2025-09-01 03:10:51 <DWwanghao> WhyNotHugo: it is recommended to use gpep517 as the build backend during the build process
2025-09-01 05:37:25 <ikke> ptrc: are you interested in taking over maintenance for darktable?
2025-09-01 09:59:31 <WhyNotHugo> DWwanghao: thanks!
2025-09-01 09:59:56 <WhyNotHugo> for a split package of this kind, I'd love to have onionshare-cli and onionshare-desktop. But it's not possible to _not_ have an "onionshare" package while having those two subpackages, right?
2025-09-01 10:00:09 <WhyNotHugo> (it's just a matter of naming tbf)
2025-09-01 10:58:24 <Sertonix[m]> I would probably go with "onionshare" and "onionshare-cli" in such a case
2025-09-01 11:24:32 <ikke> The origin package must always exist
2025-09-01 13:57:19 <elagost> could someone checkout the post-install script in !89412 and tell me if it's ok? It's for downloading data that otherwise shouldn't be distributed.
2025-09-01 14:15:08 <ikke> elagost: haven't checked very thoroughly, but I think you need to add unzip as a dependency 
2025-09-01 14:16:12 <elagost> ikke: there is a busybox unzip - is that ok to use?
2025-09-01 14:17:45 <ikke> Oh yeah, that should be fine
2025-09-01 14:18:49 <elagost> thanks. I am also concerned about it from a policy perspective, not sure if there is anything else that does a big download at install time, or if that's ok.
2025-09-01 14:22:02 <ikke> elagost: I'm not aware of anything else that does that, but I do appreciate that approach 
2025-09-01 14:24:25 <elagost> thanks! just wanted to make sure I wasn't running afoul of some rules or guidelines I didn't know. 
2025-09-01 14:25:52 <ikke> Maybe good to check hashes for the downloaded files 
2025-09-01 14:28:27 <elagost> Ooh, good point. Are variables like $Pkgver usable in post-install too?
2025-09-01 14:34:38 <Saijin_Naib[m]> elagost, thanks for packaging that! It might help me figure out what to do with WarFork, which also needs a ton of data
2025-09-01 14:34:56 <Sertonix[m]> Yes, I think it is the second argument
2025-09-01 14:42:52 <Sertonix[m]> [@_oftc_elagost:matrix.org](https://matrix.to/#/@_oftc_elagost:matrix.org) I think downloading files in such a way can cause unexpected behaviour. For example 'apk --no-networking' would still use networking when the script is run. I am uncertain at the moment how this could be done better though.
2025-09-01 14:45:52 <Saijin_Naib[m]> What about splitting the post-install script into a alephone-data package that the main package does not depend upon?
2025-09-01 14:46:05 <ikke> elagost: it's a shell script 
2025-09-01 14:46:09 <Saijin_Naib[m]> That way the user can manually provide the game data, or install the pacakge and run the post-install script separately>
2025-09-01 14:46:10 <ikke> So, yes
2025-09-01 16:18:34 <elagost> Saijin_Naib[m]: thanks for the advice, I've switched to that strategy.
2025-09-01 16:20:02 <ikke> elagost: ah, I misunderstood what you meant. post-install scripts do not have the same context as APKBUILD files
2025-09-01 16:22:21 <ikke> elagost: The scripts do get some information about versions on their stdin
2025-09-01 16:23:09 <ikke> Not sure about post-install
2025-09-01 16:25:53 <elagost> post-install provides "$pkgname-r$pkgrel" as $1 so I parse that in the script. Is there a better way to have post-install and post-upgrade be the same script, other than a symlink?
2025-09-01 16:26:34 <ikke> No, a symlink is exactly how that's done
2025-09-01 16:30:44 <elagost> cool, only thing extra I could do is get checksums from the github api, but I think that kinda defeats the purpose.
2025-09-01 20:23:32 <ovf> remembered to push !89501 for duke nukem / shadow warrior / ion fury / etc. build games
2025-09-02 02:27:37 <Saijin_Naib[m]> sweet! I love seeing gaming stuff for Alpine
2025-09-02 02:29:34 <Saijin_Naib[m]> Long-term, I've got to try packaging darkplaces, knightmare, ioquake, and darkmod (iDTech 1-4)
2025-09-02 02:30:03 <Saijin_Naib[m]> the fork of darkplaces for WRATH: Aeon of Ruin would also be nice to run it natively
2025-09-02 02:30:13 <Saijin_Naib[m]> but that's like a me thing only, I'm sure
2025-09-02 02:30:45 <Saijin_Naib[m]> If anyone plays Arx Fatalis, I got Arx Libertatis packaged, but the engine bombs with the demo data, and I've yet to trace down what is happening to upstream the error and hopefully get it fixed
2025-09-02 07:45:23 <ovf> and then the FROM alpine people (and also whoever is running s390x) are like, what's this all about
2025-09-02 14:25:12 <ncopa> achill and Sertonix[m]: can I ask you to follow up the /usr merge? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504 when both are you are ok with it you just merge it
2025-09-02 15:22:34 <achill> yes sure
2025-09-02 15:33:20 <qaqland> maybe !88712 is ready
2025-09-02 20:25:27 <ptrc> ikke: sorry, i missed your message yesterday! i can take over, sure :3 i'll submit a MR
2025-09-02 20:25:41 <ikke> Ack
2025-09-02 20:26:02 <ptrc> in the meantime, there's also plenty of stuff i don't use anymore that's in community, or stuff that i took over from fab, so.. i'll have to think of a way to work this out
2025-09-02 20:29:11 <ikke> ptrc: note that there are updates for dt, so you can combine ethat
2025-09-02 20:35:27 <Asmadeus> Is there a way to mark a package as dependency only if upgrading from older version? (asking as follow-up for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88937#note_537724 -- to get the -gui subpackage to install if upgrading from older versions without leaving a default provide)
2025-09-02 20:35:45 <Asmadeus> (that got merged, but if there's a way of doing it might as well clean up sooner rather than later)
2025-09-02 23:40:35 <dok> dmesg says: > [drm:amdgpu_job_submit [amdgpu]] *ERROR* Trying to push to a killed entity
2025-09-02 23:41:00 <dok> sorry wrong channel
2025-09-03 04:09:19 <terror> Hi all, I've been following the OpenRC replacement conversation for years. I know Laurent started working on this but progress seem to have stalled and in the meantime dinit has showed up as a very worthy init system that ticks most of the boxes in Laurent's analysis of OpenRC vs SystemD vs s6. Have we discussed seriously considering dinit as Alpine's init system moving forward?
2025-09-03 04:21:07 <terror> I've been testing it for a few months and the "service files" are very pleasant to use. Alpine boots fine with it and faster than with OpenRC (though that doesn't really matter to me very much)
2025-09-03 05:08:57 <pj-> alpine uses busybox as init
2025-09-03 05:09:13 <pj-> what you want to replace is service management
2025-09-03 05:15:16 <ikke> they already left
2025-09-03 05:17:43 <pj-> so much for discussing
2025-09-03 05:19:15 <psykose_> the hyperspecific init/service-management/supervising/whatever term separation is just being pedantic for no gain
2025-09-03 05:26:06 <caskd> ^
2025-09-03 05:27:10 <pj-> ^
2025-09-03 06:32:46 <achill> ^
2025-09-03 07:23:06 <quinq> That was constructive
2025-09-03 08:24:49 <caskd> but on the topic of inits i think many fail to observe that having a mix of init/supervisors requires the distro to either maintain service files for every one of them or commit on one
2025-09-03 08:25:02 <caskd> or write some abstract wrapper/generator
2025-09-03 08:25:13 <caskd> which doesn't help much on the "there are X standards" issue
2025-09-03 08:25:31 <caskd> so i think everyone is welcome to experiment first and then submit their work
2025-09-03 08:26:25 <caskd> alpine is community led and people don't have time to attempt something they aren't familiar with
2025-09-03 08:26:44 <caskd> (i would assume, feel free to correct me)
2025-09-03 08:27:11 <caskd> so if someone desires change then they are free to work on it themselves and ask for feedback or integration
2025-09-03 08:27:31 <caskd> but asking for it to happen without being invested in it yourself is not going to get far
2025-09-03 08:28:35 <caskd> its fine to ask if there's interest into it to avoid working on something that will never be upstreamed
2025-09-03 08:29:07 <caskd> but otherwise, the best path is to show it can be done and bring in at least the basics of the idea
2025-09-03 10:47:16 <skarnet> I should probably communicate more that I'm actively working on s6-rc >.>
2025-09-03 10:47:48 <f_> Now I know you are actively working on s6-rc :P
2025-09-03 10:49:16 <skarnet> but that's the dilemma of working on stuff: I have overpromised and underdelivered because my ambitions were too big, now that I'm working on something reasonable I'd rather not say anything until it's ready
2025-09-03 10:49:26 <caskd> i think thats fine
2025-09-03 10:49:42 <caskd> better than having people have high expectations and constantly bothering you about it
2025-09-03 10:49:54 <skarnet> well apparently it doesn't stop them
2025-09-03 10:49:59 <caskd> ^^'
2025-09-03 10:50:08 <pj-> is this actually working on -rc or is it the same state as for the past some years
2025-09-03 10:50:15 <skarnet> did I stutter
2025-09-03 10:50:22 <caskd> wow rude
2025-09-03 10:51:33 <caskd> we don't want the next service manager to have the same downsides as openrc, do we?
2025-09-03 10:51:37 <pj-> idk, the last time I had this talk there was agreement from all three sides to improve the situation and it ended up where?
2025-09-03 10:51:37 <caskd> maybe should give it time
2025-09-03 10:52:04 <pj-> ok, will come back in 5~10 years
2025-09-03 10:52:05 <skarnet> pj-: that's exactly what I meant with "ambitions were too big"
2025-09-03 10:52:46 <skarnet> ambitions have now been scaled down to something doable
2025-09-03 10:52:59 <f_> step-by-step
2025-09-03 10:55:38 <skarnet> the reason why you haven't seen anything yet is that making something foolproof enough for a distro requires a lot of hardening work
2025-09-03 13:29:54 <Ermine> op nick was suitable
2025-09-03 17:19:11 <z3ntu> Can someone with permissions on gitlab please press the rebase button in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89135 ? The CI artifacts have expired so I cannot try it out anymore (easily)
2025-09-03 17:19:35 <caskd> pretty sure you can do this too with git pull --rebase && git push -f
2025-09-03 17:19:50 <caskd> it will also trigger a rebuild
2025-09-03 17:20:06 <caskd> unless you are talking about a MR you don't own
2025-09-03 17:20:19 <z3ntu> don't think so, it's not my MR and I'm not an alpine dev
2025-09-03 17:20:25 <caskd> ah okay
2025-09-03 17:28:19 <z3ntu> nvm, re-opened the MR under my account temporarily
2025-09-03 21:40:16 <terror> Hi everyone, sorry about bailing out yesterday, it was late down here. My question was along the lines of "is this avenue worth pursuing or is the project direction set"? as I said, dinit has been booting Alpine for a while, and meeting the requirements highlighted on Laurent's analysis but supporting/migrating is a big endeavour that'll take effort so don't want to waste time if it's not in the best interest of the project.
2025-09-03 21:41:23 <terror> @skarnet, great to hear you are still working on s6-rc and have made some progress.
2025-09-03 21:45:16 <skarnet> np :) and yes, supporting several service managers is a big endeavour, but that's part of the work I'm doing
2025-09-03 21:46:29 <skarnet> when I'm done with the current work (providing a high-level UI to s6-rc that makes it as easy to use as openrc), one of the next steps is provide a way to give users a choice of service managers without adding to the maintenance burden of Alpine devs
2025-09-03 21:46:50 <skarnet> so it has to integrate seamlessly
2025-09-03 21:47:44 <Ermine> 
ACTION brings popcorn

2025-09-03 21:48:07 <quinq> skarnet, nice
2025-09-03 21:48:19 <terror> Once you have solidified the declarative interface format, I'll take a stab at wrinting a little conversion utility along the lines of https://skarnet.org/software/s6/unit-conversion.html to go from SystemD unit files to s6 and to dinit. As you said, it will never be 100% accurate but if it does 75% of the work, it is still a win IMO. 
2025-09-03 21:50:42 <skarnet> unit files are a whole other enchilada, I'm not touching that one, you are XD
2025-09-03 21:51:59 <skarnet> as for a declarative interface, it will probably be the last part of the project, because a lot can change in the meantime and it's mostly sugar for developers, it doesn't impact users
2025-09-03 22:05:50 <terror> Users are fine with the statu quo. This is all for developers
2025-09-03 22:07:18 <terror> Also once we have a spec (I'll look at the dinit spec for unit files too, so hopefully some of it can be reused) LLMs should be pretty good at translating
2025-09-03 22:09:32 <terror> I've moved all my services (containers) to dinit as supervisor with 0 issues so far, so would like to leverage as much as I can from that. The dev experience of "I wrote this new app, I want to run it under the supervisor" of dinit is pretty great.
2025-09-03 22:10:02 <terror> My devs have had no problems writing unit files with very little handholding.
2025-09-03 22:37:14 <skarnet> dinit has always looked like a nonstarter to me for Alpine because it's C++, but what do I know
2025-09-03 22:57:51 <terror> @ncopa, is that some sort of philosophical position for Alpine? SOrry I wasn't aware of that at all, good catch @Skarnet
2025-09-03 23:04:46 <skarnet> it's certainly not philosophical, but the amount of resources taken might be a factor
2025-09-03 23:05:54 <skarnet> I don't think Alpine is opinionated, however it does pay attention to RAM and disk usage of infrastructure
2025-09-03 23:18:08 <terror> Given OpenRC is 4363KiB and dinit is 586KiB, that shouldn't be a problem I'd hope. Anyway I'm happy to wait for the s6 flavoured init if that's where we are going :)
2025-09-03 23:24:45 <terror> With dependencies they go to OpenRC: 24 packages, 114 dirs, 285 files, 15 MiB and dinit: 19 packages, 99 dirs, 119 files, 11 MiB so much of a muchness
2025-09-03 23:26:15 <terror> @Ermine, glad to be entertaining
2025-09-03 23:59:53 <skarnet> that's for disk space, now do the RAM :)
2025-09-04 00:00:10 <skarnet> (that's much harder to tally, I know)
2025-09-04 00:06:52 <psykose_> like 2mb rss on chimera
2025-09-04 00:15:07 <terror> Is there even a way to get actual ram footprint of anything? Every measure I've seen has someone criticising as "not accurate acshually"
2025-09-04 00:17:08 <terror> I most definitely don't know enough about s6 to figure it out, maybe add up all the s6-* processe's RSS ?
2025-09-04 00:23:04 <skarnet> memstat, but it's been deprecated for a while
2025-09-04 00:24:14 <skarnet> the only accurate way I know is to look at /proc/$pid/smaps_rollup for every relevant pid
2025-09-04 00:24:28 <skarnet> and do the computation yourself. That's what memstat did back in the day
2025-09-04 00:24:45 <skarnet> RSS is no good because it mixes shared and private
2025-09-04 00:25:42 <skarnet> off to bed, gn
2025-09-04 01:29:42 <terror> Apparently there's something called ps_mem on Alpine that gives a breakdown of Private + Shared memory. I'll run some tests when I have some time
2025-09-04 03:56:17 <terror> These are the service files I've been using: https://gitlab.alpinelinux.org/PureTryOut/dinit-alpine/-/tree/master/services?ref_type=heads
2025-09-04 05:51:35 <Saijin_Naib[m]> If anyone has bandwidth, could I get review/merge for gradia and cobang? !88800 and !88082
2025-09-04 10:13:21 <indy> fabled, hi, can be apk-tools updated to 2.14.10 in 3.22? and also in older releases?
2025-09-04 10:48:02 <achill> i think the was some abi breakage or so
2025-09-04 10:48:20 <achill> is there a specific commit you want to have backported?
2025-09-04 11:33:33 <indy> !89633
2025-09-04 11:35:22 <indy> achill, which abi breakage?
2025-09-04 11:35:47 <achill> dont remember
2025-09-04 12:12:24 <indy> i tested that single patch in 2.14.4+
2025-09-04 12:16:55 <wen> Could someone please help merge this MR so I can proceed with the follow-up work: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89581
2025-09-04 12:17:20 <ikke> !89581
2025-09-04 13:27:41 <indy> ncopa, fabled, achill what about !89633 ? 
2025-09-04 14:01:18 <achill> wen: you can also just combine the package additions together with the upgrade in the same MR
2025-09-04 14:16:23 <wen> achill: the upgrade of mycli seems require many new aports, so I would complete it in several parts.
2025-09-04 14:20:57 <achill> sure
2025-09-04 23:38:05 <WhyNotHugo> Kind ping for https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/99
2025-09-05 00:20:45 <craftyguy[m]> I think this should unstick the x86 builder: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89678
2025-09-05 00:26:12 <craftyguy[m]> PureTryOut (matrix.org) you disabled x86 for qt6-qtwebengine, and quite a few other packages probably need to be updated too to be disabled on x86 (and likewise a few of those packages can probably be re-enabled for armv7 based on your latest qt6-qtwebengine patch)
2025-09-05 01:33:38 <EvTheFuture> !89513
2025-09-05 01:36:28 <EvTheFuture> If someone could glance at MR 89513 when possible it would be appreciated. It seems like the assigned maintainer is not so active...
2025-09-05 01:53:57 <lotheac> i think you should give them a bit longer than 2 days :) but the MR looks fine to me
2025-09-05 04:12:12 <lotheac> EvTheFuture: I suggest submitting your patch upstream; seems they tried to fix musl compilation recently but their fix is wrong https://github.com/BestImageViewer/geeqie/issues/1894
2025-09-05 07:11:23 <indy> fabled, ncopa, achill !17481
2025-09-05 07:12:25 <indy> fabled, ncopa, achill https://gitlab.alpinelinux.org/alpine/aports/-/issues/17481
2025-09-05 07:23:41 <fabled> Indy: just updated the version instead of cherry pick, though I should probably tag the current apk 2.14-stable head
2025-09-05 07:30:49 <indy> fabled, what about that abi breakage?
2025-09-05 07:30:53 <indy> achill, ^^
2025-09-05 07:32:34 <indy> i mean i haven't observed issues on 3.18 with 2.14.10
2025-09-05 07:46:50 <indy> fabled, netrc is already in 2.14.10 but as achill stated there is problem with abi
2025-09-05 07:47:04 <indy> so i tried this way
2025-09-05 08:05:15 <fabled> Oh right, the soname changes
2025-09-05 13:34:11 <EvTheFuture> lotheac: I have created a PR upstream https://github.com/BestImageViewer/geeqie/pull/1898
2025-09-05 13:57:41 <ikke> Apparently Firefox will drop 32-bits support starting from v144
2025-09-05 13:57:58 <ikke> https://lwn.net/Articles/1036856/
2025-09-05 13:58:48 <ikke> Correction, 144 is the last version to still have it
2025-09-05 19:20:48 <f_> :/
2025-09-05 19:21:41 <f_> is this just affecting x86 or also armv7?
2025-09-05 19:22:01 <ikke> 32-bit linux systems
2025-09-05 19:22:07 <ikke> so I assume armv7 as well
2025-09-05 19:22:41 <f_> :\
2025-09-05 19:22:51 <ikke> https://blog.mozilla.org/futurereleases/2025/09/05/firefox-32-bit-linux-support-to-end-in-2026/
2025-09-05 19:22:58 <f_> yeah I read that
2025-09-05 19:23:26 <JustSouptheyhe[m]> ESR 140 will be supported until september 2026 though
2025-09-05 19:23:36 <f_> That's "just" one year of support
2025-09-05 19:28:35 <ikke> "we strongly encourage you to move to a 64-bit operating system and install the 64-bit version of Firefox"
2025-09-05 19:28:45 <ikke> If only you could convince your CPU to run that
2025-09-05 19:29:49 <f_> if only
2025-09-05 19:30:01 <f_> "CPU! Run in 64-bit mode!"
2025-09-05 19:30:48 <f_> or phone also, a large number of phones from 2011-2015 run armv7 .. 
2025-09-05 19:42:45 <realroot[m]> .config/enviroment.d/file.conf is not working. out of the blue micro does not see anymore MICRO_TRUECOLOR=1, env sees it. i am using bash for the completions
2025-09-05 19:53:36 <realroot[m]> oops I mean to write that in#alpine
2025-09-05 19:53:48 <pj> environment.d is a systemd user service feature
2025-09-05 19:55:10 <realroot[m]> how can I update from cli my fork of aports? I mean to merge the new changes from upstream (alpine aports)
2025-09-05 19:55:38 <pj> git remote add upstream https://gitlab.alpinelinux.org/alpine/aports.git
2025-09-05 19:55:51 <pj> git pull upstream --rebase
2025-09-05 20:18:25 <leg> How can I squash the commits of a merge request? It seems I do not have the permissions. Merge request 89717 on aports.
2025-09-06 00:59:04 <lotheac> EvTheFuture: thanks! i left a comment there to try to convince them :)
2025-09-06 02:49:53 <lotheac> EvTheFuture: oh you actually did that work too :D I figured I would leave it up to them
2025-09-06 02:49:58 <lotheac> thanks
2025-09-06 05:40:25 <EvTheFuture> lotheac: yeah if you want something done (within a reasonable time), just do it yourself ;) 
2025-09-06 05:43:03 <lotheac> i can respect that :)
2025-09-06 14:52:09 <puli> Hello people, I want to add a patch to the existing lighttpd package to make it support sessions. The said patch https://github.com/gstrauss/lighttpd-mod_authn_tkt is suggested by the official documentation but it is not present in the repo because of incompatible licenses. The patch has apache license as it is obtained from the Apache httpd project. Can I add the patch to
2025-09-06 14:52:11 <puli> existing APKBUILD? 
2025-09-06 14:55:03 <ikke> If the original project is not able to ship it together, we are not either
2025-09-06 15:04:02 <puli> ikke: Thanks for replying, I'll maintain my own APKBUILD for now and try to solve the issue in upstream.
2025-09-06 15:11:15 <q66> what's the issue? bsd-3 and apache should be compatible
2025-09-06 15:12:26 <q66> presumably upstream would want all under the same license but for distributors it should not matter 
2025-09-06 15:42:55 <puli> q66: I vaguely remember seeing that the project is maintaining the patch separately due to license incompatibilities last night. I am new to licenses, I'll try to find the source of this info
2025-09-06 15:55:04 <bulldozer> Hey! If someone makes a suggestion to a MR I have, what would be the correct way of taking that suggestion in? Should I reset my commit, then edit the files and recommit, or do I revert, or how would this best work?
2025-09-06 15:55:33 <ikke> bulldozer: if it's a single commit, git commit --amend, and then git push --force-with-lease
2025-09-06 15:56:47 <bulldozer> ikke, so I would, edit the file, git add, then --amend, etc?
2025-09-06 15:56:52 <ikke> yes
2025-09-06 15:57:10 <bulldozer> Thank you, I appreciate you helping me understand git.
2025-09-06 16:02:46 <q66> puli: upstream not wanting to introduce apache-licensed code into their repo is kinda expected
2025-09-06 16:02:53 <q66> but that doesn't mean the result is incompatible, i think
2025-09-06 16:03:03 <q66> all the permissive licenses can be distributed with each other more or less fine
2025-09-06 16:03:46 <puli> q66: Apparently, the author(gstrauss) made all the efforts to re-release the original apache module under Apache 2.0: https://github.com/gavincarr/mod_auth_tkt/issues/24 and updated the lighttpd fork
2025-09-06 16:04:08 <q66> oh, it's apache-1.0
2025-09-06 16:04:19 <puli> It seems so
2025-09-06 16:04:28 <q66> yeah apache-1.0 has issues
2025-09-06 16:04:40 <puli> but now changed to Apache 2.0 both in httpd and lighttpd fork
2025-09-06 16:04:47 <q66> apache-2.0 should be fine
2025-09-06 16:05:46 <puli> q66: Does this mean I can update the patch main APKBUILD?
2025-09-06 16:06:30 <q66> i'd say yes but i am not a maintainer so i can't really tell you
2025-09-06 16:06:53 <q66> the alpine people need to decide that
2025-09-06 16:10:12 <puli> q66: Thanks for the help, I try to create a issue in gitlab aports repo, if at all it is possible to signup
2025-09-06 16:15:04 <ikke> it should be possible, let me know if not
2025-09-06 16:18:49 <puli> ikke: Yes, it is working! Some time back, I was not able to login citing spam. Now working thanks!
2025-09-06 16:20:47 <ikke> puli: maybe you were thinking of archlinux or freedesktop?
2025-09-06 16:20:56 <puli> I have misspoken. Gnome project's pages are the ones being in attack lately.
2025-09-06 16:21:02 <puli> ikke: yes and yes, those too
2025-09-06 16:21:53 <puli> my bad
2025-09-06 16:21:57 <ikke> np
2025-09-06 20:01:53 <ikke> gitlab is being upgraded
2025-09-07 01:47:17 <qaqland> g.a.o/dashboard/merge_requests looks great
2025-09-07 02:44:45 <Saijin_Naib[m]> What is the resolution when two packages provide the same cmd, but are completely unrelated?
2025-09-07 02:46:10 <Saijin_Naib[m]> So, flare (Signal GTK client) and the flare-game (RPG on FLARE engine) package both provide cmd:flare
2025-09-07 04:43:12 <EvTheFuture> I have updated !89513 to implement the same patch as proposed upstream. Would this be accepted in order to get the version of geeqie updated in Alpine?
2025-09-07 05:02:50 <ikke> Saijin_Naib[m]: you'd have to rename one if you want to be able to install them both
2025-09-07 07:16:16 <lotheac> EvTheFuture: i would expect so, once a developer gets to your MR - but if it was my MR, I would add some more information to the patch file that shows it's been submitted upstream (or backported from upstream); such as a link to the upstream PR
2025-09-07 07:17:00 <lotheac> also the maintainer might have a say in how you've done things
2025-09-07 07:17:10 <lotheac> the package maintainer that is
2025-09-07 13:06:18 <wen> I would update py3-django from 4.2.x to 5.2.6. Today I tested all the aports depends on py3-django(130+) with django-5.2.6.
2025-09-07 13:06:34 <wen> There are 8 aports build fail.
2025-09-07 13:06:59 <wen> I list here to avoid duplicte work:
2025-09-07 13:07:48 <wen> 1 py3-django-pglock   2 py3-django-tenants  3 py3-django-jinja   4 py3-django-pgactivity
2025-09-07 13:09:22 <wen> 5 py3-django-oauth-toolkit    6 py3-django-filter    7 py3-django-sorl-thumbnail    8 py3-django-dynamic-fixture
2025-09-07 14:11:48 <Saijin_Naib[m]> @ikke what package gets priority to keep its name? Do I open an Issue and tag both maintainers and let them sort it out? 
2025-09-07 14:12:03 <ikke> Saijin_Naib[m]: Generally the first package
2025-09-07 14:12:23 <ikke> But yes, it does require coordination
2025-09-07 14:12:47 <ikke> For go-task, I renamed the binary to go-task, but created a subpackage that installs it as 'task'
2025-09-07 14:13:33 <Saijin_Naib[m]> Hmm, okay, thanks. I'll open the issue later
2025-09-07 19:04:17 <realroot[m]> fossdd I am flagging fastfetch.
2025-09-07 19:04:59 <achill> what?
2025-09-07 19:05:12 <realroot[m]> can I just register to Anitya to make  a package mapping?
2025-09-07 19:05:15 <achill> flags are disabled for some time now 2. fastfetch is up to date
2025-09-07 19:05:31 <achill> oh yeah mean that, yeah just go ahead, if it isnt already
2025-09-07 19:05:54 <realroot[m]> uhm I saw a comment referring to 2.52.1 but it is not released sorry
2025-09-08 04:59:38 <Saijin_Naib[m]> Issue made, hopefully the maintainers can see it
2025-09-08 09:40:31 <indy> fabled, ncopa, achill any comments on !89633 ?
2025-09-08 20:28:15 <raspbeguy> hello, I am trying to package something which doesn't have tarball snapshot available. So I'm trying to use `aport snapshot`. however I guess I can't because I can't upload anything to dev.alpinelinux.org because my key isn't authorized. So do I have to be an Alpine developper to be able to make this package
2025-09-08 20:30:31 <ikke> I'm not a fan of that approach to be honest, because it always involves an extra step from a developer
2025-09-08 20:30:56 <ikke> What is the project?
2025-09-08 20:31:04 <raspbeguy> I know. Is there another approach?
2025-09-08 20:31:20 <raspbeguy> https://git.familie-radermacher.ch/linux/ptouch-print.git/
2025-09-08 20:31:52 <quinq> raspbeguy, other approach is to ask nicely upstream for a release
2025-09-08 20:32:12 <quinq> Though they do have one from a month ago
2025-09-08 20:32:38 <raspbeguy> a release snapshot to be exact, because there is already a release per se
2025-09-08 20:32:49 <ikke> I think they disabled snapshots in cgit
2025-09-08 20:33:26 <achill> maybe its mirrored somewhere with tarballs like github?
2025-09-08 20:35:00 <quinq> “Dear visitor, currently I have absolutely no time for improvements on this project (my free time currently is about one or two hours PER MONTH). Therefore, I can not look at suggestions about improvements.” :/
2025-09-08 20:35:03 <raspbeguy> achill, I don't think so
2025-09-08 20:35:52 <achill> eh not nice, i mean i can run abuild snapshot for you, but its still not the nicest way to do it
2025-09-08 20:36:12 <achill> it makes it a little harder for developers without access to upgrade and stuff
2025-09-08 20:36:29 <raspbeguy> yeah
2025-09-08 20:36:56 <raspbeguy> hopefully I'll be accepted as developper at some point 🙂
2025-09-08 20:37:11 <quinq> :D
2025-09-08 20:39:22 <ikke> https://gitlab.alpinelinux.org/mirror/ptouch-print#
2025-09-08 20:40:48 <raspbeguy> ah nice, thanks
2025-09-08 20:41:21 <ikke> (I need to add some automation to keep it updated at some point)
2025-09-08 20:42:02 <raspbeguy> yes please
2025-09-08 20:43:09 <ikke> sadly gitab CE does not support pull syncing, only push
2025-09-08 20:43:49 <raspbeguy> hum :'
2025-09-08 20:56:56 <Ariadne> indy: i merged the backport
2025-09-09 00:24:46 <timlegge> CVEs in a main package get backported to which branches?
2025-09-09 00:31:10 <timlegge> nvm back to 3.19 it looks like
2025-09-09 01:20:10 <Saijin_Naib[m]> raspbeguy, if you get some time, I am stuck on !86066
2025-09-09 01:20:47 <Saijin_Naib[m]> I packaged py3-senf already, but I cant figure out next steps
2025-09-09 05:13:48 <indy> Ariadne, thanks :)
2025-09-09 05:42:41 <Biswa96[m]> Saijin_Naib: this patch will help https://gitlab.archlinux.org/archlinux/packaging/packages/quodlibet/-/blob/5742b990efe5f3f886d06aca4fddfc54f23eb1dd/quodlibet-fix-executable-conflict.patch
2025-09-09 05:45:16 <raspbeguy> Oh nice
2025-09-09 08:07:44 <ikke> f_: apparently it's only x86 that's no longer going to be supported by Mozilla (they updated the blogpost)
2025-09-09 08:08:18 <ikke> (today)
2025-09-09 08:11:48 <achill> also it'll probably work for the time being
2025-09-09 08:12:25 <achill> they just won't build artifacts anymore and probably spend less time fixing this stuff but there are also other parties likely interested in fixing x86 32b support
2025-09-09 08:12:37 <achill> only the future can show how the supports gonna be :)))
2025-09-09 09:44:51 <f_>  10:07 <@ikke> f_: apparently it's only x86 that's no longer going to be supported by Mozilla (they updated the blogpost)
2025-09-09 09:44:58 <f_> okay then I'm less worried
2025-09-09 09:45:54 <f_> I'd be all for x86 support... but frankly the number of working x86 hardware in active use is just dropping.. hey, most of the aging computers I have are x86_64
2025-09-09 09:46:31 <f_> So that's not too bad after all given that
2025-09-09 09:54:04 <skarnet> don't dismiss aging computers. At some point they'll be the future.
2025-09-09 09:54:33 <skarnet> (and I'm not saying that because I have 5 old PCs waiting in the cellar, of course not)
2025-09-09 09:57:02 <f_> skarnet: I'm typing this from a 13 year old computer
2025-09-09 09:57:46 <f_> I'm not saying we should dismiss aging computers, but I'm saying the number of users still on x86 hardware is dropping
2025-09-09 09:58:38 <f_> the most recent """x86""" computers these days are just underpowered x86_64 atom CPUs running windows in x86 mode
2025-09-09 10:35:10 <skarnet> yeah, that's certainly true in the West at least
2025-09-09 10:35:42 <skarnet> I think that in places with less access to modern hardware you can still find a lot of old PCs powering network access or something
2025-09-09 11:16:14 <Ermine> f_: how recent are those x86 computers?
2025-09-09 11:17:03 <Ermine> <achill> only the future can show how the supports gonna be :))) --- it's Firefox, so it'll probably require large amount of effort
2025-09-09 11:25:36 <shaw> hello
2025-09-09 11:31:34 <achill> and already ggone
2025-09-09 11:32:39 <ikke> hello-goodbye
2025-09-09 12:41:13 <raspbeguy> Hello, I'm still trying to package ptouch-print. Here is my draft so far https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89863 I added argp-standalone as makedepends but build still fails with undefined items. I checked and the items are present in the .h file.
2025-09-09 12:53:07 <liske> raspbeguy: this is a missing libc symbol, isn't it?
2025-09-09 12:53:54 <Habbie> you are not linking against the argp lib
2025-09-09 12:54:06 <Habbie> so the compiler knows the symbol should exist from the .h, but the linker cannot find it as it is not getting the lib
2025-09-09 12:54:58 <raspbeguy> so you mean this isn't in the lib binary itself ?
2025-09-09 12:55:02 <Habbie> no
2025-09-09 12:55:04 <Habbie> i mean you are not using the lib
2025-09-09 12:55:39 <raspbeguy> I thought that should be done automagically using the cmake command
2025-09-09 12:55:49 <Habbie> usually, yues
2025-09-09 12:55:51 <Habbie> yes
2025-09-09 12:55:53 <Habbie> in your case, no
2025-09-09 12:56:45 <Habbie> the cmake logging also does not indicate that it found it
2025-09-09 12:57:16 <Habbie> try setting LDFLAGS=-largp for your cmake call?
2025-09-09 12:59:03 <raspbeguy> I'll try in a bit
2025-09-09 13:40:01 <raspbeguy> Habbie, nope, I added `export LDFLAGS=-largp` in my build function but same error
2025-09-09 13:40:43 <Habbie> what does the linker call look like now?
2025-09-09 13:42:15 <raspbeguy> ninja: job failed: : && /usr/lib/ccache/bin/cc -Os -fstack-clash-protection -Wformat -Werror=format-security -fno-plt -largp CMakeFiles/ptouch-print.dir/src/libptouch.c.o CMakeFiles/ptouch-print.dir/src/ptouch-print.c.o -o ptouch-print  /usr/lib/libgd.so  /usr/lib/libpng.so  /usr/lib/libz.so  /usr/lib/libjpeg.so  -lusb-1.0  /usr/lib/libusb-1.0.so  /usr/lib/libintl.so && :
2025-09-09 13:42:56 <Habbie> ok, -largp did make it in there
2025-09-09 13:43:20 <Habbie> can you try this command by hand in the build dir?
2025-09-09 13:43:24 <Habbie> because then we can try a few changes easily
2025-09-09 13:46:46 <raspbeguy> I guess I have to execute some other commands first
2025-09-09 13:47:06 <Habbie> ah, if it was cleaned, yes
2025-09-09 13:47:17 <Habbie> if it's easier to just edit the APKBUILD, here's a few suggestions, to try *one at a time*
2025-09-09 13:47:45 <Habbie> LDFLAGS=/usr/lib/libargp.a
2025-09-09 13:47:50 <Habbie> LIBS=/usr/lib/libargp.a
2025-09-09 13:48:45 <Habbie> ok nevermind the LIBS one
2025-09-09 13:51:13 <raspbeguy> ok so I tried LDFLAGS=/usr/lib/libargp.a /usr/bin/cc -Os -fstack-clash-protection -Wformat -Werror=format-security -fno-plt -largp CMakeFiles/ptouch-print.dir/src/libptouch.c.o CMakeFiles/ptouch-print.dir/src/ptouch-print.c.o -o ptouch-print  /usr/lib/libgd.so  /usr/lib/libpng.so  /usr/lib/libz.so  /usr/lib/libjpeg.so  -lusb-1.0  /usr/lib/libusb-1.0.so  /usr/lib/libintl.so
2025-09-09 13:51:17 <raspbeguy> same errors
2025-09-09 13:52:56 <Habbie> ok no you're mixing up two things
2025-09-09 13:53:03 <Habbie> either set LDFLAGS before the whole cmake thing
2025-09-09 13:53:15 <Habbie> or when redoing this one call, manually replace -largp with /usr/lib/libargp.a
2025-09-09 13:53:17 <raspbeguy> oh I see
2025-09-09 13:54:31 <raspbeguy> I tried /usr/bin/cc -Os -fstack-clash-protection -Wformat -Werror=format-security -fno-plt /usr/lib/libargp.a CMakeFiles/ptouch-print.dir/src/libptouch.c.o CMakeFiles/ptouch-print.dir/src/ptouch-print.c.o -o ptouch-print  /usr/lib/libgd.so  /usr/lib/libpng.so  /usr/lib/libz.so  /usr/lib/libjpeg.so  -lusb-1.0  /usr/lib/libusb-1.0.so  /usr/lib/libintl.so
2025-09-09 13:54:33 <raspbeguy> same error
2025-09-09 13:54:49 <Habbie> and if you move the libargp item to the end?
2025-09-09 13:55:20 <raspbeguy> oh, no error
2025-09-09 13:55:42 <raspbeguy> binary seems to work
2025-09-09 13:55:45 <Habbie> and a working binary in ..
2025-09-09 13:55:46 <Habbie> yess
2025-09-09 13:55:52 <Habbie> ok, then we know what we want. just need to figure out how to get it
2025-09-09 13:56:04 <Habbie> probably some cmake argument
2025-09-09 13:58:19 <raspbeguy> just to confirm, that works also with -largp at the end instead of /usr/lib/libargp.a
2025-09-09 13:58:27 <Habbie> awesome, that's cleaner
2025-09-09 13:58:45 <Habbie> that will also keep working if a .so appears and the .a goes away etc.
2025-09-09 14:00:25 <raspbeguy> I have no idea about how to do that in cmake though
2025-09-09 14:45:08 <raspbeguy> hum, that seems hard
2025-09-09 14:56:48 <Sertonix[m]> ikke: \o/ Thanks for mentioning!
2025-09-09 14:59:07 <raspbeguy> Habbie, found a way to do it. I hoped that I could make my way in by setting a env variable but no. I had to patch the CMakeLists.txt
2025-09-09 15:00:29 <qaqland> there is a program needs suid, how can i check its security?
2025-09-09 15:01:19 <skarnet> I'm afraid there isn't any shortcut, the only way is a full source code audit
2025-09-09 15:14:04 <raspbeguy> Saijin_Naib[m], could you apply the suggested patch on !86066 when you'll have time please?
2025-09-09 16:08:27 <f_>  15:24 <tumbleweed> (because these aren't local rooms)
2025-09-09 16:08:31 <f_> oops
2025-09-09 16:08:35 <f_>  13:16 <Ermine> f_: how recent are those x86 computers?
2025-09-09 16:09:02 <f_> well I've seen a bunch of atom laptops/small stick that run windows in x86 mode instead of x86_64
2025-09-09 17:13:15 <realroot[m]> WhyNotHugo to help with rocm would be usefult if if do rocprim?
2025-09-09 17:13:25 <realroot[m]> can I install packages from a mr?
2025-09-09 17:26:38 <realroot[m]> is this needed https://gitlab.archlinux.org/tpkessler/rocm-toolchain/-/blob/main/rocm-supported-gfx?ref_type=heads ? in ARCH rocprim depends on it
2025-09-09 20:57:57 <Saijin_Naib[m]> @raspbeguy @Biswa96 thanks, i'll try to get to it this week! 
2025-09-09 23:55:48 <timlegge> achill: I think I have sorted all the MRs for perl-cpanel-json-xs
2025-09-10 02:15:23 <vpzom> Hi, I'm trying to register an account on the GitLab instance, but it's throwing an error "Email is not allowed for sign-up. Please use your regular email address."
2025-09-10 02:15:42 <vpzom> what would be "irregular" about my email address?
2025-09-10 04:16:51 <ikke> vpzom: is it a gmail address with lots of consequtiven umbers or lots of dots or very long?
2025-09-10 04:21:14 <vpzom> no
2025-09-10 04:21:49 <ikke> would you be willing to share the address privately with me?
2025-09-10 11:41:07 <struanr> I've been the person submitting updates for a package in testing for a while now (!89889), as the maintainer hasn't been active on gitlab since 2023. Is there a process for becoming maintainer or should I just update the APKBUILD in the pull request?
2025-09-10 11:54:37 <achill> looks like the maintainer has been gone for a while now
2025-09-10 11:54:44 <achill> just set yourself as the maintainer then
2025-09-10 13:05:07 <raspbeguy> can someone merge this please? !87336
2025-09-10 16:25:10 <EvTheFuture> It seems like there are no more unresolved issues upstream for the proposed patch so would it be ok to go ahead and merge !89513 ?
2025-09-10 16:25:49 <EvTheFuture> upstream PR: https://github.com/BestImageViewer/geeqie/pull/1898
2025-09-10 16:35:36 <Biswa96[m]> the commit message is a bit weird.
2025-09-10 17:25:56 <Saijin_Naib[m]> struanrthanks for keeping it updated. It is quite handy to have
2025-09-11 00:10:07 <struanr> Saijin_Naib[m]: no worries :)
2025-09-11 07:52:53 <raspbeguy> Hello, can someone help for !89665 please? the only build that doesn't pass is riscv64, the reason being timing out after 1h.
2025-09-11 08:02:23 <Biswa96[m]> I thought build timeout is ignored from my vlc MR.
2025-09-11 08:17:18 <achill> you can bump the CI timeout in your project settings under CI
2025-09-11 08:17:23 <achill> raspbeguy
2025-09-11 09:51:12 <raspbeguy> I think I don't have that setting
2025-09-11 09:57:44 <achill> https://gitlab.alpinelinux.org/raspbeguy/aports/-/settings/ci_cd#js-general-pipeline-settings
2025-09-11 09:57:55 <achill> -> timeout -> 6 hour
2025-09-11 12:21:02 <wen> Help ! How can I ask a MR to move community/perl-crypt-urandom to main ? Because the update of main/perl-authen-sasl require it.
2025-09-11 12:21:48 <wen> The update of main/perl-authen-sasl include a CVE fix.
2025-09-11 12:26:00 <ikke> You can do `git mv community/perl-crypt-urandom main/perl-crypt-urandom` and commit that
2025-09-11 12:26:09 <ikke> and make sure the maintainer is aware and agrees
2025-09-11 12:26:51 <ikke> Make sure you include the reason in the commit message
2025-09-11 12:29:09 <wen> Thank you !
2025-09-11 12:54:04 <raspbeguy> achill, I thought that was in the origin repo settings, not my fork. I changed that and launched a run, we'll see if that's better
2025-09-11 12:54:27 <ikke> raspbeguy: The pipeline runs in your repo
2025-09-11 12:55:01 <raspbeguy> sounds logic now that I said that outloud
2025-09-11 12:55:16 <ikke> Only pipelines for developers are created in alpine/aports
2025-09-11 12:58:15 <WhyNotHugo> realroot[m]: you can just clone my branch and run `abuild` for each package as usual
2025-09-11 12:59:31 <WhyNotHugo> yes, rocprim would be useful. it's necessary for rocsparse
2025-09-11 13:25:10 <realroot[m]> * what about the Arch script? There rocprim depends on ithttps://gitlab.archlinux.org/tpkessler/rocm-toolchain/-/blob/main/rocm-supported-gfx?ref_type=heads
2025-09-11 15:23:21 <kaey_> can we merge this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77477 ? been hanging for a while
2025-09-12 05:48:16 <qaqland> #17499
2025-09-12 05:49:14 <qaqland> we have 406 packages use this way
2025-09-12 05:53:52 <indy> hi all, what means mid number in DESCRIPTION file in APKINDEX archive? for example v3.22.1-395-g7ff2feda9bb last is g+ short version of sha1 in aports in branch for release, but 395 is what?
2025-09-12 06:07:07 <qaqland> indy: iirc it's from git describe
2025-09-12 06:13:32 <indy> qaqland, i see, so it is number of commits since last tag
2025-09-12 19:00:03 <ikke> correct
2025-09-12 19:23:39 <caskd> question regarding prohibition of cap_* & o+x, is CAP_SYS_NICE a reasonable exception?
2025-09-12 19:23:51 <caskd> or should it also require a group?
2025-09-12 19:25:47 <caskd> im working on getting monado-service that capability so users can benefit from high priority queues in vk
2025-09-12 19:25:59 <caskd> which makes a big difference
2025-09-12 19:45:37 <caskd> if anyone here uses monado, please give me feedback :)
2025-09-12 19:45:54 <caskd> ill open a MR later asking for feedback more widely on gitlab
2025-09-12 20:19:28 <Shiz> hmm, is it normal that the zfs kernel module is distributed unstripped and with debug symbols?
2025-09-12 20:19:39 <Shiz> i was wondering why it shot up in size and filled up my initramfs, zfs.ko.gz is 30mb+
2025-09-12 20:19:47 <Shiz> zfs.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=44adb95adef5a667a50371393e9365336e5b4139, with debug_info, not stripped
2025-09-12 20:19:53 <Shiz> cc ncopa as you're the maintainer
2025-09-12 20:20:45 <Shiz> :p
2025-09-13 07:25:00 <Hello71> caskd: rtkit?
2025-09-13 07:25:59 <Hello71> I guess for vk maybe it needs to 
2025-09-13 10:24:33 <caskd> Hello71: rtkit is not really nice to interact with and it would add a dependency, the service for monado can't really exec anything else anyways so it should be pretty safe to just let it have it
2025-09-13 10:26:21 <Hello71> most installations probably don't have yama enabled, so that's not a limitation
2025-09-13 10:26:58 <Hello71> afaik ptrace only checks (e)uid, not caps?
2025-09-13 10:27:28 <caskd> huh?
2025-09-13 10:27:40 <caskd> i'm talking mostly about packaging
2025-09-13 10:27:51 <caskd> abuild has checks for caps now too
2025-09-13 10:28:09 <Hello71> an attacker can start the caps binary, then ptrace it to start whatever they want
2025-09-13 10:28:18 <caskd> oh
2025-09-13 10:28:45 <Hello71> at least I'm pretty sure that's allowed without yama
2025-09-13 10:29:15 <Hello71> for deps
2025-09-13 10:30:13 <Hello71> about deps, probably most monado systems will have pipewire which I think needs rtkit? might be mixing up arch and alpine though
2025-09-13 10:30:53 <caskd> pipewire doesn't need rtkit
2025-09-13 10:30:58 <caskd> it can use it but works fine without it
2025-09-13 10:33:48 <caskd> i wasn't aware of the ptrace issue though, that's a good thing to watch out for
2025-09-14 04:20:44 <qaqland> I'm a bit confused, is it correct to directly change 'setup.py' to 'gpep517'? !90060
2025-09-14 04:23:22 <qaqland> can all python projects be done this way?
2025-09-14 09:42:34 <omni> most
2025-09-14 21:19:22 <omni> weird that a browser tab (qt6-qtwbengine) takes a lot of resources to write a comment in gitlab in "plain text", but if I switch to "rich text" it is very smooth and light
2025-09-14 21:39:59 <amadaluzia> i'd see if this issue is replicable on another gitlab instance--gitlab's gitlab instance, or freedesktop's or arch linux's for example--just in case this is just our issue :)
2025-09-14 21:41:29 <amadaluzia> i'm partially hopeful for a return of the email patch system we used to have
2025-09-14 21:51:16 <omni> tried on another gitlab instance and can't reproduce it there
2025-09-14 22:08:35 <amadaluzia> omni: interesting, arch people are usually absurdly up to date with their software so i'll cross check the version there and alpine
2025-09-14 22:09:05 <omni> the other instance was gitlab.torproject.org
2025-09-14 22:09:52 <omni> not sure where else I have a gitlab account
2025-09-14 22:13:36 <amadaluzia> hmm... it seems that arch linux and tor uses the enterprise edition of gitlab
2025-09-14 22:13:45 <amadaluzia> no way to compare on my end :(
2025-09-14 22:13:53 <amadaluzia> i mean, i could try some more
2025-09-14 22:14:11 <amadaluzia> i have a freedesktop gitlab acc for spares
2025-09-14 22:15:05 <amadaluzia> okay, freedesktop alpine has a fairer comparison
2025-09-14 22:18:34 <amadaluzia> freedesktop (18.3.2) > alpine (18.2.6)
2025-09-14 22:18:36 <amadaluzia> hm
2025-09-14 22:53:07 <amadaluzia> has anyone tried to package gitlab yet?
2025-09-14 22:53:11 <amadaluzia> i'm trying myself :P
2025-09-14 23:02:14 <amadaluzia> gitlab is a beast, wow
2025-09-14 23:03:43 <amadaluzia> seems i even have to write the services from scratch since even gentoo and void didn't package it themselves :P
2025-09-15 09:21:36 <Biswa96[m]> achill: could you update the wine MR? the build issue was fixed in 10.15 version.
2025-09-15 10:59:52 <Habbie> gitlab unhappy for everybody or just me?
2025-09-15 11:02:39 <Habbie> not just me, confirmed
2025-09-15 11:11:35 <dne> yep, getting 404 from https://gitlab.alpinelinux.org/api/graphql
2025-09-15 11:12:09 <Habbie> indeed
2025-09-15 12:41:39 <WhyNotHugo> !88742 is ready to merge
2025-09-15 14:52:38 <Imbus> I could use some help with my APKBUILD. https://paste.centos.org/view/47acad0c.
2025-09-15 14:53:02 <Imbus> It fails when trying to cd into subpackage, which im clearly misunderstanding:
2025-09-15 14:53:54 <Imbus>  / usr/bin/abuild: cd: line 2680: can't cd to /storage/aports/community/libhash/pkg/libhash-dev: No such file or directory
2025-09-15 14:54:44 <pj-> you shouldn't cd anywhere and use builddir= to set the extracted package source
2025-09-15 14:55:18 <Biswa96[m]> -dev subpackage is automatically created.
2025-09-15 14:58:28 <Imbus> But its not auto created in my case
2025-09-15 14:58:32 <Imbus> okay pj will correct
2025-09-15 15:06:44 <Imbus> How about this? https://paste.centos.org/view/a340d6bf
2025-09-15 15:06:58 <Imbus> It fails with make: *** No targets specified and no makefile found.  Stop.
2025-09-15 15:07:38 <Biswa96[m]> cd pkgname
2025-09-15 15:07:47 <Biswa96[m]> in build()
2025-09-15 15:08:04 <Imbus> But pj said that you shouldnt cd when using builddir=
2025-09-15 15:09:03 <pj-> you have to adjust builddir= to point to the dir with extracted source
2025-09-15 15:09:09 <pj-> that's what I was trying to say
2025-09-15 15:09:15 <pj-> and then the cd is pointless
2025-09-15 15:10:33 <Biswa96[m]> something like this builddir="$srcdir/$pkgname"  https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Simple
2025-09-15 15:10:39 <pj-> example: https://gitlab.alpinelinux.org/alpine/aports/-/raw/master/testing/zed/APKBUILD
2025-09-15 15:14:29 <Imbus> Cannot get rid of:
2025-09-15 15:14:32 <Imbus>  /usr/bin/abuild: cd: line 2680: can't cd to /storage/aports/community/libhash/pkg/libhash-dev: No such file or directory
2025-09-15 15:16:05 <PureTryOut> replace package_dev for just dev. currently the logic to automatically find the right files to put in a -dev package can't find such files so you need to override it and you do that by using dev as the function name rather than package_dev
2025-09-15 15:17:02 <PureTryOut> but it's better to install the files in the package function and let the auto -dev stuff handle things. Also add a -static subpackage for that static archive
2025-09-15 15:26:04 <Imbus> Whats the auto -dev stuff?
2025-09-15 15:27:08 <Imbus> Revision 2: https://paste.centos.org/view/1155fd81
2025-09-15 15:27:40 <Imbus> With error: install: can't stat 'hash/djb2.h': No such file or directory
2025-09-15 15:27:48 <pj-> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#dev()
2025-09-15 15:49:22 <Imbus> Got it working, added a static: https://paste.centos.org/view/42f3ffa9
2025-09-15 15:49:35 <Imbus> Does this look idiomatic?
2025-09-15 15:52:55 <pj-> not really, -dev and -static would automatically move that
2025-09-15 15:53:16 <pj-> look at https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/libgit2/APKBUILD for example
2025-09-15 15:53:26 <pj-> or any other library with -dev/-static
2025-09-15 15:54:18 <pj-> it's all "installed" in package() and abuild knows that it should move static archive/headers because it's defined in subpackages, and  it does that for you
2025-09-15 17:09:09 <Imbus> So, i got it to build correctly without any subpackages. The subpackages fail with:
2025-09-15 17:09:12 <Imbus>  /usr/bin/abuild: cd: line 2680: can't cd to /storage/aports/community/libhash/pkg/libhash-static: No such file or directory
2025-09-15 17:10:07 <Imbus> But its only the -static that fails. The -dev behaves as expected for some reason
2025-09-15 17:11:03 <Imbus> For reference, https://paste.centos.org/view/a11f489d
2025-09-15 17:11:47 <Imbus> i cant for the life of me figure this out
2025-09-15 17:17:57 <bulldozer> I have a 3 weeks old MR that has had no feedback nor approval but the package's maintainer seems to have been very active during this time.  What is the appropriate action to take to ensure this MR gets approved as fast as possible?
2025-09-15 17:37:27 <ikke> bulldozer: what MR?
2025-09-15 18:08:53 <achill> btw help regarding !89855 is very appreciated, i wont have time in the near future to fix all failures (many are also gcc15 related), but there is a list of failing packages
2025-09-15 18:09:43 <ikke> another ABI break?
2025-09-15 18:10:02 <achill> its just the old libxml 2.14 upgrade we had reverted
2025-09-15 18:10:13 <achill> actually i dont know if 2.15 also breaks abi
2025-09-16 05:23:40 <Saijin_Naib[m]> !87826 has been open for a month, it passes CI, and I don't think anyone has tested nor objected to it
2025-09-16 05:23:48 <Saijin_Naib[m]> Should it be merged or do I need to lobby for more testing first?
2025-09-16 05:24:41 <ikke> ptrc: ^
2025-09-16 05:24:44 <achill> in general, ptrc is the maintainer and didn't approve it yet
2025-09-16 05:27:00 <Saijin_Naib[m]> Yeah, just didn't know if they had the bandwidth to review/test or if I need to be the one to get folks onboard to test and report back
2025-09-16 05:27:07 <Saijin_Naib[m]> Since it was my MR to update it and tweak it
2025-09-16 05:46:59 <Saijin_Naib[m]> raspbeguyBiswa96thanks for the help, !86066 is finally ready
2025-09-16 08:28:32 <tw_> I'm not sure whether I have already posted this here, excuse me if that's the case, but packaging river should've changed since the last release.
2025-09-16 08:28:44 <tw_> The details are on codeberg.com/river/river.
2025-09-16 08:28:47 <tw_> https://codeberg.org/river/river/releases/tag/v0.3.12
2025-09-16 08:54:53 <z3ntu> For me git fetch for aports is super slow, anything going on with gitlab right now?
2025-09-16 08:55:39 <achill> apparently yeah
2025-09-16 09:03:13 <z3ntu> achill: if you have a minute: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90190 Then I can start CI again for a different MR
2025-09-16 09:03:53 <achill> done
2025-09-16 14:01:37 <ptrc> Saijin_Naib[m]: sorry for the delay, approved and merged now
2025-09-16 17:23:37 <pc_magas> hello I resolved all issues upon https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79350
2025-09-16 17:39:39 <Saijin_Naib[m]> ptrcNo, no worries at all! I know you, like pretty much everyone else, are slammed. I just wanted to see what I needed to move forward
2025-09-16 17:55:18 <Saijin_Naib[m]> Is the Approval thing in GitLab tied to a developer/maintainer account role?
2025-09-16 17:55:38 <Saijin_Naib[m]> I have two patches folks made for aports of mine that look great, but I can't mark either Approved despite them being assigned to me
2025-09-16 18:02:43 <mio> Saijin_Naib[m]: is it xfce4-mpc-plugin and lutris?
2025-09-16 18:02:57 <achill> someone in #alpine-infra can give you 'guest'-permissions that allow to approve
2025-09-16 18:03:08 <achill> but you can also write "LGTM" which is excatly the same in the end
2025-09-16 18:03:39 <achill> also, please add your email address you used in the apkbuild maintainer fields also to your gitlab account so that the bot can assign them to you
2025-09-16 18:03:45 <mio> Saijin_Naib[m]: just leave a comment in the meantime, or upvote in the MR
2025-09-16 18:04:28 <achill> (upvote have a bad discoverbility, comments are much more visible)
2025-09-16 18:05:16 <mio> not necessarily, a comment doesn't show up in the MR list on web ui, but thumb up does, even if it doesn't indicate who added it
2025-09-16 18:05:45 <mio> a comment/review open thread shows in the list view, but not for single comment
2025-09-16 18:06:01 <mio> guess it depends on the ui
2025-09-16 18:18:46 <Sertonix[m]> Some people thumb up their own MRs which can make them misleading
2025-09-16 18:24:03 <mio> yeah, it doesn't indicate in list view who upvoted
2025-09-16 18:26:46 <mio> it's another relative indicator of activity besides a timestamp in small font
2025-09-16 20:00:31 <andar1an> is anyone having trouble with merge requests right now? 
2025-09-16 20:00:53 <f_> What do you mean by that?
2025-09-16 20:00:55 <andar1an> getting a 500
2025-09-16 20:01:04 <andar1an> but I was able to log in
2025-09-16 20:01:19 <andar1an> just 500 when trying to create PR
2025-09-16 20:02:23 <ikke> andar1an: Are you following the link after pushing a branch?
2025-09-16 20:02:32 <ikke> andar1an: Your forks target branch may be too much out of date
2025-09-16 20:02:55 <andar1an> ah crap, I forgot to sync my repo, that is probably it. thanks @ikke
2025-09-16 20:05:06 <andar1an> does gitlab have a feature to keep main in sync at a specific cadence? Github requires an action
2025-09-16 20:08:51 <ikke> Not aware of anything
2025-09-16 20:09:03 <ikke> I use glab to create MRs, so never run into that issue
2025-09-16 20:09:24 <ikke> It's just the page that wants to show the commits you are proposing to create an MR for that is timing out
2025-09-16 20:16:08 <andar1an> I was using glab to create mr too. I just always forget to sync fork, and don't touch enough. I find that to be tedious whatever provider, especially if you fork to follow/archive
2025-09-16 20:33:01 <andar1an> my bad, you meant cli, that is cool, ty.
2025-09-16 21:26:43 <Saijin_Naib[m]> @mio yes, lutris and xfce4-mpc-plugin for now. I'll ask for guest, and add that email. Thanks! 
2025-09-16 21:37:29 <mio> Saijin_Naib[m]: you're welcome, thanks for checking the MRs
2025-09-17 05:25:08 <lotheac> phew... successfully booted alpine installer on aarch64 lenovo yoga 7x, only took a few days :)
2025-09-17 07:23:02 <raspbeguy> could somebody have a look at !87884 and !78807 please?
2025-09-17 17:32:26 <craftyguy[m]> Sertonix does this mean we have to start using sha256 for index signing in order for apk to work on Fedora (and other distros that disable SHA1 in openssl)? https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11139#note_542135
2025-09-17 17:41:43 <Sertonix[m]> For the v2 file formats SHA1 hashes won't go away. The v3 file formats use SGA256 everywhere so they should work fine. The issue in my opinion is just to include an alpine index in the test suite. Would be fixed with the commit I linked. Not sire how quickly alpine will move to v3 indexes or even packages.
2025-09-17 17:46:12 <craftyguy[m]> yeah the bigger problem, imho, is that the alpine indexes don't support sha256 :(
2025-09-17 17:47:00 <craftyguy[m]> I'm trying to upstream support for pmOS in mkosi, and tl;dr: it's basically blocked on this issue 🤣
2025-09-17 17:50:00 <Sertonix[m]> apk.static should work though?
2025-09-17 17:52:09 <Sertonix[m]> And as soon as we use v3 index you will probably notice that this isn't enough. All packages would need to be rebuild in the v3 file format as well. That won't happen quickly
2025-09-17 17:55:30 <craftyguy[m]> yeah I'm going to see if I can use apk.static, it does work
2025-09-17 17:55:55 <craftyguy[m]> yeah... I understand that this won't get fixed on our side 'quickly' :P
2025-09-17 18:01:55 <achill> can we not just generate the v3 index side-by-side and let fedora already use that one?
2025-09-17 18:02:01 <achill> (i.e. https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/425)
2025-09-17 22:11:13 <Ariadne> achill: why does fedora need v3 indexes?  we still support the v2 indexes today
2025-09-17 22:12:27 <craftyguy[m]> Ariadne: because they disable SHA1 verification stuff by default in openssl. There's an env var I can use to enable it anyways, but no one knows how long that'll keep working.
2025-09-17 22:12:59 <Ariadne> then we should programatically enable SHA1 in apk
2025-09-17 22:13:10 <craftyguy[m]> so running apk in Fedora to fetch Alpine indexes fails with a super vague "crypto error", and it's because of the SHA1 digest stuff. I debugged it in that comment I linked to earlier
2025-09-17 22:13:18 <craftyguy[m]> yeah, that's one way
2025-09-17 22:13:51 <Ariadne> if apk is explicitly requesting SHA1, then we should ensure openssl is configured appropriately
2025-09-17 22:15:00 <craftyguy[m]> by implementing SHA1 in apk?
2025-09-17 22:15:15 <Ariadne> no, by ensuring the legacy openssl provider is loaded :)
2025-09-17 22:16:09 <craftyguy[m]> ig there's some system policy thing in fedora/rh/whatever that disables SHA1 support in openssl. idk how this works. but I can work around it for the stuff I'm doing by setting OPENSSL_ENABLE_SHA1_SIGNATURES=1 🤷‍
2025-09-17 22:23:41 <Ariadne> i found the patch, if we explicitly use SHA-1 from the legacy provider it should be fine
2025-09-17 22:27:31 <craftyguy[m]> I'm probably the wrong person to make that change in apk-tools haha
2025-09-17 22:43:04 <Ariadne> anyway your patch is simple enough
2025-09-17 22:43:07 <Ariadne> it is basically
2025-09-17 22:43:21 <Ariadne> +/* work around redhat nanny state shenanigans */
2025-09-17 22:43:31 <Ariadne> +setenv("OPENSSL_ENABLE_SHA1_SIGNATURES", "1");
2025-09-17 22:50:06 <craftyguy[m]> oh, yeah the comment from Neal was something like "we don't know how long they'll keep this patch" to enable turning on SHA1 stuff. The patch is downstream / in Fedora pkging and stuff
2025-09-17 23:59:01 <craftyguy[m]> is there an existing issue somewhere where folks are discussing what to do about apk-tools and "recommends" ? Context: https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/2089f8a8225b812c982cd253aa5fcd74d5099c3a
2025-09-17 23:59:14 <craftyguy[m]> I didn't see anything obvious in the apk-tools issues
2025-09-18 04:20:24 <ikke> Great, libxml2 maintainer also stepping down
2025-09-18 04:20:57 <ikke> https://discourse.gnome.org/t/stepping-down-as-libxml2-maintainer/31398
2025-09-18 05:18:14 <achill> yeah afaik theyve been understaffed a long time
2025-09-18 05:19:03 <achill> and big monopoly companies using libxml without giving back doesnt help
2025-09-18 05:20:00 <achill> craftyguy[m]: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10722
2025-09-18 05:21:58 <craftyguy[m]> achill: thank you :)
2025-09-18 05:23:13 <Saijin_Naib[m]> If only people put even a little money where their value was
2025-09-18 05:24:15 <Saijin_Naib[m]> So, I'm trying to package darkradiant to edit maps for doom3/quake4/darkmod and iDTech4 engine games, and the build is failing on missing execinfo.h
2025-09-18 05:24:24 <Saijin_Naib[m]> Searching aports, that looks like only zig provides that
2025-09-18 05:24:33 <Saijin_Naib[m]> Adding zig to makedepends does not change this failure
2025-09-18 05:24:43 <Saijin_Naib[m]> I have seen this before, and I'm lost on how to resolve it
2025-09-18 05:24:48 <Saijin_Naib[m]> https://bpa.st/DZDA
2025-09-18 05:25:00 <Saijin_Naib[m]> Am I missing something simple?
2025-09-18 05:25:13 <achill> execinfo.h is not supported in musl just patch it out
2025-09-18 05:25:31 <Saijin_Naib[m]> What would that look like?
2025-09-18 05:25:53 <Saijin_Naib[m]> comment out all the includes for it or something in the makefile(s)?
2025-09-18 05:26:20 <achill> there are many examples in ls //execinfo.patch
2025-09-18 05:27:05 <achill> maybe the project also already has a build option for it
2025-09-18 05:35:11 <Saijin_Naib[m]> Thanks for the guidance. I'm going to see if what I did will work
2025-09-18 05:35:42 <Saijin_Naib[m]> It is only used in their SegFaultHandler, so I don't think it is super critical
2025-09-18 05:49:52 <achill> yeah it usually isnt
2025-09-18 06:06:50 <Saijin_Naib[m]> my diff/patch file is broken
2025-09-18 06:06:53 <Saijin_Naib[m]> why is this so hard haha
2025-09-18 06:07:38 <Saijin_Naib[m]> cant find the file to be patched
2025-09-18 06:07:54 <Saijin_Naib[m]> Looking at the other patches, they use a/src/path followed by b/src/path
2025-09-18 06:08:30 <Saijin_Naib[m]> Am I right that src is the src folder that is unpacked when using abuild, so the path that follows should be from that point in the folder structure down to the file?
2025-09-18 06:20:17 <ikke> Yes, relative to $builddir
2025-09-18 06:24:14 <Saijin_Naib[m]> Ah, okay, thanks
2025-09-18 06:28:43 <Saijin_Naib[m]> beautiful, thanks ikke
2025-09-18 06:28:51 <ikke> I typicaly init a new git repo in there, commit everything,cand the make changes
2025-09-18 06:29:10 <ikke> The git diff output is the patch 
2025-09-18 06:30:04 <Saijin_Naib[m]> Yeah, I see most of the patch files for execinfo have a git diff structure
2025-09-18 06:30:24 <Saijin_Naib[m]> I used Meld to make mine, which I guess didn't set me off on the right foot since the paths were weird
2025-09-18 07:24:11 <Saijin_Naib[m]> That got me further, but now it is failing on backtrace function in that same cpp file
2025-09-18 07:24:12 <Saijin_Naib[m]> https://bpa.st/GOAA
2025-09-18 07:24:45 <Saijin_Naib[m]> backtrace was not declared in this scope
2025-09-18 07:24:54 <Saijin_Naib[m]> Can I just... patch that out, too?
2025-09-18 07:28:23 <achill> probably yes
2025-09-18 07:29:03 <Saijin_Naib[m]> Hmm, okay, thanks
2025-09-18 07:29:13 <Saijin_Naib[m]> I'll give that a go then
2025-09-18 09:00:12 <fisssion> So to recap
2025-09-18 09:00:23 <fisssion> "omni" = nir lichtman (or as i like to call it, mnyookman)
2025-09-18 09:00:30 <fisssion> f_ = prolly 1# bitch skid of his
2025-09-18 09:00:37 <fisssion>  Clayton Craft is another skid
2025-09-18 09:00:49 <f_> to recap I see 40000% chance that you are a troll
2025-09-18 09:00:54 <f_> ikke: ^
2025-09-18 09:00:59 <f_> and -z
2025-09-18 09:01:10 <f_> oh nvm already -z'd
2025-09-18 09:02:45 <Ermine> They're on #alpine-hardened too
2025-09-18 09:08:36 <Ermine> geez
2025-09-18 09:08:43 <f_> geez indeed
2025-09-18 09:10:19 <Ermine> hopefully we're not getting alpine joss
2025-09-18 09:10:47 <f_> he reminds me of some other spammer I had to help some ops deal with
2025-09-18 09:11:13 <f_> even had to bring a bot to autodetect the vpns they used and autoban
2025-09-18 09:11:19 <f_> and stuff
2025-09-18 09:15:25 <f_>  11:14 ::: fisssion [~fisssion@9O6AAHUWV.tor-irc.dnsbl.oftc.net] has quit (autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2025-09-18 
2025-09-18 09:15:27 <f_>           09:14:26))
2025-09-18 09:15:39 <f_> nice, I still recommend the +q
2025-09-18 09:16:03 <f_> tbh it's quite common to +q uncloaked tor users.. and I guess you now know why
2025-09-18 10:48:40 <kcxt_m> damn, alpine gitlab blocked on my phone from my home IP? who do i ping with the magic request ID a899ce48460e4054825de1cecd4a5a72
2025-09-18 11:23:19 <pj> ikke
2025-09-18 11:42:47 <ikke> kcxt_m: it failed a very bassic http fallback check
2025-09-18 11:44:19 <ikke> kcxt_m: Is the browser blocking cookies?
2025-09-18 11:44:46 <kcxt_m> it's firefox on ios with maybe the safari adblock extension
2025-09-18 11:44:52 <kcxt_m> safari itself works though
2025-09-18 11:59:44 <wen> Help! I had 9 MRs which build well and passed check, but no comment, no merge, could anyone have a look of it ? Merge it if it is OK, then I can continue the follow-up work. 
2025-09-18 12:05:42 <ikke> I don't see any open MRs for wen
2025-09-18 12:06:37 <ikke> Oh, different username
2025-09-18 13:25:01 <z3ntu> Is there anything that could block https git clones from Alpine GltLab?
2025-09-18 13:25:06 <z3ntu> Cloning into 'aports-proxy-bot'...
2025-09-18 13:25:06 <z3ntu> error: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403
2025-09-18 13:25:06 <z3ntu> 
2025-09-18 13:25:06 <z3ntu> $ git clone https://gitlab.alpinelinux.org/alpine/infra/aports-proxy-bot.git
2025-09-18 13:25:06 <z3ntu> fatal: expected flush after ref listing
2025-09-18 13:26:31 <z3ntu> I cannot reproduce this from other machines, just one where I've got this set up
2025-09-18 13:33:57 <ikke> We received a lot of (excessive) git clone / fetch traffic from that AS (many IP addresses)
2025-09-18 14:04:11 <camelia> hi everyone!
2025-09-18 14:05:40 <camelia> i'm here because one of my aport merge request got flagged as stale, and the bot told me that it may get closed in the future if it doesn't get any new activity
2025-09-18 14:06:27 <camelia> however, the merge request was already reviewed by someone and is just waiting for someone with merge access to review. I was wondering what I should do
2025-09-18 14:07:05 <ikke> What MR?
2025-09-18 14:07:30 <camelia> it's !88635
2025-09-18 14:07:50 <lotheac> the bot message is a bit misleading :) generally the developers with merge rights just haven't had time to get to it yet
2025-09-18 14:09:15 <camelia> ohh okay I see thanks! I can leave it as it is and it wont get automatically closed then?
2025-09-18 14:10:10 <lotheac> in my experience, correct. i don't think i've ever seen anything autoclosed
2025-09-18 14:10:36 <ikke> There is nothing to auto close MRs
2025-09-18 14:10:48 <ikke> If MRs are closed, it's done manually
2025-09-18 14:11:41 <camelia> ok thanks a lot! I was afraid there was something like github does (I think), where old issues are automatically closed. I will wait then :P
2025-09-18 16:01:37 <f_> camelia: this is horribly awful so alpine doesn't do it :P
2025-09-18 17:27:50 <Habbie> github does not do that; but many organisations/repos on github do this
2025-09-18 20:30:05 <pj> > Tier 3 musl targets now link dynamically by default.
2025-09-18 20:30:42 <pj> so close to having proper linkage in rust
2025-09-18 21:18:05 <Habbie> nice
2025-09-18 22:13:30 <omni> as in upstream rust?
2025-09-18 22:31:13 <omni> ah, now I caught up
2025-09-19 06:17:23 <Saijin_Naib[m]> !90369, I have disabled all tests because I couldn't get xvfb-run and vglrun to cooperate with the builder and like, 90% of the tests subsequently fail. Seems to work fine locally, however
2025-09-19 06:17:47 <Saijin_Naib[m]> For situations like this, can I leave the checkdepends and check function in and commented out in case I or someone else fixes it later?
2025-09-19 09:45:20 <Sertonix[m]> It's better to keep them not commented out to allow running abuild check locally more easily.
2025-09-19 12:39:49 <Saijin_Naib[m]> Hmm, but it fails and kills the build if not commented
2025-09-19 12:53:41 <ikke> You can add !check to options with a comment to disable the checks 
2025-09-19 15:03:11 <Saijin_Naib[m]> And linter wont be mad about checkdepends and the check function not being commented?
2025-09-19 15:04:15 <ikke> Correct 
2025-09-19 15:19:46 <Saijin_Naib[m]> I'll fix that, thanks
2025-09-19 16:47:48 <craftyguy[m]> I'm trying to understand what `apk add --latest` does exactly and when it would be appropriate to use it... the manpage entry for this option is a bit cryptic for me to read.. does this mean it ignores providers and stuff and *only* looks at "real" packages + versions?
2025-09-19 16:51:26 <craftyguy[m]> I'm asking, because this gives a confusing error: `apk add -s --latest udev` ... "Huh? Error reporter did not find the broken constraints." 
2025-09-19 17:43:48 <fabricionaweb> my rootbld is giving me error Read-only file system, did something changed?
2025-09-19 17:45:01 <Sertonix[m]> Have you configured any paths to be in different positions? (Error message would be helpful)
2025-09-19 17:48:26 <Sertonix[m]> [@craftyguy:postmarketos.org](https://matrix.to/#/@craftyguy:postmarketos.org) That error message means that there is an apk bug. Ideally would be to find a reproducer of the issue in a clean environment.
2025-09-19 17:49:26 <fabricionaweb> lol yeah that was it Sertonix, thanks, just lack of attention... I missed the "$pkgdir" scope
2025-09-19 17:52:47 <Saijin_Naib[m]> does anyone have pointers on invoking check with both xvfb-run and vglrun?
2025-09-19 17:53:04 <Saijin_Naib[m]> The one example I had looks like xvfb-run -a vglrun check... etc
2025-09-19 18:07:37 <craftyguy[m]> Sertonix can you help me understand the purpose of --latest and why someone would use it? or point me to more documentation other than the manpage about it?
2025-09-19 18:39:55 <Sertonix[m]> I think when the added package is already installed it will essentially check all repositories and the installed db and select the highest version
2025-09-19 18:40:31 <Saijin_Naib[m]> !90369 is ready for testing/review if anyone has the bandwidth. Editing works nicely here, so I think it is good. Still have not figured out the testsuite, but I'm registering to The Dark Mod Community to try and get some help there about that
2025-09-19 18:40:52 <Saijin_Naib[m]> Hopefully that will make packaging The Dark Mod itself a bit closer for me, as well
2025-09-19 18:40:54 <craftyguy[m]> Sertonix it kinda sounds like what --upgrade does though
2025-09-19 19:13:28 <Sertonix[m]> --latest affects only a single condition. Maybe it's about showing an error when the latest version isn't selectable? https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/225e3ebd25c4bcd821b49369fd7c328a8ed09b43/src/solver.c#L559
2025-09-19 19:15:44 <craftyguy[m]> Hmm ok, ya I looked at that earlier but couldn't make sense of it (I'm not familiar with apk-tools codebase)... I'm hitting this downstream in pmOS, and can't seem to find a way to reproduce it using only Alpine aports.
2025-09-19 20:18:06 <iggy> craftyguy[m]: I think --latest is useful for when you change repo versions to make sure you have the latest version of packages (i.e. you go from 3.21 -> 3.22 but they both have libsomething-0.2.0, --latest will make it install the one from 3.22 even though the same version is already installed)
2025-09-19 20:18:19 <iggy> at least that's the way it was described to me once
2025-09-19 20:21:25 <craftyguy[m]> that kinda sounds like what apk upgrade --available does (install the version available in the repos)
2025-09-19 20:21:58 <craftyguy[m]> so does it basically do --available for apk add (which doesn't have that flag) ? /me still confused
2025-09-19 21:07:07 <craftyguy[m]> hmm what's going on with the CI runners? https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/2020033
2025-09-19 21:34:18 <iggy> nvm, you're right, I was thinking of --available... I should have checked my shell history :(
2025-09-19 21:46:07 <craftyguy[m]> no worries :)
2025-09-19 21:50:43 <craftyguy[m]> wow the CI build script really doesn't like this apkbuild, it just fails silently every time...
2025-09-19 21:54:43 <craftyguy[m]> ah, a typo in the apkbuild. sheesh
2025-09-19 21:55:04 <craftyguy[m]> (but apkbuild-lint and everything passed 🤷)
2025-09-20 05:39:59 <Saijin_Naib[m]> Anyone wanna try !90449
2025-09-20 05:40:21 <Saijin_Naib[m]> It crashes here immediately with the arx_fatalis demo file, but that could just be my really crap Intel iGPU
2025-09-20 12:54:40 <WhyNotHugo> !89436 was a draft for quite a while but is now ready to merge
2025-09-20 13:01:38 <ffoss> c
2025-09-20 13:13:48 <ikke> fabled_: it seems apk prefers dash-binsh to busybox-binsh on the builders, pulled in through the '/bin/sh' provides, even though busybox-binsh has a higher provider_priority. Any idea why?
2025-09-20 14:53:02 <craftyguy[m]> are there any tricks for building multiple rust apps in a branch/MR for the aports CI that tend to use some of the same deps/crates, to cache/reuse the deps/crates without recompiling them every time?
2025-09-20 14:55:31 <Biswa96[m]> like this? https://github.com/mozilla/sccache (assuming the cache directory is not removed between building two packages)
2025-09-20 14:56:05 <Biswa96[m]> I have not tried that in CI though
2025-09-20 14:57:07 <craftyguy[m]> yeah I've heard of that, but also not sure how well it would work in CI...
2025-09-20 15:06:07 <ikke> craftyguy[m]: is this something cargo does by default? The ~/.cargo directory is preserved between builds in the same job
2025-09-20 15:35:58 <craftyguy[m]> idk. it doesn't seem to be reusing anything, if I look at the CI build job for a MR that has ~20-something rust apps being built. I'll try to poke around a bit more though, I was just curious if anyone here knew
2025-09-20 17:13:53 <raspbeguy> Hello, for some reason package testing/reap is not available on riscv64. However I have the build log saying that building was successful https://build.alpinelinux.org/buildlogs/build-edge-riscv64/testing/reap/reap-0.2-r0.log
2025-09-20 17:26:57 <ikke> The builder is still building. Packages are only uploaded after a specific repository is finished
2025-09-20 17:47:34 <raspbeguy> Oh really?
2025-09-20 17:49:40 <raspbeguy> This logfile is dated from 2 days ago
2025-09-20 17:51:41 <ikke> raspbeguy: php85 is failing
2025-09-20 17:52:03 <raspbeguy> Oh I see then
2025-09-20 18:08:29 <ikke> fabled_: turns out because we run `apk del busybox-binsh`, it deselects that package. Doing it the other way around (adding dash-binsh, and then removing it) causes busybox-binsh to be selected
2025-09-20 18:12:36 <fabled_> ikke: Iirc there was change to have apk del to remove the package if possible in case there are alternative providers
2025-09-20 18:13:25 <ikke> fabled_: ultimately this was caused by a package that pulled in dash-binsh, and then that remained after the deps were removed
2025-09-20 18:17:31 <fabled_> Why is del busybox-binsh done?
2025-09-20 18:18:10 <ikke> fabled_: that was done to get rid of the explicit busybox-binsh in world
2025-09-20 18:18:34 <fabled_> See: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11015
2025-09-20 18:19:43 <fabled_> Or more specifically the commit https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/30f89ce0ca4a912214b3702bca539601a0a54631
2025-09-20 18:20:35 <fabled_> Se del now actually deletes deinstalls the named package if the dependencies can by satisfied by substituting it with another package 
2025-09-20 18:21:32 <fabled_> But if those packages depend on BusyBox ash, they should depend on it
2025-09-20 18:21:42 <ikke> They depend on /bin/sh
2025-09-20 18:21:54 <fabled_> Then they should work with dash too
2025-09-20 18:22:24 <fabled_> Though, agreeably having the builder be in same state always is a good thing...
2025-09-20 18:22:41 <ikke> It does kind of break the assumption that apk add / del manipulate world 
2025-09-20 18:22:54 <ikke> (or just manipulate world) to be more exactly
2025-09-20 18:23:37 <ikke> busybox-binsh has a higher provider_priority
2025-09-20 18:24:24 <ikke> having those packages explicitly pull in ash would probably prevent the other implementations to be installed completely
2025-09-20 18:24:42 <ikke> all provide cmd:sh and /bin/sh
2025-09-20 18:24:49 <ikke> so they are mutually exclusive
2025-09-20 18:26:54 <fabled_> Can't remember immediately all details as the selection is a complex process. But the package installed state also is used as tie breaker in some cases.
2025-09-20 18:27:03 <ikke> https://tpaste.us/N5Lk 
2025-09-20 18:27:13 <ikke> relevant solver output with PRINT_DEBUG
2025-09-20 18:27:27 <ikke> That's how I found out
2025-09-20 18:28:19 <fabled_> What was the command ran?
2025-09-20 18:28:26 <ikke> apk del busybox-binsh
2025-09-20 18:28:57 <fabled_> Yes. This changed with the commit referenced above
2025-09-20 18:33:02 <fabled_> I wonder if that should be somehow refined when the removal preference is applied.
2025-09-20 18:36:08 <fabled_> Could you create an issue about this?
2025-09-20 18:36:19 <ikke> sure
2025-09-20 18:41:18 <fabled_> I suppose the remove preference should be applied only when it's a tie. Provides_preference should probably win the bin/sh case.
2025-09-20 18:41:54 <fabled_> Does a later "upgrade" change it back to BusyBox?
2025-09-20 18:42:14 <ikke> No, it does not
2025-09-20 18:42:23 <ikke> I tried apk upgrade --available and nothing happened
2025-09-20 18:45:32 <fabled_> Yes. Seems the "currently installed" wins over "preference by provider priority"
2025-09-20 18:46:10 <ikke> right
2025-09-20 18:46:25 <ikke> So is that the issue I should report?
2025-09-20 18:49:35 <fabled_> I think so. That's the main difference and only disambiguation possible. Basically provider_priority should be stronger than installed state or "apk del" removal hint.
2025-09-20 18:56:30 <ikke> btw, is there a way for apk query to return the provider_priority of a package?
2025-09-20 18:56:44 <ikke> priority or provider_priority are not recognized
2025-09-20 18:59:09 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11142
2025-09-20 19:03:34 <fabled_> ikke: thanks! https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-query.8.scd?ref_type=heads#L82
2025-09-20 19:03:54 <ikke> ah, with a dash
2025-09-20 19:04:03 <ikke> I checked the output of query --help, forgot to check the man page, thansk
2025-09-20 19:04:51 <fabled_> I'll try to look at the issue tomorrow 
2025-09-20 19:05:22 <ikke> Sure, no problem. I've fixed the builders
2025-09-20 19:13:36 <fabled_> Meant Monday...
2025-09-20 19:46:08 <ikke> sure
2025-09-21 15:09:06 <caskd> hello, is nld.t1.alpinelinux.org down?
2025-09-21 15:09:28 <caskd> i get connection refused errors from it since 2025-09-14
2025-09-21 15:22:24 <ikke> yes, it's part of the HW that we are decommissioning. We never really advertised those domains though
2025-09-21 15:23:19 <ikke> I was planning to move those domains to the new infra, but I need to setup certificates for those
2025-09-21 15:24:04 <caskd> oh okay
2025-09-21 15:24:09 <caskd> well i can fallback to v4
2025-09-21 15:24:16 <caskd> but i mainly used that because v6 
2025-09-21 18:34:37 <daedaevibin[m]> Suggestion:
2025-09-21 18:34:37 <daedaevibin[m]> The hardware world is changing rapidly, and the current kernel is missing important components that likely can’t be fully backported (e.g., Wi-Fi drivers, NVMe support, CPU schedulers, security patches, firmware updates, etc.). A newer kernel would ensure better compatibility, performance, and security for users.
2025-09-21 18:34:37 <daedaevibin[m]> .
2025-09-21 18:34:37 <daedaevibin[m]> Use a newer kernel version in stable releases (at least 6.7–6.10).
2025-09-21 18:53:09 <ikke> daedaevibin[m]: alpine 3.22 has linux-lts 6.12
2025-09-21 18:53:28 <daedaevibin[m]> The message was deleted. You must be on IRC as well
2025-09-21 18:53:40 <ikke> Yes, no takesies backsies
2025-09-21 18:54:03 <ikke> This is an irc-first channel
2025-09-21 18:54:30 <daedaevibin[m]> I deleted it and marked it as "redundant" because I went and checked.
2025-09-21 18:54:30 <daedaevibin[m]> Alpine 3.22.1 (latest stable) uses 6.12 LTS I believe 
2025-09-21 18:58:51 <ikke> Correct