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
2025-09-22 06:52:14 <ikke> glib 2.86 breaks awesomewm for me
2025-09-22 06:54:44 <ikke> https://tpaste.us/5QZ0
2025-09-22 06:59:41 <ikke> Apparently GObject.TypeClass.ref has been deprecated in glib 2.84
2025-09-22 07:04:35 <ikke> Ok, simple patch to lua-lgi
2025-09-22 07:33:26 <omni> ikke: what's the patch?
2025-09-22 07:38:00 <ikke> https://tpaste.us/vodL
2025-09-22 07:39:23 <ikke> That misses a pkgrel bump
2025-09-22 07:45:13 <omni> ok, because I'm looking at !90518
2025-09-22 08:35:27 <ikke> 👍
2025-09-22 09:56:06 <PureTryOut> pabloyoyoista: just did the usr-merge on my work Alpine VM, works nicely 👍️ Going to do it on my laptop and desktop when I'm home too, great work!
2025-09-22 09:56:43 <f_> I did it a long while ago and it worked awesome with no issues
2025-09-22 09:57:00 <f_> Only logbookd/logview was an issue but that got fixed quickly
2025-09-22 11:51:55 <proycon> Could someone take a look at merging https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86932 ? Has been ready for merge for about 2 months. Pretty simple standalone CLI tool.
2025-09-22 12:13:01 <pabloyoyoista> PureTryOut: thanks a lot for the heads up!
2025-09-22 13:30:25 <ffoss> Also just did the usr-merge on my laptop, now it is boot looping :/
2025-09-22 13:33:16 <ffoss> I'm getting `fsck.vfat: unrecognized option: C`
2025-09-22 13:34:32 <ffoss> it then prints the fsck.vfat help message, then `Filesystems repaired, but reboot needed` then reboots repeat
2025-09-22 13:43:02 <Sertonix[m]> ffoss: Can you configure your bootloader to add "single" to the kernel arguments?
2025-09-22 13:46:53 <ffoss> Sertonix[m]: I managed
2025-09-22 13:47:45 <Sertonix[m]> Then you should be dropped into a shell with your rootfs mounted at /sysroot
2025-09-22 13:48:58 <ffoss> I'm in the shell, but /sysroot is empty
2025-09-22 13:50:24 <Sertonix[m]> When the sysroot is mounted you want to run: sed -i 's/readlink -f/readlink/' /sysroot/etc/init.d/fsck
2025-09-22 13:51:28 <Sertonix[m]> What kind of root filesystem are you using? You somehow want to mount that at /sysroot
2025-09-22 13:54:02 <ffoss> Just the default, ext4 not encrypted
2025-09-22 13:54:51 <ffoss> can't find /dev/sda
2025-09-22 13:55:32 <Sertonix[m]> I recommend running 'blkid' to find the correct device
2025-09-22 13:56:32 <ffoss> Ah right, there it is
2025-09-22 14:00:49 <ffoss> Sertonix[m]: alright it's mounted
2025-09-22 14:01:18 <Sertonix[m]> Then try running the sed command from above
2025-09-22 14:03:44 <ffoss> There
2025-09-22 14:04:38 <Sertonix[m]> Maybe send the output of 'grep readlink /sysroot/etc/init.d/fsck' to make sure it worked
2025-09-22 14:05:15 <ffoss> Yep, it removed the -f flag of readlink in the script
2025-09-22 14:05:35 <Sertonix[m]> And then you can 'umount /sysroot' and if that succeded 'reboot -f'
2025-09-22 14:06:47 <ffoss> Thanks that worked :)
2025-09-22 14:07:58 <ffoss> Should I open an issue somewhere?
2025-09-22 14:08:36 <Sertonix[m]> Not needed, I am trying to come up with a good fix already
2025-09-22 14:08:56 <ffoss> Alright, thanks!
2025-09-22 14:21:38 <sentriz> hi all, is there a policy/guidelines on building packages which indirectly depend on embedded Wasm blobs? for example a package for a Go project which depends on a Wasm based sqlite driver
2025-09-22 14:29:30 <Sertonix[m]> ncopa: Any opinion on dropping -C0 completely from /etc/init.d/fsck? (busybox source code comment seems right that fsck should be filesystem agnostic)
2025-09-22 14:38:48 <WhyNotHugo> where should I leave feedback for `merge-usr`?
2025-09-22 14:39:30 <WhyNotHugo> I tried a `--dry-run` and it failed to write a bunch of files and directories into /usr, but I don't think --dry-run should be trying to perform write operations
2025-09-22 14:43:13 <pabloyoyoista> WhyNotHugo: aports and ping me or https://gitlab.alpinelinux.org/postmarketOS/merge-usr
2025-09-22 14:50:51 <WhyNotHugo> Something went wrong when creating issue. Please try again. :(
2025-09-22 14:50:51 <WhyNotHugo> pabloyoyoista: 
2025-09-22 14:51:08 <Sertonix[m]> dry-run shouldn't and doesn't need to copy [gs]etfattr. Is that the issue you mean?
2025-09-22 14:52:17 <WhyNotHugo> Can't create snippet: JSON.parse: unexpected character at line 1 column 1 of the JSON data
2025-09-22 14:52:17 <WhyNotHugo> tried to paste into a snippet on gitlab: 
2025-09-22 14:52:37 <WhyNotHugo> https://tpaste.us/oxJY
2025-09-22 14:52:45 <WhyNotHugo> It tries to create all directories and a few files.
2025-09-22 14:52:52 <WhyNotHugo> I checked with strace and it's effectively doing so.
2025-09-22 15:05:48 <Sertonix[m]> ensure_directory should probably be a noop with --dryrun
2025-09-22 15:45:17 <f_|mo> <WhyNotHugo> "Something went wrong when..." <- Refresh the page
2025-09-22 15:45:18 <f_|mo> it's a known issue
2025-09-22 15:45:20 <f_|mo> anubis is being a bit too strict rn
2025-09-22 15:45:38 <f_> WhyNotHugo: ^
2025-09-22 15:56:04 <WhyNotHugo> I did refresh the New Issues page. I don’t think I did with the Snippets page.
2025-09-22 15:56:46 <craftyguy[m]> Is the alpine gitlab using anubis?
2025-09-22 15:56:47 <WhyNotHugo> Sertonix[m]: Should check that path does not exist OR is a directory.
2025-09-22 15:57:07 <WhyNotHugo> No, this was reporting to the upstream merge-usr project 
2025-09-22 15:57:10 <f_> craftyguy[m]: it uses go-away
2025-09-22 15:57:20 <f_> 393:##crustaceans
2025-09-22 15:57:28 <f_> oops
2025-09-22 15:57:31 <f_> https://git.gammaspectra.live/git/go-away
2025-09-22 16:00:44 <craftyguy[m]> the 'upstream merge-usr' is in alpine's gitlab
2025-09-22 16:46:21 <PureTryOut> Huh, usr-merge --dryrun revealed all kind of files in /usr/bin without an owner lol. Guess it's time to clean this up finally
2025-09-22 20:22:33 <camelia> hii is anyone already running a /usr-merged system? is it ready for testing? i am a bit scared to execute the script on my machine tbh
2025-09-22 20:24:28 <ikke> Yeah, it's still being tested
2025-09-22 20:40:18 <fabricionaweb> Hi, I may need reviews here !90398 and here !90425
2025-09-23 02:05:18 <daedaevibin[m]> Using Setup-Desktop for gnome removes DOAS and breaks openrc-init completely. This has made it IMPOSSIBLE to manage user devices via rc-service/rc-update/etc.
2025-09-23 02:08:57 <psykose> it doesn't remove or add doas
2025-09-23 03:30:20 <Saijin_Naib[m]> Do packages need to be updated to not break when we run the merge-usr program?
2025-09-23 03:37:52 <craftyguy[m]> no, we spent many months fixing pkging bugs that would break some things when upgrading (like if a pkg didn't properly overwrite a busybox symlink for an app it installed), but I think most of those were resolved
2025-09-23 03:39:18 <Saijin_Naib[m]> sweet! I just got the "nag" in apk update, ran the dry-run, am reading the documentation linked from the log, and will fire off the upgrade soon
2025-09-23 03:39:24 <craftyguy[m]> otherwise, apps can still access stuff in /lib or whatever, and they'd be symlinks to /usr/lib and that should just work. My own anecdote: I've been running a usr merged Alpine/pmOS install for like roughly 6 months now
2025-09-23 03:40:01 <Saijin_Naib[m]> that is very promising
2025-09-23 03:40:21 <Saijin_Naib[m]> dry-run says all good, so away we go!
2025-09-23 03:47:10 <Saijin_Naib[m]> Reboot and back up. Thanks all involved for a seamless upgrade!
2025-09-23 03:48:49 <craftyguy[m]> nice and boring, just what I wanted to hear :P
2025-09-23 05:55:24 <daedaevibin[m]> @psykose it infact did.
2025-09-23 05:55:25 <daedaevibin[m]> It deleted Doas and completely broke OpenRC init.
2025-09-23 05:58:17 <daedaevibin[m]> Extra context:
2025-09-23 05:58:17 <daedaevibin[m]> It caused OpenRC to report that it "did not boot the system" and that it could not manage services anymore. This was entirely unfixable and has results in a SIXTH reinstall.
2025-09-23 05:58:17 <daedaevibin[m]> .
2025-09-23 05:58:18 <daedaevibin[m]> .
2025-09-23 05:58:18 <daedaevibin[m]> "openrc-init" was deleted and so was doas for an unknown reason during "Setup-Desktop" after selecting GNOME.
2025-09-23 06:12:34 <ncopa> good morning! I just ran merge-usr
2025-09-23 06:13:13 <ncopa> daedaevibin[m]: can you create an issue with the exact steps how to reproduce it?
2025-09-23 06:16:07 <daedaevibin[m]> @ncopa Where do I create the issue?
2025-09-23 06:18:10 <ncopa> depends a bit on exactly what is broken, but since this is triggered by setup-desktop, lets file it there.
2025-09-23 06:18:30 <ncopa> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
2025-09-23 06:18:41 <daedaevibin[m]> Alright, danke.
2025-09-23 06:35:58 <daedaevibin[m]> @ncopa Issue up as #10625
2025-09-23 06:36:59 <daedaevibin[m]> 
ACTION uploaded an image: 651 (19KiB) < https://matrix.org/oftc/media/v1/media/download/AamGpbO-yei7_xtNJx3N8GfOnpkSpPJeIjr9vWBJJ4k0RC4AjR-rGDBdFmDMOwE8-pXp7fizVo_uzpwd0gnmH5VCeZvWM1LQAG1hdHJpeC5vcmcvbVRtU05XSGlSSWVraEtCRWt4S25LRUFZ >

2025-09-23 10:09:15 <ncopa> daedaevibin[m]: thanks!
2025-09-23 10:09:45 <ncopa> i dont see where the openrc-init comes from though. as far I know, running setup-alpine does not install openrc-init
2025-09-23 10:10:34 <ncopa> also, you say in the issue to not install to disk, so it runs from ram. That basically means that you cannot reboot at all, unless you first lbu commit the configs
2025-09-23 10:10:49 <ncopa> and if you do that, you will re-install from scratch at reboot
2025-09-23 11:01:42 <pj-> achill: ptrc: could you look at makefile (and maybe use it) in forgejo-runner package? there's more flags and it maybe will prevent an issue where runner reports as "dev" instead of actual version
2025-09-23 11:06:37 <ptrc> sure, i'll take a look
2025-09-23 12:29:10 <camelia> idk if this is the right place for feedback, but I just ran merge-usr and rebooted. no issue was encountered :)
2025-09-23 12:32:06 <pj-> ptrc: apparently in go you can reference plain path in -ldflags -X (without module version) and it will set the variable there but it will only work for external modules and internally it uses the version path
2025-09-23 12:32:49 <pj-> so version in CLI works but it doesn't work inside code that's /pkg/ and you have to do code.forgejo.org/forgejo/runner/v11/internal/pkg/ver.version=
2025-09-23 12:33:08 <pj-> don't ask me why
2025-09-23 13:00:44 <pabloyoyoista> camelia: indeed this is, thanks a lot for the feedback. Seems like so far nothing has completely blown up :)
2025-09-23 15:12:11 <craftyguy[m]> ncopa: \o/ (I assume you didn't have issues :P)
2025-09-23 15:54:55 <ncopa> no issues so far
2025-09-23 18:15:06 <raspbeguy> Hello. ikke, how can we help to make the riscv64 builder not stuck anymore?
2025-09-23 19:37:29 <omni> is it stuck?
2025-09-23 19:40:20 <ikke> kde has been pushed, so for the time being, it's going to be busy
2025-09-23 19:40:33 <ikke> 87 packages in the queue
2025-09-23 20:17:31 <raspbeguy> omni: yes it is, no now package since 3 September https://dl-cdn.alpinelinux.org/alpine/edge/testing/riscv64/
2025-09-23 20:17:52 <raspbeguy> s/now/new
2025-09-23 20:18:38 <ikke> it was stuck on php85 for some time, but that's testing
2025-09-23 20:19:00 <ikke> I would expect community to still receive updates
2025-09-23 20:22:59 <raspbeguy> It's still stuck on testing anyway, which is problematic too
2025-09-23 20:23:41 <ikke> !90552
2025-09-23 20:25:30 <Ariadne> what's up with gitlab?  git pulling aports is taking forever
2025-09-23 20:26:44 <ikke> Hmm, atm it's instant for me
2025-09-23 20:27:21 <ikke> I did see that the builders all fetching at the same time can cause high load
2025-09-23 21:39:30 <omni> I can't pull either
2025-09-23 22:35:00 <omni> ..but I think that is at my end
2025-09-23 23:16:30 <craftyguy[m]> could someone please take a look at !90183? thanks :D
2025-09-24 02:37:30 <tranzystorekk> craftyguy[m]: 
2025-09-24 03:07:24 <Saijin_Naib[m]> @craftyguy this will be helpful for managing family devices. Thank you for packaging it! 
2025-09-24 03:12:37 <Saijin_Naib[m]> !90369 and !90449 could use a merge so I can play a game and map this weekend (it is a lie, I never have time 🤣)
2025-09-24 04:38:36 <craftyguy[m]> Saijin_Naib np, I needed it to recover one :P
2025-09-24 04:48:25 <pepijndevos[m]> I've submitted, tested, and repeatedly updated this simple pr but it keeps not getting merged and then the build number needs a new bump and I'm just done with it. Glhf https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87454#note_543722
2025-09-24 04:49:59 <craftyguy[m]> oof, yeah that makes sense... the maintainer even said they were fine with the change
2025-09-24 04:50:21 <craftyguy[m]> maybe just forgot to come back to it 🤷
2025-09-24 04:52:18 <Biswa96[m]> And I thought my 4 months old MR is probably new enough for merging 😅
2025-09-24 07:18:03 <fabricionaweb> Hi, morning, Im needing review on these !90398 !90425
2025-09-24 12:48:18 <ncopa> lets remove ffmpeg4 for alpine 3.23
2025-09-24 13:14:51 <andypost[m]> what's wrong with 3.22 builders? looks like looping 
2025-09-24 13:16:47 <dne> or are they waiting for riscv64 to finish building tree-sitter?
2025-09-24 13:25:53 <ikke> No, builders are independent 
2025-09-24 13:29:38 <ncopa> im investigating 3.22 builders
2025-09-24 13:31:16 <ncopa> OpenSSL version mismatch. Built against 30500020, you have 3050003f
2025-09-24 13:31:17 <ncopa> rsync error: unexplained error (code 255) at log.c(245) [sender=3.4.1]
2025-09-24 13:33:41 <ncopa> for some reason it installed old openssl for the rebuildshttps://build.alpinelinux.org/buildlogs/build-3-22-aarch64/main/openssh/openssh-10.0_p1-r8.log
2025-09-24 13:41:11 <q66> i'm confused why that would matter
2025-09-24 13:41:17 <q66> aren't those vers abi-compatible
2025-09-24 13:41:43 <dne> because 3.5.x with x < 3 had this bug: https://github.com/openssl/openssl/issues/28227
2025-09-24 13:43:46 <q66> is there anything else affected by this
2025-09-24 13:43:50 <q66> or is it just openssh
2025-09-24 13:49:20 <andar1an> Do work in progress pr's require updates for usr merge changes?
2025-09-24 13:50:03 <andar1an> just learning about this now
2025-09-24 13:54:19 <ikke> andar1an: abuild would warn if that's the case 
2025-09-24 13:54:30 <ikke> Most applications already write in /usr
2025-09-24 13:54:57 <ikke> s/write/install 
2025-09-24 13:57:59 <andar1an> cool, ty
2025-09-24 13:58:51 <dne> ffs, I guess openssl v3.5.4 (to be relased 2025-09-30) will require yet another openssh rebuild: https://github.com/openssl/openssl/pull/28603
2025-09-24 14:05:49 <q66> tbf checking the version at runtime like that is pretty stupid
2025-09-24 14:06:04 <q66> abi compat is already ensured with soname
2025-09-24 14:06:16 <abby> tell that to libxml
2025-09-24 14:06:37 <q66> what does libxml do
2025-09-24 14:07:09 <abby> seems like every release they do something maybe abi incompatible
2025-09-24 14:07:30 <q66> they don't, but they regress stuff pretty often and there were some deprecations
2025-09-24 14:08:05 <q66> or rather, removals of stuff that was previously deprecated
2025-09-24 14:09:02 <q66> eg 2.14 no longer supports http io :)
2025-09-24 14:09:29 <q66> (something that i've never seen used ever and that seems like a terrible idea for an xml library to do, but it does break a couple testsuites)
2025-09-24 14:11:11 <q66> also tbf 2.14 actually did change the soname
2025-09-24 14:14:10 <dne> fwiw, openssh was checking only the major version and status bits in runtime, for openssl>=3
2025-09-24 14:30:15 <liske> I'm observing conntrackd crashes on 3.22 (since upgrading from 3.22 a longer time ago, but I had no time for a deeper look at it, yet)... strace shows a SIGKILL due to "illegal instruction" - anybody using conntrackd and (not) observing this issue?
2025-09-24 14:30:41 <liske> s/from 3.22/from 3.21/
2025-09-24 14:34:32 <liske> s/SIGKILL/SIGILL/
2025-09-24 14:55:56 <ostolc> good morning, not sure if this is the right place to ask... Is it possible that today's release of openssh 10.0_p1-r8 in 3.22 broke the ssh-keyscan binary?
2025-09-24 14:56:11 <ostolc> I am getting this error: OpenSSL version mismatch. Built against 3050003f, you have 30500010
2025-09-24 15:00:48 <dne> you need to make sure that dependencies are upgraded, e.g. in a docker image install with "apk add -u ..."
2025-09-24 15:02:29 <ostolc> this is what our developers do in their build:  apk add --update --no-cache curl git openssh
2025-09-24 15:02:51 <ostolc> so I believe the dependencies are upgraded
2025-09-24 15:04:26 <dne> hm, yes, I could reproduce it (adding "apk upgrade" fixes it though)
2025-09-24 15:04:27 <ostolc> I don't have an alpine installation, it's just our developers reporting to me, that they builds are failing. When I compare their last successfull build, it was using 10.0_p1-r7. And today 10.0_p1-r8 was released, as per pkgs.alpinelinux.org
2025-09-24 15:05:27 <ikke> #17547
2025-09-24 15:07:40 <dne> but why doesn't "apk add -u openssh" pull in updated deps?
2025-09-24 15:13:12 <ostolc> I will watch the issue tracker, thanks for the link
2025-09-24 16:05:57 <achill> okay so apparently stuff compiled with dotnet links against /usr/lib/ld-linux-x86-64.so.2 instead of /lib/ld-... causing abuild's call of apk to retrieve the pacakge owner to fail..
2025-09-24 16:23:47 <Sertonix[m]> Could you link/paste the error message?
2025-09-24 16:25:24 <durrendal> achill: ncopa: is the maintainer of moc inactive, I'd be happy to take over maintenance of the package if so. There are known working patches to make it build against the newest version of ffmpeg
2025-09-24 16:29:48 <achill> durrendal: sure, semes like the maintainer is not active; feel free to open a MR taking over maintainership
2025-09-24 16:30:11 <achill> Sertonix[m]: >>> jellyfin*: Tracing dependencies... ERROR: /usr/lib/ld-musl-x86_64.so.1: Could not find owner package
2025-09-24 16:32:31 <durrendal> achill: appreciate it! I'd rather do the work to keep moc in than go find (or make) a different music player :)
2025-09-24 16:36:20 <Sertonix[m]> achill: on a /usr-merged system?
2025-09-24 16:36:30 <achill> yes
2025-09-24 16:37:11 <achill> was also reproducible on abuild rootbld which is also usr-merged
2025-09-24 16:39:32 <pj> durrendal: if for some reason you would go searching for a new player, there is musikcube
2025-09-24 17:02:33 <Sertonix[m]> achill: The issue seems to trigger with libc.so in the elf needed section. abuild then later calls relpath which results in the incorrect /usr/lib path.
2025-09-24 18:29:49 <Sertonix[m]> achill: Fixing this properly in abuild is almost impossible. Since libc.so is not actually the soname of musl the best fix I can think of is to patch dotnet to use the correct soname. Then abuild won't try to fall back to the unreliable apk info --who-owns method
2025-09-24 21:06:55 <jahway603[m]> What is the process to get an aports package moved from testing -> community? I'm inquiring about the nomadnet package and it's associated packages which I submitted on May 27, 2025 (git show ebe20309554). I also updated these 3 packages yesterday in !90604.
2025-09-24 22:21:26 <camelia> hi, i have noticed that libreoffice was crashing after i performed the /usr-merge
2025-09-24 22:22:05 <camelia> it kept complaining about not being able to load /usr/lib/jvm/java-21-openjdk/lib/libjimage.so, which actually exists on my filesystem
2025-09-24 22:23:08 <camelia> after a quick check, I noticed that libjimage.so is linked against libjvm.so, which cannot be loaded since the merge (I'm not sure whether the merge caused that, but the package wasn't update recently so idk)
2025-09-24 22:23:52 <camelia> i was able to start libreoffice by exporting LD_LIBRARY_PATH="/usr/lib/jvm/java-21-openjdk/lib/server"
2025-09-24 22:24:37 <camelia> anyway I was wondering whether other people can reproduce this, before opening an issue in the aports repository
2025-09-24 22:26:48 <quinq> That's a bit weird though, my libjimage.so is in /usr/lib/jvm/java-22-openjdk/lib/
2025-09-24 22:27:15 <camelia> uhh, maybe the location differs between version 21 and 22?
2025-09-24 22:29:42 <camelia> oh sorry, i misread. yes, libjimage.so is indeed in /usr/lib/jvm/java-22-openjdk/lib/ on my system as well
2025-09-24 22:30:07 <camelia> libjvm.so is the one in /usr/lib/jvm/java-22-openjdk/lib/server, and that's the one that cannot be loaded as well
2025-09-24 22:30:33 <camelia> s/22/21/
2025-09-25 00:33:26 <Saijin_Naib[m]> camelia can't repro on x86_64 edge after usr-merge, but I semi-routinely do apk upgrade -al, so maybe something there helped, or maybe an orphaned package is holding things back that need updating?
2025-09-25 00:33:40 <Saijin_Naib[m]> I made sure I had nothing orphaned or wrong-channel before the usr-merge last night
2025-09-25 03:02:06 <jdknight> Question about GitLab interaction (alpine/aports). Curious about who closes discussion threads in a GitLab merge request. I have typically experienced that the user who opens the discussion thread should be the one to resolve the thread as well. What's the common practice for Alpine development? Sorry if I have overlooked any documentation reflecting this.
2025-09-25 04:27:38 <ikke> jdknight: If the author of the MR think the point of the thread has been solved, there is no issue for them to resolve it
2025-09-25 04:58:02 <jdknight> @ikke, noted. Thanks for the reply.
2025-09-25 09:29:31 <ncopa> good morning!
2025-09-25 09:29:44 <ncopa> achill: I'm working on backporting openssl fix
2025-09-25 09:30:00 <ncopa> then we shouldnt need recompile openssh or tor or anything
2025-09-25 09:30:16 <achill> that would be great
2025-09-25 09:30:18 <achill> thanks
2025-09-25 10:00:43 <achill> I think we still need to add the openssh version constraint right?
2025-09-25 10:01:34 <achill> there are many users reporting issues with their containers since they still have a old openssl and try to install the new openssh
2025-09-25 10:02:12 <achill> Telling them to upgrade openssl is basically impossible regarding our size and the affected users
2025-09-25 10:03:07 <ncopa> i think problem is openssl 3.5.3?
2025-09-25 10:03:11 <ncopa> let me test
2025-09-25 10:03:37 <ncopa> ouch
2025-09-25 10:03:43 <achill> yeah but users still have the old openssl but install the new openssl which still expects the old openssl
2025-09-25 10:03:45 <ncopa> indeed
2025-09-25 10:03:49 <achill> *new
2025-09-25 10:04:37 <achill> the version constraint is ugly but it works and users' apk automatically resolve the correct version
2025-09-25 10:05:55 <ncopa> cant we just upgrade openssh?
2025-09-25 10:06:03 <ncopa> i men rebuild openssh
2025-09-25 10:07:22 <achill> hmm i guess yea
2025-09-25 10:08:24 <ncopa> we probably also need rebuild tor
2025-09-25 10:08:53 <achill> yeah although this is not that important since thats just a warning in tor
2025-09-25 12:17:45 <tw_> Is there a chance for some bootloader other than grub becoming the new default?
2025-09-25 12:18:34 <Habbie> i have no idea, but i'm curious what alternatives you might have in mind
2025-09-25 12:19:42 <tw_> There aren't many I'd personally consider to be a good fit. But, for example, Limine looks rather promising.
2025-09-25 12:20:07 <Habbie> ah yes, i remember. it does
2025-09-25 12:21:33 <tw_> I guess Grub could be considered an industry standard of sorts, but it's extremely bloated
2025-09-25 12:21:53 <tw_> Furthermore, Chimera has also switched over to Limine, IIRC.
2025-09-25 12:22:44 <Habbie> my laptop has neither, just systemd-boot :> (but i'm not on Alpine)
2025-09-25 12:23:52 <tw_> Yeah, sd-boot makes a lot of sense on Systemd-centric distros. It's also my bootloader of choice on Arch. :b
2025-09-25 12:24:03 <Habbie> it's a bit bare, but it works
2025-09-25 12:24:33 <tw_> I'd argue that's a good thing. Grub is messy...
2025-09-25 12:24:52 <Habbie> grub has come in handy on other machines when i was debugging OS boot failure
2025-09-25 12:24:54 <Habbie> but yes
2025-09-25 13:07:15 <pj> <tw_> "Furthermore, Chimera has also..." <- you have to be more specific when saying "Chimera"
2025-09-25 13:11:39 <tw_> There's only one Chimera worth talking about ;-)
2025-09-25 13:20:59 <pj> > sd-boot makes a lot of sense on Systemd-centric distros
2025-09-25 13:21:01 <pj> it doesn't
2025-09-25 13:21:20 <pj> sd-boot has nothing to do with systemd service management
2025-09-25 13:22:15 <Habbie> that's true, it's entirely unrelated
2025-09-25 13:30:01 <sam_> it has niceties on systemd systems because of some integration with "what if the kernel didn't boot" and such
2025-09-25 13:30:04 <sam_> but it otherwise works just fine w/o systemd
2025-09-25 13:54:54 <q66> systemd-boot is much better supported in chimera than limine (which is barely at all)
2025-09-25 13:55:03 <q66> oh the person quit
2025-09-25 14:15:12 <Sertonix[m]> limine looks ok. It seems to be missing arm32 efi support compared to systemd-boot.
2025-09-25 17:01:53 <ncopa> Sertonix[m]: I think we should do release of abuild asap (within a few days?)
2025-09-25 17:02:11 <ncopa> Sertonix[m]: please let me know which MR that should be prioritized
2025-09-25 17:02:18 <andypost[m]> somehow arch64 builder is stuck on imagick since last night
2025-09-25 17:04:18 <ikke> andypost[m]: killed it
2025-09-25 17:05:28 <andypost[m]> ikke: thanks, looks test for the extension is non determenistic 
2025-09-25 17:06:46 <Sertonix[m]> [@_oftc_ncopa:matrix.org](https://matrix.to/#/@_oftc_ncopa:matrix.org) Sounds great! I hope to get the time for rebasing later
2025-09-25 17:15:28 <ncopa> Sertonix[m]: I'm looking at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/342
2025-09-25 17:16:32 <ncopa> I'm slightly worried about annoying maintainers. personally its not a bit deal for me. I can adapt. other may or may not be more sensitive to changes like this
2025-09-25 17:17:06 <ncopa> i wonder if it would make sense to have it configurable, and the default to be current behavior? and then change the config on the builders?
2025-09-25 17:17:31 <ncopa> maybe not. i dont know
2025-09-25 17:20:30 <Sertonix[m]> I have added a line to abuild.conf.in that when commented out reverts the change. I would hope that maintainers who don't like the changed behaviour to be ok with needing to change that line.
2025-09-25 17:24:28 <andypost[m]> ikke: if you can please check edge s390x builder as seems stuck
2025-09-25 21:39:49 <jvvv> I tried to email prspkt about recent bspwm release, but it bounced with: <prspkt@protonmail.com>: Recipient address rejected: Address does not exist
2025-09-25 21:49:22 <Sertonix[m]> Maybe create an gitlab issue and ping @prspkt ?
2025-09-25 23:42:37 <jvvv> Sertonix[m]: good approach. will do, thanks
2025-09-26 03:45:59 <alpine-user> im having trouble with the new kernel update in the edge repo anyone uses EDGES packges?
2025-09-26 03:47:03 <alpine-user> o/
2025-09-26 03:52:17 <alpine-user> anyone with the linux-lts 6.12.49-0-lts ? my wifi card firmware is not in this kernel? is the wifi-7265D
2025-09-26 04:05:42 <alpine-user> anyone?
2025-09-26 04:31:21 <alpine-user> anyone here hello?
2025-09-26 04:31:24 <alpine-user> :)
2025-09-26 06:48:46 <achill> you've successfully annoyed someone
2025-09-26 07:06:16 <skarnet> but only after they left
2025-09-26 07:56:23 <fabricionaweb> who wants to review my prs \o/
2025-09-26 07:56:47 <fabricionaweb> !90425 !90398
2025-09-26 08:08:05 <apreiml> I've started a little software preservation project and noticed that I couldn't fetch the sources of about 80 packages (besides the ones on ftp.gnu.org which I got from a mirror, since it's down)
2025-09-26 08:08:33 <ikke> A
2025-09-26 08:08:38 <apreiml> would you accept patches that change them to a mirror? What about fetching some from archive.org?
2025-09-26 08:09:13 <ikke> apreiml: you could check if they're available on distfiles.alpinelinux.org
2025-09-26 08:10:09 <apreiml> ah, nice. thanks
2025-09-26 08:12:08 <ikke> Note that that should generally not be used as primary source 
2025-09-26 08:12:53 <apreiml> sure
2025-09-26 18:49:48 <ikke> gitlab will be upgraded in ~10 minutes (19:00 UTC)
2025-09-26 19:04:48 <ikke> Upgrade done
2025-09-26 20:09:40 <Sertonix[m]> [@_oftc_apreiml:matrix.org](https://matrix.to/#/@_oftc_apreiml:matrix.org) Sometimes you can get the primary sources fixed. For example mujs has fixed their certificate since I last checked. And some other people fixed the ipv6 config very quickly after I mailed them
2025-09-26 21:47:35 <WhyNotHugo> should official docker images for :edge start having merged usr? currently using apk nags that one should merge usr on new images
2025-09-27 09:04:26 <mallory> Hi, it seems my PR about (re)adding libetebase got lost (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78130). Is there any way to "push" it if that's fine? A while ago, it got added status:mr-stale, but I have since finished it.
2025-09-27 09:11:49 <achill> ncopa: it would be good to do a new edge snapshot to roll out merged-usr images/tarballs
2025-09-27 09:52:28 <ikke> mallory: I've rebased it
2025-09-27 12:49:44 <ffoss> Can I just send a merge request to update a package that has had a new release, or should i ask the maintainer?
2025-09-27 12:50:56 <ikke> You can send an MR, the maintainer will be notified and generally has to ack it before it is merged
2025-09-27 12:52:11 <ffoss> thanks
2025-09-27 18:37:36 <ikke> ptrc: firefox is now failing on ppc64le
2025-09-27 18:37:41 <ikke> Seems to be some rust issue
2025-09-27 21:37:37 <achill> ptrc: also it would be nice if you could look at !90737
2025-09-27 21:37:48 <achill> otherwise i think ill merge it tomorrow or so
2025-09-28 00:46:01 <Sertonix[m]> achill: Will you change it back once upstream has fixed ffmpeg8 support?
2025-09-28 07:31:12 <achill> That would be my plan
2025-09-28 10:28:41 <ikke> any idea why ff fails on ppc64le?
2025-09-28 10:33:35 <ikke> raspbeguy: fyi, riscv64 is up-to-date again
2025-09-28 10:54:09 <raspbeguy> ikke: awesome 
2025-09-28 11:48:40 <mallory> Is there a good way to get notified if an issue is opened for a package I maintain? E.g., subscribe to issues mentioning a certain keyword or something?
2025-09-28 11:52:22 <ikke> mallory: afaik, no. But we try to assign issues to the maintainers of the packages 
2025-09-28 12:09:53 <Habbie> i -usually- get pinged for mine indeed
2025-09-28 13:47:19 <mallory> ok, good to know that the maintainer gets assigned/pinged
2025-09-28 15:10:06 <andar1an> I am having trouble installing a locally built package today for testing. apk search sees the version, but for some reason anything I try to add the package pulls the upstream version
2025-09-28 15:10:53 <andar1an> am wondering if I am forgetting something. Have added local repositories to repository file, see the built package there, and have tried using flag and version to install, as well as upgrade
2025-09-28 15:17:42 <andar1an> nvm, believe it is a world confict that is preventing
2025-09-28 15:20:18 <andar1an> doesn
2025-09-28 15:20:26 <andar1an> t seem like it should be a conflict though
2025-09-28 15:21:22 <andar1an> all referenced conflicts are same version
2025-09-28 15:35:17 <ikke> andar1an: what happens if you do 'apk add -s package=<version>' where <version> is the version of the package that you built
2025-09-28 15:44:27 <andar1an> didn't try -s flag, give me a sec
2025-09-28 15:44:42 <ikke> -s is just simulate
2025-09-28 15:45:42 <andar1an> ah, then it is same "breaks world" error, though specifying the apk package directly gave explicit detail of conflicts, and it didn't seem like they should be conflicts
2025-09-28 15:46:23 <ikke> can you provide those?
2025-09-28 15:46:38 <andar1an> yes, 1 sec
2025-09-28 15:47:47 <andar1an> not sure how this will look on irc: 
2025-09-28 15:48:23 <andar1an> but the gist is   rustc-dev-1.90.0-r0:    conflicts: swww-0.11.2-r0[so:libdarling_macro-0d229b526fb4d500.so=0]
2025-09-28 15:48:37 <andar1an>    satisfies: world[rustc-dev]  swww-0.11.2-r0:    masked in: @local    conflicts: rustc-dev-1.90.0-r0[so:libdarling_macro-0d229b526fb4d500.so=0]
2025-09-28 15:49:07 <andar1an> there are 17 other listed conflicts, but all match each other
2025-09-28 15:49:07 <ikke> so both provide the same so:
2025-09-28 15:49:12 <ikke> which is a conflict
2025-09-28 15:49:34 <andar1an> ah, I thought that if it was the same it wouldn't be a conflict. My bad
2025-09-28 15:49:52 <andar1an> thank you @ikke!
2025-09-29 07:59:15 <qaqland> does pytest need py3-typing-extensions? https://github.com/search?q=repo%3Apytest-dev%2Fpytest+typing_extension&type=code
2025-09-29 08:22:42 <BOMBOCLAT> 
ACTION 9-=[ 3https://ppnetworks.it9 ]=- 4VPS 1G PROMO .HU 1,20€/mo 

2025-09-29 08:46:46 <strophy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90581 should have bumped svt-av1 to 3.1.2-r0 for all 64 bit archs, but I still only see the old version for s390x and ppc64le on https://pkgs.alpinelinux.org. This worked in CI, did a builder fail somewhere? Is there a build system where I can view logs or trigger a retry?
2025-09-29 09:04:12 <ikke> strophy: https://build.alpinelinux.org
2025-09-29 09:04:33 <ikke> Those builders are currently failing on a couple of packages 
2025-09-29 09:05:07 <ikke> strophy: you can also check #alpine-commits
2025-09-29 09:52:05 <raspbeguy> ikke, can I get a riskv5 vm please? I wish to investigate why one of my ports doesn't work
2025-09-29 09:52:13 <raspbeguy> ikke, can I get a riscv5 vm please? I wish to investigate why one of my ports doesn't work
2025-09-29 10:01:23 <Habbie> if i -only- change the secfixes section of an APKBUILD, do i bump pkgrel?
2025-09-29 10:16:43 <ikke> Habbie: no
2025-09-29 10:17:04 <Habbie> thanks
2025-09-29 10:17:51 <ikke> secfixes are not stored in the package / index, so it does not require a rebuild of the package
2025-09-29 10:18:02 <Habbie> good heuristic
2025-09-30 06:18:44 <quinq> Bonjour
2025-09-30 06:19:22 <quinq> ptrc, would you have some free time for looking into updating webkitgtk?
2025-09-30 06:20:02 <quinq> Current edge version is 6 releases behind
2025-09-30 14:09:33 <achill> btw i plan to get !89408 ready for the 3.23 builder bootstrap, if someone has any opjections please comment
2025-09-30 14:54:10 <quinq> (ptrc, meant that in a friendly request way of course :>)
2025-09-30 15:53:10 <elagost> quinq: I opened mr !90871 for this, would you test when they finish building?
2025-09-30 17:20:34 <quinq> Thank you elagost, with pleasure :)
2025-09-30 17:20:41 <quinq> Though tomorrow at best
2025-09-30 17:25:24 <q66> elagost: why not do 2.50 while at it
2025-09-30 17:27:37 <q66> need to update a couple patches (i have those if needed) though i guess internal libpas malloc is broken on riscv64 and i haven't yet figured out why so i had to switch it to system malloc on riscv (no idea if that reproduces on alpine too though)
2025-09-30 17:30:20 <q66> if you do 2.50 and you let the ci run on riscv and see if that fails in the same way, that'd probably be an useful observation for me actually :p
2025-09-30 17:31:41 <q66> https://github.com/chimera-linux/cports/commits/master/main/webkitgtk you can get all the changes here (since alpine does not have big endian ppc64 or ppc32, some of those commits are irrelevant and can ignore those)
2025-09-30 17:50:51 <elagost> q66: ok, I can pull that in after work. Thanks for letting me know!
2025-09-30 20:17:29 <Noisytoot> Is there a list of exceptions to the "free software only" policy? intel-ucode, amd-ucode, and linux-firmware all violate it (and it's well known that they do), but I couldn't find a clear list of exceptions anywhere.
2025-09-30 20:18:17 <Noisytoot> Also, aports should have a license. It doesn't and that's problematic if it contains anything copyrightable.
2025-09-30 20:26:55 <panekj> > Also, aports should have a license.
2025-09-30 20:27:02 <panekj> Noisytoot: why
2025-09-30 20:30:01 <panekj> no one is going to complain if something is copied from aports and it would be quite misleading if there was any licence
2025-09-30 20:30:24 <achill> Noisytoot: https://gitlab.alpinelinux.org/alpine/aports/-/issues/9074
2025-09-30 20:30:34 <craftyguy[m]> what "free software only" policy are you referring to?
2025-09-30 20:31:11 <achill> tldr: basically impossible to apply a license to aports; maybe we can force new contribtions to have a license
2025-09-30 20:31:39 <achill> craftyguy[m]: i would think https://gitlab.alpinelinux.org/alpine/tsc/-/issues/23
2025-09-30 20:32:09 <achill> 
ACTION note to self: clarify free-software-policy for the developer handbook

2025-09-30 20:33:32 <panekj> the policy is that non-free software is not added to alpine
2025-09-30 20:33:40 <achill> there isnt a list of exact exceptions but generally speaking, no new non-free packages are allowed and we try to reduce as much as possible but stuff like linux-firmware is basically impossible
2025-09-30 20:33:58 <craftyguy[m]> that tsc issue doesn't seem to be a policy, and as pointed out in there linux-firmware is "not free software" but folks agreed it should be kept in aports
2025-09-30 20:33:59 <panekj> ucode/firmware is firmware, which is essential to use hardware at all
2025-09-30 20:34:06 <panekj> so it's not removed
2025-09-30 20:34:09 <panekj> and it comes from kernel
2025-09-30 20:34:31 <achill> craftyguy[m]: we basically dont have any policies other than tsc issues and the 2 markdown files in aports
2025-09-30 20:34:40 <panekj> craftyguy[m]: the policy was that non-free software was in non-free category, category was dropped therefore no new non-free
2025-09-30 20:34:40 <craftyguy[m]> ah gotcha
2025-09-30 20:36:33 <achill> for a proper non-free-policy we'd probably need to clarify what we mean by non-free because this might be misleading with spdx, fsf, oss and what not. also i think that was the idea of a "licensing"-team that specifically concerns about this kind of stuff w/ exceptions and so
2025-09-30 21:18:12 <Noisytoot> panekj: it depends, I wouldn't need linux-firmware if I didn't care about wifi (or used a dongle) and I don't need intel-ucode because libreboot already applies microcode updates
2025-09-30 21:18:30 <Noisytoot> I'm referring to that tsc issue as well as https://wiki.alpinelinux.org/wiki/Package_policies#Licensing
2025-09-30 21:21:23 <pj> you are not an average user
2025-09-30 21:28:15 <Noisytoot> I don't mind intel-ucode/amd-ucode/linux-firmware existing (although I'd rather they be put in a seperate repository like in debian), but I want there to be a clearer policy on licensing that specifies why those three packages are allowed
2025-09-30 21:31:03 <pj> we had "separate" repo, it was annoying to use and it would be annoying now too
2025-09-30 21:44:32 <q66> what would be the purpose of a separate repo
2025-09-30 21:45:46 <abby> pleasing the software puritans
2025-09-30 21:47:17 <q66> from what i can tell the tsc stuff does not explicitly deal with this either, it just drops the repository section
2025-09-30 21:48:04 <q66> if it's legally redistributable i don't see the problem
2025-09-30 21:49:24 <q66> excluding something on vague "freeness" criteria is weird because noone is forcing you to install these packages if you don't want them
2025-09-30 22:03:15 <Noisytoot> In general, I do not want to accidentally find and install proprietary software via apk search, or have it pulled in as dependencies. But in this case that's not an issue since it's just 3 packages that nothing depends on.
2025-09-30 22:04:55 <panekj> you could just check the licence before installing
2025-09-30 22:05:00 <panekj> is it that hard?
2025-09-30 22:06:21 <q66> nothing is going to implicitly depend on proprietary software
2025-09-30 22:07:28 <abby> doesn't apk have a way to mark a package as never installable?
2025-09-30 22:07:33 <q66> yes
2025-09-30 22:07:49 <q66> you just add a conflict to world
2025-09-30 22:08:19 <q66> so apk add '!foo'
2025-09-30 22:18:44 <panekj> while on-topic, unrar should have not been removed
2025-09-30 22:19:05 <q66> given there is no other way to unpack certain rars, yeah
2025-09-30 22:19:43 <q66> not that it's a good format but "it's a shitty format anyway" does not help people who need to unpack one
2025-09-30 22:20:57 <Noisytoot> I disagree. libarchive/bsdtar supports rar, and you can always install it manually
2025-09-30 22:21:20 <panekj> > you can always install it manually
2025-09-30 22:21:22 <panekj> what exactly
2025-09-30 22:21:24 <Noisytoot> if unrar was to be kept it should have been moved to non-free and non-free kept
2025-09-30 22:21:26 <Noisytoot> unrar
2025-09-30 22:21:43 <q66> how is "libarchive/bsdtar supports rar" refuting what i said
2025-09-30 22:21:49 <panekj> ok, why should we provide linux kernel or any other package when it can be installed manually
2025-09-30 22:21:51 <panekj> by user
2025-09-30 22:21:56 <q66> there are many rars that libarchive won't unpack
2025-09-30 22:22:13 <q66> https://github.com/libarchive/libarchive/issues/1426
2025-09-30 22:22:40 <panekj> KDE Ark uses unrar CLI to unpack .rar files and it does not use libarchive for that
2025-09-30 22:22:44 <q66> https://github.com/libarchive/libarchive/issues/1426#issuecomment-699587770
2025-09-30 22:23:01 <panekj> it's possible to substitute that with unrar-free but still, libarchive doesn't open every .rar
2025-09-30 22:24:12 <Noisytoot> because linux is free software. unrar definitely did not belong in main
2025-09-30 22:24:31 <Noisytoot> or community
2025-09-30 22:24:43 <panekj> why not
2025-09-30 22:25:31 <Noisytoot> it should have been in non-free, because it's non-free
2025-09-30 22:26:45 <panekj> that category distiction makes no sense
2025-09-30 22:34:05 <Noisytoot> it does make sense. I do not want to install proprietary software, or have it pollute "apk search", nor would I want to host it if I hosted an alpine mirror
2025-09-30 22:35:05 <panekj> there are already present options for you to satisfy your needs
2025-09-30 22:35:07 <q66> kinda sounds like a you problem tbh
2025-09-30 22:35:41 <panekj> that doesn't mean everyone else have to suffer the consequences because you have very toxic GNU opinion
2025-09-30 22:41:54 <Noisytoot> my opinion isn't toxic, proprietary software is. anyway, it's a non-issue because unrar was removed
2025-09-30 22:44:37 <panekj> lol
2025-09-30 22:49:34 <Noisytoot> something like gentoo's ACCEPT_LICENSE is an alternative to having seperate repositories, however, alpine does not have this
2025-09-30 22:50:11 <panekj> have you tried looking at the licence before installing something?
2025-09-30 22:52:45 <Noisytoot> I just avoid distros that package lots of proprietary software with no way of excluding it (alpine is not one of those distros, since it's just 3 packages)
2025-09-30 22:55:31 <Noisytoot> also, not all packages have very informative SPDX metadata currently (linux-firmware just has "custom", apparently because it predates SPDX metadata)
2025-09-30 22:55:51 <Noisytoot> (I might try to add it but I don't know how to give different subpackages different license metadata)
2025-09-30 22:57:36 <panekj> it's custom probably because putting every licence in that field is terrible and it's mostly "redistribution is fine but this is proprietary anyway"
2025-09-30 22:58:36 <Noisytoot> not everything is proprietary, linux-firmware-ath9k_htc is free
2025-09-30 22:59:15 <panekj> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE
2025-09-30 22:59:16 <q66> linux-firmware has so many licenses in it, can't really express it with spdx
2025-09-30 23:01:55 <Noisytoot> linux-firmware-ath9k_htc should at least have the correct license, it's 3-clause BSD with a patent disclaimer ( https://github.com/qca/open-ath9k-htc-firmware/blob/master/LICENCE.TXT )
2025-09-30 23:08:15 <Noisytoot> panekj: what do you think about cases in which a free program has some proprietary parts? for example plan9port, which currently contains some non-free fonts. in this case, if I wanted to install plan9port but not the non-free fonts, I couldn't just not install it. (you could split it into a separate package but some parts of plan9port hardcode the font names)
2025-09-30 23:09:37 <durrendal> You could patch plan9port if that's what you want to do. Then either host it on your own mirror or create an MR and see if the maintainer will accept your suggestions.
2025-09-30 23:09:40 <panekj> either patch it out or it's all "AND custom"
2025-09-30 23:12:56 <Noisytoot> since the alpine policy is, as far as I can tell, "no non-free software except firmware and microcode", I reported it as a bug (and maybe I'll do an MR later)
2025-09-30 23:21:43 <panekj> there is more in font/
2025-09-30 23:22:05 <panekj> I don't think "from the students at the University of Hong Kong" is a valid licence or SPDX :>