2023-09-01 05:36:42 <PureTryOut> ptrc: merged
2023-09-01 08:30:46 <ikke> PabloCorreaGomez[m]: Hmm, I get a feelings it's now possible to assign MRs to a group. I havent tested it yet, but if I do /assign @ then the popup shows groups that I can assign
2023-09-01 08:53:44 <PureTryOut> That'd be great!
2023-09-01 08:53:51 <PureTryOut> Btw team/alpine-desktop is still not pinged by the bot
2023-09-01 08:54:03 <ikke> That one wasn't added, only kde
2023-09-01 08:54:19 <ikke> oh, my bad, it was
2023-09-01 08:55:32 <ikke> PureTryOut: what issue should've been assigned to that team?
2023-09-01 08:56:38 <PureTryOut> No issue, but MR's to community/pipewire for example
2023-09-01 08:56:48 <ikke> sorry, I meant MR
2023-09-01 08:58:10 <ikke> PureTryOut: there was an issue when deploying a new version of the bot, so it waas inactive for a while
2023-09-01 08:58:22 <PureTryOut> Ah that's probably it then
2023-09-01 08:59:00 <ikke> oh, and there not existing a gitlab group for it doesn't help either
2023-09-01 08:59:08 <ikke> hmm
2023-09-01 08:59:31 <ikke> ugh, nm, ignore me
2023-09-01 09:00:23 <ikke> I can assign certain groups, but not others
2023-09-01 09:01:52 <ikke> Ok, apparently it's just a UI glitch. It provides some teams as an option, but the command will fail
2023-09-01 09:06:45 <PureTryOut> Strange 🤔
2023-09-01 13:30:11 <ikke> going to upgrade gitlab and host OS, it will be unavailable for a bit
2023-09-01 13:40:46 <ikke> gitlab is available again
2023-09-01 13:42:09 <ncopa> awesome
2023-09-01 13:42:28 <ncopa> thanks for the great job you do!
2023-09-01 13:43:19 <ikke> Appreciate it. Funnily enough, all in all it's not even that much work to keep it up-to-date :-)
2023-09-01 14:34:51 <ncopa> i tagged a new edge release snapshot
2023-09-01 14:36:35 <ikke> cool
2023-09-01 14:37:04 <ikke> clandmeter: seems the pipeline triggered as well
2023-09-01 14:37:07 <ikke> https://gitlab.alpinelinux.org/clandmeter/alpine-disk-image/-/pipelines/177799
2023-09-01 14:38:41 <clandmeter> Nice thx
2023-09-01 15:25:53 <PabloCorreaGomez[m]> ikke: so false positive on assigning MRs to groups?
2023-09-01 15:27:07 <PabloCorreaGomez[m]> I've done some work already on the QA bot. And started working in the option to do actions on comments. But that needs a bit more of refactoring
2023-09-01 15:28:30 <ikke> PabloCorreaGomez[m]: I think so, yes
2023-09-01 15:28:49 <PabloCorreaGomez[m]> That refactoring might even benefit pmOS too. We right now have to keep a couple of package in-sync with aports. And we do that manually, but there are some plans to automate it, and reusing part of the aports-qa-bot would be amazing
2023-09-01 15:30:13 <PabloCorreaGomez[m]> And if that thought becomes real, might be pretty cool if we could get some webhook that directly notifies us too. Probably better for everbody than us doing polling :)
2023-09-01 15:32:59 <ikke> You could already subscribe to mqtt 
2023-09-01 15:35:34 <PabloCorreaGomez[m]> Uh, I guess I have no idea about that. So will have to look into it then :)
2023-09-02 08:03:40 <pj> ikke: i added a bit more context to why I pushed 3.18 first for rust-analyzer :>
2023-09-02 09:58:35 <PureTryOut> Uh, apk refuses to remove a package for seemingly no reason 🤔
2023-09-02 09:58:39 <PureTryOut> / # apk del qt5-qtbase
2023-09-02 09:58:39 <PureTryOut> World updated, but the following packages are not removed due to:
2023-09-02 09:58:39 <PureTryOut>   qt5-qtbase:
2023-09-02 09:58:45 <PureTryOut>  * ```... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/jcEEFDVdLjkeHRphiZdweLWg>)
2023-09-02 10:06:18 <ikke> PureTryOut: sadly, matrix.org links are useless
2023-09-02 10:06:52 <ikke> (they force download, instead of showing in browser)
2023-09-02 10:07:22 <PureTryOut> Well that doesn't make them useless, but less useful 😉
2023-09-02 10:07:42 <ikke> practically useless 
2023-09-02 10:07:53 <PureTryOut> Anyways it's apk reporting that it won't remove qt5-qtbase due to... nothing
2023-09-02 10:08:08 <ikke> Is there an install_if that is pulling it in?
2023-09-02 10:08:11 <PureTryOut> (working through some wrong dependency chains)
2023-09-02 10:08:11 <ikke> somewhere
2023-09-02 10:08:12 <PureTryOut> no
2023-09-02 10:09:27 <PureTryOut> it's not much of a problem, as I said the dependency chain is incorrect anyway and I'm figuring out why it's installed in the first place to properly get rid of it in this chroot
2023-09-02 10:09:35 <PureTryOut> it's just a weird message 😅
2023-09-02 13:59:40 <PureTryOut> How do you easily see by which package a file on the file system is owned?
2023-09-02 14:02:00 <ikke> apk info -W /path/to/file
2023-09-02 14:02:09 <ikke> (--who-owns)
2023-09-02 14:16:45 <PureTryOut> Awesome, thanks!
2023-09-02 15:06:01 <PureTryOut> So I have a package that has a -libs that's just default_libs. The lib file itself is properly split out but there is also a symlink from the same directory but different file name to it that isn't split out. Is that expected?
2023-09-02 15:15:27 <lnl> I think these typically get split out to -dev?
2023-09-02 15:22:44 <PureTryOut> This particular one shouldn't, and it isn't either
2023-09-02 15:23:48 <ikke> default_libs only moves lib*.so.[0-9]*
2023-09-02 15:23:59 <PureTryOut> Yeah but afaik that should include this file
2023-09-02 15:24:18 <ikke> it skips regular files
2023-09-02 15:24:26 <PureTryOut> the original file is libKF6Solid.so.5.240.0 and the symlink is libKF6Solid.so.6
2023-09-02 15:24:32 <ikke> but you say it's a symlink?
2023-09-02 15:24:35 <PureTryOut> yes
2023-09-02 15:25:04 <PureTryOut> I guess I should overwrite the libs function and move it manually?
2023-09-02 15:27:20 <ikke> I'd try to find out why it is not moved by the default function first
2023-09-02 15:29:39 <PureTryOut> well yeah but that's the problem lol, I'm not sure why. the mv command is simple enough and it should be matched https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2114 as far as I can see
2023-09-02 15:30:04 <PureTryOut> Oh I guess line 2115?
2023-09-02 15:30:09 <PureTryOut> 
ACTION looks up what the -f means again

2023-09-02 15:30:32 <ikke> iirc, regular file
2023-09-02 15:30:43 <PureTryOut> so making sure it's not a symlink then
2023-09-02 15:31:00 <ikke> Oh, yes
2023-09-02 15:31:02 <ikke> || continue
2023-09-02 15:31:07 <PureTryOut> there you go
2023-09-02 15:31:08 <ikke> I read it as && continue
2023-09-02 15:31:14 <PureTryOut> Ok I'll just overwrite it in this package then
2023-09-02 15:31:44 <ikke> normally the symlinks go in the dev package, like lnl mentioned
2023-09-02 15:31:57 <PureTryOut> yeah makes sense for most cases, but not this particular one 😛
2023-09-02 15:32:13 <ikke> fyi, you can still call default_libs and manually move the remaining file
2023-09-02 15:32:18 <ikke> (I assume you were aware of that)
2023-09-02 15:32:58 <PureTryOut> I was yes, but thanks 😉
2023-09-03 12:56:31 <MHickford[m]1> Hello. Does this merge request to install a man page look correct? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50977/diffs
2023-09-03 12:59:15 <ikke> The file you try to install doesn't appear to exist. And you also need a `$pkgname-doc` subpackage
2023-09-03 13:06:13 <MHickford[m]1> Thanks, amended.
2023-09-03 13:09:13 <ikke> merged :)
2023-09-03 13:29:19 <MHickford[m]1> Thanks. Here's a similar merge request for a sister package https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50978
2023-09-03 13:31:47 <ikke> merged ;-)
2023-09-03 13:32:00 <MHickford[m]1> Thanks again
2023-09-03 14:17:19 <RootWyrm> aaaaaargh, why the bloody hell would linux-lts continually not produce the goddamn package?
2023-09-03 14:23:41 <ikke> step 1: breath in
2023-09-03 14:23:43 <ikke> step 2:
2023-09-03 14:23:45 <ikke> breath out
2023-09-03 14:23:48 <ikke> step 3: repeat
2023-09-03 14:24:03 <ikke> RootWyrm: now, what's the matter?
2023-09-03 14:26:03 <RootWyrm> Beats the fuck out of me. abuild -r produces a whole lot of heat and no result.
2023-09-03 14:26:27 <ikke> RootWyrm: for the recrod, where are you looking for the package?
2023-09-03 14:29:36 <RootWyrm> ikke: exactly where it should be; $HOME/packages/*
2023-09-03 14:29:49 <ikke> RootWyrm: just wanted to make sure
2023-09-03 14:30:10 <ikke> What is the tail of the output?
2023-09-03 14:33:51 <RootWyrm> zero abnormal, I know that. already lost it. so now I have to wait another 6 fucking hours.
2023-09-03 14:34:32 <ikke> safe the log output ;)
2023-09-03 14:34:37 <ikke> save*
2023-09-03 14:49:07 <RootWyrm> uh, since when did any `auto n` static interface also instantiate a default route?
2023-09-03 14:54:49 <ikke> That does not make a lot of sense to me
2023-09-03 14:55:05 <ikke> as far as I know the only thing that auto <name> does is to bring the interface up
2023-09-03 14:55:29 <RootWyrm> if a gateway is present, it's adding a default route, resulting in double defaults.
2023-09-03 14:56:06 <ikke> a gateway implies a default route
2023-09-03 14:57:42 <RootWyrm> it really doesn't. but I've given up on basic networking since near 30 years on people still insist either it doesn't happen or sending replies out the wrong interface is ok.
2023-09-03 14:59:38 <ikke> what do you expect to happen when you specify a gateway?
2023-09-03 15:00:51 <dalias> a gateway has an associated set of masks it's for
2023-09-03 15:01:01 <dalias> if none is specified, "all" is a reasonable default
2023-09-03 15:02:51 <RootWyrm> except a mask is specified, and still it adds a default. <shrug> i'll just do it by hand, got enough other migraines.
2023-09-03 16:22:58 <RootWyrm> If anyone wants to grab some quick low-hanging fruit, !50982
2023-09-03 17:18:41 <skarnet> pid files strike again
2023-09-03 17:19:20 <Reinhilde> thanks for the commentary
2023-09-03 20:10:52 <pj> !50972 merge pls? :-)
2023-09-03 20:30:28 <ikke> pj: do we want to (test) rebuild packages using rust afterwards?
2023-09-03 20:30:41 <pj> yes
2023-09-03 20:30:59 <pj> should I do that together with rust bump?
2023-09-03 20:31:54 <ikke> For these statically compiled languages we typically do that separate
2023-09-03 20:32:00 <pj> i mean, I would like to rebuild after each upgrade, not sure if you are asking about any specific changes
2023-09-03 20:32:17 <ikke> No, not asking for any changes
2023-09-03 20:32:30 <pj> I thought so, as I recall it was usually a separate MR
2023-09-03 20:32:53 <ikke> Just wanted to make sure that it was going to happen
2023-09-03 20:33:12 <pj> (y)
2023-09-03 20:33:52 <pj> just need to do it on alpine machine or somehow get abuild tools working on ubuntu
2023-09-03 20:44:20 <pj> I guess I can upgrade it on stable branches as well? At least for 3.18
2023-09-03 20:45:12 <ikke> pyskose planned to keep all releases up-to-date
2023-09-03 20:45:51 <pj> yeah, but it was planned for after 3.18 and for main
2023-09-03 20:45:58 <ikke> indeed
2023-09-03 20:46:05 <pj> 3.18 is still community, which I will do but 3.17 hasn't been touched in logn time
2023-09-03 20:46:18 <pj> so I'm kind of skeptical to start doing it now for older
2023-09-03 20:46:27 <ikke> yeah, you are right, doesn't make sense now
2023-09-03 20:46:52 <pj> and those are EOL according to community spec so.. I guess it's fine
2023-09-03 20:47:26 <ikke> pj: I can  provide you a x86_64 dev container
2023-09-03 20:47:28 <ikke> (lxc)
2023-09-03 20:47:49 <ikke> if you like
2023-09-03 20:48:13 <pj> I have x86_64 powerful machine, although it uses Ubuntu I'm doing just fine with docker-abuild
2023-09-03 20:48:25 <pj> other arches are more than welcome though
2023-09-03 20:49:05 <pj> but I can try to manage fine with just docker-abuild, it worked nicely for riscv64 today
2023-09-03 20:49:21 <pj> I won't comment on s390x
2023-09-03 20:50:15 <pj> I just have to do ap revdep stuff on alpine
2023-09-03 20:50:30 <pj> which I can do on my little NAS box
2023-09-03 20:55:59 <pj> was/is there command to bump pkgrel +1?
2023-09-03 20:56:30 <ikke> apkgrel -a
2023-09-03 20:57:33 <ikke> takes one or more package names
2023-09-03 21:05:14 <pj> i love that ap returns subcommands in different order with every invocation
2023-09-03 21:31:40 <ikke> It returns it in order that it gets them from the filesystem
2023-09-03 21:45:06 <pj> grrr, things listing cargo and rust as makedeps
2023-09-03 21:45:19 <pj> can I remove that when rebuilding?
2023-09-03 21:46:05 <dalias> lol
2023-09-03 21:47:03 <ikke> pj: I assume it should only list either one of them?
2023-09-03 21:47:20 <pj> it should list only cargo because cargo pulls rust
2023-09-03 21:47:47 <ikke> right
2023-09-03 21:47:49 <ikke> fine with me
2023-09-03 21:48:56 <pj> I think cargo-auditable should also depend on cargo
2023-09-03 21:49:42 <pj> then the only thing that should be pulled would be cargo-auditable (although I'm unsure if that would like fine in build manifest)
2023-09-04 00:27:51 <omni> shouldn't glibmm (currently at 2.66.6) be the aport being bumped and the one that needs to stay be named glibmm2.66, currently there is a glibmm2.68 at version 2.76.0 and there's an MR for it to bump it to 2.77.0 and this seems a bit confusing to me
2023-09-04 07:19:59 <ptrc> omni: they're named by the soname
2023-09-04 07:20:40 <ptrc> $ apk info --provides glibmm2.68
2023-09-04 07:20:42 <ptrc> glibmm2.68-2.76.0-r0 provides:
2023-09-04 07:20:44 <ptrc> so:libglibmm-2.68.so.1=1.3.0
2023-09-04 08:01:55 <omni> oh..
2023-09-04 12:09:28 <omni> license files, if packaged, should go in the -doc sub-package right?
2023-09-04 12:11:52 <omni> also have vague memory of someone saying that we don't need to since it's mentioned in license= in the APKBUILD, at least if it's in the SPDX License list
2023-09-04 12:12:57 <omni> if someone could clarify, so I'd know what to comment in, for example, !51014
2023-09-04 12:47:35 <quinq> I installed the “outils” package, but it's empty
2023-09-04 12:47:47 <quinq> ("apk info -L outils" returns nothing)
2023-09-04 12:47:51 <quinq> Is that a broken package?
2023-09-04 12:59:59 <ptrc> quinq: the main package is empty, but it has 18 subpackages: https://pkgs.alpinelinux.org/package/edge/community/x86_64/outils
2023-09-04 13:04:34 <omni> wouldn't it make sense for such empty packages to be meta packages that install the sub-packages?
2023-09-04 13:04:40 <omni> assuming outils isn't the only one
2023-09-04 13:12:02 <quinq> oh
2023-09-04 13:12:19 <quinq> Erf indeed, I'd expect to have all sub-packages installed when installing the main package
2023-09-04 13:34:13 <EvTheFuture> Is this MR ok regarding doing two things in one MR, but I wanted to fix the config dir at the same time the version was upgraded so I bundled the commits into one MR. !51020
2023-09-04 13:53:20 <ikke> omni: MIT style licenses have a copyright notice  
2023-09-04 14:05:55 <ikke> So it's not sufficient to just say it's MIT, you have to include the actual notice 
2023-09-04 14:06:25 <omni> and not just in the -doc package?
2023-09-04 14:08:44 <omni> EvTheFuture: it is, and I think things like this could also go into the same commit if you describe below the first line in the commit message the additional changes
2023-09-04 14:10:23 <omni> I merged it, but should probably have suggested using lowercase in the commit messages and removing "version" so that the first message had been "community/go2rtc: upgrade to 1.7.0"
2023-09-04 14:10:33 <omni> but too late for that now!
2023-09-04 14:12:15 <omni> ikke: I'm generally quite ignorant wrt to licenses but want to be correct in our repos, of course
2023-09-04 14:38:01 <EvTheFuture> omni: thanks
2023-09-04 14:40:37 <ikke> omni: we have always put those in the -doc subpackage 
2023-09-04 17:27:09 <RootWyrm> Well, I now have the aml-s905x-cc getting to second stage failure. So what's the preferred method for kernel option MRs? Do 3.18-stable and edge separate?
2023-09-04 17:27:48 <ikke> yes, and updates to the kernel would also involve bumping the dependent modules
2023-09-04 17:29:07 <RootWyrm> ikke: which modules need bumped?
2023-09-04 17:30:44 <ikke> https://tpaste.us/a1rq
2023-09-04 17:32:12 <ikke> and it's the _krel variable that would need to be bumped
2023-09-04 17:32:53 <RootWyrm> ikke: OK, will add them to the list. is there any specific order enforced on the lts.*.configs or would tacking it at the bottom be OK?
2023-09-04 17:33:05 <ikke> I'm not entirely sure myself
2023-09-04 17:33:58 <RootWyrm> Yeah, it's not clear to me either. I'd like to tack them at the end with a comment so nobody accidentally pulls them out (they're all req'd for AMLogic S905s to not panic) but that looks like it'd be way out of line with norm.
2023-09-04 17:34:15 <ikke> It is generated some way
2023-09-04 17:35:58 <RootWyrm> It looks like a manual run of make menuconfig to me, but could be wrong there. <.<
2023-09-04 17:36:17 <ikke> It's not the complete config though, just the differences
2023-09-04 18:07:54 <omni> is jupyter-server blocking other packages to be built for x86 & x86_64?
2023-09-04 18:08:12 <omni> #15238
2023-09-04 19:15:21 <ikke> omni: it is for community and testing
2023-09-04 19:15:26 <ikke> at least, to upload packages
2023-09-04 19:28:43 <omni> ok, noticed that no new texlive is available for those archs
2023-09-04 19:30:09 <ikke> the builders will only upload a repository once all packages finished building
2023-09-04 19:32:15 <omni> so, should we just disable the tests then?
2023-09-04 19:32:48 <omni> I didn't see them failing on the CI builders (but maybe I missed something in the logs) so I merged
2023-09-04 19:33:07 <ikke> Only those specific tests preferrably.
2023-09-04 19:33:34 <ikke> But it can indicate something is broken
2023-09-04 19:33:55 <ikke> The tor test suite uncovered a bug in musl that was only triggered on the builders
2023-09-04 19:33:56 <omni> yeah, that's why I opened the issue instead
2023-09-04 19:34:13 <omni> and I was too tired to look further into it
2023-09-04 19:34:46 <ikke> yeah, I can imagine, it can take a lot of time / effort to get into the bottom of these kinds of failures
2023-09-04 19:35:56 <ikke> But I don't feel like digging in either atm
2023-09-04 20:01:54 <omni> !51048
2023-09-04 20:03:14 <omni> do I also need to bump pkgrel or will it trigger on x86 & x86_64 builders anyway (as that pkgver-pkgrel does not exist for those archs yet) when merged?
2023-09-04 20:06:33 <ikke> correct, no pkgrel bump needed
2023-09-04 20:07:01 <ikke> the builders will keep retrying to build the packages
2023-09-04 20:45:28 <RootWyrm> ikke: yeah, that's typical of menuconfig as well.. though I'm starting to suspect something else is missing since second stage isn't working. :/
2023-09-04 23:20:27 <omni> in !50943 they put some test inside package(), could someone have a look and come with a proper suggestion?
2023-09-05 08:28:47 <omni> improvements have been made, possibly fine now
2023-09-05 12:14:21 <indy> ncopa, hi 3.18 and edge mariadb breaks functionality
2023-09-05 12:28:30 <ikke> indy: how
2023-09-05 12:32:46 <indy> ikke, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51089
2023-09-05 12:33:14 <indy> ncopa, ikke partitioning plugin was disabled as YES was causing cmake error
2023-09-05 12:41:44 <indy> ikke, ncopa we use partitioning for quasi auto-maintenance
2023-09-05 12:47:47 <indy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51092
2023-09-05 12:55:36 <indy> ncopa, ikke hmm, for 3.18 from 10.11 lts .4 is not available, only .5 and .6
2023-09-05 12:59:01 <indy> is fine to cherry-pick commits in main/mariadb to 3.18 branch?
2023-09-05 14:12:12 <ncopa> hi
2023-09-05 14:12:33 <ncopa> yes, cherry-pick commits to 3.18-stable is ok
2023-09-05 14:37:10 <bl4ckb0ne> is there a way to get more log from abuild when failing to apply a patch?
2023-09-05 14:37:27 <bl4ckb0ne> other than doing it myself manually
2023-09-05 14:42:08 <ikke> Add patch_args="-p1 --verbose" perhaps
2023-09-05 14:42:38 <bl4ckb0ne> might help if one patch in the middle of the serie is properly applied
2023-09-05 14:45:58 <bl4ckb0ne> forgot a ".patch"
2023-09-05 14:52:05 <ikke> Ah
2023-09-05 14:53:06 <ikke> I thought you meant that the patch failed to apply, instead of abuild failing to apply the patch 🙂
2023-09-05 14:57:16 <Tach> Hi guys, is anyone able to help me out how to create a seperate clamav-freshclam package instead of all in one ?
2023-09-05 15:00:47 <bl4ckb0ne> the 3rd patch of the serie failed to apply, but because the 2nd one was not applied
2023-09-05 15:06:37 <bl4ckb0ne> PureTryOut: you want the khronos 1.3.261.1 bump or we wait for the next sdk
2023-09-05 15:07:48 <PureTryOut> Depends on how critical the change is that warranted a .1. But I don't tend to update for every release anyway, they release quite often and can break ABI with patch releases
2023-09-05 15:08:05 <bl4ckb0ne> yeah, i'd follow the sdk tags and not bother with it
2023-09-05 19:30:07 <ikke> The opentf repository is public: https://github.com/opentffoundation/opentf
2023-09-05 20:05:03 <omni> did the aarch64 CI builder have something hard to swallow?
2023-09-05 20:05:17 <ikke> yes
2023-09-07 10:57:22 <Ermine> I'm going to enable mt7921au module in linux-edge. Should I enable it for all arches and are there other similar modules I should enable as well?
2023-09-07 12:07:49 <omni> I'll change upstream of sslh if no-one beats me to it
2023-09-07 12:08:15 <ikke> 👍
2023-09-07 12:25:47 <RootWyrm> Ermine: yes please on all arches. Can you please mention here when merged so I remember to rebase what I'm working on?
2023-09-07 12:26:28 <Ermine> Sure
2023-09-07 12:42:55 <Ermine> file "community/linux-edge/config-edge.aarch64" is quite big (266 kiB), better to upload it to dev.alpinelinux.org <-- what should I do? In fact, I've made it a bit smaller
2023-09-07 12:57:30 <ikke> Ermine: Something like was done for the lts kernel: f2d708907ba2fccc8b499c588f713b47d5cba2ed
2023-09-07 12:58:54 <Ermine> Oh
2023-09-07 13:55:02 <Kladky> Hello, I am having an issue when replying to emails sent from gitlab where it cannot recieve emails due to TLS not being available.
2023-09-07 13:55:21 <Kladky> The error is as follows: Diagnostic-Code: smtp; 451 4.0.0 No usable MXs, last err: TLS it not available or unauthenticated but required
2023-09-07 13:57:29 <humm> Well, does GitLab’s receiving MTA support TLS?
2023-09-07 13:58:11 <Kladky> I would sure hope so.
2023-09-07 14:00:48 <Kladky> It seems you can setup an MTA of your choice: https://docs.gitlab.com/ee/administration/incoming_email.html#set-it-up
2023-09-07 14:12:52 <minimal> Kladky: shouldn't your email server fallback to non-TLS if TLS is not available?
2023-09-07 14:15:23 <Kladky> No, MTA-STS is setup so that messages are never sent over plain text (as it should be).
2023-09-07 14:16:58 <minimal> MTA-STS *for your domain* is to ensure that incoming email to your domain uses TLS.
2023-09-07 14:17:52 <minimal> so unless Alpine have MTA-STS set up for their domain then MTA-STS isn't relevant for you sending email to Alpine's domain
2023-09-07 14:20:22 <Kladky> Idk then, cause Alpine's gitlab doesn't have an MTA-STS polciy.
2023-09-07 14:21:52 <Kladky> Does email reply work for you?
2023-09-07 14:22:09 <omni> pkgrel bump isn't needed hee !51217 right?
2023-09-07 14:22:16 <minimal> so then you need to look at the email config at your end to see why it does not fallback to non-TLS
2023-09-07 14:24:23 <Kladky> Probably, but it is really strage that a security-focused distro doesn't even have TLS support on it's gitlab MTA.
2023-09-07 14:24:48 <minimal> why not ask in the alpine-infra channel?
2023-09-07 14:25:14 <Kladky> Ok, will do.
2023-09-07 14:29:58 <fluix> I think we need to figure out what the actual secfixes policy is, because it's coming up again and again (re: omni)
2023-09-07 14:32:13 <fluix> as for pkgrel, I'm not sure if the security tracker cares about it. if yes, then bump, if not, then no
2023-09-07 15:05:01 <ikke> omni: no
2023-09-07 15:05:27 <ikke> the secfixes tracker indeed does not care, it collects everything that is in aports tree-wide
2023-09-07 15:05:31 <ikke> or rather, secdb does
2023-09-07 21:40:05 <omni> 3.18 builders stuck on various
2023-09-07 21:58:28 <ptrc> poked them so they retrigger again
2023-09-08 06:27:08 <omni> they need to be re-poked (=
2023-09-08 06:35:43 <omni> tickle the builders
2023-09-08 06:48:40 <ikke> omni: if they are just in a failed state, you can do it yourself 
2023-09-08 06:48:47 <ikke> algitbot: retry master
2023-09-08 06:49:06 <ikke> If they are stuck, someone with builder access needs to check 
2023-09-08 06:53:17 <omni> aha!
2023-09-08 06:58:05 <omni> algitbot: retry 3.18-stable
2023-09-08 09:31:06 <kaathewise> Good day!  I was bumping a version of a package, and it broke the building process.  gunzip returns an "unexpected end of file"  error
2023-09-08 09:31:24 <kaathewise> I tried downloading the same archive w/ wget, and it gets unzipped just fine
2023-09-08 09:36:36 <kaathewise> Is there, perhaps, some known issue with archives?  I couldn't find anything similar in the Gitlab issues
2023-09-08 09:37:28 <omni> what aport? do you have an MR?
2023-09-08 09:38:00 <kaathewise> testing/vale.  I tried to bump the version to 2.28.3
2023-09-08 09:38:09 <kaathewise> I don't have an MR, because I can't build it locally
2023-09-08 09:41:51 <omni> let's see
2023-09-08 09:42:55 <kaathewise> Its bizzare, because versions 2.28.2 and 2.28.1 work.  And manually fetching 2.28.3 with wget, unzipping, and building it works too
2023-09-08 09:44:06 <omni> and seem to work on CI builders !51280 so probably something local
2023-09-08 09:46:43 <kaathewise> Thanks!
2023-09-08 09:46:56 <kaathewise> On this note, is there some kind of a cache for abuild?
2023-09-08 09:47:52 <ikke> Yes, /var/cache/distfiles
2023-09-08 09:48:18 <kaathewise> That must be it
2023-09-08 09:48:41 <kaathewise> the .3 archive is malformed for some reason, only 560K instead of expected 9M
2023-09-08 09:48:59 <ikke> abuild cleancache removes the archives for the current version of the current package 
2023-09-08 09:51:25 <kaathewise> Yep, cleaning the cache fixed it.  TY!
2023-09-08 09:55:08 <dok> hi, I am trying to get an aarch64 kernel from alpine to boot with barebox, it fails because barebox doesn't seems to properly handle the vmlinux image used.
2023-09-08 09:55:18 <omni> kaathewise: I assume you'd like me to merge that, right?
2023-09-08 09:55:35 <dok> I am a bit confused on the different vmlinux format and how there are supposed to be used
2023-09-08 09:55:57 <kaathewise> omni: yes
2023-09-08 09:56:13 <dok> for instance, does vmlinuz-lts needs to be first decompressed ?
2023-09-08 09:59:25 <dok> because when decompressed the image starts with the MZ magic number... but why ?
2023-09-08 10:15:54 <omni> algitbot: retry master
2023-09-08 10:40:47 <chereskata> Hi, i opened a MR to upgrade protobuf. After bumping the pkgrel of depending programs, some of them do not want to compile. Could someone give some "how to fix" ideas?
2023-09-08 10:40:51 <chereskata> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51119
2023-09-08 10:41:21 <ikke> I was looking at mosh before, but couldn't find that offending line
2023-09-08 11:32:20 <kaathewise> If I push a commit, which changes my alias to my real name, do I need to increment $pkgrel?
2023-09-08 11:35:53 <ikke> Yes, the maintainer name is part of the package metadata 
2023-09-08 11:36:17 <kaathewise> TY
2023-09-08 11:36:19 <ikke> You could skip it if you don't care that it's changed until the next upgrade
2023-09-08 11:36:31 <ikke> it's not changed*
2023-09-08 11:36:54 <kaathewise> Yeah, its nothing important
2023-09-08 12:23:51 <chereskata> After trying to bump webrtc-audio-processing to 1.3 i get the following compile error: `'int64_t' has not been declared` how could i fix it?
2023-09-08 12:29:47 <ikke> Patch it to add <stdint.h> I believe 
2023-09-08 14:19:32 <chereskata> Thanks, this fixed it :)
2023-09-08 16:56:01 <humm> chereskata: send the patch upstream
2023-09-08 17:18:13 <linearcannon> is there any specific requirement to get an arch added to abuild/apk-tools
2023-09-08 17:19:05 <linearcannon> i've been working on a port off-and-on for a while and it would be a lot easier if i wasn't maintaining my own patchset for those on my system
2023-09-08 17:21:05 <linearcannon> everything else is easy to rebase
2023-09-08 17:31:53 <durrendal> what arch are you trying to add, out of curiosity
2023-09-08 17:51:59 <linearcannon> m68k
2023-09-08 17:52:16 <Habbie> why
2023-09-08 17:52:49 <Habbie> fairer question, how big is such a patch? (i have no control over apk-tools or anything but i'm curious)
2023-09-08 17:54:10 <linearcannon> 2 lines for apk-tools, 2 lines for abuild
2023-09-08 17:54:29 <Habbie> then i'd say, just submit it
2023-09-08 17:54:33 <Habbie> got nothing to lose
2023-09-08 17:55:30 <linearcannon> there's a bit more work in aports, mostly to disable things that don't support it (like golang), or add it to a list of archs that need a given flag to build, which is already present (like openssl)
2023-09-08 17:55:54 <Habbie> right
2023-09-08 17:55:57 <linearcannon> right now it doesn't bootstrap because of some failure in gmp, but i've had a working chroot before
2023-09-08 17:56:12 <Habbie> still curious - what's your hardware?
2023-09-08 17:56:16 <linearcannon> most of the other big fixes i've needed aren't arch-specific and already made it into aports
2023-09-08 17:56:23 <linearcannon> macintosh quadra 700
2023-09-08 17:56:26 <Habbie> cool
2023-09-08 17:56:34 <Habbie> how much power does that draw?: >
2023-09-08 17:57:17 <Habbie> and how much RAM did you put in?
2023-09-08 17:57:35 <linearcannon> not much. i have a lot of retro machines, and the only one really worth thinking about as far as power draw is my powermac g5, which i don't really use now that i have a power9 box
2023-09-08 17:57:54 <linearcannon> i think the q700 is rated for 45 watts or so but that's meant to include addon cards and hard drive
2023-09-08 17:58:02 <Habbie> that's.. not too bad
2023-09-08 17:58:02 <linearcannon> i have no cards, and it's got a ssd
2023-09-08 17:58:13 <Habbie> for the actual performance it's a lot, of course
2023-09-08 17:58:19 <linearcannon> sure
2023-09-08 17:58:21 <Habbie> ssd? some adapter?
2023-09-08 17:58:32 <linearcannon> it's a scsi emulator that uses an sd card as a backing store
2023-09-08 17:58:46 <Habbie> right
2023-09-08 17:58:53 <linearcannon> other machines i have which don't use scsi, i just use a compactflash card
2023-09-08 17:59:14 <Habbie> uhuh
2023-09-08 17:59:26 <Habbie> oh that reminds me, i need to buy CF cards or adapters for some old devices i got
2023-09-08 17:59:39 <Habbie> linearcannon, do you know if linux intends to keep m68k support around?
2023-09-08 18:00:05 <linearcannon> Habbie, i don't think it has any intent to *drop* it. it doesn't take much maintenance
2023-09-08 18:00:15 <Habbie> ah
2023-09-08 18:00:19 <linearcannon> things like i386/i486 are a different story here since they affect arch-specific infrastructure targeting new stuff
2023-09-08 18:00:31 <Habbie> ah yes
2023-09-08 18:00:33 <Habbie> that makes sense to me
2023-09-08 18:00:35 <Habbie> it's out of the way
2023-09-08 18:00:38 <linearcannon> exactly
2023-09-08 18:00:51 <Habbie> it's 32 bits?
2023-09-08 18:00:56 <linearcannon> yes
2023-09-08 18:01:24 <Habbie> did you port the irix filemanager to alpine for it?
2023-09-08 18:01:28 <Habbie> to re-enact Jurassic Park?
2023-09-08 18:01:50 <linearcannon> no, i have an sgi indy and octane if i want to do that :)
2023-09-08 18:02:02 <Habbie> hah
2023-09-08 18:02:17 <Habbie> i got rid of my last few SGIs a few years ago
2023-09-08 18:02:24 <Habbie> turned out that wasn't my hobby any more
2023-09-08 18:02:31 <Habbie> (now it's old routers, hence the need for CF)
2023-09-08 18:02:52 <Habbie> i haven't searched yet, but do you happen to have recommendations for CF? are SD adapters a thing?
2023-09-08 18:03:13 <linearcannon> i don't think so. i just buy modern-manufactured cf cards and they usually turn out fine
2023-09-08 18:03:35 <Habbie> ack
2023-09-08 18:03:38 <Habbie> plus some way to write them i guess :)
2023-09-08 18:03:51 <linearcannon> i have an odd 486 that doesn't like POST with some of the cards i have on a coldboot
2023-09-08 18:04:02 <linearcannon> but i also have a magneto-optical drive in that and i usually just use that instead
2023-09-08 18:04:14 <linearcannon> with a floppy emulator to get installer images and such if i need them
2023-09-08 18:04:52 <linearcannon> anyway. yeah, i guess i'll just submit the patches to abuild/apk-tools and see what happens?
2023-09-08 18:05:05 <Habbie> i would, yes
2023-09-08 18:16:37 <chereskata> how do you bump poppler when it has a circular dependency on poppler-qt5 and that depends on poppler again?
2023-09-08 18:31:28 <ikke> I think you need to upgrade them at the same time
2023-09-08 18:31:43 <chereskata> If i build locally, how do i do this?
2023-09-08 18:32:42 <ikke> poppler does not have a makedepend on poppler-qt5
2023-09-08 18:33:07 <ikke> so you upgrade poppler first, then poppler-qt5
2023-09-08 18:33:28 <chereskata> i tried, but it did not go troudh
2023-09-08 18:33:43 <ikke> poppler-qt5 lives in community, so poppler cannot depend on it
2023-09-08 18:34:19 <ikke> chereskata: what error(s) did you get?
2023-09-08 18:35:41 <chereskata> Out of my head it was something related to poppler-qt5 having a too low version
2023-09-08 18:35:55 <ikke> yes, that's something that is literally in the APKBUILD
2023-09-08 18:36:02 <ikke> in the prepare action
2023-09-08 18:36:18 <chereskata> I'll check later
2023-09-08 18:36:20 <ikke> so you change the pkgver of poppler-qt5, but don't build it yet
2023-09-08 18:36:33 <chereskata> Ahh okey
2023-09-08 18:36:34 <ikke> (honestly, it's a hack what they did)
2023-09-08 18:37:05 <ikke> it just checks the pkver variable of the APKBUILD, it does not need it to build
2023-09-08 18:37:26 <chereskata> Thanks a lot :)
2023-09-08 18:37:39 <ikke> You're welcome
2023-09-08 18:37:48 <ikke> And, welcome to Alpine btw :-)
2023-09-08 18:49:41 <chereskata> I'm glad i can help out here and there :D
2023-09-09 01:17:00 <linearcannon> https://paste.sr.ht/~ky0ko/4e75a3ffbc88fdad21b3626444892d924b28b2dc i believe binutils apkbuild is subtly broken for bootstrap/cross
2023-09-09 01:17:14 <linearcannon> similar issue as i fixed a while back in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24871 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24870
2023-09-09 01:18:15 <linearcannon> i'm not sure you can actually trigger the error targeting any archs that alpine officially supports
2023-09-09 01:19:03 <linearcannon> if the target has a 64-bit version (e.g. armv7->aarch64) then it will silently skip the host library instead of erroring; if it's same-arch i think it might incorrectly link against the host library
2023-09-09 01:19:29 <linearcannon> i'll try to fix it later, binutils is a bit tricky though
2023-09-09 02:02:42 <linearcannon> i think i figured it out. the sysroot check is not correct. it should check if CBUILD != CTARGET, but checks CHOST. this would be correct for anything but a toolchain component
2023-09-09 02:15:58 <linearcannon> everything else in that APKBUILD that checks CHOST against CTARGET is correct, i think. it's only the sysroot check that should be CBUILD instead
2023-09-09 02:16:05 <linearcannon> its libtool likely also needs to be updated
2023-09-09 02:18:12 <linearcannon> yeah. see also: LFS. it mentions this being an issue on the second pass only (where i'm seeing this) and offers a quick fix https://www.linuxfromscratch.org/lfs/view/development/chapter06/binutils-pass2.html
2023-09-09 07:39:38 <nmeum> ikke: should we rebuild testing with the new Go as well? 🤔
2023-09-09 07:42:09 <ikke> Probably, to weed out build issues
2023-09-09 07:48:54 <nmeum> and also to have the standard library security fixes applied to software in testing :)
2023-09-09 07:50:14 <nmeum> 1ab901c2155987b7d849a4e9f930596601ef67ab
2023-09-09 07:59:53 <Newbyte> Is anything blocking !51021 from being merged?
2023-09-09 11:47:02 <omni> Newbyte: a sign of approval, but I guess your question is? =)
2023-09-09 11:48:25 <omni> I think too many tests are disabled
2023-09-09 11:48:37 <omni> in general, not just that aport
2023-09-09 11:49:26 <omni> but for that aport, would it be possible to patch out just the test that require geoclue?
2023-09-09 11:55:34 <caskd> Could someone have a look at https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/8? Been hanging in the merge list without any feedback or progress and it's quite a useful improvement
2023-09-09 11:56:01 <omni> Newbyte: I'm saying that here rather than in the MR because I don't want to suggest that it would be needed for that one to be merged
2023-09-09 11:57:31 <omni> ncopa: ^^ mdev-conf
2023-09-09 11:58:30 <caskd> one could say it's even a bug solution considering the comments say "virtio-blk" even though the case used only handles virtio-scsi ;)
2023-09-09 12:48:19 <Newbyte> <omni> "Newbyte: a sign of approval, but..." <- Cogitri isn't active any more, so I don't think he'll approve it
2023-09-09 13:12:54 <omni> Newbyte: ah, sorry about the mixup, somehow I managed to read it as that it was assigned to you
2023-09-09 13:13:20 <omni> didn't know he wasn't, perhaps someone should adopt that and others then?
2023-09-09 13:18:00 <Newbyte> omni: His packages have slowly been adopted by others, but there are still some stragglers like this one
2023-09-09 13:18:45 <Newbyte> See !39229
2023-09-09 13:48:15 <RootWyrm> Well, this is a new one by me... 3.18 should be fine with ext4 root by default, should it not?
2023-09-09 13:48:38 <Cogitri> Yeah, I usually read pings in IRC but unfortunately I‘m pretty busy otherwise @omni
2023-09-09 23:07:34 <RootWyrm> This might be the damndest thing I've ever seen... the AMLogic S905X consistently just destroys the ext4 root when /sbin/init runs.
2023-09-09 23:23:10 <dalias> uhg wtf
2023-09-09 23:23:22 <dalias> can you tell how it's happening?
2023-09-09 23:23:40 <dalias> i'm using one with no problem
2023-09-09 23:23:47 <dalias> librecomputer le potato
2023-09-10 00:39:12 <RootWyrm> dalias: no idea how it's happening. 3.18 with their u-boot or your own?
2023-09-10 00:39:57 <RootWyrm> Well, let me rephrase. I know where and what point: "[BL31]: tee size: 0" and rootfs is dead.
2023-09-10 02:08:25 <dalias> what prints that?
2023-09-10 03:08:05 <RootWyrm> dalias: something in the amlogic firmware itself.
2023-09-10 16:06:36 <elly> I am pondering whether it makes sense to package any janet packages using apk... janet itself is packaged, but currently I think everything else is installed via jpm
2023-09-10 16:06:46 <elly> some janet modules (like sqlite) can be built against system libs: https://github.com/janet-lang/sqlite3
2023-09-10 16:40:44 <ikke> elly: how big is the chance on conflicts (project A needs version x of dependency D, but project B needs version y)
2023-09-10 16:41:24 <elly> that's a good question, I am unsure of the answer
2023-09-10 16:41:27 <elly> or how jpm solves it
2023-09-10 19:07:49 <omni> of all the rios I hadn't heard of a terminal
2023-09-11 06:55:36 <ncopa> good morning! im back after a few days in the mountains
2023-09-11 06:57:11 <Habbie> hope you enjoyed that :)
2023-09-11 07:02:35 <ncopa> was very nice
2023-09-11 07:21:54 <Ermine> Which mountains did you visit?
2023-09-11 07:24:02 <ikke> The Alps ofcourse 
2023-09-11 07:25:30 <quinq> Well, that's a lot of mountains :)
2023-09-11 08:54:40 <chereskata> Hi, could someone merge testing/flowtime, main/poppler, main/mpfr4 MRs? Thanks :)
2023-09-11 09:20:55 <ncopa> Ermine: Jotunheimen, Norway
2023-09-11 09:22:17 <ncopa> The tops: Rasletinden and Sikkilsdalshøa
2023-09-11 09:22:54 <ncopa> And Gjendehøe, if that counts
2023-09-11 09:23:45 <ncopa> lets continue in #alpine-offtopic
2023-09-11 10:35:31 <ikke> proposal for contributing loongarch support: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15260
2023-09-11 11:30:13 <chereskata> Hey, i tried to bump pkgrel of poppler depending programs. Unfortunately scribus does not want to compile
2023-09-11 11:30:31 <chereskata> there seems some compiler-based problem with 'off64_t' was not declared in this scope; did you mean 'off_t'
2023-09-11 11:30:45 <ptrc> yeah, that's the new musl version not having those symbols
2023-09-11 11:30:53 <chereskata> should i patch it?
2023-09-11 11:30:57 <ptrc> yes
2023-09-11 11:31:15 <ptrc> off64_t -> off_t, and the function names ending in 64 as well
2023-09-11 11:31:26 <chereskata> thanks!
2023-09-11 11:58:35 <Ermine> ikke: do they mean 'make it possible to build aports for loongarch64' or 'make alpine releases for loongarch64'?
2023-09-11 12:40:04 <ikke> Ermine: I suppose to start building packages 
2023-09-11 12:49:47 <omni> is vim one of those aports that are still in main of historical reasons and should perhaps be moved to community?
2023-09-11 12:50:33 <ptrc> doesn't vim provide xxd or something?
2023-09-11 12:50:52 <ptrc> or, well, busybox probably also has a small impl
2023-09-11 12:55:23 <Habbie> TIL: even xxd on debian comes from vim sources
2023-09-11 13:16:30 <raspbeguy> Hi. Would somebody have the time to check !51336 please? This package is necessary to make new Matrix client Element X work.
2023-09-11 14:32:48 <xordspar0> Is there a way to clear an out-of-date flag? Someone flagged my package, but there's no mention of a new version on the project's github or repology. https://pkgs.alpinelinux.org/package/edge/testing/x86_64/chocolate-doom
2023-09-11 14:33:19 <ikke> There is no official way 
2023-09-11 14:41:07 <ptrc> yeah, usually you can just ignore it
2023-09-11 14:41:18 <ptrc> it doesn't do anything besides showing up on pkgs.a.o/flagged
2023-09-11 15:07:36 <chereskata> @ptrc: There is an open issue here: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/issues/48
2023-09-11 18:06:46 <omni> is it because their branch is called master that I cannot rebase !51426 ?
2023-09-11 18:07:01 <ikke> omni: it's because the master branch is protected by default
2023-09-11 18:07:44 <ikke> omni: fixed
2023-09-11 18:15:22 <omni> 👍
2023-09-11 18:15:54 <omni> ikke: or what was it that you fixed?
2023-09-11 18:16:02 <ikke> omni: I unprotected it
2023-09-11 18:16:58 <omni> shouldn't it be?
2023-09-11 18:17:43 <ikke> Not if you want to be able to rebase it 
2023-09-11 18:18:07 <omni> you did it for just that MR?
2023-09-11 18:18:10 <ikke> Normally users create dedicated branches which are not protected 
2023-09-11 18:18:18 <ikke> For that fork 
2023-09-11 18:18:24 <omni> ah, ok
2023-09-11 18:19:02 <ikke> users push the branch to their fork, you are rebasing that branch in their fork
2023-09-11 18:19:11 <ikke> so if master is protected, you cannot rebase it
2023-09-11 18:23:03 <omni> right
2023-09-11 18:31:02 <ikke> omni: btw, your maintainer address is not available on your profile, so aports-qa-bot automaintainer does not work for your packages
2023-09-11 20:10:01 <omni> because I chose "Do not show on profile"?
2023-09-11 20:10:38 <omni> updated that, it's publicly available through git logs anyway
2023-09-11 20:14:38 <ikke> Hm, it's because of the extra tag
2023-09-12 07:32:59 <hjaekel> Good morning @ikke, is it possible to continue reviewing my changes in !51000? It looks like you started to review them but then got interrupted.
2023-09-12 17:34:48 <bl4ckb0ne> is there a reason why the aavmf package is aarch64 only?
2023-09-12 17:35:17 <bl4ckb0ne> oh its built not copied
2023-09-12 17:45:01 <minimal> bl4ckb0ne: yeah the same issue applies for ovmf as well
2023-09-12 17:45:35 <bl4ckb0ne> yeah i figured
2023-09-12 17:45:44 <bl4ckb0ne> wanted to aavmf file for qemu-system-aarch64
2023-09-12 17:45:56 <bl4ckb0ne> but grabbing the pkg and manually extracting it did the work
2023-09-12 17:45:57 <minimal> so if wanting to run aarch64 VMs on an Alpine x86_64 host you have to download and extract the AAMF out of the aarch64 apk file
2023-09-12 17:46:34 <minimal> right, but then you don't automatically get updated versions of the AAMF file when they're published by Alpine
2023-09-12 17:46:50 <bl4ckb0ne> 
ACTION shrugs

2023-09-12 17:58:58 <bl4ckb0ne> a way to include a submodule required by a source release?
2023-09-12 17:59:51 <ikke> bl4ckb0ne: download them as separate source
2023-09-12 18:00:23 <ikke> and then move them to the correct location
2023-09-12 18:00:37 <ikke> see for example netdata
2023-09-12 18:00:41 <bl4ckb0ne> thanks
2023-09-12 18:07:14 <hjaekel> thank you for the review and merge, ikke
2023-09-12 18:07:25 <ikke> hjaekel: yw
2023-09-12 18:49:30 <Saijin_Naib[m]> hjaekel you crazy person, you! 
2023-09-12 18:49:34 <Saijin_Naib[m]> You did it! 
2023-09-12 18:54:38 <hjaekel> Saijin_Naib[m] yes, we have now GRASS and QGIS in edge. The GIS ecosystem is evolving.
2023-09-12 18:55:34 <Saijin_Naib[m]> hjaekel: I'll be testing shortly... Gotta up my game and start packaging OpenDroneMap stuff now 🤣
2023-09-12 18:56:43 <Saijin_Naib[m]> And maybe pitch OSGeoLive to rebase on Alpine so they aren't hitting that DVD Media size constraint as easily as they are now 🤔
2023-09-12 18:58:23 <hjaekel> haha, I have received complaints from ikke that the QGIS package is very large.
2023-09-12 18:58:49 <ikke> It is 😋
2023-09-12 19:00:42 <hjaekel> And please test if you have time. I already know a bug in QGIS: The developer map in the about window is not displayed.
2023-09-12 19:07:59 <Saijin_Naib[m]> I have some older projects that lean heavily on advanced symbology and multiple data types, so should be a good way to poke at it 
2023-09-13 10:48:39 <ncopa>   = note: /usr/lib/gcc/x86_64-alpine-linux-musl/13.1.1/../../../../x86_64-alpine-linux-musl/bin/ld: /home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/output/target/release/deps/shortwave-b3eddde814f760d5.shortwave.150c8ae19828016e-cgu.0.rcgu.o: in function `getrandom::util_libc::open_readonly':
2023-09-13 10:48:39 <ncopa>           shortwave.150c8ae19828016e-cgu.0:(.text._ZN9getrandom9util_libc13open_readonly17h9a47521370a9ec8eE+0xd): undefined reference to `open64'
2023-09-13 10:48:56 <ikke> lfs64
2023-09-13 10:48:59 <ncopa> i suppose I need a newer version of util_libc something?
2023-09-13 10:58:21 <ncopa> how do I update the Cargo.lock?
2023-09-13 10:58:52 <ikke> cargo upgrade -p
2023-09-13 10:58:58 <ikke> with the version you want
2023-09-13 10:59:13 <ikke> or rather, the package
2023-09-13 10:59:33 <ncopa> error: no such command: `upgrade`
2023-09-13 10:59:33 <ncopa> 	Did you mean `update`?
2023-09-13 10:59:35 <ikke> cargoyes
2023-09-13 10:59:49 <ikke> cargo update -p libc
2023-09-13 10:59:57 <ncopa> cargo update -p getrandom --precise 0.2.10
2023-09-13 11:00:07 <ncopa> didnt do anything from what I could see
2023-09-13 11:00:39 <ncopa> neither did cargo update -p libc
2023-09-13 11:00:39 <ikke> pj: do you know ^?
2023-09-13 11:02:58 <pj> what are you doing it on
2023-09-13 11:03:08 <pj> does anything change in lockfile?
2023-09-13 11:03:13 <ncopa> community/gnome-shortwave
2023-09-13 11:03:24 <ncopa> nope. nothing appears to change
2023-09-13 11:03:48 <pj> what's in Cargo.toml ?
2023-09-13 11:04:18 <pj> probably need to look at dep tree if it's not being locked to specific version 
2023-09-13 11:04:42 <ncopa> $ tpaste < Cargo.toml 
2023-09-13 11:04:42 <ncopa> https://tpaste.us/PEX7
2023-09-13 11:05:48 <ncopa> how do I find out which dependency is preventing the update?
2023-09-13 11:06:06 <pj> Look at what uses libc
2023-09-13 11:06:33 <ncopa> in the Cargo.lock?
2023-09-13 11:06:40 <ncopa> there are a lot of them that uses libc
2023-09-13 11:06:42 <pj> In lockfile there should be a dep that lists libc 0.2.something
2023-09-13 11:06:55 <pj> or whichever version it was
2023-09-13 11:07:21 <ncopa> none of the libc entries in Cargo.lock are versioned
2023-09-13 11:07:43 <pj> then that's harder :>
2023-09-13 11:08:03 <ncopa> there is a  [[package]]
2023-09-13 11:08:06 <pj> didn't gnome stuff used vendored deps?
2023-09-13 11:08:06 <ncopa> name = "libc"
2023-09-13 11:08:21 <ncopa> version = "0.2.139"
2023-09-13 11:09:37 <ncopa> oh, there is a vendor/libc/Cargo.toml
2023-09-13 11:09:49 <ncopa> how do I update that?
2023-09-13 11:10:31 <pj> You can look at rust package for example
2023-09-13 11:10:43 <pj> https://git.alpinelinux.org/aports/tree/main/rust/APKBUILD#n147
2023-09-13 11:13:43 <ncopa> oh man.
2023-09-13 11:14:00 <ncopa> i thought rust was complicated in general
2023-09-13 11:14:09 <ncopa> i was wrong. its super complicated
2023-09-13 11:14:53 <pj> it's not that complicated, imo....
2023-09-13 11:20:56 <ncopa> im gonna report it upstream
2023-09-13 11:22:27 <pj> ncopa: no need
2023-09-13 11:22:33 <pj> they are already on patched version
2023-09-13 11:22:50 <pj> on HEAD
2023-09-13 11:23:17 <pj> well, one patch version lower than available
2023-09-13 11:23:18 <pj> https://gitlab.gnome.org/World/Shortwave/-/blob/main/Cargo.lock?ref_type=heads#L1535
2023-09-13 11:28:50 <ncopa> so i could just grab a patch from upstream I suppose
2023-09-13 11:29:13 <pj> well, no
2023-09-13 11:29:33 <pj> because they are creating vendor when releasing new version
2023-09-13 11:30:08 <j_v> is there a document that describes the conditions by which an aport in testing can be moved to community?
2023-09-13 11:30:09 <pj> you can patch the libc
2023-09-13 11:30:25 <pj> j_v: no, it's up to the maintainer of the package
2023-09-13 11:30:40 <j_v> pj: thanks
2023-09-13 11:31:17 <pj> it's usually along the lines of "I feel this package is tested enough, so I'm going to move it community"
2023-09-13 11:32:52 <Piraty_> arm64 rebuild due to gcc bug?  https://rtx.meta.security/mitigation/2023/09/12/CVE-2023-4039.html
2023-09-13 11:33:30 <j_v> thanks for the clarification
2023-09-13 11:34:13 <ikke> Piraty_: mentioned it in #alpine-security as well 
2023-09-13 11:34:37 <Piraty_> which i'm not in... sorry for noise then
2023-09-13 11:34:38 <Piraty_> where are alpine's CFLAGS defined?
2023-09-13 11:35:01 <pj> usr/share/abuild.conf ?
2023-09-13 11:35:19 <pj> it's in abuild, I don't remember the new path for the defaults
2023-09-13 11:35:46 <pj> # defaults are in /usr/share/abuild/default.conf
2023-09-13 11:36:06 <Piraty_> default.conf
2023-09-13 11:36:24 <Piraty_> i expected it to be part of aports at first
2023-09-13 11:36:56 <pj> one can build a package that is not part of aports :>
2023-09-13 11:37:44 <ncopa> i think our toolchain enables stack protector by default
2023-09-13 11:38:10 <pj> oh yeah, there are some defaults set in gcc APKBUILD
2023-09-13 11:38:17 <ncopa> so its will be -fstack-protector-strong  unless explicitly disabled
2023-09-13 11:38:27 <ncopa> ... or similar
2023-09-13 11:39:14 <pj> ncopa: do you need help with shortwave?
2023-09-13 11:39:41 <ncopa> maybe. let me try first
2023-09-13 11:41:28 <andypost[m]> I faced it on all arm* arches #15262
2023-09-13 11:43:08 <Piraty_> whenever i see that bot comment, i think of algae
2023-09-13 11:44:01 <pj> You should be able to just take patch from rust package and apply it on vendor/libc https://git.alpinelinux.org/aports/tree/main/rust/lfs64-libc.patch.noauto
2023-09-13 11:44:13 <ncopa> thats what im trying to do
2023-09-13 11:46:19 <ncopa> allright
2023-09-13 11:46:30 <ncopa> rust is very very secure
2023-09-13 11:46:34 <ncopa> does not build if sources changes
2023-09-13 11:46:37 <ncopa> error: the listed checksum of `/home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/libc/src/unix/linux_like/mod.rs` has changed:
2023-09-13 11:46:37 <ncopa> expected: 759e65c13f7e49a6efd1a979c821c53c478648f7f00cb29da65d92904c7c6814
2023-09-13 11:46:37 <ncopa> actual:   08e46e47ee61effa3795d5617e9e237ec3deecd002789103d2f0a887ec745fd2
2023-09-13 11:47:54 <ncopa> i could not find the expected "759e65c13f7e49a6efd1a979c821c53c478648f7f00cb29da65d92904c7c6814"  anywhere?
2023-09-13 11:47:56 <pj> yeah, that's why I linked earlier you to rust APKBUILD which has the function to clean checksums :P
2023-09-13 11:48:25 <pj> it's in vendor/libc/.cargo-checksum.json
2023-09-13 11:49:03 <pj> https://git.alpinelinux.org/aports/tree/main/rust/APKBUILD#n148
2023-09-13 11:52:43 <ncopa> ok. progress
2023-09-13 11:52:46 <ncopa> 775 | mod lfs64;
2023-09-13 11:52:46 <ncopa> error[E0583]: file not found for module `lfs64`
2023-09-13 11:52:46 <ncopa>    --> /home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/libc/src/unix/linux_like/linux/musl/mod.rs:775:1
2023-09-13 11:52:46 <ncopa>    Compiling ucd-trie v0.1.5
2023-09-13 11:52:46 <ncopa>     |
2023-09-13 11:52:48 <ncopa>     | ^^^^^^^^^^
2023-09-13 11:52:48 <ncopa>     |
2023-09-13 11:52:50 <ncopa>     = help: to create the module `lfs64`, create file "/home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/libc/src/unix/linux_like/linux/musl/lfs64.rs" or "/home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/libc/src/unix/linux_like/linux/musl/lfs64/mod.rs"
2023-09-13 11:54:21 <ncopa> i rebased the patch: 
2023-09-13 11:54:22 <ncopa> $ tpaste < lfs64-libc.patch 
2023-09-13 11:54:22 <ncopa> https://tpaste.us/6M4D
2023-09-13 11:55:17 <pj> probably the previous patch would work, since I rebased it for 1.72 rust
2023-09-13 11:56:35 <ncopa> $ rustc --version
2023-09-13 11:56:35 <ncopa> rustc 1.72.0 (5680fa18f 2023-08-23) (Alpine Linux 1.72.0-r0)
2023-09-13 11:57:02 <pj> rust also uses libc
2023-09-13 11:57:27 <pj> but nevermind, it was lfs64-rust.patch
2023-09-13 11:57:50 <ncopa> so i should use lfs64-rust.patch instead of the noauto?
2023-09-13 11:58:04 <pj> no, nevermind my rambling
2023-09-13 11:58:33 <pj> does the rebased (by you) patch work?
2023-09-13 11:58:51 <ncopa> i get the error[E0583]: file not found for module `lfs64`
2023-09-13 12:06:33 <pj> seems like part of patch didn't apply?
2023-09-13 12:07:42 <pj> it's missing the lfs64.rs file
2023-09-13 12:07:43 <pj> --- /dev/null
2023-09-13 12:07:43 <pj> +++ b/src/unix/linux_like/linux/musl/lfs64.rs
2023-09-13 12:08:18 <pj> it's not present in your patch
2023-09-13 12:12:50 <ncopa> allright
2023-09-13 12:17:19 <ncopa> now i get error with getrandom
2023-09-13 12:17:27 <ncopa> error[E0061]: this function takes 3 arguments but 2 arguments were supplied
2023-09-13 12:17:27 <ncopa>    --> /home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/getrandom/src/util_libc.rs:150:18
2023-09-13 12:17:27 <ncopa>     |                  ^^^^------------------------------------------------------------- an argument of type `u32` is missing
2023-09-13 12:17:27 <ncopa>     |
2023-09-13 12:17:27 <ncopa> 150 |         let fd = open(path.as_ptr() as *const _, libc::O_RDONLY | libc::O_CLOEXEC);
2023-09-13 12:17:28 <ncopa>     |
2023-09-13 12:17:28 <ncopa> note: function defined here
2023-09-13 12:17:30 <ncopa>    --> /home/ncopa/aports/community/gnome-shortwave/src/shortwave-3.2.0/vendor/libc/src/unix/linux_like/linux/musl/lfs64.rs:112:26
2023-09-13 12:17:30 <ncopa>     |
2023-09-13 12:17:32 <ncopa> 112 | pub unsafe extern "C" fn open64(
2023-09-13 12:17:32 <ncopa>     |                          ^^^^^^
2023-09-13 12:17:34 <ncopa> help: provide the argument
2023-09-13 12:17:34 <ncopa>     |
2023-09-13 12:17:36 <ncopa>     |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2023-09-13 12:17:36 <ncopa> 150 |         let fd = open(path.as_ptr() as *const _, libc::O_RDONLY | libc::O_CLOEXEC, /* u32 */);
2023-09-13 12:17:38 <ncopa> For more information about this error, try `rustc --explain E0061`.
2023-09-13 12:17:38 <ncopa> error: could not compile `getrandom` (lib) due to previous error
2023-09-13 12:18:38 <ncopa> i suppose i also need to patch vendored getrandom
2023-09-13 12:18:52 <pj> https://gitlab.alpinelinux.org/alpine/aports/-/raw/3.18-stable/community/rust/lfs64-getrandom.patch
2023-09-13 12:20:04 <ncopa> thank you sir!
2023-09-13 12:23:22 <ncopa> and it passed!
2023-09-13 12:26:43 <pj> I'll try to push MR for rust packages rebuild today, which I promised to ikke, so probably will find more issues
2023-09-13 17:41:06 <omni> aarch64 CI builder MIA?
2023-09-13 17:41:57 <ikke> I paused the backup CI runner, there should still be one available, let me check
2023-09-13 17:43:06 <ikke> omni: it's still there and running jobs
2023-09-13 17:43:17 <ikke> omni: I don't see any pending jobs?
2023-09-13 17:46:40 <omni> I cancelled it
2023-09-13 17:48:13 <ikke> there is 1 job running, it should run 2 at the same time
2023-09-13 17:48:22 <ikke> Now there are none
2023-09-13 18:37:19 <omni> elly: hey, I did !51465 yesterday but left chromium in 3.18-stable as it didn't look as easy
2023-09-13 21:51:40 <elly> omni: thanks! what made it look not as easy?
2023-09-13 21:51:43 <elly> (I'll take a peek)
2023-09-13 21:56:20 <omni> elly: that it looked like more than just bumping pkgver and updating the checksums
2023-09-13 21:59:54 <omni> I probably didn't have to add to the secfixes section since mitigated CVEs would be inferred from the version number
2023-09-13 22:03:19 <elly> well, let's find out
2023-09-13 22:11:26 <elly> hm, libstdc++13.patch and random-fixes.patch don't apply
2023-09-13 22:23:03 <elly> (wading through the various problems with libstdc++13.patch now)
2023-09-13 22:37:10 <elly> omni: I'm surprised that edge built with just a bump...
2023-09-13 22:39:34 <elly> aha, tricked by _extra_patches yet again
2023-09-13 22:50:01 <elly> oh no wonder, we never rolled 3.18 past 115
2023-09-13 22:58:00 <omni> I think it's mainly up to you how you want to do
2023-09-13 22:58:47 <elly> yeah
2023-09-13 22:58:50 <elly> I wonder if this will build
2023-09-13 23:00:32 <elly> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51557 I want to see a clean CI run on this before we do anything else to it
2023-09-13 23:00:37 <elly> I have pretty low confidence in it :)
2023-09-13 23:54:13 <elly> ughhhh it requires a gn upgrade as well
2023-09-13 23:54:15 <elly> what the heck
2023-09-13 23:54:31 <elly> omni: how on earth did the edge upgrade succeed?
2023-09-13 23:59:24 <elly> oh, because edge has the newer gn in it already
2023-09-14 00:13:27 <elly> ninja: file is missing and not created by any action: '../../../../../../../../../usr/lib/clang/18/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a'
2023-09-14 00:13:30 <elly> hmmm.
2023-09-14 00:18:55 <elly> ah butts
2023-09-14 00:20:56 <elly> two major clang versions out of date, this could get ugly
2023-09-14 00:37:02 <elly> current puzzlement: clang has its libs in /usr/lib/clang/16/lib/linux, not /usr/lib/clang/16/lib/x86_64-musl-linux (or whatever)
2023-09-14 00:55:23 <elly> yeah, I have no idea how to fix that one
2023-09-14 00:55:28 <elly> yuck :( advice solicited!
2023-09-14 01:35:00 <elly> (I think I figured that one out as well)
2023-09-14 02:52:22 <elly> ok: I can't figure out how to get chromium 117 to build on 3.18, and there's CVE-2023-4863 open against 115, so I will try to roll it to 116.0.5845.187 instead
2023-09-14 04:06:42 <elly> (I also can't get 116 to build yet... the rust goo doesn't seem to like our rust setup)
2023-09-14 08:45:06 <omni> ouch
2023-09-14 11:50:54 <consus> Hi guys. Busybox is known to be missing useradd and userdel applets, there is even a mail from ncopa: https://busybox.busybox.narkive.com/L1PLjgG4/adduser-addgroup-vs-portable-useradd-groupadd. However, do busybox guys oppose to the idea or no one just wrote these applets?
2023-09-14 12:53:11 <ncopa> looks like i wrote the groupadd applet and nobody cared
2023-09-14 12:53:32 <ncopa> consus: i think its just that nobody cared enough
2023-09-14 12:53:39 <consus> Maybe worth another shot?
2023-09-14 12:53:44 <ncopa> sure
2023-09-14 12:54:11 <ncopa> feel free to send a patch ;)
2023-09-14 12:54:20 <consus> Will do
2023-09-14 12:54:21 <consus> Thanks
2023-09-14 12:54:36 <ncopa> i think it will be good that they see that more people are interested in it
2023-09-14 12:56:01 <ikke> related? https://fosstodon.org/@troglobit/111056992977580594
2023-09-14 12:59:19 <consus> nah, it's jsut another flag for adduser
2023-09-14 12:59:30 <consus> scripts that expect useradd/userdel will still fail
2023-09-14 13:42:18 <minimal> consus: there are a lot of limitations in Busybox's adduser & related utils, e.g. it doesn't set some of the /etc/shadow fields relating to expriy, also (from memory) adduser sets strange permissions for users' home directories
2023-09-14 13:42:50 <consus> My biggest concern is that scripts fail miserably :D
2023-09-14 13:43:01 <consus> And having shadows just for two tools feels meh
2023-09-14 13:43:20 <consus> That's of course my OCD talking, but still
2023-09-14 13:43:22 <minimal> also the Busybox tools don't support BCRYPT for passwords, they use SHA512 with rounds=5000
2023-09-14 13:43:42 <consus> That's actually good idea
2023-09-14 13:43:50 <minimal> I've recently tested building "shadow" package to enable BCRYPT support
2023-09-14 13:44:00 <minimal> musl supports both SHA512 and BCRYPT
2023-09-14 13:44:39 <minimal> I think it would make more sense to "fix" any issues with the existing Busybox user-related tools before starting to write new useradd etc tools
2023-09-14 13:44:56 <chereskata> +1
2023-09-14 13:44:58 <consus> the problem is now the feature set
2023-09-14 13:45:06 <consus> the problem is that ansible running useradd will fail
2023-09-14 13:45:25 <consus> because busybox has no useradd at all
2023-09-14 13:45:33 <minimal> consus: "shadow" is for more than just "useradd" and "groupadd", there's "chpasswd" for example to get BCRYPT support
2023-09-14 13:45:45 <consus> true
2023-09-14 13:46:28 <minimal> and likewise "mkpasswd" also for BCRYPT support
2023-09-14 13:46:36 <consus> this is also true
2023-09-14 13:47:11 <consus> however, not being able  to create a user because nothing expects adduser instead of useradd is really a problem
2023-09-14 13:47:13 <minimal> I'm intended to raise a MR for the "shadow" and "mkpasswd" (sub-package of "whois") packages BCRYPT stuff once I've completed enough testing
2023-09-14 13:48:24 <minimal> consus: for example if you did implement useradd would you have it with expiry support? that wouldn't make sense if the other associated Busybox utils didn't make use of expiry support
2023-09-14 13:48:56 <minimal> so Busybox "login" would need to check for expiry etc which I don't think it currently does
2023-09-14 13:49:16 <consus> service users rarely need an expiration date
2023-09-14 13:49:23 <consus> at least I've never seen one
2023-09-14 13:49:38 <consus> but again, if that's usable, this can be added
2023-09-14 13:50:09 <minimal> well I'm asking if you "useradd" implementation would just not implement the expiry related stuff?
2023-09-14 13:50:26 <minimal> as then it would only be partly compatible
2023-09-14 13:50:50 <minimal> but if you did implement it then that would make no sense if the other BB tools didn't also implement expiry
2023-09-14 13:51:17 <consus> of course
2023-09-14 13:51:33 <consus> but I don't think that adding all at once is such a good idea
2023-09-14 13:51:41 <minimal> e.g. if you look at the BB code for adduser it sets the last several fields of the /etc/shadow file to empty values, that is hardcoded
2023-09-14 13:52:06 <consus> and someone who wants to user these fields can send a patch, nah?
2023-09-14 13:52:10 <consus> *to use
2023-09-14 13:52:25 <minimal> consus: well you want to do this because of apps expecting "useradd" - at some of those apps will expect 100% useradd compatibilty/functionality
2023-09-14 13:52:36 <consus> Perhaps
2023-09-14 13:53:05 <consus> But 99% of the automation tools I've seen just need a couple of them
2023-09-14 13:53:11 <minimal> to put this in context, I maintain cloud-init for Alpine, at present it relies up "shadow" being installed as it uses "useradd", "groupadd", "passwd", "chpasswd" etc
2023-09-14 13:54:01 <minimal> I have a local patch that I've been planning to implement for fallback on Alpine to adduser/addgroup etc and the expiry-related stuff etc is an issue/a pain
2023-09-14 13:54:27 <consus> And I wish you luck!
2023-09-14 13:55:43 <minimal> the point is BB doesn't provide 100% user management functionality with its existing tools, so adding a couple of new utils doesn't improve things that much
2023-09-14 13:56:17 <consus> it would improve it for me
2023-09-14 13:56:19 <minimal> expecially if the code I had "sees" useradd and expect that to have the complete functionality of the shadow useradd
2023-09-14 13:57:00 <minimal> cloud-init does make use of a lot of user-related functionality like expiry
2023-09-14 13:59:17 <minimal> consus: to use your Ansible example, it does/can make use of the password expiry and account expiry features of useradd
2023-09-14 14:01:50 <consus> Of course
2023-09-14 14:02:04 <consus> So someone who  want expiry can send a patch?
2023-09-14 14:02:53 <minimal> so then existing code that calls "useradd" would have to figure out whether it is "shadow" useradd or "busybox" useradd installed to know what options not to use?
2023-09-14 14:02:55 <consus> I even can do that if expiry support will land to login prior to that
2023-09-14 14:03:18 <consus> I think if existing code does not use expiry it's fine
2023-09-14 14:03:27 <consus> If it uses expiry you still need shadows
2023-09-14 14:03:31 <consus> nah?
2023-09-14 14:03:33 <minimal> consus: well there's 3 logins - "busybox", "shadow", and "util-linux" ;-)
2023-09-14 14:03:41 <consus> :D
2023-09-14 14:03:49 <consus> shadow and util-linux both have expiry
2023-09-14 14:03:54 <consus> so it's only busybox
2023-09-14 14:05:00 <consus> actually I'm not sure which login I have
2023-09-14 14:05:40 <consus> huh, busybox
2023-09-14 14:05:59 <consus> weird
2023-09-14 14:06:11 <consus> nvm
2023-09-14 14:06:12 <minimal> so you don't have PAM (from memory) then ;-)
2023-09-14 14:06:25 <consus> nope, not on this host
2023-09-14 14:06:38 <consus> And on the one I do...
2023-09-14 14:06:57 <consus> # apk info -W /bin/login
2023-09-14 14:06:58 <consus> ERROR: /bin/login: Could not find owner package
2023-09-14 14:06:59 <consus> LOL
2023-09-14 14:07:07 <minimal> have you tried locking a user's password?
2023-09-14 14:07:08 <consus> nah, still busybox
2023-09-14 14:07:24 <consus> AFAIR only root can login via console
2023-09-14 14:08:08 <minimal> I'm asking as without PAM if you lock a user's password and then try and SSH in using a key (rather than password) OpenSSH will not permit that
2023-09-14 14:08:10 <consus> ah, of course, I have no shadow-login there
2023-09-14 14:08:47 <consus> # apk info -L util-linux-misc | grep login | wc -l
2023-09-14 14:08:48 <consus> 0
2023-09-14 14:08:56 <consus> Btw, which package has util-linux login?
2023-09-14 14:08:58 <minimal> as OpenSSH incorrectly treats a lock password as being a locked account - UNLESS PAM is enabled in the config of the openssh-server-pam
2023-09-14 14:09:10 <ptrc> consus: util-linux-login
2023-09-14 14:09:14 <minimal> that would be util-linux-login ;-)
2023-09-14 14:09:34 <consus> :D
2023-09-14 14:09:43 <consus> Could've guessed
2023-09-14 14:12:07 <consus> openssh will not permit because of "empty" password?
2023-09-14 14:12:20 <consus> that's odd
2023-09-14 14:14:19 <minimal> consus: nope, "!" at the start of a password field indicates a locked password. On BSD such a "!" means the whole account is locked, whereas on Linux it means only password access is disabled. OpenSSH was written by BSD people so it treats the presence of a "!" as refusing all SSH logins (whether via password or key) UNLESS the OpenSSH server has PAM enabled which is treated as a special case
2023-09-14 14:14:48 <consus> But openbsd-portable is not for BSD
2023-09-14 14:15:00 <consus> So I kinda thought it's platform dependent
2023-09-14 14:15:00 <minimal> yes, but it is the same codebase
2023-09-14 14:15:01 <consus> Meh
2023-09-14 14:15:05 <minimal> and that logic is present
2023-09-14 14:15:33 <consus> I guess it can be patch in portable version, but I don't think anyone cares enough
2023-09-14 14:16:35 <consus> #ifdef SUPPORT_LOCKED_PASSWORDS
2023-09-14 14:16:45 <consus> <treat as locked password>
2023-09-14 14:16:46 <consus> #else
2023-09-14 14:16:47 <minimal> consus: it only tends to affect Alpine and other Linux distros tend to have PAM-enabled openssh server
2023-09-14 14:17:05 <minimal> s/ and other/ as other/
2023-09-14 14:17:55 <consus> I guess that's because people rarely need "passwordless" accounts
2023-09-14 14:18:22 <minimal> consus: you mean password-disabled accounts?
2023-09-14 14:18:37 <minimal> "passwordless" would mean no password at all
2023-09-14 14:18:38 <consus> I mean "login through other means"
2023-09-14 14:18:48 <consus> Bad wording
2023-09-14 14:19:22 <minimal> well it's typical for security reasons to disable remote access via password
2023-09-14 14:19:24 <consus> And "other means" are usually invlove PAM
2023-09-14 14:21:30 <consus> But you still can need password for sudo / doas / whatever
2023-09-14 14:21:42 <consus> So "PasswordAuthentication no"
2023-09-14 14:23:15 <minimal> Here's the openssh logic in question: https://github.com/openssh/openssh-portable/blob/master/auth.c#L111-L115
2023-09-14 14:24:28 <consus> > platform_locked_account
2023-09-14 14:24:37 <consus> that's your pick for #ifdef I think
2023-09-14 14:25:03 <consus> Actually
2023-09-14 14:25:29 <consus> It already has all the ifdefs
2023-09-14 14:26:02 <consus> https://github.com/openssh/openssh-portable/blob/b6b49130a0089b297245ee39e769231d7c763014/platform.c#L228C5-L228C10
2023-09-14 14:26:41 <consus> > #ifdef LOCK_PASSWD_STRING
2023-09-14 14:28:54 <minimal> LOCKED_PASSWD_STRING is used by (some?) BSDs I think, not by Linux
2023-09-14 14:29:03 <minimal> it would be LOCKED_PASSWD_PREFIX
2023-09-14 14:29:11 <consus> anyhow
2023-09-14 14:29:15 <consus> that's configured with configure
2023-09-14 14:29:28 <consus> LOCKED_PASSWD_STRING is set for hpux
2023-09-14 14:29:42 <consus> So unset this
2023-09-14 14:29:44 <consus> And it's okay
2023-09-14 14:29:48 <consus> problem solved
2023-09-14 14:30:30 <minimal> new problem created..........the problem is that *KEY* passwd access should be permitted regardless of whether or not the password is locked
2023-09-14 14:31:03 <consus> yes
2023-09-14 14:31:23 <consus> So remove false positive from the check for locked account
2023-09-14 14:31:42 <consus> Or am I missing something?
2023-09-14 14:33:03 <minimal> your suggestion changes how locked password are identified/treated, not whether key-access is permitted regardless of whether an account has a locked password or not
2023-09-14 14:33:34 <consus> nope
2023-09-14 14:33:41 <consus> Why?
2023-09-14 14:33:55 <consus> LOCKED_PASSWD_STRING is used only here, in platform_locked_account()
2023-09-14 14:34:04 <consus> Which check for locked account
2023-09-14 14:34:07 <consus> Not locked password
2023-09-14 14:35:16 <consus> The name is off, it should be LOCKED_ACCOUNT_STRING
2023-09-14 14:38:03 <consus> But I guess PASSWD here stands for passwd entry, not password
2023-09-14 14:38:29 <minimal> yupe
2023-09-14 14:38:45 <minimal> well, or /etc/shadow entry also ;-)
2023-09-14 14:39:12 <consus> So if this constant is defined on Linux with shadow that's a bug
2023-09-14 14:39:28 <minimal> what's a bug?
2023-09-14 14:39:31 <consus> Drop it and openssh will behave as expected
2023-09-14 14:39:54 <consus> #ifdef HAS_SHADOW_EXPIRE
2023-09-14 14:39:54 <consus> if (spw != NULL && auth_shadow_acctexpired(spw))
2023-09-14 14:39:54 <consus> return 1;
2023-09-14 14:39:54 <consus> #endif /* HAS_SHADOW_EXPIRE */
2023-09-14 14:40:01 <consus> ssh checks for expiration date here
2023-09-14 14:40:11 <consus> That's the proper check for *locked account*, right?
2023-09-14 14:40:45 <consus> No other check for *locked account* shall happen on Linux hosts, if I'm not missing anything
2023-09-14 14:41:33 <minimal> nope, a locked password (i.e. a password field in /etc/shadow beginning with "!") is AFAIK distinct from a expired password and from a expired account as those expiries are due to *different* fields in /etc/shadow
2023-09-14 14:41:55 <consus> forget about a locked password for a second
2023-09-14 14:42:08 <consus> how to check if *account* is locked?
2023-09-14 14:42:22 <consus> All I can see on the internets is "set expiry to 1"
2023-09-14 14:43:01 <minimal> look at the 2nd-last field of /etc/shadow which is the date of expiry (relative to 1970)
2023-09-14 14:43:28 <consus> that's "set expiry to 1"
2023-09-14 14:43:36 <consus> or "set expiration date prior to current"
2023-09-14 14:43:53 <minimal> yes
2023-09-14 14:43:56 <consus> So
2023-09-14 14:44:06 <minimal> as long as not 0
2023-09-14 14:44:11 <consus> We have no other means to check for *locked account*?
2023-09-14 14:44:45 <minimal> that's an expired account, i.e. no longer active
2023-09-14 14:44:53 <consus> yes
2023-09-14 14:44:57 <minimal> "locked account" is a BSD concept AFAIK
2023-09-14 14:45:02 <consus> okay
2023-09-14 14:45:06 <consus> we are talking about linux
2023-09-14 14:45:16 <ikke> doesn't ! as a password mean it's locked?
2023-09-14 14:45:20 <consus> no
2023-09-14 14:45:25 <consus> password is locked
2023-09-14 14:45:30 <minimal> it means that password access is prevent
2023-09-14 14:45:40 <minimal> but that other forms of access (i.e. SSH kjey) are permitted
2023-09-14 14:45:48 <consus> So openssh check for *locked account* here:  * For the account and password expiration functions, we assume the expiry
2023-09-14 14:45:55 <consus> dammit
2023-09-14 14:46:07 <consus> So openssh checks for *locked account* here: https://github.com/openssh/openssh-portable/blob/b6b49130a0089b297245ee39e769231d7c763014/platform.c#L215C15-L215C15
2023-09-14 14:46:12 <ikke> I recall there was a case where a locked password meant you cannot ssh
2023-09-14 14:46:15 <consus> It check if expiry > today
2023-09-14 14:46:40 <minimal> ikke: yes, that's what we're talking about - for non-PAM-enabled openssh server
2023-09-14 14:46:49 <consus> What happens next? It checks if pass->pw_passwd matches LOCKED_PASSWD_STRING
2023-09-14 14:46:53 <consus> And that's wrong on Linux
2023-09-14 14:47:00 <consus> Right?
2023-09-14 14:47:28 <minimal> nope, LOCKED_PASSWD_STRING isn't for Linux, LOCKED_PASSWD_PREFIX is for Linux
2023-09-14 14:47:33 <consus> Okay
2023-09-14 14:47:38 <consus> LOCKED_PASSWD_PREFIX is for Linux
2023-09-14 14:47:48 <consus> But we already know that it does not mean *locked account*
2023-09-14 14:47:50 <consus> So
2023-09-14 14:48:09 <minimal> on Linux when passwords are locked they value in /etc/shadow is prefixed with "!" so that they can later be unlocked (i.e. via "passwd -u")
2023-09-14 14:48:11 <consus> Why is it set?
2023-09-14 14:48:22 <consus> Because that's a bug
2023-09-14 14:48:22 <minimal> what is what set?
2023-09-14 14:48:28 <consus> LOCKED_PASSWD_PREFIX
2023-09-14 14:48:34 <consus> It should not be set for Linux
2023-09-14 14:48:41 <consus> Because it does not mean *locked account*
2023-09-14 14:48:51 <minimal> because that defines what is the prefix to indicate a locked password
2023-09-14 14:49:10 <consus> But this function is not called platform_locked_password()
2023-09-14 14:49:20 <consus> This function is called platform_locked_account()
2023-09-14 14:49:24 <minimal> go ask the OpenSSH guys
2023-09-14 14:50:06 <minimal> it's a known issue and only affects Linux distros with PAM disabled in OpenSSH..........which basically only means Alpine and perhaps a few random corner cases
2023-09-14 14:50:11 <consus>         AC_DEFINE([LOCKED_PASSWD_PREFIX], ["!"],
2023-09-14 14:50:19 <consus> But it can be unset in configure, right?
2023-09-14 14:51:07 <consus> So basically the fix is to remove this #ifdef
2023-09-14 14:51:16 <consus> And everything will work as intended
2023-09-14 14:51:38 <consus> Or unset, but of course it's better to remove
2023-09-14 14:55:12 <minimal> it's a known issue and only affects Linux distros with PAM disabled in OpenSSH..........which basically only means Alpine and perhaps a few random corner cases
2023-09-14 14:55:33 <consus> I understand
2023-09-14 14:55:36 <consus> But if that's an issue
2023-09-14 14:55:40 <consus> Why not talk to the devs?
2023-09-14 14:55:59 <consus> I mean you mentioned it, so it must be important, right?
2023-09-14 14:56:41 <minimal> Well (a) I'm not the first person to "discover" this, I found an article from several years back describing it, and (b) OpenSSH devs are OpenBSD devs AFAIK and let's say OpenBSD has a bit of a reputation...
2023-09-14 14:56:54 <minimal> ikke: https://git.alpinelinux.org/aports/tree/community/cloud-init/README.Alpine#n380
2023-09-14 14:57:51 <minimal> consus: for now with cloud-init I (and I believe the tiny-cloud guys also) use a workaround
2023-09-14 14:58:28 <consus> do we have any other login's?
2023-09-14 14:58:35 <consus> busybox, util-linux and shadow
2023-09-14 14:58:37 <consus> anyhing else?
2023-09-14 14:58:49 <minimal> don't think so
2023-09-14 14:59:18 <consus> Cool
2023-09-14 14:59:37 <minimal> well not sure how "login" via GUIs work exactly...
2023-09-14 14:59:48 <consus> shadow uses ! as *locked password*, no one else uses anything 
2023-09-14 15:00:20 <minimal> there must be something used for GUI logins to check for locked passwords
2023-09-14 15:01:03 <consus> pam expiration I guess
2023-09-14 15:01:24 <consus> > GDM uses PAM for login authentication
2023-09-14 15:01:48 <consus> sddm does that same
2023-09-14 15:02:07 <minimal> BB's passwd does support lock/unlock although it describes it as "Lock (disable) account"
2023-09-14 15:02:38 <ikke> It toggles the '!' prefix
2023-09-14 15:02:38 <minimal> whereas Shadow's passwd describes it as "lock the password of the named account"
2023-09-14 15:02:48 <consus> haha
2023-09-14 15:02:50 <consus> classic
2023-09-14 15:03:22 <consus> do you have a link?
2023-09-14 15:03:27 <minimal> ikke: yes, that's the only way lock/unlock could work - if locking replaced the whole password field then how could it later be restored
2023-09-14 15:03:39 <consus> if (pw->pw_passwd[0] == '!' || pw->pw_passwd[0] == '*')
2023-09-14 15:03:40 <consus> goto auth_failed;
2023-09-14 15:03:44 <consus> All I can see is this
2023-09-14 15:04:08 <consus> Which basically works the same as shadow
2023-09-14 15:04:16 <minimal> yeah a password prefix of "*" is a whole different story lol
2023-09-14 15:04:53 <consus> that's an unset password according to the man page
2023-09-14 15:07:15 <consus> Actually
2023-09-14 15:07:18 <consus> Actually
2023-09-14 15:07:31 <minimal> circling all the way back to the original discussion, BB's user tools don't support some of the account management functionality typically used in corporate (or "secure") environments such as password expiry, account expiry etc
2023-09-14 15:07:42 <consus> eh?
2023-09-14 15:07:51 <consus> in corporate environments no one uses local accounts
2023-09-14 15:07:59 <consus> it's AD all the way in
2023-09-14 15:08:26 <minimal> that's one viewpoint
2023-09-14 15:08:40 <consus> Having local accounts that need to be disabled *manually* on *each* server
2023-09-14 15:08:41 <consus> lol
2023-09-14 15:09:00 <consus> That's what people call security disaster
2023-09-14 15:09:18 <minimal> so how do you get remote access to machines then?
2023-09-14 15:09:26 <consus> via ssh
2023-09-14 15:09:56 <minimal> which requires an account to ssh into
2023-09-14 15:10:02 <consus> no it does not
2023-09-14 15:10:05 <consus> nslcd
2023-09-14 15:10:08 <ikke> or sssd
2023-09-14 15:10:09 <minimal> and such an account then likely needs to be defined to prevent password access, etc
2023-09-14 15:10:18 <consus> nope
2023-09-14 15:10:20 <consus> nslcd 
2023-09-14 15:10:25 <consus> and PAM
2023-09-14 15:10:50 <minimal> yes I've used LDAP-based accounts in the past, I'm talking in "generic" terms, not specifically locally defined accounts
2023-09-14 15:11:06 <consus> Yes, you have an account in AD
2023-09-14 15:11:10 <consus> Or LDAP
2023-09-14 15:11:20 <consus> When you lose access it gets disabled
2023-09-14 15:11:23 <minimal> but even then it is not unusual to have at least 1 "break glass" local account
2023-09-14 15:12:19 <consus> Of course, but it's usually root or admin with key-based authentication
2023-09-14 15:12:21 <minimal> e.g. in case there's an issue with AD/LDAP
2023-09-14 15:12:45 <consus> And something mad far password stored in vault
2023-09-14 15:12:46 <minimal> key-based? i.e. OTP?
2023-09-14 15:12:50 <consus> nah, ssh
2023-09-14 15:14:01 <consus> If everything else dead you open vault.example.com and write this crazy line down
2023-09-14 15:14:18 <consus> While getting a cold in the server room
2023-09-14 15:14:44 <minimal> right, so then for a local SSH account you want its password locked and rather than just relies on the OpenSSH config to disable password access (which could mistakenly be changed, i.e. during upgrade) as an additional level of protection you'd want the password locked also
2023-09-14 15:14:51 <consus> why?
2023-09-14 15:14:55 <consus> if it's locked
2023-09-14 15:15:01 <consus> how do you password in
2023-09-14 15:15:04 <minimal> if what is locked?
2023-09-14 15:15:15 <consus> if this account is locked
2023-09-14 15:15:18 <consus> and the net is  dead
2023-09-14 15:15:24 <consus> how do you log in?
2023-09-14 15:15:29 <minimal> if the account is locked or the account's password is locked?
2023-09-14 15:15:33 <consus> password
2023-09-14 15:15:49 <minimal> I was referring to SSH access above
2023-09-14 15:16:10 <consus> Password access is already restricted by ssh itself
2023-09-14 15:16:11 <minimal> not to just rely on the SSH server's config to block password access
2023-09-14 15:16:17 <consus> Sure you can
2023-09-14 15:16:19 <consus> Why not?
2023-09-14 15:16:41 <minimal> did you not see where I mentioned its config being mistakenly changed?
2023-09-14 15:17:05 <consus> Pfft, I can root password to ChangeMe
2023-09-14 15:17:10 <consus> mistakenly
2023-09-14 15:17:22 <consus> Or forget to mistakenly set the expiration date
2023-09-14 15:17:54 <consus> Come on, you write the config, give it SSH CA and forget about all that
2023-09-14 15:17:58 <minimal> its a difference in approach, setting the SSH server's config means "don't let SSH access via passwords"
2023-09-14 15:18:24 <minimal> whereas setting an account's password to locked means "don't let password access via any mechanism"
2023-09-14 15:18:43 <consus> Nobody do that :)
2023-09-14 15:18:51 <consus> At least in corporate
2023-09-14 15:18:55 <minimal> oh? I've had to do it for security audits
2023-09-14 15:19:04 <consus> > security audits
2023-09-14 15:19:16 <consus> :)))
2023-09-14 15:19:21 <consus> Exactly
2023-09-14 15:19:24 <minimal> yes, required before a service could go live and re-audited every year
2023-09-14 15:20:23 <consus> The bottom line is: the account expiration surely has it's uses, but it's as widespread as it was in the 90s
2023-09-14 15:20:39 <consus> And failing scripts are much more common problem
2023-09-14 15:20:56 <consus> That's why I ask ncopa at the first place
2023-09-14 15:21:12 <consus> Because he used the very reasoning
2023-09-14 15:21:29 <minimal> and if you only partly implement a subset of "useradd" etc then some scripts may be fail
2023-09-14 15:21:32 <consus> If you think that account expiration shall be added to the busybox then great!
2023-09-14 15:21:39 <minimal> s/may be fail/may still fail/
2023-09-14 15:21:46 <consus> busybox is all about partial implementation
2023-09-14 15:22:06 <consus> I've yet to see fully function applet
2023-09-14 15:22:12 <consus> For gods sake they have ip :)))
2023-09-14 15:22:33 <consus> ip is a huge monster
2023-09-14 15:22:49 <consus> And they won't *ever* write the same in busybox
2023-09-14 15:23:01 <consus> But it still works 9 of 10 times
2023-09-14 15:23:30 <minimal> as an examp-le, the code I've written (but not yet submitted upstream) for cloud-init fallback to "adduser" etc, it first checks if "useradd" exists - if you produce a limited version of "useradd" then I'd have to add further logic to differenciate between shadow's useradd and the other one and then code around that
2023-09-14 15:25:51 <minimal> and likewise the Ansible support for useradd would have to differenciate in order to handle situations where someone specifies things like "expiry"
2023-09-14 15:26:11 <consus> Feel free to submit expiry then
2023-09-14 15:26:27 <fluix> what's the issue with requiring installing shadow for proper useradd support?
2023-09-14 15:26:56 <consus> busybox missing useradd and groupadd and having non-standard adduser and addgroup
2023-09-14 15:26:56 <minimal> fluix: who's that addressed to?
2023-09-14 15:27:00 <fluix> consus: 
2023-09-14 15:27:33 <consus> we are discussing edge cases of adding support for useradd directly to busybox
2023-09-14 15:27:37 <fluix> I think I agree with minimal here, adding another non-standard {user,group}add to busybox is a bad idea
2023-09-14 15:27:41 <fluix> I know, but why
2023-09-14 15:27:49 <fluix> isn't adduser already just a limited useradd?
2023-09-14 15:28:01 <consus> mostly for the scripts
2023-09-14 15:28:13 <fluix> right, so what's wrong with requiring users install shadow if they use a script depending on useradd
2023-09-14 15:29:46 <fluix> now scripts which use the full functionality are all going to have to either add checks or say "go get a proper useradd" which brings you back to the same place you were in the first place (sure, some minimal scripts will function fine, but only by chance)
2023-09-14 15:29:47 <consus> if busybox has tools to add users it can have standard tools to add users
2023-09-14 15:30:04 <fluix> but you're proposing implementing *non*-standard useradd and groupadd
2023-09-14 15:30:30 <consus> nah, I'm proposing to implement most of the keys and add missing pieces later
2023-09-14 15:30:45 <consus> Because having all of it in one PR may be too much 
2023-09-14 15:30:47 <fluix> so non-standard for now, with plans for standard eventually
2023-09-14 15:30:52 <consus> aha
2023-09-14 15:31:12 <fluix> so people will do what? implement checks for non-standard useradd for now? this sounds like a pain
2023-09-14 15:31:19 <consus> same as now
2023-09-14 15:31:20 <fluix> unless you don't do a busybox release until it's all in
2023-09-14 15:31:24 <consus> if it does not work install shadow
2023-09-14 15:31:31 <consus> nothing really changes
2023-09-14 15:31:33 <fluix> not same as now, because now people just check for useradd like minimal said
2023-09-14 15:32:02 <consus> if useradd -> busybox?
2023-09-14 15:32:13 <consus> dunno
2023-09-14 15:32:17 <fluix> if useradd -> use it, if adduser -> do something else
2023-09-14 15:32:27 <consus> It seems weird to have tools that noone uses
2023-09-14 15:32:36 <fluix> what?
2023-09-14 15:32:49 <minimal> which tools no-one uses?
2023-09-14 15:32:51 <consus> since you can't rely on adduser
2023-09-14 15:32:56 <consus> and you need to install shadow
2023-09-14 15:33:03 <fluix> but you can... I do it all the time as a user
2023-09-14 15:33:05 <consus> it's easier just to install shadow and use ity
2023-09-14 15:33:16 <consus> so... why not have proper useradd then? :D
2023-09-14 15:33:26 <fluix> I don't think anyone is against *proper* useradd
2023-09-14 15:33:48 <consus> if you think the applet is not yet "good enough" it can always be disabled, nah?
2023-09-14 15:33:55 <fluix> you're proposing non-proper useradd with proper useradd at some later point. if you do this before a release of busybox so you don't have non-proper useradd ever released, that sounds fine. otherwise, it's a pain for everyone
2023-09-14 15:33:57 <minimal> yes, it is that intermediate period where there's a new useradd without all the expected functionality that is the issue
2023-09-14 15:34:05 <consus> But in order to get there we have to start somewhere
2023-09-14 15:34:44 <fluix> yes, that's fine of course, I just hope there's no release with non-standard useradd
2023-09-14 15:35:14 <fluix> so if you propose an incomplete version and that's fine, finish it (or have someone else work with you, you aren't obligated to do anything of course :D) before getting it merged
2023-09-14 15:35:17 <fluix> ^ is my suggestion, at least
2023-09-14 15:35:23 <consus> That's not up to mee
2023-09-14 15:35:29 <consus> That's up for the busybox maintainers
2023-09-14 15:35:43 <fluix> you have some control, as the one contributing the patch, to bring up these issues
2023-09-14 15:36:04 <fluix> just like we do, to discuss it with you
2023-09-14 15:36:05 <consus> Bringing huge ass patch that touch also login and other tools?
2023-09-14 15:36:24 <consus> I'm not sure that they will merge it
2023-09-14 15:36:24 <fluix> hm? why does it need to touch those?
2023-09-14 15:36:33 <consus> :))
2023-09-14 15:36:42 <consus> Because busybox does not have expiry for example
2023-09-14 15:36:50 <consus> As minimal mentioned
2023-09-14 15:37:09 <fluix> can you not have the other tools continue to ignore it for now?
2023-09-14 15:37:12 <fluix> also you can split patches
2023-09-14 15:37:19 <consus> of course I can
2023-09-14 15:37:27 <consus> Let me rephrase it
2023-09-14 15:37:48 <consus> Bringing huse ass patch series is harder than bringing small pieces
2023-09-14 15:38:34 <fluix> of course, we're just expressing our opinion that merging and releasing the small pieces on its own would be bad, and hope that you take into account those concerns
2023-09-14 15:39:20 <consus> the applet can be disabled by default until it gets into shape
2023-09-14 15:39:26 <consus> AFAIR busybox has plenty
2023-09-14 15:39:41 <fluix> whether that means implementing it fully and putting in more work to get it merged or just sending the small patches that also outline these concerns, or what you just mentioned (I did not know busybox ships with a default)
2023-09-14 15:40:14 <consus> their Kconfig-like thingy ought to have the default state
2023-09-14 15:40:25 <consus> I'll check
2023-09-14 15:41:05 <fluix> thinking out loud here: if you need to recompile busybox to enable it or install a busybox-extras-useradd package for it, how is that different from just installing shadow? I guess it's so that eventually you don't need to because eventually it will be fully compatible?
2023-09-14 15:41:49 <minimal> fluix: well in that scenario it would be smaller (i.e. likely not having PAM enabled)
2023-09-14 15:42:10 <minimal> whereas shadow drags in PAM
2023-09-14 16:02:54 <consus> hmm
2023-09-14 16:03:25 <consus> last works on alpine?
2023-09-14 16:03:36 <consus> util-linux-login has both last and lastb
2023-09-14 16:08:19 <minimal> consus: last relies on utmps being installed and enabled
2023-09-14 16:08:31 <consus> oh, sweet
2023-09-14 16:08:38 <consus> I vaguely remember something about that
2023-09-14 16:08:40 <minimal> actualyl both last and lastb do
2023-09-14 16:09:12 <minimal> consus: A bit out of date, but for reference: https://github.com/dermotbradley/alpine-misc-notes/blob/main/utmp-status.md
2023-09-14 16:09:23 <consus> https://skarnet.org/software/utmps/
2023-09-14 16:09:27 <consus> this one, right?
2023-09-14 16:09:49 <minimal> it's already packaged for Alpine
2023-09-14 16:10:13 <minimal> so you need to add it, enable its init.d services and then have other utmp-enabled apps/utils installed
2023-09-14 16:10:29 <consus> ah
2023-09-14 16:10:29 <consus> s6
2023-09-14 16:10:33 <consus> lol, nah
2023-09-14 16:11:00 <minimal> eh? it is not using s6 for init
2023-09-14 16:11:12 <consus> weird, it reference s6 as a run-time requirements
2023-09-14 16:11:39 <minimal> that doesn't mean it is using s6 for init
2023-09-14 16:11:49 <minimal> it is using s6-ipcserver and some other stuff
2023-09-14 16:11:59 <consus> aah
2023-09-14 16:12:02 <consus> stil nah
2023-09-14 16:12:15 <consus> I don't like s6
2023-09-14 16:12:16 <minimal> that's the only way to get UTMP support on Alpine as musl does not have UTMP functionality at all
2023-09-14 16:12:18 <consus> It's creepy
2023-09-14 16:12:24 <consus> Yeah, I know
2023-09-14 16:12:28 <consus> That's why I asked
2023-09-14 16:12:36 <minimal> creepy?
2023-09-14 16:12:42 <consus> It's author is creepy
2023-09-14 16:13:08 <consus> I'm trying not to touch his software if possible
2023-09-14 16:13:47 <skarnet> good, please stay as far away from it as possible
2023-09-14 16:13:57 <consus> I glad we understand each other
2023-09-14 16:14:09 <skarnet> it will stalk your wife and bully your kids
2023-09-14 16:14:15 <skarnet> and steal their lunch money
2023-09-14 16:14:18 <skarnet> it's evil
2023-09-14 16:14:38 <consus> Yeah, this
2023-09-14 16:14:40 <consus> This is why
2023-09-14 16:14:42 <consus> :D
2023-09-14 16:15:30 <skarnet> in any case if you want utmp to work you'll have to deal with it
2023-09-14 16:15:36 <consus> Okay, so basically, the consensus is that fully functionaal useradd is a good idea
2023-09-14 16:15:50 <consus> The half-finished will create additional maintainer burden
2023-09-14 16:16:13 <consus> And no ones wants that
2023-09-14 16:38:46 <chereskata> i am working on patching / finding out why protobuf revdeps would not compile any more: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51119
2023-09-14 16:38:59 <chereskata> contributions welcome
2023-09-14 18:04:35 <chereskata> current community/plantuml has multiple critical CVEs https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50073
2023-09-14 18:04:56 <chereskata> it is java based
2023-09-14 18:05:15 <chereskata> jdk 17 has some problems inside the gitlab ci runners
2023-09-14 18:05:29 <chereskata> on x86_64 it compiles without problems
2023-09-14 18:05:33 <chereskata> what do we do?
2023-09-14 18:07:59 <chereskata> similar issue https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/179072
2023-09-14 21:51:15 <omni> *sigh* too optimistic
2023-09-14 21:51:20 <omni> what did I do?
2023-09-15 00:16:52 <RootWyrm> I have a bit of an odd request... anyone here work with fonts regularly? I don't know the first thing about 'from source' for them, and was hoping someone could add https://github.com/polarsys/b612 (SIL Open Font licensed)
2023-09-15 06:18:04 <ncopa> RootWyrm: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51618
2023-09-15 09:54:10 <omni> I think it's this https://invent.kde.org/qt/qt/qtwebengine-chromium/-/commit/3bf928ef51c9ef418de17bc7c4d9ac49e that somehow makes the qtwebengine-chromium build fail
2023-09-15 09:56:04 <omni> hope I didn't speak too soon
2023-09-15 10:01:35 <omni> no, something else
2023-09-15 10:55:10 <omni> ok, no, it's this https://invent.kde.org/qt/qt/qtwebengine-chromium/-/commit/053835946c48a135b86e28b37f8ff127cbea1210 ??
2023-09-15 12:20:44 <Habbie> how long after an aports merge should i expect 'apk add' to notice?
2023-09-15 12:21:52 <Habbie> (3.18, if it matters)
2023-09-15 12:47:08 <Habbie> is https://lists.alpinelinux.org/~alpine/security-announcements supposed to be empty?
2023-09-15 12:48:25 <zcrayfish> Dunno, but with a last updated date of 2 years ago, it wouldn't be helpful in any case.
2023-09-15 12:49:14 <Habbie> well, that suggests nothing was posted to it, which raises the question - what is it for
2023-09-15 12:51:35 <Habbie> ah, there is my bumped dnsdist in 3.18
2023-09-15 12:56:46 <ikke> Habbie: after the builders are ready, it takes up to 15 minutes to appear on the primary mirrors 
2023-09-15 12:57:21 <Habbie> right, so pretty automatic
2023-09-15 13:06:01 <omni> automatic and pretty
2023-09-15 13:06:18 <Habbie> :)
2023-09-15 13:06:21 <Habbie> thanks for the merge, omni
2023-09-15 13:06:47 <omni> np =)
2023-09-15 13:12:58 <omni> HRio: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/py3-nats/py3-nats-2.4.0-r0.log
2023-09-15 13:19:12 <HRio> omni: weird OK in gitlab https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1113351
2023-09-15 13:19:53 <HRio> and also in "normal build" on other targets https://pkgs.alpinelinux.org/packages?name=py3-nats&branch=edge&repo=&arch=&maintainer=
2023-09-15 13:21:31 <omni> yeah, idk
2023-09-15 13:30:54 <RootWyrm> ncopa: oh awesome, thank you so much!!
2023-09-15 13:34:32 <HRio> omni: disabled that test for now
2023-09-15 16:59:30 <omni> aarch64 builder stuck?
2023-09-15 17:29:25 <ikke> omni: it was, killed the process
2023-09-15 17:31:16 <omni> ikke: so it was stuck on a mozjs test?
2023-09-15 17:32:58 <ikke> yes
2023-09-15 22:09:55 <omni> wrt the recently opened "logs for <x> permanently accumulates" issues, isn't this where you install and configure something like logrotate or am I missing something here?
2023-09-15 22:11:06 <minimal> omni: I think he is pointing out that the various packages do not themselves come with logrotate config files
2023-09-15 22:11:55 <minimal> fyi: he's in the alpine-linux channel
2023-09-15 22:15:08 <omni> right
2023-09-15 22:15:39 <skarnet> obligatory mention that logrotate does not solve the issue of disk filling between two logrotate invocations, and that the only solution is an auto-rotating logger
2023-09-15 23:26:44 <omni> should there be a -logrotate sub-package?
2023-09-15 23:28:31 <minimal> omni: for what reason?
2023-09-15 23:29:40 <minimal> to save a few bytes by avoiding having a logrotate config in a main package?
2023-09-15 23:30:35 <omni> yeah, like shell completion sub-packages
2023-09-15 23:30:51 <omni> and not have a /etc/logrotate.d and expecting it to be used when it isn't
2023-09-15 23:31:00 <omni> idk, just a thought
2023-09-15 23:31:40 <minimal> it would certainly make things obvious when a package supports logrotate
2023-09-15 23:34:46 <minimal> with an "install_if" so that installing logrotate would then auto-install any required logrotate subpackages
2023-09-15 23:36:07 <omni> yeah
2023-09-15 23:57:00 <omni> ptrc: I think at least one of these would be needed for coeurl to build https://nheko.im/nheko-reborn/coeurl/-/commits/master 
2023-09-16 00:04:17 <somercet1> I see Taner Tas is in charge of deadbeef music player. It's missing a few features I would like to help enable, like the pipewire output plugin. Is he/she here?
2023-09-16 01:06:30 <celie> omni: Perhaps you can add fmt-dev to makedepends of coeurl so it can be found easier during the next fmt rebuild
2023-09-16 01:16:28 <omni> celie: do you think that is why it wasn't part of the major rebuild against fmt 10?
2023-09-16 01:20:11 <celie> Very likely, i think rebuilds are usually found through looking for the -dev subpackage in makedepends, i added fmt-dev to gr-funcube in !51575, and was meaning to add fmt-dev to coeurl in my libsodium rebuild but didn't want to interrupt the 3+ hour pipeline (though it looks like i'll have to rebase now ;))
2023-09-16 01:22:04 <celie> If fmt-dev is already installed according to build logs, perhaps adding it to makedepends explicitly wouldn't require a pkgrel bump
2023-09-16 01:52:27 <omni> but it's not just coeurl, right?
2023-09-16 01:52:50 <omni> I'm sorry, I need to drop this now, I'm just making sloppy mistakes
2023-09-16 01:53:18 <omni> the last patch I added to nheko failed to apply
2023-09-16 01:54:24 <celie> Yeah, there are probably other aports needing rebuilds against fmt that don't have fmt-dev in their makedepends
2023-09-16 01:54:53 <omni> perhaps it would be easiest to just fetch a tar-ball of the latest state of the nheko repo to make it build
2023-09-16 01:56:10 <omni> but it won't build on the gitlab CI builders since they need the rebuilt coeurl and mtclient packages that aren't available outside the main builders since they're blocked by the nheko aport
2023-09-16 01:56:21 <omni> mtxclient*
2023-09-16 01:57:07 <celie> I'm not sure i get what you mean by that
2023-09-16 01:57:41 <celie> I was able to (re)build coeurl and mtxclient in my libsodium MR without nheko
2023-09-16 01:58:30 <omni> compare https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1113996
2023-09-16 01:58:52 <omni> to https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/nheko/nheko-0.11.3-r5.log
2023-09-16 02:00:43 <omni> celie: I meant the other way around
2023-09-16 02:03:43 <omni> I'm not getting smarter by the minute now so I need to take a step back
2023-09-16 02:03:55 <omni> maybe someone else will sort this out
2023-09-16 02:04:38 <celie> Ah, the rebuilt coeurl and mtxclient haven't hit the mirrors so the CI builders can't use them...perhaps i should have made a separate MR for coeurl and mtxclient or brought it up so others can take note of that when i found they needed rebuilding in my libsodium MR...sorry
2023-09-16 02:13:01 <celie> Ok, now i see, the only archs that have the rebuilt coeurl and mtxclient are armhf and riscv64, which nheko is not enabled for...maybe you can just revert the nheko pkgrel bump so the builders are not blocked on that and get build coeurl and mtxclient
2023-09-16 02:14:14 <celie> Then when the CI builders can use those 2 aports, you can try fixing nheko again
2023-09-16 02:14:51 <celie> s/get build/can build/
2023-09-16 02:20:10 <celie> Maybe you don't need to revert all the nheko commits to unblock the builders, just the one that bumps pkgrel
2023-09-16 06:22:55 <fluix> man people are fast haha. I get MRs to bump my packages before Anitya even sends me emails :p
2023-09-16 09:55:37 <omni> would unbumping smplxmpp unblock builders?
2023-09-16 10:29:37 <omni> yes
2023-09-16 10:53:06 <ikke> omni: celie had a fix as an MR
2023-09-16 11:06:12 <omni> yeah, I saw that just now
2023-09-16 11:49:08 <omni> I think !51664 looks ok but I may have missed something and it's also protected so I cannot rebase
2023-09-16 11:50:24 <ikke> unprotected the branch
2023-09-16 11:50:55 <ikke> export GOFLAGS="$GOFLAGS -modcacherw"
2023-09-16 12:00:42 <omni> thanks
2023-09-16 12:00:49 <omni> also for commenting
2023-09-16 14:02:39 <celie> Isn't -modcacherw already in /usr/share/abuild/default.conf?
2023-09-16 14:11:59 <ikke> Oh was it
2023-09-16 14:12:17 <ikke> As I still had issues locally when it was not set
2023-09-16 14:18:06 <ikke> celie: regarding smplxmpp, I don't think it matters that much what the result was, as it would just affect trace debugging 
2023-09-16 14:47:41 <celie> Ok
2023-09-17 03:29:27 <fluix> if there's no soname differences, then should revdeps still be tested?
2023-09-17 12:39:02 <chereskata> Hi, what is the state of gnome 45 upgrade?
2023-09-17 19:21:23 <filoozom> Hey, has anyone played with Alpine on RK3558?
2023-09-17 19:22:17 <Ermine> Was full kernel support for RK3558 mainlined already?
2023-09-17 19:29:54 <filoozom> Hmm, good question :p
2023-09-18 00:03:43 <RootWyrm> I don't think so. It's on my todo after I can get an RK3558.
2023-09-18 13:36:21 <ptrc> perhaps there should also be some links to Matrix on https://alpinelinux.org/community/, and a more explicit description how to connect to OFTC rather than just a link?
2023-09-18 13:36:45 <fubogini> How to create a merge request to add a package?
2023-09-18 13:37:11 <ptrc> fubogini: hiya! once you create an account on https://gitlab.alpinelinux.org/, you can fork the aports repo ( https://gitlab.alpinelinux.org/alpine/aports )
2023-09-18 13:38:09 <quinq> ptrc, how to use *an* IRC client is outside the target of the Alpine wiki I think
2023-09-18 13:38:14 <ptrc> when you make your changes and push them to your fork, you should get a pop-up on gitlab like this: https://ptrc.gay/gFcncOkG
2023-09-18 13:38:26 <quinq> There could be a link to OFTC though, where documentation can be found
2023-09-18 13:38:41 <ptrc> quinq: if someone doesn't have an irc scheme handler, they don't even get the OFTC server address unless they copy the URL manually and extract the info from that
2023-09-18 13:38:59 <quinq> That depends
2023-09-18 13:39:09 <quinq> My web browsers shows me the underlying link
2023-09-18 13:40:01 <ptrc> i mean, yeah, but if you're not on OFTC, you have to copy the link, paste it into some text field, copy the server address section, etc.
2023-09-18 13:40:22 <ptrc> i just feel like it could be made a bit more intuitive
2023-09-18 13:41:17 <quinq> It's only intuitive if you know how to configure your IRC client, but again, I suppose a link to OFTC saying “on OFTC” wouldn't hurt
2023-09-18 14:02:59 <eletrotupi> I agree with ptrc, we shouldn't make difficult for people to get on board, maybe just add a link to the webchat?
2023-09-18 14:03:20 <ptrc> hm, does OFTC even have a webchat?
2023-09-18 14:03:44 <eletrotupi> ttps://www.oftc.net/WebChat/
2023-09-18 14:03:44 <Habbie> it does
2023-09-18 14:03:52 <eletrotupi> oh, missed a h there for some reason
2023-09-18 14:03:57 <eletrotupi> https://www.oftc.net/WebChat/
2023-09-18 14:04:46 <eletrotupi> a link like this might do it: https://webchat.oftc.net/?channels=#alpine-linux
2023-09-18 14:13:15 <chereskata> where should pkgconfigs go? /usr/lib/pkgconfig or /usr/share/pkgconfig?
2023-09-18 14:19:21 <eletrotupi> chereskata: pkgconfigdir=/usr/lib/pkgconfig
2023-09-18 14:19:49 <eletrotupi> most of pkgconfigs seems to be going into this directory (I've run git grep pkgconfig on aports source)
2023-09-18 14:20:33 <eletrotupi> there is far less packages installing on /usr/share
2023-09-18 14:21:53 <indy> ncopa, hi, i have issue with gcc, looks like 12.3.0 contains fix for that. i saw 12.1.1 -> 12.2.1 update, but is this pattern, or just coincidence? :) i mean would be objections against update to 12.3.0 for stable-3.18?
2023-09-18 14:24:13 <indy> ncopa, i'm playing with particular patch against 12.2.1, if it is real cause of build failures
2023-09-18 14:41:41 <ncopa> indy: do you have an URL to the issue?
2023-09-18 14:42:27 <ncopa> i dont think there would be any objection for 12.3.0
2023-09-18 14:42:39 <indy> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
2023-09-18 14:43:40 <indy> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2e4210698c644e44f9e0645dc7bc49710fd60ce8 is fix, our build pipelines are back
2023-09-18 14:43:54 <indy> with just that cherry picked
2023-09-18 14:44:18 <indy> but i assume 12.3.0 will incorporate more fixes
2023-09-18 14:47:02 <ncopa> create an issue with that info. I think we could bump gcc to 12.3
2023-09-18 14:56:34 <indy> https://gitlab.alpinelinux.org/alpine/aports/-/issues/15278
2023-09-18 15:21:52 <chereskata> eletrotupi: thanks!
2023-09-18 15:22:46 <ikke> chereskata: you asked about gnome 45 yesterday: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15228
2023-09-18 15:23:10 <chereskata> I know, thanks
2023-09-18 15:23:13 <ikke> ok
2023-09-18 15:23:24 <chereskata> maybe there was some undocumented progress or so
2023-09-18 15:23:27 <chereskata> wanted to be sure
2023-09-18 16:15:06 <indy> ncopa, what is workflow to make such release archive?
2023-09-18 17:24:27 <fubogini> How quickly are merge requests accepted or rejected?
2023-09-18 17:26:11 <ikke> simple / straightforward merge requests are merged pretty quickly (usually within a day)
2023-09-18 20:01:17 <chereskata> gitlab is offline
2023-09-18 20:01:20 <chereskata> just me?
2023-09-18 20:01:28 <chereskata> (bad gateway)
2023-09-18 20:01:55 <ikke> chereskata: security upgrade
2023-09-18 20:01:56 <chereskata> ah i see on alpine-infora
2023-09-18 20:01:58 <chereskata> sorry
2023-09-18 20:02:10 <ikke> it should be back shortly
2023-09-18 20:03:55 <ikke> chereskata: it's back
2023-09-18 20:07:27 <chereskata> perfect, thanks
2023-09-18 20:23:20 <chereskata> could someone merge MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51826 ?
2023-09-18 20:27:23 <ikke> chereskata: does this support buildtype MinSizeRel?
2023-09-18 20:27:38 <ikke> "buildtype         : plain"
2023-09-18 20:28:41 <chereskata> unfortunately i do not know what this buildtype is about 
2023-09-18 20:30:39 <ikke> Sets the alpine default build option for -Os
2023-09-18 20:31:20 <ikke> chereskata: -DBUILD_TYPE=MinSizeRel if it's supported
2023-09-18 20:32:14 <chereskata> thanks, ill try in a moment
2023-09-18 20:34:04 <chereskata> ikke: meson.build:1:0: ERROR: Unknown options: "BUILD_TYPE"
2023-09-18 20:34:53 <ikke> Ok
2023-09-18 20:36:58 <ikke> ah, it's for cmake, not for meson
2023-09-18 20:37:32 <ikke> merged
2023-09-18 20:42:08 <chereskata> thanks
2023-09-18 20:42:27 <chereskata> some packages put their pkgconfig into /usr/share
2023-09-18 20:42:48 <chereskata> here is a find / | grep pkgconfig excerpt from my machine:
2023-09-18 20:43:18 <chereskata> \/usr/share/pkgconfig/shared-mime-info.pc
2023-09-18 20:43:27 <chereskata>  /usr/share/pkgconfig/mobile-broadband-provider-info.pc
2023-09-18 22:18:23 <chereskata> could someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51605
2023-09-18 22:18:34 <chereskata> it seems to be needed to upgrade protobuf
2023-09-18 22:26:49 <pj> the other way around?
2023-09-18 22:34:51 <chereskata> why do you think so? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51119
2023-09-18 22:36:35 <chereskata> there is a typo in main/vala/APKBUILD: # Maintainter: Natanael Copa <ncopa@alpinelinux.org>
2023-09-18 22:37:05 <chereskata> I think this is in multiple files
2023-09-18 22:42:52 <ptrc> oh, good catch
2023-09-18 22:42:57 <ptrc> 7 files in total
2023-09-18 22:43:00 <ptrc> all with the same typo
2023-09-18 22:44:53 <ptrc> aaaand only now, after pushing to master, i realised that a rebuild of some of those might fail
2023-09-18 22:44:57 <ptrc> welp
2023-09-18 22:45:18 <chereskata> could you push after the core gnome upgrade has been merged?
2023-09-18 22:45:32 <ptrc> that ship has sailed already
2023-09-18 22:47:20 <ptrc> tbh that doesn't really matter
2023-09-18 22:47:37 <ptrc> because if a rebuild of something in main/ would fail, it would have to be fixed anyway before the next release
2023-09-18 22:47:43 <ptrc> so i guess it's better to catch those early
2023-09-18 22:47:47 <chereskata> thats correct
2023-09-18 22:48:04 <pj> chereskata: because the build failure is just a simple sed to remove mut keyword
2023-09-18 22:48:36 <chereskata> failure of what package?
2023-09-19 08:35:06 <chereskata> could someone please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51820, so i can continue with upgrading gnome 45
2023-09-19 09:26:34 <celie> Can someone running Alpine on armhf or armv7 try to build https://gitlab.alpinelinux.org/Celeste/aports/-/raw/81e44ae08/main/curl/APKBUILD ?
2023-09-19 09:27:28 <celie> It is the APKBUILD from !51528 with check() modified to only run test 650, which the Gitlab CI is having trouble with
2023-09-19 09:31:00 <ncopa> ugh... sorry about the typo
2023-09-19 11:21:44 <ptrc> celie: fails for me as well: https://ptrc.gay/ZOXnIQMZ
2023-09-19 12:12:14 <celie> ptrc: Thanks for trying that
2023-09-19 12:20:48 <minimal> I'm trying to build the Grub package locally and it is failing. Comparing the build log with the one for the packaged Grub (which dates from 24th May) I see that different flags are being used for the compilation, specificaly "-fno-plt" is currently being used which appears to cause problems for grub modules
2023-09-19 12:20:55 <celie> It seems you managed to get further in the test compared to the CI, the test http server gets the /6500002 POST request, unlike the CI, where it did not...but it's still weird that armhf and armv7 are the only architectures where this tests fails
2023-09-19 12:21:06 <minimal> I don't see "-fno-plt" being defined by abuild however so I don't know where this is coming from
2023-09-19 12:25:16 <celie> I see "-fno-plt" in /usr/share/abuild/default.conf
2023-09-19 12:45:36 <minimal> celie: I'm not seeing that in the abuild source: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/default.conf
2023-09-19 12:46:45 <minimal> ah, it's in the APKBUILD...
2023-09-19 12:47:26 <minimal> so that was added on 5th June....after the last time the Grub package was built
2023-09-19 12:48:18 <minimal> sorry, on 3rd for June (for both x86 & x86_64 and then changed on 5th to be x86_64 only)
2023-09-19 12:51:01 <minimal> so what would be the typical way to remove an entry from CFLAGS in either a APKBUILD file or in a Makefile?
2023-09-19 12:53:20 <ikke> CFLAGS="${CFLAGS/-fno-plt/}"
2023-09-19 12:53:39 <minimal> ikke: thanks, I'll try that
2023-09-19 12:53:54 <ikke> Don't forget to export 
2023-09-19 13:12:58 <minimal> ok, that built ok when "-fno-plt" was removed. The next question is whether to only remove it for grub-bios (as grub-efi built fine with that present)
2023-09-19 13:50:31 <j_v> recent upgrade of clamav causes a glitch in clamd.initd. the sed in clamav APKBUILD package() function causes 2 lines of LocalSocket in /etc/clamav/clamd.conf. this causes $socket variable in clamd.initd's start_pre have two lines instead of one, which causes the $socketdir to equate to full path of the first line, causing the socketdir to be the same as the socket path,
2023-09-19 13:50:32 <j_v> breaking clamd startup
2023-09-19 13:52:55 <j_v> upstream change of $srcdir/etc/clamd.conf.example has two lines with commented example LocalSocket definitions instead of two, so the sed in APKBUILD package() uncomments and transforms both lines
2023-09-19 13:58:40 <j_v> is better fix to modify the sed in the APKBUILD package function or force the awk in clamav.initd to exit after first print, ie socket=`awk '$1 == "LocalSocket" { print $1 ; exit } $CONF` ?
2023-09-19 14:02:21 <j_v> I should just submit a draft MR, sorry for the noise
2023-09-19 14:10:59 <chereskata> Here is a cool MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51877. It needs some shellscripting and admin knowledge: concretely: is var/cache/misc appropriate to save a backlight state and if so, is the parent directory always exsistant per default?
2023-09-19 14:28:49 <durrendal> yes it should be there by default. At least it is in a completely new lxd container
2023-09-19 14:28:54 <fluix> would /var/local/ make more sense, or something in /run/? cache doesn't feel like quite the right place
2023-09-19 14:29:43 <fluix> or even just /var/lib/, that's what community/unit uses
2023-09-19 14:31:11 <ikke> /var/lib would make more sense to me as well
2023-09-19 14:31:34 <chereskata> fluix: good question, i would say that /var/lib/ sounds sensible. I would definitely rule out /run/, because it is tmpfs and we need reboot persistant state. /var/local/ is unused on my system
2023-09-19 14:31:47 <fluix> yeah wasn't sure if /run/ was ephemral
2023-09-19 14:32:04 <ikke> It is, and should only be used for runtime state 
2023-09-19 14:37:37 <chereskata> thank you all
2023-09-19 14:41:34 <chereskata> could someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51407
2023-09-19 14:52:25 <ptrc> chereskata: it not only wasn't approved yet, but you have an unanswered question on it :p
2023-09-19 14:52:37 <fluix> I just asked that :p
2023-09-19 14:52:52 <fluix> but yes, it's mainly waiting for the maintainer approval
2023-09-19 14:53:20 <fluix> also it's technically a minor release, not major
2023-09-19 15:07:25 <chereskata> did not see
2023-09-19 15:11:41 <j_v> can some one take a look at !51885 if get a chance? wondering if I am on the right track
2023-09-19 15:12:12 <chereskata> is there a way to do it without cat? brightnessctl -q s `cat $save_file`
2023-09-19 15:13:46 <ikke> j_v: I wonder whether it's not better to use a patch file instead of these sed statements
2023-09-19 15:14:41 <j_v> ikke: that is a good point and seems appropriate to my worry about the longevity of the sed... thank you
2023-09-19 16:53:24 <j_v> ikke: i thought about it and decided to replace the sed statements with a patch in new MR !51893. Thanks for your input.
2023-09-19 17:11:01 <ikke> j_v: looks good to me
2023-09-19 17:21:03 <j_v> ikke: thanks
2023-09-20 03:30:46 <elly> fyi, I'm still basically stuck on community/chromium - the new rust stuff in 116+ is challenging
2023-09-20 04:13:24 <elly> even with rust disabled further fixes are still needed, unfortunately
2023-09-20 04:18:34 <elly> here's a question... chromium 117 requires re2 newer than what is present in 3.18
2023-09-20 04:18:50 <elly> is it legit to update re2 in 3.18, or should I patch around this in chromium?
2023-09-20 04:33:39 <Arnavion> Just be careful that chromium 115 should not be compiled with re2 newer than 2023-06-01, otherwise it'll segfault. re2 changes its API in that release and only chromium 116.0.5803.0 onwards handle it
2023-09-20 04:45:42 <ikke> That also seems to imply that we cannot update re2 in 3.18
2023-09-20 06:33:01 <bratkartoffel> I've got issues building an docker image on out gitlab runner due to apk errors ("temporary error"). Locally it builds fine and curl'ing the APKINDEX from the server is also good. Is there an option for apk to be more verbose? Using the verbose flag like "apk add --no-cache -vv jq" did not provide any further information.
2023-09-20 06:37:49 <bratkartoffel> job log: https://tpaste.us/QRqE
2023-09-20 07:01:55 <ikke> Temporary error means some kind of network error. Afaik there is not a way to let apk give more details 
2023-09-20 07:02:51 <ikke> Most of the time, it means the dns record could not be resolved 
2023-09-20 07:27:53 <Arnavion> ikke: Right, either update only chromium, or both re2 and chromium, but not only re2
2023-09-20 07:28:30 <Arnavion> If you really want to update only re2 you can backport the chromium commit that supports the API change
2023-09-20 07:29:20 <Arnavion> (See   https://bugzilla.opensuse.org/show_bug.cgi?id=1214003   for details)
2023-09-20 07:32:21 <ikke> I meant not just regarding chromium 
2023-09-20 07:33:16 <Arnavion> True. At least in opensuse the only thing that noticeably broke was chromium, but there could've been others that nobody noticed
2023-09-20 08:53:52 <fubogini> Is anyone ready to become a maintainer of the sing-box package?
2023-09-20 10:19:42 <omni> are the CI arm builders sad?
2023-09-20 10:20:03 <ikke> yes, saw notifications from zabbix
2023-09-20 10:23:58 <ikke> omni: I've enabled the backup runners now
2023-09-20 10:45:15 <omni> ikke: currently interested in armhf and aarch64 and they don't seem to work
2023-09-20 10:45:31 <omni> arm* pending and aarch64 maybe networking issues?
2023-09-20 10:48:19 <ikke> Sorry, didn't enable to correct runners
2023-09-20 10:52:24 <bratkartoffel> can someone please merge !48752?
2023-09-20 10:57:19 <chereskata> can someone please merge !51820?
2023-09-20 10:57:56 <ptrc> PabloCorreaGomez[m]: is that ^ ready to merge?
2023-09-20 11:12:23 <chereskata> i need to install gradle, depending on jdk17. Can i force replace jdk17 with jdk8 to not download both on compile time?
2023-09-20 11:12:43 <chereskata> (APKBUILD context)
2023-09-20 11:19:31 <PabloCorreaGomez[m]> ptrc: appart from your comments, and the small nit I have, i
2023-09-20 11:19:40 <PabloCorreaGomez[m]> it's all good to go, I think
2023-09-20 11:19:56 <ptrc> chereskata: i'm pretty sure gradle won't work with 8
2023-09-20 11:19:59 <ptrc> *might* work with 11
2023-09-20 11:23:18 <bratkartoffel> chereskata: i think gradle should not depend on an specific jdk version, instead the aport should have a depends="java-jdk", maybe a "java-jdk>=11"
2023-09-20 11:23:52 <ptrc> see 5dca1eef7290debe69ef77666522e1aeb3426100
2023-09-20 11:24:36 <bratkartoffel> do you still know why you changed this?
2023-09-20 11:25:14 <ptrc> it was not me who changed it :p but i'm looking for it right now, i remember it made sense at the time
2023-09-20 11:27:17 <chereskata> https://pkgs.alpinelinux.org/package/edge/community/x86/gradle - depends on jdk8
2023-09-20 11:27:37 <ptrc> because it's 32-bit
2023-09-20 11:27:41 <ptrc> anyway
2023-09-20 11:27:50 <ptrc> gradle didn't depend on java-jdk, because you can't specify the version
2023-09-20 11:28:36 <chereskata> the idea was this: !50073 fails to build with jdk17 on x86_64 and aarch64. So i thought i can replace jdk17 with jdk8 and try again
2023-09-20 11:30:00 <pj> Gradle supports only Java 18 for 7.5
2023-09-20 11:31:24 <ptrc> yeah, and it was added for gradle 7.5.1
2023-09-20 11:31:28 <ptrc> don't see the relevance
2023-09-20 11:31:39 <ptrc> oh, you mean
2023-09-20 11:31:54 <ptrc> ...right, so it shouldnuse Java 8 *at all*
2023-09-20 11:32:03 <ptrc> s/shouldnuse/shouldn't use/
2023-09-20 11:34:35 <pj> apparently
2023-09-20 11:34:43 <pj> https://docs.gradle.org/current/userguide/compatibility.html#compatibility
2023-09-20 11:35:31 <ptrc> i mean, it works just fine for building stuff like java-postgresql-jdbc
2023-09-20 11:38:01 <pj> the keyword is "supports"
2023-09-20 11:49:51 <bratkartoffel> pj: gradle can still run with java 8; "A Java version between 8 and 20 is required to execute Gradle."
2023-09-20 11:51:03 <bratkartoffel> anyways, almost any java project i've come across the last years use a shipped gradle wrapper, which then uses a specific gradle version to build the project. If plantuml does not build with the latest gradle shipped by alpine, then it should add the gradle wrapper for an older version and use that instead.
2023-09-20 11:52:52 <chereskata> i'll try that first
2023-09-20 11:59:16 <pj> bratkartoffel: the keyword is "supports"
2023-09-20 11:59:24 <pj> I never implied that it doesn't run
2023-09-20 12:04:02 <chereskata> bratkartoffel: it does not work with ./gradlew
2023-09-20 12:05:45 <chereskata> btw. i have adressed all comments on !51820
2023-09-20 12:12:27 <bratkartoffel> chereskata: can you add "font-dejavu" to the makedepends? this should fix the build for x86_64
2023-09-20 12:21:17 <bratkartoffel> x86_64 green now :)
2023-09-20 12:22:41 <chereskata> bratkartoffel: why use the ./gradlew instead of gradle from alpine?
2023-09-20 12:27:12 <bratkartoffel> this way the project itself defines which gradle version they want to run on
2023-09-20 12:43:15 <chereskata> i have updated !50073 to latest version. Unfortunately aarch64 still refuses to build
2023-09-20 12:44:33 <chereskata> Shall i create i have updated !50073 to latest version. Unfortunately aarch64 still refuses to build
2023-09-20 12:44:43 <chereskata> shall i create an upstream bug report?
2023-09-20 12:45:10 <chereskata> (it also does not build with jdk8 btw
2023-09-20 12:45:12 <chereskata> )
2023-09-20 12:54:20 <elly> (re chromium) ok yes it seems like we can't uprev re2 in 3.18 then; I'll see if we can just use chromium's bundled re2 and drop the dep on the system one altogether
2023-09-20 13:02:18 <bratkartoffel> chereskata: looking into it, i can reproduce it locally with my qemu-vm
2023-09-20 13:02:30 <chereskata> thanks!
2023-09-20 14:33:56 <elly> fatal error: error in backend: IO failure on output stream: No space left on device
2023-09-20 14:34:08 <elly> my chromium builds are running out of disk now :( see https://gitlab.alpinelinux.org/elly/aports/-/jobs/1118890 for example
2023-09-20 14:34:11 <elly> anyone know how to fix that?
2023-09-20 14:34:23 <elly> ideally by giving it more disk
2023-09-20 14:37:00 <ptrc> ikke: ^
2023-09-20 14:38:08 <ikke> The backup arm ci runners have limited space 
2023-09-20 14:43:46 <ptrc> that's x86_64 though :p
2023-09-20 14:43:48 <ptrc> not arm
2023-09-20 14:44:43 <ikke> Then the docker cache needs to be cleaned up
2023-09-20 14:47:36 <elly> is that something I can do?
2023-09-20 14:51:23 <ikke> Nope
2023-09-20 14:55:10 <ikke> elly: should be sufficient space now 
2023-09-20 14:55:54 <elly> thanks!
2023-09-20 14:56:14 <elly> let's retry x86_64 and see what fails this time
2023-09-20 14:56:20 <elly> man, I miss when psykose did this :P
2023-09-20 15:00:09 <ikke> Hehe 😅
2023-09-20 15:11:26 <elly> another build failure, great :P
2023-09-20 15:12:45 <ikke> psykose mostly built everything locally
2023-09-20 15:39:37 <elly> I wish I had more computer to do that with
2023-09-20 15:39:53 <kpcyrd> when running `apk update; apk add rust`, how does `apk add` know to download from `https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/rust-1.71.1-r0.apk` (the `community` part specifically, the rest of it is obvious)? I can tell it reads from /var/cache/apk but I can't tell where it's getting that info from, it doesn't seem to be part of either APKINDEX which repo they
2023-09-20 15:39:55 <kpcyrd> belong to
2023-09-20 15:40:10 <elly> I guess if I do it incrementally it could be not that bad
2023-09-20 15:41:22 <elly> perhaps I'll try that and see what happens :)
2023-09-20 15:43:03 <ikke> kpcyrd: I don't know the exact details, but apk can map the apkindex to the repository it comes from
2023-09-20 15:43:29 <ikke> the file is APKINDEX.3a932e97.tar.gz for example
2023-09-20 15:53:01 <kpcyrd> for me it's APKINDEX.49104001.tar.gz and APKINDEX.884188d8.tar.gz but I can't find any other files that reference these random strings in my filesystem
2023-09-20 15:55:06 <ptrc> you can try `apk policy <pkgname>` btw
2023-09-20 15:55:15 <ptrc> it shows you the repositories and versions
2023-09-20 15:56:10 <ptrc> ( that's not the answer to your question, and i don't know it yet either )
2023-09-20 15:57:59 <kpcyrd> it doesn't seem to read the content of /var/cache/apk and instead does a newfstatat on the specific filenames, it's possibly a hash of the url it read from /etc/apk/repositories)
2023-09-20 15:58:24 <ikke> yes, that's what I assumed
2023-09-20 15:58:42 <ikke> I did try to find it in the source, but couldn't the last time
2023-09-20 16:00:38 <kpcyrd> found it (I think): https://github.com/alpinelinux/apk-tools/blob/99a264f936d752a45ee83442736163163ca458e2/src/database.c#L606-L616
2023-09-20 16:02:48 <ikke> Just wondering where repo->csum comes from
2023-09-20 16:03:49 <kpcyrd> echo -n https://dl-cdn.alpinelinux.org/alpine/edge/main | sha1sum - | head -c 8; echo
2023-09-20 16:04:29 <kpcyrd> -> APKINDEX.e37b76c2.tar.gz
2023-09-20 16:09:16 <ikke> alright
2023-09-20 18:19:52 <pj> could someone merge !51940
2023-09-20 18:20:52 <ikke> done
2023-09-20 18:21:07 <pj> thank
2023-09-20 18:21:18 <quinq> pretty efficient
2023-09-21 04:48:21 <celie> It seems https://gitlab.alpinelinux.org/chereskata/aports/-/jobs/1118928 has been running for almost 16 hours, it probably needs to be retried
2023-09-21 08:07:03 <chereskata> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51877#note_338929
2023-09-21 08:36:47 <chereskata> !51820 seems to be ready for merge
2023-09-21 09:17:50 <chereskata> !51407 seems to be ready to merge
2023-09-21 15:17:36 <minimal> is there a problem with the Edge aarch64 builder? build.alpinelinux.org shows it with the same info/job for quite some time
2023-09-21 15:22:36 <ikke> minimal: kicked it
2023-09-21 15:23:00 <minimal> thanks
2023-09-21 15:30:03 <ikke> apparently kicking just the test process let it continue, fun
2023-09-21 16:33:58 <WhyNotHugo> What's the state of using s6 with openrc on alpine?
2023-09-21 16:34:06 <WhyNotHugo> I found this: https://github.com/OpenRC/openrc/blob/master/s6-guide.md
2023-09-21 16:34:23 <WhyNotHugo> But simply adding the 'needs' and ' supervisor' directive to /etc/conf.d/sshd isn't enough.
2023-09-21 16:34:33 <WhyNotHugo> The service failed to start: /var/svc.d/sshd does not exist.
2023-09-21 16:35:19 <Ermine> It's broken
2023-09-21 16:35:20 <WhyNotHugo> I guess that something needs to create the service dir?
2023-09-21 16:35:56 <fluix> well that link mentions s6_service_path but it's also 6 years old
2023-09-21 16:37:06 <WhyNotHugo> Any ideas on what program created the s6_service_path 6 years ago?
2023-09-21 16:38:11 <ikke> Note that guides on openrc mostly apply to gentoo
2023-09-21 16:39:30 <fluix> unfortunately not
2023-09-21 16:39:58 <fluix> (I interpreted it as a file that needs to be read, but that's not the case)
2023-09-21 16:53:54 <WhyNotHugo> Is anyone actually using s6 to supervise service with openrc on alpine?
2023-09-21 16:59:21 <Ermine> I just ditched openrc
2023-09-21 16:59:37 <Ermine> But you may want to take a look at Adelie Linux
2023-09-21 17:04:06 <consus> If you just want supervision add supervisor=supervise-daemon
2023-09-21 17:19:06 <WhyNotHugo> Ermine: You went 100% into s6, s6-rc, etc?
2023-09-21 17:19:27 <WhyNotHugo> Did you write the service_dirs for all the services that you use?
2023-09-21 17:25:49 <Ermine> WhyNotHugo: yes, 100% s6-rc
2023-09-21 17:30:48 <skarnet> WhyNotHugo: don't use the 's6 support in openrc' thing, it kinda works but it's doing things all wrong
2023-09-21 17:31:53 <skarnet> s6 is packaged for Alpine and will work - it will give you a supervision tree - it just doesn't integrate with the way openrc people have done it
2023-09-21 17:32:22 <skarnet> (I wish they'd have talked to me when they added support, but hey, imagine people in tech communicating)
2023-09-21 17:33:34 <skarnet> properly integrating s6 with openrc is harder than that, it requires the service manager understanding that there's already a working supervision tree
2023-09-21 17:34:41 <skarnet> I've done that for Adélie because Adélie provides a supervision tree at boot; for Alpine it's different because you can't make all the services depend on s6 :)
2023-09-21 17:35:04 <Ermine> So Adelie has patched openrc?
2023-09-21 17:35:28 <skarnet> no need to patch openrc, it's the way the boot system organized
2023-09-21 17:35:37 <skarnet> is organized*
2023-09-21 17:38:22 <WhyNotHugo> So I guess that it's simpler to go 100% into s6-rc instead of trying to do a hybrid of s6 and openrc first, right?
2023-09-21 17:39:32 <skarnet> depends on what your goal is really
2023-09-21 17:40:39 <Ermine> 100% s6-rc is hard, since you're going to maintain all the scripts yourself
2023-09-21 17:41:02 <skarnet> yeah
2023-09-21 17:42:21 <orbea> there is no community effort to have shared scripts?
2023-09-21 17:42:30 <Ermine> 's6 + openrc' as upstream proposes to do it will not make you any advantage over supervise-daemon, I guess
2023-09-21 17:43:00 <Ermine> so, Adelie way
2023-09-21 17:43:19 <skarnet> WhyNotHugo: if what you want is run services under s6 while still being started by openrc, in a distribution relying on openrc such as Alpine, then your best bet is to look at what Adélie is doing e.g. for the qmail services, you'll just need to copy some boilerplate into your scripts
2023-09-21 17:43:42 <skarnet> (it's easier nowadays with s6-svlink and s6-svunlink which I wrote for this use case precisely)
2023-09-21 17:44:08 <WhyNotHugo> Personally, I'd add -s6 subpackages with the service dirs in the same way we have -openrc subpackages with init scripts.
2023-09-21 17:44:20 <skarnet> yeah, that's the end goal
2023-09-21 17:44:40 <Ermine> Right now it's maintenance burden
2023-09-21 17:44:49 <skarnet> orbea: s6-rc v0 has too small a community to have a repository of shared scripts for a whole distro
2023-09-21 17:45:22 <orbea> ah, has any scripts been made yet? an imcomplete repo might still be useful
2023-09-21 17:45:28 <orbea> *incomplete
2023-09-21 17:45:35 <Ermine> Because for fairness you'd need to add scripts for superd, runit, etc
2023-09-21 17:46:01 <orbea> people could at least see what scripts look like to make their own
2023-09-21 17:46:03 <WhyNotHugo> You mean like superd-services from the testing repo? :P
2023-09-21 17:46:12 <Ermine> orbea: s6-rc repo has examples. And s6 repo too
2023-09-21 17:46:19 <orbea> :)
2023-09-21 17:46:26 <skarnet> orbea: definitely, there are some of these
2023-09-21 17:46:49 <skarnet> including services written by other people for stuff I'd never use XD
2023-09-21 17:48:11 <Ermine> orbea: I've also published my service dirs at github.com/petershh/s6-rc-services . But they are outdated, and I'm too lazy to update them :]
2023-09-21 17:49:03 <skarnet> maintenance burden really is the thing that slows everything down until adoption reaches critical mass
2023-09-21 17:49:18 <orbea> makes sense
2023-09-21 17:49:24 <WhyNotHugo> Ermine: thanks for the reference :)
2023-09-21 17:49:34 <skarnet> and people have been very clear that critical mass will never be reached with s6-rc v0 (for good reason), so, v1 is on the way. slowly.
2023-09-21 17:54:30 <Ermine> Also, it's out of sync with the package manager, and I've shot myself in the leg because of this and lack of vigilance
2023-09-21 18:00:18 <chereskata> Could someone please look over bluez-1.59 MR !51411 :)?
2023-09-21 18:49:13 <chereskata> I have the feeling, that !51820 is finally ready now :P
2023-09-21 18:50:53 <ikke> Newbyte: PabloCorreaGomez[m] any objections left to merge ^?
2023-09-21 18:59:02 <Newbyte> <ikke> "Newbyte: Pablo Correa Gomez..." <- I'll have a look
2023-09-21 19:03:31 <ikke> apparently ncopa already merged it
2023-09-21 19:11:27 <ncopa> whoops...
2023-09-21 19:13:06 <ncopa> I'm trying to keep the open MRs down
2023-09-21 19:13:17 <ikke> understood
2023-09-21 19:14:04 <ikke> It's difficult without sidestepping all maintainers
2023-09-21 19:19:01 <ptrc> i mean, here Newbyte commented a while before the merge that it's fine and Pablo didn't leave any other comments since last review, so i'd say that went quite smoothly? :p
2023-09-21 19:19:26 <ikke> That was just a general remark, not in this specific case
2023-09-21 19:19:39 <ikke> ie, keeping the amount of open MRs low
2023-09-21 19:20:23 <Newbyte> yeah, and besides, we still have until 3.19 to fix any lingering issues with GNOME 45
2023-09-21 19:20:36 <ikke> amount of open MRs: https://imgur.com/a/vkheGgk
2023-09-21 19:20:56 <Newbyte> can I invest in number of open MRs in aports stocks?
2023-09-21 19:21:04 <ikke> lol
2023-09-21 19:35:30 <minimal> we don't want any of that subprime MR trading going on where bad MRs are bundled with good MRs and them all declared good ;-)
2023-09-21 19:36:30 <ikke> All our MRs have A* rating
2023-09-21 19:39:34 <Habbie> * not actually A
2023-09-21 20:04:04 <elly> I definitely have a couple of subprime MRs open right now personally
2023-09-21 20:04:11 <elly> I would call them "not investment grade"
2023-09-21 20:12:13 <bl4ckb0ne> ikke: whats the cause for the increase?
2023-09-21 20:12:57 <ikke> Most likely waiting longer for maintainers to comment on MRs from others
2023-09-21 20:14:09 <ikke> also, more MRs 
2023-09-21 20:15:12 <ikke> previously a lot of changes were pushed directly, now they come in more through MRs
2023-09-21 20:15:57 <fluix> also maybe slow growth as blocked/wip MRs grow
2023-09-21 20:37:10 <Newbyte> Could someone look at !46487
2023-09-21 20:37:28 <Newbyte> It's been open for months, so I would think it might've been lost in the backlog. But it's ready now.
2023-09-21 20:38:35 <ikke> chekcing
2023-09-21 20:40:44 <Ermine> I remember that there are aports which use specific git commit hashes to version packages, can you point me at one please?
2023-09-21 20:41:36 <c7s> Ermine: retroarch-assets
2023-09-21 20:41:36 <ikke> Ermine: anything with an _git* version
2023-09-21 20:41:57 <Ermine> c7s, ikke: thank you
2023-09-21 20:43:33 <ikke> apkgquery 'pkg.Pkgver matches "_git"' | tpaste -> https://tpaste.us/j4Rq
2023-09-21 21:16:10 <ptrc> DylanVanAssche: upgraded obexd-enhanced to 5.69 since bluez was bumped as well; i assume you maintain it because of pmos, and i really hope that doesn't break anything there, just letting you know
2023-09-21 21:42:40 <PabloCorreaGomez[m]> ikke, ncopa: on my side, I get notified about mostly everything GNOME-related nowadays. I'm in general totally fine with you going ahead and merging unless there are weird stuff going on. And like Newbyte said, I'm fine dealing with fallout later. I'm daily-driving GNOME in edge, so anything critical breaking will certainly hit me xD
2023-09-21 21:43:04 <PabloCorreaGomez[m]> That said, will try to be fast looking at things, so they don't stay pending for long
2023-09-22 03:12:32 <elly> if/when someone merges an MR with multiple commits, are the commits squashed?
2023-09-22 03:12:37 <elly> or do I squash them myself and push -f first?
2023-09-22 03:26:05 <Arnavion> Yes, the MR branch is rebase-squashed onto master
2023-09-22 03:30:11 <elly> great
2023-09-22 03:30:21 <elly> in that case I believe chromium 117 is ready for 3.18 finally
2023-09-22 03:40:21 <Arnavion> Did you update re2?
2023-09-22 03:43:52 <Arnavion> You didn't. It's probably fine. Just to be sure, install uBlock Origin, enable it and visit some websites with ads that get blocked. If it doesn't segfault you're fine
2023-09-22 04:57:56 <DylanVanAssche> ptrc: shouldn't be a problem. Enhanced version is just with a few addirional deps that won't make it into main. Thanks!!
2023-09-22 05:51:45 <ikke> elly: ftr, we don't squash everything by default, just rebase 
2023-09-22 05:52:45 <ikke> But if we notice fixup commits, we squash those before we merge 
2023-09-22 06:49:14 <ncopa> morning!
2023-09-22 06:49:31 <ncopa> ikke: can we squash commits from UI before merging?
2023-09-22 06:49:57 <ncopa> on a sidenote, I miss a "rebase and merge" button in gitlab.
2023-09-22 06:50:35 <ncopa> now I have to do rebase, wait 10 seconds, and merge, before going on to next
2023-09-22 06:54:08 <ncopa> PabloCorreaGomez[m]: thank you!
2023-09-22 07:04:01 <ikke> There is an option to allow squash merges
2023-09-22 07:07:15 <ikke> ncopa: https://gitlab.com/gitlab-org/gitlab/-/issues/895
2023-09-22 07:07:20 <ikke> (spoiler, still open)
2023-09-22 07:14:24 <quinq> 10 seconds for merging a git commit? sounds like a bug
2023-09-22 07:14:48 <ikke> no, rebasing a branch through the webinterface and waiting for it to finish
2023-09-22 07:15:13 <ikke> merging is instant
2023-09-22 07:20:43 <quinq> finishing what?
2023-09-22 07:24:17 <ikke> The rebase
2023-09-22 07:24:20 <omni> rebasing and javascripting
2023-09-22 07:24:34 <ikke> It's an async op
2023-09-22 07:25:14 <quinq> I meant rebase+merging, sorry
2023-09-22 07:25:24 <quinq> But ok
2023-09-22 07:26:05 <ikke> there is no single operation in the webif. Locally ofcourse it's instant
2023-09-22 07:26:21 <omni> I often need to reload the page after rebase to get to press the merge-button
2023-09-22 07:28:01 <ikke> The glab command is helpful, but there is one issue where it aborts due to some response from the API and you have to retry
2023-09-22 07:29:17 <ncopa> so it can be done with glab?
2023-09-22 07:29:26 <ikke> yes
2023-09-22 07:29:49 <ikke> `glab mr merge --when-pipeline-succeeds=false -yr <iid>`
2023-09-22 07:30:29 <ikke> glab mr checkout is also nice to easily checkout an MR locally
2023-09-22 07:36:42 <omni> very nice, I've known I need to look at starting to use it
2023-09-22 07:37:43 <omni> I used zaquestions lab a lot to follow MR CI pipelines in the terminal, before that broke for some reason
2023-09-22 07:38:14 <omni> still use it occationally to search mr and issues
2023-09-22 08:15:43 <omni> when it used to work, 'lab ci trace build-aarch64', for example, in a checked out branch was very convenient, defaulted to pager of choice or could be piped to whatever
2023-09-22 08:15:49 <omni> how do I do that with glab?
2023-09-22 10:45:52 <ikke> omni: similar, glab ci trace [options]
2023-09-22 10:46:14 <ikke> not sure if you can specify the job name though
2023-09-22 11:34:16 <kpcyrd> I found some docs on how C: works in APKINDEX: https://wiki.alpinelinux.org/wiki/Apk_spec#Binary_Format, but I can't figure out which specific parts of the .apk I need to hash to match the checksum. are there some more elaborate examples somewhere I could look at?
2023-09-22 11:35:26 <ikke> kpcyrd: https://gitlab.alpinelinux.org/alpine/go/-/blob/master/repository/package_utils.go#L318
2023-09-22 11:37:10 <ikke> basically, the the control stream
2023-09-22 11:50:58 <kpcyrd> without the signature maybe? due to the missing end-of-stream gzip marker I currently read .SIGN... and .PKGINFO together but I suspect they are supposed to be two different streams
2023-09-22 11:51:37 <ikke> Yes, read the entire file, they are separate streams
2023-09-22 11:51:56 <ikke> https://gitlab.alpinelinux.org/alpine/go/-/blob/master/repository/package_utils.go#L174-L180
2023-09-22 12:13:48 <omni> ikke: I tried a bit without success and was hoping someone else was already doing this for mr pipelines and could just share how so that I can continue being lazy and not research it further
2023-09-22 12:19:54 <ikke> glab ci view -R chereskata/aports -b py3-protobuf
2023-09-22 12:23:04 <ikke> that would show you all jobs and you can select the one you want to view
2023-09-22 12:23:55 <ikke> glab ci trace would take a job id, so you'd first have to look that up
2023-09-22 12:30:07 <omni> now I use my eyes and see in the returned error url that it has gitlab.com and not gitlab.a.o
2023-09-22 12:32:25 <omni> changed to default host: gitlab.alpinelinux.org and now I get another error, must bee viewed as progress
2023-09-22 12:33:46 <ikke> fyi, it helps to run this in the repo you want to show the logs frm
2023-09-22 12:33:47 <ikke> from
2023-09-22 12:33:59 <omni> I do
2023-09-22 12:35:31 <omni> but I feel like 'glab ci view' should be sufficient for a branch I have checked out
2023-09-22 12:37:18 <ikke> I think Leo has an open issue for it
2023-09-22 12:37:36 <ikke> It works if the branch is part of the repo, but if it's a fork, it's not working properly
2023-09-22 12:39:49 <ikke> omni: https://gitlab.com/gitlab-org/cli/-/issues/611
2023-09-22 12:42:46 <omni> ah
2023-09-22 12:43:17 <omni> why are these ASCII text file logs suffixed .gz? https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/lua-filesystem/
2023-09-22 12:43:39 <ikke> They are compressed on the fs
2023-09-22 12:44:28 <ikke> But due to 'Content-Encoding: gzip', it shows as plaintext
2023-09-22 12:49:55 <omni> so when I do 'curl -LO https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/lua-filesystem/lua-filesystem-1.8.0-r3.log.gz' I get a plainext file ending with .gz, thought of it as an error
2023-09-22 12:50:26 <omni> why haven't I seen this before?
2023-09-22 12:50:45 <omni> here we have both https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/7zip/
2023-09-22 12:51:33 <ikke> Yeah, I manually gzipped one repo as a test
2023-09-22 12:53:11 <omni> those two, the gzipped one look smaller in the file liesting on the web, but you'll get an uncompressed 7zip-22.01-r5.log.gz when you download it, confusing
2023-09-22 12:58:34 <elly> is the web server sending `Content-Encoding: gzip` and causing curl to undo the gzip layer on you?
2023-09-22 12:58:55 <elly> it should not do that if it truly wants to serve a gzipped file :)
2023-09-22 12:59:07 <ikke> It doesn't want to server a gzipped file
2023-09-22 12:59:17 <ikke> It wants to serve plain text files, but safe on storage
2023-09-22 12:59:46 <ikke> save*
2023-09-22 12:59:49 <elly> gotcha
2023-09-22 13:00:45 <ikke> Ideally the fact that they are gzipped on disk would be hidden as will
2023-09-22 13:00:58 <ikke> but not sure if that's possible without generating a custom indez
2023-09-22 13:01:00 <ikke> index*
2023-09-22 13:01:24 <omni> but it looks like only log files dated 23-Apr-2023 are listed as .gz
2023-09-22 13:01:45 <ikke> I did it once as a test, did not continue to make it permanenet yet
2023-09-22 13:02:17 <omni> if it was me, I'd just have them as plaintext and use zstd as default compression on the zpool :B
2023-09-22 13:03:25 <omni> but guessing not everyone has upgraded their filesystems yet :p
2023-09-22 13:04:22 <omni> ikke: I think I too get what you were saying now
2023-09-22 13:05:20 <ikke> And the goal was mostly to save space on the builders, which are most space constraint
2023-09-22 13:05:29 <ikke> and to have abuild gzip them by defautl