2023-04-01 02:43:44 <psykose> who on earth added this lmao https://release-monitoring.org/project/324014/
2023-04-01 17:19:03 <phoenix> hello
2023-04-02 09:47:01 <nmeum> does someone have an idea why build-ppc64le is the only runner which is not able to fetch the tarball in !45002 ?
2023-04-02 09:47:17 <nmeum> > curl: (22) The requested URL returned error: 404
2023-04-02 10:02:11 <ddevault> that URL 404's for me locally
2023-04-02 10:02:15 <ddevault> maybe it's cached on the other builders?
2023-04-02 10:13:22 <nmeum> wild, it definitly works for me
2023-04-02 10:14:12 <nmeum> download.savannah.nongnu.org does seem to redirect to a mirror though, so maybe it does sometimes redirect to a mirror which doesn't have the file
2023-04-02 10:16:51 <nmeum> I will just hardcode the de.freedif.org mirror for now, because that mirror definitly has the file
2023-04-02 12:22:37 <donoban> tests/test_pam_rules.py::test_pam_config[util-linux-login-edge] PASSED                                     [100%]
2023-04-02 12:22:54 <donoban> that's a first step :D
2023-04-02 12:43:49 <donoban> well, the tests is currently don't testing pretty much but it looks promising https://tpaste.us/gggv
2023-04-02 16:57:29 <sam_-> psykose: https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/mawk?id=fc6cf843090ce7fd17930a2d4b3a025875129ec3
2023-04-02 17:07:22 <psykose> yeah it's just a classic eh
2023-04-02 17:25:40 <donoban> psykose: I felt that using VM whats painkiller for it so I switch to a docker based solution https://tpaste.us/ePP5
2023-04-02 17:26:56 <sam_-> yes dickey is special
2023-04-02 17:27:03 <donoban> I have to add many login/password change/account locking/... and the CVE-2019-5021 case
2023-04-02 17:33:05 <donoban> s/painkiller/painful :D
2023-04-02 19:12:13 <Newbyte> >>> Size difference for squeekboard: 21 MiB -> 12 MiB (https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/1002942#L1244)
2023-04-02 19:12:25 <Newbyte> did something change with regards to Rust on armv7?
2023-04-02 19:12:38 <Newbyte> oh, could it be thumb2?
2023-04-02 19:13:06 <psykose> could be
2023-04-02 19:13:29 <psykose> you can rebuild it with some RUSTFLAGS thing and see if it goes back to 21
2023-04-02 19:15:34 <Newbyte> meh
2023-04-02 19:15:51 <Newbyte> not worth the effort given that it works fine
2023-04-02 19:16:03 <Newbyte> but thank you for the suggestion
2023-04-02 20:05:15 <bl4ckb0ne> ty for handling the khronos bump psykose 
2023-04-02 20:05:28 <bl4ckb0ne> didnt get a notification, did you pushed it directly?
2023-04-02 20:05:43 <psykose> yeah
2023-04-02 20:05:52 <psykose> nothing interesting this time
2023-04-02 20:09:39 <bl4ckb0ne> fair enough
2023-04-02 20:37:29 <skarnet> #45640 whenever is convenient :)
2023-04-02 20:38:06 <skarnet> have I forgotten everything? is it !45640 ?
2023-04-02 20:38:09 <skarnet> yes it is
2023-04-03 11:49:11 <Hello71> about !45644, i thought we don't do virtual packages for optional dependencies
2023-04-03 11:50:09 <psykose> people find literally anything to complain about eh
2023-04-03 13:33:40 <skarnet> it wouldn't be FOSS otherwise!
2023-04-03 14:08:38 <donoban> could I disable CI temporary for a MR?
2023-04-03 14:19:18 <ikke> donoban: you could remove the jobs in the .gitlab-ci.yaml
2023-04-03 14:19:38 <ikke> Make sure it does not get merged though
2023-04-03 15:18:57 <ovf> donoban: https://docs.gitlab.com/ee/user/project/push_options.html ?
2023-04-03 15:19:31 <ikke> ovf: Not sure if that was fixed already, but skip_ci was not supported for merge request pipelines
2023-04-03 15:20:09 <ovf> ikke: you are right, sorry: > Only skips branch pipelines and not merge request pipelines.
2023-04-03 15:23:47 <donoban> uhM
2023-04-03 15:26:07 <donoban> Author: donoban <donoban@riseup.net>
2023-04-03 15:26:09 <donoban> Date:   Mon Apr 3 17:25:30 2023 +0200
2023-04-03 15:26:12 <donoban>     DONT MERGE THIS!!!!
2023-04-03 15:26:13 <donoban> :D
2023-04-03 15:28:39 <donoban> ok thanks ikke 
2023-04-03 20:09:23 <WhyNotHugo> As someone shipping Rust code, how can I best package this mess for downstream distributions?
2023-04-03 20:10:14 <WhyNotHugo> I've tried generating tarballs with vendored dependencies, but cargo includes build-dependencies to terminal-related libraries on windows, and that pulls like 200MB of crap.
2023-04-03 20:10:31 <orbea> WhyNotHugo: the blunt answer is write in C...
2023-04-03 20:10:49 <WhyNotHugo> I'm looking for the second best answer here.
2023-04-03 20:12:07 <orbea> depends on the distro, but they may not want to use vendored deps
2023-04-03 20:12:40 <WhyNotHugo> Would alpine use them?
2023-04-03 20:13:07 <orbea> someone else would need to answer how alpine does rust specifically
2023-04-03 20:20:36 <elibrokeit> WhyNotHugo: make two tarballs perhaps?
2023-04-03 20:20:54 <elibrokeit> a windows one and a Unix one
2023-04-03 20:24:59 <WhyNotHugo> I don't even care about windows support, it's a bunch of transitive dependencies that pull these in.
2023-04-03 20:25:15 <WhyNotHugo> But they're only dependencies on windows, like, they're not even downloaded when you try to build on Linux.
2023-04-03 20:25:31 <WhyNotHugo> But yuo can't easily exclude them from the vendoring process.
2023-04-03 20:26:02 <orbea> can you elaborate on what kind of dependencies these are? are they crates
2023-04-03 20:26:03 <orbea> ?
2023-04-03 20:26:36 <WhyNotHugo> Output of cargo tree --target=all | less | wl-copy: https://paste.sr.ht/blob/55c80be51446399e84402f687507c4fec5c01d1b
2023-04-03 20:26:45 <WhyNotHugo> Look for "winapi"
2023-04-03 20:27:16 <WhyNotHugo> So these crates specify "on windows I need winapi". `cargo vendor` unconditionally pulls this.
2023-04-03 20:27:25 <WhyNotHugo> So when I try to tarball this, it's 200MB of crap.
2023-04-03 20:28:07 <orbea> these are all available from crates.io?
2023-04-03 20:29:39 <orbea> specified in Cargo.lock?
2023-04-03 20:30:02 <WhyNotHugo> For a single of my direct dependencies I use a locked commit of a github repo.
2023-04-03 20:30:27 <WhyNotHugo> https://github.com/Smithay/client-toolkit
2023-04-03 20:35:03 <elibrokeit> maybe use a script that deletes all the ones you know you don't need?
2023-04-03 20:36:58 <elibrokeit> also why does it look like most of the first hits are because of some crate for building C++
2023-04-03 20:37:42 <elibrokeit> welp, this is depressing 
2023-04-03 20:37:58 <elibrokeit> maybe cargo needs an option to vendor only platform specific stuff.
2023-04-03 20:40:10 <WhyNotHugo> It does: https://github.com/rust-lang/cargo/issues/7058
2023-04-03 20:40:25 <orbea> cargo ebuild is not returning...wanted to see what dep list it generated,but oh well...
2023-04-03 21:49:29 <sam_-> orbea: --noaudit may help
2023-04-03 21:49:34 <sam_-> or try pycargoebuild instead
2023-04-03 23:04:19 <psykose> WhyNotHugo: the best way is to do nothing
2023-04-03 23:04:28 <psykose> just ship the application with the .lock
2023-04-03 23:37:41 <orbea> sam_-: didn't know about pycargobuild, but that fails presumably for the same reason, this repo doesn't have Cargo.lock
2023-04-03 23:38:10 <orbea> at least it was verbose though :P
2023-04-04 00:08:23 <elibrokeit> WhyNotHugo: at this point the practical solution is to recognize that rust doesn't want to help you here, so you'll have to help yourself. fork your dependencies and modify them to delete any cfg you don't need for your application, and tell cargo to override the resolution and use your fork
2023-04-04 00:09:37 <elibrokeit> depend on e.g. iana-time-zone-linuxonly
2023-04-04 00:45:15 <psykose> ^ ignore this advice
2023-04-04 00:48:54 <elibrokeit> psykose: curious why you don't like it
2023-04-04 01:33:37 <orbea> elibrokeit: sounds like a lot of technical debt
2023-04-04 01:37:29 <elibrokeit> if you're doing it to fix a real problem in the programming language itself then why does that matter?
2023-04-04 09:53:39 <WhyNotHugo> If I'm going to override resolution, I might as well override `winapi` with an empty crate.
2023-04-04 11:54:16 <nmeum> is there any way to get the origin name of all installed packages? neither apk list nor apk info seem to have an option to print the origin name
2023-04-04 11:55:01 <nmeum> apk search has -o but doesn't seem to be able to filter installed packages
2023-04-04 11:56:04 <ptrc> nmeum: grep '^o:' /lib/apk/db/installed | sort -u
2023-04-04 12:10:57 <elibrokeit> WhyNotHugo: sure, same basic idea
2023-04-04 14:03:09 <Piraty> when will the next alpine release branch off of edge?
2023-04-04 14:11:34 <ikke> Official date is 1 May 
2023-04-04 14:41:13 <Piraty> oh great. thanks
2023-04-04 14:49:35 <pj> elibrokeit: that's completely untrue
2023-04-04 14:49:45 <pj> a blatant lie even
2023-04-04 14:50:09 <pj> WhyNotHugo: specify dependencies with target_os in Cargo.toml
2023-04-04 15:12:11 <elibrokeit> pj: the problem being solved here is that cargo vendor will download dependencies for every possible cfg resolution 
2023-04-04 15:13:27 <elibrokeit> the program in question doesn't compile on Windows to begin with. deep in its dep tree, other crates conditionally depend on "winapi" if target_os is windows.
2023-04-04 15:14:38 <elibrokeit> because of this conditional recursive dep, cargo vendor downloads ***huge*** dependencies which shall never be used
2023-04-04 15:49:53 <WhyNotHugo> elibrokeit: Exactly, thanks for putting it in clearer terms.
2023-04-05 05:41:57 <ikke> low probability corruption bug fixed in zstd: https://github.com/facebook/zstd/releases/tag/v1.5.5
2023-04-05 05:42:22 <ikke> already upgraded in aports
2023-04-05 16:55:07 <ovf> http://0x0.st/HXHq.diff
2023-04-05 16:55:28 <ovf> also, how is man-pages built? it doesn't have makedepends probably because those would be outside 'main'
2023-04-05 16:56:37 <ikke> ovf: anything that is in build-base is not explicitly added in makedepends
2023-04-05 16:57:19 <ovf> at a first glance it seems to want 'sponge' from 'moreutils'
2023-04-05 17:02:38 <ikke> it builds without sponge installed
2023-04-05 17:04:10 <ovf> interestingly enough, not for me (either 'abuild roobld' or 'abuild' without moreutils installed)
2023-04-05 17:04:13 <ovf> *rootbld
2023-04-05 17:04:35 <ikke> ovf: is that with your change applied?
2023-04-05 17:05:15 <ovf> ...yes. sorry, today isn't my day
2023-04-05 17:05:21 <ikke> yeah
2023-04-05 17:06:14 <ikke> so that's very likely the reason it uses find + gz instead of using Z=.gz
2023-04-05 17:11:39 <ovf> yep. i note that upstream has a rather gratuitous use of sponge. (they output uncompressed pages into files ending in .gz and then want to gzip them in place)
2023-04-05 17:11:53 <ikke> lol
2023-04-05 17:19:39 <donoban> does anyone know what kind of use has the "session optional pam_keyinit.so force revoke"?
2023-04-05 17:19:52 <donoban> wops, copy&pasting error
2023-04-05 17:20:14 <donoban> I want to say the "Kernel session keyring"
2023-04-05 17:20:47 <donoban> I saw a pam rule on sddm config forcing it to be revoked, but not in any other pam configuration
2023-04-05 17:28:34 <Ermine> does Alpine ship liudev-zero's helper program for mdev?
2023-04-05 17:58:57 <donoban> hm... according to packages that depend on https://pkgs.alpinelinux.org/package/edge/main/s390x/keyutils-libs , it doesn't seem very extended
2023-04-05 20:55:52 <ovf> psykose: thanks!
2023-04-05 22:54:46 <winter> psykose: what does this commit fix, out of curiosity? seems that the Ninja deps would be properly setup so that a manual build of that target isn't required, no? https://git.alpinelinux.org/aports/commit/?id=ceee2f96a993ae2aa508f7cfff7d847321aaaacc
2023-04-05 22:55:22 <psykose> the 'seems that' is wrong, there is no dependency there
2023-04-05 22:56:59 <winter> what broke it all of a sudden, was a bump not tested or something?
2023-04-05 22:58:30 <psykose> beats me, i assume it works 20% of the time
2023-04-05 22:59:29 <psykose> gen/components/feed/core/proto/v2/wire/web_feeds.pb.cc depends on that existing but does not depend on that target
2023-04-05 22:59:34 <psykose> other things do so sometimes it works anyway
2023-04-05 23:01:53 <psykose> if you're asking as a chromium developer then you know more than me :p
2023-04-05 23:02:24 <psykose> feel free to fix the gn deps
2023-04-05 23:03:20 <winter> nope, just another distro dev scratching her head :P
2023-04-05 23:03:29 <psykose> :)
2023-04-05 23:03:30 <winter> let me see what we happen to do for this, maybe i can get some more info
2023-04-05 23:03:58 <winter> (hi, i know nothing about alpine dev, but noticed this commit and it looked interesting)
2023-04-05 23:06:54 <winter> odd, looks like all we do is the same ninja invocation too, but i see no build failures
2023-04-05 23:07:11 <psykose> or well it wasn't web_feeds.pb.cc but some other thing..
2023-04-05 23:07:16 <psykose> i dunno it's weird
2023-04-05 23:07:25 <psykose> and not always reproducible
2023-04-05 23:08:29 <winter> sounds like a race then?
2023-04-05 23:08:30 <winter> o.O
2023-04-05 23:08:47 <winter> that's not very fun
2023-04-05 23:09:31 <winter> happen to know where i'd find logs, was this run into on one of the alpine buildbots?
2023-04-05 23:10:05 <psykose> https://img.ayaya.dev/qvHtvoimo4S8
2023-04-05 23:11:26 <psykose> this is hilarious because i can't repro it anymore :p
2023-04-05 23:11:30 <psykose> but it did fail in a loop until that
2023-04-05 23:14:53 <winter> psykose: https://github.com/chromium/chromium/commit/a7d41a879e76768b1875ed145dae2ad0584584a0
2023-04-05 23:14:58 <winter> looks like this is it
2023-04-05 23:15:28 <winter> wonder how it ever worked at all
2023-04-05 23:15:50 <psykose> yep it's that
2023-04-05 23:15:56 <winter> or only works some times when building the aport, as it's the same invocations...
2023-04-05 23:15:57 <psykose> uhh something else just depends on it i guess
2023-04-05 23:16:19 <winter> yeah but nothing's changed, i guess it could be a race cond in ninja?? but that seems bad :(
2023-04-05 23:16:23 <winter> and unlikely
2023-04-05 23:16:24 <winter> idk
2023-04-05 23:16:46 <psykose> as the commit says it was only broken in https://chromium-review.googlesource.com/c/chromium/src/+/4266050
2023-04-05 23:16:59 <psykose> which is only 112 pretty sure
2023-04-05 23:17:11 <psykose> too lazy to check which M that is in
2023-04-05 23:17:22 <psykose> so it's basically only This Release
2023-04-05 23:17:47 <psykose> the reason why it's not deterministic is because of the time taken for stuff in parallel in ninja
2023-04-05 23:18:11 <psykose> the build graph is deterministic (at least in samurai, i forget what ninja does) but the actual jobs take varying time so something outputs that .h just happens to be first sometimes
2023-04-05 23:18:16 <psykose> nothing scary i don't think
2023-04-05 23:18:18 <psykose> just a missing dep :D
2023-04-05 23:19:06 <psykose> given that it works for everyone (and even us) except Sometimes i'm going to guess it's an issue only when you have above a certain N of parallelism that is also below a certain speed
2023-04-05 23:19:16 <psykose> which is exactly how you find parallelism bugs in the first place
2023-04-05 23:19:21 <psykose> create a million really slow jobs
2023-04-05 23:20:21 <psykose> i wouldn't worry about it :)
2023-04-05 23:27:55 <psykose> also surprised someone reads the commit history :p
2023-04-05 23:28:50 <winter> :) i'm a dumb nerd, so yeah
2023-04-05 23:28:54 <winter> question though
2023-04-05 23:29:45 <winter> is it typical that folks don't include much description to why they made a nontrivial/nonobvious change, e.g. the chromium one above? like, idk, maybe the commit desc could have mentioned something, or it could have added a comment saying why the weird manual build is needed
2023-04-05 23:29:47 <winter> idk
2023-04-05 23:29:54 <winter> just curious
2023-04-05 23:30:09 <psykose> nah that's just me being stupid
2023-04-05 23:30:40 <psykose> but also from experience i already know that what looks like the above is a buildorder workaround for these cases
2023-04-05 23:30:51 <psykose> it would also take 3x longer to write out why it's wrong
2023-04-05 23:31:45 <psykose> i usually try write more stuff in .patch files instead, but dunno
2023-04-05 23:31:59 <psykose> after working on it for so long all of it is '''obvious''' and it's hard to write anything
2023-04-05 23:32:17 <winter> yeah, i get that
2023-04-06 00:30:47 <winter> is there a reason things like GOCACHE (that are set in ~every Go package) aren't set in abuild.conf like other variables are (maybe bc of the usage of srcdir)? furthermore, why does the setting of these variables in packages do `export GOCACHE="${GOCACHE:-"$srcdir/go-cache"}"` -- where else would GOCACHE be set so that the default isn't used?
2023-04-06 00:31:26 <psykose> abuild.conf doesn't let you to use srcdir indeed
2023-04-06 00:31:33 <psykose> it can be set yourself
2023-04-06 00:33:21 <winter> ah, i'm guessing... in abuild.conf...
2023-04-06 00:33:44 <winter> why would you want to do that, though, can builds even escape the buildroot (so things like a shared GOCACHE may be beneficial)
2023-04-06 00:34:48 <psykose> they can escape it to anywhere yeah
2023-04-06 00:34:58 <psykose> the default abuild (not rootbld) is just like running a script in a dir
2023-04-06 00:35:21 <winter> i see
2023-04-06 00:42:12 <winter> psykose, i've seen a bunch of commits where you rebuild packages against a newer lib*. how do you detect that such things are required, via issues as a bump happens + causes stuff?
2023-04-06 00:43:26 <psykose> file diff into seeing it has a new soname
2023-04-06 00:47:59 <sam_-> you should definitely file diff things as a packager
2023-04-06 00:48:02 <sam_-> if you're not already, start :)
2023-04-06 00:48:13 <sam_-> (also diff the build system if ur a pro)
2023-04-06 00:54:16 <psykose> build system diffs are fun
2023-04-06 00:57:15 <handlerug> file diffs as in diffing the trees resulting from unpacking the old and the new .apks?
2023-04-06 00:58:56 <psykose> pretty much
2023-04-06 01:57:06 <winter> <@psykose> file diff into seeing it has a new soname <-- do you then manually bump all packages that depend on that package's pkgrel, or do you do it automatically with awk magic or something?
2023-04-06 01:57:06 <winter> (also what do you mean by diffing the build system, what does that mean in aports terms?)
2023-04-06 01:57:34 <psykose> usually just random shell things i think of
2023-04-06 01:57:35 <psykose> depends
2023-04-06 01:57:49 <psykose> apk list -d so:libsomething.so.1 lists what uses the old one, etc
2023-04-06 01:57:55 <sam_-> diff meson.build in old/new, diff configure.ac in old/new, ...
2023-04-06 01:57:56 <psykose> ap revdep is useful for other stuff
2023-04-06 01:57:57 <psykose> shrug
2023-04-06 01:58:14 <psykose> as for build diffs i view upstream tag diff most of the time
2023-04-06 01:58:56 <psykose> e.g. https://github.com/madler/zlib/compare/v1.2.12...v1.2.13 and then scroll thru the files like a chump
2023-04-06 08:20:01 <midasi> psykose: could you please review MR !20664? The dependency to libc6-compat was removed in the meantime
2023-04-06 08:45:44 <psykose> no
2023-04-06 09:04:11 <midasi> is anybody else able to proceed with MR !20664?
2023-04-06 11:57:00 <winter> https://gitlab.alpinelinux.org/alpine/aports/-/blob/b366ab43efc78d76556c983664a803e3d185b9d0/main/doas-sudo-shim/APKBUILD#L24 why can't this be defined at top-level? i see nothing in e.g. the apkbuild reference that would prohibit this, and it's not like it's doing provides="sudo" or similar 🤔
2023-04-06 12:00:03 <ikke> winter: only thing I can think of is to prevent subpackages from conflicting with sudo
2023-04-06 12:01:47 <winter> ikke: are depends etc only parsed after package() (and whatever sub package functions) are run then, so stuff like this is possible?
2023-04-06 12:03:16 <winter> i guess that's also why the version "should always be lower than the ... real sudo," but i don't see why doas-sudo-shim-doc wouldn't conflict with sudo-doc no matter the version, assuming they install the same files
2023-04-06 12:03:30 <winter> like, they'd always conflict, i'm guessing
2023-04-06 12:05:08 <psykose> winter: it can be top-level
2023-04-06 12:05:11 <psykose> no difference there
2023-04-06 12:05:43 <psykose> the docs also don't conflict
2023-04-06 12:05:52 <psykose> sudo has sudo.8, that has sudo.1
2023-04-06 12:07:01 <psykose> the top-level applies to all subpackages, but most default_ subpackages reset it
2023-04-06 12:07:04 <psykose> like doc
2023-04-06 12:07:13 <psykose> does depends_doc which is empty by default
2023-04-06 12:46:36 <winter> psykose: in the past, would it have conflicted, i guess that's why it's there? what about the version thing, do you happen to know what's up with that? (thank you for taking the time to answer my questions by the way, i appreciate it)
2023-04-06 12:54:16 <psykose> not sure what you mean by the past, the conflict is because they do conflict in binary (/usr/bin/sudo)
2023-04-06 12:54:21 <psykose> the -doc manpages don't
2023-04-06 12:54:41 <psykose> the version is because they both have /usr/bin/sudo
2023-04-06 12:54:57 <psykose> and abuild has a feature to add a cmd:binaryname=$pkgver-r$pkgrel of every binary in PATH
2023-04-06 12:55:05 <psykose> and some people add binaries via apk add cmd:binaryname
2023-04-06 12:55:14 <psykose> if it had a bigger version it would be what gets installed i guess
2023-04-06 12:55:21 <psykose> which would probably not be intentional
2023-04-06 12:56:02 <psykose> to add a provides= *, specifically
2023-04-06 14:34:03 <winter> <@psykose> not sure what you mean by the past, the conflict is because they do conflict in binary (/usr/bin/sudo) <-- i meant why it's not at toplevel when it can be because of the resetting you mentioned, i guess the author just wasn't aware and wanted to be on the safer side?
2023-04-06 14:34:30 <winter> <@psykose> to add a provides= *, specifically <-- what do you mean by this?
2023-04-06 14:34:40 <winter> like, how does it relate to your earlier messages?
2023-04-07 01:58:31 <Thermi> Hello, I have an MR here that needs to use a snapshot. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/45752
2023-04-07 02:40:19 <psykose> winter: it doesn't matter if it's top level or not is what i mean
2023-04-07 02:40:25 <psykose> the effect is the same
2023-04-07 04:09:09 <ikke> Thermi: you know you can get archives from github for commit hashes as well? 
2023-04-07 04:18:29 <psykose> that is one of the worst things i have ever seen in my life
2023-04-07 04:21:47 <sam_-> did u look in the mirror lol
2023-04-07 04:22:08 <psykose> ok fair
2023-04-07 04:22:10 <psykose> second
2023-04-07 04:23:26 <sam_-> oh wow that is uh
2023-04-07 04:23:27 <sam_-> creative
2023-04-07 04:26:00 <abby> wow
2023-04-07 05:30:27 <Thermi> wow so kind
2023-04-07 05:31:06 <Thermi> ikke, hmmmh. I presume this is about libvmime, no?
2023-04-07 05:31:24 <Thermi> (Because for grommunio-* we did it like that. the libvmime change was given to me verbatim like this)
2023-04-07 05:32:42 <psykose> you should set up an internal repository at your company instead
2023-04-07 05:35:37 <Thermi> yeaaaah we've been over that topic a couple of times and the answer was always that I was just supposed to do as I was told :)
2023-04-07 05:35:58 <Thermi> (or that it would be too much maintenance work internally to keep up with changes and coordination with the new releases)
2023-04-07 05:36:10 <psykose> yeah
2023-04-07 05:36:18 <psykose> it's certainly easier to send complete dogshit to open source projects instead
2023-04-07 05:36:23 <psykose> how about you don't do what you're told instead
2023-04-07 05:36:28 <psykose> :)
2023-04-07 05:36:34 <Thermi> :shrug: I like money
2023-04-07 05:36:48 <psykose> noted!
2023-04-07 05:36:55 <Thermi> I'm basically just a messenger right now
2023-04-07 05:37:01 <Thermi> so the problem is libvmime, the others are fine?
2023-04-07 05:37:31 <Thermi> grommunio is a better project for a groupware than kopano, so at least now that zarafa is basically gone for a couple of years, there'd be a groupware that would be readily available
2023-04-07 05:37:50 <Thermi> (because packaging kopano and grommunio is, as evident, not a 5 minute job)
2023-04-07 05:39:02 <ikke> Thermi: it would be nice that you would review what you get sent and send feedback back rather than being a dumb messenger
2023-04-07 05:39:22 <Thermi> ikke, then what is the feedback from you to me then?
2023-04-07 05:39:45 <Thermi> ah, misread. Sorry.
2023-04-07 05:39:58 <ikke> at least for libvmime: use github archives instead of requiring us to maintain snapshots
2023-04-07 05:40:04 <Thermi> thank you
2023-04-07 05:40:06 <psykose> it would be nice if you did this internally in your company
2023-04-07 05:40:10 <psykose> i reject this waste of time
2023-04-07 05:40:12 <psykose> stop sending it at all
2023-04-07 05:40:17 <psykose> thank you
2023-04-07 05:40:48 <psykose> this is not a place to dump random shit and "get paid" because you "like money"
2023-04-07 06:26:34 <ncopa> good morning!
2023-04-07 06:28:26 <psykose> mornin
2023-04-07 08:26:20 <nmeum> psykose: how do the libgit2 rust bindings work? will it silently fallback to a vendored libgit2 version if the system-installed libgit2 version is not supported by the bindings?
2023-04-07 08:26:34 <psykose> i don't have a very precise understanding, but yes
2023-04-07 08:26:43 <psykose> in fact, i think it's a bit more dumb than that- you see something like
2023-04-07 08:26:50 <psykose> libgit2-sys-0.15.0+1.6.3
2023-04-07 08:26:51 <psykose> right
2023-04-07 08:26:56 <psykose> if you have 1.6.2, it falls back
2023-04-07 08:27:00 <psykose> if you have 1.6.4, it falls back
2023-04-07 08:27:04 <nmeum> urhgs
2023-04-07 08:27:04 <psykose> only links with exact, or something
2023-04-07 08:27:12 <psykose> but it's been a while since i tested the behaviour
2023-04-07 08:27:18 <psykose> in this case, there is only 1.6.3 anyway
2023-04-07 08:27:26 <psykose> (the -sys crate only has a 1.6.3 version)
2023-04-07 08:27:42 <psykose> updating is /usually/ something like cargo update -p for the crates in question
2023-04-07 08:28:27 <psykose> if it works then cargo will say it updated it in the output, and then that should work
2023-04-07 08:28:36 <psykose> if it doesn't say anything then some other constraints weren't met
2023-04-07 08:28:37 <nmeum> we can also just wait a few weeks/months with the libgit2 1.6 update and then manually adjust creates which still do not support libgit2 1.6.3
2023-04-07 08:28:58 <psykose> well, it goes both ways
2023-04-07 08:29:06 <psykose> currently some rust things "link libgit2"
2023-04-07 08:29:19 <psykose> and when they upgrade to some version that uses the new -sys, it will just silently not use the "system libgit2"
2023-04-07 08:29:27 <psykose> then maybe in the MR it will start using it again
2023-04-07 08:30:05 <psykose> i can't think of any good solution except either manually bumping every one and checking it, or just doing nothing and going thru with it and letting them either vendor it or not
2023-04-07 08:30:29 <psykose> i wonder if there's a way to easily get cargo to use system-installed -sys crates universally..
2023-04-07 08:30:51 <nmeum> ideally those crates would just fail to build unless they pick up the system libgit2 version, but not sure if we can enforce that somehow
2023-04-07 08:30:56 <psykose> in fedora they require every crate to be system managed, which is a bit way too much work, but if it's possible to make it "only some crates" that would be useful for this
2023-04-07 08:31:04 <psykose> yeah there's no way to enforce it :/
2023-04-07 08:31:13 <abby> isn't there a way to tell it to use pkgconfig
2023-04-07 08:31:21 <psykose> it does
2023-04-07 08:31:36 <psykose> the issue is the bindings silently fallback to vendored if they don't match the system lib
2023-04-07 08:32:03 <psykose> since the bindings are generated for a specific version, the +$ver in the version of them
2023-04-07 08:32:06 <nmeum> do the rust crates link statically or dynamically against libgit2?
2023-04-07 08:32:31 <psykose> against system? defaults to dyn or whatever
2023-04-07 08:32:47 <psykose> vendored is vendored static like always
2023-04-07 08:32:47 <nmeum> can't we just do something like "if libgit2-dev is in $makedepends, then package() must include a binary which links against an .so provided by libgit2-dev otherwise fail the build"-thing in abuild?
2023-04-07 08:33:11 <psykose> kind of but that's a ton of work and very error prone as a general case
2023-04-07 08:33:23 <psykose> also slow
2023-04-07 08:33:28 <nmeum> hmhm
2023-04-07 08:33:30 <nmeum> yea, probably
2023-04-07 08:34:42 <psykose> if abuild wasn't sh it would be possible to have a lot of checks that were fast for various things, but sadly looping stuff like this adds up a lot :D
2023-04-07 08:36:22 <psykose> it would also only serve as "enforcement" in this case- i.e. telling you something went wrong
2023-04-07 08:36:29 <psykose> doesn't help much with the fundamental difficulty of the issue
2023-04-07 12:10:50 <skarnet> > grommunio
2023-04-07 12:10:54 <skarnet> > kopano
2023-04-07 12:10:59 <skarnet> > zarafa
2023-04-07 12:11:02 <skarnet> are the capitalists okay
2023-04-07 12:28:50 <Ermine> ?
2023-04-07 12:31:30 <skarnet> apparently these are all names for existing groupware software
2023-04-07 12:32:16 <skarnet> there was a time where you didn't name your software after troll belching sounds
2023-04-07 13:19:45 <Ermine> It is as weird as corporate art style
2023-04-07 13:43:16 <skarnet> 
ACTION grommunios Ermine

2023-04-07 13:45:36 <Ermine> 
ACTION starts kopaning

2023-04-07 13:46:54 <minimal> I thought they were names of Mexican revolutionaries ;-)
2023-04-07 14:02:59 <valerius> lol, glad to wake up to a laugh... I have unfortunately had some corporate experience with the named products...
2023-04-07 17:58:00 <winter> <@psykose> winter: it doesn't matter if it's top level or not is what i mean <-- got it, but i still don't understand how the depends at toplevel thing relates to setting provides as you said earlier, am i missing something obvious?
2023-04-07 18:03:13 <psykose> the two things are not related at all, the latter was about the version
2023-04-07 18:12:39 <winter> i see, is there an implicit provides or something?
2023-04-07 18:12:48 <winter> maybe i'm just misunderstanding
2023-04-07 18:13:04 <winter> i understand why you don't want the version to go above real sudo for cmd:sudo
2023-04-07 18:16:33 <winter> <@psykose> and abuild has a feature to add a cmd:binaryname=$pkgver-r$pkgrel of every binary in PATH <-- maybe i'm misunderstanding this/how it relates to provides, is what i mean
2023-04-07 18:16:54 <psykose> there is an implicit provides of that
2023-04-07 18:17:14 <psykose> e.g. sudo has provides="cmd:sudo=$pkgver-r$pkgrel" because it has a sudo binary
2023-04-07 18:17:24 <ikke> try `apk info -P sudo`
2023-04-07 18:18:28 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1505
2023-04-07 18:18:32 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1240
2023-04-07 18:21:33 <winter> ahhhhhh, so by "and abuild has a feature to add a cmd:binaryname=$pkgver-r$pkgrel of every binary in PATH", you meant "to add a provides=...", which is what you said later
2023-04-07 18:21:38 <winter> okay, i understand now
2023-04-07 18:22:07 <winter> thanks!
2023-04-07 21:31:31 <that_guy> The format of the files at secdb.alpinelinux.org has changed
2023-04-07 21:32:00 <that_guy> is that on purpose or a script misbehaving? if the former, was that announced somewhere?
2023-04-07 21:40:06 <psykose> the titles?
2023-04-07 21:40:20 <psykose> there was a change like today so it's probably that
2023-04-07 21:41:14 <that_guy> the shape of the `pkg.secfixes` member changed
2023-04-07 21:42:32 <that_guy> I'm using go to unmarshal into my type called `Details`, so the error I'm seeing: json: cannot unmarshal array into Go struct field Details.packages.pkg.secfixes of type map[string][]string
2023-04-07 21:43:13 <psykose> aha, i see what you mean
2023-04-07 21:44:20 <psykose> ikke: you probably oops'd something in https://gitlab.alpinelinux.org/alpine/security/secdb/-/merge_requests/7
2023-04-07 21:44:33 <that_guy> yeah, compare/contrast the 3.3 data vs the 3.17 data
2023-04-07 21:45:10 <psykose> it'll probably get fixed when he sees it :)
2023-04-07 21:50:29 <that_guy> rad. Can also open a gitlab issue if needed
2023-04-08 06:10:05 <ikke> that change was unintentional
2023-04-08 06:55:55 <ikke> https://gitlab.alpinelinux.org/alpine/security/secdb/-/merge_requests/8
2023-04-08 10:14:38 <ikke> that_guy: The format is restored back to how it was
2023-04-08 17:58:42 <WhyNotHugo> gitlab.alpinelinux.org/alpine/mkinitfs has no licence
2023-04-08 18:00:59 <ptrc> the aports package assumes GPL-2.0-only
2023-04-08 19:37:48 <umk3[m]> waybar is not finding wireplumber module, is it because waybar wasn't compiled with wireplumber-dev in makedepends?
2023-04-09 01:30:05 <psykose> WhyNotHugo: it has a licence on nlplug
2023-04-09 01:30:07 <psykose> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs/nlplug-findfs.c#L2
2023-04-09 01:30:07 <psykose> :P
2023-04-09 01:31:18 <psykose> umk3[m]: yeah, fixed that, should work now
2023-04-09 01:58:28 <umk3[m]> psykose thank you so much!
2023-04-09 01:58:48 <umk3[m]> it works
2023-04-09 02:01:42 <psykose> :)
2023-04-09 11:51:11 <WhyNotHugo> psykose: lol
2023-04-09 11:51:21 <WhyNotHugo> Just to be clear, does that include patent grants?
2023-04-09 11:52:29 <psykose> i have no idea :p
2023-04-09 11:53:03 <psykose> i guess at this point it would be weird to just licence it without asking every contributor
2023-04-09 11:54:22 <psykose> or maybe we could just say the aports licence for it was the correct one
2023-04-09 11:54:33 <psykose> i don't think it's very relevant or matters very much
2023-04-09 11:54:56 <psykose> hhh not again this is the 10th time i got baited into licensing isn't it
2023-04-09 11:55:15 <psykose> that's it, next time pay me $500/hr :p
2023-04-09 11:57:37 <psykose> the licence was in license= since added in
2023-04-09 11:57:38 <psykose> 73fabdb4e43466a9f3a0777780045e3d83274d0c
2023-04-10 03:52:26 <psykose> really wish buildrepo could do builds in parallel sometimes
2023-04-10 03:52:54 <psykose> currently building main/ with 80 cores
2023-04-10 03:53:03 <psykose> and the load average in 30 minutes is.. 4
2023-04-10 03:53:09 <psykose> literally 95% idle
2023-04-10 04:17:26 <psykose> scratch that, it goes as low as 1.5
2023-04-10 05:26:32 <ikke> building packages in parallel comes with its own set of challenges
2023-04-10 05:28:30 <psykose> obviously
2023-04-10 07:56:24 <ncopa> building packages in parallel would be nice indeed, but would require a major refactoring of the building infra
2023-04-10 07:56:34 <ncopa> and a major refactoring is needed anyway for other reasons too
2023-04-10 08:26:26 <psykose> given the way the current building works it's pretty much only buildrepo that has to be changed
2023-04-10 16:34:01 <Newbyte> Do you have any ideas what could be causing this: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/1007427
2023-04-10 16:55:42 <Elysia> Hello, I am searching the source code for the alpine setup script. I have tried to find it in the git repo but I got no result for "setup-alpine". Any idea where I can find the source code?
2023-04-10 17:01:22 <Elysia> nvm I found it under https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in
2023-04-10 17:01:28 <ikke> https://gitlab.alpinelinux.org/alpine/alpine-conf/
2023-04-10 17:13:48 <humm_> its sources are in /sbin/setup-alpine 
2023-04-10 17:16:30 <donoban> is there a special word for specifying options on a subpackage?
2023-04-10 17:18:44 <ikke> donoban: what do you mean?
2023-04-10 17:19:07 <donoban> I'm doing a -suid subpcakage for swaylock, so you can use it free of pam
2023-04-10 17:19:22 <donoban> I did options="suid" on the subpackage function
2023-04-10 17:19:26 <donoban> but it failed
2023-04-10 17:19:34 <ikke> options are global
2023-04-10 17:19:47 <ikke> so no, there is no way to enable an option just for a subpackage
2023-04-10 17:20:03 <donoban> oh, I see
2023-04-10 17:21:02 <donoban> well, I will try if it's accepted
2023-04-10 17:21:09 <donoban> it's inspired in phsylock and pshylock-elogind
2023-04-10 17:21:44 <donoban> I think that it could be improved
2023-04-10 17:22:03 <donoban> it should work runnig with sgid and making it shadow group
2023-04-10 17:22:38 <donoban> hmM.. if fails I will let my desktop locked, nice
2023-04-10 17:27:22 <donoban> just a timer with:
2023-04-10 17:27:24 <donoban>        SIGUSR1
2023-04-10 17:27:26 <donoban>            Unlock the screen and exit.
2023-04-10 17:28:02 <donoban> yeah, I can safely test :D
2023-04-10 17:33:48 <donoban> 2023-04-10 19:33:40 - [shadow.c:19] swaylock needs to be setuid to read /etc/shadow
2023-04-10 17:33:52 <donoban> rggg
2023-04-10 17:40:17 <donoban> yeah, it works
2023-04-10 17:40:28 <donoban> altought it semes that it needs "suid" option too
2023-04-11 06:15:37 <psykose> donoban: i would refuse that
2023-04-11 06:15:48 <psykose> things that use pam should never have suid versions or whatever
2023-04-11 07:45:28 <raspbeguy> hello, would you happen to have an exemple of a ruby program aport ?
2023-04-11 08:25:55 <pj> psykose: why abuild fails when -static is after -dev >:(
2023-04-11 08:26:11 <psykose> you already know why
2023-04-11 08:26:37 <pj> annoying
2023-04-11 08:26:52 <pj> although not as annoying as upgrading gitlab
2023-04-11 09:18:59 <donoban> psykose: why exactly? pam it's theorically (optional), it's paradoxical that you have a default sshd without pam but get forced to install it for an screenlocker :)
2023-04-11 09:20:16 <donoban> raspbeguy: try looking at this https://tpaste.us/9MMl
2023-04-11 09:21:51 <psykose> those two things aren't related at all
2023-04-11 09:23:56 <donoban> well, they are both things that can be built with or without pam support
2023-04-11 09:26:45 <psykose> not with or without suid however
2023-04-11 09:28:54 <dzilvys> Good morning beautiful people. What process do I need to follow to install grub instead of syslinux?, I read the docs however, /boot is not a efi compatible format. My question is, do I do the following -> Uninstall syslinux -> Format /boot to vfat -> apk add grub-efi -> grub-install --target=x86_64-efi --efi-directory=/boot. Or is there something else I am missing?
2023-04-11 09:29:47 <psykose> you can mount esp on /boot/efi and use --efi-directory=/boot/efi or whatever
2023-04-11 09:30:02 <psykose> or even just mount esp to /boot? i'm not sure what it matters what your /boot is or isn't currentl;y
2023-04-11 09:30:47 <dzilvys> esp/
2023-04-11 09:30:48 <dzilvys> ?
2023-04-11 09:31:15 <donoban> well, I understand that being suid it's a undiserable risk, but with the shadow/sgid fix it becomes probably safer than pam alternative
2023-04-11 09:41:57 <donoban> dzilvys: EFI System Partition
2023-04-11 09:46:19 <dzilvys> donoban: Oh thank you, I have encountered an issue though that when I am trying to boot into my os I am getting a mounting uuid=... on /sysroot failed: no such file or directory
2023-04-11 09:51:19 <donoban> hmm.. could you detail more what you did on #alpine-linux? this seems more suited to there
2023-04-11 10:00:15 <dzilvys> sure
2023-04-11 11:07:31 <donoban> uh.. psykose I think that it's unrelated to "su-l" but I have some tests failing on util-linux
2023-04-11 11:07:41 <psykose> that didn't fail before or
2023-04-11 11:08:05 <donoban> I think that it never failed, or at least didn't fail the build
2023-04-11 11:08:11 <donoban> I'm trying again removing su-l
2023-04-11 11:09:38 <donoban>   3 tests of 216 FAILED
2023-04-11 11:09:40 <donoban>       lsblk/lsblk
2023-04-11 11:09:42 <donoban>       script/buffering-race
2023-04-11 11:09:44 <donoban>       script/options
2023-04-11 11:09:49 <donoban> I'm gonna retry the pipeline
2023-04-11 11:23:40 <donoban> ouch, success pipeline but it didn't have any change on util-linux :D
2023-04-11 11:25:35 <psykose> usual scuffed tests
2023-04-11 11:35:47 <donoban> may I send a MR with just bump pgkrel for see if works on CI?
2023-04-11 11:38:55 <psykose> it does, i ran it recently
2023-04-11 11:39:08 <donoban> ok, so I will just add su-l
2023-04-11 12:21:06 <skarnet> there is no testing, there is only su-l
2023-04-11 12:23:55 <donoban> little time stressing for discover what/why fails on my system :) , but I will dig on it later 
2023-04-11 12:25:34 <skarnet> (it was a bad pun, derived from a famous Ghostbusters quote.)
2023-04-11 12:26:06 <psykose> people have watched ghostbusters?
2023-04-11 12:26:22 <skarnet> youngsters these days have no respect for anything anymore
2023-04-11 12:26:42 <donoban> I watched many times but don't remember any quote, only the main soundtrack hehe
2023-04-11 12:30:10 <Ermine> Oh those youngsters
2023-04-11 12:30:24 <psykose> i only watch good movies like the avengers
2023-04-11 12:34:36 <mercenary> Heh. I thought it was a derivation of "Do. Or do not. There is no try."
2023-04-11 12:35:14 <skarnet> that one's easy
2023-04-11 12:35:20 <skarnet> Do. Or do no. There is no ban.
2023-04-11 13:36:20 <ncopa> psykose: can you please push musl snapshot?
2023-04-11 13:38:56 <psykose> sure
2023-04-11 13:39:53 <psykose> done
2023-04-11 13:44:46 <ncopa> thanks!
2023-04-11 13:45:11 <ncopa> lets see what breaks...
2023-04-11 13:47:19 <psykose> if you see anything related to *64 then it's https://github.com/bminor/musl/commit/25e6fee27f4a293728dd15b659170e7b9c7db9bc
2023-04-11 13:47:22 <psykose> aside from that there are no breaks
2023-04-11 13:48:05 <psykose> for that specifically, the 'effort' fix is removing direct use of e.g. open64 from the code (correct usage is just open and passing -D_FILE_OFFSET_BITS=64, which works on glibc too)
2023-04-11 13:48:17 <psykose> and the easy fix is passing -D_LARGEFILE64_SOURCE to get the macro defines back
2023-04-11 13:48:46 <psykose> i already fixed a couple i think
2023-04-11 13:51:58 <ncopa> ok good
2023-04-11 14:29:14 <psykose> wish gcc13 was out so we could ship that
2023-04-11 14:29:33 <psykose> ncopa: do you mind looking at the DT_RELR thing so we can ship it in 3.18?
2023-04-11 14:29:40 <psykose> it works and i've tested it for half a year
2023-04-11 14:29:57 <psykose> all there is to figure out is how to set the ldflags only on x86* and idk how that's possible with abuild for the builders
2023-04-11 14:30:18 <psykose> i can conditionally append a line in apkbuild if you want, that would be fine
2023-04-11 14:30:42 <psykose> i guess i'll do that
2023-04-11 14:38:37 <psykose> ikke, ncopa: could you adjust the x86 and x86_64 abuild.conf on the builders to make sure it updated
2023-04-11 14:38:48 <psykose> thanks :)
2023-04-11 14:51:42 <psykose> ah, and ppc64le too
2023-04-11 15:07:24 <ncopa> im on it
2023-04-11 15:08:21 <ncopa> we should start work on release-notes for 3.18 too. I think this is a significant change that should be mentioned
2023-04-11 15:09:17 <ncopa> noDT_RELR for aarch64?
2023-04-11 15:10:02 <psykose> binutils only supports it on x86* and ppc64le
2023-04-11 15:10:20 <ncopa> binutils as in lld?
2023-04-11 15:10:36 <ncopa> what about gold?
2023-04-11 15:10:38 <psykose> binutils as in gnu binutils as in /usr/bin/ld on alpine as in ld.bfd
2023-04-11 15:10:45 <psykose> didn't check gold
2023-04-11 15:10:53 <ncopa> what bout golang linker?
2023-04-11 15:11:58 <psykose> zero issues or references in codebase
2023-04-11 15:12:00 <ncopa> looks like gold does not support it: https://sourceware.org/bugzilla/show_bug.cgi?id=28601
2023-04-11 15:12:02 <psykose> so.. no
2023-04-11 15:12:09 <psykose> and yeah gold doesn't get any feature work anymore
2023-04-11 15:12:10 <psykose> this is recent
2023-04-11 15:13:04 <ncopa> will gloang's cgo work with the libs from alpine with this?
2023-04-11 15:13:29 <psykose> i don't see why it wouldn't
2023-04-11 15:14:10 <psykose> it only affects final elf objects (not .o/.a), and then they are just normal objects that linkers don't look at in this sense
2023-04-11 15:14:19 <psykose> unless i severely misunderstood the problem space by a whole barn
2023-04-11 15:14:52 <ncopa> eg, if people use docker image go:1.20-alpine want to link system libs, package from apk add *-dev
2023-04-11 15:15:01 <psykose> in which case it would be the second thing that 'cannot be used' because golang the language exists and i will be seriously upset and throw a small fit and set fire to a google office (in minecraft)
2023-04-11 15:15:05 <psykose> yeah, should be fine
2023-04-11 15:15:32 <ncopa> i think we should add the above patch to gold too
2023-04-11 15:15:45 <ncopa> this is really cool
2023-04-11 15:16:06 <psykose> maybe, but nothing uses gold
2023-04-11 15:16:23 <ncopa> well, we have the package in our repos
2023-04-11 15:16:26 <psykose> except (arm golang, where it exists due to a binutils bug so they hardcoded it, but i don't consider that to be relevant in the spirit of discussion)
2023-04-11 15:16:39 <psykose> sure, but i am against it on 'simple' feature patch grounds :/
2023-04-11 15:16:45 <psykose> if gold wants this feature they should add it themselves
2023-04-11 15:16:50 <ncopa> so either we fix gold or remove it
2023-04-11 15:16:56 <psykose> this isn't a fix
2023-04-11 15:17:06 <psykose> it is also used for golang on arm
2023-04-11 15:17:17 <ncopa> ok
2023-04-11 15:17:33 <psykose> and yeah it works, i rebuild sqlite with the change, and things that link -tags=libsqlite3 still work
2023-04-11 15:17:50 <psykose> which uses cgo to link the .so
2023-04-11 15:17:56 <psykose> afaik
2023-04-11 15:17:59 <ncopa> ok good
2023-04-11 15:18:18 <psykose> so yeah, 3.18 should have a smaller docker image than 3.17 :p
2023-04-11 15:18:23 <psykose> for x86 i guess
2023-04-11 15:18:31 <psykose> now the only 'tracking' to do is what doesn't read LDFLAGS
2023-04-11 15:18:39 <psykose> because i have found quite the number of things by random chance
2023-04-11 15:19:02 <psykose> wish abuild could check that, but it's a bit expensive as a check because it's yet another elf loop
2023-04-11 15:19:43 <psykose> (using ldflags to add a note property, then reading it off the elf objects in pkgdir, and warning if not found)
2023-04-11 15:20:01 <psykose> it would also end up warning on prebuilt objects, so kind of a 2-in-1
2023-04-11 15:25:16 <pj> what's the deadline for 3.18
2023-04-11 15:28:53 <psykose> yes
2023-04-11 15:29:47 <ncopa> pj: i am about to set up the builders for 3.18 now
2023-04-11 15:29:54 <ncopa> or maybe tomorrow
2023-04-11 15:30:35 <pj> ngl, I neglected my packages and also have to push some stuff that would be nice at $work
2023-04-11 15:32:19 <ncopa> well, the builders will bootstrap, so as long as your packages are not compilers etc you may have this week to update them
2023-04-11 15:32:58 <ncopa> if its only minor updates, backwards compat updates, then deadline is 1 May
2023-04-11 15:33:19 <ncopa> psykose: i have updated abuild.conf on build-edge-x86* and build-edge-ppc64le
2023-04-11 15:33:23 <psykose> thanks
2023-04-11 15:33:38 <ncopa> does the CI also have those changes?
2023-04-11 15:33:46 <psykose> dunno what ci uses
2023-04-11 15:33:54 <psykose> if it just installs abuild and it doesn't conflict then it would work
2023-04-11 15:33:57 <ncopa> so we dont end up with CI pass but builders fail
2023-04-11 15:33:57 <ikke> abuild.conf from the package
2023-04-11 15:34:06 <ncopa> ok. good
2023-04-11 15:34:40 <psykose> dt_relr has some funny stuff in some places
2023-04-11 15:36:32 <psykose> >>> Size difference for libphonenumber: 17 MiB -> 6872 KiB
2023-04-11 15:36:48 <ncopa> um...
2023-04-11 15:36:57 <psykose> it's not a bug
2023-04-11 15:37:00 <ncopa> does libphonenumber work?
2023-04-11 15:37:03 <psykose> yes
2023-04-11 15:37:08 <ncopa> ok. wow..
2023-04-11 15:37:22 <ncopa> why don't we have this for arm?
2023-04-11 15:37:37 <psykose> someone has to implement it in binutils
2023-04-11 15:43:39 <ncopa> ok. im sure this will blow up in our faces due to something unexpected, but lets do it!
2023-04-11 15:43:44 <psykose> the person i know that cares about Weird Linker Stuff and one of the people that wrote a lot about this (https://maskray.me/blog/2021-10-31-relative-relocations-and-relr) is an ld.lld maintainer so mostly wrote the support there
2023-04-11 15:43:53 <psykose> and also implemented reading it in musl iirc
2023-04-11 15:44:01 <psykose> and no, i tested it extensively :D
2023-04-11 15:44:13 <psykose> i caught two bugs and made sure they were fixed in musl first
2023-04-11 15:44:23 <psykose> and backported all the support up to 3.13 so the binaries can run fine
2023-04-11 15:44:44 <psykose> i guess someone trying to run fresh edge binaries on 3.12 will have the segfault, sure
2023-04-11 15:44:50 <ncopa> that's why i say "something unexpected"
2023-04-11 15:44:53 <psykose> :)
2023-04-11 15:44:57 <psykose> redundant :p
2023-04-11 15:45:16 <ncopa> anyway, we'll hande that when it hits us
2023-04-11 15:45:19 <psykose> yeah
2023-04-11 15:47:58 <Ermine> What about !42734 ? If it is desirable to have, I'll try to find some time asap and finish it.
2023-04-11 15:52:48 <psykose> that's not impacted by any freeze
2023-04-11 15:54:32 <pj> fact check me: is disabling arch for package, effectivelly removing it from index and/or mirror?
2023-04-11 15:54:59 <ncopa> yes
2023-04-11 15:55:07 <pj> sad
2023-04-11 15:55:19 <ikke> it will not immediately be removed though
2023-04-11 15:55:48 <pj> what's the condition?
2023-04-11 15:55:53 <ikke> upgrading the package
2023-04-11 15:56:02 <pj> hm
2023-04-11 15:56:34 <pj> imo, packages should be allowed to lag behind per arch
2023-04-11 15:57:16 <psykose> most of the archs are gratuitous
2023-04-11 15:57:47 <psykose> disabling armhf in an upgrade impacts i think literally 0 people :p
2023-04-11 15:58:19 <pj> I was thinking of disabling ppc64le for luajit upgrade but I doubt that jirutka will allow this :P
2023-04-11 15:58:27 <psykose> well that was already discussed
2023-04-11 15:58:40 <psykose> in the sense of jirutka said 'no'
2023-04-11 15:58:54 <pj> yep
2023-04-11 16:00:54 <pj> god, luajit is main..
2023-04-11 16:01:02 <skarnet> on the other hand, differing behaviours depending on arch is sus
2023-04-11 16:01:19 <pj> luajit doesn't support ppc64l
2023-04-11 16:01:33 <psykose> it does
2023-04-11 16:01:40 <skarnet> if a piece of software builds on A and not on B, well, I'm not inclined to trusting that it works
2023-04-11 16:02:21 <pj> psykose: where
2023-04-11 16:02:27 <pj> surely not openresty luajit
2023-04-11 16:02:31 <psykose> someone added it in some merge request years ago
2023-04-11 16:02:34 <ncopa> whats the problem with luajit on ppc64le?
2023-04-11 16:02:46 <psykose> the new version fails tests on ppc64le
2023-04-11 16:02:55 <psykose> in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33367
2023-04-11 16:03:17 <pj> segfault
2023-04-11 16:03:25 <ncopa> maybe we can ask IBM for help?
2023-04-11 16:03:27 <pj> maybe just need to keep bumping tests+luajit and it will go away :)
2023-04-11 16:03:33 <psykose> i've bumped it twice :p
2023-04-11 16:04:02 <pj> definition of insanity... yada yada
2023-04-11 16:04:40 <pj> ncopa: do we have point of contact or some gitlab group to ping?
2023-04-11 16:04:51 <psykose> nope
2023-04-11 16:04:57 <psykose> well for the former, kind of
2023-04-11 16:05:10 <psykose> i forget who it was though
2023-04-11 16:05:12 <ncopa> i think we have a mick_ibm here in this channel?
2023-04-11 16:05:39 <mick_ibm> hello
2023-04-11 16:05:39 <psykose> last person that did some stuff was the binutils maintainer which was convenient
2023-04-11 16:06:09 <ncopa> hi mick_ibm! youare on ppc64le team right?
2023-04-11 16:06:15 <mick_ibm> yes :) 
2023-04-11 16:06:21 <mick_ibm> whats up
2023-04-11 16:06:26 <ncopa> maybe you can find someone who can help us with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33367
2023-04-11 16:06:35 <ncopa> luajit update does not work on ppc64le
2023-04-11 16:06:45 <skarnet> how's that for serendipity
2023-04-11 16:06:50 <mick_ibm> ok ill take a look
2023-04-11 16:07:05 <pj> should bump luajit+tests so we can new pipeline and logs
2023-04-11 16:07:19 <pj> s/can/can get/
2023-04-11 16:07:43 <ncopa> mick_ibm: awesome! thank you!
2023-04-11 16:08:45 <psykose> pj: i can do it if you want
2023-04-11 16:09:04 <psykose> ah it's already the latest
2023-04-11 16:09:34 <pj> then rebase after main/* commit
2023-04-11 16:09:40 <pj> :)
2023-04-11 16:09:44 <psykose> eh :p
2023-04-11 16:09:47 <psykose> same shit for pipeline
2023-04-11 16:11:34 <psykose> done
2023-04-11 16:14:20 <pj> damn, that luajit build is fast
2023-04-11 16:15:37 <pj> hmm, I wanted to add awscliv2 but it's already added 🤔
2023-04-11 16:15:59 <psykose> i got emailed
2023-04-11 16:16:00 <psykose> five
2023-04-11 16:16:02 <psykose> fucking
2023-04-11 16:16:02 <psykose> times
2023-04-11 16:16:03 <psykose> about it
2023-04-11 16:16:07 <psykose> holy shit
2023-04-11 16:16:10 <psykose> people really love that thing
2023-04-11 16:16:23 <psykose> eventually i just went and did it
2023-04-11 16:16:24 <pj> you have no idea
2023-04-11 16:16:35 <psykose> idk if it even works to be honest with you
2023-04-11 16:16:44 <psykose> it would require having an aws account to actually test :p
2023-04-11 16:16:50 <pj> I can
2023-04-11 16:17:01 <ikke> afaik it works
2023-04-11 16:17:02 <psykose> but it passes its own tests for the most part, so eh
2023-04-11 16:17:09 <pj> well, my goal adding it was actually for work lol
2023-04-11 16:17:09 <ikke> I tested it the other day
2023-04-11 16:17:12 <psykose> :)
2023-04-11 16:17:21 <ikke> (ofcourse not every single feature)
2023-04-11 16:17:39 <psykose> the -doc thing is a bit scuffed, you just get an error for any usage because it uses groff on its own manpages or whatever
2023-04-11 16:17:45 <psykose> except for just default help which i left in
2023-04-11 16:17:50 <pj> no one uses docs
2023-04-11 16:17:54 <psykose> :)
2023-04-11 16:18:09 <pj> once 3.18 is released I'll ask at $work to test it
2023-04-11 16:18:18 <pj> since we use alpine in aws
2023-04-11 16:18:19 <psykose> but yeah not that hard to keep up to date so i'll just keep doing that
2023-04-11 16:18:58 <pj> would you like to add terraform-switcher? :3
2023-04-11 16:19:26 <minimal> pj: are you using tiny-cloud or cloud-init in AWS?
2023-04-11 16:19:40 <pj> alpine for containers only
2023-04-11 16:20:15 <pj> amazonlinux2 or X distro but never alpine for EC2 and others
2023-04-11 16:20:22 <psykose> classic 10mb golang binary that does one thing
2023-04-11 16:20:43 <pj> yeah, need to riir that
2023-04-11 16:21:01 <psykose> that would just be 5mb :p
2023-04-11 16:21:12 <pj> that's 50% of space saved
2023-04-11 16:21:33 <pj> and downloading 300 different crates during build
2023-04-11 16:23:55 <pj> ikke: re: gitlab, upgrading from 13.12.15 to 14.0.12 and from that to 14.3.6, gitlab was confused and did not see background migrations, had to run gitlab-rake db:migrate manually and after that it noticed that it had stuff to do
2023-04-11 17:00:44 <PabloCorreaGomez[m]> ikke: it seems like the appstream generator is crashing again for a while. But I cannot reproduce the problem locally. I suspect it's triggered in the server because of the incredible amount of redundancy
2023-04-11 17:01:39 <PabloCorreaGomez[m]> Is there any chance that you can debug it, or give me access to the container so that I can do it? It probably needs some debug build of appstream-generator and possibly some libraries
2023-04-11 17:02:17 <PabloCorreaGomez[m]> Otherwise, dirty hack would be to limit cores in the compose. Would you be ok with me sending a MR and you deploying it just to see what happens?
2023-04-11 17:02:45 <PabloCorreaGomez[m]> I'd prefer the clean solution, but I understand if you don't want to debug or cannot give me access
2023-04-11 17:03:31 <psykose> limiting cores sounds fine if it works
2023-04-11 17:04:51 <PabloCorreaGomez[m]> It's more likely to work, but still not 100% The thing is that with fewer cores the crashes are often not reproducible, as they happen super seldomly. Thus the problem debugging
2023-04-11 17:05:57 <psykose> this sounds more fun as a rewrite project if you ask me :p
2023-04-11 17:06:11 <psykose> and if you did, it would allow removing the entire D toolchain from alpine
2023-04-11 17:06:26 <psykose> it's only miserably around for this one thing more or less
2023-04-11 17:07:06 <psykose> then like three other small things that are mostly whatever
2023-04-11 17:08:10 <PabloCorreaGomez[m]> It would be a fun rewrite project if I had more time
2023-04-11 17:08:53 <PabloCorreaGomez[m]> I'd rather use https://github.com/hughsie/appstream-glib instead in that case. But that's not by the AppStream maintainer, has less features and breaks the spec in a couple of places. So not great either
2023-04-11 17:11:12 <psykose> still sounds way better
2023-04-11 17:11:19 <psykose> this now reminds me that the D toolchain is now broken on edge
2023-04-11 17:11:22 <skarnet> 
ACTION skims the chat log and understands that psykose wants to remove three miserably small Ds

2023-04-11 17:11:28 <psykose> and i now have to fix it before 3.18
2023-04-11 17:11:28 <psykose> sigh
2023-04-11 17:11:44 <psykose> fucking *64 interfaces
2023-04-11 17:13:18 <psykose> skarnet: is yours one of them
2023-04-11 17:14:20 <skarnet> you know I'm a C person
2023-04-11 17:14:48 <PabloCorreaGomez[m]> I'd still wait for ikke to chim in and say what's the best option for him from the infra pov
2023-04-11 17:15:05 <psykose> the jobs thing would be good
2023-04-11 17:15:13 <psykose> speaking as an infra running person, just not this piece
2023-04-11 17:15:19 <psykose> the rest here is all fluff
2023-04-11 17:19:00 <psykose> (.text._D4core6thread5fiber5Fiber10allocStackMFNbmmZv+0x6f): undefined reference to `mmap64'
2023-04-11 17:19:03 <psykose> time for capital-f fun
2023-04-11 17:31:45 <psykose> rust is also broken by this :D
2023-04-11 17:39:44 <pj> psykose: what did you broke with rust
2023-04-11 17:40:06 <psykose> nothing, but the lfs64 change breaks libstd
2023-04-11 17:41:04 <pj> https://github.com/rust-lang/rust/pull/106246
2023-04-11 17:44:14 <psykose> it's also the libc crate afaict
2023-04-11 17:44:20 <psykose> and that is mostly unfixable
2023-04-11 17:47:29 <pj> stupid architectures
2023-04-11 17:52:10 <mick_ibm> im not familiar with lua but I reached out to the kernel team to see who might have more info about it for ppc64le. not sure what your seg fault looked like but there was one reported in December 2022: https://github.com/openresty/luajit2/issues/186 and this issue also contains more info about ppc64le and lua. Perhaps someone from the kernel team will have more info about lua…
2023-04-11 17:53:27 <mick_ibm> Additionally, I looked at the commit and noticed 2 patches specifically for ppc64le were removed... just curious if the build passes with those patches included? unfortunately the author of those patches no longer seem to be on ibm slack or else I would get more info :/ 
2023-04-11 17:54:41 <pj> I think it's wasteful to investigate that, neither upstream supports ppc64le
2023-04-11 17:56:58 <pj> the fact we use luajit on ppc64le is "because we want to" but we don't have anyone who actually can maintain it
2023-04-11 17:57:20 <pj> it seems that ppc64le was only ever supported with moonjit
2023-04-11 18:02:52 <sam_-> luajit overall is such a mess
2023-04-11 18:03:04 <sam_-> elibrokeit and I spent a while talking about it a few days ago
2023-04-11 18:03:23 <sam_-> I wasn't aware it was broken on ppc64le but i'm not surprised
2023-04-11 18:05:40 <pj> psykose: https://github.com/vlinkz/nixos-appstream-generator
2023-04-11 18:05:42 <pj> :)
2023-04-11 18:05:58 <psykose> good one
2023-04-11 18:08:05 <PabloCorreaGomez[m]> pj, psykose: I'd say a terrible one. Instead of writing a backend for your package format in one of two already-existing applications, try to implement a moving and non-stable pretty big spec from scratch :P
2023-04-11 18:08:46 <psykose> 'moving and non-stable' is the core of the issue
2023-04-11 18:08:51 <psykose> it's some damn app metadata
2023-04-11 18:09:05 <pj> I don't even know what the hell is appstream
2023-04-11 18:09:18 <psykose> it's what lets gnome-software show package descriptions for packages in the distro
2023-04-11 18:09:27 <psykose> with the appwhatever.xml they install
2023-04-11 18:09:54 <PabloCorreaGomez[m]> There's a reason for it, they've come to multiple iterations because it's not just straight-forward
2023-04-11 18:10:24 <PabloCorreaGomez[m]> 1.0 is not that far away, but some things still need polish
2023-04-11 18:11:05 <pj> after 8 years, it's very close to v1
2023-04-11 18:11:06 <pj> :)
2023-04-11 18:12:15 <psykose> AppStream is an agreement between major Linux vendors (i.e. Red Hat
2023-04-11 18:12:18 <psykose> whew
2023-04-11 18:12:20 <psykose> almost kept reading
2023-04-11 18:12:23 <psykose> they made me close that tab real fast
2023-04-11 18:13:25 <elibrokeit> sam_-: luajit should be destroyed, and so should lua :P
2023-04-11 18:13:47 <pj> psykose: have you seen first commit?
2023-04-11 18:13:50 <pj> > A new AppStream generator written in Go, being much faster and more versatile than the old one.
2023-04-11 18:14:49 <PabloCorreaGomez[m]> I'm not sure how any of those comments contribute to a "positive environment for our community"
2023-04-11 18:15:31 <elibrokeit> it is nixos, so you should not have expected positivity to begin with
2023-04-11 18:16:22 <pj> when did nixos come into this
2023-04-11 18:16:36 <pj> we're talking about appstream generator
2023-04-11 18:17:54 <elibrokeit> wasn't it the nixos-appstream-generator that got linked
2023-04-11 18:18:16 <pj> yes, but we're talking about appstream-generator?
2023-04-11 18:18:50 <elibrokeit> then perhaps I misread the discussion
2023-04-11 18:18:56 <orbea> the nixos one is in rust
2023-04-11 18:19:22 <elibrokeit> 
ACTION isn't overly fond of clicking on nixos links

2023-04-11 18:19:23 <orbea> which sounds somehow preferable to go
2023-04-11 18:19:53 <pj> appstream-generator is written in D
2023-04-11 18:20:11 <pj> but it's funny that it started with "written in Go"
2023-04-11 18:20:18 <pj> totally wouldn't help either
2023-04-11 18:20:22 <orbea> ah, thanks for the clarification
2023-04-11 18:20:41 <pj> well, maybe gccgo would be able to compile it
2023-04-11 18:20:49 <psykose> i don't think it matters much what language it's written in
2023-04-11 18:22:07 <psykose> or that discussing it will fix it :p
2023-04-11 18:22:58 <elibrokeit> well, depends on the language -- some of them could really constitute the authors thumbing their noses at the community.
2023-04-11 18:23:05 <elibrokeit> imagine if it was written in ponylang
2023-04-11 18:23:24 <pj> imagine if it was written in hare
2023-04-11 18:24:28 <elibrokeit> I keep forgetting that exists
2023-04-11 18:24:55 <pj> I wish I could
2023-04-11 19:56:46 <ikke> PabloCorreaGomez[m]: Would it help to give you a dev container (on a different host, but it has 48 cores
2023-04-11 20:11:56 <PabloCorreaGomez[m]> ikke: I think it would. It's 2.5x what I have :)
2023-04-11 20:14:19 <ikke> Ok, I'll try to arrange that tomorrow
2023-04-11 20:15:05 <PabloCorreaGomez[m]> Thank you  very much! Would you need something from my side?
2023-04-11 20:17:16 <ikke> an ssh key to use, and if you want, a wireguard public key: https://gitlab.alpinelinux.org/alpine/infra/infra/-/wikis/Alpine-wireguard-VPN
2023-04-11 21:17:29 <psykose> ncopa: 4c7babc7a2e44c4b4bd966a6f2d7b8c15d4517a0
2023-04-11 21:17:38 <psykose> upodated the checksums but didn't enable anything
2023-04-12 05:40:12 <ncopa> whoops. ill fix it
2023-04-12 05:42:36 <ncopa> oh, so I need to bump another pkgrel then
2023-04-12 05:45:13 <psykose> nah
2023-04-12 05:45:17 <psykose> it didn't retry after mine
2023-04-12 05:45:28 <psykose> it'll just be picked up next cycle
2023-04-12 05:45:31 <ncopa> oh, cool
2023-04-12 05:46:17 <ncopa> i kinda hoped to get that kernel fixed, and backported that fix for 3.17 and 3.16 so the ppc64le builder could be fixed
2023-04-12 05:46:38 <ncopa> but maybe I should wait til next kernel version bump
2023-04-12 05:48:03 <pj> mick_ibm: sorry, forgot to respond, I created that MR year ago so might misremember it but I think those patches didn't apply anymore because it was fixed upstream
2023-04-12 05:50:45 <pj> https://github.com/openresty/luajit2/commit/017e15e1ffff75c92a8c5b129068536c40e78205
2023-04-12 05:50:46 <pj> https://github.com/openresty/luajit2/commit/471f8936cbd6aa80a937e375fe53ecadab93696a
2023-04-12 05:56:37 <psykose> ncopa: actually no you do have to bump it, since it started it before retry
2023-04-12 05:56:44 <psykose> nvm haha
2023-04-12 06:01:03 <psykose> did it for you
2023-04-12 06:12:38 <ncopa> awesome thanks!
2023-04-12 06:39:59 <pj> psykose: meanie
2023-04-12 06:40:07 <psykose> how so
2023-04-12 06:40:07 <pj> breaker of rust
2023-04-12 06:40:20 <psykose> is fixed but i had this great idea to push 800 rebuilds too
2023-04-12 06:40:31 <psykose> so uh yes
2023-04-12 06:40:42 <psykose> enjoy waiting for another 300
2023-04-12 06:40:54 <pj> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2023-04-12 06:41:28 <maribu> Hi, now that python 3.12 is approaching (https://lwn.net/SubscriberLink/928437/e1e63ecf61763d9b/), I'd like to raise awareness again for https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189
2023-04-12 06:42:17 <ikke> maribu: unlikely thaat 3.12 will make alpine 3.18 though
2023-04-12 06:42:32 <psykose> not unlikely, impossible
2023-04-12 06:42:35 <psykose> but it's also not relevant
2023-04-12 06:43:12 <maribu> That's great. It would be excellent to get https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189 in prior to the next python update :)
2023-04-12 06:43:19 <pj> am I waiting for cargo specifically or musl?
2023-04-12 06:43:23 <psykose> musl
2023-04-12 06:43:43 <abby> 3.12 is also 5-6 months away, which is half the python release cycle away
2023-04-12 06:44:41 <psykose> sadly all i had was nitpicks, but it's a good and very well tested changed
2023-04-12 06:44:43 <psykose> impressive tbh
2023-04-12 06:45:01 <psykose> ncopa: could you merge https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189
2023-04-12 06:45:14 <maribu> The best case would actually to get https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189 in, then rebuild as many py3-packages as possible, and only afterwards update python. That way systems won't update to the new python package until all py3-packages installed also have a matching rebuild.
2023-04-12 06:46:24 <pj> can you also merge: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/186
2023-04-12 06:46:44 <psykose> that has no point because it's just set in every apkbuild already
2023-04-12 06:47:04 <psykose> and will become default in like less than 2 months
2023-04-12 06:56:35 <pj> > > > wezterm: Build complete at Wed, 12 Apr 2023 06:55:47 +0000 elapsed time 0h 11m 4s
2023-04-12 06:56:41 <pj> psykose: thank you bestie
2023-04-12 06:57:09 <psykose> yw
2023-04-12 11:43:30 <psykose> ncopa: repo updates seem to be very noisy now by what abuild invokes https://img.ayaya.dev/p0XyyfhgEQDC
2023-04-12 11:43:44 <psykose> (for the local repo, etc)
2023-04-12 11:44:00 <psykose> (with new apk)
2023-04-12 12:41:02 <Quillith> My harddrive died and I lost my copy of an app I was porting over to Alpine as well as my local aports branch. I had a merge request going in gitlab, would I be able to pick up where I left off with that or would I need to start from scratch? ELI5 please this is my first time with gitlab or this sort of thing in general. Thanks
2023-04-12 12:45:04 <psykose> whatever you pushed is saved remotely
2023-04-12 12:45:08 <psykose> you can just pull it again
2023-04-12 12:53:35 <Quillith> Thank you!!
2023-04-12 13:25:06 <Newbyte> What do you think of applying the patches suggested here (see "Additional information"): https://gitlab.com/postmarketOS/pmaports/-/issues/2062
2023-04-12 13:26:02 <Newbyte> While this issue was filed in pmaports, the relevant packages sit in aports. The merge requests are not yet merged, so I'm unsure how I feel about it. On the other hand, Guido Günter has a good track record and is paid to work on this in an upstream-first manner, so it is unlikely that he wouldn't finish the patches.
2023-04-12 14:33:37 <mick_ibm> hi all, FYI: just thought id share the update about ppc64le and lua from kernel team… there had been people porting luajit and luajit2 and moonlit for ppc64le however none of them actually have jit support :/ 
2023-04-12 14:39:57 <pj> thanks
2023-04-12 15:02:47 <PabloCorreaGomez[m]> Hi, I have bumped to some issue in alpine, where I tried editing /etc/rc.conf to set rc_group_mode to unified, but seems like OpenRC is ignoring the setting. I solved it by adding cgroups to sysinit runlevel as recommended here: https://github.com/OpenRC/openrc/blob/master/NEWS.md#openrc-035
2023-04-12 15:02:57 <PabloCorreaGomez[m]> Is that something that should be part of alpineconf?
2023-04-12 15:03:17 <PabloCorreaGomez[m]> s/alpineconf/alpine-conf/
2023-04-12 15:04:45 <minimal> the cgroups init.d script READS the value of rc_group_mode and uses it to decide how to mount the cgroups /sys/ accordingly
2023-04-12 15:06:27 <PabloCorreaGomez[m]> Yes, exactly. And I wonder why that's not configured in setup-alpine or equivalent
2023-04-12 15:10:14 <minimal> I guess because utils/programs using cgroups (i.e. docker) are not installed by setup-alpine and therefore cgroups init.d is not enabled
2023-04-12 15:14:48 <PabloCorreaGomez[m]> That makes some sense. I'd have the feeling cgroups are useful in more circumstances, but I have to admit that I only needed them for podman...
2023-04-12 15:19:25 <minimal> the docker init.d defines "need cgroups"
2023-04-12 15:21:40 <PabloCorreaGomez[m]> So does the podman one. But podman is "rootless", so I guess it was never being pulled, since it's just expected to be run in a different way
2023-04-12 15:21:47 <PabloCorreaGomez[m]> I guess I just hit quite a corner-case
2023-04-12 15:24:35 <minimal> likewise the lxc, lxd, nomad, k3s, cgmanager scripts all "need cgroups"
2023-04-12 15:25:25 <umk3[m]> cgroups in runlevel is required for rootless podman, can confirm
2023-04-12 15:27:09 <PabloCorreaGomez[m]> I guess then the one option might be to add a comment as a post-install script? I guess it's not that obvious
2023-04-12 15:28:23 <minimal> what sort of comment? in which post-install script(s)?
2023-04-12 15:29:18 <PabloCorreaGomez[m]> One of the sort of "you need to add cgroups to sysinit runlevel to use rootless podman" in the podman post-install script
2023-04-12 15:29:39 <PabloCorreaGomez[m]> It's one of the main reasons why I understand people use podman. So not totally stupid?
2023-04-12 15:51:11 <minimal> PableCorreaGomez[m]: Not sure I follow, the podman init.d script defines a "need cgroups" which means that cgroups init.d will be started before podman's init.d
2023-04-12 15:52:05 <minimal> or are you referring to the "unified" change to rc_group_mode? How would that impact any other software you might also have installed that uses cgroups?
2023-04-12 21:55:20 <PabloCorreaGomez[m]> minimal: podman is daemonless. Rootless podman is run by a non-root user. The wonderful part of podman is that you don't need to enable a service, there's no service, no daemon. So in principle, for most of the usecases (and for all in rootless podman), there is no need to enable the service
2023-04-12 21:57:53 <PabloCorreaGomez[m]> Still, it needs cgroups configured. So my confusion came from the fact that I modified rc_group_mode, as I wanted an unified cgroup hierarchy, and that change was ignored by openrc
2023-04-12 21:57:58 <minimal> ok, but looking at the service is does do "modprobe" for 2 modules when in rootless mode
2023-04-12 21:58:30 <minimal> as the conf.d/init.d cater for both root and rootless situations
2023-04-12 21:59:41 <minimal> the change wasn't ignored by openrc, what happen is that setting was there to be used by the cgroups init.d service...you just didn't have it running
2023-04-12 22:00:48 <minimal> so it appears that you should (a) edit /etc/conf.d/podman and set "podman_user" to a non-root value, and then enable the podman init.d service :-)
2023-04-12 22:01:54 <PabloCorreaGomez[m]> I guess the problem is that I do not expect to enable a service when using podman
2023-04-12 22:01:59 <PabloCorreaGomez[m]> And that's by design
2023-04-12 22:02:26 <minimal> the description in the init.d says "Listening service that answers API calls for Podman"
2023-04-12 22:04:04 <PabloCorreaGomez[m]> It can be run like that. But that's not how it'd usually be used. Because then "Podman is a daemonless container engine..." (from their website), does not make sense
2023-04-12 22:04:05 <minimal> this would be for the podman-remote package to use I assume...
2023-04-12 22:04:18 <PabloCorreaGomez[m]> Yes, that's one example
2023-04-12 22:04:30 <PabloCorreaGomez[m]> I guess the problem is how to make the need to enable the cgroups discoverable
2023-04-12 22:05:26 <minimal> well I guess the package maintainer could add a postinstall note about either enabling the podman service or enabling the cgroups service
2023-04-12 22:05:34 <PabloCorreaGomez[m]> Otherwise I guess it can be just left like it is. I wasted some time due to my lack of knowledge, and might be better if other people don't do so afterwards. But maybe they'll all know better :P
2023-04-12 22:06:27 <minimal> perhaps talk to the package maintainer to see what he thinks?
2023-04-12 22:07:14 <PabloCorreaGomez[m]> Cool. Know that I managed to convince you, might be easier to convince the maintainer :P 
2023-04-12 22:07:43 <minimal> of course people often ignore messages that appear on screen lol
2023-04-12 22:08:10 <PabloCorreaGomez[m]> Perhaps...
2023-04-13 05:24:45 <psykose> PabloCorreaGomez[m]: the new apk version of 2.14 means apk-polkit-rs needs updating
2023-04-13 05:24:58 <psykose> specifically, apk_name_foreach_matching is removed
2023-04-13 05:25:18 <psykose> new api https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/67f5a753e50da8737dc28b0ea2c2194b21d76fdd
2023-04-13 05:39:22 <psykose> ah, i see there's already an mr
2023-04-13 05:39:26 <psykose> thanks :)
2023-04-13 09:16:47 <donoban> hmm.. "abuild-addgroup: User donoban is not a member of group abuild"
2023-04-13 09:17:12 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094
2023-04-13 09:17:13 <donoban> Am I abuild? Yes I am!
2023-04-13 09:17:34 <psykose> it calls abuild-addgroup in the chroot but the mapped user doesn't have the abuild group i think
2023-04-13 09:17:45 <psykose> s/chroot/sandboxwhateverbwrapthing
2023-04-13 09:18:27 <donoban> it seems a pretty delicated topic
2023-04-13 09:18:37 <psykose> what is
2023-04-13 09:18:45 <donoban> where create that kind of users
2023-04-13 09:19:19 <donoban> well
2023-04-13 09:22:20 <donoban> I dealed with this in the past, because I noticed that rootbld was sharing my host /etc/passwd with the chroot
2023-04-13 09:24:13 <donoban> maybe I have that branch, it added a user with 1000 uid (which from the running user) as 'builder' or something similar
2023-04-13 17:08:30 <ikke> Ariadne: Do you mind me moving secfixes tracker to the alpine/security group (maybe I already asked this, but I forgot)
2023-04-13 18:39:59 <Ariadne> ikke: go for it.  though i am writing some golang stuff that might be a viable alternative
2023-04-13 18:40:54 <ikke> ok, something short-term or longer term?
2023-04-13 18:51:17 <psykose> ncopa: could you merge https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/153? afaict there is nothing else to do there
2023-04-13 18:53:01 <ncopa> i'd prefer to add a test while at it but i dont have time now. I trust you if you say its good
2023-04-13 18:54:04 <psykose> it's the same as all the others :D
2023-04-13 20:50:32 <Ermine> Fwiw, there is some spam in alpine-aports ML
2023-04-13 20:52:10 <ikke> You mean the investment proposal?
2023-04-13 21:00:08 <psykose> the sky is usually blue, yeah
2023-04-13 21:00:35 <ikke> Was just trying to confirm if that's what Ermine was refering to
2023-04-13 21:02:57 <Ermine> ikke: yeah
2023-04-13 21:03:14 <ikke> poof
2023-04-13 21:04:27 <Ermine> psykose: if it was, my Zung score would be smaller
2023-04-13 21:15:21 <psykose> lol
2023-04-13 21:16:41 <psykose> ayy i got a funnynumber/80
2023-04-13 21:22:12 <Ermine> Depending on what you mean, you are either okay or really needing help
2023-04-13 21:59:01 <skarnet> psykose lives in a perpetual quantum state where both are true, and you should never observe
2023-04-13 22:07:26 <Ermine> skarnet: if you observe the state, uncertainty will dissapear
2023-04-13 22:15:58 <skarnet> exactly. Don't do that.
2023-04-14 01:12:18 <Qa> I am installing alpine on a raspberry pi zero w, and setup-alpine fails to show the available ssid and only shows Wifi and Xwifi, but if I manually put the ssid in wpa_supplicant.conf it works fine. also it works fine on boot with the headless overlay, but stops working on reboot. any hints?
2023-04-14 04:36:41 <ncopa> Qa: sounds like a bug. maybe file a bug report?
2023-04-14 04:41:59 <ncopa> i should probably get one of those, but there are nowhere to buy...
2023-04-14 04:43:36 <psykose> haha yeah https://img.ayaya.dev/Z9O5ADDCtyzp
2023-04-14 04:44:02 <psykose> someone has it for fucking 736kr though
2023-04-14 04:44:05 <psykose> jesus
2023-04-14 05:00:14 <ncopa> i found it for 841 nok
2023-04-14 05:00:46 <psykose> i would not buy that haha
2023-04-14 05:01:08 <ncopa> someone is also selling 2 on finn.no for 1000 nok per each. 1800 nok together.
2023-04-14 05:01:08 <psykose> it's what they call uh, daylight robbery :)
2023-04-14 05:01:22 <ncopa> demand and supply
2023-04-14 05:01:38 <psykose> yeah
2023-04-14 05:02:28 <psykose> it's that armhf device :p
2023-04-14 05:03:00 <ncopa> i have a pi 1 here though, but that does not help with debugging wifi on rpi zero
2023-04-14 05:49:58 <psykose> ncopa: think i found a bug in new apk
2023-04-14 05:50:07 <psykose> or abuild
2023-04-14 05:50:13 <psykose> if you build community/dnsdist it fails
2023-04-14 05:50:44 <psykose> or.. did momentarily, that it didn't detect the install= script
2023-04-14 05:51:02 <psykose> ERROR: dnsdist: dnsdist-common.pre-install: install script does not match pkgname or any subpackage
2023-04-14 05:51:04 <psykose> but it's there
2023-04-14 05:51:29 <psykose> not sure how that happens
2023-04-14 05:51:41 <psykose> ah
2023-04-14 05:51:44 <psykose> no, that's my fault
2023-04-14 05:51:46 <psykose> disregard :D
2023-04-14 05:52:03 <psykose> why is that not deterministic *grumble*
2023-04-14 05:52:38 <ncopa> 👍
2023-04-14 05:52:49 <ncopa> i suppose we should tag a new release of abuild also
2023-04-14 05:53:33 <psykose> there's some stuff to fix there if you wanted, but not important for release
2023-04-14 05:53:37 <psykose> mostly rootbld issues
2023-04-14 05:54:10 <psykose> also i fixed the python cache thing
2023-04-14 05:54:24 <psykose>  https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/194 with a trigger to generate it instead
2023-04-14 05:54:29 <psykose> believe it or not, not very slow
2023-04-14 05:59:27 <ncopa> so we generate a python cache with trigger instead.
2023-04-14 05:59:33 <ncopa> thats pretty nice
2023-04-14 05:59:49 <psykose> yeah, it works, and afaict the delete+option works too
2023-04-14 05:59:59 <psykose> i am surprised that it's that simple, so i am wondering if i really missed something
2023-04-14 06:01:00 <psykose> it's not the original 'python3-minimal' proposal or whatever, but i prefer this one as it's more obvious, and i like the apk add !python3-pycompile as an optout
2023-04-14 06:01:15 <psykose> also i found a bug while doing that https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10100
2023-04-14 06:03:46 <psykose> the supposed downside of this is the entire cache is not tracked by apk ever, but that wouldn't conflict on installs unless files/directories are mixed and these names are very different for the two
2023-04-14 06:04:00 <psykose> it also removes a bunch of size from the repo i guess for all the python stuff
2023-04-14 06:04:11 <ncopa> i was thinking of shipping the python cache in separate package, but I guess it makes more sense to save the space on repos
2023-04-14 06:04:13 <ncopa> yeah
2023-04-14 06:04:47 <ncopa> i think we could have some config knob that would allow users to disable python cache at all
2023-04-14 06:04:54 <ncopa> and let it be slower at runtime
2023-04-14 06:05:00 <psykose> that's apk add !python3-pycompile
2023-04-14 06:05:06 <psykose> it will just remove the hook
2023-04-14 06:05:20 <ncopa> ah!  brilliant!
2023-04-14 06:05:45 <psykose> we can make it an /etc config like that mkinitfs trigger too, but seems not much better
2023-04-14 06:05:55 <ncopa> yeah
2023-04-14 06:05:57 <ncopa> this is better
2023-04-14 06:06:16 <psykose> and of course i'd write a release notes entry after
2023-04-14 06:06:26 <psykose> so, i guess all is good, and we go back to the implementation itself
2023-04-14 06:06:30 <psykose> any bugs/edgecases i missed
2023-04-14 06:07:15 <psykose> the tests cover the obvious case, but we could expand that, just not sure what
2023-04-14 06:07:30 <psykose> you are much better at writing that than me, i spent 20 minutes figuring out kyua again :D
2023-04-14 06:11:19 <ncopa> ok, i'll have a closer look at the test then
2023-04-14 06:11:26 <ncopa> also, what do you think about https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/67?
2023-04-14 06:11:42 <ncopa> i'd lke ot have a test for it before adding it, but I dont have time right now
2023-04-14 06:11:47 <ncopa> i think the idea is good ingeneral
2023-04-14 06:12:18 <psykose> i think it's good yeah
2023-04-14 06:12:35 <psykose> the actual scope is 'small', and i can't imagine more than 5 things will use it, but it's complete and does what it says
2023-04-14 06:13:19 <psykose> hm
2023-04-14 06:13:29 <psykose> was it valid with no prio or version?
2023-04-14 06:13:36 <psykose> it' just user-dbus:xyz
2023-04-14 06:13:48 <psykose> and a version would have the same pitfall as cmd:
2023-04-14 06:15:19 <psykose> ah i guess it's implicit? cmd doesn't add anything
2023-04-14 06:16:50 <ncopa> seems to be quite a few: https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Fshare%2Fdbus-1%2F*services&name=&branch=edge
2023-04-14 06:17:20 <ncopa> we'd still need test for it
2023-04-14 06:17:29 <psykose> the services yeah, i just mean what would actually depend on those
2023-04-14 06:17:37 <psykose> it's not very useful as a user, mostly for some packaging
2023-04-14 06:18:01 <psykose> but it's also not possible i think to automate in packaging like this just like cmd: doesn't let you do it very well- there's no priorities if pkgver is appended
2023-04-14 06:18:09 <psykose> so the biggest version thing by luck is just the #1 implementation
2023-04-14 06:18:31 <psykose> currently we have a manual dbus:org.freedesktop.Secrets on three things
2023-04-14 06:18:44 <psykose> and this wouldn't even be able to replace that if it have pkgver suffix because the prio would fail
2023-04-14 06:18:53 <psykose> (or work by luck)
2023-04-14 06:19:17 <psykose> so it's not wrong, and good convenience, but also not perfect
2023-04-14 06:19:26 <psykose> and the latter isn't easily fixable :D
2023-04-14 06:19:33 <psykose> still +1, just not something groundbreaking
2023-04-14 06:22:56 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/180 would be nice small flag change
2023-04-14 06:32:43 <ncopa> we should either have an /etc/abuild.site.conf or /usr/share/abuild/defaults.conf
2023-04-14 06:33:09 <ncopa> so we can update the default flags wit apk upgrade
2023-04-14 06:33:23 <psykose> yeah, i was thinking that
2023-04-14 06:33:43 <psykose> latter sounds better afaict, because it does not get apk protected
2023-04-14 06:33:44 <ncopa> i suppose /usr/share/abuild/default.conf makes more sense
2023-04-14 06:33:47 <psykose> yep
2023-04-14 06:33:47 <ncopa> yeah
2023-04-14 06:34:22 <psykose> what's the source order? after /etc? before? inside /etc itself?
2023-04-14 06:39:59 <ncopa> i think /etc comes last
2023-04-14 06:40:18 <ncopa> defaults first, then override with /etc
2023-04-14 06:41:37 <psykose> sure, works
2023-04-14 06:41:53 <psykose> small issue is just cflags=x overrides anything set, but we can make the default cflags=$cflags , etc
2023-04-14 06:42:23 <ncopa> right
2023-04-14 06:42:31 <ncopa> um
2023-04-14 06:42:34 <ncopa> well
2023-04-14 06:43:06 <ncopa> maybe : ${CFLAGS:= ....}
2023-04-14 06:43:18 <psykose> hmm, no
2023-04-14 06:43:27 <psykose> cflags=$cflags works because /usr site always has then
2023-04-14 06:43:29 <psykose> them*
2023-04-14 06:43:33 <psykose> it's not dirty or anything
2023-04-14 06:44:04 <ncopa> CFLAGS=x abuild ...
2023-04-14 06:44:30 <ncopa> should win
2023-04-14 06:44:32 <psykose> what behaviour do you want that to have
2023-04-14 06:44:34 <psykose> replace or append
2023-04-14 06:44:48 <ncopa> replace i think
2023-04-14 06:45:07 <psykose> hmm
2023-04-14 06:45:08 <ncopa> because if some of the default flags are bad, user should be able to unset
2023-04-14 06:45:14 <psykose> maybe then, not sure of the order
2023-04-14 06:45:26 <ncopa> its a bit confusing indeed :)
2023-04-14 06:45:35 <psykose> personally i find the env flags mostly confusing, since i prefer more hermetic builds where you do things by intent
2023-04-14 06:45:50 <psykose> because of that i never invoke abuild, i have a wrapper over it that exec env -i into it
2023-04-14 06:52:01 <psykose> WhyNotHugo: small fun example https://img.ayaya.dev/sejzgYziiRCI
2023-04-14 06:52:46 <psykose> nothing groundbreaking but small and fun :)
2023-04-14 07:58:19 <psykose> sam_: does compileall --hardlink-dupes have any obvious downsides?
2023-04-14 08:13:22 <skarnet> psykose: Chrome thinks that page is in Danish, which matches my experience of the language pretty well
2023-04-14 08:13:35 <psykose> lol
2023-04-14 08:13:47 <psykose> close
2023-04-14 08:17:06 <ncopa> psykose: do you have any opinion on /usr/share/devhelp? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/87#note_253818
2023-04-14 08:17:19 <ncopa> not sure if its worth to have a separate -devhelp package
2023-04-14 08:17:23 <psykose> new devhelp sounds best as you suggested
2023-04-14 08:17:26 <psykose> imo splits are cheap
2023-04-14 08:17:29 <psykose> and this is not really -doc
2023-04-14 08:23:06 <psykose> that said, it could just be 2-step- there are accidental devhelp in main package already
2023-04-14 08:23:18 <psykose> just that oneliner fixes that. later it can be changed or not.
2023-04-14 08:23:24 <psykose> not wrong to put in -doc over origin
2023-04-14 08:55:09 <ncopa> ok i wonder if we can tag abuild release now? or are there things we absolutely should include?
2023-04-14 08:55:37 <psykose> the python thing
2023-04-14 08:55:50 <ncopa> python cache?
2023-04-14 08:56:12 <ncopa> or python3~$ver dep?
2023-04-14 08:56:13 <psykose> yeah, what we just discussed and you approved
2023-04-14 08:56:29 <psykose> the dep would be also good i guess, but it matters more for edge
2023-04-14 08:56:36 <psykose> up to you, i think it's ready to go already
2023-04-14 08:56:40 <ncopa> if its approved you can merge
2023-04-14 08:57:16 <psykose> the python3~deps look correct and even well tested, so i'm impressed there
2023-04-14 08:57:32 <psykose> and that's it, everything else is new other stuff or rootbld in issues list, so nothing more from me
2023-04-14 08:58:30 <ncopa> is this ready to merge? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/158
2023-04-14 08:58:40 <psykose> yes
2023-04-14 08:58:53 <psykose> i tested the behaviour and it works much better than the old one
2023-04-14 08:59:04 <psykose> you get /home/.../main when building community rootbld
2023-04-14 08:59:09 <psykose> it's one of the bigger pain points :)
2023-04-14 08:59:40 <psykose> of course as you suggested half a year ago the whole thing could use more work and so on- but this is small and a big up for current state
2023-04-14 09:01:51 <WhyNotHugo> psykose: I algo got a ~70MB reductin on updates today.
2023-04-14 09:05:01 <psykose> :)
2023-04-14 09:05:06 <ncopa> awesome
2023-04-14 09:05:19 <ncopa> will probably be more with python cache deleted
2023-04-14 09:05:56 <psykose> as soon as you tag i'll cleanup all the devhelp in aports and merge the python hook
2023-04-14 09:06:25 <psykose> today was really productive! we nailed like over half the abuild issues just like that
2023-04-14 09:06:38 <psykose> (over half in terms of what's in my head, not the open issue list)
2023-04-14 09:06:55 <ncopa> i would like to have the /use/share/abuild/default.conf includeded too, but probably not today
2023-04-14 09:07:20 <ncopa> this is related the default.conf: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/113
2023-04-14 09:07:29 <psykose> i think you should write it (when time), just a small thing
2023-04-14 09:07:54 <psykose> also i kinda like the thing i did with the conditional cat >> in abuild directly for specific flags, that makes it much easier to set stuff per architecture
2023-04-14 09:08:08 <psykose> so allow default.conf to allow that and not do something weird :p
2023-04-14 09:13:19 <ncopa> abuild-3.11.0_rc1 pushed to aports
2023-04-14 09:13:24 <psykose> okie
2023-04-14 09:13:28 <ncopa> lets hope it does not blow up in out face
2023-04-14 09:18:41 <psykose> yeah
2023-04-14 09:18:45 <psykose> let's hope :)
2023-04-14 09:18:59 <ovf> is there a more entertaining/complete dashboard than https://build.alpinelinux.org/ ?
2023-04-14 09:21:48 <ncopa> i'd like that to be more mobilefriendly :)
2023-04-14 09:22:25 <ncopa> and i'd like a favicon with a green checkmark when all builders are idle, yellow when someont is building and red if somethign failed
2023-04-14 09:23:38 <ncopa> psykose: thank you alot for the help with abuild
2023-04-14 09:23:42 <ovf> do you really want the status indication across all branches and arches?
2023-04-14 09:24:16 <pj> why not
2023-04-14 09:24:32 <pj> <ovf> "is there a more entertaining/..." <- yes, install mqtt client and connect yourself
2023-04-14 09:24:42 <psykose> ncopa: np <3
2023-04-14 09:24:54 <ncopa> i want 3 status indications: one for all branches/arches, one per branch and one per arch
2023-04-14 09:25:04 <psykose> i usually use https://ptrc.gay/alpinebuild/ but it's even worse on mobile
2023-04-14 09:25:35 <psykose> anyway the repo is https://gitlab.alpinelinux.org/alpine/infra/build-server-status
2023-04-14 09:25:42 <psykose> ikke was doing stuff to improve it then didn't finish it
2023-04-14 09:25:46 <psykose> should probably wait for that first
2023-04-14 09:26:02 <ncopa> i've been thinking of rewrite it with vue or something
2023-04-14 09:26:08 <psykose> i don't think that's much better
2023-04-14 09:26:24 <psykose> those weird js framework websites aren't good :p
2023-04-14 09:26:30 <psykose> you're supposed to be older than me dammit
2023-04-14 09:26:55 <psykose> the main issues you outlined with the existing aren't because of what it's built with, it's just that it doesn't have that
2023-04-14 09:27:09 <psykose> making it better on mobile for instance is mostly fixing the css a bit
2023-04-14 09:27:29 <ikke> psykose: to be fair, I did finish what I was working on 
2023-04-14 09:27:36 <psykose> you never deployed it!
2023-04-14 09:27:37 <psykose> send it
2023-04-14 09:27:42 <ikke> It is deployed 
2023-04-14 09:30:16 <psykose> ah
2023-04-14 09:30:20 <psykose> right
2023-04-14 09:30:25 <psykose> it was just not very visual
2023-04-14 09:30:27 <psykose> did fix the referest
2023-04-14 09:30:29 <psykose> refresh
2023-04-14 09:30:55 <ikke> Yes, and counters for the progress 
2023-04-14 09:31:02 <ikke> Rather than just percentage 
2023-04-14 09:31:37 <psykose> yeah
2023-04-14 09:31:42 <psykose> sorry i completely forgot :D
2023-04-14 09:31:53 <psykose> guess it's open season then for someone to spruce up the css
2023-04-14 09:32:48 <ovf> ok, despite my dislike for terminal uis, mqttui -b mqtt://msg.alpinelinux.org:1883  is kind of okay (but fundamentally i want the full (recent?) history, which the msg. thing doesn't provide)
2023-04-14 09:37:54 <ncopa> i'd like to write a backend that converts the mqtt messages to http server side events
2023-04-14 09:38:03 <ikke> There is a go service now in the back 
2023-04-14 09:38:25 <ncopa> i have to go
2023-04-14 09:38:48 <ikke> That caches the last 3 messages (just to implement what's necessary for the current functionality) 
2023-04-14 09:38:55 <ikke> But we can expand it 
2023-04-14 09:41:26 <psykose> i don't think there's a need to expand it really
2023-04-14 09:41:31 <psykose> like, the current site works fine for what it is
2023-04-14 09:41:46 <psykose> not much else to do there except make it look pretty
2023-04-14 09:42:01 <psykose> the part where we could expand it, is to replace it entirely with something more useful with history
2023-04-14 09:42:13 <psykose> https://build.voidlinux.org/
2023-04-14 09:42:16 <psykose> https://build.voidlinux.org/waterfall
2023-04-14 09:42:25 <psykose> this is at least 50 million times more useful, with that aspect instead
2023-04-14 09:42:41 <psykose> but this is so far from the current design they are apples and oranges, you can't really slowly expand into something like that
2023-04-14 09:42:54 <psykose> so if it's wanted, it would make some sense to kind of start more 'fresh' if you wanted it
2023-04-14 09:50:51 <ikke> http://build.postmarketos.org/
2023-04-14 09:51:30 <psykose> yeah, that's pretty good
2023-04-14 09:51:42 <psykose> it also looks 0% like ours, so it's kinda what i mean innit
2023-04-14 09:52:01 <psykose> ofc we keep the inputs and stuff and expand existing- but the design of the site we kinda scrap to make that
2023-04-14 09:52:24 <psykose> it's also easier for people to see what's up with the repos
2023-04-14 09:52:30 <psykose> in ours nobody knows anything :D
2023-04-14 10:57:26 <ovf> looks like community/pidgin would be better off with renaming its subpackages s/liburple-/purple-/ as every other libpurple extension is purple- (which is the customary naming scheme for them in the upstream)
2023-04-14 10:58:55 <psykose> is there an actual benefit aside from breaking the name and keeping the old compat name forever anyway
2023-04-14 11:01:27 <ovf> just the usual things like uniformity (e.g. `apk list purple-\*`)
2023-04-14 11:01:49 <psykose> you mean bonjour/xmpp right
2023-04-14 11:02:37 <ovf> yep. i can see why they ended up being libpurple-* historically, and i agree the added provides= is unfortunate
2023-04-14 14:06:29 <psykose> ncopa: urg, there was something i completely forgot about
2023-04-14 14:06:35 <psykose> there is nothing to remove pycache on uninstalls
2023-04-14 14:06:40 <psykose> and there's no good way to make that
2023-04-14 14:08:17 <psykose> it's possible to 'do' it by just deleteing as part of the trigger, but there's no way to make the trigger accurate to only the removal, so it kinda deleted+regens everything per anything removed/added in python
2023-04-14 14:10:28 <psykose> i guess we should do the autosplitting method instead since that definitely works, with a new base-package
2023-04-14 14:10:47 <psykose> i'll just revert this for now because i don't think it'll work with every trigger taking an extra 5 seconds on any py3- added
2023-04-14 14:36:24 <psykose> yeah, i reverted, should have a think some other time more deeply, probably not this release
2023-04-14 14:36:40 <psykose> you should also look at https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10101 
2023-04-14 15:58:37 <Hello71> "theoretically it is possible to add a hook to compile bytecode on install, but the problem is properly tracking those files to remove them later." https://gitlab.alpinelinux.org/alpine/aports/-/issues/11906#note_192289
2023-04-14 15:59:33 <PabloCorreaGomez[m]> psykose: any luck with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/45972?
2023-04-14 16:12:43 <ncopa> 5 secomds to generator pycache? On what machine? Raspberry pi zero?
2023-04-14 17:13:47 <tomalok> still problems with MR rebasing?
2023-04-14 17:14:32 <ikke> yep
2023-04-14 17:14:48 <tomalok> :'(
2023-04-15 07:33:42 <psykose> ncopa: any, because it would delete effectively the whole tree and fully regenerate it every time
2023-04-15 13:55:27 <adhawkins> My 'edge' based VM has thrown up quite a large number of updates over the last few days. Is there a big transition going on, or is it just normal updates?
2023-04-15 13:56:42 <ikke> lots of rebuilds with a new flag that should result in smaller binaries
2023-04-15 13:57:14 <psykose> every complaint adds another 100 rebuilds
2023-04-15 13:57:22 <psykose> /s
2023-04-15 13:57:31 <adhawkins> Ah ok. Thanks ikke. 
2023-04-15 13:57:33 <pj> standard rebuild whenever a library has new version
2023-04-15 13:57:37 <psykose> i'll probably save the rest for gcc13
2023-04-15 13:57:41 <psykose> lots of stuff is quite stale
2023-04-15 14:02:01 <adhawkins> Ok, will take a snapshot of the VM before updating as usual. Thanks all.
2023-04-15 18:31:23 <ikke> tomalok: https://gitlab.com/gitlab-org/gitlab/-/issues/407115
2023-04-15 18:31:39 <ikke> (see the video)
2023-04-15 22:03:33 <handlerug> is the version lag intended? https://a.uguu.se/CWLlgHwi.png
2023-04-15 22:11:25 <psykose> yeah i intentionally held everything back until i get paid
2023-04-15 22:11:32 <psykose> (more seriously the queue was huge so it just takes a while)
2023-04-15 22:13:12 <psykose> the x86_64 builder is also pretty slow compared to the arm ones
2023-04-15 22:14:30 <handlerug> huh
2023-04-15 22:14:43 <handlerug> yeah I looked at the commit date and was like "that's too slow to be true"
2023-04-15 22:15:06 <handlerug> thanks for explaining
2023-04-15 22:16:13 <psykose> you can always look at https://build.alpinelinux.org
2023-04-15 22:38:32 <andypost[m]> Looking at build.a.o it looks ppc builder also spending lots of time uploading instead of building 
2023-04-15 22:42:12 <psykose> yeah it's kinda stuck
2023-04-15 22:51:59 <andypost[m]> no, it's just very slow on upload (takes hours)
2023-04-15 23:09:02 <psykose> yeah
2023-04-15 23:14:06 <pert> hi Alpine devs, sorry to bother you. I was wondering if when you get the chance, if you could please look into enabling DNSSEC and DANE for alpinelinux.org? Please let me know if I can be of any assistance. thank you
2023-04-15 23:14:33 <pert> some highly relevant examples of services with DNSSEC + DANE enabled include OFTC and musl libc
2023-04-15 23:16:09 <pert> furthermore, if you publish your release signing keys in DNS with OPENPGPKEY records, folks will be able to ascertain the validity of your keys through DNSSEC without doing the traditional Web of Trust/keysigning parties. I think this is the greatest potential benefit of all
2023-04-15 23:17:54 <Habbie> pert, are you aware of any software to benefit from OPENPGPKEY?
2023-04-15 23:18:22 <psykose> is it security roleplaying hour again
2023-04-15 23:18:28 <pert> yes, GnuPG can use it and if the zone is signed, set the trust information appropriately. I'm almost certain Sequoia PGP can use it too, but I haven't used it personally
2023-04-15 23:18:57 <psykose> last someone checked it wasn't possible because of the dns provider not supporting it
2023-04-15 23:19:24 <Habbie> indeed, linode does not do it
2023-04-15 23:19:30 <Habbie> https://www.linode.com/community/questions/158/is-dnssec-going-to-be-supported
2023-04-15 23:20:51 <pert> there are free of charge DNS providers that support it, maybe you'd like to switch? I know that's a lot to ask, so if it's not a priority that's cool, I'm just spitballing ideas
2023-04-15 23:22:24 <pert> I like deSEC, they're non-profit. anyway, thanks for thinking about it with me :)
2023-04-15 23:22:42 <Habbie> desec is good people
2023-04-15 23:24:25 <pert> I donated $10 to them, I'm so glad I found them
2023-04-15 23:24:50 <psykose> this looks pretty good
2023-04-15 23:25:02 <psykose> i was just lazily used HE myself for the most part
2023-04-15 23:27:24 <Habbie> pert, https://github.com/PowerDNS/pdns/issues/9418 :)
2023-04-15 23:27:47 <Habbie> (desec reporting a problem with OPENPGPKEY)
2023-04-15 23:28:05 <Habbie> they're excellent bug reporters https://github.com/PowerDNS/pdns/issues?q=author%3Apeterthomassen
2023-04-15 23:30:18 <psykose> some days i'm upset at the internet
2023-04-15 23:30:30 <Habbie> other days you stay outside?
2023-04-15 23:30:33 <psykose> other days i see people can just "ping the author of the standards document on twitter" and get a response in 5 seconds
2023-04-15 23:30:38 <psykose> :D
2023-04-15 23:30:40 <Habbie> hah
2023-04-15 23:30:46 <Habbie> that's paul wouters, who then showed up in the thread
2023-04-15 23:30:50 <psykose> yup
2023-04-15 23:30:50 <Habbie> and made me upset at the internet again ;)
2023-04-15 23:31:30 <Habbie> but overall the thread is happy, with a fix ending up in dnspython in the end
2023-04-15 23:31:47 <Habbie> anyway, desec, good people
2023-04-15 23:32:01 <Habbie> i'd probably let them do my DNS if i wasn't dogfooding
2023-04-15 23:32:13 <psykose> :)
2023-04-15 23:33:43 <psykose> ikke: i forget what the real linode dns utilisation was (since we automate above it with tf a  bit), how hard would it really be to move somewhere?
2023-04-15 23:38:20 <pert> deSEC has multiple ways to import DNS records from the previous provider, can't say I've used it
2023-04-15 23:41:51 <psykose> the records don't matter, they're all in terraform anyway
2023-04-15 23:42:06 <psykose> more or less
2023-04-16 02:12:58 <sam_> psykose: did you build LO ok with new icu
2023-04-16 02:18:41 <psykose> haven't tried as someone had the great idea to build a 'minimised data file'
2023-04-16 02:18:52 <psykose> so with this 'minimised data file' in the build a bunch of tests fail
2023-04-16 02:19:07 <sam_> do you ever hate what we do
2023-04-16 02:19:18 <psykose> i want to jump off a bridge
2023-04-16 02:38:05 <sam_> :))
2023-04-16 03:02:16 <skarnet> psykose is a much better person than I am
2023-04-16 03:02:44 <skarnet> when I encounter that kind of thing I want to push *other people* off a bridge
2023-04-16 03:03:32 <minimal> psykose: can I please have my data file back now? ;-)
2023-04-16 03:42:05 <sam_> psykose: new ncurses snapshot out, upgraded to that, testing vim now.
2023-04-16 03:42:07 <sam_> psykose: filed https://github.com/OpenRC/openrc/issues/619 for openrc issue
2023-04-16 03:42:13 <psykose> tmux is still broken
2023-04-16 03:42:19 <sam_> amazing
2023-04-16 03:42:22 <psykose> didn't file anything yet though because i am too lazy to uh
2023-04-16 03:42:25 <psykose> get it to print anything
2023-04-16 03:42:28 <sam_> do it 4 me bby
2023-04-16 03:42:31 <sam_> dont make me suffer
2023-04-16 03:42:33 <psykose> it just exits and breaks the terminal
2023-04-16 03:42:42 <psykose> server debugging is annoying
2023-04-16 03:42:51 <psykose> ok fine
2023-04-16 03:42:52 <psykose> i will spend
2023-04-16 03:42:56 <psykose> 5 mintues on it
2023-04-16 03:42:58 <sam_> i cant even hit it on my main machine, only my work laptop lol
2023-04-16 03:46:57 <psykose> yep
2023-04-16 03:46:59 <psykose> more tparm
2023-04-16 03:47:11 <psykose> https://img.ayaya.dev/IBwEoLLIOfOK
2023-04-16 03:47:39 <psykose> s is the output of tty_term_ptr2
2023-04-16 03:47:49 <psykose> https://img.ayaya.dev/QqSk9A5vxGz4
2023-04-16 03:48:01 <psykose> https://img.ayaya.dev/Pc9in63KoGOp
2023-04-16 03:49:51 <psykose> you know more than me prolly
2023-04-16 03:53:31 <sam_> i actually dont know shit here, there's a few things i think of as forbidden disgusting unix lore 
2023-04-16 03:53:35 <sam_> curses/lex/yacc
2023-04-16 03:53:43 <sam_> every time i have to interact with any of them i feel sick
2023-04-16 03:55:39 <psykose> i'm sure someone else will figure it out
2023-04-16 03:55:43 <psykose> just gotta open an issue
2023-04-16 03:56:45 <sam_> cant wait for dickey to decide every application uses ncurses ever is wrong
2023-04-16 03:59:42 <psykose> bridge rope etc etc
2023-04-16 04:06:59 <sam_> 100%
2023-04-16 04:07:01 <sam_> thx for doing that
2023-04-16 04:07:03 <sam_> im now dying over zfs
2023-04-16 04:07:07 <sam_> because it ate my data again
2023-04-16 04:07:09 <sam_> https://github.com/openzfs/zfs/issues/14753
2023-04-16 04:07:24 <sam_> there's a long ongoing story with this involving sparse files: https://github.com/openzfs/zfs/issues/11900
2023-04-16 04:07:40 <sam_> starting with "why does sams go segfault"
2023-04-16 04:15:45 <psykose> ty, also reverted the commit
2023-04-16 04:16:15 <psykose> classic zfs moment
2023-04-16 04:16:21 <psykose> i've lost data to btrfs 0 times
2023-04-16 04:16:24 <psykose> L + ratio
2023-04-16 04:39:44 <sam_> cruel
2023-04-16 11:08:58 <adhawkins> My version of dabuild is segfaulting trying to build checksums. Does it need to be rebuilt? I'm using an image built by panekjdev
2023-04-16 11:10:51 <adhawkins> https://termbin.com/clept
2023-04-16 11:24:12 <adhawkins> I've reverted to using the 'real' dabuild, which seems to get the container image from registry.alpine.org. That seems to be working.
2023-04-16 11:32:01 <adhawkins> Now getting the same thing trying to run the CI stuff locally. This is the command I use.
2023-04-16 11:32:17 <adhawkins> docker run --rm -e CI_PROJECT_DIR=/home/andy/alpine-packaging/aports -e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master -e CI_MERGE_REQUEST_PROJECT_URL=upstream  -v /home/andy:/home/andy -w `pwd` alpinelinux/alpine-gitlab-ci:latest /usr/local/bin/build.sh
2023-04-16 11:32:20 <adhawkins> Have those images moved too?
2023-04-16 11:35:49 <ikke> alpinelinux/alpine-gitlab-ci:latest is still there
2023-04-16 11:43:56 <psykose> doesn't look like it segfaults to me
2023-04-16 15:22:29 <pj> <adhawkins> "My version of dabuild is..." <- most likely outdated image
2023-04-16 15:41:06 <psykose> i can't think of anything that would just segfault for no reason
2023-04-16 15:41:32 <psykose> new dt_relr binaries would segfault on musl without support, but i backported that to like 3.13, and if you ran upgrade it would upgrade musl as part of it obviously
2023-04-16 15:41:40 <psykose> it's not possible for it to be that
2023-04-16 15:41:45 <psykose> and anything else is just completely random :
2023-04-16 16:26:22 <pj> adhawkins: you should use registry.alpinelinux.org/alpine/docker-abuild images since they are now regularly updated
2023-04-16 21:09:35 <adhawkins> pj: I got dabuild sorted. It's ci I'm having an issue with now
2023-04-16 21:10:33 <pj> I know, I was just reassuring that this is the way forward :)
2023-04-16 21:10:52 <adhawkins> Great, thanks. Should be doing that now.
2023-04-16 21:11:28 <adhawkins> https://paste.debian.net/1277550/
2023-04-16 21:43:27 <pj> what host are you running this on?
2023-04-17 05:10:02 <wener> Why /usr/lib/libxml2.so is in libxml2-dev, but libxml2.so.2 is in libxml2 ?
2023-04-17 05:17:08 <ikke> /usr/lib/libxml2.so is a symlink which is only used when building an application
2023-04-17 05:28:27 <wener> But httpd use this symlink, make the default install failed to start
2023-04-17 05:30:19 <ikke> That sounds incorrect
2023-04-17 05:30:49 <ikke> it should use the versioned soname
2023-04-17 05:33:25 <ikke> wener: what httpd are you refering to?
2023-04-17 05:38:37 <wener> apache2
2023-04-17 05:39:16 <wener> cat /etc/apache2/conf.d/proxy-html.conf | grep libxml2 -> `LoadFile	/usr/lib/libxml2.so`
2023-04-17 05:41:35 <ikke> Oh, dynamic loading
2023-04-17 06:27:37 <ncopa> LoadFile /usr/lib/libxml2.so will fail when libxml2 breaks ABI and libxml2.so.3 is out, even if the symlink is provided
2023-04-17 06:28:14 <ncopa> so you need `LoadFile /usr/lib/libxml2.so.2`
2023-04-17 06:29:08 <ncopa> if that was the ABI version the proxy-html was built load
2023-04-17 06:31:46 <ncopa> you cannot dynamically load libxml2.so and expect it to work with future libxml2.so updates, because libxml2.so has no ABI guarantee
2023-04-17 06:32:48 <ncopa> you can load libxml2.so.2 though, because libxml2.so.2 is supposed to be a stable ABI. (If ABI breaks the version should change to libxml2.so.3)
2023-04-17 07:33:29 <adhawkins> pj: Running it on my local debian machine. That's where I've always run it.
2023-04-17 08:45:06 <donoban> any opinion for https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094 ? tl;dr; bwrap needs unsahre user namespace if it's not executed by root (so all others uid/gids different from user id/gid become 'nobody')
2023-04-17 08:48:01 <donoban> a possible fix could be use abuild-sudo for calling bwrap and then become the user again via su or something similar and, in order to fix 'mkusers' at least /etc/passwd|group has to be writable. I will consider mouting the whole chroot as rw, so you can swap a shell in the build process and add missing deps, debug tools etc... 
2023-04-17 08:49:11 <donoban> the only benefit that I see having it read-only is that it avoids errors like moving things outside the $pkgdir... but it should fail also in most case since the build user has no write permissions
2023-04-17 09:38:23 <kunkku> donoban: do you know if rootbld has ever worked with pipewire?
2023-04-17 09:40:10 <kunkku> your comment says "it worked with bwrap 0.4.1" but bwrap devs blame the kernel
2023-04-17 09:40:37 <ovf> while packaging something, i felt like doing -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON so that ccache would work. but it doesn't look like that's used elsewhere in the aports. do people just live without ccache?
2023-04-17 09:54:44 <ptrc> ovf: ccache enabled via /etc/abuild.conf seems to work for me on most projects, including cmake ones
2023-04-17 09:55:15 <adhawkins> Sorted out my CI issue. I assumed 'docker run' would pull the latest image. Seems I was mistaken. I've just pulled the latest one manally, and my CI build runs Ok.
2023-04-17 09:58:18 <ovf> ptrc: it does for me as well, but the project at hand seems to be using pch in a way that makes ccache bail.
2023-04-17 10:07:59 <donoban> kunkku: well it probably worked fine running 'mkuser' outside the bwrapp/chroot, I could test it now
2023-04-17 10:09:43 <ovf> anyway, let's see what the powers say: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46169
2023-04-17 10:09:45 <donoban> the problem is that I had a mix of changes on my local branch and finally sent the mkusers change without realizing that /etc/group was read-only on master
2023-04-17 10:10:09 <kunkku> donoban: after re-reading the comments, I understand the problem is the combination of 1) running 'mkuser' inside bwrap and 2) bwrap no longer being setuid
2023-04-17 10:11:26 <donoban> yes, it could work without setuid or sudo call, but it's pretty weird that it things that root is 'nobody', etc... I suppose that I may break things or tests
2023-04-17 10:11:57 <kunkku> ... and to run mkuser inside bwrap we would need some uid/gid trickery around the bwrap call
2023-04-17 10:12:02 <donoban> thinks*
2023-04-17 10:12:58 <donoban> uhM, well 1 option is just abuild_sudo -> bwrap -> su $(whoami), which it's like setuid it but only for this scope
2023-04-17 10:13:21 <donoban> other could be setup a rootless container setup with /etc/subuid|subgid etc..
2023-04-17 10:14:17 <donoban> but it could ending adding a shadow dependency, so also linux-pam...
2023-04-17 10:21:10 <adhawkins> Since I started using the latest dabuild, I keep getting the following error:
2023-04-17 10:21:22 <adhawkins>  /home/andy/bin/dabuild: 126: DABUILD_PLATFORM: parameter not set
2023-04-17 10:21:29 <adhawkins> '/home/andy/bin/dabuild: 126: DABUILD_PLATFORM: parameter not set'
2023-04-17 10:21:40 <adhawkins> Whoops, sorry for the double.
2023-04-17 10:22:04 <adhawkins> If I explicitly export DABUILD_PLATFORM as an empty string, it works. Shouldn't there be a default for that in the script?
2023-04-17 10:23:49 <ikke> looks like it, yes
2023-04-17 10:24:14 <adhawkins> Happy to raise an issue and a MR if it helps. It's a one-liner fix though...
2023-04-17 10:26:19 <adhawkins> Ah, there's already an MR for it.
2023-04-17 10:26:22 <adhawkins> 3 months old :)
2023-04-17 10:26:29 <adhawkins> https://gitlab.alpinelinux.org/alpine/docker-abuild/-/merge_requests/68
2023-04-17 10:27:25 <ikke> merged it
2023-04-17 10:27:34 <adhawkins> Perfect, thanks ikke
2023-04-17 10:28:41 <adhawkins> That works.
2023-04-17 10:55:32 <mqqc> ncopa: hi, I had a small question about the licensing of https://github.com/alpinelinux/aports/blob/master/main/openrc/networking.initd as I'd like to use it in an OpenEmbedded layer; you seem to be the main author, would you be willing to provide a license statement somewhere so I can be sure we are allowed to use it? :)
2023-04-17 11:14:30 <ncopa> mqqc: pushed. 325abf676b41f5ef6772e97aeb8aee673f13c91e
2023-04-17 11:14:48 <mqqc> <3 thank you!
2023-04-17 12:00:49 <ncopa> no issues with apk-2.14.0_rc1 so far?
2023-04-17 12:07:29 <ncopa> are we ready to set up 3.18 builders?
2023-04-17 12:17:25 <fossy> is it the case that aports are not technically under any license? https://gitlab.alpinelinux.org/alpine/aports/-/issues/9074 appears to say so, but i wanted to confirm this is still true..
2023-04-17 12:35:38 <psykose> they are indeed under no licence
2023-04-17 12:49:54 <psykose> not sure if it's just me or if CBUILD=somearch abuild rootbld was broken recently
2023-04-17 16:15:31 <PabloCorreaGomez[m]> ncopa: apk-2.14.0_rc1, we fixed the issue with the polkit, although not sure that's whay you're meaning
2023-04-17 17:29:32 <ncopa> i wondered if there were any issues at all with apk 2.14
2023-04-17 17:34:30 <psykose> i couldn't find anything
2023-04-17 17:34:36 <psykose> well
2023-04-17 17:34:40 <psykose> i got /one/ segfault
2023-04-17 17:35:26 <psykose> https://img.ayaya.dev/Juwyt1HCERnT
2023-04-17 17:35:30 <psykose> not sure what happened there
2023-04-17 17:36:27 <psykose> the ipkg in 		if (ipkg->replaces->num) { is null somehow
2023-04-17 18:58:52 <bl4ckb0ne> psykose: where can I apply to get aports merge rights so I can merge stuff without bothering you
2023-04-17 18:58:59 <psykose> it doesn't bother me
2023-04-17 19:00:31 <psykose> if anything i'm basically a marge bot conceptually
2023-04-17 19:00:34 <psykose> actual useful work? pfft
2023-04-17 19:00:36 <bl4ckb0ne> kek
2023-04-17 19:00:40 <bl4ckb0ne> marge is a bit more rude tho
2023-04-17 19:00:46 <psykose> doubt
2023-04-17 19:00:56 <bl4ckb0ne> and marge's builders are more reliable
2023-04-17 19:01:03 <ikke> But that doesn't mean bl4ckb0ne cannot be added as a developer themselves
2023-04-17 20:31:28 <armeaux> exit
2023-04-17 20:34:47 <randvmb> mesa-libwayland-1.22-queue-2.patch sha512sum changed for mesa APKBUILD, its now 5f961707731d9392acd6f14e54bc965e77c2f8d1c759128ddc2e99abd35d6d06c996369ef71c70cf6cfc58e812265af32276349c2321300c9287aff56013277a
2023-04-17 20:35:00 <psykose> indeed it did
2023-04-18 00:04:22 <sam_> psykose: latest dickeyware update: https://bugzilla.suse.com/show_bug.cgi?id=1210485#c12
2023-04-18 00:05:29 <psykose> yep
2023-04-18 00:05:55 <psykose> tmux still broke though, as it goes
2023-04-18 00:06:32 <sam_> loving this strategy
2023-04-18 00:14:10 <psykose> what if we made newlinux and it had no ncurses
2023-04-18 08:44:48 <ncopa> morning
2023-04-18 08:45:06 <ncopa> intend to get the 3.18 builders up today
2023-04-18 08:45:32 <ncopa> need to have abuild in proper shape before I do so
2023-04-18 08:45:56 <ncopa> let me rephrase, need to verify that abuild is in proper shape
2023-04-18 08:46:11 <psykose> seems to work fine to me
2023-04-18 08:46:14 <psykose> well
2023-04-18 08:46:34 <psykose> you could add https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189, but that's about it
2023-04-18 08:46:40 <ncopa> im looking at the CFLAGS/CXXFLAGS etc
2023-04-18 08:46:48 <ncopa> seems like we dont have the format-security on edge buidlers
2023-04-18 08:49:02 <psykose> we do
2023-04-18 08:49:11 <psykose> unless the abuild.conf is as always 'updated'
2023-04-18 08:49:15 <psykose> and doesn't merge
2023-04-18 08:49:29 <psykose> i guess that is a thing to fix
2023-04-18 08:53:21 <ncopa> i am not 100% confidedn python3 dep is a good idea. https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189#note_302551
2023-04-18 08:54:12 <ikke> Is it possible to move the builder specific stuff to ~/.abuild/abuild.conf?
2023-04-18 08:54:28 <ncopa> ikke: i was thinking in those lines yes
2023-04-18 08:54:44 <ncopa> was thinking about a /usr/share/abuild/defaults.conf
2023-04-18 08:54:47 <psykose> i'm not sure i understand the caution there
2023-04-18 08:55:37 <psykose> most py3- packages already depend on python3
2023-04-18 08:55:47 <psykose> you already get it when installing the vast majority of them
2023-04-18 08:55:56 <psykose> just.. not one locked to the correct version, i.e. broken dependency
2023-04-18 08:56:14 <psykose> they already have the dep, just not a constrained one in aports
2023-04-18 08:56:20 <psykose> it doesn't affect any of the cases you list
2023-04-18 08:56:40 <ncopa> what I wonder is if people use docker's python:3.*-alpine and apk add py3-* packages
2023-04-18 08:56:50 <psykose> this change yields no difference whatsoever
2023-04-18 08:57:00 <psykose> they get python3 with and without it
2023-04-18 08:57:37 <psykose> (for almost everything, some things are missing explicit python3 i guess)
2023-04-18 08:57:40 <ncopa> and i theory they shouldnt use py3-* package with their python build
2023-04-18 08:57:49 <psykose> more or less, idk if it works
2023-04-18 08:57:51 <psykose> lemme see
2023-04-18 08:58:01 <ncopa> i did test on apk info --depends py3-zulip
2023-04-18 08:58:09 <ncopa> which does not dep on python3
2023-04-18 08:58:39 <psykose> https://img.ayaya.dev/7SQtjnk36nwJ
2023-04-18 08:58:43 <psykose> you straight up cannot do that anyway
2023-04-18 08:58:53 <psykose> because the python version doesn't match
2023-04-18 08:59:14 <psykose> ah, doesn't even when it does
2023-04-18 08:59:22 <psykose> you can't import them from the python in the 'docker image' at all
2023-04-18 08:59:49 <psykose> https://img.ayaya.dev/pMmHX2EipRwm
2023-04-18 08:59:53 <psykose> they don't read usr/lib
2023-04-18 09:00:44 <psykose> so now there are 3 reasons why this is not something anyone would've been affected by: 1: it doesn't work 2: even hacked, the version might not match 3: the python dep is pulled for most things already and that doesn't change
2023-04-18 09:00:51 <psykose> emphasis on, uh, 1
2023-04-18 09:01:08 <ncopa> ok. can  you please comment that on the issue
2023-04-18 09:01:15 <ncopa> i just wanted to make sure
2023-04-18 09:36:11 <ncopa> re py cache, what if we just split it to a -pycache subpackage
2023-04-18 09:36:56 <ncopa> similar to the trigger, you woudl need to apk add !python3-pycache to disable install of pycache
2023-04-18 09:37:10 <ncopa> or maybe opposite
2023-04-18 09:37:22 <ncopa> off by default
2023-04-18 09:58:38 <psykose> there is already an mr for that
2023-04-18 09:58:48 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/182
2023-04-18 10:00:00 <psykose> for python3 itself i already manually split it (because it ships opt1/2 too), and install -0 by default with optout, so it's 10mb smaller
2023-04-18 10:00:02 <psykose> i guess
2023-04-18 10:05:32 <ncopa> do you think -pycache or -pyc is better suffix?
2023-04-18 10:06:35 <psykose> indifferent
2023-04-18 10:06:57 <ncopa> pycache is more clear what it is, pyc is shorter
2023-04-18 10:07:17 <psykose> we don't name it -development :p
2023-04-18 10:07:22 <psykose> the files are also .pyc
2023-04-18 10:07:26 <psykose> but aside from that i don't think it matters
2023-04-18 10:07:28 <ncopa> ok
2023-04-18 10:07:41 <ncopa> lets keep what is proposed then
2023-04-18 10:07:46 <ncopa> pyc is fine i gues
2023-04-18 10:09:11 <ncopa> do we want a options="keeppyc" to avoid warning of pycache found but name does nto end with -pyc ?
2023-04-18 10:09:32 <psykose> sure
2023-04-18 10:09:48 <ncopa> i dont think we have it for init.d and others
2023-04-18 10:10:39 <psykose> if it's a warning it doesn't fail so it's implicit i guess
2023-04-18 10:32:44 <ncopa> i don think we need the depends="python3~$pyver" in -pyc packages?
2023-04-18 10:33:13 <ncopa> i suppose technically we can keep them as the py cache is tied to the python interpreter
2023-04-18 10:35:11 <ncopa> i guess the pychache is not a blocker for bootstrapping the builders. we need to rebuild the py3-packages anyway, right?
2023-04-18 10:37:49 <psykose> nah
2023-04-18 10:37:51 <psykose> doesn't need depends
2023-04-18 10:37:59 <psykose> and no it's not a blocker
2023-04-18 10:38:04 <psykose> it doesn't matter for the release either
2023-04-18 10:38:07 <psykose> it's mostly an edge thing
2023-04-18 10:38:11 <psykose> because edge does the rebuild
2023-04-18 10:38:15 <psykose> where stuff is broken in the middle
2023-04-18 10:38:26 <ncopa> i think it would be nice to have -pyc packages for 3.18
2023-04-18 10:38:45 <ncopa> and reduce the python package size
2023-04-18 10:51:31 <psykose> ugh, i think i figured out that index validation failure thing and why rootbld CBUILD fails sometimes
2023-04-18 10:51:40 <psykose> new apk gets confused with the indexes sometimes for some reason
2023-04-18 10:52:23 <psykose> if you mix `apk update` and `CBUILD=something abuild rootbld` a few times, the APKINDEX's that are saved are kinda flipped or something
2023-04-18 10:52:39 <psykose> so then when you do CBUILD= and it tries to install e.g. the riscv64 --arch, it actually uses the x86_64 index and installs that
2023-04-18 10:52:54 <psykose> or opposite on host and fails the signature check somehow, idk
2023-04-18 10:53:14 <psykose> and then you get UNTRUSTED signature
2023-04-18 10:53:35 <psykose> i think you can reproduce this with just, rm /var/cache/apk/APKINDEX.*, CBUILD=riscv64 abuild rootbld, apk update
2023-04-18 10:56:52 <psykose> it even installs the wrong apks so it replaced /etc/apk/keys with the other arch which is why everything fails signatures after
2023-04-18 10:57:14 <psykose> seems like a bug in apk --arch or some cache thing
2023-04-18 11:02:41 <psykose> /usr/lib/libcairo-gobject.so.2.11708.0: ELF 64-bit LSB shared object, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, stripped
2023-04-18 11:02:42 <psykose> yep
2023-04-18 11:02:52 <psykose> i randomly replaced random binaries on my disk with riscv64 in an upgrade after
2023-04-18 11:02:52 <psykose> :D
2023-04-18 11:03:08 <psykose> seems to be a new-apk bug
2023-04-18 11:03:13 <psykose> but only paired with --arch stuff
2023-04-18 11:36:15 <psykose> ncopa: do you mind trying to debug this a bit ^? i can't seem to get it clearly figured out and it scares me a bit
2023-04-18 11:37:25 <psykose> 'just' rm /var/cache/apk/APKINDEX.*, CBUILD=riscv64 abuild rootbld, apk update doesn't break apkindex checksum but it does then further prevent CBUILD=riscv64 from working (it stays x86_64 only in whatever created root)
2023-04-18 11:38:18 <psykose> hm
2023-04-18 11:38:22 <psykose> downgrading apk doesn't fix it
2023-04-18 11:38:33 <psykose> i think this broke in the rootbld changes, but we only changed clearenv
2023-04-18 11:38:43 <psykose> the arch thing is simple enough to rule out
2023-04-18 11:38:44 <psykose> weird
2023-04-18 11:39:47 <psykose> the installed indexes become riscv64 ones and apk just uses them
2023-04-18 11:53:16 <ncopa> can someone please review https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/202
2023-04-18 11:53:24 <ncopa> its abuild's default.conf
2023-04-18 11:53:39 <Piraty> `apk list --upgradeable` shows two packages , yet `upgrade -a` doesn't upgrade them
2023-04-18 11:54:15 <psykose> fomit-frame-pointer is not implied everywhere
2023-04-18 11:54:24 <psykose> i wouldn't touch it
2023-04-18 11:56:00 <Piraty> if line breaking with \ allowed to have anything else than space before backslash?
2023-04-18 11:56:05 <Piraty> s/if/is
2023-04-18 11:56:30 <Piraty> L144
2023-04-18 11:58:10 <psykose> yes
2023-04-18 11:59:26 <Piraty> then it's inconsistent at least
2023-04-18 12:07:13 <psykose> what is
2023-04-18 13:04:43 <ncopa> psykose: i think -fomit-frame-pointer was not enabled with -O* in the past, which is why I added it in the early days
2023-04-18 13:04:56 <ncopa> i believe -Os enables -fomit-frame-pointer nowadays
2023-04-18 13:05:05 <ncopa> with eht exception of aarch64?
2023-04-18 13:05:28 <psykose> yes
2023-04-18 13:05:56 <ncopa> so I think we can remove it from our defaults
2023-04-18 13:06:15 <ncopa> if i understand things correctly, it will not be any difference for our edge builders
2023-04-18 13:20:58 <psykose> don't forget to edit the >> abuild.conf in abuild to default.conf instead when you upgrade it
2023-04-18 13:21:10 <psykose> or i can do it
2023-04-18 13:22:41 <ncopa> i will have a look at that
2023-04-18 13:23:23 <psykose> https://img.ayaya.dev/r0x17SXkzshw
2023-04-18 13:24:00 <ncopa> i wonder if we should move that to default.conf
2023-04-18 13:25:04 <psykose> it's conditional
2023-04-18 13:25:30 <psykose> you can't put conditional things in the .conf, nor is there a point for it
2023-04-18 13:25:53 <ncopa> why not? https://tpaste.us/BJMn
2023-04-18 13:28:27 <psykose> carch is defined after default.conf is sourced
2023-04-18 13:30:04 <psykose> it also works perfectly fine as it is
2023-04-18 13:30:08 <ncopa> ok
2023-04-18 13:30:17 <ncopa> lets keep it simple then
2023-04-18 13:31:02 <psykose> (it would somewhat simple to have it in one place, but in this case it would require moving around the define order, since currently it only sets every var after including .conf)
2023-04-18 13:31:07 <psykose> so at least carch would have to come first
2023-04-18 13:31:20 <psykose> and then it somewhat stops making sense
2023-04-18 13:31:30 <psykose> something something shell
2023-04-18 13:32:06 <ncopa> i want to tag a new _rc now
2023-04-18 13:32:31 <psykose> sure
2023-04-18 13:32:38 <psykose> i tagged a million of them for every slight bug
2023-04-18 13:32:40 <psykose> was fun
2023-04-18 13:33:12 <ncopa> a million? no i think you only tagged a thousand.... :)
2023-04-18 13:33:24 <psykose> :D
2023-04-18 13:33:41 <ncopa> but thanks for doing it
2023-04-18 13:33:49 <psykose> yeah, was just doing cleanup
2023-04-18 13:34:05 <psykose> sadly still have that broken rootbld thing from above destroying indexes, but it's not apk related..
2023-04-18 13:34:24 <ncopa> is it a blocker for bootstrapping the builders?
2023-04-18 13:34:41 <ncopa> i can have a look at it when 3.18 builders are building
2023-04-18 13:35:01 <psykose> nope
2023-04-18 13:35:02 <psykose> not at all
2023-04-18 13:45:39 <psykose> guess i'll update it
2023-04-18 13:45:55 <psykose> if the tests passed that is
2023-04-18 13:56:56 <ncopa> i have a fix
2023-04-18 14:00:13 <ncopa> alrighty then, i guess I can bootstrap the builders then
2023-04-18 14:00:27 <psykose> aye
2023-04-18 14:01:29 <ncopa> i think we also should update the abuild.conf on the edge builders
2023-04-18 14:02:09 <psykose> yep
2023-04-18 14:02:17 <psykose> i would but i don't have access to them of course
2023-04-18 14:15:25 <ncopa> hum.. maybe we should keep the JOBS=64 on the edge builders
2023-04-18 14:15:33 <ncopa> instead of $(nproc)
2023-04-18 14:15:57 <psykose> on what
2023-04-18 14:16:07 <psykose> the ones with nproc=80?
2023-04-18 14:16:08 <ncopa> on arm edge builders
2023-04-18 14:16:09 <psykose> what for
2023-04-18 14:16:11 <ncopa> yes
2023-04-18 14:16:30 <ncopa> i think we have that because all builders run at the same time
2023-04-18 14:16:41 <psykose> "that"?
2023-04-18 14:17:04 <psykose> you mean have nproc because all run at the same time? that sounds backwards from what i'm guessing you mean
2023-04-18 14:17:36 <psykose> i would keep 80
2023-04-18 14:17:36 <ncopa> so if all 3 edge builders all run -j80 and there are only 80 cpus
2023-04-18 14:17:48 <ncopa> each build will overload the cpu
2023-04-18 14:17:52 <psykose> there's pretty much nothing that actually runs 80
2023-04-18 14:17:53 <ncopa> and we have CI
2023-04-18 14:17:57 <psykose> ci is another machine
2023-04-18 14:18:01 <ncopa> aha
2023-04-18 14:18:08 <psykose> the thrashing loss is less than 16 idle loss
2023-04-18 14:18:20 <psykose> there are a lot of builds that stay as 80 but alone, because e.g. aarch64 only or whatever
2023-04-18 14:18:22 <ncopa> ok, lets use nproc then
2023-04-18 14:18:29 <psykose> and stuff is skipped on armhf sometimes, etc
2023-04-18 14:18:42 <psykose> like, it's kinda uhh
2023-04-18 14:18:50 <psykose> peaky? there is very little '80 utilisation'
2023-04-18 14:19:00 <psykose> most of the time you get >80 from parallel, or you have an average of.. 3
2023-04-18 14:19:14 <psykose> because nothing uses the 80 jobs (configure tests, 3 source file builds, ..)
2023-04-18 14:19:24 <ncopa> nproc it is now 
2023-04-18 14:19:36 <psykose> so what we're optimising is the in-between part of 'one build kinda runs alone and can use 80 instead of 64 when idle' compared to 'thrashing loss'
2023-04-18 14:19:37 <ncopa> lets keep an eye on the arm builder
2023-04-18 14:19:44 <psykose> and ime, the thrashing loss is less than the -16 moments
2023-04-18 14:19:53 <psykose> so yeah, current has been o
2023-04-18 14:19:55 <psykose> ok*
2023-04-18 14:20:15 <psykose> if we ran CI same machine it would be a bit different
2023-04-18 14:20:21 <psykose> the previous 2x80 machine was a bit of a mess
2023-04-18 14:20:43 <psykose> there was a lot more NUMA issue for some reason, and then we have like =64, and shared between all the ci and everything
2023-04-18 14:20:47 <psykose> we got it to like 500 load all the time
2023-04-18 14:21:08 <psykose> the current 1x80 reaches 300 or whatnot when you push kernels, but it's still faster than the old
2023-04-18 14:21:48 <psykose> and it wouldn't be faster with =64; the thrashing is mostly a small % difference
2023-04-18 14:22:18 <ncopa> JOBS=$(nproc) is fine with me. makes abuild.conf even smaller
2023-04-18 14:22:23 <ncopa> easier to maintain
2023-04-18 14:22:51 <psykose> yeah, just explaining my observations so far more or less
2023-04-18 14:23:20 <psykose> i was building main/ and some community/ for a while to test some stuff a week ago with buildrepo and i averaged a load of 2
2023-04-18 14:23:25 <psykose> with nproc, on that machine
2023-04-18 14:23:26 <psykose> so
2023-04-18 14:23:38 <psykose> on average, nothing uses anything there, until you hit a 1k+ source file c++ build
2023-04-18 14:23:59 <psykose> there's a lot of singlethread limitation from the whole 'abuild overhead' and then configures
2023-04-18 14:24:19 <ncopa> autoconf is extremely inefficient 
2023-04-18 14:24:34 <psykose> it can be sped up a lot with an autoconf cache but that has to be maintained somewhat
2023-04-18 14:24:49 <psykose> e.g. https://github.com/chimera-linux/cports/blob/339c0eef5be61397707170c6789e09fa4c3b5810/src/cbuild/misc/autoconf_cache/arm-linux#L1
2023-04-18 14:25:08 <psykose> skips like half the stuff instantly
2023-04-18 14:35:37 <ncopa> im bootstrapping 3.18 builders now. it means we are in effective feature freeze for build toolchains
2023-04-18 14:43:33 <psykose> except rust
2023-04-18 14:58:22 <psykose> (this time i'll keep it up to date in stable, as that's just how they do it and support it upstream)
2023-04-18 14:58:37 <psykose> not real benefit to freezing it except not being able to keep firefox up to date via doing so
2023-04-18 15:01:40 <psykose> (it's stable via actual compiling wrt not breaking building applications, the actual breakage is practically nil compared to most language compilers)
2023-04-18 15:03:36 <ncopa> ok! all 3.18 builders are bootstrapping aports
2023-04-18 15:04:07 <psykose> when announce to build.a.o
2023-04-18 15:04:27 <psykose> :-)
2023-04-18 15:05:01 <ncopa> one aports is bootstrapped. eg all build-base packages and abuild deps are built
2023-04-18 15:05:30 <ncopa> will probably happen tomorrow
2023-04-18 15:05:47 <ncopa> there are some manual handling of things like bison/flex circular deps
2023-04-18 15:06:20 <psykose> ah, thoose
2023-04-18 15:06:22 <psykose> right
2023-04-18 15:06:27 <psykose> good work!
2023-04-18 15:06:53 <ikke> Wasn't that handled with BOOTSTRAP?
2023-04-18 15:06:54 <ncopa> i have already done those except for x86 and x86_64 which are the last servers
2023-04-18 15:06:57 <ncopa> it is
2023-04-18 15:07:10 <ikke> Or do you mean rebuilding it without BOOTSTRAP
2023-04-18 15:07:10 <ncopa> i have to manually build bison with BOOTSTRAP=1
2023-04-18 15:07:15 <ikke> Yeah
2023-04-18 15:08:14 <psykose> it's an arg named BOOTSTRAP but we do not set it for bootstrap except one thing manually :p
2023-04-18 15:08:24 <psykose> water is dry, etc etc
2023-04-18 15:08:39 <ikke> There are more packages that use it
2023-04-18 15:08:50 <psykose> yeah, small couple
2023-04-18 15:08:57 <psykose> also mostly for ./bootstrap.sh which is different
2023-04-18 15:09:04 <ncopa> yeah
2023-04-18 15:09:21 <ncopa> we should maybe have an APORTS_BOOTSTRAP var or similar
2023-04-18 15:09:43 <ncopa> i have also been thinking of how to handle it automatically, but there is not really any good way
2023-04-18 15:09:45 <ikke> There is ABUILD_BOOTSTRAP as well
2023-04-18 15:09:51 <ncopa> hum
2023-04-18 15:10:11 <ikke> It disables checks globally 
2023-04-18 15:10:18 <ikke> We use it for rv64
2023-04-18 15:10:22 <ncopa> for bison the only thing it does is disable check
2023-04-18 15:10:50 <psykose> two vars for the same thing
2023-04-18 15:10:52 <ncopa> we want build everything that is possible with tests
2023-04-18 15:10:54 <ikke> for git it disables some subpackages 
2023-04-18 15:11:10 <ncopa> its used for ./bootstrap.sh
2023-04-18 15:11:26 <ikke> For curl as well
2023-04-18 15:11:34 <ncopa> so we can bootstrap new architectures without cross-compling the entire universe
2023-04-18 15:12:30 <psykose> ghc should probably be removed from that list then
2023-04-18 15:12:33 <psykose> not sure why it's there
2023-04-18 15:12:39 <ikke> brotli disables dependency on python
2023-04-18 15:14:19 <psykose> hm
2023-04-18 15:14:25 <psykose> ncopa: how did you want -pyc to be default
2023-04-18 15:14:34 <psykose> pyc, install_if="python3 alpine-base" or something
2023-04-18 15:16:25 <ncopa> i was thinking having it off by default
2023-04-18 15:16:37 <ncopa> so you would need to manually apk add pyc
2023-04-18 15:17:56 <psykose> hmm
2023-04-18 15:18:48 <psykose> i guess, but that's not that great an idea considering the startup time impairment and so on
2023-04-18 15:18:58 <psykose> it's trading a bit of diskspace for all that, not much else
2023-04-18 15:22:52 <psykose> ah, *-pyc should also be marked noarch because it warns
2023-04-18 15:23:01 <psykose> https://img.ayaya.dev/5y6rbmTXAC6L
2023-04-18 15:24:59 <ikke> I suppose we haven't measured how much time it saves with and without the pyc files
2023-04-18 15:25:11 <psykose> people have
2023-04-18 15:25:46 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11906#note_232487
2023-04-18 15:25:47 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/182
2023-04-18 15:26:34 <psykose> it sounds small but that is the most basic example possible, and on a desktop computer
2023-04-18 15:26:49 <psykose> and if you type a python command it is on every invocation, it won't keep the cache
2023-04-18 15:27:07 <psykose> so e.g. every python program you run, probably +100ms just waiting extra
2023-04-18 15:27:27 <psykose> worse on slow machines
2023-04-18 15:27:42 <psykose> in itself the split is fine, but it's a bit weird to default-off in a backwards-compatibility way
2023-04-18 15:29:05 <ikke> "or example one of our test suites takes twice as long to run without the system pyc cache."
2023-04-18 15:29:20 <ikke> Sounds like something you want by default
2023-04-18 15:29:39 <psykose> yeah, that case is like the interactive worst case- not a long-running but just spawning a new interpreter repeatedly
2023-04-18 15:29:47 <psykose> each of those pays the cost every time
2023-04-18 15:30:07 <psykose> just wondering what the install_if rule is best as
2023-04-18 15:30:32 <psykose> hm
2023-04-18 15:30:48 <psykose> two layers of indirection should work
2023-04-18 15:31:08 <psykose> python3-pyc, install_if=$pkgname=$pkgver-r$pkgrel, depends=pyc
2023-04-18 15:31:13 <psykose> and then the full exclusion is !python3-pyc
2023-04-18 15:31:19 <psykose> sounds ok to me
2023-04-18 15:31:42 <psykose> and nothing depends on pyc so it won't matter in that name
2023-04-18 15:31:45 <psykose> yeah i'll go ahead with that
2023-04-18 15:40:21 <minimal> no plans to support pyc-only package installs?
2023-04-18 15:42:05 <psykose> ask me in 6 years when i drank enough to forget about this ordeal
2023-04-18 15:42:09 <psykose> but no, that sounds quite silly
2023-04-18 15:42:56 <minimal> s/package/sub package/
2023-04-18 15:43:10 <psykose> i mean it's not workable at all and a huge mess
2023-04-18 15:43:17 <minimal> where someone only wants to install the pyc files to run something
2023-04-18 15:43:27 <psykose> things depends on py3-x
2023-04-18 15:43:39 <psykose> to make it only pull py3-x-pyc and not py3-x itself is uh, shall we say, silly hack
2023-04-18 15:43:43 <psykose> i don't even want to think about it
2023-04-18 15:44:34 <minimal> I guess that worked easier/better when pyc files used to be kept in same dir as the py files, before __pycache__ subdir came along
2023-04-18 15:45:01 <psykose> i don't think that complicates it much
2023-04-18 15:45:13 <psykose> the issue here is they become analogous virtual siblings and really idk who this is for
2023-04-18 15:45:42 <psykose> i'm sure if someone cares that much about 'the same (bit less) diskspace as no-pyc, but also no compile cost' they can uhh rice their own distro
2023-04-18 15:45:43 <psykose> : ^ )
2023-04-18 15:46:22 <psykose> expressing those kinds of dependencies would be very annoying and would require a rework of everything using python to work well
2023-04-18 15:46:25 <psykose> for, nobody
2023-04-18 15:47:26 <ncopa> drats
2023-04-18 15:47:42 <ncopa> -fprofile-generate -I./Include/internal  -I. -I./Include   -fPIC -DPy_BUILD_CORE_BUILTIN -c ./Modules/pwdmodule.c -o Modules/pwdmodule.o
2023-04-18 15:47:42 <ncopa> gcc  -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall    -g -O2 -DTHREAD_STACK_SIZE=0x200000 -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -g -O2 -DTHREAD_STACK_SIZE=0x200000
2023-04-18 15:47:47 <ncopa> where is the -Os?
2023-04-18 15:48:14 <psykose> the cflags are empty
2023-04-18 15:48:24 <psykose> none of them that would be there are
2023-04-18 15:48:42 <psykose> we set -O2 for python anyway, but it would indeed have -Os and the wformat first
2023-04-18 15:48:51 <psykose> all the flags are empty
2023-04-18 15:48:57 <psykose> i.e. everything you have in default is missing
2023-04-18 15:49:40 <ncopa> + '[' -f /default.conf ]
2023-04-18 15:49:56 <psykose> aha
2023-04-18 15:50:21 <psykose> i think i broke that
2023-04-18 15:50:42 <psykose> hm, no
2023-04-18 15:50:50 <ncopa> must have been me
2023-04-18 15:50:55 <psykose> the makefile does the sed
2023-04-18 15:51:11 <psykose> although it looks ok
2023-04-18 15:53:11 <ncopa> nothign sets ABUILD_SHAREDIR
2023-04-18 15:55:36 <ncopa> it means i need to re-run the 3.18 bootstrap
2023-04-18 15:56:14 <psykose> yeah
2023-04-18 15:56:21 <psykose> sucks
2023-04-18 15:59:57 <ncopa> fix pushed
2023-04-18 16:01:00 <ncopa> we should rebuild everything since  f7f0cd5a61431182c483f8e33cfd1c7809cf8ca9
2023-04-18 16:01:09 <ncopa> git log  git log f7f0cd5a61431182c483f8e33cfd1c7809cf8ca9...
2023-04-18 16:01:18 <psykose> yeah
2023-04-18 16:01:19 <psykose> i'll do
2023-04-18 16:02:51 <psykose> thanks for fixing it <3
2023-04-18 16:04:46 <ncopa> those perl builds should be killed right?
2023-04-18 16:05:04 <psykose> no
2023-04-18 16:05:06 <psykose> was after
2023-04-18 16:05:23 <psykose> a minute after your commit and abuild looped first
2023-04-18 16:05:29 <psykose> ah
2023-04-18 16:05:30 <psykose> or did it
2023-04-18 16:05:33 <ncopa> abuild 3.11.0_rc9-r0
2023-04-18 16:05:33 <psykose> i guess kill
2023-04-18 16:08:07 <psykose> they might've all gotten scuffed
2023-04-18 16:08:08 <psykose> every arch
2023-04-18 16:08:15 <ncopa> yeah
2023-04-18 16:08:23 <ncopa> i have fixed x86*
2023-04-18 16:08:45 <ncopa> abuild 3.11.0_rc9-r1
2023-04-18 16:08:45 <ncopa> build-edge-s390x [~]# abuild -V
2023-04-18 16:08:46 <ncopa> ps xa
2023-04-18 16:10:45 <ncopa> s390x and ppc64le should be ok now
2023-04-18 16:11:33 <ncopa> i dunno if perl got built
2023-04-18 16:11:39 <ncopa> on aarch64
2023-04-18 16:12:55 <psykose> i can always just bump it one more time
2023-04-18 16:13:20 <ikke> "Don't you know bump it up, you gotta bump it up"
2023-04-18 16:13:54 <ncopa> aarch64 was ok
2023-04-18 16:15:49 <ncopa> ok, all edge builders are now updated and have updated abuild
2023-04-18 16:15:55 <ncopa> phew
2023-04-18 16:16:38 <psykose> phew indeed :)
2023-04-18 16:16:45 <psykose> you did a lot of good work today
2023-04-18 16:16:48 <ncopa> you too
2023-04-18 16:16:50 <ncopa> teamwork
2023-04-18 16:17:01 <psykose> 🤛
2023-04-18 16:19:46 <ncopa> i cannot restart the 3.18 builders til the updated abuild is pushed to edge
2023-04-18 16:20:23 <psykose> could you fix the noarch warning too
2023-04-18 16:20:31 <psykose> for pyc subpkg
2023-04-18 16:20:43 <psykose> it's just adding it to the case block where the others are like fishcomp etc
2023-04-18 16:22:28 <ncopa> not now im late for a meeting
2023-04-18 16:22:36 <ncopa> need to run...
2023-04-18 16:22:46 <psykose> sure thing :)
2023-04-18 16:22:51 <psykose> do you mind if i do it?
2023-04-18 16:40:08 <psykose> did it
2023-04-18 17:50:48 <ncopa> thanks!
2023-04-19 00:49:06 <srcfn> I had to add some kconfig flags before this laptop's audio would work (Google Pixelbook). Ubuntu 22.10 seems to already ship with the right modules. Is it ok to add the flags to lts.x86_64.config? 
2023-04-19 00:59:38 <srcfn> For reference, it's CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH that was missing. Thanks!
2023-04-19 01:00:15 <srcfn> Er, wrong line. CONFIG_SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH it is.
2023-04-19 01:13:19 <bl4ckb0ne> ikke: if its possible id like that pls
2023-04-19 06:37:37 <ncopa> morning
2023-04-19 06:37:46 <ncopa> gcc does not build with format-security
2023-04-19 06:37:49 <ncopa> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100431
2023-04-19 08:35:34 <ncopa> I think 765dc9ebf42040ad441c81c2b9aed5e9ca674bd4 introduced a circular dep
2023-04-19 08:36:27 <ncopa> i cannot build nghttp2 because c-ares-dev is missing
2023-04-19 08:37:19 <ncopa> and i think cmake needs curl who needs c-ares
2023-04-19 08:44:40 <abby> yeah void had that cycle too https://github.com/void-linux/void-packages/issues/43362
2023-04-19 09:14:30 <ncopa> our CI does not check for circular deps, right?
2023-04-19 09:14:36 <ikke> Yet
2023-04-19 09:14:37 <ncopa> i think we should have a check in CI
2023-04-19 09:15:40 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/merge_requests/8
2023-04-19 10:20:18 <ncopa> freetype has also circular dep
2023-04-19 10:24:45 <ikke> apkcircledep does not report anything
2023-04-19 10:24:53 <ikke> ptrc: ^
2023-04-19 10:25:03 <ncopa> its ap/lua-aports that does not pick up provides
2023-04-19 10:25:10 <ncopa> harfbyzz-stage0
2023-04-19 10:25:23 <ikke> apkcircledep uses alpine/go
2023-04-19 10:25:26 <ptrc> hm, i thought we fixed the harfbuzz loop?
2023-04-19 10:25:32 <ncopa> i thought so too
2023-04-19 10:25:38 <ncopa> but is seems to be soemthing else now
2023-04-19 10:25:49 <ncopa> ERROR: unable to select packages:
2023-04-19 10:25:49 <ncopa>   .makedepends-cairo-20230419.102523:
2023-04-19 10:25:49 <ncopa> >>> cairo: Analyzing dependencies...
2023-04-19 10:25:49 <ncopa>     masked in: cache
2023-04-19 10:25:49 <ncopa>     satisfies: world[.makedepends-cairo=20230419.102523]
2023-04-19 10:25:51 <ncopa>     required by: .makedepends-cairo-20230419.102523[fontconfig-dev]
2023-04-19 10:25:51 <ncopa>   fontconfig-dev (no such package):
2023-04-19 10:25:53 <ncopa>     required by: .makedepends-cairo-20230419.102523[freetype-dev]
2023-04-19 10:25:53 <ncopa>   freetype-dev (no such package):
2023-04-19 10:25:55 <ncopa> >>> ERROR: cairo: builddeps failed
2023-04-19 10:26:23 <ptrc> ncopa: is that just `abuild deps` in cairo?
2023-04-19 10:26:38 <ikke> Maybe for after 3.18 that we should look into how to provide subpackage metadata in the global scope
2023-04-19 10:36:01 <ncopa> ptrc: yes
2023-04-19 10:36:16 <ncopa> when building from empty repository
2023-04-19 10:36:23 <ptrc> okay, hm
2023-04-19 10:36:39 <ptrc> i can see why apkcircledep fails to find it
2023-04-19 10:36:45 <ncopa> i manually built harfbuzz-stage0
2023-04-19 10:37:03 <ptrc> https://gitlab.alpinelinux.org/ptrcnull/apkcircledep/-/blob/master/main.go#L116
2023-04-19 10:37:21 <ikke> you exclude stage0?
2023-04-19 10:37:28 <ptrc> the opposite
2023-04-19 10:37:31 <ptrc> specifically pick stage0
2023-04-19 10:37:36 <ikke> ah ok
2023-04-19 10:37:38 <ptrc> if it's an available provider
2023-04-19 10:37:40 <ptrc> the question is
2023-04-19 10:37:45 <ptrc> why does ap not pick that?
2023-04-19 10:38:24 <ncopa> ap does not need to. i buildt stage0 manually, so its there for apk
2023-04-19 10:38:37 <ncopa> but its not harfbuzz this time i think
2023-04-19 10:40:13 <ptrc> i commented out the biased choice and it's only this loop it finds: [cairo fontconfig freetype harfbuzz cairo]
2023-04-19 10:41:41 <ncopa> build-3-18-armv7 [~/aports]$ (cd ~/aports/main/freetype/ && abuild -r) && git pull --rebase && sh  ~/.abuild/bootstrap-aports.sh abuild aports-build
2023-04-19 10:41:42 <ncopa> >>> freetype: Building main/freetype 2.13.0-r3 (using abuild 3.11.0_rc10-r0) started Wed, 19 Apr 2023 10:40:52 +0000
2023-04-19 10:41:42 <ncopa> >>> freetype: Checking sanity of /home/buildozer/aports/main/freetype/APKBUILD...
2023-04-19 10:41:42 <ncopa> >>> freetype: Analyzing dependencies...
2023-04-19 10:41:42 <ncopa> ERROR: unable to select packages:
2023-04-19 10:41:43 <ncopa>   .makedepends-freetype-20230419.104052:
2023-04-19 10:41:43 <ncopa>     masked in: cache
2023-04-19 10:41:45 <ncopa>     satisfies: world[.makedepends-freetype=20230419.104052]
2023-04-19 10:41:45 <ncopa>   harfbuzz-bootstrap (virtual):
2023-04-19 10:41:47 <ncopa>     note: please select one of the 'provided by' packages explicitly
2023-04-19 10:41:47 <ncopa>     provided by: harfbuzz-stage0
2023-04-19 10:41:49 <ncopa>     required by: .makedepends-freetype-20230419.104052[harfbuzz-bootstrap]
2023-04-19 10:41:49 <ncopa>   harfbuzz-bootstrap-dev (virtual):
2023-04-19 10:41:51 <ncopa>     provided by: harfbuzz-stage0-dev
2023-04-19 10:41:51 <ncopa>     note: please select one of the 'provided by' packages explicitly
2023-04-19 10:41:53 <ncopa>     required by: .makedepends-freetype-20230419.104052[harfbuzz-bootstrap-dev]
2023-04-19 10:41:53 <ncopa> >>> ERROR: freetype: builddeps failed
2023-04-19 10:45:19 <ptrc> why does that even happen? apk source (commit.c#analyze_missing_name) doesn't really have any comments
2023-04-19 10:47:43 <ikke> So it asks you to select one of the provides from a list of only 1 provides?
2023-04-19 11:31:23 <ncopa> yes
2023-04-19 11:32:11 <ncopa> at some point i think it would pick that one if it only was a single one, but that change was reverted
2023-04-19 11:32:18 <ncopa> in apk-tools
2023-04-19 11:32:39 <ncopa> i dont remember why, but IIRC it was a good reason
2023-04-19 11:32:57 <ncopa> I think it might help if provider_priority is non-zero
2023-04-19 11:33:32 <ncopa> but in general, im not too happy with this approach
2023-04-19 11:34:02 <ncopa> because, its sort of non-deterministic if freetype is built with harfbuzz or not
2023-04-19 11:34:23 <ncopa> will we ship a freetype built with harfbuzz in 3.18?
2023-04-19 11:34:30 <ncopa> maybe. maybe not
2023-04-19 11:34:58 <ncopa> it actually depends if there are any updates to freetype after world is built
2023-04-19 11:35:28 <ncopa> if there are no updates, there is nothing that forces a rebuilt of freetype
2023-04-19 11:54:32 <ncopa> i think it would be better to have a BOOTSTRAP conditional in harfbuzz
2023-04-19 11:56:45 <ncopa> other option would be to build a static-only harfbuzz and let freetype link to that
2023-04-19 12:24:50 <raspbeguy> hello, probably a stupid question, but is there a script/tool to create patches that are usable by aports ?
2023-04-19 12:26:00 <ncopa> patch?
2023-04-19 12:26:08 <ncopa> no, sorry
2023-04-19 12:26:10 <ncopa> diff
2023-04-19 12:26:15 <ncopa> from diffutils
2023-04-19 12:26:20 <ncopa> and git
2023-04-19 12:26:34 <ncopa> i often do cd src/foo-1.0/ && git init
2023-04-19 12:27:13 <ncopa> git add . ; git commit -minit; and then do changes and: git diff > ../../mychage.patch
2023-04-19 12:27:37 <raspbeguy> ok thanks
2023-04-19 12:35:52 <ncopa> interesting. libucontext segfaults on 32bit x86 when built with -Os
2023-04-19 12:51:55 <ncopa> ok, so i built harfbuzz-stag0 and freetype. now i get cairo -> fontconfig problem
2023-04-19 12:52:15 <ncopa> >>> cairo: Analyzing dependencies...
2023-04-19 12:52:15 <ncopa> ERROR: unable to select packages:
2023-04-19 12:52:15 <ncopa>     masked in: cache
2023-04-19 12:52:15 <ncopa>     satisfies: world[.makedepends-cairo=20230419.125033]
2023-04-19 12:52:15 <ncopa>   .makedepends-cairo-20230419.125033:
2023-04-19 12:52:17 <ncopa>     required by: .makedepends-cairo-20230419.125033[fontconfig-dev]
2023-04-19 12:52:17 <ncopa>   fontconfig-dev (no such package):
2023-04-19 12:52:37 <ncopa> fontconfig fails due to:
2023-04-19 12:52:40 <ncopa>   .makedepends-fontconfig-20230419.125219:
2023-04-19 12:52:40 <ncopa>     satisfies: world[.makedepends-fontconfig=20230419.125219]
2023-04-19 12:52:40 <ncopa> ERROR: unable to select packages:
2023-04-19 12:52:40 <ncopa> >>> fontconfig: Analyzing dependencies...
2023-04-19 12:52:40 <ncopa>     masked in: cache
2023-04-19 12:52:41 <ncopa>   docbook2x (no such package):
2023-04-19 12:52:41 <ncopa>     required by: .makedepends-fontconfig-20230419.125219[docbook2x]
2023-04-19 12:52:43 <ncopa>   json-c-dev (no such package):
2023-04-19 12:52:43 <ncopa>     required by: .makedepends-fontconfig-20230419.125219[json-c-dev]
2023-04-19 12:55:29 <ncopa> this is a nightmare
2023-04-19 12:55:53 <ncopa> i have no idea what is circular but something is
2023-04-19 13:04:07 <psykose> feels like cmake causes half of them
2023-04-19 13:06:17 <psykose> what does json-c-dev say
2023-04-19 13:14:05 <psykose> <ncopa> because, its sort of non-deterministic if freetype is built with harfbuzz or not
2023-04-19 13:14:05 <psykose> <ncopa> will we ship a freetype built with harfbuzz in 3.18?
2023-04-19 13:14:10 <psykose> it is? that's what the -stage0 is
2023-04-19 13:14:22 <psykose> it does not have to be built with the final non -stage0 harfbuzz
2023-04-19 13:14:34 <psykose> the output is the same
2023-04-19 13:16:23 <psykose> if you think it has to then build freetype with non-stage0 harfbuzz to be correct, you're wrong
2023-04-19 13:16:28 <psykose> i intentionally didn't do it that way
2023-04-19 13:17:22 <psykose> the error is weird however, it means provider_priority=0 doesn't work with one provider
2023-04-19 13:17:30 <psykose> which means we have to fix a few more stuff that did that
2023-04-19 13:36:49 <ncopa> >>> json-c: Analyzing dependencies...
2023-04-19 13:36:49 <ncopa> ERROR: unable to select packages:
2023-04-19 13:36:49 <ncopa>     satisfies: world[.makedepends-json-c=20230419.133641]
2023-04-19 13:36:49 <ncopa>   .makedepends-json-c-20230419.133641:
2023-04-19 13:36:49 <ncopa>     masked in: cache
2023-04-19 13:36:51 <ncopa>     required by: .makedepends-json-c-20230419.133641[cmake]
2023-04-19 13:36:51 <ncopa>   cmake (no such package):
2023-04-19 13:36:53 <ncopa>   doxygen (no such package):
2023-04-19 13:36:53 <ncopa>     required by: .makedepends-json-c-20230419.133641[doxygen]
2023-04-19 13:36:58 <psykose> and if you build cmake what does it say
2023-04-19 13:37:17 <ncopa>   libarchive-dev (no such package):
2023-04-19 13:37:17 <ncopa>   libuv-dev (no such package):
2023-04-19 13:37:17 <ncopa>     required by: .makedepends-cmake-20230419.133709[libarchive-dev]
2023-04-19 13:37:17 <ncopa>   py3-sphinx (no such package):
2023-04-19 13:37:17 <ncopa>     required by: .makedepends-cmake-20230419.133709[libuv-dev]
2023-04-19 13:37:19 <ncopa>     required by: .makedepends-cmake-20230419.133709[py3-sphinx]
2023-04-19 13:37:19 <ncopa>   rhash-dev (no such package):
2023-04-19 13:37:21 <ncopa>     required by: .makedepends-cmake-20230419.133709[rhash-dev]
2023-04-19 13:37:29 <psykose> hmm
2023-04-19 13:38:36 <ncopa> manually building lz4 and libarchive now
2023-04-19 13:38:58 <psykose> i'm going through iteratively and don't see anything yet
2023-04-19 13:39:06 <ncopa> same here
2023-04-19 13:39:09 <psykose> ah
2023-04-19 13:39:12 <psykose> doxygen uses cmake
2023-04-19 13:39:44 <psykose> or is that fine
2023-04-19 13:40:00 <psykose> yeah should be
2023-04-19 13:40:10 <psykose> hrm
2023-04-19 13:40:27 <ncopa> its something cairo <-> fontconfig
2023-04-19 13:41:04 <psykose> fontconfig has json-c-dev in checkdepends
2023-04-19 13:42:20 <ncopa> that might be it
2023-04-19 13:42:47 <ncopa> but how does json-c pull in fontconfig?
2023-04-19 13:44:17 <psykose> probably cmake -> py3-sphinx -> ..
2023-04-19 13:44:17 <psykose> hmm
2023-04-19 13:44:31 <psykose> if you go to cmake, and just delete the py3-sphinx line, does ap then find a path
2023-04-19 13:44:31 <ncopa> im building doxygen now
2023-04-19 13:47:03 <ncopa> cmake does not seem to be in py3-sphinx's path
2023-04-19 13:47:23 <ncopa> https://tpaste.us/KExP
2023-04-19 13:47:23 <ncopa> $ ap recursive-deps py3-sphinx | tpaste
2023-04-19 13:48:25 <psykose> ap recursive-deps cmake, has cmake
2023-04-19 13:51:21 <psykose> not sure what does though
2023-04-19 13:51:27 <psykose> wish we had a smaller cmake for packaging
2023-04-19 13:51:45 <psykose> not sure it even uses any of these deps when used in aports
2023-04-19 13:51:49 <ncopa> it recursively prints all deps
2023-04-19 13:52:02 <psykose> yeah
2023-04-19 13:52:13 <psykose> so if the recursive deps for cmake has cmake, means there is a circle somewhere, no
2023-04-19 13:52:30 <ncopa> i see it only at the end
2023-04-19 13:53:06 <psykose> yeah
2023-04-19 13:53:19 <psykose> ah
2023-04-19 13:53:25 <psykose> right
2023-04-19 13:53:26 <psykose> nvm
2023-04-19 13:53:37 <ncopa> i dont think its cmake this time
2023-04-19 13:54:55 <psykose> ah, for fontconfig, there is a fontconfig-dev in the list
2023-04-19 13:55:13 <psykose> hm
2023-04-19 13:55:30 <ncopa> yup
2023-04-19 13:55:35 <ncopa> thats the problem
2023-04-19 13:55:59 <ncopa> i wonder if its harfbuzz that might confuse ap
2023-04-19 13:56:57 <ncopa> when caclulating the dependency chain it picks the harfbuzz instead of harfbuzz-stage0
2023-04-19 13:57:05 <ncopa> and fails to calculate the order
2023-04-19 13:57:26 <psykose> yeah
2023-04-19 13:57:48 <psykose> so you get fontconfig -> freetype -> non-stage0-harfbuzz -> cairo -> fontconfig
2023-04-19 13:57:52 <ncopa> yeah, harfbuzz depends on cairo
2023-04-19 13:58:04 <psykose> even though the calculation is wrong and there isn't an actual circle
2023-04-19 14:00:25 <ncopa> so we either need to fix the dependency solving to handle this kind fo thing
2023-04-19 14:00:39 <psykose> haha, funny
2023-04-19 14:00:42 <psykose> anyway fixed
2023-04-19 14:00:45 <psykose> git pull and it'll work
2023-04-19 14:01:44 <psykose> this is a very nontrivial case to handle and would take a while to make
2023-04-19 14:01:56 <psykose> it's more a future wishlist for a long day somewhere
2023-04-19 14:02:18 <ncopa> in general, circular deps are evil
2023-04-19 14:02:44 <ncopa> https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1514618751
2023-04-19 14:02:52 <psykose> it's not circular, that's the whole point
2023-04-19 14:02:57 <psykose> well, the 'underlying thing' is
2023-04-19 14:03:01 <psykose> not the actual dependency graph
2023-04-19 14:04:19 <psykose> they don't have a way to fix it
2023-04-19 14:04:24 <psykose> adding more tarballs wouldn't really do it
2023-04-19 14:04:53 <psykose> hmm, or maybe
2023-04-19 14:05:21 <ncopa> if you split the parts that freetype uses, yes, it would help
2023-04-19 14:08:50 <ncopa> >>> freetype: Fetching https://download.savannah.gnu.org/releases/freetype/freetype-2.13.0.tar.xz
2023-04-19 14:08:54 <ncopa> curl: (22) The requested URL returned error: 404
2023-04-19 14:13:27 <psykose> it works
2023-04-19 14:13:30 <psykose> you just hit a bad mirror
2023-04-19 14:13:42 <psykose> savannah is geo roundrobinned mirrors
2023-04-19 14:13:53 <ncopa> and thank for fixing the harfbuzz thing. i think it was the only sane solution
2023-04-19 14:13:53 <psykose> it fails at random and takes a few retries depending on where you are
2023-04-19 14:14:11 <psykose> yeah i just assumed ap would have been able to look past a stage0 loop, but now i know
2023-04-19 14:14:17 <psykose> tbh apkcircledep also reported it
2023-04-19 14:14:23 <psykose> just.. i assumed it works anyway
2023-04-19 14:14:37 <psykose> now i know that if apkcircledep says no that it doesn't matter what i think
2023-04-19 14:14:38 <psykose> :D
2023-04-19 14:14:46 <ncopa> :)
2023-04-19 14:14:48 <psykose> ptrc: you should remove the exclusion ^
2023-04-19 14:15:42 <ncopa> i was thinking wwe could build a minimalistic harfbuzz build with static lib only, and link freetype to that
2023-04-19 14:16:11 <psykose> you shouldn't have changed the URL
2023-04-19 14:16:14 <ncopa> but then there would be double identifiers when linking harfbuzz
2023-04-19 14:16:17 <psykose> the one you picked is just one of the savannah mirrors
2023-04-19 14:16:26 <psykose> you picked something that doesn't cycle instead
2023-04-19 14:16:36 <ncopa> well, I'll change it back whenever that mirror dissapears
2023-04-19 14:16:40 <psykose> sure, i guess
2023-04-19 14:36:01 <ncopa> perl-http-daemon no longer build man page
2023-04-19 14:36:09 <ncopa> so -doc package fails
2023-04-19 14:37:09 <ncopa> .SIGN.RSA.alpine-devel@lists.alpinelinux.org-6165ee59.rsa.pub
2023-04-19 14:37:09 <ncopa> .PKGINFO
2023-04-19 14:37:09 <ncopa> $ apk fetch --stdout perl-http-daemon-doc | tar -zt
2023-04-19 14:37:09 <ncopa> usr/
2023-04-19 14:37:09 <ncopa> usr/share/
2023-04-19 14:37:11 <ncopa> usr/share/man/man3/
2023-04-19 14:37:11 <ncopa> usr/share/man/
2023-04-19 14:37:13 <ncopa> usr/share/man/man3/HTTP::Daemon.3pm.gz
2023-04-19 14:46:44 <psykose> is that even in the bootstrap bath
2023-04-19 14:55:07 <ptrc> psykose: removing the exclusion's gonna create some false positives then, iirc
2023-04-19 15:09:39 <psykose> nope
2023-04-19 15:09:42 <psykose> not anymore
2023-04-19 15:09:47 <psykose> it wasn't a false positive
2023-04-19 15:14:36 <ptrc> ah, hm
2023-04-19 15:14:37 <ptrc> okay
2023-04-19 15:30:44 <ncopa> the problem is, how should lua-aports decide which provider to use when calculating what to build and in what order?
2023-04-19 15:32:03 <ikke> highest version or provider priority?
2023-04-19 15:32:45 <ncopa> that breaks bootstrap, as that package has circular dep
2023-04-19 15:33:23 <ncopa> if it picks the other, it will break build order after bootstrap is done
2023-04-19 15:33:52 <ncopa> so the correct answer is, the highest provider prio that has an apk built
2023-04-19 15:34:17 <ncopa> which means it would need to consult the built index
2023-04-19 15:34:41 <ncopa> in other words in it not possible to figure it out unless you know what built  .apk  you have available
2023-04-19 15:36:56 <ikke> This is about build order at bootstrap time, right So about packages that are by definition not available yet?
2023-04-19 15:37:40 <ikke> But I guess the idea is that you can skip taking a provides into account because there is already a different provider available or something like that?
2023-04-19 15:38:10 <ncopa> which means you need to know whats available
2023-04-19 15:38:17 <ncopa> and if nothing is available?
2023-04-19 15:38:41 <ncopa> i dont think there is any good automatic solution for it
2023-04-19 15:39:04 <ncopa> what we could do is always run the builds twice
2023-04-19 15:39:07 <ikke> There are I think 2 different concepts interlinked
2023-04-19 15:39:20 <ncopa> firs run with BOOTSTRAP enabled
2023-04-19 15:39:21 <ikke> run-time providers and build-time providers
2023-04-19 15:39:31 <ncopa> and second time without BOOTSTRAP
2023-04-19 15:39:43 <ikke> ncopa: that would make sense to me anyway
2023-04-19 15:39:56 <ikke> things like curl and git are incomplete when built with BOOTSTRAP
2023-04-19 15:40:10 <ncopa> but it also mean that packages that needs bootstrap would always be built twice on updates, which is not so fun
2023-04-19 15:40:43 <ikke> oh you mean that abuild itself would automatically do that somehow?
2023-04-19 15:40:50 <ncopa> buildrepo
2023-04-19 15:40:56 <ncopa> woudl automatically run twice
2023-04-19 15:40:56 <ikke> `right
2023-04-19 15:41:24 <ikke> build wouldn't it say the package is up-to-date the 2nd time?
2023-04-19 15:41:26 <ncopa> it still wouldnt solve things that does not have a bootstrap path
2023-04-19 15:41:37 <ikke> or force build?
2023-04-19 15:41:56 <ncopa> it would skip it unless the BOOTSTRAP disables one or more subpackages
2023-04-19 15:42:15 <ikke> true
2023-04-19 15:42:35 <ikke> could it be an option that we can enable on buildrepo?
2023-04-19 15:42:42 <ncopa> we would want to skip it, because we want to use the second build
2023-04-19 15:42:47 <ncopa> well
2023-04-19 15:42:58 <ncopa> its *much* simpler to avoid the bootstrap problem
2023-04-19 15:43:18 <ncopa> or handle it manually
2023-04-19 15:43:52 <ikke> doing it manually makes it easy to forget
2023-04-19 15:44:51 <psykose> we could just have the bootstrap path have BOOTSTRAP=1 and double build bootstrap only, as suggested
2023-04-19 15:44:58 <psykose> doesn't build anything twice on setup builders or edge
2023-04-19 15:45:20 <psykose> but when you set it up manually for a release, the first run gets BOOTSTRAP=1, and the custom logic can make it clean
2023-04-19 15:45:25 <psykose> that said, it works fine as is
2023-04-19 15:45:47 <psykose> if you want to change it it needs more thought than this
2023-04-19 15:54:28 <handlerug> raspbeguy: you working on gotosocial 0.8.1?
2023-04-19 15:54:56 <handlerug> wanted to send an MR then saw your comment
2023-04-19 15:55:16 <raspbeguy> handlerug: I didn't do anything yet on 0.8.1
2023-04-19 15:55:29 <handlerug> okay, I will do it
2023-04-19 17:02:48 <ncopa> lua-filesystem fails on ppc64le due to missing luajit
2023-04-19 17:04:51 <psykose> are you bootstrapping or just building the whole repo?
2023-04-19 17:08:39 <ncopa> bootstrapping abuild and aports-build
2023-04-19 17:08:50 <ncopa> its in the dependency path
2023-04-19 17:09:11 <psykose> ah right
2023-04-19 17:09:22 <psykose> well, just git pull
2023-04-19 17:09:50 <ncopa> thank you!
2023-04-19 17:16:24 <ncopa> rmv7 is bootstrapped
2023-04-19 17:16:28 <ncopa> armv7*
2023-04-19 17:17:51 <ncopa> all arm machines are bootstrapped now
2023-04-19 17:23:41 <ncopa> hum why do they not show up https://build.alpinelinux.org?
2023-04-19 17:32:33 <psykose> forgot the keys?
2023-04-19 17:32:45 <psykose> if you mean 3.18
2023-04-19 17:33:50 <ncopa> yup i mean 3.18
2023-04-19 17:35:20 <ncopa> key seems to be there
2023-04-19 17:39:09 <ncopa> nope, you are right it is the key that is missing
2023-04-19 17:47:54 <ncopa> look at that build-3-18-armhf showed up
2023-04-19 17:48:31 <ncopa> ah, maybe they need to build 3 packages before they show up?
2023-04-19 17:49:31 <ncopa> nope
2023-04-19 17:51:29 <psykose> off it goes
2023-04-19 17:51:57 <ncopa> something is wrong with checkum of mesa patch
2023-04-19 17:51:59 <ncopa> from distfiles
2023-04-19 18:02:37 <psykose> yeah, already fixed that
2023-04-19 18:02:43 <psykose> and 3 more failures
2023-04-19 18:02:57 <psykose> nice to see the new flags catch some stuff
2023-04-19 18:04:24 <psykose> should get the other 3.18 builders to announce
2023-04-19 18:04:27 <psykose> it's just arm currently
2023-04-19 18:40:08 <ncopa> arm was the first ready
2023-04-19 18:40:29 <ncopa> it was the fastest, even if had 3 times more work to do :)
2023-04-19 18:40:53 <ncopa> here comes ppc64le
2023-04-19 18:42:00 <ncopa> and s390x
2023-04-19 18:43:12 <ncopa> x86_64 is not done bootstrapping yet
2023-04-19 18:45:25 <psykose> aha
2023-04-19 18:45:26 <psykose> thanks :)
2023-04-19 18:48:22 <ncopa> dhcpcd moved to github
2023-04-19 18:48:47 <psykose> it did yeah
2023-04-19 18:48:57 <ikke> future proof it?
2023-04-19 18:49:23 <psykose> whadya mean
2023-04-19 18:49:31 <ncopa> :'-|
2023-04-19 18:49:37 <ikke> author is ill
2023-04-19 18:49:39 <psykose> ah
2023-04-19 18:49:40 <psykose> yeah
2023-04-19 18:49:45 <psykose> new release too
2023-04-19 18:49:47 <ncopa> terminal cancer
2023-04-19 18:50:34 <psykose> is it just me
2023-04-19 18:50:40 <psykose> or is like 90% of the stuff in /main
2023-04-19 18:50:45 <psykose> stuff that hasn't been updated in 14 years
2023-04-19 18:50:50 <psykose> and fails with format-security
2023-04-19 18:50:51 <psykose> :D
2023-04-19 18:51:54 <ikke> Lots of 'finished' stuff
2023-04-19 18:56:05 <psykose> if they were 'finished' they wouldn't be misusing printf 20 years ago and have implicit function decls in every file
2023-04-19 18:56:49 <psykose> sadly code is never finished :'/
2023-04-19 18:58:11 <ikke> Hence in quotes
2023-04-19 18:59:04 <psykose> maybe the software is 'finnished', i.e. the author retired in finland
2023-04-19 18:59:05 <psykose> :^)
2023-04-19 18:59:17 <ikke> :D
2023-04-19 19:05:11 <bl4ckb0ne> what if the author is already from finland
2023-04-19 19:09:12 <psykose> silence canadian
2023-04-19 19:19:12 <bl4ckb0ne> why are you booing me im asking the right questions here
2023-04-19 19:38:28 <ncopa> all the 3.18 builders are up
2023-04-19 19:44:04 <ikke> 🎉
2023-04-19 19:48:28 <donoban> \o/
2023-04-19 20:10:45 <psykose> char *auth_pass = (char)NULL;
2023-04-19 20:10:47 <psykose> somebody wrote this
2023-04-19 20:42:58 <skarnet> what a terrible day to have eyes
2023-04-19 20:46:59 <ikke> skarnet: would it look better through a brail reader?
2023-04-19 20:47:24 <ikke> or text-to-speach for that matter
2023-04-19 20:48:10 <skarnet> probably not, but it's a meme. :P
2023-04-19 20:48:19 <ikke> heh
2023-04-19 20:51:52 <psykose> to skarnet it's all the same
2023-04-19 20:52:01 <psykose> his eyes have wifi and bluetooth and can see sound
2023-04-19 21:42:59 <psykose> think the 3.18 builders have some broken /etc/apk/world
2023-04-19 21:43:24 <psykose> ikke: could you show me /etc/apk/world from 3.18-aarch64
2023-04-19 22:36:39 <psykose> https://img.ayaya.dev/nzZuiB4PNNda
2023-04-19 22:36:43 <psykose> how did this ever work
2023-04-19 22:38:04 <bl4ckb0ne> bit of spec abusing
2023-04-19 22:40:17 <psykose> i mean it literally doesn't lol
2023-04-19 22:40:34 <psykose> afaik that is just not legal or guaranteed to work unless the layout is identical to the definition
2023-04-19 22:40:41 <psykose> need name: xyz, init
2023-04-19 22:40:51 <psykose> that seems to make Werror=int-conversion happy
2023-04-19 22:44:09 <bl4ckb0ne> standard initialization is pre c99
2023-04-19 22:44:54 <bl4ckb0ne> c99 has designated initialization, which are less of a footgun
2023-04-19 23:19:10 <ovf> psykose: what's wrong with that snippet?
2023-04-19 23:20:07 <psykose> struct initialisation like that is struct declaration order dependent
2023-04-19 23:20:56 <ovf> of course, and what's wrong with that? struct declaration order defines the abi
2023-04-19 23:22:31 <psykose> the 'abi' is hidden and not actually specified to be literally that
2023-04-19 23:22:55 <psykose> if you put a int __pad; in the middle that initialisation doesn't work
2023-04-19 23:22:58 <psykose> incidentally...
2023-04-19 23:23:46 <psykose> https://img.ayaya.dev/rV3JJF4BK1mX
2023-04-19 23:27:49 <ovf> if you have an int foo(int x,int y) that you declare as int foo(); and call foo(2,3), then putting an int __pad in the middle of its formal arguments also will make your code not work, so what?
2023-04-19 23:28:33 <ovf> in c, struct layout is part of your program's interface. changing it changes the semantics.
2023-04-19 23:29:05 <psykose> it's not changed
2023-04-19 23:29:32 <psykose> unless you think 'struct iovec' is by standard required to have the same ABI everywhere, in which case, uh, you are wrong
2023-04-19 23:30:30 <psykose> or rather that's a little backwards
2023-04-19 23:30:48 <psykose> it's more a C language thing
2023-04-19 23:32:04 <ovf> i know for certain that 'struct iovec' is not required, by its standard, to have a certain layout, so any code i write against it won't make any such assumptions. cf. https://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/uio.h.html
2023-04-19 23:32:43 <psykose> so you do get it
2023-04-19 23:32:54 <psykose> :)
2023-04-19 23:34:35 <psykose> i also typo'd that and meant msghdr in this case
2023-04-19 23:34:49 <psykose> which is mostly unspecified the same way i guess
2023-04-19 23:35:55 <ovf> yes: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html
2023-04-19 23:37:36 <psykose> someone already fixed it it seems https://github.com/schweikert/fping/pull/263
2023-04-19 23:37:38 <ovf> but that has nothing to do with c -- within one system, it's perfectly legal to use struct initialization. what posix does, here, is intentionally underspecify the interface from c's point of view in the name of portability
2023-04-19 23:38:12 <psykose> i never said it wasn't legal to use struct initialisation
2023-04-19 23:38:22 <psykose> getting the feeling you just like arguing with me to waste my time over nothing
2023-04-19 23:38:25 <psykose> not today !
2023-04-19 23:39:35 <ovf> i misunderstood your first complaint as being to that effect.
2023-04-19 23:40:36 <ovf> surely that patch could use designated initialisers? i've written enough c89 code in my life to enjoy the luxury of some c99
2023-04-19 23:40:49 <bl4ckb0ne> just accept the whole of ansi C as major footgun and carry on 
2023-04-19 23:41:15 <psykose> sure, i wrote it more shorterer https://git.alpinelinux.org/aports/tree/main/fping/int-conversion.patch
2023-04-19 23:41:22 <psykose> bl4ckb0ne: you write C
2023-04-19 23:41:24 <psykose> L + ratio
2023-04-19 23:41:29 <psykose> + you fell off
2023-04-19 23:41:37 <psykose> + bad coffee
2023-04-19 23:43:26 <bl4ckb0ne> yes
2023-04-19 23:43:50 <bl4ckb0ne> i got tired of hipsters trying to replace C with $newlang in #currentyear
2023-04-19 23:44:22 <psykose> they replaced it ages ago
2023-04-19 23:44:38 <psykose> sadly a language is but a language
2023-04-19 23:44:50 <psykose> doesn't replace the roads or the government !
2023-04-19 23:45:28 <bl4ckb0ne> 
ACTION grumbles in K&R

2023-04-19 23:46:42 <psykose> https://img.ayaya.dev/k9JkiH5JeSzV
2023-04-19 23:47:30 <ovf> i'm actually slightly confused about what's going on in musl's sys/socket.h. aren't the definitions just emulate natural alignment, that any reasonable abi would dictate? is there some architecture that musl supports that doesn't do this?
2023-04-19 23:48:23 <ovf> s/(emulat)e/\1ing/
2023-04-19 23:48:28 <psykose> you could probably ask in #musl on libera.chat
2023-04-19 23:48:30 <psykose> or the mailing list
2023-04-20 00:00:31 <ovf> answer: https://git.musl-libc.org/cgit/musl/commit/?id=7168790763cdeb794df52be6e3b39fbb021c5a64
2023-04-20 00:01:47 <ovf> i guess he could have not exposed that to userspace (as these paddings don't change the physical layout, and are only for the convenience of addressing the gaps when zeroing them)
2023-04-20 00:06:11 <Hello71> psykose: that syntax is "obsolete since GCC 2.5": https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
2023-04-20 00:06:19 <psykose> :p
2023-04-20 00:07:22 <psykose> that doesn't read like the same thing
2023-04-20 00:07:36 <psykose> ah
2023-04-20 00:07:37 <psykose> i see
2023-04-20 00:26:50 <handlerug> where are my damn tarballs https://github.com/openzfs/zfs/releases/tag/zfs-2.1.11
2023-04-20 00:28:28 <psykose> https://img.ayaya.dev/byYAwKc4PUcb
2023-04-20 00:28:47 <psykose> zee eff ess
2023-04-20 00:30:28 <handlerug> oh lol
2023-04-20 00:39:02 <psykose>    94 |    struct msghdr msg = { NULL, 0, iov, 1, control_un.control,
2023-04-20 00:39:02 <psykose> fdleak_cmsg.c:94:43: error: initialization of 'int' from 'char *' makes integer from pointer without a cast [-Werror=int-conversion]
2023-04-20 00:39:05 <psykose> second time today
2023-04-20 00:39:07 <psykose> and this time in valgrind
2023-04-20 00:39:13 <psykose> :D
2023-04-20 00:40:43 <psykose> https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=7136cd987635e8c323fc7da35c8c9f0d3ba25ebd;hp=a6101db6920d12c4d61f1ace19d931670b9d8141 fixed for next
2023-04-20 01:16:01 <bl4ckb0ne> gross fix
2023-04-20 01:16:41 <psykose> is correct
2023-04-20 01:16:45 <psykose> and basically the same lines anywa
2023-04-20 01:16:54 <psykose> and even the same compiled output
2023-04-20 03:38:46 <sam_> this is a nice common one
2023-04-20 03:38:58 <sam_> they should've used designated initialisers but w/e
2023-04-20 03:39:22 <sam_> but it really shows how -Wint-conversion exposes some horrific stuff
2023-04-20 03:39:28 <sam_> stuff that absolutely did not work
2023-04-20 03:39:47 <psykose> yeah been havin fun
2023-04-20 03:40:02 <psykose> well
2023-04-20 03:40:15 <psykose> i only just now remembered that -Werror=int-conversion could break quite a lot of configure tests
2023-04-20 03:40:20 <psykose> and the whole release is built with it
2023-04-20 03:40:20 <psykose> so far
2023-04-20 03:40:45 <sam_> LMAO
2023-04-20 03:41:10 <sam_> on the upside a lot of low hanging fruit in common stuff is fixed, if they've had releases
2023-04-20 03:41:17 <sam_> on the other hand i've only been doing some work on musl, not that much yet
2023-04-20 03:41:27 <sam_> and florian isn't working on int-conversion yet, just me
2023-04-20 03:41:42 <psykose> yeah :-|
2023-04-20 03:41:50 <psykose> got a gentoobugshortlist for me to scan
2023-04-20 03:47:34 <sam_> no short list i'm afraid
2023-04-20 03:47:51 <psykose> sad
2023-04-20 03:47:57 <psykose> just a long one? ;)
2023-04-20 03:48:00 <sam_> yes :D
2023-04-20 03:48:12 <sam_> https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hide_resolved=0 you can grep for configure which will have a lot of it, and i usually mention configure in the commit message as well
2023-04-20 03:48:16 <sam_> but ultimately it's a real mess
2023-04-20 03:48:29 <psykose> phew
2023-04-20 03:48:33 <psykose> 90% of this is implicit
2023-04-20 03:48:37 <psykose> which i don't set
2023-04-20 03:48:41 <psykose> well
2023-04-20 03:48:44 <psykose> they usually combine anyway
2023-04-20 03:49:27 <sam_> that's the problem
2023-04-20 03:49:39 <sam_> or like, implicit was the first issue, so we just say that, etc
2023-04-20 03:50:30 <psykose> wish there was a 'builds but is broken' list tbh
2023-04-20 03:50:35 <psykose> cause build failures are real easy
2023-04-20 03:52:48 <psykose> aha, right
2023-04-20 03:52:53 <psykose> that is a big list at the bottom there
2023-04-20 03:56:57 <sam_> off the top of of my head: openldap, ntp, lvm 
2023-04-20 03:57:43 <sam_> it doesn't help that loads of this stuff has false positives, because it's valid to have an e.g. int-conversion warning while testing for the strerror_r variant
2023-04-20 03:58:30 <psykose> was openmeme and lvm fixed
2023-04-20 03:59:00 <sam_> yes, although it's not in an openmeme release 
2023-04-20 03:59:06 <sam_> oh, zsh too, not in a release either iirc
2023-04-20 03:59:26 <psykose> lvm is yes
2023-04-20 03:59:41 <sam_> apr + apr-util but they're in releases (the latest ones)
2023-04-20 04:00:31 <psykose> yep
2023-04-20 04:02:40 <psykose> really gonna regret this one eh
2023-04-20 04:08:01 <sam_> yes yes you are
2023-04-20 04:08:03 <sam_> but it's for the best it's fine
2023-04-20 04:12:54 <psykose> been to any grime shows recently
2023-04-20 04:25:54 <sam_> i don't think i've left the house recently lmao
2023-04-20 04:25:55 <sam_> have you 
2023-04-20 04:28:23 <psykose> good one
2023-04-20 04:28:37 <psykose> a month ago maybe
2023-04-20 04:28:43 <psykose> or two
2023-04-20 04:28:46 <psykose> did a bit of travelling
2023-04-20 04:52:32 <ikke> psykose: https://tpaste.us/ogxB 
2023-04-20 04:52:54 <psykose> hm
2023-04-20 04:52:55 <psykose> weird
2023-04-20 04:53:02 <psykose> well, gnat should go :^)
2023-04-20 04:53:45 <psykose> my sus was about python3 being added by makedepends but the -pyc stuff not being installed in the log
2023-04-20 04:53:48 <psykose> even though it does normally
2023-04-20 04:55:44 <ikke> did something change that gcc-gnat no longer need to be explicitly installed?
2023-04-20 04:56:04 <ikke> we also needed to add it to alpine-gitlab-ci
2023-04-20 04:56:34 <psykose> it's not needed except to build gcc
2023-04-20 04:56:39 <psykose> for bootstrap or w/e
2023-04-20 04:56:45 <psykose> what was it needed for in ci
2023-04-20 04:58:47 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/commit/2e3444d5d6e2c6aa46b6fc0df246cf672aeb1cc2
2023-04-20 05:01:18 <psykose> classic
2023-04-20 05:01:53 <psykose> the real question is why we ever had that enabled
2023-04-20 05:02:01 <psykose> literally nothing used ada in all of aports until half a year ago lol
2023-04-20 05:04:12 <ikke> maybe something did use it before
2023-04-20 07:28:47 <ikke> psykose: fyi, repo.apache.maven.org is having issues, so expect build failures 
2023-04-20 07:29:05 <psykose> yay
2023-04-20 07:29:39 <ikke> missing DNS records 
2023-04-20 08:00:45 <ncopa> im fixing gcc6
2023-04-20 08:03:05 <psykose> didn't see
2023-04-20 08:03:31 <psykose> though it looks cursed as hell
2023-04-20 08:05:22 <psykose> seems to have fixed it
2023-04-20 08:05:26 <psykose> idk what happens these
2023-04-20 08:06:08 <psykose> the first <isl/val.h> replaces itself with <isl/val_gmp.h>, unless you add it a second time
2023-04-20 08:06:20 <psykose> magique
2023-04-20 08:12:12 <psykose> yep, fixed
2023-04-20 08:14:25 <ncopa> nice! thanks
2023-04-20 08:14:34 <ncopa> I'll have a look at the rust stuff then
2023-04-20 08:15:20 <psykose> just needs a usual bootstrap build
2023-04-20 08:15:30 <psykose> all 3 arm ones are ready
2023-04-20 08:19:30 <ncopa> i kille aarch64 build to build rust
2023-04-20 08:25:10 <psykose> sure
2023-04-20 08:30:02 <ncopa> rust is now building on arm machines and s390x
2023-04-20 08:32:04 <psykose> success
2023-04-20 08:32:58 <ncopa> packages are available from https://dl-master.alpinelinux.org/alpine/v3.18/ now
2023-04-20 08:34:38 <donoban> good morning, I would like to move few packages (pdjfs/nyx and is depedency py3-stem) to community from testing, it's ok? is enough to push it to edge?
2023-04-20 08:42:01 <psykose> yeah
2023-04-20 08:42:21 <psykose> ncopa: also i think you had forgotten the MGLRU thing, so i enabled it in 
2023-04-20 08:42:22 <psykose> 956df0627335ec0ce0cc60a68007b16eae57ba89
2023-04-20 08:42:34 <psykose> since it's good to have but it's one of those weird non-default-enabled things for base =y
2023-04-20 08:42:37 <psykose> :p
2023-04-20 08:43:30 <psykose> it's runtime togglable, there's some tuning too, that option is just the default for /sys/kernel/mm/lru_gen/enabled
2023-04-20 08:50:50 <ncopa> sounds good. thanks!
2023-04-20 08:54:28 <donoban> >>> WARNING: nyx*: Found __pycache__ but package name doesn't end with -pyc
2023-04-20 08:54:40 <psykose> add $pkgname-pyc to subpackages
2023-04-20 08:54:52 <donoban> ok ty
2023-04-20 08:54:59 <ncopa> psykose: we should update the docs
2023-04-20 08:55:03 <psykose> which
2023-04-20 08:55:25 <ncopa> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2023-04-20 08:55:58 <psykose> i just checked and i actually came across 2 other pages instead
2023-04-20 08:56:03 <psykose> we really got 20 pages for this huh
2023-04-20 08:58:55 <ncopa> rust is done on build-3-18-armhf
2023-04-20 08:59:14 <donoban> is fine to do this if test fails due "uknown" term? >>> WARNING: nyx*: Found __pycache__ but package name doesn't end with -pyc
2023-04-20 08:59:19 <donoban> argg, sorry
2023-04-20 08:59:26 <donoban> TERM=xterm python3 run_tests.py
2023-04-20 08:59:42 <donoban> anyway 1 test fails but it continues packaging
2023-04-20 09:00:26 <psykose> i usually do TERM=linux or dumb or whatever
2023-04-20 09:01:47 <ncopa> rust is done on build-3-18-aarch64 too
2023-04-20 09:02:00 <ncopa> this ampera machine is *fast*
2023-04-20 09:02:14 <psykose> what was our x86_64 builder again
2023-04-20 09:02:24 <psykose> the one we have for riscv64 shared with the dev containers is like 2x better
2023-04-20 09:02:25 <psykose> quite literally
2023-04-20 09:02:57 <psykose> and yeah the ampere is very fun :D
2023-04-20 09:03:10 <psykose> i do a lot of stuff on it when i need to test things
2023-04-20 09:03:26 <ncopa> model name	: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
2023-04-20 09:03:35 <psykose> ah yes
2023-04-20 09:03:51 <ncopa> 32 virtual cpus, so i guess 16 cpu cores with HT
2023-04-20 09:03:55 <psykose> 2012 cpu on ddr3
2023-04-20 09:04:15 <ncopa> i think its rotating disks as well
2023-04-20 09:04:25 <psykose> served us really well eh :D
2023-04-20 09:04:34 <donoban> lol, I have one older
2023-04-20 09:04:37 <donoban> model name      : Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz
2023-04-20 09:04:44 <psykose> we could migrate to the one we have dev containers on, no?
2023-04-20 09:06:08 <ncopa> possibly. its a topic for #alpine-infra though
2023-04-20 09:12:30 <ncopa> rust is done on build-3-18-armv7
2023-04-20 09:13:07 <psykose> 🦛
2023-04-20 09:24:45 <psykose> ncopa: you could do aarch64 ghc too i guess
2023-04-20 09:24:52 <psykose> don't think anything after that needed pauses
2023-04-20 09:25:46 <ncopa> golang?
2023-04-20 09:28:15 <psykose> nope
2023-04-20 09:28:24 <psykose> already built, it builds from gcc-go
2023-04-20 09:29:48 <ncopa> ok, cool
2023-04-20 09:31:35 <psykose> thank nmeum for that one :)
2023-04-20 09:31:37 <psykose> it's very cool
2023-04-20 09:51:51 <dzilvys> how can disable kernel panic messages? I am trying to debug an application that is causing a kernel panic but I would rather see what gdb is throwing than get flooded with kernel messages
2023-04-20 09:53:21 <dzilvys> just a bit more info, the application is running inside a docker container. I have already set `kernel.printk = 3 4 1 3` in /etc/sysctl.conf on the ubuntu docker container, but it still throws it so I assume there is a setting on the alpine side too?>
2023-04-20 09:59:10 <ncopa> you need configure that on the host, not in the container
2023-04-20 09:59:51 <nmeum> the gcc-go based bootstrapped might break with go 1.22 because they might bump the required bootstrap version to 1.20 with that release and gcc-go is currently at 1.18 :(
2023-04-20 10:00:07 <ncopa> psykose: we can probably build openjdk without those -Werror=int-conversion
2023-04-20 10:00:48 <dzilvys> ncopa: as the sysctl.conf does not exist on the host, I assume I just make one?
2023-04-20 10:00:57 <psykose> ncopa: i can fix them anyway
2023-04-20 10:01:03 <ncopa> psykose: thanks
2023-04-20 10:01:16 <ncopa> dzilvys: you never told if you run alpine or ubuntu on the host
2023-04-20 10:01:22 <dzilvys> Alpine
2023-04-20 10:01:41 <dzilvys> I said `ubuntu docker container`
2023-04-20 10:01:46 <dzilvys> but my bad if it wasn't clear enough
2023-04-20 10:01:55 <dzilvys> So, Alpine = Host, Ubuntu = Guest
2023-04-20 10:02:13 <ncopa> ok. usually people do the opposite :)
2023-04-20 10:02:21 <dzilvys> :D
2023-04-20 10:02:38 <ncopa> yes, you can add a sysctl config in /etc/sysctl.d/
2023-04-20 10:03:21 <ncopa> have a look at /etc/sysctl.d/README
2023-04-20 10:04:59 <ncopa> then you run /etc/init.d/sysctl restart
2023-04-20 10:05:39 <psykose> or  sysctl -p /etc/sysctld./*
2023-04-20 10:05:54 <psykose> or sysctl --system with util-linux sysctl :D
2023-04-20 10:21:30 <ncopa> ghc done on aarch64
2023-04-20 10:24:46 <dzilvys> thank youuu
2023-04-20 10:57:48 <ncopa> build-3-18-s390x is done with rust and back online
2023-04-20 11:42:19 <ikke> qemu8 is out
2023-04-20 11:42:38 <ikke> and ofcourse psykose already upgraded it
2023-04-20 11:43:43 <psykose> aye
2023-04-20 11:43:44 <donoban> Is There Anything Faster Than Speed of psykose?
2023-04-20 11:43:49 <psykose> they seem to want to drop x86 host support
2023-04-20 11:43:53 <psykose> i.e. the x86 build
2023-04-20 11:43:57 <psykose> which is ok i guess
2023-04-20 11:44:01 <psykose> not sure who uses qemu on literally x86
2023-04-20 11:44:04 <psykose> (not target)
2023-04-20 11:44:08 <psykose> probably in a release or two
2023-04-20 11:44:55 <psykose> they also removed virtfsiod in favor of external project
2023-04-20 11:44:58 <psykose> so i packaged that
2023-04-20 11:45:22 <psykose> virtiofsd*
2023-04-20 13:16:59 <ncopa> awesome! thanks!
2023-04-20 14:49:26 <ncopa> kernel build fails for some weird reason
2023-04-20 14:50:04 <ncopa> sh: write error: Resource temporarily unavailable
2023-04-20 15:07:23 <psykose> sounds like rng
2023-04-20 15:15:18 <ncopa> could be. i think the running kernel was not corresponding to the installed, so I rebooted. lets see if it builds now
2023-04-20 15:16:33 <psykose> it could be out of file descriptors somewher else i guess right
2023-04-20 15:50:06 <ncopa> i killed kernel build of 3.18-x86_64
2023-04-20 15:50:43 <ncopa> since i updated the kernel version anyway. no need to build it twice
2023-04-20 15:51:23 <psykose> yep
2023-04-21 08:42:22 <ikke> Is this a correct patch? https://tpaste.us/7Mod
2023-04-21 08:43:26 <ikke> static const char *papszSOFilenames[]
2023-04-21 09:03:50 <ikke> I don't want to accidentally introduce (more) UB
2023-04-21 09:06:20 <pert> isn't using sprintf() like that the same as just doing strcpy()?
2023-04-21 09:11:59 <ikke> probably yes
2023-04-21 09:37:56 <skarnet> ikke: but why is that sprintf there in the first place? o.O
2023-04-21 09:41:07 <ikke> https://github.com/libogdi/ogdi/blob/master/contrib/gdal/gdalbridge.c#L111-L130
2023-04-21 09:41:12 <ikke> Don't ask me :p
2023-04-21 09:42:17 <ikke> just trying to fix a format-security error
2023-04-21 09:42:38 <skarnet> yeah, they're reusing szPath later
2023-04-21 09:43:18 <skarnet> your fix works for the format-security error but if you really want to harden it use snprintf() with 2048
2023-04-21 09:43:26 <skarnet> (the size of szPath)
2023-04-21 09:43:32 <ikke> Yeah, was thinking of that
2023-04-21 09:43:49 <skarnet> on all 3 sprintf invocations
2023-04-21 09:44:38 <skarnet> better hardening idea: git rm gdalbridge.c
2023-04-21 09:45:14 <ikke> It stops compiling though
2023-04-21 09:46:13 <skarnet> even better for security!
2023-04-21 09:46:37 <ikke> well, I'd not have to change anything then, as it already does not compile
2023-04-21 09:47:50 <skarnet> ship it
2023-04-21 09:48:57 <ovf> just remove `make -C contrib/gdal` from APKBUILD? that thing wouldn't have been able to load gdal in a decade or so anyway
2023-04-21 09:52:21 <Ermine> skarnet: router vendors literally ship firmware sources which.
2023-04-21 09:58:55 <ovf> how does one rebuild revdeps?
2023-04-21 10:35:00 <ptrc> ovf: you usually just bump pkgrel wherever needed
2023-04-21 10:35:27 <ptrc> in extreme cases, there's `ap revdep $pkgname | xargs apkgrel -a` or something
2023-04-21 10:36:34 <Ermine> s/which./which do not rebuild./
2023-04-21 10:43:09 <ptrc> ikke: any chance we could get https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/merge_requests/12 merged soon-ish?
2023-04-21 10:59:50 <ovf> ptrc: thanks, that confirms what i have figured out so far. manual or lua-aports' ap
2023-04-21 11:02:51 <ptrc> for shared libraries, you can also use `apk list -d 'so:libsomething.so.1'`
2023-04-21 11:03:14 <ptrc> that gives you the list of everything that depends on that specific library
2023-04-21 11:05:00 <ovf> ok, thanks! i got momentarily confused and thought i would only get that for locally installed packages
2023-04-21 11:09:32 <ovf> i'm trying to figure out the libtool story, started as a drive-by in !46264. at the very least, default_dev should claim the .la files (these currently end up in the base package). i'm still trying understand what ever needs them.
2023-04-21 12:13:53 <psykose> probably nothing
2023-04-21 12:24:43 <ovf> continuing to shave the yak, looks like with the way bwrap is set i can't rootbld packages that add users/groups -- as abuild-sudo protests to the bwrapped user not being a member of 'abuild'. fixing it i guess requires some sort of login-like program, like newgrp, sg, newgidmap, ...
2023-04-21 12:26:09 <psykose> yeah rootbld doesn't work with pkgusers/groups
2023-04-21 12:30:29 <ovf> i'm a bit surprised i'm ~the only one using it. i wouldn't trust a non-rootbld build on my system to capture the deps etc. correctly. do people generally just wait for ci to try things out?
2023-04-21 12:30:59 <ncopa> rust is done on x86_64
2023-04-21 12:31:25 <ptrc> ovf: you're definitely not the only one :p i just patched out some things in abuild locally to make rootbld less of a pain instead of waiting for upstream to fix bugs properly
2023-04-21 12:32:55 <psykose> no, i use it all the time
2023-04-21 12:33:00 <psykose> most things just don't set pkgusers/groups
2023-04-21 12:35:44 <pj> build without rootbld in container with docker or something
2023-04-21 12:36:56 <ovf> perhaps abuild-sudo could just do something else instead
2023-04-21 12:38:26 <psykose> it was already discussed in https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10094
2023-04-21 12:42:34 <ovf> thanks! i forget not everything happens on irc
2023-04-21 13:25:54 <PabloCorreaGomez[m]> Hi, is there some warranty in apk-tools of the order in which things are installed? So if a -> depends -> b -> depends -> c, is there a warranty that "c" will be installed before "b", before "a"?
2023-04-21 13:47:29 <psykose> you should ask that in apk-tools issues
2023-04-21 13:48:11 <PabloCorreaGomez[m]> Ok, thanks!
2023-04-21 14:36:13 <donoban> I have a POC for 10094 but needs litte fix and testing. ovf if you don't mind to add users/groups in your host you can simply revert https://gitlab.alpinelinux.org/alpine/abuild/-/commit/84d7b7693d44a95d4aba4ea44bd768e2512d92cb
2023-04-21 16:30:48 <umk3[m]> cannot install sakura terminal using latest edge, it asks for libicuuc.so.72 required by vte3-0.72.1-r0
2023-04-21 16:43:45 <ikke> wait until edge finishes rebuilding
2023-04-21 16:43:49 <ikke> edge/community
2023-04-21 16:44:03 <ikke> 16 / 265 (6%)
2023-04-21 16:57:54 <umk3[m]> thank you ikke no problem!
2023-04-21 16:58:08 <umk3[m]> notified just in case
2023-04-21 17:05:49 <psykose> might benefit from pausing 3.18 x86 just to get there faster xD
2023-04-21 17:15:57 <ikke> That server must be on fire, 2x qt5-qtwebengine
2023-04-21 17:16:19 <ikke> Load average: 84.60 85.71 86.13
2023-04-21 17:16:47 <psykose> it's also mostly old eh
2023-04-21 17:18:00 <psykose> ikke: i had the idea like yesterday- maybe we should swap the x86_64 builders to the dev container host that also does riscv64?
2023-04-21 17:18:04 <psykose> since that machine is like 2x faster
2023-04-21 17:18:07 <psykose> if not more
2023-04-21 17:18:30 <psykose> of course that would mean riscv64 goes back to being really slow on the opposite machine
2023-04-21 18:21:05 <psykose> ikke: is there a way i can change the username of my alpine-dev account so it matches my local one so i can just rsync things without doing name@
2023-04-21 18:21:26 <ikke> psykose: I can rename it for you I suppose
2023-04-21 18:21:39 <ikke> fyi, there is also ssh_config to set a username to use :)
2023-04-21 18:21:47 <psykose> aha
2023-04-21 18:21:51 <psykose> that works even better
2023-04-21 18:24:49 <psykose> though that doesn't work for rsync does it
2023-04-21 18:25:04 <psykose> i.e. rsync xyz host doesn't read the ssh config
2023-04-21 18:25:23 <psykose> ah
2023-04-21 18:25:26 <psykose> guess it has to match an entry
2023-04-21 18:26:16 <psykose> yeah
2023-04-21 18:26:19 <psykose> thanks
2023-04-21 18:28:00 <ikke> :)
2023-04-21 19:07:55 <psykose> PureTryOut: i decided to cleanup all the qt5-* kde clone stuff, and make them all use the 5.15.9-lts-lgpl tag etc
2023-04-21 19:08:03 <psykose> you cool with that or were you planning some other stuff
2023-04-21 20:56:23 <ncopa> im writing an email for alpine-devel, about feature freeze  for 3.18
2023-04-21 21:12:21 <ncopa> thank you all for amazing work that was done this week!
2023-04-22 06:48:13 <craftyguy> I noticed that a kernel compile on gitlab runner #145 is failing due to "no space left on device".  I've gotten this failure in two different jobs on that same runner: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/1016092#L10483
2023-04-22 06:51:02 <ikke> craftyguy: cleaned up docker on that host
2023-04-22 06:57:21 <craftyguy> ikke: thanks! I'll retry it
2023-04-22 23:37:42 <mio> is it okay to submit a newer version of mypaint-brushes as a separate package? my understanding is the current version in the repos (1.3.1) is the latest stable version and is used by Gimp (does Gimp support mypaint 2.0 brushes now?), while the latest stable version of mypaint requires 2.0 brushes
2023-04-22 23:40:09 <psykose> by mypaint do you mean libmypaint or something else
2023-04-22 23:40:31 <psykose> ah literal mypaint
2023-04-22 23:40:45 <mio> mypaint release notes explicitly links to 2.0.2 brushes https://github.com/mypaint/mypaint/releases/tag/v2.0.0
2023-04-22 23:40:51 <mio> yeah, mypaint the app
2023-04-22 23:41:19 <mio> was going to get mypaint-brushes the dep in first, got mypaint lined up next
2023-04-22 23:41:51 <mio> mypaint (the app) looks for mypaint-2.0.pc (or whatever the pkgconfig is called exactly) and won't build with 1.3.1
2023-04-22 23:42:24 <mio> it can still use libmypaint 1.6 so that one's okay
2023-04-22 23:44:10 <psykose> yeah seen the rest
2023-04-22 23:44:19 <psykose> added
2023-04-22 23:45:15 <mio> thanks, that was fast!
2023-04-22 23:45:43 <psykose> will take a while to build but you can use it locally all the same
2023-04-22 23:46:31 <psykose> as for gimp, gimp3 uses the new version
2023-04-22 23:46:48 <psykose> whenever that comes out
2023-04-22 23:47:07 <psykose> i remember running into the same thing a year ago
2023-04-22 23:51:55 <psykose> of course as for mypaint itself, this looks a bit scuffed :D
2023-04-22 23:52:09 <psykose> brushes are cool
2023-04-22 23:52:54 <mio> lol
2023-04-22 23:53:51 <mio> yeah, been using mypaint brushes indirectly in gimp, but missed mypaint ^^"
2023-04-22 23:58:10 <psykose> :)
2023-04-23 00:01:00 <mio> will wait a bit for mypaint-brushes2 to finish building to re-run the builders. the application works on x86_64, just have to confirm the arch it can be available on. tyvm :)
2023-04-23 00:05:20 <psykose> :)
2023-04-23 00:05:22 <psykose> yeah it builds
2023-04-23 00:31:51 <mio> psykose: would you like your name added under contributor? esp. for your suggestion with pyc()
2023-04-23 00:35:22 <psykose> nah it's ite
2023-04-23 00:36:22 <mio> okay, if you're sure, thanks ^^"
2023-04-23 06:09:19 <JSkilton> Mrs. Skilton gets her holes filled and satisified by Rush's Geddy Lee.  Later, Geddy meets Jean Pierre Manikariza, her husband, and gets filled by his big black cock!  Read all about it!  https://pastebin.com/1ExdrDQA
2023-04-23 16:31:48 <PabloCorreaGomez[m]> I'm trying to fix the issue with the appstream generator, and the backtrace really looks like a thread exhaustion. Since the crash happens on a simple free. I've tried building the generator with an increased stack with: 'LDFLAGS="$LDFLAGS -Wl,-z,stack-size=10485760"'. But it seems to still be crashing, and I don't see any virtual memory increase use with top (it's at 128G consistently) So any idea on how to make that increase
2023-04-23 16:31:48 <PabloCorreaGomez[m]> work with D? I've tried searching online for quite a while, with no luck
2023-04-23 16:33:56 <sam_> the crash happening on a free probably means something else
2023-04-23 16:34:04 <sam_> (freed memory is not on the stack, and the stack size issues tend to be an issue with recursion instead)
2023-04-23 16:34:10 <sam_> but ah, D
2023-04-23 16:35:20 <PabloCorreaGomez[m]> Oh, true. The code path where it crashes is certainly correct, though. The free cannot be an invalid one
2023-04-23 16:40:40 <PabloCorreaGomez[m]> Do you have any clue on where to look for?
2023-04-23 16:41:24 <sam_> could you show me what you're seeing? I'm really no D expert but I'm happy to try until someone else shows up
2023-04-23 16:45:38 <PabloCorreaGomez[m]> So this is the stack trace: https://justpaste.it/d5isn, and the crash happens here: https://github.com/ximion/appstream/blob/v0.16.1/compose/asc-utils-l10n.c#L383, which is called from D concurrent code. I can send the complete code-path if you want
2023-04-23 16:49:03 <PabloCorreaGomez[m]> And now I'm able to crash the generator with the exact same backtrace all the time, so maybe memory exhaustion is not the cause :/
2023-04-23 16:50:26 <sam_> how does the autofree thing work if locale gets set to tmp? is it smart enough to then not try autofree it? could you try follow the path it takes in gdb?
2023-04-23 16:50:54 <sam_> oh no that should be fine
2023-04-23 16:50:56 <sam_> weird
2023-04-23 16:52:34 <PabloCorreaGomez[m]> Yes, the way I'm reading the documentation, that should be fine. More like that code path is leaking "locale" if it gets assigned from "tmp"
2023-04-23 17:27:01 <PabloCorreaGomez[m]> Or maybe I've been reading the docs wrong and there's actually a bug in the code-path? Then maybe this is a different bug to the crash we've been getting in 3.16, but it has been running for longer than any other run now... So thanks sam for pointing me out of the memory exhaustion problem. I probably need to do more debugging before asking for help
2023-04-23 17:53:42 <psykose> PabloCorreaGomez[m]: what does readelf -n output for it
2023-04-23 18:00:14 <psykose> if it has a stack-size note then the ldflags worked (though of course not the issue)
2023-04-23 18:00:27 <psykose> anyway
2023-04-23 18:00:52 <psykose> idk what the lifetime of that locale is
2023-04-23 18:01:11 <psykose> the g_autofree is basically a __attribute__((cleanup)) with something that frees it at the end of scope
2023-04-23 18:02:02 <psykose> so it means at the time it runs, it was set back to null by something
2023-04-23 18:02:31 <psykose> well
2023-04-23 18:02:43 <psykose> https://github.com/ximion/appstream/blob/859c2a2658e13b2d689ad9bbdeaf6ff6fbba8abd/compose/asc-utils-l10n.c#L395https://github.com/ximion/appstream/blob/859c2a2658e13b2d689ad9bbdeaf6ff6fbba8abd/compose/asc-utils-l10n.c#L395
2023-04-23 18:02:47 <psykose> this also increments the pointer
2023-04-23 18:02:53 <psykose> idk if you can free that after validly
2023-04-23 18:02:59 <sam_> that's what i was questioning
2023-04-23 18:03:10 <psykose> i'm going to guess no
2023-04-23 18:04:11 <psykose> try replace `locale = tmp + 1;` with `somevar = 1`, init it to 0, and instead pass locale + somevar to asc_l10n_parse_file_qt
2023-04-23 18:04:29 <psykose> random guess
2023-04-23 18:04:40 <psykose> so the increment is not on the pointer
2023-04-23 18:38:12 <PabloCorreaGomez[m]> psykose: readelf -n outputs nothing
2023-04-23 18:38:56 <psykose> indeed the ldflags didn't work then
2023-04-23 18:39:39 <PabloCorreaGomez[m]> And I think you're in the right direction. The thing is that when locale gets re-assigned, it's not something that can be freed. It should be: free(locale); locale = g_strdup(tmp + 1);
2023-04-23 18:39:57 <PabloCorreaGomez[m]> I've patched it in a similar fashion, and seems to work
2023-04-23 18:40:51 <psykose> yeah, that's the same thing with more frees
2023-04-23 18:40:55 <psykose> that would work
2023-04-23 18:41:13 <PabloCorreaGomez[m]> Without the extra frees, you leak something, though
2023-04-23 18:41:40 <PabloCorreaGomez[m]> The thing is, that code has been there since version 0.14.something. I really wonder how did we end up hitting it now...
2023-04-23 18:43:29 <PabloCorreaGomez[m]> Ah, ok, I understand now you're pseudocode... You're right :)
2023-04-24 07:20:44 <ncopa> looks like the first 3.18 builder is done. winner is aarch64!
2023-04-24 07:36:49 <PureTryOut> 🎉
2023-04-24 07:37:10 <PureTryOut> And here I was expecting riscv64 😜
2023-04-24 07:39:14 <ncopa> riscv64 wasnt even in the competition
2023-04-24 07:39:29 <ncopa> we only do edge riscv64 atm
2023-04-24 07:39:59 <psykose> it still lost even though it had a few hundred packages to build instead
2023-04-24 07:53:01 <Misthios> rip
2023-04-24 07:55:39 <PureTryOut> awww
2023-04-24 08:23:35 <Newbyte> I'm sure it tried its best
2023-04-24 08:24:07 <psykose> it was just a pretender
2023-04-24 10:30:00 <ncopa> im gonna bootstrap ghc on x86_64 now
2023-04-24 10:30:38 <ikke> ack
2023-04-24 11:32:27 <ncopa> ghc done on x86_64
2023-04-24 13:53:30 <andypost[m]> Looks like build-edge-s390x hanging on prettier since last day
2023-04-24 13:58:52 <psykose> yes
2023-04-24 15:13:13 <ikke> It's admiring its prettiness
2023-04-24 16:58:55 <Ariadne> nmeum: any objection to including the output of `busybox --list-path` at `/etc/busybox-paths.d/$pkgname`?  it will help SCA tools (and also apko, which tries to avoid scripts) analyze and assemble alpine images
2023-04-25 07:29:42 <bratkartoffel> openjdk11 (https://pkgs.alpinelinux.org/package/edge/community/x86_64/openjdk11) was falsely flagged out of date, can someone mark it as uptodate again? thanks
2023-04-25 07:38:33 <psykose> it being marked doesn't really matter since it doesn't do anything special
2023-04-25 07:38:41 <psykose> just the usual flagged page spam
2023-04-25 07:39:29 <psykose> Ariadne: i typo'd list-path and realised that you can do `busybox --list-` and it gives the same output :D
2023-04-25 09:02:39 <Ariadne> psykose: sizecoding: not even once
2023-04-25 09:03:10 <psykose> :D
2023-04-25 09:03:29 <psykose> --list-bunnies
2023-04-25 09:11:17 <Ariadne> btw, re: risc-v servers, there is the veyron coming out later this year
2023-04-25 09:11:37 <Ariadne> up to 192 cores on an SoC
2023-04-25 09:15:09 <psykose> definitely for sure this time
2023-04-25 09:15:26 <psykose> is it 8ghz too and 10x faster than x86?
2023-04-25 09:15:37 <psykose> :)
2023-04-25 10:07:00 <liske> psykose: thanks for the help with the pypy packages :-)
2023-04-25 10:07:05 <psykose> np :)
2023-04-25 10:07:12 <psykose> i cleaned that up so now it's identical to regular python
2023-04-25 10:07:23 <psykose> still works to build cexts and stuff, i tested a pip install of numpy with it in a venv
2023-04-25 10:10:15 <liske> i wonder if pypy should be moved to community
2023-04-25 10:10:56 <psykose> sounds cursed
2023-04-25 10:11:55 <liske> and we need pypy3-* packages to make pypy3 more useful
2023-04-25 10:20:24 <psykose> rejected
2023-04-25 10:20:58 <psykose> definitely don't want a bunch of repetitive bunch of another 10,000 python modules just for pypy
2023-04-25 10:21:02 <psykose> people can use pip with it just fine
2023-04-25 11:00:42 <liske> I'm not talking about all py3-* packages ;) - but if a packaged cli command/daemon should work with pypy3 it needs its dependencies. I'm thinking about ifstate here, where it might make sense for routers with large routing tables... (benchmark cpython3 vs. pypy3 pending)
2023-04-25 11:06:24 <psykose> i am responding to what you are talking about
2023-04-25 11:25:07 <ovf> i just did `git commit-graph write --reachable --changed-paths` and walking ancient history (e.g. git log) became much faster
2023-04-25 11:48:02 <psykose> ovf: hmm
2023-04-25 11:48:09 <psykose> is there a way to make git do something like that as maintenance
2023-04-25 12:54:46 <andypost[m]> iirc it doing GC so should be extendable
2023-04-25 12:59:55 <psykose> i don't think gc calls that
2023-04-25 13:00:49 <psykose> scripted it i guess
2023-04-25 13:00:51 <psykose> https://img.ayaya.dev/MjpZjxx1Li8t
2023-04-25 13:00:52 <psykose> :)
2023-04-25 13:06:29 <andypost[m]> nice
2023-04-25 13:24:06 <ikke> git maintenance run
2023-04-25 13:25:03 <ikke> https://git-scm.com/docs/git-maintenance#documentation/
2023-04-25 13:29:38 <andypost[m]> The build-3-18-s390x builder looks hanging since last night
2023-04-25 13:33:17 <psykose> i know of git maintenance run but it does not really say what it's doing
2023-04-25 13:33:44 <psykose> maintenance.commit-graph is certainly `git commit-graph`, but what exactly? doesn't say
2023-04-25 13:33:57 <psykose> i bet it is not like the above :)
2023-04-25 13:49:17 <ikke> It can setup a cronjob that uses git for-each-repo to run specified maintenance tasks
2023-04-25 14:12:29 <durrendal> psykose: would you have any issues moving py3-looseversion to community alongside salt?
2023-04-25 14:12:43 <durrendal> really just need it so my saltstacks don't break :)
2023-04-25 14:13:32 <psykose> already done
2023-04-25 14:13:40 <durrendal> <3 you rock
2023-04-25 14:13:56 <psykose> there was a seemingly missing pycryptodomex too, and packaging, but they might've been indirect
2023-04-25 14:14:18 <psykose> ikke: yeah, that itself might work
2023-04-25 14:15:41 <durrendal> yeah both of those should be deps on salt. I'm gonna make another MR to add them in just a minute
2023-04-25 14:17:00 <psykose> i did already :D
2023-04-25 14:17:53 <durrendal> :D you're killing it over here!
2023-04-25 14:18:02 <durrendal> thank you so much psykose!
2023-04-25 15:56:50 <ovf> there also seems to be fetch.writeCommitGraph
2023-04-25 15:57:40 <psykose> there is
2023-04-25 15:57:45 <psykose> but it's better to background maintenance
2023-04-25 15:57:46 <ikke> I have set that to true locally
2023-04-25 15:57:55 <psykose> that's also not the same as that command :D
2023-04-25 15:58:27 <ovf> yes, there doesn't seem to be a way to pass --changed-paths
2023-04-25 19:37:44 <ikke> PabloCorreaGomez[m]: I've deployed the new image
2023-04-25 20:50:45 <PabloCorreaGomez[m]> Thanks a lot! Hopefully tonight we get new data :D
2023-04-25 20:55:57 <psykose> fresh from the fields
2023-04-26 08:33:18 <ovf> what are the people's feelings towards 'task' metapackages, like e.g. wayland-desktop (that'd install_if qt6-qtbase qt6-qtwayland) or fat-desktop (that'd pull all the optional stuff, like gdk-pixbuf-loaders)? i think that's one alternative to optional depends
2023-04-26 11:33:11 <ptrc> does anyone have any idea why does python3 depend on itself?
2023-04-26 11:33:16 <ptrc> depends*
2023-04-26 11:34:19 <ptrc> also, i feel betrayed, .log.gz files on buildlogs are served as plaintext by the server
2023-04-26 11:35:10 <ptrc> anyways, oddly enough, python3 gets itself as a traced dependency
2023-04-26 15:18:26 <psykose> because it's added anytime anything has a usr/lib/python
2023-04-26 15:18:34 <psykose> does it break something :p
2023-04-26 15:19:53 <psykose> also yeah the server stores gz but serves plaintext i guess
2023-04-26 15:20:03 <psykose> although is there no way to make it send gz
2023-04-26 16:34:48 <nmeum> if a package upgrade fixes a CVE in a vendored library, do we normally include the corresponding CVE in the secfixes comment?
2023-04-26 16:35:15 <psykose> not really
2023-04-26 16:35:25 <psykose> i don't see that much use in doing it either
2023-04-26 16:35:43 <ikke> keeping the security scanners at bay :P
2023-04-26 16:35:54 <psykose> usually the published data in itself is enough, and we could instead add metadata, though idk how it works for golang
2023-04-26 16:36:06 <psykose> for rust for instance, we could replace every cargo build with cargo-auditable build
2023-04-26 16:36:10 <psykose> and it embeds the dep versions
2023-04-26 16:36:23 <psykose> and that in itself tracks it, you wouldn't need manual secfixes at all
2023-04-26 16:36:35 <psykose> i really hate the secfixes approach tbf :p
2023-04-26 16:37:10 <ikke> Ideally you'd only add it in case you patch it yourself
2023-04-26 16:37:13 <psykose> the only thing it's useful for is manual backports
2023-04-26 16:37:14 <psykose> yeah
2023-04-26 16:37:24 <psykose> and yet for some reason 95% of the added secfixes we have are not for that
2023-04-26 16:38:11 <ikke> people (started to) assume that secdb has info about all CVEs
2023-04-26 16:38:37 <psykose> well that's easy, we (start to) tell them that's not the case, something something
2023-04-26 16:39:01 <ikke> I can already imagine the flood of issues we get when we stop / remove that
2023-04-26 16:39:18 <psykose> they are welcome to pay for alpine pro (+ security tracking fee)
2023-04-26 16:39:41 <psykose> mirroring the full data is whatever anyway, well, difficulty aside
2023-04-26 16:39:43 <psykose> that is 'ok'
2023-04-26 16:39:59 <psykose> it's just the manual aspect that is unworkable to actually add it by hand per package for whatever reason
2023-04-26 16:40:17 <ikke> the secfix tracker already marks something as fixed if it's outside of the vulnerable version (given that that info is available)
2023-04-26 16:40:29 <psykose> yeah, something like that
2023-04-26 16:40:36 <ikke> And at some point the information is no longer relevant
2023-04-26 16:40:46 <ikke> but now we keep it forever
2023-04-26 16:47:06 <nmeum> alright
2023-04-26 16:55:03 <mio> psykose: tyvm for the fixes! ^^"
2023-04-26 16:55:16 <psykose> :)
2023-04-26 17:35:37 <psykose> ikke: where was the secdb exclusions again
2023-04-26 17:37:42 <ikke> yhttps://gitlab.alpinelinux.org/ariadne/security-rejections
2023-04-26 17:37:45 <ikke> https://gitlab.alpinelinux.org/ariadne/security-rejections
2023-04-26 17:39:45 <psykose> hmm
2023-04-26 17:39:46 <psykose> are you sure
2023-04-26 17:40:00 <psykose> i remember nmeum added something recently but this is untouched for forever
2023-04-26 17:41:50 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/secfixes-tracker/-/merge_requests/8
2023-04-26 17:42:03 <ikke> That's not a rejection but a rewrite
2023-04-26 17:42:05 <psykose> aha
2023-04-26 17:42:11 <psykose> is there something we do for withdrawn?
2023-04-26 17:42:16 <psykose> excluding e.g. https://security.alpinelinux.org/vuln/CVE-2022-3555 seems pointless
2023-04-26 17:42:19 <psykose> can't it just be removed
2023-04-26 17:45:31 <psykose> (there's a ton of those)
2023-04-26 17:46:22 <ikke> Based on what should it be removed?
2023-04-26 17:46:38 <ikke> the security-rejections is basically a global ignore
2023-04-26 17:48:26 <psykose> wdym based on what
2023-04-26 17:48:34 <psykose> > ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. 
2023-04-26 17:48:42 <psykose> but it's marked as vulnerable which is annoying
2023-04-26 18:36:31 <mio> psykose: what's the recommendation for including optional dependencies? initially was looking to build the executables in a way that allows users to install additional packages if they want to enable a certain feature, but it seems by including the -dev packages beforehand for build, the lib version is automatically pulled in during install? or is that not the case? sorry for
2023-04-26 18:36:33 <mio> the newb question, asking as I'm not sure I understand how dependency tracing works
2023-04-26 18:36:46 <psykose> they're not optional
2023-04-26 18:37:29 <mio> they are in the sense that it would warn but should still build without some of the -dev packages?
2023-04-26 18:37:38 <psykose> no, like
2023-04-26 18:37:43 <psykose> the binary links the libraries
2023-04-26 18:37:50 <psykose> it will not start if you removed the library
2023-04-26 18:37:55 <psykose> there's nothing optional about it
2023-04-26 18:38:14 <psykose> building the support (linking it at all) is optional, sure, but then it's always missing
2023-04-26 18:40:50 <mio> okay, in that case it def makes sense. from the project docs my interpretation was they were opportunistically linked/optional, like qt5-qtkeychain (which it couldn't find when the lib not -dev package is included but still builds anyway without it). didn't realise the binary wouldn't run without all of them
2023-04-26 18:41:30 <psykose> yeah, they're optional as things to build against- not at runtime
2023-04-26 18:42:19 <psykose> then linked normally, added as NEEDED to the dynamic elf section, traced by abuild, added as a dependency, required at runtime or loading the binary would fail due to NEEDED failing to resolve, ..
2023-04-26 18:42:42 <psykose> the way things usually do optional plugin support (offtopic) is one of three ways of varying lazyness
2023-04-26 18:42:51 <psykose> - using cli commands and exec instead of a library
2023-04-26 18:43:13 <psykose> - dlopen() of a library name (this is very fragile because there is no guarantee what you open is what you expect), instead of linking
2023-04-26 18:43:54 <psykose> - dlopen() of your own plugin (i.e. you make a drawpile-giflib.so), that links the library (compile-time guarantees) in the same way, but people can split out the plugin .so to a subpackage, and then if it's not there the 'support is missing' but it can be added separately
2023-04-26 18:44:20 <psykose> 2,3 also prevent static linking since you lose dlopen
2023-04-26 18:49:13 <mio> okay. does that mean that generally, if a packager builds against certain libs that are theoretically optional, that makes them not optional anymore at runtime? for packaging, is the practice to prefer including more libs to support more features, treating them as non-optional, or make a decision on what is a good default and add only when requested? e.g. if qt5-keychain adds
2023-04-26 18:49:15 <mio> password saving for the client and could be enabled
2023-04-26 18:49:48 <ikke> mio: that's one of the more difficult decissions
2023-04-26 18:50:45 <mio> s/qt5-keychain/qt5-qtkeychain/
2023-04-26 18:50:56 <mio> ikke: ah ^^"
2023-04-26 18:56:18 <psykose> last one yeah
2023-04-26 18:59:46 <fullmetalScience[m]> What's causing this error with abuild? http://pastie.org/p/44RTddQqyL1XcGuQBInhvW
2023-04-26 19:00:05 <ikke> You did not place anything in $pkgdir
2023-04-26 19:00:57 <mio> psykose: okay. to confirm, anything that's traced in the tracing deps list don't need to be added as depends? you mentioned something about the tracing before, but I may gotten confused about libs (non -dev packages) in depends, vs. what gets automatically pulled when added in makedepends
2023-04-26 19:01:11 <ikke> mio: that's correct
2023-04-26 19:01:18 <psykose> ye
2023-04-26 19:02:41 <fullmetalScience[m]> What should I put there? Didn't I provide all required infos already in the APKBUILD?
2023-04-26 19:02:49 <fullmetalScience[m]> -s
2023-04-26 19:04:05 <ikke> fullmetalScience[m]: that's where you install the files that should be included in the package (in the structure as they will end up when installing the package)
2023-04-26 19:04:27 <mio> ikke, psykose: thanks :) is there a difference between adding a package to makedepends globally vs in the subpackage block? libmicrohttpd is in global, but think that was for the server binary only (may be wrong though), and qt5-qtbase-sqlite is def server only and that is in the server() block
2023-04-26 19:04:44 <ikke> mio: makedepends need to be global
2023-04-26 19:04:56 <ikke> (makedepends for subpackages do not really make sense anywya)
2023-04-26 19:05:17 <mio> right, so qt5-qtbase-sqlite wasn't a dev package anyway
2023-04-26 19:05:41 <psykose> that's an optional qt5 plugin that qt itself loads if you try to use it for sqlite
2023-04-26 19:05:56 <psykose> option 3 from the list above :p
2023-04-26 19:06:42 <mio> ikke: thanks, that makes more sense in light of building everything in package() then moving the pieces to the subpackages
2023-04-26 19:07:11 <mio> psykose: ah! okay, thanks ^^"
2023-04-26 19:07:57 <mio> s/building/storing first/
2023-04-26 19:09:19 <mio> ty both, will try to remember this for next time ^^"
2023-04-27 01:51:34 <WhyNotHugo> Why is https://lists.alpinelinux.org/~alpine/aports offline? Is the integration currently broken?
2023-04-27 01:53:22 <psykose> ye
2023-04-27 01:53:26 <psykose> well
2023-04-27 01:53:42 <psykose> literally yes (the integration was broken in a gitlab upgrade since they changed some api stuff around)
2023-04-27 01:53:53 <psykose> but also it never worked to begin with (all it could do is open a merge request)
2023-04-27 01:54:47 <psykose> so what happened 90% of the time is someone (me) would review a merge request, and i would get a reply of a v2 patch to my comment because there is no integration for that
2023-04-27 01:55:13 <psykose> you had to make a 'new patch' and hence new merge request each time
2023-04-27 01:55:15 <psykose> worse than useless
2023-04-27 01:55:27 <WhyNotHugo> lol. I was wondering if a v2 would update the MR.
2023-04-27 01:55:31 <WhyNotHugo> Where's the source for the integration?
2023-04-27 01:56:02 <psykose> hmmm
2023-04-27 01:57:28 <psykose> i can't seem to find it but ikke would remember
2023-04-27 01:59:18 <WhyNotHugo> How would you hack on it though? You run a local GitLab instance?
2023-04-27 02:00:32 <psykose> from what i hear, probably
2023-04-27 02:00:51 <psykose> iirc gitlab publishes a "docker container" that "just runs lol" and you can use that for development of random stuff
2023-04-27 02:01:06 <psykose> personally i never looked at the docs for more than 2 minutes and have no idea
2023-04-27 02:02:01 <psykose> for integration with us we have a gitlab-test as well i guess, but you'd have to talk to ikke to get anywhere
2023-04-27 05:04:27 <ikke> WhyNotHugo: https://git.sr.ht/~sircmpwn/dispatch.sr.ht
2023-04-27 05:05:10 <ikke> https://git.sr.ht/~sircmpwn/dispatch.sr.ht/tree/master/item/dispatchsrht/tasks/gitlab/patch_to_gitlab_mr.py
2023-04-27 05:06:48 <psykose> nmeum: gonna start rebasing gcc13
2023-04-27 05:07:09 <psykose> pushed a 13.1 with nothing rebased in it yet so i can open a pull request against it (can't create a branch as part of one)
2023-04-27 05:13:01 <psykose> algitbot: give me fire
2023-04-27 05:13:21 <psykose> scuffed callbacks
2023-04-27 05:13:46 <psykose> that's it lads
2023-04-27 05:13:52 <psykose> i think it's time to rewrite algitbot in rust
2023-04-27 05:19:01 <sam_> there's 2 miscompilation fixes on releases/gcc-13 you should include
2023-04-27 05:20:03 <psykose> yeah, i'm just taking latest branch
2023-04-27 05:20:13 <psykose> it's what we did before more or less, just nobody has really touched it in a while
2023-04-27 05:20:16 <psykose> good opportunity
2023-04-27 05:34:00 <psykose> algitbot: ping
2023-04-27 05:51:49 <psykose> seems our patchset went from 54 to 34 after the rebase
2023-04-27 05:51:53 <psykose> which is a bit suspicious :)
2023-04-27 05:51:57 <psykose> maybe i didn't pick this correctly
2023-04-27 06:58:33 <nmeum> psykose: nice, thanks!
2023-04-27 06:58:57 <nmeum> though we should wait with the 13.1 upgrade until 3.18 is released, right?
2023-04-27 06:58:59 <psykose> first broken thing is that d mode_t thing that is broken now
2023-04-27 06:59:00 <psykose> yeah
2023-04-27 06:59:02 <psykose> until split
2023-04-27 07:15:04 <ncopa> yes, please wait with gcc-13 til after alpine 3.18 is branched (3.18.0 is released)
2023-04-27 07:16:09 <psykose> i thought that much was really obvvious :p
2023-04-27 07:18:00 <ncopa> you never know...
2023-04-27 07:18:13 <psykose> :)
2023-04-27 07:18:30 <psykose> i was planning to rebuild most of edge a bit after testing 13 a bit, since we never really rebuild edge
2023-04-27 07:18:40 <psykose> perhaps maybe after someone added relr to aarch64 or something tho
2023-04-27 07:18:48 <sam_> chromium needed like 20 patches
2023-04-27 07:18:59 <psykose> for what
2023-04-27 07:19:01 <sam_> 13
2023-04-27 07:19:04 <psykose> we use clang
2023-04-27 07:19:07 <sam_> poop
2023-04-27 07:19:10 <psykose> :D
2023-04-27 07:19:14 <sam_> do u use libcxx or libstdc++
2023-04-27 07:19:17 <psykose> latter
2023-04-27 07:19:21 <sam_> ok unpoop
2023-04-27 07:19:31 <psykose> i check the gcc chromium repo thing for that
2023-04-27 07:19:35 <psykose> so it's mostly easy
2023-04-27 07:20:04 <psykose> for electron the former only because it is kinda very scuffed and there are some real subtle broken things in there that don't work on libstdc++
2023-04-27 07:44:18 <ncopa> I have done some changes on linux kernel. the linux-lts-dev package is 30MB smaller. I deleteted some thing I thought we dont need
2023-04-27 07:44:43 <ncopa> i re-enabled DEBUG_INFO_BTF
2023-04-27 07:45:00 <ncopa> which increases the size a bit
2023-04-27 07:45:22 <ncopa> linux-lts 101MB -> 120 MB
2023-04-27 07:47:35 <psykose> was it really that bad
2023-04-27 08:19:57 <ncopa> Not sure if that was the only thing increasing it
2023-04-27 09:06:51 <donoban> psykose: do you expect !45631 merged for 3.18? if yes I could write something about it on releases notes
2023-04-27 09:20:08 <ncopa> kunkku: nice work on the nlplug-findfs tests!
2023-04-27 09:20:28 <ncopa> i wonder if it would make sense to move nlplug-findfs to its own git repo
2023-04-27 09:20:32 <ncopa> and its own package
2023-04-27 09:21:26 <ncopa> the challenge at hand is that I am adding tests for the scripts, and they run in a second, while the qemu stuff takes half an hour
2023-04-27 09:32:06 <kunkku> yes, running the qemu stuff is not very practical on each build
2023-04-27 09:33:29 <kunkku> the other option is to have separate make target for it
2023-04-27 09:33:51 <ncopa> that i already did
2023-04-27 09:34:17 <ncopa> i think we can parallelize it a bit to but thats a project for another day
2023-04-27 09:38:22 <kunkku> are you using qemu to test the scripts too?
2023-04-27 09:42:02 <ncopa> no
2023-04-27 09:42:15 <ncopa> just atf-sh
2023-04-27 09:42:24 <ncopa> and kyua
2023-04-27 09:56:39 <ikke> kunkku: the prefix is fde7:4eeb:852a::/48
2023-04-27 10:07:31 <ncopa> I would like to backport this: https://github.com/OpenRC/openrc/pull/467 and enable wipe_tmp by default again
2023-04-27 14:08:43 <ncopa> 248G free now on nld8. 69%
2023-04-27 14:09:30 <ncopa> rebooting it now
2023-04-27 14:10:13 <ikke> great
2023-04-27 14:36:00 <PabloCorreaGomez[m]> ikke: The appstream generator is up and working again! Seems like the deployment worked, thanks a lot! :D
2023-04-27 14:36:21 <ikke> PabloCorreaGomez[m]: You as well for fixing it :)
2023-04-27 14:39:12 <PabloCorreaGomez[m]> :)
2023-04-27 20:58:34 <umk3[m]> some applications icons broke with latest librsvg I believe
2023-04-27 21:04:15 <ptrc> hey, does anyone want to take over maintainership of community/drone? i don't run an instance anymore, so it's a bit hard to test new releases
2023-04-27 21:04:38 <psykose> iirc it wasn't even very usable anymore since the whole woodpecker thing
2023-04-27 21:04:50 <psykose> since the oss version has 0 features
2023-04-27 21:05:04 <ptrc> move to unmaintained then? :p
2023-04-27 21:15:09 <psykose> dunno
2023-04-27 21:16:13 <ikke> ref: https://woodpecker-ci.org/faq#why-is-woodpecker-a-fork-of-drone-version-08
2023-04-27 21:16:35 <ikke> so drone will not get new versions anymore?
2023-04-27 21:16:41 <ikke> (that we can ship)
2023-04-27 21:25:04 <psykose> it's a go-tag thing
2023-04-27 21:25:18 <psykose> have to build with -tags oss that disables most of it
2023-04-27 21:27:27 <psykose> there are updates aside from that, never made a comparison of how many features there are except 'way less'
2023-04-28 09:23:32 <ncopa> im working on hledger-interest
2023-04-28 13:31:03 <ncopa> all 3.18 builders are done!
2023-04-28 13:36:44 <ikke> 🎉
2023-04-28 15:45:30 <bl4ckb0ne> psykose: filters seems to be missing from the aerc update
2023-04-28 15:45:40 <bl4ckb0ne> the /usr/share/aerc/filters folder is empty
2023-04-28 15:46:26 <bl4ckb0ne> ah nice they went into libexec
2023-04-28 15:47:15 <bl4ckb0ne> but aerc still looks int XDG paths and share/aerc
2023-04-28 15:47:17 <bl4ckb0ne> great
2023-04-28 18:55:06 <psykose> bl4ckb0ne: yeah, they moved them
2023-04-28 18:55:10 <psykose> and also deprecated half the config
2023-04-28 18:59:37 <ptrc> https://tpaste.us/6MKZ?hl=true
2023-04-28 19:00:01 <ptrc> ..apparently that's what breaks all the github patches
2023-04-28 19:03:35 <bl4ckb0ne> yeah spent 30 mins fixing my shit
2023-04-28 19:11:45 <psykose> ptrc: i think fd11 is a bad place, you want to use like fd23
2023-04-28 19:12:04 <psykose> bl4ckb0ne: it gave me a distraction to change the theme around :p
2023-04-28 19:12:21 <psykose> probably one of the few softwares that actually tell you how to migrate instead of breaking on startup
2023-04-28 19:12:26 <psykose> filters aside
2023-04-28 19:12:53 <bl4ckb0ne> kek
2023-04-28 19:12:58 <bl4ckb0ne> yeah the popup was vnice
2023-04-29 00:30:09 <sam_> psykose: <3 thanks
2023-04-29 00:30:15 <sam_> psykose: also real debian moment re libxml2
2023-04-29 00:30:25 <sam_> i swear to god
2023-04-29 00:30:29 <psykose> :)
2023-04-29 00:30:30 <sam_> every time i see "i scanned the debian archives and.."
2023-04-29 00:30:50 <psykose> tbf it's better than no scanning
2023-04-29 00:31:12 <sam_> war crime apologist much??
2023-04-29 00:31:18 <psykose> :D
2023-04-29 00:31:24 <psykose> shit like https://gitlab.gnome.org/GNOME/libxml2/-/commit/ce76ebfd1312459951d555ad9d87fb9a89eede55 also removed some struct api
2023-04-29 00:32:01 <psykose> no idea what checked was used for or how it relates to ent->flags |= XML_ENT_CHECKED;
2023-04-29 00:32:09 <psykose> latter is loop and former is ?
2023-04-29 03:09:16 <sam_> no clue
2023-04-29 03:09:18 <sam_> and honestly
2023-04-29 03:09:26 <sam_> i'm just going ot wait this out
2023-04-29 03:09:29 <sam_> this is a mess and a half
2023-04-29 03:12:27 <psykose> i should've probably done the same
2023-04-29 03:12:38 <psykose> but i rebuilt everything instead so that's gonna take a day
2023-04-29 03:12:39 <psykose> unlucky
2023-04-29 03:26:39 <andypost[m]> FYI building PHP fails few xml-related tests now
2023-04-29 03:39:32 <psykose> sam_: i'm also not 200% sure about the valgrind malloc-patch thing, but i did some sanity tests and it works like before for regular and works instead of not working for LD_PRELOAD interposed leaks
2023-04-29 03:39:40 <psykose> which is nice i guess :)
2023-04-29 03:40:12 <sam_> the part which made me unsure was i tried to trace through the patch which definitely helped (not the one we dropped, the one upstream) <-> the bit where the patch we drop intersect, and got absolutely 100% lost
2023-04-29 03:40:42 <sam_> definitely nice
2023-04-29 03:50:06 <psykose> sam_: the one that gets rid of the context is mostly https://sourceware.org/git/?p=valgrind.git;a=blobdiff;f=coregrind/m_replacemalloc/vg_replace_malloc.c;h=c46e719c94ac1f362925f9d268a8f86ec1f70a09;hp=3379aa96f785274a998878b4099be55b4a4cf1f1;hb=50bded71b23cb11a8b6c1b6eaf6e3abcc05a06c2;hpb=4af62304d95701ed110f4ba89c5a9ceeb0255393 afaict
2023-04-29 03:50:56 <sam_> OH
2023-04-29 03:51:02 <sam_> thanks that makes a lot more sense now
2023-04-29 03:51:05 <psykose> cd20c3c60433fd20b7e57723575a5944dc6ae42f is the context
2023-04-29 03:51:09 <psykose> .. :D
2023-04-29 03:51:15 <psykose> for why it was there originally
2023-04-29 03:51:46 <psykose> i am perhaps confused again
2023-04-29 03:52:00 <sam_> no i think you're right
2023-04-29 04:31:46 <sam_> btw
2023-04-29 04:31:49 <sam_> musl.supp is upstream now iirc
2023-04-29 04:32:10 <sam_> https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-util/valgrind?id=16fa81ac4ea8e35dd4444a5cfa19f758b785a49a
2023-04-29 04:32:18 <sam_> diff yours/theirs tho
2023-04-29 04:32:38 <sam_> it's nice that after like 10 years they got interested in musl
2023-04-29 04:33:10 <psykose> i checked but couldn't find where that thing was
2023-04-29 04:33:22 <psykose> aha
2023-04-29 04:33:24 <psykose> it's just there
2023-04-29 04:33:42 <psykose> uhh
2023-04-29 04:33:46 <psykose> this is /literally/ the same file
2023-04-29 06:10:28 <psykose> sam_: have you heard of some weird m4 thing where it allocs like infinite memory and ooms
2023-04-29 06:11:56 <psykose> hm
2023-04-29 06:12:45 <psykose> it was related to some old m4 macro for detecting libxml without .pc against the new libxml
2023-04-29 06:14:31 <sam_> like m4 itself or weird OOMs with configure? for the latter, i've seen it a lot with shit trying to call ada, because it does something like: check for ada -> call clang -> clang calls out to gcc to do ada -> gcc for some reason calls clang -> ...
2023-04-29 06:14:36 <sam_> i don't think i've seen something for just m4 though
2023-04-29 06:14:37 <sam_> that's weird
2023-04-29 06:15:03 <psykose> nah, purely m4 itself
2023-04-29 06:15:21 <psykose> specifically this weird thing called 'dvdauthor' against new libxml in autoreconf
2023-04-29 06:15:59 <psykose> before this change https://github.com/ldo/dvdauthor/commit/45705ece5ec5d7d6b9ab3e7a68194796a398e855
2023-04-29 06:16:19 <psykose> that fixes it by not using m4 i guess, though idk what it's doing otherwise
2023-04-29 06:16:55 <psykose> if you can repro it it sounds like something very cursed
2023-04-29 06:21:48 <sam_> repro'd
2023-04-29 06:22:02 <sam_> the fuck is going on
2023-04-29 06:26:05 <psykose> maybe this project has some bizarro file in a corner
2023-04-29 06:26:24 <psykose> this doesn't happen against 2.10 libxml i don't think tho
2023-04-29 06:26:29 <psykose> hmm
2023-04-29 06:26:47 <sam_> it's because of the .m4 change in https://gitlab.gnome.org/GNOME/libxml2/-/commit/d598d8af0913b6e3d4e61ffa62397a275b669dca, i'm "bisecting" the .m4 file
2023-04-29 06:27:01 <psykose> yeah yeah
2023-04-29 06:27:22 <psykose> that's like the whole change
2023-04-29 06:27:29 <psykose> the whole file is empty now and just calls pc
2023-04-29 06:27:32 <sam_> AC_DEFUN([AM_PATH_XML2],[
2023-04-29 06:27:33 <sam_>   AC_MSG_WARN([AM_PATH_XML2 is deprecated, use PKG_CHECK_MODULES instead])
2023-04-29 06:27:33 <sam_> ])
2023-04-29 06:27:35 <sam_> it spins on that even
2023-04-29 06:28:20 <sam_> quoting AM_PATH_XML2 and PKG_CHECK_MODULES works
2023-04-29 06:28:22 <sam_> i think it's expanding to itself
2023-04-29 06:28:27 <sam_> i don't get why it does in a [] tho
2023-04-29 06:28:28 <sam_> lol
2023-04-29 06:28:34 <sam_> cringe 
2023-04-29 06:29:01 <sam_>   AC_MSG_WARN([[AM_PATH_XML2] is deprecated, use PKG_CHECK_MODULES instead]) is ok
2023-04-29 06:29:04 <sam_> what a joke
2023-04-29 06:29:28 <psykose> hmmm
2023-04-29 06:29:52 <psykose> this seems like a really weird m4 thing
2023-04-29 06:32:56 <psykose> [AM_PATH_XML2] also isn't valid since it just tells you that is undefined later
2023-04-29 06:34:57 <sam_> lame
2023-04-29 09:39:28 <psykose> sam_: if you run the tests for libxml++-2.6 against it you'll find a juicy sigsegv at parser.c:4503 of *in being overran somewhere and derefd
2023-04-29 09:39:34 <psykose> you find that out for me i'm too tired
2023-04-29 10:04:33 <psykose> same for 5.0 i guess
2023-04-29 10:14:07 <psykose> hm, figured that out
2023-04-29 10:18:20 <psykose> nvm
2023-04-29 10:18:56 <psykose> interestingly no overrun with another allocator
2023-04-29 11:41:05 <Hello71> it should use m4_warn instaed
2023-04-29 19:51:38 <Arnavion> Is there any way I can package something when the upstream is on cgit and has disabled snapshots? ie there is no ".../snapshot/..." URL to download a source tarball from, so the only way to get the source is to `git clone`. Of course I could set up a GitHub mirror or something but that would be icky
2023-04-29 20:17:56 <sam_> what was it psykose 
2023-04-30 01:14:15 <psykose> sam_: no clue
2023-04-30 01:14:17 <psykose> still there
2023-04-30 21:09:33 <andypost[m]> someone spammed https://pkgs.alpinelinux.org/flagged
2023-04-30 21:31:42 <pj> as usual