2023-03-01 01:10:50 <Asmadeus> oh actually kmod-openrc provides a kmod-static-nodes service that does it, but doesn't get permissions right... heh
2023-03-01 01:41:27 <Asmadeus> (oh, and actually it just creates a tmpfiles template but we're not packaging https://github.com/openrc/opentmpfiles so back to square 1... Yeah ok did I said I'll stop looking...)
2023-03-01 09:15:54 <omni> seems like the "man" dummy package was holding back mandoc and docs
2023-03-01 09:17:58 <omni> so now 'apk version' only return the package I intentionally hold back
2023-03-02 00:44:40 <aeroraptor> what is the best way to go about having a package get added to the repositories?
2023-03-02 00:45:08 <aeroraptor> I am not a package maintainer myself, but I would really like it if LinuxPTP were included. I have confirmed that it builds perfectly fine and runs great. 
2023-03-02 00:45:10 <aeroraptor> https://linuxptp.nwtime.org/
2023-03-02 00:47:14 <elly> you can file an issue here: https://gitlab.alpinelinux.org/alpine/aports requesting that it get packaged
2023-03-02 00:47:40 <aeroraptor> thank you! I will do that :) 
2023-03-02 00:47:49 <aeroraptor> I have never done this before and don't want to step on any toes
2023-03-02 00:48:18 <psykose> sure i'll do it
2023-03-02 00:53:43 <aeroraptor> psykose: you're going to maintain the package for it?
2023-03-02 00:54:06 <aeroraptor> should I still log it as an issue in aports so you can close it out for recordkeeping?
2023-03-02 01:01:15 <minimal> aeroraptor: I'd locally packaged linuxptp about 1 month ago but never got around to preparing it for a MR
2023-03-02 01:01:29 <aeroraptor> oh, go figure
2023-03-02 01:01:35 <aeroraptor> how are/were you using it?
2023-03-02 01:01:42 <minimal> if you're looking for a daemon then there already is the ptpd package
2023-03-02 01:02:02 <aeroraptor> I specifically want LinuxPTP for the ts2phc and phc2sys tools
2023-03-02 01:02:35 <minimal> aeroraptor: I was trying to see if I could use phc2sys as a way to update system clock from /dev/ptp_kvm
2023-03-02 01:02:48 <aeroraptor> I have been using GNSS receivers to discipline Raspberry Pi clocks for years, but I am just now start to dip my toes into feeding time pulses into i210 NICs
2023-03-02 01:02:48 <minimal> instead of needing to use chronyd for that
2023-03-02 01:02:51 <aeroraptor> interesting! 
2023-03-02 01:03:22 <aeroraptor> this is what I am working on right now: https://wiki.millerjs.org/doku.php?id=pps2sdp
2023-03-02 01:03:44 <psykose> aeroraptor: not needed, no
2023-03-02 01:03:52 <psykose> should be available in edge in a bit
2023-03-02 01:03:56 <aeroraptor> I don't really know what I'm doing, but the documentation out there is very sparse, so I'm trying to lay down some groundwork 
2023-03-02 01:04:02 <aeroraptor> psykose: thank you very much, that's wonderful 
2023-03-02 01:04:39 <aeroraptor> I'll be setting up another system, probably Friday night or this weekend, and I'll give it a go
2023-03-02 01:06:32 <minimal> aeroraptor: I don't really have the need for PTP in my local network, especially as I don't have many network cards with support for it
2023-03-02 01:06:57 <aeroraptor> I don't either, but it's super fun
2023-03-02 01:07:18 <aeroraptor> and I'm not really using PTP across the network (yet), rather I'm using it on single systems that have dedicated GNSS receivers 
2023-03-02 01:10:45 <minimal> aeroraptor: so why not use chrony/gpsd for it instead?
2023-03-02 01:11:41 <aeroraptor> I'm exploring the best ways to get a PPS signal into chrony
2023-03-02 01:12:54 <aeroraptor> on a machine like a raspberry pi, that's relatively trivial, on a "normal" PC, it's a bit harder. The DCD pin on serial ports (if you have one) can be used as a system interrupt, and that's what gpsd uses as the "standard" PPS pin for serial-attached receivers - but myself and a few folks I'm working with have found that on a lot of newer systems the DCD pin isn't a real interrupt, and isn't particularly reliable
2023-03-02 01:13:50 <aeroraptor> so what you can do is feed the PPS signal into one of the "software defined pins" on some NICs, the intel i210 in this case, and then use some of the tools in LinuxPTP to use that signal to discipline chrony just like a "normal" PPS
2023-03-02 01:15:08 <minimal> yeah I've never used GPS on a "normal" PC, these days they'd be USB based which may or may not provide a PPS signal
2023-03-02 01:16:52 <aeroraptor> and even if they did, USB allows for an astonishing amount of jitter, plus/minus 30 milliseconds if I remember right
2023-03-02 01:17:03 <aeroraptor> which is useless at this scale 
2023-03-02 01:17:33 <minimal> yupe, its cheaper and easier just to use a RPI hat :-)
2023-03-02 01:17:38 <aeroraptor> granted chrony will absolutely do it if you configure it to, but your connection to a reputable NTP server over the internet is almost certainly going to be more reliable 
2023-03-02 01:18:48 <minimal> I've also got a DCF77 receiver lying around that I need to dig out some time
2023-03-02 01:18:51 <aeroraptor> yeah, and a Pi + hat is how I actually first got into this mess - I made a few for myself and friends, then ended up making... like... gosh almost 300 of them? that I sold over the TimeNuts mailing list
2023-03-02 01:18:53 <aeroraptor> https://millerjs.org/timehat
2023-03-02 01:19:22 <aeroraptor> I should update that first photo, that's the oldest and crustiest revision, not very impressive 
2023-03-02 01:19:35 <minimal> ah, I noticed you chatting on the ntp (or ntpsec) channel recently about that lol
2023-03-02 01:19:55 <aeroraptor> oh yeah that's entirely possible - I'm also very active in the GPSD channel hah
2023-03-02 01:20:11 <minimal> or maybe it was there, don't remember which lol
2023-03-02 01:21:46 <aeroraptor> I want to play with WWVB broadcast receivers, but I live in Maine which is pretty much outside of the broadcast range. We *barely* get the edge of it. I have a few atomic clocks that maybe update once a week. 
2023-03-02 01:22:24 <aeroraptor> I also have this absolutely wild old Hopf clock that has a DCF77 *transmitter* in it, so I need to get a german atomic clock or wristwatch or something and see if it actually works
2023-03-02 01:22:49 <minimal> at one stage I was thinking of a 3rd time source in addition to GNSS and DCF77....but didn't think MSF was a great choice and mobile networks' time really isn't great either
2023-03-02 01:24:31 <aeroraptor> yeah, I mean mobile networks' time is just GNSS time anyway, so it's a step removed. I am interested in using powerline frequency, at least measuring it to start, but I haven't gotten very far in that particular endeavor 
2023-03-02 01:25:07 <aeroraptor> I've got two GNSS reference antennas on my roof though, so I'm fairly committed to that hahaha
2023-03-02 01:25:52 <aeroraptor> I do have a little rubidium oscillator that someone gave me a while back, and I've thought about making a rubidium-disciplined free-running clock
2023-03-02 01:32:03 <minimal> going back to linuxptp, if I'd managed to figure out if phc2sys could handle the ptp_kvm stuff I'd have pushed the package MR. However phc2sys always seemed to want ptp4l to be running and I didn't get back to digging through the source code to understand what was going on
2023-03-02 01:59:33 <aeroraptor> I think it's definitely a worthy quest - if you're not familiar with the TimeNuts mailing list already you may want to ask there. Lots of sharp folks. 
2023-03-02 01:59:46 <aeroraptor> beyond my own scope but a question I am interested in answering. 
2023-03-02 12:38:33 <Newbyte> https://gitlab.gnome.org/guidog/phosh/-/jobs/2626399
2023-03-02 12:38:37 <Newbyte> do you have any idea why this fails?
2023-03-02 12:38:57 <Newbyte> here's the list of packages that are being installed: https://gitlab.gnome.org/World/Phosh/phosh/-/blob/a4e993eb09a885d251814e973188bc65641fdc11/.gitlab-ci.yml#L34-38
2023-03-02 12:43:16 <Newbyte> it seems like just installing polkit-elogind-dev causes this conflict
2023-03-02 12:44:34 <ikke> both seem to provide libglib-2.0.so
2023-03-02 12:44:51 <ikke> sorry, no, the other way around
2023-03-02 12:46:04 <Newbyte> I filed !14673
2023-03-02 12:46:13 <Newbyte> sorry, #14673
2023-03-02 12:46:17 <Newbyte> I guess?..
2023-03-02 12:46:47 <ikke> polkit-elogind-dev -> polkit-elogind-libs
2023-03-02 12:47:09 <ikke> polkit-elogind-dev -> polkit-dev -> polkit-noelogind-libs
2023-03-02 12:47:20 <ikke> So they are both pulled in
2023-03-02 12:47:21 <Newbyte> both -libs provide libglib-2.0.so?
2023-03-02 12:47:38 <ikke> no, they depend on it
2023-03-02 12:47:38 <Newbyte> I see. Thanks. I am not sure how you'd go about resolving this
2023-03-02 12:48:23 <ikke> Newbyte: I found that via apk dot polkit-elogind-dev
2023-03-02 12:50:11 <ikke> So dependencies are manually added in polkit-dev
2023-03-02 12:50:25 <ikke> (specifically the polkit-noeligind-libs)
2023-03-02 12:52:13 <ikke> These packages are all subpackages of polkitr
2023-03-02 12:52:17 <ikke> polkit*
2023-03-02 12:52:46 <ikke> -dev depends on polkit-noelogind-libs
2023-03-02 12:53:36 <ikke> elogind-dev depends on polkit-dev
2023-03-02 12:54:11 <ikke> I supsect the latter to be an error
2023-03-02 12:57:43 <ikke> 7368ae495d12305bf791e31675e3e846f05e80b3
2023-03-02 13:03:13 <ikke> I've added my findings to that issue
2023-03-02 13:04:43 <Newbyte> thanks!
2023-03-02 13:10:32 <ikke> maybe we need an explicit polkit-noelogind-dev
2023-03-02 13:10:50 <ikke> where polkit-dev contains the common files
2023-03-02 13:13:16 <ikke> or maybe instead of calling those -dev, call them -gir or something
2023-03-02 14:08:01 <omni> something takes forever on armhf with !44673 could we disable for that arch if it doesn't complete on the builders or now?
2023-03-02 14:37:11 <ptrc> omni: afaik rust is broken on armhf
2023-03-02 14:37:29 <ikke> yeah, psykose is looking at why
2023-03-02 15:27:01 <ikke> Newbyte: are you able to test this? https://tpaste.us/z5aj
2023-03-02 15:27:57 <ikke> I tried to keep everything backwards compatible, so things are not ideally named
2023-03-02 15:29:18 <ikke> sorry, something was still missing: https://tpaste.us/XygZ
2023-03-02 15:31:54 <ikke> hmm
2023-03-02 15:35:43 <ikke> ok, n/m psykose already pushed something
2023-03-02 15:39:59 <ikke> psykose reverted the change again
2023-03-02 15:50:30 <Newbyte> ikke: where do you see it being reverted?
2023-03-02 15:50:45 <ikke> https://git.alpinelinux.org/aports/commit/?id=cd85be3d3e88
2023-03-02 15:51:22 <Newbyte> ikke: I don't see the revert?
2023-03-02 15:52:46 <ikke> compare to https://git.alpinelinux.org/aports/commit/?id=7368ae495d12
2023-03-02 15:53:06 <ikke> oh, not exact revert
2023-03-02 15:53:07 <Newbyte> ikke: oh, I thought you meant the fix was reverted
2023-03-02 15:53:22 <ikke> no, the commit that introduced the issue
2023-03-02 15:53:29 <ikke> but I see now without =$pkgver-r$pkgrel
2023-03-02 16:15:37 <psykose> ikke: i still can't log into the armhf container
2023-03-02 16:22:14 <ikke> ok, apparently root (/) is not root (/root) :P
2023-03-02 16:35:28 <psykose> :)
2023-03-02 16:40:38 <psykose> works now
2023-03-02 16:40:39 <psykose> thanks
2023-03-03 01:27:58 <ptrc> is the logic behind what goes into modloop documented anywhere?
2023-03-03 01:28:32 <ptrc> i'm trying to read through the update-kernel script and.. it's kind of a mess with only really vague comments
2023-03-03 07:36:48 <skarnet> docuwhat?
2023-03-03 09:23:09 <omni> "complete instructions are available as a gnu info page"
2023-03-03 09:32:03 <humm> that’s better than ska’s HTML-only
2023-03-03 09:33:41 <humm> there’s not that much difference between lynx and info
2023-03-03 09:34:27 <omni> ptrc: sorry, what are you trying to do? I'm a bit interested too
2023-03-03 09:40:54 <ncopa> ptrc: which modloop? i think it is different in alpine standard and extended images
2023-03-03 09:41:53 <ncopa> the thinking is that modloop is readonly, which means you can not add stuff once its created. it means that we need to include everything that might be needed
2023-03-03 09:42:04 <ncopa> including firmware
2023-03-03 09:42:22 <ncopa> but we dont want include things that is not needed (eg firmware that no kernel module uses)
2023-03-03 09:42:57 <ncopa> also, i think we added zfs kernel modules to the extended iso, but not to the standard iso.
2023-03-03 09:43:31 <ncopa> and the reasoning is that we want keep the standard iso as small as possible. if you need more you can always use the extended
2023-03-03 09:43:54 <ncopa> that has been the thinking so far
2023-03-03 10:38:53 <skarnet> humm: better? yeah sure, how many info readers are out there vs. how many web browsers are out there?
2023-03-03 10:39:54 <skarnet> istg people, you need to get a grip on reality. Using GNU info puts you square in the "insular GNU zealot" category
2023-03-03 10:40:08 <skarnet> and you don't want to be there.
2023-03-03 10:59:32 <consus[m]> using a program does not put you anywhere lol
2023-03-03 11:00:10 <humm> There are two info readers and many browsers. Texinfo can be translated to HTML or to PDF or the like or to info.
2023-03-03 11:01:58 <humm> I, for my part, would love to see more documentation as troff, both as man pages and as ms manuscripts.
2023-03-03 11:02:00 <skarnet> that's awesome, everyone reads documentation as PDF
2023-03-03 11:02:29 <humm> it’s true that hardly anyone does
2023-03-03 11:02:29 <skarnet> and if you like man pages, rejoice, flexibeast is writing man pages for my packages, isn't it wonderful
2023-03-03 11:02:35 <humm> it is
2023-03-03 11:03:04 <humm> and it is comfortable to read your HTML with lynx
2023-03-03 11:03:49 <skarnet> yeah, so I have no idea where your "gnu info pages are better than HTML-only" comment comes from
2023-03-03 11:04:05 <skarnet> it is provably untrue
2023-03-03 11:05:02 <humm> my thinking was that the set of output formats is a superset of that of HTML
2023-03-03 11:05:28 <humm> my comment was misplaced
2023-03-03 11:05:41 <humm> should have been something like “not that bad”
2023-03-03 11:06:13 <humm> “Texinfo is not that bad. You can convert it to HTML if you like.”
2023-03-03 11:07:05 <humm> Also, I hadn’t realized we’re in #alpine-devel. I’m sorry.
2023-03-03 11:08:34 <skarnet> even then it's arguable because it depends on a lot of factors: how much you're willing to depend on a texinfo compilation suite, the quality of the output (which is not great for info2html), the ease of writing texinfo (which is no great either), etc. But the discussion about documentation formats should indeed happen somewhere else (and preferrably a place I don't read).
2023-03-03 11:34:11 <ncopa> ddevault: I have a question about cb053f3506f9486d41a9c5744e07116ccc6cbaa1
2023-03-03 11:34:32 <ncopa> that commit introduces 0003-efi-implemented-LoadFile2-initrd-loading-protocol-fo.patch
2023-03-03 11:34:56 <ncopa> 0003-efi-implemented-LoadFile2-initrd-loading-protocol-fo.patch changes grub-core/loader/arm64/linux.c
2023-03-03 11:35:21 <ncopa> which is arm64 and not risc-v as the cb053f3506f9486d41a9c5744e07116ccc6cbaa1 commit message suggests
2023-03-03 11:35:54 <ncopa> now I see that there is an upstream change, that looks very similar - but still different: https://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/loader?id=75e8d0d98069294c725f4f1fff41f27cb577a040
2023-03-03 11:37:15 <ddevault> these were a WIP patch series lifted off the mailing list with relatively little scrutiny under the justification that some RISC-V support was better than no RISC-V support, dating to well before I had started the upstreaming process
2023-03-03 11:37:34 <ddevault> I can look for an updated patchset and rebase these if necessary
2023-03-03 11:37:48 <ddevault> testing on real hardware would be a bit of a challenge, my RISC-V setup is currently pretty stale
2023-03-03 11:37:54 <ddevault> will have time for this next week, drop me an email
2023-03-03 11:39:07 <JohannesJ[m]> ohhh someone mentioned risc-v
2023-03-03 11:39:29 <ncopa> ddevault: I bumped into this while trying to debug: https://gitlab.alpinelinux.org/alpine/aports/-/issues/14407
2023-03-03 11:40:02 <ncopa> JohannesJ[m]: we also have an #alpine-riscv64 channel
2023-03-03 11:40:18 <ddevault> can you still reproduce this bug with the RISC-V series removed from grub?
2023-03-03 11:40:51 <JohannesJ[m]> ncopa: not according to matrix? it says no such room can be found?
2023-03-03 11:41:25 <ddevault> on IRC, not matrix
2023-03-03 11:41:33 <JohannesJ[m]> ahh :)
2023-03-03 11:44:12 <ncopa> ddevault: did this "drop you an email"?  https://gitlab.alpinelinux.org/alpine/aports/-/issues/14407#note_294044
2023-03-03 11:45:11 <ddevault> yep
2023-03-03 11:45:13 <ddevault> cheers
2023-03-03 11:45:18 <ddevault> will get back to you on it next week
2023-03-03 14:49:44 <ncopa> ddevault: i had a look at it and I think I was able to rebase them properly. Will push update in a bit
2023-03-03 14:50:13 <ddevault> ncopa: cool, keep me updated
2023-03-03 15:08:38 <ncopa> I pushed grub rebase of patches. we need to test if riscv64 still works
2023-03-03 15:20:09 <ikke> OK, I can test later today 
2023-03-03 15:20:28 <ikke> Just upgrading and rebooting? 
2023-03-03 15:28:33 <midasi> Hi all, could anybody please look at MR !20664? It seems to ready for merge since weeks
2023-03-03 15:33:13 <ncopa> looks like it failed on some arches
2023-03-03 15:40:18 <midasi> oh ok, I didn't see any pending changes. Let me try to contact the owner
2023-03-03 16:38:38 <spameier> Hello all, I'm trying to build a package from a Python project and the tests folder is being included in the final apk. Does anyone know how I can avoid this?
2023-03-03 16:41:44 <ptrc> spameier: you can 'rm -rf "$pkgdir"/usr/lib/python3*/site-packages/some-name/tests', basically
2023-03-03 16:43:48 <spameier> Oh I wanted to avoid that, but if it's the best option
2023-03-03 16:49:30 <psykose> ncopa: seems your rebased patches for grub don't build on riscv
2023-03-03 16:58:18 <ncopa> psykose: i saw. unfortunately my riscv64 dev env does not have working network for some reason
2023-03-03 17:02:38 <psykose> ah yeah
2023-03-03 17:02:39 <psykose> mine either
2023-03-03 17:29:03 <ikke> ncopa: but your container should have an address, doesn't it?
2023-03-03 17:29:36 <ikke> I set them statically
2023-03-03 17:50:18 <ikke> psykose: you should be able to access your container again
2023-03-03 17:52:28 <psykose> it doesn't resolve
2023-03-03 17:52:31 <psykose> unless you moved the dns
2023-03-03 17:52:59 <ikke> hmm, I did add a host record
2023-03-03 17:56:09 <ikke> psykose: ok, apparently I do need to add the fqdn as host-record as well
2023-03-03 17:56:41 <ikke> psykose: resolves for me now
2023-03-03 17:57:07 <psykose> same for me
2023-03-03 17:57:08 <psykose> thanks
2023-03-03 20:23:07 <hjaekel> !23678 is waiting for a review. I would be happy if someone had time for that.
2023-03-03 20:25:25 <ikke> "1 year ago" oof
2023-03-03 20:26:48 <hjaekel> yes, it took me a long time...
2023-03-03 20:27:18 <ncopa> ikke: i configured a static ip, yes
2023-03-03 20:27:24 <ikke> ncopa: ah
2023-03-03 23:21:38 <ncopa> i will fix grub on riscv64 on monday unless someone beat me over the weekend
2023-03-04 01:09:50 <aeroraptor> hmmmm this is.... confusing. I get LinuxPTP working right on alpine... and when I try to point chrony at it.... it segfaults immediately 
2023-03-04 01:11:18 <skarnet> just chrony things
2023-03-04 01:16:28 <aeroraptor> yeah, maybe, I can't even tell yet
2023-03-04 01:16:51 <aeroraptor> I need to replicate this setup on rocky (least favorite distro name ever)
2023-03-04 01:18:32 <aeroraptor> https://paste.millerjs.org/zeqawinusi.txt
2023-03-04 01:20:51 <minimal> aeroraptor: nothing useful in the chrony logs?
2023-03-04 01:21:07 <psykose> if you add gdb + musl-dbg and get it to crash in gdb then you could get something slightly more useful
2023-03-04 01:21:30 <aeroraptor> I don't know how to do those things yet but that sounds like a good idea!
2023-03-04 01:22:02 <aeroraptor> minimal: nope, segfaults *instantly*, doesn't run long enough to generate a log
2023-03-04 01:22:19 <aeroraptor> I'm looking to see if I can run chronyd directly at a debug mode or whatever
2023-03-04 01:23:30 <minimal> running via strace might give a hint as to what is going on
2023-03-04 01:26:07 <aeroraptor> okay here we go
2023-03-04 01:26:43 <aeroraptor> https://paste.millerjs.org/okadawipoy.txt
2023-03-04 01:26:55 <psykose> nice
2023-03-04 01:27:07 <psykose> now add those, and add chrony-dbg too, and then gdb --args <that line>
2023-03-04 01:27:17 <psykose> then r, bt full
2023-03-04 01:27:43 <aeroraptor> okay - and I'm going to try and comment out leapsectz - the clock will be off by 37 seconds, but at least it will give me an idea
2023-03-04 01:28:00 <psykose> don't have to do anything else
2023-03-04 01:28:14 <aeroraptor> 2023-03-04T01:27:58Z Fatal error : refclock tai option requires leapsectz
2023-03-04 01:28:17 <aeroraptor> lol well nevermind anyway!
2023-03-04 01:28:23 <aeroraptor> I know I just wanted to test a few things, hang on here
2023-03-04 01:28:46 <minimal> aeroraptor: which version of Alpine is this? wasn't there an upstream tzdata fuss of some sort about things like "right" about 6 months ago?
2023-03-04 01:29:21 <aeroraptor> alpine release tells me 3.18_alpha20230208
2023-03-04 01:29:31 <minimal> ah, so it's Edge then
2023-03-04 01:29:49 <aeroraptor> tzdata is 2022-r0 
2023-03-04 01:32:51 <minimal> aeroraptor: relevant? https://chrony-users.chrony.tuxfamily.narkive.com/wDW8DCm4/leapsectz-and-phc-refclock-offset
2023-03-04 01:33:17 <minimal> specifically the reply by Miroslav Lichvar, the chrony author
2023-03-04 01:34:15 <aeroraptor> oh this is a SUPER interesting thread 
2023-03-04 01:34:33 <aeroraptor> for what it's worth, I don't NEED TAI time, I could use UTC and be just as happy
2023-03-04 01:35:34 <aeroraptor> I had thought that phc2sys needed an offset but now I'm not so sure... hmmm
2023-03-04 01:40:07 <aeroraptor> psykose: I'm a bit of a newbie at this, where do I add chrony-dbg from?
2023-03-04 01:40:46 <psykose> apk add
2023-03-04 01:40:58 <psykose> unless you're using a mirror other than dl-cdn and it takes a while to sync
2023-03-04 02:13:22 <aeroraptor> doh of course it's on the testing repo! hah!
2023-03-04 02:15:23 <minimal> aeroraptor: chrony? nope, it's in main
2023-03-04 02:15:38 <aeroraptor> chrony-dbg ?
2023-03-04 02:16:03 <minimal> it is a sub-package of chrony
2023-03-04 02:16:24 <minimal> just like chrony-doc and chrony-openrc
2023-03-04 02:16:36 <aeroraptor> oh, well I got that, but I
2023-03-04 02:16:42 <aeroraptor> I am not entirely sure if I am doing this right
2023-03-04 02:17:14 <minimal> apk update; apk add chrony-dbg ?
2023-03-04 02:17:24 <aeroraptor> https://paste.millerjs.org/xozatunefu.txt
2023-03-04 02:18:32 <minimal> "<psykose> then r, bt full"
2023-03-04 02:19:37 <minimal> AFAIK the "r" runs the program until it crashed, the "bt full" shows a full backtrack of when it died
2023-03-04 02:19:45 <minimal> s/backtrack/backtrace/
2023-03-04 02:19:45 <alpine-meetbot> minimal meant to say: AFAIK the "r" runs the program until it crashed, the "bt full" shows a full backtrace of when it died
2023-03-04 02:20:05 <aeroraptor> oh that's a cute bot lol
2023-03-04 02:20:07 <aeroraptor> okay I'm testing now
2023-03-04 02:20:33 <skarnet> I don't know chrony, but what I do know is that syncing on UTC is a historical mistake that makes it impossible to properly synchronize around a leap second
2023-03-04 02:20:41 <skarnet> in practice it makes no difference 99.5% of the time
2023-03-04 02:20:53 <aeroraptor> you are 100% correct
2023-03-04 02:21:03 <aeroraptor> leap seconds were a mistake
2023-03-04 02:21:14 <minimal> well they are talking about getting rid of them
2023-03-04 02:21:16 <skarnet> that's not what I'm saying
2023-03-04 02:21:36 <aeroraptor> https://paste.millerjs.org/ziqaromuyo.txt
2023-03-04 02:21:48 <skarnet> that's unfortunately a misconception, leap seconds are not the mistake, the mistake is having made them mandatory at the machine level instead of the user interface level
2023-03-04 02:22:11 <aeroraptor> okay yeah you're right
2023-03-04 02:22:15 <skarnet> NTP using UTC to synchronize instead of TAI is the mistake
2023-03-04 02:22:19 <aeroraptor> they are a human thing like time zones
2023-03-04 02:22:22 <skarnet> exactly
2023-03-04 02:22:59 <aeroraptor> I was talking about this with my dad earlier today hahah when I was explianing this to him (he's a ham and very much a nerd do he's into this shit)
2023-03-04 02:23:21 <aeroraptor> and he was like "well what about 200 years from now when suddenly it gets dark at 2PM at the equator???"
2023-03-04 02:23:31 <aeroraptor> and I was like... *emphatic eye rolling* 
2023-03-04 02:24:03 <skarnet> I'll honestly be surprised if computers are still a thing in 200 years
2023-03-04 02:24:36 <skarnet> but for the next 20-30 years, yeah, if you want to aim at the mystical 100% correctness, you'll need to sync over TAI, not UTC :)
2023-03-04 02:35:26 <aeroraptor> yup yup
2023-03-04 02:35:57 <aeroraptor> psykose: did you see that paste 
2023-03-04 02:36:53 <psykose> you didn't add chrony-dbg
2023-03-04 02:38:59 <aeroraptor>  gdb --args chronyd-dbg -f /etc/chrony/chrony.conf -d -U
2023-03-04 02:39:01 <aeroraptor> like that?
2023-03-04 02:40:18 <abby> is the package chrony-dbg installed?
2023-03-04 02:44:19 <aeroraptor> yes it is, but I can't find what actually was installed 
2023-03-04 02:50:30 <psykose> https://img.ayaya.dev/4ebOjXfTlTHw
2023-03-04 02:51:02 <aeroraptor> okay, thank you, I will try it tomorrow 
2023-03-05 09:47:14 <staceee> someone got waydroid to works? It just fails with this message on edge "modprobe: FATAL: Module binder_linux not found in directory"
2023-03-05 09:47:37 <staceee> looks like we don't have the options enabled: https://github.com/waydroid/waydroid/issues/30
2023-03-05 09:54:32 <psykose> it's enabled in -lts but not in -edge
2023-03-05 09:59:56 <staceee> mhh
2023-03-05 10:00:09 <staceee> can it be enabled in -edge?
2023-03-05 10:00:21 <staceee> or there is a reason not to?
2023-03-05 10:01:13 <vyivel> a more general question: any reason to not keep modules in sync? iirc hid_playstation is in -edge but not -lts
2023-03-05 10:02:49 <staceee> to me it looks curious edge got less modules than lts. The contrary looks less problematic
2023-03-05 10:39:47 <psykose> they're maintained by separate people that do different things :p
2023-03-05 10:40:05 <psykose> you can always open issues and ask for stuff i guess
2023-03-05 10:40:17 <psykose> personally i just build my own
2023-03-05 11:07:46 <EvTheFuture> @psykose: A while ago you pointed me to use clang and compiler-rt when compiling pipewire after my previous debugging session. I'm currently trying to find another possible bug in pipewire and are giving compiler-rt and clang shot but fail to build it. If you could just take a quick look at the output and my modifications to the APKBUILD to see what I've missed/messed up, I'd
2023-03-05 11:07:47 <EvTheFuture> appreciate it greatly: https://tpaste.us/NBmy and APKBUILD https://tpaste.us/xykl
2023-03-05 11:10:37 <psykose> for pipewire specifically you just can't iirc
2023-03-05 11:10:46 <psykose> they had some weird stuff that made it impossible
2023-03-05 11:15:19 <psykose> aside from that not really sure
2023-03-05 11:15:25 <psykose> sam_: do you perhaps remember this
2023-03-05 11:16:10 <psykose> it fails with https://img.ayaya.dev/HyOigeWpC8kt and the asan is https://img.ayaya.dev/wPySTGvlMYqk , so i'm not actually sure what is wrong
2023-03-05 11:16:14 <psykose> it does work for everything else
2023-03-05 11:28:10 <EvTheFuture> @psykose: In other words the APKBUILD looks ok to you?
2023-03-05 11:28:41 <psykose> in terms of what you wanted to do? sure
2023-03-05 11:30:52 <EvTheFuture> Well this is the issue I'm rebuilding pipewire for: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3063
2023-03-05 11:33:16 <psykose> most of the useful information you would get is just backtracing the core dump with the debug symbols
2023-03-05 18:55:10 <psykose> nvm, i forgot to read the logs
2023-03-05 18:58:06 <psykose> EvTheFuture: https://img.ayaya.dev/K5qmCQFP4d1X
2023-03-05 18:58:14 <psykose> you just need -Db_lundef=false
2023-03-05 21:03:23 <elibrokeit> WhyNotHugo: yet again someone trying to package hyprland and discovering that the developer doesn't want it to be packaged, huh?
2023-03-05 21:06:27 <WhyNotHugo> elibrokeit: I've seen worse
2023-03-05 21:06:37 <elibrokeit> I bet you haven't
2023-03-05 21:06:56 <abby> elibrokeit: must be a tuesday
2023-03-05 21:07:06 <elibrokeit> the hyprland developer has a very... nasty... way of speaking to users
2023-03-05 21:09:06 <elibrokeit> significant degree of third-grade potty humor is matched and exceeded by hysterical threats to prosecute packagers for "violating the geneva conventions", as a ground level state of being. But if you dig in deep, the author actually does get seriously nasty.
2023-03-05 21:19:20 <WhyNotHugo> I'm not sure I follow
2023-03-05 21:22:07 <elibrokeit> Listen, do whatever you want. :) However, I continue to not understand, why is this piece of artisanal half-melted pottery so interesting to people.
2023-03-05 21:22:39 <elibrokeit> If you'd like to tilt at windmills to try packaging it, go right ahead.
2023-03-05 21:22:47 <ikke> probably because it's shiny :P
2023-03-05 21:23:44 <skarnet> elibrokeit: it's a law of nature, the more unpleasant the developer, the more hoops people will jump through to accommodate them, and the more flexible the developer, the more disinterested people are
2023-03-05 21:24:06 <skarnet> like human/cats relationships, or men/women
2023-03-05 21:25:16 <elibrokeit> I don't even understand why it's considered shiny.
2023-03-05 21:25:57 <ikke> Look at all those shiny github stars
2023-03-05 21:25:59 <ikke> it must be good
2023-03-05 21:26:40 <abby> it has animations! and rounded corners!!
2023-03-05 21:34:32 <WhyNotHugo> I wrote/maintain shotman, and want to know on which compositors it works.
2023-03-05 21:37:11 <elibrokeit> maybe just lean on "but any wlroots-based compositor should work"
2023-03-05 21:37:39 <elibrokeit> or, you know, git clone the repo, run make, and execute the compositor as ./<name> for a one-off test :P
2023-03-05 21:38:36 <elibrokeit> you don't need to make an alpine package for it, nor try to figure out how to use system wlroots, if all you want is to verify that your program works okay on it
2023-03-05 21:38:36 <bl4ckb0ne> elibrokeit: hyprland targets the r/unixporn users
2023-03-05 21:38:37 <alpine-meetbot> [reddit] https://reddit.com/r/unixporn | 425,663 subscribers | Created at 2011-09-27 - 22:48:33UTC | Submit screenshots of all your *NIX desktops, themes, and nifty configurations, or submit anything else that will make ricers happy. Maybe a server running on an Amiga, or a Thinkpad signed by Bjarne Stroustrup? Show the world how pretty your computer can be!
2023-03-05 21:39:40 <vyivel> ^ is this really useful
2023-03-05 21:44:15 <bl4ckb0ne> i also heard some horror story about their discord server
2023-03-05 21:45:24 <bl4ckb0ne> also https://blog.vaxry.net/articles/Hyprland%20and%20the%20bundled%20wlroots
2023-03-05 21:45:27 <ikke> vyivel: it's default behavior of the bot and it's rare enough that I don't feel to compelled to do anything about it 
2023-03-05 21:54:33 <skarnet> bl4ckb0ne: "Hyprland is aiming to be bleeding edge" yeah ok so packaging it is useless
2023-03-05 21:54:42 <bl4ckb0ne> yep
2023-03-05 21:55:17 <bl4ckb0ne> i dont think they understand software release cycle
2023-03-05 21:56:24 <WhyNotHugo> I tend to agree on that. A stable release should work with SOME stable release of its dependencies.
2023-03-05 21:56:49 <bl4ckb0ne> at least it proves one thing
2023-03-05 21:56:54 <bl4ckb0ne> anybody can use wlroots 
2023-03-05 22:05:04 <skarnet> stable release? never heard of her
2023-03-05 22:06:32 <elibrokeit> > In the beginning, Hyprland did not bundle wlroots. We just would depend on wlroots-git
2023-03-05 22:06:44 <elibrokeit> which is... also problematic.
2023-03-05 22:06:58 <elibrokeit> because how can you *possibly* know that wlroots is new enough, let alone too old?
2023-03-05 22:07:07 <elibrokeit> err, too new
2023-03-05 22:10:20 <bl4ckb0ne> arch users smh
2023-03-05 22:11:12 <bl4ckb0ne> imagine waking up at 2am to fix the compilation of your shiny project 
2023-03-05 22:12:49 <elibrokeit> why not just always lock to the most recent stable release
2023-03-05 22:13:18 <elibrokeit> > Because Hyprland is aiming to be bleeding edge, offering users the newest features from wlroots
2023-03-05 22:13:26 <elibrokeit> riiiiiiiiiiiiiiiiiight
2023-03-05 22:16:04 <bl4ckb0ne> https://blog.vaxry.net/articles/Addressing%20some%20common%20Hyprland%20complaints ;)
2023-03-05 22:20:42 <paper_> also the dev is an edgy teen bigot https://imgur.io/a/6Po3Paq https://fosstodon.org/@TheEvilSkeleton/109587658504727925
2023-03-05 22:23:24 <bl4ckb0ne> ah thats the toot i was talking about thanks
2023-03-05 22:24:42 <bl4ckb0ne> "spread hyprland superiority" lovely
2023-03-05 22:51:36 <elibrokeit> the fact that hyprland uses discord for its support channel is probably a big huge red flag all on its own
2023-03-05 22:54:14 <orbea> requiring using malware to get support lol
2023-03-05 22:54:24 <orbea> *sigh*
2023-03-06 00:38:27 <aeroraptor> psykose: https://paste.millerjs.org/raw/wucesufudo
2023-03-06 00:39:05 <aeroraptor> I don't know why it's saying no debugging symbols found, I have chronyd-debug installed, and there's a file at /usr/lib/debug/usr/sbin/chronyd.debug
2023-03-06 13:22:13 <psykose> well, there's a clue anyway
2023-03-06 13:22:29 <psykose> it's doing setenv("TZ", NULL, 1);
2023-03-06 13:22:35 <psykose> not exactly valid
2023-03-06 13:23:05 <psykose> hm or is it
2023-03-06 13:23:33 <psykose> isn't
2023-03-06 13:27:09 <psykose> my favorite part of the hyprland drama is everyone gives it shit for the bundled wlroots but we already have bundled wlroots projects in aports
2023-03-06 13:27:12 <psykose> smh double standards
2023-03-06 13:28:08 <psykose> except even worse, they're outdated and forked bundled wlroots :p
2023-03-06 13:28:48 <bl4ckb0ne> but we're not 19 years old edgelords
2023-03-06 13:30:15 <psykose> hey hey
2023-03-06 13:30:21 <psykose> as someone presently geographically in poland
2023-03-06 13:30:27 <psykose> it's geographically appropriate i'll have you know
2023-03-06 13:34:25 <bl4ckb0ne> pls send me some kielbasa
2023-03-06 13:39:43 <psykose> if only i know what that is
2023-03-06 13:41:21 <paper_> I was something like 10 m away from Poland yesterday :)
2023-03-06 13:53:52 <psykose> come fight me before i leave
2023-03-06 13:58:51 <paper_> 
ACTION is going 100km/h away from Polish border right now

2023-03-06 13:59:12 <paper_> I will be closer to Austria than Poland in a minute
2023-03-06 14:03:10 <WhyNotHugo> FWIW, bundling older versions of libraries is the norme in Rust and Golang where binaries statically link all their dependencies.
2023-03-06 14:03:17 <WhyNotHugo> Though they usually bundle old *stable* releases.
2023-03-06 14:10:48 <ikke> Many go projects use dependabot or similar to automatically bump dependencies, though 
2023-03-06 14:23:51 <orbea> rust has tools like that too
2023-03-06 14:24:28 <orbea> although i personally dont like the mass vendoring...
2023-03-06 14:24:51 <orbea> you end up patching long fixed bugs over and over and over....
2023-03-06 14:25:12 <ikke> It's not vendoring 
2023-03-06 14:25:22 <ikke> At least, in most cases 
2023-03-06 14:26:01 <orbea> its vendoring as in many projects have their own versions of every crate rather than using system versions
2023-03-06 14:29:45 <skarnet> <WhyNotHugo> FWIW, bundling older versions of libraries is the norme in Rust and Golang where binaries statically link all their dependencies.
2023-03-06 14:30:01 <skarnet> and then people wonder why I scoff at new languages
2023-03-06 14:30:42 <skarnet> how about, y'know, you actually inject some engineering sanity into your new hype shit?
2023-03-06 14:31:49 <orbea> i wish ^
2023-03-06 14:32:15 <orbea> maybe controversial to say, but rust is extend, embrace, extinguish
2023-03-06 14:39:13 <skarnet> if that's really what they want... *that* is wishful thinking XD
2023-03-06 14:40:06 <orbea> skarnet: its already in the browsers and now its getting shoved into the graphics drivers and kernel
2023-03-06 14:40:13 <minimal> SBOMs for rust-based distros (if they exist) must be "interesting", showing a million-and-1 versions of each crate lol
2023-03-06 14:40:27 <orbea> and if you try to tell any of these devs, almost all of them act like they just saw heresy
2023-03-06 14:41:11 <orbea> not to say they are in on it
2023-03-06 14:41:16 <skarnet> orbea: oh, it's spreading for sure, but that has nothing to do with EEE
2023-03-06 14:41:20 <skarnet> they're not killing anything
2023-03-06 14:41:30 <skarnet> they're just adding your own problem to the pile of problems
2023-03-06 14:41:36 <skarnet> s/your/their/
2023-03-06 14:41:36 <alpine-meetbot> skarnet meant to say: they're just adding their own problem to the pile of problems
2023-03-06 14:42:06 <orbea> a problem that was created by deep pockets
2023-03-06 14:42:19 <skarnet> that's what deep pockets do
2023-03-06 14:45:22 <orbea> its a hypothesis that all the financial interest is to subvert and control free software spaces, but maybe im wrong :shrug:
2023-03-06 14:57:54 <psykose> suckless people pretending someone even wants to control their fancy space xD
2023-03-06 14:57:55 <psykose> good one
2023-03-06 14:59:02 <orbea> yea, i dont mean suckless, that is disengenious
2023-03-06 14:59:25 <orbea> i mean the kernel, the browsers, graphics drivers, othey key components
2023-03-06 14:59:30 <orbea> *other
2023-03-06 14:59:37 <orbea> there is a lot of money in that these days
2023-03-06 15:01:47 <psykose> it's much much more simple than that i'm afraid
2023-03-06 15:01:59 <psykose> the reason that is that nobody wants to write C except 4 people on irc
2023-03-06 15:01:59 <orbea> hmm?
2023-03-06 15:02:38 <orbea> so they all adopt the corporate hype language that is worse in basically every regard?
2023-03-06 15:02:52 <valerius> nobody under 35 wants to write C :(
2023-03-06 15:03:17 <valerius> yeah, people have decided that "new is always better" in many cases
2023-03-06 15:03:42 <valerius> and then they will end up having to solve all the old problems again in a new way
2023-03-06 15:03:59 <psykose> if you close your ears and scream into the ground that it's definitely "worse in every regard because i said so" and "shiny new thing bad" then yeah, certainly
2023-03-06 15:04:02 <psykose> you are always right :)
2023-03-06 15:04:22 <psykose> lots of people that aren't you, however
2023-03-06 15:04:28 <psykose> and they all wrote many languages
2023-03-06 15:04:32 <psykose> and they picked one they enjoy more :p
2023-03-06 15:04:33 <valerius> it does not have to be one of those polar opposites though
2023-03-06 15:04:38 <valerius> I'll take new if it is actually better
2023-03-06 15:04:39 <psykose> there's really nothing more to it than that
2023-03-06 15:05:12 <orbea> sarcasm is not going to convince anyone
2023-03-06 15:05:18 <valerius> "look at how smart I am because I made something complicated" is often the reason for "new" though
2023-03-06 15:05:23 <psykose> i'm not trying to convince you
2023-03-06 15:05:29 <psykose> i already know you are a doomerist lost cause
2023-03-06 15:05:36 <psykose> but i can certainly have fun in an irc channel
2023-03-06 15:06:04 <orbea> 
ACTION shrugs, "fun" is subjective

2023-03-06 15:06:09 <psykose> at the end of the day you can write and use whatever you want
2023-03-06 15:06:12 <psykose> that in itself has never changed
2023-03-06 15:06:15 <orbea> and this is not going anywhere so I will stop
2023-03-06 15:07:15 <psykose> and if every "graphics driver" developer decided at once they actually wanted to write it in rust (like they apparently seem to be doing, if that's what you think they are), then maybe there is a reason for that
2023-03-06 15:07:25 <psykose> and if you are unhappy with it, all you can do is write your graphics drivers yourself
2023-03-06 15:08:16 <valerius> that's not really an answer, coming from the perspective of someone who has spent thousands of hours writing software because I decided to "do it better myself" :(
2023-03-06 15:08:41 <valerius> robust discussions on the value of a technology are necessary
2023-03-06 15:08:52 <valerius> it can't simply be "someone dislikes something, shut them up immediately!"
2023-03-06 15:11:05 <psykose> if only i had the power to just shut people up immediately lol
2023-03-06 15:11:27 <psykose> i'm just telling you these people that suddenly went from C to rust after writing drivers for 10 years are doing it for a reason
2023-03-06 15:11:35 <psykose> and all you can tell them is "rust bad stop using it"
2023-03-06 15:11:38 <psykose> they're not going to listen to that
2023-03-06 15:11:44 <psykose> do whatever you want with this advice
2023-03-06 15:12:20 <psykose> including discuss it! but it just might not actually go anywhere
2023-03-06 15:12:38 <psykose> and in the end, what can anyone complaining about it do, if nothing changes?
2023-03-06 15:12:50 <valerius> well, the way I see it, it seems like the discussion is not allowed in those spaces
2023-03-06 15:14:22 <psykose> as someone that has read that discussion for years i don't think that's a fair assessment
2023-03-06 15:14:40 <valerius> has it been considered "settled, never revisit"?
2023-03-06 15:22:18 <valerius> anyway, if one finds themself getting emotional over software for any reason, it is likely unrelated to technology at that point
2023-03-06 15:22:20 <valerius> until next time!
2023-03-06 15:22:49 <psykose> certainly a good thing to take a break when you get emotional, yes
2023-03-06 15:29:02 <Piraty> is patching upstream sources to disable auto-update / update notifications and such (by fetching upstream website for example) in scope of aports ? i mean it's defunct for auto-update anyway
2023-03-06 15:39:21 <psykose> yes
2023-03-06 16:26:49 <skarnet> <@psykose> i'm just telling you these people that suddenly went from C to rust after writing drivers for 10 years are doing it for a reason
2023-03-06 16:27:16 <skarnet> I for one welcome the departure of these people from the C programmer space :P
2023-03-06 16:28:18 <skarnet> if you don't think that C is the correct language to write a friggin *driver* then you're right and you should stop writing drivers in C
2023-03-06 16:29:08 <psykose> thinking C is the only language to write drivers in is equally completely stupid
2023-03-06 16:29:15 <psykose> it's so funny it makes me laugh out loud, even
2023-03-06 16:30:27 <skarnet> well I'm still waiting for a language that does low-level things with the same amount of control that C gives you, all I can say is Rust isn't it
2023-03-06 16:31:21 <psykose> yeah, it sadly has even more control
2023-03-06 16:31:24 <psykose> gotta wait for a downgrade
2023-03-06 16:32:32 <skarnet> you're busting the bad faith meter today and I don't have many in store, I'll wait until tomorrow :P
2023-03-06 16:49:12 <aeroraptor> 8:22:29 AM <@psykose> it's doing setenv("TZ", NULL, 1);
2023-03-06 16:49:12 <aeroraptor> 8:22:35 AM <@psykose> not exactly valid
2023-03-06 16:49:12 <aeroraptor> so is this chrony playing badly, or what?
2023-03-06 16:49:21 <psykose> probably
2023-03-06 16:49:37 <psykose> it's in reference.c
2023-03-06 16:49:44 <psykose> the only two setenv's in the program
2023-03-06 16:49:55 <psykose> i can see how it /can/ happen but ofc i didn't write the program
2023-03-06 16:49:58 <aeroraptor> I'm all for posting it to the chrony-dev peeps but I'm not really sure how to articulate the problem as of yet - I wish I could get chrony-dbg to work properly
2023-03-06 16:50:00 <aeroraptor> sure
2023-03-06 16:50:02 <psykose> the only bug reports they take are the mailing list apparently
2023-03-06 16:50:32 <psykose> as for chrony-dbg not sure
2023-03-06 16:50:51 <psykose> should just work, weird
2023-03-06 17:55:45 <minimal> aeroraptor: seems you didn't set "leapsectz" in chrony.conf
2023-03-06 17:57:27 <aeroraptor> minimal: I did thought! https://paste.millerjs.org/raw/gafivuheci
2023-03-06 17:57:30 <aeroraptor> though* 
2023-03-06 17:59:49 <minimal> strange, from config.c and reference.c leap_tzname is set based on leapsectz value in config file
2023-03-06 18:01:27 <minimal> aeroraptor: ah, did you checks logs for "Timezone ... failed leap second check, ignoring"?
2023-03-06 18:02:00 <aeroraptor> chrony logs? they don't get any output before it segfaults. 
2023-03-06 18:10:09 <minimal> ok, that's the only place I set leap_tzname being set to NULL
2023-03-06 18:16:56 <aeroraptor> this should technically work, as is, but I'm thinking that for this machine, in the short term, what I could do is configure SDP0 on /dev/ptp0 to be a generic PPS source, and then use gpsd's SOCK or SHM0 for the wallclock time
2023-03-06 18:22:41 <minimal> " this should technically work, as is"? chronyd is seg faulting because it tried to set TZ to null, the only place I can see the value to be set for TZ being NULL is where "leapsectz" is specified but that that file doesn't have "good data" for Jun 30 2012 and Dec 31 2012 (from the comment in the code)
2023-03-06 18:23:24 <aeroraptor> oh I mean the setup I am running should work
2023-03-06 18:23:46 <aeroraptor> also, this is what chronyd spits out when I run the config file with the refclock commented out: https://paste.millerjs.org/raw/yigaqufayu
2023-03-06 18:25:31 <minimal> aeroraptor: that's the EXACT message I asked you to look for earlier
2023-03-06 18:26:01 <aeroraptor> I just didn't get a chance to see it until I ran when the ptp0 refclock disabled 
2023-03-06 18:26:14 <minimal> so the "right/UTC" file does not have "good data" for Jun 30 2012 and Dec 31 2012
2023-03-06 18:27:41 <aeroraptor> https://github.com/mlichvar/chrony/blob/master/doc/chrony.conf.adoc#leapsectz
2023-03-06 18:27:50 <minimal> wondering if there's a difference in behaviour between musl and glibc setenv and perhaps the setenv TZ with NULL doesn't segfault on glibc systems
2023-03-06 18:27:58 <aeroraptor> at the bottom of this section there is a little command string that can be used to test right/UTC
2023-03-06 18:28:10 <aeroraptor> and it works on my debian and arch boxes, but fails on my alpine boxes
2023-03-06 18:28:13 <aeroraptor> so I think you're right
2023-03-06 18:28:23 <aeroraptor> $ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
2023-03-06 18:29:41 <minimal> I'm referring to here: https://github.com/mlichvar/chrony/blob/master/reference.c#L265
2023-03-06 18:29:53 <minimal> where the else clause is then leading to the segfault you see
2023-03-06 18:32:14 <aeroraptor> can run the same test with a date in that range - TZ=right/UTC date -d 'Jun 30 2012 23:59:60'
2023-03-06 18:38:05 <minimal> aeroraptor: and Dec 31 2012 ?
2023-03-06 18:38:45 <aeroraptor> I can try, but according to NIST there wasn't a leap second on that date, I'm not sure why it's picked
2023-03-06 18:38:46 <aeroraptor> https://www.nist.gov/pml/time-and-frequency-division/time-realization/leap-seconds
2023-03-06 18:39:12 <aeroraptor> yeah, a leap second on 2012-12-31 fails
2023-03-06 18:39:20 <aeroraptor> (on my debian box)
2023-03-06 18:39:34 <minimal> aeroraptor: yes, look at the code link I posted, it is checking that there IS a leap second for Jun 30 2012 and that there is NOT a leap second for Dec 31 2012
2023-03-06 18:39:46 <aeroraptor> oh doh of course, I misread it
2023-03-06 18:39:55 <minimal> it is also checking tai_offset in both cases as well
2023-03-06 18:40:28 <minimal> so at least 1 of those 4 connditions that it checks is not met
2023-03-06 22:58:13 <Quillith> Hello, I'm trying to make my first package and was wondering where I could find more info on the part of the template where it says "replace with proper build commands" 
2023-03-06 23:01:30 <Quillith> Arch linux has tcc listed as its sole dependency, which wikipedia says is a tiny c compiler, but some of the examples in the aports directory I'm looking at seem to use meson to build. Is meson usually used in Alpine to build?
2023-03-06 23:05:12 <ptrc> Quillith: it depends on the project you're trying to build
2023-03-06 23:05:40 <ptrc> if they use meson (have meson.build file, etc.) then you can use meson to build it
2023-03-06 23:14:37 <Quillith> Okay, thank you. The makefile on github says build: envload , i'll keep looking
2023-03-06 23:16:02 <Quillith> followed the wiki's recommendation to check out the arch pkgbuild, I'll probably reference that a lot
2023-03-06 23:32:05 <Quillith> I ran abuild -r and it said 'source 1.0.4.tar.gz needs to be renamed to avoid possible collisions'. All I put in source was the URL for the github's tar download, what could abuild be colliding with?
2023-03-06 23:32:49 <ptrc> files downloaded from upstream get stored in the global cache
2023-03-06 23:33:03 <ptrc> both on your computer (/var/cache/distfiles) and on the actual alpine builders
2023-03-06 23:33:33 <ptrc> so if you have a file that just says 1.0.4.tar.gz and someone makes the same mistake, it's gonna assume the source has already been downloaded and use the wrong file
2023-03-06 23:33:55 <ptrc> to avoid that, you can just prefix the url with `$pkgname-$pkgver.tar.gz::` - the `::` part is the delimiter between target filename and URL
2023-03-06 23:38:05 <Quillith> Okay, so instead of "https://github.com/jcnils/protonhax/archive/refs/tags/1.0.4.tar.gz" I would put source as "$pkgname-$pkgver.tar.gz::https://github.com/jcnils/protonhax/archive/refs/tags/1.0.4.tar.gz" , thank you
2023-03-06 23:48:17 <ptrc> well, yeah, but you can't hardcode the version
2023-03-06 23:53:21 <Quillith> Oh, good point, so would " $pkgname-$pkgver.tar.gz::https://github.com/jcnils/protonhax/archive/refs/tags/$pkgver.tar.gz " be better then?
2023-03-07 00:00:20 <Quillith> So it looks like abuild -r worked, but at the end it says UNTRUSTED signature and error failed to create index 
2023-03-07 01:52:55 <Quillith> I successfully built the apk, but when I point my repository file at the new directory I get an error- no such file or directory. But when I copypaste the error's path to cd into the directory that works. Does a repository need a special formatting or pathing to work? What generated for me was /home/nick/packages/nick/x86_64/
2023-03-07 02:19:57 <Quillith> okay, I reduced the repo line to /home/nick/packages/nick/ and that worked, but now it's saying the signature is UNTRUSTED and won't build. How would I fix that
2023-03-07 02:25:19 <Quillith> I found an Alpine blog post from 2022, would this link still work or would I needd to update it to a  new version?apk add -X https://dl-cdn.alpinelinux.org/alpine/v3.16/main -u alpine-keys
2023-03-07 02:36:19 <ptrc> no, that's not the case here
2023-03-07 02:36:26 <ptrc> what you're missing is your own keys in the system trust
2023-03-07 02:36:56 <ptrc> if you look at the .abuild directory in your home, you can see the private key (ending with .rsa) and its public counterpart (.rsa.pub)
2023-03-07 02:37:03 <ptrc> you need to copy the latter into /etc/apk/keys/
2023-03-07 03:24:39 <elibrokeit> orbea: the browsers were always a lost cause if you don't want rust in your programs, on account of where rust came from... on the other hand my impression of the kernel was that they were only interested in adding support for optional new modules.
2023-03-07 03:26:21 <Quillith> holy cannoli it works! whoa! Thanks for your help 
2023-03-07 03:37:10 <orbea> elibrokeit: yep i agree regarding browsers, it was an example of how crucial parts of the ecosystem are being used to force this onto everyone and for kernels or mesa my assumption is it will be moving goal posts, but we'll see
2023-03-07 03:37:39 <orbea> i'd be happy to be wrong
2023-03-07 03:38:46 <elibrokeit> for mesa I don't know anything about limiting scope anyway, but I do know that they very much want to build rust code via meson and NOT via cargo, for a couple reasons including the fact that crates should have consistent versions
2023-03-07 03:38:56 <elibrokeit> (and meson will enforce no diamond dependencies)
2023-03-07 03:39:40 <elibrokeit> in slightly better news
2023-03-07 03:41:05 <elibrokeit> there is a rust-lang developer, who is trying to push for rust defining an actual "rich rust types" FFI, which is NOT just "bind it to C", and this is apparently going to maybe unlock a world where rust crates can be compiled to shared libraries and linked into multiple rust programs
2023-03-07 03:42:07 <abby> ooh, got anymore info/links about that?
2023-03-07 03:43:24 <elibrokeit> https://github.com/rust-lang/rust/pull/105586
2023-03-07 03:44:51 <abby> nice thanks
2023-03-07 03:46:41 <elibrokeit> if rust developers can avoid translating functions into "unsafe C" and immediately back when communicating over a shared library interface, they may become a lot more tempted to compile librust-foobar.so as shared functionality instead of always vendoring it and statically linking it
2023-03-07 03:46:56 <abby> it's me, i'm rust developers
2023-03-07 03:47:36 <orbea> elibrokeit: yea, the biggest issue imo are crates
2023-03-07 03:48:00 <orbea> gcc-rs also may offset some of the pain
2023-03-07 03:49:19 <abby> i see gcc-rs succeeding in the same way that gcc-go has succeeded
2023-03-07 03:49:38 <orbea> i really hope so
2023-03-07 03:49:44 <abby> that was sarcasm
2023-03-07 03:49:49 <orbea> lol
2023-03-07 03:49:54 <orbea> the bar is already very low
2023-03-07 03:50:02 <elibrokeit> now if only compilers would start shipping support for #embed
2023-03-07 03:50:19 <orbea> (and i am not forced into using go so I dont know how bad that really is or not)
2023-03-07 03:51:11 <elibrokeit> IIRC gcc-go was perfectly fine a while back, but it basically came as a code dump from google and sort of bitrotted.
2023-03-07 03:52:36 <elibrokeit> also I feel like people care a lot less about go than they do about rust, so probably very few people cared to contribute to its maintenance
2023-03-07 03:53:16 <elibrokeit> certainly there were no kernel people saying they'd love gcc-go to be robust and useful "so we can compile some into our kernels"
2023-03-07 10:50:07 <dalias> elibrokeit, yay, 1500 ms startup times for rust programs..
2023-03-07 10:50:42 <dalias> if your libraries are at "crate" resolution, they absolutely should be static linked
2023-03-07 10:51:41 <dalias> and size, ntm memory at runtime, cost of shared libs is much higher than static until you reach a fairly large size threshold
2023-03-07 11:47:19 <WhyNotHugo> How did you guys realise so quickly that I was asking Hyprland-upstream some Alpine-related questions?
2023-03-07 11:47:26 <WhyNotHugo> I can't imagine you're monitoring issues for Hyprland.
2023-03-07 12:38:33 <elibrokeit> dalias: crate developers would have to manually opt into this anyway. So you can expect that it will only happen when specific rust developers have a high level crate they particularly want to share, which in turn statically links a bunch of other crates in at the rust level rather than the C library (either static *or* shared* level)
2023-03-07 12:40:47 <elibrokeit> which is a bad thing, because we deserve a world where we can generate static libraries for all crates at the crate level, build them once and link them statically many times. Something that Alpine isn't a stranger to...
2023-03-07 12:41:38 <elibrokeit> whether some people choose to use shared libs even for small libraries isn't really a language decision, it's a distributor decision
2023-03-07 13:14:06 <dalias> imo it would make sense for "large" things like a video codec library
2023-03-07 13:14:17 <dalias> but not things like leftpad
2023-03-07 15:34:49 <PabloCorreaGomez[m]> Hi all! Does alpine officially support upgrading multiple releases at a time? So let's say from 3.15 to 3.17 or from 3.16 to edge? I had the feeling that I had read here that it was not supported, but that information seems to be nowhere
2023-03-07 15:35:09 <PabloCorreaGomez[m]> So likely I'm just wrong, but wanted to double-check
2023-03-07 15:38:42 <elibrokeit> dalias: yes but I also think that things like left-pad shouldn't exist even as a source crate
2023-03-07 15:39:23 <elibrokeit> rust is better than npm here, but not exactly perfect
2023-03-07 15:41:36 <orbea> being better than npm is not exactly a compliment :)
2023-03-07 15:41:49 <skarnet> PabloCorreaGomez[m]: you should have no problems directly upgrading to the release you want.
2023-03-07 15:43:32 <minimal> PabloCorreaGomez: in general it depends, a few releases ago the package signing keys changes and you had to update that package before doing upgrades
2023-03-07 15:44:20 <minimal> so if you were on a release that didn't contain the new keys then you couldn't directly upgrade to current release
2023-03-07 15:48:23 <PabloCorreaGomez[m]> That makes sense. Thanks both for your comments!
2023-03-08 09:55:07 <ikke> To fix that, you only had to make sure alpine-keys was up to date though 
2023-03-08 09:55:29 <ikke> But checking release note (especially on the wiki) can help
2023-03-08 16:49:42 <donoban> ouch, I just noticed that pdfjs was removed acd74dd4d9feeb4be7990e48874da0d5853fcdd5
2023-03-08 16:50:00 <donoban> is there some problem with it or just removed due lack of attention?
2023-03-08 16:50:27 <ikke> sounds like the latter
2023-03-08 16:51:10 <donoban> ok so I will try to get it up to date
2023-03-08 17:08:50 <donoban> uhM, is distributed as source code (which needs a tool called gulp for bundle it) and a dist zip
2023-03-08 17:09:11 <donoban> I suppose that is better to use the source but it seems that gulp is not packaged
2023-03-08 19:43:12 <Luke> Hello, could someone give me a tip. Why do I always get a PXE boot image with the instructions? https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage I'm new to Alpine
2023-03-08 23:36:42 <mio> are the arm builders under maintenance?
2023-03-08 23:39:44 <mio> getting a timeout exceeded error on arm jobs: `ERROR: Job failed: failed to pull image "alpinelinux/gitlab-runner-helper:latest" with specified policies [always]: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) (manager.go:237:19s)`
2023-03-09 13:31:18 <midasi> MR !20664 always fails with a timeout on aarch64 and ppc64le. Should we disable these arches in the package or how to proceed?
2023-03-09 14:21:44 <ikke> midasi: we can try extending the pipeline duration a bit to see it just needs some more time
2023-03-09 14:22:19 <ikke> midasi: are you working together with Thermi?
2023-03-09 15:29:46 <midasi> ikke: yes exactly, we are working together. Please extend the timeout a bit
2023-03-09 15:29:56 <ikke> I already did
2023-03-09 15:40:06 <midasi> thank you, we will verify if it works now
2023-03-09 15:40:39 <ikke> aarch64 seems to be finishing
2023-03-09 15:40:44 <ikke> it's uploading artifacts
2023-03-09 15:40:52 <ikke> ppc64le is still building
2023-03-09 17:07:48 <midasi> ikke: the ppc64le failed again, this time after 2h
2023-03-09 17:53:09 <ikke> midasi: perhaps disable it on ppc64le then?
2023-03-09 17:53:58 <donoban> uhM, is not psykose here? this MR !44935 seems start a more deep debate (npm && pip vs apk) ...
2023-03-09 17:54:15 <ikke> donoban: she is traveling
2023-03-09 17:54:53 <donoban> ah, nice
2023-03-09 17:56:40 <Quillith> Hello, when an AUR pkgbuild has a section for optdepends and splits it up into #recommended and says #this is for bla, how does alpine handle that? Is it preferred to put all the optdepends as just dependencies?
2023-03-09 17:57:08 <Quillith> specifically I'm looking at https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nb
2023-03-09 17:57:16 <ikke> Quillith: there is no support for optional dependencies
2023-03-09 17:58:23 <ikke> You could have a post-install trigger that echoes these things, but they are a bit frowned upon if not done for a good reason
2023-03-09 17:58:47 <Quillith> hmm could I make a seperate package like nb-extra ?
2023-03-09 17:58:50 <ikke> (They are used sometimes for significant changes the user should be aware about)
2023-03-09 17:59:09 <ikke> You could make a subpackage that pulls in these dependencies, yes
2023-03-09 18:01:23 <Quillith> Thank you! Is there a naming convention for subpackages I should be aware of? If not I'd probably just follow how the author separated the dependencies ('nb' 'nb-recommended' 'nb-additional')
2023-03-09 18:02:57 <ikke> Not sure if there is any convention, but sometimes -full is used
2023-03-09 18:03:13 <Quillith> Okay, thanks! 
2023-03-09 18:03:22 <ikke> but that might imply that it contains more components of the package rather than just pull in extra dependencies
2023-03-09 18:03:45 <ikke> ruby-full does at least do that
2023-03-09 18:03:49 <ikke> just pull in more deps
2023-03-09 18:04:19 <ikke> but they do come from ruby itself
2023-03-09 18:59:32 <elibrokeit> donoban: seems pretty bizarre to reject a package on the grounds that it can be installed via pip/npm, I could follow down that line of thought and arrive at the notion that openssl can be installed with Conan and shouldn't be packaged either.
2023-03-09 18:59:48 <elibrokeit> so yeah I don't understand what the objection is to your MR
2023-03-09 19:04:41 <donoban> well, or even you can run things on flatpak or container images... 
2023-03-09 19:07:17 <donoban> I'm opened to the possiblity that relying on pip would avoid reinvent the wheel, but it should be integrated on abuild don't just remove all packages that are already on pip repositories
2023-03-09 19:16:54 <elibrokeit> qutebrowser itself recommends pip as one of the official install processes
2023-03-09 19:17:04 <elibrokeit> who needs an alpine package??? :p
2023-03-09 19:17:07 <mercenar-> There is an underlying assumption there that all computers/containers have unrestricted access to anything anywhere internet
2023-03-09 19:17:49 <mercenar-> In some environments, that may not be the case. E.g. isolated networks with access to a local repo
2023-03-09 21:25:19 <Quillith> The package works, but I'm going through the Code Review section of the wiki and am wondering, how do I tell whether there is a test suite? What is the sign of a test suite being present
2023-03-09 21:26:52 <bl4ckb0ne_> usually theres a test folder in the project
2023-03-09 21:27:03 <bl4ckb0ne_> or a test target in the build system
2023-03-09 21:27:17 <abby> can also be called check
2023-03-09 21:27:19 <bl4ckb0ne_> you can also check if the projecr has a CI
2023-03-09 21:27:35 <bl4ckb0ne_> if there's teat they run there
2023-03-09 21:38:00 <Quillith> Okay, thank you
2023-03-09 21:45:35 <Quillith> Is code review something that happens before or after I go to Alpine's GitLab instance and create a merge request?
2023-03-09 21:48:18 <ikke> after you make a merge request
2023-03-09 21:48:28 <ikke> ie, the merge request is what's get reviewed
2023-03-09 21:48:43 <Quillith> ohh ok, thank you
2023-03-09 21:59:22 <psykose> i used some "mobile internet" going 200km/h across nowhere in sweden in a train in a snowstorm
2023-03-09 21:59:31 <psykose> and it was probably still better than our ARM server networking
2023-03-09 21:59:34 <psykose> hot competition !
2023-03-09 21:59:42 <ikke> Something something LTE
2023-03-09 21:59:54 <psykose> (it was like 50kb/s and cut out every 3 minutes)
2023-03-09 22:01:15 <psykose> also we really have to fix that armhf rust thing
2023-03-09 22:01:25 <psykose> time to nosedive back into reading some lxc configs i guess
2023-03-09 22:11:48 <ikke> psykose: good news and bad news
2023-03-09 22:12:15 <psykose> bad news first
2023-03-09 22:12:23 <ikke> the arm builders no longer have ipv4
2023-03-09 22:15:55 <lucidiot> finally, the migration to ipv6 is complete
2023-03-09 22:26:28 <Quillith> I made a gitlab account and am in the Merge Requests forum, but the only 'create' button I see is a link to email a merge request to the list. But if I email the list how would the APKBUILD file be included, will it handle it correctly if I attach the file to the email?
2023-03-09 22:27:07 <ikke> Quillith: you need to create a fork first
2023-03-09 22:27:13 <ikke> not sure if you did that
2023-03-09 22:27:50 <Quillith> Was that the git pull and making a git commit message? I did that and formatted it by the wiki page
2023-03-09 22:28:01 <ikke> no
2023-03-09 22:28:17 <ikke> https://gitlab.alpinelinux.org/alpine/aports on the top right, there should be a fork button
2023-03-09 22:28:34 <psykose> ikke: and the good news? ;)
2023-03-09 22:28:52 <ikke> The connection to the builder should now be stable
2023-03-09 22:28:58 <psykose> hm
2023-03-09 22:28:58 <psykose> neat
2023-03-09 22:29:39 <ikke> but no ipv4 means no dmvpn
2023-03-09 22:30:45 <ikke> (somehow linux does not support multi-point gre over ipv6)
2023-03-09 22:38:07 <Quillith> I did it!!!!!Aahhhh!!!
2023-03-09 22:40:17 <Quillith> Thanks for your help explaining things!
2023-03-09 23:34:38 <Quillith> How do I update the merge request with the changes I've made to my file? Do I open a new one?
2023-03-09 23:35:33 <skarnet> just push your new changes to your branch, with --force if needed
2023-03-09 23:35:38 <skarnet> the mr will be automatically updated
2023-03-09 23:40:31 <psykose> git add .; git commit --amend; git push -f
2023-03-09 23:41:13 <abby> git commit --all --amend :0
2023-03-09 23:41:27 <abby> s/0/)/
2023-03-09 23:41:27 <alpine-meetbot> abby meant to say: git commit --all --amend :)
2023-03-09 23:58:17 <Quillith> "remote: you are not allowed to push code to this project"
2023-03-09 23:58:44 <Quillith> I ran cd aports ; git add testing/nb ; git commit --amend; git push -f
2023-03-10 00:03:24 <Quillith> The first commit I pushed was via the GUI of gitlab's webpage, but when I try to do that again it just says that the file already exists. bleck
2023-03-10 00:03:56 <paper_> you are trying to push directly to Alpine which you obviously can't 
2023-03-10 00:04:14 <paper_> you are supposed to push to the branch on your own fork
2023-03-10 00:07:30 <Quillith> oh wow that's not great, I'm glad it blocked me lol. So I need to point the command toward my fork instead of at Alpine, thanks
2023-03-10 00:16:48 <psykose> git remote remove origin; git remote add origin git@gitlab.alpinelinux.org:T-Quill/aports.git; git remote add upstream git@gitlab.alpinelinux.org:alpine/aports.git; git remote update --prune; git branch -u origin/nb
2023-03-10 00:16:59 <psykose> (if you're on a local branch named nb anyway)
2023-03-10 00:19:39 <Quillith> Thank you! So I do those once I get onto the local branch named nb
2023-03-10 00:25:12 <Quillith> I think I broke git, anytime I run git (status, checkout, or git remote remove origin) I just get "fatal: not a git repository). Is there a GUI way on gitlab's site to upload the file? I have my apkpackage file, I'm just struggling to get it on this site
2023-03-10 00:25:46 <psykose> as the error tells you: you are apparently not in a git repository
2023-03-10 00:25:58 <psykose> so either you are in the wrong folder or you deleted the .git folder from the repository somehow
2023-03-10 00:27:01 <Quillith> You were right, I had accidentally cd'd myself out of my aports directory. I will read about how to git onto my nb branch to run those commands and update the MR. Thanks
2023-03-10 00:49:09 <Quillith> psykose: thanks for your help and patience. I successfully committed. Appreciate your time
2023-03-10 12:17:24 <donoban> psykose: lol, it seems that pdfjs is currently broken in qutebrwoser/qt5webengine
2023-03-10 12:17:35 <donoban> https://github.com/qutebrowser/qutebrowser/issues/7335
2023-03-10 12:22:21 <donoban> "it's rather hacky, and PDF.js provides a legacy build which does work fine with Qt 5 still"
2023-03-10 17:10:06 <abby> ah yeah that https://github.com/void-linux/void-packages/pull/40078
2023-03-10 17:19:29 <Newbyte> Are the Alpine ARM builders gone?
2023-03-10 17:19:36 <Newbyte> Or, ARM CI builders
2023-03-10 18:26:58 <caskd> Did anyone try to fix the wwn by-id being associated to partition instead of disk with /lib/mdev/persistent-storage
2023-03-10 18:30:28 <minimal> caskd: are you referring to https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/3 ?
2023-03-10 18:31:21 <caskd> Nope, i'm talking more about having by-id/wwn-XX > ../sda1 which makes absolutely no sense
2023-03-10 18:31:40 <caskd> since partitions can't have WWN IDs
2023-03-10 18:32:17 <minimal> you mean by-id/wwn-XX-partX ?
2023-03-10 18:32:30 <caskd> i don't have any partX
2023-03-10 18:32:50 <caskd> the main wwn-X is supposed to point to the disk but points to a partition
2023-03-10 18:34:34 <minimal> and that is what that MR fixes - it adds the missing "{partsuffix}" for wwn-* links
2023-03-10 18:34:50 <minimal> so that the link name includes a "-partX" suffix
2023-03-10 18:34:52 <caskd> okay but does that also keep the main disk?
2023-03-10 18:35:00 <caskd> so the one without part?
2023-03-10 18:35:52 <caskd> oh wait
2023-03-10 18:35:53 <minimal> I believe currently without that fix it creates the link for the disk and THEN creates a link for each partition by REPLACING the link for the disk
2023-03-10 18:35:59 <caskd> yeah 
2023-03-10 18:36:04 <caskd> it just clicked for me too
2023-03-10 18:36:06 <caskd> i see
2023-03-10 18:36:07 <caskd> yes
2023-03-10 18:36:42 <caskd> yeah sorry i thought that MR didn't solve my problem but it would indeed do
2023-03-10 18:37:20 <minimal> a general point about /dev/disk/ entries in general, the set you get depends on whether you have util-linux's blkid or Busybox's blkid installed and also whether you're using mdev/mdevd or eudev
2023-03-10 18:38:04 <caskd> thanks, i am aware
2023-03-10 18:40:12 <minimal> I'm hoping to add some small programs for mdev/mdev to get additional info so that "missing" links (that eudev creates) can be implemented
2023-03-10 18:40:31 <caskd> Shouldn't be too hard to hack together
2023-03-10 18:41:15 <minimal> eudev has a couple of small programs it uses but was looking at some other alternatives
2023-03-10 18:57:06 <ikke> Newbyte: network issues 
2023-03-10 18:59:20 <macmpi> Newbyte: same here, no ARM builds for few hours. Was very hectic yesterday too
2023-03-10 19:08:52 <ikke> We are working on trying to get it working again 
2023-03-10 19:09:12 <Newbyte> Great to hear
2023-03-11 15:32:21 <ikke> psykose: I was thinking, would it make sense to test rust on armhf in a chroot to rule out any lxc specific issues? 
2023-03-11 15:32:50 <psykose> i already did that myself in the sense of just an armhf userspace container instead of lxc
2023-03-11 15:33:05 <psykose> it does work everywhere except that lxc setup, i already know it's "lxc specific" (with no idea where the fault is)
2023-03-11 15:33:13 <psykose> that's why i want the configs to reproduce myself and go from there :D
2023-03-11 15:33:47 <psykose> i could also try with just my own lxc configs and see if it's not our-config-specific too, was a bit lazy
2023-03-11 15:33:57 <psykose> if even that reproduces that is also convenient
2023-03-11 15:34:48 <psykose> 'armhf userspace container' i.e. arm32v6/alpine via containerd or whatever
2023-03-11 15:34:55 <psykose> it also does not reproduce in qemu-arm either
2023-03-11 15:46:13 <ikke> Any cli paste that supports ipv6?
2023-03-11 15:48:55 <psykose> 0x0.st maybe?
2023-03-11 15:48:58 <psykose> seems to have AAAA
2023-03-11 15:48:58 <psykose> curl -F'file=@yourfile.png' https://0x0.st
2023-03-11 15:49:47 <psykose> seems to work withg curl -6 for me
2023-03-11 15:50:12 <psykose> file=@- to use stdin but you knew that :-)
2023-03-11 15:52:23 <ikke> https://0x0.st/Hip8.conf
2023-03-11 15:52:36 <ikke> builder.common.conf
2023-03-11 15:52:40 <psykose> mhm
2023-03-11 15:53:30 <ikke> https://0x0.st/HipK.conf
2023-03-11 15:53:43 <ikke> default.conf
2023-03-11 15:54:26 <psykose> thanks
2023-03-11 15:54:31 <psykose> will have a go in a bit
2023-03-11 16:38:47 <psykose> this is more work than i expected to set up :p
2023-03-11 17:03:26 <psykose> ikke: can't reproduce
2023-03-11 17:03:46 <psykose> made an armhf container mostly the same, just different networking, with lxc 5.0.2 on edge on an rpi4
2023-03-11 17:03:56 <psykose> rustc doesn't hang in it
2023-03-11 17:04:06 <psykose> it is only the builder/ci containers :D
2023-03-11 17:04:24 <psykose> which lxc were we running anyway
2023-03-11 18:21:33 <psykose> so uhh yeah, you should try a chroot outside lxc
2023-03-11 18:21:40 <psykose> just in case it's the host itself or kernel being weird
2023-03-11 19:31:02 <ahills> psykose: hi, I see you updated the kitty terminal to 0.27.1 in edge, any chance you (or fcolista) would backport to 3.17?
2023-03-11 22:52:46 <PurpleChip> I'm working on running Alpine on a RK3399 board (R4S) but am struggling to understand how to create the image. I have Linux booting but it fails to find the rootfs (I think), initramfs appears to load. Is there any documentation about how to create an SD card image with the provided rootfs and boot files?
2023-03-11 22:56:06 <PurpleChip> According the Rockchip the partitions are as follows: https://opensource.rock-chips.com/wiki_Partitions, with that being the case I don't see a way to create an ext4 boot.img that contains Alpine's vmlinuz, initramfs, dtbs, and mods because the boot partition is only 112MB.
2023-03-12 03:41:43 <psykose> ahills: generally that's not done unless 0.26.5 is completely broken or something
2023-03-12 04:29:32 <ahills> ah ok
2023-03-12 11:31:38 <Ermine> aarch64, armhf and armv7 pipelines for !45023 timed-out. IIRC there was a button to restart them
2023-03-12 11:32:20 <ikke> Ermine: arm is defunct atm 
2023-03-12 11:33:18 <Ermine> ah
2023-03-12 12:59:59 <Ermine> https://github.com/apache/trafficserver/blob/9.2.x/include/tscore/ink_rwlock.h#L51 -- is this true for musl or can I remove this warning?
2023-03-12 13:07:28 <psykose> why would you ever remove a random warning
2023-03-12 13:07:32 <psykose> it doesn't do anything
2023-03-12 13:12:15 <Ermine> Only for more clean build process
2023-03-12 13:33:24 <Hello71> make >/dev/null 2>&1
2023-03-12 13:38:44 <Ermine> hehe
2023-03-12 13:40:48 <Ermine> https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/989917 --- In what side does stack grow on ppc64le ?
2023-03-12 13:41:44 <Ermine> https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/989917#L1054 To be precise
2023-03-12 14:26:23 <sam_> it's down on everything except for hppa and ia64 in some weird situations
2023-03-12 14:27:34 <Ermine> sam_: thank you
2023-03-12 14:30:02 <sam_> np
2023-03-12 14:49:01 <Ermine> psykose: dfu_programmer pipelines fail, tried abuild rootbld on my machine, it fails too due to update-bash-completion.sh . But update-bash-completion.sh does exist, so I don't know what's the problem.
2023-03-12 14:53:26 <psykose> it passes fine
2023-03-12 15:09:46 <Ermine> Okay then...
2023-03-12 18:17:07 <Ermine> Are there any stats on which packages are getting downloaded  and how many times
2023-03-12 18:17:09 <Ermine> ?
2023-03-12 18:21:27 <psykose> nope
2023-03-12 21:34:22 <ikke> Ermine: note that packages could be downloaded from any mirror
2023-03-13 00:40:52 <ptrc> $ curl 'https://gitlab.alpinelinux.org/api/v4/projects/1/merge_requests?state=opened&search=fq'
2023-03-13 00:41:09 <ptrc> i wonder if i'm doing something wrong, because i'm pretty sure this should return 1 result
2023-03-13 00:48:23 <Asmadeus> It seems to only match whole words... testing/fq finds it :|
2023-03-13 00:48:47 <Asmadeus> (I was sure one had to be authentified for that, but I guess not)
2023-03-13 09:14:52 <macmpi> Hi. Is there some indicative ETA for armhf/armv7/aarch build infra fix?
2023-03-13 09:22:40 <ikke> I hope to resolve it this week 
2023-03-13 09:31:40 <macmpi> ikke: thanks.
2023-03-13 09:32:13 <Newbyte> ikke: is there a tracking issue or something like that?
2023-03-13 09:34:28 <ikke> Newbyte: not yet 
2023-03-13 09:34:34 <Newbyte> also, I would like if you think this sounds good given that I'm writing about something that is about Alpine: https://gitlab.com/postmarketOS/postmarketos.org/-/merge_requests/207
2023-03-13 09:35:31 <Newbyte> for clarification: we have this "edge blog" in postmarketOS where we put up new posts whenever there is some problem with edge to notify users about it
2023-03-13 09:35:34 <Newbyte> just want to check with you so I'm not writing something dumb or incorrect
2023-03-13 09:35:50 <Newbyte> (by "you" I mean anyone here familiar with the infrastructure situation)
2023-03-13 09:36:07 <ikke> Yeah, not that it matters much but it's a network issue that causes it. 
2023-03-13 09:36:16 <ikke> Just as a fyi
2023-03-13 09:36:52 <Newbyte> Sure, thanks. Do you prefer if that's mentioned?
2023-03-13 09:38:28 <ikke> You mentioned they're unavailable, which should cover it 
2023-03-13 09:38:48 <Newbyte> 👍
2023-03-13 09:42:36 <ikke> The issues is that the builders are on a ipv6 only network which we were not setup for. When we migrated the builders there was Ipv4 connectivity, but that turned out was provided by an accidental LTE connection 
2023-03-13 09:43:25 <Newbyte> I'm curious how you accidentally get an LTE connection
2023-03-13 09:44:23 <mercenary> 't was supposed to be the OOB connection?
2023-03-13 09:52:46 <ikke> Newbyte: they have these router appliances that can provide internet via LTE. apparently there was a sim card present 
2023-03-13 11:19:57 <psykose> the pmos edge announcement things are very convenient
2023-03-13 11:20:40 <psykose> wish we had something like that sometimes :D
2023-03-13 11:22:18 <ncopa> where would we put it? on alpinelinux.org/ ?
2023-03-13 11:24:25 <psykose> well yeah, we already have the news there
2023-03-13 11:24:40 <psykose> it's more an organisation problem and structuring it and getting people to start following it, etc
2023-03-13 11:25:07 <psykose> 'pmos edge announcement thing' is a known pmos feature people actually check pretty sure, the issue is making the latter, not so much where one puts it
2023-03-13 11:25:36 <ncopa> might also make sense to separate the development news with the user news
2023-03-13 11:25:44 <psykose> yeah
2023-03-13 11:25:49 <ncopa> i dont think many end users cares about build infra
2023-03-13 11:26:01 <psykose> yep
2023-03-13 11:26:10 <psykose> though the above post (alpine builders down) is not an infra post
2023-03-13 11:26:15 <psykose> that is exactly the sort of useful thing to put
2023-03-13 11:26:44 <psykose> looks like this https://postmarketos.org/edge/
2023-03-13 11:26:48 <psykose> https://postmarketos.org/edge/2023/03/13/alpine-arm-builders-gone/
2023-03-13 11:26:54 <psykose> which is quite useful for "end user using edge"
2023-03-13 11:27:26 <psykose> e.g. so far i have told maybe 14 people the builders are down.. maybe if we had that it would be three instead
2023-03-13 11:27:37 <psykose> not an issue or anything, but just a useful way to spread some sorts of news
2023-03-13 16:13:52 <ncopa> I wonder if this would fix JIT on armv6: https://social.treehouse.systems/@marcan/110015868164496947
2023-03-13 16:15:45 <psykose> you mean for qt?
2023-03-13 16:16:08 <psykose> it might but it also doesn't really matter as i can think of precisely zero people that use graphical qt on armv6
2023-03-13 16:16:47 <psykose> you'd have to be insane to be doing that on 10+year old devices or some new rpi0 with 512M of ram :D
2023-03-13 16:17:05 <psykose> in any case i'd imagine it will be `upstream' at some point into the qt5patchthing via kde
2023-03-13 16:18:54 <ncopa> yeah
2023-03-13 16:19:24 <ncopa> reminds me, i wonder if we can drop armv6 after alpine 3.18
2023-03-13 16:19:39 <psykose> i remember that proposal before too, you had a mailing list post right?
2023-03-13 16:19:44 <psykose> there were two issues with it
2023-03-13 16:20:08 <psykose> 1: was pmos phone support, a bunch of phones that were armhf only (even though hardware was armv7) for porting related reasons. not sure how it is today
2023-03-13 16:20:20 <psykose> 2: the rpi0 supported until like 2027 or some shit that is armhf
2023-03-13 16:20:28 <psykose> the latter i don't /really/ care about
2023-03-13 16:20:37 <psykose> well
2023-03-13 16:20:41 <psykose> they do still sell them and stuff
2023-03-13 16:21:16 <ncopa> yeah, i think rpi0 is main reason to keep armv6
2023-03-13 16:21:35 <psykose> this also reminds me of the x86 thing
2023-03-13 16:21:35 <ncopa> iirc pmos phones were mostly armv7
2023-03-13 16:21:38 <psykose> they are yeah
2023-03-13 16:21:49 <psykose> i don't know the stats now of what is still armv6
2023-03-13 16:22:09 <ncopa> rpi0 w 2 is armv7 iirc
2023-03-13 16:22:12 <psykose> Newbyte: maybe you remember ^
2023-03-13 16:22:29 <psykose> ncopa: no, rpi0 2w is armv8
2023-03-13 16:22:40 <ncopa> oh right, so its 64 bit?
2023-03-13 16:22:42 <psykose> yep
2023-03-13 16:22:48 <psykose> https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/
2023-03-13 16:22:51 <psykose> cortex a53
2023-03-13 16:22:52 <Newbyte> psykose: we have this ancient issue about it: https://gitlab.com/postmarketOS/pmaports/-/issues/599
2023-03-13 16:22:57 <psykose> Newbyte: ty!
2023-03-13 16:23:46 <psykose> https://www.raspberrypi.com/products/raspberry-pi-zero-w/ https://www.raspberrypi.com/products/raspberry-pi-zero/ these are the issue
2023-03-13 16:23:47 <Newbyte> it's a bit outdated though. for example samsung-n7100 has been renamed to samung-t03g and uses an armv7 kernel now
2023-03-13 16:23:49 <psykose> produced until 2026
2023-03-13 16:24:28 <Newbyte> but most of the devices on this list are either actually armv7 or aarch64. they were just ported back when Alpine only had armhf
2023-03-13 16:24:53 <psykose> the zero/zero-w use a ARM1176JZF-S cpu
2023-03-13 16:25:04 <psykose> which is our exact armhf target, armv6zk or whatever
2023-03-13 16:25:07 <Newbyte> so … I don't think there's anything other than the Pi 0 that is a real issue
2023-03-13 16:25:29 <psykose> Newbyte: yeah, i jhust mean all the maintainers of them /do/ have to flip some switches at least if they 'still are' armhf only in spec
2023-03-13 16:26:06 <Newbyte> actually there's one other use I can think of. someone was running Alpine on an armv6 iPod
2023-03-13 16:26:10 <Newbyte> and actively putting in work on that
2023-03-13 16:26:21 <psykose> the meme q3k post or something else
2023-03-13 16:26:26 <Newbyte> yes
2023-03-13 16:26:30 <Newbyte> I think
2023-03-13 16:26:36 <Newbyte> (that one)
2023-03-13 16:26:48 <psykose> i guess
2023-03-13 16:27:05 <psykose> but that's a consideration for even 15 years, even then someone will be 'putting linux on $randomdevicewithsomecpu'
2023-03-13 16:27:29 <ptrc> yup, especially that there's currently one madman porting some alpine bits to mips32
2023-03-13 16:27:35 <Newbyte> but all in all I don't think armhf is important for postmarketOS. the devices that haven't been switched over to armv7 or aarch64 are abandoned anyway
2023-03-13 16:27:42 <Newbyte> and none of the armhf devices supported in postmarketOS (sans the Pi 0) actually use an up-to-date kernel
2023-03-13 16:27:44 <psykose> ok, good to know
2023-03-13 16:27:54 <psykose> ncopa: should we have a tsc resolution?
2023-03-13 16:28:14 <ncopa> yes, i think so
2023-03-13 16:28:35 <psykose> i'll write up some blurb as a tsc issue just to note the points
2023-03-13 16:28:45 <ncopa> i dont know how much extra work armhf gives us nowadays
2023-03-13 16:29:02 <psykose> i don't think any of them are particularly much 'work' on average in themselves
2023-03-13 16:29:23 <psykose> it's more just each arch has a copy of packages, is a release, space on mirrors/wherever, sometimes holds up CI for someone for some reason
2023-03-13 16:29:34 <psykose> more just those less visible costs than 'fix on armhf' kinda stuff
2023-03-13 16:29:46 <psykose> most things just get marked broken if they don't build on armhf instead of time spent
2023-03-13 16:29:47 <skarnet> aiui the main problem with armv7 is having a decent architecture to build stuff on, porting isn't especially difficuly
2023-03-13 16:30:11 <skarnet> s/culy/cult/
2023-03-13 16:30:23 <skarnet> algitbot?
2023-03-13 16:30:29 <skarnet> s/difficuly/difficult/
2023-03-13 16:30:30 <psykose> algitbot: ping
2023-03-13 16:30:31 <psykose> hehe
2023-03-13 16:30:37 <Newbyte> I thought Alpine just uses aarch64 builders for armv7
2023-03-13 16:30:42 <psykose> we do yes
2023-03-13 16:30:45 <ncopa> we do
2023-03-13 16:30:54 <psykose> 32-bit personality kernel in a userspace of the arch
2023-03-13 16:30:55 <macmpi> armhf Pi devices are not EOF for a while
2023-03-13 16:31:06 <macmpi> *EOL
2023-03-13 16:31:08 <psykose> so the armhf build is the 'armhf minirootfs' as a container with a setarch entry
2023-03-13 16:31:11 <skarnet> that sounds voodoo to me, but if it works, I'm not complaining
2023-03-13 16:31:28 <psykose> it's like running 32-bit x86 binaries on your pc
2023-03-13 16:31:32 <psykose> but static ones, no multilib stuff
2023-03-13 16:31:37 <psykose> ah right you use windows nvm
2023-03-13 16:32:00 <skarnet> the same thing happens with windows, it's full of 32-bit x86 binaries
2023-03-13 16:32:03 <macmpi> "Raspberry Pi Zero W will remain in production until at least January 2026"
2023-03-13 16:32:04 <psykose> :)
2023-03-13 16:32:14 <Newbyte> what psykose really meant is that it's like WoW64
2023-03-13 16:32:31 <macmpi> https://www.raspberrypi.com/products/raspberry-pi-zero-w/
2023-03-13 16:32:33 <ncopa> question is how much effort we should put in to it for a single board
2023-03-13 16:32:45 <ncopa> has anyone tested if it actually works?
2023-03-13 16:32:46 <Newbyte> macmpi: do you care about the Pi 0?
2023-03-13 16:32:52 <psykose> pretty sure macmpi has a pi 0
2023-03-13 16:32:56 <Newbyte> hm I actually think I have a friend's Pi 0 laying around
2023-03-13 16:32:58 <macmpi> yes I do
2023-03-13 16:33:01 <psykose> lots of people have one
2023-03-13 16:33:20 <skarnet> and there are a lot of odroids and similar stuff around
2023-03-13 16:33:22 <psykose> in general it does not cost much time, i noted the invisible costs that apply to any arch
2023-03-13 16:33:23 <macmpi> it is a quite big seller (don't have the numbers though)
2023-03-13 16:33:37 <psykose> but for armv6 specifically, the architecture fucking sucks
2023-03-13 16:33:39 <Newbyte> skarnet: aren't ODROID boards armv7?
2023-03-13 16:33:45 <psykose> there are only more toolchain issues as time goes on in general
2023-03-13 16:33:52 <skarnet> oh right you're talking about armv6, my bad
2023-03-13 16:33:54 <Newbyte> or aarch64
2023-03-13 16:33:58 <ncopa> i guess if you have one of those boards, you will want run a lightweight distro
2023-03-13 16:33:58 <macmpi> typically good fit for alpine: low RAM, good for headless low-level application
2023-03-13 16:34:08 <psykose> random stuff i've disabled on armhf because of some niche bug in llvm output or the like only goes p
2023-03-13 16:34:10 <psykose> up*
2023-03-13 16:34:16 <psykose> and debugging any of that is a very big time sink
2023-03-13 16:34:17 <Newbyte> just use Gentoo and build everything on the Pi 0
2023-03-13 16:34:28 <ncopa> lol
2023-03-13 16:35:01 <psykose> and random software fixes seem to be not-really-upstream patches as nobody cares about the arch anymore :/
2023-03-13 16:35:09 <Newbyte> psykose: you don't get it, having mozjs on armhf is so important
2023-03-13 16:35:48 <macmpi> Sept 2016: Raspberry Pi passes 10m sales mark (https://www.bbc.com/news/technology-37305200)
2023-03-13 16:35:55 <skarnet> there's a rpi (not zero, but one of the first ones) in the list of machines I build my stuff on for testing. It is... rare that I wait for the rpi build to finish, if all the other arches build ok. >.>
2023-03-13 16:35:56 <ncopa> armv7 makes sense to keep for a while though
2023-03-13 16:36:44 <skarnet> Newbyte: and Steam and all the Electron apps, too!
2023-03-13 16:37:12 <Newbyte> fun fact: it wasn't until a few weeks ago that Google stopped shipping an armv7 userspace on aarch64 Chromebooks
2023-03-13 16:38:57 <Newbyte> ncopa: for what it's worth I personally still use armv7 devices on a regular basis
2023-03-13 16:41:26 <ikke> Looks like we have the arm builders back
2023-03-13 16:41:34 <Newbyte> wow, already?
2023-03-13 16:41:42 <ikke> Yeah
2023-03-13 16:47:28 <psykose> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/66
2023-03-13 16:47:35 <psykose> comment what you wish, ask others if you wish too
2023-03-13 16:47:43 <psykose> i wrote the pro/cons list based on what i know
2023-03-13 16:48:34 <psykose> ikke: good work!
2023-03-13 16:48:58 <Newbyte> psykose: actually I'm pretty sure they had Weston working on that 60 MB RAM iPod
2023-03-13 16:49:04 <psykose> they did
2023-03-13 16:49:12 <psykose> they played games on it and implemented some drm stuff
2023-03-13 16:49:25 <psykose> i picked the first weird link
2023-03-13 18:03:18 <macmpi> ikke: thanks. Seems still stuck on my side, and current gitlab MRs also report stuck state: is that due to backlog processing?
2023-03-13 18:05:36 <psykose> CI is still down
2023-03-13 18:09:07 <ikke> yeah, need to fix CI separately
2023-03-13 18:09:21 <psykose> don't forget the rust arg
2023-03-13 19:51:24 <umk3[m]> thank you psykose for the package :)
2023-03-13 19:51:29 <psykose> :)
2023-03-13 19:51:38 <umk3[m]> very kind
2023-03-14 11:02:16 <donoban> >>> Size difference for pdfjs: 16 MiB -> 4184 KiB :D
2023-03-14 11:04:59 <donoban> I wonder if it could be compressed/minified
2023-03-14 11:14:47 <PureTryOut> psykose: protected paths, interesting. Is there documentation for that somewhere?
2023-03-14 11:15:44 <psykose> can't find any
2023-03-14 11:19:11 <PureTryOut> Oh 😢
2023-03-14 11:19:17 <psykose> weirdly doesn't seem to actually work but does for the other case
2023-03-14 11:22:05 <psykose> confusion
2023-03-14 11:22:10 <psykose> it does work for the ca-certs
2023-03-14 15:48:16 <ovf> when lang manual pages are present (e.g. from fakeroot-doc), mandb tries to convert from its idea of possible single-byte national encoding to UTF-8//IGNORE, which is a glibcsm. that results in annoying `mandb: iconv_open ("UTF-8//IGNORE", "ISO-8859-1"): Invalid argument` lines every time man-db trigger fires
2023-03-14 15:49:15 <psykose> sounds like an issue for man-db upstream
2023-03-14 15:50:36 <psykose> although i'm not sure where the ignore comes from
2023-03-14 15:50:37 <psykose> hm
2023-03-14 15:51:04 <psykose> seems to just be "UTF-8"
2023-03-14 15:53:19 <psykose> and afaik musl only doesn't support //TRANSLIT so not sure why that specific call is wrong..
2023-03-14 15:53:35 <psykose> ah
2023-03-14 15:53:36 <psykose> found it
2023-03-14 15:53:54 <psykose> manconv.c has a last ? "UTF-8//IGNORE" : "UTF-8";
2023-03-14 15:56:26 <ovf> i'm fairly sure that none of the reencoding monkey business is ever required in the first place, but so far i can't see a convenient knob where man-db can be convinced to just leave the encoding alone
2023-03-14 15:57:35 <ovf> perhaps musl should just support //IGNORE?
2023-03-14 16:03:52 <psykose> doubt it
2023-03-14 16:04:17 <psykose> https://www.openwall.com/lists/musl/2017/08/26/2 is relevant here
2023-03-14 16:06:46 <psykose> i have a patch that ignores the errors if you want?
2023-03-14 16:06:47 <psykose> https://img.ayaya.dev/lXBjUgiCxuBB
2023-03-14 16:06:57 <psykose> the other alternative is indeed making it use gnu-libiconv but that doesn't really make sense
2023-03-14 16:07:01 <psykose> using this in the first place is quite useless
2023-03-14 16:07:54 <psykose> the final message in https://www.openwall.com/lists/musl/2017/08/26/3 is of most relevance, but without even 'misencoded author names' to test with idk if that has any meaning
2023-03-14 16:08:16 <psykose> do you mind just asking the man-db issue tracker, perhaps seeking a way to solve this that isn't "gnu-libiconv"?
2023-03-14 16:24:05 <orbea> there is always mandoc :P
2023-03-14 16:26:42 <ovf> nice find! see also somewhat relevant https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003089 , especially the `w3m -dump https://lintian.debian.org/tags/national-encoding | grep --count usr/share/man` line (debian packages that have non-utf8 manpages)
2023-03-14 16:27:17 <ovf> frankly man-db source code is a bit of a horrifying mess of endless repetitions. and all man pages on alpine should probably be utf8. :-)
2023-03-14 16:49:32 <psykose> i read a lot of manpages and haven't seen anything broken with mandoc, but..
2023-03-14 16:49:36 <psykose> i guess i never read translated ones
2023-03-14 16:50:06 <psykose> i do insist on reporting it though, maybe someone will have a rethink :-)
2023-03-14 16:50:10 <psykose> plenty of info to pass through
2023-03-14 16:52:17 <orbea> yea, always good to report bugs :)
2023-03-14 16:52:33 <orbea> epecially if the upstream might actually fix them
2023-03-14 16:58:34 <ovf> psykose: ok, i'll report it, but i also just switched to mandoc per orbea's suggestion which feels like a smaller amount of moving parts
2023-03-14 16:58:59 <psykose> that does work :)
2023-03-14 16:59:06 <psykose> tbh i thought you just had a reason to not use it :p
2023-03-14 16:59:18 <psykose> usually people know mandoc exists and intentionally go to man-db
2023-03-14 16:59:31 <orbea> yea, i use mandoc because its simple, it seems to work well per my experience and you can learn to write man pages using solely using their own documentation
2023-03-14 16:59:46 <orbea> grammar fail...
2023-03-14 17:00:47 <ovf> no, i completely forgot it existed and installed man-db out of habit. :-)
2023-03-14 17:39:57 <hjaekel> Hi, my merge request !44833 is waiting for a review, if anyone has time.
2023-03-14 19:14:40 <Saijin_Naib> <hjaekel> "Hi, my merge request !44833 is..." <- You madman, you did it! 
2023-03-14 19:21:36 <Newbyte> is this what people keep telling me to touch?
2023-03-14 19:23:24 <hjaekel> Saijin_Naib I was going to ask you for test support as soon as grass is available in testing. There are so many ways to use this software, I can only do some basic tests
2023-03-14 19:25:14 <Saijin_Naib> Newbyte: Underrated comment 
2023-03-14 19:25:59 <Saijin_Naib> hjaekel: I'll try to give it a go. I mostly use it via QGIS and OpenDroneMap so stand-alone isn't my strongest 
2023-03-14 19:29:06 <hjaekel> Then you have to bring OpenDroneMap to Alpine to test it :-)
2023-03-14 19:29:34 <Saijin_Naib> hjaekel: I'm trying, but I'm not up to the task 😭
2023-03-14 19:29:50 <hjaekel> QGIS is already on my harddisk, but many the unit tests fail currently
2023-03-14 19:30:42 <Saijin_Naib> We are based upon Ubuntu LTS and UbuntuGIS PPA, so ancient dependencies. Just doing the upgrades is non-trivial 
2023-03-14 19:31:14 <Saijin_Naib> hjaekel: That's the best news I've seen so far! Flatpak is cramping my style and breaking plug-ins 
2023-03-15 18:30:12 <hjaekel> I already asked yesterday, but maybe someone has time to do a review of !44833 today. I hope it's not because of my merge request that no one wants to do a review.
2023-03-15 18:32:35 <donoban> wow, it looks pretty big :D
2023-03-15 18:35:54 <hjaekel> yes, it's big, sorry for that. I had to move some things around so that they are at the correct place 
2023-03-15 18:36:23 <hjaekel> most things in package() are taken from the debian project
2023-03-15 18:38:58 <hjaekel> and I had to package a new font package so that images rendered by doxygen are properly rendered. The default font for doxygen is Helvetica
2023-03-15 18:41:44 <donoban> I feel it looks pretty good but someone with merge rights (psykose?) will need some time for carefully review
2023-03-15 18:44:50 <hjaekel> it's not a 5 minute review, psykose usually finds something in my MR that I can improve 😀
2023-03-15 18:45:45 <craftyguy> I'm trying to backport an update to nheko, and it depends on an updated version of coeurl. I added that to the branch, but it seems like CI is still installing the old version (despite successfully building the new version of it): https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/992066#L628
2023-03-15 18:46:05 <craftyguy> so I'm not sure what I'm missing here...
2023-03-15 18:46:45 <psykose> because you missed the third dependency in the middle of mtxclient which also uses it
2023-03-15 18:46:50 <psykose> so mtxclient-dev is linked to the old one
2023-03-15 18:46:59 <psykose> all 3 update at once generally
2023-03-15 18:47:39 <craftyguy> ahhhh, ok. I don't have a lot of experience updating these
2023-03-15 18:47:50 <craftyguy> thanks :)
2023-03-15 18:55:18 <hjaekel> psykose would it be possible for you to set aside some time in the next few days to look at the MR for grass? I know it's complex...
2023-03-15 18:55:44 <psykose> fonts start with font-
2023-03-15 18:55:45 <psykose> :D
2023-03-15 18:56:34 <hjaekel> haha, thank you, I will change that
2023-03-15 18:56:48 <hjaekel> but this package contains 35 fonts, not only one
2023-03-15 18:57:21 <psykose> the optipng could either be skipped, or be pngquant instead (which isn't lossless but generally you don't notice for these kinds of images, and much faster)
2023-03-15 18:57:59 <psykose> it should probably be enabled on just x86_64/aarch64 as it's kinda useless elsewhere
2023-03-15 18:58:24 <psykose> +usr/lib/grass82/locale/ can be -lang
2023-03-15 18:59:30 <psykose> it's a bunch of fonts yeah, but that doesn't matter that much unless you want to make a subpackage for each one
2023-03-15 19:00:38 <hjaekel> no, I don't want a subpackage. I just rename the package to font-
2023-03-15 19:01:00 <psykose> you can also do uh
2023-03-15 19:01:03 <psykose> instead of find -exec
2023-03-15 19:01:24 <psykose> find -print0 | xargs -0 -n 1 -P ${JOBS:-2}
2023-03-15 19:02:05 <psykose> if that's even correct, i just typed it from memory
2023-03-15 19:02:11 <psykose> parallel exec
2023-03-15 19:03:20 <hjaekel> you mean for the optipng/pngquant stuff? I will try it
2023-03-15 19:04:04 <psykose> yeah
2023-03-15 19:04:18 <psykose> it doesn't matter for things that take 1 second, but if something takes 5 minutes it's nice
2023-03-15 19:09:40 <psykose> nitpicks nitpicked successfully
2023-03-15 19:13:28 <hjaekel> thank you , now I have work to do 😀
2023-03-16 00:24:51 <Saijin_Naib[m]> <hjaekel> "thank you , now I have work to..." <- Do you know when you might have an APK built for me to test against?
2023-03-16 00:24:51 <Saijin_Naib[m]>  
2023-03-16 00:24:51 <Saijin_Naib[m]> I have no machines on Edge, but I'm hoping I can just sideload it and get lucky
2023-03-16 12:56:03 <psykose> you won't be able to side install that one
2023-03-16 13:47:39 <wener> is there any url I can curl to get latest version ?
2023-03-16 13:48:14 <ikke> curl https://alpinelinux.org/releases.json
2023-03-16 13:48:29 <ikke> it's json, so not just curl expecting plain-text
2023-03-16 13:48:36 <wener> thanks
2023-03-16 14:30:28 <ncopa> re sudo version 1.9.5p2 vs 1.9.5_p2, I wonder if we should let abuild warn on [0-9]p[0-9]
2023-03-16 14:31:52 <ikke> as part of sanitycheck?
2023-03-16 14:38:28 <ncopa> yes https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/188
2023-03-16 14:39:16 <psykose> it would be nice if abuild accepted anything that apk did and didn't do any further checking
2023-03-16 14:39:33 <psykose> except for things that are wrong of course, but this isn't really one
2023-03-16 15:22:23 <psykose> ncopa: would you be open to adding some more logic into stripbin, to allow something like stripcmd=${STRIP} as a fallback
2023-03-16 15:22:38 <psykose> i would do it but there are already 10 layers of logic there for various CHOST-strip's
2023-03-16 15:24:23 <psykose> context is that binutils strip is broken on riscv64 for ld.lld output
2023-03-16 15:24:43 <psykose> so sometimes it would be useful to just pass llvm-strip to it, but there isn't a way to do it that i can see
2023-03-16 15:30:18 <psykose> i should probably also report it to binutils but that requires "emailing an administrator" for a "bugzilla account" to then make the thousandth binutils bug that just gets ignored so
2023-03-16 15:43:41 <ncopa> wouldnt it be better to fix binutils' strip?
2023-03-16 15:44:18 <ncopa> <@psykose> it would be nice if abuild accepted anything that apk did and didn't do any further checking
2023-03-16 15:44:42 <ncopa> that is what we currently do, but unfortunately it has led to inconsistency in the sudo case
2023-03-16 15:44:43 <psykose> it would be better to 'fix binutils strip' but that would take years and i don't know how to do it
2023-03-16 15:45:03 <psykose> being able to pass an explicit strip is useful regardless because llvm-strip is a cross-strip in general and always works for any target
2023-03-16 15:45:43 <psykose> the sudo inconsistency is because we toggled back and forth, no? if we never changed it in either case it would've been ok
2023-03-16 15:45:51 <psykose> i guess then your point is to warn on one to force consistent
2023-03-16 15:45:52 <psykose> that's ok
2023-03-16 15:46:06 <psykose> i just think it's fine to accept non-_, you just have to stay on it
2023-03-16 15:46:37 <ncopa> problem is that contributors does not check the history apparently
2023-03-16 15:46:42 <ncopa> or does not agree with the history
2023-03-16 15:47:23 <ncopa> i guess being able to override strip is a generally good thing.
2023-03-16 15:47:31 <ncopa> i would like to have tests for it though
2023-03-16 15:51:24 <psykose> it is indeed untested what it already uses depending on the archspec and the like
2023-03-16 15:52:51 <psykose> the strip override would also allow some fun improvements
2023-03-16 15:53:59 <psykose> e.g. in xen we have !strip and manually strip the bins, to exclude usr/share, and afaict that is only because those are non-native binaries
2023-03-16 15:54:31 <psykose> if you do strip=llvm-strip though it doesn't crash on them. whether that's wanted or not is separate (maybe they just shouldn't be stripped at all), but not needing to add manual scanelf's is sometimes neat
2023-03-16 16:14:50 <psykose> sam_: do you mind making a binutils issue actually
2023-03-16 16:14:51 <psykose> https://img.ayaya.dev/ySYwShluFbmR
2023-03-16 16:15:30 <psykose> ah and it's llvm 15.0.7 for reference
2023-03-16 16:16:13 <ncopa> would be good to report the issue to upstream binutils, yes
2023-03-16 16:17:05 <psykose> there is also an llvmgold bug paired with clang -flto -fuse-ld=bfd on 32-bit arm which is easy to reproduce
2023-03-16 16:17:18 <psykose> that one idk who's fault it is but that whole thing is a mess
2023-03-16 18:44:18 <sam_> psykose: sure
2023-03-16 18:44:23 <sam_> lemme read backlog
2023-03-16 18:44:41 <psykose> it's just that url
2023-03-16 18:44:51 <psykose> binutils strip be bad at lld output
2023-03-16 18:44:56 <psykose> and only riscv64
2023-03-16 18:55:46 <ikke> FYI, arm CI should be back
2023-03-16 18:58:05 <psykose> java still broken on arm tho for apache-ant
2023-03-16 18:59:01 <ikke> We do need that environment variable
2023-03-16 18:59:18 <psykose> does it fix it? it was still broken
2023-03-16 18:59:28 <psykose> unless the still broken part was uhh the firewall
2023-03-16 18:59:43 <ikke> There was still one domain that did not work, need to verify it
2023-03-16 18:59:44 <psykose> guess you have to put it in ~/.abuild
2023-03-16 19:00:04 <ikke> would also need something for CI
2023-03-16 19:01:36 <psykose> yep
2023-03-16 19:06:37 <ikke> With the correct option, the build even mentions it
2023-03-16 19:06:43 <ikke> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv6Addresses=true
2023-03-16 19:08:04 <psykose> :)
2023-03-16 19:15:20 <ikke> it's building waiting to so if it fails to download something
2023-03-16 19:15:26 <ikke> the repo1.maven.org stuff works fine
2023-03-16 19:18:21 <psykose> iirc you said 6->4 works right
2023-03-16 19:18:25 <psykose> so ipv4 only hosts will be ok
2023-03-16 19:18:35 <ikke> yes
2023-03-16 19:18:42 <ikke> as long as it tries to connect to ipv6
2023-03-16 19:21:41 <sam_> filed https://sourceware.org/bugzilla/show_bug.cgi?id=30237
2023-03-16 19:21:44 <sam_> tell me if i should shove more in it
2023-03-16 19:25:09 <ikke> psykose: https://netrexx.org/files/NetRexxC-2.05.jar is failing
2023-03-16 19:26:10 <psykose> ikke: is it because it has AAAA that is down..
2023-03-16 19:26:16 <ikke> yes
2023-03-16 19:26:54 <ikke> curl -s6 -fail https://netrexx.org/files/NetRexxC-2.05.jar -o /dev/null 
2023-03-16 19:27:15 <psykose> well
2023-03-16 19:27:21 <psykose> i can tell you there's gonna be quite a few hosts like that
2023-03-16 19:28:05 <psykose> sam_: looks good, i don't know what other info would be wanted
2023-03-16 19:28:26 <psykose> if they want llvm stuff version it's 15.0.7, if you think there's anything useful (you would know more), let me know
2023-03-16 19:32:44 <ikke> psykose: this is the situation right now
2023-03-16 19:35:53 <psykose> yeah
2023-03-16 19:36:39 <ikke> I mean, I did try to setup a tunnel to provide ipv4
2023-03-16 19:36:53 <ikke> It's just not working yet
2023-03-16 19:42:52 <ikke> Oh, maybe it is working
2023-03-16 19:43:05 <ikke> oh, right, it was not working in the containers yet
2023-03-16 21:10:43 <elibrokeit> sort of sad that I have to talk people down from using GNU coreutils-isms: https://github.com/mesonbuild/meson/issues/11533
2023-03-16 21:11:46 <elibrokeit> I didn't even know `env -S 'PATH=foobar:${PATH}' myprog` was a thing, now I'm terrified... and this was being used as an alternative to just sourcing a script, amazing.
2023-03-16 21:12:42 <psykose> i'm confused why it even differentiates the two
2023-03-16 21:14:01 <elibrokeit> env -S'foo --bar' is supposed to *split* strings
2023-03-16 21:14:18 <elibrokeit> for use in shebangs because #!/usr/bin/env python -B
2023-03-16 21:14:25 <Habbie> the env manpage doesn't even mention expansion
2023-03-16 21:14:27 <elibrokeit> which linux turns into /usr/bin/env "python -B"
2023-03-16 21:14:42 <psykose> >Because of that, meson devenv is only useful for hacking on projects inside your terminal.
2023-03-16 21:14:45 <psykose> uhh.. yeah..
2023-03-16 21:14:47 <Habbie> lol
2023-03-16 21:14:53 <elibrokeit> -S is non-portable to begin with, simply do not use it...
2023-03-16 21:14:56 <psykose> kind of.. in the name..
2023-03-16 21:15:25 <ikke> psykose: https://tpaste.us/BJko 
2023-03-16 21:15:59 <elibrokeit> but also iterating over a list of lines in a shell script, filtering out the lines that are just assignments, and passing it as arguments to env -S because magic re-evaluation of envvars??? what and why
2023-03-16 21:16:45 <elibrokeit> anyways, gnome-builder no longer tries to do stuff that flat-out fails on alpine with busybox `env`
2023-03-16 21:16:50 <elibrokeit> :)
2023-03-16 21:17:38 <Habbie> nice :)
2023-03-16 21:19:20 <psykose> last time this happened someone had the idea to install coreutils by default
2023-03-16 21:20:43 <psykose> ikke: that's just a 404
2023-03-16 21:20:44 <psykose> hm
2023-03-16 21:21:04 <ikke> yeah, the rest succeeds
2023-03-16 21:26:37 <elibrokeit> installing coreutils by default would rather seem to miss the point of providing it at all
2023-03-16 21:26:47 <elibrokeit> err, providing busybox at all
2023-03-16 21:27:15 <ikke> yea
2023-03-16 21:28:05 <elibrokeit> (there are many distros that make that decision already, if that's desirable)
2023-03-16 21:30:00 <psykose> if only everyone thought what you think
2023-03-16 21:30:24 <psykose> it is by far the most frustrating part of being a distro developer
2023-03-16 21:30:53 <psykose> x distro does it already, something something, just add everything to base
2023-03-16 21:31:06 <Habbie> why do you even have things separated in packages
2023-03-16 21:31:08 <psykose> my brother in christ there's a hundred distros just use what you want
2023-03-16 21:31:08 <Habbie> think about it
2023-03-16 21:31:10 <Habbie> :)
2023-03-16 21:31:28 <Habbie> *breathes in*
2023-03-16 21:31:30 <Habbie> my child
2023-03-16 21:31:34 <psykose> :)
2023-03-16 21:34:42 <skarnet> also I want Alpine to have glibc because all the other distros have it so why is Alpine such a snowflake
2023-03-16 21:34:45 <skarnet> and systemd too
2023-03-16 21:35:31 <elibrokeit> 
ACTION chooses to use something other than alpine for *exactly* those reasons

2023-03-16 21:41:03 <handlerug> I just installed alpine linux and "snap install fortnite" says something is not found. how do I get a refund
2023-03-16 21:41:29 <ikke> 
ACTION hands handlerug a refund

2023-03-16 21:44:03 <Ermine> I just run alpine linux from usb drive and it shows white letters on a black screen. I expected desktop to pop up. Such a broken distro
2023-03-16 21:44:05 <elibrokeit> 
ACTION hands handlerug to a reef, under it

2023-03-16 21:45:21 <elibrokeit> Ermine: oh no! Which words did it say instead of `desktop`?
2023-03-16 21:48:22 <Ermine> elibrokeit: Welcome to Alpine Linux <some letters and digits> (edge)
2023-03-16 21:48:51 <elibrokeit> wow, that sucks
2023-03-16 21:48:56 <Ermine> Yeah
2023-03-16 21:49:01 <psykose> edge usb? wtf that is illegal
2023-03-16 21:49:05 <psykose> the police are dispatched
2023-03-16 21:49:06 <elibrokeit> 
ACTION sends patch to switch it to "Welcome to desktop (edge)"

2023-03-16 21:50:26 <Ermine> psykose: I have a usb with alpine-conf master (outdated though)
2023-03-16 21:50:36 <psykose> not very master is it
2023-03-16 21:51:05 <Ermine> Indeed XD
2023-03-16 21:52:05 <lucidiot> where's the alpine-all iso with every package installed
2023-03-16 21:52:28 <psykose> ikke: also that old 404 https://img.ayaya.dev/WddAfPteziHi (curl this don't open it in browser)
2023-03-16 21:52:30 <psykose> nice padding :D
2023-03-16 21:52:47 <psykose> i like how people expand their http 404's by 70% in size with nothing these days
2023-03-16 21:53:00 <ikke> haha
2023-03-16 21:53:09 <ikke> <!-- a padding to disable MSIE and Chrome friendly error page -->
2023-03-16 21:53:17 <psykose> :D
2023-03-16 21:53:20 <handlerug> pretty sure it's just the default
2023-03-16 21:53:27 <handlerug> hm, apparently no
2023-03-16 21:53:35 <lucidiot> "how dare you be friendly"
2023-03-16 21:53:45 <elibrokeit> how does that even disable chrome whatever
2023-03-16 21:54:12 <abby> breaks their html-parsing regex?
2023-03-16 21:54:15 <psykose> i assume they had some check that if you get a 404 under a certain size they display their own error
2023-03-16 21:54:22 <psykose> instead of the backend error
2023-03-16 21:54:22 <elibrokeit> ... why
2023-03-16 21:54:23 <handlerug> chrome displays its own "network error"-style 404 page when the response is of zero size
2023-03-16 21:54:23 <ikke> yeah, I recall that
2023-03-16 21:54:32 <ikke> I think ie started that
2023-03-16 21:54:35 <psykose> so you get 'failed to connect' instead of the nginx error
2023-03-16 21:54:36 <elibrokeit> but if it's not zero-size....
2023-03-16 21:54:43 <lucidiot> probably allows it to distinguish between default errors like just '404 Not Found' as text/plain and customized errors full of CSS and JS
2023-03-16 21:54:46 <handlerug> psykose: nah it actually says "not found" I think
2023-03-16 21:54:49 <psykose> :)
2023-03-16 21:54:56 <psykose> idk what it says to be clear
2023-03-16 21:54:58 <psykose> just guessing
2023-03-16 21:55:10 <lucidiot> what does it say when you return HTTP 666
2023-03-16 21:55:19 <elibrokeit> why doesn't chrome grep for javascript tags then
2023-03-16 21:57:55 <elibrokeit> can we disable chrome's attempted helpfulness with <script>alert("404 not found");</script>
2023-03-16 21:58:03 <psykose> :)
2023-03-16 21:58:09 <elibrokeit> "it's a customized error full of js"
2023-03-16 21:58:21 <lucidiot> reimplement the dinosaur game
2023-03-16 22:00:32 <bl4ckb0ne> how will alpine survive the end of docker
2023-03-16 22:00:43 <bl4ckb0ne> things are looking bad folks
2023-03-16 22:00:48 <psykose> i already got fired
2023-03-16 22:01:17 <bl4ckb0ne> im surprised you got hired tbh
2023-03-16 22:02:22 <psykose> true
2023-03-16 22:02:46 <psykose> should've fallen off a bridge instead
2023-03-16 22:03:01 <bl4ckb0ne> they should've fire you sooner anyway
2023-03-16 22:03:36 <bl4ckb0ne> like when you broke my ci pipeline with ncurses 
2023-03-16 22:05:15 <lucidiot> are you saying alpine is cursed?
2023-03-16 22:05:36 <Ermine> Without psykose it would be doomed
2023-03-16 22:06:35 <handlerug> I actually really hope psykose is compensated for alpine work
2023-03-16 22:06:51 <handlerug> like this is probably true but I'm still thinking about this sometimes
2023-03-16 22:07:27 <bl4ckb0ne> 
ACTION gives compensation to psykose 

2023-03-16 22:54:27 <Hello71> btw the proper gnu way to substitute variable references is envsubst, which is in gettext for the same reason that cal and column are in util-linux and mkpasswd is in whois
2023-03-16 22:59:09 <psykose> mkpasswd in whois seems like some sort of hilarious joke
2023-03-16 22:59:18 <psykose> there's also a mkpasswd in.. expect?
2023-03-16 22:59:24 <psykose> handlerug: i'm not
2023-03-16 22:59:31 <abby> that's unexpected
2023-03-16 22:59:33 <handlerug> D:
2023-03-17 03:17:20 <elibrokeit> > We don't officially support Alpine as it is as we use coroutines with ucontext_t unsupported on MUSL.
2023-03-17 03:17:30 <elibrokeit> funny... gnome-builder seems to be there okay...
2023-03-17 03:18:15 <elibrokeit> oh and in relation to #musl, there we have all-caps :D
2023-03-17 03:21:35 <psykose> there is no ucontext_t in the gnome-builder codebase
2023-03-17 03:21:41 <psykose> like at all
2023-03-17 03:21:50 <psykose> libucontext also exists
2023-03-17 14:04:47 <valerius> lol, mention of coroutines... triggers my PTSD
2023-03-19 02:50:24 <DavidHeidelberg[m]> Hey fellow humans. Figured out Alpine 3.17+ container freezing; it was ccache 4.7, probably inode caching doesn't work well inside GitLab runner
2023-03-19 02:50:46 <DavidHeidelberg[m]> currently reproducible on Debian and Fedora with 4.7.x ccache...
2023-03-19 03:01:32 <psykose> :)
2023-03-19 03:02:20 <psykose> well it's easy to disable i guess
2023-03-19 03:02:44 <psykose> does it still freeze on 4.8?
2023-03-19 03:16:27 <DavidHeidelberg[m]> psykose: no idea, I'm doing currently debian bullseye -> bookworm migration, so after I finish it, I'm going to give a alpine spin
2023-03-19 03:17:18 <DavidHeidelberg[m]> I was pretty sad to stay with Alpine 3.16 in CI because of it.
2023-03-19 03:17:32 <DavidHeidelberg[m]>  * I was pretty sad to stay on old Alpine 3.16 in CI because of it.
2023-03-19 10:02:35 <Newbyte> Why did raspberrypi-userland-udev get pulled in when I installed udev 🤔
2023-03-19 10:02:38 <Newbyte> s/udev/tmux/
2023-03-19 10:11:11 <ptrc> Newbyte: on what architecture?
2023-03-19 10:11:23 <Newbyte> ptrc: armv7 and aarch6
2023-03-19 10:11:25 <Newbyte> s/aarch6/aarch64/
2023-03-19 10:12:28 <ptrc> can't reproduce in a container 
2023-03-19 10:13:04 <ptrc> ah
2023-03-19 10:13:10 <ptrc> raspberrypi-userland-udev-0.20220616-r0 has auto-install rule:
2023-03-19 10:13:10 <ptrc> eudev
2023-03-19 10:13:50 <ptrc> i don't think it was related to tmux though, its dependencies are quite concise
2023-03-19 10:14:10 <Newbyte> yeah, I think it just was because I hadn't updated for a while
2023-03-19 10:14:30 <Newbyte> I would think the same would've happened if I did apk upgrade
2023-03-20 01:48:28 <psykose> the amount of relative symlinks i have fucked up really makes me wish ln -r was a thing in busybox
2023-03-20 01:54:36 <somercet1> I remember there was an small app, symlinks by, that turned absolute symlinks into relative. Ah, here: https://github.com/brandt/symlinks
2023-03-20 01:57:43 <psykose> i know there's a million solutions and various coreutils that have ln -r
2023-03-20 01:57:50 <psykose> can't rely on any of those for writing scripts however
2023-03-20 01:58:14 <psykose> 'in busybox' would at least mean i could do ln -r in apkbuild's :p
2023-03-20 01:58:22 <somercet1> ah
2023-03-20 07:55:11 <maribu> I just dropped a high impact MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/45251
2023-03-20 07:57:25 <maribu> The problem I try to solve is that when python3 is updated to a new major version (e.g. 3.10.x to 3.11.y) all python modules are broken until the builders have completed rebuilding them all, which in the most recent instance meant I was waiting for 2 days to have my setup working again. The idea is to add a dependency to `python3>=3.11.0 python3<3.12.0` this time to avoid updating python3 until all installed modules are rebuild.
2023-03-20 07:58:26 <maribu> The MR only adds the deps to main/py3-* packages. If that approach is agreed upon, the same could be done for the other repos.
2023-03-20 08:00:35 <psykose> please no
2023-03-20 08:01:07 <maribu> Note: I opted to invoke python3 to print the version currently installed, rather than hardcoding it. Ideally, the line added needs to never be touched again. Hardcoding the dependency would certainly also work and a simple sed or awk snipped would be able to update the hardcoded dependency for all pkgs. But I personally favor doing a bit more work upfront that having to remember running an sed script on every python3 update
2023-03-20 08:01:32 <maribu> psykose: What is that you dislike with the approach?
2023-03-20 08:03:00 <abby> o.o that's certainly a way to do it
2023-03-20 08:05:03 <psykose> for a start you only need python3~{sys.version_info.major}.{sys.version_info.minor}
2023-03-20 08:05:17 <psykose> for another you put the dependency in the wrong subpackage in places :p
2023-03-20 08:05:25 <psykose> for the actual reason it should be in abuild and automatic
2023-03-20 08:07:35 <maribu> That was exactly what I proposed a few months ago. But the feedback was adding python3 specific features is a no-go.
2023-03-20 08:08:33 <maribu> But yeah, adding this to every APKBUILD will be a game of whack a mole with new py3-* packages popping up all the time, while adding it to abuild would fix the issue once and for all.
2023-03-20 08:09:38 <psykose> not quite, someone had an issue for it for a while https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10029
2023-03-20 08:10:52 <abby> on void we freeze the repos when doing a python3.x bump, so there's never a state like this
2023-03-20 08:10:57 <psykose> would probably just be an additional scan_python_something function that gets called in one place
2023-03-20 08:11:05 <psykose> yeah a repo freeze also solves this and is 10x easier
2023-03-20 08:11:09 <psykose> and i thought of that a million years ago
2023-03-20 08:11:19 <psykose> it's useful for like 10 other reasons too
2023-03-20 08:11:33 <psykose> but nobody really cared and i can't do it myself and i'm not one to repeat the same thing in a loop 800 times
2023-03-20 08:11:53 <psykose> only a few people can 'freeze the repos'
2023-03-20 08:12:12 <maribu> Write a bot that asks for that feature. Start with a weekly interval to nag, then slowly increase frequency ;)
2023-03-20 08:12:58 <psykose> that scan_whatever seems quite easy to make in this case, since it just detects /usr/lib/python3.X
2023-03-20 08:13:09 <psykose> and adds a dep on python3~3.X
2023-03-20 08:14:24 <maribu> Do want to look into that? Otherwise I will take a look. I keep the other MR open, at least as argument for why adding a python3 specific hook to abuild this would serve well.
2023-03-20 08:15:58 <psykose> i know where to add it but idk how to write tests for that
2023-03-20 09:21:16 <maribu> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/189 provides the scan hook for python3 site-packages
2023-03-20 09:46:25 <ikke> maribu: should include tests as well as psykose mentioned 
2023-03-20 10:07:10 <maribu> Will do. After lunch, though :)
2023-03-20 10:58:02 <maribu> ikke: Done
2023-03-20 13:14:37 <pogduhog> Has anyone had any success booting rk3399 boards? I have a stripped down kernel config and openwrt patches working but I can't for the life of me get lts or edge kernels to work even with tweaks
2023-03-20 13:15:34 <pogduhog> The issue is that nlplug-findfs doesn't find the mmc disk so it times out
2023-03-20 13:50:35 <Newbyte> pogduhog: We support several rk3399 devices in postmarketOS (Alpine-based distribution). However, we have our own "rockchip" kernel rather than Alpine Edge.
2023-03-20 14:05:15 <pogduhog> @Newbyte good to know, I will take a look. I would be interested in getting 'stock' lts or edge working as they are almost there, it is just the mmc issue that needs resolving at this point and I don't believe any patches are actually needed 
2023-03-20 14:07:31 <pogduhog> I will try with my config and no patches later, if that works it must be a config issue but I can't seem to nail it down 
2023-03-20 14:08:12 <Newbyte> pogduhog: would be great if you could do that. if so, we could offer it as an option as well on such devices.
2023-03-20 14:08:18 <pogduhog> MMC on the rk3399 boards are a mess in all honesty
2023-03-20 14:09:59 <pogduhog> Another issue with stock alpine is the nlplug-findfs script times out too quickly. On my build I have recompiled it to allow for a longer wait, the USB_DELAY option did not work in this situation
2023-03-20 14:11:30 <pogduhog> So in short with an option to increase the wait in nlplug-findfs and the correct config we should be able to boot all the rk3399 devices out the box. Again I will test with no patches later, I don't think any are strictly necessary to boot
2023-03-20 16:45:11 <psykose> maribu: that looks perfect, great work
2023-03-20 16:45:39 <maribu> Thx :)
2023-03-20 16:49:23 <psykose> :)
2023-03-20 16:49:31 <psykose> Newbyte: everything is 44.0 now, clear or more testing
2023-03-20 16:51:23 <Newbyte> psykose: I asked someone to test it on his aarch64 laptop and it works fine for him. I should probably test it on a phone just to make sure there's no weird interactions with Phosh before we merge though.
2023-03-20 16:51:35 <Newbyte> … so I'll do just that
2023-03-20 19:10:07 <mio> psykose: so fast! thanks :)
2023-03-20 19:12:28 <mio> also for the earlier version bumps, thanks for all that you and the rest of the team do to keep the CI and packages going smoothly
2023-03-20 19:13:37 <psykose> miyopan is a cute sounding name
2023-03-20 19:15:59 <mio> :)
2023-03-20 19:16:16 <psykose> :3
2023-03-20 19:17:24 <mio> thanks <3
2023-03-20 20:23:18 <Newbyte> How do I downgrade a specific package to what's available in the repositories? I know about upgrade -a, but I don't know how to convince it to downgrade a specific package
2023-03-20 20:23:47 <ikke> apk add package=<version>
2023-03-20 20:24:10 <ikke> Not sure if it works with downgrades, but apk add -u <package> can be used to upgrade a single package
2023-03-20 20:24:11 <Newbyte> That worked, thanks
2023-03-20 20:24:18 <psykose> apk add xdg-desktop-portal-gnome\<44
2023-03-20 20:24:23 <ikke> note that the pinning is kept
2023-03-20 20:24:31 <ikke> so it will not automatically upgrade
2023-03-20 20:24:35 <Newbyte> psykose: is the backslash meant to be there?
2023-03-20 20:24:39 <ikke> yes
2023-03-20 20:24:44 <psykose> yes otherwise it's a shell redirection
2023-03-20 20:24:45 <ikke> you don't want to pipe in fd 44
2023-03-20 20:24:49 <psykose> alternatively quote it
2023-03-20 20:24:51 <Newbyte> oh, that makes sense
2023-03-20 20:32:00 <Hello71> ikke: that's <&44, <44 is just reading from a file called 44
2023-03-20 20:32:09 <ikke> oh right
2023-03-20 20:52:13 <psykose> DavidHeidelberg[m]: ccache 4.7.5 disables inode by default so now you don't even need the workaround for 3.17
2023-03-20 20:53:17 <DavidHeidelberg[m]> psykose: yup, I proposed this solution to a maintainer when wr been discussing issue
2023-03-20 20:53:23 <DavidHeidelberg[m]> :)
2023-03-20 20:53:23 <psykose> ye
2023-03-20 20:53:29 <psykose> upgraded for you already, enjoy
2023-03-20 20:53:37 <DavidHeidelberg[m]> But thank you think about me :P
2023-03-20 20:56:40 <DavidHeidelberg[m]> *thank you for pinging me
2023-03-20 20:57:05 <DavidHeidelberg[m]> is it mirrored? I would try to uprev container tonight
2023-03-20 21:00:24 <psykose> already in dl-cdn yeah
2023-03-20 21:04:23 <DavidHeidelberg[m]> nice
2023-03-20 22:18:18 <ovf> when is subpackages=...::noarch needed? i see it's not generally used for -doc -lang
2023-03-20 22:25:51 <psykose> default_doc/lang sets it already
2023-03-20 22:26:02 <psykose> hm or does it
2023-03-20 22:26:44 <psykose> guess not
2023-03-20 22:26:48 <psykose> but it doesn't really do anything
2023-03-20 22:27:10 <psykose> there's no noarch packaging and it's mostly habit
2023-03-20 22:28:09 <ovf> why isn't there? :-)
2023-03-20 22:28:44 <ovf> also, looks like abuild.conf isn't documented anywhere? e.g. REPODEST
2023-03-20 22:49:24 <ovf> anyway, will http://0x0.st/H-lc.3.patch fly for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28871 ? (i don't really care for warzone2100, but i noticed it was ancient)
2023-03-20 22:52:12 <ovf> sorry, the other thing got in there probably due to my experiments with abump. http://0x0.st/H-lm.3.patch
2023-03-20 23:07:23 <psykose> probably
2023-03-20 23:07:31 <psykose> there isn't because no one made it, dunno
2023-03-20 23:07:42 <psykose> it's somewhat weird to set up a repo to handle noarch correctly
2023-03-20 23:07:50 <psykose> (apks shared for every arch)
2023-03-20 23:08:08 <psykose> on top of the issue of 'which builder builds the noarch and uploads it'
2023-03-20 23:13:40 <Hello71> all of them, something something reproducible builds
2023-03-20 23:55:34 <ovf> psykose: thanks! do you really prefer the gitlab mr workflow to patch-over-{irc,email}? this whole pr/mr business still feels extremely weird to me, 15 years into github's existence -- why do i need to host my private repo somewhere just to submit a patch...
2023-03-21 00:09:15 <psykose> it's more convenient for me as both the person reviewing it and writing it
2023-03-21 00:09:23 <psykose> but i'm ok with curl | git am too i guess
2023-03-21 00:09:43 <psykose> mostly because i'm ok with fixing anything i want to change myself
2023-03-21 00:09:50 <psykose> actual git email review i just avoid and never use
2023-03-21 00:22:25 <ovf> i see. sourcehut must have gotten it right then? i think i can git-send a patch into it, and then you can do the clicky-clicky in the ui. conversely it also supports curl | git am
2023-03-21 00:23:17 <ovf> er, s/git-send/&-email/
2023-03-21 00:23:31 <psykose> haven't checked in a while
2023-03-21 05:49:55 <psykose> Newbyte: fyi in mutter https://gitlab.gnome.org/GNOME/mutter/-/commit/0e8aaebc00f18a642c9058c00f5ea6f52cd2b385 is new in gnome-44 and makes mutter exit when xwayland crashes
2023-03-21 05:49:56 <psykose> :  )
2023-03-21 05:50:36 <psykose> META_X11_DISPLAY_POLICY_MANDATORY is only set for non-systemd as well, since this old thing https://gitlab.gnome.org/GNOME/mutter/-/commit/9b25248c96129641ba2b1b0b64c21a1dc41e38ae
2023-03-21 05:50:50 <psykose> so basically on !systemd xwayland failing causes an exit of mutter
2023-03-21 05:50:50 <psykose> fun
2023-03-21 06:51:17 <Newbyte> <psykose> "so basically on !systemd..." <- Is there an issue about this? Looking at the code it looks like a deliberate change, but still
2023-03-21 06:51:37 <psykose> someone will prolly make one
2023-03-21 06:51:52 <psykose> it's not deliberate in a bad way, just unfortunate
2023-03-21 06:52:04 <psykose> just in case people report something crashed and the whole thing exited you can probably know it's that
2023-03-21 11:28:52 <robertmader[m]> z3ntu: hi! I shortly wanted to make you aware of an issue with the libcamera package that just got fixed in a bunch of other distros (debian, arch, fedora). Are you around? (and can people read this?)
2023-03-21 11:31:09 <robertmader[m]> In short it's about these commits: https://salsa.debian.org/multimedia-team/libcamera/-/commit/7871e6737d82e76942aaa3b6f56a2f03f28b1d91 / https://github.com/archlinux/svntogit-packages/commit/9b0cb2833e62cb4e8f2bfec703649a9fb10b6cd8
2023-03-21 11:32:30 <ikke> robertmader[m]: we can certainly read this
2023-03-21 11:32:47 <robertmader[m]> libcamera does a rather odd thing and requires signing of certain .so files. Most distros, however, strip parts of the binary, making the signature invalid and requiring resigning. I don't see something like that in https://git.alpinelinux.org/aports/tree/community/libcamera/APKBUILD yet
2023-03-21 11:33:34 <psykose> guess i'll fix it
2023-03-21 11:33:37 <robertmader[m]> End of story is that the pipewire libcamera plugin usually won't work then.
2023-03-21 11:34:46 <z3ntu> psykose: thanks!
2023-03-21 11:34:51 <z3ntu> robert.mader: and thanks for letting us know!
2023-03-21 11:34:52 <robertmader[m]> The combi of libcamera+pipewire in turn makes now makes it possible to use the cameras on e.g. the Pinephone Pro and other devices in a simple manner.
2023-03-21 11:35:55 <robertmader[m]> Thanks for looking into it!
2023-03-21 11:36:40 <psykose> ah ok it's juse the .sign
2023-03-21 11:37:44 <robertmader[m]> The important part is to check if the alpine build system does binary stripping, which I'd assume it does?
2023-03-21 11:44:48 <psykose> b1d4082bfd0643dce8e4000a49c86781d2734cf0
2023-03-21 11:45:06 <psykose> should be fine but someone should probably test it
2023-03-21 11:57:38 <robertmader[m]> psykose: thanks, will try to do that later. If somebody else has a device using an IPA, such as a Pinephone Pro or a raspberry pi, you should be able to check by running `pw-dump | grep libcamera` (listing any output) or `gst-device-monitor-1.0 Video/Source` (showing libcamera devices for pipewiresrc).
2023-03-21 11:58:40 <psykose> if it works i'll backport it too i guess
2023-03-21 12:01:56 <robertmader[m]> Nice - with a bunch of other stuff having landed upstream recently (especially linux 6.3), this should allow us to finally mark cameras as "Works" on https://wiki.postmarketos.org/wiki/PINE64_PinePhone_Pro_(pine64-pinephonepro) and some devices, because simple apps like Cheese start to just work.
2023-03-21 12:04:19 <robertmader[m]> Some libcamera dev will test it and ping back.
2023-03-21 12:04:46 <psykose> it'll prolly take like 1.5 hours to build from now
2023-03-21 12:04:50 <psykose> some stuff in front in the queue
2023-03-21 12:04:57 <psykose> has to be edge specifically too
2023-03-21 12:42:48 <ovf> > Open-source modules are identified based on digital signatures, while closed-source modules are isolated inside a Sandbox environment with restricted access to the system, reducing the impact of untrusted binary blobs.
2023-03-21 12:43:09 <jmondi> psykose: ping
2023-03-21 12:43:14 <psykose> pong
2023-03-21 12:43:23 <ovf> one would think that the sandboxing decision needs to be made based on access requirements etc., not licence
2023-03-21 12:43:29 <jmondi> psykose: hello
2023-03-21 12:43:33 <psykose> hello
2023-03-21 12:43:35 <jmondi> I'm testing https://git.alpinelinux.org/aports/commit/?id=b1d4082bfd0643dce8e4000a49c86781d2734cf0
2023-03-21 12:43:53 <psykose> which architecture are you on
2023-03-21 12:43:58 <jmondi> but even with the patch applied, I still have invalid signatures
2023-03-21 12:44:03 <jmondi> postmarketos aarch64
2023-03-21 12:44:11 <psykose> is it edge and is the package 0.0.4-r1
2023-03-21 12:44:28 <jmondi> I have manually applied the patch to the APKBUILD
2023-03-21 12:44:34 <jmondi> however
2023-03-21 12:44:36 <psykose> sure, that works too
2023-03-21 12:44:42 <jmondi> I still have invalid signatures
2023-03-21 12:44:52 <psykose> yeah
2023-03-21 12:44:54 <psykose> let me think a bit
2023-03-21 12:45:12 <jmondi> and what puzzles me, is that the md5sum of the .sign file on the build chroot and on the target differ
2023-03-21 12:45:42 <psykose> target?
2023-03-21 12:46:17 <jmondi> ah no sorry
2023-03-21 12:46:42 <jmondi> yes, the target device where libcamera is deployed
2023-03-21 12:46:50 <jmondi> anyway, no sorry, the signatures match
2023-03-21 12:46:55 <jmondi> again, sorry
2023-03-21 12:46:59 <jmondi> the md5sum matches
2023-03-21 12:47:11 <jmondi> but the signatures are still invalid
2023-03-21 12:47:30 <psykose> hmm
2023-03-21 12:47:36 <psykose> it does basically the same thing as the arch patch
2023-03-21 12:47:40 <psykose> strip first then just sign again
2023-03-21 12:48:04 <jmondi> I know, I was expecting it to work in facts
2023-03-21 12:49:20 <psykose> ah hm
2023-03-21 12:49:27 <psykose> if i sha1sum in the loop it does not match the installed one
2023-03-21 12:51:18 <jmondi> mine do... https://paste.debian.net/1274785/
2023-03-21 12:51:58 <jmondi> but still PAManager ipa_manager.cpp:303 IPA module /usr/lib/libcamera/ipa_rkisp1.so signature is not valid
2023-03-21 12:53:18 <psykose> oh i know
2023-03-21 12:53:50 <psykose> it's because the debug package modifies the .so's later to add a .debug_link thing
2023-03-21 12:53:56 <psykose> hmm
2023-03-21 12:54:13 <psykose> but does it work if you just copy the things from the root to the host with definitely-matching signature
2023-03-21 12:55:28 <jmondi> no, but I've just re-generated the signauture running the signing script manually and now the sha512sum of the .sign file differ
2023-03-21 12:55:41 <jmondi> let me try to deploy the newly generated .sign file to the target
2023-03-21 12:57:21 <jmondi> yes
2023-03-21 12:57:22 <jmondi>  IPA module /usr/lib/libcamera/ipa_rkisp1.so signature is valid
2023-03-21 12:57:49 <jmondi> so if I re-generate the .sign file manually and deploy it to the target the signature validation works
2023-03-21 12:58:16 <psykose> hm, ok
2023-03-21 12:58:18 <jmondi> so there's likely another step that modifies the .so file after the package() step
2023-03-21 12:58:21 <psykose> 081c80e25a579d6a2dcb0639dace5e1a7c1194d2
2023-03-21 12:58:23 <psykose> this fixes the other issue
2023-03-21 12:58:28 <psykose> but nothing else should touch it
2023-03-21 12:58:49 <psykose> this makes the sha match, i think what you tried was slightly incorrect somehow (they definitely didn't match post-install before since -dbg modifies it)
2023-03-21 12:59:36 <psykose> if this still doesn't work then i have to look even harder, but these have matching checksums for sure so i would be puzzled
2023-03-21 12:59:45 <jmondi> let me try your patch
2023-03-21 12:59:56 <psykose> unless the signing itself is wrong somehow
2023-03-21 13:04:38 <jmondi> IPA module /usr/lib/libcamera/ipa_rkisp1.so signature is valid
2023-03-21 13:04:49 <jmondi> so yes, splitting out the -ipa() task helps
2023-03-21 13:06:20 <jmondi> which makes me wonder if !strip + manual stripping is now necessary
2023-03-21 13:07:01 <jmondi> but as I don't know where stripping would happen without !strip I won't bother and be happy with the package now working correctly :p
2023-03-21 13:08:42 <psykose> the !strip is kinda global, unlike in the arch pkgbuild it wouldn't apply to only the subpackage
2023-03-21 13:08:54 <psykose> so if you use it you have to manually do it, which is fine, just that scanelf loop
2023-03-21 13:08:58 <psykose> it's the same one strip does
2023-03-21 13:09:00 <psykose> if it works it works
2023-03-21 13:09:02 <psykose> thanks for testing :)
2023-03-21 13:10:10 <jmondi> no worries, thanks for fixing
2023-03-21 13:10:20 <jmondi> when can I expect those patches to land ?
2023-03-21 13:10:22 <psykose> (the -dbg is also a strip, it objcopy's the debug section, strips original, then adds a .debug_link to file location of .dbg)
2023-03-21 13:10:31 <psykose> edge is fixed pending rebuild, i'll do 3.17 in a second
2023-03-21 13:10:41 <psykose> nothing else to fix aside from that
2023-03-21 13:10:42 <jmondi> 3
2023-03-21 13:10:43 <jmondi> 2
2023-03-21 13:10:45 <jmondi> 1
2023-03-21 13:10:47 <psykose> :)
2023-03-21 13:10:47 <jmondi> go
2023-03-21 13:11:01 <jmondi> thanks, I'll re-pull later today
2023-03-21 13:13:46 <psykose> pushed
2023-03-21 13:13:56 <psykose> 3.17 is 0.0.1 libcamera, does that even work :D
2023-03-21 13:15:03 <robertmader[m]> Hm, at least not for devices like the pinephone pro which only got full support in 0.0.4
2023-03-21 13:15:32 <jmondi> 0.0.1 is ancient
2023-03-21 13:15:58 <psykose> z3ntu: wanna upgrade that too in 3.17
2023-03-21 13:42:34 <Newbyte> psykose: doesn't that break the stability guarantee of Alpine stable?
2023-03-21 13:42:40 <psykose> no
2023-03-21 13:42:44 <Newbyte> why not?
2023-03-21 13:42:56 <Newbyte> the libcamera API is not stable
2023-03-21 13:43:32 <psykose> in what sense
2023-03-21 13:43:37 <psykose> what uses it
2023-03-21 13:44:33 <Newbyte> psykose: I mean, isn't the idea that someone can build their own libcamera application against Alpine 3.17 and not have to worry about having to rebuild it or change their code until Alpine 3.18?
2023-03-21 13:44:53 <Newbyte> if you upgrade libcamera existing builds will break
2023-03-21 13:46:17 <psykose> sure, that is true
2023-03-21 13:46:40 <psykose> what libcamera applications even exist
2023-03-21 13:46:47 <psykose> all i know is pipewire links it
2023-03-21 13:48:12 <Newbyte> psykose: I used it for a university project
2023-03-21 13:48:23 <psykose> fancy
2023-03-21 13:49:07 <Newbyte> but my point is that people using Alpine stable as a development platform may be using it
2023-03-21 13:49:20 <psykose> yeah
2023-03-21 13:49:22 <psykose> good point
2023-03-21 16:19:17 <robertmader[m]> Newbyte: libcamera does not have a stable api yet, so devs arguably should be aware of that and not expect the same stability as they do from other libs. But I see the point.
2023-03-21 16:45:05 <robertmader[m]> i.e. IMHO apps requiring stability should statically compile libcamera for the moment - if all distros freeze it to the release version already it will block hardware enablement quite a bit unfortunately :/
2023-03-22 05:08:10 <ptrc> a475456ce8a14a248e291b2f2cd74fbec6c0b23e 🤔
2023-03-22 11:28:12 <ikke> ptrc: you mean 2 packages for the same source?
2023-03-22 11:28:20 <ptrc> two exactly same packages
2023-03-22 11:28:30 <ikke> right
2023-03-22 11:28:43 <ptrc> author of the mr followed a suggestion to rename, but didn't remove the original package
2023-03-22 11:29:03 <ptrc> so now we have two in aports, hence !45300
2023-03-22 11:29:26 <ikke> makes sense
2023-03-22 11:33:33 <ikke> ptrc: maintainer has not been active ever since, so I suppose it's no longer maintained either
2023-03-22 13:42:39 <Newbyte> <robertmader[m]> "i.e. IMHO apps requiring..." <- That is a reasonable argument. I wouldn't be against updating libcamera on stable branches in Alpine, but I think the current Alpine policy says no to that
2023-03-22 13:43:14 <Newbyte> But changing the policy to make exceptions like this sounds reasonable to me (but I'm not affiliated with Alpine beyond contributing to it)
2023-03-22 15:11:34 <ncopa> hoho.... my experiments in rust reveals bugs in aports tree
2023-03-22 15:12:19 <ncopa> this is great, i think what i've done today is useful for ci already
2023-03-22 15:14:58 <ncopa>  home/ncopa/aports/community/iio-sensor-proxy/APKBUILD
2023-03-22 15:15:10 <ncopa>  /bin/sh: syntax error: unexpected newline
2023-03-22 15:21:25 <ncopa> nope... I'm stupid. its a bug in my rust code
2023-03-22 15:21:54 <ncopa> what was funny was that I saw an unexpected ` char in the APKBUILD
2023-03-22 15:22:08 <ncopa> but it turned out to be dirt on my screen
2023-03-22 15:22:28 <ncopa> i couldnt understand why I couldn't see the ` from another window
2023-03-22 15:23:32 <lucidiot> i once had a comma like that, and didn't understand why the comma seemed to be moving slowly until it flew away
2023-03-22 15:24:20 <ncopa> LOL
2023-03-22 15:24:31 <ncopa> man i feel stupid now
2023-03-22 15:31:37 <psykose> whadya writing
2023-03-22 15:32:57 <ikke> Sounds a lot like what I already have in alpine/go
2023-03-22 15:48:38 <ncopa> yup
2023-03-22 15:48:46 <ncopa> im just trying to understand rust
2023-03-22 15:49:07 <ncopa> so i'm writing a APKBUILD parser similar to lua-aports
2023-03-22 15:49:41 <ncopa> mostly to learn how to do pipe things to a shell in rust and read it back
2023-03-22 15:51:03 <psykose> fun :)
2023-03-22 15:51:22 <psykose> ncopa: i had a thought the other day after seeing that it wouldn't be a collosal amount of work- to replace eudev with systemd-udev
2023-03-22 15:51:34 <psykose> the patchset is quite small and in relative terms is actually smaller than eudev
2023-03-22 15:51:42 <psykose> (given that eudev is years out of date at this point)
2023-03-22 15:53:34 <minimal> which other distros are using eudev at this point?
2023-03-22 15:54:26 <ncopa> sounds interesting
2023-03-22 15:55:09 <ncopa> where come that thought from? do we have problems with eudev?
2023-03-22 15:55:17 <ncopa> apart from that it is not well maintained anymore
2023-03-22 15:56:19 <minimal> I think its slow divergence from systemd-udev (both for udev rules and also for functionality) is the main issue
2023-03-22 15:56:42 <psykose>  mostly just that it's not maintained
2023-03-22 15:56:54 <psykose> this affects things like minor bugfixes that we may or may not even know about
2023-03-22 15:56:55 <skarnet> the effort would be better spent porting stuff to mdevd + libudev-zero. :P
2023-03-22 15:56:57 <psykose> and stuff like the hwdb
2023-03-22 15:57:10 <psykose> since nothing really keeps up with the hwdb quirks
2023-03-22 15:57:46 <ncopa> libudev-zero is even more diverged
2023-03-22 15:58:15 <psykose> i wouldn't even call it diverged
2023-03-22 15:58:37 <psykose> ncopa: the current patchset (this is for musl and systemd-stuff workarounds) is https://github.com/chimera-linux/cports/tree/f7e789f10b794e43319986652a11b28795492d5d/main/udev/patches
2023-03-22 15:58:52 <psykose> if we went with it i would probably make a repo with q66 to rebase that in i guess
2023-03-22 15:58:54 <psykose> up to you though
2023-03-22 16:00:58 <psykose> well, quite small is relative i guess
2023-03-22 16:01:22 <psykose> it's smaller than the 'patchset' of eudev being thousands of commits behind for reference, but i guess it would need more study on if it fixes something major
2023-03-22 16:01:43 <psykose> the hwdb stuff is in itself something i know for sure is a small pain
2023-03-22 16:02:41 <psykose> they sync it periodically (e.g. https://github.com/eudev-project/eudev/pull/239) but since there's no releases it's not like anyone gets to make use of it for devices to work
2023-03-22 16:04:13 <Newbyte> wow, there's cports now too?
2023-03-22 16:05:07 <minimal> yes, no news on c++ports yet though ;-)
2023-03-22 16:05:20 <Newbyte> can't wait for rustports
2023-03-22 16:08:48 <ddevault> .apk as tarballs is good, keep it
2023-03-22 16:09:14 <psykose> that's a request for apk-tools i think
2023-03-22 16:09:32 <ddevault> more of a general comment
2023-03-22 16:09:37 <ddevault> I didn't think apk was actually considering changing it?
2023-03-22 16:10:46 <ddevault> yeah apkv3 branch still uses tarballs
2023-03-22 16:10:51 <Newbyte> sorry, I meant hareports
2023-03-22 16:12:28 <ddevault> transient DNS issue (only one resolver configured, since fixed) caused libcrypto to fail during apk upgrade on a critical system
2023-03-22 16:12:38 <ddevault> no problem, download apk and tar -C/ it, fixed :)
2023-03-22 16:13:00 <ikke> alternative: download apk.static 
2023-03-22 16:13:17 <ddevault> we added "consider apk-static" to our upgrade notes
2023-03-22 16:13:48 <ddevault> but the use of tar and lack of NIH makes creative thinking on your feet pretty easy with alpine
2023-03-22 16:14:29 <ddevault> anyway, 25 hosts upgraded from 3.15 => 3.17 in less than two hours with no other issues
2023-03-22 16:14:36 <ddevault> alpine still solid as a rock :)
2023-03-22 16:15:26 <ddevault> look forward to our next fleet upgrade report in a year, I expect it to be as easy as they always have been
2023-03-22 16:18:29 <ncopa> im actually pretty happy to hear that apk as tarballs was a good idea
2023-03-22 16:19:31 <ncopa> i remember thinking in the lines back then (15 years ago+) that one day someone will have use for it in a way i cannot predict :)
2023-03-22 16:19:36 <ncopa> and apparently i was right :)
2023-03-22 16:19:49 <psykose> it's a wonderful format especially compared to all the others
2023-03-22 16:20:24 <psykose> keeping compression separate has always let people do various compression stuff on them too at their choosing (generally speaking)
2023-03-22 16:20:40 <psykose> in contrast to zip i guess
2023-03-22 16:21:14 <ncopa> there were two things i thought was a good idea back then
2023-03-22 16:21:54 <ncopa> 1) gzip and tar are streamable, which means we can process data from a stream, and process it while waiting for the network io
2023-03-22 16:22:25 <ncopa> 2) it should be possible to use standard tools (like tar and gzip) to do troubleshooting
2023-03-22 16:23:25 <ncopa> my chatgpt rust code is stupid
2023-03-22 16:23:48 <ncopa> reading file from a reader into a string
2023-03-22 16:23:55 <ncopa> writing the string to a writer
2023-03-22 16:24:09 <ncopa> there is io::copy that does that more efficiently
2023-03-22 16:25:49 <ddevault> aye, I am pretty fond of tar
2023-03-22 16:25:55 <ddevault> and I thought that was hare's io::copy for a second -_-
2023-03-22 16:28:18 <ncopa> i have used chatgpt to generate som rust code because I don't know rust very well
2023-03-22 16:29:41 <ncopa> i did some "split the main function into multiple smaller functions"
2023-03-22 16:29:50 <ncopa> and from there i got a few ideas 
2023-03-22 16:30:42 <ncopa> the code runs and apparently work, and i read the rust docs to understand why it works
2023-03-22 17:00:18 <Ermine> Are APKv3 packages still tar? Ariadne wrote something about that last year.
2023-03-22 17:14:20 <ikke> I recall something about some memory mapped format 
2023-03-22 17:15:36 <minimal> yes I also recall talk that APKv3 files where NOT going to remain as simple tar files
2023-03-22 17:21:56 <mercenary> I seem to remember that too, and thought it very unfortunate. There were some good reasons, but having something where standard tooling and libraries Just Work(tm) is imo a large selling point.
2023-03-22 17:42:57 <minimal> my thoughts/concerns at the time where how would I continue to do "bootstrapping" in a script using apk.static and extracting repo keys (for use by apk.static) from the alpine-keys package if the alpine-keys package would no longer be a simple tarfile
2023-03-22 18:00:42 <elly> apkv3 packages are not tar files
2023-03-22 18:01:10 <elly> https://git.alpinelinux.org/apk-tools/tree/doc/apk-v3.5.scd
2023-03-22 18:08:47 <minimal> elly: right, hence my point about the chicken-and-egg situation of getting Alpine keys from a APK package in order to run apk.static to create a base Alpine system for a chroot environment
2023-03-22 18:10:08 <ikke> minimal: releases.json points to the keys that you can download directly 
2023-03-22 18:14:05 <ovf> elly: is there a rationale for the direction apkv3 has apparently taken?
2023-03-22 18:14:13 <minimal> ikke: where is releases.json?
2023-03-22 18:14:56 <ikke> https://alpinelinux.org/releases.json
2023-03-22 18:15:16 <elly> ovf: I don't know, I was not involved in its creation - I just reverse-engineered the format to document it because I was curious how it works
2023-03-22 18:15:44 <elly> the new format has some benefits over the old format, but whether those outweigh the drawback of needing custom tools, I am not sure
2023-03-22 18:17:28 <minimal> ikke: thanks, didn't see a mentioned of that. Now time for "jq" to figure out hoe to parse it...
2023-03-22 18:18:27 <ikke> minimal: where would you expect that to be documented? 
2023-03-22 18:18:57 <minimal> ikke: perhaps a link/reference to it from the usual Releases page?
2023-03-22 18:24:20 <psykose> cgit should have a dark theme now
2023-03-22 18:24:49 <psykose> defaults on the media prefers-color-scheme thing
2023-03-22 18:25:04 <psykose> let me know of any issues and i might even fix them
2023-03-22 18:33:35 <psykose> the highlighting is also pygments instead
2023-03-22 18:43:08 <psykose> ikke: was there a reason the cgit setup is split in two
2023-03-22 18:43:38 <psykose> the nginx container has a .cgi but then also passes over to the other cgi over uwsgi in another place
2023-03-22 18:43:48 <psykose> and the former has the css and the latter all the config and highlighting
2023-03-22 18:43:58 <psykose> it took me like two hours to figure out why the css didn't even work
2023-03-22 18:44:18 <Ermine> > It is currently illegal for a DATAX block to appear.
2023-03-22 18:44:27 <Ermine> 
ACTION looks at DATAX block

2023-03-22 18:45:19 <Ermine> Wait. That's illegal
2023-03-22 18:50:55 <elly> well, it is :)
2023-03-22 19:06:42 <mercenary> As is using a different compiler or -O options apparently, unless I misunderstand the Notes
2023-03-22 19:33:05 <pj> hearing ncopa learn rust from chatgpt makes me fear for future of the project
2023-03-22 21:06:32 <ikke> psykose: you'd have to ask clandmeter, who did most of the work on cgit
2023-03-22 21:09:00 <psykose> :)
2023-03-22 21:27:48 <Newbyte> <pj> "hearing ncopa learn rust from..." <- what, you're not looking forward to abuild-rs?
2023-03-22 21:37:31 <pj> <Newbyte> "what, you're not looking forward..." <- I'm
2023-03-22 21:38:13 <pj> It's why I'm developing it
2023-03-22 22:38:05 <Test1324356> Hello! I'm creating a distribution of Alpine for a specific purpose (3d printing). I feel like it would be easier on the users for me to distribute an apk cache. I couldn't find any information on Alpine's licensing, so can I redistribute this APK cache?
2023-03-22 22:49:43 <psykose> why would the apk cache be affected by "alpine licensing"
2023-03-22 22:51:20 <psykose> i am definitely your lawyed and this is definitely paid legal advice: apk generates the apk cache, and it has https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/LICENSE , so that is not relevant
2023-03-22 22:51:45 <psykose> and the actual .apks contain things that are bound to the licence of what you put in them i guess
2023-03-22 22:51:52 <psykose> nothing from alpine plays a part in that
2023-03-22 22:54:08 <Test1324356> alright thanks
2023-03-22 22:54:31 <Test1324356> so do you think the devs would respect me redistributing the apk cache?
2023-03-22 22:54:50 <Test1324356> i'm used to ubuntu/debian's stricter licensing for deriviatives
2023-03-22 22:55:55 <psykose> idk what licensing you expect
2023-03-22 22:56:12 <psykose> the apk cache is a bunch of files, it's up to you to read the files and figure out if you are allowed to do it or not
2023-03-23 10:02:42 <ncopa> pj: don't worry. this is mostly for my own amusement at this point. And I was able to detect various things it does stupid
2023-03-23 10:03:31 <ncopa> and I don't learn from the code chatgpt generates. I learn from checking it against the official rust docs.
2023-03-23 10:07:56 <ncopa> chatgpt is a tool that with great confidence will tell you to shoot yourself in the foot
2023-03-23 10:14:52 <ikke> And convince you that it's normal to shoot yourself in the foot 
2023-03-23 10:17:18 <ncopa> ikke: the alpine/go APKBUILD parser will not spawn any shell, will it?
2023-03-23 10:18:06 <ikke> No, it won't 
2023-03-23 10:20:25 <ikke> It uses mvdan.cc/sh to parse them 
2023-03-23 10:21:05 <ncopa> is this still true? https://gitlab.alpinelinux.org/alpine/go/-/blob/master/README.md?plain=1#L21
2023-03-23 10:22:16 <ncopa> oh shfmt sounds nice for formatting shellcode
2023-03-23 10:24:56 <ikke> No, forgot to update it
2023-03-23 10:25:06 <ncopa> but there is a chance that mvdan.cc/sh and shell will parse it differently?
2023-03-23 10:25:16 <ncopa> and if they do, shell is correct, right?
2023-03-23 10:25:56 <ikke> I haven't come across an issue yet in aports 
2023-03-23 10:26:16 <ncopa> I mean, it is a theoretical problem
2023-03-23 10:26:42 <ncopa> i would feel more confident if it was parsed in shell
2023-03-23 10:27:03 <ikke> https://gitlab.alpinelinux.org/kdaudt/apkgquery uses it 
2023-03-23 10:35:01 <ncopa> it seems like it manages to parse main/bash and print correct number of $source
2023-03-23 10:35:04 <ncopa> hum
2023-03-23 10:51:53 <ikke> Yeah, the top level is really evaluated 
2023-03-23 10:52:01 <ikke> So not just static analysis 
2023-03-23 11:07:06 <ncopa> pretty cool
2023-03-23 11:20:14 <ikke> I wanted to avoid forking to speed up the process, and so far, haven't noticed any discrapencies
2023-03-23 11:27:15 <ikke> It also powers apkcircledep from ptrc btw
2023-03-23 11:27:23 <ikke> which detects circular dependencies across aports
2023-03-23 11:27:57 <ikke> https://gitlab.alpinelinux.org/ptrcnull/apkcircledep
2023-03-23 11:30:38 <ncopa> nice
2023-03-23 12:14:10 <ikke> ncopa: the only 'blind' spot is still metadata for subpackages
2023-03-23 12:14:27 <ikke> as you'd need to evaluation the split functions
2023-03-23 12:15:33 <ikke> ``
2023-03-23 14:13:22 <ncopa> we can not set metadata in the split functions. it must be in global scope
2023-03-23 14:13:44 <ncopa> which is why i have wanted a better designed APKBUILD format
2023-03-23 14:13:54 <ikke> yes, you mentioned that before
2023-03-23 14:14:01 <ikke> which is why I refrened from persuing that
2023-03-23 14:14:05 <ikke> refrained*
2023-03-23 14:14:23 <ncopa> yes. we should not even try
2023-03-23 14:15:08 <ikke> maybe mention that here as well https://gitlab.alpinelinux.org/alpine/go/-/issues/3
2023-03-23 14:20:33 <ncopa> btw. I have been working on a script that generates a bootable disk image with multiple partitions (EFI + root partition), without mounting anything
2023-03-23 14:21:16 <ncopa> i was thinking we could create official "cloud" images or similar in that way
2023-03-23 14:21:31 <ikke> right, that would be nice
2023-03-23 14:21:39 <ikke> That would make it easier to do in CI I suppose
2023-03-23 14:21:45 <ncopa> yes
2023-03-23 14:21:52 <ncopa> that is what i was thinking
2023-03-23 14:24:04 <minimal> ncopa: similar to my own script?
2023-03-23 14:24:24 <ncopa> i suppose
2023-03-23 14:24:28 <ikke> minimal: yours did require some mounts, right?
2023-03-23 14:24:47 <ncopa> and similar to what the current cloud images does
2023-03-23 14:25:17 <minimal> ikke: well it's doing chroot so needs filesystems mounted for that
2023-03-23 14:25:41 <minimal> ncopa: not sure what you mean by "without mounting anything" - how do you write to fs if it is not mounted?
2023-03-23 14:25:56 <ncopa> minimal: that is the thing
2023-03-23 14:27:20 <ncopa> mkfs.ext4 -E offset=$offset -d dir file.img $size
2023-03-23 14:27:29 <minimal> ncopa: for my script I'm creating a disk image files, partitioning & formatting it, then using loop device in order to mount each partition, then chrooting into it
2023-03-23 14:27:52 <ncopa> the problem I had at hand was the loop device
2023-03-23 14:28:06 <minimal> what was the problem?
2023-03-23 14:28:23 <ncopa> the CI would allocate a loop device in docker --privileged
2023-03-23 14:28:27 <ikke> oh nice, -d
2023-03-23 14:28:33 <ikke> "Copy the contents of the given directory into the root directory of the file system."
2023-03-23 14:28:58 <ncopa> for some reason, the CI job failed to release the loop device
2023-03-23 14:29:09 <minimal> also you wouldn't then intend to support LVM, LUKS, MD etc? and how to install bootloader?
2023-03-23 14:29:29 <ncopa> so at some point it ran out of loopdevices
2023-03-23 14:29:34 <ncopa> default i 8
2023-03-23 14:29:58 <ncopa> no, just plain ext4 in a gpt partition
2023-03-23 14:30:04 <ncopa> + efi partition with vfat
2023-03-23 14:30:14 <ncopa> mkfs.vfat can also take offise and size
2023-03-23 14:30:25 <minimal> so what about cloud providers that don't (officially or otherwise) support UEFI?
2023-03-23 14:30:29 <ncopa> and mcopy -i file.img@@$offset can be used
2023-03-23 14:30:48 <ncopa> they will have to use something else
2023-03-23 14:31:05 <ncopa> at least for now
2023-03-23 14:31:25 <ncopa> i mean, uefi is a good start
2023-03-23 14:31:45 <ncopa> ppc64le and other etc can be handled later, if ever needed
2023-03-23 14:32:00 <minimal> I was referring to BIOS on x86/x86_64
2023-03-23 14:32:54 <ncopa> should be possible to do a hybrid partition table?
2023-03-23 14:33:45 <minimal> hybrid booting can be setup, but how to use the likes of grub-install (writing to MBR) with your method?
2023-03-23 14:34:21 <ncopa> i dont know
2023-03-23 14:35:09 <ncopa> i mean, syslinux has a mbr.bin for MBR
2023-03-23 14:35:13 <ncopa> its only 404 bytes
2023-03-23 14:35:30 <ncopa> so we can use dd?
2023-03-23 14:35:39 <minimal> yeah but can that be copied to 1st sector from inside the docker env you're talking about?
2023-03-23 14:36:09 <minimal> I thought you were "presenting" only filesystems to the docker env
2023-03-23 14:36:37 <ncopa> its a disk image file, so you are asking if its possible to write specific 404 bytes in the beginning of a file
2023-03-23 14:36:52 <ncopa> i mean, why wouldnt it be possible
2023-03-23 14:38:09 <minimal> maybe I'm confused about exactly what you're proposing
2023-03-23 14:38:53 <ncopa> im proposing create disk images without need capabilites to mount anything and without depending on loop back devices from kernel
2023-03-23 14:38:55 <minimal> but generally speaking bootloaders' install scripts would expect to see things mounted for them to do their work
2023-03-23 14:40:35 <ncopa> which means that you really need to boot up a vm to create images, which is sort of painful
2023-03-23 14:41:03 <minimal> nope, can be done in chroot
2023-03-23 14:42:21 <ncopa> yes it can, if you can guarantee that it never fails in unexpected ways
2023-03-23 14:42:36 <ncopa> (eg killed by oom killer or with any kill -9)
2023-03-23 14:43:01 <minimal> my script doesn't need a VM, it does need root privs however as it uses stuff like cryptsetup and LVM utils
2023-03-23 14:43:45 <minimal> that's why I moved away from doing stuff inside Docker, when I wanted to add encryption and LVM etc support
2023-03-23 14:44:11 <ncopa> docker is technically a more sofisticated chroot
2023-03-23 14:44:19 <ncopa> so whatever you can do in a chroot you can do in docker
2023-03-23 14:44:45 <ncopa> but also, if you script is killed with -9, it does not clean up its resources
2023-03-23 14:45:20 <minimal> true, it does trap and cleanup for normal errors, but not for -9
2023-03-23 14:45:22 <ncopa> and if you re-run it and kill -9 it multiple times you will run out of loopback devices
2023-03-23 14:46:00 <ncopa> the only way to guarantee clean up is to run it in a vm
2023-03-23 14:46:50 <minimal> right, and my script *can* be run in a VM, it just doesn't require it
2023-03-23 14:47:14 <minimal> but you also said you had problems with loop device cleanup too
2023-03-23 14:47:25 <ncopa> so, the problem i solved this and previous week was a github runner that ran out of loopback devices
2023-03-23 14:49:36 <ncopa> i have no idea what or how it got in a state where the trap didn't execute the cleanup
2023-03-23 14:49:48 <ncopa> i was never able to reproduce it
2023-03-23 14:50:31 <ncopa> maybe it was oomkiller, maybe it was a race condition, maybe it was something else
2023-03-23 14:51:05 <ncopa> using loopback dev worked just fine, without any problems, for months (years?) - until it didn't
2023-03-23 14:58:15 <skarnet> yeah, permanent resources are difficult to deal with. Depending on the system, periodic scripts that perform cleanups may be useful
2023-03-23 14:58:33 <skarnet> but I'm not sure how that could apply to loopback devices, that users may want to keep permanently
2023-03-23 14:59:04 <skarnet> you'd need a table of permanent lodevices you want to keep, and clean up the rest... and bam you're in the weeds of distro-specific sysadmining again :/
2023-03-23 15:03:33 <ptrc> firefox is segfaulting for me on edge, does anyone else have this problem?
2023-03-23 15:07:46 <ptrc> nevermind, reinstall fixed it
2023-03-23 15:13:37 <ncopa> i just realized that not even root permissions would be needed to create rootfs if fakeroot is used
2023-03-23 15:13:40 <ncopa> cool...
2023-03-23 15:15:30 <minimal> aren't you creating the rootfs in the CI VM (which has root privs) before docker is invoked?
2023-03-23 15:16:32 <ncopa> right now im only playing with the idea of doing this for alpine, so im not currently doing anything
2023-03-23 15:16:51 <ncopa> the thing i worked on earlier created the rootfs in docker
2023-03-23 15:16:59 <ncopa> which is sort of nice tbh
2023-03-23 15:17:42 <minimal> ok, so which bits would happen outside docker?
2023-03-23 15:17:49 <ncopa> none
2023-03-23 15:18:34 <minimal> ok, so partitioning happens inside docker?
2023-03-23 15:18:35 <ncopa> well the github runner software that runs the docker image create and runs the create_image.sh script in docker
2023-03-23 15:18:57 <ncopa> the create_image.sh script runs in a docker container with --privileged yes
2023-03-23 15:19:48 <ncopa> anyway, i should probably fix the nocloud support for tiny-cloud first
2023-03-23 15:20:34 <minimal> I didn't point out in alpine-cloud an general "issue" with passing "ds=" on cmdline that I'd spotted
2023-03-23 15:20:45 <minimal> oops s/didn't/did/
2023-03-23 15:21:28 <minimal> I had to quote the value otherwise it was being truncated at first semicolon when passed to kernel by bootloader
2023-03-23 15:22:16 <ncopa> oh. i think i know why
2023-03-23 15:22:20 <ncopa> eval is evil
2023-03-23 15:22:38 <minimal> saw this happening with grub and limine and (I think) syslinux
2023-03-23 15:23:06 <skarnet> shells should rename eval to evil
2023-03-23 15:23:14 <minimal> why eval? this wasn't in initramfs' init, it was when the kernel received it from bootloader
2023-03-23 15:23:57 <minimal> "dmesg" clearly shows kernel receiving a truncated cmdline
2023-03-23 15:24:05 <ncopa> oh, really
2023-03-23 15:24:17 <ncopa> i thought it was eval here: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L368
2023-03-23 15:24:28 <ncopa> thats a bootloader issue then
2023-03-23 15:24:36 <minimal> yupe, I even tested this in Grub when using "e" to edit the menu option during boot
2023-03-23 15:24:41 <ncopa> not really a tiny-cloud issue
2023-03-23 15:25:55 <minimal> right, but it's not going to work for as expect with tiny-cloud (or cloud-init) if it's not quoted - e.g. ds='h=test;s=http://a.b.c/seed'
2023-03-23 15:36:23 <donoban> ncopa: have you discarded the option of properly release the "unused" loopbacks? maybe there is some way for doing it
2023-03-23 15:37:15 <donoban> looking at 'docker events' you could check what containers have something mounted, in case of get a destroy event, just unmount everything linked to that container
2023-03-23 15:37:34 <ncopa> yeah i think that might work
2023-03-23 15:37:46 <ncopa> and it was on the table
2023-03-23 15:38:00 <ncopa> i was a bit skeptic
2023-03-23 15:38:12 <ncopa> what happens if there are parallel jobs at the same time?
2023-03-23 15:38:46 <ncopa> as i understand losetup, it would release it once its unmounted
2023-03-23 15:39:00 <donoban> hmm.. if don't sure what you mean
2023-03-23 15:39:36 <ncopa> would be racy
2023-03-23 15:40:01 <donoban> I'm thinking on a simple script that runs on the host monitoring events, it tracks mounts/unmounts and stores all mounted devices for each container, on a container destroy event it cehecks if there are some devices for that container
2023-03-23 15:40:15 <ncopa> job1 does losetup loop0 to img1
2023-03-23 15:40:35 <ncopa> job2 releases all unused loop devices
2023-03-23 15:41:06 <ncopa> job1 tries to mount loop0 - which job2 at this point has released
2023-03-23 15:41:43 <ncopa> so i figured its much better to do it without loop devices, since its theoretically possible
2023-03-23 15:42:30 <ncopa> you have write access to the image file and can in theory populate it without help of kernel and loopback devices
2023-03-23 15:42:46 <ncopa> anyway, that is a solved problem now
2023-03-23 15:42:58 <ncopa> and as a bonues, the docker images no longer needs to run privileged
2023-03-23 15:43:24 <donoban> oh great
2023-03-23 15:44:04 <ncopa> took hours/days to get the offiset and sizes right
2023-03-23 15:44:12 <ncopa> different tools operates with different units
2023-03-23 15:44:33 <minimal> what about 4K sector sizes?
2023-03-23 15:44:35 <ncopa> sectors (512 bytes), blocks (1024 bytes or maybe 4096)
2023-03-23 15:44:45 <ncopa> minimal: what about them?
2023-03-23 15:45:12 <ncopa> i think mkfs.ext4 has option for sector size?
2023-03-23 15:45:14 <minimal> I'm not sure if some cloud providers with NVME storage present as 512B or 4K
2023-03-23 15:45:47 <ncopa> i dunno
2023-03-23 15:46:00 <ncopa> in any case, i should work on tiny-cloud tests now
2023-03-23 15:46:15 <minimal> so if 4K then might not be bootable if created for 512
2023-03-23 15:46:57 <ncopa> i was just happy that i was able to actually create images without loopback devices, because it is a thing i have been thinking about for years
2023-03-23 15:48:45 <donoban> thats a good feeling :)
2023-03-23 15:48:57 <ncopa> indeed :)
2023-03-23 15:51:20 <skarnet> ncopa: creating images without loopback devices (and without the horror that is virt-make-fs) is something I'd love to do, what's the trick? (or where's the source if that's simpler XD)
2023-03-23 15:54:29 <ncopa> unfortnately it was in a closed repo
2023-03-23 15:54:58 <ncopa> but the key points are: sfdisk --label gpt <<-EOF
2023-03-23 15:55:15 <ncopa> mkfs.ext4 -E offset=... -d sourcedir file.img
2023-03-23 15:55:28 <ncopa> mkfs.ext4 -E offset=... -d sourcedir file.img $size
2023-03-23 15:55:54 <ncopa> mkfs.vfat --offset ... file.img $size
2023-03-23 15:56:16 <ncopa> mcopy -i file.img@@$offset ...
2023-03-23 15:56:18 <ikke> How to determine the offset?
2023-03-23 15:56:52 <ncopa> that is the tricky part
2023-03-23 15:57:41 <ncopa> and i had to make the ext4 filesystem 1MB smaller than the caclulated partition size
2023-03-23 15:58:12 <ncopa> sfdisk can do: size=1M,
2023-03-23 15:58:39 <ncopa> mkfs.vfat operated with sectors so had to / 512
2023-03-23 15:58:55 <ncopa> and mkfs.vfat also needed -S 512 iirc
2023-03-23 15:59:06 <ncopa> and 12 bit fats or something
2023-03-23 15:59:31 <ncopa> mkfs.ext4 -E offset operates in bytes
2023-03-23 15:59:46 <ncopa> size can be suffixed with k,m,g,t etc
2023-03-23 15:59:57 <ikke> y
2023-03-23 16:00:08 <ncopa> some place it had to be 'm' other it was MiB
2023-03-23 16:00:25 <ncopa> but that was the hard part to figure out
2023-03-23 16:01:19 <ncopa> offsets and sizes were all different units
2023-03-23 16:04:00 <ncopa> i suppose i should wrap it up in a script
2023-03-23 16:04:03 <minimal> ncopa: how are you populating the resultant rootfs with Alpine packages? if it isn't mounted then are yuo not using "apk" at all to install stuff?
2023-03-23 16:04:45 <ikke> minimal: the -d allows you to specify a dir that's used to populate the image from what I can see
2023-03-23 16:04:55 <ovf> i suppose that's the kind of thing that libguestfs was meant to solve, but ended up being some strange monstrosity of python and ocaml
2023-03-23 16:05:16 <ncopa> ovf: yeah exactly
2023-03-23 16:05:50 <minimal> ikke: but what dir? which directory represents the rootfs of the image if it's not mounted?
2023-03-23 16:06:12 <ncopa> minimal: the job i did was for debian images, they created a docker image as the rootfs and then exported it toa debian.tar file
2023-03-23 16:06:53 <ncopa> then they ran docker ... create_image.sh which untars the debian.tar to temp dir, and them mkfs.ext4 ... -d /tmp/rootfs ...
2023-03-23 16:07:44 <minimal> ncopa: right so that is just mcopy'ing "arbitrary" files into the fs
2023-03-23 16:07:53 <ncopa> exactly
2023-03-23 16:08:11 <minimal> so something first would have to create a valid Alpine install for it to copy
2023-03-23 16:08:44 <minimal> so you've avoid the chroot-type situation but moving that part out of this solution
2023-03-23 16:08:59 <minimal> s/but/by/
2023-03-23 16:09:39 <minimal> so this is step 2 of a two-step mechanism for creating cloud images
2023-03-23 16:11:05 <ncopa> actually, the interesting bits here is that no kernel capabliliteis for mount is needed. (and with fakeroot, no root permissions either)
2023-03-23 16:12:03 <ncopa> makes me think that it woudl be extremely cool if mkfs.ext4 -d could take a tarball (or more) as input, instead of a dir
2023-03-23 16:12:25 <minimal> ok, but step 1 (creating the Alpine installed files for cloud use) would also run via CI and then wouldn't it need mount and/or chroot to function?
2023-03-23 16:13:01 <ncopa> theoretically not
2023-03-23 16:13:26 <ncopa> apk files are just tarballs...
2023-03-23 16:14:27 <minimal> yeah but what manages deps? and triggers (such as mkinitfs creating initramfs file when kernel package installed) etc
2023-03-23 16:14:53 <ncopa> good point
2023-03-23 16:15:02 <ncopa> those wouldnt run
2023-03-23 16:15:31 <ncopa> but that is a different problem
2023-03-23 16:15:55 <ncopa> and already now we build iso images with deps and initramfs - without needing to be root
2023-03-23 16:16:29 <minimal> yes you've have to manage deps in the script (manage deps changes for new versions of each package?) and would have to create initfs and know of any other triggers that existed that were important to do the same tasks
2023-03-23 16:16:59 <ncopa> yup
2023-03-23 16:21:03 <minimal> rather than having apk manage all that for you
2023-03-23 16:38:15 <ncopa> our current iso images let apk manage the deps
2023-03-23 18:10:43 <pj> ncopa: well, I hope so because from chat history it sounded uncertain and I've had way too many people tell me already they are learning from chatGPT or using it constantly which is worrisome
2023-03-24 05:31:43 <qaqland[m]> whats the difference between pkgname and origin? pkgname is used for install or search, origin is used for webpage index. Is it right?
2023-03-24 05:35:00 <psykose> in what context
2023-03-24 05:35:55 <psykose> if you mean something like apk search --origin, the origin package is the parent package, i.e. not a subpackage
2023-03-24 05:36:43 <qaqland[m]> I'm looking into APKindex and Apk spec
2023-03-24 05:36:53 <psykose> same thing then
2023-03-24 05:39:39 <qaqland[m]> Got it
2023-03-24 06:49:51 <ncopa> origin is the APKBUILD the .apk comes from. Useful in case of subpackages
2023-03-24 06:52:49 <psykose> ncopa: do you think it would be a good idea to add things like shadow, motd, shells, ... to apk/protected_files.d as an exclusion? otherwise one constantly has to `z` them away in update-conf
2023-03-24 06:53:08 <psykose> and ever updating them is probably a mistake and would break your system in case of shadow etc
2023-03-24 07:17:00 <ncopa> does apk use protected_files.d? or is it only update-conf?
2023-03-24 07:17:04 <ncopa> i dont remember how that works
2023-03-24 07:19:32 <ncopa> but in general i think its a good idea to solve the problem with update-conf
2023-03-24 07:24:03 <psykose> apk will not create .apk-new for things excluded in protected_files afaik
2023-03-24 07:24:12 <psykose> or maybe
2023-03-24 07:24:13 <psykose> i'm wrong
2023-03-24 07:24:23 <psykose> protected_paths.d *
2023-03-24 07:24:40 <psykose> and update-conf can't update what doesn't have a .apk-new
2023-03-24 07:24:51 <psykose> although i don't really know how it works
2023-03-24 07:26:31 <psykose> i looked at ca-certificates, then copied the same thing for
2023-03-24 07:26:32 <psykose> d9bce0e6298290a34e44210e4d3806134ca8886a
2023-03-24 07:26:36 <psykose> but afaict it doesn't work?
2023-03-24 07:26:43 <psykose> but it does for ca-certs
2023-03-24 07:27:50 <psykose> maybe it's broken for subpackages
2023-03-24 07:28:58 <psykose> nope
2023-03-24 07:30:21 <psykose> maybe it's forbidden top-level for /etc
2023-03-24 07:32:33 <psykose> ok so it has to end in .list for sure
2023-03-24 07:33:33 <psykose> the rest looks like it should work but it does not
2023-03-24 07:34:37 <psykose> also there is a 1% chance fakeroot failure that happens sometimes
2023-03-24 07:34:38 <psykose> https://img.ayaya.dev/6MCa9lLXR1c5
2023-03-24 08:29:29 <ncopa> oh interesting
2023-03-24 08:29:36 <ncopa> fakeroot is somewhat hackish
2023-03-24 08:29:55 <ncopa> i thought protected_paths.d would make apk always overwrite the files
2023-03-24 08:30:04 <psykose> it does for everything except that one thing
2023-03-24 08:30:16 <psykose> i found from the code that it has to end in .list but it still doesn't work
2023-03-24 08:30:39 <psykose> so i'm doing something else wrong but i dunno what it is
2023-03-24 08:30:41 <ncopa> anyone from desktop/gnome team could have a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/151?
2023-03-24 08:31:12 <ncopa> psykose: i was thining that we should maybe do the logic in update-conf for the specific files
2023-03-24 08:31:32 <psykose> we can but i don't think it makes much sense if we can make the former work
2023-03-24 08:31:32 <ncopa> with a flag to optionally keep the odl/current behavior
2023-03-24 08:31:50 <psykose> if we never want to update the files then there is no point for the .apk-new to be there, and then it avoids it entirely
2023-03-24 08:32:03 <psykose> when would you ever want to merge shadow.apk-new except to instantly destroy your system?
2023-03-24 08:32:29 <psykose> we can avoid it with more code but by not making it also works
2023-03-24 08:32:39 <psykose> i guess i have to debug why apk doesn't like that one particular case and makes it anyway..
2023-03-24 08:32:57 <ncopa> so, the idea with update-conf was to make upstream changes in default config visible
2023-03-24 08:33:15 <psykose> yes, and the things we're excluding here are not configs
2023-03-24 08:33:16 <ncopa> and give you a change to manually merge in upstream changes
2023-03-24 08:34:42 <psykose> let me refocus the point. what update-conf does or doesn't do is not actually important, i was just using it as an example
2023-03-24 08:34:46 <ncopa> ideally we should do a 3-way merge, but that is a bit complicated
2023-03-24 08:34:49 <psykose> the .apk-new should just not exist for things like shadow et al
2023-03-24 08:35:12 <psykose> that update-conf lets you merge a nuke after is way after
2023-03-24 08:35:20 <ncopa> well, im not sure i agree here
2023-03-24 08:35:43 <psykose> so you have a usecase for merging a default shadow? what would it be?
2023-03-24 08:36:02 <ncopa> i agree that you will not want replace your shadow with .apk-new 
2023-03-24 08:36:38 <psykose> then it should also not be there? or do you mean 'me' by 'you'? i mean the universal case
2023-03-24 08:36:54 <psykose> the exclusion would be tied to alpine-baselayout-data
2023-03-24 08:36:57 <ncopa> but if lets say there is a new default syster user id or a uid was removed, it would be nice to make that visible and give the user a change to manually merge that in
2023-03-24 08:37:29 <ncopa> if we simply never create the .apk-new there is no way to know if there were any changes in the default configs from updated .apk
2023-03-24 08:37:42 <psykose> ah wait a minute
2023-03-24 08:37:47 <psykose> i was thinking of it backwards
2023-03-24 08:37:51 <psykose> apk doesn't support this at all
2023-03-24 08:38:07 <psykose> adding the exclusion would just make it impossible to make users because baselayout-data shadow would always get replaced
2023-03-24 08:38:09 <psykose> hrm
2023-03-24 08:38:14 <psykose> guess it does have to be in update-conf
2023-03-24 08:38:59 <psykose> but as a response to that- i understand what you mean, but it just really doesn't work that way by default, because there is no database of changes
2023-03-24 08:39:11 <ncopa> so what i previously had in mind was a list of files to auto-nuke .apk-new
2023-03-24 08:39:23 <psykose> every single 'shadow was modified' is just 50 lines of everything you ever made, haha
2023-03-24 08:39:27 <ncopa> yes, i know it is a bit clumsy, and current behaviour is not good
2023-03-24 08:39:33 <psykose> yeah, nuking some specific .apk-news without a special flag is ok
2023-03-24 08:39:52 <ncopa> but it make it theoretically possible to pick upstream changes
2023-03-24 08:41:00 <psykose> it also doesn't work very well without vimdiff that lets you edit it, you either get the whole thing or nothing, you can't pick hunks to apply (there is `e` but you have to memorise what you want to change before you open it)
2023-03-24 08:41:04 <psykose> but making that work is complicated
2023-03-24 08:41:14 <psykose> since you would most likely have to add a whole tool just for the functionality
2023-03-24 08:41:37 <psykose> i guess it's all a wishlist, and default-rm seems like something workable to start
2023-03-24 08:47:48 <ncopa> and add a update-conf to test-suite
2023-03-24 08:48:31 <ncopa> i have to step out for a few hours
2023-03-24 08:51:10 <psykose> have fun :)
2023-03-24 08:51:40 <ncopa> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/tests/update_conf_test
2023-03-24 08:52:52 <ncopa> Add a test for current behavior, modify test to desired behavior (test now fails) change code so test passes 
2023-03-25 11:42:02 <nmeum> is there a way to flag spurious "package out of date"-reports on pkgs.alpinelinux.org?
2023-03-25 13:10:49 <ikke> There is no way to flag flags
2023-03-25 14:59:26 <Nulo[m]> how would i go about packaging https://github.com/chaptergy/certbot-dns-njalla? i don't know much about python. looking at https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/certbot-apache/APKBUILD it seems it uses gpep517, but i believe certbot-dns-njalla isn't PEP517 compliant.
2023-03-25 15:02:38 <ikke> It has a setup.py, so the classical python way
2023-03-25 15:03:44 <Nulo[m]> what's that? this? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ansible/APKBUILD
2023-03-25 15:04:33 <ikke> Yes
2023-03-25 15:38:03 <Qa> how could I solve: apk fix
2023-03-25 15:38:04 <Qa>   ffmpeg5-libavutil-5.1.2-r10 (no such package):
2023-03-25 15:38:04 <Qa>     required by: world[ffmpeg5-libavutil-5.1.2-r10]
2023-03-25 15:38:04 <Qa> ERROR: unable to select packages:
2023-03-25 15:38:12 <Qa> (pinephone)
2023-03-25 17:14:54 <psykose> apk del ffmpeg5-libavutil-5.1.2-r10
2023-03-25 17:15:04 <psykose> you added a string that doesn't exist into your world file
2023-03-26 11:04:23 <Ermine> When 3.18 freeze is going to happen?
2023-03-26 11:11:32 <psykose> probably a month
2023-03-26 11:29:44 <clandmeter> nlplug-findfs: recvmsg: No buffer space available
2023-03-26 11:29:52 <clandmeter> looks like I have a problem booting
2023-03-26 11:30:17 <psykose> ah
2023-03-26 11:30:26 <psykose> that looks like the too-small buffer
2023-03-26 11:30:41 <psykose> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/116 fixes it, but no release
2023-03-26 11:30:52 <psykose> by fixes i mean you can pass an arg
2023-03-26 11:31:43 <psykose> udev has used 5MB for probably a decade for that reason
2023-03-26 11:34:54 <clandmeter> interesting
2023-03-26 11:35:06 <clandmeter> so this only happens on recent kernels
2023-03-26 11:35:14 <clandmeter> it was booting fine on 3.16
2023-03-26 11:35:26 <clandmeter> and this server I have is nothing special
2023-03-26 11:39:15 <psykose> if you want my guess, the 3.16 boot was using 98% size by luck or something
2023-03-26 11:39:25 <psykose> and some minor reordering and or magical sun rays killed it
2023-03-26 11:40:06 <psykose> this whole process isn't really affected by anything but that buffer size and the kernel and processing the events (in nlplug)
2023-03-26 11:47:04 <clandmeter> psykose: thx for the link, i added my comment
2023-03-26 11:48:18 <psykose> oh nvm
2023-03-26 11:48:22 <psykose> udev is 128MB actually, no 5
2023-03-26 11:48:26 <psykose> :D
2023-03-26 11:48:30 <psykose> they just said fuck it
2023-03-26 11:48:51 <clandmeter> i hope we can this in a patch release
2023-03-26 11:49:11 <clandmeter> booting without nvme is problematic :)
2023-03-26 11:50:36 <psykose> we could just hot backport the commit into 3.17 if you really want, but you'll still have to regenerate the initrd once
2023-03-26 11:53:33 <clandmeter> the problem is the fix is not in the image
2023-03-26 11:53:46 <clandmeter> i will only generate one for them on each alpine release
2023-03-26 11:54:32 <psykose> ah yeah
2023-03-26 11:55:25 <clandmeter> thx for looking into it. ill try to convince ncopa to make a release :)
2023-03-26 11:57:37 <psykose> yeah, should indeed be part of release
2023-03-26 12:15:34 <ikke> clandmeter: fyi, the no buffer space message is relatively new, before it would just silentely fail
2023-03-26 12:15:36 <ikke> silently
2023-03-26 13:23:48 <clandmeter> Right
2023-03-26 13:24:06 <clandmeter>  well the problem is it did not yet load nvme
2023-03-26 13:24:34 <clandmeter>  else it would probably not fail
2023-03-26 13:40:13 <ikke> We had that before with a server from eqnx
2023-03-26 14:27:18 <skarnet> I honestly have no idea what's happening there or how the kernel is storing uevents, because the text of the uevents is short and there's no way there's 5 MB of uevents even with the coldplug spam
2023-03-26 14:27:43 <skarnet> why does the socket buffer need to be so huge
2023-03-26 14:27:56 <skarnet> I suspect the kernel is doing very inefficient things
2023-03-26 14:28:14 <ikke> I have no clue either
2023-03-26 14:28:31 <ikke> just that we are running into these issues where the rootfs is not found
2023-03-26 14:30:47 <minimal> perhaps add a debug/logging option so you can see all the actual events being generated?
2023-03-26 14:31:25 <ikke> I think there is
2023-03-26 14:31:45 <ikke> I mean, I recall enabling debug output
2023-03-26 14:32:23 <minimal> ah, yeah, there is a "--debug" option
2023-03-26 14:32:58 <ikke> But all you see is that the event for the disk you need is missing
2023-03-26 14:33:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325
2023-03-26 14:34:01 <minimal> ok, I was thinking of a debug option to show every uevent, so then you could boot into recovery/single mode and manually run with that option to see what's going on
2023-03-26 14:34:22 <ikke> That's exactly what I did in that issue
2023-03-26 14:34:44 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325#note_139126
2023-03-26 14:35:16 <psykose> the other magic is how udev does 128MB but it does not actually use 128MB of memory
2023-03-26 14:35:20 <psykose> so what's up with that
2023-03-26 14:36:13 <skarnet> I suppose it's not immediately committed, if the kernel needs it and can't allocate it it will requisition it by oom-killing userspace stuff
2023-03-26 14:36:33 <ikke> minimal: what I recall is that it failed on boot, but then running nlplug-findfs in the emergency shell would work
2023-03-26 14:36:48 <ikke> so some timing / race-condition / settling issue
2023-03-26 14:38:40 <minimal> ikke: looking at your info in that Issue, obviously more uevents would occur for physical machines than VMs and also more for large servers with lots of storage devices
2023-03-26 14:38:47 <skarnet> could also be that nlplug-findfs doesn't generate events for stuff it has already seen
2023-03-26 14:39:07 <ikke> minimal: certainly, but things also changed between kernel versions
2023-03-26 14:39:17 <ikke> older kernels would work fine, but newer kernels started to have issues
2023-03-26 14:39:35 <minimal> ikke: yeah well different kernel versions can have added drivers which result in extra events
2023-03-26 14:39:47 <ikke> yes, that makes sense
2023-03-26 14:42:30 <minimal> and newer systems likely also have more cores so more uevents, etc
2023-03-26 15:16:41 <kaathewise> Good day!  In APKBUILD, what is the difference between the Maintainer and the Contributor fields?
2023-03-26 15:16:55 <psykose> the former is the maintainer
2023-03-26 15:16:59 <psykose> the latter does not mean or do anything
2023-03-26 15:17:34 <kaathewise> And the maintainer is the person who creates and updates the build, right?
2023-03-26 15:17:44 <psykose> most of the time
2023-03-26 15:17:49 <kaathewise> Got, it, thanks!
2023-03-26 15:18:11 <kaathewise> And one last question about it, the name must be the real name, right?
2023-03-26 15:20:22 <psykose> no
2023-03-26 15:21:27 <kaathewise> Oh, so it is fine to use a pseudonim/nickname?
2023-03-26 15:22:15 <psykose> ye
2023-03-26 15:22:29 <kaathewise> TY!
2023-03-26 16:59:07 <clandmeter> ikke: does providing the module on cmdline fix the issue?
2023-03-26 17:00:09 <ikke> clandmeter: from what I recall, not really
2023-03-26 17:00:23 <ikke> The fix was increasing the buffer size
2023-03-26 17:01:57 <clandmeter> If I load nvme manually it works but init already stopped ofc.
2023-03-26 17:03:22 <ikke> clandmeter: when it happened, it would work if I ran nlplug-findfs manually in the recovery shell
2023-03-26 17:05:08 <clandmeter> What would work?
2023-03-26 17:06:04 <ikke> It would get the proper events and find the correct rootfs
2023-03-26 17:06:19 <ikke> In that case, it was not only nvme but also lvm 
2023-03-26 17:06:23 <ikke> that it required
2023-03-26 17:06:28 <clandmeter> Ok
2023-03-27 10:50:27 <ncopa> psykose: so you have an url to where udev sets socket buf size to 128MB instead of 5?
2023-03-27 12:03:03 <bjorn3_gh> i would like to contribute a minor change to abuild's newapkbuild. is there a contributor guide and are there some general rules i need to follow like needing to sign off changes?
2023-03-27 12:05:12 <ikke> bjorn3_gh: no sign-off required, but test coverage, if possible, is
2023-03-27 12:06:12 <bjorn3_gh> alright
2023-03-27 12:06:51 <bjorn3_gh> i can't find any tests for newapkbuild though. all tests i could find seem to be for abuild itself or other tools
2023-03-27 12:35:23 <bjorn3_gh> pr up. tested it using a dummy package
2023-03-27 16:27:30 <psykose> ncopa: there's a link in the merge request in mkinitfs
2023-03-27 16:50:14 <Qa> psykose, thanks! that solved it!
2023-03-27 16:50:33 <psykose> what did solved what
2023-03-27 17:21:51 <skarnet> take yes for an answer and don't look a gift compliment in the mouth
2023-03-27 17:21:58 <skarnet> that solved it, okay?
2023-03-28 07:59:47 <psykose> ncopa: if you want some motivation to ship a release with the mkinitfs changes, there was a nothingburger openssl cve :p
2023-03-28 08:00:06 <psykose> https://nvd.nist.gov/vuln/detail/CVE-2023-0464
2023-03-28 08:10:55 <lucidiot> mmm borgar
2023-03-28 08:11:09 <Ermine> borgir
2023-03-28 09:18:36 <midasi> psykose: could you please review MR !20664? We fixed and commented all issues in the meantime
2023-03-28 09:20:08 <psykose> libc6-compat looks like it's there
2023-03-28 09:20:21 <midasi> yes it is necessary for the build
2023-03-28 09:20:28 <psykose> no :)
2023-03-28 09:20:48 <midasi> we requested a new release without this dependency 
2023-03-28 09:22:06 <midasi> but in the meantime we should leave it there
2023-03-28 09:32:19 <psykose> i don't know how many times you want me to repeat 'no'
2023-03-28 09:32:32 <psykose> you would probably find it easier to manage your own downstream repository where you can do whatever you want
2023-03-28 11:26:21 <nmeum> https://dev.alpinelinux.org/buildlogs/build-edge-x86/community/inkscape/inkscape-1.2.2-r1.log
2023-03-28 11:26:25 <nmeum> > >>> ERROR: inkscape*: libinkscape_base.so: path not found
2023-03-28 11:26:45 <nmeum> is this intentional? also: shouldn't abuild exit with a non-zero exit status if find_so_files() fails?
2023-03-28 11:30:45 <psykose> i had an issue open for that ages ago
2023-03-28 11:30:55 <psykose> in this specific case it is found however
2023-03-28 11:31:03 <psykose> it is the detection that just doesn't see it
2023-03-28 11:33:43 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10085
2023-03-28 11:33:56 <psykose> in this specific case it's weird because there's nothing actually wrong
2023-03-28 11:34:04 <psykose> inkscape has an rpath of ../lib/inkscape
2023-03-28 11:34:08 <psykose> libinkscape_base.so is in there
2023-03-28 11:34:11 <psykose> and it has an soname of libinkscape_base.so
2023-03-28 11:34:17 <psykose> everything matches and it runs
2023-03-28 11:34:39 <psykose> there's zero issues here except for spurious warnings
2023-03-28 11:35:45 <psykose> ah, it is the same as the other case
2023-03-28 11:35:45 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/41766#note_277212
2023-03-28 11:35:51 <psykose> i guess it just doesn't read $ORIGIN
2023-03-28 11:36:26 <psykose> there's also another tracing issue in the same vein when the SONAME does not match the file, https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10092
2023-03-28 11:38:34 <nmeum> hm yea, I am also not sure why inkscape complains about libinkscape_base.so. I guess I need to debug this further. I think it is also a bug that abuild doesn't exit when find_so_files() fails, because imho it should in the general case
2023-03-28 11:39:19 <psykose> you mean it fails at runtime?
2023-03-28 11:40:06 <psykose> exiting is correct and fine by me, would just like to fix the ORIGIN thing first because there's no easy workarounds for it
2023-03-28 11:40:41 <psykose> nobody is doing anything wrong and the only way to workaround it is to actually put things in the wrong path, or to hack different rpaths into things, or disable all tracing, so it's a pretty difficult build failure to fix when it's meaningless
2023-03-28 11:41:29 <nmeum> yep, the ORIGIN thingy should be fixed first probably
2023-03-28 11:41:39 <psykose> i can't reproduce inkscape failing to start if that's what you meant
2023-03-28 11:41:46 <nmeum> no, it doesn't fail to start
2023-03-28 11:41:50 <psykose> ah
2023-03-28 11:41:52 <psykose> okay :)
2023-03-28 11:42:17 <nmeum> I just mean: `abuild -r` should exit with a non-zero exit status if it fails to find an .so in find_so_files() fails because that usually indicates that something is wrong
2023-03-28 11:42:34 <psykose> yep
2023-03-28 11:42:46 <psykose> it would especially auto crash every libc.so.6 case which is nice
2023-03-28 11:48:00 <midasi> psykose: perhaps you should start to explain your 'no'. What issue do you have with the dependency?
2023-03-28 11:57:02 <ovf> abuild does something silly with git when run in an aports tree with uncommited APKBUILD
2023-03-28 11:59:34 <psykose> ovf: what's the something silly? all i know is the SOURCE_DATE_EPOCH calculation takes forever from the git calls for it
2023-03-28 12:00:07 <ovf> that must be it, takes seconds on my box
2023-03-28 12:01:26 <psykose> i usually put git=true at the top where it checks it in /usr/bin/abuild by hand and forget about it
2023-03-28 12:01:37 <psykose> was meaning to debug a bit why it takes so long but that takes time
2023-03-28 12:03:14 <ovf> ok, i might take a look a bit later. incidentally, why is abuild split (and not in an obvious way) between /usr/bin/abuild and /usr/share/abuild/functions.sh?
2023-03-28 12:05:54 <psykose> hmm
2023-03-28 12:06:03 <psykose> didn't occur to me to call it split :D
2023-03-28 12:06:05 <psykose> i guess it is
2023-03-28 12:06:39 <psykose> i had it mentally labelled as "that file with the defines"
2023-03-28 12:08:18 <ovf> typically i'd expect the /bin to be the driver and the other one to be logic, but that's not quite the case here
2023-03-28 12:09:12 <ovf> anyway, here's vmtouch: http://0x0.st/Hoxt.diff
2023-03-28 12:12:05 <psykose> that's not a custom licence
2023-03-28 12:12:48 <ovf> ianal, and it doesn't seem to be byte-identical (modulo copyright line) to a 3-clause bsd
2023-03-28 12:20:38 <ovf> thanks! (but i hope you've received advice from your lawyer confirming this licence is indeed identical to a 3-clause bsd)
2023-03-28 12:24:09 <psykose> i can confirm it is not identical (the difference is 'and contributors')
2023-03-28 12:24:35 <psykose> i can also confirm license= is not legally binding to anything and does not matter, and that almost every other distro does not even use spdx and just writes 'bsd' or 'gpl' on everything
2023-03-28 12:24:36 <psykose> :p
2023-03-28 12:25:21 <psykose> there are a million bsd variants with a word changed so it's a bit of a soup
2023-03-28 12:26:45 <psykose> if i had to start from scratch and do it differently, i would probably require always installing the licence and omitting license= entirely
2023-03-28 12:27:36 <psykose> it is inherently a useless field of metadata, since you need the whole licence with all the copyright etc info for it to do anything, and nobody cares about that except lawyers, people that get paid, and people with too much time
2023-03-28 12:27:43 <psykose> which in linux distros is usually nobody
2023-03-28 12:27:43 <PureTryOut> Oh agreed there. Arch installs the license for every package and that seems like a good way to do it
2023-03-28 12:27:50 <ovf> fair enough, although i guess license= does make auditing easier (i'm guessing it's a field in apk list's output for a reason)
2023-03-28 12:28:16 <psykose> it doesn't make it easier, is the point
2023-03-28 12:28:31 <psykose> you cannot rely on it unless someone gave you a guarantee that it's correct
2023-03-28 12:28:56 <psykose> and if you actually rely on it (read: you are not just 'a user', but you are some company reshipping alpine outputs), then the field is useless to you
2023-03-28 12:29:22 <psykose> since you need the actual file anyway
2023-03-28 12:29:31 <psykose> (for things with copyright attribution, etc)
2023-03-28 12:30:29 <psykose> and since this isn't a company and everything is open source, and none of use get paid.. all of it is a waste of time and nobody cares :p
2023-03-28 12:31:15 <ovf> indeed, i was making the assumption that there is some (implied) guarantee of the correctness of license=. i'm very happy not to care either. :-)
2023-03-28 12:31:19 <psykose> admittedly just installing the license always is very low effort, but it's a bit late for that i guess
2023-03-28 12:31:30 <psykose> well, the 'guarantee' is "i check it"
2023-03-28 12:31:44 <psykose> is that a warranty? no.. so you can't rely on it
2023-03-28 12:31:49 <psykose> you can see how it follows on from there
2023-03-28 12:32:08 <psykose> if you're a user then you don't care because it's inherently a waste of time like all licencing is :p
2023-03-28 12:32:14 <psykose> or maybe that's the anarchist in me
2023-03-28 12:33:25 <ovf> i definitely don't care about licenses of end-user stuff i've installed on my personal machine
2023-03-28 12:33:44 <psykose> i wouldn't mind starting to install licenses i guess, but i would prefer if there was just a quick tool to put it in the correct place (alicense $file, that puts it in /usr/share/licenses/$subpkgname/$file), then i can just sprinkle it in
2023-03-28 12:34:01 <PureTryOut> Yes please!
2023-03-28 12:34:29 <psykose> the last time someone gave us shit for this was the libffi author, that libffi doesn't ship the licence
2023-03-28 12:34:32 <psykose> and you know the funny part
2023-03-28 12:34:53 <psykose> i'm pretty sure at the time the tarballs of libffi didn't have the licence either :p
2023-03-28 12:35:17 <ovf> quick test (without looking!): is e.g. 'amove' in /usr/bin/abuild or /usr/share/abuild/functions.sh? :-)
2023-03-28 12:35:30 <psykose> former
2023-03-28 12:36:25 <psykose> or maybe that was me dreaming and i looked in the wrong place at the time
2023-03-28 12:36:44 <ovf> no, that's correct. but i guessed wrong
2023-03-28 12:39:03 <ovf> +1 for alicense. it can also auto set license= for compatibility, but that will probably do more harm than good
2023-03-28 12:39:57 <psykose> nah, that can stay manual
2023-03-28 12:40:09 <psykose> i can already picture the process though
2023-03-28 12:40:16 <psykose> i would write that in ~15 minutes
2023-03-28 12:40:23 <psykose> then i would spend 3 hours trying to think of tests
2023-03-28 12:40:32 <psykose> then i would get to experience some implementation bikeshed
2023-03-28 12:40:37 <psykose> then it would sit there for 6 months
2023-03-28 12:40:44 <psykose> so on second thought, someone else can write it :p
2023-03-28 13:05:19 <ikke> And then someone complains that the license is shipped in a separate doc subpackage, not the actual package 
2023-03-28 13:06:36 <psykose> the kinda-nice design would be $pkgname-licenses with install_if on some random shit
2023-03-28 13:06:56 <psykose> the rest is an implementation detail that should not be looked at :p you see, the binaries autoinstall the licence so it's okay...
2023-03-28 13:08:36 <ikke> Is it worth the overhead? 
2023-03-28 13:08:48 <ikke> At that point just ship it with the origin package 
2023-03-28 13:11:20 <psykose> dunno, the overhead is kinda invisible in most ways (if you mean bigger index + install_if rules)
2023-03-28 13:11:39 <psykose> invisible as in nobody calculates it
2023-03-28 13:13:06 <ikke> I need to worry about that overhear 
2023-03-28 13:13:55 <ikke> At least, until we changed the builder architecture
2023-03-28 13:26:19 <psykose> i'm not sure how builder architecture would affect that specifically?
2023-03-28 13:26:56 <psykose> i do agree just keeping it in -doc is fine, idc much about the semantics
2023-03-28 13:26:59 <psykose> (or just main package)
2023-03-28 13:27:12 <psykose> ((or more seriously, nobody will do this anyway, so there aren't any changes anyway))
2023-03-28 13:27:55 <psykose> the apkindexes are megabytes in size so i don't see it as a size thing, what else would affect the builders
2023-03-28 13:31:22 <ovf> ooh, i just learned what abuild deps does. slick!
2023-03-28 14:57:37 <ovf> do people maintain their own repos? e.g. here's slade (doom wad editor): http://0x0.st/Hog1.diff but i seriously doubt it has to go in aports
2023-03-28 15:09:20 <psykose> yeah
2023-03-28 16:23:17 <ayakael> @ovf Many do! Here is jirutka's who uses Github infra to build their packages https://github.com/jirutka/user-aports Myself, I use my Gitlab instance to build and host my repo: https://lab.ilot.io/ayakael/user-aports
2023-03-28 16:27:58 <psykose> hmm, why do you keep around stuff that is also in aports
2023-03-28 16:28:13 <psykose> git-annex, electron, ..
2023-03-28 16:28:28 <psykose> does it get handled differently
2023-03-28 16:28:34 <psykose> neat setup :D
2023-03-28 16:28:52 <psykose> for electron specifically, you should note i only keep the latest tarball since they're pretty big
2023-03-28 16:34:05 <ayakael> Thanks :) Mostly for backporting. By principle, I don't like having mixed release repositories on the same system so for anything that's stuck in testing I build it for the Alpine releases I target. As for git-annex, and other packages I maintain, I first build the packages on my infra, and then push it out to alpine. My Gitlab is sort-of a staging
2023-03-28 16:34:05 <ayakael> area since I have my own homelab at home.
2023-03-28 16:36:05 <psykose> ahhhh
2023-03-28 16:36:10 <psykose> i see, you rebuild into stable
2023-03-28 16:36:18 <psykose> makes sense :)
2023-03-28 16:37:14 <ayakael> I also plan on getting pipelines up and running that will automatically create a merge-request whenever one of my packages get an update. If the build fails, then I intervene. If it's a success it's automatically pushed to my repo, and I an MR is pushed to Alpine.
2023-03-28 16:37:40 <orbea> what if it builds, but doesn't run?
2023-03-28 16:37:42 <ovf> ayakael: thanks!
2023-03-28 16:37:53 <ayakael> check() is your friend :)
2023-03-28 16:38:32 <orbea> doesn't run might be more subtle than a segfault or exiting with an error code
2023-03-28 16:40:16 <psykose> TIL binaries don't run sometimes
2023-03-28 16:40:21 <psykose> i thought everything just worked all the time
2023-03-28 16:40:27 <orbea> :P
2023-03-28 16:40:33 <ayakael> x) 
2023-03-28 16:40:40 <ayakael> Quite right! I imagine the level of automation will depend on the package and the extent of the testing suite. I'm stilling designing this in my mind
2023-03-28 16:40:44 <ayakael> still*
2023-03-28 16:41:05 <orbea> its a neat idea, I was just wondering how that would work :)
2023-03-28 16:41:10 <psykose> still less to do if everything autoupdates and then you test it first
2023-03-28 16:51:05 <ayakael> The way I imagine the workflow is I have a Git clone of, for example, git-annex. Every month, they push an update via a tag.  My Gitlab would then pull that clone, and the repo would point to a Gitlab CI file that, on new tags, starts a pipeline. This clones my `user-aports` repo, updates the APKBUILD for git-annex to new version, and pushes an MR
2023-03-28 16:51:05 <ayakael> with the new update. On new MRs, `user-aports` starts up a pipeline (very much like Alpine's MR CIs) that builds the packages. On success, I have the option to push build artifacts to `apk-repo` which is backed by git-lfs. 
2023-03-28 17:01:20 <ayakael> I've done the user-aports to apk-repo part of the workflow. Now it's about creating the gitlab CI stuff for each package that I maintain. The idea being to automate as much as possible the repetetive tasks so that for each update I just have to check the diff, check the test suite, and push a button. For releases where I want there to be backports
2023-03-28 17:01:20 <ayakael> for previous releases (dotnet, for example), the MR for that is also automatically created and update built. 
2023-03-28 17:01:49 <ayakael> Also, gitlab is hella fun. 
2023-03-28 17:20:17 <ayakael> ovf: I went ahead and added your aport to my repo for the hell of it, so available at https://lab.ilot.io/ayakael/apk-repo. It's both on 3.17 and edge branches.
2023-03-28 17:20:33 <ayakael> https://lab.ilot.io/ayakael/repo-apk *
2023-03-28 17:23:57 <ovf> ayakael: thanks! not that i expect this to be useful to anyone
2023-03-28 17:25:14 <ayakael> Didn't take more than a minute haha :)
2023-03-28 18:27:20 <Piraty> psykose: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198#note_1843659
2023-03-29 01:55:42 <anjan> Hi, can someone take a look at this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/38362?commit_id=74d05f7b6e31b9e3abf39c0af4632292f7821ff8
2023-03-29 01:55:49 <anjan> it's been open for a while now
2023-03-29 01:55:58 <anjan> and is needed for a Sxmo release
2023-03-29 09:18:29 <ncopa> merged
2023-03-29 09:45:16 <ncopa> i think we should make alpine releases today
2023-03-29 13:46:19 <minimal> ncopa: will the releases you are planning for today include e2fsprogs 1.47.0? If so then there may be problems...
2023-03-29 13:49:59 <tomalok> runc needs a security update too, i should have one backported to 3.17 this us/pacific morning
2023-03-29 13:51:21 <ncopa> the release today will have e2fsprogs 1.46.6
2023-03-29 13:51:58 <ncopa> i can do runc release now
2023-03-29 13:52:13 <ncopa> its not critical for the release though, sice the release images does not include runc
2023-03-29 13:52:20 <minimal> ncopa: ok. I'm investigating/testing currently whether e2fsprogs 1.47+ will have implications/problems for the forthcoming 3.18 release
2023-03-29 13:53:48 <tomalok> ncopa, then focus on the release image, i'll take care of runc 
2023-03-29 13:54:16 <ncopa> thanks, to both of you
2023-03-29 14:03:39 <ovf> are people here significantly opposed to CONFIG_IKCONFIG_PROC, at least on the 'big' targets, like x86_64?
2023-03-29 14:05:00 <ovf> sorry, i'm blind, it's behind a CONFIG_IKCONFIG=m (modprobe configs)
2023-03-29 14:05:31 <ovf> i'd probably like CONFIG_IKCONFIG=y instead
2023-03-29 14:07:28 <minimal> ovf: as it is built as a module then what's the issue? People who don't want it (to save memory don't have it, those that want it can add it to their /etc/modules etc file
2023-03-29 14:09:26 <ovf> it being in a module (on a filesystem) does not bring anything over /boot/config-* -- i.e., there is no guarantee it's there/it pertains to the running kernel/etc.
2023-03-29 14:10:14 <minimal> ovf: no guaranteed? the module is created when the associated kernel is built
2023-03-29 14:10:48 <minimal> so the only time there's no "match" is if you have upgraded the kernel package but not yet rebooted (which is an issue not specific to this 1 module)
2023-03-29 14:13:18 <ovf> yes, that would be the most common reason for a mismatch.
2023-03-29 14:15:42 <ikke> But that's not a reason to make it a built-in 
2023-03-29 14:16:46 <ncopa> CONFIG_IKCONFIG=y is more convenient, but that not a valid reason to enable it as 'y'
2023-03-29 14:27:09 <ovf> fair enough
2023-03-29 14:51:31 <tomalok> ncopa: how far back will we be releasing?
2023-03-29 14:51:48 <ncopa> 3.14.10
2023-03-29 14:52:30 <tomalok> thx.  lmk when to start building the cloud images
2023-03-29 14:52:35 <ncopa> See https://alpinelinux.org/releases/
2023-03-29 14:52:43 <ncopa> for what release branches we support
2023-03-29 14:53:08 <tomalok> wasn't sure how far back the issue necessitating the release was
2023-03-29 14:53:17 <ncopa> seems like releases are uploaded so you can go ahead
2023-03-29 14:54:52 <ncopa> does those look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.14.10-3.15.8-3.16.5-released.html
2023-03-29 14:55:00 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.17.3-released.html
2023-03-29 14:55:26 <tomalok> builder has a dependency on https://alpinelinux.org/releases.json - when that's ready i can start
2023-03-29 14:55:32 <ncopa> aha
2023-03-29 14:56:00 <ncopa> as soon the two pages i linked to here up^^^ is reviewed and pushed
2023-03-29 14:57:26 <ncopa> psykose: it just amazes me the good job you do! thank you! (specifically for the openssl fixes this time)
2023-03-29 14:57:53 <ncopa> for example: https://security.alpinelinux.org/vuln/CVE-2023-0465 is all green
2023-03-29 14:58:54 <ncopa> tomalok: if you please could have a quick look at the two wwwtest links above
2023-03-29 14:59:11 <tomalok> ncopa: i've looked them over, they lgtm
2023-03-29 14:59:15 <ncopa> thanks!
2023-03-29 14:59:37 <ncopa> pushed to production branch now
2023-03-29 14:59:46 <ncopa> the releases.json should show in a few seconds
2023-03-29 15:00:30 <tomalok> yep i see it now
2023-03-29 15:03:55 <tomalok> starting the build of non-edge cloud images
2023-03-29 15:20:41 <ayakael> Out of curiosity, how can I add my packages to the secfix tracker? For instance, https://security.alpinelinux.org/vuln/CVE-2023-21808 was fixed with dotnet v7.0.103.
2023-03-29 15:21:47 <ikke> ayakael: add a secfixes section to your apkbuild
2023-03-29 15:22:04 <ikke> Apparently there is no CPE in the CVE
2023-03-29 15:22:27 <ikke> Which is what normally matches the CVE to a package
2023-03-29 15:24:54 <ayakael> I see. I do have a secfix section, but as the package name diverges from other distros it makes sense that it isn't detected automatically
2023-03-29 15:25:48 <ikke> nvd.nist.gov is slow
2023-03-29 15:27:42 <ikke> Let me import the 2023 nvd feed manually, see if it gets the CPE then
2023-03-29 15:35:54 <ikke> ayakael: ok, the CPE's are the now
2023-03-29 16:05:50 <ikke> ncopa: I've posted the release on fosstodon
2023-03-29 16:06:14 <ncopa> ikke: thank you!
2023-03-29 16:07:22 <ncopa> ikke: do you have access to the twitter account? maybe you could post there too
2023-03-29 16:07:29 <ikke> I have not
2023-03-29 16:07:39 <ncopa> let me fix that for you
2023-03-29 16:23:55 <skarnet> ncopa: grats on the releases!
2023-03-29 16:37:06 <ncopa> skarnet: thanks!
2023-03-29 17:27:56 <PabloCorreaGomez[m]> Hi ikke: the appstream generator has been crashing for like a month. I am quite sure it's something related to https://github.com/ximion/appstream-generator/issues/100, but I had lots of issues reproducing locally, since I believe the problem has to be with the massive parallelization in the server, and the max I have is 16 cores. Would it be allowed, and is there any way that I can get a connection to the container that runs
2023-03-29 17:27:57 <PabloCorreaGomez[m]> it? Otherwise a likely ugly fix would be to limit the CPU resources of the container to just a couple of cores
2023-03-29 17:28:11 <PabloCorreaGomez[m]> Or maybe you want to look into debugging it in detail. But if I have to do it, I cannot do it without having some sort of access where I can get some nice stack trace, recompile and play around
2023-03-29 17:28:50 <PabloCorreaGomez[m]> It's not urgent, since I'm going on holidays soon, but I just realized I had posted this like a week ago in Libera instead of here xD
2023-03-29 20:31:52 <psykose> ncopa: thanks :)
2023-03-29 21:41:53 <psykose> ncopa: also your email announcements don't handle unicode correctly and every unicode letter is just '*'
2023-03-29 23:39:54 <pj> psykose: can you check checksum for scdoc?
2023-03-29 23:41:24 <pj> looks like sr.ht is having same issue that github had with git changing how it generates checksums
2023-03-29 23:43:59 <pj> https://tpaste.us/yYYp
2023-03-29 23:44:34 <psykose> indeed it did
2023-03-29 23:44:39 <psykose> idk what you want me to about that though
2023-03-29 23:44:48 <pj> fix the checksum?
2023-03-29 23:45:13 <pj> or yell at ddevault to fix sr.ht :P
2023-03-29 23:45:16 <pj> or both
2023-03-29 23:45:26 <psykose> the former doesn't matter and you're welcome to do the latter
2023-03-29 23:46:04 <pj> why the former doesn't matter?
2023-03-29 23:46:10 <pj> it fails builds
2023-03-29 23:46:29 <psykose> doesn't look like anything is failing in aports to me
2023-03-29 23:46:35 <pj> it fails for me
2023-03-29 23:46:49 <pj> and will fail for anyone else
2023-03-29 23:54:10 <pj> why the rename tho
2023-03-30 00:18:07 <abby> i'm not seeing a checksum change with soju archives from srht
2023-03-30 00:20:15 <psykose> there is
2023-03-30 00:20:25 <psykose> the new 0.6 one is from way after git-archive changes
2023-03-30 00:20:29 <psykose> if you check 0.5.2 it is
2023-03-30 00:20:38 <psykose> -08aff63b198583820685dd46ee4c0f8a02e3afeb32b077a14cff375ff3fba8ebfe6c2934e79dffb294c79212031d63032c16e63c5d14854433889699adb272f8  soju-0.5.2.tar.gz
2023-03-30 00:20:43 <psykose> new one is cd34e3d72591cb41aa5d45e3275629ddfb8a0d2752f398add58aead90ce82db500dabf6095db13faf75c6b17d31e5fb868ca5a9421b67a955574837c4c85e790 if you fetch
2023-03-30 00:20:58 <abby> yeah i checked both versions
2023-03-30 00:21:11 <psykose> which checksum do you get
2023-03-30 00:21:28 <psykose> in sha512 i guess since i can't compare historical of anything else
2023-03-30 00:21:52 <abby> sha256 15:checksum=243e97e89d1ab9db0757b4d9e2181bf9602bf1ca277aba665417ea788ef82d9b
2023-03-30 00:21:58 <psykose> pj: because they're cached, only the old archive exists for the edge builders and it doesn't fetch the new ones of the same nbame
2023-03-30 00:22:22 <psykose> abby: sure i'll pull some files..
2023-03-30 00:23:19 <psykose> which version is that
2023-03-30 00:24:14 <abby> 5 2
2023-03-30 00:24:34 <handlerug> I think sr.ht "fixed" this as in they upgraded their systems to a newer alpine version which included a newer busybox version which had a change for the gzip applet to be compatible with the gnu version
2023-03-30 00:25:01 <handlerug> so the checksums have changed but now they should match the ones you see on github/gitlab/etc
2023-03-30 00:25:20 <handlerug> but obviously the old checksums are no longer valid now
2023-03-30 00:25:37 <handlerug> this happened a while ago
2023-03-30 00:25:39 <psykose> abby: i can't reproduce that checksum with sha256sum for either the new or old tarball :p
2023-03-30 00:26:56 <abby> 243e97e89d1ab9db0757b4d9e2181bf9602bf1ca277aba665417ea788ef82d9b  -
2023-03-30 00:26:56 <abby> same checksum for the archive from when it was built: curl -s https://sources.voidlinux.org/soju-0.5.2/soju-0.5.2.tar.gz | sha256sum -
2023-03-30 00:26:57 <abby> curl -s 'https://git.sr.ht/~emersion/soju/refs/download/v0.5.2/soju-0.5.2.tar.gz' | sha256sum -
2023-03-30 00:27:00 <abby> 243e97e89d1ab9db0757b4d9e2181bf9602bf1ca277aba665417ea788ef82d9b  -
2023-03-30 00:31:07 <psykose> i can reproduce that, but it doesn't match soju/archive/version.tar.gz
2023-03-30 00:31:18 <psykose> i guess refs/download is something else?
2023-03-30 00:32:24 <psykose> e.g. https://git.sr.ht/~emersion/soju/archive/v0.5.2.tar.gz
2023-03-30 00:32:31 <psykose> the download link on the refs page gives you that
2023-03-30 00:32:32 <abby> yeah, i think its a manual archive
2023-03-30 00:32:42 <psykose> it's not linked anywhere
2023-03-30 00:33:02 <psykose> ah
2023-03-30 00:33:08 <psykose> it's on here https://git.sr.ht/~emersion/soju/refs/v0.6.0
2023-03-30 00:33:10 <psykose> and nowhere else
2023-03-30 00:33:41 <abby> ok nvm, let me try scdoc
2023-03-30 00:34:00 <abby> yeah, it's borken
2023-03-30 17:52:59 <donoban> is normal that I have an error boooting alpine-standard-3.17.3-x86_64.iso with 'qemu-system-x86_64 -cdrom alpine-standard-3.17.3-x86_64.iso '?
2023-03-30 17:53:46 <ikke> That's not really a question we can answer without more details
2023-03-30 17:54:27 <donoban> https://postimg.cc/kVcq0FT8
2023-03-30 17:54:47 <donoban> same command with alpine-virt-3.17.3-x86_64.iso works
2023-03-30 17:55:05 <ikke> That's not normal
2023-03-30 17:55:21 <psykose> did you forget to raise the memory limit
2023-03-30 17:55:29 <psykose> that looks like oom of like 128mb from the image or whatever
2023-03-30 17:55:36 <psykose> and virt is smaller so it fits
2023-03-30 17:55:39 <donoban> ahh, ok
2023-03-30 17:55:54 <psykose> -m 512 should be fine i think, but idk
2023-03-30 17:56:08 <donoban> let's try 1024
2023-03-30 17:56:24 <donoban> yeah it's booting, thanks
2023-03-30 17:57:42 <psykose> it's probably a consequence of the whole thing in memory thing as opposed to the other style of mounting an image
2023-03-31 07:00:14 <ncopa> heh, I think the limit is around 180MB RAM to be able to boot
2023-03-31 08:31:41 <donoban> is worth to add some check&warning about it?
2023-03-31 08:35:53 <donoban> ey ncopa I would like to create some tests for pam configuration so things like #14710 could be easily detected
2023-03-31 08:36:09 <donoban> do you think that https://github.com/ncopa/alpine-installer-testsuite/tree/main/tests could be a good place/way for doing it?
2023-03-31 08:36:54 <umk3[m]> I also have a problem with linux-pam, now elogind cannot recognize a session at shell login
2023-03-31 08:37:40 <donoban> uhM, are you running edge right? linux-pam-1.5.2-r8 ?
2023-03-31 08:37:45 <umk3[m]> yes
2023-03-31 08:38:18 <umk3[m]> no session and therefore elogind not setting up XDG_RUNTIME_DIR either
2023-03-31 08:38:33 <donoban> do you se some login manager?
2023-03-31 08:38:38 <umk3[m]> no nothing
2023-03-31 08:38:40 <donoban> /s/se/use
2023-03-31 08:39:10 <donoban> I'm using seatd here but I'm installing a VM for test gdm
2023-03-31 08:39:20 <umk3[m]> tried installing "pam-rundir" package but no help
2023-03-31 08:40:46 <ptrc> add util-linux-login, relogin
2023-03-31 08:42:50 <umk3[m]> nothing
2023-03-31 08:43:52 <umk3[m]> it is preferred to use util-linux-login rather than shadow-login ?
2023-03-31 08:44:07 <donoban> if it uses shadow-login it will ignore pam
2023-03-31 08:45:22 <donoban> wops no, is that the busybox login?
2023-03-31 08:46:11 <umk3[m]> I have no idea what that means :P I'm very lost here
2023-03-31 08:46:35 <umk3[m]> but the real thing is that before upgrading linux-pam everything worked perfectly hah
2023-03-31 08:46:47 <donoban> alpine as default doesn't use pam, but it seems a busybox logi
2023-03-31 08:46:58 <donoban> i confused it with shadow-login
2023-03-31 08:48:06 <donoban> so you log on a tty with 'login' and then run a desktop like 'sway' or 'dbus-run-session...' ?
2023-03-31 08:48:26 <umk3[m]> dbus-run-session -- labwc
2023-03-31 08:49:26 <donoban> I thnk that the probem is on /etc/pam.d/login
2023-03-31 08:49:32 <donoban> it has session include base-session-noninteractive
2023-03-31 08:49:40 <donoban> could you change it to session include base-session-noninteractive
2023-03-31 08:49:42 <donoban> sorry
2023-03-31 08:49:54 <donoban> could you change it to base-session?
2023-03-31 08:49:59 <umk3[m]> yes sure, let me try!
2023-03-31 08:50:28 <donoban> it seems changed on last commit
2023-03-31 08:52:48 <umk3[m]> nothing, but I'll keep using shadow-login and read what changed on last commit
2023-03-31 08:54:09 <donoban> uhm.. it semes that both shadow-login&util-linux-login rely on same /etc/pam.d/login
2023-03-31 08:54:35 <donoban> could you tpaste your /etc/pam.d/login and /etc/pamd.d/base-session?
2023-03-31 08:56:20 <umk3[m]> cannot paste but base-session file has: base-session-noninteractive pam_rundir pam_elogind pam_ck_connector and pam_turnstile
2023-03-31 08:57:16 <donoban> it seems fine
2023-03-31 08:57:37 <umk3[m]> obviously removing noninteractive from that locked me out hah
2023-03-31 08:57:41 <donoban> you can remove the first - on the lines
2023-03-31 08:57:48 <donoban> so it will send something to syslog
2023-03-31 08:57:49 <umk3[m]> ok
2023-03-31 08:57:53 <donoban> if fails
2023-03-31 08:59:05 <donoban> uhM.
2023-03-31 08:59:23 <donoban> nothing logged here
2023-03-31 08:59:33 <donoban> maybe it needs enabling debug somewhere
2023-03-31 08:59:41 <umk3[m]> i'm getting some errors
2023-03-31 08:59:49 <donoban> ohh nice
2023-03-31 08:59:51 <donoban> what says?
2023-03-31 09:00:44 <umk3[m]> let me upload the log
2023-03-31 09:00:48 <donoban> ok
2023-03-31 09:01:17 <donoban> maybe psykose doesn't expect that someone wants to run a desktop when logged via tty
2023-03-31 09:01:58 <umk3[m]> possibly
2023-03-31 09:03:12 <donoban> I'm logged via 'agetty -l' so I suppose that pam is not running, just setting XDG.. via some profile script
2023-03-31 09:03:12 <umk3[m]> https://termbin.com/zfns
2023-03-31 09:05:37 <donoban> PAM adding faulty module: /lib/security/pam_rundir.so -> is because pam_rundir.so doesn't exist?
2023-03-31 09:05:41 <ptrc> donoban: i think that agetty -l runs the login executable, but not sure
2023-03-31 09:06:03 <ptrc> also, pam-rundir is provided by a package with the same name
2023-03-31 09:06:33 <donoban> I wonder if the problem is that elogin complains about some dirs already existing
2023-03-31 09:06:48 <donoban> and it enforces some policy about creating/destroying the dirs when the session starts/ends
2023-03-31 09:06:54 <donoban> could you try with a full reboot?
2023-03-31 09:07:16 <donoban> or remove /run/user
2023-03-31 09:07:19 <donoban> user is your username?
2023-03-31 09:07:23 <umk3[m]> yes sure, I'm trying different setups
2023-03-31 09:07:37 <umk3[m]> no it's xkrz here
2023-03-31 09:08:00 <donoban> ptrc: I feel that I had to create that profile script when I set 'aggety -l' on inittab
2023-03-31 09:08:18 <donoban> uhM
2023-03-31 09:08:25 <umk3[m]> brb
2023-03-31 09:08:32 <donoban> I don't remeber how elogin hadles that, it uses /run/user/<uid>?
2023-03-31 09:09:46 <donoban> lol
2023-03-31 09:10:09 <donoban> I just noticed that I was trying busybox 'login' and expecting some pam messages on syslog :D
2023-03-31 09:10:13 <umk3[m]> yes I believe it's like that
2023-03-31 09:15:49 <donoban> so rebooting didn't work?
2023-03-31 09:16:14 <umk3[m]> nope, I tried removing the user directory just in case to see if elogind creates it back
2023-03-31 09:16:20 <umk3[m]> I'll keep trying things :P
2023-03-31 09:18:28 <umk3[m]> I believe the 'faulty module' errors showed when I removed pam-rundir
2023-03-31 09:19:26 <donoban> you ignore them
2023-03-31 09:22:34 <donoban> you can*
2023-03-31 09:22:49 <umk3[m]> yes
2023-03-31 09:24:55 <donoban> I would worry about Mar 31 05:59:22 navi authpriv.err login[3153]: pam_elogind(login:session): Failed to create session: File exists
2023-03-31 09:25:14 <umk3[m]> i'll see if I can replicate that
2023-03-31 09:25:26 <donoban> ok
2023-03-31 09:37:15 <umk3[m]> it stopped showing after removing /run/user
2023-03-31 09:37:27 <umk3[m]> stopped showing after removing /run/user
2023-03-31 09:39:20 <donoban> uhM.. I have a fresh gnome/gdm setup on edge, and I feel that doas and su are broken
2023-03-31 09:39:36 <umk3[m]> related to pam?
2023-03-31 09:39:42 <donoban> probably
2023-03-31 09:39:52 <donoban> 'su' doesn't ask for any password
2023-03-31 09:40:10 <donoban> and fails, su: incorrect password
2023-03-31 09:40:33 <umk3[m]> what does var log messages tell about it
2023-03-31 09:40:44 <donoban> permission denied :D
2023-03-31 09:41:00 <umk3[m]> oh ok
2023-03-31 09:41:07 <umk3[m]> I understand
2023-03-31 09:41:47 <donoban> uhM, it should just link to base-auth
2023-03-31 09:42:04 <umk3[m]> which is the package that comes with pam_turnstile.so ?
2023-03-31 09:42:20 <donoban> maybe there is no package
2023-03-31 09:42:41 <donoban> alpine doesn't have all pam modules packaged, but it semes a reasonalbe idea let them configured as optional
2023-03-31 09:42:54 <donoban> so if in the future they are packaged and installed they will just work
2023-03-31 09:43:41 <umk3[m]> cool
2023-03-31 09:44:02 <donoban> I'm gonna try to log in gnome as root
2023-03-31 09:44:30 <donoban> looool
2023-03-31 09:44:42 <donoban> it logeed as root without asking password
2023-03-31 09:44:48 <umk3[m]> nice
2023-03-31 09:45:14 <umk3[m]> now you can read /var/log/messages :D
2023-03-31 09:45:36 <donoban> yeah
2023-03-31 09:47:15 <donoban> at least my elogin log seems fine
2023-03-31 09:47:19 <donoban> New session c2 for user root
2023-03-31 09:47:22 <donoban> :D
2023-03-31 09:48:00 <donoban> pam_unix(gdm-passwordauth): User [root] has a blank passwrod, authteicated without it
2023-03-31 09:49:15 <umk3[m]> elogind is not creating /run/user back lmao
2023-03-31 09:49:32 <donoban> uhM, maybe I didn't set a password when running setup-alpine
2023-03-31 09:49:50 <donoban> yeah shadow seems empty
2023-03-31 09:50:45 <donoban> yeah now asks for it, sorry for the mess :@
2023-03-31 09:51:28 <donoban> maybe su failed because root has no password
2023-03-31 09:51:39 <donoban> yeah now works
2023-03-31 09:51:53 <umk3[m]> ok donoban i tried back again your idea
2023-03-31 09:52:03 <umk3[m]> removing noninteractive from login file
2023-03-31 09:52:11 <umk3[m]> elogind seems to create a session properly
2023-03-31 09:52:28 <donoban> and sets XDG...?
2023-03-31 09:52:57 <umk3[m]> yes it does
2023-03-31 09:53:10 <donoban> so your desktop works fine?
2023-03-31 09:53:19 <umk3[m]> yes :)
2023-03-31 09:53:38 <umk3[m]> i'll see what happens if I remove /run/user again
2023-03-31 09:53:46 <donoban> ok great, let's wait psykose what thinkgs about this
2023-03-31 09:53:53 <umk3[m]> you're a genius :P
2023-03-31 09:54:29 <umk3[m]> I would have never thought about messing with the pam file directly
2023-03-31 09:54:32 <donoban> I'm not sure if there si some drawback of having base-session for all login cases
2023-03-31 09:54:48 <donoban> well, I wouldn't say that
2023-03-31 09:54:57 <donoban> I logged as root without password set and wolala
2023-03-31 09:55:07 <umk3[m]> hah
2023-03-31 09:55:56 <donoban> I'm currently trying to help a little with the pam mess, I installed gnome on a VM just for this
2023-03-31 10:02:06 <umk3[m]> pam_elogind also acts weird if /run/user doesn't exist, because it creates the directory and then refuses to create the session
2023-03-31 10:02:28 <umk3[m]> I wonder if this was introduced with the latest linux-pam commit too
2023-03-31 10:04:50 <umk3[m]> https://termbin.com/gzgs donoban
2023-03-31 10:06:51 <donoban> uhm.. but did you some manual remove of the dir?
2023-03-31 10:07:38 <donoban> let me disable gdm and try with login
2023-03-31 10:08:12 <umk3[m]> yes i did
2023-03-31 10:08:39 <donoban> I think that elogin has some process or lib storing info
2023-03-31 10:08:54 <donoban> if you log 3 times for example, it will don't remove the dir until last session is logged out
2023-03-31 10:09:09 <donoban> if you manual remove the dir you will create some incoherence
2023-03-31 10:09:28 <donoban> so maybe it refuses to recreate because it thinks that it already exists
2023-03-31 10:27:40 <Ermine> Is it ok if .pyc files get into py3 packages?
2023-03-31 10:28:14 <Ermine> E.g. https://pkgs.alpinelinux.org/contents?branch=edge&name=py3-dulwich&arch=x86_64&repo=community
2023-03-31 10:28:35 <ikke> Ermine: There is no policy against it, there are proposals to remove them
2023-03-31 10:34:17 <ddevault> regarding broken sourcehut checksums
2023-03-31 10:34:20 <ddevault> we're looking into it
2023-03-31 10:34:34 <ddevault> plan is to restore the old checksums, so don't go committing aports rehashes
2023-03-31 10:34:52 <ikke> scdoc has already been
2023-03-31 10:35:19 <ddevault> well, don't go committing *more* rehashes then :P
2023-03-31 10:35:24 <ikke> heh
2023-03-31 10:36:35 <ddevault> old hashes should be restored now
2023-03-31 10:36:40 <ddevault> LGTM, old scdoc hash applies
2023-03-31 10:36:59 <ikke> The builders have the old archives cached, so old builds will still work
2023-03-31 10:38:47 <ncopa> FYI, I just tested armhf on rpi1. It does boot.
2023-03-31 10:39:35 <Newbyte> ncopa: is there any reason to think armhf would've been broken? I'm missing the context, sorry.
2023-03-31 10:39:56 <ncopa> I somehow thought it was broken, not sure where i got it from
2023-03-31 10:40:06 <ncopa> also, I had not personally tested it for years
2023-03-31 11:14:33 <donoban> could someone give me advice for rebasing a pretty old MR before making some disaster on my local workdir?
2023-03-31 11:14:47 <donoban> doing 'git  pull upstream master' is not good idea right?
2023-03-31 11:19:13 <donoban> hmm, maybe it's just what I need to do
2023-03-31 11:19:26 <abby> add --rebase
2023-03-31 11:19:30 <donoban> agg
2023-03-31 11:20:41 <donoban> disaster, I did without it and ctr+c when read it
2023-03-31 11:21:23 <donoban> well, rebase --abort seems that worked
2023-03-31 11:21:40 <donoban> ok, let's try
2023-03-31 11:40:53 <donoban> hm..
2023-03-31 11:41:00 <donoban> I'm getting: pre-commit: community/gdm: bad checksum for file "0003-pam-rename-common-to-base.patch" (hint: run abuild checksum)
2023-03-31 11:41:20 <donoban> but I run 'abuild checksum' and manually checked it
2023-03-31 11:43:20 <donoban> ahh, I needed to git add it
2023-03-31 13:18:32 <minimal> donoban: Busybox login does NOT use PAM as Busybox is compiled without PAM support
2023-03-31 13:20:35 <minimal> also re PAM issues in general I think the current situation needs to be analysed before "randomly" changing things. I started (manually) testing some aspects of PAM a little while ago with regard to server use, obviously desktop use adds additional complications
2023-03-31 13:25:07 <skarnet> that's an incredibly diplomatic and benevolent way of talking about PAM
2023-03-31 13:30:44 <minimal> well I wasn't talking about PAM in general, rather about Alpine's pam config files
2023-03-31 13:32:32 <skarnet> sure but there's a reason why PAM configuration is difficult ;)
2023-03-31 13:37:30 <minimal> to keep us geeks in a job? ;-)
2023-03-31 13:38:43 <minimal> I have a stunt double for handling PAM stuff lol
2023-03-31 13:40:04 <umk3[m]> i'm still stuck fighting with linux-pam :P
2023-03-31 13:49:05 <umk3[m]> this works at last for a single time: removing "-noninteractive" from /etc/pam.d/login and rm -rf /run/user directory, and then relogging shell in
2023-03-31 14:29:30 <donoban> minimal: I'm not changuing things randomly
2023-03-31 14:30:30 <donoban> umk3[m]: but it doesn't work on a fresh boot with "-nointeractive" removed?
2023-03-31 14:30:45 <umk3[m]> no it does not
2023-03-31 14:31:00 <umk3[m]>  and /run/user directory needs to be created manually everytime hah
2023-03-31 14:31:11 <umk3[m]> so I dunno what is going on
2023-03-31 14:31:20 <donoban> skarnet: one interesting cause of problems is that code don't folllows what their documentation says
2023-03-31 14:32:00 <minimal> donoban: I was just making a general comment that making PAM changes without testing that *everything* that uses PAM still functions as expected is not a good thing
2023-03-31 14:32:30 <donoban> uhm, let me test it. Do you use shadow-login right?
2023-03-31 14:33:15 <donoban> minimal: I started this morning saying that could be a good idea having some minimal tests for PAM config
2023-03-31 14:33:28 <donoban> at least for a minimla term-based roles
2023-03-31 14:33:47 <minimal> yes I saw that, and please don't think I'm blaming you for anything
2023-03-31 14:34:13 <umk3[m]> yes shadow-login works as fine as util-linux-login
2023-03-31 14:34:14 <donoban> ah sorry
2023-03-31 14:34:31 <minimal> I'm just pointing out that PAM config is a "Jenga" structure
2023-03-31 14:35:13 <minimal> donaban: I've been intended to "fix" PAM myself, by first starting to try documenting exactly what is broken first
2023-03-31 14:36:01 <minimal> umk3[m]: from memory the upstream shadow people recommend util-linux-login is used in preference to shadow-login
2023-03-31 14:36:20 <donoban> well I only know about "try_first_pass" https://unix.stackexchange.com/a/688780
2023-03-31 14:37:16 <donoban> I want to believe that is not something generall, and wanted to ask upstream if they want to fix the documentation or the code
2023-03-31 14:38:15 <skarnet> donoban: in the case of PAM, this is *especially* true that the documentation is years, if not decades, behind actual code practice
2023-03-31 14:51:26 <umk3[m]> thank you minimal
2023-03-31 15:00:40 <donoban> skarnet: well, I'm not surprised that many people here prefer to just 'apk add !linux-pam' :)
2023-03-31 15:02:02 <skarnet> instantly double your machine's security with that simple trick
2023-03-31 15:13:48 <minimal> it depends, even without pam there can be some security-related issues lol
2023-03-31 15:20:17 <donoban> umk3[m]: yep, I can reproduce your problem
2023-03-31 15:20:28 <umk3[m]> nice!
2023-03-31 15:20:36 <donoban> ahh
2023-03-31 15:21:00 <donoban> in my case, elogind complained about cannot connect to system bus
2023-03-31 15:21:20 <donoban> let's relogin..
2023-03-31 15:21:37 <donoban> it works..
2023-03-31 15:21:57 <donoban> I have both /var/run/user/1000 and XDG_...
2023-03-31 15:22:06 <umk3[m]> that is a different problem
2023-03-31 15:22:15 <umk3[m]> but not related to pam i believe
2023-03-31 15:22:37 <donoban> yes, I suppose that you already have running on startup
2023-03-31 15:23:13 <donoban> i rebooted after 'rc-update add dbus', all fine
2023-03-31 15:24:15 <donoban> could you paste the pam related log on a fresh boot?
2023-03-31 15:24:42 <umk3[m]> sure
2023-03-31 15:25:41 <umk3[m]> https://termbin.com/bstr
2023-03-31 15:26:31 <umk3[m]> that is with "-noninteractive" substring removed from /etc/pam.d/login file
2023-03-31 15:26:48 <donoban> uhm.. could you check if your /run/ dir is fresH? are there some older file on it?
2023-03-31 15:27:41 <donoban> maybe its a problem with umask of the /run/ dir
2023-03-31 15:27:44 <donoban> but has mode 0775 that is too permissive (0755 was requested), refusing.
2023-03-31 15:28:20 <umk3[m]> hmm, I've checked when that error appears, it creates a hidden file ".1001" regarding to my user uid
2023-03-31 15:28:34 <umk3[m]> rather than creating a proper directory 1001 
2023-03-31 15:29:21 <donoban> let me add an extra user
2023-03-31 15:29:23 <umk3[m]> you can try removing /run/user and creating /run/user manually to see if the error replicates too
2023-03-31 15:29:29 <umk3[m]> ok
2023-03-31 15:29:54 <umk3[m]> i did that and got the same results before
2023-03-31 15:30:22 <donoban> works fine, XDG_RUNTIME_DIR=/run/user/1001
2023-03-31 15:30:56 <donoban> I think that for some reason your /run/user is created 775 instead 755
2023-03-31 15:31:02 <donoban> and elogin refuses to continue working with it
2023-03-31 15:33:27 <donoban> try to do
2023-03-31 15:33:35 <donoban> chmod 755 /run/user
2023-03-31 15:33:38 <donoban> and relogin
2023-03-31 15:33:59 <umk3[m]> ok
2023-03-31 15:35:00 <donoban> uhM, check your output of "mount | grep run"
2023-03-31 15:35:16 <donoban> is your run dir a tmpfs? mode=755?
2023-03-31 15:37:22 <umk3[m]> yes
2023-03-31 15:37:27 <donoban> also check if runing umask as root you get 0022
2023-03-31 15:38:26 <umk3[m]> relogin worked fine (with and without chmod), rebooting completely did not make me shell login successfully 
2023-03-31 15:39:56 <donoban> uhmm... so after a normal boot, the first login fails, and after logout&&reloging it works?
2023-03-31 15:43:59 <donoban> the more weird is that this worked for you before the linux-pam upgrade
2023-03-31 15:45:45 <donoban> is there anything in your boot chain that could create the /run/user dir before elogin?
2023-03-31 15:49:52 <umk3[m]> nop
2023-03-31 15:50:22 <donoban> restore the -nointeractive part of /etc/pam.d/login
2023-03-31 15:50:33 <donoban> reboot and check if /run/user exists
2023-03-31 16:03:56 <umk3[m]> it does not exist
2023-03-31 16:04:43 <donoban> uhm
2023-03-31 16:04:51 <umk3[m]> also with "-noninteractive" I can't even make it work by manually creating a /run/user
2023-03-31 16:05:09 <donoban> yes, with -nointeractive the elogin module is not loaded
2023-03-31 16:05:32 <umk3[m]> seems fair
2023-03-31 16:05:41 <donoban> I wonder if something in the new PAM rules is modifying the umask so when elogin creates /run/user is has 775 instead 755
2023-03-31 16:07:27 <umk3[m]> it's possibly a problem along that way
2023-03-31 16:12:08 <donoban> do you have pam_rundir installed?
2023-03-31 16:12:30 <donoban> hMm..
2023-03-31 16:12:45 <umk3[m]> didn't have before, but it doesn't make a change by installing it
2023-03-31 16:13:01 <donoban> maybe it's creating its own /run/user dir
2023-03-31 16:13:18 <donoban>     /* construct file name, e.g: "/run/users/.1000" */
2023-03-31 16:13:38 <donoban> and looking at edge base-session
2023-03-31 16:13:45 <donoban> it's called before elogin
2023-03-31 16:13:59 <donoban> please try removing it
2023-03-31 16:14:55 <umk3[m]> remove what?
2023-03-31 16:15:02 <donoban> apk del pam-rundir
2023-03-31 16:15:10 <umk3[m]> yes it's uninstalled
2023-03-31 16:15:15 <umk3[m]> I never used it
2023-03-31 16:15:23 <donoban> uHm..
2023-03-31 16:18:18 <donoban> lol, now my VM lost eth0
2023-03-31 16:18:34 <donoban> kernel upgrade :)
2023-03-31 16:19:34 <donoban> could you check that /lib/security/pam_rundir.so doesnt exist?
2023-03-31 16:20:21 <donoban> or just remove: "session optional pam_rundir.so" in base-session
2023-03-31 16:21:30 <umk3[m]> that file it does exist
2023-03-31 16:21:30 <umk3[m]> let me check by removing the line
2023-03-31 16:21:44 <donoban> so you have pam-rundir installed or miss-uninstalled
2023-03-31 16:22:33 <umk3[m]> nevermind hah I installed it seconds ago
2023-03-31 16:22:58 <donoban> :)
2023-03-31 16:23:01 <umk3[m]> file does not exist but I could try removing the pam_rundir.so line
2023-03-31 16:23:03 <umk3[m]> brb
2023-03-31 16:23:11 <donoban> if it doesn't exist the pam line will be just ignored
2023-03-31 16:23:21 <donoban> try again please, crossfingers
2023-03-31 16:24:15 <donoban> I wonder if elogin could unset XDG_... after failing, which pam_rundir was set before
2023-03-31 16:24:45 <donoban> anyway elogind and pam-rundir should be mutual excluyent
2023-03-31 16:32:40 <umk3[m]> it didnt change anything
2023-03-31 16:42:30 <donoban> :'(
2023-03-31 16:43:34 <donoban> do you still having /run/user with 775?
2023-03-31 16:44:33 <donoban> maybe you can strace login and try to find what creates it
2023-03-31 21:30:28 <donoban> ey umk3[m] https://tpaste.us/oggk
2023-03-31 21:30:44 <umk3[m]> hello
2023-03-31 21:30:59 <umk3[m]> you got the same output as me?
2023-03-31 21:31:15 <donoban> yeah but installing pam-rundir
2023-03-31 21:31:38 <donoban> I suppose that it will be fixed if I remove it
2023-03-31 21:32:20 <umk3[m]> in my setup removing pam-rundir doesn't fix anything
2023-03-31 21:32:28 <umk3[m]> crossing fingers :P
2023-03-31 21:33:07 <donoban> rebooting..
2023-03-31 21:34:04 <donoban> its fine now
2023-03-31 21:35:46 <umk3[m]> is shadow-login installed?
2023-03-31 21:36:00 <donoban> util-linux
2023-03-31 21:36:06 <donoban> let me try the other
2023-03-31 21:37:04 <donoban> rebooting..
2023-03-31 21:37:54 <donoban> fine too
2023-03-31 21:38:13 <umk3[m]> interesting
2023-03-31 21:39:13 <donoban> well, it's late
2023-03-31 21:39:17 <donoban> see you tomorrow
2023-03-31 21:39:38 <umk3[m]> take care! you messed a lot with that :P
2023-03-31 21:40:11 <donoban> hehe yep, good night