2023-05-01 08:47:19 <staceee> in my personal aports CI build, I have "(111/185) Installing mopidy (3.4.1-r1) \n ERROR: mopidy-3.4.1-r1: BAD signature". How's that possible? I never had bad signation in pulling package before
2023-05-01 08:47:32 <staceee> and I don't reproduce locally
2023-05-01 08:48:00 <staceee> it is on edge
2023-05-01 08:59:48 <ikke> staceee: what arch?
2023-05-01 09:00:09 <staceee> x86_64
2023-05-01 10:16:16 <ikke> staceee: I get bad signature locally as well
2023-05-01 10:16:51 <staceee> scary?
2023-05-01 10:17:04 <ikke> Not necessarily
2023-05-01 10:18:14 <ikke> 6b33280b1d73c00c3150d1a5995b707248281982 added a subpackage without bumping pkgrel
2023-05-01 10:18:38 <ikke> so the package got rebuilt, but dl-cdn is still serving the old package that no longer matches the signature in the index
2023-05-01 10:22:03 <ikke> staceee: fixed
2023-05-01 10:44:14 <staceee> nice
2023-05-01 14:52:11 <that_guy> I was wondering if there's any plans to implement PEP-668 for alpine's system python?
2023-05-01 14:59:13 <abby> i think that's been tried and breaks things for people using pip in containers
2023-05-01 14:59:29 <ikke> debian implemented it
2023-05-01 14:59:42 <ikke> Wonder how they deal with that
2023-05-01 15:06:54 <that_guy> they already add a path to the search list that only dpkg uses
2023-05-01 15:08:44 <that_guy> my concern is mostly for if/when apk-packaged python packages carry patches and create frankenversions
2023-05-01 15:09:39 <that_guy> since (iirc) apk-installed packages and pip-installed packages go into the same spot
2023-05-01 15:11:05 <that_guy> if the apk packages don't all have an INSTALLER file or don't somehow modify the METADATA file to signifiy it's not the same as upstream, it's basically impossible to tell
2023-05-01 15:12:57 <abby> you can prevent this by not comingling apk-packaged python modules and system-pip-installed python modules
2023-05-01 15:13:07 <abby> use a venv or something for pip
2023-05-01 15:14:38 <that_guy> I know one can, but I'm saying it might be worth doing by default on a new release
2023-05-01 15:34:52 <ncopa> psykose: i suppose its safe to merge? https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/114
2023-05-01 16:18:43 <psykose> ncopa: yeah, just uses -T0 for the zstd mode and not much else
2023-05-01 16:19:35 <psykose> that_guy: i already did that and within one day someone complained it broke `pip install something` into the system dir
2023-05-01 16:19:43 <psykose> and that it would be 'very inconvenient' to 'use a venv'
2023-05-01 16:19:52 <psykose> it doesn't actually have any benefits aside from.. preventing that
2023-05-01 16:19:59 <psykose> and apparently people really love to do that
2023-05-01 16:27:23 <sam_> we just bit the bullet but i know there's more people using alpine for dockerfiles and then using pip in it
2023-05-01 16:27:38 <sam_> you've got cover if you want to, because ubuntu is doing it
2023-05-01 16:29:51 <psykose> i guess i'll consider it after 3.18 with the ole edge excuse
2023-05-01 16:38:12 <orbea> pip installing into system directories, lol...
2023-05-01 16:42:41 <that_guy> yeah, pip now has the explicit `--break-system-packages` flag and a user/administrator should be able to `pip config set install.break-system-packages True`
2023-05-01 16:43:05 <that_guy> (although I haven't tried that, on account of... sanity)
2023-05-01 16:47:17 <psykose> ah right, --break-system-packages
2023-05-01 16:53:51 <that_guy> that's relatively new, but I also don't develop python so maybe it's well-known?
2023-05-01 17:13:05 <mercenary> Just add 'conflicts: py3-*' to pip. Problem solved.
2023-05-01 17:25:53 <skarnet> if I were a packager and some tool came with an option named --break-system-packages I don't think I'd want to package that tool
2023-05-01 17:25:59 <skarnet> but I'm weird like that
2023-05-01 17:29:01 <ikke> --dont-hold-my-hand-and-allow-me-to-do-what-i-want
2023-05-01 17:30:09 <humm> pip install --no-preserve-root
2023-05-01 17:30:47 <mercenary> Old redhat was fun with that. The package manager was in python, random 'pip install' overwriting the system packages breaks the package manager. Only way to unbreak the system is re-install
2023-05-01 17:33:43 <minimal> "--do-what-I-meant-not-what-I-said"
2023-05-01 17:34:22 <ncopa> we dont support 32 bit uefi right?
2023-05-01 17:35:27 <minimal> well grub-efi is packaged for x86
2023-05-01 17:35:58 <ncopa> hum. ok
2023-05-01 17:36:09 <minimal> and linux-lts for x86 has CONFIG_EFI=y
2023-05-01 17:37:02 <minimal> though personally I'd avoid x86 UEFI, it seems "tempramental"
2023-05-01 17:37:45 <ncopa> im trying to figure out why nfit does not work with lts kernel but it works with virt kernel
2023-05-01 17:38:29 <minimal> what's "nfit"?
2023-05-01 17:38:56 <ncopa> driver for /dev/pmem0 driver for uefi http boot
2023-05-01 17:39:06 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13823
2023-05-01 17:39:12 <ncopa> nvdimm
2023-05-01 17:39:37 <ncopa> it allows uefi to boot from http
2023-05-01 17:39:59 <ncopa> the cdrom image is doenloaded to a ramdisk that is visible as /dev/pmem0
2023-05-01 17:40:19 <minimal> sounds like a strange connect? is'nt NVDIMM a "flash" version of RAM, don't see how it related to UEFI HTTP
2023-05-01 17:40:20 <ncopa> which works on virt kernel (with my local changes), but it does not work with lts kernel
2023-05-01 17:40:41 <ncopa> uefi boot can do network boot, similar to pexe
2023-05-01 17:40:47 <ncopa> pxe
2023-05-01 17:41:02 <ncopa> uefi firwmare dwonloads an alpine iso image and boots it
2023-05-01 17:41:03 <minimal> yeah I know that, I just don't see the nvdimm relevance
2023-05-01 17:41:27 <ncopa> the initramfs can find the iso as /dev/pmem0
2023-05-01 17:41:38 <ncopa> apparently nvdimm needs to be enabled in kernel
2023-05-01 17:44:54 <minimal> ok, I'll take your word for it, it still sounds strange, NVDIMM = Non-volatile Dual Inline Memory Module
2023-05-01 17:45:15 <minimal> anyway for NFIT you're referring to CONFIG_ACPI_NFIT kernel option?
2023-05-01 17:45:21 <ncopa> it was claimed in https://gitlab.alpinelinux.org/alpine/aports/-/issues/13823
2023-05-01 17:45:29 <ncopa> yep
2023-05-01 17:47:13 <minimal> seems related to find EDK2 (UEFI) code: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
2023-05-01 17:47:19 <minimal> s/find/this/
2023-05-01 17:47:35 <ncopa> i found it pretty cool that you could do netboot that way
2023-05-01 17:47:49 <ncopa> now I'm investigating why it only works for -virt kernel
2023-05-01 17:47:57 <minimal> specifically line 58 onwards
2023-05-01 17:48:03 <ncopa> i also wonder if this could work on aarch64
2023-05-01 17:48:40 <ncopa> yup
2023-05-01 17:48:50 <minimal> HTTP boot is an *optional* part of the UEFI spec from memory, however most shipping UEFI implementations out there are derived from EDK2 AFAIK
2023-05-01 17:48:51 <ncopa> oh, i proably also need enable DXE something
2023-05-01 17:50:50 <ncopa> no, i think i need memory hotplug enabled
2023-05-01 17:53:00 <ncopa> ok, it does not work on aarch64
2023-05-01 17:53:12 <ncopa> due to CONFIG_ARCH_HAS_PMEM_API
2023-05-01 17:53:12 <minimal> for PMEM I think you need CONFIG_X86_PMEM_LEGACY
2023-05-01 17:53:50 <ncopa> src/build-virt.x86/.config:# CONFIG_X86_PMEM_LEGACY is not set
2023-05-01 17:53:50 <ncopa> src/build-virt.x86_64/.config:# CONFIG_X86_PMEM_LEGACY is not set
2023-05-01 17:54:14 <minimal> yes you can either use NVDIMM for PMEM, or that legacy option
2023-05-01 17:54:14 <ncopa> src/build-lts.x86_64/.config:CONFIG_X86_PMEM_LEGACY_DEVICE=y
2023-05-01 17:54:14 <ncopa> src/build-lts.x86_64/.config:CONFIG_X86_PMEM_LEGACY=y
2023-05-01 17:54:24 <ncopa> maybe i need to disable legacy
2023-05-01 17:55:28 <minimal> I'm still confused why UEFI HTTP Boot needs PMEM support when the vast majority of machines do not have an persistent memory (NVDIMM or otherwise) fitted
2023-05-01 17:56:55 <minimal> ncopa: sounds like same issue: https://edk2.groups.io/g/devel/message/68053
2023-05-01 17:57:37 <ncopa> yeah
2023-05-01 17:57:48 <ncopa> im trying to sync the configs a bit
2023-05-01 17:57:57 <ncopa> building kernel now. lets see if it boots
2023-05-01 17:59:43 <minimal> "If there is no NFIT, the booted operating system will have no idea where to load other files from."
2023-05-01 18:00:02 <ncopa> the nfit module is there
2023-05-01 18:02:35 <minimal> FYI: Slide 15, https://bhyvecon.org/bhyveconOttawa2019-DScott.pdf
2023-05-01 19:57:09 <mio> hi, what does "could not find owner package" during tracing dependencies mean? context: https://gitlab.alpinelinux.org/mio/aports/-/jobs/1022900#L4111
2023-05-01 19:58:59 <mio> and is there a place where people can look up/interpret common abuild errors?
2023-05-01 20:17:55 <ncopa> mio: it means that abuild detects that something depends on  libcolorfx.so but cannot figure out which package provides it
2023-05-01 20:18:18 <ncopa> my guess is that there are some RPATH set to the build directory
2023-05-01 20:18:48 <ncopa> or there is some symlink pointing to absolute path in build directory
2023-05-01 20:19:41 <psykose> it is a broken rpath
2023-05-01 20:19:54 <mio> ncopa: thanks. was getting an rpath-related error locally so some sort of rpath is probably being set
2023-05-01 20:20:26 <mio> psykose's suggestion in MR will hopefully fix both
2023-05-01 20:21:13 <mio> didn't realise the two things were related
2023-05-01 20:52:33 <ncopa> ok, i think I have done everything I wanted for rc1
2023-05-01 20:52:49 <ncopa> but its late, so I'll tag 3.18.0_rc1 tomorrow
2023-05-01 20:53:06 <ncopa> (unless the builders are busy with something)
2023-05-01 20:55:04 <ncopa> good night!
2023-05-02 00:26:46 <timlegge> a number of my packages were flagged on pkgs.alpinelinux.org with the New Version column set to 1.  I received an email yesterday around the same time I  sent MRs for updates
2023-05-02 00:27:09 <timlegge> Anything I need to do, the versions are up-to-date as far as I can tell
2023-05-02 00:32:29 <psykose> nope, just spam
2023-05-02 00:33:17 <psykose> sam_: have you heard of something related to libgcc_s from 13 breaking chromium build because the flatc built in the tree works, exits, then the dtors fail and give: https://img.ayaya.dev/TsjkSwxEqd5k
2023-05-02 00:33:32 <psykose> if i just use libgcc from 12 it magically works
2023-05-02 00:33:47 <psykose> and the flatc from flatbuffers git works normally, just the chromium tree one doesn't
2023-05-02 00:34:58 <psykose> no weird attribute destructors anywhere
2023-05-02 00:36:25 <timlegge> thanks psykose
2023-05-02 07:53:39 <ncopa> could we fix any of those for 3.18? https://gitlab.alpinelinux.org/alpine/aports/-/milestones/199#tab-issues
2023-05-02 07:54:03 <ncopa> i think I will do rc1 later today
2023-05-02 10:09:53 <PabloCorreaGomez[m]> ncopa: I looked into https://gitlab.alpinelinux.org/alpine/aports/-/issues/11642 the other day. There are just a few (like 5?) packages in community and another few in testing with the old path. That's an upstream issue and nothing I think it's worth our effort, since everything keeps working with the legacy paths for now, and when it breaks, it will break for everybody, so upstream will be forced to act in consequence. If you
2023-05-02 10:09:53 <PabloCorreaGomez[m]> want, I can go to the issue and list  the packages with that problem, but I honestly don't think it's worth the effort. In worst case, I believe it should be the maintainers of those packages that should take the issue with their upstream. Does that make sense?
2023-05-02 11:41:08 <ncopa> I think so. Looks like a problem for upstream 
2023-05-02 11:54:57 <PabloCorreaGomez[m]> Would it make sense to patch abuild so that it can add something like "provides=service:gdm=$pkgver-r$pkgrel" in default_openrc? I'm trying to script a way to find from which package does a certain service come from, and I seem to be unable to do it, since "apk info" only has the list of installed files after installation, for  which you need to know the pkgname. And unfortunately, the service names and the pkgname sometimes
2023-05-02 11:54:57 <PabloCorreaGomez[m]> differ, e.g: bluez-openrc -> bluetooth service
2023-05-02 11:55:06 <PabloCorreaGomez[m]> Maybe this is not enough of an usecase and I should instead create a dictionary for those cases? But seems a bit annoying
2023-05-02 12:19:33 <ncopa> dont think its worth it
2023-05-02 12:24:19 <PabloCorreaGomez[m]> Ok, so a dict it is, thanks!
2023-05-02 13:32:33 <ncopa> im tagging 3.18.0_rc1 now
2023-05-02 13:37:08 <ncopa> here we go....
2023-05-02 14:03:49 <ncopa> aeaaa1f3e1f20eafff71f09d578e77b5f09f38dc broke 3.18.0_rc1. irssi was a part of extended image
2023-05-02 14:04:04 <ncopa> commit message says nothing about why it was moved
2023-05-02 14:43:34 <andypost[m]> ncopa: looks like there's was discussion https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/37901#note_272586
2023-05-02 14:44:41 <ncopa> thanks
2023-05-02 14:44:51 <ncopa> the git log didnt tell me anything about it
2023-05-02 15:22:16 <andypost[m]> I see no way except Gitlab's API to know is there related MR for commit except fetching 'refs/merge-requests'
2023-05-02 15:23:15 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/commit/aeaaa1f3e1f2 shows the related MR
2023-05-02 15:23:29 <ikke> But it's not part of the git history
2023-05-02 15:23:37 <ikke> as it's not in the commit and we do not use merge commits
2023-05-02 15:31:04 <andypost[m]> ikke: as I see there's '2c85550b9f7a4ff3483cf7a8659fcacc42ae78e9	refs/merge-requests/37901/head' where "tail" or MR exists and all related information
2023-05-02 15:31:13 <andypost[m]> it's not fetched by default
2023-05-02 15:31:57 <ikke> no, these are non-standard refs that gitlab creates
2023-05-02 15:32:03 <ikke> so they are not fetched by default
2023-05-02 15:32:11 <andypost[m]> and another d48702a5808aa049bdb3ce6d5bcc1537fdb12686	refs/merge-requests/37901/merge set
2023-05-02 15:33:00 <andypost[m]> but yes, not a standard
2023-05-02 15:33:30 <andypost[m]> at least a way
2023-05-02 15:33:42 <ikke> If you use merge commits, the default merge commit message includes a reference to the MR
2023-05-02 15:35:39 <andypost[m]> if the ref will be fetched by default this merge commits will be useless)
2023-05-02 15:36:25 <andypost[m]> from aport maintainer's POV
2023-05-02 15:38:26 <ikke> These refs represent all merge requests created, not necessarily what's accepted
2023-05-02 15:38:31 <ikke> so would introduce a lot of noise
2023-05-02 21:10:32 <omni> since a few days I've had issues booting with zfs root, haven't had time to dig into it earlier
2023-05-02 21:11:12 <omni> the last working snapshot is at linux 6.1.24-r0 and it may have been working since and that I had not taken any more recent snapshots
2023-05-02 21:12:51 <omni> (a "few days" could be a couple of weeks, been busy)
2023-05-02 21:17:26 <omni> so what I just did was rolling back to that snapshot, upgrade everything and then run into the issue I noticed last week or something
2023-05-02 21:17:35 <omni> zfs module missing in initfs I think it was
2023-05-02 21:18:04 <omni> then I rolled back again to be able to boot
2023-05-02 21:59:13 <omni> tried upgrading just the kernel (linux-lts -> 6.1.27-r1 & zfs-lts -> 6.1.27-r4)
2023-05-02 22:00:17 <omni> modprobe: ERROR: could not insert 'zfs': Key was rejected by service
2023-05-02 22:00:33 <omni> when trying manualy in the rescue shell
2023-05-02 22:04:45 <omni> 6a915eca probably?
2023-05-02 22:05:30 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/commit/6a915eca44c0f2841e724777652f72b1b7be1259
2023-05-02 22:23:09 <omni> maybe I also have module.sig_enforce=1 on the cmdline for whatever reason..
2023-05-03 00:33:25 <elly> hiya folks - after updating earlier today, X no longer starts on my framework laptop
2023-05-03 00:34:52 <elly> specifically, it dies with an assert in xf86-video-intel now: https://elly.town/t/xorg-log.txt
2023-05-03 00:35:03 <elly> anyone else see this? I do not see recent changes to xf86-video-intel
2023-05-03 00:35:34 <psykose> this looks like indeed the change to xf86-video-intel
2023-05-03 00:35:39 <psykose> but you should also probably just uninstall it
2023-05-03 00:36:19 <elly> is it obsolete now?
2023-05-03 00:37:26 <psykose> it's been obsolete for a very long time, afaik unless -modesetting (that uses mesa directly) works poorly on $specific gpu, there's no point to use it
2023-05-03 00:37:42 <psykose> and mesa is needed anyway for application gl or something, this is just xorgs own acceleration
2023-05-03 00:38:04 <psykose> if you never touched any config files, just `apk del` of it should give you a starting X
2023-05-03 00:38:26 <psykose> the only change to xf86-video-intel recently is going from the 2 year old commit to the 6 month old commit https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commits/master?ref_type=heads
2023-05-03 00:38:35 <psykose> seems indeed it asserts for some reason
2023-05-03 00:39:02 <elly> wild
2023-05-03 00:39:05 <elly> alright, I'll remove it :)
2023-05-03 00:39:38 <elly> and like magic it works now
2023-05-03 00:39:40 <elly> thanks psykose
2023-05-03 00:39:48 <psykose> check that it doesn't stutter or anything
2023-05-03 00:39:57 <psykose> framework is new enough that it should be 'good' i guess
2023-05-03 00:47:24 <psykose> as for that i downgraded it to the previous version i guess (since you're not the first), for when that builds in a bunch of hours
2023-05-03 00:54:19 <Arnavion> Speaking of downgrading, after sofia-sip was downgraded from r2 to r1, the r1 can't install on aarch64 because it has bad signature. x86_64 is fine.   >Downgrading sofia-sip (1.13.14-r2 -> 1.13.14-r1) >ERROR: sofia-sip-1.13.14-r1: BAD signature
2023-05-03 00:55:46 <psykose> someone reverted a commit without a pkgrel increment
2023-05-03 00:56:03 <psykose> 1->2->1
2023-05-03 00:56:06 <Arnavion> (   https://gitlab.alpinelinux.org/alpine/aports/-/commit/aa2d78868c3e4522a677dc9ebeb9c306682105fe   )
2023-05-03 00:56:17 <Arnavion> Yeah
2023-05-03 00:57:34 <Arnavion> So I take it the correct way would've been to bump to r3?
2023-05-03 00:58:12 <Arnavion> And why would it only break aarch64 repo but not x86_64 repo?
2023-05-03 00:58:58 <psykose> probably expired from cdn
2023-05-03 00:59:23 <psykose> (that's all that breaks it)
2023-05-03 01:00:41 <Arnavion> Ah I get it, it's serving the pre-rebuild r1
2023-05-03 03:35:23 <Skillingford> Don't let Micky Mouse diddle your little boy!  Mickey was busted by Chris Hansen on To Catch a Predator trying to buttscrew a 13 y/o boy in a sting operation!  Read all about it here:  https://pastebin.com/edvNf8kn   Ron Desantis 2024
2023-05-03 04:49:21 <DeSantis> Don't let Micky Mouse diddle your little boy!  Mickey was busted by Chris Hansen on To Catch a Predator trying to buttscrew a 13 y/o boy in a sting operation!  Read all about it here:  https://pastebin.com/edvNf8kn   Ron Desantis 2024
2023-05-03 11:03:32 <eddsalkield> seems like there's a conflict between perl-doc and perl-scalar-list-utils-doc at the moment:
2023-05-03 11:03:35 <eddsalkield> https://paste.sr.ht/~eddsalkield/f8e749af5f9b75df8d39afc3177aef3158799943
2023-05-03 11:04:25 <eddsalkield> Do we need a `replaces=perl-doc`?
2023-05-03 11:16:01 <ikke> If both packages provide the same file, that should be mitigated 
2023-05-03 13:41:55 <eddsalkield> seems like the latest `perl-doc` doesn't have the conflict, but an older one does
2023-05-03 13:42:00 <eddsalkield> so the upgrade path is broken
2023-05-03 13:42:10 <eddsalkield> I fixed it by reinstalling perl-scalar-list-utils
2023-05-03 13:42:22 <eddsalkield> is there a mitigation we need to apply in this case?
2023-05-03 13:49:08 <ikke> A replaces would help in that case, yes
2023-05-03 13:55:49 <eddsalkield> Cool, I've submitted an MR here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46709
2023-05-03 14:31:53 <Newbyte> https://builds.sr.ht/~postmarketos/job/983564#task-img-717
2023-05-03 14:32:14 <Newbyte> has this been resolved yet? i.e., ERROR: sofia-sip-1.13.14-r1: BAD signature when trying to install it
2023-05-03 14:32:26 <Newbyte> I guess it's something mirror-specific
2023-05-03 14:33:13 <Newbyte> it's coming from http://dl-cdn.alpinelinux.org anyway. should I make an issue?
2023-05-03 14:33:31 <ikke> Usually happens when an upgrade is reverted or a subpg added or removed without pkgrel bump 
2023-05-03 14:34:40 <Newbyte> thanks, looks like it has been fixed in aports then
2023-05-03 14:38:01 <ikke> Simple fix is to purge the cache for that package 
2023-05-03 14:38:29 <ikke> alpine-repo-tools helps with that 
2023-05-03 14:38:52 <Newbyte> not sure I understand. is this something I would do locally?
2023-05-03 14:39:35 <ikke> Newbyte: you purge it on fastly (dl-cdn), which fixes it for everyone 
2023-05-03 14:40:05 <Newbyte> ikke: I can do that without any privileges?
2023-05-03 14:40:10 <ikke> Yes
2023-05-03 14:42:25 <Newbyte> Did you already do it? It says "Nothing to do" for me.
2023-05-03 14:43:02 <ikke> What did you execute?
2023-05-03 14:43:10 <ikke> I haven't done anything 
2023-05-03 14:43:12 <Newbyte> repo-tools fastly purge pkg sofia-sip
2023-05-03 14:43:37 <ikke> Add --origin and --repo
2023-05-03 14:44:29 <Newbyte> Thanks, adding --origin fixed it (since sofia-sip is in main, i.e. the default)
2023-05-03 14:44:34 <ikke> Ok
2023-05-03 14:55:30 <bl4ckb0ne> whats the rule to push to master? I have one of my own package that i simply bumped with abump
2023-05-03 16:23:26 <Piraty> psykose: you messed up the patch. https://gitlab.alpinelinux.org/alpine/aports/-/commit/6cc25326d7d8f12b7efa3247aef4d1f63de03cde#3a5a0575c4b354f9b07ff96820ea07bda2945193_72_76
2023-05-03 16:41:30 <dzilvys> Hello, I was just wondering but where do the openvpn logs get stored on alpine?
2023-05-03 16:42:32 <Piraty> can abuild rootbld preserve the rootfs so i can iterate more quickly?
2023-05-03 17:10:49 <Piraty> psykose: i have the fix, hang on a few minutes
2023-05-03 18:21:28 <Piraty> psykose: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46713 here we go
2023-05-03 19:49:39 <psykose> bl4ckb0ne: there aren't any
2023-05-03 20:01:17 <bl4ckb0ne> ill do a mr to check if no arch broke
2023-05-03 20:01:48 <ikke> That's sensible 
2023-05-03 20:05:13 <bl4ckb0ne> last time cglm broke randomly on x86
2023-05-03 20:51:11 <Piraty> abump is a thing now?
2023-05-03 20:51:28 <ikke> Has been there for ages
2023-05-03 20:51:30 <pj> if now is years, then yes
2023-05-03 20:51:49 <bl4ckb0ne> pretty handy tool, i bump a lot of my packages with that
2023-05-03 20:51:54 <Piraty> where is "there" ?
2023-05-03 20:52:01 <Piraty> ah
2023-05-03 20:52:03 <Piraty> abuild
2023-05-03 20:52:05 <pj> abuild
2023-05-03 20:52:07 <pj> liek
2023-05-03 20:52:14 <pj> all other abuild tools
2023-05-03 20:52:18 <pj> and scripts
2023-05-03 20:52:24 <Piraty> got
2023-05-03 20:52:25 <Piraty> it
2023-05-03 20:52:26 <Piraty> thanks
2023-05-04 01:51:44 <bl4ckb0ne> good thing i did that MR, ci failed on multiple arch
2023-05-04 01:56:07 <psykose> :D
2023-05-04 07:32:47 <raspbeguy> hello
2023-05-04 07:33:22 <raspbeguy> psykose, yesterday you validated https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46718
2023-05-04 07:34:01 <psykose> yes
2023-05-04 07:34:14 <raspbeguy> this MR renames locale.sh into 20locale.sh, but 20locale.sh is already a file that is provided by musl-locales
2023-05-04 07:34:26 <raspbeguy> wouldn't this just break everything?
2023-05-04 07:34:55 <psykose> no?
2023-05-04 07:35:13 <raspbeguy> how so?
2023-05-04 07:35:47 <psykose> musl-locales doesn't contain a 20locale.sh
2023-05-04 07:36:27 <raspbeguy> oh sorry, that was 00locale.sh
2023-05-04 07:36:30 <raspbeguy> my bad
2023-05-04 07:37:51 <raspbeguy> will the documentation be updated to reflect the change?
2023-05-04 07:38:03 <psykose> which documentation
2023-05-04 07:40:19 <raspbeguy> oh you did that a few minutes ago 😛
2023-05-04 12:25:42 <solene> hi, is there a way to enable ccache when building with abuild? I couldn't find any documentation about that
2023-05-04 12:26:32 <ikke> I see USE_CCACHE in the abuild source
2023-05-04 12:28:18 <solene> https://wiki.alpinelinux.org/wiki/User:Mattx86/qwn:Enabling_ccache i'll try that...
2023-05-04 12:29:45 <solene> or maybe I don't really need it? I'm packaging a software for alpine for the first time, using abuild -r, but that's the second time it fails at the very end and I lose so much time, with ccache I wouldn't have to rebuild everything from scratch, but if I could have the build process to not clean and be able to pick up after a small change?
2023-05-04 12:29:47 <psykose> /etc/abuild.conf has a USE_CCACHE
2023-05-04 12:30:18 <psykose> abuild has -K to keep stuff but it's not guaranteed the build will work reran fully
2023-05-04 12:31:12 <psykose> i.e. it's just simple shell functions so if you do abuild -Kr twice the second time just fails on applying any patches, etc
2023-05-04 12:31:27 <psykose> you can manually run only the build step after with `abuild build`
2023-05-04 12:33:48 <solene> psykose: thanks! This leads me to another question I had in mind, is there a group of people focusing on documentation? I'd like to help in that regard, but I'd like to do it right and not just add another wiki page
2023-05-04 12:34:28 <ikke> solene: yes, there is
2023-05-04 12:34:33 <psykose> used to be, don't think anyone is doing much currently
2023-05-04 12:34:39 <psykose> the new focus was on https://docs.alpinelinux.org/
2023-05-04 12:36:01 <psykose> but overall there's no real "documentation project", wiki pages are just random ad-hoc and that website is https://gitlab.alpinelinux.org/alpine/docs/user-handbook
2023-05-04 12:36:03 <psykose> so.. that i guess
2023-05-04 12:37:03 <solene> psykose: cool, that's a lead to contribute effectively :)
2023-05-04 12:48:11 <solene> I have a dependency issue for building a package, https://pbot.rmdir.de/SoLTpb-0QuA0Rul6a_42nA , does that mean all the dependencies listed are missing?
2023-05-04 13:07:18 <psykose> no, just the mentioned one is dt_needed on something but not in absolute rpath
2023-05-04 13:07:28 <psykose> you can probably just ignore it
2023-05-04 13:34:46 <solene> psykose: ok :)
2023-05-04 13:44:19 <solene> which package should provide LIBTINFO? I can't find any libtinfo.so in the packages contents, I wonder if alpine ncurses as something special
2023-05-04 14:57:10 <ncopa> i would like to tag rc3 now
2023-05-04 15:01:11 <ncopa> ok, here comes alpine 3.18 rc3
2023-05-04 15:42:09 <solene> I just upgraded to edge, I'm getting desperate with locale issues ^^', ansible-playbook used to work on 3.17, and upgrading to edge gives me
2023-05-04 15:42:12 <solene> ERROR: Ansible requires the locale encoding to be UTF-8; Detected ISO8859-1.
2023-05-04 15:45:01 <solene> works fine in a tty, so it's yet another gnome / shell locale issue :(
2023-05-04 18:12:13 <tomalok> ncopa, ikke: i haven't checked what release notes are on deck for 3.18 -- but we should call out Docker 23.0.x -- and its default of wanting to use buildx (available separately as docker-cli-buildx) instead of the builtin/deprecated build...  iirc there is an env variable that one can set to tell docker to use the old builtin build command.
2023-05-04 19:07:34 <ncopa> Yeah, I get a warning now. We should make docker use buildx by default 
2023-05-04 19:10:20 <ikke> It does, but it's a plugin that you need to seperately install
2023-05-04 19:10:47 <ikke> so by default now docker does not support building until you install docker-cli-buildx
2023-05-04 19:10:53 <ikke> I suggested adding that by default
2023-05-04 22:11:21 <omni> how will out-of-tree modules be signed?
2023-05-04 23:07:46 <tomalok> ikke: being able to build docker images is not a requirement for actually running docker on a host -- i would prefer that if i only need to run docker containers, that i don't have to install extra stuff...
2023-05-04 23:08:35 <tomalok> ...hence calling out the significant changes in the release notes instead of auto-installing something not everyone needs?
2023-05-04 23:10:33 <tomalok> what we _COULD_ do is turn on whatever it is to enable the old "docker build" but document in notes that this is only temporary transitionary mitigation
2023-05-05 00:22:48 <skarnet> !46793 smol update
2023-05-05 05:41:32 <ncopa> i found a bug in busybox ash
2023-05-05 05:41:44 <ncopa> actually, my alpine-installer-testsuite found it
2023-05-05 05:41:56 <ncopa> good morning, btw
2023-05-05 05:42:31 <valerius> feliz cinco de mayo
2023-05-05 05:43:19 <ncopa> omni: the linux-lts-dev package should now have the sign-file  tool: https://gitlab.alpinelinux.org/alpine/aports/-/issues/14826
2023-05-05 05:43:42 <ncopa> but i wonder if we ship the private key or key config that was used when signing
2023-05-05 05:57:25 <ncopa> hum
2023-05-05 05:57:37 <ncopa> this busybox bug seems a bit difficult to debug
2023-05-05 06:08:33 <psykose> what's the bug
2023-05-05 06:11:36 <ncopa> ash segfaults after stty -echo is run
2023-05-05 06:11:56 <ncopa> to reproduce: ulimit -c unlimited; ash 
2023-05-05 06:12:05 <ncopa> and there type stty -echo
2023-05-05 06:13:15 <ncopa> your terminal will no longer echo after that, so you will have to do: stty echo
2023-05-05 06:14:11 <ncopa> (gdb) bt
2023-05-05 06:14:12 <ncopa> #2  0x00007f13ab810429 in ?? ()
2023-05-05 06:14:12 <ncopa> #1  0x5b007ffc5d700ee0 in ?? ()
2023-05-05 06:14:12 <ncopa> #0  0x0000000000496f94 in parse_and_put_prompt ()
2023-05-05 06:16:13 <ncopa> ok, i have a proper backtrace
2023-05-05 06:19:02 <Flora[m]123> !!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW on TG 
2023-05-05 06:19:03 <Flora[m]123> https://t.me/FloraGordon
2023-05-05 06:21:32 <psykose> ncopa: hah, weird
2023-05-05 06:28:10 <ncopa> psykose: i found a patch in busybox git stable
2023-05-05 06:28:22 <ncopa> but there seems to be a few more fixes there
2023-05-05 06:28:40 <psykose> we should probably apply them all
2023-05-05 06:28:52 <psykose> like we do for gcc, i.e. generally based on stable branch not a tag
2023-05-05 06:28:53 <ncopa> yeah
2023-05-05 06:29:03 <psykose> good find :)
2023-05-05 06:29:20 <ncopa> it was my alpine-installer-testsuite that found it :)
2023-05-05 06:29:41 <psykose> you wrote it :p
2023-05-05 06:36:25 <ncopa> we already have one of the patches
2023-05-05 06:36:54 <ncopa> maybe we shoudl re-enable the assembly version of sha?
2023-05-05 06:37:00 <ncopa> its fixed upstream
2023-05-05 06:42:24 <ncopa> nmeum: i backported various fixes for busybox
2023-05-05 06:44:52 <psykose> for x86_64 probably, iirc x86 still had the textrel issue
2023-05-05 06:44:55 <psykose> unless that was fixed
2023-05-05 06:46:04 <psykose> looks like it wasn't on 36 stable
2023-05-05 07:20:46 <omni> ncopa: as I understand it, we now generate a keypair, and sign in-tree modules with it, at build time
2023-05-05 07:21:24 <omni> if you boot with module.sig_enforce=1 your /proc/keys will have public key content
2023-05-05 07:21:35 <omni> (otherwise it's empty)
2023-05-05 07:25:23 <omni> with modinfo you can now see feilds sig_id, signer, sig_key, sig_hashalgo and signature for in-tree modules
2023-05-05 07:29:25 <omni> so what I'm thinking about is how to temporarily save that buildtime autogenerated keypair and use it to sign the out-of-tree modules zfs-lts, xtables-addons-lts, rtpengine-lts, rtl8821ce-lts and jool-modules-lts
2023-05-05 07:30:01 <omni> (I mostly care about zfs-lts)
2023-05-05 07:31:04 <psykose> it's not possible without also putting the keypair into the package, which sends around the private key
2023-05-05 07:31:37 <omni> =/
2023-05-05 07:32:02 <omni> I was hoping it would be possible to somehow have a temporarily shared storage or something
2023-05-05 07:32:48 <psykose> everything is possible if you add in a bunch of stuff that doesn't exist and implement a million build steps and add 50 moving parts
2023-05-05 07:33:06 <psykose> the only feasible way to do that without also completely changing how the builds are done is to build all modules in the same build and not externally
2023-05-05 07:33:20 <psykose> i.e. to have linux-lts build zfs, rtp, ... in the same build in the same apkbuild
2023-05-05 07:33:28 <omni> yes, I was thinking of that too...
2023-05-05 07:33:49 <omni> they already have to be rebuilt everytime the kernel is updated
2023-05-05 07:34:09 <psykose> yep
2023-05-05 07:34:19 <omni> but I guess you want to keep the community out-of-tree modules there and not in main
2023-05-05 07:34:43 <psykose> updating the modules is also a lot easier than rebuilding the whole kernel every time
2023-05-05 07:34:44 <omni> and the APKBUILD files are quite big as is
2023-05-05 07:35:34 <omni> psykose: hmm?
2023-05-05 07:36:14 <psykose> upgrading zfs-lts takes like a minute since you don't build a whole kernel to do it
2023-05-05 07:39:09 <omni> ah, you mean that if zfs-lts, for example, was put in the same job as linux-lts then the kernel would have to be rebuilt each time zfs is upgraded
2023-05-05 07:48:31 <omni> would it be easier if I just convinced linus to accept zfs into his kernel?
2023-05-05 07:55:40 <ikke> Define easier 
2023-05-05 08:07:07 <psykose> for distro maintainers? yeah
2023-05-05 08:07:10 <psykose> ;)
2023-05-05 08:15:22 <ncopa> so basically, 3rd party modules are broken with module signing
2023-05-05 08:15:42 <ncopa> its kinda the purpose of kernel module signing in the first place, isnt it
2023-05-05 08:18:36 <ncopa> next question is, can we use the abuild key for this?
2023-05-05 08:23:18 <ncopa> I suppose we don't want to do that
2023-05-05 08:23:36 <ncopa> but we could probably store the private key together with the abuild key
2023-05-05 08:27:09 <ncopa> hm
2023-05-05 08:39:30 <omni> and have a static signed keypair?
2023-05-05 08:43:02 <ncopa> yeah
2023-05-05 08:43:27 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/14873
2023-05-05 11:40:47 <ncopa> im not sure if this is a good idea or not: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/204
2023-05-05 11:40:58 <ncopa> do we want abuild-keygen to generate a kernel key?
2023-05-05 11:43:57 <psykose> it seems like something very infra specific, so idk who would ever use that
2023-05-05 11:51:08 <ncopa> anyone who wants to build their own kernel and own thirdparty kernel modules (eg zfs) and sign them
2023-05-05 11:55:12 <ncopa> i'd like to be able to generate the key with a oneliner to avoid doing manual work on builders
2023-05-05 11:57:21 <ncopa> I intend to use it with: https://tpaste.us/vNaO
2023-05-05 12:00:24 <oldes> Hi, does anybody know, what I can do with this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44734#note_305045
2023-05-05 12:02:08 <psykose> ncopa: yeah, for that it seems fine
2023-05-05 12:02:37 <ncopa> oldes: squashing the commits into a single commit would be nice
2023-05-05 12:03:03 <ncopa> eg `git rebase -i` and mark the two last commits as 'fixup'
2023-05-05 12:03:32 <ncopa> so it looks like you got it right first time you tried
2023-05-05 12:05:56 <ncopa> psykose: do you mind approving it? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/204
2023-05-05 12:07:33 <psykose> ncopa: funnily i can't even though i can merge it :D
2023-05-05 12:07:41 <psykose> but yeah i read it
2023-05-05 12:07:43 <psykose> looks alright
2023-05-05 13:53:43 <ncopa> here comes rc4
2023-05-05 21:24:25 <omni> ncopa: reading again, only if you require modules to be signed (modules.sig_enforce=1 on the cmdline) 3rd party modules won't load
2023-05-05 21:26:10 <omni> isn't it still an improvement though? if you choose to enforce then only signed modules can be loaded, even though they're limited to in-tree ones
2023-05-05 21:34:07 <minimal> there's a distinction to be made between out-of-kernel but packaged by Alpine kernel modules, and kernel modules not packaged by Alpine
2023-05-05 21:36:08 <minimal> as an example, on Debian using Virtualbox package provided by Oracle the vbox kernel modules are obviously not signed by Debian and so (by default) cannot be loaded when module signed is enforced (i.e. secure boot). The solution to that is for the machine owner/user to create their own key, load it into the UEFI's MOK, and sign the Virtualbox modules with that key and then they can be loaded
2023-05-05 21:36:10 <omni> yes, here I'm only referring to in-tree and out-of-tree modules packaged by alpine
2023-05-05 21:36:49 <minimal> it would make sense for Alpine packaged out-of-kernel modules to be signed by the same key as used to sign the Alpine kernel packages
2023-05-05 21:37:14 <omni> yes, this is what I'd like ot see
2023-05-05 21:37:56 <minimal> omni: I thought you said you wanted signing to be limited to in-tree modules, sorry I misunderstood
2023-05-05 21:39:22 <omni> ah, no, I meant that I think it is still an improvement, if I understand it correctly, that by requiring modules to be signed you can make it harder for malicious actors to insert modules
2023-05-05 21:40:39 <omni> so I still find use for this, even though I cannot (yet) use it where I need/want out-of-tree/3rd party modules like the zfs ones
2023-05-05 21:43:26 <bl4ckb0ne> anybody tried to build proton/wine-ge-custom recently?
2023-05-06 00:26:31 <psykose> bl4ckb0ne: that makes zero sense to package
2023-05-06 00:26:41 <psykose> below zero actually
2023-05-06 00:35:39 <bl4ckb0ne> i didnt talk about packaging
2023-05-06 00:39:16 <psykose> :D
2023-05-06 00:39:21 <psykose> i guess the last time i tried was many moons ago
2023-05-06 00:39:41 <psykose> anything specific you were looking at? i could give it a go, but these days i just curl the proton-ge-custom tarball into the steam folder
2023-05-06 00:40:51 <orbea> i presume because of musl not in alpine?
2023-05-06 00:41:23 <orbea> or are there ways of getting steam to work? :)
2023-05-06 00:52:47 <bl4ckb0ne> they have that shitty way of running the build in a container, dunno if it works on musl
2023-05-06 00:53:01 <bl4ckb0ne> last time i checked i had a build but i rebooted and wiped the tmp build
2023-05-06 01:00:06 <bl4ckb0ne> and the wine-ge stuff seemes a bit more sane to build than proton
2023-05-06 01:03:51 <psykose> afaik that's still the best way
2023-05-06 01:04:05 <psykose> i don't remember how well that vagrant thing worked
2023-05-06 01:04:47 <bl4ckb0ne> it starts an ubuntu image
2023-05-06 01:05:03 <bl4ckb0ne> wonder how hard it would be to replace it with that trendy docker distrib
2023-05-06 01:05:08 <bl4ckb0ne> dunno what its name was
2023-05-06 01:05:29 <bl4ckb0ne> alps linux?
2023-05-06 01:05:36 <psykose> impossible
2023-05-06 01:05:45 <bl4ckb0ne> was some dumb mountains name
2023-05-06 01:08:42 <sam_> snowdonia linux
2023-05-06 01:09:48 <bl4ckb0ne> want to play the new diablo but I dont want to put up with arch
2023-05-06 01:14:20 <psykose> install flatpak steam
2023-05-06 01:14:42 <psykose> curl -L https://github.com/GloriousEggroll/proton-ge-custom/releases/download/GE-Proton8-1/GE-Proton8-1.tar.gz | tar xz -C .var/app/com.valvesoftware.Steam/data/Steam/compatibilitytools.d
2023-05-06 01:14:44 <psykose> start it
2023-05-06 01:14:46 <psykose> yw
2023-05-06 01:14:53 <bl4ckb0ne> tyvm
2023-05-06 01:14:57 <bl4ckb0ne> but diablo is not on steam
2023-05-06 01:15:05 <psykose> i think that's a skill issue
2023-05-06 01:15:17 <bl4ckb0ne> its an interface issue
2023-05-06 01:16:42 <psykose> more realistically though uhh idk
2023-05-06 01:16:50 <bl4ckb0ne> hu maybe flatpak has lutris
2023-05-06 01:16:53 <psykose> i think there was flatpak lutris that had stuff
2023-05-06 01:16:53 <psykose> yeah
2023-05-06 01:17:56 <bl4ckb0ne> oh wait no i need xwayland for steam
2023-05-06 01:17:59 <bl4ckb0ne> why cant we have nice things
2023-05-06 01:18:46 <bl4ckb0ne> and pulse
2023-05-06 01:18:48 <bl4ckb0ne> uuuuuuuuuugh
2023-05-06 01:22:27 <psykose> yea
2023-05-06 01:22:32 <psykose> what is ur audio stack, bare alsa
2023-05-06 01:22:39 <bl4ckb0ne> yeah
2023-05-06 01:23:26 <bl4ckb0ne> probably with apulse i guess
2023-05-06 01:43:39 <Daaanct12> pulseaudio is the best
2023-05-06 01:47:14 <bl4ckb0ne> wrong
2023-05-06 01:54:41 <orbea> steam works with straight alsa for me still
2023-05-06 02:15:41 <bl4ckb0ne> wait i think that was signal that shat itself without pulse
2023-05-06 02:56:17 <orbea> iirc steam just needs an appropriate alsa config in the user's $HOME
2023-05-06 03:02:15 <bl4ckb0ne> yeah i have a .asoundrc because my dac device id changes every reboots
2023-05-06 03:02:18 <bl4ckb0ne> fun times
2023-05-06 03:04:55 <valerius> bl4ckb0ne, me too :p
2023-05-06 03:05:39 <bl4ckb0ne> it sucks
2023-05-06 03:05:54 <valerius> I was fine with OSS back in the good old days
2023-05-06 03:06:25 <valerius> just smash the audio data into /dev/dsp
2023-05-06 03:11:09 <bl4ckb0ne> time to write another audio stack
2023-05-06 03:14:10 <valerius> 
ACTION resists temptation to do so

2023-05-06 03:15:37 <psykose> i've used pipewire for years and have touched the config like two times
2023-05-06 03:16:37 <valerius> has it been around long enough for years to be plural?
2023-05-06 03:16:45 <valerius> if that is the case... oh shit... time is passing too fast
2023-05-06 03:17:37 <orbea> according to wiki the initial release is: 20 June 2017; 5 years ago
2023-05-06 03:17:39 <psykose> 0.3.10 was almost 3 years ago yeah
2023-05-06 03:17:55 <psykose> pre 0.3 was just video unless i remember wrong
2023-05-06 03:19:57 <bl4ckb0ne> tempted to use pipewire
2023-05-06 03:20:02 <bl4ckb0ne> will you help me psykose 
2023-05-06 03:20:43 <psykose> it's mostly just starting `pipewire` `pipewire-pulse` `wireplumber` as your user and that's about it
2023-05-06 03:20:56 <psykose> assuming you're a normal person with a functioning xdg runtime dir and dbus-run-session
2023-05-06 03:21:10 <valerius> lol, normal people use Windows
2023-05-06 03:22:42 <psykose> personally i have an s6 scandir for user services i throw that in, but /usr/libexec/pipewire-launcher also starts those i guess with no supervision
2023-05-06 03:23:04 <psykose> you also probably want to delete any custom alsa config, and install pipewire pipewire-alsa pipewire-pulse wireplumber
2023-05-06 03:25:12 <bl4ckb0ne> can i use sway with that
2023-05-06 03:25:31 <psykose> you mean `exec /..` as a config line? sure
2023-05-06 03:27:36 <bl4ckb0ne> hmm
2023-05-06 04:41:58 <tomalok> ikke, ncopa: just remembered that the docker APK is virtual and just pulls other APKs in -- so, if someone really just wanted to run dockerd and hte base cli, they could simply install docker-engine and docker-cli instead...  so "docker" is more of a functional suite, so yes, it does make sense to start having it pull in docker-cli-buildx -- should
2023-05-06 04:41:58 <tomalok> be quick to add -- but we should probably also call that out in release notes
2023-05-06 04:42:52 <ikke> 👍
2023-05-06 04:44:41 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.18.0
2023-05-06 05:47:18 <ncopa> so docker package should depend on docker-engine, docker-cli and docker-cli-buildx
2023-05-06 05:47:31 <ncopa> and docker-cli-buildx should not depend on anything
2023-05-06 05:49:24 <tomalok> docker-cli-buildx depends on docker-cli
2023-05-06 05:49:33 <ncopa> we need to swap that
2023-05-06 05:49:42 <ncopa> so we dont get a circular dep build time
2023-05-06 05:49:54 <tomalok> yep, basically
2023-05-06 05:50:08 <ncopa> i'll push that
2023-05-06 05:50:42 <tomalok> zzz...
2023-05-06 06:05:28 <ncopa> ikke: can you please help me crete kernel signing keys on build-{edge,3-18}-{aarch64,armhf,armv}?
2023-05-06 06:05:49 <ncopa> similar to this: for i in ppc64le s390x x86 x86_64; do ssh buildozer@build-3-18-$i abuild-keygen --kernel || break; done
2023-05-06 06:06:20 <ncopa> but for both edge and 3-18
2023-05-06 06:10:28 <ikke> ncopa: will do that this afternoon
2023-05-06 06:14:30 <ncopa> thanks!
2023-05-06 06:24:38 <ikke> ncopa: nm, already did it
2023-05-06 06:39:35 <ncopa> aweseome! thanks!
2023-05-06 06:39:44 <ncopa> i'll push kernel update in a minute
2023-05-06 10:51:16 <sam_> psykose: good heuristic I used a while ago (and am now checking again) for stale intltool deps: grep -rsin meson -l | xargs grep -l "intltool"
2023-05-06 10:51:18 <sam_> ditto cmake
2023-05-06 10:51:27 <sam_> there's still a few oddballs out there using it with meson/cmake but very few, so usually an error
2023-05-06 10:53:02 <psykose> i just ran that, waited like 10 seconds, cancelled it, replaced it with rg, and it finished in 0.1s
2023-05-06 10:53:03 <psykose> lmao
2023-05-06 10:53:39 <sam_> fuck i dont want the rg shills to win but this is killing me
2023-05-06 10:54:21 <psykose> :)
2023-05-06 10:55:03 <psykose> it helps you can also pass shit like -g \*.ebuild and it skips any garbage that was there i guess
2023-05-06 10:55:08 <psykose> stale builddirs are inline in aports
2023-05-06 11:06:27 <psykose> got 35
2023-05-06 11:06:45 <sam_> sick
2023-05-06 11:06:53 <sam_> what do you mean builddirs btw? like removed packages or something else?
2023-05-06 11:06:57 <sam_> and yeah, good point, ive done an alias now for rg
2023-05-06 11:07:02 <sam_> 'rge'
2023-05-06 11:07:04 <sam_> with the grep-like format
2023-05-06 11:07:52 <psykose> the actual source directories with unpacked source
2023-05-06 11:07:58 <psykose> gets built in ./src
2023-05-06 11:22:15 <roooy[m]> !!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW on TG 
2023-05-06 11:22:15 <roooy[m]> https://t.me/FloraGordon
2023-05-06 13:08:05 <sam_> scrubbing all that intltool makes me feel very clean
2023-05-06 13:08:11 <sam_> like i've taken out 5 bin bags
2023-05-06 13:08:19 <ikke> lol
2023-05-06 13:10:02 <psykose> just 5?
2023-05-06 13:10:29 <psykose> when i was moving out of glasgow i think i took out a stack of 50 pizza boxes
2023-05-06 13:10:32 <psykose> has to be at least that good
2023-05-06 13:11:05 <sam_> in uni there was this big drama about a stolen loaf of bread
2023-05-06 13:11:08 <sam_> i couldn't stand any of my flatmates
2023-05-06 13:11:41 <sam_> on the last day, moving out, we found a solid black bag behind the toaster
2023-05-06 13:11:52 <sam_> i mean it literally couldn't have been moldier
2023-05-06 13:11:54 <ikke> oof
2023-05-06 13:11:55 <sam_> it was pure 100% mold
2023-05-06 13:12:03 <ikke> biohazard
2023-05-06 13:12:08 <sam_> absolutely!
2023-05-06 13:30:08 <ikke> Upgrading gitlab to 15.10
2023-05-06 13:34:41 <ikke> Done
2023-05-06 13:36:21 <psykose> still says update available :D
2023-05-06 13:38:28 <ikke> 15.11 is latest
2023-05-06 14:43:50 <deflated8837> I am trying to build a peertube APKBUILD but when I build it I get this error ld-linux-x86-64.so.2: path not found.
2023-05-06 14:44:02 <deflated8837> What does this error mean?
2023-05-06 14:44:15 <psykose> that you just installed some files precompiled against glibc
2023-05-06 14:45:17 <deflated8837> ok
2023-05-06 14:45:43 <deflated8837> thanks
2023-05-06 14:45:50 <psykose> this whole thing just looks like some javascript
2023-05-06 14:45:56 <deflated8837> it is
2023-05-06 14:45:56 <psykose> looks useless to package
2023-05-06 14:51:28 <ikke> dhcp still does not work, no clue why
2023-05-06 14:51:42 <ikke> udhcpc failed to get a DHCP lease
2023-05-06 14:52:05 <psykose> strange
2023-05-06 14:54:13 <ikke> If I run tcpdump on the host, I see the container making requests and responses being sent back
2023-05-06 14:55:00 <ikke> cannot run tcpdump in the container :(
2023-05-06 14:55:06 <ikke> SIOCETHTOOL(ETHTOOL_GET_TS_INFO) ioctl failed: Function not implemented
2023-05-06 14:55:35 <psykose> aw
2023-05-06 14:55:55 <ikke> same with strace
2023-05-06 14:56:01 <ikke> attach: ptrace(PTRACE_ATTACH, 1163): Function not implemented
2023-05-06 14:58:32 <psykose> probably just container protections
2023-05-06 15:00:11 <ikke> I don't see any relevalt caps dropped
2023-05-06 15:00:32 <ikke> https://tpaste.us/QR0Q 
2023-05-06 15:02:22 <psykose> perhaps 'another' implies there's a default
2023-05-06 15:02:26 <psykose> generally ptrace is never allowed
2023-05-06 15:04:56 <ikke> it works on my x86_64 container on the same host
2023-05-06 15:05:43 <ikke> includes the same config
2023-05-06 15:06:15 <psykose> perhaps a qemuism then
2023-05-06 15:06:29 <ikke> Yeah, likely not implemented
2023-05-06 15:06:43 <ikke> rv64 is still building qemu
2023-05-06 15:07:16 <andypost[m]> ikke: IIRC docker container needs cap-add=SYS_PTRACE +privileged to use strace
2023-05-06 15:07:32 <ikke> andypost[m]: docker uses seccomps to limit a lot
2023-05-06 15:07:44 <psykose> it is, but the actual qemu used for the container is just on the x86_64 host isn't it
2023-05-06 15:07:49 <psykose> so it's done
2023-05-06 15:08:08 <ikke> psykose: yes, but was waiting before restarting the container
2023-05-06 15:08:13 <ikke> waiting for it to finish*
2023-05-06 15:08:14 <psykose> hehe
2023-05-06 15:09:36 <ikke> andypost[m]: and it works on the x86_64 containers, implying it's something specific to rv64
2023-05-06 15:09:47 <ikke> (or rv64 run via qemu-user)
2023-05-06 15:10:23 <andypost[m]> got it, thanks
2023-05-06 15:12:49 <Hello71> nsenter -n tcpdump
2023-05-06 15:13:16 <Hello71> although that won't help with qemu issues
2023-05-06 15:18:56 <ikke> getting this when trying dhcpcd: https://tpaste.us/KE4P 
2023-05-06 15:23:12 <tomalok> does wiki.alpinelinux.org have its own set of authnz, or is it tied into gitlab, etc?
2023-05-06 15:23:16 <psykose> own
2023-05-06 15:23:25 <tomalok> thx
2023-05-06 15:23:29 <psykose> alpine-standard went from 153 to 189mb this release
2023-05-06 15:23:34 <psykose> all in vmlinuz+modloop+initrd
2023-05-06 15:23:43 <psykose> kernel 8->10 :D
2023-05-06 15:23:51 <psykose> it's all that btf nonsense i think
2023-05-06 15:33:22 <ikke> I wonder what that 'Protocol not supported' is
2023-05-06 15:38:03 <tomalok> Docker 23 release notes for 3.18.0 updat'd.
2023-05-06 15:38:19 <ikke> tomalok: thanks
2023-05-06 15:54:23 <pj> sadly my contrib to docker will be in 24
2023-05-06 15:54:40 <pj> what's the policy on static / dynamic libraries
2023-05-06 15:56:49 <pj> openssl-libs-static > libssl.a
2023-05-06 15:56:49 <pj> mimalloc2-dev > libmimalloc.a
2023-05-06 15:56:49 <pj> libsecret-static > libsecret-1.a
2023-05-06 15:59:02 <psykose> there is none
2023-05-06 15:59:26 <pj> I suspected that
2023-05-06 15:59:35 <pj> the question is, does anyone care
2023-05-06 15:59:47 <psykose> hopefully people stop adding that stuff yeah
2023-05-06 15:59:52 <pj> also, mimalloc2-dev > *.h, every other package *-headers
2023-05-06 15:59:56 <pj> I mean
2023-05-06 16:00:09 <pj> should it be -static -libs-static -dev or what
2023-05-06 16:00:15 <psykose> pretty much every -dev is *.h and almost nothing is -headers
2023-05-06 16:00:27 <psykose> except things that are actually supposed to be named headers
2023-05-06 16:00:48 <pj> opencl-headers
2023-05-06 16:00:54 <pj> bsd-compat-headers
2023-05-06 16:01:06 <pj> vulkan-headers
2023-05-06 16:01:09 <pj> plenty of headers there
2023-05-06 16:01:22 <pj> and some random py3 stuff
2023-05-06 16:01:35 <psykose> wow 3 things
2023-05-06 16:01:40 <psykose> compared to 3k -dev packages
2023-05-06 16:01:56 <pj> well then get your shit right
2023-05-06 16:02:05 <pj> smh
2023-05-06 16:02:28 <pj> also, what about the .a
2023-05-06 16:03:09 <psykose> generally just intentionally removed
2023-05-06 16:03:17 <psykose> when it's there it's -static unless it's missed
2023-05-06 16:03:21 <psykose> with an exception of cmake
2023-05-06 16:03:24 <psykose> can't split files from cmake
2023-05-06 16:03:54 <pj> I mean about the name
2023-05-06 16:03:59 <ikke> This has been changed numerous times
2023-05-06 16:04:04 <pj> -libs-static , -static , -dev
2023-05-06 16:04:06 <psykose> it's pretty much always been -static
2023-05-06 16:04:12 <ikke> last consesus was that -static is for static binaries
2023-05-06 16:04:23 <psykose> i'm pretty sure that was a "consensus"
2023-05-06 16:04:32 <psykose> aka a bunch of people did some talking that doesn't matter
2023-05-06 16:04:46 <psykose> much like the "consensus" on what the testing/ repository is
2023-05-06 16:05:42 <psykose> currently there are a bunch of -static and they are all static libraries, except about maybe 10 executables
2023-05-06 16:06:18 <psykose> the -dev ones are either cmake or forgotten to split
2023-05-06 16:39:49 <ikke> hmm, fakeroot seems to be hanging for me since upgrading the host to 3.18
2023-05-06 16:39:53 <Hello71> -headers is because there's no opencl, bsd-compat, or vulkan packages
2023-05-06 16:42:58 <psykose> there is for opencl
2023-05-06 16:43:05 <psykose> but i kept the headers name for compat
2023-05-06 16:43:33 <psykose> -dev just pulls it anyway
2023-05-06 16:43:44 <psykose> ikke: fully every time, or one-off?
2023-05-06 16:43:50 <ikke> every time
2023-05-06 16:43:52 <psykose> i've had weird fakeroot behaviour sporadiacally
2023-05-06 16:43:53 <psykose> hmmmmm
2023-05-06 16:43:56 <psykose> that sounds not good
2023-05-06 16:44:00 <ikke> apparently it's fakeroot-tcp
2023-05-06 16:44:09 <psykose> wrong one
2023-05-06 16:44:22 <ikke> it gets installed with abuild-rootbld
2023-05-06 16:44:30 <ikke> checking the normal one now
2023-05-06 16:45:26 <psykose> it has a lower version tho
2023-05-06 16:45:40 <psykose> ah
2023-05-06 16:45:41 <psykose> nvm
2023-05-06 16:45:44 <psykose> prio was changed a bit
2023-05-06 16:45:46 <psykose> i'll fix it
2023-05-06 16:45:56 <ikke> World updated, but the following packages are not removed due to:
2023-05-06 16:45:58 <ikke>   fakeroot-tcp: alpine-sdk
2023-05-06 16:46:35 <ikke> yeah, works with the ipc one
2023-05-06 16:46:44 <ikke> apk add fakeroot \!fakeroot-tcp
2023-05-06 16:48:17 <psykose> seemingly that virtual behaviour was flipped a bit
2023-05-06 16:48:33 <psykose> before having a provides=somename with any prio didn't matter if the real name existed, since it had a version
2023-05-06 16:48:51 <psykose> now regular fakeroot comes second even with bigger version because it has no prio and the other is =1
2023-05-06 16:48:51 <psykose> hehe
2023-05-06 16:49:11 <psykose> in some ways this is better (version doesn't matter i guess, and can provide same name) but have to remember to set prios
2023-05-06 16:49:19 <psykose> should be fixed
2023-05-06 17:01:00 <ikke> psykose: confirmed
2023-05-06 17:01:05 <psykose> :)
2023-05-06 17:01:37 <ikke> wonder why the builders weren't impacted
2023-05-06 17:02:00 <ikke> but perhaps related to the package I was building
2023-05-06 17:16:25 <umk3[m]> is dhcpcd-ui still usable for anyone?
2023-05-06 17:16:46 <umk3[m]> dhcpcd service at least seems to work fine
2023-05-06 17:22:51 <psykose> requires unpriv sock to be set up i guess
2023-05-06 17:28:23 <psykose> yeah was just a wrong dir
2023-05-06 17:28:32 <psykose> but the ui only works if you don't use the networking service
2023-05-06 17:29:09 <psykose> i.e. dhcpcd service has to be both master and control the interfaces
2023-05-06 17:29:32 <psykose> just starting it after another dhcp client via networking doesn't work, neither does networking that spawns dhcpcd's for you, or that with dhcpcd service
2023-05-06 17:29:38 <psykose> only pure dhcpcd works with ui
2023-05-06 17:40:10 <umk3[m]> thank you psykose, I understand, networking service has to be disabled
2023-05-06 17:40:47 <umk3[m]> do you get this when trying to start dhcpcd-gtk?
2023-05-06 17:40:51 <umk3[m]> (dhcpcd-gtk:4549): Gtk-CRITICAL **: 14:39:47.780: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
2023-05-06 17:41:36 <psykose> yea
2023-05-06 17:41:41 <psykose> well
2023-05-06 17:41:45 <psykose> that in itself doesn't mean anything
2023-05-06 17:41:46 <umk3[m]> maybe in xorg works fine but not on wayland
2023-05-06 17:41:51 <psykose> half the gtk3 shit shows that
2023-05-06 17:42:05 <psykose> and no, if it worked in xorg it would work with GDK_BACKEND=x11 and xwayland
2023-05-06 17:42:06 <psykose> doesn't
2023-05-06 17:42:13 <psykose> but yeah it doesn't show anything
2023-05-06 20:53:42 <omni> ncopa: I installed the latest linux-lts package 6.1.27-r2 and see that modules are signed with the new key, including the zfs ones
2023-05-06 20:54:02 <omni> but when booting with module.sig_enforce=1 I don't see anything in /proc/keys
2023-05-06 20:54:43 <omni> so I'm wondering if something is still missing..
2023-05-06 20:55:13 <omni> SORRY!
2023-05-06 20:55:15 <omni> :D
2023-05-06 20:55:29 <omni> only root can read the contents of that file, everything is fine
2023-05-06 20:56:17 <psykose> :)
2023-05-06 21:56:21 <omni> I've also upgraded a couple of VMs from 3.17.3 to 3.18.0_rc4 without issues, very few packages installed but still
2023-05-07 06:02:26 <EvTheFuture> Quick question... One of the packages I'm maintaining seem to have ditched some files that were in a subpackage. Do I need to make some sort of transition in order to remove it when upgrading or how do I handle it?
2023-05-07 06:05:08 <ikke> If the files were part of the subpackage, but not anymore, apk will automatically remove it
2023-05-07 06:24:25 <EvTheFuture> @ikke: thanks
2023-05-07 16:48:15 <pj> 
ACTION hugs ptrc

2023-05-07 16:50:55 <ptrc> thanks~
2023-05-07 18:06:09 <skarnet> 
ACTION has no idea why but he hugs ptrc too

2023-05-07 18:18:20 <ptrc> well, i assume it was about the mckay stuff, either the evergreen telegram group chat drama or !43307
2023-05-07 18:18:47 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43307#note_305675
2023-05-07 18:24:41 <Ermine> https://i.imgur.com/iWKad22.jpeg
2023-05-07 18:37:12 <skarnet> ptrc: okay, if you're the one dealing with this guy, have all my hugs in advance, stockpile them, you'll need them
2023-05-07 18:40:34 <Ermine> 
ACTION brings tea and pastries to ptrc

2023-05-07 18:45:34 <ptrc> thanks :3
2023-05-07 20:46:36 <pj> ptrc: both, and I too lost braincells reading that conversation
2023-05-07 21:25:29 <Newbyte> 
ACTION snatches the hugs and runs away

2023-05-08 06:25:55 <ncopa> good morning! lets get the 3.18.0 release out tomorrow
2023-05-08 06:27:50 <psykose> all i can think of that needs fixing is https://gitlab.alpinelinux.org/alpine/aports/-/issues/14877
2023-05-08 06:30:49 <pj> 3.18 would be pog
2023-05-08 06:45:03 <ncopa> im looking into it. for some reason there is no /etc/init.d/mdev
2023-05-08 06:46:20 <psykose> weirdly the xen setup script adds udev too
2023-05-08 06:46:29 <psykose> not really sure how that works
2023-05-08 06:46:45 <ncopa> i suspect thats leftovers
2023-05-08 06:46:51 <ncopa> but i think i know why this happens
2023-05-08 06:48:17 <psykose> no busybox-mdev package
2023-05-08 06:48:30 <ncopa> yes, and i think i know why
2023-05-08 06:48:40 <ncopa> im trying to find the commit
2023-05-08 06:49:15 <psykose> it wasn't the original devd rework since that was 3.17
2023-05-08 06:49:18 <psykose> narrows it down a bunch
2023-05-08 06:49:30 <psykose> barely did anything there this cycle
2023-05-08 06:52:55 <ncopa> it may be a bug in apk-tools
2023-05-08 06:55:07 <psykose> how so
2023-05-08 06:55:22 <ncopa> still trying to find out
2023-05-08 06:55:36 <ncopa> im trying to reproduce what I thought it was
2023-05-08 06:55:39 <ncopa> but i couldnt
2023-05-08 06:57:08 <ncopa> i suspect some package pulls in udev to cdrom image repositories
2023-05-08 06:57:55 <ncopa> meaning that apk figures out that the  dev-openrc dependency is satisfied with udev, and don't need to pull in busybox-mdev-openrc
2023-05-08 06:58:18 <ncopa> so its not on the iso image, and can not be installed to tmpfs root at boot
2023-05-08 06:58:27 <ncopa> and nothing provides `dev` service
2023-05-08 07:00:14 <psykose> the package that pulls udev is multipath-tools
2023-05-08 07:03:34 <ncopa> but its not a new thing
2023-05-08 07:03:50 <ncopa> been like that since 3.17
2023-05-08 07:03:50 <psykose> yep
2023-05-08 07:04:03 <ncopa> so i think it is due to change in apk-tools behavior
2023-05-08 07:04:12 <ncopa> and i think the apk-tools behavior is correct
2023-05-08 07:04:36 <ncopa> wait a sec
2023-05-08 07:04:54 <ncopa> yes
2023-05-08 07:05:44 <ncopa> its just the price we pay for the complexity of provides and pluggable dev handler
2023-05-08 07:07:15 <ncopa> we get unexpected surprises
2023-05-08 07:09:37 <ncopa> anybody know why we ship multipath-tools with xen?
2023-05-08 07:16:34 <HRio> guess its needed for some centralized storage setups
2023-05-08 07:19:15 <ncopa> any objection to remove it from xen image?
2023-05-08 07:19:18 <psykose> eudev's dev-openrc has a lower prio tho
2023-05-08 07:19:39 <psykose> i don't think the prio matter at all here
2023-05-08 07:19:45 <ncopa> it doesnt matter. busybox-mdev-openrc does not exist at all
2023-05-08 07:20:24 <psykose> as a package? it does
2023-05-08 07:20:31 <ncopa> the package is not added to the boox iso
2023-05-08 07:20:37 <psykose> the issue is multipath tools pulling eudev instead
2023-05-08 07:20:51 <psykose> and the mkimg scripts not explicitly adding busybox-mdev
2023-05-08 07:20:59 <psykose> which they should
2023-05-08 07:21:04 <psykose> because that is what they use
2023-05-08 07:21:35 <psykose> the dev-openrc is a virtual but the images only work with one, so they have to depend on the one they actually use
2023-05-08 07:21:41 <psykose> that it worked by magic is just magic
2023-05-08 07:21:58 <psykose> so the fix is apks=busybox-mdev
2023-05-08 07:22:00 <psykose> into every image
2023-05-08 07:22:41 <psykose> unless you want to only tangentially 'fix' it by removing what pulls eudev (and hence eudev-openrc that gives dev-openrc), until it breaks again in 2 years
2023-05-08 07:23:51 <ncopa> meaning that even if we introduce provides with provides priority in any form anywhere, we need to make sure that we still add explicit deps
2023-05-08 07:23:58 <ncopa> where it should be
2023-05-08 07:24:28 <ncopa> we cannot add provides with provider priority and assume everything just works
2023-05-08 07:26:07 <psykose> like we've always done already
2023-05-08 07:26:15 <ncopa> yeah
2023-05-08 07:26:24 <ncopa> its just the price we pay for the added complexity
2023-05-08 07:29:54 <HRio> ncopa: I think it will break some setups. As that's might be where the persistent storage actually is. I have storage via iscsi (open-iscsi) with xen booting "diskless"
2023-05-08 07:31:56 <ncopa> ok. lets keep it
2023-05-08 07:32:08 <HRio> and more resilient setups probably uses multipath-tools for this
2023-05-08 07:32:20 <ncopa> why is busybox-mdev-openrc a subpackage in the first place?
2023-05-08 07:32:40 <ncopa> introduced here 8262f47378327d5f46f8615a3979e878f80a0cb5
2023-05-08 07:34:07 <psykose> so the mdev init.d file is separate from the rest of the init.d files that are always used regardless of devd
2023-05-08 07:34:38 <ncopa> why does it need to be separate?
2023-05-08 07:34:44 <psykose> from busybox itself?
2023-05-08 07:35:17 <ncopa> from busybox-openrc
2023-05-08 07:35:29 <ncopa> why is it not in busybox-openrc
2023-05-08 07:35:48 <psykose> so the mdev init.d file is separate from the rest of the init.d files that are always used regardless of devd, and you don't have `mdev` init.d when using another one
2023-05-08 07:36:05 <pj> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/55
2023-05-08 07:36:47 <psykose> so it's actually apks=busybox-mdev-openrc
2023-05-08 07:37:39 <ncopa> why is mdev special compared to syslog or ntpd?
2023-05-08 07:38:06 <ncopa> i mean you can run any other ntpd or syslog implementation instead of the busybox one
2023-05-08 07:38:34 <ncopa> even if the busybox etc/init.d/ntpd is still there
2023-05-08 07:38:46 <psykose> it's just how it was written to allow the dev-openrc virtual
2023-05-08 07:38:57 <psykose> otherwise there is no dev-openrc for busybox at all
2023-05-08 07:39:06 <psykose> it would be an empty subpackage instead
2023-05-08 07:39:26 <psykose> it would also fix this issue (busybox-openrc would have the missing mdev)
2023-05-08 07:39:27 <ncopa> unless busybox-openrc provided dev-openrc
2023-05-08 07:39:35 <psykose> what
2023-05-08 07:40:14 <psykose> that makes zero sense so i'm not even going to pretend i read it
2023-05-08 07:40:20 <psykose> anyway just add apks=busybox-mdev-openrc
2023-05-08 07:41:33 <ncopa> well, busybox is a 'catch-all' thingy. we ship a bunch of stuff in busybox (in general). its the base of alpine
2023-05-08 07:41:45 <ncopa> if you are not happy with busyb add stuff on top of it
2023-05-08 07:42:02 <ncopa> we can ship all the openrc stuff for busybox in busybox-openrc
2023-05-08 07:42:18 <ncopa> including mdev.initd
2023-05-08 07:42:32 <ncopa> togenter with the rest of the busybox provided services
2023-05-08 07:42:45 <ncopa> im just not happy that this bites us in the first place
2023-05-08 07:42:51 <ncopa> also
2023-05-08 07:43:27 <ncopa> for almost every other package that ships any openrc service, we do install_if="$pkg openrc"
2023-05-08 07:43:57 <ncopa> so you you have openrc installed, and install $pkg, we also get the openrc service. regardless if we intend to use it or not
2023-05-08 07:44:19 <ncopa> except for busybox openrc.
2023-05-08 07:44:40 <ncopa> so there is nothing automatic pulling in the busybox openrc stuff
2023-05-08 07:48:39 <ncopa> ah
2023-05-08 07:49:42 <ncopa> busybox-openrc is an explicit dependency of alpine-base
2023-05-08 07:49:48 <ncopa> thats what pulls it in
2023-05-08 08:15:15 <ncopa> HRio: i wonder if wen remove the nomodeset cmdline for xen?
2023-05-08 09:00:13 <HRio> ncopa: checked on a xen system running Debian bullseye, that system did not boot the dom0 kernel with nomodeset
2023-05-08 09:02:43 <HRio> https://github.com/alpinelinux/alpine-iso/commit/61a22aa626b6405d6d9ef1bcbf5afad1a4f9f080
2023-05-08 09:04:47 <HRio> commits doing this in old alpine-iso.git https://tpaste.us/BJXq
2023-05-08 09:52:11 <hcs> Hi guys, do any of you know the sacred incantations required to make i915 happy? (Or do any of you have comprehensive experience with i915?)
2023-05-08 11:11:10 <skarnet> ncopa: I had to add busybox-openrc as a dependency of alpine-base because it was required for compatibility with the previous setup where mdev and its startup script were hardcoded
2023-05-08 11:11:30 <skarnet> so users get a device manager by default as soon as they install
2023-05-08 11:12:48 <skarnet> and I have explained at length why the mdev script needed to be separate, not going to do it again :P
2023-05-08 11:53:32 <ncopa> yeah. we have different opinions on that subject
2023-05-08 11:55:05 <ncopa> my opinion is that if you don't explicitly specify which dev handler you want you should get mdev and not a broken system
2023-05-08 11:55:49 <skarnet> that's exactly what's happening right now
2023-05-08 11:55:59 <ncopa> and if you want other dev handler you need to explicitly configure it (eg rc-update add $devhandler ...)
2023-05-08 11:56:09 <skarnet> that's also exactly what's happening right now
2023-05-08 11:56:15 <ncopa> regardless of what packages that are installed
2023-05-08 11:57:29 <skarnet> ^ and that is why the separation had to happen
2023-05-08 11:57:55 <ncopa> i disagree with that
2023-05-08 11:58:13 <ncopa> it works as i explained after reverting 98aeed5e45585d219f2091170fa6c5b3c7517292
2023-05-08 11:58:30 <ncopa> sorry, after reverting d1014c82b176
2023-05-08 11:58:42 <ncopa> the 98aeed5e45585d219f2091170fa6c5b3c7517292 reverts d1014c82b176
2023-05-08 11:58:45 <ncopa> algitbot: hi
2023-05-08 11:59:32 <ncopa> d1014c82b176 (main/alpine-base: depend on dev-openrc) broke alpine-xen boot image
2023-05-08 11:59:49 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/14877
2023-05-08 12:00:35 <ncopa> but, yeah. lets not get there again. im done with that discussion
2023-05-08 12:00:47 <skarnet> yeah that's pretty weird, it should be strictly the same thing
2023-05-08 12:00:56 <skarnet> so I suppose it's an apk-tools bug indeed
2023-05-08 12:01:18 <skarnet> I don't think we disagree here, we want the same thing to happen
2023-05-08 12:01:42 <skarnet> I just relied on apk-tools being able to handle an indirection, which I shouldn't have :P
2023-05-08 12:02:18 <ncopa> i think apk-tools does the right thing
2023-05-08 12:02:23 <skarnet> hmmm, wait
2023-05-08 12:02:45 <psykose> skarnet: it's not a bug, eudev-openrc is installed so it's satisfied
2023-05-08 12:02:50 <psykose> the image has hardcoded expectations of using mdev with nobody adding the -mdev dep to the image
2023-05-08 12:02:53 <psykose> which is still broken
2023-05-08 12:02:54 <ncopa> and i think apk-tools did the wrong thin in alpine 3.17
2023-05-08 12:03:36 <skarnet> psykose: ahh, yes that's it
2023-05-08 12:03:41 <skarnet> so um
2023-05-08 12:03:51 <psykose> no, we can't just add the dep
2023-05-08 12:03:59 <psykose> here, let me write a page long essay on why this 1 line fix is wrong
2023-05-08 12:04:22 <skarnet> the proposed solution is to hardcode mdev *more* rather than actually, yknow, going along with the decision to abstract?
2023-05-08 12:04:33 <skarnet> yeah I *will* disagree with that
2023-05-08 21:03:08 <ncopa> ok here comes rc5
2023-05-08 21:09:20 <ncopa> hcs: what is the problem you are facing? i915 should work with modeset
2023-05-08 21:24:07 <ncopa> lets do 3.18.0 tomorrow!
2023-05-09 06:34:56 <HRio> ncopa: no problems observed with removal of nomodeset from the xen image for installation via HP iLO
2023-05-09 06:49:18 <pj> Good morning
2023-05-09 08:36:00 <ncopa> ugh.. dotnet builds
2023-05-09 08:36:17 <ncopa> i suppose this means we can not do release today :-(
2023-05-09 08:37:19 <psykose> if i had the ability to kill them that wouldn't have happened
2023-05-09 08:37:25 <psykose> regardless, what time did you plan that for
2023-05-09 08:37:30 <psykose> it should be clear in maybe 4-5 hours
2023-05-09 08:40:05 <ncopa> ok. lets see how it goes
2023-05-09 08:40:50 <psykose> actually you could slightly speed it up, if you want
2023-05-09 08:40:58 <psykose> just take edge-x86_64 offline by freezing the container
2023-05-09 08:41:13 <psykose> they share the same cpu so it would definitely meet under 4 hours, then do release
2023-05-09 08:41:15 <psykose> should be fine
2023-05-09 08:41:35 <psykose> it can deal with the same queue afterward
2023-05-09 08:42:26 <psykose> emphasis on freeze and not kill
2023-05-09 08:43:54 <consus[m]> Guys, is baremetal  autoinstall possible rn? Built-in or cloud-init perhaps.
2023-05-09 08:44:08 <consus[m]> Oops, wrong channel
2023-05-09 08:46:54 <psykose> ncopa: just do what i suggested and freeze edge-x86_64 and it'll all be fine
2023-05-09 10:24:29 <ikke> psnszsn_: done
2023-05-09 10:24:47 <ikke> oh, psykose is gone
2023-05-09 10:32:09 <pj> rip psykose
2023-05-09 10:48:15 <ikke> ncopa: dotnet just finished
2023-05-09 10:48:30 <ikke> 18 packages left to build
2023-05-09 10:51:03 <ncopa> great"
2023-05-09 10:51:32 <ikke> ftr, I ran lxc-freeze on the edge builder
2023-05-09 11:20:38 <ikke> oh, still some dotnet components left
2023-05-09 13:42:53 <ncopa> its getting late for release ...
2023-05-09 13:48:15 <ikke> 3 packages left, including firefox 
2023-05-09 14:01:10 <ncopa> + the stuff that has been pushed today
2023-05-09 14:01:19 <ncopa> which shouldnt be anything too heavy
2023-05-09 14:07:39 <minimal> ikke: re e2fsprogs I added a note to the draft Release Notes. There is a potential "solution", modify the /etc/mke2fs.conf file in the package to remove those 2 features. Not sure if that is a good idea.
2023-05-09 14:21:33 <ncopa> this is actually going pretty well
2023-05-09 14:23:35 <PabloCorreaGomez[m]> I also just realized we missed adding the necessary changes for GNOME Software in the release notes of GNOME. Just added a short sentence.
2023-05-09 14:24:46 <ncopa> super!
2023-05-09 14:53:06 <ncopa> I'm thikning that the release notes on wiki are pretty good https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.18.0
2023-05-09 14:53:17 <ncopa> maybe we should just copy it to alpinelinux.org
2023-05-09 14:53:30 <ncopa> and add a "highlights" section at the top
2023-05-09 14:54:27 <umk3[m]> wayland is very much usable now in alpine 3.18.0 with labwc 0.6.3
2023-05-09 14:55:35 <umk3[m]> for a window stacking desktop
2023-05-09 15:04:40 <ncopa> hum dotnet6....
2023-05-09 15:04:47 <ncopa> this will take a few more hours
2023-05-09 15:05:32 <ncopa> oh 1/58
2023-05-09 15:05:49 <ncopa> that blew the last hope of a relase today
2023-05-09 15:06:22 <ikke> :/
2023-05-09 15:06:27 <ncopa> or even release candidate
2023-05-09 15:06:29 <ikke> sadface
2023-05-09 15:06:33 <ncopa> :-(
2023-05-09 15:15:19 <ncopa> would also be nice if we could avoid push anything to testing til 3.18 is out
2023-05-09 15:18:10 <ikke> plasma awas just pushed
2023-05-09 15:21:15 <ncopa> yeah
2023-05-09 15:22:17 <ncopa> hum
2023-05-09 15:22:27 <ncopa> it might be doable within an hour I think
2023-05-09 15:22:32 <ncopa> or two
2023-05-09 15:34:17 <pj> why when creating a new release, a new branch isn't created from master and that being tracked by builders?
2023-05-09 15:35:42 <ikke> The idea is that everyone should focus on the releases (and fixing it) rather than focussing on new features
2023-05-09 15:36:35 <pj> They can focus by simply pushing to that branch though?
2023-05-09 15:45:26 <pj> Main issue I've seen for years in Alpine is that there is lack of communication and organisation between Alpine devs. since "the main communication channel" seems to be IRC (or at least it's chosen by majority), some are on Twitter, some are [nowhere]
2023-05-09 15:46:05 <ikke> Almost all devs (with push access) are here
2023-05-09 15:46:32 <pj> yeah, "almost all"
2023-05-09 15:46:39 <ikke> I just know one who isn't here
2023-05-09 15:46:51 <ikke> (and still active)
2023-05-09 15:47:08 <ikke> ok, 2
2023-05-09 15:47:38 <ikke> ncopa did send out a mail to ~alpine/devel
2023-05-09 15:48:09 <pj> yeah, and it seems like that mail isn't enough
2023-05-09 15:48:44 <pj> (I'm also counting people who are in this channel but aren't active)
2023-05-09 15:58:23 <ncopa> yeah, it is a challenge to coordinate thing when not everybody are in one place
2023-05-09 15:58:38 <ncopa> not everyone read emails (me included)
2023-05-09 15:58:46 <ncopa> not everyone uses IRC
2023-05-09 15:58:57 <ncopa> some are here and some are there
2023-05-09 15:59:30 <ncopa> so to coordinate I need to dupe the message for each available communication channel
2023-05-09 16:00:03 <ncopa> i was kinda hoping we could say "this is the channel. use it if you want join coordination"
2023-05-09 16:00:19 <ncopa> but no challen is perfect so far
2023-05-09 16:01:08 <ncopa> alright! builder is progressing with kde
2023-05-09 16:01:10 <ncopa> there is hope!
2023-05-09 16:04:02 <pj> yes, so to prevent that the branch could be split on first rc (or when _trying_ to make non-rc release), then "someone pushed something by accident" wouldn't happen
2023-05-09 16:04:49 <ncopa> yeah i know. its a trade off
2023-05-09 16:04:59 <ncopa> we have been doing like this since forever
2023-05-09 16:05:45 <pj> I knew someone would say that ;)
2023-05-09 16:06:17 <ncopa> i think it works fairly well
2023-05-09 16:06:30 <ncopa> now it is in everybodys interest to get the release out
2023-05-09 16:08:23 <pj> other idea would be to implement pre-receive hooks that refuse commits like moving packages (although due to commit title policy, it would be quite limited)
2023-05-09 16:08:57 <ncopa> probably not worth it
2023-05-09 16:09:47 <pj> also inconvenient because it would have to be configured when new release is planned and disabled after split is done
2023-05-09 16:10:02 <ncopa> yeah
2023-05-09 16:10:17 <ikke> Not too difficult, just not worth it
2023-05-09 16:10:29 <ncopa> just be patient and do best effort to coordinate is good enough for for now
2023-05-09 16:11:53 <ikke> ncopa: one thing you could do is send out an e-mail that you expect to do a release
2023-05-09 16:11:55 <pj> I apologise but I do not believe in best effort and "good enough" for now when "now" is "always", I prefer solving or preventing issues permanently
2023-05-09 16:12:00 <ikke> (maybe for next time)
2023-05-09 16:12:11 <pj> ikke: the devel ML gets such email
2023-05-09 16:13:17 <ncopa> we wont change it before 3.18 release (within a couple of hours) at least
2023-05-09 16:13:26 <ncopa> but im open for ideas after that
2023-05-09 16:13:34 <pj> although I think what could be better than email and even replace it, is gitlab notification messages
2023-05-09 16:13:43 <ncopa> i need to step out for an hour
2023-05-09 16:13:47 <pj> they appear on web and when doing git actions
2023-05-09 16:13:51 <ncopa> will try tag it after
2023-05-09 16:14:02 <pj> (from cli)
2023-05-09 16:14:04 <ikke> pj: you mean after they pushed a big build? :P
2023-05-09 16:14:39 <pj> yes, but if you enable it when starting first rc
2023-05-09 16:15:19 <pj> one thing I'm not sure if the path set in such message also applies to git cli
2023-05-09 16:15:55 <pj> would be quite annoying when someone pushes only some docker images or anything that isn't aports
2023-05-09 16:16:59 <pj> unrelated: when upgrading from 13.12 to 15.10 gitlab, they removed option to specify own colour of the message background and replaced it with list of ~10 colours
2023-05-09 16:17:31 <ikke> Yes, I'm aware
2023-05-09 16:17:44 <pj> was quite surprising when my blood red colour turned into purple
2023-05-09 17:14:43 <HRio> 3.18 builders are now idle
2023-05-09 17:28:26 <ncopa> i did rc6
2023-05-09 17:29:11 <ncopa> there were a number of updates in critical packages. Will just run the installer testsuite and tag 3.18.0
2023-05-09 17:59:01 <ncopa> hum... somethign is wrong
2023-05-09 18:02:57 <ncopa> WARNING: Erase the above disk(s) and continue? (y/n) [n] y
2023-05-09 18:02:57 <ncopa> line 1: unsupported command
2023-05-09 18:05:23 <ncopa> drats
2023-05-09 18:19:54 <Lock> Hello
2023-05-09 18:37:56 <ncopa> ok fixed, and tests passes. I'm tagging 3.18.0 now
2023-05-09 18:39:20 <Lock> Identify
2023-05-09 18:39:45 <Lock> Now?
2023-05-09 18:40:02 <Lockl00p> Hi
2023-05-09 19:02:01 <ncopa> hi
2023-05-09 19:09:17 <ncopa> anyone has a good overview doc on DT_RELR?
2023-05-09 19:09:29 <ncopa> I'd like to add alink to people who would like to read more about it
2023-05-09 19:11:18 <pj> perhaps https://maskray.me/blog/2021-10-31-relative-relocations-and-relr ?
2023-05-09 19:11:19 <sam_> https://maskray.me/blog/2021-10-31-relative-relocations-and-relr
2023-05-09 19:11:21 <sam_> jinx
2023-05-09 19:18:09 <ikke> ncopa: need any help?
2023-05-09 19:20:10 <ncopa> im writing release notes
2023-05-09 19:20:29 <ncopa> let me create a MR with a draft
2023-05-09 19:22:42 <ncopa> I need to take a break, but feel free to fill in thehttps://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/63
2023-05-09 19:23:03 <ncopa> fill in the missing spots https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/63
2023-05-09 19:28:25 <pj> isn't that MR missing the post markdown file?
2023-05-09 19:29:38 <ikke> yes
2023-05-09 19:34:04 <ncopa> added. sorry
2023-05-09 19:34:23 <ncopa> if you could help we write it, i'll start sign the images and prepare for the docker images
2023-05-09 19:34:48 <ncopa> we hsuld also mention something about the tiny-cloud stuff that was added
2023-05-09 19:34:56 <ncopa> but that needs some better documentation
2023-05-09 19:36:35 <pj> looking at ISC dhcp it seems still to be in main
2023-05-09 19:40:11 <pj> or is ISC dhcp supposed to move to community after 3.18
2023-05-09 19:40:35 <ikke> It's under deprecation, that would make sense
2023-05-09 19:40:44 <ikke> But then the changelog needs to be adjusted
2023-05-09 19:44:47 <pj> I added a suggestion on how could it be worded, feel free to work it out
2023-05-09 19:46:49 <ncopa> i think mentioning ISC was leftovers from when I copied from 3.17 release notes
2023-05-09 19:49:02 <pj> ah yes
2023-05-09 19:49:05 <pj> PHP 8.0 too
2023-05-09 19:49:26 <ncopa> heh, someone suggested to add Kea note lat time, but never followed up on actually moving it to community
2023-05-09 19:49:30 <ncopa> oh well
2023-05-09 19:49:36 <pj> but at the same time it doesn't sound good :)
2023-05-09 19:49:38 <ncopa> remove php 8.0
2023-05-09 19:51:58 <ncopa> ikke: can you please also invalidate the cdn cache for latest-stable?
2023-05-09 19:52:35 <ikke> ncopa: on it
2023-05-09 19:59:35 <ncopa> do we have anything for deprecation notes?
2023-05-09 20:00:42 <ikke> In what sense?
2023-05-09 20:00:56 <ncopa> question is if I should remove the section
2023-05-09 20:01:47 <ikke> Oh, you mean if we have anything that is deprecated this release
2023-05-09 20:04:04 <ncopa> yes
2023-05-09 20:04:53 <ikke> Cannot recall anything
2023-05-09 20:05:25 <pj> I'm not aware of anything either
2023-05-09 20:05:42 <pj> psykose would know
2023-05-09 20:18:09 <ikke> ncopa: would it make sense to stop listing older releases in pkgs.a.o?
2023-05-09 20:18:14 <ikke> We now list up to 3.3
2023-05-09 20:18:19 <ikke> (or down to)
2023-05-09 20:22:54 <ikke> Started importing 3.18 into aports-turbo
2023-05-09 20:22:56 <ikke> will take aa bit
2023-05-09 20:24:33 <ncopa> yeah
2023-05-09 20:24:52 <ncopa> makes sense to drop anything that is not supported
2023-05-09 20:25:42 <ncopa> well, we can keep a few unsupported generations
2023-05-09 20:26:10 <ncopa> but we can definitively drop anything older than 3.10
2023-05-09 20:26:41 <ikke> alright, will do that tomorrow
2023-05-09 20:33:53 <ikke> ncopa: did you unfreeze x86_64 edge?
2023-05-09 20:36:44 <ncopa> ikke: i did
2023-05-09 20:36:52 <ncopa> as soon the 3.18 release was done
2023-05-09 20:36:59 <ikke> thanks
2023-05-09 20:37:32 <ncopa> I updated the release notes draft
2023-05-09 20:37:43 <ikke> I was just reviewing it
2023-05-09 20:38:32 <ncopa> and again
2023-05-09 20:38:47 <ikke> Do we want to link to https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.18.0?
2023-05-09 20:38:59 <ikke> oh, already there
2023-05-09 20:44:56 <ncopa> i'd like to shorten the highlights a bit
2023-05-09 20:46:01 <ncopa> im dropping mention of openssl and crystal
2023-05-09 20:53:38 <ikke> Don't forget the actual ungleich link
2023-05-09 20:59:11 <ncopa> yeah added it
2023-05-09 20:59:24 <ncopa> and simplified the highlights a bit
2023-05-09 20:59:29 <ncopa> i think im pretty happy now
2023-05-09 21:00:48 <ikke> Just the branch date in alpine-releases.conf.yaml
2023-05-09 21:02:38 <ikke> 👍
2023-05-09 21:04:09 <ncopa> https://wwwtest.alpinelinux.org/ is down, but I guess its ok
2023-05-09 21:04:15 <ncopa> i can check it in local docker
2023-05-09 21:04:59 <ncopa> ok i think I'll just push it to prod
2023-05-09 21:05:20 <ikke> let me quickly check
2023-05-09 21:05:48 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.18.0-released.md
2023-05-09 21:07:13 <ikke> https://wwwtest.alpinelinux.org/
2023-05-09 21:08:09 <ikke> updated
2023-05-09 21:08:33 <ncopa> awesome! thanks
2023-05-09 21:08:39 <ncopa> i think it looks good now
2023-05-09 21:09:23 <ncopa> hum, my icons have been messed up in xfce for a while
2023-05-09 21:09:34 <ncopa> i just noticed it when i opend email cleint
2023-05-09 21:09:37 <ncopa> client*
2023-05-09 21:09:44 <ncopa> or i got reminded of it
2023-05-09 21:11:02 <ikke> both purging cdn cache and aports-turbo are still in progress
2023-05-09 21:13:47 <ncopa> ha
2023-05-09 21:14:07 <ncopa> i pasted the release notes in chatgpt, and the result is actually pretty good
2023-05-09 21:18:08 <ncopa> im using chatgpt to reformat the email to become more readable
2023-05-09 21:35:28 <ncopa> ikke: can you please post on fosstodon?
2023-05-09 21:35:37 <ikke> ✅
2023-05-09 21:35:45 <ikke> https://fosstodon.org/@alpinelinux/110340846774186258
2023-05-09 21:36:33 <ncopa> thank you sir!
2023-05-09 21:36:59 <ncopa> i think i'll celebrate other day. im tired now
2023-05-09 21:39:49 <ikke> sounds like a plan
2023-05-09 21:40:38 <ncopa> ikke: thank you alot for being here and helping with the release
2023-05-09 21:41:05 <ikke> It's a team effort, glad I can be part of it :)
2023-05-09 21:41:41 <ikke> Without you, we would only have edge :)
2023-05-09 21:44:19 <ncopa>   7505	psykose
2023-05-09 21:44:26 <ncopa> number of commits
2023-05-09 21:44:47 <ikke> She's a beast :)
2023-05-09 21:45:16 <ncopa> she is ... amazing!
2023-05-09 21:45:21 <ncopa> congrats everyone!
2023-05-09 21:45:39 <Ermine> 
ACTION throws release confetti

2023-05-09 21:52:20 <pj> are docker images built?
2023-05-09 21:52:43 <pj> ah, i see https://github.com/docker-library/official-images/pull/14607
2023-05-09 21:56:45 <pj> is registry.a.o usable in public (and does it receive same images as dockerhub)?
2023-05-09 21:58:22 <ikke> It is usable in public, it does not mirror dockerhub
2023-05-09 22:00:36 <pj> I mean, as in, does it have same images and tags
2023-05-09 22:02:23 <pj> (yes, I'm too lazy to docker import)
2023-05-09 22:10:49 <pj> also, would be nice to update https://gitlab.alpinelinux.org/alpine/tsc/-/issues/34 if registry.a.o is ok to be used in public
2023-05-10 04:41:09 <ikke> pj: bandwidth is still going to be an issue
2023-05-10 06:55:00 <staceee> hey there o/ I still get "ERROR: mopidy-openrc-3.4.1-r1: BAD signature" from builds.sr.ht edge x86_64, but the problem has been fixed a week ago. Someone got a clue? o_O I don't have this locally now
2023-05-10 07:10:40 <ikke> staceee: just to confirm, what mirror is used?
2023-05-10 07:13:04 <staceee> ikke: http://dl-cdn.alpinelinux.org
2023-05-10 07:16:03 <ikke> And no other caching that could interfere?
2023-05-10 07:16:13 <ikke> What arch?
2023-05-10 07:23:02 <staceee> ikke: I asked on #sr.ht
2023-05-10 07:23:12 <staceee> x86_64
2023-05-10 07:23:29 <staceee> seems like I have another issue on aarch64, it might hide this one too
2023-05-10 07:23:51 <staceee> ikke: maybe bumping the rel would fix this?
2023-05-10 07:30:10 <ikke> Can you install repo-tools and then run repo-tools fastly pkg purge --origin mopidy
2023-05-10 07:30:19 <ikke> Add --release if relevant 
2023-05-10 08:23:51 <staceee> ikke: Error: unknown flag: --origin
2023-05-10 08:25:21 <staceee> I don't understand this use
2023-05-10 09:12:22 <donoban> 
ACTION congrats for the new release :D

2023-05-10 11:20:15 <andypost[m]> any idea why CI for aarch62/arm* can hang last 40 mins? one of 3 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1030099
2023-05-10 11:24:25 <ikke> andypost[m]: because the servers are unreachable 
2023-05-10 11:26:46 <skarnet> ncopa: congrats on the release!
2023-05-10 11:27:17 <ncopa> thanks! \o/
2023-05-10 12:02:07 <ovf> where does abuild get the usual CFLAGS? i just realised that at least on my system, when building something cmake-y with the None buildtype (per newapkbuild), none of the -O options actually get passed on
2023-05-10 12:05:58 <ikke> /etc/abuild.conf
2023-05-10 12:07:17 <ovf> well, actually it's /usr/share/abuild/default.conf , but it's not getting picked up because nobody bothers to set ABUILD_SHAREDIR
2023-05-10 12:08:58 <ovf>  /usr/bin/abuild has sharedir=${ABUILD_SHAREDIR:-/usr/share/abuild} but that fails to set ABUILD_SHAREDIR, which is used by readconfig in /usr/share/abuild/functions.sh
2023-05-10 12:09:45 <ovf> hope the autobuilders haven't been doing this. :-)
2023-05-10 12:38:32 <ovf> oh, i see it's already been fixed in 3.11.0-r1. sorry
2023-05-10 13:36:56 <maribu> I'm feeling a bit stupid, but I fail to generate core dumps for sway. I have the issue that when I connect my notebook to a beamer, I'm using wl-mirror to "clone" the external output to see what I am presenting. When I normally unplug, say, an HDMI connector, sway will just disable the output and everything is fine. If that output however is captured, sway crashes most of the time when unplugging. When having to present on an HDMI beamer
2023-05-10 13:36:56 <maribu> with a flaky cable that looses connection every now and then, the presentation is an emberresing display of segfaults.
2023-05-10 13:37:36 <maribu> I thought when I run ulimit -c unlimited in a TTY and then launch sway, I would get a core dump. That doesn't work however.
2023-05-10 13:38:46 <maribu> If I run sway in GDB, I'm pretty sure that GDB intercepts. However, I'm not dropped back into the TTY when GDB intercepts and than raising the elephant I have little means to actually interact with my machine again.
2023-05-10 13:39:09 <maribu> Has anyone an idea how I would get a core dump created?
2023-05-10 13:40:08 <maribu> Or maybe I should use gdbserver and a second machine
2023-05-10 13:44:30 <psykose> maribu: iirc you don't get coredumps for cap'd/fancy programs, and sway has CAP_SYS_NICE
2023-05-10 13:44:32 <psykose> you could just uncap it first
2023-05-10 13:45:17 <psykose> setcap -r cap_sys_nice or something
2023-05-10 13:46:12 <maribu> Good to know :) I'll give a try, thx :)
2023-05-10 13:50:52 <maribu> It worked, thx :)
2023-05-11 08:49:55 <staceee> ikke: hey back o/ I hope you'r fine :) do you have any clue about the mopidy signing issue I encountered?
2023-05-11 08:52:00 <ikke> willow_staceee: I'll check this afternoon
2023-05-11 08:53:06 <willow_staceee> thanks a lot for you help!
2023-05-11 10:58:24 <ncopa> what happened with lxc alpine template?
2023-05-11 10:58:55 <ikke> -legacy
2023-05-11 10:58:57 <ncopa> i cannot create alpine container in legacy lxc
2023-05-11 10:59:14 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/lxc-templates-legacy-alpine
2023-05-11 10:59:26 <ikke> -legacy-alpine
2023-05-11 11:00:55 <ncopa> thank you sir! i must have mistyped it
2023-05-11 11:01:13 <ncopa> $ doas apk add lxc-legacy-templates-alpine
2023-05-11 11:01:13 <ncopa> ERROR: unable to select packages:
2023-05-11 11:01:13 <ncopa>   lxc-legacy-templates-alpine (no such package):
2023-05-11 11:01:25 <ikke> you swapped legacy and templates
2023-05-11 11:05:35 <ncopa> yeah
2023-05-11 11:05:40 <ncopa> and i found a bug
2023-05-11 11:06:12 <ncopa> $ doas lxc-create a1 -t alpine -- -a armv7
2023-05-11 11:06:14 <ncopa> ...
2023-05-11 11:06:27 <ncopa> armhf
2023-05-11 11:06:27 <ncopa> a1:~# apk --print-arch
2023-05-11 11:06:40 <ncopa> i end up with armhf, not armv7
2023-05-11 11:06:42 <ikke> interesting
2023-05-11 11:06:47 <ikke> haven't noticed that before
2023-05-11 11:06:56 <ncopa> also with lxd images
2023-05-11 11:07:05 <ncopa> which is why i fall back to legacy now
2023-05-11 11:11:15 <ncopa> https://tpaste.us/wxg5
2023-05-11 11:11:33 <ncopa> note the fetch http://.../armhf/...
2023-05-11 11:11:46 <ikke> yes
2023-05-11 11:12:25 <ncopa> bah.. i found the bug
2023-05-11 11:13:03 <ikke> what is it?
2023-05-11 11:13:30 <ncopa> https://tpaste.us/JR4v
2023-05-11 11:13:47 <ncopa> note the order of arm*)
2023-05-11 11:13:49 <ikke> yeaeh
2023-05-11 11:13:55 <ncopa> and armv7 | ...)
2023-05-11 11:14:41 <ncopa> i'll create an issue
2023-05-11 11:15:09 <ikke> I ran into that before but forgot about it
2023-05-11 11:18:33 <ikke> fun, next chromium uses llvm17 features, which is not released yet
2023-05-11 11:25:35 <ncopa> now I get: lxc-create: a1: ../src/lxc/confile.c: set_config_personality: 1432 Invalid argument - Unsupported personality "armv7"
2023-05-11 11:26:20 <ikke> but armhf worked?
2023-05-11 11:31:35 <ncopa> i suppose it did
2023-05-11 11:33:39 <ikke> Because that message could mean armv8l is no supported
2023-05-11 13:36:45 <ikke> staceee: trying to understand where the issue comes from
2023-05-11 13:37:04 <ikke> trying on differen servers all over the world does not give any signature errors
2023-05-11 13:47:54 <Nermalq>  Speedy Gonzalez and Jerry visit Barbra Streisand and masturbate her cooter before being expelled by her super powerful spray of kosher cum juices! https://justpaste.it/Barbra_Streisand_Speedy_Gonzalez
2023-05-11 14:05:58 <ncopa> this is the reason I am skeptic of moving rust to main:  https://build.alpinelinux.org/buildlogs/build-3-18-ppc64le/community/dust/dust-0.8.6-r0.log
2023-05-11 14:06:21 <ncopa> cannot even bump a minor version without an arch go boom
2023-05-11 14:07:22 <ikke> It was said rust versions are backwards compattible
2023-05-11 14:08:30 <ikke> ncopa: has this to do with the rust version?
2023-05-11 14:09:18 <ncopa> no idea
2023-05-11 14:09:38 <ncopa> a project bumped a minor version and now it no longer builds on ppc64le
2023-05-11 14:10:31 <ncopa> and thats my general impression of rust world. touch anything and somethings goes boom
2023-05-11 14:11:52 <pj> this is running commands on the host and collecting output
2023-05-11 14:12:07 <pj> I wouldn't be so quick to call it "rust problem"
2023-05-11 14:18:37 <pj> assert_cmd crate was bumped in dust between 0.8.5 and 0.8.6
2023-05-11 14:21:52 <handlerug> is the aarch64 builder still building plasma
2023-05-11 14:22:33 <handlerug> asking because CI pipelines fail due to timeouts
2023-05-11 14:23:41 <ikke> handlerug: The builder and CI host are currently unavailable / unreachable
2023-05-11 14:24:06 <handlerug> ah, interesting
2023-05-11 16:14:02 <abby> have y'all at alpine run into issues with the rpi kernel thinking it's arm64 on 32-bit arm? manifests as errors like crypto/Kconfig:1399: can't open file "arch/arm64/crypto/Kconfig" when building dkms things (that one specifically can be done with doas make -j $(nproc) -C /lib/modules/6.1.27_1/build prepare0)
2023-05-11 16:17:13 <minimal> stuff like zfs is packaged for RPI armv7 via akms (not dkms) so I guess it works in general
2023-05-11 21:15:42 <omni> will 2023 be the year of zfs on the phone?
2023-05-12 04:11:31 <psykose> ncopa: those failing tests are the projects own flaky tests that have always failed like that a bunch of times
2023-05-12 04:11:33 <psykose> but yes you're right, that means we should not put rust in main
2023-05-12 04:11:36 <psykose> i will close the proposal
2023-05-12 04:13:49 <psykose> not pictured: the lack of complaints for the other 50 million flaky testsuites
2023-05-12 04:13:57 <psykose> maybe we should remove abuild too? i heard it has some flaky tests
2023-05-12 05:12:47 <pj> if only C and other languages were held up to such standard
2023-05-12 05:14:38 <ikke> There is one difference, that we said we would keep rust up-to-date on stable branches, so the standard is higher
2023-05-12 05:18:53 <ikke> But N=1 here and not even clear yet what the issue is
2023-05-12 05:19:49 <psykose> just restarted some kde tests like three times
2023-05-12 05:19:52 <psykose> welp, that's it
2023-05-12 05:19:54 <psykose> removing it from the repos
2023-05-12 05:27:04 <Arnavion> https://github.com/bootandy/dust/blob/master/tests/test_exact_output.rs#L8-L18   This is the most bonkers thing I've ever read
2023-05-12 05:28:57 <Arnavion> Changing the `cargo test --frozen` to `cargo test --frozen --exclude test_exact_output` will stop those busted tests from running, if you care
2023-05-12 05:34:08 <orbea> those tests....lol
2023-05-12 05:34:11 <psykose> ooh they added --exclude
2023-05-12 05:34:21 <psykose> how long has that been there? years ago i thought that didn't exist
2023-05-12 05:35:27 <psykose> you can even specify it more than once and it has globs
2023-05-12 05:35:29 <psykose> the dream
2023-05-12 05:38:04 <Arnavion> Oh actually, `--exclude` is for crates, not tests. My bad
2023-05-12 05:38:16 <staceee> ikke: only the one I mentionned give an error? or they all works and something might wrong in the builds.sr.ht side?
2023-05-12 05:38:22 <psykose> aha
2023-05-12 05:38:37 <psykose> staceee: it's weird you got a checksum mismatch at all
2023-05-12 05:38:44 <psykose> the package was never e.g. rebuilt into same pkgrel or anything
2023-05-12 05:38:49 <staceee> hey psykose o/ :D
2023-05-12 05:38:54 <ikke> psykose: a subpackage was added
2023-05-12 05:38:56 <psykose> ah
2023-05-12 05:39:22 <psykose> ah, yeah that was my bad then
2023-05-12 05:39:26 <staceee> issue has been fixed apparently, but I still have a problem on builds.sr.ht
2023-05-12 05:39:32 <ikke> We did purge the cache, but I'm trying to understand why it still gives issues
2023-05-12 05:39:39 <psykose> makes sense
2023-05-12 05:40:02 <Arnavion> `--skip` was the one
2023-05-12 05:40:15 <Arnavion> `cargo test --frozen -- --skip test_exact_output`
2023-05-12 05:40:17 <psykose> if it's using dl-cdn and you're sure you purged it then i'd assume it doesn't fully purge or something
2023-05-12 05:40:33 <psykose> Arnavion: huh, which command is that under the --
2023-05-12 05:40:57 <Arnavion> `cargo test` compiles a test binary with libtest entrypoint, and then the ones after the `--` are args for that binary
2023-05-12 05:41:14 <psykose> do you know which docs are for libtest
2023-05-12 05:42:01 <Arnavion> There are a few of them like `--nocapture`. If you run `cargo test -- --help` you would see them. Let's see if they're documented somewhere...
2023-05-12 05:42:08 <ikke> staceee: I've ran repo-tools fastly purge pkg --repo community --origin mopidy 
2023-05-12 05:42:11 <ikke> just now
2023-05-12 05:42:16 <ikke> can you see if the job still fails?
2023-05-12 05:42:22 <ikke> otherwise we'll just bump the pkgrel again
2023-05-12 05:42:26 <ikke> or in the first place
2023-05-12 05:42:28 <staceee> I just submitted one like ~30s ago
2023-05-12 05:42:37 <ikke> I did it 15s ago :D
2023-05-12 05:42:44 <staceee> I'll ssh if it fails to apk update if it fails
2023-05-12 05:42:53 <psykose> the weird thing is that it doesn't say it's skipped or anything
2023-05-12 05:42:55 <psykose> Arnavion: https://img.ayaya.dev/ymRhUarfDWV6
2023-05-12 05:42:56 <ikke> 05:41:56
2023-05-12 05:42:56 <Arnavion> psykose:   https://doc.rust-lang.org/rustc/tests/index.html#cli-arguments
2023-05-12 05:43:00 <psykose> so i'm not sure if that really skipped or not
2023-05-12 05:43:28 <Arnavion> I can clone and check
2023-05-12 05:43:32 <staceee> ikke: 5:39:48 lmfao
2023-05-12 05:43:37 <staceee> first
2023-05-12 05:43:40 <ikke> :D
2023-05-12 05:44:09 <psykose> ah, just exact_output
2023-05-12 05:45:19 <psykose> well, that doesn't change anything either, but by the docs and the name it would exclude it
2023-05-12 05:45:34 <ikke> psykose: fyi, I tried it on all the 3 t1 hosts to see if it was some geographic issue
2023-05-12 05:45:42 <ikke> though, that does not cover that many areas
2023-05-12 05:46:27 <psykose> staceee: that builds.sr.ht ssh access thing is awesome
2023-05-12 05:46:32 <psykose> ikke: yea
2023-05-12 05:46:35 <staceee> yaaaa
2023-05-12 05:47:28 <Arnavion> psykose: Ah, they're what Cargo calls "integration tests". Each /tests/*.rs compiles as a separate binary, so the `--skip` will match its functions' names, not the filename itself
2023-05-12 05:47:49 <psykose> yeah, something like that
2023-05-12 05:48:07 <psykose> now to figure out why whether i pass anything or not it just says 0/0 and doesn't indicate what really happened
2023-05-12 05:48:19 <psykose> Arnavion: thanks a lot for the docs though, i've wondered how to do that for a long time :)
2023-05-12 05:49:00 <Arnavion> The part after "Running tests/test_exact_output.rs (target/debug/deps/test_exact_output-...)" will tell you how many tests it ran from there
2023-05-12 05:49:02 <staceee> ikke: looks like I don't fail on the same error anymore \o/
2023-05-12 05:50:03 <Arnavion> The nuclear option is to `rm -rf tests/test_exact_output.rs` before the `cargo test` command
2023-05-12 05:50:21 <Arnavion> Well, not -r
2023-05-12 05:56:46 <ikke> staceee: ok, seems like something helped :P
2023-05-12 05:57:12 <staceee> now I got a buildrepo maybe nice :D
2023-05-12 06:32:22 <ncopa> psykose: i was just expressing my skeptisism based on my own fear and my own impression of rust ecosystem. I'm glad it was baseless
2023-05-12 06:33:24 <ncopa> rust in main would open some doors and is absolutely a goal worth pursuing
2023-05-12 06:34:19 <ncopa> i think it is inevitable. question is just when
2023-05-12 06:40:20 <staceee> ikke: my builds passes! imense thanks you, for your time. I hope you have a great day :)
2023-05-12 06:42:35 <ikke> staceee: glad to hear
2023-05-12 09:57:24 <JohannesJ[m]> i want to look into building packages for alpine too :)
2023-05-12 09:57:33 <JohannesJ[m]> especially fore the desktop environment
2023-05-12 10:04:39 <ncopa> cool
2023-05-12 10:05:14 <ncopa> JohannesJ[m]: I needed to set up new dev env yesterday and wrote small script. I think it could be useful for getting started
2023-05-12 10:05:49 <JohannesJ[m]> dont say that just yet.. :) i have general linux knowledge, but im only just recently learning the inner workings of alpine :)
2023-05-12 10:05:53 <JohannesJ[m]> yes, that environment ;-)
2023-05-12 10:07:19 <ncopa> https://tpaste.us/9MkK
2023-05-12 10:08:13 <ncopa> actually, the ssh key thingy should probably be >> so we don't overwrite the current authorized_keys
2023-05-12 10:09:08 <ncopa> permission of authorised keys is also wrong. but it gives an idea what's needed to get started
2023-05-12 10:09:18 <JohannesJ[m]> exactly :)
2023-05-12 10:11:45 <JohannesJ[m]> reading the wiki https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2023-05-12 10:12:14 <JohannesJ[m]> i already spoke with Bart in the past about working on KDE packages :)
2023-05-12 10:12:54 <JohannesJ[m]> then i needed to onboard new clients into our company which took up most of my waking hours :| you'd be amased abouyt the mess some MSP's leave behind
2023-05-12 17:54:57 <psykose> nmeum: could you have a look at the libgcc_s thing? everything else is good to go, i've been using gcc13 for weeks and there's no other surprises really
2023-05-12 17:58:12 <psykose> that one is just quite hard and i don't have any good ideas except "fuck it no FORTIFY" :p
2023-05-12 17:59:06 <psykose> tbh i was somewhat wondering what the perf difference is on gcc as a whole to remove hardening from it
2023-05-13 14:48:40 <nmeum> psykose: can I reproduce the chromium libgcc flatc crash without building the entirety of chromium?
2023-05-13 14:48:45 <nmeum> can I just build flatc and invoke it?
2023-05-13 14:48:53 <psykose> it's just `ninja flatc`
2023-05-13 14:49:03 <psykose> 31 objects
2023-05-13 14:49:32 <psykose> abuild deps unpack prepare, cd $builddir/out/bld, ninja flatc, ./flatc
2023-05-13 14:49:49 <nmeum> ah nice
2023-05-13 14:56:01 <nmeum> building gcc rn, should be fixable if it is easy to debug
2023-05-13 14:57:13 <psykose> large if
2023-05-13 14:57:19 <psykose> i'm testing the __builtin_memcpy too
2023-05-13 14:57:21 <psykose> didn't think of that
2023-05-13 14:57:55 <psykose> nmeum: also could you g+w the gcc folder on archive?
2023-05-13 14:58:21 <psykose> i'm also curious why you mirror e.g. the diffs/ folder when it's not very useful without every other snapshot mirrored too (the diffs are between snapshot)
2023-05-13 14:59:13 <nmeum> I just did `wget -r --no-parent …` but yea I guess we don't need the diffs/ folder
2023-05-13 15:00:08 <psykose> ah ole wget :)
2023-05-13 15:00:58 <nmeum> changed the permission of the gcc archive
2023-05-13 15:03:49 <psykose> thanks
2023-05-13 15:04:06 <nmeum> hm, wait I should build my gcc 13 with debug symbols
2023-05-13 15:04:50 <nmeum> is there easy way to just get debug symbols for libgcc?
2023-05-13 15:05:15 <psykose> don't think so, no
2023-05-13 15:05:30 <psykose> except for like manually installing libgcc into your system from the build tree for fun i guess
2023-05-13 15:12:27 <psykose> seems to abort with builtin_memcpy too
2023-05-13 15:12:52 <psykose> so i'm gonna guess it's from somewhere else now and i just don't have symbols
2023-05-13 15:13:33 <psykose> still a ud2 tho
2023-05-13 15:50:21 <Newbyte> did the ARM builders take another nap?
2023-05-13 15:50:38 <ikke> no, should be working
2023-05-13 15:50:50 <ikke> they're building kde stuff atm
2023-05-13 15:50:53 <Newbyte> https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/1031823
2023-05-13 15:50:55 <Newbyte> what's up with this?
2023-05-13 15:56:30 <ikke> Not sure why yet, but for some reason those servers cannot reach the registry over ipv4
2023-05-13 15:56:36 <ikke> (and they do not provide ipv6)
2023-05-13 16:22:33 <nmeum> ok, i can reproduce the flatc crash now nice
2023-05-13 16:22:58 <psykose> poggers
2023-05-13 16:23:17 <nmeum> how did you obtain the second backtrace in your comment?
2023-05-13 16:23:25 <nmeum> https://gitlab.alpinelinux.org/alpine/alpine-gcc-patches/-/merge_requests/13#note_305493
2023-05-13 16:23:26 <nmeum> this one
2023-05-13 16:23:43 <nmeum> the backtrace I am currently seeing is similar to the first
2023-05-13 16:24:16 <psykose> check if gdb even loaded the libgcc_s symbols
2023-05-13 16:24:20 <psykose> it didn't for me
2023-05-13 16:24:30 <nmeum> ah
2023-05-13 16:24:31 <psykose> i manually objcopy'd a debuglink since for some reason it was missing
2023-05-13 16:24:33 <psykose> kinda scuffed
2023-05-13 16:25:03 <psykose> the current -dbg setup is not the most robust thing ever, though it does work 99% of the time
2023-05-13 16:26:03 <psykose> it's all going to be optimised-out too unless you built the thing with -O0 or somethin
2023-05-13 16:26:52 <psykose> it's probably easier to use LD_PRELOAD of an in-tree libgcc_s with all the symbols than to install things, probably
2023-05-13 16:26:56 <psykose> i'll do that next time
2023-05-13 16:27:42 <nmeum> this is what the backtrace looks like for me https://tpaste.us/LRjm
2023-05-13 16:27:47 <nmeum> > 0x00007ffff7f3d411 in __deregister_frame_info_bases (begin=<optimized out>) at /home/buildozer/aports/main/gcc/src/gcc-13-20230506/libgcc/unwind-dw2-fde.c:281
2023-05-13 16:27:57 <nmeum> ^ this is where it fails, but this is a failing assertion in unwind-dw2-fde.c
2023-05-13 16:28:10 <nmeum> https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libgcc/unwind-dw2-fde.c#L281
2023-05-13 16:28:10 <psykose> that's new
2023-05-13 16:28:19 <psykose> didn't see that before
2023-05-13 16:30:35 <nmeum> weird
2023-05-13 16:30:40 <nmeum> but ok time to figure out why this assertion fails then
2023-05-13 16:30:49 <psykose> yeah it's really bizarre :D
2023-05-13 16:30:58 <psykose> and i pinky swear i found absolutely nothing else that triggers it
2023-05-13 16:31:02 <psykose> not even flatc from the normal repo
2023-05-13 16:31:06 <psykose> just from chromium tree
2023-05-13 16:31:07 <nmeum> maybe you compiled with -DNDEBUG?
2023-05-13 16:31:24 <nmeum> and that's why you dont see the assertion failure
2023-05-13 16:32:13 <psykose> no, flatc without DNDEBUG doesn't trigger it
2023-05-13 16:32:22 <psykose> 23.3.3 anyway
2023-05-13 16:32:56 <psykose> the chromium tree one is a bit older i think but i don't think that's the difference, it's probably something more subtle in the way they build it in the .gn spec
2023-05-13 16:33:07 <nmeum> I mean compile (lib)gcc without -DNDEBUG, though not sure if gcc_assert actually respects NDEBUG
2023-05-13 16:33:26 <psykose> ah
2023-05-13 16:33:33 <psykose> no, same build as you, nothing special passed
2023-05-13 16:33:41 <psykose> unless it passes DNDEBUG itself and you removed it or something
2023-05-13 16:34:03 <nmeum> I added -g to CFLAGS, not sure if that makes a difference
2023-05-13 16:34:19 <psykose> doesn't affect it no, and i did that once too
2023-05-13 16:34:30 <nmeum> anyway, I will try to find some time to figure out why the assertion fails
2023-05-13 16:35:01 <psykose> thanks
2023-05-13 16:35:06 <psykose> with that solved i think the rest is fine
2023-05-13 16:44:46 <nmeum> I think release_registered_frames is supposed to be run before __deregister_frame_info_bases but it is run after
2023-05-14 14:25:47 <juano> Naruto buttfucks Nuevo Leon Governor Samuel Garcia Sepulveda in Monterrey, Mexico, using a new sexual jutsu!  Naruto donates his cum to ensure Samuel's wife gives birth to blue-eyed babies!  https://justpaste.it/Naruto_Makes_Love_Samuel_Garcia
2023-05-14 14:30:29 <Cogitri> Dafuq
2023-05-14 14:36:21 <ikke> Ohai Cogitri
2023-05-14 14:36:42 <Cogitri> ikke: Hey :D 
2023-05-14 14:38:54 <nmeum> psykose: I fixed the failing assertion in libgcc and with that fix chromium's flatc without any arguments doesn't crash for me. is there any other flatc usage i should test?
2023-05-14 14:39:04 <psykose> nope, just that
2023-05-14 14:39:11 <nmeum> I still haven't encountered your fortify source failure though
2023-05-14 14:39:25 <psykose> it was probably the same thing
2023-05-14 14:39:36 <psykose> you can just push to my mr branch and i'll test it later
2023-05-14 14:39:45 <nmeum> *nod*
2023-05-14 14:39:49 <psykose> if you have no other comments i'll probably merge it all later when i'm not playing videogames
2023-05-14 14:40:21 <nmeum> I will also try to contact the author of the patchset which introduced that regression, i.e. the failing assertion
2023-05-14 14:40:31 <psykose> good idea :)
2023-05-14 14:40:35 <nmeum> regarding other comments: I noticed some libgcc functions are instrumented with endbr64 instructions?
2023-05-14 14:40:48 <psykose> hmm
2023-05-14 14:40:55 <nmeum> or is that only my local build because they shouldn't do anything due to lack of support CFI support in musl
2023-05-14 14:41:27 <psykose> are you referring to 13 or current too? iirc that cfi thing is enabled by default
2023-05-14 14:41:30 <psykose> and indeed does nothing
2023-05-14 14:41:56 <psykose> i'm not 100% sure if it's since now or like 11 to be on by default on x86*
2023-05-14 14:41:58 <nmeum> ah, I didn't consult the current version. yea that might be the case
2023-05-14 14:43:14 <psykose> objdump -D /usr/lib/libgcc_s.so.1 | grep endbr does stuff on 12
2023-05-14 14:43:29 <psykose> same for 11
2023-05-14 14:43:41 <psykose> but not 10
2023-05-14 14:43:42 <psykose> so yeah
2023-05-14 14:43:52 <psykose> guess my memory was right
2023-05-14 14:44:29 <psykose> but i don't see anything in the 11 changelog about it :D
2023-05-14 14:44:33 <psykose> regardless, it's harmless
2023-05-14 14:50:11 <nmeum> yes, if we can disable it it will save us a few bytes though but not super urgent
2023-05-14 15:07:53 <psykose> i'll see if i can find anything in the configure options
2023-05-14 17:10:53 <EvTheFuture> I upgraded my daily driver host today to 3.18, but got some issues which I just want to check if anyone else experience: Running wayland with sway and when trying to start mplayer it crashes: https://tpaste.us/lgrg
2023-05-14 17:18:35 <EvTheFuture> Also get a problem in Carla which doesn't render Ardour-Style "Inline Displays" anymore...  
2023-05-14 17:57:44 <ikke> EvTheFuture: Haven't heard about any relevant issues
2023-05-14 17:57:49 <ikke> maybe open an issue?
2023-05-14 17:59:41 <psykose> mplayer is actually broken but in another way, so i'm not sure how you can even get that error
2023-05-14 19:02:33 <psykose> EvTheFuture: new one should work
2023-05-14 19:53:39 <minimal> what's up with Gitlab recently, when raising MRs the webpage initially doesn't show the merge or pipeline and then it auto-updates after a couple of minutes to show the pipeline
2023-05-14 19:57:48 <ikke> minimal: some change in gitlab where they switched loading the mr page asynchronously 
2023-05-14 19:59:39 <minimal> ah ok, strange as it initially says "no changes" from memory
2023-05-14 20:02:07 <minimal> "This merge request contains no changes"
2023-05-14 20:02:09 <ikke> yeah, when they ask for the changes, they are not calulcated yet and they show that as no changes
2023-05-14 20:02:27 <ikke> there is an open issue about it
2023-05-14 20:02:29 <minimal> all very confusing
2023-05-15 01:41:08 <EvTheFuture> @psykose: Thank you, the new updated git version works!
2023-05-15 01:41:45 <psykose> :)
2023-05-15 01:42:10 <psykose> have you heard of mpv? i heard it's like mplayer but they got an actual git repository and a build system that guarantees it works..
2023-05-15 01:42:12 <psykose> /joking
2023-05-15 01:42:24 <EvTheFuture> Now I just have to try to troubleshoot Carla and why it's not rendering inline displays anymore
2023-05-15 01:42:30 <psykose> yeah that one seems weird
2023-05-15 01:42:53 <psykose> does it do things via qt/pyqt? since it's in deps
2023-05-15 01:42:59 <psykose> if so, it could be related to the new py versions
2023-05-15 01:43:04 <psykose> qt* versions
2023-05-15 01:43:18 <psykose> or just the new carla version? is it related to deps or just carla itself
2023-05-15 01:43:28 <EvTheFuture> @psykose: I guess so, because it is an python application.
2023-05-15 01:44:15 <EvTheFuture> @psykose: Since I'm the maintainer of Carla I always install the latest version (purpose built for the version I'm running at the moment), so I was using the same version before but on Python 3.10
2023-05-15 01:44:22 <psykose> makes sense
2023-05-15 01:44:28 <psykose> so it's one of the deps then
2023-05-15 01:44:40 <psykose> new qt bindings or pyqt itself is my guess
2023-05-15 01:48:54 <EvTheFuture> I get one warning which I'm not sure I got before, but not sure it is related... Does this mean anything to you: [WRN] Unsupported KVT object type: http://lsp-plug.in/plugins/lv2/spectrum_analyzer_x2/dumpState
2023-05-15 01:49:27 <psykose> not really no, not sure if it matters or not
2023-05-15 01:50:14 <EvTheFuture> ok, same here. I think it's a new warning though. Thanks for the help with mplayer and getting some ideas on where to troubleshoot Carla
2023-05-15 01:50:43 <EvTheFuture> I'mean, it is functioning, but just not all the visual fluffiness :)
2023-05-15 01:56:43 <psykose> do you have a visual example of what doesn't render?
2023-05-15 01:56:46 <psykose> i can try some stuff
2023-05-15 01:57:15 <EvTheFuture> @psykose: I will create. give me a sec
2023-05-15 02:15:17 <EvTheFuture> @psykose: https://www.valitron.se/tmp/carla-3_17.png
2023-05-15 02:15:29 <EvTheFuture> @psykose: https://www.valitron.se/tmp/carla-visuals-noaudio.mp4
2023-05-15 02:15:45 <EvTheFuture> @psykose: Let me know when you have downloaded and I will remove the directory
2023-05-15 02:16:25 <EvTheFuture> the first is a static image where the nodes circled by red are not rendering and the onces circled with green are
2023-05-15 02:16:41 <psykose> done
2023-05-15 02:16:51 <psykose> i see
2023-05-15 02:17:10 <EvTheFuture> the video is when it is working in 3.17
2023-05-15 02:17:35 <EvTheFuture> sorry I named it wrong
2023-05-15 02:17:50 <EvTheFuture> carla-3_17 shall be carla-3_18
2023-05-15 02:21:22 <EvTheFuture> I checked the warning message I sent previously and I get two for spectrum analyzer and two messages for a Compressor. These types are the non working ones
2023-05-15 02:21:39 <EvTheFuture> So it might be related
2023-05-15 02:28:01 <psykose> which plugin is uhh
2023-05-15 02:28:05 <psykose> compressor-sink compressor
2023-05-15 02:29:11 <psykose> damn i'm surprised how good this works
2023-05-15 02:29:24 <psykose> even the custom uis load
2023-05-15 02:30:40 <psykose> https://img.ayaya.dev/GnZtRZX4IuC5 this never fails to make me laugh
2023-05-15 02:46:00 <psykose> not fixed on master either
2023-05-15 02:46:09 <psykose> tested with all the features and juce compiled in too
2023-05-15 02:50:38 <psykose> if you figure it out let me know
2023-05-15 02:51:10 <psykose> i don't get any warnings anywhere
2023-05-15 02:52:01 <psykose> ah, maybe https://github.com/sadko4u/lsp-plugins/issues/314
2023-05-15 02:52:16 <psykose> i'll test
2023-05-15 02:59:26 <EvTheFuture> @psykose: the compressor is this one: x42-comp - Dynamic Compressor Stereo
2023-05-15 02:59:52 <psykose> hm
2023-05-15 03:00:07 <psykose> can you test https://img.ayaya.dev/vXxL0a42ZpkM
2023-05-15 03:01:28 <psykose> doesn't seem to fix it for me but i might be holding it wrong
2023-05-15 03:01:55 <EvTheFuture> @psykose: I'll give it a shot, just need to setup build VM for 3.18
2023-05-15 03:10:33 <EvTheFuture> @psykose: I'm still setting up a new builder, but just a thought, when you tested, had you activated inline displays in the configuration / experimental settings?
2023-05-15 03:10:44 <EvTheFuture> in Carla that is
2023-05-15 03:11:03 <psykose> no
2023-05-15 03:11:04 <psykose> thanks
2023-05-15 03:11:04 <psykose> https://img.ayaya.dev/JOqA5J2hMqsc
2023-05-15 03:11:05 <psykose> here
2023-05-15 03:11:06 <psykose> it works
2023-05-15 03:11:09 <psykose> ok, i'll backport it
2023-05-15 03:11:39 <psykose> (i just dragged random lines don't read any of it lol)
2023-05-15 03:26:57 <EvTheFuture> :)
2023-05-15 03:27:11 <EvTheFuture> Perfect, good work!
2023-05-15 03:28:34 <psykose> should already be there
2023-05-15 03:28:46 <EvTheFuture> Great, thanks!
2023-05-15 03:46:23 <EvTheFuture> @psykose: Wohoo, https://imgbox.com/d8ndgxoR
2023-05-15 03:46:26 <psykose> :)
2023-05-15 08:02:28 <hcs> Do you guys have any idea how I could tell irqbalance to live in /run/irqbalance instead of /var/run/irqbalance? (/var/run is just symlinked to /run anyway)
2023-05-15 08:02:56 <hcs> Checkpath is throwing errors because /var/run is populated by bootmisc, which isn't available yet for some reason.
2023-05-15 08:10:26 <nmeum> psykose: thanks for following up on the gcc ml with the docker file to reproduce the assertion failure
2023-05-15 08:22:44 <psykose> np :)
2023-05-15 08:27:35 <psykose> hcs: probably just https://gitlab.alpinelinux.org/alpine/aports/-/commit/f6bf1c613d590fa714f5f956f8d4ff1b5ef8fb1c
2023-05-15 08:28:26 <hcs> I actually just found the bug. It's in the depends function of /etc/init.d/irqbalance
2023-05-15 08:28:48 <hcs> Gentoo OpenRC handbook: If the service must write to local disks, it should need localmount. If it places anything in /var/run/ such as a pidfile, then it should start after bootmisc
2023-05-15 08:29:01 <hcs> Irqbalance does not depend on bootmisc like it should
2023-05-15 08:34:29 <hcs> I'm getting HTTP500 when attempting to create a MR to aports from my fork
2023-05-15 08:41:49 <hcs> Are you guys doing maintenance on the gitlab instance or...? https://i.imgur.com/5DZiYDU.png
2023-05-15 08:43:03 <psykose> iirc that's the 500 of clicking something wrong
2023-05-15 08:43:13 <psykose> which is quite unfortunate
2023-05-15 08:44:52 <hcs> I use gitlab for work, I didn't misclick anything. The "You pushed to hc-hmk-master-patch-50773 at HCS HMK / aports. Create merge request" button leads to HTTP500.
2023-05-15 08:45:21 <ncopa> hcs: which version of irqbalance/alpine? looks like edge version should use "/run/irqbalance"
2023-05-15 08:45:30 <ncopa> 168:#define SOCKET_TMPFS "/run/irqbalance"
2023-05-15 08:45:30 <ncopa> irqbalance.h
2023-05-15 08:46:09 <psykose> i already fixed it
2023-05-15 08:46:20 <psykose> hcs: yeah, what i mean there is some specific url that gets generated like that that always 500's
2023-05-15 08:46:54 <hcs> ncopa: irqbalance version 1.9.2 on alpine 3.17.3 iirc. Is it using /run/irqbalance on 3.18?
2023-05-15 08:47:28 <hcs> psykose: gotcha, mb. I'll try to work around that
2023-05-15 08:53:05 <hcs> I'm allowed to target my fork but not parent. Targetting parent just results in HTTP500
2023-05-15 08:58:47 <ncopa>  i think it uses /run/irqbalance on 3.17 as well
2023-05-15 08:59:13 <psykose> it has nothing to do with what it uses but what the checkpath init.d is running
2023-05-15 08:59:31 <psykose> +- the deps
2023-05-15 09:01:22 <ncopa> yeah checkpath should create /run/irqbalance, not /var/run/irqbalance
2023-05-15 09:04:30 <hcs> What in version of irqbalance was the SOCKET_TMPFS patch merged?
2023-05-15 09:05:37 <psykose> like 1.0.9 like 4 years ago
2023-05-15 09:06:29 <hcs> Oh wow okay. It's just a typo in the service file then. Are you guys working on a MR?
2023-05-15 09:07:06 <psykose> i fixed it in the link i pasted 30 minutes ago then backported it :p
2023-05-15 09:14:16 <hcs> That's amazing, thank you so much!
2023-05-15 09:29:04 <ncopa> thanks!
2023-05-15 09:29:28 <ncopa> and yes, psykose is indeed amazing :)
2023-05-15 09:37:27 <pj> hcs: make sure your master is up to date with aports master
2023-05-15 09:37:45 <pj> gitlab likes to just not work when forks are out of sync
2023-05-15 09:37:50 <hcs> I've also got a completely different issue. Do you know why chronyd wants to start twice?
2023-05-15 09:38:02 <psykose> in what sense does it start twice
2023-05-15 09:38:20 <hcs> pj: thanks, but I've just abandoned the change. psykose already merged it
2023-05-15 09:38:51 <pj> 
ACTION shrugs

2023-05-15 09:40:52 <hcs> psykose: "Starting chronyd ..." "Starting chronyd ..." "start-stop-daemon: /usr/sbin/chronyd is already running" "Failed to start chronyd" "ERROR: chronyd failed to start". I have only one version of chrony installed through apk, and the service is only present on one runlevel.
2023-05-15 09:42:27 <psykose> is that edge or 3.18
2023-05-15 09:42:31 <psykose> and can you paste the full log
2023-05-15 09:43:09 <hcs> It's on 3.17.3. How do I get openrc to tee bootlog into a text file?
2023-05-15 09:43:29 <hcs> brb 30 min lunch
2023-05-15 09:44:02 <psykose> rc_logger=yes in /etc/rc.conf and it writes it somewhere
2023-05-15 10:34:35 <nmeum> psykose: the libgcc assertion failure is now fixed in gcc upstream 😊
2023-05-15 10:34:39 <psykose> i saw
2023-05-15 10:34:40 <psykose> :D
2023-05-15 10:34:46 <nmeum> it's also on the gcc-13 branch and should therefore be part of the next snapshot
2023-05-15 10:34:52 <nmeum> was suprisingly fast this time
2023-05-15 10:44:54 <psykose> yeah
2023-05-15 10:45:02 <psykose> i guess i'll update to 0522 in a week then
2023-05-15 10:49:09 <nmeum> is the occassional build failure of gcc-go/libgo on ppc64/x86 still at thing?
2023-05-15 10:49:17 <hcs> psykose: the chronyd thing seems to be intermittent. The same read-only filesystem will sometimes complain about chrony, sometimes not.
2023-05-15 10:49:20 <nmeum> might attempt to fix that as well if so
2023-05-15 10:49:56 <hcs> I agree.
2023-05-15 10:51:05 <hcs> btw bootmisc will complain that "/ is not writable; unable to clean up underlying /run" even when /run is a regular tmpfs
2023-05-15 10:52:19 <hcs> Got it. I have a log with the complaints from cronyd. Does alpine have a pastebin?
2023-05-15 10:52:47 <ikke> https://tpaste.us
2023-05-15 10:55:58 <hcs> https://tpaste.us/MRDD
2023-05-15 10:56:04 <hcs> That's _very_ nifty
2023-05-15 10:56:33 <psykose> nmeum: didn't see it
2023-05-15 10:56:49 <psykose> it was pretty likely before, so check the diff of the two snapshots
2023-05-15 10:56:56 <psykose> it's just a week apart and like 25 commits, maybe they fixed it
2023-05-15 10:57:27 <hcs> never mind that fsck is complaining, it's not the rootfs
2023-05-15 11:02:36 <psykose> did you change the chrony conf.d by chance
2023-05-15 11:08:29 <hcs> psykose: I did. You suppose it starts twice, failing the second time, because it's misconfigured?
2023-05-15 11:08:44 <psykose> well what did you change
2023-05-15 11:08:54 <hcs> sec
2023-05-15 11:10:17 <hcs> chrony.conf: https://tpaste.us/EJy5
2023-05-15 11:10:52 <psykose> i meant the /etc/conf.d/chrony
2023-05-15 11:11:08 <hcs> Oh, nope, /etc/conf.d/chrony doesn't even exist
2023-05-15 11:11:42 <psykose> probably because it's chronyd specifically
2023-05-15 11:12:58 <hcs> Brainfart, /etc/conf.d/chronyd is stock, I think. It has FAST_STARTUP turned on
2023-05-15 11:14:10 <psykose> fast_startup is off by default because it gives you this exact issue
2023-05-15 11:14:19 <psykose> which to be clear is not even an issue, there is no actual fatal error
2023-05-15 11:14:52 <psykose> so you turnt it on and now you're complaining :p
2023-05-15 11:16:00 <psykose> that said i think it might work without the warning in 3.18, not sure
2023-05-15 12:05:12 <hcs> I thought that "fast startup" was just that the init script wont block until system time has changed, but instead forks to background
2023-05-15 12:05:49 <psykose> try it on 3.18 and see if you get the issue or not
2023-05-15 12:05:54 <hcs> I will
2023-05-15 12:06:27 <psykose> also do you have rc_parallel
2023-05-15 12:07:58 <hcs> I do. It's been fairly robust so far. I just added chrony a short while ago
2023-05-15 12:08:44 <psykose> well
2023-05-15 12:08:51 <psykose> please don't report any of these issues then
2023-05-15 12:08:52 <psykose> thanks
2023-05-15 12:09:53 <hcs> Alright, I'll just turn it off and reproduce without
2023-05-15 13:31:16 <psykose> hmm
2023-05-15 13:31:26 <psykose> which configuration has no ATOMIC_FDE_FAST_PATH that breaks the build
2023-05-15 13:31:41 <psykose> the report says the new patch is fixed on aarch64 but it was not broken on aarch64 for us :D
2023-05-15 15:33:49 <zv> in an APKBUILD, is something like arch="noarch !x86_64" legitimate? abuild seems to use the string literal "noarch" for comparison -- https://git.alpinelinux.org/abuild/tree/abuild.in#n1204
2023-05-15 15:35:56 <zv> the reasoning here is for when e.g. makedepends cannot be satisfied on a particular arch
2023-05-15 15:38:15 <psykose> yes
2023-05-15 15:38:51 <psykose> that line is in trace way after everything happens
2023-05-15 15:39:19 <psykose> if you do noarch !x86_64 the whole build just gets skipped on x86_64, it's not really 'actual noarch', so it works like all !x86_64 and just doesn't build it
2023-05-15 15:39:23 <donoban> wow, 227 upgrades
2023-05-15 15:39:29 <donoban> gcc?
2023-05-15 15:41:28 <zv> psykose: the problem I am experiencing is, say it's "noarch !x86_64", now my arm build fails because it complains that -dbg is empty
2023-05-15 15:43:28 <psykose> well, that's a separate question
2023-05-15 15:43:54 <ikke> then you should only add $pkgname-dbg if $CARCH != x86_64
2023-05-15 15:44:25 <psykose> nah
2023-05-15 15:44:34 <psykose> noarch implicitly skips strip/-dbgsplit
2023-05-15 15:44:46 <psykose> in your case you want all !x86_64 if your intention is 'dont build it on x86_64'
2023-05-15 15:44:53 <psykose> i'm not sure what you're actually doing however
2023-05-15 15:45:24 <psykose> 'for when e.g. makedepends cannot be satisfied on a particular arch' generally just means 'so you disable it on that arch', just a regular all !x86_64
2023-05-15 15:45:41 <zv> I just want to skip it on x86_64 because it will otherwise fail to build with unsatisfied deps, the package itself is truly noarch
2023-05-15 15:45:54 <psykose> what's in the -dbg
2023-05-15 15:46:20 <psykose> also i was wrong, it doesn't skip -dbg
2023-05-15 15:46:22 <zv> nothing at all. hence why it fails. when arch="noarch" (not arch="noarch !x86_64") it works fine
2023-05-15 15:46:38 <ikke> Why is $pkgname-dbg in there then?
2023-05-15 15:46:40 <ikke> Just remove it?
2023-05-15 15:46:49 <psykose> can you just paste the actual file
2023-05-15 15:47:35 <zv> https://cgit.adelielinux.org/packages/tree/user/ant/APKBUILD
2023-05-15 15:48:26 <psykose> and when you build that on x86_64 env, it fails? what should i run to reproduce it
2023-05-15 15:49:01 <psykose> that looks correct however
2023-05-15 15:49:04 <psykose> we have a million of those
2023-05-15 15:49:17 <zv> s/x86_64/armv7 here, you can reproduce it by just 'abuild -r', the relevant bit of error log is here https://git.adelielinux.org/adelie/packages/-/issues/1031
2023-05-15 15:49:42 <zv> the build is successful when you change it back to arch="noarch"
2023-05-15 15:49:51 <ikke> that does not seem to correspond with the APKBUILD you linked to
2023-05-15 15:50:03 <psykose> do you have DEFAULT_DBG=1
2023-05-15 15:50:07 <psykose> that would do that
2023-05-15 15:50:55 <psykose> the check here would add a -dbg with nothing https://git.alpinelinux.org/abuild/tree/abuild.in#n2893
2023-05-15 15:51:10 <psykose> since you have "noarch .." instead of "noarch" it would create a subpackage that does nothing and fail like that
2023-05-15 15:51:18 <psykose> it is an actual bug but we don't use default_dbg ourselves
2023-05-15 15:51:31 <psykose> the [ "$arch" != "noarch" ] has to be changes to just check if 'noarch at all'
2023-05-15 15:51:38 <psykose> you can probably patch it pretty easily
2023-05-15 15:52:03 <zv> right, thanks, wanted to confirm this is an abuild bug and not my being stupid with an undocumented convention
2023-05-15 15:52:37 <WhyNotHugo> Not sure where to send this, but I have a small patch for abuild adding a man page: https://git.sr.ht/~whynothugo/abuild/commit/36ce560add6bde4a7be09ed61b19ce2c1dd22b9e
2023-05-15 15:52:45 <psykose> to the abuild repo
2023-05-15 15:52:58 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/
2023-05-15 15:53:31 <WhyNotHugo> Oh, I'd only found https://git.alpinelinux.org/abuild/
2023-05-15 15:54:44 <psykose> zv: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10109
2023-05-15 15:58:35 <zv> thanks
2023-05-15 16:03:49 <psykose> WhyNotHugo: thanks
2023-05-15 16:05:24 <psykose> WhyNotHugo: also did the qemu issues get fixed
2023-05-15 16:25:03 <zv> psykose: want me to come up with a patch or should i wait for someone to get around to it?
2023-05-15 16:27:42 <psykose> you could
2023-05-16 14:05:58 <Newbyte> Did my previous two messages go through? It seems Matrix <-> IRC bridging is having issues.
2023-05-16 14:06:21 <MelMalik> What are the contents of your previous two messages?
2023-05-16 14:06:47 <psykose> Newbyte: no
2023-05-16 14:07:23 <pj> look in log: https://irclogs.alpinelinux.org/%23alpine-devel-2023-05.log
2023-05-16 14:07:45 <pj> > How do I properly combine making a subpackage noarch with having a non-default subpackage splitting function?
2023-05-16 14:07:48 <pj> > This doesn't work: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47200/diffs?commit_id=10d95391f65fdcffd2896915cf553ab474a99105#01f3c4fc25d632ecf7c616aec4abd86f515b5bb9_65_69
2023-05-16 14:08:52 <Newbyte> MelMalik: What pj posted (thanks)
2023-05-16 15:09:11 <WhyNotHugo> psykose: I didn't actually, but I've no idea exactly what's broken.
2023-05-16 15:09:27 <psykose> didn't what
2023-05-16 15:09:48 <psykose> a
2023-05-16 15:09:48 <psykose> ah
2023-05-16 15:10:11 <Newbyte> a
2023-05-16 15:13:30 <psykose> hmm
2023-05-16 15:13:34 <psykose> not sure what else it could be
2023-05-16 15:15:27 <ikke> Newbyte: one : too many
2023-05-16 15:15:55 <ikke> it's not ::noarch, it's <subpkgname>:[splitfunc]:[arch]
2023-05-16 15:20:31 <Newbyte> ikke: got it, thanks
2023-05-16 16:03:54 <zv> psykose: this is based on an older abuild, but generally does this approach look correct? tested and working for us. https://cgit.adelielinux.org/packages/tree/system/abuild/noarch.patch?id=92d883729d221f4e26ca83fbd3a5870746f4aa09
2023-05-16 16:05:03 <zv> not all of these changes may be needed but I couldn't be bothered to prove out all possibilities
2023-05-16 16:12:19 <psykose> zv: yeah
2023-05-16 16:12:59 <zv> cool. i will fix the missing quotes on one of those, rebase onto upstream abuild and submit
2023-05-16 16:17:46 <ncopa> zv: would be nice with tests also
2023-05-16 16:18:07 <zv> where would tests go?
2023-05-16 16:18:17 <zv> or you mean 'test' the command, not unit/reg tests
2023-05-16 16:19:14 <ncopa> i mean unit/reg test. they would go into tests/abuild_test
2023-05-16 16:20:09 <ncopa> usually when there is a bug, I start with create a testcase there, to show the problem
2023-05-16 16:20:19 <ncopa> and to verify that the fix actually fixes it
2023-05-16 16:29:31 <zv> since we are using a very old fork of abuild right now, I may leave this as an exercise to the reader
2023-05-16 18:10:18 <sam_> psykose: a project raised an interesting point wrt edge's current revert of the musl LFS stuff
2023-05-16 18:10:28 <sam_> pretty much every project which does musl in CI uses alpine containers, and usually edge
2023-05-16 18:10:31 <psykose> what was the interesting point
2023-05-16 18:10:44 <sam_> libvirt, for example, didn't find a build failure with the LFS changes because they use alpine in ci
2023-05-16 18:10:50 <sam_> because of the revert in the musl pkg
2023-05-16 18:11:27 <psykose> please direct all complaints to the rust developers
2023-05-16 18:11:27 <psykose> ty
2023-05-16 18:11:33 <sam_> i am believe me
2023-05-16 18:12:32 <sam_> ofc im subscribed to every single PR and issue about it and there's 0 activity
2023-05-16 18:12:34 <sam_> almsot as if hardcoding loads of shit is ab ad idea
2023-05-16 18:12:36 <sam_> and then nobody wants to touch it, crazy
2023-05-16 18:13:52 <psykose> it's slowly moving
2023-05-16 18:13:57 <psykose> they merged the rust one so libc is next
2023-05-16 18:13:58 <psykose> i guess
2023-05-16 18:14:01 <psykose> but that's still months away
2023-05-16 18:18:32 <sam_> fml
2023-05-16 18:24:42 <pj> psykose: can we expect musl 1.2.4 in this century?
2023-05-16 18:35:26 <psykose> it's already there?
2023-05-16 18:51:23 <pj> in rust?
2023-05-16 18:55:30 <psykose> no
2023-05-16 18:55:34 <psykose> ask the rust developers not me
2023-05-16 18:56:46 <Newbyte> what, I thought you maintained everything
2023-05-16 20:29:11 <Arnavion> pj, psykose: Rust v1.71 is expected to come out in 2023-07 and that will only update to musl v1.2.3. v1.2.4 will probably not happen any time soon
2023-05-16 20:29:56 <psykose> it doesn't have to
2023-05-16 20:30:01 <Arnavion> Even if it happened today it'll take 18 weeks for it to move from nightly to stable
2023-05-16 20:30:05 <psykose> only the lfs64 fixes have to land at some point
2023-05-16 20:30:17 <psykose> and mostly just in libc, which can happen soon for the 0.3 break i guess
2023-05-16 20:30:25 <psykose> the actual rust parts are whatever because that one is smaller
2023-05-16 20:30:29 <psykose> i can just backport that one
2023-05-16 20:30:31 <psykose> libc not so much
2023-05-16 20:31:08 <psykose> the other thing that needs fixing is gdc
2023-05-16 20:31:21 <psykose> i think it isn't fixed yet either, and is probably a very small change
2023-05-16 20:31:31 <psykose> granted the obvious patch doesn't work so that would be nice if you want to help :p
2023-05-16 20:41:02 <pj> ok?
2023-05-16 20:49:09 <Arnavion> Seems a bunch of stuff is planned for libc 0.3 so who knows how long it'll take   https://github.com/rust-lang/libc/issues/3248
2023-05-16 20:50:19 <psykose> i give it about 2 months
2023-05-17 10:07:00 <uquark> Hello Alpine developers, I'm working with a PJSIP + SWIG + Java app on Alpine Linux in Docker.
2023-05-17 10:07:02 <uquark> I'm getting a `StackOverflowError` when Java code is called from native code, despite not having recursion in my code.
2023-05-17 10:07:16 <uquark> I've tried to increase stack size during PJSIP build and enlarged Java stack size with `-Xss1024k` JVM option. Details: https://rentry.co/2ug6c
2023-05-17 10:07:19 <uquark> Yet, the `StackOverflowError` still persists. Here's the stack trace: https://rentry.co/uqo63c
2023-05-17 10:07:20 <uquark> Does anyone have advice on how to increase the stack size for Java code called from native code in Alpine? Thanks in advance.
2023-05-17 10:11:07 <ncopa> usually this is due to large stack allocations in threads. the default thread stack size is smaller than most other platforms.
2023-05-17 10:11:24 <ncopa> i dont think  `-Xss1024k` set the default stack size
2023-05-17 10:11:39 <ncopa> the default *thread* stack size
2023-05-17 10:12:10 <uquark> I tried rebuilding the library with linker flags to increase the thread stack size, see https://rentry.co/2ug6c
2023-05-17 10:12:16 <uquark> Didn't work though
2023-05-17 10:12:38 <ncopa> LDFLAGS="-Wl,-z,stack-size=8388608" is the correct thing i think
2023-05-17 10:12:53 <uquark> Yeah but sadly did not work :(
2023-05-17 10:12:53 <ncopa> however, you need to do that on the executable, not the library
2023-05-17 10:13:13 <ncopa> which to my understading is java in this case?
2023-05-17 10:13:16 <uquark> Hm. It's a Java app loading a shared object
2023-05-17 10:13:18 <uquark> yes
2023-05-17 10:13:26 <ncopa> how was java built?
2023-05-17 10:13:31 <ncopa> i mean which java build
2023-05-17 10:13:50 <uquark> I just installed openjdk17-jre with apk
2023-05-17 10:15:32 <ncopa> does it actually run in a thread?
2023-05-17 10:16:02 <uquark> It's quite a blackbox but yes
2023-05-17 10:18:51 <ncopa> We might have patched openjdk in teh past to increase the default stack size
2023-05-17 10:20:21 <ncopa> um, maybe we should confirm that it actually is the default stack thread that is too small
2023-05-17 10:20:34 <ncopa> there is a tool for setting elf attributes
2023-05-17 10:20:36 <uquark> I'm ready to perform any tests
2023-05-17 10:20:38 <ncopa> patchelf or similar
2023-05-17 10:20:42 <ncopa> or chelf
2023-05-17 10:20:44 <uquark> chelf yeah
2023-05-17 10:21:07 <ncopa> might be possible to set the -Wl,-z,stack-size=8388608 via chelf
2023-05-17 10:21:11 <ncopa> on the java binary
2023-05-17 10:21:17 <ncopa> just to test if it makes any difference
2023-05-17 10:21:23 <uquark> will try, thx
2023-05-17 10:22:28 <ncopa> the real fix is likely to fix the pjsip to not do large allocations on stack
2023-05-17 10:24:05 <uquark> I understand but my C/C++ skills are really, really far from achieving this :)
2023-05-17 10:25:34 <ncopa> have you tried using the precompiled pjsip tha comes with pjproject package?
2023-05-17 10:26:34 <uquark> No because we apply our own patches 
2023-05-17 10:28:23 <uquark> Lol what: ~ # chelf /usr/bin/java
2023-05-17 10:28:25 <uquark> /usr/bin/java: INTERP=/lib/ld-musl-x86_64.so.1 STACKSIZE=0
2023-05-17 10:28:43 <ncopa> i think that means default
2023-05-17 10:28:53 <psykose> can you share your program
2023-05-17 10:30:28 <ncopa> do you know which codec is used when it happens? it might be one of the embedded libs
2023-05-17 10:30:46 <ncopa> i have fixed lots of upstream packages to not use big stack allocations in the past
2023-05-17 10:31:01 <ncopa> might be it fixed upstream already
2023-05-17 10:36:49 <ncopa> would be nice to have a stacktrace of the native code
2023-05-17 10:40:34 <psykose> also java -Xss is stack size, but only for the java threads
2023-05-17 10:40:39 <psykose> granted i'm not sure how that interacts
2023-05-17 10:40:50 <psykose> i would imagine if you stack overflowed in native thread you would just segfault
2023-05-17 10:40:53 <psykose> not get a helpful java errr
2023-05-17 10:45:07 <ncopa> maybe
2023-05-17 10:45:26 <ncopa> woudl be interesting to know if chelf on java helps
2023-05-17 11:12:18 <uquark> After a few tests it seems that increasing thread stack limit to 8MB worked 🎉️
2023-05-17 11:12:53 <uquark> chelf should really be in official repo
2023-05-17 11:13:19 <uquark> big thanks to ncopa
2023-05-17 11:14:16 <ncopa> i wonder if we should bump it in the openjdk binary
2023-05-17 11:14:32 <ncopa> but I'd like to have it as 2MB instead of 8 if possible
2023-05-17 11:14:36 <psykose> if you change it to 1mb does it work
2023-05-17 11:14:50 <uquark> will try, is it urgent?
2023-05-17 11:14:50 <ncopa> yeah, thats exactly what I wonder
2023-05-17 11:14:52 <ncopa> no
2023-05-17 11:15:11 <ncopa> but we'll forget it if its not reported in an issue
2023-05-17 11:15:16 <psykose> yes, it's urgent
2023-05-17 11:15:22 <ncopa> :D
2023-05-17 11:15:50 <psykose> without a way to reproduce it and without you finding the minimum number we simply won't change it
2023-05-17 11:15:51 <psykose> :p
2023-05-17 11:16:14 <uquark> I'll do some tests in a few hours, but the result is dependent on how bloated the library is. There's just no "optimal" value
2023-05-17 11:16:21 <psykose> wrong
2023-05-17 11:16:27 <psykose> because this is settable at runtime
2023-05-17 11:16:31 <psykose> it's a bug to need to set it at all
2023-05-17 11:16:36 <psykose> you can change it to anything in code
2023-05-17 11:17:12 <psykose> but since it is way too hard for some people to spend time actually fixing their broken code, and they prefer silly workarounds, you have to find an actual sane value that is not 8mb
2023-05-17 11:17:21 <psykose> and then perhaps it can be set
2023-05-17 11:17:36 <uquark> Ok I totally don't understand how this thing works so I won't make dumb assumptions :) I will test it with 1-2MB soon
2023-05-17 11:18:13 <psykose> from C it's https://www.ibm.com/docs/en/zos/2.2.0?topic=functions-pthread-attr-setstacksize-set-stacksize-attribute-object
2023-05-17 12:32:03 <ncopa> it sort of surprises me that this is the first time we are hitting this
2023-05-17 13:03:59 <psykose> because it's not actually broken, just in this specific application
2023-05-17 13:32:18 <EvTheFuture> Anyone experienced or heard of problem with external monitor on Alpine 3.18 with kernel 6.1 and amdgpu? Worked flawless in Alpine 3.17 with kernel 5.15. Now I get this more than 50% of the times when I connect the HDMI cable to the monitor: [drm:detect_link_and_local_sink [amdgpu]] *ERROR* No EDID read.
2023-05-17 13:41:22 <psykose> looks like https://gitlab.freedesktop.org/drm/amd/-/issues/615 amongst others, an issue that happens at random at any version
2023-05-17 13:41:23 <psykose> :D
2023-05-17 15:21:25 <EvTheFuture> @psykose: Well, something has made it being triggerd much easier in 6.1 then, because this is the first time I ever see it on this laptop, which Iv'e been using for about a year
2023-05-17 15:30:08 <EvTheFuture> Wonder if it could be in conjunction with a firmware change or something
2023-05-17 15:34:13 <psykose> yeah something like that
2023-05-17 16:00:20 <tomalok> with as long as docker 20.x was around, i'm surprised to see docker 24 so soon after docker 23.
2023-05-17 16:05:05 <psykose> more features more faster
2023-05-17 16:06:20 <psykose> Introduce experimental support for containerd as the content store (replacing the existing storage drivers). 
2023-05-17 16:06:20 <psykose> hah
2023-05-17 16:07:42 <skarnet> it's fascinating that "what is the best driver to store (check notes) content" is even a question
2023-05-17 16:08:23 <psykose> can't tell if trolling
2023-05-17 16:09:17 <skarnet> not trolling. "content store" is a sequence of words that has close to zero information. What does a content store even do?
2023-05-17 16:09:36 <skarnet> When I hear "content store" I usually think of a hard drive
2023-05-17 16:09:43 <psykose> most things have no information if you put them with no context
2023-05-17 16:10:12 <psykose> you would have to know what moby is and does and a bunch more things for it to have meaning
2023-05-17 16:10:31 <psykose> otherwise yes, it's easy to take the literary value and pretend it makes no sense
2023-05-17 16:10:43 <abby> contain nerd
2023-05-17 16:10:53 <psykose> (which is just fancy words for trolling)
2023-05-17 16:11:45 <psykose> starts from here https://github.com/moby/moby/releases/tag/v24.0.0
2023-05-17 16:11:52 <psykose> abby: contain thyself
2023-05-17 16:12:43 <skarnet> I know what moby is and does, that doesn't mean I have to accept that "content store" isn't terrible naming
2023-05-17 16:13:25 <psykose> fell for troll bait counter: approaching overflow limit
2023-05-17 16:13:26 <psykose> classic
2023-05-17 16:21:27 <pj> "The --host CLI flag now supports a path component in a ssh:// host address, allowing use of an alternate socket path without configuration on the remote host. "
2023-05-17 16:21:53 <pj> I wonder whom did that
2023-05-17 16:42:46 <minimal> skarnet: a "content store" stores content, in the same way as a "graphic equaliser" equalises graphics ;-)
2023-05-17 16:45:54 <mercenary> in that way a content store would be selling content
2023-05-17 16:46:14 <skarnet> minimal: thanks for being exactly as informative as the release notes, I guess?
2023-05-17 16:46:45 <minimal> skarnet: yes I was being minimally informative ;-)
2023-05-17 16:46:57 <skarnet> :D
2023-05-17 16:48:21 <minimal> the "graphic equaliser" reference it to a sketch from a 1980s UK TV comedy show with 2 marketing guys on stage at the launch of a new all-in-one HiFi system who know absolutely nothing about audio
2023-05-17 16:57:45 <tomalok> https://github.com/containerd/containerd/blob/main/docs/content-flow.md has something about "content store" though i'm not sure what it's describing there is particularly new
2023-05-17 17:10:31 <minimal> interesting that docker 0.24 has actually removed the deprecated overlay (and aufs) storage drivers that a couple of people had problems with when a recent release disabled them by default
2023-05-17 19:22:43 <ikke> seems like github is having issues
2023-05-17 19:26:34 <minimal> they wrote a blog article (yesterday? day before?) to explain why they had so many issues recently lol
2023-05-17 19:28:41 <ikke> https://github.blog/2023-05-16-addressing-githubs-recent-availability-issues/
2023-05-17 19:28:53 <minimal> that's the one
2023-05-18 02:40:40 <tomleb> hey folks, currently the navidrome package writes its cache to /var/lib/navidrome/cache. I'd like to move the cache to /var/cache/navidrome instead. There isn't a configuration for this path. Unsure what's the best way to go about it: patch the application, work with upstream to add a flag in the config file for it, symlink the current cache to /var/cache/navidrome?
2023-05-18 02:40:53 <tomleb> Or keep the current behavior
2023-05-18 05:31:23 <fluix> patching it or working with upstream are probably best but I don't really package for Alpine
2023-05-18 06:21:48 <Arnavion> (   https://github.com/navidrome/navidrome/blob/be12c12b/utils/cache/file_caches.go#L212   I assume)
2023-05-18 06:22:50 <Arnavion> The symlink approach wouldn't work because `/var/cache` can get cleaned up which would delete the symlink target
2023-05-18 07:36:19 <ncopa> tomleb: work with upstream is the best approach
2023-05-18 09:09:40 <adhawkins> Hi all. The developer of one of the packages I maintain has told me that it is going to be renamed in the future. How do I handle that in Alpine?
2023-05-18 09:09:54 <adhawkins> If there's a doc for it, a pointer to that is fine.
2023-05-18 09:11:14 <ikke> Add a provides and replaces to the package with the old name
2023-05-18 09:11:25 <ikke> The provides should include the version 
2023-05-18 09:12:16 <ikke> provides="old name=$pkgver-r$pkgrel"
2023-05-18 09:31:53 <nmeum> psykose: do you have any thoughts on shipping a /etc/profile.d file with the aarch64 version of GHC which adds /usr/lib/llvm14/bin to $PATH by default? _if_ the builders source /etc/profile.d/* then this would not require us to set PATH explicitly in every Haskell APKBUILD
2023-05-18 09:38:51 <adhawkins> So if emborg v1.36 becomes assimilate v1.0, then in the assimilate APKBUILD I would put:
2023-05-18 09:38:55 <adhawkins> provides="emborg=1.36-r0"
2023-05-18 09:41:37 <ikke> If the version scheme changes it becomes trickier
2023-05-18 09:53:58 <adhawkins> So it'd be easirr if assimilate's first release was (say) v2.0?
2023-05-18 10:09:47 <psykose> nmeum: i think it's better to be explicit there since it requires that path, we do the same for any other build that has to add a path to something
2023-05-18 10:09:52 <psykose> a profile that adds paths is a bit magic
2023-05-18 10:18:55 <ikke> adhawkins: yes, but maybe it works if the provides is a higher version os the previous version
2023-05-18 10:19:15 <ikke> adhawkins: but I'd have to test how apk behaves
2023-05-18 10:20:13 <psykose> with -a it's fine
2023-05-18 10:24:17 <ikke> another curl regression, fun
2023-05-18 10:25:25 <psykose> which one
2023-05-18 10:25:41 <ikke> https://curl.se/mail/lib-2023-05/0029.html
2023-05-18 10:25:59 <psykose> ah
2023-05-18 13:03:07 <tomleb> Ariadne: Yes pretty much this. Also you're probably right about the symlink approach. ncopa: Thanks, I'll see if upstream wants to consider this.
2023-05-18 13:09:26 <psykose> it doesn't sound like something that even has to be fixed
2023-05-18 13:11:44 <psykose> that said, all you need is to add a cache-dir= option
2023-05-18 14:12:39 <Newbyte> https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/1034846
2023-05-18 14:12:44 <Newbyte> wonder why the armhf CI keeps getting stuck here
2023-05-18 14:49:01 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/issues/14667
2023-05-18 15:00:19 <ikke> psykose: wonder whether it makes sense to set the cp15_barrier setting in the VMs as well
2023-05-18 15:00:37 <psykose> that's where it is required
2023-05-18 15:00:45 <psykose> whatever kernel the thing is running on
2023-05-18 15:43:04 <uquark> Hi again. Yesterday, ncopa had me check if a 1MB thread stack size for the JRE works for my PJSIP use case. Turns out, it's enough. Right now, I'm using chelf to adjust the stack size, but I'm on the lookout for a more streamlined approach
2023-05-18 15:59:04 <psykose> now check 512k
2023-05-18 16:02:24 <ikke> they left
2023-05-18 18:13:38 <psykose> pj: you might want to test -r6 rust to see if some static stuff works now
2023-05-18 18:14:36 <psykose> -Bdynamic is finally gone when +crt-static, so it should work in all cases (or just error since the .a's don't exist of nativelibs)
2023-05-18 18:59:08 <pj> <psykose> "pj: you might want to test -r6..." <- it works for me all the time
2023-05-18 18:59:17 <pj> I'm just not using alpine package lol
2023-05-18 18:59:28 <psykose> then feel free to not test it
2023-05-18 18:59:37 <pj> (but will test later, thamk babe)
2023-05-18 21:30:57 <pj> psykose: seems to work
2023-05-18 21:31:04 <psykose> poggers
2023-05-18 21:32:56 <pj> guess I can replace rustup-init with just cardo in my build system
2023-05-18 21:39:23 <mio> is anyone else getting an error in the CI builder about openmpi? `so:libmpi.so.40 (no such package): required by: openmpi-4.1.5-r2[so:libmpi.so.40]`
2023-05-18 21:42:33 <psykose> that was just me forgetting a relbump
2023-05-18 21:43:34 <mio> okay, thanks
2023-05-18 21:47:26 <mio> psykose: any further thoughts on the opentoonz MR after the patch? if it's a no-go, can update the package request ticket with the findings and wrap it up. whenever it is most convenient for you to chime in again, thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/46596/
2023-05-18 21:48:20 <mio> was trying to rebase and put it through the builders one more time so you can have a look at it
2023-05-18 22:57:22 <minimal> anyone seen this before? https://zacksiri.dev/posts/why-i-created-pakman ?
2023-05-18 22:57:24 <minimal> "builds your application using github actions into alpine packages that get delivered to an S3 compatible bucket you specify via instellar. Our platform then takes that built package and deploys the application on your infrastructure"
2023-05-18 23:03:09 <psykose> looks like yet more paas stuff
2023-05-18 23:03:24 <Habbie> psykose, p? packaging?
2023-05-18 23:03:47 <psykose> platform
2023-05-18 23:03:52 <Habbie> right
2023-05-18 23:04:22 <psykose> haven't seen that but i have seen at least 10 things in the same concept
2023-05-18 23:04:48 <Habbie> https://instellar.app/ <title> literally starts with PaaS
2023-05-18 23:05:50 <psykose> she <platform> on my <service> till i <buzzword>
2023-05-18 23:05:51 <psykose> idk
2023-05-18 23:05:55 <Habbie> :)
2023-05-18 23:06:24 <psykose> looks neat, but i'm the sort of nerd that enjoys this sort of stuff so it's the sort of thing i would do myself
2023-05-18 23:06:42 <psykose> software is using a bunch of software of things you don't care about and then writing things yourself for the parts you do
2023-05-18 23:08:34 <Habbie> agreed
2023-05-18 23:08:35 <Habbie> plus glue
2023-05-18 23:08:52 <Habbie> the parts you didn't want to care about, but have to :)
2023-05-18 23:09:46 <psykose> :D
2023-05-18 23:10:05 <Habbie> meanwhile, my pi gpio project randomly does things when i get up from my chair
2023-05-18 23:10:08 <Habbie> hardware was a mistake
2023-05-18 23:12:01 <psykose> fun things, i hope?
2023-05-18 23:12:20 <Arnavion> Or in the sense of static electricity
2023-05-18 23:12:20 <Habbie> well, all of this is educational
2023-05-18 23:12:30 <Habbie> me: i don't know why any of this happens
2023-05-18 23:12:33 <Habbie> my wife: that must suck
2023-05-18 23:12:37 <Habbie> me: no i'm learning so much
2023-05-18 23:12:41 <Habbie> my wife: what's wrong with you?
2023-05-18 23:12:44 <Habbie> me: i have a list
2023-05-18 23:13:00 <psykose> can confirm
2023-05-18 23:13:07 <psykose> i ask my girlfriend what is wrong with her all the time
2023-05-18 23:13:09 <Habbie> however, sometimes i do wish things would Just Work
2023-05-18 23:13:11 <Habbie> haha
2023-05-18 23:13:14 <psykose> and one of her pi gpio projects is behind me
2023-05-18 23:13:16 <Habbie> what does she say?
2023-05-18 23:13:18 <Habbie> hah
2023-05-18 23:13:28 <psykose> usually just laughs :)
2023-05-18 23:13:37 <Habbie> smart response ;)
2023-05-18 23:21:03 <minimal> this seems to be the core of it: https://github.com/upmaru/pakman
2023-05-18 23:22:32 <psykose> that's some real nice art
2023-05-18 23:24:17 <minimal> so Alpine packages, LXD, Caddy, Terraform, not sure what else they're using
2023-05-18 23:24:57 <psykose> they use the things they want to use and don't use the things they don't want to use
2023-05-18 23:25:03 <psykose> think that's that
2023-05-18 23:25:34 <minimal> oh and s6 also
2023-05-19 07:51:47 <skarnet> minimal: no lol, they're using the old "s6 as a supervisor for openrc" approach that is not the way to use it in Alpine and I'm not even sure how much it is supported in Gentoo since they wrote their own supervisor
2023-05-19 15:03:10 <psykose> it would probably be an improvement over existing
2023-05-19 18:39:37 <psykose> mostly because incremental improvements are fun
2023-05-19 18:40:20 <psykose> between s-s-d and supervise-daemon, the former is lol and the latter is broken for certain things and doesn't let you do anything with logs except dump straight to file
2023-05-19 18:40:33 <psykose> iirc just supervisor=s6 would actually solve the latter but i forget
2023-05-19 18:51:10 <skarnet> if they're using Alpine they could just use the official s6 package, which comes with a supervision tree, and start their services in it
2023-05-19 18:51:32 <skarnet> it's exactly as difficult as using the broken gentoo thing
2023-05-19 18:53:58 <psykose> it's harder to manage because instead of being part of the same rc-service already there it's another thing to use to up/down from the tree
2023-05-19 20:52:00 <skarnet> ah yes, dependencies are hard
2023-05-19 20:52:42 <skarnet> it's not like openrc had a mechanism to do, like, *just that*
2023-05-19 20:54:05 <psykose> is it the same thing or separate
2023-05-19 20:55:09 <skarnet> they provide openrc files, they could depend on the s6 service in the openrc file they provide and it would be the exact same thing
2023-05-19 20:55:43 <skarnet> since they need the s6 package installed anyway to use it as supervisor in their current form
2023-05-19 20:56:12 <skarnet> but nvm, nobody cares
2023-05-19 20:58:41 <psykose> would i be asking if i didn't care? i don't know the specifics
2023-05-19 21:20:57 <humm> skarnet: So like depend() { need s6; }; start() { s6-svc -u $RC_SVCNAME; }?
2023-05-19 21:23:19 <skarnet> humm: more like s6-svlink with the path to the service directory, but yes
2023-05-19 21:24:20 <skarnet> psykose: sorry, I think you knew. I can develop if you want the specifics, but I'm a bit busy tonight ^^'
2023-05-19 21:25:12 <humm> I see
2023-05-19 23:25:14 <psykose> skarnet: go to bed
2023-05-20 08:57:08 <shafire> hi
2023-05-20 09:02:49 <psykose> hi
2023-05-20 09:03:44 <shafire> trying to package virtualbox now, which I requested 8 years ago :)
2023-05-20 09:06:28 <psykose> ok
2023-05-20 09:06:30 <shafire> I use "abuild -r" but the unpacking process takes sooo much time. Is there a way for "rapid testing", such as to just clean the srcdir and rebuild?
2023-05-20 09:08:33 <psykose> the builddir is in the srcdir, do you mean to keep all of it
2023-05-20 09:08:49 <psykose> that would be -K but you'd have to manually call build every time
2023-05-20 10:13:35 <shafire> thanks
2023-05-21 17:48:39 <shafire> hi
2023-05-21 17:50:21 <shafire> my package requires linux headers based on "uname -r"
2023-05-21 17:50:54 <shafire> how do I add them correctly to makedepends?
2023-05-21 17:51:23 <shafire> as there are three different linux-lts-dev, linux-virt-dev, or linux-edge-dev
2023-05-21 17:51:48 <psykose> linux-headers
2023-05-21 17:52:36 <psykose> if it builds something based on actual linux-*-dev headers then that's a kernel module and something else and you generally don't make a package for it
2023-05-21 17:58:23 <shafire> ok
2023-05-21 18:17:41 <shafire> it's based on the actual linux-*-dev headers
2023-05-21 18:17:42 <shafire> *** Error: unable to find the headers of the Linux kernel to build against (KERN_DIR=/lib/modules/6.1.29-0-lts/build). Specify KERN_VER=<version> (currently 6.1.29-0-lts) and run Make again.  Stop.
2023-05-21 19:14:42 <shafire> mh
2023-05-21 19:15:06 <shafire> ~ $ VBoxManage list vms "test" {ac3cd1b3-3269-40f9-acea-658889354a11}
2023-05-21 19:15:14 <shafire> virtualbox seems to work
2023-05-21 19:20:19 <ptrc> did you reuse the already existing vbox mr, or start from scratch
2023-05-21 19:20:36 <shafire> I reused both
2023-05-21 19:20:48 <shafire> but I build just a minimal headless variant
2023-05-21 19:22:52 <psykose> i heard there's an alternative that works better than oracle garbageware virtualbox
2023-05-21 19:22:59 <psykose> called literally-every-other-virtualisation-program-ever-made
2023-05-21 19:26:45 <ptrc> virtualbox emulates some ancient stuff that qemu can't anymore, iirc
2023-05-21 19:31:00 <Ermine> ptrc: vmware emulates ancient stuff better. E.g. win9x works stable there, while win98 fails to shut down on virtualbox
2023-05-21 19:31:16 <ptrc> yeah, but vmware is insanely proprietary
2023-05-21 19:31:28 <psykose> if you have actual reasons to run win9x you can pay 4 it
2023-05-21 19:31:33 <psykose> spoiler:
2023-05-21 19:31:54 <Ermine> Yeah, so I break the law
2023-05-21 19:33:57 <Ermine> Also, VBox UI is simple. 10yo me managed to run stuff with it
2023-05-21 19:37:04 <shafire> VBoxHeadless -startvm test --vrdp on Oracle VM VirtualBox Headless Interface 7.0.8 Copyright (C) 2008-2023 Oracle and/or its affiliates  Starting virtual machine: 10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
2023-05-21 19:57:00 <shafire> https://i.postimg.cc/qM3hmb2b/image-2023-05-21-215640673.png
2023-05-21 19:57:03 <shafire> works :)
2023-05-21 19:57:25 <shafire> vbox in vbox
2023-05-22 03:38:42 <Qa> I'm building (personal) apks that will be used in several containers, is it possible to make unsinged apks and simply install them directly from the apk file without having to make a repository?
2023-05-22 03:56:28 <psykose> apk add ./file --allow-untrusted
2023-05-22 04:41:09 <Qa> thanks!
2023-05-22 07:07:06 <pj> did something break with libssl on aarch64?
2023-05-22 07:07:31 <pj> I'm getting wrong format when linking
2023-05-22 07:08:52 <psykose> nope
2023-05-22 07:35:48 <pj> seems to be gcc
2023-05-22 07:36:07 <psykose> can u share the actual problem
2023-05-22 07:36:16 <pj> libopenssl_sys-a50c1360a9b5179d.rlib(libssl-lib-methods.o): Relocations in generic ELF (EM: 183)
2023-05-22 07:36:39 <psykose> missing roughly the other 10k lines of logs
2023-05-22 07:36:57 <pj> libopenssl_sys-a50c1360a9b5179d.rlib: error adding symbols: file in wrong format
2023-05-22 07:37:59 <pj> The other 10k lines of logs are just Compiling crate-name
2023-05-22 07:38:13 <psykose> yes you blithering fool
2023-05-22 07:38:20 <psykose> share the whole environment and what you are doing
2023-05-22 07:38:32 <pj> https://github.com/lapce/lapce/actions/runs/5040362637/jobs/9039977693
2023-05-22 07:40:50 <psykose> you're trying to link an aarch64 elf object with x86_64 binaries
2023-05-22 07:41:32 <pj> ah yes, "I'm trying"
2023-05-22 07:41:46 <pj> I'm actively doing that
2023-05-22 07:44:13 <psykose> that's what the logs say yes
2023-05-22 07:44:36 <pj> thank you, did you learn anything else from logs?
2023-05-22 07:44:42 <pj> perhaps something I didn't already knew?
2023-05-23 06:14:35 <powers> two questions
2023-05-23 06:14:39 <powers> 1. how would one manually sign a kernel-module in alpine?
2023-05-23 06:14:55 <powers> 2. how can i find the kernel config that determines if modules are signed on install? Its called "CONFIG_MODULE_SIG_ALL" and its not in sysctl
2023-05-23 06:30:30 <powers> ive found the answer to question-#1, linux-lts-dev package /scripts/sign-file. The apk search feature is really strong :)
2023-05-23 06:30:58 <powers> however question two is still a mystery
2023-05-23 06:32:13 <abby> zgrep MODULE_SIG_ALL /proc/config.gz
2023-05-23 06:32:32 <ikke> powers: it can be that that module is not enabled yet, as we don't want to lock out out if tree (akms) modules 
2023-05-23 06:32:32 <abby> if that exists on alpine
2023-05-23 06:32:46 <ikke> You might need to modprobe configs 
2023-05-23 06:43:09 <powers> ikke yes, that would be it, thank you. just a question however, without configs loaded, my module was rejected by the kernel for not being signed-properly. Where is that handled?
2023-05-23 06:44:31 <powers> is it just built-in to the kernel itself (would make sense for integrity reasons)? or is there another module? 
2023-05-23 06:45:25 <powers> abby thank you for the response. this is how to access it after its loaded
2023-05-23 07:07:08 <ncopa> you'll have to create your own keypair though. Not sure how you add an additional pub key to kernel
2023-05-23 11:07:33 <adhawkins> There seem to be some stuck builders. I assume it's a known issue?
2023-05-23 11:08:31 <ikke> adhawkins: yes
2023-05-23 11:08:38 <ikke> I assume you mean the arm runners
2023-05-23 11:09:36 <adhawkins> That's right ikke. aarch64, armhf and armv7. If it's known about I'll crawl back under my rock :)
2023-05-23 11:10:04 <ikke> It's a network issue, trying to figure out what causes it, but haven't had much time to dig into it
2023-05-23 11:10:21 <adhawkins> Ok, no worries. As long as it's not something wrong with my package updates.
2023-05-23 11:24:21 <ikke> adhawkins: ok, managed to find the issue
2023-05-23 11:24:41 <ikke> well, one of them 🤔
2023-05-23 13:43:00 <adhawkins> It's a start ikke :D
2023-05-23 14:36:14 <minimal> ncopa: normally when signing modules with another pub you'd load that key into the UEFI keystore, that's what I do with Debian when using Virtualbox modules not provided by Debian - I have my own key to sign those and loaded it into UEFI keystore
2023-05-23 14:36:33 <minimal> s/another pub/another key/
2023-05-23 17:20:20 <shafire> hi
2023-05-23 17:21:27 <shafire> When I use abuild without fakeroot, I can successfully compile a package. When I use it with fakeroot, I get a compile error: error: 'uint32_t' was not declared in this scope   note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
2023-05-23 17:30:22 <psykose> you mean rootbld?
2023-05-23 17:30:28 <ikke> shafire: are you perhaps missing a dependency?
2023-05-23 17:30:36 <ikke> That is installed on your system 
2023-05-23 17:30:38 <psykose> your host gcc is 12 and the rootbld one is 13
2023-05-23 17:30:40 <shafire> ah, yes, I mean rootbld
2023-05-23 17:31:09 <psykose> and the error tells you exactly what the issue is
2023-05-23 17:31:30 <shafire> ok, so I have to patch that
2023-05-23 17:31:36 <shafire> https://gcc.gnu.org/gcc-13/porting_to.html
2023-05-23 17:31:38 <shafire> thanks psykose 
2023-05-23 19:27:05 <powers> there seems to be an issue with "apk index" but i want to double-check here to make sure
2023-05-23 19:27:51 <powers> when creating an index from a repo, some of the the packages are not added no matter what flags are present
2023-05-23 19:28:38 <psykose> which ones
2023-05-23 19:29:16 <psykose> you are probably missing --rewrite-arch
2023-05-23 19:29:21 <powers> to be more specific, i was attempting to add "alpine-sdk linux-lts-dev linux-headers" to a repo - with all of its dependencies
2023-05-23 19:29:29 <psykose> and the noarch ones become 'missing'
2023-05-23 19:29:39 <powers> yes exactly
2023-05-23 19:30:01 <powers> fortify-headers, linux-headers, ncurses, etc
2023-05-23 19:30:16 <powers> is this a bug? or am i missing something?
2023-05-23 19:30:43 <psykose> you have to use --rewrite-arch
2023-05-23 19:30:47 <ikke> psykose: mentioned it
2023-05-23 19:30:57 <ikke> Twice 
2023-05-23 19:31:06 <powers> okay thank you, x86_64 as an arg is fine?
2023-05-23 19:31:18 <powers> or is it amd64
2023-05-23 19:31:41 <psykose> /etc/apk/arch
2023-05-23 19:31:51 <powers> thanks for the help
2023-05-23 19:31:56 <powers> appreciated
2023-05-23 19:32:07 <psykose> the reason they have 'noarch' is because of some incomplete work towards making noarch packages etc
2023-05-23 19:32:15 <psykose> but apk itself only tracks the host arch and nothing else
2023-05-23 19:32:28 <psykose> so implicitly having .apk's that don't match /etc/apk/arch isn't installable
2023-05-23 19:33:06 <powers> yeah, that makes sense. noarch makes sense for those packages, they have no real-dependencies or binaries
2023-05-23 19:33:47 <powers> its just that i though apk would do it automagically. the docs are sparse so its really hard to tell
2023-05-23 19:35:49 <powers> i plan on taking things that im using for this project and writing alpine wikis, and the irc saves me a lot of time
2023-05-23 20:35:40 <ikke> adhawkins: it is working again now, thanks for encouraging me to look into it again
2023-05-23 20:44:09 <adhawkins> No worries ikke, thanks. Was just worried my latest package update was broken for some reason :)
2023-05-24 15:01:21 <adhawkins> Hi all. Updating one of my python packages that has changes from using setup.py to pyproject.toml. A side effect of this is that during testing, it creates two directories (d1 and d2) and then looks for all directories starting with 'd',, expecting to only find d1 and d2
2023-05-24 15:01:24 <adhawkins> It's now also finding 'dist'.
2023-05-24 15:01:36 <adhawkins> Is there any way to have the tests run in a different (clean) directory?
2023-05-24 15:50:41 <adhawkins> I've updated the 'check' function to this: https://paste.debian.net/1281047/
2023-05-24 15:50:45 <adhawkins> Is that a sensible thing to do?
2023-05-24 15:55:00 <ncopa> yeah, that looks ok
2023-05-24 15:57:47 <adhawkins> Ok, thanks ncopa.
2023-05-24 15:57:53 <adhawkins> Regarding the 'sed' line, couple of questions:
2023-05-24 15:58:04 <adhawkins> 1. Is there an alpine package that makes a link from python -> python3
2023-05-24 15:58:20 <adhawkins> 2. Would that sed line be more correctly achieved using a patch file?
2023-05-24 15:59:10 <ncopa> i prefer to use patch files as it will fail to apply when they fix it upstream and patch can be removed. the sed line will stay forever
2023-05-24 15:59:25 <ncopa> i dont think there are any package for python symlink
2023-05-24 16:00:07 <adhawkins> Ok, thanks ncopa, will change to use a patch.
2023-05-24 16:00:29 <ikke> python3 provides both
2023-05-24 16:00:53 <adhawkins> That's odd ikke, as the tests used to fail because it couldn't find 'python'. Let me try again without.
2023-05-24 16:01:17 <ikke> https://pkgs.alpinelinux.org/contents?file=python*&path=%2Fusr%2Fbin&name=&branch=edge&repo=main&arch=x86_64
2023-05-24 16:01:57 <adhawkins> Ok, seems to work without now. Odd. I'll remove it!
2023-05-24 16:40:53 <shafire> hi
2023-05-24 16:45:17 <jmondi> psykose:
2023-05-24 16:45:19 <jmondi> ups
2023-05-24 16:45:23 <jmondi> psykose: ping :)
2023-05-24 20:04:24 <wej> https://about.gitlab.com/releases/2023/05/23/critical-security-release-gitlab-16-0-1-released/
2023-05-24 20:04:57 <ikke> Yes, saw it, we are not on 16 yet
2023-05-24 20:13:29 <wej> okay :)
2023-05-24 21:05:29 <psykose> jmondi: what is it
2023-05-24 21:17:03 <powers> what does it mean for a packet to be capped? Does it mean that the receiver is rejecting requests, or has no more bandwidth to accept requests?
2023-05-24 21:18:02 <powers> In particular I am referring to `NLM_F_CAPPED` in netlink.h, the documentation for it is all but non-existent
2023-05-25 00:26:01 <skarnet> I just got an e-mail: "Alpine aport bearssl has been flagged out of date"
2023-05-25 00:26:17 <skarnet> ... yeah, I haven't changed it because there hasn't been anything new for a while
2023-05-25 00:26:36 <skarnet> it still works. It's not out of date.
2023-05-25 00:26:57 <skarnet> The mail tells me to abump it, but why should I abump something that has no reason to change?
2023-05-25 00:27:30 <psykose> any1 can put any spam into the field and hit send
2023-05-25 00:27:48 <psykose> i.e. literally spam
2023-05-25 00:27:51 <psykose> second time :D
2023-05-25 00:28:24 <skarnet> ... what?
2023-05-25 00:29:16 <skarnet> you mean there's an open way for the public to send spam to package maintainers from the pkgs@alpinelinux.org address?
2023-05-25 00:29:27 <skarnet> that doesn't sound like a good idea
2023-05-25 00:33:08 <psykose> i have suggested to remove it maybe 9 times by now
2023-05-25 00:33:29 <psykose> i don't enjoy the complete random garbage in my inbox either
2023-05-25 00:33:45 <skarnet> well, here's a +1 then XD
2023-05-25 00:33:52 <psykose> even when it's not spam, half of it is flags for shit that is just wrong, or bug reports that are cut off and incomplete
2023-05-25 00:34:05 <psykose> i think i've had somewhere over 90 emails by now for stuff that is meaningless
2023-05-25 00:34:10 <skarnet> ew
2023-05-25 00:55:18 <minimal> Just noticed someone flagged Grub as being out-of-date despite there (still) being no newer release lol
2023-05-25 00:55:47 <psykose> yeah i'm sure the literal spam for version '1' is a legitimate flag
2023-05-25 00:58:32 <minimal> ah, don't think I ever looked at the "Flagged" tab on pkgs.alpinelinux.org, was only looking at the package itself which doesn't show exactly what was flagged
2023-05-25 05:53:15 <nmeum> psykose: re ae0e8a7ff5305ef84d66ad6f6fe4ed5e73bf28bb shouldn't this be `if $CHOST == $CBUILD` (i.e. if not cross-compiling)? 🤔
2023-05-25 05:53:27 <psykose> yeah, i fixed it after
2023-05-25 05:54:00 <nmeum> ah, I didn't rebase my branch
2023-05-25 05:54:02 <nmeum> nvm then
2023-05-25 15:13:58 <ovf> psykose: ok to privmsg you about random stuff?
2023-05-25 15:15:58 <jmondi> psykose: re-ping, sorry I missed your pong back
2023-05-25 15:16:51 <psykose> ovf: sure
2023-05-25 15:17:07 <psykose> jmondi: you can just say what you need instead of pinging me and waiting, this is not tcp
2023-05-25 15:18:24 <jmondi> psykose: SYN+ACK
2023-05-25 15:18:27 <jmondi> :p
2023-05-25 15:19:19 <jmondi> if you're here it's easier.. 
2023-05-25 15:19:24 <jmondi> I'm looking at this line here
2023-05-25 15:19:25 <jmondi> https://github.com/alpinelinux/aports/blob/master/community/libcamera/APKBUILD#L63
2023-05-25 15:20:03 <jmondi> I have forked the alpine package and built a custom repository in postmarket os.. whenever I build a custom version the package version gets appended with information about the build date
2023-05-25 15:20:26 <jmondi> the APKBUILD however forces the libcamera-ipa version to the revision specified in the APKBUILD
2023-05-25 15:20:41 <psykose> "the package version gets appended with information about the build date" where do you see this
2023-05-25 15:20:47 <psykose> i.e. show what you're talking about
2023-05-25 15:20:59 <psykose> also none of this 'needs me to be here' so don't do that again, thanks
2023-05-25 15:21:34 <jmondi> do what ? ping you ?
2023-05-25 15:21:37 <jmondi> libcamera-0.0.5_p20230524175902-r1.apk \
2023-05-25 15:21:58 <psykose> ping me and then say nothing until i respond wasting both of our time
2023-05-25 15:22:00 <psykose> sure, that seems fine so far
2023-05-25 15:22:15 <psykose> you made that the version yourself in pkgver= or pmos did
2023-05-25 15:22:24 <jmondi> pmos did
2023-05-25 15:22:47 <jmondi> when I install the package on the device however, the libcamera-ipa version is kept to 0.0.5-r1
2023-05-25 15:23:23 <jmondi> if I remove "$pkgver-r$pkgrel" from depends="$pkgname-ipa=$pkgver-r$pkgrel" it works again
2023-05-25 15:23:35 <psykose> sounds like you're either doing it wrong or pmos has a bug in how they update pkgver=
2023-05-25 15:23:39 <psykose> nothing to fix here, report it to them
2023-05-25 15:23:57 <jmondi> so I was wondering if "$pkgver-r$pkgrel" is needed in the 'depends' directive
2023-05-25 15:24:18 <psykose> the whole build has the same pkgver= so with 'pkgver=0.0.5_p20230524175902' you get 'libcamera-0.0.5_p20230524175902' and 'libcamera-ipa-0.0.5_p20230524175902' and everything works
2023-05-25 15:24:19 <psykose> yes, it is
2023-05-25 15:24:21 <psykose> this is not the bug
2023-05-25 15:25:06 <jmondi> I don't think it's a bug in pmbootstrap, it correctly identifies pkgver=0.0.5 and pkgrel=1 from the APKBUILD 
2023-05-25 15:25:31 <jmondi> but if you say "$pkgver-r$pkgrel" is needed, fine by me
2023-05-25 15:25:41 <psykose> if you get '0.0.5_p20230524175902' the the pkgver is not '0.0.5'
2023-05-25 15:25:54 <psykose> as i said, the template has nothing to do with this, either something you do is wrong or what pmos-something does is wrong
2023-05-25 15:26:16 <jmondi> the build timestamp is appended to the pacakge name, not specified in the APKBUILD
2023-05-25 15:26:20 <psykose> sigh
2023-05-25 15:26:31 <psykose> abuild does not append anything or change any pkgver
2023-05-25 15:26:39 <psykose> if you put pkgver=0.0.5, you get 0.0.5
2023-05-25 15:26:44 <psykose> not 0.0.5_somestuff
2023-05-25 15:26:48 <psykose> so, this is pmos doing something
2023-05-25 15:26:51 <jmondi> anyway, I will report to them if this is not an relevant to alpine
2023-05-25 15:27:37 <jmondi> psykose: FIN
2023-05-25 15:27:40 <jmondi> :p
2023-05-25 15:27:44 <psykose> i sadly don't know what that is, but hopefully they do
2023-05-25 15:27:59 <psykose> the specific thing with pkgver-rpkgrel just ties it to the same build
2023-05-25 15:28:09 <psykose> all packages and subpackages come out with the same version so the dependencies are fine
2023-05-25 15:28:32 <psykose> for it to not work means the pkgver somehow changed between the package and subpackages (so they broke something), or the way you install it is wrong and you somehow only have one of the packages
2023-05-25 15:28:57 <psykose> i.e. you built 0.0.5_p20230524175902 but copied only libcamera.apk and not libcamera-other-subpackages.apk so the others are missing
2023-05-25 15:29:14 <psykose> and by removing the =pkgver you hide this and install the 'new libcamera' with older subpackages that are from another source
2023-05-25 15:29:24 <psykose> my guess is the latter and not the former
2023-05-25 15:29:50 <jmondi> pmbootstrap has a 'sideload' (but I presume 'install' works the same) command which picks the most recent package version either from your local pacakge cache or from aport
2023-05-25 15:30:02 <jmondi> it picks libcamera and libcamera-tools from my local cache
2023-05-25 15:30:08 <psykose> it has to pick -ipa too
2023-05-25 15:30:40 <jmondi> but the APKBUILD directives instructs it to use libcamera-ipa-0.0.5-r1 instead of my locally build libcamera-ipa-0.0.5-something-r1
2023-05-25 15:30:49 <psykose> no
2023-05-25 15:31:09 <psykose> it instructs it to use pkgver-rpkgrel and the pkgver is changed and it's the same one
2023-05-25 15:31:16 <psykose> just assume you are wrong and forget that part
2023-05-25 15:32:39 <jmondi> ok, as said I was wondering if I should have sent a patch to remove "$pkgver-r$pkgrel" but if you say it's needed I'll revert back to pmos and leave alpine alone
2023-05-25 15:33:28 <psykose> the bug is not here, you are only masking it
2023-05-25 15:42:09 <psykose> if i had to guess sideload might not see the subpackages= inside the case block for some reason so it misses that -ipa even exists and doesn't install it
2023-05-25 15:42:16 <psykose> i didn't check the code though, they would know for sure
2023-05-25 15:44:24 <jmondi> it picks -ipa, but with the wrong version. I admit I haven't looked at the code there much either
2023-05-25 15:45:01 <psykose> i mean the sideload of the installation of apks
2023-05-25 15:45:10 <psykose> i.e. basically it shadows the repositories with the extra stuff
2023-05-25 15:45:34 <psykose> so you build 0.0.5_whatever, you get all of those, then sideload skips one, but you still have the normal repositories too
2023-05-25 15:46:05 <psykose> if you remove the constraint this then installs libcamera-0.0.5_bunchofstuff with libcamera-ipa-0.0.5 (not the one you built), because that one didn't get also installed from what you built
2023-05-25 15:46:08 <psykose> which is not what you want
2023-05-25 15:46:27 <psykose> i'm just beating a dead horse at this point though :p
2023-05-25 15:47:07 <psykose> just open an issue and they'll figure it out, promise
2023-05-25 15:47:49 <jmondi> yeah no worries, I'll revert to them
2023-05-25 15:49:13 <psykose> could you paste a log of your terminal of you doing all that if you still have it
2023-05-25 15:56:51 <jmondi> I don't have it anymore but I can reproduce it later
2023-05-25 19:27:01 <craftyguy> -exclude=#bish /buffer hide
2023-05-26 10:40:54 <Piraty> is there a policy when to / when not to add a -dbg subpackage to an APKBUILD?
2023-05-26 10:41:23 <Piraty> i.e. when to pester you (alpine upstream) with end-user debugging needs.
2023-05-26 11:51:49 <pj> just don't unless needed
2023-05-26 13:46:12 <ncopa> did something change recently in abuild/buildrepo/abuild-rootbld? I am no longer able to build this with qemu-binfmt: https://gitlab.alpinelinux.org/nmeum/alpine-visionfive/-/blob/main/starfive/linux-starfive/APKBUILD
2023-05-26 13:46:49 <ncopa> what happens is that _flavors is set in global scope, but when calling prepare(), _flavors is empty for some reason
2023-05-26 13:51:35 <nmeum> ncopa: yea there were recently some changes to rootbld
2023-05-26 13:53:40 <ncopa> i cannot see any changes in abuild git log
2023-05-26 13:55:33 <nmeum> so since a  recent abuild release the bwrap environment is cleared for example in the rootbld but this probably isn't related to your issue
2023-05-26 13:57:20 <Piraty> pj: please explain 'unless needed'. i needed it recently for community/calls and modified the local APKBUILD . does that count?
2023-05-26 13:57:42 <ncopa> Piraty: yes
2023-05-26 13:57:59 <ncopa> "i needed it ...." counts
2023-05-26 13:58:14 <Piraty> great ;)
2023-05-26 13:58:43 <Piraty> i guess since alpine doesn't have a split binary repo for dbg packages, this is applied with care?
2023-05-26 13:58:52 <Piraty> as it bloats the repo
2023-05-26 13:59:20 <ikke> Yes
2023-05-26 13:59:50 <ikke> And it's always possible to build it just locally 
2023-05-26 14:00:21 <Piraty> is there an abuild flag?
2023-05-26 14:00:44 <ncopa> you can add a -dbg subpackage or you can build it as: DEBUG=1 abuild ...
2023-05-26 14:01:02 <ncopa> both should enable debugging symbols
2023-05-26 14:02:17 <Piraty> thanks
2023-05-26 14:03:54 <quintasan>  wrong?
2023-05-26 14:03:54 <quintasan> Hi, I'm trying to do a static build of my Haskell web app which uses PostgreSQL, when I do so. I get a linker error `/usr/lib/libpq.a(fe-connect.o): in function `sslVerifyProtocolVersion': fe-connect.c:(.text+0xd10): undefined reference to `pg_strcasecmp'`. To determine if `pg_strcasecmp` is present I did `nm /usr/lib/libpq.a | grep pg_strcasecmp`  which returned 4 instances of `U pg_strcasecmp`. I'm wondering if this is a bug or I'm doing something
2023-05-26 14:24:19 <ncopa> its probably right. you need to find the lib that provides pg_strcasecmp
2023-05-26 14:24:42 <ncopa> usually the pkg-config tells you what to link in for static
2023-05-26 14:25:19 <ncopa> I wonder if I have bumped into a recent ash bug
2023-05-26 14:25:21 <ncopa> in busybox
2023-05-26 14:25:49 <ncopa> here is the debug ouput from within bubblewrap: https://tpaste.us/z5j9
2023-05-26 14:27:26 <quintasan> ncopa: I don't understand, pkg-config has a flag to tell you which symbol comes from which package?
2023-05-26 14:27:54 <ncopa> quintasan: no, but it usually tells you what libraries you need
2023-05-26 14:28:03 <ncopa> the linker flags
2023-05-26 14:28:27 <ncopa> i believe this is a busybox bug
2023-05-26 14:28:54 <ncopa> note the APKBUILD: https://tpaste.us/Xyw8 first it sets source=...
2023-05-26 14:29:09 <ncopa> then it: for _i in $source; do
2023-05-26 14:29:18 <ncopa> at that point source appears to be empty
2023-05-26 14:33:11 <ncopa> ok. this is *weird*
2023-05-26 14:47:00 <ncopa> will rootbld pull in locally built packages? eg if i build busybox locally
2023-05-26 14:48:28 <ncopa> nope
2023-05-26 14:48:30 <ncopa> it doesnt
2023-05-26 14:48:36 <ncopa> so I cannot test locally built busybox
2023-05-26 14:48:57 <ncopa> nmeum: I suspect that busybox is broken. but it only manifests itself in bubblewrap for some reason
2023-05-26 14:49:04 <ncopa> source="foo bar"
2023-05-26 14:49:23 <ncopa> for _i in $source; do something; done
2023-05-26 14:49:28 <ncopa> does not do something
2023-05-26 14:56:03 <ncopa> does rootbld work for anyone? with CBUILD=riscv64 abuild rootbld
2023-05-26 14:56:38 <nmeum> hm, I can't seem to be able to reproduce the for loop thing in bwrap
2023-05-26 14:57:00 <ncopa> can you build the alpine-visionfive kernel?
2023-05-26 14:57:06 <ncopa> with build-pkgs.sh?
2023-05-26 14:57:26 <nmeum> I am currently on a train, can't test it right now ':D
2023-05-26 14:57:46 <ncopa> its just weird
2023-05-26 14:59:53 <nmeum> rootbld with different CBUILD does seem to generally work for me
2023-05-26 15:00:02 <ncopa> same here
2023-05-26 15:00:28 <ncopa> i have no idea what goes wrong with linux-starfive
2023-05-26 15:07:33 <ncopa> im giving up
2023-05-26 15:07:36 <ncopa> its friday
2023-05-26 20:40:33 <Piraty> 
ACTION highfives ncopa for the correct attitude

2023-05-26 20:41:12 <Piraty> took me some years to let such issues sit there and rot in my brain. often enough they resolve over the weekend in my brain and on monday it's a 2minute fix
2023-05-26 21:04:40 <psykose> ncopa: no, it's not ash, all that works
2023-05-26 21:04:51 <psykose> the issue is CARCH is still x86_64 so the case match fails and won't update flavors
2023-05-26 21:05:09 <psykose> CBUILD=xyz seems to be broken, but i never figured out why
2023-05-26 21:07:39 <psykose> you can see in the full log CARCH/CBUILD_ARCH is riscv64 for bwrap and everything, but once you get into the apkbuild _carch=$CARCH is x86_64, etc
2023-05-26 21:11:28 <psykose> --setenv CARCH "$CARCH" fixes it
2023-05-26 21:15:00 <psykose> well, apk still ends up installing the x86_64 gcc somehow because of the other CBUILD= issue i talked about months ago
2023-05-26 21:15:04 <psykose> but that fixes carch i guess
2023-05-26 21:51:34 <jahway603> psykose: thanks for that git workflow link. Unfortunately, when going thru what you provided I'm not able to see the commits I need to fixup/squash, which I see in `git log` when I run `git rebase -i HEAD~3` to fixup/squash (as I've done in the past with squashing commits) -- what am I missing here?
2023-05-26 21:54:51 <psykose> i can't teach you git, sorry
2023-05-26 22:13:25 <bl4ckb0ne> jahway603: https://git-rebase.io/ might help you
2023-05-26 22:48:27 <jahway603_> psykose: I'm not asking you to teach my git, I know how to use git. I'm doing the same thing I would do on non-alpine projects and it's not showing me the commits. Oh well
2023-05-26 22:49:55 <psykose> run `git rebase -i HEAD~10` and take a screenshot :p
2023-05-26 22:50:12 <psykose> well, and also git status before it
2023-05-26 22:58:21 <psykose> most likely though you just can't read the output because you made a merge commit and everything is all over the place now
2023-05-26 22:59:31 <psykose> yes https://img.ayaya.dev/kGAQb3A630ML
2023-05-26 23:00:41 <psykose> (the sort of easy mistake to make if you don't know how to use git, i guess)
2023-05-26 23:00:57 <psykose> fixing it isn't obvious either
2023-05-27 12:29:10 <psykose> nmeum: should put bb update in 3.18 too
2023-05-27 13:53:29 <Newbyte> Do you still manually need to enable LTO for packages in Alpine?
2023-05-27 18:37:14 <dalias> is there a reason alpine's arm-generic kernel is omitting CONFIG_ARCH_MESON and various other SoC support?
2023-05-27 18:37:51 <dalias> actually it's the *only* one i see omitted
2023-05-27 18:39:13 <psykose> someone requested it but only for edge
2023-05-27 18:39:18 <psykose> no actual reason
2023-05-27 18:39:21 <psykose> i'll enable it i guess
2023-05-27 18:39:39 <ikke> These things mostly get enabled based on requests
2023-05-27 18:43:58 <dalias> it looks like it'll make alpine just work out of the box on librecomputer boards
2023-05-27 18:44:06 <dalias> which will be pretty cool
2023-05-27 18:44:33 <dalias> they're cheap (and more importantly, actually available for purchase) pi3 alternatives
2023-05-27 18:44:50 <dalias> and vendor seems to care about having stuff supported in mainline kernel
2023-05-27 18:46:48 <psykose> why is like eveyr single serial driver =y
2023-05-27 18:46:49 <psykose> :D
2023-05-27 18:46:53 <psykose> almost done tho
2023-05-27 18:47:02 <dalias> psykose, because you need them for earlycon
2023-05-27 18:47:07 <psykose> dalias: you can probably test it in like two hours from now if i don't fuck something up
2023-05-27 18:47:07 <psykose> ah
2023-05-27 18:47:12 <dalias> having them as a module will not help you debug failure to boot
2023-05-27 18:47:15 <dalias> :-)
2023-05-27 18:47:16 <psykose> should i =Y the SERIAL_MESON_* then?
2023-05-27 18:47:25 <dalias> yes i think so
2023-05-27 18:47:27 <psykose> okie
2023-05-27 18:47:30 <ikke> For edge it's y
2023-05-27 18:47:36 <dalias> otherwise no output if something is configured wrong
2023-05-27 18:57:38 <psykose> we were POWER8 baseline right
2023-05-27 19:00:00 <ikke> From what I can remember, yes
2023-05-27 19:11:12 <psykose> added
2023-05-27 19:11:34 <psykose> e3098250ccef522267758f44f08552913c39e861
2023-05-27 19:11:38 <psykose> check if these are.. enough options
2023-05-27 19:16:31 <psykose> should be available in under an hour
2023-05-27 20:09:51 <dalias> is there a place to get the modloop or a way to make it?
2023-05-27 20:11:01 <psykose> iirc that was some non-sys booting thing
2023-05-27 20:12:27 <shafire> hi
2023-05-27 20:13:04 <shafire> I'm trying to create a merge request, but gitlab times out
2023-05-27 20:13:23 <dalias> yeah, like booting the install system. i don't actually need to do that i guess
2023-05-27 20:13:54 <dalias> it booted fine but dropped to emergency recovery shell
2023-05-27 20:14:21 <dalias> so i think it's good
2023-05-27 20:14:36 <psykose> should keep goin till it fully works i guess
2023-05-27 20:14:46 <ikke> Hmm, not sure if related, but I see this in production.log: ActiveRecord::StatementInvalid (PG::UndefinedFile: ERROR:  could not load library "/usr/local/lib/postgresql/llvmjit.so": Error relocating /usr/local/lib/postgresql/llvmjit.so: LLVMBuildGEP: symbol not found
2023-05-27 20:14:50 <dalias> it has no video but i'm not sure if that's the lack of driver or that the modules aren't available
2023-05-27 20:15:27 <psykose> ikke: not sure where you see that (it's not related to our psql), but that means it was compiled with llvm16
2023-05-27 20:15:32 <psykose> it doesn't support that
2023-05-27 20:15:54 <psykose> GEP is the pre-opaque-pointer interface removed in 16 (GEP2 new, no release supports it)
2023-05-27 20:16:02 <psykose> the postgres docker image had that issue but i thought they fixed it
2023-05-27 20:16:11 <psykose> (since they just used llvm-dev which pulled 16 and then ran no tests)
2023-05-27 20:16:34 <psykose> or you just have to pull a new one
2023-05-27 20:16:38 <ikke> yeah, perhaps
2023-05-27 20:17:01 <ikke> It does download a newer image
2023-05-27 20:17:02 <psykose> was fixed with https://github.com/docker-library/postgres/pull/1077 for docker-lib
2023-05-27 20:17:05 <psykose> so that fixes it
2023-05-27 20:17:25 <psykose> dalias: sounds like modules
2023-05-27 20:19:20 <dalias> hmm i think there's maybe other stuff missing too
2023-05-27 20:19:36 <dalias> this is the diff from pmos config, grepped for MESON: http://ix.io/4wQR
2023-05-27 20:21:05 <dalias> maybe you have them as modules; if so the problem is just that i don't have any driver to access the sd card to load modloop :-p
2023-05-27 20:21:11 <dalias> (in the initramfs)
2023-05-27 20:24:41 <ikke> shafire: do you still have issues?
2023-05-27 20:28:16 <psykose> dalias: all of them are enabled (check /boot/config-lts)
2023-05-27 20:28:43 <psykose> as modules for the most part, but enabled
2023-05-27 20:28:55 <psykose> that part is just a usual 'gotta fix the system to get an initrd it loads etc'
2023-05-27 20:32:40 <dalias> ok
2023-05-27 20:33:08 <dalias> does that get handled automatically making install images?
2023-05-27 20:36:30 <minimal> dalias: it really comes down to which mkinitfs features and selected and which modules those feature files including in the generated initramfs
2023-05-27 20:36:39 <minimal> s/and /are /
2023-05-27 20:42:44 <psykose> i dunno what you're doing
2023-05-27 20:42:56 <psykose> for normal sys stuff any time the kernel is touched mkinitfs runs and that works
2023-05-27 20:43:16 <psykose> and i only ever use the 'normal sys stuff' because i'm basic :p
2023-05-27 20:43:53 <minimal> psykose: likewise
2023-05-27 20:44:41 <minimal> dalias: is your problem booting Alpine in the first place? or after you've then used setup-alpine to install with booting that installed system?
2023-05-27 20:46:03 <dalias> well i'm testing from a standpoint of wanting to boot first time and install
2023-05-27 20:46:18 <dalias> but i could skip that step and just pre-image stuff
2023-05-27 20:47:36 <psykose> yeah the issue is you have no kernel in a .iso
2023-05-27 20:47:39 <psykose> i guess no easy fix for that
2023-05-27 20:47:40 <dalias> i hacked up the initramfs i had from arm-generic install files to put all the modules from the new kernel on it, and it gets farther, but some things are still wrong
2023-05-27 20:48:30 <dalias> fb0 loads but there's no output on hdmi, and it's erroring out mounting rootfs which i'm not sure why it's trying to do
2023-05-27 20:49:05 <dalias> i thought the install initramfs didn't try to mount a root fs but instead did everything from the ramfs (tmpfs)
2023-05-27 20:50:43 <minimal> dalias: what cmdline options are you passing from the bootloader? those will impact on how the initramfs' init behaves
2023-05-27 20:53:12 <shafire> ikke: no issue anymore
2023-05-27 20:53:27 <ikke> shafire: ok
2023-05-27 20:55:21 <dalias> APPEND modules=loop,squashfs,sd-mod,usb-storage earlycon console=ttyAML0,115200
2023-05-27 20:55:24 <psykose> damn like 5 people in 1 day that open merge requests from master branch
2023-05-27 20:55:28 <psykose> what'd i do to deserve this
2023-05-27 20:55:30 <dalias> i just changed the default quiet to earlycon
2023-05-27 20:55:53 <ikke> psykose: maybe we can add a CI check for that :P
2023-05-27 20:56:01 <psykose> it technically doesn't break anything
2023-05-27 20:56:02 <psykose> i guess
2023-05-27 20:56:09 <ikke> It's anoying
2023-05-27 20:56:30 <psykose> yeah
2023-05-27 20:56:33 <psykose> especially to push to
2023-05-27 20:59:51 <psykose> i guess it was worse when i wasn't an admin
2023-05-27 21:00:17 <psykose> now i just toggle the protections real quick :-)
2023-05-27 21:02:00 <minimal> dalias: you're using a serial console? that's what "console=ttyAML0" appears to indicate (thought is was ttyAMA0 for Arm serial ports)
2023-05-27 21:03:49 <dalias> yeah. ttyAML0 is what it's called, and it's working
2023-05-27 21:04:57 <minimal> so why would you expect HDMI output if you're using a serial console?
2023-05-27 21:07:08 <minimal> you could try adding "debug_init" to the cmdline
2023-05-27 21:09:46 <minimal> as you haven't' specified "root=" then the initramfs' init should mount the boot device, create a tmpfs, and then setup a rootfs inside that tmpfs
2023-05-27 21:23:41 <dalias> yeah that's what i'd expect
2023-05-27 21:24:08 <dalias> re: hdmi, not console on it, but i'd expect it to come on if the driver is loaded
2023-05-27 21:24:12 <dalias> it did with the pmos kernel
2023-05-27 21:28:11 <minimal> dalias: I'd expect either simpledrm or meson drm to load as they should both be in the initramfs (assuming you updated it to include meson drm)
2023-05-27 21:29:56 <minimal> if the initramfs is missing either (or both) the mmc/host/meson-gx-mmc and mmc/host/meson-mx-sdio modules then that might explain why the boot device can't be mounted
2023-05-27 21:30:18 <dalias> ohh it's not rootfs it's failing to mount
2023-05-27 21:30:20 <dalias> it's boot media
2023-05-27 21:30:25 <dalias> because of some fs error
2023-05-27 21:30:34 <minimal> that's what I just said, the boot device
2023-05-27 21:30:58 <dalias> this sd card might be bad
2023-05-27 21:31:06 <dalias> i've got 10 shiny new comes coming tomorrow tho
2023-05-27 21:31:07 <minimal> as the initramfs' init needs access to the APK packages there to populate the tmpfs-based rootfs it is going to create
2023-05-27 21:35:33 <minimal> dalias: what fs type(s) does the SDcard use?
2023-05-27 21:36:17 <dalias> fat
2023-05-27 21:42:20 <minimal> dalias: and you checked your initramfs includes the fat module?
2023-05-27 21:42:42 <dalias> yes, the sd card is just shitting itself i think
2023-05-27 21:51:36 <dalias> reformatted and it works
2023-05-27 21:51:44 <dalias> brought up the hdmi too
2023-05-27 22:06:32 <dalias> so i think its good!
2023-05-27 22:07:20 <psykose> :)
2023-05-27 22:09:12 <dalias> i'll try real install tomorrow on new media
2023-05-27 22:09:30 <dalias> this one may be flaky and new is double size
2023-05-27 22:09:42 <dalias> 10pc 32GB for $26
2023-05-27 22:10:04 <psykose> sure
2023-05-27 22:10:29 <psykose> if it works i'll put it in 3.18 so the 3.18.1 iso will get it eventually for convenience
2023-05-27 22:10:39 <dalias> yay
2023-05-27 22:11:21 <dalias> if all goes well i'll be trying to promote alpine as base in this space
2023-05-27 22:11:55 <dalias> (3d printer controller host)
2023-05-27 22:12:26 <dalias> too much raspian & systemd hell
2023-05-27 22:12:39 <psykose> openrc ain't much better :p
2023-05-27 22:13:44 <dalias> except it does nothing to get in the way
2023-05-27 22:20:04 <Habbie> my octoprint is in docker and it is hell with the serial device
2023-05-27 22:20:56 <Habbie> psykose, hah, i'm always scared to point that out, some people get mad
2023-05-27 22:21:03 <Habbie> psykose, appreciate the clarity in here
2023-05-27 22:22:25 <dalias> openrc sucks but it sucks without tentacles wrapped around everything else
2023-05-27 22:23:12 <psykose> i spend ~100 hours a week fixing this shit
2023-05-27 22:23:16 <psykose> i get the right to complain about any of it
2023-05-27 22:23:17 <psykose> :p
2023-05-27 22:23:22 <dalias> :)
2023-05-27 22:23:28 <Habbie> i still like daemontools, which i used 20 years ago, but i gave up on writing run scripts for everything
2023-05-27 22:23:53 <psykose> daemontool style is my favorite
2023-05-27 22:23:59 <psykose> it's certainly opaque to most people though
2023-05-27 22:24:03 <Habbie> yes, indeed
2023-05-27 22:24:22 <Habbie> and honestly systemd is not that dissimilar, except it does way more
2023-05-27 22:24:45 <psykose> the basic supervision part of systemd isn't bad
2023-05-27 22:24:55 <Habbie> indeed, i'll admit i'm a fan in fact
2023-05-27 22:25:02 <Habbie> i also like systemd-networkd
2023-05-27 22:25:04 <Habbie> i pick and choose
2023-05-27 22:25:06 <psykose> the 'stuff gets supervised' is correct, and where openrc completely falls apart because there's no way anyone agrees on doing it
2023-05-27 22:25:21 <psykose> supervise-daemon sucks and everything else is a hack on top of openrc to do
2023-05-27 22:25:30 <Habbie> yep
2023-05-27 22:25:31 <psykose> the service model isn't that good either
2023-05-27 22:25:42 <Habbie> i don't hate openwrt's procd
2023-05-27 22:25:47 <Habbie> seems to be better in this regard
2023-05-27 22:25:56 <Habbie> (than sysv, openrc, ..)
2023-05-27 22:26:04 <psykose> it just is simple and not that hard to get to work so there's never a situation where you're experienced with it and wonder why stuff doesn't work
2023-05-27 22:26:20 <Habbie> that is true
2023-05-27 22:26:45 <Habbie> and i guess 'restart leaked a whole different environment into it' is mostly fixed these days even in the non-supervising managers (such as openrc)
2023-05-27 22:27:01 <psykose> yeah, except for TERM
2023-05-27 22:27:05 <Habbie> oh fun
2023-05-27 22:27:06 <psykose> that still leaks
2023-05-27 22:27:10 <psykose> the rest is fixed
2023-05-27 22:27:32 <Habbie> by 'environment' i do mean slightly more than the environ dict, but it was the most painful one
2023-05-27 22:28:09 <psykose> hehe
2023-05-27 22:28:29 <skarnet> I have more respect for people who try to write service managers since I've tried writing one
2023-05-27 22:28:36 <skarnet> that will still happen
2023-05-27 22:29:04 <skarnet> but previously I was like "why can nobody get it right?"
2023-05-27 22:29:21 <skarnet> now I'm like "it's a wonder that some half-broken service managers even exist"
2023-05-27 22:29:22 <Habbie> hehe
2023-05-27 23:29:39 <Piraty> psykose: thanks for merging the calls fix. am i expected to open a PR for the appropriate versioned branches ? (i see you already cherry-picked it)
2023-05-27 23:29:46 <psykose> no
2023-05-27 23:31:10 <psykose> for me anyway
2023-05-28 03:05:43 <Jesica> C04o08m12e09 13V03i07s06i11t02 10u04s08 @12 09i13r03c07.06t11w02i10s04t08e12d09n13e03t07.06o11r02g 10c04h08a12n09n13e03l07 06#t11w02i10s04t08e12d09
2023-05-28 08:07:03 <ikke> Ariadne: For ifupdown-ng, we are still using the stub executor for bridge, the comment mentions it's still being ported. Is that still the case? The executor script from ifupdown-ng seems pretty complete?
2023-05-29 15:40:28 <staceee> hey there o/ I got a problem with v4l2loopback-src and linux-lts : https://paste.sr.ht/~stacyharper/f8b5e4a797a552c6304bd072534acc8130b6139d
2023-05-29 15:40:40 <staceee> known? already fixed somehow?
2023-05-29 15:41:09 <ikke> haven't seen it reported (but I don't see everything ;))
2023-05-29 15:41:57 <staceee> I'm trying to just bump it
2023-05-29 15:45:03 <staceee> it doesn't help
2023-05-29 15:47:35 <staceee> mhh does it means the installed gcc version must match the kernel builted with gcc one for kernel-hooks to works?
2023-05-29 15:52:53 <psykose> that's pretty normal on gcc upgrades
2023-05-29 15:53:00 <psykose> not usually always kernel rebuilt with it
2023-05-29 15:53:41 <staceee> hey psykose o/ do you think this version missmatch is just unrelated?
2023-05-29 15:53:43 <psykose> but sure i'll push that for you
2023-05-29 15:53:48 <psykose> no it's the exact issue
2023-05-29 15:54:00 <staceee> so linux-lts rebuilt?
2023-05-29 15:55:00 <psykose> as the error message says, gcc was upgraded but the kernel was not, so it's saying the compiler you have (upgraded) is not the same as what the kernel was built with
2023-05-29 15:55:11 <psykose> i wish there was a way to just bypass that because it is noise 99.8% of the time
2023-05-29 15:55:19 <psykose> it does it whenever the version string won't match
2023-05-29 15:55:26 <sam_> if you find a way please tell me
2023-05-29 15:55:28 <sam_> i hate it so much
2023-05-29 15:55:39 <psykose> well you can just patch it from the /src tree makefile if you want
2023-05-29 15:55:45 <staceee> nice, just saw your commits. Thanks a lot :3 do you think of a way to not forget this next times?
2023-05-29 15:55:48 <psykose> but it's there for good reason, you want it on majors and.. some functionality
2023-05-29 15:56:06 <psykose> staceee: i don't forget it i just intentionally don't do it usually i guess
2023-05-29 15:56:11 <psykose> but i guess i'll start :-)
2023-05-29 15:57:05 <staceee> psykose: aha okay :D ~ how much time for this to land in repos?
2023-05-29 15:57:22 <ikke> ~15 minutes after the build completes
2023-05-29 15:57:27 <psykose> x86_64? 90 minutes
2023-05-29 15:58:05 <staceee> 
ACTION hug ikke and psykose

2023-05-29 15:58:11 <staceee> thanks again you guys
2023-05-29 15:58:11 <psykose> large hug
2023-05-29 15:58:29 <staceee> I got long arms
2023-05-29 15:59:10 <staceee> btw thanks old me to choosed to keep linux-edge "just in case"
2023-05-29 16:07:34 <psykose> :)
2023-05-29 18:31:48 <Sallly> C04o08m12e09 13V03i07s06i11t02 10u04s08 @12 09i13r03c07.06t11w02i10s04t08e12d09n13e03t07.06o11r02g 10c04h08a12n09n13e03l07 06#t11w02i10s04t08e12d09
2023-05-30 14:56:28 <bl4ckb0ne> whats going on with the CI? i got several stuck runners
2023-05-30 14:56:45 <bl4ckb0ne> arm mostly
2023-05-30 14:57:15 <ikke> bl4ckb0ne: arm's awol atm
2023-05-30 14:57:37 <bl4ckb0ne> ack
2023-05-30 14:57:43 <bl4ckb0ne> what's the issue?
2023-05-30 14:58:03 <ikke> network
2023-05-30 14:58:11 <minimal> mostly 'armless? ;-)
2023-05-30 14:58:18 <ikke> :D
2023-05-30 14:58:29 <ikke> reading that in a scottisch accent
2023-05-30 14:59:02 <minimal> in honour of Douglas Adams lol
2023-05-30 16:05:46 <bl4ckb0ne> ty psykose 
2023-05-30 16:06:05 <psykose> hope u found ur arms :(
2023-05-30 16:06:06 <psykose> :)
2023-05-30 16:21:57 <bl4ckb0ne> as we say in french
2023-05-30 16:22:04 <bl4ckb0ne> pas de bras, pas de chocolat
2023-05-30 16:22:46 <ikke> no arms, no chocolate
2023-05-30 16:23:45 <bl4ckb0ne> no chocolate for the ci
2023-05-30 16:27:58 <ikke> poor CI, life without chocolate
2023-05-30 16:31:45 <minimal> everything is better with chocolate
2023-05-30 16:34:52 <ikke> https://i.redd.it/t7r4r2643hv21.jpg
2023-05-30 16:38:28 <Habbie> hugops
2023-05-30 16:42:20 <skarnet> tech emotional support
2023-05-30 16:42:38 <minimal> stressops
2023-05-30 16:53:40 <bl4ckb0ne> so how much does it cost to have an ampere server next to my desk
2023-05-30 16:54:10 <psykose> https://www.ipi.wiki/products/com-hpc-ampere-altra?variant=43194527875234
2023-05-30 16:54:31 <psykose> and all the addons and an eatx case
2023-05-30 16:54:42 <pj> much
2023-05-30 16:54:43 <pj> at least 3 cookies
2023-05-30 16:54:44 <pj> (for me)
2023-05-30 16:55:18 <Habbie> 750W, so, one ampere server costs several amperes?
2023-05-30 16:55:48 <psykose> 750w?
2023-05-30 16:56:01 <Habbie> that's https://www.ipi.wiki/products/ampere-altra-developer-platform
2023-05-30 16:56:04 <psykose> funnily the spec is wrong
2023-05-30 16:56:11 <Habbie> which might just be because you might stick a GPU in
2023-05-30 16:56:23 <psykose> the q80-26 at load building stuff is like ~150 for the whole thing
2023-05-30 16:56:30 <Habbie> ugh, this site has the fake 'somebody in london just bought something' popups
2023-05-30 16:56:37 <bl4ckb0ne> might be doable
2023-05-30 16:56:47 <psykose> yeah gift me one
2023-05-30 16:56:49 <psykose> :3
2023-05-30 16:57:13 <psykose> the only downside is altra has a pcie erratum not in the kernel
2023-05-30 16:57:22 <psykose> so if you plan to use a gpu you'll probably have to build your own kernel
2023-05-30 16:57:25 <psykose> but that's not super hard
2023-05-30 16:57:36 <Habbie> ah
2023-05-30 16:58:08 <psykose> https://gitlab.freedesktop.org/mesa/mesa/-/issues/9100
2023-05-30 16:58:14 <psykose> https://github.com/chimera-linux/cports/commit/38692a68fb01b0bb0ff70f94124eec6b69b51eec
2023-05-30 17:08:33 <bl4ckb0ne> you have lots of core to build it anyway
2023-05-30 17:08:52 <Habbie> i used an ampere a few years ago, once i got through configure, building things did go quite fast
2023-05-31 02:24:21 <bl4ckb0ne> you're too fast psykose 
2023-05-31 02:24:43 <psykose> :-)
2023-05-31 06:06:15 <Newbyte> psykose: what was the issue you had with packaging glvnd? someone in pmOS is complaining about their ugly proprietary GPU drivers no longer working because they need classic Mesa driver support.
2023-05-31 06:06:28 <psykose> none
2023-05-31 06:06:34 <Newbyte> oh
2023-05-31 06:07:11 <Newbyte> psykose: why did you not package it then?
2023-05-31 06:07:22 <psykose> it's not a thing to package
2023-05-31 06:07:33 <psykose> it's changing how all the gl is done for mesa
2023-05-31 06:07:35 <Newbyte> how so? mesa needs to be built with support for it?
2023-05-31 06:07:48 <psykose> there is no benefit, only a bunch of downsides
2023-05-31 06:07:55 <Newbyte> thanks
2023-05-31 06:08:01 <psykose> except random people with 'proprietary gpu drivers' that is
2023-05-31 06:08:07 <psykose> but we don't do that here
2023-05-31 06:08:30 <Newbyte> we don't do it in pmOS either actually
2023-05-31 06:08:39 <Newbyte> but there is a pmOS downstream (lol) that does it
2023-05-31 06:08:46 <psykose> i guess libOpenGL is theoretically nice since unlike libGL it's not connected to libX11 but
2023-05-31 06:09:25 <Newbyte> but?..
2023-05-31 06:10:11 <psykose> but nothin, the rest is memes like https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/222
2023-05-31 06:11:04 <psykose> if it had more benefit than 'you can sideload proprietary libGL' it would be ok but it doesn't
2023-05-31 06:11:15 <psykose> (which makes sense because that's why it exists in the first place)
2023-05-31 06:11:31 <psykose> nvidia wrote it for their own drivers lol
2023-05-31 13:14:12 <gebbie[m]> I'm trying to make an APKBUILD for something with dependencies on edge, but I'm on stable so abuild -r doesn't work. Should I just switch to edge or is there some other way?
2023-05-31 13:57:23 <ikke> gebbie[m]: you should build that dependency on 3.18 if you want 3.18
2023-05-31 13:57:27 <ikke> otherwise switch to edge
2023-05-31 20:18:36 <Newbyte> Are the ARM builders back?
2023-05-31 20:19:22 <ikke> nope, not yet :(
2023-05-31 20:19:47 <Newbyte> Oh well!