2022-04-01 04:53:18 <smcavoy>  could somone, maybe ncopa, take a look at !26763 ?
2022-04-01 05:11:31 <Asmadeus> Since I faced some lack of reviews recently as well I've wanted to review some other unrelated PRs to help -- how do you folks go about it? It it just 'content looks OK and tests pass'? Or are there some scripts that can pull in the test build artiacts to install locally and confirm? I can probably do that for programs I use, unless tests are enough and it's considered a waste of time to do so
2022-04-01 05:21:06 <boomanaiden154> The general way to pull in build artifacts is to just download them from the CI pipeline and then install them with apk add —allow-untrusted
2022-04-01 05:21:48 <boomanaiden154> Reviews also make sure that MRs correspond to the code style guidelines (documentation is in the aports repository at the top level if I recall correctly) wherever reasonable.
2022-04-01 05:38:39 <Asmadeus> yeah, I found the apk in the appropriate arch build artifacts but it's a bit of a pain (multiple clicks, unzip, untrusted apk add)... Having some script to at least automatically get the proper archive for local arch and extract it would be nice if reviewers are supposed to test
2022-04-01 05:39:01 <Asmadeus> If only style check is enough downloading artifacts isn't needed though, hence my question
2022-04-01 05:52:18 <Ariadne> anyone can do reviews, you just do them :P
2022-04-01 06:08:00 <Asmadeus> A poor review is no better than any review, and there doesn't seem to be any information about what's expected of one in the markdown files in the repo. If nobody cares then I'll happily just review commit guidelines without downloading anything
2022-04-01 06:25:39 <ikke> Asmadeus: I check the build log as well
2022-04-01 06:25:46 <ikke> but I don't install the packages locally
2022-04-01 06:26:14 <Asmadeus> That sounds like something I can do :) thanks!
2022-04-01 07:01:29 <nmeum> does anyone know if Marian Buschsieweke is in this irc channel?
2022-04-01 07:02:00 <ikke> not atm
2022-04-01 07:02:07 <ikke> they would be here as maribu[m]
2022-04-01 07:02:21 <nmeum> ok, thanks
2022-04-01 10:51:56 <ikke> ncopa: !32597 nss security upgrade, but the suggestion version bumps soname
2022-04-01 13:03:06 <ncopa> ikke: does it really bump soname? provides seems to have so:libssl3.so=72
2022-04-01 13:05:32 <ncopa> i dont think it bumps soname
2022-04-01 13:19:11 <ikke> oh ok
2022-04-01 13:20:02 <ikke> so there aren't things linked against '/usr/lib/libsmime3.so.60' for example?
2022-04-01 13:43:41 <ncopa> correct. they are linked against libsmime3.so
2022-04-01 13:44:19 <ikke> ah ok
2022-04-01 14:34:54 <ncopa> yay! I have build all main with openssl3 now
2022-04-01 14:35:06 <ncopa> there was only a couple that failed. openvpn and pound
2022-04-01 14:35:23 <ncopa> pound needs an update, which uses mbedtls
2022-04-01 14:35:39 <ncopa> openvpn 2.6 will support openssl3
2022-04-01 14:41:40 <ncopa> actually, i have a handful left, that has indirect builddep of openssl
2022-04-01 14:45:52 <ncopa> what do you think? should I push that or rebuild comminuty first?
2022-04-01 14:47:49 <psykose> community as well
2022-04-01 14:47:59 <psykose> otherwise edge will be completely broken if anyone upgrades for a long time
2022-04-01 14:48:21 <psykose> i.e. libcurl is pulled in by basically anything, it will break flatpak and a bunch of things in that space
2022-04-01 14:48:44 <ncopa> apk will prevent you from upgrade that?
2022-04-01 14:48:49 <psykose> nope
2022-04-01 14:48:52 <skarnet> the right answer is you should merge my alpine-conf MR first ;)
2022-04-01 14:49:06 <psykose> it will upgrade libcurl to openssl3, and the thing that pulls in libcurl and openssl1.1 itself will still be there
2022-04-01 14:49:15 <psykose> so the process will crash with both openssls
2022-04-01 14:49:24 <psykose> i know because i was doing the same main/ rebuilds
2022-04-01 14:49:32 <psykose> and broke my world repeatedly :p
2022-04-01 14:49:32 <ncopa> ok
2022-04-01 14:51:45 <ncopa> for main I changed openssl-dev to openssl-dev>3
2022-04-01 14:51:54 <ncopa> not sure we need to do the same with community?
2022-04-01 14:52:14 <ncopa> i did it mostly to avoid pull in openssl-dev 1.1 by mistake
2022-04-01 14:52:22 <psykose> you can also do openssl3-dev
2022-04-01 14:52:28 <psykose> but yes, i prefer that one
2022-04-01 14:52:30 <psykose> also you might want to
2022-04-01 14:52:31 <psykose> uhh
2022-04-01 14:52:36 <psykose> remove the sonameprefix= from openssl3
2022-04-01 14:52:42 <ncopa> that i already did
2022-04-01 14:52:45 <psykose> good
2022-04-01 14:52:46 <psykose> :)
2022-04-01 14:52:48 <psykose> all good then
2022-04-01 14:52:51 <Ariadne> i'm almost done with my MR to rework apk version parsing
2022-04-01 14:53:10 <skarnet> what's the problem with apk version parsing?
2022-04-01 14:53:34 <Ariadne> gentoo versions are not sufficiently expressive (e.g. you cannot put a git hash in a gentoo version, only a date)
2022-04-01 14:53:43 <skarnet> the trouble I've had with apks were mostly from the way it handles explicit vs implicit dependencies in cases of conflict
2022-04-01 14:53:48 <ncopa> 223 packages needs rebuild in community. not too bad
2022-04-01 14:53:58 <Ariadne> so we are changing things up a bit to allow things like git hashes
2022-04-01 14:54:23 <skarnet> that's cool, but how can you tell that a git hash is more recent than another?
2022-04-01 14:54:30 <skarnet> do you look into the git repo?
2022-04-01 14:54:51 <Ariadne> the solver uses build date for breaking ambiguous version collisions already
2022-04-01 14:55:22 <skarnet> hmm
2022-04-01 14:55:23 <psykose> how does the user tell, aside from it saying 'upgrade' and not 'downgrade'? what i like about the date is it kind of tells me what era it comes from
2022-04-01 14:55:53 <Ariadne> also, i'm not saying this feature will be used in alpine
2022-04-01 14:56:33 <Ariadne> but openwrt, for example, has versions which are otherwise valid, but have no valid mapping to a gentoo-style version
2022-04-01 14:56:42 <psykose> makes sense
2022-04-01 14:56:48 <Ariadne> apk recognizes things like "svn revision 1234" explicitly
2022-04-01 14:57:34 <Ariadne> (also, you could just do 1.2.3.4_gitYYYYMMDD~123456abcd)
2022-04-01 14:57:47 <psykose> lengthy
2022-04-01 14:58:53 <Ariadne> anyway, the new parsing algorithm tries to understand the semantics without having hardcoded prefixes/suffixes/etc
2022-04-01 20:47:31 <Sheila> it'd be nice to clear the 'out of date' warning per Repology on lynx…
2022-04-01 20:50:25 <craftyguy> where are the default GOFLAGS set for building packages?
2022-04-01 20:50:44 <psykose> /etc/abuild.conf
2022-04-01 20:50:45 <panekj> should be in /etc/abuild.conf
2022-04-01 20:50:57 <psykose> currently it's just -buildmode=pie
2022-04-01 20:51:06 <panekj> pie is a lie
2022-04-01 20:51:24 <psykose> it should also have have -trimpath -modcacherw i guess, but changing anything in abuild never happens so
2022-04-01 20:51:41 <psykose> also everyones fancy go makefile ignores the goflags
2022-04-01 20:51:59 <craftyguy> I think we might want to add -buildvcs=false
2022-04-01 20:52:02 <psykose> and nobody every checks that when calling `make` on go projects :p
2022-04-01 20:52:15 <panekj> I'm curious why -s -w are not in there
2022-04-01 20:52:25 <psykose> they are stripped by abuild already
2022-04-01 20:52:33 <psykose> and yes, -buildvcs=false sounds good
2022-04-01 20:52:35 <craftyguy> added in go 1.18, it makes 'git' a requirement for building because it tries to configure some version info in the binary
2022-04-01 20:52:38 <panekj> right, I keep forgetting
2022-04-01 20:52:47 <psykose> well, git is always present in build-base
2022-04-01 20:52:56 <psykose> or whatever it was called
2022-04-01 20:53:17 <psykose> the issue is only that what it configures is completely wrong and throws the aports version in there
2022-04-01 20:53:46 <craftyguy> psykose: ya, but it may not be if you abuild it locally
2022-04-01 20:54:06 <psykose> it is always pulled in by build-base
2022-04-01 20:54:08 <panekj> git is already a requirement so I don't see what's wrong
2022-04-01 20:54:15 <omni> I have no comments !28504
2022-04-01 20:54:17 <psykose> if you run `abuild -r` it will exist
2022-04-01 20:54:43 <panekj> what to do with this
2022-04-01 20:54:46 <craftyguy> oh wait, also the build fails if the builddir is not a git repo
2022-04-01 20:54:46 <psykose> or am i wrong
2022-04-01 20:54:47 <psykose> hm
2022-04-01 20:54:53 <craftyguy> even if git is installed
2022-04-01 20:54:56 <psykose> ah, that makes more sense
2022-04-01 20:55:28 <craftyguy> I hit the first issue (no git) in an unrelated CI, and someone just reported in the pmOS channel that it failed because builddir wasn't a repo. heh
2022-04-01 20:55:30 <psykose> ah, alpine-sdk is what pulls in git, but yeah
2022-04-01 20:55:36 <psykose> right, yeah
2022-04-01 20:55:37 <psykose> well
2022-04-01 20:55:43 <psykose> you can add it to goflags in an abuild mr
2022-04-01 20:55:49 <psykose> but it will probably sit there for months
2022-04-01 20:55:53 <craftyguy> ugh
2022-04-01 20:56:04 <psykose> just like modcacherw, just like trimpath, and so on
2022-04-01 20:56:16 <psykose> so every single aport manually does `export GOFLAGS="$GOFLAGS -trimpath .."`
2022-04-01 20:56:17 <ikke> Well, usually just before releases abuild gets attention
2022-04-01 20:56:20 <psykose> so you can add into that
2022-04-01 20:56:31 <psykose> before releases is probably the worst possible time for it
2022-04-01 20:56:33 <ikke> so now is a good time
2022-04-01 20:56:49 <craftyguy> ok I'll send a patch, one sec
2022-04-01 20:57:19 <panekj> I would like to see example first
2022-04-01 20:57:23 <panekj> I cannot reproduce this
2022-04-01 20:57:50 <ikke> I did have an issue the other way around
2022-04-01 20:58:03 <ikke> building in a container without git, but there was a .git dir available
2022-04-01 20:58:09 <ikke> and
2022-04-01 20:58:35 <ikke> https://github.com/golang/go/issues/51748
2022-04-01 20:58:58 <craftyguy> ikke: https://gitlab.com/postmarketOS/postmarketos-mkinitfs/-/jobs/2273477401
2022-04-01 20:59:21 <craftyguy> that was without using abuild or anything
2022-04-01 20:59:29 <panekj> right, so it fails without git
2022-04-01 20:59:43 <ikke> but CI does have git available
2022-04-01 20:59:55 <psykose> sounds like it still should be false anyway
2022-04-01 20:59:56 <ikke> _our_ ci
2022-04-01 20:59:59 <craftyguy> not that CI
2022-04-01 21:00:08 <craftyguy> ok hang on, let me clarify
2022-04-01 21:00:12 <psykose> because the tarballs will never have a separate git repo anyway- even if the stamping does something, it will be useless
2022-04-01 21:00:18 <ikke> yes, agreed
2022-04-01 21:00:19 <panekj> sure
2022-04-01 21:00:21 <ikke> so the info will be misleading
2022-04-01 21:00:38 <panekj> but "also the build fails if the builddir is not a git repo" seems false
2022-04-01 21:00:54 <craftyguy> https://paste.sr.ht/~stacyharper/ba643c686058faf460d0ceb48709beedfb36b1a2
2022-04-01 21:00:59 <craftyguy> builddir is not a repo failure ^^
2022-04-01 21:01:46 <craftyguy> setting the goflags to disable buildvcs "fixed" that failure
2022-04-01 21:02:20 <ikke> hmm, maybe some heuristic failing in go thinking it's a git repo?
2022-04-01 21:02:37 <panekj> it doesn't fail for me without .git
2022-04-01 21:03:00 <craftyguy> 🤷
2022-04-01 21:03:17 <psykose> there is a `busybox su pmos -c HOME=/home/pmos ln -sf /mnt/pmaports/.git /home/pmos/build/.git`
2022-04-01 21:03:19 <psykose> earlier
2022-04-01 21:03:54 <psykose> either there is some magic stuff, or that .git is not a git repo, and some git heuristic doesn't check if it's actually git
2022-04-01 21:04:02 <psykose> i.e. if exists .git; git status ..
2022-04-01 21:04:27 <psykose> (git status then fails with not a git repo..)
2022-04-01 21:04:34 <craftyguy> hmm. yeah I don't know
2022-04-01 21:04:41 <psykose> in any case none of these really matter and are easily fixed with false which it should be
2022-04-01 21:04:51 <psykose> but if you think it's also a go heuristic bug, you can take that to the go upstream
2022-04-01 21:05:53 <psykose> and yes, feel free to mr the -buildvcs=false change
2022-04-01 21:06:01 <craftyguy> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/142
2022-04-01 21:06:05 <psykose> neat
2022-04-01 21:06:09 <craftyguy> :)
2022-04-01 21:06:25 <panekj> in few years, it might get merged
2022-04-01 21:06:39 <psykose> at least three
2022-04-01 21:06:47 <craftyguy> heh
2022-04-01 21:08:53 <panekj> might as well add PR for go get
2022-04-01 21:09:18 <psykose> i don't think that one works as well as cargo fetch
2022-04-01 21:09:29 <psykose> or hm
2022-04-01 21:09:33 <psykose> what does it do with vendor dirs
2022-04-01 21:09:39 <psykose> there
2022-04-01 21:09:40 <panekj> I tested it, it works
2022-04-01 21:09:41 <psykose> 's
2022-04-01 21:09:46 <psykose> a lot of things that don't fetch anything
2022-04-01 21:09:59 <panekj> things that don't fetch things can remove it?
2022-04-01 21:10:00 <psykose> i.e. they only need a go build, without network, because they ship a tarball with vendor predone
2022-04-01 21:10:05 <psykose> sure
2022-04-01 21:10:28 <panekj> most things are off of vendor nowadays
2022-04-01 21:11:10 <psykose> most indeed
2022-04-01 21:12:20 <psykose> ah, we don't have a mr for -trimpath
2022-04-01 21:12:23 <psykose> you can open one :)
2022-04-01 21:13:18 <psykose> it's mostly stylistic and does not affect anything: https://img.ayaya.dev/E66Q4WzYlwt7
2022-04-01 21:13:30 <psykose> the only real use for this (aside from not adding pointless system paths), is reproducible builds
2022-04-01 21:13:41 <psykose> since the output will no longer care about the fs path
2022-04-01 21:13:56 <psykose> the vcs=false is also needed for repro builds, as far away as we are from that
2022-04-01 21:43:58 <panekj> mr made
2022-04-01 21:47:20 <psykose> very good
2022-04-01 21:48:11 <ikke> now 3 mrs that conflict with eachother :p
2022-04-01 21:55:13 <psykose> if only i could press the merge button :p
2022-04-01 21:58:16 <sam_> psykose: the go thing is a real PITA
2022-04-01 21:58:23 <sam_> especially given it doesn't exist with older go versions
2022-04-01 21:58:25 <sam_> (the flag)
2022-04-01 21:58:51 <psykose> well we do only have new versions
2022-04-01 21:59:29 <psykose> we don't backport abuild (usually) so it would only affect going forward
2022-04-01 21:59:32 <psykose> and going forward it's 1.18
2022-04-01 21:59:36 <psykose> at minimum
2022-04-01 21:59:39 <panekj> imo, other derivatives should use own abuild.conf if they maintain difference 
2022-04-01 21:59:50 <psykose> it would take some work, but sure
2022-04-01 21:59:58 <psykose> mostly just a per-branch patch in the branch
2022-04-01 22:03:46 <sam_> psykose: oh right
2022-04-01 23:08:30 <rdavidson> i'm here about a bug i opened in the aports repo: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13302
2022-04-01 23:09:21 <rdavidson> basically, on some raspberry pi zero 2 w boards, the linux-firmware-brcm package is missing the right firmware to make wifi work
2022-04-01 23:09:39 <rdavidson> because the firmware hasn't been merged into the linux-firmware upstream repo yet
2022-04-01 23:10:08 <rdavidson> if i make a patch to pull in this firmware from the RPi-Distro repo, would such a patch be accepted?
2022-04-01 23:15:53 <psykose> possibly, but it would really be good if upstream also fixed it
2022-04-01 23:18:45 <rdavidson> yeah, i agree, and according to https://github.com/raspberrypi/linux/issues/4723#issuecomment-984418504 it is currently hung up on formally approved license statements.
2022-04-01 23:21:25 <psykose> hm
2022-04-01 23:21:36 <psykose> if the sole upstream reason is 'licensing issues' then the same would apply to us
2022-04-01 23:21:37 <psykose> sadly
2022-04-01 23:22:05 <psykose> not to say that we can't make a different decision and decide it is resolved or something and instantly pre-load it, but i would not hold my breath
2022-04-01 23:22:44 <psykose> and yes, i have read all the rpi issues and the same '2w' having two different modules with different firmware, so it kinda sucks
2022-04-01 23:24:01 <rdavidson> 
ACTION nods

2022-04-01 23:25:17 <rdavidson> i made a custom apk for it but iirc i ran into some issues with getting mkimage and update-kernel to include it. i'll repro with the latest release and see where it stands.
2022-04-01 23:26:38 <psykose> your easiest bet would be to have an 'upgraded' version of linux-firmware, but you have to be careful to not let new versions without your overrides to install as well
2022-04-01 23:26:51 <psykose> since if you have a patched linux-firmware it should just work as always, i would guess
2022-04-01 23:27:05 <psykose> you can always make the version 999999 as well :p
2022-04-01 23:27:54 <rdavidson> oh, i made it as a separate package named "rpizero2w-wifi-firmware"
2022-04-01 23:32:40 <psykose> you can, but that involves making sure those scripts work fine with the extra package, which means updating them too
2022-04-01 23:33:51 <rdavidson> yeah, i was wondering how it detected the firmware to use. i had thought that including a package which deployed the files on the right path would be sufficient, but it turned out to not be.
2022-04-01 23:35:25 <psykose> it probably has a hardcoded list of packages
2022-04-02 00:19:48 <rdavidson> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/update-kernel.in#L300 implies to me that the firmware files are supposed to be detected by some code. :D
2022-04-02 00:21:36 <rdavidson> ah, it's compiled into the kernel module. bluh.
2022-04-02 00:23:27 <psykose> --modloopfw lets you pass more
2022-04-02 00:23:30 <psykose> apparently
2022-04-02 00:23:58 <rdavidson> yep! i found a bug in that earlier. thankfully it's fixed now.
2022-04-02 00:24:15 <rdavidson> (https://gitlab.alpinelinux.org/alpine/aports/-/issues/13408)
2022-04-02 00:25:13 <rdavidson> i'm curious, though, if i specify --modloopfw, and update-kernel is later run automatically (for instance, when i update the kernel) will my extra firmware be preserved?
2022-04-02 00:29:40 <Hello71> update-kernel is, confusingly, not run when the kernel is updated
2022-04-02 00:30:46 <rdavidson> ah.
2022-04-02 01:12:15 <rdavidson> so, in my case, i have this raspberrypi which is typically run headless, and i have to ssh into it. in order for ssh to work, wifi has to work; in order for wifi to work, this custom firmware has to be found during boot. i want to make sure that my extra firmware is included if modloop is ever rebuilt. i would assume the modloop _can_ get rebuilt at some points, because the kernel modules can get upgraded during an upgrade.
2022-04-02 01:13:08 <rdavidson> or is that a manual process?
2022-04-02 01:16:23 <rdavidson> ah, i see, it's a manual process for diskless setups
2022-04-02 01:50:22 <Hello71> yes
2022-04-02 21:32:02 <EvTheFuture> Hello! I'm looking at packaging x42-plugins from https://github.com/x42/x42-plugins I just wonder if anyone have an idea on how to package this... As one package with the version set to the date like other distros seems to do according to https://repology.org/project/x42-plugins/versions or as separate packages or maybe as subpackages for each plugin. Ideas are very welcome.
2022-04-02 21:35:53 <panekj> imo, make single package 'x42-plugins' and each submodule as subpackage with own versioning, description, etc.
2022-04-02 21:36:32 <panekj> but you want to grab each git repo separately since github will not provide you with submodules in downloaded archive
2022-04-02 21:37:07 <panekj> and each seems to have git tags to which you could refer
2022-04-02 21:41:25 <EvTheFuture> Thanks for the feedback, I'll look into it and see how to achieve this in a simple maintanable way.
2022-04-03 05:39:03 <ikke> EvTheFuture: right now, subpackages cannot have a separate version
2022-04-03 05:53:59 <EvTheFuture> ikke: I guess I just use the date then as the version. I've successfully compiled all submodules (needed to package a new lib which I've created an MR for). All submodules are downloaded in the tar file that is automatically downloaded when building the package. Can I include the version in the description of each subpackage maybe?
2022-04-03 06:08:37 <psykose> if you mean https://gareus.org/misc/x42-plugins/x42-plugins-20220327.tar.xz , then i would not really split it into submodules to begin with
2022-04-03 06:34:50 <EvTheFuture> psykose: Yes that was my idea. would you rather prefer to create individual packages (one for each plugin) and then a meta package x42-plugins that depend on all the plugin packages? Or how would you do this?
2022-04-03 06:35:28 <psykose> literally just x42-plugins and it has all the plugins
2022-04-03 06:36:04 <EvTheFuture> psykose: ok, that is very simple and if so, that is already done :)
2022-04-03 06:37:26 <EvTheFuture> psykose: If you have time maybe you could take a look at MR 32750 which x42-plugins will depend on
2022-04-03 06:37:36 <ikke> !32750
2022-04-03 06:38:31 <psykose> i certainly have the time
2022-04-03 06:38:38 <psykose> but do i have the will and the energy? absolutely not
2022-04-03 06:38:49 <EvTheFuture> psykose: :)
2022-04-03 06:39:18 <ikke> btw, approving your own MRs is kinda moot
2022-04-03 06:39:29 <psykose> approvals in general are meaningless except in one single case
2022-04-03 06:39:34 <ikke> yes
2022-04-03 06:40:06 <ikke> With CE you don't really have control over who can approve
2022-04-03 06:41:07 <EvTheFuture> yea it would be kinda weird to not aprove your own MR, the only thing is if it would be used instead of the Draft: prefix
2022-04-03 06:41:36 <ikke> For us, the only case it makes sense if the maintainer of a package approves the MR from someone else to that package
2022-04-03 06:43:00 <ikke> approving things you authored yourself doesn't make a lot of sense
2022-04-03 06:43:13 <EvTheFuture> ikke: ok. I recently started to package for Alpine. Did't know how you used the "aprove" function, now I know, thanks.
2022-04-03 06:44:03 <EvTheFuture> ikke: exactly, that was what I tried to say above, but it was not that clear in my text :)
2022-04-03 06:47:02 <EvTheFuture> I do no longer "approve" MR 32750, but appreciate reviews/merge when the time, energy, motivation, feeling, will is available for someone with permission to merge :)
2022-04-03 06:48:11 <ikke> I'll try later today, have to go now
2022-04-03 06:48:16 <psykose> if i was less dead inside i would go do it
2022-04-03 06:54:37 <EvTheFuture> No worries, I fully understand.
2022-04-03 07:05:03 <EvTheFuture> Another question regarding the license tag. All modules except two have the license GPL version 2, the other two have the license GPL version 3. Now when packaging this as one package with all plugins included. How do we handle the license tag for the package?
2022-04-03 07:10:14 <EvTheFuture> Do I just list both GPLv2 and GPLv3 in the license tag for the pacakge then?
2022-04-03 07:30:32 <EvTheFuture> Ok, I added both licenses to the license tag. Will create MR when 32750 has been merged (learned today that I could have created one MR with two commits, I'll do that the next time)
2022-04-03 09:41:51 <clandmeter> ncopa, ikke: seems lua-mosquitto is broken https://tpaste.us/x51r
2022-04-03 09:42:04 <clandmeter> edge and stable
2022-04-03 10:08:06 <clandmeter> seems it needs LUA_COMPAT_APIINTCASTS for lua5.3
2022-04-03 10:08:22 <clandmeter> but that introduces others issues
2022-04-03 10:37:50 <Ariadne> nmeum: nice to see testing/booster, i wonder if we can integrate the run from ram bits into it
2022-04-03 10:40:09 <nmeum> Ariadne: you mean the modloop stuff for non-sys installations?
2022-04-03 10:40:34 <Ariadne> i mean the "run apk to generate a tmpfs"
2022-04-03 10:40:38 <ikke> clandmeter: can it be built against lua5.4?
2022-04-03 10:41:30 <nmeum> Ariadne: right, that's what I was referring to as well :D (haven't personally used that in a while)
2022-04-03 10:41:38 <nmeum> I think it should be possible, the booster code is really quite hackable
2022-04-03 10:41:59 <nmeum> currently working with booster upstream to generally improve support for musl-based distributions
2022-04-03 10:54:42 <clandmeter> ikke: its in aports so i guess it should
2022-04-03 10:54:52 <clandmeter> i think something in lua changed in 3.15
2022-04-03 10:54:59 <clandmeter> before, mosquitto seems to work
2022-04-03 11:02:45 <Ariadne> nmeum: i wonder if booster upstream would be interested in a cooperative mode, where an initramfs uses booster components to probe for devices, etc
2022-04-03 11:03:45 <Ariadne> at $dayjob we are working on a declarative installer for APK distributions, which is deployed as an initramfs (it fetches a config from some location and then reboots the machine)
2022-04-03 11:40:30 <nmeum> Ariadne: possible, so far upstream has been very open to changes and additional use-cases
2022-04-04 01:02:32 <panekj> there is a bug(?) in openrc checkpath where it fails to create directory if path ends with /
2022-04-04 01:03:41 <panekj> it's been patched in at least 0.43.3-r3 (alpine v3.14) but it's still present in 0.42.1-r21 (alpine v3.13)
2022-04-04 01:09:34 <panekj> seems like https://github.com/OpenRC/openrc/commit/6219d87071d07acf4d6b3e99ec58134acf129d8e should be backported
2022-04-04 01:12:35 <panekj> also https://github.com/OpenRC/openrc/commit/00ea2166081856774f24f7243126f701c7fe6db9 looks like potentially should be backported as well?
2022-04-04 05:24:24 <Ariadne> panekj: feel free to open an MR and i'll review it
2022-04-04 05:25:25 <ikke> panekj: yeah, I've been running into the same
2022-04-04 07:33:30 <ikke> "OSs That Do Not Support kTLS": "Alpine Linux 3.11–3.14 – Kernel is built with the CONFIG_TLS=n option, which disables building kTLS as a module or as part of the kernel."
2022-04-04 07:33:37 <ikke> https://www.nginx.com/blog/improving-nginx-performance-with-kernel-tls/
2022-04-04 07:45:25 <ikke> ncopa: is that something we can enable?
2022-04-04 07:50:12 <ncopa> ncopa-desktop:~$ zcat /proc/config.gz | grep CONFIG_TLS
2022-04-04 07:50:12 <ncopa> # CONFIG_TLS is not set
2022-04-04 07:50:20 <ncopa> i guess we can
2022-04-04 07:51:24 <ncopa> ikke: maybe create an issue in gitlab with tag kernel, and I'll have a look at it next kernel update
2022-04-04 07:51:32 <ikke> will do
2022-04-04 07:52:05 <ncopa> interestingly: main/linux-lts/config-lts.armv7:CONFIG_TLS=m
2022-04-04 07:52:31 <ncopa> lts.armv7.config:CONFIG_TLS=m
2022-04-04 07:52:59 <ncopa> yeah, i think we should enable it for all of our kernels
2022-04-04 07:55:46 <ikke> !13664
2022-04-04 07:55:51 <ikke> #13664
2022-04-04 07:57:31 <ncopa> 👍
2022-04-04 07:59:05 <Daanct12> good afternoon ncopa 
2022-04-04 07:59:21 <ncopa> Daanct12: hi! how are you doin?
2022-04-04 08:00:56 <Daanct12> doing good, i'm currently trying to get linux mainline to boot on my tv set top box
2022-04-04 08:01:31 <Daanct12> so i can have alpine tv :)
2022-04-04 08:07:23 <ncopa> sounds cool :)
2022-04-04 08:07:48 <Daanct12> yep! i dont think it can go to alpine though, so postmarketOS it is :)
2022-04-04 08:09:09 <ncopa> postmarketos ppl are doing an amazing job
2022-04-04 08:09:50 <Daanct12> they sure do! picking alpine was a very good choice for ancient phones
2022-04-04 08:11:06 <Daanct12> as for why it can't go to alpine, booting one of these quirks on top of vendor's u-boot
2022-04-04 08:11:25 <Daanct12> chainloading u-boot was one of them
2022-04-04 08:13:06 <Daanct12> so yeah, not upstreamable and i dont think any of you would like them :)
2022-04-04 08:55:02 <indy> psykose, hi, i recall you made some changes for rust+wasm
2022-04-04 08:58:30 <indy> psykose, i'm trying to make packages for influxdb v2 and build process fails on building wasm-pack which is needed for building got wrapper for libflux (rust)
2022-04-04 10:31:21 <panekj> I don't think it ever made into alpine/aports
2022-04-04 11:40:28 <panekj> Ariadne: !32784
2022-04-04 11:56:59 <panekj> and !32785
2022-04-04 12:33:12 <ncopa> bumped into first problematic package with openssl3. I dont know how to fix this.
2022-04-04 12:34:25 <ncopa> its fractal. it uses rust openssl binding
2022-04-04 12:38:09 <panekj> do we really need to move to openssl3 now? openssl1.1.1 is supported until sept 2023
2022-04-04 12:39:09 <panekj> btw. openssl{,-sys} crates support up to openssl1.1.1, openssl3 is not supported
2022-04-04 12:39:23 <ikke> Alpine 3.16 would be supported until May 2024
2022-04-04 12:39:34 <Ariadne> i'm not really convinced that openssl 3 will be the winner here
2022-04-04 12:40:11 <Ariadne> amazon has forked openssl 1.1 internally, for example
2022-04-04 12:42:23 <ncopa> fedora and debian is switching to openssl3. i think its a good time to do so now
2022-04-04 12:45:35 <panekj> well, rust packages that depend on openssl-dev will have trouble building with openssl3 for sure, as I mentioned earlier openssl supports only up to 1.1.1 and libressl 2.5 - 3.4.0 
2022-04-04 12:45:54 <panekj> s/openssl supports/openssl crate supports
2022-04-04 12:45:54 <alpine-meetbot> panekj meant to say: well, rust packages that depend on openssl-dev will have trouble building with openssl3 for sure, as I mentioned earlier openssl crate supports only up to 1.1.1 and libressl 2.5 - 3.4.0 
2022-04-04 12:46:59 <Ariadne> how does fedora/debian solve this openssl-sys issue
2022-04-04 12:58:26 <ncopa> sounds like they give a 404....
2022-04-04 12:58:34 <ncopa> so they probably dont have fractal package
2022-04-04 12:58:54 <panekj> there is fractal, just not gnome fractal :P
2022-04-04 12:59:24 <panekj> https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/openssl-sys/debian
2022-04-04 13:00:51 <panekj> seems like they build own version of openssl-sys and link to it
2022-04-04 13:01:20 <panekj> but I don't know any major rust package that is available in debian
2022-04-04 13:01:23 <ncopa> ddevault: i get build error for gmnisrv with openssl3
2022-04-04 13:01:34 <ddevault> what error?
2022-04-04 13:02:01 <ncopa> https://tpaste.us/WQEY
2022-04-04 13:02:23 <ddevault> can you prepare a patch?
2022-04-04 13:03:19 <ncopa> dont know how (yet)
2022-04-04 13:03:31 <ddevault> well, neither do I (yet)
2022-04-04 13:03:36 <ncopa> :D
2022-04-04 13:03:52 <ddevault> if you don't have time or run into a wall, email me the details and I'll add it to my (large) todo list
2022-04-04 13:03:54 <panekj> fedora also seems to build own openssl-sys https://src.fedoraproject.org/rpms/rust-openssl-sys/blob/rawhide/f/openssl-sys-fix-metadata.diff
2022-04-04 13:05:08 <ncopa> ddevault: I'll see if i can fix it. does not look too scary
2022-04-04 13:05:13 <ddevault> agreed
2022-04-04 13:05:15 <ddevault> thanks!
2022-04-04 13:18:44 <ncopa> ddevault: it builds fine. just not with -Werror
2022-04-04 13:19:40 <ddevault> I will NACK a patch disabling -Werror
2022-04-04 13:25:20 <ncopa> I think -Werror is fine for dev / git master. But not so good for releases
2022-04-04 13:26:12 <ncopa> woudl be nice with a --disable-werror config flag or similar
2022-04-04 13:27:06 <ncopa> i believe gmnisrv works just fine with openssl3. it just warns that the API is deprecated
2022-04-04 13:27:15 <ncopa> so for the alpine package its fine
2022-04-04 13:27:33 <ncopa> but for upstream dev its nice to get it error out so it can be fixed
2022-04-04 13:28:44 <ncopa> this is what I propose for aports:  https://tpaste.us/enVa
2022-04-04 13:33:15 <ncopa> sources for gnome-podcasts is gone
2022-04-04 13:33:40 <ncopa> curl: (22) The requested URL returned error: 404
2022-04-04 13:33:51 <ncopa> seems like they re-tagged it or something
2022-04-04 13:35:33 <panekj> source url seems to be correct: https://gitlab.gnome.org/World/podcasts/uploads/de438a4d62196bddd134bb155a812fe1/gnome-podcasts-0.5.1.tar.xz
2022-04-04 13:36:24 <panekj> weird, their gitlab releases is intact and showing this file but 404
2022-04-04 13:43:01 <ncopa> similar with gnome-shortwave
2022-04-04 13:45:12 <ncopa> https://gitlab.gnome.org/World/Shortwave/-/releases
2022-04-04 13:45:28 <ncopa> gnome source downloads is broken. anybody know who to contact?
2022-04-04 13:48:06 <panekj> can ask on ther matrix channel
2022-04-04 13:48:18 <ncopa> would appreciate that
2022-04-04 13:48:36 <panekj> any other packages that are gone?
2022-04-04 13:48:36 <ncopa> https://gitlab.gnome.org/World/Shortwave/-/issues/635
2022-04-04 13:49:16 <ncopa> https://gitlab.gnome.org/World/podcasts/-/issues/259
2022-04-04 13:49:28 <ncopa> those two are the ones I noticed so far
2022-04-04 13:51:17 <ncopa> maybe because they involve rust? feels rust has a finger in every problem I have nowdays
2022-04-04 13:51:59 <panekj> I don't think rust magically makes uploads disappear
2022-04-04 13:53:18 <panekj> although I agree it's not the best thing to package 
2022-04-04 13:53:55 <panekj> mentioned both issues on main GNOME channel, someone ought to have a look at some point
2022-04-04 13:54:19 <ncopa> thanks!
2022-04-04 14:49:16 <panekj> I've raised issue for GNOME infra team since I was told infra doesn't look in main channel on matrix https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/799
2022-04-04 14:50:12 <ikke> Maybe they ran into the gitlab issue where artifacts were removed that weren't supposed to
2022-04-04 14:50:53 <panekj> there seem to be custom uploads, and not artifacts released by pipeline
2022-04-04 14:50:58 <panekj> s/there/these
2022-04-04 14:50:58 <alpine-meetbot> panekj meant to say: these seem to be custom uploads, and not artifacts released by pipeline
2022-04-04 15:15:50 <skarnet> -Werror is a toy for developers and shoud *never* be used in releases
2022-04-04 15:16:31 <skarnet> what software can pretend to control exactly what warnings compiler developers are going to add in subsequent versions?
2022-04-04 15:17:01 <skarnet> -Werror ties software to a compiler version, which is the road to madness
2022-04-04 15:21:55 <ncopa> skarnet: exactly
2022-04-04 15:22:16 <ncopa> at a minimum there should be a convenient way to disable it
2022-04-04 15:24:58 <Ariadne> in fairness, openssl 3 "deprecated" APIs have had a non-zero likelihood of just being totally broken
2022-04-04 15:25:04 <Ariadne> see also: MD_null
2022-04-04 15:25:38 <Ariadne> so i think turning off -Werror and letting a deprecation warning slide might not be a winning strategy
2022-04-04 15:26:41 <skarnet> there should be a -Werror-deprecated flag
2022-04-04 15:27:05 <skarnet> because that's a situation where you actively want the build to fail
2022-04-04 15:28:09 <skarnet> -Werror isn't actively wanting the build to fail in a given case, it's being a snowflake princess that will refuse to go on when someone sneezes near her
2022-04-04 15:31:14 <Ermine> There's something like -Wno-error
2022-04-04 15:32:33 <Ariadne> skarnet: there is: -Werror=deprecated
2022-04-04 15:34:55 <skarnet> Ariadne: great, then that's the flag that should be used
2022-04-04 15:51:29 <panekj> from gnome infra said, there was a disk corruption around 25th
2022-04-04 15:56:00 <panekj> should be restored soon
2022-04-04 16:08:25 <ncopa> thanks!
2022-04-04 16:20:19 <ncopa> Does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.12.12-3.13.10-3.14.6-3.15.4-released.html
2022-04-04 16:38:19 <Ermine> lgtm
2022-04-04 16:40:09 <panekj> looks ok
2022-04-04 16:44:08 <ncopa> thank you
2022-04-04 16:45:03 <panekj> mhm, I noticed that webpage title is ver - 1
2022-04-04 16:45:28 <panekj> <title>Alpine 3.12.11, 3.13.9, 3.14.5 and 3.15.3 released | Alpine Linux</title>
2022-04-04 16:46:06 <panekj> cc ncopa
2022-04-04 16:46:12 <ncopa> oh,,
2022-04-04 16:46:16 <ncopa> ill fix it
2022-04-04 16:47:11 <ncopa> should be fixed now. thanks!
2022-04-04 16:47:16 <panekj> other than that, everything looks fine
2022-04-04 16:47:30 <ncopa> its pushed to prod
2022-04-04 16:55:44 <ncopa> hm... vtk fails to build on x86. i cannot tag edge release
2022-04-04 17:24:17 <panekj> ncopa: data was restored and package sources should be available again 
2022-04-04 17:25:10 <panekj> but it seems now that gnome gitlab died with 502 error
2022-04-04 17:28:29 <panekj> ok, now it's should be available for sure, from gnome infra, data restored, gitlab restored and they moved stuff into s3
2022-04-04 17:46:09 <ikke> boomanaiden154 vtk has test failures on x86
2022-04-04 19:54:07 <boomanaiden154> ikke: Fun. I should be able to get to it in a couple hours. If you need to get stuff through the builder I’m fine with the tests temporarily being disabled.
2022-04-04 19:59:35 <ikke> boomanaiden154: I suppose ncopa wants to do a release tomorrow (CEST), so there's time until then
2022-04-04 20:11:07 <boomanaiden154> Okay. I’ll almost definitely have everything fixed up by then.
2022-04-04 20:21:13 <Ermine> 3.15.5?
2022-04-04 20:22:35 <ikke> no, edge snapshot, others have already been released
2022-04-04 20:23:38 <ikke> https://alpinelinux.org/posts/Alpine-3.12.12-3.13.10-3.14.6-3.15.4-released.html
2022-04-05 04:14:07 <EvTheFuture> If someone have the time/energy etc to take a look at MR 32750 it would be greatly appreciated :)
2022-04-05 04:36:42 <ikke> merged
2022-04-05 04:36:51 <EvTheFuture> Thank you!
2022-04-05 04:37:32 <EvTheFuture> Now I can work on my next one that have dependency on this :)
2022-04-05 04:38:04 <ikke> EvTheFuture: fyi, it's also possible to submit them in a single MR 
2022-04-05 04:49:23 <EvTheFuture> Ikke: yes I got that info after creating 32750 and I will do so the next time :)
2022-04-05 04:49:43 <ikke> EvTheFuture: no worry
2022-04-05 06:08:58 <EvTheFuture> ikke: Can I see the progress of the build somewhere? Doesn't seem like the x86 version gets built...
2022-04-05 06:29:50 <ikke> EvTheFuture: x86 builder is stuck atm
2022-04-05 06:29:54 <ikke> boomanaiden154: bad news
2022-04-05 06:31:31 <EvTheFuture> ikke: ok
2022-04-05 06:31:47 <ikke> EvTheFuture: https://build.alpinelinux.org/
2022-04-05 06:31:54 <ikke> there you can see what the builders are doing
2022-04-05 06:32:16 <ikke> If you feel inclined, you can also join #alpine-commits, where the builders announce things as well
2022-04-05 06:48:31 <EvTheFuture> Thank you ikke
2022-04-05 07:29:12 <omni> !32655
2022-04-05 07:44:08 <ddevault> community/weasyprint up for adoption, any takers?
2022-04-05 07:44:34 <ddevault> it seems that everyone and their dog has been making major changes to it without notifying me, anyway
2022-04-05 07:46:39 <ddevault> we may generally need to strive to be better about making sure package maintainers are in the loop when their packages are being changed, bit of a nasty surprise to come back to one to find it much different from how you left it
2022-04-05 07:48:52 <Habbie> i recently got pinged on a third party MR to one of my ports - is that not automated in gitlab?
2022-04-05 07:49:15 <ddevault> I noticed that as well (+1 for that, btw) but it does not seem to work consistently
2022-04-05 07:49:21 <ddevault> I am still often surprised by changes that flew under my radar
2022-04-05 07:49:25 <Habbie> ack
2022-04-05 07:49:43 <ddevault> when was the gitlab bot rolled out?
2022-04-05 07:49:50 <ddevault> maybe all of the surprises are really prior to its introduction
2022-04-05 07:49:51 <Ermine> Package maintainers should get emails when there is a mr on their packages, shouldn't they?
2022-04-05 07:49:55 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/36
2022-04-05 07:50:13 <ikke> They should, by being assigned to the MR
2022-04-05 07:50:23 <ddevault> when was the assignment mechanism introduced?
2022-04-05 07:52:52 <ikke> about 1 year ago
2022-04-05 07:53:18 <ddevault> hm, plausibly close enough to the source of the changes which I'm noticing
2022-04-05 07:53:43 <ddevault> it's probably just that I'm still being bitten by changes which snuck in prior to the assignment bot, but which I'm only noticing now when I go to update a package which was changed under my feet
2022-04-05 07:53:46 <ddevault> 
ACTION shrugs

2022-04-05 08:25:00 <ktprograms> ikke: Just wondering, why did you set -R on the channel?
2022-04-05 08:38:26 <ikke> ktprograms: We added it to deal with spam, but there are users who want to remain anonymous and it prevents them from participating
2022-04-05 08:39:09 <ktprograms> Hmm I see. So what's the plan for dealing with spam?
2022-04-05 08:39:37 <ikke> We'll see when it happens
2022-04-05 08:40:43 <ktprograms> Alright. Hopefully there's no spam :)
2022-04-05 08:40:47 <ikke> nod
2022-04-05 08:41:34 <ikke> And as oftc does not support SASL yet, it's more user friendly when your client gets disconnected
2022-04-05 08:42:24 <ktprograms> Yes, that happens to me every day since I haven't taken the time to register my alt nick
2022-04-05 08:42:40 <ktprograms> FYI the #alpine-offtopic channel is still +R
2022-04-05 10:18:34 <ncopa> openssl 3 migration is going fairly well so far
2022-04-05 10:19:19 <ncopa> only bumped into a 2-3 packages that cannot be ported to openssl 3 so far
2022-04-05 10:19:45 <panekj> \o/
2022-04-05 10:27:12 <Habbie> ncopa, pdns/pdns-recursor/dnsdist are happy?
2022-04-05 10:28:07 <ncopa> dont know yet
2022-04-05 10:28:36 <Habbie> ok
2022-04-05 10:29:01 <ncopa> dnsdist is unhappy. but... https://src.fedoraproject.org/rpms/dnsdist/blob/rawhide/f/dnsdist-1.7.0-openssl30.patch
2022-04-05 10:29:15 <ncopa> so it will be fine
2022-04-05 10:29:21 <Habbie> ack - we have that one upstream too, just unreleased i think
2022-04-05 10:30:50 <ncopa> i think the only problematic package so far is gnome-shortwave
2022-04-05 10:31:13 <ncopa> problematic as no solution or workaround so far
2022-04-05 10:32:07 <ncopa> there are a couple of ther packages that can be worked around by using openssl1.1, like mongodb-tools. its a golang app so its static and has no conflicts with other deps
2022-04-05 10:32:26 <panekj> what's the problem with gnome-shortwave
2022-04-05 10:32:39 <panekj> as in, what's the error
2022-04-05 10:32:44 <ncopa> https://gitlab.gnome.org/World/Shortwave/-/issues/636
2022-04-05 10:33:11 <ncopa> i think it may be solved with newer version of rust-openssl
2022-04-05 10:38:44 <panekj> it's latest
2022-04-05 10:40:08 <ncopa> then its still problematic :)
2022-04-05 10:40:25 <panekj> it could have been fixed in HEAD though
2022-04-05 10:40:33 <panekj> I'm looking through rust-openssl commits
2022-04-05 10:41:05 <panekj> is there an openssl3 branch in aports perchance?
2022-04-05 10:41:38 <ncopa> not publically available. only here on my local machine
2022-04-05 10:42:26 <panekj> commit history is great: "Subject: [PATCH] f u libressl"
2022-04-05 10:44:19 <ncopa> sounds nice...
2022-04-05 10:44:22 <ncopa> hum
2022-04-05 10:44:36 <ncopa> i think i have bumped into the firs real serious problem
2022-04-05 10:44:43 <ncopa> py3-cryptography
2022-04-05 10:44:53 <ncopa> upstream switched to rust
2022-04-05 10:45:01 <panekj> I forgot that openssl3 is on edge, will try to patch shortwave to use HEAD for rust-openssl
2022-04-05 10:45:14 <ncopa> but we need it for all architectures, including s390x
2022-04-05 10:45:38 <ncopa> so this is actually a potential blocker
2022-04-05 10:46:05 <Ariadne> :(
2022-04-05 10:46:21 <Ariadne> i can try to bootstrap rust on s390x again
2022-04-05 10:46:31 <Ariadne> but there's some bug in rustbuild
2022-04-05 10:47:00 <Habbie> it only needs it during build, but i guess that doesn't help here?
2022-04-05 10:49:38 <Ariadne> s390x does not have rust at build time no
2022-04-05 10:50:32 <Habbie> ack - in openwrt these distinctions help, although I see they're still at cryptography 3.4.8, from before the hard requirement
2022-04-05 10:52:44 <panekj> cross-compiling wouldn't work as a hack?
2022-04-05 10:52:57 <Ariadne> can't create
2022-04-05 10:53:00 <Ariadne> s390x cross compiler
2022-04-05 10:53:09 <Ariadne> rustbuild is bugged
2022-04-05 10:53:29 <ncopa> do you have an url to the upstream issue for rustbuild?
2022-04-05 10:54:08 <Ariadne> https://github.com/rust-lang/rust/issues/92976
2022-04-05 10:54:25 <ncopa> i wonder if i should file an issue to upstream python cryptography
2022-04-05 10:59:38 <ikke> https://github.com/pyca/cryptography/issues/6681
2022-04-05 11:26:11 <panekj> is there are reason gnome-shortwave isn't bumped to 2.0.1 (cur: 1.1.1)
2022-04-05 11:57:52 <panekj> seems like latest version of rust-openssl does fix the issue
2022-04-05 12:18:57 <pabloyoyoista> Hi everybody, which is the best way to deal with one library that changed its versioning number down? Its libgweather, which "upgraded" from 40 to 4.0.0, including a major API change
2022-04-05 12:22:16 <pabloyoyoista> Packages that need the new API are still pulling version 40 in the pipeline :(
2022-04-05 12:23:03 <Ermine> Idk if there are epoch numbers available
2022-04-05 12:24:04 <ikke> no
2022-04-05 12:24:12 <panekj> maybe new package 'libgweather4'?
2022-04-05 12:24:31 <ikke> But, the -40 packages should disappear after 4.0.0 is built and published
2022-04-05 12:25:10 <ikke> Locally people would have to upgrade with --available
2022-04-05 12:26:09 <pabloyoyoista> libgweather4 is an option. But my feeling is that alpine tries to avoid it, maybe you can confirm?
2022-04-05 12:26:42 <pabloyoyoista> ikke: so are you suggesting to split the package in a different MR, and then rebuild all the dependent packages?
2022-04-05 12:28:15 <panekj> looking at tags, that release tagged '40.0' looks like a mistake
2022-04-05 12:28:20 <ikke> It's an option, but that means the depending packages are broken for some time until the last MR is merged
2022-04-05 12:29:39 <pabloyoyoista> panekj: most likely. But nothing we can do about it now :(
2022-04-05 12:31:27 <pabloyoyoista> Considering the MR is GNOME 42, and most of the dependent packages have to be updated together, that sounds like an issue
2022-04-05 12:32:26 <panekj> constrain to 4.0.0 and then fix it?
2022-04-05 12:33:04 <pabloyoyoista> panekj: that sounds like a better idea to me! Will try to implement it :)
2022-04-05 12:33:27 <panekj> s/fix it/fix it after MR merge
2022-04-05 12:33:27 <alpine-meetbot> panekj meant to say: constrain to 4.0.0 and then fix it after MR merge?
2022-04-05 12:34:02 <panekj> patching rust + 'vendor/' is a nightmare, eh...
2022-04-05 12:39:03 <Ariadne> we agreed to abandon the openssl 3 upgrade for now
2022-04-05 12:39:43 <Ariadne> i would like to see openssl 3 mature further, we can try it with 3.17 and do it early in 3.17 cycle to help clean up the mess
2022-04-05 12:40:05 <ncopa> well... i'm still curious how far i get...
2022-04-05 12:40:16 <panekj> I agree, although it would be good to weed out packages with issues
2022-04-05 12:40:25 <panekj> and raise those issues upstream
2022-04-05 12:40:47 <ncopa> openssl 3 for v3.16 is still unlikely though
2022-04-05 12:41:09 <panekj> like gnome-shortwave which has last tagged release 11 months ago
2022-04-05 12:48:48 <EvTheFuture> !32757
2022-04-05 12:49:26 <pabloyoyoista> panekj: Your idea seems to have worked! Thanks a lot everybody for the comments :)
2022-04-05 12:51:48 <ikke> pabloyoyoista: There is also the ~ constraint
2022-04-05 12:52:04 <ikke> Then you don't have to pin it on an exact version / release
2022-04-05 12:52:33 <ikke> libgweather-dev=~4
2022-04-05 12:53:38 <pabloyoyoista> Will that pin on 4.x.x instead?
2022-04-05 12:58:18 <panekj> the idea was to pin it temporarily until libgweather=40.0 is gone from edge, then remove the constraint so it would pull 4.x.x
2022-04-05 13:06:17 <panekj> but also, pabloyoyoista, yes, it will grab 4.x
2022-04-05 13:07:33 <pabloyoyoista> That probably makes a bit more sense. But I would like to revert it as soon as possible anyway. So having a specific version is probably a driver too :)
2022-04-05 13:27:01 <ikke> yeah, makes sense
2022-04-05 13:27:21 <ikke> epsecially because it's a -dev dependency
2022-04-05 13:35:51 <Ariadne> anyways
2022-04-05 13:36:11 <Ariadne> if you care about alpine s390x, we need a lot of help with keeping the port going
2022-04-05 13:36:29 <Ariadne> i've asked the tsc to consider whether it should remain qualified as a release architecture
2022-04-05 15:06:13 <skarnet> ncopa: *please* merge my alpine-conf MR before next year ; ;
2022-04-05 15:06:33 <Ariadne> it would indeed be nice to have it
2022-04-05 15:14:36 <ikke> skarnet: before next year.., so you given him permission to postpone it for 3.17? :P
2022-04-05 15:15:56 <skarnet> artistic license
2022-04-05 16:08:17 <Misthios> :)
2022-04-05 16:25:33 <EvTheFuture> :D
2022-04-05 16:27:54 <ncopa> skarnet: the goal is before 3.16 release
2022-04-05 16:29:24 <Ermine> Ah,  tsc meeting is today
2022-04-05 16:30:01 <skarnet> ncopa: well on its own this MR does nothing, it needs a whole change to aports that I have pending and that needs to be tested as well
2022-04-05 16:30:15 <skarnet> but I can't test it before the alpine-conf change is merged
2022-04-05 16:31:05 <skarnet> so if you want things to be ready for 3.16, please don't delay too much because the biggest part of the work depends on it
2022-04-05 16:32:40 <skarnet> (something something I kinda like to test stuff before merging but if it will bypass choke points I will ask for dev rights and yolo merge)
2022-04-05 16:33:12 <ncopa> ok. will try get it merged this week
2022-04-05 16:33:24 <skarnet> thanks
2022-04-05 16:33:35 <panekj> when 3.16 is planned?
2022-04-05 16:34:23 <ncopa> May
2022-04-05 16:34:32 <ncopa> will set up the 3.16 builders asap
2022-04-05 16:35:55 <ncopa> which means we will have a "toolchain freeze", anything that builds other things, gcc, make, automake, cmake, go, rust etc will be feature frozen
2022-04-05 16:50:18 <Ariadne> can we drop s390x :D
2022-04-05 16:50:21 <Ariadne> and move rust to main
2022-04-05 16:54:49 <jvoisin> and move to https://github.com/uutils/coreutils :>
2022-04-05 17:43:00 <Ermine> Sorry for dumb question, but are TSC meetings for members only?
2022-04-05 17:44:22 <ikke> yes, it is. and ftr, it was postponed
2022-04-05 17:46:21 <panekj> while it doesn't explicitly says so, TSC meetings workflow "says" it's for TSC only and community should raise issues via GitLab tracker https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/workflow.md
2022-04-05 19:49:18 <bl4ckb0ne> is it normal that wayland-egl is not available anymore for Qt apps?
2022-04-05 19:49:29 <bl4ckb0ne> >qt.qpa.plugin: Could not find the Qt platform plugin "wayland-egl" in ""
2022-04-05 19:49:40 <bl4ckb0ne> >Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, xcb.
2022-04-05 19:53:14 <panekj> is wayland-libs-egl installed?
2022-04-05 19:55:38 <panekj> qt5-/qt6-wayland has the plugins for wayland-egl, so maybe it's a local issue
2022-04-05 19:57:06 <panekj> s/-wayland/-qtwayland
2022-04-05 19:57:06 <alpine-meetbot> panekj meant to say: qt5-/qt6-qtwayland has the plugins for wayland-egl, so maybe it's a local issue
2022-04-05 20:08:30 <bl4ckb0ne> was indeed missing wayland-libs-egl
2022-04-05 20:08:32 <bl4ckb0ne> thanks
2022-04-05 20:23:37 <Hello71> this stable set seems suspiciously large
2022-04-05 20:23:44 <Hello71> https://lore.kernel.org/lkml/20220405070438.404034032@linuxfoundation.org/
2022-04-05 20:23:55 <Hello71> i bet this is exploitable
2022-04-05 20:24:48 <Hello71> hm, wait, only in 5.17...
2022-04-06 00:17:43 <eddsalkield> Hi all - I'm building a package for some software written in go, which depends on some other (currently unpackaged) libraries in the go ecosystem.  Do we let `go build` handle resolving these, or do I need to package those libraries too?
2022-04-06 01:00:24 <eddsalkield> Also, I've just got the package successfully building, but there's a warning under `Tracing dependencies...`: `>>> ERROR: nwg-bar*: libc.so.6: path not found`
2022-04-06 01:00:51 <eddsalkield> Does anyone have a good idea as to why this might be?
2022-04-06 01:57:17 <sam_> that sounds like it has a bundled binary dynamically linked against glibc
2022-04-06 04:35:12 <ikke> eddsalkield: at the moment for languages like go and rust, we let the tools handle the dependencies
2022-04-06 04:35:25 <ikke> as long as they are locked, but that's now the case for both by default
2022-04-06 04:35:39 <ikke> eddsalkield: you can look at other go tools to see how they are packaged
2022-04-06 05:29:27 <EvTheFuture> !32756
2022-04-06 05:29:50 <EvTheFuture> !32757
2022-04-06 05:30:22 <EvTheFuture> If anyone have the time and energy to take a look, I'd appreciate it :)
2022-04-06 10:51:49 <panekj> is meson broken on edge? data/meson.build:1:0: ERROR: Function does not take positional arguments.
2022-04-06 10:53:34 <ikke> panekj: no
2022-04-06 10:53:45 <ikke> package needs to be fixed
2022-04-06 10:54:05 <ikke> Some template added arguments that never did anything
2022-04-06 10:54:34 <ikke> Now it's no longer accepted
2022-04-06 10:56:00 <panekj> mhm, ok, broken packages are: tau, gnome-podcasts, gnome-authenticator, fractal, apk-polkit-rs
2022-04-06 10:58:00 <ikke> Hmm, what should I do if one dependency needs / wants ffmpeg5 (vtk) and the other uses ffmpeg4 (opencv)
2022-04-06 10:58:43 <panekj> I assume building statically is not an option?
2022-04-06 10:59:05 <panekj> other than that, patch it out to single ffmpeg if possible
2022-04-06 11:00:41 <ikke> It's during build time 
2022-04-06 11:02:59 <eddsalkield> sam_: Thanks for your help - it was indeed a bundled binary that I'd missed
2022-04-06 11:08:48 <panekj> squeekboard fails during mid build https://tpaste.us/X0K8
2022-04-06 11:09:05 <panekj> while fetching deps
2022-04-06 11:09:40 <ikke> panekj: are you using rootbld?>
2022-04-06 11:09:54 <panekj> I'm using dabuild
2022-04-06 11:13:22 <panekj> I did rebuilt all packages from `ap revdep cargo` with CARGO_PROFILE_RELEASE_* to see what builds and whatnot
2022-04-06 11:14:16 <panekj> and only above mentioned packages + cbindgen fail
2022-04-06 11:29:29 <ikke> it should not automatically download dependencies during build
2022-04-06 11:29:58 <ikke> well, cargo / go are an exception
2022-04-06 11:43:26 <psykose> ikke: the buildorder for !32211 looks broken, as if the ordering algorithm only looks at makedepends= and not depends= when defining build order
2022-04-06 11:43:41 <psykose> and not also*
2022-04-06 11:44:34 <panekj> ikke: i know, but I didn't make the package :) it's some weird abomination of meson cat'ting a Cargo.toml.in and doing weird things
2022-04-06 11:44:48 <psykose> it's fine to patch by hand
2022-04-06 11:44:52 <psykose> usually you can find an upstream version
2022-04-06 11:44:57 <psykose> it's just deleting the line
2022-04-06 11:46:18 <panekj> still doesn't change the fact it's terrible
2022-04-06 11:47:49 <panekj> this also goes against the idea of 'fetch deps and build offline'
2022-04-06 11:48:05 <psykose> you can run a cargo fetch after the meson step probably
2022-04-06 11:49:54 <ikke> psykose: can it be that there are cyclic dependencies?
2022-04-06 11:49:59 <ikke> that can mess up the order
2022-04-06 11:50:03 <psykose> ah
2022-04-06 11:50:04 <psykose> could be..
2022-04-06 11:50:08 <psykose> ptrc: you should check that
2022-04-06 11:50:27 <panekj> psykose: it's doing it during build
2022-04-06 11:50:42 <psykose> very fun
2022-04-06 11:50:46 <panekj> I don't get Cargo.toml after first abuild-meson
2022-04-06 12:04:33 <psykose> ikke: doesn't seem to be one so far, and the build itself has some strange output 
2022-04-06 12:04:55 <psykose> https://img.ayaya.dev/5816ymxZu1em the first package doesn't follow the printed order and building is printed twice
2022-04-06 12:05:16 <psykose> wish there was some easy tool to just detect circles
2022-04-06 12:05:33 <psykose> because in python land they go 200 deep
2022-04-06 12:47:23 <psykose> ah, it was probably py3-flit needing pip in makedeps
2022-04-06 12:48:57 <ikke> Oh, did I forget to add it? :)
2022-04-06 12:49:24 <ikke> Can it use py3-installer?
2022-04-06 12:50:10 <psykose> already committed
2022-04-06 12:50:19 <psykose> you didn't forget, it predates us knowing about installer at all
2022-04-06 12:50:59 <ikke> I mean forgot to add py3-pip to makedepends
2022-04-06 12:51:06 <psykose> no, it was there
2022-04-06 12:51:08 <psykose> but that causes the circle
2022-04-06 12:51:19 <psykose> pip needs something, that something needs flit, flit needs pip
2022-04-06 12:51:36 <psykose> now it's just checkdepends so hopefully that works
2022-04-06 12:51:45 <ikke> ok, good. I did try to avoid it
2022-04-06 12:51:57 <ikke> but these things are tricky
2022-04-06 12:52:34 <psykose> yep
2022-04-06 12:52:41 <psykose> but now we know for sure very wheel installs with installer
2022-04-06 12:52:43 <psykose> so we should be okay
2022-04-06 12:59:10 <psykose> ikke: what thing pulls in both opencv and vtk to cause the ffmpeg conflict
2022-04-06 13:00:02 <psykose> i will patch opencv to use 5 too, just need to find the commit
2022-04-06 13:00:04 <psykose> it's already merged
2022-04-06 13:00:18 <ikke> mlt
2022-04-06 13:00:42 <psykose> or well, not really sure what the 'memory leaks' are here https://github.com/opencv/opencv/pull/21754
2022-04-06 13:01:44 <psykose> ah
2022-04-06 13:01:49 <psykose> i think it can just be moved out of depends_dev
2022-04-06 13:01:51 <psykose> perhaps
2022-04-06 13:08:17 <psykose> ah
2022-04-06 13:08:27 <psykose> opencv technically does not even use vtk currently
2022-04-06 13:14:56 <psykose> or does it..
2022-04-06 13:51:55 <psykose> ikke: that didn't fix the issue, but adding py3-flit pkgrel bump to the same mr fixes the order
2022-04-06 13:52:24 <psykose> https://img.ayaya.dev/K1qhXW1TIEp6.png this is the correct one
2022-04-06 13:52:32 <psykose> removing it goes back to https://img.ayaya.dev/rNkHKwV0vK0b.png
2022-04-06 13:52:34 <psykose> i have no idea why
2022-04-06 13:52:55 <psykose> oh actually
2022-04-06 13:52:55 <psykose> hm
2022-04-06 13:53:19 <psykose> mdurl should always be after flit
2022-04-06 13:53:30 <psykose> i think even the checkdepends makes it not work..?
2022-04-06 13:53:42 <psykose> we could remove pip from it entirely and disable the two tests that need it
2022-04-06 13:54:07 <ikke> checkdepends does not break cycles
2022-04-06 13:54:11 <psykose> grr
2022-04-06 13:54:13 <ikke> unless you build without checks
2022-04-06 13:54:32 <psykose> sigh
2022-04-06 13:54:43 <psykose> disable it is
2022-04-06 14:02:48 <psykose> even that seems to not break it
2022-04-06 14:02:58 <psykose> time to draw a graph on paper
2022-04-06 14:05:36 <psykose> oh
2022-04-06 14:06:38 <psykose> py3-flit -> py3-build -> py3-pep517 -> py3-tomli -> (py3-flit/py3-build)
2022-04-06 14:06:48 <psykose> tomli needs to have everything removed
2022-04-06 14:13:44 <psykose> also even directly, py3-flit -> py3-tomli -> py3-flit
2022-04-06 14:14:07 <psykose> so yeah, tomli/tomli-w need to just be installed from pypi wheel
2022-04-06 17:15:33 <ikke> psykose: sorry, I missed your comments re ppsspp
2022-04-06 17:15:52 <psykose> haha
2022-04-06 17:15:57 <psykose> i mean it works, i can start some psp games
2022-04-06 17:16:04 <psykose> but it was not the maintainer doing it :p
2022-04-06 18:22:48 <sam_> eddsalkield: np, happy to help
2022-04-07 05:15:33 <smcavoy> could someone take a look at  !32108 ? thanks
2022-04-07 05:23:18 <Hello71> now is possibly not good time to ask, europeans and most americans are sleeping
2022-04-07 05:23:37 <Hello71> i think it is preferred to use pypi downloads where possible
2022-04-07 06:29:41 <ncopa> good morning!
2022-04-07 06:29:54 <ncopa> is it just me or is busybox build failing during tests nowdays?
2022-04-07 06:31:16 <PureTryOut> Hello71: it doesn't matter much as long as the package includes the same stuff including things like tests
2022-04-07 06:32:24 <smcavoy> thanks 
2022-04-07 08:05:49 <ikke> ncopa: we have been struggling with that
2022-04-07 08:06:19 <ikke> Seems like SIGPIPE is ignored 
2022-04-07 08:06:37 <ikke> We fixed one thing in mqtt-exec, but it still happens 
2022-04-07 08:07:26 <ncopa> happens on my desktop now
2022-04-07 08:08:53 <ikke> Oh, hmm. We only experienced that on the builders 
2022-04-07 08:09:06 <ikke> Is it a failure or hanging? 
2022-04-07 08:21:48 <ncopa> failure in tar
2022-04-07 08:22:12 <ncopa> one seem to be due to sticky bit being set for directory
2022-04-07 08:34:15 <psykose> ikke: !32864 there you go
2022-04-07 08:34:43 <psykose> i looked at the devendoring stuff to see if it was possible to just keep-in more-itertools instead but if everyone actually thinks it's broken then perhaps it's best to not touch it and do this instead
2022-04-07 08:36:36 <psykose> of note, the only things gone are lib2to3ex and ssl_support- only ever seen the former (just mentioning again)
2022-04-07 08:36:59 <psykose> i've seen at least 2 things need 'new setuptools' to remove pip from makedeps so far, probably everything under jaraco too
2022-04-07 08:37:17 <psykose> we could also preemptively move py3-build since that will be needed one day, but there is plenty of time for that
2022-04-07 08:38:52 <psykose> or, well, it really depends what will end up using what backend.. if things in main move to poetry then nothing will save us :p
2022-04-07 08:53:25 <psykose> also this circular order breaking with checkdepends is a little annoying..
2022-04-07 08:53:52 <psykose> because technically with a !check bootstrap everything is fine and there are no real circles, but just because of the thing that generates the order afterwards all the builds are wrong
2022-04-07 08:55:01 <psykose> i suppose it could be 'tweaked' to ignore checkdepends when making an order, at the cost of not picking up new checkdepends in a build.. which would also lead to some specific broken cases i would guess where you would want that
2022-04-07 08:55:06 <psykose> not sure what an actual good solution would be
2022-04-07 08:55:49 <psykose> also meson has like 4 checkdepend circles on it so i bet that will break something at some point, hah
2022-04-07 08:56:25 <psykose> 2 or 3 of them are optional, but the others were hardcoded into the tests, so if that is an issue i will have to go through it again
2022-04-07 09:00:12 <ncopa> busybox test failures: https://tpaste.us/lVyX
2022-04-07 09:01:06 <psykose> what did you change?
2022-04-07 09:01:12 <psykose> (if anything)
2022-04-07 09:01:29 <ncopa> ssl_client. but it also fails without any changes
2022-04-07 09:01:50 <psykose> hmm
2022-04-07 09:02:04 <psykose> they definitely passed before
2022-04-07 09:02:22 <ncopa> yup
2022-04-07 09:02:40 <ncopa> and they pass on my aarch64 laptop
2022-04-07 09:02:58 <psykose> the pidof thing looks strange
2022-04-07 09:03:01 <psykose> and the date also does
2022-04-07 09:03:09 <ncopa> yup. not sure what that is about
2022-04-07 09:03:38 <psykose> maybe there's just something weird in your env? they pass for me on x86_64 like always..
2022-04-07 09:04:20 <ncopa> ncopa-desktop:~/aports/main/busybox/src/build-dynamic/testsuite (master)$ ./runtest -v tar 2>&1 | tpaste
2022-04-07 09:04:20 <ncopa> https://tpaste.us/4o14
2022-04-07 09:04:20 <psykose> pidof could be procps, if they don't call busybox pidof
2022-04-07 09:04:28 <psykose> date could also be something else i think..
2022-04-07 09:04:32 <psykose> but they do call busybox
2022-04-07 09:04:34 <psykose> maybe some tz files
2022-04-07 09:05:46 <ncopa> those i dont worry too much about. The tar failure is what im trying to solve
2022-04-07 09:06:14 <psykose> i think i've seen those before a bunch
2022-04-07 09:06:34 <psykose> something something g+s for some reason that we have in some places..
2022-04-07 09:06:46 <psykose> i don't remember anything about it, though
2022-04-07 09:12:38 <ncopa> weird. now it happens on my remote lxc container too
2022-04-07 09:15:11 <ncopa> and it fails in rootbld
2022-04-07 09:56:18 <psykose> ncopa: also could you look at !32077 !32296
2022-04-07 10:00:02 <ncopa> LGTM
2022-04-07 10:04:26 <psykose> thankies
2022-04-07 10:05:00 <psykose> there is also new python in !32164
2022-04-07 10:05:08 <psykose> i also think there was some python upgrades for release branches..
2022-04-07 10:06:00 <psykose> 3.8.13 for 3.12+3.13 3.9.12 for 3.14+3.15
2022-04-07 11:16:56 <ncopa> anybody wants to take over emacs matinenance?
2022-04-07 11:19:13 <jvoisin> ncopa: a good way to find a maintainer would be to say that vim is better maintained in Alpine :>
2022-04-07 11:23:08 <ktprograms> jvoisin: it probably is given how much simpler vim is :)
2022-04-07 11:24:28 <psykose> ikke: i think i figured it out
2022-04-07 11:24:30 <psykose> but it's quite stupid
2022-04-07 11:24:50 <psykose> ..you need the old py3-setuptools in makedepends
2022-04-07 11:24:54 <psykose> so we need to make a stage0 or something
2022-04-07 11:31:35 <psykose> and fixed
2022-04-07 11:31:42 <psykose> it's not a terrible solution
2022-04-07 11:39:23 <psykose> the bootstrapping means we can 'technically' use the bootstrap in more-itertools, so we don't need installer
2022-04-07 11:40:06 <psykose> but that feels a little weird, using a -stage0 build something else and then the main thing
2022-04-07 11:40:40 <psykose> i.e. setuptools-stage0 -> more-itertools -> setuptools
2022-04-07 11:40:50 <psykose> up to you, though
2022-04-07 11:40:52 <psykose> i think they all work
2022-04-07 13:50:10 <ncopa> perl testsuite fails do to a change in zlib behavior with the recent update. I think we may need to backport this: https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2
2022-04-07 13:50:36 <psykose> looks ok to me
2022-04-07 13:50:58 <psykose> does it fix the tests
2022-04-07 13:51:09 <ncopa> im testing right now
2022-04-07 13:51:29 <ncopa> it looks liek the zlib update uncovers bugs in applications that were previously hidden by zlib
2022-04-07 13:51:54 <ncopa> so we might want let keep the edge zlib be as it is
2022-04-07 13:52:12 <ncopa> and fix the apps that are buggy
2022-04-07 13:52:49 <ncopa> I think this might be the fix for perl: https://github.com/pmqs/Compress-Raw-Zlib/commit/f47ea5f36c40fe19efe404dd75fd790b115de596
2022-04-07 13:53:18 <ncopa> but it does not look good. has conditional based on zlib version
2022-04-07 13:54:33 <ncopa> meaning that if we backport the fix from upstream zlib, next version of perl compress-raw-zlib will fail again
2022-04-07 13:57:11 <ncopa> huh... backporting that commit did not fix perl test suite
2022-04-07 13:57:30 <psykose> maybe there is more than one issue then
2022-04-07 13:57:42 <ncopa> apparently so yes
2022-04-07 13:58:25 <ncopa> not too happy about the behavior change in zlib
2022-04-07 13:58:37 <ncopa> #   Failed test 'inflate returns Z_DATA_ERROR'   
2022-04-07 13:59:42 <ncopa> i think that updating zlib in stable branches might been a mistake
2022-04-07 14:00:00 <ncopa> even if that was the official way to fix the zlib CVE
2022-04-07 14:00:31 <psykose> are you referring to the zlib backport or the perl backport for that test suite
2022-04-07 14:01:19 <ncopa> im referring to the zlib 1.2.12 update 74148808679f47ad96dc99e83ef73acfdeec1642
2022-04-07 14:01:28 <psykose> i mean right now, as you're testing
2022-04-07 14:01:35 <psykose> it's broken and there's two separate backports above
2022-04-07 14:01:47 <psykose> not the upgrade we did
2022-04-07 14:02:52 <ncopa> i havent tested the perl backport yet. only backported the fix for zlib, which seems to be unrelated
2022-04-07 14:03:01 <psykose> ah
2022-04-07 14:03:04 <psykose> ok, that's very not good then
2022-04-07 14:03:24 <ncopa> thats what im trying to say. this is not very good
2022-04-07 14:03:26 <psykose> if zlib alone was fine then it could be one more thing to just add to release branches.. like this it's a bit unclear
2022-04-07 14:03:35 <psykose> welp
2022-04-07 14:04:20 <ncopa> based on https://github.com/pmqs/Compress-Raw-Zlib/commit/f47ea5f36c40fe19efe404dd75fd790b115de596 it seems like zlib returns different err message now
2022-04-07 14:05:16 <ncopa> who knows what else it breaks
2022-04-07 14:06:05 <psykose> maybe.. this? https://github.com/madler/zlib/compare/v1.2.11...v1.2.12#diff-777624c91e0094ce23b8cb9ae77b578bedf2bc9dab3670253db87313df005787R380
2022-04-07 14:06:26 <psykose> but that would be a 'new' error but new is end not error
2022-04-07 14:07:03 <psykose> ah, no line number
2022-04-07 14:07:24 <ncopa>  i just get a list of commits
2022-04-07 14:07:25 <psykose> https://github.com/madler/zlib/commit/90287635ef9ae8e51e120483d1b48789239a0577
2022-04-07 14:08:40 <ncopa> dont think its that one. seems like it now returns Z_STREAM_END when it previously returned Z_DATA_ERROR
2022-04-07 14:09:20 <psykose> yeah
2022-04-07 14:10:23 <psykose> we.. could undo the upgrade, and try to find the specific secfix commit, if it's possible
2022-04-07 14:10:36 <psykose> or we can bisect the two tags and try and figure out why that changed
2022-04-07 14:16:42 <ncopa> i dont think we should undo the upgrade. lets wait a bit and see what breaks
2022-04-07 14:16:56 <ncopa> but we should be aware of it
2022-04-07 14:54:28 <EvTheFuture> Emacs? Woho, cool, nostalgia just entered the room. I haven't been using it since the 90s and back then I used it on SunOS :)
2022-04-07 15:07:30 <skarnet> 
ACTION kicks nostalgia out of the room

2022-04-07 15:07:31 <skarnet> shoo.
2022-04-07 15:22:24 <minimal> skarnet: the future isn't what it used to be? ;-)
2022-04-07 15:22:46 <Habbie> minimal, "here's a picture of when i was younger" "what do you mean - every picture of you is of when you were younger"
2022-04-07 15:26:38 <minimal> Habbie: true, now don't ask me if you can ask me a question ;-) as the answer will be "you just did"
2022-04-07 15:26:49 <Habbie> minimal, can i ask you two questions?
2022-04-07 15:27:37 <ikke> You didn't have permission to ask that question
2022-04-07 15:30:33 <minimal> Habbie: <beep!> you now have one question remaining...
2022-04-07 15:30:44 <Habbie> minimal, ok, first of all,
2022-04-07 15:31:07 <Habbie> minimal, actually i have more of a comment
2022-04-07 16:02:41 <Saijin_Naib> Someone worked in academia 🤣
2022-04-07 16:02:51 <ikke> :D
2022-04-07 16:03:31 <psykose> ikke: could you merge !32866
2022-04-07 16:03:44 <ikke> psykose: yes, was running a build in my lxc container
2022-04-07 16:03:49 <psykose> aha
2022-04-07 16:03:52 <psykose> did so too
2022-04-07 16:03:55 <ikke> aha ok
2022-04-07 16:04:24 <psykose> do you think the setuptools change is fine as well or should i make more-itertools use stage0 instead
2022-04-07 16:04:40 <ikke> was reviewing it
2022-04-07 16:06:43 <psykose> there is !29616 as well
2022-04-07 16:06:57 <psykose> funnily, existing zstd was statically linked, this makes it depend on its own libs
2022-04-07 16:08:35 <ikke> hmm, py3-appdirs depnds on py3-setuptools
2022-04-07 16:08:54 <ikke> and py3-setuptools-stage0 depends on py3-appdirs
2022-04-07 16:09:05 <psykose> it doesn't
2022-04-07 16:09:10 <psykose> https://git.alpinelinux.org/aports/tree/main/py3-appdirs/APKBUILD
2022-04-07 16:09:37 <psykose> setup.py build does not actually imply setuptools, though it does 95% of the time
2022-04-07 16:09:55 <ikke> psykose: sorry, wrong command :P
2022-04-07 16:10:01 <psykose> :p
2022-04-07 16:21:02 <ikke> http://g.jk.gs/QK.png :)
2022-04-07 16:22:38 <psykose> it's beautiful
2022-04-07 16:23:54 <ikke> I think needing py3-installer or something like that in main is a question of time
2022-04-07 16:24:06 <psykose> yeah
2022-04-07 16:24:14 <psykose> one day py3-build will have to move, and that one is going to take more thinking
2022-04-07 16:24:20 <psykose> and the specific backends will be tough
2022-04-07 16:24:30 <ikke> yup
2022-04-07 16:24:55 <ikke> py3-installer is nicely autonomous
2022-04-07 16:25:13 <psykose> mhm
2022-04-07 16:26:03 <ikke> It does depend on distutils?
2022-04-07 16:26:22 <psykose> what does
2022-04-07 16:26:45 <ikke> the py3-installers setup.py imports distutils.core
2022-04-07 16:27:30 <psykose> distutils is from python3
2022-04-07 16:27:44 <psykose> apk info -W /usr/lib/python3.10/distutils/core.py 
2022-04-07 16:27:44 <psykose> /usr/lib/python3.10/distutils/core.py is owned by python3-3.10.3-r0
2022-04-07 16:28:02 <ikke> Right, was verifying that
2022-04-07 16:28:41 <ikke> It's going to be removed in python 3.12
2022-04-07 16:28:54 <ikke> according to the deprecation warning
2022-04-07 16:28:57 <psykose> yeah, but that would mean installer itself needs to change itself
2022-04-07 16:29:15 <psykose> currently the setup.py is generated for the pypi tarball
2022-04-07 16:29:25 <psykose> the github repo has only the pyproject.toml (i think)
2022-04-07 16:29:28 <psykose> so, either something else will come up
2022-04-07 16:29:29 <psykose> oooor
2022-04-07 16:29:37 <psykose> unzip -d "$pkgdir" pypi.whl
2022-04-07 16:29:45 <psykose> but i assume they will figure out something else
2022-04-07 16:29:49 <psykose> it's intended to be low level
2022-04-07 16:29:50 <psykose> shrug
2022-04-07 16:29:56 <psykose> would be weird if you can't bootstrap it easily
2022-04-07 16:30:32 <ikke> Would surprise me
2022-04-07 16:30:34 <psykose> that same distutils deprecation is what will eventually break every setup.py
2022-04-07 16:30:38 <ikke> wouldn't*
2022-04-07 16:30:52 <psykose> which is what makes the move, so it would be weird if the only way to even install anything (py3-installer/pip) cannot be gotten in any way
2022-04-07 16:30:55 <ikke> "Just install it from pypi"
2022-04-07 16:30:58 <psykose> heh
2022-04-07 16:38:02 <Ariadne> just use docker my dude
2022-04-07 16:38:07 <psykose> no
2022-04-07 16:38:10 <Ariadne> install some sketchy base image
2022-04-07 16:38:14 <psykose> yes
2022-04-07 16:38:15 <Ariadne> with a gazillion CVEs
2022-04-07 16:38:52 <ikke> Gotta collect them all
2022-04-07 16:43:02 <ikke> psykose: btw, what is the plan for setuptools >= 60, where it needs things like jaraco-*
2022-04-07 16:43:10 <psykose> i have no clue
2022-04-07 16:43:16 <Ariadne> cry
2022-04-07 16:43:18 <psykose> i assume it will be a slightly more convoluted -stage0 path
2022-04-07 16:43:22 <psykose> but to even move to that
2022-04-07 16:43:27 <psykose> things need to work with 60
2022-04-07 16:43:30 <psykose> afaik everything is just broken
2022-04-07 16:43:52 <psykose> i expect 59 to work for a long time
2022-04-07 16:43:56 <ikke> right
2022-04-07 16:44:07 <ikke> Maybe it makes sense to use the vendored libs then for stage0
2022-04-07 16:44:08 <psykose> it will let me remove py3-pip from a few more things, and then i will clean up the rest of pyproject2setuppy and remove it from aports
2022-04-07 16:45:22 <psykose> anything jaraco complains about <56 or 58 or some shit
2022-04-07 16:50:18 <ikke> Hmm: https://github.com/more-itertools/more-itertools/issues/593
2022-04-07 16:51:40 <ikke> so next release of iter-tools can be built with flit
2022-04-07 16:52:22 <ikke> Would it make sense to backport that so that we do not have to use the pre-built wheel?
2022-04-07 16:52:31 <psykose> flit has a huge dep chain
2022-04-07 16:52:43 <ikke> gentoo says it's trivially covered
2022-04-07 16:52:49 <psykose> maybe i missed something
2022-04-07 16:53:01 <ikke> "One of the interesting options is to use flit as it has much fewer dependencies than setuptools and we've got its bootstrap trivially covered."
2022-04-07 16:53:18 <psykose> it needs build/installer itself, which needs pep517, and then like 30 things
2022-04-07 16:53:28 <psykose> maybe they are doing something special, but in terms of the tree it's very big 
2022-04-07 16:53:54 <psykose> it would be an early py3-build move to main
2022-04-07 16:53:59 <psykose> but i also don't think installing pypi wheel is that bad
2022-04-07 16:56:18 <psykose> hmm
2022-04-07 16:56:20 <psykose> they don't use either
2022-04-07 16:56:23 <psykose> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/flit/flit-3.7.1.ebuild
2022-04-07 16:56:44 <psykose> there's no build/install or any builddeps
2022-04-07 16:56:51 <psykose> ah, core
2022-04-07 16:57:10 <psykose> core has nothing
2022-04-07 16:57:10 <psykose> weird
2022-04-07 16:57:32 <psykose> sadly i can't tell what they really do without reading through 5712383 eclasses, but they seem to be cheating something
2022-04-07 16:58:49 <ikke> If we'd want to use just flit_core for bootstrapping, it would need to be its own package
2022-04-07 16:58:59 <psykose> yeah, i think it should be split at some point
2022-04-07 16:59:04 <psykose> but idk, i think we can think about it later
2022-04-07 16:59:13 <ikke> yu[
2022-04-07 16:59:15 <ikke> yup
2022-04-07 16:59:19 <Habbie> Saijin_Naib, nah, just been to too many conferences :D
2022-04-07 17:01:56 <ikke> psykose: waitin for Sean McAvoy to respond
2022-04-07 17:02:00 <psykose> mhm
2022-04-07 17:13:09 <Saijin_Naib> Habbie: never thought I'd miss that particular ism but I do. It is gold 
2022-04-07 17:13:17 <Habbie> :)
2022-04-07 17:32:37 <smcavoy> the changes !32864 to py3-installer look good to me (updated)
2022-04-07 17:32:49 <ikke> smcavoy: 👍
2022-04-07 17:37:58 <ikke> uboot fails on rv64 due to unrecognized opcodes
2022-04-07 17:48:44 <NbrSBL> Is there a way we could add CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER=m to the edge kernel?
2022-04-07 17:50:09 <psykose> make an issue and tag mps in it
2022-04-07 18:31:07 <ikke> ugh, test failures in ipython 8.2 on certain arches
2022-04-07 18:32:08 <sam_> psykose: I think you only really need to read one eclass
2022-04-07 18:32:24 <psykose> indeed so
2022-04-07 18:32:26 <sam_> psykose: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/distutils-r1.eclass#n81 and beyond
2022-04-07 18:32:37 <psykose> sorry i forgot how to read
2022-04-07 18:32:40 <psykose> could you whisper it to me
2022-04-07 18:32:46 <psykose> :p
2022-04-07 18:33:20 <sam_> i can find more specific bits if needed too, depending on what you need
2022-04-07 18:33:24 <sam_> but pep517 continues to give me a headache
2022-04-07 18:33:50 <psykose> i'm just curious of the exact invocation to build flit
2022-04-07 18:34:00 <ikke> oh, aarch64 and armv7 are still on an older setuptools
2022-04-07 18:34:03 <psykose> we do this, https://git.alpinelinux.org/aports/tree/community/py3-flit/APKBUILD
2022-04-07 18:34:08 <psykose> you can ignore the core part
2022-04-07 18:34:28 <psykose> and py3-build has a quite fat tree- in your case you skip all of this i think
2022-04-07 18:38:31 <psykose> i am not much of a new 517 expert after all :p
2022-04-07 18:42:04 <sam_> so before we'd call it to the relevant backend (give it in the ebuild, flit here) directly, but the logic ended up getting kind of gross to do inline, so now we have https://github.com/gentoo/gentoo/commit/8c7ee2dcb159f0cc1464fdce29fd4dbe86c5e857 / https://github.com/mgorny/gpep517/ (the example at the end of the GH repo helps a fair bit I think)
2022-04-07 18:43:32 <psykose> hm
2022-04-07 18:43:59 <psykose> so basically, instead of py3-build, it's just invoking py3-gpep517 like in the example
2022-04-07 18:44:01 <psykose> and.. it's done
2022-04-07 18:44:21 <psykose> i guess then we can move installer/tomli to main, add gpep517, and do stuff like that
2022-04-07 18:44:33 <psykose> and since we cheat for tomli by just installing from pypi that works
2022-04-07 18:44:36 <psykose> i suppose, that's ok
2022-04-07 19:10:50 <ikke> just armv7 left
2022-04-07 20:52:05 <ikke> takes long 😴
2022-04-07 20:54:57 <psykose> ikke: this seems mildly related to the rv64 opcodes https://lkml.org/lkml/2022/1/24/537
2022-04-07 20:55:27 <psykose> maybe those flags work.. let's see
2022-04-07 20:55:41 <ikke> right
2022-04-07 20:56:34 <psykose> what's our rv64 -march by default
2022-04-07 20:56:36 <psykose> i forgot it again
2022-04-07 20:57:15 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/APKBUILD#L289
2022-04-07 20:57:26 <psykose> ty
2022-04-07 20:59:55 <panekj> rust 1.60 released https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html
2022-04-07 21:01:28 <psykose> !32872
2022-04-07 21:01:39 <panekj> nice :)
2022-04-07 21:01:42 <psykose> i guess i can just merge it
2022-04-07 21:01:46 <psykose> you could try build some stuff with it first
2022-04-07 21:02:17 <panekj> I'm about to do lots of building with rust, so yeah
2022-04-07 21:02:38 <panekj> forgot that testing exists and didn't built it when testing CARGO_PROFILE_RELEASE_*
2022-04-07 21:03:10 <psykose> hehe
2022-04-07 21:03:12 <panekj> s/testing existss/edge-testing exists
2022-04-07 21:03:26 <panekj> i give up
2022-04-07 21:03:27 <psykose> ..did you rebuild all of aports with rust?
2022-04-07 21:03:31 <psykose> for the flags
2022-04-07 21:03:36 <panekj> whole community
2022-04-07 21:03:40 <psykose> neat
2022-04-07 21:03:55 <panekj> took ~6h
2022-04-07 21:05:48 <Ermine> Will you rebuild packages due to musl release? 
2022-04-07 21:06:16 <panekj> me?
2022-04-07 21:06:42 <psykose> no
2022-04-07 21:06:53 <panekj> :(
2022-04-07 21:07:18 <jvoisin> musl, now with securer™ stack canaries!
2022-04-07 21:19:44 <psykose> https://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg611473.html
2022-04-07 21:19:58 <psykose> tis always binutils
2022-04-07 21:27:24 <psykose> adding _zfencei removes fence.i, but csrw remains
2022-04-07 21:27:32 <psykose> and csrs
2022-04-07 21:27:49 <psykose> ah
2022-04-07 21:28:02 <psykose> forgot the other
2022-04-07 21:32:31 <psykose> fixed i think
2022-04-07 21:50:54 <psykose> !32892
2022-04-08 00:07:22 <panekj> psykose: will you merge rust?
2022-04-08 00:07:48 <psykose> did you test that it builds stuff
2022-04-08 00:08:06 <panekj> it builds
2022-04-08 00:08:21 <panekj> does it work? idk :P
2022-04-08 00:08:58 <panekj> mhm, I think it still builds with previous rust
2022-04-08 00:15:33 <psykose> previous?
2022-04-08 00:15:58 <panekj> forget it, will ping you when done, my brain smol and corrupted
2022-04-08 00:16:26 <psykose> just build like 10 bigger things and tell me it's fine
2022-04-08 00:16:47 <panekj> yeah, I need to build rust first
2022-04-08 00:16:55 <psykose> download it from artifacts
2022-04-08 00:36:10 <psykose> do it work
2022-04-08 00:44:17 <psykose> eh, merged anyway
2022-04-08 00:44:21 <psykose> have fun
2022-04-08 00:44:29 <panekj> can't get abuild to cooperate
2022-04-08 00:44:38 <psykose> in what way
2022-04-08 00:44:46 <panekj> or apk idk
2022-04-08 00:44:49 <psykose> show errors
2022-04-08 00:44:53 <panekj> no error
2022-04-08 00:44:58 <panekj> doesn't see 1.60 rust
2022-04-08 00:45:03 <psykose> what are you typing
2022-04-08 00:45:13 <panekj> abuild rootbld
2022-04-08 00:45:22 <psykose> how would it see it from the artifacts
2022-04-08 00:45:24 <panekj> or apk info -X ~/packages/community rust
2022-04-08 00:45:31 <panekj> because I put it there
2022-04-08 00:45:35 <psykose> did you resign the index
2022-04-08 00:45:37 <panekj> yes
2022-04-08 00:45:48 <panekj> it doesn't complain about signature
2022-04-08 00:46:13 <psykose> by default rootbld ignores your local things i think
2022-04-08 00:46:24 <panekj> I put it in .rootbld-repositories
2022-04-08 00:46:31 <panekj> but even apk doesn't see it
2022-04-08 00:46:39 <psykose> shrug
2022-04-08 00:46:47 <psykose> you have to apk index ; first
2022-04-08 00:46:48 <panekj> and I added signing key from ci 
2022-04-08 00:46:50 <psykose> it should work
2022-04-08 00:47:15 <panekj> I already did apk index
2022-04-08 00:47:53 <panekj> empty lol
2022-04-08 00:48:27 <panekj> ah right, it needs packages arg
2022-04-08 00:53:24 <psykose> aye
2022-04-08 00:58:12 <panekj> builds
2022-04-08 00:58:18 <panekj> :D
2022-04-08 01:04:13 <psykose> pog
2022-04-08 06:37:52 <Ariadne> fabled_: thx for getting the musl 1.2.3 upgrade
2022-04-08 06:38:12 <ncopa> +1
2022-04-08 07:01:39 <fabled_> Wondering if we should back port to latest stable. It's mostly bug fixes. Though it has the kernel headers update too...
2022-04-08 07:02:07 <Misthios> ++
2022-04-08 07:04:21 <Misthios> oops
2022-04-08 07:11:00 <ncopa> fabled_: good question. maybe wait a bit and test in edge in case there are regressions?
2022-04-08 07:14:55 <ikke> fabled_: would it be possible to clean up your armv7 container a bit?
2022-04-08 07:15:31 <fabled_> Ikke: you can delete my containers. Have not used them for quite a while.
2022-04-08 07:19:09 <ikke> Ok
2022-04-08 08:35:51 <ncopa> im starting with bootstrapping aports for build-3-16-* now
2022-04-08 08:36:24 <ncopa> starting with s390x 
2022-04-08 08:39:32 <ncopa> hum.. I may need to fix perl build...
2022-04-08 11:08:12 <ncopa> looks like we have a circular dep bison m4 flex something
2022-04-08 11:08:32 <psykose> can you post some output?
2022-04-08 11:08:51 <psykose> bison and flex depend on eachother
2022-04-08 11:08:55 <psykose> but only without bootstrap
2022-04-08 11:09:10 <ncopa> i am bootstrapping aports
2022-04-08 11:09:18 <ncopa> >>> bison: Analyzing dependencies...
2022-04-08 11:09:18 <ncopa>     masked in: cache
2022-04-08 11:09:18 <ncopa>   .makedepends-bison-20220408.105947:
2022-04-08 11:09:18 <ncopa> ERROR: unable to select packages:
2022-04-08 11:09:18 <ncopa>     satisfies: world[.makedepends-bison=20220408.105947]
2022-04-08 11:09:20 <ncopa>   m4 (no such package):
2022-04-08 11:09:20 <ncopa>     required by: .makedepends-bison-20220408.105947[m4]
2022-04-08 11:09:22 <ncopa>   flex (no such package):
2022-04-08 11:09:22 <ncopa>     required by: .makedepends-bison-20220408.105947[flex]
2022-04-08 11:09:24 <ncopa> >>> ERROR: bison: builddeps failed
2022-04-08 11:09:24 <ncopa> >>> bison: Uninstalling dependencies.
2022-04-08 11:09:59 <ikke> ncopa: are you bootstrapping with ABUILD_BOOTSTRAP?
2022-04-08 11:10:09 <psykose> it shouldn't pull flex without abuild_bootstrap
2022-04-08 11:10:18 <ikke> yeah
2022-04-08 11:10:35 <psykose> er, with
2022-04-08 11:14:32 <ncopa> um
2022-04-08 11:14:58 <psykose> flex is in checkdepends but those are ignored with the variable
2022-04-08 11:15:16 <ncopa>  12 checkdepends="bison flex"
2022-04-08 11:15:16 <ncopa>  13 [ -n "$BOOTSTRAP" ] && options="!check"
2022-04-08 11:15:42 <ncopa> but I wonder if it confuses the buildorder calculation
2022-04-08 11:16:11 <ncopa> i think it does not check the options, just blindly adds checkdepends
2022-04-08 11:16:23 <ncopa>   m4 (no such package):
2022-04-08 11:16:23 <ncopa>     required by: .makedepends-bison-20220408.111421[m4]
2022-04-08 11:18:20 <psykose> i'm pretty sure just exporting abuild_bootstrap will fix it
2022-04-08 11:18:46 <ncopa> bison package checks for BOOSTRAP, not ABUILD_BOOTSTRAP
2022-04-08 11:19:17 <psykose> abuild itself skips checkdepends with the latter regardless of what is in the apkbuild
2022-04-08 11:19:23 <psykose> pretty sure
2022-04-08 11:19:38 <ncopa> exporting ABUILD_BOOTSTRAP does not help
2022-04-08 11:19:48 <psykose> hm
2022-04-08 11:20:02 <ncopa> however... exporting BOOTSTRAP did help
2022-04-08 11:20:08 <ncopa> now it builds diffutils
2022-04-08 11:20:26 <ncopa> and m4
2022-04-08 11:20:54 <psykose> strange
2022-04-08 11:23:16 <ncopa> FAIL: test-posix_spawn_file_actions_addclose
2022-04-08 11:23:19 <ncopa> m4 fails
2022-04-08 11:29:13 <ncopa> aha! i think its musl 1.2.3 that triggers it
2022-04-08 11:31:11 <psykose> heh
2022-04-08 11:37:18 <ncopa> i the test may be controversial
2022-04-08 11:37:21 <ncopa> This behaviour is not mandated by POSIX, but happens to pass on all
2022-04-08 11:37:21 <ncopa>      platforms.
2022-04-08 11:39:05 <ncopa> ok its weekend. will get the builders bootstrapped early next week
2022-04-08 11:43:04 <ncopa> if someone wants to help, following up and fixing m4 build may be useful
2022-04-08 11:43:46 <ncopa> i suspect it is a gnulib test, so it might affect more packages
2022-04-08 11:44:04 <ncopa> anyway. have a nice weekend everybody!
2022-04-08 11:47:32 <psykose> you too!
2022-04-08 11:51:01 <psykose> sam_: ah, i see now. everything depends on tomli for bootstrap and gentoo is doing the exact same thing we just changed to, essentially just an unzip (though py3-installer is identical really) from pypi :p
2022-04-08 11:51:05 <psykose> and in 3.11 the issue will solve itself
2022-04-08 11:51:29 <psykose> then it's just the first 517 builder, will look at mgorny's one some other time along with improving flit a bit, and then everything should be fine for us too
2022-04-08 12:18:51 <psykose> ah, another one, py3-flit -> py3-testpath (check) -> py3-flit
2022-04-08 12:22:31 <psykose> slightly improved with py3-flit->py3-flit-core->py3-testpath, with !check on -core, i think
2022-04-08 12:25:40 <psykose> testpath->core *
2022-04-08 12:30:09 <psykose> is there a way to multiline a pytest -k string?
2022-04-08 12:30:43 <psykose> 'not x and not y' works, 'not x\nand not y' doesn't
2022-04-08 12:36:16 <ikke> psykose: my searches proved in vain the last time I looked for it
2022-04-08 12:36:20 <psykose> mhm
2022-04-08 12:36:22 <psykose> i unsplit flit
2022-04-08 12:36:23 <ikke> even extra whitespace broke it
2022-04-08 12:36:33 <ikke> ie, newlines
2022-04-08 12:37:48 <psykose> er, split
2022-04-08 12:37:51 <psykose> and yeah everything breaks it..
2022-04-08 12:38:00 <psykose> wish more things let you just pass more options
2022-04-08 12:38:09 <psykose> they support --deselect being specified more than once
2022-04-08 12:38:17 <psykose> hm, actually..
2022-04-08 12:42:40 <psykose> yeah it only takes the last one, f
2022-04-08 12:45:14 <psykose> is a replaces="py3-flit<3.5.1-r3" valid for something getting bumped from r2 -> r3
2022-04-08 12:45:20 <psykose> i guess there is always the lazy way of no version specifier
2022-04-08 12:45:24 <psykose> anyway, !32926
2022-04-08 12:46:09 <ikke> not sure replaces even takes a version
2022-04-08 12:46:13 <psykose> yeah should be, since -r2 is installed, new -core pulled in while -r2, replaced, then becomes r3
2022-04-08 12:46:15 <psykose> mm
2022-04-08 12:46:16 <psykose> it should..
2022-04-08 12:46:22 <psykose> i did test it and it seemed to not error on upgrade
2022-04-08 12:46:32 <psykose> having -r2 installed, then upgrading with both in local pkgs
2022-04-08 12:46:49 <psykose> let me give it one more try..
2022-04-08 12:46:59 <ikke> ok
2022-04-08 12:47:35 <psykose> https://img.ayaya.dev/omvpTwuN58XZ.png
2022-04-08 12:47:37 <psykose> looks fine
2022-04-08 12:48:02 <psykose> maybe it just ignores the version and considers it anyway, but it works
2022-04-08 12:48:04 <psykose> ok, all good
2022-04-08 12:48:06 <PiRATA> how are mods+sum handled for go packages? Interesting, they are not listed in APKBUILD
2022-04-08 12:48:10 <psykose> they're not
2022-04-08 12:48:18 <psykose> they just download whatever the build downloads
2022-04-08 12:48:31 <psykose> but `go build` by default respects the go.sum/.mod i think
2022-04-08 12:49:03 <psykose> a stray apkbuild explicitly does `go get` in some places, some things have a vendor/ dir and don't download anything (tarball prevendor of all mods)
2022-04-08 12:49:09 <psykose> but we don't have a strict no-network policy yet
2022-04-08 12:49:22 <psykose> if we do, we will probably need to do a `go get` in prepare, like we do with cargo fetch now
2022-04-08 12:50:36 <psykose> ikke: i hope you're enjoying these python adventures :)
2022-04-08 12:50:42 <psykose> but i think python3.11 will make it much easier
2022-04-08 12:51:12 <psykose> then there will be no toml issue anymore, so a clean path will be easy
2022-04-08 12:51:28 <PiRATA> python ports = dependency hell IME :p
2022-04-08 12:53:31 <psykose> it's not really that bad
2022-04-08 12:53:41 <psykose> it's only bad once you have to support a lot of big applications
2022-04-08 12:53:57 <psykose> because then they all want 3 different versions of the same thing
2022-04-08 12:54:04 <psykose> but that applies to basically anything
2022-04-08 12:54:18 <psykose> there's multiple things we have out of date because some shit like libreoffice only wants the ancient versions
2022-04-08 12:54:33 <psykose> and those are just random c libs
2022-04-08 12:54:43 <psykose> such is life in dependency management
2022-04-08 13:02:08 <psykose> sam_: i can't seem to figure out what specifically the flit ebuild runs, with flit_core as the dependency, to build a .whl with no other deps
2022-04-08 13:02:32 <psykose> i.e. removing python3 -m build with whatever it's supposed to be to not have it as the dependency
2022-04-08 13:02:39 <psykose> (assuming i even understand this part right..)
2022-04-08 13:34:12 <psykose> also now done with everything that used pyproject2setuppy, so will be able to drop it once the rest of the things are merged
2022-04-08 13:34:53 <ikke> psykose: I'd make sure that every maintainer agrees with the change
2022-04-08 13:35:00 <psykose> they're all there
2022-04-08 13:35:23 <psykose> in open mrs
2022-04-08 13:35:25 <psykose> :)
2022-04-08 13:35:26 <ikke> ok
2022-04-08 13:40:04 <fcolista> nice job psykose 
2022-04-08 13:40:38 <psykose> thanks!
2022-04-08 13:42:38 <fcolista> the python dependency hell is why i dropped GNS3 
2022-04-08 14:03:37 <bl4ckb0ne> what's going on with dotnet6?
2022-04-08 14:04:10 <psykose> temporarily disabled until it's fixed
2022-04-08 14:04:24 <psykose> something changed in the move to community so one part of it fails to compile, yada yada
2022-04-08 14:04:28 <bl4ckb0ne> waiting on upstream?
2022-04-08 14:04:29 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31451#note_227723
2022-04-08 14:04:34 <psykose> dunno what the actual issue is
2022-04-08 14:04:59 <bl4ckb0ne> welp, i was working on a new aports that uses dotnet6
2022-04-08 14:05:07 <bl4ckb0ne> guess ill find something else to do
2022-04-08 14:05:59 <psykose> if you already had it installed then that should be fine
2022-04-08 14:06:07 <psykose> if you had it in cache just copy it to local repo
2022-04-08 14:06:10 <psykose> if not, well, yeah
2022-04-08 14:06:10 <bl4ckb0ne> somehow gone from my system
2022-04-08 14:06:11 <psykose> sorry
2022-04-08 14:06:14 <psykose> rip
2022-04-08 14:06:16 <bl4ckb0ne> np
2022-04-08 14:06:20 <psykose> i would still check apk cache
2022-04-08 14:06:25 <psykose> since it ignores it if it's not in the index
2022-04-08 14:06:29 <psykose> (if you have it enabled)
2022-04-08 14:06:36 <bl4ckb0ne> goner
2022-04-08 14:06:40 <psykose> unlucky
2022-04-08 14:07:00 <psykose> nice to see people actually use it already though, hah
2022-04-08 14:07:13 <bl4ckb0ne> eh its okay, i have the frontend to package too, its not using dotnet
2022-04-08 14:08:10 <bl4ckb0ne> i have been waiting on dotnet6 for a long time, just to make this package
2022-04-08 14:08:31 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32930 here's the draft
2022-04-08 14:08:41 <psykose> oh
2022-04-08 14:08:41 <psykose> hah
2022-04-08 14:08:45 <Ariadne> it has taken a lot of effort to get there but i am glad to see dotnet on alpine
2022-04-08 14:08:51 <psykose> you don't need the optout
2022-04-08 14:08:55 <psykose> we have optout as default
2022-04-08 14:09:07 <Ariadne> mostly because from a tech perspective, dotnet is really neat :p
2022-04-08 14:09:11 <psykose> indeed
2022-04-08 14:09:25 <psykose> you can also name it dotnet6-dev for makedepends
2022-04-08 14:09:26 <bl4ckb0ne> packaging/bootstrapping looks like a bloody nightmare
2022-04-08 14:09:33 <psykose> and it needs to depend on dotnet6
2022-04-08 14:09:34 <Ariadne> microsoft helped a lot
2022-04-08 14:09:45 <psykose> more like the person doing it got microsoft to help a lot
2022-04-08 14:10:00 <psykose> i don't envy ayakael :p
2022-04-08 14:10:13 <psykose> (aside from microsoft doing musl releases themselves, of course)
2022-04-08 14:10:29 <Ariadne> nah there is a twitter group DM where all of this has been discussed for about a year
2022-04-08 14:10:38 <Ariadne> microsoft has been involved pretty actively
2022-04-08 14:10:41 <psykose> if it's not public it doesn't exist
2022-04-08 14:10:43 <bl4ckb0ne> for the jellyfin frontend, if the source is different, it should be its own aport right?
2022-04-08 14:10:45 <bl4ckb0ne> no subpackage
2022-04-08 14:10:47 <psykose> maybe
2022-04-08 14:10:50 <psykose> probably
2022-04-08 14:10:59 <psykose> we have a bunch of -frontend separate aports already
2022-04-08 14:11:00 <Ariadne> jellyfin on alpine would be great
2022-04-08 14:11:06 <psykose> though idk, i don't think it makes much difference
2022-04-08 14:11:12 <bl4ckb0ne> have it in a podman for now but updating is a pain
2022-04-08 14:11:13 <psykose> if they have matched versions and always need to be bumped together
2022-04-08 14:11:20 <bl4ckb0ne> also 10.8 is supposed to come out soon
2022-04-08 14:12:36 <psykose> grafana and grafana-frontend are separate for instance.. but they always need to be matched, and it's not like you will ever install only the frontend
2022-04-08 14:12:51 <psykose> if the frontend has separate versioning then you need it
2022-04-08 14:15:24 <bl4ckb0ne> same number but different repo
2022-04-08 14:15:35 <bl4ckb0ne> arch does one package
2022-04-08 14:15:45 <Ariadne> one advantage to splitting them is that it allows for more expressive license tracking
2022-04-08 14:15:52 <bl4ckb0ne> but 2 packages sounds safer
2022-04-08 14:16:01 <bl4ckb0ne> saner*
2022-04-08 14:18:13 <minimal> how that smcavoy has gotten the aavmf subpackage (of edk2) built for aarch64 how can that apk be placed into all arch's repos and likewise for the ovmf subpackage (built for x86_64) be placed in the repo for all arches?
2022-04-08 14:18:57 <minimal> If I want to run a aarch64 VM via Qeum on x86_64 I need to install the aavmf package on x86_64 to get the relevant UEFI files
2022-04-08 14:19:03 <psykose> i don't think it's possible is the issue
2022-04-08 14:19:10 <psykose> he thought making it noarch would skip the arch check
2022-04-08 14:19:22 <psykose> but it doesn't, it still only builds on the specific builder
2022-04-08 14:19:28 <psykose> noarch is pretty much meaningless
2022-04-08 14:19:53 <minimal> psykose: no option for post-build to copy the resultant apk into the other arch repos?
2022-04-08 14:20:09 <psykose> if you need to build aavmf from aarch64 only (can't elsewhere) and for it to then be available elsewhere, this is impossible with our builder setup
2022-04-08 14:20:17 <psykose> because the builders are also the mirrors
2022-04-08 14:20:56 <psykose> the 'fix' for this would be to make noarch.. mean something, where one builder that builds it would then make it distributed to everything
2022-04-08 14:21:00 <psykose> but it's not currently the case
2022-04-08 14:21:19 <ikke> the builders are not setup to take packages from other builders
2022-04-08 14:21:22 <psykose> yep
2022-04-08 14:21:29 <psykose> and that would be quite a mess to implement as well
2022-04-08 14:21:38 <psykose> the real solution is to find a way to separate mirrors from builders
2022-04-08 14:21:46 <psykose> then the actual arch logic can just be put on something else
2022-04-08 14:22:15 <psykose> and things with noarch can clearly just apply to anything regardless of where they came from, while still respecting, say, arch="noarch !ppc64le" to make sure 'not that one specifically though'
2022-04-08 14:22:28 <psykose> maybe one day
2022-04-08 14:23:14 <panekj> ms devs did help, doesn't change the fact that dotnet is absolute nightmare to build/package Ariadne 
2022-04-08 14:23:52 <panekj> ms pls get RID of RIDs 
2022-04-08 14:24:41 <panekj> psykose: it's actually `go mod download` :P
2022-04-08 14:24:57 <psykose> yes, it is
2022-04-08 14:25:15 <panekj> at least for packages that have go.mod
2022-04-08 14:28:16 <Ariadne> panekj: yes, total nightmare even with help (btw they are redesigning RIDs from scratch)
2022-04-08 14:28:36 <panekj> I know, I retweeted one of the PRs 
2022-04-08 14:28:50 <panekj> finally they realised
2022-04-08 14:29:07 <Ariadne> that was partially a result of this packaging effort
2022-04-08 15:43:18 <psykose> i think it's broken by new musl
2022-04-08 15:44:01 <Ariadne> what is
2022-04-08 15:44:03 <psykose> specifically https://git.musl-libc.org/cgit/musl/commit/include/locale.h?id=98e688a9da5e7b2925dda17a2d6820dddf1fb287
2022-04-08 15:44:14 <panekj> dotnet i assume
2022-04-08 15:44:17 <Ariadne> o
2022-04-08 15:44:20 <psykose> because of the error 
2022-04-08 15:44:20 <psykose> https://img.ayaya.dev/PhtqYd4fUn7q
2022-04-08 15:44:30 <psykose> nullptr_t memes
2022-04-08 15:44:45 <psykose> let me do a local build..
2022-04-08 15:47:56 <Ariadne> memes
2022-04-08 16:21:05 <skarnet> VeryPracticalVariableName InterlockedCompareExchangePointerT
2022-04-08 16:22:47 <psykose> a revert of that commit fixes the issue
2022-04-08 16:22:59 <psykose> how fortunate
2022-04-08 16:25:38 <Ermine> Yoda-style comparisons there are
2022-04-08 16:42:50 <Hello71> https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/clr-jit-coding-conventions.md "Use the C++11 nullptr keyword when assigning a "null" to a pointer variable, or comparing a pointer variable against "null". Do not use NULL." :thinking:
2022-04-08 16:42:57 <PiRATA> would be cool listing $pkg last release on https://pkgs.alpinelinux.org
2022-04-08 16:43:26 <PiRATA> would be easier to pkg maintainers :p
2022-04-08 16:43:40 <Hello71> also, reinterpret_cast<T*>(intval) is wrong anyways
2022-04-08 16:43:40 <psykose> listing what
2022-04-08 16:43:47 <panekj> what do you mean
2022-04-08 16:44:11 <PiRATA> the last release version
2022-04-08 16:44:31 <panekj> like, upstream?
2022-04-08 16:44:38 <PiRATA> yes
2022-04-08 16:44:48 <psykose> there is already alerting for new versions
2022-04-08 16:45:16 <psykose> but in any case i don't check pkgs.a.o to see if there are new updates for anything i touch, so i'm not sure what the point would be to display that
2022-04-08 16:45:29 <panekj> https://repology.org/ 
2022-04-08 16:45:57 <psykose> repology is fantastic if you want to be recommended the wrong version for every single package for sure
2022-04-08 16:46:04 <ikke> yeah repology kinda already does that, though, it relies on some project alreayd having the latest version
2022-04-08 16:46:05 <panekj> :)
2022-04-08 16:46:18 <panekj> there is also the fedora one but forgot the name
2022-04-08 16:46:26 <PiRATA> sorry, I meant an option to check outdated packages
2022-04-08 16:46:26 <panekj> it's used in alpine pkgs 
2022-04-08 16:46:26 <psykose> there's things marked out of date on it, because a random distro upgraded to a version that doesn't even exist
2022-04-08 16:46:29 <psykose> anitya
2022-04-08 16:46:33 <psykose> release-monitoring.org/
2022-04-08 16:46:36 <panekj> yes anitya
2022-04-08 16:46:38 <psykose> it's what we use already
2022-04-08 16:46:42 <psykose> you get emailed by it
2022-04-08 16:46:51 <psykose> you can make a fedora account to sign into it
2022-04-08 16:46:55 <psykose> and add packages, if you wisnh
2022-04-08 16:46:57 <psykose> wish*
2022-04-08 16:46:59 <panekj> I said, that it's used by alpine pkgs
2022-04-08 16:47:04 <psykose> or map existing ones to alpine
2022-04-08 16:47:12 <panekj> I do that sometimes
2022-04-08 16:47:17 <psykose> PiRATA: there is already an outdated section
2022-04-08 16:47:22 <psykose> it just gets the anitya data
2022-04-08 16:47:23 <PiRATA> https://pkgs.alpinelinux.org/flagged
2022-04-08 16:47:25 <PiRATA> ?
2022-04-08 16:47:26 <psykose> yes
2022-04-08 16:47:29 <psykose> well
2022-04-08 16:47:34 <psykose> it also has a lot of meaningless spam
2022-04-08 16:47:39 <psykose> from people flagging packages to say thanks
2022-04-08 16:47:46 <psykose> or type a single character
2022-04-08 16:47:54 <psykose> https://img.ayaya.dev/SSKf48Cw9VlJ.png
2022-04-08 16:47:57 <psykose> wow, thanks for the message
2022-04-08 16:47:59 <psykose> appreciated
2022-04-08 16:48:00 <psykose> :p
2022-04-08 16:48:04 <psykose> i don't know why we don't just disable this
2022-04-08 16:48:23 <panekj> there is open issue on pkgs.a.o repo
2022-04-08 16:48:37 <PiRATA> ahhh coool, this way is easier to choose a pkg to update :)
2022-04-08 16:49:24 <panekj> https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/issues/40
2022-04-08 16:49:48 <psykose> yeah i'm aware
2022-04-08 16:49:56 <psykose> but nobody works on that, so
2022-04-08 16:50:07 <psykose> may as well not exist :p
2022-04-08 16:50:42 <panekj> btw. cab we close picoro issues in aports
2022-04-08 16:50:48 <panekj> s/cab/can
2022-04-08 16:50:48 <alpine-meetbot> panekj meant to say: btw. can we close picoro issues in aports
2022-04-08 16:50:52 <psykose> what for
2022-04-08 16:51:01 <psykose> smh typical lammers
2022-04-08 16:51:11 <panekj> there are at least 2 which are resolved
2022-04-08 16:51:16 <panekj> and you commented in one
2022-04-08 16:51:40 <panekj> gotta get tickets closed
2022-04-08 16:52:28 <minimal> panekj: I was intended on commenting on the utmp one shortly
2022-04-08 16:53:10 <minimal> s/intended/intending/
2022-04-08 16:53:10 <alpine-meetbot> minimal meant to say: panekj: I was intending on commenting on the utmp one shortly
2022-04-08 16:53:34 <panekj> Go ahead :P
2022-04-08 16:54:33 <panekj> although "collaborating" with piccoro, if I can even call that this way, is nearly impossible
2022-04-08 16:54:44 <psykose> https://github.com/dotnet/runtime/issues/67763
2022-04-08 16:54:47 <psykose> upstream dotnet issue
2022-04-08 16:57:31 <panekj> imo https://gitlab.alpinelinux.org/alpine/aports/-/issues/12736 should be closed
2022-04-08 16:58:37 <psykose> is it fixed in 3.12 3.13 3.14 etc
2022-04-08 16:58:42 <psykose> i can't really tell based on the discussion
2022-04-08 16:59:03 <panekj> yes, I've tested the fix before pushing it
2022-04-08 16:59:14 <psykose> sure
2022-04-08 16:59:19 <psykose> also, what creates that pid file?
2022-04-08 16:59:25 <panekj> lighttpd
2022-04-08 16:59:30 <psykose> hm
2022-04-08 16:59:31 <panekj> it's in lighttpd config
2022-04-08 16:59:32 <psykose> that does not seem correct
2022-04-08 16:59:46 <psykose> because what is in the pid file is what ssd kills on stop
2022-04-08 16:59:57 <psykose> so lighttpd could write `1` into it, then when you stop you crash your computer
2022-04-08 17:00:17 <psykose> things should never make their own pid files, but maybe i'm missing something here
2022-04-08 17:00:36 <panekj> "things should never make their own pid files" huh?
2022-04-08 17:01:11 <panekj> it's first time I hear such thing
2022-04-08 17:01:18 <psykose> https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#pid-files-should-be-writable-only-by-root= this and the next thing
2022-04-08 17:01:22 <psykose> not literally that, but more or less
2022-04-08 17:01:44 <psykose> if it drops privileges then it's fine
2022-04-08 17:01:45 <panekj> "For a well-behaved daemon that backgrounds itself and writes its own PID file by default, the following OpenRC variables are likely all that you'll need:"
2022-04-08 17:02:15 <panekj> it's not wrong to write own pid file
2022-04-08 17:02:27 <panekj> it's only discouraged if it doesn't know how to do it properly
2022-04-08 17:02:28 <psykose> > Some daemons run as an unprivileged user account, and create their PID files (as the unprivileged user) ..
2022-04-08 17:02:30 <psykose> this specifically
2022-04-08 17:02:42 <panekj> yes, but it runs as root now
2022-04-08 17:03:05 <panekj> even though lighttpd creates lighttpd user, it doesn't drop into it
2022-04-08 17:03:22 <psykose> i see
2022-04-08 17:03:28 <panekj> which also is wrong
2022-04-08 17:03:33 <psykose> yes, this is a clusterfuck
2022-04-08 17:03:35 <panekj> but I didn't had time to check that
2022-04-08 17:03:40 <psykose> as is expected for init.d scripts
2022-04-08 17:07:48 <skarnet> "
2022-04-08 17:08:00 <skarnet> a well-behaved daemon that backgrounds itself"
2022-04-08 17:08:03 <skarnet> stopped reading there
2022-04-08 17:08:38 <skarnet> .pid files certainly *should not* be created by the daemon itself, because that's policy
2022-04-08 17:08:54 <skarnet> leave that to the service manager, that's what it's there for
2022-04-08 17:09:18 <skarnet> (and of course ideally there aren't any pid files because every daemon is supervised)
2022-04-08 17:10:40 <panekj> go argue with lighttpd maintainer(s)
2022-04-08 17:15:18 <psykose> if they're as good as lighttpd is then i would rather not
2022-04-08 17:20:05 <Ermine> panekj: I run lighttpd supervised by s6. It can be made to behave
2022-04-08 17:20:28 <panekj> ok?
2022-04-08 17:20:43 <Ermine> it is ok
2022-04-08 17:20:53 <panekj> I never said it doesn't behave
2022-04-08 17:21:11 <panekj> just complaining that service config is big mess
2022-04-08 17:21:21 <panekj> and openrc also big mess
2022-04-08 17:22:07 <skarnet> more news at 11
2022-04-08 17:40:37 <psykose> just make it use supervise-daemon and not write a pidfile
2022-04-08 17:40:37 <psykose> ez
2022-04-08 17:41:24 <panekj> s6 in alpine when
2022-04-08 18:44:25 <skarnet> it's already there
2022-04-08 18:45:05 <skarnet> nothing is stopping people from writing APKBUILDs that make daemons depend on s6 and start them supervised
2022-04-08 18:45:21 <skarnet> people are just choosing not to do it, apparently
2022-04-08 18:45:41 <skarnet> because something something dependencies are bad something something disk image footprint
2022-04-08 20:03:21 <Newbyte> So I'm trying to build mozjs91 for the purpose of upgrading gjs, and I've been making progress. But now I'm hitting this error: `Don't know how to translate x86_64-pc-linux-musl for rustc`. Do you have any ideas?
2022-04-08 20:03:36 <psykose> could you post more error
2022-04-08 20:05:25 <Newbyte> Sure, one moment
2022-04-08 20:05:51 <Newbyte> though, I noticed Void has an open PR where mozjs91 is built for musl so I can look at what they're doing 
2022-04-08 20:06:42 <psykose> it is probably an issue with us having arch-alpine-linux-musl triples
2022-04-08 20:06:51 <Newbyte> https://paste.centos.org/view/4d6757e0
2022-04-08 20:07:02 <Newbyte> here's the full log
2022-04-08 20:07:37 <Newbyte> I'm not sure there's much more useful stuff
2022-04-08 20:09:43 <psykose> perhaps it's hardcoding the -pc- somewhere
2022-04-08 20:09:47 <psykose> shrug
2022-04-08 20:09:57 <psykose> you're also missing some env vars from the firefox build
2022-04-08 20:10:01 <psykose> though that is unrelated
2022-04-08 20:10:02 <Newbyte> like what?
2022-04-08 20:10:22 <Newbyte> I mostly just copied the Arch Linux package 
2022-04-08 20:10:22 <psykose> export MACH_USE_SYSTEM_PYTHON=1 probably
2022-04-08 20:10:35 <Newbyte> I already have that
2022-04-08 20:10:46 <psykose> hm
2022-04-08 20:10:50 <Newbyte> can send the APKBUILD if you want
2022-04-08 20:10:56 <Newbyte> maybe I'm doing something worng 
2022-04-08 20:11:02 <psykose> ah, no, i'm just wrong
2022-04-08 20:11:02 <psykose> :)
2022-04-08 20:11:22 <Newbyte> oh, all right hten
2022-04-08 20:11:26 <Newbyte>  * oh, all right then
2022-04-08 20:12:29 <Newbyte> what do you mean by that perhaps it's hardcoding the -pc- somewhere? should it not be there?
2022-04-08 20:13:20 <psykose> ours is -alpine-
2022-04-08 20:13:26 <Newbyte> Do you think this line could be relevant: https://github.com/void-linux/void-packages/pull/36241/files#diff-1a849ae62c0b6e1c39311f4bfeaff06cf89fee9d1538a5e1524997fd612ec908R43
2022-04-08 20:13:32 <psykose> if it tries to compile something with --target=something-pc then i assume it fails
2022-04-08 20:13:36 <Newbyte> granted, it's using some XBPS variable here
2022-04-08 20:13:46 <Newbyte> (see the highlighted line)
2022-04-08 20:13:47 <psykose> that doesn't link to a line
2022-04-08 20:13:54 <Newbyte> it should
2022-04-08 20:14:16 <Newbyte> line 43 of the template file 
2022-04-08 20:14:50 <psykose> yeah, that looks like it fixes it
2022-04-08 20:14:50 <panekj> tis for cross build though
2022-04-08 20:15:07 <Newbyte> yeah, I realise. but maybe it could be useful still
2022-04-08 20:15:21 <psykose> it is, but if it respects setting host then it would never check for any -pcp
2022-04-08 20:16:12 <bl4ckb0ne> i remember messing around with mozjs for 0ad, iirc that's a rust issue
2022-04-08 20:16:21 <Newbyte> though, they are using configure instead of going through mach 
2022-04-08 20:16:30 <bl4ckb0ne> could be patched by hardcoding the value
2022-04-08 20:16:42 <bl4ckb0ne> i quickly lost interest in it and gave up
2022-04-08 20:16:59 <bl4ckb0ne> i think its somewhere in a python script
2022-04-08 20:17:20 <psykose> mach has the same options somewhere most likely
2022-04-08 20:17:44 <Newbyte> what is the triplet supposed to be? x86_64-alpine-linux-musl?
2022-04-08 20:17:56 <Newbyte> s/x86_64/$arch
2022-04-08 20:17:56 <alpine-meetbot> Newbyte meant to say: what is the triplet supposed to be? $arch-alpine-linux-musl?
2022-04-08 20:18:01 <psykose> CHOST
2022-04-08 20:18:02 <bl4ckb0ne> i think so
2022-04-08 20:18:07 <Newbyte> oh, yeah
2022-04-08 20:18:17 <panekj> https://raw.githubusercontent.com/subnut/void-packages/mozjs91-91.5.0/srcpkgs/mozjs91/patches/014-rust-target.patch
2022-04-08 20:18:38 <psykose> ah, that definitely fixes it
2022-04-08 20:18:46 <Newbyte> nice find
2022-04-08 20:18:48 <psykose> then just pass RUST_TARGET=chost or whatever
2022-04-08 20:19:56 <Newbyte> actually, we already have that patch in mozjs78. so I guess I just need to set that variable
2022-04-08 20:19:56 <panekj> there is also https://raw.githubusercontent.com/subnut/void-packages/mozjs91-91.5.0/srcpkgs/mozjs91/patches/015-drop-rustc-validation.patch
2022-04-08 20:20:38 <bl4ckb0ne> delighful
2022-04-08 20:20:53 <Newbyte> hm, it's already setting RUST_TARGET TO $CTARGET
2022-04-08 20:21:02 <Newbyte> s/TO/to
2022-04-08 20:21:02 <alpine-meetbot> Newbyte meant to say: hm, it's already setting RUST_TARGET to $CTARGET
2022-04-08 20:21:15 <panekj> can you drop apkbuild somewhere?
2022-04-08 20:21:23 <Newbyte> sure, one moment
2022-04-08 20:22:03 <Newbyte> http://0x0.st/ob3X.txt
2022-04-08 20:24:28 <Newbyte> the patches are just copied from mozjs78
2022-04-08 20:39:41 <panekj> it seems to fail when detecting our target triple
2022-04-08 20:45:09 <panekj> uhm
2022-04-08 20:45:10 <panekj> so
2022-04-08 20:45:18 <panekj> why preapre() doesn't have default_prepare
2022-04-08 20:45:24 <psykose> lol
2022-04-08 20:45:28 <panekj> s/preapre()/prepare()
2022-04-08 20:45:28 <alpine-meetbot> panekj meant to say: why prepare() doesn't have default_prepare
2022-04-08 20:45:37 <psykose> none of the patches were applied then
2022-04-08 20:46:05 <panekj> I'm like, why does this detection logic not work, then look at patch, look at source, "huh, the patch was not applied"
2022-04-08 20:48:26 <panekj> I was surprised that you copied the patches from mozjs78 and they all worked *fine*
2022-04-08 20:48:35 <panekj> and turns out they just weren't applied
2022-04-08 20:54:01 <Newbyte> I'll admit I was surprised by that too. That explains it 😅
2022-04-08 20:59:53 <Newbyte> Lo and behold, patches fails. Thanks
2022-04-08 21:01:21 <Newbyte> s/fails/fail
2022-04-08 21:01:21 <alpine-meetbot> Newbyte meant to say: Lo and behold, patches fail. Thanks
2022-04-08 21:58:26 <sam_> psykose: I've just moved home but remind me tomorrow or sunday if I don't look at it tonight, bit stunned atm, then will try figure it out
2022-04-09 07:26:34 <Newbyte> psykose: Could you give an example of how this would look: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32412#note_227903
2022-04-09 07:47:31 <ktprograms> Newbyte: That's fuzzy version matching. So it would be used as dependency=~x.y, which will match any version that starts with x.y
2022-04-09 07:48:41 <Newbyte> So, I'd do clang~$_llvmver?
2022-04-09 07:48:54 <Newbyte> or rather, clang-dev
2022-04-09 07:48:59 <ktprograms> clang=~$_llvmver I think
2022-04-09 07:49:17 <Newbyte> Oh I see, thanks
2022-04-09 08:00:43 <psykose> no = sign, but yeah
2022-04-09 08:00:58 <psykose> sam_: i hope the move went well!
2022-04-09 08:06:31 <ktprograms> psykose: Oh, the wiki says =~ (https://wiki.alpinelinux.org/wiki/Package_management#Holding_a_specific_package_back)
2022-04-09 08:12:25 <ddevault> not sure what's causing the man pages in the aerc package to be broken
2022-04-09 08:12:44 <ddevault> they get installed at /usr/share/man/man1/aerc.1.gz et al, but these files aren't gzipped, and then empty files are installed at /usr/share/man/man1/aerc.1
2022-04-09 08:12:57 <ddevault> the makefile just installs the latter, something else (in abuild?) is mucking about
2022-04-09 08:15:47 <ktprograms> ddevault: The default_doc function is quite complicated and I can't really wrap my head around what all the fina commands are doing: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1849-1901
2022-04-09 08:15:58 <ktprograms> Is it only aerc manpages that are broken?
2022-04-09 08:16:00 <psykose> they work for me
2022-04-09 08:16:32 <psykose> https://img.ayaya.dev/KjemiMSQGBr5.png
2022-04-09 08:16:34 <psykose> seems to be a gzip
2022-04-09 08:16:37 <psykose> and it opens fine
2022-04-09 08:16:52 <ktprograms> Hmm, works for me too
2022-04-09 08:17:07 <psykose> ktprograms: ah, maybe, i don't even remember which one works
2022-04-09 08:17:46 <ktprograms> ddevault: Are you trying these on a custom build? Could it be something to do with the packages you have installed?
2022-04-09 08:19:59 <ddevault> could be
2022-04-09 08:20:11 <ddevault> I'll uninstall it and clean out any lingering files and see if it persists after a reinstall
2022-04-09 08:22:15 <psykose> ikke: i figured out how to build flit without py3-build :) it's a tiny hack, but it's fine to keep in until https://github.com/mgorny/gpep517 is more stable
2022-04-09 08:22:21 <psykose> (and i'm just doing the same thing it is)
2022-04-09 08:22:29 <psykose> surprisingly it's quite easy..
2022-04-09 08:22:46 <psykose> but it's also not terribly important, can just drop it for now, up to you
2022-04-09 08:47:12 <psykose> or i could just package that already, which is a little better
2022-04-09 08:48:52 <ikke> also a possibility, but using what you have now is also fine with me
2022-04-09 08:50:00 <psykose> sure, then it's ready
2022-04-09 08:50:32 <psykose> if gpep517 works as well as i think it will, then it will remove basically the entire py3-build dep chain to build .tomls for things
2022-04-09 08:50:47 <psykose> and flit-core and poetry-core themselves are very low-dep too, so it should be easy
2022-04-09 08:51:03 <psykose> i guess it's nice we preemptively did this work now, will make it easier in a year :)
2022-04-09 08:52:52 <psykose> oh and thanks sam_ for the pointers
2022-04-09 08:52:55 <psykose> much appreciated!
2022-04-09 08:56:13 <ikke> psykose: certainly
2022-04-09 09:07:56 <psykose> shall i press the magic button? :)
2022-04-09 09:09:08 <psykose> also, maybe we should add a pythonispython3 package?
2022-04-09 09:09:16 <psykose> (a python->python3 symlink)
2022-04-09 09:09:30 <psykose> so we stop needing to patch things that call python, when we can just use that instead
2022-04-09 09:09:49 <psykose> python2 is now basically just around for qt6-qtweb and nothing else, and will be removed after, but regardless we don't use python anywhere
2022-04-09 09:10:12 <psykose> and it's also useful for users, since random third party things can call `python` too, so it's a bit easier than them having to make a symlink themselves
2022-04-09 09:13:21 <psykose> basically just this https://img.ayaya.dev/k8hI26RrP2ol
2022-04-09 09:15:25 <psykose> ah, subpkgdir
2022-04-09 09:21:45 <psykose> !32986
2022-04-09 09:22:00 <psykose> maybe in 4.6 months, it may even make it in :)
2022-04-09 09:24:06 <psykose> hm
2022-04-09 09:24:08 <psykose> what is there to work on now
2022-04-09 09:24:26 <ikke> finishing multi-stage builds :P
2022-04-09 09:24:32 <psykose> hey that's your job!
2022-04-09 09:24:35 <psykose> ah
2022-04-09 09:24:39 <ikke> Was worth a try :P
2022-04-09 09:24:41 <psykose> could you backport something for me
2022-04-09 09:24:57 <psykose> 1579acf67a30ecd20f63e588baab94a931b28efd
2022-04-09 09:25:07 <psykose> this i think is what causes our containers to only work with 3.13 ..
2022-04-09 09:25:12 <psykose> for cgit/algitbot
2022-04-09 09:25:20 <psykose> unless i am mistaken and actually it was another issue
2022-04-09 09:25:20 <psykose> h
2022-04-09 09:25:21 <psykose> hm
2022-04-09 09:25:46 <psykose> let me actually look at it for more than 0 seconds
2022-04-09 09:25:49 <ikke> That would give an explicit error when importing mosquitto
2022-04-09 09:26:04 <ikke> see the check that ncopa added
2022-04-09 09:26:06 <psykose> yeah
2022-04-09 09:26:24 <psykose> time for some testing
2022-04-09 09:27:33 <psykose> i don't think they even use mosquitto actually, and they were always 5.3, so it was another issue, but maybe today i will actually figure it out
2022-04-09 09:32:40 <psykose> ah, it pulls in mosquitto as well
2022-04-09 09:32:47 <psykose> 3.13: https://img.ayaya.dev/Jo55gXGpJf2w.png (error is not an error)
2022-04-09 09:32:56 <psykose> 3.15: https://img.ayaya.dev/WPTp6JMIM28W.png
2022-04-09 09:33:07 <psykose> yeah, it's this..
2022-04-09 09:33:37 <ikke> and edge?
2022-04-09 09:34:27 <psykose> sec
2022-04-09 09:35:10 <psykose> the upstream commit was between 0.3 and 0.4.1 (3.15 upgrades lua-mosquitto to the latter), https://github.com/flukso/lua-mosquitto/commit/ec32b23c0ae764610fdfbb41c81da542f3bb81c4
2022-04-09 09:35:12 <psykose> now for edge
2022-04-09 09:35:29 <psykose> https://img.ayaya.dev/v0wpY5vqRJuI.png
2022-04-09 09:35:30 <psykose> works again
2022-04-09 09:35:35 <psykose> so yes, in 3.15-only this broke
2022-04-09 09:35:50 <psykose> 3.14 would still work as it's 0.3, it just went straight back to 3.13 because i crashed algitbot
2022-04-09 09:36:01 <psykose> and i had a <3.15 issue that was probably something else on cgit
2022-04-09 09:36:03 <ikke> Strange that it tries to get the version but the field does not exist
2022-04-09 09:36:07 <psykose> there is none
2022-04-09 09:36:17 <psykose> mqtt.exec doesn't have a version field
2022-04-09 09:36:25 <psykose> i just lazily changed the import
2022-04-09 09:36:35 <ikke> ah ok
2022-04-09 09:36:43 <ikke> so different lib, same error
2022-04-09 09:36:46 <psykose> yep
2022-04-09 09:36:58 <psykose> anything .version fails; they do actually work
2022-04-09 09:37:04 <psykose> the import error for the symbol is the real one
2022-04-09 09:37:08 <psykose> so yes, this needs a 3.15 backport
2022-04-09 09:37:09 <ikke> yes
2022-04-09 09:37:23 <ikke> ncopa asked clandmeter to test it before backporting
2022-04-09 09:37:32 <psykose> i did instead :p
2022-04-09 09:37:38 <psykose> unless you want me to build the patch in 3.15 and test that too
2022-04-09 09:37:57 <ikke> no
2022-04-09 09:40:47 <psykose> !32987
2022-04-09 09:41:09 <psykose> then i can upgrade algitbot to 3.15
2022-04-09 09:41:19 <psykose> as for cgit, groan, i have no clue what breaks in 3.14..
2022-04-09 09:41:44 <psykose> 3.13 works, 3.14+ returns a http 429 if you try and clone anything instantly
2022-04-09 09:41:58 <psykose> via the https://git.a.o clone url
2022-04-09 09:42:14 <psykose> but it's all cgi, i don't think cgit itself does ratelimiting
2022-04-09 09:42:47 <psykose> so maybe some integration between nginx/traefik/deps-inside-cgit broke
2022-04-09 09:42:58 <psykose> the regular git.a.o works, it's only clone that breaks
2022-04-09 10:06:52 <omni> community/ocaml: upgrade to 4.14.0 - https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32594
2022-04-09 10:08:22 <psykose> you did right after i restarted it
2022-04-09 10:08:25 <psykose> like literally 20 seconds after
2022-04-09 10:08:25 <psykose> haha
2022-04-09 10:08:38 <psykose> the timing :p
2022-04-09 10:08:48 <psykose> right uh
2022-04-09 10:08:50 <psykose> i think i tested this
2022-04-09 10:09:00 <psykose> nooot sure if ocaml still built
2022-04-09 10:09:06 <psykose> it didn't crash anymore
2022-04-09 10:09:13 <psykose> but it spent like 9 hours on linking and never finished
2022-04-09 10:09:17 <psykose> for rv64
2022-04-09 10:09:36 <psykose> which is probably some weird qemu thing more than anything, see that sometimes
2022-04-09 10:09:56 <psykose> i could still merge it- rv64 is quite far behind so it will be a while before it gets stuck on this again instead
2022-04-09 10:09:58 <psykose> sure, i'll do that
2022-04-09 10:10:02 <psykose> we'll deal with it when we get there
2022-04-09 10:10:07 <psykose> (and maybe it does pass at some point)
2022-04-09 10:11:08 <psykose> thanks for your work
2022-04-09 10:11:20 <psykose> also didn't even know the ocaml modules need rebuilds, i think all the libs are the same
2022-04-09 10:42:47 <omni> o7
2022-04-09 10:42:58 <omni> not too certain myself...
2022-04-09 10:43:37 <omni> buut.. a good test of the compiler?
2022-04-09 11:02:45 <psykose> perhaps
2022-04-09 12:07:27 <knuxify> i'm planning to make a mr for fixing tests for graphene (as mentioned in !32888); the tests are currently not fully running due to missing mutest
2022-04-09 12:07:48 <knuxify> now, mutest isn't actually packaged yet; in fact, it seems to be mostly intended to be used as a submodule
2022-04-09 12:08:12 <knuxify> (although i could definitely see the potential benefits of packaging it system-wide)
2022-04-09 12:08:26 <knuxify> only issue is, i'd have to add a package directly to main, since graphene is in main too :p
2022-04-09 12:08:36 <knuxify> what would be the best thing to do in this situation?
2022-04-09 12:08:55 <knuxify> (for reference - i'm talking about https://github.com/ebassi/mutest)
2022-04-09 12:09:34 <psykose> imo just submoduling it is fine
2022-04-09 12:14:21 <knuxify> had a quick glance at github search results - it seems to me that graphene is pretty much the only program that uses mutest for tests
2022-04-09 12:14:30 <knuxify> only other program i could find that uses it is https://gitlab.com/goodvibes/goodvibes
2022-04-09 12:15:08 <psykose> damn wish i had some of those good vibes
2022-04-09 18:02:42 <panekj> did dotnet6 build?
2022-04-09 18:04:27 <psykose> just finished
2022-04-09 18:06:34 <panekj> ok, I see, was looking at dotnet6-sdk log but it was dotnet6-build
2022-04-09 18:18:07 <eddsalkield> Do we have to add shared object dependencies to $depends in packages?
2022-04-09 18:18:13 <eddsalkield> This wiki page says not to: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#depends
2022-04-09 18:18:29 <eddsalkield> But the building guide (https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#depends_.26_makedepends) says:
2022-04-09 18:18:39 <eddsalkield> > After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the $depends variable. We do this by using scanelf.
2022-04-09 18:19:18 <psykose> no, scanelf adds .so dependencies itself
2022-04-09 18:20:22 <eddsalkield> Okay great - is the guide page advice left over from when we didn't do this automatically?
2022-04-09 18:20:55 <psykose> yes, and i just deleted it
2022-04-09 18:21:02 <psykose> thanks
2022-04-09 18:21:17 <psykose> also note that doesn't 'always' happen, but those cases are very rare
2022-04-09 18:21:22 <psykose> some things dlopen() random libraries
2022-04-09 18:21:38 <eddsalkield> oh that's kind of nasty
2022-04-09 18:21:47 <eddsalkield> I guess the checks should detect this, when they exist
2022-04-09 18:21:59 <psykose> but most things are just regular DT_NEEDED dynamic linking, so that is fine
2022-04-09 18:23:28 <psykose> could someone merge !32887 for me
2022-04-09 19:33:01 <bl4ckb0ne> wew dotnet6 back
2022-04-09 19:33:12 <bl4ckb0ne> nice work
2022-04-09 19:34:19 <psykose> aye
2022-04-09 19:34:32 <psykose> i might actually try and use jellyfin if you get it in
2022-04-09 19:38:50 <bl4ckb0ne> on it
2022-04-09 19:39:16 <bl4ckb0ne> my time is very limited these days tho, might take a few days
2022-04-09 19:39:28 <bl4ckb0ne> i have that weird runtime issue to take care of
2022-04-09 19:41:11 <psykose> aye
2022-04-09 19:41:15 <psykose> :)
2022-04-09 19:41:16 <psykose> take your time
2022-04-09 19:41:34 <bl4ckb0ne> hu nice sdk issue already
2022-04-09 19:42:17 <psykose> what issue
2022-04-09 19:42:50 <bl4ckb0ne> i have dotnet6-sdk in makedepends but abuild -r complains that no framework is found
2022-04-09 19:43:43 <psykose> can you post some output
2022-04-09 19:43:47 <bl4ckb0ne> hu rootbld works
2022-04-09 19:44:28 <panekj> most likly stalled index on your host
2022-04-09 19:44:41 <panekj> or cache
2022-04-09 19:44:49 <bl4ckb0ne> aye
2022-04-09 19:45:15 <bl4ckb0ne> ran an upgrade -al
2022-04-09 19:47:14 <psykose> pretty sure -l is default
2022-04-09 19:47:23 <bl4ckb0ne> 
ACTION shrugs

2022-04-09 19:49:27 <bl4ckb0ne> The framework 'Microsoft.AspNetCore.App', version '5.0.0' (x64) was not found.
2022-04-09 19:49:30 <bl4ckb0ne>   - The following frameworks were found:
2022-04-09 19:49:32 <bl4ckb0ne>       6.0.3 at [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
2022-04-09 19:49:34 <bl4ckb0ne> hm
2022-04-09 19:50:57 <psykose> that sounds like it needs dotnet5 and not 6
2022-04-09 19:51:13 <bl4ckb0ne> needs 6 to build tho
2022-04-09 19:51:16 <psykose> or, you have both installed, and something breaks
2022-04-09 19:51:39 <psykose> does it get past that with only dotnet6 installed
2022-04-09 19:51:51 <bl4ckb0ne> its at running the install package
2022-04-09 19:51:59 <psykose> the what
2022-04-09 19:52:32 <psykose> are you running master or latest tag?
2022-04-09 19:52:38 <psykose> latest tag explicitly says dotnet5
2022-04-09 19:52:39 <psykose> master is 6
2022-04-09 19:52:47 <psykose> https://github.com/jellyfin/jellyfin/tree/v10.7.7
2022-04-09 19:53:26 <psykose> 10.8 beta is 6 as well
2022-04-09 19:53:36 <psykose> if you want to use 6, the beta is fine
2022-04-09 19:54:08 <bl4ckb0ne> 10.7.7
2022-04-09 19:54:33 <bl4ckb0ne> idk if 10.8 has a release date already
2022-04-09 19:54:43 <psykose> yeah then you need 5
2022-04-09 19:55:23 <psykose> and i mean it's fine to package, doesn't matter if it's not clearly-defined when it releases
2022-04-09 19:55:28 <psykose> idc much for testing/
2022-04-09 19:59:18 <bl4ckb0ne> gah, damn runtimes
2022-04-09 20:01:26 <psykose> the reason i find the beta fine in this case is not-6 will never make it into community/ anyway
2022-04-09 20:01:36 <psykose> so you may as well go straight to the version that uses 6
2022-04-09 20:01:43 <bl4ckb0ne> ack
2022-04-09 20:01:57 <psykose> and maybe you fix some upstream issues in the meantime, always fun :)
2022-04-09 20:06:04 <bl4ckb0ne> should we provide a default config file?
2022-04-09 20:06:14 <panekj> libSystem.IO.Ports.Native.so is missing from dotnet
2022-04-09 20:10:44 <bl4ckb0ne> psykose: im speaking about jellyfin runtimes, there's a folder with bins in there that messes everything up
2022-04-09 20:10:53 <bl4ckb0ne> blocks all arches beside x86_64
2022-04-09 20:11:19 <bl4ckb0ne> cant seems to do without
2022-04-09 20:11:40 <panekj> bins where
2022-04-09 20:12:22 <bl4ckb0ne> in the jellyfin build folder
2022-04-09 20:12:22 <panekj> psykose: do you know if ayakael is on irc/matrix?
2022-04-09 20:12:42 <psykose> isn't
2022-04-09 20:12:46 <psykose> ping him and tell him to get in here
2022-04-09 20:12:58 <psykose> bl4ckb0ne: usually that means they fetched it from the net or something
2022-04-09 20:13:02 <bl4ckb0ne> aye
2022-04-09 20:13:05 <bl4ckb0ne> its a mess
2022-04-09 20:13:09 <psykose> i think in osu, we deleted them, and just.. added a depends=sdl2
2022-04-09 20:13:10 <psykose> or whatever
2022-04-09 20:13:11 <bl4ckb0ne> have to yeet the unused archs by hand
2022-04-09 20:13:12 <psykose> and it finds them anyway
2022-04-09 20:13:22 <bl4ckb0ne> there seems to be a hardcoded path somewhere
2022-04-09 20:13:25 <bl4ckb0ne> works tho
2022-04-09 20:13:32 <bl4ckb0ne> just not very pretty
2022-04-09 20:13:36 <psykose> that can be fixed by making the hardcode uhh
2022-04-09 20:13:42 <psykose> symlink to the usr/lib one
2022-04-09 20:13:56 <psykose> it's very messy for sure, though
2022-04-09 20:14:50 <bl4ckb0ne> https://paste.sr.ht/~bl4ckb0ne/d2d1bf695045e4628899b63c2bb995cc13aec3bb
2022-04-09 20:14:53 <bl4ckb0ne> not very big
2022-04-09 20:15:00 <bl4ckb0ne> i guessi  could file an issue to fix it
2022-04-09 20:15:09 <bl4ckb0ne> do we have skia packaged?
2022-04-09 20:16:58 <panekj> looks like no
2022-04-09 20:24:23 <psykose> we don't split it out from chromium no
2022-04-09 20:24:34 <psykose> i assume they use skia-sharp
2022-04-09 20:24:38 <psykose> which is that + c# bindings
2022-04-09 20:24:53 <panekj> skia seems to have own repo
2022-04-09 20:24:58 <panekj> so we could add it
2022-04-09 20:25:09 <panekj> https://github.com/google/skia
2022-04-09 20:26:36 <bl4ckb0ne> ill make the package first then sort out those shitty runtime bins
2022-04-09 20:32:46 <psykose> i mean the sharp thing is standalone i think
2022-04-09 20:32:51 <psykose> https://github.com/archlinux/svntogit-community/blob/packages/skia-sharp/trunk/PKGBUILD
2022-04-09 20:32:57 <psykose> so you have to find which you want
2022-04-09 20:33:18 <psykose> i would also rather not add more python2 builds..
2022-04-09 20:33:54 <bl4ckb0ne> yikes
2022-04-09 20:34:48 <panekj> https://github.com/mono/SkiaSharp/wiki/Building-on-Linux
2022-04-09 20:34:56 <panekj> https://github.com/mono/skia
2022-04-09 20:35:17 <panekj> if you build managed it will probably pull skia somewhere there
2022-04-09 20:35:24 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32930 first openrc file ive ever written, feedback welcome
2022-04-09 20:36:44 <psykose> i would rather throw supervise-daemon at it, as scuffed as it is
2022-04-09 20:37:02 <bl4ckb0ne> what dod you mean
2022-04-09 20:37:22 <psykose> and with that you need a `checkpath -f -o $command_user /var/log/jellyfin.log` in start_pre(), and an output_log/error_log= to that logfile
2022-04-09 20:37:27 <psykose> uhh just supervisor=supervise-daemon
2022-04-09 20:37:32 <panekj> https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md
2022-04-09 20:37:38 <psykose> and you need to set up users
2022-04-09 20:37:42 <psykose> jellyfin user/group
2022-04-09 20:37:51 <panekj> jellyfin doesn't build into binary?
2022-04-09 20:38:02 <psykose> that is one
2022-04-09 20:38:15 <psykose> you could
2022-04-09 20:38:17 <psykose> make a symlink
2022-04-09 20:38:21 <psykose> usr/bin/jellyfin ->
2022-04-09 20:38:25 <bl4ckb0ne> there's a bin yeah
2022-04-09 20:39:09 <panekj> there is a dll in init file
2022-04-09 20:39:21 <psykose> it's not actually a dll
2022-04-09 20:39:39 <psykose> aside from that, you need pkgusers= pkggroups of jellyfin in the apkbuil
2022-04-09 20:39:50 <psykose> and to install as that owner /var/lib/jellyfin /cache
2022-04-09 20:40:07 <psykose> then you can add command_user=jellyfin:jellyfin into the init.d
2022-04-09 20:40:12 <psykose> and also a post-install to make them
2022-04-09 20:40:18 <psykose> look at like.. testing/soju
2022-04-09 20:40:45 <bl4ckb0ne> i looked at testing/emby
2022-04-09 20:40:51 <bl4ckb0ne> since jellyfin is a fork of emby
2022-04-09 20:40:55 <psykose> soju is probably the ideal reference
2022-04-09 20:41:20 <psykose> emby is passing the user in ssd args instead of just using command_user lol, hah
2022-04-09 20:41:31 <fluix> good to know soju does it right, I used it as a reference recently :)
2022-04-09 20:41:52 <bl4ckb0ne> eh
2022-04-09 20:41:58 <bl4ckb0ne> will look at soju then
2022-04-09 20:42:15 <bl4ckb0ne> so bin in /usr/bin?
2022-04-09 20:42:33 <psykose> assuming that .dll is the actual exe
2022-04-09 20:42:36 <psykose> just.. symlink it
2022-04-09 20:43:02 <psykose> ln -s "$pkgdir"/the/dll /usr/bin/jellyfin
2022-04-09 20:43:04 <psykose> if that works
2022-04-09 20:43:15 <psykose> or well, no, no $pkgdir i think :)
2022-04-09 20:43:20 <psykose> you'll figure it out
2022-04-09 20:43:30 <bl4ckb0ne> there's an exe on its own
2022-04-09 20:43:34 <psykose> ah
2022-04-09 20:43:40 <psykose> is it already in usr bin
2022-04-09 20:44:02 <psykose> fluix: how've you been
2022-04-09 20:44:23 <fluix> alright :)
2022-04-09 20:44:26 <psykose> awesome
2022-04-09 20:44:30 <fluix> seems you've been more and more active here!
2022-04-09 20:44:37 <psykose> something like that
2022-04-09 20:44:40 <psykose> :p
2022-04-09 20:45:05 <panekj> psykose: can i move ncurses-terminfo-base from wezterm depends to wezterm-extra-terminfo depends and then make wezterm depend on that?
2022-04-09 20:45:33 <psykose> replace the install in the subpkg fn with amove, then add a depends=wezterm-extra-terminfo=$pkgver-r$pkgrel into the package()
2022-04-09 20:46:52 <fluix> hm, the thing I copied from soju was hedgedoc, maybe I should make an MR for it
2022-04-09 20:47:02 <fluix> it's https://git.sr.ht/~fluix/mirror.cats.sh-apk/tree/master/item/cats.sh/hedgedoc (now I realize I'm missing pkgusers and pkggroups)
2022-04-09 20:49:05 <fluix> would I make an MR and get feedback there or ask for it here?
2022-04-09 20:49:29 <panekj> if someone gets to checkout your MR they will give feedback on MR
2022-04-09 20:49:41 <panekj> most likely psykose
2022-04-09 20:50:01 <panekj> if your MR wasn't touched in at least a week, you can complain here :P
2022-04-09 20:50:05 <psykose> you only need pkgusers/pkggroups if you use them
2022-04-09 20:50:13 <panekj> psykose: https://tpaste.us/wYYP
2022-04-09 20:50:14 <psykose> i.e. install -o /some/dir
2022-04-09 20:50:30 <psykose> panekj: lgtm
2022-04-09 20:50:36 <psykose> just ensure it installs fine
2022-04-09 20:50:36 <fluix> hm, soju defines them but doesn't use them IIUC
2022-04-09 20:50:45 <psykose> ah, then perhaps it's a little stray
2022-04-09 20:50:52 <psykose> but i mostly meant the init.d
2022-04-09 20:51:24 <fluix> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkggroups seems to say they should be defined anyways as well
2022-04-09 20:51:29 <fluix> and yeah, makes sense
2022-04-09 20:51:32 <psykose> doesn't harm anything anyway!
2022-04-09 20:51:51 <fluix> yep :)
2022-04-09 20:52:10 <fluix> oh and I guess I copied gamja more than soju
2022-04-09 20:52:22 <fluix> specifically the /usr/share/webapps/ part
2022-04-09 21:16:01 <bl4ckb0ne> damn webapp packaging
2022-04-09 21:17:15 <psykose> panekj: you also don't really have to add contributor:
2022-04-09 21:17:27 <panekj> ree
2022-04-09 21:18:16 <panekj> once I'm told to add contributor, sometimes I'm not
2022-04-09 21:18:17 <panekj> smh
2022-04-09 21:18:48 <psykose> it's certainly not consistent
2022-04-09 21:19:00 <psykose> but what i mean is if nobody tells you then you don't :p
2022-04-09 21:20:49 <bl4ckb0ne> anybody has experience packaging npm stuff?
2022-04-09 21:20:57 <bl4ckb0ne> i have a use interaction required for "webpack-cli"
2022-04-09 21:21:12 <psykose> what is required
2022-04-09 21:21:16 <psykose> ah
2022-04-09 21:21:23 <psykose> uhh, there is probably a flag to skip it
2022-04-09 21:21:32 <psykose> or perhaps echoing something into it
2022-04-09 21:21:32 <psykose> etc
2022-04-09 21:21:48 <psykose> usually people release run scripts don't prompt anything
2022-04-09 21:21:51 <psykose> i would have to see what it's doing
2022-04-09 21:22:07 <panekj> you can look at dotnet or ceph
2022-04-09 21:22:10 <panekj> both use npm
2022-04-09 21:22:39 <bl4ckb0ne> arch uses yarn for jellyfin-web but it seems 10.8 is not recommanding it
2022-04-09 21:22:49 <psykose> what do they say
2022-04-09 21:22:54 <psykose> that also shouldn't matter
2022-04-09 21:22:59 <psykose> if something prompts you it's not npm
2022-04-09 21:23:30 <bl4ckb0ne> i think i got a way around
2022-04-09 21:24:38 <bl4ckb0ne> We will use "npm" to install the CLI via "npm install -D webpack-cli".
2022-04-09 21:24:40 <bl4ckb0ne> Do you want to install 'webpack-cli' (yes/no):
2022-04-09 21:24:42 <bl4ckb0ne> prompts me this
2022-04-09 21:24:51 <bl4ckb0ne> ill try to slip the cmd just before building it
2022-04-09 21:24:59 <psykose> all of that sounds wrong
2022-04-09 21:25:11 <bl4ckb0ne> it does
2022-04-09 21:25:13 <bl4ckb0ne> its javascript
2022-04-09 21:25:13 <panekj> it probably depends on webpack-cli to create webpacks
2022-04-09 21:25:22 <panekj> could be packaged i guess
2022-04-09 21:26:00 <psykose> yes | npm i webpack-cli
2022-04-09 21:26:25 <panekj> s/|/||
2022-04-09 21:26:47 <psykose> wha
2022-04-09 21:26:54 <panekj> nevermind :P
2022-04-09 21:33:14 <bl4ckb0ne> ah
2022-04-09 21:33:16 <bl4ckb0ne> gah*
2022-04-09 21:36:25 <psykose> wah*
2022-04-09 21:38:46 <bl4ckb0ne> https://github.com/jellyfin/jellyfin-web/blob/master/scripts/prepare.js turns out theres a skip
2022-04-09 21:57:46 <bl4ckb0ne> woot CI green
2022-04-09 21:57:49 <bl4ckb0ne> now testing
2022-04-09 21:57:53 <bl4ckb0ne> the longest part
2022-04-09 21:58:01 <bl4ckb0ne> ill try to give it a run tonight
2022-04-09 21:59:36 <psykose> i have never seen that algitbot feature
2022-04-09 22:00:28 <bl4ckb0ne> guess im a good boy
2022-04-09 22:03:36 <psykose> very good
2022-04-09 22:03:39 <psykose> *pat*
2022-04-09 22:03:43 <psykose> damn this web thing is huge
2022-04-09 22:03:47 <psykose> 320mb 
2022-04-09 22:03:52 <bl4ckb0ne> aye
2022-04-09 22:04:50 <bl4ckb0ne> also it seems we're the first to mess with 10.8
2022-04-09 22:04:56 <bl4ckb0ne> even the aur -git package is late
2022-04-09 22:05:02 <psykose> ERROR:[1;0m [1;1mjellyfin[1;0m[1;34m*[1;0m: libfontconfig.so.1: path not found
2022-04-09 22:05:12 <psykose> think you need the fontconfig in depends=, or something
2022-04-09 22:05:25 <psykose> (i assume it would try and use it)
2022-04-09 22:06:18 <bl4ckb0ne> huh?
2022-04-09 22:09:30 <panekj> also freetype and ffmpeg
2022-04-09 22:09:44 <psykose> don't they need a custom ffmpeg
2022-04-09 22:09:52 <psykose> if not, it's ffmpeg4
2022-04-09 22:10:20 <bl4ckb0ne> you need it at runtime i think
2022-04-09 22:10:23 <psykose> yes
2022-04-09 22:10:25 <bl4ckb0ne> its optional
2022-04-09 22:10:32 <panekj> https://github.com/jellyfin/jellyfin-ffmpeg
2022-04-09 22:10:35 <psykose> it does not look very optional
2022-04-09 22:10:51 <bl4ckb0ne> ughhhhh its not upstrean ffmpeg
2022-04-09 22:10:56 <psykose> hm, what is happening in this ffmpeg branch
2022-04-09 22:11:03 <panekj> I'm sure standard ffmpeg will work
2022-04-09 22:11:05 <bl4ckb0ne> i guess i have more shit to package
2022-04-09 22:11:45 <psykose> also the jellyfin aur maintainer is someone i see in aports all the time
2022-04-09 22:11:48 <psykose> heh
2022-04-09 22:12:02 <psykose> the aur build just depends on ffmpeg
2022-04-09 22:12:04 <psykose> nothing custom
2022-04-09 22:12:13 <psykose> but 'ffmpeg' is also ffmpeg5 in arch
2022-04-09 22:12:17 <psykose> maybe it's actually wrong
2022-04-09 22:12:21 <psykose> either way test using it and see
2022-04-09 22:18:20 <panekj> liblttng-ust.so.0: path not found
2022-04-09 22:18:21 <panekj> mhm
2022-04-09 22:20:32 <bl4ckb0ne> runtime deps with dotnet is hard
2022-04-09 22:22:59 <psykose> aye
2022-04-09 23:17:58 <Hello71> i think lttng-ust should be caught by dep scanner though?
2022-04-09 23:18:00 <Hello71> also krb5
2022-04-09 23:18:19 <Hello71> afaik it is safe to split to subpackage
2022-04-09 23:18:41 <Hello71> in fact dotnet could probably be split into quite small subpackages
2022-04-09 23:18:54 <panekj> lttng-ust is liblttng-ust.so.1 on edge
2022-04-09 23:19:31 <panekj> coreclr tracept still uses so.0
2022-04-09 23:19:55 <Hello71> hm.
2022-04-10 09:06:03 <omni> PureTryOut: I know how I missed qt5-qtwebengine-5.15.3_git20220406.tar.gz vs qt5-qtwebengine-5.15.3_git20220407.tar.gz, I was on my way out!
2022-04-10 11:38:07 <sdomi> can abuild be somehow forced not to delete the src directory when retrying a failed build?
2022-04-10 11:40:16 <sdomi> nvm, looks like `abuild build` does what I'd like
2022-04-10 11:40:24 <PureTryOut> `abuild -K`
2022-04-10 11:40:35 <PureTryOut> doesn't work in combination with rootbld however
2022-04-10 11:42:19 <sdomi> even better, thanks
2022-04-10 12:45:44 <donoban> sdomi: you can call a bash when the build command fails
2022-04-11 07:44:22 <omni> ncopa: !32655
2022-04-11 07:45:46 <omni> but I also saw 3.15.33 is out and opened !33059
2022-04-11 07:49:37 <ncopa> omni: hi! thank you!
2022-04-11 07:49:43 <ncopa> should also have a look at https://gitlab.alpinelinux.org/alpine/aports/-/issues/13677
2022-04-11 07:50:11 <ncopa> and https://gitlab.alpinelinux.org/alpine/aports/-/issues/13664
2022-04-11 07:50:52 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13680
2022-04-11 07:52:58 <ncopa> and this https://gitlab.alpinelinux.org/alpine/aports/-/issues/13576#note_226631
2022-04-11 07:53:11 <Newbyte> Can you increase the CI timeout for other people's forks of aports? In !32638, the armhf CI only seems to fail because it times out. I would like to have it merged because we need it for GNOME 42, but currently the CI is red.
2022-04-11 07:53:35 <ktprograms> ncopa: Can take a look at my comment: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13677#note_228674
2022-04-11 07:54:13 <ktprograms> I have instructions for fully installing Alpine in Virtualization.framework, just waiting for that to be merged so that manually patching the initramfs-init script isn't necessary.
2022-04-11 09:16:28 <ncopa> ktprograms: how do I test Virtualization.framework? via qemu?
2022-04-11 09:18:18 <panekj> Newbyte: you need to bump timeout in your own forks settings
2022-04-11 09:18:57 <Newbyte> panekj: It wasn't my MR, but it was merged
2022-04-11 09:23:25 <ktprograms> ncopa: Easiest would be to download UTM[0], and follow my draft instructions[1]. [0]: https://github.com/utmapp/UTM/releases/latest [1]: https://tpaste.us/Z44a
2022-04-11 09:23:55 <ktprograms> Qemu doesn't support it (and probably never will as it's much more stripped down)
2022-04-11 09:40:24 <ddevault> _alice: are you psykose?
2022-04-11 09:40:30 <ddevault> no, psykose is psykose
2022-04-11 09:40:41 <ddevault> hey psykose! your py3-jinja2 upgrade caused a regression
2022-04-11 09:41:03 <ddevault> ImportError: cannot import name 'Markup' from 'jinja2' (/usr/lib/python3.10/site-packages/jinja2/__init__.py)
2022-04-11 09:42:42 <ddevault> oh no, that was an upstream issue. sorry for the noise, looked similar to abuild-cased regressions in other python packages I've been working with
2022-04-11 09:42:51 <ddevault> nice of them to deprecate features without bumping the major version number
2022-04-11 09:53:30 <Newbyte> following semver is so hard
2022-04-11 10:00:18 <panekj> gnome software is great at it
2022-04-11 10:27:30 <psykose> hmm, perhaps it should be reverted
2022-04-11 10:28:33 <psykose> alternatively i can forward patch things, but first i have to get out of bed
2022-04-11 10:28:57 <panekj> stay in bed, it's not worth it
2022-04-11 10:29:28 <psykose> but warm hugs are outside bed
2022-04-11 10:29:38 <psykose> brb
2022-04-11 10:32:21 <omni> I went out of bed and survived
2022-04-11 10:46:06 <ncopa> majority of deaths are in bed, so getting out of bed is probably a good idea
2022-04-11 10:51:55 <psykose> ddevault: reverted it for now, sorry for the noise
2022-04-11 10:53:07 <psykose> i /did/ read the damn release notes, but thought 'oh just a deprecated interface, surely nobody is still using this '
2022-04-11 10:53:17 <psykose> > Removed builtin markup class and switched to markupsafe. For backwards compatibility the pure Python implementation still exists but is pulled from markupsafe by the Jinja developers.
2022-04-11 10:53:23 <psykose> this is from _2010_
2022-04-11 10:53:32 <psykose> i really didn't think anything used it anymore..
2022-04-11 10:59:12 <ddevault> psykose: eh, let's keep up with upstream
2022-04-11 10:59:34 <ddevault> there were about 300 days between deprecation notice and actual removal
2022-04-11 10:59:39 <ddevault> having a discussion with upstream about it
2022-04-11 10:59:50 <ddevault> but I don't think alpine should be too opinionated about conflicts with upstream policy
2022-04-11 11:00:52 <ddevault> on my end the solution is to expedite the removal of python from my stack -_-
2022-04-11 11:02:11 <psykose> sure thing, i just reverted it to 'fix' it for the next 5 seconds
2022-04-11 11:02:21 <psykose> now i can go and check all the revdeps and patch/fix/upgrade them
2022-04-11 11:02:25 <psykose> 'properly', in a sense
2022-04-11 11:02:55 <psykose> what thing failed for you
2022-04-11 11:05:04 <psykose> ncopa: ah, do you think many things will fail with this 2.4.7 libtool in the same way?
2022-04-11 11:06:22 <ncopa> i hope not
2022-04-11 11:06:56 <psykose> hmm
2022-04-11 11:07:09 <ncopa> I actually dont think it will
2022-04-11 11:07:22 <psykose> ah
2022-04-11 11:07:28 <psykose> i think libtoolize caused it
2022-04-11 11:07:34 <psykose> if i remove prepare() entirely, it's fixed
2022-04-11 11:07:39 <ncopa> gmp did libtoolize alone, but I think the correct fix is to run full autoconf
2022-04-11 11:07:47 <psykose> actually you can just remove everything
2022-04-11 11:07:54 <ncopa> comment says its needed for crosscompile
2022-04-11 11:08:16 <psykose> ah, right, the libtool is 'vendored' into it
2022-04-11 11:08:24 <psykose> yeah, shouldn't be common
2022-04-11 11:38:07 <indy> psykose, hi, i recall something about wasm + rust, what are dependencies for having wasm in alpine?
2022-04-11 11:41:46 <psykose> building it
2022-04-11 11:42:02 <psykose> not sure if it was possible to have it with the old build system, and i couldn't get rust to build properly with the new one
2022-04-11 11:42:10 <psykose> aside from that, it builds fine
2022-04-11 12:04:05 <indy> old build system means what?
2022-04-11 12:04:29 <indy> how wasm is built?
2022-04-11 12:42:21 <psykose> right now it's ./configure
2022-04-11 12:42:45 <psykose> ah, i think it works with this one too
2022-04-11 12:43:16 <psykose> ncopa: does #13650 even still apply? even the 5.4 3.12 kernel is latest version, but i cannot find any information at all on what versions fixed what for these cves
2022-04-11 12:44:15 <psykose> indy: i will have one more look
2022-04-11 13:00:12 <ncopa> psykose: i have no idea. in my experience security researches does not care at all in what kernel version things are fixed and it can be difficult to find it out
2022-04-11 13:04:58 <psykose> yeah, i tried looking at some kernel release notes and found nothing relevant to the specific subsystems either
2022-04-11 13:13:27 <admin__> Fin
2022-04-11 13:14:17 <admin__> Hello, does anyone know of any good AKPBUILD tutorials online. I am trying to create a package for MongoDB for personal use.
2022-04-11 13:14:52 <ktprograms> admin__: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2022-04-11 13:19:30 <admin__> yeah, been working through that but it's either outdated or is expected to be run from a vm. 
2022-04-11 13:19:55 <panekj> perhaps it would be easier to help you if you tell us your problem
2022-04-11 13:20:28 <admin__> what it doesn't really do is actually help much for those who are new-ish to alpine 
2022-04-11 13:20:46 <psykose> if only you described what issue you ran into so we could fix it
2022-04-11 13:21:47 <psykose> that page is what i used when making an apkbuild the first time, and the setup at the top is completely correct, then the rest is not so great i guess
2022-04-11 13:21:56 <psykose> but one can always use existing apkbuilds as a reference
2022-04-11 13:22:35 <panekj> I used it as well, as except for github/travis part, it's pretty on point
2022-04-11 13:23:23 <panekj> there are also APKBUILD reference and APKBUILD examples linked at the bottom of that wiki page
2022-04-11 13:23:46 <psykose> deleted the travis part
2022-04-11 13:23:50 <admin__> As I sa I have been working through the above. only have got as far as "Getting some help" were it says "A reference for APKBUILD files is available as a man page in the 'abuild-doc' package:"
2022-04-11 13:23:50 <admin__> okay, I'll persevere then sorry I bother you all
2022-04-11 13:24:06 <ktprograms> Eh?
2022-04-11 13:24:46 <panekj> it's not a bother if you tell us which parts exactly you think are lacking
2022-04-11 13:24:52 <psykose> left already
2022-04-11 13:25:43 <ncopa> 3.16 builders fails to build gcc
2022-04-11 13:25:55 <psykose> what's the error
2022-04-11 13:26:00 <ncopa> my edge container also fails to build gcc but different error
2022-04-11 13:26:08 <ncopa> sysinfo.go:6606:7: error: redefinition of 'SYS_SECCOMP'
2022-04-11 13:26:08 <ncopa>       |       ^
2022-04-11 13:26:08 <ncopa>  6606 | const SYS_SECCOMP = _SYS_SECCOMP
2022-04-11 13:26:08 <ncopa> sysinfo.go:6600:7: note: previous definition of 'SYS_SECCOMP' was here
2022-04-11 13:26:08 <ncopa>  6600 | const SYS_SECCOMP = _SYS_seccomp
2022-04-11 13:26:08 <ncopa>       |       ^
2022-04-11 13:26:19 <ncopa> my edge builder fails with:
2022-04-11 13:26:21 <psykose> hmm
2022-04-11 13:26:26 <psykose> more go errors
2022-04-11 13:26:27 <psykose> nice
2022-04-11 13:26:32 <ncopa>  /home/ncopa/aports/main/gcc/src/gcc-11.2.1_git20220219/gcc/config/i386/sse.md:21288:1: internal compiler error: Segmentation fault
2022-04-11 13:26:32 <ncopa> 21288 |   "TARGET_AVX512DQ"
2022-04-11 13:26:32 <ncopa>       | ^
2022-04-11 13:26:46 <psykose> sigh
2022-04-11 13:27:05 <ncopa> indeed
2022-04-11 13:27:53 <psykose> not sure what changed
2022-04-11 13:59:21 <psykose> i get the seccomp one on edge too
2022-04-11 13:59:56 <psykose> https://img.ayaya.dev/zrJp7g1JlKmN.png
2022-04-11 13:59:58 <psykose> why is it duped
2022-04-11 14:34:21 <psykose> indy: think i got it to work
2022-04-11 14:34:27 <psykose> can you give me something to build with it?
2022-04-11 14:34:53 <psykose> that needs a rust wasm32-* target
2022-04-11 14:35:26 <indy> psykose, influxdb2 needs wasm-pack (libflux is written in rust)
2022-04-11 14:35:52 <indy> https://github.com/influxdata/flux
2022-04-11 14:35:58 <psykose> so, wasm-pack then
2022-04-11 14:36:03 <psykose> ok
2022-04-11 14:36:11 <indy> https://github.com/influxdata/flux/tree/master/libflux
2022-04-11 14:36:26 <indy> psykose, yes build fails on wasm-pack
2022-04-11 14:47:19 <psykose> yeah works fine
2022-04-11 14:47:52 <psykose> https://img.ayaya.dev/TJpsY7ZOP0Sy.png
2022-04-11 14:49:35 <psykose> ah, needs whateve rust-lld is
2022-04-11 14:54:58 <psykose> fixed
2022-04-11 14:55:04 <psykose> https://img.ayaya.dev/BeihjAhMqfmR.png
2022-04-11 14:55:06 <psykose> anyway it works
2022-04-11 15:31:50 <indy> psykose, so nothing in way to package influxdb v2 :)
2022-04-11 15:32:09 <psykose> you would have to package wasm-pack first, and i would have to merge this
2022-04-11 15:32:13 <psykose> but sure, then i would guess it would work
2022-04-11 15:32:25 <psykose> assuming this even builds correctly
2022-04-11 15:32:32 <psykose> i bet it will fail half the arches or something dumb
2022-04-11 15:32:39 <indy> that branch is still 'valid' for wasm work?
2022-04-11 15:32:42 <psykose> nope
2022-04-11 15:32:58 <psykose> i'm just rebuilding it a second time, then i will throw it at ci
2022-04-11 15:33:14 <psykose> use the ci artifacts after, assuming everything works..
2022-04-11 15:33:37 <psykose> oh and building wasm-pack needs OPENSSL_NO_VENDOR=1, when you get to it
2022-04-11 15:34:14 <indy> with rust/cargo as it they are in edge?
2022-04-11 15:34:27 <psykose> the new version that will be in ci only
2022-04-11 15:34:29 <indy> ugh, ugly english
2022-04-11 15:34:45 <indy> is possibleto get apks from ci?
2022-04-11 15:34:52 <psykose> yeah
2022-04-11 15:34:58 <psykose> you download artifacts on the right of a ci job
2022-04-11 15:58:30 <psykose> it's in !33100 , if it completes :p
2022-04-11 16:10:42 <Newbyte> psykose: are you familiar with building SpiderMonkey/Firefox? I really don't know what options I should enable/disable
2022-04-11 16:10:55 <psykose> nothing
2022-04-11 16:11:17 <Newbyte> nothing?
2022-04-11 16:11:30 <psykose> you just duplicated the option at the top and also at the bottom
2022-04-11 16:11:36 <psykose> well, technically not for x86
2022-04-11 16:11:46 <psykose> but look at firefox instead of firefox-esr and write it out more like that
2022-04-11 16:11:51 <Newbyte> Yeah. but I was thinking maybe there are some other ones I should change
2022-04-11 16:12:06 <psykose> nah
2022-04-11 16:12:07 <Newbyte> psykose: you mean not using a file and instead using configure?
2022-04-11 16:12:18 <psykose> no, just do it in more blocks
2022-04-11 16:12:31 <psykose> do you want me to commit it for you
2022-04-11 16:12:58 <Newbyte> I think I can manage, but I wouldn't mind 
2022-04-11 16:13:41 <Newbyte> I'm sort of surprised it builds fine with the SIMD option 
2022-04-11 16:13:53 <Newbyte> Maybe it'll bite at runtime instead
2022-04-11 16:18:49 <psykose> it's not enabled on the arches that don't have it, the output is correct
2022-04-11 16:19:16 <Newbyte> but shouldn't it always be given that I set it to enabled in that file?
2022-04-11 16:19:29 <Newbyte> is it just a noop on those arches?
2022-04-11 16:19:36 <psykose> you override it later
2022-04-11 16:19:40 <psykose> it only uses the last option
2022-04-11 16:20:00 <Newbyte> oh, yeah. it adds the disable rust simd option
2022-04-11 16:20:10 <Newbyte> I forgot about that, thanks
2022-04-11 16:20:22 <Newbyte> wouldn't it be fine if I just remove the option from prepare?
2022-04-11 16:20:32 <psykose> ah, pretty sure i overrode one of your commits
2022-04-11 16:20:49 <Newbyte> correct, but it's fine
2022-04-11 16:21:01 <psykose> anyway it's fine now :)
2022-04-11 16:21:05 <psykose> sorry for nitpicking
2022-04-11 16:21:37 <Newbyte> no worries, it's good when things are clear and correct 
2022-04-11 16:22:17 <psykose> re: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32412/diffs?commit_id=91b80822cf241aa7a9f3aa5be6900184f291edc9
2022-04-11 16:22:26 <psykose> that upstream 70-uaccess.rules seems to be in elogind
2022-04-11 16:22:34 <psykose> hm
2022-04-11 16:22:35 <Newbyte> nice, so it can be dropped?
2022-04-11 16:22:39 <psykose> well
2022-04-11 16:22:40 <psykose> not exactly
2022-04-11 16:22:48 <Newbyte> why? 
2022-04-11 16:22:56 <Newbyte> in case someone doesn't use elogind?
2022-04-11 16:23:40 <psykose> we're missing the last two changes from it
2022-04-11 16:23:51 <psykose> both that and id_signal_analyzer
2022-04-11 16:24:00 <psykose> i think these should be part of some other package, but shrug
2022-04-11 16:24:11 <psykose> i think the commit is fine, if the udev rule is needed
2022-04-11 16:25:18 <psykose> there is another thing you could be doing in this mr i think
2022-04-11 16:25:24 <Newbyte> yes?
2022-04-11 16:25:35 <psykose> there is now libsoup3, and i think a lot of these things can recompile against it
2022-04-11 16:25:54 <Newbyte> I've not really looked into the gnome-bluetooth rule since Pablo did that, but he's away for like another week
2022-04-11 16:25:59 <psykose> they couldn't before the upgrades
2022-04-11 16:26:38 <psykose> if they can, just swap libsoup-dev with libsoup3-dev in the upgrade commits
2022-04-11 16:26:42 <Newbyte> that's true. I wasn't sure how widespread use of soup is, so I didn't want to change it
2022-04-11 16:26:54 <Newbyte> oh we have both, ncie
2022-04-11 16:26:58 <alpine-meetbot> Newbyte meant to say: oh we have both, nice
2022-04-11 16:26:58 <Newbyte> s/ncie/nice/
2022-04-11 16:28:22 <Newbyte> I'm not sure I'll do that in this MR. I would like to get around to testing the changes soon so I can mark it as ready for merging. But, I agree it is a good idea
2022-04-11 16:29:27 <Newbyte> I want to make sure this gets in Alpine 3.16, and I'm not sure when that will happen?
2022-04-11 16:30:50 <psykose> a lot of freezing very soon
2022-04-11 16:31:50 <Newbyte> like how soon?
2022-04-11 16:32:12 <Newbyte> are we talking a month or a week?
2022-04-11 16:33:02 <psykose> few weeks at best
2022-04-11 17:00:04 <Newbyte> psykose: not sure how much it matters but you could cancel your pipeline in the MR. seems mine and yours are running in parallel 
2022-04-11 17:04:27 <psykose> indy: adding the ci artifacts, installing wasm-pack, then building stuff works. however, you can't 'make' in flux, because they use some hardcoded build targets https://github.com/influxdata/pkg-config/blob/master/libs/flux/build.go
2022-04-11 17:04:47 <psykose> not sure how to override it, but you can also not use make and find some other way of building flux
2022-04-11 17:05:14 <psykose> you'll figure it out :)
2022-04-11 17:43:11 <indy> psykose, thanks, ill check it, i know about that cargo crippling feature :)
2022-04-11 20:32:56 <Ermine> Are armhf builders alive?
2022-04-11 20:34:54 <psykose> builders yes
2022-04-11 20:34:57 <psykose> ci apparently not
2022-04-11 20:35:09 <psykose> either it crashed somehow or someone is hosting stuff on the ci again
2022-04-11 20:46:27 <Misthios> Hosting on the ci?
2022-04-11 20:47:11 <psykose> some people run jobs on it to host stuff or mine crypto etc
2022-04-11 20:47:28 <psykose> and there's only 2 jobs per arch, so
2022-04-11 20:47:56 <Misthios> Interesting
2022-04-11 21:48:49 <eddsalkield> not sure if this is the right channel for it, but I've been thinking about building a tool/website to quickly compare package build scripts across distros
2022-04-11 21:49:34 <eddsalkield> The idea would be to help deduplicate the work of packaging by leaning on what other distros have already achieved
2022-04-11 21:50:06 <eddsalkield> you'd be able to quickly see what build flags, tools, dependencies etc. were used
2022-04-11 21:50:27 <eddsalkield> right now it seems like a right faff to work out how debian, fedora, void etc. all do it
2022-04-11 21:50:33 <eddsalkield> anyone know of existing work in this area?
2022-04-11 21:50:45 <psykose> i don't know of any (though i look at other distros as a reference)
2022-04-11 21:51:19 <psykose> really the main issue is that while it's easy to look at void templates / arch pkgbuilds / gentoo ebuilds, the apt distros are on some arcane level of hiding their stuff that it takes me 50 years to find them
2022-04-11 21:51:34 <eddsalkield> yeah that's the main one for me as well
2022-04-11 21:51:54 <psykose> afaik for debian you have to find the fork of the upstream project on salsa somewhere, then look at the rules makefile.. which is not easy to read either
2022-04-11 21:52:01 <psykose> it's not a great experience, so i just never do it
2022-04-11 21:52:04 <panekj> thing is, you just go straight into salsa
2022-04-11 21:52:11 <eddsalkield> fedora's build system is also a little arcane
2022-04-11 21:52:21 <psykose> the fedora dnf files are at least more readable than debian
2022-04-11 21:52:27 <eddsalkield> true
2022-04-11 21:53:01 <eddsalkield> would a package script diffing tool be most useful to you as a website, local tool, API, etc?
2022-04-11 21:53:04 <panekj> sounds like a lot of work to figure all that out and write it
2022-04-11 21:53:23 <eddsalkield> panekj: salsa?
2022-04-11 21:53:35 <panekj> salsa.debian.org - debian's gitlab instance
2022-04-11 21:53:55 <panekj> which has gazillions of places where you can look for build scripts
2022-04-11 21:54:27 <psykose> probably a website
2022-04-11 21:54:34 <eddsalkield> iirc there's a central archive of debian source packages
2022-04-11 21:54:41 <psykose> it's that
2022-04-11 21:54:41 <psykose> salsa
2022-04-11 21:54:41 <eddsalkield> the web server could scrape this every so often
2022-04-11 21:54:42 <panekj> with all the love and respect to debian and it's devs, but debians packaging sucks massively
2022-04-11 21:55:09 <panekj> sure, this is possible
2022-04-11 21:55:13 <eddsalkield> honestly mainly it's the ease of understanding and contributing to alpine that's brought me here
2022-04-11 21:55:40 <panekj> just need to write a software that understands each build script and it's deviation/quirks
2022-04-11 21:55:59 <panekj> if it's a local tool, it can be easily turned into API and API into website
2022-04-11 21:56:13 <eddsalkield> some parsing would be good, yeah, but honestly for me just having them all in one place would be useful
2022-04-11 21:56:34 <eddsalkield> mainly wondering whether, if i were to build this, other people would also use it
2022-04-11 21:56:46 <psykose> it would have to be near flawless to be good
2022-04-11 21:56:59 <psykose> well, all i would want to see is all the text files slightly faster than manually googling them
2022-04-11 21:56:59 <panekj> eddsalkield: we sometimes take a peek at other distros
2022-04-11 21:57:07 <psykose> but the issue is that they are sometimes named.. really differently
2022-04-11 21:57:10 <psykose> it's not easy to automate
2022-04-11 21:57:40 <panekj> you would probably need to integrate anitya/repology to figure out packages
2022-04-11 21:57:47 <psykose> and on top of that, you don't get the distro repo tooling with it
2022-04-11 21:57:57 <psykose> if you go to an arch pkgbuild, you can also look at its history in the github ui
2022-04-11 21:58:04 <psykose> that sounds like an insane amount of effort to make something do elsewhere
2022-04-11 21:58:07 <psykose> and its a useful feature
2022-04-11 21:58:19 <psykose> gentoo, void, also have easily-clickable git for the same thing
2022-04-11 21:58:46 <psykose> useful for me to be lazy and see what the new firefox options are :p
2022-04-11 21:58:54 <panekj> arch has semi-easy thing, they have a branch per package
2022-04-11 21:59:37 <eddsalkield> branch per package sounds a little insane at first
2022-04-11 22:00:01 <panekj> it's great when you need to check single package and you have direct link to it
2022-04-11 22:00:18 <panekj> it's not so great when you are *looking* for a package 
2022-04-11 22:00:22 <eddsalkield> i think that for anything more advanced like history tracking, we'd try to leave that to the distro's tooling
2022-04-11 22:00:34 <eddsalkield> a link on the page would take you to the correct place probably
2022-04-11 22:00:46 <eddsalkield> so the site is then kind of like a more accessible index
2022-04-11 22:00:49 <psykose> yeah, that would work
2022-04-11 22:01:03 <psykose> i mean, it's not slow for me already
2022-04-11 22:01:09 <psykose> i haven't optimised the flow much but it's good enough
2022-04-11 22:01:25 <psykose> anything faster would be nice, but it's not a hard requirement, and i do this a hundred times a day
2022-04-11 22:01:50 <eddsalkield> i reckon the linux ecosystem as a whole wastes a lot of time remaking packages that are basically already done by someone else somewhere else
2022-04-11 22:01:51 <panekj> if you're going to work on such thing and it's not going to be some insane language like lisp or C, I might chip in
2022-04-11 22:02:08 <panekj> "i reckon the linux ecosystem as a whole waste"
2022-04-11 22:02:12 <panekj> :)
2022-04-11 22:02:19 <eddsalkield> but yeah sounds like you've got a pretty good workflow anyway
2022-04-11 22:02:38 <eddsalkield> probably in python ngl
2022-04-11 22:02:45 <eddsalkield> it's my go-to "just hack this together" language
2022-04-11 22:02:53 <panekj> it's mostly debian+derivatives that have super inaccessible and completely unreadable package things
2022-04-11 22:04:00 <psykose> the effort is mostly remade because it diverges a lot
2022-04-11 22:04:25 <psykose> we share a lot of similar builds with void/arch (similarly written shell scripts without many default rules), but the actual packaging ecosystem is completely different
2022-04-11 22:04:36 <panekj> I think most distros already take others work if it applies to them
2022-04-11 22:04:40 <psykose> i.e. in arch they make a package
2022-04-11 22:04:45 <psykose> and it just has everything in it
2022-04-11 22:04:58 <psykose> in alpine we split it into like 5 parts, and sometimes actually just build 2 versions of it in the same build
2022-04-11 22:05:05 <psykose> even though otherwise it's the same
2022-04-11 22:05:06 <psykose> etc
2022-04-11 22:05:34 <panekj> I might have found the quickest way to access package repo on salsa
2022-04-11 22:05:40 <psykose> panekj: yeah, i basically copy paste things to maintain firefox, but it works, because everyone builds firefox exactly the same
2022-04-11 22:05:56 <eddsalkield> yeah i agree, it's primarily philosophical differences that mean the package scripts differ
2022-04-11 22:06:10 <eddsalkield> the problem i'm really trying to solve is that, despite this, there's still duplicated work going on
2022-04-11 22:06:20 <panekj> such as?
2022-04-11 22:06:24 <eddsalkield> and honestly we'd all be better off if we saved that time
2022-04-11 22:06:44 <eddsalkield> in terms of the differences, or duplicated work?
2022-04-11 22:06:51 <panekj> duplicated work
2022-04-11 22:07:15 <panekj> iirc, we have gentoo, adelie, chimera, void and probably some other devs in here
2022-04-11 22:07:37 <eddsalkield> learning which compiler flags are good for building what packages, understanding the dependency structure, etc.
2022-04-11 22:07:53 <eddsalkield> these are things that are basically the same across all distros because they depend on the software rather than the distro
2022-04-11 22:08:07 <ptrc> that would also require understanding the default flags for each build system
2022-04-11 22:08:24 <eddsalkield> automating it would, sure
2022-04-11 22:08:43 <panekj> I haven't seen much issues with dep tree and I would say it is different across distros
2022-04-11 22:08:46 <ptrc> and you'd also have to automate updating that
2022-04-11 22:09:12 <ptrc> aaand there's often some sort of abstraction
2022-04-11 22:09:46 <panekj> Seems like people use meson, which is good, python is trash, same for go + other languages with funky stuff
2022-04-11 22:09:56 <ptrc> e.g. abuild-meson or gentoo's ebuild templates(?)
2022-04-11 22:10:21 <panekj> not meson stuff usually tells what it requires or it doesn't require much
2022-04-11 22:11:34 <eddsalkield> might this also help re. packages built with language-specific package managers?
2022-04-11 22:11:47 <eddsalkield> some distros are more rigid on building every dependency as a different package
2022-04-11 22:11:56 <eddsalkield> others are just like "we'll let cargo handle it"
2022-04-11 22:12:04 <panekj> yes
2022-04-11 22:12:08 <eddsalkield> unpicking those dependencies is a right pain
2022-04-11 22:12:47 <eddsalkield> gotta cycle across town now, i'll be back in a bit
2022-04-12 00:25:13 <Hello71> many people have had this idea of standardizing linux packaging across distros. lsb was possibly the first and was certainly the most complete attempt, but there have been others including appstream and listaller
2022-04-12 00:27:12 <Hello71> fundamentally the problem is, as brought up already, different distros have different feature sets, so a "minimum standard" is either excessively restrictive on innovation, or uselessly broad
2022-04-12 00:29:16 <Hello71> the best solution is for upstreams to make their software simple to package, which really means making their software simpler. use dependencies sparingly; avoid overly complex bespoke scripts; avoid automagic in general
2022-04-12 00:30:54 <Hello71> unfortunately the direction we're headed in is docker/flatpak/snap and hiding overcomplicated 20-step packaging procedures by just crapping out a 1 GB binary blob
2022-04-12 00:56:49 <skarnet> flatpak and friends are the exact opposite of a solution
2022-04-12 00:57:08 <skarnet> it's another layer of bloat that goes *against* distros instead of working with them
2022-04-12 01:01:06 <eschwartz> psykose, pabloyoyoista: there are 3 Meson regressions in the gnome module, even after a Debian Developer did a full archive rebuild to test rc1 -- however, one regression just makes gtk4 a dependency for post_install instead of gtk3, and one regression causes gst-build (the gstreamer "build everything recursively" meta-project) to OOM due to inefficiencies 
2022-04-12 01:01:52 <eschwartz> so that's one real regression, and that (and the OOM) if I remember correctly only affect gtk-doc anyway :D
2022-04-12 01:01:59 <psykose> i don't think we use gst-build anywhere, since we package all the gst parts separate
2022-04-12 01:02:09 <psykose> and the former, uh.. can't think of what that affects
2022-04-12 01:02:10 <eschwartz> I mention this in relation to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33118
2022-04-12 01:02:14 <psykose> aye
2022-04-12 01:02:33 <eschwartz> no one uses gst-build other than gstreamer developers on Windows
2022-04-12 01:02:42 <psykose> that's it
2022-04-12 01:02:47 <psykose> alpine is now a windows distro
2022-04-12 01:02:51 <psykose> please fix this bug immediately
2022-04-12 01:03:57 <psykose> is there a fix already for the gnome regressions
2022-04-12 01:04:25 <eschwartz> yes, they're all fixed and tagged for .1
2022-04-12 01:04:48 <psykose> ah, all good then
2022-04-12 01:04:52 <psykose> thanks for the info
2022-04-12 01:05:14 <eschwartz> there is also a fourth bug that happens exclusively if you try to run `meson dist` and use the import('python') module, but it's not like you ever create new dist tarballs during distro packaging...
2022-04-12 01:05:44 <eschwartz> (that too is fixed on master and tagged for .1)
2022-04-12 01:06:34 <eschwartz> it was kind of sad, because after I got debian to test a full archive rebuild and cc me all failing build logs to investigate... I really hoped we'd have a regression-free release
2022-04-12 01:06:36 <eschwartz> SO CLOSE
2022-04-12 01:06:42 <eschwartz> but gnome slays us once again
2022-04-12 01:07:01 <psykose> wishing for the impossible again, eh?
2022-04-12 01:07:03 <eschwartz> https://github.com/mesonbuild/meson/pull/10203#issuecomment-1081380408
2022-04-12 01:07:08 <psykose> we all bargain with the demons sometimes
2022-04-12 01:11:14 <eschwartz> psykose: the gtk4 thing happens because gnome.post_install exists in order to NOT run things if $DESTDIR is set... however it still looks up gtk-update-icon-cache
2022-04-12 01:11:33 <eschwartz> due to a typo, it looked up gtk4-update-icon-cache twice, rather than once and then falling back to the gtk3 version
2022-04-12 01:12:00 <psykose> hah
2022-04-12 01:12:06 <psykose> our gtk- one is gtk2
2022-04-12 01:12:10 <eschwartz> so... if some package HAPPENS to use that, and depends on gtk3 but not gtk4, then you "might" not have gtk4-* installed
2022-04-12 01:12:21 <eschwartz> and it fails the lookup and errors with "program not found"
2022-04-12 01:13:02 <eschwartz> in Arch, the gtk- one is a symlink to the gtk4- one, and both are installed by a split package
2022-04-12 01:13:28 <eschwartz> so the typo would never affect us (and didn't affect my local testing lol)
2022-04-12 01:14:59 <eschwartz> anyway, tl;dr there's like one real regression and it is "gtkdoc might fail"
2022-04-12 01:15:36 <psykose> if you mean the thing named gtk-doc, we didn't even have it until recently and like 2 things use it
2022-04-12 01:15:47 <psykose> ah, no
2022-04-12 01:16:02 <psykose> i was thinking of gi-docgen
2022-04-12 01:17:29 <eschwartz> argh
2022-04-12 01:17:38 <eschwartz> wait never mind
2022-04-12 01:18:24 <eschwartz> the OOM thing is generating gir, that's not the "rea;"
2022-04-12 01:18:29 <eschwartz> "real" regression
2022-04-12 06:21:55 <panekj> skarnet: how so
2022-04-12 06:49:48 <craftyguy> hmm, my syslog-ng patch was assigned to the maintainer, but they haven't been active on gitlab for... 2 years. I'm not hopeful it'll get reviewed by them :/  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33122
2022-04-12 06:56:54 <craftyguy> hmmm it's also quite outdated. it's in "main", is there anything special about taking over maintainership of a package in "main" if it appears to be abandoned like this one?
2022-04-12 08:08:34 <ikke> craftyguy: There is no special procedure for packages in main
2022-04-12 08:08:47 <ikke> craftyguy: perhaps you can send an e-mail to the current maintainer
2022-04-12 10:41:13 <omni> !18234
2022-04-12 12:43:12 <skarnet> panekj: how so what?
2022-04-12 12:43:49 <panekj> "it's another layer of bloat that goes *against* distros instead of working with them"
2022-04-12 12:45:42 <panekj> curious because piccoro said exactly same thing and I don't see how they are working AGAINST distros, what is it they do that it's against
2022-04-12 12:54:35 <skarnet> flatpak and friends, by construction, have to ignore distros' policies and idiosyncrasies and work on a lowest common denominator
2022-04-12 12:54:49 <skarnet> but they still have to provide whatever a distro package does
2022-04-12 12:55:20 <skarnet> so they have to bundle everything the software needs and that would otherwise be provided by a distro, and ignore whatever optimizations distros make
2022-04-12 12:55:37 <skarnet> that's how you get 4 vendored-in copies of a given library
2022-04-12 12:56:04 <skarnet> and a way to start daemons that doesn't integrate at all with how the distros does things
2022-04-12 12:56:12 <panekj> because that's the idea of it? to run software which usually cannot run on a distro because of those libraries
2022-04-12 12:57:31 <skarnet> how about - and hear me out - helping distros package the libraries
2022-04-12 12:57:38 <skarnet> I know, I know, it requires communication, that's hard
2022-04-12 12:57:51 <skarnet> much easier to bundle everything in my own corner and not talk to anyone
2022-04-12 12:58:03 <panekj> it's not only libraries
2022-04-12 12:58:30 <skarnet> in any case it's portability by exhaustivity
2022-04-12 12:58:39 <skarnet> i.e. make stuff portable by adding everything
2022-04-12 12:58:47 <panekj> I have this *very nice* opportunity to run glibc software without actually having glibc system
2022-04-12 12:59:13 <skarnet> and it's what caused the fragmentation of Linux systems in the first place
2022-04-12 12:59:43 <skarnet> "glibc software"
2022-04-12 12:59:45 <panekj> I'm pretty sure Linux was fragmented way before
2022-04-12 12:59:50 <skarnet> not to the same extent
2022-04-12 12:59:56 <skarnet> but I'll have this conversation another day
2022-04-12 13:00:01 <skarnet> (or not at all, if you have mercy)
2022-04-12 15:39:09 <ncopa> py3-sortedcontainers cannot be built. probaly circular dependency
2022-04-12 15:42:22 <ncopa> we need som e tool to test for recurisuve dependencies, which can be executed in our CI
2022-04-12 15:43:22 <ncopa> 22d200bdd79f770409f3a9cde74549008dc30281
2022-04-12 15:44:15 <ncopa> pulls in py3-pygments as a dependency for py3-pytest
2022-04-12 15:44:49 <ncopa> but py3-pygments needs py3-pytest as checkdepends
2022-04-12 15:47:51 <elibrokeit> Sounds like something that's only solvable by bootstrapping without check
2022-04-12 15:51:30 <eddsalkield> would someone be willing to look into merging !33033 ?
2022-04-12 16:03:34 <ncopa> i think we may need to add a flag somehow to packages that needs to be bootstrapped
2022-04-12 16:03:51 <ncopa> then we need to have the builders run twice
2022-04-12 16:04:09 <ncopa> one time with bootstrap enabled, and one time without
2022-04-12 16:12:12 <ncopa> ok im about to give up here
2022-04-12 16:12:19 <ncopa> i dont have time for this :-/
2022-04-12 16:16:17 <ikke> When I have time, I'll take a look 
2022-04-12 16:17:00 <ncopa> i think i may have found it
2022-04-12 16:17:13 <ncopa> we need git
2022-04-12 16:17:22 <ncopa> but git pulls in a zillion deps
2022-04-12 16:17:56 <ikke> Isn't ABUILD_BOOTSTRAP already that? 
2022-04-12 16:18:05 <ncopa> 2ac7079a98676c721dbf115854ea6772f92bd5e1
2022-04-12 16:18:41 <psykose> abuild_bootstrap is what is set on riscv64 and it is !check and does not pull in checkdepends
2022-04-12 16:18:54 <psykose> which is what explicitly caused a lot of cases where builds failed because they actually needed checkdepends
2022-04-12 16:19:03 <psykose> are you completely sure you have !check while bootstrapping these?
2022-04-12 16:19:43 <psykose> the only other sane solution is to outright make them !check and disable the tests forever, because they are very low-level packages
2022-04-12 16:19:53 <ncopa> git unconditionally pulls in libsecret and glib which pulls in meson vala and a lot other stuff
2022-04-12 16:20:01 <psykose> but the reason i turnt it on is because i was explicitly told bootstrapping is done with !check
2022-04-12 16:20:13 <psykose> if it's not, then stuff like pytest has to be !check forever
2022-04-12 16:20:39 <ikke> https://git.alpinelinux.org/aports/tree/main/git/APKBUILD?id=2ac7079a98676c721dbf115854ea6772f92bd5e1#n67
2022-04-12 16:20:46 <ikke> Just BOOTSTRAP 
2022-04-12 16:20:58 <psykose> and in my personal usage of abuild, ABUILD_BOOTSTRAP=1 disables check/checkdepends.. so i'm very confused
2022-04-12 16:21:19 <psykose> (re: pytest, not git)
2022-04-12 16:21:28 <ncopa> this needs to be fixed: https://git.alpinelinux.org/aports/commit/?id=2ac7079a9867
2022-04-12 16:21:44 <psykose> has to be moved to the bootstrap block, yeah
2022-04-12 16:21:47 <ncopa> we should not pull those in when we bootstrap
2022-04-12 16:21:51 <ikke> ncopa: I'll look at that
2022-04-12 16:23:29 <ncopa> i think I have it now
2022-04-12 16:32:48 <ncopa> fixed it. making progress again
2022-04-12 16:33:33 <ncopa> i still think py3-pytest and py3pygments will cause problems later
2022-04-12 16:33:46 <ncopa> which do you build first if none of them exists?
2022-04-12 16:34:19 <ncopa> i think we may need disable tests for py3-pygments
2022-04-12 16:38:08 <psykose> did you read what i wrote above..?
2022-04-12 16:38:14 <psykose> fine, i will just disable the tests
2022-04-12 16:39:24 <ncopa> yeah, sorry.
2022-04-12 16:39:32 <ncopa> > the only other sane solution is to outright make them !check and disable the tests forever, because they are very low-level packages
2022-04-12 16:39:37 <ncopa> yeah
2022-04-12 16:39:56 <ncopa> i think that is what I would prefer. disable tests for things that introduces circular deps
2022-04-12 16:41:45 <psykose> yes, but is it not the case that bootstrapping is !check?
2022-04-12 16:41:54 <psykose> ikke said it's always done with ABUILD_BOOTSTRAP=1 as well
2022-04-12 16:42:00 <psykose> which would disable all the checkdepends
2022-04-12 16:47:26 <ncopa> i dont want disable checks unless needed
2022-04-12 16:53:46 <ikke> We could add [ -z "$BOOTSTRAP" ] && options="$options !check" 
2022-04-12 17:03:20 <psykose> i suppose i have to disable the meson tests again then, groan
2022-04-12 17:05:03 <psykose> unless a -z bootstrap would be fine
2022-04-12 17:46:22 <omni> !32026
2022-04-12 18:34:56 <ncopa> sigh...
2022-04-12 18:35:37 <ikke> ncopa: what's on your mind
2022-04-12 18:35:51 <ncopa> commit b00d1b1662c70650d1b91e300b4111f09ef70655 broke bootstrap. did disable the tests by default, but not when bootstrap
2022-04-12 18:36:03 <ncopa> but now tests fails ofc
2022-04-12 18:36:35 <ncopa> $ git diff | tpaste
2022-04-12 18:36:35 <ncopa> https://tpaste.us/KeeY
2022-04-12 18:37:39 <ncopa> i thikn im gonna push it anyway
2022-04-12 18:39:51 <psykose> looks fine to me
2022-04-12 18:40:11 <ncopa> except that the tests fails with recent util-linux
2022-04-12 18:40:31 <ncopa> nobody noticed due to tests were effectively disabled in b00d1b1662c70650d1b91e300b4111f09ef70655
2022-04-12 18:40:37 <ncopa> did opposite of the intention
2022-04-12 18:41:01 <psykose> i mean the changes
2022-04-12 18:41:17 <psykose> i too read -z as the opposite at first :p
2022-04-12 18:41:20 <psykose> easy mistake to make
2022-04-12 18:41:29 <psykose> probably because it's backwards
2022-04-12 18:41:58 <psykose> idk why it's not -n bootstrap instead, to make it `if bootstrap; else` instead of `if not bootstrap; else`
2022-04-12 18:42:11 <ncopa> yup
2022-04-12 18:42:13 <ncopa> agree
2022-04-12 18:42:24 <ncopa> its backwards
2022-04-12 18:42:36 <psykose> even ikke above got it backwards an hour ago: <ikke> We could add [ -z "$BOOTSTRAP" ] && options="$options !check"
2022-04-12 18:42:52 <ncopa> :)
2022-04-12 18:43:25 <ncopa> so, i pushed it but tests fails now. anybody have time and energy to debug the failing tests and report upstream?
2022-04-12 18:43:34 <psykose> let's see..
2022-04-12 18:44:06 <ncopa> feel free to also swap it to if [ -n "$BOOTSTRAP" ] ...
2022-04-12 18:46:47 <ikke> Maybe add a helper :-p
2022-04-12 18:47:57 <ikke> bootstrapping && options="$options !check" 
2022-04-12 18:53:13 <psykose> 2.37 passes all its tests
2022-04-12 18:53:17 <psykose> grr
2022-04-12 18:53:22 <psykose> i wish they said anything other than 'failed'
2022-04-12 18:55:19 <psykose> i can only reproduce two failures, and one is flaky
2022-04-12 18:55:25 <psykose> passes 80% of the time
2022-04-12 18:57:31 <ncopa> if its a flaky test i'd just disabling it saying it is flaky
2022-04-12 18:58:04 <psykose> yeah
2022-04-12 18:58:14 <ncopa> yay! all buidlers are successfully bootstrapped
2022-04-12 18:58:15 <psykose> trying to figure out what the other one is doing, but i have no idea
2022-04-12 18:58:36 <ncopa> i think i'll enable them
2022-04-12 18:59:03 <ikke> ncopa: nice 
2022-04-12 18:59:31 <omni> woot \o/
2022-04-12 19:00:51 <psykose> if i make them output stuff all the things it does succeed with 0 and then it fails anyway
2022-04-12 19:02:50 <psykose> sure, just two disables
2022-04-12 19:05:34 <psykose> pytest depends on wcwidth and wcwidth depends on the former in check, do you want !check or -n bootstrap && !check
2022-04-12 19:06:37 <psykose> did the latter
2022-04-12 19:08:26 <ncopa> the aports-build does not have logic for bootstrap
2022-04-12 19:08:47 <psykose> ah
2022-04-12 19:08:50 <psykose> well
2022-04-12 19:08:54 <psykose> that's not great
2022-04-12 19:09:30 <ncopa> so far we have had policy to not introduce circular dependencies
2022-04-12 19:09:35 <ncopa> with a few exceptions
2022-04-12 19:09:45 <ncopa> the exceptions needs manual work
2022-04-12 19:09:53 <ncopa> like go, ghc
2022-04-12 19:09:59 <ncopa> and gcc/abuild etc
2022-04-12 19:10:07 <ncopa> and rust too i think
2022-04-12 19:10:35 <psykose> sure, fixed
2022-04-12 19:10:58 <psykose> and the gcc11 failure
2022-04-12 19:11:01 <psykose> lets see what's next..
2022-04-12 19:11:40 <psykose> ah, i think then meson cannot run its tests at all
2022-04-12 19:11:46 <psykose> unless you want to manually bootstrap it
2022-04-12 19:16:56 <ncopa> i wonder if we could add an option to abuild to include the checks, so we can run the tests form CI
2022-04-12 19:17:34 <psykose> hm, seems more other failing util-linux tests
2022-04-12 19:18:29 <ikke> ncopa: what tests?
2022-04-12 19:18:49 <ncopa> psykose> ah, i think then meson cannot run its tests at all
2022-04-12 19:18:52 <ikke> ah
2022-04-12 19:18:57 <psykose> things related to circular deps
2022-04-12 19:19:02 <omni> !33112
2022-04-12 19:22:34 <ikke> ncopa: I suppose we should announce a toolchain freeze now
2022-04-12 19:23:13 <Ariadne> i wanted to update gcc to a newer snapshot
2022-04-12 19:23:16 <Ariadne> but i guess
2022-04-12 19:23:43 <ncopa> i guess you still can, unless it is know to break stuff?
2022-04-12 19:23:48 <ncopa> its a stable branch right?
2022-04-12 19:23:57 <Ariadne> yes
2022-04-12 19:23:58 <ncopa> so it should only include bug fixes
2022-04-12 19:24:05 <ncopa> then I think its ok
2022-04-12 19:24:23 <psykose> guess we are on the latest rust etc as well
2022-04-12 19:24:30 <psykose> i didn't manage to get llvm14 in but that's fine
2022-04-12 19:24:48 <psykose> 13.0.1 is plenty new :)
2022-04-12 19:32:13 <psykose> aand x86 fails like 10 util-linux tests
2022-04-12 19:32:14 <psykose> hehe
2022-04-12 19:32:15 <minimal> interesting it is utmp-related tests that are failing...I'll have a look
2022-04-12 19:34:24 <minimal> 1st guess (without looking at the tests yet) is that as utmps is not installed/running then there's no actual utmp records being created for the tests to validate (as musl just has stubs for utmp)
2022-04-12 19:35:05 <psykose> the lsfd/ tests don't look utmp related
2022-04-12 19:36:39 <minimal> psykose: didn't notice those in https://build.alpinelinux.org/buildlogs/build-3-16-x86/main/util-linux/util-linux-2.38-r0.log
2022-04-12 19:36:54 <psykose> ah
2022-04-12 19:36:58 <psykose> those didn't fail on the other arches
2022-04-12 19:37:03 <psykose> that's for x86 only
2022-04-12 19:37:06 <psykose> and i had those disabled
2022-04-12 19:37:11 <psykose> er, the ones you don't notice
2022-04-12 19:37:17 <psykose> see the APKBUILD history from just now
2022-04-12 19:38:58 <omni> are you working on a 3.16 release?
2022-04-12 19:39:08 <ikke> yes
2022-04-12 19:39:13 <ikke> the 3.16 builders have just been bootstrapped
2022-04-12 19:39:29 <omni> ah, I see...
2022-04-12 19:40:49 <omni> could !32655 or !33059 (plus -rpi patch I cannot add) make it in?
2022-04-12 19:46:27 <omni> should we drop nomad since it's not possible to upgrade?
2022-04-12 19:48:03 <minimal> omni: I upgraded nomad a couple of weeks ago
2022-04-12 19:48:18 <omni> minimal: oh, huh, good job! :D
2022-04-12 19:48:27 <minimal> with UI disabled unfortunately
2022-04-12 19:48:46 <omni> nevermind then, I'll close my related MR I haven't looked at in a while
2022-04-12 19:49:07 <minimal> there's a new Beta out that I've managed to build yesterday (including wuth UI) but haven't had a chance to actually run it yet to see if its working
2022-04-12 19:50:11 <omni> ncopa: could the zfs 2.1.4 upgrade make it into the 3.16 release?
2022-04-12 19:51:16 <psykose> ncopa: dansguardian fails to build with gcc11, but it's also unmaintained and has had no releases for 10 years.. should we perhaps just remove it ?
2022-04-12 19:51:44 <psykose> i can also patch the issues if you want, it's not that hard, but idk if this is such a great package
2022-04-12 20:06:06 <smcavoy> can someone take a look at !33147 ?
2022-04-12 20:14:27 <psykose> ah right
2022-04-12 20:14:46 <psykose> can you just make it install -Dm644 or whatever it is
2022-04-12 20:15:20 <smcavoy> Sure
2022-04-12 20:17:06 <knuxify> would appreciate a review on !33149, currently marking it as draft so that i can look over it again tommorow morning, it's kinda late but i wanted to push my changes so ci could test it :p
2022-04-12 20:18:33 <omni> !32907
2022-04-12 20:18:54 <omni> !32667
2022-04-12 20:52:53 <psykose> ugh, there's a circle between pinentry and gnupg somewhere..
2022-04-12 21:18:20 <omni> some issue with the gitlab CI builders?
2022-04-12 21:19:01 <psykose> yes, they're all down due to the git upgrade
2022-04-12 21:19:11 <psykose> you can see the error
2022-04-12 21:19:18 <psykose>  https://lore.kernel.org/git/20220412180510.GA2173@szeder.dev/T/#t
2022-04-12 21:19:24 <psykose> caused by some new security commits
2022-04-12 23:13:01 <psykose> ah
2022-04-12 23:13:06 <psykose> meson.build:1013:10: ERROR: Program 'gtk4-update-icon-cache' not found or not executable
2022-04-12 23:13:07 <psykose> right
2022-04-12 23:13:24 <psykose> elibrokeit: what was the workaround for this
2022-04-12 23:15:35 <psykose> the build is.. gtk3 itself
2022-04-12 23:16:47 <elibrokeit> psykose: make gtk4 into a split package that provides gtk4-update-icon-cache. Make it include a symlink for gtk-update-icon-cache. Make gtk2, gtk3, and gtk4 all depend on this split package. Magically, you now *always* have both versions
2022-04-12 23:17:06 <psykose> well.. to even change that, gtk3 has to be rebuilt
2022-04-12 23:17:11 <elibrokeit> but also lol that gtk3 depends on gtk4-update-icon-cache, hmm
2022-04-12 23:17:12 <psykose> and it cannot rebuild because of that error
2022-04-12 23:17:18 <psykose> i don't think it does
2022-04-12 23:17:23 <elibrokeit> nah, you could have it in build deps I am sure
2022-04-12 23:17:43 <psykose> i don't think any part of gtk3 depends on gtk4- icon cache
2022-04-12 23:17:50 <elibrokeit> but also the fix is tagged for .1, it's a typo
2022-04-12 23:17:51 <psykose> i could be wrong
2022-04-12 23:17:52 <psykose> yea
2022-04-12 23:17:59 <psykose> is there anything i can hotpatch in a meson.build of gtk3
2022-04-12 23:18:05 <elibrokeit> if it is erroring there, then something depends on it!
2022-04-12 23:18:23 <elibrokeit> gtk3 installs icons, it invokes gnome.post_install()
2022-04-12 23:18:43 <psykose> right
2022-04-12 23:19:28 <psykose>   if meson.version().version_compare('>=0.57.0')
2022-04-12 23:19:28 <psykose>     gnome.post_install(
2022-04-12 23:19:29 <psykose> yep indeed
2022-04-12 23:21:00 <elibrokeit>  # use gtk-update-icon-cache from gtk+2.0 for now. The icon cache is forward
2022-04-12 23:21:01 <elibrokeit>  # compatible so this is fine
2022-04-12 23:21:03 <elibrokeit>  rm -f "$pkgdir"/usr/bin/gtk-update-icon-cache
2022-04-12 23:21:08 <elibrokeit> this is in the gtk4.0 package
2022-04-12 23:21:37 <elibrokeit> recommendation: updatge gtk-update-icon-cache from gtk2, have it provide the gtk4-update-icon-cache name too
2022-04-12 23:22:16 <elibrokeit> delete both that and /usr/bin/gtk4-update-icon-cache from gtk4.0
2022-04-12 23:22:57 <psykose> is it fine for it to provide that name?
2022-04-12 23:23:10 <psykose> as in, do they do anything different
2022-04-12 23:23:55 <elibrokeit> it's the same program, and the gtk4 package comments that it is identical in effect
2022-04-12 23:24:20 <elibrokeit> gtk4-update-icon-cache is just a more up to date version of gtk2 -update-icon-cache
2022-04-12 23:24:34 <elibrokeit> it probably has bug fixes or somethng, idk
2022-04-12 23:24:48 <elibrokeit> generates the same files either way, though
2022-04-12 23:25:14 <elibrokeit> i mean
2022-04-12 23:25:34 <elibrokeit> gtk4 is "an updated version of gtk2" also, it just has ABI differences
2022-04-12 23:25:43 <elibrokeit> a CLI tool doesn't worry about ABI :D
2022-04-12 23:26:08 <psykose> right
2022-04-12 23:26:55 <psykose> done
2022-04-12 23:30:53 <elibrokeit> although you made the canonical version the one built from the gtk2 source code :) you could also just make the canonical version, the one built from the gtk4 source code
2022-04-12 23:31:04 <psykose> that one is in community/
2022-04-12 23:31:08 <elibrokeit> ah
2022-04-12 23:31:10 <psykose> i could make it the gtk3 version instead
2022-04-12 23:31:14 <psykose> but eh
2022-04-12 23:31:21 <elibrokeit> gtk4 isn't very popular yet I guess?
2022-04-12 23:31:43 <psykose> most things indeed don't use 4, but also it needs rust to build, etc etc
2022-04-12 23:31:50 <elibrokeit> it probably does not matter, make a mental note to use the gtk4 version if/when it migrates to main
2022-04-12 23:32:04 <psykose> that would require rust in main, as well as a ton of other things
2022-04-12 23:32:05 <psykose> etc etc
2022-04-12 23:32:22 <psykose> actually
2022-04-12 23:32:23 <psykose> hm
2022-04-12 23:32:43 <psykose> well it's more like
2022-04-12 23:32:51 <psykose> it needs colord, which needs polkit, which needs mozjs, which needs rust
2022-04-12 23:33:02 <psykose> but at some point i think polkit wont need the last part
2022-04-12 23:33:41 <psykose> as for canonical version.. it was gtk2 all along anyway, since it provided the default gtk- named one
2022-04-12 23:33:44 <elibrokeit> they are working to allow/switch entirely, to duktape IIRC
2022-04-12 23:33:52 <psykose> and we only had a trigger= for that one
2022-04-12 23:34:07 <elibrokeit> anyway the git logs for gtk.git tools/updateiconcache.c basically shows nothing
2022-04-12 23:34:07 <psykose> the one that runs gtk-update-icon-cache on install
2022-04-12 23:34:13 <elibrokeit> "use int instead of gint"
2022-04-12 23:34:22 <psykose> massive change
2022-04-12 23:34:33 <psykose> and yeah, iirc duktape was planned as well
2022-04-12 23:34:35 <psykose> we'll see
2022-04-12 23:34:40 <elibrokeit> "Avoid confusing loop construct"
2022-04-12 23:35:19 <elibrokeit> oh, the gint -> int change was so successful and popular they got really daring and followed that up with:
2022-04-12 23:35:24 <elibrokeit> > Replace "gchar" with "char"
2022-04-12 23:36:23 <psykose> definitely got the whole office together for a party after that one
2022-04-12 23:36:24 <elibrokeit> there's perhaps one actually meaningful code change to the tool, and that's the opensuse reproducible-builds change, to make the icon cache file use sorted cache contents
2022-04-12 23:36:35 <psykose> is it in 3 or 4 only
2022-04-12 23:37:02 <elibrokeit> just in case you ship the icon cache in your "reproducible builds" docker container?
2022-04-12 23:37:33 <psykose> i mean like, are those changes in 3 as well, or is it only in 4
2022-04-12 23:38:26 <elibrokeit> that one came in the 3.24 cycle before branching
2022-04-12 23:38:48 <elibrokeit> same commit is present in 3.24.19 and 4.0
2022-04-12 23:40:00 <elibrokeit> however
2022-04-12 23:40:31 <elibrokeit> switching from gint to int and gchar to char was a breaking change, they delayed that until after the 4.0 devel branching
2022-04-12 23:40:44 <psykose> a breaking change for an icon cache?
2022-04-12 23:40:50 <elibrokeit> sorry, you cannot get access to that until you move rust to main
2022-04-12 23:40:58 <elibrokeit> (it was a joke)
2022-04-12 23:41:00 <psykose> :p
2022-04-12 23:41:17 <psykose> sure, i will backlog replacing the default with the 3 variant at some point
2022-04-12 23:41:22 <elibrokeit> although less of a joke than you might think
2022-04-12 23:41:26 <psykose> and by backlog i mean i will forget about it
2022-04-12 23:41:34 <psykose> until you shout at me in 7 months
2022-04-12 23:41:37 <psykose> and then i will do it
2022-04-12 23:41:38 <psykose> deal?
2022-04-12 23:41:55 <elibrokeit> they use gint and gchar because "pre-posix compilers have bugs in support for basic types like int"
2022-04-12 23:42:13 <elibrokeit> so gint is a "better int, for when your compiler is broken"
2022-04-12 23:43:06 <humm3> >pre-posix compilers >glib
2022-04-12 23:43:09 <humm3> yeah, right
2022-04-12 23:44:13 <elibrokeit> g_free checks if you pass a NULL pointer, even though free(NULL) is guaranteed by the standard to be a no-op
2022-04-12 23:44:43 <elibrokeit> this is apparently because some compilers didn't hold with "standards", called that UB, and crashed
2022-04-13 00:35:53 <psykose> kpcyrd: hello, could you get cjdns 21.1 to build with gcc11
2022-04-13 00:36:07 <psykose> or move it to community for 21.2 (since rust)
2022-04-13 00:36:46 <psykose> i disabled it since it does not build, there is a sample working reverted commit for 21.2 to ignore the overflow errors, not sure if that is correct
2022-04-13 07:18:52 <ikke> shouldn't https://pkgs.alpinelinux.org/contents?file=*.so&path=&name=libbsd&branch=edge&repo=main&arch=x86_64 be part of the dev package?
2022-04-13 07:34:25 <ncopa> normally yes, but its not a symlink
2022-04-13 07:48:26 <ikke> Should we add libbsd as explicit dependency then? 
2022-04-13 07:54:40 <ncopa> where?
2022-04-13 07:59:14 <ikke> mg fails to build because it cannot find libbsd (-lbsd) 
2022-04-13 07:59:27 <ikke> It pulls in libbsd-dev
2022-04-13 08:27:57 <ikke> same for cvechecker
2022-04-13 08:29:17 <omni> gitlab CI still broken?
2022-04-13 08:29:47 <ikke> I need to look at it
2022-04-13 08:29:51 <ikke> Will do in a bit
2022-04-13 08:55:32 <omni> it's related to this https://git.kernel.org/pub/scm/git/git.git/commit/?h=maint&id=8959555cee7ec045958f9b6dd62e541affb7e7d9 right?
2022-04-13 08:56:10 <ikke> yes
2022-04-13 09:18:59 <ncopa> i thought i had fixed libbsd
2022-04-13 09:19:47 <ikke> ddevault sent an MR to force make it a symlink
2022-04-13 09:20:09 <ikke> !33168
2022-04-13 09:20:32 <ncopa> ok.. I had the fix in my openssl3 branch
2022-04-13 09:20:50 <ikke> ah
2022-04-13 09:21:25 <ncopa> https://tpaste.us/Bkkb
2022-04-13 09:23:57 <ncopa> where is libbsd tracked nowdays?
2022-04-13 09:24:41 <ncopa> i had a look at it back then. they intentionally use a linker script instead of symlink, so I assumed thy do that for a reason
2022-04-13 09:24:53 <ikke> https://libbsd.freedesktop.org/
2022-04-13 09:24:57 <ddevault> on freedesktop
2022-04-13 09:24:59 <ddevault> https://gitlab.freedesktop.org/libbsd/libbsd
2022-04-13 09:25:09 <ncopa> which is why I went for copying it instead of force symlink
2022-04-13 09:25:19 <ikke> https://gitlab.freedesktop.org/libbsd/libbsd/-/issues
2022-04-13 09:28:25 <ncopa> i think we should ask upstream why they use linker script instead of symlink
2022-04-13 09:28:46 <ncopa> or fix upstream to use symlink
2022-04-13 10:18:06 <ncopa> I think we should not use symlink due to https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
2022-04-13 11:00:45 <omni> are the linux-rpi patches here due to their enormous size? https://dev.alpinelinux.org/archive/rpi-patches/
2022-04-13 11:00:51 <omni> rather than in the aports repo
2022-04-13 11:01:15 <ikke> yes, and because it's easier to update them
2022-04-13 11:01:48 <omni> how are they updated?
2022-04-13 11:03:22 <omni> oh.. in genpatch()?
2022-04-13 11:04:09 <ikke> omni: the linux-rpi kernel is a fork if linux with patches
2022-04-13 11:04:28 <ikke> instead of using that source directly, we extract the changes as patches and apply that to the vanilla kernel
2022-04-13 11:04:45 <omni> yes, but I didn't look closely at the linux-rpi APKBUILD before
2022-04-13 11:06:37 <omni> then, perhaps I could dare to bump linux-rpi too in !33059
2022-04-13 11:08:40 <omni> or maybe not... because I wouldn't have access to upload the patch..
2022-04-13 11:08:50 <omni> would the gitlab CI job have?
2022-04-13 11:09:02 <ikke> no
2022-04-13 11:09:08 <ikke> one of the developers would need to do it
2022-04-13 11:09:08 <omni> good =)
2022-04-13 11:09:20 <omni> right
2022-04-13 11:13:23 <ikke> I just pushed a fix to the CI image, so let's see if CI works again in a bit
2022-04-13 11:28:09 <omni> finger crossings
2022-04-13 11:29:39 <ikke> Already one pipeline succeeded
2022-04-13 11:33:02 <omni> \o/
2022-04-13 12:32:05 <Shiz> sup
2022-04-13 12:57:34 <adhawkins> Is there an issue with CI build at the moment? A MR I did an hour or so ago had all the builds fail because it said the repo was owned by someone else. I've just tried re-submitting one of the jobs and it's still pending after several minutes.
2022-04-13 12:57:57 <ikke> adhawkins: a git upgrade caused the issue
2022-04-13 12:58:01 <adhawkins> This is an example of one of the failures: https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/689295
2022-04-13 12:58:05 <ikke> (security fix)
2022-04-13 12:58:08 <adhawkins> Ah ok ikke, as long as someone knows about it.
2022-04-13 12:58:19 <ikke> I worked around it, but there is a backlog in CI now
2022-04-13 12:58:37 <ikke> 24 pending jobs
2022-04-13 12:58:42 <adhawkins> Understood. Will those builds re-run automatically, or do I need to trigger them again?
2022-04-13 12:58:54 <adhawkins> I've only triggered one of the arch's at the moment.
2022-04-13 12:59:08 <ikke> if the others are failed, you need to restart them
2022-04-13 12:59:34 <adhawkins> Ok. I'll wait until the one I've done completes, and if it succeeds I'll trigger the others too.
2022-04-13 13:11:22 <ikke> I'm looking at dendrite@riscv64
2022-04-13 13:19:53 <psykose> our luac5.4 seems broken
2022-04-13 13:20:36 <psykose> https://build.alpinelinux.org/buildlogs/build-3-16-armhf/main/lsyncd/lsyncd-2.2.3-r3.log running the same luac commands locally segfaults with https://img.ayaya.dev/lCcmzuXOaIlr
2022-04-13 13:20:37 <psykose> strange
2022-04-13 13:22:47 <psykose> ah, the builders are almost done as well
2022-04-13 13:34:43 <omni> does anyone know how to use zaquestions lab to re-trigger/-run aports MR pipelines?
2022-04-13 13:35:05 <psykose> the what now
2022-04-13 13:35:30 <psykose> uhh if there is a way to rebase the mr, then that would work if it's not up to date
2022-04-13 13:35:32 <psykose> aside from that, no idea
2022-04-13 13:35:34 <omni> community/lab, I use it to not have to deal with webly interfaces as much
2022-04-13 13:35:40 <ikke> omni: I use glab
2022-04-13 13:36:04 <omni> hmm, perhaps I should look at that too...
2022-04-13 13:50:35 <psykose> plugins/system/uname/uname_linux.go:102:23: cannot use &utsname.Machine (value of type *[65]uint8) as type *[65]int8 in argument to arrayToString
2022-04-13 13:50:46 <ikke> Yes, saw it
2022-04-13 13:50:47 <psykose> perhaps we should just disable zabbix on riscv64
2022-04-13 13:50:54 <ikke> Just hold a bit, will look at it
2022-04-13 13:51:10 <ikke> waiting for dendrite to finish compiling
2022-04-13 14:05:01 <ikke> psykose: I think something like https://tpaste.us/NOOl should fix it, testing it in a bit
2022-04-13 14:05:23 <psykose> ah, maybe
2022-04-13 14:12:11 <psykose> not sure how to fix luac5.4 segfault
2022-04-13 14:18:36 <psykose> Newbyte, pabloyoyoista: thanks for your work!
2022-04-13 14:18:37 <ikke> psykose: hmm, I already thought it looked familiar
2022-04-13 14:18:42 <ikke> psykose: we already have a patch for this
2022-04-13 14:18:46 <psykose> oh
2022-04-13 14:19:10 <psykose> hm
2022-04-13 14:19:20 <psykose> the patches there don't look related
2022-04-13 14:19:32 <ikke> go-agent-plugin-uname-add-riscv64.patch
2022-04-13 14:19:35 <psykose> oh
2022-04-13 14:19:40 <psykose> right, i was talking about lua5.4
2022-04-13 14:19:42 <psykose> haha
2022-04-13 14:19:43 <Newbyte> glad you appreciate it :)
2022-04-13 14:20:10 <psykose> of course!
2022-04-13 14:20:21 <psykose> it's a lot of work to upgrade whole large blobs like this
2022-04-13 14:21:29 <psykose> Size difference for dotnet6-artifacts: 928 MiB -> 909 MiB
2022-04-13 14:21:31 <psykose> wow, amazing /s
2022-04-13 14:59:27 <ikke> macifrename.c:283:9: error: 'process_if' accessing 16 bytes in a region of size 14 [-Werror=stringop-overflow=]
2022-04-13 15:05:07 <Ariadne> yeah
2022-04-13 15:05:12 <Ariadne> some header changed
2022-04-13 15:05:17 <Ariadne> i'll release a new version to deal with it
2022-04-13 15:05:29 <Ariadne> give me ~10m
2022-04-13 15:05:33 <ikke> sure
2022-04-13 15:06:14 <psykose> main is almost done
2022-04-13 15:06:22 <psykose> i think it's just that and.. the luac segfault
2022-04-13 15:09:52 <ikke> should we rebuild things for go1.18.1?
2022-04-13 15:12:26 <psykose> probably?
2022-04-13 15:12:28 <psykose> i already merged it
2022-04-13 15:12:35 <ikke> yes, saw it
2022-04-13 15:12:48 <Ariadne> 1.18.1 is needed for kubernetes at the very least
2022-04-13 15:13:05 <psykose> i can't actually find the changelog..
2022-04-13 15:13:08 <psykose> was it a security release
2022-04-13 15:13:13 <ikke> yes
2022-04-13 15:13:24 <ikke> $builder/rootfs/home/buildozer/.ssh/known_hosts
2022-04-13 15:13:27 <Ariadne> 1.18.1 fixes a certificate validation issue
2022-04-13 15:13:34 <ikke> https://groups.google.com/g/golang-announce/c/oecdBNLOml8
2022-04-13 15:13:42 <psykose> ah
2022-04-13 15:13:46 <ikke> some weird thing that tailscale found
2022-04-13 15:15:04 <ikke> oh, logrotate fails due to sticky dir
2022-04-13 15:15:16 <psykose> why do we keep running into that damned sticky dir :p
2022-04-13 15:16:38 <ikke> some template sets it on $HOME
2022-04-13 15:17:31 <omni> oohh.. I wonder with that "testing/*: rebuild with go 1.18.1"... that wasn't as tested as the other one, things may fail to build...
2022-04-13 15:17:58 <psykose> i don't see why it would
2022-04-13 15:17:58 <ikke> we'll see
2022-04-13 15:18:07 <psykose> it's just pkgrel bumps and essentially the same go version
2022-04-13 15:18:13 <psykose> i had just fixed all of then for 1.18.0
2022-04-13 15:18:20 <psykose> when someone already bumped all of them like 3 weeks ago
2022-04-13 15:18:26 <omni> things break sometimes due to other things...
2022-04-13 15:18:35 <psykose> sure, but i'm awake
2022-04-13 15:18:36 <psykose> :p
2022-04-13 15:18:43 <omni> so I don't think any of it will fail because of go 1.18.1
2022-04-13 15:18:52 <ikke> psykose: physically or mentally? :P
2022-04-13 15:19:07 <psykose> definitely only the former
2022-04-13 15:19:08 <psykose> ..awake enough
2022-04-13 15:35:42 <psykose> weird, lsyncd is sigsegv on x86 but sigill on ppc/s390x
2022-04-13 15:36:16 <skarnet> ncopa: can I has alpine-conf version number bump? plz?
2022-04-13 15:36:27 <psykose> i think our lua is completely broken
2022-04-13 15:37:14 <omni> I'm looking at go for 3.15-stable
2022-04-13 15:38:18 <psykose> i don't think a world rebuild is very safe :p
2022-04-13 15:38:23 <psykose> but if you get the ci to pass, i guess
2022-04-13 15:38:35 <psykose> we really need to figure out that tool to flag only the cve-affected packages
2022-04-13 15:38:43 <ikke> psykose: I
2022-04-13 15:38:50 <psykose> i noticed it's almost done
2022-04-13 15:39:00 <ikke> I'm upgrading flit, but it now needs pip for tests
2022-04-13 15:39:07 <ikke> I suppose it's better to disable though, right?
2022-04-13 15:39:13 <psykose> are you sure it needs pip?
2022-04-13 15:39:15 <psykose> what error do you get
2022-04-13 15:39:29 <ikke> subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'pip', 'install', '--user', '-r', '/tmp/tmp6u2n6e_lrequirements.txt']' returned non-zero exit status 1.
2022-04-13 15:39:31 <psykose> there is already a -k that disables something that needed pip
2022-04-13 15:39:35 <psykose> hmmm
2022-04-13 15:39:37 <ikke> it explicitly calls pip
2022-04-13 15:39:42 <psykose> that sounds like it's missing a dep and calls pip
2022-04-13 15:39:51 <ikke> oh, maybe
2022-04-13 15:40:47 <psykose> ah
2022-04-13 15:40:47 <psykose> also
2022-04-13 15:41:17 <psykose> https://img.ayaya.dev/NXeeT2qDnPms.png
2022-04-13 15:41:25 <psykose> i think the 3.6 changes were already there, for build_dists.py
2022-04-13 15:41:28 <psykose> but i forgot how that worked
2022-04-13 15:41:46 <psykose> ah
2022-04-13 15:41:50 <psykose> now there is a bootstrap_install.py
2022-04-13 15:41:53 <psykose> you should use that for -core
2022-04-13 15:42:34 <psykose> or maybe idk how it works :p
2022-04-13 15:43:24 <ikke> looking at it
2022-04-13 15:43:41 <ikke> Use 'python -m flit_core.wheel' to make a wheel, then:
2022-04-13 15:43:45 <ikke> python bootstrap_install.py flit_core-3.6.0-py3-none-any.whl
2022-04-13 15:43:54 <psykose> some of the new tests have stuff like py3-requests
2022-04-13 15:43:58 <psykose> https://img.ayaya.dev/uclNaWuajksP.png
2022-04-13 15:44:01 <psykose> assuming it tries to do this
2022-04-13 15:44:54 <psykose> that's basically the only change to tests
2022-04-13 15:45:04 <psykose> but.. we already had those
2022-04-13 15:45:05 <psykose> so idk
2022-04-13 15:46:41 <psykose> yeah, i don't think you need the new bootstrap_install
2022-04-13 15:47:22 <psykose> the existing thing already does basically the same thing
2022-04-13 15:47:25 <psykose> and we have installer for the whl
2022-04-13 15:47:42 <ikke> yes, it would replace py3-installer
2022-04-13 15:48:01 <ikke> means even less dependencies
2022-04-13 15:49:33 <psykose> py3-installer is only makedepends and has no deps itself
2022-04-13 15:49:51 <ikke> py3-requests is already in depends for py3-flit
2022-04-13 15:53:09 <psykose> yeah
2022-04-13 15:53:26 <psykose> uhh it works without installer
2022-04-13 15:53:31 <psykose> but it does not generate the .pyc cache
2022-04-13 15:53:52 <psykose> https://img.ayaya.dev/z7nRp6BH7lUt
2022-04-13 15:54:27 <psykose> and since installer is not really a bad dependency, i think it's better to keep it
2022-04-13 15:54:38 <ikke> yeah, I don't mind
2022-04-13 15:54:49 <ikke> easier to have a consistent interface
2022-04-13 15:55:08 <psykose> as for the tests, they can be disabled
2022-04-13 15:55:17 <psykose> https://img.ayaya.dev/YGu95N2ZSfF1
2022-04-13 15:55:34 <psykose> and i think it should depends= on py3-flit-core=$pkgver-r$pkgrel since they match anyway
2022-04-13 15:55:36 <psykose> but yeah, that's all
2022-04-13 16:00:03 <ikke> ins.install_reqs_my_python_if_needed()
2022-04-13 16:01:25 <ikke> seems like explicitly trying to install depenendencies
2022-04-13 16:01:27 <psykose> from the look of the specific tests they're hardcoded to use pip
2022-04-13 16:01:33 <psykose> since it's testing installs with pip
2022-04-13 16:01:36 <psykose> or something
2022-04-13 16:01:42 <ikke> yes
2022-04-13 16:01:50 <ikke> so just disable those
2022-04-13 16:04:14 <psykose> mhm
2022-04-13 16:04:20 <psykose> that's what i did above
2022-04-13 16:04:41 <psykose> github.com/xanzy/go-cloudstack/cloudstack.(*CreateUserParams).toURLValues: unexpected trampoline for shared or dynamic linking
2022-04-13 16:04:42 <psykose> sigh
2022-04-13 16:04:49 <psykose> hopefully this is fixed in 1.18.1
2022-04-13 16:04:56 <psykose> because it was still persistent even with the patch on .0
2022-04-13 16:05:23 <psykose> oh right, that is with 1.18.1
2022-04-13 16:05:29 <psykose> 🙃
2022-04-13 16:05:49 <psykose> nmeum: hey guess what, go-ppc64le is still broken :p
2022-04-13 16:06:31 <nmeum> yeah, i also noticed some issues with it
2022-04-13 16:06:43 <psykose> those were present with patches 1.18 as well i think
2022-04-13 16:06:47 <nmeum> (for example staticcheck failed to link)
2022-04-13 16:06:58 <nmeum> 1.18.1 just includes the patch we previously backported for 1.18
2022-04-13 16:07:02 <psykose> right
2022-04-13 16:07:15 <psykose> i noticed even with goldflags=link-external in some places things failed anyway
2022-04-13 16:07:22 <psykose> but i managed to fix a thing or two with cgo_enabled=0
2022-04-13 16:07:35 <nmeum> looks like someone needs to convince go upstream to look into this again :S
2022-04-13 16:07:39 <psykose> aye
2022-04-13 16:08:08 <nmeum> would be kind of annoying to ship 3.16 with broken Go on ppc64le
2022-04-13 16:08:17 <psykose> yep
2022-04-13 16:08:55 <nmeum> can you open an issue on alpine gitlab so we don't forget about this
2022-04-13 16:09:08 <nmeum> might also be a good idea for gathering aports which fail to build with 1.18.1
2022-04-13 16:09:14 <nmeum> on ppc64le that is
2022-04-13 16:14:19 <psykose> uhh, sure
2022-04-13 16:14:25 <psykose> you might have more info than me, though
2022-04-13 16:15:46 <psykose> done
2022-04-13 16:22:19 <psykose> nmeum: do you also know why luac5.4 would segfault on usage on every arch when building lsyncd
2022-04-13 16:22:26 <psykose> (a little too big brained for me :p)
2022-04-13 16:23:29 <nmeum> psykose: thanks for opening the issue, I am just doing some riscv gcc stuff atm and would have forgotten about it otherwise :D
2022-04-13 16:23:36 <psykose> np :)
2022-04-13 16:24:06 <nmeum> do we have a backtrace for the luac segfault?
2022-04-13 16:26:26 <psykose> i did have one
2022-04-13 16:26:29 <psykose> sec
2022-04-13 16:26:45 <psykose> https://img.ayaya.dev/lCcmzuXOaIlr
2022-04-13 16:27:02 <psykose> the program invocation is like in the build
2022-04-13 16:27:19 <psykose> https://build.alpinelinux.org/buildlogs/build-3-16-armhf/main/lsyncd/lsyncd-2.2.3-r3.log (not visible here, but if you run V=1 you will see)
2022-04-13 16:27:24 <psykose> it fails locally etc etc as well
2022-04-13 16:27:42 <psykose> trimming it, it only succeeds with one file passed
2022-04-13 16:27:55 <psykose> i.e. luac5.4 -o x.out one-file works
2022-04-13 16:28:00 <psykose> any more than that gives the same error
2022-04-13 16:28:11 <psykose> it's also SIGILL on ppc/s390x, while sigsegv on the other arches
2022-04-13 16:28:17 <psykose> (same spot)
2022-04-13 16:29:16 <psykose> the specific call from lua is basically free(ptr); in l_alloc
2022-04-13 16:33:30 <omni> are packages available on builders immediately after they are built?
2022-04-13 16:33:42 <ikke> on the builders they are
2022-04-13 16:34:06 <omni> so there's no roundtrip where they need to be uploaded to a repository to fetch them from?
2022-04-13 16:34:09 <nmeum> psykose: looks like a failing assertion musl's mallocng?
2022-04-13 16:34:16 <nmeum> > get_meta (p=p@entry=0x7ffff7f5a5f0 "\001") at src/malloc/mallocng/meta.h:142
2022-04-13 16:34:20 <ikke> omni: correct
2022-04-13 16:34:23 <nmeum> > 142		assert(index <= meta->last_idx);
2022-04-13 16:34:36 <omni> ikke: cool, thanks
2022-04-13 16:35:11 <nmeum> yeah, index is 31 and meta->last_idx is 14
2022-04-13 16:35:38 <psykose> is this a 1.2.3 regression or just undefined behaviour in lua though?
2022-04-13 16:36:14 <nmeum> that I don't know
2022-04-13 16:36:25 <psykose> maybe i should ask in #musl..
2022-04-13 16:36:38 <psykose> would be easier if i was less scared of people
2022-04-13 16:36:39 <nmeum> yes, that is a good idea
2022-04-13 16:36:39 <psykose> anyway, brb
2022-04-13 16:36:43 <nmeum> :)
2022-04-13 16:40:04 <psykose> it fails with previous musl as well actually
2022-04-13 16:40:05 <psykose> hmm
2022-04-13 16:40:51 <psykose> ah
2022-04-13 16:40:54 <psykose> it passes with 3.15 lua 5.4.3
2022-04-13 16:40:59 <psykose> and fails with edge lua 5.4.4
2022-04-13 16:42:55 <psykose> so.. the issue was the lua upgrade..
2022-04-13 16:44:22 <psykose> yeah
2022-04-13 16:44:31 <psykose> you can have completely benign lua files
2022-04-13 16:44:54 <psykose> with just a return 1
2022-04-13 16:45:33 <psykose> https://img.ayaya.dev/42QkKoTHY7eH.png
2022-04-13 16:45:36 <psykose> passing more than one fails
2022-04-13 16:45:41 <psykose> what a weird regression
2022-04-13 16:48:30 <psykose> i will do a bisect
2022-04-13 16:50:16 <nmeum> might still be a bug in musl, e.g. if 5.4.4 now does allocations differently or something
2022-04-13 16:51:40 <psykose> i mean it works with old musl and new musl on .4.3
2022-04-13 16:51:48 <psykose> and fails with both old and new on .4.4
2022-04-13 17:02:54 <psykose> am i high or does the lua git not contain luac.c while the tarballs do
2022-04-13 17:04:32 <psykose> sigh
2022-04-13 17:04:37 <psykose> tempted to just downgrade to 5.4.3 in the meantime
2022-04-13 17:06:16 <PureTryOut> Is there any way to make abump (which I recently learned off) use rootbld? It's useless for some packages as is because it doesn't separate the build from the host packages...
2022-04-13 17:07:35 <ikke> PureTryOut: ABUILD_OPTS
2022-04-13 17:07:41 <ikke> https://git.alpinelinux.org/abuild/tree/abump.in#n136
2022-04-13 17:08:38 <ikke> ABUILD_OPTS=rootbld abump
2022-04-13 17:20:10 <psykose> threw in a downgrade, will look for fixes..
2022-04-13 17:23:32 <PureTryOut> ikke: ah cool thanks!
2022-04-13 17:23:41 <PureTryOut> Can't wait for rootbld to be the default 😅
2022-04-13 17:25:26 <ikke> psykose: !33200
2022-04-13 17:26:09 <psykose> aye
2022-04-13 17:26:11 <psykose> looks correct to me
2022-04-13 17:26:35 <psykose> also nice
2022-04-13 17:26:43 <psykose> you figured out the multiline -k
2022-04-13 17:26:44 <psykose> :)
2022-04-13 17:27:33 <ikke> yes
2022-04-13 17:29:24 <psykose> and armv7 has cleared main
2022-04-13 17:29:51 <ikke> I tried all kinds of things to coalesce the whitespace, but in the end letting the shell do it was easiest
2022-04-13 18:18:36 <psykose> ah
2022-04-13 18:18:42 <psykose> ncopa: you need to bootstrap rust on 3.16
2022-04-13 18:18:48 <ikke> I can do that
2022-04-13 18:18:53 <psykose>     required by: .makedepends-rust-20220413.181812[rust-bootstrap>=1.59.0]
2022-04-13 18:18:53 <psykose> rust-bootstrap (no such package):
2022-04-13 18:18:54 <psykose> sure
2022-04-13 18:18:56 <psykose> it's just copying the apk
2022-04-13 18:19:03 <psykose> thanks!
2022-04-13 18:19:48 <ikke> just add -X <edge>
2022-04-13 18:20:14 <psykose> that is a copy
2022-04-13 18:20:17 <psykose> for some definition of copy
2022-04-13 18:20:20 <nmeum> psykose: re luac: I think I would just report that upstream as a double-free and have them figure it out
2022-04-13 18:20:35 <psykose> b-but
2022-04-13 18:20:38 <psykose> it's a mailing list...
2022-04-13 18:20:41 <ikke> psykose: I suppose your constantly copying websites all the time? :P
2022-04-13 18:20:46 <psykose> of course :)
2022-04-13 18:20:52 <psykose> copying them right into system memory :p
2022-04-13 18:20:53 <nmeum> great, so you just have to send a single mail! :p
2022-04-13 18:21:02 <psykose> nmeum: could you do it for me
2022-04-13 18:21:03 <psykose> by chance
2022-04-13 18:21:03 <nmeum> at least it's not a bugzilla
2022-04-13 18:21:22 <nmeum> I have some go ppc64le bug reports on my list first
2022-04-13 18:21:59 <nmeum> if you open a gitlab issue and assign it to me I can look into it afterwards if you really don't want to do it
2022-04-13 18:22:36 <nmeum> but imho very important to report these sorts of memory corruptions upstream
2022-04-13 18:22:56 <psykose> not disagreeing!
2022-04-13 18:22:59 <psykose> just.. hard to do
2022-04-13 18:23:07 <psykose> i can assign you to the issue i already made
2022-04-13 18:23:13 <nmeum> sounds good
2022-04-13 18:26:18 <ikke> py3-nose: error: invalid command 'build_tests'
2022-04-13 18:26:41 <psykose> ah, another 59 victim
2022-04-13 18:26:44 <psykose> i will have a look
2022-04-13 18:39:37 <nmeum> hm, ppc64le hasn't build go 1.18.1 yet
2022-04-13 18:39:55 <nmeum> maybe the issue will magically disappear with go 1.18.1 🙏
2022-04-13 18:41:58 <psykose> are you sure? everything was pushed at once
2022-04-13 18:42:04 <psykose> i don't know why it wouldn't build it before the others
2022-04-13 18:42:10 <psykose> you won't see it uploaded until the whole thing is done
2022-04-13 18:42:16 <psykose> but it should be 1.18.1 on the builder itself
2022-04-13 18:42:32 <psykose> eg on edge https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/yubikey-touch-detector/yubikey-touch-detector-1.9.3-r3.log
2022-04-13 18:42:37 <psykose> 1.18.1 downloaded at the top
2022-04-13 18:42:45 <psykose> s/downloaded/installed
2022-04-13 18:42:45 <alpine-meetbot> psykose meant to say: 1.18.1 installed at the top
2022-04-13 18:43:11 <ikke> on edge, it's 1.18.1
2022-04-13 18:43:22 <psykose> ikke: i really have no clue what it's supposed to be doing.. sigh
2022-04-13 18:43:24 <ikke> build-edge-ppc64le [~]# apk version go
2022-04-13 18:43:26 <ikke> Installed:                                Available:
2022-04-13 18:43:28 <ikke> go-1.18.1-r0                            = 1.18.1-r0
2022-04-13 18:43:32 <psykose> this is something that hasn't been touched in 6+ years
2022-04-13 18:43:39 <ikke> psykose: what?
2022-04-13 18:43:43 <psykose> for nose
2022-04-13 18:43:45 <ikke> ah ok
2022-04-13 18:43:54 <psykose> i assume everything can't be easily replaced by nose2
2022-04-13 18:44:57 <psykose> we can also just disable the check i guess.. i can't really find a reference to what build_tests is
2022-04-13 18:45:45 <nmeum> ikke: what mirror are you using? I still see go 1.18 on dl-cdn
2022-04-13 18:45:47 <psykose> also something i noticed, the buildorder cannot track provides= in package/subpackage functions
2022-04-13 18:45:52 <ikke> nmeum: the builder itself
2022-04-13 18:45:55 <psykose> nmeum: it won't be upgraded on dl-cdn until it finishes
2022-04-13 18:46:02 <psykose> upload is only at the end of repo build
2022-04-13 18:46:07 <nmeum> aaaaaaa
2022-04-13 18:46:18 <nmeum> how do i use the builder itself?
2022-04-13 18:46:22 <psykose> well,
2022-04-13 18:46:27 <psykose> (you dont)
2022-04-13 18:46:40 <psykose> it means you need to build 1.18.1 on the machine you're testing on yourself, if you want it
2022-04-13 18:46:55 <ikke> yeah, the builders don't expose their repos directly
2022-04-13 18:47:55 <nmeum> i will just look into the go ppc64le issue tomorrow then :)
2022-04-13 18:50:20 <psykose> it will never upload because one of those packages will always fail
2022-04-13 18:50:23 <psykose> or rather, a lot of them
2022-04-13 18:50:24 <psykose> but yeah
2022-04-13 18:50:57 <psykose> i can probably fix them with either the goldflags or cgo_enabled=0, assuming one/both of those is the fix for all, but well
2022-04-13 18:51:00 <psykose> not the greatest solution
2022-04-13 18:54:13 <nmeum> ahh, rigth. well I guess I will just build from source then
2022-04-13 18:54:23 <nmeum> you can probably "fix" some of them with -buildmode=external
2022-04-13 18:54:33 <nmeum> (which we could also enforce in go itself)
2022-04-13 18:55:11 <ikke> (bootstrapping rust on armv7)
2022-04-13 18:55:46 <psykose> it works for the ones with trampoline but not defined i think
2022-04-13 18:55:49 <psykose> the latter is cgo only
2022-04-13 18:56:18 <psykose> it would be better to enforce it than to add edits into 10 apkbuilds, if it's really the fix for now
2022-04-13 18:57:10 <nmeum> I could re-enable 866f2e147cfbb06eec9179e7323be6d2f82b5290 again
2022-04-13 18:57:55 <ikke> compiler-rt:  CMake Error at /usr/lib/llvm13/lib/cmake/llvm/LLVMExports.cmake:1439 (message): The imported target "FileCheck" references the file "/usr/lib/llvm13/bin/FileCheck" but this file does not exist. 
2022-04-13 19:01:46 <psykose> i'm still not really sure how they lay that one out
2022-04-13 19:01:58 <psykose> it's fixed by adding the test utils, but i wonder why the files always import them
2022-04-13 19:01:59 <psykose> hm
2022-04-13 19:12:41 <nmeum> ah the go issues only happens with specific cgo compilation / linking flags
2022-04-13 19:12:42 <nmeum> fun fun
2022-04-13 19:13:26 <psykose> :)
2022-04-13 19:19:05 <nmeum> so the relocation target undefined thingy only happens with CGO_CFLAGS=-Os
2022-04-13 19:19:12 <nmeum> or at least I was only able to reproduce it with that so far
2022-04-13 19:19:33 <psykose> but not -O2?
2022-04-13 19:19:55 <psykose> quick, lets update abuild while ncopa isn't looking :p
2022-04-13 19:30:48 <Hello71> what's this about?
2022-04-13 19:31:05 <Hello71> found it
2022-04-13 19:31:10 <ikke> #13692
2022-04-13 19:32:15 <nmeum> psykose: is there anything other then packer which fails with the trampoline error
2022-04-13 19:32:34 <nmeum> I reported the relocation error upstream https://github.com/golang/go/issues/52336
2022-04-13 19:32:42 <psykose> uhh a bunch of things, but i didn't keep a list.. it's a little more rare
2022-04-13 19:32:54 <psykose> maybeee
2022-04-13 19:32:55 <psykose> github-cli
2022-04-13 19:33:03 <psykose> i set CGO_ENABLED=0 on it
2022-04-13 19:33:10 <ikke> vault
2022-04-13 19:33:13 <psykose> ah
2022-04-13 19:33:14 <psykose> ye
2022-04-13 19:33:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/689763
2022-04-13 19:33:55 <psykose> i should really set up a notepad somewhere :p
2022-04-13 19:34:01 <Hello71> odd that it would only work with external linking, i would expect it to be the other way around
2022-04-13 19:34:40 <nmeum> github-cli also fails with the relocation error
2022-04-13 19:35:00 <psykose> ah
2022-04-13 19:36:45 <nmeum> vault is also such a huge piece of software ;_;
2022-04-13 19:36:56 <nmeum> pls also don't just add CGO_ENABLED=0 unconditionally, that will impact other arches as well
2022-04-13 19:38:23 <psykose> what impact does it normally have
2022-04-13 19:38:28 <psykose> in terms of bad difference
2022-04-13 19:38:49 <ikke> It avoids building against libc
2022-04-13 19:38:55 <ikke> which means dns works differently
2022-04-13 19:39:00 <psykose> ah, right
2022-04-13 19:42:08 <nmeum> the trampoline thingy only happens with pie buildmode
2022-04-13 19:55:46 <nmeum> both of these seem to be "fixed" with -ldflags=-linkmode=external
2022-04-13 19:55:52 <nmeum> I will try to add that to go itself and see if it works
2022-04-13 19:55:58 <nmeum> until these two issues are fixed upstream
2022-04-13 19:56:07 <psykose> sure
2022-04-13 19:56:11 <psykose> well
2022-04-13 19:56:14 <psykose> github-cli wasn't
2022-04-13 19:56:23 <psykose> unless i missed a part where the makefile overrides it
2022-04-13 19:56:43 <psykose> you could test that, removing the cgo and adding the flags
2022-04-13 19:56:46 <nmeum> I will test it
2022-04-13 19:56:48 <nmeum> yes
2022-04-13 19:57:00 <nmeum> I will bake that into the compiler
2022-04-13 19:57:05 <psykose> i had initially copied one of your case ppc) export GOLDFLAGS=..
2022-04-13 19:57:06 <psykose> yea
2022-04-13 19:57:30 <ikke> bootstrapping rust on aarch64
2022-04-13 19:57:50 <psykose> is armhf done? i notice it's still offline
2022-04-13 19:57:53 <ikke> no
2022-04-13 19:57:56 <psykose> right
2022-04-13 19:57:57 <ikke> still working
2022-04-13 19:58:00 <psykose> sure thing :)
2022-04-13 19:58:04 <ikke> armv7 is ready
2022-04-13 19:58:27 <ikke> armhf continued with other things, I manually started building rust after it failed again
2022-04-13 19:59:27 <psykose> right
2022-04-13 20:11:11 <nmeum> github-cli seems to build with external buildmode
2022-04-13 20:11:15 <nmeum> vault oo
2022-04-13 20:11:16 <nmeum> *too
2022-04-13 20:11:18 <psykose> hm
2022-04-13 20:11:27 <psykose> maybe 1.18.1 had another change then, didn't work when i tried..
2022-04-13 20:11:31 <psykose> but that's nice to hear
2022-04-13 20:11:38 <psykose> sure, throw in the update to go itself
2022-04-13 20:14:02 <ikke> armhf finished building rust
2022-04-13 20:14:29 <psykose> poggies
2022-04-13 20:21:07 <nmeum> pushed the go linkmode change, if we encounter issues again on the builders feel free to re-open #13692
2022-04-13 20:21:36 <ikke> nmeum: will do :)
2022-04-13 20:21:50 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/yubikey-touch-detector/yubikey-touch-detector-1.9.3-r3.log failed :P
2022-04-13 20:24:53 <nmeum> > https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/yubikey-touch-detector/yubikey-touch-detector-1.9.3-r3.log
2022-04-13 20:24:56 <nmeum> rags
2022-04-13 20:24:58 <nmeum> clipboard fail
2022-04-13 20:25:02 <nmeum> > (1/2) Installing go (1.18.1-r0)
2022-04-13 20:25:04 <nmeum> installed old go, no?
2022-04-13 20:25:19 <nmeum> i.e. not -r1
2022-04-13 20:25:25 <ikke> nmeum: sorry, that was not serious, it failed even before the new go could be built
2022-04-13 20:25:36 <nmeum> ah ok :D
2022-04-13 21:01:09 <ikke> fixing py3-pygit2
2022-04-13 21:10:15 <donoban> anyone has idea about could I fix this: (23:09:48) plugins: /usr/lib/purple-2/libwhatsmeow.so is not loadable: Error relocating /usr/lib/purple-2/libwhatsmeow.so: sqlite3_autovacuum_pages: initial-exec TLS resolves to dynamic definition in /usr/lib/purple-2/libwhatsmeow.so
2022-04-13 21:11:06 <psykose> hm
2022-04-13 21:11:09 <psykose> where does that come from
2022-04-13 21:11:38 <donoban> I'm trying to package https://github.com/hoehermann/purple-gowhatsapp
2022-04-13 21:11:59 <psykose> it probably needs some -mtls-dialect
2022-04-13 21:12:00 <donoban> after installing it I started pidgin with debug enabled and get the error
2022-04-13 21:12:01 <psykose> no idea though
2022-04-13 21:12:44 <psykose> if you add -mtls-dialect=gnu2 it might work
2022-04-13 21:13:01 <donoban> on cmake --build ?
2022-04-13 21:13:08 <psykose> flags
2022-04-13 21:13:59 <psykose> -DCMAKE_C_FLAGS="$CFLAGS -mtls-dialect=gnu2"
2022-04-13 21:14:03 <psykose> i don't actually know, though :)
2022-04-13 21:19:18 <donoban> I get same problem
2022-04-13 21:19:30 <donoban> I will ask upstream tomorrow
2022-04-13 21:19:41 <donoban> it's too late for today
2022-04-13 21:20:22 <psykose> sure
2022-04-13 21:45:43 <Hello71> donoban: https://bpa.st/GPOQ
2022-04-13 21:45:58 <Hello71> try
2022-04-13 21:47:02 <psykose> ikke: time for ppc rust :)
2022-04-13 21:47:11 <psykose> and go bootstrap on s390, apparently
2022-04-13 21:49:57 <donoban> Hello71: thanks, tried but got: flag provided but not defined: -shared
2022-04-13 21:50:03 <Hello71> hm.
2022-04-13 21:51:37 <Hello71> ah, according to https://groups.google.com/g/golang-nuts/c/EhndTzcPJxQ/m/i-w7kAMfBQAJ it is not supported (as of 2016)
2022-04-13 21:53:20 <donoban> should I try with -gcflags=-shared -asmflags=-shared -installsuffix=_shared -a 
2022-04-13 21:53:22 <donoban> ?
2022-04-13 21:54:32 <Hello71> i don't think it will work
2022-04-13 21:54:52 <donoban> yep I was reading the continuation
2022-04-13 21:55:15 <omni> *sigh* would someone want to take over !33190 ?
2022-04-13 21:55:34 <omni> [3.15]
2022-04-13 21:58:33 <Hello71> export CGO_CFLAGS=-fPIC might work
2022-04-13 21:59:59 <omni> sure, but I'm done for now and don't know when I'll get time to continue
2022-04-13 22:00:17 <omni> it's already been lagging a few security updates
2022-04-13 22:00:21 <Hello71> i meant to donoban 
2022-04-13 22:00:26 <omni> aha
2022-04-13 22:00:29 <omni> I'm tired
2022-04-13 22:00:31 <omni> :D
2022-04-13 22:00:44 <donoban> hehe, me too
2022-04-13 22:00:49 <donoban> I'm trying to build again
2022-04-13 22:01:31 <donoban> same error :(
2022-04-13 22:02:48 <donoban> I will try again tomorrow, good night people
2022-04-13 22:27:35 <Hello71> donoban: did you unpatch the -shared?
2022-04-13 22:27:44 <Hello71> s/unpatch/reverse/
2022-04-13 22:27:44 <alpine-meetbot> Hello71 meant to say: donoban: did you reverse the -shared?
2022-04-13 22:29:07 <Hello71> it's odd that that would use TLS though
2022-04-14 07:32:31 <ikke> bootstrapping go on armhf
2022-04-14 07:33:06 <psykose> you can take all the current failed down and do them one by one for go/rust
2022-04-14 07:34:17 <ikke> Just need to keep track of what I did where
2022-04-14 07:34:24 <psykose> mhm
2022-04-14 07:34:51 <psykose> it should be as easy as seeing if there is a rust/go in local repos, if not there then not done
2022-04-14 08:23:37 <ikke> rust failed on ppc64le
2022-04-14 08:23:44 <ikke> failed to execute command: "/usr/lib/llvm13/bin/llvm-config" "--version"
2022-04-14 08:24:59 <psykose> what is the output
2022-04-14 08:25:07 <psykose> and what is the apk info of llvm13
2022-04-14 08:26:02 <ikke> strange, it did not install all dependencies the last time
2022-04-14 08:26:15 <psykose> hah
2022-04-14 08:26:25 <ikke> there was still a .makedepends-rust installed
2022-04-14 08:26:39 <ikke> lets try again
2022-04-14 09:23:23 <ikke> https://tpaste.us/5kXj
2022-04-14 09:23:59 <psykose> uhh
2022-04-14 09:24:10 <psykose> that doesn't look usually
2022-04-14 09:24:46 <psykose> it built just fine on ppc like 3-4 days ago
2022-04-14 09:25:00 <psykose> 64c49c2fa02a2c35ea6465e94e094455618a1129
2022-04-14 09:25:24 <psykose> (this is not the part that fails, but it was just building)
2022-04-14 09:25:25 <psykose> hm
2022-04-14 09:25:28 <psykose> no idea why it would fail
2022-04-14 09:25:30 <psykose> everything is the same
2022-04-14 09:25:43 <psykose> llvm, gcc, musl
2022-04-14 10:19:08 <omni> !33172
2022-04-14 10:19:24 <omni> vault wasn't bumped in the go 1.18.1 upgrade
2022-04-14 10:19:51 <psykose> what about it
2022-04-14 10:20:30 <omni> just a comment, it wasn't bumped because of the separate MR to upgrade it to 1.10.0
2022-04-14 10:21:17 <omni> and you had probably already merged it by the time I wrote that =)
2022-04-14 10:21:25 <psykose> indeed
2022-04-14 10:21:28 <psykose> :p
2022-04-14 11:53:34 <ikke> ncopa: did you fix / built rust on ppc64le?
2022-04-14 12:16:55 <ncopa> no, sorry
2022-04-14 12:17:15 <ikke> hmm, ok
2022-04-14 12:17:41 <ikke> Maybe I forgot to stop the builder then :D
2022-04-14 12:31:12 <ktprogra1> ncopa: I don't really understand how that %%,* substitution works, could you please explain it to me?
2022-04-14 12:34:12 <ncopa> remove first found ',' and everything after it
2022-04-14 12:34:41 <ncopa> it is for things like console=ttyS1,9600
2022-04-14 12:35:40 <ktprogra1> Ah, I see. I was confused because this was in the opt parsing code
2022-04-14 12:35:52 <ncopa> yup
2022-04-14 13:01:40 <fcolista> is anyone here using kubernetes to run a container in a node with different arch to build packages?
2022-04-14 13:03:42 <fcolista> I want to move from lxc-based builder to containers, with aports dir shared among the nodes
2022-04-14 13:04:08 <fcolista> has anyone tried already this road?
2022-04-14 15:11:23 <donoban> I try to apply this patch: http://ix.io/3V9B and get this error: /usr/bin/abuild: export: line 22: "-linkmode: bad variable name
2022-04-14 15:13:59 <skarnet> fcolista: isn't lxc a container manager already? o.O
2022-04-14 15:14:54 <skarnet> k8s certainly adds a lot of sugar but...
2022-04-14 15:21:55 <Ariadne> fcolista: yes, i have a multi-arch cluster
2022-04-14 15:21:59 <Habbie> if you're used to docker, it feels like lxc really conflates containers and images
2022-04-14 15:22:05 <Habbie> but that's probably unfair
2022-04-14 15:25:24 <fcolista> Ariadne, if/when you have time, care to share how it works? What's the workflow, how did you have setup it?
2022-04-14 15:25:39 <fcolista> no rush...and only if you want 
2022-04-14 15:25:44 <donoban> lol sorry, the error was not due the patch, it was a manual export that I added on APKBUILD
2022-04-14 15:26:03 <Hello71> also i think your patch will not work
2022-04-14 15:26:36 <fcolista> skarnet, my idea is having a container that just build and then destroy itself, one for each arch.
2022-04-14 15:26:49 <Ariadne> fcolista: i mean, kubernetes is multi-arch aware, it just works
2022-04-14 15:27:48 <donoban> Hello71: I'm just trying what author suggested https://github.com/hoehermann/purple-gowhatsapp/issues/119
2022-04-14 15:28:21 <fcolista> Ariadne, what are you using for Kubernetes? minikube? k3s? Or Alpine itself?
2022-04-14 15:28:51 <Hello71> in -buildmode=c-archive go is not invoking the linker at all
2022-04-14 15:29:11 <Ariadne> fcolista: minikube
2022-04-14 15:29:15 <Hello71> at most it could invoke ar/ranlib, but i think it actually uses its own implementation
2022-04-14 15:29:22 <Ariadne> i would like to use alpine's kubernetes package, but it does not support s390x
2022-04-14 15:29:40 <donoban> well, it didn't like the flags
2022-04-14 15:29:49 <fcolista> so when you git push, you have an hook that run the builder pod on $NODE with $ARCH
2022-04-14 15:30:16 <donoban> http://ix.io/3V9K
2022-04-14 15:32:00 <Hello71> smells like you put \ somewhere
2022-04-14 15:32:05 <Hello71> but anyways it still won't work
2022-04-14 15:32:31 <donoban> do you know something inspired by this that could work?
2022-04-14 15:33:27 <Hello71> well, i suggested CGO_CFLAGS=-fPIC already, which i think possibly works
2022-04-14 15:33:55 <donoban> I tried it today but maybe I didn't correctly
2022-04-14 15:34:28 <donoban> I just added export CGO_CFLAGS=-fPIC before calling cmake
2022-04-14 15:35:21 <Hello71> what exactly happens
2022-04-14 15:36:18 <donoban> it apparently build fines but when I start pidgin it says http://ix.io/3V9N
2022-04-14 15:36:31 <donoban> (17:35:42) plugins: /usr/lib/purple-2/libwhatsmeow.so is not loadable: Error relocating /usr/lib/purple-2/libwhatsmeow.so: sqlite3_autovacuum_pages: initial-exec TLS resolves to dynamic definition in /usr/lib/purple-2/libwhatsmeow.so
2022-04-14 15:36:56 <Hello71> can you post build log
2022-04-14 15:37:09 <donoban> yeah, with CGO_CFLAGS=-fPIC ?
2022-04-14 15:38:01 <donoban> take a look first to the APKBUILD if you want http://ix.io/3V9R
2022-04-14 15:43:46 <donoban> build log -> http://ix.io/3V9T
2022-04-14 15:49:54 <Hello71> i guess it would be better to use system sqlite3 anyways
2022-04-14 15:50:20 <Hello71> export GOFLAGS="$GOFLAGS -tags=libsqlite3"
2022-04-14 15:50:57 <donoban> let's try
2022-04-14 15:53:23 <donoban> different error now: (17:52:56) plugins: /usr/lib/purple-2/libwhatsmeow.so is not loadable: Error relocating /usr/lib/purple-2/libwhatsmeow.so: sqlite3_set_authorizer: symbol not found
2022-04-14 16:14:01 <Hello71> ah, also need to add -lsqlite3 to final link line
2022-04-14 16:14:34 <Hello71> don't remember how to do this in cmake. possibly like target_link_libraries(whatsmeow -lsqlite3)?
2022-04-14 16:15:21 <donoban> ok, let me check
2022-04-14 16:31:04 <donoban> wow Hello71 , now I get a segfault :\
2022-04-14 16:46:37 <Hello71> maybe that's better
2022-04-14 17:34:51 <craftyguy> any chance this could get a re-review? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32400
2022-04-14 17:40:40 <craftyguy> Ariadne: thank you :)
2022-04-14 17:42:00 <PiRATA> how long does it take to create a MR from the mailing list?
2022-04-14 18:02:18 <ikke> Should be nearly instantly 
2022-04-14 18:19:09 <bl4ckb0ne> how can I label a dep as optional in an apkbuild file
2022-04-14 18:37:24 <Hello71> omit it
2022-04-14 18:38:45 <boomanaiden154> I believe apk v3 has supported for optional dependencies, but alpine is still on apk v2.
2022-04-14 18:57:20 <jvoisin> https://www.phoronix.com/scan.php?page=news_item&px=Chromium-Qt-WIP packaging Hell in 3…2…
2022-04-14 20:02:36 <bl4ckb0ne> i guess ill just add it as a regular dep
2022-04-14 20:03:45 <panekj> how "optional" it is
2022-04-14 20:15:25 <bl4ckb0ne> its for hw acceleration
2022-04-14 20:35:23 <donoban> is this backtrace normal when debugging a nonstripped binary? http://ix.io/3Vb2
2022-04-14 20:39:17 <donoban> well, let's rebuild again with --enable-debug
2022-04-14 20:43:03 <donoban> nothing
2022-04-14 20:43:34 <donoban> /usr/lib/libpurple.so.0.14.8: ELF 64-bit LSB shared object, x86-64, version 1 (S
2022-04-14 20:43:35 <donoban> YSV), dynamically linked, stripped
2022-04-14 20:43:40 <donoban> maybe the problem is this
2022-04-14 21:01:30 <EvTheFuture> Newbie question... When approximately will 3.16 be branched and no more new aports accepted from testing?
2022-04-14 21:06:36 <panekj> 3.16 is planned for May
2022-04-14 21:08:34 <EvTheFuture> Yes I know, but will there be a branch followed by testing (functional freeze) for a couple of weeks, or how does the process look like? I'm thinking of moving a couple of aports from testing to community before 3.16 (which is why I'm asking)
2022-04-14 22:01:34 <Hello71> not really a formal process. it is branched then tested but no specific timeline afaik
2022-04-14 22:01:45 <Hello71> theoretically packages can be moved even after release
2022-04-14 22:24:04 <EvTheFuture> Hello71: Thanks for the info
2022-04-14 22:24:41 <Hello71> main focus of freeze is toolchain packages, then stuff on release ISO
2022-04-14 22:25:05 <Hello71> it is not good to build all packages and then have to update gcc and then build all packages again
2022-04-14 23:26:10 <omni> ncopa: thanks!
2022-04-14 23:31:20 <psykose> omni: thanks!
2022-04-14 23:41:57 <omni> <3
2022-04-14 23:44:22 <psykose> <3
2022-04-14 23:45:16 <omni> wrt !33190 what if we un-bump the failing aports and open an issue/separate MRs for them?
2022-04-14 23:47:46 <psykose> sure, put them in a separate mr, and i will have a look
2022-04-14 23:47:50 <psykose> if you get the ci to pass i will merge it
2022-04-14 23:50:32 <omni> I'll see if I can do it now
2022-04-14 23:52:46 <omni> psykose: do you think I should unbump those where I've disabled tests to look closer at them in separate MRs? even though they'll pass ci with tests disabled
2022-04-14 23:53:04 <psykose> the tests probably just flake and pass on retry
2022-04-14 23:53:12 <psykose> a ton of the go rebuild stuff just gets restarted 1-2 times and pass
2022-04-14 23:53:14 <psykose> so yes, sure
2022-04-14 23:53:22 <psykose> fails + failed tests in separate mr
2022-04-14 23:53:45 <psykose> (a lot of them are failures due to random networking, if you look, generally)
2022-04-14 23:53:52 <psykose> i.e. something fails to get a response in 50ms and fails, lol
2022-04-14 23:54:32 <psykose> i.e. all of the 1.18.1 rebuilds are done now, and i did absolutely nothing except restart them a few times
2022-04-14 23:54:36 <psykose> but there was a ton of test failures
2022-04-15 00:16:29 <omni> psykose: I marked it as ready and opened #13701
2022-04-15 00:16:41 <psykose> thanks for the fantastic work :)
2022-04-15 00:17:30 <omni> several archs timed out earlier, but perhaps there's more resources now
2022-04-15 00:18:09 <omni> psykose: you too, and thank you for the kind words
2022-04-15 00:18:17 <omni> I'll close the lid now
2022-04-15 00:19:15 <psykose> !33257
2022-04-15 00:19:18 <psykose> sleep well :)
2022-04-15 02:38:39 <psykose> nmeum: i know you _really_ love ppc, so there is another issue- binutils 2.38 is broken in some builds when linking things on ppc. example: https://gitlab.alpinelinux.org/nibon7/aports/-/jobs/691244
2022-04-15 02:38:43 <psykose> i've seen this on 3-4 builds
2022-04-15 02:38:50 <psykose> i think testing/wpewebkit too, and somewhere else
2022-04-15 02:39:15 <psykose> there was /another/ issue related to darn as well, but we backported acc110c98c7fe6ac495078ef1212e85711cb75f3 for it
2022-04-15 02:39:42 <psykose> all of those build fine with 2.37
2022-04-15 02:44:20 <psykose> another: glog https://gitlab.alpinelinux.org/z3ntu/aports/-/jobs/683793
2022-04-15 02:57:55 <psykose> made #13702
2022-04-15 09:34:15 <omni> how to handle when there is an XSA but a CVE is Not (yet) Assigned? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33263/diffs#fc1d2d73da8ddff843be499bceee18b7de65b969_272_277
2022-04-15 09:35:13 <ikke> Just leave it out
2022-04-15 09:35:19 <ikke> and add it when it's known
2022-04-15 09:35:27 <psykose> just put the xsa
2022-04-15 09:35:39 <psykose> by itself
2022-04-15 09:36:41 <omni> ok, thanks
2022-04-15 09:36:57 <omni> I think something broke with lab-0.24.0 =(
2022-04-15 09:39:21 <psykose> what's that
2022-04-15 09:39:27 <psykose> as in what broke
2022-04-15 09:40:26 <omni> sorry for being vague, 'lab ci trace ...' broke for me, so I just downgraded to 0.23.0-r2 and will look at it later
2022-04-15 09:40:55 <omni> hmm.. https://gitlab.alpinelinux.org/alpine/aports/-/commit/55d655af775904df28d0cc1b929a961e0b9bf4e3
2022-04-15 09:41:06 <omni> should I remove the comment about armv7?
2022-04-15 09:41:26 <omni> why was armhf replaced with armv7?
2022-04-15 09:42:27 <psykose> no idea
2022-04-15 09:43:07 <omni> ncopa: ^^ perhaps you'll read this next week
2022-04-15 09:43:53 <omni> I'll just leave the comment for now, to not forget about it, and mark this as ready
2022-04-15 09:44:24 <omni> !33263
2022-04-15 10:29:19 <ncopa> i think we switched to armv7 over armv6 for xen
2022-04-15 10:29:29 <ncopa> probably because xen does not support armv6
2022-04-15 10:35:54 <PiRATA> sent a .diff to update github-cli yesterday but no MR was created :<
2022-04-15 10:36:54 <PiRATA> tested on x86_64 and gonna try on armv7
2022-04-15 10:39:08 <omni> ncopa: oh, hi!  I thought you had weekends off =)
2022-04-15 10:39:27 <omni> not supported as in does not work or as in won't get support from upstream?
2022-04-15 10:39:41 <omni> we've still built it for a while
2022-04-15 10:41:28 <omni> !33265 !33266
2022-04-15 10:42:07 <omni> oh, should've prefixed those [3.15] and [3.14]
2022-04-15 10:43:29 <PiRATA> omni, create MR requires permissions on gitlab, right?
2022-04-15 10:44:52 <psykose> if by permissions you mean you make an account
2022-04-15 10:44:53 <psykose> but not
2022-04-15 10:45:14 <omni> and you can also do it with a github or gitlab.com account, right?
2022-04-15 10:45:37 <PiRATA> nah, I'm logged in with gitlab
2022-04-15 10:45:52 <PiRATA> and don't have any option to create MR
2022-04-15 10:45:58 <PiRATA> only issues
2022-04-15 10:47:28 <omni> did you create a gitlab.alpinelinux.org account or use your gitlab.com account?
2022-04-15 10:48:51 <omni> how did you send a .diff? I've only created local branches, pushed and created MRs from there
2022-04-15 10:49:22 <PiRATA> use my gitlab account
2022-04-15 10:49:48 <panekj> so https://gitlab.alpinelinux.org/pj/aports/-/merge_requests/new this doesn't work for you?
2022-04-15 10:49:53 <panekj> oops
2022-04-15 10:50:20 <PiRATA> sent to mailing list
2022-04-15 10:50:23 <PiRATA> https://lists.alpinelinux.org/~alpine/aports/%3Cd38760004c117b1f6626a07274971f22aba97974.camel%40riseup.net%3E
2022-04-15 10:50:24 <panekj> oh great, gitlab points to own fork 
2022-04-15 10:51:01 <PiRATA> yeah, 404 for me
2022-04-15 10:51:40 <panekj> you could just replace 'pj' with your username
2022-04-15 10:52:05 <panekj> that patch from ml might have just got lost in a void
2022-04-15 10:53:18 <PiRATA> let me try
2022-04-15 11:07:07 <PiRATA> nah, even with own account on gitlab.alpinelinux.org
2022-04-15 11:07:40 <PiRATA> only allow to open issues, not MR
2022-04-15 11:12:30 <knuxify> does adding a dbus service to dependencies, as in dbus:org.freedesktop.<service name>, make sure that the service is running?
2022-04-15 11:13:30 <knuxify> ...i'm realizing i worded this wrong
2022-04-15 11:13:51 <knuxify> anyways - i'm taking another look at gtk4.0 tests, and the printer tests require org.freedesktop.Avahi to be available
2022-04-15 11:14:41 <PiRATA> thanks ptrcnull :)
2022-04-15 11:16:17 <PiRATA> btw, I think you deleted $pkgname
2022-04-15 11:17:34 <knuxify> the dbus avahi bus should be available when installing avahi, but i've noticed that on my system when avahi-daemon is not running the bus is unavailable :p might be an inconvenience if someone has avahi installed but not running on their system (installing it seems to start the daemon, so i'm not concerned about that)
2022-04-15 11:18:22 <knuxify> doubt there's a way to force-start a service in an apkbuild, so it's probably best to leave these disabled, especially since they're not that important
2022-04-15 11:18:46 <knuxify> or just ignore this and let people figure out why the tests are failing when they try to upgrade gtk4.0 or build it manually for whatever reason :p
2022-04-15 11:18:48 <PiRATA> *ptrc
2022-04-15 11:25:26 <PiRATA> dbus + avahi, u running GNOME, knuxify?
2022-04-15 11:35:16 <ptrc> PiRATA: oh right, accidentally removed it while fixing merge conflicts, thanks
2022-04-15 11:42:55 <PiRATA> ahhhh, nevermind
2022-04-15 11:42:58 <PiRATA> got it
2022-04-15 11:43:20 <PiRATA> needed to fork the aports repo first
2022-04-15 12:47:44 <pmanolov> hey guys, i'm having problems getting wlan0 up on rpi4 and alpine 3.15.4
2022-04-15 12:48:55 <pmanolov> i came accross a brief note that brcm firmware has been moved to cypress dir, did the mksquashfs dance to add the latter to modloop, but still no joy
2022-04-15 12:50:25 <pmanolov> that brief note also mentioned that this problem originated from 3.14, what are the chances of this still not being fixed?
2022-04-15 12:51:46 <ncopa> patches are welcome...
2022-04-15 12:51:56 <ncopa> dont have time to trouble shoot that right now unfortunately
2022-04-15 12:53:06 <ncopa> what would be useful: if you could try install it as sys install on your sd card (using ethernet cable) then try find the correct firmware and test that it works
2022-04-15 12:53:13 <ncopa> then report which firmware is needed
2022-04-15 12:53:56 <ncopa> and see fi https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/linux-firmware can be fixed
2022-04-15 12:54:21 <pmanolov> ok, will take a look
2022-04-15 12:55:13 <ncopa> have also a look at the commit history https://gitlab.alpinelinux.org/alpine/aports/-/commits/master/main/linux-firmware/APKBUILD
2022-04-15 12:55:32 <ncopa> i think at some point we had rpi specific firmware but it was claimed that it went upstream
2022-04-15 12:55:35 <ncopa> but i dont know
2022-04-15 12:56:17 <pmanolov> i will have to first figure out which is the correct firmware file
2022-04-15 12:56:26 <ncopa> thanks
2022-04-15 12:57:25 <pmanolov> i've got a couple of rpi0-w and they are OK, but that's a different wifi anyway
2022-04-15 12:59:30 <pmanolov> the thing is, i'm able to do a scan with wlan0, but can't associate to a ssid
2022-04-15 12:59:38 <pmanolov> whatever is broken is somewhat subtle
2022-04-15 13:01:20 <psykose> if you can scan at all i would imagine the firmware is there
2022-04-15 13:01:33 <psykose> since without it normally you don't even see wlan0
2022-04-15 13:02:32 <pmanolov> yeah, i see wlan0 in /proc/net/dev
2022-04-15 13:02:54 <pmanolov> i get errors when i try to manually assign it to a ssid
2022-04-15 13:03:12 <pmanolov> so 'some' firmware is definitely there, but is it the right one
2022-04-15 13:03:36 <psykose> it can only be 'old', i'm pretty sure the loader does not load completely wrong firmware
2022-04-15 13:04:06 <psykose> it's.. possible for 'new' firmware to somehow have ended up in another package, but that doesn't sound likely
2022-04-15 13:04:37 <pmanolov> went for 'sys' installation in order to experiment some more
2022-04-15 13:04:53 <psykose> good luck
2022-04-15 13:06:18 <pmanolov> err, thanks :)
2022-04-15 14:06:10 <PiRATA> i'm getting these errors from apk:
2022-04-15 14:06:14 <PiRATA> ERROR: Unable to lock database: temporary error (try again later)
2022-04-15 14:06:16 <PiRATA> ERROR: Failed to open apk database: temporary error (try again later)
2022-04-15 14:06:20 <psykose> something locked it
2022-04-15 14:06:43 <psykose> are you sure nothing is running and doing things
2022-04-15 14:07:29 <PiRATA> ah, apk-polkit-server took a bit more
2022-04-15 14:23:32 <PiRATA> is there any procedure diff between updating a pkg on edge compared to stable?
2022-04-15 14:23:39 <ikke> 1No
2022-04-15 14:24:05 <ikke> But, we try to prevent breaking changes when updating packages on stable branches
2022-04-15 14:24:28 <PiRATA> yeah, I'm updating deja-dup
2022-04-15 16:22:47 <pmanolov> well, no luck
2022-04-15 16:23:17 <pmanolov> decided to go the easy way and installed rasbian on an rpi4 and got the same result there
2022-04-15 16:23:53 <pmanolov> rasbian is using slightly newer firmware blob, but that's it 
2022-04-15 16:24:01 <psykose> mm
2022-04-15 16:24:15 <psykose> have you tried only wpa_supplicant or iwd too
2022-04-15 16:26:55 <pmanolov> only wpa_supplicant
2022-04-15 16:27:25 <Hello71> what do you mean "can't associate to a ssid"
2022-04-15 16:28:04 <pmanolov> wlan0 does not get associated to neither of my wifi network
2022-04-15 16:28:44 <pmanolov> tried it on two different rpi4s
2022-04-15 16:30:39 <pmanolov> i also tried to manually associate the interface with iwconfig, no joy
2022-04-15 16:33:27 <pmanolov> 'ip link set dev wlan0 up' does not seem to bring the interface up either
2022-04-15 16:41:14 <pmanolov> afk
2022-04-15 19:43:51 <pmanolov> hmm, 'iwd' did the trick - it can successfully associate with the AP
2022-04-15 19:44:44 <pmanolov> so the problem is not the firmware as such
2022-04-15 19:48:46 <pmanolov> i'm really curious what's the matter with wpa_supplicant, if that's the actual culprit
2022-04-15 19:52:40 <psykose> reason: it bad
2022-04-15 19:55:07 <bl4ckb0ne> psykose: so we roll with a post-install msg for jellyfin-web?
2022-04-15 19:55:17 <psykose> sounds like the usual case
2022-04-15 19:55:26 <bl4ckb0ne> "please yeet the '--nowebclient' option from /etc/conf.d/jellyfin" ?
2022-04-15 19:55:36 <psykose> with a few more words, yeah
2022-04-15 19:55:49 <bl4ckb0ne> damn, my only weakness
2022-04-15 19:55:50 <psykose> 'the default jellyfin configuration does not enable ... edit xyz to enable it, : '
2022-04-15 19:56:03 <psykose> aaaand
2022-04-15 19:56:06 <psykose> test the hw ffmpeg stuff
2022-04-15 19:56:11 <bl4ckb0ne> aye
2022-04-15 19:56:11 <psykose> looking at their fork....
2022-04-15 19:56:16 <bl4ckb0ne> im at the testing stage
2022-04-15 19:56:21 <psykose> all they do is bump deps and fix some random specific issues
2022-04-15 19:56:36 <bl4ckb0ne> ffmpeg5 should be fine
2022-04-15 19:56:51 <bl4ckb0ne> idk if they changed much in their cli interface
2022-04-15 19:57:02 <psykose> not for anything resembling basic usage at least
2022-04-15 19:57:14 <psykose> maybe it they are doing complete crazy 2000 char long cmdlines something changed
2022-04-15 20:04:00 <bl4ckb0ne> also i think the jellyfin-web package size could be reduced but i lack the js packaging knowledge
2022-04-15 20:04:17 <bl4ckb0ne> (its a whooping 450mb)
2022-04-15 20:06:28 <bl4ckb0ne> >[16:04:57] [INF] [1] MediaBrowser.MediaEncoding.Encoder.MediaEncoder: FFmpeg: ffmpeg
2022-04-15 20:06:37 <bl4ckb0ne> i think the ffmpeg hw acceleration is working
2022-04-15 20:07:42 <bl4ckb0ne> hm the ui hangs
2022-04-15 20:07:46 <bl4ckb0ne> that aint good
2022-04-15 20:10:16 <psykose> definitely not
2022-04-15 20:11:05 <psykose> uhh there is no js packaging knowledge
2022-04-15 20:11:13 <psykose> we don't keep our own js unvendored modules in aports
2022-04-15 20:11:20 <psykose> that would be.... a lot of effort, lol
2022-04-15 20:11:28 <psykose> and still 450mb with everything pulled
2022-04-15 20:12:20 <bl4ckb0ne> there was with yarn, you just had to copy the dist folder once done
2022-04-15 20:12:31 <bl4ckb0ne> but now they are using npm and there's no info
2022-04-15 20:12:41 <psykose> that's still the same files, unless you are copying over the entire repo
2022-04-15 20:13:09 <psykose> you are
2022-04-15 20:13:10 <psykose> ok, sec
2022-04-15 20:13:14 <bl4ckb0ne> atm im copying the entire repo because i dont know which files i need
2022-04-15 20:14:19 <bl4ckb0ne> seems like I missed https://github.com/jellyfin/jellyfin-web/tree/master/deployment
2022-04-15 20:14:47 <psykose> that's just some dockerfiles
2022-04-15 20:14:48 <psykose> but yes
2022-04-15 20:14:54 <psykose> apparently the env ARTIFACT_DIR
2022-04-15 20:14:59 <psykose> let's you specify a folder
2022-04-15 20:15:04 <bl4ckb0ne> https://github.com/jellyfin/jellyfin-web/blob/master/deployment/build.portable
2022-04-15 20:15:37 <psykose> https://github.com/jellyfin/jellyfin-web/blob/master/deployment/build.portable#L17=
2022-04-15 20:15:39 <psykose> ye
2022-04-15 20:15:59 <psykose> just those 3 steps
2022-04-15 20:16:02 <psykose> then you can install
2022-04-15 20:16:12 <bl4ckb0ne> on it
2022-04-15 20:18:19 <bl4ckb0ne> wew it even fixes the webpack issue i had
2022-04-15 20:19:00 <psykose> was it related to perms
2022-04-15 20:19:09 <psykose> because that passes --unsafe-perm :p
2022-04-15 20:19:15 <bl4ckb0ne> probably
2022-04-15 20:19:24 <psykose> but yeah sounds about right
2022-04-15 20:19:33 <bl4ckb0ne> it was that user required validation
2022-04-15 20:19:45 <bl4ckb0ne> i think `npm ci` takes care of that on its own
2022-04-15 20:19:49 <psykose> think so
2022-04-15 20:19:59 <bl4ckb0ne> i could check if --unsafe-perm can be removed
2022-04-15 20:20:49 <bl4ckb0ne> build times is going up tho
2022-04-15 20:21:21 <bl4ckb0ne> >jellyfin-web*: Package size: 53.3 MB
2022-04-15 20:21:30 <bl4ckb0ne> way better eh
2022-04-15 20:21:51 <psykose> lol
2022-04-15 20:21:56 <psykose> yeah no shit
2022-04-15 20:22:05 <psykose> glad you pointed it for a moment
2022-04-15 20:22:19 <psykose> because i honestly don't flinch at 450mb with the horrors i've seen and thought it was legit
2022-04-15 20:22:27 <bl4ckb0ne> same 
2022-04-15 20:25:09 <bl4ckb0ne> works without --unsafe-perm
2022-04-15 20:26:44 <psykose> i think they had it because the other scripts mount shit into docker and the perms are fucked
2022-04-15 20:26:55 <bl4ckb0ne> thats entirely possible
2022-04-15 20:27:01 <psykose> speaking of which, i just had to go through five files to find that they called 'npm ci' only in the last one
2022-04-15 20:27:30 <psykose> yes, a dockerfile that calls a build.sh that calls a fedora build that calls a fedora makefile that calls a fedora.spec
2022-04-15 20:27:33 <psykose> very profound
2022-04-15 20:28:06 <bl4ckb0ne> https://github.com/jellyfin/jellyfin-web/blob/master/fedora/jellyfin-web.spec#L37
2022-04-15 20:28:11 <psykose> yep
2022-04-15 20:28:33 <bl4ckb0ne> yeah that whole "pls use docker to build because we dont want to bother" is dissapointing
2022-04-15 20:32:56 <bl4ckb0ne> https://a.uguu.se/ckdMxTpK.png runs fine o/
2022-04-15 20:39:49 <bl4ckb0ne> i think its done, openrc service works
2022-04-15 21:08:05 <bl4ckb0ne> psykose:  cheers :D
2022-04-15 21:08:14 <psykose> ^^
2022-04-15 21:11:01 <psykose> you forgot an install=
2022-04-15 21:11:02 <psykose> hehe
2022-04-15 21:12:43 <psykose> (fixed for you)
2022-04-15 21:15:31 <bl4ckb0ne> thanks
2022-04-15 21:15:42 <bl4ckb0ne> ill migrate from podman tonight
2022-04-15 21:19:57 <psykose> bl4ckb0ne: is there a config for the networking
2022-04-15 21:20:09 <psykose> the docs just say 'the default xyz is something something, you can change this in the dashboard'
2022-04-15 21:20:24 <psykose> could i instead set localhost:port somewhere else
2022-04-15 21:24:01 <bl4ckb0ne> default is 8096
2022-04-15 21:24:19 <psykose> i know
2022-04-15 21:24:25 <bl4ckb0ne> idk where to set ig
2022-04-15 21:24:31 <psykose> rip
2022-04-15 21:24:45 <bl4ckb0ne> i think there's a conf file
2022-04-15 21:25:44 <ikke> that feeling when you just pushed and update and then the project releases another version
2022-04-15 21:26:22 <omni> docker -> podman -> ?
2022-04-15 21:26:57 <bl4ckb0ne> native!
2022-04-15 21:33:32 <omni> as a Xen scholar, I've been wanting to try RunX
2022-04-15 21:34:08 <psykose> when do you graduate
2022-04-15 21:35:18 <bl4ckb0ne> psykose: found the settings, you need to start it once and its int the advanced/networking setting
2022-04-15 21:36:46 <omni> when I reach निर्वाण
2022-04-15 21:36:57 <psykose> bl4ckb0ne: uh where
2022-04-15 21:37:22 <psykose> omni: :)
2022-04-15 21:38:01 <bl4ckb0ne> on the webui
2022-04-15 21:38:15 <psykose> yeah, i mean without the webui
2022-04-15 21:38:21 <psykose> but that's ok
2022-04-15 21:38:24 <bl4ckb0ne> havent found out where
2022-04-15 21:39:11 <bl4ckb0ne> there's /var/lib/jellyfin/config/network.xml but its cursed
2022-04-15 21:39:30 <psykose> not present for me so i guess it only writes once you change a default
2022-04-15 21:39:31 <psykose> hah
2022-04-15 21:39:58 <bl4ckb0ne> it pops when you run the openrc service, otherwise its somewhere in ~/.local by default
2022-04-15 21:40:08 <psykose> i already have
2022-04-15 21:40:27 <psykose> okay
2022-04-15 21:40:31 <psykose> doing it /again/ put it there
2022-04-15 21:41:29 <psykose> now just to read magical dotnet docs to figure out what a virtual interface is and which one is localhost
2022-04-15 21:41:32 <psykose> unless that is just default
2022-04-15 21:42:10 <psykose> mm, nope
2022-04-15 21:42:15 <psykose> thanks! i'll figure it out
2022-04-15 21:50:49 <bl4ckb0ne> good luck
2022-04-15 22:49:11 <omni> !28509
2022-04-16 07:05:13 <ikke> That's a new one: 'the given path has multiple possibilities: #<Git::Ref:0x00007f3f156109a8>, #<Git::Ref:0x00007f3f15616768>'
2022-04-16 08:16:49 <ikke> PureTryOut: There are some kde related projects that fail to build due to: 'CMake Error at /usr/share/ECM/kde-modules/KDEMetaInfoPlatformCheck.cmake:69 (message): Your current platform 'Linux' is not supported. The list of supported platorms is '''
2022-04-16 09:10:57 <donoban> I'm thinking on add a reusable root dir option, trying to fix purple-gowhatsapp I'm rebuilding many times pidgin/glib/purple-gowhatsapp, and it seems a waste of time
2022-04-16 09:13:15 <ikke> donoban: sounds like you _don't_ want to use rootbld :P
2022-04-16 09:13:37 <donoban> maybe rootbld would be better a abuild conf, passed as --rootbld or setup on /etc/abuild.conf, and instead having a hardcoded loop of parts it just calls the original abuild script inside the chroot
2022-04-16 09:16:01 <donoban> ikke: well, I like to build things without modifying my system and it could used to build with different alpine versions
2022-04-16 09:16:44 <ikke> Use docker containers :)
2022-04-16 09:18:29 <ikke> If you'd have reusable directories for rootbld, it defeats its purpose
2022-04-16 09:18:57 <donoban> but it would be something optional enabled
2022-04-16 09:19:01 <donoban> like abuild -k/K
2022-04-16 09:19:43 <donoban> you only enable it when you know that you are doing something very prone to fail on some part of the build, or want to patch and repatch adding debug
2022-04-16 09:20:18 <donoban> I also could get the sources and build them directly, then add debug messages or test things, and remake
2022-04-16 09:20:25 <donoban> but using rootbld it's more cleaner
2022-04-16 09:33:29 <donoban> well, it's something easy to hack and get my desired behaviour, but I would like to do it in some way useful for other people using rootbld
2022-04-16 10:49:32 <donoban> I see a different approach than keeping the whole chroot dir (which is fast to rebuild with apk-cache), currently rootbld builds the package on "$BUILD_ROOT/tmp/" 'src' and 'pkg' so all useful tmp files are inside the chroot dir
2022-04-16 10:53:18 <donoban> I think that it could bind the real aports user dir, in case of call it with -K just don't cleanup it
2022-04-16 10:54:12 <donoban> (I mean the dir of the package that it's building, e.g. ~/aports/community/st/
2022-04-16 10:56:09 <donoban> then you can easily modify the souces, rebuild, run directly the new binaries (if you already have the package installed you should have already the deps), when all seems ok, just cleanup 'rm -fr pkg src', run abuild again, apk upgrade, all nice
2022-04-16 11:36:33 <panekj> isn't that exactly what docker-abuild does?
2022-04-16 11:59:46 <donoban> maybe, but why use docker if you can avoid it :D
2022-04-16 12:00:27 <panekj> you don't need docker exactly
2022-04-16 12:00:36 <panekj> you can use podman
2022-04-16 12:09:37 <donoban> yep but why don't try to improve rootbld design? It's currently a 'command' like build/check/etc..., and I think that it should be threated as an option, and forward the commands to the chrooted abuild process
2022-04-16 12:10:04 <panekj> I think `abuild container` should be a command :)
2022-04-16 12:11:02 <donoban> why? it would mean how/where to do what you want to do, not doing something
2022-04-16 12:11:44 <panekj> it would behave exactly like rootbld
2022-04-16 12:12:04 <panekj> but if you care about word meaning then i guess it can be called `containerbld`
2022-04-16 12:12:13 <donoban> no
2022-04-16 12:12:46 <donoban> my problem is that using rootbld as currently it's, it then calls another abuild process inside the chroot with a fixed args
2022-04-16 12:13:34 <donoban> I would find useful to have the same flexiblity that you have with std abuild, but using a chroot/rootbld/container..
2022-04-16 12:14:22 <donoban> e.g. 'abuild --rootbld deps build'
2022-04-16 12:14:36 <panekj> sure, I'm all for that
2022-04-16 12:14:45 <donoban> or 'abuild --rootbld deps prepare build'
2022-04-16 12:15:03 <donoban> using also -K to avoid all being cleaend up
2022-04-16 12:15:29 <donoban> and, since I would be using rootbld most of the time, could configure it on /etc/abuild.conf and forgive about it
2022-04-16 12:16:14 <donoban> the same design could be used for docker/podman 
2022-04-16 12:19:23 <donoban> s/forgive/forget
2022-04-16 12:19:23 <alpine-meetbot> donoban meant to say: and, since I would be using rootbld most of the time, could configure it on /etc/abuild.conf and forget about it
2022-04-16 14:00:47 <Ariadne> panekj: `abuild container` would be something to start a shell inside the build env?
2022-04-16 14:23:39 <panekj> could be :) I was mostly lacking `abuild` but as oci container since rootbld quite often is broken for me and I needed full isolation
2022-04-16 14:23:59 <panekj> and was a bit sad to see that docker-abuild is abandoned
2022-04-16 14:25:40 <panekj> Ariadne: didn't you start working on abuild replacement or am I misremembering 
2022-04-16 14:25:52 <ikke> apko
2022-04-16 14:25:54 <Ariadne> i would not say "replacement"
2022-04-16 14:26:02 <ikke> oh no, melange
2022-04-16 14:26:06 <Ariadne> melange is philosophically quite different than abuild
2022-04-16 14:26:26 <Ariadne> though in theory it would be possible to run abuilds under melange engine
2022-04-16 14:26:29 <panekj> yeah, I'm aware of both and they don't quite fit `abuild`
2022-04-16 14:26:35 <panekj> thus why I ask
2022-04-16 14:27:06 <Ariadne> outside of adelie, there aren't any other apk distributions using abuild
2022-04-16 14:27:28 <ikke> pmos, though it's more of a derivative
2022-04-16 14:27:43 <panekj> Wanted to package melange but no tagged release
2022-04-16 14:27:54 <Ariadne> yeah it's not quite ready yet to release
2022-04-16 14:28:34 <panekj> will need to mess with it and see, I've only played with apko so far
2022-04-16 14:29:02 <Ariadne> melange builds a package given a declared apko environment
2022-04-16 14:29:16 <Ariadne> there is another tool we will be releasing soon
2022-04-16 14:29:47 <Ariadne> it is basically like CoreOS ignition, but it uses apko to install an apk distribution to disk
2022-04-16 14:34:28 <panekj> that's nice
2022-04-16 14:41:32 <oneinsect> :-)
2022-04-16 15:15:11 <donoban> Ariadne: panekj , for getting a shell inside the build env wouldn't be better a explicity command (like build, prepare, clean, etc..) than you can call regardless the container tecnology? e.g. abuild deps fetch prepare build shell package..., so you can open a shell wherever you want into the build chain, or even opening multiple shell in differents moments
2022-04-16 15:18:31 <PureTryOut> ikke: yeah I saw one failing like that, not sure where that comes from. Packages have recently switched to Samurai and RelWithDebInfo as build type, maybe it comes from there somehow
2022-04-16 16:10:25 <psykose> they were rebuilt with it fine
2022-04-16 16:10:47 <psykose> i would assume it's just an issue of the ecm upgrade
2022-04-16 16:10:49 <psykose> a673c9aafe18292bc78cb9f45116fdb8f0de5b46
2022-04-16 16:10:52 <psykose> from 6 days ago
2022-04-16 16:11:05 <psykose> some things use it that are not part of kde i think
2022-04-16 16:11:14 <psykose> it's worked around with an extra -D, but no idea why it fails
2022-04-16 18:40:01 <psykose> ah, figured it out
2022-04-16 18:40:24 <psykose> the specific project i fixed (kmouth) includes KDEFrameworkCompilerSettings
2022-04-16 18:40:32 <psykose> on 5.92.0 this just included some stuff
2022-04-16 18:40:48 <psykose> on 5.93.0 it also includes KDEMetaInfoPlatformCheck
2022-04-16 18:40:58 <psykose> which checks for $projectroot/metainfo.yaml
2022-04-16 18:41:10 <psykose> these old projects don't have it, so it assumes they support 0 platforms, then fails with that error
2022-04-16 18:41:42 <psykose> yeah, it's as meaningless as i though it was, and just stale unupdated build systems for these old kde projects that still use the kde ecm modules but haven't updated in forever
2022-04-16 18:42:19 <psykose> -DKF_IGNORE_PLATFORM_CHECK=ON would fix every single one where it's run into
2022-04-16 19:12:04 <Newbyte> How do you deal with pyproject.toml again?
2022-04-16 19:12:48 <ikke> py3-build + py3-installer
2022-04-16 19:15:09 <Newbyte> thanks. nice to see that it's been figured out
2022-04-16 19:18:56 <ikke> Newbyte: an example: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/py3-testpath/APKBUILD
2022-04-16 19:19:38 <Newbyte> I actually ended up looking at that specific one 🤔 But thanks nonetheless!
2022-04-16 19:19:46 <ikke> haha :D
2022-04-16 20:41:21 <psykose> if it's going into testing use py3-gpep517 instead of py3-build
2022-04-16 20:41:35 <psykose> for which there is no example :p
2022-04-16 21:29:55 <Asmadeus> psykose: thanks for merging my old hostapd MR. If you have an opinion on !32825 (adding chattr to either busybox or busybox-extras) I'd also appreciate it! :)
2022-04-16 21:38:16 <Hello71> seems fine to me
2022-04-16 21:38:38 <Hello71> normally busybox devs measure using "size" command which i think excludes padding
2022-04-16 21:42:23 <psykose> you need to bump the pkgrel again
2022-04-16 21:42:31 <psykose> aside from that, i would probably get shot for merging it
2022-04-16 21:42:34 <psykose> so i will do exactly that
2022-04-16 21:52:03 <Asmadeus> oh, identical pkgrel bumps don't generate merge conflicts.. bumped
2022-04-16 21:52:59 <Asmadeus> Hello71: hm, right. I no longer have the binaries around but could rebuild just the main package if that'd be useful
2022-04-16 21:57:48 <Asmadeus> (added bloatcheck in a comment)
2022-04-16 23:47:34 <psykose> PureTryOut: specifically, it's this https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/935c2abff7bf531a9758bf2fbdc6b0d8abe636e8
2022-04-16 23:47:41 <psykose> from https://invent.kde.org/frameworks/extra-cmake-modules/-/compare/v5.92.0...v5.93.0?from_project_id=2609
2022-04-16 23:47:51 <psykose> so, anything using this needs a metainfo, no exceptions :)
2022-04-16 23:49:29 <psykose> given how annoying this is (and our platform is always linux anyway), i would not be opposed to patching this file and just setting the default OFF to ON and bypassing this
2022-04-16 23:49:41 <psykose> because the check is useless in our packaging
2022-04-16 23:49:52 <psykose> but so far it's only two things that failed, so eh
2022-04-16 23:50:11 <psykose> ktimer, kmouth
2022-04-17 00:42:57 <panekj> donoban: Ariadne: I don't really care about semantics, I just want to have working ways of building stuff and easily fixing it, whether it will be `abuild debug`, `abuild shell`, or else. I like the idea of using flag instead of subcommand but would prefer `abuild --backend={bwrap,docker,podman,k8s,qemu,etc.} <subcommand>`, we probably won't care about anything other than bwrap officially, but it could be easily pluggable
2022-04-17 00:43:33 <psykose> the issue with any of this is nobody maintains abuild
2022-04-17 00:43:46 <psykose> and nobody also wants to touch it because everything depends on it, so any regressions break everything instantly
2022-04-17 00:43:59 <panekj> unfortunately
2022-04-17 00:44:14 <psykose> but at the same time, there is no way to really split into other tools, because then they would be different from the official builders, and can diverge too much to be accurate
2022-04-17 00:44:27 <psykose> even as is rootbld is nearly unusable in some cases because things fail in it that don't on the builders
2022-04-17 00:45:05 <psykose> notably i don't think xvfb-run tests work at all in it, but that is probably easily fixed
2022-04-17 00:45:16 <psykose> etc, etc
2022-04-17 02:50:21 <panekj> some CI builders have borked git
2022-04-17 02:50:30 <psykose> which ones
2022-04-17 02:50:57 <panekj> #126 (Bz6_moKw) shared-runner usa9 (armhf)
2022-04-17 02:51:00 <panekj> for example
2022-04-17 02:51:04 <psykose> ah i see
2022-04-17 02:51:14 <panekj> fatal: unsafe repo
2022-04-17 02:51:16 <psykose> those just worked a second ago
2022-04-17 02:51:39 <psykose> as in, on the same mr
2022-04-17 02:51:40 <psykose> lol
2022-04-17 02:51:41 <panekj> and I saw that issue few days ago on github as well, seems to be related to git vuln
2022-04-17 02:51:44 <psykose> yes
2022-04-17 02:51:51 <psykose> but ikke had a workaround and it was fixed since then..
2022-04-17 02:51:51 <psykose> strange
2022-04-17 06:21:13 <dhruvin> Can anyone please review !32410 ?
2022-04-17 06:21:56 <dhruvin> (If this is not the right place to request for review, let me know)
2022-04-17 06:25:57 <dhruvin> thanks psykose :)
2022-04-17 06:28:19 <psykose> actually made another amendment :)
2022-04-17 06:28:21 <psykose> now ok
2022-04-17 06:32:53 <dhruvin> I'll make sure to package custom licenses (if any, in future) accordingly
2022-04-17 06:33:19 <psykose> only if they say 'include this license file' really, but yeah
2022-04-17 06:33:22 <psykose> (they always do..)
2022-04-17 06:33:46 <psykose> (in)conveniently, it's not part of the zip
2022-04-17 06:33:56 <psykose> it perhaps should be
2022-04-17 06:34:38 <dhruvin> I'll ask upstream about it
2022-04-17 07:14:24 <PureTryOut> psykose: no need to patch anything, we can just set `KF_IGNORE_PLATFORM_CHECK` on the failing packages
2022-04-17 07:14:36 <psykose> yes, but patching it is equivalent to the same
2022-04-17 07:14:44 <psykose> and does not then need it being set :p
2022-04-17 07:15:20 <PureTryOut> ah you've already turned that check off I see
2022-04-17 07:16:42 <psykose> on those two things
2022-04-17 07:17:02 <PureTryOut> yes
2022-04-17 08:18:49 <lib2know> #alpine-linux
2022-04-17 08:54:03 <l2k> join #alpine-devel
2022-04-17 09:40:38 <donoban> panekj: I like the '--backend=...', I'm gonna try to remove hardcoded commands when using rootbld
2022-04-17 09:50:06 <panekj> when is ldconfig executed on alpine?
2022-04-17 09:50:23 <panekj> and where
2022-04-17 09:51:15 <psykose> no
2022-04-17 09:51:42 <panekj> psykose: not at all?
2022-04-17 09:51:49 <psykose> (i have no idea actually)
2022-04-17 09:51:55 <panekj> lol
2022-04-17 10:06:35 <panekj> apparently nowhere
2022-04-17 13:53:08 <hazem> hey sorry for the noise I made on the mailing list and gitlab.. this is my first patch to a mailing list and I'm struggling to get things right.
2022-04-17 13:53:35 <panekj> no worries
2022-04-17 13:58:21 <hazem> so right now I have this sent to the mailing list but it doesn't seem to reflect to gitlab:
2022-04-17 13:58:24 <hazem> https://lists.alpinelinux.org/~alpine/aports/patches/4032
2022-04-17 14:08:18 <hazem> I tried my best to follow the docs at alpine wiki and git-send-email
2022-04-17 14:08:46 <hazem> but i think it's something to do with --compose 
2022-04-17 14:08:46 <panekj> it's probably just stuck
2022-04-17 14:13:29 <ikke> hazem: I don't see that last patch in the logs
2022-04-17 14:14:02 <ikke> hazem: possible the cover letter has to do with it
2022-04-17 14:14:17 <ikke> The integration is not very sophisticated
2022-04-17 14:14:45 <panekj> I really recommend raising MRs via gitlab.a.o
2022-04-17 14:15:03 <panekj> less trouble with re-sending patches
2022-04-17 14:16:10 <hazem> yeah i followed the wiki on that cover letter thing.. i opted for the mailing list because i didn't want to have to use gitlab and make a new account, but it turned out to be more of a pain haha
2022-04-17 14:16:35 <ikke> hazem: do you have a gitlab.com or github account?
2022-04-17 14:16:58 <hazem> github but it's not linked to my alpine-specific email
2022-04-17 14:17:41 <ikke> I think you should be able to login with that github account, and then add your alpine e-mail in gitlab
2022-04-17 14:18:27 <hazem> yeah trying that rn. would be really grand if a mailing list admin just erased my embarrassment from existence :P
2022-04-17 14:19:27 <ikke> which ones
2022-04-17 14:21:32 <hazem> there are like 4 or 5 attempts with [PATCH *] community/{smlsharp,massivethreads}
2022-04-17 14:22:45 <hazem> apparently the "reply" button from the mailing list gui interacts in funny ways with gnome's geary because that too didn't respect thread replies and created those RE: standalone emails
2022-04-17 14:24:56 <hazem> 
ACTION shaking fist at the sky with a single tear

2022-04-17 14:25:41 <hazem> many thanks, ikke 
2022-04-17 14:26:12 <ikke> p00f
2022-04-17 14:26:38 <panekj> don't worry, people won't mind it
2022-04-17 14:26:50 <panekj> they have other person to be angry at today :P
2022-04-17 14:29:53 <hazem> (there's also these two https://lists.alpinelinux.org/~alpine/aports/%3Cd6ee105e6b8e04c7495142e287a765e2%40riseup.net%3E)
2022-04-17 14:29:57 <hazem> :pray:
2022-04-17 14:30:26 <hazem> panekj: i am not aware of the tea
2022-04-17 14:30:31 <ikke> which ones?
2022-04-17 14:30:32 <hazem> :P
2022-04-17 14:31:34 <panekj> the tea is in progress :) !33329
2022-04-17 14:31:45 <hazem> ikke: ahh im not sure *wink
2022-04-17 14:32:44 <hazem> my god, why
2022-04-17 14:32:59 <hazem> just checked the mr
2022-04-17 14:33:13 <hazem> year of the alpine desktop??
2022-04-17 14:33:17 <hazem> perhapsss
2022-04-17 14:33:26 <panekj> haha
2022-04-17 14:33:47 <Misthios> why does it have the on hold label toh ;)
2022-04-17 14:34:10 <panekj> some are misusing their privileges to oppose the idea
2022-04-17 14:34:27 <ptrc> no surprise there
2022-04-17 14:35:19 <ptrc> but i think it would be more of a year of the alpine desktop once chromium starts accepting musl patches
2022-04-17 14:35:39 <Misthios> not just alpine, it gives void musl more apps as well
2022-04-17 14:35:56 <ptrc> yeah, that too
2022-04-17 14:36:04 <Misthios> (and we just need nvidia to make musl builds as well but that wont happen )
2022-04-17 14:36:22 <panekj> and gentoo, chimera, adelie
2022-04-17 14:36:49 <ptrc> nouveau is decent, unless we're aiming for the year of the alpine gaming distro too :p
2022-04-17 14:37:30 <Misthios> welp there goes that plan
2022-04-17 15:03:59 <hazem> woot !33343
2022-04-17 19:53:04 <Newbyte> ptrc: my GPU sounds like a jet engine when I just look at my desktop with Nouveau
2022-04-17 20:03:00 <ptrc> hm, i don't have that issue
2022-04-17 20:03:03 <ptrc> it just works
2022-04-17 20:28:49 <sicelo> hi. i'm attempting to rebuild upower to test out https://gitlab.freedesktop.org/upower/upower/-/merge_requests/40 . unfortunately, i'm stuck where it tries to build docs. what can i add to my APKBUILD to prevent docs from being built? (i don't think i need them)
2022-04-17 20:30:04 <ikke> sicelo: where exactly does it fail?
2022-04-17 20:30:11 <ikke> Do you get an error message?
2022-04-17 20:33:41 <sicelo> yes, let me see if i can provide a link to the log
2022-04-17 20:37:49 <sicelo> i hope this is the relevant section, https://paste.debian.net/1238225/
2022-04-17 20:39:26 <ikke> add -Dgtkdoc=false
2022-04-17 20:39:48 <ikke> to the meson / abuild-meson call
2022-04-17 20:41:54 <sicelo> thanks. i'm on it. will report back shortly
2022-04-17 20:46:37 <Cogitri> 👋
2022-04-17 20:46:53 <ikke> Cogitri: hey, welcome back :)
2022-04-17 20:47:42 <Cogitri> ikke: thanks :)
2022-04-17 20:47:50 <Cogitri> Heh yes, I have been on hiatus for a while, writing my thesis right now
2022-04-17 20:48:04 <ikke> Is it progressing?
2022-04-17 20:48:56 <Cogitri> Yup, I’m comparing different C++ package manager thingies for my thesis and it’s going pretty smoothly right now (well as smooth as C++ can be :D)
2022-04-17 20:49:11 <ikke> haha
2022-04-17 20:49:22 <Cogitri> I have been wondering, do we require members of Gitlab teams to be core devs? Otherwise I’d like to propose two new members for the GNOME team if that’s possible
2022-04-17 20:49:42 <ikke> Cogitri: No, that's not required
2022-04-17 20:50:09 <Cogitri> Neat
2022-04-17 20:51:12 <Cogitri> Should I open an issue for that somewhere? :)
2022-04-17 20:53:49 <sicelo> ikke: no luck. i have it as follows, https://paste.debian.net/1238228/ 
2022-04-17 20:54:13 <ikke> Still the error with gtkdoc?
2022-04-17 20:54:21 <sicelo> i also tried "no" instead of false. in both cases, i get "meson.build:1:0: ERROR: Unknown options: "gtkdoc""
2022-04-17 20:55:19 <ikke> sicelo: ah, it's called gtk-doc
2022-04-17 20:55:26 <ikke> see meson_options.txt
2022-04-17 20:58:15 <sicelo> oh nice! thanks a mil. it's going through successfully now :-)
2022-04-17 20:58:48 <ikke> Cogitri: you could make an MR here: https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf
2022-04-17 20:59:24 <Cogitri> Will do, thanks 🙏
2022-04-17 21:07:14 <Cogitri> BTW, how’s stuff in Alpine land currently? :)
2022-04-17 21:07:22 <ikke> Working on 3.16
2022-04-17 21:07:47 <ikke> Someone made an MR to add systemd :)
2022-04-17 21:09:10 <Cogitri> Oh, I imagine that caused quite the stir :D
2022-04-17 21:09:33 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33329
2022-04-17 21:10:56 <Cogitri> Oh not quite the bomb shell I imagined :p
2022-04-17 21:11:36 <ikke> 24 reactions so far
2022-04-17 21:12:55 <Cogitri> Lucky us that no one posted this to HN or Reddit yet :D
2022-04-17 21:13:08 <minimal> yet.....
2022-04-17 21:13:13 <ikke> Ariadne tweeted about it
2022-04-17 21:14:36 <Cogitri> minimal: /me braces for impact :p
2022-04-17 21:15:18 <minimal> Cogitri: its Easter weekend, give it time lol
2022-04-17 21:17:35 <Cogitri> Fair :D
2022-04-17 21:18:04 <minimal> quickly followed by another MR for glibc? ;-)
2022-04-17 21:21:13 <Cogitri> Time for aaaalll the good stuff to be introduced :)
2022-04-17 21:52:01 <skarnet> I feel it quite important to nip that in the bud
2022-04-17 21:52:45 <skarnet> you know how these things go, as soon as they become acceptable discourse you can never get rid of them anymore
2022-04-17 23:19:16 <orbea> 29 custom patches, ouch
2022-04-18 01:32:44 <panekj> minimal: not planning on, but Ariadne + chainguard-dev are making glibc + apk distro
2022-04-18 01:33:43 <minimal> panekj: it was a joke...
2022-04-18 01:33:56 <panekj> I know
2022-04-18 01:34:09 <minimal> I thought their work was container specific, not for a distro
2022-04-18 01:34:47 <panekj> and what are containers if not a tiny OS in a tarball :)
2022-04-18 01:37:30 <minimal> especially as AFAIK they use "apk" to create the containers but (from memory) there's no package manager placed into the container, so its not really an (upgradable) OS at all. I wouldn't call them OSes as there's no (built-in) kernel
2022-04-18 01:38:10 <panekj> that's apko
2022-04-18 01:38:37 <minimal> I thought that was what you were referring to
2022-04-18 01:38:39 <panekj> "there is another tool we will be releasing soon"
2022-04-18 01:38:41 <panekj> "it is basically like CoreOS ignition, but it uses apko to install an apk distribution to disk"
2022-04-18 01:38:56 <minimal> ah ok
2022-04-18 01:39:16 <panekj> but the glibc distro is also planned
2022-04-18 04:41:21 <ikke> not sure what the status is, but there was someone else here who was building alpine with glibc
2022-04-18 05:38:29 <elibrokeit> panekj: I'm actually very curious why "this can be successfully packaged with only 4 thousand lines worth of patching" should be accepted
2022-04-18 05:40:23 <elibrokeit> never mind complaints about "Once systemd gets a foot in a distribution, it doesn't stop." (I do not understand this complaint, it's not complicated to make an accompanying policy rule that "per policy, NO support other than the systemd package itself will EVER be provided")
2022-04-18 05:41:10 <elibrokeit> it's very understandable to object just based on "thousands of lines worth of patching to make it work is unpalatable, this package is not needed"
2022-04-18 05:41:44 <elibrokeit> 
ACTION actually is quite happy using a non-alpine distro that actually uses systemd, still doesn't think systemd is a good fit for alpine

2022-04-18 05:51:16 <panekj> I'm actually happy using Windows, other Linux distros and Alpine with openrc/bb init whether that's a rpi 3b+ or my powerful PC :)
2022-04-18 05:52:03 <panekj> I wouldn't put systemd on my NAS or rpi but I wouldn't mind it on my PC
2022-04-18 05:53:19 <panekj> as for 4k lines of patching and maintaining concern, it is a concern for me as a designated maintainer of that package so I don't see the issue
2022-04-18 07:31:06 <begs> s6-rc should eventually come in foreseeable future as a new init system for Alpine
2022-04-18 07:31:42 <begs> Are there any real practical reasons to use systemd?
2022-04-18 07:33:02 <panekj> yes, you don't wait for "foreseeable future"
2022-04-18 07:35:23 <orbea> panekj: the concern is that you are creating a bug farm
2022-04-18 07:36:09 <orbea> bluntly its a bad idea, but still should work with getting this upstreamed first in general. Its just going to become a giant maintainer burden
2022-04-18 07:42:49 <psykose> none of those patches are ever getting upstreamed
2022-04-18 07:43:02 <orbea> ouch
2022-04-18 07:45:32 <orbea> hacking up a large complicated moving target like systemd seems very painful...
2022-04-18 07:48:17 <panekj> patches that can be upstreamed are already upstreamed
2022-04-18 07:51:14 <elibrokeit> "it is a concern for me because I'm the package maintainer" doesn't really feel like a good defense tbh
2022-04-18 07:52:39 <elibrokeit> it's still thousands of lines of patches that reviewers need to look at, core needs to be okay clogging up the repos, and people working on toolchain rebuilds and release engineering need to be okay treating as potentially a painful blocker for getting work done
2022-04-18 07:53:17 <psykose> none of those really apply to testing/
2022-04-18 07:53:35 <psykose> goodness, i would never support this, but i find it funny how much i can play devils advocate with it
2022-04-18 07:53:47 <psykose> these arguments make less sense than actually packaging systemd
2022-04-18 07:55:01 <orbea> so if one of those patches introduces a subtle security issue that is totally acceptable in testing?
2022-04-18 07:55:45 <psykose> i hope none of our 51 gcc patches introduce a security issue then
2022-04-18 07:55:55 <psykose> :p
2022-04-18 07:56:24 <orbea> the scope of gcc and systemd is not even comparable, but yea...
2022-04-18 07:56:35 <psykose> yes, the scope for gcc is significantly bigger
2022-04-18 07:56:38 <panekj> yeah, I'm surprised how much people are against the idea even if it's just in testing
2022-04-18 07:56:40 <elibrokeit> do any of them include actual thousands of lines of changes which upstream is actively antagonistic toward, on an ongoing basis?
2022-04-18 07:57:39 <psykose> gcc has far more changes than these systemd patches do
2022-04-18 07:58:04 <psykose> have you seen these systemd patches? i know you haven't, so i will give you a small synopsis: 98% of it is renaming things and moving headers around
2022-04-18 07:58:05 <psykose> profound
2022-04-18 07:58:13 <elibrokeit> ah, okay. So what about that active antagonism?
2022-04-18 07:58:41 <psykose> as compared to the openrc active antagonism.. a little worse
2022-04-18 07:59:16 <elibrokeit> gcc is more antagonistic to alpine patches than systemd is???
2022-04-18 07:59:39 <psykose> why would we have 52 of them otherwise?
2022-04-18 08:00:41 <psykose> granted, for most of them, i think nobody has bothered trying to upstream them yet
2022-04-18 08:00:44 <psykose> as long as it has been
2022-04-18 08:01:08 <orbea> might be worth trying, 52 patches seems problematic
2022-04-18 08:02:01 <psykose> funnily enough, not really
2022-04-18 08:03:40 <elibrokeit> I think you answered your own question -- an alternative reason for having 52 of them is "no one bothered to submit them", rather than "upstream said they like bugs and compile errors so go away"
2022-04-18 08:04:13 <psykose> i never had a question, actually
2022-04-18 08:04:25 <psykose> :p
2022-04-18 08:05:10 <elibrokeit> You used a question mark, it counts!
2022-04-18 08:08:07 <fcolista> is docker-abuild still used so far/
2022-04-18 08:08:09 <fcolista> ?
2022-04-18 08:08:19 <ikke> Some people use it
2022-04-18 08:08:40 <fcolista> ikke, what's the standard we use in alpine infra for building package?
2022-04-18 08:08:50 <panekj> abuild
2022-04-18 08:09:14 <fcolista> that's not what I meant. How is abuild invoked?
2022-04-18 08:09:36 <psykose> buildrepo
2022-04-18 08:09:50 <fcolista> psykose, thanks. That was what I was looking for
2022-04-18 08:10:19 <psykose> from lua-aports
2022-04-18 08:10:24 <psykose> invoked by mqtt-exec or something
2022-04-18 08:10:25 <ikke> which just directly invokes abuild
2022-04-18 08:10:28 <ikke> yes
2022-04-18 08:11:22 <fcolista> good. So what happens is git commit triggers mqtt-exec
2022-04-18 08:11:26 <fcolista> with buildrepo
2022-04-18 08:11:38 <fcolista> which invokes abuild
2022-04-18 08:15:32 <ikke> mqtt-exec -> aports-build -> buildrepo -> abuild
2022-04-18 08:15:48 <fcolista> what is aports-build ?
2022-04-18 08:16:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build
2022-04-18 08:17:57 <ikke> That's what responds to mqtt messages and decides what needs to be done
2022-04-18 08:18:11 <fcolista> thx ikke
2022-04-18 08:18:12 <fcolista> ok
2022-04-18 08:18:32 <fcolista> For what I need, i can skip that part then
2022-04-18 08:19:00 <fcolista> I can have a trigger that runs buildrepo for the different arches
2022-04-18 08:19:12 <fcolista> with a shared nfs aport dir
2022-04-18 08:19:50 <fcolista> now I need to look on how to use buildrepo :D
2022-04-18 09:48:39 <fcolista> ikke, can you help me with buildrepo? It seems that buildrepo looks for aports.db file
2022-04-18 09:48:54 <ikke> fcolista: You need to run it in the correct directory
2022-04-18 09:49:23 <fcolista> correct directory is where the APKBUILD is located?
2022-04-18 09:49:27 <ikke> no
2022-04-18 09:49:37 <fcolista> buildrepo -p -R -n --apor
2022-04-18 09:49:37 <fcolista> ts=/dati/aports/fcolista/aports community/dnsrecon
2022-04-18 09:49:47 <fcolista> that's how I'm running it as a test
2022-04-18 09:49:58 <ikke> what is ts?
2022-04-18 09:50:07 <ikke> You don't specify individual packages
2022-04-18 09:50:08 <fcolista> it's a stupid \n
2022-04-18 09:50:24 <fcolista> buildrepo -p -R -n --aports=/dati/aports/fcolista/aports community/dnsrecon
2022-04-18 09:50:35 <ikke> it builds an entire repo, like community
2022-04-18 09:50:44 <fcolista> ah
2022-04-18 09:51:23 <fcolista> wow. I missed that part. So buildrepo is not what i need to build an actual package
2022-04-18 09:51:26 <ikke> cd dati/aports/fcolista/aports; buildrepo -n community
2022-04-18 09:51:39 <ikke> fcolista: if you just need to build a single package, you just use abuild -r
2022-04-18 09:51:59 <ikke> or abuild rootbld, if you want to use rootbld (and have it installed)
2022-04-18 09:52:00 <fcolista> yes, but I want to do it in a clean env, like a container
2022-04-18 09:52:11 <ikke> then abuild rootbld is likely what you want
2022-04-18 09:52:23 <ikke> it creates a chroot
2022-04-18 09:53:27 <fcolista> ikke, thx
2022-04-18 09:53:42 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/abuild-rootbld
2022-04-18 09:53:44 <panekj> notice: rootbld doesn't clear env
2022-04-18 09:54:07 <panekj> so it's not exactly *clear environment*
2022-04-18 09:54:46 <fcolista> panekj, yeah. Even if abuild can do it by himself
2022-04-18 09:55:13 <psykose> su - builduser -c abuild rootbld :p
2022-04-18 09:55:29 <panekj> https://tpaste.us/k6X7
2022-04-18 09:56:13 <ikke> panekj: that would break some things, though
2022-04-18 09:56:17 <fcolista> umh...
2022-04-18 09:56:24 <ikke> BOOTSTRAP=1 abuild rootbld
2022-04-18 09:56:57 <panekj> ikke: I'm not aware of all abuild specific envvars so it's not complete patch
2022-04-18 09:57:16 <panekj> but thanks for tip, will include that
2022-04-18 10:00:26 <ikke> there are more
2022-04-18 10:00:37 <psykose> having a whitelist of vars is still a better idea though
2022-04-18 10:00:49 <psykose> and considering rootbld is not actually deployed yet, this is actually fine to change to
2022-04-18 10:08:09 <donoban> I'm not sure if 'abuild rootbld' should just have the same env than plain abuild
2022-04-18 10:10:37 <donoban> s/than/that/
2022-04-18 10:10:37 <alpine-meetbot> donoban meant to say: I'm not sure if 'abuild rootbld' should just have the same env that plain abuild
2022-04-18 10:11:20 <panekj> I'd say it shouldn't
2022-04-18 10:11:53 <psykose> no, it makes perfect sense for rootbld to control as much as possible itself and drop env
2022-04-18 10:12:24 <panekj> plain abuild can be affected in multiple ways by current environment, such as custom packages installed by user
2022-04-18 10:12:50 <panekj> it only makes sense for rootbld to be isolated environment where it isn't affected by host modifications
2022-04-18 10:13:07 <donoban> so it needs a special way for passing env vars or just whiltelist some?
2022-04-18 10:13:15 <psykose> and besides, one can add --extra-env=ENV=xyz flags
2022-04-18 10:13:41 <panekj> psykose: well that would require a flag or option to add custom flags
2022-04-18 10:14:00 <psykose> my point is since rootbld is clearly not complete you can add whatever design you want :p
2022-04-18 10:15:14 <donoban> I'm trying to cleanup and flexiblity it a little
2022-04-18 10:15:54 <donoban> I see many bind options that are pointless
2022-04-18 10:16:10 <psykose> like what
2022-04-18 10:16:10 <donoban> like $build_root/home /home
2022-04-18 10:16:43 <donoban>         --bind "$BUILD_ROOT/$HOME" "$HOME" \
2022-04-18 10:16:52 <ikke> It needs at least REPODEST
2022-04-18 10:17:16 <donoban> do you mean --bind or env?
2022-04-18 10:17:20 <ikke> bind
2022-04-18 10:17:23 <donoban> ah yes
2022-04-18 10:17:33 <donoban> the pointless binds are just referring to the build_root itself
2022-04-18 10:17:39 <donoban> like
2022-04-18 10:17:42 <donoban>         --bind "$BUILD_ROOT/tmp" /tmp \
2022-04-18 10:17:52 <donoban> $BUID_ROOT/tmp is already on /tmp inside the chroot
2022-04-18 10:17:54 <psykose> what makes them pointless
2022-04-18 10:18:22 <donoban> they are binding some dir to the same place where it is without binding it
2022-04-18 10:19:05 <donoban> when you start the bwrap process, $BUILD_ROOT/tmp is already /tmp
2022-04-18 10:19:09 <psykose> ah right
2022-04-18 10:19:17 <donoban> I deleted all of them and works fine
2022-04-18 10:19:38 <panekj> BUILD_ROOT is mktemp
2022-04-18 10:19:56 <donoban> and I also moved $srcdir and $pkgbasedir so it's replicates the a std abuild or dabuild
2022-04-18 10:20:05 <donoban> it uses the src/pkg on your aports dir
2022-04-18 10:20:25 <donoban> so when I pass the whole args to it, and use -K
2022-04-18 10:20:26 <panekj> BUILD_ROOT=$(mktemp -d /var/tmp/abuild.XXXXXXXXXX)
2022-04-18 10:20:48 <donoban> it doesn't delete it
2022-04-18 10:20:50 <Newbyte> psykose: how would I ARCH the dependency? 
2022-04-18 10:21:08 <panekj> then it fails with abuild-rmtemp
2022-04-18 10:21:43 <psykose> Newbyte: in _apps_extra in community/gnome, you can do if/case shell stuff
2022-04-18 10:21:51 <panekj> also, just because it's not used currently, doesn't mean we should break current assumptions
2022-04-18 10:22:05 <donoban> panekj: what you mean?
2022-04-18 10:22:15 <panekj> there might be a case where that's actually useful
2022-04-18 10:25:52 <panekj> donoban: as in, "I tested, it works" is not enough because there are various different scenarios where abuild can behave differently
2022-04-18 10:27:43 <psykose> --bind binds a path from the host to the root
2022-04-18 10:28:16 <psykose> buildroot/tmp is /tmp in the root so that doesn't seem like it does anything
2022-04-18 10:28:17 <donoban> well, it will very reviewed, if there is some reason for doing that someone will explain it
2022-04-18 10:28:36 <donoban> thats what I felt when I saw it
2022-04-18 10:28:45 <psykose> unless there are some semantics i am not aware of
2022-04-18 10:28:54 <psykose> bwrap is magic, after all :p
2022-04-18 10:29:35 <psykose> if it was backwards, like /tmp buildroot/tmp then it would bind the host mnt into the root (obviously not wanted for rootbld), so then it would be doing something
2022-04-18 10:29:42 <psykose> but no idea
2022-04-18 10:30:48 <donoban> I also noticed that whole /proc is shared, adding --unshare-pid hides host process, probably is not something important but looks better
2022-04-18 10:32:29 <panekj> yeah, it binds new tmpdir on host to /tmp in chroot
2022-04-18 10:32:34 <panekj> don't see any issue with that
2022-04-18 10:32:55 <panekj> can be made an option if you absolutely need to
2022-04-18 10:33:02 <donoban> the issue is that the dir is already inside teh chroot
2022-04-18 10:33:07 <donoban> and in the same path
2022-04-18 10:33:24 <donoban> hM
2022-04-18 10:33:40 <donoban> maybe it's binding it for change writablity
2022-04-18 10:33:57 <panekj> where is it in chroot
2022-04-18 10:35:18 <donoban> touch jojo
2022-04-18 10:35:20 <donoban> touch: jojo: Read-only file system
2022-04-18 10:35:25 <donoban> that was the reason
2022-04-18 10:43:08 <panekj> :) told you it's for some arcane magic
2022-04-18 10:43:56 <donoban> I will add some comment
2022-04-18 10:45:23 <panekj> preferably we should have comment everywhere where usage of something is unclear
2022-04-18 10:47:46 <panekj> but I also wouldn't mind if abuild was written in something that is more sane
2022-04-18 10:53:44 <ikke> I'm on two legs about that
2022-04-18 10:54:28 <psykose> is that a dutch saying
2022-04-18 10:54:52 <ikke> yes
2022-04-18 10:56:56 <psykose> is it more like 'on the fence' or 'i am using both my legs to get to it'
2022-04-18 10:56:57 <psykose> :p
2022-04-18 10:57:04 <ikke> on the fence
2022-04-18 10:57:06 <psykose> ah
2022-04-18 10:57:47 <ikke> Better translation is hopping on two legs
2022-04-18 10:57:55 <psykose> frog ikke
2022-04-18 10:58:02 <psykose> 🐸
2022-04-18 11:02:38 <panekj> jumping from happiness 
2022-04-18 11:50:21 <Misthios> Oh no not the sayings :)
2022-04-18 11:51:15 <ikke> Yes, the infamous dutch speakwords
2022-04-18 11:54:07 <Misthios> At least i dont need to learn them for school anymore
2022-04-18 11:56:36 <psykose> did you hear there is a new icu Misthios ?
2022-04-18 11:56:37 <psykose> :p
2022-04-18 11:57:01 <Misthios> *hides*
2022-04-18 11:57:03 <psykose> ehehe
2022-04-18 11:57:07 <Misthios> Does ff need it yet ;)
2022-04-18 11:57:18 <psykose> no, but who knows what 100 will need in 2 weeks
2022-04-18 11:57:32 <psykose> i could check the dev branch but i'm lazy
2022-04-18 11:57:36 <psykose> i would bet probably it might
2022-04-18 11:57:39 <Misthios> I hope no surprise
2022-04-18 11:57:40 <psykose> given how it always goes..
2022-04-18 11:58:11 <panekj> I heard it broke ABI again
2022-04-18 11:58:18 <psykose> every version is a new abi
2022-04-18 11:58:24 <panekj> :)
2022-04-18 11:58:27 <psykose> rebuilds on every 70->71 etc
2022-04-18 11:58:28 <psykose> same as boost
2022-04-18 11:58:37 <ikke> Who needs backwards compatibility anyway
2022-04-18 11:58:38 <psykose> speaking of there is new boost
2022-04-18 11:58:43 <Misthios> Ikr
2022-04-18 11:58:46 <Misthios> Oh no
2022-04-18 11:58:57 <psykose> arch has 71.1 icu and boost 1.78 so there are patches for everything anyway i would bet
2022-04-18 11:59:01 <psykose> but it's still a lot of work
2022-04-18 12:00:09 <Misthios> I might check ff dev branch later today
2022-04-18 12:16:52 <elibrokeit> why should boost bother with backwards compatibility at all, simply ship nothing but headers and all ABI concerns disappear
2022-04-18 12:16:58 <elibrokeit> -- boost developers, probably
2022-04-18 14:05:11 <panekj> psykose: https://github.com/golang/go/issues/9887
2022-04-18 14:06:27 <psykose> the chance of that getting fixed is lower than me actually living a fulfilling and happy life
2022-04-18 14:06:42 <panekj> :)
2022-04-18 14:06:45 <psykose> :)
2022-04-18 14:06:56 <panekj> but funny animal language
2022-04-18 14:08:04 <panekj> if someone wishes to not stare at empty screen for 20 minutes, they can add `-x` to `go build`
2022-04-18 14:08:42 <panekj> it will give a nice spam of (c)go compiler
2022-04-18 14:34:39 <donoban> anyone knows better ash alternative for if  [[ "$@" == *"rootbld"* ]]; then
2022-04-18 14:35:23 <panekj> this looks bad
2022-04-18 14:35:54 <donoban> it's bashism
2022-04-18 14:36:15 <ikke> case "$@"
2022-04-18 14:36:29 <ikke> case "$@";; in *rootbld*) ..;; esac
2022-04-18 14:36:41 <ikke> one ; too many in the beginning
2022-04-18 14:36:43 <panekj> I mean *rootbld*
2022-04-18 14:36:57 <ikke> yes, it's better to check every argument
2022-04-18 14:37:06 <donoban> uhM..
2022-04-18 14:37:25 <ikke> for arg; do; if [ "$arg" = rootbld ]; then ..; fi
2022-04-18 14:37:34 <donoban> for adding a little context, currently rootbld is hadled inside a while loop
2022-04-18 14:37:44 <donoban> where it calls runpart $1 and shifts
2022-04-18 14:38:04 <panekj> ugh, i really wish it was just a flag to abuild
2022-04-18 14:38:11 <panekj> so much simpler
2022-04-18 14:38:43 <donoban> but I want to don't run rootbld part there, if there is rootbld the loop is not executed and the whole args (without the 'rootbld') are passed to the new abuild process
2022-04-18 14:40:23 <donoban> I don't sure it's too much different with a flag (read from conf file? passed as optional argument?)
2022-04-18 14:40:56 <donoban> ikke: I'm not sure if case "$@" is very good here
2022-04-18 14:41:10 <panekj> when it's a flag, it's part of getopts
2022-04-18 14:41:36 <panekj> and from there, it's just pure joy
2022-04-18 14:43:16 <donoban> probably but it will need more discussion
2022-04-18 14:43:37 <panekj> plenty of time for that in abuild repo :)
2022-04-18 14:47:00 <psykose> oh yes
2022-04-18 14:47:02 <psykose> plenty of time indeed
2022-04-18 14:47:04 <psykose> :p
2022-04-18 14:47:28 <panekj> mhm, is abuild frozen at some point before next alpine release?
2022-04-18 14:47:35 <psykose> permafrozen
2022-04-18 14:47:41 <panekj> yes lol
2022-04-18 14:48:19 <panekj> we really should merge cargo / go stuff before 3.16
2022-04-18 14:48:55 <psykose> me and you both know how that one is going
2022-04-18 14:49:15 <ikke> panekj: abuild gets most attention just before a release :)
2022-04-18 14:49:53 <Misthios> out of sight out of mind right?
2022-04-18 14:50:17 <panekj> that's great, I was just a bit worried that it's already in frozen state for next release
2022-04-18 14:50:36 <psykose> and that is by far the worst time to look at it :p
2022-04-18 14:51:11 <panekj> it's like with school work, ignore it until last minute
2022-04-18 14:52:12 <psykose> the global cargo flags would've been useful for a world rebuild
2022-04-18 14:52:15 <psykose> but that is mostly done already
2022-04-18 14:52:16 <psykose> sad
2022-04-18 14:55:35 <donoban> great, now I can modify sources and rebuild with: abuild -K rootbld build 
2022-04-18 14:56:40 <donoban> I will do some cleanup and send a MR
2022-04-18 14:58:09 <psykose> PureTryOut: were you planning on merging qt 6.3.0 or do you want me to fix the remaining shiboken/pyside issue
2022-04-18 16:07:36 <Misthios> psykose ff 100 seems to be able to use icu 70. firefox101 will most likely need the newer icu as this got merged few days ago https://bugzilla.mozilla.org/show_bug.cgi?id=1763783
2022-04-18 16:09:07 <psykose> well that's in like 6 weeks then
2022-04-18 16:09:10 <psykose> or something
2022-04-18 16:10:06 <Misthios> yeah
2022-04-18 16:10:21 <Misthios> gonna try to look at icu later this week
2022-04-18 16:10:36 <psykose> sure :3
2022-04-18 16:10:36 <psykose> thanks
2022-04-18 16:10:56 <Misthios> np
2022-04-18 16:11:22 <psykose> it helps a lot to have people focus on these singular large changes
2022-04-18 16:11:26 <psykose> it's nice you always do this one :p
2022-04-18 16:11:40 <Misthios> i only did iit once before toh
2022-04-18 16:12:01 <Misthios> but yeah more people always helps (for larger things)
2022-04-18 16:12:08 <ikke> does mean we need to rebuild quite some things for 3.16 again
2022-04-18 16:12:33 <psykose> it's actually not that many in comparison to the whole tree that we built
2022-04-18 16:13:07 <Misthios> its only around 96 or so packages if i remember correctly from last time
2022-04-18 16:13:10 <Misthios> oh and dotnet now
2022-04-18 16:14:15 <psykose> dotnet already supports it :)
2022-04-18 16:14:43 <Misthios> so n orebuilds for that?
2022-04-18 16:16:46 <psykose> no, as in you don't have to worry about it
2022-04-18 16:16:53 <Misthios> ah
2022-04-18 17:37:48 <panekj> thread 'main' panicked at 'don't know how to configure OpenSSL for x86_64-alpine-linux-musl', /home/pj/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-src-111.16.0+1.1.1l/src/lib.rs:283:18
2022-04-18 17:37:55 <panekj> any idea what might be the cause of that?
2022-04-18 17:40:20 <Cogitri> Try to build with system OpenSSL, that should work
2022-04-18 17:41:47 <psykose> export OPENSSL_NO_VENDOR=1
2022-04-18 17:42:34 <psykose> (all those configure scripts always fail, and there are a few that don't even have non-vendor options..)
2022-04-18 17:42:36 <psykose> because we have our own triple
2022-04-18 17:42:49 <psykose> but openssl-src has it
2022-04-18 17:42:55 <panekj> ok, just found pesky feature in one of Cargo.toml that does that
2022-04-18 17:43:16 <panekj> I forgot people are [REDACTED] and force vendored deps
2022-04-18 17:43:33 <psykose> i have no idea why we have our own triple for rust in the first place :p
2022-04-18 17:43:36 <psykose> not sure what it's fixing
2022-04-18 17:43:56 <psykose> back in the day unknown-linux-musl was assumed to be statically linked, but that is not the case anymore
2022-04-18 17:44:01 <panekj> it's supposed to be more vendor specific
2022-04-18 17:44:14 <panekj> like dotnet RIDs
2022-04-18 17:45:08 <psykose> yes, but what actual build issue is this solving
2022-04-18 17:45:41 <panekj> there could be people who target their software for alpine specifically
2022-04-18 17:45:46 <psykose> lol
2022-04-18 17:45:52 <panekj> with accent on *could*
2022-04-18 17:46:13 <psykose> in some cases i see things do completely wrong things that this just errors on instead, i guess, but that's not much of a statement
2022-04-18 17:46:34 <psykose> like, if triple = unknown-linux-musl; statically-link-our-entire-program
2022-04-18 17:46:39 <psykose> and instead it just crashes with unknown triple
2022-04-18 17:46:59 <psykose> but in both cases you have to patch it, so you didn't win anything
2022-04-18 17:47:04 <psykose> it would error either way for different reasons
2022-04-18 17:47:45 <panekj> well, I could have been less dumb and actually set OPENSSL_NO_VENDOR like it was telling me when it was failing but I was a bit confused by why it couldn't configure
2022-04-18 17:48:33 <panekj> psykose: i think it's better to error if it were to silently build with some vendored openssl
2022-04-18 17:48:57 <psykose> slightly, but sometimes it's implicit anyway
2022-04-18 17:49:35 <psykose> many cases of actual auto-unvendoring (usually zlib or bzip2 etc) that use system libs themselves but everyone forgets to check :p
2022-04-19 00:02:07 <Ariadne> 12:43 PM <psykose> back in the day unknown-linux-musl was assumed to be statically linked, but that is not the case anymore
2022-04-19 00:02:09 <Ariadne> err, what?
2022-04-19 00:02:17 <Ariadne> https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/linux_musl_base.rs#L12-L13
2022-04-19 00:02:21 <Ariadne> it is definitely the case
2022-04-19 00:04:05 <psykose> did they revert this https://github.com/rust-lang/compiler-team/issues/422
2022-04-19 00:04:06 <psykose> hm
2022-04-19 00:04:36 <psykose> ah
2022-04-19 00:04:39 <psykose> https://github.com/rust-lang/rust/issues/93084#issuecomment-1019328378
2022-04-19 00:04:51 <psykose> ok, so they are still just working on it
2022-04-19 00:04:53 <Ariadne> the MCP was accepted but nobody has done it yet
2022-04-19 00:04:55 <psykose> alright, in 5 years i will be correct
2022-04-19 00:05:02 <psykose> but today i am wrong
2022-04-19 00:05:07 <psykose> and so today is a fucked up day indeed!
2022-04-19 00:05:16 <psykose> :p
2022-04-19 00:05:17 <psykose> thanks
2022-04-19 04:37:44 <panekj> Good morning
2022-04-19 04:38:21 <ikke> o/
2022-04-19 05:00:17 <Misthios> Gm
2022-04-19 05:05:27 <Daanct12> good morning panekj 
2022-04-19 05:05:48 <Daanct12> how's cursedD?
2022-04-19 05:05:52 <Daanct12> :)
2022-04-19 05:06:16 <Daanct12> have you noticed any weird issue with it yet?
2022-04-19 05:06:29 <panekj> good, working on splitting it into subpackages so I can try and install gnome
2022-04-19 05:06:42 <Daanct12> :D
2022-04-19 05:06:47 <panekj> something something conflict with elogind ...
2022-04-19 05:07:04 <Daanct12> would it possible to make it conflict with elogind as well so you can use systemd-logind?
2022-04-19 05:07:21 <panekj> well, it conflicts already
2022-04-19 05:08:30 <Daanct12> anyway, let me know if everything is ready :)
2022-04-19 05:08:38 <Daanct12> i'd like to play around with it
2022-04-19 05:11:49 <panekj> had to setup local package index so it's easier with rebuilding the machine (and additionally hit a bug in caddy webserver)
2022-04-19 06:14:28 <PureTryOut> psykose: when I have the time for it yes I am
2022-04-19 10:55:17 <ncopa> this java-jdk provides. I dont think it makes sense really
2022-04-19 10:59:02 <ikke> ncopa: that something depends on a non-specifc jdk version?
2022-04-19 11:01:32 <ncopa> jdk is needed to build it right?
2022-04-19 11:02:09 <ncopa> will somethign that is built with openjdk17 run on openjdk8 runtime?
2022-04-19 11:02:50 <ncopa> or is it like llvm, where package might not depend on any specific version of llvm but we need one at build time?
2022-04-19 11:04:13 <ncopa> problem is the way java-jdk is implemented. its a provides in a subpackage, which means that it is impossible to know what package provides java-jdk until after the build is done
2022-04-19 11:04:44 <ncopa> meaning it is impossible to know that it needs to be built before whatever needs java-jdk
2022-04-19 11:05:11 <ncopa> that is normally solved by adding openjdk17-dev to makedepends
2022-04-19 11:06:01 <ncopa> but at that point you have already specified what openjdk version you build it against, and could maybe just use openjdk17-jdk instead of java-jdk?
2022-04-19 11:07:16 <Asmadeus> ncopa: hello, would you have a few minutes to look at !32825 ?
2022-04-19 11:07:24 <ikke> Is there something preventing us to know in advance what would provide something?
2022-04-19 11:09:31 <ikke> ncopa: if the resolver would have information about the provides + priority, it could take that into account?
2022-04-19 11:11:05 <ikke> The only 'challenge' is making sure it depends on the same jdk that was used to build it, I suppose
2022-04-19 11:11:14 <ikke> it depends on the same jdk*
2022-04-19 11:11:47 <ncopa> that is my question. will it depend on the same jdk version used when building it?
2022-04-19 11:12:26 <ncopa> in the hdf5 case, if it is built with openjdk8, will it run with openjdk17?
2022-04-19 11:13:02 <ikke> I'm not sure how backwards compattible these jdks are
2022-04-19 11:13:26 <ncopa> build time order resolver would need the info about provides yes
2022-04-19 11:13:37 <ikke> https://stackoverflow.com/questions/4692626/is-jdk-upward-or-backward-compatible
2022-04-19 11:13:57 <ikke> I'm working atm on a APKBUILD parser in go
2022-04-19 11:14:11 <ikke> with the goal of even being able to peek into package split functions
2022-04-19 11:14:54 <ncopa> ugh... 
2022-04-19 11:15:00 <ncopa> i dont thikn that is a good idea
2022-04-19 11:15:08 <ncopa> you'd need to parse shell
2022-04-19 11:15:17 <ncopa> and the only way to do that is to execute it
2022-04-19 11:15:21 <ikke> I use an existing shell parser
2022-04-19 11:15:28 <ikke> which is custommizable
2022-04-19 11:15:37 <ikke> and gives you the AST
2022-04-19 11:15:55 <ptrc> ikke: did you find one that would correctly handle things like ${pkgver/-/.} ? i've been looking for something similar for a while
2022-04-19 11:16:06 <ikke> mvdan.cc/sh
2022-04-19 11:16:34 <ncopa> if you make it work, users/devs will expect all kinds of magic in the future
2022-04-19 11:16:45 <ncopa> better to specify it in the golbal scope somehow
2022-04-19 11:16:49 <ikke> ncopa: we already execute APKBUILDs with buildrepo
2022-04-19 11:17:00 <ncopa> the global scope yes
2022-04-19 11:17:07 <ncopa> we dont run the split funtions
2022-04-19 11:17:20 <ikke> No, my goal is to not execute the split functions
2022-04-19 11:17:44 <ncopa> but analyze and understand what is going on in the split functions?
2022-04-19 11:17:52 <ncopa> or does it depend on specifying it in global scope?
2022-04-19 11:19:17 <ncopa> re java-jdk, if i understand this correctly
2022-04-19 11:19:19 <ikke> my goal would be to manually evaluate simple variable assignments in the split functions
2022-04-19 11:19:36 <ikke> So it would not support complex things
2022-04-19 11:19:53 <ncopa> right so you need to understand what happens in the split function with out executing it
2022-04-19 11:20:03 <ikke> ncopa: By looking at the AST
2022-04-19 11:20:19 <ncopa> once you implement that and get it working, users will file bug reports and expect advanced stuff work as well. its just a questino of time
2022-04-19 11:20:54 <ikke> We can always say no
2022-04-19 11:21:19 <ncopa> it also means we would depend on highly advanced parser to solve a problem that could easily be solved or worked around by telling what it needs to know in global scope
2022-04-19 11:22:17 <ncopa> re java-jdk, if i understand it correctly. if we build hdf5 with openjdk17 it will not run on openjdk8 runtime
2022-04-19 11:22:35 <ncopa> but if we build it with openjdk8, it will run on openjdk17?
2022-04-19 11:22:55 <ncopa> if that is true, it would be best to build hfd5 with openjdk8?
2022-04-19 11:23:56 <ikke> newer JREs run code built with older SDKs, that's what I understand as well
2022-04-19 11:24:32 <ncopa> what i mean is that it woudl be significantly simpler to just add openjdk8-jdk as makedepends instead of depending of something highy sofisticated resolver
2022-04-19 11:25:21 <ncopa> and in the end, you would end up building it with openjdk17 which has the highest prio
2022-04-19 11:25:28 <ncopa> highes provider_priority
2022-04-19 11:25:40 <ncopa> which would mean that it would only work with the latest openjdk
2022-04-19 11:26:29 <ncopa> i think right now you will end up with a random jdk
2022-04-19 11:26:38 <ncopa> depending on what happens to be there
2022-04-19 11:27:23 <ncopa> if something else has a direct dependency of openjdk14 for example, and openjdk14 is there, then the dependency woudl be satisfied and it would use it
2022-04-19 11:27:37 <ncopa> you basically end up with a random openjdk version
2022-04-19 11:29:26 <ncopa> then we will get a request to "fix" that by adding some sofisticated resolver solution that makes the jdk version you end up with predictable instead of random
2022-04-19 11:30:06 <ncopa> so my question is: why dont we just set an explicit openjdk8-jdk makedepends in the first place?
2022-04-19 11:31:32 <ncopa> i prefer simple/stupid solutions so we dont end up with complicated smart/clever solutions for problems that shouldn't be there in the first place
2022-04-19 11:32:28 <ikke> Interestingly, hdf5 does not even have a runtime dependency on java
2022-04-19 11:32:40 <ikke> Not sure if that's a mistaken ommision or not
2022-04-19 11:33:27 <ncopa> probably intentional
2022-04-19 11:33:48 <ncopa> looks like it contains java bytecode
2022-04-19 11:33:55 <ncopa> to its probably suppsed to be portable
2022-04-19 11:34:17 <ncopa> build once, run everywhere
2022-04-19 11:36:38 <ikke> I think something similar is done for boost
2022-04-19 11:36:44 <ikke> at least some packages just depend on boost-dev
2022-04-19 11:37:41 <ikke> Sometimes we have multiple boost versions in the repositories
2022-04-19 11:38:11 <ncopa> i thin boost is somewhat differently
2022-04-19 11:38:16 <ncopa> but yeah
2022-04-19 11:38:21 <ncopa> and same with llvm
2022-04-19 11:38:32 <ncopa> can can depend on llvm-dev or boost-dev
2022-04-19 11:38:43 <ncopa> and you get latest version of it at build time
2022-04-19 11:38:48 <skarnet> ncopa: sorry for the nonsequitur but *please* bump the alpine-conf version number so I can submit my MR
2022-04-19 11:39:23 <ncopa> and the exact version will be resolved at runtime by so depends
2022-04-19 11:39:30 <ncopa> automatically
2022-04-19 11:40:49 <ncopa> skarnet: you cant submit your MR without me bumping the version?
2022-04-19 11:40:59 <skarnet> no
2022-04-19 11:41:10 <skarnet> the MR depends on the additions to alpine-conf
2022-04-19 11:41:26 <skarnet> merging it without bumping alpine-conf would break things
2022-04-19 11:42:17 <skarnet> (this is why I had bumped the version in the first place, but you said it wasn't how you usually operated)
2022-04-19 11:43:33 <ncopa> so the MR depends on stuff in git master already
2022-04-19 11:43:48 <ncopa> but will break if I don't bump the version?
2022-04-19 11:44:35 <ncopa> ok.. i'll try get it done
2022-04-19 11:44:45 <ncopa> will also need to have a look at the older MRs first
2022-04-19 11:44:53 <skarnet> the way alpine-conf works, you have a separate tarball
2022-04-19 11:45:18 <skarnet> my aports MR relies on things that are not in the current tarball
2022-04-19 11:45:39 <skarnet> I need alpine-conf bumped in order for a new alpine-conf tarball to be published and imported by abuild
2022-04-19 11:45:48 <skarnet> and then my MR can work
2022-04-19 11:46:22 <skarnet> no, I'm not sure why you did it this way either :P but it's how it works
2022-04-19 11:48:17 <ncopa> ah.. MR to aports, not MR to alpine-conf. I misunderstood. sorry
2022-04-19 11:48:27 <ncopa> you need those changes in aports
2022-04-19 11:48:39 <ncopa> ok i'll do my best
2022-04-19 11:49:22 <ncopa> but many of the current MRs in alpine-conf are not top quality. i shoudl give some useful feedback
2022-04-19 11:50:00 <ncopa> and in many cases I don't trust that the change has been tested, so I may need test it as well
2022-04-19 11:57:59 <skarnet> it's all right but that is why my policy is to always bump the version right after a release
2022-04-19 11:58:14 <skarnet> so the new version number can be used to test various features
2022-04-19 11:58:47 <skarnet> and software that depends on the stable set of features (e.g. the alpine-conf APKBUILD in aports) uses the currently released version
2022-04-19 11:59:17 <skarnet> it is difficult to test when the version number still refers to the stable release
2022-04-19 12:01:17 <ncopa> yeah, i understand the value of doing so, and I think thats what I should do too
2022-04-19 12:01:30 <skarnet> :)
2022-04-19 12:01:34 <ncopa> i was just stupid in my younger days
2022-04-19 12:01:41 <ncopa> i mean, even more stupid than I am now
2022-04-19 12:02:17 <skarnet> when I was young, I was an idiot. I'm still very young!
2022-04-19 12:03:26 <ncopa> somehow I feel more and more stupid the older I get.
2022-04-19 12:04:39 <ncopa> But I guess that the smarter I get, the better I understand how stupid I actually am :)
2022-04-19 12:11:06 <ncopa> re alpine-conf, I finally have a plan for making a testsuite in qemu to do automatted tests of the installer
2022-04-19 12:11:42 <skarnet> for now I'll settle for 3.14.0 ;)
2022-04-19 12:12:34 <skarnet> also yes, feeling more stupid is a good sign - it's generally self-awareness growing more than anything else :D
2022-04-19 12:13:45 <skarnet> (and an unethical, but very efficient, tip for feeling less ashamed of yourself: just watch others for a while.)
2022-04-19 12:15:43 <panekj> I find that it's not being less/more stupid but being stupid in different ways
2022-04-19 13:15:27 <minimal> Looking at gitlab at the index of issues it shows particular issue, #12857, as being updated 1 hour ago, however when I view the issue the most recent update I can see is 3 month ago. Any ideas how I work out what apparently changed 1 hour ago?
2022-04-19 13:16:55 <panekj> minimal: there was commit pushed by hello which referenced this issue
2022-04-19 13:16:56 <ikke> minimal:  Alex Xu (Hello71) @alxu mentioned in commit alxu/alpine-conf@928a3e06 1 hour ago
2022-04-19 13:17:19 <ikke> minimal: did you filter on showing comments only?
2022-04-19 13:17:38 <ncopa> i merged this https://gitlab.alpinelinux.org/alxu/alpine-conf/-/commit/928a3e06811655db710c78e519e5cc9fcb2dd21b
2022-04-19 13:18:12 <minimal> ikke: I didn't filter on anything, just viewed the issue from the index
2022-04-19 13:18:32 <ikke> if you click on it, you see the activity
2022-04-19 13:20:08 <minimal> ah, it seems to be because I wasn't logged into Gitlab - didn't realise it would "hide" things in that situation
2022-04-19 13:20:24 <ikke> It's because alxu/alpine-conf is internal
2022-04-19 13:22:20 <minimal> yeah, I'd have expected gitlab in that scenario to indicate this is an update that cannot be viewed, rather than say nothing about it. Ah well, it is what it is.
2022-04-19 19:39:58 <psykose> ncopa: the 'correct' solution here is for the build order generator to support the same level of features as apk does
2022-04-19 19:40:18 <psykose> if the build order cannot be resolved with depends= provides= in subpackages, then the correct decision is to never use them either
2022-04-19 19:40:33 <psykose> we cannot simultaneously use the apk feature of those while not being able to actually resolve building correctly
2022-04-19 19:40:36 <psykose> that doesn't make any sense
2022-04-19 19:40:57 <psykose> you either allow both or neither, and the latter isn't good because apk obviously support these, so we need to improve the way we generate the build order
2022-04-19 19:41:03 <psykose> there is no way around this
2022-04-19 19:41:41 <psykose> java-jdk specifically might be a 'bad' case, but this same issue is present in any other place where something depends= in a subpackage/package
2022-04-19 19:41:46 <ikke> psykose: the main argument I agree with is that the result should be predictable
2022-04-19 19:41:54 <psykose> i.e. anything using gpg failed 2512354 times
2022-04-19 19:42:02 <psykose> because one of the depends= in a subpackage was pinentry
2022-04-19 19:42:05 <psykose> was pinentry built first? no
2022-04-19 19:42:15 <psykose> and so i had to restart the builders 47 times
2022-04-19 19:42:26 <ikke> same with things depending on docker in the past
2022-04-19 19:42:27 <psykose> this doesn't make any sense, the parser *has* to support this,
2022-04-19 19:43:02 <ikke> psykose: So what ncopa says is that if we need this information for the solver, it should be part of the global scope
2022-04-19 19:43:10 <psykose> <ncopa> if you make it work, users/devs will expect all kinds of magic in the future
2022-04-19 19:43:13 <psykose> and this is not a magic feature
2022-04-19 19:43:16 <psykose> it's not even a feature at all
2022-04-19 19:43:25 <psykose> nobody thinks about the build order or relies on it
2022-04-19 19:43:32 <ikke> psykose: I think he referred to looking at these variables directly in the split functions
2022-04-19 19:43:44 <psykose> yes, but anything you implement, nobody will even know about
2022-04-19 19:43:48 <psykose> it's purely your own can of worms
2022-04-19 19:43:58 <psykose> nobody is going around looking how it's getting parsed and doing fun stuff
2022-04-19 19:44:03 <psykose> the only person i've met that has was ayakael
2022-04-19 19:44:09 <ikke> No, but they will use all shell features available
2022-04-19 19:44:12 <psykose> and he did it for a very good reason
2022-04-19 19:44:32 <psykose> maybe so, but they don't already
2022-04-19 19:44:59 <psykose> nobody will be changing their practise based on this invisible improvement
2022-04-19 19:45:03 <psykose> if they are, it will be for other reasons
2022-04-19 19:45:22 <psykose> if you want to set a policy to not allow certain things preemptively, you can do that, too
2022-04-19 19:45:24 <psykose> no issues there
2022-04-19 19:45:42 <psykose> but 'maybe this should not be implemented' is not the way to go, ever
2022-04-19 19:46:00 <psykose> maybe there's "other" ways than parsing an apkbuild into an ast, but there has to be at least one way
2022-04-19 19:46:29 <ikke> imho that is one of the cleaner ways to do it
2022-04-19 19:46:51 <psykose> it will probably have like 1 niche case where everything explodes, but so will any other solution, and then we can fix it
2022-04-19 19:46:54 <ikke> being able to inspect it without actually executing it
2022-04-19 19:46:57 <psykose> i am a fan of this one so far, but we will see how it goes
2022-04-19 19:47:15 <psykose> and we always have the ability to test it in gitlab only
2022-04-19 19:47:21 <ikke> So far, I'm only doing global scope stuff
2022-04-19 19:47:27 <psykose> mhm
2022-04-19 19:47:35 <ikke> just want to have that covered
2022-04-19 19:48:17 <psykose> to be clear, we can totally make this entirely global
2022-04-19 19:48:26 <psykose> it will require a massive amount of refactoring all of aports
2022-04-19 19:48:30 <ikke> Yes, just need to add support to abuild for extra datra
2022-04-19 19:48:35 <ikke> and that, yes
2022-04-19 19:48:49 <ikke> But that does not have to happen immediately
2022-04-19 19:48:51 <ikke> for all packages
2022-04-19 19:48:53 <psykose> mhm
2022-04-19 19:49:17 <ikke> my only concern is that it will become convoluted to do in the global scope
2022-04-19 19:49:59 <psykose> it needs some thinking for sure
2022-04-19 19:52:11 <ikke> But I think what ncopa also was talking about was using virtual packages for makedepends
2022-04-19 19:52:35 <psykose> do you have an example
2022-04-19 19:52:44 <ikke> java-jdk is one
2022-04-19 19:53:25 <ikke> it's circumstantial what actual package will be used during build
2022-04-19 19:53:31 <psykose> right
2022-04-19 19:54:09 <ikke> Unless the solver makes it into something deterministic
2022-04-19 19:55:56 <psykose> technically we specifically abuse that attribute with stage0 and provides=-bootstrap
2022-04-19 19:56:07 <psykose> but i think that is a good exception
2022-04-19 19:56:22 <psykose> then there is boost-dev/llvm-dev, but again, those are much more good than bad
2022-04-19 19:56:42 <psykose> i think this java case where the version really matters is more of the exception that it's bad the version is unknown
2022-04-19 19:57:29 <ikke> What makes it bad is that you have no fixed runtime binding like we have for solibs
2022-04-19 19:57:34 <psykose> yeah
2022-04-19 20:53:33 <clandmeter> Ariadne: what is the defacto "alpine" way to rename interfaces? 
2022-04-19 20:53:43 <clandmeter> i remember you wrote some helper before
2022-04-19 20:55:16 <ikke> macifrename
2022-04-19 20:56:03 <clandmeter> ah right
2022-04-19 20:56:09 <clandmeter> and how does that get executed?
2022-04-19 20:56:21 <ikke> https://git.sr.ht/~kaniini/macifrename
2022-04-19 20:56:55 <ikke> There is an openrc service
2022-04-19 20:58:19 <clandmeter> yup found it
2022-04-19 21:07:36 <clandmeter> still wonder how this is different than nameif
2022-04-19 21:09:30 <ikke> appears similar
2022-04-19 23:00:13 <Ariadne> there's nameif, ifrename, and macifrename
2022-04-19 23:00:22 <Ariadne> all of which have advantages and disadvantages
2022-04-19 23:00:49 <Ariadne> macifrename was primarily written to deal with octeon boards where the device tree had the ports wired up backwards
2022-04-19 23:01:03 <Ariadne> and can rename based on mac address
2022-04-19 23:01:06 <Ariadne> (lowest to highest)
2022-04-19 23:33:33 <eddsalkield> now the hdf4 package has been merged to master, could we take a look at merging !27963?
2022-04-19 23:34:08 <eddsalkield> i don't have any changes to make to the APKBUILD i don't think, so we just need to prompt the CI to check it's working on all platforms
2022-04-19 23:41:02 <psykose> i made them for you (mostly because i hate email patches and closing 79 mrs after it makes a new one each time)
2022-04-19 23:41:03 <psykose> thanks!
2022-04-19 23:56:16 <eddsalkield> thanks!
2022-04-19 23:57:08 <eddsalkield> maybe there's a way to get emailed patches to appear in the same thread in gitlab, if they're from the same person and about the same package
2022-04-19 23:57:21 <psykose> it would require someone to write that integration
2022-04-19 23:59:38 <psykose> and there is only one person that can/would work on it that is busy with other things
2022-04-19 23:59:50 <psykose> and the only people that would make use of it are the 5 people actually sending email patches
2022-04-20 00:00:12 <psykose> personally, i have no idea why the support was added in the first place
2022-04-20 00:01:59 <eddsalkield> if there's a way to submit patches with gitlab that's as convenient as `git send-email -1` then i'd look into using it
2022-04-20 00:02:20 <eddsalkield> but afaik you need to make a whole new branch, fork it, push it, make an mr...
2022-04-20 00:02:31 <eddsalkield> where is the code for the mailing list bot?
2022-04-20 00:02:39 <psykose> you fork aports once
2022-04-20 00:03:09 <psykose> locally i make a branch, do whatever, git push -u origin branchname, then the link the response outputs makes an mr
2022-04-20 00:03:16 <psykose> it takes me 12 seconds to open a merge request
2022-04-20 00:03:28 <psykose> and updating it is just editing the same branch
2022-04-20 00:03:49 <psykose> the initial setup of setting up the remotes and forking the repo on the gitlab account is effort, yes
2022-04-20 00:03:57 <psykose> but past that everything is instant
2022-04-20 00:04:22 <eddsalkield> i didn't know that git knew how to give you a link to open the mr
2022-04-20 00:04:30 <psykose> remotes can paste any content to you
2022-04-20 00:04:37 <eddsalkield> nice
2022-04-20 00:04:45 <eddsalkield> hopefully that's secure enough
2022-04-20 00:04:58 <psykose> https://img.ayaya.dev/TGF799LBaDOE.png
2022-04-20 00:05:35 <anjan> psykose: do you still have the restinio build recipe you linked here https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29093?diff_id=244166&start_sha=58d66e8923c7802d5cd3a6ce6944ee7dea75bfc6#note_203148
2022-04-20 00:05:46 <psykose> uhhh
2022-04-20 00:05:51 <anjan> Im trying to get jami to build psykose and Im having much better luck now
2022-04-20 00:05:53 <psykose> i remember literally nothing about any of that
2022-04-20 00:05:56 <psykose> apologies
2022-04-20 00:06:03 <anjan> no worries, Ill write it from scratch
2022-04-20 00:06:07 <psykose> and no, i don't have those archived anymore
2022-04-20 00:06:08 <anjan> jami is actually really good.
2022-04-20 00:06:10 <psykose> but it was not hard i don't think
2022-04-20 00:06:19 <psykose> my links are ephemeral for the most part
2022-04-20 00:06:29 <anjan> heh, I shouldve downloaded it
2022-04-20 00:06:30 <anjan> =(
2022-04-20 00:06:31 <psykose> aw
2022-04-20 00:06:39 <psykose> i can check if i have it on other storage
2022-04-20 00:06:46 <psykose> sec
2022-04-20 00:07:30 <psykose> nope
2022-04-20 00:08:18 <psykose> i think it itself needed like 4-5 things though, but it's been a while
2022-04-20 00:17:22 <anjan> psykose: ya, the archlinux build script isnt too long
2022-04-20 00:17:35 <anjan> I can prolly finally get jami working without flatpaks
2022-04-20 02:09:25 <anjan> psykose: any advice on this: https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/696956#L1883
2022-04-20 02:09:27 <anjan> =P
2022-04-20 02:10:57 <psykose> the meson files do not link to whatever the dht:: stuff comes from in the correct place
2022-04-20 02:11:34 <psykose> i.e. server_account_manager.cpp:(.text+0x3de4): undefined reference to `dht::http::Request::Request(asio::io_context&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<void (Json::Value, dht::http::Response const&)>, std::shared_ptr<dht::Logger>)'
2022-04-20 02:12:01 <psykose> means whatever server_account_manager.cpp ends up in as a .o needs to link whatever dht:: comes from
2022-04-20 02:12:09 <psykose> it's usually just a one line change, somewhere, in the build system
2022-04-20 02:12:25 <psykose> i would look at it but i'm too tired
2022-04-20 02:12:54 <anjan> ok please take a look when you can psykose 
2022-04-20 02:13:00 <anjan> no rush. thanks for the help
2022-04-20 02:13:06 <psykose> i'm sure you can also figure it o ut
2022-04-20 02:13:28 <psykose> you just grep for server_account_manager.cpp in the build files
2022-04-20 02:13:38 <psykose> and then see what it generates, where that thing gets used/linked, etc
2022-04-20 02:13:48 <psykose> then find out where dht:: is from, and make sure they are just linked together or whatever
2022-04-20 02:49:00 <anjan> sorry psykose Im having a hard time with this. Im also sleep deprived. Ill see if I can work on it again soon.
2022-04-20 02:49:16 <anjan> night!
2022-04-20 02:49:26 <psykose> nini
2022-04-20 04:26:52 <ikke> I use glab, making an MR for a branch for me is just typing: 'mr'
2022-04-20 04:27:01 <ikke> eddsalkield: ^
2022-04-20 04:27:14 <ikke> (which is an alias to glab mr create ...')
2022-04-20 04:53:13 <psykose> given that it has --fill-commit-body and i've wanted something like that for 50 years i set up the same binding
2022-04-20 04:53:50 <EvTheFuture> psykose: Tnx for review of !33413 I had to go with Release instead of MinSizeRel as the build type, otherwise I made suggested changes.
2022-04-20 06:46:12 <maribu> Has someone already MR'ed a rebuild of neovim to fix `vim/_init_packages.lua: cannot load incompatible bytecode`? Otherwise I would open one.
2022-04-20 06:46:36 <panekj> there is MR open for neovim upgrade
2022-04-20 06:47:15 <panekj> it waits for maintainer (jirutka)
2022-04-20 06:48:15 <panekj> unless that's needed for stable branches, for which feel free to MR
2022-04-20 06:48:56 <panekj> oops, neovim upgrade was merged 13h ago
2022-04-20 06:52:38 <psykose> the last touch of neovim was an upgrade so that sounds caused by it
2022-04-20 06:53:09 <psykose> not sure how you run into that though
2022-04-20 06:53:41 <psykose> i installed a fresh 0.7.0 one and it loads that fine
2022-04-20 06:55:24 <psykose> i would assume perhaps something has to be rebuilt against new neovim instead, but i've no idea as i always build my own anyway
2022-04-20 06:57:13 <maribu> panekj: OK, thanks for the info :) I'm on edge, I don't know if stable neovim also needs a rebuild.
2022-04-20 07:02:44 <psykose> what neovim-related things do you have installed other than neovim itself
2022-04-20 07:57:22 <ktprograms> eddsalkield: There's also a link/button at the bottom of the MR page that shows an email address that you _should_ be able to use to send MRs using email, but according to the GitLab docs[0] it seems like you need to attach .patch files, so it won't be git-send-email workflow. [0]:
2022-04-20 07:57:23 <ktprograms> https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#add-attachments-when-creating-a-merge-request-by-email
2022-04-20 08:05:37 <psykose> they do normally send email patches, the discussion was about updating them
2022-04-20 08:07:03 <ktprograms> Ah, sorry
2022-04-20 08:25:14 <ncopa> good morning
2022-04-20 08:25:29 <ncopa> i think the v3.16 builds have been unusually smooth
2022-04-20 08:26:17 <ncopa> which means that the alpine devs has done a great job
2022-04-20 09:31:53 <ikke> psykose did quite some fixing 
2022-04-20 09:33:30 <ikke> A few projects were broken with gcc11
2022-04-20 09:34:00 <ikke> Still waiting for Java on 64bit systems 
2022-04-20 10:02:54 <Ariadne> i had a thought on that
2022-04-20 10:03:01 <Ariadne> have we tried compiling java with clang?
2022-04-20 10:04:04 <Ariadne> if the issue is a miscompilation (which seems likely given we upgraded to GCC 11 in this cycle), then perhaps compiling with clang might yield better esults
2022-04-20 10:18:48 <fcolista> skarnet, what's the status of your work on s6/alpine init?, as stated here?  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33329#note_230846
2022-04-20 10:27:16 <skarnet> fcolista: still in (slow) progress. The init part really isn't a problem, we could switch at any time; the service management is the big part that requires a lot of work.
2022-04-20 10:28:19 <skarnet> we could do s6+openrc today while waiting for s6-rc, but Ariadne doesn't like the idea (and I think ncopa doesn't either). But s6-rc with the nice ui and everything... that will still take a while.
2022-04-20 10:29:01 <Ariadne> it's more that i am skeptical that there is any benefit to s6+openrc over busybox+openrc
2022-04-20 10:29:49 <psykose> i fixed over 100 packages, yes
2022-04-20 10:29:53 <psykose> re java clang.. is that possible?
2022-04-20 10:30:04 <Ariadne> i don't see why it wouldn't be
2022-04-20 10:30:05 <panekj> I'd prefer to see bb+s6-rc
2022-04-20 10:30:05 <psykose> afaik it builds openjdk7 with gcc-gcj-bootstrap-thing
2022-04-20 10:30:17 <psykose> unless it uses gcc-c for some things and gcj for others
2022-04-20 10:30:19 <skarnet> Ariadne: you mean apart from having a real supervisor everything can rely on including super early?
2022-04-20 10:30:22 <psykose> and the former can be replaced
2022-04-20 10:30:39 <psykose> i can test locally... sec
2022-04-20 10:30:41 <Ariadne> psykose: the C/C++ components get built with GCC 11 at present
2022-04-20 10:30:45 <psykose> ah, right
2022-04-20 10:31:02 <psykose> ok, i will do a local build of regular and CC= CXX= .. and see
2022-04-20 10:32:02 <Ariadne> we compile some things with clang already because they miscompile with GCC
2022-04-20 10:32:05 <psykose> yeah
2022-04-20 10:32:10 <psykose> i'm not opposed to it at all :)
2022-04-20 10:32:21 <psykose> i just haven't even tested the build yet, so i will see if it fails, then see if it's fixed
2022-04-20 10:33:37 <skarnet> panekj: on the off 1% chance you're engaging in good faith: s6-rc is meant to work with s6, because it ensures daemons are supervised. And once you're running a supervision tree, keeping bb init is redundant.
2022-04-20 10:34:07 <panekj> why are you assuming I'm Lennart in disguise trying to destroy Alpine?
2022-04-20 10:34:11 <Ariadne> yes, there is no need to use bb init on an s6-rc system, it makes no sense
2022-04-20 10:34:34 <Ariadne> my assumption is that panekj just wants something better than openrc now
2022-04-20 10:34:52 <Ariadne> (whether systemd is actually better is beside the point)
2022-04-20 10:35:47 <panekj> as I mentioned earlier here, I'm happy with openrc on systems where I works and I don't need more but I need more on systems such as my PC where e.g. user services are a thing
2022-04-20 10:35:51 <skarnet> panekj: I'm not assuming anything, I'm looking at your actions and you have caused that shitstorm voluntarily and gleefully, so do not expect any love from me
2022-04-20 10:36:06 <panekj> lol
2022-04-20 10:36:54 <ikke> skarnet: just making that MR is not deserving of that
2022-04-20 10:36:58 <panekj> I'm sorry but this is not me who started commenting on the MR
2022-04-20 10:37:55 <panekj> I really appreciate what ddev said and that is the person I'm most surprised with as he didn't excessively shittalked me
2022-04-20 10:37:59 <skarnet> you know exactly what you were doing when you opened it, so don't add insult to injury and spare the blame shifting
2022-04-20 10:38:23 <skarnet> knew*
2022-04-20 10:38:25 <Ariadne> can we not do this
2022-04-20 10:38:33 <Ariadne> the MR is already enough of a shitshow
2022-04-20 10:38:59 <panekj> +1
2022-04-20 10:39:39 <skarnet> can we address the obvious troll instead of tone policing
2022-04-20 10:40:12 <Ariadne> skarnet: i think that MR exists because alpine's current use of openrc has not been replaced by s6-rc :)
2022-04-20 10:41:22 <Ariadne> i would bet that if s6-rc/s6-frontend were already written, and alpine had docs on how to use these things to do user services, etc. that panekj would not have any motivation to import systemd
2022-04-20 10:42:00 <skarnet> ah yeah so now it's my fault for being too slow
2022-04-20 10:42:02 <psykose> i was meaning to test an -s6 service the other and thinking of getting some preemptive ground done on an example integration
2022-04-20 10:42:03 <skarnet> thanks for the support
2022-04-20 10:42:18 <psykose> i.e. -s6 subpackage, install_if something, etc etc
2022-04-20 10:42:25 <Ariadne> i'm not saying that, but i think it is fair to say that people have reasons to be frustrated with the status quo
2022-04-20 10:42:25 <psykose> but i couldn't actually really figure out how to get it started at all
2022-04-20 10:42:37 <psykose> because all i could find was s6-svscan being invoked on some /run tmpdir
2022-04-20 10:42:40 <Ariadne> and that frustration has turned into a systemd MR
2022-04-20 10:42:52 <psykose> and so i had no idea where to even place sample run scripts
2022-04-20 10:43:11 <psykose> and then i got sidetracked :) but i will keep looking at it
2022-04-20 10:43:13 <panekj> I've been on s6{,-rc} website more than 10 times and I still don't understand how to operate it
2022-04-20 10:43:23 <psykose> and maybe after somebody starts doing it, it will be easier to continue
2022-04-20 10:43:27 <panekj> I also tried to make user supervision tree and gave up at some point
2022-04-20 10:44:32 <psykose> eh, it's mostly the issue of too many parts
2022-04-20 10:44:37 <skarnet> Ariadne: nobody likes the status quo, but few people are under the delusion that systemd would help in any way
2022-04-20 10:44:38 <panekj> and I don't say that to blame you that it is the way it is, but to state and acknowledge that things aren't ready
2022-04-20 10:45:45 <Ariadne> skarnet: i think that systemd would solve some set of our problems while introducing new ones, and not solving the ones that actually matter (upstream not interested in meaningfully collaborating with alpine)
2022-04-20 10:45:49 <panekj> I've built systemd for fun, mostly because I didn't believe it would work on musl/Alpine, but it works though...
2022-04-20 10:46:07 <skarnet> psykose: I have offered my services to help with integration for literal years. They were rejected because the UI wasn't deemed nice enough.
2022-04-20 10:46:21 <psykose> i am not even talking from the perspective of history or alpine
2022-04-20 10:46:23 <psykose> you know me :p
2022-04-20 10:46:30 <panekj> and now that I've tried most components of systemd, I wouldn't mind using it as replacement for whatever Alpine uses, but that doesn't mean I will force everyone to do s
2022-04-20 10:46:31 <psykose> i just wanted to actually write something in it, and i will ask for help at some point
2022-04-20 10:46:34 <Ariadne> okay that one i have to call BS on, the yocto patches have been discussed many times :)
2022-04-20 10:46:34 <skarnet> So now I'm working on something more palatable, and to be honest, *I hate it* because it's more complex than I want to be dealing with
2022-04-20 10:47:08 <psykose> the other alpine gatekeepers can chime in on s6-''frontend'' whenever they wish
2022-04-20 10:47:17 <psykose> me- i'm but a humble person that merges garbage straight into aports
2022-04-20 10:47:49 <Ariadne> skarnet: i mean, you don't have to if you don't want to.  there's plenty of people on alpine side who can write an appropriate frontend -- we just want to know how to implement various patterns with s6 (but i've largely figured that out already)
2022-04-20 10:47:51 <panekj> i'm but a humble person that mr's garbage straight into aports :)
2022-04-20 10:47:53 <skarnet> so yeah, it will come at some point but I'm working out of my comfort zone here and I want to make things right and you can't rish that
2022-04-20 10:47:55 <skarnet> rush*
2022-04-20 10:48:14 <psykose> how many headpats does it take to rush it?
2022-04-20 10:49:08 <skarnet> Ariadne: well as soon as s6-rc v1 is out you'll be the first to know, but even that one is still going to take a bit
2022-04-20 10:49:42 <psykose> is s6-rc the thing that can/will start/stop services?
2022-04-20 10:49:43 <skarnet> but when it's out you can use it as a backend for whatever UI you like
2022-04-20 10:49:58 <skarnet> psykose: yes, it's roughly the equivalent of openrc
2022-04-20 10:50:02 <psykose> ah
2022-04-20 10:50:08 <psykose> so.. there is no way to do that at all yet?
2022-04-20 10:50:19 <skarnet> there is: s6-rc v0
2022-04-20 10:50:32 <psykose> ah, and it's already there
2022-04-20 10:50:35 <psykose> ok, i can work with that
2022-04-20 10:50:36 <skarnet> yes
2022-04-20 10:50:38 <psykose> i will go read some docs
2022-04-20 10:51:12 <Ariadne> s6-rc works with rundirs
2022-04-20 10:51:21 <Ariadne> there still needs to be a frontend of some sort
2022-04-20 10:51:22 <skarnet> but it's not super flexible, it's good for static situations (embedded etc.) but not when you need a lot of dynamic management
2022-04-20 10:51:47 <Ariadne> yes, one of the things wanted is the ability to postpone starting services until network is up
2022-04-20 10:51:49 <Ariadne> for example
2022-04-20 10:52:25 <skarnet> Ariadne: if you're ok with writing external frontends that can be a start though, to me the blocker on s6-rc v0 is more the lack of integration with external events than the lack of friendly ui
2022-04-20 10:52:39 <psykose> sure, but all i'm looking for is the equivalents to 'the /etc/init.d / conf.d directory' and 'rc-service x start' and 'rc-update'
2022-04-20 10:52:51 <psykose> because for packaging and direct usage, that is what is already used
2022-04-20 10:52:52 <Ariadne> psykose: we have to write those
2022-04-20 10:52:57 <psykose> nobody is '''intended''' to do anything else
2022-04-20 10:52:59 <Ariadne> s6-rc does not provide those
2022-04-20 10:53:13 <psykose> sure
2022-04-20 10:53:16 <Ariadne> s6-rc is not "openrc", it's "/sbin/runscript"
2022-04-20 10:53:23 <psykose> i think it would be good to get literally any prototype out then
2022-04-20 10:53:25 <skarnet> it's mechanism, not policy
2022-04-20 10:53:27 <psykose> doesn't matter how busted it is
2022-04-20 10:53:52 <psykose> i just want something i can actually test using and writing against in the same way we already do, and i can change all of it later
2022-04-20 10:54:17 <Ariadne> that's the frontend and it doesn't exist
2022-04-20 10:54:23 <psykose> yeah
2022-04-20 10:54:28 <psykose> seemingly so
2022-04-20 10:55:06 <psykose> i had assumed something existed, because skarnet mentioned something before about -s6 service subpackages not existing only being the case because nobody had made them yet
2022-04-20 10:55:15 <Ariadne> anyway, i don't think it would be that difficult to write a frontend to take something like TOML and generate the rundirs and so on
2022-04-20 10:55:22 <psykose> but if that equivalent doesn't exist this is not really possible
2022-04-20 10:55:35 <psykose> yeah, probably
2022-04-20 10:55:36 <skarnet> psykose: this is true, s6-rc source directory definitions can be written and packaged
2022-04-20 10:55:37 <psykose> i am not a programmere
2022-04-20 10:56:03 <skarnet> it can be done today, it's just that the format is significantly different from what most people are used to
2022-04-20 10:56:19 <skarnet> and that's why Alpine people were reluctant
2022-04-20 10:56:34 <psykose> skarnet: can you give an example of where this tree/file is placed after install, and how someone enables it at all
2022-04-20 10:56:35 <skarnet> but it *can be done* and I've said this for years
2022-04-20 10:56:42 <panekj> wouldn't mind writing frontend but it wouldn't be in C
2022-04-20 10:56:56 <psykose> tl;dr i'm dumb as fuck and you have to baby me a little
2022-04-20 10:57:24 <skarnet> psykose: np at all, can you ask in #s6? so other people can chime in and we stop spamming here
2022-04-20 10:57:37 <psykose> sure, but then i will have to do it when i am profoundly less tired
2022-04-20 10:57:51 <psykose> i will try to Not Forget
2022-04-20 10:57:55 <psykose> but i have been awake for forever
2022-04-20 10:58:01 <panekj> go sleep
2022-04-20 10:58:06 <psykose> nodon'ttellmetogotobediwon'tdoitit'sforgoodreasonsiswear
2022-04-20 10:58:16 <panekj> or I'll bonk 
2022-04-20 10:58:17 <Ariadne> anyway, i will gladly write a frontend
2022-04-20 10:59:08 <Ariadne> i just need some specs to work with
2022-04-20 10:59:52 <skarnet> the specs are here: https://skarnet.org/software/s6-rc/s6-rc-compile.html#source
2022-04-20 11:03:05 <Ariadne> panekj: assuming that an s6 frontend can be developed in a timely manner, are you interested in proceeding with this MR
2022-04-20 11:03:49 <skarnet> psykose, Ariadne: and for an example of what a set of s6-rc definition directories looks like: https://github.com/skarnet/lh-bootstrap/tree/master/layout/rootfs/etc/s6-rc/source-base
2022-04-20 11:05:23 <psykose> so we can just throw shit into /etc/s6-rc/service or /etc/s6-rc/services/service or something of that sort?
2022-04-20 11:07:08 <skarnet> psykose: almost, but then there's the compilation instruction. (the thing that openrc does at boot time without telling you)
2022-04-20 11:07:23 <Ermine> FWIW a set of services I use to boot Alpine: https://github.com/petershh/s6-rc-services
2022-04-20 11:07:56 <panekj> Ariadne: I wouldn't mind having and maintaining systemd stack in aports, so I can work on it even with s6 being completely done, but if big players are so extremely against it to the point of sentimental manipulation, I can drop it right now and just disappear
2022-04-20 11:08:18 <psykose> skarnet: is that the thing that also reruns the ''caching service dependencies'' or whatever
2022-04-20 11:08:25 <Ariadne> psykose: yes
2022-04-20 11:08:35 <psykose> noted
2022-04-20 11:08:49 <psykose> Ariadne: clang fails to build it entirely for other reasons
2022-04-20 11:08:54 <Ariadne> pog
2022-04-20 11:08:57 <psykose> hehe
2022-04-20 11:08:58 <psykose> error: clang-14unknown argument: '-fno-lifetime-dse'
2022-04-20 11:09:00 <psykose> : )
2022-04-20 11:09:26 <psykose> it is gcc hardcoded
2022-04-20 11:09:26 <psykose> hm
2022-04-20 11:09:28 <psykose> what if
2022-04-20 11:09:30 <psykose> we made it gcc6?
2022-04-20 11:09:37 <psykose> : D
2022-04-20 11:09:49 <Ariadne> should work
2022-04-20 11:10:12 <psykose> uhh
2022-04-20 11:10:21 <psykose> what is...
2022-04-20 11:10:36 <psykose> ah
2022-04-20 11:10:38 <psykose> g++6
2022-04-20 11:10:38 <psykose> ok
2022-04-20 11:10:57 <Ariadne> you may wish to verify those compilers actually work first
2022-04-20 11:11:14 <Ariadne> i have not actually tested them outside of bootstrapping gcj
2022-04-20 11:11:35 <psykose> well, if they didn't, they would fail to compile it
2022-04-20 11:11:45 <Ariadne> fair
2022-04-20 11:11:56 <ikke> ncopa: regarding information about subpackages in the global scope, did you already have some design in mind? The current mechanism (separate fields with : in the subpackages string") is not really extandable with shell parameter substitution
2022-04-20 11:12:07 <psykose> ah..
2022-04-20 11:12:10 <psykose> i think it's not possible
2022-04-20 11:12:28 <psykose> https://img.ayaya.dev/B0wUGp8NLAca.png
2022-04-20 11:12:33 <psykose> given libstdc++ of depends
2022-04-20 11:12:38 <Ariadne> yes, that's what i thought
2022-04-20 11:12:47 <psykose> unlucky
2022-04-20 11:12:52 <psykose> hm, well, no ideas then
2022-04-20 11:13:00 <Ariadne> it is probably possible to solve that
2022-04-20 11:13:03 <Ariadne> in gcc6
2022-04-20 11:13:24 <psykose> it's... moving around the dirs
2022-04-20 11:13:30 <psykose> i assume then it's fine
2022-04-20 11:13:50 <psykose> well
2022-04-20 11:13:55 <psykose> the compiler itself has multiple depends
2022-04-20 11:14:10 <psykose> weh
2022-04-20 11:14:52 <Ariadne> panekj: i think that any argument for accepting or rejecting systemd should be technical, not sentimental :)
2022-04-20 11:15:03 <Ariadne> i can come up with some technical arguments to reject it
2022-04-20 11:15:18 <Ariadne> namely, the relationship with alpine is worse than that of openrc which is already poor
2022-04-20 11:16:26 <Ariadne> as an experiment, it can be argued that the experiment is misconstrued as an official change, too
2022-04-20 11:16:37 <panekj> re: meson version, they aren't that far into bleeding edge versions
2022-04-20 11:16:45 <skarnet> for the record, I gave technical arguments on the MR, and they were royally ignored
2022-04-20 11:17:08 <Ariadne> skarnet: not by me, but i would vote no on using systemd as default init in alpine anyway
2022-04-20 11:17:10 <psykose> we package bleeding edge meson, so i'm not sure why that matters
2022-04-20 11:17:16 <Ariadne> psykose: muon
2022-04-20 11:17:27 <Ariadne> i do not want python in bootstrap.sh
2022-04-20 11:17:29 <psykose> for a testing/ systemd package this doesn't matter
2022-04-20 11:17:37 <psykose> and for muon support, it has nothing to do with meson versions
2022-04-20 11:17:40 <panekj> but we assume main
2022-04-20 11:17:42 <psykose> it can barely compile ancient meson
2022-04-20 11:17:49 <psykose> and by barely i mean it can't
2022-04-20 11:17:54 <psykose> it's really feature specific
2022-04-20 11:18:04 <Ariadne> it's rapidly improving
2022-04-20 11:18:13 <psykose> for various definitions of rapidly..
2022-04-20 11:18:17 <psykose> but i do admit it is developed
2022-04-20 11:18:19 <psykose> with company support
2022-04-20 11:19:17 <psykose> i will consider it workable when it reaches samurai status
2022-04-20 11:19:32 <Ariadne> muon is sponsored by a company ?
2022-04-20 11:19:34 <psykose> samurai is actually behind ninja now and fails on new things, but it's fine, because it's near perfect to older spec
2022-04-20 11:19:46 <psykose> so if muon says 'supports meson 0.50' that is a start
2022-04-20 11:19:49 <panekj> i remember I tried to package something and it was behind ninja by few versions
2022-04-20 11:19:50 <psykose> by company? no
2022-04-20 11:20:00 <psykose> but the lead dev is paid to work on it at the company
2022-04-20 11:20:02 <psykose> or so i heard
2022-04-20 11:20:05 <psykose> as in, that is the project
2022-04-20 11:20:18 <psykose> so... really the same thing
2022-04-20 11:20:41 <psykose> panekj: was it fortran
2022-04-20 11:21:07 <panekj> s/it/samurai
2022-04-20 11:21:07 <alpine-meetbot> panekj meant to say: i remember I tried to package something and samurai was behind ninja by few versions
2022-04-20 11:21:16 <psykose> yeah
2022-04-20 11:21:19 <psykose> i mean, the issue you ran into
2022-04-20 11:21:21 <panekj> but no, not fortran
2022-04-20 11:21:28 <psykose> because the only actual issue is uh
2022-04-20 11:21:30 <panekj> I don't remember anymore
2022-04-20 11:21:40 <psykose> https://github.com/michaelforney/samurai/pull/48
2022-04-20 11:22:33 <psykose> https://github.com/michaelforney/samurai/issues/36 (it's really the only 1.10 thing needed)
2022-04-20 11:22:49 <psykose> and specifically, this fails for any cmake fortran project with -G Ninja since they all use that, so it was just a guess :)
2022-04-20 11:37:53 <ncopa> ikke: yeah some thing like field separation with :
2022-04-20 11:38:36 <ncopa> but I have no good solution for it really. field separation with : is a bit ugly and limitations in shell language is making it hard to solve it in a nice way
2022-04-20 11:38:43 <ikke> yeah
2022-04-20 11:39:30 <ikke> another thing I thought about is doing foo_provides=, where foo is $splitfunc
2022-04-20 11:41:40 <ncopa> that requires use of eval. and eval is evil :)
2022-04-20 11:42:29 <ncopa> i have also though about embedding yaml or other markup lang
2022-04-20 11:42:56 <ncopa> or embed shell in a markup lang 
2022-04-20 11:43:33 <ncopa> which would require complete redesign of APKBUILD. also unrealistic as short term solution
2022-04-20 11:43:38 <ikke> yes
2022-04-20 11:43:50 <ikke> $${splitfunc}_provides
2022-04-20 11:44:41 <ncopa> another option is to have magic functions that hides the ugly bits
2022-04-20 11:45:44 <ncopa> subpackage foo --provides bar baz --depends $pkgname
2022-04-20 11:46:39 <ikke> But how to be able to observe that?
2022-04-20 11:47:24 <Ariadne> in melange the dependencies are purely declarative, including for subpackages
2022-04-20 11:48:02 <ncopa> when you parse the apkbuild you have the subpackage() function store it in some format, yaml, json or whatever
2022-04-20 11:49:01 <ncopa> Ariadne: where you have the spec of the format?
2022-04-20 11:49:14 <Ariadne> it's yaml
2022-04-20 11:49:14 <ikke> melange is pure yaml atm
2022-04-20 11:49:18 <Ariadne> i haven't written a spec yet :D
2022-04-20 11:49:37 <panekj> https://raw.githubusercontent.com/chainguard-dev/melange/main/examples/gnu-hello.yaml
2022-04-20 11:49:43 <Ariadne> ikke: i have a cursed "half yaml, half APKBUILD" evaluation mode sitting on my desktop
2022-04-20 11:50:20 <ikke> aha
2022-04-20 11:50:46 <ncopa> the melange thingy is pretty nice
2022-04-20 11:51:03 <ncopa> panekj: thanks!
2022-04-20 11:51:15 <ikke> Yes, but yaml itself, except for small documents, is a pain to work with
2022-04-20 11:51:22 <panekj> + project url: https://github.com/chainguard-dev/melange
2022-04-20 11:52:04 <Ariadne> ikke: there are plans to switch to CUE once it is more mature, along with the rest of the kubernetes stack
2022-04-20 11:52:17 <ikke> yes, I recall you mentioning that
2022-04-20 11:52:25 <Ariadne> (CUE is backwards compatible with YAML so this isnt a problem)
2022-04-20 11:52:38 <ikke> out of curiousity, when is CUE considered mature enough?
2022-04-20 11:52:52 <Ariadne> whenever k8s pulls the trigger basically
2022-04-20 11:53:02 <ikke> ok
2022-04-20 11:53:28 <panekj> from the docs it seems it's not backwards compatible
2022-04-20 11:54:13 <panekj> rather it can convert yaml to cue
2022-04-20 11:54:43 <panekj> https://cuelang.org/docs/integrations/yaml/
2022-04-20 11:56:06 <ikke> hmm, qemu 7 has been released
2022-04-20 11:58:25 <ncopa> ikke: im working on qemu
2022-04-20 11:59:39 <clandmeter> nice
2022-04-20 11:59:44 <clandmeter> does it bring lots of goodies?
2022-04-20 11:59:55 <psykose> heh, i was just doing it myself :)
2022-04-20 12:00:17 <psykose> not really, seems to be pretty tame https://wiki.qemu.org/ChangeLog/7.0
2022-04-20 12:00:52 <clandmeter> seems it does bring lots of rv changes
2022-04-20 12:00:52 <psykose> 3 removals, 2 deprecations
2022-04-20 12:01:10 <psykose> ah yes, big riscv
2022-04-20 12:01:21 <clandmeter> could be useful for our rv  qemu-user builder
2022-04-20 12:01:25 <ikke> ncopa: ok
2022-04-20 12:01:29 <psykose> hopefully, even by things not on the page
2022-04-20 12:01:45 <clandmeter> i guess it still have golang issues
2022-04-20 12:01:48 <clandmeter> from tiem to time
2022-04-20 12:01:52 <psykose> yeah
2022-04-20 12:01:58 <psykose> it's 90% golang packages that hang
2022-04-20 12:02:08 <ikke> does qemu-user benefit from kvm?
2022-04-20 12:02:11 <psykose> not counting things that fail explicitly
2022-04-20 12:02:44 <ikke> often due to outdated x/sys though
2022-04-20 12:02:52 <clandmeter> kvm is only useful on the same platform?
2022-04-20 12:02:56 <ikke> ah yes
2022-04-20 12:03:03 <psykose> is outdated x/sys a permanent hang?
2022-04-20 12:03:11 <ikke> psykose: no, just a failure
2022-04-20 12:03:20 <psykose> ah
2022-04-20 12:03:27 <psykose> because i'm really curious about the constant hangs
2022-04-20 12:03:32 <psykose> i.e. docker built before but now doesn't anymore
2022-04-20 12:03:50 <clandmeter> is that regarding rv or in general?
2022-04-20 12:03:50 <psykose> ocaml hangs forever, nodejs hangs forever, etc
2022-04-20 12:03:57 <psykose> just our riscv
2022-04-20 12:04:09 <clandmeter> right
2022-04-20 12:04:11 <psykose> and other distros have them in their rv support, so i'm curious why it never completes for us
2022-04-20 12:04:45 <clandmeter> things that do lots of io will hang, thats what i bumped into.
2022-04-20 12:04:51 <elibrokeit> why is the subpackages variable thing an issue? Shouldn't makedepends be conceptually all you need?
2022-04-20 12:04:53 <psykose> if i try myself on dev container i get the same result (just one core spinning forever on last step), but i never checked more
2022-04-20 12:04:53 <ikke> waiting for the rv64 boards to be delived
2022-04-20 12:04:54 <clandmeter> psykose: thats because we are doing qemu-user
2022-04-20 12:04:57 <ikke> delivered*
2022-04-20 12:05:04 <clandmeter> othjers are doing system qemu
2022-04-20 12:05:12 <psykose> ahh
2022-04-20 12:05:17 <psykose> maybe we should system qemu : )
2022-04-20 12:05:22 <psykose> elibrokeit: it's regarding the build order
2022-04-20 12:05:26 <Ariadne> thats slower
2022-04-20 12:05:34 <clandmeter> iittss vveerryy ssllooww
2022-04-20 12:05:35 <psykose> the build order solver does not see any depends= inside subpackages
2022-04-20 12:06:02 <elibrokeit> should the solution not then be that the build order solver should look at makedepends?
2022-04-20 12:06:04 <Ariadne> qemu-user is 50% native speed
2022-04-20 12:06:15 <Ariadne> qemu-system is like 25%
2022-04-20 12:06:17 <psykose> it does look at makedepends
2022-04-20 12:06:38 <psykose> the issue is if you have a package foo that has a provides=foo-xyz and something with makedepends=foo-xyz
2022-04-20 12:06:40 <clandmeter> we can try to upgrade to v7
2022-04-20 12:06:40 <ikke> elibrokeit: it's about virtual packages
2022-04-20 12:06:41 <psykose> this resolves to nothing
2022-04-20 12:06:59 <psykose> if the provides= is not top-level, and in a function(), then it's not tracked
2022-04-20 12:07:14 <elibrokeit> that sounds like a policy limitation, not a technical limitation
2022-04-20 12:07:24 <psykose> no, it's technical
2022-04-20 12:07:37 <psykose> you can solve it with policy, but there is no reason to prevent this
2022-04-20 12:07:55 <psykose> having virtual providers/dependencies is useful
2022-04-20 12:08:01 <elibrokeit> no, I mean
2022-04-20 12:08:36 <elibrokeit> treating virtual makedepends as NULL sounds like a decision someone made, not a fundamental impossibility
2022-04-20 12:08:46 <psykose> it's not treated as null
2022-04-20 12:08:50 <psykose> it was just not implemented
2022-04-20 12:09:28 <elibrokeit> *can* it be implemented? Or is the situation so bad that you need to move to a yaml packaging format (?)
2022-04-20 12:09:38 <psykose> if you put that foo-xyz from above into makedepends=, it's not ignored
2022-04-20 12:09:44 <ikke> elibrokeit: it _can_ be implemented
2022-04-20 12:09:47 <psykose> the solver just sees no actual ordering for it
2022-04-20 12:09:55 <ikke> It's just missing the information to be able to do it
2022-04-20 12:09:57 <psykose> because solver dumb and stupid and bad
2022-04-20 12:10:26 <psykose> it does still pull it in, and if an actual top-level package provides it, it will see it
2022-04-20 12:10:27 <Ariadne> nobody said anything about moving to a yaml packaging format
2022-04-20 12:10:41 <ikke> ncopa mentioned it
2022-04-20 12:10:54 <psykose> i.e. if you have an actual foo-xyz package, that will then resolve to come first, it's only invisible if the only provider of foo-xyz is in a subpackage
2022-04-20 12:11:15 <Ariadne> oh
2022-04-20 12:11:18 <psykose> so, java-jdk is only defined in subpackages.. and hence doesn't exist
2022-04-20 12:11:25 <Ariadne> well i just said that in another apk ecosystem, we solved it by forcing all metadata to be declarative
2022-04-20 12:11:52 <ikke> Yes, that's what ncopa was mentioning yesterday (have it in the global scope)
2022-04-20 12:12:17 <ikke> but shell is not that suitable for nested structured data
2022-04-20 12:12:25 <Ariadne> it is possible -- in theory -- for melange to process APKBUILDs unmodified (with some exceptions), so even using melange as a build engine instead of abuild is not requiring YAML packaging format
2022-04-20 12:12:55 <ikke> So one challenge we need to solve is: how to declare metadata for subpackages
2022-04-20 12:13:02 <ikke> in a declarative way
2022-04-20 12:13:04 <ikke> in shell
2022-04-20 12:13:08 <elibrokeit> this problem is "solved" in pacman / PKGBUILD via an ingeniously horrifying bit of internals named grep_function()
2022-04-20 12:13:14 <psykose> heh
2022-04-20 12:13:22 <elibrokeit> it mostly works reliably, believe it or not
2022-04-20 12:13:22 <psykose> terrible idea: just do it secfixes style
2022-04-20 12:13:24 <psykose> : )
2022-04-20 12:13:36 <Ariadne> 
ACTION gets out the pitchfork

2022-04-20 12:13:49 <Ariadne> there's too much heresy in alpine community this week
2022-04-20 12:14:02 <elibrokeit> (it also requires bash)
2022-04-20 12:14:02 <ikke> elibrokeit: I suggested doing something similar via a shell parser + AST
2022-04-20 12:14:04 <psykose> what if we replaced abuild with makepkg?
2022-04-20 12:14:06 <psykose> 
ACTION ducks

2022-04-20 12:14:26 <Ariadne> 
ACTION imagines an effigy of psykose, panekj and elibrokeit

2022-04-20 12:14:27 <elibrokeit> then you would need to acknowledge bash as critical build infra, I suppose
2022-04-20 12:15:10 <panekj> I think shell scripts should be gone from abuild, APKBUILD and others
2022-04-20 12:15:44 <Ariadne> what if we switched to rpm spec files
2022-04-20 12:15:46 <psykose> building stuff without shell scripts really doesn't make much sense
2022-04-20 12:15:55 <Ariadne> that way everyone can be miserable
2022-04-20 12:15:57 <psykose> something somewhere is still going to be calling the shell
2022-04-20 12:15:58 <ikke> well, building things does make a lot of sense
2022-04-20 12:16:29 <panekj> psykose: just because package needs it, doesn't mean I have to suffer while modifying build system
2022-04-20 12:16:30 <elibrokeit> rpm spec files are just shell scripts embedded into an *extremely* custom metadata format anyway
2022-04-20 12:16:42 <Ariadne> ok no takers
2022-04-20 12:16:44 <psykose> whadya mean by 'modifying build system'
2022-04-20 12:16:47 <Ariadne> what if we switched to debian/rules
2022-04-20 12:16:51 <elibrokeit> hacking on abuild?
2022-04-20 12:16:54 <psykose> that's just shell scripts inside a makefile
2022-04-20 12:17:10 <Ariadne> yes, but it's so terrible
2022-04-20 12:17:13 <psykose> hacking on abuild is easier than any other build system
2022-04-20 12:17:17 <psykose> it's just one file
2022-04-20 12:17:22 <Ariadne> everyone must suffer
2022-04-20 12:17:27 <psykose> i've modified it in place 50 times
2022-04-20 12:17:31 <ikke> one of the design princiciples of abuild was not too much magic
2022-04-20 12:17:32 <panekj> amount of files doesn't matter
2022-04-20 12:17:34 <elibrokeit> Ariadne: perfect, I love build formats that require 16 different files all working together to define how to build hello-world
2022-04-20 12:17:51 <panekj> it's the terrible thing of it being written in shell
2022-04-20 12:18:04 <psykose> it would be even worse in not shell, i promise
2022-04-20 12:18:14 <elibrokeit> kisslinux is better than debian/rules
2022-04-20 12:18:14 <Ariadne> dunno, melange is pretty simple
2022-04-20 12:18:23 <panekj> I second what ariadne said
2022-04-20 12:18:47 <elibrokeit> actually so is slackbuild
2022-04-20 12:19:14 <clandmeter> yaml with nested shell, kind of similar we do with CI
2022-04-20 12:19:36 <panekj> again, with all the love to debian devs, apt/dpkg/package format absolutely sucks and should be obliterated
2022-04-20 12:20:18 <Ariadne> yeah i couldn't think of anything worse than debian/rules
2022-04-20 12:20:30 <Ariadne> https://github.com/chainguard-dev/nginx-image-demo/blob/main/.melange.yaml is another melange example that is more involved than hello world :p
2022-04-20 12:20:51 <panekj> if your package system is supported by fpm, it sucks
2022-04-20 12:20:56 <Ariadne> https://github.com/chainguard-dev/zlib-patch-demo/blob/main/.melange.yaml and another one
2022-04-20 12:21:06 <psykose> fpm supports .apk files
2022-04-20 12:21:09 <psykose> :p
2022-04-20 12:21:18 <ikke> yes, but it just packages them
2022-04-20 12:21:21 <panekj> :')
2022-04-20 12:21:25 <psykose> does it natively build rules themselves?
2022-04-20 12:21:35 <ikke> ?
2022-04-20 12:21:45 <psykose> re package supported by fpm :p
2022-04-20 12:22:02 <ikke> You just declare what files go where and it packages them
2022-04-20 12:22:11 <ikke> You need to make sure averything is built before that
2022-04-20 12:22:19 <skarnet> okay but what if we described the package via directory hierarchies and empty files instead of a structured file, in order to avoid parsing?
2022-04-20 12:22:24 <skarnet> 
ACTION is already out

2022-04-20 12:22:46 <ikke> skarnet: thanks, I hate it
2022-04-20 12:22:57 <panekj> why does s6-rc has to have everything in different files
2022-04-20 12:23:06 <psykose> to avoid parsing
2022-04-20 12:23:20 <psykose> 
ACTION is so out she wrapped around and came back

2022-04-20 12:23:29 <skarnet> exactly, and also because it's easier for a package manager
2022-04-20 12:23:44 <skarnet> install a package -> add a file in a directory, launch the compilation command: easy
2022-04-20 12:23:57 <panekj> more files is simpler than 1 file?
2022-04-20 12:23:58 <skarnet> install a package -> modify an existing file? eeeeh... not cool
2022-04-20 12:24:06 <skarnet> yes, a lot simpler
2022-04-20 12:24:17 <skarnet> 1 file is good from a *human* perspective
2022-04-20 12:24:29 <skarnet> from an automation perspective, it's much worse
2022-04-20 12:24:33 <Ariadne> the entire point of alpine is that its designed to be easy for humans to use
2022-04-20 12:24:45 <panekj> that is when I noped out of s6-rc
2022-04-20 12:24:45 <skarnet> which is why ui frontends are good
2022-04-20 12:24:49 <Ariadne> [that upside down face i do here]
2022-04-20 12:25:10 <skarnet> having a machine-friendly format with a human-friendly frontend is the best of both worlds
2022-04-20 12:25:17 <skarnet> of course that requires the frontends to exist
2022-04-20 12:25:51 <Ariadne> what if we rewrote s6 in go
2022-04-20 12:25:56 <clandmeter> and more complex to maintain 
2022-04-20 12:26:05 <Ariadne> and then adopted debian/rules
2022-04-20 12:26:08 <Ariadne> for packages
2022-04-20 12:26:24 <skarnet> 10/10 ship it
2022-04-20 12:26:26 <ikke> and gentoo classes?
2022-04-20 12:26:49 <Ariadne> i think melange's pipelines are cleaner than gentoo classes
2022-04-20 12:27:00 <Ariadne> or, i should say subpipelines
2022-04-20 12:27:31 <clandmeter> gentoo classes are not really predictable what the hell they are doing 
2022-04-20 12:27:43 <ncopa> maybe something like this? https://tpaste.us/LeRW?hl=true
2022-04-20 12:28:39 <Ariadne> what i came up with was something more like
2022-04-20 12:28:43 <panekj> is that yaml in shell
2022-04-20 12:28:46 <ikke> yes
2022-04-20 12:29:00 <panekj> how much cursed can we get from that
2022-04-20 12:29:07 <ncopa> :)
2022-04-20 12:29:09 <ikke> panekj: We already have secfixes as yaml in shell
2022-04-20 12:29:17 <ncopa> but as comments
2022-04-20 12:29:20 <ikke> yes
2022-04-20 12:29:21 <panekj> as comments
2022-04-20 12:29:41 <ikke> ncopa: but how would abuild parse that?
2022-04-20 12:29:45 <Ariadne> what i had in mind was
2022-04-20 12:29:49 <Ariadne> [yaml stuff]
2022-04-20 12:29:50 <Ariadne> ---
2022-04-20 12:29:53 <Ariadne> [shell stuff]
2022-04-20 12:30:02 <Ariadne> like how jenkins does it
2022-04-20 12:30:03 <panekj> that sounds good
2022-04-20 12:30:12 <ncopa> Ariadne: yup. I have been down that road too
2022-04-20 12:30:43 <psykose> it would be nice if it was backwards-compatible too
2022-04-20 12:30:45 <ncopa> the problem is that it is nice to be able to do shell stuff for $pkgver etc
2022-04-20 12:30:48 <psykose> and the first was optional
2022-04-20 12:30:52 <Ariadne> yuck :)))
2022-04-20 12:30:53 <ncopa> and conditional makedepends
2022-04-20 12:31:16 <panekj> pkgver="{{ var }}"
2022-04-20 12:31:18 <Ariadne> melange has "build options" for conditional dependencies, etc
2022-04-20 12:31:40 <panekj> s/pkgver="{{ var }}"/pkgver: {{ var }}
2022-04-20 12:31:40 <alpine-meetbot> panekj meant to say: pkgver: {{ var }}
2022-04-20 12:32:08 <ncopa> would like to do some transformations like ${pkgver//./_}
2022-04-20 12:32:56 <panekj> github ci style, {{ split(var) }} :P
2022-04-20 12:32:59 <ncopa> ikke: abuild would parse it as: echo "$pkgver" | yaml-parser.lua 
2022-04-20 12:33:38 <ncopa> where yaml-parser.lua would store it as a single var in a single file or similar
2022-04-20 12:33:55 <ncopa> but thats internal presentation, whic can be whatever we want
2022-04-20 12:34:31 <ncopa> we could also do something like RPMs .spec files
2022-04-20 12:36:45 <ikke> But you need to somehow linearize it again if you want to use the information in abuild
2022-04-20 12:37:01 <Ariadne> clearly
2022-04-20 12:37:20 <Ariadne> `eval $(echo "$pkgver" | yaml-parser.lua)`
2022-04-20 12:37:24 <Ariadne> where yaml-parser.lua
2022-04-20 12:37:27 <Ariadne> prints
2022-04-20 12:37:33 <Ariadne> SUBPKG_FOO_BAR_BAZ=123
2022-04-20 12:37:54 <Ariadne> but this is all terrible
2022-04-20 12:38:05 <psykose> what if we petted the alpacas on the alpaca farm
2022-04-20 12:38:30 <panekj> what if we petted alice on the alice farm
2022-04-20 12:38:48 <panekj> psykose: go sleep
2022-04-20 12:38:54 <psykose> listen
2022-04-20 12:38:57 <psykose> i am up intentionally
2022-04-20 12:39:04 <psykose> so i can go to bed in 3-4 hours
2022-04-20 12:39:08 <Ariadne> awake with intention
2022-04-20 12:39:09 <psykose> and wake up in the morning in 2 days
2022-04-20 12:39:11 <psykose> so i can be gay
2022-04-20 12:39:13 <psykose> leave me be
2022-04-20 12:39:17 <psykose> >_<
2022-04-20 12:39:52 <panekj> be gay and do crime?
2022-04-20 12:39:59 <psykose> mostly just the former
2022-04-20 12:40:02 <psykose> no promises, though
2022-04-20 12:40:05 <Ariadne> also tbh
2022-04-20 12:40:06 <Ariadne> it should be
2022-04-20 12:40:12 <Ariadne> pkgmetadata="[giant yaml blob]"
2022-04-20 12:40:19 <Ariadne> imo
2022-04-20 12:40:22 <psykose> that also works
2022-04-20 12:40:32 <psykose> but at that point why is it yaml
2022-04-20 12:40:39 <psykose> we can pick something less indentation-sensitive
2022-04-20 12:40:50 <psykose> for something not so nested anyway
2022-04-20 12:40:53 <psykose> any ini fans :)
2022-04-20 12:41:08 <ikke> toml :P
2022-04-20 12:41:08 <Ariadne> psykosed
2022-04-20 12:41:13 <psykose> :p
2022-04-20 12:41:44 <psykose> the full toml spec is pretty big, but i think there was some formal in-between formal ini thing, depending on how hard it is to find something
2022-04-20 12:41:48 <psykose> idk, have fun bikeshedding it
2022-04-20 12:41:54 <psykose> i'm just adding more fuel :)
2022-04-20 12:42:11 <panekj> Ariadne: is that a systemd component? (:
2022-04-20 12:42:22 <Ariadne> idk you're the systemd packager
2022-04-20 12:42:46 <psykose> also i am a big fan of the repo renames
2022-04-20 12:43:02 <psykose> especially because maybe 'staging' and 'experimental' sound way more serious and people will stop putting that shit in a stable release
2022-04-20 12:43:27 <psykose> i know they will anyway, but
2022-04-20 12:44:51 <ikke> psykose: I don't think that's a bad idea
2022-04-20 12:44:59 <psykose> what isn't
2022-04-20 12:45:09 <ikke> staging + experimental
2022-04-20 12:45:17 <psykose> yeah, it's what ariadne has proposed moments ago
2022-04-20 12:45:21 <ncopa> >>> qemu*: Package size: 225.3 MB
2022-04-20 12:45:27 <ncopa> me doing stufff...
2022-04-20 12:45:33 <psykose> the only issue is migration
2022-04-20 12:45:36 <ncopa> >>> qemu*: Package size: 33.3 MB
2022-04-20 12:45:39 <psykose> but since it was always 'edge' only intentionally
2022-04-20 12:45:42 <psykose> i guess it's fine
2022-04-20 12:46:08 <Ariadne> no i mean for testing
2022-04-20 12:46:12 <panekj> there was some proposal for branch renames as well
2022-04-20 12:46:24 <psykose> yes, for testing
2022-04-20 12:46:25 <Ariadne> i do want to rename 'master' to 'edge' though in git
2022-04-20 12:46:45 <ikke> I would not be opposed to that
2022-04-20 12:47:41 <panekj> it would be also great to have pkgs.a.o link to gitlab.a.o
2022-04-20 12:52:19 <elibrokeit> the full toml spec has every problem it claims to solve in other config file formats
2022-04-20 12:53:16 <elibrokeit> and is explicitly incompatible with ini, because the creator of Tom's non-obvious, maximal language doesn't like ini
2022-04-20 12:53:30 <psykose> is ini even a standard
2022-04-20 12:53:48 <psykose> last i checked it was 'ini' which is whatever random thing claimed to be ini but differed in various ways
2022-04-20 12:54:01 <psykose> to me anything with [thing]\nstuff=1 is 'ini'
2022-04-20 12:55:01 <panekj> it's informal standard
2022-04-20 12:57:59 <ikke> Sounds like a contradiction :)
2022-04-20 13:07:53 <elibrokeit> It is in fact several standards that have the misfortune yo all share the sake file extension
2022-04-20 13:08:02 <elibrokeit> *to all share the same
2022-04-20 13:08:50 <psykose> that makes it quite meaningless then, unless you specify which :)
2022-04-20 13:09:02 <psykose> and so toml being 'not compatible' with ini is also not meaningful either
2022-04-20 13:09:19 <psykose> (even if it's all of them combined.. i guess)
2022-04-20 13:09:39 <elibrokeit> It was carefully designed to be compatible with none of them :)
2022-04-20 13:10:24 <elibrokeit> A bug report to "allow X and thereby make 99% of the most common ini variant successfully and correctly parse as toml by default" was rejected
2022-04-20 13:11:48 <elibrokeit> "Tom" said effectively, "I hate that format and will never accept anything that validates its existence"
2022-04-20 13:12:06 <psykose> i would also hate it if it secretly had 17 variants with slight ambiguity
2022-04-20 13:12:17 <psykose> and spite is powerful
2022-04-20 13:12:51 <panekj> there is only really one "standardises" format, which is the original format made up by Microsoft
2022-04-20 13:12:54 <elibrokeit> It certainly is. For example, I hold a lot of spite for toml because I have hatred that it has a first class datetime object 
2022-04-20 13:13:31 <elibrokeit> And thus all spec-compliant toml parsers must consider it a critical big if they don't handle date times correctly
2022-04-20 13:13:38 <elibrokeit> *critical bug
2022-04-20 13:14:19 <elibrokeit> (often they crash, because datetimes. Those are the lucky, obvious bugs)
2022-04-20 13:15:45 <psykose> well, if i wanted a format that had definite support for datetime.. :p
2022-04-20 13:23:59 <ncopa> idea for a tool: alpine-boot-image <unpack | pack | convert> FILE.iso
2022-04-20 13:24:22 <ncopa> alpine-boot-image unpack will unpack the .iso file using bsdtar
2022-04-20 13:24:41 <ncopa> pack will recreate the iso form a previously unpacked directory
2022-04-20 13:24:50 <ncopa> useful for changing boot options
2022-04-20 13:25:32 <ncopa> the convert would generate a file.img which would be a writeable vfat image instead of the read-only iso9660
2022-04-20 13:26:22 <ncopa> I also wonder if we should ship the rpi images as .img instead of .tar.gz
2022-04-20 13:27:20 <ikke> archlinux arm started with img, but went with tar files
2022-04-20 13:27:32 <ncopa> they did? interesting
2022-04-20 13:33:38 <psykose> coming next week: panekj opens `testing/glibc: new aport`
2022-04-20 13:34:44 <panekj> don't tempt https://usercontent.irccloud-cdn.com/file/Fyui56P7/image.png
2022-04-20 13:40:48 <psykose> +			amove /usr/share/qemu/edk2-aarch64-code.fd
2022-04-20 13:41:03 <psykose> isn't this the exact edk2 thing we couldn't package properly before :p
2022-04-20 13:41:14 <psykose> now just available via qemu-system-aarch64
2022-04-20 13:41:29 <psykose> or am i slightly mixing it
2022-04-20 13:41:59 <psykose> normally it's aavmf_code but this doesn't look different
2022-04-20 13:46:03 <minimal> psykose: the previous issue, from memory, was that the aarch64 code was being built but called ovmf rather than aavmf (the correct name for aarch64 UEFI)
2022-04-20 13:46:29 <minimal> the issue still remains that the aarch64 stuff is only packaged for aarch64 and the x86_64 stuff is only packaged for x86_64
2022-04-20 13:46:52 <psykose> yes, but that comes from edk2
2022-04-20 13:47:01 <psykose> this above thing is from qemu itself, is it something else or the same
2022-04-20 13:47:41 <minimal> ah, the "edk2-aarch64-code.fd" file is the UEFI *variable* storage stuff I think
2022-04-20 13:48:11 <ikke> ncopa: I think mostly so that users do not have to resize partitions afterwards
2022-04-20 13:49:49 <Hello71> isn't that called _VARS.fd
2022-04-20 13:50:11 <minimal> psykose: nope, typically a file like AAVMF_VARS.fd would be the variables and AAVMF_CODE.fd would be the actual UEFI code
2022-04-20 13:50:25 <psykose> what is it then
2022-04-20 13:50:45 <minimal> and likewise OVMF_VARS.fd and OVMF_CODE.fd for x86_64
2022-04-20 13:50:52 <ncopa> ikke: makes sense kind of. fat does not support resizing
2022-04-20 13:51:30 <ikke> ncopa: I recall their partitions (maybe except boot) were ext*
2022-04-20 13:52:04 <ikke> But they now give intructions to manually create the partitions and then extract the tar
2022-04-20 13:52:23 <ikke> https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4
2022-04-20 13:52:36 <minimal> psykose: dunno, looking at the existing qemu package I see lots of /usr/share/qemu/edk2-*-code.fd files
2022-04-20 13:52:54 <psykose> they seem suspiciously similar
2022-04-20 13:55:27 <Hello71> ncopa: huh? tails has used fatresize for some years now
2022-04-20 13:55:39 <Hello71> i guess it only dates to 2016, maybe that's new for you :p
2022-04-20 13:56:11 <ncopa> Hello71: iirc it will extract the contents to a temp dir and recreate the filesystem?
2022-04-20 13:56:14 <Hello71> i'm pretty sure gparted has been able to resize fat long before then, but possibly not parted
2022-04-20 13:57:30 <ncopa> interesting
2022-04-20 13:58:12 <Hello71> hm, fatresize doesn't seem to actually *do* anything, it just calls libparted... suspicious.
2022-04-20 13:58:43 <Hello71> regardless of how it works exactly, tails resizes the boot partition up to... 8 GB? on first boot
2022-04-20 13:59:27 <Hello71> based on the speed of the resizing, i'm quite sure it doesn't read the whole thing and write it out again, that would be very slow
2022-04-20 14:00:51 <ncopa> its in our testing repo
2022-04-20 14:00:55 <ncopa> we should move it
2022-04-20 16:32:44 <ncopa> I have started on an alpine installer testsuite using qemu and expect/tcl https://github.com/ncopa/alpine-installer-testsuite
2022-04-20 16:33:45 <bratkartoffel> ncopa: just read through the scrollback and found your question regarding java compatibility (2022-04-19 10:55:17). Java code compiled with one version is runnable by any later version, although some really really old api might be removed in the meantime. The other way, compiling with a later jdk and running on a lower jvm should also be possible if the build was configured for a specific target java version. It's good practice to 
2022-04-20 16:33:45 <bratkartoffel> specifiy the target java version in the buildfile, but some really old projects miss this setting so they default to the compiler java version as target version. Using makedepends=openjkd8 should be the safest option, but the runtime depends should stay at java-jre(-headless).
2022-04-20 16:37:05 <ncopa> bratkartoffel: thank you. that is what I suspected
2022-04-20 16:37:43 <ncopa> yeah, adding the idk version in makedepends sounds like the way to go
2022-04-20 17:03:15 <ncopa> hum. i dont understand how to make the tests fail with expect/tcl
2022-04-20 17:05:10 <Hello71> nice, i've been thinking about that for a while. i was debating between expect and openqa
2022-04-20 17:06:08 <Hello71> openqa is more feature-complete, but i think most of the features are for testing graphical installers
2022-04-20 17:06:24 <Hello71> and virtualized gui workflows in general
2022-04-20 17:09:12 <Hello71> not sure what's a good way to do fault injection
2022-04-21 12:22:16 <clandmeter> anybody know why sd_mod would sometimes be auto loaded and sometimes not, it then fails to mount root due to missing devices.
2022-04-21 12:55:13 <skarnet> clandmeter: race condition with modprobe and mdev, I'd guess
2022-04-21 12:57:28 <skarnet> the problem is that init_module(2) returns before devices appear, and the kernel doesn't provide a notification for when devices appear
2022-04-21 12:57:53 <skarnet> (and IIRC you can't inotify in devtmpfs)
2022-04-21 12:58:00 <skarnet> so the race condition cannot be solved
2022-04-21 12:58:32 <skarnet> so every time you load a module and the remainder of the script needs a device created by the module, you need to artificially sleep for a bit
2022-04-21 13:35:43 <ncopa> I added a simple installer test: https://github.com/ncopa/alpine-installer-testsuite/blob/main/test_disk_install.exp
2022-04-21 13:36:01 <ncopa> we should add tests for different setups and different iso images
2022-04-21 13:53:25 <minimal> ncopa: yes I was already considering the same thing recently
2022-04-21 14:27:05 <Hello71> skarnet: https://lwn.net/Articles/330378/ claims that Arjan van de Ven said in 2009 that "with sata you know when you are done and have all possible drives. No so much much with USB. So with SATA we can, and do, wait for the scan to complete at the right point in the boot". is that not true? or does it only work for in-kernel root 
2022-04-21 14:27:11 <Hello71> ... mounting?
2022-04-21 14:31:21 <skarnet> I don't know, I'm only talking about when init_module(2) returns compared to when the device node appears in /dev
2022-04-21 15:17:19 <ikke> https://tpaste.us/d41w 
2022-04-21 15:17:35 <ikke> busybox test suite hangs because sigpipe is ignored
2022-04-21 15:17:41 <ikke> trying to figure out where that comes from
2022-04-21 15:19:47 <psykose> perhaps nmeum feels like debugging this same thing yet again, that became less broken but is still broken
2022-04-21 15:19:49 <psykose> true magic
2022-04-21 15:20:21 <nmeum> ikke: mqtt-exec
2022-04-21 15:20:43 <nmeum> previously, we fixed it with https://github.com/ncopa/mqtt-exec/commit/64bf27e2ca1d300391457a819e85bcfb8bc9be63
2022-04-21 15:20:49 <ikke> nmeum: yes, I'm aware
2022-04-21 15:20:56 <nmeum> ok, but why is it back then? :D
2022-04-21 15:21:01 <ikke> but as you see in the output, aports-build has nothing ignored
2022-04-21 15:21:52 <nmeum> now I have to recall how to parse SigIgn
2022-04-21 15:22:05 <ikke> bit field
2022-04-21 15:22:08 <ikke> it's in hex
2022-04-21 15:24:53 <nmeum> so the lua process has SIGPIPE in it's ignore list?
2022-04-21 15:25:08 <ikke> yes
2022-04-21 15:26:10 <psykose> but somehow not all the time, since otherwise it would always fail
2022-04-21 15:26:14 <psykose> yet it usually passes :p
2022-04-21 15:28:20 <skarnet> nondeterministically ignoring signals doesn't sound good at all
2022-04-21 15:28:51 <nmeum> sounds terrific
2022-04-21 15:29:22 <psykose> signals should simply never be ignored
2022-04-21 15:29:31 <psykose> i will take my $1,000,000 , thanks
2022-04-21 15:30:03 <skarnet> 
ACTION SIGSTOPs psykose and takes the $1M

2022-04-21 15:30:34 <Shiz> there's a few that should be ignored ;p
2022-04-21 15:31:48 <Shiz> like SIGSYS
2022-04-21 15:33:19 <skarnet> and SIGSEGV... why does my system keep sending it... everything would be so much simpler if it didn't exist
2022-04-21 15:35:21 <Hello71> has strace -e %signal -p $(pgrep mqtt-exec) not been tried yet? or, actually, perf trace -a -e '*sig*' --call-graph dwarf
2022-04-21 15:38:07 <Hello71> signal disposition requires a syscall to change, so it should be easy to log all such changes, and even reasonably efficiently with kernel support
2022-04-21 16:18:52 <ikke> Hello71: I can try that
2022-04-21 16:19:11 <ikke> I think we already did that before when we figured out it was mqtt-exec
2022-04-21 16:19:58 <nmeum> yep
2022-04-21 16:28:42 <ikke> Hello71: Only thing that mentions PIPE is 624.020 ( 0.009 ms): sshd/0 rt_sigaction(sig: PIPE, act: 0x7fff6091ae30, oact: 0x7fff6091ae50, sigsetsize: 8) = 0
2022-04-21 16:28:51 <ikke> sshd, so not related to mqtt-exec / buildrepo
2022-04-21 16:30:48 <Hello71> mmhmm
2022-04-21 16:32:04 <Hello71> what exactly did you try? start tracing, restart mqtt-exec, buildrepo somehow gets SIGPIPE ignored again?
2022-04-21 16:32:44 <ikke> Hello71: I just ran it when it was still stuck
2022-04-21 16:33:07 <Hello71> well i mean the goal is to check who sets sigpipe to ignored
2022-04-21 16:33:25 <Hello71> so you have to run it before sigpipe is ignored and then hopefully catch the culprit
2022-04-21 16:33:43 <ikke> Hello71: but it stopped tracing when I ran it
2022-04-21 16:33:49 <ikke> it only ran for 1 or 2 seconds
2022-04-21 16:34:31 <ikke> So I killed the processes under abuild, so the build failed
2022-04-21 16:34:52 <ikke> Now buildrepo is no longer ignoring SIGPIPE
2022-04-21 16:35:00 <Hello71> hm, let me try
2022-04-21 16:35:27 <ikke> SigIgn: 0000000000000004
2022-04-21 16:40:38 <Hello71> i think the correct command is doas perf trace -a -e 'rt_sigaction' --call-graph dwarf. if it takes a while to start ignoring SIGPIPE, then maybe doas perf record -a -e 'raw_syscalls:sys_enter_rt_sigaction' --call-graph dwarf and then come back later
2022-04-21 16:41:23 <Hello71> it should be much more efficient than leaving strace -fke rt_sigaction running
2022-04-21 16:42:37 <Hello71> the only problem is i think it might still use too much disk... i can't think of a good way to have it only trace mqtt-exec and aports-build and buildrepo etc but not abuild and descendants
2022-04-21 16:45:04 <ikke> qevent syntax error: 'raw_syscalls:sys_enter_rt_sigaction'
2022-04-21 16:45:06 <ikke>                      \___ unknown tracepoint
2022-04-21 16:45:09 <ikke> (-q)
2022-04-21 17:22:02 <EvTheFuture> Today my lobvirtd 
2022-04-21 17:22:36 <EvTheFuture> Today my lobvirtd stopped working after I ran apk upgrade -a
2022-04-21 17:22:51 <psykose> what stopped working about it
2022-04-21 17:22:56 <EvTheFuture> I'm on edge and have been since I installed.
2022-04-21 17:22:59 <ikke> Hello71: perf stopped again
2022-04-21 17:23:00 <EvTheFuture> 2022-04-21 15:23:06.648+0000: 6332: info : libvirt version: 8.2.0
2022-04-21 17:23:02 <EvTheFuture> 2022-04-21 15:23:06.648+0000: 6332: info : hostname: gurkhost.valitron.net
2022-04-21 17:23:04 <EvTheFuture> 2022-04-21 15:23:06.648+0000: 6332: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/lib/libvirt/storage-backend/libvirt_storage_backend_rbd.so': Error relocating /usr/lib/librbd.so.1: _ZN13entity_name_t5parseESt17basic_string_viewIcSt11char_traitsIcEE: symbol not found
2022-04-21 17:23:23 <Hello71> is it out of disk space or something
2022-04-21 17:23:23 <EvTheFuture> Maybe some package that didn't got rebuilt? Or maybe something in my machine
2022-04-21 17:23:24 <psykose> can you post /etc/apk/repositories
2022-04-21 17:23:30 <psykose> and type `apk policy libvirt`
2022-04-21 17:23:34 <ikke> Hello71: 104G available
2022-04-21 17:24:00 <psykose> and `apk policy librbd`
2022-04-21 17:24:22 <EvTheFuture> I will, I'm not on my computer now and everything is in VMs on the machine. I'll get back as soon as I can start up again. Fortunately I always do a snapshot before upgrading.
2022-04-21 17:24:33 <Hello71> CONFIG_FTRACE_SYSCALLS=y is set on linux-lts and linux-virt, does /sys/kernel/tracing/events/raw_syscalls/sys_enter exist? is tracefs mounted?
2022-04-21 17:24:41 <psykose> those are only useful if it's after the upgrade in the broken state
2022-04-21 17:24:48 <Hello71> although if tracefs isn't mounted i don't think perf trace will work either...
2022-04-21 17:25:11 <ikke> I have 92M of logs atm
2022-04-21 17:25:20 <ikke> so it does work, but at some point stops
2022-04-21 17:25:33 <EvTheFuture> It might also be my machine, but I thought I reach out just in case. I'll get back soon with more intel
2022-04-21 17:25:33 <ikke> last things loggedn:
2022-04-21 17:25:35 <ikke> LOST 91 events!
2022-04-21 17:25:37 <ikke> LOST 22 events!
2022-04-21 17:25:39 <ikke> LOST 27 events!
2022-04-21 17:27:53 <Hello71> i guess it's not too happy about --call-graph, but without that i'm not sure how to find the issue...
2022-04-21 17:28:31 <ikke> maybe just using strace?
2022-04-21 17:29:34 <Hello71> i guess, but then which processes should be traced?
2022-04-21 17:29:48 <ikke> mqtt-exec + -f?
2022-04-21 17:30:14 <Hello71> er, wait, a process's ignored signals is whatever it starts with, plus whatever changes it makes itself
2022-04-21 17:30:52 <Hello71> so if we think that buildrepo should not have sigpipe ignored, then we need to trace buildrepo and its parent
2022-04-21 17:31:08 <ikke> right, but they are not persistent
2022-04-21 17:34:02 <Hello71> right, so mqtt-exec should be configured to invoke strace -ke rt_sigaction -o /tmp/aports-build-$(date -Is).strace aports-build instead of aports-build, and aports-build should be configured to invoke strace -ke rt_sigaction -o /tmp/buildrepo-$(date -Is).strace buildrepo instead of buildrepo. my premise is that we can't just do strace -fk aports-build because it will run very
2022-04-21 17:34:04 <Hello71> slowly, but if you think that's fine then it's certainly easier
2022-04-21 17:34:04 <ikke> waiting for the builder to finish the iteration
2022-04-21 17:34:08 <Hello71> or maybe -k isn't necessary? idk
2022-04-21 17:34:25 <ikke> Hello71: can't I use -p on a running process?
2022-04-21 17:34:58 <Hello71> sure, as long as you catch it before it starts ignoring sigpipe
2022-04-21 17:35:08 <EvTheFuture> My repositories
2022-04-21 17:35:10 <EvTheFuture> #/media/sda/apks
2022-04-21 17:35:12 <EvTheFuture> #http://dl-cdn.alpinelinux.org/alpine/v3.15/main
2022-04-21 17:35:14 <EvTheFuture> # http://dl-cdn.alpinelinux.org/alpine/v3.15/community
2022-04-21 17:35:16 <ikke> Hello71: yea
2022-04-21 17:35:16 <EvTheFuture> http://dl-cdn.alpinelinux.org/alpine/edge/main
2022-04-21 17:35:18 <EvTheFuture> http://dl-cdn.alpinelinux.org/alpine/edge/community
2022-04-21 17:35:20 <EvTheFuture> http://dl-cdn.alpinelinux.org/alpine/edge/testing
2022-04-21 17:35:45 <Hello71> if you know that buildrepo starts with sigpipe unignored, and then at some point it starts ignoring sigpipe, then the cause must be that buildrepo is invoking rt_sigaction at some point
2022-04-21 17:35:52 <EvTheFuture> libvirt policy:
2022-04-21 17:35:54 <EvTheFuture>   8.2.0-r1:
2022-04-21 17:35:56 <EvTheFuture>     lib/apk/db/installed
2022-04-21 17:35:58 <EvTheFuture>     http://dl-cdn.alpinelinux.org/alpine/edge/community
2022-04-21 17:35:59 <ikke> Hello71: yes, that's my theory
2022-04-21 17:36:22 <Hello71> afaik there is no other way to change a process's ignored signals
2022-04-21 17:36:31 <ikke> EvTheFuture: psykose asked about librbd
2022-04-21 17:36:39 <ikke> apk policy librbd
2022-04-21 17:36:44 <EvTheFuture> librbd policy:
2022-04-21 17:36:46 <EvTheFuture>   16.2.7-r3:
2022-04-21 17:36:48 <EvTheFuture>     http://dl-cdn.alpinelinux.org/alpine/edge/community
2022-04-21 17:36:50 <psykose> hm
2022-04-21 17:37:07 <panekj> apk fix \* --reinstall :)
2022-04-21 17:37:43 <EvTheFuture> Yes but I have to copy paste between computer and phone to get it here since my VMs are down :) 
2022-04-21 17:37:57 <EvTheFuture> Have done APK fix already
2022-04-21 17:38:24 <Hello71> i guess there is another problem with strace -e rt_sigaction -p $(pgrep buildrepo) which is that it will probably just tell us that lua invoked rt_sigaction but not which lua function
2022-04-21 17:38:44 <ikke> Hello71: yes, indeed
2022-04-21 17:39:08 <ikke> 16.2.7-r3 is the latest version
2022-04-21 17:39:10 <psykose> by the look of the missing symbols it looks like something related to libstdc++, but if you are only on edge that should not be an issue
2022-04-21 17:39:26 <psykose> the same file from me does not have them missing
2022-04-21 17:41:13 <Hello71> librbd 16.2.7-r3 is not lib/apk/db/installed? so then where is librbd from
2022-04-21 17:41:23 <Hello71> which librbd is in lib/apk/db/installed
2022-04-21 17:45:38 <psykose> oh, huh
2022-04-21 17:45:39 <psykose> weird
2022-04-21 18:03:18 <EvTheFuture> It seems like I must have built it myself sometime in the past. But how do I get it from edge?
2022-04-21 18:03:41 <EvTheFuture> It's not in world file
2022-04-21 18:03:56 <psykose> just apk add librbd
2022-04-21 18:04:00 <psykose> probably
2022-04-21 18:05:49 <EvTheFuture> Rebooting now, fingers crossed
2022-04-21 18:06:46 <psykose> you can run `ldd` on the same file and see if it has those same missing symbols
2022-04-21 18:06:55 <EvTheFuture> Yes now it works.
2022-04-21 18:06:58 <psykose> note it will always be missing two as they are expected to be there when it's dlopened, but
2022-04-21 18:07:00 <psykose> ah
2022-04-21 18:07:01 <psykose> nice
2022-04-21 18:07:20 <EvTheFuture> Thanks for the help and sorry for the trouble.
2022-04-21 19:22:39 <nmeum> ikke: technically, aports-build depends on lua-mqtt-publish which in turn uses mosquitto (which will ignore SIGPIPE) so maybe that's the issue?
2022-04-21 19:22:53 <psykose> hah
2022-04-21 19:23:13 <ikke> hmm
2022-04-21 19:23:22 <ikke> perhaps
2022-04-21 19:23:45 <nmeum> that's the only SIGPIPE stuff I found in the aports-build dependencies so far
2022-04-21 19:24:33 <ikke> right now I see aports-build ignoring SIGPIPE again
2022-04-21 19:24:46 <ikke> or rather, buildrepo
2022-04-21 19:25:02 <ikke> nmeum: but aports-build is shell, not lua?
2022-04-21 19:25:25 <nmeum> ah right, but it does depend on lua5.2-mqtt-publish
2022-04-21 19:25:28 <ikke> And aports-build itself ignores nothing
2022-04-21 19:26:49 <ikke> cat /proc/45755/status | grep Ign
2022-04-21 19:26:51 <ikke> SigIgn: 0000000000000000
2022-04-21 19:26:59 <ikke> cat /proc/45757/status | grep Ign
2022-04-21 19:27:01 <ikke> SigIgn: 0000000000001006
2022-04-21 19:27:11 <nmeum> hmhm, well I don't see any sigpipe stuff in the lua dependencies of buildrepo
2022-04-21 19:27:15 <nmeum> no idea then
2022-04-21 19:35:25 <Hello71> ikke: are you sure that buildrepo starts with sigpipe not ignored and then it becomes ignored at some point during its execution?
2022-04-21 19:36:06 <ikke> Hello71: I just see snapshots, so I'm not sure exactly when / how it happens
2022-04-21 19:36:37 <ikke> aports-build can call buildrepo multiple times
2022-04-21 19:36:41 <ikke> so it might not be the same process
2022-04-21 19:36:41 <Hello71> mmhmm
2022-04-21 19:37:03 <Hello71> don't your snapshots have pid?
2022-04-21 19:44:02 <ikke> aports-build: 0000000000000000
2022-04-21 19:44:09 <ikke> buildrepo: 0000000000001006
2022-04-21 20:04:00 <ikke> nmeum: short python snippet to decode them: https://tpaste.us/4oal 
2022-04-21 20:51:02 <anjan> Hi, can someone help me with this error? https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/696956#L1880
2022-04-21 20:51:36 <ikke> 'pupnp.cpp:(.text+0x3afd): undefined reference to `dht::http::Url::Url(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)''
2022-04-21 20:51:38 <ikke> hmm
2022-04-21 20:52:05 <ikke> my C++ is weak
2022-04-21 20:53:35 <psykose> i did look at the files once and saw that everything is under one module
2022-04-21 20:53:46 <psykose> so i have no idea what actual build issue it is :)
2022-04-21 20:54:00 <psykose> maybe includes
2022-04-21 21:01:47 <valerius> building with -Wl,--no-undefined should have told you more
2022-04-21 21:02:12 <valerius> but yes, includes
2022-04-21 21:02:34 <valerius> and/or a missing object file
2022-04-21 21:03:27 <anjan> someone in #jami said Im missing a flag
2022-04-21 21:03:31 <anjan> lemme try that out
2022-04-21 21:04:01 <anjan> thanks for looking into it. Ill try yours valerius because it sounds like I might run into more issues - jami's build system is not very good
2022-04-21 21:04:11 <anjan> otherwise, the video/audio call on jami is amazing
2022-04-21 21:04:35 <anjan> I was confident to build it on alpine cause you guys are always so helpful and knowledgeable =)
2022-04-21 21:09:23 <psykose> no-undefined is already on the linker invocation
2022-04-21 21:09:29 <ikke> psykose: are you going to push something soon? Otherwise I'll make an MR (I need to trigger x86_64 :P)
2022-04-21 21:09:34 <psykose> uhh
2022-04-21 21:09:57 <psykose> just push it :)
2022-04-21 21:10:39 <anjan> #jami says Im prolly missing -lopendht
2022-04-21 21:10:43 <anjan> that linking flag
2022-04-21 21:10:47 <anjan> no idea where to put that
2022-04-21 21:10:58 <psykose> i mean that is their responsibility
2022-04-21 21:11:00 <anjan> in the build system
2022-04-21 21:11:02 <psykose> to add to their build systemd
2022-04-21 21:11:05 <psykose> :p
2022-04-21 21:11:12 <psykose> arch doesn't add it and it's apparently fine
2022-04-21 21:11:27 <anjan> ya....they said ask to either make a patch or ask upstream =P
2022-04-21 21:11:34 <anjan> so I asked upstream cause idk 
2022-04-21 21:11:36 <anjan> lmfao
2022-04-21 21:12:30 <psykose> and adding it fails the same way
2022-04-21 21:12:52 <psykose> because it comes before the objects
2022-04-21 21:12:58 <psykose> so you have to hack it into meson instead
2022-04-21 21:13:21 <anjan> sighhhh
2022-04-21 21:13:26 <anjan> ok, Ill submit a bug report.
2022-04-21 21:13:38 <anjan> Im friends with one of the jami maintainers, maybe they can help me
2022-04-21 21:14:25 <psykose> you also don't need fpermissive
2022-04-21 21:15:47 <ikke> nmeum: Hello71 so now buildrepo does not ignore sigpipe (it's building bb atm)
2022-04-21 21:16:00 <ikke> aports-build (47185): 0000000000000004 
2022-04-21 21:16:08 <ikke> aports-build (47327): 0000000000000000 
2022-04-21 21:16:19 <ikke> buildrepo (47329): 0000000000000006
2022-04-21 21:18:47 <ikke> gotta love fix by strace
2022-04-21 21:19:11 <ikke> stunnel was stuck, ran strace, and it got unstuck
2022-04-21 21:20:31 <psykose> wow
2022-04-21 21:21:07 <skarnet> that often points to a race condition that strace solves by messing with the timings
2022-04-21 21:21:27 <ikke> skarnet: I mean while it's running
2022-04-21 21:21:34 <ikke> stracing a running process
2022-04-21 21:21:41 <skarnet> ah
2022-04-21 21:22:08 <skarnet> restarting the stuck syscall after the interruption did some magic then
2022-04-21 21:22:23 <ikke> yes
2022-04-21 21:22:36 <skarnet> in any case that's not a good sign :P
2022-04-21 21:22:58 <ikke> nope
2022-04-21 21:23:06 <ikke> stunnel is giving us problems all the time
2022-04-21 21:23:15 <ikke> being stuck for some reason
2022-04-21 21:23:41 <skarnet> may I interest you in s6-tls[cd], tlsifying a connection using bearssl
2022-04-21 21:24:31 <psykose> s6-tlscd: change directories over tls
2022-04-21 21:24:55 <ikke> skarnet: this is during building
2022-04-21 21:24:58 <ikke> I don't use it
2022-04-21 21:25:36 <skarnet> ah, so it's not the stunnel process that gets stuck, but the build process for stunnel?
2022-04-21 21:25:54 <ikke> In the test suite
2022-04-21 21:26:38 <skarnet> ah, well, obviously, who writes a test suite, sheesh
2022-04-21 21:27:28 <skarnet> (in all seriousness test suites should have timeouts and fail when things get stuck for too long)
2022-04-21 21:29:07 <psykose> tell that to the ~7 things a week i manage to get stuck on the builders
2022-04-21 21:29:08 <psykose> :p
2022-04-21 21:29:39 <Hello71> "21:11 <psykose> to add to their build systemd" have you considered build s6 instead /s
2022-04-21 21:30:18 <psykose> is there a frontend for build-s6 or do you have to cat text files into the compiler? /s
2022-04-21 21:31:46 <skarnet> you have to call the preprocessor, compiler, assembler and linker stages separately
2022-04-21 21:32:05 <skarnet> because they're _not the same job_ so it shouldn't be done by the same tool
2022-04-21 21:32:25 <psykose> insert eyeroll below this message
2022-04-21 21:36:11 <fluix> 🙄
2022-04-22 02:32:27 <anjan> psykose: what did you mean by "-G Ninja to them too" https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28671#note_220009
2022-04-22 02:32:53 <psykose> you add it to the first cmake invocation
2022-04-22 02:32:58 <psykose> -B build -G Ninja
2022-04-22 02:33:04 <psykose> then add samurai to makedepends
2022-04-22 02:33:53 <anjan> ah ok. Ill get that done now.
2022-04-22 02:52:44 <anjan> I accidentally git pushed from a computer where my work is outdated
2022-04-22 02:56:59 <anjan> ok, Ill recover another copy =P
2022-04-22 02:57:04 <anjan> 
ACTION is bad with computers

2022-04-22 08:05:21 <ikke> Isn't everybody? :p
2022-04-22 08:08:58 <anjan> haha tru
2022-04-22 08:11:23 <clandmeter> skarnet: thx for the information.
2022-04-22 09:32:35 <ncopa> any python/pytest experts? im trying to convert my expect/tcl tests to python and pytest
2022-04-22 09:33:02 <ncopa> i want to pass an arg to pytest. eg pytest --iso <FILE>
2022-04-22 09:33:44 <ncopa> then i want create a fixture with session scipt to extract that iso and get the initramfs and kernel
2022-04-22 09:34:40 <ncopa> oh... nm.. i got it
2022-04-22 14:23:44 <ncopa> I refactored the alpine-installer-testsuite to use python and pexpect instead: https://github.com/ncopa/alpine-installer-testsuite
2022-04-22 14:23:48 <ncopa> it is pretty nice now
2022-04-22 14:23:59 <ncopa> python is so much easier to deal with than tcl
2022-04-22 14:24:23 <ikke> nice
2022-04-22 14:24:31 <ncopa> plan is to set up a matrix with different filesystems for ROOTFS
2022-04-22 14:24:44 <ncopa> eg ROOTFS=xfs etc
2022-04-22 14:25:06 <ikke> What would it require for CI?
2022-04-22 14:25:13 <ncopa> it works with alpine-virt/standard x86 and x86_64
2022-04-22 14:25:18 <ncopa> that qemu can run
2022-04-22 14:25:27 <ncopa> and maybe that we have kvm
2022-04-22 14:25:34 <ikke> ok
2022-04-22 14:25:47 <ncopa> i will add tests for crypt root etc as well
2022-04-22 14:25:54 <ncopa> and was thinking of adding nvme storage
2022-04-22 14:26:07 <ncopa> diskless installs
2022-04-22 14:26:16 <ncopa> diless installs with encrypted config
2022-04-22 14:26:41 <ncopa> would be very nice if we could run it nightly or similar
2022-04-22 14:26:49 <ncopa> to detect breakages in installer early
2022-04-22 14:27:02 <ikke> yeah
2022-04-22 14:27:11 <ncopa> we could also add arm/aarch64/s390x/ppc64le
2022-04-22 14:27:15 <ikke> Was checking if we could use resources from Azure to run these tests
2022-04-22 14:27:18 <ncopa> can be emulated or native
2022-04-22 14:27:35 <fcolista> c00l ncopa 
2022-04-22 14:27:53 <ncopa> i thikn I need to adapt the test a bit for arm. change console=ttyAMA0
2022-04-22 14:28:26 <ikke> dv3 and ev3 instances on azure apparently support nested virtualization
2022-04-22 14:28:35 <ncopa> i would appreciate contributions on the testsuite
2022-04-22 14:28:47 <ncopa> it should be relatively easy to help
2022-04-22 14:29:03 <ncopa> ikke: sounds good
2022-04-22 14:29:16 <ncopa> shoudl also test set up xen with pv guest in there
2022-04-22 15:04:12 <Hello71> anjan: git push --force-with-lease
2022-04-22 15:07:44 <ikke> Is anyone looking at java btw? brattkartofel mentioned he would look a bit, but was not that experienced with 7/8
2022-04-22 16:05:44 <Ariadne> i think it is a vectorization issue with the crc32 code in the jar tool
2022-04-22 16:22:16 <Piraty> bratkartoffel: signal-cli is missing the manpage
2022-04-22 17:25:54 <andypost[m]> Is there a schedule for 3.16? I still wanna move php7 to testing before it
2022-04-22 17:26:43 <Ariadne> testing?
2022-04-22 17:26:46 <Ariadne> why not unmaintained :D
2022-04-22 18:31:02 <ikke> andypost[m]: openjdk is blocking atm, so you have at least some time left
2022-04-22 18:31:44 <ikke> andypost[m]: btw, I still need to figure out what's going on with Zabbix. There is one page where for some reason data gets sent before the session gets initialized (and thus an 'headers already sent' message)
2022-04-22 18:35:13 <panekj> ncopa: would it be okay to remove init scripts for missing services or is there a reason for them to be shipped in busybox-initscripts? e.g.: dnsd, httpd, ..
2022-04-22 18:36:24 <panekj> inetd
2022-04-22 18:37:48 <ikke> panekj: did you also check busybox-extras?
2022-04-22 18:38:35 <panekj> I looked up with `apk search -x cmd:<exec>`, nothing exists except for apache2 providing httpd
2022-04-22 18:39:22 <skarnet> please don't modify busybox-initscripts before ncopa has bumped alpine-conf and I can finally submit my MR that's been in limbo for *two months*
2022-04-22 18:39:23 <panekj> unless symlinks don't show up
2022-04-22 18:39:29 <ikke> panekj: correct
2022-04-22 18:39:39 <ikke> bb does not haver cmd: provides for anything other than busybox and sh
2022-04-22 18:39:45 <ikke> apk info -P busybox
2022-04-22 18:39:47 <panekj> right...
2022-04-22 18:40:14 <panekj> but even then those init scripts should be in busybox-extras
2022-04-22 18:47:17 <Hello71> it depends if there are more people who use openrc but not busybox-extra or use busybox-extra but not openrc
2022-04-22 18:47:42 <Hello71> "theoretically" they should be in busybox-initscripts-extras or busybox-extras-openrc
2022-04-22 18:49:12 <panekj> it's pulled in by alpine-base so I was confused why I have them but can't run it
2022-04-22 18:49:45 <skarnet> busybox-initscripts is basically a huge blob of misc stuff
2022-04-22 18:50:12 <skarnet> my pending MR shaves off *some* of the stuff in it and puts it in other packages
2022-04-22 18:50:31 <skarnet> shaving off more of that stuff would be a good thing if there's good reason for it
2022-04-22 18:51:13 <skarnet> but early openrc is so fragile that any modification is dangerous
2022-04-22 18:51:47 <skarnet> so if it works and there's no particular reason to touch it, don't touch it ^^'
2022-04-22 18:52:59 <panekj> weird opinion from someone who writes "correct" software
2022-04-22 18:53:37 <minimal> "when you are standing on eggs don't jump!" ;-)
2022-04-22 18:56:00 <skarnet> panekj: I write "correct" software from the start when I can; when faced with existing blobs, the priority is to keep them working
2022-04-22 18:56:59 <andypost[m]> Ariadne: because some aports depending on it(
2022-04-22 18:57:22 <skarnet> and it's important to put effort into where you can leverage the most useful changes, not so much into cleaning up fragile stuff that works despite being ugly
2022-04-22 18:58:02 <andypost[m]> ikke: it points to some bug
2022-04-22 18:58:28 <ikke> andypost[m]: I'm aware, and zabbix indicates that full 8.x support is not ready yet
2022-04-22 18:58:51 <ikke> So trying to figure out what is causing it so that we can patch it
2022-04-22 18:59:41 <andypost[m]> Thanks, at least all php7-* soon should be in testing
2022-04-22 19:04:14 <ikke> Well, we'd need to figure that issue with zabbix out before that can happen
2022-04-22 19:05:26 <Misthios> easy, move it as well :)
2022-04-23 02:50:35 <sam_> re zlib: make sure you have https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2
2022-04-23 02:50:52 <sam_> (https://github.com/madler/zlib/issues/613, https://github.com/madler/zlib/issues/618)
2022-04-23 02:54:40 <Ariadne> holy shit
2022-04-23 02:55:01 <Ariadne> sam_: i owe you a beer, this is why we are having CRC32 issues with java
2022-04-23 02:55:09 <Hello71> oh yeah, i forgot about that
2022-04-23 02:55:19 <Hello71> but does java jar actually use zlib?
2022-04-23 02:55:23 <Ariadne> yes
2022-04-23 02:55:33 <Ariadne> pretty sure
2022-04-23 02:56:33 <Hello71> huh, it does. i thought it would use some poorly ported java version
2022-04-23 02:58:50 <psykose> smh i was about to backport it :p
2022-04-23 02:58:52 <psykose> sam_: thanks
2022-04-23 02:58:57 <Ariadne> nah fastjar is C
2022-04-23 04:10:01 <craftyguy> is the aarch64 edge builder stuck?
2022-04-23 04:10:20 <craftyguy> the log 404's, and it seems to be quite far behind the others
2022-04-23 04:11:28 <psykose> maybe
2022-04-23 04:11:34 <psykose> but openjdk also takes like 5 hours on it
2022-04-23 04:11:41 <craftyguy> oh wow
2022-04-23 04:11:43 <psykose> and the logs always 404 until it completes the package
2022-04-23 04:12:06 <craftyguy> I see. I thought the logs were updated as it built, my mistake
2022-04-23 06:47:14 <ikke> oh, so not a real regression in zlib, but allowing buggy applications to continue to work
2022-04-23 06:52:55 <anjan> \
2022-04-23 06:53:00 <anjan> whoops
2022-04-23 06:53:02 <anjan> sorry guys
2022-04-23 08:47:02 <bratkartoffel> can someone please check why the openjdk11 package is still at 11.0.14, although the MR was merged yesterday and a buildlog for 11.0.15 exists on 3.15 and edge?
2022-04-23 09:16:25 <ikke> bratkartoffel: the package repo on the builders have 11.0.15
2022-04-23 09:16:36 <ikke> openjdk11 policy:
2022-04-23 09:16:38 <ikke>   11.0.15_p10-r0:
2022-04-23 09:17:18 <ikke> and here as well: http://dl-master.alpinelinux.org/alpine/edge/community/x86_64/openjdk11-jre-11.0.15_p10-r0.apk
2022-04-23 09:21:54 <ikke> bratkartoffel: btw: https://build.alpinelinux.org/buildlogs/build-3-16-aarch64/community/openjdk16/openjdk16-16.0.2_p7-r1.log
2022-04-23 09:29:07 <bratkartoffel> 3.15 is still on 11.0.14: https://tpaste.us/a01m
2022-04-23 09:29:11 <bratkartoffel> the same with edge: https://tpaste.us/NOBl
2022-04-23 09:29:40 <bratkartoffel> thanks, i'll look into the 3.16 build error with openjdk16
2022-04-23 09:32:19 <ikke> http://dl-master.alpinelinux.org/alpine/v3.15/community/x86_64/openjdk11-11.0.15_p10-r0.apk
2022-04-23 09:33:01 <bratkartoffel> yes, i see that the apk is available, but the apk update / apk search still use the old version. the same for pkg.a.o search, it still shows the old version
2022-04-23 09:33:31 <bratkartoffel> or am i missing something?
2022-04-23 09:34:01 <ikke> bratkartoffel: ftr, did you do an apk update?
2022-04-23 09:34:15 <ikke> https://tpaste.us/x5y7 
2022-04-23 09:34:22 <bratkartoffel> docker run --rm -it alpine:3.15 ash -c 'apk update && apk search openjdk11-jre-headless'
2022-04-23 09:39:41 <ikke> https://tpaste.us/yvYe 
2022-04-23 09:39:50 <ikke> We are having disk space issue
2022-04-23 09:39:52 <ikke> issues
2022-04-23 09:40:01 <ikke> dl-cdn appears to be behind
2022-04-23 09:40:45 <panekj> packages for v3.16 seem to be available already :)
2022-04-23 09:42:00 <Ermine> Don't you mind me backporting a package upgrade to 3.15?
2022-04-23 09:42:07 <EvTheFuture> !33516 is my first MR where a dependency package is in the same MR but as a separate commit. Just want to check with you experts if this is the way you want it to be done?
2022-04-23 09:42:46 <panekj> EvTheFuture: it's fine
2022-04-23 09:42:47 <psykose> yes
2022-04-23 09:43:09 <bratkartoffel> ikke: thanks for looking at it. hope that the cdn mirrors gets uptodate again soon. openjdk16 for 3.16 should build should be fine again with !33527
2022-04-23 09:45:27 <EvTheFuture> thanks                  │11:42:46         panekj | EvTheFuture: it's fine                                                                                                                                 │ dhruvin
2022-04-23 09:45:33 <ikke> bratkartoffel: we are working on new mirror distribution infra, 
2022-04-23 10:46:25 <EvTheFuture> I just noticed that some icons are missing in libvirt after the upgrade a couple of days ago. I just wonder how do one know which theme/icon package to use in order to have all required icons installed?
2022-04-23 13:11:28 <Newbyte> What would it take to make the team-maintained APKBUILDs thing happen?
2022-04-23 13:11:42 <ikke> Newbyte: this: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/46
2022-04-23 13:14:13 <Newbyte> Thanks!
2022-04-23 15:09:51 <Newbyte> Regarding the GNOME team, would it be possible for us to have an aports fork under the GNOME team namespace? When working on bigger updates (like the upcoming GNOME 43), it can be nice to have a shared repo so multiple people can work on the same MR. Last time we solved it by me letting Pablo work on my aports fork, but I think it would make more sense to have a shared repo dedicated to this.
2022-04-23 15:14:48 <sam_> conked out last night 
2022-04-23 15:14:52 <sam_> Ariadne, psykose: so glad i thelped!
2022-04-23 15:15:20 <ikke> sam_: thanks!!
2022-04-23 15:15:35 <ikke> 4 builders unblocked :)
2022-04-23 15:42:05 <sam_> <3
2022-04-23 16:02:25 <omni> the other day I tried to upgrade bison, !33422, but it failed on armhf, if anyone's interested
2022-04-23 16:03:08 <omni> I haven't looked yet at what has changed, since the currently packaged version, that might be related to this
2022-04-23 16:16:39 <omni> !24236 this and an rpi kernel bump?
2022-04-23 16:22:43 <omni> how does it work with when you choose to make a new release branch?
2022-04-23 16:23:25 <omni> are the 3.16 buildes on edge till you get everything to build and then create the branch?
2022-04-23 16:24:08 <ikke> yes, when we think 3.16 is ready, ncopa will create the 3.16 branch and tag v3.16.0, and will switch the 3.16 builders to track that branch
2022-04-23 16:25:24 <omni> kool, thanks
2022-04-23 16:25:57 <omni> so anything that goes into main and community before that wel
2022-04-23 16:26:11 <omni> *will go into the release
2022-04-23 16:26:43 <ikke> yes
2022-04-23 17:33:33 <Misthios> psykose icu should be done, lot less pain this time
2022-04-23 17:57:56 <ddevault> does anyone have a moment to review this patch? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33538
2022-04-23 17:58:44 <ddevault> I would ideally like the builders to chew on it before monday
2022-04-23 18:08:03 <sam_> i've seen nothing break with icu 71 fwiw
2022-04-23 18:08:05 <sam_> ... for once
2022-04-23 18:08:48 <Misthios> yeah same, was happy
2022-04-23 19:23:48 <humm> For a package consisting of material under different licenses, should the license parameter be just a list of those licenses or an SPDX expression? (ddevault, !33538)
2022-04-23 19:24:29 <ikke> They should be separated by AND and OR
2022-04-23 21:04:28 <craftyguy> ah the aarch64 edge builder is still stuck on openjdk :(
2022-04-23 21:08:15 <omni> 
ACTION is looking forward to the best Alpine Linux release ever!

2022-04-23 21:14:20 <ikke> craftyguy: kicked it
2022-04-23 21:15:01 <ikke> omni: what do you like about the upcomming release? :)
2022-04-23 21:21:26 <craftyguy> ikke: thank you!
2022-04-23 21:58:51 <psykose> Misthios: thank you so much!
2022-04-23 21:58:59 <psykose> sam_: <3
2022-04-23 22:26:46 <humm> ikke: the round minor number
2022-04-23 23:32:16 <omni> ikke: what's not to like? everything's just better!
2022-04-24 00:30:50 <Ariadne> ideally, different licensed components would be in different subpackages, but i don't think abuild supports that today :)
2022-04-24 03:50:50 <[[sroracle]]> I dunno about apk3 but apk2 certainly allows you to set different licenses for each subpackage
2022-04-24 03:51:04 <[[sroracle]]> I had to do this extensively with PHP and LibreOffice
2022-04-24 03:51:29 <[[sroracle]]> you just set license= in your split function
2022-04-24 03:53:59 <Ariadne> ah yes
2022-04-24 03:54:09 <Ariadne> i did not know if license was one of the ones where that was allowed :)
2022-04-24 07:33:54 <anjan> [[sroracle]]: do you mind documenting that in the wiki if it's not already there? I have a package I maintain that has multiple licenses and I didnt know we were supposed to be doing that
2022-04-24 11:48:51 <lucidiot> rss
2022-04-24 11:49:03 <lucidiot> oops wrong window
2022-04-24 13:10:33 <ikke> 2.0G Dec 24 18:25 ceph-dbg-16.2.7-r0.apk
2022-04-24 13:10:35 <ikke> oof
2022-04-24 13:11:09 <ikke> single package, 2G
2022-04-24 13:47:51 <a16bitsysop> ikke: I think vectorscan-dbg was even bigger as I think the CI failed it.
2022-04-24 13:53:52 <ikke> The issue is that we are running into limits with our mirror infra. We do have new hosts with more storage planned, but that still needs to be finalized, and we want to get 3.16 out
2022-04-24 13:57:20 <a16bitsysop> Okay, I think for massive ones like ceph and vectorscan it would be good to be able to build a “temporary” dbg subpackage in the CI to diagnose a problem.  But the CI has a limit on artifact size as well.
2022-04-24 13:58:54 <ikke> I was thinking about starting to use object storage for gitlab. Maybe something more is possible then
2022-04-24 14:00:09 <a16bitsysop> okay
2022-04-24 14:01:42 <PureTryOut> fun, my rootbld is broken. It complains about missing .so's while pulling in Qt{5,6}, but if I just do `abuild -r` it works fine. And I can install those packages regularly on my system as well
2022-04-24 14:55:26 <[[sroracle]]> anjan: i'm not commenting on what the appropriate policy is for Alpine, just that abuild and apk can do this
2022-04-24 17:50:42 <anjan> [[sroracle]]: oh ok, I was just curious about the "how" alpine can do this ;)
2022-04-24 18:27:27 <ikke> anjan: just like you can set other metadata on subpackages
2022-04-24 19:00:54 <anjan> ikke: ah, ok, Ill give that a try thanks
2022-04-24 19:39:33 <anjan> hey guys, I was wondering when you would freeze packages in community/. I want to coordinate a package I maintain's release with the 3.16 release
2022-04-24 19:41:20 <panekj> if you want to get in non-sec/fix bump, do it now, no point in waiting
2022-04-24 19:41:23 <ikke> in 2/3 weeks I guess?
2022-04-24 19:41:30 <ikke> There will first be a couple of release candidates
2022-04-24 19:41:53 <anjan> panekj: I want to do it asap. It's just I have to coordinate with others too
2022-04-24 19:42:00 <anjan> ikke: ok, Ill keep that in mind. Thanks
2022-04-24 19:54:59 <Cogitri> ikke: Can we have an aports fork in the GNOME group? That would make collaborating on GNOME updates a tad easier
2022-04-24 19:56:16 <ikke> right, Newbyte asked something similar
2022-04-24 20:08:09 <ikke> Cogitri: will think about it / discuss it
2022-04-24 20:08:24 <Newbyte> is there anything particularly controversial about it?
2022-04-24 20:09:03 <ikke> mostly that the team/* namespace was meant just as user groups
2022-04-24 20:09:41 <ikke> But one option would be to create a gnome group
2022-04-24 20:14:45 <ikke> a16bitsysop: we now at least have one t1 mirror that is working again :)
2022-04-24 20:15:51 <psykose> maybe even two!
2022-04-24 20:16:25 <ikke> nld5 is still completely full
2022-04-24 20:18:10 <a16bitsysop> ikke: 👍️
2022-04-24 20:35:57 <a16bitsysop> ikke: is that because it hasn't synced or it has less space?
2022-04-24 20:44:43 <ikke> less space
2022-04-24 20:48:39 <a16bitsysop> looks like it is failing on builders with 17.2.0 still with 'fatal error: global_legacy_options.h: No such file or directory'
2022-04-24 20:48:49 <ikke> yes, we noticed
2022-04-24 20:48:57 <ikke> https://tracker.ceph.com/issues/55256
2022-04-24 20:49:13 <ikke> might be a race condition
2022-04-24 20:51:56 <a16bitsysop> yes the builders and CI both have same version of gcc
2022-04-24 20:53:30 <a16bitsysop> if its a race changing the jobs might help :https://git.alpinelinux.org/aports/tree/testing/ceph17/APKBUILD#n195
2022-04-24 21:06:01 <a16bitsysop> The CI for ceph aarch64 says 32cores, there is no hardware/vm info in the builder log
2022-04-24 21:06:16 <ikke> it's a qemu vm
2022-04-24 21:06:26 <ikke> oh, builder
2022-04-24 21:06:31 <ikke> it has 80 cores per builder
2022-04-24 21:07:12 <ikke> nproc returns 80
2022-04-24 21:07:13 <a16bitsysop> I can try another MR with less jobs
2022-04-24 21:07:49 <ikke> probably impossible to find where to add the proper build system dependency?
2022-04-24 21:14:58 <a16bitsysop> see if !33571 builds on the CI
2022-04-24 23:21:36 <a16bitsysop> it looks like python is used to create it: https://github.com/ceph/ceph/blob/29941e306fc04d9b33ff6d68921c92b4f4a09512/src/common/options/CMakeLists.txt#L33
2022-04-24 23:28:34 <psykose> i have something to try
2022-04-25 05:09:27 <a16bitsysop> looks like it worked :) a google for cmake_object_order_depends_target_common-options-objs only returns your commit!
2022-04-25 07:15:39 <ikke> ddevault: harec on rv64: ".build/cppcache:37: *** multiple target patterns.  Stop."
2022-04-25 07:16:11 <ddevault> ikke: can you run it again? I think that issue is nondeterministic
2022-04-25 07:16:20 <ddevault> will file a ticket to investigate in the meanwhile
2022-04-25 07:17:00 <ikke> ok
2022-04-25 07:17:37 <ddevault> https://todo.sr.ht/~sircmpwn/hare/655
2022-04-25 09:50:16 <omni> does 'apk list --depends' only work with installed packages?
2022-04-25 09:51:22 <omni> I'm trying to figure out what aports would need a bump with !33583
2022-04-25 09:51:55 <ikke> look at ap revdep from lua-aports
2022-04-25 09:52:13 <ikke> omni: if you use list --depends, you need to use the soname
2022-04-25 09:53:01 <ikke> omni: apk list --depends so:libmbedtls.so.12 
2022-04-25 09:53:52 <omni> yes, sure, I did
2022-04-25 09:54:02 <omni> is there documentation for lua-aports?
2022-04-25 09:56:03 <omni> ikke: but would 'apk list --depends so:libmbedtls.so.12' work also with non-installed packages?
2022-04-25 09:56:21 <ikke> yes
2022-04-25 10:00:46 <omni> thanks!
2022-04-25 11:22:36 <omni> this would be nice https://github.com/openzfs/zfs/issues/10404
2022-04-25 11:22:56 <omni> (syslinux ZFS support)
2022-04-25 11:35:24 <omni> !33583
2022-04-25 11:48:05 <skarnet> ncopa: friendly ping about the alpine-conf version bump
2022-04-25 12:09:43 <ncopa> 👍
2022-04-25 13:39:09 <panekj> ncopa: also friendly ping about !33088
2022-04-25 13:43:01 <Hello71> that patch seems... suspicious
2022-04-25 13:44:20 <Hello71> but the original code is dubious too, what is ([[:alpha:]]#)# supposed to mean
2022-04-25 13:47:52 <panekj> no idea :) whole zsh completions look terrible
2022-04-25 14:01:36 <ncopa> was caskd who wrote it initially and introduced it. not sure I have mental energy to analyze that :)
2022-04-25 14:02:49 <panekj> if only it was as easy as fish completions: `complete -f -c apk -n "__fish_seen_subcommand_from add info fetch dot" -a "(apk search -q)" -d Package`
2022-04-25 14:03:04 <Hello71> i mean i'm inclined to say that it works in this specific case, probably, but if you put * there then it makes most of the expression redunant
2022-04-25 14:03:54 <Hello71> it basically turns into ${$(apk list)%%-[[:digit:].]*} i think
2022-04-25 14:03:59 <panekj> is zsh using pcre2?
2022-04-25 14:04:23 <Hello71> yes but this isn't a regex
2022-04-25 14:04:51 <Hello71> as you'll note by the presence of (* and ##
2022-04-25 14:05:03 <Hello71> actually, no, zsh uses pcre
2022-04-25 14:05:10 <panekj> I thought it was some superset
2022-04-25 14:05:35 <Hello71> well (* doesn't make any sense in regex, even as an extension
2022-04-25 14:05:47 <Hello71> i guess you could define it as (.* but why
2022-04-25 14:06:05 <Hello71> it's an extglob, same as bash which got it from ksh
2022-04-25 14:06:59 <Hello71> the only added syntax here is that bash doesn't allow ${$(cmd)%pat}, you have to write var=$(cmd); ${var%pat}
2022-04-25 17:13:29 <ikke> ddevault: now hare: Abort: ./os/exec/cmd.ha:79:1: execution reached unreachable code (compiler bug)
2022-04-25 17:13:38 <ddevault> when doing what?
2022-04-25 17:13:46 <ikke> Building hare on rv64
2022-04-25 17:13:49 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/hare/hare-0_git20220424-r0.log
2022-04-25 17:13:54 <ddevault> bah
2022-04-25 17:14:34 <ddevault> will investigate tomorrow
2022-04-25 17:15:10 <ikke> sure
2022-04-25 17:19:49 <durrendal> oooh cool we're getting hare on Alpine, and risc support even, that feels cool
2022-04-25 22:16:05 <sdomi> mm.. I wanted to update main/ser2net to 4.3.5, but it seems that it now depends on `gensio.h`, created by the same author. I would provide a separate package for gensio, but I'm troubled about which repo should it be put in
2022-04-25 22:16:29 <sdomi> ... I guess it should be in main, but what's exactly the procedure of getting a package into main?
2022-04-25 22:16:36 <sdomi> cc: ncopa..?
2022-04-25 22:38:48 <anjan> hi all, does anyone know where I can grab mkmr?
2022-04-25 22:39:04 <anjan> The web interface for gitlab is brutal
2022-04-25 22:40:28 <anjan> oh, Im guessing it's been superseded by the gitlab mailing list bot?
2022-04-25 22:40:54 <sdomi> anjan: looks deprecated to me
2022-04-25 22:40:57 <anjan> ya
2022-04-25 22:41:02 <anjan> sdomi: Ill use the mailing list
2022-04-25 22:41:07 <anjan> I prefered the mailing list anyways
2022-04-25 22:47:42 <c7s> when you upgrade your kernel, the modules for the currently installed kernel get deleted, would it make sense to keep the modules around for the currently installed kernel?
2022-04-25 22:51:40 <sdomi> c7s: afaik it's like that to prevent bloat. When would you delete obsolete modules? we don't really have a mechanism to handle that AFAIK
2022-04-25 23:02:59 <c7s> sdomi: when they'd get deleted is the question, yeah
2022-04-25 23:03:08 <c7s> you'd obviously have to have two sets of modules around at at least some point
2022-04-25 23:03:13 <c7s> if you did that
2022-04-25 23:03:47 <panekj> it was brought up before, I think the idea was to keep all previous modules until next reboot
2022-04-25 23:04:11 <c7s> that would make sense, but I'm not sure what program would be responsible for that
2022-04-25 23:04:18 <c7s> i.e. not apk
2022-04-25 23:04:24 <panekj> not sure if there is a specific issue opened for that, but I vaguely remember it was discussed with ncopa 
2022-04-25 23:04:39 <c7s> if there isn't, should I open one?
2022-04-25 23:05:37 <panekj> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12157
2022-04-25 23:07:01 <panekj> why wouldn't apk be responsible for that? c7s 
2022-04-25 23:07:34 <c7s> panekj: because apk doesn't run as part of the boot process
2022-04-25 23:07:46 <panekj> essentially this could be just a post-upgrade trigger
2022-04-25 23:07:49 <c7s> I meant it wouldn't be apk if they; were deleted at boot
2022-04-25 23:07:58 <c7s> of the new kernel
2022-04-25 23:08:17 <c7s> it could be apk if you wanted to keep modules for kernel N and N-1
2022-04-26 07:18:05 <anjan> hi yall, is there anyway for me to send an email to the lists.alpinelinux.org and have you guys know I want it merged into 3.15
2022-04-26 07:18:33 <anjan> 
ACTION is trying to knock out some security issues he found and git send-email is much faster than gitlab ui

2022-04-26 07:18:44 <ikke> anjan: you know about glab?
2022-04-26 07:19:07 <ikke> for me, making an mr is: `mr`. Specyfing target branch: `mr -b 3.15.stable`
2022-04-26 07:19:20 <ikke> ddevault: any way to specify the target branch through the mailing list?
2022-04-26 07:20:10 <ikke> mr is an alias for glab mr create --remove-source-branch --allow-collaboration --fill --head kdaudt/aports --yes 
2022-04-26 07:20:43 <anjan> ikke: glab is neat. I just really like the git send-email workflow
2022-04-26 07:20:59 <anjan> if git send-email doesnt allow me to do what I need, Ill use glab
2022-04-26 07:21:10 <anjan> cause alpine is an amazing distro =D
2022-04-26 07:21:27 <ikke> Another disadvantage (atm) of using the mailing list is that you cannot update branches
2022-04-26 07:21:31 <ikke> so each fix needs to create a new MR
2022-04-26 07:21:32 <ddevault> ikke: no
2022-04-26 07:21:50 <ikke> anjan: ^
2022-04-26 07:21:58 <anjan> could we specify it in the commit message and the alpine linux mailbot just does it for us? ikke 
2022-04-26 07:22:06 <anjan> I would be willing to send in a patch to do that
2022-04-26 07:22:18 <anjan> I saw someone else on the mailing list complain they couldnt specify the branch
2022-04-26 07:22:22 <ikke> You can discuss that with ddevault, who maintains it
2022-04-26 07:22:50 <ddevault> I will rewrite the mailing list bot At Some Point(TM)
2022-04-26 07:22:52 <ddevault> until then, it is what it is
2022-04-26 07:23:10 <anjan> ok, I guess I have to us glab
2022-04-26 07:23:13 <anjan> thanks yall
2022-04-26 07:36:04 <anjan> nice glab is good
2022-04-26 07:45:27 <anjan> So arch and gentoo have this thing that will look on your system all the install packages and compare it to the vulnerable packages on their tracker.
2022-04-26 07:46:03 <anjan> Im wondering if it would be useful to have a tool similar to that for alpine where it looks through your installed packages and compares with whats vulnerable on security.alpinelinux.org
2022-04-26 07:46:44 <anjan> Might encourage others to contribute security fixes or atleast know about the issue since theyre personally vulnerable.
2022-04-26 07:46:57 <anjan> Does such a tool already exist?
2022-04-26 07:47:33 <ikke> security scanners like snyk?
2022-04-26 07:54:15 <anjan> ikke: i havent heard of synk. I was thinking of arch-audit or glsa-check
2022-04-26 07:54:45 <ikke> These are more generic security scanners, not specific to alpine linux
2022-04-26 07:55:17 <anjan> Oh, I guess I should just use those if Im interested in that...
2022-04-26 09:51:18 <Daanct12> the latest edge upgrade broke xfce4
2022-04-26 09:51:38 <Daanct12> seems like x11 support hasn't compiled in for some reason
2022-04-26 09:52:00 <Daanct12> melt-a5:~$ DISPLAY=:0 dbus-launch --autolaunch=67f7adb62de864e61d3760aa62361a5d --binary-syntax --close-stderr
2022-04-26 09:52:00 <Daanct12> Autolaunch requested, but X11 support not compiled in.
2022-04-26 09:59:47 <ncopa> morning
2022-04-26 09:59:51 <ncopa> or good day maybe
2022-04-26 10:00:27 <ncopa> I just rebooted my machine but I cannot log in to xfce. got error: Unable to contact settings server.
2022-04-26 10:00:40 <ncopa> Could not connect: Connection refused
2022-04-26 10:02:30 <Daanct12> yep, that's the exact same error i was having on my samsung a5
2022-04-26 10:02:58 <Daanct12> went through the log mentioning that command ^
2022-04-26 10:05:51 <ncopa> x11 support is not compiled in where?
2022-04-26 10:05:59 <ncopa> dbus?
2022-04-26 10:07:17 <ncopa> ah. bus upgraded recently
2022-04-26 10:19:20 <ikke> b869d9e7eaf4724edbad8320ea6129fb9e442059
2022-04-26 10:20:04 <ncopa> Daanct12: you are right. dbus is not built with x11 apparently
2022-04-26 10:21:18 <ncopa> $ curl --silent https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/dbus/dbus-1.12.22-r1.log | grep X11
2022-04-26 10:21:18 <ncopa> 	so:libX11.so.6
2022-04-26 10:21:18 <ncopa>         Building X11 code:        yes
2022-04-26 10:21:49 <ncopa> but 1.14.0 does not have that 'yes'
2022-04-26 10:23:57 <Daanct12> good catch, i wonder where the problem would be
2022-04-26 10:24:06 <ncopa> im investigating
2022-04-26 10:24:13 <ncopa> reading the configure script
2022-04-26 10:26:13 <ncopa> seems like they had a number of fixes to x11 detection after 1.14 release
2022-04-26 10:26:17 <ncopa> https://github.com/freedesktop/dbus/commits/master/configure.ac
2022-04-26 10:26:28 <ncopa> on March 1
2022-04-26 10:30:52 <ncopa> yup. those patches fixes it
2022-04-26 10:30:55 <ncopa> kinda bad though
2022-04-26 10:31:37 <ncopa> they make a release and silently build without x11 even if it is explicitly requested
2022-04-26 10:34:32 <ncopa> 1541c46d28ed83b20cdafb1691599865a3883332 fixes it
2022-04-26 10:49:52 <tmhoang> Hi, what is ssl dev package as of today on 3.15 ? 
2022-04-26 10:50:23 <panekj> https://pkgs.alpinelinux.org/package/v3.15/main/x86_64/openssl-dev
2022-04-26 10:54:13 <skarnet> ncopa: another friendly reminder that alpine-conf is waiting for a version bump
2022-04-26 10:54:31 <ncopa> thank you scarlet for the reminder
2022-04-26 10:54:41 <ncopa> I have been doing firefighting today sorry
2022-04-26 10:54:52 <ncopa> nothing I have touched today or today seems to work
2022-04-26 10:54:59 <skarnet> pictures with a firefighter's helmet or it didn't happen
2022-04-26 10:55:34 <ncopa> not a helm but I ws not able to login to my workstation before 1541c46d28ed83b20cdafb1691599865a3883332
2022-04-26 10:56:16 <ncopa> skarnet: btw. last week I worked on a test suite for the installer and make some good progress
2022-04-26 10:56:28 <ncopa> which means it will hopefully be easier to get things merged in the future
2022-04-26 10:56:31 <skarnet> nice :D
2022-04-26 10:56:53 <skarnet> (and who would have thought dbus would cause problems 🤔)
2022-04-26 11:03:19 <omni> I had more things installed that depend on dbus than I thought
2022-04-26 11:21:20 <sdomi> mmm.. Installed alpine on another desktop machine just now and I've been bitten with /dev/input/* not being in the input group... again
2022-04-26 11:21:35 <sdomi> maybe we should make xorg-server depend on udev?
2022-04-26 11:21:57 <sdomi> and furthermore, maybe there should be a post-install message for udev about how to set up the services :P
2022-04-26 11:22:30 <ncopa> well, it is not really a hard dependency
2022-04-26 11:22:45 <ncopa> even if hotplugging will not work without udev
2022-04-26 11:23:32 <ncopa> i don't think we should enforce udev requirement unless it actually is a hard requirement
2022-04-26 11:25:28 <Ermine> setup-xorg-base enables udev
2022-04-26 11:42:15 <ncopa> which I think is fine
2022-04-26 11:42:56 <ncopa> you *can* theoretically set it up without udev, but then you have to do it manually
2022-04-26 11:43:01 <ncopa> and you are on your own
2022-04-26 12:11:25 <sdomi> ncopa: chowning them in an openrc service is kinda ugly ;p
2022-04-26 12:11:33 <sdomi> (even though I know that's literally what udev does)
2022-04-26 12:59:47 <skarnet> setting things up with or without udev would be easier if I could submit my aports MR, which requires an alpine-conf version bump first
2022-04-26 12:59:51 <skarnet> JUST SAYIN
2022-04-26 22:12:53 <omni> could the tests failing on a* be due to CI builder setup for those archs? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33661
2022-04-26 22:13:08 <omni> !33661
2022-04-26 22:13:24 <omni> (just a preparation for the upcoming release)
2022-04-27 02:17:02 <Hello71> omni: the sandbox doesn't work on arm musl because it doesn't allow openat/fchownat/etc
2022-04-27 02:17:37 <Hello71> hm, wait, that doesn't explain why fchownat works on glibc
2022-04-27 07:40:01 <omni> should I just disable those tests for a* archs?
2022-04-27 08:19:57 <ncopa> skarnet: just a reminder that I haven't forgot to tag alpine-conf release
2022-04-27 08:22:03 <ikke> smart
2022-04-27 08:24:28 <skarnet> excellent!
2022-04-27 08:39:46 <ncopa> what I'd like to do: create some way to inject the alpine-conf from git master into https://github.com/ncopa/alpine-installer-testsuite
2022-04-27 08:44:00 <skarnet> ... okay, but could you please address my simpler need, like, first?
2022-04-27 08:44:31 <skarnet> because I have no use for pytest or whatever installer testsuite you're working on
2022-04-27 08:44:52 <ikke> ncopa: curl -O https://gitlab.alpinelinux.org/alpine/alpine-conf/-/archive/master/alpine-conf-master.tar.gz | tar xzf -C alpine-conf?
2022-04-27 08:45:00 <ikke> ncopa: curl -O https://gitlab.alpinelinux.org/alpine/alpine-conf/-/archive/master/alpine-conf-master.tar.gz | tar xz -C alpine-conf
2022-04-27 08:45:56 <ncopa> skarnet: i want add a test for the mdevd stuff, to make sure that once it is introduced, we dont break it in the future
2022-04-27 08:46:15 <ncopa> i also want make sure it does not break other stuff
2022-04-27 08:46:21 <ncopa> thats why
2022-04-27 08:47:53 <ncopa> but ofc, i suppose I could just drop everything in my hands and address your simpler needs, like first, and dont bother if the alpine-conf release works or not beofer tagging it
2022-04-27 08:48:34 <skarnet> did you already forget what we talked about last time
2022-04-27 08:49:04 <skarnet> about tagging a version number for development, before the release
2022-04-27 08:49:27 <skarnet> so you have time to work on it and fix stuff before releasing it, but it's not preventing experimental stuff depending on the new version
2022-04-27 08:50:52 <ncopa> oh right, i though you wanted to create a new release
2022-04-27 08:51:57 <ncopa> done
2022-04-27 08:52:12 <skarnet> I understand your intent but what I'm hearing is "your two months old MR is going to be delayed for a further 6 months so I can put the automation in place first, and you'll be able to perform your tests after I have the boilerplate"
2022-04-27 08:52:14 <skarnet> ah, thanks
2022-04-27 08:52:36 <ncopa> sorry, i have just misunderstood all the way
2022-04-27 08:53:44 <skarnet> at some point a new release *will* be needed, so my aports MR can be merged without depending on an experimental version of alpine-conf
2022-04-27 08:53:56 <skarnet> but that's not the first priority
2022-04-27 09:23:05 <MY-R> https://bugs.gentoo.org/840942 that looks horrible
2022-04-27 09:24:24 <ikke> oof
2022-04-27 09:30:33 <MY-R> nothing nice since most of new laptops got battery "built-in" so to unbrick device need use screwdriver :\
2022-04-27 11:17:31 <kunkku> rnalrd: I'd like to discuss the reverting of my 2016 commit on rotating /var/log/messages by default
2022-04-27 11:18:40 <kunkku> the use case was to rotate busybox-generated logs with logrotate
2022-04-27 11:18:51 <kunkku> because busybox log rotation is lame
2022-04-27 13:03:18 <Hello71> omni: i'm 90% sure the sandbox is just broken on arm musl, but i haven't quite worked out why
2022-04-27 13:26:51 <Hello71> it's broken because they just used #ifdef __i386__ :/
2022-04-27 16:36:47 <omni> Hello71: aha, I'll try and look a bit more at it later, thanks!
2022-04-27 16:37:03 <Hello71> the whole sandbox stinks and should probably be disabled or removed
2022-04-27 20:09:07 <omni> I should've looked at this earlier, they released 0.4.7.7 today
2022-04-27 21:21:44 <omni> !33661
2022-04-27 21:23:16 <omni> I disabled a bunch of tests, might sit down someday with someone and find out what's up
2022-04-27 21:27:25 <psykose> meow
2022-04-27 21:29:51 <omni> <3
2022-04-27 21:31:03 <psykose> :3
2022-04-27 21:31:07 <psykose> cute kitty
2022-04-27 21:37:01 <psykose> omni: one more fun failing test for you :p
2022-04-27 21:39:21 <omni> yes, I saw...
2022-04-27 21:39:49 <omni> it's the one I enabled because it succeeded on the CI builder
2022-04-27 21:45:09 <omni> psykose: I don't need to bump it for that, do I? !33692
2022-04-27 21:45:18 <psykose> nope
2022-04-27 22:24:59 <Hello71> the sandbox is actually broken though
2022-04-27 22:25:13 <Hello71> arguably it was broken before 0.4.7
2022-04-27 22:25:27 <Hello71> but just disabling the tests is... not a good solution.
2022-04-27 22:25:46 <omni> of course not
2022-04-27 22:29:06 <omni> huh, thought I had an account at their gitlab, perhaps not
2022-04-28 03:50:05 <Asmadeus> Would appreciate if someone could look at !33511 before the 3.16 split -- libbpf maintainer approved it already but I don't know if there are freezing rules for moving to community (if I should split the MR or not) and I don't think he can push the merge button anyway
2022-04-28 04:15:34 <psykose> it looks fine to me but i am not so sure about what else just removing those headers from linux-headers might affect
2022-04-28 04:19:47 <Asmadeus> I'm not aware of any user of these that doesn't depend on libbpf
2022-04-28 04:20:07 <Asmadeus> (which doesn't mean they don't exist, but it's going to be difficult to check)
2022-04-28 04:21:13 <Asmadeus> From my quick tests apk doesn't just allow overwriting the files, so I'm not sure if there's any other way -- the old way just had the new headers in a place that wasn't used without patching all libbpf users, or they'd just use the old version, or they'd use both somehow and break... It's not a good place to be in
2022-04-28 04:26:10 <Asmadeus> hmm, iproute2 might, let me try rebuilding it without these headers...
2022-04-28 04:28:44 <Asmadeus> .. they also include their own copy of the kernel headers, and build with these, so don't care.
2022-04-28 04:37:58 <Asmadeus> bleh, found knot through debian codesearch and that one doesn't
2022-04-28 04:38:19 <Asmadeus> well, indirectly: In file included from knot/server/server.c:54:
2022-04-28 04:38:19 <Asmadeus> /usr/include/linux/filter.h:11:10: fatal error: linux/bpf_common.h: No such file or directory
2022-04-28 04:54:33 <Asmadeus> Either way, that means I can't just rip the headers out of linux-headers like drm did, hmm.. There are a couple of higher priority include paths that could theorically be used but I'm pretty sure packaging guidelines wouldn't allow that either... I -could- add libbpf source tar next to linux's in linux-headers and pick the headers from there? but that'll be annoying to keep in sync... Any bright 
2022-04-28 04:54:39 <Asmadeus> idea?
2022-04-28 04:56:07 <psykose> it's possible to split them to libbpf-headers specifically and depend on them in libbpf-dev but let things pull in only headers, and that shoulld fix the knot case
2022-04-28 04:56:22 <psykose> but it's still a bit dirty, any time anything fails someone has to know to add those, and we now have split packaging
2022-04-28 04:56:36 <psykose> alternatively, it's possible to not remove the kernel ones, and allow replaces= for the libbpf ones
2022-04-28 04:57:02 <Asmadeus> Oh, I didn't know about replaces=. Does that ensure libbpf's wins regardless of install order?
2022-04-28 04:57:13 <psykose> but this is not really the completely intended usecase for replaces= and i think there were some edge cases that were annoying.. like being unsure which version is actually there, or what has priority for them, or something, been a while
2022-04-28 04:57:14 <psykose> no idea
2022-04-28 04:57:33 <psykose> how do other distros do it? i imagine full linux-headers always conflicts with bpf-headers
2022-04-28 04:57:44 <psykose> in terms of bare 'location'
2022-04-28 05:03:21 <Asmadeus> debian seems to be using the kernel version only. My problem with pahole came from the fact that libbpf installs its version in a non-standard location for some reason, I don't quite remember why we do that (might not have involved me) but from the looks of it that was meant to fix bcc depending on something from the newer version included in libbpf
2022-04-28 05:04:05 <Asmadeus> for nixos, I've more or less made the same change as this (always install libbpf's header), but each dev package provides its own include directory so as long as priority is managed correctly there's no problem with that solution
2022-04-28 05:04:49 <Asmadeus> I'll try to just remove the libbpf headers being installed again and see if bcc still needs it, but this keeps breaking everytime we update libbpf or related tools...
2022-04-28 05:05:38 <Asmadeus> (will check replaces= first quickly, but if there's no priority it's not great; might as well install in a separate location and create symlinks in a post hook like busybox binaries...)
2022-04-28 05:07:20 <Asmadeus> (yeah, bcc on debian hasn't been updated after 0.22 unlike other tools, so I'll bet 0.24 won't build on it)
2022-04-28 05:08:38 <Asmadeus> oh, there's a 'replaces_priority':     The priority of the replaces. If multiple packages replace files of each other, then the package with the highest replaces_priority will win.
2022-04-28 05:15:12 <Asmadeus> This has the drawback that installing libbpf-dev then removing it will leave the file missing on the system (until apk fix/upgrade of linux-headers or reinstall of libbpf-dev), that's not great but aside of that it appears to work, and reinstalling linux-headers doesn't overwrite the file
2022-04-28 05:15:52 <psykose> yeah, and those edge cases are.. really annoying when they hit
2022-04-28 05:17:27 <Asmadeus> I can agree with that, even understanding why the file is missing is going to be a hurdle
2022-04-28 05:22:57 <Asmadeus> ... and, of course bcc still doesn't build with that version of linux-header's bpf.h, it's require v5.17's or higher unless there's another error below
2022-04-28 05:24:09 <Asmadeus> I guess I can upgrade linux-headers again for now, but it's annoying everytime there's an upgrade so I'd really like to find a solution... Something kludgy with symlinks and a post hook for linux-headers is overkill but certainly tempting :D
2022-04-28 05:27:23 <psykose> ah, i suppose i should bump linux-headers
2022-04-28 05:28:24 <Asmadeus> Well, that'd work for now, yes. But libbpf 0.7.0 was released with headers that hadn't even been merged upstream yet (they were in the bpf -next tree!), so it's a lost battle
2022-04-28 05:28:33 <Asmadeus> Do you want me to open a MR for it?
2022-04-28 05:28:55 <psykose> yeah, it's a lost battle indeed..
2022-04-28 05:29:20 <psykose> or, maybe we should only bump headers after freeze
2022-04-28 05:29:23 <psykose> i guess i'll wait for that
2022-04-28 05:29:55 <Asmadeus> I wanted this before the freeze because I won't be able to use pahole on 3.16 without it
2022-04-28 05:30:21 <psykose> makes sense
2022-04-28 05:30:43 <psykose> sadly i can't think of an easy fix for it that doesn't involve butchering the headers longterm
2022-04-28 05:31:03 <psykose> so i guess ncopa would need to give an opinion, and well, you know how that goes
2022-04-28 05:31:27 <Asmadeus> Yeah, split package is probably the best, but that'll take time and it involves touching a lot of packages, that'd definitely for after the 3.16 has been branched off
2022-04-28 05:31:35 <Asmadeus> +be
2022-04-28 05:33:22 <Asmadeus> If it's unreasonable to bump linux-headers before the freeze I guess I can look for another workaround for my usecase... pahole seems to mostly just be confused about the location our libbpf currently picked to install its header, so changing that + bcc's patch might be enough short term
2022-04-28 05:35:18 <psykose> bumping is only bad because it may or may not break the build of some package (and so many things use linux-headers)
2022-04-28 05:35:40 <psykose> and since we already have all of 3.16 built, it would be invisible until maybe something is bumped in the future, or someone else tries to build something
2022-04-28 05:35:43 <Asmadeus> yes, I agree it's not an ideal time when we're trying to stabilize the tree
2022-04-28 05:35:55 <psykose> same reason we won't bump to gcc 11.3 anymore until freeze
2022-04-28 05:36:13 <psykose> and why i won't get llvm14 in anymore either, etc
2022-04-28 05:36:24 <psykose> (though that was only late because of wasi-libcxx, hehe)
2022-04-28 05:37:15 <Asmadeus> I'll just try to move where libbpf does its mess right now and see if that unstucks pahole. right now it just doesn't build, so it'll be even more of a pain to just wait it off...
2022-04-28 05:37:52 <psykose> if you can figure out some local fixes those would be fine, though not sure how hacky/painful they are
2022-04-28 05:37:57 <psykose> and then we should really fix this properly after
2022-04-28 05:38:07 <Asmadeus> yes! thanks :)
2022-04-28 05:38:38 <psykose> (admittedly it should have been fixed by now given how long its been, but you know how it goes..)
2022-04-28 05:44:41 <Asmadeus> looks like moving where libbpf installs things and setting CFLAGS/CXXFLAGS is good enough, I'll update/undraft my MR as soon as I've tested the built packages
2022-04-28 06:02:19 <Asmadeus> psykose: !33511 updated, builds ok, and tested locally :)
2022-04-28 06:03:52 <psykose> good work :)
2022-04-28 06:04:48 <Asmadeus> thanks for the help!
2022-04-28 06:47:33 <ncopa> morning
2022-04-28 06:47:43 <ncopa> i think we effectively are in a freeze now
2022-04-28 06:48:28 <ncopa> we should look over the issues and try fix as many as possible of them now https://gitlab.alpinelinux.org/alpine/aports/-/issues
2022-04-28 06:48:59 <ncopa> and maybe do some sort of triage
2022-04-28 07:42:50 <omni> I upgraded a couple of DomUs yesterday from 3.15 to edge without issues, not too many packages installed but still
2022-04-28 07:55:29 <ncopa> omni: very nice. thanks
2022-04-28 08:07:44 <ncopa> i think we should do release candidates next week
2022-04-28 08:08:06 <ncopa> i will try work on the testsuite a bit, so we can properly test the release candidates
2022-04-28 09:36:58 <omni> ncopa: linux-rpi related that seem reasonable: !20738 !24236
2022-04-28 09:37:03 <omni> plus a kernel version bump
2022-04-28 09:38:25 <omni> issue related to the first one #12425
2022-04-28 13:28:51 <ddevault> hrmph
2022-04-28 13:28:59 <ddevault> so I found out why hare fails on alpine riscv64
2022-04-28 13:29:11 <ddevault> qemu-user does not support the execveat syscall
2022-04-28 13:29:19 <ddevault> it works fine on real hardware
2022-04-28 13:29:24 <ddevault> or on a full-blown emulator
2022-04-28 13:32:37 <ikke> I had a suspicion it had to do with qemu-user
2022-04-28 13:33:18 <ddevault> https://gitlab.com/qemu-project/qemu/-/issues/1007
2022-04-28 13:33:45 <ddevault> I did fix the non-deterministic build failures on harec, though, sending up a patch
2022-04-28 13:40:05 <ddevault> it's a good thing I decided to troubleshoot this issue in qemu-user instead of firing up some hardware or reproing it would have driven me up the wall
2022-04-28 13:41:21 <ikke> haha, yeah, could imagine
2022-04-28 13:41:48 <ikke> So if we would use qemu-system, this would also have worked?
2022-04-28 13:41:56 <ddevault> yes
2022-04-28 13:42:15 <ddevault> well, presumably. It would run the real linux kernel instead of a shim
2022-04-28 13:42:18 <ddevault> did not actually test it
2022-04-28 13:42:22 <ikke> ok
2022-04-28 13:49:53 <Hello71> if you're just using execveat for running an fd why don't you use /proc/self/fd? are you not calling libc fexecve?
2022-04-28 13:50:06 <ddevault> hare does not link to libc
2022-04-28 13:50:23 <ddevault> and we use the syscall because it's been there for years and works fine
2022-04-28 13:50:27 <ddevault> qemu should implement this
2022-04-28 19:25:32 <Hello71> i think musl's policy of trying to support older kernels when possible is a good one. i don't see any reason why qemu shouldn't implement execveat though
2022-04-28 19:26:02 <Hello71> additionally if hare implements /proc/self/fd fallback then it will also work on older qemu
2022-04-28 19:27:12 <Hello71> "06:48 <@ncopa> we should look over the issues and try fix as many as possible of them now https://gitlab.alpinelinux.org/alpine/aports/-/issues" i've worked on this for some time, but unfortunately the new issues keep coming. if we turn off the issues it would be much easier
2022-04-28 19:27:36 <ikke> Hello71: those pesky users :)
2022-04-28 19:27:37 <Hello71> actually that's basically the policy of many projects, just close issues after 30 days and pretend they don't exist anymore
2022-04-28 19:28:34 <panekj> would be great
2022-04-28 19:29:31 <ikke> Ostrich policy
2022-04-28 19:38:23 <Misthios> out of sight out of mind
2022-04-28 19:40:03 <sam_> i hate stalebot
2022-04-28 19:40:08 <sam_> truly hate
2022-04-28 20:04:36 <craftyguy> I find the reminders helpful
2022-04-28 20:05:08 <ikke> Yes, we don't automatically close MRs (and should not in my opinion), but other projects automatically close issues after 30 days
2022-04-28 20:05:44 <panekj>  reminders are okay in short periods, but if something has been opened for half a year, don't really expect it to be fixed
2022-04-28 20:05:50 <craftyguy> and issues. that's a serious pet peeve of mine... bots that autoclose issues (and now on github some even lock the issue to it can't be opened/commented on)
2022-04-28 20:06:27 <panekj> I (truly) hate people commenting on old issues
2022-04-28 20:07:02 <ikke> I don't if it's relevant
2022-04-28 20:07:12 <craftyguy> I mean, context definitely matters. sometimes issues are very intermittent and there are long gaps between when new info is available
2022-04-28 20:07:25 <craftyguy> or people are busy, priorities different, and so on
2022-04-28 20:43:40 <orbea> 
ACTION agrees with above, better to have occasional pointless comments on old issues than prevent relevent info being added to old issues

2022-04-28 21:59:42 <panekj> what could be wrong with (d)abuild if it exits cleanly without building?
2022-04-28 22:02:53 <panekj> last line: 53: exec /usr/bin/abuild -r
2022-04-28 22:05:24 <craftyguy> IIRC seeing something like that when apk was unhappy, like I needed to run apk fix first, or the db was corrupt. something like that
2022-04-28 22:06:00 <panekj> apk says it's "OK"
2022-04-28 22:15:46 <panekj> guess rootbld works for now, is there a way to make meta package as subpackage?
2022-04-28 23:05:14 <eddsalkield> would someone be able to explain to me how the docs metapackage works?
2022-04-28 23:05:36 <ptrc> all the -doc packages have "install_if=docs" set
2022-04-28 23:05:56 <ptrc> so they get automatically pulled in when someone has the metapackage installed
2022-04-28 23:06:20 <eddsalkield> and this is something that abuild adds automatically? i haven't seen it in the APKBUILDs anywhere
2022-04-28 23:06:33 <eddsalkield> a while ago i made a short list of two *-doc packages that weren't pulled in, wondering how to check if they're fixed
2022-04-28 23:06:47 <eddsalkield> or contribute a patch
2022-04-28 23:07:24 <ptrc> yeah, it's in default_doc function in abuild
2022-04-28 23:08:10 <ptrc> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/d9f03b38/abuild.in#L1854
2022-04-28 23:08:34 <ptrc> do you still have the list somewhere?
2022-04-28 23:09:42 <eddsalkield> yeah it was doas-doc and openssh-doc
2022-04-28 23:10:53 <ptrc> hm, seems to work for me on edge
2022-04-28 23:11:09 <eddsalkield> this was a number of months ago in fairness
2022-04-28 23:11:53 <eddsalkield> how did you check that it was working? i could set up a clean image and install, but that sounds like a faff
2022-04-28 23:12:16 <ptrc> `docker run --rm -it alpine:edge`
2022-04-28 23:12:33 <ptrc> and just did `apk add docs doas openssh`
2022-04-28 23:13:17 <eddsalkield> yep that's working for me as well
2022-04-28 23:14:01 <eddsalkield> thanks for your help!
2022-04-28 23:14:11 <ptrc> you're welcome :)
2022-04-29 03:11:07 <psykose> ikke: do you have some hard numbers on just how much slower qemu-system would be for riscv?
2022-04-29 03:11:38 <psykose> if it's like 50%.. then eh, it's doable.. and would fix a lot of the stray issues i think
2022-04-29 03:55:47 <ikke> I don't 
2022-04-29 04:01:23 <ikke> But something we could probably test 
2022-04-29 04:03:01 <psykose> could time a kernel build
2022-04-29 04:03:25 <psykose> also qemu-system would need reserved memory as a full vm on whatever machine it's on, but i think this was basically intended already
2022-04-29 04:04:21 <psykose> i think being even slower than it already is would be less annoying than these random -user issues, correctness before performance, etc etc
2022-04-29 05:19:09 <ikke> ncopa: anything against moving pure-ftpd to community? (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31877)
2022-04-29 05:28:34 <ncopa> ikke: no objection
2022-04-29 06:47:43 <craftyguy> lol 10 years in testing
2022-04-29 06:47:55 <craftyguy> that's one well tested package :D
2022-04-29 07:14:23 <Misthios> damn
2022-04-29 08:26:31 <ikke> FYI, the s390x CI host will be down for a bit today, so CI jobs for those can hang / timeout
2022-04-29 08:42:53 <ncopa> 👍
2022-04-29 09:44:27 <ncopa> we have a "problem" with linux-firmware
2022-04-29 09:44:38 <ncopa> its almost a gig in size
2022-04-29 09:45:24 <ncopa> a clean install of alpine from edge is 929MB
2022-04-29 09:45:49 <ncopa> firwmare is 833MB
2022-04-29 09:46:11 <ikke> Yeah, it installs every firmware there is, whether you need it or not
2022-04-29 09:50:40 <Ermine> Afaik newer kernels support firmware compressuion
2022-04-29 09:50:54 <Ermine> s/compressuion/compression
2022-04-29 09:50:54 <alpine-meetbot> Ermine meant to say: Afaik newer kernels support firmware compression
2022-04-29 09:55:40 <ncopa> i still think its insane
2022-04-29 10:22:28 <skarnet> that's how linux-firmware is shipped, that can be changed but would require heavy repackaging
2022-04-29 10:23:02 <skarnet> splitting the firmware by... vendor? functionality? something else?
2022-04-29 10:23:22 <ikke> The firmware is alreayd packaged as individual packages
2022-04-29 10:23:56 <panekj> it's just a bit chonky
2022-04-29 10:24:17 <skarnet> how come it takes 833 MB if it's already split?
2022-04-29 10:24:33 <ikke> Because linux-lts pulls them all in through linux-firmware-any
2022-04-29 10:24:33 <panekj> linux-firmware is meta package for all linux-firmware-*
2022-04-29 10:25:12 <skarnet> ah yes... split packages but all of them are pulled... yay.
2022-04-29 10:25:23 <panekj> you can pull them separately if you want
2022-04-29 10:25:36 <skarnet> it's not about what I want
2022-04-29 10:26:03 <ikke> if you install linux-firmware-none, you won't get any of them
2022-04-29 10:26:25 <psykose> if you install a single one you will also get only the single one
2022-04-29 10:26:47 <skarnet> and if you install two of them you will get two of them!
2022-04-29 10:26:55 <psykose> yes, and so it's fine
2022-04-29 10:27:00 <skarnet> we're brilliant today, aren't we
2022-04-29 10:27:22 <psykose> the downside of default-all is some people used some diskspace
2022-04-29 10:27:49 <psykose> the downside of default-literally-nothing is a bunch of people suddenly having zero networking and not knowing which of linux-firmware-fuck they need
2022-04-29 10:27:58 <psykose> in some cases the firmware loader does not even tell you
2022-04-29 10:28:45 <psykose> we /could/ have an -extra that is never pulled except explicitly (not with -any), that has some of those huge near-useless ones that nobody uses for sure for industrial stuff
2022-04-29 10:28:46 <psykose> i guess
2022-04-29 10:28:58 <psykose> but aside from that people are free to optimise their own firmware space, if they care
2022-04-29 10:29:44 <panekj> or script to find which modules to load and pull respecting firmware
2022-04-29 10:31:28 <ikke> There was some snippet to find out what firmware was being used
2022-04-29 10:34:24 <ikke> skarnet: you misconstrue what we are trying to tell. Right now, the default is install-everything, but without changing the firmware pacakging, it's already possible to select exactly what you need. The only peace missing is something that will automatically select those
2022-04-29 10:37:16 <skarnet> I'm not misconstruing anything and you people are exhausting
2022-04-29 10:37:45 <ikke> skarnet: "we're brilliant today, aren't we"
2022-04-29 10:38:04 <skarnet> yes, psykose was already being condescending
2022-04-29 10:38:11 <skarnet> I don't take to condescension lightly
2022-04-29 10:38:22 <psykose> what?
2022-04-29 10:38:25 <panekj> wher
2022-04-29 10:38:28 <skarnet> especially when I'm trying to think of a problem that ncopa raised
2022-04-29 10:38:30 <panekj> s/wher/where
2022-04-29 10:38:30 <alpine-meetbot> panekj meant to say: where
2022-04-29 10:39:03 <skarnet> s/of/about
2022-04-29 10:39:03 <alpine-meetbot> skarnet meant to say: especially when I'm trying to think about a problem that ncopa raised
2022-04-29 10:39:09 <psykose> ..where was i being condescending?
2022-04-29 10:39:23 <skarnet> <psykose> if you install a single one you will also get only the single one
2022-04-29 10:39:29 <skarnet> ... duh?
2022-04-29 10:39:40 <psykose> no, the default is all of them
2022-04-29 10:39:47 <skarnet> ...
2022-04-29 10:39:49 <psykose> and the moment you add linux-firmware-mydevice it removes everything
2022-04-29 10:39:54 <psykose> except for the single thing you added
2022-04-29 10:39:56 <psykose> this is not obvious
2022-04-29 10:40:03 <skarnet> it was to me?
2022-04-29 10:40:09 <psykose> and has broken things for multiple people
2022-04-29 10:40:32 <skarnet> okay, let's start over
2022-04-29 10:40:42 <skarnet> ncopa said the default installation size was a problem
2022-04-29 10:40:51 <psykose> i'm glad it was obvious! but as you know, one can't assume over text, so i thought to clarify
2022-04-29 10:41:04 <skarnet> the linux-firmware package is already split, but by default everything is pulled
2022-04-29 10:41:07 <psykose> my apologies if this obvious knowledge came off as condescending
2022-04-29 10:41:39 <ikke> skarnet: yes, correct, that's the state as of now
2022-04-29 10:41:45 <skarnet> people are not happy with the way the metapackage gets replaced with a single package when they manually choose one <-- this is an unrelated problem, which I'm not trying to address here
2022-04-29 10:42:27 <skarnet> the question I thought everyone had in mind is: *how* can we make it so the default install size is smaller?
2022-04-29 10:42:46 <ikke> "The only peace missing is something that will automatically select those"
2022-04-29 10:43:09 <skarnet> is it possible to automatically detect what firmware is needed?
2022-04-29 10:43:23 <ikke> I've seen a snippet (I think lsmod based) that does that
2022-04-29 10:44:02 <skarnet> hmmm
2022-04-29 10:44:46 <Newbyte> one issue with that is removable devices
2022-04-29 10:45:24 <panekj> it can be solved with change log and a proper note in docs
2022-04-29 10:45:37 <panekj> also post-install message
2022-04-29 10:48:22 <panekj> or maybe `setup-firmware`?
2022-04-29 10:48:35 <Newbyte> setup-firmwaree is an interesting idea
2022-04-29 10:50:05 <omni> how about default only install network firmware packages?
2022-04-29 10:51:05 <ptrc> pretty sure some users might appreciate stuff like amdgpu/nvidia too
2022-04-29 10:51:05 <skarnet> and then you can't boot on your proprietary disk :/
2022-04-29 10:51:23 <ikke> And the firmware is not split-up that way
2022-04-29 10:51:54 <ikke> It's per vendor (chipset)
2022-04-29 10:52:21 <omni> no, it would require a new meta-package, just thought that would be one way to not be locked out of network from start without having to ship with all firmwares
2022-04-29 10:52:42 <panekj> I think it's better to make it an option during setup, so we can retain previous behaviour and give option for barebone install
2022-04-29 10:52:54 <omni> sure
2022-04-29 10:52:55 <ikke> I think we don't want users having to figure out what exact firmware package to install to get their things working if not necessary
2022-04-29 10:53:05 <omni> something automagic would be nice
2022-04-29 11:18:15 <ikke> modinfo $(lsmod | grep -v Module | awk -e '{ print $1}') | grep firmware
2022-04-29 11:18:40 <ikke> that lists the firmware that is actually used
2022-04-29 11:20:02 <panekj> mhm, are all blobs loaded into system no matter if they are actually used or not?
2022-04-29 11:21:13 <ikke> no
2022-04-29 11:21:29 <ikke> the firmware packages just contains the blobs, but does not load them, the kernel does that
2022-04-29 12:16:29 <psykose> ah, neat, i was actually missing one/two
2022-04-29 12:16:35 <psykose> also it should be grep ^firmware
2022-04-29 12:16:58 <psykose> parm:           fw_load_type:firmware loading type (0 = force direct if supported, -1 = auto) (int)
2022-04-29 12:16:58 <psykose> :p
2022-04-29 12:28:03 <Hello71> modinfo -F firmware $(awk '{print $1}' /proc/modules)
2022-04-29 12:39:56 <ikke> even shorter
2022-04-29 13:09:32 <Saijin_Naib> To ikke and psykose's points, it took me a long while to figure out how the linux-firmware-X situation worked when I was fresh with Alpine and I locked myself out of fixing it on a few installs by missing required network adapter firmware and restarting the install out of frustration
2022-04-29 13:33:06 <Ermine> I have insane idea of writing interactive disk partitioning script for alpine-conf
2022-04-29 13:48:00 <skarnet> from what ncopa told me recently, I think the goal of alpine-conf is to *minimize* interactivity, only ask effort from the user when it's strictly necessary.
2022-04-29 13:50:36 <panekj> I heard there was some TUI installer in progress (separate from alpine-conf)
2022-04-29 13:51:56 <ikke> skarnet: meaning, it has sane defaults that users can choose if they don't care. But that does not mean it cannot offer options to customize if you need.
2022-04-29 13:52:35 <skarnet> ikke: of course, but that's not what interactivity means
2022-04-29 13:52:50 <minimal> couldn't e.g. the setup-disk auto-select a subset of linux-firmware packages based on using modinfo to get firmware requirements and cross-referencing those with the linux-firmware-X packages
2022-04-29 13:57:38 <panekj> and what if it doesn't load
2022-04-29 13:57:44 <minimal> perhaps even create a linux-firmware-index subpackage containing something like just a simple textfile mapping module names to linux-firmware subpackage that any script could simply grep/awk?
2022-04-29 13:58:23 <minimal> panekj: not saying it would solve the issue for all modules, but a partial solution is better than no solution, right?
2022-04-29 13:59:51 <panekj> then I would prefer to have `setup-firmware` with options: all (default), detect, none, <list of modules>
2022-04-29 14:03:06 <minimal> basically autodetection makes sense if the user is installing specifically for *that* machine whereas some installs (i.e. on USB sticks) may be intended to be used on multiple machines with different HW
2022-04-29 14:08:29 <mercenary> Wasn't the original point the size of the install image, not which ones were going to be installed from that?
2022-04-29 14:08:59 <ikke> mercenary: the amount of diskspace used after installation
2022-04-29 14:09:24 <panekj> extended image is for machines without internet
2022-04-29 14:16:31 <Hello71> well, one problem is that currently overlayfs modloop is not enabled by default, so you cannot add firmware even if you have internet access
2022-04-29 14:17:03 <minimal> so I guess it comes down to whether the installer should option "tailored" vs ""generic" installation, and whether "tailored" is then subdivided into "just for this machine" or more generic hardware-class options "Uses WiFi/doesn't use WiFi", "Uses AMD or Intel CPUs", etc
2022-04-29 14:40:16 <ikke> FYI, I've now removed the custom seccomp profile for the s390x ci runner, as it has an up-to-date kernel now
2022-04-29 14:40:22 <ikke> let me know if you see any issues
2022-04-29 14:44:09 <omni> the x86 CI builder seem to get stuck after LD [M]  virt/lib/irqbypass.ko !33751
2022-04-29 14:44:33 <omni> tried to restart it once and it got stuck at the same place
2022-04-29 14:47:16 <omni> perhaps it's just insn_decoder_test that takes a lot of time and I've been impatient
2022-04-29 15:18:08 <omni> ah, yes, heh...
2022-04-29 15:18:43 <psykose> meow
2022-04-29 15:22:16 <omni> ERROR: Job failed: execution took longer than 2h0m0s seconds
2022-04-29 15:22:26 <omni> perhaps it's the wrong time of day to try to run it
2022-04-29 15:22:43 <Hello71> you can probably backport the mawk change
2022-04-29 15:24:38 <omni> 553da92690e7c6406f8f536b4ddbe3b9859d1642 ?
2022-04-29 15:25:13 <Hello71> yes but you also have to add mawk to makedepends
2022-04-29 15:25:47 <Hello71> it is only used for compile time test, so i think risk of regressions is negligible
2022-04-29 15:25:47 <omni> sure, I could do that...
2022-04-29 15:25:51 <Hello71> ah, but wait, mawk isn't in main in 3.12
2022-04-29 15:26:01 <omni> then I won't! :D
2022-04-29 15:26:07 <Hello71> you caould add gawk to makedepends
2022-04-29 15:26:13 <Hello71> s/a//
2022-04-29 15:26:13 <alpine-meetbot> Hello71 meant to say: you could add gawk to makedepends
2022-04-29 15:26:41 <omni> is it really necessary though?
2022-04-29 15:26:49 <omni> v3.12 is EoL on sunday
2022-04-29 15:26:51 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?label_name=v3.12
2022-04-29 15:27:00 <ikke> Officially when 3.16 is out
2022-04-29 15:27:55 <omni> aha, I thought officially was this https://alpinelinux.org/releases/ ;)
2022-04-29 15:28:18 <ikke> yes, we set a date to manage expectations
2022-04-29 15:28:26 <psykose> regardless of which i don't get what the point of using either metric is if 'one week before' becomes the real one :p
2022-04-29 15:30:24 <omni> I need to leave the keyboard for a while, so I wont do any thing now but feel free to adjust or merge my MR as you see fit
2022-04-29 15:31:15 <omni> I wish it was possible for us mortal contributors to push MRs for linux-rpi as well, that seem to lag often
2022-04-29 17:02:44 <Hello71> ah, it doesn't work on glibc either: https://gitlab.torproject.org/tpo/core/tor/-/issues/40599
2022-04-30 04:08:49 <craftyguy> apk on edge/x86_64: OK: 21999 distinct packages available
2022-04-30 04:08:58 <craftyguy> who's going to package #22000??
2022-04-30 07:31:05 <smcavoy> I am working one one now :)
2022-04-30 07:37:23 <ikke> Too late: 06:40:55           │ │ alpine/aports:master | Thomas Liske | testing/py3-apds9960: new aport | http://dup.pw/alpine/aports/7c8ebdec167e :)
2022-04-30 08:21:45 <smcavoy> :(
2022-04-30 08:37:12 <Misthios> Ripp
2022-04-30 08:37:21 <Misthios> U get it next time :)
2022-04-30 08:38:18 <psykose> just add 8k more and get to 30k :)
2022-04-30 08:39:16 <psykose> though i'm not exactly sure how to even find that number..
2022-04-30 08:39:17 <psykose> https://img.ayaya.dev/1zNRKbY4lhre
2022-04-30 09:19:19 <smcavoy> so 22000 had already happened.....  >:|
2022-04-30 10:13:22 <liske> #22222 isn't that far away ;-)
2022-04-30 11:35:39 <psykose> ikke: as always since i keep forgetting.. where exactly is the option to let people push things to a branch so it can be rebased... !33789
2022-04-30 11:35:47 <psykose> i sure love going over this a dozen times
2022-04-30 11:36:23 <ikke> psykose: the project is still internal
2022-04-30 11:36:34 <psykose> aren't most forks
2022-04-30 11:36:57 <ikke> No
2022-04-30 11:37:07 <ikke> But good news: https://gitlab.com/gitlab-org/gitlab/-/issues/211714
2022-04-30 11:37:35 <psykose> i guess.. maybe 14.9?
2022-04-30 11:37:45 <psykose> or 15
2022-04-30 11:38:01 <ikke> 14.10 is alreayd released
2022-04-30 11:38:04 <psykose> ah
2022-04-30 11:38:09 <psykose> is it fixed in that, or
2022-04-30 11:38:22 <ikke> No, I suspect the next release
2022-04-30 11:38:30 <ikke> either 14.11 or 15.0
2022-04-30 11:38:32 <psykose> i hope
2022-04-30 11:38:53 <ikke> every hour a job runs to make internal projects public atm
2022-04-30 11:39:09 <psykose> so, i will check again in 22 minutes..
2022-04-30 11:39:18 <psykose> and somehow i completely forgot what i was actually doing
2022-04-30 11:39:59 <ikke> Welcome to my life
2022-04-30 11:40:42 <psykose> happens all the time :) i love to fight my own head to do things
2022-04-30 11:40:52 <ikke> psykose: for the record, that option has been set, it's just because the project is internal, you are still not allowed to do it
2022-04-30 11:41:14 <ikke> so recognizable :)
2022-04-30 11:48:22 <omni> git push/pull is still very slow over IPv6
2022-04-30 11:51:20 <psykose> hm
2022-04-30 11:51:58 <psykose> i was about to say i was going to test it again, but i realise i don't have ipv6
2022-04-30 11:52:33 <omni> you can always use tor :D
2022-04-30 11:53:14 <psykose> i can test it from some other machines.. but efffooooorrrrtttt...
2022-04-30 11:54:15 <omni> it's no biggie, I can use -4 if I don't like to wait, just thought you'd want to know
2022-04-30 11:54:57 <omni> it's like it just sits there until it times out, but that's just me guessing
2022-04-30 11:56:08 <psykose> most likely
2022-04-30 11:59:12 <omni> now I've configured AddressFamily inet so I can forget about it again
2022-04-30 12:19:51 <ikke> Not sure why ipv6 would be slower
2022-04-30 12:24:39 <omni> a lot of python packages include tests, I guess that is unintended?
2022-04-30 12:26:02 <omni> I mean, they're only interesting for check() during build
2022-04-30 12:27:22 <ikke> You mean in the package?
2022-04-30 12:33:00 <omni> yes, like py3-websocket-client, for example, that we ship with /usr/lib/python3.10/site-packages/websocket/tests/
2022-04-30 12:34:22 <omni> I guess the worst offender is mycli !33790
2022-04-30 12:34:46 <psykose> unintended indeed
2022-04-30 12:58:19 <Ermine> Can I specify more than one license in APKBUILD
2022-04-30 12:58:45 <ikke> yes
2022-04-30 12:58:59 <ikke> separated by AND and/or OR
2022-04-30 12:59:08 <psykose> and ( ) 
2022-04-30 12:59:14 <psykose> and per subpackage
2022-04-30 12:59:49 <psykose> there's too many licences tbh
2022-04-30 13:00:25 <panekj> just make everything ISC or MPL
2022-04-30 13:04:37 <Ermine> thank you
2022-04-30 13:06:49 <psykose> there's too many thank you's tbh
2022-04-30 13:07:16 <panekj> there's not enough psykose's tbh
2022-04-30 13:07:22 <psykose> isn't there
2022-04-30 13:07:33 <psykose> d-did the store run out
2022-04-30 13:07:52 <panekj> need to find out manufacturer
2022-04-30 13:07:58 <panekj> to make more
2022-04-30 13:08:04 <psykose> oh god
2022-04-30 13:10:25 <panekj> is it ok to update to 3.16 now?
2022-04-30 13:10:41 <psykose> it's just edge
2022-04-30 13:11:40 <panekj> i mean 3.16
2022-04-30 13:12:00 <psykose> yes, 3.16 is edge
2022-04-30 13:12:10 <psykose> if you put 3.16 in repos it will just be edge/main edge/community
2022-04-30 13:12:14 <psykose> it's not split yet
2022-04-30 13:12:23 <panekj> grr
2022-04-30 13:22:54 <Ermine> psykose: there's too many thank you's tbh <-- there's never enough politeness imo
2022-04-30 13:23:07 <psykose> indeed :)
2022-04-30 13:24:24 <omni> just make everything PD, yarr
2022-04-30 13:24:35 <psykose> PD?
2022-04-30 13:25:01 <omni> public domain
2022-04-30 13:26:51 <psykose> ah
2022-04-30 13:27:06 <psykose> a-are you public domain?
2022-04-30 13:29:57 <omni> idk
2022-04-30 13:30:53 <omni> there are quite a few python aports that aren't rebuilt for python 3.10 yet, aren't there?
2022-04-30 13:58:37 <ikke> mostly things in testing
2022-04-30 13:59:06 <ikke> and  llvm11-test-utils in main apparently
2022-04-30 14:15:06 <eddsalkield> sorry if it's already been discussed, but is it possible to blacklist domains @alice.it from the alpine-aports mailing list?
2022-04-30 14:15:13 <eddsalkield> we've been receiving some spam recently
2022-04-30 15:01:20 <psykose> i don't see that address on alpine-aports or the other ones
2022-04-30 15:02:24 <psykose> ah, i do now
2022-04-30 19:29:34 <omni> ikke: what about https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fpython3.9%2F*&name=&branch=edge&repo=main ?
2022-04-30 19:30:03 <omni> oh, perhaps they were disabled for s390x?
2022-04-30 19:30:15 <ikke> mayhaps
2022-04-30 19:31:57 <anjan> Hi all, this MR should be ready to go: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28671
2022-04-30 19:32:20 <ikke> anjan: taking a look
2022-04-30 19:34:57 <anjan> thank you ikke