2023-07-01 05:56:06 <Arnavion> https://paste.rs/6B2rR   Hmm, rustc is unhappy with the unicode-ident crate ( rust-1.70.0-r3 , llvm16-libs-16.0.6-r3 )
2023-07-01 05:56:51 <psykose> classic
2023-07-01 05:57:19 <Arnavion> The patches you added in -r3 don't *seem* related
2023-07-01 05:57:32 <psykose> they're not no
2023-07-01 05:58:25 <psykose> well
2023-07-01 05:58:30 <psykose> you can try remove 9004 9011 and find out
2023-07-01 05:59:50 <Arnavion> Compiling llvm zzz
2023-07-01 05:59:55 <Arnavion> I'll do it tomorrow
2023-07-01 05:59:57 <psykose> you can also try -fno-stack-clash-protection just in case that affects it (new as well)
2023-07-01 06:00:04 <psykose> yea i got no speedy hardware for a bit either
2023-07-01 06:00:05 <psykose> and it's 8am
2023-07-01 08:01:00 <agris> does stack clash protection really add that much of a performance penalty?
2023-07-01 08:01:36 <psykose> who said that where
2023-07-01 17:18:54 <ikke> RIP unmaintained :P
2023-07-01 17:20:03 <psykose> rest in parliament
2023-07-03 01:06:00 <pj> psykose: could you move musikcube to community/main pretty pleaseeee
2023-07-03 01:06:11 <psykose> why
2023-07-03 01:06:22 <pj> so it's not in testing
2023-07-03 01:45:27 <bl4ckb0ne> did you tested it thouroughly
2023-07-03 05:50:14 <Arnavion> vvmd needs a rebuild after the libphonenumber protobuf change, I guess. It crashes with   >Error relocating /usr/bin/vvmd: _ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaEb: symbol not found
2023-07-03 05:50:49 <Arnavion> Same with chatty
2023-07-03 05:51:42 <Arnavion> I guess bump everything that depends on libphonenumber-dev to be sure?
2023-07-03 05:58:36 <psykose> yea
2023-07-03 06:13:25 <Arnavion> Yep, fixed now, thanks
2023-07-03 06:15:30 <psykose> ole classic of putting another libraries types in your abi
2023-07-03 06:21:22 <Arnavion> What I'm curious about is what a library for parsing and validating phone numbers uses protobuf for in the first place
2023-07-03 06:25:22 <psykose> seems to be purely for https://protobuf.dev/reference/cpp/api-docs/google.protobuf.repeated_field/
2023-07-03 06:25:44 <psykose> quite literally a vector replacement
2023-07-03 06:25:56 <Arnavion> Yeah, I saw that, but also the field that is of that type is itself part of a type generated from the .proto, so it's more than just that type
2023-07-03 06:26:38 <Arnavion> Specifically that current_metadata is a PhoneMetadata from phonemetadata.proto
2023-07-03 06:28:13 <psykose> interesting
2023-07-03 06:29:08 <Arnavion> Following it back, looks like there's some compiled-in data, and they just chose to use the protobuf format for it
2023-07-03 06:29:46 <Arnavion> https://github.com/google/libphonenumber/blob/master/cpp/src/phonenumbers/short_metadata.cc#L23   +   https://github.com/google/libphonenumber/blob/master/cpp/src/phonenumbers/shortnumberinfo.cc#L38C45-L38C45
2023-07-03 06:30:09 <psykose> double cute
2023-07-03 07:21:01 <nmeum> does libprotobuf really need to depend on all of those abseil-cpp-* packages?
2023-07-03 07:21:47 <psykose> yes
2023-07-03 09:14:07 <qaqland[m]> Some software seems to be inconvenient to write openrc. They have many functions, some of which need to be self-starting, and others do not.
2023-07-03 19:34:49 <quinq> e
2023-07-03 20:09:13 <gue5t1a> hi
2023-07-03 20:09:54 <gue5t1a> Is there an initd sample file, which I can use?
2023-07-03 20:12:51 <gue5t1a> just saw that "-c Copy a sample init.d, conf.d, and install script to new directory"
2023-07-04 05:18:57 <ikke> ostinator is just building single-threaded
2023-07-04 05:19:00 <ikke> ostinato
2023-07-04 10:45:12 <ncopa> chromium is broken for me. some text/images disapears
2023-07-04 10:47:35 <ikke> Seems to work fine for me
2023-07-04 10:47:41 <ikke> just upgraded on edge
2023-07-04 10:48:48 <ncopa> i upgraded earlier today, and I tried to rebuild it locally.
2023-07-04 10:50:19 <ncopa> just did another reboot. same issue
2023-07-04 10:50:30 <ncopa> maybe its mesa or gpu driver or something
2023-07-04 10:53:37 <ncopa> $ tpaste < /var/log/Xorg.0.log
2023-07-04 10:53:37 <ncopa> https://tpaste.us/ePKp
2023-07-04 10:53:42 <ncopa> not sure whats going on
2023-07-04 10:54:55 <ncopa> maybe its the libjpeg-turbo upgrade?
2023-07-04 10:56:37 <ncopa> nope
2023-07-04 10:58:22 <ikke> Just rebooted, still seems to work fine for me
2023-07-04 11:01:37 <ncopa> i tried downgrade libjpeg-turbo<3 and remove testing repo
2023-07-04 11:01:43 <ncopa> still same issue
2023-07-04 11:02:48 <ncopa> how can I run chromium in debug mode?
2023-07-04 11:03:50 <ikke> --debug-print?
2023-07-04 11:03:53 <ikke> not sure
2023-07-04 11:04:16 <ikke> --enable-gpu-debugging
2023-07-04 11:09:41 <ncopa> Errors:
2023-07-04 11:09:41 <ncopa> link failed but did not provide an info log
2023-07-04 11:14:42 <ncopa> huh... renaming ~/.config/chromium solved it
2023-07-04 11:14:48 <ncopa> annoying
2023-07-04 11:15:43 <ikke> hmm, indeed
2023-07-04 11:17:09 <ncopa> it means i lost all my saved passwords, history and what not
2023-07-04 11:17:40 <ikke> yes, you'd start with a clean profile
2023-07-04 11:22:50 <ikke> ncopa: did you try restoring your profile and clearing cache?
2023-07-04 11:22:59 <ncopa> ok, i think I might have solved it. I deleted some directories, like GrShaderCache/, Default/Extensions, Default/GPUCache, Default/Service\ Worker
2023-07-04 11:23:15 <ncopa> seems to be ok now
2023-07-04 11:28:30 <ncopa> deleting ~/.configs/chromium/Default/GPUCache was all needed to solve it
2023-07-04 11:29:23 <ikke> something something cache invalidation
2023-07-04 11:30:57 <ncopa> yeah :)
2023-07-04 11:32:08 <ncopa> there are two hard things in comuting: naming things, cache invalidation and off-by-one errors :)
2023-07-04 11:32:23 <ikke> exactly what I have in mind :)
2023-07-04 13:31:45 <psykose> ikke: yeah it's broken when built with >1 thread because of a race condition
2023-07-04 13:33:18 <ikke> Fun
2023-07-04 13:33:40 <ikke> It at least finished building on rv64
2023-07-04 17:03:33 <quinq> Hi, where can I see the build logs of alpine packages?
2023-07-04 17:04:01 <quinq> I've searched the website but couldn't find any info about that (I suppose I missed it though)
2023-07-04 17:06:22 <minimal> quinq: on pkgs.alpinelinux.org search for the package you want, click on it and on the next page click on "Build log" link ;-)
2023-07-04 17:06:55 <minimal> if it hasn't been built in some time then the build log may not be available
2023-07-04 17:07:07 <quinq> Thanks minimal :)
2023-07-04 17:07:20 <quinq> Well, I admit that was kind of an XY question.
2023-07-04 17:07:47 <quinq> I'm really looking for the builders configurations, I'd like to find out how is compiled software for some targets
2023-07-04 17:13:27 <psykose> what specifically
2023-07-04 17:15:12 <quinq> Whith what toolchain for example, the default build flags, etc.
2023-07-04 17:15:46 <quinq> I suppose by now that Alpine doesn't do any cross-compilation?
2023-07-04 17:16:11 <quinq> s/?/or does it&/
2023-07-04 17:16:19 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/default.conf 
2023-07-04 17:16:19 <psykose> https://git.alpinelinux.org/aports/tree/main/abuild/APKBUILD#n56
2023-07-04 17:17:15 <psykose> no cross compiling no
2023-07-04 17:17:41 <quinq> Thank you very much psykose :)
2023-07-04 17:18:25 <psykose> /usr/bin/cc is gcc and /usr/bin/ld is gnu binutils
2023-07-04 17:18:33 <psykose> anything past that would be in the apkbuild of the specific thing
2023-07-04 17:19:26 <quinq> ok, aports/main/gcc/APKBUILD is interesting too
2023-07-04 17:19:39 <quinq> Yeah, perfect :)
2023-07-04 17:29:27 <quinq> https://wiki.alpinelinux.org/wiki/Requirements I can see that ppc64le is duplicated
2023-07-04 17:29:36 <quinq> Is that really expected or is the second one actually ppc64?
2023-07-05 05:05:08 <ikke> quinq: we don't have a big-endian build for ppc
2023-07-05 06:36:23 <quinq> Hi ikke, allright
2023-07-05 06:36:32 <quinq> That table entry still looks strange, doesn't it?
2023-07-05 06:36:56 <ikke> Yes
2023-07-05 12:05:09 <ovf> continuing the topic of build systems that like to fetch the dependencies, is there any conceptual appetite for scaffolding that would read cargo.toml/meson wrap/etc. and fetch stuff in prepare() or so?
2023-07-05 12:05:32 <psykose> nah
2023-07-05 12:06:25 <ovf> i find doing this by hand quite exacting. and then every version bump i need to check whether any versions of the deps have changed
2023-07-05 12:07:06 <ovf> (or do what's currently done for cargo -- allowing it free reign which can't be good for reproducibility)
2023-07-05 12:07:43 <ovf> alternatively this thing could behave closer to `abuild checksum` in that it alters the APKBUILD 
2023-07-05 12:14:14 <psykose> it's perfectly fine for some notion of `reproducibility' that we don't even check regardless
2023-07-05 12:15:05 <psykose> doing more than that would be akin to either what gentoo or fedora does which has the strongest 'what the fuck' you'll ever see
2023-07-05 12:20:44 <ikke> Aren't we already doing that for rust
2023-07-05 12:20:54 <ikke> Fetching crates in prepare 
2023-07-05 12:24:34 <psykose> yes, the suggestion is a) to do that without cargo (so like gentoo etc) with a hardcoded list of urls b) also for other stuff that fetches deps
2023-07-05 12:25:32 <psykose> a) doesn't make sense and b) is.. uhh.. it's near impossible to generally know 'what deps' naively and even when that is useful it's going to be like two things most of the time
2023-07-05 12:26:16 <psykose> for something like git submodules it's not even possible to know without an actual git clone
2023-07-05 12:27:19 <psykose> for 'meson .wrap' you don't know which ones are actually used or fallback to system
2023-07-05 12:27:23 <psykose> etc
2023-07-05 12:27:31 <psykose> first you have to write an operating system for this tool
2023-07-05 12:27:48 <psykose> and it definitely has no use in aports
2023-07-05 12:30:14 <skarnet> very normal build system that doesn't let you know what the fuck exactly you're building
2023-07-05 12:30:30 <psykose> which one
2023-07-05 12:30:37 <skarnet> you may not like it but it's what peak engineering looks like
2023-07-05 12:31:00 <skarnet> well, the language-specific build systems and dependency systems such as cargo, obviously
2023-07-05 12:31:11 <psykose> those let you know that fine
2023-07-05 12:31:45 <skarnet> what was that about "you don't know which ones are actually used or fallback to system"?
2023-07-05 12:32:18 <psykose> you "dont know" from the perspective of some tool that tries to guess and prefetch what the build system does
2023-07-05 12:32:39 <skarnet> yeah
2023-07-05 12:32:50 <psykose> it's a problem as if i fed it some random s6 code and told a python script to guess if the code makes a network request or not
2023-07-05 12:32:52 <psykose> it does not make sense
2023-07-05 12:32:52 <skarnet> so the build system is the one who decides, not you
2023-07-05 12:32:56 <psykose> no, you do
2023-07-05 12:32:58 <psykose> meson lets you control this
2023-07-05 12:33:12 <psykose> please actually go look at something for more than three seconds instead of talking out of your ass
2023-07-05 12:33:32 <skarnet> I'm inferring things from what you're saying
2023-07-05 12:33:48 <psykose> that's nice but obviously this does not have 20 essays of context
2023-07-05 12:34:01 <psykose> you have to actually know what the tools do first
2023-07-05 12:34:19 <skarnet> well I'm glad it can be made to work
2023-07-05 12:34:53 <skarnet> it's just... given the amount of ink that's being spilled on this, I feel like you need a PhD to actually make it work
2023-07-05 12:35:22 <humm> Surely you can tell cargo to just fetch dependencies, no?
2023-07-05 12:35:56 <psykose> who knew build systems had more complexity than someones handwritten ./configure that needs three phds to understand
2023-07-05 12:36:37 <skarnet> you're being unfair and you know it
2023-07-05 12:37:18 <psykose> maybe it's time to retire
2023-07-05 12:37:24 <skarnet> my point is that it should be *very clear* *at all times* when you're getting stuff from the network, if you're ever going to do this
2023-07-05 12:37:39 <skarnet> and it should be very clear at all time what version of what dep you're using
2023-07-05 12:37:44 <psykose> with meson it is
2023-07-05 12:37:52 <psykose> with cargo too funnily
2023-07-05 12:37:55 <skarnet> and the way to specify it should be the easiest and clearest thing of all time
2023-07-05 12:38:12 <psykose> believe it or not, that is already true
2023-07-05 12:38:42 <skarnet> maybe it is, or maybe it is to you because you're used to these things, but why are so many people asking questions about this all the time everywhere
2023-07-05 12:38:55 <psykose> because in this case the discussion is not about what you're thinking presently
2023-07-05 12:39:15 <psykose> there's a lot more intertwined context relating very specifically to "building things in aports" and "fetching in prepare" and how that interacts with this stuff
2023-07-05 12:39:29 <skarnet> okay, let me amend
2023-07-05 12:39:40 <psykose> the tools aren't making it difficult nor are they the issue most of the time
2023-07-05 12:40:01 <skarnet> a 2023 build system should *also* make it super easy to interact with package managers
2023-07-05 12:40:21 <psykose> this doesn't have anything to do with package managers really
2023-07-05 12:40:33 <skarnet> or distro builders or whatever you wanna call it
2023-07-05 12:40:55 <psykose> the problem doesn't arise from there and you have it somewhat backwards in your head
2023-07-05 12:41:14 <skarnet> okay, if you say so
2023-07-05 12:42:04 <psykose> naive example: some project uses a git submodule of a random thing for itself
2023-07-05 12:42:13 <psykose> said project does not have thing in tarball
2023-07-05 12:42:27 <psykose> said thing is also 'random thing that is three headers' and not really a system dependency of any sort
2023-07-05 12:42:32 <skarnet> the first mistake was using a submodule
2023-07-05 12:42:36 <psykose> sure, sure
2023-07-05 12:42:43 <psykose> i can also close my ears and pretend this doesn't exist
2023-07-05 12:42:50 <psykose> sadly though i am not you and i actually have to build software
2023-07-05 12:43:18 <skarnet> you think I'm making fun of you
2023-07-05 12:43:19 <skarnet> I am not
2023-07-05 12:43:27 <psykose> no, but i'm saying this is a meaningless statement
2023-07-05 12:43:31 <skarnet> I am raging at upstreams that make *your* life *more difficult*
2023-07-05 12:43:32 <psykose> this is a thing that exists and you cannot change it
2023-07-05 12:43:49 <psykose> so now you think of how you deal with it
2023-07-05 12:44:13 <psykose> how it's done in aports: you normally just add a source= thing of the submodule at some git revision, it's just fetched with the regular tarball
2023-07-05 12:44:19 <psykose> do some `mv` in prepare and done
2023-07-05 12:44:19 <psykose> it works fine
2023-07-05 12:44:26 <psykose> that takes me 3 nanoseconds to do
2023-07-05 12:44:50 <psykose> evidently though, some people are annoyed with this, and wanted to make a tool that "does magic and manages this stuff automatically somehow", cue above discussion, ...
2023-07-05 12:45:06 <psykose> (for this specific example, you cannot even get this submodule info without a full clone, ..)
2023-07-05 12:45:07 <psykose> etc
2023-07-05 12:45:32 <psykose> then there's more types of the same thing that aren't git submodules but other variations of the same thing
2023-07-05 12:45:58 <psykose> and there's pretty much no case where any extra yet another additional tool is going to be very helpful
2023-07-05 12:46:17 <psykose> does that make somewhat more sense
2023-07-05 12:46:56 <skarnet> it does and I agree with you, you know my opinion about magic
2023-07-05 12:47:01 <ikke> In case of github, you can use the api
2023-07-05 12:47:32 <psykose> if i actually implemented such a thing i would probably prefer a clone + submodule-check-thing over a github api thing haha
2023-07-05 12:47:44 <psykose> but it's not useful for an actual build because that is slow as hell
2023-07-05 12:47:49 <psykose> would be a staging tool to fill out info
2023-07-05 12:48:15 <psykose> and it is but one of 50 types of this you have to handle or not
2023-07-05 12:48:29 <Hello71> I reckon skarnet accepts the existence of an automatic download option but wants the default to be manual download. I don't think that's very useful; it's obviously worse for people who want the automatic download, and it doesn't help that much for people who don't want the automatic download because you can convert automatic download to manual download with unshare -cn
2023-07-05 12:49:01 <Hello71> the hard work is going through all the types of download that the thing wants, not turning off the automatic download
2023-07-05 12:49:31 <skarnet> Hello71: I just want upstreams to make it easy for builders to do the correct thing
2023-07-05 12:50:02 <psykose> personal failed online rants counter: 1
2023-07-05 12:50:08 <psykose> burnt pizzas due to online rant counter: 1
2023-07-05 12:50:20 <skarnet> these are rookie numbers
2023-07-05 12:50:30 <psykose> it's probably at like 5 tbh
2023-07-05 12:50:33 <psykose> which is 5 too many
2023-07-05 12:51:07 <skarnet> if you can't deal with me in online rant mode, you don't deserve me at my best
2023-07-05 12:52:16 <skarnet> you want something constructive from this? team up with other distros and lobby for better tools from upstream
2023-07-05 12:52:19 <ikke> I think from a builders perspective, the most important part is builds being reproducible. Allowing fetching dependencies from the net or not is a proxy for that
2023-07-05 12:52:30 <skarnet> ikke: agreed
2023-07-05 12:54:53 <psykose> skarnet: i'm referring to my own rants
2023-07-05 12:54:54 <psykose> :p
2023-07-05 12:55:31 <psykose> i don't care much about reproducible builds personally
2023-07-05 12:55:38 <psykose> insofar to what the technical term means, being bit-exact
2023-07-05 12:55:42 <psykose> most of the practices are very good
2023-07-05 12:55:54 <psykose> following them you stop shit like 'thing clones git master of something in build every time'
2023-07-05 12:56:10 <psykose> the tail end of building everything n+1 times to ensure they reproduce and getting bit-perfectness is mostly a waste of time though
2023-07-05 12:56:47 <psykose> but following all the good practices you get that anyway almost every time, so..
2023-07-05 12:58:56 <skarnet> it depends on the level of guarantee you want to provide and some people (mostly corporations...) want bit-perfectness, but yeah, my preference is "reproducibility with exact version numbers of the software with all its dependencies, I don't care about stuff like build date"
2023-07-05 13:01:28 <psykose> i mean it really does follow on to more stuff with all of it
2023-07-05 13:01:50 <psykose> like nullifying some date stuff and making sure the /path is always the same (or -fprefix'd off) makes ccache/caches work better too, etc
2023-07-05 13:02:03 <psykose> it's why the practices are just good to follow even though me and you don't care at all
2023-07-05 14:09:50 <sam_> psykose: that's pretty much my position on it as well
2023-07-05 14:10:05 <sam_> we sort of benefit naturally from debian and such working on it but i don't really care about it in particular
2023-07-05 14:11:57 <psykose> ye
2023-07-05 14:12:13 <elibrokeit> ovf, psykose: usually for meson wraps you know that none of them are used in distro packages ;) because you can always just build those as apk packages and then build-depend on them. The entire concept of wraps was originally created to make vendor-happy Windows users satisfied that their stuff builds without vcpkg or whatever, while not stepping on the toes of distros -- that's
2023-07-05 14:12:15 <elibrokeit> why --wrap-mode=nofallback is a thing.
2023-07-05 14:14:49 <ovf> sure, but i don't necessarily want to spam alpine with like half a dozen random packages that are only dependents of a single one i care about
2023-07-05 14:15:08 <psykose> what are you even packaging
2023-07-05 14:15:42 <elibrokeit> I really, really, really think you should "spam" alpine with properly factored packages that build their dependencies in the natural way the dependency is meant to be built
2023-07-05 14:15:43 <sam_> tensorflow
2023-07-05 14:16:08 <elibrokeit> but also tensorflow is intentionally designed to be difficult to package, plus it does not use meson :D
2023-07-05 14:16:34 <elibrokeit> it's one of those worst-case scenarios where devendoring dependencies involves extensive patching of source code
2023-07-05 14:17:03 <orbea> they have custom versions of vendored deps?
2023-07-05 14:17:10 <elibrokeit> they use bazel, so
2023-07-05 14:17:35 <elibrokeit> everything that is a dependecy is part of the bazel sandbox, and bazel mandates that it does tarball extraction with checksums
2023-07-05 14:17:54 <orbea> oh...i'll be glad I dont have to deal with this :)
2023-07-05 14:18:04 <elibrokeit> so you want to devendor anything, you have to patch things like 5 levels deep
2023-07-05 14:18:14 <elibrokeit> it is typical googleware
2023-07-05 14:18:35 <ovf> psykose: re meson, that was pidgin3. re cargo, martypc, but there's nothing unusual about it (just the fact that i'd expect rootbld to work by default)
2023-07-05 14:19:02 <elibrokeit> also the number of distros interested in fighting with tensorflow is... low :D
2023-07-05 14:19:10 <psykose> ah you're just building it for yourself or
2023-07-05 14:22:05 <elibrokeit> skarnet: "team up with other distros and lobby for better tools from upstream" -- this is literally just "lobby for people to use meson", though
2023-07-05 14:22:18 <psykose> self sellout
2023-07-05 14:22:41 <skarnet> if meson's the least bad option out there then why not
2023-07-05 14:25:02 <valerius> "better"
2023-07-05 14:25:19 <elibrokeit> well yeah, it's the only build system which is designed and maintained by a team which includes people passionate about building linux distributions
2023-07-05 14:25:29 <elibrokeit> <--
2023-07-05 14:25:45 <ovf> pidgin3, for myself for now. i think i've come across other meson wrap stuff before
2023-07-05 14:25:50 <valerius> yeah, I am just commenting on how the term "better" is what has been in debate the entire time here
2023-07-05 14:25:55 <psykose> someone is going to bring up autotools as a counterpoint in 2 seconds
2023-07-05 14:25:57 <valerius> whether that has been realized or not
2023-07-05 14:26:14 <elibrokeit> autotools was not designed, so there's your first problem
2023-07-05 14:26:22 <psykose> ovf: generally if you just don't pass the abuild-meson --wrap-mode thing the default falls back fine
2023-07-05 14:26:31 <psykose> you can read the docs for what they do, mostly just works
2023-07-05 14:26:36 <skarnet> psykose: autotools is not useful if your target is Linux
2023-07-05 14:27:04 <psykose> but i just really need to know the size of char
2023-07-05 14:27:05 <psykose> please ma
2023-07-05 14:27:06 <psykose> man
2023-07-05 14:27:08 <psykose> just tell me
2023-07-05 14:27:13 <psykose> WHAT IS SIZEOF CHAR
2023-07-05 14:27:51 <skarnet> of course there are still some sysdeps that need testing even if you restrict yourself to Linux but I'd hope that most build systems maintain a list of actual useful sysdeps to test
2023-07-05 14:28:17 <elibrokeit> if you just need to compile a couple of files on one OS into a single target with no configuration, then raw Makefiles work fine
2023-07-05 14:28:26 <elibrokeit> the problem is this is rarely ever the case...
2023-07-05 14:29:10 <elibrokeit> autotools "check 500 things and set a macro for each of them, but you probably don't actually #ifdef off of that macro in your code anyway"...
2023-07-05 14:29:25 <elibrokeit> not really helping either :D
2023-07-05 14:29:28 <orbea> i think the least terrible choices for a complex build system is autotools or meson, both do well what the other does badly...
2023-07-05 14:31:19 <ovf> psykose: thanks. i suppose i just wanted a nice net-less rootbld for that
2023-07-05 14:31:58 <psykose> ovf: yeah rootbld doesn't support any net entirely without =net since the 'net in prepare' was never added yet
2023-07-05 14:32:02 <psykose> so unfortunate there :-)
2023-07-05 14:32:11 <psykose> idk why people rate autotools so highly
2023-07-05 14:32:16 <psykose> i would put cmake above autotools
2023-07-05 14:32:40 <orbea> yea, cmake belongs on that list, which is better is a matter of preference
2023-07-05 14:32:57 <psykose> mostly because i value my time and -G Ninja is 2x faster over any garbage autotools puts out
2023-07-05 14:33:20 <orbea> yep,  that is the biggest thing wrong with autotools, lots of slow and inefficient legacy bloat
2023-07-05 14:33:34 <psykose> well it's not the configure step where most of the time is..
2023-07-05 14:33:39 <valerius> I'm glad nobody's pitching scons
2023-07-05 14:33:40 <psykose> just the `make` sux because make is just not fast
2023-07-05 14:33:51 <psykose> ah well
2023-07-05 14:34:00 <psykose> at the end of the day i use every single one anyway
2023-07-05 14:34:06 <psykose> so it's mostly just moanin n bitchin
2023-07-05 14:34:07 <psykose> :D
2023-07-05 14:34:55 <skarnet> at the end of the day I don't use any of these because none of them detects whether posix_spawn() returns early or not so I need to do my own tests
2023-07-05 14:35:11 <psykose> you can write the test in them fine
2023-07-05 14:35:41 <skarnet> yeah, I probably even could figure out how to write it in autoconf
2023-07-05 14:35:46 <psykose> it ends up being the same actually, just with 'build system test source file compile syntax' instead of 'my own test source file compile syntax'
2023-07-05 14:36:13 <skarnet> but the point is to have a predetermined set of tests
2023-07-05 14:36:34 <skarnet> because nobody wants to redo a whole suite of tests for the OS
2023-07-05 14:41:16 <elibrokeit> psykose: I hate both cmake and autotools, but I hate cmake a lot more than I hate autotools
2023-07-05 14:42:04 <elibrokeit> -GNinja doesn't help if you spend most of your time sink, debugging CMakeLists.txt rather than watching text scroll by 
2023-07-05 14:42:46 <orbea> that is also what I dont like about cmake, lot of ways to shoot yourself in the foot
2023-07-05 14:43:19 <orbea> and you tend to find the same or similar bad practices everywhere
2023-07-05 14:44:05 <psykose> i've debugged way more autotools
2023-07-05 14:44:20 <quinq> Because it's way more older
2023-07-05 14:44:49 <psykose> i am keeping the real hot takes down low tho
2023-07-05 14:44:51 <psykose> just to spare ya
2023-07-05 14:45:03 <orbea> there are certainly ways to write autotools badly too...
2023-07-05 14:45:11 <elibrokeit> cmake: galaxy brain build system, has the advantage of initially coming out a decade later than autoconf, at a point in time where people had already learned datatypes are important, but somehow fails to have even FEWER real datatypes than autoconf, which has POSIX shell arrays in the form of $@ for functions
2023-07-05 15:08:40 <psykose> elibrokeit: click this to die instantly https://img.ayaya.dev/cbLHEKmUKroO
2023-07-05 15:11:49 <elibrokeit> this thing has several sins
2023-07-05 15:11:57 <elibrokeit> https://github.com/cktan/tomlc99/blob/master/libtoml.pc.sample
2023-07-05 15:11:59 <elibrokeit> 
ACTION dies

2023-07-05 15:14:37 <elibrokeit> this piece of garbage has a Linux-only Makefile that then adds a soname... except only in the filename, not in the ELF headers, so that fails...
2023-07-05 15:15:05 <psykose> :D
2023-07-05 15:15:37 <elibrokeit> overrides CFLAGS to set -fpic, does not use LDFLAGS at all
2023-07-05 15:16:12 <psykose> the patch over it vendors a meson.build
2023-07-05 15:16:25 <psykose> in the uhh.. thing that does that
2023-07-05 15:16:34 <elibrokeit> of course
2023-07-05 15:16:53 <elibrokeit> but why subproject a specific git commit hash
2023-07-05 15:16:59 <elibrokeit> what pointlessness
2023-07-06 16:44:22 <Piraty> Ariadne: your domain dereferenced.org expired ..?
2023-07-06 16:44:32 <ikke> Piraty: the registrar is trash
2023-07-06 16:45:33 <Ariadne> the registrar is making it difficult for me to give them money because they allowed another domain to be stolen which is the admin contact :)))
2023-07-06 16:45:42 <ikke> https://social.treehouse.systems/@ariadne/110643909699308207
2023-07-06 16:45:53 <Ariadne> distfiles.ariadne.space is operational
2023-07-06 16:45:57 <Piraty> i guess a few build systems assume distfiles.deref is up ;)
2023-07-06 16:46:22 <Ariadne> yes, i have communicated that to them, as well as had a lawyer communicate that to them
2023-07-06 16:48:22 <Piraty> good luck
2023-07-06 16:52:14 <Piraty> and thanks for working on pkgconf, in case nobody thanked for it today already
2023-07-08 18:09:46 <z3ntu> psykose: having quite some problems with compiling a package (not in aports) that uses protobuf..
2023-07-08 18:10:14 <z3ntu> first some compile error which I resolved with bumping c++ standard of this package from c++14 to c++17
2023-07-08 18:10:18 <z3ntu> 
ACTION sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/JVqGAseKOzItlJVUFiUJTETm

2023-07-08 18:10:50 <z3ntu> and now there's a million linker errors, something with protobuf+abseil-cpp
2023-07-08 18:10:52 <z3ntu> 
ACTION sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/QThIrDDlAfkxdsookmMopfuU

2023-07-08 18:11:43 <psykose> needs c++17 yea
2023-07-08 18:11:47 <psykose> the second you can work around with uhh
2023-07-08 18:11:58 <psykose> try LDFLAGS="$LDFLAGS -Wl,--copy-dt-needed-entries"
2023-07-08 18:12:23 <psykose> the dso ordering stuff is fucked somewhere in the protobuf<->abseil place so via cmake it's usually just wrong
2023-07-08 18:45:43 <z3ntu> psykose: I think that worked.. Still a different compile error with this software but this looks to be completely unrelated, maybe with the c++17 bump
2023-07-08 18:45:52 <psykose> show
2023-07-08 18:46:23 <z3ntu> 
ACTION sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/iWsDTLwOxMDFyuONbQJEDTTv

2023-07-08 18:47:26 <ikke> URxvt.font: -xos4-terminus-medium-r-normal--16-160-72-72-c-80-iso10646-1
2023-07-08 18:48:50 <psykose> yeah that's a standard c++17 error thing
2023-07-08 18:49:32 <psykose> they also entirely dropped that file + it probably works in 2.3
2023-07-08 18:49:39 <psykose> 2.13*
2023-07-09 06:16:09 <raspbeguy> Hello, I would like to drop maintainership of community/clipboard. There used to be a "unmaintained" repo, now it's gone. Do I just remove the folder now ?
2023-07-09 06:16:36 <psykose> generally you keep the package but remove yourself as a maintainer
2023-07-09 06:16:45 <psykose> but if you want to just remove the package that's also ok
2023-07-09 06:16:48 <psykose> so yea
2023-07-09 06:19:52 <raspbeguy> I don't want it gone per se. But I wanted to signify that I was leaving this package, that it won't get updated unless someone else takes care of it.
2023-07-09 06:20:18 <psykose> 1st option then
2023-07-09 06:20:46 <raspbeguy> Isn't it dangerous in terms of security?
2023-07-09 06:22:55 <psykose> why would it be
2023-07-09 06:23:40 <raspbeguy> Well regular user would still use it even if new vulnerabilities are found and not oatched
2023-07-09 06:23:48 <raspbeguy> Patched*
2023-07-09 06:24:02 <psykose> that applies to any program and a line of text in some file doesn't change anything wrt that
2023-07-09 06:24:39 <raspbeguy> Ok then
2023-07-09 06:33:20 <psykose> never thought i'd want a clipboard management program that output sound at me
2023-07-09 06:34:44 <psykose> > Optimized History action with multithreading! If you have hundreds of thousands of history entries, you'll notice that you're now getting kickASS performance here. This isn't python or webshit we're talking about here.
2023-07-09 06:34:46 <psykose> WEB SCALE
2023-07-09 06:35:32 <raspbeguy> psykose: that's exactly because of that I dropped it
2023-07-09 06:35:45 <psykose> seeing stuff like this makes me feel like a boomer
2023-07-09 06:35:51 <psykose> i just type stuff into my shell and use C-r
2023-07-09 06:36:09 <raspbeguy> Also the dev clearly signifies that he was working on a GUI
2023-07-09 06:36:21 <psykose> there's even some commented out io-uring stuff
2023-07-09 06:36:24 <raspbeguy> This is definition of bloatware
2023-07-09 06:36:24 <psykose> to make it more faster of course
2023-07-09 06:36:44 <abby> io-uring, to make it kernel scale
2023-07-09 06:36:54 <psykose> gui clipboard manager doesn't inherently not make sense (there's multiple), it's just like another ui like it already was
2023-07-09 06:36:59 <psykose> it is a funny project regardless tho
2023-07-09 06:37:37 <psykose> 
ACTION places abby onto the io ring

2023-07-09 06:37:46 <abby> 
ACTION spins

2023-07-09 06:37:47 <abby> https://github.com/Slackadays/Clipboard/blob/main/documentation/readme-assets/ProductivityTools.png
2023-07-09 06:37:49 <psykose> spinny
2023-07-09 06:37:55 <psykose> lmao
2023-07-09 06:38:03 <psykose> https://github.com/Slackadays/Clipboard/blob/main/documentation/readme-assets/ProductivityTools.svg
2023-07-09 06:38:07 <psykose> https://img.ayaya.dev/jYx98bOCyfiv
2023-07-09 07:22:37 <psykose> raspbeguy: also when the unmaintained thing existed it wasn't built, i.e. it would be the same as just rm -rf'ing it
2023-07-09 07:23:09 <psykose> so since that wasn't your intention it was indeed just confusing
2023-07-09 09:25:38 <raspbeguy> psykose: I think that it would have been better for it not to be built anymore, but the APKBUILD itself still be around for someone to find it and maybe take care of it 
2023-07-09 09:26:53 <ikke> problem is that the APKBUILDs will rot
2023-07-09 13:10:31 <humm> and the old one will stay in the repo anyway
2023-07-10 20:06:39 <omni> 
ACTION wants a fourth brain

2023-07-10 20:21:51 <bl4ckb0ne> what are you doing with the first three
2023-07-10 20:31:35 <ikke> keep the 4th one in check
2023-07-11 02:03:09 <ayoub120> Anyone working on kernel drivers ?
2023-07-11 11:11:37 <QDX45> I have a patch for the init script on the alpine-netboot initramfs...what's the best way to submit that?
2023-07-11 11:29:52 <ikke> QDX45: I think that's just the default init script
2023-07-11 11:30:19 <ikke> QDX45: so that would be here: https://gitlab.alpinelinux.org/alpine/mkinitfs
2023-07-11 13:01:47 <omni> bl4ckb0ne: one keeps my essential bodily functions running so the other two don't have to bother and those two are usually busy arguing with eachother anyway
2023-07-11 13:02:25 <bl4ckb0ne> i can only offer you a forth brain
2023-07-11 14:27:31 <omni> that's not a bad offer to put forth
2023-07-11 19:32:43 <ikke> psykose: someone wants you to upgrade thunderbird :D
2023-07-11 19:32:52 <psykose> what about it
2023-07-11 19:33:05 <psykose> you mean the classic of '5 minutes after release please update'
2023-07-11 19:33:06 <psykose> :D
2023-07-11 19:33:43 <ikke> probably
2023-07-11 19:35:05 <ikke> https://fosstodon.org/@rnd@toot.cat
2023-07-11 19:35:25 <psykose> ah
2023-07-11 19:44:33 <ikke> Hmm, shotcut was flagged by anitya, but it was a beta
2023-07-11 19:46:20 <psykose> it's just a regular number and no way for any auto rule to guess that
2023-07-11 19:46:51 <psykose> so in anitya itself it's not a beta
2023-07-11 19:46:59 <ikke> yea, figured
2023-07-11 19:48:03 <ikke> Same with repology, you'd have to explicitly mark it as a dev version
2023-07-11 19:48:29 <psykose> yep
2023-07-12 18:33:42 <fluix> when does one use /var/<name> vs. /var/lib/<name>?
2023-07-12 18:33:59 <psykose> pretty much never
2023-07-12 18:34:27 <fluix> so https://git.alpinelinux.org/aports/tree/testing/ergo/APKBUILD is probably wrong?
2023-07-12 18:34:43 <fluix> (am cloning a local copy for stuffs, but am happy to make an MR too)
2023-07-12 18:34:51 <psykose> yeah
2023-07-12 19:35:12 <fluix> is https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#pid-files-should-be-writable-only-by-root true? redis seems to follow this by having /run/redis/redis.sock owned by redis:redis but /run/redis.pid outside the directory owned by root:root. nginx (and others like murmur) don't follow this
2023-07-12 19:42:30 <psykose> it is true yeah
2023-07-12 19:44:48 <fluix> oki, thanks :)
2023-07-12 19:45:32 <psykose> some stuff is quite impossible to actually make compliant to that
2023-07-12 19:45:44 <psykose> there's also no real standard and there's a bunch of unrelated issues
2023-07-12 19:45:51 <psykose> core issue is of course 'openrc bad'
2023-07-12 19:47:58 <fluix> gotcha. any summary of its issues somewhere?
2023-07-12 19:49:12 <psykose> don't think so
2023-07-12 19:49:16 <psykose> well
2023-07-12 19:49:20 <psykose> core issue 1 is 'openrc bad'
2023-07-12 19:49:35 <psykose> core issue 2 is 'nobody can decide on what should anything really be'
2023-07-12 19:50:04 <abby> thanks algit
2023-07-12 19:51:56 <fluix> another question: say I'm making a package that just adds some nginx configs. do I have to create the directories /etc/nginx/...? I assume so because I get errors otherwise. and should I depends="nginx nginx-mod-stream" if I rely on the stream module config?
2023-07-12 19:52:11 <psykose> probably
2023-07-12 19:52:34 <psykose> create in the package you mean? to put a file in pkgdir/etc/nginx/xyz you need to make it as otherwise you can't put it there
2023-07-12 19:52:56 <fluix> yes, makes sense
2023-07-12 19:53:30 <fluix> do I need to worry about it's permissions at all and use install -m... or can I just mkdir?
2023-07-12 19:54:32 <psykose> depends what you're installing
2023-07-12 19:54:43 <psykose> most configs are just install -Dm644 config ....
2023-07-12 19:55:09 <fluix> for installing the configs yes, but what about the directories like /etc/nginx/http.d/ which the nginx package creates
2023-07-12 19:55:36 <psykose> i don't know what actually happens if they are different :D
2023-07-12 19:55:40 <psykose> but it's already 755
2023-07-12 19:55:58 <psykose> and the default for any mkdir or what install -D creates for prerequisite is 755 too
2023-07-12 19:56:17 <fluix> haha alright, thanks again
2023-07-12 19:56:39 <psykose> +- umask but that's not set anywhere
2023-07-12 21:25:55 <nmeum> psykose: is there any "easy" way to patch a rust create on which a rust package depends? do you know if we do that for any packages?
2023-07-12 21:26:42 <nmeum> i.e. adding an extra custom patch for the crate via $source, not updating the crate version
2023-07-12 21:27:00 <psykose> there is no way to do it without forking it to some repo somewhere
2023-07-12 21:27:04 <psykose> and then doing
2023-07-12 21:27:05 <psykose> [patch.crates-io]
2023-07-12 21:27:18 <psykose> crate = libc = { git = 'https://somerepo' }
2023-07-12 21:27:22 <psykose> er
2023-07-12 21:27:24 <psykose> just crate = {
2023-07-12 21:27:56 <nmeum> meh :(
2023-07-12 21:34:13 <abby> hm i thought there was a way to do it with cargo vendor or smth
2023-07-12 21:36:49 <psykose> that's even more effort
2023-07-12 21:37:28 <psykose> nmeum: what's the context tho
2023-07-12 21:40:16 <nmeum> currently upgrading testing/nickel and noticed that it doesn't build on s390x-musl and started working on patches to fix that for fun
2023-07-12 21:52:10 <psykose> it's probably the nix crate being broken
2023-07-12 21:52:21 <psykose> which would be https://github.com/nix-rust/nix/pull/1835
2023-07-12 21:59:15 <nmeum> yes and the libc crate needs some love too
2023-07-12 22:03:34 <psykose> are you sure you .147?
2023-07-12 22:03:36 <psykose> you have*
2023-07-12 22:03:51 <psykose> i already fixed that multiple times
2023-07-12 22:04:12 <psykose> unless something uses something esoteric .147 already works on s390x
2023-07-12 23:00:54 <fluix> what's the policy for moving packages to community? they've got to be stable enough, and then do you ask the original maintainer to do it or take over maintainership or?
2023-07-12 23:10:04 <ptrc> fluix: mostly just stability of upstream and the alpine package maintainer committing to backporting security fixes for the stable release
2023-07-12 23:15:32 <fluix> and what's good practice w.r.t. maintainership. is it polite to ask the existing maintainer if they're willing to do it or does whoever makes the MR take it over?
2023-07-12 23:17:26 <psykose> 'yes'
2023-07-13 01:51:35 <psykose> ikke: you should report https://git.alpinelinux.org/aports/commit/?id=15bc15c0ac231d53c42b3fe1c98ad5de7b02d100 to wherever it's meant to be reported
2023-07-13 02:56:26 <ikke> psykose: is that something new
2023-07-13 02:56:31 <psykose> nah
2023-07-13 02:56:33 <psykose> broken forever
2023-07-13 02:56:51 <ikke> ok
2023-07-14 08:36:46 <ncopa> hum. docker broke for me
2023-07-14 08:37:06 <ncopa> [+] Building 0.0s (0/0)                                                    docker-container:default
2023-07-14 08:37:06 <ncopa>  docker build .
2023-07-14 08:37:06 <ncopa> WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
2023-07-14 08:37:06 <ncopa> ERROR: http: invalid Host header
2023-07-14 08:38:45 <ncopa> seems like docker downloads and runs moby/buildkit
2023-07-14 08:38:48 <ncopa> $ docker ps
2023-07-14 08:38:48 <ncopa> CONTAINER ID   IMAGE                           COMMAND       CREATED         STATUS         PORTS     NAMES
2023-07-14 08:38:48 <ncopa> 27664ec9269f   moby/buildkit:buildx-stable-1   "buildkitd"   3 minutes ago   Up 3 minutes             buildx_buildkit_default
2023-07-14 08:39:00 <ncopa> i would have expected that the docker-cli-buildx would be used
2023-07-14 08:48:08 <ikke> haven't noticed this myself on edge
2023-07-14 08:48:36 <ncopa> https://github.com/moby/moby/issues/45935
2023-07-14 08:51:48 <ikke> ah ok
2023-07-14 08:52:42 <ikke> host header sanitization
2023-07-14 09:07:27 <ncopa> please hold pushing go 1.20.5 and 1.19.11 to stable branches
2023-07-14 09:07:59 <ikke> nmeum: ^
2023-07-14 09:08:22 <ncopa> it will break things like docker when they are rebuilt
2023-07-14 09:08:35 <ncopa> i have no idea what will happen with other go apps
2023-07-14 10:40:06 <nmeum> oh that's unexpected
2023-07-14 10:40:23 <nmeum> it also passed tests on all arches
2023-07-14 10:44:23 <ncopa> seems to be no check() func?
2023-07-14 10:45:12 <ncopa> i am trying backport the patch, but... i have to patch both moby and cli, so I'm not sure what to set builddir to for the default_prepare to apply the patches
2023-07-14 10:45:48 <ncopa> the joys of having two different source packages and builds in same APKBUILD
2023-07-14 10:46:25 <ncopa> wonder why they are not in two separate APKBUILDs
2023-07-14 10:47:10 <nmeum> I mean the Go release passed checks, not docker
2023-07-14 10:47:30 <ncopa> go works as expected i guess
2023-07-14 10:48:04 <ncopa> as i understand, what happens was that http header check got more strict for security reasons
2023-07-14 10:48:23 <ncopa> hostname in http header
2023-07-14 10:49:21 <ncopa> in docker they used the path to unix socket as host in header, when running http over unix socket, and `/` is apparently invalid in go 1.20.6
2023-07-14 10:49:30 <ncopa> i wonder what else breaks due to this
2023-07-14 10:49:59 <ikke> I think that was fixed already, but the mail parser broke on mbox messages which were accepted before
2023-07-14 10:50:14 <ncopa> IMHO opinion it was a bit clumsy fix in go stable branch
2023-07-14 10:50:36 <ikke> I suppose they see these as security fixes
2023-07-14 10:50:55 <ncopa> they could have added a separate, less strict fix in stable branch. eg deny \r and \n
2023-07-14 10:51:07 <ncopa> and do the more strict fix for go 1.21
2023-07-14 10:53:10 <ncopa> i think the security problem was that it used to accept things like: `foo\r\nx-foo: haha` which would append `x-foo: haha` header unchecked
2023-07-14 10:54:01 <ncopa> now, by issue at hand is how to fix docker so i can work today
2023-07-14 10:55:13 <ncopa> my options are: split docker-cli to its own APKBUILD, or implement my own `prepare` func
2023-07-14 11:01:24 <ncopa> alright, patching the vendor directory in cli fixes it
2023-07-14 11:02:43 <ncopa> the joys of vendored/duplicated sources
2023-07-14 13:35:06 <dhruvin> I'm getting below error when I run /usr/bin/reset (from ncurses-6.4_p20230617-r0) on 3.18.2
2023-07-14 13:35:10 <dhruvin> Error relocating /usr/bin/reset: _nc_safe_fopen: symbol not found
2023-07-14 13:35:34 <dhruvin> Can someone reproduce it?
2023-07-14 13:37:09 <ikke> 3.18 does not have 202306017
2023-07-14 13:37:12 <ikke> did you install it from edge?
2023-07-14 13:39:17 <dhruvin> Oops. I might be pulling something from edge (which I think is unsupported). I'll fix it.
2023-07-14 13:39:37 <ikke> yes, exactly because of what you run into
2023-07-14 13:40:08 <dhruvin> Yes, I remember now. My bad :)
2023-07-14 13:45:44 <dhruvin> Is there a recommended way to downgrade from edge to stable? I certainly did it wrong.
2023-07-14 13:46:34 <ikke> change the repositories, then run apk upgrade --update --available
2023-07-14 13:48:20 <PureTryOut> psykose: I just found that you removed a package (a while ago) that I maintained. The reasoning in the commit message is clear enough but _please_ notify me of changes you make to stuff _I_ maintain. I keep finding things you did after you've already actually done them. In this case it's about e0a639acc520e03dcff43ceb23a0935bb3216743, but the commit message only seems to be talking about qmake which fair enough you have a point. But I
2023-07-14 13:48:20 <PureTryOut> definitely still see a use in the package for other binaries provided by Qt not used by build scripts, like qdbusviewer.
2023-07-14 13:49:23 <dhruvin> ikke: It's downgrading. Thanks.
2023-07-14 15:06:13 <minimal> A question about Alpine and Grub (now that Grub 2.12rc1 has finally been announced). Whenever the version of the Grub packages change I don't see any trigger to, for example, automatically run grub-mkconfig - there is such a trigger for when the contents of /boot change (i.e. with a kernel upgrade/mkinitfs regenerated initramfs)
2023-07-14 15:07:00 <minimal> more importantly, even if this was done, unless grub-install is run (which only appears to happen during initial Alpine install) then the Grub code run during boot will never be updated
2023-07-14 15:08:26 <minimal> so once Alpine has a Grub 2.12 package and a machine upgrades to it, even if grub-mkconfig is run (whether manually or by a trigger) the machine will still be using Grub 2.06 code to boot (and yet a regenerated grub.cfg could have entries that rely on the newer Grub code)
2023-07-14 15:17:09 <minimal> I don't think many people know to run grub-install for the updated code to take effect (and indeed know the grub-install options that were used during the original installation by the setup scripts)
2023-07-14 15:17:47 <ikke> I wouldn't expect so either
2023-07-14 15:18:55 <minimal> for my own configs I've taken to creating an "reinstall-grub.sh" script that "remembers" and re-uses the same options as the original grub-install
2023-07-14 15:20:05 <minimal> so there's a fundamental issue here for Grub installs that upgrades (no matter how infrequent they are) may have no effect on the actual code used for booting (i.e. think about security updates that are not actually being applied)
2023-07-14 15:40:09 <minimal> any thoughts on this?
2023-07-14 15:41:15 <ikke> I have no idea why the bootloader is not being upgraded at the moment. Is there any reason why that might be?
2023-07-14 15:42:22 <minimal> because grub-install can't be run properly unless you know and use the SAME options as were originally used?
2023-07-14 15:43:02 <ikke> Don't we know what options we provide at installation? Or can we not assume they are the same?
2023-07-14 15:43:16 <minimal> I though of raising a MR for setup-disk to create a grub-upgrade script and a MR for grub to autorun such a script if it exists
2023-07-14 15:43:45 <minimal> ikke: we could assume........but as they say assumption is the mother of all feckups :-)
2023-07-14 15:44:26 <ikke> minimal: maybe a better setup would be setup-disk writing the options somewhere, and the script being provided via a package
2023-07-14 15:44:31 <ikke> that way we can still update the script
2023-07-14 15:45:02 <minimal> but the above MRs wouldn't care for existing installs or for someone who re-ran grub-install after initial installation with different options (for whatever reason)
2023-07-14 15:45:42 <ikke> yes, but not a lot to do about that, is there?
2023-07-14 15:45:58 <ikke> except for notifying users
2023-07-14 15:46:35 <minimal> indeed
2023-07-14 15:47:57 <minimal> ok, I'll look into writing MRs for it.
2023-07-14 16:55:12 <ikke> I'll be upgrading gitlab in 5 minutes
2023-07-14 17:11:30 <ikke> gitlab is back
2023-07-14 18:06:39 <psykose> PureTryOut: already agreed to that last time, that is a change even older than the previous one from the previous discussion
2023-07-14 18:07:14 <psykose> qdbusviewer is the same, `qdbusviewer` is the qt5 one and `qdbusviewer6` is the qt6 one, with both having `qdbusviewer` in /usr/lib/qt[56]/bin
2023-07-15 07:19:50 <hello9> hi
2023-07-15 07:19:54 <hello9> Are you developers for Alpine?
2023-07-15 07:20:00 <ikke> Alpine Linux, yes
2023-07-15 07:20:05 <ikke> not the mail client
2023-07-15 07:20:11 <hello9> ikke: I recognise your name
2023-07-15 07:20:47 <hello9> ikke: I am a newbie. I downloaded Alpine, installed it onto a USB stick, and it got stuck on installation asking me for login information
2023-07-15 07:21:08 <hello9> root is default user and pass
2023-07-15 07:21:09 <hello9> ?
2023-07-15 07:21:20 <ikke> root as username, no password
2023-07-15 07:21:33 <hello9> after that, it gets stalled, I cannot progress into PS
2023-07-15 07:21:34 <hello9> OS
2023-07-15 07:21:43 <hello9> thanks for sharing
2023-07-15 07:22:37 <hello9> Do you know if Alpine has edited feature length films?
2023-07-15 08:15:31 <ikke> Not sure what you mean with that, but Alpine Linux is not doing anything video related itself
2023-07-15 08:55:25 <ikke> lfkfkfk
2023-07-15 08:55:28 <ikke> ops
2023-07-15 08:57:07 <psykose> same bestie
2023-07-15 09:37:38 <lucidiot> alpine linux the movie when
2023-07-15 14:12:53 <Habbie> lucidiot, the antagonist is glibc?
2023-07-15 14:15:16 <psykose> no antagonist
2023-07-15 14:52:40 <ptrc> alpine linux the slice of life anime
2023-07-15 14:52:59 <psykose> predictable
2023-07-15 14:57:40 <ptrc> yeah
2023-07-15 14:57:47 <ptrc> little ever happens in alpine, and this is good
2023-07-15 14:58:40 <psykose> bully
2023-07-15 15:00:20 <elly> it's a romantic comedy starring the busybox and musl maintainers
2023-07-15 15:02:07 <psykose> dalias would never
2023-07-15 15:05:23 <elly> it's an action movie starring psykose and an endless horde of slightly outdated packages
2023-07-15 15:05:35 <bl4ckb0ne> whats the outro song
2023-07-15 15:06:13 <elly> I'll Make A C Programmer Out Of You
2023-07-15 15:08:16 <lucidiot> ok there's the slice of life anime, but there's a movie based on it that's about a new release of python or boost
2023-07-15 15:08:26 <bl4ckb0ne> im happy as long as it features psykose dancing 
2023-07-15 15:08:31 <lucidiot> +1
2023-07-15 15:08:32 <psykose> i don't dance tho
2023-07-15 15:08:40 <lucidiot> time to learn
2023-07-15 15:08:42 <elly> fortunately movies are works of fiction
2023-07-15 15:08:50 <elly> we'll just use AI to generate it
2023-07-15 15:08:52 <psykose> some things are too far
2023-07-16 02:16:21 <Arnavion> Another day, another segfault in firefox
2023-07-16 04:14:55 <psykose> haven't had one of those in a while
2023-07-16 04:15:01 <psykose> except for the 6.4 kernel thing
2023-07-16 06:45:50 <ikke> on 32-bits systems, we also still get the invalid host header error from docker
2023-07-16 06:46:06 <ikke> Installed:                                Available:
2023-07-16 06:46:07 <ikke> docker-cli-24.0.4-r2                    = 24.0.4-r2
2023-07-16 06:53:06 <psykose> with docker run or something else
2023-07-16 06:53:48 <psykose> and did you restart it in -r2
2023-07-16 06:55:27 <psykose> if it's docker compose then you have to upgrade for docker-cli-compose too
2023-07-16 06:56:54 <ikke> the host is still on alpine 3.17
2023-07-16 06:57:06 <ikke> and it happens with docker build
2023-07-16 06:57:18 <ikke> so it's only cli which is newer
2023-07-16 06:57:44 <ikke> non-32 bits arches work fine, but for some reason it fails on the 32-bits arches
2023-07-16 06:58:07 <psykose> i'm confused
2023-07-16 06:58:13 <psykose> you installed docker-cli-24 on the docker-20 in 3.17?
2023-07-16 06:59:33 <ikke> docker-cli in a docker container
2023-07-16 06:59:51 <ikke> alpinelinux/docker-cli:latest-x86 for example
2023-07-16 07:00:03 <psykose> ah
2023-07-16 07:03:30 <ikke> Not sure why 32-bits would make a difference, but it failed on x86, armhf and armv7
2023-07-16 07:03:56 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/golang/-/pipelines/170684
2023-07-16 07:05:14 <psykose> yeah i can reproduce it
2023-07-16 07:05:16 <psykose> not sure why
2023-07-17 06:13:27 <Newbyte> Why did I get an email saying that I've been granted "Guest" access to alpine/aports
2023-07-17 06:30:57 <psykose> does what it says on the tin
2023-07-17 06:31:42 <psykose> (lets u press approve)
2023-07-17 08:09:31 <markand> o/
2023-07-17 08:09:46 <markand> I've received a gitlab notification that I got Guest access to alpine/aports. what does that mean?
2023-07-17 08:48:02 <ikke> markand: that you can now approve merge request 
2023-07-17 08:57:38 <markand> oh <3 
2023-07-17 10:05:58 <maribu> ikke: Guest access allows you to approve MRs, but not to merge them, right? I also got guest access and I would not feel comfortable with merge permission.
2023-07-17 10:10:20 <maribu> Other topic: Could it be that the rust toolchains obtained via rustup with the musl update cause a number of issues? To me it looks like it is asking for explicit 64 bit safe versions such as lseek64, which is provided by #define lseek64 lseek on my system (so no symbol to link against). I assume all the other are also not provided as symbols.
2023-07-17 10:13:25 <maribu> In case of `lseek64` I think something like `__attribute__((alias("lseek"))) off64_t lseek64(int fd, off64_t offset, int whence);` added to the file where `lseek` is implemented would be a quick workaround on our side. It would just create a second symbol for the same `lseek` function, so it would not come at the cost of more machine code being linked in. But the symbol table would of course grow.
2023-07-17 10:17:21 <ikke> maribu: correct, you need at least developer access for that
2023-07-17 10:17:52 <ikke> Musl removed lfs64 support 
2023-07-17 10:18:08 <ikke> So the *64 variants are no longer present 
2023-07-17 10:21:24 <maribu> But why the heck is rust now _starting_ to use them in the musl flavors? My hope was that the "we updated musl support" would improve things, not wrosen them :'-(
2023-07-17 10:56:19 <abby> ? pretty sure 1.71 updated to musl 1.2.3, not .4 where the 64 symbol stuff happened
2023-07-17 11:37:34 <maribu> I see. So before it was just using lseek() and time() and there 32 bit time_t and off_t on 32 bit. And I just was lucky that I was using 64 bit system anyway. Now it starts using lseek64() etc. the issues start to pop up.
2023-07-17 17:33:52 <ysionneau> Hi! I am playing at trying to bootstrap Alpine on kvx using aports/scripts/bootstrap.sh   , but I notice that for lots of packages using autotools I need to either add a patch in the package APKBUILD to add the arch in config.sub
2023-07-17 17:34:20 <ysionneau> or add a prepare() { that does default_prepare and update_config_sub (I modified the latter in abuild to also check for kvx
2023-07-17 17:34:34 <ysionneau> is there a 3rd less painful way?
2023-07-17 17:34:55 <ysionneau> (other than adding to upstream autoconf support for kvx and waiting ages for everybody to update their scripts?)
2023-07-17 17:35:51 <ikke> the latter is what we do. For example when building for rv64, we had to add the update_config_sub to quite some packages
2023-07-17 17:36:32 <ysionneau> so you had your fork of aports where you modified lots of packages to add the update_config_sub?
2023-07-17 17:37:03 <ikke> No, we as in alpine linux itself
2023-07-17 17:37:10 <ysionneau> ah ok
2023-07-17 17:37:19 <ysionneau> so it was pushed in the main aports directly
2023-07-17 17:37:21 <ikke> yes
2023-07-17 17:37:51 <ysionneau> thanks I'll keep adding those then :)
2023-07-17 17:42:11 <ikke> an alternative would be patching abuild to check if a config.sub is present and automatically updating it
2023-07-17 17:43:11 <ysionneau> that would be like calling update_config_sub from default_prepare unconditionally , right ?
2023-07-17 17:43:37 <ikke> more or less, but by default, it would return false if it was not updated, which would cause the build to fail
2023-07-17 17:43:53 <ysionneau> ah so I would have to tweak it a little bit
2023-07-17 17:51:47 <ysionneau> I have 48 native packages built so far o/
2023-07-17 17:52:35 <ikke> nice
2023-07-17 17:52:39 <ikke> never heard of kvx
2023-07-17 17:52:56 <ysionneau> it's not widely spread so far ...
2023-07-17 17:53:02 <ysionneau> very niche
2023-07-17 17:53:14 <ysionneau> it's a vliw arch made by a small French company
2023-07-17 17:54:02 <ysionneau> so far it's mostly used as DPU accelerator for storage appliances, and accelerator like a PCIe OpenCL card
2023-07-17 17:55:21 <ysionneau> how many packages approximately are built by bootstrap.sh ?
2023-07-17 17:55:55 <ikke> I don't know from the top of my head
2023-07-17 17:57:43 <ikke> there are ~60 packages in the list
2023-07-17 17:58:19 <ysionneau> the idea is to build a native toolchain and then build "all the remaining" packages from a native target, right?
2023-07-17 17:58:26 <ikke> yes
2023-07-17 17:58:30 <ysionneau> ok
2023-07-17 17:58:49 <ikke> for rv64 we use qemu-user atm
2023-07-17 17:58:53 <ysionneau> I've never run gcc on kvx natively so far, it will be a first test :p
2023-07-17 17:59:13 <ysionneau> be it on fpga or asic or qemu
2023-07-17 17:59:57 <ysionneau> anyway I am playing with Alpine (and podman) for the first time
2023-07-17 18:00:08 <ysionneau> and the packaging / build system works quite well
2023-07-17 18:00:16 <ysionneau> it's cool to play with
2023-07-17 18:00:20 <ikke> glad to hear
2023-07-17 21:18:00 <ysionneau> hm something quite strange, the bootstrap process seems to be able to compile C code with the cross toolchain so far, but if I just doas apk add build-base-kvx and then manuall try to compile anything, no standard header can be found (like <stdio.h>)
2023-07-17 21:18:21 <ysionneau> I guess abuild or bootstrap is doing something more than just installing build-base-kvx before compiling target packages?
2023-07-17 21:18:48 <ysionneau> manually*
2023-07-17 21:19:40 <ysionneau> and indeed I just find the system stdio by doing find / -name stdio.h
2023-07-17 23:47:22 <psykose> maribu: no, it's always been broken
2023-07-17 23:47:36 <psykose> it's the change to musl that breaks that, since the when linking rust expects to find the 64 symbols
2023-07-17 23:47:50 <psykose> and now they're gone
2023-07-18 09:08:38 <omni> PureTryOut: I assume 8f575fae0d3df3e4157e6b1694c45c4e9cac7291 is a workaround since invent.kde.org disabled downloading of commit tarballs, as it took too much resources of their infrastructure, and several projects don't tag releases often or ever
2023-07-18 09:08:44 <omni> but I still have questions
2023-07-18 09:09:20 <omni> did https://git.alpinelinux.org/aports/diff/community/extra-cmake-modules/APKBUILD?id=8f575fae0d3df3e4157e6b1694c45c4e9cac7291 work as intended? first you set _commit then you unset it, right?
2023-07-18 09:09:54 <omni> (first example I found of the new feature being used)
2023-07-18 09:11:35 <omni> and then, since the created tarball is not part of source= there will be no check against sha512sums=, any idea of how to handle that?
2023-07-18 09:42:19 <psykose> you have to manually set it and it's not used for the actual build at all, intentionally
2023-07-18 09:43:10 <psykose> it's also not a workaround for anything, as the message says it's only for testing some commits
2023-07-18 09:43:16 <psykose> all the kde stuff tags releases at the same time just fine
2023-07-18 09:47:13 <psykose> they also didn't disable downloading commit tarballs (?)
2023-07-18 09:47:37 <psykose> if anything downloading a commit tarball is less load than cloning it and archiving a specific commit lol
2023-07-18 10:00:02 <PureTryOut> The empty _commit variable will be filled by scripts, but that won't be done in aports
2023-07-18 10:00:02 <PureTryOut> omni: nah we're just downloading release tarballs, works just fine and is how KDE intended it. I added the snapshot mainly to make local testing of git master of everything easier while they don't like us downloading git tarballs directly from Gitlab.
2023-07-18 10:00:48 <PureTryOut> and in that same script the source will be changed to that locally generated tarball, at which point checksums will be generated etc
2023-07-18 10:04:54 <psykose> their advice is confusing because doing that clone is more load on their infrastructure than just using /archive/$gitsha.tar.gz
2023-07-18 10:05:37 <psykose> it only becomes more if a bunch of people do it, whereas on our side we cache after one clone into our own dev.a.o for the qt stuff.. but in general it's not good advice
2023-07-18 10:06:08 <ddevault> I seem to have been given push access to aports? is that right?
2023-07-18 10:06:22 <psykose> guest is just 'press approve button' access
2023-07-18 10:06:34 <ddevault> ah, okay
2023-07-18 10:06:45 <psykose> since that broke a long time ago, but i guess i went thru a bunch of profiles and added that so people can press it again
2023-07-18 10:07:04 <psykose> gitlab removed non-'members' being able to press it in like 15.5 or something
2023-07-18 10:41:46 <omni> psykose: I think they did? or at least talked about it, cant find the discussion now, but it was the reason we went for aaf1005393f39af36e6591bf8c5f38d34843cae8
2023-07-18 10:42:09 <omni> changing upstream source
2023-07-18 10:42:17 <psykose> no, they just say they prefer for you not to
2023-07-18 10:42:18 <omni> PureTryOut: ah, ok
2023-07-18 10:42:41 <psykose> but it's not a "please don't use /archive and clone the full repo every time" i don't think :p
2023-07-18 10:42:54 <psykose> it's a "stop spamming the archive endpoint for downstream consumption"
2023-07-18 10:43:07 <omni> yeah
2023-07-18 10:43:12 <psykose> for qt stuff e.g. for us it's 8x builds that would all pull it
2023-07-18 10:43:16 <psykose> vs 1 clone, the clone is les
2023-07-18 10:43:33 <psykose> for "testing a random commit", uhh the /archive is probably less than just a full clone to get a .tar.gz of one commit
2023-07-18 10:44:01 <ikke> if you want even lighter weight, just use tar
2023-07-18 10:44:09 <ikke> that should be fairly lightweight for the server
2023-07-18 10:44:12 <psykose> yeah, also supported
2023-07-18 10:44:26 <psykose> then again i don't actually know their gitlab setup
2023-07-18 10:44:34 <psykose> maybe they have some extremely optimised clone
2023-07-18 10:44:40 <psykose> and it's less than any archive
2023-07-18 10:44:42 <psykose> who knows!
2023-07-18 10:44:50 <psykose> i doubt it though
2023-07-18 16:51:54 <srslypascal_> hi, is there any elegant solution to craft a pkgrel "between" two integers? I want to create a custom repo for alpine 3.16 that contains ghostscript packages with commits fixing CVE-2023-36664 backported, but I want to use a pkgrel "between" the current pkgrel=1 and an expected/presumed future pkgrel=2 such that the package from my repo would be detected as an available update if ghostscript 9.56.1-r1 is installed, but that a future 
2023-07-18 16:51:54 <srslypascal_> ghostscript 9.56.1-r2 package from the "official" alpine repos would be detected as an available update to the package from my custom repo. On Archlinux, this can be done by using a pkgrel with a decimal component, but this doesn't seem to work with Alpine's APKGBUILDs. Is there any other way to achieve this?
2023-07-18 16:52:41 <ikke> srslypascal_: I'm not aware of any way to achieve that
2023-07-18 16:58:40 <srslypascal_> Hm, that's sad, but thanks anyway :)
2023-07-18 17:03:56 <ikke> srslypascal_: It already has been upgraded in 3.17, will probably be soon upgrade in 3.18 as well
2023-07-18 17:06:38 <srslypascal_> ikke: is alpine 3.18 affected at all? AFAIK upstream have released ghostscript 10.01.2 specifically because that release fixes CVE-2023-36664.
2023-07-18 17:07:02 <ikke> oh, well, 3.15-3.17 have been fixed now
2023-07-18 17:07:16 <ikke> 3.17 upgraded, 3.15, 3.16 patched
2023-07-18 17:07:48 <ikke> I misread 3.16 in your message as 3.18
2023-07-18 17:08:01 <ikke> mailsize.website
2023-07-18 17:08:08 <ikke> http://dup.pw/alpine/aports/bd4535601c55
2023-07-18 17:08:10 <srslypascal_> oh, thanks <3
2023-07-18 17:08:16 <srslypascal_> just saw the git commit :)
2023-07-18 17:08:23 <ikke> psykose did all the work :)
2023-07-18 17:11:22 <srslypascal_> thanks a lot psykose :)
2023-07-19 11:52:59 <singham> I want to enable dnssec for pdns
2023-07-19 11:53:14 <singham> When I try
2023-07-19 11:53:26 <singham> pdnsutil secure-zone example.com
2023-07-19 11:53:43 <singham> It throws an error that gsqlite3-dnssec backend not here. Try with that flag.
2023-07-19 11:54:09 <singham> Is the default package compiled without that support?
2023-07-19 12:12:50 <singham> Any replies on my query? I was offline for a while.
2023-07-19 18:57:58 <fluix> is anything holding back https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47967#note_322443 now that https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47967 was merged?
2023-07-19 19:02:21 <ikke> fluix: holding back what exactly?
2023-07-19 19:02:45 <fluix> from being merged
2023-07-19 19:02:50 <fluix> ._.
2023-07-19 19:03:05 <fluix> sorry, bad link, meant https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/48650
2023-07-19 19:30:28 <psykose> porting everything to it
2023-07-19 19:32:01 <fluix> makes sense
2023-07-19 19:32:32 <psykose> singham: it means you have to put gsqlite3-dnssec into the configuration https://doc.powerdns.com/authoritative/backends/generic-sqlite3.html
2023-07-20 06:08:17 <psykose> PureTryOut: i'll backport 6.5.2 to 3.18 too for the usual sea of fixes https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.5.2/release-note.md
2023-07-20 06:09:32 <PureTryOut> Sure 👍️
2023-07-20 06:09:43 <quinq> Sure thumb
2023-07-20 06:39:36 <ncopa> im bumping linux-lts to 6.1.39
2023-07-20 08:31:21 <ikke> Need to shutdown the x86_64 builder for a bit for some maintenance 
2023-07-20 08:32:33 <ncopa> how long downtime? an hour or a week?
2023-07-20 08:33:11 <ikke> Hour or so
2023-07-20 08:33:30 <ikke> Probably less 
2023-07-20 08:34:43 <ncopa> awesome. thanks!
2023-07-20 08:37:04 <ncopa> Any volunteers to help this person create merge requests? https://lists.alpinelinux.org/~alpine/users/%3CCAMSJjc%3Dc-4CFMB88kTJEToK5vLE8mJEs2Oko%3DzR4C1ZdjyRzuw%40mail.gmail.com%3E
2023-07-20 08:37:26 <ncopa> i wonder if we should create a quickstart guide on how to use gitlab
2023-07-20 08:51:40 <PureTryOut> That probably exists already somewhere 🤔
2023-07-20 09:01:38 <psykose> they can't make merge requests from that repo, it's not a fork of anything
2023-07-20 09:01:54 <psykose> they manually recreated it from scratch and have a git history that looks like https://gitlab.alpinelinux.org/trinity-labs/mini_httpd-lighttpd/-/commits/main?ref_type=heads
2023-07-20 09:03:52 <psykose> they have their own copied version of setup-acf too etc
2023-07-20 09:04:09 <psykose> dunno what to say except that the quality of this wrt actually integrating it somewhere is basically zero
2023-07-20 09:04:23 <psykose> they would have to just undo all of it and make some other change somewhere else to do it
2023-07-20 09:04:41 <psykose> you'd have to teach them git as an entirety
2023-07-20 09:17:31 <ncopa> that was basically what i was asking for, if someone wants to help them use git
2023-07-21 01:03:12 <craftyguy> fyi it looks like the build-edge-x86_64 builder might be stuck
2023-07-21 01:03:54 <craftyguy> ( I see the message about it being shut down a few hours ago for maintenance, so maybe it's not back yet? )
2023-07-21 01:20:59 <psykose> it's not
2023-07-21 04:44:15 <Arnavion> Even chromium (115.0.5790.98-r0, aarch64) segfaults on startup now...   https://paste.rs/5BCgw
2023-07-21 04:46:45 <Arnavion> Surely it doesn't need to be rebuilt just because of the musl bump
2023-07-21 06:50:51 <Arnavion> Well, of all the hacky things to do, the firefox and chromium packages from 3.18 work fine... At least it means the problem is definitely in them and not something else like mesa or whatever. I'll investigate more and make an aports issue later
2023-07-21 16:06:49 <ysionneau> ok, bootstrap is done for kvx, all packages are built (except llvm14 llvm16 rust)
2023-07-21 16:07:17 <ysionneau> what should I do now to generate a rootfs ? use genrootfs.sh ? what are the arguments ? I should give it all the bootstrapped apk ?
2023-07-21 16:46:03 <ysionneau> ok it seems I just need to run doas ./genrootfs.sh -o alpine-kvx.tar.gz -a kvx ~/packages/main/kvx/*.apk   but with some apk removed because they require dependencies not built during bootstrap like perl/python/etc
2023-07-21 22:45:08 <psykose> Arnavion: i've seen similar on startup only with like a 5% chance
2023-07-21 22:45:10 <psykose> not at runtime tho
2023-07-21 22:48:18 <psykose> different bt too
2023-07-22 07:43:33 <psykose> nmeum: might want to disable ASH_SLEEP in bb since it's disabled upstream now too after even more complaints https://git.busybox.net/busybox/commit/?id=5e0411a7fb510b9aecda0a850c76bdd62c50efa4
2023-07-22 14:14:35 <joe> Hey guys, I was wondering are you guys planning to move from openrc to s6? If so if I currently have alpine linux installed, would the change be pushed via updates?
2023-07-22 16:07:04 <skarnet> joe: they're waiting for s6-rc v1, which I'm (slowly) still working on
2023-07-22 16:13:32 <Saijin_Naib[m]> Can a live machine be transitioned to S6 from OpenRC, or would a clean install be required? 
2023-07-22 16:14:07 <psykose> everything is possible with enough superglue
2023-07-22 16:17:20 <Saijin_Naib[m]> Hmm 🤔 rather, is that a goal or non-goal, I guess it's the better question 
2023-07-22 16:18:43 <psykose> i would say it would probably be considered a blocker to do it at all (some form of migration, manual or otherwise after an upgrade)
2023-07-22 16:18:53 <psykose> it would make more sense to just have two choices in parallel for x time
2023-07-22 16:18:58 <psykose> that said i doubt that is ever happening so
2023-07-22 16:30:11 <skarnet> Saijin_Naib[m]: the plan is to have enough integration with the package manager so you don't need to reinstall, just apk add the relevant packages
2023-07-22 16:30:22 <skarnet> it would still be a hefty upgrade
2023-07-22 16:30:42 <skarnet> psykose: give it a couple more decades and I swear it's happening
2023-07-22 16:31:35 <psykose> it's pretty much impossible to make it just an upgrade
2023-07-22 16:31:49 <skarnet> well you need to reboot at some point, obviously
2023-07-22 16:32:25 <skarnet> but I have a full transition plan laid out, it's theoretically sound
2023-07-22 16:32:35 <skarnet> would such a plan be accepted by Alpine? that's another question
2023-07-22 16:32:41 <Saijin_Naib[m]> Ah, okay, that sounds great 
2023-07-22 16:33:08 <psykose> so far from what i gather 90% of this plan is complaining about whether something gets accepted or not because that just so happens to be the focus in every discussion
2023-07-22 16:33:12 <psykose> or maybe even 100%
2023-07-22 16:33:57 <skarnet> psykose: I'm not arguing with your bad faith today
2023-07-22 16:34:32 <psykose> it's not even bad faith, i can't remember a single conversation where that wasn't magically mentioned
2023-07-22 16:35:15 <skarnet> yeah well that's not on me, all right?
2023-07-22 16:35:25 <psykose> you're the one mentioning it every time!
2023-07-22 16:35:44 <skarnet> I may or may not still be salty about previous experiences
2023-07-22 16:35:55 <skarnet> doesn't mean I don't have a plan
2023-07-22 16:36:20 <psykose> what is the plan
2023-07-22 16:37:20 <skarnet> I'll write it down when we get to that point
2023-07-22 16:37:32 <skarnet> it's real work, not something I can sum up in 2 min
2023-07-22 16:44:42 <psykose> i mean i do agree with the general nihilism
2023-07-22 16:44:57 <psykose> it's just one of those things that's such a collosal amount of work nobody is ever going to do it and it won't happen
2023-07-22 16:45:05 <psykose> if it does it's going to be worse than that first pulseaudio rollout
2023-07-22 16:49:19 <skarnet> we'll see. For now the onus is on me to actually do the thing, and I can't criticize anyone until it's actually done
2023-07-22 18:40:07 <ysionneau> is there an alpine package that is supposed to contain/create the /dev/console ? my rootfs contains nothing in /dev
2023-07-22 18:40:43 <ysionneau> and the kernel is complaining about that at boottime (though it's just a simple warning)
2023-07-22 18:42:47 <psykose> how would a package create a character file?
2023-07-22 18:43:26 <psykose> it's some part of init that makes it when booting
2023-07-22 18:43:32 <psykose> same for everything else in dev
2023-07-22 18:43:36 <psykose> it's devices, not files
2023-07-22 18:43:48 <ysionneau> I am new to alpine packages but I thought some /dev/* could be part of the initramfs 
2023-07-22 18:43:51 <ysionneau> I think buildroot does that
2023-07-22 18:44:12 <psykose> it has nothing to do with alpine, /dev is not a place with files, the boot process makes stuff in it
2023-07-22 18:45:19 <psykose> generally the device manager does so (udev, mdev, ...)
2023-07-22 18:45:26 <psykose> a rootfs does not have anything in a /dev
2023-07-22 18:45:37 <ysionneau> I think some /dev "files" can be statically created with mknod
2023-07-22 18:46:07 <psykose> theoretically you can populate the whole dev with mknod if you wanted, yes
2023-07-22 18:46:13 <psykose> and you should just not do that and do it when booting
2023-07-22 18:47:13 <ysionneau> I think some systems do a mixed approach, like most devices indeed created dynamically with udev/systemd/... but some basic ones are part of the initramfs 
2023-07-22 18:48:45 <ysionneau> anyway, that's why I am asking: https://elixir.bootlin.com/linux/latest/source/init/main.c#L1532
2023-07-22 18:48:55 <ysionneau> so I was thinking that /dev/console was supposed to be part of the rootfs
2023-07-22 18:49:01 <ysionneau> maybe I'm wrong then
2023-07-22 18:50:06 <minimal> whether /dev/console exists and whether /dev/console is part of the rootfs are two different things
2023-07-22 18:50:33 <ysionneau> well it seems that the kernel is running this code very early, even before running init I would say
2023-07-22 18:52:35 <psykose> https://img.ayaya.dev/GNEE3zBdsCj4
2023-07-22 18:52:50 <ysionneau> yes
2023-07-22 18:53:27 <ysionneau> it seems it tries to open /dev/console right after having unpacked the initramfs
2023-07-22 18:54:41 <psykose> it might be
2023-07-22 18:54:46 <psykose> i wonder why i don't see a warning then
2023-07-22 18:54:47 <psykose> hm
2023-07-22 19:00:35 <minimal> which rootfs though? when initramfs' init runs it has its own rootfs before it mounts the root device and does a switch_root to that
2023-07-22 19:02:10 <ysionneau> so far I only have an initramfs and no real rootfs
2023-07-22 19:04:10 <ysionneau> hm I think I understand now why my kernel does not like my ramfs, I didn't have any /bin/init , but I thought it was OK because I was doing init=/bin/sh on the cmdline
2023-07-22 19:04:19 <minimal> "an" initramfs? or an Alpine initramfs built using mkinitfs?
2023-07-22 19:04:20 <ysionneau> but I don't think this works for initramfs, just for real rootfs
2023-07-22 19:04:56 <ysionneau> minimal: it's an initramfs I build using cpio+gzip , out of the tree generated by aports/scripts/genrootfs.sh
2023-07-22 19:05:01 <ysionneau> built*
2023-07-22 19:05:11 <psykose> wasn't it just /init without /bin
2023-07-22 19:05:30 <ysionneau> ah maybe, I have created a symlink, let's see if it's any better...
2023-07-22 19:06:58 <ysionneau> minimal: context is, I am trying to bootstrap Alpine on a new arch (kvx)
2023-07-22 19:07:05 <ikke> it's the initramfs that reads the init arg
2023-07-22 19:07:13 <ysionneau> so I am starting pretty much from scratch
2023-07-22 19:07:14 <minimal> so in otherwords you are not using the standard Alpine initramfs
2023-07-22 19:07:35 <ysionneau> no, I am trying to use what's coming out from genrootfs.sh , but maybe I should not do that :)
2023-07-22 19:07:48 <ysionneau> ikke: aaah right ok
2023-07-22 19:08:07 <minimal> the standard Alpine initramfs is created by mkinitfs and uses a shell script as its init
2023-07-22 19:08:25 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L600
2023-07-22 19:10:16 <ysionneau> ok I'll try to use mkinitfs on my host to generate the target initramfs
2023-07-22 19:10:55 <ysionneau> thanks
2023-07-22 19:13:08 <ysionneau> maybe trying to use the "rootfs" (generated by genrootfs) as an initramfs was not a good idea after all...
2023-07-22 19:14:16 <ysionneau> ok indeed with /init being a link to /bin/sh it "works better", at least it detects the init and tries to run it
2023-07-22 20:18:07 <ysionneau> ah one of my issues is that genrootfs.sh (that I run on x86_64) is trying to execute target busybox in order to create the symlinks in the rootfs
2023-07-22 20:18:10 <ysionneau> for link in $("$tmp"/bin/busybox --list-full); do <==
2023-07-22 20:18:14 <ysionneau> but this obviously fails
2023-07-22 20:18:32 <ysionneau> so I don't get the symlinks, therefore no mknod and such and /init is not happy
2023-07-22 20:20:36 <psykose> yeah, it's not exactly cross friendly
2023-07-22 20:20:42 <psykose> that step would work with qemu-user, but....
2023-07-22 20:20:42 <psykose> :D
2023-07-22 20:21:00 <ysionneau> yes ^^
2023-07-22 20:21:13 <ysionneau> I'll try temporarily remove the $tmp prefix
2023-07-22 20:21:20 <psykose> theoretically ok
2023-07-22 20:21:21 <ysionneau> by removing*
2023-07-22 20:21:28 <psykose> same set of stuff
2023-07-22 20:21:32 <ysionneau> ype
2023-07-22 20:21:34 <ysionneau> yes*
2023-07-22 20:22:05 <ysionneau> looks better!
2023-07-22 22:17:42 <omni> I got probably expected errors of the py3-rpds -> p3-rpds-py rename, the new package didn't install because it would overwrite files of the old and the old package was purged after that, so 'apk fix' solved it
2023-07-22 22:24:12 <psykose> hm yeah forgot to do that
2023-07-22 22:48:56 <skarnet> about /dev/console: the kernel exports a minimal set of devices itself when you mount devtmpfs, which normally is done automatically at boot time
2023-07-22 22:49:15 <skarnet> /dev/null and /dev/console, which are mandated by posix, are part of that minimal set
2023-07-22 22:49:25 <skarnet> they're present even before the device manager runs
2023-07-22 22:49:35 <skarnet> so normally you don't have to do anything
2023-07-22 22:50:11 <skarnet> your rootfs just needs to have an existing /dev directory where devtmpfs can be mounted
2023-07-22 23:02:16 <psykose> interesting
2023-07-22 23:02:33 <psykose> even that half broken one definitely had a /dev pretty sure since that's just a mkdir
2023-07-22 23:05:00 <skarnet> yeah it's the first thing you do when making a thing that will serve as a rootfs: mkdir /dev XD
2023-07-23 06:03:20 <Hello71> iirc linux doesn't automount devtmpfs in initramfs, even if the automount option is enabled
2023-07-23 06:05:52 <Hello71> yeah, you have to mount it yourself. stdio is pre-attached to a /dev/console that doesn't exist on the filesystem
2023-07-23 06:06:07 <Hello71> https://cgit.alxu.ca/minitramfs.git/tree/init#n8
2023-07-23 14:36:32 <handlerug> is there a reason that zfs is still at 2.1.12 or is it just that no one bumped the version yet?
2023-07-23 14:37:05 <abby> why wouldn't it be? that's the latest version of zfs
2023-07-23 14:37:29 <psykose> lol
2023-07-23 14:37:45 <abby> 2.2 is still in rc
2023-07-23 14:39:16 <handlerug> ah indeed i can't read version strings, thanks
2023-07-23 14:39:46 <sam_> git snapshots bro
2023-07-23 14:40:23 <abby> apk add zfs-9999
2023-07-23 22:01:24 <ysionneau> I have alpine initramfs starting to boot on kvx *_*
2023-07-23 22:03:36 <ysionneau> https://pastebin.com/MT8rKkJS
2023-07-24 09:31:44 <ikke> libgudev no longer compattible with eudev (due to eudev lagging behind) https://lore.kernel.org/distributions/ZLxSolytyFht4Xvv@sysrq.in/T/#u
2023-07-24 09:33:52 <psykose> known for a while
2023-07-24 09:34:09 <psykose> good advice too tbh
2023-07-24 09:34:15 <psykose> i've wanted to do that for a long time
2023-07-24 09:43:36 <ncopa> can you build systemd-udev separately?
2023-07-24 09:43:58 <psykose> you mean as a standalone component? yes
2023-07-24 09:44:06 <ncopa> lets do that then
2023-07-24 09:44:09 <psykose> are you sure?
2023-07-24 09:44:23 <psykose> i don't mind doing it but i'm just making it sound a little smaller
2023-07-24 09:44:30 <ncopa> what is the implication?
2023-07-24 09:45:03 <ncopa> last time i checked the sysmted components were highly integrated (by design) and it was complicated to separate out things
2023-07-24 09:45:22 <psykose> nah, builds standalone
2023-07-24 09:45:23 <ncopa> i got the feeling it was done to push users over to use everythign in systemd
2023-07-24 09:45:37 <psykose> it needs about 20 patches for the part of 'musl compat', but not because of coupling
2023-07-24 09:45:41 <psykose> that part i don't mind maintaining
2023-07-24 09:45:50 <psykose> the implication is it will be "systemd added to alpine" by name
2023-07-24 09:45:54 <ncopa> oh, right. 20 patches...
2023-07-24 09:46:01 <psykose> the reason i haven't proposed it yet is because i don't feel like arguing :D
2023-07-24 09:46:11 <ncopa> yeah, thats understandable
2023-07-24 09:46:13 <psykose> the actual packaging/build i can take care of just fine
2023-07-24 09:46:18 <ncopa> so you cannot build it separately without the 20 patches
2023-07-24 09:46:21 <psykose> then we have to do testing for scenarios
2023-07-24 09:46:47 <psykose> the 20 patches aren't "that bad", i rebase a lot of patchsets all the time i guess
2023-07-24 09:46:48 <psykose> gcc is "worse"
2023-07-24 09:47:05 <psykose> if you wanna help test and think stuff through it should be fine
2023-07-24 09:47:16 <psykose> the only thing that comes to mind is they well drop split-usr support, and idk what that means
2023-07-24 09:47:27 <ncopa> im skeptic about the 20 patches
2023-07-24 09:47:29 <psykose> we can install everything to one folder and just move it after just fine
2023-07-24 09:47:38 <psykose> the 20 patches is probably the easiest part
2023-07-24 09:47:46 <psykose> we could just call it eudev2
2023-07-24 09:47:53 <ncopa> the difference with gcc is that upstream gcc supports musl, while systemd does not
2023-07-24 09:48:26 <psykose> that's true
2023-07-24 09:49:07 <psykose> i believe there's a little more perspective though: eudev is just an old version of systemd-udev that sometimes imports some changes (but well, slowly), and is otherwise the same thing just less maintained
2023-07-24 09:49:21 <psykose> making eudev "up to date" would just be.. resyncing to systemd, then placing those 20 patches
2023-07-24 09:49:24 <psykose> (if that makes sense)
2023-07-24 09:49:41 <psykose> theoretically this is the same project. having 'udev with 20 patches' is basically like making a eudev2 and we are the maintainers
2023-07-24 09:49:49 <psykose> (not literally, but if you think about it)
2023-07-24 09:50:19 <psykose> for an example of how this looks, see https://github.com/chimera-linux/cports/tree/master/main/udev
2023-07-24 09:50:21 <ncopa> yes, but
2023-07-24 09:50:23 <psykose> that is just the udev with 20 patches
2023-07-24 09:52:31 <quinq> One problem is that then we're actually relying on systemd (as in implementation/upstream development), and they've not been historically very good at supporting anything outside their own target
2023-07-24 09:52:45 <quinq> Though the current alternative indeed isn't really better in the sense that it's unmaintained :/
2023-07-24 09:54:27 <ncopa> > the reason i haven't proposed it yet is because i don't feel like arguing :D
2023-07-24 09:54:33 <ncopa> this ^^^
2023-07-24 09:54:47 <ncopa> keeping eudev as separate proj helps with that
2023-07-24 09:55:18 <ncopa> im looking at the patches
2023-07-24 09:55:31 <ncopa> and it looks like nothing has changes since last time i looked at it
2023-07-24 09:56:10 <psykose> none of them are decoupling though
2023-07-24 09:56:14 <psykose> these are all 'for musl'
2023-07-24 09:57:08 <ncopa> they look like systemd for musl. not udev for musl
2023-07-24 09:57:43 <psykose> because most of the code is src/common,shared
2023-07-24 09:57:50 <quinq> It's clearly time for somebody with time on their hands to start an independant implementation!
2023-07-24 09:58:10 <psykose> which doesn't really matter where it is
2023-07-24 09:58:16 <ncopa> sigh. this is same thing all over again
2023-07-24 09:58:22 <psykose> none of it is like 'removing calls to logind to not require liblogind' or whatnot
2023-07-24 10:00:32 <ncopa> my experience with systemd in general has always been something like:
2023-07-24 10:01:00 <ncopa> "can you <something that would be nice for alpine>?"
2023-07-24 10:01:27 <ncopa> "oh yes! sure! Thats no problem at all!"
2023-07-24 10:01:50 <ncopa> "oh cool! lets do that then. How do I <something that would be nice for alpine>?"
2023-07-24 10:02:26 <ncopa> "no problem you just <something that effectively is forking and maintainingt the entire systemd project>"
2023-07-24 10:02:51 <quinq> haha :/
2023-07-24 10:02:52 <psykose> haha
2023-07-24 10:03:03 <psykose> yeah i am slightly underplaying the work involved i suppose
2023-07-24 10:03:22 <psykose> i guess we can just wait and do nothing
2023-07-24 10:03:25 <psykose> it doesn't break anything presently
2023-07-24 10:03:29 <quinq> It's like shaking your hand with a smile while giving you the finger with the other one
2023-07-24 10:03:46 <psykose> the people with $brokenstuff in the eudev libgudev issue are from fork-distros that take it from systemd-upstream and it's not compatible
2023-07-24 10:03:49 <psykose> doesn't apply to us
2023-07-24 10:04:11 <psykose> long term i guess we'll see
2023-07-24 10:04:28 <psykose> theoretically we're part of the eudev maintainers.. though realistically nothing happened ever since that all got announced
2023-07-24 10:04:39 <psykose> and bbonev was the only one trying to maintain it
2023-07-24 10:05:00 <psykose> i think it's a bit too far gone at this point though, in the sense of it makes more sense to just restart the fork if anyone actually wants to do it
2023-07-24 10:06:43 <ncopa> quinq: that exactly how I feel every time
2023-07-24 10:08:34 <quinq> Yeah because there's also the problem of backwards compatibility, to not be part of the forced switch
2023-07-24 10:09:01 <quinq> (I don't know how much their API has changed and become uncompatible)
2023-07-24 10:10:43 <psykose> the mostly relevant api is libudev which afaik is the same with more symbols
2023-07-24 10:10:46 <psykose> and if anything fewer bugs
2023-07-24 10:10:59 <psykose> the commandline stuff is probably mostly the same
2023-07-24 11:14:25 <nmeum> psykose: re botan3: should we maybe compile it with -Os on x86 then? since this is a cryptographic library a misscompilation on x86 may actually have quite severe effects
2023-07-24 11:14:46 <nmeum> also: on -stable it also doesn't segfault in check() so might be a regression in recent gcc version if this is in fact a miscompilation
2023-07-24 11:14:55 <psykose> it does look like a miscompilation yeah
2023-07-24 11:15:04 <psykose> dunno up to you
2023-07-24 11:15:10 <psykose> if it gets fixed somehow that would be nice
2023-07-24 11:15:13 <psykose> also i tried
2023-07-24 11:15:20 <psykose> -O1 -fno...(huge list of stuff)
2023-07-24 11:15:23 <psykose> and it still fails
2023-07-24 11:15:30 <psykose> for everything i could find Os does
2023-07-24 11:15:34 <psykose> so i think this is quite weird
2023-07-24 11:15:46 <psykose> one thing that's different from stable is the default
2023-07-24 11:15:58 <psykose> -msse -msse2 -mfpmath=sse is implied
2023-07-24 11:16:08 <psykose> i tried fpmath=387 and that didn't change it which is the most meaningful one
2023-07-24 11:17:05 <nmeum> could try later if it segfaults on -stable with -msse -msse2 -mfpmath=sse in CXXFLAGS
2023-07-24 11:17:11 <nmeum> should be easy to test with the dockerfile
2023-07-24 11:17:47 <psykose> i doubt it tbh
2023-07-24 11:17:52 <psykose> probably just a 13 regression somewhere
2023-07-24 11:18:28 <nmeum> yea, most likely
2023-07-24 11:18:37 <nmeum> but debugging C++ miscompilation in a large code base like botan is really a pain
2023-07-24 11:18:59 <nmeum> I think I would just opt for compilling it with -Os for the time being and hoping that upstream adds a workaround at some point or that gcc gets a fix
2023-07-24 11:32:39 <psykose> go for it
2023-07-24 11:33:08 <psykose> maybe it was even a fluke that it worked
2023-07-24 12:39:26 <omni> hey, I just rebooted my laptop and everything still works as it should, thanks everyone!
2023-07-24 12:40:45 <psykose> 
ACTION squints

2023-07-24 12:40:53 <psykose> a non-negative message? the world's gone mad!
2023-07-24 13:15:24 <ikke> omni: I can reproduce 
2023-07-24 14:29:34 <skarnet> ikke: congrats!
2023-07-24 14:39:23 <ikke> Lol
2023-07-24 15:06:12 <zcrayfish> Hi there everybody, I'd like to suggest small potential edit to the APKBUILD for xscreensaver
2023-07-24 15:06:32 <zcrayfish> Adding elogind-dev to the makedepends, removing the --without-systemd option from the configure script, and adding --with-elogind to the configure script.
2023-07-24 15:07:02 <zcrayfish> This would cause the xscreensaver-systemd binary to be built (the manpage for it is built regardless, LOL), which enables dbus control of xscreensaver.
2023-07-24 15:19:36 <fluix> this is better discussed in the official channel on OFTC, or in a GitLab MR/Issue
2023-07-24 15:20:03 <fluix> nvm, this is the right channel, sorry about that :)
2023-07-24 15:20:20 <zcrayfish> haha, that's cool, I wasn't 100% sure if it was the right channel either =)
2023-07-24 17:45:06 <PureTryOut> So I'm trying to prepare an upgrade of some packages but something is holding them back. I fail to understand the output apk gives me, it tells me some of the new versions satisfy some deps and breaks others, and does the same for the older versions. How are you supposed to read conflict output?
2023-07-24 17:46:13 <ikke> PureTryOut: can you paste it somewhere?
2023-07-24 17:46:56 <PureTryOut> https://paste.sr.ht/~puretryout/e8f57d1f479694324839e78e88effd0f25d67cd0
2023-07-24 17:47:19 <PureTryOut> I've had trouble reading this kind of output for years now, it's really confusing 😅
2023-07-24 17:47:44 <ikke> yeah, it's not the most easiest to read
2023-07-24 17:50:36 <ikke> Did not complete yet, but so far I see something tries to keep one of the packages on 5.108.0-r1
2023-07-24 17:51:43 <ikke> thinking out loud:
2023-07-24 17:52:05 <ikke> karchive-5.108.0-r1 cannot be installed, because you specified 'karchive=9999_git20230719-r0' in world
2023-07-24 17:53:06 <PureTryOut> well I'm trying to get the 9999 stuff to install lol, upgrading from 5.108.0
2023-07-24 17:53:06 <ikke> karchive does satisfy a list of packages though
2023-07-24 17:53:12 <ikke> yes, understood
2023-07-24 17:53:20 <ikke> Just analyzing the output
2023-07-24 17:53:34 <PureTryOut> I do not have versioned stuff in world in this chroot though
2023-07-24 17:53:50 <ikke> PureTryOut: it comes from the apk add command
2023-07-24 17:53:58 <ikke> which would be part of world that apk tries to resolve
2023-07-24 17:53:59 <PureTryOut> ah ok
2023-07-24 17:55:21 <ikke> PureTryOut: You have to check each of the satisfies for karchive-5.108.0-r1 and see if it there is an equivalent for karchive=9999_git20230719-r0
2023-07-24 17:56:32 <PureTryOut> Fun 😅
2023-07-24 17:59:02 <PureTryOut> but this output doesn't show satisfies for the 9999 version?
2023-07-24 17:59:55 <ikke> apk policy kpackage knewstuff plasma-workspace kio kiconthemes kfilemetadata kio-extras ktexteditor plasma-framwork kdoctools
2023-07-24 18:01:04 <ikke> or apk version ...
2023-07-24 18:06:54 <ikke> what does that output?
2023-07-24 18:10:20 <PureTryOut> a lot 😅
2023-07-24 18:10:35 <ikke> the version command should be a bit less output
2023-07-24 18:10:36 <PureTryOut> https://paste.sr.ht/~puretryout/97cc63f14f90415c9eb1e93a5f4d7081ac0337f2
2023-07-24 18:11:14 <PureTryOut> The version command just shows there are updates available for all those packages
2023-07-24 18:12:26 <ikke> Not sure if that's the issue, but I see there is no 9999_git20230719-r0 version available for kio
2023-07-24 18:12:42 <ikke> and not for knewstuff either
2023-07-24 18:13:02 <PureTryOut> there is a 9999_git20230722 available though
2023-07-24 18:13:20 <ikke> does it depend on the newer karchive?
2023-07-24 18:15:12 <PureTryOut> let me check
2023-07-24 18:17:01 <PureTryOut> depends on so:libKF6Archive.so.6 which is provided by that version yes
2023-07-24 18:18:09 <ikke> kirigami2-libs-5.108.0-r1:
2023-07-24 18:18:13 <ikke> breaks: kirigami2-9999_git20230719-r0[kirigami2-libs=9999_git20230719-r0]
2023-07-24 18:18:24 <ikke> Not sure what breaks means exactly, but it's the only package where that's mentioned
2023-07-24 18:18:33 <ikke> (apart from world)
2023-07-24 18:19:07 <PureTryOut> yeah noticed that too
2023-07-24 18:21:33 <ikke> oh probably because kirigami2 has a hard version dependency?
2023-07-24 18:21:50 <ikke> on kirigami2-libs
2023-07-24 18:24:17 <PureTryOut> doesn't seem like it 🤔
2023-07-24 18:27:44 <PureTryOut> kirigami2-libs is just a simple default_libs package
2023-07-24 18:41:43 <PureTryOut> it would be great if it could just tell me "this is the package you have failed to update/rebuild" 😅
2023-07-24 18:42:20 <ikke> haha, yeah, that would've been nice
2023-07-24 18:43:16 <ikke> PureTryOut: does apk upgrade --available perhaps do something?
2023-07-24 18:43:57 <PureTryOut> already tried multiple times, sadly no
2023-07-24 18:44:41 <ikke> ok
2023-07-25 00:39:05 <omni> I'm having some weird issues with having a local 3.16-stable branch...
2023-07-25 00:55:50 <bl4ckb0ne> bit late for the eudev discussion but how long would it be to upgrade it to the latest udev api 
2023-07-25 00:56:40 <invoked> https://github.com/eudev-project/eudev/issues/249
2023-07-25 01:03:11 <zcrayfish> 
ACTION initiates facepalm

2023-07-25 04:45:03 <ikke> omni: what issue do you have?
2023-07-25 07:27:55 <ncopa> bl4ckb0ne: how long? I would guess it would require a couple of days of work. is probably less work to re-fork udev at this point
2023-07-25 07:45:34 <ikke> Getting by the docker host header issue left and right 🤔
2023-07-25 07:46:23 <ikke> !49102
2023-07-25 07:46:23 <psykose> getting by?
2023-07-25 07:46:31 <psykose> ah
2023-07-25 07:46:33 <ikke> Getting bitten by*
2023-07-25 07:46:40 <psykose> yeah anything that uses that repo needs a bump
2023-07-25 07:46:47 <psykose> now that there's a real release to fix it it's a bit easier
2023-07-25 07:47:11 <psykose> though only on 24
2023-07-25 07:47:18 <psykose> 23 branch doesn't
2023-07-25 07:47:22 <ikke> :/
2023-07-25 07:51:24 <psykose> i noticed all the gitlab runners have a different version of gitlab-runner :D
2023-07-25 07:52:11 <ikke> 🤐
2023-07-25 09:02:16 <ikke> psykose: so what needs to happen to fix that issue? Can that mr from ptrc be merged?
2023-07-25 09:07:59 <psykose> it can
2023-07-25 09:09:09 <psykose> if you upgrade everything to it it should work
2023-07-25 09:09:24 <psykose> also have to start the riscv builder
2023-07-25 09:23:43 <ikke> Done
2023-07-25 09:31:50 <omni> ikke: apparently I had an omni/3.16-stable remote
2023-07-25 09:36:48 <ikke> Oh, that's a fun one
2023-07-25 12:50:28 <ikke> psykose: my pipelines are happy again 🙂
2023-07-25 12:50:33 <psykose> <3
2023-07-25 12:51:05 <skarnet> ikke: congratulations - again!
2023-07-25 12:51:30 <psykose> what about
2023-07-25 12:52:16 <skarnet> yesterday he said he could reproduce, and today his pipelines are happy again. That's wonderful news!
2023-07-25 12:52:20 <skarnet> (don't mind me.)
2023-07-25 12:53:56 <Habbie> i suspect i understand that reference, the same way i suspected i understood it yesterday :D
2023-07-25 13:08:35 <psykose> ikke: is there a tmpfs mount in the lxc containers
2023-07-25 13:22:16 <psykose> i guess /dev/shm is one technically
2023-07-25 18:26:14 <markand> virtualizing Alpine aarch64 on macOS using UTM
2023-07-25 18:26:24 <markand> gorgeous for arm development on powerful platform
2023-07-25 19:47:01 <minimal> markand: using UTM's QEMU support or its support for Apple's native virtualisation?
2023-07-26 00:52:16 <fancsali[m]> Greetings all!
2023-07-26 00:52:16 <fancsali[m]> Probably a stupid question, but I'll risk it: I've seen `amove` scattered around in a few `APKBUILD`s, but couldn't find any docs for that – despite that it seems to be a staple tool.
2023-07-26 00:52:16 <fancsali[m]> What am I missing? 🤔
2023-07-26 00:55:56 <Arnavion> It's a shell function in abuild
2023-07-26 01:35:22 <fancsali[m]> I figured that much, but what does it do? Move things from the main package to the subpackage?
2023-07-26 01:37:34 <psykose> open /usr/bin/abuild and find out
2023-07-26 08:19:53 <fancsali[m]> <psykose> "open /usr/bin/abuild and find..." <- Fair point... 😉
2023-07-26 14:49:03 <raspbeguy> Hello, I'm trying to package some python lib that uses poetry https://termbin.com/lga2
2023-07-26 14:49:39 <raspbeguy> I stole the actual building and packaging code from other packages
2023-07-26 14:51:56 <raspbeguy> problem is, it creates .dist directory in the package directory : https://termbin.com/n2ba
2023-07-26 14:52:07 <raspbeguy> So I don't know what I'm missing
2023-07-26 14:52:40 <raspbeguy> also, that UNKNOWN-0.0.0 thing
2023-07-27 02:42:30 <psykose> it means your builddir is wrong
2023-07-27 02:42:50 <psykose> so everything runs from the wrong cwd
2023-07-27 02:43:01 <psykose> and outputs nothing
2023-07-27 06:15:50 <raspbeguy> psykose, I already tried to set builddir to $srcdir/$pkgname-$pkgver but same problem
2023-07-27 06:16:03 <psykose> it has to be the actual folder
2023-07-27 06:18:14 <psykose> $srcdir/$pkgname-$pkgver is just the default builddir so specifying the same thing doesn't do anything
2023-07-27 06:18:38 <psykose> and if you see pkgname=py3-bite-parser that means it expands to py3-bite-parser-0.2.2
2023-07-27 06:18:45 <psykose> but if you look in src/ that folder doesn't exist
2023-07-27 06:18:51 <psykose> it's bite-parser-0.2.2
2023-07-27 06:19:42 <psykose> see how i did it and u'll see
2023-07-27 06:25:07 <raspbeguy> oh silly me
2023-07-27 06:27:17 <psykose> the funny part in this project is the typing_extensions for Protocol which was added in python 3.8
2023-07-27 06:27:24 <psykose> but the minimum version is also 3.8
2023-07-27 06:27:26 <psykose> love me useless deps
2023-07-27 06:28:12 <raspbeguy> yeah, I noticed already... I could patch it but I don't think it's worth the maintenance effort
2023-07-27 06:28:30 <psykose> i already did
2023-07-27 06:28:45 <raspbeguy> you did? where ?
2023-07-27 06:29:17 <psykose> in aports
2023-07-27 06:29:44 <raspbeguy> you already pushed the bite-parser package?
2023-07-27 06:31:33 <raspbeguy> allright then, now onto the actual package I wanted to do
2023-07-27 07:26:19 <raspbeguy> Ok, now i'm trying to do this package https://termbin.com/d82o4
2023-07-27 07:27:30 <raspbeguy> I got this https://termbin.com/0j9xw
2023-07-27 07:29:48 <psykose> sure i'll do it
2023-07-27 07:40:32 <psykose> what's the final thing you're working on anyway
2023-07-27 07:57:32 <raspbeguy> psykose, https://github.com/jgosmann/dmarc-metrics-exporter
2023-07-27 08:00:27 <psykose> lol
2023-07-27 08:02:03 <psykose> that's quite the impressive dep tree
2023-07-27 13:37:51 <raspbeguy> hello, me again
2023-07-27 13:38:22 <raspbeguy> this time this is this one https://termbin.com/eoe4
2023-07-27 13:38:40 <raspbeguy> I have this error :
2023-07-27 13:38:42 <raspbeguy> >>> ERROR: py3-more-properties-pyc*: Missing /home/alpine/aports/testing/py3-more-properties/pkg/py3-more-properties-pyc
2023-07-27 13:39:05 <psykose> means the subpackage is empty
2023-07-27 13:39:22 <raspbeguy> yes, but why ?
2023-07-27 13:39:40 <psykose> because there were no .pyc files
2023-07-27 13:40:18 <raspbeguy> on other packages pyc are well created
2023-07-27 13:42:35 <raspbeguy> well I guess something went wrong with the `cd` line
2023-07-27 13:42:53 <psykose> the entire wheel it makes is empty
2023-07-27 13:43:09 <raspbeguy> hum
2023-07-27 13:45:34 <raspbeguy> I don't know how to deal with that
2023-07-27 13:48:48 <psykose> nothing some ingenuity can't fix
2023-07-27 13:49:10 <psykose> done for ya
2023-07-27 13:58:48 <raspbeguy> psykose, problem is I lack of ingenuity for now 🙂
2023-07-27 14:00:39 <raspbeguy> oh you even did dataclasses-serialization
2023-07-27 14:01:06 <raspbeguy> I think you added some unwanted files in your commit though
2023-07-27 14:02:05 <raspbeguy> psykose, https://termbin.com/kfdjv
2023-07-27 14:02:24 <psykose> heh
2023-07-27 14:02:48 <psykose> yeah happens
2023-07-27 14:02:57 <raspbeguy> same in py3-more-properties
2023-07-27 14:03:57 <psykose> wish there was a way to write a half decent ignore rule for that
2023-07-27 14:04:12 <psykose> or well
2023-07-27 14:04:24 <psykose> for abuild to error when cd builddir fails
2023-07-27 19:48:00 <raspbeguy> hi, me again
2023-07-27 19:48:25 <raspbeguy> trying to build the final package at last
2023-07-27 19:49:08 <raspbeguy> https://termbin.com/ps42
2023-07-27 19:49:56 <raspbeguy> at the check step I have some error. It seem to try to open a socket but doesn't manage to.
2023-07-27 19:50:59 <psykose> you didn't paste the output you get
2023-07-27 19:51:04 <psykose> you're also missing half the deps
2023-07-27 19:52:58 <raspbeguy> I decided to add dependancies only when they make the build fail
2023-07-27 19:53:12 <raspbeguy> (and the tests)
2023-07-27 19:54:38 <ikke> some dependencies are only used at runtime
2023-07-27 19:54:51 <psykose> where the output at tho
2023-07-27 19:54:58 <raspbeguy> https://termbin.com/m4yo
2023-07-27 19:55:14 <psykose> did you run that in rootbld
2023-07-27 19:55:34 <raspbeguy> tried rootbld and -r
2023-07-27 19:55:42 <psykose> do you know what self.port is
2023-07-27 19:55:56 <raspbeguy> no
2023-07-27 19:56:13 <psykose> hm not that would be eperm
2023-07-27 19:56:24 <psykose> ah
2023-07-27 19:56:28 <psykose> all of those require a running imap server
2023-07-27 19:56:34 <raspbeguy> oh
2023-07-27 19:56:42 <raspbeguy> that kind of sucks
2023-07-27 19:56:52 <raspbeguy> running on port 8080 ?
2023-07-27 19:57:05 <psykose> --deselect=tests/test_imap_queue.py --deselect=tests/test_imap_client.py --deselect=tests/test_e2e.py::test_successful_processing_of_incoming_queue_message, i guess
2023-07-27 19:57:09 <psykose> yeah they start one for tests
2023-07-27 19:57:42 <psykose> https://github.com/jgosmann/dmarc-metrics-exporter/blob/47ac9452ae0c33c8193430a9c709d4ff0de40d33/.github/workflows/ci.yml#L73
2023-07-27 19:57:56 <psykose> https://github.com/jgosmann/dmarc-metrics-exporter/blob/47ac9452ae0c33c8193430a9c709d4ff0de40d33/compose.yml#L4
2023-07-27 19:58:38 <psykose> if it was something slightly smaller it would be easy to do in shell (you just do &, then || fail=1 and kill %%), but this is contrived af
2023-07-27 19:58:40 <psykose> just skip them
2023-07-27 19:58:41 <psykose> shrug
2023-07-27 19:58:57 <raspbeguy> allright then
2023-07-27 19:59:12 <psykose> deselects i posted should work
2023-07-27 19:59:28 <raspbeguy> running now
2023-07-27 20:00:20 <raspbeguy> https://termbin.com/alhx
2023-07-27 20:00:23 <raspbeguy> still fails
2023-07-27 20:02:32 <psykose> logge
2023-07-27 20:04:15 <raspbeguy> https://termbin.com/deab
2023-07-27 20:06:29 <psykose> well it ignored everything you passed on pytest cli
2023-07-27 20:09:23 <psykose> don't know why
2023-07-27 20:10:02 <psykose> oh
2023-07-27 20:10:17 <psykose> dmarc_metrics_exporter/tests/...
2023-07-27 20:10:24 <psykose> missing prefix
2023-07-27 20:11:39 <raspbeguy> let's try again
2023-07-27 20:12:19 <raspbeguy> way better, thanks
2023-07-27 20:14:23 <raspbeguy> I'm pertty sure the pyproject.toml contains some bullshit deps
2023-07-27 20:17:00 <psykose> generally just `rg import -g \*.py | sort -u` and see what is actually imported tree-wide
2023-07-27 20:17:28 <psykose> that said the uvicorn[standard] thing isn't that simple, e.g. py3-uvloop from it is not actually imported but rather just automatically gets used for the asyncio loop and you definitely want it
2023-07-27 20:19:10 <psykose> if you want `pip check` to be less noisy, also delete the dep line from pyproject.toml for the thing that you don't add since it gets put into metadata and is checked for later
2023-07-27 20:31:19 <raspbeguy> psykose, yeah I already added uvicorn because not having it raised an error on checks
2023-07-28 12:50:45 <fancsali[m]> Hey peeps; I'm in a bit of a pickle, and I thought, I'll pick the collective brain of the community:
2023-07-28 12:50:45 <fancsali[m]> I'm packaging groovy, and it would need several environment vars to be set - `GROOVY_HOME`, `JAVA_HOME`, etc. So, what's the preferred way in the world of Alpine Linux to set those? 
2023-07-28 13:35:41 <ikke> How is it supposed to be run?
2023-07-28 13:39:11 <fancsali[m]> You mean groovy itself? Just like java on the command line; but instead of "java -jar whatever.jar" you'd say "groovy hello_world.groovy".
2023-07-28 16:42:22 <fancsali[m]> Rephrasing the question: when installing java-jre, unless one installs the jdk too, the JAVA_HOME is not set. Shouldn't it be? And if so, where and how?
2023-07-28 16:52:52 <ikke> fancsali[m]: as far as I can see, openjdk17-jdk does not set JAVA_HOME
2023-07-28 16:53:03 <ikke> instead it creates a symlink from /usr/bin/java to the installed jdk
2023-07-28 16:54:53 <fancsali[m]> Indeed, but I am under the impression java still needs the JAVA_HOME either set,  or guessed using javac to find the  built-in library classes and such.
2023-07-28 17:00:14 <ikke> java --list-modules works fine without JAVA_HOME set
2023-07-28 17:17:18 <fancsali[m]> Hm; that seems to be an unavailable command line switch in Java 7 and 8.
2023-07-28 17:19:50 <fancsali[m]> Just to reiterate, I am trying to package groovy, and that both needs  JAVA_HOME and GROOVY_HOME to be set; and I find it's not the best user experience, that after install those both are missing.
2023-07-28 17:34:03 <fancsali[m]> Which lead me to the question of how the system would find the default java and it's libraries; which lead me to the question: "what is the Alpine-way of handling these things".
2023-07-28 17:42:35 <ikke> fancsali[m]: one option is to drop a file in /etc/profile.d/
2023-07-28 17:43:20 <ikke> I think motd is just static files
2023-07-28 17:43:22 <ikke> oops
2023-07-28 17:47:25 <fancsali[m]> Yeah, I thought of /etc/profile.d; the only issue with that, that after install you need to log out and back in again...
2023-07-28 17:47:25 <fancsali[m]> ... not sure, what the community thinks about this.
2023-07-28 17:47:41 <ikke> Ther is no alternative
2023-07-28 17:47:56 <ikke> you cannot install a package and expect environment variables appear automatically for a user
2023-07-28 17:48:12 <fancsali[m]> ikke: Apologies, but how does motd come into the picture here.
2023-07-28 17:48:26 <ikke> fancsali[m]: was meant for #alpine-linux
2023-07-28 17:48:29 <ikke> not this channel
2023-07-28 17:48:59 <fancsali[m]> ikke: Fair point...
2023-07-28 17:48:59 <fancsali[m]> ... unless I do what Arch does, and modify the actual wrapper shell script(s). At least that's how groovy works, /usr/bin/groovy is actually a wrapper.
2023-07-28 17:57:14 <ikke> yeah, that's an option that does no require users to login again
2023-07-28 17:58:15 <fancsali[m]> Yeah, so these are the two options both you guys and I can see; any other ideas?
2023-07-28 19:24:26 <elibrokeit> psykose: someone just posted this https://paste.sr.ht/~tmpod/5553ce3e500336e992ca6bdbd4a99d31d1c0b3e0
2023-07-28 19:24:37 <elibrokeit> apparently python3 on alpine now forbids you from using pip?
2023-07-28 19:25:11 <elibrokeit> this is a badly motivated Python PEP intended to protect users against the ability to use their system, because debian believes their users need that kind of protection
2023-07-28 19:35:44 <PureTryOut> That seems a bit much. You can just pass --break-system-packages along and it'll use the old behaviour. Make it an alias and you won't even notice it's there
2023-07-28 19:50:01 <Newbyte> <elibrokeit> "this is a badly motivated Python..." <- can you explain why you need to be able to break your system?
2023-07-28 19:50:51 <consus[m]> The reporter mentioned the container use cases
2023-07-28 19:51:04 <consus[m]> Where he controls what gets in and out
2023-07-28 19:52:24 <consus[m]> Basically if you have well tested requirements.txt you can skip the virtualenv part
2023-07-28 19:53:21 <consus[m]> However, I'm not sure why, because venv does not prevent someone to do this: /usr/loca/bin/myapp -> /opt/myvenv/bin/app
2023-07-28 19:56:51 <abby> pipenv is good for that
2023-07-28 19:57:09 <Newbyte> or pipx
2023-07-28 19:58:36 <abby> ah that's the one i was thinking of
2023-07-28 22:02:24 <elibrokeit> Newbyte: it will not break the system, for one thing.
2023-07-28 22:03:10 <abby> it can, if you use pip to install something of a different version than a system package
2023-07-28 22:04:13 <elibrokeit> Debian's motivation for preventing Debian users from using their system effectively, was that if you pip install --user foobar, and it's a different foobar from the one installed as root, this can "break" root, but that's phony nonsense because this is why debian already patches shebangs for system software to use /usr/bin/python3.11 instead of /usr/bin/env python3
2023-07-28 22:04:48 <abby> like if you install py3-foo-1.2.3 and then pip install something that needs foo>=2.0 or foo<0.9 or something (which is incompatible with system applications that use py3-foo)
2023-07-28 22:04:52 <elibrokeit> so they can just go add -s too, and ignore the user homedir
2023-07-28 22:06:14 <elibrokeit> it has unusually detrimental effects on musl distributions, because in such cases you very much do strongly want to get some packages from apk -- all of them that are available -- and then augment the rest with pip install 
2023-07-28 22:06:50 <elibrokeit> because compiled C extensions and the lack of wheels on PyPI resulting in users having to add compilers to a container, in the worst case the compiler called "rustc" ;)
2023-07-28 22:09:38 <elibrokeit> again, this has nothing to do with "preventing users from breaking their system" -- people have been trusted to know what they are doing for decades, and the alpine userbase is very different from the debian userbase so you can assume they are capable of wisely using pip and fixing any unlikely problems themselves
2023-07-28 22:14:03 <elibrokeit> Debian isn't even interested in making the system more robust -- the entire design of the PEP and the "externally managed" feature was to tell users "you're not trusted to use this core python functionality, we would rather you don't -- if you want to use it anyway, you have to absolve us of responsibility by passing this scary flag name that says you are opting in to breaking
2023-07-28 22:14:05 <elibrokeit> your operating system"
2023-07-28 22:14:42 <elibrokeit> if Debian -- or the PyPA -- was interested in actually fixing problems, they'd write a PEP to say that Debian is advised to add "-s" to all shebangs for python scripts installed in /usr/bin
2023-07-28 22:27:17 <psykose> fancsali[m]: you make the /usr/bin/groovy a script that sets java home and execs into groovy
2023-07-28 22:27:19 <psykose> nothing more to it
2023-07-28 22:28:07 <psykose> but have you also considered: not packaging groovy? :D
2023-07-28 22:28:09 <psykose> food for thought
2023-07-28 22:34:31 <elibrokeit> psykose: by the way, regardless of anything else -- the current "externally managed" file has a bug in the English prose you used
2023-07-28 22:34:39 <elibrokeit> - The system-wide python installation should be maintained using the system package manager (apk) only.
2023-07-28 22:34:47 <elibrokeit> + The system-wide and user python installations should be maintained using the system package manager (apk) only.
2023-07-28 22:35:27 <elibrokeit> it is left as an exercise to the reader to figure out why you cannot actually maintain the user python installation using apk
2023-07-28 22:36:22 <omni> should we just go for zfs 2.2.99? there's also a 2.2.0-rc3 but if we pick 2.2.99 we don't have to wait for the 2.2.0 release and should also be safe for a couple of years number wise
2023-07-28 22:36:53 <psykose> lol
2023-07-28 22:37:08 <psykose> is it intentionally .99 or did they mean .0
2023-07-28 22:37:29 <psykose> i'll run it through ci anyway
2023-07-28 22:43:54 <psykose> ah, not even a tarball yet
2023-07-28 22:44:01 <psykose> i guess will just wait
2023-07-28 22:48:44 <psykose> ah https://github.com/openzfs/zfs/issues/15112
2023-07-28 22:49:44 <abby> zfs-2.2.9999
2023-07-28 22:51:21 <omni> I don't get it
2023-07-28 22:51:45 <omni> but I saw that there was also a 2.1.99 tag ahead of the 2.1.0 release
2023-07-28 22:54:15 <psykose> yeah it's some rpm meme
2023-07-29 01:12:15 <fancsali[m]> <psykose> "fancsali: you make the /usr/bin..." <- Well, that's what it is, pretty much anyway - /usr/bin/groovy and it's friends are wrapper scripts. So, after doing some research and contemplating I went for pretty much that solution: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49265
2023-07-29 01:13:03 <fancsali[m]> <psykose> "but have you also considered..." <- I have, and quickly discounted the idea - Alpine is awesome, it deserves to be daily-driveable and have everything at your fingertips...
2023-07-29 01:17:18 <psykose> that's not a build template it's just a shittily repackaged precompiled jar
2023-07-29 01:17:42 <psykose> you also made it use default-jdk but then also depend on jre8 which doesn't make sense because if someone installs 11 it will just use 11 instead
2023-07-29 01:28:09 <psykose> for that, java-jre is the dependency or something
2023-07-29 01:46:35 <fancsali[m]> You're actually right – my bad. Will fix it asap...
2023-07-29 01:52:54 <fancsali[m]> <psykose> "you also made it use default-jdk..." <- You're right on that part - I'll fix that mismatch tomorrow; but need to get some sleep now...
2023-07-29 01:55:51 <fancsali[m]> <psykose> "that's not a build template it's..." <- Well, those are the official downloads; and Groovy is meant to be on top of Java anyway. So why recompile it and heat the planet?
2023-07-29 01:55:51 <fancsali[m]> So, what do you find so "shitty" about this approach? Please do share some technical insight? What's the preferred method in Alpine? Do we have a guideline/policy on this?
2023-07-29 01:56:32 <psykose> we generally build things from source
2023-07-29 09:15:13 <nmeum> 9e88698cc296a8492a8f70938c58f5755f39609d
2023-07-29 09:22:57 <consus[m]> Arch, for example, just goes for it and downloads the jar :D
2023-07-29 09:26:13 <consus[m]> Same goes for freebsd
2023-07-29 09:30:49 <consus[m]> Debian and friends use gradle and suffer
2023-07-29 09:30:55 <consus[m]> Same goes for opensuse
2023-07-29 09:37:15 <pj> nmeum: I presume that's unexpected or was there some prior communication
2023-07-29 10:38:31 <lanodan> Meaning that Arch and FreeBSD can't patch groovy and instead are stuck with whatever upstream does and doesn't do.
2023-07-29 10:58:15 <consus[m]> Or maybe they don't need to
2023-07-29 10:58:20 <consus[m]> And everything just works
2023-07-29 12:59:22 <y_> hi all
2023-07-29 13:00:02 <y_> i'm very interested by alpine after use debian derivative etc 
2023-07-29 13:00:37 <y_> ans i propose my help and my contribution for the alpine community 
2023-07-29 13:00:48 <ikke> y_: welcome
2023-07-29 13:02:23 <y_> how can help you ? 
2023-07-29 13:03:01 <ikke> one common way is by contributing a package that you'd like to be present in Alpine but is not yet
2023-07-29 13:03:15 <y_> are you interested by a tutorial french traduction ?
2023-07-29 13:03:49 <ikke> At the moment we don't have anything setup for translation
2023-07-29 13:08:04 <y_> ok but are you interested ? i have a little bit knowledge in C too. 
2023-07-29 13:08:55 <y_> Or for script in sh 
2023-07-29 13:10:02 <ikke> we don't have a list of tasks for you to do. People usually contribute something when they have something to contribute.
2023-07-29 13:10:32 <ikke> You can look at the various issue trackers if you find something that you can help with
2023-07-29 13:10:42 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues
2023-07-29 13:10:49 <y_> thanks
2023-07-29 13:10:57 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/issues
2023-07-29 13:11:09 <ikke> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
2023-07-29 13:11:52 <y_> Alpine is more secure than other distribution no ? The kernel was hardened in the past, i think. 
2023-07-29 13:12:21 <y_> i look that 
2023-07-29 13:12:29 <ikke> The main security improvement is having less things present
2023-07-29 13:12:40 <y_> surface attack
2023-07-29 13:12:43 <ikke> yes
2023-07-29 13:12:43 <y_> yes
2023-07-29 13:13:11 <ikke> There used to be a grsec kernel, but since grsec went closed source, we switched to a standard kernel
2023-07-29 13:13:24 <y_> the better choice between xfce and wayland for security
2023-07-29 13:13:34 <y_> ? 
2023-07-29 13:13:42 <y_> xfce is more small
2023-07-29 13:14:23 <y_> when i install plama, i have 500 package 
2023-07-29 13:14:40 <y_> 230 approximatively with xfce 
2023-07-29 13:15:53 <y_> my english is comprehensive but sorry for grammar fault 
2023-07-29 13:16:16 <ikke> Don't worry, most of us don't speak english natively
2023-07-29 13:16:53 <y_> ok 
2023-07-29 13:19:44 <y_> it is possible to be linked with the site responsable for make a translation in french ?
2023-07-29 13:23:36 <ikke> Like I said before, we don't have anything setup
2023-07-29 13:25:15 <y_> i don't understand, for translation of https://wiki.alpinelinux.org/wiki/Tutorials_and_Howtos in french
2023-07-29 13:38:33 <y_> technical question rust can replace totally the C langage in the future or the C is indispensable
2023-07-29 13:38:35 <y_> ?
2023-07-29 13:42:02 <zcrayfish> Rust will not displace C any time soon. If ever.
2023-07-29 13:42:11 <pj> It's pointless to think about it, both exist and lets end on that. Although it would better to ask such questions in #alpine-offtopic or #alpine-linux
2023-07-29 13:44:40 <y_> thanks the c is indispensable for very low level rust is just complementary 
2023-07-29 13:45:03 <pj> Neither of these statements is true
2023-07-29 13:45:39 <pj> There is more languages than C and Rust in low level programming
2023-07-29 13:45:47 <pj> s/than/than just
2023-07-29 13:48:15 <pj> ikke: sooo... who will be taking over aports maintainership
2023-07-29 13:48:22 <y_> ada too, today continue to learn C is not an heresy as i read in certain publication 
2023-07-29 13:49:16 <ikke> pj: I don't know yet
2023-07-29 13:53:10 <y_> asssembly still has an interest today in learning it?
2023-07-29 13:54:02 <pj> It has it's own place and time for usage
2023-07-29 13:54:32 <Ermine> It is useful to know how to write assembly, but practical appliances are mostly in kernel development
2023-07-29 13:55:28 <y_> it is difficult to write a driver for a a network card ? 
2023-07-29 13:56:00 <Ermine> Yes
2023-07-29 13:56:10 <pj> If you have to ask that question, then yes
2023-07-29 13:56:18 <y_> not for beginner 
2023-07-29 14:00:20 <Ermine> You don't learn how to ride a bike by participating in the Tour de France, right?
2023-07-29 14:03:56 <y_> exactely
2023-07-29 14:08:34 <y_> here you are a professional essentialy ? 
2023-07-29 14:11:54 <ikke> Depends on what you consider professional. Alpine Linux is a community project
2023-07-29 14:13:13 <y_> do you have a litlle project in sh for me ? 
2023-07-29 14:14:05 <y_> i desire contribute to the alpine project 
2023-07-29 14:15:19 <y_> i use linux since many years and alpine is one of my favourite. I search a  simple project for started in your community 
2023-07-29 14:15:49 <y_> sh script translation in french little program in C 
2023-07-29 14:16:18 <y_> i'm not engineer or professional 
2023-07-29 14:25:34 <bl4ckb0ne> why do you want to translate so much
2023-07-29 14:27:44 <y_> not necessary but i purpose the idea. french people is not good in english
2023-07-29 14:28:39 <y_> it's maybe superflu 
2023-07-29 14:29:27 <y_> for a better accessibility to french people 
2023-07-29 14:30:28 <y_> debian fedora and others distribution have french translation 
2023-07-29 14:40:21 <pj> debian, fedora and others also have extremely more contributors and users
2023-07-29 14:41:59 <y_> for open alpine linux for french people 
2023-07-29 14:42:16 <y_> tranlate the wiki 
2023-07-29 14:42:20 <y_> in french 
2023-07-29 14:43:06 <y_> if you interested i do it 
2023-07-29 14:43:27 <ikke> There is quite some outdated information in the wiki, so just blindly translating things is probably not worth it
2023-07-29 14:43:33 <ikke> and sometimes incorrect / bad
2023-07-29 14:43:38 <ikke> (information)
2023-07-29 14:44:13 <ikke> Translating things also required coordinated effort
2023-07-29 14:44:31 <ikke> Otherwise things just get outdated
2023-07-29 14:45:18 <y_> technical question 
2023-07-29 14:45:33 <y_> what is the best choice for desktop
2023-07-29 14:45:40 <ikke> That's not a technical question
2023-07-29 14:45:50 <pj> there isn't best, it's highly subjective
2023-07-29 14:45:55 <y_> wayland or xfce for security 
2023-07-29 14:46:02 <y_> ?
2023-07-29 14:46:07 <y_> globaly
2023-07-29 14:46:28 <y_> because plasma has 500 package 
2023-07-29 14:46:39 <pj> depends on your usage and threat model
2023-07-29 14:46:40 <y_> xfce 200....
2023-07-29 14:47:02 <y_> plasma and gnome work badly 
2023-07-29 14:47:26 <zcrayfish> That's a personal decision.
2023-07-29 14:47:30 <y_> but xfce work fine 
2023-07-29 14:47:49 <y_> i use setup-desktop script 
2023-07-29 14:47:49 <zcrayfish> X11 wasn't designed with security in mind from the beginning, so it suffers
2023-07-29 14:48:18 <ikke> y_: just looking at the amount of dependencies on it's own is not a good measure
2023-07-29 14:49:11 <elly> usually it's best to pick based on which one fits your needs and what you want to do
2023-07-29 14:49:42 <y_> when i install plasma it is impossible to switch tty plasma block 
2023-07-29 14:50:23 <elly> that's configurable generally
2023-07-29 14:51:08 <y_> how many member in your community ? 
2023-07-29 14:51:52 <elly> we don't have a way of counting that, as far as I know
2023-07-29 14:52:17 <pj> it's impossible to keep count of people across many platforms
2023-07-29 14:53:32 <elly> according to `git log --pretty=tformat:%ae | sort | uniq | wc -l` in aports there have been 1535 people who have contributed to aports
2023-07-29 14:53:59 <elly> or at least, 1535 unique email addresses
2023-07-29 14:56:24 <y_> how cani contribute to alpine 
2023-07-29 14:57:07 <pj> I believe ikke already mentioned few ways how to do that
2023-07-29 14:57:18 <y_> aports
2023-07-29 14:57:30 <zcrayfish> you could even contribute to upstream.
2023-07-29 14:57:38 <elly> if you would like you could package stuff in aports, sure
2023-07-29 14:58:09 <y_> yes 
2023-07-29 14:58:14 <y_> good idea 
2023-07-29 14:58:29 <elly> or you can make life easier for other aports maintainers by working with upstreams to make their software behave better on alpine
2023-07-29 15:13:08 <orbea> that also helps other distros when software is improved upstream :)
2023-07-29 15:28:12 <fancsali[m]> <y_> "it is difficult to write a..." <- Been there, done that – it's not easy, but humanly possible. And I learned a lot. In fact, they gave me a degree for it... 😉
2023-07-29 15:29:50 <fancsali[m]>  By the way, documentation makes things accessible to people. So improving the wiki is also a good way tk contribute. 
2023-07-29 16:13:57 <markand> heya
2023-07-29 16:14:16 <markand> since unmaintained/ has gone, what's the proper way to drop maintainership of a package?
2023-07-29 16:14:36 <ikke> Just remove your name as maintainer
2023-07-29 16:16:06 <markand> the line entirely or I keep Maintainer: ... ?
2023-07-29 16:16:22 <ikke> Keep the `# Maintainer:` part
2023-07-29 16:16:56 <markand> thanks
2023-07-29 16:18:05 <markand> there is a bug I think in gitlab, when creating a merge request it always says that the MR does not contain any change
2023-07-29 16:18:08 <markand> you reload and it's gone
2023-07-29 16:19:28 <fluix> Gitlab takes some time to update stuff correctly
2023-07-29 16:20:27 <ikke> markand: known issue with gitlab
2023-07-29 16:21:57 <markand> heh
2023-07-29 16:22:08 <markand> each time we upgrade gitlab at work we get a new problem
2023-07-29 16:22:58 <pj> friends come ang go
2023-07-29 16:23:42 <pj> sometimes a link just doesn't work or sometimes whole upgrade fails
2023-07-29 17:14:04 <agris> test
2023-07-29 17:14:51 <ikke> test failed succesfully
2023-07-29 17:16:11 <pj> error: success
2023-07-29 17:17:26 <minimal> inconclusive - test criteria required
2023-07-29 17:17:51 <agris> thanks
2023-07-30 16:05:46 <bl4ckb0ne> anybody managd to reach out to psykos to on know if she's ok?
2023-07-30 16:06:31 <ikke> We've sent a message, waiting for response
2023-07-30 16:09:11 <pj> She's ok
2023-07-30 16:09:48 <pj> we still shitpost on chimera-linux irc
2023-07-30 16:17:43 <bl4ckb0ne> good to know thanks
2023-07-30 16:21:40 <quinq> If I may ask so, why shitposting on chimera-linux?
2023-07-30 16:22:02 <quinq> Ah no ok, got it :)
2023-07-30 16:37:03 <elly> ok, that is a relief
2023-07-30 16:37:06 <elly> I was a little worried
2023-07-30 16:39:02 <ikke> How do you override a transitive dependency version in rust? It looks like I need to use [patch]?
2023-07-30 16:43:14 <ikke> apparently not: "points to the same source, but patches must point to different sources"
2023-07-30 16:43:27 <pj> ikke: depends how crate is defined and distributed
2023-07-30 16:44:18 <ikke> sequoia-sqv -> sequioa-openpgp -> sha1collisiondetection
2023-07-30 16:44:34 <ikke> https://crates.io/crates/sequoia-openpgp/1.16.0/dependencies
2023-07-30 16:44:58 <ikke> it depends on 0.2.3, it needs to be 0.2.7
2023-07-30 16:45:12 <ikke> but when building sequoia-sqv
2023-07-30 16:46:25 <pj> you should be able to just cargo update it
2023-07-30 16:46:39 <ikke> does that work with transitive dependencies?
2023-07-30 16:47:07 <ikke> sequoia-sqv does not directly depend on it (it's not mentioned in Cargo.lock)
2023-07-30 16:47:24 <pj> You mean Cargo.toml?
2023-07-30 16:47:42 <pj> Cargo.lock has to mention it, otherwise it's not a dep at all
2023-07-30 16:48:07 <ikke> oh, you are right, I couldn't find it before
2023-07-30 16:48:15 <ikke> thanks
2023-07-30 16:48:54 <pj> generally it should work
2023-07-30 16:49:05 <ikke> yeah, it works
2023-07-30 16:49:11 <ikke> cargo update -p sha1collisiondetection
2023-07-30 16:49:16 <pj> yup
2023-07-30 16:50:00 <pj> although sometimes cargo likes to just wreck havoc and update all deps
2023-07-30 16:50:11 <ikke> fun
2023-07-30 16:50:35 <ikke> nice, that fixes sequoia-sqv
2023-07-30 16:58:46 <ikke> pj: thanks
2023-07-30 17:05:44 <pj> \o/
2023-07-30 19:10:50 <ikke> binutils 2.41 released
2023-07-30 19:11:06 <ikke> https://sourceware.org/pipermail/binutils/2023-July/128719.html
2023-07-30 23:30:21 <j_v> was looking through the recently orphaned aports, wondering if anyone was thinking of picking up nawk?
2023-07-30 23:55:17 <fluix> don't have any authority on the matter, but given the volume I would say just make an MR
2023-07-30 23:56:07 <j_v> thanks for input
2023-07-31 05:47:41 <ncopa> morning!
2023-07-31 05:48:53 <ncopa> seems like it has been a somewhat turbulent weekend
2023-07-31 05:49:03 <ncopa> thanks to everyone stepping up!
2023-07-31 06:15:58 <dhruvin> psykose have removed their maintainership from their packages (9e88698cc296a8492a8f70938c58f5755f39609d and later commits). Does anyone know what happened?
2023-07-31 06:16:33 <zcrayfish> dhruvin: At a glance it appears that she quit the project. That's all I know.
2023-07-31 06:18:01 <dhruvin> I hope she is well. I will soon create an MR to assume the maintainership of packages that I use often and are orphaned.
2023-07-31 06:18:28 <zcrayfish> Me too. Thanks for stepping up. 
2023-07-31 06:22:24 <ikke> Thanks. She did not give any details of why.
2023-07-31 06:25:02 <ncopa> dhruvin: I tried to reach out, asking if she is ok. Havent got any response yet.
2023-07-31 06:38:41 <zcrayfish> She had umode +g set on IRC most of the time recently. FWIW.
2023-07-31 06:44:38 <dhruvin> ncopa: If/when you get a response about her well-being, do let us know.
2023-07-31 06:45:47 <dhruvin> Do I just update the Maintainer field and bump pkgrel (like psykose did) to assume maintainership?
2023-07-31 06:45:51 <ikke> Fyi, pj mentioned psykose is still active in other places.
2023-07-31 06:46:00 <ikke> dhruvin: yes
2023-07-31 06:46:04 <dhruvin> thanks
2023-07-31 07:08:03 <pj> ncopa: she's ok in a sense she's still active in other places
2023-07-31 07:20:21 <ncopa> ok. good.
2023-07-31 11:07:24 <ncopa> we now have 84 packages in main that are unmaintained
2023-07-31 11:07:32 <ncopa> $ grep 'Maintainer:\s*$' main/*/APKBUILD | tpaste
2023-07-31 11:07:32 <ncopa> https://tpaste.us/eP7b
2023-07-31 11:08:36 <ncopa> i will take a handful of them
2023-07-31 11:09:54 <artok> damn.. llvm doesn't have one
2023-07-31 11:10:14 <ncopa> i may take llvm unless someone else has interest in those
2023-07-31 11:10:29 <ncopa> we may need move rust back to community
2023-07-31 11:12:19 <pj> I mentioned that in #alpine-linux that I could try to take rust but not llvm
2023-07-31 11:12:32 <ncopa> oh, great
2023-07-31 11:13:02 <ncopa> i grabbed zstd
2023-07-31 11:13:25 <ncopa> pj: do you think 2 year support for rust is realistic?
2023-07-31 11:13:43 <ncopa> that is 4 stable branches in addition to edge
2023-07-31 11:13:46 <pj> eh, would be nice if jirutka was on irc...
2023-07-31 11:14:04 <ncopa> it surely would
2023-07-31 11:14:25 <ncopa> he responds on private message on twitter though
2023-07-31 11:14:38 <pj> I deleted twitter account like 2 weeks ago
2023-07-31 11:14:42 <ncopa> heh
2023-07-31 11:14:51 <ncopa> respect
2023-07-31 11:15:09 <pj> it would probably be possible, but it would be definitely harder for more obscure arches, as I have no idea about ppc/riscv/etc.
2023-07-31 11:15:25 <pj> I'm amd64/aarch64 basic 
2023-07-31 11:15:49 <ncopa> i believe we could give you access to an lxc container for those architectures if needed
2023-07-31 11:18:37 <ikke> Yes
2023-07-31 11:19:04 <pj> Still I'm warning about lack of knowledge about those architectures :P
2023-07-31 11:19:57 <ikke> Nod
2023-07-31 11:20:16 <ikke> What is upstream rust status for those arches?
2023-07-31 11:20:33 <ikke> Don't think all of them are fully supported?
2023-07-31 11:21:25 <pj> ppc definitely is tier 3
2023-07-31 11:22:15 <pj> or rather, everything is tier 3 or worse, with only aarch64/x86_64 being tier 2
2023-07-31 11:22:26 <pj> for *-unknown-linux-musl
2023-07-31 11:23:07 <dhruvin> https://doc.rust-lang.org/nightly/rustc/platform-support.html
2023-07-31 11:23:46 <zcrayfish> I have not read it yet: https://www.phoronix.com/news/Alpine-Linux-Prolific-Packager
2023-07-31 11:24:02 <dhruvin> scratch that link
2023-07-31 11:24:53 <pj> correction: armhf/armv7 and x86 are also tier 2
2023-07-31 11:30:17 <raspbeguy> I claimed maintainership on 4 testing aports in !49327
2023-07-31 11:48:19 <fancsali[m]> Happy to pick up a handful of packages too...
2023-07-31 11:50:43 <Ermine> Can I grab some packages too?
2023-07-31 11:51:30 <ikke> Sure
2023-07-31 11:51:36 <ikke> Make an mr 
2023-07-31 11:51:47 <ikke> First come first serve 
2023-07-31 12:08:34 <ncopa> please do
2023-07-31 12:08:42 <ncopa> highly appreciated
2023-07-31 12:33:04 <Ermine> I mean, from main/
2023-07-31 12:34:07 <ncopa> sure, please do
2023-07-31 12:34:56 <ncopa> packages in main requires a bit more, since we need to do security fixes for those for 4 stable branches
2023-07-31 12:35:02 <ncopa> but we help each other with that
2023-07-31 12:36:55 <ncopa> picking up orphaned packages now is very valuable on many levels
2023-07-31 12:37:04 <ncopa> and highly appreciated
2023-07-31 12:38:12 <Ermine> Ah, that's 2 years, and I will highly likely be conscripted next year...
2023-07-31 12:38:27 <ncopa> as i said, we help each other
2023-07-31 12:38:35 <Ermine> ok
2023-07-31 12:38:39 <Ermine> thank you
2023-07-31 12:38:52 <ncopa> also, many packages dont have many security issues
2023-07-31 12:40:05 <ncopa> thank *you*
2023-07-31 13:05:08 <fluix> how does bootstrapping work for packages like https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/py3-setuptools/APKBUILD
2023-07-31 13:06:00 <fluix> interested in taking on maintainership
2023-07-31 13:07:20 <pj> You can also transfer maintainership if you know you will be unavailable at some point
2023-07-31 13:08:16 <ncopa> fluix: good question. in general we try avoid circular deps if possible
2023-07-31 13:08:32 <ncopa> i found this: ec8e830949fc0daa781ffa52fcd5fbd9aa1b82fe
2023-07-31 13:08:40 <ncopa> and this 22749b4dcfed8a34adf18ac858d93afc497bc6af
2023-07-31 13:09:15 <ncopa> aha, "previous commit" has this: 0ff2967388016e5b131a1b5bbedf36474c9112d6
2023-07-31 13:11:01 <fluix> so should that provides= section be removed?
2023-07-31 13:12:29 <ikke> Provides us for backwards compatibility
2023-07-31 13:12:33 <ikke> Is*
2023-07-31 13:13:12 <fluix> the bootstrap one I mean
2023-07-31 13:13:30 <fluix> oh I guess that one is too? how long are those kept?
2023-07-31 13:14:41 <ikke> As it should only be a makedepend, if there are no references anymore, it should be safe to remove 
2023-07-31 13:15:28 <fluix> otherwise some number of releases?
2023-07-31 13:16:29 <ikke> Yes. For community only until the next stable release, for main until no stable release has it anymore 
2023-07-31 13:16:37 <ikke> No supported release*
2023-07-31 13:16:45 <fluix> makes sense, thanks
2023-07-31 13:28:35 <fluix> ah, beat by Ermine :p
2023-07-31 13:31:04 <Ermine> fluix: I think it will make sense for setuptools and setuptools-stage0 to have one maintainer, so I can leave setuptools to you
2023-07-31 13:31:25 <fluix> there's no more -stage0 though
2023-07-31 13:31:46 <Ermine> ah
2023-07-31 13:32:07 <fluix> and it makes sense for one maintainer on all the base python packaging stuff, so no worries
2023-07-31 13:54:54 <Ermine> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1072565 --- py3-distlib test failed on this assertion: self.assertFalse(self.fileop.is_writable('/etc')) --- do tests run as root?
2023-07-31 13:55:49 <fluix> given the last py- (not py3-) packages are py-gdbm and py-libbytesize in 3.15 community, does it make sense to remove all the provides="py-..." for 3.19?
2023-07-31 13:58:20 <minimal> isn't that so that upgrades are handled correctly?
2023-07-31 13:59:51 <fluix> I believe it's because in the past packages were named py-... that hasn't been the case since 3.15 though, which will be unsupported once 3.19 is released
2023-07-31 14:05:46 <ikke> Yes
2023-07-31 14:06:19 <ikke> Ermine: no nothing is executed as root
2023-07-31 14:06:46 <ikke> Builds are executed as the buildozer user
2023-07-31 14:07:06 <ikke> abuild uses fakeroot for the package phase 
2023-07-31 14:07:55 <Ermine> Hm, why that test reports /etc as writeable
2023-07-31 14:23:54 <ncopa> weird. it also fails when running locally with abuild rootbld, but with other errors
2023-07-31 14:26:29 <ncopa> it passes here locally with options="net"
2023-07-31 14:33:00 <invoked> if you folks get shorthanded, i can help out in august but probably not past that. ping me
2023-07-31 15:20:33 <Ermine> ncopa: this option doesn't help. I think I'll patch this assertion out
2023-07-31 15:26:13 <psykose> ncopa: your assumption on !49329 is wrong- it has nothing to do with the compiler (and fails or passes both ways)- it fails because by default they error on deprecated includes, and with CI set the -DDISABLE_DEPRECATED=OFF is ignored
2023-07-31 15:26:18 <psykose> the actual fix is `unset CI`
2023-07-31 15:26:27 <psykose> (the original reason is it outputs a 50% smaller binary)
2023-07-31 15:41:21 <ikke> How does the CI variable cause those kind of build failures? Are they switching behaviour when it's running in CI?
2023-07-31 15:46:32 <psykose> https://github.com/transmission/transmission/blob/6b0e49bbb296f1c84785275b8a8f18b4210180af/CMakeLists.txt#L219 was just renamed but yea
2023-07-31 17:24:40 <Ermine> Is gitlab mail bridge still broken?
2023-07-31 17:24:53 <ikke> yes, and no expectation for it to be fixed
2023-07-31 17:25:14 <ikke> fyi, there is an e-mail you can send patches to, but you need to have an account for that first
2023-07-31 17:25:57 <ikke> Once signed in, on the MR page at the bottom there is a link that gives instructions how to send patches by e-mail
2023-07-31 17:29:23 <Ermine> okay
2023-07-31 17:35:14 <Ermine> Where is its source?
2023-07-31 17:35:41 <bl4ckb0ne> ohno Ermine already took the wayland packages ownership
2023-07-31 17:35:44 <bl4ckb0ne> 2fast4me
2023-07-31 17:35:54 <ikke> Ermine: That's built-in gitlab functionality
2023-07-31 17:36:00 <Ermine> Ah
2023-07-31 17:36:04 <ikke> Ermine: https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#by-sending-an-email
2023-07-31 17:37:01 <Ermine> bl4ckb0ne: do you want?
2023-07-31 17:37:19 <bl4ckb0ne> nah dont worry
2023-07-31 17:37:29 <bl4ckb0ne> ping me if you want to drop maintainership tho
2023-07-31 17:37:59 <Ermine> Ah ok
2023-07-31 17:38:24 <bl4ckb0ne> took some other
2023-07-31 17:40:00 <bl4ckb0ne> ah i see you already took libxkbcommon
2023-07-31 17:40:52 <Ermine> There's xwayland and some xcb stuff in community/
2023-07-31 17:40:59 <bl4ckb0ne> orphaned?
2023-07-31 17:41:11 <Ermine> yeah
2023-07-31 17:42:49 <ikke> List of unmaintained packages: https://pkgs.alpinelinux.org/packages?name=&branch=edge&repo=&arch=x86_64&maintainer=None
2023-07-31 17:43:08 <ikke> though not normalized per origin
2023-07-31 17:43:34 <bl4ckb0ne> oh i ran the grep command only in main
2023-07-31 17:43:39 <bl4ckb0ne> took a few from community too
2023-07-31 18:49:49 <Forza> Hi.
2023-07-31 18:51:02 <elly> hi!
2023-07-31 18:52:17 <Forza> I am considering to become a maintainer for a package. I am not used to Gitlab stuff, so I am wondering 1) Can I do most of my edits via browser? and 2) In case I want to maintain several packages, how do people normally do with their repos forks. A separate fork per package, or keep it all as one fork with different branches ,etc?
2023-07-31 18:52:32 <elly> for (2) definitely one fork with separate branches
2023-07-31 18:52:40 <elly> for (1)... I probably wouldn't but you could I guess
2023-07-31 18:52:45 <bl4ckb0ne> personal fork of aports + one branch per update
2023-07-31 18:52:52 <bl4ckb0ne> and delete it when its merged
2023-07-31 18:53:05 <Forza> Sounds good. Thanks
2023-07-31 18:53:09 <ikke> Forza: in any case, it's good to do a local build of your changes before you send an MR
2023-07-31 18:53:14 <elly> yes
2023-07-31 18:53:24 <bl4ckb0ne> i dont use the webide but i guess its doable, i dont know how good gitlab's is
2023-07-31 18:53:26 <Forza> ikke: true!
2023-07-31 18:53:34 <ikke> debugging via MR is painful and wastes CI time
2023-07-31 18:53:48 <bl4ckb0ne> yeah it avoids wasting ci time for silly mistakes
2023-07-31 18:54:01 <Forza> I'm a visual kind of person :D But I guess I can manage doing git on command line too if need be.
2023-07-31 18:54:37 <ikke> Forza: maybe look into glab, which is a command line tool which might make it easier to work with gitlab 
2023-07-31 18:54:39 <ikke> from the CLI
2023-07-31 18:55:01 <ncopa> I have never used the browser editor, but I would sort of expect it to be cumbersome for alpine packages
2023-07-31 18:55:08 <ikke> Forza: to be honest, I do most of the merge request merging via the web interface
2023-07-31 18:55:26 <ikke> nowadays they have a built-in vscode editor
2023-07-31 18:55:29 <ncopa> you do? Im shocked :)
2023-07-31 18:55:33 <ikke> :D
2023-07-31 18:56:07 <ncopa> oh. the merging...
2023-07-31 18:56:12 <ikke> yes, merging :P
2023-07-31 18:56:20 <ncopa> that I also do...
2023-07-31 19:00:35 <hjaekel> Hi, can someone do a final review for !44833? All threads are resolved.
2023-07-31 19:01:06 <zcrayfish> I find gitlab to be an incredible PITA compared to microsoft github... but it is doable, and I'll probably get accustomed to it someday :)
2023-07-31 19:01:25 <zcrayfish> I mean in terms of the web interface*
2023-07-31 19:02:20 <Forza> It is definitely harder to use with mobile ui in dark mode :D
2023-07-31 19:03:00 <zcrayfish> haha thanks for that Forza, that's my excuse from now on!
2023-07-31 19:04:57 <ikke> zcrayfish: it's mostly what you're used to
2023-07-31 19:05:00 <ikke> for me it's the opposite
2023-07-31 19:05:09 <ikke> but I use gitlab at work and here for alpine, so I use it more
2023-07-31 19:06:09 <zcrayfish> right :)
2023-07-31 19:10:42 <pj> wouldn't it be better to build lemmy-ui as part of lemmy
2023-07-31 19:11:00 <elly> as one of the rare gerrit users I find both github and gitlab difficult :)
2023-07-31 19:11:16 <ncopa> :D
2023-07-31 19:12:27 <pj> as one of the rare people who do everything everywhere, I'm equally disgusted with every interface but also familiar with them whether that's gitea/github/gitlab/gerrit/cgit/srht
2023-07-31 19:12:53 <pj> also azure devops
2023-07-31 19:15:32 <pj> anyone wants to maintain gcompat? >:)
2023-07-31 19:16:37 <Ermine> would be easier that maintaining llvm wouldn't it
2023-07-31 19:19:13 <ncopa> want gcompat? no. but I'll take it if nobody else takes it
2023-07-31 19:19:35 <pj> imo it should be moved to community
2023-07-31 19:24:17 <Ermine> I have similar concern for py3-meld btw: upstream is archived for a long time and nothing in main/ depends on it
2023-07-31 19:24:46 <ikke> makes sense
2023-07-31 19:28:33 <pj> imo such packages should be remove completely
2023-07-31 19:32:20 <ikke> no requires at all
2023-07-31 19:32:35 <quinq> Gerrit isn't really comparable to github or gitlab
2023-07-31 19:32:39 <quinq> Nor cgit
2023-07-31 19:33:09 <ikke> cgit is just a read-only interface
2023-07-31 19:33:18 <quinq> that :)
2023-07-31 19:33:34 <pj> it's still an interface for git
2023-07-31 19:33:42 <quinq> So is ls
2023-07-31 19:33:58 <quinq> But they provide different features and so fit different use-cases
2023-07-31 19:34:13 <pj> ls is an interface for file system
2023-07-31 19:34:59 <quinq> git is a file-system
2023-07-31 19:35:15 <quinq> But you still get the point, I hope
2023-07-31 19:35:49 <pj> no, I don't
2023-07-31 19:35:59 <quinq> ok, let-me try to explain
2023-07-31 19:36:09 <ikke> pj: but yes, in that case removing it directly makes more sense
2023-07-31 19:36:11 <quinq> cgit is only a git repository display interface
2023-07-31 19:36:32 <quinq> gerrit is both a git-review tool, and a git repository display interface (gitiles)
2023-07-31 19:37:02 <quinq> github/gitab/gitea are both git-review tool, and a git repository display interface, and a CI, and bug tracker
2023-07-31 19:37:07 <quinq> (and other things posibly)
2023-07-31 19:37:31 <quinq> I hope that's clearer now
2023-07-31 19:38:13 <pj> Nope
2023-07-31 19:40:10 <quinq> Sorry, I touched the level 0 of explanation, can't go below :/
2023-07-31 19:40:33 <ikke> ELI5
2023-07-31 19:41:35 <quinq> ELINOPE ;)
2023-07-31 19:41:47 <ikke> :P
2023-07-31 19:43:58 <nangel> For the record.... psykose taking a "walkabout" has just made a bunch of people realize how much work she contributed to the project, and how much garbage she dealt with without complaining.
2023-07-31 19:44:37 <quinq> Well, life is a bitch
2023-07-31 19:44:40 <quinq> And then you die
2023-07-31 19:47:57 <Habbie> nangel, that's always great to realise; would have been better earlier, of course
2023-07-31 19:48:04 <Habbie> but i don't want to venture into speculation about her reasons
2023-07-31 19:48:07 <ikke> Well, some people brought it up earlier
2023-07-31 19:48:15 <Habbie> ikke, oh, no doubt
2023-07-31 19:48:36 <Habbie> btw, does her leaving mean anything for Alpine's governance?
2023-07-31 19:48:37 <pj> there isn't speculation, she already stated the reason and it has been posted on phoronix
2023-07-31 19:48:53 <Habbie> phoronix just had the sleep quote, right?
2023-07-31 19:49:15 <ikke> Habbie: She was part of the TSC, we'll probably be looking for someone to replace her
2023-07-31 19:49:31 <Habbie> ikke, of course. "part of" is good :)
2023-07-31 19:49:56 <zcrayfish> 
ACTION nominates /dev/null, as psykose is irreplacabe.

2023-07-31 19:50:01 <zcrayfish> just being dramatic :p
2023-07-31 19:50:33 <Ermine> So what to do with rust and llvm?
2023-07-31 19:50:56 <pj> Is there something wrong with them?
2023-07-31 19:51:20 <Ermine> like, they need maintenance, no?
2023-07-31 19:51:22 <quinq> A lot of things
2023-07-31 19:51:24 <pj> ikke: btw. was someone chosen for the security position?
2023-07-31 19:51:33 <ikke> pj suggested maintaining rust, ncopa llvm
2023-07-31 19:51:58 <pj> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49349
2023-07-31 19:51:59 <ikke> pj: no, sending an e-mail is somewhere on my todo list
2023-07-31 19:52:30 <Habbie> maintainer change is a pkgrel bump?
2023-07-31 19:52:34 <ikke> yes
2023-07-31 19:52:38 <Habbie> why?
2023-07-31 19:52:40 <ikke> maintainer is part of the apk
2023-07-31 19:52:45 <Habbie> got it
2023-07-31 19:52:48 <Habbie> apk info or show or whatever
2023-07-31 19:52:53 <ikke> yes, and pkgs.a.o
2023-07-31 19:52:57 <Habbie> right, makes sense
2023-07-31 19:53:40 <pj> Such rapid maintainer changes are maybe not the best way to spend compute but it at least verifies that software works when taking over
2023-07-31 19:53:57 <pj> well, "works"
2023-07-31 19:53:58 <ikke> We had to fix some issues yesterday already
2023-07-31 19:54:02 <ikke> build issues
2023-07-31 19:56:18 <jxanthony> Hi, all. I rely on librdkafka and a few other packages marked as having no maintainer for my 9-5 work. I watch for releases of them pretty closely - would it be helpful if I started making MRs for them when upstream has a new release?
2023-07-31 19:56:34 <ikke> jxanthony: absolutely
2023-07-31 19:58:43 <quinq> 9-5, I want that job
2023-07-31 19:59:12 <Habbie> jxanthony, go one further, become the maintainer!
2023-07-31 19:59:30 <Habbie> jxanthony, a bot will email you when the port is outdated
2023-07-31 20:00:22 <ikke> (for packages that are monitored by anitya)
2023-07-31 20:00:24 <Habbie> (not kidding, but only do it if you want to)
2023-07-31 20:00:39 <Habbie> This package has been flagged automatically based on notification from
2023-07-31 20:00:41 <Habbie> Anitya <https://release-monitoring.org/>.
2023-07-31 20:00:43 <zcrayfish> does the bot email the other people (I think the field is called contributor?)?
2023-07-31 20:00:43 <Habbie> right
2023-07-31 20:00:47 <jxanthony> Cool, happy to be involved. I basically read that Phoronix article, looked at the packages - no maintainer. Cloned aports and saw that all of them had last been updated by psykose.
2023-07-31 20:00:55 <elly> how does anitya notify people?
2023-07-31 20:01:08 <ikke> zcrayfish: the contributor field is not actually used by anything
2023-07-31 20:01:08 <Habbie> elly, i'll make a screenshot
2023-07-31 20:01:17 <ikke> elly: pkgs.a.o will send an email
2023-07-31 20:01:20 <zcrayfish> ikke: good to know, thank.
2023-07-31 20:01:35 <Habbie> elly, https://i.imgur.com/Ay9hkOs.png
2023-07-31 20:01:43 <ikke> zcrayfish: so it's mostly an honary mention
2023-07-31 20:01:51 <ikke> honorary*
2023-07-31 20:02:09 <Habbie> when i took over maintainership for a few packages, i got some mixed messaging in here about removing or not removing previous contributors (i had no opinion)
2023-07-31 20:02:14 <Habbie> the final consensus was to leave them in
2023-07-31 20:02:28 <Habbie> but i agree it makes no sense to email them
2023-07-31 20:02:34 <ikke> I never add myself as a contributor
2023-07-31 20:02:50 <pj> it's a pointless waste of line space imo
2023-07-31 20:03:02 <Habbie> i have, in non-alpine situations, regretted not adding myself as contributor in a PR
2023-07-31 20:03:03 <jxanthony> I'd happily be maintainer at least of librdkafka, I use it every day so why not
2023-07-31 20:03:06 <Habbie> for aports, i wouldn't care
2023-07-31 20:03:18 <Habbie> jxanthony, sounds like you're the perfect candidate :)
2023-07-31 20:03:18 <zcrayfish> Heck I didn't even know about that field until psykose removed herself as contributor from a few packages I was watching.
2023-07-31 20:03:31 <Habbie> zcrayfish, she removed herself as contributor? or maintainer?
2023-07-31 20:03:33 <pj> There was also some rule about maintainer also having contributor comment
2023-07-31 20:03:38 <zcrayfish> Habbie: both.
2023-07-31 20:03:56 <Habbie> pj, hmm, my ports don't have that (and i don't care), why that rule?
2023-07-31 20:04:03 <elly> jxanthony: ah, useful!
2023-07-31 20:04:07 <elly> I wonder how it tracks chromium updates
2023-07-31 20:04:22 <pj> it was long time ago and might be not true anymore
2023-07-31 20:04:22 <Habbie> https://release-monitoring.org/project/12573/ it does track librdkafka
2023-07-31 20:04:30 <Habbie> pj, right
2023-07-31 20:04:34 <Habbie> https://release-monitoring.org/projects/search/?pattern=chromium
2023-07-31 20:04:34 <ikke> it was added to https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md#contributor-comment
2023-07-31 20:04:50 <Habbie> ikke, ah
2023-07-31 20:04:53 <pj> ever since psykose was doing majority of merging and reviewing MRs, it could have laxed a bit
2023-07-31 20:04:53 <Habbie> ikke, no linting for that it seems
2023-07-31 20:04:58 <ikke> indeed
2023-07-31 20:05:38 <ikke> I personally think we should remove that part from the coding style
2023-07-31 20:05:44 <pj> Same
2023-07-31 20:05:52 <pj> If we don't actually use it, what's the point
2023-07-31 20:06:06 <jxanthony> So what's the process? You guys want me to make an MR making myself the maintainer? I already get notified on the repo getting a new release tag.
2023-07-31 20:06:09 <zcrayfish> just make it optional?
2023-07-31 20:06:37 <elly> jxanthony: yeah, make an MR
2023-07-31 20:06:37 <pj> jxanthony: you can do that if you want
2023-07-31 20:06:42 <elly> that way people can email you if it breaks :)
2023-07-31 20:09:42 <bl4ckb0ne> thanks for the bump fluix 
2023-07-31 20:09:47 <fluix> nw :)
2023-07-31 20:09:54 <bl4ckb0ne> whats all that stuff in the overview tho
2023-07-31 20:10:01 <fluix> refresh
2023-07-31 20:10:03 <fluix> glab cli is bad
2023-07-31 20:12:09 <pj> build time limit, who could have thought
2023-07-31 20:14:21 <ikke> most of these packages have just been builtk
2023-07-31 20:14:36 <ikke> I don't think much has changed in the last 48 hours
2023-07-31 20:15:12 <pj> you can merge MR if you think it's fine :)
2023-07-31 20:15:25 <ikke> done
2023-07-31 20:16:13 <pj> Probably could have been a good little maintainer and make a commit for each package, but who has time for that
2023-07-31 20:18:44 <fluix> how do people here keep track of package updates? rss feeds?
2023-07-31 20:19:16 <ikke> subscribing to github releases
2023-07-31 20:19:20 <ikke> repology
2023-07-31 20:19:21 <bl4ckb0ne> i sub to the release on github, otherwise i wait for the bot mail
2023-07-31 20:19:22 <ikke> anitya
2023-07-31 20:19:25 <Habbie> emails from Anitya
2023-07-31 20:19:35 <Habbie> although for all things that Anitya emails me about, i already know ;)
2023-07-31 20:19:38 <pj> I'm following way too many releases on github
2023-07-31 20:21:21 <fluix> ooh anitya looks cool, thanks for the tips 
2023-07-31 21:03:29 <ovf> always wanted to ask why people here seem to like release-monitoring.org, while it looks to me that repology.org is way more comprehensive
2023-07-31 21:04:50 <Forza> OK. I am a total noobie :D "abuild checksum" gives "APKBUILD: line 2: syntax error: unexpected newline" .. I used nano to edit the file.
2023-07-31 21:05:05 <ptrc> ovf: release-monitoring provides a nice api
2023-07-31 21:05:25 <Habbie> Forza, can you pastebin the output of 'git diff'?
2023-07-31 21:05:29 <ptrc> and repology is kinda biased against alpine at times 
2023-07-31 21:11:18 <ovf> ptrc: out of curiosity, what's the bias?
2023-07-31 21:11:35 <Forza> Habbie: https://gist.tnonline.net/7U
2023-07-31 21:12:36 <pj> Forza: you removed #
2023-07-31 21:12:42 <Forza> ohhh
2023-07-31 21:12:43 <Forza> :D
2023-07-31 21:12:58 <pj> Maintainer and Contributor are comments
2023-07-31 21:14:26 <Forza> :) Thanks
2023-07-31 21:14:46 <Habbie> :)
2023-07-31 21:15:18 <ovf> ...and the whole APKBUILD is a shell script expected to define, upon evaluation, certain variables and functions
2023-07-31 21:18:53 <Forza> OK So I am ready to try (on my own fork) to commit a change to become maintainer. I read on https://gitlab.alpinelinux.org/forza/aports/-/blob/master/COMMITSTYLE.md that there are templates. Should I use a template for the commit message?
2023-07-31 21:19:04 <pj> yes
2023-07-31 21:19:14 <Forza> Like this "$repository/$pkgname: take maintainership"
2023-07-31 21:19:26 <pj> yes
2023-07-31 21:20:05 <Forza> literal words $repository etc, or should I transcribe it as "testing/scsi-tgt: take maintainership" ?
2023-07-31 21:20:22 <Habbie> yes
2023-07-31 21:20:26 <Habbie> do that
2023-07-31 21:20:36 <Forza> The transcribed one?
2023-07-31 21:20:40 <pj> you can look at commit history in aports
2023-07-31 21:21:10 <pj> those are not variables, they won't be automatically resolved to final values
2023-07-31 21:21:19 <Forza> I did, but didn't understand if the $xxx names would magically become the correct message
2023-07-31 21:21:23 <pj> You have to manually type out repo and pkgname
2023-07-31 21:22:13 <Forza> like such? git commit -m "testing/scsi-tgt: take maintainership"
2023-07-31 21:22:30 <pj> yes
2023-07-31 22:02:10 <minimal> jxanthony: are you running Kafka itself on Alpine?
2023-07-31 22:18:10 <Forza> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/49368 My first attempt to a MR.. probably borked it :D
2023-07-31 22:35:10 <jxanthony> minimal: Generally not, all hosted (and largely not managed by me). The reason I touch librdkafka so much is that I'm on the dev side, writing lots of microservices that use it as a message bus.
2023-07-31 22:35:15 <jxanthony> Why do you ask?
2023-07-31 22:38:09 <minimal> jxanthony: wondering about kafka performance if you did have it on Alpine (plus whether this was using the new-ish non-zookeeper method)
2023-07-31 22:41:03 <jxanthony> I did notice there's no kafka package in aports; not sure if that's for _reasons_ or if there's just been no love for it. It's hefty but simple dependencies I think.
2023-07-31 22:46:11 <elly> I wonder if it works with musl or not
2023-07-31 22:48:05 <minimal> its Java, so in theory yes
2023-07-31 22:52:40 <jxanthony> Just did a quick test. Bash + openjdk17-jre and it's working