2021-12-01 02:29:23 <ktprograms> psykose: Do you think eaglemode installing into /usr/lib/eaglemode would be ok for alpine?
2021-12-01 03:44:43 <dalias> ?
2021-12-01 04:00:15 <ktprograms> dalias: what do you mean?
2021-12-01 04:11:00 <dalias> what's the motivation for it being there?
2021-12-01 04:14:26 <ktprograms> dalias: Eaglemode installs a very messy directory structure, and by default it installs into /opt. The official (as in from eaglemode) deb release installs into /usr/lib/eaglemode, and I think that's really the only location that makes sense.
2021-12-01 05:28:28 <ikke> Hello71: oh yes, that's fixed
2021-12-01 07:43:38 <omni> are there known issues with 3.14 CI builds?
2021-12-01 08:00:32 <ikke> Nothing known to me 
2021-12-01 09:04:42 <omni> not even architectures not included in arch= succeed https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28002
2021-12-01 09:22:06 <ikke> Hmm, ok, related to the switch to doas
2021-12-01 10:06:49 <aparcar> is there a dedicated channel for the APK package manager?
2021-12-01 10:22:33 <clandmeter> aparcar: nope, this is the place
2021-12-01 10:23:50 <clandmeter> aparcar: how is the transition going? 
2021-12-01 10:41:30 <psykose> ktprograms: that sounds fine to me
2021-12-01 10:45:08 <xsteadfastx> can it be that there is a problem with the git patches to the mailinglist and the MR creation in gitlab?
2021-12-01 10:45:15 <xsteadfastx> my neovim version upgrade doesnt appear
2021-12-01 10:46:54 <mps> this integration of ML patches to github is one of the worst alpine decision
2021-12-01 10:47:05 <mps> s/github/gitlab/
2021-12-01 10:47:05 <alpine-meetbot> mps meant to say: this integration of ML patches to gitlab is one of the worst alpine decision
2021-12-01 10:47:38 <omni> what's the problem? it's merged
2021-12-01 10:47:49 <omni> !28007
2021-12-01 10:51:54 <xsteadfastx> omni: oh than i created a duplicate... mybad
2021-12-01 10:57:59 <omni> xsteadfastx: oh, thought that was yours, but you sent it to the ML and didn't see it appear in gitlab?
2021-12-01 13:10:38 <Newbyte> Do you have any idea why I might be hitting this error when trying to build OpenTDD with SDL2 instead of SDL 1.2: https://github.com/libsdl-org/SDL/blob/main/SDL2Config.cmake#L85
2021-12-01 13:12:41 <Newbyte> Here's the full log: http://0x0.st/-hcJ.txt
2021-12-01 13:14:34 <Ariadne> aparcar: there used to be, but we have not set a new one up since the freenode shitshow
2021-12-01 13:25:28 <psykose> Newbyte: no idea, but i had that same error on something else with sdl2, and based on the if/else stuff in there something in the cmake files is broken and can't find the library or something
2021-12-01 13:29:14 <psykose> wish i could say more but i can't understand anything in cmake scripts
2021-12-01 13:43:11 <ericonr> Newbyte: if you can, patch the build to use pkg-config
2021-12-01 13:43:30 <ericonr> SDL2's cmake mess is just blergh
2021-12-01 13:50:17 <psykose> Newbyte: https://termbin.com/mgc1 this should fix it for now, i think
2021-12-01 13:50:49 <Newbyte> I'll give it a shot, thanks!
2021-12-01 13:53:59 <Newbyte> It's building now 
2021-12-01 13:54:38 <psykose> i actually didn't know it was that easy to replace finding logic with pkg-config instead
2021-12-01 13:54:55 <psykose> there's some thing i've tried to build with cmake that fail because a lot of things are missing cmake files on alpine
2021-12-01 13:54:58 <psykose> some things*
2021-12-01 13:55:09 <orbea> why not just use autotools for SDL2? That build more or less works ime
2021-12-01 13:55:19 <psykose> this is a package that uses cmake
2021-12-01 13:55:23 <orbea> it has both
2021-12-01 13:55:49 <psykose> where in the openttd build system do you see autotools
2021-12-01 13:55:56 <orbea> https://github.com/libsdl-org/SDL/blob/main/configure.ac
2021-12-01 13:56:13 <orbea> i read SDL2, am I confused?...
2021-12-01 13:56:26 <psykose> a package that uses cmake and tries to find sdl2
2021-12-01 13:56:36 <ktprograms> Hi, how do I set the strip program for install to use when configuring with autoconf? /usr/bin/install -s is failing when I'm cross compiling because it can't strip binaries for different architectures.
2021-12-01 13:56:40 <orbea> oh....i'll just shut up :)
2021-12-01 14:00:11 <psykose> ktprograms: STRIP= env var i think
2021-12-01 14:03:49 <ericonr> ktprograms: the build system shouldn't be trying to strip things anyway
2021-12-01 14:04:33 <ktprograms> psykose: I tried STRIP=aarch64-linux-musl-strip when cross-compiling ncurses but it didn't seem to take notice of that var.
2021-12-01 14:04:48 <psykose> oh ncurses
2021-12-01 14:05:12 <ktprograms> ericonr: In that case then I guess it's ok to use --disable-stripping since I'm anyway only using it to compile GHC.
2021-12-01 14:05:17 <ktprograms> psykose: What about ncurses?
2021-12-01 14:07:15 <psykose> there should be an INSTALL_OPT_S inside the configure you could patch
2021-12-01 14:07:18 <psykose> but disable stripping is fine
2021-12-01 14:10:35 <ktprograms> psykose: Yes, I did find INSTALL_OPT_S, but like you said I decided disabling stripping would be fine in this case.
2021-12-01 15:27:42 <vkrishn> cannot open https://git.alpinelinux.org
2021-12-01 15:38:18 <ikke> Got a notification it was unreachable. I'll look at it in a bit. 
2021-12-01 16:11:38 <clandmeter> vkrishn: should be running again
2021-12-01 19:43:42 <maribu> This is strange. I have a MR that builds locally, but fails in the CI. Due to the huge amount of output and the log being cropped at the end (rather than at the beginning), I cannot see why the build failed. I added https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27996/diffs?commit_id=79a08b466ae9fcf98ece94e07d5cc6e63c03e87e to redirect stdout to /dev/null (and limit builds to x86_64 to reduce load), so that I at least get the
2021-12-01 19:43:43 <maribu> stderr of the actual error. The thing is that the build succeeded with that.
2021-12-01 19:46:06 <maribu> Could it be that the build is racy (e.g. make -j 1 would succeed)? I just reverted that commit and retriggered the build on x86_64, which failed again. I cannot come up with a more reasonable explanation.
2021-12-01 20:08:03 <Hello71> hovering over the ci entry in the dropdown list says "build-x86_64 - failed - (log size limit exceeded)"
2021-12-01 20:08:17 <Hello71> my conclusion is that the excessive size is causing the problem
2021-12-01 20:08:43 <ikke> afaik that should not cause CI to fail on its own
2021-12-01 20:09:34 <ikke> But I could be wrong
2021-12-01 20:10:11 <Hello71> 100 MB seems excessive
2021-12-01 20:11:10 <Hello71> https://www.google.com/search?q=gitlab+log+size+100+mb
2021-12-01 20:11:32 <Hello71> "The job log file size limit is 100 megabytes by default. Any job that exceeds this value is dropped."
2021-12-01 20:12:55 <Hello71> as i understand, there are (at least) two limits: by default, the runner will stop sending logs at 4 MB, and also, gitlab will stop receiving logs and kill the job at 100 MB
2021-12-01 20:13:25 <Hello71> normally the second limit is not reached because of the first one, but if you turn off the first one then the second one may happen
2021-12-01 20:13:41 <ikke> I think we have set the runner limit to 100M as well
2021-12-01 20:13:50 <Hello71> possibly it should be set to 99 MB
2021-12-01 20:14:23 <ikke> output_limit = 102400
2021-12-01 20:14:26 <Hello71> or 94 MiB (100 megabyte = 95.367432 mebibyte)
2021-12-01 20:15:24 <Hello71> possibly the gitlab limit is 100000000 byte and the runner is 102400000 or 104857600 byte?
2021-12-01 20:15:25 <ikke> output_limit Maximum build log size in kilobytes. Default is 4096 (4MB). 
2021-12-01 20:15:51 <ikke> Hello71: possibly
2021-12-01 20:18:21 <Hello71> hm, i think gitlab is actually 104857600 byte. i think probably runner needs to be 99 MB. i think probably the design is that the runner stops at 104857600 bytes, then prints "Log file size exceeded", which makes it more than 104857600 byte on gitlab end
2021-12-01 20:18:35 <Hello71> probably easier to increase gitlab to 101 MB instead
2021-12-01 20:25:31 <ikke> Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 101)
2021-12-01 22:11:48 <andypost[m]> clandmeter: are you ok to upgrade !27853
2021-12-01 22:13:57 <Hello71> has anyone ever tested valgrind on armhf?
2021-12-01 22:14:45 <Hello71> i downgraded all the way back to 3.4 (it doesn't exist in 3.3) and it doesn't work
2021-12-02 01:36:05 <craftyguy> Cogitri[m]: in pmOS, we'd like to install certain firefox extensions by default, so I've been looking at packaging them in aports. firefox no longer supports 'sideloading' extensions by default... arch linux builds it with flags that allow sideloading again and allows unsigned extensions that are in root-owned directories (e.g. /usr/lib). what are your thoughts on enabling that
2021-12-02 01:36:07 <craftyguy> in Alpine?
2021-12-02 01:37:37 <craftyguy> to be clear, the "install extensions by default" is not what I'm asking about, that bit would be handled in pmOS packaging/install stuff. I'm specifically asking about enabling sideloading extensions in FF from /usr/lib/firefox/extensions, which requires building it with options to turn it on
2021-12-02 01:39:31 <craftyguy> mozilla disabled it because I guess it was being abused (it's unclear "how"...) and in some cases users ended up with extensions they couldn't remove: https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions
2021-12-02 01:46:50 <dalias> i thinkt it's rather sketchy
2021-12-02 01:48:32 <craftyguy> yeah, I'm not sure how I feel about it. on one hand, if it's only sideloading unsigned extensions from root-owned directories... that seems OK? if some malware ended up there, then you've got bigger problems
2021-12-02 01:53:28 <dalias> i think it's the concept that the distro feels entitled to ship extensions that are on by default and can't be removed, that's inappropriate
2021-12-02 01:54:08 <dalias> if it were not a properly community governed distro with no tolerance for bs, but for example ubuntu and they were shipping some canonical affiliate extension...
2021-12-02 01:54:28 <dalias> that's why it's sketchy
2021-12-02 02:01:21 <craftyguy> I see. yeah we talked about this quite a bit, and would only be enabling 1 extension by default (ublock-origin, because it helps make FF usable on slower devices/inet connections)
2021-12-02 02:02:38 <craftyguy> and it could be removed... apk del <package that installed the extension>
2021-12-02 02:12:47 <Ariadne> the problem is
2021-12-02 02:12:52 <Ariadne> if we override mozilla on this
2021-12-02 02:12:59 <Ariadne> we lose official branding
2021-12-02 02:13:17 <Ariadne> and if we're going to do that
2021-12-02 02:13:22 <Ariadne> we may as well make other edits
2021-12-02 02:18:25 <craftyguy> oh I see, didn't realize that
2021-12-02 02:27:24 <ericonr> craftyguy: any chance they are using them to allow language packs to work? Firefox is really weird about language packs 
2021-12-02 02:28:11 <craftyguy> maybe, but I do see some extensions are packaged separately in their package repo
2021-12-02 03:08:08 <Hello71> also i think crappy sideloaded extensions mainly applies to windows and to a lesser extent mac
2021-12-02 03:08:25 <Hello71> but i think modern mozilla has no concept of nuance or details
2021-12-02 06:54:16 <boomanaiden154> boomanaiden154_: testing
2021-12-02 06:54:32 <boomanaiden154_> <08ParticleSwarmOptimization> boomanaiden154: testing
2021-12-02 06:57:15 <smcavoy> I am trying to create a patch that removes a binary file in a package but it produces the error "Not deleting file ... as content differs from patch", patch: https://pastebin.com/hQv2CEVd
2021-12-02 06:58:07 <smcavoy> wondering how I can get it to match only the filename and delete it regardless of content 
2021-12-02 06:59:30 <smcavoy> For packaging (its for ansible) the rest of the patch works and removes the usage of the file in question (hello) so I can just hack the APKBUILD file with rm but would be nice to have it all in the same patch and without any binary diff.. 
2021-12-02 07:00:28 <craftyguy> why don't you want to just 'rm hello' in the APKBUILD?
2021-12-02 07:01:21 <boomanaiden154> Should be pretty east to do in the check() function since this seems like a patch related to testing, but a custom prepare() function could also be used.
2021-12-02 07:03:57 <ktprograms> psykose: Eaglemode uses its docs inside the program itself (as one of the zoom areas), and it won't even launch if the index.html file for the docs isn't available. So do you think it should still split the docs (but keeping the index.html such that it can launch without the docs subpackage)?
2021-12-02 07:08:24 <smcavoy> craftyguy, boomanaiden154: indeed easy enough to do that in the package build but wondering if can be done in the patch.. 
2021-12-02 07:10:50 <boomanaiden154> I can't think of any easy way to do it in a patch file. As far as I know, removing a binary file will result in a binary patch and you can't just delete a file regardless of content using patch.
2021-12-02 07:11:50 <boomanaiden154> Could be wrong though.
2021-12-02 11:05:12 <Ariadne> boomanaiden154: please dont join bots to alpine irc channels
2021-12-02 13:34:47 <ktprograms> psykose: What do you think about !28060 ?
2021-12-02 14:02:27 <psykose> ktprograms: it should just not split anything then imo
2021-12-02 17:03:09 <nmeum> why is the mips64 builder for edge still listed on build.alpinelinux.org?
2021-12-02 17:04:33 <psykose> and 3.14
2021-12-02 17:04:42 <psykose> i think nobody formally took them down, they just vanish and reappear sometimes
2021-12-02 17:53:27 <clandmeter> nmeum: retained msgs
2021-12-02 17:53:43 <clandmeter> so it keeps listed until we restart mqtt 
2021-12-02 17:54:12 <clandmeter> not sure mips is completely offline now, but we removed the ssh key, it will never upload again.
2021-12-02 18:06:30 <skarnet> "we may be needlessly contributing to climate change but at least our repos aren't polluted anymore" :P
2021-12-02 19:05:58 <vkrishn> hi ncopa, still around  ?
2021-12-02 19:06:05 <vkrishn> I am looking at https://irclogs.alpinelinux.org/%23alpine-devel-2020-12.log
2021-12-02 19:06:18 <vkrishn> "for UEFI i currently bypass the bootloader completely, by installing the linux kernel as "bootloader" using efibootmgr"
2021-12-02 19:06:42 <vkrishn> was wondering if that kernel is available ?
2021-12-02 19:07:15 <vkrishn> or the process how to make it
2021-12-02 19:08:01 <vkrishn> I found this, http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/
2021-12-02 19:12:19 <vkrishn> and thinking if that kernel “insecure” type could be done in .iso releases only
2021-12-02 19:12:39 <vkrishn> might just boot a fraction-bit faster
2021-12-02 19:12:41 <vkrishn> ;)
2021-12-02 19:14:00 <Hello71> it is not special kernel, just manual configuration.
2021-12-02 19:14:14 <vkrishn> yes
2021-12-02 19:14:19 <Hello71> it cannot be used for removable media because you save all the parameters in nvram
2021-12-02 19:14:36 <Hello71> obviously if you move media to a different machine the nvram contents will be lost
2021-12-02 19:15:19 <vkrishn> params like ?
2021-12-02 19:15:31 <vkrishn> CONFIG_CMDLINE="root=..."
2021-12-02 19:15:44 <vkrishn> CONFIG_INITRAMFS_SOURCE="my_initrd.cpio"
2021-12-02 19:27:10 <psykose> that is just an efistub kernel (which is enabled in alpine), and then you add it to nvram with efibootmgr
2021-12-02 19:27:44 <psykose> the params are the ones for the nvram, i.e. in your motherboard booting stuff you have a list of things you can boot, if you add something with a target of something on a usb and change usbs it won't work anymore
2021-12-02 19:29:13 <vkrishn> ok, but might it work for .isos only ?
2021-12-02 19:29:17 <psykose> you can't do anything like this for .iso's to my knowledge, as the motherboard is the bootloader and has to get told what to boot, and it can't be told ahead of time 'use this gpt partition id to find an efi binary'
2021-12-02 19:29:33 <vkrishn> ok
2021-12-02 19:53:20 <minimal> Hello71: I assume if you rename the EFI Stub to be EFI/BOOT/BOOTX64.EFI (the fallback name) then it will boot without nvram
2021-12-02 19:53:32 <Hello71> yes but then you won't have any kernel parameters
2021-12-02 19:53:54 <Hello71> so it will not work with an unmodified kernel because it doesn't have any modules or init
2021-12-02 19:54:23 <Hello71> it could work if you compile with INITRAMFS_SOURCE or i think there are some utilities meant for secure boot to attach the initramfs to the kernel without recompiling
2021-12-02 19:55:04 <Hello71> but really a simple boot manager is good to have anyways, especially for distro media, because it provides an editor to add kernel parameters
2021-12-02 19:55:12 <Hello71> acpi=off or nomodeset or whatever
2021-12-02 19:55:40 <Hello71> it would be good to replace grub with gummiboot but not really a high priority
2021-12-02 19:55:42 <minimal> Hello71: gummiboot you mean?
2021-12-02 19:56:01 <Hello71> well there's other ones too but gummiboot is probably fine
2021-12-02 19:56:15 <minimal> ah, we mentioned almost simultaneously
2021-12-02 19:56:47 <minimal> haven't seen anything similar to gummiboot / systemd-boot (or whatever the current deriviative of gummiboot is called)
2021-12-02 19:57:27 <Hello71> afaik there's syslinux (has (bad) efi support now), grub, gummiboot, systemd-boot, and refind
2021-12-02 19:58:44 <Hello71> syslinux is basically unmaintained since ~2010, grub is super fat, and refind is still kinda fat and i think mainly intended for fixed installation, not removable
2021-12-02 19:59:11 <Hello71> haven't heard of any other reasonably-recent ones (i.e. lilo and refit are definitely out of the running)
2021-12-02 19:59:14 <minimal> Hello71: yes I've used Syslinux and Grub for UEFI booting, Syslinux is a mess for that. I was referring to "stub-like" bootloaders for UEFI - there's nothing I've seen except gumiboot/systemd-boot
2021-12-02 19:59:35 <Hello71> i think so too
2021-12-02 19:59:59 <Hello71> oh, there's also clover/opencore which is technically an option but i doubt anyone seriously uses that for linux
2021-12-02 20:00:05 <minimal> and gummiboot is basically a deadend since systemd "took it over" to create systemd-boot
2021-12-02 20:00:38 <AntoniAloyTorrens[m]> Hello everyone!
2021-12-02 20:00:38 <AntoniAloyTorrens[m]> Could someone take a look at !26081, !26107 and !26184? I got a warning from algitbot a few days ago. Thank you very much!
2021-12-02 20:02:24 <minimal> Hello71: u-boot does UEFI - have never tried it for that but again its not really a "stub" bootloader
2021-12-02 20:13:13 <minimal> Hello71: interestingly looks like secure boot support was added to u-boot in the past year
2021-12-02 20:51:45 <ncopa> vkrishn: the kernel is available. its linux-lts
2021-12-02 21:08:21 <senzilla> minimal: there's efilinux as well. It hasn't seen any updates for a few years, although it probably doesn't need it because very simple
2021-12-02 21:08:42 <senzilla> I think Fedora used efilinux at some point
2021-12-02 21:09:35 <minimal> senzilla: hmm, last commit 2014
2021-12-02 21:10:27 <minimal> I like the gummitboot "slimline" idea, especially for VMs/Cloud where you don't need/care about NVRAM, just intend to rely on fallback booting
2021-12-02 21:16:38 <senzilla> I have a feeling it'd be an interesting project to port OpenBSD's EFI boot loader
2021-12-02 21:35:42 <vkrishn> thanks
2021-12-02 21:59:10 <tomalok> figuring out gummiboot or similar is on the backlog for the UEFI alpine cloud images
2021-12-02 23:41:04 <Hello71> can someone take a look at !28037 and !28038? it's a critical security update
2021-12-03 01:35:46 <ktprograms> psykose: (re eaglemode) I think there isn't any point splitting the dev subpackage since it's only 240 KB, but the docs are an additional 3.24 MB, and some users might not need the docs.
2021-12-03 01:36:19 <psykose> it doesn't make sense to have -dev just because nothing would use this as a dependency as well
2021-12-03 01:37:08 <psykose> but yeah, that sounds fine
2021-12-03 01:37:14 <ktprograms> psykose: I also looked at the code, and the index.html is only required at the welcome screen but there is also already a link to the eaglemode home page, so what do you think about patching out the error with just removing the text that refers to the index.html?
2021-12-03 01:38:02 <psykose> that also sounds fine
2021-12-03 01:39:00 <psykose> you could probably bring this up with upstream if you want too, the package looks maintained to some fashion
2021-12-03 01:39:30 <psykose> also i noticed doing almost anything in it requires xterm/gimp etc, wonder if you can add more patches :)
2021-12-03 01:41:49 <ktprograms> psykose: Which parts require xterm/gimp?
2021-12-03 01:42:07 <psykose> i dunno, i clicked a random file in the viewer and it throws an error that it can't start xterm
2021-12-03 01:42:12 <psykose> ditto for an image file and gimp
2021-12-03 01:42:15 <psykose> i assume it would do more things
2021-12-03 01:42:31 <psykose> but i guess that's more of an application issue and less a packaging issue, so doesn't really matter
2021-12-03 01:42:48 <ktprograms> psykose: Oh I see. I don't think I'll work on that, though.
2021-12-03 02:18:13 <ktprograms> psykose: Does this patch look ok to you (no_need_doc_index_html.patch) in !28060 ?
2021-12-03 02:20:56 <psykose> looks good
2021-12-03 02:25:02 <ktprograms> psykose: Thanks for all your help! 😄
2021-12-03 02:25:18 <psykose> you did all the work :)
2021-12-03 02:27:56 <ktprograms> psykose: I can't seem to find anywhere to contact the eaglemode author with patches.
2021-12-03 02:28:18 <psykose> http://eaglemode.sourceforge.net/contact.html
2021-12-03 02:53:43 <ktprograms> psykose: Thanks
2021-12-03 03:42:04 <ktprograms> In the wiki, do we want to write instructions with doas or not? (For example do we want `doas apk add ...` or just `apk add ...`)
2021-12-03 06:13:51 <skarnet> depends on the context: most state modification operations assume appropriate privileges so I'd say "apk add".
2021-12-03 06:14:32 <skarnet> as a theoretical data point: please let's try *not* to normalize permission change operations in scripts
2021-12-03 06:14:45 <skarnet> permission changes should be *exceptional* and controlled
2021-12-03 06:15:10 <skarnet> and having them in scripts is the best way to ensure some of them will be overlooked
2021-12-03 06:15:55 <ktprograms> skarnet: What exactly do you mean by 'normalize permission change operations in scripts
2021-12-03 06:16:06 <ktprograms> ?
2021-12-03 06:17:03 <skarnet> if you write official distro documentation with "sudo apt install foobar" or "doas root apk install foobar" (I don't know doas' syntax, sorry if I'm getting it wrong)
2021-12-03 06:17:11 <skarnet> then people think those lines are normal
2021-12-03 06:17:29 <skarnet> even worse if you write a block of code that includes such lines
2021-12-03 06:17:46 <skarnet> then they think it's okay to automate them in scripts
2021-12-03 06:17:55 <skarnet> *it is not*
2021-12-03 06:19:05 <ktprograms> skarnet: I see what you mean.
2021-12-03 06:19:07 <skarnet> crossing privilege boundaries is the single most dangerous thing you can do on Unix and every time it happens needs to be very conscious with red blinking lights and blaring horns
2021-12-03 06:19:51 <ktprograms> skarnet: It would just be doas apk add foobar (by default doas switches to root, you can change with -u user)
2021-12-03 06:20:38 <skarnet> then the command is badly named, because I expect the first argument of "doas" to be the user I'm doing thing as :P
2021-12-03 06:20:56 <skarnet> things*
2021-12-03 06:23:27 <ktprograms> skarnet: Just wondering, how would you automate (for example) apk add in a script?
2021-12-03 06:23:45 <skarnet> I would require the script to start as root
2021-12-03 06:24:01 <skarnet> and drop privileges appropriately for the parts where root isn't needed
2021-12-03 06:24:20 <skarnet> losing privileges is always okay, gaining them is super dangerous
2021-12-03 06:24:27 <ktprograms> skarnet: How do you 'drop privileges'?
2021-12-03 06:24:39 <skarnet> su, for instance
2021-12-03 06:25:10 <skarnet> (or s6-setuidgid for the real connoisseurs ;))
2021-12-03 06:25:19 <ktprograms> skarnet: I see. Interesting. Haven't really heard of this method of scripting before, but it makes a lot of sense.
2021-12-03 06:30:26 <skarnet> it's the same as every other kind of Unix programming, really: when you run a web server that needs to bind to port 80, you don't start it as user www, and "oopsie I need to run sudo bind() just for this operation, I can be www everywhere else"
2021-12-03 06:30:46 <skarnet> you start the server as root, it binds, and then it drops to www when it doesn't need root anymore
2021-12-03 06:32:00 <skarnet> this model is typically annoying for build processes where you need root privileges towards the *end*: ./configure && make && sudo make install
2021-12-03 06:32:37 <skarnet> that's one of the reasons why initiatives like fakeroot and bubblewrap and what-have-you are a dime a dozen (and most of them are terrible)
2021-12-03 06:34:02 <skarnet> but yeah in theory you should do something like: # su normaluser -c "./configure && make" && make install
2021-12-03 06:35:01 <ktprograms> skarnet: Although I suppose the danger in this is that the program might be doing more then expected as root.
2021-12-03 06:35:33 <ktprograms> s/then/than
2021-12-03 06:35:33 <alpine-meetbot> ktprograms meant to say: skarnet: Although I suppose the danger in this is that the program might be doing more than expected as root.
2021-12-03 06:35:45 <skarnet> which is why it's important to drop privileges for the parts where they're not needed
2021-12-03 06:35:57 <ktprograms> skarnet: Yup, makes sense.
2021-12-03 07:27:30 <alandiwix> Do have openresty as luajit implementation? I'm wondering if  we should split off luajit2 from it instead of pulling nginx guts for something like neovim.
2021-12-03 08:38:14 <Ariadne> skarnet: well, programs which need to bind to 80 can have cap_net_bind_service attached to them now
2021-12-03 08:38:31 <Ariadne> so even root is not needed on linux
2021-12-03 08:38:39 <skarnet> yeah, capabilities make privileges more granular
2021-12-03 08:39:00 <skarnet> it's an improvement but doesn't change the principle
2021-12-03 08:48:50 <mercenary> The whole 'user programs can not bind to ports <1024' is historical ballast from the days a company had 3 unix boxes, and a team of 8 dedicated admins to keep them running
2021-12-03 09:04:19 <ktprograms> Should self-signed certs for nginx be specified in /etc/nginx/nginx.conf or in the per-site conf in /etc/nginx/http.d/ ?
2021-12-03 09:04:38 <ktprograms> (I'm asking for what to put in the nextcloud wiki page)
2021-12-03 09:05:02 <mps> ktprograms: where you need them specify them there
2021-12-03 09:05:23 <ktprograms> mps: What do you mean?
2021-12-03 09:06:32 <mps> you can put them globally or per SNI configs
2021-12-03 09:07:23 <mps> though it makes more sense to set certs per SNI (server name) configs
2021-12-03 09:08:38 <ktprograms> mps: I don't really understand much of web jargon, but from what I understand, you're saying put ssl_certificate in /etc/nginx/http.d/the.nextcloud.domain.conf, right?
2021-12-03 09:10:59 <mps> yes, (but again depends on your needs)
2021-12-03 09:12:22 <ktprograms> mps: So, for the wiki article, should it be /etc/nginx/nginx.conf or the conf in http.d?
2021-12-03 09:12:24 <mps> this way it is more flexible if you need to add more certs for more domains
2021-12-03 09:12:36 <MY-R> more like you can put it per "server {}" in nginx or global in "http {}"
2021-12-03 09:13:39 <MY-R> imho better do it with separated .conf files and per "server" and "http" leave for general stuff
2021-12-03 09:16:02 <ktprograms> Sorry, like I said I don't really understand enough about this to have a say in it, so if you want to look at https://wiki.alpinelinux.org/wiki/Nextcloud#How_To_Create_a_Self-Signed_SSL_Certificate and suggest a change, I don't mind putting it in, but if not I'll just leave it as it is since it should work, and if someone wants more granular control they can move it to the conf in http.d 
2021-12-03 09:16:09 <ktprograms> themselves.
2021-12-03 09:17:02 <ktprograms> Also, why is there /etc/ssl and /etc/ssl1.1 ?
2021-12-03 09:22:34 <ktprograms> It looks like /etc/ssl is only used for ca-certificates-bundle, so should the instructions on generating a self signed cert use /etc/ssl1.1/private instead of /etc/ssl/private?
2021-12-03 09:22:49 <MY-R> ktprograms: https://wiki.alpinelinux.org/wiki/Nextcloud#Nginx says to delete "server" sections and create separated file like: /etc/nginx/http.d/mysite.mydomain.com
2021-12-03 09:23:11 <MY-R> so better change "Contents of /etc/nginx/nginx.conf" to "Contents of /etc/nginx/http.d/mysite.mydomain.com"
2021-12-03 09:23:27 <ktprograms> MY-R: ok, thanks
2021-12-03 10:13:07 <omni> there's a new Xen release, 4.16, would it be a good time to pick up !14877 again?
2021-12-03 10:37:56 <Ariadne> omni: yes i think so
2021-12-04 03:32:06 <Nightrider_332211> Hello
2021-12-04 06:34:57 <ddevault> ncopa: now that 3.15 is done, can you please make a decision on the GOPROXY proposal
2021-12-04 07:11:24 <sosodank> hello there, lovely alpine people
2021-12-04 07:11:53 <sosodank> i've got a package in community, community/notcurses. as of 3.0.0 (the newest release), it uses libdeflate. the dependency is optional but strongly recommended
2021-12-04 07:12:01 <sosodank> alpine has libdeflate, but only in testing
2021-12-04 07:12:28 <sosodank> i was wondering what i could do, including possibly taking responsibility/ownership for libdeflate, to get it into community
2021-12-04 07:13:11 <sosodank> fwiw, i maintain libdeflate in fedora and macports, so it's not a thang to adopt it on alpine
2021-12-04 07:14:26 <sosodank> actually, while i'm here i might as well ask the same question about libgpm
2021-12-04 07:15:57 <boomanaiden154> {$test}
2021-12-04 07:18:14 <boomanaiden154> I believe you should be able to just move the package folder from testing to community without changing the maintainer.
2021-12-04 07:18:37 <boomanaiden154> That seems to be the typical practice for when other packages needed as dependencies have moved from testing to community.
2021-12-04 07:18:49 <sosodank> and then just submit the MR? great, i will do exactly that
2021-12-04 07:18:59 <sosodank> thanks much kindly boomanaiden154
2021-12-04 07:19:10 <boomanaiden154> Yes.
2021-12-04 07:19:32 <boomanaiden154> If anything needs to be changed, one of the maintainers there should be able to guide you.
2021-12-04 07:21:45 <sosodank> sweet, MR 28129 is up
2021-12-04 07:23:41 <boomanaiden154> !28129
2021-12-04 07:48:38 <mps> sosodank: if you want to take pkg you should first ask current maintainer, by mail and CCing to alpine-devel ML
2021-12-04 07:49:45 <mps> also, you should ask maintainer about move pkg
2021-12-04 07:50:53 <mps> boomanaiden154: not so simply, remember "my pkg is my castle" saying
2021-12-04 07:52:25 <boomanaiden154> The alpine gitlab bot should automatically assign the MR to the current maintainer for discussion.
2021-12-04 07:52:34 <ikke> I've assigned it
2021-12-04 07:52:51 <ikke> Oh, no, it was already
2021-12-04 07:53:02 <mps> boomanaiden154: not always, and not all maintainers follows gitlab
2021-12-04 07:53:52 <boomanaiden154> Well in that case it would be good to follow up creating the MR with contact on the ML.
2021-12-04 07:54:06 <boomanaiden154> Most of the maintainers seem to be on Gitlab at this point though.
2021-12-04 07:54:21 <ikke> hjaekel is active on gitlab
2021-12-04 07:55:30 <mps> gitlab will 'kill' good communication
2021-12-04 07:55:41 <boomanaiden154> How so?
2021-12-04 07:56:01 <mps> so!
2021-12-04 08:00:57 <boomanaiden154> I've personally found Gitlab to be pretty effective for communication relating to Alpine development.
2021-12-04 08:01:12 <mps> sosodank: also, you can create MR even without changing maintainer (taking it or whatever)
2021-12-04 08:01:32 <sosodank> @mps aye, i created the MR; i'll go ahead and send them a mail though
2021-12-04 08:01:50 <boomanaiden154> It's definitely of a different style than IRC, but that's why Alpine has both set up.
2021-12-04 08:02:00 <sosodank> kevin daudt marked it with needs-maintainer-feedback
2021-12-04 08:02:13 <mps> I practically maintain not small number of pkgs for few years but never asked to take them
2021-12-04 08:02:35 <sosodank> ahhh it already added hkaekel as the assignee
2021-12-04 08:02:59 <sosodank> and he's the maintainer, so i guess that's already handled? but i can still send the mail if you'd like for protocol's sake
2021-12-04 08:03:10 <sosodank> hjaekel, excuse me
2021-12-04 08:03:57 <mps> sosodank: you don't need to send mail to Holger if you don't ask to take maintainership of pkg
2021-12-04 08:04:40 <mps> if you just upgrade/fix/want to move it is ok to just create MR
2021-12-04 08:06:23 <mps> and yes, having gitlab and ML for 'development' (plus irc) is somewhat messy, imo
2021-12-04 08:08:31 <sosodank> good deal. congrats on 3.15, looks solid
2021-12-04 08:08:35 <sosodank> see y'all next time
2021-12-04 08:08:50 <boomanaiden154> mps: The combination of ML and gitlab is definitely somewhat messy, but I think gitlab and IRC compliment each other decently well.
2021-12-04 08:09:31 <boomanaiden154> Other than that if someone references IRC on gitab, unless you're active on IRC you don't get any of the context.
2021-12-04 08:10:54 <mps> boomanaiden154: yes, I agree about irc and gitlab combo, it best fit my workflow
2021-12-04 08:11:31 <mps> but I like to disagree to agree ;)
2021-12-04 11:03:00 <nmeum> maxice8: do you still recall your reasoning behind dcc5965f6f4fabd096b4df6cdd01e4f206341f64? I don't understand why util-linux-dev would require util-linux but maybe I am missing something obvious?
2021-12-04 11:06:23 <ikke> If only there would be some place where you could write down this kind of information :P
2021-12-04 11:50:48 <Newbyte> maxice8: why did you close the backport of gnome stuff to 3.15? (like !27811)
2021-12-04 11:51:41 <andypost[m]> Any idea why rust always overtime in CI on armhf? !28119 otherwise ready
2021-12-04 11:52:22 <ikke> andypost[m]: not sure why exactly, but it seems armhf virtualized is a lot slower
2021-12-04 11:52:50 <ikke> aarch64 vm in 32-bits mode
2021-12-04 12:02:53 <andypost[m]> Probably that's a cause, thanks
2021-12-04 12:04:38 <ikke> I've limited the armhf vm now to a single numa domain, just like we did for the other vms. Maybe that helps
2021-12-04 12:05:25 <maxice8> Newbyte: no will to get it merged
2021-12-04 12:17:30 <donoban> Anyone using dabuild? I'm getting this error: docker: Error response from daemon: unable to find user builder: no matching entries in passwd file.
2021-12-04 12:17:55 <donoban> I have no idea about what could be changed
2021-12-04 12:42:38 <ktprograms> Hi, I'm trying to understand the Gentoo OpenRC init script for the Gitea package: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-apps/gitea/files/gitea.initd-r3, but it looks nothing like Alpine initscripts. I'm trying to see why running 'service gitea restart' doesn't work (gitea doesn't seem to stop), but if I change the start-stop-daemon command to use --signal KILL instead of --signal 
2021-12-04 12:42:44 <ktprograms> INT, then it seems to stop fully.
2021-12-04 12:43:44 <Ariadne> perhaps reworking the initscript isn't such a bad idea
2021-12-04 12:46:25 <ktprograms> Ariadne: In what way?
2021-12-04 12:46:53 <Ariadne> porting the gentoo one
2021-12-04 12:48:10 <ktprograms> Ariadne: Wait, shouldn't it be sigterm instead of sigint?
2021-12-04 12:48:24 <Ariadne> i would assume so
2021-12-04 12:48:42 <ktprograms> Ariadne: So this part is wrong, right? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/gitea/gitea.initd#L20
2021-12-04 12:48:59 <Ariadne> actually, all of this is wrong.
2021-12-04 12:49:15 <Ariadne> if you look above, it is using supervise-daemon
2021-12-04 12:49:29 <Ariadne> so, it should not have stop() / reload() using start-stop-daemon
2021-12-04 12:49:53 <ktprograms> Ariadne: makes sense. So what's the way to do it with supervise-daemon?
2021-12-04 12:50:00 <Ariadne> stop() can go
2021-12-04 12:50:04 <Ariadne> no idea about reload
2021-12-04 12:50:10 <Ariadne> i dont think reload is really needed
2021-12-04 12:51:50 <ktprograms> Ariadne: reload might be useful since it can (probably) re-read the config file without restarting the whole service.
2021-12-04 12:54:10 <Ariadne> well, look for an initscript that uses reload and supervise-daemon i guess :p
2021-12-04 12:55:54 <ktprograms> Ariadne: In a way this initscript is a bit messed up since supervise-daemon shouldn't need a pidfile, right?
2021-12-04 12:56:05 <Ariadne> ?
2021-12-04 12:56:15 <Ariadne> the pidfile is for the supervisor
2021-12-04 12:56:54 <ktprograms> Ariadne: https://wiki.gentoo.org/wiki/OpenRC/supervise-daemon#Introduction says 'Pidfiles are not needed because the supervisor process remembers the pid.'
2021-12-04 12:57:26 <Ariadne> ktprograms: supervise-daemon has its own PID which must be recorded
2021-12-04 12:58:09 <ktprograms> Ariadne: I see. Thanks.
2021-12-04 12:59:12 <ktprograms> Ariadne: What is the default signal sent by openrc stop()?
2021-12-04 12:59:37 <Ariadne> when using supervise-daemon, it signals the supervisor to send SIGTERM
2021-12-04 13:01:06 <ktprograms> Ariadne: I wonder what d9b6414b1fdb622a937111ac4d2f6951c89bb2d4 was for?
2021-12-04 13:01:22 <Ariadne> how should i know
2021-12-04 13:03:15 <ktprograms> Ariadne: It seems to work (even with sending SIGINT) if I use ${supervisor} instead of start-stop-daemon.
2021-12-04 13:07:19 <skarnet> tfw supervision was made to avoid pid files but your supervisor needs its own pid file
2021-12-04 13:07:34 <mps> strange they use INT for terminate program
2021-12-04 13:11:35 <Ariadne> skarnet: aren't you working to fix this mess? :)
2021-12-04 13:13:11 <skarnet> yup
2021-12-04 13:14:51 <ktprograms> This is weird, when sending sigkill to the gitea process, it seems to just create a new one.
2021-12-04 13:18:38 <Ariadne> yes, because the supervisor
2021-12-04 13:18:41 <Ariadne> restarts it
2021-12-04 13:20:11 <ktprograms> Ariadne: Ah, right. Interestingly the Gentoo initscript works fine, and when restarting the gitea service, it actually takes a few seconds to stop gitea, whereas the Alpine initscript stops it instantly, but evidently doeesn't stop it properly.
2021-12-04 13:20:37 <Ariadne> so... use the gentoo one then?
2021-12-04 13:20:42 <Ariadne> i think i said that earlier :)
2021-12-04 13:22:14 <ktprograms> Ariadne: The reason why I didn't want to was because it's in a different format than other Alpine initscripts, and also it uses start-stop-daemon.
2021-12-04 13:22:29 <Ariadne> 
ACTION shrugs

2021-12-04 13:23:17 <ktprograms> Ariadne: I guess I'll use it and see what the maintainer thinks of it. Do I need to put Gentoo attribution, and if so, where?
2021-12-04 13:27:59 <Ariadne> just retain their copyright notices
2021-12-04 13:29:53 <ktprograms> Ariadne: Although, in the gitea APKBUILD it says license="MIT", so is it ok to use the gentoo initscript which is GPLv2?
2021-12-04 13:31:07 <ikke> There is no linking or anything
2021-12-04 13:31:30 <ikke> You can use the kernel which is GPLv2 to run MIT code
2021-12-04 13:40:48 <ktprograms> ikke: Right, thanks.
2021-12-04 22:49:37 <lonjil> Hello. I'm fairly new to Alpine and don't have a good grasp on the norms around packaging, so I'm wondering if anyone has any opinions on how to resolve !13262 ?
2021-12-04 22:50:19 <ikke> lonjil: is that the correct link?
2021-12-04 22:50:57 <mps> CODINGSTYLE.md and COMMITSTYLE.md, man APKBUILD
2021-12-04 22:50:59 <lonjil> Oh, no, it isn't, that was supposed to be an issue, oops: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13262
2021-12-04 22:51:13 <ikke> lonjil: ah, with a #
2021-12-04 22:51:24 <lonjil> ikke: ty, noted for the future 
2021-12-04 22:51:38 <ikke> ! is for merge requests, # for issues
2021-12-04 22:52:08 <mps> #13262
2021-12-04 23:01:09 <ikke> lonjil: I'm not familiar enough with pkg-config
2021-12-05 01:12:41 <asdflkj_sh> hi, I'm new to alpine and git send-email, may I have feedback on my first tiny patch email before I send it? https://termbin.com/jqyh
2021-12-05 01:16:44 <psykose> looks fine
2021-12-05 01:17:04 <psykose> you need to bump the pkgrel too
2021-12-05 01:17:22 <asdflkj_sh> ooh, thanks
2021-12-05 01:28:00 <asdflkj_sh> psykose: like so? https://termbin.com/i7o8
2021-12-05 01:28:13 <psykose> lgtm :)
2021-12-05 01:28:23 <Hello71> lonjil: .private should only be needed for static libraries, which should not be used in distro packages
2021-12-05 01:29:13 <Hello71> without seeing the build log it's hard to say, but it sounds like libqalculate is underlinking
2021-12-05 01:43:59 <psykose> Hello71: here's one of them https://gitlab.alpinelinux.org/lonjil/aports/-/jobs/508476
2021-12-05 01:44:28 <lonjil> Hello71: builds of a package that depends on libqalculate failed because some of libqalulate's headers #include gmp and mpfr headers. I originally added their respective dev packages as dev dependencies in the libqalculate package, but Michał Polański instead suggested that the packages should be in Requires.private so that the dependency could auto be automatically detected, which I deferred to.
2021-12-05 01:44:31 <psykose> if you see the patch you see the missing libs added to qalculate, i think they just forgot to put them into the .pc correctly
2021-12-05 02:10:42 <Hello71> eww, big stinky abi
2021-12-05 02:11:43 <Hello71> in this case probably the "right" solution is to add gmp-dev and mpfr-dev to libqalculate-dev deps, but either way is ok for alpine
2021-12-05 03:16:46 <asdflkj_sh> 
ACTION just realized his commit probably should have mentioned the patch only applied to 3.14 (the dep is already included on edge)

2021-12-05 03:37:48 <Hello71> 3.14 community is EOL
2021-12-05 03:45:53 <asdflkj_sh> then maybe my patch was useless :P
2021-12-05 03:47:33 <asdflkj_sh> I'm still on 3.14 bc I'm using postmarketOS, but now I realize it already released its last service pack before v21.12 (based on alpine 3.15)
2021-12-05 05:48:43 <Ariadne> aparcar: btw i am working on making the help database compression optional in apk
2021-12-05 05:51:52 <psykose> that would be nice
2021-12-05 05:52:31 <psykose> also, is there anything against changing the `doc` depends= to cmd:man instead of mandoc? this would allow docs to pull in all -doc subpackages while using man-db as well
2021-12-05 05:52:44 <psykose> docs* depends=
2021-12-05 06:09:27 <psykose> !28173 as an example
2021-12-05 10:43:17 <mps> why is dbus enabled in cups
2021-12-05 10:44:37 <mps> and does this patch is really important in cups 1ab1e11fd5811f388dce41df370ef84a34824af8
2021-12-05 11:07:14 <ikke> asdflkj_sh: right, that explains why the mr does not appear on gitlab, there is a merge conflict
2021-12-05 11:24:53 <Ariadne> mps: if there is -dbg package, yes
2021-12-05 11:36:07 <mps> Ariadne: yes, cups-dbg is built
2021-12-05 11:36:27 <Ariadne> well, then that patch is probably important
2021-12-05 11:36:42 <Ariadne> some build systems decide to strip the binaries themselves
2021-12-05 11:36:48 <Ariadne> thus defeating -dbg package
2021-12-05 11:37:33 <mps> ok, understand. have to refactor this patch then (later)
2021-12-05 11:37:58 <mps> !28176
2021-12-05 11:38:54 <mps> Ariadne: thanks
2021-12-05 11:57:04 <nmeum> I actually use a custom version of the cups packages which is built without dbus support :S
2021-12-05 11:57:35 <nmeum> theoratically, it should be an optional dependency and thus shouldn't be in $depends
2021-12-05 11:57:39 <nmeum> I think
2021-12-05 12:05:00 <mps> I agree
2021-12-05 18:52:15 <nmeum> omni: are you actually using sndio on alpine? :3
2021-12-05 18:57:57 <psykose> i heard it's pretty good
2021-12-05 19:11:45 <nmeum> I used it on openbsd back in the day but wasn't aware that it was viable on linux as well
2021-12-05 19:27:38 <tobtobxx> Noob question: How do you deal with building packages that have git submodules?
2021-12-05 19:28:12 <tobtobxx> Add the submodule tarball to the sources?
2021-12-05 19:28:21 <psykose> submodules get cloned by default
2021-12-05 19:28:44 <psykose> oh, in abuild
2021-12-05 19:28:55 <psykose> ask the project to make release tarballs with the correct dependencies
2021-12-05 19:29:29 <tobtobxx> : |
2021-12-05 19:29:32 <psykose> if things have submodules under like third_party/sub1 release tarballs generally contain the code there already so it can be built on unpack
2021-12-05 19:29:36 <psykose> not every project does this though
2021-12-05 19:29:52 <tobtobxx> Default GH tarballs don't.
2021-12-05 19:29:55 <psykose> yep
2021-12-05 19:30:03 <psykose> aside from that, you can see if the submodules are already in alpine
2021-12-05 19:30:07 <psykose> and the system ones work
2021-12-05 19:30:29 <psykose> usually the build system has -Dsystem-thing=ON as an option or whatever, and if the submodule is already something packaged you use that
2021-12-05 19:30:31 <tobtobxx> Aren't, but I could try to build the submodule as standalone library.
2021-12-05 19:30:48 <psykose> really depends what it is
2021-12-05 19:31:04 <ikke> If it makes sense to be a package on its own
2021-12-05 19:31:16 <psykose> if it's random tiny c++ library submodule like most c++ projects the best solution is just asking upstream, as packaging that makes almost no sense
2021-12-05 19:31:22 <ikke> There are packages that fetch eatch submodule separate
2021-12-05 19:31:48 <ikke> Not sure if tagging versions even makes sense. Submodules are checked out by commit
2021-12-05 19:32:30 <tobtobxx> Arch doesn't even have it in the AUR, separate lib prob. doesn't make sense.
2021-12-05 19:32:32 <psykose> an example is community/haxe
2021-12-05 19:32:43 <psykose> it vendors a tarball of the submodule commit via sources
2021-12-05 19:33:23 <psykose> and then you move them to the correct location yourself as if it was a git submodule checkout, and from there it should work as usual
2021-12-05 23:03:07 <omni> nmeum: I want to try to!
2021-12-06 00:00:26 <tobtobxx> What is the recommandation on parallel building? Should I set -j$(nproc) ? or -j1?
2021-12-06 00:01:00 <eris[m]> -j1 means it's not parallel ^^'
2021-12-06 00:01:25 <eris[m]> oh wait
2021-12-06 00:01:35 <eris[m]> most things will benefit from being built in parallel
2021-12-06 00:01:43 <tobtobxx> No, j1 means one job, ie. only do one thing at a time
2021-12-06 00:01:53 <eris[m]> yes
2021-12-06 00:02:20 <eris[m]> meaning the build isnt parallel because there is only one job :p
2021-12-06 00:03:22 <eris[m]> ive heard reccomendations for either nproc or nproc-1
2021-12-06 00:03:45 <tobtobxx> My machine just almost crashed with nproc. I'll go for nproc-1
2021-12-06 00:10:38 <MY-R> tobtobxx: keep in mind that huge projects like firefox need more than 2 GB of ram per job, so with -j4 and 8GB firefox build will die
2021-12-06 00:13:55 <Hello71> i don't think ram usage per job is related to number of jobs
2021-12-06 00:15:35 <Hello71> firefox has some big includes but nowhere near webkit-gtk jumbo-build (which is much smaller tarball)
2021-12-06 00:15:54 <Hello71> libreoffice also has big cpp TUs
2021-12-06 00:18:45 <MY-R> Hello71: since year I cant build firefox with more jobs because of ram, it will die almost at the end when linking
2021-12-06 00:26:59 <Jenkler> anyone here that knows about php av zendframework
2021-12-06 00:27:29 <Jenkler> what packages do i need? Does not get any db connection. PDO works 
2021-12-06 00:28:39 <Jenkler> 3.11 do have zendframework but is that needed?
2021-12-06 00:32:23 <boomanaiden154> MY-R: Have you tried setting the $(JOBS) variable in /etc/abuild.conf?
2021-12-06 00:34:05 <boomanaiden154> tobtobxx: You should probably use the jobs variable in /etc/abuild.conf or decrement that.
2021-12-06 00:34:42 <boomanaiden154> That way you can set the jobs variable in your abuild.conf when locally building and when it goes to CI/the builders, they can use all the cores since they have more RAM, or as specified in their abuild.conf.
2021-12-06 00:36:12 <MY-R> boomanaiden154: that what I was doing in that time, after I switched desktop to gentoo and lowered number of jobs for firefox done the job
2021-12-06 00:37:42 <psykose> tobtobxx: in an APKBUILD you don't set it as JOBS is set on the builders, for your local use you can set whatever you prefer
2021-12-06 00:38:23 <psykose> it's set in /etc/abuild.conf, you can change the number there
2021-12-06 00:38:24 <MY-R> and noticed that since firefox 91 it building faster with 3 jobs on old i5 it taking 1h 5m
2021-12-06 02:32:31 <ktprograms> Would there be any objection to having a wrapper for the gitea command that runs as the gitea user (like the nextcloud occ wrapper)?
2021-12-06 02:34:29 <ktprograms> And if so, where should the actual gitea binary be put? Because currently the gitea binary is in /usr/bin/gitea, but that's where the wrapper script should go as well?
2021-12-06 02:37:01 <psykose> what's wrong with running it with doas -u gitea or similar?
2021-12-06 02:38:04 <ktprograms> psykose: Would be shorter to type, and it's already been for nextcloud occ
2021-12-06 02:45:31 <psykose> does gitea not swap permissions itself? from what i can read it refuses to run as root and changes to RUN_USER from it's config file, and i would assume the commands do the same
2021-12-06 02:50:11 <psykose> ah, strange, it seems to not, even though the part of the code i was reading seemed to indicate it did
2021-12-06 02:52:53 <ktprograms> psykose: That's why I thought a wrapper would be useful. The command without the wrapper would be 'doas su -s /bin/sh gitea -c "gitea ..."' (because by default the gitea user has no password, so 'doas -u gitea gitea ...' doesn't work
2021-12-06 02:53:26 <psykose> doas -u gitea works by default, i did nothing but apk add gitea and it works
2021-12-06 02:53:45 <ktprograms> psykose: I get Operation not permitted?
2021-12-06 02:53:52 <psykose> you have to be root
2021-12-06 02:54:26 <ktprograms> psykose: Oops I forgot, it's just that I didn't permit gitea in doas.conf
2021-12-06 02:54:34 <psykose> ah right, and that
2021-12-06 02:54:55 <psykose> i also don't think you need -s /bin/sh with su, as the shell is set
2021-12-06 02:55:19 <ktprograms> psykose: But that's the problem. People then have to add more and more to their doas.conf, whereas a wrapper that uses su wouldn't need extra settings
2021-12-06 02:55:41 <ktprograms> psykose: Ah, I got used to it because the nextcloud user had /sbin/nologin as shell.
2021-12-06 02:55:52 <psykose> what commands do people run with gitea other than starting the service
2021-12-06 02:56:14 <psykose> i see dump/restore/migrate i suppose
2021-12-06 02:56:38 <ktprograms> psykose: Like list/manage users, stuff like that
2021-12-06 02:57:12 <psykose> and su gitea -c gitea is hardly.. i dunno, it seems like fairly normal system management
2021-12-06 02:57:20 <psykose> but the real solution is for gitea to just drop the permissions
2021-12-06 02:57:35 <psykose> lots of things read the user:group from a file and drop root once they don't need it
2021-12-06 02:58:14 <psykose> i don't actually understand why they have a specified user in the config file if they don't drop root (seemingly) or maybe that only after you have finished an install
2021-12-06 02:59:02 <ktprograms> psykose: Ok, then maybe I'll just add in the wiki a recommended alias of 'alias gitea=su gitea -c gitea' or something like that.
2021-12-06 02:59:07 <psykose> for occ it's a bit different as it's executing a php8 script, i think it's a bit more complicated there, but this is self-standing
2021-12-06 02:59:44 <psykose> ktprograms: do you know what happens if you have everything configured correctly with the gitea user, then run commands as root?
2021-12-06 02:59:53 <psykose> does it just overwrite all the /var/lib/xyz permissions
2021-12-06 02:59:57 <ktprograms> psykose: It doesn't allow it
2021-12-06 03:00:04 <psykose> ah, well that's fine
2021-12-06 03:00:28 <ktprograms> psykose: It says Expect user 'gitea' but current user is 'root'
2021-12-06 03:00:37 <psykose> documentation should be good then
2021-12-06 03:01:10 <ktprograms> psykose: Although that alias I sent a few msgs up doesn't seem to work.
2021-12-06 03:01:27 <psykose> i think you forgot the quotes in it
2021-12-06 03:01:33 <psykose> also it only works from root
2021-12-06 03:06:10 <ktprograms> psykose: Can an alias use $@?
2021-12-06 03:06:22 <ktprograms> And I was running doas giteaalias
2021-12-06 03:07:14 <psykose> you don't need $@
2021-12-06 03:07:51 <psykose> ah
2021-12-06 03:08:37 <psykose> you need a function in sh, i.e. giteaalias() { su gitea -c gitea $@ }
2021-12-06 03:09:05 <ktprograms> psykose: That's what I thought. So like add that line to /etc/profile.d/giteaalias.sh?
2021-12-06 03:09:12 <psykose> too used to fish alias that actually passes the args
2021-12-06 03:09:16 <psykose> i dunno, add it where you wish
2021-12-06 03:09:44 <ktprograms> psykose: Ok, thanks. I also use fish but docs should be for ash
2021-12-06 03:20:17 <psykose> and the command is `su gitea -c "gitea $@"` to be precise
2021-12-06 03:20:56 <ktprograms> psykose: Thanks
2021-12-06 05:55:15 <kevint> Can I get a review on !27863 ?
2021-12-06 06:08:22 <boomanaiden154> ikke, ncopa: What else needs to be done before the upgrade to python 3.10 can be complete? (!27026)
2021-12-06 06:08:47 <boomanaiden154> I have all the rebuild commits in a separate branch, but I'll probably need to regenerate them since I did that a couple days ago.
2021-12-06 06:32:53 <ktprograms> Hi, why it /var/lib/gitea 750 and not 754 (minimum extra permission to allow to 'cd' there at least)?
2021-12-06 06:55:59 <nmeum> eris[m]: there is a JOBS variable defined in /etc/abuild.conf so you can do -j${JOBS}, for make it will already be the default via MAKEFLAGS
2021-12-06 06:56:46 <nmeum> ok, should have read the entire backlog someone else already pointed that out (:
2021-12-06 08:08:55 <ncopa> boomanaiden154: I think we should mention in the commit message why the two patches was removed and why -fno-semantic-interposition was removed
2021-12-06 08:09:13 <ncopa> then we need to push the python update together with the rebuilds
2021-12-06 08:09:34 <ncopa> i guess there are 500? packages that needs rebuild?
2021-12-06 08:09:47 <ncopa> good morning btw :)
2021-12-06 08:10:26 <mps> \o
2021-12-06 08:13:15 <boomanaiden154> ncopa: Just change the commit message for the update or should I introduce separate commits for changing the flags and removing the patches?
2021-12-06 08:13:22 <boomanaiden154> 500 packages sounds about right.
2021-12-06 08:13:32 <boomanaiden154> Good morning to you as well.
2021-12-06 08:15:55 <ncopa> just change the commit message should be enough
2021-12-06 08:16:32 <ncopa> maybe add a reference to https://gitlab.alpinelinux.org/alpine/aports/-/issues/13227 in the commit message as well
2021-12-06 08:50:45 <ktprograms> Hi, no hurry, but I would appreciate if someone could look at !27943 and !27947 (dependencies needed for tldr-python-client, take note that the build process seems to need net), and also !28060 but that isn't important.
2021-12-06 09:26:02 <boomanaiden154> ncopa: Just added the necessary changes to the commit messages and I added the rebuild commits to the MR.
2021-12-06 09:58:48 <ncopa> boomanaiden154: were there many packages that needed patching?
2021-12-06 10:04:06 <boomanaiden154> I haven’t built most of them locally yet. I’ll see what CI says but the job will probably timeout. I’ll try and get through all the packages later today.
2021-12-06 10:23:58 <ncopa> i think the gnu-fallback-soabi.patch is not needed anymore, since we dropped bpo-43112.patch
2021-12-06 11:36:29 <ktprograms> Hi, has there been any discussion about having an AUR for alpine?
2021-12-06 11:36:53 <ikke> It has come up from time to time
2021-12-06 11:37:19 <ikke> ncopa: #13276
2021-12-06 11:37:44 <tobtobxx> Hey, I'm building a project and the cmake command completely locks up the system. Like GUI freezes, ACPI events (powerbutton) doesn't do anything, fans eventually spin down... Has anyone experienced this too?
2021-12-06 11:38:16 <tobtobxx> It's this apkbuild, if anyone has some spare 10m to try out: https://git.sr.ht/~tobtobxx/paps/tree/master/item/bespoke-synth/APKBUILD
2021-12-06 11:39:12 <ktprograms> ikke: I suppose it would actually be possible to just have another repo that's publicly writable for community-provided APKBUILDs? I think abuild+apk is capable of installing with any APKBUILD which doesn't need to be in aports?
2021-12-06 11:39:47 <ikke> ktprograms: yes, you are free to build your own repositories
2021-12-06 11:40:00 <ikke> and apk will happily accept any repository
2021-12-06 11:41:05 <ktprograms> ikke: But no semi-official/centralized user apkbuild repository exists?
2021-12-06 11:41:16 <ikke> not that I'm aware of
2021-12-06 11:41:27 <ikke> Not anything hosted by alpinelinux at least
2021-12-06 11:42:05 <ktprograms> ikke: I see. thanks
2021-12-06 13:12:35 <donoban> Hi, I'm trying to switch from dabuild to abuild rootbld but I don't found the privkey that dabuild is using, does anyone know where is it?
2021-12-06 13:27:12 <donoban> beh I will generate a newer one
2021-12-06 17:51:43 <Hello71> hm, how to fix alpine-gitlab-ci failing for 3.12-3.14?
2021-12-06 17:52:27 <Hello71> old doas doesn't support config directory
2021-12-06 18:14:43 <boomanaiden154> tobtobbxx: Yes. You probably don’t have a swap configured and ran out of RAM.
2021-12-06 18:42:31 <ikke> Hello71: ah, that's what's wrong 
2021-12-06 18:42:43 <Hello71> not sure what to do about it
2021-12-06 18:42:59 <Hello71> back to sudo? :p
2021-12-06 18:43:00 <ikke> I have tagged the image that still uses sudo 
2021-12-06 18:43:35 <ikke> So probably use that 
2021-12-06 18:44:08 <ikke> Or build an image per release rather than downgrading edge 
2021-12-06 18:44:10 <Hello71> i think there are a bunch of options, none of them very good: back to sudo, backport doas config dir, pin doas version (where?)
2021-12-06 18:44:45 <Hello71> image per release is probably the right option anyways
2021-12-06 18:45:19 <Hello71> another option is to pin doas in... build.sh?
2021-12-06 18:57:16 <tobtobxx> boomanaiden154: Yes that worked, thank you!
2021-12-06 18:59:48 <tobtobxx> But now I have another question (packaging is really just jumping from one error to the next): The package requires jack-dev, but on my host machine I already use pulseaudio-jack (which provides jack). Now abuild can't install the deps because they conflict. Does there already exist a solution that uses chroot or other ways of isolation out there or do I have to patch one together myself?
2021-12-06 19:01:33 <psykose> abuild rootbld can build anyway
2021-12-06 19:05:39 <tobtobxx> So abuild prepare && abuild rootbld && abuild package? Or am I missing a step?
2021-12-06 19:06:03 <tobtobxx> Ah, wait no, abuild prepare would fail...
2021-12-06 19:06:18 <tobtobxx> Only abuild rootbld && abuild package?
2021-12-06 19:09:18 <psykose> rootbld does everything, as if you ran -r
2021-12-06 19:09:43 <psykose> you end up with an apk in packages
2021-12-06 19:11:53 <omni> Hello71: I'd upgrade and patch doas, what could go wrong? (I might not be the right person to make this choice =)
2021-12-06 19:12:36 <tobtobxx> Is there any docs on rootbld? I'm missing .rootbld-repositories and I have no idea wether it should be a file, dir or whatever...
2021-12-06 19:35:21 <tobtobxx> Nvmd, I figured it out, it can be the same as /etc/apk/repositories.
2021-12-06 19:40:30 <z3ntu> Can some abuild maintainer look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/106 please?
2021-12-06 20:42:05 <ikke> Hello71: There is already a symlink from /etc/doas.conf to /etc/doas.d/doas.conf
2021-12-06 20:42:18 <Hello71> hm?
2021-12-06 20:42:21 <ikke> but I guess doas does not follow symlinks?
2021-12-06 20:42:31 <Hello71> the config is in wheel.conf
2021-12-06 20:42:40 <Hello71> i guess that's option 4, write doas.conf instead of wheel.conf
2021-12-06 20:42:44 <ikke> ah
2021-12-06 20:42:47 <ikke> yes
2021-12-06 20:43:02 <ikke> easiest fix for now at least
2021-12-06 20:43:42 <ikke> The default doas.conf does not contain anything anyway
2021-12-06 20:43:48 <ikke> (only comments)
2021-12-06 20:52:19 <MY-R> comments > nothing
2021-12-06 20:53:17 <ikke> Sure, but in this case it's insignificant
2021-12-06 20:56:19 <MY-R> ikke: oh, it doesnt have any examples... 
2021-12-06 20:56:37 <psykose> it does
2021-12-06 20:57:11 <ikke> It's in a docker image, and I mentioned it because I would overwrite the file, which would more probablematic if there would be some default config in there that needs to be kept
2021-12-06 20:57:21 <MY-R> I have got 3 lines of informations that it was moved on and nothing else so
2021-12-06 21:00:38 <mps> (nonsense from other distros) what is wrong with single /etc/doas.conf file
2021-12-06 21:02:27 <ikke> nothing, if that's all you need
2021-12-06 21:04:18 <mps> as everyone wants their 'how things works' also I would like to be only option on alpine ;)
2021-12-06 21:04:56 <psykose> the only correct way to use a computer is mine, and everyone else is always wrong
2021-12-06 21:05:17 <mps> psykose: I agree with you :)
2021-12-06 21:05:23 <MY-R> psykose: agree! :D
2021-12-06 21:05:25 <mps> i.e. 'mine'
2021-12-06 21:07:00 <mercenary> mps: indeed. And as a single doas file is a pain for any role-based automated setups, doas.d/ instead of fiddling with sections within a single file ;)
2021-12-06 21:08:41 <mps> mercenary: \o
2021-12-06 21:10:08 <MaximKarasev[m]> doas.d is incredibly useful if you are automating doas setup
2021-12-06 21:10:33 <MaximKarasev[m]> Like bundling configuration with package, like sxmo-utils does
2021-12-06 21:12:37 <mps> huh
2021-12-06 21:13:22 <mps> 
ACTION goes to drink wine instead of waste time on useles talk

2021-12-06 21:44:59 <ikke> Hello71: ok, it's now going through
2021-12-06 21:57:53 <Hello71> good :)
2021-12-06 22:00:16 <Hello71> did you miss !28037 or not merging on purpose?
2021-12-06 22:01:51 <ikke> Neither
2021-12-06 22:02:11 <ikke> Was waiting for the other to get merged
2021-12-06 22:03:19 <ikke> Seems like sonames _did_ change?
2021-12-06 22:03:32 <ikke> or not?
2021-12-06 22:06:22 <Hello71> "apparently the filename changes, but not the soname, so it's ok?"
2021-12-06 22:06:34 <Hello71> i was also confused about this
2021-12-06 22:07:52 <ikke> why does nss provide libssl3.so?
2021-12-06 22:10:50 <Hello71> i'm going to go with "dumb historical reasons"
2021-12-06 22:11:38 <ikke> Hmm, I cannot seem to find anything that actually depend on any of these libs, do you?
2021-12-06 22:15:53 <ikke> hmm, all on the unversioned soname
2021-12-06 22:17:22 <ikke> https://tpaste.us/6Wan
2021-12-06 22:22:50 <Hello71> yes, if you scanelf --soname it gives the unsuffixed version
2021-12-06 22:23:18 <Hello71> there is also a workaround to this effect in the APKBUILD
2021-12-06 22:24:30 <mps> Hello71: !28218 is good starting idea
2021-12-06 22:25:27 <mps> I thought and even started preliminary work in local branch for linux-edge on this
2021-12-06 22:27:40 <mps> but now is time when a lot of traditional holidays are coming and I will visit wider family, cousins and friends and we usually eat heavy food and drink good wine and brandy so I'm not sure when I will find time to finish and merge first changes
2021-12-06 22:28:23 <ikke> Hello71: So I guess it should be safe to upgrade
2021-12-06 22:28:27 <ikke> agreed?
2021-12-06 22:28:59 <mps> and I'm wasting some of my free time trying to get alpine to work well on apple m1
2021-12-06 22:29:36 <mps> so, I will be busy for next month and a half
2021-12-06 22:30:13 <mps> but, your proposal is a 'good thing' imo
2021-12-06 22:36:49 <tobtobxx> If abuild autodetects dependencies, is it good or bad practice to also add them to the APKBUILD?
2021-12-06 22:38:45 <mps> only those which are essentials and not auto 'detected'
2021-12-06 22:39:29 <mps> (or I have to switch back to debian)
2021-12-06 22:40:58 <psykose> things that get detected as like so:somelib.so don't have to be in depends=
2021-12-06 22:41:12 <tobtobxx> Ah, ok.
2021-12-06 22:59:56 <Hello71> ikke: yes, i think it is ok. probably ncopa or Ariadne will know for sure
2021-12-06 23:00:29 <Hello71> mps: what do you think of my idea of adding more subpackages and getting rid of linux-virt?
2021-12-06 23:04:49 <mps> Hello71: well, all this is worth further discussion imo
2021-12-06 23:06:35 <mps> we should do these things 'one by one' and always discuss with wider audience to hear opinions of other developers and users
2021-12-06 23:07:03 <Hello71> e.g. 99% of users will not use iio, or infiniband, or dvb, or dccp, etc
2021-12-06 23:07:04 <mps> though I think your proposal is god starting point
2021-12-06 23:08:20 <Hello71> good to hear your "tentative interest". i think i need to spend more time thinking about how the subdivision would work
2021-12-06 23:10:12 <mps> we all need to 'spend more time thinking' before we start blindly work, not only you and me :)
2021-12-06 23:10:37 <mps> this is good note
2021-12-06 23:11:09 <Hello71> then how will we be agile
2021-12-06 23:11:21 <mps> heh
2021-12-06 23:11:43 <mps> idk
2021-12-06 23:12:36 <mps> and I'm not sure we should be agile, we should be 'correct and consistent' first
2021-12-06 23:41:24 <omni> how about fragile?
2021-12-06 23:41:54 <jvoisin> the french version of agile?
2021-12-06 23:47:10 <omni> liberté, égalité, fragilité
2021-12-06 23:47:16 <jvoisin> krkr
2021-12-06 23:49:13 <omni> Hello71: where can I learn more about adding subpackages to linux-lts? for modules? (that's what has it apart the most space wise from linux-virt, right?)
2021-12-06 23:49:48 <omni> s,about,about the idea of,
2021-12-06 23:50:01 <psykose> you would just add a subpackage and move modules from the module dir to it
2021-12-06 23:50:03 <Hello71> probably on #alpine-devel in a week or something, idk
2021-12-06 23:50:25 <Hello71> (i assume you're really asking "is there a writeup", and the answer to that is no, it's currently mostly in my head)
2021-12-06 23:50:39 <Hello71> but yes, for modules
2021-12-06 23:50:48 <omni> ah, yeah, I'm just curious
2021-12-06 23:52:52 <omni> I use both linux-lts and linux-virt for virtual machines and would be happy if linux-lts could be smaller (I use it for drivers that I PCI passthrough)
2021-12-07 00:00:07 <Hello71> did you apk add linux-firmware-none
2021-12-07 00:09:59 <omni> yes
2021-12-07 00:13:25 <omni> I'm thinking a really sparse linux-virt might still be valid, though, for reduced attack surface
2021-12-07 00:16:10 <Hello71> maybe
2021-12-07 00:16:33 <Hello71> i think most of the "dangerous" things are modular anyways, e.g. strange network protocols, tty modes
2021-12-07 00:18:59 <omni> sure, and you can disable loading of additional modules post boot, right?
2021-12-07 00:19:25 <omni> still, not everything is a loadable module
2021-12-07 00:21:47 <omni> but wrt modules, currently /lib/modules/5.15.5.0-virt is 19M and /lib/modules/5.15.5.0-lts is 77M
2021-12-07 00:23:37 <Hello71> mmhmm
2021-12-07 00:23:53 <Hello71> System.map is a big waste of space on both virt and lts
2021-12-07 00:25:22 <psykose> ~4mb for nothing at all
2021-12-07 00:39:01 <omni> I understand that it would be really nice to not have to maintain both (not least by looking at a diff of config-lts.x86_64 and config-virt.x86_64)
2021-12-07 00:40:15 <omni> but how about having one as a base config and another, to concatenate with, with selections/deselections, because the last occurance of an option takes precedence, doesn't it?
2021-12-07 00:40:44 <psykose> there's already been talk for that, i.e. #12933
2021-12-07 00:40:48 <psykose> just takes a lot of effort to get there
2021-12-07 00:41:44 <psykose> changes will happen eventually, to all the kernel parts, it just needs a lot of time and discussion
2021-12-07 00:44:59 <omni> ah, yes
2021-12-07 00:47:30 <ktprograms> This is a wierd bug/edge case: I'm trying to use sddm, but it turns out that because I have 'exec fish' in my /etc/profile, the /usr/share/sddm/scripts/Xsession gets messed up (it sources /etc/profile but that ends up putting it in fish and therefore it can't start the Xsession)
2021-12-07 00:48:49 <ktprograms> Any idea what can be done? And does sddm _really_ need to source profile? Isn't everything in the session entries absolute paths?
2021-12-07 00:50:58 <psykose> why do you exec a shell in profile? that doesnt make any sense
2021-12-07 00:51:58 <psykose> and yes, it needs to source profile, to get the correct environment that then gets passed
2021-12-07 00:52:29 <omni> chsh
2021-12-07 00:52:36 <psykose> profile.d might not be very used in alpine, but on other distros you have heaps of stuff in there; it's a normal standard to source profile
2021-12-07 00:52:52 <psykose> if you want to set fish as a login shell add it to /etc/shells so chsh doesn't complain
2021-12-07 00:54:02 <ktprograms> psykose: I didn't set fish as the shell since I'm too lazy to adapt /etc/profile to fish-compatible so I just added 'exec fish' to the bottom of /etc/profile.
2021-12-07 00:54:56 <psykose> i don't see why you would ever touch /etc/profile at all
2021-12-07 00:56:58 <psykose> fish doesn't ever read /etc/profile regardless
2021-12-07 00:58:55 <minimal> Hello71: why would you want to get rid of linux-virt? Its aimed at VMs/Cloud where basically only virtio (and a limited additional set of devices) are used
2021-12-07 00:59:39 <Hello71> if you can delete all modules and get same size as current linux-virt, but without having to compile kernel twice, that is better
2021-12-07 01:00:12 <Hello71> and also you will be able to install some modules without whole linux-lts, e.g. some people want gpu drivers or ethernet drivers, but don't need wifi drivers
2021-12-07 01:00:15 <ktprograms> psykose: I mean I don't want to have to convert the contents of /etc/profile to make it fish compatible.
2021-12-07 01:00:26 <psykose> i am not sure why you would want to do that
2021-12-07 01:00:42 <minimal> I don't see how the twice compile can be avoided. However I do have local diffs for shrinking both the compiled-in and modules for linux-virt
2021-12-07 01:01:00 <Hello71> psykose: yes, i know of this issue. this is a separate but related issue, only addressing config files, not installed files
2021-12-07 01:01:20 <psykose> yep
2021-12-07 01:01:59 <minimal> basically if you want to emulate a "real" machine then use linux-lts, otherwise use linux-virt, so no need for Wifi or SATA/ATA etc in linux-virt
2021-12-07 01:05:16 <psykose> ktprograms: since sddm sources profile for you, your session should have it already- you don't need to do anything in /etc/profile at all, and the terminals you open with fish should have already sourced the profile as it came from sddm
2021-12-07 01:05:53 <psykose> if this isn't the case you can always do the meme of `exec sh -c ". /etc/profile; exec fish"` or similar, but there's never a need to exec a shell in /etc/profile
2021-12-07 01:07:47 <psykose> in fact execing in a place where things expect to return after sourcing it will break basically everything that tries to use it
2021-12-07 01:09:27 <minimal> Hello71: happy to supple my size/feature reductions for linux-virt, didn't want to just raise a MR as it needs to be discussed first (TSC?)
2021-12-07 01:09:52 <minimal> s/supple/supply/
2021-12-07 01:09:52 <alpine-meetbot> minimal meant to say: Hello71: happy to supply my size/feature reductions for linux-virt, didn't want to just raise a MR as it needs to be discussed first (TSC?)
2021-12-07 01:10:26 <psykose> supple size and features
2021-12-07 01:10:54 <minimal> psykose: supple == agile? :-)
2021-12-07 01:11:08 <psykose> for some reason that word sounds really lewd in my head
2021-12-07 01:32:25 <ktprograms> psykose: Turns out adding $PATH to fish properly was the only thing that needed to be done. I've removed the exec fish from /etc/profile and everything seems to be working.
2021-12-07 01:44:54 <skarnet> don't execute fish, release them into the water instead
2021-12-07 01:48:46 <psykose> +1
2021-12-07 02:47:25 <boomanaiden154> Does anyone know why the Alpine packages API isn't working?
2021-12-07 02:47:41 <boomanaiden154> https://api.alpinelinux.org/packages or with any other endpoint just returns a 404.
2021-12-07 05:37:26 <ikke> boomanaiden154: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10718
2021-12-07 05:39:14 <boomanaiden154> Thank you.
2021-12-07 07:56:08 <ncopa> boomanaiden154: i'm building python 3.10 + the rebuilds locally now
2021-12-07 08:06:42 <ncopa> py3-packaging has a circular dep
2021-12-07 08:06:59 <ncopa> and needs to be bootstrapped
2021-12-07 08:07:06 <ncopa> by disabling tests
2021-12-07 08:07:10 <ncopa> fun
2021-12-07 08:08:08 <boomanaiden154> Yep. Just ran across that issue like an hour ago.
2021-12-07 08:14:04 <boomanaiden154> It also looks like the builldirs command in the lua aports repository isn't fully detecting dependencies properly, so when I push to the python3.10 MR it builds in the wrong order.
2021-12-07 08:19:13 <ikke> It does not handle dependencies of subpackages 
2021-12-07 08:20:19 <artificalbeecolony> That would be why then.
2021-12-07 08:25:04 <boomanaiden154> How feasible would it be to add in subpackage support?
2021-12-07 08:27:01 <ikke> You need a semi static shell interpreter that only evaluates variables 
2021-12-07 08:27:02 <boomanaiden154> Probably pretty difficult considering some of the weird ways that subpackage dependencies get added in in some APKBUILDs.
2021-12-07 08:27:49 <boomanaiden154> Also not a particularly pressing issue as most large rebuilds don't go through MRs.
2021-12-07 08:28:19 <ikke> I'm slowly working on something written in go, but that cannot be used for the build infra atm 
2021-12-07 08:28:57 <boomanaiden154> A go based shell interpreter?
2021-12-07 08:29:02 <boomanaiden154> Or go infrastructure for Alpine CI?
2021-12-07 08:32:55 <boomanaiden154> ncopa: If you haven't gotten to it yet already, if you upgrade apache2-mod-wsgi to 4.9.0 (latest), it builds cleanly with python3.10.
2021-12-07 08:33:07 <boomanaiden154> I haven't gotten a whole lot farther than that.
2021-12-07 08:33:47 <ikke> There already exists an excellent shell parse library in go, which I'm using 
2021-12-07 08:37:27 <boomanaiden154> Interesting. Didn't realize Go had a library available like that.
2021-12-07 08:37:50 <ikke> mvdan.cc/sh
2021-12-07 08:39:32 <boomanaiden154> Is your project public at all yet?
2021-12-07 09:07:14 <ncopa> boomanaiden154: just bumped into it...
2021-12-07 10:52:22 <ncopa> boomanaiden154: did you bump into dtc error?
2021-12-07 11:08:10 <ncopa> also fail2ban fails
2021-12-07 11:16:01 <ikke> ncopa: Do you think !28190 can be merged?
2021-12-07 11:19:09 <ikke> (someone is asking about it)
2021-12-07 11:20:16 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13276#note_196932
2021-12-07 11:20:29 <ikke> right
2021-12-07 11:22:38 <ncopa> I've never been a big fan of the -DCMAKE_BUILD_TYPE=none in the first place
2021-12-07 11:23:48 <ikke> afaik, the reason was that otherwise our flags would just be ignored in many cases?
2021-12-07 11:27:37 <ncopa> yes I understand why. But there are otherways to set cflags: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html#variable:CMAKE_%3CLANG%3E_FLAGS
2021-12-07 11:57:50 <mps> I'm not sure why is _pkgverminor=2.3 from pkgver=2.3.17.1 named 'minor'. isn't this major part of version
2021-12-07 11:59:10 <ikke> it's both major and minor
2021-12-07 11:59:39 <ikke> But typically 2.3.1 is patch, 2.3 is minor and 2 is major
2021-12-07 12:00:57 <mps> yes, but why 2.3 is _pkgverminor
2021-12-07 12:01:20 <mps> shouldn't it be _pkgvermajor
2021-12-07 12:01:46 <mps> that is in !28226
2021-12-07 12:02:54 <mps> I hardcoded it to 2.3 and just when did this noticed 'strange' naming
2021-12-07 12:03:22 <mps> I think to rename it to _pkgvermajor
2021-12-07 12:04:18 <mps> ncopa: ^ (you are maintainer)
2021-12-07 12:04:49 <mps> this MR also 'must' be backported to 3.15
2021-12-07 12:16:27 <mps> ikke: for dovecot minor is third number usually
2021-12-07 12:38:18 <Thermi> Hello hello, I found an issue with the provides in the coreutils 9.0 and ucspi6-tcp 1.0.5 packages. In previous versions they did not conflict, but now they do, and it's evidently an issue with the metadata of the package, not with the contents of the package: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13266
2021-12-07 12:38:56 <Thermi> Please somebody take care of that. ucspi6-tcp is a dependency of tinyssh. So you can't install or use tinyssh with the recent versions of coreutils, which is part of release 3.15.
2021-12-07 12:45:56 <skarnet> people still use ucspi-tcp6?
2021-12-07 12:46:31 <skarnet> I kinda want to deprecate that horror and make tinyssh depend on s6-networking instead (which provides a tcpserver that works with ipv6 and is actually maintained)
2021-12-07 12:46:43 <Ariadne> Thermi: and, what do you want us to do?
2021-12-07 12:47:12 <Ariadne> Thermi: that packages do not conflict the command namespace is a policy decision that was made intentionally
2021-12-07 12:47:28 <Ariadne> in this case, the issue is that /usr/bin/who@ is a really badly named command
2021-12-07 12:48:34 <skarnet> tbh it should be authorized, the real issue is that ucspi-tcp6 is terrible code
2021-12-07 12:51:50 <Ariadne> if you have a list of known vulnerabilities, i would be happy to pursue deprecation of it
2021-12-07 12:54:45 <Thermi> The problem is that the commands do not in fact conflict. ucspi6-tcp packages who@ and whoami@, which allegedly conflict with who and whoami. But that's wrong.
2021-12-07 12:54:56 <Thermi> They coexist like any other program in $PATH
2021-12-07 13:01:01 <Ariadne> yes, but '@' is not a valid package name character
2021-12-07 13:02:58 <Hello71> alpine ucspi-tcp6 is also unmaintained
2021-12-07 13:05:11 <Hello71> #13161, none of the @ commands actually work
2021-12-07 13:06:37 <skarnet> Thermi: are you really interested in having ucspi-tcp6 work or just in tinyssh?
2021-12-07 13:07:05 <nero> tinyssh can also run via inetd or likewise
2021-12-07 13:07:51 <nero> which we have in busybox-extras
2021-12-07 13:08:13 <nero> tcpsvd is also in busybox, but its disabled on alpine
2021-12-07 13:10:00 <Thermi> skarnet, just tinyssh
2021-12-07 13:10:37 <skarnet> okay I'll take care of it then
2021-12-07 13:10:53 <skarnet> if people are okay with letting ucspi-tcp6 rot, which it should
2021-12-07 13:16:46 <nero> all the childish contempt...
2021-12-07 13:18:01 <skarnet> that could be it
2021-12-07 13:18:40 <skarnet> that could also be that I've used it for years and have constantly had problems with it, and studied the code and found it bad
2021-12-07 13:18:54 <skarnet> and incidentally written a replacement that actually works
2021-12-07 13:19:13 <skarnet> nobody will ever know which of those things is the real reason
2021-12-07 13:20:31 <nero> another thing thats potentially relevant, '@' in executable names break abuild?
2021-12-07 13:20:41 <nero> if its like that, it should get documented or fixed
2021-12-07 13:25:59 <dalias> lovely..
2021-12-07 13:32:15 <Hello71> regarding alpine auto-dependencies, i've always been annoyed at apk's overly strict interpretation of pc versions
2021-12-07 13:34:58 <skarnet> Thermi: has this package even ever worked? openrc w/ supervise-daemon auto-adds a -- between $command and $command_args, so the tcpserver options in $command_args make the invocation fail
2021-12-07 13:35:21 <skarnet> do people test their packages?
2021-12-07 13:38:23 <Hello71> it's possible that it worked at some point and then was broken by NMU
2021-12-07 13:39:38 <Ariadne> nero: yes, we should not autogenerate cmd: provides for commands we cannot actually represent correctly
2021-12-07 13:39:56 <Ariadne> though, i am curious as to what actually happens
2021-12-07 13:48:57 <Thermi> skarnet, I am not aware of if it ever worked. Only tinysshd was used
2021-12-07 13:49:21 <Ariadne> if it isnt known to work, perhaps we should just remove it
2021-12-07 13:49:29 <skarnet> I am talking about tinysshd
2021-12-07 13:49:32 <Thermi> No.
2021-12-07 13:49:36 <skarnet> the daemon could just never start
2021-12-07 13:49:42 <skarnet> I'm fixing the package atm
2021-12-07 13:49:46 <Thermi> tinysshd definitely worked, even if maybe the service needs some editing
2021-12-07 13:49:57 <skarnet> I have no idea how it ever managed to work
2021-12-07 13:50:00 <Ariadne> and if ucspi-tcp6 is known to be broken anyway, we should just drop it if it has security problems
2021-12-07 13:50:35 <skarnet> I need to go afk for a while but I'll push a mr for tinysshd asap, tomorrow at worst
2021-12-07 13:56:34 <Hello71> although it hasn't been upgraded in alpine for years, despite many upstream releases, i reckon there probably aren't any remotely exploitable vulnerabilities
2021-12-07 15:16:34 <aparcar> Hi all
2021-12-07 15:17:01 <aparcar> I'm looking for the script that generates Alpine images, specifically the rootfs
2021-12-07 15:17:55 <aparcar> I'm assuming APK is used to unpack a bunch of things into a folder, using chroot and more. Is it documented somewhere? Since I'm planing to integrate APK into OpenWrt we'd use it to generate the rootfs, too.
2021-12-07 15:24:27 <ncopa> its in our aports git repo, scripts/
2021-12-07 15:25:05 <ncopa> configure: error: "Python >= '3.4.0' development library is not installed"
2021-12-07 15:25:28 <ncopa> some configure scripts thinks that python 3.10 < 3.4
2021-12-07 15:30:24 <Hello71> possibly fixable by autoreconf?
2021-12-07 15:32:39 <ncopa> absolutetly fixable with autoconf and there are a patch from upstream already
2021-12-07 15:32:55 <ncopa> its just a bit work to do all the python 3.10 rebuilds
2021-12-07 15:33:01 <ncopa> finally done with main
2021-12-07 15:33:19 <ncopa> starting with community now
2021-12-07 15:35:26 <aparcar> ncopa: thank you
2021-12-07 15:36:54 <ncopa> aparcar: I have been thinking of adding a disk image with an efi/vfat + ext4 image, but have not had time to actually do it
2021-12-07 15:38:07 <ncopa> aparcar: where are the openwrt image scripts?
2021-12-07 16:06:27 <ncopa> boomanaiden154: looks like you didnt rebuild the py3-* packages in community?
2021-12-07 16:08:30 <boomanaiden154> Not at this point at least. I was only rebuilding packages that depended upon python3-dev for some reason. I rewrote my update script last night to account for all the necessary packages, but I only was working through main.
2021-12-07 16:58:54 <skarnet> !28229 for tinyssh
2021-12-07 17:08:20 <Ariadne> skarnet: merged
2021-12-07 17:15:00 <ncopa> boomanaiden154: my current work in progress: https://tpaste.us/9PZn
2021-12-07 17:15:05 <ncopa> will continue tomorrow
2021-12-07 17:16:36 <skarnet> Ariadne: awesome. Thermi: please test and confirm it works for you.
2021-12-07 17:36:08 <psykose> ah, finally edited, this whole time i manually added !tinysshd-openrc and wrote the init script myself to use s6-tcpserver
2021-12-07 17:36:09 <psykose> skarnet: thanks
2021-12-07 17:38:11 <skarnet> psykose: did you report it back then? instead of waiting for someone else to report it so that it's finally fixed :P
2021-12-07 17:38:33 <psykose> i in fact did not :(
2021-12-07 17:39:22 <psykose> but i did try to fix uscpi-tcp6 recently, by updating it and packaging the fehqlibs dependency.. and eventually i gave up because it's build system is nonsensical
2021-12-07 17:39:51 <psykose> i have no idea what drugs you need to do to write whatever that makefile is supposed to be
2021-12-07 17:41:02 <skarnet> you need to work in academia
2021-12-07 17:41:17 <skarnet> that's a hell of a drug
2021-12-07 17:42:33 <skarnet> I like Erwin, I really do, he's a very smart and kind man, but I wish he would stick to theoretical computer science and never attempt to code again
2021-12-07 17:55:01 <mps> any idea what that means https://tpaste.us/n5wx , i.e. how to try to fix it
2021-12-07 18:02:27 <skarnet> here's my idea: you could try to <optimized out>
2021-12-07 18:05:07 <psykose> lmfao
2021-12-07 18:05:21 <mps> hmm, lets see
2021-12-07 18:35:32 <Ariadne> if(!FtpConnect(host_name[host_number],&ftp_buf, host_use_SSL[host_number])){
2021-12-07 18:35:40 <Ariadne> clearly, the issue is that host_number is out of bounds
2021-12-07 18:36:47 <Ariadne> you can verify it `p host_number`
2021-12-07 18:37:06 <Ariadne> <optimized out> might also mean uninitialized
2021-12-07 18:37:21 <Ariadne> in fact, thats what it usually means
2021-12-07 18:38:08 <Ariadne> mps: ^
2021-12-07 18:43:12 <dalias> :-p
2021-12-07 18:43:24 <ikke> Ariadne: good to know
2021-12-07 18:43:26 <dalias> that sounds cursed
2021-12-07 18:43:31 <mps> Ariadne: thanks, what wonders me is that this started to happen without changes in source
2021-12-07 18:44:05 <psykose> maybe it was then caused by gcc 10->11 :p
2021-12-07 18:44:05 <Ariadne> well, we're looking at code that involves arrays with a host_number offset
2021-12-07 18:44:26 <Ariadne> this is, how do i put this charitably, not the correct way to store data in C
2021-12-07 18:44:28 <mps> psykose: that is what i also guessing
2021-12-07 18:45:01 <Ariadne> most likely, yes
2021-12-07 18:45:47 <Ariadne> (i mean, you *can* do it that way, but there are usually more robust and secure approaches)
2021-12-07 18:46:58 <mps> Ariadne: thanks, not sure should I try to fix this, thinking to move weex from testing to unmaintained, not sure it is used nowadays
2021-12-07 18:48:00 <Ariadne> i've never even heard of it until now, and i've been doing this for almost 20 years now
2021-12-07 18:48:47 <psykose> there's a ton of random obscure software used by 2 people, so no surprise there
2021-12-07 18:49:00 <psykose> i feel like almost everything off sourceforge falls into that category at this point
2021-12-07 18:49:23 <mps> psykose: it is maintained in debian now
2021-12-07 18:49:34 <mps> that is why tried upgrade
2021-12-07 20:12:08 <Thermi> Ariadne, can we backport the change to the tinysshd package to 3.15?
2021-12-07 20:12:10 <Thermi> It works well.
2021-12-07 20:12:28 <Ariadne> sure, you can open an MR doing this
2021-12-07 20:15:41 <Thermi> Tyvm, done. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28234
2021-12-07 20:15:46 <Thermi> !28234
2021-12-07 21:49:41 <midasi> psykose: I have a working up-to-date APKBUILD of ucspi-tcp6 and fehQlibs in case you are interested
2021-12-07 21:50:03 <psykose> i had already figured it out, but i didn't think it was worth the time to submit to aports
2021-12-07 21:50:09 <psykose> if you want, you can open an mr
2021-12-07 21:50:10 <midasi> same here..
2021-12-07 21:51:07 <psykose> the latest fehqlibs doesn't even build without patching the makefile lol, you need to fix one of the targets otherwise you need to call make twice so it's complete
2021-12-07 21:51:21 <psykose> on top of all the other random hacks
2021-12-07 21:56:10 <midasi> I don't recall such an issue with fehQlibs 19. It was actually quite straightforward compared to ucspi-tcp6
2021-12-07 22:08:10 <Ariadne> it seems like focusing on s6 makes more sense
2021-12-07 22:09:17 <Ariadne> s6 will be lower cost in the grand scheme of things as the replacement init is being built on it
2021-12-07 22:09:18 <MaximKarasev[m]> Will s6 really come to Alpine someday?
2021-12-07 22:09:23 <psykose> it's already better packaged than ucspi
2021-12-07 22:09:26 <Ariadne> it’s already there
2021-12-07 22:09:39 <Ariadne> unless you refer to the replacement of openrc
2021-12-07 22:09:48 <Ariadne> in which case probably next year
2021-12-07 22:17:42 <MaximKarasev[m]> <Ariadne> "s6 will be lower cost in the..." <- Is the new init based on s6-rc?
2021-12-07 22:17:48 <Ariadne> yes
2021-12-07 22:18:20 <MaximKarasev[m]> Sounds promising
2021-12-07 22:52:29 <Thermi> Ariadne, ty
2021-12-08 00:00:19 <omni> !28327
2021-12-08 00:00:53 <omni> oh no, no bot?
2021-12-08 00:01:44 <psykose> you typod the numbers
2021-12-08 00:01:47 <psykose> !28237
2021-12-08 00:01:54 <psykose> !28238
2021-12-08 00:02:01 <psykose> and yes, these should be merged sooner rather than later
2021-12-08 00:07:45 <psykose> maybe there is an exploit in gitlab so i can press the merge button for you :p
2021-12-08 00:13:50 <omni> ah ha, ty pod.
2021-12-08 01:03:37 <ktprograms> I'm trying to debug a segfault in SDL_PollEvent, and with gdb I've narrowed it to https://github.com/libsdl-org/SDL/blob/main/src/video/x11/SDL_x11xinput2.c#L385, and the problem is that in https://github.com/libsdl-org/SDL/blob/main/src/video/x11/SDL_x11xinput2.c#L377, the 'data' pointer seems uninitialized (in gdb it shows 'data = <optimized out>'). I checked and the rhs of the assignment is 
2021-12-08 01:03:43 <ktprograms> there properly, so why wouldn't it be getting initialized?
2021-12-08 01:04:24 <boomanaiden154> Have you turned off all optimization flags and enabled debug flags?
2021-12-08 01:04:36 <boomanaiden154> If you are using abuild, you need to make sure to edit the flags in /etc/abuild.conf.
2021-12-08 01:05:20 <ktprograms> boomanaiden154: Built with -DCMAKE_BUILD_TYPE=Debug and added -g to CFLAGS. (That's how I was able to pinpoint the source code line)
2021-12-08 01:05:31 <psykose> set -O0
2021-12-08 01:05:40 <psykose> though i think that cmake type does that
2021-12-08 01:05:57 <ktprograms> psykose: I'll try that
2021-12-08 01:06:06 <boomanaiden154> It didn't last time when I was debugging a sefault.
2021-12-08 01:06:15 <boomanaiden154> It kept picking up flags from /etc/abuild.conf.
2021-12-08 01:06:20 <psykose> in any case you can always do the classic of None and set -O0 -g3 yourself
2021-12-08 01:06:35 <boomanaiden154> Checking the build logs for compile flags is pretty helpful to see exactly what is going on.
2021-12-08 01:06:39 <psykose> yep
2021-12-08 01:06:50 <psykose> i also hate the cmake build type system
2021-12-08 01:07:15 <boomanaiden154> You need to set VERBOSE=1 in the cmake to get the compile commands typically.
2021-12-08 01:08:48 <ktprograms> If I use -DCMAKE_BUILD_TYPE=Debug and don't put $CFLAGS in -DCMAKE_C_FLAGS, will that completely ignore the CFLAGS from /etc/abuild.conf?
2021-12-08 01:09:02 <psykose> CMAKE_C_FLAGS is set from environment CFLAGS
2021-12-08 01:09:15 <psykose> but nothing you put in there matters, as they are prepended
2021-12-08 01:09:46 <psykose> if the debug build type does i.e. -Og -g, and you put -O0 -g3, the final compiler line is going to be "-O0 -g3 -Og -g" and so the first two didn't do anything at all
2021-12-08 01:09:48 <psykose> as an example
2021-12-08 01:09:50 <ktprograms> psykose: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/sdl2/APKBUILD#L82, so wouldn't removing the $CFLAGS not get it to use environment flags?
2021-12-08 01:10:06 <psykose> it's the same either way
2021-12-08 01:10:36 <ktprograms> psykose: Ah I see about prepended/ignored, so how do I set it? Build type of None and manually specify the flags?
2021-12-08 01:10:55 <boomanaiden154> The easiest way is to just removed the optimization flags from /etc/abuild.conf
2021-12-08 01:11:07 <ktprograms> Should I use -fomit-frame-pointer?
2021-12-08 01:11:07 <boomanaiden154> And then add them again once you're done debugging.
2021-12-08 01:11:21 <ktprograms> boomanaiden154: And what should I set build type to?
2021-12-08 01:11:21 <boomanaiden154> I would keep it.
2021-12-08 01:11:24 <psykose> if you have cflags set in your env the /etc/abuild flags are ignored
2021-12-08 01:11:44 <boomanaiden154> I'd say keep it set to debug.
2021-12-08 01:12:04 <ktprograms> boomanaiden154: But what about what psykose said that the flags will be prepended and ignored?
2021-12-08 01:12:20 <psykose> this depends on what the project does in the cmake files
2021-12-08 01:12:28 <boomanaiden154> They're getting prepended from the settings in /etc/abuild.conf
2021-12-08 01:12:38 <psykose> why dont you read it and see what gets run on the command line? this takes like 3 minutes to try out 3 things and see what the flags are
2021-12-08 01:12:48 <boomanaiden154> So if you remove them there, there should be nothing for CMake to pick up.
2021-12-08 01:12:52 <ktprograms> psykose: Ok will do.
2021-12-08 01:14:03 <psykose> e.g. on a random cmake project just now, the debug flags don't contain an -O at all, so just your own export of -O0 would make it -O0 and override the abuild.conf ones for this one
2021-12-08 01:14:12 <psykose> maybe this projects goes and sets -Ofast for debug flags, who knows
2021-12-08 01:14:42 <ktprograms> What is DFLAGS in abuild.conf?
2021-12-08 01:15:20 <psykose> D language flags
2021-12-08 01:15:29 <ktprograms> psykose: Ah I see
2021-12-08 01:15:34 <psykose> there is a language called d
2021-12-08 01:15:48 <psykose> gdc/ldc are two compilers for it, as mentioned in the comment
2021-12-08 01:16:32 <ktprograms> psykose: I see
2021-12-08 01:39:49 <ktprograms> I built with -O0 and -g3, and now the variables show properly, but the segfault is still there. What would be the next step in debugging?
2021-12-08 01:44:36 <ktprograms> Looking at the disassembly, the instruction just before the segfault is 'blr x5', where x5 is 0x0, so that makes sense that it's segfaulting, but how do I figure out where in the source is causing x5 to be 0 before using it to blr?
2021-12-08 01:48:17 <boomanaiden154> Set some breakpoints and step through it.
2021-12-08 01:48:29 <boomanaiden154> The backtrack is also fairly helpful most of the time.
2021-12-08 01:49:50 <ktprograms> boomanaiden154: How do I set breakpoints when it's pic?
2021-12-08 01:51:23 <ktprograms> boomanaiden154: What do you mean by backtrack? I used 'bt' and 'up', then 'layout asm' and I can see a 'blr x5', and doing 'info reg x5' shows '0x0'
2021-12-08 01:51:51 <boomanaiden154> backtrace. Sorry, autocorrect.
2021-12-08 01:51:59 <boomanaiden154> Just the bt command in gdb.
2021-12-08 01:52:38 <psykose> start the program in gdb, break X11_Xinput2UngrabTouch
2021-12-08 01:53:09 <ktprograms> boomanaiden154: Ah right.
2021-12-08 01:56:18 <ktprograms> boomanaiden154: I'm not sure if I didn't re-build the test program after using -O0 and -g3, because now there isn't any segfault.
2021-12-08 01:56:54 <boomanaiden154> Could be. I've had problems with the -Os flag that Alpine uses for optimization before.
2021-12-08 01:57:12 <boomanaiden154> Try reenabling the flags that you took off and see if the segfault returns.
2021-12-08 01:57:23 <ktprograms> boomanaiden154: That's what I'm doing now
2021-12-08 02:05:31 <ktprograms> boomanaiden154: Now it doesn't even segfault with sdl2-dev from the repos (i.e. no debug etc)
2021-12-08 02:05:42 <ktprograms> Could it be that there's a cache problem somewhere?
2021-12-08 02:06:16 <boomanaiden154> That's kind of weird. Could be. How are you building it? Local system or in a docker container?
2021-12-08 02:07:13 <ktprograms> boomanaiden154: Local
2021-12-08 02:07:32 <psykose> what were you running that segfaulted
2021-12-08 02:08:31 <ktprograms> psykose: At first I was just seeing what https://gitea.treehouse.systems/slyecho/xormod was for the fun of it, but when it segfaulted I just made a bare minimum test program of SDL_Init, create a window, and do a SDL_PollEvent
2021-12-08 02:08:47 <psykose> ah
2021-12-08 02:08:48 <psykose> hm
2021-12-08 02:10:42 <boomanaiden154> ktprograms: Building in a docker container should remove any cache/weird versioning problems on your local system.
2021-12-08 02:10:57 <ktprograms> boomanaiden154: Ok, doing that now.
2021-12-08 02:27:18 <ktprograms> boomanaiden154: How do you use a dockerfile just for building an executable (not to build an image)? Or is that the wrong way of doing it?
2021-12-08 02:28:15 <boomanaiden154> I wouldn't use a dockerfile. Just run an alpine image with docker run --rm -it <alpine image>
2021-12-08 02:28:52 <psykose> and -v somefolder:/stuff
2021-12-08 02:29:08 <boomanaiden154> Yes. Unless you want to reclone aports or your files into the container.
2021-12-08 02:29:11 <ktprograms> bleb: Ah I see. I was already doing that and the built version doesn't segfault. I wonder if the problem was my version of sdl2-dev was too old (if I didn't apk upgrade for a while)
2021-12-08 02:29:24 <boomanaiden154> alpinelinux/build-base I think works fairly well.
2021-12-08 02:29:37 <boomanaiden154> I use my own image for building aports though (boomanaiden154/apkbuild-testing).
2021-12-08 02:30:00 <ktprograms> boomanaiden154: I just did the alpine:latest image and ran 'apk add alpine-sdk ...'
2021-12-08 02:31:39 <boomanaiden154> You have to do a little more setup than that.
2021-12-08 02:31:45 <boomanaiden154> There's a page on the Alpine Wiki.
2021-12-08 02:31:54 <ktprograms> boomanaiden154: In what way? I'm not building in aports btw
2021-12-08 02:32:01 <boomanaiden154> I also believe if you use alpine:latest, you get v3.15, which isn't want you want if you're working on aports.
2021-12-08 02:32:21 <ktprograms> boomanaiden154: I'm not building with abuild
2021-12-08 02:32:39 <boomanaiden154> Oh. Then you should probably be fine.
2021-12-08 02:35:36 <ktprograms> boomanaiden154: Funny, it doesn't segfault even built from 3.13, so it's not a version problem. Wonder what could have caused it then
2021-12-08 04:59:10 <boomanaiden154> ncopa: Got a decent amount of packages in community rebuilt against python 3.10. Current patchset I'm working against for community: https://tpaste.us/qPr9
2021-12-08 05:00:54 <boomanaiden154> I started patching virtualenv so that other packages building against python3.10 utilizing it would work (since it still hasn't switched over to sysconfig for a couple things in the latest release), namely py3-setuptools_scm, but I haven't been able to get it built yet.
2021-12-08 07:43:39 <mps> 29663ea959e7a24f2910bd0f7e67a107a9e360c3
2021-12-08 07:43:56 <mps> what is upgraded? fcolista smcavoy ?
2021-12-08 07:46:58 <fcolista> mps not sure what is your question
2021-12-08 07:47:07 <fcolista> jenkins moved from stable to lts
2021-12-08 07:47:39 <fcolista> isn't the commit obiouvs?
2021-12-08 07:48:44 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12954
2021-12-08 07:48:48 <mps> fcolista: shouldn't it be 'repo/pkgname: upgrade to 2.319.1 LTS'
2021-12-08 07:49:38 <fcolista> oh ok. You are referring to the commit description
2021-12-08 07:49:40 <fcolista> you are right
2021-12-08 07:49:40 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28239
2021-12-08 07:50:02 <fcolista> I was mislead by the title of the MR
2021-12-08 07:50:24 <mps> ok, mistakes happens
2021-12-08 07:50:38 <fcolista> not sure why this happened
2021-12-08 07:50:38 <fcolista>  Sean @smcavoy changed title from upgrade to 2.319.1 LTS to community/jenkins: upgrade to 2.319.1 LTS 6 hours ago
2021-12-08 07:50:59 <fcolista> well, yes
2021-12-08 07:51:31 <fcolista> th for noticing mps 
2021-12-08 07:51:34 <fcolista> *thx
2021-12-08 07:52:08 <clandmeter> fcolista: it happend 2x ;-)
2021-12-08 07:52:22 <mps> heh, I have good eyes to notice mistakes/errors but bad eyes to fix things :)
2021-12-08 07:52:24 <psykose> foiled by gitlab ui again
2021-12-08 07:52:42 <fcolista> yeah.. I learned that the title of MR is not the actual commit
2021-12-08 07:52:44 <clandmeter> the previous one is also not following commit standards 
2021-12-08 07:52:50 <fcolista> true
2021-12-08 07:52:58 <ikke> 
ACTION should add CI for commit messages..

2021-12-08 07:53:04 <ikke> But it's hard to get that right
2021-12-08 07:53:14 <clandmeter> cant you lint it somehow?
2021-12-08 07:53:24 <nero> have it match a regex :P
2021-12-08 07:53:28 <psykose> repo/anything: * should at least be fine
2021-12-08 07:53:36 <ikke> nero: the hard part is not the easy cases
2021-12-08 07:54:05 <psykose> are there any commits that don't reference a single repo in aports with anything after the slash then a colon?
2021-12-08 07:54:11 <mps> ikke: should add something in gitlab on every page with big red letters: read the COMMITSTYLE.md and CODINGSTYLE.md
2021-12-08 07:54:49 <clandmeter> there are some commits that affect multiple aports
2021-12-08 07:55:11 <omni> right?
2021-12-08 07:55:17 <ncopa> morning
2021-12-08 07:55:21 <clandmeter> but false negatives for such wont be that bad
2021-12-08 07:55:39 <omni> moin
2021-12-08 07:56:08 <ncopa> boomanaiden154: can you please push your changes to the MR?
2021-12-08 07:56:41 <ncopa> and maybe rebase it
2021-12-08 07:56:53 <mps> I don't expect that such linter will be perfect, enough is if it works in most cases
2021-12-08 07:58:32 <mps> also, I understand that web ui (gitlab) tends to 'hide' raw things, and shows 'user friendliness'
2021-12-08 07:58:55 <mps> (modern times)
2021-12-08 08:00:15 <psykose> (bottom text)
2021-12-08 08:36:42 <boomanaiden154> ncopa: Just added the changes to the MR and rebased against master.
2021-12-08 09:11:29 <mps> holly shit, what we have !28249 (sorry couldn't resist)
2021-12-08 09:12:16 <psykose> what's strange about it
2021-12-08 09:12:35 <Ariadne> for one, going straight into community without going into testing first
2021-12-08 09:12:40 <Ariadne> but i think mps was just making a joke
2021-12-08 09:13:50 <mps> Ariadne: no, I'm surprised that 'we' (free source) endorse such software which is used on people control and spying
2021-12-08 09:14:15 <psykose> ?
2021-12-08 09:14:34 <mps> psykose: read the pkgdesc
2021-12-08 09:14:42 <psykose> i already have
2021-12-08 09:15:06 <PureTryOut> Ariadne: ah yeah for the community thing, I've been using the package locally for ages and didn't realize I hadn't put it in aports yet. So as a maintainer of it I consider it tested and working
2021-12-08 09:15:18 <Ariadne> mps: i don't see the problem?  the software displays certificate data which is issued by authorities
2021-12-08 09:15:25 <mps> medical data (and other personal data) should be peoples secrets
2021-12-08 09:15:49 <PureTryOut> mps: it's fine to have different opinions about it but the application is fully FOSS and nothing illegal. Lots of people including myself have no issue with this type of application existing
2021-12-08 09:15:57 <Ariadne> yes, but if a person wishes to disclose that data, in order to go to a nightclub, which is the primary use case of these apps, it seems reasonable
2021-12-08 09:16:26 <psykose> are you saying medical data should be such a secret you cannot even disclose it yourself at your own discretion
2021-12-08 09:16:50 <PureTryOut> also note that it supports Dutch vaccination codes and if using it for those only, you are not disclosing any medical data at all
2021-12-08 09:17:00 <Ariadne> given that there is a respiratory pandemic on, and being in tight spaces with people jumping around like idiots is high risk for contracting a respiratory infection, it seems reasonable
2021-12-08 09:17:42 <mps> psykose: yes, medical data should be peoples secrets and only could be disclosed to 'medical personal' and even then only if people do this voluntary
2021-12-08 09:17:43 <Ariadne> i mean, if you don't want to disclose your vaccination data, then don't use the app, it is simple, yes?
2021-12-08 09:18:03 <psykose> only to medical personnel? i cannot willingly tell other people my own medical history?
2021-12-08 09:18:15 <mps> Ariadne: yes, I understand, and you are right
2021-12-08 09:19:20 <mps> psykose: you can, but I don't care what you will do, I just say that I dislike idea of such software
2021-12-08 09:20:20 <ikke> grafana test timeouts are anoying
2021-12-08 09:20:23 <mps> ofc I will not say that this pkg shouldn't be merged, just told that I'm surprised
2021-12-08 09:20:39 <mps> and I think this is for OT channel
2021-12-08 09:21:33 <PureTryOut> I for one am glad it exists. Way better imo to use this than the government issued apps which require Android and iOS and proprietary Google and Apple services respectively
2021-12-08 09:22:46 <mps> PureTryOut: I'm not saying anything against that you introduced it
2021-12-08 11:26:26 <valerius> I for one welcome our new pharmaceutical overlords
2021-12-08 11:26:56 <psykose> discuss it in offtopic if you wish
2021-12-08 11:27:30 <valerius> like you were doing above?
2021-12-08 11:31:38 <ikke> ncopa: can !28190 be merged?
2021-12-08 11:33:53 <ncopa> ikke: yes
2021-12-08 11:33:58 <ikke> ok
2021-12-08 11:35:19 <psykose> also the backport
2021-12-08 11:35:49 <ikke> yes
2021-12-08 11:48:46 <PureTryOut> might be good to mention in the APKBUILD why it's different from the default
2021-12-08 11:51:12 <ikke> PureTryOut: From what I gather from ncopa, we might even think to reconsider the default?
2021-12-08 11:52:20 <psykose> added for now anyway
2021-12-08 11:52:47 <PureTryOut> ikke: oh? that's new to me
2021-12-08 11:53:21 <psykose> i haven't kept count but i've lost it for how many times something had debugging enabled with None
2021-12-08 11:53:42 <ikke> https://tpaste.us/NML6 
2021-12-08 11:54:03 <psykose> also those other ways don't work, as those are already implicit and prepended
2021-12-08 11:54:08 <ikke> yeah
2021-12-08 11:54:12 <ikke> you mentioned that
2021-12-08 11:54:20 <psykose> yeah, just making sure
2021-12-08 11:54:30 <psykose> but like... i'm sure there /must/ be a way
2021-12-08 11:54:37 <psykose> to just make cmake append some flags? surely this isn't insane?
2021-12-08 11:55:06 <psykose> maybe the gentoo folk have done something special for cmake
2021-12-08 11:55:47 <psykose> i think it's also a good idea to add an abuild-cmake similar to abuild-meson to get the 3-5 flags everyone adds into it
2021-12-08 11:55:57 <psykose> but not really important
2021-12-08 14:23:52 <dosmanak> Hello. I hit a bug, when I insallet mariadb-client package I could not connect to percona mysql db due missing library caching_sha2_password.so which is present in package mariadb-connector-c. Isn't it missing dependency?
2021-12-08 14:24:50 <Hello71> gentoo used to set -DCMAKE_BUILD_TYPE=Gentoo, but in new EABIs it is RelWithDebInfo then flags overridden in toolchain file
2021-12-08 14:49:25 <artok> but did they set CMAKE_Gentoo_C_FLAGS etc?
2021-12-08 14:55:57 <Hello71> well it would be CMAKE_C_FLAGS_GENTOO but i don't think there's a need to
2021-12-08 14:57:26 <Hello71> ah, yes, None isn't really a valid type
2021-12-08 15:01:09 <orbea> it is documented on the cmake ML
2021-12-08 15:07:22 <Hello71> like, it's not invalid
2021-12-08 15:08:14 <orbea> yea, its not documented on the cmake docs, but I did learn about it from the ML :P
2021-12-08 15:58:24 <mps> psykose: could you remove noted one line in !28264? I tested build yesterdays with this extra '--without-wasm-sandboxed-libraries' and it is ok
2021-12-08 15:59:36 <mps> ohm, also you need to update '_releasedate=2021-11-22' to real release date
2021-12-08 17:55:40 <aparcar> ncopa: my openwrt build scripts are here https://github.com/openwrt/openwrt/pull/4294
2021-12-08 17:55:49 <aparcar> ncopa: it will take some more time to have it fully integrated
2021-12-08 17:56:19 <aparcar> ncopa: specially the roots part bugs me right now since I'm not sure how to handle post-install scripts for the rootfs
2021-12-08 17:58:51 <mps> aparcar: could you post url of your script source (I'm bad with finding things on github)
2021-12-08 17:59:23 <aparcar> mps: what do you want to see specifically? It's deeply integrated in the openwrt build system
2021-12-08 17:59:33 <aparcar> it's all makefile 
2021-12-08 18:00:06 <mps> aparcar: ah, ok. I thought you are making script to make image from packages
2021-12-08 18:01:17 <aparcar> mps: that what the makefiles are doing :)
2021-12-08 18:02:36 <mps> I have some simple scripts to install alpine on different boxes (real and qemu) which practically creates 'images' on disks, mmcs or qemu imgs
2021-12-09 01:00:52 <psykose> mps: done
2021-12-09 01:30:53 <anjan> I have a friend who wanted to try out alpine as a desktop (using dwm), they used the setup-xorg script
2021-12-09 01:31:02 <anjan> but the user was not added to the video group and it tripped them up
2021-12-09 01:31:24 <anjan> would you guys accept a patch with a prompt to ask the user which user to add to the video group?
2021-12-09 01:34:18 <ktprograms> anjan: wouldn't you need to add to input and audio groups too?
2021-12-09 01:34:46 <anjan> ktprograms: oh, probably yua
2021-12-09 01:35:03 <anjan> I just think it's a bit annoying to get errors everywhere when the script is supposed to handle that
2021-12-09 01:36:35 <ktprograms> anjan: Makes sense. Maybe you could see how some of the other setup-* scripts handle input, and have the default value be $USER?
2021-12-09 01:36:47 <Hello71> on balance that sounds like a good idea
2021-12-09 01:37:42 <Hello71> if xorg supported seatd then i think that would be better, but afaik it doesn't
2021-12-09 01:38:16 <anjan> ktprograms: thats a good idea, Ill check
2021-12-09 01:38:47 <ktprograms> anjan: I think it would be best so split video,audio,input to 3 separate questions, for maximum configurability.
2021-12-09 01:41:25 <anjan> ok Ill hack together a patch right now =)
2021-12-09 01:54:43 <Saijin_Naib[m]> I've been tripped up by this exact thing, so I think having the setup-xorg script do that all would be excellent and shorten that barrier to entry of using Alpine with a DE for new folks significantly
2021-12-09 01:58:46 <psykose> i think it also doesn't tell you to restart / su yourself after either, which a few people run into, which you need for groups to take effect
2021-12-09 01:59:52 <Saijin_Naib[m]> Had no idea that is a thing
2021-12-09 02:00:09 <Saijin_Naib[m]> Does it check for a user with ID over 1000? GDM at least requires that to work right, according to Alpine wiki/docs
2021-12-09 02:00:18 <psykose> yeah, groups update only after you log in again
2021-12-09 02:00:49 <psykose> and i don't think it checks that either, i mean xorg-setup-base is like a 10 line script that enables community and installs 4 packages
2021-12-09 02:01:01 <psykose> and runs setup-udev
2021-12-09 02:01:26 <Saijin_Naib[m]> Should this be something like setup-de or something?
2021-12-09 02:01:38 <psykose> it would take some work, but yeah that would be a nice 'helper' script
2021-12-09 02:02:58 <Hello71> well i mean there's a reason why it's the way it is. xorg used to be suid so this wasn't necessary
2021-12-09 02:03:29 <Hello71> actually it should only need input and audio now, with rootless drm patch
2021-12-09 02:07:04 <ktprograms> Oh, is xorg set up to be rootless now? If so, how do I set it up?
2021-12-09 02:07:35 <psykose> the installed xorg-server should just be rootless
2021-12-09 02:08:24 <ktprograms> psykose: I guess I'll have to try again, but the last time I tried, it didn't work.
2021-12-09 02:08:54 <psykose> sure, but by default someone installing xorg-server has it as not suid
2021-12-09 02:09:00 <psykose> some people have issues and +s it
2021-12-09 02:12:08 <Hello71> the "standard" rootless is with elogind
2021-12-09 02:12:23 <Hello71> rootless kms is "experimental"
2021-12-09 02:15:27 <anjan> I opened the MR https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/42
2021-12-09 02:15:54 <ktprograms> Hello71: Ah, so if I'm just using 'startx' without anything else then it needs suid?
2021-12-09 02:16:30 <Hello71> well you need to install and enable elogind
2021-12-09 02:16:44 <ktprograms> anjan: What's the PREFIX= and . "$PREFIX"/lib/libalpine.sh?
2021-12-09 02:17:10 <anjan> ktprograms: checkout the root of alpine-conf and the other scripts
2021-12-09 02:17:12 <ktprograms> anjan: Why not use $USER?
2021-12-09 02:17:22 <anjan> it provides the "ask" command
2021-12-09 02:17:31 <anjan> ktprograms: because that script is supposed to be run as root
2021-12-09 02:17:50 <anjan> we dont want users to run xorg as root
2021-12-09 02:17:55 <ktprograms> anjan: I see. Forgot about the root
2021-12-09 02:18:22 <anjan> sorry what? ktprograms 
2021-12-09 02:18:57 <ktprograms> anjan: I meant I was mistaken. Yes, you can't use $USER if the script is running as root.
2021-12-09 02:19:09 <anjan> oh ok no problem =D
2021-12-09 02:20:21 <ktprograms> anjan: I think you should use 'adduser "$resp" video', because usermod is in the 'shadow' package which isn't installed by default
2021-12-09 02:20:59 <anjan> oh, interesting. Ill amend my patch. thanks
2021-12-09 02:23:15 <ktprograms> anjan: getent is from musl-utils. Is there any alternative that is just part of busybox (so as to not add extra dependencies)?
2021-12-09 02:23:57 <anjan> ktprograms: i dont think so. I looked up on stackexchange
2021-12-09 02:24:01 <anjan> Im open to changing it
2021-12-09 02:25:06 <ktprograms> anjan: Can you share the link to the stackexchange answer you found?
2021-12-09 02:26:13 <anjan> https://unix.stackexchange.com/questions/36580/how-can-i-look-up-a-username-by-id-in-linux
2021-12-09 02:31:53 <psykose> getent passwd 10000 doesn't return anything for me, did you mean 1000
2021-12-09 02:32:56 <psykose> and id -nu not working with a number seems to be a busybox bug
2021-12-09 02:33:53 <psykose> at least i don't see another use -n can have if all you can get is a username back from the same username you supply instead of a uid
2021-12-09 02:35:46 <ktprograms> anjan: As there doesn't seem to be any way to get the user without additional dependencies, I think you should 'ask' for the username, then just have yes/no for the adding groups.
2021-12-09 02:36:15 <ktprograms> Also, 'echo' a message to log out and log back in for group changes to take effect
2021-12-09 02:38:38 <ktprograms> Is there any reason why dirs in /var/lib/gitea aren't world readable? Is there sensitive data there?
2021-12-09 03:20:05 <ktprograms> anjan: Looks good, but the 'ask' on line 19 doesn't need the empty ""
2021-12-09 03:28:25 <ktprograms> anjan: See my suggested change.
2021-12-09 03:32:21 <ktprograms> anjan: Looks fine to me now. 👍
2021-12-09 03:41:38 <anjan> sounds good ktprograms 
2021-12-09 03:41:42 <anjan> hopefully it gets merged
2021-12-09 09:03:34 <mps> \o
2021-12-09 09:03:42 <mps> ncopa: !28226
2021-12-09 09:07:04 <mps> omni: zig 0.9.0 will be released (probably)  in 10 days. could we postpone !27367 till that release
2021-12-09 09:22:53 <psykose> maybe it's time for some llvm/clang 13 fun too :p
2021-12-09 09:23:39 <psykose> also should find a way to reenable compiler-rt sanitizers- i tried to currently but it failed ci on every arch except x86_64, maybe it's just magically fixed in 13
2021-12-09 09:24:13 <psykose> the cfi stuff currently disabled in the chromium build needs some files from compiler-rt-sanitizers to be enabled
2021-12-09 09:39:20 <caskd> Does the pkg maintainer for grafana happen to be here? grafana-frontend split is installed as a dep before grafana resulting in collisions during upgrade
2021-12-09 09:39:57 <caskd> apk fix would fix it but it would be nicer if that wasn't required
2021-12-09 09:40:20 <psykose> it installs fine for me, i assume this is on upgrade only
2021-12-09 09:44:36 <ktprograms> How do I build vim that it doesn't strip binaries? I've already added options="!strip" but it looks like make install still runs strip.
2021-12-09 09:45:16 <ikke> CHeck where it runs strip and rip it out?
2021-12-09 09:46:00 <caskd> psykose: yes, it can only happen during upgrades
2021-12-09 09:55:55 <ktprograms> ikke: That seems to have worked.
2021-12-09 09:57:06 <ktprograms> (Completely unrelated to vim): Can /var/lib/gitea/ be made 755 instead of 750? (Much easier to work with, autocompletion works and can 'cd' there)
2021-12-09 09:57:49 <ikke> You should ask the gitea maintainer
2021-12-09 09:59:24 <ktprograms> ikke: As an issue?
2021-12-09 10:02:39 <ikke> They should be here
2021-12-09 10:02:50 <ikke> Hmm, maybe not atm
2021-12-09 10:07:28 <ikke> so then an issue would be the next option
2021-12-09 10:07:32 <ikke> or an MR
2021-12-09 10:09:04 <ktprograms> ikke: I already have an MR with changing the Gitea initscript to use the Gentoo one, so I'll just add a commit+comment there then
2021-12-09 10:12:37 <ncopa> boomanaiden154: I had issues with mercurial testsuite. dont know why the tests failed
2021-12-09 10:12:49 <ncopa> I also have problems iwth py3-setuptools_scm
2021-12-09 10:20:44 <ktprograms> Why is it that when I run (in gdb) 'start', 'record' and 'continue' it says 'Process record: failed to record execution log.'?
2021-12-09 10:21:25 <psykose> don't you have to do record before start
2021-12-09 10:21:38 <psykose> ah, no
2021-12-09 10:21:39 <psykose> hm
2021-12-09 10:21:49 <psykose> maybe you have to break it first
2021-12-09 10:22:01 <ktprograms> psykose: 'start' sets a breakpoint on main
2021-12-09 10:22:16 <psykose> ah, you're right
2021-12-09 10:25:28 <psykose> i think it
2021-12-09 10:25:37 <psykose> 's because of the unsupported instruction, if it says that
2021-12-09 10:25:43 <psykose> that's the first thing i got on the first thing i tried
2021-12-09 10:26:00 <ktprograms> psykose: There isn't unsupported instruction message for me.
2021-12-09 10:26:06 <psykose> does it say anything else
2021-12-09 10:28:27 <ktprograms> psykose: Nevermind I've given up on record since I already know which variable is the problem, so I'm trying to use watch, but now it says 'Watchpoint 2 deleted because the program has left the block in which its expression is valid.'
2021-12-09 10:29:43 <psykose> afaik you can't watch an auto local variable
2021-12-09 10:30:10 <ktprograms> psykose: Oh I see.
2021-12-09 10:30:24 <psykose> https://stackoverflow.com/questions/25938830/gdb-how-to-force-a-watchpoint-to-not-be-deleted-after-a-function-returned this has a small hack you can use
2021-12-09 10:31:21 <ktprograms> psykose: In vim, how do I see which function I'm currently in?
2021-12-09 10:31:21 <psykose> commands $bpnum means the number of the breakpoint you are given, then it auto applies them when it enters the breakpoint
2021-12-09 10:31:28 <psykose> in vim?
2021-12-09 10:31:38 <ktprograms> psykose: Yes, I'm looking at the source
2021-12-09 10:32:19 <psykose> you can try [m
2021-12-09 10:32:41 <psykose> then `` to move back
2021-12-09 10:32:45 <psykose> unless you mean something else
2021-12-09 10:34:15 <ktprograms> psykose: does that find the nearest function or just the nearest {}?
2021-12-09 10:35:03 <psykose> probably the latter, vim isn't an ide that knows what functions are, but it works while nested inside {}
2021-12-09 10:35:21 <psykose> i'm sure it breaks sometimes, but it works for anything c-like that i can see
2021-12-09 10:35:33 <psykose> or, maybe it works different for me cause i have a fancy setup
2021-12-09 10:36:02 <ktprograms> psykose: watch -l works so I don't think I'll need the vim thing now.
2021-12-09 10:36:10 <ktprograms> BTW what's your vim setup?
2021-12-09 10:36:13 <psykose> not sure why you needed it in the first place :p
2021-12-09 10:36:20 <psykose> and yeah, vanilla vim seems to not work the same
2021-12-09 10:36:25 <psykose> uhh, it's neovim with a bunch of plugins
2021-12-09 10:36:35 <psykose> i think nvim-treesitter is what makes this work better specifically
2021-12-09 10:37:09 <psykose> since it does analyze the actual language syntax with that and it probably overrides [m to use the real top-level function definition instead of some regex magic
2021-12-09 10:37:18 <psykose> but i can't say for sure
2021-12-09 10:37:33 <MaximKarasev[m]> Is there any reason for utf8proc having a custom pkg-config file with different name than in default one?
2021-12-09 10:37:47 <ktprograms> psykose: I see. Wonder if YCM could do that since it integrates with language servers?
2021-12-09 10:38:15 <psykose> for treesitter specifically it's because it parses the language- ycm does some other stuff pretty sure
2021-12-09 10:38:23 <psykose> but maybe, idk what ycm is really doing, or how to integrate that
2021-12-09 10:38:37 <psykose> maybe in the manual it has some keybinds for go-to-definition of various things
2021-12-09 10:38:43 <ktprograms> psykose: Ok thanks anyway
2021-12-09 10:40:03 <psykose> MaximKarasev[m]: they don't seem to have a difference aside from the -D, maybe there is some historical context, or it came first
2021-12-09 10:40:32 <psykose> and of course, the name
2021-12-09 10:41:06 <psykose> seems it was added in 2016 when moved from testing, and never touched
2021-12-09 10:41:44 <psykose> upstream one is dated 2018 for the .in
2021-12-09 10:43:22 <psykose> oh, the upstream one overrides the one that is packaged anyway i think
2021-12-09 10:43:38 <psykose> since the one on disk matches upstream and ignores the git versioned ones changes, and has the -D in it
2021-12-09 10:44:10 <psykose> and both names of it exist, utf8proc.pc and libutf8proc.pc because of the symlink, so everything should work fine anyway
2021-12-09 10:44:26 <psykose> MaximKarasev[m]: you can probably delete the packaged one and clean up the build a bit, but i don't think anything is broken
2021-12-09 10:54:02 <piraty> does alpine offer outdated .apk somewhere?
2021-12-09 10:57:27 <ikke> no
2021-12-09 10:57:34 <ikke> We don't have the space to keep older versions
2021-12-09 11:00:44 <piraty> any known mirror slow to sync?
2021-12-09 11:01:08 <ikke> look at mirrors.alpinelinux.org
2021-12-09 11:01:27 <piraty> yep
2021-12-09 11:04:51 <piraty> say i need alsa-lib-1.2.5.1-r1, how to conince apk-fetch to pull it from one of the mirrors ?
2021-12-09 11:06:49 <psykose> apk add -X mirror thing might work
2021-12-09 11:07:36 <piraty> i temporarily put the mirror alone in the repositories file
2021-12-09 11:09:29 <psykose> why do you want the old version anyway
2021-12-09 11:10:44 <piraty> debug sound issues
2021-12-09 11:10:53 <piraty> why else
2021-12-09 11:11:49 <piraty> thanks, add -X kinda did it for now, `man apk-add` is a bit sparse though, `apk add --help` is more useful
2021-12-09 11:12:51 <psykose> the other options are in man apk
2021-12-09 11:12:56 <psykose> apk-add only has the add specific options
2021-12-09 11:13:05 <psykose> -X is valid for fetch etc as well
2021-12-09 11:15:08 <ktprograms> psykose: Do you know how to make gdb continue after the local watchpoint goes out of scope?
2021-12-09 11:15:41 <psykose> can't you just type continue
2021-12-09 11:15:52 <psykose> or `c` for short
2021-12-09 11:16:16 <ktprograms> psykose: any way to make it auto-continue?
2021-12-09 11:16:26 <ktprograms> psykose: It goes through about 100 times
2021-12-09 11:16:53 <psykose> i don't think that's possible
2021-12-09 11:17:01 <ktprograms> psykose: Ok, nevermind then
2021-12-09 11:17:06 <psykose> but it doesn't save you much time as you're stepping through it and continuing 100 times anyway
2021-12-09 11:17:42 <psykose> you can break only if something is a specific value, if that works
2021-12-09 11:17:51 <ktprograms> psykose: I have a breakpoint that sets a watchpoint, then continues
2021-12-09 11:18:31 <psykose> you could make the autocommand continue for you so it just goes through it 100 times and logs it each time without stopping
2021-12-09 11:19:51 <psykose> maybe something here is what you want https://stackoverflow.com/questions/53173854/watching-local-variables-in-gdb-without-stopping-execution
2021-12-09 11:20:20 <ktprograms> psykose: What does 'Cannot access memory at address' mean (after a segfault)?
2021-12-09 11:22:06 <piraty> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28220 is likely to have broken it (PureTryOut accuses alsa-ucm-conf)
2021-12-09 11:24:54 <psykose> ktprograms: something interpreted as a pointer in the program doesn't point to valid memory
2021-12-09 11:25:02 <PureTryOut> (because it has broke things in the past and seems the most logical in the things that got upgraded)
2021-12-09 11:25:24 <piraty> yeah makes sense
2021-12-09 11:25:37 <piraty> i found a mirror that has the old package (i don't have it in cache anymore
2021-12-09 11:26:22 <piraty> how to downgrade? apk add -X mirror <pkg> doesn't
2021-12-09 11:26:46 <psykose> ah, i guess it still prefers the new one anyway
2021-12-09 11:26:53 <psykose> just do fetch instead, the apk add ./the.apk
2021-12-09 11:28:16 <piraty> ah
2021-12-09 11:28:27 <piraty> --repositories-file=/dev/null :>
2021-12-09 11:28:30 <piraty> works
2021-12-09 11:28:51 <piraty> at least for `apk fetch`
2021-12-09 11:35:41 <ktprograms> psykose: What I'm trying to debug is that after vim 8.2.3584, it segfaults if you have "call dein#begin('/path/to/dein/dir')" in your vimrc when you open a directory.
2021-12-09 11:36:24 <psykose> sadly i have no idea what would cause that
2021-12-09 11:36:33 <ktprograms> The backtrace shows that the segfault was at https://github.com/vim/vim/blob/58ef8a31d7087d495ab1582be5b7a22796ac2451/src/usercmd.c#L1778, but as far as I can see cmd isn't set again, and it doesn't segfault at L1769, which is exactly the same as L1778.
2021-12-09 11:37:02 <ktprograms> The funny thing is, if I run vim -u /etc/vim/vimrc (which is anyway the default vimrc), then it doesn't happen.
2021-12-09 11:37:11 <ktprograms> s/it/the segfault
2021-12-09 11:37:11 <alpine-meetbot> ktprograms meant to say: The funny thing is, if I run vim -u /etc/vim/vimrc (which is anyway the default vimrc), then the segfault doesn't happen.
2021-12-09 11:47:37 <ncopa> any python experts can help me figure out how to fix this: https://tpaste.us/YENP
2021-12-09 11:48:51 <ikke> does that need python 3.10?
2021-12-09 11:51:13 <psykose> if that's using current py3-packaging, it's probably an issue with the version regex in it.. https://img.ayaya.dev/IFKRLl6PxRtG but idk what it matches
2021-12-09 11:51:20 <psykose> if it doesn't match that it fails and throws what you get
2021-12-09 11:52:39 <psykose> and the version passed seems to be a path and not a version string
2021-12-09 11:57:23 <psykose> maybe it's getting the version from its egg-info or something, and the egg-info contains the path in the version
2021-12-09 11:57:34 <psykose> i had to patch that in something recently
2021-12-09 11:57:59 <psykose> instead of 2.0.4 it had /full/path/something/2.0.4 or somesuch
2021-12-09 11:58:50 <ktprograms> psykose: I'm giving up on debugging the vim segfault. Do you think a repdoction instruction like 'install dein' and 'run vim directory/' is ok?
2021-12-09 11:59:02 <ktprograms> s/repoduction/reproduction
2021-12-09 11:59:05 <psykose> yeah, if it segfaults for them too it should be fine
2021-12-09 11:59:11 <ktprograms> psykose: Ok
2021-12-09 11:59:14 <psykose> not exactly full of info but a reproducible segfault should be fine
2021-12-09 11:59:22 <psykose> you should try reproduce it on another environment too
2021-12-09 11:59:46 <ktprograms> psykose: Other environment as in another distro?
2021-12-09 12:00:03 <psykose> yeah, or just start a docker container with another distro image and do it there
2021-12-09 12:00:15 <ktprograms> psykose: Ok, will do. Thanks for the advice
2021-12-09 12:16:51 <ncopa> yes, it only happens with python 3.10
2021-12-09 12:27:03 <ktprograms> psykose: What's a good distro to test recent software that also works on aarch64? (with Debian even unstable doesn't have the problematic version)
2021-12-09 12:27:40 <psykose> you should build the same version from source
2021-12-09 12:28:02 <ktprograms> psykose: Ah, ok. will do
2021-12-09 13:00:55 <ncopa> i thikn i have a problem with rootbld
2021-12-09 13:02:03 <ncopa> building python 3.10 main packages with rootbld works, but when building commuity, it pulls in python from https, not from local main repo
2021-12-09 13:02:26 <ncopa> which means that the community packages I have built in rootbld was built with python 3.9, not 3.10
2021-12-09 13:06:25 <psykose> i think i had something similar once and manually added the local repo to community/.rootbld-repositories
2021-12-09 13:08:04 <ncopa> thank you for that tip. seems to work
2021-12-09 13:08:54 <psykose> afaik it works with the same local repo (i.e. local-build community/ will be pulled in in rootbld), but seems to fail for cross-repo local, i never investigated it more
2021-12-09 13:10:29 <ncopa> and now ofc, alot more packages fails
2021-12-09 13:10:30 <minimal> relevant to the recent kernel & initramfs compression changes: https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Initramfs-Zstd-Too-High
2021-12-09 13:11:24 <ncopa> we use gz for module compression
2021-12-09 13:11:49 <ncopa> we also ran out of memory when using zstd on 32 bit x86
2021-12-09 13:12:08 <psykose> minimal: the picture in the article is compression though
2021-12-09 13:12:36 <ikke> You mean compression level?
2021-12-09 13:13:40 <minimal> the article is about initramfs compression rather than kernel.
2021-12-09 13:13:48 <minimal> This is the bit that caught my eye: "But with that highest compression level they have found the initramfs decompression to be too slow and consumes too much memory. In particular, for low-end devices and embedded hardware like the Raspberry Pi Zero with just 512MB of RAM, it just crashes."
2021-12-09 13:15:23 <psykose> the original source does not specify whether it was compression or decompression that crashes
2021-12-09 13:15:37 <psykose> and appears to mention 500MB usage on compression create of the initramfs
2021-12-09 13:16:17 <psykose> i assume it is a misquote by phoronix, which is typical for the quality of phoronix articles, but regardless, it would mean that -19 can't be used to compress in low memory environments
2021-12-09 13:16:33 <minimal> psykose: even if its compression, rather than decompression, it is still relevant any time mkinitfs is run on a slow/low memory device (i.e. when kernel package is updated)
2021-12-09 13:16:49 <psykose> that is what i said
2021-12-09 13:16:53 <psykose> but yeah, the ubuntu ml says as much
2021-12-09 13:17:27 <minimal> psykose: yes I was typing whilst you were saying the same thing
2021-12-09 13:18:53 <psykose> i also think this doesn't apply as much to alpine mkinitfs, as i don't see why zstd -19 would use 500mb for an initramfs that is like <50 uncompressed
2021-12-09 13:19:19 <psykose> but -9 or -1 would be fine if we ever move there
2021-12-09 13:23:24 <psykose> a quick -19 of my 25mb uncompressed initramfs-lts gave 126180KB peak resident, and -9 gave 48324KB
2021-12-09 13:23:30 <psykose> -9 should be fine for everything i would guess
2021-12-09 13:24:57 <psykose> and for something like the kernel/modules, which is precompressed, should be fine with -19/-22 as all the linked issues are about compression alone it seems
2021-12-09 13:29:29 <minimal> psykose: the kernel modules were compressed with zstd for a short time before switching to gzip, from memory someone in this channel compared resultant sizes and here wasn't much diff between the 2 compressions for some reason. It'll be in the IRC logs, about 4 weeks ago from memory.
2021-12-09 13:30:00 <psykose> there was much difference, but it was partly lost due to needing 1MB kmod thrown in there to decompress them
2021-12-09 13:30:17 <psykose> another quick test- zstd -3 beats gzip -9
2021-12-09 13:31:04 <minimal> that's why the "full fat" kmod/modprobe was added to the initramfs as Busybox's modprobe doesn't support zstd (the "full fat" kmod/modprobe still hasn't yet been removed since the revert to gzip)
2021-12-09 13:31:16 <psykose> yes
2021-12-09 13:31:16 <mps> minimal: \o
2021-12-09 13:31:24 <psykose> hopefully the busybox zstd gets merged eventually
2021-12-09 13:31:25 <mps> I did
2021-12-09 13:31:57 <Ariadne> psykose: i can work on backporting it into alpine's busybox patches today, if it would help
2021-12-09 13:32:01 <Ariadne> it's not terribly invasive
2021-12-09 13:32:17 <psykose> oh it's not needed for anything- just long term i think we would eventually move to zstd modules
2021-12-09 13:32:22 <mps> and it is not important
2021-12-09 13:32:29 <psykose> and then it's preferable to kmod in initramfs
2021-12-09 13:32:40 <minimal> psykose: I think the delay getting it into Busybox was it didn't (yet) meet the Busybox code standards and it needed to be tweaked/rewritten to meet those
2021-12-09 13:32:50 <psykose> of course, the sooner it gets there, the sooner we can do some testing that busybox zstd support actually works
2021-12-09 13:33:02 <psykose> it's a fairly big patch
2021-12-09 13:33:39 <psykose> minimal: the last post in the ML was asking what to do in september- afaik it's dead since then https://www.mail-archive.com/busybox@busybox.net/msg27914.html
2021-12-09 13:34:27 <psykose> dead as in no activity
2021-12-09 13:43:28 <ktprograms> psykose: You use a heavily configured vim right? How do you manage keeping root vim and user vim having the same configuration?
2021-12-09 13:43:58 <psykose> ktprograms: i use the equivalent of sudo -e with doas, doasedit, that has you edit a tmpfile as your user and uses doas to copy the file after
2021-12-09 13:44:49 <ktprograms> psykose: So you never use 'doas vim'?
2021-12-09 13:44:52 <psykose> nope
2021-12-09 13:45:10 <psykose> there are multiple doasedits around, i can give you mine that i stole from somewhere and patched afterward
2021-12-09 13:45:31 <ktprograms> psykose: But if you do that, you can't open other files in splits etc, right?
2021-12-09 13:45:49 <psykose> sure you can, all it does is modify the tmpfile it opened itself on close in the script
2021-12-09 13:45:56 <psykose> well, the things you open wont be as root
2021-12-09 13:46:01 <psykose> so, yes, you cant in that sense
2021-12-09 13:46:16 <psykose> i never really edit more than one file at once as root anyway, i can't imagine when i would be doing that
2021-12-09 13:46:39 <psykose> and i don't keep my editor open normally, i open/close it all the time per file, so i guess it works for me
2021-12-09 13:46:53 <ktprograms> psykose: I see
2021-12-09 13:47:28 <ktprograms> I seem to have traced the issue to having the luochen1990/rainbow plugin installed that's causing the segfault
2021-12-09 13:47:33 <psykose> it starts instantly even with all the plugins, afaik just because all the lua stuff is much faster in neovim, and most of them are lua + the init.vim is init.lua instead for me
2021-12-09 13:48:06 <psykose> i think the vim author was working on a vimscript revamp to make it much faster for vim9
2021-12-09 13:54:13 <psykose> minimal: do you think there is a need to keep /sbin/modprobe in base.files? since it's not needed anymore as no zstd
2021-12-09 13:56:45 <minimal> psykose: that was my point - its not currently needed as zstd use was reverted. I think ncopa said he intended to remove it. Perhaps if there's an intention to use zstd again it will stay in place.
2021-12-09 13:56:58 <psykose> yes, that or the patch
2021-12-09 13:57:03 <psykose> sure, no harm in the interim then
2021-12-09 13:57:14 <minimal> removing it would make a (small) difference to initramfs size
2021-12-09 13:57:33 <psykose> it seems to be 128K by itself
2021-12-09 13:57:45 <psykose> 138
2021-12-09 13:58:10 <psykose> and libzstd is 1.1MB
2021-12-09 13:58:24 <minimal> I used "small" as a relative term as I didn't check the modprobe size
2021-12-09 13:58:41 <psykose> yeah, just getting the numbers
2021-12-09 14:01:07 <minimal> yeah about 1.2-1.3MB for kmod/libkmod/libzstd
2021-12-09 14:02:15 <psykose> i am assuming the patch does not depend on libzstd itself, since i did not formally verify what it is doing, as that is most of the space saving
2021-12-09 14:02:26 <minimal> which is a significant percentage of the 5MB slimmed-down initramfs I have on the VM I'm looking at here
2021-12-09 14:02:32 <psykose> hah
2021-12-09 14:02:35 <psykose> yeah, that is a quarter
2021-12-09 14:03:50 <minimal> obviously it would tend to be a far lower oercentage of the size of an initramfs on a physical machine with various kernel modules and their firmware in the initramfs
2021-12-09 15:16:59 <Hello71> initramfs modules shouldn't be compressed anyways
2021-12-09 15:17:50 <Hello71> double compression almost always makes files larger
2021-12-09 15:27:39 <mps> Hello71: right
2021-12-09 15:28:02 <mps> that is why I don't see much benefit in compressing modules
2021-12-09 15:28:19 <mps> apk file is also compressed
2021-12-09 15:28:50 <mps> only less space on disk when pkg is installed
2021-12-09 15:28:52 <Hello71> it saves disk space
2021-12-09 15:29:25 <mps> less space but more time when loading them
2021-12-09 15:29:45 <mps> though I would call all this nitpicking
2021-12-09 15:31:55 <minimal> mps: depends on whether the device (i.e. SBC) is more limited by slow I/O to load the file(s) or CPU for decompression
2021-12-09 15:33:51 <mps> minimal: right
2021-12-09 15:34:32 <mps> but we are talking about _default_ for alpine and about tailored to specific use cases
2021-12-09 15:34:50 <mps> s/and/and not/
2021-12-09 15:34:50 <alpine-meetbot> mps meant to say: but we are talking about _default_ for alpine and not about tailored to specific use cases
2021-12-09 15:36:22 <minimal> mps: right, and I was thinking in terms of armv7 and aarch64 which generally speaking have both slow I/O and limited CPU (though Alpine aarch64 can be used on multi-core AWS and Oracle Cloud VMs too)
2021-12-09 15:36:55 <minimal> by default neither is likely to be an issue for x86 & x86_64
2021-12-09 15:40:36 <mps> I'm using arm32 desktops for more than 10 years and I don't think compressed modules are much better on them
2021-12-09 15:41:30 <mps> irrelevant, imo
2021-12-09 15:42:27 <mps> minimal: when you are here, could you tell me is possible to install grub files on EFI partition instead of rootFS
2021-12-09 15:43:05 <mps> it is possible to copy them ofc, but does that makes sense
2021-12-09 15:44:23 <psykose> which grub files
2021-12-09 15:45:14 <mps> psykose: all under /boot/grub dir, actually all files under /boot dir
2021-12-09 15:47:32 <psykose> that doesn't seem useful? the only thing that needs to be on esp (i assume /boot/efi here) is the grub efi image, which gets placed under esp/EFI/alpine/grub$arch.efi
2021-12-09 15:47:37 <mps> I have problem with nvme disk on apple m1, u-boot find efi and tries to find partition with /boot files but can't
2021-12-09 15:47:44 <psykose> ah
2021-12-09 15:48:05 <psykose> you can use grub-install with --directory to put then on something other than /boot/grub
2021-12-09 15:49:37 <mps> or simply 'cp -a /boot /mnt'? /mnt is where efi partition is mounted
2021-12-09 15:50:04 <mps> problem could be FAT fs on efi part
2021-12-09 15:50:24 <psykose> i would assume that's fine as long as the efi image is in the same place and boots fine, but i don't know m1-specific config
2021-12-09 15:50:52 <psykose> i would assume that the issue is something else though, as you would not get a u-boot error if grub was found at all
2021-12-09 15:51:01 <psykose> you should check if /mnt (efi part) has any .efi in it
2021-12-09 15:51:06 <mps> efi part is nvme0n1p4 and rootFS is nvme0n1np5
2021-12-09 15:51:53 <mps> it starts grub but put me in grub rescue cli
2021-12-09 15:52:32 <mps> ok, thanks for idea, I look further on this
2021-12-09 15:54:05 <psykose> i was also testing grub-install and it deletes all your other efi entries... nice
2021-12-09 16:57:41 <minimal> mps: <back> grub-install --directory is where it gets files from, not puts them to. What you'd want would be "--boot-directory"
2021-12-09 16:58:33 <minimal> mps: you could possibly use a bind mount "trick" to instead map /boot/grub/ to somewhere in the ESP partition I guess
2021-12-09 17:00:39 <psykose> yes, boot-directory, mind-typod that one
2021-12-09 17:00:39 <psykose> hah
2021-12-09 17:02:32 <minimal> so /dev/nvme0n1p4 is your ESP partition, which then has a "EFI" directory. You could for example create a "grub" directory at the same level and then for example either (a) mount that onto /boot/grub, or (b) grub-install --boot-directory <mount location of nvme0n1p4's grub directory>
2021-12-09 17:03:17 <minimal> you'd obviously have to have either of these mounts into your /etc/fstab
2021-12-09 17:03:46 <mps> minimal: thanks. but 'cp -a .... ...' is simpler if it works
2021-12-09 17:04:16 <mps> will check later
2021-12-09 17:04:34 <mps> now I have to free some ssd disks
2021-12-09 17:04:37 <minimal> mps: I had a similar issue with Syslinux when I got UEFI working - it was message as I had to manually copy files into the same ESP partition directory as the Syslinux.efi file so I started trying to avoid the copying using a bind-mount but never quite got it working right
2021-12-09 17:04:45 <minimal> s/message/mess/
2021-12-09 17:04:45 <alpine-meetbot> minimal meant to say: mps: I had a similar issue with Syslinux when I got UEFI working - it was mess as I had to manually copy files into the same ESP partition directory as the Syslinux.efi file so I started trying to avoid the copying using a bind-mount but never quite got it working right
2021-12-09 17:05:20 <mps> minimal: yes, also I did something like this when installed syslinux on efi system
2021-12-09 17:06:00 <minimal> the idea of the bind-mount was that any syslinux package updates would get "automagically" applied
2021-12-09 17:08:41 <mps> for now I just want to get m1 boot with grub, making it 'proper' is for later tasks
2021-12-09 17:09:25 <mps> actually it boot with u-boot+grub combo from usb devices but not from internal nvme
2021-12-09 17:11:29 <psykose> is there an easy way to bump pkgrel on everything depending on something in main/ only, etc
2021-12-09 17:14:56 <mps> psykose: yes, simple shell script, which I deleted by mistake
2021-12-09 17:15:01 <psykose> ha
2021-12-09 17:15:15 <mps> probably someone else have it, just wait some time
2021-12-09 17:15:43 <psykose> i figured it out, for everything
2021-12-09 17:15:47 <psykose> but i can commit one repo at once
2021-12-09 17:16:23 <psykose> not sure if good idea to bump 149 packages though, haha
2021-12-09 17:17:07 <psykose> or if 0.1.0->0.20.0 needs bump, i forgot
2021-12-09 17:32:41 <psykose> from what i can tell it doesn't, so i guess !28296 should be fine
2021-12-09 17:33:25 <psykose> the 0.0.0->0.20.0 always looks sketchy
2021-12-09 17:59:15 <Nulo> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28210
2021-12-09 18:01:09 <mps> !28210
2021-12-09 18:53:45 <Nulo> When trying to use rust@edge I get this: Error relocating /usr/bin/../lib/librustc_driver-860c4c8b1b0c7de2.so: _ZSt28__throw_bad_array_new_lengthv: symbol not found
2021-12-09 18:56:43 <psykose> did you upgrade? and what arch
2021-12-09 18:56:59 <psykose> i don't get that on x86_64
2021-12-09 18:58:27 <Nulo> x86_64. I'm on 3.15 but specifically installed the rust from edge.
2021-12-09 18:59:26 <Nulo> Ah, libstdc++ is significantly newer in edge. That's probably it.
2021-12-09 19:02:44 <psykose> well..
2021-12-09 19:02:47 <psykose> :p
2021-12-09 19:02:56 <psykose> yes, edge got a 10->11 gcc upgrade
2021-12-09 19:07:02 <psykose> and i still have not figured why the rustup toolchains are broken, on x86_64-musl-stable/nightly at least
2021-12-09 19:07:31 <psykose> some things just sigsegv instantly, with the easiest repro just being a gtk::init() from the gtk crate
2021-12-09 19:07:43 <psykose> i spent 3 hours stepping through gdb debugging and got too tired
2021-12-09 19:16:52 <Nulo> I really don't like Rust in that sense (and many others)
2021-12-09 19:17:10 <Nulo> Apparently there's *no way* to compile vaultwarden without pulling nightly Rust (so not possible to package properly at all)
2021-12-09 19:18:46 <Hello71> allegedly they are working on it
2021-12-09 19:18:59 <Nulo> Yes, I know
2021-12-09 19:19:59 <psykose> i've said it before but i wish stuff in nightly rust was not stuck there forever or it was not viewed so seriously that it is used on like half of projects
2021-12-09 19:33:14 <Hello71> dalias: you said before that -fno-plt on x86/x86_64 by default is probably ok. what about -mtls-dialect=gnu2?
2021-12-09 19:33:52 <Hello71> also https://gitlab.alpinelinux.org/alpine/aports/-/issues/13246#note_195905
2021-12-09 19:38:50 <psykose> going off the manpage- what do they mean exactly with 'new assembler, linker, and library support' as requirements for gnu2?
2021-12-09 19:42:02 <Hello71> binutils *mumblemumble* and libc *mumblemumble*
2021-12-09 19:42:27 <Hello71> alpine has it.
2021-12-09 20:03:56 <mipmeb>  c  e  r t  a i n l y    		 ,   	 z		 a m e r i c a n  s 		n e e d e d  	     s o m e t h i n  g   	  l i  k e   	9  /  11 	   t  o  	  	 J u s t i f y      		i n v a  d i n g  -  		i r -  a  q		   w h i c h	    h  a s	   b e e n	   		a l r e a d y 	  	p la n n e d 			a s 	  	a  p a r t  		o f   		c r e  a t i v e    		c -h a  o s 	p l   a n  	 f o r  		  m i d d l e	     -e a s t   		 D    i   d   
2021-12-09 20:14:09 <dalias> hello71, yes please -mtls-dialect=gnu2
2021-12-09 20:14:16 <dalias> it should be default anywhere it's supported
2021-12-09 20:14:44 <Hello71> apparently it's default on arm64
2021-12-09 20:15:05 <Hello71> anything other than -fno-plt and -mtls-dialect=gnu2?
2021-12-09 20:17:48 <dalias> i mean there are lots of potentially valuable tweaks but i dont think you want to become gentoo :-p
2021-12-09 20:36:25 <psykose> if it's not going to end up with 5 unique flags per arch i think there's more room
2021-12-09 20:37:03 <Saijin_Naib[m]> You don't want individual builds per sub-arch like Funtoo? 😛
2021-12-09 20:37:54 <psykose> those are local, it's the same on gentoo with whatever stuff you want to set yourself really
2021-12-09 20:38:07 <psykose> as in afaik funtoo doesn't have a bindist for every sub-arch
2021-12-09 20:38:35 <Saijin_Naib[m]> https://www.funtoo.org/Subarches
2021-12-09 20:39:07 <Saijin_Naib[m]> Any way to scrape their stuff to find out what flags they use for everything?
2021-12-09 20:39:16 <Saijin_Naib[m]> It looks like they've put a ton of work into this all
2021-12-09 20:39:41 <psykose> oh wow, they do have a prebuild
2021-12-09 20:39:55 <psykose> well i guess it's just compiling the same thing 10 times on the same build server, technically
2021-12-09 20:40:05 <psykose> Saijin_Naib[m]: if yo click the page you see the flags
2021-12-09 20:40:32 <psykose> eg skylake is -march=skylake -O2 -pipe and the set of CPU_FLAGS for it
2021-12-09 20:40:44 <Saijin_Naib[m]> psykose: Yeah, I've dug through a bit. I was just wondering where they all would be so that a "common" set of flags could be drawn from
2021-12-09 20:40:54 <Saijin_Naib[m]> Other than scraping the site or manually recording them all
2021-12-09 20:41:17 <psykose> i don't think they are setting anything fancy in these 24 pages
2021-12-09 20:41:25 <psykose> and perhaps the default gcc flags has more
2021-12-09 20:42:08 <psykose> they're all -O2 pipe pretty much, with some omit-frame-pointer
2021-12-09 20:42:17 <Saijin_Naib[m]> Ahhh, okay. I don't understand it enough to know. It does run nicely, however. I think that's mostly down to basically doing a -march=native for each one, though
2021-12-09 20:56:21 <Hello71> even arch is considering subarches now
2021-12-09 21:09:26 <Saijin_Naib[m]> Does that mean it is a good(ish) idea, or is it still pretty niche and without demonstrable benefit?
2021-12-09 21:16:31 <Ariadne> fwiw subarch is something that will likely get proper support in apk3 because of openwrt
2021-12-09 21:28:50 <Saijin_Naib[m]> Is the embedded space where it makes sense, or do you think that would work it's way back out to non-embedded Alpine? 
2021-12-09 21:31:05 <psykose> i don't have any experience in embedded, but the biggest gains for more cpu flags in the subarch on desktop use is from very flag-using programs like scientific stuff or ffmpeg, to my knowledge
2021-12-09 21:31:56 <psykose> something like openrc or most system stuff doesn't really do anything anyway, so no real gains there, but overall it does make a system more usable/efficient/responsive/fast/whatever
2021-12-09 21:32:02 <psykose> it's not measured in high percentages though
2021-12-09 21:33:08 <Hello71> ffmpeg is not a candidate because it does runtime cpu detection
2021-12-09 21:33:32 <psykose> does it
2021-12-09 21:33:36 <Hello71> and the cores are all in asm anyways
2021-12-09 21:33:47 <psykose>  afaik i've seen -march=native benchmarks for it that show a clear distinction
2021-12-09 21:33:50 <psykose> but it's been a while
2021-12-10 04:45:09 <ktprograms> psykose: Good news and bad news: I've narrowed the vim problem to a 4 line vimrc, but it doesn't happen on Debian. Could be a musl vs glibc thing.
2021-12-10 04:45:31 <psykose> does it repro on edge vim in alpine
2021-12-10 04:46:01 <psykose> if so, toss me the config, i'll give it a look
2021-12-10 04:46:45 <ktprograms> psykose: Yes it does. https://tpaste.us/ovJr, put it in /etc/vim/vimrc, make sure you *do not* have ~/.vimrc, then open vim :Explore
2021-12-10 04:46:59 <psykose> why doesn't it repro inside ~/.vimrc?
2021-12-10 04:47:21 <psykose> or do you mean just so it's actually 4 lines, and not importing system
2021-12-10 04:47:25 <psykose> there's a flag for that i think
2021-12-10 04:48:20 <ktprograms> It seems that if you put a vimrc with 3 or user defined commands inside the system vimrc location (not the user vimrc location), then it segfaults when running :Explore or directly opening a directory
2021-12-10 04:49:05 <psykose> huh, yeah
2021-12-10 04:49:07 <psykose> but not with -u
2021-12-10 04:50:16 <ktprograms> psykose: Yes, and if you have even a 0 byte ~/.vimrc, then it doesn't segfault
2021-12-10 04:50:19 <psykose> passing the same system config with -u makes it /not/ segfault
2021-12-10 04:50:27 <ktprograms> psykose: Yes, that's what I found
2021-12-10 04:50:28 <psykose> with only /etc/vim/config, just -u to it fixes it
2021-12-10 04:50:31 <psykose> this is really strange
2021-12-10 04:51:00 <ktprograms> psykose: But the same reproduction steps don't cause a problem on Debian.
2021-12-10 04:51:12 <psykose> yes, probably alpine specific
2021-12-10 04:58:55 <ktprograms> psykose: Also I tested that if building vim without setting SYS_VIMRC_FILE to /etc/vim/vimrc (leaving it as the default /usr/share/vim/vimrc), it still segfaults if you put the config there
2021-12-10 04:59:19 <ktprograms> (there as in at /usr/share/vim/vimrc)
2021-12-10 04:59:20 <psykose> cursed
2021-12-10 04:59:29 <psykose> ah, ok that makes sense
2021-12-10 05:15:38 <ktprograms> psykose: How soon will a tpaste link expire?
2021-12-10 05:16:30 <psykose> no clue, no config for it https://gitlab.alpinelinux.org/alpine/infra/turbo-paste
2021-12-10 05:16:37 <psykose> if you want like 90d you can try 0x0.st
2021-12-10 05:20:11 <ktprograms> psykose: I guess I'll just try my luck with tpaste and if it gets expired before the issue is solved I'll just tpaste the vimrc again.
2021-12-10 05:20:28 <ktprograms> psykose: BTW what vim plugin manager do you use?
2021-12-10 05:20:45 <psykose> packer
2021-12-10 05:35:31 <ikke> tpaste does not expire
2021-12-10 05:43:04 <ktprograms> ikke: Really? So is it just when the url gets overriden?
2021-12-10 05:43:21 <ikke> ktprograms: did you have that happen?
2021-12-10 05:43:46 <ktprograms> ikke: No, just wondering because it's only 4 chars
2021-12-10 05:44:09 <ikke> I don't know the exact algorithm, so I don't know if they get reused
2021-12-10 05:44:31 <ktprograms> ikke: Ok, thanks for the info anyway.
2021-12-10 05:45:29 <ikke> https://hashids.org/lua/
2021-12-10 05:46:49 <ikke> so they should remain unique
2021-12-10 05:59:44 <ikke> hashids is base62, so that gives you 14776336 possibilities
2021-12-10 06:00:53 <ktprograms> ikke: makes sense. Thanks
2021-12-10 06:33:06 <ktprograms> psykose: Should I say loading the directory editor as netrw or :Explore or something else?
2021-12-10 06:41:06 <ktprograms> psykose: This happens for you on x86_64 right? So architecture doesn't seem to be the problem?
2021-12-10 06:51:27 <ktprograms> psykose: Can you please take a look at https://github.com/vim/vim/issues/9318 and let me know if I missed any info?
2021-12-10 08:43:43 <craftyguy> anyone have any ideas why CI is blowing up with "permission denied" when cleaning up after building a Go app? https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/559583
2021-12-10 08:44:49 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/nfpm/APKBUILD#L13-L14
2021-12-10 08:45:19 <craftyguy> oh that thing got merged, huh
2021-12-10 08:45:37 <ikke> What thing?
2021-12-10 08:46:27 <craftyguy> oh never mind, I was thinking of the change to disable goproxy
2021-12-10 08:46:40 <ikke> ah, no, this has nothing to do with that
2021-12-10 08:47:25 <ikke> 1) you can just set GOMODCACHE, not GOPATH, and 2, I prefer $srcdir/go, instead of $srcdir so that $srcdir does not get littered
2021-12-10 08:47:36 <craftyguy> thanks for the help, let's see if I can get a green CI now
2021-12-10 08:47:48 <craftyguy> yep, I removed GOPATH and set GOMODCACHE :)
2021-12-10 08:48:31 <craftyguy> (I actually had $srcdir/build before, but tried just $srcdir because I was completely confused why it failed)
2021-12-10 08:50:25 <craftyguy> ikke: nice, thanks for the help :)
2021-12-10 08:57:50 <ikke> go likes to make the cachedir read-only
2021-12-10 08:58:01 <ikke> so abuild fails when it tries to remove $srcdir
2021-12-10 10:39:24 <mps> could grub load DTB file? I tried with 'devicetree' directive but looks like it doesn't work
2021-12-10 11:26:08 <mps> looks like fixes for intel drm drivers is on horizon https://lore.kernel.org/dri-devel/YbIBOeqhn+nPzaYD@tursulin-mobl2/
2021-12-10 12:41:21 <donoban> Hi guys, I'm trying to enable CCCACHE with 'abuild rootbld'. I enabled USE_CCACHE, it seems that it creates a ~/.ccache dir but it is not properly bind with bwrap
2021-12-10 12:49:21 <donoban> hm, it seems that problem is before bwrap, with $SUDO_APK --initdb
2021-12-10 12:53:17 <donoban> ouch, I was confusing CCACHE with just apk packages cache
2021-12-10 12:53:28 <donoban> does anyone know how could I setup the second?
2021-12-10 13:01:45 <ikke> setup-apkcache, or just creating a symlink from /etc/apk/cache to a directory
2021-12-10 13:02:24 <donoban> yeah let's try
2021-12-10 13:03:38 <donoban> uhM, it doesn't work
2021-12-10 13:04:48 <donoban> I used setup-apkcache with /var/cache/apk and effectively there is a symlink on /etc/apk/cache
2021-12-10 13:04:59 <ikke> and?
2021-12-10 13:05:07 <donoban> but I tried to build a package twice and it downloaded all both times
2021-12-10 13:05:18 <ikke> do you see packages being placed there?
2021-12-10 13:05:36 <donoban> now I upgraded my system
2021-12-10 13:05:38 <ikke> And is the cache location available in the chroot
2021-12-10 13:05:42 <donoban> it downloaded 7 pacakges and they are effectively on the cache
2021-12-10 13:06:17 <donoban> uhm, I need to check the code for confirm it
2021-12-10 13:06:30 <donoban> but before running it in chroot
2021-12-10 13:07:07 <donoban> it does something like: apk add --initdb --update abuild alpine-base etc...
2021-12-10 13:07:12 <donoban> should it use my local apkcache?
2021-12-10 13:09:04 <ikke> Unless it mounts that directory (which I assume it would not), it does not
2021-12-10 13:10:51 <ikke> I don't see it being done
2021-12-10 13:10:59 <donoban> ok, and I could just mount it on /etc/apk/cache, no problem if it is not a symlink?
2021-12-10 13:12:19 <donoban> I have to go for a have lunch
2021-12-10 13:12:54 <donoban> thanks ikke, I will continue then
2021-12-10 13:13:16 <donoban> ouch, s/for a have/for having
2021-12-10 13:18:15 <ikke> donoban: it does not need to be a symlink, no
2021-12-10 13:59:24 <ktprograms> Hi, does anyone know if this is a known problem: https://github.com/vim/vim/issues/9318#issuecomment-990826507? (Vim segfault but only on Alpine, not reproducible on Debian)
2021-12-10 14:08:16 <ikke> It's known that the thread stack size is smaller
2021-12-10 14:09:25 <ktprograms> ikke: Would `ulimit -s unlimited` fix it? Or does it need to be done on a code level?
2021-12-10 14:10:05 <ikke> I don't know all the details, but afaik there is a global stack size and a per-thread stack size
2021-12-10 14:10:18 <ikke> and with -s I think you just change the global stack size
2021-12-10 14:10:43 <ktprograms> ikke: I see. Do you think this could be the issue?
2021-12-10 14:11:33 <ktprograms> There doesn't seem to be any Docker images with musl and arm64 that aren't Alpine. Guess I'll have to make a VM with either Void or Gentoo.
2021-12-10 14:12:06 <skarnet> if vim uses threads and segfaults with musl and not glibc, then yes, chances are it's the same old same old bug
2021-12-10 14:12:14 <skarnet> ulimit -s won't help indeed
2021-12-10 14:12:26 <skarnet> what helps is fixing vim
2021-12-10 14:12:44 <ktprograms> skarnet: In what way?
2021-12-10 14:12:47 <skarnet> with a pthread_attr_setstacksize() call before it starts spawning threads
2021-12-10 14:13:39 <skarnet> what happens in most of these programs is that they're written with the glibc assumption that default thread stacks are huge (8 MB) and so they don't bother setting the size they need
2021-12-10 14:13:50 <skarnet> but that's a bug because the standard doesn't guarantee huge stacks
2021-12-10 14:14:05 <skarnet> and musl is compliant
2021-12-10 14:14:14 <skarnet> so programs should always declare the stack size they need
2021-12-10 14:17:38 <ktprograms> skarnet: Would just putting the call to the function in main() work?
2021-12-10 14:18:50 <ktprograms> Side note, have you ever seen so much preprocessor usage just to define main(): https://github.com/vim/vim/blob/b711814cb64b60ec4918e3e1fb2ca5c50d6e9340/src/main.c#L87-L97
2021-12-10 14:21:30 <skarnet> my eyes -_-
2021-12-10 14:21:54 <ktprograms> skarnet: All Windows's fault...
2021-12-10 14:21:54 <skarnet> yeah ifdef forests are hard to read :/
2021-12-10 14:22:25 <skarnet> and yes, putting the pthread_attr_setstacksize() call in main() would work
2021-12-10 14:22:53 <skarnet> depending on how threads are called it may require a bit more work, e.g. if thread creation does not already declare a pthread_attr_t, etc.
2021-12-10 14:23:06 <skarnet> or if thread creation is buried under 4 layers of wrappers
2021-12-10 14:23:13 <valerius> ifdef forests... going to steal that terminology from you
2021-12-10 14:23:16 <skarnet> which is very possible if there's Windows compatibility
2021-12-10 14:23:28 <skarnet> it's not mine, it's a classic :)
2021-12-10 14:24:16 <ktprograms> skarnet: What is the size of pthread_attr_t?
2021-12-10 14:26:16 <skarnet> I don't know, but nobody should care
2021-12-10 14:26:30 <skarnet> (it's a system thing, it's small)
2021-12-10 14:26:46 <ktprograms> skarnet: How do I get the thread stacksize? What pthread_attr_t should I pass to pthread_attr_getstacksize ?
2021-12-10 14:27:32 <skarnet> you don't need getstacksize() :) you just need setstacksize
2021-12-10 14:27:41 <skarnet> it goes something like this:
2021-12-10 14:27:49 <ktprograms> skarnet: Out of intereset I want to know the stack size by default
2021-12-10 14:28:00 <ktprograms> s/intereset/interest
2021-12-10 14:28:00 <alpine-meetbot> ktprograms meant to say: skarnet: Out of interest I want to know the stack size by default
2021-12-10 14:28:17 <skarnet> makes sense
2021-12-10 14:29:08 <ktprograms> skarnet: giving up on getting the stack size, but what should I pass for the first arg to pthread_attr_setstacksize?
2021-12-10 14:29:19 <ktprograms> Where do I get 'pthread_attr_t *attr'?
2021-12-10 14:29:46 <skarnet> pthread_attr_t attr ; size_t size ; int e = pthread_attr_init(&attr) ; if (e) gtfo() ; e = pthread_attr_getstacksize(&size) ; if (e) gtfo() ; printf("size is %zu\n", size) ;
2021-12-10 14:30:32 <skarnet> s/pthread_attr_getstacksize(&size)/pthread_attr_getstacksize(&attr, &size)/
2021-12-10 14:30:32 <alpine-meetbot> skarnet meant to say: pthread_attr_t attr ; size_t size ; int e = pthread_attr_init(&attr) ; if (e) gtfo() ; e = pthread_attr_getstacksize(&attr, &size) ; if (e) gtfo() ; printf("size is %zu\n", size) ;
2021-12-10 14:30:53 <skarnet> you declare a pthread_attr_t in the stack and initialize it with pthread_attr_init()
2021-12-10 14:30:59 <skarnet> then you do whatever you want with it
2021-12-10 14:31:02 <ktprograms> skarnet: Ah I see.
2021-12-10 14:31:19 <skarnet> give it to pthread_attr_destroy() when you're done with it
2021-12-10 14:32:43 <ktprograms> skarnet: outputs that the stack size is 131072, does that sound about right?
2021-12-10 14:33:04 <ktprograms> skarnet: If I set the stack size in main, will it be kept even if the attr is never used again?
2021-12-10 14:33:26 <skarnet> it's possible, I thought it was 80k on musl but ISTR there was a plan to bump it, so maybe it was bumped to 128k indeed and it would be right
2021-12-10 14:34:13 <skarnet> and no, the &attr must be used as an argument to pthread_create()
2021-12-10 14:34:43 <skarnet> basically a pthread_attr_t is a struct that gathers configuration data for thread creation
2021-12-10 14:35:13 <skarnet> you call pthread_attr_foobar for all the foobars you want, and then you pass &attr to pthread_create() and your thread is created with all the configuration you just did
2021-12-10 14:35:16 <skarnet> including stack size
2021-12-10 14:37:11 <skarnet> so basically the fix is: 1. find where a program calls pthread_create() ; 2. check whether it uses a pthread_attr_t or NULL ; 2a. call pthread_attr_setstacksize() on the existing pthread_attr_t so all threads are created with the correct value, or 2b. declare a pthread_attr_t, set the stack size, and modify the pthread_create() invocation so that attr is used instead of NULL
2021-12-10 14:37:49 <skarnet> NULL is when you don't have any special configuration to do and you're okay with creating threads with all the default values
2021-12-10 14:38:52 <skarnet> which people often do because it's simpler and most of the time the defaults are good, but if you're assuming megabytes of thread stack, the defaults are not good even if glibc provides those megabytes
2021-12-10 14:45:23 <ktprograms> skarnet: I don't see any pthread_create in vim source code: https://github.com/vim/vim/search?q=pthread_create&type=code only shows one use in vim runtime vimscript files.
2021-12-10 14:47:27 <ktprograms> skarnet: Thanks for the explanation about the pthread_attr_t
2021-12-10 14:47:33 <skarnet> yeah, a search for pthread.h doesn't return much either, so apparently vim doesn't use pthreads. It doesn't use C11 threads either.
2021-12-10 14:47:51 <skarnet> So if it's single-threaded, then the segfault has to come from somewhere else.
2021-12-10 14:53:19 <ktprograms> skarnet: So do you have any idea what could be causing the segfault? Apparently ASAN isn't available for musl, so how are segfaults supposed to be debugged?
2021-12-10 14:56:28 <skarnet> I have no idea. Chances are it's still vim doing something wrong rather than musl; what I would do is asan or valgrind it on a glibc machine, see what it says.
2021-12-10 14:57:36 <skarnet> if valgrind says everything is fine, then it may be a musl problem.
2021-12-10 14:59:01 <ktprogra1s> skarnet: Ok, I'll try that tomorrow. Bye!
2021-12-10 15:46:48 <Sam_> Hi Folks,
2021-12-10 15:47:13 <Guest8160> Is Alpine linux impacted by https://www.cve.org/CVERecord?id=CVE-2021-44228  ?
2021-12-10 15:53:12 <ikke> Guest8160: We don't have log4j itself in the repositories as far as I know
2021-12-10 15:58:29 <nero> heh, this is the kind of software java people would come up with
2021-12-10 15:58:44 <nero> they cant use syslog-based systems because the java stacktraces are too big for them
2021-12-10 16:03:15 <nero> to answer the question, alpine only has client libraries, not log4j itself
2021-12-10 16:06:42 <dalias> this log4j thing is a clowncar
2021-12-10 16:07:51 <dalias> why do languages continually reinvent this stupid antipattern of "serialized object deserializes to data+code for its class"
2021-12-10 16:08:00 <dalias> it's ALWAYS WRONG
2021-12-10 16:09:05 <dalias> the whole point of serialization is to store/exchange/marshall the data across [privilege] domains where sharing code is a complete non-starter
2021-12-10 16:14:41 <Hello71> actually this is not a deserialization vuln for once
2021-12-10 16:15:12 <ikke> it's an injection vuln
2021-12-10 16:15:14 <Hello71> er, well, it's half of one??
2021-12-10 16:15:19 <Hello71> s/\?//
2021-12-10 16:23:55 <dalias> hello71, isn't it?
2021-12-10 16:25:49 <Hello71> well the first stupid feature is that interpolation sequences are interpreted even with parameterized output
2021-12-10 16:26:14 <Hello71> the second stupid feature is that certain interpolation sequences can silently download network resources
2021-12-10 16:27:47 <Hello71> and the third part (which is apparently the only part considered a "bug") is that under certain conditions, the network resource is downloaded and executed
2021-12-10 16:30:52 <Guest8160> dalias: "clowncar" is well phrased. 
2021-12-10 16:31:09 <Hello71> actually, no, that's not right. https://www.lunasec.io/docs/blog/log4j-zero-day/
2021-12-10 17:28:34 <ikke> https://blogs.gentoo.org/mgorny/2021/11/07/the-future-of-python-build-systems-and-gentoo/
2021-12-10 17:38:38 <ericonr> ikke: python just loves bikeshedding packaging to worse and worse solutions :/
2021-12-10 18:17:16 <ikke> ericonr: nod
2021-12-10 18:22:31 <donoban> ikke: I added this https://gitlab.alpinelinux.org/donoban/abuild/-/commit/e2be4dd90d50f09669210ebe33719ea1eb6154b8 and seems working properly
2021-12-10 18:23:26 <donoban> I would send a MR but I don't see the option for doing it
2021-12-10 18:23:30 <skarnet> ikke: "Unfortunately, there seems to be very little concern on (sic) distribution packagers" -> summary of langtech for the past 10 years
2021-12-10 18:24:36 <ikke> donoban: wouldn't that create a recursive symlink?
2021-12-10 18:25:15 <donoban> hM, I tested it without problems
2021-12-10 18:26:23 <donoban> do you mean that the symlink points to itself inside the chroot?
2021-12-10 18:27:46 <mps> if you make something to work smoothly and without problems you don't look as smart but if you make something which forces people to tear hairs and you have solution you look super smart
2021-12-10 18:28:34 <mps> re python: https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2021-12-10 18:33:58 <Ariadne> i realized that as a result of porting apk to run on macOS, i could replace homebrew
2021-12-10 18:34:03 <Ariadne> somebody please talk me out of this
2021-12-10 18:34:51 <knolle> you should do it
2021-12-10 18:34:55 <skarnet> has anyone successfully talked you out of anything that tickled your interest?
2021-12-10 18:36:47 <mps> 'if you want something to be done tell children they must not do that' :)
2021-12-10 18:40:42 <ikke> Anyone an idea what to do with firefox-esr
2021-12-10 18:43:02 <mps> ikke:  clang-12: error: linker command failed with exit code 1 (use -v to see invocation) ?
2021-12-10 18:43:26 <mps> what that means? it is built with clang now?
2021-12-10 18:43:37 <ikke> undefined reference to `wl_proxy_marshal_flags'
2021-12-10 18:45:05 <ikke> I guess
2021-12-10 18:45:52 <mps> ah, it fails on all arches
2021-12-10 18:46:51 <ikke> yes
2021-12-10 19:00:45 <mps> wayland-client-protocol.h:5983: more undefined references to `wl_proxy_marshal_flags' follow
2021-12-10 19:02:20 <mps> is this related to upgraded wayland
2021-12-10 19:02:28 <ikke> I found this earlier: https://bugs.gentoo.org/811840
2021-12-10 19:03:15 <ikke> Ariadne mentioned that wayland was upgraded and that it should be upgraded / rebuilt together
2021-12-10 19:03:29 <ikke> with wayland-protocols
2021-12-10 19:03:45 <ikke> I've rebuilt wayland-protocols, but that does not fix it
2021-12-10 19:03:57 <Ariadne> uhh
2021-12-10 19:03:59 <Ariadne> there's like
2021-12-10 19:04:03 <Ariadne> a wayland-protocol-scanner
2021-12-10 19:04:04 <Ariadne> or something
2021-12-10 19:04:09 <Ariadne> that probably also has to be updated
2021-12-10 19:04:20 <Ariadne> those .h files are generated from XML files
2021-12-10 19:04:32 <mps> uff
2021-12-10 19:05:31 <ikke> https://wayland-book.com/libwayland/wayland-scanner.html
2021-12-10 19:05:50 <ikke> part of wayland-dev
2021-12-10 19:06:35 <Ariadne> perhaps wayland-protocols needs updating ?
2021-12-10 19:06:56 <mps> iirc ikke upgraded it
2021-12-10 19:07:06 <Ariadne> there is #wayland
2021-12-10 19:07:10 <Ariadne> maybe lets ask there :)
2021-12-10 19:08:53 <mps> not me, I'm not interested in wayland, and would like it never happened
2021-12-10 19:09:18 <ikke> wayland-protocols is already the last version as far as I can tell
2021-12-10 19:11:13 <mps> https://wayland.freedesktop.org/releases/
2021-12-10 19:11:23 <ikke> 404
2021-12-10 19:11:44 <ikke> .html exists
2021-12-10 19:11:44 <Ariadne> 1:09 PM <Ariadne> in alpine, a contributor submitted a package update for the latest wayland version (1.20.0), and now we are having a lot of problems with wl_proxy_marshal_flags missing.
2021-12-10 19:11:44 <Ariadne> 1:09 PM <Ariadne> we upgraded wayland-protocols already
2021-12-10 19:11:44 <Ariadne> 1:09 PM <Ariadne> am i missing something?
2021-12-10 19:11:47 <Ariadne> for reference
2021-12-10 19:11:57 <ikke> Ariadne: thanks
2021-12-10 19:12:01 <ikke> I joined there as well
2021-12-10 19:12:53 <mps> wayland is released yesterday but protocols release is lagging behind, my conclusion
2021-12-10 19:13:59 <mps> I could be wrong ofc
2021-12-10 19:15:43 <craftyguy> I think some edge builders need to be kicked, seems like they're stuck on some failed firefox-esr build attempt
2021-12-10 19:17:13 <craftyguy> specifically, ppc, aarch64 and armv7
2021-12-10 19:17:14 <ikke> craftyguy: firefox-esr needs to be fixed, which we are working on
2021-12-10 19:17:24 <ikke> They are not stuck, just failing every time
2021-12-10 19:17:31 <craftyguy> ah ok, sorry for the noise then :)
2021-12-10 19:17:50 <skarnet> I am not stuck on this test! I am just failing it every time!
2021-12-10 19:17:56 <craftyguy> heh
2021-12-10 20:25:12 <Ariadne> aparcar: https://usercontent.irccloud-cdn.com/file/3xwIVXOD/image.png
2021-12-10 21:02:30 <ikke> mps: !27546
2021-12-10 21:04:37 <mps> ikke: I'm busy with other useless tasks :)
2021-12-10 21:05:07 <ikke> heh, do you think it can be merged?
2021-12-10 21:05:26 <ikke> (if you're too busy to tell, no worry)
2021-12-10 21:07:10 <mps> ikke: I promise you that I will look tomorrow, if I don't you are free to slap me with big trout ;)
2021-12-10 21:07:31 <mps> I need also to fix cups MR
2021-12-10 21:20:20 <Hello71> there is already new cups MR
2021-12-10 21:20:56 <mps> Hello71: which one
2021-12-10 21:21:10 <Hello71> er, i mean there are two now
2021-12-10 21:21:39 <ikke> !28330 !28176
2021-12-10 21:22:42 <mps> ah, this one looks more clean than mine. good and thanks. you saved me some time
2021-12-10 21:23:17 <mps> though commit msg of this new one looks bad
2021-12-10 21:38:18 <aparcar> Ariadne: amazing!
2021-12-10 21:38:22 <aparcar> I just saw this
2021-12-10 21:38:36 <aparcar> great work, I expected the MacOS journey to take weeks 
2021-12-10 21:42:00 <Habbie> hey aparcar :)
2021-12-10 21:42:12 <Habbie> fun to see this happening in stereo
2021-12-10 21:43:12 <aparcar> Oh hey there
2021-12-10 21:43:53 <Ariadne> aparcar: well, there is no facility for emulating linux programs, so chroot scripts will not work :)
2021-12-10 21:44:50 <aparcar> Ariadne: for now OpenWrt won't use chroot anyway :P Not my ideal solution but I think nobody wants to loose the MacOS support for now
2021-12-10 21:45:21 <Ariadne> however, there is more potential in this
2021-12-10 21:45:23 <Ariadne> for example
2021-12-10 21:45:26 <aparcar> Ideally we'd use a real "jail" or something for building. User scripts from packages can technically compromise a users system
2021-12-10 21:45:28 <Ariadne> we can make homebrew die
2021-12-10 21:45:29 <Ariadne> :D
2021-12-10 21:45:56 <aparcar> I thought nixos is about to put salt into the brewing?
2021-12-10 21:46:05 <Ariadne> homebrew is basically the reason why i do not use this mac for anything serious
2021-12-10 21:46:15 <Ariadne> yeah, well, nix is nix
2021-12-10 21:46:28 <aparcar> I don't know nix, just gossip 
2021-12-10 21:46:52 <Ariadne> i think what most people want is something easy, nix is not
2021-12-10 21:47:09 <Ariadne> curl ... | bash; apk add whatever
2021-12-10 21:47:11 <Ariadne> now that's easy
2021-12-10 21:47:13 <Ariadne> :p
2021-12-10 21:47:35 <ikke> Ariadne: curl | sudo bash :P
2021-12-10 21:48:27 <eris[m]> nix is super annoying
2021-12-10 21:49:00 <Ariadne> ikke: as a security professional, i have more sense than to do a curl ... | bash, much less a curl ... | sudo bash
2021-12-10 21:49:20 <ikke> :)
2021-12-10 21:49:33 <psykose> curl | bash is not any different from downloading and running random files, yet for some reason it's always talked about more than the latter :p
2021-12-10 21:50:05 <aparcar> well I'm happy to see APK taking over
2021-12-10 21:59:54 <Ariadne> i think it’s gonna be really neat to be able to use whatever tooling you want to build packages for any apk-based OS
2021-12-10 22:07:37 <aparcar> Ariadne: are you aware of handling "alternatives" within APK? For example if you install both busybox and coreutils-chown, the latter should be preferred. OPKG does so by using symlinks
2021-12-10 22:08:29 <aparcar> OPKG does so via https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/pkg_alternatives.c;h=24efedfd36576588467407b13bced862a73ad992;hb=refs/heads/master
2021-12-10 22:08:34 <Hello71> apk doesn't.
2021-12-10 22:08:34 <Ariadne> it’s been discussed but never actually implemented
2021-12-10 22:09:05 <Ariadne> i think personally alternatives is out of scope for apk, better to write a generic implementation
2021-12-10 22:16:07 <aparcar> In that case it could be useful to generically stores variables in the database
2021-12-10 22:16:50 <aparcar> if there are no strong objections I'd implement something, symlinks seem to be fairly generic
2021-12-10 22:18:24 <ikke> Note that at least in the case of busybox, the way it's setup in alpinelinux already means that the you can just install the original versions of tools and it automatically replaces the bb variant
2021-12-10 22:19:22 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/busybox.trigger#L22
2021-12-10 22:21:37 <aparcar> ikke: sure but then there is openssh and dropbear
2021-12-10 22:21:51 <aparcar> and I'm sure some more fun corner cases we didn't think about 
2021-12-10 22:21:58 <aparcar> neovim, vim, vi
2021-12-10 22:22:01 <ikke> yes
2021-12-10 22:25:26 <Hello71> but dropbear doesn't provide /usr/sbin/sshd, even on debian
2021-12-10 22:25:41 <aparcar> but scp I think
2021-12-10 22:26:50 <Hello71> hm.
2021-12-10 23:42:13 <Hello71> ikke: was !28336 recommended by wayland?
2021-12-10 23:45:57 <Hello71> i'm pretty sure it will cause wayland to not work at all
2021-12-11 00:01:33 <psykose> it works, i tested the build artifact
2021-12-11 00:06:03 <psykose> and the stub function was recommended by emersion, should be fine
2021-12-11 00:06:11 <psykose> hopefully firefox fixes it themselves by next release
2021-12-11 00:06:42 <Hello71> hm. am confused but ok
2021-12-11 00:07:14 <emersion> yes, confusion is to be expected
2021-12-11 00:07:36 <psykose> and firefox doesn't link against libwayland-client.so as well, it dlopens it pretty sure
2021-12-11 00:07:39 <psykose> so all this does is fix the build
2021-12-11 00:07:49 <emersion> yup
2021-12-11 00:08:16 <emersion> firefox has stubs for libwayland functions, which are overriden on dlopen
2021-12-11 00:15:21 <psykose> in other build failure news x86_64 3.15 crashed on qtwebengine, since it's signal it sounds like it would be oom but i don't see how that would even be possible
2021-12-11 00:30:49 <Hello71> emersion: how did it work before 1.20?
2021-12-11 00:31:02 <Hello71> psykose: chromium too fat
2021-12-11 00:31:26 <psykose> it's certainly fat, but doesn't the builder have over 100G even
2021-12-11 00:31:30 <psykose> i am just perplexed
2021-12-11 00:31:44 <Hello71> depends on what other builds running simultaneously
2021-12-11 00:33:02 <psykose> Hello71: we haven't found a root cause yet on why it still works on 1.19
2021-12-11 00:33:13 <psykose> grepping for wayland in the source doesn't seem to have anything super obvious
2021-12-11 00:34:51 <psykose> funnily, our attempt to fix it by rebuilding wayland-protocols now seems to be mentioned in the gentoo thread, even though it didn't fix it https://bugs.gentoo.org/811840
2021-12-11 00:42:27 <ktprograms> Ariadne: (re apk on mac): What about using sandbox-exec(1) for securely building packages? It appears that you can have fine grained control over r/w/x on a per-directory basis, and can also block network, etc. It seems to be more meant for Apple internal services and techincally in the manpage it says is deprecated, but it seems to still be working fine according to articles on the internet. The 
2021-12-11 00:42:28 <alpine-meetbot> No such subreddit.
2021-12-11 00:42:33 <ktprograms> simple config I got in about 10 mins of fiddling is https://tpaste.us/ov9n, put it in config.sb and run 'sandbox-exec -f config.sb /bin/zsh'. You can then run any binary in /bin, and read any files allowed in /System/Library/Sandbox/Profiles/bsd.sb and /System/Library/Sandbox/Profiles/system.sb. FYI .sb files are a dialect of Scheme apparently.
2021-12-11 00:44:53 <psykose> using something marked as deprecated for a new project seems a bit on the nose for modern software development
2021-12-11 00:48:00 <ktprograms> psykose: There's no other choice since bind mounts on macos require osxfuse which is closed source and in order to prevent network access the next best way is making an entire app and signing that with restrictive entitlements. This way doesn't require installing anything and it also allows for a chroot-like environment without requiring root (of course then in the sandboxed zsh you're still the 
2021-12-11 00:48:06 <ktprograms> same user, but if you sudo sandbox-exec ... then it switches to root).
2021-12-11 00:50:15 <ktprograms> skarnet: FYI thanks to Hello71 debugging the Vim memory problems, it's been fixed already.
2021-12-11 00:50:23 <Hello71> yes, i saw
2021-12-11 00:51:22 <Hello71> although i believe skarnet already suggested using valgrind
2021-12-11 00:51:39 <psykose> ktprograms: and i got my 15 hours of sleep in the meantime :p sorry
2021-12-11 00:52:12 <ktprograms> Would it be ok if I upgrade Vim in aports to v8.2.3779 (latest as of now and it fixes the segfault)? Do I have to test all the functionality changed between current in Alpine and latest Vim or just a quick test that most core functionality works?
2021-12-11 00:52:45 <psykose> it should be fine
2021-12-11 00:52:48 <ktprograms> Hello71: So valgrind works on musl? I'm very unfamiliar with this sort of tools.
2021-12-11 00:53:06 <psykose> valgrind just checks memory stuff, so yeah
2021-12-11 00:53:10 <ktprograms> Hello71: Also what options did you use with valgrind? Just for my future reference
2021-12-11 00:53:19 <Hello71> none
2021-12-11 00:53:21 <ktprograms> psykose: Ok, thanks
2021-12-11 00:53:42 <ktprograms> Hello71: I see. Thanks
2021-12-11 00:59:34 <emersion> Hello71: a new function was introduced in 1.20. the firefox stub is misisng it.
2021-12-11 00:59:52 <Hello71> ah, i see. sounds obvious when you put it that way :p
2021-12-11 01:00:16 <Hello71> but wait, how does it bind the functions at runtime then?
2021-12-11 01:07:35 <ktprograms> Is there a way to make 'apk list' show which version comes from which repository?
2021-12-11 01:08:57 <boomanaiden154> apk policy?
2021-12-11 01:10:05 <ktprograms> boomanaiden154: Ah thanks. Didn't know about that
2021-12-11 03:41:01 <Ariadne> ktprograms: idk.  atm i am just getting enough working so openwrt people can do apk things on openwrt
2021-12-11 04:34:20 <ktprograms> Ariadne: What does openwrt have to do with macos?
2021-12-11 04:34:40 <Ariadne> ktprograms: openwrt supports building images (via cross-compilation) on macos
2021-12-11 04:35:03 <Ariadne> and, openwrt is switching to apk3
2021-12-11 04:36:45 <ktprograms> Ariadne: I see.
2021-12-11 05:29:14 <skarnet> alpine-meetbot, you're a gem, never change.
2021-12-11 05:29:17 <skarnet> r/w/x
2021-12-11 05:29:17 <alpine-meetbot> No such subreddit.
2021-12-11 06:24:49 <ktprograms> There is a small problem in Alpine's packaging of Vim that /etc/vim/vimrc is used as the system vimrc location, but /etc/vim isn't in runtimepath, so (for example) you can't put the vim-plug autoload file in /etc/vim/autoload/plug.vim.
2021-12-11 06:28:53 <anjan> hi all, I ran into an issue with nm-applet and alpine
2021-12-11 06:28:54 <anjan> https://wiki.gentoo.org/wiki/NetworkManager#Fixing_nm-applet_insufficient_privileges
2021-12-11 06:28:56 <anjan> this fixed it
2021-12-11 06:29:37 <anjan> can I send a MR to add that config to networkmanager?
2021-12-11 06:49:28 <ikke> Hello71: yes
2021-12-11 07:17:52 <ikke> Hello71: THey did recommend reporting this to mozilla, though
2021-12-11 08:30:53 <ktprograms> ncopa: Can you please merge !28341 soonish? It updates Vim to a version that fixes a segfault.
2021-12-11 08:41:06 <mps> ktprograms: you tested it?
2021-12-11 08:41:59 <ktprograms> mps: Have been since this morning as the installed vim. Basic stuff works, vim-plug works, vim-airline works etc
2021-12-11 08:42:21 <mps> ok, will merge it now
2021-12-11 08:42:56 <mps> done
2021-12-11 08:43:31 <ktprograms> mps: Thanks
2021-12-11 08:43:38 <mps> never had issues with vim
2021-12-11 08:43:42 <mps> ktprograms: np
2021-12-11 08:55:37 <ktprograms> PureTryOut: Should akonadi also depend on qt5-qtbase-postgresql? The build seems to be failing with not being able to find libqsqlpsql.so. (The only reason I'm looking at this is I happened to look at build.alpinelinux.org)
2021-12-11 08:56:51 <ktprograms> mps: It was a very funny issue. If you had 3 or more user defined commands in the **system vimrc location** and you opened netrw, it would segfault _unless_ you explicitly specified vim to use the system vimrc (which it was already doing) OR ~/.vimrc existed.
2021-12-11 08:58:22 <mps> ktprograms: interesting. I don't use much plugins (just 3) so didn't had this problem
2021-12-11 08:59:43 <ktprograms> mps: The interesting thing was it didn't have anything to do with plugins, even using https://tpaste.us/ovJr as the vimrc would segfault when netrw was opened. (All that vimrc has is setting nocompatible and defining 3 commands).
2021-12-11 09:00:36 <PureTryOut> ktprograms: seems like it, just like it just now needed qt5-qtbase-odbc. I don't understand CI succeeded on it but oh well
2021-12-11 09:07:25 <ktprograms> How quickly is dl-4.alpinelinux.org updated from the master package repo?
2021-12-11 09:08:09 <psykose> the up to dateness is here https://mirrors.alpinelinux.org/
2021-12-11 09:08:14 <psykose> as for how often it syncs, i dunno
2021-12-11 09:08:25 <psykose> sometimes it just desynced for a day or two in my experience
2021-12-11 09:08:31 <psykose> sometimes it's 1 hour
2021-12-11 09:08:54 <ktprograms> psykose: So I should still be using dl-cdn as the mirror if I need to test packages as soon as they're done being built?
2021-12-11 09:09:20 <psykose> you can download the artifact from the ci run and install it there, though that is not the exact same as from the builders i guess
2021-12-11 09:09:23 <psykose> and sure
2021-12-11 09:09:41 <ktprograms> psykose: Ok thanks
2021-12-11 09:13:29 <mps> ktprograms: packages are uploaded when build finishes for particular repo
2021-12-11 09:13:38 <mps> not one by one
2021-12-11 09:14:17 <mps> you can join #alpine-commits and look
2021-12-11 09:14:34 <ktprograms> mps: Oh I see. That explains why vim is updated only for certain archs right now
2021-12-11 09:18:03 <ktprograms> PureTryOut: akonadi needs qt5-qtbase-tds too it seems.
2021-12-11 09:41:56 <PureTryOut> ffs. I'm not at a PC atm so someone else has to do ot
2021-12-11 09:41:58 <PureTryOut> *it
2021-12-11 09:42:26 <ktprograms> PureTryOut: I could do it but can you merge it?
2021-12-11 09:43:07 <PureTryOut> no sorry, not logged in on Gitlab on mobile
2021-12-11 09:43:14 <ikke> I can
2021-12-11 09:43:14 <PureTryOut> but another dev here can do it
2021-12-11 09:44:10 <ktprograms> ikke: As in you'll just do the commit? If you're doing that you might as well look through the cmake file and see what other deps are needed.
2021-12-11 09:44:29 <ikke> I'm a bit busy, but I can merge it
2021-12-11 09:46:02 <ktprograms> ikke: Ok.
2021-12-11 10:15:13 <ktprograms> ikke: !28348
2021-12-11 10:29:39 <ikke> merged
2021-12-11 11:07:42 <ikke> PureTryOut: ktprograms seems like more packages are failing
2021-12-11 11:08:27 <ktprograms> ikke: And it's the same sort or error. Was qt5 sql stuff updated recently?
2021-12-11 11:08:33 <ktprograms> s/or/of
2021-12-11 11:08:33 <alpine-meetbot> ktprograms meant to say: ikke: And it's the same soft or error. Was qt5 sql stuff updated recently?
2021-12-11 11:08:40 <ktprograms> s/soft/sort
2021-12-11 11:08:40 <alpine-meetbot> ktprograms meant to say: ikke: And it's the same sort or error. Was qt5 sql stuff updated recently?
2021-12-11 13:48:55 <Hello71> something is wrong with the deps, qt5-qtbase-dev should pull in qt5-qtbase-mysql
2021-12-11 13:49:02 <Hello71> i'm looking into it
2021-12-11 13:49:20 <ikke> Ik ga niet zomaar core routers rebooten
2021-12-11 13:49:22 <ikke> 👍
2021-12-11 13:49:27 <ikke> wrong paste :P
2021-12-11 13:59:25 <Hello71> it must be somehow related to 8ee3cb9f67875164cf603dceee1d45ce2547b227 but i have no idea how
2021-12-11 14:03:55 <Hello71> it is true that qt5-qtbase-dev lost dep on qt5-qtbase-mysql, both in ci and on builders, but idk how (yet?)
2021-12-11 14:06:28 <Hello71> ikke: what to do about qt5-qtwebengine? it is OOM
2021-12-11 14:06:40 <ikke> Where?
2021-12-11 14:10:43 <Hello71> https://build.alpinelinux.org/buildlogs/build-3-15-x86_64/community/qt5-qtwebengine/qt5-qtwebengine-5.15.3_git20211127-r1.log
2021-12-11 14:33:20 <ikke> not sure what to do about it if it can exhaust 64G of mem
2021-12-11 14:33:45 <ikke> other than limiting the amount of jobs being used (if it's not during link time
2021-12-11 14:57:54 <minimal> mps: are you familiar with Xen? am trying to work out for a domU using linux-virt which drivers must be compiled into kernel versus can be built as loadable modules
2021-12-11 15:05:07 <Hello71> shouldn't it be none? doesn't xen support initrd?
2021-12-11 15:08:03 <ikke> Hello71: qt5-qtwebengine passed now
2021-12-11 15:08:34 <Hello71> did you do something?
2021-12-11 15:08:37 <ikke> no
2021-12-11 15:08:49 <mps> minimal: no, I'm not. had to use it only once on gandi.net cloud. there alpine linux-virt worked
2021-12-11 15:08:50 <ikke> maybe it ran together with another expensive build
2021-12-11 15:09:56 <minimal> mps: I'm assuming that a dom0 uses linux-lts (as a dom0 is supposed to run on bare metal) and domU uses linux-virt
2021-12-11 15:09:57 <mps> and that was two years when I removed it
2021-12-11 15:10:41 <mps> minimal: I forgot details but I'm sure linux-virt worked fine
2021-12-11 15:11:12 <minimal> Hello71: that's what I'm not sure about, whether some of the Xen drivers (i.e. display) *need* to be compiled into kernel (as some are currently for linux-virt) or not - I'm working on my MR to reduce linux-virt modules :-)
2021-12-11 15:54:20 <Hello71> qt stuff should be fixed by !28357
2021-12-11 15:55:12 <ikke> PureTryOut: ^
2021-12-11 16:12:07 <ikke> Hello71: just wondering, why did you keep qt5-qtbase-mysql in the depends of anakonda
2021-12-11 16:12:14 <Hello71> akonadi?
2021-12-11 16:12:19 <ikke> yes
2021-12-11 16:12:24 <ikke> same for sqlite
2021-12-11 16:12:34 <Hello71> it was there before, i think it is actually required
2021-12-11 16:13:18 <ikke> ok
2021-12-11 16:13:58 <Hello71> from memory and google, i think akonadi has mysql and sqlite backend
2021-12-11 16:18:22 <PureTryOut> yeah applications using a specific backend need them explicitely in their depends
2021-12-11 16:18:44 <PureTryOut> thanks for fixing it Hello71, I was wondering why this was suddenly happening while CI had no such problems
2021-12-11 16:19:24 <Hello71> the perils of rebasing
2021-12-11 16:20:20 <Hello71> (and the benefits of a bors-like merge bot)
2021-12-11 16:20:40 <ikke> What does that do?
2021-12-11 16:22:03 <Hello71> hm, i guess our current "merge after ci succeeds" is technically isomorphic. the problem is that ci uses packages from builders, which may be delayed
2021-12-11 16:24:27 <Hello71> i think possibly the best solution is to have CI issue a warning if the modified packages (transitively?) depend on packages which are currently being built on the builders
2021-12-11 16:27:32 <ikke> That's not trivial to determine though
2021-12-11 16:28:21 <Hello71> well, we don't actually need to determine what the builders are doing
2021-12-11 16:28:57 <Hello71> just compare the versions of the modified packages' transitive dependencies in git and on the apk repository
2021-12-11 16:30:12 <Hello71> if any are not matching, then either the builders have not finished, or the mirror is out of sync, which is an equivalent problem in this context
2021-12-11 16:32:18 <Hello71> or, equivalently, take the list of packages that abuild buildrepo (?) would build, and then take the set intersection with the modified packages' dependencies
2021-12-11 16:34:21 <ikke> You need the actual repo for that last one
2021-12-11 16:34:26 <ikke> not just the index
2021-12-11 16:35:24 <Hello71> you mean to run buildrepo?
2021-12-11 16:36:04 <Hello71> i don't know what is the best way to implement it, but assuming i haven't missed anything, it seems pretty simple conceptually
2021-12-11 16:36:39 <ikke> yes, and by extension ap build-list
2021-12-11 16:39:39 <Hello71> i guess the problem is that the builders do not exclusively use version to determine which packages to build?
2021-12-11 16:40:45 <ikke> It determines what apk files should exist based on the APKBUILDs and builds every package that is missing
2021-12-11 16:45:06 <Hello71> but this is fundamentally information that exists in the APKINDEX, right? it's just that the current utilities use the actual files, not the index
2021-12-11 16:45:50 <ikke> Yes, I think so
2021-12-11 16:46:14 <ikke> It could be as a precaution to make sure that the actual apkfiles exist
2021-12-11 16:46:26 <ikke> if an apk file is removed, it should be rebuilt
2021-12-11 16:46:54 <ikke> not assumed to exist just because the index says so
2021-12-11 16:57:05 <Hello71> mm.
2021-12-11 17:50:24 <Hello71> why doesn't alpine-gitlab-ci/build-base set up apk cache?
2021-12-11 17:50:37 <Hello71> i guess alpine-gitlab-ci
2021-12-11 17:51:12 <ikke> Hello71: Just to not have to deal with cleaning it up
2021-12-11 17:51:39 <ikke> Or do you maen just for withing a single CI job?
2021-12-11 17:51:44 <Hello71> mmhmm
2021-12-11 17:53:50 <Hello71> i have a dumb idea to avoid touching lua-aports: comm <(ap apk-list) $(cd /var/cache/apk; ls)
2021-12-11 17:53:56 <Hello71> s/\$/</
2021-12-11 17:55:40 <Hello71> comm -13, if non-empty then we used some apks inconsistent with mirror, so raise warning
2021-12-11 17:56:00 <ikke> https://pkg.go.dev/gitlab.alpinelinux.org/alpine/go#section-readme
2021-12-11 18:00:48 <Hello71> not sure using go is cleaner
2021-12-11 18:01:39 <Hello71> i think this is a good solution, it precisely tracks exactly which apks were used during build
2021-12-11 18:02:07 <Hello71> the only catch is it needs cache to be enabled, and it needs to filter out APKINDEX
2021-12-11 18:03:25 <ikke> but the cache needs to be persistent
2021-12-11 18:04:06 <ikke> and technically there is no guarantee each job runs on the same host
2021-12-11 18:05:13 <Hello71> what do you mean?
2021-12-11 18:05:32 <ikke> We could add more runners per arch
2021-12-11 18:05:51 <ikke> then each job can run on a different host
2021-12-11 18:06:06 <Hello71> if each job runs independently, then it also fetches the deps independently
2021-12-11 18:06:08 <ikke> You would need to synchronize the cache on each host
2021-12-11 18:06:59 <ikke> or does it not matter /etc/apk/cache is removed after each job?
2021-12-11 18:07:03 <ikke> matter if*
2021-12-11 18:07:36 <Hello71> i specifically want to track which packages were fetched in order to complete a job. to do this, i assume that the cache starts empty, then as packages are built, the cache is populated. at the end, the contents of the cache are the packages which were fetched to build the aports changed in the MR
2021-12-11 18:10:43 <Hello71> concretely, at the very end of https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh, add a line roughly like this: old_apks_used=$(comm -13 <(ap apk-list) <(cd /var/cache/apk; ls)); if [ -n "$old_apks_used" ]; then echo "some apks used in the build were not up-to-date on the mirror: $old_apks_used"; fi
2021-12-11 18:10:55 <ikke> You'd need to do that for each repository
2021-12-11 18:11:05 <Hello71> yes, and also busybox sh doesn't have process substitution
2021-12-11 18:11:35 <ikke> Ok, I understand now how it works
2021-12-11 18:12:28 <Hello71> s/; fi/; exit 137; fi/, and then add allow_failures: exit_codes: 137 to .gitlab-ci.yml
2021-12-11 18:12:28 <alpine-meetbot> Hello71 meant to say: concretely, at the very end of https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh, add a line roughly like this: old_apks_used=$(comm -13 <(ap apk-list) <(cd /var/cache/apk; ls)); if [ -n "$old_apks_used" ]; then echo "some apks used in the build were not up-to-date on the mirror: $old_apks_used"; exit 137; fi
2021-12-11 18:13:36 <Hello71> then the submitter/reviewer will know that the results may change when built on top of the new packages on the builders, and can either wait and re-run the CI later, or merge anyways
2021-12-11 18:14:33 <ikke> Maybe we could run that in a separate job so that we do not need to wait for everything to be built
2021-12-11 18:14:37 <Hello71> it can't be done simply in lint phase, because it needs to be done for each arch, and there is a race condition
2021-12-11 18:14:42 <ikke> heh
2021-12-11 18:14:56 <ikke> right toctou
2021-12-11 18:15:00 <Hello71> we need to know the exact APKINDEX which was used for the build
2021-12-11 18:15:36 <Hello71> (and the git contents, but we assume that won't change behind our back)
2021-12-11 18:16:12 <ikke> I hope not
2021-12-11 18:17:41 <Hello71> arguably using the cache to track packages used is not "clean", but i think we should enable apk cache anyways for gitlab ci, so it seems ok?
2021-12-11 18:18:20 <ikke> Yeah, initially I don't see an issue enabling non-perssting caching to be used
2021-12-11 18:18:58 <Hello71> i guess it's a little wasteful for majority of MRs that are only building a single package
2021-12-11 18:19:15 <ikke> but at the same time also at very little cost in that case
2021-12-11 18:19:35 <ikke> depends on the amount of dependencies
2021-12-11 18:20:17 <ikke> It would be the most impactful on the arm runners
2021-12-11 18:21:19 <ikke> (because they only have 50G disks)
2021-12-11 18:22:10 <Hello71> hm. i think i should think of a better way to get the deps, and also we should enable cache if more than one package is to be built
2021-12-11 18:23:13 <ikke> ap recursive-deps
2021-12-11 18:23:18 <ikke> but that does not include the versions
2021-12-11 18:23:51 <Hello71> well as you pointed out earlier, i think we need to ask apk, not lua-aports
2021-12-11 18:24:38 <Hello71> oh, you mean to get the aports versions
2021-12-11 18:25:18 <ikke> yes
2021-12-11 18:25:26 <Hello71> i think apk info, policy, and version will get the APKINDEX versions, and ap apk-list or dump-json combined with ap recursive-deps will get the git versions
2021-12-11 18:25:55 <ikke> but not really in a parsble format
2021-12-11 18:26:39 <Hello71> mmhmm
2021-12-11 18:27:41 <ikke> So what we want to compare are the package + versions in aports against the index from the mirror
2021-12-11 18:28:13 <Hello71> yes
2021-12-11 18:28:23 <Hello71> we can also go rummaging for this data manually
2021-12-11 18:28:41 <ikke> and that intersected with the used depedencies of the packages
2021-12-11 18:29:05 <Hello71> yes, i think so
2021-12-11 21:37:34 <aparcar> Ariadne: new ideas on the Mac issue I reported?
2021-12-11 21:38:00 <Ariadne> not yet
2021-12-11 21:38:03 <Ariadne> probably monday
2021-12-11 21:40:59 <Ariadne> Instead of using these, set the _DARWIN_USE_64_BIT_INODE
2021-12-11 21:40:59 <Ariadne>      macro before including header files to force 64-bit inode support.
2021-12-11 21:41:04 <Ariadne> maybe try that and report back
2021-12-11 21:41:06 <Ariadne> aparcar: ^
2021-12-11 22:02:29 <aparcar> Ariadne: will do, thank you
2021-12-11 23:12:27 <aparcar> Ariadne: I'm not much of a C person, so would I import it at apk.c or where specifically?
2021-12-11 23:12:48 <Ariadne> i would just add -D_DARWIN_USE_64_BIT_INODE to the cflags somehow
2021-12-11 23:13:52 <aparcar> ack
2021-12-11 23:16:40 <aparcar> done but it doesn't change anything 
2021-12-11 23:16:51 <aparcar> still seeing dyld[16691]: symbol not found in flat namespace '_fstat$INODE64'
2021-12-12 05:25:28 <jkfne`kjev>  <D<    i<   d <              u<  s<  a       . t@ R a i n       &          s u p. p l y         i  s<  i  s         w i t h     .        W e< a   <P  o  n s         l i k e       i t        d i d         w i  t h            a  l#  - q  A#  - e  d a        t o         
2021-12-12 05:25:28 <jkfne`kjev>  
2021-12-12 05:25:28 <jkfne`kjev>           a m e r <i c a n  s         n e e d e d           s o m e t h i n  g.         L i  k e  .     9  /  11        t  o             J u s t <i f y              i n <v A  d i n g  -      .    i r -  a  q                       
2021-12-12 05:25:28 <jkfne`kjev>     j u s  t i f y             c r e a  t i n g               w < a  r .s  
2021-12-12 05:25:28 <jkfne`kjev>          
2021-12-12 05:25:30 <jkfne`kjev>            d  i  d             C<   I<  a        -   d< i d .          9    < \    11           o r              i t              j u s t                l e  t                i t               h a  p p e n                  
2021-12-12 05:25:30 <jkfne`kjev>  
2021-12-12 05:25:32 <jkfne`kjev>     
2021-12-12 05:25:32 <jkfne`kjev> .i f      a  l<  Q  a <  e d a       d i d         i t           W  H  Y       t o          k - i -<l - l         9     m i <L l i o n               i r -a q< i – s
2021-12-12 05:32:01 <skarnet> that's a new one
2021-12-12 05:32:40 <boomanaiden154> I think there was a similar troll a day or two ago.
2021-12-12 11:32:38 <Newbyte> Do you have any suggestions regarding how I could resolve !27210?
2021-12-12 15:09:41 <maribu> Has anyone given Alpine on RockChip RK3326 a try? PureTryOut (matrix.org): Is https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6677 also needed for RK3326, or only for RK3399?
2021-12-12 15:10:42 <PureTryOut> probably, idk
2021-12-12 15:58:45 <andypost[m]> ikke: any idea why few builders set 's' flag on files - it makes them fail tests of ccache
2021-12-12 16:02:49 <ikke> andypost[m]: it's set on the aports/main/ccache dir for some reason
2021-12-12 16:03:12 <ikke> rwxr-sr-x    3 buildoze buildoze      4096 Dec 12 14:44 aports/main/ccache/
2021-12-12 16:04:29 <andypost[m]> ikke: then not clear why other builders (arches) passed
2021-12-12 16:08:09 <ikke> It's not set in x86
2021-12-12 16:08:27 <ikke> It is set on aarch64
2021-12-12 16:17:39 <andypost[m]> ikke: and it passed in CI !28396
2021-12-12 19:59:42 <petkan> hi guys, i've been trying to mount an encrypted partition from initramfs, without much luck.  This is on 2017 lenovo laptop, secure-boot enabled, regular partition, not lvm or raid.  Vanilla /usr/share/mkinitfs/initramfs-init isn't working so i had to modify it a bit.  That did the trick with the exception of manual /sysroot mount, which is far from ideal.  In theory the goal
2021-12-12 19:59:44 <petkan> should be achievable by only modifying /etc/kernel-hooks.d/secureboot.conf, but it doesn't work for me...
2021-12-12 20:00:24 <petkan> any ideas where i can read up more?
2021-12-12 20:02:18 <petkan> btw, the default 3.15 installer failed on me each time i selected 'crypt' target for setup-disk on GPT system.  However, it does work properly on MBR machines.
2021-12-12 20:42:55 <minimal> petkan: what exactly is the problem(s) you are seeing? what did you modify in initramfs-init?
2021-12-12 20:54:25 <petkan> minimal: i tried to use 'cryptroot' in /etc/kernel-hooks.d/secureboot.conf and point it to the encrypted device - no joy
2021-12-12 20:56:04 <petkan> i basically added "cryptsetup luksOpen /dev/nvme0n1p3 root" followed by "mount -t ext4 -o ro /dev/mapper/root /sysroot" in /usr/share/mkinitfs/initramfs-init
2021-12-12 20:56:42 <minimal> petkan: the secure boot stuff is fairly new in Alpine
2021-12-12 20:57:12 <petkan> minimal: secure boot is working just fine, it is the initramfs code that doesn't
2021-12-12 20:57:49 <minimal> petkan: normally decrypting rootfs and mounting it is handled by nlplug-findfs
2021-12-12 20:57:50 <petkan> i could not quckly make nlplug-findfs do what i need, so i decided to ask here
2021-12-12 20:58:39 <minimal> I don't believe any secure boot specific functionality has ever been added to mkinitfs - like I said secure boot is fairly new for Alpine
2021-12-12 20:59:08 <petkan> minimal: secure boot doesn't have anything to do with it :)
2021-12-12 20:59:48 <petkan> there's a nice and simple wiki that is rather useful
2021-12-12 21:00:10 <minimal> petkan: you tried without secure boot? I use UEFI (without secure boot) with encrypted rootfs with not issues.
2021-12-12 21:00:57 <petkan> i got rid of GRUB, installed 'kernel-hooks' (i already have signing keys) and bam, Alpine boots securely...
2021-12-12 21:01:00 <minimal> petkan: just to clarify, you're using Grub? which version of LUKS are you using? LUKS1 or LUKS2?
2021-12-12 21:02:09 <petkan> minimal: the system boots straight from EFI, it's an elf image that contains kernel, initramfs, slpash screen (if you have one) and microcode (again, if supplied)
2021-12-12 21:02:32 <minimal> petkan: using EFISTUB, right.
2021-12-12 21:03:05 <petkan> you may want to look at this: https://wiki.alpinelinux.org/wiki/UEFI_Secure_Boot
2021-12-12 21:03:28 <minimal> petkan: so "i could not quckly make nlplug-findfs do what i need" - what did you need nlpug-findfs to do?
2021-12-12 21:04:31 <petkan> minimal: tell it which is my encrypted partition, be prompted for password, mount the dm-crypt 'device' to /sysroot
2021-12-12 21:05:56 <petkan> i tried something like this "nlplug-findfs $cryptopts -p /sbin/mdev ${KOPT_debug_init:+-d} $KOPT_root" by hand, but it seems that i am missing something
2021-12-12 21:06:00 <minimal> petkan: that's what it normal does. However generally this is controlled/triggered by the cmdline that Grub/Syslinux pass to it. In your EFISTUB case what cmdline are you passing?
2021-12-12 21:07:36 <petkan> minimal: "cryptroot=/dev/nvme0n1p3 modules=ext4"
2021-12-12 21:10:18 <minimal> petkan: nothing else? no "root=/dev/mapper/<whatever>", "cryptdm=<whatever>", "cryptkey" values?
2021-12-12 21:11:34 <petkan> minimal: i added "root=/dev/mapper/root" but it didn't help much
2021-12-12 21:11:47 <petkan> what's cryptdm for?
2021-12-12 21:12:07 <minimal> petkan: also "rootfstype=ext4"
2021-12-12 21:12:38 <petkan> the kernel mounter will figure it out, as it does in my manual boot
2021-12-12 21:13:00 <minimal> cryptdm is what you want to name the device (without the /dev/mapper/" prefix)
2021-12-12 21:13:16 <petkan> ah, this is it, maybe :)
2021-12-12 21:13:18 <minimal> what is used with luksOpen
2021-12-12 21:13:53 <minimal> petkan: all this stuff is referenced in the initramfs-init script
2021-12-12 21:14:00 <petkan> that's the broken link between the encrypted partition, the dm name and mountpoint
2021-12-12 21:14:31 <petkan> minimal: yes it is, but it isn't documented, or at least i could not find the descriptions
2021-12-12 21:14:34 <minimal> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L346
2021-12-12 21:15:42 <petkan> minimal: i've gone through it, but i could not figure out what "cryptdm" is for
2021-12-12 21:15:53 <petkan> at least not definitively ;)
2021-12-12 21:16:00 <minimal> petkan: its documented here: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/mkinitfs-bootparam.7.in
2021-12-12 21:17:09 <petkan> minimal: thank you, this is what i needed, hopefully
2021-12-12 21:19:33 <minimal> petkan: I worked out all this stuff a long time and scripted it. Just haven't gotten around to trying EFISTUB and Secureboot yet
2021-12-12 21:23:19 <minimal> petkan: normally for "cryptroot=" I use a UUID rather than a device name
2021-12-12 21:30:14 <petkan> minimal: i would too, once i get it to work the easy way, typing uuid is pain in the ass :)
2021-12-12 21:30:56 <minimal> petkan: well normally you don't need to type as you please it in the Syslinux/Grub config file
2021-12-12 21:31:01 <minimal> s/please/place/
2021-12-12 21:31:01 <alpine-meetbot> minimal meant to say: petkan: well normally you don't need to type as you place it in the Syslinux/Grub config file
2021-12-12 21:33:10 <petkan> minimal: going offline for a bit of testing...
2021-12-12 21:33:19 <petkan> minimal: thanks for the help!
2021-12-12 21:33:34 <minimal> petkan: interested to hwar how you get on
2021-12-12 21:33:39 <minimal> s/hwar/hear/
2021-12-12 21:33:39 <alpine-meetbot> minimal meant to say: petkan: interested to hear how you get on
2021-12-12 21:39:09 <petkan> minimal: bakc
2021-12-12 21:39:15 <petkan> s/bakc/back
2021-12-12 21:39:15 <alpine-meetbot> petkan meant to say: minimal: back
2021-12-12 21:40:04 <petkan> well, with proper usage of the above keywords it is now booting as expected ;)
2021-12-12 21:40:42 <petkan> this is the command line: cryptroot=/dev/nvme0n1p3 cryptdm=root root=/dev/mapper/root modules=ext4
2021-12-12 21:41:23 <petkan> i believe it would be nice if this is documented in a wiki, somewhere
2021-12-12 21:42:46 <minimal> petkan: it is mentioned in several articles on the wiki, search for "cryptroot"
2021-12-12 21:43:25 <petkan> this guy, Jirutka, did an excellent wiki for UEFI secure boot, btw
2021-12-12 21:43:51 <minimal> petkan: well he did write the package for it
2021-12-12 21:46:41 <petkan> minimal: and the package works just fine, i only had to use my own keys and the system booted right away
2021-12-12 21:48:51 <petkan> now, cryptroot pops up exactly four times when searched for in the wiki;  none of the articles describe the relation between cryptroot, cryptdm and root;  i assume it is well-known to someone spending a lot of time in initramfs, but it was not for me :)
2021-12-12 21:50:10 <minimal> petkan: I've been meaning to get qemu working with secureboot so I can test this sort of stuff without the risk of messing up a physical machine
2021-12-12 21:50:49 <minimal> petkan: the alpine install (setup-alpine / setup-disk) recently added support for encryption so the majority of people do not need to know this stuff as its handled for them
2021-12-12 21:51:15 <petkan> minimal: secure boot isn't that intrusive to the system health - you could always disable it from BIOS/UEFI
2021-12-12 21:52:06 <petkan> minimal: are you aware of encrypted partition support problems in 3.15 installer?
2021-12-12 21:52:40 <petkan> i could not get it to work neither in 'lvm' nor in 'sys' mode 'crypt' target
2021-12-12 21:52:59 <petkan> on GPT (UEFI) machines
2021-12-12 21:53:25 <petkan> old style MBR (BIOS) install went OK, though
2021-12-12 21:57:40 <minimal> petkan: personally I don't tend to use the standard installer. Is strange you had gpt issues - any ueful errors produced?
2021-12-12 22:01:26 <petkan> minimal: not that i remember, i only recently started to hack on my initramfs :)
2021-12-12 22:01:46 <petkan> i am mostly user of this sort of stuff
2021-12-13 08:02:07 <aparcar> Ariadne: The inode64 seem to be fakeroot related
2021-12-13 08:12:41 <ncopa> good morning
2021-12-13 08:13:18 <boomanaiden154> Good morning.
2021-12-13 08:14:55 <boomanaiden154> ncopa: I've been working on the community rebuild for python3.10. I'm maybe about 200 packages in at this point. I'll try and commit my changes soon and push them to the MR.
2021-12-13 08:15:24 <boomanaiden154> I was able to get setuptools_scm built as well.
2021-12-13 08:15:46 <boomanaiden154> I disabled the mercurial tests that were failing and they need more investigation, but I'm not sure I have the time to do that currently.
2021-12-13 08:15:53 <ncopa> i think my issue with setuptools_scm was that i build with ptyon 3.9
2021-12-13 08:16:02 <psykose> ncopa: would it be possible to enable CONFIG_SMB_SERVER and CONFIG_SMB_SERVER_SMBDIRECT in -lts for edge and 3.15? someone was asking about it, and afaik it works fine
2021-12-13 08:16:02 <ncopa> i also disabled mercurial tests for now
2021-12-13 08:16:20 <boomanaiden154> It failed for me when I built with 3.10
2021-12-13 08:16:53 <ncopa> psykose: i guess to. create an issue and tag it with category:kernel
2021-12-13 08:16:55 <boomanaiden154> It for some reason kept getting either the package version or the python version as a path to some random directory instead of the actual version.
2021-12-13 08:17:04 <ncopa> s/to/so/
2021-12-13 08:17:04 <alpine-meetbot> ncopa meant to say: psykose: i guess so. create an issue and tag it with category:kernel
2021-12-13 08:18:17 <boomanaiden154> I'll probably try and rebase soon too.
2021-12-13 08:18:34 <ncopa> I have like 35 patches on top of your MR
2021-12-13 08:18:37 <ncopa> and I rebased
2021-12-13 08:19:13 <ncopa> i rebased last friday or maybe Thursday
2021-12-13 08:19:35 <boomanaiden154> Can you push those to the MR?
2021-12-13 08:20:03 <ncopa> i rebased it so it may remove stuff you added since
2021-12-13 08:20:08 <psykose> ncopa: i can't seem to edit the labels, but it's #13309
2021-12-13 08:21:14 <boomanaiden154> ncopa: I haven't pushed anything for a couple days and I haven't staged anything yet, so it shouldn't remove anything.
2021-12-13 08:21:40 <boomanaiden154> And it would be helpful to have a central branch so that we aren't redoing everything.
2021-12-13 08:21:44 <ncopa> yeah
2021-12-13 08:21:47 <ncopa> true
2021-12-13 08:22:05 <ncopa> i wonder if I should rebase it before I push
2021-12-13 08:22:47 <ncopa> boomanaiden154: do you have any local patches?
2021-12-13 08:23:24 <boomanaiden154> I have around 20 right now that I haven't committed.
2021-12-13 08:24:13 <ncopa> ok. maybe you can push those to your MR, then I'll do a rebase
2021-12-13 08:24:50 <ncopa> I have totally 1114 commits  here
2021-12-13 08:25:14 <ncopa> starting with python 3.10 upgrade
2021-12-13 08:25:30 <boomanaiden154> Are you putting patch commits on top of the commits in the MR instead of editing the rebuild commits?
2021-12-13 08:25:40 <ncopa> yes
2021-12-13 08:26:14 <ncopa> thats what i did so far, mostly becase it makes it easier to rebase your work
2021-12-13 08:26:32 <boomanaiden154> Yeah. Rebasing 1000+ commits for every change that you want to make changes forever.
2021-12-13 08:26:39 <boomanaiden154> I'll try and stick to that format going forward.
2021-12-13 08:26:53 <boomanaiden154> Give me a couple minutes and I'll push all my local changes.
2021-12-13 08:27:00 <ncopa> great!
2021-12-13 08:27:06 <ncopa> and thank yo for helping with this
2021-12-13 08:27:16 <ncopa> its not very diffifcult work, but it is *alot*
2021-12-13 08:27:34 <ncopa> and the constant rebasing is challenging
2021-12-13 08:27:57 <ncopa> its like replacing wheels on a train in movement
2021-12-13 08:28:17 <boomanaiden154> Yeah. I ran into quite a few packages today that wouldn't pull from the local repos because they got updated in the remote repos.
2021-12-13 08:28:21 <boomanaiden154> Pretty good analogy.
2021-12-13 08:39:21 <boomanaiden154> ncopa: Just pushed to the MR.
2021-12-13 08:39:33 <boomanaiden154> Hopefully that didn't mess anything up.
2021-12-13 08:40:07 <boomanaiden154> And I assume the plan from now on is to try and push all local changes fairly quickly to the MR branch so we aren't stepping on each other?
2021-12-13 08:51:35 <ncopa> sounds good
2021-12-13 08:51:52 <ncopa> im gonna eat some breakfast and do the rebase in a bit
2021-12-13 09:00:19 <mps> psykose: good, I proposed ksmdb server about month ago in -lts but ncopa ignored me ;)
2021-12-13 09:00:43 <psykose> you also did forget the _DIRECT thing for it :p
2021-12-13 09:01:20 <ktprograms> psykose: What does the _DIRECT do?
2021-12-13 09:01:21 <mps> I didn't forgot, but left it after it is tested some some time
2021-12-13 09:01:51 <psykose> ktprograms: enables smb direct transfers
2021-12-13 09:02:01 <ktprograms> psykose: Ah I see.
2021-12-13 09:02:31 <psykose> it is explained here https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-direct but i cannot load this as their cert is fucked up
2021-12-13 09:02:35 <mps> psykose: I prefer not to rush for new things but do them in steps
2021-12-13 09:02:48 <psykose> it came out at the same time as ksmbd though
2021-12-13 09:03:13 <mps> and ksmbd still have some quirks and possible bugs
2021-12-13 09:07:39 <apangona> Good morning. What is the preferred way to takover maintainershio of a package where the previous maintainer is no longer active?
2021-12-13 09:08:34 <psykose> you contact the previous maintainer and get their approval on an mr taking it over
2021-12-13 09:08:43 <psykose> if they don't respond for some time that would also work i guess
2021-12-13 09:08:58 <ikke> and cc ~alpine/devel@lists.alpinelinux.org
2021-12-13 09:09:19 <mps> psykose: also CC mail to alpine-devel ML
2021-12-13 09:09:37 <mps> good morning ikke :)
2021-12-13 09:14:13 <apangona> Thanks, I asked him to approve/send confirmation to ML
2021-12-13 09:38:41 <ncopa> mps: did you create an issue?
2021-12-13 09:39:25 <mps> ncopa: you know that I didn't, I wrote in private irc
2021-12-13 09:39:37 <ncopa> then I forgot about it, sorry
2021-12-13 09:39:52 <mps> ncopa: np, it is ok 
2021-12-13 09:40:55 <mps> I don't think we have to hurry with this because ksmbd have bugs. I think it will really stable in some o newer mainline kernels
2021-12-13 09:41:38 <ncopa> found your comparison notes now, you are right. you mentioned it there. sorry that I forgot to follow up on that
2021-12-13 09:41:42 <mps> and the fixes will be bakported to LTS
2021-12-13 09:42:50 <mps> if I know 10% percent of knowledge I forgot I would be very happy man :)
2021-12-13 09:44:41 <mps> also, this discussion reminds me that I have to add init script and default smb.conf to ksmbd-tools
2021-12-13 10:30:28 <ncopa> boomanaiden154: I'm rebasing your MR against current master now, and test rebuilds what needs to be rebuild (eg samba etc)
2021-12-13 10:30:42 <ncopa> will push -f as soon as I have it rebased and rebuilt
2021-12-13 10:30:59 <ncopa> then I will merge in my fixes on top of it
2021-12-13 10:38:58 <ktprograms> Hi, can someone please take a look at !27943 and !27947 ? I'm not sure if the options="net" part is really needed since I'm new to packaging Python software. Thanks!
2021-12-13 10:40:10 <ikke> ktprograms: you can test by using abuild rootbld without that option
2021-12-13 10:40:15 <ikke> if it succeeds, you do not need it
2021-12-13 10:40:42 <ikke> (you do need to install abuild-rootbld for that
2021-12-13 10:42:07 <ktprograms> ikke: When I was packaging it I found that it needed net, but I'm trying to understand what exactly needs net. Shouldn't all deps already be available on the system so it wouldn't need to download more stuff?
2021-12-13 10:42:37 <ncopa> they should
2021-12-13 10:42:40 <ikke> Yes
2021-12-13 10:43:02 <ktprograms> So how should I trace what's being downloaded?
2021-12-13 10:45:43 <psykose> does the package build itself not tell you
2021-12-13 10:46:41 <ktprograms> psykose: Which file would that be in?
2021-12-13 10:47:01 <psykose> you're the one packaging it, i would assume something in the setup.py or similar
2021-12-13 10:47:21 <psykose> i will have a look
2021-12-13 10:48:56 <ikke> It might mean you are missing a dependency and it's being installed with pip
2021-12-13 10:51:40 <psykose> py3-wheel and -setuptools_scm are missing
2021-12-13 10:52:07 <psykose> and py3-pip is not needed
2021-12-13 10:52:23 <psykose> the network errors contain the missing package in the fetch name when failing with rootbld
2021-12-13 10:54:54 <ktprograms> psykose: I see. I'll try in a while (I messed up my aports tree by rebasing a backport branch with master).
2021-12-13 11:10:07 <ktprograms> psykose: Thanks, builds fine now!
2021-12-13 11:13:50 <ktprograms> BTW I find #13307 rather interesting. Why wouldn't someone want their configuration in an apk-managed file? Is it the risk of it being deleted when uninstalling vim?
2021-12-13 11:15:19 <ktprograms> psykose: Is requiring net just for the tests to succeed (not one of my MRs, it's tldr-python-client and it needs to access the documentation repo for the tests) preferred over just using !check?
2021-12-13 11:16:17 <psykose> because the apk managed file gets updated when things get changed, and if you have edited it it gets placed in .apk-new instead- it's more convenient to add all local changes in another file you manage yourself
2021-12-13 11:16:21 <psykose> ktprograms: i have no idea for tests
2021-12-13 11:16:44 <ktprograms> psykose: (re vim) makes sense.
2021-12-13 11:19:28 <psykose> are you sure they need net? the test file doesn't seem like it makes network requests
2021-12-13 11:29:53 <ikke> amount of open merge requests passed 400
2021-12-13 11:30:25 <ikke> 110 draft merge requests
2021-12-13 11:30:49 <ikke> 183 merge requests marked as stale
2021-12-13 11:32:44 <ikke> 94 new aports
2021-12-13 11:33:37 <ktprograms> psykose: The test fails with <urlopen error [Errno -3] Try again>. This is in test_error_message() in tests/test_tldr.py, which calls tldr.main().
2021-12-13 11:34:35 <psykose> ah, i think it runs the tldr exe in the .mock
2021-12-13 11:34:36 <psykose> makes sense
2021-12-13 11:35:08 <ktprograms> psykose: So it looks like there's no choice but to allow net?
2021-12-13 11:36:04 <ktprograms> ikke: Can you please merge !27943 and !27947 ?
2021-12-13 11:36:33 <psykose> not my decision, but the precedent is a disabled test probably
2021-12-13 11:36:48 <ncopa> ktprograms: would it be too much to ask to wait with adding more py3-* stuff til python 3.10 is merged?
2021-12-13 11:37:11 <ktprograms> ncopa: Ok, I'll wait.
2021-12-13 11:37:27 <ncopa> i am hoping we can merge python 3.10 this week
2021-12-13 11:37:43 <ktprograms> ncopa: Ok, no problem.
2021-12-13 11:38:37 <ktprograms> ncopa: Anything I can do to help with the python 3.10 upgrade?
2021-12-13 11:39:35 <psykose> ikke: if you want to give a random person merge access i'll take it :p
2021-12-13 11:40:37 <ikke> psykose: helping reviewing MRs to get them in shape already helps a lot
2021-12-13 11:41:44 <ikke> We can add you as a reporter so that you can add labels
2021-12-13 11:41:47 <ikke> if you want
2021-12-13 11:42:14 <psykose> sure, if you're fine with it- i think reported lets me see the hidden security issues too, if that is fine
2021-12-13 11:42:20 <psykose> reporter*
2021-12-13 11:43:14 <mps> psykose: are you gentoo developer?
2021-12-13 11:43:22 <ncopa> boomanaiden154: i rebaed your branch against master and pushed it
2021-12-13 11:43:22 <psykose> nope
2021-12-13 11:44:14 <mps> I got this impression, and it is wrong obviously ;)
2021-12-13 11:44:22 <ikke> psykose: done
2021-12-13 11:45:12 <psykose> ikke: thanks! i'll see if i can put it to some use at least :)
2021-12-13 11:45:33 <ktprograms> I'm just looking through some of the stale MRs, and it looks like the only problem with !27230 is that it takes more than hour to compile the rpi kernel.
2021-12-13 11:46:20 <ikke> ncopa takes care of the kernels
2021-12-13 11:46:48 <ikke> (adding category:kernel helps with that)
2021-12-13 11:47:41 <ktprograms> I think !27080 would be mergeable (the aarch64 job just needs a re-run)
2021-12-13 11:48:05 <psykose> mr labels is locked behind a yet higher tier
2021-12-13 11:48:14 <ikke> ugh
2021-12-13 11:49:53 <ikke> I see, sad
2021-12-13 11:51:21 <ncopa> boomanaiden154: i pushed my changes to your MR
2021-12-13 11:53:09 <ktprograms> Does https://github.com/koalaman/shellcheck/wiki/SC2004 apply to busybox ash?
2021-12-13 11:54:35 <nero> this is not a problem at all
2021-12-13 11:55:11 <ktprograms> nero: What I mean is that the '$' _can_ be removed inside an arithmetic expression, right?
2021-12-13 11:55:45 <psykose> yes
2021-12-13 11:56:05 <ktprograms> ok, thanks
2021-12-13 11:56:11 <nero> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
2021-12-13 11:56:33 <nero> 03> If the shell variable x contains a value that forms a valid integer constant, optionally including a leading <plus-sign> or <hyphen-minus>, then the arithmetic expansions "$((x))" and "$(($x))" shall return the same value.
2021-12-13 11:57:18 <ktprograms> nero: Thanks!
2021-12-13 11:59:16 <ncopa> that was an interesting question, and something new to me
2021-12-13 12:02:36 <nero> i unironically have fun reading documentation while procrastinating
2021-12-13 12:02:55 <nero> i wish more people had this habit, too
2021-12-13 12:36:45 <bratkartoffel> do we really ship a ca-certificate bundle which was last updated in december 2019?
2021-12-13 12:38:03 <mps> bratkartoffel: no, it is base pkg which updates certificates periodically iirc
2021-12-13 12:40:09 <bratkartoffel> as far as i can see this does not happen; the ca-certificates aport simply donwloads the latest tag of "alpine/ca-certificates", which dates back to 2019. This repository contains the "certdata.txt" which contains the certificates and will be used to package the certs
2021-12-13 12:40:26 <bratkartoffel> the certdata.txt hasn't been updated since
2021-12-13 12:42:14 <bratkartoffel> https://git.alpinelinux.org/aports/tree/main/ca-certificates/APKBUILD#n26   should not run default make target, but also "make update", as this updates the certdata.txt
2021-12-13 12:42:57 <bratkartoffel> or am i missing some key point here?
2021-12-13 12:43:06 <mps> I didn't looked details because clandmeter told me it is ok, and I trust him
2021-12-13 12:46:24 <bratkartoffel> LuxTrust Global Root 2 was removed from mozilla in 2020 (https://bugzilla.mozilla.org/show_bug.cgi?id=1641718), but still ships with alpine 3.15 (https://pkgs.alpinelinux.org/contents?file=LuxTrust_Global_Root_2.crt&path=&name=&branch=v3.15)
2021-12-13 12:48:28 <mps> aha, then alpine needs update
2021-12-13 12:52:59 <psykose> mps: do you feel like moving soju/tlstunnel to community
2021-12-13 12:53:34 <mps> psykose: I don't know about soju pkg, what is it
2021-12-13 12:55:03 <psykose> oh my mistake, i confused the other name with yours
2021-12-13 12:55:10 <psykose> same initials
2021-12-13 12:55:42 <psykose> tired me, apologies :)
2021-12-13 12:56:19 <mps> who is this one? don't know anyone with my initials except me, on alpine
2021-12-13 12:56:56 <psykose> Michał Polański , so in my head it makes `mps`
2021-12-13 12:57:25 <mps> aha, you are not first one who made this mistake ;) so no worries
2021-12-13 12:57:44 <nero> and not the last one
2021-12-13 12:57:45 <nero> TIL
2021-12-13 12:58:04 <mps> nero: :)
2021-12-13 12:59:01 <mps> nero: you gave me idea, in modern world when everyone change names I think now I would change my to 'Natanael Copa' :D
2021-12-13 13:01:54 <nero> you can basically set your git user.name to any random text
2021-12-13 13:03:05 <mps> ofc, I know this but I prefer to use real name
2021-12-13 13:04:00 <mps> I have more trust in people who uses their real names
2021-12-13 13:09:21 <psykose> i don't see many people changing their name
2021-12-13 15:05:27 <xrs> Hi guys, my MR is ready for review. https://gitlab.alpinelinux.org/xrs/aports/-/merge_requests/2
2021-12-13 15:08:23 <minimal> xrs: your MR needs to be for aports repo, not your personal repo
2021-12-13 15:08:33 <mps> ikke: now 'we' lowered MR num bellow 400 :)
2021-12-13 15:10:14 <xrs> minimal: I'm not that experienced with gitlab. Should I revert the merge? And how to you take over the MR?
2021-12-13 15:10:28 <mps> psykose: !27955
2021-12-13 15:11:25 <mps> you should add short description and maybe upstream url in commit message when you introducing new pkg to aports
2021-12-13 15:12:23 <psykose> if you want me to, but basically nobody does that
2021-12-13 15:12:32 <psykose> and the url is inside the commit itself in url= field
2021-12-13 15:12:53 <psykose> same for pkgdesc
2021-12-13 15:14:07 <minimal> xrs: you should be able to reapply the merge request against the correct branch (i.e. aports/master)
2021-12-13 15:14:12 <mps> I do, and not same as pkgdesc
2021-12-13 15:14:39 <mps> psykose: 3213312d87cbc4ea447d3194d3a177ef32df3761
2021-12-13 15:15:04 <psykose> those are both the same
2021-12-13 15:15:39 <mps> I intentionally write comment here for other unexperienced contributors to read this
2021-12-13 15:16:03 <mps> it is not same
2021-12-13 15:18:28 <psykose> the pkgdesc and the line you have in the commit message are identical? what am i missing
2021-12-13 15:19:33 <mps> both
2021-12-13 15:20:44 <mps> psykose: please follow current alpine 'best practice' (with some also I disagree but I always trying to follow it)
2021-12-13 15:26:06 <xrs> minimal: OK, I think I got the idea. Still, I did a mistake reverting the commit. Any idea how to fix this?
2021-12-13 15:27:29 <xrs> Oh, dear, what a mess.
2021-12-13 15:28:50 <ncopa> boomanaiden154: I have rebased the MR again. I reverted (removed) py3-sybil upgrade to 3.0 due to py3-testfixures needs py3-sybil 2
2021-12-13 15:29:56 <mps> I think we have problem with ucspi-tcp6 on x86 https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/nullmailer/nullmailer-2.2-r4.log
2021-12-13 15:30:10 <xrs> minimal: please see here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28428/commits
2021-12-13 15:38:10 <minimal> xrs: what mistake? I don't think you needed to revert the commit, just to reapply the MR to the correct repo/branch
2021-12-13 15:41:13 <xrs> minimal: I can't. It seems that only by reverting (or cherry picking?) I can edit the repo/branch for the MR.
2021-12-13 16:30:57 <ikke> FYI, we are moving build.a.o and distfiles.a.o over to a new host. 
2021-12-13 16:34:16 <clandmeter> could be the builders will hang for some time due to dns changes
2021-12-13 17:16:20 <Ariadne> aparcar: i have an idea on how to attack this dyld issue.  still thinking about uid/gid
2021-12-13 17:41:18 <Ariadne> our problem is this: #define __DARWIN_ONLY_64_BIT_INO_T      1
2021-12-13 17:48:49 <Ariadne> aparcar: latest feature/macos branch should work with fakeroot, but fakeroot should also be fixed
2021-12-13 18:08:50 <aparcar> Ariadne: thanks for the update I'll test it right now
2021-12-13 18:16:42 <aparcar> Ariadne: ideas on how to fix fake root?
2021-12-13 18:52:22 <Ariadne> aparcar: i mean, it should be working with the current code.  i have no idea how to fix fakeroot, my guess is that it needs to be aware of the __DARWIN feature flags
2021-12-13 18:52:39 <Ariadne> aparcar: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/75
2021-12-13 19:04:39 <Newbyte> Ariadne: just curious. is this something you want to do because you want to, or something that someone is paying you to do?
2021-12-13 19:05:37 <Ariadne> Newbyte: the former.  openwrt needs it, and its a nice way to solve my "homebrew is annoying to use" problem
2021-12-13 19:06:36 <Newbyte> will there be a separate repo for packages built against Darwin? 🤔
2021-12-13 19:06:52 <Ariadne> that will likely be an entirely different project
2021-12-13 19:11:08 <aparcar> Ariadne: thanks I'll try it right now
2021-12-13 19:22:48 <aparcar> Ariadne: dyld[17565]: symbol not found in flat namespace '_fstat$INODE64'
2021-12-13 19:22:53 <aparcar> still the same issue, not sure what's wrong
2021-12-13 19:23:05 <aparcar> I guess fakeroot just bails
2021-12-13 19:23:25 <Ariadne> yes seems to be a fakeroot issue
2021-12-13 19:23:48 <Ariadne> but latest apk should be using fstat64 symbol on x86
2021-12-13 19:24:00 <Ariadne> or are you using an arm mac
2021-12-13 19:26:00 <aparcar> arm Mac 
2021-12-13 19:26:05 <aparcar> sorry for extra loop
2021-12-13 19:26:12 <aparcar> I thought you where using a arm one too
2021-12-13 19:27:34 <aparcar> Ariadne: sorry I don't understand that comment https://github.com/openwrt/openwrt/pull/4294#issuecomment-992793898
2021-12-13 19:28:11 <Ariadne> yes i’m on an arm mac without using fakeroot
2021-12-13 19:28:52 <Ariadne> i think the issue is that fakeroot is aliasing the 64-bit stat to fstat64
2021-12-13 19:29:27 <Ariadne> aparcar: openwrt uses x86/64 instead of x86_64 right?
2021-12-13 19:30:07 <aparcar> Ariadne: regarding fakeroot, I'll try to just patch that away then?
2021-12-13 19:30:23 <aparcar> Ariadne: yes target x86/64 uses arch x86_64
2021-12-13 19:30:32 <aparcar> however we have some 50 more target/archs :)
2021-12-13 19:30:41 <Ariadne> so if you set /etc/apk/arch in that way it should just work
2021-12-13 19:31:08 <Ariadne> though it does slightly complicate my vision of universal build tools for apks
2021-12-13 19:32:30 <Ariadne> (i have lots of ideas that i need to just dump into a blog)
2021-12-13 19:35:10 <aparcar> Ariadne: wait so /etc/apk/arch isn't related to fake root or is it?
2021-12-13 19:35:28 <aparcar> I tried to patch the arch away since it doesn't make sense within openwrt
2021-12-13 19:35:36 <aparcar> we use target and arch over multiple repos
2021-12-13 19:35:37 <Ariadne> not related to fakeroot
2021-12-13 19:49:24 <Sheila> could I get an opinion on !28433 most recent comment, please?
2021-12-13 20:22:52 <Sheila> ikke: to clarify: I want to know if it would be preferred to demote perl-io-async or promote perl-data-dump.
2021-12-13 20:25:00 <ikke> d'oh, yes ofcourse
2021-12-13 20:27:27 <mps> could it use perl-data-dumper
2021-12-13 20:33:39 <Sheila> no, it specifically needs Data::Dump.
2021-12-13 20:34:48 <mps> this one test can be disabled, Data::Dump is replaced by Data::Dumper in perl base
2021-12-13 20:36:09 <mps> but also: t/70future-io.t .............. Can't locate Test/Future/IO/Impl.pm in @INC (you may need to install the Test::Future::IO::Impl module ......
2021-12-13 20:36:40 <Sheila> yes, that's from perl-future-io.
2021-12-13 20:38:23 <mps> and perl-future-io is not in aports
2021-12-13 20:40:11 <ikke> the MR adds it
2021-12-13 20:42:28 <Sheila> as nothing depends on perl-io-async, I think the correct answer is demotion.
2021-12-13 20:42:46 <ikke> perl-net-async-http depends on it
2021-12-13 20:42:55 <ikke> but that could be moved as well
2021-12-13 20:43:10 <ikke> Nothing else depends on those 2
2021-12-13 20:45:11 <mps> ikke: why not move perl-future-io to main
2021-12-13 20:45:35 <ikke> And perl-data-dump
2021-12-13 20:45:59 <ikke> But is there a good reason to have those in main if nothing in main depends on them?
2021-12-13 20:46:13 <mps> perl-data-dump is used in only one test and I think this test could be disabled
2021-12-13 20:47:04 <mps> or replaced with Data::Dumper maybe (I have no time to check)
2021-12-14 07:42:44 <ncopa> good morning!
2021-12-14 07:43:02 <ncopa> boomanaiden154: do you mind if I rebase your MR again against current master?
2021-12-14 08:09:39 <indy> hi all, few days i was looking for packaging guidelines for go and saw also rust packaging notes, but forgot to bookmark them now i can't find it (or wiki refuse to find them for me) :)
2021-12-14 08:10:03 <indy> does anybody has rust guidelines in bookmarks? :)
2021-12-14 08:10:27 <ktprograms> https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Go ?
2021-12-14 08:11:31 <indy> ktprograms, yes, thanks
2021-12-14 08:17:51 <ktprograms> indy: You're welcome.
2021-12-14 09:49:10 <ktprograms> How can I change the ssh base directory for the Gitea user? I need to do this because $HOME for the gitea user is /var/lib/gitea but the repositories are stored in /var/lib/gitea/git, so I need to do 'git clone gitea:git/user/repo.git' instead of just 'git clone gitea:user/repo.git' (where gitea is a working ssh entry in my .ssh/config).
2021-12-14 10:25:17 <smcavoy> ktprograms: take a look at the  `ROOT` option under `[repository] in the `/etc/gitea/app.ini`
2021-12-14 10:34:12 <ktprograms> smcavoy: I know I can change the ROOT of repositories, but I'm not sure if that will break something else (if I change the gitea user's home dir)
2021-12-14 11:06:06 <ncopa> kdevelop-python does not work at all with python 3.10. upstream has promised to fix it at some point but not yet delivered. https://bugzilla.redhat.com/show_bug.cgi?id=1898116 I think we disable it for now
2021-12-14 13:19:36 <ktprograms> How do I get a pypi source tarball download link? The link format suggested at https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python#source doesn't work, and the download link from pypi has a bunch of random characters that look like a hash of some kind (which I'm not sure if it stays constant across releases).
2021-12-14 13:23:40 <dhruvin> ktprograms: https://files.pythonhosted.org/packages/source/<<first-letter-of-name>>/<<name>>/<<name>>-<<version>>.tar.gz
2021-12-14 13:25:51 <ktprograms> dhruvin: Thanks
2021-12-14 13:26:05 <dhruvin> some packages use _ instead of - in between words, some use capital letters. I had to set _pyname of sphinx-rtd-theme from here https://pypi.org/project/sphinx-rtd-theme/#files
2021-12-14 13:27:09 <dhruvin> _pyname=<<whatever-the-file-name-of-sdist-is>>
2021-12-14 14:27:51 <Sheila> hmm. I notice !28433 keeps hanging on ppc64el on perl-future-io, not entirely sure what's up with that.
2021-12-14 14:31:31 <markand> so openssl jumped from 1.1.z to 3.0.0 without stepping through 2.0.
2021-12-14 18:52:53 <Ariadne> markand: yes because of their stupid FIPS edition
2021-12-14 19:10:20 <Newbyte> Are there Rust bindings for libapk?
2021-12-14 19:12:59 <psykose> most likely not
2021-12-14 19:19:50 <Ariadne> yes, actually.
2021-12-14 19:20:14 <Ariadne> https://gitlab.alpinelinux.org/Cogitri/apk-tools-rs
2021-12-14 19:34:16 <Newbyte> thanks!
2021-12-14 19:47:38 <psykose> poggers
2021-12-14 19:54:49 <Cogitri[m]> Those are only what I ripped out of apk-polkit-rs though, I haven’t gotten around to cleaning the stand-alone version of apk-tools-rs yet
2021-12-14 22:39:39 <mps> anyone knows who is J0WI in 'real world'
2021-12-14 22:40:15 <psykose> is there a reason to know
2021-12-14 22:40:23 <mps> yes
2021-12-14 22:48:51 <psykose> is there an actual reason other than 'yes'
2021-12-14 22:49:07 <mps> yes
2021-12-14 22:53:38 <mps> psykose: I always feels some strange 'feeling' when I have to merge his/her MRs because I'm not sure if any of alpine developer knows real identity, though his/her contribution is usually very useful
2021-12-14 22:53:57 <psykose> you seem to merge mine without issue
2021-12-14 23:03:58 <omni> how would you know even if they claimed to be someone "real"?
2021-12-14 23:04:02 <mps> psykose: yes, but I looked at its importance and risk first
2021-12-14 23:05:25 <mps> omni: I know that all developers are known as real persons by other developers
2021-12-14 23:06:51 <omni> ah, so the question is not who J0WI really is but rather if someone happen to know them?
2021-12-14 23:06:56 <omni> some kind of web of trust
2021-12-14 23:07:09 <mps> omni: right
2021-12-15 01:24:21 <ktprograms> I've successfully gotten qtile working on Alpine, the APKBUILDs for it and its deps are at https://gitlab.alpinelinux.org/ktprograms/custom-aports (ignore the openbox-rounded, that's unrelated to this), if you want to rootbld, you need to use ./rootbld.sh (which sets APORTSDIR correctly). Once we're out of the Alpine python freeze I'll contribute these changes to aports.
2021-12-15 04:40:46 <ktprograms> Can someone please help to see why the check for gitea is failing? Seems to be related to gpg but it was working fine yesterday: https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/563814
2021-12-15 05:00:22 <psykose> seems it fails locally too, lets see if git has more output
2021-12-15 05:01:36 <psykose> of course, since the gitea devs use git subprocessing instead of something actually sane like libgit, setting git_trace=1 makes half the tests fail lmao
2021-12-15 05:05:44 <ktprograms> psykose: What is git subprocessing?
2021-12-15 05:06:02 <psykose> they exec `git ..args` in a shell for every git action instead of using a library to manipulate repositories
2021-12-15 05:06:58 <ktprograms> psykose: Ah I see. But why would git_trace=1 break it?
2021-12-15 05:07:14 <psykose> because to do anything with this model you need to parse the stdout output
2021-12-15 05:07:31 <ktprograms> psykose: Ah that makes sense.
2021-12-15 05:07:43 <psykose> doesn't mean i can't debug the tests, but it's funny to see i guess
2021-12-15 05:12:37 <psykose> the gpg key in their tests integrations/private-testing.key expired yesterday
2021-12-15 05:12:47 <psykose> more info https://github.com/go-gitea/gitea/pull/17984
2021-12-15 05:13:34 <ktprograms> That's interesting. Thanks! So should I patch that key file or what?
2021-12-15 05:14:30 <psykose> it should make a new release soonish
2021-12-15 05:17:06 <ktprograms> psykose: It was backported to the release/v1.15 branch, should I set Gitea to use the HEAD of that branch, or wait for a release?
2021-12-15 05:17:15 <psykose> wait
2021-12-15 05:18:07 <ktprograms> psykose: This only affects the testing right? So the existing Gitea package will still work?
2021-12-15 05:18:20 <psykose> yes
2021-12-15 05:18:37 <ktprograms> psykose: Ok, thanks for your help
2021-12-15 05:19:00 <psykose> this would be easier if git printed gpg output instead of just 'error lol' as gpg itself gives you an expired error
2021-12-15 05:19:34 <psykose> see for yourself with any manual gpg sign and the equivalent git commit -Skeyid
2021-12-15 05:23:17 <ktprograms> psykose: I'll have to take your word for it since I've never set up gpg.
2021-12-15 05:23:41 <psykose> i have and i don't use it as it's quite garbage, but just showing the issue
2021-12-15 06:03:06 <anjan> how do you guys feel about moving zig to community?
2021-12-15 06:03:18 <anjan> I want certain zig projects in stable
2021-12-15 06:05:08 <ikke> mps: ^
2021-12-15 06:58:40 <ktprograms> psykose: If you can edit labels on MRs can you remove the mr-waiting-maintainer-feedback label and add some sort of waiting for upstream release label on !28196?
2021-12-15 06:58:49 <psykose> i cannot
2021-12-15 07:00:00 <ktprograms> psykose: Oh I see.
2021-12-15 08:04:54 <boomanaiden154> ncopa: Just added two patches to the MR.
2021-12-15 08:05:10 <boomanaiden154> Another circular dependency.
2021-12-15 08:08:15 <boomanaiden154> I was rebuilding the main packages that got bumped today too and it looks like some tests for fail2ban still fail?
2021-12-15 08:08:22 <boomanaiden154> Is that the case on your machine as well?
2021-12-15 08:12:17 <mps> anjan: ikke: re zig, we discussed this here about 9-12 months with nmeum and ncopa (and Ariadne iirc) and conclusion was to not move it from testing until first stable is released
2021-12-15 08:12:21 <ncopa> good morning
2021-12-15 08:12:54 <ncopa> boomanaiden154: i havent rebuilt fail2ban today. IIRC I also had test failures. I might have ignored those for now
2021-12-15 08:13:28 <mps> having in mind problems we had with crystal and too early moving it to community
2021-12-15 08:21:42 <anjan> okay thank you mps 
2021-12-15 08:44:27 <mps> why ceph dependency added to qemu?
2021-12-15 08:45:23 <mps> Hello71: ^
2021-12-15 08:46:06 <mps> we should remove this imo. any objection?
2021-12-15 09:02:05 <nmeum> mps: yes, I agree that it would be wise to wait a bit until zig has matured a bit
2021-12-15 09:04:22 <nmeum> anjan: what zig projects do you want in stable?
2021-12-15 09:06:33 <mps> and why we need snappy in qemu?!
2021-12-15 09:08:28 <psykose> dump-guest-memory has an -s option to snappy compress the dump
2021-12-15 09:44:00 <ncopa> mps: try git log -p community/qemu/APKBUILD and then do a search for ceph
2021-12-15 09:44:17 <ncopa> will lead you to the commit:
2021-12-15 09:44:23 <ncopa> f8efeadd234cc81dcaeda3f2491d444cd7b03f51
2021-12-15 09:44:50 <ncopa> which points to: https://gitlab.alpinelinux.org/alpine/aports/-/issues/3418
2021-12-15 09:45:22 <ncopa> there you have the answer for why ceph dep was added
2021-12-15 10:06:32 <nmeum> Ariadne: btw gcc upstream merged the libgo patch without the signoff, that change was probably not copyrightable in the first place. would be nice to also cleanup the remaining gcc-go patches and get them merged upstream
2021-12-15 10:21:09 <mps> ncopa: I already looked all this before asking. my question is do we need this
2021-12-15 10:33:14 <psykose> it's only pulled in as part of modules meta or block-rbd
2021-12-15 11:08:49 <ncopa> mps: someone asked for it, so yes
2021-12-15 11:27:11 <mps> if I ask removal?
2021-12-15 11:27:28 <clandmeter> what is the problem?
2021-12-15 11:27:57 <mps> clandmeter: ceph is big and not easy to keep in 'good shape'
2021-12-15 11:28:21 <clandmeter> ok but thats not directly affected to qemu?
2021-12-15 11:28:40 <clandmeter> i mean if ceph is not able to build, we can still remove support for it?
2021-12-15 11:29:33 <mps> I don't insist, but wonder why we add complexity in 'small, simple' distro
2021-12-15 11:30:37 <mps> other example is wayland-libs in gtk+3.0, this is not needed for users/machine which runs xorg only and not wayland
2021-12-15 11:32:14 <clandmeter> what does qemu actually pull in for ceph?
2021-12-15 11:33:55 <mps> ceph-dev and librbd
2021-12-15 11:35:07 <clandmeter> ceph-dev is not a runtime dep?
2021-12-15 11:35:32 <mps> no
2021-12-15 11:35:49 <clandmeter> i guess it pulls in librdb but only when you install qemu-block-rbd
2021-12-15 11:36:06 <psykose> i propose to remove alsa as well, as i do not use it
2021-12-15 11:36:09 <mps> I think so
2021-12-15 11:36:15 <psykose> and xorg-server, useless package
2021-12-15 11:36:18 <psykose> maybe even ncurses
2021-12-15 11:36:47 <mps> psykose: it is not funny
2021-12-15 11:36:48 <clandmeter> so we give users options without bloating std installation
2021-12-15 11:37:14 <clandmeter> you can use qemu just fine without qemu-block-rbd i suppose 
2021-12-15 11:37:44 <mps> clandmeter: yes, but I think we should do give users options with well maintained pkgs
2021-12-15 11:39:51 <clandmeter> mps: so we should remove the functionality for this user because you dont like ceph in alpine?
2021-12-15 11:40:55 <clandmeter> dont get me wrong, i also dont like ceph, i never used it, and it only gives issues for me due to its insane build system.
2021-12-15 11:41:21 <mps> clandmeter: yes and no. I think ceph should be in better shape if 'we wan't' qemu uses modules/libs from it
2021-12-15 11:41:56 <clandmeter> i remember somebody said he wanted to look at ceph
2021-12-15 11:42:22 <mps> heh, old saying: talk is cheap but work is not
2021-12-15 11:43:05 <clandmeter> i think it was telmich but he is not here
2021-12-15 11:43:25 <psykose> aside from the amount of patches, the actual build seems to just be standard cmake other than the jobs/npm reg
2021-12-15 11:43:41 <mps> what I wanted to say is 'someone asked for it' is not good reasoning
2021-12-15 11:44:33 <clandmeter> mps: if you dont agree create an issue and explain your issues with ceph
2021-12-15 11:45:00 <clandmeter> i think else its up to the maintainer of the pkg
2021-12-15 11:45:09 <mps> clandmeter: too late, it is already in qemu makedeps
2021-12-15 11:45:12 <clandmeter> he/she should decide
2021-12-15 11:45:39 <clandmeter> nothing is too late, else its also too late to discus it here :)
2021-12-15 11:45:48 <mps> I don't ask for removal, this would make a lot of heat
2021-12-15 11:46:37 <psykose> you asked for removal 18 minutes ago
2021-12-15 11:46:55 <mps> psykose: read backlog, carefully
2021-12-15 11:47:02 <psykose> asking to ask is just asking
2021-12-15 11:47:17 <mps> it is not
2021-12-15 11:47:18 <clandmeter> psykose: if we build ceph, it makes our builders overloaded
2021-12-15 11:47:30 <psykose> that i know, and is something that would constitute an actual reason
2021-12-15 11:47:31 <ikke> it takes 25-30GB of space
2021-12-15 11:47:32 <clandmeter> it uses a lot of cpu/mem and even disk space
2021-12-15 11:48:49 <psykose> as you say yourself: needs an issue and discussion that isn't 'i dont like it' in here
2021-12-15 13:44:20 <ncopa> looks like i'm maintainer of qemu. we keep ceph support in qemu.
2021-12-15 13:45:13 <ncopa> if librdb dependency is unwanted, the we can split  qemu-block-rbd into its own subpackage
2021-12-15 13:51:05 <psykose> it already is
2021-12-15 14:07:45 <anjan> nmeum: mepo and river
2021-12-15 14:23:42 <omni> speaking of !27367
2021-12-15 14:33:13 <omni> they do themselves say "Zig is immature" https://ziglang.org/download/0.8.1/release-notes.html#There-Are-Still-Known-Bugs-Remaining
2021-12-15 14:39:32 <mps> omni: I expect zig 0.9.0 in a week
2021-12-15 14:48:56 <omni> is that why it isn't merged yet?
2021-12-15 14:49:43 <mps> not only that
2021-12-15 14:50:34 <skarnet> ohey I found someone who's worse than me at writing docs!
2021-12-15 14:50:42 <skarnet> the Ceph people!
2021-12-15 14:50:58 <skarnet> after reading the backlog I had no idea what Ceph is so I looked it up
2021-12-15 14:51:01 <skarnet> found the doc page
2021-12-15 14:51:37 <skarnet> here is the FIRST SENTENCE of the very first "Intro to Ceph" document, the thing that should give total beginners (like me) the basics of the basics of what the thing is and what it's supposed to do:
2021-12-15 14:51:52 <skarnet> Whether you want to provide Ceph Object Storage and/or Ceph Block Device services to Cloud Platforms, deploy a Ceph File System or use Ceph for another purpose, all Ceph Storage Cluster deployments begin with setting up each Ceph Node, your network, and the Ceph Storage Cluster.
2021-12-15 14:52:15 <skarnet> folks it's not a contest of how many times you can namedrop your product in your intro
2021-12-15 14:52:45 <skarnet> after reading that first sentence the only thing I've learned about Ceph is that I want absolutely nothing to do with it
2021-12-15 14:53:07 <skarnet> because if that's how all the doc is written, interacting with the thing is going to be a lifetime of pain
2021-12-15 14:53:37 <mps> could someone look at this https://tpaste.us/0wbK firefox is stuck on start on M1
2021-12-15 14:54:23 <mps> it tries to reads in loop some pipe and always get EAGAIN
2021-12-15 14:54:28 <minimal> skarnet: they might take exCephtion to your document complaints ;-)
2021-12-15 14:55:19 <skarnet> minimal: I'll say it to get it out of everyone's system so we can be done with it
2021-12-15 14:55:36 <skarnet> Estuans interius, Ira vehementi, Cephiroth
2021-12-15 14:56:33 <minimal> skarnet: I successfully excised my schoolboy Latin many decades ago lol
2021-12-15 14:57:09 <skarnet> it's the best known Final Fantasy song you PEON
2021-12-15 14:57:15 <skarnet> 
ACTION grins.

2021-12-15 14:58:24 <minimal> song? Oh, as in buy the game, the film, the poster, the t-shirt, the mug, and the song? :-)
2021-12-15 14:58:54 <mps> Carl Orf
2021-12-15 14:59:37 <skarnet> well *every* villain theme featuring Ominous Latin Chanting is obviously a rip-off of O Fortuna
2021-12-15 14:59:55 <mps> Carmina Burana
2021-12-15 15:00:15 <skarnet> O Fortuna specifically, because the rest of Carmina Burana doesn't sound like it _at all_
2021-12-15 15:00:29 <mps> yes, yes, O fortuna
2021-12-15 15:01:13 <mps> I don't buy much music but this one I bought long ago
2021-12-15 15:09:52 <ncopa> mps: you are running linux on the M1 iron or in a VM?
2021-12-15 15:10:10 <mps> ncopa: iron
2021-12-15 15:10:29 <ncopa> wow.. thats cool!
2021-12-15 15:10:31 <mps> and it is alpine 
2021-12-15 15:10:39 <ncopa> *mind blown*
2021-12-15 15:10:47 <ncopa> does it dualboot?
2021-12-15 15:10:51 <mps> everything works fine except firefox
2021-12-15 15:11:10 <mps> ncopa: dual boot linux and macos you mean
2021-12-15 15:11:14 <ncopa> yup
2021-12-15 15:11:45 <mps> only through 1TR, keep power buton and select what to boot
2021-12-15 15:12:16 <ncopa> fine. thats how i do (did) on my old 2015 macbook
2021-12-15 15:12:30 <mps> that is apple firmware limitation
2021-12-15 15:12:50 <ncopa> does wifi work?
2021-12-15 15:13:06 <ncopa> or let me put it other way: what does not work?
2021-12-15 15:13:17 <mps> not yes, Martin announced that he will make it this week
2021-12-15 15:13:21 <psykose> ncopa: https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
2021-12-15 15:13:26 <psykose> there is a handy chart thing at the bottom
2021-12-15 15:14:06 <mps> today Martin added keyboard and touchpad, both works
2021-12-15 15:14:59 <mps> Martin Povišek added sound driver but it doesn't work yet, dmesg shows bug
2021-12-15 15:15:49 <mps> also, I made alpine on usb disk and boot it with u-boot/grub combo
2021-12-15 15:16:12 <ncopa> looks fairly usable
2021-12-15 15:16:59 <mps> well, it is usable, but a lot of drivers and features need to be fixed/added
2021-12-15 15:17:38 <ncopa> sort of expected, but still, this hardware is relatively new, no real support from the manufacturer, so this is impressive
2021-12-15 15:17:41 <mps> I use it with external usb wifi and ethernet and external and external usb sound card
2021-12-15 15:18:06 <mps> yes, what these people do is fantastic
2021-12-15 15:18:59 <mps> I'm typing on it right now and from alpine
2021-12-15 15:20:02 <mps> to fully switch for daily usage I need to find what causes firefox problem
2021-12-15 15:20:31 <mps> btw, building kernel takes about 4 minutes and 10-20 seconds
2021-12-15 15:22:07 <ncopa> wiht m1 optimized config i guess
2021-12-15 15:23:06 <mps> actually I copied our linux-gru config as base and then tweaked it to M1
2021-12-15 15:23:17 <ncopa> i built qemu on my m1 in qemu. took a while to compile
2021-12-15 15:23:46 <ncopa> was looking ath the 6.2.0 update but was not able to git clone aports to the ppc64le machine for some reason
2021-12-15 15:24:44 <mps> today I found what is problem with f2fs and I will convert rootfs from ext4 to f2fs. I expect disk speed increase
2021-12-15 15:25:42 <mps> this morning I tried to make qemu upgrade but ceased because of snappy and librdb mess
2021-12-15 15:25:45 <mps> :)
2021-12-15 15:26:30 <mps> without those two qemu upgrade is fine
2021-12-15 15:26:51 <ncopa> i got it to build just fine on my m1
2021-12-15 15:27:01 <ncopa> i was not able to verify the ppc64le build
2021-12-15 15:29:08 <mps> ok, xorg-server 21.1.2 is just released. I think I will 'supersede' !28464 because this MR is mess
2021-12-15 15:29:18 <psykose> yes
2021-12-15 15:29:20 <mps> ncopa: do you agree
2021-12-15 15:29:22 <psykose> oh and finally the dpi fix
2021-12-15 15:29:29 <ncopa> yeah, better upgrade
2021-12-15 15:29:36 <mps> psykose: right
2021-12-15 15:29:44 <psykose> should also backport
2021-12-15 15:29:51 <mps> ok, will make after coffee
2021-12-15 15:29:59 <ncopa> and remember to add the secfixes comment
2021-12-15 15:30:08 <mps> psykose: sure, this is my intention
2021-12-15 15:30:13 <ncopa> mps: thank you for following that up!
2021-12-15 15:30:33 <mps> ncopa: yes, already added them in local branch
2021-12-15 15:31:22 <mps> no one should thanks to me for work on alpine, but thank you for kindness
2021-12-15 15:54:10 <mps> psykose: ncopa: !28502
2021-12-15 15:55:52 <psykose> lgtm
2021-12-15 15:58:16 <mps> psykose: thanks. lets wait for CI finish before merge
2021-12-15 15:58:21 <psykose> yeah, ofc :)
2021-12-15 15:58:54 <ncopa> i think the python3.10 upgrade MR is consuming alot of the CI
2021-12-15 15:59:32 <ncopa> there are like 1145 commits in there
2021-12-15 16:00:03 <mps> huh, not small number
2021-12-15 16:00:17 <ncopa> i cancelled the build there for now
2021-12-15 16:00:38 <boomanaiden154> ncopa: The pipelines have been “succeeding” really early because one of the scripts in the CI image fails to find the head of the branch.
2021-12-15 16:00:45 <boomanaiden154> At least on x86_64.
2021-12-15 16:00:47 <mps> ah. that is why other MRs is started
2021-12-15 16:01:32 <ncopa> i think we should disable the CI for the python 3.10 rebuild. I think its too big
2021-12-15 16:01:56 <boomanaiden154> Let me go and change the settings in my fork really quick.
2021-12-15 16:02:11 <mps> ncopa: btw, did you looked did qemu devs fixed warnings on alpine I posted them about two months ago( I didn't)
2021-12-15 16:02:51 <ncopa> no, i didnt
2021-12-15 16:03:03 <mps> ok
2021-12-15 16:03:07 <ncopa> i was thinking that we should probably give another shot at upstreaming the patches we have
2021-12-15 16:03:16 <ncopa> but i dont have time for that right now
2021-12-15 16:03:29 <ncopa> this python rebuild is eating up my entire weekd
2021-12-15 16:03:35 <mps> also I'm busy, maybe after new year
2021-12-15 16:04:25 <boomanaiden154> ncopa: I just disabled CI in my repo. That should disable it for the MR.
2021-12-15 16:05:49 <boomanaiden154> And we should probably bump Python to 3.10.1 like J0WI mentioned.
2021-12-15 16:06:05 <boomanaiden154> I can do that today.
2021-12-15 16:08:15 <ncopa> sounds good
2021-12-15 16:09:59 <ncopa> looks like there are nothing using py3-opengl-accelerate. maybe we just delete it?
2021-12-15 16:13:12 <boomanaiden154> The build is failing and there are no upstream patches/releases?
2021-12-15 16:13:20 <ncopa> correct
2021-12-15 16:13:39 <boomanaiden154> I’d say move it to unmaintained.
2021-12-15 16:13:41 <ncopa> or, more like, i could not find any patches
2021-12-15 16:13:49 <boomanaiden154> There’s always that one person using it.
2021-12-15 16:14:09 <ncopa> they can still find it in the git log
2021-12-15 16:14:37 <boomanaiden154> That’s true.
2021-12-15 16:14:43 <boomanaiden154> I guess either works then.
2021-12-15 16:16:36 <ncopa> i think i have ~200 builds left now
2021-12-15 16:19:02 <boomanaiden154> Okay. I’ll get the testing commits ready and then we can start working through that repo.
2021-12-15 16:19:47 <ncopa> i wonder if we should push it once community is done, and work on testing while builders are catching up
2021-12-15 16:20:07 <ncopa> it will break testing repo for a while, but I dunno....
2021-12-15 16:20:26 <ncopa> also makes it easier for more people to help
2021-12-15 16:24:46 <ncopa> 468 py3-* packages in testing
2021-12-15 16:37:57 <psykose> last i checked some random python testing packages they were even broken and like 6 months or whatever out of date
2021-12-15 16:38:17 <psykose> seems quite a lot of testing just gets forgotten entirely, maybe we should have a more stringent remove policy
2021-12-15 16:47:01 <omni> mps: !28504 then
2021-12-15 16:47:26 <Ariadne> regarding zig, i would prefer to not have it enter community until the language is stable
2021-12-15 16:48:11 <mps> Ariadne: yes, I explained this this morning, iirc we discussed this some months ago
2021-12-15 16:49:38 <nmeum> 👍
2021-12-15 16:51:37 <mps> omni: upstream author told zig 0.9.0 will be released on 2021-12-20, then we can look what is needed for this MR
2021-12-15 16:56:44 <omni> mps: I assume you'd only have to remove the patch when going to 0.9.0, but the change also fixes linter warnings, enables tests and re-adds the -doc package 
2021-12-15 16:57:03 <omni> I made this because people were having issues with river as it is now, if I remember correctly
2021-12-15 16:58:33 <mps> omni: I'm not against idea that you prepare new MR when the new zig is released, if you want ofc
2021-12-15 16:59:05 <boomanaiden154_> ncopa: Merging the MR after community is done seems like a decent plan to me.
2021-12-15 16:59:26 <omni> out of curiosity, I'll try with the current state of zig in a Draft: MR
2021-12-15 16:59:31 <boomanaiden154_> Testing isn't supposed to be relied upon anyways for stability.
2021-12-15 17:01:00 <ncopa> i don't mind that we do the low-hanging fruit in testing, but I don't think its worth delay the push too much
2021-12-15 17:02:57 <boomanaiden154_> That's probably a good idea. I'll still prepare the commits, I'll try and figure out what builds, and then we can just push whatever doesn't need any changes.
2021-12-15 17:03:05 <psykose> yeah, i think that sounds fine
2021-12-15 17:03:19 <boomanaiden154_> I'm going to start working on the Python 3.10.1 upgrade now.
2021-12-15 17:03:27 <ncopa> thanks!
2021-12-15 17:03:41 <ncopa> should be a simple abump ...
2021-12-15 17:04:27 <boomanaiden154_> Hopefully.
2021-12-15 17:05:09 <boomanaiden154_> ncopa: You also said that the gnu-fallback-soabi patch could be removed?
2021-12-15 17:08:44 <ncopa> yes
2021-12-15 17:09:06 <ncopa> that is an addition on top of the soabi patch we have for python 3.9
2021-12-15 17:09:50 <ncopa> ok. we have another circular dep: py3webtest -> py3wsgiproxy2
2021-12-15 17:14:22 <boomanaiden154_> Check dependencies again?
2021-12-15 17:14:28 <ncopa> yup
2021-12-15 17:14:52 <ncopa> but it seems like it is possible to run a subset of the py3-webtest without py3-wsgiproxy2
2021-12-15 17:15:00 <ncopa> so im disabling a bunch of tests
2021-12-15 18:00:44 <ncopa> im getting closer the end of the list...
2021-12-15 18:01:02 <ncopa> around ~10 left now
2021-12-15 18:01:11 <boomanaiden154> Okay. I’m almost done with Python 3.10.1
2021-12-15 18:01:18 <boomanaiden154> It’s taking forever because of internet issues.
2021-12-15 18:01:24 <boomanaiden154> Should be fixed soon though.
2021-12-15 18:11:24 <ncopa> im starting with the testing repo
2021-12-15 18:12:07 <boomanaiden154> Okay.
2021-12-15 18:12:17 <boomanaiden154> I’ll have the 3.10.1 upgrade out in a couple minutes.
2021-12-15 18:15:34 <ncopa> \o/ all community packages are done!
2021-12-15 18:16:09 <boomanaiden154> Nice!
2021-12-15 18:16:40 <ncopa> build a single package in testing so far, and are chewing freecad as we speak
2021-12-15 18:17:01 <ncopa> its pretty slow, so I'm gonna let it finish and then we should rebase the MR I think
2021-12-15 18:17:38 <ncopa> rebase, rebuild what is needed after the rebase and maybe then we push?
2021-12-15 18:17:44 <ncopa> looks like you pushed python update?
2021-12-15 18:17:53 <boomanaiden154> Yes.
2021-12-15 18:17:59 <ncopa> perfect
2021-12-15 18:18:43 <boomanaiden154> That strategy sounds good to me.
2021-12-15 18:22:36 <ncopa> my cpu here is sweating
2021-12-15 18:23:14 <psykose> getting the gains
2021-12-15 18:23:27 <boomanaiden154> I just rebased locally. Do you want me to push?
2021-12-15 18:25:49 <boomanaiden154> Nevermind. Just screwed up the rebase.
2021-12-15 18:26:02 <boomanaiden154> Gotta go take a final, so I’ll be back in like 45 minutes.
2021-12-15 18:26:22 <psykose> quick final
2021-12-15 18:26:32 <psykose> good luck
2021-12-15 18:42:31 <ncopa> i can do the rebase
2021-12-15 18:42:36 <ncopa> the freecad build failed
2021-12-15 19:15:39 <ncopa> synapse tests are slow. when thy finish i think I will push python 3.10
2021-12-15 19:16:08 <ncopa> it is possible that some packages fails to build but I guess we can deal with the few that pops up
2021-12-15 19:16:35 <boomanaiden154> Yep. I’ll try and keep an eye on the builder status today.
2021-12-15 19:16:52 <boomanaiden154> Surprising that the FreeCAD build failed. I’ll have to look into that later.
2021-12-15 19:17:23 <boomanaiden154> psykose: Thank you.
2021-12-15 19:18:55 <ncopa> pushed!
2021-12-15 19:21:02 <boomanaiden154> Just closed the MR.
2021-12-15 19:21:15 <ncopa> boomanaiden154: thank you very much for your help with this!
2021-12-15 19:22:14 <boomanaiden154> Thank you for giving me the opportunity to work on it.
2021-12-15 19:22:43 <boomanaiden154> I’ll try and get through some of the testing packages tonight and see how far I get.
2021-12-15 19:23:20 <boomanaiden154> I’ll open up another MR to keep track of the changes once I get to it.
2021-12-15 19:25:10 <ncopa> i pushed a few packages to testing already
2021-12-15 19:25:45 <ncopa> im gonna call it a day. have a nice evening!
2021-12-15 19:26:38 <boomanaiden154> I’ll make sure to not include those in the MR. You too!
2021-12-15 19:30:56 <omni> mps: I think zig 0.9.0 will require llvm13, will that be in in a week?
2021-12-15 19:31:35 <psykose> most likely not
2021-12-15 19:32:20 <psykose> one can attempt to bump the 6-7 or something llvm aports to 13, but most likely it will need some special care again
2021-12-15 19:32:35 <psykose> i have wanted to do it for a few weeks but i am on a shitty laptop and lack the hours of willpower
2021-12-15 19:45:04 <omni> oh, they're actually not many
2021-12-15 19:46:17 <psykose> the actual llvm packages come first, compiler-rt lld lldb llvm clang openmp llvm-libunwind
2021-12-15 19:46:35 <boomanaiden154> Looks like main/supervisor is failing on the x86 builder.
2021-12-15 19:47:03 <psykose> some of them also had checks disabled last cycle due to llvm-lit dissappearing from the package despite actually building i think, but it was rushed in for 3.15
2021-12-15 19:47:19 <psykose> so it is more work than it looks like, before any rebuilds
2021-12-15 19:47:26 <psykose> also, i think nothing uses llvm10/11 anymore
2021-12-15 20:00:57 <omni> fewer does, but still
2021-12-15 20:03:11 <donoban> I just see !25054 in git log but I didn't received any update, is too soon yet or maybe it missed to bump pkgrel?
2021-12-15 20:03:59 <ikke> not sure when it was pushed, but there were just >1000 commits pushed to upgrade python
2021-12-15 20:04:37 <donoban> two hours ago hehe
2021-12-15 20:04:42 <psykose> it did indeed forget to bump pkgrel
2021-12-15 20:05:00 <ikke> and now it has to wait for all those packages to be built :)
2021-12-15 20:05:12 <donoban> I'm not sure if it will be upgraded when using --available regardless the pkgrel was bumped
2021-12-15 20:05:29 <ikke> No, because the builders did not rebuild it
2021-12-15 20:05:33 <psykose> if the pkgrel is not bumped it is skipped
2021-12-15 20:05:46 <donoban> ok
2021-12-15 20:41:55 <nmeum> I still find it dubious to enable this feature via static linking against utmps, but we'll see how it plays out…
2021-12-15 20:44:27 <mps> dubious means nonsensical?
2021-12-16 00:14:11 <Ariadne> nmeum: i think it would be better to integrate it into musl itself via static linking, but i suspect dalias would have things to say about that idea :)
2021-12-16 00:34:19 <ktprograms> Should I cherry pick the GPG key fix from !28501 into !28196, or wait the GPG fix MR to be merged? (Some context: the testing key for Gitea expired yesterday, there's a new one but it isn't in any stable release yet, so a patch is needed)
2021-12-16 06:34:53 <nmeum> > Executing busybox-1.34.1-r5.post-upgrade
2021-12-16 06:34:57 <nmeum> > stat: can't stat 'usr/bin/last': No such file or directory
2021-12-16 06:35:01 <nmeum> > stat: can't stat 'usr/bin/who': No such file or directory
2021-12-16 06:35:11 <nmeum> anyone else running into this?
2021-12-16 06:50:49 <ktprograms> nmeum: Do you have coreutils installed (that's where who comes from apparently)?
2021-12-16 06:51:59 <nmeum> no. who/last should be provided by busybox now, since -r5 it is linked statically aganist utmps for utmp support
2021-12-16 06:57:20 <ktprograms> nmeum: I see, in that case I don't know what's happening.
2021-12-16 07:16:17 <mps> good morning and welcome to 'dubious world of alpine'
2021-12-16 07:29:38 <ncopa> good morning
2021-12-16 07:32:35 <ktprograms> Good morning (afternoon for me). MR !28196 is ready to merge, can someone please help to do it? The tests have been fixed by adding a patch that replaces the expired GPG key (it's taken from an upstream commit that just hasn't made it into a release yet).
2021-12-16 07:43:29 <ncopa> seems like gdb was installed on s390x builder, which means that python 3.9 was installed, and all the rebuilds was done with python 3.9
2021-12-16 08:25:15 <clandmeter> ncopa: any plans to switch to rootbld?
2021-12-16 08:25:20 <clandmeter> for builders
2021-12-16 09:43:03 <ncopa> not any specific plans currently
2021-12-16 09:43:31 <ncopa> i did the python 3.10 rebuild using rootbld. there are a lot of packages that does not build in rootbld
2021-12-16 10:11:26 <ktprograms> ikke: Can you please merge !28196 (see my earlier message for how the tests were fixed)? Thanks!
2021-12-16 10:12:10 <mps> instead of this nonsense with adding utpmps to every pkg someone should make utmp patch for musl and apply it in aports *if we want to have utmp*
2021-12-16 10:12:37 <mps> s/utpmps/utmps/
2021-12-16 10:12:37 <alpine-meetbot> mps meant to say: instead of this nonsense with adding utmps to every pkg someone should make utmp patch for musl and apply it in aports *if we want to have utmp*
2021-12-16 10:13:23 <mps> (just noticed that utmps contains my nick :) )
2021-12-16 10:23:26 <ncopa> i dont think we want add utmp to musl. there are only a handful packages that uses it
2021-12-16 10:28:53 <mps> wait some time and we will see how 'handful' it will be
2021-12-16 10:46:20 <nmeum> if we add it to every package it might make sense to discuss this in the tsc as this is a system-wide change then
2021-12-16 10:47:29 <nmeum> ikke: I was able to debug the s390x issue I had with the container you gave me. turns out: musl does not support -fsplit-stack and using that option causes a silent memory corruption on architectures where it is supported (e.g. on s390x). see #28525 for details. thanks for the container :)
2021-12-16 10:53:31 <mps> nmeum: I'm not TSC member so not sure it is good idea from my POV
2021-12-16 10:54:21 <nmeum> the idea of the tsc, as I understand it, is that the entire community can participate in the discussion
2021-12-16 10:55:20 <mps> hmm, maybe this is idea but 'quiet' cmdline fiasco shows opposite
2021-12-16 10:56:07 <nmeum> I created https://gitlab.alpinelinux.org/alpine/tsc/-/issues/30 please add your comments there
2021-12-16 10:56:37 <mps> thanks
2021-12-16 10:59:13 <ikke> nmeum: you're welcome. FYI, you can keep the container, we do not need to clean it up 
2021-12-16 11:04:11 <ncopa> jay! good work nmeum!
2021-12-16 11:19:43 <ikke> nmeum: that issue number does not exist?
2021-12-16 11:19:52 <ikke> or is that an MR?
2021-12-16 11:19:57 <ikke> !28525
2021-12-16 11:21:00 <skarnet> mps: what exactly do you think utmps *is*
2021-12-16 11:22:48 <mps> skarnet: I know what is it
2021-12-16 11:23:00 <skarnet> the problem of utmp is that it can't be implemented securely with just a libc patch
2021-12-16 11:23:08 <nmeum> ikke: yes, MR number sorry
2021-12-16 11:23:32 <mps> skarnet: yes, you are right and I also know this
2021-12-16 11:24:14 <skarnet> the only way to have a secure implementation is a daemon, which is why you need an external package
2021-12-16 11:24:34 <mps> but I have impression that security is not important nowadays
2021-12-16 11:25:07 <skarnet> I don't know what gave you that impression
2021-12-16 11:25:25 <mps> skarnet: just to repeat my note: I don't think anything bad about utmps
2021-12-16 11:25:54 <skarnet> that's not my concern
2021-12-16 11:26:45 <mps> simply, I don't need any utmp/wtmp on my machines
2021-12-16 11:26:49 <ncopa> mps: the point here is that it is more secure to keep utmps out of musl libc
2021-12-16 11:27:15 <mps> ncopa: yes, I think I understand this quite well
2021-12-16 11:27:34 <ncopa> so using libutmps is more secure than patch musl libc
2021-12-16 11:28:08 <ncopa> i think linking it statically is a decent tradeoff
2021-12-16 11:28:31 <mps> but if you all insist on having it I will not object, just feel somewhat strange to have installed something that I don't use (and utmps is not only thing)
2021-12-16 11:28:58 <ncopa> you have lots of things you dont use in busybox
2021-12-16 11:29:03 <mps> yes, to me static linking sound better
2021-12-16 11:29:40 <ncopa> if you want remove the things you dont use, you better build your own busybox. but thats not gonna work for the majority
2021-12-16 11:30:21 <mps> ncopa: I can but I don't want, want to test pkgs as they are in alpine
2021-12-16 11:30:31 <ncopa> we cannot make a build for one single persons needs, so we will have to do trade-offs
2021-12-16 11:30:35 <mps> even stopped to build 'my' firefox
2021-12-16 11:31:32 <mps> I don't think we should build 'for one single person', never told this
2021-12-16 11:31:47 <ncopa> we cannot expect the people who needs who/lastlog to build their own builds either. so we accept a small bloat, similar as we accept a small cost for adding stuff to busybox, even if it means that we add unused stuff
2021-12-16 11:32:05 <mps> I discuss changes to get other people to express their POv
2021-12-16 11:32:07 <ikke> ncopa: could you take a look at https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/34? It adds a latest-stable field to releases.json, which makes it easier to see what version latest-stable is.
2021-12-16 11:33:17 <mps> my 'battle' is to lower complexity in everything where it is possible
2021-12-16 11:38:47 <ncopa> mps: and I appreciate that we have people that keeps pulling in that direction
2021-12-16 11:39:29 <ncopa> ikke: approved and merged. we should also remove mips64 from alpine-releases.conf.yaml
2021-12-16 11:39:39 <ikke> ncopa: right
2021-12-16 11:40:22 <mps> ncopa: thanks :)
2021-12-16 13:22:30 <mps> ncopa: with latest asahi kernel I got firefox working on M1. If you decide to try I could help you
2021-12-16 14:51:36 <minimal> skarnet: the only "issue" with using utmps (and its daemon) versus the old-style approach of utmp being handled by libc is that at boot OpenRC/Busybox init are supposed to write an inital "boot" utmp entry but cannot as the utmps-utmpd daemon is not yet running and so utmp/wtmp records from a prior boot may not be reset
2021-12-16 15:12:03 <skarnet> minimal: utmp is on a tmpfs anyway, it should be reset at boot time
2021-12-16 15:12:07 <skarnet> wtmp is another matter
2021-12-16 15:12:45 <minimal> skarnet: right, but it still is supposed to have an initial "I just booted" entry added by either OpenRC or Busybox init - which is does not as the daemon is not yet running
2021-12-16 15:12:50 <skarnet> but I will write a utility to be called very early in the boot process to initialize the utmp/wtmp record with what init would have written, just in case someone cares
2021-12-16 15:12:53 <minimal> that impacts on some utmp-based tools
2021-12-16 15:13:05 <skarnet> those tools suck
2021-12-16 15:13:08 <skarnet> but yeah
2021-12-16 15:13:27 <minimal> wel its used for things like determining which logins happened since the last boot
2021-12-16 15:13:31 <skarnet> if the spec says the db needs to be initialized, then it will be initialized
2021-12-16 15:13:41 <minimal> so if there's no "boot" record the tools may be confused
2021-12-16 15:13:57 <skarnet> tbh utmp should be treated as ephemeral since last boot
2021-12-16 15:14:08 <skarnet> wtmp is where records are kept over different lifetimes
2021-12-16 15:14:11 <minimal> yeah I was going to suggest that the utmps-utmpd daemon generate this record
2021-12-16 15:14:45 <skarnet> utmpd cannot, it runs under ipcserver and only when a client connects
2021-12-16 15:15:11 <skarnet> even if it wasn't the case it's hard to tell the difference between "first launch" and "was killed and restarted, so do not init the db"
2021-12-16 15:15:25 <skarnet> but yeah there will be an early oneshot that does it
2021-12-16 15:15:34 <minimal> yes that was the potential flaw I was going to point out
2021-12-16 15:15:58 <nero> i just discovered that screen pulled in the utmps daemon for me
2021-12-16 15:16:08 <nero> i thought alpine took the shortcut of just ignoring it and patching it out
2021-12-16 15:16:12 <minimal> so it needs to be generated as early as possible before things like getty/login
2021-12-16 15:17:10 <minimal> skarnet: the point about utmp being ephemeral - true but wtmp is not and the "boot" record affects I too AFAIK
2021-12-16 15:17:17 <minimal> s/I/it/
2021-12-16 15:17:17 <alpine-meetbot> minimal meant to say: skarnet: the point about utmp being ephemeral - true but wtmp is not and the "boot" record affects it too AFAIK
2021-12-16 15:17:31 <skarnet> yeah it's actually more important to write the record in wtmp than in utmp
2021-12-16 15:17:41 <skarnet> but both will be done
2021-12-16 15:18:50 <skarnet> and yes, early enough (sysinit or boot runlevel in openrc parlance) that gettys don't notice anything
2021-12-16 15:36:43 <Ariadne> nero: it should only pull in the library
2021-12-16 15:39:04 <nero> which is in the same package
2021-12-16 15:39:35 <Ariadne> well, either way, solution is to just staticly link it i guess
2021-12-16 15:40:10 <Ariadne> i would prefer to just put libutmps in musl itself and not bother with any of this
2021-12-16 15:40:20 <Ariadne> but, again, i think dalias has opinios
2021-12-16 15:40:22 <nero> i would prefer to not bother with utmps at all
2021-12-16 15:40:39 <Ariadne> then go use a distro that does not bother
2021-12-16 15:41:13 <nero> until half an hour ago i believed that this is said place
2021-12-16 15:41:58 <Ariadne> well, you appear to have believed incorrectly, as a large number of users have asked about utmp over the years
2021-12-16 15:42:43 <skarnet> I would also be happy to spend my life in a utmp-less world
2021-12-16 15:43:00 <skarnet> but for better or worse (spoiler: it's worse) a lot of users want utmp
2021-12-16 15:44:28 <Ariadne> literally the constant stream of inquiries ("why doesn't who show the list of logged in users?") over the years is what led to a bikeshed that led to skarnet writing this code to begin with
2021-12-16 15:45:21 <nero> so the cycle of feature accumulation goes on
2021-12-16 15:45:32 <psykose> i am sure kisslinux is more your speed
2021-12-16 15:45:38 <Ariadne> yes, if you want a distro that is purist, sabotage or something is probably what you want
2021-12-16 15:45:54 <nero> yeah, i wrote the initramfs for that
2021-12-16 15:46:01 <Ariadne> and btw, this is not feature accumulation, it is fixing a long standing bug
2021-12-16 15:46:08 <Ariadne> in alpine 2.x, utmp was working
2021-12-16 15:46:13 <nero> how?
2021-12-16 15:46:20 <skarnet> you'll be free to remove utmps from your installation, you'll get the old behaviour
2021-12-16 15:46:31 <Ariadne> alpine 2.x used uClibc, which had it
2021-12-16 15:51:18 <minimal> for server machines being able to do things like find out who is logged in currently, the dates/times that an specific user logged in etc is a basic security/audit requirement and that's where utmp comes it
2021-12-16 15:52:05 <Ariadne> in fairness, utmp on most systems is useless for that, as an attacker can write to the utmp database
2021-12-16 15:52:26 <Ariadne> skarnet's implementation fixes this
2021-12-16 15:52:58 <minimal> Ariadne: I wasn't talking about any particular implementation of utmp, rather the concept in general
2021-12-16 15:53:24 <Ariadne> sure, but a lot of "utmp bad" criticism is valid, caused by the historical implementation defects
2021-12-16 15:53:40 <nero> brb, called in
2021-12-16 15:54:04 <mercenary> fwiw, although I generally advocate 'less is more', the first thing I missed on alpine was utmp.
2021-12-16 15:54:37 <minimal> right. There doesn't really seem to be any comprehensive alternative to utmp in general - the audit subsystem might provide some of the info that utmp makes available
2021-12-16 15:54:40 <Ariadne> there's nothing wrong with "less is more" philosophy in many cases
2021-12-16 15:55:10 <Ariadne> the problem is when you introduce regressions that are surprising to users
2021-12-16 15:55:21 <Ariadne> in those cases, less is more [of a pain in the ass]
2021-12-16 15:55:47 <ncopa> mps: thank you for your offer. kinda busy with other stuff for now.
2021-12-16 15:56:06 <ncopa> re screen pulling in utmps daemon, I think that is unexpected.
2021-12-16 15:56:16 <Ariadne> mps: does audio or GPU work on asahi kernels yet
2021-12-16 15:56:27 <Ariadne> ncopa: yes, it should be switched to static linking imo
2021-12-16 15:56:30 <ncopa> nero: do you mind filing a bug for it? I can have a look at it
2021-12-16 15:56:58 <psykose> or utmps-libs can be split
2021-12-16 15:56:58 <ncopa> well, I don't mind if it pulls in libutmps, the library. but there should be no hard dependency on the daemon
2021-12-16 15:57:13 <ncopa> i think they already are split?
2021-12-16 15:57:23 <psykose> nope
2021-12-16 15:57:31 <psykose> utmps has both the bin and the .so
2021-12-16 15:57:43 <ncopa> (6/7) Installing libutempter (1.2.1-r3)
2021-12-16 15:57:48 <psykose> thats utempter
2021-12-16 15:57:52 <ncopa> i confused those two then I guess
2021-12-16 15:58:14 <ncopa> thought it was libutmps
2021-12-16 15:58:35 <skarnet> I'll split the .so if people want to link dynamically
2021-12-16 15:58:38 <Ariadne> psykose: theres other reasons to static link it
2021-12-16 15:58:42 <skarnet> but you should not :P
2021-12-16 15:58:52 <psykose> Ariadne: yeah, of course
2021-12-16 15:58:59 <psykose> i just mean why it pulls in the daemon at all
2021-12-16 15:59:04 <Ariadne> skarnet: i think screen should just be fixed regardless
2021-12-16 15:59:25 <skarnet> to give you an idea: the .so is bigger than the .a
2021-12-16 15:59:44 <Ariadne> yeah the .a only costs like a few kb
2021-12-16 16:00:13 <ncopa> um...
2021-12-16 16:00:44 <ncopa> the utmps-* binaries are only 16k
2021-12-16 16:01:01 <Ariadne> utmps-libs binaries pull in libskarnet though
2021-12-16 16:01:09 <Ariadne> which is several hundred kb dynamic
2021-12-16 16:01:19 <Ariadne> but the client only uses a little bit of libskarnet
2021-12-16 16:01:25 <Ariadne> so it is like 10kb or less to staticly link
2021-12-16 16:02:47 <Ariadne> skarnet: btw
2021-12-16 16:03:00 <Ariadne> skarnet: wtmpd initscript fails with  * start-stop-daemon: fopen `/run/utmps/wtmpd.pid': No such file or directory                                                                                                                         
2021-12-16 16:03:16 <Ariadne> if started before utmpd
2021-12-16 16:03:37 <skarnet> there's no checkpath in the wtmpd script?
2021-12-16 16:03:38 <skarnet> will fix
2021-12-16 16:04:07 <ncopa> i think splitting utmps-libs is a ok trade-off
2021-12-16 16:04:56 <ncopa> will still pull in skalibs (200k) but will not pull in utmps daemon, nor openrc script or s6-ipcserver
2021-12-16 16:05:06 <skarnet> I think I'll give an alpineconf talk about the hidden costs of dynamic linking
2021-12-16 16:05:10 <skarnet> with utmps as an example
2021-12-16 16:05:18 <Ariadne> :D
2021-12-16 16:05:42 <ncopa> i know the hidden cost
2021-12-16 16:05:43 <skarnet> and how alpine pretends to have a super small rootfs but actually cheats by eating a lot of ram
2021-12-16 16:05:58 <skarnet> so in the end consumes more resources than would be necessary
2021-12-16 16:06:01 <skarnet> :P
2021-12-16 16:06:07 <psykose> ncopa: !28529
2021-12-16 16:06:27 <ncopa> again, when to do static and dynamic linking is a trade-off
2021-12-16 16:06:38 <skarnet> psykose: I'm actually working on that apkbuild right now
2021-12-16 16:06:41 <Hello71> skarnet: send everything through upx, it's smaller so it must be better
2021-12-16 16:07:09 <skarnet> NMUs are great when the maintainer has been awol for 6 months, when he's in the room I find them pretty fucking rude
2021-12-16 16:07:45 <Ariadne> hmm, weird
2021-12-16 16:09:54 <Ariadne> i enabled utmps on a system, and updated to openssh 8.8_p1-r1
2021-12-16 16:10:03 <Ariadne> yet, its not working
2021-12-16 16:10:14 <Ariadne> i think jirutka missed something
2021-12-16 16:10:37 <Ariadne> oh, it hasnt been merged yet
2021-12-16 16:12:33 <psykose> and i think !28531 is all that is needed for static utmps in screen as well, if it's preferred
2021-12-16 16:12:36 <psykose> or at least it works locally
2021-12-16 16:17:36 <psykose> ah, no
2021-12-16 16:19:35 <Ariadne> moonframe:~$ who
2021-12-16 16:19:35 <Ariadne> kaniini  pts/0        Dec 16 16:18 (10.0.0.6)
2021-12-16 16:19:37 <Ariadne> cool, it works
2021-12-16 16:28:01 <psykose> i don't see a good way to do this while libutempter itself also needs utmps-libs/libskarnet
2021-12-16 16:28:07 <psykose> i guess just utmps-libs is good enough
2021-12-16 16:41:05 <mps> and to finish 'Carthago delenda est'
2021-12-16 16:41:52 <mps> Ariadne: no, audio still doesn't work on my m1 but some people reported it works on some other models
2021-12-16 16:42:20 <mps> Ariadne: also GPU doesn't but simpledrm is good enough
2021-12-16 16:42:34 <Ariadne> audio is a dealbreaker for me
2021-12-16 16:43:52 <mps> well, driver is in but it fails initilization. hope Martin (povik) will fix it in next few days
2021-12-16 16:44:02 <psykose> currently people use a usb dongle for audio mostly
2021-12-16 16:44:20 <mps> marcan 'promised' to work on wifi driver this week
2021-12-16 16:44:55 <mps> psykose: also I use usb audio and wifi, and ethernet
2021-12-16 16:53:30 <staceee> I got a problem with meson on edge "importlib.metadata.PackageNotFoundError: meson". Is it known ?
2021-12-16 16:54:03 <ikke> staceee: python3.10 rebuild
2021-12-16 16:54:27 <ikke> community is stil being rebuilt
2021-12-16 16:54:54 <staceee> okay !
2021-12-16 16:55:14 <staceee> that also explain why sxmo-{sway,wlroots} arent in repositories yet ?
2021-12-16 16:55:22 <Ariadne> yes
2021-12-16 16:55:29 <staceee> perfect, thanks a lot !
2021-12-16 16:55:47 <nero> ncopa: beliefs are not a bug
2021-12-16 16:56:05 <nero> so, is some kind of utmp support actually on the roadmap?
2021-12-16 16:56:19 <psykose> as it has been for many years
2021-12-16 16:56:46 <Ariadne> nero: yes
2021-12-16 16:57:55 <psykose> also doesn't help it seems py3-compreffor is broke
2021-12-16 16:57:59 <ikke> nope
2021-12-16 16:58:20 <psykose> think it's been restarted twice already if my watching is accurate
2021-12-16 16:58:45 <ikke> ImportError: cannot import name '_compreffor' from partially initialized module 'compreffor' 
2021-12-16 16:58:48 <ikke> Someone needs to investigate
2021-12-16 17:01:44 <skarnet> foundf like fomeone haff a fpeetf impediment
2021-12-16 17:02:08 <ikke> lol
2021-12-16 17:02:35 <psykose> lmao
2021-12-16 17:03:01 <omni> I'm trying to figure out why my xen hvm domu won't boot, if it's due to 4.16 upgrade or xen-qemu split...
2021-12-16 17:16:47 <omni> (and, yes, I installed the xen-qemu package)
2021-12-16 17:36:49 <omni> think I found it!
2021-12-16 17:37:57 <omni> xen-qemu installs to /usr/share/qemu instead of /use/share/qemu-xen/qemu
2021-12-16 17:40:42 <omni> not sure that's all yet
2021-12-16 17:45:33 <nmeum> Ariadne: any chance you could take a look at !28525 ? (:
2021-12-16 17:45:49 <nmeum> after that has been merged I only need to figure why gcc-go doesn't work on ppc64le
2021-12-16 17:46:29 <nmeum> the ppc64le issues seems to be libucontext related, for some reason setcontext(3) returns immediately on that arch
2021-12-16 17:47:34 <Ariadne> ask koorogi about it
2021-12-16 17:48:41 <nmeum> about ppc64le? I think I will just add a -dbg subpackage to libucontext and try to debug this with qemu-user
2021-12-16 17:49:06 <Ariadne> on ppc64le, we use kernel SYS_swapcontext to do the actual swapping
2021-12-16 17:49:10 <mps> uh, just one commit for kernel https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.9
2021-12-16 17:49:20 <Ariadne> mps: that smells like a CVE
2021-12-16 17:49:29 <mps> Ariadne: do you think we should upgrade ASAP
2021-12-16 17:49:49 <Ariadne>     netfilter: selftest: conntrack_vrf.sh: fix file permission
2021-12-16 17:49:50 <Ariadne> hmm
2021-12-16 17:49:52 <Ariadne> nah
2021-12-16 17:50:00 <Ariadne> guess not a CVE, just strange
2021-12-16 17:50:27 <mps> ok, I will upgrade linux-edge later this evening, just in case
2021-12-16 17:59:05 <nmeum> Ariadne: who is koorogi? why would koorogi be interested in gcc-go on ppc64le and how do I contact this person?
2021-12-16 17:59:41 <Ariadne> koorogi is on #musl
2021-12-16 17:59:52 <Ariadne> he did the libucontext ppc64[le] port
2021-12-16 17:59:56 <nmeum> ah!
2021-12-16 18:00:18 <nmeum> ok, thanks for the info. might contact him later after I gathered some more information on this (:
2021-12-16 18:07:30 <dalias> ariadne, what is the utmps issue now?
2021-12-16 18:07:53 <Ariadne> some would like to see it implemented directly in musl (the client part)
2021-12-16 18:10:41 <skarnet> you would looooove the protocol
2021-12-16 18:17:03 <dalias> ariadne, can you give m a brief explanation of why this has come up as an issue? i thought the analysis before indicated just linking libutmps in the few apps that want it would do fine
2021-12-16 18:17:33 <Ariadne> dalias: bikes, sheds, etc.  not important
2021-12-16 18:17:50 <psykose> can i store a car in the shed
2021-12-16 18:18:49 <skarnet> the detailed technical explanation is that some people are scared shitless of linking code statically (but it's totally okay if the same code is in the libc, for reasons)
2021-12-16 18:18:54 <omni> should xen-qemu collide with qemu?
2021-12-16 18:27:58 <omni> I think that was just an error
2021-12-16 18:45:47 <dalias> *sigh*
2021-12-16 20:21:39 <omni> is amove documented somewhere?
2021-12-16 20:22:59 <omni> I mainly want to know if I can move directories with it, but also think its documentation should be easy to find (and I may just have been sloppy in my search)
2021-12-16 20:24:01 <ikke> Yes, it can be used to move directories
2021-12-16 20:25:31 <ikke> I'm not aware of any specific documentation
2021-12-16 20:29:46 <omni> it's mentioned in https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2021-12-16 20:29:55 <omni> but that's the only thing I can find
2021-12-16 20:37:43 <psykose> /usr/bin/abuild has all the functions
2021-12-16 20:37:51 <psykose> not exactly docs, but reading shell is pretty easy
2021-12-16 20:38:02 <psykose> and yeah, it moves anything from pkgdir->subpkgdir
2021-12-16 22:30:34 <omni> ah, thanks, I've been thinking of diving into that some day
2021-12-16 22:42:59 <omni> !28530
2021-12-16 23:29:42 <omni> !28535
2021-12-16 23:57:03 <omni> compreffor fail
2021-12-17 01:36:47 <bl4ckb0ne> builderseems to have issues on compreffor
2021-12-17 01:38:38 <smcavoy> I received a message from 'pkgs@alpinelinux.org' regarding a package I am a maintiner of (python 3.10 related). It appears to be automated but mentions a message sent by a user and includes their email address. A reply to `pkgs@alpinelinux.org` results in a 'user not found' error. Is this automated / is there a proper form to track this / reply via? 
2021-12-17 01:56:36 <boomanaiden154> Seems like there might be a problem with the alpine email infrastructure if you can't reply, but I'm not exactly sure if that functionality is supposed to exist.
2021-12-17 01:57:07 <boomanaiden154> The general protocol would probably be to just review the changes and then send an email to that specific user's email address if you have questions, or open a MR on gitlab with changes and ping them there.
2021-12-17 03:40:45 <smcavoy> thanks
2021-12-17 08:27:33 <clandmeter> smcavoy: it has been manually flagged by somebody
2021-12-17 08:27:50 <clandmeter> but seems this user uses it as an issue tracker which it is not.
2021-12-17 08:50:00 <lmarz> Morning. Is the transition to python 3.10 complete?
2021-12-17 08:51:58 <psykose> nope
2021-12-17 08:53:07 <lmarz> ok, thanks
2021-12-17 09:20:17 <smcavoy>    ~.
2021-12-17 10:23:46 <smcavoy> clandmeter: that being the case it seems a issue should be created in gitlab and that should send a message to the maintainer, then the maintainer can reply to the issue/open a MR if need be.. 
2021-12-17 10:25:26 <clandmeter> smcavoy: yes, the user who flagged that pkg should do that. I cannot fix the user :)
2021-12-17 10:28:12 <smcavoy> indeed but the tool they use to flag the package is on https://pkgs.alpinelinux.org/packages it seems that tool should then be updated so when filled out it uses the issue tracking system.. 
2021-12-17 10:29:03 <clandmeter> no, that tool is not for that use case.
2021-12-17 10:29:18 <clandmeter> issues should go to our gitlab
2021-12-17 10:29:28 <clandmeter> flagging can be done on pkgs.a.o
2021-12-17 10:29:38 <clandmeter> i cannot stop users from abusing it
2021-12-17 10:31:48 <clandmeter> tbh, i think we should probably remove manual flagging from pkgs.a.o and only use automatic flagging based on anyita
2021-12-17 10:32:01 <smcavoy> what is the use case difference between the user opening a issue for an out of date package and flagging the package?
2021-12-17 10:32:36 <psykose> there already are plenty of issues for out of date packages, though i don't know the numbers as a ratio
2021-12-17 10:32:38 <clandmeter> as i mention, your case is not about flagging
2021-12-17 10:32:58 <clandmeter> the user reported an issue
2021-12-17 10:34:42 <psykose> the other day someone mentioned someone flagged something on 3.12 community
2021-12-17 10:35:00 <clandmeter> thats technically not possible
2021-12-17 10:35:09 <clandmeter> you can only flag on edge
2021-12-17 10:35:19 <clandmeter> or else its a bug :)
2021-12-17 10:35:24 <smcavoy> clandmeter: oh, right but to the user it appeared as though a package was out of date.. I opened #13320 regarding that. I suggested the flagging go through the issue tracking system / perhaps have an status page with info on changes to edge that might be prolematic 
2021-12-17 10:35:27 <psykose> ah, i guess they edge flagged it and mentioned 3.12
2021-12-17 10:35:37 <psykose> was not clear in the mention here :p
2021-12-17 10:35:43 <psykose> that's fine there
2021-12-17 10:36:41 <clandmeter> smcavoy: pkgs.a.o existed before our gitlab instance
2021-12-17 10:36:54 <clandmeter> so yes you could create issues for packages that are flagged
2021-12-17 10:37:19 <clandmeter> but there is no easy way to link a package maintainer to a gitlab user
2021-12-17 10:38:47 <clandmeter> it would also create a lot of issues on gitlab, not sure thats what we want. 
2021-12-17 10:39:21 <smcavoy> maybe it would be better to direct them to the issue tracker to create an issue.
2021-12-17 10:39:54 <smcavoy> certainly do not want just a button to click when things might not be correct :)
2021-12-17 10:40:14 <psykose> how many daily flags are there normally
2021-12-17 10:40:25 <clandmeter> check pkgs.a.o :)
2021-12-17 10:40:32 <clandmeter> it has a flagged colomn
2021-12-17 10:41:05 <clandmeter> a better integration with anyita would be preferable 
2021-12-17 10:41:21 <psykose> a fairly hefty amount for something that spams issues
2021-12-17 10:41:50 <clandmeter> the mapping is also something that needs attention
2021-12-17 10:42:00 <clandmeter> i think we currently have mapping for 1.5k packages
2021-12-17 10:42:06 <clandmeter> but our db is much, much larger
2021-12-17 10:43:05 <psykose> apparently a ton of these are anitya already
2021-12-17 10:43:25 <psykose> issues for only manual ones suddenly seems less insane
2021-12-17 10:43:26 <clandmeter> i think 99 out of 100 :)
2021-12-17 10:44:11 <psykose> is the mapping the database of what things it tracks
2021-12-17 10:44:51 <clandmeter> https://release-monitoring.org/static/docs/index.html
2021-12-17 10:45:18 <clandmeter> you map an alpine apkname to the one in anitya
2021-12-17 10:45:57 <clandmeter> its a manual process so it takes time
2021-12-17 10:47:10 <clandmeter> https://release-monitoring.org/distro/Alpine/
2021-12-17 10:47:21 <clandmeter> 2362 projects found
2021-12-17 10:48:16 <clandmeter> I have not taken a closer look at it, but it make be interesting to list in pkgs.a.o if there is a mapping
2021-12-17 10:48:41 <clandmeter> s/make be/maybe/
2021-12-17 10:48:41 <alpine-meetbot> clandmeter meant to say: I have not taken a closer look at it, but it maybe interesting to list in pkgs.a.o if there is a mapping
2021-12-17 10:49:16 <clandmeter> if not, we could add a link so users could make one if they are interested.
2021-12-17 10:49:48 <psykose> ahh
2021-12-17 10:49:51 <psykose> yes, this seems useful
2021-12-17 10:53:25 <clandmeter> some details are discussed in #10736
2021-12-17 10:53:44 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10736
2021-12-17 11:00:48 <smcavoy> it seems with anitya anyone can create an account/update mappings.. 
2021-12-17 11:53:26 <mps> ncopa: xf86-video-modesetting is dummy pkg, it could be removed because modesetting driver is in xorg-server for some (not short) time
2021-12-17 12:24:27 <donoban> hi, is python 3.10 rebuild finished?
2021-12-17 12:25:17 <psykose> no
2021-12-17 12:26:00 <donoban> I guess is not very good idea do upgrade before it finish
2021-12-17 12:30:12 <ikke> See the topic :-) 
2021-12-17 12:32:07 <donoban> hehe ok
2021-12-17 12:35:58 <donoban> ouch, tried to upgrade only busybox, it started to upgrade py3-* packages and I aborted with ctrl+c
2021-12-17 12:42:44 <donoban> 'apk upgrade -Ua busybox' is expected to upgrade everything?
2021-12-17 12:46:39 <ikke> Yes
2021-12-17 12:46:58 <ikke> apk add -u busybox
2021-12-17 12:47:32 <psykose> upgrade states it should be listed only, otherwise all
2021-12-17 12:47:54 <psykose> not that i care much for partial upgrades
2021-12-17 12:56:36 <donoban> well I tried it because the man says " apk upgrade [<options>...] [<packages>...]"
2021-12-17 12:56:59 <donoban> maybe the [<packages>--] should be removed?
2021-12-17 13:06:05 <ktprograms> donoban: I think the problem is you used -Ua, where the -a means --available, so it upgraded everything available, and not just the packages you listed.
2021-12-17 13:06:37 <mps> trying to make firefox MR I got this "/usr/include/wayland-client-protocol.h:3672: undefined reference to `wl_proxy_marshal_flags'"
2021-12-17 13:06:54 <psykose> you need the patch from firefox-esr
2021-12-17 13:07:12 <mps> isn't wayland-protocols fixed? ikke^
2021-12-17 13:07:18 <psykose> it's the patch in firefox-esr
2021-12-17 13:07:35 <donoban> ah I see ktprograms 
2021-12-17 13:07:37 <psykose> mozwayland-add-missing-stub
2021-12-17 13:10:23 <ktprograms> donoban: You would probably want to do 'apk add -U busybox', where the -U stands for --update-cache, which forces a update of the cache. If you're okay with the default cache update time, then just 'apk upgrade busybox' _should_ work.
2021-12-17 13:11:46 <donoban> so maybe --available should fail if some package are specified
2021-12-17 13:13:13 <mps> psykose: thanks for info
2021-12-17 13:14:43 <mps> (yet another build test)
2021-12-17 13:14:55 <psykose> whadya adding
2021-12-17 13:15:17 <mps> 'whadya' meaning is?
2021-12-17 13:15:28 <psykose> what are you
2021-12-17 13:15:43 <mps> added patch you mentioned above
2021-12-17 13:15:46 <omni> Xen user comments? !28535
2021-12-17 13:15:47 <psykose> ah, right
2021-12-17 13:16:12 <omni> wrt --enable-qemu-traditional and --enable-pv-grub
2021-12-17 13:16:55 <mps> and please (to all) use colloquial English language, most people here aren't native english speakers
2021-12-17 13:17:14 <psykose> i'm not either, but sure
2021-12-17 13:17:18 <psykose> omni: enable both
2021-12-17 13:19:54 <minimal> mps: colloquial American English? or colloquial British English or colloquial Australian English? they are not the same thing
2021-12-17 13:20:23 <mps> minimal: lol
2021-12-17 13:20:53 <minimal> mps: I may not understand some Americanisms despite being a native English speaker
2021-12-17 13:21:14 <mps> I'd prefer British because I learned using it, but for me there is no much differences between them all :)
2021-12-17 13:22:41 <mps> psykose: would you look my comment in !28553. I looked yesterday in mold and intended to package it but you are faster
2021-12-17 13:23:38 <mps> minimal: I thought you are american one
2021-12-17 13:24:13 <psykose> mps: i already resolved it, unless you want another change
2021-12-17 13:24:41 <mps> psykose: thanks
2021-12-17 13:25:39 <psykose> i also tried to get libtbb upgraded to use system, but the newest version has something that relies on glibc dlopen and i didn't care enough to see if it can maybe be worked around
2021-12-17 13:25:48 <mps> merged mold
2021-12-17 13:26:10 <psykose> that same thing is disabled in the static-only build, so the bundled one builds fine for mold
2021-12-17 13:26:11 <minimal> mps: I can't think what ever gave you that impression
2021-12-17 13:26:51 <mps> minimal: you are active in their TZ mostly, probably this
2021-12-17 13:27:29 <psykose> where do you think i'm from :p
2021-12-17 13:27:55 <mps> psykose: you are in east
2021-12-17 13:27:55 <minimal> mps: a good "hint" is whether someone uses "s" versus "z" in words
2021-12-17 13:28:13 <psykose> how far east
2021-12-17 13:28:32 <mps> poland and ...
2021-12-17 13:29:05 <mps> minimal: ok, but who uses 's' and who 'z'
2021-12-17 13:30:10 <psykose> not the worst guess
2021-12-17 13:30:47 <mps> psykose: russia?
2021-12-17 13:31:20 <psykose> i wouldn't say i am from anywhere :p but it is a good guess
2021-12-17 13:31:28 <mps> minimal: now my guess is you are in Canada?
2021-12-17 13:31:55 <minimal> mps: thought you learnt British English? that would mean using "s", whereas "z" is an Americanism
2021-12-17 13:32:26 <mps> psykose: I 'see and know' your personality, and that was how I thought you have Slovene character (as I have it)
2021-12-17 13:32:59 <minimal> mps: nope, east of Canada, west of Greenwich Meridian :-)
2021-12-17 13:33:01 <mps> minimal: I'm self taught and I'm not good teacher :)
2021-12-17 13:33:17 <mps> minimal: ireland
2021-12-17 13:33:21 <minimal> yupe
2021-12-17 13:33:30 <mps> nice
2021-12-17 13:33:59 <mps> now I know why I didn't had any clash with you
2021-12-17 13:34:02 <psykose> the good one or the bad one?
2021-12-17 13:34:28 <minimal> mps: we like our "s" and "u" (i.e. "colour", not "color") ;-)
2021-12-17 13:34:35 <mps> psykose: both, good and bad (though I think it is more good than bad)
2021-12-17 13:35:16 <mps> minimal: yes, I know, but reading fast msgs on irc I 'skip' these fine points
2021-12-17 13:36:54 <mps> minimal: Irish bars are popular here
2021-12-17 13:37:07 <mps> pubs?
2021-12-17 13:37:48 <mps> and Irish music, I like to listen players on Irish flute (pipe)
2021-12-17 13:40:39 <minimal> mps: Irish pubs are popular all over the world - they used to be a company here that you could pay to build an Irish pub for you, they would design the whole bar, make all the fittings, fill up shipping containers with the fittings (inc. cliches like old bicycles to hang on the wall) and ship it to the destination and fly over electricians, carpenters, etc to set it up
2021-12-17 13:41:44 <mps> ah, that explains why they are so popular :D
2021-12-17 13:44:06 <mps> minimal: if you ever want to rename alpine pkgnames from '*color*' to '*colours*' I'll merge them ;)
2021-12-17 13:44:31 <mps> s/rs/r/
2021-12-17 13:44:31 <alpine-meetbot> mps meant to say: minimal: if you ever want to rename alpine pkgnames from '*color*' to '*colour*' I'll merge them ;)
2021-12-17 13:44:58 <minimal> cue joke about the Irish Linux distro that for every command asks you twice if you really want to do it ("to be sure to be sure") :-)
2021-12-17 13:49:35 <Misthios> mps: oh no
2021-12-17 13:54:22 <psykose> oh yes
2021-12-17 14:01:07 <mps> psykose: btw, I read russia and understand talks (not perfect ofc) and even I can speak to some degree but writting is hard for me
2021-12-17 14:01:20 <mps> s/russia/russian/
2021-12-17 14:01:20 <alpine-meetbot> mps meant to say: psykose: btw, I read russian and understand talks (not perfect ofc) and even I can speak to some degree but writting is hard for me
2021-12-17 14:02:58 <psykose> oh i don't speak russian at all
2021-12-17 14:03:08 <psykose> also seems kodi needs to be fixed, and i think i know what the fix is
2021-12-17 14:07:41 <andypost[m]> minimal: do you use words like "centre", "formulae"?
2021-12-17 14:12:53 <minimal> andypost: certainly "centre" (and "metre"), I don't usually refer to multiple formula but guess I'd still say "formula" as my Latin has always been awful :-)
2021-12-17 14:14:45 <minimal> anypost: unfortunately pretty much every one says "billion" for a thousand million as otherwise big mistakes would happen :-)
2021-12-17 14:15:00 <minimal> s/any/andy/
2021-12-17 14:15:00 <alpine-meetbot> minimal meant to say: andypost: unfortunately pretty much every one says "billion" for a thousand million as otherwise big mistakes would happen :-)
2021-12-17 14:17:53 <andypost[m]> minimal: thanks, good to know)
2021-12-17 14:18:43 <mps> also I use 'formula' ;)
2021-12-17 14:20:46 <kpcyrd> is there something I can do for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28404? it seems the build hits the 1h timeout on armhf
2021-12-17 14:21:14 <mps> !28404
2021-12-17 14:22:25 <psykose> you can raise your own timeout
2021-12-17 14:22:45 <psykose> go to your aports fork, settings cog on the left, ci/cd, some timeout value in there
2021-12-17 14:24:15 <kpcyrd> thanks, changed it to 2h and restarted the build
2021-12-17 14:24:20 <psykose> mps: !28566 should fix kodi on aarch64/x86_64, when ci passes
2021-12-17 14:25:25 <mps> psykose: nice, lets wait finish
2021-12-17 14:26:40 <psykose> now question why suricata sigsegv in the build on x86 :)
2021-12-17 14:26:46 <psykose> think not much left and we are done
2021-12-17 14:39:55 <psykose> can reproduce locally but no idea why rustc would segfault on x86, sigh
2021-12-17 14:40:09 <psykose> mps: kodi should be fine to merge now
2021-12-17 14:40:46 <mps> already merged
2021-12-17 14:41:13 <psykose> same time :)
2021-12-17 14:41:53 <mps> yes
2021-12-17 14:42:24 <mps> psykose: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/kodi/kodi-19.1-r6.log
2021-12-17 14:42:35 <psykose> that is not the new one
2021-12-17 14:42:39 <psykose> new one is -r7
2021-12-17 14:42:42 <mps> aha, good
2021-12-17 14:42:55 <psykose> also got scared 
2021-12-17 14:43:22 <mps> same time :)
2021-12-17 14:44:02 <psykose> cute
2021-12-17 15:04:53 <psykose> mps: !28568 for ppc64le fix
2021-12-17 15:05:04 <psykose> ci fail only because of numpy not rebuilt for 3.10 yet
2021-12-17 15:09:54 <psykose> and !28569 unless someone wants to debug a rustc segfault
2021-12-17 15:15:23 <skarnet> mps: welp I guess NMUs are accepted practice now
2021-12-17 15:15:45 <skarnet> it's all fine but it's not what I was told, and I had scruples submitting patches for various stuff before
2021-12-17 15:15:55 <skarnet> no more scruples then
2021-12-17 15:16:39 <mps> skarnet: NMUs was always ok
2021-12-17 15:16:54 <mps> psykose: I don't touch python
2021-12-17 15:17:16 <psykose>  it's just a disable on failing because of missing dep- you can see in the logs
2021-12-17 15:17:23 <skarnet> were they? ISTR they were a backup solution for when the maintainer was awol
2021-12-17 15:17:32 <psykose> half the maintainers are awol
2021-12-17 15:17:32 <mps> skarnet: on the developers is to decide will or will not merge NMUs
2021-12-17 15:18:11 <skarnet> psykose: do I look awol to you? 2 NMUs in 2 days is not negligible
2021-12-17 15:18:20 <mps> skarnet: I do NMUs daily, most of ncopa pkgs I merge without asking him
2021-12-17 15:18:23 <psykose> sorry, i did not mean you are
2021-12-17 15:19:21 <skarnet> I think we should remove the maintainer lines in the apkbuild because they don't mean anything
2021-12-17 15:19:38 <mps> only were NMUs are not allowed are 'my' pkgs :) and kernel
2021-12-17 15:19:59 <skarnet> I'm totally ok with anyone submitting MRs for anything, God knows we don't need more hurdles slowing things down
2021-12-17 15:20:09 <psykose> mps: if you meant suricata, the failure is most likely due to new rust version, but regardless should be fine for now to unblock the builder
2021-12-17 15:20:36 <skarnet> but I find it hypocritical to designate someone as the maintainer when they can 100% be bypassed
2021-12-17 15:20:43 <skarnet> from submission to merge
2021-12-17 15:20:44 <mps> psykose: !28568
2021-12-17 15:20:56 <psykose> ah, sure, but that you merged :p
2021-12-17 15:22:00 <mps> psykose: no I didn't merged !28568
2021-12-17 15:22:13 <psykose> i got the name confused again
2021-12-17 15:22:25 <mps> heh
2021-12-17 15:22:31 <minimal> skarnet: I agree re NMUs being merged - there's risk associated with it, especially if the non-maintainer is not aware of package-specific "complications"
2021-12-17 15:22:54 <skarnet> that's exactly what I'm afraid of
2021-12-17 15:23:09 <mps> most of devs knows whose packages are 'free' to merge and whose not
2021-12-17 15:23:35 <psykose> in my experience only trivial changes get bypassed, or maintainer is gone for a week
2021-12-17 15:23:51 <mps> and there are one person who allowed to merge whatever
2021-12-17 15:24:13 <skarnet> "most devs know" -> that's unwritten knowledge, not scalable, not transmissible
2021-12-17 15:24:22 <skarnet> and unofficial
2021-12-17 15:24:51 <mps> skarnet: best rules are unwritten ones on which we agreed during work
2021-12-17 15:25:00 <psykose> i disagree
2021-12-17 15:25:08 <mps> :)
2021-12-17 15:25:23 <mps> I don't care ;P
2021-12-17 15:25:32 <skarnet> if there's a classification between "this package can be NMU'd the shit out of" and "this package needs oversight, don't merge w/o approval" it should be written explicitly in the APKBUILD
2021-12-17 15:26:19 <mps> 'we' usually try to think and not blindly follow rules (this is what I love most in alpine)
2021-12-17 15:26:52 <dalias> i agree with skarnet here
2021-12-17 15:27:03 <dalias> unwritten rules are error-prone
2021-12-17 15:27:18 <mps> and written ones
2021-12-17 15:27:44 <skarnet> I don't know mps, I'm pretty solidly on the anarchist side but reading you makes me turn authoritarian by the minute :P
2021-12-17 15:27:51 <minimal> As maintainers are expected to take on responsibility for the packages they look after then I'd also expect in most (i.e. non emergency) cases they would be expected to ok/no-ok any NMUs to their packages also
2021-12-17 15:27:53 <dalias> at least the written ones invite human review of the potential errors
2021-12-17 15:28:02 <dalias> lol @ skarnet :)
2021-12-17 15:28:08 <minimal> s/cases/changes/
2021-12-17 15:28:08 <alpine-meetbot> minimal meant to say: As maintainers are expected to take on responsibility for the packages they look after then I'd also expect in most (i.e. non emergency) changes they would be expected to ok/no-ok any NMUs to their packages also
2021-12-17 15:29:21 <mps> well, I'm more for looking changes case by case and decide what to do than follow rules
2021-12-17 15:29:27 <dalias> as an aside, unwritten power structures are not the goal of anarchism; they're usually more subject to abuse/authoritarianism because they rely on the authority of the people who know the unwritten rules and how others will react to their being broken
2021-12-17 15:30:20 <mps> but we all follow unwritten rules which we learned through irc, MLs, and comments in patchwork and now gitlab
2021-12-17 15:31:42 <dalias> yeah. but if you want to be welcoming to new people, that really should eventually get written down somewhere
2021-12-17 15:31:49 <dalias> not necessarily as hard "rules"
2021-12-17 15:32:12 <dalias> but as being open about the assumed shared knowledge ppl are working off of
2021-12-17 15:32:18 <mps> dalias: all power structures tends to be authoritative with written or unwritten rules
2021-12-17 15:33:45 <skarnet> what dalias is saying is that having the rules written makes abuse of power more difficult
2021-12-17 15:34:08 <skarnet> and you know he's right, you're just arguing for the sake of it. :P
2021-12-17 15:34:13 <mps> dalias: yes I agree to some degree with this, but I'm lazy to add some lines to COMMITSTYLE.md and CODINGSTYLE.md, or always forgot to do this
2021-12-17 15:34:39 <mps> skarnet: no, you are wrong in last msg
2021-12-17 15:35:10 <skarnet> too bad, you're not as smart as I thought you were then :P
2021-12-17 15:35:14 <dalias> :-p
2021-12-17 15:35:25 <mps> power is usurped if there are chances and don't depend on anything else
2021-12-17 15:36:22 <mps> skarnet: I'm tired actually and had cramps in stomach, trying to fix with third red wine glass
2021-12-17 15:37:59 <mps> and if I'm smart I would play music somewhere in the wild and not sit behind the screen and keyboard
2021-12-17 15:40:52 <mps> anyone know is suricata maintainer on irc or have gitlab account?
2021-12-17 15:41:05 <mps> i.e. Steve McMaster
2021-12-17 15:42:48 <mps> psykose: you should add comment in git commit why is !28569 disabled on x86
2021-12-17 15:43:26 <psykose> considering it didn't get autoassigned (no gitlab account with same email) and the name is here https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 , i doubt it
2021-12-17 15:43:27 <psykose> mps: done
2021-12-17 15:44:34 <psykose> last commits by person was in 2017
2021-12-17 15:44:58 <psykose> everyone was NMU the packages this whole time
2021-12-17 15:45:29 <mps> yes, I see. asked just in case
2021-12-17 15:45:38 <psykose> yep, just adding what i can find
2021-12-17 15:46:38 <mps> psykose: merged suricata
2021-12-17 15:46:44 <psykose> haha
2021-12-17 15:46:51 <psykose> you merged 2 seconds before the typo fix :p
2021-12-17 15:47:20 <mps> that's realtime distro development :)
2021-12-17 15:49:48 <psykose> think that was everything failing so far
2021-12-17 15:49:50 <psykose> now we wait
2021-12-17 16:29:11 <psykose> why does aarch64 keep pulling the 1 rel lower kodi, grr
2021-12-17 16:38:57 <Saijin_Naib[m]> Hmm... So submitting MRs to update packages that I notice are out of date and I feel comfortable with is not a good practice? Never heard of NMU before now.
2021-12-17 16:39:23 <Saijin_Naib[m]> Is it better then to use the flag functionality and leave it for the maintainer?
2021-12-17 16:40:27 <mps> Saijin_Naib[m]: best (and first) is to contact maintainer, imo
2021-12-17 16:40:54 <Saijin_Naib[m]> Via mailing list? pkgs.a.o? Privately email to their email in the APKBUILD?
2021-12-17 16:41:26 <mps> then, if maintainer doesn't respond some time (depends on urgency) create MR, ask here or alpine-devel  ML
2021-12-17 16:41:53 <Saijin_Naib[m]> Hmm, alright
2021-12-17 16:41:57 <Saijin_Naib[m]> I thought I was being helpful
2021-12-17 16:41:58 <mps> contact however you think is best
2021-12-17 16:42:26 <mps> if the maintainer active on irc this will be best and fastest
2021-12-17 16:42:38 <Saijin_Naib[m]> Fair. Thank you
2021-12-17 16:48:10 <omni> will maintainers ever mind an MR?
2021-12-17 16:49:58 <Saijin_Naib[m]> My first ones were a mess, so they probably minded those 🤣
2021-12-17 16:50:58 <omni> I'd say 1) create an MR if there is none and you've got time, 2) is it hasn't been picked up in a while, poke the maintainer (should be notified by the MR) or this chat or the mailing list
2021-12-17 16:51:07 <omni> Saijin_Naib[m]: but that's how you learn
2021-12-17 16:52:03 <ikke> exactly
2021-12-17 16:54:04 <psykose> !28572 more ppc deps
2021-12-17 16:55:42 <ikke> maybe we can fix pyzmq, apparently it's an issue with the test itself
2021-12-17 16:55:48 <ikke> https://github.com/zeromq/pyzmq/issues/1274#issuecomment-610701488
2021-12-17 16:56:54 <psykose> given the date of that maybe they fixed themselves
2021-12-17 17:00:39 <ikke> possibly
2021-12-17 17:01:42 <psykose> let's see if they pass in a draft i guess
2021-12-17 17:04:08 <psykose> s390x passes
2021-12-17 17:05:20 <psykose> ppc has a fail
2021-12-17 17:05:57 <psykose> 8 fails, meh
2021-12-17 17:06:10 <psykose> what do you propose (https://gitlab.alpinelinux.org/psykose/aports/-/jobs/566300)
2021-12-17 17:07:20 <psykose> i can try enable s390x for the chain of deps, but the disable was to massage the builder anyways
2021-12-17 17:11:46 <psykose> wha, rerun passed them all
2021-12-17 17:11:51 <psykose> stupid flaky tests
2021-12-17 17:14:06 <ikke> ugh
2021-12-17 17:23:58 <psykose> i stuffed all of them into that one, but the ci cant pass as numpy is not available rebuilt
2021-12-17 17:24:27 <psykose> i can throw in a dummy numpy bump so it's built for ci at least, i guess
2021-12-17 18:18:00 <psykose> ikke: should merge the disable for now, and i'll look at the reenable another day
2021-12-17 18:18:10 <psykose> hard to test this while missing a bunch of rebuilt python anyway
2021-12-17 18:19:00 <psykose> awake for too long
2021-12-17 19:22:26 <omni> now I think I'm done with !28535
2021-12-17 19:24:43 <omni> I want to look more at this package in the future, add -openrc packages, split out into xen-pvgrub and xen-qemu-traditional are some ideas, but right now I just want to move on =)
2021-12-17 19:35:27 <omni> s/e/3/g;s/a/4/g;s/s/5/g;s/t/7/g;s/o/0/g
2021-12-17 19:35:27 <alpine-meetbot> omni meant to say: I want to look mor3 at this packag3 in th3 futur3, add -op3nrc packag3s, split out into x3n-pvgrub and x3n-q3mu-traditional ar3 som3 id3as, but right now I just want to mov3 on =)
2021-12-17 19:36:06 <omni> worth a try
2021-12-17 19:36:12 <omni> I'm not bored
2021-12-17 19:39:17 <psykose> reading is fun
2021-12-17 20:29:16 <fabled> seems meson is broken. recent python update?
2021-12-17 20:29:44 <bgs> ongoing python update
2021-12-17 21:46:30 <mps> ikke: !28571 ready to merge
2021-12-17 21:46:39 <mps> I thought to add it
2021-12-17 21:47:19 <mps> I have it long time in .config/awesome/vicious/ on my machines
2021-12-17 21:50:52 <mps> ikke: sorry, I couldn't resist
2021-12-17 22:50:17 <ikke> mps: no worry
2021-12-17 22:50:22 <ikke> I was afk
2021-12-17 22:50:45 <ikke> I'm not too picky on who merges it
2021-12-17 22:51:24 <mps> I'm happy you made it, so I don't have to do :)
2021-12-17 22:52:49 <mps> just one question, why you put it in /usr/share/$luaver and not to /usr/share/awesome/lib? I assume you have good reason
2021-12-17 22:53:31 <ikke> Honestly I just copied what archlinux did in this regard, and it kind of made sense to me as vicious is a stand-alone library
2021-12-17 22:54:08 <mps> ok, at the end it doesn't matter where it is
2021-12-17 22:56:06 <ikke> I tested it on my laptop and it works
2021-12-17 22:57:08 <mps> I don't have any doubt
2021-12-17 22:57:29 <ikke> I first built it for lua 5.3, but then found out that awesomewm uses lua 5.1
2021-12-17 22:57:48 <mps> yes
2021-12-17 22:58:28 <ikke> Fixed it with a symlink locally before I rebuilt the package
2021-12-17 23:00:01 <mps> I see a lot merges in awesomewm and hope for new release soon, even was tempted to build current git master but don't have strong reasons
2021-12-17 23:00:46 <ikke> aha, nice to see
2021-12-17 23:00:53 <mps> arch Aur have git version already
2021-12-17 23:01:01 <ikke> last release has been a while ago, though it's stable for me
2021-12-17 23:01:12 <ikke> I haven't installed it from aur
2021-12-17 23:01:22 <mps> ofc it is 'super stable'
2021-12-17 23:02:17 <ikke> I was able to obtain a new laptop, so used that opportunity to install alpine on it
2021-12-17 23:02:57 <mps> my daughter is happy with awesome after I told her to install it and try for some days
2021-12-17 23:03:16 <ikke> nice
2021-12-17 23:03:23 <mps> s/some/few/
2021-12-17 23:03:23 <alpine-meetbot> mps meant to say: my daughter is happy with awefew after I told her to install it and try for some days
2021-12-17 23:05:01 <mps> I think I should show it to my nephew (who is web designer) and tell him it is better than xfce for his workflow
2021-12-18 00:57:25 <omni> many years ago I decided to try tiling WMs, so I did some research and a list of a few to try out, first on that list was awesome and I didn't try any other and also never did any configuration, it was simply awesome
2021-12-18 00:58:06 <omni> I haven't used awesome for a long time though, but that's a longer story, and now I use sway
2021-12-18 02:28:06 <Thermi> Are there issues known with so:libcrypto.so.3 in current testing?
2021-12-18 02:28:08 <Thermi> https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/566621#L89
2021-12-18 02:28:19 <Thermi> Looks like it's not in the packages available at build time on the builders
2021-12-18 03:25:26 <Ariadne> hilarious if true
2021-12-18 03:25:39 <Ariadne> because that would mean that openssl 3.0.1 introduced an ABI break
2021-12-18 03:34:02 <orbea> makes you wonder if openssl upstream knows what they are doing
2021-12-18 03:37:28 <Ariadne> i believe i opened a TSC issue to discuss whether they know what they are doing
2021-12-18 03:37:38 <Ariadne> because it is my opinion that they do not
2021-12-18 03:37:47 <Ariadne> but i cannot make that kind of decision unilaterally
2021-12-18 03:38:45 <orbea> i've been skeptical since seeing all the security issues a while back, but I dont have the experience to assess the current code.
2021-12-18 04:06:04 <omni> I get sha512sum mismatch on !28589 but don't think I should, but I'm also pretty tired
2021-12-18 09:45:45 <psykose> Thermi: i don't know what the issue is, but anything that uses libcrypto/libssl 3 does not autoinstall and fails with that, unless you manually add libssl3 yourself for instance
2021-12-18 14:27:43 <psykose> ppc ci gets stuck on package upload for some reason
2021-12-18 14:30:12 <ikke> Happens from time to time, not sure why (something network related)
2021-12-18 14:32:19 <psykose> yeah, strange
2021-12-18 15:09:49 <psykose> ikke: is there anyone working on bumping testing for py3.10 or should i give it a try
2021-12-18 15:10:30 <psykose> or, i guess it already was, but some things were missed
2021-12-18 15:10:30 <psykose> hm
2021-12-18 15:10:49 <ikke> yeah, it seems to have been rebuilt partially
2021-12-18 15:24:33 <psykose> what's the easiest way to bump everything by so? the testing APKINDEX does have a ton of so:libpython3.9.so.1.0 in it, but all the tools seem to not like searching by this
2021-12-18 15:27:17 <ikke> apk list --depends so:libpython3.9.so
2021-12-18 15:28:26 <psykose> ah, thanks
2021-12-18 15:39:35 <psykose> !28614 should be all of them
2021-12-18 15:41:42 <lmarz> psykose: testing/imath has the variable _python_ver
2021-12-18 15:41:48 <psykose> ah, thanks
2021-12-18 15:47:27 <psykose> oh, the libssl3/libcrypto3 provides are broken, that's why they don't install on testing
2021-12-18 15:47:37 <psykose> unless this is a valid provide https://img.ayaya.dev/Z4i1c5VJmRex
2021-12-18 15:47:58 <Ariadne> they are intentionally namespaced yes
2021-12-18 15:48:08 <Ariadne> anyone which depends on them should rebuild i guess
2021-12-18 15:49:00 <psykose> nothing intentionally depended on them, but some testing packages were forgotten to be rebuilt
2021-12-18 15:49:03 <psykose> sure, i'll bump them
2021-12-18 15:49:52 <psykose> that causes the earlier error from the ci fail, where libvmime can't be pulled
2021-12-18 15:54:03 <psykose> !28617
2021-12-18 16:11:58 <aparcar> Ariadne: hi, could you please rebase your macos branch to the latest master branch?
2021-12-18 16:39:10 <Ariadne> aparcar: done
2021-12-18 16:44:04 <aparcar> thanks!
2021-12-18 16:44:45 <aparcar> Ariadne: don't you need this PR too? https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/83
2021-12-18 16:45:13 <Ariadne> it builds for me on macOS 12
2021-12-18 16:45:21 <Ariadne> but is harmless
2021-12-18 16:46:14 <aparcar> ok it crashes on my macOS 12
2021-12-18 16:46:21 <aparcar> strange...
2021-12-18 16:49:04 <aparcar> Ariadne: I'm seeing a bunch of new warnings too https://paste.debian.net/1223977/
2021-12-18 16:49:46 <Ariadne> those warnings are harmless
2021-12-18 16:51:09 <aparcar> Ariadne: ok thank you
2021-12-18 16:51:32 <Ariadne> the first 4 i intentionally added
2021-12-18 16:51:44 <aparcar> is alpine using fakeroot at all? Since APK is broken with fakeroot on Macs I'm wondering if I can fix it somehow?
2021-12-18 16:51:51 <Ariadne> to note that uid/gid cache always uses the system LDAP
2021-12-18 16:52:05 <Ariadne> yes, alpine uses fakeroot, but alpine does not target macOS :p
2021-12-18 16:52:31 <aparcar> fair enough
2021-12-18 16:55:57 <Ariadne> i'm not sure yet how to fix fakeroot
2021-12-18 16:56:00 <aparcar> Ariadne: would it be possible to remove all of _fstat$INODE64 by enabling it by default?
2021-12-18 16:56:09 <Ariadne> no
2021-12-18 16:56:26 <Ariadne> this is an ARM-specific issue
2021-12-18 16:56:33 <Ariadne> apple retired the old ABI on ARM
2021-12-18 16:56:41 <Ariadne> fakeroot needs to support both ABIs
2021-12-18 16:57:07 <aparcar> and we can't add a wrapper or something?
2021-12-18 17:02:27 <Ariadne> no, the issue is that fakeroot itself needs to be fixed
2021-12-18 17:02:31 <PJ[m]> can the maintainer of package be replaced if they haven't been active for past few months?
2021-12-18 17:02:44 <Ariadne> yes, but it is good practice to email them and cc alpine-devel
2021-12-18 17:20:07 <aparcar> Ariadne: cross compiling doesn't work for lib fetch anymore, is it possible your static linking broke it? https://paste.debian.net/1223983/
2021-12-18 17:24:04 <psykose> wonder why it's missing -D_GNU_SOURCE
2021-12-18 17:29:50 <Ariadne> aparcar: i'll look into it later
2021-12-18 17:30:01 <Ariadne> i do not have time atm, sorry
2021-12-18 17:30:39 <Ariadne> psykose: nothing in apk should be _GNU_SOURCE
2021-12-18 17:32:19 <Ariadne> aparcar: i would be surprised if cross-compiling ever worked on meson, tbh
2021-12-18 17:34:47 <Ariadne> aparcar: i suspect it is related to the libportability stuff.  for example, -DNEED_MEMRCHR is in cflags, but it should not be needed on a musl or glibc target
2021-12-18 17:35:30 <Ariadne> if i were to guess, bits of the macOS SDK are leaking into the build somehow
2021-12-18 19:21:33 <bl4ckb0ne> did somebody already bumped meson for 3.10?
2021-12-18 19:25:17 <psykose> yes
2021-12-18 19:25:37 <ikke> 72c7c81a392a1c7109cde72690371905840a6e2d
2021-12-18 19:25:42 <psykose> your mirror might be out of date
2021-12-18 20:33:06 <omni> psykose: this is probably hoping for too much, but what if nomad 1.2.x doesn't have this problem (I'm sure it has)
2021-12-18 20:33:41 <omni> but nodejs14 just for nomad..
2021-12-18 20:33:43 <psykose> it also uses ember
2021-12-18 20:34:20 <omni> yeah, thought so
2021-12-18 20:34:41 <psykose> i'm just putting it there as a possibility, no difference to me if it gets fixed or not
2021-12-18 20:35:43 <omni> me neither, really, I just think nomad is interesting but I don't work with such things right now
2021-12-18 20:41:20 <bl4ckb0ne> which one is the official mirror? dl-cdn.alpinelinux.org?
2021-12-18 20:41:44 <psykose> anything under alpinelinux.org i would guess
2021-12-18 20:41:47 <psykose> dl-cdn gets filled first
2021-12-18 20:42:07 <bl4ckb0ne> made the switch and meson is still acting out huh
2021-12-18 20:42:13 <psykose> can you post some errors
2021-12-18 20:42:24 <bl4ckb0ne> sure
2021-12-18 20:42:47 <bl4ckb0ne> https://paste.sr.ht/~bl4ckb0ne/e453209510105380430ccb1905c6df5176f03db3
2021-12-18 20:43:03 <psykose> and of a apk upgrade -Uia
2021-12-18 20:43:14 <psykose> you should have 0.60.2-r1
2021-12-18 20:43:31 <bl4ckb0ne> yup
2021-12-18 20:43:42 <bl4ckb0ne> -Uia added some stuff but meson still errors out
2021-12-18 20:43:50 <psykose> what arch
2021-12-18 20:55:04 <bl4ckb0ne> x86_64
2021-12-18 20:56:17 <ikke> bl4ckb0ne: apk policy meson
2021-12-18 20:56:26 <ikke> bl4ckb0ne: apk policy python3
2021-12-18 20:56:45 <ikke> Do you have things that hold back python3 to 3.9?
2021-12-18 20:56:48 <bl4ckb0ne> python3 lists 3.9.7 and 3.10
2021-12-18 20:56:49 <ikke> Custom packages?
2021-12-18 20:56:53 <bl4ckb0ne> hmmm perhaps
2021-12-18 20:56:57 <ikke> apk del python3
2021-12-18 20:56:59 <ikke> what does that say?
2021-12-18 20:57:26 <bl4ckb0ne> https://paste.sr.ht/~bl4ckb0ne/a17a9c1cca76f05ef338081717c09548c85f24b1
2021-12-18 21:05:45 <psykose> renderdoc is 3.9
2021-12-18 21:05:56 <psykose> and also cannot be rebuilt to 3.10 as it fails
2021-12-18 21:06:52 <psykose> along with a few others, and the rest that pass are in !28614
2021-12-18 21:07:15 <ikke> bl4ckb0ne: apk add 'python3>3.9'
2021-12-18 21:07:21 <psykose> if you del it you should get a 3.10 upgrade
2021-12-18 21:12:20 <minimal> omni, psykose: are you working on updating the nomad package?
2021-12-18 21:12:43 <mps> uh, I got this with less on 3.15-stable 'Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default'
2021-12-18 21:12:46 <psykose> yep
2021-12-18 21:13:38 <minimal> psykose: cool, I build 1.1.6 locally a while ago and was intending to do a MR for it
2021-12-18 21:13:52 <psykose> it can't build with nodejs16, so that is the only issue
2021-12-18 21:14:28 <minimal> bummer. Strictly speaking the UI is not 100% required but it would be useful to have it working
2021-12-18 21:23:55 <bl4ckb0ne> ikke: did nothing
2021-12-18 21:24:22 <bl4ckb0ne> yeeting renderdoc did it
2021-12-18 21:24:23 <ikke> sorry, >= 3.10
2021-12-18 21:24:25 <ikke> ok
2021-12-18 21:24:43 <bl4ckb0ne> thanks!
2021-12-18 21:24:56 <ikke> But that should in the future help with determining what is holding it back
2021-12-18 21:28:11 <omni> minimal: would you just skip 'make ember-dist' then?
2021-12-18 21:29:13 <minimal> omni: AFAIK for Nomad, like Consul, there's a way to build without the UI. Lemme see if I can find a reference
2021-12-18 21:29:34 <psykose> yes, you skip ember-dist
2021-12-18 21:30:10 <psykose> and maybe static-assets aswell
2021-12-18 21:31:19 <minimal> psykose: ah, I was recalling a discussion to disable the UI from running, not from building: https://github.com/hashicorp/nomad/pull/4088
2021-12-18 21:33:24 <psykose> i wonder if it crashes if you don't pass disable ui with it missing
2021-12-18 22:53:30 <Ariadne> Hello71: do not assign crap like that to me
2021-12-18 22:57:04 <Hello71> 1. do not talk like that to me
2021-12-18 22:57:16 <Hello71> 2. you're wrong, it is broken.
2021-12-18 22:57:25 <Hello71> ERROR: unable to select packages:   openssl1.1-compat-libs-static (no such package):     required by: .makedepends-apk-tools-20211218.225649[openssl1.1-compat-libs-static] 
2021-12-18 22:59:09 <psykose> yes, it needs to be just openssl-libs-static to work
2021-12-18 22:59:13 <Ariadne> hmm, so it is.
2021-12-18 22:59:44 <Ariadne> Hello71: okay, next time if you assign a bug like that to me, explain *why* you are doing it
2021-12-18 22:59:52 <Ariadne> i'm not interested in playing tech support
2021-12-18 23:01:56 <Hello71> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/32#note_199304
2021-12-18 23:02:05 <Hello71> i would have moved it but no permissions
2021-12-18 23:02:32 <Ariadne> i predict this URL is going to be irritating to me
2021-12-18 23:02:46 <ikke> It's the same issue
2021-12-18 23:02:48 <ikke> but then in TSC
2021-12-18 23:03:01 <Ariadne> well, either way, i am testing a fix
2021-12-18 23:14:30 <Ariadne> Hello71: sorry for being snippy by the way
2021-12-18 23:15:03 <Ariadne> Hello71: are you confident in that D change?  personally i am having a lot of doubt about gdc lately
2021-12-18 23:15:41 <Hello71> tbh, i would be more sympathetic to your complaints of wasting time doing tech support if i didn't get comments like https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27930#note_195591. i am aware that 3.15 is broken, i don't really appreciate a reminder.
2021-12-18 23:15:56 <Hello71> not that much, but i can't see how it would break anything not already broken
2021-12-18 23:16:13 <Hello71> do you think it does some dlopen nonsense?
2021-12-18 23:17:26 <Ariadne> well, gdc is failing to link libucontext again
2021-12-18 23:17:58 <Ariadne> but i'm confused, as libgphobos does link it as a dependency
2021-12-18 23:18:11 <Ariadne> so i have no idea whats going on, but it causes D programs to FTBFS
2021-12-18 23:18:18 <Hello71> link?
2021-12-18 23:18:24 <ikke> gir-to-d
2021-12-18 23:18:29 <Hello71> (or instructions i guess)
2021-12-18 23:18:40 <Ariadne> yes, an example is try to build community/gir-to-d
2021-12-18 23:19:17 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/gir-to-d/gir-to-d-0.22.0-r1.log
2021-12-18 23:19:20 <Ariadne> Hello71: regarding that MR comment, it was meant as a reminder to myself to do the backport whenever it gets merged
2021-12-18 23:19:49 <Hello71> uh, ok. that's not how i interpreted it.
2021-12-18 23:20:27 <Ariadne> sorry :)
2021-12-18 23:21:54 <Ariadne> hmm, i just noticed it is using libgphobos.a
2021-12-18 23:22:15 <Ariadne> so, i guess we need to fix gdc to use libucontext.a, in that scenario
2021-12-18 23:22:27 <Ariadne> to me, i feel like the musl support in gdc is really half baked
2021-12-18 23:23:00 <Hello71> yes, i saw it is using .a. i wasn't sure if that is normal for d
2021-12-18 23:23:15 <Xe> is there any particular reason that abuild doesn't allow more than one maintainer per package?
2021-12-18 23:23:49 <Hello71> i.e. if there is libgphobos.so why does it need libgphobos.a for non-static
2021-12-18 23:25:50 <ikke> Xe: The idea is that ultimately there is at least one person has the main responsibility for a package. Technically it's because there is just space for a single maintainer in the apk file
2021-12-18 23:26:17 <Xe> doesn't at least imply that n can be greater than one though?
2021-12-18 23:26:51 <ikke> More people can contribute to a package, but one person is responsible
2021-12-18 23:28:38 <Hello71> well it also doesn't work with -shared-libphobos, so apparently gdc is totally broken?
2021-12-18 23:28:48 <Ariadne> amazing
2021-12-18 23:29:06 <Hello71> it also doesn't work with -nophoboslib but i think that's expected
2021-12-18 23:29:23 <Ariadne> i wonder if we should make an acceptance test suite for the toolchain
2021-12-18 23:29:54 <Ariadne> this was working in GCC 10, i suspect that the D people screwed up porting to GCC 11
2021-12-18 23:29:54 <Hello71> isn't that called building the distro? :p
2021-12-18 23:30:03 <Ariadne> well, i mean, like
2021-12-18 23:30:17 <Ariadne> compile a set of trivial programs
2021-12-18 23:30:19 <Hello71> if it builds the distro, then it has acceptable functionality
2021-12-18 23:30:26 <Ariadne> before sending it off to build the distro
2021-12-18 23:30:48 <Ariadne> i think the only reason alpine gained D support in first place was because Cogitri was interested in it
2021-12-18 23:30:58 <Ariadne> and, his interest appears to have waned in favor of rust
2021-12-18 23:31:31 <mps> :)
2021-12-18 23:32:05 <Ariadne> so i wonder if it is worth keeping D
2021-12-18 23:32:20 <Ariadne> because upstream seems to not do any testing against musl
2021-12-18 23:32:25 <mps> Ariadne: good question
2021-12-18 23:46:44 <Ariadne> Hello71: also, while you are here, what is your opinion on enabling LTO
2021-12-18 23:47:53 <Hello71> quite beneficial but remains somewhat risky
2021-12-18 23:48:32 <mps> yes
2021-12-18 23:49:01 <Hello71> risk is less than few years ago since fedora and opensuse have enabled by default and arch is enabling in near future
2021-12-18 23:51:07 <Hello71> many packages must be excluded. main issues nowadays are gcc (available internally but broken if set in CFLAGS), glibc, musl, some qt programs (wireshark), valgrind, everything that uses .symver (ignored by musl but afaik will still be present in source code to cause compile errors)
2021-12-18 23:51:09 <mps> tempting but to early imo
2021-12-18 23:51:43 <Hello71> and dalias doesn't like it because it surfaces bugs in broken programs
2021-12-18 23:52:30 <mps> s/to/too/
2021-12-18 23:52:30 <alpine-meetbot> mps meant to say: tempting but too early imo
2021-12-18 23:53:35 <Hello71> i would prefer to enable -fstack-clash-protection -fcf-protection -Werror=format-security plus -fno-plt -mtls-dialect=gnu2 for applicable arches in 3.15, then consider lto for 3.17
2021-12-18 23:53:59 <Hello71> s/15/16/
2021-12-18 23:53:59 <alpine-meetbot> Hello71 meant to say: i would prefer to enable -fstack-clash-protection -fcf-protection -Werror=format-security plus -fno-plt -mtls-dialect=gnu2 for applicable arches in 3.16, then consider lto for 3.17
2021-12-18 23:58:03 <Hello71> since -fno-plt -mtls-dialect=gnu2 is likely to cause some minor breakage, and lto is guaranteed to cause major breakage, i think it would be good to split it up so we can have a better idea of what caused breakage
2021-12-18 23:58:38 <Hello71> oh, and also alpine has some static packages and those are even more annoying to deal with if lto is enabled system-wide
2021-12-19 00:00:46 <dalias> hello71, i don't like it because it defeats the purpose of TUs making build resource requirements bounded
2021-12-19 00:01:00 <dalias> i find surfacing bugs just to be another practical reason not to do it
2021-12-19 00:01:05 <psykose> unless we also move to clang with flto=thin
2021-12-19 00:01:09 <dalias> especially when it already leaves programs same-speed or slower
2021-12-19 00:01:18 <Hello71> actually that's not true, both gcc and lto have had lto unit splitting for some time now
2021-12-19 00:01:33 <psykose> how do you enable that in gcc
2021-12-19 00:01:58 <dalias> hello71, pretty sure that does *not* make resource usage bounded
2021-12-19 00:02:06 <dalias> just less ridiculous than full LTO
2021-12-19 00:02:11 <Hello71> imo the theory is sound, that TUs shouldn't be arbitrary optimization barriers (assuming bug-free programs), the optimization boundaries should be determined by compiler convenience, not files
2021-12-19 00:02:22 <dalias> i think it still has to load all the .o's to decide how to start splitting them up
2021-12-19 00:03:03 <Hello71> afaik the resource usage is still dominated by the actual optimizing
2021-12-19 00:03:54 <dalias> i doubt that's true when you have 100k .o files
2021-12-19 00:04:09 <Hello71> there is a practical problem with lto and memory usage though, which is that if you compile "normally", the big TUs are usually spread throughout the program. some jobs will use more ram and some will use less. if lto is enabled, then all the jobs will use maximum ram all at the same time
2021-12-19 00:04:41 <Hello71> do any programs currently exist with 100k .o files? even firefox and chromium are not that fat
2021-12-19 00:05:16 <Hello71> and if you're going to go down this path, then your bottleneck will still be the linker, not the lto aggregator
2021-12-19 00:05:45 <psykose> maybe ceph is even more fun with lto
2021-12-19 00:06:55 <Hello71> i don't see an issue if the lto aggregator takes 2G to manage 100k .o files if the linker takes 4G either way. if anything, i think lto should slightly reduce the amount of work for the actual linker to do
2021-12-19 00:09:48 <dalias> linked for 100k .o files should take like 10M
2021-12-19 00:09:52 <dalias> linker*
2021-12-19 00:10:00 <dalias> taking 4GB is just a huge gratuitous bug
2021-12-19 00:10:06 <Hello71> "should" but how much does bfd actually use? :p
2021-12-19 00:10:35 <Hello71> but you miss my point, the lto splitter should use much less peak ram than the linker
2021-12-19 00:12:43 <dalias> i'm doubtful about that
2021-12-19 00:13:07 <dalias> conceptually, LTO splitter needs to look at a lot of call graph stuff between files which requires working data structures
2021-12-19 00:13:27 <dalias> otoh linker is designed to work all in-place from the input files on disk with no need for any in-memory data structures
2021-12-19 00:13:28 <Hello71> if each compile job takes 100 MB, lto takes 2 GB, and the linker takes 10 MB, then i would agree with you. is that true though?
2021-12-19 00:13:42 <dalias> it's only not true only because we have awful linkers
2021-12-19 00:13:53 <dalias> designed around GNU silliness
2021-12-19 00:14:00 <dalias> and OOP dogmatism
2021-12-19 00:14:12 <dalias> rather than efficient use-in-place data structures ELF provided
2021-12-19 00:15:14 <Hello71> i look forward to seeing your new, efficient and standards-compliant linker then. i will be ecstatic to delete bfd and its 1000 near-identical linker scripts from my system
2021-12-19 00:23:04 <Hello71> i will suggest "oyster" as a terrible programmer joke name
2021-12-19 00:42:32 <Ariadne> i would unironically be ecstatic to delete GNU ld
2021-12-19 00:46:12 <Hello71> absolutely
2021-12-19 00:47:23 <Hello71> about gdc, it was broken by https://github.com/gcc-mirror/gcc/commit/285d81be9725acc36dc8eca48d4df506cd5e6f6f
2021-12-19 00:47:51 <Hello71> i'm 99% sure
2021-12-19 00:49:44 <Hello71> https://github.com/gcc-mirror/gcc/blob/master/libphobos/m4/druntime/libraries.m4#L213 skips finding ucontext if it is implemented in asm, but then https://github.com/gcc-mirror/gcc/blob/master/libphobos/libdruntime/config/x86/switchcontext.S#L32 it's just not implemented if cfi is enabled, the file is just blank
2021-12-19 00:51:44 <Hello71> also, libgphobos.a has a 656-byte file libgdruntime_convenience_la-switchcontext.o which contains no symbols and has no effect on the compiled executable, it just takes up 656 bytes
2021-12-19 01:21:47 <Ariadne> Hello71: seems likely.
2021-12-19 02:16:52 <Hello71> ncopa: do you remember where you got https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/qt5-qtwebengine/qt-musl-thread-stacksize.patch from? i think it doesn't work, at least not completely. in #13333 i did gdb qutebrowser and found it doesn't call pthread_attr_setstacksize at all
2021-12-19 02:19:57 <ktprograms> Hello71: bit funny about #13333, when I had a 'renderer process crashed' error on youtube, the backtrace was in Chromium v8 JS engine.
2021-12-19 02:20:09 <Hello71> what?
2021-12-19 02:22:21 <ktprograms> Hello71: Oh, sorry, it seems to be the same backtrace, but it was also happening for me when it was running qt with single threaded, so I don't think it's a thread stack size problem.
2021-12-19 02:22:44 <Hello71> what do you mean "running qt with single threaded"
2021-12-19 02:23:03 <Hello71> i guess you are confusing single thread with single process
2021-12-19 02:25:56 <ktprograms> Hello71: I can't remember the exact command, but it was some --qt-flag recommened by The-Compiler on #qutebrowser when I was trying to debug this error (because without it the renderer process was crashing but its backtrace wasn't being shown)
2021-12-19 02:26:33 <Hello71> --qt-flag single-process.
2021-12-19 02:26:54 <ktprograms> Hello71: I think that's the one
2021-12-19 02:27:09 <Hello71> despite what linux kernel will tell you, processes and threads aren't the same
2021-12-19 02:29:28 <ktprograms> Hello71: Oh, I see, but what I mean is that I didn't see any thread related info in the backtrace: https://0x0.st/-F5P.txt
2021-12-19 02:29:30 <Hello71> and i checked, it is 100% absolutely caused by thread stack overflow. it's crashing at a call instruction, and $rsp is right at the bottom of the valid map
2021-12-19 02:29:56 <Hello71> yes, that's what a stack overflow looks like
2021-12-19 02:30:26 <ktprograms> Hello71: Oh, I see. Sorry, I don't know much about debugging this sort of stuff.
2021-12-19 02:30:28 <Hello71> the first suspicious point is that it goes to #953 with apparently valid values. the proof needs checking $rsp though
2021-12-19 02:30:33 <Hello71> algitbot: bad bot
2021-12-19 02:31:32 <ktprograms> Hello71: You mean the fact that all of a sudden the backtrace just goes to invalid addresses?
2021-12-19 02:32:10 <Hello71> no, that's normal. it's caused by missing debug symbols
2021-12-19 02:32:20 <Hello71> you can fix it by installing musl-dbg
2021-12-19 02:32:45 <ktprograms> Hello71: Then what do you mean by 'goes to #953 with apparently valid values'?
2021-12-19 02:35:27 <Hello71> i mean that the stack trace is very long
2021-12-19 02:35:51 <ktprograms> Hello71: I don't quite understand, why does a long stack trace indicate a segfault?
2021-12-19 02:36:02 <Hello71> so it provides basis for speculation that it was so long that it exceeded the space allocated
2021-12-19 02:36:32 <Hello71> but the stack trace doesn't contain enough data for a conclusion, because it doesn't say how much space each frame used, only the total number of frames
2021-12-19 02:36:41 <ktprograms> Hello71: Ah I see. Thanks for explaining it to me.
2021-12-19 02:37:06 <Hello71> it also doesn't tell the amount of space allocated
2021-12-19 02:38:49 <ktprograms> Hello71: The flatpak version doesn't crash, do you know if flatpak provides more stack space?
2021-12-19 02:38:58 <Hello71> i assume it's using glibc
2021-12-19 02:39:39 <ktprograms> Hello71: Oh, that's right.
2021-12-19 02:53:46 <Thermi> Can somebody please enlighten me why that dependency failed? https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/566621
2021-12-19 02:54:11 <Thermi> the dependencies are at the very least in latest testing, so why do they fail?
2021-12-19 02:54:30 <Thermi> building it locally also works. libvmime is in testing, so that should work fine
2021-12-19 02:54:51 <Thermi> and libcrypto and libssl are in main, so naturally that should work aswell
2021-12-19 02:57:56 <psykose> !28617 Thermi 
2021-12-19 02:58:21 <psykose> they were build against openssl3, then openssl3 got namespaces so the so: provide for it changed
2021-12-19 02:58:30 <psykose> so, they cannot find so:libssl3 as it doesn't exist
2021-12-19 02:58:54 <psykose> that mr should fix the rest of the openssl3 stragglers
2021-12-19 02:59:04 <psykose> like libvmime in the ci there
2021-12-19 03:49:53 <thiagowfx> hi y'all, I'm new to alpine and submitted my first aport a week ago !28364, any feedback is appreciated. Do I need to look for a maintainer/committer if I want to add it to testing/ ?
2021-12-19 03:54:30 <ktprograms> thiagowfx: Mark yourself as the maintainer. The one who adds the package to aports is responsible for keeping it up to date and fixing any problems. (But don't be afraid to ask for help here)
2021-12-19 03:56:44 <thiagowfx> ktprograms: I see. Is that common practice even without having commit access? (e.g. compared to Arch's AUR). Maybe that
2021-12-19 03:57:02 <thiagowfx> * maybe that's why no one looked at it, I will re-send it by adding myself as a maintainer then :p
2021-12-19 03:58:01 <ktprograms> thiagowfx: The maintainer doesn't need commit access, it's just to know who's in charge of keeping it up to date etc.
2021-12-19 03:59:01 <ktprograms> thiagowfx: The more likely reason why no one's looked at it is that there are a lot of open MRs and (I think) the people with merge access are busy.
2021-12-19 03:59:28 <ktprograms> thiagowfx: When a new version is released, just make a MR that updates the APKBUILD.
2021-12-19 04:00:57 <thiagowfx> ktprograms: makes sense, thanks
2021-12-19 06:35:48 <skarnet> minimal: everything is ready for the utmps init script, I just need to release new versions of skaware first (small fixes all around)
2021-12-19 06:37:51 <skarnet> question: I have 3 services (utmpd, wtmpd, utmp-init) and they all *need to* be in the boot runlevel, and utmp won't work if they're not running. What's the official way of doing it? can I add "rc-update add utmpd boot" in a post-install script? or even at this low level do the users need to do that manually?
2021-12-19 07:34:53 <mps> skarnet: users should do this, not pkgs
2021-12-19 07:38:28 <skarnet> yes, for "normal" services, that's understood
2021-12-19 07:38:40 <skarnet> because users control the default runlevel
2021-12-19 07:38:52 <skarnet> but for "essential" services in boot or sysinit, that's not the same
2021-12-19 07:39:04 <ikke> That's arranged by the installer
2021-12-19 07:39:26 <ikke> setup-alpine
2021-12-19 07:39:35 <skarnet> ah
2021-12-19 07:40:20 <skarnet> should I submit a patch to setup-alpine then, to rc-update add the utmps services in the boot runlevel? (after I've pushed the new version)
2021-12-19 07:40:21 <mps> we allowed just one exception to this rule, and that was mistake
2021-12-19 07:41:16 <mps> no
2021-12-19 07:41:32 <mps> it is not essential, afaik
2021-12-19 07:41:48 <skarnet> look
2021-12-19 07:42:05 <skarnet> I'm not trying to push things or force utmps down users' (or your) throat
2021-12-19 07:42:11 <skarnet> but I want things to *work*
2021-12-19 07:42:27 <skarnet> if users install the package and the services are not started, it won't work and THEY WILL COMPLAIN
2021-12-19 07:42:29 <mps> maybe add patch but to ask user when running setup-alpine do these should be enabled
2021-12-19 07:43:02 <skarnet> my point is the following: utmps not installed -> all good, utmps installed -> the services should be started else this will be confusing
2021-12-19 07:43:07 <mps> users will always complain
2021-12-19 07:43:23 <mps> if it is enabled by default or disabled
2021-12-19 07:43:27 <skarnet> yes, and if stuff they expect to work doesn't work, they are right to complain
2021-12-19 07:44:06 <mps> well, we don't enable them for any pkg when it is intalled
2021-12-19 07:44:26 <skarnet> idc what the default is, I just want it to be easy and not confusing for users who actually want the feature
2021-12-19 07:44:47 <skarnet> you don't need to play gatekeeper here
2021-12-19 07:45:39 <mps> I understand that you like it to be simple but alpine has this principle to not enable anything non-essential by default
2021-12-19 07:45:48 <skarnet> AND THAT IS FINE
2021-12-19 07:46:01 <skarnet> I'm not asking for the default to be changed
2021-12-19 07:46:09 <skarnet> I'm asking where the switch should appear
2021-12-19 07:46:27 <mps> 'we' expect that our users knows what s/he wants better than we
2021-12-19 07:47:08 <skarnet> if the answer is setup-alpine, with something like "install and start utmp services? y/n" and the default is n then it's _all right with me_
2021-12-19 07:47:21 <skarnet> I just need to know where it is
2021-12-19 07:47:58 <mps> that looks acceptable but I think more discussion will follow on this
2021-12-19 07:48:14 <skarnet> you need to learn to close a file
2021-12-19 07:48:30 <mercenary> different users, different wants. This user for example doesn't want it to be a package one has to manually install, it should just be part of core.
2021-12-19 07:48:41 <mps> because this is not essential for alpine
2021-12-19 07:49:22 <mercenary> it is, for the use cases this particular user has for alpine. But that ship sailed long ago.
2021-12-19 07:49:42 <mps> mercenary: no, it is not
2021-12-19 07:49:59 <skarnet> 
ACTION turns and walks away, not looking at the explosion

2021-12-19 07:50:35 <mps> \o :)
2021-12-19 07:50:39 <ikke> in any case, yes, setup-alpine would be the place to enable this in case the user wants it
2021-12-19 07:51:39 <mps> ikke: should I add 'do you want to setup xorg-server (y/m)' ;P
2021-12-19 07:51:47 <skarnet> ikke: thanks
2021-12-19 07:53:08 <mps> how many times we told users 'run setup-xorg'?
2021-12-19 07:54:10 <ikke> It's part of setup-alpine, just an optional part
2021-12-19 07:55:52 <mps> yes, but we answered this question a looooot more times than that we don't have utmp/wtmp
2021-12-19 09:00:44 <Cogitri[m]> Ariadne: FWIW I think D upstream does work on musl support - Geod24 has upstreamed most of their work for making D work on musl
2021-12-19 09:36:22 <skarnet> yeah it's high time Alpine got the D
2021-12-19 10:03:27 <ikke> These packages in testing still have files in /usr/lib/python3.9: https://tpaste.us/ovbn 
2021-12-19 11:15:27 <nmeum> Ariadne: if the goal is to always link against utpms statically, it might make sense to remove libutmps.so entirely because build system will usually prefer that over libutmps.a if both are available, case in point the opennsh change from 04d4e07ad8bd54fe49fe32c117c47d91f31ae937
2021-12-19 11:15:40 <nmeum> > $ ldd /usr/sbin/sshd
2021-12-19 11:15:41 <nmeum> > libutmps.so.0.1 => /lib/libutmps.so.0.1 (0x4001ae9000)
2021-12-19 11:16:35 <nmeum> our /bin/busybox is also dynamically linked against libutmps btw
2021-12-19 12:00:27 <skarnet> nmeum: with psykose's latest MR, the libs are now in a separate utmps-libs package, and the utmps package containing the binaries should not depend on it
2021-12-19 12:00:51 <skarnet> so, it should already be possible to remove utmps-lib for building
2021-12-19 12:01:02 <skarnet> (or to never install it in the first place)
2021-12-19 12:01:10 <skarnet> utmps-libs*
2021-12-19 12:02:15 <nmeum> ok, I guess that works too
2021-12-19 12:02:25 <psykose> do you have a different sshd? my one does not show that in ldd
2021-12-19 12:02:57 <psykose> and yes, installing screen/others pulls in -libs only, still need to add main utmps packages to use it
2021-12-19 12:03:08 <nmeum> openssh-8.8_p1-r2 on riscv64
2021-12-19 12:03:24 <psykose> hmm
2021-12-19 12:03:40 <skarnet> psykose: utmps-libs does not pull utmps, but utmps should not pull utmps-libs either
2021-12-19 12:04:06 <nmeum> hmhm
2021-12-19 12:04:16 <nmeum> on x86_64 my /bin/busybox is also not linked dynamically against utmps
2021-12-19 12:04:20 <nmeum> but on riscv64 it is
2021-12-19 12:04:25 <nmeum> weird
2021-12-19 12:04:28 <psykose> skarnet: it doesn't :)
2021-12-19 12:04:31 <skarnet> cool :D
2021-12-19 12:04:41 <psykose> nmeum: i think this is a riscv toolchain difference then
2021-12-19 12:04:57 <psykose> maybe it is doing something funny with the linking
2021-12-19 12:05:40 <nmeum> hmhm, but if libutmps.so is not available during build then it should not link against it no matter what
2021-12-19 12:05:50 <psykose> yes, that would fix it
2021-12-19 12:06:08 <psykose> but i would guess a difference in build outcome like this to imply something else on riscv that might have other effects in the future too
2021-12-19 12:06:13 <psykose> if it is not a bug or something
2021-12-19 12:15:08 <nmeum> hmhm, might be related to !28639 but not sure
2021-12-19 12:17:26 <psykose> you would know much more than me :p i am just some random person
2021-12-19 12:19:50 <nmeum> I can debug this riscv64 utmps linking issue further later, first want to fix gcc-go on riscv64. unfourtunatly, it takes forever to re-build gcc in a riscv64 qemu environment and building it on the unmatched takes even longer :/
2021-12-19 12:23:15 <psykose> aye, stuff is incredibly slow
2021-12-19 12:40:21 <ktprograms> nmeum: Would qemu-user be faster? Or is that already what you're using?
2021-12-19 12:53:54 <nmeum> that's what i am using
2021-12-19 13:54:30 <Hello71> the cause is that riscv64 builder is permanently backlogged
2021-12-19 14:19:16 <psykose> it's the same pkgrel though, from the rebuild, regardless of if -libs was split the binary shouldn't have it in ldd, no?
2021-12-19 14:25:11 <Hello71> busybox was updated
2021-12-19 14:25:41 <Hello71> hm, or did i miss something
2021-12-19 14:26:23 <Hello71> yeah, never mind
2021-12-19 14:39:06 <minimal> skarnet: to pick up on the utmps "setup" discussion, utmp support would not be part of a base installed Alpine system and therefore setup-alpine would not enable its daemons. The utmps package should provide a /sbin/setup-utmps script that enables the init.d scripts - have a look at "setup-cloud-init" script in aports/community/cloud-init/ as an example
2021-12-19 14:44:51 <psykose> setup-udev as well is a good example
2021-12-19 14:45:06 <MY-R> for me utmps stuff could be default but "setup-utmps" sounds even better
2021-12-19 14:52:58 <minimal> MY-R: I assuming that some/many people (desktop users) do not want utmps installed by default
2021-12-19 14:54:03 <MY-R> agree with "some" but not with "many" many just dont care :) but ye setup-thing looks like Alpine way
2021-12-19 14:57:59 <Hello71> i think a proliferation of poorly-discoverable three-line setup scripts is not that good either. possibly setup-alpine should ask a single question at the end "which additional components do you want to install (udev, utmps, xorg-base)? []"
2021-12-19 14:58:45 <Hello71> s/install/configure/
2021-12-19 14:58:45 <alpine-meetbot> Hello71 meant to say: i think a proliferation of poorly-discoverable three-line setup scripts is not that good either. possibly setup-alpine should ask a single question at the end "which additional components do you want to configure (udev, utmps, xorg-base)? []"
2021-12-19 15:03:09 <MY-R> then still for people who would like to do it later and not during installation should be prepared some documentation
2021-12-19 15:06:02 <minimal> Hello71: I guess the problem is that there is a very long list of potential setup scripts when installing a typical server, i.e. cloud-init, utmps, auditd, firewall, apparmor, dockerd, etc. Likewise for desktop users. I cannot see how setup-alpine can realistically cater for more than a basic set of generic services
2021-12-19 15:06:56 <Hello71> eh, i guess it can also just print the list of setup scripts installed
2021-12-19 15:08:10 <minimal> that's an idea. Of course unless a user decides to run setup-alpine again at a later stage then that list will not reflect things like utmps which are not part of the default installed packages set...
2021-12-19 15:08:34 <skarnet> setup-foobar is fine but there needs to be an obvious place where people can see all the values of foobar they can setup
2021-12-19 15:09:27 <MY-R> ls /sbin/setup-* :P
2021-12-19 15:09:52 <skarnet> yes, because every Alpine user will think of doing this on their own :P
2021-12-19 15:09:57 <skarnet> at installation time!
2021-12-19 15:10:50 <MY-R> still would be cool to make it clear that Alpine way stuff got prefix setup- even in installer with bold text! :D
2021-12-19 15:15:31 <minimal> skarnet: the reason why have setup-* scripts it that it is policy that any <package>.post-install scripts are not supposed to enable daemons
2021-12-19 15:15:59 <skarnet> again I 100% understand that for normal services, and I generally agree with that policy
2021-12-19 15:16:17 <skarnet> for early system stuff, I wasn't sure the policy was the same
2021-12-19 15:17:49 <skarnet> setup-cloud-init doesn't look like a good example because it unconditionally enables the services
2021-12-19 15:18:02 <skarnet> I thought the point of setup-foobar was to ask the user for what they want
2021-12-19 15:19:03 <psykose> no, the individual setup-x just enable the things
2021-12-19 15:20:10 <skarnet> okay then
2021-12-19 15:23:12 <minimal> skarnet: I did it this way for cloud-init precisely as I had previously just enabled the services in the post-install script and got pushback. I did add a README.alpine file to document the need to run the setup script but do still occasionally see individuals who don't do so (as they dodn't read the README)
2021-12-19 15:24:44 <minimal> Short of writing Wiki articles for services like this I'm not sure how any Alpine lack of documentation/awareness can be addressed
2021-12-19 15:26:09 <dalias> what is this rv64 utmps linking issue? i thought the utmps stuff was just someone being allergic to static linking for wacky rules-checkboxing reasons
2021-12-19 15:27:41 <skarnet> minimal: that's exactly what I was afraid of and let's say I'm exactly 0% surprised to learn that it is already happening with other services
2021-12-19 15:35:44 <dalias> setup-* is absolutely the right way here
2021-12-19 15:39:04 <mercenary> minimal: normally I would expect it in a man page, but alpine seems to hate man pages
2021-12-19 15:39:54 <nmeum> that ain't true, we have a few man pages for apk and other stuff now
2021-12-19 15:39:54 <Hello71> i think there is possibly some confusion here. some setup scripts are packaged with alpine-conf, and do two things: 1. install the relevant package(s); 2. configure them. some setup scripts are packaged separately, and only do part 2
2021-12-19 15:40:13 <nmeum> minimal: we actually have https://docs.alpinelinux.org/user-handbook/0.1a/index.html but it's a bit stuck atm
2021-12-19 15:41:47 <Hello71> man pages should be used as a reference manual, not as a user guide. both are important for comprehensive documentation
2021-12-19 15:44:26 <mercenary> Indeed. But being used to 'other systems', I would expect the man page to at least have a mention, and more importantly a 'SEE ALSO: setup-foobar'
2021-12-19 15:45:55 <Hello71> i'm leaning towards the view that all one-time-use setup scripts, like cloud-init and udev, should be moved into alpine-conf and modified to do the installation (if not already installed) then do the configuration. then, setup-alpine can simply do (echo "available setup scripts:"; cd /sbin; ls setup-*; cd /usr/sbin; ls setup-*) or somesuch
2021-12-19 15:51:00 <Hello71> that way, users will have a list of what next step configurations are available. they may see utmps in the list and think "hm, i do need utmp support" and investigate it
2021-12-19 15:53:02 <Hello71> most setup scripts will not be used, but i think that's better than installing it with the actual package, since you can delete all of alpine-conf after completing initial setup
2021-12-19 15:54:08 <Hello71> whereas right now if you install eudev it always comes with setup-udev which you can't remove even if you already set up udev. it only occupies ~4k on disk but still wasteful
2021-12-19 15:55:32 <minimal> Hello71: adding those scripts to alpine-conf would then mean various package maintainers having to add them to alpine-conf and potentially also occasionally modify them in alpine-conf based on changes to their own packages
2021-12-19 15:56:31 <Hello71> that sounds fine to me. if they require very frequent modifications then they should be init scripts or something, because the user should only have to run the script once
2021-12-19 15:58:29 <MY-R> does Alpine thinking about switching to systemd udev or will stay with eudev?
2021-12-19 15:58:43 <minimal> mercenary: manpages are optional and so many people will not have the relevant <package>-doc installed
2021-12-19 15:58:49 <dalias> last i heard the choices were maintaining eudev or moving to mdev
2021-12-19 15:58:52 <dalias> not systemd's udev
2021-12-19 15:59:05 <Hello71> eudev in short term, mdev(d?) in long term
2021-12-19 15:59:05 <dalias> i can't imagine systemd not intentionally making their udev incompatible over and over
2021-12-19 15:59:43 <nmeum> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/12#note_177717
2021-12-19 16:00:07 <minimal> nmeum: re the user handbook, perhaps it would make sense to have "desktop" and "server" specific sections?
2021-12-19 16:00:11 <Hello71> yes, libudev-zero+mdev(d)
2021-12-19 16:00:18 <Hello71> minimal: #alpine-docs
2021-12-19 16:00:29 <Ariadne> MY-R: eudev for now, i help with the upstream maintenance
2021-12-19 16:00:33 <Ariadne> mdevd in future
2021-12-19 16:00:40 <nmeum> minimal: the alpine documentation team is always looking for more contributors I believe ;)
2021-12-19 16:00:43 <Ariadne> the real question there is libudev-zero
2021-12-19 16:01:20 <minimal> nmeum: I walked right into that didn't it? ;-)
2021-12-19 16:01:26 <minimal> s/it/I/
2021-12-19 16:01:26 <alpine-meetbot> minimal meant to say: nmeum: I walked right into that didn't I? ;-)
2021-12-19 16:01:32 <nmeum> (:
2021-12-19 16:01:40 <Hello71> Ariadne: what do you mean
2021-12-19 16:01:48 <MY-R> udev is all time incompatibile, isnt openembedded "responsible" for patches?
2021-12-19 16:04:54 <Ariadne> Hello71: libudev-zero seems to be incomplete
2021-12-19 16:05:33 <psykose> mdevd also seems to be, unless there is something else for user-installable .udev scripts, and there is some way to load multiple confs
2021-12-19 16:06:04 <orbea> is libudev-zero potentially going to be complete in the future or is that a dead end?
2021-12-19 16:06:12 <Ariadne> psykose: that's not a desired feature in alpine
2021-12-19 16:06:21 <psykose> sure, that's fine
2021-12-19 16:06:30 <psykose> there are currently some number of .udev in packages
2021-12-19 16:06:43 <Ariadne> yes but those install to /etc/udev
2021-12-19 16:06:54 <Ariadne> or is that what you mean by user-installable
2021-12-19 16:07:24 <Ariadne> i thought you meant some crazy stuff like $HOME/.udev/whatever
2021-12-19 16:07:25 <Ariadne> :D
2021-12-19 16:07:30 <orbea> lol
2021-12-19 16:08:13 <MY-R> in gentoo they switched from eudev to systemd udev and working fine
2021-12-19 16:08:35 <psykose> Ariadne: eg libu2f-host having /usr/lib/udev/rules.d/70-u2f.rules
2021-12-19 16:08:47 <Ariadne> psykose: yes, that's fine
2021-12-19 16:09:04 <Ariadne> MY-R: yes, well, we are using eudev, and i am maintaining it
2021-12-19 16:09:05 <psykose> are those read by mdevd/libudev-zero? i don't personally know how that loading works
2021-12-19 16:09:19 <Ariadne> psykose: they will need to be translated to mdev format
2021-12-19 16:10:09 <MY-R> Ariadne: so every distribution basically maintaining alone own eudev? :/
2021-12-19 16:10:28 <Ariadne> no.  eudev has a new upstream.
2021-12-19 16:10:43 <MY-R> oh
2021-12-19 16:10:44 <nmeum> see https://github.com/eudev-project/eudev#readme
2021-12-19 16:10:44 <Ariadne> one that is not gentoo
2021-12-19 16:11:08 <MY-R> thanks, is really hard to follow all changes
2021-12-19 16:11:22 <psykose> Ariadne: and then, doesn't that mean mdevd needs to read them from somewhere? last i checked mdevd docs it reads 'only' /etc/mdev.conf, unless i misread
2021-12-19 16:11:39 <Ariadne> yes, configuration directory support would need to be added
2021-12-19 16:11:42 <Hello71> it can be patched, the main work is writing the translator
2021-12-19 16:11:45 <psykose> okay, good to know, thanks
2021-12-19 16:13:19 <psykose> i guess that is some fun 'work' for skarnet
2021-12-19 16:16:22 <Ariadne> thank u pfizer
2021-12-19 16:19:07 <skarnet> re mdevd, the whole *point* was to be a drop-in replacement for mdev
2021-12-19 16:19:43 <skarnet> if what you want is a full-featured device manager, I can do that, but then I wouldn't have started with the terrible mdev.conf syntax in the first place
2021-12-19 16:19:49 <dalias> :)
2021-12-19 16:21:03 <skarnet> user script support is achievable via hooks à la mdev-like-a-boss
2021-12-19 16:23:48 <psykose> i can't seem to figure out which part of that adds hooks
2021-12-19 16:24:23 <skarnet> the whole concept is to divert management to scripts
2021-12-19 16:24:41 <skarnet> you want dynamically pluggable management? add a script for .*
2021-12-19 16:25:42 <psykose> ah, i see now
2021-12-19 16:25:46 <skarnet> then you can do everything you want, and it's Turing-complete - cue starry-eyed executives hearing a buzzword they like
2021-12-19 16:27:10 <skarnet> you can even write your scripts in Node.js or whatever your preferred hype language of the year is, for more suckage
2021-12-19 16:29:56 <psykose> ack, nodejs-mdev will be released in alpine 3.16
2021-12-19 16:32:38 <Ariadne> nodejs-apk
2021-12-19 16:32:41 <dalias> ehhh...
2021-12-19 16:32:42 <Ariadne> nodejs-busybox
2021-12-19 16:32:48 <Ariadne> nono
2021-12-19 16:32:50 <Ariadne> busybox.js
2021-12-19 16:33:13 <dalias> lol now configure takes 36 hours
2021-12-19 16:33:29 <psykose> speaking of, what should be done about !28610 !28622
2021-12-19 16:33:30 <dalias> (10 seconds startup for each shell command)
2021-12-19 16:33:43 <Ariadne> i said nodejs, not ethereum
2021-12-19 16:33:45 <Ariadne> geeze
2021-12-19 16:34:06 <dalias> ethereum would be like "8 hours startup and $2000 for each shell command"
2021-12-19 16:34:14 <minimal> omni, psykose: as expected, nomad 1.2.3 does have the same problem
2021-12-19 16:34:42 <psykose> anything with ember in the repos has the problem
2021-12-19 17:05:32 <xrs> hi everybody! I have to new MRs for gnunet, gnunet-gtk, and gnurl.
2021-12-19 17:05:47 <xrs> https://gitlab.alpinelinux.org/xrs/aports/-/merge_requests/3
2021-12-19 17:06:09 <xrs> https://gitlab.alpinelinux.org/xrs/aports/-/merge_requests/4
2021-12-19 17:06:11 <xrs> https://gitlab.alpinelinux.org/xrs/aports/-/merge_requests/5
2021-12-19 17:06:31 <psykose> you are merging these into the wrong branch
2021-12-19 17:06:48 <psykose> it has to go to aports/master, not your-fork/master
2021-12-19 17:07:10 <xrs> yes, it schould be master.
2021-12-19 17:08:45 <xrs> I tried to change it to aports/master but I can't. Any hint is appreciated. :)
2021-12-19 17:09:13 <psykose> you have to close it and remake it
2021-12-19 17:09:19 <psykose> go to aports/master and start the mr from there
2021-12-19 17:09:46 <xrs> ahh, that's the trick.
2021-12-19 17:09:54 <xrs> OK, I'll try.
2021-12-19 17:10:10 <psykose> then you select the source branch and make sure the target is alpine/aports master
2021-12-19 17:10:18 <psykose> should be all you need, then i'll review it
2021-12-19 17:10:32 <xrs> ok!
2021-12-19 18:16:32 <xrs> psykose: I rebased my master and the braches. It should be okay now. Should I renew the MRs based on the new state?
2021-12-19 18:16:57 <psykose> your mr still shows 2000 commits
2021-12-19 18:16:59 <psykose> it should show 1
2021-12-19 18:17:03 <psykose> you have to fix the divergence
2021-12-19 18:17:13 <xrs> ok
2021-12-19 18:17:24 <xrs> then I close the current MRs.
2021-12-19 18:17:29 <psykose> it is caused by what i posted, i can't really tell you how you should fix it
2021-12-19 18:17:36 <psykose> you also don't have to close the mr, just fix the branch
2021-12-19 18:17:54 <xrs> Mh.
2021-12-19 18:18:47 <psykose> the way i would do it is to take your master, reset --hard upstream/master with upstream being alpine/aports, and then reset your mr branches on that and place your changes on top of that
2021-12-19 18:19:12 <psykose> but this isn't very clear and if you don't know how to do this with git you might break your repo even more, and lose your changes in the meantime if you don't save them
2021-12-19 18:19:22 <xrs> Yes, I did something like that in the last hour. Let me check again
2021-12-19 19:27:40 <vkrishn> hi, what would be simple way to mount remote disk using pkgs from /main only ? nfs ?
2021-12-19 19:28:40 <vkrishn> I have a disk in alpine(install A), of which disk data I would like to share in alpine(install B)
2021-12-19 19:29:34 <vkrishn> the mount could remain persistent for days
2021-12-19 19:34:05 <Hello71> 16:24 <skarnet> the whole concept is to divert management to scripts
2021-12-19 19:34:07 <Hello71> 16:24 <skarnet> you want dynamically pluggable management? add a script for .*
2021-12-19 19:34:22 <Hello71> doesn't it defeat the purpose of mdevd if you run a helper on every event?
2021-12-19 19:36:27 <xrs> psykose: Next try.. my master and branches should be fixed now. ^^
2021-12-19 19:37:43 <xrs> I get some pipeline errors. This is due to the seperation of the MRs, which actually depend from each other, right?
2021-12-19 19:38:44 <skarnet> Hello71: yes, it does. It also defeats the purpose of mdevd to have pluggable helpers in the first place.
2021-12-19 19:39:25 <psykose> xrs: if they depend on each other put them in the same mr
2021-12-19 19:39:45 <skarnet> again, I'm all for a device manager reading its config from something more modular than a file - a directory with a lot of files, for instance. That's not what mdev is, so, as a drop-in replacement, that's not what mdevd is either.
2021-12-19 19:40:18 <xrs> psykose: but they are different packages. Please confirm.
2021-12-19 19:40:26 <psykose> confirmed
2021-12-19 19:41:07 <skarnet> The preprocessing approach (build foobar.conf from all the files in foobar.conf.d/) isn't encouraged in Alpine for some reason, despite the fact that it would work really well here; I don't know why.
2021-12-19 21:41:34 <adhawkins> Anyone here familiar with dabuild able to try something for me?
2021-12-19 21:41:46 <adhawkins> This MR fails to build with dabuild, but does on CI and if I run the CI containers locally
2021-12-19 21:41:47 <adhawkins> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28655
2021-12-19 21:42:27 <adhawkins> The tests fail to find a module, but it is being installed
2021-12-19 21:50:50 <adhawkins> This is the relevant part of the build output: https://paste.debian.net/1224095/
2021-12-19 22:07:46 <donoban> adhawkins: is your dabuild image based on edge?
2021-12-19 22:47:38 <adhawkins> Good question, one sec donoban
2021-12-19 22:50:38 <adhawkins> It seems to be this one: https://hub.docker.com/r/alpinelinux/docker-abuild
2021-12-19 22:53:22 <adhawkins> The script that runs it does seem to be using the 'edge' version
2021-12-19 23:02:19 <adhawkins> This is the command line the script ends up running: https://paste.debian.net/1224101/
2021-12-19 23:44:01 <ddevault> I don't think the builder picked this up https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28620
2021-12-19 23:47:07 <Hello71> it seems to be working fine? https://pkgs.alpinelinux.org/packages?name=bearssl&branch=edge
2021-12-19 23:47:18 <Hello71> (mips64 is dead)
2021-12-19 23:47:45 <psykose> it installs fine for me, -r2, with the correct change
2021-12-19 23:48:12 <psykose> what strikes me is that libbearssl.so is placed in /lib, but maybe that is intended
2021-12-20 01:48:37 <Hello71> can someone review !27930? wine is completely broken on 3.15 and edge
2021-12-20 01:57:31 <dalias> how does wine work nowadays anyway?
2021-12-20 01:57:39 <dalias> can you like run games and apps and stuff out of the box?
2021-12-20 02:13:15 <psykose> with proton that works pretty well sure, can't say i use vanilla wine much though
2021-12-20 02:15:54 <bl4ckb0ne> you can't do much without lib32 though
2021-12-20 02:16:10 <psykose> and all the wine stuff is basically a mess of patchsets, to my knowledge wine-staging is some releases ahead + patches that only stay in staging, proton is in between the releases + some of the staging patches + some proton-only patches + some extra software
2021-12-20 02:16:38 <psykose> yeah, the alpine packaging doesn't let you do too much with it, tons of stuff needs lib32 for windows
2021-12-20 02:16:55 <psykose> not much can be done about that, just not a multilib system
2021-12-20 05:36:56 <skarnet> psykose: yeah it was intended, because it's pretty low level, but since nothing in / depends on it, it's not really important and can be changed to /usr/lib if required
2021-12-20 05:37:08 <psykose> was just curious :)
2021-12-20 05:38:13 <skarnet> tbh the fact that .so's and .a's are in the same places is one of the FHS things that irk me
2021-12-20 05:38:21 <skarnet> those are not the same objects at all
2021-12-20 05:39:00 <psykose> ncopa: could you merge !28617 !28652
2021-12-20 05:39:04 <psykose> skarnet: aye, it irks me too
2021-12-20 09:12:02 <DylanVanAssche> Alpine v3.15 has synapse 1.47.0, however there's a necessary security update to 1.47.1
2021-12-20 09:12:02 <DylanVanAssche> Would an upgrade to 1.47.1 be desired or immediately to 1.49.0?
2021-12-20 09:12:02 <DylanVanAssche> https://matrix.org/blog/2021/11/18/pre-disclosure-upcoming-security-release-of-synapse-1-47-1
2021-12-20 09:12:48 <mps> DylanVanAssche: imo, to 1.47.1
2021-12-20 09:16:24 <DylanVanAssche> mps: Oh never mind, I was mistaken.
2021-12-20 09:16:24 <DylanVanAssche> But good to know for the future, thanks
2021-12-20 09:16:24 <DylanVanAssche> 1.47.1 is already in 3.15, I must have been on an older branch.
2021-12-20 09:49:05 <ddevault> should /etc/os-release report something other than 3.15 on edge?
2021-12-20 09:53:44 <mps> no
2021-12-20 09:54:12 <ddevault> why not?
2021-12-20 09:54:33 <mps> when the first tagged 3.16 released then it will
2021-12-20 09:54:50 <ddevault> it is not 3.15, though
2021-12-20 09:54:58 <mps> it is
2021-12-20 09:54:59 <ddevault> I could see it reporting 3.16 as it's essentially a WIP version of that
2021-12-20 09:55:01 <ddevault> or edge
2021-12-20 09:55:04 <ddevault> but it's definitely not 3.15
2021-12-20 09:55:39 <mps> did you upgrades alpine-base
2021-12-20 09:55:47 <ddevault> yes?
2021-12-20 09:56:43 <mps> apk info -W /etc/os-release => /etc/os-release is owned by alpine-base-3.15.0-r0
2021-12-20 09:56:59 <ddevault> yes, I understand
2021-12-20 09:57:02 <ddevault> what of it?
2021-12-20 09:58:00 <mps> os-release on my edge boxes shows 3.15
2021-12-20 09:58:08 <ddevault> aye, but it shouldn't
2021-12-20 09:58:11 <ddevault> edge != 3.15
2021-12-20 09:58:16 <mps> ah
2021-12-20 09:58:56 <mps> yes, it will be 3.15 till first tagged 3.16 release
2021-12-20 09:59:07 <ddevault> right. I'm suggesting that this is incorrect
2021-12-20 09:59:47 <mps> well, I'm not sure, maybe it will be 'edge' always
2021-12-20 10:00:02 <mps> s/will/should/
2021-12-20 10:00:02 <alpine-meetbot> mps meant to say: well, I'm not sure, maybe it should be 'edge' always
2021-12-20 10:00:03 <ddevault> a better solution would be to set it to 3.16 early, as soon as 3.15 is branched off, or to set it to "edge"
2021-12-20 10:00:30 <mps> '3.15+'
2021-12-20 10:43:42 <adhawkins> Anyone able to assist with my dabuild question from yesterday?
2021-12-20 10:43:59 <adhawkins> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28655
2021-12-20 10:44:15 <adhawkins> That MR builds fine on the CI containers both locally and at Alpine, but fails to build with dabuild.
2021-12-20 10:46:17 <adhawkins> The previous version of emborg builds just fine. There are very few changes between the two versions.
2021-12-20 10:46:26 <adhawkins> This is the error I get when I build locally with dabuild: https://paste.debian.net/1224095/
2021-12-20 11:03:28 <ikke> adhawkins: I have no experience with dabuild, but are you able to enter into the container?
2021-12-20 11:04:00 <adhawkins> ikke: It's transient as far as I'm aware.
2021-12-20 11:07:32 <ikke> It just sets up docker run with alpinelinux/docker-abuild as image
2021-12-20 11:07:46 <ikke> If you override the entrypoint, you should be able to get a shell
2021-12-20 11:08:28 <adhawkins> Ok. And what would I do with the shell?
2021-12-20 11:10:10 <ikke> verify shlib
2021-12-20 11:10:42 <ikke> see if you can reproduce it
2021-12-20 11:14:29 <adhawkins> Ok, will see if I can do that. What's odd is that it builds fine in CI...
2021-12-20 11:21:47 <donoban> ikke: maybe it is not the source of the problem but last dabuild image is pretty old (maybe something fails in the upgrade process)
2021-12-20 11:22:11 <donoban> won't be better to push a new tag?
2021-12-20 11:22:34 <donoban> it's upgrading from 3.10 or 3.11 to edge
2021-12-20 11:22:38 <adhawkins> I've just cleared out all the 'local' built packages, and the build has gone through.
2021-12-20 11:23:02 <donoban> oh great
2021-12-20 11:23:05 <adhawkins> dabuild seems to keep local copies of all the packages it builds.
2021-12-20 11:23:22 <adhawkins> Not sure why that would have caused an issue just for this version of emborg!
2021-12-20 11:24:38 <donoban> did you have some py3-packages on your local repo?
2021-12-20 11:26:00 <adhawkins> Yes. Including shlib (I'm the maintainer of it)
2021-12-20 13:40:23 <markand> I just discovered that eudev was abandoned by gentoo and now maintained by ourselves and some other folks
2021-12-20 13:43:27 <markand> 
ACTION feels like we will be on a isolated island at some point with few barrels floating all around named dcron, sysklogd, eudev, ntpd, ...

2021-12-20 13:47:28 <minimal> markand: there are other options for at least some of those in Alpine: rsyslog or syslog-ng, chrony, etc
2021-12-20 14:03:47 <skarnet> and they're all bad! :D
2021-12-20 14:04:22 <psykose> ur bad
2021-12-20 14:04:56 <skarnet> I am, but at least my logs are autorotated, unlike rsyslog's :P
2021-12-20 14:06:26 <psykose> i like how gnu.org has been down for like 10 hours
2021-12-20 14:06:43 <MY-R> no logs, no problem! :D
2021-12-20 14:06:54 <markand> exactly
2021-12-20 14:10:05 <mps> I'm using metalog
2021-12-20 14:10:43 <mps> markand: also, we have libudev-zero as alternative to eudev
2021-12-20 14:12:41 <orbea> 
ACTION likes metalog too

2021-12-20 14:15:24 <fcolista> I didn't know metalog...looks cool
2021-12-20 14:16:10 <markand> 
ACTION googled it and stambled accross a french storage factory

2021-12-20 14:16:29 <orbea> https://github.com/hvisage/metalog
2021-12-20 14:16:42 <mps> apk add metalog :)
2021-12-20 14:16:48 <markand> thanks orbea 
2021-12-20 14:17:22 <markand> for the moment I've always used the busybox's syslogd with no problem for my simple use but I'll get a proper look at metalog 
2021-12-20 14:18:21 <psykose> markand: could you look at !28601
2021-12-20 14:19:27 <markand> do calf really needs rebuild psykose? (the pkgrel++)
2021-12-20 14:20:31 <psykose> https://img.ayaya.dev/zpjpuZSBuuKn
2021-12-20 14:20:44 <markand> okay
2021-12-20 14:20:57 <markand> then that's fine I guess
2021-12-20 14:21:16 <markand> I'm no longer in audio creation on Linux so you may also take calf if you want
2021-12-20 14:22:21 <psykose> i don't mind either way, just ikke tagged it as 'maintainer feedback' so :p
2021-12-20 14:24:33 <Hello71> dalias: ignoring the current bug, then i think games and apps and stuff should mostly work, with the notable exception of wow64 (windows multilib), very common for installers. fortunately such installers are relatively few nowadays
2021-12-20 14:25:54 <Hello71> oh, there were already responses along those lines
2021-12-20 14:39:53 <omni> ncopa: !28535
2021-12-20 14:45:48 <dalias> hello71, in theory does it work if you install 32-bit packages in another location in path?
2021-12-20 14:51:16 <psykose> you need to build wine against multilib pretty sure
2021-12-20 14:51:43 <psykose> otherwise you only get the wine64 target
2021-12-20 14:55:37 <Hello71> afaik it should work as well as any other 32-bit program, i.e. the programs need to be compiled for multilib paths, otherwise you need chroot
2021-12-20 17:42:50 <craftyguy> ikke: thanks for the help with rebuilding khal/vdirsyncer. I would have responded sooner but was asleep :P
2021-12-20 17:42:58 <caskd> oh nice
2021-12-20 17:43:12 <caskd> i was quite annoyed i couldn't use my calendar for a bit
2021-12-20 17:43:16 <caskd> but you were faster
2021-12-20 17:46:27 <craftyguy> yeah I'm not excited that my calendaring system depends on many python modules
2021-12-20 17:46:45 <caskd> it's the best we have at the moment :/
2021-12-20 18:08:39 <ikke> caskd: no worry
2021-12-20 18:08:44 <ikke> craftyguy: *
2021-12-20 22:22:26 <lzsaver> !28560
2021-12-20 22:41:27 <Ariadne> holy crap this python3.10 migration is fucked
2021-12-20 22:43:07 <Ariadne> like, literally costing me money fucked
2021-12-20 22:51:46 <Ariadne> weasyprint needs a rebuild,  but the py3-cairocffi package is busted
2021-12-20 22:52:04 <Ariadne> i rebuilt it with rootbld, and it is not busted
2021-12-20 22:55:05 <craftyguy> there's something like 11 months left until 3.11 drops. (IIRC python is on an annual release cadence now?)
2021-12-20 22:55:15 <craftyguy> what can be done to make it go smoother next time?
2021-12-20 22:56:24 <craftyguy> like maybe identifying all packages that need to be rebuilt and pushing some branch that rebuilds them all at once to master? (seems like some packages were missed in the initial push either because they were unknown, or broken, or ???, which is why I mention that)
2021-12-20 23:00:50 <Ariadne> well, part of the problem is that python3-using apps (like weasyprint) did not get rebuilt
2021-12-20 23:01:06 <Ariadne> my bookkeeping system uses weasyprint to generate and email invoices to my customers
2021-12-20 23:01:14 <Ariadne> instead of doing this, it has been just crashing instead
2021-12-20 23:01:40 <Ariadne> but i'm honestly not sure why py3-cairocffi is broken
2021-12-20 23:01:48 <Ariadne> i think the build environment on build-edge-aarch64 is dirty
2021-12-20 23:02:23 <Ariadne> it is kind of my fault for using alpine edge on things i need to work though
2021-12-20 23:11:27 <tbodt> connect
2021-12-20 23:11:35 <tbodt> whoops thought i was talking to znc
2021-12-20 23:19:13 <tbodt> filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/13340 a bit ago. does this make sense
2021-12-20 23:20:30 <tbodt> etc/os-release doesn't change when upgrading a minirootfs so thinking it should be moved to alpine-baselayout from alpine-base
2021-12-20 23:20:45 <Ariadne> yes
2021-12-20 23:20:48 <Ariadne> it makes sense
2021-12-20 23:21:12 <tbodt> ok i might do a pr
2021-12-20 23:31:31 <craftyguy> Ariadne: yeah from my perspective, it seems like python 3.10 was pushed before a lot of apps APKBUILDs were changed to force a rebuild
2021-12-20 23:32:02 <craftyguy> it seems like python upgrade should be pushed at the beginning of a branch that includes all apps that need to be rebuilt with it
2021-12-21 00:00:52 <tbodt> where do i find the script that builds the minirootfs images?
2021-12-21 00:00:59 <tbodt> *tarballs
2021-12-21 00:01:55 <tbodt> aha, aports/scripts
2021-12-21 00:02:46 <artok> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts
2021-12-21 00:02:53 <artok> yah
2021-12-21 00:03:47 <Hello71> afaik there are two problems: 1. packages in testing are not done yet; 2. there is no standard way to find out which packages need to be rebuilt with a major upgrade. ad hoc methods are used every time, which inevitably leads to some packages being missed. this was seen very recently in the boost 1.77 upgrade
2021-12-21 00:16:09 <Ariadne> yeah i think we need to spend some time to solve that
2021-12-21 00:27:32 <tomalok> just me, or is https://gitlab.alpinelinux.org currently not happy?
2021-12-21 00:27:45 <Ariadne> it frequently is unhappy
2021-12-21 00:28:33 <tomalok> i'll try not to take it personally, then... ;)
2021-12-21 00:35:11 <ktprograms> ikke: Thanks for merging the Gitea fix.
2021-12-21 01:01:27 <ktprograms> Hi, I'd like to add Qtile to aports, but it depends on having py3-cairocffi being build against py3-xcffib (which I'll also package), but the problem is that py3-cairocffi is in community, so I can't make it depend on py3-xcffib which will be in testing. Should I make a py3-cairocffi package in testing (with a different name) that is built against py3-xcffib?
2021-12-21 01:11:22 <Ariadne> i fixed it already
2021-12-21 01:16:12 <ktprograms> Ariadne: This is a different thing (see https://gitlab.alpinelinux.org/ktprograms/custom-aports/-/blob/master/py3-cairocffi/APKBUILD), it needs to depend on *xcffib* in order for Qtile to work.
2021-12-21 01:16:50 <Ariadne> no just make the py3-cairocffi depend on xcffib
2021-12-21 01:21:07 <ktprograms> Ariadne: I thought we aren't allowed to make packages in community depend on packages in testing? (py3-xcffib will be in testing when I add it)
2021-12-21 01:21:27 <Ariadne> yes
2021-12-21 01:21:32 <Ariadne> move xcffib
2021-12-21 01:21:35 <Ariadne> to community
2021-12-21 01:22:16 <ktprograms> Ariadne: Immediately? (It isn't even in aports yet)
2021-12-21 01:27:43 <minimal> Ariadne: weasyprint 53.x no longer requires cairo
2021-12-21 01:46:26 <Ariadne> ktprograms: sure
2021-12-21 01:48:08 <ktprograms> Ariadne: Ok, thanks. But I'll have to clean up my APKBUILD first.
2021-12-21 01:49:21 <Ariadne> minimal: what does it replace it with?
2021-12-21 01:51:52 <minimal> Ariadne: pydyf, seems to be their own replacement
2021-12-21 01:52:05 <Ariadne> weird
2021-12-21 01:52:08 <Ariadne> and worrying
2021-12-21 01:52:12 <minimal> https://www.courtbouillon.org/blog/00008-weasyprint-53-beta
2021-12-21 01:52:42 <minimal> v53.0 was released with this change in July.
2021-12-21 01:54:25 <Ariadne> yeah but does it have good output lol
2021-12-21 01:58:06 <minimal> Ariadne: dunno but "its the way of the future", at least for weasyprint, lol
2021-12-21 04:57:07 <anjan> I want to use a patch from an aur package. Can I just copy paste it?
2021-12-21 04:57:10 <anjan> https://aur.archlinux.org/cgit/aur.git/tree/use_external_ecos.patch?h=python-ecos
2021-12-21 04:57:15 <anjan> any licensing issues?
2021-12-21 05:32:34 <ikke> I would say that the patch would have the same license as the code it patches (IANAL)
2021-12-21 05:44:41 <anjan> ikke: we can include it in alpine official repos right
2021-12-21 06:00:33 <anjan> ugh, I give up, Im using virtualenvs
2021-12-21 06:00:36 <anjan> I hate python
2021-12-21 09:05:41 <skarnet> Boom, new releases, and fully functional and Alpine Policy Approved (tm) utmps setup script. !28716
2021-12-21 09:06:00 <skarnet> (cue the MR pipeline crashing and burning)
2021-12-21 09:08:08 <ktprograms> FYI skarnet, in your page for execline, in the second paragraph, in the phrase 'Meanwhile, its syntax is far more logic and ...', it should probably be 'logical'?
2021-12-21 09:09:42 <skarnet> yeah, it probably should, but you're looking at my English skills from 20 years ago basically :D
2021-12-21 09:10:05 <skarnet> will fix, thanks. Why do bug-reports always happen *right after* a release? XD
2021-12-21 09:10:33 <ktprograms> skarnet: Because a release draws attention to the software?
2021-12-21 09:10:51 <skarnet> of course there's a logical explanation, but it's still horribly frustrating. :P
2021-12-21 09:11:07 <ktprograms> true...
2021-12-21 15:47:13 <ahills> ncopa: re: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13254 (busybox-initscripts persistent-storage vs. /dev/usbdisk), would you consider a patch to /sbin/setup-bootable that attempts replacing references to /dev/usbdisk with UUID=… in /etc/fstab?
2021-12-21 15:47:57 <ahills> IMO while /dev/usbdisk picking the first sdXY that comes from usb works well for my use case, it's not hard to imagine configurations where it is more fragile
2021-12-21 15:48:18 <ahills> (the logic isn't necessarily choosing the one alpine booted from as far as I can tell)
2021-12-21 15:49:35 <ahills> side note, upgrading from 3.11 straight to 3.15 worked perfectly except for this one detail, really appreciate how easy it is to use alpine :)
2021-12-21 16:21:35 <mps> interesting is that some MR authors click 'Aprove' button ;)
2021-12-21 16:27:52 <psykose> maybe pressing approve on my own mrs would actually make some of them merged :p
2021-12-21 16:28:24 <mps> I doubt ;p
2021-12-21 16:28:54 <mps> actually will do opposite
2021-12-21 16:31:09 <Ariadne> dang it where is aparcar :P
2021-12-21 16:31:19 <psykose> hopefully doing something fun
2021-12-21 16:31:39 <Ariadne> well, the issue with cross-compilation seems to be a GCC 11 bug
2021-12-21 16:31:42 <Ariadne> https://github.com/gambit/gambit/issues/724
2021-12-21 16:31:51 <Ariadne> cause this happened to an alpine user running native
2021-12-21 16:31:56 <Ariadne> same issue
2021-12-21 16:32:35 <psykose> hah
2021-12-21 16:32:45 <psykose> i guess it's not present on the 3.15 gcc10 toolchain then
2021-12-21 16:44:13 <psykose> Ariadne: i get the same error on 3.15 with gcc10 in a docker container
2021-12-21 16:44:47 <psykose> running the same configure as that gambit report, though i don't think that matters
2021-12-21 18:09:34 <Ariadne> psykose: yeah i figured it out
2021-12-21 18:09:47 <Ariadne> psykose: gambit has a _GNU_SOURCE define hiding out in one of its headers
2021-12-21 18:09:54 <ikke> :)
2021-12-21 18:09:57 <psykose> :)
2021-12-21 18:11:13 <ikke> https://ariadne.space/2021/12/21/stop-defining-feature-test-macros-in-your-code/
2021-12-21 18:11:31 <Ariadne> yes i wrote a blog to link to upstreams which do this :P
2021-12-21 18:11:50 <Ariadne> if you want _GNU_SOURCE, put it on CFLAGS
2021-12-21 18:11:57 <Ariadne> that's how this is supposed to be done
2021-12-21 18:13:51 <psykose> is it? i would assume there isn't much wrong with it if you are indeed using something formally defined under _GNU_SOURCE only in the code, as in documented under the feature-test-macros
2021-12-21 18:14:30 <psykose> cflags accomplishes the same, but i can't blame application developers for seeing a _GNU_SOURCE: xyzfunction() in manpages and putting it in the code to use it
2021-12-21 18:14:32 <Ariadne> the problem is when you do not consistently use the macros
2021-12-21 18:14:52 <Ariadne> yes, as i wrote, the documentation does not really explain the need for the macros to be used consistently
2021-12-21 18:14:52 <psykose> yes, that would be an issue
2021-12-21 18:15:13 <Ariadne> in this case, fortify broke because of how #include_next works
2021-12-21 18:15:42 <Ariadne> the fortify header got included with a different view of the world than the initial musl headers
2021-12-21 18:15:56 <Ariadne> due to that #define _GNU_SOURCE being misused
2021-12-21 18:16:08 <Ariadne> it really does need to be on CFLAGS, and the manpage *does* say that
2021-12-21 18:16:24 <Ariadne> https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
2021-12-21 18:16:28 <Ariadne> in fact, it explicitly says
2021-12-21 18:16:32 <Ariadne> do not #define _GNU_SOURCE
2021-12-21 18:16:46 <Ariadne> unfortunately, this is the first and only "code example" they have in that manpage
2021-12-21 18:16:52 <Ariadne> so i am sure many people are just skipping to it
2021-12-21 18:17:00 <Ariadne> and concluding "ok i will #define _GNU_SOURCE"
2021-12-21 18:17:04 <Ariadne> even though it's a "do not do this"
2021-12-21 18:18:12 <Ariadne> either way, if the project wants _GNU_SOURCE, it should just put it in CFLAGS
2021-12-21 18:19:53 <psykose> i totally didn't even know that, lmao
2021-12-21 18:19:57 <psykose> what a manpage
2021-12-21 18:20:51 <Ariadne> yes, the manpage is so wishywashy
2021-12-21 18:21:50 <psykose> thanks, i'll stop thinking to define them myself too
2021-12-21 18:28:03 <Ariadne> psykose: in reality, all most people need is `-std=gnu11`
2021-12-21 18:28:29 <Ariadne> if you use that, then you always get all the feature macros enabled
2021-12-21 18:29:15 <psykose> ah, that does make more sense
2021-12-21 18:31:53 <psykose> since, we're on the topic of fortify, do you know what might cause https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28666#note_199953 ? ignore the lto comment as it didn't apply
2021-12-21 18:36:50 <Ariadne> the exact same issue
2021-12-21 18:37:16 <psykose> it doesn't define gnu source in headers anywhere though, as far as i can see
2021-12-21 18:37:18 <psykose> or any of the source
2021-12-21 18:38:13 <Ariadne> oh
2021-12-21 18:38:18 <Ariadne> i should look more closely
2021-12-21 18:38:23 <Ariadne> this is just C++ being stupid
2021-12-21 18:38:26 <Ariadne> disable FORTIFY
2021-12-21 18:38:47 <Ariadne> expecting it to get along with STL is probably not a reasonable expectation, as STL is not reasonable
2021-12-21 18:38:59 <psykose> yeah, did for now with -U_FORTIFY_SOURCE :) was just wondering, since i have no idea what is happening
2021-12-21 18:40:30 <psykose> in that case that can be merged as well
2021-12-21 18:43:25 <skarnet> it's only the latest installment - not the first, not the last - of stuff that breaks because of fortify
2021-12-21 18:43:45 <skarnet> fortify as in "what doesn't break you makes you stronger", I guess
2021-12-21 18:43:58 <skarnet> and a lot of things break
2021-12-21 18:47:23 <psykose> yes, i think i've seen quite the number of broken things like this that reference fortify
2021-12-21 18:47:43 <psykose> it's always some insane incantation of things to find out what exactly is wrong as well, so i can never find the issues
2021-12-21 18:50:25 <dalias> #define _GNU_SOURCE (or any FTM) is fine as long as you do it at the top of the .c and not buried in some .h
2021-12-21 18:52:32 <Ariadne> dalias: sure, but its better to just tell them to use CFLAGS for this
2021-12-21 18:53:03 <Ariadne> because what might be top of line today
2021-12-21 18:53:03 <Ariadne> might get moved by somebody tomorrow
2021-12-21 18:53:03 <dalias> well as skarnet noted it depends on whether this is uniform across your whole project or specific to a source file
2021-12-21 18:53:31 <dalias> like if your project as a whole is written to standards but one file wants some _GNU_SOURCE stuff
2021-12-21 18:53:42 <dalias> you don't want -D_GNU_SOURCE in CFLAGS or it will break your strerror_r etc
2021-12-21 18:54:16 <Ariadne> yes, that's the exception imo
2021-12-21 18:54:43 <Ariadne> but most people
2021-12-21 18:54:56 <Ariadne> they should just use -std=c99
2021-12-21 18:55:52 <Ariadne> er
2021-12-21 18:55:52 <Ariadne> -std=c11
2021-12-21 18:55:52 <Ariadne> or -std=gnu11
2021-12-21 18:56:38 <skarnet> glad to be the exception once more
2021-12-21 18:56:53 <jvoisin> writing gnu-C sounds like a baa idea™
2021-12-21 18:56:55 <jvoisin> *bad
2021-12-21 18:57:42 <psykose> baa
2021-12-21 18:57:51 <psykose> 🐑
2021-12-21 18:58:09 <Ariadne> skarnet: i'm going to go try to compile s6 on BSD 4.3-Tahoe
2021-12-21 19:02:20 <skarnet> be my guest! if it doesn't work, please submit a bug-report. :P
2021-12-21 19:03:10 <Ariadne> it wont even compile ISO C
2021-12-21 19:03:20 <Ariadne> you'll have to use K&R function declarations
2021-12-21 19:03:33 <Ariadne> int foo(bar, baz)
2021-12-21 19:03:38 <Ariadne>    int bar;
2021-12-21 19:03:40 <Ariadne>    char *baz;
2021-12-21 19:03:41 <Ariadne> {...}
2021-12-21 19:04:44 <skarnet> well, not posix then! unsupported. :P
2021-12-21 19:06:17 <Ariadne> i did recently acquire a VAX
2021-12-21 19:07:49 <skarnet> because you figured you had too much time
2021-12-21 19:08:21 <minimal> Ariadne: running VMS? Old memories flowing back...
2021-12-21 19:08:34 <Ariadne> running nothing at the moment
2021-12-21 19:09:00 <Ariadne> skarnet: well, i was acquiring some cisco switches from a networking vendor
2021-12-21 19:09:09 <Ariadne> and they had it
2021-12-21 19:09:11 <Ariadne> and so i bought it
2021-12-21 19:09:41 <q66> fun fact: gnu readline is written to have its headers k&r compatible and it's fucking terrible
2021-12-21 19:10:29 <q66> it's also why it's half broken in c++ by default
2021-12-21 19:10:46 <q66> rl_message is a vararg function that is declared with empty parameter libs because stdarg wasn't a thing in k&r
2021-12-21 19:10:51 <Ariadne> everything about bash and friends are terrible
2021-12-21 19:11:04 <q66> and obviously c++ considers it a function with no parameters
2021-12-21 19:11:05 <Ariadne> why do you think i spent so much time making busybox ash comfortable to use
2021-12-21 19:11:23 <q66> er, *parameter list
2021-12-21 19:11:42 <skarnet> Ariadne: because for some reason everyone forgets about zsh
2021-12-21 19:11:54 <q66> and *ksh
2021-12-21 19:12:04 <Ariadne> skarnet: i don't like zsh or ksh :D
2021-12-21 19:12:13 <q66> i don't like busybox
2021-12-21 19:12:18 <skarnet> I don't like shells
2021-12-21 19:12:30 <skarnet> let's all hate everything together
2021-12-21 19:13:18 <q66> i don't like shells either
2021-12-21 19:14:10 <q66> neither the andrew lee ones nor the *nix ones
2021-12-21 19:14:40 <jvoisin> iirc, openbsd is still running on VAX
2021-12-21 19:15:20 <bl4ckb0ne> is it normal that regular users can't approve a merge request?
2021-12-21 19:16:19 <skarnet> yes
2021-12-21 19:16:37 <skarnet> (I think so)
2021-12-21 19:16:54 <mps> Approve button should be disabled
2021-12-21 19:17:33 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28663#note_200280 related to my question
2021-12-21 19:25:20 <psykose> assigned maintainers should have the privilege
2021-12-21 19:25:25 <psykose> they normally do, could you take a picture
2021-12-21 19:26:39 <psykose> hm, why is spirv-tools so old
2021-12-21 19:27:45 <psykose> ah, leo dropped maintenance
2021-12-21 19:28:15 <bl4ckb0ne> you want a screenshot of what?
2021-12-21 19:29:09 <psykose> the button/element of approvers
2021-12-21 19:29:40 <bl4ckb0ne> there's just a "approval is optional"
2021-12-21 19:30:09 <bl4ckb0ne> https://l.sr.ht/nH8r.png
2021-12-21 19:30:21 <psykose> hmm
2021-12-21 19:30:36 <psykose> you should definitely normally be able to
2021-12-21 19:31:51 <psykose> and if the email was different or something then gitlab wouldn't assign you as well, so i don't know what is wrong
2021-12-21 19:33:14 <bl4ckb0ne> 
ACTION shrugs

2021-12-21 19:57:56 <omni> !28535
2021-12-21 19:58:11 <omni> xen-qemu has been broken since it was introduced a few days ago
2021-12-21 20:38:17 <skarnet> bl4ckb0ne: I will definitely reuse that image out of context
2021-12-21 20:39:21 <bl4ckb0ne> dont forget to credit me
2021-12-21 20:42:22 <psykose> approval is optional :p
2021-12-21 20:57:04 <anjan> > top convex optimization package. Made by oxford university.
2021-12-21 20:57:11 <anjan> > packaging it is horrible
2021-12-21 20:57:26 <anjan> > installing from pip takes overnight and still doesnt finish cause it's compiling everything
2021-12-21 20:57:32 <anjan> python was a mistake
2021-12-21 21:16:50 <skarnet> python, pip, and academic code, what could possibly go wrong
2021-12-21 21:25:43 <mps> skarnet: :)
2021-12-21 21:26:46 <bl4ckb0ne> in academic code, approval is optional
2021-12-21 21:28:05 <anjan> ya, I am using this code for my thesis
2021-12-21 21:28:14 <anjan> it's a good solver but it's awful for packaging
2021-12-21 21:28:36 <anjan> Ill submit a PR for aports cause I couldnt get it to install on alpine via pip and I got it to build via abuild
2021-12-21 21:28:46 <anjan> (In less than 5 min)
2021-12-21 21:30:58 <mps> I'm waiting crypto miners to create MRs ;)
2021-12-21 21:32:11 <Saijin_Naib[m]> At least if you have it packaged it has some small chance of being reproducible for other people using it, so thanks for that!
2021-12-21 21:32:31 <psykose> there are a few crypto mrs :p
2021-12-21 21:32:34 <anjan> Saijin_Naib[m]: ya, I want my entire thesis to be reproducible 
2021-12-21 21:33:27 <Saijin_Naib[m]> anjan: That's amazing! Usually you follow up to get the data/tooling and it's "whoops, that was on an old computer that I recycled" or something :|
2021-12-21 21:34:03 <anjan> lol, ya. plots are advertising not scholarship. The real scholarship is the code.
2021-12-21 21:34:34 <Saijin_Naib[m]> Mine's all locked up in proprietary formats until I get my hands on a few thousand dollar license and redo everything in FOSS tooling.
2021-12-21 21:34:44 <Saijin_Naib[m]> Hah, interesting way to think about it
2021-12-21 21:52:28 <anjan> any idea why this fails? https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/570820#L900
2021-12-21 21:52:32 <anjan> I dont see an error
2021-12-21 21:52:38 <anjan> and it compiles on other arches
2021-12-21 21:54:17 <ikke> error: cannot convert 'QDLDL_int*' {aka 'int*'} to 'const long long int*'
2021-12-21 21:57:17 <ikke> https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/570820#L900
2021-12-21 21:57:57 <anjan> ikke: hmmm, I guess just disable for x86, armv7, and armhf then?
2021-12-21 21:59:05 <ikke> that's the easiest if you do not care about those arches
2021-12-21 22:01:41 <psykose> Ap is qdldl_int_type which is compile time macro defined to int here, and the thing it's throwing it into is defined as a long long argument
2021-12-21 22:04:30 <mps> this python is popular in universities, I guess because professors can't understand and remember ';{}' characters
2021-12-21 22:10:24 <ikke> anjan: one trick to find errors with c related projects: look for ": error:"
2021-12-21 22:30:51 <anjan> thanks, Ill make a note lol
2021-12-22 00:39:19 <ahills> code written at universities can defeat even the most resilient packaging systems
2021-12-22 04:54:54 <ktprograms> Ariadne: Can you please check if !28734 looks good?
2021-12-22 04:58:03 <psykose> does the thing this will use have the ability to use it currently
2021-12-22 04:58:58 <psykose> that will use this*
2021-12-22 04:59:04 <ktprograms> psykose: I built py3-cairocffi with depends on py3-xcffib and it works well enough to build/run qtile, if that's what you mean.
2021-12-22 04:59:17 <psykose> you should add that to the mr then, and swap them
2021-12-22 04:59:48 <ktprograms> psykose: What do you mean by 'swap them'?
2021-12-22 04:59:58 <psykose> make whatever depends on this rebuild against it
2021-12-22 05:00:10 <psykose> if you add an aport as a dep for something you may as well rebuild against it, if it makes sense
2021-12-22 05:01:05 <ktprograms> psykose: Does it work to add the rebuild in the same MR? Will the dep be available?
2021-12-22 05:01:18 <psykose> it does yes, the ci rebuild in dep order
2021-12-22 05:01:28 <psykose> and dep changes in the mr are used in the mr
2021-12-22 05:02:02 <psykose> also you have a cool name
2021-12-22 05:03:19 <ktprograms> psykose: I see, thanks
2021-12-22 05:05:55 <ktprograms> psykose: Should the rebuild be in a separate commit?
2021-12-22 05:06:44 <psykose> each change in a separate commit
2021-12-22 05:29:04 <ktprograms> psykose: Ok, thanks
2021-12-22 06:35:41 <ktprograms> Any thoughts on moving the qemu-binfmt.initd from qemu-openrc to a qemu-openrc-binfmt subpackage such that users (like me) who want to set up qemu + binfmt_misc but don't need the other features in the qemu-openrc package and don't want the extra dependencies (qemu and socat) can do so? (I'd ask jirutka but he doesn't seem to be on IRC)
2021-12-22 08:05:57 <anjan> psykose: hey, I just wanted to say thanks alot for reviewing my patches lately. I really appreciate it.
2021-12-22 08:06:10 <psykose> i try
2021-12-22 08:06:19 <anjan> Im still new to packaging on alpine and thanks for being patient with me and giving me detailed explanations lol
2021-12-22 08:06:38 <psykose> also i can reproduce the build failure.. the files are autogenned, fun
2021-12-22 08:07:06 <anjan> psykose: ya, there's packages where I just run newapkbuild and all the tests and everything run perfectly
2021-12-22 08:07:13 <anjan> and then there's stuff like that...
2021-12-22 08:10:17 <psykose> you can also drop the uranium apkbuild for now i guess, since it's vendored
2021-12-22 08:11:01 <anjan> psykose: I thought it would be nice to install that way since it installs uranium's dependancies
2021-12-22 08:11:14 <psykose> dependencies?
2021-12-22 08:11:42 <psykose> you can comment them in cura ed _depends_uranium= and then add from that
2021-12-22 08:13:15 <anjan> sorry how?
2021-12-22 08:14:59 <psykose> https://img.ayaya.dev/J7h8u7kBtzko
2021-12-22 08:21:05 <anjan> psykose: oh, I meant the uranium package has some depends
2021-12-22 08:21:19 <psykose> ahh, i see
2021-12-22 08:21:21 <anjan> and it's a seperate package so by installing uranium, cura gets them
2021-12-22 08:21:22 <psykose> sure, if you want
2021-12-22 08:21:43 <psykose> i think i will look at how to not vendor it anyway, if it somehow gets to a built state
2021-12-22 08:22:55 <anjan> psykose: ya, I wish I could figure out why it's dependancy is not building
2021-12-22 08:22:59 <anjan> it builds on void
2021-12-22 08:23:01 <anjan> and arch
2021-12-22 08:23:13 <psykose> musl void?
2021-12-22 08:28:33 <anjan> psykose: https://voidlinux.org/packages/?arch=x86_64-musl&q=pynest2d
2021-12-22 08:33:58 <anjan> I cant figure out what they did that Im not doing, if you find out - please let me know psykose 
2021-12-22 08:34:09 <anjan> again, thanks for helping me with everything.
2021-12-22 08:34:11 <psykose> for a start py3-sip is like 6.5.0 instead of 4.9
2021-12-22 08:34:21 <psykose> upgrading it is a pain though
2021-12-22 08:43:05 <anjan> psykose: if I end up upgrading it, would you like it in a seperate MR?
2021-12-22 08:45:11 <anjan> I dont think Ill have a chance to do it lol
2021-12-22 08:50:10 <psykose> i don't think that's it, it's the same for the arch build
2021-12-22 08:50:18 <psykose> idk, you'll figure it out
2021-12-22 08:51:53 <anjan> psykose: I dont think I will, I spent all night on it lol
2021-12-22 08:52:04 <psykose> you and me both on random packaging :p
2021-12-22 08:52:12 <psykose> i've been working on things for like 17 hours
2021-12-22 08:52:20 <anjan> take a break!!
2021-12-22 08:52:33 <psykose> chatting to cute people helps
2021-12-22 08:52:44 <skarnet> she's talking about me
2021-12-22 08:53:45 <psykose> if only we were talking
2021-12-22 08:54:15 <skarnet> sorry, *some* of us sleep sometimes
2021-12-22 08:54:16 <psykose> i slept for 18 hours yesterday
2021-12-22 08:54:20 <psykose> definitely up there
2021-12-22 08:55:23 <skarnet> 35 hour day cycles can't be healthy
2021-12-22 08:55:51 <psykose> i was awake for 34 hours before that
2021-12-22 08:55:54 <psykose> so more like 52 hour cycles
2021-12-22 08:56:01 <skarnet> >.>
2021-12-22 08:56:10 <psykose> i'm fine, i promise
2021-12-22 09:02:52 <anjan> psykose: I think I found a patch to fix it
2021-12-22 09:03:02 <psykose> yoink
2021-12-22 09:04:22 <psykose> what's the patch
2021-12-22 09:06:24 <anjan> psykose: https://patch-diff.githubusercontent.com/raw/tamasmeszaros/libnest2d/pull/18.patch
2021-12-22 09:06:51 <psykose> ah, this looks like it does something
2021-12-22 09:07:04 <anjan> ya! =D
2021-12-22 09:07:24 <anjan> IT WORKS
2021-12-22 09:07:27 <anjan> GOD BLESS
2021-12-22 09:08:26 <anjan> my gf wanted me to 3d print something for her and I was worried I couldnt since I installed alpine on my laptop lol
2021-12-22 09:10:01 <psykose> grats :D
2021-12-22 09:16:33 <anjan> all the checks passed
2021-12-22 09:17:45 <psykose> now you just need cura-binary vendored for translations i guess
2021-12-22 09:18:55 <anjan> psykose: ya, but thats not a top priority
2021-12-22 09:19:05 <anjan> just getting english to work is a massive achievement lol
2021-12-22 09:19:40 <psykose> don't think you need the CXX_STANDARD
2021-12-22 09:20:30 <psykose> the uranium failing test is probably the same one i disabled in cura
2021-12-22 09:22:20 <psykose> and i guess there's the cmake spam i will fix eventually if !28731 gets merged, the rest looks good
2021-12-22 09:22:32 <psykose> unvendoring uranium would take some amount of cmake patching
2021-12-22 09:22:43 <psykose> not entirely sure if it's just changing the dep declaration, didn't try
2021-12-22 09:28:33 <anjan> psykose: cura still doesnt launch =(
2021-12-22 09:28:39 <psykose> whats the errors
2021-12-22 09:28:47 <anjan> psykose: there are a lot
2021-12-22 09:29:11 <anjan> it didnt crash
2021-12-22 09:29:13 <psykose> paste em all
2021-12-22 09:29:23 <anjan> it's just stuck
2021-12-22 09:30:19 <anjan> psykose: https://paste.sr.ht/~anjan/e9670f1ee1ecb0bd4faa1ff8bd7fa858a1ee6d73
2021-12-22 09:31:51 <psykose> it's missing py3-zeroconf, py3-trimesh(not packaged), qt5-qtquickcontrols ( i think)
2021-12-22 09:32:15 <psykose> add the last first and see if that gets rid of the qtquick warns, the rest are easy
2021-12-22 09:35:12 <psykose> idk where QtGraphicalEffects comes from though, i'm not sure if it's in thre
2021-12-22 09:35:14 <psykose> there*
2021-12-22 09:36:00 <anjan> psykose: https://archlinux.org/packages/community/any/cura/
2021-12-22 09:36:23 <psykose> qt5-qtgraphicaleffects then
2021-12-22 09:37:54 <psykose> and a bunch of qt5-qtquick
2021-12-22 09:39:29 <psykose> just controls actually
2021-12-22 09:39:31 <psykose> and i think that's all
2021-12-22 09:39:54 <psykose> also you are missing your XDG_RUNTIME_DIR
2021-12-22 09:40:03 <psykose> it's important to have that :p
2021-12-22 09:42:44 <anjan> whoops
2021-12-22 09:42:47 <anjan> idk why that isnt set
2021-12-22 09:43:31 <psykose> no pam login is the main reason
2021-12-22 09:44:40 <psykose> a quick shitty hack that fails to clear it on session end per xdg standard is https://img.ayaya.dev/movyaa0FaGn9
2021-12-22 09:45:12 <anjan> nice, Ill add that to my .profile
2021-12-22 09:45:53 <psykose> as long as you don't juggle sessions it should be fine, otherwise, the only other way i know of is having pam logins sadly
2021-12-22 09:46:45 <psykose> if you use it only for wm start and dont have it in a dynamically read profile on every shell start i guess you can append random chars to that and it should fix that issue :p
2021-12-22 09:46:56 <anjan> psykose: https://paste.sr.ht/~anjan/e932dbc33520fee3137f6d2b2f23dc4ffb5a92e8
2021-12-22 09:47:26 <anjan> psykose: oh, I guess I should put it in my xinitrc then
2021-12-22 09:47:33 <psykose> yes, that is better
2021-12-22 09:48:00 <psykose> why is that python3.9
2021-12-22 09:48:07 <anjan> any idea why I still dont have output?
2021-12-22 09:48:09 <psykose> still missing trimesh
2021-12-22 09:48:12 <anjan> Im using alpine stable
2021-12-22 09:48:17 <anjan>  python-trimesh (optional) - Reading AMF files
2021-12-22 09:48:22 <psykose> ah
2021-12-22 09:48:23 <anjan> psykose: according to arch
2021-12-22 09:48:57 <psykose> qtquickcontrols2 instead maybe
2021-12-22 09:49:00 <psykose> it needs 2.3 in the log output
2021-12-22 09:50:04 <psykose> libsavitar isnt optional on arch, though that is just a warning here
2021-12-22 09:50:47 <psykose> also that arch build shows how to unvendor uranium
2021-12-22 09:54:33 <anjan> ayyyy
2021-12-22 09:54:35 <anjan> it loaded up
2021-12-22 09:54:38 <anjan> and it's only 5am
2021-12-22 09:55:31 <psykose> :)
2021-12-22 11:07:35 <ktprograms> ncopa: Now that the Python 3.10 upgrade is finished, can you please merge !27943 and !27947 ? Thanks!
2021-12-22 11:27:29 <ncopa> i just bumped into a disk full. seems like /tmp is no longer wiped?
2021-12-22 11:27:54 <ncopa> wiped on reboot
2021-12-22 11:29:22 <ncopa> "it is recommended that files and directories located in /tmp be deleted whenever the system is booted."  https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html
2021-12-22 11:29:27 <psykose> 0008-bootmisc-switch-wipe_tmp-setting-to-no-by-default.patch 1a30681d3faba4ea4cedeb95eb8df62d8afee434
2021-12-22 11:29:54 <psykose> er, not that commit
2021-12-22 11:29:57 <psykose> but that file
2021-12-22 11:30:11 <ncopa> I think the history behind is this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13070
2021-12-22 11:30:57 <psykose> yep
2021-12-22 11:31:54 <ncopa> but, it looks like there was some sort of bug in the code, that made it to not return error on cd or similar
2021-12-22 11:32:07 <ncopa> i still think we should wip /tmp
2021-12-22 11:33:05 <psykose> ncopa: what do you think of !28731
2021-12-22 12:08:40 <ktprograms> ncopa: Would there be any licenisng problems with using the fixes in https://github.com/archlinux/svntogit-community/commit/fc9cd4b15d312ff12aeaf2bffc30e48d933e6576 for py3-sphinx-argparse?
2021-12-22 12:10:49 <psykose> what fixes? it just upgrades the tag, and disables some tests
2021-12-22 12:11:14 <psykose> no licensing issues for 5 lines of changes, but you can credit things to the link if you want
2021-12-22 12:11:28 <ktprograms> psykose: At the end, the removing of the top level test/ directory in site_packages.
2021-12-22 12:11:41 <psykose> that falls under 'trivial change'
2021-12-22 12:12:54 <ktprograms> psykose: I see, thanks
2021-12-22 12:24:27 <ncopa> psykose: mixed feelings about abuild-cmake. I'm no big fan of wrapper/helper scripts that hides what is actually going on
2021-12-22 12:24:37 <psykose> abuild-meson does the same
2021-12-22 12:24:52 <ncopa> abuild-meson does not give me sparks of joy
2021-12-22 12:25:14 <psykose> i suppose it's fine, but everything having those same 10 lines in every apkbuild mixed around isn't very fun either
2021-12-22 12:25:17 <psykose> your decision though
2021-12-22 12:25:59 <ncopa> the reason is, sometimes when you debug a thing, you wonder how it was actually built
2021-12-22 12:26:08 <ncopa> then you see a wrapper script that hides that
2021-12-22 12:26:21 <ncopa> so you end up need to find the sources of wrapper script
2021-12-22 12:26:41 <ncopa> and then it goes "where do i find the source of the abuild-cmake"
2021-12-22 12:26:47 <ncopa> spend 15 mins searching for it
2021-12-22 12:26:52 <psykose> i suppose
2021-12-22 12:26:57 <ncopa> and then you finally find it
2021-12-22 12:27:07 <ncopa> and you think you know what it does
2021-12-22 12:27:12 <psykose> sure, i'll change it to just plain cmake with minsizerel some other time
2021-12-22 12:27:22 <ncopa> but the bug still does not makes sense
2021-12-22 12:27:38 <ncopa> and after a few hours you realized it was built with different version of abuild-cmake
2021-12-22 12:28:00 <ncopa> so you need to find out exactly which versino of abuild-cmake it was built with
2021-12-22 12:28:05 <ncopa> and how do you find that out?
2021-12-22 12:28:42 <ncopa> i have that experience from the early days when alpine was built with gentoo
2021-12-22 12:28:52 <ncopa> who has lots of those magic helpers
2021-12-22 12:29:06 <ncopa> and eclasses
2021-12-22 12:29:31 <ncopa> so whe I wrote abuild and the APKBUILD format, one of the main goals was to make the format transparent
2021-12-22 12:30:00 <ncopa> the price is code duplication
2021-12-22 12:30:30 <psykose> that code duplication is insane though, it takes forever to make these changes consistent
2021-12-22 12:30:41 <psykose> there are like 8 different ways of using cmake in aports
2021-12-22 12:31:08 <psykose> half the things are missing the crossopts, which i'm not sure are even needed for anything
2021-12-22 12:31:39 <ncopa> cross opts are probably needed for the packages in the bootstrap chain
2021-12-22 12:31:59 <ncopa> and yes, inconsistency is also a downside
2021-12-22 12:32:09 <ncopa> the problem is, i don't know where to draw the limit
2021-12-22 12:32:17 <ncopa> maybe this is something for the TSC
2021-12-22 12:32:25 <psykose> no, it's fine as is
2021-12-22 12:33:58 <ncopa> personally im kinda ok that it is not consistent, and let the maintainer chose whatever he/she prefers
2021-12-22 12:37:19 <ncopa> but the again, I think the opinion of the people doing the actual work matters, so I don't know
2021-12-22 12:43:24 <ktprograms> psykose: What's wierd is the 'test/' folder isn't present in the .apk I built, so I'm not sure if it's something different in the Arch package building process, but I don't see any difference in how I'm doing it.
2021-12-22 12:44:19 <psykose> probably env var or similar
2021-12-22 12:48:53 <ktprograms> psykose: I don't see any vars being set, but nevermind, I don't care as long as the dir doesn't exist.
2021-12-22 12:49:06 <psykose> invisible global ones
2021-12-22 12:49:09 <psykose> or something else
2021-12-22 12:49:13 <psykose> i wouldn't knowo
2021-12-22 12:50:22 <ktprograms> When I modify a patch taken from a commit (because the commit is after the latest release), should I note anywhere that the patch is modified?
2021-12-22 13:07:13 <psykose> you can leave a comment on the patch
2021-12-22 13:15:41 <ktprograms> psykose: Like 'Modified from <link to upstream commit>'?
2021-12-22 13:17:57 <psykose> sure
2021-12-22 13:18:27 <ktprograms> psykose: Ok, thanks
2021-12-22 13:18:31 <psykose> 'this is ab2718d8cbe2414151 from upstream, but rebased onto our version tag'
2021-12-22 13:18:56 <psykose> '$url \n rebased onto our tag' etc
2021-12-22 13:19:06 <psykose> it really doesn't matter what you put as long as reference to upstream is there
2021-12-22 13:19:51 <ktprograms> psykose: Not so much rebased as just removed unneeded changes
2021-12-22 13:20:06 <psykose> there is no point to do that
2021-12-22 13:21:48 <ktprograms> psykose: The unneeded change is in a file that doesn't exist in the pypi tarball
2021-12-22 13:22:10 <psykose> then it's not an unneeded change, you are fixing the patch
2021-12-22 13:25:32 <ktprograms> psykose: Yes, that better describes it.
2021-12-22 13:27:22 <mps> ncopa: nice to see that we have same opinion about helpers in abuild and APKBUILD
2021-12-22 13:28:20 <mps> and nice to read what was your reason to create APKBUILD, i.e. transparency
2021-12-22 13:28:53 <mps> nowadays it becoming 'dirty' with helpers
2021-12-22 14:02:38 <ktprograms> ncopa: Can you please look at !27947 again? I fixed the test failures. Thanks!
2021-12-22 14:06:23 <psykose> you can just do `python -m pyproject2setuppy.main build`, there's no need for the patch to make a setup.py
2021-12-22 14:06:37 <psykose> python3*
2021-12-22 14:23:05 <ktprograms> psykose: I see, thanks
2021-12-22 14:52:29 <minimal> psykose: did you ever notice if there was a Nomad github issue raised by anyone for the yuidoc problem?
2021-12-22 14:53:17 <psykose> no, why
2021-12-22 14:54:35 <minimal> psykose: well I didn't see anything on the Nomad github to indicate it was a known problem
2021-12-22 14:54:46 <psykose> why would there be? 99.9999999% of the people using this use it from containers/similar, and the only people that run into this issue are those that build it themselves within the last 6 months on 16.x
2021-12-22 14:57:26 <minimal> right but I'd assume Hashicorp would want to know that there's a problem building it with NodeJS 16.x, especially as 16.13.1 appears to be an LTS
2021-12-22 14:58:02 <psykose> then open an issue
2021-12-22 14:58:45 <minimal> psykose: I was intending to if there wasn't already one open, hence my initial question to you
2021-12-22 14:59:44 <psykose> other distros don't even build it with node, i guess they are skipping the uii
2021-12-22 15:04:41 <psykose> i'm also assuming the go build invocation embeds all the ui assets into the single go binary, and it actually works
2021-12-22 15:27:39 <jvoisin> stupid question, but shall APKBUILD use "make -j `nproc`" instead of `make` ?
2021-12-22 15:28:30 <Sheila> abuild already has configuration for that in abuild.conf, there's no need for you to do that.
2021-12-22 15:28:53 <Sheila> (unless the buildsystem is racy, in which case you'd want -j1 specifically.)
2021-12-22 15:35:11 <Hello71> also `` is obsolete, use $()
2021-12-22 15:52:50 <ikke> `` is markdown for inline code 
2021-12-22 15:53:16 <ikke> Oh, but not in the first example 
2021-12-22 15:55:00 <orbea> fwiw setting -j to nproc is dangerous if there is not enough ram or the build is insane (libreoffice)
2021-12-22 15:56:32 <psykose> i believe the people running the builders are already aware given how long this has been done
2021-12-22 15:56:39 <psykose> libreoffice is also pretty tame
2021-12-22 15:57:00 <orbea> i figured they would
2021-12-22 15:57:13 <orbea> its a rather heavy build
2021-12-22 15:57:19 <orbea> but yea, there is probably worse
2021-12-22 16:07:01 <ikke> orbea: fyi, it defaults to nproc on the builders 
2021-12-22 16:28:07 <jvoisin> Sheila: thank you
2021-12-22 21:58:01 <omni> why don't releases' linux-lts follow longterm?
2021-12-22 21:59:11 <mps> omni: it does
2021-12-22 21:59:42 <omni> I mean, in 3.13 linux-lts is at 5.10.78 and in 3.14 it is at 5.10.82, latest is 5.10.88
2021-12-22 22:00:30 <mps> when the alpine stable released then current linux LTS is used
2021-12-22 22:01:01 <omni> in 3.12 linux-lts is at 5.4.143 but latest is 5.4.167
2021-12-22 22:01:25 <mps> sometimes some options are deprecated and even drivers removed so doesn't make sense backport it to old alpine stable releases
2021-12-22 22:01:34 <omni> I'm just wondering if this is they way it's supposed to be or if I should create MRs
2021-12-22 22:02:07 <mps> I would left -lts to ncopa
2021-12-22 22:03:01 <mps> it is not enough to upgrade just -lts, there are other things which need upgrades which depends on kernel
2021-12-22 22:04:05 <omni> sure, but I also assume ncopa has enough to do as is and this might just be oversight
2021-12-22 22:04:35 <mps> no, it is not, he upgrades old kernels when there are reasons
2021-12-22 22:06:52 <omni> would XSA-391 and XSA-392 be reason enough to bump on all supported releases?
2021-12-22 22:08:08 <mps> I don't know, didn't looked at these
2021-12-22 22:08:40 <mps> but thank you, you reminded me that I have to upgrade linux-edge in 3.15 :)
2021-12-22 22:08:55 <omni> np =)
2021-12-22 22:09:44 <dne> at least XSA-392 I'd say: "Guest can force Linux netback driver to hog large amounts of kernel memory
2021-12-22 22:09:46 <dne> "
2021-12-22 22:10:39 <omni> but as a user I would've assumed linux-lts on a supported release to follow longterm not just for security fixes but also bug fixes and stability improvements
2021-12-22 22:11:08 <mps> yes, I read changelog today but only for 5.16.11 not old ones
2021-12-22 22:12:38 <minimal> omni: I guess the idea is to change as little as possible in old releases - if you update the kernel then you might have to update things like zfs which might require you to update something else, etc
2021-12-22 22:13:02 <mps> minimal: right
2021-12-22 22:13:31 <omni> yeah, I can see that it could easily grow
2021-12-22 22:13:52 <mps> but 'serious' bugs and sec fixes are usually fixed
2021-12-22 22:15:11 <minimal> yeah, in that case the risk of not fixing security issues outweighs the risk of possibly breaking things when doing the security fix
2021-12-22 22:17:44 <omni> I'll open an MR for at least 3.15 (this time also bumping aports that need to be rebuilt against the new kernel version) and see what ncopa has to say about it later
2021-12-22 22:19:50 <mps> omni: better create issue
2021-12-22 22:20:21 <mps> by MR you will just make things somewhat more cumbersome for ncopa
2021-12-22 22:20:48 <omni> really?
2021-12-22 22:21:03 <mps> yes really
2021-12-22 22:21:42 <omni> I get it when I don't bump things like I did earlier today, so it's not complete (sorry about that)
2021-12-22 22:21:59 <mps> he has scripts and tools to do upgrade in 'defined' manner and MR just complicates this
2021-12-22 22:22:32 <omni> fine
2021-12-22 22:22:46 <mps> this is why I also ignore MRs for linux-edge
2021-12-22 22:25:07 <omni> how about patches via email?
2021-12-22 22:26:31 <mps> omni: :)
2021-12-22 22:27:07 <mps> just create issue and assign to ncopa, this is best approach
2021-12-22 22:28:44 <donoban> ey omni I did a MR for rebuild tor due zstd upgrade
2021-12-22 22:30:55 <donoban> one question about APKBUILD, pkgusers and pkggroups just add new users/groups if missing? how should I add that new user to existing group like audio?
2021-12-22 22:33:41 <mps> donoban: in script
2021-12-22 22:34:21 <mps> post/pre-install
2021-12-22 22:34:28 <donoban> ok thanks mps 
2021-12-22 22:35:03 <mps> but why you would do that? that is admin job
2021-12-22 22:35:56 <donoban> uhM, well I try to package spotifyd as a rc-service
2021-12-22 22:36:30 <donoban> it's supposed to be able to play sound
2021-12-22 22:37:02 <donoban> altought I'm not sure what group exactly will it need
2021-12-22 22:37:11 <mps> hmm, not sure this is good idea on alpine to add users in groups automatically
2021-12-22 22:37:38 <donoban> anyway it needs manual configuration so I can skip that
2021-12-22 22:38:49 <donoban> well I will skip that, try to draft and MR and discuss later
2021-12-22 22:38:53 <donoban> thanks
2021-12-22 22:39:06 <donoban> to draft a MR*
2021-12-22 22:52:02 <omni> as a mere mortal used, I cannot assign tickets I create
2021-12-22 22:52:52 <omni> donoban: had they only been merged in opposite order, just 8 minutes apart! ;)
2021-12-22 22:53:33 <donoban> ahh lol
2021-12-22 22:53:40 <donoban> hehe
2021-12-22 22:57:02 <omni> well spotted though
2021-12-22 22:57:43 <donoban> just cleaning up
2021-12-22 22:58:17 <omni> of course we want to use advanced zstd functionality!
2021-12-22 22:58:32 <donoban> hehe, at least on the rolling edge :P
2021-12-22 22:58:54 <omni> yeah
2021-12-22 22:59:01 <omni> at least one good thing is coming out of facebook(tm)
2021-12-22 23:01:22 <donoban> lol, I didn't know
2021-12-22 23:03:07 <donoban> well, it's late, see you guys
2021-12-22 23:03:29 <donoban> good night! :P
2021-12-22 23:03:47 <omni> nn
2021-12-23 00:53:53 <ktprograms> Would the best way to disable a test (when using pytest) be to patch it out, or use pytest -k 'not ...' ?
2021-12-23 02:10:00 <smcavoy> can anyone look at !28013 ? 
2021-12-23 02:10:35 <smcavoy> the listed maintainer has been unavailable for the last several releases...
2021-12-23 03:37:47 <lzsaver> ncopa, take a look !28560
2021-12-23 10:29:18 <smcavoy>    ~.
2021-12-23 15:13:08 <donoban> Hello, I think that there is a bug with 'abuild rootbld' and pkgusers/pkggroups, it adds them in my host instead the chroot
2021-12-24 03:28:47 <thiagowfx> are you aware of any existing package that implements command_not_found for apk(8)? I.e. basically something like this: http://ix.io/3Jj8
2021-12-24 03:29:22 <thiagowfx> i.e. when you search for a binary that isn't installed in the system, it uses 'apk search' or similar underneath to list providers
2021-12-24 03:31:16 <thiagowfx> I wrote one, it's actually quite simple: http://ix.io/3Jj9, I was just wondering if it's something that already exists, it seems a common enough operation. If it doesn't exist I am happy to send a more polished version of that upstream 
2021-12-24 03:50:54 <Ariadne> ncopa: it would be nice to have CONFIG_FSL_MC_UAPI_SUPPORT=y
2021-12-24 03:50:58 <Ariadne> on aarch64
2021-12-24 05:22:09 <psykose> mps: may i humbly request an enabling of https://cateee.net/lkddb/web-lkddb/INTEL_RAPL.html for config-edge.x86_64
2021-12-24 05:59:54 <ktprograms> Ariadne: Does !28734 look ok to you?
2021-12-24 06:02:23 <ktprograms> Ariadne: Thanks for looking at it.
2021-12-24 06:33:20 <craftyguy> are old versions of packages archived somewhere?
2021-12-24 06:49:57 <clandmeter> craftyguy: no
2021-12-24 06:50:54 <clandmeter> its already hard to keep up with current pkgs
2021-12-24 06:51:28 <craftyguy> ok
2021-12-24 07:02:40 <ncopa> good morning
2021-12-24 07:03:02 <ncopa> Ariadne: what do I write in the commit message on why we enable CONFIG_FSL_MC_UAPI_SUPPORT=y?
2021-12-24 07:03:44 <Ariadne> it is needed to configure the 10g/40g NICs on honeycomb
2021-12-24 07:04:04 <ncopa> 👍
2021-12-24 07:06:00 <ncopa> does it need to be backported to 3.15-stable?
2021-12-24 07:21:53 <Ariadne> would be nice but restool is needed too
2021-12-24 07:22:29 <Ariadne> so not important
2021-12-24 07:41:31 <Yin-Dawg> Hi, I am trying to re-compile the Bind9 package with the " --disable-isc-spnego" flag disabled.
2021-12-24 07:42:56 <Yin-Dawg> But am unable to sort out the dependencies when invoking "abuild -r".  I get the error: "ERROR: No such package: .makedepends-bind".  Is someone able to point me in the right direction as to what I'm doing wrong?
2021-12-24 07:57:26 <ktprograms> Yin-Dawg: Can you please post the full log (to a pastebin)?
2021-12-24 08:06:20 <Yin-Dawg> @ktprograms: https://pastebin.com/JtidFR3M
2021-12-24 08:12:08 <ktprograms> Yin-Dawg: What do you have in /etc/apk/repositories?
2021-12-24 08:13:25 <Yin-Dawg> @edge https://mirror.xtom.com.hk/alpine/edge/main
2021-12-24 08:13:28 <Yin-Dawg> one line only
2021-12-24 08:14:27 <ktprograms> I think that's the problem. You should probably remove the tag (the `@edge` part) because apk needs a default repository to use.
2021-12-24 08:18:06 <Yin-Dawg> @ktprograms: Thanks, I have removed the '@edge' in /etc/apk/repositories, apk update, 'abuild-apk update'.  Then ran the 'abuild -r' command.  The output I get is: https://pastebin.com/W6wgXA5A 
2021-12-24 08:19:19 <mps> psykose: what is config option name?
2021-12-24 08:24:04 <ktprograms> Yin-Dawg: I'm guessing the problem is that in /etc/apk/world (the list of packages you have installed), a lot of the packages would have been installed from the tagged @edge repository. Can you check, in /etc/apk/world, do you have lots of lines like 'pkgname@edge' ?
2021-12-24 08:24:05 <Yin-Dawg> Dear kitprograms, I found the problem.  I checked /etc/apk/world and I had a package installed with the @edge tag.  It was confusing APKBUILD so I purged that and it started working.  Hope this helps someone in the future.
2021-12-24 08:24:27 <Yin-Dawg> Oh we solved it at the same time.  Thanks again. ktprograms.
2021-12-24 08:25:31 <ktprograms> Yin-Dawg: Great that you figured it out! FYI in future, ensure that you have a repo in /etc/apk/repositories without a tag. The tag is only (for example) enabling the testing repo but not accidentally installing packages from it (you need to deliberately use 'pkgname@testing')
2021-12-24 08:26:38 <Yin-Dawg> I think i might cry if I get this to work...
2021-12-24 08:26:49 <Yin-Dawg> it's been stressing me out lol
2021-12-24 11:03:46 <Thermi> Can somebody please merge this MR for me? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28804
2021-12-24 11:03:52 <Thermi> Also: Merry Crysis!
2021-12-24 12:06:18 <Thermi> tyvm!
2021-12-24 12:11:10 <mps> Thermi: :) (Merry Crysis! lol)
2021-12-24 13:44:43 <Hello71> thiagowfx: i don't think alpine philosophy believes in cnf. also, your script doesn't work properly; try apk search cmd:ls
2021-12-24 13:44:55 <Hello71> apk list -P cmd:ls is better
2021-12-24 14:37:31 <PureTryOut> is there any tool to easily remove a RPATH set to `/home/<whatever>` from a library?
2021-12-24 14:42:06 <mps> chrpath? didn't used so don't know for sure
2021-12-24 14:43:19 <ikke> Yes, chrpath 
2021-12-24 14:47:31 <mps> psykose: linux-edge for x86_64 have this already CONFIG_PERF_EVENTS_INTEL_RAPL=m
2021-12-24 14:48:09 <psykose> mps: https://cateee.net/lkddb/web-lkddb/INTEL_RAPL.html as the link says, CONFIG_INTEL_RAPL
2021-12-24 14:48:11 <psykose> not the same option
2021-12-24 14:48:46 <mps> I don't see CONFIG_INTEL_RAPL in config
2021-12-24 14:49:01 <psykose> yes, it's not in there unless you enable it
2021-12-24 14:49:05 <PureTryOut> I tried chrpath with `--delete`, but it gives me "open: No such file or directory" and same for "elf_open"
2021-12-24 14:49:05 <psykose> you can see it in config-lts
2021-12-24 14:49:18 <psykose> it is in the menu helpers, but not the text file for some reason
2021-12-24 14:49:46 <mps> psykose: it is not in any Kconfig file
2021-12-24 14:50:16 <mps> it is related to MSR and MSR is dead code
2021-12-24 14:50:29 <psykose> https://img.ayaya.dev/oWIhZG4yIRqk
2021-12-24 14:51:36 <mps> hmm
2021-12-24 14:52:17 <mps> aha powercap subsystem
2021-12-24 14:54:05 <mps> ok, noted. will look at next upgrade
2021-12-24 14:55:57 <psykose> thanks :)
2021-12-24 15:07:31 <PureTryOut> ah my issue with chrpath was doing it in a subpackage but it should happen in the package function. Strange but doable for me
2021-12-24 15:38:15 <mps> Marry Christmas to everyone who celebrate and to all who don't :)
2021-12-24 16:00:48 <MaximKarasev[m]> Thanks!
2021-12-24 16:34:19 <adhawkins> Hi all. Trying to update one of my python packages. It's distributed with a pyproject.toml. In order to get a setup.py file, I was downloading from pythonhosted.org, but the package for the latest version doesn't have a setup.py in it.
2021-12-24 16:34:56 <adhawkins> I've tried creating a 'wrapper' setup.py file that invokes pyproject2setuppy.main, but that then fails at the point of test.
2021-12-24 16:35:04 <adhawkins> Anyone got any suggestions as to how to get round this?
2021-12-24 16:39:14 <adhawkins> https://paste.debian.net/1224647/
2021-12-24 16:41:46 <ikke> I don't have experience with it yet, but I believe you can use pip install nowadays to install local packages nowadays
2021-12-24 16:42:27 <ikke> it has options as --prefix, --no-deps, --use-pep517
2021-12-24 16:47:16 <adhawkins> It's not the install that's the issue, it's the test.
2021-12-24 16:47:31 <adhawkins> If I copy the setup.py from the 0.7.1 tarball (the last version I packaged) it tests fine.
2021-12-24 16:52:53 <adhawkins> I seem to remember when I initally packaged this, someone recommended getting the tarball from somewhere other than github, as it would have a setup.py in it. That no longer seems to be the case.
2021-12-24 16:53:19 <ikke> Projects stop providing setup.py, it's apparently deprecated
2021-12-24 16:53:31 <ikke> Moving towards pep517 / pep518 builds
2021-12-24 16:55:51 <adhawkins> Ok, so moving forward what's the 'plan' for alpine?
2021-12-24 16:56:09 <ikke> I don't think there is an official plan yet
2021-12-24 16:56:26 <ikke> But more distros are strugling
2021-12-24 16:56:47 <adhawkins> Ok. Will have to see if someone a bit more knowledgeable than me has any idea then!
2021-12-24 16:58:16 <ikke> We'll have to see where the ecosystem is settling on
2021-12-24 16:58:47 <thiagowfx> Hello71: ok thanks, I will just keep it in my dotfiles then. It could be improved for sure
2021-12-24 16:59:31 <thiagowfx> is it possible to do something like 'apk search cmd:podman$'? I.e. matching with the $. it seems apk search only uses globbing, if it was possible to use a regex it could be slightly better
2021-12-24 17:00:04 <Hello71> why don't you want to use apk list
2021-12-24 17:00:34 <thiagowfx> I haven't tried that yet actually, let me see
2021-12-24 17:01:20 <thiagowfx> Hello71: ah I see, it's much nicer with 'apk list -P' indeed. Thanks for the suggestion!
2021-12-24 17:02:05 <Hello71> mps: what do you mean msr is dead code
2021-12-24 17:04:41 <mps> Hello71: it was announced for deprecation few months ago, iirc
2021-12-24 17:06:22 <adhawkins> Ok ikke, if I use pip3 it seems to work Ok. What command should I use in 'build' and 'package'? They're both basically the same?
2021-12-24 17:06:49 <ikke> adhawkins: yeah, I was looking for something, but it seems like there are no separate ways to do that anymore
2021-12-24 17:07:20 <adhawkins> An empty 'build' seems to work. But is that acceptable?
2021-12-24 17:07:31 <ikke> yes
2021-12-24 17:07:43 <ikke> There are plenty of packages that do not have a build function and just package
2021-12-24 17:13:58 <adhawkins> Cool, will do that then. Thanks ikke
2021-12-24 17:18:18 <adhawkins> Something seems to have a specific dependency on this package
2021-12-24 17:18:30 <adhawkins> https://paste.debian.net/1224652/
2021-12-24 17:18:47 <adhawkins> I can't find any reference to it anywhere in an APKBUILD file in the tree I have.
2021-12-24 17:19:05 <adhawkins> Is the package py3.10?
2021-12-24 17:20:03 <ikke> No, it's a provides
2021-12-24 17:20:22 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1222
2021-12-24 17:21:37 <adhawkins> I'm not sure where the error is coming in. I'm trying to build emborg (which uses this package) and I'm getting that error.
2021-12-24 17:21:51 <adhawkins> I assumed emborg would use the local copy of the package I'd built to get the latest version. Is that not the case?
2021-12-24 17:22:07 <ikke> What is in your /etc/apk/world?
2021-12-24 17:22:17 <adhawkins> I'm using dabuild, so not sure.
2021-12-24 17:22:56 <ikke> ok, so less relevant
2021-12-24 17:25:33 <adhawkins> I have local builds of this module at version 0.7.1-r1 and 0.9.1-r1 (that should be r0, will fix that). PResumably it'll only pick up the newer one?
2021-12-24 17:26:11 <ikke> It should
2021-12-24 17:26:31 <adhawkins> The failure is coming at the point where it tries to install the build dependencies. Then I get the error in the latest paste.
2021-12-24 17:27:09 <adhawkins> Ah hang on, now I've got rid of the -r1 for this package and built the r0, it's working...
2021-12-24 17:27:17 <adhawkins> 
ACTION is confused...

2021-12-24 17:29:06 <adhawkins> Ok, so the way I've got it working is to remove the 'build' function, and changed 'package from 'python3 setup.py install --prefix=/usr --root="$pkgdir"' to 'pip3 install --prefix=/usr --root="$pkgdir" .'
2021-12-24 17:29:32 <adhawkins> And added a makedep of py3-pip
2021-12-24 17:32:40 <adhawkins> I'm also now getting the sources direct from github again.
2021-12-24 17:37:40 <adhawkins> !28808
2021-12-24 17:37:45 <adhawkins> Does that look Ok ikke?
2021-12-24 17:39:40 <ikke> adhawkins: maybe add --no-deps to install
2021-12-24 17:39:56 <ikke> Otherwise it will still install dependencies when they are missing
2021-12-24 17:40:06 <adhawkins> Ah ok, will do.
2021-12-24 17:42:33 <adhawkins> Ok, done.
2021-12-24 17:45:46 <adhawkins> Ok, so I guess 'someone' needs to come up with a plan for how these sorts of packages are going to be handled moving forward. This way does seem to work Ok.
2021-12-24 17:47:21 <adhawkins> Thanks a lot for the assistance ikke. Appreciate it. Enjoy the holidays if you celebrate them.
2021-12-24 17:52:43 <ikke> adhawkins: you're welcome
2021-12-24 18:38:01 <mps> adhawkins: I'll take burden from ikke to celebrate holidays :)
2021-12-24 18:59:39 <ikke> hmm, busybox.net is down
2021-12-24 19:08:28 <Ariadne> hmm
2021-12-24 19:08:32 <Ariadne> build-edge-aarch64 seems stuck
2021-12-24 19:11:10 <ikke> libreoffice
2021-12-24 19:19:55 <Ariadne> can you check that aarch64 builder is actually building
2021-12-24 19:20:04 <Ariadne> because when i tried to build the kernel locally
2021-12-24 19:20:09 <Ariadne> it wanted me to say yes/no to some things
2021-12-24 19:20:53 <ikke> ok
2021-12-24 19:21:31 <ikke> At least now it's building
2021-12-24 19:21:36 <Ariadne> sweet
2021-12-24 19:22:24 <ikke> tailing the buildlog
2021-12-24 19:55:16 <ikke> Ariadne: it finished
2021-12-24 20:02:37 <Hello71> does #13352 even remotely make sense to anyone
2021-12-24 20:03:40 <ikke> not really
2021-12-24 20:13:54 <Ariadne> err
2021-12-24 20:14:02 <Ariadne> is the date on build-edge-aarch64 correct?
2021-12-24 20:14:19 <Ariadne> Linux terrace 5.15.11-1-lts #2-Alpine SMP Wed, 22 Dec 2021 03:16:06 +0000 aarch64 Linux
2021-12-24 20:17:11 <ikke> Fri Dec 24 20:17:04 UTC 2021
2021-12-24 20:17:27 <ikke> sounds correct to me
2021-12-24 21:01:59 <psykose> Hello71: lmao i was thinking the same
2021-12-24 21:02:30 <psykose> is this person running apache in windows 95? brave
2021-12-24 21:09:53 <psykose> adhawkins: pyproject2setuppy also works, you just have to invoke it correctly, e.g. https://img.ayaya.dev/rd7KRfFIi4e3
2021-12-24 21:10:02 <psykose> but i think in the future only pip will be left, by how it's going
2021-12-24 23:17:24 <PJ[m]> Could be just old Windows theme
2021-12-25 10:45:35 <ikke> Anything against using this approach for python packages without setup.py: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28808/diffs
2021-12-25 10:46:16 <ikke> using pip install --no-deps in package()?
2021-12-25 11:11:53 <psykose> if it works it works
2021-12-25 11:12:09 <psykose> looks the same as the pyproject2setuppy overall
2021-12-25 11:12:15 <psykose> i assume the check() works anyway
2021-12-25 11:19:39 <ikke> My only 'objection' would be that it builds the wheel then as well (in fakeroot)
2021-12-25 11:20:38 <psykose> i think it builds it compressed as well or something
2021-12-25 11:23:15 <ikke> (fyi, I suggested that as a potential approach, just wanted to discuss it to see it's acceptable)
2021-12-25 11:32:32 <nmeum> speaking of python: there still seem to be a few packages which haven't been rebuild against 3.10 yet https://pkgs.alpinelinux.org/contents?path=%2Fusr%2Flib%2Fpython3.9%2F%2A&page=1&file=%2A&arch=x86_64&branch=edge
2021-12-25 12:31:34 <psykose> a lot of these are crazy out of date
2021-12-25 12:31:37 <psykose> i guess i will bump what i can
2021-12-25 12:31:57 <psykose> some are deprecated/source gone/not supported in 3.10/no updates for a year
2021-12-25 12:35:26 <ikke> nmeum: I rebuilt most in testing without build failures, the rest I didn't get to yet
2021-12-25 12:36:16 <psykose> is there a pypi pretty format that doesn't have the whole hash in it?
2021-12-25 12:36:34 <ikke> https://tpaste.us/aZKZ
2021-12-25 12:36:50 <nmeum> ikke: it's not just testing though there is also some stuff in main/community which still has /usr/lib/python3.9
2021-12-25 12:37:02 <ikke> yes
2021-12-25 12:37:05 <psykose> gnuradio/gr-osmos has an mr in !28666
2021-12-25 12:38:00 <ikke> psykose: https://files.pythonhosted.org/packages/source/<first-letter>/<project>/<project>-<version>.tar.gz
2021-12-25 12:38:08 <psykose> thanks!
2021-12-25 12:39:11 <ikke> nmeum: these are all packages: https://tpaste.us/qP8a
2021-12-25 12:40:33 <nmeum> that list seems to be missing some packages, for example community/bcc which has a py3-bcc subpackage
2021-12-25 12:40:46 <ikke> I grouped by origin
2021-12-25 12:41:27 <nmeum> but bcc (the origin) is not include in your list or am I missing something?
2021-12-25 12:41:47 <ikke> Or rather, what I did is I selected only origin packages (name=origin)
2021-12-25 12:41:51 <psykose> we need a better way of doing this that doesn't involve jumping around random missed packages for 2 weeks
2021-12-25 12:42:19 <psykose> even llvm/clang was missed until yesterday
2021-12-25 12:43:57 <ikke> nmeum: https://tpaste.us/NMeB
2021-12-25 12:45:14 <nmeum> that looks better
2021-12-25 12:45:41 <ikke> I excluded subpackages first, now I just grouped by origin
2021-12-25 12:46:36 <ikke> https://tpaste.us/xnND this is with origin name
2021-12-25 12:49:52 <ikke> https://tpaste.us/ypxg with repo
2021-12-25 13:13:44 <ikke> libreoffice gets stuck on aarch64 
2021-12-25 13:14:06 <ikke> https://tpaste.us/YERw 
2021-12-25 13:14:25 <psykose> it was stuck for 6 hours on ci too
2021-12-25 13:17:06 <ikke> Did it timeout or continue after 6 hours?
2021-12-25 13:21:56 <psykose> timeout
2021-12-25 13:22:12 <psykose> on the builders i think it's been there for days now
2021-12-25 13:22:24 <psykose> unless i have severely lost track of time
2021-12-25 13:22:36 <ikke> I've killed it 2 or 3 times already
2021-12-25 13:22:42 <psykose> aye
2021-12-25 13:22:57 <psykose> can you toggle it back to clang and see if it unstucks itself
2021-12-25 13:23:06 <psykose> ci alone should be fine, since it was stuck on that too, for a test
2021-12-25 14:50:23 <Nulo> Any reason 3.15 doesn't have foot 1.10.3 (as opposed to 1.10.1)? Should I send a patch?
2021-12-25 14:51:33 <ikke> It's up to the maintainer to make sure packages in stable releases are updated as well
2021-12-25 14:52:58 <Nulo> amk, come thru
2021-12-25 14:59:16 <Nulo> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28849 Is this fine? I cherrypicked commits from master
2021-12-25 15:00:49 <mps> do we backport packages to stable without reason (bug or secfix)
2021-12-25 15:01:10 <mps> ikke: ^
2021-12-25 15:03:27 <ikke> Mostly up to the maintainer. We don't refuse updates just because no one reported a bug (barring our general stable release policies)
2021-12-25 15:04:13 <mps> hmm, I disagree with 'policy'
2021-12-25 15:04:19 <Nulo> There is a reason, I'm stumbling upon a bug which has been fixed according to upstream (crashes)
2021-12-25 15:04:22 <mps> with this*
2021-12-25 15:04:57 <mps> Nulo: then you should create issue first and assign it to maintainer
2021-12-25 15:05:23 <ikke> mps: burocracy
2021-12-25 15:05:35 <mps> ikke: or chaos ;p
2021-12-25 15:06:00 <Nulo> Yeah I'm a bit confused as of to why I would need to do that. Maintainer already made those changes on edge, I'm just reapplying in 3.15
2021-12-25 15:07:00 <psykose> almost done going through the whole list of py3.10 stuff
2021-12-25 15:07:12 <mps> Nulo: I told above, backport to stable only if bug or security fixed, and in exceptional cases something really is needed
2021-12-25 15:07:34 <ikke> How about fixing bugs before users run into them?
2021-12-25 15:07:35 <psykose> those foot releases fixed some bugs
2021-12-25 15:08:01 <Nulo> I just said, it fixed some issues that I'm stumbling upon. Check the CHANGELOG: https://codeberg.org/dnkl/foot/src/branch/master/CHANGELOG.md#1-10-3
2021-12-25 15:08:15 <mps> that is not problem, maintainer should be first informed
2021-12-25 15:10:04 <Nulo> They are automatically informed by algitbot; https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28849 has been assigned to the maintainer
2021-12-25 15:10:21 <mps> ikke: 'fixing bugs before users run into them?' are you dreaming :)
2021-12-25 15:13:14 <ikke> No, but upstream apparently already got bugreports and made new releases fixing them
2021-12-25 15:13:31 <ikke> Why should we by policy wait for users to report these bugs to us before we fix them?
2021-12-25 15:14:20 <omni> I don't get it either
2021-12-25 15:14:26 <mps> imo maintainer should be informed
2021-12-25 15:14:33 <ikke> Sure
2021-12-25 15:14:45 <ikke> but that does not necessarily have to happen by a separate issue
2021-12-25 15:15:34 <ikke> like Nulo said, maintainers already get notified when an MR is opened for their package
2021-12-25 15:15:44 <mps> well, I create MR and maintainer is auto assigned but s/he is offline for some time and you blindly merge it
2021-12-25 15:16:03 <omni> not blindly, I don't think
2021-12-25 15:16:16 <omni> a lot of packages are updated without involvment of the maintainer and if it wouldn't be like that many packages would be very outdated
2021-12-25 15:16:18 <mps> i see this as potential problem
2021-12-25 15:16:45 <mps> omni: we are talking about stable not the edge
2021-12-25 15:17:05 <omni> ok
2021-12-25 15:18:11 <Nulo> Would this be a problem then? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27732
2021-12-25 15:18:28 <Nulo> (Actually a question, I'm curious)
2021-12-25 15:20:25 <mps> Nulo: I don't know what ncopa and jirutka talked 'behind the scene' (if they did) to say is this ok or not
2021-12-25 15:23:55 <ikke> I don't think there was any communication
2021-12-25 15:24:16 <ikke> But we typically fast-track security upgrades
2021-12-25 15:27:09 <psykose> ikke: !28852 as much as i could get i guess
2021-12-25 15:27:52 <psykose> most of the non-rebuildable ones are very.. not maintained anymore, or so it seems
2021-12-25 15:33:51 <ikke> Yes, a lot is unmaintained in testing
2021-12-25 15:34:17 <psykose> i mean more so upstream, but yeah
2021-12-25 15:34:41 <ikke> oh, yeah, that as well :)
2021-12-25 15:35:06 <psykose> think i should put the 3 llvm bumps in a separate mr so we can actually watch the ci
2021-12-25 15:35:12 <ikke> yes
2021-12-25 15:35:15 <psykose> otherwise this will take 3 hours on ppc
2021-12-25 15:37:41 <psykose> there
2021-12-25 15:56:00 <ikke> hmm, py3-build seems interesting
2021-12-25 16:02:15 <ikke> yay for packages that require themselves to build (flit)
2021-12-25 16:02:46 <psykose> how does something fail to include <libportal/portal-gtk3.h> when it's just in the standard include path
2021-12-25 16:04:35 <psykose> oh
2021-12-25 16:04:36 <psykose> i see
2021-12-25 16:05:08 <ikke> Enlighten us
2021-12-25 16:07:47 <psykose> it's just an error you get because it fails the includes down the chain
2021-12-25 16:07:57 <psykose> and looks like a circular header thing, considering it fails no matter what the include is
2021-12-25 16:11:30 <psykose> ah, no
2021-12-25 17:00:01 <Nulo> telegram-desktop 3.3.1 tries to build with clang++ even though CXX=g++. Yay.
2021-12-25 17:02:25 <psykose> that's fine
2021-12-25 17:02:40 <psykose> if upstream prefers clang then you might as well use it
2021-12-25 17:04:51 <Nulo> Well, nothing upstream appears to say they require clang..
2021-12-25 17:05:11 <Nulo> > Tell CMake where to find the compiler by setting either the environment variable "CC" 
2021-12-25 17:05:21 <Nulo> I already did bro 😭
2021-12-25 17:06:55 <psykose> the external dispatch project forces it
2021-12-25 17:08:19 <Nulo> Yes, that's it..
2021-12-25 17:09:03 <psykose> classic cmake
2021-12-25 17:10:43 <Nulo> Honestly I don't know what to do. Report to upstream or add clang to makedepends?
2021-12-25 17:12:19 <psykose> you can patch those 5 lines, or use clang
2021-12-25 17:13:29 <orbea> Nulo: just guessing, but does setting CMAKE_CXX_COMPILER:FILEPATH or CMAKE_C_COMPILER:FILEPATH as cmake arguments work?
2021-12-25 17:13:58 <Nulo> orbea, haven't tried but it seems that it's not passing env variables at least
2021-12-25 17:14:04 <Nulo> I'll patch for now
2021-12-25 17:15:33 <psykose> you generally can't override anything in cmake like that if the project does not let you
2021-12-25 17:16:01 <psykose> in this case it calls a subprocess cmake with -DCMAKE_C_COMPILER=clang itself, not much else you can do i don't think
2021-12-25 17:18:42 <orbea> lol...that is ugh
2021-12-25 17:19:00 <orbea> i guess you could sed the correct compiler into place
2021-12-25 17:29:49 <psykose> writing a patch takes 2 minutes :p
2021-12-25 18:18:44 <Nulo> It uses clang specific options \o/
2021-12-25 18:20:17 <Nulo> error: unknown type name '__BEGIN_DECLS'
2021-12-25 18:22:12 <skarnet> sounds like glibc headers have been included somehow
2021-12-25 18:23:20 <psykose> that does not look clang related
2021-12-25 18:25:29 <Nulo> Yes, I'm just building with clang now
2021-12-25 18:25:34 <Nulo> So it depends on glibc? Great
2021-12-25 18:25:55 <Ariadne> __BEGIN_DECLS is a magic macro on glibc which wraps an extern "C" {} block
2021-12-25 18:26:05 <psykose> you can define it yourself in 5 seconds
2021-12-25 18:26:17 <Ariadne> yes, something like
2021-12-25 18:26:22 <psykose> because it has a corresponding __END_DECLS
2021-12-25 18:26:24 <Ariadne> #ifndef __cplusplus
2021-12-25 18:26:26 <psykose> yep
2021-12-25 18:26:33 <Ariadne> #define __BEGIN_DECLS
2021-12-25 18:26:33 <Nulo> Awesome, I hate it here
2021-12-25 18:26:36 <Ariadne> #define __END_DECLS
2021-12-25 18:26:39 <Ariadne> #else
2021-12-25 18:26:40 <Nulo> It uses other things, that's just one error
2021-12-25 18:26:42 <Ariadne> ...
2021-12-25 18:26:43 <Ariadne> #endif
2021-12-25 18:26:49 <psykose> nice spam ariadne!
2021-12-25 18:27:06 <Ariadne> youre welcome
2021-12-25 18:27:08 <psykose> :3
2021-12-25 18:27:22 <Nulo> https://0x0.st/orA0.txt
2021-12-25 18:27:41 <Ariadne> oh
2021-12-25 18:27:43 <Ariadne> telegram
2021-12-25 18:27:45 <Ariadne> don't bother
2021-12-25 18:27:50 <Nulo> C macro spam <3
2021-12-25 18:27:57 <Nulo> Ariadne, I.. bother sadly
2021-12-25 18:28:13 <Ariadne> telegram don't want their software packaged
2021-12-25 18:28:21 <Ariadne> they keep making moves that are hostile to packagers
2021-12-25 18:28:21 <Nulo> Yes I noticed from previous experiences https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27025
2021-12-25 18:28:30 <psykose> libdispatch is a trip
2021-12-25 18:29:48 <psykose> as long as you have fun with packaging it :p
2021-12-25 18:30:11 <Nulo> I am not having fun tbh
2021-12-25 18:30:24 <psykose> i've spent 20 hours not having fun in aports
2021-12-25 18:30:26 <psykose> or maybe it was fun
2021-12-25 18:30:27 <Nulo> My initial upgrade was because it crashed when I tried to do a voice call with my friends
2021-12-25 18:30:36 <Nulo> I had to use the Flatpak
2021-12-25 18:31:10 <psykose> personally i would just use the flatpak
2021-12-25 18:32:47 <Nulo> Ariadne, mind if I PM for an unrelated reason?
2021-12-25 18:33:06 <Ariadne> i guess
2021-12-25 18:33:44 <psykose> 👀
2021-12-25 18:38:49 <Nulo> omg it's a Swift thing https://github.com/apple/swift-corelibs-libdispatch what the hell
2021-12-25 18:38:53 <Nulo> I hate this
2021-12-25 18:38:59 <Nulo> Has anything with this been packaged before?
2021-12-25 18:40:34 <psykose> there is probably at least one thing with it as a vendored dep
2021-12-25 18:41:23 <psykose> hmmm
2021-12-25 18:41:43 <psykose> the arch pkgbuild isn't doing anything special for it
2021-12-25 18:42:42 <psykose> neither is void
2021-12-25 18:42:46 <psykose> aside from yoinking the api key
2021-12-25 18:43:03 <Nulo> :)
2021-12-25 18:43:20 <Nulo> Fedora and OpenSUSE use it for deadbeef/deadbeef-plugins
2021-12-25 18:43:51 <psykose> even gentoo isn't doing anything special here
2021-12-25 18:43:59 <Nulo> https://github.com/DeaDBeeF-Player/deadbeef/search?q=dispatch
2021-12-25 18:44:18 <Nulo> To be clear, I think this got introduced on 3.3.1 and Void has 3.3.0
2021-12-25 18:44:44 <psykose> ah
2021-12-25 18:44:46 <psykose> makes sense
2021-12-25 18:44:50 <Nulo> Yep https://github.com/telegramdesktop/tdesktop/commit/d89597bf64859eaf1bdad57a86c40b810a4923c1
2021-12-25 18:44:52 <psykose> silly me to think the numbers mean anything
2021-12-25 18:45:22 <Nulo> Lol they even patch it in their own build script to some degree https://github.com/telegramdesktop/tdesktop/commit/d89597bf64859eaf1bdad57a86c40b810a4923c1#diff-6459e7429c8f96e46a7b23b51bf21be6b35242b1cfbe3da4d1c1dc1a898d08b9
2021-12-25 18:46:06 <Nulo> It's not like the CI that uses that Dockerfile has passed for the past 20 commits anyway so I can't see if it works for them
2021-12-25 18:46:15 <psykose> unistd.h is a libc header
2021-12-25 18:46:48 <Nulo> Ah yeah, no clue then
2021-12-25 18:46:56 <Nulo> Also: 3.3.1 is technically a pre-release. I wish I was kidding. I just want to be prepared for the next release
2021-12-25 18:47:08 <psykose> you should add 3.3.0 in the meantime
2021-12-25 18:47:53 <Nulo> I tried packaging it before and it failed with who-knows-what-error so I just didn't bother
2021-12-25 18:49:32 <Nulo> https://www.freshports.org/devel/libdispatch/ Even FreeBSD ports gave up
2021-12-25 18:51:19 <Nulo> I'll just patch this out, it replaces "slow QThreadPool"
2021-12-25 18:55:16 <psykose> in the next few commits they will change the code that uses the pools so you can't go back :p
2021-12-25 18:56:43 <Nulo> If they do I Will Cry
2021-12-25 18:56:50 <psykose> aww
2021-12-25 18:56:51 <psykose> there there
2021-12-25 18:56:58 <psykose> hug
2021-12-25 18:57:09 <Nulo> u.u thanks
2021-12-25 18:57:21 <Nulo> #alpine-devel turned roleplay
2021-12-25 18:58:33 <psykose> not much else happening during the holidays
2021-12-25 18:59:38 <Nulo> Except weirdos trying to package Telegram?
2021-12-25 18:59:58 <psykose> don't seem very weird to me
2021-12-25 19:00:01 <Nulo> A friend suggested gcompat.. would that work?
2021-12-25 19:01:10 <Nulo> gcompat is only for already built, dynamically linked binaries, correct?
2021-12-25 19:01:13 <psykose> gcompat is just for symbols
2021-12-25 19:06:13 <Nulo> sadge
2021-12-25 19:08:22 <psykose> sadge
2021-12-25 19:14:51 <Nulo> Nah I give up
2021-12-25 19:15:00 <Nulo> I patched it out and it still is trying to compile it
2021-12-25 19:16:43 <psykose> you probably did it wrong
2021-12-25 19:16:52 <psykose> skarnet2 electric boogaloo
2021-12-25 19:17:29 <Nulo> psykose, thank you you're right
2021-12-25 19:17:38 <psykose> hehe
2021-12-25 19:17:41 <psykose> cute
2021-12-25 19:21:11 <psykose> well, patching it out is 3 lines, except for the part everything fails because it wants it to link with
2021-12-25 19:21:47 <Nulo> I knooow
2021-12-25 19:23:07 <Nulo> Two patches + rm -rf inside APKBUILD down, let's see if it works now
2021-12-25 19:52:31 <orbea> why not just sed?
2021-12-25 19:53:32 <Nulo> orbea, why would I sed
2021-12-25 19:53:54 <Nulo> You can't (read: you can but shall not) sed out entire commits
2021-12-25 19:55:04 <orbea> hmm, I was thinking this was just changing a compiler string?
2021-12-25 19:55:20 <orbea> but i read up and seems I missed some context...
2021-12-25 19:58:28 <orbea> Nulo: fwiw I gave up on libdispatch too, no replies to even this... https://github.com/apple/swift-corelibs-libdispatch/pull/552
2021-12-25 21:19:41 <Nulo> orbea, good to know, thanks
2021-12-25 21:20:02 <Nulo> I got it to work by patching out libdispatch for now
2021-12-25 21:24:57 <Nulo> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28864
2021-12-25 22:37:59 <ericonr> lmao ofc they use -fblocks
2021-12-25 22:39:45 <orbea> that was where I realized how much work it was...and given upstream didn't care Im glad I didn't go farther. :P
2021-12-25 22:44:40 <mps> anyone tried to report problem to upstream
2021-12-25 22:46:49 <orbea> i made a PR starting work on the problem as linked above, got nothing
2021-12-25 22:47:46 <orbea> not that I expected better from an apple repo
2021-12-25 22:49:04 <Nulo> > Apple designed blocks with the explicit goal of making it easier to write programs for the Grand Central Dispatch threading architecture
2021-12-25 22:49:08 <Nulo> https://en.wikipedia.org/wiki/Blocks_(C_language_extension)
2021-12-25 22:49:09 <alpine-meetbot> [WIKIPEDIA] Blocks (C language extension) | "Blocks are a non-standard extension added by Apple Inc. to Clang's implementations of the C, C++, and Objective-C programming languages that uses a lambda expression-like syntax to create closures within these languages. Blocks are supported for programs developed for Mac OS X 10.6+ and iOS 4.0+, although..."
2021-12-25 22:50:36 <mps> that is why I prefer gcc
2021-12-25 22:50:56 <Nulo> mps, why?
2021-12-25 22:51:59 <Nulo> Ah, -fblocks didn't get to upstream gcc
2021-12-25 22:52:01 <mps> that is just 'gut feeling' (and don't like anything made or emerged from companies and comercial entities)
2021-12-25 22:52:48 <mps> else I would use macos or windows
2021-12-25 22:55:22 <Nulo>  #alpine-offtopic
2021-12-25 22:55:47 <mps> Nulo: really? :)
2021-12-25 22:59:36 <orbea> mps: agreed, but its better to have more than one viable compiler
2021-12-25 23:00:06 <mps> orbea: yes and there is tcc :)
2021-12-25 23:00:38 <mps> orbea: jk ofc
2021-12-25 23:00:41 <orbea> :P
2021-12-25 23:22:03 <Nulo> I don't even know at this point https://gitlab.alpinelinux.org/Nulo/aports/-/jobs/574499#L4756
2021-12-25 23:28:07 <mps> Nulo: why you added pipewire to telegram
2021-12-25 23:28:39 <Nulo> mps, because it seems it requires it to build? But it still doesn't work?
2021-12-25 23:28:51 <mps> (less deps less security risks)
2021-12-25 23:29:18 <mps> ah, ok if it is needed by upstream
2021-12-25 23:30:54 <mps> I will try tomorrow to build it on aarch64 to try if I could help you
2021-12-25 23:31:42 <mps> now, good night
2021-12-25 23:34:30 <Nulo> mps, yeah I don't believe Telegram takes security seriously to any degree.
2021-12-25 23:34:38 <Nulo> I've been scammed and I want my money back
2021-12-25 23:34:57 <PJ[m]> they never did
2021-12-25 23:36:41 <mps> PJ[m]: gui and security? this doesn't go
2021-12-25 23:37:00 <Nulo> PJ[m], I never said they did :P
2021-12-26 01:04:25 <ericonr> mps: GCC has the even worse inline functions though, it's not really an improvement 
2021-12-26 01:22:41 <Hello71> nested functions?
2021-12-26 03:40:02 <ericonr> Hello71: defining a function inside another function 
2021-12-26 04:00:28 <thiagowfx> when sending a v2 patch via git send-email for a new aport, should I add --in-reply-to= to nest it in the same thread, or should that flag be omitted?
2021-12-26 08:36:16 <ikke> thiagowfx: doesn't really matter. Most people don't do it
2021-12-26 10:28:22 <nmeum> gitlab is getting ipv6? \o/
2021-12-26 10:28:58 <nmeum> late christmas present I suppose (:
2021-12-26 10:29:14 <ikke> Yeah, trying to set it up
2021-12-26 10:29:26 <ikke> The docker part
2021-12-26 10:40:49 <mps> ericonr: rarely used features doesn't counts :)
2021-12-26 11:45:05 <ikke> I need to reboot the gitlab server
2021-12-26 12:05:10 <ikke> Ok, that looks better
2021-12-26 12:45:08 <jvoisin> skarnet: https://gavinhoward.com/2021/12/is-it-even-worth-working-on-foss-anymore/ s6 mentionned :)
2021-12-26 13:46:23 <psykose> Nulo: you need pipewire-dev, adding -libs is always generally a mistake to makedepends
2021-12-26 14:04:28 <nmeum> mps: do I recall correctly that you are using alpine on arm chromebooks? if so: which ones are you using?
2021-12-26 14:04:36 <mps> psykose: right, about two hours ago I tried to build !28864 and had to add pipewire-dev instead of pipewire-libs just to start build
2021-12-26 14:05:11 <mps> but it fails even with this
2021-12-26 14:05:21 <psykose> yes, the package is cursed anyway :p
2021-12-26 14:07:35 <mps> nmeum: I tested on arm32 samsung peach pi (exynos5800 cpu) and on two arm64: acer R13 mediatek mt8173 (code name oak-elm) and on rk3399 samsung one plus (code name gru-kevin)
2021-12-26 14:08:30 <nmeum> thanks (:
2021-12-26 14:08:56 <mps> nmeum: only kernels are specific for these, user space works unchanged as we 'ship' it
2021-12-26 14:09:13 <skarnet> jvoisin: take everything gdh writes with one or two salt shakers
2021-12-26 14:09:22 <mps> some people have kernels for other chromebooks
2021-12-26 14:11:22 <mps> psykose: looks like telegram fails because wrong usage of gtkmm or out gtkmm is outdated (didn't looked deeply)
2021-12-26 14:12:04 <mps> these days I'm 'wasting' time on apple M1 kernel testing and 'fixing'
2021-12-26 14:13:06 <mps> also good news is that the alpine aarch64 works very fine unchanged on apple M1
2021-12-26 14:13:29 <mps> aarch64 userspace I mean
2021-12-26 14:16:16 <mps> psykose: Nulo: example of build error on telegram `/usr/include/glibmm-2.4/glibmm/variant_basictypes.h:340:12: note:   candidate expects 2 arguments, 0 provided`
2021-12-26 14:18:35 <psykose> try glibmm2-dev
2021-12-26 14:18:59 <psykose> 2.68*
2021-12-26 14:19:43 <mps> gtkmm4-dev?
2021-12-26 14:40:08 <psykose> ah
2021-12-26 14:40:23 <psykose> upgrading glibmm from 2.66.0 to 2.66.2 seems to make it get past that part
2021-12-26 15:00:19 <psykose> 900/1000 on the build
2021-12-26 15:00:21 <psykose> maybe i fixed it
2021-12-26 15:01:59 <psykose> where's Nulo when you need em
2021-12-26 15:07:02 <mps> psykose: you are right, build on aarch64 pass with glibmm2.66.2
2021-12-26 15:07:08 <psykose> yes
2021-12-26 15:07:21 <psykose> glibmm2.66.2 also fails to build without rebuilding doxygen with libclang
2021-12-26 15:07:28 <psykose> for documentation
2021-12-26 15:07:29 <psykose> :p
2021-12-26 15:07:39 <mps> it passed on my run
2021-12-26 15:07:49 <psykose> hm
2021-12-26 15:08:07 <mps> I even didn't looked at build log of it
2021-12-26 15:11:21 <mps> psykose: Nulo: and it works on aarch64
2021-12-26 15:11:27 <psykose> awesome
2021-12-26 15:11:46 <mps> thank you both for work on fixing it
2021-12-26 15:12:56 <psykose> ah no, seems the docs failing to build was unrelated.. it builds fine in rootbld
2021-12-26 15:13:07 <psykose> classic environment issues
2021-12-26 15:13:30 <mps> psykose: yes, I usually build simple pkgs with rootbld
2021-12-26 15:14:00 <mps> psykose: will you update MR with fixes
2021-12-26 15:14:10 <psykose> i don't have the permission to edit nulo'
2021-12-26 15:14:27 <psykose> but i will go open glibmm mr instead i think
2021-12-26 15:14:47 <mps> hmm, then Nulo have to do that, I don't like to update others MRs
2021-12-26 15:15:22 <mps> and now, lets go for coffee
2021-12-26 15:15:37 <psykose> yes, nulo will deal with the rest
2021-12-26 15:37:51 <adhawkins> psykose: Thanks for that. Would be good if we can come up with an agreed 'standard' for this kind of thing moving forward.
2021-12-26 15:38:23 <adhawkins> psykose: Regarding installing python packages with no setup.py moving forward.
2021-12-26 15:38:25 <ikke> adhawkins: did you see the MR I made for flit?
2021-12-26 15:38:25 <psykose> yes
2021-12-26 15:38:40 <adhawkins> No. Got a pointer to it ikke?
2021-12-26 15:39:07 <ikke> !28865 
2021-12-26 15:41:24 <adhawkins> Ah ok. So that could be used to install instead of pip?
2021-12-26 15:42:03 <ikke> no, it's in addition
2021-12-26 15:42:17 <ikke> py3-build + flit to build a wheel, then pip install to install the wheel
2021-12-26 15:42:47 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28865/diffs#diff-content-b23a36b4d1ef447ed923be9d7173c4eaa4936a87
2021-12-26 15:44:01 <adhawkins> Oh I see. So why not just use pip?
2021-12-26 15:44:52 <ikke> to not do any actual building in the fakeroot
2021-12-26 15:45:14 <ikke> (package / rootpkg)
2021-12-26 15:45:25 <omni> is it only the gitlab web interface that now also listen to IPv6?
2021-12-26 15:45:46 <adhawkins> ikke: Ok. Is that considered better?
2021-12-26 15:45:49 <ikke> adhawkins: yes
2021-12-26 15:45:49 <omni> I added 'AddressFamily inet' to my ~/.ssh/config
2021-12-26 15:46:06 <ikke> omni: hmm, good question, yes, I've only added it to traefik
2021-12-26 15:46:08 <adhawkins> ikke: Ok. Will bear that in mind in future then. Will look out for that MR going through.
2021-12-26 15:57:39 <Nulo> psykose, mps, thank you so much! I was awake but didn't get to IRC yet
2021-12-26 15:58:18 <psykose> Nulo: i made some modifications to both builds as well https://img.ayaya.dev/U5xBXA0seQrQ https://img.ayaya.dev/IDxVuFjDwNT5
2021-12-26 15:58:25 <psykose> i don't know why rlottie was removed tbh
2021-12-26 16:00:28 <psykose> or why there is a small sizes patch that shrinks something by like 4%
2021-12-26 16:00:57 <Nulo> Yeah there's many changes, why's that?
2021-12-26 16:01:01 <Nulo> Like, where does it come from
2021-12-26 16:01:15 <psykose> whadya mean? those are already in tree
2021-12-26 16:03:19 <Nulo> In which tree? That's just on your diff
2021-12-26 16:03:44 <psykose> the aports tree has those patches in it
2021-12-26 16:03:57 <psykose> the diff removes them
2021-12-26 16:04:23 <ikke> adhawkins: Could you add your +1 to that MR if you agree?
2021-12-26 16:04:30 <adhawkins> Will do.
2021-12-26 16:05:04 <adhawkins> I clicked 'approve', is that what you meant?
2021-12-26 16:05:31 <psykose> Nulo: what i mean is i cannot find any reasoning anywhere for why there was a patch to shrink some element by 5% in the first place, or why some dependency was patched out
2021-12-26 16:07:30 <Nulo> Ah okay, I get it
2021-12-26 16:07:53 <psykose> i also combined your patches and made it smaller
2021-12-26 16:08:07 <psykose> and the rm -rf's which don't do anything, etc
2021-12-26 16:08:42 <Nulo> No, the rlottie patch makes it use the packaged one AFAIK
2021-12-26 16:08:49 <psykose> there is no system rlottie
2021-12-26 16:08:58 <Nulo> Yeah that's what I'm trying to figure out
2021-12-26 16:09:00 <psykose> it's also using roughly 10 other packaged dependencies
2021-12-26 16:09:25 <psykose> between it and tg_owt
2021-12-26 16:09:42 <Nulo> `[113/1049] Building CXX object Telegram/CMakeFiles/lib_stripe.dir/SourceFiles/payments/stripe/stripe_api_client.cpp.o`
2021-12-26 16:09:46 <psykose> let me see if void history is more useful
2021-12-26 16:09:56 <Nulo> Why does an instant messaging thing need a Stripe client 
2021-12-26 16:10:05 <Nulo> Void kinda just bundles most dependencies AFAIK
2021-12-26 16:10:05 <psykose> because it has payments
2021-12-26 16:10:30 <psykose> lol
2021-12-26 16:10:32 <psykose> https://github.com/void-linux/void-packages/commit/2176826e6f30c99d95d60851715ff946e80b045c
2021-12-26 16:10:35 <psykose> yes, seems very related
2021-12-26 16:10:36 <psykose> (not)
2021-12-26 16:13:01 <Nulo> `[243/1049] Building CXX object cmake/external/rlottie/CMakeFiles/external_rlottie_bundled.dir/__/__/__/Telegram/ThirdParty/rlottie/src/lottie/lottiemodel.cpp.o`
2021-12-26 16:13:36 <psykose> yeah, what of it
2021-12-26 16:14:09 <psykose> i dare you to grep for thirdparty/third_party in the build output for all the others :p
2021-12-26 16:14:32 <Nulo> :#
2021-12-26 16:15:40 <psykose> anyways, everything builds fine with the upgraded glibmm and the 2 patches, and starts, i suppose you should check if the calls actually work
2021-12-26 16:16:26 <Nulo> I have a few questions..
2021-12-26 16:16:39 <Nulo> The CSS/shrink patch is for pmOS
2021-12-26 16:16:51 <psykose> leave it in then
2021-12-26 16:17:03 <psykose> but it's 5%, unless it does some magic that nobody seems to have cared to document
2021-12-26 16:17:17 <Nulo> CSS is magic
2021-12-26 16:17:22 <psykose> 5% is.. not perceptible on anything
2021-12-26 16:18:02 <psykose> unless there is a phone you can start telegram-desktop on that crashes with 380px but not 360px
2021-12-26 16:18:12 <Nulo> Yes, but I believe that the UI didn't fit or something
2021-12-26 16:18:31 <Nulo> Why did you set -DCMAKE_BUILD_TYPE=MinSizeRel? I remember reading something about =None being common practice
2021-12-26 16:19:05 <psykose> then leave it in, and add a comment at the top that it's to fit in phone ui or somesuch
2021-12-26 16:19:23 <psykose> because None is an awful build type default
2021-12-26 16:19:32 <psykose> and hopefully will eventually be removed from the linter
2021-12-26 16:20:37 <Nulo> 
ACTION doesn't know much about cmake

2021-12-26 16:20:50 <Nulo> Lol ok 
2021-12-26 16:20:51 <Nulo> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28826
2021-12-26 16:20:51 <psykose> you can search the gitlab for cmake_build_type
2021-12-26 16:20:58 <psykose> indeed
2021-12-26 16:21:05 <psykose> everything gets linked to from there
2021-12-26 16:21:14 <psykose> enjoy the few pages of content
2021-12-26 16:22:42 <Nulo> I'll send the MR as None for now and change it whenever !28826 gets merged
2021-12-26 16:22:52 <psykose> it will never get merged
2021-12-26 16:27:34 <ikke> Why do you think so?
2021-12-26 16:29:17 <Hello71> nobody handles these "big" MRs from non-devs. see e.g. !23041. to add insult to injury, the bot implies that it's the submitter's fault that nobody is handling it
2021-12-26 16:29:58 <psykose> the community/ version has 791 commits in it as well :p
2021-12-26 16:30:17 <Hello71> which I have complained about in the past, see !28046. i have been waiting for the stale comment to come complain further
2021-12-26 16:31:26 <ikke> Just that MR would not do anything
2021-12-26 16:31:35 <Hello71> possibly
2021-12-26 16:31:37 <ikke> I have been thinking about it
2021-12-26 16:31:50 <psykose> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/merge_requests/4 this one should be merged as well
2021-12-26 16:31:51 <ikke> I would say that we only use that for MRs with certain labels
2021-12-26 16:50:09 <ikke> psykose: one tip: it helps to limit the changes you do in these mass-update MRs
2021-12-26 16:50:29 <psykose> if you mean to remove the fluff linting fixes, i can remove those, but it's still a huge mr
2021-12-26 16:50:52 <ikke> yes, but it's easier to review if the changes are uniform
2021-12-26 16:51:57 <psykose> and some of them fix the subsequent rebuild, but i guess i can leave those in
2021-12-26 16:53:06 <ikke> Yes, if it's necessary it's necessary
2021-12-26 16:56:15 <psykose> done
2021-12-26 17:38:58 <mps> Nulo: this is APKBUILD with which I built telegram https://tpaste.us/7VPO
2021-12-26 17:39:31 <mps> I had to build glibmm 2.66.2 first, thanks to psykose noticed this
2021-12-26 17:40:02 <psykose> already merged aswell
2021-12-26 17:40:18 <mps> psykose: i see, just noted to Nulo 
2021-12-26 18:26:28 <Nulo> psykose: why did you change where options= was? Any specific reason?
2021-12-26 18:26:35 <psykose> nope
2021-12-26 18:26:55 <psykose> generally i just put it below metadata though
2021-12-26 18:30:06 <Nulo> Would you like to be added as a contributor?
2021-12-26 18:34:52 <psykose> i don't mind either way
2021-12-26 18:35:07 <psykose> i don't bother for anything i edit
2021-12-26 18:35:46 <psykose> i've never even used telegram
2021-12-26 18:55:46 <Nulo> psykose: okay, is Contributor: psykose <alice@ayaya.dev> ok?
2021-12-26 18:56:52 <psykose> it is
2021-12-26 18:57:49 <Nulo> Newbyte: I see you are the maintainer of tg_owt. I'm taking the maintainership of telegram-desktop, do I take tg_owt too?
2021-12-26 18:58:51 <Nulo> What's your disable-dispatch.patch
2021-12-26 18:58:53 <Nulo> ?
2021-12-26 18:59:47 <psykose> it's just yours
2021-12-26 18:59:54 <psykose> but with the unneeded parts removed
2021-12-26 19:00:42 <psykose> oh, i see
2021-12-26 19:01:32 <psykose> https://img.ayaya.dev/eGSTR2pLC9MZ i forgot to add -N first
2021-12-26 19:01:37 <psykose> my mistake :p
2021-12-26 19:02:00 <Nulo> I didn't have the first part :)
2021-12-26 19:02:17 <psykose> you did
2021-12-26 19:02:34 <psykose> in disable-crl
2021-12-26 19:06:23 <Nulo> Ah, that was a literal reverse of their patch. Yours is better
2021-12-26 19:06:29 <Nulo> Still getting this on a rootbld: ninja: file is missing and not created by any action: '/usr/lib/libpipewire-0.3.so'
2021-12-26 19:06:40 <Nulo> pipewire-dev then?
2021-12-26 19:08:11 <psykose> yes, you can just copy all my changes
2021-12-26 19:08:20 <psykose> plain .so is always in dev
2021-12-26 19:08:31 <psykose> -libs is for the ones with a version, i.e. .so.3
2021-12-26 19:08:57 <Nulo> Huh 
2021-12-26 19:09:04 <Nulo> I really need to learn about this stuff
2021-12-26 19:09:41 <psykose> it's also just a symlink to the version
2021-12-26 19:09:58 <skarnet> .so is only needed for build-time linking, so, development. versioned one is used at runtime.
2021-12-26 19:10:04 <psykose> when you build something with -lsomelib it looks for a libsomelib.so
2021-12-26 19:10:20 <psykose> and the symlink resolves to i.e. libsomelib.so.1.2.0, so it links against that version and depends on that after
2021-12-26 19:11:02 <mps> Nulo: I posted above APKBUILD by which I built telegram and test that it works
2021-12-26 19:11:22 <Nulo> mps: yes, I saw, thanks. I'm using that too
2021-12-26 19:11:56 <Nulo> I didn't know .so were needed for linking, that's what weirded me out
2021-12-26 19:12:26 <psykose> or .a for static linking
2021-12-26 19:14:34 <Nulo> I'm trying to clean up the file and add comments to explain things, etc
2021-12-26 19:14:39 <Nulo> Thanks for your help!
2021-12-26 19:38:02 <Nulo> font-iosevka-curly-slab:curly_slab (no such package):
2021-12-26 19:38:46 <psykose> yes, i forgot to edit the depends
2021-12-26 19:38:50 <psykose> and fixed it, when it gets merged
2021-12-26 19:38:54 <psykose> didn't think anyone but me used it
2021-12-26 19:39:20 <psykose> you can manually install the components in the meantime if you want
2021-12-26 19:39:43 <Nulo> Ah, it's fine, I was adding font-iosevka but I just want font-iosevka-base 
2021-12-26 19:39:56 <psykose> yeet
2021-12-26 21:45:01 <mps> psykose: !28892 are these metapackages or subpackages
2021-12-26 21:45:16 <psykose> font-iosevka itself is a meta for its subpackages
2021-12-26 21:45:35 <mps> is it really 'meta'
2021-12-26 21:45:59 <psykose> not sure i understand the question
2021-12-26 21:46:11 <mps> terminology
2021-12-26 21:46:38 <mps> meta means something else
2021-12-26 21:46:43 <psykose> what does it mean then
2021-12-26 21:47:14 <mps> out, outside
2021-12-26 21:47:30 <mps> not real
2021-12-26 21:48:08 <psykose> what do you think font-iosevka is
2021-12-26 21:48:31 <mps> can someone who is native (and understand) english speaker explain difference
2021-12-26 21:48:48 <mps> or better yet native latin speaker :D
2021-12-26 21:48:50 <psykose> it is an empty package that just pulls in the others
2021-12-26 21:48:58 <psykose> it contains nothing
2021-12-26 21:49:04 <mps> virtual then
2021-12-26 21:49:18 <psykose> a virtual is something satisfied by multiple separate packages but that doesn't need all of them
2021-12-26 21:49:29 <psykose> and what does any of this have to do with the fixes in the commit
2021-12-26 21:49:42 <mps> term
2021-12-26 21:51:36 <psykose> i dunno it seems pretty accurate to me https://en.wiktionary.org/wiki/metapackage
2021-12-26 21:52:38 <psykose> this is also the most useless bikeshedding of all time
2021-12-26 21:53:25 <mps> we don't have metapackages, yet
2021-12-26 21:53:48 <psykose> yes we do
2021-12-26 21:54:18 <psykose> main/gnome is another example
2021-12-26 21:54:49 <mps> uh, gnome (which should be removed from alpine)
2021-12-26 21:54:54 <psykose> so is alpine-sdk
2021-12-26 21:55:38 <mps> hmm, maybe even this one
2021-12-26 22:07:38 <Hello71> pls delete alpine-base. software is a scourge on the earth, all computers should be deleted
2021-12-26 22:08:01 <psykose> hard agree bestie
2021-12-26 22:11:35 <mps> and melted in iron melt towers
2021-12-26 22:12:20 <mps> Zend Avesta explains
2021-12-26 22:13:27 <omni> software was a mistake
2021-12-26 22:14:31 <mps> omni: yes, and big one
2021-12-26 23:28:24 <Nulo> river now requires wlroots 0.15, can we upgrade?
2021-12-26 23:30:09 <Hello71> it needs to be slotted because ssway needs 0.14
2021-12-26 23:30:14 <Hello71> s/ss/s/
2021-12-26 23:30:14 <alpine-meetbot> Hello71 meant to say: it needs to be slotted because sway needs 0.14
2021-12-26 23:30:34 <Nulo> slotted?
2021-12-26 23:38:02 <psykose> river only requires 0.15 once river gets upgraded :p
2021-12-26 23:38:14 <psykose> sway will have a release for 0.15 in about a week or two
2021-12-26 23:38:30 <psykose> it is currently -rc1 and i am running it along with 0.15, and it seems to work
2021-12-26 23:38:53 <psykose> there is an mr for 0.15 already- you can see what it depends on
2021-12-26 23:39:15 <psykose> if that can't be met we need to slot it like we do for wlroots 0.12- a separate package of the older version
2021-12-26 23:39:43 <psykose> !28574
2021-12-26 23:49:17 <psykose> Nulo: do you want me to try qt6 as well? :p
2021-12-27 00:08:14 <omni> !28797
2021-12-27 00:08:42 <omni> psykose: your comment unfortunately didn't help someone as copyright ignorant as me much
2021-12-27 00:09:11 <psykose> the licence comments in the linked repository specify -or-later, so you are right
2021-12-27 00:09:44 <psykose> https://github.com/autotools-mirror/libtool/blob/master/libltdl/lt__strl.c#L12 if this is present in the headers it is -or-later
2021-12-27 00:09:47 <omni> yeah, but the first one was LGPL and the other GPL?
2021-12-27 00:09:47 <psykose> the -only versions remove that part
2021-12-27 00:10:12 <psykose> ah, then it's both
2021-12-27 00:10:36 <psykose> GPL-2.0-or-later AND LGPL-2.0-or-later
2021-12-27 00:10:52 <omni> so "LGPL-2.0-or-later AND GPL-2.0-or-later" or "OR"?
2021-12-27 00:10:59 <omni> ah
2021-12-27 00:12:15 <psykose> to be honest idk when you would use or/with/and, but if there's multiple between files i would just assume and
2021-12-27 00:27:10 <omni> yeah
2021-12-27 00:29:00 <omni> I added a comment and hope whoever merge it will have a good idea about the situation
2021-12-27 00:31:07 <psykose> :p
2021-12-27 00:31:29 <psykose> Nulo: i have a working qt6 build if you want, though it's a bit cursed
2021-12-27 00:56:32 <omni> psykose: no, but thank you
2021-12-27 00:56:52 <psykose> no to what
2021-12-27 01:03:20 <Nulo> psykose: I love me some cursed Telegram, bring it on
2021-12-27 01:07:02 <omni> psykose: didn't want you to think I didn't value the input
2021-12-27 01:09:41 <psykose> omni: i don't understand, what input
2021-12-27 01:09:44 <psykose> Nulo: https://img.ayaya.dev/kwuA0Gur4j4x
2021-12-27 01:10:45 <psykose> it uses some third party patches from which it uses the kwayland one, to patch its bundled copy of kwayland to force it to support qt6, then builds that as well
2021-12-27 01:11:00 <psykose> this is only for the qt6 build
2021-12-27 01:13:41 <Nulo> psykose: oh no oh god, so it uses bundled kwayland? I thought it used the packaged one?
2021-12-27 01:14:28 <psykose> pretty sure that's only for the qt6 build
2021-12-27 01:14:39 <psykose> it doesn't build kwayland normally
2021-12-27 01:14:54 <psykose> you see it as separate build output if you apply that patch to your current mr worktree
2021-12-27 01:23:45 <Nulo> Okay, I think we should wait that out then. It's late for me, good night!
2021-12-27 01:24:50 <psykose> sleep well dear
2021-12-27 10:15:54 <mps> Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default
2021-12-27 10:16:14 <mps> how we got this on less in 3.15 
2021-12-27 10:19:35 <mps> <grumpy mode> from small and simple alpine becoming complicated and bad</grumpy mode>
2021-12-27 10:19:44 <psykose> for some reason i can't reproduce that
2021-12-27 10:21:44 <mps> I cannot find anything related to less pkg which introduced this, probably had to look deeply (I had a hope someone knows what causes this)
2021-12-27 10:40:54 <ncopa> good morning
2021-12-27 11:03:09 <psykose> mornin
2021-12-27 11:18:46 <mps> good evening ;)
2021-12-27 11:27:39 <pabloyoyoista_> ncopa: any luck you can have a look at !28330? I understand I am just a regular dev and maybe went a bit too far upgrading a package in main. But the new release includes a patch that fixes a crash with muslc that cannot be otherwise avoided
2021-12-27 11:28:29 <pabloyoyoista_> If that is likely to take long, is cherry-picking the patch to current release more likely to be accepted?
2021-12-27 11:28:41 <mps> pabloyoyoista_: I think it could be merged
2021-12-27 11:37:05 <pabloyoyoista_> It'd be great if that's possible! But honestly I just want the bug fixed once that it's fixed upstream. I don't mind the process :)
2021-12-27 12:05:17 <mps> omni: !28902 isn't license changed to something which prohibit distribution
2021-12-27 12:05:56 <mps> long ago I looked at it to upgrade but didn't because of license change
2021-12-27 12:07:46 <jvoisin> https://imapsync.lamiral.info/LICENSE the license looks like public domain-ish
2021-12-27 12:13:48 <mps> https://github.com/imapsync/imapsync
2021-12-27 12:14:05 <mps> hm, yes. looks like I missed this when I looked at it
2021-12-27 12:50:58 <minimal> can someone please merge !28733
2021-12-27 17:01:46 <omni> psykose: your input was your replies to my concerns with regards to what the license should be stated as, I said that I wrote a comment for whoever would merge it to make sure it was correct, you wrote ":p" which promped me to thank you for your comments on the matter, your input
2021-12-27 17:11:38 <omni> mps: it seem to be this still? https://github.com/imapsync/imapsync/blob/master/LICENSE
2021-12-27 17:12:05 <omni> and now I read up
2021-12-27 18:45:44 <Newbyte> Nulo: haven't been on Matrix for a while so I didn't see your message until now, but yes it's fine if you want to take over maintainership of tg_owt
2021-12-27 18:46:28 <donoban> and telegram-desktop too :)
2021-12-28 09:28:40 <omni> there's a new busybox release
2021-12-28 09:30:16 <dhruvin> I am trying to build a package for aarch64 on x86_64. I am using `scripts/bootstrap.sh aarch64` to get the toolchain working. It requires openssl1.1-compat, which is missing in main. Am I doing something wrong?
2021-12-28 09:34:21 <omni> dhruvin: is it openssl-dev you need?
2021-12-28 09:35:15 <dhruvin> omni: I don't need openssl-dev.
2021-12-28 09:36:11 <dhruvin> It's just a simple C program that I'd like to package (depends on nothing else).
2021-12-28 09:38:43 <dhruvin> omni: I'm relatively new to alpine packaging. I believe I'm supposed to run bootstrap.sh with aarch64, to get the toolchain. Am I getting it right?
2021-12-28 09:44:59 <mps> dhruvin: bootstrap.sh is not for cross building, it is for bootstraping new arch
2021-12-28 09:46:09 <mps> for 'cross develepment' you can use qemu-user with lxc, or just qemu
2021-12-28 09:46:54 <dhruvin> mps: Oh, I was completely misunderstanding it. Thanks.
2021-12-28 09:47:21 <ikke> dhruvin: fyi: bootstrap.sh is meant for bootstrapping new arches, not for making a general cross-compiler
2021-12-28 09:53:08 <dhruvin> ikke: yes, now that I re-read the script it does make sense. I thought adding a new architecture would be necessary to add said architecture to arch="" field of some APKBUILD. I think I'll read more about it on wiki and elsewhere before moving forward.
2021-12-28 09:53:19 <dhruvin> Thanks omni mps and ikke.
2021-12-28 10:20:52 <ktprograms> dhruvin: Adding an architecture refers to porting the entirely of Alpine to a completely new arch (for example riscv64), to add an architecture to arch="" in an APKBUILD, you just need to add it there, but then to test it out you need to actually build it on that architecture. The simplest way to do that if you have qemu-user and binfmt_misc setup is to install the abuild-rootbld package and run 
2021-12-28 10:20:58 <ktprograms> 'CBUILD_ARCH=<arch> abuild rootbld', otherwise you could just build in a qemu-user lxc or chroot.
2021-12-28 12:34:24 <dhruvin> ktprograms: That's exactly what I needed. It seems to be working now. Thanks.
2021-12-28 14:01:26 <ktprograms> dhruvin: You're welcome
2021-12-28 14:15:47 <PureTryOut> hey ncopa, can I request enabling of a kernel module in linux-lts? and mps same in linux-edge
2021-12-28 14:16:21 <mps> PureTryOut: sure. which one
2021-12-28 14:16:36 <PureTryOut> CONFIG_HID_MAYFLASH
2021-12-28 14:16:51 <mps> which arch?
2021-12-28 14:16:56 <mps> or all?
2021-12-28 14:18:19 <PureTryOut> All I suppose
2021-12-28 14:18:48 <mps> ok, noted it for next upgrade
2021-12-28 14:18:52 <PureTryOut> I have direct use of it right now on x86_64 but have plans to use it on aarch64 as well. And I'm sure I'll get other arches in the future like RISCV64 to play with it
2021-12-28 14:18:53 <PureTryOut> thanks!
2021-12-28 14:19:37 <mps> np
2021-12-28 14:25:52 <PureTryOut> mps: oh btw also CONFIG_HID_WIIMOTE if possible
2021-12-28 14:40:19 <ncopa> PureTryOut: i guess x86* and arm*/aarch64 is enough?
2021-12-28 14:40:39 <ncopa> i dont think s390x users will need it
2021-12-28 14:40:41 <PureTryOut> I suppose. RISCV64 might be useful later on as well
2021-12-28 14:40:46 <PureTryOut> Oh no definitely not lol
2021-12-28 14:43:48 <psykose> what if i really want to emulate smash and play it with a wiimote at the ibm offices though
2021-12-28 14:43:59 <ncopa> PureTryOut: can you please create an issue for linux-lts? and add category:kernel label. I will do it with next kernel upgrade
2021-12-28 14:44:05 <PureTryOut> And just to be sure, I'd like both CONFIG_HID_MAYFLASH and CONFIG_HID_WIIMOTE to be enabled. Built-in or module are both fine
2021-12-28 14:44:09 <PureTryOut> Yes will do!
2021-12-28 14:44:18 <ncopa> thanks
2021-12-28 14:47:16 <PureTryOut> Done 👍️
2021-12-28 14:48:41 <Hello71> imo all these modules that don't increase core kernel size should be enabled. if they occupy too much space in aggregate they can be moved to subpackage, some linux-lts-miscinput
2021-12-28 14:50:47 <mps> heh, maybe we will at 'make allmodconfing' :)
2021-12-28 14:51:08 <alpine-meetbot> mps meant to say: heh, maybe we will end at 'make allmodconfing' :)
2021-12-28 14:51:08 <mps> s/will/will end/
2021-12-28 14:54:07 <mps> PureTryOut: will look at it also
2021-12-28 14:54:21 <PureTryOut> Thanks!
2021-12-28 15:01:40 <mps> ikke: I reenabled libreoffice and disabled java on it, hope you will not object
2021-12-28 15:03:44 <ikke> No, I just disabled it because it was hanging on the builder 
2021-12-28 15:04:14 <mps> it also hangs on lxc but pass with java disabled
2021-12-28 15:04:24 <ikke> If that's mitigated, it's fine with me 
2021-12-28 15:04:52 <mps> passed in lxc and I hope it will pass on builder
2021-12-28 15:04:53 <psykose> it would probably pass with clang
2021-12-28 15:04:59 <psykose> and java enabled
2021-12-28 15:05:23 <mps> meh, who needs java and clang
2021-12-28 15:06:25 <mps> ah yes, hipsters ;)
2021-12-28 15:19:01 <Hello71> can someone review !23774, !27650, !28035? also !28218, !28222, !28338, but those are arguably less important. !28653 can also be merged i think but always OOM on CI and probably OOM on builders too
2021-12-28 15:23:48 <psykose> i don't even know why that oom's
2021-12-28 15:23:56 <psykose> my change to qtwebengine passed first try
2021-12-28 15:25:23 <Hello71> depends what else is running i guess
2021-12-28 15:29:15 <PureTryOut> qtwebengine is quite random in that regard. Sometimes I need 10 tries before it succeeds, sometimes it succeeds first time
2021-12-28 15:30:04 <PureTryOut> But since it succeeds on all but x86_64 right now and that one only due to OOM, it should be fine to merge
2021-12-28 15:30:10 <psykose> yep
2021-12-28 15:30:50 <Hello71> i think the pass rate should be much reduced by adding debug symbols
2021-12-28 15:30:54 <psykose> it needs a pkgrel bump as well
2021-12-28 15:30:59 <Hello71> or, well, fixing debug symbols
2021-12-28 15:31:10 <Hello71> ugh, it does
2021-12-28 15:31:50 <psykose> i guess you can merge the sndio patch too :p 
2021-12-28 15:31:51 <Hello71> about ci, i would prefer to improve infra or make some workaround so we don't need to run it 10 times and waste some kwh of electricity
2021-12-28 15:31:54 <psykose> that will bump the rel
2021-12-28 15:32:05 <PureTryOut> could you link the sndio patch?
2021-12-28 15:32:12 <psykose> !28908
2021-12-28 15:32:13 <PureTryOut> actually nvm I saw that pass by
2021-12-28 15:32:47 <PureTryOut> Needs local rebase it seems, could you do that psykose?
2021-12-28 15:33:14 <psykose> done
2021-12-28 15:33:21 <mps> (looks like we need to ban Heisenberg from alpine development and ask Schroedinger to join ;) )
2021-12-28 15:33:26 <psykose> ah
2021-12-28 15:33:55 <PureTryOut> Hmm still can't merge that one
2021-12-28 15:34:11 <PureTryOut> Gitlab says it still needs to be rebased locally first
2021-12-28 15:34:17 <PureTryOut> I guess I'll manually merge locally
2021-12-28 15:34:33 <psykose> no, i just forgot to pull upstream first
2021-12-28 15:35:46 <PureTryOut> ah lol
2021-12-28 15:36:02 <PureTryOut> noticed that as well. Well I'm doing it locally now anyway
2021-12-28 15:36:40 <psykose> now it's done
2021-12-28 15:37:53 <PureTryOut> Oh I did it locally as well. Double-work, oh well
2021-12-28 15:38:19 <psykose> we both tried to do it too fast :p
2021-12-28 15:38:28 <PureTryOut> Yup haha
2021-12-28 15:38:41 <PureTryOut> I don't know sndio although I heard about it. Is it an alternative to PulseAudio and Pipewire?
2021-12-28 15:38:59 <psykose> yes, i believe the linux version is a openbsd port
2021-12-28 15:39:25 <PureTryOut> Interesting. Well have fun, whoever needs that 😛
2021-12-28 15:39:30 <psykose> indeed
2021-12-28 16:52:57 <omni> "need" is such a strong word
2021-12-28 16:54:05 <mps> sndio is not port for linux
2021-12-28 16:55:59 <mps> I'm not sure of its usability on linux though but it looks cleaner than pulseaudio
2021-12-28 17:02:51 <abk> Libreoffice is better with java enabled, some *very* useful text checkers use java. Although java mostly sucks, whoever started openoffice/libreoffice chose to use it for the user-made extensions.
2021-12-28 17:06:39 <ikke> abk: right now, on aarch64 it just hangs for us
2021-12-28 17:11:51 <abk> uh, thats weird. Sounds like someone missed something at a very low level. BTW, happy anticipated 2022 to everyone.
2021-12-28 17:48:57 <durrendal> anyone mind taking a look at MR28235 and letting me know if there's anything I need to correct with it?
2021-12-28 17:49:18 <durrendal> !28235, forgot it needed the exclam 
2021-12-28 17:52:39 <psykose> looks fine, though 3.12 community has been EOL since 3.13 came out, and i'm not sure what the point of backporting that for it is
2021-12-28 17:53:09 <psykose> unless you are running a box somewhere with 3.12 you really want sbcl on :p
2021-12-28 17:58:54 <durrendal> It's for the iSH iOS app, their repos are still stuck on 3.12 and they need SBCL to utilize a set of build tools they've written so they can upgrade everything to a supported release 
2021-12-28 17:59:21 <durrendal> normally I wouldn't bother since EOL is EOL, but they asked nicely :)
2021-12-28 18:01:37 <psykose> ah
2021-12-28 18:01:42 <psykose> yes, i think it is fine
2021-12-28 18:02:14 <psykose> i wish them luck with 3.15, afaik a straight upgrade is painless
2021-12-28 18:04:23 <mps> abk: never liked java in libreoffice, though I don't use any-office tools much
2021-12-28 18:05:21 <durrendal> that's what I thought, but it has something to do with the x86 emulation on the iPhone's arm chips. Either way, if it makes it easier for them to get alpine into more people's hands, I'm happy to help :)
2021-12-28 20:14:49 <ikke> psykose: isn't #13362 that they are combining edge and 3.15? 
2021-12-28 20:15:01 <psykose> nope
2021-12-28 20:15:02 <ikke> It mentions python3.10
2021-12-28 20:15:09 <psykose> sure, but that fails on edge
2021-12-28 20:15:11 <psykose> or 3.15
2021-12-28 20:15:14 <ikke> hmm
2021-12-28 20:15:17 <psykose> you can try it, just import gettext from locale
2021-12-28 20:15:22 <ikke> ok
2021-12-28 20:15:32 <ikke> I believe you, but that part is just suspect
2021-12-28 20:15:59 <psykose> to be honest i didn't even see :p
2021-12-28 20:16:04 <psykose> 5.11.22 is also a strange kernel version
2021-12-28 20:16:08 <ikke> That's the first thing I look for :-)
2021-12-28 20:16:30 <psykose> wait no
2021-12-28 20:16:31 <psykose> i am silly
2021-12-28 20:16:37 <psykose> py3-gettext does provide it
2021-12-28 20:16:46 <psykose> groan
2021-12-28 20:17:35 <psykose> thanks for catching it
2021-12-28 20:17:45 <ikke> np
2021-12-28 20:20:21 <psykose> or did i bamboozle myself twice
2021-12-28 20:20:24 <psykose> ah, of course i did
2021-12-28 20:20:28 <ikke> :D
2021-12-28 20:20:31 <psykose> no, py3-gettext provides "pythongettext"
2021-12-28 20:20:47 <ikke> so tripple now?
2021-12-28 20:20:52 <psykose> i had rebuild python locally with gettext
2021-12-28 20:20:55 <psykose> and the example worked
2021-12-28 20:20:56 <psykose> groan
2021-12-28 20:21:16 <psykose> ok, so the issue is correct, and not an edge mixing issue
2021-12-28 20:21:23 <ikke> odd
2021-12-28 20:22:46 <psykose> i guess enabling gettext on main/python3 would cause very python thing that invokes cc to need libintl-dev, if the comment is true
2021-12-28 20:23:09 <psykose> don't think there is an easy solution
2021-12-28 20:24:03 <ikke> interesting. Installing xfce4-screensaver does not install python
2021-12-28 20:24:11 <ikke> so the configure tool does not work
2021-12-28 20:24:34 <ikke> psykose: but yes, if I do it on 3.15, I get the message for python3.0
2021-12-28 20:24:38 <ikke> 3.9*
2021-12-28 20:25:06 <psykose> the missing python is pretty common for these DE specific dependencies
2021-12-28 20:25:13 <ikke> ImportError: cannot import name 'gettext' from 'locale' (/usr/lib/python3.9/locale.py)  
2021-12-28 20:25:27 <psykose> yep, and you need to compile with gettext-dev for it
2021-12-28 20:25:57 <ikke> Maybe patch out gettext?
2021-12-28 20:26:01 <ikke> not sure how feasible
2021-12-28 20:26:53 <psykose> this isn't the first time i've seen it, would be a patch per program each time
2021-12-28 20:26:56 <psykose> let me inspect this instance
2021-12-28 20:27:04 <aparcar> Ariadne: good evening
2021-12-28 20:27:39 <Ariadne> hi
2021-12-28 20:27:55 <psykose> ikke: i don't think it's possible
2021-12-28 20:27:57 <ikke> psykose: https://gitlab.alpinelinux.org/Leo/atools/-/merge_requests/55 was merged :-)
2021-12-28 20:28:07 <psykose> it's just a binding to c gettext, and gets the translation string
2021-12-28 20:28:14 <psykose> removing it means removing translations
2021-12-28 20:29:27 <psykose> ikke: oh, i noticed the main/* one was merged too
2021-12-28 20:29:30 <psykose> i guess i was wrong :)
2021-12-28 20:29:35 <aparcar> Ariadne: I'm facing this issue and since you're the last person "touching" adb.c I was wondering if it could be related: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10803
2021-12-28 20:30:45 <psykose> make: /usr/bin/make: Operation not permitted
2021-12-28 20:30:50 <psykose> ppc64le ci is busted it seems
2021-12-28 20:31:15 <ikke> hmm
2021-12-28 20:31:16 <ikke> ok
2021-12-28 20:31:18 <ikke> I know why
2021-12-28 20:31:19 <psykose> it happens at random too
2021-12-28 20:31:43 <Ariadne> aparcar: nope, but i can dig into it
2021-12-28 20:32:20 <ikke> psykose: should be fixed now
2021-12-28 20:32:25 <psykose> what was the issue
2021-12-28 20:33:13 <ikke> I disabled a custom seccomp profile we put into place to work around docker/runc returning -EPERM for unknown syscalls
2021-12-28 20:33:29 <ikke> which was necessary after faccess2 was added to musl
2021-12-28 20:33:56 <psykose> hah
2021-12-28 20:34:03 <ikke> I disabled the profile because we thought it caused other issues
2021-12-28 20:34:12 <ikke> so I enabled it again
2021-12-28 20:34:56 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2
2021-12-28 20:36:10 <ikke> psykose: having targeted MRs helps, less room for bikeshedding
2021-12-28 20:36:23 <psykose> maybe i just really like bikeshedding
2021-12-28 20:36:32 <ikke> :)
2021-12-28 20:37:01 <psykose> that's more smiles from you than i've seen in weeks :p
2021-12-28 20:37:19 <psykose> happy ikke
2021-12-28 21:07:00 <aparcar> Ariadne: test, did you see my last message regarding the adb.c issue? My IRC client is acting up
2021-12-28 21:07:17 <ikke> aparcar: yes
2021-12-28 21:07:31 <aparcar> ikke: thank you
2021-12-28 21:07:42 <ikke> Ariadne │ aparcar: nope, but i can dig into it
2021-12-28 21:48:57 <Ariadne> aparcar: this is on glibc?
2021-12-29 00:33:49 <tomalok> any significant mdev changes land for 3.15?  i have /lib/mdev script that doesn't seem to be working anymore...
2021-12-29 00:51:30 <ktprograms> Should the qt5-qtwebengine stack size fix be backported to 3.15? Not that it affects me personally so if no one has the time to do it I don't mind.
2021-12-29 00:53:23 <Hello71> possibly but i'm not going to
2021-12-29 00:55:04 <ktprograms> Hello71: I'm also busy these few days, so I don't think I can do it. But thanks for fixing the problem (I tested it with qutebrowser and it doesn't crash)
2021-12-29 00:55:12 <Hello71> mmhmm
2021-12-29 00:56:24 <ktprograms> It's funny but I keep typing 'doas' when I mean to type 'does', which is probably the only downside of doas over sudo, it messes up your muscle memory.
2021-12-29 01:18:52 <tomalok> newer /etc/mdev.conf rule above my rule steals the event, apparently...
2021-12-29 01:30:07 <minimal> tomalok: yeah ncopa made some changes regarding mdev to replace a few scripts with persistent-storage and modified the mdev.conf according to call it
2021-12-29 07:42:35 <anjan> ktprograms: Im running into issues with qutebrowser. Im assuming the stack size fix is the solution?
2021-12-29 07:42:53 <anjan> qutebrower's renderer will randomly crash
2021-12-29 07:43:05 <anjan> Ill look into the patch and see if I can backport. Thanks for the nudge he
2021-12-29 07:43:39 <ktprograms> anjan: Yes, it has been fixed in edge and most probably is in all the mirrors that aren't broken. The fixed version is 5.15.3_git20211127-r4, and psykose has already submitted a backport MR I think.
2021-12-29 07:43:51 <ktprograms> (FYI it wasn't fixed by me)
2021-12-29 07:43:59 <anjan> ktprograms: oh ok, I guess I can check if the backport fixes it then
2021-12-29 07:44:12 <anjan> I dont use edge, I use the latest stable release ktprograms 
2021-12-29 07:44:28 <anjan> too much breakage on edge for my workstations =(
2021-12-29 07:44:33 <ktprograms> anjan: I see.
2021-12-29 08:42:18 <mps> good morning
2021-12-29 08:43:46 <mps> jirutka should be banned from alpine, he splits agetty from util-linux without proper depend or install_if
2021-12-29 08:44:01 <mps> and without announce
2021-12-29 09:30:53 <omni> I wonder what installed it for me then
2021-12-29 09:36:37 <MY-R> probably 68771b613c825ad4dff3286c602cac44aa818987
2021-12-29 10:01:03 <mps> MY-R: right
2021-12-29 10:12:12 <mps> this morning I had to 'pass' complicated procedure to get login prompt on M1 because of this (unannounced) change
2021-12-29 10:18:21 <MY-R> welcome in "edge"
2021-12-29 10:22:09 <mps> heh, you should say this to me more than three years ago :)
2021-12-29 14:58:50 <mps> PureTryOut: HID_WIIMOTE was already enabled in x86_64 linux-edge
2021-12-29 15:00:31 <mps> and aarch64
2021-12-29 15:01:45 <mps> psykose: FSL_MC_UAPI_SUPPORT was already enabled in linux-edge aarch64
2021-12-29 15:02:04 <PureTryOut> awesome
2021-12-29 15:58:59 <psykose> mps: i don't know what that is, did you confuse me with someone else :p
2021-12-29 16:22:07 <PJ[m]> is there solution to armhf ci being painfully slow?
2021-12-29 16:22:55 <psykose> it's faster than ppc64le 50% of the time
2021-12-29 16:23:22 <psykose> but no, not really
2021-12-29 17:23:37 <mps> psykose: hm, someone asked to enable this option in kernel and I thought you are
2021-12-29 17:24:15 <mps> psykose| mps: may i humbly request an enabling of https://cateee.net/lkddb/web-lkddb/INTEL_RAPL.html for config-edge.x86_64
2021-12-29 17:24:44 <mps> but someone else asked RAPL
2021-12-29 17:30:22 <mps> ah Ariadne asked for FSL_MC_UAPI_SUPPORT
2021-12-29 17:40:32 <psykose> ah, makes sense
2021-12-29 17:44:01 <Ariadne> mps: yes i like being able to configure my smart NIC
2021-12-29 17:55:56 <mps> Ariadne: it was enabled in linux-edge for some time
2021-12-29 17:57:51 <mps> actually long ago
2021-12-29 20:30:22 <tbodt> ncopa: ptal at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28712
2021-12-29 21:04:58 <ikke> nice that riscv64 is up-to-speed
2021-12-29 21:07:44 <psykose> oh shit
2021-12-29 21:07:44 <psykose> it is
2021-12-29 21:07:48 <psykose> i am impressed
2021-12-29 21:09:40 <ikke> note that we do not run tests on riscv64 atm
2021-12-29 21:09:50 <psykose> yep, still no check
2021-12-29 21:09:56 <psykose> or ci for it, but it makes sense
2021-12-29 21:10:40 <ikke> Yeah, we could add it, but it would add a lot of noise / delay to MRs
2021-12-29 21:13:04 <psykose> indeed
2021-12-29 21:13:15 <psykose> maybe in 2 years there will be some decent hardware
2021-12-29 21:13:42 <ikke> yeah, the hardware atm is pi-grade
2021-12-29 21:14:02 <ikke> Our builder is x86_64 with qemu-user
2021-12-29 22:16:29 <donoban> I think that this line should be removed https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2380 , is there any reason for creating build users/groups on the host system? Doesn't have more sense to add it them inside the chroot?
2021-12-29 22:18:09 <donoban> maybe it should be add inside rootbld_actions() https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2339
2021-12-29 22:19:47 <ikke> No motivation, but it was done deliberately: https://gitlab.alpinelinux.org/alpine/abuild/-/commit/cf18bf6ed98715be16e9c335c8113b208ca29776
2021-12-29 22:20:14 <ikke> apparently it did not work in the chroot
2021-12-29 22:20:28 <donoban> uhM
2021-12-29 22:22:03 <donoban> let's dig into it :)
2021-12-29 22:24:57 <mps> nice, mold linker is added to gcc 12
2021-12-29 22:25:02 <mps> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868
2021-12-29 22:26:10 <psykose> clang did this better with --ld-path so you can just pass any linker instead of needing hardcoded definitions in the cc
2021-12-29 22:29:08 <ikke> anoying that ppc64le takes so long to just upload the artifacts
2021-12-29 22:31:03 <psykose> it's also sporadic, sometimes it's much faster than other times
2021-12-29 22:31:28 <psykose> i heard it was ibm that provided it, does anyone here have the contact info to tell them to fix it :p
2021-12-29 22:32:03 <ikke> psykose: it's a long standing issue
2021-12-29 22:32:04 <psykose> i also find it impressive that the ci with 64(?) or some silly number of threads is slower than s390x with 8 95% of the time
2021-12-29 22:32:30 <psykose> i know it's long standing, but i'm wondering if the hosts were told
2021-12-29 22:33:16 <ikke> https://gitlab.alpinelinux.org/alpine/infra/compose/gitlab-runner-alpine-ci/-/issues/2
2021-12-29 22:33:22 <ikke> Yes, we did tell them
2021-12-29 22:33:45 <psykose> blech
2021-12-29 22:33:51 <psykose> a year of networking issues
2021-12-29 22:34:05 <ikke> It was good for quite some time
2021-12-29 22:34:10 <ikke> it came back
2021-12-29 22:34:23 <psykose> aye, just unlucky
2021-12-29 22:40:51 <donoban> abuild-addgroup: User builder is not a member of group abuild
2021-12-29 22:40:55 <donoban> >>> ERROR: spotifyd: mkusers failed
2021-12-29 22:41:38 <donoban> I think that the right fix was just add "builduser" to that group before
2021-12-29 23:54:01 <Hello71> also the artifact uploads sometimes fail
2021-12-30 01:19:45 <anjan> hey, the qt-webengine patch fixed my issue with qutebrowser
2021-12-30 01:19:47 <anjan> thanks yall
2021-12-30 02:23:36 <Hello71> mmhmm
2021-12-30 02:41:11 <psykose> hm, wonder why the checksums changed just for a rebuild
2021-12-30 02:41:23 <psykose> i guess the old ones were cached, so the builders can't validate against the new ones
2021-12-30 02:44:04 <Hello71> what for
2021-12-30 02:44:23 <psykose> e.g. https://img.ayaya.dev/hd3kopdJATVD
2021-12-30 02:44:27 <psykose> and check the build failures currently
2021-12-30 02:44:58 <psykose> they did legitimately change, but i have no idea why
2021-12-30 02:47:26 <psykose> the updated versions in the apkbuilds are correct, so i'm assuming it's still using the older cached ones from the previous builds as the file is the same
2021-12-30 06:46:20 <ikke> psykose: yes, archives are stored at distfiles.alpinelinux.org
2021-12-30 06:46:52 <psykose> i guess someone needs to cycle those few
2021-12-30 06:49:25 <ikke> apparently they retagged. _version.py has been updated
2021-12-30 06:49:32 <psykose> yep
2021-12-30 06:49:45 <ikke> https://tpaste.us/PrOx
2021-12-30 06:50:40 <ikke> removed it
2021-12-30 06:52:53 <ikke> sphinx-theme-bootstrap changed significantly
2021-12-30 06:53:39 <psykose> i guess they really just cycled the tag on github then
2021-12-30 06:54:11 <ikke> tagged the wrong commit I suppose
2021-12-30 06:54:15 <ikke> or something like that
2021-12-30 06:54:50 <ikke> 2 years difference in the date even
2021-12-30 06:55:02 <ikke> 2019-09-25 vs 2021-09-11
2021-12-30 06:56:35 <psykose> free upgrade :^)
2021-12-30 12:43:14 <ikke> psykose: hmm, test_018b_http_10_keepalive_framing fails on s390x for py3-eventlet, broken pipe
2021-12-30 12:43:27 <psykose> classic flaky tests
2021-12-30 12:43:29 <ikke> yes
2021-12-30 12:43:38 <ikke> I retried it once
2021-12-30 12:44:26 <psykose> one more for the disable
2021-12-30 12:44:34 <ikke> I think we should remove the maintainer of that package, they have not been active for 10 years
2021-12-30 12:44:43 <psykose> agree
2021-12-30 12:47:06 <psykose> do i bump a pkgrel for a test disable on a failing arch
2021-12-30 12:47:09 <ikke> no
2021-12-30 12:47:32 <ikke> The already built packages do not need to be rebuilt, while the failing builder picks up the new change
2021-12-30 12:48:07 <psykose> !29019
2021-12-30 12:48:11 <psykose> thanks, just making sure
2021-12-30 12:48:14 <ikke> np
2021-12-30 12:48:24 <ikke> Happy to explain these things
2021-12-30 12:48:36 <ikke> While we do not have it documented yet :P
2021-12-30 12:49:00 <psykose> ~yet~ :p
2021-12-30 12:49:59 <psykose> i will say, all these commits/rebases i have been going through have made me much faster at git
2021-12-30 12:51:12 <ikke> heh :-)
2021-12-30 12:51:20 <ikke> psykose: I have hope :P
2021-12-30 12:51:58 <psykose> i wonder if it fits into commitstyle or in another document
2021-12-30 12:52:15 <ikke> ttps://docs.alpinelinux.org/developer-handbook/0.1a/index.html
2021-12-30 12:52:20 <ikke> https://docs.alpinelinux.org/developer-handbook/0.1a/index.html
2021-12-30 12:52:29 <psykose> ah, right
2021-12-30 12:52:43 <psykose> that is so ~big~ and formal though.. hard to write..
2021-12-30 12:52:54 <psykose> ah i guess if you give me a list of bullet points i can give it a start
2021-12-30 12:53:04 <psykose> when i have not been awake for 24 hours anyway
2021-12-30 12:53:08 <ikke> heh
2021-12-30 12:53:57 <psykose> well, ci passes
2021-12-30 12:54:01 <psykose> time for attempt two at the same ci
2021-12-30 12:54:03 <psykose> then should be ok
2021-12-30 12:54:15 <psykose> i can also remove the maintainer line if you want
2021-12-30 12:54:22 <PJ[m]> go sleep, this is a threat
2021-12-30 12:57:28 <psykose> no u
2021-12-30 13:13:34 <psykose> ikke: shall i delete the 3 maintainer lines with this person, or replace it with myself
2021-12-30 13:15:18 <psykose> er, two
2021-12-30 13:15:54 <ikke> proftpd and py3-eventlet
2021-12-30 13:16:22 <ikke> Maybe you could try sending an e-mail just as a formality
2021-12-30 13:16:29 <psykose> proftpd is maintained by someone else
2021-12-30 13:16:37 <psykose> greeneventlet
2021-12-30 13:16:41 <ikke> ok, it was initially added by Elizabeth
2021-12-30 13:16:41 <psykose> sure, i will artifice an email
2021-12-30 13:17:10 <psykose> what was the alpine-devel cc again
2021-12-30 13:17:41 <ikke> ~alpine/devel@lists.alpinelinux.org
2021-12-30 13:18:04 <ikke> Last commit was from 2011
2021-12-30 13:24:54 <psykose> undelivered mail returned to sender
2021-12-30 13:25:20 <psykose> the MX is also the default for the porkbun registrar, it's just an unused domain
2021-12-30 13:28:41 <psykose> is that how you are even meant to cc a list or did i ping everyone :p
2021-12-30 13:36:29 <ikke> You sent it to the mailing list
2021-12-30 13:36:39 <ikke> But that's not an issue
2021-12-30 13:36:50 <ikke> But feel free to take over maintenership then
2021-12-30 13:37:15 <psykose> is that not who i am supposed to cc
2021-12-30 13:40:50 <ikke> yes
2021-12-30 13:41:26 <psykose> then what did i do wrong
2021-12-30 13:41:41 <ikke> Nothing?
2021-12-30 13:42:33 <psykose> i guess the random person shouting at me in another oftc channel about it 1 minute after i sent it is just being an ass then
2021-12-30 13:42:41 <mps> psykose: you joined alpine ;)
2021-12-30 13:42:51 <psykose> joined? :p
2021-12-30 13:43:07 <psykose> is there something wrong with me joining
2021-12-30 13:43:09 <mps> psykose: yes, you did
2021-12-30 13:43:28 <mps> psykose: and yes and no
2021-12-30 13:43:31 <skarnet> psykose: it's complicated but the short answer is that yes he was being an ass
2021-12-30 13:43:47 <mps> psykose: jk
2021-12-30 13:43:55 <psykose> my poor nerves
2021-12-30 13:44:01 <skarnet> I told him to behave, come back and if he doesn't stfu he will leave
2021-12-30 13:44:39 <mps> don't worry, that is 'nature' of open 'systems'
2021-12-30 13:44:52 <skarnet> but also, and that goes for ikke or anyone else, ccing the whole list on the first callout email to a maintainer is pretty aggressive
2021-12-30 13:44:55 <skarnet> and I would not like that
2021-12-30 13:45:08 <skarnet> could FOSS people please learn some social skills
2021-12-30 13:45:16 <skarnet> it would help
2021-12-30 13:45:29 <mps> some can some can't
2021-12-30 13:45:51 <skarnet> at least it would help me stop feeling like the only adult in the room
2021-12-30 13:45:59 <skarnet> which is not the kind of ego boost I need
2021-12-30 13:46:10 <mps> but this is irrelevant, 'we' need to learn to be calm
2021-12-30 13:48:46 <ikke> skarnet: it's a way to create a public record, not for people just to claim having sent the request
2021-12-30 13:48:59 <mps> skarnet: now serious question, could the mdevd read config from more files, for example mdevd.conf.d with include in /etc/mdev.conf
2021-12-30 13:56:21 <skarnet> ikke: yes, but again, it's a question of perception and it can come off as pretty aggressive, and as a maintainer I'd hate it if the *first* e-mail I get were public
2021-12-30 13:56:28 <skarnet> second and further ones are fair game
2021-12-30 13:56:55 <skarnet> but the first ping should not alert the whole list, because a maintainer's absence can be very justified
2021-12-30 13:57:11 <skarnet> mps: I already answered this in here I think
2021-12-30 13:57:43 <skarnet> my answer was that the point of mdevd was to follow the exact mdev.conf format, because if I was designing a device manager from scratch I would definitely not follow that ugly format in the first place
2021-12-30 13:57:57 <mps> skarnet: hmm, then I missed it or I forgot, sorry
2021-12-30 13:58:08 <skarnet> I *could* probably add mdev.conf.d functionality but then it would stop being a drop-in replacement for mdev
2021-12-30 13:58:22 <skarnet> and my longer answer contained a question that did not get answered
2021-12-30 13:58:48 <skarnet> the simplest way for distros to handle config files with independently mobile parts, which is a common problem with daemons, is preprocessing
2021-12-30 13:58:57 <mps> skarnet: I don't ask you to add it, just wanted to know if it is there already (and to not look source)
2021-12-30 13:59:02 <skarnet> have a script reading files in mdev.conf.d and cat'ing them to mdev.conf
2021-12-30 13:59:12 <skarnet> and do the same with any similar daemon reading a flat config file
2021-12-30 13:59:25 <skarnet> and my question was, why was this discouraged in Alpine
2021-12-30 13:59:30 <skarnet> because it's not bad practice per se
2021-12-30 13:59:31 <mps> yes, this could be solution
2021-12-30 14:00:17 <mps> skarnet: thank you nice answer
2021-12-30 14:01:05 <ikke> skarnet: This is what jirtuka argued for doas: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/1#note_169964
2021-12-30 14:01:40 <mps> re maintainer mail: I don't care will someone contact me with CC to devel ML or private, I consider my mail address public else I wouldn't put it there
2021-12-30 14:04:15 <skarnet> yeah but failing to maintain a package for a given period of time is a failure and getting pinged is a call-out
2021-12-30 14:04:34 <skarnet> and the first ping should definitely be gentle because, again, there could be very good reasons
2021-12-30 14:04:48 <skarnet> and a public ping definitely feels like a public call-out to me
2021-12-30 14:05:05 <skarnet> if it doesn't feel that way to you, then more power to you, you're not as much of a snowflake than I am
2021-12-30 14:05:08 <mps> hmm, not sure
2021-12-30 14:05:18 <skarnet> s/than/as
2021-12-30 14:05:18 <alpine-meetbot> skarnet meant to say: if it doesn't feel that way to you, then more power to you, you're not as much of a snowflake as I am
2021-12-30 14:05:35 <mps> skarnet: :)
2021-12-30 14:05:38 <mps> lol
2021-12-30 14:06:04 <mps> if you are snowflake I don't know who is not then
2021-12-30 15:23:54 <Nulo> How can I make rootbld cache packages?
2021-12-30 15:32:10 <Nulo> Heyy https://github.com/telegramdesktop/tdesktop/commit/7b4354eb4ab38371f0edc010a32190fc11c667cb
2021-12-30 15:33:58 <psykose> well it saves a few lines of patch :)
2021-12-30 15:34:36 <psykose> but you can't use that patch because it's submodule patches, so next release
2021-12-30 15:35:05 <psykose> i'd say the mr is already fine to merge
2021-12-30 15:40:31 <Nulo> psykose, they *just* tagged 3.4.0
2021-12-30 15:40:37 <psykose> convenient
2021-12-30 15:40:47 <Nulo> And 3.3.2 before that
2021-12-30 15:40:56 <Nulo> Which I was trying to build before I realized they had 3.4.0
2021-12-30 15:41:11 <Nulo> It's so early that they haven't uploaded the tar.gz with submodules included, so I'm waiting
2021-12-30 15:43:34 <mps> Nulo: MR is ok but please remove so much not needed comments from APKBUILD, those which are needed add to git commit msg
2021-12-30 15:44:12 <Nulo> mps, which comments do you find are not needed?
2021-12-30 15:44:41 <mps> mentioning qt6
2021-12-30 15:45:00 <Nulo> I wanted to leave info about why each dependency is bundled or not and how to easily check for new dependencies according to the wiki page (because upstream doesn't like mentioning new dependencies in changelogs)
2021-12-30 15:45:01 <psykose> qt6 comment is fine
2021-12-30 15:45:43 <Nulo> It's just one line :') and it's a TODO, I tried to follow CODINGSTYLE.md
2021-12-30 15:45:44 <mps> psykose: why it can't be fine in commit msg
2021-12-30 15:45:57 <psykose> because when someone opens the apkbuild they don't see the commit messages
2021-12-30 15:46:16 <mps> so git log is complicated
2021-12-30 15:46:32 <psykose> idk about you but i don't have the time to read the 30 prior commits of every package i touch
2021-12-30 15:46:45 <psykose> a todo: in the apkbuild is extremely clear on the other hand
2021-12-30 15:46:47 <mps> then you should
2021-12-30 15:47:36 <mps> if someone doesn't have time then s/he shouldn't work on pkg
2021-12-30 15:47:46 <psykose> it is literally the same thing but takes more time to find
2021-12-30 15:47:53 <psykose> and is more likely to be missed
2021-12-30 15:47:56 <Nulo> To be clear, I added comments because it's the sort of info I wished I had when I started "maintaining" the package. "Why is Qt6 not enabled? Should it be enabled?" (actually, that was my change, but I couldn't understand why Void had done it)
2021-12-30 15:48:02 <psykose> for absolutely no benefit aside from... saving 1 line in a 100 line file
2021-12-30 15:48:03 <psykose> get real
2021-12-30 15:48:09 <ikke> I typically put information both in comments and in the commit message
2021-12-30 15:48:46 <mps> every character saved is worth thing
2021-12-30 15:48:48 <Hello71> commit messages should be used for information that was relevant at the time, but is likely to expire soon. comments should be used for information which is likely to remain relevant
2021-12-30 15:49:11 <Hello71> "upgrade to 3.5.0" is not relevant for future readers to know
2021-12-30 15:49:24 <mps> Hello71: meh
2021-12-30 15:49:35 <mps> I disagree
2021-12-30 15:50:29 <mps> git log is invented to keep history, look at kernel git log, and I'm sure you did a lot of times
2021-12-30 15:50:40 <ikke> How often do you read all commits affecting an APKBUILD to figure out all the contexT?
2021-12-30 15:50:49 <Hello71> so in your opinion, code should never have any comments?
2021-12-30 15:51:00 <mps> ikke: often
2021-12-30 15:51:26 <psykose> Nulo: you may also now make it minsizerel
2021-12-30 15:51:41 <mps> and if I don't understand something than I use 'git log -p' always
2021-12-30 15:52:07 <ikke> But what if the comment was right there, explaining it?
2021-12-30 15:52:07 <mps> Hello71: I'm not against all comments
2021-12-30 15:52:20 <Hello71> for some projects, there is arguably reason to keep information in commits rather than source tree to save space for users who only need latest version. for aports i think this doesn't really apply
2021-12-30 15:52:42 <ikke> To me they are not mutually exclusive
2021-12-30 15:53:14 <mps> ok, I give up, do whatever you want
2021-12-30 15:53:31 <Nulo> psykose, done
2021-12-30 15:54:31 <mps> and enjoy mess
2021-12-30 15:55:22 <Nulo> psykose, https://gitlab.alpinelinux.org/Nulo/aports/-/jobs/579660#L55 lint complains about MinSizeRel, normal?
2021-12-30 15:55:34 <psykose> yeah, it will go away after atools gets a bump/container refresh
2021-12-30 15:55:36 <psykose> but it is changed
2021-12-30 15:55:56 <mps> Hello71: btw, I'm sure you meet long numbers of code where comment and code don't 'agree'
2021-12-30 15:58:18 <mps> Nulo: I removed hold label from telegram-desktop
2021-12-30 15:58:36 <Nulo> Thanks
2021-12-30 16:25:37 <Nulo> Who is "in charge" of merging this now that it has no maintainer? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28864
2021-12-30 16:26:10 <psykose> people with merge access
2021-12-30 16:26:18 <psykose> maintainers can't merge normally either
2021-12-30 16:26:45 <Nulo> Well, of approving it I guess
2021-12-30 16:26:51 <psykose> doesn't have to be
2021-12-30 16:27:07 <psykose> and you are the maintainer
2021-12-30 16:28:57 <PJ[m]> +1 for comments instead of commit messages, i hate deep diving git log to find context which could be done as simple comment
2021-12-30 16:51:31 <dalias> i prefer commit messages over comments because.. (1) temporal locality, to the *change* not the code. they're describing the reason for changing what is done or how it's done, and are missing context when you don't see them alongside the change
2021-12-30 16:52:38 <dalias> (2) bitrot. often when making changes, a comment that no longer applies (and that might even be misleading) is overlooked and left in place. this can't happen if it's instead attached to the immutable change it was associated with
2021-12-30 16:54:07 <dalias> (3) clutter from exaggerated impression of relevance/importance when making the change
2021-12-30 16:54:25 <dalias> and reading git log isn't a "deep dive", it's a trivial one-line command
2021-12-30 16:54:30 <psykose> i don't disagree with any of this, but the context was a TODO comment
2021-12-30 16:54:42 <psykose> of which there are 4 mentions in the musl history, and 22 in the tree
2021-12-30 16:59:50 <dalias> :)
2021-12-30 17:04:15 <Ariadne> i only use code comments for situations where i expect somebody (multiple somebodies) are going to ask about something weird
2021-12-30 17:13:00 <skarnet> code comments are for voodoo parts that aren't self-explaining
2021-12-30 17:13:11 <skarnet> (self-explanatory? English is hard.)
2021-12-30 17:56:21 <mps> nice to see that some smart people agree with me :)
2021-12-30 17:57:19 <mps> Nulo: I will merge it this time but please be more receptive what smart people say next time ;)
2021-12-30 17:58:06 <Nulo> I very much believe that Qt6 it's a voodoo part that isn't self-explanatory; but I wasn't explaining anything, I made a TODO
2021-12-30 17:58:14 <mps> Nulo: whatever we say you did a good work
2021-12-30 17:58:16 <psykose> if you think everyone that disagrees with you is a moron you are free to close the merge requests as well
2021-12-30 17:58:19 <Nulo> The other comments explain why some dependencies are bundled, etc
2021-12-30 17:58:51 <Nulo> mps, thanks <3 also huge thanks to psykose and someone else which I forgot
2021-12-30 17:59:40 <mps> psykose: yes, I have rights to do this but I don't think _everyone_ is moron, we just disagrees I think
2021-12-30 18:00:51 <mps> psykose: I prefer consistent state of alpine and I will fight for it to much higher degree
2021-12-30 18:02:44 <Ariadne>  7:42 AM <psykose> i guess the random person shouting at me in another oftc channel about it 1 minute after i sent it is just being an ass then
2021-12-30 18:03:06 <Ariadne> that random person was also banned from participation in alpine for running a developer out of the project with a harassment campaign
2021-12-30 18:03:35 <Ariadne> the reason for CCing maintainer pings to alpine-devel list is so that there is a record that the maintainer was actually pinged.  it is the correct procedure
2021-12-30 18:03:57 <mps> Ariadne: ^ I agree
2021-12-30 18:06:49 <mps> but something of shiny, booting alpine armv7 VM in qemu on M1 take about nearly one minute, not much longer than on real hardware
2021-12-30 18:07:39 <mps> (we shouldn't end year in bad 'mode')
2021-12-30 18:10:46 <Ariadne> :)
2021-12-30 18:14:14 <Ariadne> skarnet: fwiw, it is assumed that the missing-maintainer process is invoked *after* some attempt to contact the maintainer privately, though that is admittedly not stated
2021-12-30 18:15:06 <Ariadne> a lot of the time, a maintainer is contacted, and replies, "sure, take it over" and then a takeover MR is filed, quoting the email in question :)
2021-12-30 18:17:08 <skarnet> Ariadne: yeah as long as the maintainer is contacted privately first I have no objections
2021-12-30 18:19:42 <Ariadne> the other purpose of cc to alpine-devel, is that somebody might have an alternate contact for the maintainer, and can go ping them :P
2021-12-30 18:23:24 <skarnet> Ariadne: is there a record of the harassment campaign thing? I wasn't aware of that and would like more info
2021-12-30 18:24:29 <Ariadne> skarnet: he (as ^7heo) harassed Barthalion until he left, on IRC, on Github, etc
2021-12-30 18:25:04 <Ariadne> and encouraged other alpine devs to participate
2021-12-30 18:25:11 <Ariadne> because he deemed barthalion to be incompetent
2021-12-30 18:25:21 <skarnet> that's the kind of thing I'd like to see a record of
2021-12-30 18:25:45 <Ariadne> unfortunately, i don't have irc logs anymore, i deleted my quassel instance
2021-12-30 18:26:29 <skarnet> I wasn't paying attention back then, and didn't care much about the drama because the few times I had interacted with barthalion before, he'd been an ass to me
2021-12-30 18:26:51 <Ariadne> but you can ask ncopa about it, as he dealt with it
2021-12-30 18:26:59 <Ariadne> it is why alpine has CoC today
2021-12-30 18:27:33 <skarnet> I thought the reason Alpine has a CoC was because its devs had no balls
2021-12-30 18:27:41 <skarnet> (sorry, had to make it)
2021-12-30 18:28:06 <psykose> [alpine-devel] a discourse on the troubles .. is the only real thing related to it that i can find
2021-12-30 18:28:28 <Ariadne> specifically, the core team was tasked with producing and implementing a CoC as a result of that incident
2021-12-30 18:29:36 <skarnet> indeed I remember jirutka being at odds with barthalion, but I don't remmber ^7heo being a part of it
2021-12-30 18:30:20 <ikke> I still have the logs I believe
2021-12-30 18:30:37 <Ariadne> he was part of it.  jirutka got the larger attention because he was on the alpine core team, and he should not have been involved in the incident
2021-12-30 18:32:15 <mps> what is approximate time when this happened? I can't remember about this but I was here when the jirutka also was here
2021-12-30 18:34:13 <Ariadne> it was july 2017
2021-12-30 18:36:31 <psykose> oh and ariadne
2021-12-30 18:36:32 <psykose> thanks
2021-12-30 18:36:37 <mps> hmm, I think I joined at the end of that year so probably I was not here when this happened
2021-12-30 18:36:51 <ikke> I have logs here
2021-12-30 18:37:02 <ikke> at least, some logs
2021-12-30 18:37:50 <mps> ikke: for me you don't have to post them, don't think it will be interesting to me
2021-12-30 18:38:14 <mps> but nice to know that someone preserves logs
2021-12-30 18:38:44 <skarnet> ikke: I'll appreciate a link if you have one, but no obligation obviously, and no rush
2021-12-30 18:39:01 <skarnet> also thanks to everyone involved for the additional information
2021-12-30 18:39:13 <ikke> It's mostly meta, I don't see anything involving barthalion
2021-12-30 18:43:38 <Ariadne> afaik it was mostly on #alpine-offtopic
2021-12-30 18:55:48 <ikke> I think the actual issue happened before I joined
2021-12-30 18:55:54 <ikke> around 2016
2021-12-30 18:56:06 <mps> how to add extra lib for linker with meson, I need to add -lexecinfo to dosbox-staging build
2021-12-30 18:57:03 <psykose> the thing usually has a some_app_deps or whatever array
2021-12-30 18:58:07 <psykose> you make a execinfo_dep = cc.find_library('execinfo', required: true)
2021-12-30 18:58:13 <mps> looked this but it has only something about static libs
2021-12-30 18:58:15 <psykose> and then those_deps += [execinfo_dep]
2021-12-30 18:58:27 <psykose> if you post what project it is i can find out for you
2021-12-30 18:59:11 <mps> testing/dosbox-staging and have to upgrade it to 0.78.1
2021-12-30 18:59:20 <psykose> ah, right missed the words
2021-12-30 18:59:24 <psykose> sure, looking
2021-12-30 18:59:48 <mps> psykose: https://tpaste.us/REJ5 this is where I'm now
2021-12-30 18:59:57 <mps> APKBUILD
2021-12-30 19:04:31 <psykose> don't need static, and here https://img.ayaya.dev/hwTuPX5uKA7h
2021-12-30 19:04:40 <psykose> if you need static, add static: true as well to it with the statics
2021-12-30 19:04:45 <psykose> apkbuild same as yours
2021-12-30 19:05:36 <mps> thanks will test now
2021-12-30 19:06:06 <psykose> didn't check if runs since not sure what this is, but it builds
2021-12-30 19:06:22 <psykose> ah, seems to open too
2021-12-30 19:08:19 <mps> ok, now other bug but it passed execinfo linking
2021-12-30 19:08:28 <psykose> what now
2021-12-30 19:08:50 <mps> fluidsynth lib
2021-12-30 19:09:13 <psykose> fluidsynth-dev is in the list of your makedepends, and works for me
2021-12-30 19:09:13 <psykose> hm
2021-12-30 19:09:44 <psykose> i guess because you put -Ddefault_library=static so it needs static of everything, so it's disabled? or you mean it's a build error
2021-12-30 19:10:31 <mps> ah, probably
2021-12-30 19:12:33 <psykose> here, my final working version https://img.ayaya.dev/WjiASDkQ7j67
2021-12-30 19:12:37 <psykose> with the patch from above
2021-12-30 19:13:21 <psykose> just works on x86_64, but maybe arm has funny stuff
2021-12-30 19:19:13 <mps> will test on aarch64 and armv7 when finish with x86_64
2021-12-30 19:19:44 <mps> hm, /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/libfluidsynth.so: undefined reference to `std::__throw_bad_array_new_length()'
2021-12-30 19:19:55 <mps> will try you now
2021-12-30 19:20:00 <psykose> uhh
2021-12-30 19:20:20 <psykose> are you on 3.15
2021-12-30 19:21:56 <psykose> that looks like something you would get with 3.15 gcc/world and edge fluidsynth
2021-12-30 19:22:07 <psykose> given the 10.3 gcc in the path there
2021-12-30 19:22:34 <mps> no, I'm on edge
2021-12-30 19:23:07 <psykose> how come the gcc is not 11.2
2021-12-30 19:23:21 <mps> meh, but didn't upgraded gcc
2021-12-30 19:23:25 <mps> huh
2021-12-30 19:23:51 <psykose> give yerself an upgrade -Ua
2021-12-30 19:23:59 <psykose> maybe some world package is holding you back
2021-12-30 19:24:02 <mps> already done
2021-12-30 19:24:09 <psykose> it should be 11.2
2021-12-30 19:24:23 <psykose> and if it's held back, so it libstdc++
2021-12-30 19:24:28 <psykose> which would give you that ref error
2021-12-30 19:24:33 <mps> and it pass now :)
2021-12-30 19:24:35 <psykose> :)
2021-12-30 19:24:44 <mps> psykose: thank you for big help
2021-12-30 19:24:48 <psykose> np, glad to help
2021-12-30 19:25:22 <mps> if I know your real name I would put you in contributor field
2021-12-30 19:25:29 <psykose> my email has my name
2021-12-30 19:25:40 <mps> really, where
2021-12-30 19:25:47 <psykose> the git email on all my commits
2021-12-30 19:25:52 <psykose> my surname is cringe so i don't add that
2021-12-30 19:26:16 <mps> hmm
2021-12-30 19:27:01 <mps> ah, so I'm free to put `psykose <alice@ayaya.dev>' to contributor?
2021-12-30 19:27:06 <psykose> if you wish to :)
2021-12-30 19:27:38 <mps> I always ask first, and if you agree I will be pleased to add you
2021-12-30 19:27:43 <psykose> no issue from me
2021-12-30 19:28:10 <mps> can't you simply say yes or no :)
2021-12-30 19:28:17 <psykose> sure sure, yes :)
2021-12-30 19:28:26 <mps> thanks
2021-12-30 19:29:24 <jvoisin> psykose: get a new nickname then?
2021-12-30 19:29:52 <psykose> jvoisin: for my surname? what's the point when i can just never use it :)
2021-12-30 19:30:00 <jvoisin> :D
2021-12-30 19:53:14 <mps> psykose: !29027
2021-12-30 19:55:43 <psykose> looks good
2021-12-30 19:56:28 <mps> yes, thanks to your help
2021-12-30 19:57:09 <mps> (now is the time for red wine)
2021-12-30 19:57:20 <psykose> the reddest of red wine
2021-12-30 20:06:43 <mps> sure
2021-12-30 20:13:04 <ikke> hmm, checksum mismatches
2021-12-30 20:13:10 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/dosbox-staging/dosbox-staging-0.78.1-r0.log
2021-12-30 20:14:37 <psykose> yeah they don't match locally either
2021-12-30 20:14:38 <psykose> strange
2021-12-30 20:15:11 <psykose> but rerunning checksum does match it
2021-12-30 20:15:59 <psykose> ah, clearing cache makes it update
2021-12-30 20:16:07 <psykose> weird, why did it change between builds in under an hour
2021-12-30 20:16:19 <psykose> i was not building the wrong tarball for sure, and nothing failed anywhere
2021-12-30 20:16:19 <ikke> I suppose you do not have the old archive anymore
2021-12-30 20:16:33 <psykose> i /just/ deleted it 4 seconds ago
2021-12-30 20:16:34 <psykose> sigh
2021-12-30 20:16:35 <psykose> silly me
2021-12-30 20:16:51 <ikke> I assume you know diffoscope?
2021-12-30 20:17:04 <psykose> oh
2021-12-30 20:17:06 <psykose> they repushed
2021-12-30 20:17:11 <psykose> the tag is 12 minutes old on the repo
2021-12-30 20:17:18 <mps> ikke: yes, looking and wonder why it worked locally and on CIs
2021-12-30 20:17:27 <psykose> mps: they just updated it as soon as you merged
2021-12-30 20:17:32 <ikke> lol
2021-12-30 20:17:36 <psykose> ikke: i do not- will check it out for future reference
2021-12-30 20:17:38 <mps> uhm
2021-12-30 20:17:41 <psykose> https://github.com/dosbox-staging/dosbox-staging/tags
2021-12-30 20:17:43 <psykose> look at the date
2021-12-30 20:17:49 <ikke> ah, it's a nice tool to see differences in source archives
2021-12-30 20:18:02 <psykose> yeah, i will make sure to give it some use for this from now on
2021-12-30 20:18:06 <ikke> it's something the reproducable builds project created
2021-12-30 20:18:26 <psykose> that project does a ton of good stuff
2021-12-30 20:19:03 <ikke> So I started using that whenever upstream archives changed
2021-12-30 20:19:12 <ikke> given that once the builders built it, the archive is on distfiles
2021-12-30 20:20:10 <psykose> yeah, i'll start giving it a go when i notice discrepancies
2021-12-30 20:20:14 <psykose> !29029 should fix
2021-12-30 20:20:54 <ikke> mps: ...
2021-12-30 20:21:10 <ikke> 6f59301f54fbd1f72d1b230d287faa206ff340ad
2021-12-30 20:21:15 <psykose> haha
2021-12-30 20:21:20 <mps> hah
2021-12-30 20:21:49 <mps> https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2021-12-30 20:21:55 <ikke> It was not removed, just retagged
2021-12-30 20:22:01 <psykose> i updated mr anyway
2021-12-30 20:22:11 <skarnet> mps: people should understand that it was satire, not a HOWTO
2021-12-30 20:22:40 <skarnet> maybe we should make another video to explain this
2021-12-30 20:22:49 <mps> I'm not sure some doesn't interpret it as guide :)
2021-12-30 20:22:57 <skarnet> exactly
2021-12-30 20:23:53 <mps> but pkg is in testing so I don't much important to be fixed 'real soon now'
2021-12-30 20:24:05 <ikke> real soon is 5 seconds ago
2021-12-30 20:24:15 <psykose> real soon is i fixed it in 1 minute :p
2021-12-30 20:24:39 <psykose> if only i had 'merge access' to break more things to fix more things too
2021-12-30 20:24:42 <psykose> then i would really 'fix more'
2021-12-30 20:24:50 <psykose> ;)
2021-12-30 20:26:12 <mps> that is why I prefer to keep not 'finished' pkgs in testing
2021-12-30 22:53:39 <ikke> mps: I had disabled riscv64 for telegram-desktop, so your latest fix would do nothing
2021-12-30 22:54:59 <psykose> bypassing the maintainer to delete some todo comments is also quite poor form
2021-12-30 22:56:48 <mps> ikke: i didn't noticed
2021-12-30 22:57:42 <mps> should we reenable it to check will it build
2021-12-30 22:58:08 <psykose> it probably will
2021-12-30 22:59:44 <mps> it didn't on my riscv64 lxc because of bwrap
2021-12-30 23:00:07 <mps> bwrap: Creating new namespace failed, likely because the kernel does not support user namespaces.  bwrap must be installed setuid on such systems.
2021-12-30 23:08:45 <mps> psykose: ask TSC to remove me from alpine, you will make me a favor because this will save me some time and nerves
2021-12-30 23:15:25 <mps> heh, debian proposal on debian-security ML to change 'security claim' to 'Debian's security updates are created by volunteers working in their spare time. Some packages may receive more attention than others. ....'
2021-12-30 23:16:00 <ikke> Was there some event triggering this change?
2021-12-30 23:17:20 <mps> I didn't followed thread carefully so don't know what triggered this
2021-12-30 23:17:59 <mps> but obviously keep security 'claim' become tedious task even for them
2021-12-30 23:19:11 <mps> I follow debian-security (where I'm still subscribed) as hints to look at if we need to fix something
2021-12-31 00:58:45 <Nulo> mps, can you *please* not bypass me just to remove some comments which you said you "gave up" on
2021-12-31 00:59:12 <Nulo> _why_ https://gitlab.alpinelinux.org/alpine/aports/-/commit/fa3e9621791ce3a36ee8b2dd463f884c7ff62be4
2021-12-31 01:08:17 <Nulo> Thank you for fixing riscv64 BTW
2021-12-31 02:38:05 <q66> Ariadne: btw, since you buld d/gdc as a part of your gcc build, what do you plan to do for gcc12
2021-12-31 02:38:24 <q66> d in there is going to use a frontend written in itself, so you will need a d compiler to bootstrap it
2021-12-31 02:38:27 <q66> just like ada
2021-12-31 02:38:52 <Ariadne> probably have a gdc-bootstrap
2021-12-31 02:39:05 <Ariadne> like gnat-bootstrap :)
2021-12-31 02:39:10 <q66> sounds kinda bad to require this for something that barely anything uses
2021-12-31 02:39:41 <q66> it's already bad for ada, since barely anything uses ada either
2021-12-31 04:14:37 <Ariadne> with ada, it’s a complicated situation.  we do not package any ada software, but there are users running scientific workloads written in ada.  that’s how the ada support came to be to begin with.
2021-12-31 06:26:06 <Ariadne> (and the fortran if you were wondering)
2021-12-31 08:54:40 <mps> Nulo: there are more but please read backlog
2021-12-31 09:26:22 <z3ntu> Hi, on Alpine edge since recently if you build an empty package that does have a .post-install script, abuild will put "size = 0" instead of previously "size = 4096" into .PKGINFO of the apk file and that seems to make apk-tools not run the post-install script (found a comment somewhere that says apk-tools is considering it as virtual package with size=0)
2021-12-31 09:27:21 <z3ntu> It doesn't seem to correlate with abuild version, I have one built December 18th and one built today (both with abuild 3.9.0-r0) and they have the size difference (and the one from today doesn't get the post-install script run)
2021-12-31 09:27:57 <ikke> There was something fixed regarding that: https://gitlab.alpinelinux.org/alpine/abuild/-/commit/29557a4a5432e084207ae7f746f50be4cfd9c070
2021-12-31 09:29:14 <z3ntu> ikke: There's no actual file installed in the package so this doesn't apply. Final .apk only contains .SIGN.RSA*, .PKGINFO, .post-install and .dummy
2021-12-31 09:29:42 <z3ntu> And this was added quite a while ago, and as I mentioned the same package built from December 18th is and works fine
2021-12-31 09:29:53 <ikke> Difference maybe between coreutils du and busybox du
2021-12-31 09:30:11 <ikke> Did you add or remove that from your system?
2021-12-31 09:32:03 <z3ntu> This is both built in chroot so I doubt coreutils was installed randomly before
2021-12-31 09:32:07 <ikke> right
2021-12-31 09:32:28 <ikke> But it would have something to do with that I suppose
2021-12-31 09:42:40 <z3ntu> Ugh I don't know what's going on here.. Feel free to check these packages yourself: https://mirror.postmarketos.org/postmarketos/master/aarch64/postmarketos-ui-console-0.1-r1.apk or https://mirror.postmarketos.org/postmarketos/master/aarch64/msm-modem-7-r1.apk Both have a post-install and when rebuilding today they don't run this post-install anymore because presumably size=0 in .PKGINFO
2021-12-31 09:46:37 <ikke> z3ntu: Can you share the APKBUILD?
2021-12-31 09:47:29 <ikke> z3ntu: do you have mkdir -p "$pkgdir" in package()?
2021-12-31 09:47:35 <z3ntu> https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/postmarketos-ui-console/APKBUILD and https://gitlab.com/postmarketOS/pmaports/-/blob/master/modem/msm-modem/APKBUILD
2021-12-31 09:47:44 <ikke> yes, apparently
2021-12-31 09:48:07 <z3ntu> Also pretty sure this isn't caused by a recent pmbootstrap change, built with a version from September it's also the same behavior. I've also tried a sample apkbuild in Alpine 3.10 container (to make sure nothing got upgraded recently) and I'm also getting size=0
2021-12-31 09:50:11 <z3ntu> (sample apkbuild is the msm-modem one without subpackages and without sources set so it's easy to build)
2021-12-31 09:56:59 <z3ntu> What does `du` report in an empty directory for you? I get `0       .` in a fresh directory in my home dir
2021-12-31 09:57:55 <z3ntu> well... On my other laptop I get `4 .`. That one is ext4, the one I get 0 with is btrfs...
2021-12-31 09:58:11 <z3ntu> Is it possible that this is just broken on hosts with btrfs?
2021-12-31 09:58:56 <ikke> Yes, I think I've seen more reports about that
2021-12-31 09:59:34 <z3ntu> 🙄
2021-12-31 10:00:00 <ikke> It might even be that commit that tried to fix it
2021-12-31 10:00:31 <z3ntu> doesn't work though because post-install scripts are only copied later into that dir so it's still empty at that point
2021-12-31 10:00:42 <ikke> yeah
2021-12-31 10:00:51 <z3ntu> "If there are only empty files in the pkgdir, on some filesystems (discovered on btrfs),"
2021-12-31 10:00:56 <z3ntu> yep that was for btrfs
2021-12-31 10:02:09 <z3ntu> Fun way to spend 2 hours
2021-12-31 10:02:15 <ikke> Certainly
2021-12-31 10:04:25 <z3ntu> Also great that you can reproduce this in super old Alpine containers because it's also somehow still on btrfs then (I've used podman, not sure if it's different with docker)
2021-12-31 10:10:12 <z3ntu> Reported it as an issue now at least https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10055
2021-12-31 12:52:05 <Nulo> mps, I believe I've read the backlog, what did I miss?
2021-12-31 12:56:55 <Nulo> I don't want to remove you TSC, especially because I have no power to do that. I want to solve this situation without stepping on each other
2021-12-31 12:57:52 <Nulo> When you proposed to remove the comments, I (and other folks) generally disagreed. Instead of accepting that, you merged my changes and then removed them in an unrelated commit, I guess in hope that I wouldn't notice 
2021-12-31 13:17:51 <mps> Nulo: do you really-really think comment '# disable jemalloc' belong to APKBUILD
2021-12-31 13:19:47 <Nulo> It is relevant because the list of dependencies (the wiki page link which you deleted) had jemalloc as a dependency, but we are patching it out instead. It provides an explanation as of to why that dependency wasn't in the list.
2021-12-31 13:23:36 <mps> git commit msg servers this
2021-12-31 13:36:47 <mps> Nulo: you should follow alpine best practice and not introduce 'featurism' from other distros
2021-12-31 13:37:13 <Nulo> mps, ?
2021-12-31 13:37:15 <mps> and not only you but also other newcomers to alpine
2021-12-31 13:38:42 <Nulo> What is featurism?
2021-12-31 13:38:50 <valerius> when you try to become Debian
2021-12-31 13:39:49 <Nulo> AFAIK I'm following best practices according to CODINGSTYLE.md and the only other distro I have ever contributed to was Void
2021-12-31 13:39:54 <mps> or windows/macos even ;)
2021-12-31 13:40:25 <orbea> comments, the slipperly slope to windows....
2021-12-31 13:41:38 <valerius> some people buy the Escalade and want all the fancy features for that one trip they might or might not take one day, meanwhile they overpay for gas the entire time they own it
2021-12-31 13:41:43 <valerius> the same people choose a heavy distro
2021-12-31 13:42:36 <valerius> meanwhile, practical people choose things that do what needs to be done and nothing else
2021-12-31 13:43:02 <Nulo> We are talking about... code comments, no?
2021-12-31 13:43:14 <Nulo> To be specific, about 5 lines of comments
2021-12-31 13:43:26 <mps> Nulo: yes
2021-12-31 13:44:06 <ikke> It doesn't matter if the application wipes your harddrive, as long as there are no superfluous comments
2021-12-31 13:44:09 <mps> only important notes goes to APKBUILD comment
2021-12-31 13:45:53 <mps> and be assured that I will remove all superfluous things I see
2021-12-31 13:46:48 <skarnet> abuild is written in shell, so comments impede run-time performance!
2021-12-31 13:47:27 <mps> we made a BIG mistake with one of infra decision when accepted 'something' on which we agreed post mortem that was bad
2021-12-31 13:47:56 <skarnet> that's not what post mortem means, but I suppose you wrote it on purpose :P
2021-12-31 13:48:15 <mps> skarnet: good conclusion
2021-12-31 13:52:00 <Nulo> The wiki seems to link to no-longer-existent forums in the sidebar
2021-12-31 13:52:38 <mps> wiki should be removed as was forum long ago
2021-12-31 13:59:59 <Nulo> Whatever, I'm leaving this room for now. I don't want to deal with this bullshit
2021-12-31 14:01:21 <mps> please don't use bad words here
2021-12-31 14:10:28 <mps> nmeum: I think to add st-patched to testing with patches people asked in last few years, but I remember that you once objected to this idea. did you maybe changed mind in meantime?
2021-12-31 14:11:03 <ikke> mps: Was it worth it to scare Nulo away?
2021-12-31 14:11:27 <nmeum> I still dislike the idea of shipping this software which patches in aports there are so many different patches that people should just build it on their own if they want a custom version
2021-12-31 14:11:33 <nmeum> but that's just my personal opinion (:
2021-12-31 14:11:48 <mps> ikke: I don't have answer, and my intention is not to 'scare' anyone
2021-12-31 14:12:32 <mps> nmeum: understand, thanks
2021-12-31 14:13:02 <mps> ikke: I just want alpine to be 'small, simple, secure'
2021-12-31 14:13:52 <mps> ikke: if these are not our 'goals' anymore I can stop
2021-12-31 14:14:41 <orbea> mps: to be frank you achvieved none of those with this
2021-12-31 14:14:48 <orbea> *achieved even
2021-12-31 14:15:18 <mps> orbea: yes, I know, you are right, but I still trying :)
2021-12-31 14:16:02 <mps> 'hope dies last'
2021-12-31 14:33:24 <ikke> FYI, I'm rebooting nld5 (server with developer x86_64 containers) for upgrades
2021-12-31 14:37:15 <mps> ikke: not yet up
2021-12-31 14:37:24 <ikke> No
2021-12-31 14:37:30 <ikke> it's still rebooting
2021-12-31 14:37:56 <mps> ok, no hurry
2021-12-31 14:38:11 <ikke> I have a serial connection, so I can see what's happening
2021-12-31 14:39:04 <mps> no BMC on machine for oob access?
2021-12-31 14:39:55 <ikke> No idea, this is what we have
2021-12-31 14:42:51 <ikke> it's back
2021-12-31 14:44:05 <mps> yes, it works
2021-12-31 14:45:54 <ikke> That went smooth, luckily
2021-12-31 16:00:47 <mps> best wishes for new year to all of you
2021-12-31 16:11:05 <donoban> happy new year! :P
2021-12-31 16:19:35 <donoban> anyone using abuild rootbld? I would like to hear some comments on https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10054 
2021-12-31 16:32:08 <psykose> i think you can hack in that support by modifying abuild yourself
2021-12-31 16:32:21 <psykose> i already do to make rootbld use the apk cache instead of needing to network download every package
2021-12-31 16:32:31 <donoban> yeah I've already did
2021-12-31 16:32:35 <psykose> for the meantime :)
2021-12-31 16:32:42 <donoban> well, I fixed the apk cache with another way
2021-12-31 16:32:52 <donoban> not pushed yet
2021-12-31 16:33:34 <donoban> how did you fix psykose ?
2021-12-31 16:33:43 <donoban> s/fix/fix the apk cache?/
2021-12-31 16:33:43 <alpine-meetbot> donoban meant to say: how did you fix the apk cache? psykose ?
2021-12-31 16:34:20 <psykose> at around line 2426 where it invokes apk, just added --cache-dir=/path/to/apk/cache
2021-12-31 16:34:32 <psykose> this is not dynamically configurable and not something i mr'd of course
2021-12-31 16:34:33 <donoban> ok same than me
2021-12-31 16:34:35 <psykose> maybe i will at some point
2021-12-31 16:34:38 <donoban> well
2021-12-31 16:34:44 <donoban> I set it to /etc/apk/cache
2021-12-31 16:34:50 <donoban> which is the default host cache
2021-12-31 16:35:00 <psykose> it's the symlink to the host cache
2021-12-31 16:35:04 <psykose> so the stable version
2021-12-31 16:35:04 <donoban> just a symlink
2021-12-31 16:35:06 <psykose> yea
2021-12-31 16:35:27 <donoban> uhM, could it be problematic if host runs an stable version?
2021-12-31 16:35:57 <psykose> afaik cache is only used if package requested exists in the repo
2021-12-31 16:36:13 <psykose> if rootbld is running on edge/ repos, and the cache is all 3.15 stable packages, it will just fetch new ones
2021-12-31 16:36:33 <psykose> i did not test this however
2021-12-31 16:37:00 <psykose> and having new packages in the cache also doesn't matter for the host, as it just ignores them as they are not found in the configured 3.15 repos
2021-12-31 16:37:28 <psykose> that is how it /should/ work anyway, just something that saves the network trip and adds no other logic
2021-12-31 16:38:09 <donoban> I will try to merge it, I'm trying to fix mkusers firt
2021-12-31 16:38:11 <donoban> first*
2021-12-31 16:38:16 <psykose> i wish you luck :)
2021-12-31 16:38:41 <psykose> i think more settings in /etc/abuild.conf are fine, if you can program them in correctly
2021-12-31 16:38:46 <psykose> the default should probably be whatever it is now
2021-12-31 16:39:39 <psykose> default tmp build is not a good idea for anything large i don't think- like all the web browsers
2021-12-31 16:40:07 <psykose> and it would be annoying if the default only works for 90% of packages but someone needs to edit a file for the specific thing they are building
2021-12-31 16:40:26 <psykose> so, opt-in
2021-12-31 16:40:39 <donoban> well default tmpfs is not a good default, maybe only if it detects more than.. 16gb? of free memory
2021-12-31 16:40:50 <donoban> but it would nice to have a option for enabling it easily
2021-12-31 16:40:57 <psykose> yes, just a line in abuild
2021-12-31 16:41:04 <psykose> USE_TMPFS_ROOTBLD=yes/no
2021-12-31 16:41:07 <psykose> or 1/0, etc
2021-12-31 16:41:13 <psykose> commented out into the default list
2021-12-31 16:41:16 <donoban> the problem is that if the user has no already tmpfs /tmp, it will need to mount the abuild-Temp as tmpfs
2021-12-31 16:41:29 <psykose> afaik the default tmp is mounted tmpfs
2021-12-31 16:41:37 <donoban> i thought it also
2021-12-31 16:41:43 <donoban> but I have serious doubts
2021-12-31 16:41:44 <psykose> but yes, then it's their issue
2021-12-31 16:41:59 <donoban> here I noticed that it isn't, but it's a custom btrfs setup
2021-12-31 16:42:26 <donoban> uhM, I checked another system and yes
2021-12-31 16:42:31 <donoban> ehh
2021-12-31 16:42:34 <donoban> no
2021-12-31 16:42:35 <psykose> a comment above the use_tmpfs saying 'this makes it make the root under /tmp, make sure you have your tmp mounted as tmpfs' would be fine
2021-12-31 16:42:36 <donoban> it's /run
2021-12-31 16:42:41 <donoban> - /tmp is not tmpfs
2021-12-31 16:43:07 <donoban> yeah it's more simple and don't need root privileges
2021-12-31 18:13:58 <Ariadne> i wish we were using rootbld
2021-12-31 18:14:01 <Ariadne> for all packages
2021-12-31 18:14:05 <Ariadne> on the actual builders ;/
2021-12-31 18:15:32 <Ariadne> 7:40 AM <orbea> comments, the slipperly slope to windows....
2021-12-31 18:15:49 <psykose> there are probably like 200+ packages currently that would break without options=net
2021-12-31 18:15:49 <Ariadne> well, a hashtag # has squares in it, which is similar to windows logo
2021-12-31 18:16:03 <orbea> lol
2021-12-31 18:16:11 <psykose> i suppose enabling something like rootbld on the CI first would ease a transition
2021-12-31 18:16:27 <Ariadne> psykose: we plan to change prepare() to allow network access
2021-12-31 18:16:52 <psykose> it's a good plan, but what i mean is that those 200+ are not currently in prepare and hence broken
2021-12-31 18:17:15 <psykose> just a guesstimate anyway
2021-12-31 18:17:25 <Ariadne> i can try to do a rebuild with rootbld and see
2021-12-31 18:17:38 <psykose> that takes a long time, but yeah it's good to get a list sooner
2021-12-31 18:18:00 <psykose> is there anything other than testing this on CI first and making the rootbld() changes that is needed for the transition?
2021-12-31 18:18:15 <Ariadne> buildrepo needs to support rootbld
2021-12-31 18:18:35 <psykose> 'sounds' easier than it probably is
2021-12-31 18:24:01 <Ariadne> its easy
2021-12-31 18:24:23 <psykose> there's already a do_rootbld in buildrepo
2021-12-31 18:24:35 <Ariadne> oh
2021-12-31 18:24:41 <psykose> https://github.com/alpinelinux/lua-aports/blob/master/bin/buildrepo.lua#L102
2021-12-31 18:24:44 <Ariadne> thats new
2021-12-31 18:25:00 <psykose> -R flag
2021-12-31 18:25:09 <Ariadne> v
2021-12-31 18:25:10 <Ariadne> https://github.com/alpinelinux/lua-aports/commit/8158e71f787cd5274372992be6222e66acb13dca
2021-12-31 18:25:11 <Ariadne> oh
2021-12-31 18:25:14 <Ariadne> i did it already
2021-12-31 18:25:15 <ikke> psykose: we cannot use rootbld directly on CI
2021-12-31 18:25:17 <Ariadne> ... 4 years ago
2021-12-31 18:25:21 <psykose> ariadne...
2021-12-31 18:25:33 <psykose> ikke: how come?
2021-12-31 18:25:40 <ikke> Jobs run inside docker
2021-12-31 18:25:40 <psykose> i guess the ns requirement?
2021-12-31 18:25:41 <psykose> ah
2021-12-31 18:26:01 <ikke> And, apart from disconnecting the network, it's already a rootbld
2021-12-31 18:26:18 <psykose> yeah, the network :)
2021-12-31 18:26:31 <Ariadne> realistically
2021-12-31 18:26:34 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/33#note_200489
2021-12-31 18:26:34 <Ariadne> blanking /etc/resolv.conf
2021-12-31 18:26:38 <psykose> and i think modifying the ci to turn off network after prepare is a bit much
2021-12-31 18:26:38 <Ariadne> is probably good enough
2021-12-31 18:26:40 <ikke> Ariadne: yes
2021-12-31 18:26:42 <psykose> unless you manually run the steps
2021-12-31 18:27:15 <ikke> Not atm, but that would be how we would do it
2021-12-31 18:27:46 <psykose> if it's doing abuild -r for the jobs (didn't check) then i guess making it manually run the steps and rm resolv in the middle is basically the same
2021-12-31 18:27:53 <ikke> yes
2021-12-31 18:27:54 <ikke> it does
2021-12-31 18:28:07 <psykose> awesome
2021-12-31 18:28:10 <psykose> get to it ikke
2021-12-31 18:28:13 <ikke> You cannot remove it, but you can blank it
2021-12-31 18:28:15 <psykose> there's a few more hours until next year :)
2021-12-31 18:30:38 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L72
2021-12-31 18:51:54 <psykose> i made a scuffed version that does it, but i'm not sure how to integrate the part where abuild has different behaviour for check options or the post-build cleanup
2021-12-31 18:52:45 <psykose> just 'abuild' runs extra things that are not part of any provided arguments, so it seems hard to duplicate that
2021-12-31 18:52:49 <ikke> network should be re-enabled again after build
2021-12-31 18:53:01 <ikke> psykose: rootpkg index
2021-12-31 18:53:06 <psykose> not those
2021-12-31 18:53:10 <ikke> Which?
2021-12-31 18:53:39 <ikke> fetch deps unpack prepare build check rootpkg index
2021-12-31 18:53:43 <ikke> should be complete
2021-12-31 18:53:46 <ikke> iirc
2021-12-31 18:53:47 <psykose> build_abuildrepo calls cleanup $CLEANUP
2021-12-31 18:53:51 <psykose> and has a _check
2021-12-31 18:54:07 <psykose> unless i am being silly and just abuild cleanup does that
2021-12-31 18:54:46 <psykose> no, cleanup would need the arg parsed from $CLEANUP yourself, hm
2021-12-31 18:56:15 <ikke> Hmm, not sure if that's so important in CI
2021-12-31 18:56:29 <psykose> perhaps not, but it's a change from current behaviour
2021-12-31 18:56:32 <ikke> nod
2021-12-31 18:56:57 <ikke> $CLEANUP comes from abuild.in, which is already sourced
2021-12-31 18:57:06 <ikke> I mean /etc/abuild.conf
2021-12-31 18:57:27 <ikke> I have to go now
2021-12-31 18:58:21 <psykose> ah, if it's available then that's easy
2021-12-31 18:58:23 <psykose> enjoy your dinner
2021-12-31 18:58:49 <psykose> just the _check options left
2021-12-31 19:00:59 <psykose> https://img.ayaya.dev/DdO95o5xjwhY this is most of it, that i haven't tested
2021-12-31 19:29:20 <boomanaiden154> Does anyone know how to get the alpine images updated on dockerhub? I just ran into an issue using the alpine:edge image because the musl packaged with the image is two releases behind and doesn't have the qsort_r patch.
2021-12-31 19:29:57 <psykose> can you not just run an upgrade in the image
2021-12-31 19:30:18 <psykose> that's what i always did and it just works, i dunno
2021-12-31 19:32:19 <boomanaiden154> I can and that’s what I’m going to do in my future image builds, but it would be nice if the image contained the latest software.
2021-12-31 19:36:43 <boomanaiden154> Having to upgrade the pre installed software adds another layer to the image which is undesirable.
2021-12-31 19:57:50 <Hello71> yes, we should make a new image
2021-12-31 20:01:49 <Ariadne> we should honestly just publish our own images
2021-12-31 20:01:55 <Ariadne> on our own container registry
2021-12-31 20:02:10 <Ariadne> the docker official images registry is such a shitshow, the more i have found out about it, the less i like
2021-12-31 20:03:09 <Ariadne> im pretty sure the reason docker hasn't signed any of the images in like 2 years now
2021-12-31 20:03:17 <Ariadne> is because the employee who was doing it walked out the door
2021-12-31 20:03:25 <Ariadne> and took the keys with him
2021-12-31 20:03:37 <Ariadne> and they dont want to admit they dont control the docker notary key anymore
2021-12-31 20:05:20 <Ariadne> we have gitlab, which has container registry stuff in it
2021-12-31 20:05:25 <Ariadne> it should be easy to do i guess
2021-12-31 20:08:03 <ikke> Yes, though we do need to think about storage 
2021-12-31 20:09:24 <Ariadne> (obviously we would want to keep the docker library stuff for a while as to not break anyone's workflow, but i think we are better off owning our own distribution channel for the docker image, given the docker official one is... not great)
2021-12-31 20:12:13 <ikke> The alpine image itself is not so big, so that should bit be an issue to self-host 
2021-12-31 20:17:58 <Ariadne> i'll open a TSC issue i guess
2021-12-31 20:18:07 <Ariadne> i think we should do this, given the situation with image signing
2021-12-31 20:18:36 <Ariadne> the docker image should meet our baseline requirements there, and if docker isn't signing it, it is worse than minirootfs on its own which *is* signed
2021-12-31 20:31:17 <Hello71> but also as a general principle container image source diversification is good
2021-12-31 20:31:30 <Hello71> why should the signature chain go to docker if alpine is providing all the code anyways
2021-12-31 20:32:23 <Hello71> also we can take some load off of docker servers, since apparently they have such tremendous server load that they need to charge for access
2021-12-31 20:32:47 <Hello71> (something tells me that alpine will not need to charge for access)
2021-12-31 20:34:57 <Ariadne> yes, i agree with that as well re: why is docker signing our images anyway
2021-12-31 20:35:06 <Ariadne> the answer is because we cannot sign them ourselves
2021-12-31 20:35:26 <Ariadne> that's what sigstore is about in kubernetes-land, fixing the totally broken docker notary stuff
2021-12-31 20:35:45 <Ariadne> (the fact that our images are not signed with sigstore is also a real bummer for k8s people)
2021-12-31 20:35:47 <Hello71> but is (or was) docker actually doing any verification of the images before signing them
2021-12-31 20:36:03 <Ariadne> no
2021-12-31 20:36:15 <Ariadne> i want to change the dockerfile to verify the minirootfs sig
2021-12-31 20:38:05 <Ariadne> Hello71: anyway feel free to supplement those points on https://gitlab.alpinelinux.org/alpine/tsc/-/issues/34 :)
2021-12-31 20:41:14 <Ariadne> and yes, i think that infra is no problem.  alpine has lots of sponsors that could easily take care of the infra :P
2021-12-31 20:41:23 <Ariadne> we just gotta figure out the logistics
2021-12-31 20:42:49 <Hello71> what would that look like for users? will they be able to do docker run alpinelinux.org/alpine? what kind of infra does that need? is it like curl https://alpinelinux.org/.well-known/docker/alpine and then that can HTTP redirect somewhere?
2021-12-31 20:43:10 <psykose> it's just a specific container http/whatever thing at that endpoint
2021-12-31 20:43:13 <psykose> afaik it is very easy to set up
2021-12-31 20:44:18 <Hello71> it seems like it does curl https://something/v2/alpine. i can't figure out what the something is, but if it's literally alpinelinux.org then that seems... poorly namespaced
2021-12-31 20:44:44 <Ariadne> Hello71: i think it would be "docker run registry.alpinelinux.org/alpine:latest"
2021-12-31 20:44:46 <Ariadne> or so
2021-12-31 20:45:35 <psykose> yep, the default docker tags you see e.g. 'alpine:latest' just imply the default docker path prefixed, but different runtimes e.g. podman don't even have that in the default search path so you need the full one or to add paths to the list
2021-12-31 20:46:26 <psykose> deploying a 'registry' for docker is documented somewhat here https://docs.docker.com/registry/deploying/ and the thing under the hood it runs is https://github.com/distribution/distribution/tree/main/registry
2021-12-31 20:46:40 <psykose> gitlab does some other stuff probably, and goes through whatever that does instead
2021-12-31 20:47:29 <Ariadne> (it doesn't have to be gitlab, i just suggested it because i guess it would be easy)
2021-12-31 20:47:44 <psykose> of course! but i do think gitlab is the easiest solution already if the disk has enough space
2021-12-31 20:48:05 <Hello71> right, i saw that already, but it doesn't seem to answer how i can make it so i don't have to type :5000
2021-12-31 20:48:12 <psykose> a new image per alpine release + maybe a weekly auto-edge is quite light on space
2021-12-31 20:48:58 <psykose> Hello71: type it in where? the sample docker instructions let you pass REGISTRY_HTTP_ADDR with the port on normal http it seems
2021-12-31 20:51:27 <psykose> even if you couldn't it sounds like the usual service you can throw behind a reverse proxy and just forward 443 to what it's running on
2021-12-31 20:52:25 <Ariadne> usually you want to reverse proxy stuff like this anyway
2021-12-31 20:52:38 <psykose> mmhmm
2021-12-31 20:54:07 <psykose> ah, it seems gitlab is using that same distribution/distribution/registry thing under the hood
2021-12-31 20:54:37 <Ariadne> anyway, point being basically that alpine community does not gain anything helpful from docker being a middleman here
2021-12-31 20:54:40 <Hello71> right but like if i want to use alpinelinux.org/alpine then does it occupy all of https://alpinelinux.org/v2/
2021-12-31 20:56:17 <psykose> i think it would be bad to mix it like that yeah
2021-12-31 20:56:24 <psykose> so we could do containers.alpinelinux.org
2021-12-31 21:02:51 <minimal> I think pretty much ever docker registry solution has the docker one under the hood (i.e. Harbor is based around it).
2021-12-31 21:02:57 <minimal> s/ever/every/
2021-12-31 21:02:57 <alpine-meetbot> minimal meant to say: I think pretty much every docker registry solution has the docker one under the hood (i.e. Harbor is based around it).
2021-12-31 21:03:23 <psykose> i couldn't even really find an alternative implementation
2021-12-31 21:03:43 <psykose> every website for all of them is corporate bait and at best has a zip you download and throw in, no git anywhere
2021-12-31 21:03:46 <psykose> in 10 minutes anyway
2021-12-31 21:04:33 <boomanaiden154> What about quay?
2021-12-31 21:04:43 <boomanaiden154> https://projectquay.io
2021-12-31 21:05:15 <psykose> ah, seems i missed it
2021-12-31 21:05:58 <psykose> well, that's two options
2021-12-31 21:07:00 <psykose> for just hosting some alpine images i would probably prefer the docker one as it's just a go binary you run instead of a bunch of python and features that aren't useful for such a tiny host
2021-12-31 21:08:14 <minimal> whilst development of the docker registry "distribution" sort of bumpstarted again 1 year ago with more maintainers they still haven't had a release in 3 years
2021-12-31 21:09:08 <psykose> seems about par for container land
2021-12-31 21:09:17 <minimal> a year ago they brought in maintainers other that Docker: https://github.com/distribution/distribution/commit/d11c4f9adea598f4288b9d880efa5c5044d6a2bb
2021-12-31 21:09:35 <minimal> "Maintainers from Docker, GitHub, GitLab, Digital Ocean, Harbor."
2021-12-31 21:10:23 <minimal> I'm fairly sure Azure and AWS also use it as the base for their stuff - its basically a monoculture
2021-12-31 21:15:04 <boomanaiden154> psykose: Using the docker image registry for the short term would probably be fine but using something like Quay or Harbor that supports HA and scalability would probably be better for the long term.
2021-12-31 21:15:53 <psykose> HA and scalability for like the 15 alpine image tags?
2021-12-31 21:16:36 <Hello71> we need to use mongodb
2021-12-31 21:16:50 <minimal> because its webscale :-)
2021-12-31 21:16:51 <psykose> it's one per release, and an edge one rolled every interval
2021-12-31 21:17:41 <boomanaiden154> psykose: Scalability might not be necessary, I’m not too familiar with how many images would be downloaded per time interval. HA wouldn’t be a bad idea in either case.
2021-12-31 21:18:33 <psykose> it's probably a lot of images network traffic wise
2021-12-31 21:19:33 <boomanaiden154> And in terms of building images, it would probably be best to build a new image everytime a package included in the image gets updated (should only be an issue for the edge images), but I’m not sure how feasible that is.
2021-12-31 21:20:37 <psykose> that would be 10-100+ image builds a day for next to no reason
2021-12-31 21:20:47 <psykose> ah, a package in the base image
2021-12-31 21:20:55 <psykose> sure, that is quite rare, as the base image has next to nothing
2021-12-31 21:21:15 <boomanaiden154> Yes. And it would ensure that the image is always up to date.
2021-12-31 21:21:30 <boomanaiden154> Definitely no reason to rebuild for every package in edge.
2021-12-31 21:22:38 <psykose> agree
2021-12-31 21:23:10 <minimal> Isn't the base image basially a repacking of minirootfs, so that'd be built how often? daily? weekly?
2021-12-31 21:23:41 <boomanaiden154> In terms of selecting an image registry, having the option to scale in the future is also never a bad thing.
2021-12-31 21:31:15 <ikke> minimal: only when releases are tagged