2021-11-01 06:44:55 <ncopa> good morning
2021-11-01 06:46:30 <mps> good morning
2021-11-01 07:17:41 <Danct12> good morning ncopa 
2021-11-01 07:17:49 <Danct12> long time no see, :)
2021-11-01 07:29:21 <fcolista>   'MORNING
2021-11-01 07:29:37 <fcolista> *morning :) stupid CAPS :D
2021-11-01 07:30:17 <mps> Bodhidarma finally got name in linux ecosystem though by his Chinese name https://github.com/awslabs/damo :)
2021-11-01 07:32:04 <mps> but it is written in python so I wait some time for someone with experience in python to package it for alpine
2021-11-01 08:20:15 <ikke> good morning
2021-11-01 09:03:30 <mps> new long term stable kernel is declared https://www.kernel.org/category/releases.html
2021-11-01 09:03:36 <mps> ncopa: ^
2021-11-01 09:04:25 <mps> heh, I had a hope that will be 5.16
2021-11-01 09:05:34 <psykose> hm, why does this one have a shorter eol than the previous ones
2021-11-01 09:06:03 <psykose> guess they got tired of 6 year eol's :p
2021-11-01 09:06:47 <mps> my guess is it will be replaced with 5.16
2021-11-01 09:07:04 <mps> lets see in two months
2021-11-01 09:07:22 <psykose> ah, perhaps
2021-11-01 09:07:37 <mps> 5.16 will have futex2
2021-11-01 09:07:45 <ikke> The current LTS was prolonged as well
2021-11-01 09:08:09 <psykose> the new ntfs3 should probably be enabled
2021-11-01 09:09:07 <mps> mandatory locking will be 'removed' in 5.16 which is quite good
2021-11-01 09:09:31 <mps> psykose: yes, and ksmbd
2021-11-01 09:09:38 <mps> and damon
2021-11-01 09:09:41 <psykose> mhm
2021-11-01 09:09:49 <mps> and a lot of new 'things'
2021-11-01 09:10:30 <mps> and *finally* rpi flavors should be removed
2021-11-01 09:10:50 <psykose> PREEMPT_RT is mainline now it seems
2021-11-01 09:10:58 <psykose> could replace -rpi with a new -rt flavor :p
2021-11-01 09:11:12 <mps> psykose: yes, but not yet fully ready to be used
2021-11-01 09:11:18 <psykose> albeit it seems like a lot of work
2021-11-01 09:11:20 <psykose> yes
2021-11-01 09:11:21 <ncopa> mps: wow. I checked earlier today. I will try upgrade to 5.15
2021-11-01 09:12:22 <mps> ncopa: also I will upgrade linux-edge, but first on my machines to test possible serious bugs
2021-11-01 09:12:38 <ncopa> good
2021-11-01 09:13:07 <mps> hope to finish all this evening
2021-11-01 09:18:50 <mps> uh, openssl deps again :)
2021-11-01 09:18:54 <ikke> ncopa: regarding ghc, the next step is to build it against system ffi again? One thing I noticed when rebuilding some packages (alex, happy), is that after rebuild they no longer depend on libffi.so*
2021-11-01 09:25:11 <ncopa> ikke: that was the plan yes
2021-11-01 09:25:25 <ncopa> maybe we dont need use system libffi?
2021-11-01 09:25:41 <ncopa> trying to build alex here, but testsuite fails
2021-11-01 09:27:04 <ikke> there is an upstream patch
2021-11-01 09:28:54 <ncopa> oh, cool
2021-11-01 09:30:09 <mps> aieee, ECDSA (MODULE_SIG_KEY_TYPE_ECDSA) (NEW) in kernel, sign modules with ecdsa instead of rsa \o/
2021-11-01 09:30:11 <Ariadne> mps: openssl transition for cmd:openssl/openssl-dev will be done today.
2021-11-01 09:30:34 <mps> Ariadne: np, I just forgot to change makedeps
2021-11-01 09:30:35 <Ariadne> mps: not \o/, afaik the ECDSA supported are backdoored
2021-11-01 09:30:46 <Ariadne> e.g. sec256p1
2021-11-01 09:30:47 <ikke> ncopa: https://gitlab.alpinelinux.org/kdaudt/aports/-/compare/master...remove-libffi3.3-compat?from_project_id=1
2021-11-01 09:31:52 <mps> Ariadne: omg
2021-11-01 09:31:54 <ncopa> I think it should be enough with adding --with-system-libffi and add libffi-dev to makedepends_buil
2021-11-01 09:32:15 <psykose> wonder why they didn't jump straight to ed25519
2021-11-01 09:33:03 <mps> yes, that would be better
2021-11-01 09:33:34 <Ariadne> oh, it's secp384r1
2021-11-01 09:33:44 <Ariadne> well that one is probably owned too
2021-11-01 09:33:47 <Ariadne> it came from NSA
2021-11-01 09:37:34 <Ariadne> yeah secp384r1 is owned, according to djb
2021-11-01 09:37:40 <Ariadne> https://safecurves.cr.yp.to/
2021-11-01 09:38:40 <mps> just wanted to say 'safe bet' :)
2021-11-01 09:39:42 <mps> anything from TLAs is suspicious at least
2021-11-01 12:34:42 <omni> "though it is pluggable and permits others to be used"?
2021-11-01 12:35:34 <Ariadne> ?
2021-11-01 12:35:41 <Ariadne> though what is pluggable
2021-11-01 12:41:38 <donoban> Ariadne: do you really believe secp256k1 is backdoored? There was some post on bitcointalk about that the https://safecurves.cr.yp.to/ reults
2021-11-01 12:42:12 <Ariadne> i was talking about the nist p-256
2021-11-01 12:42:14 <Ariadne> not the bitcoin one
2021-11-01 12:42:29 <Ariadne> i have no opinion / don't care about the bitcoin one
2021-11-01 12:42:30 <donoban> ahh sorry
2021-11-01 12:42:36 <donoban> ok
2021-11-01 12:59:46 <minimal> mps: re: "and *finally* rpi flavors should be removed", unfortunately not - the mainline kernel does not support overlays which RPI needs and, I don't know why, it seems there is no wish or attempt for overlay support to be added to mainline kernel
2021-11-01 13:03:00 <Ariadne> what is 'overlay' here?
2021-11-01 13:03:29 <Ariadne> minimal: ?
2021-11-01 13:03:30 <psykose> i would guess devicetree overlays
2021-11-01 13:04:53 <minimal> sorry, yes device tree overlays - for loading the various files in /boot/overlays/*.dtbo that support both official and 3rd party RPI addon hardware
2021-11-01 13:06:34 <Ariadne> shouldn't u-boot handle combining those
2021-11-01 13:07:20 <minimal> Ariadne: RPI does use u-boot, it has its own bootloader (though you could chainload u-boot or, on RPI4, reflash bootloader with u-boot)
2021-11-01 13:07:25 <minimal> s/does/doesn't/
2021-11-01 13:07:49 <Ariadne> yes, what i am saying is, i think a proposal to remove rpi-specific kernels, would involve chainloading into a more capable bootloader
2021-11-01 13:08:38 <minimal> Ariadne: and can u-boot then handle these DTBO files, and provide a means to enable/disable individual ones?
2021-11-01 13:09:10 <Ariadne> i have no idea, but i would assume so
2021-11-01 13:09:50 <Ariadne> https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html#ways-to-utilize-overlays-in-u-boot
2021-11-01 13:09:51 <Ariadne> yes
2021-11-01 13:10:50 <Ariadne> but shouldn't the rpi bootloader flatten the overlays, too?
2021-11-01 13:10:57 <minimal> flatten?
2021-11-01 13:11:09 <Ariadne> combine base FT + overlays into a finalized DT
2021-11-01 13:11:28 <Ariadne> s/FT/DT/
2021-11-01 13:12:04 <mps> Ariadne: you are right
2021-11-01 13:12:40 <minimal> noep, with standard bootloader you edit the text file config.txt (on a FAT partition) and add "dtoverlay=" lines to load individual overlays and add "dtparam=" lines to pass config setting to overlays
2021-11-01 13:13:03 <mps> minimal: that could be done also in u-boot
2021-11-01 13:13:24 <minimal> so for example to use the 3rd party RTC I have I add the following to config.txt: "dtoverlay=i2c-rtc,ds1307"
2021-11-01 13:13:30 <mps> all other SBCs does this
2021-11-01 13:15:10 <minimal> the other issue with RPI is that mainline lags in support RPI changes, whether for new stuff or old stuff, and often mainline is broken at times with regard to some RPI functionality.
2021-11-01 13:15:55 <mps> 'we' lag in more than this
2021-11-01 13:16:03 <mps> why is RPi special
2021-11-01 13:17:01 <mps> (I don't care though, if ncopa likes to make upgrades and fixes for these devices I don't care)
2021-11-01 13:18:12 <minimal> mps: For example currently linux-lts is 5.10.76, linux-rpi is 5.10.64. Mainline 5.10.76 does not work correctly for RPI without a fair bit of patching AFAIK
2021-11-01 13:19:07 <psykose> are the patches for regressions? how do other sbcs fare with this
2021-11-01 13:19:22 <mps> minimal: well, I didn't tested rpi zero in last 6 months but last time I tested it it worked with mainline
2021-11-01 13:19:54 <minimal> mps: RPI is "special" because RPI Foundation do their own thing in their own (lagging) fork of kernel at https://github.com/raspberrypi/linux
2021-11-01 13:20:24 <mps> 
ACTION wonders why do we have to care for this

2021-11-01 13:21:06 <minimal> mps: well Alpine doesn't have to care if it doesn't care about having functional RPI support.
2021-11-01 13:21:09 <Ariadne> i have no objection to rpi kernels sticking around, but i think that it would be better if they were "owned" by an rpi-specific team
2021-11-01 13:21:32 <minimal> Ariadne: agreed
2021-11-01 13:21:56 <Ariadne> i'm also kind of anxious about security support for them for the same reason -- what rpi linux kernels are shipping for X version is not the same as mainline
2021-11-01 13:22:02 <mps> most of things are already upstreamed
2021-11-01 13:22:02 <Ariadne> so, it is kind of a mess
2021-11-01 13:22:11 <Ariadne> really, i would prefer to see rpi kernels be in community :)
2021-11-01 13:22:28 <Ariadne> i would also like to see us use akms for out-of-tree modules
2021-11-01 13:22:29 <minimal> mps: some of the recent upstreaming of RPI stuff didn't work correctly
2021-11-01 13:22:30 <mps> testing :)
2021-11-01 13:23:13 <minimal> I'd love to be able to use a mainline kernel for RPI but it seems like proper and complete mainline support is some way off
2021-11-01 13:23:17 <mps> minimal: a lot of things in mainline doesn't work correctly
2021-11-01 13:23:46 <psykose> on rpi4 you can use mainline fine with rpi4-uefi :) hehe
2021-11-01 13:24:03 <Ariadne> i think we need to also overhaul kernel configurations
2021-11-01 13:24:04 <mps> I'm 'wrestling' nearly every day with some bugs in kernels
2021-11-01 13:24:14 <Ariadne> the way kernel options are set in -rpi are better
2021-11-01 13:24:24 <Ariadne> we should just specify deviations from base
2021-11-01 13:25:12 <minimal> mps: if you look at https://github.com/raspberrypi/linux/commits/rpi-5.15.y you can see the changes RPI Foundation are making to their fork of 5.15.x to make it work for RPI
2021-11-01 13:26:37 <minimal> Ariadne: agree about kernel config overhaul. As I mentioned to mp recently, once 5.15 is out I intend to raise either with TSC or via an Issue some changes to linux-virt config to "slimline" it for VM use
2021-11-01 13:26:54 <mps> minimal: I don't use rpis because I dislike their decision to use broadcom
2021-11-01 13:27:25 <mps> minimal: raise whatever you want but don't mention linux-edge there
2021-11-01 13:27:33 <minimal> psykose: isn't rpi4-uefi still in-development, i.e. not guaranteed to be stable. Also that doesn't address all other pre-RPI4 devices
2021-11-01 13:27:38 <psykose> i am not sure what what you use has to do with supporting rpi
2021-11-01 13:27:50 <psykose> minimal: i know :) just poking fun, and most people haven't heard of it
2021-11-01 13:27:56 <psykose> also fwiw i have had no issues with it
2021-11-01 13:28:18 <Ariadne> mps: same, i use other SBCs
2021-11-01 13:28:28 <Ariadne> mostly odroid
2021-11-01 13:29:57 <Ariadne> i have several odroid-c4 as serial console servers :)
2021-11-01 13:30:08 <minimal> Ariadne: I'm happy to be a member of an RPI team if one is set up
2021-11-01 13:31:55 <mps> anyway, 5.15 works on my 3 boxes, armv7, aarch64 and x86_64
2021-11-01 13:34:27 <mps> and with new and shiny xorg ;)
2021-11-01 13:37:35 <minimal> mps: "raise whatever you want but don't mention linux-edge there" - many of the config changes I'd be recommending for linux-virt are changes you have already made in linux-edge-virt so a bit hard not to mention linux-edge-virt for comparison purposes
2021-11-01 13:48:22 <mps> minimal: aha, ok then. I meant to say don't ask TSC how to configure linux-edge
2021-11-01 13:48:42 <mps> we have kernel team, ask them about linux-edge
2021-11-01 13:49:51 <minimal> mps: where is kernel team? I see no group in https://gitlab.alpinelinux.org/alpine
2021-11-01 13:50:55 <mps> https://gitlab.alpinelinux.org/team
2021-11-01 13:51:20 <mps> https://gitlab.alpinelinux.org/team/kernel
2021-11-01 13:55:25 <Ariadne> yes, i think escalation to TSC is not really needed for this.  only reason why the sudo -> doas transition was done that way is because some people are going to complain about it
2021-11-01 13:56:09 <mps> btw, nmeum already opened issue about kernel config consolidation
2021-11-01 13:56:49 <minimal> forgot about teams, find the "group" and "team" distinction in Gitlab confusing
2021-11-01 13:57:15 <Ariadne> as the change is self-contained to the kernel packages in this case, i think basically the kernel team can make the decision, and if necessary, do the full system change process
2021-11-01 13:57:23 <Ariadne> though, i don't think it would be necessary :)
2021-11-01 13:57:32 <minimal> Ariadne: agreed
2021-11-01 13:57:42 <nmeum> mps: issue id?
2021-11-01 13:57:49 <ikke> minimal: you don't really have teams in gitlab
2021-11-01 13:57:57 <mps> nmeum: if I could find it
2021-11-01 13:57:59 <ikke> we just decides to have dedicated 'team' groups
2021-11-01 13:58:13 <nmeum> mps: :D
2021-11-01 13:58:41 <Ariadne> by the way, it is my intention to go to GCC 11 for alpine 3.16
2021-11-01 13:58:45 <mps> #12933
2021-11-01 13:59:04 <mps> nmeum: ^ :)
2021-11-01 13:59:31 <nmeum> aahhhh
2021-11-01 13:59:45 <nmeum> I remember now
2021-11-01 14:02:44 <mps> anyway. linux-edge 5.15.0 is on builders for brave ones to test it when it is uploaded
2021-11-01 14:06:16 <minimal> mps: ready and waiting for it :-)
2021-11-01 14:08:20 <mps> minimal: expeting your reports and ideas
2021-11-01 14:09:37 <minimal> mps: they will virtually be with you soon ;-) you saw the MR I raised to address Grub issue with linux-edge-virt? !26977
2021-11-01 14:10:57 <mps> minimal: I wanted to approve MR but forgot, sorry
2021-11-01 14:11:30 <minimal> mps: no rush, it only affects Edge
2021-11-01 14:12:04 <mps> you tested it with lts and edge-virt?
2021-11-01 14:30:51 <mps> minimal: only objection for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26977/diffs#diff-content-9b54de20eee373046d1b79b9ddac81b6976023a0 is that I think text is too long
2021-11-01 14:31:10 <mps> I don't think that need so long explanation
2021-11-01 14:31:33 <mps> imo, subject line is enough
2021-11-01 14:32:20 <psykose> the explanation seems fine to me
2021-11-01 14:32:26 <psykose> or at least i wish more things had things written like this
2021-11-01 14:32:36 <minimal> mps: tested lts, virt, edge, and edge-virt
2021-11-01 14:32:50 <mps> minimal: I approved it
2021-11-01 14:33:11 <minimal> mps: thanks
2021-11-01 14:33:13 <mps> psykose: I think I have right to express my opinion
2021-11-01 14:33:24 <psykose> as do i? where did i say you don't
2021-11-01 14:33:36 <mps> psykose: yes, agree
2021-11-01 14:34:11 <mps> (who reads looooong texts nowadays :) )
2021-11-01 14:34:21 <psykose> me
2021-11-01 14:34:52 <minimal> mps: people trying to figure out why a 1 line change made 5 years ago suddenly means stuff breaks today :-)
2021-11-01 14:51:55 <ncopa> ha... i was kinda expecting our scripts to break when i saw the name linux-edge-virt
2021-11-01 14:52:24 <ncopa> would probably make sense to rename it to linux-edgevirt
2021-11-01 14:54:12 <Ariadne> yes, likely other edge cases exist
2021-11-01 14:55:25 <mps> hmm, what about linux-virtual or linux-4virt
2021-11-01 14:55:44 <mps> linux-4vm
2021-11-01 14:56:06 <psykose> virtual for edge but virt for lts? how do you differentiate the two
2021-11-01 14:56:16 <ncopa> exactly
2021-11-01 14:56:24 <psykose> edgevirt is the clearest so far
2021-11-01 14:56:49 <ncopa> linux-edge4vm or linux-edge4virt would work as well
2021-11-01 14:56:53 <psykose> wyep
2021-11-01 14:57:47 <mps> makes sense
2021-11-01 15:03:28 <Ariadne> in other news,
2021-11-01 15:03:42 <Ariadne> openrc /sbin/runscript and minicom /usr/bin/runscript
2021-11-01 15:04:30 <Ariadne> i suggest that minicom needs to use a different name for runscript for now.
2021-11-01 15:04:38 <Ariadne> while we transition to /sbin/openrc-run
2021-11-01 15:05:38 <ncopa> wasnt openrc's runscript renamed to openrc-run?
2021-11-01 15:08:07 <Ariadne> yes
2021-11-01 15:08:13 <Ariadne> but i am sure we have initscripts
2021-11-01 15:08:16 <Ariadne> that depend on runscript
2021-11-01 15:08:25 <Ariadne> the alternative is we fix the init scripts
2021-11-01 15:08:28 <Ariadne> and rebuild i guess
2021-11-01 15:08:29 <Ariadne> :)
2021-11-01 15:09:22 <psykose> there is one thing in community with /sbin/runscript in an init.d, uptimed
2021-11-01 15:09:29 <psykose> the rest is unmaintained/nonfree it seems
2021-11-01 15:09:58 <ncopa> i think we should fix the packages still using sbin/runscript. it was renamed many years ago
2021-11-01 15:11:39 <psykose> community: uptimed non-free: 3dm2 unmaintained: dspam, opensips, rrdbotd
2021-11-01 15:11:56 <Ariadne> okay
2021-11-01 15:12:08 <Ariadne> can somebody work on MRs for that, and then we can nuke runscript from openrc :)
2021-11-01 15:12:16 <Ariadne> we should probably also put this in release notes
2021-11-01 15:12:30 <psykose> all 5 or just the two maintained
2021-11-01 15:12:38 <Ariadne> just the two
2021-11-01 15:13:24 <Ariadne> though alint should check for this i think
2021-11-01 15:13:26 <Ariadne> :)
2021-11-01 15:17:11 <psykose> !27036
2021-11-01 15:20:49 <psykose> oh right, checksums :)
2021-11-01 15:22:00 <psykose> and the 3dm2 archive is 404 now
2021-11-01 15:26:31 <psykose> i can't actually find the 3dm2 archive anywhere, what should be done about it
2021-11-01 15:30:36 <Ariadne> move it to unmaintained i guess
2021-11-01 15:30:44 <Ariadne> 3dm2 isn’t really relevant anymore
2021-11-01 15:31:00 <Ariadne> 3ware has been out of business for over a decade now
2021-11-01 15:37:45 <psykose> perhaps it should be removed outright then?
2021-11-01 15:38:17 <Ariadne> sure why not
2021-11-01 15:41:21 <mps> there are more candidates for removal
2021-11-01 15:41:40 <psykose> i can throw them all into one mr if you wish
2021-11-01 15:42:06 <mps> :)
2021-11-01 15:42:22 <mps> we usually ask maintainers first
2021-11-01 15:42:46 <psykose> of course :)
2021-11-01 15:43:14 <Ariadne> pulseaudio
2021-11-01 15:43:17 <Ariadne> ncurses
2021-11-01 15:43:23 <Ariadne> etc :)
2021-11-01 15:44:40 <mps> .............. long list :D
2021-11-01 15:53:47 <mps> heh, 'trojan' code in comments, https://www.trojansource.codes/
2021-11-01 16:30:54 <Danct12> can anyone look into these mrs?
2021-11-01 16:31:12 <Danct12> !27038 !27039 !27044
2021-11-01 20:47:23 <nicholas01> downloaded latest alpine but the kernel is only showing v. 5.10 ? Any way to get the latest kernel? (5.15)
2021-11-01 20:50:39 <ikke> grep linux /etc/apk/world
2021-11-01 20:53:28 <nicholas01> i guess i change it to linux-edge then and update
2021-11-01 20:53:31 <omni> nicholas01: perhaps you're looking for linux-edge?
2021-11-01 20:53:36 <omni> right :D
2021-11-01 20:54:04 <nicholas01> omni:  thanks
2021-11-01 22:26:56 <andypost[m]> rust anounced https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html
2021-11-01 22:27:27 <andypost[m]> how to deal with 3.15 - upgrade or try to patch?
2021-11-01 22:33:11 <ericonr> that's arguably irrelevant as an issue imo :P
2021-11-01 22:59:10 <Ariadne> andypost[m]: security NAK
2021-11-01 22:59:19 <Ariadne> andypost[m]: this is not a valid security issue
2021-11-01 22:59:24 <Ariadne> andypost[m]: we will ignore it
2021-11-01 23:00:16 <Ariadne> also, do not upgrade to 1.56.1 unless, and until, it is known to still work with hebrew and arabic comments which use RTL legitimately
2021-11-01 23:04:37 <ericonr> Ariadne: oh lol they jumped the gun on that?
2021-11-01 23:04:48 <ericonr> amazing
2021-11-01 23:05:03 <Ariadne> i have opinions
2021-11-01 23:06:14 <Ariadne> but i don't think it's cool that somebody gets a CVE about "lol i can turn your source code into Zalgo with UTF-8", and then a traditionally underserved population (RTL script users) get thrown under the bus
2021-11-01 23:06:44 <Ariadne> i am not interested in throwing RTL script users on alpine under the bus
2021-11-01 23:07:05 <Ariadne> over "shit i used to do in 2004 to troll IRC friends" being turned into a 2021 CVE
2021-11-01 23:20:05 <fluix> IIRC I think I read somewhere that the check is that both the start and end RTL characters are in the same comment
2021-11-01 23:20:23 <fluix> not for Rust specifically, but as a fix for this CVE
2021-11-02 00:57:10 <ngortheone> Hello folks, I just found out that Gentoo decided to abandon eudev (src: https://github.com/eudev-project/eudev) and " and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors"
2021-11-02 00:57:44 <ngortheone> Where can I find more info on the topic? What is going to be a replacement?
2021-11-02 01:18:04 <valerius> I think libudev-zero was being pitched, but don't quote me on it
2021-11-02 01:38:13 <craftyguy> has 3.15 branched? i.e. will packages added to community now make it in 3.15?
2021-11-02 03:37:41 <dalias> fluix, it's really a CVE in editors/viewers that display text in misleading ways
2021-11-02 03:39:43 <dalias> ariadne, i'm not clear on whether actual RTL users are affected or whether it's purely abuse of the RTL/LTR override stuff that probably should not have existed as unicode characters
2021-11-02 03:40:37 <dalias> unless you have nested quotations, bidi just works naturally with no embeds or overrides. embeds are necessary for nested quoting, but i don't think overrides have any legitimate use
2021-11-02 03:40:58 <dalias> but it's been a long time since i looked at the TR on how it all works
2021-11-02 03:46:10 <Hello71> well we had to put something in all that unihan space, why not some security vulnerabilities
2021-11-02 06:29:53 <Cogitri[m]> fwiw Fedora added a check to pagure to warn for those characters and scanned the entirety of their dist-git and didn’t find anything of note: https://twitter.com/mattdm/status/1455188564250185729
2021-11-02 08:36:46 <fcolista> ikke, how to manage linting error when we use disturl and giturl for packages not having a tag?
2021-11-02 08:36:55 <fcolista> I'm referring to things like this: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/528219
2021-11-02 08:42:59 <psykose> i think it needs to be added to https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/overlay/usr/share/abuild/APKBUILD_SHIM
2021-11-02 08:43:13 <psykose> just missing from the defaults of variables that can be empty
2021-11-02 08:43:33 <psykose> er, empty -> "unused"
2021-11-02 08:52:01 <ikke> fcolista: if you can get an archive from a commit, that's still preferred to using the snapshot function
2021-11-02 09:19:38 <HRio> Hi, I need some help with a merge to main !27031
2021-11-02 09:33:20 <ncopa> craftyguy: its not yet branched
2021-11-02 09:33:48 <fcolista> ikke, can you help me in finding a way to get the package from a commit? https://github.com/freeswitch/freetdm
2021-11-02 09:34:00 <fcolista> if/when you can
2021-11-02 09:39:35 <ncopa> fcolista: i think it would make sense to ask upstream to tag a release
2021-11-02 09:39:47 <fcolista> i already did it ncopa
2021-11-02 09:39:59 <ncopa> ah. i just saw :) 
2021-11-02 09:40:01 <fcolista> but for spandsp the same request is from sept 2020
2021-11-02 09:40:07 <fcolista> and they still haven't done it..
2021-11-02 09:40:20 <fcolista> does not seems they are willing to do that :D
2021-11-02 09:41:15 <fcolista> basically they have moved out from FS tree spandsp, sofia-sip, freetdm..and I bet they will do the same for other packages in the next releases
2021-11-02 09:41:16 <ncopa> they probably don't care
2021-11-02 09:41:22 <ikke> fcolista: do you want a specific commit or just the latest?
2021-11-02 09:41:23 <fcolista> right
2021-11-02 09:41:33 <fcolista> latest is better
2021-11-02 09:41:49 <fcolista> what we have in dev.a.o is the master
2021-11-02 09:41:54 <fcolista> (up to few days ago)
2021-11-02 09:42:10 <ikke> https://github.com/freeswitch/freetdm/archive/8918ee1c3637cad0f9d41a402d26d3aa076fc202.tar.gz
2021-11-02 09:42:36 <fcolista> thanks a lot ikke 
2021-11-02 09:42:47 <ikke> just archive/<commit>.tar.gz
2021-11-02 09:42:49 <fcolista> is there any black magic to get this link? :)
2021-11-02 09:43:20 <ikke> Just knowing the url scheme
2021-11-02 09:43:21 <fcolista> cool
2021-11-02 09:43:29 <fcolista> thanks a lot
2021-11-02 09:43:42 <ikke> It can be any reference
2021-11-02 09:43:52 <ikke> but using a branch would not work for us
2021-11-02 09:44:01 <ncopa> will you create a separate package or will you pull in and build it with freeswitch?
2021-11-02 09:44:10 <fcolista> separate package
2021-11-02 09:44:33 <ncopa> then *we* need to give it a version number, so apk gets happy
2021-11-02 09:44:45 <fcolista> pkgver=0_git20211102
2021-11-02 09:44:52 <fcolista> would that make sense?
2021-11-02 09:45:08 <ncopa> yeah. i guess that could work
2021-11-02 09:45:30 <ikke> I would use the commit date personally
2021-11-02 09:45:58 <fcolista> ikke, yeah. I think your suggestion makes more sense
2021-11-02 09:47:01 <fcolista> which in this case appears to be august 30
2021-11-02 09:47:19 <fcolista> so 0_git20210830
2021-11-02 09:47:38 <ncopa> sounds good to me
2021-11-02 09:48:01 <ikke> +1
2021-11-02 09:48:45 <fcolista> ok, going to update the APKBUILD
2021-11-02 09:49:56 <fcolista> ncopa, if/when you have time, I would appreciate your review of MR 27043. The two patches related to ppc64le and s390x probably needs a blessing
2021-11-02 09:50:21 <ncopa> !27043
2021-11-02 10:33:11 <mps> clandmeter: there is linux-edge 5.15 for rv64, did you tried it on your machine
2021-11-02 10:35:18 <Ariadne> andypost[m]: working on the regression testing of rust 1.56.1 upstream didn't do because they got frenzied up into fixing non-bugs
2021-11-02 10:36:46 <Ariadne> i really hope that Nicholas enjoys being a pariah in this industry.  i am sure his spooky website and CVE collection has really had the effect he was hoping for.
2021-11-02 10:37:35 <mps> :)
2021-11-02 10:39:01 <Ariadne> assuming that the effect was pissing off basically every computer scientist ever, anyway
2021-11-02 10:39:19 <Ariadne> in which case, i guess we can call it a success
2021-11-02 10:41:11 <Ariadne> i am also working on the gcc patch
2021-11-02 11:33:49 <Ariadne> andypost[m]: sending rust 1.56.1
2021-11-02 11:34:19 <Ariadne> i tested with a friend's rust homework who uses RTL comments and it all seems to still compile
2021-11-02 11:34:22 <Ariadne> so, whatever
2021-11-02 11:34:47 <Ariadne> i strongly protest the existence of CVE-2021-42574 but too late now :)
2021-11-02 11:43:44 <andypost[m]> Ariadne: thank you! curious if it pass on builders
2021-11-02 11:48:23 <Ariadne> it better
2021-11-02 11:48:35 <Ariadne> i mean it did on CI
2021-11-02 11:48:38 <Ariadne> except for armhf
2021-11-02 11:48:42 <Ariadne> but it never passes CI on armhf
2021-11-02 11:57:08 <donoban> I think that there is some version missmatch between py3-aiohttp and py3-async-timeout: "AttributeError: module 'async_timeout' has no attribute 'Timeout'"
2021-11-02 12:01:54 <Ariadne> :D
2021-11-02 12:01:57 <Ariadne> probably
2021-11-02 12:02:03 <Ariadne> upgrade both to latest i guess
2021-11-02 12:03:00 <PureTryOut> So uh, I'm packaging Qt6Webengine which is Chromium with a layer of Qt around it, and I just can not get it to pass CI (on any architecture) due to memory constraints. I've ran it like a 100 times now, also with `-j1` and stuff, but it just keeps running out of memory. Any clue what I can do about that?
2021-11-02 12:03:35 <Ariadne> cry
2021-11-02 12:04:38 <psykose> what are the memory limits i wonder, it should be possible with like 8gb i thought
2021-11-02 12:04:40 <eris[m]> oh dear
2021-11-02 12:05:06 <eris[m]> is it possible to pump up swap on the builders?
2021-11-02 12:06:43 <Ariadne> the builders have like
2021-11-02 12:06:44 <Ariadne> 128gb
2021-11-02 12:06:46 <Ariadne> :P
2021-11-02 12:06:51 <eris[m]> of ram?
2021-11-02 12:06:54 <eris[m]> or swap
2021-11-02 12:06:56 <Ariadne> yes ram
2021-11-02 12:07:04 <eris[m]> whst the FUCK
2021-11-02 12:07:06 <Ariadne> the CI does not
2021-11-02 12:07:06 <eris[m]> WHAT THE FUCK
2021-11-02 12:07:11 <eris[m]> oh
2021-11-02 12:07:24 <eris[m]> on the ci then
2021-11-02 12:07:30 <eris[m]> forgot those were different things
2021-11-02 12:07:40 <Ariadne> PureTryOut: try avoiding ld.gold?
2021-11-02 12:08:38 <PureTryOut> I'm... not sure what that is lol
2021-11-02 12:09:09 <psykose> the linker, it probably uses gold by default, though it would be in makedepends then afaik
2021-11-02 12:10:19 <Ariadne> ok maybe try using ld.gold :)
2021-11-02 12:10:26 <Ariadne> one or the other :D
2021-11-02 12:10:37 <psykose> or lld if you want more things to try
2021-11-02 12:10:57 <psykose> or even add mold to the repos and try that :p (probably needs even more memory)
2021-11-02 12:11:37 <PureTryOut> And uh, how would I make it use that?
2021-11-02 12:12:16 <psykose> cflags -fuse-ld=
2021-11-02 12:12:55 <psykose> ld.gold ld.lld etc for the arg
2021-11-02 12:14:19 <PureTryOut> Thanks I'll give it a shot
2021-11-02 12:20:34 <Ariadne> the alternative is to raise the CI memory limit for your jobs, i guess
2021-11-02 12:20:39 <Ariadne> i dont know
2021-11-02 12:20:47 <Ariadne> chromium is kind of obnoxious :P
2021-11-02 12:21:02 <eris[m]> absolutely
2021-11-02 12:30:02 <PureTryOut> Yeah I wish Qt6Webengine used Gecko or something instead, but alas
2021-11-02 12:39:59 <donoban> Now aiohttp misses aiosignal "ModuleNotFoundError: No module named 'aiosignal'
2021-11-02 12:40:17 <donoban> I don't understand how this depencies errors are not detected by tests
2021-11-02 12:43:22 <Ariadne> :D
2021-11-02 13:09:20 <omni> what if we just quit the web?
2021-11-02 13:10:30 <psykose> your ethernet cable is a yoink away
2021-11-02 13:13:05 <omni> there's a lot going through it that is !web that I do appreciate
2021-11-02 13:15:44 <donoban> could someone take a look to !98568? 
2021-11-02 13:16:12 <donoban> lol
2021-11-02 13:16:36 <donoban> !27078 this ^^
2021-11-02 13:18:25 <donoban> meh, there is a wrong description in frozenlist
2021-11-02 13:22:24 <Hello71> PureTryOut: turn debug symbols back off?
2021-11-02 15:15:53 <ngortheone> guys, what is going to replace eudev?
2021-11-02 15:19:10 <psykose> probably libudev-zero+mdevd+mdevd scripts, but it will be some time before it gets replaced
2021-11-02 15:30:01 <mps> ngortheone: you can now use libudev-zero on alpine
2021-11-02 15:30:28 <mps> don't expect everything to work
2021-11-02 15:33:52 <psykose> afaik there is no udev scripts on libudev-zero either, so anything whatsoever that uses those doesn't anymore
2021-11-02 15:34:56 <mps> psykose: rules are configured in mdev.conf
2021-11-02 15:35:22 <psykose> i am aware
2021-11-02 15:35:43 <mps> only problem I had was with usb-modeswitch, but I fixed it by shell script
2021-11-02 15:36:05 <psykose> there is a few pages of things in udev/rules.d that will have to be converted
2021-11-02 15:36:08 <psykose> but it is not a huge amount
2021-11-02 15:36:22 <psykose> maybe an odd 30-40ish packages off a quick count
2021-11-02 15:36:48 <mps> psykose: I think the same, not much of them
2021-11-02 15:36:54 <psykose> of course the bigger issue is maintenance i think
2021-11-02 15:37:00 <psykose> a lot of them are just shipped from upstream
2021-11-02 15:37:21 <psykose> now there is not much care, with conversion you have to watch changes
2021-11-02 15:38:00 <mps> right, alpine maintainers should look at these and convert them to mdev
2021-11-02 15:45:02 <minimal> potentially there's also a need for stubs for things like "udevadm" for apps that may call them
2021-11-02 16:11:57 <skarnet> won't help as long as it's mdev and not mdevd, but for the long run, yeah
2021-11-02 17:21:19 <Newbyte> would it be okay to get in !26028 for Alpine 3.15? then we'd have more or less all of GNOME on version 41
2021-11-02 17:22:10 <Newbyte> there are no soname differences from what I can tell
2021-11-02 17:41:49 <Newbyte> andypost: GNOME 41 works now btw
2021-11-02 17:41:53 <Newbyte> if you use that MR
2021-11-02 17:42:10 <Newbyte> I remember you talked about it
2021-11-02 17:46:46 <maribu> Can someone confirm that `$ v4l2-ctl -c foo=bar` now segfaults?
2021-11-02 17:48:22 <psykose> it does for me, weird
2021-11-02 17:55:06 <maribu> OK. Looks like the behavior of getsubopts has changed and breaks the option parsing of the v4l utils
2021-11-02 17:55:45 <maribu> *getsubopt
2021-11-02 18:04:31 <maribu> The observed behavior from GDB doesn't match the behavior documented in the man-page. "Otherwise, -1 is returned and *valuep is the entire name[=value] string.". It does return -1 as it should, but *valuep is set to NULL. This is than passed on to strchr which segfaults.
2021-11-02 18:10:26 <maribu> This doesn't really look like recent changes: https://git.musl-libc.org/cgit/musl/log/src/misc/getsubopt.c
2021-11-02 18:11:09 <mps> uhm, looks like latest ssh client doesn't work
2021-11-02 18:16:12 <psykose> what doesn't work in it
2021-11-02 18:16:40 <mps> debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
2021-11-02 18:16:58 <mps> debug1: Connecting to 10.5.1.1 [10.5.1.1] port 22.
2021-11-02 18:17:05 <mps> and hangs there
2021-11-02 18:17:15 <psykose> hehe
2021-11-02 18:17:32 <psykose> something is indeed broken then
2021-11-02 18:20:53 <mps> hmm, on another machine (aarch64) it works but not on x86_64
2021-11-02 18:21:02 <mps> MTU?
2021-11-02 18:21:43 <mps> hmm no
2021-11-02 18:23:15 <mps> hmmmmm, I can connect over WG tunnel but not normal WIFI
2021-11-02 18:23:28 <psykose> is aarch64 on wifi
2021-11-02 18:23:34 <psykose> also does an older client work
2021-11-02 18:23:35 <mps> both are
2021-11-02 18:24:15 <mps> don't have older client, have to downgrade for this, which I don't like to do
2021-11-02 18:24:55 <psykose> eh, it's just an openssh client, simple enough
2021-11-02 18:25:42 <mps> and a lot of libs which will pulldown a lot of other pkgs
2021-11-02 18:26:31 <psykose> i don't think any of the dependencies changed though
2021-11-02 18:28:58 <mps> if it is not because of broadcom wifi
2021-11-02 18:29:23 <mps> lets try with external usb dongle
2021-11-02 19:29:06 <mps> psykose: yes, it is because of wifi, over ethernet it ssh works fine
2021-11-02 19:29:47 <psykose> :) not ssh then
2021-11-02 19:29:58 <mps> right
2021-11-02 19:30:22 <mps> broadcom :/
2021-11-02 19:30:35 <mps> f**k you broadcom
2021-11-02 19:31:52 <mps> sorry, couldn't resist
2021-11-02 19:32:37 <mps> just wanted to paraphrase Linus Torvalds about nvidia
2021-11-02 19:33:17 <mps> and now I fell ashamed
2021-11-02 19:33:32 <mps> feel*
2021-11-02 20:08:48 <ikke> .uptime
2021-11-02 20:08:48 <alpine-meetbot> I've been sitting here for 0:02:04 and I keep going!
2021-11-02 20:09:26 <ikke> s/uptime/downtime
2021-11-02 20:09:26 <alpine-meetbot> ikke meant to say: .downtime
2021-11-02 21:58:40 <clandmeter> mps: not yet, the box is down
2021-11-02 21:58:58 <clandmeter> I moved it cause it makes to much noise
2021-11-02 21:59:19 <clandmeter> It's insane the amount of noise that fan makes
2021-11-02 23:51:40 <craftyguy> could someone take a look at this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27066
2021-11-03 07:28:11 <mps> clandmeter: so even airport can't suppress rv64 noise :)
2021-11-03 08:47:56 <ncopa> good morning
2021-11-03 08:51:59 <Cogitri[m]> Morning
2021-11-03 08:52:33 <mps> good day
2021-11-03 08:53:18 <mps> a lot of pkgs on builders fails with errors like 'ERROR: seahorse-41.0-r1.apk: BAD signature'
2021-11-03 09:15:42 <andypost[m]> mpa: that's probably effect of lack of disk space
2021-11-03 09:42:28 <clandmeter> mps: i put the box on the attic here, and i can still here the fan making noise...
2021-11-03 09:43:03 <clandmeter> so moved it offsite where the noise cant harm people trying to enjoy life.
2021-11-03 09:45:05 <mps> clandmeter: hmm, where is that place? I would like to move there where people trying to enjoy life ;)
2021-11-03 09:49:31 <clandmeter> you know where, you just never come to visit and experience it ;-)
2021-11-03 09:50:22 <mps> hah, I think place is where the 'bob the builder' worked in last time :)
2021-11-03 09:51:22 <clandmeter> bob is still here :) still few months to go.
2021-11-03 09:51:39 <clandmeter> little offtopic though :)
2021-11-03 09:52:09 <mps> yes, but nice
2021-11-03 11:24:01 <yyp> Is mailinglist-bot running correctly? My patches don't seem to come through
2021-11-03 13:11:58 <PureTryOut> > error adding symbols: memory exhausted
2021-11-03 13:12:05 <PureTryOut> Ugh, switching linkers doesn't help 😢
2021-11-03 13:18:15 <Misthios> idk if this would be allowed but could u try making a swpafile for during the build
2021-11-03 13:18:35 <Misthios> hacky way tbh so dont think its a good idea
2021-11-03 13:20:13 <ikke> no
2021-11-03 13:21:22 <psykose> i think PureTryOut has spent enough ci cycles on this that it's time to just bump the memory limit and call it a day
2021-11-03 13:21:32 <ikke> We do not set a memory limit
2021-11-03 13:21:39 <PureTryOut> I have indeed spent quite a lot of CI on this lol
2021-11-03 13:22:02 <ikke> It's limited by what the host has available
2021-11-03 13:22:08 <psykose> i thought ci did have limits, separate from the builders
2021-11-03 13:22:08 <psykose> hm
2021-11-03 13:22:52 <PureTryOut> At least Qt5Webengine usually succeeds after like 2 tries
2021-11-03 13:23:12 <ikke> psykose: it runs on separate hosts
2021-11-03 13:23:20 <ikke> which might have a different amount of memory
2021-11-03 13:23:41 <psykose> what choices does that leave then
2021-11-03 13:24:09 <ikke> complain upstream that it uses too much memory to link
2021-11-03 13:24:58 <psykose> i doubt qt/chromium will be super receptive, but i suppose one can try
2021-11-03 13:25:07 <psykose> i wonder what the actual limit is, maybe i should run the build myself
2021-11-03 13:26:42 <Hello71> without debug symbols it should only require like 10 GB?
2021-11-03 13:27:12 <ikke> the x86_64 ci host has 64G of memory availbe
2021-11-03 13:27:15 <ikke> available
2021-11-03 13:27:30 <ikke> if that's not enough, then the project is the issue, not CI
2021-11-03 13:28:06 <ikke> (not withstanding differences that cause it use more memory, but not sure what would)
2021-11-03 13:28:26 <Hello71> does it not depend on what else is running?
2021-11-03 13:29:36 <ikke> Current memory usage (while running jobs) is 6G
2021-11-03 13:29:45 <ncopa> "memory exhausted" is that on a 64bit or 32bit build?
2021-11-03 13:29:53 <ikke> x86_64
2021-11-03 13:29:53 <PureTryOut> I would try running it locally but either my PC completely locks down for about 4 hours while doing so, or (when using e.g. -j1) it runs for longer than I'm willing to leave my PC on
2021-11-03 13:30:16 <PureTryOut> ncopa: that particular one is on 32-bit. The 64-bit builds don't even get that far
2021-11-03 13:30:19 <PureTryOut> Hold on let me link you logs
2021-11-03 13:30:33 <ikke> oh, that might be address space exhaustion then
2021-11-03 13:30:46 <PureTryOut> x86_64: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/529714/raw
2021-11-03 13:30:48 <ncopa> i have seen "memory exhausted" on 32 bit builds and it is address space problem
2021-11-03 13:31:38 <ncopa> g++: fatal error: Killed signal terminated program cc1plus
2021-11-03 13:31:38 <PureTryOut> armv7: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/529655/raw
2021-11-03 13:31:56 <PureTryOut> the last x86 run has the same result as the x86_64 one, but if you retry it once or twice it gets to the memory exhausted thing again
2021-11-03 13:32:27 <ncopa> error adding symbols: memory exhausted
2021-11-03 13:32:40 <ncopa> im pretty sure it runs out of address space
2021-11-03 13:32:50 <PureTryOut> even 64-bit?
2021-11-03 13:33:06 <ncopa> the 64-bit does not get that error?
2021-11-03 13:33:13 <PureTryOut> no but it constantly fails as well
2021-11-03 13:33:21 <ncopa> different error: "g++: fatal error: Killed signal terminated program cc1plus"
2021-11-03 13:33:38 <ncopa> i mean, yeah, its probably same or similar problem
2021-11-03 13:33:41 <ikke> sounds like OOM killer
2021-11-03 13:33:44 <PureTryOut> yeah but what causes that if not memory?
2021-11-03 13:33:45 <ncopa> yes
2021-11-03 13:33:48 <PureTryOut> yes 
2021-11-03 13:34:07 <PureTryOut> like I said earlier, Qt5Webengine has that often too but if you retry it once or twice then it often succeeds after all
2021-11-03 13:34:26 <ncopa> difference is "memory exchausted" can not be solved by adding more memory. the x86_64 problem can likely be solved by adding memory
2021-11-03 13:34:46 <ncopa> its during the linking phase it happens
2021-11-03 13:34:56 <PureTryOut> that I realize. As long as we don't have cross-compiling I'll probably just disable the package on 32-bit arches
2021-11-03 13:35:14 <ncopa> i think we should solve it somehow
2021-11-03 13:35:29 <ncopa> its kinda bad that a program is so big that you cannot even link it
2021-11-03 13:35:40 <ikke> and disabling debug symbols?
2021-11-03 13:36:04 <PureTryOut> Not sure how to do that with CMake tbh
2021-11-03 13:36:31 <ncopa> oh are debugging symbold enabled?
2021-11-03 13:36:45 <ncopa> disabling debug symbols will likely solve it
2021-11-03 13:37:07 <ncopa> im pretty sure that debug symbols will create this problem
2021-11-03 13:37:19 <ncopa> https://forums.gentoo.org/viewtopic-t-1040682-start-0.html
2021-11-03 13:37:51 <PureTryOut> So removing `-g gdb` from LDFLAGS?
2021-11-03 13:37:53 <ncopa> this also tells user to disable debug symbols: https://coderedirect.com/questions/507312/llvm-clang-compile-error-with-memory-exhausted
2021-11-03 13:38:01 <PureTryOut> *CFLAGS
2021-11-03 13:38:19 <ncopa> depends on cmake script i guess
2021-11-03 13:38:31 <PureTryOut> Alpine policy is to use None build, not Release. Release would indeed build without debug symbols
2021-11-03 13:38:37 <PureTryOut> Maybe we should make an exception for this package?
2021-11-03 13:38:45 <ncopa> yes. absolutely
2021-11-03 13:38:51 <ncopa> and add a comment why its needed
2021-11-03 13:38:55 <PureTryOut> Yeah ofc
2021-11-03 13:39:01 <PureTryOut> Ok I'll give that a shot then
2021-11-03 13:39:17 <psykose> what is the reason for None being preferred
2021-11-03 13:39:17 <ncopa> 👍
2021-11-03 13:39:30 <ncopa> psykose: so we use the system CFLAGS
2021-11-03 13:39:44 <psykose> weird, does cmake ignore CFLAGS in release?
2021-11-03 13:39:56 <ncopa> yes, i think it does
2021-11-03 13:40:11 <PureTryOut> It does yes
2021-11-03 13:40:20 <ncopa> i think it will set the CFLAGS to -O2 or similar, while alpine default is -Os
2021-11-03 13:40:30 <PureTryOut> It uses whatever upstream has set it should use
2021-11-03 13:40:42 <psykose> buildtype MinSizeRel is equivalent to -Os i think then
2021-11-03 13:40:56 <psykose> at least the neovim package had the same issue and overrode None with MinSizeRel
2021-11-03 13:41:16 <psykose> and by same issue i mean None gives a slow debug build for it, not a memory build issue
2021-11-03 13:41:31 <PureTryOut> Ah I forgot about MinSizeRel, probably better than Release type
2021-11-03 13:42:28 <ncopa> agree
2021-11-03 13:46:13 <psykose> yep, minsizerel is "-Os -DNDEBUG" in the default definition
2021-11-03 13:46:26 <psykose> i wonder if adding CMAKE_C_FLAGS to the environment adds to this or replaces it
2021-11-03 13:56:38 <ncopa> i think we may have used CMAKE_C_FLAGS in the past. I don't know why we ended up with `none`. Might be so that -dbg subpackages "just works"
2021-11-03 13:56:56 <ncopa> in any case, I think making exceptions when needed makes sense
2021-11-03 13:58:02 <psykose> it does indeed
2021-11-03 13:58:22 <psykose> funnily there is a RelWithDebInfo but no MinSizeRelWithDebInfo which would be the defaults anyway
2021-11-03 14:07:09 <fcolista> ncopa, looks that !27043 is ready to be merged
2021-11-03 14:07:33 <fcolista> I can go ahead and merge it if you give me green light
2021-11-03 14:07:55 <Hello71> exporting CMAKE_C_FLAGS doesn't do anything because it's a cmake variable, not an environment variable
2021-11-03 14:08:04 <Hello71> cmake initializes CMAKE_C_FLAGS using the environment variable CFLAGS
2021-11-03 14:08:17 <psykose> makes sense
2021-11-03 14:45:31 <ncopa> fcolista: good job. good commit messages as well
2021-11-03 15:33:55 <Saijin_Naib[m]> ncopa: As the maintainer of the XFCE stack, would you be receptive to MRs for expanding say, the thumbnail functionality of tumbler by adding some things to the makedepends?
2021-11-03 15:34:17 <Saijin_Naib[m]> Or is that antithetical to the Alpine-ness of keep it separated/minimal
2021-11-03 15:35:56 <psykose> it is separated; it doesn't require you to have it installed afterward to my knowledge
2021-11-03 15:36:15 <psykose> arch does it the same way, there's a makedepends for all of them, then you can install the actual lib yourself if you want the functionality
2021-11-03 15:38:29 <Saijin_Naib[m]> So, I would not want to change the depends to pull in those libs then, correct?
2021-11-03 15:38:40 <Saijin_Naib[m]> People are expected to know what is needed for full functionality
2021-11-03 15:39:03 <psykose> yep
2021-11-03 15:39:34 <psykose> also that arch patch you showed the other day would perhaps make it detect it correctly, but the issue is also in the .pc from libopenraw, and i don't know how to fix that one
2021-11-03 15:40:02 <omni> ncopa: what is needed to get https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/81 in?
2021-11-03 15:40:14 <PureTryOut> ncopa: sadly 32-bit is still lacking address space, so I still think I'll disable the package on 32-bit architectures
2021-11-03 15:42:47 <dalias> how does None work with cmake? sounds like something i should know about
2021-11-03 15:43:09 <dalias> does it really just honor your CFLAGS and disable the cmake CFLAGS logic?
2021-11-03 15:43:14 <dalias> that would be so nice
2021-11-03 15:43:24 <PureTryOut> Afaiu, yes
2021-11-03 15:43:34 <dalias> and you could keep None here just by putting -g0 in CFLAGS and CXXFLAGS
2021-11-03 15:43:42 <psykose> seems so, but there are some number of cmake projects that also use that as a sign to set debug logic
2021-11-03 15:43:47 <dalias> uhg
2021-11-03 15:44:08 <psykose> let me see if i can find what specifically in neovim does that real quick...
2021-11-03 15:46:11 <psykose> ah, it seems to rely on the release flags from cmake, but not the buildtype
2021-11-03 15:46:24 <psykose> there is debug code that is #ifndef NDEBUG
2021-11-03 15:46:35 <psykose> and the Rel cmake types pass -DNDEBUG
2021-11-03 15:47:37 <psykose> i guess this is one example of relying on cmake behaviour, but i don't think adding -DNDEBUG to cflags universally or something would be a good idea to match it, so it's still case by case
2021-11-03 15:47:55 <ncopa> Saijin_Naib[m]: depends how bit it is, but I guess I could always review an MR
2021-11-03 15:49:17 <Saijin_Naib[m]> ncopa: Thank you. I will draw one up for your review, then.
2021-11-03 15:49:37 <ncopa> omni: re https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/81 maybe we can ask clandmeter to have a look at it? I haven't really used overlaytmpfs at all, ever
2021-11-03 15:50:06 <Saijin_Naib[m]> psykose: I didn't even know about the packageconfig stuff. I'm going to ask upstream since I imagine pulling in the latest version of the libs they use is a good security practice at the least
2021-11-03 15:50:46 <psykose> i mean it seems like an upstream error, building and installing gives you two -0.3.pc's and one relies on a 0.1 that doesn't exist or is installed
2021-11-03 15:50:56 <psykose> i don't know why this is the case, you can see it by reading the .pc in libopenraw-dev
2021-11-03 15:55:06 <clandmeter> you can always ask :)
2021-11-03 15:56:41 <clandmeter> i think overlaytmpfs is added by fabled iirc?
2021-11-03 16:31:53 <Nulo> https://bpa.st/DRBQ
2021-11-03 16:32:01 <Nulo> I'm having issues installing gnome-calendar
2021-11-03 16:56:56 <psykose> think libreoffice needs a rebuild against new openldap-dev
2021-11-03 16:58:43 <psykose> it was seemingly missed in the merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24084/diffs
2021-11-03 16:59:55 <psykose> hmm.. no it's there
2021-11-03 17:01:07 <psykose> for some reason libreoffice is gone from the repos, so maybe that's why it fails to update
2021-11-03 17:02:34 <psykose> ah, failed on builders :) #13141
2021-11-03 17:02:42 <psykose> will get fixed eventually
2021-11-03 17:22:45 <Nulo> psykose, there's also vlc vlc-qt gnupg neomutt
2021-11-03 17:24:15 <psykose> neomutt doesn't have a libldap dependency
2021-11-03 17:24:47 <psykose> and i can install all of those, do you mean something else
2021-11-03 17:25:38 <Nulo> Sorry, it's just gnupg and libreoffice I believe
2021-11-03 17:26:13 <Nulo> neomutt depends on gnupg which has the issue
2021-11-03 17:26:39 <psykose> gnupg is rebuilt and installs fine though 
2021-11-03 17:26:45 <psykose> maybe your mirror is out of date
2021-11-03 17:35:06 <Nulo> psykose, dl-cdn.alpinelinux.org?
2021-11-03 17:35:36 <psykose> that is up to date
2021-11-03 17:35:40 <psykose> what was the gnupg error then
2021-11-03 17:36:49 <psykose> if you mean from the output above everything under 2.6.0 is correct, it's just showing what pulls it, only the 2.4.59 one is the broken things
2021-11-03 17:37:42 <Nulo> psykose, sorry, I can't read apparently
2021-11-03 17:37:47 <psykose> that is okay :)
2021-11-03 17:38:23 <psykose> anyway you can uninstall libreoffice temporarily if you don't need it and it will fix it for now
2021-11-03 17:38:46 <psykose> though you won't be able to get it back till it's fixed
2021-11-03 17:52:35 <Nulo> psykose, okay, thanks
2021-11-03 17:54:10 <omni> ncopa: alandiwix closed their https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/90 in favor of it
2021-11-03 17:55:07 <omni> clandmeter: looks like TTeräs added overlaytmpfs support, is that fabled?
2021-11-03 17:55:23 <ikke> yes
2021-11-03 17:55:43 <omni> fabled: ^^ (if your highlighting didn't trigger yet)
2021-11-03 17:57:18 <alandiwix> so we'll get it merged?
2021-11-03 19:00:23 <dalias> is blender package supposed to be broken?
2021-11-03 19:00:24 <dalias> i get
2021-11-03 19:00:25 <dalias> : CommandLine Error: Option 'help-list' registered more than once!
2021-11-03 19:00:25 <dalias> LLVM ERROR: inconsistency in registered CommandLine options
2021-11-03 19:00:25 <dalias> Aborted
2021-11-03 19:03:54 <PureTryOut> I don't think any package is ever supposed to be broken lol
2021-11-03 19:05:41 <dalias> it happens right after mesa dlopens a bunch of drm modules for every video card vendor >_<
2021-11-03 19:06:20 <dalias> ok upgrading mesa seems to fix it
2021-11-03 19:13:48 <dalias> i love how alpine doesn't track lib version dependencies :-p
2021-11-03 19:23:37 <psykose> what kind of lib version
2021-11-03 19:23:47 <psykose> it tracks the soname lib in deps
2021-11-03 19:24:22 <dalias> yeah but new soname just means incompatible with old version
2021-11-03 19:25:57 <psykose> do you mean instead of tracking e.g. so:somelib.so.5 it should track somelib-1.4.2
2021-11-03 19:26:17 <dalias> dep on somelib >=1.4.2
2021-11-03 19:26:22 <psykose> right
2021-11-03 19:26:35 <dalias> so: deps are just a *wrong model*
2021-11-03 19:29:15 <ikke> dalias: if some application has a dependency on somelib.so.5, does it make sense to pull in anything other than a package that provides that?
2021-11-03 19:29:44 <dalias> ikke, but it doesn't tell what version is needed
2021-11-03 19:30:14 <dalias> suppose somelib-5.2 adds new functionality not in somelib-5.1
2021-11-03 19:30:35 <dalias> and the package was compiled against 5.2 and selected to use that new functionality
2021-11-03 19:30:46 <dalias> so:somelib.so.5 only encodes that 5.x is needed, not >=5.2
2021-11-03 19:31:47 <ikke> so you need a combination
2021-11-03 19:32:23 <ikke> >=5.2 woud mean somelib.so.6 would also be acceptable
2021-11-03 19:33:43 <ikke> somelib=~5.2 would probably work, assuming projects follow semver
2021-11-03 19:36:17 <dalias> well
2021-11-03 19:36:43 <dalias> if there are incompatible library versions, the soname version should be part of the package name not just version
2021-11-03 19:36:52 <dalias> so somelib5-5.2 vs somelib6
2021-11-03 19:36:59 <dalias> and dep on somelib5 >= 5.2
2021-11-03 19:52:54 <ikke> It's a lot of work for developers though
2021-11-03 19:53:05 <ikke> to track everything and keep multiple versions of libraries
2021-11-03 19:57:42 <dalias> well there's nno hard requirement that old sonames need to be kept/maintained
2021-11-03 19:57:58 <dalias> they just shouldn't conflict with and shouldn't be purged by installing new one
2021-11-03 19:58:23 <dalias> so that unrelated packages don't get force-upgraded when you install something that needs the new soname
2021-11-03 19:58:29 <dalias> and so self-built software doesn't break
2021-11-03 20:16:14 <skarnet> who would have thought that having the possibility of having several versions of the same package on the machine would be a good thing 🤔
2021-11-03 20:35:36 <bl4ckb0ne> hitting `no space left on device` on aarch64 https://gitlab.alpinelinux.org/bl4ckb0ne/aports/-/jobs/530023#L155
2021-11-03 20:36:21 <ikke> ceph is building. We have limited space on our arm-based CI hosts, and ceph is consuming most of it
2021-11-03 20:36:35 <bl4ckb0ne> ill relaunch it in a few hours
2021-11-03 20:39:25 <ikke> bl4ckb0ne: I've freed some space, you should be able to try again
2021-11-03 20:40:24 <bl4ckb0ne> thanks
2021-11-04 06:54:19 <ktprograms> Nextcloud expects cron.php to be run every 5 minutes, but the shortest interval Alpine has is 15min. Should the nextcloud install add a /etc/periodic directory for 5min cron jobs with a corresponding /etc/crontabs/root line?
2021-11-04 07:51:59 <fcolista> hi all.Looking at some important packages, very often there's the debian dir with all the instructions to build a deb package. You can find also the .spec file for rpm based distro. If we do create an upstream request for alpine dir with the APKBUILD, wouldn't it be a good way to make some advertisement? 
2021-11-04 07:52:33 <fcolista> (the apk should be installed with --allow-untrusted ofc)
2021-11-04 07:53:39 <fcolista> just a brainfart i had looking at the FS source tree..
2021-11-04 08:16:07 <mps> good morning
2021-11-04 08:16:31 <mps> armhf CI is stuck or 'out on breakfast'
2021-11-04 08:23:23 <andypost[m]> mps: I bet numpy is stuck in tests
2021-11-04 08:26:01 <andypost[m]> btw IIRC scipy build much longer then numpy
2021-11-04 08:28:22 <andypost[m]> btw looks it stuck as https://build.alpinelinux.org/buildlogs/build-3-15-armhf/community/py3-scipy/py3-scipy-1.7.1-r1.log
2021-11-04 08:48:49 <ikke> 7 pending jobs for armhf
2021-11-04 08:48:59 <ikke> 2 long running jobs
2021-11-04 08:49:20 <ikke> rav1e and ceph
2021-11-04 09:21:00 <mps> andypost[m]: I see this https://github.com/noirlinux/main/blob/master/xorg/xorg-server/patches/rootless_modesetting.patch  patch for rootless xorg server
2021-11-04 09:21:49 <mps> and CarbsLinux have it. would we add this in alpine?
2021-11-04 09:31:39 <ncopa> rootless modesetting sounds like a good idea to me. I don't know what the patch or why its needed or why its not already in upstream though.
2021-11-04 09:47:39 <ncopa> dalias: if you want prevent self-built software to break you should do something like: `apk add --virtual .myprogram so:libsomelib.so.5 ....` which will add a "virtual" package with dependencies. It will prevent conflicts on upgrades and will prevent your library to unintentionally be uninstalled.
2021-11-04 09:48:07 <ncopa> If you want ABI stability, you should probably use a stable branch.
2021-11-04 09:48:39 <ncopa> we reserve the right to break things in edge, even if we try to avoid
2021-11-04 09:50:33 <mps> ncopa: I don't know why rootless patch is not applied upstream. last time I tried to test run xorg as user it failed with error saying something  about no access to tty0
2021-11-04 09:51:26 <mps> I will test this patch on weekend on my local box (hope will find little for this)
2021-11-04 09:52:34 <ncopa> skarnet: I don't appreciate your snarky comment, specially not when you don't like snarky responses yourself
2021-11-04 09:53:29 <skarnet> hey, in context, I thought that was perfectly fair game
2021-11-04 09:53:51 <skarnet> but I'll retract it if you want
2021-11-04 09:58:53 <ncopa> I apologized my snarkyness. lets avoid it in the future. its not constructive.
2021-11-04 09:59:57 <maribu> Can someone please confirm that `$ wget https://noms2022.ieee-noms.org/` doesn't work, because it fails to resolve the host? (The reason I'm asking is that it works for me on Arch Linux running in docker on the same machine. I also have this issue in Firefox, except when I enable DNS over HTTPS.)
2021-11-04 10:00:10 <mps> Ariadne: !27031 is it ok for merge?
2021-11-04 10:00:44 <mps> maribu: it works
2021-11-04 10:01:10 <maribu> In wireshark I see two DNS requests, one for IPv4 and one for the IPv6 address. I get a NXDOMAIN for the AAAA request, but the correct IPv4 address for the A request.
2021-11-04 10:02:20 <mps> maribu: ah yes, from ipv6 it doesn't work
2021-11-04 10:03:09 <maribu> But wget should just use IPv4 if there is no IPv6 address for the dnsname, shouldn't it? This is what wget in Arch Linux does for me.
2021-11-04 10:03:54 <mps> maribu: this is of resolver to decide iirc
2021-11-04 10:04:07 <mercenary> The name server shouldn't return NXDOMAIN, just 0 answers. Try wget -4
2021-11-04 10:04:40 <mps> if the user space program got NXDOMAIN it does not make sense for it to continue
2021-11-04 10:05:14 <mps> maribu: yes, what mercenary says
2021-11-04 10:05:18 <maribu> `wget -4` works like a charm
2021-11-04 10:06:21 <maribu> mercenary: Thanks, I will file a bug report to the admin of the DNS server :-)
2021-11-04 10:07:36 <skarnet> no snarkiness intended, but that's the exact use case that dnsfunnel was written for
2021-11-04 10:08:24 <skarnet> and it's still waiting to be merged, fortunately I will soon have more time to be more hands-on with Alpine and help move these things forward
2021-11-04 10:10:18 <skarnet> ncopa: there's a difference between punching up and punching down, and forgive me if I sometimes fail to resist the urge to poke fun at a project leader after basically 20 years spent being Cassandra in tech. I will do my best though.
2021-11-04 10:11:33 <mps> 'Cassandra in tech' nice :)
2021-11-04 10:11:52 <Ariadne> mps: if ddevault is fine with it
2021-11-04 10:11:55 <mps> sometimes I'm also
2021-11-04 10:12:25 <mps> Ariadne: to late, already merged and ddevault approved it before
2021-11-04 10:12:35 <Ariadne> :)
2021-11-04 10:12:51 <Ariadne> i have not apk fetch coffee yet
2021-11-04 10:12:53 <Ariadne> :)
2021-11-04 10:13:34 <mps> oh, that reminds me that I have to prepare second one for me ;)
2021-11-04 10:15:18 <ericonr> fcolista: having downstream build scripts in upstream projects is always bleh to me :p
2021-11-04 10:15:36 <skarnet> ericonr: +1
2021-11-04 10:34:59 <Ariadne> man
2021-11-04 10:35:12 <Ariadne> apparently in the back scroll i missed some drama
2021-11-04 10:35:24 <Ariadne> who has screenshots :p
2021-11-04 10:40:29 <ikke> https://irclogs.alpinelinux.org/%23alpine-devel-2021-11.log
2021-11-04 10:44:30 <fcolista> ericonr, can you explain why?
2021-11-04 10:44:43 <fcolista> My gut feeling is the same, though
2021-11-04 10:53:18 <ncopa> Ariadne: I'm looking at the patches we currently have for linux-lts. seems like 0007-pci-hotplug-declare-IDT-bridge-as-hotpluggabl-bridge.patch never was added upstream
2021-11-04 10:53:39 <Ariadne> you can drop the patches for honeycomb
2021-11-04 10:53:44 <Ariadne> they arent needed anymore
2021-11-04 10:53:47 <ncopa> ok
2021-11-04 10:54:23 <Ariadne> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.15-LTS-Kernel
2021-11-04 10:54:25 <Ariadne> going to 5.15? :)
2021-11-04 10:54:35 <ericonr> fcolista: I see how it can make sense if the maintainers use that distro and would prefer to stick all the files in one place, but to me it feels like separate concerns. If the distro already has packaging for your software, changing anything in your debian/ or .spec file still means *they* need to do the same work; detailed changelogs should fill the same role without being as
2021-11-04 10:54:37 <ericonr> intrusive. It can also be noisy to have a bunch of git log changes related to packaging that's not truly useful
2021-11-04 10:54:42 <ncopa> Ariadne: yes, thats what I'm aiming for
2021-11-04 10:55:01 <Ariadne> jirutka is asking for hold on release
2021-11-04 10:55:14 <ncopa> hold on release for what?
2021-11-04 10:55:21 <ericonr> fcolista: in a way it's like having CI definitions live in the same repository as the software, but in this case, it's way easier to avoid :P
2021-11-04 10:55:26 <ncopa> btw we should create an MR of the release notes already now
2021-11-04 10:55:59 <ncopa> and announce on the mailing list that we are working on release notes. so we avoid people coming long after the release wanting have things mentioned there
2021-11-04 10:56:28 <ncopa> why we dont need the honeycomb patches? because 5.15 already supports it out of the box or because we dont need support honeycomb anymore?
2021-11-04 11:07:11 <ncopa> do we want: Software Guard eXtensions (SGX) (X86_SGX) [N/y/?]
2021-11-04 11:07:25 <mps> Y
2021-11-04 11:07:32 <ncopa> why?
2021-11-04 11:07:47 <mps> to be 'secure' distro
2021-11-04 11:08:52 <mps> though it not important, imo
2021-11-04 11:09:01 <ncopa> are there any applycations actually using it?
2021-11-04 11:09:24 <ncopa> "... can be used by applications to set aside private regions of code and data, referred to as enclaves."
2021-11-04 11:10:20 <mps> these enclaves something modern for x86, which I didn't looked deeply
2021-11-04 11:10:22 <ncopa> im leaning against disable things, unless its enabled by upstream default, of if we are interested in the feature
2021-11-04 11:11:11 <mps> yes, that is right approach imo
2021-11-04 11:11:24 <ncopa> and enable when users ask for it
2021-11-04 11:13:55 <mps> yes, and wait till someone write blog somewhere saying that alpine is insecure ;)
2021-11-04 11:14:42 <mps> but these will happen for whatever reason
2021-11-04 11:14:55 <ericonr> is anyone using SGX for things besides DRM? If even that
2021-11-04 11:15:02 <mps> so, 'we' should 'keep our way'
2021-11-04 11:15:09 <ericonr> It might make sense for VM hosters, but beyond that, Idk
2021-11-04 11:16:14 <mps> right and I thought to enable it for linux-edge-virt but didn't waiting till someone asks for it
2021-11-04 11:16:34 <mps> linux-edge also
2021-11-04 11:20:14 <ikke> ncopa: re release notes, I already created an issue for it, was indeed planning sending a post to the mailing list as well
2021-11-04 11:20:46 <ikke> #13099
2021-11-04 12:10:41 <Ariadne> SGX is bad
2021-11-04 12:13:28 <Ariadne> the only applicable use is DRM, it’s far too broken for anything else
2021-11-04 12:14:03 <jvoisin> __confidential cloud__
2021-11-04 15:01:42 <PureTryOut> Ariadne: so your blog post about apk's providers was good, but I still don't understand how https://gitlab.alpinelinux.org/alpine/aports/-/issues/13152 this happening with it 😅 Could you take a look?
2021-11-04 15:02:13 <Ariadne> because you already have pipewire
2021-11-04 15:02:15 <Ariadne> installed
2021-11-04 15:02:24 <Ariadne> and you have dependencies on jack
2021-11-04 15:02:32 <Ariadne> so, the subpackage gets preferred
2021-11-04 15:02:45 <Ariadne> due to having less depth in the dependency graph
2021-11-04 15:02:52 <Ariadne> if that makes sense
2021-11-04 15:03:06 <Ariadne> (`apk dot` can generate diagrams explaining the solutions generated, btw)
2021-11-04 15:03:20 <psykose> the log in the issue pulls in all of pipewire on that upgrade; it wasn't already installed i don't think
2021-11-04 15:03:35 <psykose> otherwise pipewire-libs wouldn't be getting pulled as they would already be there
2021-11-04 15:04:05 <psykose> or well, i guess can't really know without the entire log anyway as it could also be an upgrade
2021-11-04 15:04:07 <PureTryOut> true, pipewire-libs would've been installed if pipewire was
2021-11-04 15:04:39 <PureTryOut> Ariadne: makes sense but the person in question didn't have pipewire installed yet according to the apk snippet they posted
2021-11-04 15:05:12 <Ariadne> in that case, pipewire-jack had less dependency cost than real jack
2021-11-04 15:05:18 <Ariadne> provider_priority does not "fix" that
2021-11-04 15:05:32 <PureTryOut> I realize that, that line in the issue is old
2021-11-04 15:06:15 <PureTryOut> Also in this case I'm not sure the behaviour of pipewire-jack being preferred over jack is wanted . It was meant as a replacement for jack, but only if explicitly requested by the user. Is there anyway to accomplish that without caring about the graph depth?
2021-11-04 15:06:31 <ikke> Ariadne: apk with debug enabled mentioned something about a provides conflict
2021-11-04 15:06:51 <ikke> disqualify_package: jack-1.9.19-r0 (conflicting provides) 
2021-11-04 15:07:12 <Ariadne> PureTryOut: sure, version the provides=jack in pipewire
2021-11-04 15:07:20 <PureTryOut> That's already happening
2021-11-04 15:07:26 <Ariadne> is it?
2021-11-04 15:07:34 <Ariadne> what version is provided, then?
2021-11-04 15:07:47 <PureTryOut> `=$pkgver-r$pkgrel`, which is lower than jack's
2021-11-04 15:12:11 <ikke> Ariadne: https://tpaste.us/0w7N
2021-11-04 15:18:41 <Ariadne> its because
2021-11-04 15:18:45 <Ariadne> the so:libjack.so.8
2021-11-04 15:18:49 <Ariadne> er, .so.0
2021-11-04 15:18:52 <Ariadne> is not versioned
2021-11-04 15:19:08 <Ariadne> i think
2021-11-04 15:19:55 <PureTryOut> oh yeah pipewire-jack's libs are higher versioned than jack's... Ugh
2021-11-04 15:20:27 <Ariadne> hmm?
2021-11-04 15:20:35 <Ariadne> i'm talking about the so:libjack.so.0 virtual
2021-11-04 15:20:39 <Ariadne> i don't think it is versioned
2021-11-04 15:20:50 <Ariadne> let me check abuild source.
2021-11-04 15:21:28 <PureTryOut> so:libjack.so.0 isn't but there is so:libjack.so.0.1.0. pipewire-jack has so:libjack.so.0.339.0
2021-11-04 15:22:12 <Ariadne> sed 's/^\(.*\) \([0-9].*\)/provides = so:\1=\2/' \
2021-11-04 15:22:19 <Ariadne> hmm
2021-11-04 15:22:24 <Ariadne> okay i see what you're saying
2021-11-04 15:22:26 <Ariadne> :)
2021-11-04 15:22:39 <Ariadne> but my question is
2021-11-04 15:22:41 <Ariadne> what is this \2
2021-11-04 15:22:46 <Ariadne> give me a sec
2021-11-04 15:24:52 <Ariadne> provides = so:libjack.so.0=0.1.0
2021-11-04 15:24:53 <Ariadne> yep
2021-11-04 15:24:55 <Ariadne> thats your issue
2021-11-04 15:25:50 <PureTryOut> 0.1.0 vs 0.339.0?
2021-11-04 15:25:57 <Ariadne> yep
2021-11-04 15:26:14 <PureTryOut> Ok so how do I fix this properly while still allowing users to choose pipewire-jack over regular jack? If at all possible? 😅
2021-11-04 15:26:31 <Ariadne> jack will need to install as libjack.so.0.99999.0
2021-11-04 15:26:33 <Ariadne> or something
2021-11-04 15:26:40 <Ariadne> just rename it and rewire up the symlink
2021-11-04 15:26:43 <PureTryOut> This makes me wish jack2 installed itself as libjack.so.2 damn it
2021-11-04 15:26:43 <Ariadne> it should work fine
2021-11-04 15:26:46 <Ariadne> or patch the build system
2021-11-04 15:26:49 <Ariadne> :)
2021-11-04 15:26:57 <PureTryOut> I'm not sure I want to touch jack at all tbh
2021-11-04 15:27:20 <Ariadne> well, I can comment on the bug
2021-11-04 15:30:32 <PureTryOut> I'm not sure why our jack2 package is actually called jack
2021-11-04 15:34:27 <PureTryOut> I guess for now I'll just revert the pipewire-jack change
2021-11-04 15:35:43 <PureTryOut> jack sets it's "API version" https://github.com/jackaudio/jack2/blob/develop/wscript#L16
2021-11-04 15:35:50 <PureTryOut> I'm not sure if things break if we just patch that
2021-11-04 15:38:12 <Ariadne> no, patching it
2021-11-04 15:38:13 <Ariadne> will be fine
2021-11-04 15:38:20 <Ariadne> just set it to
2021-11-04 15:38:21 <Ariadne> 0.999.0
2021-11-04 15:38:26 <Ariadne> it will do what we want :)
2021-11-04 15:38:53 <PureTryOut> if you say so. if things go wrong I'll just blame you 😂
2021-11-04 15:44:11 <PureTryOut> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27154
2021-11-04 15:44:40 <Ariadne> lets see what CI says
2021-11-04 15:45:27 <PureTryOut> I typod the pkgname somehow, pushed a fix
2021-11-04 15:46:23 <ikke> Ariadne: sounds more like a work-around?
2021-11-04 15:46:39 <Ariadne> ikke: it is a workaround
2021-11-04 15:46:44 <Ariadne> ikke: but the solver is working as intended
2021-11-04 15:47:47 <ikke> but I don't think we should a version as surragate for priority, should we?
2021-11-04 15:48:28 <ikke> what is pipewire-jack upgraded to 0.2.0?
2021-11-04 15:48:32 <ikke> s/is/if/
2021-11-04 15:48:32 <alpine-meetbot> ikke meant to say: what if pipewire-jack upgraded to 0.2.0?
2021-11-04 15:49:22 <PureTryOut> pipewire-jack is 0.339.0 currently, so it's already higher than 0.2.0
2021-11-04 15:50:08 <ikke> ok, 1.0
2021-11-04 15:50:34 <PureTryOut> yeah I get your point
2021-11-04 15:52:55 <ikke> But not sure if there is a way around it, if this happens due to automaticaly dependencies
2021-11-04 15:55:16 <Ariadne> ikke: i agree, but the fix is to change abuild
2021-11-04 15:55:40 <Ariadne> ikke: because in the general sense, we *do* want the solver to consider versions
2021-11-04 15:55:51 <Ariadne> if it did not, then `apk upgrade` would not work
2021-11-04 15:56:11 <ikke> Ariadne: yeah, I'm not arguing against that
2021-11-04 16:17:41 <ikke> But because this is an implicit dependency, I don't think switching to a dependency on a virtual package with a provider_priority would work
2021-11-04 16:18:29 <Ariadne> provider_priority is only tiebreaker
2021-11-04 16:18:35 <Ariadne> if all other things are equal :)
2021-11-04 16:55:20 <nmeum> PureTryOut: it seems you still cannot have both pipewire-dev and jack-dev installed at the same time, try it yourself with `apk add -s pipewire-dev jack-dev`, i.e. you still cannot build mpd
2021-11-04 16:55:37 <nmeum> I think this is because pipewire-dev pulls in pipewire-jack and you cannot have two packages installed which provide jack
2021-11-04 16:56:34 <PureTryOut> why does mpd need both?
2021-11-04 16:57:18 <nmeum> for compiling with support for both the pipewire and the jack audio output backend
2021-11-04 16:57:33 <PureTryOut> it has a native pipewire backend? intereseting
2021-11-04 16:57:41 <nmeum> yes, recently added
2021-11-04 16:57:55 <nmeum> https://musicpd.org/news/2021/10/mpd-0-23-released/
2021-11-04 16:57:59 <PureTryOut> but yes that's an issue
2021-11-04 16:58:18 <Ariadne> that one, i cannot help with
2021-11-04 16:58:45 <nmeum> does pipewire-dev need pipewire-jack?
2021-11-04 16:58:56 <Ariadne> probably not
2021-11-04 16:58:59 <PureTryOut> seems like it, pulls it in automatically. idk why though
2021-11-04 16:59:10 <Ariadne> because default_dev
2021-11-04 16:59:15 <Ariadne> pulls in all subpackages
2021-11-04 16:59:19 <Ariadne> so you'll need to tweak it
2021-11-04 16:59:19 <nmeum> this
2021-11-04 17:00:12 <Ariadne> though i am worried that pipewire-jack isn't actually ABI-compatible with other libjack
2021-11-04 17:00:23 <Ariadne> has this been tested with abi-compliance-checker?
2021-11-04 17:00:41 <PureTryOut> it has not as I didn't know that was a thing. it's implemented to be ABI compatible though
2021-11-04 17:01:04 <Ariadne> we should check, to be sure
2021-11-04 17:01:29 <Ariadne> with all respect, GNOME's opinion on ABI compliance may not be the same as reality's opinion
2021-11-04 17:01:53 <PureTryOut> GNOME? PipeWire is not GNOME lol
2021-11-04 17:23:17 <PJ[m]> shouldn't current doas package be called opendoas?
2021-11-04 17:26:52 <psykose> why would it be
2021-11-04 17:27:20 <PJ[m]> because the upstream calls it opendoas and it collides with another doas port
2021-11-04 17:35:48 <PureTryOut> Ariadne looking into that abi-compliance-checker, but according to Usage info in the project README, it requires a tool abi-dumper which is unpackaged?
2021-11-04 17:36:12 <PureTryOut> oh never mind I should read manpages
2021-11-04 17:36:18 <Ariadne> :)
2021-11-04 17:36:50 <PureTryOut> Seems easier with that tool though lol
2021-11-04 17:41:27 <PureTryOut> Well I'm doing something wrong, binary and source compatibility 0% lol
2021-11-04 17:46:54 <PureTryOut> problem seems to be that without that abi-dumper tool, it requires header files to compare and pipewire just doesn't supply those for pipewire-jack, programs are supposed to link to jack and pipewire-jack can then just replace the library
2021-11-04 17:47:04 <PureTryOut> so, packaging that abi-dumper locally then I suppose
2021-11-04 17:49:30 <ericonr> pretty sure they just vendor the jack headers
2021-11-04 17:56:03 <PureTryOut> yeah ok I can't figure out how to use abi-dumper and abi-compliance-checker properly lol
2021-11-04 18:12:09 <anyuser> test
2021-11-04 18:12:27 <psykose> test passed
2021-11-04 19:14:56 <maxice8> hmm
2021-11-04 19:15:21 <maxice8> go1.17.3 fixes issues in archive/zip and debug/macho
2021-11-05 00:09:40 <eschwartz> Ariadne: "One solution would be to work on getting muon to build OpenRC. This is a reimplementation of Meson in C, which has no outside dependencies other than libpkgconf. But muon does not yet support all Meson features. I'm willing to contribute to adding missing features to muon, as well as maintaining the current buildsystem. We could also make 0.44.x an LTS branch of OpenRC
2021-11-05 00:09:42 <eschwartz> until muon is ready."
2021-11-05 00:09:57 <eschwartz> muon just now added preliminary support for `muon install`
2021-11-05 00:17:34 <eschwartz> PJ[m]: if the other doas port is https://github.com/slicer69/doas/ beware that the author of said port has a really bad reputation, and no one should be using it anyway :)
2021-11-05 00:23:46 <Ariadne> bad reputation?
2021-11-05 00:23:50 <Ariadne> i've never heard of the dude
2021-11-05 00:23:53 <Ariadne> couldn't be that bad
2021-11-05 00:23:54 <Ariadne> :p
2021-11-05 00:25:24 <eschwartz> https://www.patreon.com/sysvinit
2021-11-05 00:25:36 <eschwartz> > Alternatively you might have stumbled across my reviews and tutorials on DistroWatch.
2021-11-05 00:26:26 <eschwartz> also claims to be the coordinator of GNU patch fixes, because GNU just cannot handle it themselves... apparently also champions sysvinit development...
2021-11-05 00:27:05 <eschwartz> if being associated with distrowatch isn't qualifying as a bad reputation, then there is always the actual quality of doas itself: https://π.duncano.de/slicer69-doas.html
2021-11-05 00:27:40 <Ariadne> LOL
2021-11-05 00:47:53 <Ariadne> eschwartz: omg
2021-11-05 00:48:04 <Ariadne> eschwartz: i asked the sysvinit maintainer in devuan if he ever heard of this dude
2021-11-05 00:48:06 <Ariadne> and he was like nope
2021-11-05 00:48:49 <Ariadne> if he is maintaining sysvinit, it is apparently news to a downstream packager of sysvinit
2021-11-05 00:48:55 <Ariadne> i think that tells me all i need to know :D
2021-11-05 00:52:27 <eschwartz> I regret to inform you that the tarballs in their debian/watch file are signed by this dude
2021-11-05 00:53:09 <eschwartz> https://git.savannah.gnu.org/cgit/sysvinit.git/log/?h=3.01
2021-11-05 00:53:56 <eschwartz> curl https://git.devuan.org/devuan/sysvinit/raw/branch/suites/unstable/debian/upstream/signing-key.asc | gpg --list-packets
2021-11-05 00:54:03 <eschwartz> :user ID packet: "Jesse Smith <jsmith@resonatingmedia.com>"
2021-11-05 00:57:19 <Ariadne> apparently, he is maintaining it
2021-11-05 00:57:19 <Ariadne> wow
2021-11-05 00:57:23 <Ariadne> wtf
2021-11-05 00:57:40 <eschwartz> I suspect literally no one else wanted to touch it
2021-11-05 00:57:48 <Ariadne> probably
2021-11-05 00:58:09 <Ariadne> well none the less, i have alerted my fellow eudev maintainers to look carefully at his patches
2021-11-05 01:00:34 <eschwartz> > Please get in touch if you are a downstream eudev package maintainer who wants to get patches sent upstream.
2021-11-05 01:00:46 <eschwartz> he wants people to go through him to communicate with eudev
2021-11-05 01:05:05 <Ariadne> uhh
2021-11-05 01:05:06 <Ariadne> no
2021-11-05 01:05:26 <Ariadne> they can literally open a PR
2021-11-05 01:05:32 <Ariadne> like
2021-11-05 01:05:38 <Ariadne> what does he think he is going to do
2021-11-05 01:05:42 <Ariadne> he is not a committer
2021-11-05 01:06:23 <eschwartz> well you know
2021-11-05 01:06:25 <eschwartz> >  Another project I am currently working on is GNU Patch. The Patch command is used by many developers in the open source community. Unfortunately, the current version of Patch has a number of bugs and the utility has not been updated in over a year. I am making an effort to fix known bugs and coordinate improvements with distributions to make patch a better, safer development
2021-11-05 01:06:27 <eschwartz> tool.
2021-11-05 01:06:41 <eschwartz> it's not just eudev he thinks he needs to personally handhold
2021-11-05 01:06:54 <eschwartz> "coordinate improvements with distributions"
2021-11-05 01:07:43 <Ariadne> https://github.com/eudev-project/eudev#readme
2021-11-05 01:07:48 <Ariadne> i do not see his name on this list
2021-11-05 01:07:53 <Ariadne> maybe i missed it
2021-11-05 01:08:19 <Ariadne> i mean, he's free to open PRs, of course
2021-11-05 01:20:12 <Ariadne> eschwartz: https://twitter.com/ariadneconill/status/1456430248988495878 is pretty much all i have to say about it
2021-11-05 01:21:00 <Ariadne> i will be glad to commit any reasonable and correct patch to eudev for $0, there is no need to engage with that grifter, who does not even have commit rights anyway
2021-11-05 01:25:06 <Ariadne> eschwartz: it seems the one (1) patch he landed in eudev is being reverted because he didn't even do it right
2021-11-05 01:25:18 <Ariadne> the systemd commit hash is wrong
2021-11-05 01:26:48 <eschwartz> that is actually hilarious
2021-11-05 01:27:40 <sam_> i have also not heard of this person or any efforts involving patch
2021-11-05 01:27:47 <sam_> this is.. interesting
2021-11-05 01:27:57 <sam_> is patch rotting? yes
2021-11-05 01:28:06 <sam_> have they made some sort of fork? not that i'm aware of
2021-11-05 01:31:52 <Ariadne> well i am sure, he can solve that for you, if you just join his patreon at the appropriate tier
2021-11-05 01:32:34 <sam_> oh great
2021-11-05 01:33:41 <Ariadne> eschwartz: we have discovered the systemd patch he ported, is actually wrong, too
2021-11-05 01:33:43 <Ariadne> amazing
2021-11-05 01:36:41 <eschwartz> I'm not... completely shocked
2021-11-05 01:38:09 <eschwartz> I did like how the systemd commit hash mentioned in the grifter's PR, pointed to something that was apparently an old revision of the systemd PR -- it warned me that the commit was not on any branch, and I found a different version of the commit actually merged to systemd 
2021-11-05 01:38:22 <eschwartz> I wonder how one even accidentally manages that?
2021-11-05 01:39:46 <eschwartz> anyway, I futzed around a bit and added one of the last missing bits of meson language support which openrc needs, to muon
2021-11-05 01:39:55 <eschwartz> string.to_lower
2021-11-05 01:40:09 <eschwartz> and I think now you just need meson.add_install_script() and vcs_tag
2021-11-05 03:15:59 <earboxer> I'm trying to build a projects which uses cmake and boost-dev, but it fails with "No rule to make target '/usr/lib/libboost_context.a'" (while we only have .so's installed)
2021-11-05 03:35:15 <earboxer> (Checking my CMakeCache.txt file, it seems like this can be configured with a -DBoost_CONTEXT_LIBRARY_RELEASE=/usr/lib/libboost_context.so, so I guess I'll see after a bit whether this worked.)
2021-11-05 06:13:27 <smcavoy> ev
2021-11-05 06:17:05 <smcavoy> c
2021-11-05 06:17:30 <smcavoy> whoops... wrong window
2021-11-05 07:25:32 <PJ[m]> eschwartz: interesting, thanks for elaborate answer, nonetheless I still think distros shouldn't use different package name without reason :p 
2021-11-05 08:07:47 <mps> good morning
2021-11-05 08:08:29 <mps> how to quote reply in gitlab when answering to message there (in web ui)
2021-11-05 08:14:52 <mps> maybe 'proper' question is: can I answer to these msgs by mail?
2021-11-05 08:23:21 <mps> answer by mail works, though it looks somewhat strange
2021-11-05 08:56:18 <ikke> morning
2021-11-05 08:58:23 <Misthios> gm
2021-11-05 09:00:44 <maxice8> morning
2021-11-05 09:01:50 <maxice8> pushed go security upgrades and rebuilds 
2021-11-05 09:02:12 <ikke> how did you determined the archive/zip users?
2021-11-05 09:03:31 <maxice8> Ikke: https://gist.github.com/maxice8/a3c83e466c9aeae081cb9468840d00fe
2021-11-05 09:04:29 <ikke> interesting, using file
2021-11-05 09:04:39 <ikke> does that work for stripped binaries?
2021-11-05 09:05:40 <maxice8> most likely yes, not entirely sure
2021-11-05 09:06:05 <maxice8> works
2021-11-05 09:06:05 <maxice8> strip -s ~/go/bin/gopls; strings ~/go/bin/gopls | grep -x archive/zip 
2021-11-05 09:06:16 <ikke> and if they are built with -s -w?
2021-11-05 09:06:26 <ikke> -ldflagfs '-s -w'
2021-11-05 09:07:25 <maxice8> yes as far as I can tell
2021-11-05 09:07:27 <ikke> zok
2021-11-05 09:07:50 <ikke> does that also work for third-party modules?
2021-11-05 09:07:55 <ikke> I could probably check myself
2021-11-05 09:08:12 <maxice8> yes if they are used
2021-11-05 09:08:33 <maxice8> strings ~/bin/alt-tab-daemon | grep -x github.com/joshuarubin/go-sway works
2021-11-05 09:08:41 <maxice8> and I build it with -ldflags="-s -w" and -trimpath
2021-11-05 09:09:05 <maxice8> https://gitlab.com/maxice8/meltryllis/-/blob/master/mkfile#L66
2021-11-05 09:10:49 <maxice8> looking at restic
2021-11-05 09:12:08 <ikke> I wonder if there is a more structured way to extact this information
2021-11-05 09:13:28 <maxice8> someone somewhere probably wrote a neat small binary that prints the modules used in a go binary
2021-11-05 09:15:02 <maxice8> https://pkg.go.dev/runtime/debug#ReadBuildInfo
2021-11-05 09:15:16 <maxice8> https://pkg.go.dev/runtime/debug#Module
2021-11-05 09:17:53 <ikke> That's more for introspection (runtime info)
2021-11-05 09:27:35 <maxice8> yeah
2021-11-05 12:16:28 <Ariadne> good morning: i plan to push eudev prerelease to edge, it should be safe
2021-11-05 12:16:59 <Ariadne> also openssl switch finally
2021-11-05 12:19:11 <ikke> Ariadne: what was the delay of 3.15 release about btw?
2021-11-05 12:19:41 <Ariadne> apparently jirutka has some things he wants to resolve
2021-11-05 12:19:45 <Ariadne> i can ask for more info
2021-11-05 12:24:05 <Ariadne> he wants to rework postgresql
2021-11-05 12:24:22 <Ariadne> so that people don’t stress out over the upgrade
2021-11-05 12:25:15 <ikke> I suppose by having both the current and the new version installable?
2021-11-05 12:25:37 <Ariadne> yes
2021-11-05 12:25:54 <Ariadne> i think it has merit
2021-11-05 12:26:02 <Ariadne> since we upgraded to 14 with this release
2021-11-05 12:26:08 <ikke> yes, I noticed
2021-11-05 12:26:21 <ikke> He should open an issue for it to track it
2021-11-05 12:27:10 <Ariadne> i asked him to join irc for this discussion
2021-11-05 12:29:16 <Habbie> Ariadne, openssl switch? to 3 again?
2021-11-05 12:29:37 <ikke> Habbie: no
2021-11-05 12:29:45 <ikke> Just the package names
2021-11-05 12:29:52 <Habbie> ah :)
2021-11-05 12:54:41 <donoban> ouch
2021-11-05 12:54:49 <donoban> Error loading shared library libjack.so.0: No such file or directory (needed by /usr/bin/mpv)
2021-11-05 12:55:14 <dalias> is this with pipewire? i think they had some bug with their rpaths or something
2021-11-05 12:55:29 <donoban> yes I run pipewire and pipewire-pulse
2021-11-05 13:06:37 <streampunk> donoban: libjack.so is in pipewire-jack
2021-11-05 13:08:37 <donoban> uhM, let's try
2021-11-05 13:09:16 <donoban> yeah it works fine now
2021-11-05 13:10:15 <PureTryOut> if you didn't have pipewire-jack, jack itself should've been installed
2021-11-05 13:24:41 <donoban> yes I have it installed as some dependency
2021-11-05 13:24:54 <donoban> is this the desired behaviour or should it be improved?
2021-11-05 13:43:04 <ncopa> ncopa-desktop:~$ uname -a
2021-11-05 13:43:04 <ncopa> Linux ncopa-desktop 5.15.0-0-lts #1-Alpine SMP Fri, 05 Nov 2021 12:00:48 +0000 x86_64 GNU/Linux
2021-11-05 13:43:54 <ncopa> i wonder if i shoudl just push it, or if I should change the kernel module compression to gz so it works with busybox modprobe. Currently it needs kmod (+1.5MB in size)
2021-11-05 13:44:08 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12857#note_190285
2021-11-05 13:46:44 <ncopa> Ariadne: re jirutka and postgresql/IRC. I think its ok that he don't want talk in IRC but an issue would be nice
2021-11-05 13:47:07 <Ariadne> ncopa: yes, i asked him to open a tracking issue, so we can mark it as a blocker
2021-11-05 13:47:26 <ncopa> :+1: thanks!
2021-11-05 13:48:05 <ncopa> i think I'm gonna push 5.15 kernel with zstd modules, and build it locally with gz to have something to compare with.
2021-11-05 13:48:18 <Ariadne> i think that busybox has a patch to enable zstd support
2021-11-05 13:48:25 <Ariadne> i saw something like that on the list
2021-11-05 13:48:30 <ncopa> really? that would be awesome
2021-11-05 13:48:35 <psykose> zstd seems to be about 2/3 ratio there, i wonder what gz would be in comparison
2021-11-05 13:49:01 <psykose> if i remember correctly from playing around with it on gentoo it was maybe 80%? so worth it even with kmod
2021-11-05 13:49:01 <Ariadne> eudev 3.2.11_pre1 has been pushed to edge, please test it and let me know if it blows up
2021-11-05 13:49:11 <Ariadne> it works for me, so
2021-11-05 13:49:13 <Ariadne> :p
2021-11-05 13:49:18 <ncopa> psykose: that is what I suspect too
2021-11-05 13:49:33 <Ariadne> (i also took maintainership, since i am eudev upstream anyway)
2021-11-05 13:49:44 <Ariadne> (and, unlike that sysvinit patreon dude, i actually *am* eudev upstream :))
2021-11-05 13:49:51 <fcolista> :)
2021-11-05 13:50:04 <fcolista> so you can commit to your git repo? lol
2021-11-05 13:50:06 <Ariadne> yes
2021-11-05 13:50:10 <Ariadne> i know, its a novel concept
2021-11-05 13:50:16 <ncopa> thats what I was afraid of would happen... I hope you don't burn out yourself
2021-11-05 13:50:21 <psykose> ncopa: https://www.mail-archive.com/busybox@busybox.net/msg27734.html i believe this is the patch for busybox
2021-11-05 13:50:36 <ncopa> but really, i cannot think of any better maintainer for eudev, so it is great
2021-11-05 13:50:41 <fcolista> +
2021-11-05 13:50:43 <Ariadne> ncopa: bb|hcb from debian is actually doing most of the work
2021-11-05 13:50:44 <fcolista> +1
2021-11-05 13:50:54 <Ariadne> and devuan, i suppose
2021-11-05 13:51:47 <Ariadne> ncopa: jirutka says there is an MR already, he is just working to finish it, and that the MR is marked as a blocker
2021-11-05 13:52:02 <Ariadne> so sounds like everything is in order
2021-11-05 13:52:14 <ncopa> awesome
2021-11-05 13:52:36 <Ariadne> though umm
2021-11-05 13:52:47 <Ariadne> i think we are going to diverge from systemd udev source
2021-11-05 13:52:50 <psykose> Ariadne: rebooted with new eudev, everything still seems to work :)
2021-11-05 13:52:55 <Ariadne> we've found some uhh, not very good code
2021-11-05 13:53:00 <ncopa> im gonna reboot my desktop with new eudev. if i dont come back its because it blew up...
2021-11-05 13:53:00 <Ariadne> that needs to be rewritten asap
2021-11-05 13:53:14 <Ariadne> but that will wait for "4.0"
2021-11-05 13:54:50 <ncopa> and im back! eudev didnt blew up my desktop (yet)
2021-11-05 13:54:59 <psykose> lucky us
2021-11-05 13:56:17 <ncopa> ok, 5.15 kernel pushed to edge
2021-11-05 13:56:59 <mps> ncopa: I don't think it is worth compressing modules, you got some space but also could lost in boot time on small and old machines
2021-11-05 13:57:03 <Ariadne> anyway, we've found some very bad code, written by a mr. *squints* lennart poettering?  is that right?  that needs to be rewritten, as it leaks memory
2021-11-05 13:57:44 <Ariadne> i plan to rewrite his rewrite of the udev rules parser with byacc
2021-11-05 13:57:48 <Ariadne> should be fun
2021-11-05 14:02:43 <ncopa> mps: lets see how bit the performance loss is on small machines. I suspect they are not that big. might even improve performance if storage is slow
2021-11-05 14:03:38 <ncopa> mps: lease also check if there are anythinkg in the -lts kernel you think should be configured differently. or some drivers are missing or anything
2021-11-05 14:04:52 <ncopa> mps: i mean, i would appreciace if you had a review of what I did. you do have some experience with kernel configs now
2021-11-05 14:05:06 <mps> ncopa: 'lease'? maybe you meant 'please'?
2021-11-05 14:05:20 <ncopa> i meant please :) 
2021-11-05 14:05:25 <mps> :) ok
2021-11-05 14:05:43 <mps> will look this evening
2021-11-05 14:06:12 <ncopa> appreciate! thanks
2021-11-05 14:06:52 <ncopa> have a nice weekend!
2021-11-05 14:07:08 <mps> but expect big diff without much comments ;)
2021-11-05 14:07:45 <mps> enjoy you life and nice weekend
2021-11-05 14:10:45 <jvoisin> Ariadne: put your changes upstream?
2021-11-05 14:11:03 <Ariadne> jvoisin: upstream?
2021-11-05 14:11:14 <Ariadne> jvoisin: i have no interest in fighting a battle with lennart
2021-11-05 14:12:01 <Ariadne> as far as i'm concerned, eudev is eudev, there is no 'upstream'
2021-11-05 14:12:20 <Ariadne> we import changes from systemd, if they make sense, but lately changes do not make sense so much :)
2021-11-05 14:13:57 <jvoisin> :)
2021-11-05 14:15:19 <omni> 🖒
2021-11-05 14:30:39 <caskd> are there any images which enable ssh and dhcp/static ip at start for bootstrapping?
2021-11-05 14:30:46 <caskd> trying to get alpine on a rockpro64
2021-11-05 14:33:13 <Hello71> mps: with fast decompressor, compression improves speed by reducing i/o
2021-11-05 14:33:49 <Hello71> if you want to make old machines faster we should change xz to zstd
2021-11-05 14:35:15 <Hello71> actually how is the cdrom shrinking by 30 MB anyways
2021-11-05 14:35:24 <Hello71> aren't the files all in squashfs
2021-11-05 14:35:50 <mps> kernel apk is already compressed
2021-11-05 14:38:00 <mps> I didn't tested zstd on old CPUs so don't know is fast 'enough'
2021-11-05 14:38:20 <Hello71> huh? kernel apk isn't used for anything important
2021-11-05 14:38:40 <mps> I mean on distro media it is
2021-11-05 14:40:01 <mps> long ago I thought to enable kmods gz/xz but didn't because I didn't found this much important
2021-11-05 14:41:56 <mps> caskd: maybe this could help #13157
2021-11-05 14:42:56 <mps> OP booted on its box, which is surprise to me
2021-11-05 14:45:31 <Hello71> for alpine iso isn't it kernel image, initramfs, and modloop? where is kernel apk
2021-11-05 14:46:18 <mps> iirc base pkgs are on iso also, though not sure for kernel
2021-11-05 14:52:03 <PureTryOut> `py3-filelock-3.0.12-r3: breaks: world[py3-filelock>=3.3.0]` uh, what? why doesn't it just install 3.3.0 (which I have in a local repo)?
2021-11-05 14:52:26 <Saijin_Naib[m]> eudev + linux-lts (5.10.x) no problem with the latest upgrade of eudev
2021-11-05 15:15:33 <mps> ncopa: linux-lts failed on x86 with 'zstd: error 11 : Allocation error : not enough memory'
2021-11-05 15:16:35 <mps> (my gut feeling told that is too early to switch to zstd)
2021-11-05 15:18:18 <Hello71> yes, there is unfortunate issue that cat file | zstd allocates 1.5 GB
2021-11-05 15:18:30 <ericonr> wat
2021-11-05 15:19:05 <Hello71> and kernel uses cat file file2 | zstd. i have a workaround patch to do cat file file2 > file.tmp; zstd file.tmp
2021-11-05 15:19:53 <mps> zstd is made for big co
2021-11-05 15:19:58 <Hello71> zstd allocates all buffers upfront based on file size, but with pipe you don't know file size so it allocates maximum buffer
2021-11-05 15:20:54 <mps> I thing switch to xz is good compromise for now
2021-11-05 15:21:06 <mps> think*
2021-11-05 15:21:13 <Hello71> xz is very slow, especially kernel xz
2021-11-05 15:21:33 <mps> yes, but works
2021-11-05 15:21:34 <Hello71> in particular xz decompression is very slow. zstd compression is slow but decompression is very fast
2021-11-05 15:21:35 <ericonr> Hello71: I couldn't reproduce it, does it still happen for you?
2021-11-05 15:22:04 <Hello71> ericonr: i had this problem about a year ago. note that it doesn't *use* all the ram
2021-11-05 15:22:17 <Hello71> so it works as long as you have at least 1 GB total, but not if you have 512 MB
2021-11-05 15:22:46 <Hello71> it also works if you enable unrestricted overcommit
2021-11-05 15:22:58 <mps> Hello71: then compromise could be gz
2021-11-05 15:23:09 <ericonr> Hello71: it should show in VSZ, no?
2021-11-05 15:23:27 <Ariadne> mps: yes, go ahead and switch it to GZ for all kernels
2021-11-05 15:23:30 <Hello71> ericonr: yes
2021-11-05 15:23:50 <mps> Ariadne: ok
2021-11-05 15:24:03 <Ariadne> oh wow
2021-11-05 15:24:12 <Ariadne> i'm in LWN again
2021-11-05 15:24:53 <mps> heh, will read after coffee
2021-11-05 15:25:13 <mps> your writings are interesting
2021-11-05 15:25:50 <Ariadne> oh, it's a short story about how me, and awilfox from adelie wound up working at an adtech
2021-11-05 15:26:06 <Ariadne> and a sampling of the fucked up shit they were doing
2021-11-05 15:41:24 <minimal> Ariadne: you forgot to recommend people to use an adblock-blocker-blocker ;-)
2021-11-05 15:41:37 <Ariadne> ublock origin does both
2021-11-05 15:42:27 <minimal> unhappy that Firefox Mobile (or whatever its called now) only lets you install a limited set of plugins, not including uMatrix :-(
2021-11-05 15:44:51 <Ariadne> i use adguard on my iphone
2021-11-05 15:44:53 <Ariadne> it works well
2021-11-05 15:50:21 <psykose> firefox beta lets you use regular ublock origin
2021-11-05 15:50:25 <psykose> on mobile
2021-11-05 15:51:16 <PureTryOut> Not just beta, regular Firefox for Android too
2021-11-05 15:51:39 <psykose> ah, they updated? last i checked (ages ago now) it was the 'beta' only
2021-11-05 15:51:44 <psykose> nice :)
2021-11-05 15:51:54 <PureTryOut> I have used it for ages, literal months if not even a year
2021-11-05 15:56:29 <minimal> PureTryOut: will have to look again, Fennec (or whatever the Firefox for Anroid is called) certainly is past only supported something like 7 or 9 specific plugins and then the added "collections" for some more plugins but you could not install arbitrary plugins like you can with desktop edition
2021-11-05 15:56:52 <PureTryOut> oh yeah that's still the case, but uBlock Origin is one of the few supported ones
2021-11-05 15:57:00 <MY-R> hey, why "apk search rng" showing only -extra packages? but when do apk add rng-tools then installing it without problem
2021-11-05 15:57:12 <minimal> PureTryOut: note I said uMatrix, not uBlock Origin
2021-11-05 15:57:23 <PureTryOut> I know
2021-11-05 15:57:28 <PureTryOut> I was responding to psykose 
2021-11-05 15:57:35 <PureTryOut> who said uBlock Origin 😉
2021-11-05 15:57:55 <minimal> uBlock Origin is not as flexible as uMatrix with its nice dropdown matrix of alow/block options
2021-11-05 15:58:13 <PureTryOut> I don't think uMatrix's UI would work well on mobile
2021-11-05 15:58:24 <minimal> PureTryOut: tablet?
2021-11-05 15:58:28 <PureTryOut> ah sure
2021-11-05 15:58:59 <psykose> ubo has a matrix in advanced mode, but it's not per request/feature type, not as in-depth sadly
2021-11-05 15:59:07 <psykose> wish you could combine the two
2021-11-05 16:01:57 <minimal> psykose: indeed
2021-11-05 16:12:01 <Ariadne> i used to use ublock origin on firefox on android like years ago
2021-11-05 16:12:05 <Ariadne> its not new :)
2021-11-05 16:17:21 <Ariadne> mps: do you have any plan to switch to GZ for modules? :)
2021-11-05 16:18:30 <mps> I'm testing on armv7
2021-11-05 16:18:52 <mps> looks like it pass on all arches except x86
2021-11-05 16:19:41 <mps> I could switch to GZ with few 'sed' invocation, but tbh don't like to argue again with ncopa
2021-11-05 16:20:36 <mps> so if it fails again on x86 I think to use GZ only on it and left rest to ncopa to decide whatever he wants
2021-11-05 16:21:15 <omni> zstd --size-hint=?
2021-11-05 16:21:23 <mps> Ariadne: what is you opinion
2021-11-05 16:21:43 <Ariadne> okay lets see what happens
2021-11-05 16:50:24 <mps> Ariadne: pushed, lets see will it pass now
2021-11-05 16:52:56 <Ariadne> mps: i texted ncopa to let him know, so he can provide other instructions
2021-11-05 16:55:45 <mps> I don't like to annoy him (or anyone) when he is of, only would call in emergency
2021-11-05 16:56:21 <Ariadne> yes, but in this case, i wanted to ask if he wanted us to back out zstd on everything or just x86
2021-11-05 16:56:31 <Ariadne> :)
2021-11-05 16:56:55 <Ariadne> mps: he says he will look into it on monday, to see if zstd can be fixed on x86
2021-11-05 16:57:04 <Ariadne> :)
2021-11-05 16:57:18 <mps> my another thinking will this make some bootloaders 'happy' when they find they couldn't uncompres zstd vmlinuz :)
2021-11-05 16:57:56 <Ariadne> ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'mmu_feature_keys'
2021-11-05 16:57:57 <Ariadne> hmm
2021-11-05 16:58:05 <mps> ohm, I really need coffee, kernel uncompres self
2021-11-05 16:59:12 <mps> this should be akms pkg
2021-11-05 16:59:39 <mps> AKMS
2021-11-05 16:59:50 <ericonr> Ariadne: which kernel version is that?
2021-11-05 17:00:12 <mps> ericonr: 5.15 I think
2021-11-05 17:01:40 <ericonr> Hm, I know people running zfs on 5.15 D:
2021-11-05 17:03:14 <omni> 
ACTION plays it long term safe

2021-11-05 17:03:40 <Ariadne> ericonr: 5.15 on ppc64le
2021-11-05 17:03:51 <ericonr> Aah
2021-11-05 17:04:07 <ericonr> We had to disable spinlock something a while ago on ppc64le because of zfs
2021-11-05 17:04:14 <ericonr> But that was 5.10 I think 
2021-11-05 17:30:29 <minimal> MY-R: not sure why it does that, "apk info rng-tools" shows info on both rng-tools and rng-tools-extra. Maybe I didn't set up the "provides" correctly...
2021-11-05 17:37:18 <Hello71> omni: last i checked it either didn't exist or didn't work
2021-11-05 17:37:34 <HRio> Ariadne: OpenZFS 2.1.1: Linux: compatible with 3.10 - 5.14 kernels
2021-11-05 17:38:57 <HRio> https://github.com/openzfs/zfs/issues/12590
2021-11-05 17:39:30 <HRio> https://git.launchpad.net/ubuntu/+source/zfs-linux/tree/debian/patches/ubuntu/4900-ppc-get-user-workaround.patch
2021-11-05 17:40:06 <MY-R> minimal: yeah, weird
2021-11-05 17:40:32 <MY-R> minimal: got it on "stable"
2021-11-05 17:42:31 <minimal> MY-R: "apk search -a rng" shows perhaps what you were expecting?
2021-11-05 17:43:12 <MY-R> minimal: yes!
2021-11-05 17:49:45 <Ariadne> HRio: i can check it in a bit
2021-11-05 18:34:39 <mps> what are these MRs with msg "rebuild with sdl12-compat-dev"
2021-11-05 19:00:09 <Nulo> Is there a way to install the dev dependencies of a package outside of aports/abuild?
2021-11-05 19:13:43 <omni> Hello71: yeah, could be a new feature, still worth a try?
2021-11-05 19:16:25 <Ariadne> mps: to remove sdl1
2021-11-05 19:16:37 <Hello71> ericonr: can't reproduce it anymore, probably they fixed it
2021-11-05 19:17:24 <Hello71> ah, wait, i checked, you need to pass --ultra -22 for it to allocate 1.5 GB
2021-11-05 19:17:38 <mps> Ariadne: msg is somewhat misleading to me. I thought it is to build with sdl1 and not with sdl2
2021-11-05 19:18:45 <Hello71> echo | busybox time -v zstd --ultra -22 -c > /dev/null: Maximum resident set size (kbytes): 2665264 on glibc (my alpine machines don't have enough ram)
2021-11-05 19:19:24 <Ariadne> mps: there is a library called sdl12-compat that implements the sdl1 api on sdl2
2021-11-05 19:19:47 <mps> Ariadne: aha, thanks
2021-11-05 19:20:01 <mps> now understand
2021-11-05 19:20:27 <Ariadne> :)
2021-11-05 19:21:08 <Hello71> omni: seems to work with either
2021-11-05 19:21:37 <mps> like openssl1.1-compat that implement openssl 1.1 api on openssl 3.0 :D
2021-11-05 19:22:13 <mps> I know, I know, jk
2021-11-05 19:23:29 <Hello71> omni: thanks
2021-11-05 19:40:19 <Hello71> mps: gzip decompression is also slower than zstd. based on my benchmark few years ago (zstd should be faster now), zstd is about 4x faster than gzip for decompressing kernel on x86_64. so if you spend 1 second decompressing kernel on gzip then it will shave off 0.75 seconds from your boot
2021-11-05 19:40:24 <Hello71> which is not huge but not negligible either
2021-11-05 19:41:28 <logan2611[m]> zstd is indeed quite fast, and has better compression ratio than gzip too iirc
2021-11-05 19:43:42 <Hello71> only at max settings (zstd -19 vs gzip -9). if you compare for same compression time cost then gzip wins
2021-11-05 19:44:03 <Hello71> but for building distro kernel nobody cares if it takes 10 seconds or 20 seconds to compress
2021-11-05 19:45:28 <Hello71> gzip/deflate is excellent algorithm for its time. modern algorithms are much faster to compress, faster to decompress, or smaller, but afaik nobody has managed to consistently beat deflate on all three
2021-11-05 19:45:53 <Hello71> (consistently and significantly, if you get -1% on each nobody cares)
2021-11-05 19:46:26 <minimal> wonder what different gzip and zstd would make to RPI (or indeed other lowend ARM-based systems) boot times
2021-11-05 19:47:06 <logan2611[m]> xz might be another good one to consider
2021-11-05 19:47:13 <mps> most reasonable option is *do not compress* modules
2021-11-05 19:48:49 <Hello71> logan2611[m]: xz is awful for kernel compression unless you desperately need size at all costs. it is extremely slow to decompress
2021-11-05 19:48:51 <minimal> mps: you mean for Arm? there's a trade off of smaller modules mean less to load from slow SDcards versus time on "slow" ARM CPU to decompress them when needed (thinking of sys-mode system, not run-from-ram)
2021-11-05 19:49:06 <Hello71> only one worse is bzip2 which is slower to compress, slower to decompress, and larger
2021-11-05 19:49:13 <logan2611[m]> yeah I was just thinking about that
2021-11-05 19:49:27 <mps> minimal: I mean for all
2021-11-05 19:49:49 <Hello71> just checked recompressing x86_64 linux-lts to gzip, size increases by ~15%
2021-11-05 19:50:02 <Hello71> about 1 MB
2021-11-05 19:50:41 <logan2611[m]> I thought Alpine's kernels were already gzip
2021-11-05 19:51:19 <mps> logan2611[m]: most arch kernels are but not modules, till today
2021-11-05 19:51:28 <logan2611[m]> ah
2021-11-05 19:52:08 <Hello71> logan2611[m]: ncopa upgraded to 5.15 and switched to zstd
2021-11-05 19:52:12 <Hello71> today
2021-11-05 19:52:27 <Hello71> i think 5.10 doesn't have zstd
2021-11-05 19:52:46 <mps> Hello71: right
2021-11-05 19:53:23 <mps> but my memory is little fog-ed about exact version where zstd appeared
2021-11-05 19:55:26 <logan2611[m]> looks like 5.13
2021-11-05 19:56:07 <logan2611[m]> wait
2021-11-05 19:56:11 <mps> could be, but I forgot
2021-11-05 19:56:24 <mps> and don't want to look :)
2021-11-05 19:56:44 <logan2611[m]> fair
2021-11-05 19:56:48 <Hello71> i still don't understand how it is possible for modloop to shrink with kernel module compression. it should grow slightly
2021-11-05 19:57:03 <mps> Hello71: :)
2021-11-05 19:57:10 <mps> ofc
2021-11-05 19:57:46 <mps> but will be 'marketing friendly' in release notes ;)
2021-11-05 19:59:03 <mps> about year or two ago I tested compressed modules on my machines and didn't found any benefit with this
2021-11-05 19:59:22 <Hello71> omni: oddly --stream-size/--size-hint causes compressed size to grow by ~300 bytes. --stream-size causes +3 bytes which is expected, but 300 bytes is not
2021-11-05 20:03:58 <omni> Hello71: I haven't compared myself.. the man page says --stream-size need to be exact not to cause errors, and the closer to exact with --size-hint the better the compression
2021-11-05 20:04:42 <omni> that's all I know =)
2021-11-05 20:06:04 <Hello71> mps: my point is i don't want to have new for sake of new, but i also don't want to have old for sake of old
2021-11-05 20:06:45 <mps> Hello71: I agree with mindset
2021-11-05 20:08:27 <omni> I used to use xz for most of my compression needs until last year, when I built a backup solution (with restic) and found it to be unacceptably slow for the task and I think that's when I found how great zstd was, also compared to gzip for that
2021-11-05 20:10:06 <mps> I'm not against compression but we should carefully look at pro and cons and not just jump to 'new and shiny'
2021-11-05 20:13:01 <Hello71> omni: unfortunately zstd is still bigger than xz
2021-11-05 20:14:27 <Hello71> afaik 7-zip lzma2 and ppmd are currently the best general-purpose compressors, taking into account comp/decomp speed, size, and usability (nobody wants to rely on some sketchy binary from encode.ru for critical backups)
2021-11-05 20:14:46 <Hello71> and 7-zip even has proper linux version now
2021-11-05 20:18:30 <mps> what is ppmd?
2021-11-05 20:20:33 <Hello71> "the compression algorithm PPMd, a variant of the Prediction by partial matching (PPM) compression technique", "Prediction by partial matching (PPM) is an adaptive statistical data compression technique based on context modeling and prediction."
2021-11-05 20:20:44 <Hello71> mainly useful for text afaik
2021-11-05 20:21:33 <Hello71> or maybe other similar low-entropy data
2021-11-05 20:21:39 <Hello71> s/similar //
2021-11-05 20:21:39 <alpine-meetbot> Hello71 meant to say: or maybe other low-entropy data
2021-11-05 20:24:19 <mps> thanks
2021-11-05 22:26:43 <Saijin_Naib[m]> What would be the best way to debug random hard-crash/freeze under the new 5.15.x LTS?
2021-11-05 22:30:13 <MY-R> when I hear "random" after kernel upgrade I have goose skin... :\
2021-11-05 22:31:13 <Saijin_Naib[m]> MY-R: I would be incredibly surprised if this was anything other than something isolated to my particular hardware
2021-11-05 22:31:22 <Saijin_Naib[m]> So, I wouldn't worry 🙂
2021-11-05 22:31:53 <Saijin_Naib[m]> I'm using a rather low-end Intel Reference Platform based notebook with questionable UEFI firmware, haha
2021-11-05 22:33:13 <MY-R> I would wait at least next 6 releases until call 5.15 LTS/stable one
2021-11-05 22:34:48 <MY-R> not to mention drm stuff is often broken while fresh :\
2021-11-05 22:35:26 <Saijin_Naib[m]> I was kind of fearing this since I was having the same random hangs on the Linux-edge kernel, but I was hoping it was due to the different kernel config. 
2021-11-05 22:37:31 <MY-R> I have got such a hope too and figured out that my intel haswell+ gpu working best/stable only on 5.4 kernels unfortunately
2021-11-05 22:42:32 <kunkku> I just updated to 5.15.0
2021-11-05 22:42:54 <Saijin_Naib[m]> How'd it go for you? What Gen CPU are you on? 
2021-11-05 22:43:04 <kunkku> I use disk encryption on my laptop
2021-11-05 22:43:36 <kunkku> the "Enter passphrase" prompt is no longer visible because it does not switch to text mode
2021-11-05 22:44:18 <kunkku> took a few minutes to figure out that you can actually enter the passphrase
2021-11-05 22:44:32 <MY-R> kunkku: intel?
2021-11-05 22:44:50 <kunkku> yes
2021-11-05 22:45:38 <ericonr> kunkku: has cryptsetup been updated?
2021-11-05 22:45:51 <ericonr> It had a release fixing that behavior recently 
2021-11-05 22:46:05 <mps> my old macbook (2009) intel i3 works fine with linux-edge 5.15.0
2021-11-05 22:46:54 <kunkku> 2.4.1
2021-11-05 22:47:06 <MY-R> guys, please report the issues after upgrade on https://gitlab.alpinelinux.org/alpine/aports/-/issues or next Alpine release will be just bad
2021-11-05 22:47:35 <Saijin_Naib[m]> Hmm... Maybe I am doing something wrong with my Apollo Lake 
2021-11-05 22:48:09 <Saijin_Naib[m]> If the issue is isolated to me and I can't reproduce it or figure out what is going wrong, is it worth reporting? 
2021-11-05 22:48:13 <MY-R> doesnt matter, upgrade shouldnt break your current setup
2021-11-05 22:52:59 <MY-R> Saijin_Naib[m]: if you remove all non default modifications which you made and check and the problem still persist then is always worth to report
2021-11-05 22:59:45 <Saijin_Naib[m]> MY-R: i assume you mean edited modules files, grub config, etc, right? Should I disable TLP too? 
2021-11-05 23:05:42 <MY-R> Saijin_Naib[m]: try keep things as default as possible
2021-11-05 23:06:35 <Saijin_Naib[m]> Understood. This is my daily, so it's a far cry from a clean baseline install, but I didn't force much by way of configs. 
2021-11-05 23:09:28 <MY-R> Saijin_Naib[m]: keep it clean and if it wont help then create the issue, probably wont be related with Alpine itself but then people will keep in mind that something doesnt work like should
2021-11-05 23:18:42 <Saijin_Naib[m]> Heh... I can't get into my DE without freezing. Fine seemingly forever in console session
2021-11-06 03:57:36 <obw> hey so uhhh
2021-11-06 03:57:38 <obw> moon's haunted
2021-11-06 03:57:47 <obw> (i am having some trouble with abuild)
2021-11-06 03:58:13 <obw> if I su to my regular non-root user, `abuild` outputs nothing and `abuild-keygen` just says "Unable to deduce build architecture. Install apk-tools, or set CBUILD"
2021-11-06 03:58:18 <obw> it works as root though
2021-11-06 03:58:33 <obw> and I have apk-tools installed
2021-11-06 03:59:49 <obw> now, i DID have a working build machine, but in the process of upgrading it from 3.9 to 3.13 it appears to have deleted sudo
2021-11-06 07:30:10 <ikke> obw: sudo is no longer a depedency for abuild, so if you need it, you need to install it explicitly
2021-11-06 08:00:26 <ddevault> is there a policy on when to drop replace=
2021-11-06 08:00:33 <ddevault> once the old package rolls out of the maintained releases?
2021-11-06 08:00:42 <ddevault> replaces=*, in APKBUILDs
2021-11-06 08:01:50 <mps> iiuc when replacable doesn't exist in aports
2021-11-06 08:02:22 <ddevault> I wonder if we can automate an audit for these
2021-11-06 08:02:28 <mps> freeipmi on rv64 fail with this "checking build system type... Invalid configuration `riscv64-alpine-linux-musl': machine `riscv64-alpine' not recognized"
2021-11-06 08:02:56 <mps> also liferea is missing deps on rv64
2021-11-06 08:03:45 <ddevault> the solution for this is usually to update config.guess/config.sub
2021-11-06 08:03:56 <mps> automate or add linter warning
2021-11-06 08:04:37 <ddevault> well, many packages with replaces= refer to a package from an older alpine release, and they should be kept in this situation, but cannot be easily tested at linter time
2021-11-06 08:05:04 <ddevault> an automation would probably want to check the set of supported alpine releases for the package named by replaces
2021-11-06 08:05:34 <mps> so, let it to human to fix
2021-11-06 08:14:16 <ddevault> generating a report which is acted on by a human, yes
2021-11-06 08:15:19 <mps> yes
2021-11-06 10:49:18 <Newbyte> do I need to bump pkgrel when adding a -dbg subpackage?
2021-11-06 11:03:48 <psykose> yes
2021-11-06 12:11:09 <clandmeter> Newbyte: if the version and/or pkgrel does not change, the pkg will not be build. our builders will think its just cosmetics and ignore the commit.
2021-11-06 12:11:55 <ikke> clandmeter: I think it should detect the subpackage is missing, not?
2021-11-06 12:12:22 <ikke> but for dbg packages, it's good that they are generated from the same build as the rest
2021-11-06 12:13:26 <clandmeter> ikke: hmm, could be, but does it?
2021-11-06 12:13:43 <clandmeter> so if any subpkg is missing it will rebuild it all?
2021-11-06 12:13:52 <ikke> from my understanding of how buildrepo works, it should
2021-11-06 12:14:03 <clandmeter> i guess you are right
2021-11-06 12:14:15 <clandmeter> i think im mixing things with how apk handles it
2021-11-06 12:14:46 <ikke> I'm not sure of the already built packages are replaced in that case
2021-11-06 12:15:20 <clandmeter> i guess if the package needs a rebuild, it will replace all of them.
2021-11-06 12:24:18 <PureTryOut> Ariadne: so currently packages building with both jack-dev and pipewire-dev are still broken, as pipewire-dev wants to pull in pipewire-jack which doesn't satisfy jack-dev but conflicts with jack itself. I'm thinking of overriding the dev function of pipewire-dev to move /usr/lib/libjack.so back to the main package so -jack can split it out to itself, or something like that. Do you have any advise there?
2021-11-06 12:24:52 <Ariadne> no
2021-11-06 12:25:37 <PureTryOut> no as in no advise or no as in "you shouldn't do that"
2021-11-06 12:28:57 <Ariadne> no advice
2021-11-06 12:29:08 <Ariadne> this is unfortunately not a situation we considered
2021-11-06 12:29:09 <PureTryOut> ok lol. Then I'll just give it a shot
2021-11-06 12:29:16 <PureTryOut> should be fine
2021-11-06 12:34:00 <PureTryOut> yeah seems to work fine, pipewire-dev doesn't depend on pipewire-jack anymore
2021-11-06 12:34:03 <PureTryOut> Newbyte: fix coming in
2021-11-06 12:42:24 <PureTryOut> Newbyte: https://git.alpinelinux.org/aports/commit/?id=5b657aa872c6
2021-11-06 12:42:29 <PureTryOut> Wait for that to appear in the repos, then retry your CI
2021-11-06 12:42:42 <Newbyte> nice, thanks
2021-11-06 13:43:57 <Hello71> ncopa: do you plan to update linux-rpi to 5.15 for 3.15?
2021-11-06 15:34:54 <minimal> Hello71: Whilst the Raspberry Pi Foundation do have a branch for 5.15.x (https://github.com/raspberrypi/linux) its not clear if this is usable yet
2021-11-06 15:43:38 <mps> Saijin_Naib[m]: this commit for just released maybe will fix your problem from last night fd5f954b690c63a9d5825ec8c7369329bae1740d
2021-11-06 15:43:52 <mps> Revert "drm/i915/gt: Propagate change in error status to children on unhold"
2021-11-06 15:45:09 <mps> for just released kernel 5.15.1*
2021-11-06 15:48:51 <Saijin_Naib[m]> @mps: Thank you! I don't understand that, so I'll look into it. I'll push the update soon to see if it fixes, and I guess I'll add further information to my issue here:  
2021-11-06 15:48:51 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13163
2021-11-06 15:49:05 <Saijin_Naib[m]> Do you know of what other logs I should be checking to see what is going on?
2021-11-06 15:52:39 <mps> no, not really. but from reminds similar reports in last year or two usually was related to drm/i915/gt
2021-11-06 15:53:42 <mps> I'll push 5.15.1 linux-edge this evening anyway and you could test
2021-11-06 17:13:11 <dalias> wtf is libreoffice gone because it's broken??
2021-11-06 17:13:42 <psykose> yep
2021-11-06 17:14:07 <dalias> *sigh* i have a broken system because of conflicting icu versions and libreoffice can't be upgraded not to depend on the broken icu because new pacckages are not there
2021-11-06 17:14:11 <dalias> wtf
2021-11-06 17:14:19 <dalias> FFS start static linking icu
2021-11-06 17:15:12 <orbea> either find the icu fixes from fedora or the libreoffice git or use the internal icu from libreoffice
2021-11-06 17:15:45 <orbea> conflicting icu versions sounds like a terrible situtation
2021-11-06 17:16:02 <dalias> yes libreoffice ships its own internal icu
2021-11-06 17:16:13 <dalias> distro undoing that is a regression
2021-11-06 17:16:37 <dalias> and right now my system is hosed. some other upgrade has prevented old firefox from starting (immediate crash)
2021-11-06 17:17:52 <dalias> is there any way to tell apk to 'forget about' a package without actually deleting the files?
2021-11-06 17:18:04 <dalias> apk del but no actual deletion
2021-11-06 17:18:05 <mps> dalias: you are running on edge? if so expect it break especially in freeze time
2021-11-06 17:18:27 <valerius> yes, the LTS kernel broke for me yesterday ;)
2021-11-06 17:18:35 <valerius> using the mps edge kernel to survive
2021-11-06 17:18:56 <mps> valerius: :)
2021-11-06 17:19:02 <dalias> lol really stupid idea:
2021-11-06 17:19:43 <dalias> tar ... $(apk info -L) ; apk del ; tar xf ....
2021-11-06 17:20:06 <mps> dalias: you can try to 'pin' pkg
2021-11-06 17:20:14 <dalias> ?
2021-11-06 17:20:29 <mps> apk add pkgname-version
2021-11-06 17:20:47 <mps> and it will not be auto updated/removed
2021-11-06 17:20:57 <dalias> i need updates of something
2021-11-06 17:21:17 <mps> ah, then pin will not help
2021-11-06 17:21:24 <dalias> i will probably just rm libreoffice and hope i dont need it for a while :(
2021-11-06 17:22:02 <mps> don't understand, on my box firefox and libreoffice works, edge
2021-11-06 17:22:28 <dalias> firefox 89 (which i have now) is crashing due to some other upgrade (probably mesa)
2021-11-06 17:22:43 <dalias> and updating to latest needs new icu
2021-11-06 17:22:44 <mps> why don't you upgrade it
2021-11-06 17:23:29 <dalias> because i can't
2021-11-06 17:23:44 <dalias>   icu-libs-67.1-r2:
2021-11-06 17:23:44 <dalias>     breaks: icu-dev-69.1-r0[icu-libs=69.1-r0]
2021-11-06 17:23:44 <dalias>     conflicts: icu-libs-69.1-r0
2021-11-06 17:23:44 <dalias>     satisfies: world[icu-libs] libreoffice-common-6.4.6.2-r11[so:libicui18n.so.67] libreoffice-common-6.4.6.2-r11[so:libicuuc.so.67]
2021-11-06 17:23:45 <mps> ah, you don't have libreoffice installed?
2021-11-06 17:23:47 <dalias>                libreoffice-writer-6.4.6.2-r11[so:libicui18n.so.67] libreoffice-writer-6.4.6.2-r11[so:libicuuc.so.67]
2021-11-06 17:23:51 <dalias> i do have libreoffice installed
2021-11-06 17:23:57 <ikke> mps: libreoffice has bene disabled
2021-11-06 17:23:58 <dalias> and it's forcing keeping old icu
2021-11-06 17:24:10 <ikke> so not rebuilt against latest icu
2021-11-06 17:24:16 <mps> ikke: I know
2021-11-06 17:24:30 <dalias> why would it be disabled rather than switching (temp or permanent) to in-tree icu??
2021-11-06 17:24:58 <mps> dalias: that is what I asked earlier here when it was disabled
2021-11-06 17:25:01 <dalias> disabling packages really should not be a first resort when it fails to build
2021-11-06 17:25:12 <dalias> that horribly breaks people's systems
2021-11-06 17:25:28 <dalias> just do the simplest hack to make it build again
2021-11-06 17:25:54 <mps> heh, that is why I have rescue mmc card with known stable system
2021-11-06 17:27:08 <mps> dalias: give me some time, I will look at it (though I dislike to play with such pkgs)
2021-11-06 17:27:25 <dalias> i would look... if i had a browser >_<
2021-11-06 17:27:44 <Saijin_Naib[m]> mps: Thank you so much! I will report back as soon as I can test it.
2021-11-06 17:29:33 <mps> Saijin_Naib[m]: is it on mirrors now?
2021-11-06 17:29:53 <ikke> dalias: libreoffice fails due to boost, there is no simple hack
2021-11-06 17:30:05 <ikke> afaik
2021-11-06 17:30:14 <ikke> #13141
2021-11-06 17:30:56 <obw> any tips for solving the error "Unable to deduce build architecture. Install apk-tools, or set CBUILD.", i have apk-tools installed
2021-11-06 17:31:01 <dalias> now qt5-qtbase is also holding back icu...
2021-11-06 17:31:11 <dalias> grr
2021-11-06 17:31:22 <Saijin_Naib[m]> 
ACTION sent a code block: https://matrix.org/_matrix/media/r0/download/matrix.org/GofBAJvUdaSdvxfIzEBeHgQl

2021-11-06 17:31:41 <mps> yes, big monolitic builds for simple, small distro :)
2021-11-06 17:32:22 <mps> Saijin_Naib[m]: it is IRC and not matrix, don't do this
2021-11-06 17:32:49 <obw> oh, my $PATH is way empty for that user, wtf
2021-11-06 17:33:02 <mps> ikke: I built locally libreoffice to have it just in case
2021-11-06 17:34:20 <mps> hmm, libreoffice ./configure doesn't have ' --with-system-icu' in APKBUILD
2021-11-06 17:35:11 <mps> so, why is icu-dev in makedepends
2021-11-06 17:37:03 <dalias> ok removing unused junk trying to clean up this dep spaghetty
2021-11-06 17:37:08 <dalias> WHY does mutt depend on gnupg ?!
2021-11-06 17:37:17 <dalias> gnupg is an optional command mutt can run, not a dep
2021-11-06 17:37:32 <dalias> *sigh*
2021-11-06 17:38:37 <mps> I argued against this also
2021-11-06 17:38:54 <dalias> "X can run Y as a command" != "X depends on Y"
2021-11-06 17:39:11 <dalias> dep mean "X cannot run at all without Y present
2021-11-06 17:39:21 <mps> but till I be promoted to BDFL these thing will happen ;)
2021-11-06 17:39:34 <dalias> who is blocking fixing this???
2021-11-06 17:39:37 <minimal> I guess its because there's no "recommends" or "suggests" for packages so some people therefore make them hard depends
2021-11-06 17:39:48 <dalias> it shouldn't be any of them
2021-11-06 17:39:53 <dalias> if you want to use gpg you install it
2021-11-06 17:39:55 <dalias> if not, you don't
2021-11-06 17:40:00 <dalias> there's no relation to mutt
2021-11-06 17:40:19 <mps> dalias: that is war I loosing
2021-11-06 17:40:20 <dalias> is there a simple way to make a "provides gnupg" fake package via apk command line?
2021-11-06 17:40:29 <minimal> dalias: not disagreeing
2021-11-06 17:40:36 <mps> I want just this 'minimum deps'
2021-11-06 17:42:05 <ikke> mutt has a makedepends on gpgme-dev
2021-11-06 17:42:12 <ikke> no direct dep on gnugp
2021-11-06 17:42:25 <ikke> dalias: apk add -t gnupg
2021-11-06 17:45:45 <dalias> oh maybe my mutt package is just really old
2021-11-06 17:46:47 <ikke> gpgme depends on gnupg
2021-11-06 17:46:49 <psykose> it depends on libgpgme.so, which is only provided by gpgme, which depends on gpg
2021-11-06 17:46:58 <psykose> because the libs aren't split i guess
2021-11-06 17:49:27 <mps> ikke: liferea on rv64 can't be built, there are no needed makedeps pkgs
2021-11-06 17:50:16 <mps> I told jirutka about this mutt - gpg problem
2021-11-06 17:50:32 <mps> and had a hope he will fix it
2021-11-06 17:52:46 <mps> minimal: I renamed linux-edge-virt to linux-edge4virt
2021-11-06 17:55:56 <Saijin_Naib[m]> mps: I thought the code block was fine in IRC. Apologies
2021-11-06 17:56:39 <mps> Saijin_Naib[m]: ok, we all learn by mistakes
2021-11-06 17:58:29 <psykose> code block is fine if you put code in it :p then it's just a fast pastebin
2021-11-06 17:58:39 <psykose> don't put replies and whatever in the same message though
2021-11-06 17:59:47 <ikke> Usually you add some context though in the message
2021-11-06 18:00:28 <ikke> "Hey, I have an issue, i'm trying foo, and it's not working. Here is the error: <link>
2021-11-06 18:00:30 <ikke> "
2021-11-06 18:01:24 <psykose> yeah, but doing that in two messages is basically the same if you put the link in the second
2021-11-06 18:09:38 <minimal> mps: ok. I don't think there's any issue with the Grub patch remaining as its still relevant
2021-11-06 18:24:20 <mps> minimal: yes. just wanted to inform you
2021-11-06 18:53:56 <mps> andypost[m]: ping
2021-11-06 18:54:45 <mps> build libreoffice pass on x86_64 without icu-dev in makedeps
2021-11-06 18:55:01 <mps> tested with 'abuild rootbld'
2021-11-06 19:31:05 <andypost[m]> mps: that's great news
2021-11-06 19:52:44 <Saijin_Naib[m]> 5.15.1 linux-edge hard-freezes the same as 5.15.0 linux-lts once I'm in the DE, so it would appear that the patch for i915 didn't resolve the issue. Though, maybe the linux-lts will behave differently since the kernel config is somewhat different still (I think)
2021-11-06 20:31:49 <mps> Saijin_Naib[m]: bad news
2021-11-06 20:32:12 <mps> andypost[m]: I think it could be enabled on 64bit arches
2021-11-06 20:32:35 <mps> I'll test build on aarch64
2021-11-06 20:33:31 <Ariadne> there are some workarounds you can do for i915
2021-11-06 20:33:50 <Ariadne> i think intel iGPUs are shit
2021-11-06 20:45:26 <Nulo> linux-lts 5.15 makes my machine not boot at all, corebooted Thinkpad X230
2021-11-06 20:45:36 <Nulo> This took way too long to solve D:
2021-11-06 20:51:28 <Nulo> Is there a way to jump from edge to the "next" release and then stay on that stable release?
2021-11-06 20:52:32 <ikke> You could install linux-lts from 3.14
2021-11-06 21:02:40 <Nulo> ikke, yes, that's what I did. I just want to avoid this happening in the future
2021-11-06 21:03:15 <Nulo> To be fair I could just use the kernel from the stable release, if anything happens with anything else I can just manually install the package. It doesn't take nearly as long than a broken kernel recovery
2021-11-06 21:04:44 <psykose> there isn't really a way to stop it happening in the future, even if you were on stable technically 5.15 would be in next release and would also magically break your boot, unless someone managed to catch it in the few weeks before
2021-11-06 21:04:48 <mps> andypost[m]: libreoffice pass build on aarch64 also, now checking on armv7
2021-11-06 21:04:50 <psykose> it's a lower chance but it still happens all the time
2021-11-06 21:05:14 <ikke> mps: from what I understood, it failed on the 3.15 builders
2021-11-06 21:05:30 <Nulo> psykose, fair enough
2021-11-06 21:05:33 <mps> ouh
2021-11-06 21:05:55 <Nulo> Well, I catched an issue! Is there any way I can debug it? It just freezes on the last coreboot screen completely
2021-11-06 21:06:38 <psykose> there is probably some writing on getting early boot output somewhere that i've forgotten about
2021-11-06 21:07:11 <mps> error fs
2021-11-06 21:10:32 <mps> pstore fs
2021-11-06 21:11:57 <ikke> mps: just tested it again, it fails on 3.15 x86_64
2021-11-06 21:14:06 <mps> ikke: do you know what is a reason, because it works on edge
2021-11-06 21:14:23 <mps> are builders different?
2021-11-06 21:14:26 <ikke> trying to figure it out, has to do with boost
2021-11-06 21:15:01 <ikke> checking for exit in -lboost_filesystem... no
2021-11-06 21:18:02 <mps> looks like there are two boost filesystem in repo
2021-11-06 21:18:15 <psykose> no exit :( forever stuck inside
2021-11-06 21:19:12 <ikke> psykose: do you know how I can further investigate this?
2021-11-06 21:19:19 <ikke> I do have access to the builder
2021-11-06 21:19:30 <psykose> sadly i don't
2021-11-06 21:19:35 <ikke> ok
2021-11-06 21:20:04 <psykose> the configure log will have the actual error
2021-11-06 21:20:07 <psykose> as always
2021-11-06 21:20:09 <ikke> my autoconf foo is extremly limited
2021-11-06 21:22:34 <ikke> https://tpaste.us/OryY 
2021-11-06 21:23:26 <psykose> that should be clang++ and not clang
2021-11-06 21:25:00 <psykose> or should it? i don't actually know if configure runs c++ conftests separately, but those look like errors you get with the wrong compiler mode where it doesn't link against the c++ stdlib
2021-11-06 21:25:41 <psykose> which is implied when you use clang++/g++, of course
2021-11-06 21:25:57 <ikke> I don't see it running it with clang++
2021-11-06 21:39:10 <Saijin_Naib[m]> Ariadne: unfortunately, the Intel iGPU is all I have on this platform. Do you have a specific workaround I should be investigating or should I just dig around? 
2021-11-06 22:10:48 <Ariadne> Saijin_Naib[m]: try i915.enable_psr=1
2021-11-06 22:10:52 <Ariadne> er =0
2021-11-06 22:15:25 <Saijin_Naib[m]> Thank you! I had that with a number of other options proir, but saw it "tainted" the kernel so removed it before the upgrade 
2021-11-06 22:15:55 <dalias> so.. any idea when libreoffice will be back? :/
2021-11-06 22:18:31 <ikke> when we figure out why boost_filesystem fails to link
2021-11-06 22:18:33 <ikke> see ^^
2021-11-06 22:23:04 <Hello71> isn't enable_psr=0 for flickering, not freeze
2021-11-06 22:24:31 <Hello71> psykose: if boost_filesystem needs libstdc++ then it should depend on it in the so
2021-11-06 22:24:36 <dalias> ikke, where's the error? i can take a look
2021-11-06 22:24:42 <Hello71> SO_NEEDED
2021-11-06 22:24:49 <Hello71> er, DT_NEEDED
2021-11-06 22:25:19 <Hello71> 17:30 <@ikke> #13141
2021-11-06 22:25:57 <dalias> checking for exit ???
2021-11-06 22:26:38 <dalias> no config.log ?
2021-11-06 22:26:47 <psykose> the paste is from the config.log
2021-11-06 22:27:20 <dalias> that looks like save of configure output
2021-11-06 22:27:22 <dalias> not config.logh
2021-11-06 22:27:26 <dalias> config.log is much more verbose
2021-11-06 22:29:31 <dalias> one-line fix:
2021-11-06 22:29:35 <dalias> - --with-system-libs \
2021-11-06 22:29:51 <dalias> (afaict libreoffice also ships its own boost)
2021-11-06 22:41:30 <dalias> ok i just confirmed this is boost being broken
2021-11-06 22:41:48 <dalias> the boost libs are missing the DT_NEEDED as hello71 said
2021-11-06 22:45:23 <psykose> that's weird then, since it builds on edge, and i think the 3.15 builders are also the same boost1.77 aren't they
2021-11-06 22:46:41 <Hello71> smells like --as-needed
2021-11-06 22:47:37 <dalias> it's not --as-needed
2021-11-06 22:47:43 <dalias> libstdc++ *is* needed
2021-11-06 22:47:49 <dalias> it has hundreds of symbol refs to it
2021-11-06 22:48:15 <Hello71> hm, good point, if it was -lstdc++ boost.a then it should have failed at ld
2021-11-06 22:48:30 <dalias> well the configure tests here are supposed to run with a c++ compiler
2021-11-06 22:48:35 <dalias> where -lstdc++ would always be present
2021-11-06 22:48:44 <Hello71> yes
2021-11-06 22:49:07 <dalias> so either they're running with a C compiler instead, or some flags that suppress it, or gcc has broken specs
2021-11-06 22:50:06 <dalias> i can reproduce the failure with:
2021-11-06 22:50:07 <dalias> gcc hello.c -Wl,--no-as-needed -lboost_filesystem
2021-11-06 22:50:20 <Hello71> but on arch and gentoo libboost_filesystem.so has NEEDED libstdc++.so.6 
2021-11-06 22:50:55 <dalias> i think alpine's default as-needed might be breaking it somehow (possibly a bug in as-needed)
2021-11-06 22:50:58 <Hello71> unfortunately the build log only has the useless ln-UNIX /home/buildozer/aports/main/boost1.77/src/boost_1_77_0/stage/lib/libboost_filesystem.so
2021-11-06 22:51:11 <dalias> lovely..
2021-11-06 22:51:12 <Hello71> but gentoo and arch also use --as-needed
2021-11-06 22:51:26 <Hello71> er, "gcc.link.dll bin.v2/libs/filesystem/build/gcc-10/release/threading-multi/visibility-hidden/libboost_filesystem.so.1.77.0" actually
2021-11-06 22:51:31 <dalias> do they do it a different way tho?
2021-11-06 23:01:56 <Hello71> dunno
2021-11-07 03:23:25 <Saijin_Naib[m]> Ariadne: psr does not help under 5.15.1, unfortunately.
2021-11-07 03:23:26 <Saijin_Naib[m]> Is there room for a linux-oldlts of 5.10.x in edge if I make an APKBUILD for it?
2021-11-07 03:41:01 <psykose> you could install lts from the 3.14 repo
2021-11-07 03:43:43 <Saijin_Naib[m]> Yeah, for now, right? But I imagine the 5.10.x based kernel is going away once 3.15 lands right? 
2021-11-07 03:49:23 <psykose> the 3.14 repos will still be there
2021-11-07 03:50:06 <Saijin_Naib[m]> Can they be updated? 5.10.67 or whatever predates a MR that enables hardware on my laptop, like my TouchPad
2021-11-07 03:50:19 <Saijin_Naib[m]> Or are they frozen? 
2021-11-07 03:51:04 <psykose> hm
2021-11-07 03:51:19 <psykose> i would say you are in quite an unfortunate position then
2021-11-07 03:54:40 <Saijin_Naib[m]> Yep, looks like I'm back to cooking my own kernels again
2021-11-07 07:23:15 <mps> Saijin_Naib[m]: main where linux-lts is maintained two years, so linux-lts 5.10.x will be there for two years
2021-11-07 07:59:32 <JuniorJPDJ> <Saijin_Naib[m]> "Can they be updated? 5.10.67..." <- afaik those should be updated to latest patch level
2021-11-07 07:59:38 <JuniorJPDJ> you could do MR
2021-11-07 08:02:56 <ikke> ncopa takes care of the kernels. It's easier for him to do just do it himself
2021-11-07 08:04:07 <mps> yes, don't create MRs for kernels, open the issue or ask on ML or here
2021-11-07 08:04:24 <mps> good morning
2021-11-07 08:04:51 <mps> and learn that we are here on IRC, not matrix ;)
2021-11-07 08:11:51 <tomalok> i have a request to add CONFIG_GPIO_PL061=y to the virt kernel -- this is the device that EC2 sends to gracefully shutdown aarch64 instances
2021-11-07 08:12:21 <mps> tomalok: ok, will note it
2021-11-07 08:12:31 <tomalok> thanks, mps
2021-11-07 08:12:44 <mps> tomalok: np
2021-11-07 08:13:42 <mps> tomalok: this is for aarc64? it is not needed/available for x86*
2021-11-07 08:14:33 <mps> aarch64*
2021-11-07 08:22:40 <mps> xorg-server 21.1.1 is released with meson fixed, working on it RN \o/
2021-11-07 08:22:59 <mps> we will have it in 3.15-stable
2021-11-07 08:32:50 <tomalok> mps: yes it's for aarch64, apparently x86_64 reboot signal's handled differently
2021-11-07 08:33:08 <tomalok> s/reboot/shutdown/
2021-11-07 08:33:08 <alpine-meetbot> tomalok meant to say: mps: yes it's for aarch64, apparently x86_64 shutdown signal's handled differently
2021-11-07 13:17:09 <Hello71> tomalok: did you check that it works with CONFIG_GPIO_PL061=y? seems like some assembly required
2021-11-07 13:31:57 <donoban> my laptop fails to boot with last linux-lts, it hungs on  "Loading initial ramdisk ..."
2021-11-07 13:46:54 <Ariadne> :D
2021-11-07 13:47:15 <Ariadne> donoban: try booting without quiet
2021-11-07 13:47:28 <donoban> I did, no additional messages
2021-11-07 13:47:38 <Ariadne> weird
2021-11-07 13:47:45 <donoban> :\
2021-11-07 13:47:52 <donoban> at least linux-edge works ^^
2021-11-07 13:48:51 <donoban> maybe a "backup" policy for kernel upgrading would be nice
2021-11-07 13:49:25 <donoban> first for not being forced to reboot due missing modules on runtime kernel, and second because you could easy boot a working kernel if newer fails
2021-11-07 13:51:54 <Ariadne> open a bug
2021-11-07 13:52:24 <donoban> ok
2021-11-07 14:24:11 <Ariadne> Saijin_Naib[m]: are these freezes intermittent where if you say, move the mouse cursor or something, it stops freezing?
2021-11-07 14:24:32 <Ariadne> Saijin_Naib[m]: also, are you using X or wayland
2021-11-07 14:24:52 <Ariadne> if wayland, which compositor?
2021-11-07 14:25:01 <Saijin_Naib[m]> X with XFCE. I had to give up wayland a while back with the GNOME/GDM kerfluffle, so I've not tried wayland since (so I can't confirm/deny behavior)
2021-11-07 14:25:28 <Saijin_Naib[m]> I have however, tried other DMs from lightdm with gtk-greeter, and behavior is consistent. Same for other DEs
2021-11-07 14:26:14 <Saijin_Naib[m]> No, moving the mouse or providing input doesn't unfreeze it. It can seemingly trigger anywhere from 0s after DM starts to about 3min. Somtimes just pressing a key freezes it, sometimes I can open the browser and use it like normal until it just dies
2021-11-07 14:29:03 <Saijin_Naib[m]> Console session seems to last the longest consistently, but will eventually lock
2021-11-07 16:19:17 <caskd> oh
2021-11-07 16:19:23 <caskd> wups, wrong buffer
2021-11-07 16:37:30 <tomalok> Hello71: I found reference to the PL061 chip in a FreeBSD discussion thread, trying to gracefully shut down FreeBSD on EC2 (instead of a hard shutdown after 2 minutes -- which is what the Alpine aarch64 AWS images are experiencing) and checked Amazon Linux's configured modules to confirm it was on.
2021-11-07 17:08:39 <Saijin_Naib[m]> Probably meaningless with the number of changes that go into each kernel version, but 5.11.22 with the linux-lts kernel config from 5.10.76 works perfectly.
2021-11-07 17:08:39 <Saijin_Naib[m]> Working on testing out 5.12.19 next
2021-11-07 17:09:58 <Ariadne> Saijin_Naib[m]: have you tested pinging the machine from another computer while the GPU is frozen?
2021-11-07 17:10:09 <Ariadne> it could be that the entire machine is locking up, not just the GPU
2021-11-07 17:12:31 <Saijin_Naib[m]> Ariadne: I had not considered that... Thank you. I'll try soon. Would complete local lockup of input like keyboard/mouse/USB and output like audio (looping) work as a proxy to confirm full lockup like trying to ping/ssh it, or are those not positive tests for full lockup?
2021-11-07 17:16:49 <Ariadne> they might
2021-11-07 17:17:00 <Ariadne> but it could be kpanic'ing
2021-11-07 17:17:35 <Ariadne> my go to is to ping the machine
2021-11-07 17:17:39 <Ariadne> to verify health though
2021-11-07 19:15:22 <Saijin_Naib[m]> 5.12.19 bombs and touch is broken despite unchanging kernel config, so something massive changed between 5.11.22 and that.
2021-11-07 19:41:36 <alandiwix> Is there a way to increase boot logs verbosity aside from removing "quiet" flag?
2021-11-07 19:45:23 <minimal> alandiwix: you can pass "debug_init" to see what the initramfs's init script is doing
2021-11-07 19:46:22 <alandiwix> minimal: thanks
2021-11-07 19:46:42 <minimal> alandiwix: adding that makes no difference to the problem I'm currently seeing though
2021-11-07 19:47:42 <alandiwix> So something wrong with the kernel itself I suppose?
2021-11-07 19:49:05 <alandiwix> Copying from #alpine-linux:  Just installed Alpine through chroot on a new machine and the the boot process is getting stuck on "EFI stub: Loaded initrd from command line option".
2021-11-07 19:50:05 <minimal> alandiwix: yes I assume its somehow a EFI-related kernel config as BIOS booting works
2021-11-07 19:50:32 <minimal> I'm guessing that linux-edge may work but haven't yet tested it
2021-11-07 19:53:26 <alandiwix> Anything specific in your setup, like btrfs root or booting from nvme device?
2021-11-07 19:54:12 <alandiwix> I doubt these things matter, but still
2021-11-07 19:56:59 <minimal> alandiwix: nope, ext4 on virtio-scsi. As BIOS works that should mean in theory that the initramfs is "fine".
2021-11-07 19:58:56 <alandiwix> mps: the size of linux-edge is x2 so the compilation config differs significantly fron lts, right?
2021-11-07 20:00:28 <mps> alandiwix: yes, modules are not compressed in linux-edge
2021-11-07 20:00:29 <minimal> alandiwix: yes the linux-lts and linux-edge configs are not generally aligned.
2021-11-07 20:05:35 <alandiwix> minimal: I guess I'll try linux-edge tomorrow, please let me know if you do it sooner
2021-11-07 20:06:51 <minimal> alandiwix: I'll try once my Alpine mirror update finishes. I have the building of all these various VM creations scripted
2021-11-07 21:45:34 <maxice8> looking at fwupd
2021-11-07 21:45:56 <maxice8> no worse feeling that CI passing and builder failing
2021-11-07 21:49:22 <ikke> strange that that works on CI..
2021-11-07 21:50:13 <maxice8> apparently usage of unknown meson options is not fatal on CI but is on the builder
2021-11-07 21:50:26 <ikke> I cannot imagine why that is
2021-11-07 21:50:46 <maxice8> https://mesonbuild.com/Release-notes-for-0-60-0.html#unknown-options-are-now-always-fatal
2021-11-07 21:50:53 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/fwupd/fwupd-1.6.4-r2.log install meson 0.60.0
2021-11-07 21:51:18 <maxice8> CI didn't even build lol
2021-11-07 21:51:18 <mps> yes, I meet it with xorg-server hour ago
2021-11-07 21:51:32 <maxice8> nvm i'm dumb
2021-11-07 21:51:33 <eschwartz> hopefully you weren't expecting that unknown option to do something in the past... :)
2021-11-07 21:51:36 <maxice8> looked at the new pipeline
2021-11-07 21:51:46 <maxice8> es: I have no expectations
2021-11-07 21:51:59 <maxice8> in the CI meson is 0.59.3
2021-11-07 21:52:06 <maxice8> WARNING: Unknown options: "agent"
2021-11-07 21:52:09 <eschwartz> (it's way too easy to have crusty old arguments that used to do something, hence the change to make it fatal)
2021-11-07 21:52:44 <eschwartz> and on the meson front, muon is now in pretty good shape
2021-11-07 21:52:57 <maxice8> I understand but that is not what I care about really
2021-11-07 21:53:09 <ikke> (14/267) Installing meson (0.59.3-r0)
2021-11-07 21:53:16 <eschwartz> Ariadne: it can actually install openrc perfectly I think -- other than not yet supporting shared libraries
2021-11-07 21:54:03 <ikke> ah, meson was upgraded today
2021-11-07 21:54:10 <ikke> while the job ran 9h ago
2021-11-07 21:54:36 <ikke> (14/267) Installing meson (0.59.3-r0)
2021-11-07 21:54:47 <maxice8> makes sense
2021-11-07 21:54:51 <ikke> a6d8ba86b07c
2021-11-07 21:54:57 <ikke> https://git.alpinelinux.org/aports/commit/?id=a6d8ba86b07c
2021-11-07 21:55:05 <maxice8> I'll make an MR to rebuild all meson stuff to see what fails due to unknown options
2021-11-07 21:55:36 <mps> upgrading meson in freeze time?
2021-11-07 21:55:39 <ikke> yeah
2021-11-07 21:55:44 <ikke> not sure if that was a good idea
2021-11-07 21:55:59 <mps> I think it is not
2021-11-07 21:57:35 <maxice8> well it was already reverted before
2021-11-07 21:57:36 <maxice8> e119949d1359274c13c33a7ca1e0d882a7bf9039
2021-11-07 21:58:49 <ikke> I suppose that was due to the positional arguments that were now errors
2021-11-07 21:59:05 <ikke> which was to be accepted again in 0.60.1
2021-11-07 22:01:50 <maxice8> !27242
2021-11-07 22:06:08 <ikke> #13166
2021-11-08 01:23:21 <tomalok> in the search for a more lightweight EFI bootloader for Alpine cloud images, i've come across "gummiboot"... which was absorbed into the systemd megaproject back in 2015, and renamed "systemd-boot"...  However, this piece of systemd is a small lightweight EFI bootmanager that allows us to bridge the gap to use the EFI_STUB bootloader in the kernel
2021-11-08 01:23:21 <tomalok> itself -- without having to recompile the kernel to point at a specific kernel & initrd, and without having to rely on setting such things in NVRAM (which is something we can't do in the cloud anyways!).  of course, there doesn't seem to be any systemd APKs around (probably for good reason), and I don't know offhand how hard it might be to build an
2021-11-08 01:23:21 <tomalok> APK just for the bootloader...
2021-11-08 01:24:24 <tomalok> *for just the systemd-boot bootmanager
2021-11-08 01:24:29 <minimal> tomalok: there is already a gummiboot package for Alpine
2021-11-08 01:24:48 <tomalok> ooh, i may have missed that!
2021-11-08 01:24:52 <minimal> its in Edge so it will appear in Alpinre 3.15 as well
2021-11-08 01:25:06 <minimal> been meaning to try it out myself
2021-11-08 01:25:09 <tomalok> ah, but not back in 3.14, etc.
2021-11-08 01:25:39 <minimal> I think that is was added as part of testing secure boot
2021-11-08 01:26:14 <minimal> new packages don't get backported to existing releases
2021-11-08 01:28:55 <tomalok> i've got the "alpine-cloud-images" project building all kinds of AWS images... hoping to add cloud-init as a variant soon, tidy up a couple of things code-wise, and then get to work on the other clouds...  the build config system should be able to handle "start using gummiboot starting with v3.15"...  :)
2021-11-08 01:29:20 <minimal> alandiwix: I've updated #13165 with my findings
2021-11-08 01:29:58 <minimal> tomalok: I updated the cloud-init package a couple of days ago to the new releae
2021-11-08 01:30:56 <tomalok> it's like the stars are aligning...  ;)
2021-11-08 01:32:10 <minimal> tomalok: I got sidetracked recently looking into kernel configs and a few other things so haven't found the time to test on AWS
2021-11-08 01:35:55 <tomalok> minimal: anything i should keep in mind?  just "apk add cloud-init" into the image, or is there more to it?
2021-11-08 01:37:00 <tomalok> hrm, would be nice if gummiboot also came in aarch64...
2021-11-08 01:37:02 <minimal> tomalok: install cloud-init-doc and read the README.Alpine :-)
2021-11-08 01:37:20 <tomalok> RTFRM!  ;)
2021-11-08 01:40:08 <minimal> tomalok: this is an aarch64 patch in the Alpine gummiboot repo, by the APKBUILD doesn't specify aarch64 as an arch.
2021-11-08 01:40:55 <minimal> I think gummiboot is basically "dead" as of when it was absorbed by systemd, the old repo saws "obsoleted"
2021-11-08 01:41:02 <minimal> s/saws/says/
2021-11-08 01:41:02 <alpine-meetbot> minimal meant to say: I think gummiboot is basically "dead" as of when it was absorbed by systemd, the old repo says "obsoleted"
2021-11-08 01:46:46 <tomalok> which is probably why i subconsciously didn't think to search for a gummiboot APK itself...
2021-11-08 02:37:34 <anjan> excuse my ignorance but I dont get why the tests are failing https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27182#note_190396
2021-11-08 02:37:40 <anjan> they pass on the CI
2021-11-08 02:37:44 <anjan> they pass on my local machine
2021-11-08 02:37:50 <anjan> but they dont work on the builder?
2021-11-08 02:37:55 <anjan> I dont even know how to debug this
2021-11-08 02:52:12 <smcavoy> might help to get the full builder logs..
2021-11-08 02:54:01 <smcavoy> anjan: quickly checking sustained_traffic_from_multiple_processes_bi_directional_total: https://github.com/imsnif/bandwhich/blob/acd1b0a95dbc2ee245648f2d5ef75494cf1cba54/src/tests/cases/ui.rs#L937 
2021-11-08 02:55:51 <smcavoy> I see the ports in use are below 1024, *should* not be a problem. Also there is a mix of private IP space (10.0.0.0/8) with public IP space (1.1.1.1 and 3.3.3.3)  not ideal.. 
2021-11-08 03:34:47 <anjan> I see
2021-11-08 03:34:52 <anjan> smcavoy: thanks for looking into this
2021-11-08 03:35:00 <anjan> should I change the test in upstream?
2021-11-08 04:16:25 <maxice8> Ikke: found unknown option failures
2021-11-08 04:16:37 <maxice8> faebe5773fbf7402bacf1154dbcab56ef41c6cc9
2021-11-08 04:35:06 <smcavoy> anjan: get the logs first and if they are not verbose, which they seem not to be, see if you can enable verbose/debug. you *should* get a more specific error.
2021-11-08 05:13:29 <maxice8> Ikke: more errors revealed and some I don't even think are related to meson
2021-11-08 05:31:28 <maxice8> 4783db5e3b3c4909b795650eb14005febeea574a 580eb070c28c0d9792511be1c8dbb6359c0fed8b 0f02a2083c18af8dcd88293ad98fe69a28c52b3b 466587dfa85a856c0cc8da26c81f4743d8257a80 86723ddc3c639aac0d4cb2bfb95aa1b418182a00
2021-11-08 06:28:00 <alandiwix> minimal: so linux-edge works? great news.
2021-11-08 07:18:08 <ncopa> good morning
2021-11-08 07:18:23 <mps> good morning
2021-11-08 07:20:32 <ncopa> tomalok: I used gummiboot before it got merged into systemd. It is pretty nice. However, there are no new development of gummiboot so I think it might be a dead end
2021-11-08 07:20:43 <ncopa> unless we (or someone else) fork it
2021-11-08 07:23:05 <ikke> morning
2021-11-08 07:39:47 <alandiwix> what is ETA for 3.15?
2021-11-08 07:49:30 <ncopa> before end of Nov
2021-11-08 07:53:11 <alandiwix> will it include 5.15 kernel?
2021-11-08 07:55:42 <ncopa> yes
2021-11-08 07:55:51 <alandiwix> nice, thanks
2021-11-08 07:59:16 <markand_> I had that error while trying to build a package that depends on polkit: https://bpa.st/5M7A
2021-11-08 08:02:40 <staceee> hello there ! is there someone to merge review and merge this please ? :D https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27205
2021-11-08 08:05:57 <markand_> it also looks like abuild does not like to be ^C'ed, because now I get: https://bpa.st/4UXA
2021-11-08 08:06:44 <ikke> That just means you interrupted it before it installed any dependencies
2021-11-08 08:07:17 <ikke> run apk fix
2021-11-08 08:07:43 <markand_> lemme try that
2021-11-08 08:08:17 <mps> should 'we' merge xorg-server? it works fine on my 4 boxes, 3 arches
2021-11-08 08:09:08 <mps> !27236
2021-11-08 08:09:56 <mps> ncopa: also, should we add rootless modeset patch to it
2021-11-08 08:14:56 <markand_> ikke, thanks, it werks
2021-11-08 08:25:27 <ikke> maxice8: meson upgrade has been reverted again
2021-11-08 09:04:43 <adhawkins> Anyone care to take a look at !26894. Been open longer than I would normally expect. Is there an issue with it, or is it just that someone hasn't got round to looking at it yet?
2021-11-08 09:18:38 <indy> hi all is release of 3.15.0 blocked by https://gitlab.alpinelinux.org/alpine/aports/-/milestones/177 ?
2021-11-08 09:22:13 <ikke> Not all issues there are blockers
2021-11-08 09:26:58 <ncopa> what is the status of openssl1.1 revert?
2021-11-08 09:27:05 <ncopa> Ariadne: ^^^
2021-11-08 09:27:24 <ncopa> !13075
2021-11-08 09:27:45 <ncopa> #13075
2021-11-08 09:29:43 <ncopa> ikke: what is the status of ghc? we still need to rebuild it with system libffi?
2021-11-08 09:29:55 <ikke> ncopa: yes
2021-11-08 09:30:32 <ikke> I'll continue where I left off with my branch
2021-11-08 09:36:05 <andypost[m]> ncopa: please consider upgrade !25263
2021-11-08 09:41:27 <ikke> ncopa: do you think it's an issue that packages like Alex and happy no longer link against libffi? 
2021-11-08 09:42:31 <ncopa> not really. What I find problematic is if packages link to ghc bundled libffi.so.7
2021-11-08 09:43:09 <ncopa> I saw it when I tried to package uusi
2021-11-08 09:43:44 <ncopa> i also find it problematic that it pull sin 900MB of dependencies
2021-11-08 09:43:53 <ncopa> but if we can avoid that, then great!
2021-11-08 09:44:32 <ikke> Certainly 
2021-11-08 09:46:02 <ikke> One more question: is it expected that something like apk info -r so:libffi.so.7 or apk info -r libffi.so.7 does not return anything?
2021-11-08 09:46:46 <ncopa> good question
2021-11-08 09:47:20 <ncopa> i think `apk info -r` will not return anything when there are no provider, even if there are packages depending on it
2021-11-08 09:47:33 <ikke> ghc still provides it
2021-11-08 09:47:40 <indy> ikke, any estimations when will 3.15.0 pop-up?
2021-11-08 09:47:53 <ikke> indy: the goal is before end of this month
2021-11-08 09:48:15 <ncopa> apk list --depend so:libffi.so.7
2021-11-08 09:48:47 <ncopa> ugh.. ghc should not provide so:libffi.so.7
2021-11-08 09:49:14 <ikke> Yes, that's the goal
2021-11-08 09:50:06 <ncopa> I guess we should use system libffi to avoif the so:libffi.so.7 provide
2021-11-08 09:52:14 <ikke> https://gitlab.alpinelinux.org/kdaudt/aports/-/commit/de62e74c81e70c0fa60c8acfd9be51592a46f447
2021-11-08 09:52:53 <ikke> You said that could be done simpler?
2021-11-08 09:53:53 <ikke> ncopa: list vs info makes sense, thanks.
2021-11-08 09:55:44 <ncopa> Simply adding `--with-system-libffi` should be enough
2021-11-08 09:55:57 <ikke> and adding libffi-dev to makedepends I suppose
2021-11-08 09:56:12 <ncopa> yes. but not to depends
2021-11-08 09:56:25 <ikke> ok
2021-11-08 10:22:34 <PureTryOut> Hmm upgrading meson just now it gives me a BAD signature. edge, x86_64, https://dl-cdn.alpinelinux.org
2021-11-08 10:25:10 <ikke> I suppose it was just plainly reverted 
2021-11-08 10:25:21 <psykose> same for me, but works with other mirrors
2021-11-08 10:25:27 <ikke> Without increasing pkgrel 
2021-11-08 10:25:45 <ikke> psykose: it's a known 'issue' 
2021-11-08 10:25:48 <psykose> it was reverted many days ago if it was the 0.60 revert
2021-11-08 10:26:05 <psykose> and i had it upgrade and revert cleanly on uk. mirror, weird
2021-11-08 10:26:11 <ikke> dl-cdn caches files by name
2021-11-08 10:26:27 <psykose> ah
2021-11-08 10:46:25 <andypost[m]> any idea why __sync_lock_test_and_set() is missing on rv64? for #12775
2021-11-08 10:48:56 <PavloosCz>  Hello, is it possible to create a package that will only contain files that it will copy somewhere during installation? I can't include files in the package. Any Help ? 
2021-11-08 10:49:09 <psykose> andypost[m]: i believe that is from libatomic
2021-11-08 10:49:16 <psykose> and that libatomic hasn't been ported to rv64 yet
2021-11-08 10:49:31 <andypost[m]> thank you
2021-11-08 10:49:50 <psykose> could be wrong, but i remember something about libatomic and rv64 about a month ago, so likely it's not done yet
2021-11-08 10:50:15 <psykose> PavloosCz: what do you mean can't include files in the package?
2021-11-08 10:50:43 <ikke> I suppose due to license reasons?
2021-11-08 10:53:19 <ikke> ncopa: apk list --depends so:libffi.so.7 mentions happy-1.20.0-r1, but apk info -R happy does not list libffi.so.7 for that version
2021-11-08 10:57:45 <psykose> andypost[m]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12948 has some info and links to other related things for rv64, but it appears this php usage is still one of the non-fixed things
2021-11-08 10:57:54 <psykose> i assume you're checking on latest edge if it builds
2021-11-08 10:59:24 <psykose> should make an issue for it specifically
2021-11-08 10:59:38 <andypost[m]> psykose: thank a lot, reading
2021-11-08 10:59:41 <maxice8> Ikke: ok
2021-11-08 11:00:24 <andypost[m]> psykose: without -latimic it fails just pushed update to see
2021-11-08 11:17:04 <alandiwix> A stupid question: can linux-edge load linux-firmware-* packages?
2021-11-08 11:17:15 <psykose> yes
2021-11-08 11:17:43 <psykose> firmware is separate from the kernel/modules
2021-11-08 11:18:03 <ikke> It's the hardware that uses the firmware 
2021-11-08 11:21:44 <alandiwix> Thanks. I'm struggling to make this mediatek wireless card work. Could it be that the kernel is just built without the driver?
2021-11-08 11:21:59 <psykose> does it work on -lts instead
2021-11-08 11:22:23 <alandiwix> -lts just hangs for me on boot
2021-11-08 11:22:43 <alandiwix> see #13165
2021-11-08 11:24:07 <psykose> which mediatek card is it
2021-11-08 11:27:27 <alandiwix> 7961 I think
2021-11-08 11:27:52 <alandiwix> at list lspci gives that name
2021-11-08 11:28:01 <alandiwix> least*
2021-11-08 11:28:02 <psykose> not supported
2021-11-08 11:28:17 <psykose> 7921 is the newest supported according to https://wireless.wiki.kernel.org/en/users/drivers/mediatek
2021-11-08 11:28:32 <psykose> you can see what is enabled around here as well https://git.alpinelinux.org/aports/tree/community/linux-edge/config-edge.x86_64#n3423
2021-11-08 11:29:13 <psykose> that is for x86_64, you can search for similar in the other configs, lts has the same -mt76x0e for x86_64
2021-11-08 11:30:48 <psykose> according to some random things i found the 7921 driver would maybe work, but it would have to be enabled
2021-11-08 11:30:51 <alandiwix> Well, I think 7921 is included into 7961
2021-11-08 11:31:03 <psykose> think they should just all be enabled
2021-11-08 11:31:29 <psykose> if you have the time to build the kernel yourself you can go enable just that and run abuild for it
2021-11-08 11:33:36 <alandiwix> Search says "device 7961" is a Bluetooth/WiFi combo that has 7921 as a network card
2021-11-08 11:33:39 <psykose> you seem to be right, everyone with it working is using 7921
2021-11-08 11:33:42 <alandiwix> nasty naming
2021-11-08 11:33:50 <psykose> haha
2021-11-08 11:33:52 <psykose> in any case,
2021-11-08 11:34:02 <psykose> mps: CONFIG_MT7921E could be enabled for ^
2021-11-08 11:34:58 <mps> psykose: is it needed for x86/x86_64?
2021-11-08 11:35:05 <psykose> it's a network card this person has
2021-11-08 11:35:25 <mps> on x86?
2021-11-08 11:35:40 <mps> alandiwix: ^
2021-11-08 11:35:42 <psykose> i assumed x86_64, alandiwix can elaborate :)
2021-11-08 11:36:00 <alandiwix> yep
2021-11-08 11:36:05 <alandiwix> 64
2021-11-08 11:36:16 <mps> mtk are usually on arm 'world'
2021-11-08 11:36:50 <psykose> there seems to be a few new laptops using that one for some reason
2021-11-08 11:36:52 <mps> psykose: alandiwix: I add this to notes for next upgrade
2021-11-08 11:37:18 <psykose> i didn't even know there was new wifi6 chipsets from this vendor myself
2021-11-08 11:37:47 <alandiwix> yea, taiwan laptops supporting taiwan wireless chips...
2021-11-08 11:38:16 <mps> a lot of patches for mediatek are pushed to mainline in last few months
2021-11-08 11:38:20 <psykose> well, if they work better than broadcom that is nice
2021-11-08 11:38:42 <alandiwix> yea, but worse that intel
2021-11-08 11:39:36 <psykose> i've had my share of intel issues, but at least all of intel is under one `iwlwifi` module
2021-11-08 11:39:39 <psykose> certainly convenient
2021-11-08 11:42:06 <mps> I have wifi router full of mtk peripherals
2021-11-08 11:43:23 <mps> ethtool -i wlan0 => driver: mt7603e
2021-11-08 11:44:13 <mps>  ethtool -i eth0 => driver: mtk_soc_eth
2021-11-08 11:45:02 <mps> and current workstation is mediatek SoC (acer R13 chromebook)
2021-11-08 11:46:02 <psykose> blazing fast :)
2021-11-08 12:01:56 <mps> psykose: yes, it is really fast for machine 5 years old
2021-11-08 12:02:14 <mps> only faster I found is apple M1
2021-11-08 12:03:15 <mps> for daily work, I mean (and of the arm notebooks, I don't use intels for more that 3-4 years)
2021-11-08 12:03:30 <mps> more than*
2021-11-08 12:03:31 <psykose> there are really not a lot of arm notebooks sadly
2021-11-08 12:04:44 <mps> I'm quite satisfied with chromebooks, have 3 box, one arm32 and two arm64
2021-11-08 12:05:25 <mps> though my son ordered apple M1 for me, should arrive this week
2021-11-08 12:34:49 <fcolista> kernel 5.15.1-0-lts stucks on my machine. I had to install to 5.15.1-0-edge in order to have it booted
2021-11-08 12:35:02 <ikke> Seems more people have issues with it
2021-11-08 12:35:26 <ikke> bios or uefi?
2021-11-08 12:35:31 <fcolista> bios
2021-11-08 12:37:24 <donoban> fcolista: there is a issue opened for it
2021-11-08 12:37:42 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13165
2021-11-08 12:37:46 <ikke> ncopa: apparently not a lot of the haskell ecosystem is compattible with ghc 9 yet
2021-11-08 12:38:15 <ikke> https://github.com/haskell/cabal/issues/7747#issuecomment-943008401
2021-11-08 12:38:28 <fcolista> thx donoban 
2021-11-08 12:38:59 <donoban> I'm gonna test what ncopa suggests when I can reboot
2021-11-08 12:39:38 <fcolista> "Does caps lock work? (will the capslock led switch on/off?)" Not for me
2021-11-08 12:40:01 <donoban> do you have LUKS also?
2021-11-08 12:40:05 <fcolista> nope
2021-11-08 12:40:20 <donoban> and ctrl+alt+supr reboots properly?
2021-11-08 12:40:22 <mps> -lts needs a 'cleaning service company'
2021-11-08 12:40:38 <jvoisin> `rm`
2021-11-08 12:40:40 <donoban> hehe
2021-11-08 12:42:24 <mps> I promised ncopa that I will look over weekend to -lts config, I did and my conclusion is soooo harsh that I will not dare to say any word :)
2021-11-08 12:43:35 <Ariadne> ncopa: will seal with it today :)
2021-11-08 12:43:49 <Ariadne> deal*
2021-11-08 12:57:51 <donoban> fcolista: this is weird, the caps lock also fails for me, but blindy putting my luks passphrase works :\
2021-11-08 13:01:04 <psykose> it's probably the simpledrm option in 5.15
2021-11-08 13:02:24 <donoban> fcolista: have you tried ping or ssh login?
2021-11-08 13:03:56 <mps> psykose: I have CONFIG_DRM_SIMPLEDRM=m on my chromebook, and it works
2021-11-08 13:04:08 <psykose> it works for me too
2021-11-08 13:04:14 <psykose> but it might be what causes the issue for some people
2021-11-08 13:04:37 <mps> but on linux-edge x86_64 it is '# CONFIG_DRM_SIMPLEDRM is not set'
2021-11-08 13:04:42 <indy> aany chance to get gdbm 1.22 to 3.15.0?
2021-11-08 13:04:54 <psykose> hm
2021-11-08 13:05:21 <indy> ncopa, ^^
2021-11-08 13:11:33 <ikke> indy: would require a rebuild of some packages (including php and python), which we try to avoid at this moment
2021-11-08 13:12:27 <ikke> (unless there is a very compelling reason)
2021-11-08 13:20:32 <donoban> yeah!, adding both simplefb and simpledrm to the initramfs and modules= option works!
2021-11-08 13:28:43 <ikke> donoban: oh, nice!
2021-11-08 13:33:06 <MY-R> so compile in CONFIG_DRM_SIMPLEDRM=y or disable or leave as module and add somewhere in /etc/mkinitfs/features.d/
2021-11-08 13:34:11 <mps> MY-R: yes
2021-11-08 13:37:31 <Ariadne> hmm, simpledrm
2021-11-08 13:37:35 <Ariadne> https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers ?
2021-11-08 13:53:52 <Hello71> CONFIG_FB_SIMPLE=y not CONFIG_DRM_SIMPLEDRM=y
2021-11-08 13:54:44 <mps> or vice versa
2021-11-08 13:55:09 <mps> this have to be tested
2021-11-08 13:55:16 <MY-R> on gentoo I have CONFIG_DRM_SIMPLEDRM=y
2021-11-08 13:55:26 <Hello71> well the problem is that CONFIG_SYSFB_SIMPLEFB=y and CONFIG_FB_SIMPLE=m
2021-11-08 13:55:53 <mps> for aarch64 this works
2021-11-08 13:56:07 <mps> looks like not for x86
2021-11-08 13:56:16 <mps> x86_64*
2021-11-08 13:57:11 <MY-R> I dont even have any CONFIG_FB_SIMPLE, all I have:
2021-11-08 13:57:26 <MY-R> CONFIG_SYSFB=y
2021-11-08 13:57:28 <MY-R> CONFIG_SYSFB_SIMPLEFB=y
2021-11-08 13:57:32 <MY-R> CONFIG_DRM_SIMPLEDRM=y
2021-11-08 13:57:57 <MY-R> and working fine, gentoo-source-bin using fedora kernel configs
2021-11-08 13:58:24 <MY-R> gentoo-kernel-bin*
2021-11-08 14:01:47 <Hello71> if you use CONFIG_DRM_SIMPLEDRM=y then (according to fedora article) you can set CONFIG_FB=n
2021-11-08 14:02:04 <Hello71> CONFIG_FB_SIMPLE=y is more "conservative" option
2021-11-08 14:32:57 <indy> ikke, 1.22 brings some security fixes
2021-11-08 14:33:47 <indy> ikke, as they do not break api, i think rebuild gdbm should be enough
2021-11-08 14:36:33 <ikke> indy: ah, makes sense
2021-11-08 14:53:00 <Ariadne> mps: alpine + M1 is going to be a game changer i think
2021-11-08 14:53:39 <mps> Ariadne: I hope
2021-11-08 14:54:06 <mps> and I hope that I will have alpine on it in a week or two
2021-11-08 14:55:16 <mps> reseller is late with delivery for ten days now
2021-11-08 14:56:08 <mps> though I had alpine on my son box at the beginning of these year
2021-11-08 15:02:34 <Saijin_Naib[m]> What other STRs or other info should I add to help this issue be complete?
2021-11-08 15:02:41 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13163
2021-11-08 15:03:29 <Ariadne> mps: but no audio support yet, and 3D is still WIP
2021-11-08 15:03:48 <Ariadne> its about chromebook elm levels of usability i guess, sans the audio
2021-11-08 15:09:28 <mps> Ariadne: yes, audio is still missing though there are people works on it
2021-11-08 15:10:09 <mps> gpu will not be soon, I think but I don't need gpu too much
2021-11-08 15:10:37 <mps> also suspend/resume still not work
2021-11-08 15:11:12 <mps> but suspend/resume also doesn't work on elm with kernels 5.11 and up
2021-11-08 15:11:59 <mps> for sound I could use usb audio card
2021-11-08 15:12:55 <mps> but my main reason to switch to M1 is retina display, I need to care for my eyes
2021-11-08 15:13:15 <mps> else, elm will be quite fine for year or two
2021-11-08 15:16:42 <mps> Ariadne: you probably see my msgs on #asahi ;)
2021-11-08 15:18:36 <tomalok> ncopa: re gummiboot - if there was a way to build and package just the "systemd-boot" bits from systemd, then we'd have a maintained upstream repo.  !27249 would at least allow us to see if it's worth pursuing that angle for cloud images.
2021-11-08 15:41:04 <ncopa> ERROR: meson-0.59.3-r0: BAD signature
2021-11-08 15:41:04 <ncopa> (2/2) Downgrading meson-vim (0.60.1-r0 -> 0.59.3-r0)
2021-11-08 15:41:04 <ncopa> ERROR: meson-vim-0.59.3-r0: BAD signature
2021-11-08 15:41:16 <ncopa> i think we need bump pkgrel to fix the meson downgrade
2021-11-08 15:41:40 <ikke> yes
2021-11-08 15:41:48 <ikke> or purge dl-cdn
2021-11-08 15:44:32 <ikke> ncopa: I think we switched a bit too early to ghc 9
2021-11-08 15:44:48 <ikke> that makes it at the moment impossible to build cabal
2021-11-08 15:48:07 <ikke> sad, scaleway is EOL-ing their alpine image
2021-11-08 15:56:18 <psykose> 3.4.0.0 should work with ghc9, no?
2021-11-08 15:58:16 <psykose> the 9.0.1 release mentions it under included libraries https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/9.0.1-notes.html , assuming this is even the right thing to look at
2021-11-08 15:59:16 <psykose> latest cabal is also 3.6 it seems
2021-11-08 15:59:52 <ikke> https://github.com/haskell/cabal/issues/7747
2021-11-08 16:01:12 <psykose> ah
2021-11-08 16:02:08 <ikke> I'm not sure if that also counts for 3.4.0.0, I haven't tried it
2021-11-08 16:02:54 <ikke> https://github.com/haskell/cabal/issues/7763 seems to be a larger issue
2021-11-08 16:02:55 <psykose> the issue report is 3.4.0.0, so i'm not sure if these are two different 'cabals', or if you can't build 3.6.0.0 from 3.4.0.0+ghc9
2021-11-08 16:03:22 <psykose> you can see the cabal --version with ghc --version in it
2021-11-08 16:03:54 <ikke> It's also dependencies that are limiting versions
2021-11-08 16:04:41 <ikke> https://tpaste.us/PrYD 
2021-11-08 16:04:41 <psykose> yup
2021-11-08 16:07:14 <Ariadne> going to swap the openssl packages shortly.
2021-11-08 16:10:42 <HRio> ikke: do you have a link to this info from scaleway?
2021-11-08 16:11:41 <ikke> https://t.elements.scaleway.com/c/?t=19eff43-4mc-1swa-13m-1skea
2021-11-08 16:12:51 <HRio> thats sad indeed
2021-11-08 16:13:48 <psykose> that is almost the entirety of 'instantapps'
2021-11-08 16:32:26 <ddevault> bump, cc ncopa https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26774
2021-11-08 16:32:40 <ddevault> happen to be dealing with yet another google-sponsored DDoS of git.sr.ht today
2021-11-08 16:38:28 <ikke> but that changes does not specifically help with that, does it? (or is your intention to block google after this)
2021-11-08 16:38:56 <Newbyte> How would I make the -dbg splitting function work for the subpackages here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27210#note_190413
2021-11-08 16:40:57 <ddevault> ikke: it's just a first step
2021-11-08 16:41:20 <ddevault> being annoyed by google DoSing my servers is what motivated me to look more closely at goproxy
2021-11-08 16:41:28 <ddevault> but it also leads to broken packages and presents privacy concerns
2021-11-08 16:41:56 <ddevault> I don't think it'll help my dos problem, but it is a good change for those other reasons
2021-11-08 16:43:02 <ddevault> my ultimate intentions are to make this case to other distros, and ultimately to make the case with Go that goproxy shouldn't exist at all
2021-11-08 16:43:32 <ikke> ddevault: did you intend to add these other commits? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26774/commits
2021-11-08 16:43:50 <ddevault> hm, no, I thought I got rid of those
2021-11-08 16:45:06 <ddevault> I fixed it but gitlab hasn't noticed
2021-11-08 16:45:07 <ddevault> god I hate gitlab
2021-11-08 16:45:28 <ddevault> there it goes
2021-11-08 16:48:52 <PureTryOut> thanks for that MR btw. I didn't realize GOPROXY was a thing and to me disabling it only makes sense
2021-11-08 16:49:22 <ddevault> np
2021-11-08 17:12:34 <nmeum> ddevault: how does Go authenticate downloaded source code without the GOSUMDB?
2021-11-08 17:12:57 <ddevault> it checks against the local go.sum file
2021-11-08 17:13:28 <ddevault> I think this is sufficient: one person checksums it themselves, and then everyone else who builds the code (including CI, other maintainers, downstream users) checks it against their checksum
2021-11-08 17:13:36 <ddevault> if funny business is about, it gets noticed
2021-11-08 17:16:20 <Ariadne> (206/242) Replacing meson (0.59.3-r0 -> 0.59.3-r0)
2021-11-08 17:16:20 <Ariadne> ERROR: meson-0.59.3-r0: BAD signature
2021-11-08 17:16:28 <Ariadne> the revert needs a different $pkgrel.
2021-11-08 17:16:36 <ikke> heh, that's 3 :P
2021-11-08 17:20:43 <Ariadne> anyway, openssl is back to 1.1
2021-11-08 17:20:48 <Ariadne> apk upgrade --available is important
2021-11-08 17:22:13 <mps> kernels in alpine are in bad shape, linux-edge and linux-edge-dev, then linux-edge4virt and linux-edge4virt-dev. same for -lts
2021-11-08 17:23:02 <ikke> mps: someone asked about CVE-2021-39537 for ncurses in 3.14. Do you know anything about it?
2021-11-08 17:23:17 <mps> proper linux-headers should be good to fix this
2021-11-08 17:23:43 <mps> ikke: iirc it is false CVE, but have to look at it
2021-11-08 17:24:20 <ikke> https://nvd.nist.gov/vuln/detail/CVE-2021-39537
2021-11-08 17:24:21 <mps> now I'm in the middle of trying to fix simpledrm for kernels
2021-11-08 17:24:25 <ikke> sure, np
2021-11-08 17:24:56 <ikke> https://security.alpinelinux.org/vuln/CVE-2021-39537
2021-11-08 17:25:04 <mps> if I enable all what fedora have on above url kernel doesn't build
2021-11-08 17:26:57 <mps> ikke: https://lists.gnu.org/archive/html/bug-ncurses/2021-10/msg00023.html
2021-11-08 17:27:35 <mps> I doubt we should upgrade ncurses on stable releases
2021-11-08 17:27:52 <minimal> mps: you're compiling simpledrm into kernel?
2021-11-08 17:28:01 <mps> minimal: yes
2021-11-08 17:29:03 <minimal> mps: ok, let me know if you need any kernel packages tested on BIOS/UEFI VMs
2021-11-08 17:29:07 <mps> minimal: I have to build few of them to test on different arches
2021-11-08 17:29:26 <mps> and different SoCs
2021-11-08 17:30:19 <mps> minimal: sure, I count on you to help with linux-edge
2021-11-08 17:30:37 <Ariadne> ikke: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/ncurses/patches/patch-ncurses_tinfo_captoinfo.c?rev=1.1&content-type=text/x-cvsweb-markup
2021-11-08 17:31:26 <mps> heh, 'Many thanks to Thomas Dickey for help in tracking down the bugfix patch!'
2021-11-08 17:31:42 <Ariadne> i want to thank thomas by removing his code from alpine
2021-11-08 17:32:38 <mps> this is quite proper idea which I sometimes consider, i.e. move to *BSD :)
2021-11-08 17:33:32 <Ariadne> i've been sketching out a modern replacement to `alpine-conf`, which has a menu-driven interface like bsdconfig
2021-11-08 17:35:26 <nmeum> what's wrong with the alpine-conf interface?
2021-11-08 17:36:03 <nmeum> only use alpine-conf during initial setup and for that purpose I really like the interface (reminds me of the openbsd installer)
2021-11-08 17:38:37 <Ariadne> among other things, i would like a capable partitioner for sys mode :p
2021-11-08 17:39:51 <psykose> i've always used setup-interfaces, apkrepos, then manually did disk stuff and setup-disk on a mountpoint
2021-11-08 17:40:02 <psykose> afaik the answer file doesn't even pass on rootfstype
2021-11-08 17:42:23 <Ariadne> yes, that's the other thing i want
2021-11-08 17:42:27 <Ariadne> answer file as first class citizen :P
2021-11-08 17:43:37 <psykose> answer file with a 'declarative spec' kind of answering for everything would be nice
2021-11-08 17:43:53 <psykose> which it already is in a way, but you know, with that kind of mentality
2021-11-08 19:37:34 <mps> minimal: for VMs to boot with grub uefi boot partition must be vfat? ext4 will not work?
2021-11-08 19:43:29 <minimal> boot fstype isn't relevant for UEFI, only that the ESP partition must be FAT16/FAT32
2021-11-08 19:44:15 <minimal> I use ext4 for /boot fine (whenever I actually bother to have a /boot separate from rootfs)
2021-11-08 19:44:20 <mps> minimal: yes, I mean ESP instead of boot partition. thanks for confirmation
2021-11-08 19:44:51 <minimal> ESP needs to be FAT16 or FAT32 (think FAT12 might work also).
2021-11-08 19:45:30 <tomalok> if you want to use EFI_STUB from kernel, your kernel/initrd will need to be on vfat too.  (FAT12 does work, btw)
2021-11-08 19:45:56 <minimal> Size is a problem for ESP partition - I've tried shrinking it and had problems with some UEFI implementations if its is too small - using 48MB for ESP on VMs currently
2021-11-08 19:46:05 <tomalok> (by "on vfat" i mean they'll need to be on ESP)
2021-11-08 19:47:08 <tomalok> I think I got the latest cloud image to work with 512KiB...
2021-11-08 19:47:13 <minimal> tomalok: yes that's an implementation-specifc issue, same with Syslinux UEFI, it needs boot & kernel to be in ESP also, whereas with Grub it has its own modules for various filesystems to load kernel/initramfs from elsewhere
2021-11-08 19:47:50 <minimal> tomalok: FAT12 with tweaked cluster settings?
2021-11-08 19:48:13 <tomalok> (nod) i looked at syslinux UEFI but dropped that when i discovered no aarch64 ;)
2021-11-08 19:49:48 <tomalok> So, the new alpine-cloud-images was trying to format UEFI using busybox mkfs.vfat -- and i was having problems.  I switched to using dosfstools' mkfs.fat and my problems went away.  it figures out what FAT to use (in my case 12) based on the size of the partition, and apparently does something correctly that busybox does not
2021-11-08 19:50:32 <tomalok> previously, alpine-ec2-ami builder was using an Amazon Linux instance to put together the image, and was using the non-busybox mkfs.fat, too.
2021-11-08 19:51:26 <minimal> tomalok: ah, I resorted to doing things like "mkfs.fat -F16 -s 1 -S 512" but haven't spend too much time getting it as small as possible
2021-11-08 19:51:59 <tomalok> yeah, i just let it figure it out, and it was fine
2021-11-08 19:53:49 <minimal> actually that is coming from the dosfstools package. I had to use options like that to get to avoid cluster warnings from it
2021-11-08 19:54:36 <minimal> I got the impression that FAT12 support is not uniformly supports by various UEFI implementations so didn't want to get too aggressive
2021-11-08 19:54:44 <tomalok> i did try to move the partition closer down to LBA34 but eventually decided not to fiddle too much, and i start ESP at 512KiB with a size of 512KiB, which allows my root partition to start on a nice optimized boundary at 1MiB
2021-11-08 19:55:15 <minimal> s/supports/supported/
2021-11-08 19:55:15 <alpine-meetbot> minimal meant to say: I got the impression that FAT12 support is not uniformly supported by various UEFI implementations so didn't want to get too aggressive
2021-11-08 19:55:19 <tomalok> the ESB is not in optimal alignment, but it shouldn't be too much of an issue as it's only rarely referenced after boot
2021-11-08 19:56:00 <tomalok> FAT12 worked well enough for AWS EC2 :)
2021-11-08 19:56:46 <minimal> tomalok: sure, the question is does it reliably work for other clouds and VM hypervisors and various PCs
2021-11-08 19:57:16 <tomalok> that is indeed at least one of the questions :)
2021-11-08 19:58:03 <tomalok> i will try 16 and 32 later today to see if AWS EC2 is okay with that.
2021-11-08 20:05:59 <minimal> tomalok: I'm trying a build with 1MB FAT12 currently out of interest :-)
2021-11-08 20:07:38 <tomalok> i've got several more hours on the clock for the DayJob™ but i should have time to test that afterward.
2021-11-08 20:10:58 <minimal> tomalok: haven't tried booting it yet (on virtualbox) but the mkfs.fat didn't give any cluster warning which is a good sign. I'll still have to test VB to see if its UEFI implementation is happy or not wih F12
2021-11-08 20:14:37 <minimal> tomalok: from memory once you go below 100MB FAT16/FAT32 you are outside of "recommended" / "supported" ESP partition sizes. I've got the spec somewhere here but I seem to remember 100MB is Microsoft's min definition and you know UEFI vendors will likely only really test stuff with Windows... :-(
2021-11-08 20:19:49 <mps> minimal: tomalok: any good url with guide how to setup all this
2021-11-08 20:20:25 <mps> (quite annoyed to read about micrsofoft to use linux)
2021-11-08 20:20:35 <minimal> mps: UEFI with which bootloader?
2021-11-08 20:20:51 <mps> grub-efi, I think
2021-11-08 20:24:07 <minimal> so create a ESP partition, I use parted: "parted --machine --script --align optimal <device> unit MiB mkpart primary fat32 0% 48MiB set 1 esp on"
2021-11-08 20:24:11 <mps> minimal: if you don't have it at hands, do not search, I will find it
2021-11-08 20:24:23 <minimal> mps: I have it all scripted :-)
2021-11-08 20:24:25 <psykose> having efibootmgr and installing grub-efi will set it up in post-install with an esp at /boot/efi
2021-11-08 20:24:49 <psykose> with an esp you already put there**
2021-11-08 20:25:15 <minimal> then "grub-install --bootloader-id=alpine --efi-directory=/efi --no-nvram --target=x86_64-efi <device>"
2021-11-08 20:25:45 <minimal> in my case I'm mounted the ESP partition as /efi rather than as /boot/efi that some others night do
2021-11-08 20:25:48 <mps> I did all this with syslinyx but lost script
2021-11-08 20:26:04 <minimal> mps: have Syslinux UEFI also scripted :-)
2021-11-08 20:26:18 <psykose> just post the script :p
2021-11-08 20:26:43 <minimal> psykose: its already been posted for some time: https://github.com/dermotbradley/create-alpine-disk-image
2021-11-08 20:26:58 <minimal> though as usual the posted version lags behind my current version
2021-11-08 20:27:19 <psykose> ahh, this
2021-11-08 20:27:22 <psykose> i remember seeing this around
2021-11-08 20:30:38 <mps> minimal: just to confirm, gpt part table?
2021-11-08 20:31:12 <minimal> mps: yupe, not tried UEFI with mbr, always used GPT
2021-11-08 20:32:08 <mps> ok
2021-11-08 20:35:54 <minimal> tomalok: just realised that parted doesn't support "fat12" as an option, only "fat16" and "fat32"
2021-11-08 20:36:38 <psykose> is there any benefit to non-fat32 options
2021-11-08 20:38:51 <dalias> was fat12 ever a partition type option??
2021-11-08 20:38:58 <dalias> i thought it was only used on unpartitioned floppy disks
2021-11-08 20:39:21 <minimal> psykose: size AFAIK, you can make smaller fat12 or fat16 filesystems than fat32
2021-11-08 20:39:29 <psykose> ah
2021-11-08 20:40:05 <minimal> dalias: not sure, that's why I'm wondering. The mkfs.fat tool does take -F12 and -F16 options for formatting, perhaps its the same underlying partition type though
2021-11-08 20:40:14 <dalias> just the fat is smaller
2021-11-08 20:40:40 <dalias> minimal, i'm saying (at least AIRI) 12 isn't used on partitions only on whole-disk and only for floppies
2021-11-08 20:41:51 <dalias> minimal, just the fat itself becomes smaller (25% smaller than fat16), but it requires the total number of clusters to fit in 12 bits
2021-11-08 20:42:33 <dalias> i suspect they used 512b clusters for a 2MB limit
2021-11-08 20:42:33 <minimal> dalias: ok, I'll take your word for it. Am trying to shrink an ESP partition as small as possible yet that still works with common UEFI implementations
2021-11-08 20:42:53 <dalias> heh
2021-11-08 20:43:54 <minimal> I only have 266Kb of files in the ESP partition lol
2021-11-08 20:44:01 <dalias> well i would avoid fat12 then. it's going to save *at most* 2kB and it's unlikely to be compatible
2021-11-08 20:44:45 <dalias> and if you have to increase cluster size to make fat12 work it will surely waste much more than 2kB in slack space
2021-11-08 20:47:38 <tomalok> minimal: i used "fat32" with parted, and formatted FAT12... was fine.
2021-11-08 21:06:30 <eschwartz> I have always used a fat12 efi partition
2021-11-08 21:07:19 <eschwartz> mine is 2mb in size, horrifically overkill compared to the size of the only file on it (a stub loader)
2021-11-08 21:21:22 <dalias> if the partition is going to be tiny the fat will be 1 sector regardless of whether it's fat12, 16, or 32
2021-11-08 21:35:13 <minimal> dalias: in the past when creating small FAT32 partitions and the formatting them mkfs.fat would give warnings such as "WARNING: Number of clusters for 32 bit FAT is less then suggested minimum." and I've used "-s" and "-S" options to adjust sectors-per-cluster and sector size
2021-11-08 22:01:45 <donoban> doing some cleanup I discovered acct package, no new release since 2017 and it seems pretty broken (couldn't open file '/dev/null/wtmp': Not a directory) 
2021-11-08 22:02:31 <donoban> is it needed for something? it is not dependency for anything but I have it in apk/world
2021-11-08 22:04:12 <donoban> "The system's default login accounting file is /dev/null/wtmp.
2021-11-08 22:04:21 <donoban> maybe I broke it with my "cleanup"
2021-11-08 22:13:46 <streampunk> donoban: Musl doesn't support wtmp, don't know if that is relevant to your problem: https://wiki.musl-libc.org/faq.html#Q:-Why-is-the-utmp/wtmp-functionality-only-implemented-as-stubs?
2021-11-08 22:15:19 <ikke> There is utmps
2021-11-08 22:15:26 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/utmps
2021-11-08 22:15:36 <ikke> https://skarnet.org/software/utmps/
2021-11-08 22:15:37 <donoban> I have it
2021-11-08 22:15:49 <minimal> donoban: I didn't work on some patches for acct a while ago to enable utmps support
2021-11-08 22:16:15 <ikke> I didn't either :P
2021-11-08 22:16:30 <minimal> s/didn't/did/
2021-11-08 22:16:30 <alpine-meetbot> minimal meant to say: donoban: I did work on some patches for acct a while ago to enable utmps support
2021-11-08 22:16:32 <minimal> :-)
2021-11-08 22:16:34 <donoban> yeah it doesn't seems a big loose
2021-11-08 22:17:11 <donoban> ah well I just pretty suprised to have an installed package by default wich seems broken
2021-11-08 22:17:53 <minimal> I'd intended to start raising MRs for them after 3.14 came out but, amongst other thing someone's elses patches for utmps in Busybox didn't get merged so I held off to see how that panned out
2021-11-08 22:18:16 <skarnet> minimal: I should be available soon-ish to help with the merge, if you're willing
2021-11-08 22:19:02 <donoban> hehe great
2021-11-08 22:19:03 <minimal> skarnet: sure, just that Busybox MR seems to have either died or paused
2021-11-08 22:19:33 <skarnet> yeah I need to take a look at how bb handles utmps for other reasons anyway
2021-11-08 22:19:46 <skarnet> I'll check which versions make it manageable
2021-11-09 07:46:44 <indy> ncopa, ikke i just built gdbm 1.22 and installed python3 and played with dbm.gnu module - https://dpaste.org/FCY5
2021-11-09 07:47:36 <indy> on 3.14
2021-11-09 08:11:54 <ncopa> good morning
2021-11-09 08:12:02 <ikke> o/
2021-11-09 08:12:02 <ncopa> does gdbm 1.22 break ABI?
2021-11-09 08:12:21 <ikke> I checked abi-laboratories, but it's outdated
2021-11-09 08:13:16 <ikke> 1.22 is out as well already
2021-11-09 08:14:34 <ikke> ncopa: there is no soname difference
2021-11-09 08:15:15 <ikke> same for 1.22
2021-11-09 08:27:32 <ncopa> ok. then I guess we can upgrade?
2021-11-09 08:27:58 <ikke> I suppose so, yes
2021-11-09 08:33:06 <ncopa> i think i'm gonna disble fbdev drivers in kernel, and rely on simpledrm instead
2021-11-09 08:43:32 <indy> ncopa, do you want issue for 3.15.0 milestone?
2021-11-09 08:43:39 <indy> ncopa, for gdbm?
2021-11-09 08:47:43 <ncopa> is there an open MR?
2021-11-09 08:49:31 <ncopa> i found it
2021-11-09 08:52:22 <ikke> it's merged ftr
2021-11-09 08:53:27 <ikke> ncopa: in case you didn't notice, ghc is now built with system ffi
2021-11-09 08:53:53 <ikke> Only cabal + what depends on it is still missing
2021-11-09 08:54:06 <psykose> now if only the rest of haskell can build against 'ghc' :)
2021-11-09 08:54:22 <psykose> sometimes i feel like the dependencies in haskell are as bad as in nodejs
2021-11-09 08:54:38 <ikke> psykose: :)
2021-11-09 08:55:14 <ncopa> ikke: awesome! thank you very much!
2021-11-09 09:40:32 <adhawkins> Anyone able to take a look at !26894
2021-11-09 09:40:59 <adhawkins> It's been waiting for longer than I would normally expect. Is there an issue with it, or is it just nobody has got round to looking at it?
2021-11-09 09:41:11 <ikke> adhawkins: most focus is on the 3.15 release atm
2021-11-09 09:41:27 <adhawkins> ikke: Understood. I'll try to be patient then :)
2021-11-09 09:41:43 <adhawkins> There's a new version of emborg just been released, and don't want to work on that while this MR is still outstanding.
2021-11-09 09:42:06 <ikke> ftr, changes in arch do not require a pkgrel bump
2021-11-09 09:43:06 <adhawkins> ikke: Ok, I wasn't sure about that. Will try to remember in future.
2021-11-09 09:43:48 <ikke> It's only required if you need pacakges to be rebuilt
2021-11-09 09:59:16 <ncopa> I'm in doubt if I should build  CONFIG_DRM=y or CONFIG_DRM=m
2021-11-09 09:59:36 <ncopa> with CONFIG_DRM=y I can enable SIMPLEDRM=y, which is very small
2021-11-09 09:59:44 <ncopa> CONFIG_DRM seems to 200K or so
2021-11-09 10:00:22 <ncopa> but with CONFIG_DRM=m we'll need to modprobe simpledrm from initramfs to get early console
2021-11-09 10:00:53 <ncopa> and we'll not have any console til after modprobe simpledrm
2021-11-09 10:01:19 <ncopa> with SIMPLEDRM=y (and CONFIG_DRM=y) we will have early console
2021-11-09 10:08:00 <mps> ncopa: you have to set DRM=y
2021-11-09 10:08:49 <mps> well, if 'we' want users to early boot errors
2021-11-09 10:09:07 <mps> and ofc remove 'quiet' from cmdline :)
2021-11-09 10:21:35 <mps> I'm thinking to disable -dev subpkgs for linux-edge. anyone have objections?
2021-11-09 10:22:24 <psykose> seems fine
2021-11-09 10:22:31 <psykose> i guess there will be a linux-headers-edge instead?
2021-11-09 10:23:23 <mps> psykose: I thinking about this in 'one packet'
2021-11-09 10:24:02 <psykose> not sure what you mean
2021-11-09 10:25:21 <mps> remove -dev and add linux-header in one commit
2021-11-09 10:26:10 <mps> ncopa: looks like if 'real' DRM driver is enabled simpledrm is not used at boot
2021-11-09 10:26:23 <psykose> ah
2021-11-09 10:26:27 <psykose> makes sense
2021-11-09 10:26:57 <mps> and I don't have hardware for which drm driver doesn't exists in kernels to test activation of simpledrm
2021-11-09 10:29:10 <mps> psykose: that is how void linux and arch alarm do these things, they build linux-headers with every kernel upgrade
2021-11-09 10:29:37 <psykose> yep :)
2021-11-09 10:42:08 <ncopa> mps: as I understand the idea is to have a generic, dimple drm driver in initramfs, and then let the more advanced "real" drm driver take over later
2021-11-09 10:42:31 <mps> I think so
2021-11-09 10:42:54 <ncopa> that is so we dont need to have every single drm driver in initramfs (or copiled into kernel)
2021-11-09 10:43:16 <mps> again this is what I think
2021-11-09 10:43:48 <mps> should try to find hardware without 'real' drm driver and test it
2021-11-09 10:44:01 <ncopa> i tested it in qemu
2021-11-09 10:44:04 <ncopa> it works
2021-11-09 10:44:18 <mps> ah, good idea
2021-11-09 10:44:19 <ncopa> simpledrm takes initial console
2021-11-09 10:44:46 <ncopa> later DRM_VIRTIO_GPU takes over
2021-11-09 10:45:06 <ncopa> or DRM_BOCHS
2021-11-09 10:45:20 <mps> yes, any of virt DRM
2021-11-09 10:46:21 <mps> maybe I could make real drm driver as module on my box and disable it in 'blacklist' to test on real hardware
2021-11-09 11:01:27 <adhawkins> ikke: Where is the 'arch' setting stored? Is it in the package itself, or just in the indexes? I assumed the package would need to be rebuild for the new arch to take effect.
2021-11-09 11:01:33 <adhawkins> 
ACTION has a lot to learn still :)

2021-11-09 11:04:25 <ikke> adhawkins: it's not stored, except in the fact that the package is present for a certain arch or not
2021-11-09 11:05:35 <ikke> so if you enable a certain arch, the builder for that arch notices the package is not present but should be, so it starts building it
2021-11-09 11:05:44 <ikke> if you disable an arch, that builder will just ignore it
2021-11-09 11:07:31 <adhawkins> Ok, great. Thanks ikke. I don't suppose there's a handy document I can read that summarises this?
2021-11-09 11:07:42 <ikke> No, not at the moment
2021-11-09 11:08:55 <adhawkins> Ok thanks. Just trying to avoid asking too many basic questions :)
2021-11-09 11:51:08 <alandiwix> ncopa: what is the release cycle for mkinitfs? Can we have a release soon? Having recent changes in init script for overlaytmpfs and UUID in 'resume' as a part of upstream package would be very nice.
2021-11-09 11:55:53 <donoban> for adding a missing dependency is needed to bump pkgrel?
2021-11-09 12:05:33 <psykose> yes
2021-11-09 12:06:53 <donoban> ok
2021-11-09 12:21:17 <mps> does grub-install boot in mbr?
2021-11-09 12:21:34 <mps> grub-install installs*
2021-11-09 12:48:08 <ncopa> alandiwix: i'm planning to do mkinifs release soonish. before 3.15 release
2021-11-09 12:49:37 <alandiwix> sounds great, thanks
2021-11-09 12:58:10 <mps> nwm, found the issue
2021-11-09 14:05:20 <Hello71> ncopa: if you are concerned about size why not use simplefb instead of simpledrm?
2021-11-09 14:06:28 <Hello71> also 2021-11-06 13:43:56     Hello71 ncopa: do you plan to update linux-rpi to 5.15 for 3.15?
2021-11-09 14:06:37 <ncopa> fbdev is deprecated
2021-11-09 14:06:49 <ncopa> yes, I plant to upgrade linux-rpi to 5.15
2021-11-09 14:07:44 <ncopa> see https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers about the fbdev replacement
2021-11-09 14:09:00 <Hello71> well... fbdev is deprecated for outside users. as the article says, fbcon still uses fbdev, so you can't CONFIG_FB=n
2021-11-09 14:10:32 <Hello71> i think CONFIG_DRM=y is ok too, increases kernel size but decreases module size
2021-11-09 14:19:33 <ncopa> i did CONFIG_DRM=m for now
2021-11-09 14:20:35 <minimal> ncopa: for RPI are you sure the Foundation 5.10.x branch is ready?
2021-11-09 14:20:59 <minimal> s/5.10/5.15/
2021-11-09 14:20:59 <alpine-meetbot> minimal meant to say: ncopa: for RPI are you sure the Foundation 5.15.x branch is ready?
2021-11-09 14:22:13 <ncopa> minimal: I guess we will find out...
2021-11-09 14:24:27 <minimal> ncopa: I think there's a strong risk of breaking things for RPI by going to 5.15.x for RPI currently
2021-11-09 14:27:00 <ikke> "Add the spellcheck option", not my proudest commit message
2021-11-09 14:27:55 <MY-R> shouldnt be firmware for rpi in sync with kernel raspberrypi-bootloader pkg? Alpine using files for 5.10.x "master" and no "next" branch https://github.com/raspberrypi/firmware
2021-11-09 14:28:36 <MY-R> if wanna use it 5.15.x kernel then "raspberrypi-bootloader" need use "next" branch
2021-11-09 14:31:39 <ncopa> minimal: why do you think so?
2021-11-09 14:32:28 <minimal> MY-R: indeed. However the Foundation repo for their 5.10.x kernel, https://github.com/raspberrypi/linux/commits/rpi-5.15.y is still showing lots of commits (100+ comit yesterday alone) which implies its not stable yet
2021-11-09 14:33:58 <minimal> ncopa: first that the page https://github.com/raspberrypi/rpi-firmware/commits/master implies 5.10.78 is the latest "stable" Foundation kernel, and also that the 5.15.x branch is still having extensive commits currently - 100+ alone yesterday, its a moving target and unlikely to be stable/reliable
2021-11-09 14:35:27 <ncopa> i sorta thought that upstream kernel had support for rpi nowdays
2021-11-09 14:38:01 <minimal> ncopa: as I mentioned on here before, nope - some stuff has been upstreamed but not everything and it appears that, as in order to upstream the Foundation were "forced" to rewrite their commits to meet kernel standards then in their own fork when they move to a new kernel version as a base they sometimes/often then "revert" the new upstream addition and place their own "old" version of the functionality on top
2021-11-09 14:38:46 <minimal> ncopa: all the Device Tree Overlay stuff is not in upstream and this is used for various hardware RPI uses (including official HATs like fan and PoE)
2021-11-09 14:39:41 <minimal> basically the patch set is not really reducing, at best its "holding position", at worse its still getting bigger with new hardware coming out
2021-11-09 14:41:44 <minimal> ncopa: I was wrong when I said 100+ commits yesterday to their 5.15.y branch - its more like 300+ commits in one day
2021-11-09 14:42:12 <mps> minimal: iiuc you got less than optimal kernels then if they are not passed mainline standards
2021-11-09 14:43:07 <mps> current mainline kernels are fine for rpis
2021-11-09 14:43:59 <mps> maintaining specific kernels for random vendors is not easy task for distros
2021-11-09 14:44:22 <minimal> mps: My understanding (from talking to some other "distro" people doing RPI builds) is that some of the upstream RPI stuff is basically broken and then Foundation fix it in their patches
2021-11-09 14:45:03 <mps> debian doesn't (and debian is not 'small' in metric)
2021-11-09 14:49:00 <psykose> is there more context to 'revert upstream commit and reapply their old one'
2021-11-09 14:49:05 <psykose> because that sounds asinine
2021-11-09 14:49:29 <psykose> i can't figure out why they would do that if it's the same functionality, or why they wouldn't just make sure to get the same thing into upstream by upstream standard
2021-11-09 14:56:11 <minimal> psykose: I don't understand either
2021-11-09 14:57:25 <minimal> maybe I'm wrong - I've been talking to people who are building RPI kernels on a regular basis using upstream and having to work around issues/apply patches to get it working
2021-11-09 15:02:49 <minimal> ncopa: you could talk to some of the guys in #arm-img-builder on Libera IRC to hear it straight from the horses mouth...
2021-11-09 15:27:38 <minimal> ncopa: re DRM, on Virtualbox simpledrm is initial console with the vmwgfx DRM (VMware written but also used by VB) also takes over during boot
2021-11-09 15:33:22 <ncopa> minimal: did you test the linux-lts/linux-virt 5.15.1-r1 kernels on virtualbox? I think they should work now
2021-11-09 15:35:56 <minimal> ncopa: not yet, will be doing so later today
2021-11-09 21:07:05 <bl4ckb0ne> anybody has experience packaging with boost-build
2021-11-09 21:07:35 <bl4ckb0ne> the pkgconfig generated has path directing to my aports folder and i suspect b2
2021-11-10 06:31:43 <ncopa> good morning
2021-11-10 06:32:24 <ncopa> we need to solve the dependency errors in repositories before we can make a final release
2021-11-10 06:32:42 <ncopa> docker run --rm -it alpine:edge sh -c 'apk upgrade -U -a -q --no-progress; apk dot --errors'
2021-11-10 06:51:17 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13173
2021-11-10 07:11:51 <ikke> I see shellcheck in there, which has been disabled. 
2021-11-10 07:26:57 <ikke> ncopa: I suppose that would mean we would need to actually remove the apkbuilds for those packages instead of disabling them?
2021-11-10 07:28:17 <ikke> For that particular case, because they have never been built for 3.15, it should not be an issue. Nothing prevents us enabling them again after 3.15 has been branched, as cabal is still available and built against a recent libffi
2021-11-10 07:28:29 <ikke> we just cannot build cabal atm
2021-11-10 07:33:02 <mps> good morning
2021-11-10 07:33:53 <mps> anyone have script to make commits of revdep for package
2021-11-10 07:34:52 <ikke> I typically just use shell oneliners
2021-11-10 07:36:01 <mps> ikke: when (and if) you find some free time could you post example
2021-11-10 07:36:25 <ikke> for PKG in $(ap revdep rust); do (cd $PKG; apkgrel -a . && git commit -m "community/$PKG: rebuild to mitigate CVE-2021-29922"; ); done 
2021-11-10 07:37:04 <ikke> hmm, that forgot to stage the file
2021-11-10 07:37:24 <mps> so fast, thanks. have to convert it to tcsh
2021-11-10 07:37:49 <mps> yes, 'git add' is missing
2021-11-10 07:38:25 <ikke> for PKG in $(ap revdep rust); do apkgrel -a $PKG; git commit -m "community/$PKG: rebuild to mitigate CVE-2021-29922" $PKG/APKBUILD; done
2021-11-10 07:39:00 <ikke> no need for a subshell either
2021-11-10 07:39:29 <mps> hmm, I don't see 'git add'
2021-11-10 07:39:59 <ikke> I directly specified the file to the commit command
2021-11-10 07:40:22 <ikke> in which case git add is not needed
2021-11-10 07:40:37 <mps> ah, new thing for me
2021-11-10 07:40:57 <fcolista> i didn't knot that either
2021-11-10 07:41:06 <fcolista> *know
2021-11-10 07:41:21 <ikke> It even skips things that were already staged
2021-11-10 07:41:25 <fcolista> cool...thx ikke nice hint about adding the unstaged file to git commit
2021-11-10 07:45:35 <nmeum> mps: there is also https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10033
2021-11-10 07:47:05 <mps> nmeum: thanks
2021-11-10 07:48:48 <fcolista> that's something should be into abuild
2021-11-10 07:49:23 <clandmeter> maybe for contrib dir
2021-11-10 07:49:37 <ikke> I don't think it should be part of abuild itself per-se
2021-11-10 07:50:07 <ikke> And there are other reasons to rebuild packages, which this does not cover
2021-11-10 07:50:22 <ikke> (ie, rebuilding go / rust / ghc packages)
2021-11-10 07:50:23 <clandmeter> its nice to have a dedicated place for such scripts, just not bloat abuild even more.
2021-11-10 07:50:28 <ikke> or python / ruby modules
2021-11-10 07:50:42 <fcolista> +1 clandmeter 
2021-11-10 07:50:52 <fabled> what's the status of enabling libreoffice? seems it go disabled due to https://gitlab.alpinelinux.org/alpine/aports/-/issues/13141
2021-11-10 07:51:09 <mps> ikke: oh no, python or ruby
2021-11-10 07:51:53 <ikke> fabled: It fails to build due to some issue with boost_filesystem
2021-11-10 07:51:58 <ikke> just need to figure out what the issue is
2021-11-10 07:52:47 <ikke> https://tpaste.us/OryY
2021-11-10 07:53:16 <ikke> fabled: but for some reason, it only happens for 3.15, not for edge
2021-11-10 07:56:10 <fabled> strange
2021-11-10 07:56:29 <fabled> but since 3.15 is not branched, libreoffice is now disabled also on edge
2021-11-10 07:56:33 <ikke> yes
2021-11-10 08:01:23 <mps> ikke: I invoked you one liner !27236 lets see is it ok
2021-11-10 08:02:40 <ncopa> ikke: we can downprioritize shellcheck for now, and focus on those that are easily fixed
2021-11-10 08:02:57 <ikke> nod
2021-11-10 08:04:32 <mps> ncopa: and all: for clamav best I managed to get is !25043
2021-11-10 08:05:24 <mps> actually it is 0.104.1, and this package should be upgraded to this release on 3.15
2021-11-10 08:05:46 <mps> but I don't know how to make it cleaner
2021-11-10 08:06:56 <mps> please anyone who know better/proper than me to review and possibly fix it
2021-11-10 09:09:15 <ncopa> Ariadne: why was ldns updated to a git version? f2002cd811a31e70f8db43414e29ac14973d075a
2021-11-10 09:09:56 <ncopa> seems like we have some packages depending on so:libldns.so.3, which we no longer have any provider for. I wonder how we ended up here
2021-11-10 09:12:49 <mps> some xf86-video packages doesn't build with upgraded xorg-server
2021-11-10 09:19:54 <ncopa> mps: we cannot push xorg-server until those are resolved one way or the other
2021-11-10 09:20:12 <maxice8> Ikke HRio: !27310 waiting on CI
2021-11-10 09:20:12 <mps> yes, I see
2021-11-10 09:20:40 <mps> ncopa: I answered your comment
2021-11-10 09:25:07 <ncopa> mps: someone needs to investigate. I don't have time to do so
2021-11-10 09:27:22 <mps> i think I made fix for qxl
2021-11-10 09:27:47 <mps> also I don't have much free time
2021-11-10 09:28:09 <ncopa> ok. then we wait with xorg-server update
2021-11-10 09:29:21 <HRio> maxice8: thanks!
2021-11-10 09:30:25 <ikke> I have time today to look at things
2021-11-10 09:31:21 <Gaming4LifeDE> Can you guys have another look at this? This is still an issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12413  Sorry if this is the wrong channel to ask for this, i'm new here :)
2021-11-10 09:34:39 <mps> #12413
2021-11-10 09:35:50 <Gaming4LifeDE> You still have to run the chmod for it to work. I'm running edge, so i should have the updated version already
2021-11-10 09:36:07 <ddevault> seems that man pages for binutils are broken
2021-11-10 09:37:15 <maxice8> HRio: not done yet, another test needs fixing
2021-11-10 09:37:21 <ikke> ddevault: Yes, I see
2021-11-10 09:40:11 <mps> looks like this could be patch for xf86-video-nouveau https://github.com/archlinux/svntogit-packages/blob/packages/xf86-video-nouveau/trunk/xorg-server-21.1.diff
2021-11-10 09:42:33 <mps> yes, this fixes build
2021-11-10 09:43:50 <mps> so maybe we could find fixes for few others, and we could remove really outdated ones from repo
2021-11-10 09:44:19 <Gaming4LifeDE> mps is this about the issue i linked or something else? I'm getting a bit confused
2021-11-10 09:45:00 <ikke> Gaming4LifeDE: this is something separate
2021-11-10 09:45:06 <mps> tbh, for me all this is not much important but I think it would be nice to ship new xorg with alpine 3.15 release (for users)
2021-11-10 09:45:06 <ikke> he's looking at upgrading xorg-server
2021-11-10 09:45:12 <Gaming4LifeDE> ikke oh ok
2021-11-10 09:45:36 <mps> Gaming4LifeDE: no, it is about upgrading xserver and drivers
2021-11-10 09:46:41 <Gaming4LifeDE> mps is the proprietary nvidia driver available in the repo btw? I haven't seen it. And then of course the next question would be if it could even work because of this whol glibc <-> musl libc thing
2021-11-10 09:47:00 <mps> Gaming4LifeDE: no
2021-11-10 09:47:07 <Gaming4LifeDE> thought so
2021-11-10 09:47:32 <mps> ncopa: looks like arch linux have most of patches needed for xf86 modules
2021-11-10 09:50:11 <mps> ncopa: https://archlinux.org/packages/?sort=&q=xf86-video&maintainer=&flagged=
2021-11-10 09:50:35 <mps> list of fixed xf86 video modules in arch linux
2021-11-10 09:51:01 <mps> if we have one week of time I can try to fix these
2021-11-10 09:51:13 <ncopa> 👍
2021-11-10 09:52:39 <ikke> !27312
2021-11-10 09:52:49 <maxice8> Ikke HRio: set it to merge when CI passes, it might not pass if someone else merges anything to 3.14-stable so might be good to check in 20 or so minutes if nothing comes out of it
2021-11-10 09:53:03 <ikke> maxice8: I'll keep an eye on it
2021-11-10 09:53:11 <maxice8> ty
2021-11-10 09:53:11 <ikke> should not be much pushing to 3.14 going on
2021-11-10 09:55:38 <ncopa> ikke: re release notes. Did you create an MR? or only the wiki page
2021-11-10 09:58:44 <ikke> ncopa: not an MR yet, I can start working on that
2021-11-10 10:05:31 <ddevault> why do we set -fomit-frame-pointer?
2021-11-10 10:18:59 <ikke> maxice8: it failed :(
2021-11-10 10:34:16 <ddevault> life used to be simple until fucking GNU got involved
2021-11-10 10:40:22 <maxice8> Ikke: such is life
2021-11-10 10:40:39 <ikke> Only on aarch64 this time
2021-11-10 10:41:30 <psykose> according to the manpage -fomit-frame-pointer is set for any -O level
2021-11-10 10:42:00 <maxice8> Ikke: disabled the tests for it
2021-11-10 10:42:50 <ddevault> yeah, I retract the question
2021-11-10 10:43:03 <ddevault> the answer is that it's implemented widely enough to force me down the miserable path of eh_frame
2021-11-10 11:17:15 <donoban> mps: (I didn't read whole discussion) but I think that !12413 is fixed by last gdm update
2021-11-10 11:17:25 <donoban> ouch, #12413
2021-11-10 11:22:49 <mps> donoban: sorry don't understand. what change?
2021-11-10 11:25:41 <donoban> uhM, I'm not sure what MR fixed it and maybe I didn't test properly rootless/suid modes
2021-11-10 11:26:00 <donoban> Newbyte: are you there?
2021-11-10 11:26:25 <Newbyte> donoban: yes hello
2021-11-10 11:26:42 <Newbyte> what's the question? 
2021-11-10 11:26:47 <donoban> hi, do you think #12413 is already fixed?
2021-11-10 11:26:53 <Newbyte> No idea
2021-11-10 11:27:01 <Newbyte> I just set it to use "rootful" X.org
2021-11-10 11:27:05 <Newbyte> when I tested it
2021-11-10 11:28:11 <donoban> I will check later on my other laptop
2021-11-10 11:28:18 <Newbyte> Sure
2021-11-10 11:28:27 <donoban> sorry for the confusion :\
2021-11-10 11:30:32 <Newbyte> What confusion?
2021-11-10 11:31:09 <donoban> that it was already fixed by last upgrade
2021-11-10 11:31:19 <mps> Newbyte: how do you start gdm? as user or as root
2021-11-10 11:31:38 <Newbyte> rc-service gdm start
2021-11-10 11:32:04 <donoban> maybe it runs as gdm user
2021-11-10 11:32:14 <mps> aha, so what you mean then 'rootless xorg'
2021-11-10 11:33:38 <Newbyte> gdm tries to drop privileges of the X server if it can do so
2021-11-10 11:33:49 <Newbyte> from what I understand
2021-11-10 11:33:58 <Newbyte> but with this enabled, gdm doesn't start properly in X11 mode
2021-11-10 11:34:34 <mps> how can it drop privilege? it needs some user to run it
2021-11-10 11:35:12 <mps> run X as some system user?
2021-11-10 11:41:07 <Newbyte> From what I understand logind (or elogind in Alpine's case) provides something that makes this possible, but I don't know how it works exactly.
2021-11-10 11:41:28 <Newbyte> btw could we merge !26193 before Alpine 3.15?
2021-11-10 11:41:33 <Newbyte> so GNOME actually will be installable 
2021-11-10 11:41:34 <donoban>  5483 gdm       0:00 /usr/bin/Xwayland :1024 -rootless -noreset -accessx -core -auth /run/user/115/.mutter-Xwaylandauth.9BGLC1 -listen 4 -listen 5 -displayfd 6 -initfd 7
2021-11-10 11:41:39 <donoban> it runs as gdm user
2021-11-10 11:41:54 <Newbyte> That's XWayland, not regular X
2021-11-10 11:42:00 <donoban> ah
2021-11-10 11:42:28 <donoban> how can I switch it?
2021-11-10 11:43:03 <donoban> uhMWaylandEnable=true
2021-11-10 11:43:04 <Newbyte> Not sure. gdm defaults to Wayland nowadays 
2021-11-10 11:43:13 <Newbyte> That sounds good
2021-11-10 11:43:36 <donoban> it failed to start without wayland
2021-11-10 11:43:47 <Newbyte> Did you do the rootless X.Org workaround?
2021-11-10 11:43:56 <Newbyte> Like, make it run with root
2021-11-10 11:44:09 <donoban> do it suid?
2021-11-10 11:46:00 <Newbyte> donoban: No, add needs_root_rights=yes to /etc/X11/Xwrapper.config
2021-11-10 11:46:08 <Newbyte> Create the file if it doesn't exist
2021-11-10 11:46:32 <donoban> yeah it works now
2021-11-10 11:46:40 <donoban> running as root obv
2021-11-10 11:49:06 <donoban> with rootless it returns to:  xf86OpenConsole: Cannot open virtual console 1 (Permission denied)
2021-11-10 12:02:47 <donoban> uhM
2021-11-10 12:03:16 <donoban> https://wiki.ubuntu.com/X/Rootless -> Non-root access to certain device files
2021-11-10 12:03:19 <donoban> tty/VT probing and ownership
2021-11-10 12:03:35 <donoban> maybe it needs to chown gdm some tty before running it
2021-11-10 12:10:25 <Gaming4LifeDE> I really hope this will be included in the package. Maybe reopen #12413 to address this
2021-11-10 12:27:18 <donoban>  6614 gdm       0:00 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/115/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 7 -core
2021-11-10 12:27:49 <donoban> it starts after 'chown gdm /dev/tty1'
2021-11-10 12:35:31 <donoban> [ 3530.367381] gdm[7078]: segfault at 0 ip 00005575e4ea3e4e sp 00007fffc49a1280 error 4 in gdm[5575e4e89000+32000]
2021-11-10 12:35:37 <donoban> no good 
2021-11-10 13:04:50 <mps> what is this xf86-video-xgixp? first time see it and in aports
2021-11-10 13:04:59 <mps> what is use case for it?
2021-11-10 13:05:15 <ikke> https://www.x.org/releases/X11R7.6/doc/man/man4/xgixp.4.xhtml
2021-11-10 13:05:24 <ikke> xgixp is an Xorg driver for XGI XP video cards.
2021-11-10 13:06:28 <mps> The xgixp driver supports PCI, AGP, and PCIE video cards based on the following XGI chips: Volari 8300
2021-11-10 13:06:43 <mps> do we need to keep it?
2021-11-10 13:06:44 <Gaming4LifeDE> sounds very old
2021-11-10 13:07:13 <ikke> "The Volari 8300 was a graphics card by XGI, launched on November 1st, 2005."
2021-11-10 13:07:38 <mps> ncopa: ^^
2021-11-10 13:08:25 <mps> also s3 and ati, not sure they are used in last 10 years
2021-11-10 13:09:15 <Gaming4LifeDE> mps ati=radeon?
2021-11-10 13:09:23 <Gaming4LifeDE> the old radeons?
2021-11-10 13:10:06 <mps> yes, I know, I had one long ago
2021-11-10 13:11:04 <mps> also xf86-video-glint, GLINT/Permedia video driver
2021-11-10 13:11:35 <psykose> anything older than hd7750 needs ati
2021-11-10 13:12:24 <Gaming4LifeDE> then i'd still have a gpu using it. I'm actually using it for debugging if i have a server without integrated gfx
2021-11-10 13:13:00 <mps> ok, ati could be fixed
2021-11-10 13:13:07 <psykose> or maybe i am confusing xf86-ati with the kernel ati/amdgpu
2021-11-10 13:13:15 <psykose> not sure if they have a different matrix of support
2021-11-10 13:14:13 <mps> kernel have drm drivers which xorg can use with modesetting driver
2021-11-10 13:15:31 <psykose> ah, yep, makes sense
2021-11-10 13:15:42 <Gaming4LifeDE> mps i'm pretty sure glint isn't worth it. I scanned the wikipedia article: their latest graphics card used directx 9.0c (=windows xp) and they're now part of creative (for those who don't immediately know, the guys with the soundblaster cards)
2021-11-10 13:15:47 <mps> these xf86-video-* are for unsupported by kernel
2021-11-10 13:15:51 <psykose> so anything older than 7750 won't be able to use kernel amdgpu
2021-11-10 13:15:51 <psykose> yep
2021-11-10 13:15:58 <psykose> i forgot how the xfvideo worked
2021-11-10 13:16:52 <mps> unsupported by kernel drm driver, I mean
2021-11-10 13:17:26 <mps> maybe simpledrm could 'retire' all of them :)
2021-11-10 13:19:07 <mps> I don't have (yet) fixes for glint, sunleo, xgixp
2021-11-10 13:19:15 <psykose> xgixp, rendition, tdfx, sunleo seem to be of the same fate
2021-11-10 13:19:28 <psykose> i wonder if anyone has these installed
2021-11-10 13:21:19 <mps> if I'm maintainer I would move them in testing
2021-11-10 13:21:36 <ikke> I don't think we want more packages in testing
2021-11-10 13:26:33 <ncopa> i think modesetting is supposed to retire most of them. including xf86-video-intel
2021-11-10 13:27:19 <psykose> the question is what things are unsupported by modesetting and if they are still in use by anyone and if there is a wish for support
2021-11-10 13:27:32 <psykose> i don't use xf86-video-intel as i don't need it, but maybe somebody does
2021-11-10 13:29:10 <mps> yes, I don't have xf86-video-intel on macbook from 2009 year, modesetting works
2021-11-10 13:30:31 <psykose> from the looks of it 99% of people are using modesetting, and all those xf86 modules are for things from 2001 aside
2021-11-10 13:30:54 <mps> found patch on upstream site for ati https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/merge_requests/8/diffs
2021-11-10 13:31:02 <mps> hope it will fix ati
2021-11-10 13:31:15 <ncopa> good
2021-11-10 13:31:24 <psykose> it was merged 7 months ago, isn't it part of release
2021-11-10 13:31:33 <psykose> 6*
2021-11-10 13:31:40 <mps> but glint, sunleo, xgixp and s3 looks like they are 'doomed'
2021-11-10 13:31:49 <ncopa> yes, I have backported patches on xorg server upgrade in the past
2021-11-10 13:32:20 <psykose> ah, no tag for 2 years
2021-11-10 13:32:24 <mps> psykose: no, ati last release is old, xf86-video-ati-19.1.0.tar.gz                2019-10-15 16:18
2021-11-10 13:32:28 <psykose> yep
2021-11-10 13:32:57 <mps> ncopa: I see only gcc patch
2021-11-10 13:35:05 <mps> uh, how GL is unintuitive, how to download patch from MR
2021-11-10 13:35:20 <ikke> add .patch to the url MR url
2021-11-10 13:35:49 <ncopa> fedora also have patches: https://src.fedoraproject.org/rpms/xorg-x11-drv-ati/tree/rawhide
2021-11-10 13:36:07 <Hello71> psykose: the man page is wrong
2021-11-10 13:36:14 <ikke> mps: for example https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27315.patch
2021-11-10 13:36:25 <mps> arch linux use git for ati
2021-11-10 13:36:37 <ncopa> glint was dropped by fedora 7 years ago https://src.fedoraproject.org/rpms/xorg-x11-drv-glint/commits/rawhide
2021-11-10 13:36:44 <ncopa> just remove it
2021-11-10 13:37:11 <mps> ok
2021-11-10 13:37:28 <ncopa> https://lists.fedoraproject.org/pipermail/devel/2013-August/188429.html
2021-11-10 13:37:56 <Hello71> ddevault: why can't you use elfutils/libunwind/llvm-libunwind? not everything has .eh_frame; musl for example specifically sets -fno-unwind-tables -fno-asynchronous-unwind-tables
2021-11-10 13:38:15 <ddevault> because
2021-11-10 13:38:44 <ddevault> how does libunwind even work in the absence of .eh_frame or frame pointers
2021-11-10 13:38:47 <psykose> Hello71: i tested gcc -Q -v and -fomit-frame-pointer is passed for any -O
2021-11-10 13:38:53 <ncopa> mps: fedora retired sunleo 8 years ago https://src.fedoraproject.org/rpms/xorg-x11-drv-sunleo/commits/rawhide   you can delete it
2021-11-10 13:39:26 <Hello71> psykose: it is correct for all archs except aarch64 and some minor arch
2021-11-10 13:39:37 <alandiwix> skarnet:  I'm wondering why do we have -O2 as mdevd argument in the mdev-openrc script?
2021-11-10 13:39:40 <mps> ncopa: ok
2021-11-10 13:39:44 <Hello71> ddevault: .debug_frame
2021-11-10 13:39:46 <psykose> as the manpage says then, that some arches ignore the option for various reasons
2021-11-10 13:39:58 <psykose> if it's supported it is passed
2021-11-10 13:40:02 <Hello71> psykose: aarch64 doesn't ignore it. it is supported, just not added by -O
2021-11-10 13:40:04 <ddevault> which works until you strip the binary
2021-11-10 13:40:06 <ncopa> ddevault: you might be interested in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22958
2021-11-10 13:40:29 <Hello71> ddevault: yes, so it looks for splitdebug, and if you deleted that too then you're SOL
2021-11-10 13:40:35 <ddevault> ncopa: that's nice to see
2021-11-10 13:41:01 <Hello71> (well i guess you can walk the stack anyways and look at the mapped filenames but that's rarely that useful)
2021-11-10 13:41:07 <ddevault> bloody stupid that we've (we as in the industry) given the finger to simple debugging tools simply to save a couple kilobytes or a handful of nanoseconds
2021-11-10 13:41:11 <mps> I think it would be best to build xf86-video-ati from current upstream git
2021-11-10 13:41:21 <psykose> Hello71: ah, i see, any reason why the option default changes then?
2021-11-10 13:41:35 <ddevault> Hello71: you can walk the stack, but not the stack frames
2021-11-10 13:41:44 <Hello71> psykose: https://github.com/gcc-mirror/gcc/commit/af3b4514fcb92b6275ed52e47bb0dd8146f7e304
2021-11-10 13:41:50 <ddevault> there's no way to tell which stack entries are return addresses and which are locals or something else
2021-11-10 13:42:14 <Hello71> yes
2021-11-10 13:42:33 <Hello71> gdb tries to guess and ime rarely succeeds
2021-11-10 13:43:16 <ikke> zfs-rpi fails on aarch64 due to incompattible kernel versions
2021-11-10 13:43:22 <ddevault> we'll happily give away millions of bytes and cycles to abstraction after abstraction but one puny register and one little stack slot is too much to ask
2021-11-10 13:44:28 <ncopa> i think keeping eh_frame on all arches makes sense. but we kinda wanted the blessing from upstream
2021-11-10 13:44:28 <Hello71> there is a vague idea floating around for "thin splitdebug" which only contains stack frame info like .eh_frame but isn't loaded into ram
2021-11-10 13:44:48 <Hello71> imo that is best solution but of course somebody has to actually implement it
2021-11-10 13:44:50 <ncopa> ikke: I'll fix zfs-rpi
2021-11-10 13:45:09 <ddevault> I think alpine should have eh_frames. it does not do much for my particular problem, though
2021-11-10 13:45:11 <ddevault> 
ACTION shrugs

2021-11-10 13:45:34 <skarnet> alandiwix: to piggyback events into a netlink group, for use by libudev-zero
2021-11-10 13:46:05 <psykose> ncopa: i think something regressed in new mkinitfs, there is +6s (0.7 -> 6.7) before root mounts every boot
2021-11-10 13:46:08 <psykose> afaik nothing else changed
2021-11-10 13:47:44 <ncopa> psykose: does not surprise me. the code is a mess
2021-11-10 13:48:07 <ncopa> what do you have your rootfs on?
2021-11-10 13:48:12 <alandiwix> skarnet: I'm really not knowledgeable about netlink groups, but illiliti suggests -O4 in the example
2021-11-10 13:48:13 <ncopa> lvm2?
2021-11-10 13:48:16 <ncopa> zfs?
2021-11-10 13:48:21 <alandiwix> is it the same?
2021-11-10 13:49:05 <ikke> ncopa: not sure if psykose was referring to that, but helby mentioned it as well
2021-11-10 13:49:28 <psykose> i added 3.5.0-r0 from v3.14 and it fixed itself
2021-11-10 13:49:30 <psykose> rootfs is xfs
2021-11-10 13:49:35 <psykose> on nothing
2021-11-10 13:49:49 <psykose> just simple install on disk
2021-11-10 13:50:46 <skarnet> alandiwix: well currently I'm not sure the mdevd + libudev-zero integration is fully operational in Alpine, I'm not sure what nlgroup Alpine's libudev-zero listens to, etc. Some time early next year I'll be able to make sure it works; I think replacing mdev with mdevd needs more openrc script changes, for instance
2021-11-10 13:51:11 <skarnet> at that point we'll make sure that mdevd's -O option corresponds to the nlgroup libudev-zero listens to
2021-11-10 13:51:14 <Gaming4LifeDE> If we can get gnome-desktop to work correctly, I think the wiki page needs to be reworked. I do have a few issues with gnome which need to be ironed out first
2021-11-10 13:51:53 <Gaming4LifeDE> for example gnome-control-center segfaulting when i try creating a new user and trying to type or paste into the Full Name field
2021-11-10 13:52:26 <Gaming4LifeDE> I really don't know how to debug stuff like this though, i'd be happy to help if i can get some guidance there
2021-11-10 13:54:06 <alandiwix> skarnet: I'm using it with -O4 (never tried with -O2) and it's amazing experience already. Thank you and illiliti for that.
2021-11-10 13:54:38 <skarnet> well if it's working for you today with -O4 then we should definitely change the script to -O4
2021-11-10 13:55:50 <alandiwix> would you kindly do it ir should I provide a PR?
2021-11-10 13:56:10 <alandiwix> it's actually just 1 digit diff
2021-11-10 13:56:33 <skarnet> hold on
2021-11-10 13:57:38 <skarnet> it's in mdevd-openrc right?
2021-11-10 13:58:15 <skarnet> /etc/init.d/mdevd?
2021-11-10 13:58:26 <skarnet> if that's the one, I'll do it ;)
2021-11-10 13:58:28 <alandiwix> yes
2021-11-10 13:58:34 <skarnet> ok
2021-11-10 13:58:54 <skarnet> still in testing, early next year I'll make sure it's integrated in main
2021-11-10 13:59:04 <ncopa> fabled: looks like the patch we have for lua-ldbus was never upstreamed? it no longer applies on current ldbus git master
2021-11-10 13:59:56 <alandiwix> skarnet: sounds great
2021-11-10 14:00:22 <alandiwix> can't wait for alpine s6 migration :)
2021-11-10 14:00:41 <skarnet> yeah, that one will have to wait for a little more ^^'
2021-11-10 14:02:49 <alandiwix> yea, I know:) thank you for your work, it's awesome
2021-11-10 14:02:57 <skarnet> thanks!
2021-11-10 14:07:07 <skarnet> !27319, whenever someone can :)
2021-11-10 14:12:57 <fabled> ncopa: seems so.
2021-11-10 14:13:49 <maxice8> skarnet: merged, bumped pkgrel and regenerated checksum
2021-11-10 14:14:16 <skarnet> maxice8: whoops, forgot to bump pkgrel, sorry about that, and thanks
2021-11-10 14:14:26 <maxice8> nw
2021-11-10 14:14:50 <fabled> ncopa: it's old stuff from 2015. i don't even writing the patch... :-o
2021-11-10 14:24:33 <ncopa> psykose: I can reproduce. can you please create an issue? add details about root filesystem
2021-11-10 14:24:54 <psykose> ncopa: do you want a dmesg of both boots?
2021-11-10 14:25:02 <ncopa> would be usefule yes
2021-11-10 14:25:07 <psykose> sure thing, give me a moment
2021-11-10 14:27:50 <ncopa> also include what you have in /etc/mkinitfs/mkinitfs.conf
2021-11-10 14:33:56 <psykose> ncopa: #13178
2021-11-10 14:34:22 <ncopa> psykose: thank you!
2021-11-10 14:35:05 <Gaming4LifeDE> psykose is that the reason why alpine takes so long to boot (considering its size)?
2021-11-10 14:35:17 <psykose> this is only since yesterday, and only on edge
2021-11-10 14:35:44 <psykose> aside from that i boot from power press to grub/alpine boot in maybe 8 seconds (all efi time, unrelated) and the into openrc in less than a second
2021-11-10 14:36:02 <psykose> until this, of course, added a good few more seconds :)
2021-11-10 14:36:03 <Gaming4LifeDE> ohh ok. i still think it's weird that distros like solus boot faster than alpine, even with solus booting to graphical instead of text only
2021-11-10 14:36:31 <psykose> you probably want to configure some settings
2021-11-10 14:37:01 <psykose> the actual alpine boot part is near-instant, but i can't look at what your hardware is doing sadly
2021-11-10 14:37:08 <Gaming4LifeDE> weird. even with alpine 3.13/14 it still takes a good 3-4 seconds until openrc does anything (or at least prints anything to screen)
2021-11-10 14:37:41 <Gaming4LifeDE> tested it in a proxmox vm, so qemu/kvm with uefi
2021-11-10 14:42:35 <Saijin_Naib[m]> Gaming4LifeDE: Linux Kernel 5.11 and above here boot incredibly much faster than 5.10 does on the same hardware.
2021-11-10 14:42:56 <Saijin_Naib[m]> I can barely even read the OpenRC prints before I'm at lightdm
2021-11-10 14:44:33 <Gaming4LifeDE> Saijin_Naib[m] yeah no, not for me at least. On edge, mounting the fs takes a good 5s but we already talked about this
2021-11-10 14:45:45 <Gaming4LifeDE> mounting is done at 6.67 seconds and the system seems to be done booting at 10.68
2021-11-10 14:45:53 <Gaming4LifeDE> (without gdm though)
2021-11-10 14:46:10 <Ariadne> hi
2021-11-10 14:46:29 <Ariadne> Gaming4LifeDE: perhaps #alpine-linux is a better venue for this conversation
2021-11-10 14:46:58 <Gaming4LifeDE> Ariadne i'm in both channels, i'm just answering where i'm being asked
2021-11-10 14:47:31 <Ariadne> alright, well, i think it would be best to move the conversation there, as we are trying to coordinate getting a release out the door.
2021-11-10 14:48:41 <Gaming4LifeDE> I do hope at least #12413 will be fixed in the new release though :D  (setting suid seems to be everything you need to do for a fix)
2021-11-10 14:50:28 <mps> Gaming4LifeDE: use slim DM, you will not have these problems
2021-11-10 14:50:45 <Ariadne> Gaming4LifeDE: i have marked it as a blocker for 3.15
2021-11-10 14:51:02 <Gaming4LifeDE> mpa i got it fixed by setting suid on /usr/bin/X but it would be nice to have it done in the package already
2021-11-10 14:51:08 <Gaming4LifeDE> Thanks Ariadne
2021-11-10 14:51:15 <Ariadne> setting /usr/bin/X as suid is not the correct fix
2021-11-10 14:51:34 <mps> X don't need to be suid by default
2021-11-10 14:51:58 <Ariadne> the correct fix, most likely, is to have gdm do something with elogind prior to starting X
2021-11-10 14:52:16 <Ariadne> so that the permissions are properly set up
2021-11-10 14:53:48 <Ariadne> running X as root is fundamentally a bad idea
2021-11-10 14:54:26 <Newbyte> s/as root //
2021-11-10 14:57:06 <Gaming4LifeDE> Newbyte i don't think the free software world is quite ready to finally kick X out for good... although.... I wonder if it's possible to use gdm and gnome without installing x directly (xwayland only)
2021-11-10 14:57:23 <mps> anyone could tell me how to use https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/commits/master with latest commit as source to download tarball
2021-11-10 14:57:39 <Newbyte> they both default to Wayland
2021-11-10 14:58:39 <psykose> mps: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/archive/5eba006e4129e8015b822f9e1d2f1e613e252cda/xf86-video-ati-5eba006e4129e8015b822f9e1d2f1e613e252cda.tar.gz
2021-11-10 14:58:46 <Gaming4LifeDE> mps hit "browse files" (the folder icon) and then get the download link like you would from master
2021-11-10 14:59:24 <Gaming4LifeDE> Newbyte default to, yes. but i mean just not installing x in the first place. you'd probably need to patch a lot of apkbuilds to rip the dependencies out though
2021-11-10 14:59:34 <psykose> the archive/commit/xf86 part can have commit replaced by master to make it shorter it seems
2021-11-10 15:02:31 <ncopa> psykose: i found the issue. its a regression. i'll push a fix
2021-11-10 15:02:36 <mps> psykose: thanks
2021-11-10 15:02:51 <psykose> ncopa: thank you!
2021-11-10 15:03:13 <ncopa> psykose: good catch! I didnt notice the 5 seconds extra delay
2021-11-10 15:03:39 <psykose> i didn't think much of it until someone else pointed it out in #alpine-linux, then i went to check :p
2021-11-10 15:03:44 <mps> Gaming4LifeDE: no, this will not work, we need commit id
2021-11-10 15:03:59 <Gaming4LifeDE> mps it has the commit id as the branch
2021-11-10 15:04:41 <Gaming4LifeDE> Uploaded file: https://uploads.kiwiirc.com/files/53c6e46480b48bac135702443ff9b0a5/Screenshot%202021-11-10%20160423.png
2021-11-10 15:05:09 <Gaming4LifeDE> The archive has the commit id too
2021-11-10 15:07:34 <mps> Gaming4LifeDE: ah, I see
2021-11-10 15:12:32 <ncopa> ugh, ceph pushed again. lets hope we dont run out of diskspace again
2021-11-10 15:13:06 <psykose> should check preemptively
2021-11-10 15:18:06 <Ariadne> the people who push don't necessarily have that knowledge :p
2021-11-10 15:20:59 <ncopa> i think i need to set up a vm on my M1 macbook. my aarch64 dev env is slow today
2021-11-10 15:21:51 <mps> ncopa: I did right this yesterday :)
2021-11-10 15:23:20 <mps> building current qemu git took 2-3 minutes
2021-11-10 15:24:29 <mps> latest qemu git have HVF finally
2021-11-10 15:40:57 <tomalok> curious if CONFIG_GPIO_PL061=y has managed to get into config-virt.aarch64 of linux-lts / linux edge?  without it AWS can't tell an arm64 instance to reboot/shutdown nicely.  i can open a more formal issue if necessary...
2021-11-10 15:41:27 <ikke> tomalok: please do
2021-11-10 15:41:42 <ikke> ncopa looks at these issues when he is working on the kernels
2021-11-10 15:42:26 <tomalok> any particular tags or whatnot i should put on the issue?
2021-11-10 15:42:32 <ikke> category:kernel
2021-11-10 15:42:34 <mps> tomalok: I'm waiting 5.15.2 to add it to linux-edge aarch64
2021-11-10 15:47:15 <tomalok> officially an issue #13180 (linked back to our original alpine-ec2-ami issue)
2021-11-10 15:54:27 <Ariadne> mps: i just use UTM for that
2021-11-10 15:58:50 <mps> Ariadne: is it better
2021-11-10 15:59:00 <Ariadne> yes, UTM is quite nice
2021-11-10 15:59:14 <Ariadne> the author is also a contributor to libucontext :P
2021-11-10 15:59:45 <mps> hmm, and libucontext author is Ariadne ?
2021-11-10 16:01:51 <Ariadne> i mean, yes, but the author of UTM is not me, they just sent in patches to make it portable outside of Linux
2021-11-10 16:02:28 <mps> for me qemu is temporary till I make natively running linux/alpine on it
2021-11-10 16:03:50 <mps> and I will not hurry because of my $day_job, and trying to fix some pkg before 3.15 release
2021-11-10 16:56:03 <Hello71> tomalok: have you tested it yet
2021-11-10 17:43:08 <mps> ncopa: https://src.fedoraproject.org/rpms/xorg-x11-drv-s3/blob/rawhide/f/dead.package
2021-11-10 17:46:10 <mps> ncopa: and I can't find xf86-video-xgixp in any popular distro
2021-11-10 18:22:55 <ncopa> mps: i think we can just delete it
2021-11-10 18:23:33 <mps> ncopa: them, there are two, s3 and xgixp?
2021-11-10 18:24:30 <mps> looking at arch linux here https://archlinux.org/packages/?sort=&q=xf86-video&maintainer=&flagged= they have a lot less of these drivers
2021-11-10 18:25:16 <mps> we still can have s3virge
2021-11-10 18:28:29 <ncopa> mps: delete them both. no point build drivers that nobody uses and that does not work
2021-11-10 18:28:52 <mps> ok
2021-11-10 19:01:06 <anjan> hey PureTryOut sxmo is looking to get this patch merged https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27205#note_190699
2021-11-10 19:01:36 <anjan> Both staceee and I agree with your conclusion and we were wondering what's left to do to that MR to get it merged?
2021-11-10 19:09:08 <PureTryOut> I would love a response from ncopa there really
2021-11-10 19:09:18 <Hello71> yes, delete it. if anyone is using something that old they can live without hwaccel
2021-11-10 19:09:44 <ikke> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/33
2021-11-10 19:21:42 <ncopa> PureTryOut: I responded
2021-11-10 19:21:47 <ncopa> ikke: nice!
2021-11-10 19:29:16 <ncopa> mps: I'm testing lima to run alpine. Its a qemu manager for mac. They have preconfigured alpine images. Works pretty decent!
2021-11-10 19:30:20 <mps> ncopa: lima? do you have url?
2021-11-10 19:30:32 <mps> ah, gui? :)
2021-11-10 19:30:57 <ncopa> no gui.
2021-11-10 19:31:11 <ncopa> https://github.com/lima-vm/lima
2021-11-10 19:31:18 <ncopa> brew install lima
2021-11-10 19:31:22 <mps> I moved my elm chromebook FS to qemu img and run it from cli
2021-11-10 19:31:49 <ncopa> cool
2021-11-10 19:32:41 <mps> do they have bridge mode net setup, this is what I need to find how to make it
2021-11-10 19:33:49 <ncopa> i think they do
2021-11-10 19:34:11 <mps> at first look I thought it something about lima gpu
2021-11-10 19:34:48 <mps> I will look at it, maybe it could be usable to me also
2021-11-10 19:36:33 <mps> ah, 'Managed VMNet networks (via vde_vmnet)', interesting to look
2021-11-10 19:37:19 <mps> ncopa: btw, xorg is finished on CI, there are left 3 pkgs in testing but this can be done later
2021-11-10 19:52:13 <PureTryOut> anjan: merged!
2021-11-10 19:52:46 <anjan> thank you PureTryOut. We want to get 1.6.0 (sxmo with wayland support) out before pmos stable hehe
2021-11-10 19:52:59 <PureTryOut> Lol before Alpine 3.15 then
2021-11-10 19:53:01 <PureTryOut> Better be quick
2021-11-10 20:03:24 <omni> I boot a system from a USB device, since recently, on edge, I have to remove and insert it on reboot for the machine to find it as a bootable device
2021-11-10 20:03:42 <omni> I've tried with a USB stick, different brand and model, same issue
2021-11-10 20:04:41 <psykose> this sounds like a machine/efi/whatever issue to me
2021-11-10 20:04:47 <psykose> unless it doesn't happen under 3.14 or something
2021-11-10 20:06:37 <Newbyte> Hi, could we merge !26193 before Alpine 3.15?
2021-11-10 20:07:02 <Newbyte> It just removes two dependencies and bumps the version of the package
2021-11-10 20:15:16 <nmeum> Newbyte: yes, we need to address this anyhow to fix the gnome-apps-extra dependency error from #13173
2021-11-10 21:52:36 <ikke> Fun, sourceforge https certificate has expired for 1.5 months
2021-11-10 21:53:11 <Gaming4LifeDE> wonderful. never had a particular liking for sourceforge. always a bit too overloaded and complicated
2021-11-10 22:01:30 <Hello71> ikke: fine here.
2021-11-10 22:01:52 <ikke> Hello71: strange. Both the s390x builder as my local machine seem to get the wrong certificate
2021-11-10 22:02:29 <Hello71> sourceforge downloads are hosted from mirrors
2021-11-10 22:02:55 <ikke> But this is the main domain
2021-11-10 22:03:36 <Hello71> i think it does a redirect to *.dl.sourceforge.net
2021-11-10 22:05:30 <ikke> Hello71: seems to be fixed now
2021-11-10 22:05:46 <ikke> I now get a 404
2021-11-10 22:06:11 <Hello71> sounds like a bad mirror
2021-11-10 22:06:16 <donoban> lol, I just entered in #gdm on gnome irc and this their topic: Topic for #gdm is "mixtou: needs_roots_rights=yes in /etc/X11/Xwrapper.config"
2021-11-10 22:08:30 <Gaming4LifeDE> donoban lol wtf
2021-11-10 22:09:10 <donoban> I suppose that they don't expect to rootless work properly
2021-11-10 22:09:21 <Gaming4LifeDE> that's how you know you've written a very bad piece of software when you actually need to put disclaimers like this in their topic
2021-11-10 22:09:38 <Gaming4LifeDE> basically yeah. i wonder if it'll work in alpine soon
2021-11-10 22:14:28 <donoban> I passed a log to them, let's continue tomorrow, good night
2021-11-10 22:14:43 <Gaming4LifeDE> good night
2021-11-10 23:26:43 <omni> psykose: I'm not so sure, I managed to rollback to a snapshot round linux-lts-5.15.0 and the issue was consistently gone, then upgraded all packages again and it's consistently there
2021-11-10 23:27:06 <omni> not sure it's related to 5.15.1 though
2021-11-10 23:28:36 <omni> another issue that has surfaced; I rely on zfs snapshot devices and all of them don't seem to reliably appear
2021-11-10 23:31:24 <omni> since 5.15.0 I think, but I'm not sure since on some boots they're all there and some one or two is missing
2021-11-10 23:32:41 <omni> zvol snapshot devices
2021-11-10 23:33:22 <omni> could be this https://github.com/openzfs/zfs/issues/12712
2021-11-10 23:34:08 <omni> but it's not the entire zvol, just one or two snapshots on a semingly random zvol
2021-11-10 23:37:23 <omni> this rather https://github.com/openzfs/zfs/issues/12507 but I began experiencing it just a few days ago
2021-11-10 23:44:19 <omni> perhaps solved by https://github.com/openzfs/zfs/commit/65d56083b4617a4cade0cff68cbbaf68114169d6
2021-11-10 23:47:11 <omni> uh, wrong paste, this https://github.com/openzfs/zfs/commit/371e0f7754746f2b2574006ec5dd58059cf165cd
2021-11-10 23:48:07 <omni> and I'm too tired for this, sry
2021-11-11 07:44:14 <mps> good morning
2021-11-11 07:44:56 <mps> ncopa: did you looked at final !27236, could we merge it
2021-11-11 07:55:11 <PureTryOut> What is remaining to be done for Alpine 3.15?
2021-11-11 07:59:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/milestones/177
2021-11-11 07:59:39 <mps> PureTryOut: maybe these https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?milestone_title=3.15.0
2021-11-11 08:00:25 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13173
2021-11-11 08:01:15 <mps> #13173
2021-11-11 08:03:53 <mps> I'm waiting ncopa to merge xorg-server and want after that to add rootless server patch and test it, if it work fine maybe merge to aports
2021-11-11 08:05:31 <mps> and I'm right now testing just released crystal lang 1.2.2
2021-11-11 08:05:33 <indy> hi all, is planned to put 1.34 busybox to all affected alpine branches? https://sensorstechforum.com/cve-2021-42373-linux-busybox/
2021-11-11 08:09:03 <PureTryOut> Oh that is quite a lot still
2021-11-11 08:09:45 <ikke> PureTryOut: not all are blockers for 3.15
2021-11-11 08:09:56 <ikke> It helps to go over the list and see what is really blocking things
2021-11-11 08:10:07 <PureTryOut> Shouldn't the ones that aren't not be removed from that milestone then?
2021-11-11 08:10:18 <ikke> yes
2021-11-11 08:10:32 <PureTryOut> for example https://gitlab.alpinelinux.org/alpine/aports/-/issues/625 could probably be removed from it
2021-11-11 08:10:44 <ikke> Some issues are perpatually postponed, I tend to just remove the milestone then
2021-11-11 08:15:31 <PureTryOut> Is there a 3.16 milestone we can move things too?
2021-11-11 08:15:54 <ikke> yes
2021-11-11 08:16:06 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/milestones/183
2021-11-11 08:16:21 <ikke> Also https://gitlab.alpinelinux.org/alpine/aports/-/milestones/184
2021-11-11 08:16:22 <ikke> 3.15.1
2021-11-11 08:17:05 <HRio> indy: does that include v3.11?
2021-11-11 08:19:22 <ikke> indy: I've seen it, but the CVE's have not been disclosed yet
2021-11-11 08:19:22 <indy> HRio, yes
2021-11-11 08:19:28 <ikke> https://nvd.nist.gov/vuln/detail/CVE-2021-42373
2021-11-11 08:19:45 <indy> https://jfrog.com/blog/unboxing-busybox-14-new-vulnerabilities-uncovered-by-claroty-and-jfrog/
2021-11-11 08:20:04 <indy> there is list of cves and applets affected
2021-11-11 08:22:25 <ikke> indy: But yes, they will probably be backported, one way or another
2021-11-11 08:37:14 <ncopa> good morning
2021-11-11 08:37:27 <ncopa> ugh.. those busybox issue will cost us some time
2021-11-11 08:38:52 <ikke> ye
2021-11-11 08:47:19 <ncopa> those never affected us https://tpaste.us/0w4N
2021-11-11 08:49:13 <ikke> ncopa: https://gitlab.alpinelinux.org/ariadne/security-rejections
2021-11-11 09:12:52 <ncopa> why not just set that version 0 "fixes" it?
2021-11-11 09:13:13 <ncopa> should make all scanners that does version compare work
2021-11-11 09:13:23 <ikke> Ariadne: ^?
2021-11-11 09:15:37 <ncopa> oh , those rejections are because the package name does not match
2021-11-11 09:15:40 <ncopa> makes sense
2021-11-11 09:16:07 <ikke> ah
2021-11-11 13:44:48 <omni> why is there no /usr/share/examples/?
2021-11-11 13:45:35 <ikke> https://pkgs.alpinelinux.org/contents?path=%2Fusr%2Fshare%2Fexamples*&page=1&arch=x86_64&branch=edge
2021-11-11 13:46:15 <psykose> most packages are not configured to install anything there
2021-11-11 14:00:20 <omni> no, sure, but some seem to be packaged to put example files under /etc/
2021-11-11 14:00:40 <omni> I assume the right place in alpine would be in the -doc package, under /usr/share/doc/ ?
2021-11-11 14:03:51 <mps> omni: +1
2021-11-11 14:12:36 <Ariadne_> heh
2021-11-11 14:12:47 <Ariadne_> hm
2021-11-11 14:37:35 <mps> any objection to merge  · created 4 days ago by Milan P. Stanić  
2021-11-11 14:37:35 <mps> aports:remove
2021-11-11 14:37:47 <mps> huh
2021-11-11 14:38:07 <mps> any objection to merge  !27236 
2021-11-11 15:05:13 <Ariadne> mps: no objection
2021-11-11 15:09:36 <mps> Ariadne: ok and thanks for answering
2021-11-11 15:18:36 <minimal> ikke: for Busybox mount, certainly with "-t auto", you need to create /etc/filesystems file and put the module name(s) in there for it to be loaded
2021-11-11 15:20:49 <ikke> minimal: then you can just as well just specify the fs directly to mount :P
2021-11-11 15:21:18 <minimal> ikke: well I found this out when packaging cloud-init as it uses "mount -t auto" :-)
2021-11-11 15:21:27 <ikke> aha
2021-11-11 16:22:24 <streampunk> I am trying to backport rust 1.53 on alpine v3.14 (rust 1.52). I get this error: "Unable to generate vergen keys!" A github issue says miri is trying to find a git repo. Has anybody encountered this?
2021-11-11 16:24:28 <streampunk> I created a git repo alongside APKBUILD with "git init"... may that helps
2021-11-11 16:29:22 <psykose> could you link the issue? i can find nothing useful at all for that error
2021-11-11 16:34:00 <ikke> https://github.com/rust-lang/rust/issues/56576
2021-11-11 16:36:55 <psykose> weird
2021-11-11 16:49:11 <streampunk> yes, thats the one. sorry I was distracted.
2021-11-11 16:53:46 <krystianch> Could we close #11366 as !26373 is merged?
2021-11-11 16:57:39 <ncopa> closed. thanks!
2021-11-11 16:58:26 <krystianch> thanks
2021-11-11 17:43:07 <omni> mps: !27367
2021-11-11 17:45:46 <ikke> Seems to be movement in making cabal build with ghc9
2021-11-11 17:56:43 <streampunk> making a git-repo with a single commit solves the rust/miri problem.
2021-11-11 17:57:37 <ikke> :/
2021-11-11 17:57:46 <ikke> broken build system
2021-11-11 18:13:53 <psykose> based on that issue it looked like it should've been fixed before 1.52, as it got closed 2.5 years before lol
2021-11-11 19:33:56 <oneinsect> :P
2021-11-11 19:34:07 <mps> omni: could we postpone this after 3.15 release
2021-11-11 19:47:25 <shafire> hi
2021-11-11 19:47:43 <donoban> I noticed this on iotop: "CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %"
2021-11-11 19:47:45 <shafire> Is there already an APKBUILD that uses docker as buildtool?
2021-11-11 19:48:51 <ncopa> ERROR: libxcvt-0.1.1-r0: trying to overwrite usr/bin/cvt owned by xorg-server-1.20.13-r0.
2021-11-11 19:49:02 <ncopa> sounds like a replaces is needed?
2021-11-11 19:50:12 <ikke> shafire: maybe someone created one, but official packages cannot use docker as a build tool
2021-11-11 19:51:19 <shafire> ikke: ok, then I will try it without docker (though the project recommends to use docker to build their executables)
2021-11-11 19:51:35 <mps> ncopa: doesn't apk do this automaticaly?
2021-11-11 19:51:37 <ikke> because they are lazy :)
2021-11-11 19:51:39 <psykose> the project is wrong :)
2021-11-11 19:52:58 <psykose> donoban: i believe that is iotop reporting what it needs wrong as it is =y
2021-11-11 19:53:12 <ncopa> mps: not if they are two different packages
2021-11-11 19:53:14 <psykose> but it needs roughly 1 or 2 more acct options, it just doesn't check correctly
2021-11-11 19:54:17 <donoban> hmm
2021-11-11 19:54:34 <donoban> does it work fine for you? are you runing linux-lts?
2021-11-11 19:54:37 <mps> ncopa: hmm, so we need to add replaces. but how? 'replaces="xorg-server"' doesn't look good
2021-11-11 19:54:52 <ikke> mps: it's a bit of a misnomer
2021-11-11 19:55:01 <ikke> it just means: allow to take over files from this package
2021-11-11 19:55:25 <ikke> mps: If you add a comment to it why, then it's less confusing
2021-11-11 19:55:42 <mps> ah, so it is ok with comment
2021-11-11 19:55:44 <mps> ?
2021-11-11 19:55:54 <ikke> yes, I would say so
2021-11-11 19:56:32 <mps> could someone do this, I'm not at home now
2021-11-11 19:56:36 <psykose> donoban: ahh, i think you need to add "delayacct" to the cmdline
2021-11-11 19:57:01 <psykose> which is weird as i don't remember needing that before many months ago
2021-11-11 19:57:42 <donoban> I don't know what you mean heh
2021-11-11 19:57:46 <mps> and I don't carry alpine access with me on moving machines
2021-11-11 19:57:56 <mps> access keys*
2021-11-11 19:58:13 <ikke> I can take a look at it in a bit
2021-11-11 19:58:35 <mps> ikke: tia
2021-11-11 19:58:42 <psykose> donoban: yep, adding delayacct to kernel cmdline fixes it
2021-11-11 19:58:44 <psykose> strange :)
2021-11-11 19:59:18 <donoban> ah, so is this an issue?
2021-11-11 19:59:29 <donoban> I suppose that iotop is pretty useful in server/cloud enviroment
2021-11-11 19:59:57 <mps> donoban: iotop or iotop-c
2021-11-11 20:00:17 <donoban> I think that just iotop
2021-11-11 20:00:30 <psykose> mps: same on both
2021-11-11 20:01:25 <xordspar0> !25372 seems ready but hasn't been reviewed. Is there any chance of getting it merged before the release?
2021-11-11 20:02:13 <ikke> Is that an LTS release?
2021-11-11 20:02:20 <psykose> donoban: try `sysctl kernel.task_delayacct=1` and see if that works by itself
2021-11-11 20:02:46 <mps> CONFIG_TASK_DELAY_ACCT=y is in linux-edge
2021-11-11 20:02:46 <donoban> nothing
2021-11-11 20:02:59 <donoban> iotop-c let me press ctrl+t for enabling it, but it didn't work 
2021-11-11 20:03:04 <xordspar0> ikke: yes
2021-11-11 20:03:17 <psykose> then i guess you need delayacct on the cmdline
2021-11-11 20:03:17 <donoban> oh
2021-11-11 20:03:20 <donoban> it works now
2021-11-11 20:03:24 <donoban> it seems that it delayed a few time
2021-11-11 20:03:26 <ikke> xordspar0: ok\
2021-11-11 20:03:41 <psykose> ah
2021-11-11 20:03:49 <psykose> just sysctl then
2021-11-11 20:05:44 <xordspar0> ikke: Wait, I'm actually not sure. They might be in the process of changing the version scheme. Usually x.0 releases are LTS. Anyway, 3.14 uses a deprecated non-LTS release.
2021-11-11 20:06:37 <ikke> xordspar0: yeah, I noticed
2021-11-11 20:06:55 <ikke> I left some remarks
2021-11-11 20:07:10 <minimal> donoban: https://github.com/Tomas-M/iotop/issues/21
2021-11-11 20:07:42 <xordspar0> ikke: ty
2021-11-11 20:08:28 <xordspar0> Also according to phk the 7.x line will not include an LTS release: https://varnish-cache.org/lists/pipermail/varnish-announce/2021-September/000747.html
2021-11-11 20:09:54 <donoban> minimal: I see
2021-11-11 20:11:04 <minimal> donoban: so you can use sysctl as an alternative to adding it to cmdline
2021-11-11 20:11:45 <ikke> xordspar0: what is the current LTS release?
2021-11-11 20:11:54 <donoban> ok ok
2021-11-11 20:12:28 <xordspar0> ikke: 6.0: http://varnish-cache.org/docs/index.html
2021-11-11 20:13:38 <xordspar0> The non-LTS "fresh" releases are on a 6 month cycle. Sometimes the newest release makes it into Alpine and sometimes it doesn't, it seems.
2021-11-11 20:13:58 <ikke> Because people not always pay attention
2021-11-11 20:14:07 <ikke> (or don't care)
2021-11-11 20:14:25 <psykose> why does 6.0.8 (lts) say 'supported' for EOL
2021-11-11 20:14:35 <psykose> instead of any time value indicating how long that is
2021-11-11 20:15:11 <nmeum> mps: did xorg 21.X change something related to font rendering? somehow every rendered text is slightly bigger here now
2021-11-11 20:16:11 <xordspar0> psykose: Good question :)
2021-11-11 20:16:24 <psykose> supported until next week, i guess ;)
2021-11-11 20:21:07 <mps> nmeum: I didn't noticed any change on 4 machines
2021-11-11 20:21:15 <mps> but maybe it does
2021-11-11 20:21:37 <ikke> I wonder what the next LTS release for varnish will be
2021-11-11 20:21:38 <mps> nmeum: could be because it now better handle hidpi
2021-11-11 20:21:41 <donoban> nothing changed here too (if it upgraded correctly)
2021-11-11 20:21:55 <ikke> xordspar0: maybe you could add a comment above pkgrel mentioning to use LTS version
2021-11-11 20:21:57 <ikke> versions*
2021-11-11 20:22:06 <ikke> pkgver*
2021-11-11 20:22:40 <mps> nmeum: maybe you need to set it now differently, look what xdpinfo says with old and upgraded X
2021-11-11 20:23:00 <nmeum> yeah, that might be it
2021-11-11 20:24:20 <mps> nmeum: actually I'm lying, I had it also but forgot :)
2021-11-11 20:24:50 <xordspar0> ikke: sure
2021-11-11 20:24:50 <nmeum> did you just change the DPI manually then?
2021-11-11 20:25:14 <mps> yes, in .xinitrc
2021-11-11 20:25:27 <mps> but only on one machine
2021-11-11 20:25:39 <nmeum> with xrandr --dpi?
2021-11-11 20:26:10 <mps> echo 'Xft.dpi: 235' | xrdb -merge
2021-11-11 20:26:20 <mps> in .xinitrc
2021-11-11 20:26:55 <nmeum> right, that should work too. thanks
2021-11-11 20:26:56 <mps> this should be written in release notes
2021-11-11 20:27:21 <nmeum> they also mention dpi issues in the xorg announcement
2021-11-11 20:27:24 <nmeum> https://lists.x.org/archives/xorg/2021-October/060799.html
2021-11-11 20:27:38 <nmeum> > X server now correctly reports display DPI in more cases. This may affect rendering of client applications that have their own workarounds for hi-DPI screens.
2021-11-11 20:27:58 <mps> yes, I remember this
2021-11-11 20:28:16 <mps> and that is why I knew this 'from the head'
2021-11-11 20:29:11 <mps> 
ACTION is someone who reads release notes of major upgrades of pkgs

2021-11-11 20:29:31 <mps> and someone who forget them after reading :)
2021-11-11 20:30:30 <mps> actually I read release notes even for minor upgrades, but not always
2021-11-11 20:39:12 <xordspar0> ikke: Did you mean to add that comment in a separate MR or in the MR I linked to? I'm not the MR author, FYI.
2021-11-11 20:39:31 <ikke> oh, ok, I misunderstood
2021-11-11 20:41:02 <xordspar0> Ok, np. Just mention that in the MR thread then I guess.
2021-11-11 22:08:04 <wyk72> I need some help regarding running alpine-extended via an usb key (formatted w setup-bootable script) in DATA/RAM  mode
2021-11-11 22:08:48 <wyk72> when I run the update-kernel script, I lose ZFS modules (they don't seem to make it into initramfs/modloop)
2021-11-11 22:09:31 <wyk72> if I add them into mkinitfs.conf as per wiki instructions, they don't get into the modloop either
2021-11-11 22:10:01 <wyk72> if I force them the init gets coprrupt and the usb key does not boot (mounting root failed) like it's not loading the USB modules
2021-11-11 22:10:06 <wyk72> it's very weird
2021-11-12 03:41:43 <Ariadne> meanwhile, on the moon: https://github.com/openwrt/openwrt/pull/4294#issuecomment-966774292
2021-11-12 06:07:00 <lzsaver> ncopa, is the "thunderbolt-net" module available somehow on alpine as some package? I do not see it in linux-lts / linux-virt for x86_64.
2021-11-12 06:07:00 <lzsaver> # modprobe thunderbolt-net
2021-11-12 06:07:00 <lzsaver> modprobe: module thunderbolt-net not found in modules.dep
2021-11-12 06:12:55 <lzsaver> some modern desktops have at least one thunderbolt port and most modern laptops have it as well. thunderbolt-net provides high-speed tcp/ip network over the thunderbolt protocol. it would be nice to have such option in alpine out of the box. more info: https://kernel.org/doc/html/v4.15/admin-guide/thunderbolt.html https://christian.kellner.me/2018/05/24/thunderbolt-networking-on-linux/
2021-11-12 06:23:54 <lzsaver> ah, I see it in linux-edge
2021-11-12 06:23:54 <lzsaver> https://pkgs.alpinelinux.org/contents?file=*thunderbolt*&path=%2Flib%2Fmodules%2F*&name=&branch=edge&arch=x86_64
2021-11-12 06:28:39 <lzsaver> any chances to get it in a non-edge kernel before the 3.15 release?
2021-11-12 06:55:28 <ncopa> morning
2021-11-12 06:55:41 <ncopa> do you know what the kernel config knobs are for thunderbolt-net?
2021-11-12 06:55:47 <ncopa> config-lts.x86_64:CONFIG_INTEL_WMI_THUNDERBOLT=m
2021-11-12 06:55:53 <ncopa> is what we already have
2021-11-12 06:57:08 <ncopa> CONFIG_USB4_NET
2021-11-12 07:02:29 <mps> good morning
2021-11-12 07:02:50 <mps> I think it is already enabled in linux-edge
2021-11-12 07:04:02 <mps> lzsaver: could you try to install linux-edge and check if it works
2021-11-12 07:05:27 <ikke> mps: they already mentioned it's present in edge
2021-11-12 07:08:35 <ncopa> lzsaver: can you please create an issue for it? and ad label categor:kernel. so i dont forget
2021-11-12 07:08:41 <mps> ikke: ah, just started to drink first morning coffee so I do not 'see' what I read
2021-11-12 07:09:53 <mps> ikke: but I remember that you told me to enable this driver :)
2021-11-12 07:10:06 <ikke> mps: I don't :D
2021-11-12 07:10:27 <mps> you and/or clandmeter, I think
2021-11-12 07:11:03 <mps> please don't force me to read irclogs early in the morning :)
2021-11-12 07:12:39 <ikke> ncopa: any objections against merging !25372?
2021-11-12 07:13:02 <ikke> It's not an LTS release, but nor is the current 6.6 
2021-11-12 07:13:41 <mps> 2021-05-05 22:18............@ikke| mps: do you know what enables the thunderbolt module? linux-edge has it, but linux-lts does not
2021-11-12 07:13:57 <ikke> aha
2021-11-12 07:14:04 <ikke> probably because someone asked about it
2021-11-12 07:14:27 <mps> I think so
2021-11-12 07:18:26 <ncopa> ikke: no objection
2021-11-12 07:18:37 <ikke> alright
2021-11-12 08:01:04 <ncopa> whee! all builders are idle
2021-11-12 08:02:14 <ikke> I feel an RC incomming
2021-11-12 08:02:33 <ncopa> I was thinking of tagging a new 3.14 release for the busybox CVEs
2021-11-12 08:02:35 <mps> is the libreoffice fixed?
2021-11-12 08:02:43 <ikke> ncopa: ah
2021-11-12 08:02:46 <ikke> mps: no
2021-11-12 08:02:55 <lzsaver> mps, yes, I'll try it today later.
2021-11-12 08:03:17 <mps> ncopa: I think I should upgrade postfix bug fix release for 3.14 after breakfast
2021-11-12 08:05:39 <mps> is the "bugfix uprade to 3.6.3" good commit msg?
2021-11-12 08:08:27 <lzsaver> ncopa, sure. in alpine/aports, right?
2021-11-12 08:09:34 <ikke> lzsaver: correct
2021-11-12 09:34:45 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.14.3-released.html
2021-11-12 09:35:00 <ncopa> I added the date above the title to the right
2021-11-12 09:38:10 <ikke> Not all CVE links show a fixed version
2021-11-12 09:38:19 <ikke> https://security.alpinelinux.org/vuln/CVE-2021-42374
2021-11-12 09:52:44 <ncopa> i have no permissions to set channel topic. can someone please help me update alpine version in irc channels?
2021-11-12 09:53:37 <ikke> ncopa: you should now
2021-11-12 09:54:10 <ikke> ncopa: can you also look at !13117 while you're working on releases?
2021-11-12 09:54:12 <ikke> urg
2021-11-12 09:54:14 <ikke> #13117
2021-11-12 10:02:11 <ncopa> i dunno what to do with the signature of the previous ppc64le release
2021-11-12 10:02:38 <ncopa> IIRC the release had a hickup of some sort, so I had to manually regenerate the release
2021-11-12 10:02:52 <ncopa> some checksum got broken in the process I guess
2021-11-12 10:04:25 <ikke> And signing them again does not help?
2021-11-12 10:11:17 <ncopa> I just re-signed the releases
2021-11-12 10:11:32 <ncopa> I had to manually delete the old signature from dl-master first
2021-11-12 10:14:08 <ikke> Ok, so you think it should work now?
2021-11-12 10:14:16 <ikke> ah, you replied already
2021-11-12 10:25:36 <ncopa> finally done with 3.14.3 \o/
2021-11-12 10:26:13 <ncopa> ok. whats next. 3.13.x, 3.12.x and 3.11.x? or I do 3.15.0_rc1?
2021-11-12 10:26:51 <ikke> Are we ready for _rc1?
2021-11-12 10:27:14 <ikke> The build failure from libreoffice might indicate issues with boost
2021-11-12 10:27:23 <ikke> It only happens on 3.15
2021-11-12 10:27:59 <ncopa> so we pushed boost-x, built 3.15, upgraded to boost-y, and now 3.15 fails?
2021-11-12 10:28:23 <ncopa> next release we should freeze boost when building world
2021-11-12 10:28:50 <ncopa> what arch fails to build libreoffice?
2021-11-12 10:28:57 <ikke> I think all
2021-11-12 10:29:12 <ikke> I confirmed it on x86_64
2021-11-12 10:29:31 <ikke> I don't think we upgraded boost during building world
2021-11-12 10:29:35 <ncopa> how was the boost upgrade performed? was the dependants not rebuilt?
2021-11-12 10:30:23 <ikke> boost1.77 was moved to main before the builders were setup
2021-11-12 10:30:45 <ncopa> but libreoffice (and others?) was not rebuilt when that happened?
2021-11-12 10:31:09 <ikke> No, it just failed to build when the builders reached it
2021-11-12 10:31:23 <ncopa> ok
2021-11-12 10:31:57 <ikke> w#13141
2021-11-12 10:32:14 <ncopa> well, liberoffice and boost are not on any release media i guess? so it shouldn't make any difference for a _rc1?
2021-11-12 11:55:17 <ikke> Ah, I see jirutka created separate packages for major postgresql versions
2021-11-12 11:56:05 <ikke> 3e1445c35d12886e3c844c79bc1cc6da2b790f4c
2021-11-12 12:21:44 <maribu> Would it be possible to disable SC3060 in the linter? abuild uses `#!/bin/ash -e` - so incompatibilities with dash shouldn't be of concern, should they?
2021-11-12 12:23:11 <ikke> also relevant: https://github.com/koalaman/shellcheck/issues/1841
2021-11-12 12:23:31 <ikke> But yes, I think 3060 can be disabled
2021-11-12 12:25:20 <ikke> https://github.com/koalaman/shellcheck/issues/853 is better
2021-11-12 13:30:37 <ncopa> I guess we can tag 3.15.0_rc1 now?
2021-11-12 13:50:56 <valerius> any good news on linux-lts?
2021-11-12 13:53:22 <ncopa> only good news on linux-lts
2021-11-12 13:53:25 <ncopa> works fine for me :)
2021-11-12 13:54:23 <Ariadne> ncopa: do it
2021-11-12 13:56:39 <ncopa> done...
2021-11-12 13:57:44 <ncopa> so.. I've done 5 releases on a single day
2021-11-12 13:57:47 <ncopa> on a Friday...
2021-11-12 13:57:52 <ncopa> must be some sort of record
2021-11-12 13:59:05 <Ariadne> regarding libreoffice
2021-11-12 13:59:16 <Ariadne> i can look into what is going on with boost
2021-11-12 14:00:22 <valerius> I'll have to check if it boots on my system now, I see there's another build since I last checked
2021-11-12 14:00:44 <mps> ncopa: no worries, it is 12 and not 13 date of november :)
2021-11-12 14:01:18 <mps> even if it is friday
2021-11-12 14:08:47 <ncopa> 3.15.0_rc1 is tagged. can someone please send an email to alpine-devel mailing list? I need a break...
2021-11-12 14:15:02 <mps> valerius: maybe CONFIG_DRM_FBDEV_EMULATION=y is needed for -lts
2021-11-12 14:16:03 <mps> ahm, already enabled
2021-11-12 14:16:08 <valerius> last time I tried booting it just freezes at loading initial ramdisk... so yeah, never kicks into framebuffer console
2021-11-12 14:16:43 <mps> I've got blank screen by disabling it
2021-11-12 14:19:14 <fcolista> is this suffice? https://tpaste.us/YE14
2021-11-12 14:19:31 <fcolista> ikke, clandmeter ^
2021-11-12 14:33:09 <minimal> valerius: what type of machine is the problem with? x86? x86_64? arm? with BIOS or UEFI?
2021-11-12 14:33:49 <valerius> x86_64, UEFI, Radeon 5500XT
2021-11-12 14:37:11 <mps> with current 5.15.2 release GKH should write 'all users must upgrade to arm arch' ;)
2021-11-12 14:37:47 <Misthios> if i had money
2021-11-12 14:38:29 <mps> Misthios: you can buy samssung exynos chromebook with about 200 eur
2021-11-12 14:38:45 <Misthios> yeah but those are meh
2021-11-12 14:38:54 <minimal> valerius: I've had no issues with x86_64 UEFI in general with 5.15.1-3 linux-virt. I have not yet tested linux-lts. Wonder if CONFIG_DRM_RADEON is set for linux-lts
2021-11-12 14:38:54 <Misthios> might get a pinephone pro around march if its good
2021-11-12 14:38:54 <mps> hah
2021-11-12 14:39:56 <mps> Misthios: believe me this old armv7 chromebook is really usable with alpine
2021-11-12 14:41:10 <valerius> CONFIG_DRM_RADEON=m
2021-11-12 14:52:04 <Ariadne> i think libreoffice builds fine on aarch64
2021-11-12 14:52:36 <ikke> Ariadne: It apparently only happened on the 3.15 build
2021-11-12 14:52:59 <mps> Ariadne: I tested it on my lxcs armv7, aarch64 and x86_64. it builds but not on 3.15 builders
2021-11-12 14:53:34 <Ariadne> well then
2021-11-12 14:53:41 <Ariadne> let’s send it to the builders again
2021-11-12 14:53:52 <Ariadne> could have been memory pressure
2021-11-12 14:54:17 <psykose> it was a configure fail
2021-11-12 14:55:05 <Ariadne> yes i know
2021-11-12 14:55:10 <Ariadne> in a linker
2021-11-12 15:21:35 <alandiwix> are there any arm laptops with somewhat ok GPUs on a market? or should I wait for M1 Max to have solid GPU support in linux?
2021-11-12 15:29:26 <mps> alandiwix: M1 gpu will not be soon ready
2021-11-12 15:30:17 <mps> alandiwix: you can look at some rockchip RK33xx and up with mali 860
2021-11-12 15:31:43 <mps> my daughter have one old about 5 years now, rk3390 samsung chromebook, panfrost driver for gpu works fine though it is not high end class
2021-11-12 15:32:50 <minimal> valerius: could it be missing firmware for the Radeon? wondering if the relevant firmware from Alpine package linux-firmware-amdgpu needs to be in in the initramfs
2021-11-12 15:34:43 <valerius> yeah, wondering if it is something related to how the initramfs is being generated in this case
2021-11-12 15:34:56 <valerius> linux-edge is working fine and I'm talking to you using it
2021-11-12 15:35:05 <valerius> so there is some subtle difference somewhere
2021-11-12 15:37:28 <psykose> the main difference between latest edge-linux-lts and edge-linux-edge is -lts uses simpledrm for everything, edge still has the fbdev stuff
2021-11-12 15:38:01 <mps> +CONFIG_FB_BOOT_VESA_SUPPORT=y
2021-11-12 15:39:48 <minimal> psykose: yeah that why I was thinking that the amdgpu drm module when loaded needs firmware files and if linux-lts is loading/initialising it in initramfs then these file would possibly need to be in there
2021-11-12 15:40:11 <mps> valerius: nice that i'm conservative and don't change a lot on upgrades
2021-11-12 15:40:35 <psykose> minimal: perhaps indeed
2021-11-12 15:40:46 <mps> I prefer work in in small steps
2021-11-12 15:40:51 <psykose> if valerius knows how to include firmware files into initramfs, should try to see if that fixes it
2021-11-12 15:41:22 <mps> psykose: if it is installed I think it is added by default
2021-11-12 15:41:40 <minimal> mps: if that setting affect when the hardware-specific drm kicks in then it should be visible in the "dmesg" timings when the amdgpu (or whatever) is initialised, i.e. if its done after 6 secons then like not from initramfs whereas if its 1-1.5secs then like by initramfs
2021-11-12 15:42:02 <mps> (always hated it added on my initramfs and I don't have these cards)
2021-11-12 15:42:37 <minimal> mps: I tune my initramfs contents for different hardware and use cases :-)
2021-11-12 15:43:07 <mps> minimal: testing all these with newly added simpledrm takes time
2021-11-12 15:43:23 <psykose> uuhh
2021-11-12 15:43:25 <minimal> mps: indeed, that's what I've been doing the past couple of days :-)
2021-11-12 15:43:38 <psykose> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/mkinitfs.in#L143
2021-11-12 15:43:50 <psykose> doesn't this break if the .ko is compressed, rn it's .ko.gz on -lts
2021-11-12 15:44:47 <mps> psykose: good catch
2021-11-12 15:44:51 <minimal> psykose: good spot! that needs changed
2021-11-12 15:44:56 <valerius> ah yes, that would do it
2021-11-12 15:44:58 <psykose> maybe that is why my bluetooth doesn't work on lts either, somehow
2021-11-12 15:45:09 <psykose> even though all the firmware does load fine and dmesg is the same :) but who knows
2021-11-12 15:45:28 <minimal> to "*.ko.*" I guess (to cover for other than zstd compression as well)
2021-11-12 15:45:40 <mps> +1
2021-11-12 15:46:10 <psykose> modinfo seems to handle compression itself fine
2021-11-12 15:46:12 <psykose> simple enough change
2021-11-12 15:46:26 <psykose> +1 from me too :0
2021-11-12 15:46:29 <psykose> :) *
2021-11-12 15:46:32 <mps> though it shoule be '*.ko*'
2021-11-12 15:47:05 <skarnet> I don't want foo.koala to match
2021-11-12 15:47:30 <mps> linux-edge doesn't compress modules currently
2021-11-12 15:47:31 <psykose> compression will always have another . *.ko.* seems fine to me
2021-11-12 15:47:35 <psykose> ah
2021-11-12 15:47:36 <psykose> right
2021-11-12 15:48:05 <minimal> mps: I thought to use "*.ko.*" as that avoid any filename containing the substring "ko" from being unnecessarily added to initramfs
2021-11-12 15:48:09 <mps> though I want with 5.12.2 to use xz for compression
2021-11-12 15:48:32 <psykose> -name "*.ko" -o -name "*.ko.*"
2021-11-12 15:48:47 <mps> minimal: if you find foo.koala there something is wrong with this system
2021-11-12 15:49:16 <minimal> Just noticed linux-lts is on GZ compression now? did it switch since yesterday from zstd?
2021-11-12 15:49:35 <mps> minimal: yes, this morning, iirc
2021-11-12 15:49:58 <ikke> b532b582adf36253ece5209c8d698cc907064c58
2021-11-12 15:50:09 <ikke> yesterday
2021-11-12 15:50:13 <mps> looks like ncopa 'follows' my method more and more :)
2021-11-12 15:51:29 <minimal> ikke: fair enough. Perhaps that might address !13185 as I assumed that issue was a Alpine 3.12 Xen host not supporting zstd
2021-11-12 15:51:44 <minimal> oops, #13185
2021-11-12 15:52:07 <ikke> minimal: lol, that would never happen to me :P
2021-11-12 15:52:09 <mps> minimal: what about xz compression? will it work?
2021-11-12 15:52:43 <minimal> mps: I guess that depends on Busybox's modprobe
2021-11-12 15:53:01 <minimal> mps: or do you mean for Xen?
2021-11-12 15:53:23 <mps> I mean for Xen
2021-11-12 15:53:50 <mps> minimal: but good that you warned me to test first
2021-11-12 15:54:11 <minimal> mps: not sure, never actually used Xen, but it uses grub-xen which I guessed on Alpine 1.12.x was an older version of Grub without zstd support
2021-11-12 15:54:33 <psykose> minimal: i don't understand that issue, config_kernel_gzip has been =y for a while 
2021-11-12 15:54:45 <mps> zstd is too new, I wouldn't rely on it yet
2021-11-12 15:55:11 <mps> psykose: this is for vmlinuz
2021-11-12 15:55:12 <minimal> psykose: that issue is 22+ hours old, I/m guessing when he tested with linux-virt it was still using zstd rather than gz
2021-11-12 15:55:33 <psykose> ah, it's possible
2021-11-12 15:55:37 <psykose> but that was only for modules
2021-11-12 15:55:48 <mps> psykose: and that doesn't work on aarch64
2021-11-12 15:56:52 <mps> I hope I will find time this evening to test this on x86_64
2021-11-12 15:57:23 <psykose> ah i see, there was a brief window of kernel_zstd=y for very short time
2021-11-12 15:57:25 <psykose> forgot about that :)
2021-11-12 15:57:34 <psykose> days ago
2021-11-12 15:59:00 <minimal> psykose: true the kernel is bz compressed. In that issue when I saw the "xc_dom_probe_bzimage_kernel: unknown compression format: Invalid kernel" error it made me think of the zstd stuff
2021-11-12 15:59:28 <psykose> it's possible the person hasn't updated in 6 days but did pull the zstd update
2021-11-12 15:59:40 <psykose> but i guess that's why you don't run edge kernels on alpine 3.12, or something
2021-11-12 16:00:12 <mps> minimal: bz?
2021-11-12 16:00:51 <psykose> ah, no, i have misread again
2021-11-12 16:00:57 <psykose> sigh, i have drank way too much caffeine today :)
2021-11-12 16:02:21 <ikke> fcolista: Looks good
2021-11-12 16:02:22 <psykose> minimal: the person is right
2021-11-12 16:02:39 <psykose> the -virt kernel is zstd..
2021-11-12 16:02:49 <psykose> https://git.alpinelinux.org/aports/tree/main/linux-lts/config-virt.x86_64#n45
2021-11-12 16:03:09 <minimal> actually very strange thing I just noticed: with both 5.15.1-1-virt and 5.15.1-3-virt both have CONFIG_KERNEL_ZSTD=y whereas "file" says /boot/vmlinuz is bz compression
2021-11-12 16:04:21 <mps> psykose: take wine, it is better than coffee ;)
2021-11-12 16:04:24 <psykose> bzImage is not bz compression
2021-11-12 16:04:26 <minimal> when I just said bz I was relying on "file"
2021-11-12 16:05:01 <psykose> mps: drinking leads to bad things :p
2021-11-12 16:05:36 <minimal> so zstd kernel is likely to be cause of that Xen issue
2021-11-12 16:05:55 <mps> hah, drinking alcohol is best thing in this world, and last one for free people
2021-11-12 16:10:39 <psykose> minimal: yes, all of -lts is kernel_zstd since 5.15
2021-11-12 16:10:53 <psykose> i just got confused at first and assumed other things
2021-11-12 16:11:36 <psykose> modules got moved from no-compression->zstd->gz in 5.15 alone; kernel went gz->zstd
2021-11-12 16:11:51 <minimal> psykose: right, so does grub-xen in Alpine 5.12.x support zstd?
2021-11-12 16:12:37 <psykose> xen supports zstd from 4.15
2021-11-12 16:12:49 <psykose> alpine 3.12 has xen 4.13.4
2021-11-12 16:13:48 <psykose> to be fair i don't think this is an issue that matters.. this person is using 3.12 xen trying to run alpine-edge kernels, which sounds funny in my head
2021-11-12 16:14:04 <psykose> alpine-3.14 kernel would work fine
2021-11-12 16:14:40 <psykose> alpine-3.14 xen is 4.15 and should support the edge kernels fine, xen in alpine 3.15 should as well
2021-11-12 16:14:52 <psykose> doesn't make sense to change -edge kernel configs to be supported by something in -3.12
2021-11-12 16:15:27 <psykose> but if it's wanted, it should be reverted to kernel_gzip
2021-11-12 16:16:06 <psykose> personal opinion: ignore wontfix :) but i will let ncopa decide
2021-11-12 16:17:00 <psykose> minimal: also have you tested/mr'd the mkinitfs fix?
2021-11-12 16:24:49 <minimal> psykose: due to the way Xen works think this is a Alpine 3.12 host which uses grub-xen (from 3.12) to boot an Alpine Edge VM which has a zstd compressed kernel
2021-11-12 16:26:12 <psykose> yep
2021-11-12 16:32:11 <Ariadne> maybe linux-virt should just be gz
2021-11-12 16:33:22 <psykose> i have no idea what this mkinitfs firmware thing does.. for me -lts is empty even adding .ko.* to the find, -edge includes only some... qlogic firmware for something i don't even have and nothing else
2021-11-12 16:48:30 <minimal> psykose: #13188
2021-11-12 16:48:48 <minimal> psykose: have you any linux-firmware-* packages installed?
2021-11-12 16:48:48 <abk> Is too late for the wishlist for Alpine 3.15? Would be cool to have the «unbound» dns server compiled with libnghttp2, so it provides DNS-over-HTTPS out of the box.
2021-11-12 16:49:11 <psykose> yes :) that's why in the -edge case i get some random fw in there, and i have fw for wifi i915 and bluetooth
2021-11-12 16:49:14 <Ariadne> abk: i'm afraid so
2021-11-12 16:49:20 <abk> ok
2021-11-12 16:49:56 <Ariadne> i mean, we can do it, if it is low risk
2021-11-12 16:50:30 <abk> I guess its low risk. It does no modify anything else.
2021-11-12 16:50:36 <psykose> minimal: ..oh i'm an idiot, i needed to change two lines
2021-11-12 16:50:41 <abk> *not*
2021-11-12 16:51:17 <Ariadne> okay
2021-11-12 16:52:03 <ikke> Installed size 1.31 MB
2021-11-12 16:52:39 <abk> however compiles it just needs to add --with-libnghttp2 (and update the dependencies)
2021-11-12 16:52:46 <ikke> oh, libs is Installed size 156 kB
2021-11-12 16:52:51 <Ariadne> feel free to open an MR
2021-11-12 16:54:34 <psykose> minimal: ok, i made it behave the same for compressed modules too https://termbin.com/gnlon
2021-11-12 16:55:13 <minimal> psykose: if you run "mkinitfs -l" to see what would go into a initramfs on your machine then any firmware included will relate to the modules included in the initram, e.g. if you're using amdgpu then a "modinfo amdgpu" will show a list of firmware files that (once the issue is fixed) will be included in the initramfs, assuming you have package linux-firmware-amdgpu installed when mkinitfs is run
2021-11-12 16:57:11 <psykose> yep, i understand that now :) was confused at first
2021-11-12 16:58:24 <staceee> Is there an available dev to merge our sxmo release ? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27364
2021-11-12 16:59:42 <mps> 'our'? who are 'our'
2021-11-12 17:00:19 <staceee> "our" as sxmo maintainers :)
2021-11-12 17:00:39 <mps> and why? today is first rc 3.15 is tagged
2021-11-12 17:01:17 <mps> I don't think we should now add anything except bug and sec fixes
2021-11-12 17:02:51 <mps> (but I know someone will blindly merge a lot of things)
2021-11-12 17:03:55 <staceee> thats why anjan proycon and me released two days ago to be ready
2021-11-12 17:04:46 <staceee> we needed some other merged on pmaports first. The process took longer than what we expected :)
2021-11-12 17:06:50 <mps> maybe PureTryOut could help, he better understand pmOS
2021-11-12 17:07:27 <PureTryOut> staceee: I can merge your stuff, but I asked you a questiosn #devel:postmarketos.org 😉
2021-11-12 17:07:48 <Ariadne> mps: :D
2021-11-12 17:08:00 <mps> :D
2021-11-12 17:08:37 <psykose> minimal: hah, i actually didn't know about -quit behaviour so that doesn't work, since -o with -quit always ignores the left side. i guess just *.ko* would be better
2021-11-12 17:08:37 <Ariadne> i think sxmo is low risk enough to warrant a freeze exception
2021-11-12 17:08:50 <mps> I have a hope that PureTryOut will become more conservative ;)
2021-11-12 17:09:10 <PureTryOut> I did not realize we had a freeze, sorry for that
2021-11-12 17:09:11 <Ariadne> but i don't want to introduce any new release-critical bugs
2021-11-12 17:09:28 <Ariadne> PureTryOut: well, it *is* that time of year :)
2021-11-12 17:09:42 <ikke> PureTryOut: I did sent out an e-mail on alpine-dev ;-)
2021-11-12 17:09:45 <PureTryOut> I mean, I expected 3.15 like 3 weeks ago already 😛
2021-11-12 17:10:10 <mps> maybe he is busy too much with pmOS and didn't noticed ;)
2021-11-12 17:10:14 <PureTryOut> ikke: please link the specific email that says the freeze has begun 😛
2021-11-12 17:10:23 <PureTryOut> mps: I mainly do Alpine packages, not pmOS
2021-11-12 17:10:42 <Ariadne> PureTryOut: https://lists.alpinelinux.org/~alpine/devel/%3CYWsU6tiHtmsWIma7%40alpha%3E
2021-11-12 17:10:53 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3CYWsU6tiHtmsWIma7%40alpha%3E#%3CYWsU6tiHtmsWIma7@alpha%3E
2021-11-12 17:11:24 <PureTryOut> Oh I thought that was just for toolchain stuff
2021-11-12 17:11:46 <Ariadne> anyway, sxmo is fine
2021-11-12 17:11:56 <Ariadne> feel free to merge it
2021-11-12 17:12:15 <Ariadne> but yes, lets try to be conservative :)
2021-11-12 17:12:46 <Ariadne> also: lol @ openssl dev team
2021-11-12 17:13:17 <mps> I would rephrase my stance 'innovative and conservative at same time'
2021-11-12 17:14:19 <mps> maybe 'carefully innovative'
2021-11-12 17:17:28 <minimal> 'infinitely unpredictable' :-)
2021-11-12 17:17:32 <PureTryOut> I just did not realize we were in a freeze that effected more than just the toolchains. Sorry for that
2021-11-12 17:17:49 <staceee> ty for the exception O:)
2021-11-12 17:18:09 <psykose> PureTryOut: thanks for your prompt pipewire updating :)
2021-11-12 17:18:25 <PureTryOut> Np, but I wouldn't have done it if I realized about this freeze 😅
2021-11-12 17:18:27 <minimal> psykose: yeah not sure of a "nice" way to deal with the "-o" and "-quit" conflict, don't know POSIX shell well enough
2021-11-12 17:19:57 <psykose> minimal: based on what i'm reading this is something that is really not correct but has stuck around for backwards compatibility in find as the behaviour is kind of nonsensical, but i guess just one -name "*.ko*" will work fine
2021-11-12 17:22:41 <shafire> Hello, what is the best way to send patches? A few years ago I used the mailing list, but now there is Gitlab.
2021-11-12 17:23:05 <psykose> or at least i hope nobody thinks only checking the rightmost option and immediately exiting ignoring the others is correct behaviour...
2021-11-12 17:23:12 <psykose> shafire: there is still a mailing list, and gitlab is also fine
2021-11-12 17:23:14 <psykose> your preference
2021-11-12 17:23:29 <psykose> it's easier to work with things in gitlab that need multiple goes :)
2021-11-12 17:27:26 <PureTryOut> shafire we'd recommend Gitlab
2021-11-12 17:29:37 <shafire> Ok, thanks!
2021-11-12 17:47:01 <mps> PureTryOut: no worries, ncopa gave me a full week of time to upgrade xorg-server and drivers (though I did that in a day (with your help libxcvt-doc, thanks))
2021-11-12 17:47:36 <mps> so it is not so dramatic as I 'pretend' it is ;)
2021-11-12 17:49:20 <mps> uhm, and that reminds me that I wanted to pick zathura-djvu patch from ML to add, but forgot
2021-11-12 17:50:27 <mps> testing kernels takes time
2021-11-12 17:56:17 <alandiwix> mps: you mean 5.15.2?
2021-11-12 17:57:11 <shafire> How again is the procedure to create a merge request? :D I fork aports, push a commit and then in Gitlab, I create the merge request?
2021-11-12 17:57:59 <mps> alandiwix: yes
2021-11-12 17:58:54 <alandiwix> let me gently remind you about mediatek drivers :)
2021-11-12 18:00:04 <psykose> shafire: yes
2021-11-12 18:00:51 <ikke> shafire: make sure you create a branch first (on master)
2021-11-12 18:01:15 <mps> alandiwix: already added in WIP
2021-11-12 18:02:13 <alandiwix> thanks
2021-11-12 18:02:18 <shafire> thanks
2021-11-12 18:02:22 <mps> but we need fix for mkinitfs psykose proposed above if we want to have kernel compressed modules
2021-11-12 18:02:46 <mps> s/we need/we must have/
2021-11-12 18:02:46 <alpine-meetbot> mps meant to say: but we must have fix for mkinitfs psykose proposed above if we want to have kernel compressed modules
2021-11-12 18:03:03 <psykose> i put a for-me working sample patch on the issue minimal created at #13188
2021-11-12 18:03:04 <mps> just tested this
2021-11-12 18:03:06 <psykose> someone else needs to confirm though
2021-11-12 18:03:11 <ikke> #13188?
2021-11-12 18:03:14 <psykose> and actually merge it somewhere :)
2021-11-12 18:03:44 <mps> will test it now
2021-11-12 18:03:53 <ikke> dalias: fyi, libreoffice is avaible again
2021-11-12 18:04:54 <mps> psykose: ah not patch, just issue
2021-11-12 18:05:04 <psykose> it's linked in the reply
2021-11-12 18:05:16 <psykose> i can mr it to alpine/mkinitfs, but that is scary
2021-11-12 18:05:32 <mps> ah. I see
2021-11-12 18:07:35 <alandiwix> what are -edge compress methods for kernel & modules?
2021-11-12 18:08:34 <psykose> gzip kernel, uncompressed modules
2021-11-12 18:09:24 <dalias> ikke, yay thank you!
2021-11-12 18:09:27 <dalias> what was the fix?
2021-11-12 18:09:32 <alandiwix> but mps just mentioned some plans to change that, didn't he?
2021-11-12 18:09:38 <ikke> autoconf 
2021-11-12 18:09:55 <dalias> ah, its autoconf was just outdated?
2021-11-12 18:10:00 <mps> alandiwix: yes, I'm testing with xz
2021-11-12 18:10:03 <ikke> dalias: https://git.alpinelinux.org/aports/commit/?id=afc8349a712d
2021-11-12 18:10:04 <dalias> and doing something wrong to detect boost?
2021-11-12 18:10:10 <psykose> alandiwix: probably will get gz modules, but have to make sure everything works first
2021-11-12 18:10:29 <ikke> dalias: the logic was incorrect, causing it to use clang, not clang++ to try to link
2021-11-12 18:10:44 <dalias> ahhh
2021-11-12 18:10:55 <dalias> well the DT_NEEDED being present would have avoided the need
2021-11-12 18:11:05 <dalias> so i think there's still a bug in boost too
2021-11-12 18:11:11 <dalias> but glad this works around it :)
2021-11-12 18:11:23 <alandiwix> what aboud decomp speed? isn's zstd better in this regard?
2021-11-12 18:11:39 <psykose> ikke: haha, i had almost figured that out.. i was one away from that lang stuff but couldn't figure it out in the end :)
2021-11-12 18:11:52 <ikke> ariadne figured it out
2021-11-12 18:11:54 <psykose> yep
2021-11-12 18:11:58 <ikke> I have no clue about autoconf :)
2021-11-12 18:12:03 <psykose> big clap for ariadne
2021-11-12 18:12:18 <psykose> alandiwix: in my experience, xz is slow enough to make my eyes bleed :)
2021-11-12 18:12:23 <xordspar0> ikke, ncopa: Thanks a ton for reviewing and merging Varnish 7.0!
2021-11-12 18:12:39 <psykose> zstd won't be used for modules yet as it is not supported by busybox for now and needs kmod (1MB)
2021-11-12 18:12:46 <Ariadne> dalias: yes, but do we really want to open the eldritch box of horrors which is boost-build
2021-11-12 18:12:47 <psykose> the -lts kernel is zstd though
2021-11-12 18:13:47 <Ariadne> also, the OpenSSL team would like to let everyone know that they are upset that I wrote a report to the TSC outlining why the OpenSSL 3 migration was reverted and my general opinions on OpenSSL 3
2021-11-12 18:14:21 <Ariadne> i mean, that report was going to get written regardless of their feelings, but i am quite amused
2021-11-12 18:14:22 <dalias> ariadne, :)
2021-11-12 18:15:10 <ikke> Ariadne: popcorn.gif
2021-11-12 18:15:12 <psykose> Ariadne: do you have a quick link to this perchance :)
2021-11-12 18:15:15 <Ariadne> someday, i am going to lose my mind over some open source grandstanding bullshit
2021-11-12 18:15:26 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
2021-11-12 18:15:29 <psykose> thanks
2021-11-12 18:15:41 <Ariadne> hey, they fixed the EVP_md_null
2021-11-12 18:15:45 <Ariadne> after a month of not caring
2021-11-12 18:16:12 <Ariadne> i mean, i don't know, if an API that was not marked for deprecation turned into a crash bug
2021-11-12 18:16:18 <Ariadne> i think personally i would prioritize fixing it
2021-11-12 18:17:21 <Ariadne> that's just me though
2021-11-12 18:17:34 <Ariadne> apparently to OpenSSL, reinventing QUIC support from scratch and refusing to support DTLS is more important
2021-11-12 18:17:45 <mps> aieee, busybox kmod with xz compressed modules doesn't work
2021-11-12 18:17:49 <Ariadne> i smell another Heartbleed in the future
2021-11-12 18:18:03 <mps> now to build with gz
2021-11-12 18:18:26 <skarnet> Ariadne: you have real trouble letting go of past slights
2021-11-12 18:18:28 <skarnet> they suck
2021-11-12 18:18:30 <psykose> mps: i recommend just sticking with gz for now, until busybox merges zstd patch
2021-11-12 18:18:32 <skarnet> they proved they suck
2021-11-12 18:18:37 <skarnet> you gonna dump them
2021-11-12 18:18:38 <Ariadne> :D
2021-11-12 18:18:41 <skarnet> that's all good
2021-11-12 18:18:42 <skarnet> end of story
2021-11-12 18:19:12 <caskd> Unrelated topic but does anyone else have problems with tty throwing permission denied since a recent update?
2021-11-12 18:19:23 <mps> psykose: right, I agree. just wanted to test
2021-11-12 18:19:23 <psykose> are you using gdm perchance
2021-11-12 18:19:25 <Ariadne> skarnet: i mean, i proposed switching to LibreSSL, and then got hit with whining from them in alpine gitlab and github.  i was pretty much over it :)
2021-11-12 18:19:52 <Ariadne> i have work to do
2021-11-12 18:19:55 <skarnet> well it's the uninvolved bf scrambling back when he sees you're leaving his ass
2021-11-12 18:19:56 <psykose> mps: mhm :) after the merge we can do a "slow" and "tested" attempt at zstd modules for real.. i feel xz is a bit too slow
2021-11-12 18:20:01 <skarnet> nothing special
2021-11-12 18:20:28 <alandiwix> psykose: are there a zstd patch for busybox?
2021-11-12 18:20:30 <Ariadne> why not just use gz
2021-11-12 18:20:40 <skarnet> I'm so so sorry how can I make it up to you - I swear I'm going to be better for at least two minutes and a half
2021-11-12 18:20:42 <psykose> Ariadne: it is currently, will be, now
2021-11-12 18:20:45 <psykose> alandiwix: there is, unmerged
2021-11-12 18:20:55 <Ariadne> skarnet: well, they were mostly ok for 2 years
2021-11-12 18:21:11 <psykose> alandiwix: https://www.mail-archive.com/busybox@busybox.net/msg27914.html this thread about it
2021-11-12 18:21:32 <Ariadne> and at the time, they were heavily pushing the narrative that the OpenSSL 1.1 API breaks were for everyone's good (narrator: they were superfluous)
2021-11-12 18:21:46 <Ariadne> i'm just mad at myself for allowing myself to be gullible :)
2021-11-12 18:21:47 <alandiwix> would be nice to have zstd in the future... I'm wondering what size it will add to busybox though
2021-11-12 18:21:56 <psykose> the patch? probably quite little
2021-11-12 18:21:58 <ikke> What about libressl bumping soname every release?
2021-11-12 18:22:00 <skarnet> yeah but I mean their reaction here is neither unusual nor directed at you
2021-11-12 18:22:04 <skarnet> it's regular human weakness
2021-11-12 18:22:06 <skarnet> nothing to see here
2021-11-12 18:22:12 <vkrishn> is there support for orangefs module+orangefs tools ?
2021-11-12 18:22:20 <skarnet> anyway gtg, see you later
2021-11-12 18:22:25 <ikke> o/
2021-11-12 18:22:31 <psykose> alandiwix:  the existing requirement for zstd modules is 1MB kmod, so obviously we cannot do that yet. the busybox patch is probably a tiny amount in comparison for the same usability
2021-11-12 18:22:43 <Ariadne> ikke: eh, i think that is largely caused by the openssl portable maintainer not really understanding SONAMEs
2021-11-12 18:22:53 <Ariadne> ...
2021-11-12 18:22:57 <Ariadne> libressl portable
2021-11-12 18:23:30 <Ariadne> but i plan to get an answer regardless
2021-11-12 18:23:35 <mps> psykose: yes, looks like we should use gz for now
2021-11-12 18:23:51 <ikke> "It's part of the release strategy of libressl to increase the soname version with every openbsd release."
2021-11-12 18:24:06 <caskd> just ignore my prev msg about tty, seems like /etc/security/limits.d was the problem
2021-11-12 18:24:20 <Ariadne> ikke: well, if that's libssl.so.X.Y and they increment Y, that's fine
2021-11-12 18:24:32 <ikke> right
2021-11-12 18:24:50 <psykose> caskd: really? what in there caused a tty error
2021-11-12 18:24:55 <Ariadne> even if the issue is that the SONAME itself on the binaries is wrong
2021-11-12 18:24:59 <Ariadne> in this case, we can fix it
2021-11-12 18:25:17 <Ariadne> SONAMEs is something that is very easy (stupidly easy) to get wrong with automake+libtool
2021-11-12 18:25:17 <alandiwix> psykose: 17kb size cost for busybox is mentioned in these lists, which is really awesome
2021-11-12 18:25:22 <caskd> psykose: i've set the nofile size too high
2021-11-12 18:25:27 <Ariadne> so i would assume they are using libtool wrongly
2021-11-12 18:25:28 <psykose> mhm :)
2021-11-12 18:25:46 <psykose> caskd: hah, i wouldn't expect too much nofile to give such errors
2021-11-12 18:25:59 <caskd> turns out it did
2021-11-12 18:26:04 <Ariadne> nonetheless, openbsd developers have told me that actual ABI breaks in libressl have been minimal
2021-11-12 18:26:09 <Ariadne> and included receipts
2021-11-12 18:26:17 <ikke> ok
2021-11-12 18:26:30 <Ariadne> so i would assume it is libressl portable maintainer using libtool wrong
2021-11-12 18:27:27 <Ariadne> the other thing about libressl is that
2021-11-12 18:27:39 <Ariadne> instead of relicensing to apache2 under sketchy relicensing campaign
2021-11-12 18:27:48 <Ariadne> they are just rewriting all the openssl 1.x licensed code slowly
2021-11-12 18:27:57 <Ariadne> which i think is more clean
2021-11-12 18:28:02 <ikke> yea
2021-11-12 18:28:05 <caskd> psykose: http://0x0.st/-Roa.txt
2021-11-12 18:28:29 <caskd> well, not too high
2021-11-12 18:28:31 <caskd> but yeah...
2021-11-12 18:28:31 <ikke> Ariadne: technically openssl could do it if they have written permission from every author, right?
2021-11-12 18:28:44 <Ariadne> some authors are dead, or did not respond
2021-11-12 18:28:46 <Ariadne> and they did it anyway
2021-11-12 18:28:58 <Ariadne> and said "lol linux foundation core infrastructure initiative will cover the legal fees"
2021-11-12 18:29:01 <ikke> yeah, that's always a tricky thing
2021-11-12 18:36:43 <Ariadne> there's also AWS-LC, but they rewrote half of it in C++
2021-11-12 18:36:48 <Ariadne> so, i don't know how i feel about it
2021-11-12 19:09:26 <vkrishn> ok, CONFIG_ORANGEFS_FS module is there
2021-11-12 19:17:42 <mps> busybox insmod lib/modules/5.15.2-0-edge/kernel/fs/ext4/ext4.ko.gz => insmod: can't insert 'lib/modules/5.15.2-0-edge/kernel/fs/ext4/ext4.ko.gz': invalid module format
2021-11-12 19:20:44 <vkrishn> try modprobe
2021-11-12 19:20:57 <vkrishn> modprobe ext4
2021-11-12 19:21:09 <mps> vkrishn: no, it was from wrong kernel version
2021-11-12 19:21:14 <vkrishn> ah ok
2021-11-12 19:21:48 <mps> busybox insmod exfat.ko.gz worked
2021-11-12 19:22:47 <mps> busybox insmod exfat.ko.xz, also works
2021-11-12 19:23:38 <mps> so, why kernel doesn't boot with any of these two compression for modules
2021-11-12 19:26:30 <Newbyte> Can a subpackage have a subpackage?
2021-11-12 19:27:57 <Newbyte> What I'm trying to do is split off some extra libraries from the main package
2021-11-12 19:28:21 <Newbyte> So those libraries only get pulled in by the one package that consumes them (while the main package is consumed by various other packages)
2021-11-12 19:28:41 <Newbyte> But how can I give that subpackage for those libraries a -dev subpackage?
2021-11-12 19:31:04 <minimal> mps: I guess adding "debug_init" to cmdline won't be any use if DRM modules need to load to show anything? lol
2021-11-12 19:32:25 <mps> minimal: I have console text but not more '/sysroot' can't be mounted and keyboard doesn't work
2021-11-12 19:35:57 <minimal> mps: root mount failing makes sense if compressed ext4 module can't be loaded. Does the debug output show the modprobe attempts?
2021-11-12 19:39:20 <mps> minimal: no on the visible screen, and can't scroll back because keyboard doesn't work
2021-11-12 19:39:48 <mps> this is something to test on qemu
2021-11-12 19:40:46 <Newbyte> Made an MR with what I have right now, suggestions welcome: !27397
2021-11-12 19:41:08 <minimal> mps: as initramfs-init is shellscript stick in some "sleep" lines just after "modprobe" calls (and perhaps add "modprobe --help" to verify its actually Busybox version) and rebuild initramfs to test? ;-)
2021-11-12 19:42:44 <mps> could be 'APPEND modules=...." problem but don't have time now for this. will continue to make linux-edge with uncompressed modules and test gz/zstd when find time
2021-11-12 19:58:54 <mps> tomalok: ping
2021-11-12 19:59:32 <mps> does CONFIG_GPIO_PL061=y must be 'y' or it can be 'm'
2021-11-12 20:01:50 <psykose> it's set to =m for the aarch64 lts config
2021-11-12 20:02:39 <psykose> lts-virt*
2021-11-12 20:04:27 <mps> hmm, why it is needed in virt kernels
2021-11-12 20:06:32 <psykose> needed by ec2
2021-11-12 20:06:39 <psykose> https://git.alpinelinux.org/aports/commit/main/linux-lts?id=184cc768ed20a656079aeae847811b84b9e0061e
2021-11-12 20:06:52 <mps> ahm, we work for amazon
2021-11-12 20:07:28 <mps> then it could be module
2021-11-12 20:07:32 <psykose> yep
2021-11-12 20:10:05 <minimal> mps: AWS appear to use PL061 instead of ACPI button to signal VMs to gracefully shutdown
2021-11-12 20:10:36 <minimal> mps: so I guess it should be build as module
2021-11-12 20:11:33 <mps> and I think we do need this only aarch64?
2021-11-12 20:11:39 <minimal> don't know why AWS did this differently as Arm server specs (AMBA) require machines to have ACPI
2021-11-12 20:12:14 <mps> yes, and kernel have tiny-power module
2021-11-12 20:12:33 <minimal> mps: apart from x86/x86_64 AWS only offer arm64/aarch64, so not needed for Armv7
2021-11-12 20:13:42 <mps> minimal: yes, agree, and I doubt anyone would use virt armv7 except for basic things
2021-11-12 20:13:43 <psykose> i assume on x86 they use acpi normally
2021-11-12 20:14:32 <minimal> not sure what Azure and Oracle Cloud (and any other Arm-based cloud provider) do for their graceful shutdown signalling
2021-11-12 20:15:48 <minimal> psykose: yeah ACPI is the "standard" method and as mps pointed out for a VM/Cloud server you can load tiny-button instead of button just to handle ACPI power signal
2021-11-12 20:16:07 <psykose> wonder what the 'technical' reason is then for them
2021-11-12 20:17:40 <minimal> psykose: AWS? either they didn't bother with ABMA-related compliance, or they started designing their Arm servers before the spec was finalised, or just to be different, who knows. My question was what do the other Arm server Cloud vendors do? hopefully they'll use ACPI
2021-11-12 20:19:13 <minimal> oops, replace AMBA with SBSA (so many standards) lol
2021-11-12 20:21:25 <psykose> aye, same question here :)
2021-11-12 20:27:54 <minimal> psykoze: Oracle Cloud looks like ACPI button (based on a "dmesg" Ariadne gave me a while ago)
2021-11-12 20:29:06 <psykose> nice :)
2021-11-12 20:34:48 <mps> linux-edge is on builders with this enabled
2021-11-12 20:35:05 <mps> and CONFIG_MT7921E for alandiwix 
2021-11-12 20:35:48 <alandiwix> awesome, thanks!
2021-11-12 20:36:15 <mps> np
2021-11-12 20:41:11 <minimal> psykoze: for the mkinitfs Issue not sure who is going to work on this - I could do so but it would probably take me 24hrs of work/testing (especially as I don't have a spare real machine that I can reinstall on) before I'd be ready to raise an MR
2021-11-12 20:43:40 <Ariadne> 2:10 PM <minimal> mps: AWS appear to use PL061 instead of ACPI button to signal VMs to gracefully shutdown
2021-11-12 20:43:42 <Ariadne> what the actual fuck
2021-11-12 20:45:06 <minimal> Ariadne: https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021600.html
2021-11-12 20:45:20 <ikke> 184cc768ed20a656079aeae847811b84b9e0061e
2021-11-12 20:45:40 <Ariadne> yes
2021-11-12 20:45:43 <Ariadne> what i want to know is
2021-11-12 20:45:45 <Ariadne> the backstory
2021-11-12 20:46:42 <minimal> there's also a mentioned from Linaro: https://www.linaro.org/blog/linaro-engineering-highlights-december-2020/ (search for "PL061")
2021-11-12 20:47:34 <ikke> "A proposal to use sbsa_ec controller to reboot QEMU secure virtual machine was sent as patches to QEMU and Arm Trusted Firmware mailing lists. But discussion of next improvement sbsa_ec may break the virt platform, so the community decided to use secure gpio (pl061) to reboot/shutdown a virtual machine from the secure world. Maxim is working on a new set of patches."
2021-11-12 20:50:31 <psykose> minimal: well, it only needs someone to test if that is all that is needed; iirc it was valerius that was having drm issues, and if this was what caused it should be enough
2021-11-12 20:51:02 <minimal> psykose: it was flagged by tomalok who does a lot of AWS testing
2021-11-12 20:51:21 <minimal> psykose: oops, getting conversations mixed up lol
2021-11-12 20:51:24 <Ariadne> is graviton not SystemReady compliant?
2021-11-12 20:51:25 <psykose> hah
2021-11-12 20:51:32 <psykose> Ariadne: apparently not
2021-11-12 20:51:51 <Ariadne> wow
2021-11-12 20:52:06 <Ariadne> AWS nitro sucks apparently :D
2021-11-12 20:53:38 <minimal> Ariadne: there's too many "standards" for Arm: AMBA, SBSA, SBBR, etc and differing levels within SBSA.
2021-11-12 20:53:59 <minimal> ACPI is part of SBSA according to https://en.wikipedia.org/wiki/Server_Base_System_Architecture
2021-11-12 20:54:00 <alpine-meetbot> [WIKIPEDIA] Server Base System Architecture | "The Server Base System Architecture (SBSA) is a hardware system architecture for servers based on 64-bit ARM processors."
2021-11-12 20:56:38 <Ariadne> yes, they call SBSA SystemReady now
2021-11-12 20:58:29 <Ariadne> minimal: PL061 is for Graviton1
2021-11-12 20:58:34 <Ariadne> minimal: Graviton2 does have ACPI
2021-11-12 20:58:44 <Ariadne> according to an AWS executive
2021-11-12 20:58:48 <Ariadne> i asked on twitter :)
2021-11-12 21:00:33 <minimal> ok, so does seem like Graviton1 was designed before SBSA took off.
2021-11-12 21:02:21 <minimal> Ariadne: so is SBBR now called SystemBootReady? ;-)
2021-11-12 21:02:40 <Ariadne> no idea.
2021-11-12 22:06:10 <shafire> Hi, I opened the firecracker merge request. The tests fail, because it can't find cgroup like cpuset in /proc/mounts. What do I miss here?
2021-11-12 22:07:21 <shafire> Does the test need to run as root?
2021-11-12 22:12:01 <psykose> the aarch64 version doesn't even compile, and i can't see anything about cgroups in the x86_64 one
2021-11-12 22:26:50 <shafire> Why aarch64 doesn't compile is weird, will check that later
2021-11-12 22:27:02 <shafire> there is now a fourth pipeline
2021-11-12 22:27:29 <ikke> fyi, equinix has network issues, so we lost x86_64 CI and all arm based CI and builders
2021-11-12 22:28:33 <psykose> since last hour? :p
2021-11-12 22:28:42 <psykose> unfortunate
2021-11-12 22:29:00 <ikke> 30 minute
2021-11-13 00:30:05 <lonjil> I saw recently that there may be plans to remove packages that stay in testing for too long without moving to community or main, but what exactly is the process for moving a package from testing?
2021-11-13 00:47:51 <Ariadne> you open an MR as the maintainer doing it
2021-11-13 00:51:01 <lonjil> Ah, so you just do so when you as the maintainer of a package think it would be good?
2021-11-13 00:54:41 <shafire> Hi, okay, I fixed the aarch64 for firecracker
2021-11-13 00:55:21 <shafire> A test fails that wants to spawn a thread... is this an issue with docker?
2021-11-13 01:01:44 <Ariadne> lonjil: yes
2021-11-13 01:05:19 <lonjil> Ariadne: alright, thanks.
2021-11-13 06:16:01 <tomalok> mps: checking in...  the PL061 can be m -- we should be enable that module with the bootloaders/kernel command line
2021-11-13 06:21:45 <tomalok> once we i things shiny with the alpine-cloud-images build script and in (at least) parity with alpine-ec2-ami we'll be able to plug in other clouds (and enable this-or-that as necessary)
2021-11-13 06:21:57 <tomalok> s/we i/i get/
2021-11-13 06:21:57 <alpine-meetbot> tomalok meant to say: once i get things shiny with the alpine-cloud-images build script and in (at least) parity with alpine-ec2-ami we'll be able to plug in other clouds (and enable this-or-that as necessary)
2021-11-13 08:13:11 <alandiwix> mps: my laptop keyboard no longer works on 5.12.2
2021-11-13 08:13:45 <alandiwix> were there any changes related?
2021-11-13 08:20:25 <mps> alandiwix: 'wha't is your laptop? arch, keyboard type etc
2021-11-13 08:21:39 <alandiwix> sorry, figured it out, my mdevd init script got messed up
2021-11-13 08:25:31 <alandiwix> hmm, it still doesn't work for couple of seconds after I see the login prompt though
2021-11-13 08:26:18 <alandiwix> but it's perfectly fine after that
2021-11-13 08:32:44 <alandiwix> mps: wireless works, thanks
2021-11-13 08:32:58 <alandiwix> but only 2.4G
2021-11-13 08:33:14 <alandiwix> s/G/GHz
2021-11-13 08:33:14 <alpine-meetbot> alandiwix meant to say: but only 2.4GHz
2021-11-13 08:34:11 <mps> good, it works :)
2021-11-13 08:34:48 <alandiwix> 3 minutes later 5GHz also kicked in
2021-11-13 08:35:17 <alandiwix> hardware is really weird it seems
2021-11-13 08:38:40 <mps> "will commit suicide, it doesn't work" :)
2021-11-13 09:06:09 <alandiwix> it connects to the network, obtains the lease, but I can't even ping the host after that :D
2021-11-13 11:30:57 <PureTryOut> ikke Ariadne: no ABI breaking changes, but minor updates (from semver) which upstream guarantees have no ABI breaking changes are fine still?
2021-11-13 11:37:54 <ikke> PureTryOut: Should be OK. Just make sure to test that everything is working as expected
2021-11-13 11:39:10 <ikke> As a maintainer you can best judge what the impact is
2021-11-13 11:55:49 <PureTryOut> Yeah ofc
2021-11-13 18:53:06 <mps> minimal: are you around?
2021-11-13 18:53:55 <mps> initramfs uses kmod binary and it can load gz and zst compressed modules, busybox can only gziped
2021-11-13 18:54:52 <mps> same kernel apk file built with zstd compressing modules is about 7MB bigger than with gz
2021-11-13 18:55:19 <mps> tested with linux-edge4virt
2021-11-13 18:57:35 <mps> in next 4-5 I will have 'free' machine on which I will continue to testing simpledrm and fb
2021-11-13 18:57:44 <mps> 4-5 days*
2021-11-13 18:59:35 <mps> so for 3.15 looks like we should 'keep' gzip compress for module as is the vmlinuz is already
2021-11-13 19:08:05 <minimal> mps: hi
2021-11-13 19:09:15 <mps> hello, good evening
2021-11-13 19:10:31 <minimal> mps: surprised that gzip is smaller, thought the point of zstd was it would be smaller plus be faster to decompress
2021-11-13 19:11:06 <mps> also I was surprised, expected opposite
2021-11-13 19:12:08 <mps> maybe it is faster, but I don't test speed, alpine boot is fast anyway
2021-11-13 19:19:59 <minimal> a speed improvement is good to have but its a balancing act of speed versus disk space
2021-11-13 19:20:41 <minimal> I guess the "structure" of kernel modules is something that zstd doesn't handle as well as expected
2021-11-13 19:21:35 <minimal> mps: !27432 just submitted
2021-11-13 19:21:55 <minimal> mps: oops, !27423
2021-11-13 19:24:56 <mps> minimal: looks like this patch is not needed because current mkinitfs copies compressed modules (some magic in it?)
2021-11-13 19:26:30 <minimal> mps: its not for copying compressed modules, its for ensuring that firmware is added to initramfs - the code uses "modinfo XYZ | grep firmware" to determine firmware required for each module in initramfs but didn't actually do anything since they were compressed
2021-11-13 19:28:02 <minimal> so, for example, if your DRM kernel module (radeon, i915, amdgpu) needs firmware to function then it wouldn't work - likely to cause some of the reported "boot stops at Loading initramfs" reports
2021-11-13 19:28:06 <mps> minimal: oh sorry, I didn't looked carefully
2021-11-13 19:28:43 <mps> yes, that makes sense
2021-11-13 19:28:46 <ikke> going to restart gitlab in a couple of minutes to upgrade it
2021-11-13 19:29:13 <minimal> without this change when a initramfs contains radeon.ko.zstd then the firmware is missing, with this change it also contains /lib/firmware/radeon/* files
2021-11-13 19:29:30 <valerius> yes, please merge asap
2021-11-13 19:29:37 <mps> minimal: yes, I understand all this
2021-11-13 19:30:45 <mps> not foo.zstd but foo.zst is extension
2021-11-13 19:35:20 <minimal> mps: right, was writing from memory :-)
2021-11-13 19:37:52 <ikke> gitlab has been upgraded
2021-11-13 19:44:22 <maxice8> Ikke: can you try merging this ? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27412
2021-11-13 19:44:55 <ikke> Unable to load the merge request widget. Try reloading the page.  :.
2021-11-13 19:44:57 <ikke> :/
2021-11-13 19:47:42 <maxice8> rip
2021-11-13 19:48:07 <ikke> oof: Error relocating /usr/local/bin/gitaly-git2go-v14: qsort_r: symbol not found
2021-11-13 19:48:55 <ikke> Wasn't that recently added?
2021-11-13 19:49:20 <mps> ikke: yes, I added it to musl, but I think it is only in edge
2021-11-13 19:49:31 <ikke> right, and gitlab is not on edge
2021-11-13 19:49:55 <mps> so, backport it or upgrade to edge
2021-11-13 19:50:32 <ikke> But how can it refer to that symbol if it's not available?
2021-11-13 19:50:59 <mps> it can refer to whatewer
2021-11-13 19:51:30 <ikke> Generally it needs to be defined in a header, not?
2021-11-13 19:51:42 <Hello71> /usr/local?
2021-11-13 19:51:49 <mps> not necesary
2021-11-13 19:51:56 <ikke> Hello71: we do not build it as a package
2021-11-13 19:52:53 <ikke> oooh, I think I know what happened
2021-11-13 19:53:24 <ikke> It's built with golang from edge
2021-11-13 19:53:42 <mps> ah, that explains
2021-11-13 20:16:15 <ikke> Working on it, hold on
2021-11-13 20:16:35 <ikke> 
ACTION makes notes to add tests to verify gitaly is working

2021-11-13 20:47:31 <ikke> maxice8: fixed
2021-11-13 20:47:53 <maxice8> thanks, will merge some stuff later
2021-11-13 20:48:08 <ikke> Let me know if you encounter other issues
2021-11-13 21:36:42 <maxice8> all merges are blocked
2021-11-13 21:42:51 <ikke> trying to figure out what's going on
2021-11-13 21:54:03 <ikke> I have difficulty finding out what's wrong
2021-11-13 22:13:52 <adhawkins> Whoops, think I just broke gitlab...
2021-11-13 22:13:56 <ikke> no
2021-11-13 22:14:03 <adhawkins> Returning a 502. Was working a few moments ago.
2021-11-13 22:14:16 <adhawkins> Ah, back now.
2021-11-13 22:17:34 <adhawkins> Ah, looks like it was being upgraded. Just picked a bad time :)
2021-11-13 22:21:26 <maxice8> says I don't have permission to push code to this project, huh
2021-11-13 22:22:29 <ikke> :/
2021-11-13 22:23:27 <maxice8> can push to alpine/aports with my ssh key though
2021-11-13 22:23:38 <maxice8> just not to other user's forks
2021-11-13 22:28:03 <ikke> You manually pushed some commits?
2021-11-13 22:30:52 <maxice8> yes
2021-11-13 22:42:35 <adhawkins> maxice8: Doesn't that depend on the MR? There's a checkbox when you create an MR to allow people with commit access to add commits to the MR.
2021-11-13 22:42:43 <adhawkins> (I think)
2021-11-13 22:42:53 <maxice8> aports-qa-bot automatically sets that via the MinimumRequiredSettings service
2021-11-13 22:46:58 <adhawkins> Ah ok, my mistake.
2021-11-13 22:48:13 <ikke> Some issues related to the upgrade
2021-11-13 22:48:28 <ikke> But it's too late for me now, I'll have to continue tomorrow
2021-11-14 00:00:17 <andypost[m]> ikke: is there git-lfs used? there's related issue to downgrade it
2021-11-14 00:34:15 <graywolf> If package has no maintainer, what is procedure for "taking over"? Should I just send a patch adding myself as a maintainer? Can I fix it to build as one patch or should that be two separates?
2021-11-14 01:20:38 <PJ[m]> following that question, shouldn't a package without a maintainer be in unmaintained?
2021-11-14 01:24:16 <graywolf> This one is in testing (testing/font-ipa)
2021-11-14 04:11:04 <lzsaver> "Partition id "vfat" is not supported!" is it okay? it's setup-alpine. alpine 3.14.3, UEFI, virtualbox.
2021-11-14 04:12:41 <lzsaver> sys
2021-11-14 04:19:48 <lzsaver> the system boots ok, but I see an error message
2021-11-14 04:20:14 <lzsaver> seems noncritical
2021-11-14 04:21:26 <lzsaver> "fsck.vfat ...
2021-11-14 04:21:26 <lzsaver> Label '' stored in boot sector is not valid.
2021-11-14 04:21:26 <lzsaver> Writing changes."
2021-11-14 04:21:26 <lzsaver> Auto-removing lebel from boot sector.
2021-11-14 04:21:26 <lzsaver> Filesystem was changed
2021-11-14 04:22:12 <lzsaver> I did not try alpine on uefi before. so do not know if it's okay.
2021-11-14 04:30:37 <PJ[m]> should be supported
2021-11-14 04:30:43 <PJ[m]> at least with GRUB
2021-11-14 04:32:45 <lzsaver> yes, system boots without real problems using grub-efi. just strange messages
2021-11-14 04:45:50 <PJ[m]> does that show up dooring boot or `setup-alpine`?
2021-11-14 04:46:41 <PJ[m]> I don't use vbox so can't say if it is happening but I have Hyper-V/VMware hvisors which do not present such message
2021-11-14 05:30:57 <minimal> lzsaver: Alpine works fine with UEFI on Virtualbox, use it all the time. What exact error messages are you seeing?
2021-11-14 05:37:04 <craftyguy> is there a tool to scan for and help merge (with vimdiff or whatever) any apk-new files on a system?
2021-11-14 05:39:47 <craftyguy> ah, update-conf will list them
2021-11-14 07:11:04 <ikke> andypost[m]: We don't actively use git lfs
2021-11-14 09:24:59 <mps> interesting zstd merge for kernel 5.16 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8c109546a19613d323a319d0c921cb1f317e629
2021-11-14 09:26:42 <mps> nice thing is that this will be available in next linux-edge major upgrade, in about two months
2021-11-14 10:05:15 <caskd> What is the part before the ':' supposed to mean in main/u-boot board_configs='' other than subpackage to put it into?
2021-11-14 10:05:56 <caskd> trying to add a new board to the list and i am not sure if i am naming/grouping it correctly
2021-11-14 10:08:26 <mps> caskd: 'class', i.e. usually SoC
2021-11-14 10:09:02 <caskd> all right, i'll go with SoC name then
2021-11-14 10:09:35 <mps> for example 'sunxi:pine64-lts,pinebook,orangepi_3,teres_i,a64-olinuxino,a64-olinuxino-emmc,nanopi_neo2' sunxi subpkg contains all these u-boots
2021-11-14 10:11:41 <mps> SoC:SBC1,SBC2....
2021-11-14 10:12:15 <caskd> i just went with rk3399:rockpro64-rk3399 in my case
2021-11-14 10:13:40 <mps> after ':' comes defconfig for SBC as it is in u-boot configs/ dir
2021-11-14 10:14:55 <caskd> yeah, that is right
2021-11-14 10:15:09 <caskd> was just wondering about the first part, the one after was already clear
2021-11-14 10:15:23 <mps> maybe would be better 'rockchip:rockpro64-rk3399'
2021-11-14 10:15:41 <caskd> indeed
2021-11-14 10:15:46 <caskd> i'll change that
2021-11-14 15:07:26 <ikke> fyi, merging is working again in gitlab
2021-11-14 15:30:30 <psykose> mps: 35% speed increase on zstd kernel which was already fast is impressive :) i had no idea it was that far out of date this whole time in-kernel
2021-11-14 15:30:34 <psykose> exciting update
2021-11-14 15:43:58 <minimal> Hi folks, spotted another compressed kernel-related issue - about to submit MR to fix update-kernel so that firmware is added to modloop
2021-11-14 15:47:10 <minimal> psykose: wondering if this zstd update will improve things for module compression as mps yesterday was saying gz modules are smaller than zstd
2021-11-14 15:49:06 <mps> psykose: this is in linux-next which will be 5.16-rc1 tomorrow. and alpine 3.15 will be released with 5.15 kernel which will be default (-lts) kernel till the end of next year
2021-11-14 15:50:11 <mps> psykose: but 5.16 stable will be released in about two months and it will be upgraded in alpine as linux-edge
2021-11-14 15:54:10 <mps> minimal: I found what is problem with linux-edge on my test with compressed modules
2021-11-14 15:55:02 <mps> mkinitfs for some unknown reason doesn't add kmod to initramfs while it does for -lts
2021-11-14 15:55:46 <mps> but I work in 'slow motion mode' last two days
2021-11-14 15:56:09 <minimal> mps: hmm, am looking at mkinitfs code currently, I'll check if there's some sort of issue triggering that
2021-11-14 15:57:50 <mps> I feel so strange that I don't want to look any code in next few days
2021-11-14 15:58:25 <mps> just read nonsenses called news
2021-11-14 16:00:47 <Hello71> minimal: compressing kernel/modules/initramfs is using userspace command, not kernel, so it doesn't matter
2021-11-14 16:01:16 <mps> Hello71: right
2021-11-14 16:03:53 <minimal> Hello71: true
2021-11-14 16:28:37 <tomalok> mps: finally got around to testing the GPIO_PL061=y...  i am happy to report that 'modprobe gpio_pl061' before attempting to terminate/reboot a t4g instance (Graviton2) successfully results in immediate graceful termination/rebooting.
2021-11-14 16:28:58 <tomalok> i'll see if it works on the previous generation too, in a moment.
2021-11-14 16:32:36 <mps> tomalok: good news
2021-11-14 16:34:53 <tomalok> bam.  a1 (Graviton1) works too. will work that into the cloud images.
2021-11-14 16:36:21 <tomalok> (i should probably also move kernel modules like 'ena' (AWS elastic network adapter) over to just be aws-specific, i doubt the other clouds use that
2021-11-14 16:36:27 <tomalok> )
2021-11-14 16:51:15 <minimal> tomalok: are you using tiny-power-button for the x86/x86_64 AMIs?
2021-11-14 16:52:20 <minimal> tomalok: ariadne indicated that the Graviton2 are supposed to support ACPI poweroff and PL061 was needed only for Graviton1
2021-11-14 16:53:11 <tomalok> tiny-power-button?  is that a different kernel module?
2021-11-14 16:54:06 <tomalok> fwiw, Graviton2 didn't gracefully reboot/terminate until i modprobed gpio_pl061.
2021-11-14 16:54:56 <minimal> with "normal" button kernel module I believe you need to also run acpid whereas with tiny-power-button you don't need acpid (though you do need to add a cmdline entry to ensure its signal gets to init)
2021-11-14 16:55:38 <tomalok> yeah, don't believe this is running acpid, and at present there's no cmdline set up for it
2021-11-14 16:57:01 <minimal> with tiny-power-button loaded I add "tiny_power_button.power_signal=12" to cmdline
2021-11-14 16:57:51 <minimal> tomalok: https://cateee.net/lkddb/web-lkddb/ACPI_TINY_POWER_BUTTON.html
2021-11-14 17:02:24 <tomalok> launched another ... current state acpid is running, pl061 module not loaded ... hit reboot (and wait...)
2021-11-14 17:03:13 <Hello71> minimal: fyi tiny_power_button is blacklisted by default in 3.15
2021-11-14 17:03:38 <Hello71> i guess maybe should write it in release notes
2021-11-14 17:03:44 <minimal> Hello71: yes there was a issue if *both* button and tiny-power-button are loaded so that blacklist was added
2021-11-14 17:04:00 <tomalok> while waiting i do see the tiny_power_button in /lib/modules
2021-11-14 17:05:27 <tomalok> does/did tiny_power_button work for Graviton1?
2021-11-14 17:05:44 <minimal> Hello71: I'm building my own VM/Cloud images so for those I'm blacklisting button and using tiny-power-button instead
2021-11-14 17:06:32 <minimal> tomalok: it will not as G1 doesn't support ACPI, the question is whether G2 supports ACPI in which case it would work there
2021-11-14 17:07:22 <tomalok> i think i'm going to stick with PL061 so that the aws aarch64 image works with both Gravitrons
2021-11-14 17:10:14 <minimal> tomalok: re ENA, yes its AWS specific, there's a different GCE-specific adaptor, and a Azure-specific one too
2021-11-14 17:11:37 <tomalok> with how alpine-cloud-images build tool works, that's all easily configurable...  and in theory, others should be able to use the platform to make their own custom images too.
2021-11-14 17:12:54 <tomalok> (i seem to remember maintaining the ena module apk before it got merged into mainline kernel)
2021-11-14 17:14:33 <minimal> tomalok: in my own script I'm modifying the mkinitfs feature files to only include the Cloud-relevant kernel modules in the initramfs and blacklisting irrelevant modules
2021-11-14 17:18:02 <tomalok> i assemble variant configs based on the config associated with keys for various dimensions (version, arch, firmware, bootstrap, cloud)...  so if somethiing is specific to aws, it gets added to configs/cloud/aws.conf
2021-11-14 17:20:38 <tomalok> although all variant configs are resolved by the build script, --only <dimension-key>.and --skip <dimension-key> ... allows you to focus on just the stuff you're interested in building locally/importing/publishing
2021-11-14 17:22:51 <tomalok> Packer pretty much handles the rest (optionally in parallel), builds locally with qemu, and then post-processor is called for doing the actual import/publishing via whatever cloud plugin applies for that variant
2021-11-14 17:25:30 <tomalok> there's kernel_modules, kernel_optiosn, and initfs_features maps in the configs that allow things to be set/unset in any dimension
2021-11-14 18:41:01 <lzsaver> > PJ[m]: does that show up dooring boot or `setup-alpine`?
2021-11-14 18:41:01 <lzsaver> "Partition id "vfat" is not supported!" - setup-alpine
2021-11-14 18:41:01 <lzsaver> "Label '' stored in boot sector is not valid." - openrc boot
2021-11-14 18:41:48 <lzsaver> minimal, messages above
2021-11-14 18:42:16 <minimal> lzsaver: was this partitioned/installed via setup-alpine/setup-disk?
2021-11-14 18:42:22 <lzsaver> setup-alpine
2021-11-14 18:42:36 <lzsaver> after booting iso in efi mode
2021-11-14 18:43:19 <lzsaver> after that system boots okay. just those messages. I don't know if it's okay and works as expected
2021-11-14 18:50:00 <minimal> what does "parted /dev/sda print" or "fdisk -l /dev/sda" or "blkid" show?
2021-11-14 19:21:36 <lzsaver> minimal, http://pastebin.calculate-linux.org/en/show/a478a821b979abc779e65e1d42a5e09a
2021-11-14 19:23:19 <minimal> lzsaver: that looks ok
2021-11-14 19:24:16 <minimal> lzsaver: and "blkid" output to see the filesystem labels
2021-11-14 19:27:33 <lzsaver> it was sfdisk actually. here's busybox fdisk http://pastebin.calculate-linux.org/en/show/022f8c1546813eff14cde44872fd2d1a
2021-11-14 19:27:44 <lzsaver> here's blkid http://pastebin.calculate-linux.org/en/show/235271
2021-11-14 19:34:20 <minimal> lzsaver: do seems you don't have a label on the EFI partition, which sort of explains the  "Label '' stored in boot sector is not valid." message
2021-11-14 19:36:01 <minimal> lzsaver: which part of the boot sequence does that message appear during?
2021-11-14 19:36:26 <lzsaver> minimal, lsblk does not show any label too http://pastebin.calculate-linux.org/en/show/7341d5e2a33439ca9ed4f0dbc50269e3
2021-11-14 19:38:37 <minimal> I've never seen that message before and the "stored in boot sector" doesn't make sense to me, so need to narrow down which part of the boot sequence its occurring during
2021-11-14 19:39:46 <lzsaver> I think it was near "Checking local filesystems ..."
2021-11-14 19:40:27 <lzsaver> it does not show this message on second reboot. it was shown on first boot only
2021-11-14 19:40:38 <mps> lsblk -f
2021-11-14 19:43:46 <minimal> lzsaver: do you have dosfstools package installed?
2021-11-14 19:44:51 <lzsaver> mps, https://pastebin.com/i5K2GELj
2021-11-14 19:45:49 <lzsaver> minimal, yes, I can see it in the world file
2021-11-14 19:47:11 <mps> ok, my uefi machine doesn't have label for vfat boot partition but it boots fine
2021-11-14 19:47:17 <minimal> lzsaver: ok, so /usr/sbin/fsck.fat and fsck.vfat exist, I thought that might of been a problem
2021-11-14 19:48:27 <lzsaver> yes, I see them in /usr/sbin
2021-11-14 19:49:03 <lzsaver> probably fsck did show that message
2021-11-14 19:49:24 <lzsaver> on first boot
2021-11-14 19:52:58 <minimal> yeah that's what I'm thinking, there was something "wrong" which was fixed on 1st boot. It still doesn't make sense though
2021-11-14 19:56:00 <lzsaver> it is alpine 3.14.3, a current release. no idea what can be wrong
2021-11-14 19:56:31 <lzsaver> I may try to reproduce it on old releases later
2021-11-14 20:01:54 <mps> yesterday I tested 3.14.3 x86_64 iso with qemu, all works fine
2021-11-14 20:02:20 <mps> in uefi boot mode
2021-11-14 20:03:32 <mps> hmm, wrong, not uefi mode
2021-11-14 20:03:35 <lzsaver> did you do an installation?
2021-11-14 20:03:36 <lzsaver> ah
2021-11-14 20:03:59 <lzsaver> it was in uefi, "sys" installation
2021-11-14 20:04:20 <mps> I always prefer syslinux wherever I can use it
2021-11-14 20:04:38 <lzsaver> me too. I just got new laptop. it just have no "legacy boot" option
2021-11-14 20:04:46 <lzsaver> only uefi is available
2021-11-14 20:05:40 <lzsaver> so i'm experimenting in virtualbox before I'll do an actual installation
2021-11-14 20:05:40 <mps> I know that aarc64 install in uefi mode works fine
2021-11-14 20:07:11 <mps> and I don't have roseta for macos aarch64 to test x86_64 on it
2021-11-14 20:07:11 <lzsaver> btw. can I replace openwrt with alpine on my router?
2021-11-14 20:07:32 <mps> lzsaver: what cpu is it
2021-11-14 20:07:37 <lzsaver> let me check
2021-11-14 20:07:58 <mps> better to ask for arch, sorry
2021-11-14 20:08:56 <minimal> lzsaver: I build/rebuild Alpine UEFI Virtualbox VMs on almost a daily basis and they work fine for me :-)
2021-11-14 20:08:57 <mps> I'm running alpine on some routers for about 3-4 years
2021-11-14 20:09:19 <mps> before that I user openwrt
2021-11-14 20:09:29 <mps> use*
2021-11-14 20:09:42 <mps> used* (hrrmm)
2021-11-14 20:10:17 <lzsaver> Qualcomm Atheros IPQ4018 / IPQ4019
2021-11-14 20:10:34 <mps> mips?
2021-11-14 20:12:07 <mps> arm cortex 7
2021-11-14 20:12:29 <lzsaver> arm I think
2021-11-14 20:12:40 <mps> lzsaver: you are lucky, alpine could work on it
2021-11-14 20:12:46 <lzsaver> cool
2021-11-14 20:13:05 <mps> not sure is it enabled in kernel
2021-11-14 20:23:20 <lzsaver> ncopa, thunderbolt-net module works on linux-edge. today I successfully ping'ed another machine over thunderbolt on alpine edge. I had to add thunderbolt0 to /etc/network/interfaces. I'll add logs to #13187 tomorrow
2021-11-14 20:24:32 <graywolf> Was the bot syncing mailing list (aports) to gitlab disabled? There seems to be nothing created from the mailing list in the past ~week
2021-11-14 20:24:59 <ikke> no, it has not been disabled
2021-11-14 20:25:11 <ikke> ddevault: any idea why no MRs are created anymore?
2021-11-15 06:52:16 <ddevault> will investigate
2021-11-15 07:50:27 <ncopa> good morning!
2021-11-15 07:53:37 <mps> good morning
2021-11-15 08:06:20 <ikke> o/
2021-11-15 08:13:13 <fcolista> _0/
2021-11-15 08:30:25 <mps> ncopa: linux-virt config for aarch64 have '# CONFIG_COMPAT_32BIT_TIME is not set'. it must be =y
2021-11-15 08:34:18 <ncopa> ok
2021-11-15 08:34:21 <ncopa> thanks
2021-11-15 08:41:39 <fcolista> Does the position of secfixes in the APKBUILD matters?
2021-11-15 08:41:39 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27430.patch
2021-11-15 08:42:00 <fcolista> is this acceptable or we want taht the secfixes section is putted after builddir?
2021-11-15 08:43:15 <ikke> There is a defacto standard
2021-11-15 08:43:48 <fcolista> yeah..i'd like to point this out with the MR author
2021-11-15 08:44:30 <fcolista> but it's just guessed by looking at the other secfixes entries in the other APKBUILDs right?
2021-11-15 08:46:23 <Ariadne> as long as the structured data is correct, it does not really "matter" where it is
2021-11-15 08:47:08 <fcolista> I know..it's jsut as ikke stated a sort of coding standard that we want to keep
2021-11-15 09:05:28 <ikke> ncopa: regarding lxc.cgroup.cpuset.cpus = 80-159
2021-11-15 09:05:30 <ikke> lxc.cgroup.cpuset.mems = 1
2021-11-15 09:05:34 <ikke> sorry
2021-11-15 09:05:59 <ikke> regarding community/rtl8821ce-lts, I have rtl8821ce-src now
2021-11-15 09:06:06 <ikke> which is an akms package
2021-11-15 09:06:15 <ikke> issue is that I have no way to test it actually works
2021-11-15 09:06:44 <mps> ikke: it builds, is that enough?
2021-11-15 09:06:55 <ikke> I suppose
2021-11-15 09:07:11 <mps> then it is ok, imo
2021-11-15 09:07:53 <mps> if someone uses it and it doesn't work we will/should get report
2021-11-15 09:09:41 <mps> qemu 6.2 planning https://wiki.qemu.org/Planning/6.2
2021-11-15 09:09:49 <ikke> Not unless they are now using rtl8821ce-lts and have no idea rtl8821ce-src exists, nor do they feel the need to use it because there is alreayd a pre-compiled package tam
2021-11-15 09:10:14 <ikke> atm*
2021-11-15 09:10:52 <mps> 2021-12-07 Release; or tag rc4 if needed , will this be too late for 3.15 release?
2021-11-15 09:11:16 <mps> ikke: if you remove it they will notice for sure :)
2021-11-15 09:11:52 <ikke> mps: I would say yes, I would not do significant upgrades anymore
2021-11-15 09:13:00 <mps> ikke: and few latest kernels improved rtl drivers, maybe this is not needed as separate pkg at all
2021-11-15 09:13:13 <ikke> mps: even better
2021-11-15 09:15:08 <mps> I have one usb rtl wifi which didn't worked good with 5.10 but after 5.13 it works fine, though with some small quirks
2021-11-15 09:42:52 <ikke> Funny, spdx just released v3.15
2021-11-15 09:55:35 <ddevault> got the gitlab<>lists bot fixed
2021-11-15 09:55:45 <ddevault> but the emails which were dropped were dropped, and will need to be resent
2021-11-15 09:55:53 <ddevault> or just reviewed on the list
2021-11-15 09:57:15 <ncopa> ikke: i think rtl8821ce-lts does not hurt currently. I think we can keep it for v3.15 at least
2021-11-15 09:57:26 <ikke> ncopa: ok
2021-11-15 09:57:47 <ikke> ddevault: ok, good to know
2021-11-15 09:57:52 <ikke> What was the issue?
2021-11-15 09:58:08 <ncopa> there was zero issues with it for the 5.15 release
2021-11-15 09:58:23 <ddevault> for the curious, the sr.ht packages init.d scripts had the port assignments copy/pasted from each other rather than using the ports assigned for each service in the git repo for the longest time, and was only recently corrected. This changed the local bind port of the services, which I updated in nginx but not in the config used for services to communicate with one another.
2021-11-15 09:58:33 <ddevault> this caused dispatch to be unable to reach the lists API to fetch patchset details
2021-11-15 09:59:12 <ddevault> didn't affect sr.ht upstream because we go through the same external address for inter-service communication, whereas alpine has a network configuration which prevents this and uses a different address
2021-11-15 09:59:47 <mps> ncopa: I agree about rtl8821ce-lts for 3.15, but after this should be reviewed imo
2021-11-15 10:06:05 <graywolf> Resending the patches is easy enough, but it should probably be also stated on the list directly. Not everyone is in the irc.
2021-11-15 10:06:28 <ddevault> I also set up exceptions on the alpine sr.ht stack to be forwarded to me, so issues will be detected earlier
2021-11-15 10:06:33 <ddevault> not sure why that wasn't set up before
2021-11-15 10:46:22 <omni> were humans involved?
2021-11-15 10:47:34 <ddevault> yes
2021-11-15 10:47:36 <ddevault> that explains it, eh
2021-11-15 10:47:47 <omni> ;)
2021-11-15 10:48:57 <mps> humans makes mistakes sure, but technology makes a lot bigger errors
2021-11-15 11:10:13 <ncopa> seems like there was no rc1 x86* releases
2021-11-15 11:13:22 <ikke> ncopa: hmm
2021-11-15 11:13:28 <ikke> the builders just ignored it?
2021-11-15 11:15:26 <meph> where's jirutka?
2021-11-15 11:15:37 <ikke> He's not on irc
2021-11-15 11:15:41 <djt> ugh
2021-11-15 11:15:54 <ikke> He does respond on gitlab
2021-11-15 11:19:29 <djt_> I'm offering to take maintainership of Kea since I'm working at ISC these days
2021-11-15 11:19:39 <djt_> I guess BIND too since it looks to have no maintainer
2021-11-15 11:21:27 <ikke> Yes, would be nice if someone could maintain bind
2021-11-15 11:23:43 <djt_> hmmm
2021-11-15 11:24:55 <djt_> kinda surprised bind is at the latest version despite being unmaintained
2021-11-15 11:25:10 <djt_> ah yes, a secfix
2021-11-15 11:25:35 <djt_> +1
2021-11-15 11:25:50 <ikke> Yes, we do make sure security updates are done
2021-11-15 11:38:23 <ncopa> djt_: would be great! thanks
2021-11-15 11:38:42 <djt_> should I just submit an MR?
2021-11-15 11:38:47 <ncopa> yes please
2021-11-15 11:38:49 <djt_> ok
2021-11-15 11:38:52 <djt_> thank you
2021-11-15 14:10:39 <minimal> can someone please consider merging !27423 and !27444. These should be in the Alpine 3.15 release as they impact since the introduction of compressed kernel modules
2021-11-15 14:13:58 <minimal> ncopa: ^^^
2021-11-15 14:41:22 <ncopa> minimal: looks good. will have a look in at bit
2021-11-15 14:41:35 <ncopa> my computer has locked up due to some nbd device hangs
2021-11-15 14:41:43 <ncopa> `sync`hangs
2021-11-15 14:45:38 <minimal> ncopa: no problem. It might be worth do an "audit" of aport packages in general to check for any scripts that can't handle compressed kernel modules...
2021-11-15 15:29:05 <ncopa> i broke my desktop while working on kernels. had to rescue it
2021-11-15 15:29:27 <ncopa> i'm also working on disk/by-id in mdev.conf today
2021-11-15 15:29:35 <ncopa> should fix some of the zfs issues we have
2021-11-15 17:04:22 <Nulo> Hey, iwd keeps crashing for me. How can I get a backtrace or similar to send to developers?
2021-11-15 17:04:41 <Nulo> Oh sorry, this might be more appropriate on #alpine-linux right?
2021-11-15 17:05:17 <ikke> yea
2021-11-15 17:12:48 <ikke> Nulo: you can try to add rc_ulimit="-c unlimited" to /etc/conf.d/iwd and restart iwd
2021-11-15 17:15:02 <ikke> You probably also want to set the core dump location: sysctl -w kernel.core_pattern=/tmp/core-%e-%s-%u-%g-%p-%t
2021-11-15 17:22:49 <mps> Nuloo: /usr/libexec/iwd -d
2021-11-15 17:34:36 <omni> !27467
2021-11-15 17:59:50 <ikke> Anything against !27473?
2021-11-15 18:27:09 <ncopa> ikke: no objectin
2021-11-15 18:27:16 <ikke> 👍
2021-11-15 18:28:05 <ncopa> i have been waiting for the builders to become idle so I can ta rc2 and troubleshoot why the x86* releases failed, but I guess I'll wait til tomorrow
2021-11-15 18:28:40 <ikke> gmm
2021-11-15 18:53:09 <minimal> ncopa: I see you merged one of my "compressed kernel module" fixes but wouldn't you also want !27444 in rc2?
2021-11-15 20:57:37 <ncopa> Will look at it tomorrow. Did you create an mr for alpine-conf as well?
2021-11-15 21:07:58 <psykose> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/34
2021-11-15 21:57:04 <omni> ah, a new message in early boot
2021-11-15 21:58:13 <omni> * Mounting root: Enter passphrase for /dev/nvme0n1: cat: read error: No such device or address
2021-11-15 21:58:24 <omni> but I can still enter passphrase and boot
2021-11-15 21:59:29 <omni> then the usual
2021-11-15 22:00:01 <omni> cannot import 'zpool': pool already exists
2021-11-15 22:00:19 <omni> cannot import 'zpool': a pool with that name already exists
2021-11-15 22:00:36 <omni> but that's not critical either
2021-11-15 22:02:14 <omni> also later in the openrc boot process: no pools available to import
2021-11-15 22:02:25 <dalias> that sounds terrifying
2021-11-15 22:03:23 <omni> I've been thinking to look into these, but haven't had any issues and so haven't prioritized
2021-11-15 22:09:46 <omni> but there are two issues recently introduced, I tried to describe them the other day when I was too tired, that are a bit disruptive
2021-11-15 22:11:01 <omni> on is that I now, when doing a warm reboot, have to remove the USB device I'm booting from and re-insert it to be able to boot from it
2021-11-15 22:12:18 <omni> and, again, I've tried with another one of different brand and the issue persists, but not when rolling back "a bit" (around when 5.15 lts was introduced)
2021-11-15 22:32:13 <clandmeter> ive updated all lxc container configs on our arm builder. could be that some of our devs lost their personal settings, if so let me know and i can restore them.
2021-11-15 22:55:18 <ddevault> can someone with the appropriate gitlab permissions assign this to me: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13196
2021-11-15 22:59:03 <ddevault> thanks clandmeter 
2021-11-15 22:59:13 <clandmeter> np
2021-11-15 23:33:31 <omni> ok, so I've done 8-9 reboots since I described the above issue, now *twice* I didn't have to remove the device or cold boot the machine for it to find the device bootable, what's going on??
2021-11-15 23:33:48 <omni> I was more comfortable when it was failing in a consistent manner
2021-11-15 23:34:03 <Ganonk> hello all
2021-11-15 23:34:13 <Ganonk> someone can help me
2021-11-16 00:34:20 <midi[m]> https://dontasktoask.com/
2021-11-16 01:39:04 <JonasTripps> https://www.youtube.com/watch?v=ykT_g0-bgZo&t=44s
2021-11-16 06:33:16 <ncopa> good morning
2021-11-16 06:33:39 <lzsaver> morning
2021-11-16 06:33:46 <ncopa> omni: I think it was my mdev.conf "fixes" for persistent storage that introduced it
2021-11-16 06:34:10 <ncopa> omni: how is your setup? nvme with zfs root? how many disks?
2021-11-16 07:28:04 <ncopa> anyone else having issues with busybox-initscripts-4.0?
2021-11-16 07:42:09 <mps> latest ncurses have memleak, MR with fixed version is coming
2021-11-16 07:54:07 <ddevault> does anyone know off the top of their head how we're meant to build python packages which only have a pyproject.toml file (and no setup.py)
2021-11-16 07:54:45 <ddevault> ah, found pyproject2setuppy
2021-11-16 07:54:57 <ddevault> petition to revoke the programming licenses of anyone who tries to make another python packaging system
2021-11-16 07:55:48 <mercenary> s/python //
2021-11-16 07:58:44 <ncopa> omni: do you have a way for me to reproduce your issue?
2021-11-16 08:02:11 <ikke> ddevault: From what I understood, the idea is to use pip install
2021-11-16 08:02:37 <ddevault> i.e. the idea is to give the finger to linux distros
2021-11-16 08:03:08 <ddevault> great for shoving a bunch of crap into docker though
2021-11-16 08:03:43 <ikke> ddevault: not necessarily
2021-11-16 08:03:51 <ikke> pip install takes --prefix --root etc
2021-11-16 08:04:23 <ddevault> oh? well, that's an improvement, at least
2021-11-16 08:06:23 <omni> ncopa: I'm looking at the peristent-storage script now..
2021-11-16 08:06:44 <ncopa> i dont think it is the root cause
2021-11-16 08:07:24 <ncopa> the persistent-storage change introduced the `cat: read error: No such device or address`
2021-11-16 08:07:36 <omni> yeah
2021-11-16 08:07:56 <ncopa> but the only thing it should cause is a missing /dev/disk/by-id/ symlink
2021-11-16 08:08:01 <ncopa> which was not created at all before
2021-11-16 08:08:23 <ncopa> so what I think is that you have some other issue, which is caused by some sort of timing
2021-11-16 08:08:48 <ikke> ddevault: the idea is that pip is a front-end, which can use several back-ends
2021-11-16 08:08:52 <ncopa> I'm adding 2>/dev/null to all the cats
2021-11-16 08:11:04 <omni> ncopa: I have a somewhat special setup, I have /boot with syslinux on a usb drive and my (single) nvme drive is unpartitioned with luks and a zpool
2021-11-16 08:11:12 <ddevault> unilaterally adding 2>/dev/null seems like a bad idea
2021-11-16 08:12:25 <omni> actually, /boot is a mdmirror of the usb drive and a zvol in the later unlocked zpool :B
2021-11-16 08:13:51 <ncopa> ddevault: thats what I originally thought as well but the "No such device or address" error indicates that the file exists but cannot be read
2021-11-16 08:13:56 <omni> and I occationally rotate the usb drive in the mirror, often after a kernel upgrade, in case it would go bad
2021-11-16 08:14:25 <ddevault> do you have a handy link to the change which causes this?
2021-11-16 08:15:35 <omni> I can still rescue with a regular alpine image and restore the boot device from the zvol, but I'm glad when I don't have to
2021-11-16 08:15:44 <ncopa> ddevault: 7141b493a223fdb910ed90439cc044a9d5fe8c46
2021-11-16 08:16:13 <ncopa> https://git.alpinelinux.org/aports/tree/main/busybox-initscripts/persistent-storage
2021-11-16 08:16:24 <ddevault> perhaps test for readability with -r?
2021-11-16 08:16:35 <ncopa> its not a permission error
2021-11-16 08:16:47 <ddevault> hm, right
2021-11-16 08:16:49 <ncopa> im thinking i should drop the if [ -e ...  test
2021-11-16 08:17:06 <ncopa> and unconditionally do partition=$(cat .... 2>/dev/null)
2021-11-16 08:17:12 <ncopa> and test if its zero or not
2021-11-16 08:17:28 <ddevault> then repeat the cat without 2>/dev/null?
2021-11-16 08:17:37 <ddevault> err, no
2021-11-16 08:17:44 <ddevault> I'm just concerned that this will eat legitimate errors
2021-11-16 08:18:02 <ddevault> I don't have a good solution to offer, though
2021-11-16 08:18:14 <ncopa> it will eat legitimate errors
2021-11-16 08:18:23 <ncopa> but it think that is what we want
2021-11-16 08:18:26 <ddevault> might be worth quickly reading through the kernel bits to see what other errors are possible and make a judgement call on whether or not they'll be important
2021-11-16 08:18:50 <omni> what cat is it that fail, though? cat /sys/class/block/$MDEV/partition?
2021-11-16 08:18:58 <ncopa> i have no idea
2021-11-16 08:19:09 <ncopa> but there is a theoretical race condition there too
2021-11-16 08:19:30 <ddevault> maybe this should be a C program instead of a shell script
2021-11-16 08:19:45 <ncopa> the file may exist and disappear after the -e test and before the cat
2021-11-16 08:19:57 <ncopa> so better not test if it exists, just cat it and ignore errors
2021-11-16 08:20:44 <ncopa> i just wanted avoid the fork/exec if it didnt exist
2021-11-16 08:27:51 <omni> brb
2021-11-16 08:29:06 <ncopa> aha! i can do < /path/to/possibly/non-existing-file
2021-11-16 08:33:07 <ddevault> nice to see the python party line being that linux distros are the inconvenient thing which bootstraps your docker container and by no means should their needs be taken into account
2021-11-16 08:37:46 <ncopa> thats not unique to python
2021-11-16 08:37:55 <ncopa> thats all languages that has a package manager
2021-11-16 08:38:12 <omni> something around wwid perhaps?
2021-11-16 08:38:13 <ddevault> python is especially egregious imo, and getting worse
2021-11-16 08:38:39 <ddevault> they have like 17 different package managers, all broken in their own stupid ways, and we have to come up with workarounds for every one
2021-11-16 08:43:01 <ncopa> omni: I'm about to push this: https://tpaste.us/zlma
2021-11-16 08:43:11 <ncopa> i don't think it will solve your setup though
2021-11-16 08:43:21 <ncopa> it will just hide the cat error
2021-11-16 08:57:58 <omni> haha, nah, my setup is an unfinished project I began early last year, but had to take a job, and haven't gotten back to that part of it
2021-11-16 08:59:16 <omni> it's been working fine as my daily driver since, even though it's a bit quirky
2021-11-16 08:59:37 <omni> otoh I came from years of tormenting myself with qubes :D
2021-11-16 09:03:32 <ddevault> does anyone have anything to add to this https://paste.sr.ht/~sircmpwn/88a91de553acdb15cbdf1b7602f9b4b6be0522db
2021-11-16 09:08:36 <omni> ncopa: would you like me to try it?
2021-11-16 09:16:45 <omni> I'll do it in a minute
2021-11-16 09:25:01 <ikke> ddevault: maybe look at / mention the recent PEPs that are involved
2021-11-16 09:25:33 <ddevault> just added that:
2021-11-16 09:25:35 <ddevault> >P.S. PEP-517 and 518 are a start, but are very disappointing in how little they address distro problems. These PEPs are designed to tolerate the proliferation of build systems, which is exactly what needs to stop. Python ought to stop trying to avoid hurting anyone’s feelings and pick one. Maybe their decision-making framework prevents this, if so, the framework needs to be
2021-11-16 09:25:37 <ddevault> changed.
2021-11-16 09:38:42 <ddevault> https://drewdevault.com/2021/11/16/Python-stop-screwing-distros-over.html
2021-11-16 09:55:52 <omni> ncopa: worked for me
2021-11-16 11:16:35 <ncopa> omni: so all is good?
2021-11-16 11:32:57 <nmeum> is there any easy way to make package() depend on all subpackages? depends="$subpackages" may not neccessairly work due to the ":$splitfunc" syntax
2021-11-16 11:39:18 <nmeum> d855652e460f1b9ff335214100f55acc5bd1cd42 this seems to work for now :S
2021-11-16 12:07:30 <krystianch> ncopa: Cool that you merged alpine-conf!33 it's my first contribution of this size. You asked about why util-linux is needed. I think there may be a bug in busybox's swapon. I'm going to create minimal repro steps and investigate.
2021-11-16 12:08:44 <ncopa> krystianch: I removed util-linux for now
2021-11-16 12:08:59 <ncopa> krystianch: nice work!
2021-11-16 12:09:18 <ncopa> im gonna push alpine-cone-3.13.0_rc1 to edge now
2021-11-16 12:09:26 <krystianch> Without util-linux you can't install crypt+lvm+sys and then sys or crypt+sys. It errors out on swapon.
2021-11-16 12:09:48 <omni> ncopa: well, I don't get the cat error message at least
2021-11-16 12:09:57 <ncopa> I haven't really tested anything, so things might be pretty broken
2021-11-16 12:10:00 <ikke> alpine-cone?
2021-11-16 12:10:07 <ncopa> alpine-conf 
2021-11-16 12:10:36 <ncopa> what's the problem with busybox swapon?
2021-11-16 12:11:19 <omni> ncopa: the error message from the persistant-storage script I saw is gone
2021-11-16 12:13:00 <ncopa> good
2021-11-16 12:14:54 <krystianch> ncopa: after installing crypt+lvm+sys and then crypt+sys or just sys busybox "swapon -a" says "UUID=...: no such file or directory"; in such case blkid shows incorrect type "crypto_LUKS" on the swap partition instead of "swap"
2021-11-16 12:16:54 <krystianch> this happens only if crypt+lvm+sys was installed earlier and installing lvm+sys makes this go back to normal
2021-11-16 12:18:43 <ncopa> but does it happen with crypt but without lvm?
2021-11-16 12:19:11 <ncopa> I think we can install util-linux when crypt + lvm is used
2021-11-16 12:19:12 <ncopa> or
2021-11-16 12:19:39 <ncopa> we can use the lvm device instead of UUID
2021-11-16 12:19:48 <ncopa> in fstab
2021-11-16 12:21:27 <krystianch> it happens only after crypt+lvm+sys, it's like crypt+lvm+sys corrupts somehting that I didn't yet investigate
2021-11-16 12:22:26 <krystianch> good idea with lvm device instead of UUID, I can implement and test this
2021-11-16 12:24:40 <krystianch> but note that crypt+lvm+sys works fine, it's just when you install crypt+lvm+sys and THEN (crypt+)sys, there is a problem
2021-11-16 12:50:15 <krystianch> aah, sorry, I misunderstood, replacing UUID with LVM device won't work as this issue is present when not using lvm, so cryptsys or just sys
2021-11-16 12:58:31 <ncopa> i mean use /dev/foo/swap something
2021-11-16 12:58:34 <ncopa> instead of UUID
2021-11-16 13:06:47 <krystianch> should I open an issue for this? I think it's unlikely that someone will install crypt lvm sys and then install again but without lvm, but maybe this should be documented as an issue
2021-11-16 13:07:00 <ncopa> yes please
2021-11-16 13:09:07 <ncopa> ok, something happened to me with setup-alpine with encrypted disk. it hangs after "* Loading hardware drivers"
2021-11-16 13:13:54 <krystianch> hmm, I tested every scenario under qemu/kvm
2021-11-16 13:18:19 <ncopa> i think the kernel args are not set as expected
2021-11-16 13:18:26 <ncopa> boot options
2021-11-16 13:19:20 <ncopa> ah i think i found it
2021-11-16 13:20:04 <ncopa> https://tpaste.us/XKz1
2021-11-16 13:22:58 <ikke> ah, kernel_opts are overwritten
2021-11-16 13:23:13 <ncopa> yup, that fixed it
2021-11-16 13:23:46 <ncopa> it did not really hang, it enabled framebuffer with does not work with qemu -curses
2021-11-16 13:24:48 <ncopa> ok, this is not bad. not bad at all
2021-11-16 13:24:50 <ncopa> very nice work
2021-11-16 13:29:56 <ncopa> btw, to quickly test setup-disk, you can run: setup-alpine -q && setup-disk
2021-11-16 13:32:06 <valerius> the changes to mkinitfs are working great
2021-11-16 13:32:15 <ncopa> nice to hear!
2021-11-16 13:32:48 <ncopa> krystianch: im pretty impressed how well this crypt root thing works
2021-11-16 13:33:21 <ncopa> support for encrypted root should be mentioned in release notes
2021-11-16 13:34:58 <krystianch> thanks ncopa, very glad to hear that, I'll add it to release notes
2021-11-16 13:36:51 <krystianch> overwriting kernel opts was embarrassing, sorry, did not catch that in time
2021-11-16 13:37:25 <ncopa> no, no... that is normal for this kind of changes
2021-11-16 13:37:48 <ncopa> there are a few other minor detail we can improve
2021-11-16 13:38:09 <ncopa> like the prompt going over to new line
2021-11-16 13:38:30 <ncopa> if you type 'yes' instead of 'YES' you get thrown out in the dark
2021-11-16 13:41:52 <krystianch> could you please point me where the problem is with the prompt going to new line?
2021-11-16 13:44:18 <nmeum> I assume this is the cryptsetup luksFormat prompt? luksFormat will exit with exit status 1 if you don't type YES and this will likely cause the entire setup_crypt() to fail
2021-11-16 13:48:48 <krystianch> ah, ok, i get it
2021-11-16 13:51:35 <nmeum> might be possible to differentiate prompt confirmation failures and actual errors using the luksFormat exit code, but I haven't looked into it
2021-11-16 13:58:02 <krystianch> if I type lowercase yes into luksFormat prompt currently I get "Operation aborted.". would a more detailed message be desired?
2021-11-16 14:13:36 <ncopa> I think we can run it in a loop til it succeeds
2021-11-16 14:17:06 <ikke> But the user cannot abort it then?
2021-11-16 14:17:34 <krystianch> I was also thinking about cryptsetup open, if user types wrong password 3 times they can just restart setup-disk to format and try opening again
2021-11-16 14:20:24 <krystianch> ikke: right, cryptsetup luksFormat exits with 1 on ctrl+c and on incorrect "YES", so it would be hard to differentiate
2021-11-16 14:20:58 <Hello71> it would be better to disable the prompt
2021-11-16 14:21:00 <Hello71> but, uh...
2021-11-16 14:21:09 <Hello71> i guess setup-disk already wipes your drive
2021-11-16 14:21:32 <Hello71> now it can be cryptographically erased (the first few MB anyways)
2021-11-16 14:25:11 <krystianch> the simple solution would be to leave it like it is (or maybe add a helpful message) and let user restart setup-disk if `luksFormat` or `open` fails
2021-11-16 14:25:49 <Hello71> well disabling the prompt is easy
2021-11-16 14:27:11 <ncopa> maybe we should just disable the prompt
2021-11-16 14:27:29 <ncopa> we already ask for confirmation when deleting the disk
2021-11-16 14:28:55 <ncopa> other minor thing: if you select lvm first, and then crypt, it will do the same as crypt first and lvm after
2021-11-16 14:29:16 <ncopa> which i guess makes sense
2021-11-16 14:29:42 <ncopa> but we should maybe not suggest crypt *after* lvm is picked?
2021-11-16 14:32:38 <krystianch> I'm curious if users would think that crypt+lvm result in LVM on LUKS and lvm+crypt would result in LUKS on LVM
2021-11-16 14:32:53 <krystianch> which is ofc not the case
2021-11-16 14:33:04 <ncopa> that is what I thought
2021-11-16 14:34:04 <krystianch> right, so maybe we should not suggest and block enabling crypt after lvm was enabled
2021-11-16 14:34:11 <krystianch> as you said
2021-11-16 14:34:20 <ncopa> that is what i thought
2021-11-16 14:34:33 <ncopa> not a big deal, but nicer
2021-11-16 14:34:44 <krystianch> right, I agree
2021-11-16 14:35:42 <ncopa> i had no issues with swap without util-linux
2021-11-16 14:35:49 <ncopa> i think it just works
2021-11-16 14:36:39 <krystianch> were you not able to reproduce  #10491?
2021-11-16 14:37:51 <ncopa> correct. i was not able to reproduce https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10491
2021-11-16 14:39:12 <krystianch> hm, let me carefuly verify these instructions again
2021-11-16 14:39:37 <mps> few days ago I tested kernels with compressed modules, mkinitfs add kmod binary to initramfs when building -lts but not for -edge
2021-11-16 14:40:07 <mps> anyone have idea what could be cause
2021-11-16 14:41:49 <ncopa> do you have kmod in /etc/mkinitfs/features.d/base.files?
2021-11-16 14:42:20 <mps> i did test on the same machine, so I think it is there
2021-11-16 14:42:46 <mps> installed both kernels on it
2021-11-16 14:44:10 <mps> if it add kmod for -lts it is very strange it doesn't for -edge
2021-11-16 14:44:19 <ncopa> if /sbin/modprobe is in /etc/mkinitfs/features.d/base.files, then I have no clue why it didnt add it for -edge
2021-11-16 14:44:31 <ncopa> yes, its very strange
2021-11-16 14:44:50 <mps> ok, will look further when find some time
2021-11-16 14:47:39 <krystianch> this is very weird, I can reliably reproduce the swap issue in qemu on a 3.14 CD upgraded to edge using instructions in https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10491
2021-11-16 15:01:19 <minimal> ncopa: actually with recent switch of compressed modules back to gzip we don't need kmod anymore, correct? so this could be reverted
2021-11-16 15:04:20 <minimal> krystianch: can you clarify your reproduction steps? you installed 3.14 from CD and then upgraded it to Edge and then did what?
2021-11-16 15:05:05 <minimal> krystianch: I have a suspicion of what happened
2021-11-16 15:06:32 <krystianch> one more thing: adding -q to luksFormat gets rid of the YES prompt and asks for pasphrase only once. in my opinion this is fine as setup_crypt will ask for password twice (format, open) instead of three times; would that be ok or should we add -y to verify passphrase during format?
2021-11-16 15:07:55 <krystianch> minimal: boot 3.14 standard CD, run setup-alpine -e until setup-disk, upgrade to edge, do steps from here: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10491
2021-11-16 15:08:01 <ncopa> minimal: correct
2021-11-16 15:09:27 <minimal> krystianch: you are running setup-disk again after Edge upgrade? or only "swapon -a"?
2021-11-16 15:10:38 <krystianch> i'm running setup-disk twice (once `crypt+lvm+sys`, then `sys`), both times after edge upgrade
2021-11-16 15:11:16 <ncopa> im using a 3.15/edge iso
2021-11-16 15:11:30 <minimal> krystianch: ok, after Edge upgrade, before you do anything else, check if the util-linux-misc package is installed
2021-11-16 15:13:23 <Hello71> ncopa: you're sure that gzip module compression decreases modloop size compared to no module compression? i would expect it to increase modloop size
2021-11-16 15:13:44 <krystianch> minimal: it's not installed
2021-11-16 15:13:45 <ncopa> Hello71: im pretty sure, and im not surprised
2021-11-16 15:14:14 <Hello71> why? xz is much stronger than gzip, but if you xz a gzip it should remain at gzip size
2021-11-16 15:14:19 <ncopa> i think it is because squashfs is compressed with xz, and xz does better job when compressing gz files than zstd files
2021-11-16 15:14:45 <minimal> krystianch: ok, is util-linux is installed by Alpine 3.14.x? if so then your upgrade commands may need to be tweaked
2021-11-16 15:15:02 <ncopa> oh, maybe I misunderstood, i thought you ompares zstd modules with gz modules
2021-11-16 15:17:30 <krystianch> minimal: before upgrade (on 3.14 CD) util-linux is also not installed
2021-11-16 15:17:57 <ncopa> i dont think its related previosly installed util-linux
2021-11-16 15:18:09 <ncopa> might be you setill use old busybox swapon even avter upgrade
2021-11-16 15:18:29 <ncopa> try run /bin/sh after upgrade and before running setup-alpine
2021-11-16 15:18:36 <ncopa> to make sure you use the updated busybox
2021-11-16 15:18:39 <minimal> krystianch: ok, so once you install util-linux on Edge you're likely using the swapon from util-linux-misc rather than Busybox
2021-11-16 15:19:03 <Hello71> (cat *.gz)|xz smaller than (cat *.zst)|xz is still a little surprising but not that much. it's quite surprising if (cat *.gz)|xz is smaller than (cat *.ko)|xz
2021-11-16 15:19:14 <Hello71> but there is a complication with squashfs block size here
2021-11-16 15:19:48 <minimal> ncopa: I was just checking regarding util-linux as, from Edge/3.15 onwards, swapon is in the new util-linux-misc subpackage whereas in 3.14 its in util-linux (though upgrade might have been missing "--available" option)
2021-11-16 15:20:08 <krystianch> minimal: the thing is the bug occurs only when using busybox swapon, so it makes sense
2021-11-16 15:20:40 <krystianch> the workaround is to replace busybox swapon with one from util-linux
2021-11-16 15:21:30 <ncopa> i dont have the error when booting from edge iso
2021-11-16 15:21:35 <ncopa> that i create myself
2021-11-16 15:26:24 <minimal> krystianch: one though - when you run setup-disk in Edge its recreating the swap partition and so its UUID will change, if you chck the /etc/fstab file afterwards it may possibly have either (1) one entry for swap with the *OLD* UUID value or (2) two entries for the old and the new UUIDs.
2021-11-16 15:26:30 <minimal> s/though/thought/
2021-11-16 15:26:30 <alpine-meetbot> minimal meant to say: krystianch: one thought - when you run setup-disk in Edge its recreating the swap partition and so its UUID will change, if you chck the /etc/fstab file afterwards it may possibly have either (1) one entry for swap with the *OLD* UUID value or (2) two entries for the old and the new UUIDs.
2021-11-16 15:26:51 <ncopa> right, that makes sense
2021-11-16 15:27:08 <ncopa> if swap is recreated the fstab entry should be replaced with new UUID
2021-11-16 15:27:36 <minimal> krystianch: your error "swapon: UUID=589...: No such file or directory" means it have found an entry in /etc/fstab with UUID "589.."
2021-11-16 15:31:26 <ncopa> i think im ready for rc2 now
2021-11-16 15:32:24 <krystianch> right, but what is weird that this issue can't be reproduced (1) on edge iso or (2) with non-busybox swapon
2021-11-16 15:38:18 <ncopa> tilix fails to build everywhere. some linking error
2021-11-16 15:38:22 <ncopa> no idea what it is about
2021-11-16 15:38:27 <minimal> krystianch: I'm sure this is solvable, its just a case of how much time and effort it will take - you could start by peppering the setup_swap_dev function from https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L967 onwards with "echo", "cat" or other debugging stuff to check if the UUID in /etc/fstab matches the UUID of the actual swap partition
2021-11-16 15:39:03 <ikke> tilix is currently blocking some builders
2021-11-16 15:39:19 <ncopa> im disabling tilix for now
2021-11-16 15:39:24 <ikke> right
2021-11-16 15:40:15 <ncopa> im pretty sure that alpine 3.15 will work with cryptroot, without util-linux
2021-11-16 15:40:25 <ncopa> you normally don upgrade and then reinstall the disk
2021-11-16 15:41:29 <ncopa> are there many other big packages in the build pipe? i'd like to tag rc2
2021-11-16 15:42:34 <ikke> https://tpaste.us/lymg 
2021-11-16 15:43:08 <ikke> that's x86_64
2021-11-16 15:45:05 <ikke> 6 packages on aarch64
2021-11-16 15:51:29 <krystianch> minimal: I'm not sure if it is worth it. in 3.14 there is no cryptroot option and in 3.15 everything works fine, thanks for help though!
2021-11-16 15:52:23 <ncopa> how do we prevent cryptsetup luksFormat prompt?
2021-11-16 15:52:56 <krystianch> i submitted a MR to add -q flag
2021-11-16 15:55:03 <krystianch> it disables the YES prompt and password verification so that setup_crypt asks for it twice instead of three times
2021-11-16 15:55:58 <minimal> ncopa: I use "-q" in my script for luksFormat
2021-11-16 15:56:45 <minimal> I also pipe the passphrase to cryptsetup
2021-11-16 16:01:05 <ncopa> i think asking for password three times might be a good thing
2021-11-16 16:01:42 <krystianch> if so, we can add -y in addition for -q
2021-11-16 16:01:47 <ncopa> the two first times you verify that that you didnt mistype, the third time you get a reminder
2021-11-16 16:02:13 <ncopa> yeah, i think it makes sense with -y
2021-11-16 16:02:20 <ncopa> maybe use long opts while at it
2021-11-16 16:02:49 <ncopa> --batch-mode --verify-passphrase
2021-11-16 16:02:54 <ncopa> makes the script more readable
2021-11-16 16:04:31 <krystianch> sure, I'll create another MR
2021-11-16 16:04:34 <ncopa> Hello71: btw, i added a "fix" that always install gnu wget when http_proxy is used
2021-11-16 16:04:54 <Hello71> not really good solution. it will break those whose proxy actually works properly
2021-11-16 16:05:05 <ncopa> gnu wget?
2021-11-16 16:05:12 <ncopa> gnu wget does not work?
2021-11-16 16:05:49 <Hello71> busybox wget unconditionally uses original method, gnu wget unconditionally uses HTTP CONNECT
2021-11-16 16:06:22 <Hello71> so if you install gnu wget it will fix those proxies which require HTTP CONNECT and break those proxies which require actual http proxying
2021-11-16 16:06:34 <ncopa> i would guess that gnu wget behavior is what users expect?
2021-11-16 16:07:28 <Hello71> well, afaik there is no proxy "standard", but we can look at e.g. curl, which interprets --proxy http://proxy as real http proxy, and requires --proxytunnel for HTTP CONNECT
2021-11-16 16:07:42 <Hello71> i tried to find what browsers do but couldn't locate
2021-11-16 16:09:41 <ncopa> i guess the other option would be to test, something like:  wget -q -O /dev/null https://dl-cdn.alpinelinux.org || apk add wget
2021-11-16 16:10:47 <Hello71> yes, i thought of that too. but you should also test if it works with gnu wget, otherwise you installed it for nothing
2021-11-16 16:11:40 <Hello71> that's easier than the way i thought of though, which is to do the HTTP CONNECT manually instead of installing gnu wget. the benefit of my way is that you don't need to install gnu wget, but the downside is more code complexity. i think installing gnu wget for testing is not too bad though
2021-11-16 16:12:29 <Hello71> if we are already bundling it on the iso, and for people not using iso, we can assume that if you want to configure a proxy then you probably (although arguably not necessarily) have internet access to download wget
2021-11-16 16:13:52 <ncopa> we do bundle gnu wget on the iso nowdays
2021-11-16 16:14:27 <Hello71> right but only for this purpose i think
2021-11-16 16:15:40 <ncopa> yup
2021-11-16 16:15:58 <ncopa> other option is to bundle curl and stop use wget at all
2021-11-16 16:16:13 <ncopa> btw, i wonder how libfetch and apk does
2021-11-16 16:17:43 <ncopa> this cryptsetup thingy is very nice now
2021-11-16 16:19:15 <krystianch> thanks! this means a lot, also thanks for today's collaboration, I have to go now, but will come by later when I fix the crypt+lvm vs lvm+crypt thingy
2021-11-16 16:19:44 <ncopa> super! thank you!
2021-11-16 16:20:25 <ncopa> im tagging rc2 now
2021-11-16 16:20:34 <Hello71> ok so i'm *pretty* sure that firefox always uses HTTP CONNECT for https proxy
2021-11-16 16:20:50 <Hello71> which imo is dumb and you should use SOCKS instead but meh
2021-11-16 16:21:45 <Hello71> ah, i actually checked apk libfetch already but forgot. looks like it uses HTTP CONNECT also
2021-11-16 16:22:25 <Hello71> so in conclusion i think despite it being dumb, installing gnu wget when https proxy is requested is probably the "best" solution
2021-11-16 16:22:29 <ncopa> sounds like it might be worth "fix" busybox wget behaviro
2021-11-16 16:22:39 <ncopa> yeah, thats what i figured
2021-11-16 16:23:26 <Hello71> possibly but who wants to work on busybox :p
2021-11-16 16:23:48 <Hello71> i already have TODO of fixing busybox mount without -t or modprobe
2021-11-16 16:25:11 <skarnet> tbh I'd rather work on bb than on GNU code, especially GNU wget
2021-11-16 16:26:12 <Hello71> yes but gnu wget already properly does the wrong thing, we need to make busybox also do the wrong thing
2021-11-16 16:26:20 <Hello71> but yes i agree with you
2021-11-16 16:26:27 <Hello71> allegedly wget2 is supposed to be better though
2021-11-16 16:27:09 <skarnet> GNU code often does the wrong thing properly :D
2021-11-16 16:27:41 <ncopa> lol
2021-11-16 16:29:17 <ncopa> bah
2021-11-16 16:29:26 <ncopa> unrar: unable to select package (or its dependencies)
2021-11-16 16:29:35 <ncopa> someone moved unrar to community i guess
2021-11-16 16:30:20 <ncopa> no... it moved to non-free
2021-11-16 16:30:35 <Hello71> yes, i already submitted mr to fix that
2021-11-16 16:30:43 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/26293
2021-11-16 16:31:25 <ikke> Was it just in the image so that it was available, or was it used for something?
2021-11-16 16:31:26 <ncopa> completely went under my radar
2021-11-16 16:31:35 <ikke> 7f875ea1e58f5b6feb5dcf2bdf026847f7c1cbb7
2021-11-16 16:31:40 <ncopa> only included in the extended iso
2021-11-16 16:31:58 <Hello71> also, upon investigation, i was wrong. curl --proxytunnel is not required for HTTP CONNECT when the final protocol is HTTPS, it is intended for FTP (and i guess also HTTP)
2021-11-16 16:32:01 <ncopa> i think it was originally added as a nice to ahve tool
2021-11-16 16:32:44 <Hello71> bsdtar would be better
2021-11-16 16:32:57 <Hello71> not sure if it is already pulled in by something
2021-11-16 16:40:57 <ncopa> its not
2021-11-16 16:42:56 <Hello71> huh, i'm surprised that libarchive-tools is bigger than libarchive
2021-11-16 16:43:10 <ncopa> do we really need bsdtar when we have gnu tar and xz and all?
2021-11-16 16:43:21 <ncopa> why include duplicate tools
2021-11-16 16:43:27 <Hello71> well if someone wants to unpack a rar for some reason
2021-11-16 16:43:34 <Hello71> and also doesn't have internet access
2021-11-16 16:43:39 <Hello71> it seems pretty unlikely to me
2021-11-16 16:43:44 <ncopa> yeah
2021-11-16 16:43:53 <ncopa> rar is rarely used nowdays i guess
2021-11-16 16:44:10 <skarnet> that's why it's called "rar"
2021-11-16 16:44:12 <Hello71> it is still very popular for warez
2021-11-16 16:44:27 <ncopa> but not for linux tools i guess?
2021-11-16 16:44:33 <Hello71> skarnet: on the other hand everybody uses "com", it's short for "common"
2021-11-16 16:44:34 <ncopa> linux rescue disk
2021-11-16 16:44:45 <skarnet> Hello71: exactly!
2021-11-16 16:44:47 <ikke> :D
2021-11-16 16:45:58 <ncopa> we have duplicate tools parted and sfdisk
2021-11-16 16:46:00 <Hello71> ncopa: well a lot of the extended stuff doesn't really make that much sense, e.g. why lxc but not docker, why cyrus-sasl, nsd but no bind, etc
2021-11-16 16:46:37 <Hello71> i think some people like parted but i have no idea why
2021-11-16 16:47:42 <Hello71> links is listed twice
2021-11-16 16:48:23 <omni> could the terraform ad be removed from the gitlab web interface? nothing against terraform, but I've seen the ad and thought I'd only see it once
2021-11-16 16:48:51 <ncopa> Hello71: indeed
2021-11-16 16:49:02 <ncopa> i wonder if we should add f2fs tools
2021-11-16 16:49:18 <ncopa> exfat
2021-11-16 16:49:36 <Hello71> i think for 3.16 we should send email asking people what they use/want in extended
2021-11-16 16:50:42 <ikke> Hello71: answer: everything :P
2021-11-16 16:51:23 <omni> or remove things and re-add them in a point release if people complain?
2021-11-16 16:51:35 <ncopa> yeah, i like that
2021-11-16 16:51:40 <ncopa> im removing haserl
2021-11-16 16:51:48 <ncopa> replacing lua5.3 with lua5.4
2021-11-16 16:52:14 <omni> https://xkcd.com/1172/
2021-11-16 16:52:15 <alpine-meetbot> Workflow | Alt-text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
2021-11-16 16:53:42 <ikke> omni: :)
2021-11-16 16:54:39 <Hello71> isn't haserl needed for awall or something
2021-11-16 16:55:10 <Hello71> acf
2021-11-16 16:58:18 <omni> and squark, with a broken url
2021-11-16 17:01:13 <ncopa> haserl will be pulled in if something else depends on it
2021-11-16 17:01:34 <mps> parted is good for scripting
2021-11-16 17:01:35 <Hello71> right, i mean is it an optional requirement
2021-11-16 17:01:41 <Hello71> mps: why not sfdisk?
2021-11-16 17:01:57 <omni> ah, not removing from main
2021-11-16 17:02:07 <mps> Hello71: afaik parted is better
2021-11-16 17:02:31 <mps> also I vote for f2fs-tools
2021-11-16 17:02:32 <donoban> Hi, it seems that py3-aiorpcX was updated to last version which breaks electrum (the only package that requires it) and upstream doesn't want to fix it yet https://github.com/spesmilo/electrum/issues/7446
2021-11-16 17:03:20 <donoban> how could I downgrade it?
2021-11-16 17:03:21 <mps> f2fs is very good for flash/mmc/ssd/nvme
2021-11-16 17:03:38 <Hello71> it's advertised that way but is it actually
2021-11-16 17:04:09 <mps> last few years I only use f2fs everywhere
2021-11-16 17:04:16 <Hello71> i think putting it on extended makes sense though
2021-11-16 17:04:59 <minimal> don't we still have the "issue" with f2fs for rootfs that when fsck is run against it mounted ro it doesn't like it
2021-11-16 17:05:15 <mps> I think it should be in setup-disk as choice
2021-11-16 17:05:47 <ncopa> im dropping lftp and email
2021-11-16 17:05:56 <ncopa> who uses ftp or email nowdays
2021-11-16 17:07:57 <omni> and you can use busybox wget for ftp, no?
2021-11-16 17:08:08 <nmeum> yes
2021-11-16 17:08:12 <ncopa> yeah, and we also ship curl and gnu wget
2021-11-16 17:08:36 <ncopa> wireguard-tools might be useful though
2021-11-16 17:08:44 <Hello71> technically curl can also be used as email client
2021-11-16 17:09:00 <Hello71> it has pop3, imap, and smtp
2021-11-16 17:09:11 <mps> WG-tools? where?
2021-11-16 17:09:28 <ncopa> also dropping cciss_vol_status. i think it is no longer supported by kernel
2021-11-16 17:09:43 <ncopa> wg-tools on the alpine-extended iso image
2021-11-16 17:09:52 <mps> aha, ok
2021-11-16 17:10:04 <ncopa> also adding f2fs-tools
2021-11-16 17:10:12 <Hello71> if you are fiddling with img presets then can you merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23651
2021-11-16 17:10:32 <Hello71> !23651
2021-11-16 17:11:10 <lzsaver> still no x86 / x86_64 iso files?
2021-11-16 17:11:16 <omni> mps: !27367 comments from river developer in description
2021-11-16 17:11:42 <mps> Hello71: bb ntpclient, chrony and openntpd. all three?
2021-11-16 17:11:57 <Hello71> well if they are offered in setup-ntp then they should be usable
2021-11-16 17:12:22 <Hello71> otherwise fix setup-ntp to not offer it if you cannot install it
2021-11-16 17:12:25 <mps> omni: really don't have time to examine this for now
2021-11-16 17:13:04 <Hello71> or fix setup-alpine to call setup-ntp after. i think it could use busybox ntpdate first, then get mirrors, then setup-ntp
2021-11-16 17:13:23 <Hello71> but imo easier just to add openntpd considering it is only like 200k or something
2021-11-16 17:13:41 <ncopa> im adding openntpd
2021-11-16 17:13:47 <ncopa> but i think it was broken?
2021-11-16 17:14:14 <Hello71> if you want to shrink standard image i think lowest fruit now are increasing modloop block size and adding kernel subpackages
2021-11-16 17:14:27 <mps> I didn't used openntpd for few years (5-10) and all I remember with it were problems
2021-11-16 17:14:52 <Hello71> i don't use openntpd either but if setup-ntp offers it then it should at least be able to install it
2021-11-16 17:15:05 <nmeum> I think it should work
2021-11-16 17:15:09 <Hello71> if you think openntpd is broken and people shouldn't use it then remove it from options
2021-11-16 17:15:10 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/9635#note_147097
2021-11-16 17:15:21 <ncopa> i think we should fix it
2021-11-16 17:15:27 <Hello71> huh, i thought that was about nntp
2021-11-16 17:15:57 <ncopa> and we should probably use openntpd as the default
2021-11-16 17:16:00 <mps> :)
2021-11-16 17:16:08 <ncopa> would be nice to kick out chrony which is alot bigger
2021-11-16 17:16:32 <ikke> noooo :'(
2021-11-16 17:16:33 <mps> chrony is bigger but better
2021-11-16 17:16:55 <ncopa> ok. lets keep both then :)
2021-11-16 17:17:01 <ncopa> but lets fix openntpd
2021-11-16 17:17:04 <Hello71> i think it is reasonable idea to rewrite setup-alpine to use ntpdate to get rough time and then move setup-ntp after setup-apkrepos
2021-11-16 17:17:08 <Hello71> (where it was before)
2021-11-16 17:17:46 <ncopa> yeah
2021-11-16 17:17:47 <Hello71> then we can keep chrony as setup-ntp option but not bundled on iso
2021-11-16 17:17:52 <ncopa> makes sense
2021-11-16 17:17:53 <lzsaver> is not busybox ntpd good enough?
2021-11-16 17:18:04 <ncopa> for many use cases it is
2021-11-16 17:18:10 <mps> lzsaver: no
2021-11-16 17:18:19 <Hello71> chrony is more accurate, keeps time when computer is off, supports many more features...
2021-11-16 17:18:31 <Hello71> also i think it uses less power
2021-11-16 17:18:36 <ncopa> i think there was some issue last time i tried it, it would  not block til time was set
2021-11-16 17:18:38 <lzsaver> but busybox is fast. the service loads much faster
2021-11-16 17:19:05 <ncopa> it starts the service, goes on and fix the time in the background later
2021-11-16 17:19:12 <lzsaver> chrony takes more time to load on system boot
2021-11-16 17:19:31 <Hello71> that's because it's doing fundamentally different work
2021-11-16 17:19:35 <mps> lzsaver: this can be changed in config
2021-11-16 17:19:35 <nmeum> if you don't wont chrony to block until time is set there is an option for that in /etc/conf.d/chrony
2021-11-16 17:19:36 <lzsaver> ah okay
2021-11-16 17:19:38 <ncopa> if time is off, wget will fail with busybox ntp due to certificate errors
2021-11-16 17:19:41 <Hello71> it's like saying apk update is better because it is faster than apk upgrade
2021-11-16 17:20:06 <lzsaver> thanks for info
2021-11-16 17:20:24 <ncopa> but i kinda like the idea of running ntpdate after network from setup-alpine
2021-11-16 17:21:11 <mps> is the ntpate secure?
2021-11-16 17:21:22 <Hello71> secure against what
2021-11-16 17:21:47 <mps> iirc I read last year something about possibilites to fake it
2021-11-16 17:22:54 <ncopa> its probably not secure
2021-11-16 17:23:27 <nmeum> ntp is generally a very bad protocol in that regard, that's why openntpd (for example) offers to extract additional constraints via TLS
2021-11-16 17:23:28 <lzsaver> ncopa, is ntpdate available on alpine? I did not see it in packages
2021-11-16 17:23:42 <nmeum> there is also NTS (network time security) but busybox ntp doesn't support that iirc
2021-11-16 17:23:54 <mps> nmeum: right
2021-11-16 17:23:57 <skarnet> tired: ntpd
2021-11-16 17:24:15 <skarnet> wired: while true ; do ntpdate ; sleep 14400 ; done
2021-11-16 17:24:30 <skarnet> that's laaaargely accurate enough for most machines
2021-11-16 17:24:40 <skarnet> (of course that doesn't apply if you need to serve a LAN)
2021-11-16 17:25:13 <lzsaver> skarnet, just put a ntpdate call in /etc/periodic
2021-11-16 17:25:58 <skarnet> lzsaver: I wrote this in a language everyone understands, implementation details are left to the user, and really smart people use a supervised service for that. :P
2021-11-16 17:26:13 <mps> :)
2021-11-16 17:26:21 <lzsaver> sure :)
2021-11-16 17:28:55 <ncopa> skarnet: thats basically sntpc
2021-11-16 17:29:17 <Hello71> systemd-timesyncd
2021-11-16 17:29:19 <skarnet> is that how the cool kids call it these days
2021-11-16 17:29:21 <omni> chrony does nts
2021-11-16 17:29:43 <skarnet> ncopa: s6-sntpclock or bust ;)
2021-11-16 17:30:04 <ncopa> where did sntpc go?
2021-11-16 17:30:10 <ncopa> its gone upstream
2021-11-16 17:30:51 <ncopa> i implemented sntpc for use for linux-vserver on windows hyper-v (or the thing before hyper-v)
2021-11-16 17:31:27 <ncopa> i added a flag to prevent it so make clock jump backwards, which actually happened
2021-11-16 17:32:31 <ncopa> ok seems like builder is rsync'ing _rc3
2021-11-16 17:32:36 <ncopa> we have a release candidate
2021-11-16 17:34:00 <omni> shampandje
2021-11-16 17:34:11 <ncopa> we should test the -rpi images
2021-11-16 17:34:13 <ncopa> i havent tested them
2021-11-16 17:34:27 <ncopa> i think there was some issues with wifi in 5.15.1 kernel
2021-11-16 17:34:54 <ncopa> wifi stopped working after a while
2021-11-16 17:37:49 <ikke> I don't have a PI with built-in wifi sadly
2021-11-16 17:44:06 <ncopa> fcolista: do you think you can help with adding alpine 3.15 to osinfo-db?
2021-11-16 17:46:52 <artok> I could kick in upgrade for rpi's
2021-11-16 17:46:53 <fcolista> ncopa, sure. I've all the stuff ready
2021-11-16 17:46:58 <fcolista> waiting for the official release
2021-11-16 17:47:13 <fcolista> :)
2021-11-16 17:54:18 <ncopa> but it would be nice to test it with release candidates...
2021-11-16 17:54:51 <ncopa> never mind. its not that important
2021-11-16 17:55:30 <ncopa> ok. im gonna call it a day. Thank you everyone for the _rc3. great work has been done!
2021-11-16 17:55:33 <artok> ncopa: want me to test rc installer or just hit new packages to running ?
2021-11-16 17:55:38 <Hello71> i have rpi zero w, can do quick check
2021-11-16 17:55:48 <ncopa> artok: testing both would be nice
2021-11-16 17:56:03 <artok> will do, report tomorrow =)
2021-11-16 17:56:11 <artok> (rpi4 and rpi3b+
2021-11-16 17:56:11 <ncopa> i think grub and efi boot may need some more polishing
2021-11-16 17:56:29 <ncopa> it works but gives lots of scary and misleading messages during install
2021-11-16 17:57:01 <ncopa> it says something like: install finished. no errors found. and then the progressbar from apk-tools starts moving for 30 seconds
2021-11-16 17:57:07 <ncopa> which is kinda weird :)
2021-11-16 18:23:56 <mps> uhm, nearly forgot to upgrade linux-tools to 5.15 for 3.15
2021-11-16 18:32:39 <mps> what about rootless modeset for xorg servers? it works on my box and I have branch in repo.
2021-11-16 18:36:20 <mps> ncopa: ^
2021-11-16 19:25:38 <nmeum> mps: how did you do it?
2021-11-16 19:35:52 <mps> nmeum: added patch
2021-11-16 19:36:28 <mps> I'll create draft MR now so you (and all) can see
2021-11-16 19:37:01 <nmeum> that would be great, ty
2021-11-16 19:38:13 <mps> !27499
2021-11-16 19:38:55 <mps> patch is already in some distros
2021-11-16 19:52:31 <ncopa> would be great with rootless modesetting
2021-11-16 19:53:04 <ncopa> I got some report that alpine does not boot in VMware on Mac if there are more than 3G ram something
2021-11-16 19:53:13 <ncopa> it boots if there are less
2021-11-16 19:53:28 <ncopa> and after install you can increase RAM
2021-11-16 19:54:11 <ncopa> anybody has wmvare that can help investigate what is going on?  I suspect there is some automatic setting which enables EFI or similar?
2021-11-16 19:55:59 <mps> this must be macos/vmware combo issue, I run alpine on macos in qemu with 6GB ram
2021-11-16 19:56:47 <mps> ncopa: I could merge rootless modeseting now if no one have objections
2021-11-16 19:57:12 <mps> or remove Draft and left it to you ;)
2021-11-16 19:57:48 <mps> I didn't noticed any problem using it two days nowe
2021-11-16 19:58:02 <mps> now*
2021-11-16 20:05:55 <Hello71> ncopa: longstanding issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/8476
2021-11-16 20:08:35 <mps> caskd: I'll merge rockchip  u-boot MR, hope you tested it. doesn't look problematic
2021-11-16 20:08:42 <caskd> oh
2021-11-16 20:08:45 <caskd> i will test it tommorow
2021-11-16 20:08:49 <caskd> should be fine though
2021-11-16 20:08:51 <caskd> ^^'
2021-11-16 20:09:07 <caskd> you can wait for my confirmation if that's wanted
2021-11-16 20:09:42 <mps> too late, merged
2021-11-16 20:10:47 <caskd> welp
2021-11-16 20:10:58 <caskd> let's hope upstream tested then
2021-11-16 20:11:10 <mps> yes
2021-11-16 20:11:30 <Hello71> actually now that i think about it, #8476 is probably related to #12325
2021-11-16 20:11:48 <mps> it is not big issue if it doesn't work now, if it fails we can fix it later
2021-11-16 20:12:13 <Hello71> memory hot-add... maybe balloon device is bumping pci device number or something...
2021-11-16 20:12:58 <mps> Hello71: uh, I remember 5.14 or 5.15 had issue with build lsilogic driver, not sure if it is fixed now
2021-11-16 20:13:25 <Hello71> well this is three years old so probably not related to 5.15
2021-11-16 20:13:38 <mps> hmm, good then
2021-11-16 20:14:05 <mps> but you reminded me to look at lsilogic driver status now
2021-11-16 22:06:02 <bpwoods> I found a small issue with the installer script, were is a good place to post it?
2021-11-16 22:07:20 <ikke> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
2021-11-16 22:07:58 <mps> nmeum: I took patch for xorg-server from crux distto, but I'm tired now to search it again. probably will add comment to MR tomorrow
2021-11-16 22:08:16 <bpwoods> Thanks ikke!
2021-11-16 22:08:50 <mps> (actually too much wine for serious comments :) )
2021-11-16 22:09:01 <mps> valerius: ^ :)
2021-11-16 22:18:10 <mps> https://github.com/CarbsLinux/repository/blob/master/xorg/xorg-server/patches/rootless_modesetting.patch
2021-11-16 22:21:03 <Hello71> i still don't understand why this patch is necessary. isn't it supposed to work automatically upstream
2021-11-16 22:23:56 <mps> I think there are some corner cases where it is needed, though I can't make these cases to test
2021-11-16 22:24:29 <mps> only what I know is that it works without issues on my machine
2021-11-16 23:29:36 <idkrn> Are there any plans to add a hardened kernel to Alpine?
2021-11-16 23:35:08 <idkrn> or perhaps a guide to hardening the kernel?
2021-11-16 23:37:29 <psykose> what is a 'hardened kernel'
2021-11-16 23:40:38 <idkrn> A kernel focused on security
2021-11-16 23:40:53 <idkrn> as opposed to the standard linux kernel
2021-11-17 02:33:57 <kpcyrd> this one I think: https://archlinux.org/packages/extra/x86_64/linux-hardened/
2021-11-17 07:19:44 <mps> good morning
2021-11-17 07:20:09 <mps> what about !25043 for 3.15 release
2021-11-17 07:31:09 <ncopa> mps: have you addressed the comments?
2021-11-17 07:33:36 <mps> ncopa: no, I'm not versed in cmake and because that MR is a draft
2021-11-17 07:34:13 <ncopa> so its not finished? I guess we need to finish it before we can merge it?
2021-11-17 07:34:17 <psykose> think mps is more asking if there's still time to work on it to get in, or if instead not worth effort and defer to another date
2021-11-17 07:34:42 <mps> and upstream is unreachable over irc so I didn't talked with them
2021-11-17 07:34:52 <ncopa> yeah, sure, i think it would be good to have it included, but we will not hold the release for another month
2021-11-17 07:35:15 <ncopa> but if someone can clean it up and finish it before next week, that would be great
2021-11-17 07:35:26 <ncopa> or is the question if I can do it?
2021-11-17 07:36:17 <mps> anyone who knows good these are welcomed to make it for release
2021-11-17 07:36:53 <mps> or create new MR
2021-11-17 07:37:05 <mps> and better one
2021-11-17 07:37:25 <mps> s/and/or/
2021-11-17 07:37:25 <alpine-meetbot> mps meant to say: or better one
2021-11-17 07:40:06 <ncopa> it needs to be rebased
2021-11-17 07:40:48 <mps> it is 0.104.1 version actually
2021-11-17 07:41:05 <mps> didn't rename branch
2021-11-17 07:47:55 <ncopa> mps: I have rebased it for you, sorted the makedepends, cleaned up # build() {
2021-11-17 07:48:10 <ncopa> i ran out of time and pushed it, but it atleast address some of the feedback
2021-11-17 07:48:26 <ncopa> can you please look over it and s\reolved the threads of the htings that I solved for you?
2021-11-17 07:52:21 <mps> i will try in a few hours, but can't promise I will make it 'pretty'
2021-11-17 07:55:45 <clandmeter> i cannot reproduce the fennel issue
2021-11-17 07:56:15 <ncopa> ok i resolvec the issues in the MR. now there are only 4 left
2021-11-17 07:56:27 <clandmeter> heh
2021-11-17 07:56:51 <clandmeter> kunkku: i think there is a small issue with rootbld
2021-11-17 07:56:57 <clandmeter> or im holding it wrong
2021-11-17 07:58:43 <nmeum> the fennel thing is because check is disabled
2021-11-17 07:58:53 <nmeum> fennel.lua is a prerequsite of the test target but not otherwise build
2021-11-17 07:59:04 <nmeum> I can fix it in a sec
2021-11-17 08:00:19 <clandmeter> ah ok, i didnt investigate it deeply as i noticed rootbld has an issue. looking if i can fix it.
2021-11-17 08:01:39 <nmeum> what kind of rootbld issue?
2021-11-17 08:02:38 <clandmeter> if you run it with a different arch, it creates the index for system arch it seems.
2021-11-17 08:03:23 <nmeum> fennel build should be fixed
2021-11-17 08:05:55 <psykose> the 1.0.0 tag has `build: fennel fennel.lua` in the makefile though
2021-11-17 08:07:14 <nmeum> yeah but the apkbuild dosen't invoke make build
2021-11-17 08:08:21 <clandmeter> yup holding it wrong :)
2021-11-17 08:08:34 <psykose> ah, yes
2021-11-17 08:09:31 <clandmeter> noticed CBUILD_ARCH and used that instead of just CBUILD
2021-11-17 09:03:37 <smcavoy> Hello, could someone take a look at !27518 ? It is needed for Ansible to work properly, it needs to be included with 3.15 (assuming the 4.x version of ansible is also in 3.15)
2021-11-17 09:07:02 <ikke> Whatever is in edge will be part of 3.15 until the release
2021-11-17 10:02:51 <krystianch> ncopa: would you take a look at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/38 ? it's about what we discussed yesterday: the order of lvm and luks
2021-11-17 10:49:57 <mps> is it possible to pull changes back from MR on gitlab to local branch
2021-11-17 10:50:20 <mps> branch from which MR created
2021-11-17 10:51:14 <ikke> You can fetch the branch from gitlab and fast-forward or reset your local branch to that
2021-11-17 10:52:03 <mps> do you know for any example
2021-11-17 10:52:16 <ikke> Is it an MR you created?
2021-11-17 10:52:21 <mps> yes
2021-11-17 10:52:35 <ikke> Do you have local changes committed to that branch you need to keep?
2021-11-17 10:53:08 <mps> no, ncopa added changes to MR and I want to pull them to local branch to test
2021-11-17 10:53:30 <mps> I have original branch
2021-11-17 10:53:35 <ikke> checkout that branch
2021-11-17 10:53:39 <ikke> run git fetch <remote>
2021-11-17 10:53:52 <mps> aha, lets try
2021-11-17 10:55:10 <mps> hmm, looks like it worked, lets see
2021-11-17 10:55:43 <ikke> Not yet
2021-11-17 10:55:50 <ikke> That just updated the remote tracking branch
2021-11-17 10:56:51 <mps> yes, I see nothing is changed locally
2021-11-17 10:57:17 <ikke> if you do not have any uncommitted changes: git reset --hard @{upstream}
2021-11-17 10:58:36 <mps> 'upstream' is?
2021-11-17 10:58:38 <psykose> if the changes are added to the branch you made an mr from i.e. mps/aports -> alpine/aports and the changes got added to the former you can just git pull
2021-11-17 10:59:45 <mps> uh, complicated. will remove branch and fetch complete MR
2021-11-17 11:01:21 <psykose> the mr /is/ your branch in this case, fetching the 'complete mr' is just pulling your own branch that you are already on
2021-11-17 11:01:28 <ncopa> mps: i cleaned up clamav and pushed it. i also needed an upstream patch for parallel build race condition
2021-11-17 11:01:33 <psykose> you can remove it and readd it of course, but it's the same thing as just pulling it
2021-11-17 11:04:04 <mps> ncopa: ah, didn't noticed it is merged. just tested with your changes and it builds locally. thanks!
2021-11-17 11:04:46 <mps> ohm, except on rv64
2021-11-17 11:06:55 <mps> couldn't find python3 interpreter on rv64 (:
2021-11-17 11:11:05 <ncopa> any opinion on adding ssh key to root user from setup scripts? https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/24
2021-11-17 11:12:18 <mps> will not hurt, imo
2021-11-17 11:16:00 <mps> 'we' should not prevent user/admin to shot self in the foot if they want
2021-11-17 11:19:20 <ncopa> the idea is to make it easy to do the right thing, and add more resistance to shoot yourself in the foot
2021-11-17 11:19:51 <ncopa> for example, ubuntu will craete an ubuntu user with sudo access, instead of adding password to root
2021-11-17 11:20:26 <ncopa> nothing prevents you to create password for root and add ssh keys to root on ubuntu
2021-11-17 11:20:29 <mps> yes, I know, but ...
2021-11-17 11:21:06 <mps> I doubt it is more secure then allow user to do what s/he want
2021-11-17 11:21:31 <mps> someone who want easy root access will make it
2021-11-17 11:21:53 <ncopa> my point is, its easy to do that on ubuntu, but nobody does
2021-11-17 11:21:59 <ncopa> because its disencouraged
2021-11-17 11:22:52 <mps> I know, used debian for decades, but are our 'targets' ubuntu users or more knowledgeable ones
2021-11-17 11:23:42 <ncopa> if we makes it easy to add ssh key to root, then that will be the standard for alpine
2021-11-17 11:23:53 <mps> first things was 'sudo /bin/bash' and do the rest ;)
2021-11-17 11:25:18 <mps> I don't have strong opinion, whatever you decide is ok for me
2021-11-17 11:25:50 <mps> only what I dislike is false sense of security
2021-11-17 11:38:06 <ikke> mps: clam-av fails because it cannot find python3
2021-11-17 11:40:30 <mps> ikke: yes, I noticed, but why that happens
2021-11-17 11:41:11 <mps> python3 is available on rv64
2021-11-17 11:41:37 <ikke> mps: it's in checkdepends
2021-11-17 11:41:43 <ikke> which are not installed on riscv64
2021-11-17 11:41:50 <ikke> but apparently it's also a makedepends
2021-11-17 11:43:51 <mps> testing in lxc now
2021-11-17 11:44:44 <ikke> Run it with ABUILD_BOOTSTRAP=1 set in the environment 
2021-11-17 11:45:22 <mps> ah, I started with 'abuild -r'
2021-11-17 11:46:07 <mps> and it is slow with qemu-user emulation
2021-11-17 11:47:55 <ikke> clandmeter: where do we set ABUILD_BOOTSTRAP for riscv64?
2021-11-17 11:47:59 <mps> ikke: should we move python3 to makedepends
2021-11-17 11:48:16 <ikke> mps: that's the easiest solution
2021-11-17 11:48:37 <mps> it pass 'abuild -r' on rv64
2021-11-17 11:49:05 <ikke> with python3 in makedepends?
2021-11-17 11:49:09 <ikke> clandmeter: ah, found it
2021-11-17 11:49:17 <mps> no, still in checkdepends
2021-11-17 11:49:23 <ikke> ncopa fixed it
2021-11-17 11:49:30 <ikke> did you set ABUILD_BOOTSTRAP=1?
2021-11-17 11:49:37 <mps> not yet
2021-11-17 11:49:49 <ikke> Then checkdepends are still installed
2021-11-17 11:49:50 <mps> waiting check finish
2021-11-17 11:50:05 <ikke> ABUILD_BOOTSTRAP=1 makes it skip the tests
2021-11-17 11:50:11 <ikke> and also installing checkdepends
2021-11-17 11:50:33 <mps> what about test with rootbld?
2021-11-17 11:50:52 <ikke> does not matter as long as you do not have that variabe set
2021-11-17 11:53:34 <ikke> The problem is that python3 is never installed on rv64 because it does not install checkdepends because ABUILD_BOOTSTRAP=1
2021-11-17 11:53:38 <mps> looks like 'abuild -r' will pass with ABUILD_BOOTSTRAP=1
2021-11-17 11:53:47 <ikke> yes
2021-11-17 11:53:53 <ikke> that's why it succeeds on other hosts
2021-11-17 11:54:03 <ikke> mps: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L101
2021-11-17 11:54:56 <mps> 1ok, will move python3 to makedeps and push
2021-11-17 11:55:04 <ikke> mps: ncopa already did that
2021-11-17 11:55:07 <mps> s/iok/ok/
2021-11-17 11:55:18 <ikke> 8c2faf3f4a4a8270a59f02df2e1589e8e2e933a5 
2021-11-17 11:55:34 <mps> ah, he is really fast this morning :)
2021-11-17 11:56:22 <mps> 'we' can add clamav in release notes
2021-11-17 11:57:01 <mps> and don't forget gvim split from vim and moved to community
2021-11-17 11:58:05 <mps> also, not sure should we add notes about linux-edge moved to community and linux-edge-virt renamed to linux-edge4virt
2021-11-17 11:58:38 <lzsaver> ncopa, please take a look !13198
2021-11-17 11:58:53 <mps> and ksmbd in kernel and ksmbd tools in community
2021-11-17 11:59:04 <lzsaver> ah.. not that. this one: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13198
2021-11-17 11:59:22 <ncopa> #13198
2021-11-17 11:59:24 <ikke> #13203
2021-11-17 11:59:24 <mps> also, paragon ntfs driver
2021-11-17 11:59:49 <lzsaver> ncopa, thanks
2021-11-17 14:19:24 <fcolista> re: apk-new appended file. Does it work only for config file in /etc ?
2021-11-17 14:19:24 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13085#note_185548
2021-11-17 14:19:36 <fcolista> !13085
2021-11-17 14:20:09 <fcolista> I was never able to use correctly algitbot... /0\
2021-11-17 14:20:52 <fcolista> anway: apk new $package that ships a config file, is not going to upgrade the config file rather appends .apk-new 
2021-11-17 14:21:08 <fcolista> does it happens only for files in /etc ? 
2021-11-17 14:29:18 <Hello71> seems like need to install file in /etc/apk/protected_paths.d
2021-11-17 14:30:00 <Hello71> i think for other distros normally symlink is installed to /etc, e.g. /var/spool/hylafaxplus/etc -> ../../../etc
2021-11-17 14:30:13 <Hello71> er, ../../../etc/hylafaxplus
2021-11-17 14:31:52 <fcolista> Hello71, so if I add a post-install script in the APKBUILD that does this symlink, I'm gonna have .apk-file 
2021-11-17 14:32:55 <fcolista> ..now, the issue is that alpine, compared with other distros, could run from ram...and that means that an lbu ci for /etc pointing to /var/spool/hylafaxplus might require sometimes
2021-11-17 14:34:41 <Hello71> well it is a different semantics
2021-11-17 14:35:04 <Hello71> i'm not sure about hylafaxplus but i think for postgres this is fairly common
2021-11-17 15:13:59 <lzsaver> #13200
2021-11-17 15:21:41 <lzsaver> can someone revert py3-aiorpcx ?
2021-11-17 16:21:22 <liske> fcolista: maybe to consider to create the file in the init script? In diskless mode the file will get lost intentionally including empty directories (?)
2021-11-17 16:22:12 <liske> s/get lost/get lost on next reboot/
2021-11-17 16:22:12 <alpine-meetbot> liske meant to say: fcolista: maybe to consider to create the file in the init script? In diskless mode the file will get lost on next reboot intentionally including empty directories (?)
2021-11-17 17:48:12 <craftyguy> is Jakub Jirutka here?
2021-11-17 17:48:17 <ikke> no
2021-11-17 17:49:07 <craftyguy> ah ok. this change is causing problems running some DEs that use dbus: https://gitlab.alpinelinux.org/alpine/aports/-/commit/2779b81458d666777fa1460a423172e442d38525#86836d53d88490d322bd25fd08fc5c11ba326bf0_23_18
2021-11-17 17:49:21 <nmeum> try contacting him over gitlab, e.g. by commenting on the commit
2021-11-17 17:49:27 <nmeum> he is usually very fast to respond
2021-11-17 17:49:33 <craftyguy> nmeum: ok good suggestion, thanks
2021-11-17 18:34:29 <craftyguy> that change is too restrictive, or maybe the intention is that users (including those that only run some service) that need to access the system bus are in the messagebus group?
2021-11-17 19:01:21 <ikke> sad, you cannot prefetch things like go modules and not rely on options="net" with abuild rootbld
2021-11-17 19:02:43 <ikke> go mod download could download them modules, but it would need to run after unpack
2021-11-17 19:20:10 <xordspar0> ikke: I don't know if this is useful to you, but what I have done before is grab just the go.mod file, go mod download, then unpack the source.
2021-11-17 19:20:26 <xordspar0> *go.mod and go.sum files
2021-11-17 19:22:43 <nmeum> I am currently looking at cabal for 3.15, it's a pain but I think I have something that should work…
2021-11-17 19:22:50 <ikke> nmeum: oh!
2021-11-17 19:23:08 <nmeum> did you start working on it too? 😅
2021-11-17 19:23:11 <ikke> But I suppose it still relies on a working cabal, or?
2021-11-17 19:23:21 <ikke> nmeum: not recently since ghc9 was not supported yet
2021-11-17 19:23:23 <nmeum> no
2021-11-17 19:23:25 <nmeum> it's bootstraped
2021-11-17 19:23:27 <ikke> vpp;
2021-11-17 19:23:30 <ikke> cool*
2021-11-17 19:23:30 <nmeum> it does not rely on a working cabal
2021-11-17 19:23:36 <nmeum> I still have to clean this up
2021-11-17 19:23:54 <ikke> I made an attempt, but stopped when I ran into dependency resolving issues with cabal
2021-11-17 19:24:08 <nmeum> https://tpaste.us/gBzr
2021-11-17 19:24:11 <ikke> I did read they should have been solved now, but there was one more isseu
2021-11-17 19:24:23 <nmeum> I ran into a lot of issues
2021-11-17 19:24:25 <ikke> he
2021-11-17 19:25:23 <ikke> https://github.com/haskell/cabal/issues/7747
2021-11-17 19:26:15 <nmeum> yes
2021-11-17 19:26:29 <nmeum> I had to patch a few version constraints
2021-11-17 19:28:46 <nmeum> I also used git head
2021-11-17 19:28:58 <nmeum> because latest release is nearly impossible to bootstrap with ghc 9.X
2021-11-17 19:30:28 <ikke> ah, good idea
2021-11-17 19:30:55 <omni> I'm having issues booting after last upgrade, am not prompted for a luks passphare, looking into it...
2021-11-17 19:31:33 <nmeum> ikke: will prepare MR in a sec, are we then using the bootstraped version with provides to rebuild it again?
2021-11-17 19:32:14 <ikke> We could make a dedicated cabal-bootstrap package
2021-11-17 19:32:37 <ikke> Then we do not have to do anything special
2021-11-17 19:33:05 <nmeum> that could work too
2021-11-17 19:33:09 <ikke> But I suppose a lot of the fixes you did have to be shared?
2021-11-17 19:33:22 <ikke> (that's one of the suggestions that ncopa made)
2021-11-17 19:34:00 <nmeum> not sure
2021-11-17 19:34:23 <craftyguy> would a partial revert of 2779b8145 be acceptable until this is resolved? https://gitlab.alpinelinux.org/alpine/aports/-/issues/13204
2021-11-17 19:35:08 <craftyguy> the partial revert would be the bit setting ownership/mode on /run/dbus, so the behavior would be the same as it was ~6 hours ago before that was merged
2021-11-17 19:36:10 <ikke> I'd first wait for a reaction from jirutka
2021-11-17 19:36:21 <nmeum> ikke: !27526
2021-11-17 19:36:29 <nmeum> lets hope this passes on the builders too
2021-11-17 19:36:36 <nmeum> haven't done a clean build yet
2021-11-17 19:37:25 <craftyguy> ikke: ya I first tried here: https://gitlab.alpinelinux.org/alpine/aports/-/commit/2779b81458d666777fa1460a423172e442d38525#86836d53d88490d322bd25fd08fc5c11ba326bf0_23_18
2021-11-17 19:37:36 <craftyguy> but this is causing all kinda of headache on pmOS edge right now
2021-11-17 19:37:58 <craftyguy> like, nothing that uses dbus will start anymore, and adding things to that messagebus group dont' seem to help
2021-11-17 19:38:50 <craftyguy> so something else funky is going on. if *everything* needs to be in messagebus for it to function, then what's the point in enforcing group permissions :P
2021-11-17 19:40:04 <craftyguy> due to timezones, Jakub may not respond for a while, so I'm proposing reverting that permission change until they show back up and we can sort out the proper way to resolve it
2021-11-17 19:40:51 <nmeum> ikke: I like the idea of splitting community/cabal-bootstrap and community/cabal
2021-11-17 19:41:17 <nmeum> we could even try building the latest cabal with release with the cabal-bootstrap version from git head
2021-11-17 19:42:35 <ikke> nmeum: yes, that what I was thinking as well
2021-11-17 19:43:24 <artok> avahi-daemon seems to have some problems on rc
2021-11-17 19:43:25 <ikke> craftyguy: Does it work if you change the checkpath line to use -m755?
2021-11-17 19:45:02 <Ariadne> craftyguy: i poked jakub on telegram and he acted a change back to 755
2021-11-17 19:45:13 <craftyguy> ikke: yes
2021-11-17 19:45:17 <ikke> ^
2021-11-17 19:45:24 <craftyguy> Ariadne: ah, thank you so much!
2021-11-17 19:46:24 <craftyguy> yeah I wasn't sure if 755 is desired long term... so I only suggested it as a temporary thing but I'll defer to Jakub to make the right call there since I don't know how they intended things to work with it set to 750
2021-11-17 19:46:43 <Ariadne> he acted going to 755
2021-11-17 19:46:49 <Ariadne> acked even
2021-11-17 19:46:52 <Ariadne> so just do it :)
2021-11-17 19:46:55 <craftyguy> ok, I'll submit a patch then
2021-11-17 19:49:03 <ikke> nmeum: :(
2021-11-17 19:49:15 <craftyguy> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27527
2021-11-17 19:49:19 <nmeum> ikke: ?
2021-11-17 19:49:27 <craftyguy> ah checksum, oops
2021-11-17 19:49:40 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/540861
2021-11-17 19:49:46 <Ariadne> i’ll check it in a bit.  really sick today
2021-11-17 19:49:50 <nmeum> ah dependency errors
2021-11-17 19:50:00 <craftyguy> Ariadne: oh, sorry to hear that... get well soon :)
2021-11-17 19:50:00 <nmeum> (haven't done a cleanup built)
2021-11-17 19:50:15 <ikke> I'll handle it
2021-11-17 19:50:19 <ikke> craftyguy: ^
2021-11-17 19:50:31 <craftyguy> ikke: thank you :)
2021-11-17 19:50:39 <craftyguy> ah I just pushed the new checksum
2021-11-17 19:50:43 <craftyguy> if that's what you mean
2021-11-17 19:50:59 <Ariadne> i have some sort of sinus infection.  no idea why, haven’t gone anywhere lately
2021-11-17 19:51:01 <ikke> I mean, I'll merge it when it's building
2021-11-17 19:51:56 <artok> geh.. avahi user to messagebus group and ok, other than that, my rpi4 is doing fine with rc4
2021-11-17 19:52:11 <artok> (so far)
2021-11-17 19:53:06 <nmeum> ikke: it's building now ;)
2021-11-17 19:53:14 <ikke> nmeum: good
2021-11-17 19:59:01 <ikke> craftyguy: mpolanski already merged it
2021-11-17 19:59:29 <craftyguy> ya just noticed. thank you so much!
2021-11-17 20:01:21 <ikke> nmeum: so the next step is splitting it up in cabal and cabal-bootstrap?
2021-11-17 20:02:03 <nmeum> good question
2021-11-17 20:02:10 <nmeum> I think we could just merge the MR as soon as the pipeline passed
2021-11-17 20:02:20 <ikke> Ok, also fine with me
2021-11-17 20:02:21 <nmeum> and later rename community/cabal to community/cabal-bootstrap
2021-11-17 20:02:31 <nmeum> and add a new community/cabal package which uses community/cabal-bootstrap?
2021-11-17 20:02:37 <ikke> yes
2021-11-17 20:02:53 <ikke> This package is suitable to use for other packages already/
2021-11-17 20:03:10 <nmeum> I haven't tried
2021-11-17 20:03:22 <ikke> We could try to build shellcheck and pandoc
2021-11-17 20:03:22 <nmeum> CI pipeline passed
2021-11-17 20:03:45 <nmeum> I think building the latest release of cabal with this bootstraped version shouldn't be a lot of work
2021-11-17 20:07:43 <nmeum> ikke: do you want to do some further testing of the cabal MR or should I just merge it?
2021-11-17 20:07:56 <nmeum> I would look the -bootstrap split tomorrow then
2021-11-17 20:08:01 <nmeum> *look into
2021-11-17 20:08:10 <ikke> I guess just merge it
2021-11-17 20:08:21 <ikke> nothing is using it now anyway
2021-11-17 20:08:25 <nmeum> hehe
2021-11-17 20:12:40 <nmeum> ok done, I will look into the -bootstrap split asap so we can have a working haskell setup with 3.15 if all goes as planed
2021-11-17 20:13:16 <ikke> 👍
2021-11-17 21:55:04 <Nulo> I can't upgrade Telegram Desktop to 3.2 (which uses Qt6 now) because of this error: https://bpa.st/LERQ
2021-11-17 21:56:11 <Hello71> sure
2021-11-18 00:55:51 <artok> hit rc into all 3 rpi's and seems to work from installer as supposed, wifi working, boot from usb works, rpi4 (rev c03111), rpi3b (rev a02082), rpi3b (rev a22082)
2021-11-18 05:31:42 <ikke> artok: nice
2021-11-18 05:43:30 <idkrn> why was the hardened kernel removed?
2021-11-18 05:44:18 <ikke> idkrn: the patches that we used for it went private and require you to pay for it to obtain it
2021-11-18 05:46:12 <idkrn> wow
2021-11-18 05:46:58 <idkrn> doesn't arch have a fork of graphene's kernel?
2021-11-18 05:47:07 <idkrn> would that be possible for Alpine?
2021-11-18 06:08:47 <ikke> Someone needs to investagine it and maintain it
2021-11-18 07:28:08 <ncopa> good morning
2021-11-18 07:28:54 <ncopa> we used grsecurity patch for the kernel, which is no longer available
2021-11-18 08:05:50 <nmeum> ikke: looks like we can even use the bootstraped cabal version to build shellcheck and such directly !27539
2021-11-18 08:06:08 <nmeum> the cabal version we packaged previously was also only a bootstraped one
2021-11-18 08:26:15 <ikke> J0WI has an MR open for shellcheck 
2021-11-18 08:30:17 <nmeum> oh
2021-11-18 08:30:24 <nmeum> well, minimal changes either way
2021-11-18 08:31:12 <nmeum> I was able to compile the full cabal distribution with cabal-bootstrap now, would suggest we merge that first before we touch shellcheck and pandoc
2021-11-18 08:51:26 <nmeum> ikke: do you want to review !27540 or should I just merge it when the pipeline passed?
2021-11-18 09:02:02 <ncopa> the only thing i think is a bit controversial is depends="gmp zlib !cabal-bootstrap"
2021-11-18 09:02:36 <ncopa> it means that abuild will apk add --virtual  .makedepends-cabal  cabal-bootstrap !cabal-bootstrap
2021-11-18 09:02:45 <ncopa> as abuild will pull in runtime deps as well
2021-11-18 09:03:17 <ncopa> second thing is, can cabal itself be used to build next version?
2021-11-18 09:03:40 <nmeum> regarding: the conflict: would probably be easier to add depends="!cabal" to cabal-bootstrap
2021-11-18 09:03:48 <ncopa> if so, then maybe it should have a provides="cabal-bootstrap=$pkgver-r$pkgrel"
2021-11-18 09:03:52 <ncopa> yeah
2021-11-18 09:03:58 <ncopa> but do we need the conflict?
2021-11-18 09:04:04 <ncopa> maybe we do
2021-11-18 09:04:15 <nmeum> no, we don't need it just wanted to prevent someone from installing both since they ship the same binaries
2021-11-18 09:04:44 <ncopa> i think adding the conflict to cabal-bootstrap should work. good thinking
2021-11-18 09:05:07 <nmeum> we could use cabal itself to build the next version, I just wanted to avoid that for now since cabal is dynamically linked against a few libraries such as libffi, libgmp, … and this might cause issue when rebuilding cabal on soname bumps
2021-11-18 09:07:02 <nmeum> I personally always prefer to have a clean bootstrap path which doesn't rely on a previous version of the aport being present in the repo but we can still add the provides later if we want to
2021-11-18 09:08:58 <ncopa> yeah. sounds good
2021-11-18 09:13:14 <maribu> PureTryOut (matrix.org): Have you tried using wireplumber without elogind? I just gave seatd a try and everything except wireplumber still works for me. I rebuild the package with `elogind` disabled. This results in wireplumber complaining about no logind found, but working anyway. I wonder why it behaves differently for elogind for me.
2021-11-18 09:20:22 <nmeum> updated the cabal stuff accordingly and pushed it, fingers crossed everything goes well on the builders
2021-11-18 09:24:11 <maribu> OK, just using `pipewire-media-session` instead works fine with seatd.
2021-11-18 09:28:03 <psykose> maribu: you can try comment out the load_optional_module("logind") in bluetooth.lua.d/30-bluez-monitor.lua
2021-11-18 09:28:18 <psykose> works fine for me then without elogind running
2021-11-18 09:28:25 <ikke> nmeum: yeah, relying on the previous versions means we have to manually add the bootstrap version each time
2021-11-18 09:29:54 <nmeum> if the cabal-bootstrap package is too much work to maintain in the long run we can also bootstrap from the static pre-compiled cabal binary provided by upstream but the current approach should work for 3.15
2021-11-18 09:30:15 <maribu> psykose: Worked like a charm :-)
2021-11-18 09:30:34 <psykose> so wireplumber works fine now then? good to hear :)
2021-11-18 09:31:25 <PureTryOut> maribu: I have not, my system requires elogind
2021-11-18 09:32:16 <maribu> It's a pity that a call to `load_optional_module()` results in an exit, when the optional module cannot load.
2021-11-18 09:33:05 <PureTryOut> Seems like a bug, you should report it upstream
2021-11-18 09:33:49 <psykose> the lua that loads it seems correct, so i would assume it's in wireplumber itself
2021-11-18 09:34:20 <maribu> I guess that the fact that it works when failing to optionally load logind (not elogind) it will just warn indicates that the exit is not intended.
2021-11-18 09:34:55 <psykose> it just appends to a table per .lua.d directory, wireplumber itself would use that in the c part
2021-11-18 09:35:02 <psykose> "logind" is elogind in this case
2021-11-18 09:39:01 <psykose> but yes; you should send the issue upstream
2021-11-18 09:39:06 <psykose> i'm sure someone will have time to find it
2021-11-18 10:42:45 <nmeum> why was vala-lint not purged from the repos even though I disabled it in 4c427f68ad447eaa57907e0ce10d5ba88c15a358 ?
2021-11-18 10:43:16 <nmeum> ah, disabling a packaging via $arch does generally not cause it to be removed from the repos. right?
2021-11-18 10:43:47 <nmeum> what would I need to do to remove it from the repos as well? it needs a rebuild but cannot be rebuild atm
2021-11-18 11:23:16 <ncopa> i don tknow tbh. But i think its not that critical
2021-11-18 11:26:41 <nmeum> just want to get rid of the dependency error in apk dot --errors
2021-11-18 11:27:29 <ncopa> does it happen if you sed -i -e 's/edge/v3.15/g' /etc/apk/repositories && apk upgrade -U -a?
2021-11-18 12:12:53 <ncopa> ok. i think we are ready for a rc4?
2021-11-18 12:13:03 <ncopa> anything critical that prevents us from doing rc4?
2021-11-18 12:14:27 <mps> nothing I know
2021-11-18 12:16:08 <ncopa> we got shellcheck back?
2021-11-18 12:16:13 <ncopa> this is great!
2021-11-18 12:16:40 <ncopa> nmeum: thank you for following up on ghc/cabal
2021-11-18 12:18:43 <maribu> PureTryOut (matrix.org): The optional module load will only fail non-fatal if a module is not installed, but fail fatal if it is present but fails to load.
2021-11-18 12:18:59 <ncopa> ok, i pushed 3.15.0_rc4
2021-11-18 12:24:22 <PureTryOut> maribu: ah cool
2021-11-18 12:24:26 <PureTryOut> that seems fine
2021-11-18 12:25:36 <nmeum> nmeum: np
2021-11-18 13:02:09 <ncopa> the rc4 seems to work well. the vmware issue is "fixed"
2021-11-18 13:02:56 <ncopa> and alpine-virt has a working network on aarch64 vmware (macbook with m1)
2021-11-18 13:03:39 <ncopa> i think we can tag 3.5.0 early next week. either Monday or Tuesday
2021-11-18 13:03:47 <ncopa> unless there are any blockers
2021-11-18 13:05:07 <nmeum> there are still a few open issues assigned to the 3.15 milestone in aports.git but I suppose many of them could be moved to 3.16
2021-11-18 13:05:16 <nmeum> might make sense to go through the list once
2021-11-18 13:05:28 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/issues?milestone_title=3.15.0
2021-11-18 13:08:04 <ikke> If we go through the list, we should verify if it makes sense to assign it to 3.16, or leave it unassigned
2021-11-18 13:08:17 <ikke> We have many issues that we just bump from one release to the next
2021-11-18 13:09:17 <ktprograms> Hello
2021-11-18 13:09:32 <ktprograms> ncopa: Can you please merge !26444 ? Thanks!
2021-11-18 13:11:25 <nmeum> ikke: yes
2021-11-18 13:11:33 <ktprograms> I've successfully ported GHC to Alpine aarch64 and am in the middle of writing up detailed instructions, but what I'd like to know is if a Dockerfile would be wanted for hands off reproducing?
2021-11-18 13:12:55 <ktprograms> Thanks ncopa !
2021-11-18 13:12:58 <ncopa> might be useful
2021-11-18 13:13:02 <nmeum> I would actually prefer if GHC upstream starts providing bindists for musl for non x86_64 architectures
2021-11-18 13:13:34 <ncopa> the x86_64 bindist was not that useful for us
2021-11-18 13:13:37 <nmeum> they have a bindist for x86_64 already, usage of which would make bootstraping and maintaing ghc easier
2021-11-18 13:13:45 <nmeum> why not?
2021-11-18 13:13:56 <ncopa> they have a different triplet that we need linux-unknown instead of linux-alpine
2021-11-18 13:14:20 <ncopa> which means that it when we build with our triplet it thinks it will corsscompile
2021-11-18 13:14:29 <ncopa> and things goes bad
2021-11-18 13:14:41 <nmeum> hmhm
2021-11-18 13:14:46 <nmeum> should maybe try to talk to upstream about this then
2021-11-18 13:15:05 <nmeum> without using the bindist ghc is just annoying to maintain in the long run imho
2021-11-18 13:15:17 <ncopa> i think for upstram it makes sense to ship unknown instead of alpine
2021-11-18 13:15:27 <ncopa> ghc is annoying. period. :)
2021-11-18 13:15:57 <ktprograms> But wouldn't the problem with a bindist be that you depend on the integrity of an upstream binary?
2021-11-18 13:15:59 <nmeum> sure, but it doesn't neccessairly make sense to cross-compile if that part of the triplet differs
2021-11-18 13:16:15 <nmeum> ghc doesn't have to be annoying if we get upstream to understand our downstream needs :p
2021-11-18 13:17:18 <ktprograms> Also, it seems that cross compiling GHC is easier now then in 2013 (judging by the wiki notes).
2021-11-18 13:17:34 <nmeum> when bootstraping self-hosting compilers you will always rely on the integrity of a pre-compiled binary at some point
2021-11-18 13:18:11 <ktprograms> nmeum: So do you mean the bindist will be used as a bootstrap or for every release?
2021-11-18 13:19:09 <nmeum> not sure, I am just considering options to make ghc less painful to maintain since it really required it a lot of work this time around to get in shap for 3.15
2021-11-18 13:19:15 <psykose> i can't think of a case where the bindist is used aside from initial bootstrap or when ghc gets somehow broken each time
2021-11-18 13:19:24 <psykose> this instance i believe was because it got deleted from the repos by accident
2021-11-18 13:19:34 <nmeum> ultimately it would be nice to have someone who wants to maintain haskell stuff for alpine
2021-11-18 13:19:49 <psykose> i believe there was someone offering on twitter but not sure how it ended up
2021-11-18 13:19:50 <nmeum> because we don't have anyone who really seems to be interested in haskell on alpine atm
2021-11-18 13:19:51 <ktprograms> Right now GHC cross compiling just needs 2 small patches to force enable cross compiling, but then the make just goes through with no errors/manual intervention.
2021-11-18 13:20:19 <psykose> the final binary should also pass all tests
2021-11-18 13:21:04 <ikke> psykose: no, it was not deleted from the repos
2021-11-18 13:21:44 <nmeum> the problem with having ghc rely on itself for bootstraping is that ghc is a dynamically linked binary and when the libraries it depends on change in ABI incompatible ways it becomes very hard to rebuild it
2021-11-18 13:21:56 <psykose> ikke: i seem to have a memory in the back of my head that ghc-bootstrap or something was accidentally ridden, but it's been a month or so :)
2021-11-18 13:22:02 <nmeum> correct me if I am wrong but this was the problem we faced with libffi and ghc this time around
2021-11-18 13:22:06 <ktprograms> I suppose there's two things to be careful about when maintaining GHC: (a) we'll need a temporary version of libffi when it gets upgraded, and (b) GHC shouldn't be upgraded until cabal supports it so no hacks/using cabal HEAD is needed.
2021-11-18 13:22:12 <ikke> psykose: it was disabled, and ncopa thought it was removed, but it was not
2021-11-18 13:22:15 <psykose> ah
2021-11-18 13:22:21 <psykose> thanks for clarification
2021-11-18 13:22:57 <ktprograms> nmeum: Yes, from what I remember the problem was the libffi was updated, so ghc couldn't run.
2021-11-18 13:23:36 <nmeum> it's not just libffi though ghc also needs other libraries such as libgmp, libncursesw, …
2021-11-18 13:23:52 <ikke> libffi was updated so libffi.so.7 was no longer available, required to build ghc
2021-11-18 13:23:56 <nmeum> **if** I were to be the maintainer of the GHC package in alpine I would prefer to have a clean bootstrap path
2021-11-18 13:24:19 <ktprograms> nmeum: What do you mean by 'clean bootstrap path'?
2021-11-18 13:24:37 <ikke> note we have the same issue with go and rust
2021-11-18 13:24:50 <ikke> at least, depending on itself I mean
2021-11-18 13:24:54 <nmeum> yes
2021-11-18 13:24:58 <psykose> ktprograms: something like the build for ghc just being 'bindist -> ghc -> ghc' instead of needing itself
2021-11-18 13:25:01 <ikke> rust has issues with libgit2 updates
2021-11-18 13:25:10 <nmeum> though the go compiler does not link against a bunch of libraries dynamically
2021-11-18 13:25:13 <nmeum> so it is less of an issue
2021-11-18 13:25:15 <nmeum> not sure about rustc
2021-11-18 13:25:18 <ikke> ^^
2021-11-18 13:25:48 <nmeum> ktprograms: a compilation path which does not rely on a previous version of ghc being available in the repos
2021-11-18 13:27:11 <ikke> For ghc, go and rust, someone with access to the builders needs to manually install *-bootstrap packages before they can be built
2021-11-18 13:28:17 <nmeum> and we also need to do manuall fiddeling if the ABI of any of the libraries these package link against dynamically change
2021-11-18 13:30:11 <nmeum> anyway, regarding ghc: someone just needs to step up and maintain it. I would personally attempt to use the bindist but I wouldn't mind if it is compiled in a different way as long as we have someone taking care of it and keeping ghc/cabal up to date
2021-11-18 13:35:05 <ktprograms> I would think that depending on external binaries on every update and not just the first time would be more chance for security problems?
2021-11-18 13:35:29 <ktprograms> ikke: What are the *-bootstrap packages? I don't see any in aports?
2021-11-18 13:36:28 <ikke> ktprograms: They are provided by the original packages
2021-11-18 13:36:47 <ikke> but because a package cannot makedepends on itself, we do provides="<pkg>-bootstrap"
2021-11-18 13:37:14 <ikke> And we install them from edge when bootstrapping a new release
2021-11-18 13:37:24 <ktprograms> ikke: Oh that's right.
2021-11-18 13:37:26 <nmeum> ktprograms: from a security perspective it really doesn't make much of a difference if you depend on a pre-existing binary once or every time. see https://doi.org/10.1145/358198.358210
2021-11-18 13:38:24 <nmeum> and you don't have to use the external binary for every built but just having an alternative compilation path were some sort of bootstrap package can be used as a subustite would be nice
2021-11-18 13:38:53 <ktprograms> nmeum: My perspective is that with only a single round of external binary, you only trust once, whereas with always using a bindist, you have to trust each time. I do agree that IF the first round is compromised it isn't any better.
2021-11-18 13:39:46 <ktprograms> nmeum: Well the alternative compilation path would be a Debian based Dockerfile?
2021-11-18 13:42:10 <nmeum> as I said: I don't care how ghc is compiled/bootstraped (bindist is just what I would personally use), it just needs to be maintained by someone and if that someone is you I am totally fine with that (:
2021-11-18 14:02:08 <ktprograms> So what exactly was the libffi problem with GHC?
2021-11-18 14:04:45 <ikke> ghc depends on itself to build
2021-11-18 14:04:51 <ikke> ghc also depends on ffi
2021-11-18 14:05:19 <ktprograms> So when ffi was updated ghc couldn't build?
2021-11-18 14:05:23 <ikke> yes
2021-11-18 14:05:31 <ikke> because it cannot find the previous libffi soname
2021-11-18 14:05:40 <ikke> (note that it only matters if there is a soname bump)
2021-11-18 14:05:46 <nmeum> libffi was upgraded to 3.4.X. this version of libffi is ABI incompatible with the one we shipped previously, thus soname changed from libffi.so.7 to libffi.so.8. due to the soname change we needed to rebuild ghc but ghc needs ghc to build itself, but since ghc was dynamically linked against libffi.so.7 we coludn't rebuild it
2021-11-18 14:06:21 <ktprograms> Oh I see dynamically linked. So that's why there needed to be the libffi compat package?
2021-11-18 14:06:29 <ikke> yes
2021-11-18 14:06:45 <ikke> But in the next iteration, ncopa just built ghc with the shipped ffi
2021-11-18 14:07:05 <ikke> and after that, we switched back to system ffi, because otherwise all packages would depend on ghc
2021-11-18 14:07:48 <ktprograms> So basically the process is (1) add the compat package, (2) use it to build ghc against the new ffi ?
2021-11-18 14:08:03 <ktprograms> As in wouldn't it just work without having to use the included ffi?
2021-11-18 14:10:11 <nmeum> I think the compat package approach didn't really work out for some reason and we ended up building ghc with the vendored ffi version to resolve this
2021-11-18 14:10:12 <nmeum> see c07ef27c2be7d97c73a890055bdeaae1f979ebfd
2021-11-18 14:13:19 <ikke> nmeum: afaik, ncopa just wanted to use the built-in ffi to make transitions easier in the future
2021-11-18 14:13:44 <ikke> but then found out it resulted in all haskell based packages pull in ghc + llvm
2021-11-18 14:14:06 <nmeum> or that but afaik we ultimately ended up not using the libffi compat package for ghc
2021-11-18 14:16:00 <ikke> It was for a period built against it
2021-11-18 14:16:41 <nmeum> ah! that I didn't know
2021-11-18 14:16:43 <ikke> THat's how ncopa was able to build it with built-in ffi, otherwise ghc could not be rebuilt
2021-11-18 14:16:57 <nmeum> ahhhh
2021-11-18 14:17:03 <nmeum> ok, makes sense
2021-11-18 14:17:17 <ikke> THat's why I merged the compat package in the first place
2021-11-18 14:17:24 <nmeum> *nod*
2021-11-18 14:43:31 <ncopa> yeah, ghc upgrade was messy.
2021-11-18 14:44:02 <ncopa> im not sure the ghc + llvm dependency thingy was related libffi
2021-11-18 14:45:11 <ncopa> part of the problem was also that ghc used libff-dev as a runtime dep, so even with libffi-compat we got a conflict with old and new libffi.
2021-11-18 14:45:26 <ncopa> this was solved by building interim ghc with bundled libffi
2021-11-18 14:45:43 <ncopa> but the problem with that was that it ended up providing libffi.so.7
2021-11-18 14:46:24 <ikke> right
2021-11-18 14:47:59 <nmeum> sounds messy indeed :S
2021-11-18 14:48:42 <ikke> And removing the libffi-dev dependency made sense, it's actually the built packages that need it, not ghc
2021-11-18 14:48:57 <ikke> (I had to add libffi-dev to other packages now, which makes more sense)
2021-11-18 16:11:11 <tomalok> looks like there's a CVE for containerd -- i'll get a MR for that today.  new docker version too, but it's unclear if it's just for when containerd isn't packaged separately
2021-11-18 17:42:20 <ikke> tomalok: lmk when it's finished
2021-11-19 00:28:49 <ktprograms> Re GHC: So given the knowledge gained from this round of upgrading libffi, what would be the best course of action when a runtime dep gets a soname bump?
2021-11-19 00:41:27 <ktprograms_> My VM with my IRC client keeps crashing... Anyway I'm using the webchat now.
2021-11-19 02:50:42 <smcavoy> anyone around able to discuss MR  !25760 ? 
2021-11-19 02:50:47 <tomalok> ikke: the MRs for containerd (and docker !27590, because apparently part of the mitigation is there too) are on deck i think andypost[m] already merged the main branch containerd MR
2021-11-19 02:51:29 <tomalok> 3.14 backports !27589 and !27585
2021-11-19 07:08:52 <ncopa> good morning
2021-11-19 07:31:01 <artok> moarning
2021-11-19 07:35:35 <mps> \o
2021-11-19 07:55:49 <mps> do we need something more to enable in kernels, I will upgrade linux-edge to 5.15.3 today
2021-11-19 07:57:12 <mps> or just bump version?
2021-11-19 11:21:51 <ikke> o/
2021-11-19 11:31:46 <PureTryOut> ncopa: please take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27599
2021-11-19 12:41:34 <maribu> PureTryOut (matrix.org): Looks like I'm not the only one using flatpak to play games. And being interested in ARM based desktop machines. https://www.reddit.com/r/arm/comments/qfa495/running_serious_sam_3_bfe_steam_on_arm_pc_phytium/
2021-11-19 12:41:34 <alpine-meetbot> [REDDIT] Running Serious Sam 3 BFE / Steam on ARM PC (Phytium D2000 + Radeon Rx500) using Box86 (https://i.redd.it/ulschseobjv71.png) to r/arm | 41 points (0396.0%) | 19 comments | Posted by _ptitSeb_ | Created at 2021-10-25 - 05:48:45UTC
2021-11-19 12:47:15 <PureTryOut> maribu: haha ofc you're not
2021-11-19 12:47:25 <PureTryOut> I'm using Flatpak to play Star Citizen via Lutris right now 😄
2021-11-19 12:53:01 <maribu> I had fun playing the old Jedi Knight games I played when I was still at school the last few weeks. I guess I'm too old and have to little spare time to learn new games :-D
2021-11-19 13:12:23 <alandiwix> I wish flatpak allowed a bit more control over underlying bubblewrap.
2021-11-19 14:36:23 <lzsaver> minimal, #13209
2021-11-19 14:37:22 <minimal> lzsaver: yes there have several issues raised around this, seems to be an "issue" related to the Busybox mkfs.fat
2021-11-19 14:39:07 <Newbyte> alandiwix: what would you want to be able to do?
2021-11-19 14:42:08 <alandiwix> mount stuff around, better control over namespaces, native env control, etc. so, basically a bit more access to the bubblewrap command arguments
2021-11-19 14:42:54 <alandiwix> correct me if I mentioned something that is implemented already
2021-11-19 14:43:19 <lzsaver> minimal, can you say me where can I see the command, which formats the boot parition? I want to read it
2021-11-19 14:44:25 <Newbyte> alandiwix: not sure what you mean by "native env control" exactly, but you can definitely set permanent (and temporary) environment variables on a per-Flatpak basis and also choose what paths to share from your host system
2021-11-19 14:45:39 <minimal> lzsaver: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L889
2021-11-19 14:47:51 <minimal> lzsaver: looks like the intention was to use mkfs.fat from dosfstools rather than Busybox: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L795 but during to #13194 even though dosfstools is installed the Busybox mkfs.fat is used instead
2021-11-19 14:48:09 <minimal> s/during/due/
2021-11-19 14:48:09 <alpine-meetbot> minimal meant to say: lzsaver: looks like the intention was to use mkfs.fat from dosfstools rather than Busybox: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L795 but due to #13194 even though dosfstools is installed the Busybox mkfs.fat is used instead
2021-11-19 14:50:19 <lzsaver> minimal, thanks. so we need dosfstools to be installed on the installation media too
2021-11-19 14:50:31 <alandiwix> Newbyte: yea, my env complaint is not fair, but the main one is mounting stuff
2021-11-19 14:52:25 <lzsaver> minimal, also perhaps I see the real bug https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L144
2021-11-19 14:53:02 <alandiwix> also the portals are now mandatory for file selection operations in qt apps (UI hangs for me if no portal impl installed)
2021-11-19 14:53:26 <alandiwix> and wlr portal doesn't implement gile sharing for now
2021-11-19 14:53:58 <lzsaver> minimal, should be "vfat) id=SOME_PARTTYPE_TO_VFAT_BOOT_EFI_PARTITION ;;", right ?
2021-11-19 14:54:19 <minimal> lzsaver: I assume dosfstools already is, it just was not being used - which is fixed in dosfstools 4.2-r1
2021-11-19 14:55:17 <minimal> lzsaver: that sounds like a different issue from the fsck-on-1st-boot issue you mentioned before whih is what I thought we were talking about
2021-11-19 14:55:19 <lzsaver> minimal, please look at the code. I think we also just do not set the right parttype ID
2021-11-19 14:55:43 <lzsaver> minimal, no, it looks related
2021-11-19 14:56:21 <minimal> lzsaver: you may have seen this problem *also* but I don't see how it is related to a mkfs/fsck issue
2021-11-19 14:56:45 <lzsaver> minimal, it should set the right ID, but it does not, so busybox fsck showed the error
2021-11-19 14:57:11 <lzsaver> minimal, dosfstools seems prefer to just ignore it
2021-11-19 14:57:11 <minimal> lzsaver: which error?
2021-11-19 14:58:02 <lzsaver> minimal, ah.. It said about a label, not a parttype. hmm
2021-11-19 14:58:27 <lzsaver> minimal, yeah, probably it's different issue, that's right
2021-11-19 14:59:16 <lzsaver> minimal, so mkfs problem is defferent to fsck problem
2021-11-19 14:59:39 <lzsaver> and the fsck problem is closed
2021-11-19 15:00:06 <lzsaver> need to resolve mkfs problem
2021-11-19 15:00:07 <Ariadne> lzsaver: dosfstools is not able to know the partition type, as linux does not make that information available to programs
2021-11-19 15:01:30 <lzsaver> Ariadne, what do you mean? well, if I install let's windows on efi, it will set the parttype to the boot partition, so UEFI can find it to boot PC using it
2021-11-19 15:01:40 <lzsaver> *let's say
2021-11-19 15:02:09 <lzsaver> (I mean gpt one, not mbr one)
2021-11-19 15:02:15 <Ariadne> your UEFI is not the linux kernel, so i don’t see where you’re going with this
2021-11-19 15:02:49 <ericonr> Ariadne: afaik the kernel doesn't even try to detect partition type, does it? At least in util-linux, it's the library that does that detection. The kernel will only check if it can mount a partition with a given fs type once someone calls mount()
2021-11-19 15:03:08 <minimal> lzsaver: as Ariadne indicated mkfs is for formatting partitions, it does not know or care what type of partition label (MBR or GPT) the partition is contained within, indeed you can run mkfs on a whole unpartitioned disk
2021-11-19 15:03:20 <Ariadne> ericonr: correct
2021-11-19 15:03:46 <lzsaver> minimal, ah, I got now, that's true
2021-11-19 15:03:51 <ericonr> alandiwix: I think wlr portal should forward requests to the gtk portal
2021-11-19 15:04:01 <ericonr> or smth like that
2021-11-19 15:04:44 <minimal> lzsaver: so apart from the resolved fsck-warning-on-1st-boot issue, what other problem/error are you seeing?
2021-11-19 15:06:29 <lzsaver> minimal, "Partition id "vfat" is not supported!". probably it's related to disk partitioning then
2021-11-19 15:07:12 <minimal> lzsaver: and that occurs during setup-alpine/setup-disk or during boot?
2021-11-19 15:09:26 <lzsaver> minimal, setup-alpine during installation from ISO. the messages during boot were fixed in #13194 !27513
2021-11-19 15:11:12 <minimal> lzsaver: confused now as you're pointed out the issue/bug to me that I pointed out to you about 15mins ago :-) So is there still any problem when installing with the updated dosfstools package?
2021-11-19 15:12:09 <lzsaver> minimal, yes
2021-11-19 15:12:27 <minimal> lzsaver: so what is the current problem?
2021-11-19 15:13:38 <lzsaver> minimal, as I said the first booting problem was fixed, but the setup-alpine problem exists still
2021-11-19 15:14:09 <lzsaver> minimal, it shows 'Partition id "vfat" is not supported', so it works not as expected
2021-11-19 15:14:42 <lzsaver> minimal, you said that it is probably fixed with dosfstools upgrade, right?
2021-11-19 15:14:52 <minimal> lzsaver: can you provide more screen output/logs of the problem? What are you installing on exactly? x86_64 EFI?
2021-11-19 15:15:03 <lzsaver> minimal, yes, x86_64 EFI
2021-11-19 15:15:22 <minimal> lzsaver: I said the fsck issue should be resolved by the dosfstools package update
2021-11-19 15:18:06 <lzsaver> ah, that's true the fsck issue is resolved
2021-11-19 15:18:27 <lzsaver> need to think what's wrong with mkfs
2021-11-19 15:19:22 <lzsaver> I thought that it's the problem that parted/sfdisk does not set correct parttype
2021-11-19 15:19:37 <lzsaver> but now I'm not sure
2021-11-19 15:23:13 <minimal> lzsaver: The error you see appears to be because some part of the setup-disk script is calling the partition_id function, https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L134 with an unexpected paramaeter of "vfat" - that does not mean its a mkfs problem but without knowing exactly how setup-disk is trying to arrange your disk it is hard to debug. Are you calling setup-disk yourself or is it being called by 
2021-11-19 15:23:13 <minimal> setup-alpine? are you passing any parameter to either setup-alpine or setup-disk when this happens?
2021-11-19 15:25:35 <lzsaver> should there be "vfat) id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b ;;" ?
2021-11-19 15:25:57 <minimal> lzsaver: that is not the issue
2021-11-19 15:26:09 <lzsaver> minimal, what do you mean?
2021-11-19 15:26:21 <minimal> minimal: I mean that is not the issue
2021-11-19 15:26:42 <minimal> lzsaver: you are trying to find problems where there no problems
2021-11-19 15:26:43 <lzsaver> > Are you calling setup-disk yourself
2021-11-19 15:26:43 <lzsaver> yes, i'm calling it myself just after the boot
2021-11-19 15:26:49 <lzsaver> from ISO
2021-11-19 15:27:24 <minimal> lzsaver: and what options did you pass to setup-disk?
2021-11-19 15:28:07 <lzsaver> minimal, ah, wrong, I wanted to say that no, I run setup-alpine and it calls the setup-disk script
2021-11-19 15:28:17 <lzsaver> minimal, we just need to remove the warning. it looks bad. QA
2021-11-19 15:28:39 <minimal> lzsaver: what warning?
2021-11-19 15:28:44 <lzsaver> minimal, the right way to remove the warning is to get how it is produced
2021-11-19 15:29:06 <alandiwix> ericonr: yea, but afaik gtk portal is quite big, same for kde, a lot of deps on OS side, just to pick files :/
2021-11-19 15:29:19 <lzsaver> minimal, "Partition id "vfat" is not supported!"
2021-11-19 15:29:29 <minimal> lzsaver: that is not a warning, that is an error
2021-11-19 15:30:00 <lzsaver> minimal, I mean it's an error for mkfs, but for setup-alpine/setup-disk it's a warning because it does not stop execution
2021-11-19 15:30:45 <lzsaver> well, I just woke up, probably, I do not transfer my thoughts in a right way
2021-11-19 15:31:09 <lzsaver> I'll be later
2021-11-19 15:31:48 <minimal> lzsaver: I'm sorry, perhaps someone else can help you, I have tried to help but you don't to want to listen to my help/advice and you change direction repeatedly whilst talking about you problem(s)
2021-11-19 15:34:58 <lzsaver> it's not about helping me. it's about making alpine linux better. thanks anyway, you tried.
2021-11-19 15:41:09 <alandiwix> Newbyte:  so, I ended up with bubblewrapping void rootfs as jury-rigged "flatpak" for glibc proprietary crap :/
2021-11-19 15:47:40 <HRio> anybody remember when we dropped syslinux package from the iso files? 
2021-11-19 15:47:59 <HRio> setup-bootable seems to want it do be there, but its not
2021-11-19 15:49:33 <HRio> hmm possibly a "bad effect of" bcdaeacd529258f346f53631627ad681aa8fc9aa
2021-11-19 15:53:42 <tomalok> lzsaver: what is that error coming from?  parted or something else?
2021-11-19 15:56:50 <tomalok> because parted, iirc only understands fat32 and fat16 as partition types.  i also had trouble using busybox mkfs.vfat for a filesystem on EFI partition -- had to use dosfstools for that, and then a 512 KiB partition would only work as fat12.
2021-11-19 15:58:49 <minimal> tomalok: its nothing to do with parted AFAIK
2021-11-19 15:59:01 <tomalok> so i partitioned as fat32 (or fat16) and dosfstools mkfs.vfat chose fat12 (because of the size of the partition) -- i'm not sure offhand how setup-disk is doing it.
2021-11-19 15:59:32 <tomalok> minimal: just woke up, too...  this was the bad dream from a couple weeks ago ;)
2021-11-19 16:42:33 <HRio> re-added syslinux on the xen iso in !27602
2021-11-19 16:59:19 <ikke> Ariadne: still need to move sudo to community before the 3.15 release
2021-11-19 16:59:48 <Ariadne> go ahead and do it, i’m not at my computer atm
2021-11-19 16:59:51 <ikke> ok
2021-11-19 17:16:44 <ncopa> I think we have sudo included in the extended image. I think we should avoid move anything to community at this point
2021-11-19 17:16:57 <ncopa> or make another rc after
2021-11-19 17:17:33 <ikke> !27605
2021-11-19 17:17:37 <ikke> Hmm
2021-11-19 17:17:39 <ncopa> i was hoping to do 3.15 on Monday or Tuesday 
2021-11-19 17:18:05 <Ariadne> it would be nice to move it
2021-11-19 17:18:20 <Ariadne> and replace the extended with `doas`
2021-11-19 17:26:41 <ncopa> I’m ok to move it. I just don’t want any surprises on monday
2021-11-19 17:29:03 <ikke> can we do one more RC on monday then?
2021-11-19 17:30:46 <HRio> I was hoping that 3.15 would be the switch from sudo to doas in an orderly fashion
2021-11-19 17:30:52 <HRio> i.e. both in main
2021-11-19 17:32:06 <psykose> the primary reason for adding doas was to move sudo to community all along afaik, so the endless supply of sudo cves don't have to be patched for the 2 year main release
2021-11-19 17:32:17 <psykose> at least i think that is what ariadne said
2021-11-19 17:33:02 <ikke> yes, that's the idea
2021-11-19 17:33:24 <ikke> But I can also support what HRio is saying
2021-11-19 17:33:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27605
2021-11-19 17:33:32 <tomalok> edge/3.15 cloud images have already dropped sudo for doas
2021-11-19 17:33:40 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/1
2021-11-19 17:37:12 <HRio> I have some docs and some ansible code expecting sudo to be in main, was hoping to use 3.15 timeframe to update everything for doas
2021-11-19 17:38:59 <omni> !27600 !27601
2021-11-19 17:39:05 <HRio> i.e. during this time frame introduce users to doas and making sure everything works with doas (write does rules) like it used to with sudo
2021-11-19 17:39:31 <omni> the second is for 3.14, I'll add that to the description
2021-11-19 17:41:44 <ikke> So we could say we officially deprecate sudo in 3.15, and then remove it in 3.16
2021-11-19 17:42:00 <ikke> I expect we can expect less fall-out then if we move it now just before release
2021-11-19 17:42:39 <ikke> (deprecate for main, that is, not remove it)
2021-11-19 17:46:39 <Ariadne> fine
2021-11-19 17:47:20 <Ariadne> one more support lifecycle for sudo is tolerable
2021-11-19 17:48:10 <HRio> Ariadne: big thx
2021-11-19 17:50:35 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/1#note_193104
2021-11-19 18:05:50 <omni> added https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.15.0#Move_from_sudo_to_doas
2021-11-19 18:11:36 <jvoisin> TIL: https://en.wikipedia.org/wiki/MIPS_Technologies "Wave declared bankruptcy in 2020, emerging in 2021 as MIPS and announcing that the MIPS architecture was being abandoned in favor of RISC-V designs"
2021-11-19 18:11:37 <alpine-meetbot> [WIKIPEDIA] MIPS Technologies | "MIPS Technologies, Inc., formerly MIPS Computer Systems, Inc., was an American fabless semiconductor design company that is most widely known for developing the MIPS architecture and a series of RISC CPU chips based on it. MIPS provides processor architectures and cores for digital home, networking,..."
2021-11-19 19:09:18 <mps> what is 'boot media' when booting alpine generic aarch64
2021-11-19 19:09:49 <mps> I got 'Mounting boot media: failed'
2021-11-19 19:11:36 <mps> i.e. does it makes sense to catenate modloop-lts to chainload an boot image
2021-11-19 19:12:48 <mps> uh, no. resulting img is to big for m1n1 boot loader
2021-11-19 19:15:49 <mps> it is interesting to see 'Alpine init 3.5.0-r0' msg on M1 screen ;)
2021-11-19 19:55:37 <donoban> hehe nice
2021-11-19 20:25:20 <ikke> omni: thanks
2021-11-19 20:44:24 <dalias> has https://git.alpinelinux.org/aports/tree/community/v4l-utils/fix_parse_next_subopt.patch been sent upstream?
2021-11-19 20:48:18 <ikke> dalias: I suppose not: !27262
2021-11-19 20:49:09 <dalias> we've gotten multiple requests to make musl honor v4l2-ctl's wrong expectations here over the past few weeks
2021-11-19 20:49:16 <dalias> so getting it upstream would be nice
2021-11-19 21:29:40 <lzsaver> tomalok, hi. thanks for your info about mkfs.vfat. I'll check it
2021-11-19 21:51:23 <Hello71> "The downside is that we have to support main for 6 more months" did you mean 18 months?
2021-11-19 21:52:18 <psykose> there is already 18 more months because of prior releases, it becomes 24 if it gets put there again
2021-11-19 21:53:28 <Hello71> so s/main/sudo/, not s/6/18/
2021-11-19 21:57:54 <ikke> what psykose says
2021-11-19 21:58:07 <ikke> Hello71: yes, I meant hat
2021-11-19 21:58:09 <ikke> sudo in main
2021-11-19 21:58:30 <ikke> adjusted
2021-11-19 22:04:18 <ikke> dalias: maribu sent the patch somewhere upstream
2021-11-19 22:12:48 <maribu> let's see if someone still moderates that old mailing list and if it gets reacted upon...
2021-11-19 22:24:09 <dalias> :)
2021-11-20 00:18:18 <Hello71> 3.15.0_rc4 boot, serial, wifi ok on rpi zero w
2021-11-20 00:33:05 <lzsaver> armhf?
2021-11-20 00:34:21 <Hello71> well rpi zero w only has armv6, so...
2021-11-20 00:53:57 <lzsaver> they do not show the cpu model on the web page. thanks
2021-11-20 00:54:36 <Hello71> afaik the main reason armhf is kept around is for rpi zero w
2021-11-20 01:50:25 <omni> how about phones?
2021-11-20 01:50:37 <omni> I mean downstream PMOS
2021-11-20 01:52:28 <Hello71> i think possibly some devices use armv6 but probably not very many, because android needs armv7
2021-11-20 01:57:44 <omni> I find several devices that has this comment "This device is still running on armhf, although the processor supports armv7. If you own it, change it and test it that way."
2021-11-20 02:00:05 <omni> their wiki says rpiz is armhf https://wiki.postmarketos.org/wiki/Raspberry_Pi_Zero_(raspberry-pi0)
2021-11-20 02:03:14 <omni> oh-no! no nophone support! https://wiki.postmarketos.org/wiki/Unsupported_Devices
2021-11-20 05:06:19 <Ariadne> oh no
2021-11-20 05:08:32 <Ariadne> 
ACTION wishes there would be more embedded projects using the pmOS tools outside just phones :)

2021-11-20 08:22:30 <ktprograms> Re GHC: So given the knowledge gained from this round of upgrading libffi, what would be the best course of action when a runtime dep gets a soname bump?
2021-11-20 08:30:15 <ikke> One option is to first rebuild ghc without --with-system-libffi, upgrade ffi, then rebuild again with it
2021-11-20 08:32:29 <ktprograms> ikke: Would it make sense to always have a version of ghc available that doesn't depend on anything other than musl (no other dynamic deps)?
2021-11-20 08:51:18 <ikke> maybe, but it does mean we have to maintain 2 ghc aports
2021-11-20 08:54:07 <ktprograms> ikke: Ok, I guess not having the other ghc and then just rebuilding would be ok as long as it's done in the order you said (don't upgrade ffi before ghc has been built to not depend on it).
2021-11-20 08:56:06 <ktprograms> Just a thought: that non system ffi version of GHC can be built and run just on the Alpine builders without needing to upload it to the repos, right?
2021-11-20 08:58:10 <ikke> no
2021-11-20 09:00:46 <ktprograms> Why?
2021-11-20 09:02:05 <ikke> built packages endup in the central repo that are automatically synced
2021-11-20 09:02:30 <ikke> And we do not want some kind of custom setup that needs to be maintained for each release
2021-11-20 09:02:42 <ktprograms> I see. Makes sense
2021-11-20 09:32:40 <ktprograms> Can someone please help with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27624? The tests seem to be failing on 32 bit architectures but I can't see why from the log
2021-11-20 09:41:12 <ikke> https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/542724#L604
2021-11-20 09:42:05 <ikke> That's on armv7
2021-11-20 09:42:52 <ikke> The other arches is less clear. Something returns an error code without mentioning why
2021-11-20 09:44:05 <ktprograms> Ok, looks like I'll have to debug with QEMU. Should I change the title to "Draft: ..." ?
2021-11-20 09:47:21 <ikke> You can, but it's obvious that the build is broken, so you don't have to be afraid that someone will accidentaly merge it
2021-11-20 09:51:27 <ktprograms> Ok, thanks
2021-11-20 11:12:06 <nmeum> can't we have two ghc packages like community/ghc and community/ghc-bootstrap and assign those a different provider_priority so community/ghc-bootstrap is only used once for bootstraping new builders? does that work?
2021-11-20 11:12:33 <nmeum> I was considering implementing something along those lines for testing/cyclone but haven't looked into that yet
2021-11-20 11:12:42 <ikke> We do not even need provider_priority for that
2021-11-20 11:12:45 <ikke> or
2021-11-20 11:13:02 <ikke> The problem is, how does the first package gets built on a new builder
2021-11-20 11:13:23 <ikke> nmeum: we certainly can have 2 packages
2021-11-20 11:13:41 <ikke> but if you have a ghc-bootstrap package, you need something like ghc-bootstrap-bootstrap
2021-11-20 11:14:07 <nmeum> right
2021-11-20 11:14:14 <ikke> (ghc now provides ghc-bootstrap already so that we can have ghc makedepends on itself)
2021-11-20 11:14:32 <nmeum> I mean we can have both (community/ghc and community/ghc-bootsrap) provide something like ghc-bootstrap-stage0
2021-11-20 11:15:17 <ikke> What benefits would that have?
2021-11-20 11:15:49 <ikke> There would be only one package that should use the bootstrap package (ghc itself)
2021-11-20 11:16:05 <ikke> (or stage0)
2021-11-20 11:16:31 <nmeum> I was think this would allow us to a) build ghc/cyclone/… without manuall intervention when bootstraping new builders and b) we can always bootstrap ghc/cyclone/… from scratch with the -bootstrap package in case we ran into issues with dynamic libraries
2021-11-20 11:17:03 <ikke> nmeum: so you mean a stage0 that can be built without ghc?
2021-11-20 11:17:16 <ikke> otherwise we always need manual intervention
2021-11-20 11:17:18 <nmeum> yes
2021-11-20 11:17:20 <ikke> ok
2021-11-20 11:17:44 <nmeum> community/ghc-bootstrap would not require a pre-existing ghc compiler e.g. by using the bindst or in cyclone's case by using the autogenerated bootstrap files provided by upstream
2021-11-20 11:17:45 <ikke> If it's possible, that's always preferable
2021-11-20 11:20:30 <nmeum> that should also be feasible for cabal, right? we have community/cabal and community/cabal-bootstrap provide cabal-bootstrap-stage0 (with community/cabal-bootstrap having the lower provider_priority), make community/cabal depend on cabal-bootstrap-stage0 and then it should compile fine without manual intervention when setting up new builders. right?
2021-11-20 11:21:20 <ikke> if we have cabal-bootstrap which can be built without cabal, we do not need that
2021-11-20 11:21:41 <ikke> nmeum: unless you want to make sure future cabal versions are built by cabal itself, not bootstrap
2021-11-20 11:21:52 <nmeum> yes, I assumed that would be desirable
2021-11-20 11:22:18 <ikke> right
2021-11-20 11:25:07 <ikke> Think that should work indeed. Just need to think about how to name each as to not cause confusion
2021-11-20 11:25:23 <nmeum> to generalize this a bit: for self-hosting stuff (like cabal, ghc, cyclone, …) upstream usually provides some sort of bootstrap path (e.g. static binaries (ghc), autogenerated files (cyclone), special scripts (cabal), …) and by providing two packages for stuff that is self-hosting (one with and one without -bootstrap) we would use upstream's desired boostraping path once and otherwise 
2021-11-20 11:25:23 <nmeum> just build self-hosting software with the previous version as available in the repos
2021-11-20 11:25:59 <ikke> The problem is that in most cases, they rely on bootstrapping from existing binaries, which have been trying to avoid as much as possible
2021-11-20 11:26:14 <ikke> jdk is still built from ghc6 -> openjdk7 -> ...
2021-11-20 11:28:01 <nmeum> but with self-hosting compilers you will always need to depend on some sort of pre-existing binary. I am sure our gcc version was also bootstrapped with a pre-existing gcc binary at some point
2021-11-20 11:28:56 <ikke> yes, like I said, as much as possible, but at some point, it becomes more difficult and difficult
2021-11-20 11:29:08 <ikke> and gcc is not possible to bootstrap without gcc
2021-11-20 11:29:39 <nmeum> yep, as with all self-hosting compilers (:
2021-11-20 11:29:56 <nmeum> my thinking is just: with something like ghc-bootstrap it would at least be transparent on which pre-existing binary we depended at some point
2021-11-20 11:30:40 <nmeum> for example, I think our current ghc version was initially cross-compiled from the ghc version packaged by ubuntu years ago but that's just hidden in the git history
2021-11-20 11:31:31 <skarnet> self-hosting is weird, it's a remnant of good academic correctness principles that is entirely at odds with ease of engineering and for once, for the only thing where it's objectively the wrong choice, projects choose academic correctness
2021-11-20 11:31:54 <skarnet> I can't help but interpret it as nerd wankery
2021-11-20 11:32:11 <skarnet> since it's harder, it must be better, right?
2021-11-20 11:33:45 <skarnet> what good is bootstrapping if in order to correctly bootstrap a piece of software I have to go back to the first version and do 8 builds successfully while every build takes 4 hours
2021-11-20 11:34:54 <skarnet> or, worse, "you have to download this binary from our site in order to perform a build from source", aka fake bootstrap
2021-11-20 11:35:31 <jvoisin> ikke: you can boostrap old gcc versions with tcc iirc
2021-11-20 11:35:49 <skarnet> jvoisin: my point exactly, you need to go back to gcc-4.3.4 or something
2021-11-20 11:36:03 <skarnet> and then build newer gccs incrementally
2021-11-20 11:36:16 <jvoisin> yes :'(
2021-11-20 11:36:16 <nmeum> tcc is also written in C. how do you bootstrap tcc then?
2021-11-20 11:36:20 <skarnet> how hard is it to just shorten the needed chain of trust
2021-11-20 11:36:26 <jvoisin> because no one writes C++ compilers.
2021-11-20 11:36:42 <nmeum> anyway, I don't think discussing self-hosting is productive. we just have to accept that it is a thing and deal with it somehow
2021-11-20 11:36:46 <skarnet> nmeum: well you build tcc with gcc, DUH
2021-11-20 11:37:25 <skarnet> yup, sorry for interrupting, I just felt like venting because nobody ever _questions_ those things
2021-11-20 11:37:44 <skarnet> and not questioning feels a lot like endorsing
2021-11-20 11:37:56 <nmeum> yeah, I totally get that (:
2021-11-20 11:39:03 <ikke> skarnet: I think it's also a matter of: I work on $superior_language, so I want to use $superior_language to build $superior_language
2021-11-20 11:39:21 <skarnet> see: nerd wankery
2021-11-20 11:40:13 <skarnet> brb rewriting execline in execline
2021-11-20 11:47:43 <nmeum> can we get back to my proposal of splitting ${repo}/${self_hosting_compiler} and ${repo}/${self_hosting_compiler}-bootstrap were the latter uses whatever upstreams recommends to get their stuff bootstraped, even if they recommend a "fake bootstrap"? wouldn't that be preferable to how we handle self-boostraping compiler presently (i.e. by making the bootstrap path more transparent)?
2021-11-20 11:48:01 <nmeum> if I am the only one who believes this to be a good idea I will stop talking about it :D
2021-11-20 11:53:05 <ikke> I think we need to make a decission whether we officially want to start depending on upstream binaries for self-hosted languages
2021-11-20 11:54:56 <nmeum> we already depend on existing binaries for self-hosted languages, it is just hidden atm
2021-11-20 11:56:38 <ikke> why hidden?
2021-11-20 11:56:47 <ikke> You mean from the bootstrap path in the past?
2021-11-20 11:59:37 <ikke> We do depend on our own binaries from edge, but that's not really hidden
2021-11-20 12:03:21 <nmeum> ikke: yes, we depend on our own binaries but these binaries depended on a binary provided by some else at some point for the initial version added to the alpine repos
2021-11-20 12:03:39 <skarnet> nmeum: having $compiler distinct from $compiler-bootstrap is the way I do it in my toolchain building tool, so I believe it's a good idea too :)
2021-11-20 12:04:21 <nmeum> with self-hosting compilers you have to trust not just the version you are building it with but also the version with which this version was build etc.
2021-11-20 12:04:39 <ikke> nmeum: yes, I understand that
2021-11-20 12:04:39 <skarnet> and yes it would be clearer to isolate the "depending on an external binary" ugliness in a separate package
2021-11-20 12:04:52 <skarnet> and have $compiler be a regular package that pretends to be clean
2021-11-20 12:05:04 <ikke> nmeum: didn't we bootstrap go from source?
2021-11-20 12:05:31 <ikke> for rust, we did use binaries from void from what I recall
2021-11-20 12:05:35 <nmeum> yes, go can be bootstraped from source with go 1.4 which is still written in C but only for some architecture
2021-11-20 12:05:43 <nmeum> but with go my proposal works fine as well
2021-11-20 12:06:19 <nmeum> we can package the go 1.4 compiler version again as community/go-bootstrap and use that for the initial bootstrap on some architectures but for architectures not supported by go 1.4 (e.g. riscv64) a different bootstrap path is needed
2021-11-20 12:08:11 <nmeum> I think I might send a mail to the alpine-devel ML to collect some feedback on this idea and might implement it for some simpler self-hosting compilers that I maintain (e.g. cyclone)
2021-11-20 12:10:14 <ikke> I mean I'm all for making it easier to bootstrap these packages in aports
2021-11-20 12:14:03 <mps> skarnet: very well told about problem
2021-11-20 12:15:02 <skarnet> thanks
2021-11-20 12:23:43 <nmeum> skarnet: https://bootstrappable.org/ you might be interested in this ;)
2021-11-20 12:25:11 <skarnet> nmeum: yes, I know and love this site :)
2021-11-20 12:26:06 <nmeum> that project is also compatible with what I am proposing for example we could just mrustc (rust compiler in C++) as community/rust-bootstrap, if mrustc is mature enough for doing so
2021-11-20 12:26:13 <nmeum> s/just/use/
2021-11-20 12:26:13 <alpine-meetbot> nmeum meant to say: that project is also compatible with what I am proposing for example we could use mrustc (rust compiler in C++) as community/rust-bootstrap, if mrustc is mature enough for doing so
2021-11-20 12:28:13 <skarnet> I think that's the least bad solution tbh
2021-11-20 12:28:53 <ericonr> It kinda isn't, cause mrustc is at an old rust, and it would take ages to actually build up to current rust from what it can compile 
2021-11-20 12:29:01 <ericonr> It's nice, but extremely impractical 
2021-11-20 12:31:14 <nmeum> no, I think they actually support building somewhat reason rust atm https://github.com/thepowersgang/mrustc/blob/master/build-1.54.0.sh
2021-11-20 12:31:19 <nmeum> *recent
2021-11-20 12:31:51 <nmeum> we package rust 1.15.6 atm
2021-11-20 12:32:35 <nmeum> *1.56.1
2021-11-20 12:33:31 <ericonr> nmeum: https://github.com/thepowersgang/mrustc/commit/6c7dfbc76f162d3a1a78bde4af4392384a62cf92
2021-11-20 12:33:59 <ericonr> And the readme hasn't added 1.54.0 yet to the list of supported versions :/
2021-11-20 12:35:35 <nmeum> *nod*
2021-11-20 12:35:58 <nmeum> I am not saying I want to switch to *mrustc*-based rustc bootstrapping *right now* but it is something that might become feasible in the future
2021-11-20 12:39:20 <skarnet> ^ that's my point, the package separation makes it easier to switch to that kind of solution if at all possible
2021-11-20 13:35:23 <nmeum> https://lists.alpinelinux.org/~alpine/devel/%3C33KG0XO61I4IL.2Z7RTAZ5J3SY6%408pit.net%3E
2021-11-20 13:35:45 <nmeum> ^ more detailed text which (hopefullys) summarizes the preceeding discussion
2021-11-20 13:35:49 <nmeum> *hopefully
2021-11-20 13:59:35 <ollieparanoid> hey all! can this MR be fast-tracked? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27630
2021-11-20 14:02:27 <ollieparanoid> thanks!
2021-11-20 14:02:32 <ikke> :)
2021-11-20 14:03:46 <caskd> ollieparanoid: you'll need a premium ticket for that, which you can get for 49.99$ a month :D
2021-11-20 14:09:46 <ollieparanoid> :D
2021-11-20 14:12:04 <Hello71> that's extremely cheap by enterprise support standards
2021-11-20 14:30:13 <mps> !27630
2021-11-20 15:25:59 <ikke> wait what
2021-11-20 15:26:05 <ikke> build-edge-mips64: failed to build libffi:
2021-11-20 15:26:21 <ikke> mips builder is back
2021-11-20 15:36:52 <lzsaver> new mips build machine?
2021-11-20 15:37:28 <ikke> No, same one
2021-11-20 15:39:06 <dalias> ikke, uhg why is libffi failing?
2021-11-20 15:39:32 <ikke> test failures, not sure why
2021-11-20 15:39:47 <ikke> FAIL: libffi.bhaible/test-call.c -W -Wall -Wno-psabi -DDGTEST=55 -Wno-unused-variable -Wno-unused-parameter -Wno-unused-but-set-variable -Wno-uninitialized -O0 execution test
2021-11-20 15:39:49 <ikke> and more like those
2021-11-20 17:00:21 <ikke> Ariadne: what supprises me most is that the mips64 builder has more then a year of uptime, so the builder itself apparently never was down
2021-11-20 17:00:32 <ikke> (mips builder)
2021-11-20 17:14:45 <boomanaiden154> On https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27514, I'm able to get a passing build in both a docker container on my machine and in a VM.
2021-11-20 17:15:46 <boomanaiden154> Seems to be failing on this: [17350:17350:1119/051420.139164:FATAL:credentials.cc(122)] Check failed: . : Function not implemented (38)
2021-11-20 17:16:22 <boomanaiden154> Does anyone know of any potential differences between the CI environment and my local environment that could be causing this?
2021-11-20 17:18:31 <Hello71> smells like gitlab again...
2021-11-20 17:18:53 <Hello71> also electron stinks
2021-11-20 17:20:36 <Hello71> did you try just restarting the build
2021-11-20 17:23:03 <boomanaiden154> I just tried restarting it. We'll see where that goes.
2021-11-20 17:23:19 <boomanaiden154> There's no electron in the package. FreeCAD is fully QT.
2021-11-20 17:34:08 <Hello71> qtwebengine then
2021-11-20 17:35:03 <ikke> Hello71: "smells like gitlab again"?
2021-11-20 17:35:32 <Hello71> gitlab runner i mean
2021-11-20 17:35:56 <ikke> You can get almost the same environment by using the alpinelinux/alpine-gitlab-ci docker image
2021-11-20 19:30:14 <boomanaiden154> ikke: I was able to get it running in a container with the alpinelinux/build-base image on my local machine.
2021-11-20 19:31:14 <boomanaiden154> QtWebEngine is definitely used by FreeCAD during startup, but I'm not really sure that's the issue if I can get it working in a very similar image on my machine.
2021-11-20 19:45:42 <Hello71> i think wait4 should be available everywhere
2021-11-20 19:46:40 <dalias> what's going on? some wacky seccomp?
2021-11-20 19:47:20 <Hello71> dunno
2021-11-20 19:49:46 <ericonr> qtwebengine in freecad is to display the welcome screen iirc
2021-11-20 19:50:05 <ikke> Embedding a browser just for a welcome screen?
2021-11-20 19:50:18 <ericonr> arguably useless, but it probably makes it closer to enterprise cad and that makes it more respectable to corporate sorts
2021-11-20 19:52:27 <dalias> eew
2021-11-20 19:52:40 <dalias> like, that should really just be patched out if so
2021-11-20 20:07:53 <mps> today I've got alpine running on apple M1 with mainline kernel 5.16-rc1 and number of patces, basic things works but not yet ready for daily usage
2021-11-20 20:11:51 <boomanaiden154> ericonr: FreeCAD does seem to just use it for the start screen. There might be some add-ons that use it though.
2021-11-20 20:12:41 <boomanaiden154> dalias: I don't think there's anything going on with seccomp unless the Alpine CI infrastructure has some abnormal configuration. Seems to be a possibility though.
2021-11-20 20:22:33 <Hello71> ah, it's not wait4, it's clone
2021-11-20 20:27:09 <Hello71> https://invent.kde.org/qt/qt/qtwebengine-chromium/-/blob/d33026ed7c5f25bd0c7936963021936148015522/chromium/sandbox/linux/services/credentials.cc#L122
2021-11-20 20:28:01 <Hello71> wait, no, it's unshare
2021-11-20 20:29:05 <Hello71> and under new docker, unshare in unprivileged container returns ENOSYS instead of EPERM
2021-11-20 20:29:11 <Hello71> sigh
2021-11-20 20:34:10 <Hello71> can someone test docker run alpine:edge 'unshare -U true' and docker run --privileged alpine:edge 'unshare -U true'?
2021-11-20 20:35:54 <boomanaiden154> I'm getting an operation not permitted in the unprivileged container and it seems to work fine in the privileged container.
2021-11-20 20:37:11 <Hello71> hm. docker/runc version?
2021-11-20 20:37:42 <boomanaiden154> Docker version 20.10.8.
2021-11-20 20:40:02 <Hello71> runc?
2021-11-20 20:40:18 <boomanaiden154> 1.0.2
2021-11-20 20:42:31 <Hello71> hm.
2021-11-20 20:53:55 <Hello71> yeah, i'm out of ideas. it must be caused by clone or unshare returning ENOSYS instead of EPERM but i don't know why
2021-11-20 20:55:28 <boomanaiden154> Yeah. They're definitely restricted in the default seccomp profile for Docker, but it should be failing on my local machine as well.
2021-11-20 20:55:36 <boomanaiden154> Definitely more direction than what I had before for debugging though.
2021-11-20 20:55:38 <boomanaiden154> Thanks for the help.
2021-11-20 21:05:23 <Hello71> ikke, dalias: do you have an idea why that would be?
2021-11-20 21:08:18 <ikke> Hello71: I see that I still have a custom seccomp.json on that host
2021-11-20 21:08:26 <Hello71> oh, that's probably why then
2021-11-20 21:08:39 <Hello71> i forgot that i recommended that
2021-11-20 21:09:09 <Hello71> best delete it, it's only causing problems with runc 1.0.0+
2021-11-20 21:09:38 <ikke> Removed it
2021-11-20 21:09:51 <ikke> boomanaiden154: can you try again?
2021-11-20 21:52:51 <dalias> that sounds like it could be the problem
2021-11-20 22:10:43 <mps> grub is not in good shape on alpine, but someone who better understand it should fix it before 3.15 release
2021-11-20 22:11:59 <mps> at least /etc/default/grub file need more options added there, as comments maybe
2021-11-20 22:18:54 <mps> oh, to not forger ttyACM[0-9] rule should be added to mdev.conf
2021-11-20 22:19:02 <mps> forget*
2021-11-20 22:39:53 <boomanaiden154> ikke: Just retried it and it worked. Thank you.
2021-11-20 22:40:51 <ikke> boomanaiden154: ah, very good
2021-11-20 22:57:41 <minimal> mps: which options do you think need added to /etc/default/grub?
2021-11-20 22:59:01 <mps> minimal: at least GRUB_CMDLINE_LINUX_DEFAULT=
2021-11-20 22:59:34 <mps> timeout probably, terminal maybe, idk all
2021-11-20 23:01:57 <mps> hmm, GRUB_CMDLINE_LINUX
2021-11-20 23:02:45 <mps> minimal: that was my issue with booting in qemu I talked here few days ago
2021-11-20 23:04:32 <minimal> mps: all? I've used options like GRUB_DISABLE_RECOVERY, GRUB_TIMEOUT, GRUB_CMDLINE_LINUX_DEFAULT, GRUB_DISABLE_LINUX_UUID, GRUB_TERMINAL, GRUB_ENABLE_CRYPTODISK, GRUB_SERIAL_COMMAND in various situations but not sure which would make sense to include by default
2021-11-20 23:05:57 <minimal> mps: re GRUB_CMDLINE_LINUX it and GRUB_CMDLINE_LINUX_DEFAULT are slightly different, one of them applies only to "normal" boot and the other applies to both "normal" and "recovery" boot, can't remember which is which
2021-11-20 23:06:18 <mps> minimal: I mean add them commented for users to not search over internet
2021-11-20 23:06:39 <minimal> mps: they're all documented in the Grub info file
2021-11-20 23:07:04 <mps> hackers read info files? ;)
2021-11-20 23:07:36 <minimal> mps: but of course :-)
2021-11-20 23:08:52 <mps> I didn't used grub for years but now when everything need it I have to relearn it again
2021-11-20 23:14:18 <minimal> mps: you could always look at my script to see which options I'm adding to /etc/default/grub for QEMU VMs :-)
2021-11-20 23:15:17 <mps> sure, but I can't look anything when machine doesn't boot :)
2021-11-20 23:16:58 <mps> minimal: thanks for list of options
2021-11-20 23:17:18 <mps> now I'm going to bed, good night
2021-11-20 23:17:36 <minimal> mps: I meant the likes of https://github.com/dermotbradley/create-alpine-disk-image/blob/main/create-alpine-disk-image#L1274 and https://github.com/dermotbradley/create-alpine-disk-image/blob/main/create-alpine-disk-image#L1311 onwards
2021-11-21 04:09:25 <Ganonk> hello 
2021-11-21 04:10:08 <Ganonk> is possible to create disk for : /root and swap only?
2021-11-21 04:11:27 <Ganonk> how to create /root and swap only? https://paste.pics/F1QKL
2021-11-21 04:11:34 <Ganonk> please help me
2021-11-21 04:21:47 <psykose> do it manually
2021-11-21 04:23:42 <Ganonk> psykose : how to? what option i'm select..
2021-11-21 04:24:55 <ktprograms> Re " 3  2
2021-11-21 04:25:11 <psykose> manually format the disk however you want and mount the disk then setup-disk /mounted/disk
2021-11-21 04:25:51 <Ganonk> psykose : any tutorial Sir?
2021-11-21 04:26:01 <psykose> you will probably also need to modify some things in syslinux without a boot partition
2021-11-21 04:26:12 <psykose> none that i can think of, so you are better off just doing nothing and using what works already
2021-11-21 04:26:36 <ktprograms> Re "Thoughts on self-hosting compilers in Alpine": I would think that having to manually install the ${self_hosting_compiler}-bootstrap from edge when making a new Alpine release wouldn't be too much trouble since it's only done every 6 months?
2021-11-21 04:27:02 <ktprograms> Besides, how is alpine-sdk installed currently to start building non self hosting compilers?
2021-11-21 04:28:08 <Ganonk> psykose : thanks for your attentions :)
2021-11-21 04:34:55 <ktprograms> Clarifying my second message: I meant isn't alpine-sdk already installed as part of the new release process and can't the -bootstrap packages for self hosting compilers just be added to the list of things to install?
2021-11-21 04:37:43 <ktprograms> xvfb-run seems to be broken when running abuild rootbld with CBUILD_ARCH set to armv7 (on an aarch64 host)
2021-11-21 05:31:27 <AboothahirU[m]> How long it takes to compile Mesa driver? 
2021-11-21 05:34:35 <psykose> depends on your hardware
2021-11-21 05:48:08 <psykose> took me 12 minutes to abuild -r mesa while using 25% of the cpu for something else, on a 8 thread laptop
2021-11-21 05:55:27 <AboothahirU[m]> <psykose> "took me 12 minutes to abuild -..." <- are u compiling mesa 21.3.0 ?
2021-11-21 05:55:54 <psykose> i built.. 21.2.5
2021-11-21 05:56:00 <ktprograms> Can you believe that xvfb doesn't work in QEMU user mode emulation (chroot)?
2021-11-21 05:56:05 <AboothahirU[m]> <psykose> "depends on your hardware" <- core 2 duo processor and i am runnng alpine aarch64 in QEMU 
2021-11-21 05:56:06 <psykose> i don't think it magically takes longer on the new version
2021-11-21 05:56:18 <psykose> well, then it's probably gonna take over an hour
2021-11-21 05:56:23 <psykose> or more
2021-11-21 05:56:41 <AboothahirU[m]> but i need to compile llvm12 first ?
2021-11-21 05:56:48 <psykose> no, it all comes from packages
2021-11-21 05:57:10 <AboothahirU[m]> i am compiling mesa 21.3.0 
2021-11-21 05:57:17 <psykose> llvm12 is in edge at least
2021-11-21 05:57:27 <psykose> if you are using 3.14 then yes, you would also need to build llvm yourself
2021-11-21 05:57:34 <psykose> with that setup it would probably take over a day
2021-11-21 05:58:32 <AboothahirU[m]> compiling llvm12 currently ..it seems more than a day 
2021-11-21 05:59:19 <psykose> you can just upgrade your alpine to edge
2021-11-21 05:59:22 <psykose> and use llvm12-dev
2021-11-21 05:59:35 <AboothahirU[m]> from where i can get llvm12-dev
2021-11-21 06:00:10 <psykose> `apk add llvm12-dev` with edge repos
2021-11-21 06:01:05 <AboothahirU[m]> how to upgrade to edge
2021-11-21 06:01:39 <psykose> you change the 
2021-11-21 06:01:53 <psykose> 'v3.14' in /etc/apk/repositories to 'edge' and `apk upgrade -Ua`
2021-11-21 06:18:57 <AboothahirU[m]> thanks
2021-11-21 07:12:01 <mps> Ganonk: docs.alpinelinux.org and section about installation, setting some env variables before run setup-alpine
2021-11-21 07:12:25 <mps> swap and root size
2021-11-21 07:30:01 <ktprograms> Has anyone used picom successfully on a 32 bit architecture? Because it is segfaulting in tests. The backtrace seems to be #0 in memchr and #1 in strnlen
2021-11-21 07:32:16 <ericonr> ktprograms: Check if it prints a time_t variable anywhere
2021-11-21 07:32:43 <ericonr> Or well, just find where it's calling a printf() like function 
2021-11-21 07:34:05 <ericonr> It's probably printing time_t using a %ld format and then a string, which means it uses complete garbage for the string 
2021-11-21 07:36:13 <ikke> that's why you were looking at xvfb
2021-11-21 07:37:01 <ktprograms> ericonr: No time_t anywhere.
2021-11-21 07:37:31 <ktprograms> ikke: Yeah, in the end I had to use a full qemu vm. But it's slooooow...
2021-11-21 07:37:57 <ikke> which arch??
2021-11-21 07:38:02 <ikke> x86?
2021-11-21 07:38:07 <ktprograms> x86 emulation on aarch64 host
2021-11-21 07:38:10 <ikke> ah
2021-11-21 07:38:23 <ikke> isn't it easier to use armv7?
2021-11-21 07:38:29 <ikke> or is it only on x86
2021-11-21 07:38:49 <ikke> You can run armv7 native on many aarch64 hosts
2021-11-21 07:38:59 <ktprograms> Couldn't get the armv7 image to boot. Anyway wouldn't be any speed increase since the M1 doesn't have 32bit mode
2021-11-21 07:39:08 <ikke> oh, m1, ok
2021-11-21 07:39:40 <ikke> That's how we build armhf and armv7, on aarch64 in 32-bits mode
2021-11-21 07:39:45 <ikke> same with x86
2021-11-21 07:46:09 <ktprograms> This is the backtrace: https://gist.github.com/ktprograms/3ff9bcdf0bda428c3a63c7293d90de68. What's weird is the #2 0x7fffffff.
2021-11-21 07:46:41 <mps> ktprograms: https://arvanta.net/alpine/install-armv7-qemu/
2021-11-21 07:47:48 <maribu> dalias: The email containing the v4l-utils patch is still awaiting moderator approval. Let's wait till Monday, but it looks like I sent the email to /dev/null
2021-11-21 07:48:11 <ktprograms> mps: Thanks!
2021-11-21 07:48:45 <ktprograms> How do I enable debug building when the build process is abuild-meson build and meson compile?
2021-11-21 07:49:21 <mps> ktprograms: this iso is something I created for our users and devs so they can test armv7, it is not official iso
2021-11-21 07:49:32 <ikke> ktprograms: you need at least add a dbg- subpackage
2021-11-21 07:51:59 <ktprograms> mps: what's the difference form the standard iso?
2021-11-21 07:52:20 <ktprograms> ikke: I just want to compile it with debug symbols to see why it's segfaulting
2021-11-21 07:53:06 <mps> ktprograms: it uses linux-edge-virt kernel instead of linux-virt from linux-lts aports
2021-11-21 07:53:46 <ktprograms> I wonder if the picom segfault is related to the large number of warnings produced during the compile about long long int and %lu format strings?
2021-11-21 07:53:53 <ikke> ktprograms: adding a -dbg subpackages also sets -Og for CFLAGS
2021-11-21 07:54:08 <ktprograms> mps: What exactly in the linux-edge-virt is needed to boot in qemu?
2021-11-21 07:54:25 <ktprograms> ikke: Oh, I see. Thanks.
2021-11-21 07:54:58 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2802
2021-11-21 07:55:03 <ikke> sorry, -g, not -Og
2021-11-21 07:55:07 <mps> ktprograms: LPAE for using more RAM and some other tweaks
2021-11-21 07:55:52 <ktprograms> mps: If that's all, then I think my problem is I didn't have the -bios AAVMF32_CODE.fd line.
2021-11-21 07:56:49 <mps> ktprograms: yes, and in my script you can find how to download and extract it from debian
2021-11-21 07:57:53 <mps> ktprograms: ofc, we can use qemu u-boot but then it is somewhat more complicated to install from iso img
2021-11-21 07:58:07 <ktprograms> mps: It's ok, UTM.app has edk2-arm-code.fd that I can probably use with pure commandline qemu, it's just that I didn't think it was needed.
2021-11-21 08:02:50 <ktprograms> ikke: Can you look at these warnings in the picom build log: https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/542724#L386 until L509 ? Do you think it's releated to the segfault?
2021-11-21 08:03:58 <ktprograms> Has anyone used picom on any 32bit cpu?
2021-11-21 08:05:24 <mps> ktprograms: just tested on armv7, it doesn't fail
2021-11-21 08:06:40 <ktprograms> mps: What did you test?
2021-11-21 08:07:01 <mps> ktprograms: basic start and type few chars
2021-11-21 08:07:31 <ktprograms> "type a few chars"?
2021-11-21 08:07:49 <ktprograms> I'm talking about picom the compositor not picocom the serial console btw
2021-11-21 08:08:22 <mps> ktprograms: ohm, sorry, I missread your msg
2021-11-21 08:09:25 <ktprograms> mps: I'm trying to see why the tests for picom cause it to segfault on x86, armv7 and armhf. So I want to know if it's faulty tests or that it's just broken
2021-11-21 08:10:23 <ktprograms> btw what is dev.alpinelinux.org and what's it used for?
2021-11-21 08:12:10 <mps> ktprograms: it is for alpine devs to put whatever they think should be available  and not for 'official' usage
2021-11-21 08:12:30 <ktprograms> I see
2021-11-21 08:17:45 <ktprograms> lol I just typed Ctrl-A 'x' meaning to start typing 'x' at the start of the line but instead killed qemu running with -serial mon:stdio
2021-11-21 08:18:35 <ikke> heh
2021-11-21 08:35:54 <ktprograms> What vnc server should I use?
2021-11-21 08:57:20 <idkrn> Is there anywhere I can find documentation on ash?
2021-11-21 09:00:59 <psykose> what little exists is here https://git.busybox.net/busybox/tree/shell
2021-11-21 09:03:57 <idkrn> I though ash was just for Alpine?
2021-11-21 09:04:07 <idkrn> I guess I misunderstoof lol
2021-11-21 09:04:10 <psykose> it doesn't stand for alpine shell :)
2021-11-21 09:04:13 <idkrn> lol
2021-11-21 09:04:16 <psykose> almquist
2021-11-21 09:04:22 <idkrn> is it from netbsd or whatever
2021-11-21 09:04:35 <psykose> original 'ash' is from the 80's probably, let's see...
2021-11-21 09:04:36 <idkrn> I forget what the history of Alpine is
2021-11-21 09:04:58 <idkrn> yea I read something about that around 5 min ago lol
2021-11-21 09:05:03 <psykose> https://www.in-ulm.de/~mascheck/various/ash/
2021-11-21 09:05:19 <idkrn> that was fast
2021-11-21 09:05:28 <psykose> remembered where to look, been there
2021-11-21 09:05:51 <psykose> if you can be specific on what docs you want i might be able to provide something specific
2021-11-21 09:05:58 <idkrn> I just wanted to know what files ash read first and what the simplest way to always source $HOME/.ashrc is
2021-11-21 09:06:20 <ikke> idkrn: You need to set ENV to a file for it to read it on non-login shells
2021-11-21 09:06:28 <psykose> yep
2021-11-21 09:06:33 <ikke> for login shells, it reads /etc/profile
2021-11-21 09:06:44 <psykose> and ~/.profile
2021-11-21 09:06:51 <ikke> right
2021-11-21 09:07:28 <psykose> if you want to work with both login and regular, you can use a trick
2021-11-21 09:07:39 <psykose> https://unix.stackexchange.com/a/418715
2021-11-21 09:08:33 <idkrn> is it using ENV in /etc/profile?
2021-11-21 09:08:47 <idkrn> was just confused as to why there's no "official" way
2021-11-21 09:08:49 <psykose> internal to shell
2021-11-21 09:09:08 <idkrn> what does that mean
2021-11-21 09:09:55 <psykose> the code of the shell reads ENV
2021-11-21 09:10:24 <ikke> without ENV, ash does not read any files for non-login shells
2021-11-21 09:10:33 <ikke> s/read/source
2021-11-21 09:10:34 <alpine-meetbot> ikke meant to say: without ENV, ash does not source any files for non-login shells
2021-11-21 09:11:03 <idkrn> ok
2021-11-21 09:11:13 <psykose> specifically ash.c:14665 reads it
2021-11-21 09:11:19 <psykose> if you want to read the code for it
2021-11-21 09:11:30 <idkrn> i read a long time ago to put ENV='$HOME/.ashrc' >> /etc/profile
2021-11-21 09:11:35 <idkrn> is this this most common way?
2021-11-21 09:11:57 <psykose> that wouldn't work for non-login
2021-11-21 09:12:09 <idkrn> I only want it for my interative shell for now
2021-11-21 09:12:18 <psykose> then you can just put things in ~/.profile
2021-11-21 09:12:25 <psykose> login shells source that
2021-11-21 09:12:34 <idkrn> really
2021-11-21 09:12:48 <idkrn> so what would I do if I wanted to use ENV
2021-11-21 09:13:07 <idkrn> ENV='file'?
2021-11-21 09:13:09 <psykose> but i think then you will have to set your terminals shell to `ash -l` for terminals to read it, as by default those aren't login
2021-11-21 09:13:10 <psykose> yes
2021-11-21 09:14:16 <idkrn> how do you get a .zshrc equivalent for interactive shells only
2021-11-21 09:15:09 <ikke> You need to export ENV
2021-11-21 09:15:09 <idkrn> also do you mean with ash -l from chsh?
2021-11-21 09:15:18 <idkrn> in /etc/profile?
2021-11-21 09:15:22 <psykose> no, your terminal has a shell that it starts
2021-11-21 09:15:34 <idkrn> where is that called?
2021-11-21 09:16:04 <psykose> your terminal starts a shell when you open it, and most likely somewhere in that config you set what shell you use
2021-11-21 09:16:18 <idkrn> oh I was talking about a tty
2021-11-21 09:16:35 <idkrn> I use alacritty which has a shell: variable
2021-11-21 09:16:41 <psykose> when you log in on tty it's always a login shell
2021-11-21 09:17:00 <ikke> And if you export ENV there, it will be in affect for all terminals
2021-11-21 09:17:04 <psykose> yep
2021-11-21 09:17:35 <idkrn> where do I look for that
2021-11-21 09:17:42 <psykose> if you really want to make a profile for interactive only, you would have to make the ENV= profile have a check for interactive in it
2021-11-21 09:17:52 <psykose> look for ENV? you just set it, it's an env variable
2021-11-21 09:18:05 <idkrn> no the file that reads it first
2021-11-21 09:18:13 <idkrn> or where it would be read first
2021-11-21 09:18:19 <psykose> reads what first
2021-11-21 09:18:25 <idkrn> or just /etc/profile
2021-11-21 09:18:52 <idkrn> psykose: I think I need to sleep
2021-11-21 09:18:55 <psykose> when ash starts as a login shell, it reads /etc/profile, $HOME/.profile is HOME is defined, and $ENV
2021-11-21 09:18:58 <idkrn> Im confusing myself
2021-11-21 09:19:02 <psykose> if it's not a login shell, it does only the ENV
2021-11-21 09:19:27 <psykose> so, you can define ENV and export it in ~/.profile
2021-11-21 09:19:31 <ikke> Hmm, you cannot look at $0 to see if it's interactive
2021-11-21 09:19:34 <psykose> and then when you log in on tty, it will be set
2021-11-21 09:19:47 <psykose> and be read, and then subsequent shells will all read ENV
2021-11-21 09:20:15 <ikke> ah, $-
2021-11-21 09:21:20 <idkrn> I had this in a setup script to run on fresh installs, `echo 'ENV=/root/.ashrc'`
2021-11-21 09:21:28 <idkrn> that's not what youre talking about thought is it
2021-11-21 09:22:01 <psykose> i have no idea what that sets up, but that is exactly what i am talking about in general
2021-11-21 09:22:27 <idkrn> after that I just make a ~/.ashrc
2021-11-21 09:22:31 <psykose> just put `export ENV="$HOME/.ashrc` in ~/.profile and the rest in .ashrc and you will get what you want
2021-11-21 09:22:52 <idkrn> oh my mistake was putting it in /etc/profile
2021-11-21 09:23:01 <psykose> it works there too
2021-11-21 09:23:16 <ktprograms> This is the worst! picom works completely fine and the running the basic.py test doesn't segfault when running without xvfb.
2021-11-21 09:23:31 <psykose> time to run with xvfb :)
2021-11-21 09:23:46 <idkrn> I've only ever really used Sway lol
2021-11-21 09:23:46 <ktprograms> Could it be that xvfb -s "+extension composite" is broken on 32 bit archs?
2021-11-21 09:23:58 <ktprograms> psykose: What do you mean?
2021-11-21 09:24:19 <psykose> well you said without xvfb :p so you have to test it with it
2021-11-21 09:24:21 <psykose> just a jest
2021-11-21 09:24:49 <idkrn> psykose: would I have to write ENV=/$HOME/.ashrc in /root/.profile and in /home/user/.ashrc??
2021-11-21 09:25:09 <ikke> idkrn: https://linux.die.net/man/1/ash
2021-11-21 09:25:09 <psykose> only in .profile 
2021-11-21 09:25:12 <psykose> and you have to export it
2021-11-21 09:25:13 <ikke> section Invocation
2021-11-21 09:25:38 <idkrn> oh I think I did ENV ENV='... before
2021-11-21 09:25:40 <psykose> if you don't export it's not going to be read by any subsequent shells as env is unset for them
2021-11-21 09:25:57 <psykose> you can see whatever non-working shell you are in right now and check the echo $ENV
2021-11-21 09:26:33 <idkrn> non-working?
2021-11-21 09:26:39 <idkrn> am i asking dumb questions?
2021-11-21 09:27:40 <idkrn> ikke: is ash almost a vanilla /bin/sh?
2021-11-21 09:28:02 <ikke> not sure what you mean with vanilla, but it's mostly a posix shell
2021-11-21 09:28:32 <idkrn> I mean almost pure posix
2021-11-21 09:28:39 <ikke> On alpine, some bash specific extensions are enabled
2021-11-21 09:28:51 <ikke> things like ${foo/a/b}
2021-11-21 09:28:57 <idkrn> yea there's no man page
2021-11-21 09:29:01 <idkrn> so where did you read that from
2021-11-21 09:29:11 <ikke> Where did I read what from?
2021-11-21 09:29:14 <idkrn> yea
2021-11-21 09:29:18 <idkrn> wait
2021-11-21 09:29:23 <ikke> https://linux.die.net/man/1/ash
2021-11-21 09:29:45 <idkrn> why does that just say /bin/sh then?
2021-11-21 09:30:14 <idkrn> it looks like the dash man page to me
2021-11-21 09:30:20 <idkrn> never mind I guess
2021-11-21 09:30:58 <idkrn> how is `ENV=$HOME/.shinit; export ENV` different from `export ENV=$HOME/.shinit`
2021-11-21 09:31:24 <ikke> they are not, except that the latter syntax is not supported by all shells
2021-11-21 09:31:52 <idkrn> so a purely posix shell may not understand the latter?
2021-11-21 09:32:00 <ikke> correct
2021-11-21 09:32:11 <idkrn> I'll try to remember that
2021-11-21 09:32:51 <idkrn> I'm feeling like using && it looks better than a semi-colon
2021-11-21 09:34:21 <idkrn> Can I write that to /etc/profile so that I don't need to add it to ~/.profile for every user?
2021-11-21 09:35:47 <idkrn> 1 more question
2021-11-21 09:36:31 <idkrn> if a package in the stable community repo gets an update due to a CVE, will stable repos get the update as soon as edge users would?
2021-11-21 09:38:17 <ikke> It needs to be seperately backported
2021-11-21 09:38:27 <ikke> the stable branch might even have a different version
2021-11-21 09:38:57 <idkrn> meaning the CVE might not even apply?
2021-11-21 09:39:24 <ikke> either that, or it needs to be updated to a different version
2021-11-21 09:39:37 <ikke> 1.5.x vs 2.0.x for example
2021-11-21 09:40:00 <idkrn> so which branch would theoretically get patches from the CVE first assuming it affects both branches
2021-11-21 09:40:16 <ikke> It depends on the one updating the packages
2021-11-21 09:40:23 <ikke> But people tend to start with edge
2021-11-21 09:40:46 <idkrn> I'm assuming that for packages in main it would make little difference
2021-11-21 09:41:11 <ikke> how so?
2021-11-21 09:41:28 <idkrn> well it's managed by the main dev team right?
2021-11-21 09:42:10 <idkrn> I'm just slightly confused as to whether I should run edge or not
2021-11-21 09:42:43 <ikke> edge is more volatile, so there could be breakages from time to time
2021-11-21 09:42:47 <idkrn> the wiki advises against edge for end users due to possible breakage, but I assumed edge would get patches first
2021-11-21 09:43:08 <idkrn> I tend to keep my systems somewhat lightweight
2021-11-21 09:43:25 <ikke> If feasible, we try to upgrade all branches more or less around the same time
2021-11-21 09:43:27 <idkrn> I've never broken an arch system (I didn't use it a ton though)
2021-11-21 09:44:03 <ikke> but arch is a rolling-release first distro. They have testing repos where they tend to roll out changes first
2021-11-21 09:44:08 <ikke> edge is our testing repo
2021-11-21 09:44:18 <idkrn> so in terms of security patches for packages in main, it doesn't make a big difference?
2021-11-21 09:44:37 <idkrn> or would you reccomend stable
2021-11-21 09:45:08 <ktprograms> And then NOW I see that running the run_tests.sh EVEN without xvfb still segfaults the same way...
2021-11-21 09:45:32 <ikke> The latest stable release is very closes to edge, so security fixes typically can be applied easily
2021-11-21 09:45:44 <idkrn> I would much rather use Alpine than Arch, but I would like to understand if using packages from edge might be an additional risk
2021-11-21 09:46:02 <ikke> idkrn: what kind of risk
2021-11-21 09:46:10 <idkrn> unpatched CVEs
2021-11-21 09:46:27 <ikke> Should not matter a lot
2021-11-21 09:46:42 <idkrn> I like having the most up to date packages, but security comes first
2021-11-21 09:46:48 <idkrn> ok that's good to now
2021-11-21 09:47:01 <ikke> like I said, packages in edge tend to be updated first
2021-11-21 09:47:14 <idkrn> newest packages + strong security sounds good lol
2021-11-21 09:47:19 <idkrn> ok thanks for helping
2021-11-21 09:47:54 <idkrn> btw I'm only familiar with Matrix, not IRC. Does the "@" in front of your name mean youre a dev?
2021-11-21 09:48:24 <ikke> It means I'm a channel operator
2021-11-21 09:48:41 <idkrn> same thing in this case I guess
2021-11-21 09:49:01 <idkrn> anyway thanks
2021-11-21 09:57:09 <idkrn> this is unimportant now, but I found this in ash.c
2021-11-21 09:57:17 <idkrn> if (login_sh) {
2021-11-21 09:57:17 <idkrn> 		read_profile("/etc/profile");
2021-11-21 09:57:17 <idkrn> 		state = 1;
2021-11-21 09:57:17 <idkrn>  state1:
2021-11-21 09:57:17 <idkrn> 		const char *hp;
2021-11-21 09:57:19 <idkrn> 		state = 2;
2021-11-21 09:57:22 <idkrn> 		hp = lookupvar("HOME");
2021-11-21 09:57:24 <idkrn> 		if (hp)
2021-11-21 09:57:27 <idkrn> 			read_profile("$HOME/.profile");
2021-11-21 09:57:29 <idkrn> oops
2021-11-21 09:59:17 <psykose> yep, and right below that you can see the ENV lookupvar
2021-11-21 09:59:49 <idkrn> I realize that it may basically be a "sibling" to dash
2021-11-21 10:03:18 <psykose> it was started from dash code
2021-11-21 10:03:40 <psykose> which was started from the netbsd code, and so on
2021-11-21 10:03:45 <psykose> it's kinda like the ircd history
2021-11-21 10:03:50 <idkrn> right
2021-11-21 10:04:28 <idkrn> yea I see the 'derived from... Almquist'
2021-11-21 10:08:22 <ktprograms> well it looks like picom segfaults when you specify --log-level=debug. So probably a problem with 32 bit ints vs 64 bit ints
2021-11-21 10:09:52 <ktprograms> How do 64 bit ints work on 32 bit systems? Is it 2 consecutive memory addresses seamlessly treated as 1 64 bit int by the compiler?
2021-11-21 10:14:26 <psykose> the first thing i checked with a %d is actually a uint32_t
2021-11-21 10:14:39 <psykose> so i would guess somewhere in the code the segfault is indeed caused by this
2021-11-21 10:16:00 <ktprograms> I just tested. If your format string is "%ld %s" but then supply a uint64_t for the first arg, it segfaults
2021-11-21 10:16:32 <psykose> that is generally "%" PRIu64 " %s" or somesuch iirc, if done properly
2021-11-21 10:17:10 <psykose> from inttypes.h
2021-11-21 10:18:19 <ktprograms> psykose: Yeah, the point is that picom doesn't do that and so logging is broken on 32bit archs
2021-11-21 10:18:24 <psykose> yep
2021-11-21 10:18:34 <psykose> and %l is definitely not 64bit on 32bit
2021-11-21 10:19:22 <psykose> %llu should work, i believe that is the same as uint64_t on 32 and 64 bit
2021-11-21 10:19:29 <psykose> or just using the PRI macros
2021-11-21 10:19:32 <psykose> sounds like a fun patch
2021-11-21 11:50:36 <alandiwix> mps: would it make sense to move sway backgrounds into the separate sway-backgrounds package? they take 4.9 out of 5MB
2021-11-21 12:14:54 <clandmeter> mps: do we need kernel firmware when building the kernel?
2021-11-21 12:44:47 <Hello71> ikke: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export
2021-11-21 12:47:05 <Hello71> ktprograms: despite what is shown in introductory computer science textbooks, memory does not exist as "slots" in modern CPU architectures. uint64_t is implemented as accessing 8 bytes starting from a given memory address
2021-11-21 12:47:39 <ktprograms> Hello71: I see. thanks
2021-11-21 12:51:19 <Hello71> (note that 128-bit integers are an exception and are usually implemented as software emulation as you said)
2021-11-21 12:52:38 <ktprograms> But wouldn't 64 bit ints on 32 bit cpus still be twice as long since by definition a 32 bit cpu's ALU only handles 32 bits at once?
2021-11-21 12:52:38 <Hello71> but this is part of the reason why the strict segmentation of machines into "32-bit" and "64-bit" is misleading: x86-32 supports 64-bit integers but only 32-bit pointers, whereas x86-64 supports only 64-bit pointers but normally uses 32-bit integers
2021-11-21 12:53:05 <Hello71> no, see my last message
2021-11-21 12:53:07 <ktprograms> Oh, I see.
2021-11-21 12:53:16 <ktprograms> So the ALU is 64 bits wide?
2021-11-21 12:54:08 <Hello71> roughly speaking. i'm not sure if all operations are equally fast on 32-bit and 64-bit inputs though. for example integer division is frequently slower on wider inputs
2021-11-21 12:54:58 <ktprograms> Does the same apply for arm?
2021-11-21 12:56:17 <Hello71> not sure. you can play around with https://gcc.godbolt.org/ and see the assembly generated for different architectures
2021-11-21 13:00:30 <Hello71> these kinds of things can also vary with ISA extensions; for example on x86, the "standard" floating-point instructions use the weird x87 80-bit floats, and you need SSE/SSE2 to get normal IEEE 754-ish behavior
2021-11-21 13:01:45 <ktprogra1s> Hello71: my IRC client VM crashed, but I saw your messages on the alpine irclogs anyway
2021-11-21 13:01:58 <Hello71> mm.
2021-11-21 13:02:17 <ktprogra1s> 80 bit floats? that's wierd
2021-11-21 13:10:16 <ericonr> ktprograms: the compiler warnings are extremely relevant, because it's the exact issue I pointed out 
2021-11-21 13:10:33 <ericonr> If it's not time_t, it's some other type
2021-11-21 13:11:27 <ktprograms> ericonr: Yep, that turned out to be the problem. Interesting that the picom tests have never been run on 32 bit architectures.
2021-11-21 13:11:43 <ericonr> Welcome to modern software ;)
2021-11-21 13:12:06 <ericonr> Sometimes upstream doesn't even care to fix broken hashing code for 32 bit archs
2021-11-21 13:12:23 <ktprograms> ericonr: hashing code?
2021-11-21 13:12:38 <ericonr> Yeah, code for computing a hash
2021-11-21 13:13:00 <ktprograms> Why would it be broken on 32 bits?
2021-11-21 13:14:07 <ericonr> In this case, it was Rust and type confusion because they were using usize
2021-11-21 13:15:14 <ktprograms> Well I don't know rust so I don't really know what that means
2021-11-21 13:18:39 <Newbyte> ktprograms: usize is the size of a pointer, and therefore is varies depending on what hardware you're on
2021-11-21 13:21:01 <ktprograms> Oh that makes sense
2021-11-21 13:24:15 <mps> alandiwix: I don't know anything about sway except it is pkg in alpine, so don't have any 'think' about it
2021-11-21 13:24:42 <mps> clandmeter: no, we don't need firmware for building kernel
2021-11-21 13:29:26 <alandiwix> mps: I mean, the backgrounds are not necessary for functioning, moreover, afaik, they are not even enabled by default. I think we could ask ddevault about it, but IMO it's not good that sway (wayland compositor) has ~90% of it's package size as png wallpapers of different resolutions.
2021-11-21 13:30:07 <ddevault> they are enabled by default, and many other desktops have 
2021-11-21 13:30:10 <ddevault> much more in the way of assets
2021-11-21 13:31:25 <mps> slim and slim-themes are separate pkgs, but that was 'set in stone' when alpine was small, simple ....
2021-11-21 13:31:59 <alandiwix> yea, but I guess we could painlessly separate them into "sway-wallpapers", right? that would reduce the package size to like 400 KB instead of 5 MB
2021-11-21 13:32:15 <ddevault> 5 MB is not very much
2021-11-21 13:32:19 <mps> novadays .... add every possible trash^Wnice to have :)
2021-11-21 13:32:20 <ddevault> but I don't really care, do what you please
2021-11-21 13:32:56 <ddevault> missing wallpapers will cause sway to start with an error, for the record
2021-11-21 13:33:20 <ikke> ktprograms: the checks have been disabled altogether, because it requires X, and the author did not know about xvfb
2021-11-21 13:33:44 <ikke> (or tried it but did not work for some reason)
2021-11-21 13:34:33 <ikke> ktprograms: oh, that was you :P
2021-11-21 13:34:47 <ikke> Before that, there were apparently no tests
2021-11-21 13:42:18 <ktprograms> ikke: Yep, when I did the manpages fix I didn't know about xvfb
2021-11-21 13:46:09 <ikke> so if possible, it would be nice if you could enable the tests with xvfb
2021-11-21 13:59:27 <ktprograms> ikke: That's what !27624 is for, but it turns out that passing the --log-level=debug option to picom on 32 bit architectures causes it to segfault.
2021-11-21 14:00:42 <ktprograms> It's a problem of using %ld for uint64_t. I'm probably going to do what psykose said and use PRIu64
2021-11-21 14:05:18 <Hello71> %d is also wrong for uint
2021-11-21 14:05:32 <AboothahirU[m]> 
ACTION uploaded an image: (238KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ICbgALQERXBdsjcapSZDJMrF/20211121_193458_1917736473343620356.jpg >

2021-11-21 14:05:34 <AboothahirU[m]> Hi, I am compiling mesa21.3.0  for aarch64 in chrooted alpine in Android, but now it here 
2021-11-21 14:05:42 <ktprograms> Hello71: Good point. thanks!
2021-11-21 14:06:01 <alandiwix> I see that sway pulls libelogind as a dependency, but APKBUILD doesn't seem to contain any mentions of elogind, how do I figure out what actually pulls it? I thought wlroots (and also sway) dropped any dependency on elogind and use libseat instead.
2021-11-21 14:06:04 <AboothahirU[m]> * now it stuck here
2021-11-21 14:06:14 <Hello71> probably is linking
2021-11-21 14:06:46 <ikke> alandiwix: apk info -R sway -> so:libelogind.so.0
2021-11-21 14:07:28 <AboothahirU[m]> AboothahirU[m]: any solution to this? 
2021-11-21 14:08:13 <ikke> AboothahirU[m]: how long is it stuck, it might just take a long time?
2021-11-21 14:08:45 <AboothahirU[m]> more than 5 minutes
2021-11-21 14:09:07 <Hello71> keep waiting
2021-11-21 14:09:33 <AboothahirU[m]> Okk
2021-11-21 14:10:02 <alandiwix> ikke: thanks, so wlroots dropped libelogind, but sway did not? It's not listed as a dependency in sway repo readme
2021-11-21 14:10:21 <Hello71> add up the time until linking, if it takes longer than that it's probably stuck
2021-11-21 14:10:28 <Hello71> why don't you just open new terminal and see what it is doing
2021-11-21 14:11:17 <ikke> alandiwix: it might get pulled in indirectly (in which case it would be good if an explicilt makedepends was added, or explicitly disabled of possible)
2021-11-21 14:12:24 <ikke> elogind-dev is being pulled in
2021-11-21 14:12:50 <psykose> alandiwix: sd-bus-provider is pulling in libelogind in the meson.build/meson_options for 1.6.1
2021-11-21 14:14:14 <alandiwix> can we safely disable it in Alpine?
2021-11-21 14:15:04 <psykose> it is needed for the tray
2021-11-21 14:15:31 <psykose> as it needs a dbus provider; the alternative is basu, which could be used
2021-11-21 14:15:38 <psykose> or the tray can be split to a subpkg
2021-11-21 14:15:57 <psykose> regardless, just elogind-libs doesn't do anything by itself
2021-11-21 14:18:34 <psykose> personally i don't see much point, libelogind is 588K
2021-11-21 14:20:19 <psykose> basu is 500K, and the tray can't actually be split reasonably (checked) as it's compile-time swaybar option
2021-11-21 14:20:48 <psykose> so unless you want to split all of swaybar there isn't much to be worried about here :)
2021-11-21 14:21:04 <alandiwix> thanks
2021-11-21 14:21:28 <alandiwix> basu sounds like a better alternative in alpine though, no?
2021-11-21 14:21:58 <psykose> it is an alternate libdbus provider (the other being elogind only i think?), but most things cannot use it to my knowledge (could be wrong)
2021-11-21 14:22:49 <alandiwix> basu is a dependency of mako though
2021-11-21 14:23:39 <psykose> yes; nothing wrong with that
2021-11-21 14:23:49 <psykose> if you would prefer to add it to sway over elogind make a mr :)
2021-11-21 14:23:54 <psykose> i think it would be approved
2021-11-21 14:24:21 <alandiwix> but libelogind is a dependency of libseat
2021-11-21 14:24:35 <psykose> yes
2021-11-21 14:24:59 <alandiwix> so doesn't really matter I guess
2021-11-21 14:25:10 <alandiwix> will have both anyway
2021-11-21 14:25:22 <alandiwix> thanks
2021-11-21 14:31:21 <AboothahirU[m]> <AboothahirU[m]> "20211121_193458_1917736473343620..." <- still here :(
2021-11-21 14:32:02 <ikke> AboothahirU[m]: maybe you could use qemu-user to compile it, might go faster than on a phone
2021-11-21 14:32:42 <AboothahirU[m]> inside termux ? 
2021-11-21 14:33:06 <ikke> no, not on a phone, on another machine that has more resources
2021-11-21 14:40:06 <AboothahirU[m]> Okk.. It is my phone issue I guess..
2021-11-21 14:40:24 <ikke> perhaps
2021-11-21 14:40:33 <ikke> but a phone is typically not a good debugging environment
2021-11-21 14:41:38 <AboothahirU[m]> No reboot, no power off works... 
2021-11-21 14:41:56 <AboothahirU[m]> I have force press powerbutton to do that 
2021-11-21 14:42:19 <ikke> probably because it's using up all your ram
2021-11-21 14:44:04 <AboothahirU[m]> 3gb ram 🤒
2021-11-21 14:48:28 <Hello71> psykose: technically swaybar could be split
2021-11-21 15:34:55 <alandiwix> would someone please take a look at !27654 ? I think I messed up with splitting subpackage
2021-11-21 15:42:11 <fakeshell> Hello, Any moderators around?
2021-11-21 15:42:21 <ikke> fakeshell: yes, how can I help?
2021-11-21 15:48:07 <omni> hmm... I need to look at init.d/zfs-mount, its fsck doesn't seem to respect the sixth field in fstab
2021-11-21 15:48:41 <omni> also, when would init.d/fsck not be run, for it to be needed in init.d/zfs-mount?
2021-11-21 15:50:46 <fakeshell> hey ikke i'm running an alpine linux mirror and i sent an email to alpine-mirrors email address twice and got no response 
2021-11-21 15:51:50 <fakeshell> are there any further procedures i need to take? here is the mirror: alpine.bardia.tech protocols are http and https
2021-11-21 17:03:56 <ikke> fakeshell: We sadly get quite some spam on that e-mail address, so it drowned a bit
2021-11-21 17:04:41 <fakeshell> hmm alright
2021-11-21 17:04:51 <fakeshell> any place i can submit it to the dev team?
2021-11-21 17:05:40 <ikke> I've found it, I'll handle it
2021-11-21 17:05:45 <fakeshell> thanks
2021-11-21 17:06:03 <fakeshell> you can contact me via email or even irc if there were any further questions
2021-11-21 17:06:24 <ikke> alright
2021-11-21 19:38:53 <clandmeter> mps: why not add firware-none to makedepens?
2021-11-21 19:46:31 <mps> clandmeter: I forgot details but I remember ncopa concluded that firmware-any is 'correct' solution
2021-11-21 19:47:14 <mps> though I think firmware-none is ok
2021-11-21 19:47:46 <mps> actually not have any firmware in makedeps
2021-11-21 19:48:00 <Hello71> if you add firmware-none then if someone is building without chroot it will either fail or it will delete all their firmware
2021-11-21 19:48:32 <Hello71> imagine if power fails during building, then alpine will not boot anymore
2021-11-21 19:48:49 <ikke> I think firmware-none is a user choice, not?
2021-11-21 19:50:18 <mps> it is irrelevant for builders
2021-11-21 19:50:51 <Hello71> really the best solution is to decouple depends and makedepends. imo arch system of makedepends automatically including depends is a mistake
2021-11-21 19:54:42 <mps> yes, something to reconsider
2021-11-21 21:01:58 <dalias> yes
2021-11-21 21:03:41 <dalias> random thought: it'd be really nice to see alpine outreach/advocacy to projects shipping whole OS to run on rpi etc.
2021-11-21 21:04:27 <dalias> things like retropi, octopi, etc. would be so much better alpine-based (booting in a few seconds rather than minutes, small SD image download, etc.)
2021-11-21 21:13:47 <Hello71> yes, it would be good to not be seen as "docker distro" (as i have complained about in past)
2021-11-21 21:14:18 <mps> dalias: uh, raspberry?
2021-11-21 21:19:27 <omni> yeah, I love retropi as long as I don't have to look under the hood, I feel like it's a pile of not so pretty hacks but it works
2021-11-21 21:21:16 <valerius> I'm working on making that situation better
2021-11-21 21:23:14 <dalias> *nod* this is imo where alpine really shines (for the same reason as "docker distro")
2021-11-21 21:40:29 <vkrishn> maybe firmware-empty
2021-11-21 21:44:14 <Hello71> what?
2021-11-21 21:57:12 <mps> firmware-none is this
2021-11-21 22:19:31 <alandiwix> PureTryOut: Hi. Could you please take a look at !27668 ?
2021-11-21 22:23:19 <Hello71> ugh, awk. and why is it kill -9?
2021-11-21 22:28:07 <psykose> this doesn't work with procps
2021-11-21 22:28:19 <psykose> if someone installs procps this script no longer works
2021-11-21 22:29:23 <Hello71> also a good point
2021-11-21 22:30:41 <Ariadne> 3:03 PM <dalias> random thought: it'd be really nice to see alpine outreach/advocacy to projects shipping whole OS to run on rpi etc.
2021-11-21 22:30:59 <Ariadne> yes, this is something that is in queue, as far as i know
2021-11-21 22:31:48 <Ariadne> the problem is that marketing is usually the most damaging appendage of any organization
2021-11-21 22:37:02 <omni> if anyone is running zfs, would you mind having a look at https://github.com/openzfs/zfs/pull/12780
2021-11-21 23:03:46 <lzsaver> omni, will zfs work if it uses fstab mountpoints?
2021-11-21 23:04:28 <lzsaver> omni, some guys prefer to do "zfs set mountpoint=leagacy"
2021-11-21 23:04:40 <lzsaver> * "zfs set mountpoint=legacy"
2021-11-21 23:05:17 <lzsaver> omni, I mean with your patch
2021-11-21 23:07:28 <lzsaver> need to test such setup
2021-11-21 23:49:09 <omni> lzsaver: good feedback, thanks
2021-11-22 00:15:30 <PJ[m]> is there any alternative for xf86-input-keyboard that doesn't break input?
2021-11-22 00:16:59 <PJ[m]> anything else completely breaks input. dead keys, keys responding as different ones etc.
2021-11-22 01:39:42 <omni> lzsaver: localmount handle that too just fine
2021-11-22 02:25:10 <dalias> pj[m], aiui -keyboard is deprecated and only -evdev should be used
2021-11-22 02:25:52 <dalias> -keyboard seems to have been removed even
2021-11-22 02:26:00 <dalias> what ver are you on?
2021-11-22 02:27:21 <dalias> actually the recommendation now might be -libinput but iirc i had bad experience with it and switched back to -evdev
2021-11-22 02:31:15 <Hello71> libinput is "the future" and is the only one supported on wayland, but evdev will probably be kept alive for foreseeable future
2021-11-22 02:31:20 <Hello71> same with wayland and xorg
2021-11-22 02:32:33 <dalias> why is wayland relevant for folks using X ?
2021-11-22 02:33:04 <Hello71> well if you want to use wayland in future it may be easier to use libinput now
2021-11-22 02:33:17 <dalias> i absolutely do not want to use wayland in the future
2021-11-22 02:33:45 <dalias> i would rather use c.2000 xf86_fbdev unaccelerated
2021-11-22 02:34:09 <dalias> because the whole idea of wayland is just so uhg to me
2021-11-22 02:34:15 <Hello71> fbdev will probably die sooner than xorg
2021-11-22 02:34:39 <Hello71> quite possibly in this decade
2021-11-22 02:34:40 <dalias> i mean forget about modern xorg and use a 20 year old xf86
2021-11-22 02:34:46 <dalias> :)
2021-11-22 02:35:31 <Hello71> you may also need to use old linux kernel. from what i hear, linux maintainers are sick enough of fbdev that once fbcon is replaced, they may well drop fbdev
2021-11-22 02:36:22 <dalias> it doesn't matter if it's /dev/fb0 or whatever; you can use the same x server on whatever api to access to actual framebuffer
2021-11-22 02:36:30 <Hello71> i guess
2021-11-22 02:36:44 <dalias> but i think you're thinking of the old fbcon drivers
2021-11-22 02:36:45 <Hello71> that's basically modesetting sans glamor
2021-11-22 02:36:55 <dalias> the modern one just sits on top of modesetting
2021-11-22 02:37:14 <Hello71> i thought xf86-video-fbdev still opens /dev/fb*
2021-11-22 02:37:34 <dalias> with modern kernel drivers, /dev/fb0 *is* the thing stting on top of modesetting
2021-11-22 02:37:56 <dalias> it's only some ancient hardware that never got modesetting drivers that's using the old fbcon driver framework
2021-11-22 02:38:16 <dalias> $ cat /proc/fb
2021-11-22 02:38:16 <dalias> 0 i915drmfb
2021-11-22 02:38:17 <Hello71> i thought the answer is "yes and no" and something to do with fbdev2 or somesuch
2021-11-22 02:38:38 <dalias> that's not the old thing, it's on top of the drm layer
2021-11-22 02:38:52 <Hello71> or wait, is it fbdev drivers that are turning into kms drivers that's fbdev2
2021-11-22 02:39:55 <Hello71> but anyways, is /dev/fb0 not going away then even if fbcon is? i thought fbcon is the thing keeping /dev/fb0
2021-11-22 02:49:28 <dalias> oohhhhhh now i know what you mean
2021-11-22 02:49:40 <dalias> fbcon = actually running a console on top of the fb
2021-11-22 02:49:46 <dalias> that's nothing to do with /dev/fb0
2021-11-22 02:49:53 <dalias> it's /dev/tty1...
2021-11-22 02:50:02 <dalias> (and /dev/vcs*)
2021-11-22 02:50:31 <dalias> that's the layer that's had bugs/vulns over and over and that makes no sense to have in kernel
2021-11-22 02:50:50 <dalias> you can just run a userspace terminal emulator on top of /dev/fb0 instead
2021-11-22 03:18:05 <PJ[m]> dalias, I know, that's why I'm asking
2021-11-22 05:39:32 <boomanaiden154> ikke: Have you had a chance to review my MR in the apkbuild-lint-tools repo?
2021-11-22 05:40:35 <ikke> boomanaiden154: not yet, but thanks! Will look at it
2021-11-22 06:28:41 <MaximKarasev[m]> Hi, can anyone please review !27067, !27006 and !27012 ?
2021-11-22 07:30:38 <alandiwix> Hello71, psykose: thanks, fixed those
2021-11-22 07:50:27 <ncopa> good morning
2021-11-22 07:51:06 <mps> good morning
2021-11-22 07:51:45 <mps> ncopa: do you plan to make release today
2021-11-22 08:02:47 <ncopa> doing 5.15.4 kernel first. will see after that
2021-11-22 08:04:29 <mps> I created !27676 but didn't tested it, changelog is here https://lists.gnu.org/archive/html/info-mtools/2021-11/msg00000.html
2021-11-22 08:05:10 <mps> not sure should it be merged for 3.15 because it is not tested yet
2021-11-22 08:08:32 <mps> hm, someone merged it, ok
2021-11-22 08:10:06 <mps> everything else I tested works fine, except xorg-server segfaults on one of my aarch64 machines
2021-11-22 08:12:11 <mps> that happens on apple M1 so I think it is not important. doubt that anyone except me using alpine on M1 ;)
2021-11-22 08:23:59 <ncopa> I think we need to do rc5 today
2021-11-22 08:24:43 <ikke> #13218
2021-11-22 08:25:36 <mps> ncopa: btw, if you uprading kernel could you add #13206
2021-11-22 08:25:59 <mps> fix
2021-11-22 08:29:00 <ncopa> ugh. the kernel build is almost done..
2021-11-22 08:33:34 <mps> sorry I didn't mentioned it earlier
2021-11-22 08:35:45 <ncopa> well, better late than never
2021-11-22 08:36:11 <ncopa> I should have checked the issues too
2021-11-22 08:42:38 <psykose> all the manpages under binutils-doc are broken
2021-11-22 08:43:55 <psykose> just an empty .gz with no content for each one
2021-11-22 09:07:37 <ncopa> sounds like abuild man page compression is broken
2021-11-22 09:12:24 <psykose> seems weird that it would affect only binutils-doc like this, but maybe
2021-11-22 09:12:54 <Ariadne> no
2021-11-22 09:12:54 <Ariadne> the issue is binutils
2021-11-22 09:13:04 <Ariadne> they fucked up and shipped blank ones
2021-11-22 09:13:40 <Ariadne> something about --enable-maintainer-mode
2021-11-22 09:22:24 <psykose> passing that makes it complain autoconf is too new (2.71, 2.69 wanted), lmao
2021-11-22 09:22:30 <psykose> i had briefly forgotten this is a gnu project
2021-11-22 09:24:02 <Ariadne> regenerate the build system
2021-11-22 09:24:02 <Ariadne> idk im drunk
2021-11-22 09:24:02 <Ariadne> autoreconf blabla
2021-11-22 09:25:58 <psykose> it is intentional by the maintainer-mode docs, they want fixed versions
2021-11-22 09:28:02 <mps> Ariadne: ;)
2021-11-22 09:28:09 <mps> I'm not alone
2021-11-22 09:34:28 <Ariadne> psykose: did you catch that
2021-11-22 09:34:39 <psykose> catch what
2021-11-22 09:34:39 <Ariadne> some script kiddie is apparently ddosing irccloud again
2021-11-22 09:34:53 <Ariadne> psykose: use autoreconf -rvi to refresh the build system
2021-11-22 09:34:56 <psykose> ah that
2021-11-22 09:34:56 <Ariadne> in prepare()
2021-11-22 09:36:51 <psykose> yes, but you can't do that with --enable-maintainer-mode as they hardcode the wanted version and it says so in the docs
2021-11-22 09:39:03 <Ariadne> ...
2021-11-22 09:39:14 <Ariadne> just patch the one
2021-11-22 09:39:16 <Ariadne> er
2021-11-22 09:39:21 <Ariadne> patch the autoconf configure.ac
2021-11-22 09:39:22 <Ariadne> thing
2021-11-22 09:39:30 <Ariadne> to make it 2.71
2021-11-22 09:39:36 <Ariadne> or delete the check
2021-11-22 09:39:38 <Ariadne> or whatever
2021-11-22 10:00:16 <psykose> for some reason an autoreconf -iv or -fiv fails with one of the subdirs missing a config.cache read in their Makefile, either i am very stupid or this is just caused by forcing the new version patched in
2021-11-22 10:00:27 <psykose> in any case i've been awake for almost 2 days and i should probably go to bed
2021-11-22 10:00:28 <psykose> blech
2021-11-22 10:00:45 <psykose> silly binutils can't just install some manpages normally
2021-11-22 10:04:29 <Ariadne> dunno
2021-11-22 10:04:43 <Ariadne> i looked into it already and couldn't make heads or tails of their build system for the manpages
2021-11-22 10:05:16 <psykose> yes, i spent like 15 minutes trying to find anything and it's like a needle in the ocean
2021-11-22 10:06:38 <psykose> oh well
2021-11-22 10:06:57 <psykose> goodnight Ariadne, thanks for the help
2021-11-22 10:32:25 <ncopa> i think my bluetooth broke
2021-11-22 10:32:36 <ncopa> my keyboard does not connect
2021-11-22 10:33:34 <ncopa> bluetoothctl does not list any adapters
2021-11-22 10:36:30 <ikke> aaand mips is gone again
2021-11-22 10:36:43 <ikke> It was fun while it lasted
2021-11-22 10:37:02 <ikke> (I think it's the network, not the host)
2021-11-22 10:41:29 <Ariadne> i dunno, the whole thing is supposed to be decommissioned by now
2021-11-22 10:41:59 <Ariadne> i do have another UBNT XG in my colo that i could set up to replace the mips64 builder
2021-11-22 10:42:04 <Ariadne> i just don't know if it is worth it
2021-11-22 10:44:39 <ncopa> probably not
2021-11-22 11:45:37 <ncopa> aha... with kernel 5.15.2 my Bluetooth works. 5.15.3 must have broken it
2021-11-22 11:46:53 <caskd> 5.15 broke so much
2021-11-22 11:47:17 <caskd> for me the graphics switch during initramfs froze my display
2021-11-22 11:53:01 <mps> caskd: did you tried with linux-edge
2021-11-22 11:53:14 <caskd> not yet
2021-11-22 11:53:19 <caskd> i was ahead of linux-edge
2021-11-22 11:53:22 <caskd> with my kernel build
2021-11-22 11:57:41 <ikke> https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html
2021-11-22 11:58:22 <caskd> are the kernel mods also compressed in initramfs?
2021-11-22 11:58:37 <ktprograms> Here's the instructions to build GHC on Alpine Arm64: https://gist.github.com/ktprograms/011000bda16fbcdd5e00002b42d051d5
2021-11-22 11:58:49 <ktprograms> I haven't had time to write a Dockerfile yet, though
2021-11-22 11:58:51 <ncopa> caskd: yes
2021-11-22 11:59:10 <caskd> ooh, that should make the partition size requirements way smaller
2021-11-22 11:59:52 <omni> here I thought lts was longterm, but now I'm confused..
2021-11-22 12:00:21 <mps> ikke: I think you should mention xorg upgrade and that the dpi should be probably set
2021-11-22 12:00:34 <caskd> oh yeah i had dpi problems
2021-11-22 12:00:42 <caskd> any resources about that?
2021-11-22 12:01:10 <mps> caskd: you have to set dpi in .Xresources
2021-11-22 12:01:48 <mps> ikke: also kernel smbd driver and ksmbd-tools should be mentioned
2021-11-22 12:02:12 <mps> ikke: and gvim move to community
2021-11-22 12:02:27 <omni> ikke: that overlaytmpfsflags link seem to be broken, what should it point to?
2021-11-22 12:03:22 <mps> ikke: also, linux-edge moved to community and linux-edge-virt renamed to linux-edg4virt
2021-11-22 12:04:00 <ncopa> i dont think gvim move matters that much
2021-11-22 12:04:56 <ncopa> ktprograms: was that on an arm64 host or x86_64?
2021-11-22 12:05:30 <ktprograms> ncopa: Arm64 Alpine with Debian Testing Arm64 chroot
2021-11-22 12:06:28 <ncopa> ok 👍
2021-11-22 12:07:06 <mps> ikke: also new paragon ntfs driver is enabled in kernels, not sure should this be mentioned
2021-11-22 12:10:29 <ncopa> allrighty then... i guess its time for 3.15.0_rc5
2021-11-22 12:11:03 <ktprograms> I haven't tested using the built GHC to rebuild itself, but XMonad compiles and runs fine (you can see a screenshot at the bottom of my gist)
2021-11-22 12:21:36 <Hello71> mps: i think can be put on wiki
2021-11-22 14:01:28 <ikke> ncopa: there should also be an abuild release before 3.15
2021-11-22 14:03:03 <ncopa> true
2021-11-22 14:07:02 <ncopa> i tagged abuild release
2021-11-22 14:17:50 <ncopa> anything blocking a rc5?
2021-11-22 14:20:34 <ncopa> I have been thinking a bit about release notes. https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/33 vs the wiki
2021-11-22 14:22:07 <ncopa> it is kinda weird to have two different releases notes
2021-11-22 14:22:37 <ncopa> so it would be nice to have a single one with everything. an official one (not wiki where anyone can edit)
2021-11-22 14:22:39 <clandmeter> nod
2021-11-22 14:22:54 <ncopa> which means that the official one will be long
2021-11-22 14:24:12 <clandmeter> i would prefer longer compared to mutliple locations
2021-11-22 14:24:49 <clandmeter> maybe the commit stats can be a link?
2021-11-22 14:25:28 <clandmeter> or maybe it does not need to be included in the release notes
2021-11-22 14:28:49 <ikke> ncopa: THe original idea behind the wiki is to be able to collect them during the release cycle
2021-11-22 14:29:47 <ikke> and people used the wiki to add a lot of details aobut certain issues that affect upgrades
2021-11-22 14:52:27 <ncopa> ugh. got interupted. and now its lunch. brb (hopefully)
2021-11-22 14:52:48 <ncopa> (quick thought: would be nice to split the main vs community somehow)
2021-11-22 14:54:45 <ikke> The release notes?
2021-11-22 14:54:49 <ikke> I was thinking about that as well
2021-11-22 15:12:49 <ncopa> yeah. maybe we could have community in wiki and the rest in main? (just an idea, maybe bad idea)
2021-11-22 15:12:58 <ncopa> need to run out now. i tagged rc5
2021-11-22 15:13:44 <ncopa> we try come back later and comment more on release notes
2021-11-22 15:24:46 <AboothahirU[m]> Where I can get the compiled alpine pacakage
2021-11-22 15:27:32 <ikke> From you favorite alpinelinux mirror
2021-11-22 15:27:47 <omni> is there any issue with the official release notes being a longer read?
2021-11-22 15:28:02 <AboothahirU[m]> can't get the file locally? 
2021-11-22 15:28:34 <ikke> omni: something about tl;dr :P
2021-11-22 15:29:20 <omni> sure
2021-11-22 15:29:58 <omni> but then perhaps have changes to community packages at the end, or at least after changes to packages in main
2021-11-22 15:31:39 <omni> I too would prefer longer read compared to multiple locations, if I bump into any issue I could easily go back and see if I missed anything tl;dring
2021-11-22 15:33:20 <AboothahirU[m]> <AboothahirU[m]> "can't get the file locally?..." <- I don't remember which mirror was selected during installation
2021-11-22 15:36:07 <ikke> apk fetch <packagename>
2021-11-22 15:36:57 <AboothahirU[m]> It download mesa-21. 2.5-r0
2021-11-22 15:37:08 <AboothahirU[m]> I need mesa-21. 3.0-r0
2021-11-22 15:37:23 <AboothahirU[m]> Mesa 21.3.0 was compiled
2021-11-22 15:37:56 <ikke> Did you compile it locally?
2021-11-22 15:38:02 <AboothahirU[m]> Yeah
2021-11-22 15:38:40 <ikke> Oh, then you need to add /home/<username>/packages/<reponame> to /etc/apk/repositories
2021-11-22 15:38:57 <ikke> and make sure your local signing public key is added to /etc/apk/keys
2021-11-22 15:39:38 <AboothahirU[m]> I get those file now... 
2021-11-22 15:40:27 <AboothahirU[m]> Thanks
2021-11-22 15:43:53 <AboothahirU[m]> Can I directly install those .apk s or need any signing keys? 
2021-11-22 15:50:40 <ikke> You need to add the key that you generated in ~/.abuild to /etc/apk/repositories
2021-11-22 15:50:49 <ikke> you can always ignore untrusted packages though
2021-11-22 16:22:32 <AboothahirU[m]> how to upgrade app ?i have the .apk locally
2021-11-22 18:10:44 <boomanaiden154> AboothahirU[m]: apk install --allow-untrusted [apk file]
2021-11-22 18:11:00 <Hello71> there's no apk install, and you shouldn't need --allow-untrusted
2021-11-22 18:11:11 <Hello71> in fact i'm pretty sure abuild won't let you build a package if the keys aren't trusted
2021-11-22 18:11:54 <boomanaiden154> apk add. I apparently can't even remember the commands today.
2021-11-22 18:12:08 <ikke> it requires a key to be generated before you can build a package, but those keys do not necessarily have to be trusted (in /etc/apk/keys)
2021-11-22 18:28:36 <Hello71> hm, i probably misremembered then
2021-11-22 18:31:38 <donoban> I noticed that wpa_supplicant runs as a boot rc-service, there is no better place for handling it?
2021-11-22 18:34:13 <Misthios> u can change it to default
2021-11-22 18:35:29 <donoban> well, I feel that it should be handled by ifup/ifdown
2021-11-22 18:47:47 <Ariadne> it can be
2021-11-22 18:47:54 <Ariadne> see interfaces-wifi(5)
2021-11-22 18:52:39 <donoban> it looks nice, should this be integrated with setup-interfaces?
2021-11-22 18:54:43 <Ariadne> it requires ifupdown-ng
2021-11-22 18:56:33 <omni> tip: iwd is a really nice alternative to wpa_supplicant
2021-11-22 19:09:32 <donoban> I tried it for setup an access point but unfornately I get very low speed compared to wpa_supplicant
2021-11-22 19:13:39 <mps> donoban: something with your wifi card? as Denis told on #iwd
2021-11-22 19:14:08 <mps> I used it about two years ago as AP and it worked fine
2021-11-22 19:38:45 <donoban> I'm not sure but I get only 4Mpbs with iwd and near 20Mpbs with wpa_supplicant, maybe what he said about wide channels?
2021-11-22 19:38:54 <donoban> how can I determine if wpa_supplicant is using them?
2021-11-22 19:41:10 <mps> use iw to look detailed state of interface
2021-11-22 19:42:31 <ncopa> I think https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html is pretty good
2021-11-22 19:42:39 <donoban> ok I will check later, I got to go now, thanks mps 
2021-11-22 19:43:11 <ncopa> i think it might have been better with all the wiki in the official release notes, but....
2021-11-22 19:43:20 <ncopa> im not sure im too happy with everything in the wiki
2021-11-22 19:43:39 <ikke> I did work on a proof of concept to split it out a bit
2021-11-22 19:44:08 <ncopa> for example, i disagree with the the postgresql recommendations in the -dev section
2021-11-22 19:45:10 <ikke> ncopa: do you think we should add more details to the release notes instead of linking back to the wiki?
2021-11-22 19:45:35 <Ariadne> ncopa: postgreslq13
2021-11-22 19:45:43 <ncopa> that was the original idea, but I read the wiki and I no longer think it is a good idea
2021-11-22 19:45:51 <ncopa> probably better to keep the wiki
2021-11-22 19:46:08 <ncopa> significantly easier to keep the wiki
2021-11-22 19:46:15 <ikke> right
2021-11-22 19:46:46 <ikke> Especially with passed releases, the section about docker got significantly expanded after more details were known
2021-11-22 19:46:58 <ncopa> right
2021-11-22 19:47:13 <ikke> past*
2021-11-22 19:47:42 <Misthios> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27275%7CMR that links doesnt work
2021-11-22 19:47:51 <Misthios> from the postgres part
2021-11-22 19:47:57 <ikke> ncopa: https://tpaste.us/qP75 
2021-11-22 19:48:09 <ncopa> Ariadne: i agree with the postgresql13 + postgresql14. i understand why it is neccessary and I trust jirutka to do a good job (or take responsibility and fix if he doesnt)
2021-11-22 19:48:33 <ncopa> what I disagree with is the "add depends=$(... ) in the package function"
2021-11-22 19:49:45 <ncopa> ikke: i think that is good
2021-11-22 19:49:52 <ncopa> better than what I had in mind :)
2021-11-22 19:50:29 <ikke> Ok, will push that to the MR then
2021-11-22 20:04:59 <Ariadne> ncopa: no i mean.
2021-11-22 20:05:06 <Ariadne> ncopa: its misspelled
2021-11-22 20:19:19 <ncopa> oh...
2021-11-22 20:26:32 <ikke> Ariadne: fixed :-)
2021-11-22 21:29:15 <vkrishn> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.15.0#Support_overlaytimpfs_mount_options <- s/overlaytimpfs/overlaytmpfs/
2021-11-22 21:35:34 <vkrishn> suggestion /5.15 LTS kernels/Linux Kernel LTS 5.15/
2021-11-22 22:27:41 <mps> I've got alpine running on apple m1 with xorg and simpledrm, nearly everything works
2021-11-22 22:29:59 <mps> if anyone wants to play with it I can post kernel apk and short instruction how to install
2021-11-22 22:52:51 <clandmeter> what does not work?
2021-11-22 22:55:52 <mps> audio card, touchpad works with evtest but now in xorg (probably have to find how to configure it)
2021-11-22 22:56:12 <mps> s/now/not/
2021-11-22 22:56:12 <alpine-meetbot> mps meant to say: audio card, touchpad works with evtest but not in xorg (probably have to find how to configure it)
2021-11-22 22:56:33 <clandmeter> these are known to not work?
2021-11-22 22:56:44 <mps> didn't had patience to patch wifi driver but used one on usb
2021-11-22 22:57:30 <mps> there are patches for audio but I didn't added them, will try next week
2021-11-22 22:57:47 <clandmeter> so in principle all works with patches?
2021-11-22 22:58:03 <mps> yes, a lot of patches
2021-11-22 22:58:46 <mps> people work on adding and fixing many drivers
2021-11-22 22:58:53 <clandmeter> ah i see you are active on asahi :)
2021-11-22 22:59:03 <mps> well, gpu is still far from working
2021-11-22 23:00:52 <mps> but, practically it could be used, though not yet 'for end users' ;)
2021-11-22 23:01:49 <clandmeter> time for bed
2021-11-22 23:02:07 <mps> yes, also for me, good night
2021-11-22 23:02:07 <Ariadne> this postgresql stuff seems to have exposed a bug in the apk-tools solver.
2021-11-23 01:05:03 <ktprograms> Hi, why is pixman.h installed in /usr/include/pixman-1/pixman.h?
2021-11-23 01:07:35 <tomalok> fwiw I've successfully built 3.15.0_rc4 x86_64 and aarch64 cloud images for AWS, and at the very least, they instantiate.
2021-11-23 01:24:41 <Hello71> ktprograms: why not
2021-11-23 01:25:41 <ktprograms> Hello71: Just using #include <pixman.h> doesn't work, and if you do #include <pixman-1/pixman.h> then it can't find pixman-version.h
2021-11-23 01:26:14 <Hello71> $(pkg-config --cflags pixman-1)
2021-11-23 01:27:44 <Ariadne> Hello71: congrats on getting that damn mesa patch upstreamed
2021-11-23 01:27:48 <ktprograms> Hello71: yes, that works, but why is it pixman-1 and not just pixman?
2021-11-23 01:28:07 <Ariadne> ktprograms: because its a versioned sdk
2021-11-23 01:28:21 <Hello71> because that's what the people that wrote pixman came up with
2021-11-23 01:28:34 <ktprograms> I see. Thanks
2021-11-23 01:28:42 <Hello71> perhaps they thought they would make a pixman-2 at some point
2021-11-23 01:29:04 <Hello71> which would be incompatible, and maybe you would be able to install them side by side
2021-11-23 01:29:35 <ktprograms> Grr picom makes extensive use of __auto_type and in one of the places it does pointer math, so on 64 bits %ld is correct but on 32 bits it needs to be %d.
2021-11-23 01:29:48 <ktprograms> Is there any simple #ifdef for 32 bits?
2021-11-23 01:29:55 <Hello71> Ariadne: it's a new patch by me
2021-11-23 01:30:07 <Hello71> %p
2021-11-23 01:30:08 <Ariadne> well
2021-11-23 01:30:12 <Ariadne> congrats regardless
2021-11-23 01:30:12 <Hello71> ktprograms: %p
2021-11-23 01:31:11 <Hello71> also tlsdesc is apparently broken on lld so probably musl distros will need to specify -mtls-dialect=gnu2 manually but it's not mandatory, only for better performance (and slightly smaller size)
2021-11-23 01:32:30 <ktprograms> These are the lines in question: https://github.com/yshui/picom/blob/1c7a4ff5a3cd5f3e25abcac0196896eea5939dce/src/backend/backend.c#L46-L47. ps->damage and ps->damage_ring are pointers to a pixman_region32, and ps->ndamage is int
2021-11-23 01:33:56 <Hello71> %zu
2021-11-23 01:35:08 <Hello71> i wonder why nobody has complained about this yet
2021-11-23 01:35:24 <ktprograms> Hello71: but it's ((pointer - pointer) + int) % int, so isn't the end result int?
2021-11-23 01:35:33 <Hello71> er
2021-11-23 01:35:55 <Hello71> yes i think you are right
2021-11-23 01:36:05 <Hello71> hm, wait, no, integer promotion
2021-11-23 01:36:06 <dalias> ptrdiff_t
2021-11-23 01:36:12 <Hello71> yeah, that
2021-11-23 01:36:18 <ktprograms> <Hello71> i wonder why nobody has complained about this yet << That's probably one of the causes of the segfaults on 32 bit architectures
2021-11-23 01:36:21 <dalias> which has a format character
2021-11-23 01:36:23 <Hello71> it's too late here :p
2021-11-23 01:36:32 <dalias> but if you % smallint you could just cast to int afterwards
2021-11-23 01:36:44 <Hello71> right
2021-11-23 01:36:56 <ktprograms> so %td?
2021-11-23 01:37:09 <ktprograms> dalias: What's % smallest?
2021-11-23 01:37:35 <Hello71> if you % int then mathematically the result fits in int
2021-11-23 01:37:56 <Hello71> i don't think it needs to be a small value?
2021-11-23 01:38:35 <Hello71> right but i mean shouldn't this trigger -Wformat at compile time? does nobody read that?
2021-11-23 01:38:37 <dalias> well i wasn't assuming 'int' meant actual type "int", only some integer type
2021-11-23 01:38:45 <Hello71> er, to 
2021-11-23 01:38:47 <Hello71> 01:36 <ktprograms> <Hello71> i wonder why nobody has complained about this yet << That's probably one of the causes of the segfaults on 32 bit archit
2021-11-23 01:38:49 <dalias> so i used 'smallint' to mean "a value small enough to fit in int"
2021-11-23 01:39:04 <dalias> regardless of the exact type
2021-11-23 01:39:22 <ktprograms> dalias: I see. So would %td be correct here?
2021-11-23 01:39:42 <dalias> ktprograms, as written, i think so
2021-11-23 01:40:42 <Hello71> assuming rank of ptrdiff_t >= rank of int i think
2021-11-23 01:41:08 <ktprograms> Hello71: Yes, there are -Wformat warnings, but I think upstream hasn't really tested on 32 bit architectures. picom works fine but whenever you turn on debug logging, it segfaults because it uses the wrong format specifiers.
2021-11-23 01:41:15 <Hello71> mmhmm
2021-11-23 01:41:36 <ktprograms> Hello71: Sorry, what does 'rank of' mean?
2021-11-23 01:42:00 <Hello71> i think it also only crashes on x86, due to stack calling convention. on other archs it should print correct result or some garbage
2021-11-23 01:42:21 <Hello71> integer conversion rank i mean. not sure, it's late here
2021-11-23 01:43:18 <ktprograms> Hello71: When running the tests on armv7 and armhf it also segfaults (the tests use --log-level=debug)
2021-11-23 01:43:35 <Hello71> could be a different reason
2021-11-23 01:45:32 <Hello71> ah, wait, no, log_printf has a whopping four non-variadic arguments
2021-11-23 01:46:01 <Hello71> and arm32 only has 4 argument registers, i thought it had 8 like arm64
2021-11-23 01:47:44 <Hello71> ktprograms: if ps->ndamage really is an int, then best solution is to manually cast to int
2021-11-23 01:48:14 <Hello71> using full auto is arguably a good idea, but if you want to do that then you also need to use a type-generic printing method like the awful c++ iostreams or the slightly better c++ fmt
2021-11-23 01:57:07 <ktprograms> Hello71: Sorry, I was busy with something else. By cast to int, you mean that anything modulo an int should always be int?
2021-11-23 01:57:35 <ktprograms> Well using %td got rid of that -Wformat warning
2021-11-23 02:00:28 <dalias> -abs(y) < x%y < abs(y)
2021-11-23 02:04:03 <ktprograms> So would casting to int be better, or using %td?
2021-11-23 02:05:00 <dalias> for practical purposes i think either is fine
2021-11-23 02:05:40 <dalias> ptrdiff_t is not going to be lower rank than int on any reasonable system
2021-11-23 02:08:10 <ktprograms> Ok, thanks
2021-11-23 02:49:43 <ktprograms> Any idea why on 32 bits I get a -Wsign-compare about long int and unsigned int but on 64 bits I don't?
2021-11-23 02:51:39 <psykose> long int is normally 64 on 64, and 32 on 32, but it's not guaranteed
2021-11-23 02:52:00 <psykose> hm
2021-11-23 02:52:27 <psykose> you can try some sizeof() tests to see their actual sizes
2021-11-23 02:53:14 <psykose> idk why it wouldn't always give you an error given that it's about the signedness only
2021-11-23 02:54:33 <dalias> psykose, because whether there's a signedness mismatch is dependent on promotions
2021-11-23 02:54:41 <psykose> ah, right
2021-11-23 02:55:04 <dalias> if long is 32-bit, the long is coerced to unsigned by the promotion (value-changing); this is the warnings
2021-11-23 02:55:31 <dalias> if long is 64-bit, the unsigned int is promoted with no change in value and the inequality has its mathematical truth value as written
2021-11-23 02:56:01 <psykose> right, makes sense
2021-11-23 02:58:22 <ktprograms> Can someone please provide me a resource on integer promotion? I've never heard of it
2021-11-23 02:59:03 <ktprograms> BTW the line with the -Wsign-compare is width > UINT_MAX (width is a long int)
2021-11-23 03:04:08 <ktprograms> Nevermind, I think I understand integer promotion now after some reading, but what would be the solution here? Should I cast UINT_MAX to long?
2021-11-23 03:06:27 <psykose> given how they are checking if something is larger than the max of something they are relying on these weird rules for the code to work :)
2021-11-23 03:09:40 <psykose> i don't know what they are trying to do but i'm guessing they want a 64-bit width/height/x/y and to check if it's larger than the 32bit limit, but i can't think of any case in which you are going to have a width of millions of pixels
2021-11-23 03:10:43 <ktprograms> Oh it checks that the width fits within an unsigned int because pixman_region32_union_rect needs unsigned int. So I think using 'width > (long)UINT_MAX' should work?
2021-11-23 03:11:59 <psykose> (long)UINT_MAX with 32-bit long and int makes it... INT_MIN, doesn't it
2021-11-23 03:12:10 <psykose> everything returns true then
2021-11-23 03:12:26 <psykose> or no, it makes it 0
2021-11-23 03:15:05 <dalias> (long)UINT_MAX would be -1 then
2021-11-23 03:15:12 <psykose> yes; -1 not 0, bad memory
2021-11-23 03:15:42 <ktprograms> Yep, it's -1
2021-11-23 03:16:08 <ktprograms> So what would be the way to check if a 32bit long is more than UINT_MAX?
2021-11-23 03:16:35 <dalias> it's not
2021-11-23 03:16:46 <dalias> however you don't need to special-case this
2021-11-23 03:16:49 <dalias> the code is fine already
2021-11-23 03:16:56 <dalias> the condition is always-false for a 32-bit long
2021-11-23 03:17:32 <ktprograms> Oh that's right a 32bit long can never be more than UINT_MAX
2021-11-23 03:17:44 <ktprograms> So just leave it as 'width > UINT_MAX'?
2021-11-23 03:17:50 <dalias> looks fine to me
2021-11-23 03:18:01 <dalias> -Wsign-compare is a very dangerous warning
2021-11-23 03:18:15 <ktprograms> dalias: Dangerous in what way?
2021-11-23 03:18:20 <dalias> because it leads ppl to think something is wrong and make changes "to make the warning go away" that are actually very wrong
2021-11-23 03:18:39 <ktprograms> Right. Thanks for your help
2021-11-23 03:35:02 <ktprograms> Would using unsigned long be the solution for https://github.com/yshui/picom/blob/1c7a4ff5a3cd5f3e25abcac0196896eea5939dce/src/c2.c#L1333-L1337 (there's a -Wsign-conversion because win is uint32_t)
2021-11-23 03:41:22 <ktprograms> Whoops, doesn't look like that would work because other times predef_target is used with signed values. So should it be long long predef_target?
2021-11-23 03:44:08 <psykose> i guess you can make tgt int64_t :p
2021-11-23 03:44:55 <ktprograms> Would long long be better or int64_t?
2021-11-23 03:45:48 <psykose> these issues would have been more obvious if everything just used the sized types
2021-11-23 03:46:02 <ktprograms> psykose: What do you mean?
2021-11-23 03:46:31 <psykose> long long is also 64 so go for it if youw ant
2021-11-23 03:46:52 <ktprograms> Ok I'll just keep with the convention that picom has
2021-11-23 05:37:32 <ktprograms> What would be the best solution for this line: https://github.com/yshui/picom/blob/dac85eac10082dfc3df463aaa74b811144e22122/src/picom.c#L1061 (tv_usec is susecond_t which is long long on 32bits)
2021-11-23 05:41:12 <psykose> suseconds_t is defined as no bigger than long
2021-11-23 05:44:39 <psykose> hm
2021-11-23 05:47:00 <psykose> it's int64_t for me on 64bit, which seems weird as the posix spec is that it's no bigger than long, or at least well, 'supports one or more programming environments' with such an implementation
2021-11-23 05:47:32 <psykose> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html from here
2021-11-23 05:47:39 <psykose> so on 32-bit long it should be 32-bit
2021-11-23 05:48:36 <psykose> the list of values for it is also very small and definitely fits in 32bit int
2021-11-23 05:49:59 <psykose> i wish i had an x86 machine to test some of these things
2021-11-23 05:50:23 <psykose> but in any case that code should be fine
2021-11-23 05:50:26 <psykose> no changes
2021-11-23 05:50:51 <ikke> docker run -it --rm --entrypoint linux32 i386/alpine
2021-11-23 05:53:27 <ikke> or docker run -it --rm --entrypoint linux32 --platform linux/i386 alpinelinux/build-base
2021-11-23 05:53:58 <psykose> that is probably the most useful docker thing i've ever seen
2021-11-23 05:53:59 <psykose> thanks
2021-11-23 05:54:28 <ikke> our x86 ci works like that
2021-11-23 05:54:35 <ktprograms> In armv7 /usr/include/bits/alltypes.h suseconds_t is defined to _Int64 which is defined to long long
2021-11-23 05:55:05 <ikke> long long time_ago;
2021-11-23 05:55:31 <ktprograms> ikke: ?
2021-11-23 05:55:40 <ikke> that was just a joke
2021-11-23 05:55:44 <ktprograms> Oh I see
2021-11-23 05:55:57 <psykose> it should be fine anyway
2021-11-23 05:56:13 <ktprograms> psykose: Ok that's what I thought too
2021-11-23 05:56:17 <psykose> even with it being int128_t, the values are small and nothing should be lost +-ing with 32 bits
2021-11-23 05:56:30 <smcavoy> anyone experienced problems with MR pipelines failing on armhf? see https://gitlab.alpinelinux.org/smcavoy/aports/-/pipelines/100389/builds
2021-11-23 05:56:51 <ktprograms> psykose: apparently long long is still 64 bits on 64bit architectures
2021-11-23 05:56:55 <psykose> yes
2021-11-23 05:57:14 <ikke> Hmm, timeout
2021-11-23 05:57:51 <psykose> i guess it's just a gratuitously ignored posix recommendation, ir the long version is elsewhere, but it really doesn't matter
2021-11-23 05:58:02 <psykose> and the posix spec should have just said int32_t anyway (shoot me)
2021-11-23 05:59:04 <ikke> smcavoy: not sure why those tests take so long
2021-11-23 06:00:22 <smcavoy> indeed.. 
2021-11-23 06:03:47 <psykose> ktprograms: did you find what specifically segfaulted before going on this type hunt?
2021-11-23 06:07:41 <psykose> a backtrace would probably tell you what format specifier somewhere was wrong, but i forgot if you already went through the simpler steps
2021-11-23 06:15:28 <ktprograms> psykose: There weren't too many -Wformat warnings so I'm just going through all the warnings one by one. (The segfault happens when debug logging is enabled so it's in one of the log_debug calls)
2021-11-23 06:15:48 <ericonr> ktprograms: can't you build the program with debug symbols?
2021-11-23 06:15:51 <psykose> yeah, what i'm saying is you can compile with debug symbols and get it to crash in gdb
2021-11-23 06:16:01 <psykose> and it should instantly tell you where the segfault is
2021-11-23 06:16:10 <psykose> just pass -g to CFLAGS
2021-11-23 06:16:31 <ericonr> Does abuild not strip the binary?
2021-11-23 06:16:41 <psykose> then gdb --args ./picom --debug-logging-thing
2021-11-23 06:16:57 <ikke> ericonr: not if you add a -dbg subpackage
2021-11-23 06:16:59 <psykose> ericonr: they are using a locally built version anyway
2021-11-23 06:17:02 <ikke> or add options="!strip"
2021-11-23 06:17:51 <ericonr> psykose: oh fair
2021-11-23 06:18:10 <ericonr> ikke: makes sense :) I guess for local testing !strip is probably the simplest 
2021-11-23 06:18:17 <psykose> and adding tests for the package which segfault on 32bit due to c memes :) for context
2021-11-23 06:18:41 <ericonr> Oh, I've been accompanying the saga heh
2021-11-23 06:18:49 <ericonr> *following 
2021-11-23 06:26:52 <ktprograms> How do I set debug build with meson? Is it --buildtype=debug?
2021-11-23 06:28:41 <psykose> there is a flag like that yeah
2021-11-23 06:28:47 <psykose> or CFLAGS=stuff meson ...
2021-11-23 06:29:08 <smcavoy> ikke: seems to be a bug with armhf, I recreated it locally.
2021-11-23 06:30:08 <psykose> ktprograms: fwif --buildtype=debug is the default if you don't specify
2021-11-23 06:36:36 <ktprograms> It seems that even with !strip and --buildtype=debug the backtrace is only memchr, strnlen, 0x7fffffff, '0xb7ffcf88 in /lib/ld-musl-i386.so.1'
2021-11-23 06:39:27 <psykose> ah you are using abuild
2021-11-23 06:39:42 <psykose> you need to add a -dbg subpackage then
2021-11-23 06:40:43 <ktprograms> I think the last time when I tried it like that it didn't work either. Anyway I'm just going to fix all the warnings then test
2021-11-23 06:41:10 <psykose> just build it yourself instead then
2021-11-23 07:08:41 <ktprograms> lol I pushed my test fixes to my aports in order to test with my changes on a x86 (32 bit) VM but as I was testing I got an email from the gitlab CI 'Fixed pipeline for picom-add-tests'. 😄
2021-11-23 07:15:29 <psykose> and it works :)
2021-11-23 07:15:44 <psykose> grats
2021-11-23 07:16:32 <psykose> the longlong changes might get rejected by upstream, but it works
2021-11-23 07:36:49 <ktprograms> fcolista: Can you please merge !27624?
2021-11-23 07:36:53 <ktprograms> psykose: Thanks
2021-11-23 07:55:10 <fcolista> ktprograms, i was looking at your MR
2021-11-23 08:07:21 <fcolista> ktprograms, can you please squash the two commits?
2021-11-23 08:08:06 <ktprograms> fcolista: I thought it's unrelated enough to be separate?
2021-11-23 08:08:47 <ktprograms> One is about adding tests, and the other fixes a bug that happens to be found by the tests but occurs whenever you use --log-level=debug or --log-level=trace
2021-11-23 08:19:37 <fcolista> ktprograms, program,  well, your first patch was failing on x86, and was fixed by the second one, right?
2021-11-23 08:21:29 <fcolista> if they are unrelated, then they should be on two different MR.If it's on the same MR, then it would be better to have it on the same commit. 
2021-11-23 08:21:35 <fcolista> I don't want to be dogmatich though
2021-11-23 08:21:43 <fcolista> *dogmatic
2021-11-23 08:21:53 <fcolista> ikke, any suggestion on this? 
2021-11-23 08:22:24 <ktprograms> fcolista: I don't mind splitting it into another MR
2021-11-23 08:23:16 <psykose> i don't think the number of mr's matter when it's simple enough to review at once and in the end only the individual commits matter
2021-11-23 08:23:43 <ikke> yeah, splitting up in multiple MRs is not necessary
2021-11-23 08:23:53 <ncopa> good morning!
2021-11-23 08:24:00 <psykose> it also creates a dependency, as the fix has to come before tests
2021-11-23 08:24:04 <ncopa> who is ready for a release today?
2021-11-23 08:24:09 <psykose> since everything is already there might as well merge if no issues
2021-11-23 08:24:11 <ikke> ^^
2021-11-23 08:24:11 <Misthios> you>
2021-11-23 08:24:16 <Misthios> *?
2021-11-23 08:24:29 <fcolista> ok
2021-11-23 08:24:37 <fcolista> I might be too picky :)
2021-11-23 08:24:59 <fcolista> ktprograms, merged. Thanks!
2021-11-23 08:25:10 <ikke> fcolista: The advantage of separate commits is that you can easily revert the 'fix' commit while leaving the tests enabled
2021-11-23 08:25:16 <ncopa> before i start on the release i need some coffee...
2021-11-23 08:25:38 <fcolista> ncopa, my osinfo-db patch is done...just need the official release to send it upstream
2021-11-23 08:26:32 <ktprograms> fcolista: It doesn't show as merged on the GitLab?
2021-11-23 08:26:43 <boomanaiden154> 3.15 today. Let's go!
2021-11-23 08:28:57 <ktprograms> fcolista: Why do you merge manually and not with the GitLab 'Merge' button?
2021-11-23 08:29:11 <mps> in always changing world releases are bad idea
2021-11-23 08:30:27 <mps> for example http://dist.schmorp.de/rxvt-unicode/Changes just released and alpine stable will have old one
2021-11-23 08:31:35 <fcolista> ktprograms, good question...always done it manually since forever..
2021-11-23 08:34:18 <ikke> fcolista: you can merge it locally, but if you 'rebase' the commits, gitlab does not set the mr to merged. If you would update the original branch (force push or rebase on gitlab), it will see it as merged
2021-11-23 08:34:56 <ikke> The advantage is that you can easily find the MR back for a commit
2021-11-23 08:38:31 <fcolista> ikke, ok, thanks. So the quickest way is that when i got a MR, rather than git am locally, it's enough clickin  on "Merge" ?
2021-11-23 08:39:17 <ikke> yes
2021-11-23 08:39:31 <ktprograms> fcolista: Thanks for merging anyway.
2021-11-23 08:40:17 <fcolista> np... i'm not an advanced user of GL, actually I should become more acquainted with it :)
2021-11-23 08:41:45 <psykose> i thought it was done out of not wanting to start/stop a new ci pipeline :)
2021-11-23 08:45:46 <boomanaiden154> The alpine gitlab bot already cancels the CI pipelines upon merge.
2021-11-23 08:52:24 <ikke> Only for detached / fork pipelines afaik
2021-11-23 09:27:08 <ktprograms> Any idea why swi-prolog didn't get built for ppc64le?
2021-11-23 09:29:10 <psykose> maybe the builder is down
2021-11-23 09:30:05 <ikke> hmm, yea
2021-11-23 09:30:07 <psykose> nothing on ppc64le has been updated in 4 days
2021-11-23 09:30:25 <ikke> oof
2021-11-23 09:30:45 <ktprograms> It seems riscv64 is also not updating (picom)
2021-11-23 09:31:08 <ikke> riscv64 is blocked
2021-11-23 09:31:10 <psykose> along with every other package
2021-11-23 09:31:29 <ktprograms> ikke: Why is it blocked?
2021-11-23 09:31:54 <ikke> hylafaxplux + gdal
2021-11-23 09:33:17 <psykose> that sounds like a fancy plushie name
2021-11-23 09:33:38 <ktprograms> Looks like build-edge-ppc64le is stuck on main/ncurses due to the apk repository lock having a bad file descriptor?
2021-11-23 09:40:20 <ikke> probably crashed mid-build
2021-11-23 09:40:32 <ikke> read-only filesystem :/
2021-11-23 09:40:38 <ikke> need to reboot the vm
2021-11-23 09:42:09 <ncopa> uh uh...
2021-11-23 09:42:16 <ncopa> so no ppc64le
2021-11-23 09:52:19 <clandmeter> looks like its not coming back, or its terrible slow in booting.
2021-11-23 10:00:36 <ncopa> they are back
2021-11-23 10:15:42 <ncopa> I'm going over the issues now
2021-11-23 10:15:45 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11546
2021-11-23 10:15:52 <ncopa> lots of the tests are still failing on armhf
2021-11-23 10:16:04 <ncopa> anyone wants to followup? we need to report it upstream
2021-11-23 10:25:44 <ikke> clandmeter: terribly slow at booting
2021-11-23 11:23:22 <clandmeter> ikke: heh, nice... io is that slow?
2021-11-23 11:23:49 <ikke> I haven't measured it
2021-11-23 11:30:11 <ikke> ncopa: should I create a release checklist for 3.15?
2021-11-23 11:33:49 <ikke> #13221
2021-11-23 11:47:10 <mps> ikke: please add note wherever you think is appropriate that xorg users should probably fix DPI settings (in .Xresources I think) after upgrade
2021-11-23 11:47:38 <ikke> mps: ncopa mentioned the change might've been reverted again?
2021-11-23 11:47:56 <mps> ?
2021-11-23 11:48:09 <mps> xorg-server is already merged
2021-11-23 11:48:21 <ikke> I mean upstream
2021-11-23 11:48:31 <ncopa> i think i saw somewhere that xorg-server already merged it upstream, yes
2021-11-23 11:48:38 <ikke> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/33#note_193586
2021-11-23 11:49:03 <mps> ncopa: what, reverted DPI improvement?
2021-11-23 11:49:13 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27599
2021-11-23 11:49:36 <ncopa> https://gitlab.freedesktop.org/xorg/xserver/-/issues/1241#note_1153655
2021-11-23 11:51:26 <mps> huh, why then it happened to me yesterday on M1 with simpledrm I wonder
2021-11-23 11:52:00 <mps> I had to increase dpi for 50%
2021-11-23 11:52:53 <mps> but ok, then this not need notes for release
2021-11-23 11:56:03 <ncopa> so, xorg-server 21 had the DPI fix
2021-11-23 11:56:16 <ncopa> then they realized it created more isses than it solved, so they reverted it upstream
2021-11-23 11:56:48 <ncopa> so I guess what happened was that you had xorg with the fix, then you upgraded and got the version that reverted the fix
2021-11-23 11:56:59 <ncopa> the boost 1.77 upgrade went bad
2021-11-23 11:57:10 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13214#note_193724
2021-11-23 11:59:02 <psykose> these xorg dpi issues look like a decade of xorg giving the wrong dpi, everything under the sun having workarounds for it, and now that it is fixed everything breaks
2021-11-23 12:00:18 <psykose> yep, end of thread concludes as such
2021-11-23 12:00:27 <psykose> sad
2021-11-23 12:00:29 <mps> ncopa: no, I played with both and it is very strange. but lets see what the users reactions will be after release
2021-11-23 12:00:51 <mps> psykose: I think so
2021-11-23 12:01:02 <psykose> the thread mentions revert happening in 21.1.2
2021-11-23 12:01:06 <psykose> alpine is 21.1.1
2021-11-23 12:01:25 <mps> and 21.1.2 is not yet released
2021-11-23 12:01:59 <psykose> says in the coming week a week ago.. so any day now
2021-11-23 12:03:40 <mps> good example why to keep bugs in software even when it could be fixed :)
2021-11-23 12:04:00 <ncopa> oh...
2021-11-23 12:04:05 <ncopa> i thought it was released
2021-11-23 12:04:31 <ncopa> boost issue worries me
2021-11-23 12:04:42 <psykose> boost issue looks like things mixing versions by that issue you linked
2021-11-23 12:04:52 <psykose> as you say, but i think things just need to rebuild to 1.77
2021-11-23 12:04:54 <ncopa> yes, that is what worries me
2021-11-23 12:05:08 <ncopa> why was that not done when upgradeing boost to 1.77?
2021-11-23 12:05:32 <psykose> i don't know... mtxclient is even explicitly just boost-dev and not a version
2021-11-23 12:05:35 <psykose> seems it got missed
2021-11-23 12:05:52 <ncopa> i tried to rebuild it, and when i started nheko it killed my xorg...
2021-11-23 12:06:12 <psykose> haha
2021-11-23 12:06:40 <ncopa> that was exactly what I was hoping would happen on the day i planned to do the release...
2021-11-23 12:07:45 <psykose> par for the course
2021-11-23 12:08:45 <ncopa> ok. so my next question is: what else got missed?
2021-11-23 12:09:00 <ncopa> $ apk search -q --exact --origin -r boost1.76-* | sort -u | wc -l
2021-11-23 12:09:00 <ncopa> 35
2021-11-23 12:09:15 <mps> releases should be yearly
2021-11-23 12:09:32 <ncopa> some of those are libraries....
2021-11-23 12:10:01 <psykose> i like how one of the things on that list is 'bitcoin'
2021-11-23 12:10:24 <ncopa> also, what will happen if we push a security fix to any of those in 3.15-stable in the future?
2021-11-23 12:10:34 <ncopa> they will switch over to boost 1.77
2021-11-23 12:10:38 <psykose> yep
2021-11-23 12:10:40 <ncopa> and unexpected things may happen
2021-11-23 12:10:43 <ncopa> oh my...
2021-11-23 12:10:44 <psykose> this has to be all rebuilt
2021-11-23 12:10:52 <ncopa> how goud we go so wrong?
2021-11-23 12:11:03 <ikke> hmm, boost was moved to main before the 3.15 builders were setup, how could they have been built against 1.76?
2021-11-23 12:11:04 <psykose> but i think something like libtorrent-rasterbar might even fail, given its history
2021-11-23 12:11:31 <ncopa> ikke: i think boost1.77 was introduced after the 3.15 builders were up
2021-11-23 12:11:44 <ncopa> psykose: yup
2021-11-23 12:11:58 <ncopa> im pretty sure at least some of those will fail
2021-11-23 12:12:12 <ncopa> which liekly is the reason why someone wanted to have both 1.76 and 1.77
2021-11-23 12:13:48 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27133 this doesn't bode well
2021-11-23 12:17:28 <ncopa> both boost1.76 and boost1.77 claims boost-dev
2021-11-23 12:18:14 <ncopa> do anything depending on boost-dev may pick any of them, depending if there are any runtime deps depenging on either
2021-11-23 12:19:02 <ncopa> so if your package has a makedepends="boost-dev ..." you will get boost1.77 as it has newer version
2021-11-23 12:19:57 <ncopa> unless you have other dependency in the dependency chain that has a runtime dependency to boost1.76, in which case you'll end up with boost1.76
2021-11-23 12:20:09 <ncopa> this is sort of a nightmare
2021-11-23 12:21:23 <ncopa> boost1.77 was moved to main in a8ba11c16c104b234557c597f40734ff55502a49
2021-11-23 12:21:25 <ikke> Sorry :(
2021-11-23 12:21:40 <ikke> I had to be more diligent there
2021-11-23 12:22:02 <ncopa> i guess this things can happen
2021-11-23 12:22:20 <ncopa> but we need to be careful when we have multiple versions of same library
2021-11-23 12:22:34 <ncopa> we try to avoid that for a (IMHO good) reason
2021-11-23 12:24:57 <ncopa> oh... i thikn its worse
2021-11-23 12:25:16 <ncopa> there are a number of packages that does not have runtime linking to boost. they only use the headers
2021-11-23 12:26:02 <ncopa> which means that if one of those gets a security fix in the future, they will change boost version with security fix, which may lead to unexpected build failures
2021-11-23 12:27:39 <ncopa> hum... they were rebuilt.... aedfe60e91af878f60614b2f325abf7e464bb427
2021-11-23 12:49:58 <ncopa> poedit is problematic as well. pullsin both boost1.77 and 1.76 when I try to rebuild it
2021-11-23 12:56:12 <psykose> probably because lucene is 1.76
2021-11-23 12:56:18 <psykose> it has to be done bit by bit
2021-11-23 12:59:45 <ncopa> yeah, my script didnt pick up lucene++
2021-11-23 13:00:02 <ncopa> so im working on a better rebuild cmdline
2021-11-23 13:00:13 <ncopa> it does not help that my xorg server constantly crashes...
2021-11-23 13:02:42 <ncopa> apk search -q boost1.76* | xargs apk info -q --provides | grep ^so: | cut -d=  -f1 | xargs apk list --depend
2021-11-23 13:05:37 <caskd> is apk3 gonna have machine parsable output modes?
2021-11-23 13:11:24 <ncopa> caskd: hopefully yes
2021-11-23 13:11:38 <ncopa> argh! why is my xorg-server crashing all the time... and today of all days
2021-11-23 13:19:26 <ncopa> well... i guess it was a good thing that we discovered this boost business before the release
2021-11-23 13:21:42 <psykose> how many boost-sized holes do you think will be found after release? :p
2021-11-23 13:23:27 <ncopa> 0
2021-11-23 13:23:53 <ncopa> think we can purge boost1.76 now
2021-11-23 13:24:10 <ikke> 👍
2021-11-23 13:24:13 <ncopa> or move it to community at least
2021-11-23 13:25:15 <ncopa> there are 18 packages in testing
2021-11-23 13:37:43 <ncopa> ok im seeing light in the tunnel
2021-11-23 13:37:55 <ncopa> also, watching a few cat videos help :)
2021-11-23 13:40:32 <psykose> no cat at home to floof? :3
2021-11-23 13:42:49 <ncopa> unfortunally no :-(
2021-11-23 13:44:00 <ncopa> im gonna take a walk while waiting for the builders. its sunny
2021-11-23 13:44:37 <psykose> have a great walk!
2021-11-23 15:04:49 <ncopa> im back, and ready for a new fight against ppc64le
2021-11-23 15:04:54 <ncopa> something is broken
2021-11-23 15:05:07 <ncopa> >>> megapixels: Analyzing dependencies...
2021-11-23 15:05:07 <ncopa>     required by: libsrtp-2.4.2-r1[so:libcrypto.so.3]
2021-11-23 15:05:07 <ncopa>   so:libcrypto.so.3 (no such package):
2021-11-23 15:05:07 <ncopa> ERROR: unable to select packages:
2021-11-23 15:05:30 <ncopa> why is libsrtp linked to libcrypto.so.3 on ppc64le, but not on the other architectures?
2021-11-23 15:14:20 <ncopa> seems like we have a handful of packages still lniked to openssl 3
2021-11-23 15:15:11 <ikke> ncopa: maybe for the next release cycle, we shoud plan a sanity check
2021-11-23 15:15:17 <ikke> before we do the release
2021-11-23 15:26:03 <the6543> hi
2021-11-23 15:26:14 <the6543> I have an important MR
2021-11-23 15:26:30 <the6543> (!27702)
2021-11-23 15:26:46 <the6543> it fix CVE-2021-41281: Path traversal when downloading remote media.
2021-11-23 15:27:02 <the6543> looking forward to see smoe reviews/merges ;)
2021-11-23 15:27:42 <the6543> backport: !27703
2021-11-23 15:31:07 <ncopa> someone pushed inkscape rebuild also. so it seems like the release will be delayed
2021-11-23 15:37:28 <the6543> well it's known since 12:00 UTC today - some minutes more wont make a difference
2021-11-23 15:37:34 <the6543> but it should happen today ;)
2021-11-23 15:51:15 <the6543> @ncopa  - rebased
2021-11-23 16:24:52 <the6543> by the way - tanks to @smcavoy ... the !26273 is ready :tada:
2021-11-23 16:35:36 <the6543> what are the requirements to move a testing package into community?
2021-11-23 17:07:07 <ikke> the6543: Generally tested that the package works + a merge request to do so
2021-11-23 17:08:01 <ikke> And the expectation that you keep the package in good shape for the last stable release (6 months)
2021-11-23 17:49:17 <Saijin_Naib[m]> What is the proper etiquette for a bunch of python packages being outdated? Flag on pgks.alpinelinux.org, or make a MR for each with the changes (since I tested/built each locally), or make a mega all-in-one MR that has all of them together?
2021-11-23 17:49:35 <Saijin_Naib[m]> Basically the sphinx documentation ones
2021-11-23 18:41:46 <ncopa> i guess it depends a bit on the maintainer, but I would expect most maintainers be thankful for a well done MR
2021-11-23 18:42:09 <ncopa> a single MR with multiple commits should be fine
2021-11-23 18:42:35 <mps> I have 'interesting' problem, on machine without sound card and no driver loaded firefox and mpv are stuck on start
2021-11-23 18:43:10 <mps> when disabling audio in mpv it works and shows video
2021-11-23 18:52:04 <Hello71> it is probably waiting for pulse or something
2021-11-23 18:52:19 <ncopa> we are all waiting for pulse...
2021-11-23 18:53:49 <dalias> to be removed?
2021-11-23 18:55:21 <mps> yes, I thought to rebuild them again without pulse and pipewire
2021-11-23 18:56:00 <dalias> :)
2021-11-23 18:56:12 <dalias> i havent looked at the code but folks seem pretty happy with pipewire
2021-11-23 18:57:21 <mps> folks are happy with gnome :)
2021-11-23 18:58:46 <ncopa> with pipewire I have a working volume control applet in xfce. makes me happy
2021-11-23 18:58:57 <ncopa> but I dont have any sound in chromium for some reason
2021-11-23 19:01:10 <mps> i wrote sound control applets for awesomewm in lua, for alsa
2021-11-23 19:05:02 <dalias> mps, i mean folks in communities i expect to have higher expectations for software :-p
2021-11-23 19:06:36 <Saijin_Naib[m]> ncopa: Thank you. I was having trouble figuring out how I could do all of them in a single squashed commit in the MR. If multiple commits is fine in the single MR, I can do that without messing it up too bad, I think
2021-11-23 19:06:55 <ikke> Saijin_Naib[m]: at least one commit per package
2021-11-23 19:07:10 <ikke> Unless the amount of packages is very significant and the change trivial
2021-11-23 19:07:13 <Saijin_Naib[m]> ikke: Is that for clarity of reading what changed for each APKBUILD?
2021-11-23 19:07:30 <Saijin_Naib[m]> Offhand I think like 10 packages, and mostly just version bumps in the APKBUILD and new hashes
2021-11-23 19:07:41 <ikke> 10 packages can just be one commit per package
2021-11-23 19:07:50 <ncopa> i think version bumps is nice in separate commits
2021-11-23 19:08:05 <smcavoy> I noticed a  package in testing (partclone) was not able to be installed due to 'so:libcrypto.so.3 (no such package)' but libcrypto3 exists. Rebuilding it locally links against libcrypto.so.1.1 and installs. Wondering if its my setup or stuff needs to be rebuilt..
2021-11-23 19:08:09 <ncopa> unless they are tied (you cannot revert one without revert the other)
2021-11-23 19:08:22 <ikke> Saijin_Naib[m]: the commit message also makes more sense if you do it per package
2021-11-23 19:08:45 <ikke> smcavoy: probably needs to be rebuilt
2021-11-23 19:10:03 <ncopa> smcavoy: probably due to 57e309f24940ca0b79ce2c2c19b3219398cc6632
2021-11-23 19:10:06 <smcavoy> is that related to the openssl changes that were reverted?
2021-11-23 19:10:36 <Saijin_Naib[m]> ikke: Understood. Thank you!
2021-11-23 19:11:02 <ncopa> probably. I rebuilt a handful packages with openssl1.1 today. in main and community
2021-11-23 19:11:18 <ncopa> didnt touch testing because i tried to get the release out today
2021-11-23 19:11:37 <Saijin_Naib[m]> ncopa: I do not know about whether they are tied or not. All python packages.
2021-11-23 19:11:50 <smcavoy> the release sounds more important 
2021-11-23 19:11:53 <ncopa> then separate commits are fine
2021-11-23 19:11:56 <ncopa> smcavoy: exactly
2021-11-23 19:12:14 <ncopa> unfortunately, that recent openssl change broke things and delayed the release
2021-11-23 19:13:41 <ncopa> this one "broke" it 57e309f24940ca0b79ce2c2c19b3219398cc6632
2021-11-23 19:14:05 <ncopa> bit it was kinda good, because then we detected the packages still linked to openssl3
2021-11-23 19:14:47 <ncopa> unfortunately it also broke testing which got downprioritized
2021-11-23 19:15:58 <smcavoy> well, glad to hear the release will be out soonish
2021-11-23 19:16:17 <ikke> This week™
2021-11-23 19:16:36 <ikke> With a strong preference towards tomorrow
2021-11-23 19:16:56 <ncopa> likely tomorrow. I pushed partclone rebuild
2021-11-23 19:17:49 <smcavoy> ok, thanks. I will close ~27708
2021-11-23 19:18:29 <ncopa> smcavoy: you are the maintainer for partclone, I was about to suggest move it to community so it gets included in 3.15 release
2021-11-23 19:19:06 <ikke> except for aarch64, the 3.15 builders are idle
2021-11-23 19:19:21 <ncopa> but looks like it may need a better review. there are some questionable makedepends: libuuid libbsd
2021-11-23 19:19:56 <smcavoy> ok sure, moving it to community would be good
2021-11-23 19:20:03 <ncopa> are patchutils and diffutils only build time deps? or also runtime deps?
2021-11-23 19:20:16 <ncopa> i can move it for you if we just clean it up a bit
2021-11-23 19:20:47 <ncopa> and if you can support it. help us with secfixes, bug reports etc when needed
2021-11-23 19:20:51 <the6543> is 3.15 near release date or wat's up?!?
2021-11-23 19:20:58 <ikke> the6543: tomorrow
2021-11-23 19:21:00 <ncopa> was scheduled for today
2021-11-23 19:21:05 <the6543> heh
2021-11-23 19:21:08 <ncopa> but builders were too slow
2021-11-23 19:21:22 <the6543> ok I have one pull mith that milestone I just made ready
2021-11-23 19:21:29 <the6543> !26273
2021-11-23 19:22:01 <the6543> should it be moved or merged?
2021-11-23 19:22:07 <ncopa> so thats why the CIs have been eating the cpu power from the builders.... :)
2021-11-23 19:22:48 <the6543> well was not aware i just had time today :D
2021-11-23 19:23:24 <ikke> yay, a couple of xen vulnaribilities just dropped
2021-11-23 19:23:45 <the6543> hehe - ok should i rebase the pull?
2021-11-23 19:23:56 <ikke> https://www.openwall.com/lists/oss-security/2021/11/23/
2021-11-23 19:23:59 <the6543> or are you scheduling it by ureselfe?
2021-11-23 19:24:06 <the6543> *yourselfe
2021-11-23 19:24:20 <ikke> the6543: let the one who is going to merge it rebase it
2021-11-23 19:24:25 <the6543> ok so many CVEs that are published today :D
2021-11-23 19:24:33 <the6543> ok
2021-11-23 19:24:38 <the6543> *ACK
2021-11-23 19:24:53 <smcavoy> ncopa: happy to update the package when needed. Not 100% sure about patch/diff utils might actually be needed for building packages on other platforms
2021-11-23 19:27:23 <ncopa> yeah, diffutils is needed for some binary diff apparently
2021-11-23 19:29:33 <ncopa> the6543: looks a bit scary so late
2021-11-23 19:29:59 <ncopa> smcavoy: what do you think about this? https://tpaste.us/5n09
2021-11-23 19:30:29 <the6543> well it has a long history if you like to read throu
2021-11-23 19:30:46 <the6543> but in the end it was good to go all the time - just one test and it's subtests failed
2021-11-23 19:30:54 <ncopa> its the long story that scares me :) 
2021-11-23 19:31:08 <the6543> because ssh-rss was not supported by default somehow anymore
2021-11-23 19:31:12 <the6543> *allowed
2021-11-23 19:31:27 <the6543> and the the easyest fix in the end you can see is the patch file
2021-11-23 19:32:02 <the6543> ```diff
2021-11-23 19:32:12 <the6543> -		"ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -i 
2021-11-23 19:32:13 <the6543> +		"ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o IdentitiesOnly=yes -o  HostkeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -i \""+keyFile+"\"")
2021-11-23 19:32:15 <the6543> ```
2021-11-23 19:32:33 <the6543> (HostkeyAlgorithms=+ssh-rsa)
2021-11-23 19:33:46 <ncopa> i read it. and i think its fine. it got reported upstream as well
2021-11-23 19:33:54 <ncopa> and apparently fix is from upstream?
2021-11-23 19:34:04 <ncopa> and it was only the test anyway
2021-11-23 19:34:04 <ikke> I think the6543 is upstream as well
2021-11-23 19:34:28 <the6543> most parts - if not I'll add them as usual
2021-11-23 19:34:50 <ncopa> the changes looks fine
2021-11-23 19:35:28 <ncopa> nitpick: I prefer $PWD over $(pwd), but its just a question of taste
2021-11-23 19:35:37 <ikke> (no fork)
2021-11-23 19:36:06 <ncopa> yeah, but does not matter at all in this context
2021-11-23 19:38:29 <smcavoy> ncopa: looks good. 
2021-11-23 19:39:53 <the6543> hi @smcavoy
2021-11-23 19:40:03 <the6543> thank's for the patch by the way
2021-11-23 19:40:33 <smcavoy> the6543: no worries. good to see it worked
2021-11-23 19:41:19 <the6543> did you create a pull for that specific path upstream to `main` and `release/v1.15` branch?
2021-11-23 19:41:37 <the6543> *patch
2021-11-23 19:42:29 <ncopa> me? just a local git commit and `git format-patch -1 --stdout | tpaste`
2021-11-23 19:42:37 <the6543> (I wont steal your credists if you like to have them) ...
2021-11-23 19:42:47 <the6543> no @smcavoy
2021-11-23 19:43:34 <ncopa> i figured. im returning to under my rock..
2021-11-23 19:43:50 <the6543> oh hihi - must be a nice rock
2021-11-23 19:44:07 <ncopa> smcavoy: so I guess you are ok that i move it to community?
2021-11-23 19:44:41 <smcavoy> the6543: no I have not. I have the patch, just have not gotten around to running the tests before creating a PR.
2021-11-23 19:44:49 <smcavoy> ncopa: yes I am
2021-11-23 19:45:25 <smcavoy> the6543: I will get around to it this week.
2021-11-23 19:45:44 <smcavoy> (unless someone else does it first.. )
2021-11-23 19:46:03 <the6543> well it's few seconds away for me
2021-11-23 19:46:19 <the6543> just a git apply and commit
2021-11-23 19:46:30 <ikke> hfsprogs missing
2021-11-23 19:47:20 <smcavoy> ah
2021-11-23 19:47:42 <ncopa> oh my
2021-11-23 19:47:50 <ncopa> my bad
2021-11-23 19:47:55 <ncopa> and i clean it up
2021-11-23 19:48:06 <smcavoy> forgot that was in testing :(
2021-11-23 19:48:15 <ncopa> it was my bad. im tired
2021-11-23 19:49:45 <ikke> #13222
2021-11-23 19:57:13 <Ariadne> ikke: i am working on the xen XSAs
2021-11-23 19:57:22 <ikke> Ariadne: good
2021-11-23 19:57:38 <Ariadne> it would be nice if we could wait for that to land before doing 3.15 release (i am just waiting to smoketest it)
2021-11-23 19:57:49 <ikke> release will be tomorrow
2021-11-23 19:58:15 <Ariadne> alright
2021-11-23 20:26:49 <Ariadne> alandiwix: have you verified that the pgrep/pkill -u patch I implemented is sufficient for pipewire?
2021-11-23 20:34:21 <ncopa> Ariadne: you have an s390x machine, right? will you ever play widelands on it? I was wondering if we should disable s390x, just to save space on the mirrors. its almost 1G size
2021-11-23 20:34:28 <Ariadne> LOL
2021-11-23 20:34:35 <alandiwix> Ariadne: I tried it with other persistent processes, same binary, different users - works perfectly fine, I don't think pipewire is different in this regard.
2021-11-23 20:34:59 <Ariadne> ncopa: no, i don't think widelands is the sort of thing people are doing on alpine s390x
2021-11-23 20:35:18 <ncopa> what i figured. so I think we can disable it for s390x
2021-11-23 20:35:22 <Ariadne> yes
2021-11-23 20:35:28 <alandiwix> :D
2021-11-23 20:35:51 <Ariadne> though we should really fix our repo management to dedup noarch packages
2021-11-23 20:36:47 <ikke> :D
2021-11-23 20:36:52 <ncopa> it requires that the builders are aware of the other arches
2021-11-23 20:37:04 <Ariadne> true
2021-11-23 20:37:07 <ikke> same with libpostal-data
2021-11-23 20:37:12 <ncopa> builds needs to be coordinated across arches
2021-11-23 20:37:18 <omni> what is this productivity suite? never heard of widelands before
2021-11-23 20:37:49 <ncopa> tbh, i dont think anyone wiht an s390x will ever use libreoffice on it either
2021-11-23 20:38:20 <ikke> Did we tests any rc on ppc64le and s390x btw?
2021-11-23 20:38:43 <ncopa> i dont think so. nobody cared
2021-11-23 20:38:45 <Ariadne> yes, i created a ldom with 3.15 rc5 iso this morning
2021-11-23 20:38:49 <Ariadne> it booted fine
2021-11-23 20:38:54 <ncopa> ah! cool
2021-11-23 20:38:54 <Ariadne> setup-alpine works
2021-11-23 20:38:57 <ncopa> wow
2021-11-23 20:39:24 <Ariadne> have not tested ppc64le
2021-11-23 20:39:40 <Ariadne> but ppc64le needs 4K page_size kernel to be usable on talos
2021-11-23 20:39:42 <ncopa> I suspect someone from IBM is testing while we speak
2021-11-23 20:39:59 <ikke> I don't think they will use an rc, do they
2021-11-23 20:40:03 <Ariadne> we should create 4k page_size kernel variant in future
2021-11-23 20:40:13 <Ariadne> without it, the GPU drivers are all buggy :)
2021-11-23 20:42:16 <Ariadne> ncopa: the only game i've ever installed on s390x is freeciv-server
2021-11-23 20:43:00 <ncopa> game servers are ok i guess
2021-11-23 20:44:04 <Ariadne> a lot don't work on s390x because big-endian
2021-11-23 20:58:26 <Ariadne> ugh
2021-11-23 20:58:41 <Ariadne> ran out of disk space on my Xen machine
2021-11-23 20:58:52 <Ariadne> (in the dom0)
2021-11-23 20:59:14 <ncopa> whee!!! \o/ apk dot --errors is empty for v3.15
2021-11-23 20:59:33 <ikke> nice
2021-11-23 20:59:46 <ncopa> Ariadne: did you play widelands on it?
2021-11-23 21:00:03 <Ariadne> what is this game
2021-11-23 21:00:28 <Ariadne> "realtime strategy game with emphasis on economy and transport"
2021-11-23 21:01:03 <ncopa> no idea. i just discovered it due to boost 1.77 rebuild
2021-11-23 21:01:03 <Ariadne> looks like a Sid Meier's Colonization clone
2021-11-23 21:01:54 <Ariadne> could actually be interesting
2021-11-23 21:02:04 <Ariadne> maybe someday :)
2021-11-23 21:02:27 <omni> yes, I fear so too
2021-11-23 21:07:46 <Ariadne> okay, rebooting my xen server now
2021-11-23 21:12:16 <maxice8> widelands is more based on the settler's franchise than Sid Meier's Civ
2021-11-23 21:12:32 <Ariadne> colonization is a mashup between settlers and civ
2021-11-23 21:13:14 <maxice8> I must be thinking of a different colonization
2021-11-23 21:13:35 <Ariadne> i'm talking about the original Amiga / MS-DOS one, not the Civ4 mod
2021-11-23 21:13:51 <maxice8> makes sense then, I only played the civ4 spin-off 
2021-11-23 21:21:15 <Ariadne> alandiwix: sent it
2021-11-23 21:23:56 <alandiwix> many thanks
2021-11-23 21:35:22 <ikke> oof, libmagic upgrade with soname change in 3.14
2021-11-23 21:36:13 <ikke> #13224
2021-11-23 21:58:15 <ikke> maxice8: imagemagick upgrade causes issues
2021-11-23 21:59:18 <maxice8> looking
2021-11-23 21:59:43 <ikke> jirutka is apparently working on it as well
2021-11-23 21:59:48 <gay> the APKBUILD for godot looks weird: godot 3.x doesn't support vulkan; "bits=64", "use_llvm=no" and "platform=x11" are redundant; doesn't include server and export template (official binaries are dynamically linked against glibc); if you care about packages using system libraries instead of bundled ones, you need to add lots of "builtin_*=no" https://github.com/void-linux/void-packages/blob/master/srcpkgs/godot/template#L13
2021-11-23 22:02:57 <ikke> https://github.com/alpinelinux/aports/pull/3220
2021-11-23 22:06:53 <gay> ikke: that's a really old PR which was not even merged, meanwhile I'm referring to what I've seen here: https://git.alpinelinux.org/aports/tree/testing/godot/APKBUILD
2021-11-23 22:08:11 <ikke> gay: being closed does not mean it's not merged. With github, we usaully manually rebased the commits and pushed them, and then closed it
2021-11-23 22:08:42 <ikke> although it was stale
2021-11-23 22:09:36 <ikke> gay: but it was once added by that author, and later just minimally updated
2021-11-23 22:10:54 <gay> I'm considering to switch from void to alpine, but while I'm sitting on void I'm unable to update the port
2021-11-23 22:13:00 <gay> also from what I see with scons you're not taking benefit of having multiple processor cores?
2021-11-23 22:16:29 <ikke> I have no experience with scons 
2021-11-23 23:03:42 <Hello71> ctest is also stuck at one job
2021-11-23 23:03:50 <Hello71> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/122
2021-11-24 00:17:30 <boomanaiden154> I'm currently working on adding tests to VTK, and making that change would certainly be helpful.
2021-11-24 00:17:42 <boomanaiden154> The test suite currently takes like 20-30 minutes in CI and times out on some of the jobs.
2021-11-24 07:11:40 <ncopa> good morning
2021-11-24 07:23:11 <wener> good morning
2021-11-24 07:24:00 <wener> I'm at UTC+8, but live like in your timezone....
2021-11-24 07:30:26 <mps> \o
2021-11-24 07:47:24 <fcolista> so, are we going to celebrate 3.15 today? :)
2021-11-24 08:02:01 <ncopa> yes!
2021-11-24 08:02:45 <wener> is 3.15 out ? seems release page is not update yet
2021-11-24 08:06:48 <mps> wener: not yet
2021-11-24 08:11:40 <fcolista> \0/ looking forward!
2021-11-24 08:12:45 <mps> well, edge is quite fine
2021-11-24 08:40:13 <wener> will 3.15 support riscv64 ?
2021-11-24 08:41:16 <wener> writing a 3.15 release note in chinese https://wener.me/notes/os/alpine/alpine-version#315
2021-11-24 08:46:36 <mps> wener: not officially
2021-11-24 08:47:46 <ikke> Indeed, we are waiting for suitable hardware to build it on (and enable tests)
2021-11-24 08:48:11 <ikke> Most available hardware are comparable with rpi's 
2021-11-24 08:48:52 <wener> 😄 so, release will include riscv64 iso and rootfs ?
2021-11-24 08:49:10 <mps> wener: but we have everything ready for someone who want to install it on real hardware or in qemu
2021-11-24 08:49:58 <wener> good to know that, riscv still need some time
2021-11-24 08:50:17 <mps> I haven't seen images for install, but maybe someone will make them
2021-11-24 08:50:34 <psykose> what are the next planned/rumoured hardware releases? it will probably take that +6months to get something solid set up
2021-11-24 08:51:34 <mps> with current market/industry status I think everything will be slowed/postponed
2021-11-24 08:56:04 <ikke> wener: no, no iso's / rootfs for 3.15 for risc64
2021-11-24 08:56:32 <ikke> wener: https://dl-cdn.alpinelinux.org/alpine/v3.15/main/ riscv64 is missing here
2021-11-24 08:57:31 <wener> ricsv64 is postponed to 3.16 ?
2021-11-24 08:57:55 <wener> or, when hardware is readly
2021-11-24 08:58:13 <boomanaiden154> Are there any upcoming higher performance Risc-V CPUs? Companies like SiFive only seem to be offerring up to 8 cores that probably aren't clocked too high.
2021-11-24 08:58:47 <mps> I thought to make unofficial iso for qemu but didn't found time for this, maybe will do around beginning of next year
2021-11-24 08:59:51 <ikke> wener: there is no set release for rv64
2021-11-24 09:00:27 <wener> thanks
2021-11-24 09:02:07 <wener> emmm, but how debian build there rv64 pipeline
2021-11-24 09:03:10 <wener> maybe alpine have to wait some sponsor who need rv64
2021-11-24 09:08:55 <ikke> wener: we did receive some hardware, but it's not fast enough to act as builders
2021-11-24 09:09:35 <ktprograms> Correct me if I'm wrong, but GHC can't be built into a fully static version, right?
2021-11-24 09:10:56 <ncopa> ktprograms: that is how understand it yes
2021-11-24 09:12:06 <ncopa> i tagged rc6
2021-11-24 09:12:13 <psykose> nothing in the docs about it, so i assume not
2021-11-24 09:12:30 <ncopa> just to make sure the release is actually built. will do 3.15.0 once its confirmed the rc6 built fine
2021-11-24 09:15:32 <ktprograms> Bit of a pity about GHC since if it were static once built it could be archived for future bootstrapping and never break.
2021-11-24 09:20:02 <ncopa> ok here we go... 3.15.0 tagged
2021-11-24 09:21:04 <clandmeter> \o/
2021-11-24 09:21:53 <clandmeter> i think we should have algitbot announce tags here  :)
2021-11-24 09:24:44 <ncopa> .git/hooks/post-checkout: cd: line 6: can't cd to community/solid-community-server/src/community-server-2.0.0/: No such file or directory
2021-11-24 09:24:56 <ncopa> whats that?
2021-11-24 09:25:57 <ikke> 
ACTION suspects husky

2021-11-24 09:26:14 <ikke> grep -l husky .git/hooks
2021-11-24 09:28:35 <ncopa> build-3-15-x86_64 [~/aports]$ grep -l husky .git/hooks/* | tpaste
2021-11-24 09:28:35 <ncopa> https://tpaste.us/ovBB
2021-11-24 09:29:13 <ncopa> how do we prevent that to happen?
2021-11-24 09:29:20 <ncopa> i guess rootbld is the answer
2021-11-24 09:29:22 <ikke> yes
2021-11-24 09:31:05 <clandmeter> rootbld is the answer to many problems :)
2021-11-24 09:31:36 <ikke> How do we handle bootstrapping packages with rootbld?
2021-11-24 09:31:39 <clandmeter> and probably a recipe for a few new ones
2021-11-24 09:32:10 <clandmeter> ikke: good question
2021-11-24 09:32:25 <clandmeter> i guess boostrapping should be done manually
2021-11-24 09:33:24 <clandmeter> I guess the list of those pkgs is growing?
2021-11-24 09:37:37 <ikke> relatively stable
2021-11-24 09:37:44 <ikke> ghc, go and rust
2021-11-24 09:38:23 <ikke> another question, do we want to store modules for go and crates for rust on distfiles?
2021-11-24 09:38:30 <ikke> if we go rootbld, they get removed
2021-11-24 09:51:59 <clandmeter> i think for speed it doesnt matter much, but for history reasons maybe?
2021-11-24 09:52:44 <clandmeter> but tbh, it will be more complicated to support each package manager for each lang.
2021-11-24 09:53:11 <clandmeter> and some will need direct disk access, not http based.
2021-11-24 09:53:34 <ikke> yes, mostly for historical purposes / making sure future builds will still work
2021-11-24 09:54:27 <clandmeter> you would need to create some profile to which directories you want to mount from distfiles into rootbld?
2021-11-24 09:54:43 <clandmeter> or mount home
2021-11-24 09:55:15 <clandmeter> its also nice that rootbld cleans up after itself, leaving nothing behind to conflict other builds.
2021-11-24 09:57:19 <ikke> nod
2021-11-24 10:06:04 <clandmeter> do you want to have specific directories mounted in the chroot?
2021-11-24 10:08:26 <ikke> You can direct these paths with environment variables
2021-11-24 10:08:33 <ikke> out of $HOME
2021-11-24 10:09:34 <ncopa> should we mention something about kde in the release notes?
2021-11-24 10:09:38 <ncopa> kde 21.08?
2021-11-24 10:11:07 <clandmeter> we want to do that also with git repos like for golang?
2021-11-24 10:35:58 <ncopa> I have re-arranged the release notes. Please take a look: https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html
2021-11-24 10:36:30 <ikke> The secureboot link is broken
2021-11-24 10:37:35 <ncopa> fixed already
2021-11-24 10:39:24 <Misthios> postgres updates notes have a broken mr link
2021-11-24 10:39:54 <Misthios> |mr at the end of the url
2021-11-24 10:40:44 <ikke> Fixed
2021-11-24 10:42:03 <ncopa> i htink we should rename the wiki page. remove "draft"
2021-11-24 10:42:41 <ncopa> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.15.0
2021-11-24 10:50:02 <ikke> 👍
2021-11-24 10:50:52 <ncopa> Ok i think we are golden? https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html
2021-11-24 10:52:07 <fcolista> "The MIPS64 port is discontinued. The architecture is EOL and no new releases will be made." shall we put the link on TSC# ?
2021-11-24 10:52:24 <fcolista> like was done for:
2021-11-24 10:52:26 <fcolista> "sudo will be moved to community in Alpine Linux 3.16. The suggested replacement is doas, which is available in main. See TSC#1"
2021-11-24 10:53:52 <ncopa> good idea
2021-11-24 10:56:45 <ncopa> TSC 27 added
2021-11-24 10:57:09 <fcolista> lgtm
2021-11-24 10:58:58 <ikke> ncopa: did you remove mips from edge on the releases.yaml?
2021-11-24 11:02:13 <fcolista> https://wwwdev.alpinelinux.org/releases/ what would be the End of support for Alpine 3.15 ? 
2021-11-24 11:02:33 <fcolista> (I'm asking for osinfodb)
2021-11-24 11:17:02 <ikke> 2023-11-01
2021-11-24 11:17:12 <fcolista> thx ikke jsut saw on the page.
2021-11-24 11:17:23 <fcolista> https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/379
2021-11-24 11:17:37 <fcolista> <lunch>
2021-11-24 11:18:18 <ikke> fcolista: still mentions 3.14: https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/379/diffs#7961d50282899a5c6d7575ed72bbd0afcdaa00ff_0_8
2021-11-24 11:33:22 <clandmeter> ncopa: i wonder if we could change the commit list to a thank you list
2021-11-24 11:34:26 <clandmeter> doesnt have to be this time, but it sounds a bit more thankful and doesnt show off the commit count.
2021-11-24 11:38:40 <ncopa> I added links to upstream release notes: https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html
2021-11-24 11:38:50 <ncopa> clandmeter: sounds like a good idea to me
2021-11-24 11:40:15 <ncopa> clandmeter: any idea how to do so? remove the commit count?
2021-11-24 11:41:00 <ncopa> rename "Commit statistics" to "Commit contributions"?
2021-11-24 11:41:10 <mps> that is what I proposed two years ago :)
2021-11-24 11:41:38 <mps> but better late than never
2021-11-24 11:41:41 <ikke> ncopa: or just Contributors?
2021-11-24 11:41:41 <ncopa> something like this? https://tpaste.us/DXmR
2021-11-24 11:41:58 <ikke> Although, there are more contributors than people who make commits
2021-11-24 11:42:03 <ncopa> exactly
2021-11-24 11:45:02 <ikke> ncopa: fyi, my previous e-mail to distrowatch was bounved
2021-11-24 11:45:04 <ikke> bounced
2021-11-24 11:45:40 <ikke> <distro@distrowatch.org>: connect to distrowatch.org[82.103.129.71]:25:
2021-11-24 11:45:42 <ikke>     Connection refused
2021-11-24 11:47:22 <ncopa> i think we can drop sending email to distrowatch nowdays
2021-11-24 11:47:33 <ncopa> they will pick it up anyway
2021-11-24 11:47:54 <ncopa> and I don't think we care much if they don't
2021-11-24 11:48:38 <ikke> Seems like their info about is quite outdated
2021-11-24 11:49:06 <ncopa> yeah. i think we should ask them to update it
2021-11-24 11:49:07 <ikke> They don't have 3.14.
2021-11-24 11:49:15 <ikke> miss at least armv7 as arch
2021-11-24 11:49:27 <ncopa> but i think its not a high prio
2021-11-24 11:49:32 <ikke> nope
2021-11-24 11:54:25 <ikke> ncopa: fyi, I have a tool that should be able to purge fastly once latest-stable is switched
2021-11-24 11:55:26 <ncopa> yes. feel free to use it when the latest-stable points to v3.15
2021-11-24 12:05:31 <clandmeter> ncopa: maybe something like: We would like to thank to following people who have send patches to aports:
2021-11-24 12:06:48 <ncopa> We have something like that under Credits
2021-11-24 12:07:29 <clandmeter> right ok.
2021-11-24 12:12:55 <ncopa> I also did the aports commit contributions a subheading under credits
2021-11-24 12:20:03 <ncopa> https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html#credits
2021-11-24 12:20:57 <clandmeter> another option is to just list the number of people who have contributed, and we can skip the listing. we would like to thank the more than X people who have make this release possible... 
2021-11-24 12:21:03 <clandmeter> just thinking out load
2021-11-24 12:21:07 <clandmeter> i can stop :)
2021-11-24 12:21:43 <clandmeter> just ideas for next time.
2021-11-24 12:30:43 <ikke> clandmeter: fyi, the import is running in a tmux session
2021-11-24 12:37:29 <clandmeter> 👍
2021-11-24 12:38:34 <clandmeter> ikke: will it drop edge for mips?
2021-11-24 12:40:36 <clandmeter> ncopa: maybe also an idea is to mention the supported architectures on releases page, so we can kind of exclude mips by not mentioning it.
2021-11-24 12:41:43 <ikke> clandmeter: I have not removed mips yet
2021-11-24 12:43:12 <clandmeter> ikke: removing mips we need to be careful the mips building does not sync it back
2021-11-24 12:43:37 <ikke> yeah
2021-11-24 12:43:47 <ikke> But we do not have access atm to change anything
2021-11-24 12:43:51 <clandmeter> but i guess you knew that already :)
2021-11-24 12:43:52 <ikke> so I suppose we need to remove the key?
2021-11-24 12:43:59 <clandmeter> yeah
2021-11-24 12:44:02 <clandmeter> i can take a look
2021-11-24 12:44:47 <clandmeter> done
2021-11-24 12:44:50 <clandmeter> i commented it
2021-11-24 13:03:47 <fcolista> ikke, that was a bad commit :-/ thx for noticing
2021-11-24 13:04:09 <ikke> pipeline failed as well because of it :-)
2021-11-24 13:05:15 <fcolista> yeah..i did the correct alpinelinux3.15 with the correct data, but that was for 3.15_rc3...so i reset it and forgot that xml that was checkedout
2021-11-24 13:32:30 <ncopa> I added back multi-versions of psql: https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html#significat_changes
2021-11-24 13:36:20 <ikke> ok
2021-11-24 13:38:08 <valerius> awesome to see the new release out, have upgraded my non-edge Alpine machines already with great success
2021-11-24 13:39:15 <nmeum> whoo 3.15 is out? \o/
2021-11-24 13:39:20 <ikke> nmeum: yes
2021-11-24 13:39:29 <ikke> ncopa is still working on finalizing
2021-11-24 13:39:48 <ikke> (ie, release notes)
2021-11-24 13:39:54 <nmeum> but we have the 3.15- branch already, so I can merge all the stuff I have been waiting with :D
2021-11-24 13:40:15 <ikke> :D
2021-11-24 13:43:57 <nmeum> clandmeter: I would also prefer listing the number of people who have contributed without the commit statistics. I don't think amount of commits really means a lot, maybe for the next release :D
2021-11-24 13:45:22 <bandali> i mean it's a nice way of giving shout outs to contributors by name
2021-11-24 13:45:52 <nmeum> I think it's nice to do a little shout out, I just don't think we need to attach a number with each name
2021-11-24 13:46:40 <mps> nmeum: agree, and I proposed this with few previous releases (sorry to repeat myself). "Cartago delenda est" - Cato :)
2021-11-24 13:49:18 <ncopa> so I just remove the numbers?
2021-11-24 13:50:50 <nmeum> I don't know, I am just thinking out loud
2021-11-24 13:51:40 <nmeum> in my personal opinion just sorting alphabetically would also work just fine just my two cents on this
2021-11-24 13:52:11 <nmeum> but I wouldn't mind if we just keep it as is and discuss this again for 3.16
2021-11-24 13:53:25 <ikke> It's already sorted alphabetically
2021-11-24 13:53:46 <nmeum> yes, without the commit number I mean
2021-11-24 13:57:07 <clandmeter> burn the numbers
2021-11-24 13:57:45 <ncopa> done https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html#credits
2021-11-24 13:58:48 <ncopa> I also s/contributions/contributors/
2021-11-24 14:13:03 <ncopa> got some feedback from jiruka. moved postgresql to upgrade notes. https://wwwdev.alpinelinux.org/posts/Alpine-3.15.0-released.html
2021-11-24 14:13:13 <ncopa> i'm gonna merge it now and send it
2021-11-24 14:14:47 <minimal> ncopa: mkinitfs is still using "full" modprobe for initramfs? I thought with the switch back to gzipped kernel modules this was no longer required and Busybox modprobe would be again used instead
2021-11-24 14:20:30 <ncopa> we still have kmod yes, with gz modules
2021-11-24 14:20:35 <ncopa> I guess we can revert it now
2021-11-24 14:23:07 <MY-R> imho I think that link "https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.15.0" should be on the top of "released.html" site, just right above "Highlights"
2021-11-24 14:24:04 <ncopa> its already published
2021-11-24 14:24:44 <MY-R> for many releases I didnt even know there is more detailed "release notes" page because link was hiden under "Wiki" word which not telling me much about and somewhere in middle of site full of text :\
2021-11-24 14:33:44 <Hello71> ncopa: do you have an idea for "clean" way to enable -fno-plt by default in abuild for x86 and x86_64 only, but keep it configurable?
2021-11-24 14:37:45 <ncopa> use /etc/abuild.conf?
2021-11-24 14:45:29 <tomalok> heh, i made the contiributor list twice, thanks to my name change ;)
2021-11-24 14:53:41 <vkrishn_> kernel 5.15 is a stable or lts release?
2021-11-24 14:54:16 <ikke> vkrishn: lts
2021-11-24 14:54:35 <vkrishn> ok, thanks
2021-11-24 14:57:13 <vkrishn> ok celebrate got marked, \o/
2021-11-24 15:05:05 <ncopa> oh no.... there is a mess with python wheels
2021-11-24 15:07:19 <Hello71> ncopa: i mean by default. do you think it is a good idea to have different abuild.conf for different archs?
2021-11-24 15:07:39 <Hello71> yes, time to un-celebrate :)
2021-11-24 15:08:22 <ikke> :(
2021-11-24 15:11:06 <donoban> :\
2021-11-24 15:19:20 <vkrishn> tcl is not used these days? 
2021-11-24 15:19:32 <vkrishn> noticed tcllib in unmaintained
2021-11-24 15:22:54 <Hello71> testing/tcl-lib
2021-11-24 15:23:24 <Hello71> dunno why it was renamed
2021-11-24 15:24:38 <Hello71> "# no tests" is also a lie
2021-11-24 15:39:58 <Nulo> Sent a bunch of MRs for a Ruby security upgrade, who do I ping?
2021-11-24 15:40:41 <ikke> The maintainers of those packages initially
2021-11-24 15:41:03 <Nulo> I believe they were automatically assigned the MR
2021-11-24 15:57:57 <ikke> Nulo: You can ping @team/security as well
2021-11-24 15:58:07 <Nulo> ikke, already done, thanks
2021-11-24 16:00:08 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/1
2021-11-24 16:04:44 <fcolista> ncopa, clandmeter, ikke : would it be possible to have eol date in latest-releases.yaml too ?
2021-11-24 16:16:07 <ikke> fcolista: which one?
2021-11-24 16:16:22 <ikke> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/alpine-releases.conf.yam contains eol dates
2021-11-24 16:17:36 <fcolista> ok, but this is not reachable "from outside" right? I'd like to have the alpinelinux$ver.xml.in generated automatically
2021-11-24 16:17:41 <fcolista> for osinfodb
2021-11-24 16:18:30 <ikke> yes
2021-11-24 16:18:32 <ikke> it is
2021-11-24 16:18:57 <fcolista> you are always providing me solutions...thanks!
2021-11-24 16:19:12 <ikke> https://alpinelinux.org/releases.json
2021-11-24 16:20:01 <ikke> (that's the official source of truth for releases)
2021-11-24 16:22:53 <nmeum> 🥳
2021-11-24 16:34:21 <vkrishn> what's with truth<->lie, something I missed, not reading logs for a while
2021-11-24 16:34:34 <vkrishn> which month/year?
2021-11-24 16:38:10 <ikke> What are you referring to?
2021-11-24 16:38:38 <vkrishn> "source of truth" ^
2021-11-24 16:39:23 <vkrishn> "# no tests" is also a lie" ^
2021-11-24 16:39:47 <ikke> those are totally unrelated
2021-11-24 16:40:02 <vkrishn> ok nevermind, just thought something went in past
2021-11-24 16:44:55 <Hello71> Ariadne: why 74ab74e9739 "we skip tests intentionally"?
2021-11-24 16:45:48 <ikke> 74ab74e97390b5624baca6536db9bc159388f2e7
2021-11-24 17:01:26 <indy> ikke, thanks for git config hint :)
2021-11-24 17:01:41 <ikke> indy: No idea which one anymore :P
2021-11-24 17:02:12 <indy> hi all: does raspberry pi image supports zero 2 (rpi3 based one)
2021-11-24 17:02:57 <indy> is there any work on preempt_rt kernel?
2021-11-24 17:03:24 <Hello71> probably, and i doubt it, but you can compile your own easily enough
2021-11-24 17:20:33 <ikke> ncopa: fyi, latest-stable has been purged
2021-11-24 17:24:46 <ncopa> ikke: awesome!
2021-11-24 17:25:42 <ikke> pkgs.a.o is still going
2021-11-24 17:26:04 <ncopa> heh
2021-11-24 17:26:39 <ncopa> i had a call with henry about cleaning up the python3 wheel mess
2021-11-24 17:26:55 <ikke> ah ok, and?
2021-11-24 17:26:58 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13227
2021-11-24 17:27:42 <ncopa> he posted a summary here: https://bugs.python.org/issue43112#msg406939
2021-11-24 17:28:25 <ncopa> i will have to add a patch on top of the current SOABI patch in our 3.15 and 3.14 that makes python also look for -gnu in addition to -musl
2021-11-24 17:29:00 <ncopa> the whole thing is just to big to fit in my head :) 
2021-11-24 17:31:12 <ikke> Ok, but at least there is a way forward
2021-11-24 17:31:22 <ikke> without having to rebuild everything
2021-11-24 17:49:40 <ikke> ncopa: should we send an e-mail to alpine-devel?
2021-11-24 18:03:43 <ncopa> about 3.15 release?
2021-11-24 18:03:59 <ncopa> i guess the announce mailing list is enough
2021-11-24 18:04:47 <Hello71> about python i think
2021-11-24 18:06:36 <ikke> ncopa: oh, right
2021-11-24 18:06:47 <ikke> I missed that one
2021-11-24 19:16:47 <Nulo> I think I will make myself the telegram-desktop mantainer (the former has already suggested to me to do it.) How do I notify myself of tdesktop releases?
2021-11-24 19:17:36 <ikke> If it's on github you can subscribe to releases only
2021-11-24 19:18:36 <bandali> perhaps https://github.com/telegramdesktop/tdesktop/releases.atom
2021-11-24 19:19:19 <ikke> Watch > custom > releases
2021-11-24 19:19:25 <ikke> Then you get notifications from github
2021-11-24 19:19:38 <ikke> Maybe also security alerts
2021-11-24 19:22:52 <Nulo> Ah, that works
2021-11-24 19:23:14 <Nulo> bandali: yes, I considered Atom/RSS but I don't usually use it so I would have to set it up and remember to check it
2021-11-24 19:27:12 <mps> https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.15
2021-11-24 19:27:20 <bandali>  Nulo, right :) yeah i thought i'd give a no-account-needing answer in case you happen to not use github like myself
2021-11-24 19:32:16 <minimal> mps: "not having been much of a focus for the distro given its container focus"
2021-11-24 19:32:56 <minimal> "Further boosting its bare metal potential"
2021-11-24 19:33:09 <ikke> Very funny :)
2021-11-24 19:34:06 <minimal> yeah we need to stop our container focus and think about physical machines and VMs... lol
2021-11-24 19:34:34 <mps> I agree
2021-11-24 19:35:13 <mps> declare alpine as 'universal OS' and remove small, simple and secure :)
2021-11-24 19:35:20 <minimal> but then we'd think to think of an init system to use as we probably haven't being using  one for containers...
2021-11-24 19:35:46 <minimal> s/think to/need to/
2021-11-24 19:35:46 <alpine-meetbot> minimal meant to say: but then we'd need to think of an init system to use as we probably haven't being using  one for containers...
2021-11-24 19:35:51 <PJ[m]> > I'm familiar with Alpine in container scenarios, but is there any mileage to using it as a day-to-day desktop distro?
2021-11-24 19:35:53 <PJ[m]> > Not really. It's not designed for that. It's designed to be as lightweight as possible.
2021-11-24 19:36:24 <PJ[m]> courtesy of orange site: https://news.ycombinator.com/item?id=29330585
2021-11-24 19:36:29 <mps> init system exist in alpine for years and its name is runit but because of ideological reasons it is not default
2021-11-24 19:40:01 <vkrishn> just a silly question, why all news in https://alpinelinux.org/atom.xml published at UTC only? :D
2021-11-24 19:43:43 <vkrishn> 'universal OS' ^, considering that now community/ folder is 24gb~
2021-11-24 19:44:19 <vkrishn> but I would not second it ;)
2021-11-24 19:44:59 <vkrishn> small, simple and secure -- sounds sweet and solid
2021-11-24 19:46:28 <alandiwix> ^s6
2021-11-24 19:47:16 <nero> yeah of course we can upgrade alpine into a universal purpose distro
2021-11-24 19:47:35 <nero> when its fully featured, some other people will consider it to bloated and start another, minimalistic distro
2021-11-24 19:47:39 <nero> and the cycle repeats
2021-11-24 19:48:23 <minimal> nero: my distro is Alpine :-)
2021-11-24 19:54:39 <mps> nero: count on me :)
2021-11-24 19:55:09 <nero> as long as alpine default install is not writing random AT commands into my atmel programmers
2021-11-24 19:55:15 <nero> (like ubuntu did with modem manager)
2021-11-24 19:55:19 <nero> ... i can settle down with it
2021-11-24 19:56:12 <nero> some other thing... is it known how firefox connects to a already running instance?
2021-11-24 19:56:26 <Hello71> no, it is a mystery
2021-11-24 19:56:42 <Hello71> lost in the sands of C++
2021-11-24 19:57:26 <mps> Executing: /usr/bin/firefox --new-tab  'https:.....
2021-11-24 19:58:23 <mps> ~/.urlview
2021-11-24 19:58:25 <nero> mps: im trying to strace that, but the log seems big
2021-11-24 19:58:45 <mps> 'COMMAND /usr/bin/firefox --new-tab  %s'
2021-11-24 19:59:18 <mps> runs without any problem from mutt long time
2021-11-24 19:59:52 <nero> this used to work for me until the update today
2021-11-24 19:59:56 <bgs> nero: wayland or X?
2021-11-24 20:00:00 <nero> Xorg
2021-11-24 20:00:17 <mps> nero: still works here
2021-11-24 20:00:17 <bgs> no idea then
2021-11-24 20:17:35 <Nulo> bandali: I wish I wasn't forced to use GitHub :(
2021-11-24 20:19:58 <mps> Nulo: I fully understand, I stubbornly don't create account there
2021-11-24 20:25:12 <valerius> Microsoft Github
2021-11-24 20:25:40 <valerius> it's not so bad, it does make collaboration easier
2021-11-24 20:25:52 <valerius> wouldn't put all my eggs in that basket though
2021-11-24 20:31:23 <mps> valerius: I wouldn't put one of my eggs in this basket ;)
2021-11-24 20:32:01 <valerius> I use it for issuing PRs to other people's projects
2021-11-24 20:32:43 <mps> 
ACTION is someone who will not sold his soul for anything

2021-11-24 20:33:14 <nero> its a personal preference and imho not worth discussing, people will pick their choice either way
2021-11-24 20:33:20 <mps> sold or sell?
2021-11-24 20:33:26 <valerius> sell
2021-11-24 20:34:00 <orbea> sold is paste tense
2021-11-24 20:34:07 <mps> nero: yes, personal preference will someone sell or not sell soul
2021-11-24 20:34:34 <mps> nero: I assume you read 'Faust'
2021-11-24 20:34:35 <orbea> i very much want to agree with mps and never use github, but then I would have not been able to fix so many bugs...
2021-11-24 20:35:03 <orbea> i never put my own stuff there though
2021-11-24 20:35:09 <nero> mps: had to
2021-11-24 20:35:21 <vkrishn> 'sell thy soul' would would better
2021-11-24 20:35:23 <mps> nice :)
2021-11-24 20:35:57 <vkrishn> would sound better
2021-11-24 20:36:47 <nero> i think #alpine-offtopic would be more suitable to vent about corporations
2021-11-24 20:36:52 <PJ[m]> there are worse companies than the one owning GitHub
2021-11-24 20:49:55 <bandali> Nulo, yeah :/ it's a bit unavoidable isn't it?  i personally don't host/develop any of my projects there, and don't let my browser run their proprietary js either.  at least their site isn't half-bad with js disabled.  but yeah i'll refrain from further spamming this channel about it, and will /join #alpine-offtopic
2021-11-24 22:06:33 <maribu> dalias: Regarding the v4l-utils bug fix: The mailing list seems to be indeed dead. The git repo still has recent activity. I just now forwarded the mail to the most recent contributor there.
2021-11-24 23:15:51 <Nulo> Any reason the 3.15 and master MRs haven't been merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27732 (3.12-3.14 have)
2021-11-24 23:16:12 <Nulo> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27728
2021-11-25 00:27:43 <maxice8> Jirutka will handle those
2021-11-25 02:44:44 <Ariadne> nmeum: gcc-go is broken in gcc 11 (with musl at least), missing size_t type
2021-11-25 02:44:51 <dalias> :/
2021-11-25 02:45:26 <Ariadne> i've disabled go for now, but its something to figure out i guess
2021-11-25 02:47:03 <ericonr> Does anyone maintain gcc-go? :/ 
2021-11-25 02:50:14 <Ariadne> yes, Google does
2021-11-25 06:59:15 <nmeum> Ariadne: could you share the error message?
2021-11-25 06:59:30 <Ariadne> nmeum: sysinfo.go: unknown type _size_t
2021-11-25 06:59:36 <nmeum> upstream isn't really paying attention to musl support for the gcc-go frontend I believe
2021-11-25 06:59:49 <nmeum> I put it on my to-do list, hope I get around to it soon
2021-11-25 06:59:59 <Ariadne> for now, i disabled gcc-go
2021-11-25 07:00:03 <nmeum> yeah, I saw
2021-11-25 08:05:56 <ncopa> good morning
2021-11-25 08:05:59 <ncopa> _size_t 
2021-11-25 08:10:48 <ktprograms> In picom next (dev branch), stale_props_capacity is hardcoded to uint64_t (https://github.com/yshui/picom/blob/next/src/win.h#L142), but in https://github.com/yshui/picom/blob/1c7a4ff5a3cd5f3e25abcac0196896eea5939dce/src/win.c#L2644 new_capacity is used as size_t. This is ok on 64bits where size_t == uint64_t, but on 32bits it causes -Wconversion. So would the solution be to make stale_props_capacity to be size_t?
2021-11-25 08:12:05 <ktprograms> (for future reference the win.h permalink is https://github.com/yshui/picom/blob/1c7a4ff5a3cd5f3e25abcac0196896eea5939dce/src/win.h#L142)
2021-11-25 08:23:30 <psykose> they should just both be the same typer
2021-11-25 08:23:33 <psykose> type*
2021-11-25 08:24:22 <ktprograms> psykose: what type should they be? Making stale_props_capacity size_t seems to work
2021-11-25 08:25:39 <psykose> either way works
2021-11-25 08:25:50 <ktprograms> psykose: What would the other way have been?
2021-11-25 08:25:59 <psykose> both uint64_t
2021-11-25 08:26:02 <psykose> size_t makes more sense
2021-11-25 08:26:25 <ktprograms> psykose: Yes, size_t makes more sense since it is used with sizeof
2021-11-25 08:26:50 <psykose> sizeof works with any type, not sure how that is related
2021-11-25 08:27:16 <ktprograms> As in the size_t variable was being multiplied by the output of sizeof
2021-11-25 08:30:27 <psykose> that would go the same even if it wasn't size_t
2021-11-25 08:31:37 <ktprograms> psykose: What does that mean?
2021-11-25 08:32:48 <psykose> as in it doesn't matter if it's size_t or uint64_t or int16_t, the place where sizeof is used won't change, why would it
2021-11-25 08:33:00 <caskd> you don't have to cast between the types with size_t
2021-11-25 08:33:36 <caskd> as sizeof() gives the same type
2021-11-25 08:33:47 <caskd> that's why it makes more sense
2021-11-25 08:34:00 <caskd> even though it works with any type as long as it's casted for comparasion
2021-11-25 08:34:04 <psykose> ah, that's what you mean
2021-11-25 08:40:07 <Ariadne> ktprograms: if size_t is used, then it should be used consistently, and %zu should be used with printf
2021-11-25 08:42:50 <ktprograms> Ariadne: That makes sense. I don't think stale_props_capacity is being printf'd anywhere.
2021-11-25 08:43:16 <Ariadne> sure, i am just clarifying how size_t is supposed to be used
2021-11-25 08:43:31 <ktprograms> Ariadne: Understood
2021-11-25 08:44:14 <Ariadne> ncopa: C types are prefixed with _, but the _size_t one does not get defined i guess
2021-11-25 08:49:32 <ktprograms> What next step should I take regrading GHC on Alpine arm64? Should I send my instructions gist to upstream so they can make a bindist?
2021-11-25 08:50:07 <Ariadne> i think we can adapt the APKBUILD to allow cross-compilation
2021-11-25 08:51:52 <ktprograms> Ariadne: Right now the way I'm doing it is cross compiling from Debian arm64. So I think this goes back to the discussion on the mailing list about self hosting compilers.
2021-11-25 08:52:14 <Ariadne> why cross it from debian, and not alpine x86_64?
2021-11-25 08:53:00 <ktprograms> Because I don't have fast x86_64 hardware.
2021-11-25 08:54:50 <indy> https://www.cnx-software.com/2021/11/24/sipeed-licheerv-a-low-cost-allwinner-d1-linux-risc-v-board/
2021-11-25 08:55:41 <indy> hi all, any progress on riscv port? ^^
2021-11-25 09:03:28 <caskd> sifive boards should be working more or less from what i can tell
2021-11-25 09:03:45 <caskd> but there's still work to be done
2021-11-25 10:05:48 <clandmeter> indy: which progress are you looking for?
2021-11-25 10:14:39 <indy> alpine docker image :)
2021-11-25 10:15:55 <indy> is there any other registry which contains unofficial docker images?
2021-11-25 10:22:41 <clandmeter> indy: i think we have docker images on hub
2021-11-25 10:22:43 <clandmeter> for edge
2021-11-25 10:22:50 <clandmeter> we are not doing stable releases yet
2021-11-25 10:25:07 <ncopa> reminds me. i need to tag a new edge release as well
2021-11-25 10:30:03 <maribu> dalias: the v4l-utils bug should be fixed in the upstream git repo (that fix is different to the patch, but should fix the bug)
2021-11-25 11:05:10 <ktprograms> Got my picom 32bit segfault fix merged! (into the next branch so I'll be keeping the patch in aports until the next release)
2021-11-25 11:07:47 <psykose> grats
2021-11-25 11:10:47 <ktprograms> psykose: Thanks
2021-11-25 11:10:53 <psykose> :)
2021-11-25 11:15:15 <Ariadne> hmm
2021-11-25 11:15:23 <Ariadne> that python LTO thing is annoying
2021-11-25 11:15:49 <Ariadne> i guess python3 needs rebuild?
2021-11-25 11:16:24 <ncopa> i rebuilt python yesterday?
2021-11-25 11:16:45 <ncopa> what python LTO thing?
2021-11-25 11:25:58 <Ariadne> apparently it needs rebuild again
2021-11-25 11:26:02 <Ariadne> for gcc 11 LTO
2021-11-25 11:26:10 <Ariadne> which is apparently not compatible with gcc 10 LTO
2021-11-25 11:26:32 <Ariadne> lto1: fatal error: bytecode stream in file '/usr/lib/python3.9/config-3.9-i386-linux-musl/libpython3.9.a' generated with LTO version 9.4 instead of the expected 11.2
2021-11-25 11:45:19 <psykose> not the first time i've seen this, having used lto for most things on gentoo before
2021-11-25 11:45:44 <psykose> definitely have to rebuild anything that used lto, which is probably not many things at all thankfully
2021-11-25 11:50:14 <ncopa> oh , ok
2021-11-25 11:51:14 <ikke> I guess !27605 can be merged now as well, correct?
2021-11-25 11:51:28 <ncopa> ok with me
2021-11-25 12:27:39 <Hello71> psykose: not true, only those which install static libraries
2021-11-25 12:52:58 <dalias> maribu, great
2021-11-25 12:54:17 <dalias> *sigh* why is python using lto in a .a file?
2021-11-25 12:54:32 <dalias> can that just be turned off?
2021-11-25 12:56:33 <Hello71> ncopa: why do alpine isos come with System.map?
2021-11-25 12:56:48 <Hello71> dalias: that's how gcc lto works?
2021-11-25 12:57:21 <Hello71> you can turn on fat objects, but then 1. they're fat and 2. it's not lto anymore
2021-11-25 12:58:15 <ncopa> i think there might be an option to disable LTO in python, but it comes with a performance penalty
2021-11-25 12:58:46 <ncopa> Hello71: i dont remember
2021-11-25 12:59:56 <dalias> i would say it's not valid to ship a .a library that's LTO-only
2021-11-25 13:00:16 <dalias> LTO for a particular gcc version is *not* the api/abi boundary expected for a library package
2021-11-25 13:00:31 <dalias> you either turn off LTO for the shipped one or you make it fat
2021-11-25 13:00:55 <dalias> whether python itself as built with LTO is a package-internal matter but the packaged .a files should not depend on it
2021-11-25 13:07:43 <ktprograms> Hi, Nextcloud expects its cron.php to be run every 5 minutes, but currently it's being run every 15 minutes (in /etc/periodic/15min). Do we just want to (a) leave it as that, (b) add a custom crontab entry, or (c) patch the nextcloud code to increase the time before warning?
2021-11-25 13:18:58 <ncopa> ktprograms: i have no good suggestions. what do you think ktprograms?
2021-11-25 13:22:31 <mercenary> (d) create an /etc/periodic/5min
2021-11-25 13:23:18 <Hello71> ncopa: i think it may be time to stop installing System.map by default. i think arch linux has put it in linux-headers for at least 10 years. it is basically useless if KASLR is enabled, doesn't contain dynamically loaded modules, and is semi-redundant with CONFIG_KALLSYMS
2021-11-25 13:24:08 <ikke> (e) add support for cron.d
2021-11-25 13:25:41 <ktprograms> ikke: What is cron.d?
2021-11-25 13:26:07 <ikke> A drop-in directory where you can place crontabs
2021-11-25 13:27:23 <ktprograms> Currently what I'm doing is I added a /etc/crontabs/nextcloud (nextcloud is the user for nextcloud) that runs the nextcloud.cron script from aports (but I moved it to /usr/share/webapps/nextcloud) every 5 minutes
2021-11-25 13:27:39 <ktprograms> ikke: Isn't that /etc/crontabs?
2021-11-25 13:28:45 <mercenary> no. there the filename indicates the user. cron.d has an extra user field in the crontab entries
2021-11-25 13:28:48 <ikke> afaik that dir is meant just for user corntabs
2021-11-25 13:28:52 <ikke> crontabs*
2021-11-25 13:28:59 <ikke> mercenary: exactly
2021-11-25 13:29:00 <mercenary> cron.d would be nice
2021-11-25 13:29:36 <ktprograms> I see. How is that implemented, though?
2021-11-25 13:32:53 <mercenary> however cron wants to do it. Modern way probably has an inotify on it
2021-11-25 13:33:25 <ikke> sadly it would probably not be supported by bb cron
2021-11-25 13:34:47 <ktprograms> mercenary: ikke: I see. So right now the options are either /etc/periodic/5min, /etc/crontabs/nextcloud with custom 5 minute entry, or patching nextcloud code
2021-11-25 13:35:09 <ktprograms> Actually, what is so important that needs to be run every 5 minutes?
2021-11-25 13:37:52 <Hello71> checking for updates
2021-11-25 13:38:21 <ikke> Hello71: :D
2021-11-25 13:39:31 <ktprograms> Hello71: I'm guessing that's a joke?
2021-11-25 13:39:36 <Hello71> mostly
2021-11-25 13:57:38 <dalias> 
ACTION mumbles something about automatically running things via crontab just because a package is installed...

2021-11-25 14:10:56 <mps> modern time
2021-11-25 14:21:31 <ktprograms> Well it looks like it isn't critical for cron.php to be run every 5 minutes (https://duckduckgo.com/?q=nextcloud+cron+15+minutes&t=osx&ia=web), so maybe we can just add some info to the wiki about the fact that cron jobs run every 15 minutes instead of 5.
2021-11-25 14:27:53 <nmeum> there is a better solution https://tpaste.us/5n0N
2021-11-25 14:27:53 <nmeum> Ariadne: I have a fix for the gcc-go problem. The problem is: The pre-proccessed libgo/sysinfo.c file defines size_t twice <https://tpaste.us/YE7P> this confuses -fdump-go-spec and causes _size_t not to be defined for go at all. this can be fixed by causing the size_t definition in GCC's stddef.h to take precedence over the musl one by defining musl type check macro there. not sure if 
2021-11-25 14:34:29 <psykose> ktprograms: what do these cron jobs even trigger? the .php script just fetches 'jobs' from the server and runs them, and all i can find online is that it runs 'maintenance' on the database or trashing files
2021-11-25 14:34:42 <psykose> in which case it could run every 24 hours and i don't think it would make much difference?
2021-11-25 14:36:04 <psykose> lines 115-118 of it makes it look like quite a strange architecture for whatever this is doing
2021-11-25 16:26:43 <piraty> would make sense if zlib-static depends on zlib-dev
2021-11-25 18:44:13 <ikke> Anyone got an idea why I would get this error message:
2021-11-25 18:44:16 <ikke> checkpath: /run/zabbix/: could not open zabbix: No such file or directory
2021-11-25 18:44:29 <ikke> heckpath --directory --owner zabbix:zabbix /run/zabbix/
2021-11-25 18:44:37 <ikke> s/heckpath/checkpath
2021-11-25 18:44:37 <alpine-meetbot> ikke meant to say: checkpath --directory --owner zabbix:zabbix /run/zabbix/
2021-11-25 18:44:54 <ikke> oh
2021-11-25 18:44:57 <ikke> the / at the end :/
2021-11-25 19:24:20 <yyp> Why could a patch from lists.alpinelinux.org not be forwarded to gitlab?
2021-11-26 00:34:58 <ktprograms> psykose: I had to go, but apparently Nextcloud apps can register jobs with cron.php that need to run, and some of them might depend on a semi-frequent interval (such as 15 minutes, not 24 hours). I do agree that it is a bit strange allowing 3 concurrent jobs, and I do wonder how taxing it would be on (for example) a RPi.
2021-11-26 00:54:36 <ktprograms> Any idea why the config files for MariaDB (/etc/my.cnf and /etc/my.cnf.d/mariadb-server.cnf) are in heredocs in the APKBUILD instead of being additional files?
2021-11-26 02:07:17 <ktprograms> MariaDB currently uses /var/tmp as tmpdir, but the mysql user does not have permission to write there, so I set tmpdir to /var/tmp/mysqld in the cmake configure, but now the mf_iocache test fails because the /var/tmp/mysqld folder doesn't exist and can't be created (in the rootbld)
2021-11-26 03:31:08 <dalias> why would mysql user not have permission to write there ?
2021-11-26 03:31:32 <dalias> shouldn't it be 1777?
2021-11-26 03:39:10 <ktprograms> dalias: /var/tmp is 755 and root:root for me
2021-11-26 03:43:31 <dalias> yeah, odd -- i thought it was supposed to be 1777...
2021-11-26 03:45:07 <ktprograms> dalias: Is it like that for you too?
2021-11-26 03:45:16 <dalias> FHS does not mention the mode as far as i can tell but it decribes it as a temp dir with no mention of it beint g root-only
2021-11-26 03:45:20 <dalias> on alpine its like that
2021-11-26 03:45:40 <dalias> on debian:
2021-11-26 03:45:40 <dalias> drwxrwxrwt 2 root root 4096 Nov 25 06:25 /var/tmp/
2021-11-26 03:45:51 <ktprograms> There is a /var/tmp/nextcloud directory installed by nextcloud so it makes sense for mariadb to do the same, right?
2021-11-26 03:46:23 <ktprograms> The only problem is the test can't create a new directory in /var/tmp because of the ro filesystem used in abuild rootbld
2021-11-26 03:46:27 <dalias> so i think alpine is maybe wrong-ish here...?
2021-11-26 03:46:41 <dalias> mount a tmpfs over it? :-p
2021-11-26 03:47:39 <dalias> https://serverfault.com/a/427290
2021-11-26 03:50:19 <ktprograms> dalias: Hmm interesting
2021-11-26 05:18:22 <lonjil> I'm getting AKMS failures on my newly upgraded edge system, due to a mismatch between gcc and some gcc plugins: https://paste.ee/d/ueJUs
2021-11-26 05:32:25 <ikke> Ariadne: ^
2021-11-26 05:32:43 <Ariadne> kernel needs rebuild
2021-11-26 05:32:51 <Ariadne> gcc 10 plugins wont work with gcc 11
2021-11-26 05:35:10 <Ariadne> 5.15.5 is out today
2021-11-26 05:35:29 <Ariadne> ncopa: do you want me to handle updating to kernel 5.15.5?
2021-11-26 05:54:39 <Ariadne> hmm, this seems like a pain in the ass :P
2021-11-26 05:55:18 <Ariadne> gcc 11 enables new features in kernel so the configs need to be refreshed
2021-11-26 06:03:03 <ktprograms> ikke: Ariadne: What do you think about the problem of /var/tmp not being world writable and mariadb therefore not working (the mysql user does not have to permission to write there)?
2021-11-26 06:03:27 <Ariadne> mariadb is working fine for me ?
2021-11-26 06:06:11 <ktprograms> Ariadne: How do you start it?
2021-11-26 06:06:19 <Ariadne> with openrc?
2021-11-26 06:13:51 <ktprograms> Ariadne: Until I made a /var/tmp/mysqld directory owned by the mysql user, starting mysqld with service mariadb start wouldn't start and manually starting with su -s /bin/sh mysql -c mysqld would give the error `Can't create/write to file '/var/tmp/ibXXXXXX' (Errcode: 13 "Permission denied")`
2021-11-26 06:15:10 <ktprograms> But starting it with su -s /bin/sh mysql -c "mysqld --tmpdir /var/tmp/mysqld/" does work
2021-11-26 06:28:59 <ktprograms> Why are the permissions/owners changed on some nextcloud directories when nextcloud-initscript is installed? Shouldn't it just be the same permissions without the initscript package?
2021-11-26 07:53:26 <ncopa> I can have a look at the kernels
2021-11-26 08:37:48 <ncopa> Ariadne: didnt we at some point offer to help python to set up a CI for musl?
2021-11-26 08:37:55 <Ariadne> yes
2021-11-26 08:40:40 <ncopa> did we ever deliver that?
2021-11-26 08:48:25 <utf8> alpine linux is the OS of the arien rockets
2021-11-26 08:58:34 <Ariadne> ncopa: no, i wasn't sure who was supposed to provide that
2021-11-26 09:04:08 <Ariadne> utf8: huh?
2021-11-26 09:10:46 <utf8> they use fedora at esa
2021-11-26 09:12:47 <Ariadne> well, alpine isn't fedora :p
2021-11-26 09:17:11 <utf8> fedora for workstations
2021-11-26 09:17:19 <utf8> alpine for rocket
2021-11-26 09:18:39 <mps> rtx2000 cpu with its forth ISA is for rockets
2021-11-26 09:19:25 <ktprograms> Ariadne: Did you see my response re mariadb /var/tmp permission denied?
2021-11-26 09:19:27 <mps> anything else is 'call' for troubles 
2021-11-26 09:20:12 <Ariadne> ktprograms: i did, but i have a bunch of other issues i am working on atm
2021-11-26 09:20:20 <ktprograms> Ariadne: Ok, np
2021-11-26 09:20:59 <ikke> ktprograms: Could you open an issue for it
2021-11-26 09:26:05 <utf8> kevin?
2021-11-26 09:26:31 <utf8> do you play cricket?
2021-11-26 09:27:22 <ikke> I don't
2021-11-26 09:32:03 <ktprograms> ikke: What are the permissions on your /var/tmp?
2021-11-26 09:32:29 <ikke> 1777
2021-11-26 09:32:41 <ikke> (in an lxc container)
2021-11-26 09:33:27 <mps> ktprograms: also my is 1777
2021-11-26 09:33:38 <mps> on metal
2021-11-26 09:34:32 <ktprograms> Strange. On one of my alpine systems that I didn't create a non-root interactive user, it's 1755
2021-11-26 09:48:03 <ktprograms> ikke: I think I've figured it out: when installing the nextcloud-initscript package, /var/tmp gets chmod'd to 1755
2021-11-26 09:50:25 <ikke> I don't see it being done in the package
2021-11-26 09:51:04 <psykose> i checked earlier and i had 1777
2021-11-26 09:51:09 <psykose> i just installed that and it is not 1755
2021-11-26 09:51:15 <psykose> s/not/now
2021-11-26 09:51:15 <alpine-meetbot> psykose meant to say: i just installed that and it is now 1755
2021-11-26 09:52:00 <psykose> yep
2021-11-26 09:52:38 <ktprograms> That's very weird since I don't see anywhere in the APKBUILD that chmod's /var/tmp
2021-11-26 09:54:31 <psykose> it could be any of the nextcloud apkbuilds
2021-11-26 09:54:35 <psykose> but just the initscripts one
2021-11-26 09:54:50 <psykose> oh nvm, i'm silly
2021-11-26 09:55:01 <ktprograms> I tested that just installing the other nextcloud stuff doesn't chmod /var/tmp
2021-11-26 09:56:13 <psykose> if you check the .apk for it it contains a 755 /var/tmp
2021-11-26 09:56:37 <ktprograms> psykose: Funny, I was just going to say that
2021-11-26 09:56:41 <psykose> it is probably caused by install -m700 /var/tmp/nextcloud creating a default 755 dir
2021-11-26 09:57:21 <ktprograms> Yep, I can confirm that install by default creates a 755 dir
2021-11-26 09:57:47 <psykose> 	`install -m 1777 -d "$subpkgdir"/var/tmp` think you need this before it
2021-11-26 09:57:57 <ktprograms> psykose: Actually should apk overwrite permissions of higher up directories?
2021-11-26 09:58:12 <psykose> i don't think it should, in which case it could be a bug
2021-11-26 09:58:13 <psykose> i dunno
2021-11-26 09:58:52 <ktprograms> psykose: I don't know about if apk has a bug, but I think that install -m 1777 ... should work. thanks!
2021-11-26 09:59:02 <psykose> given that it is just a tar that gets extracted, i think it's whatever the tar behaviour is
2021-11-26 10:01:13 <ktprograms> psykose: Makes sense. But it doesn't look like there's any tar option to keep parent dir permission?
2021-11-26 10:01:19 <psykose> i think that is the wrong behaviour anyway? if someone wants to make their /var/tmp whatever perms, that would override them again
2021-11-26 10:01:46 <psykose> someone with more knowledge of tar/apk should decide on what is wrong here, it's out of my expertise for sure
2021-11-26 10:01:52 <psykose> but the behaviour seems very wrong as it is
2021-11-26 10:23:11 <ncopa> Ariadne: do you think we should tell them "sorry we cant provide musl CI" or should we find someone that can help us set it up? Looks like they are using github actions nowdays
2021-11-26 10:23:36 <ncopa> i think we should either keep what we promise or not promise at all
2021-11-26 10:46:01 <Ariadne> if they are using github actions then it is something i can assist with
2021-11-26 10:46:19 <Ariadne> the previous CI was buildbot
2021-11-26 10:46:30 <Ariadne> and that was where the logistics never got sorted
2021-11-26 10:51:55 <ncopa> looks like they do use github actions: https://github.com/python/cpython/tree/main/.github/workflows
2021-11-26 10:56:12 <ncopa> mps: I'm starting to think that splitting gvim and move it to community was not worth it
2021-11-26 10:58:20 <ncopa> oh you made me the maintainer of community/gvim.... Then I'll just revert it. I dont want maintain that mess
2021-11-26 10:58:35 <Ariadne> :D
2021-11-26 10:59:02 <Ariadne> meanwhile i’m over here wondering why anyone would use anything other than nano
2021-11-26 10:59:29 <ncopa> i'm a vim addict. I can't stand nano
2021-11-26 11:00:10 <ncopa> nano is *waaaay* to easy to exit :)
2021-11-26 11:00:53 <ktprograms> Is It expected behaviour that https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/nextcloud/APKBUILD#L180 would cause /var/tmp to become 755 (because install creates 755 intermediate dirs)? I would think that it should keep the permissions of parent directories when installing the apk
2021-11-26 11:02:06 <ncopa> ktprograms: I guess it is sort of expected, but not desired.
2021-11-26 11:03:40 <ncopa> I'm also thinking that it is a general bad idea to let the package manager create anything under /var/tmp/
2021-11-26 11:04:00 <ncopa> i mean a package include anything undev /var/tmp. We had similar issues with nginx
2021-11-26 11:04:28 <psykose> from what i've seen the post-install scripts make things under /var half the time
2021-11-26 11:04:29 <ncopa> does not nextcloud itself manage to create the irectory there? /var/tmp should be world writeable
2021-11-26 11:04:39 <ncopa> under /var is ok
2021-11-26 11:04:46 <psykose> could just move that part to a post-install
2021-11-26 11:04:54 <ncopa> under /var/tmp needs special care
2021-11-26 11:05:12 <ncopa> or maybe to the init.d script in this case
2021-11-26 11:05:38 <psykose> aye, checkpath also works
2021-11-26 11:08:56 <alandiwix> Ariadne: does nano have full utf-8 support?
2021-11-26 11:09:43 <Ariadne> to the extent that ncurses can support unicode (aka badly)
2021-11-26 11:20:21 <mps> ncopa: gvim depends on gtk and iirc we discussed some time ago moving from main all things which depends on gtk
2021-11-26 11:21:23 <mps> yes, it is mess, but if you remember we discussed move complete vim to community but ikke need it in main
2021-11-26 11:22:06 <mps> and it was mess also earlier
2021-11-26 11:22:23 <mps> I will fix this, but not today
2021-11-26 11:26:41 <mps> but I see that my ideas and works are usually rejected, so I think I should orphan all my pkgs, alpine will be better without me I presume
2021-11-26 11:28:36 <Ariadne> i disagree
2021-11-26 11:29:30 <ncopa> I also don't think alpine will be better without you
2021-11-26 11:29:58 <Ariadne> though i think main vs community is a not very useful distinction
2021-11-26 11:30:21 <mps> thanks both, but I feel that I'm not good in these new and changing things
2021-11-26 11:30:33 <Ariadne> in practice the only difference is how long security updates occur for
2021-11-26 11:31:23 <ncopa> in this case (vim) there was unintended consequences. I was still listed as maintainer for both main/vim and community/gvim and I think for my own sanity I'd like to keep them in same APKBUILD. vim has historically created very little extra long-term maintenence work
2021-11-26 11:32:04 <mps> ncopa: yes, and we discussed this before I split it if you remember
2021-11-26 11:32:25 <Ariadne> personally i would like community to go away
2021-11-26 11:32:48 <mps> keeping you as maintainer was because i didn't wanted to 'steal' package
2021-11-26 11:32:55 <ktprograms> ncopa: so the solution in this case would be to do like psykose said and run 'install -m 1777 -d "$subpkgdir"/var/tmp' ? Or do you suggest something else?
2021-11-26 11:33:25 <Ariadne> but… i think realistically we need to rethink release lifecycles anyway
2021-11-26 11:33:34 <ncopa> mps: I wrongly assumed that you would take maintenece for gvim. I also said that I wouldn't mind to *keep* it in main.
2021-11-26 11:33:38 <mps> Ariadne: +1
2021-11-26 11:33:41 <psykose> ktprograms:  you should create it in the init.d or in post-install
2021-11-26 11:33:50 <ncopa> that said. I don't mind to accept patches and changes to try things
2021-11-26 11:33:52 <Ariadne> the world has evolved, and alpine’s approach to releases should evolve too
2021-11-26 11:34:14 <ncopa> and i dont mind break things once in a while (but should be avoided in general)
2021-11-26 11:34:16 <psykose> ktprograms:  e.g. in init.d it goes in start_pre() like checkpath --directory --owner user:group --mode 0775 /var/tmp/nextcloud
2021-11-26 11:34:32 <Ariadne> in a way the plans i have for rust are intended to prove out a new strategy for release lifecycles
2021-11-26 11:34:37 <Ariadne> but we’ll see
2021-11-26 11:34:54 <ktprograms> psykose: Which would be better? (since there's already a nextcloud-initscript.post-install)
2021-11-26 11:34:59 <ncopa> but I also think we should not be afraid to revert things that turned out to not be as good as we originally thought, even if the intention was good
2021-11-26 11:35:07 <psykose> personally i prefer init.d, but it's up to you
2021-11-26 11:35:29 <mps> if 'we' want to keep gtk in main then reverting vim is good solution
2021-11-26 11:35:47 <psykose> postscripts are best for users/groups and migrations of things between versions
2021-11-26 11:36:07 <ncopa> ktprograms: I have looked too close at it, but my first impression is that doing it with checkpath form init.d would be the nicest
2021-11-26 11:36:07 <mps> um, wifi is unstable on apple m1 with alpine
2021-11-26 11:36:15 <Ariadne> i think instead of cutting a new branch every 6 months we should move to a set of update streams, which get closer and closer to edge
2021-11-26 11:36:37 <skarnet> and are about to break
2021-11-26 11:36:55 <Ariadne> nah
2021-11-26 11:37:14 <skarnet> (one step closer to the edge. Sorry.)
2021-11-26 11:37:23 <ncopa> mps: i think keeping vim in main is what I'd prefer
2021-11-26 11:37:38 <mps> ncopa: ok
2021-11-26 11:37:40 <Ariadne> the idea is that stable remains stable but it gets updated more often
2021-11-26 11:37:55 <Ariadne> and then you have canary which is something in between stable and edge
2021-11-26 11:38:18 <skarnet> that sounds good
2021-11-26 11:41:03 <Ariadne> bbl
2021-11-26 11:50:18 <ktprograms> psykose: I'm not sure how doing the checkpath in the init.d would work since it's just a symlink to the php-fpm8 init script
2021-11-26 11:50:42 <psykose> hmm
2021-11-26 11:51:41 <psykose> then you can only use post-install i guess
2021-11-26 11:53:42 <ktprograms> psykose: Ok, that's what I thought. So should I use mkdir and chmod or install?
2021-11-26 11:55:37 <psykose> former
2021-11-26 11:56:41 <ktprograms> psykose: Ok, thanks
2021-11-26 11:57:40 <ktprograms> psykose: mkdir -p or hard fail if /var/tmp doesn't exist (which should never happen)?
2021-11-26 11:59:01 <psykose> pretty sure either is fine
2021-11-26 12:22:32 <ktprograms> psykose: What group should own /var/tmp/nextcloud?
2021-11-26 12:22:39 <psykose> nextcloud
2021-11-26 12:22:44 <psykose> whatever user:group runs it
2021-11-26 12:23:15 <psykose> as it already is, -o nextcloud -m 700
2021-11-26 12:23:44 <ktprograms> psykose: /usr/share/webapps/nextcloud is nextcloud:www-data, so I guess the same for /var/tmp/nextcloud
2021-11-26 12:26:28 <psykose> it is already installed as nextcloud:root or something, i dunno
2021-11-26 12:26:32 <psykose> you're the boss
2021-11-26 12:26:53 <ktprograms> psykose: It currently is Nextcloud:root but I think it makes more sense to be nextcloud:www-data?
2021-11-26 12:27:20 <psykose> i don't know a thing about nextcloud or what happens
2021-11-26 12:27:38 <psykose> with -m 700 it doesn't matter what the group is so it's :root
2021-11-26 12:27:56 <ktprograms> psykose: I thought you said use mkdir and chmod?
2021-11-26 12:28:07 <psykose> to make the directory, yes
2021-11-26 12:28:18 <ktprograms> So there's no -m 700 right?
2021-11-26 12:28:20 <psykose> i am also saying that this entire time it has been 700 and nextcloud:root, and apparently works fine
2021-11-26 12:28:26 <psykose> because the install used -m 700
2021-11-26 12:28:33 <ktprograms> psykose: Ah that's what you mean. Ok
2021-11-26 12:31:51 <psykose> i'm beginning to think i should bump libtorrent-rasterbar to 2.x and not bother actually running any tests just like now
2021-11-26 12:32:19 <psykose> one of the tests fails because the test ssl cert has been expired since june.. yet nobody has reported this on github, so i'm thinking nobody even bothers running these
2021-11-26 13:10:09 <ktprograms> Should I quote this like spellcheck suggests: https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/547241#L50
2021-11-26 13:11:29 <ikke> yes, better to do so
2021-11-26 13:13:36 <ktprograms> ikke: What about the other warnings?
2021-11-26 13:13:52 <ikke> SC3060 you can ignore
2021-11-26 13:14:18 <ikke> The others are valid in general
2021-11-26 13:14:36 <ikke> (sometimes you know it's not going to happen, but it's good to be consistent)
2021-11-26 13:16:19 <ktprograms> ikke: Ok, thanks
2021-11-26 13:37:06 <Hello71> ktprograms: https://gitlab.alpinelinux.org/alpine/aports/-/issues/9364
2021-11-26 13:38:47 <Hello71> apparently ncopa also forgot that he filed this
2021-11-26 13:39:11 <MaximKarasev[m]> Hm, why was fpc aport removed right after it was added? I'd like to get it in repos.
2021-11-26 13:39:38 <ikke> 27b2cd47076aa2e501defb6a5501b1926017bfdb
2021-11-26 13:39:54 <ikke> maxice8: ^
2021-11-26 13:40:41 <psykose> probably didn't feel like maintaining it
2021-11-26 13:41:05 <psykose> also languages/their compilers are best maintained by someone very involved with it
2021-11-26 13:43:21 <MaximKarasev[m]> Also what's the correct way of bootstrapping a package that depends on itself? Upload a temporary package that downloads prebuilt binaries and then a normal package, or there's something cleaner?
2021-11-26 13:43:57 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3C33KG0XO61I4IL.2Z7RTAZ5J3SY6%408pit.net%3E
2021-11-26 13:48:50 <MaximKarasev[m]> <psykose> "also languages/their compilers..." <- Free Pascal doesn't seem to be very active and requiring high involvement to maintain. That year old apkbuild gives a working compiler at least.
2021-11-26 13:48:53 <MaximKarasev[m]> ikke: Thanks!
2021-11-26 13:49:17 <psykose> MaximKarasev[m]: i don't mean you shouldn't do it, i just mean it's better not there if someone will just throw it there and forget about it :)
2021-11-26 13:49:25 <psykose> if it's not a lot of work for you feel free to add it
2021-11-26 13:50:11 <ikke> MaximKarasev[m]: so probably it means creating a dedicated bootstrap / stage0 package that does what you suggested and let the actual pacakge depend on it, but it's not clear yet if that's the direction we want to go in.
2021-11-26 14:13:31 <MaximKarasev[m]> <ikke> "Maxim Karasev: so probably it..." <- Haven't seen it in action actually. I'd better wait for someone to implement it for other compiler first, so I may be sure it's the way to go :D
2021-11-26 14:25:33 <ktprograms> Hello71: Thanks for finding the link. So since there hasn't been any formal rule on /var/tmp, I can just leave nextcloud-initscript as is for now?
2021-11-26 14:27:33 <Hello71> well it's clear that setting /var/tmp to 755 is wrong
2021-11-26 14:27:38 <Hello71> the question is how to fix it
2021-11-26 14:28:49 <ikke> I tend to agree packages should not manage anything in /var/tmp
2021-11-26 14:29:59 <ikke> sudo deprecation of alpine linux is mentioned on dutch tech site
2021-11-26 14:31:25 <ikke> Link in case you're interested: https://tweakers.net/nieuws/189998/alpine-linux-wil-sudo-commando-door-doas-van-openbsd-vervangen.html
2021-11-26 14:52:17 <Hello71> fcolista: are you sure that this will not delete hfaxd.conf for existing users?
2021-11-26 14:55:51 <fcolista> Hello71, apk si not going to delete anything
2021-11-26 14:55:54 <fcolista> *is
2021-11-26 15:13:55 <minimal> in the scripts for building Alpine standard/extended etc images where is the firmware to be included specified? I see that mkimg.base.sh calls update-kernel with "--modloopfw "$modloopfw" but I don't see modloopfw defined anywhere
2021-11-26 15:58:20 <Hello71> ncopa, ikke: i am thinking we should make some old aports issues non-confidential. specifically i want to release all closed issues with label tag:security and updated at least 1 year ago. i looked through issues and noted only #11430 with arguably "sensitive information". issue #9745 title looks sensitive but is actually just a spam. i didn't check each issue contents though,
2021-11-26 15:58:22 <Hello71> only title.
2021-11-26 15:58:47 <Hello71> it is not super important but i want to avoid having like mozilla where git refers to 10 year old bugs which are still hidden
2021-11-26 15:59:40 <ikke> Hello71: I personally don't see an issue with that
2021-11-26 17:18:29 <Hello71> on a vaguely related note, Cogitri: can we please turn off stale mr notice? it is extremely obnoxious to receive when the problem is normally the maintainer is not responding, not something wrong with the patch (i.e. it is not actionable by the MR creator)
2021-11-26 17:18:44 <Hello71> (i think Cogitri implemented that, sorry if i misremembered)
2021-11-26 18:17:38 <Ariadne> nmeum: the gcc patches have to have sign-off now when going upstream
2021-11-26 18:18:56 <nmeum> yeah, I thought I added it but only noticed it after sending the mail :S
2021-11-26 18:19:16 <nmeum> we can also cleanup our other gcc-go patches a bit and send those upstream
2021-11-26 18:20:00 <nmeum> a few of this patches just work around the fact that loff_t and off64_t are defined as macros and not typedefs on musl and thus not recognized by gcc's -fdump-go-spec
2021-11-26 18:20:14 <nmeum> *these
2021-11-26 20:59:43 <omni> a bit sad that this didn't get in https://github.com/alpinelinux/alpine-make-vm-image/pull/21 I'll have to stick to my fork then
2021-11-26 21:00:06 <omni> good feedback on my other PR though, I'll probably fix that during the weekend
2021-11-26 21:06:48 <Guest6880> Hiya! Congrats on next step! My usb input devices won't work. I think the cause is new xorg, but i,m not sure. Is there is a way to downgrade xorg? Any script like uninstall-xorg-base? sadface
2021-11-26 21:42:55 <mps> how to clone branch from github?
2021-11-26 21:43:26 <mps> this one https://github.com/kettenis/u-boot/tree/apple-m1-m1n1-nvme for example
2021-11-26 21:43:50 <mps> with git clone I got only master branch
2021-11-26 21:47:15 <Hello71> mps: did you try git checkout
2021-11-26 21:47:52 <mps> Hello71: no, only git branch and it shows only master
2021-11-26 21:48:06 <Hello71> when you use git checkout, it will automatically create branch
2021-11-26 21:48:39 <mps> ah, wonder why it is not visible with 'git branch'
2021-11-26 21:48:52 <Hello71> local tracking branches are only created on demand
2021-11-26 21:49:09 <mps> lets try, thanks
2021-11-26 21:51:14 <Hello71> Guest6880: you need to install xf86-input-evdev or xf86-input-libinput
2021-11-26 21:51:39 <mps> Hello71: it works, thanks again
2021-11-26 21:52:26 <Hello71> it was documented in alpine linux 3.14 release notes, but possibly not clear enough
2021-11-26 21:54:51 <Guest6880> Hello71, thanks for that info, i already cut my hair out...
2021-11-26 21:56:21 <Guest6880> going to try out the solution
2021-11-26 22:02:13 <mtnt_> No luck... Even update 5.15.4 did not fixed it. I'm still sitting here with sadface 
2021-11-26 22:02:55 <mtnt_> If you'll ask, yes Guest6880 that was me
2021-11-26 22:18:25 <Hello71> post xorg log
2021-11-26 22:18:38 <boomanaiden154> I'm currently having trouble installing vim on 3.15 and edge. APK complains about a bad signature on xdd and vim. Is anyone else able to replicate this issue?
2021-11-26 22:32:11 <Hello71> ikke said that he would deal with it
2021-11-26 22:32:21 <Hello71> however he did say this 7 hours ago
2021-11-26 22:33:32 <smcavoy> boomanaiden154: try a different mirror
2021-11-26 22:35:17 <Hello71> i think it is related to gvim unsplitting
2021-11-26 22:36:44 <boomanaiden154> That would make sense. I didn't have the problem yesterday and that commit revert was 10 hours ago.
2021-11-26 23:05:58 <mtnt_> i'm out of space, so unable to post nothing, but thanks!
2021-11-26 23:08:38 <mtnt_> thanks to Nathan and all the people involved, even if corporations will take this off from us, we already had some fun learning of it while testing that high quality stuff.
2021-11-26 23:09:28 <mtnt_> i'm drunk
2021-11-26 23:10:07 <MY-R> good for you ;)
2021-11-26 23:10:33 <mtnt_> wi'll see it tomorrow
2021-11-26 23:11:14 <valerius> "testing that high quality stuff"
2021-11-26 23:11:49 <MY-R> he/she/they knew when quit :) +1
2021-11-26 23:26:06 <Cogitri[m]> Hello71: Sure, we can disable that, or increase the time for MRs to be marked as stale. Just edit https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.gitlab/aports-qa-bot.json for the latter
2021-11-26 23:29:39 <andypost[m]> any idea what's wrong with Github API as common pattern stopped work, example 4e43364540c3 also in #_oftc_#alpine-commits:matrix.org delta fails for the same reason
2021-11-26 23:34:32 <PJ[m]> https://github.com/dandavison/delta/archive/refs/tags/0.10.0.tar.gz
2021-11-26 23:41:56 <PJ[m]> it seems like they changed their URLs everywhere 
2021-11-26 23:42:12 <PJ[m]> everything has to have refs/tags/ now
2021-11-26 23:44:51 <psykose> i think clicking download links on the webpage has had refs/tags/ in it for quite a while now, so i guess it kind of makes sense
2021-11-27 00:15:59 <PJ[m]> https://github.com/dandavison/delta/archive/0.10.0.tar.gz works now
2021-11-27 00:16:17 <PJ[m]> so it's probably a brownout for people to switch to new link format
2021-11-27 01:01:40 <ktprograms> Hi, did anyone notice that the GitLab CI builders seem to have very slow internet access? For example aarch64 on !27815 is going at ~14K and estimating another 2 hours 18 minutes just to download the 124M nextcloud tarball.
2021-11-27 01:03:49 <ktprograms> It seems that nextcloud works just fine without the php-fpm8 service running (but of course starting the nextcloud service). This would make sense given that the nextcloud service is just a symlink to the php-fpm8 service. So is the wiki wrong or am I missing something?
2021-11-27 01:23:36 <andypost[m]> ktprograms: it looks like it has own config https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/nextcloud/fpm-pool.conf so probably we need to split php8-fpm-openrc
2021-11-27 01:25:54 <ktprograms> andypost[m]: What do you mean by 'split php8-fpm-openrc'?
2021-11-27 01:28:56 <andypost[m]>  I mean nextcloud needs php-fpm but default install also provides default pool, which looks unused for nextcloud
2021-11-27 01:31:14 <andypost[m]> not sure that initd file and www.conf is needed for nextcloud https://pkgs.alpinelinux.org/contents?branch=edge&name=php8-fpm&arch=x86_64&repo=community
2021-11-27 01:31:50 <ktprograms> andypost[m]: Ah, I see what you mean. But I've got no idea how it can be split without having to duplicate the init script.
2021-11-27 01:39:41 <andypost[m]> I will check tomorrow with fresh head, please file issue
2021-11-27 01:43:00 <ktprograms> andypost[m]: The reason why I was asking was because of this comment: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27815#note_194620
2021-11-27 01:46:09 <andypost[m]> ktprograms: thank you will check tomorrow
2021-11-27 09:32:36 <Ariadne> would be nice to get an edge snapshot done so we have riscv64 install media
2021-11-27 09:34:13 <wyk72> I'm experiencing huge troubles with the latest kernel 5.15 in Alpine 3.15.0
2021-11-27 09:35:37 <wyk72> I use to passthrough my GPU through VFIO, blacklisting ALL graphic modules in the kernel line (i.e. nouveau, radeon, i915etc) and all the framebuffers
2021-11-27 09:36:24 <wyk72> with the latest kernel 5.15, the VFIO modules stopped working
2021-11-27 09:36:39 <wyk72> when I initialize the passtrough to QEMU
2021-11-27 09:37:26 <wyk72> the exact messages I get are
2021-11-27 09:37:31 <wyk72> DMAR: ERROR: DMA PTE for vPFN 0x3fe15 already set (to 4d6cd8803 n ot 4d6cd8803) [   91.628918] ------------[ cut here ]------------ [   91.628918] WARNING: CPU: 4 PID: 3697 at drivers/iommu/intel/iommu.c:2385 __d omain_mapping.cold+0x28/0x2f
2021-11-27 09:38:47 <wyk72> it's kind of a big issue for me
2021-11-27 09:41:30 <wyk72> I think it's connected with this: "Framebuffer drivers have been disabled in kernel and replaced by simpledrm."
2021-11-27 09:42:27 <wyk72> Even if I completely disable drm via blacklisting through kernel command line, vfio refuses to work
2021-11-27 10:12:39 <wyk72> if I load ALL the drivers without blacklisting anything
2021-11-27 10:12:43 <wyk72> vfio wokrs
2021-11-27 10:12:52 <wyk72> but I get dmesg clogged with these errors:
2021-11-27 10:12:55 <wyk72>  ---[ end trace 9f1642fe514280b4 ]--- [   80.621167] DMAR: ERROR: DMA PTE for vPFN 0x7fa21 already set (to 51685b803 not 51685b803) [   80.621170] ------------[ cut here ]------------ [   80.621170] WARNING: CPU: 6 PID: 3723 at drivers/iommu/intel/iommu.c:2385 __domain_mapping.cold+0x28/0x2f [   80.621171] Modules linked in: tun vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio nfs fscache netfs nfsd auth_rpcgss lockd grace sunr pc bridge stp 
2021-11-27 10:15:03 <wyk72> RIP: 0010:__domain_mapping.cold+0x28/0x2f
2021-11-27 11:29:58 <nmeum> Ariadne: I was also wondering if it would make sense to provide an apkvol image for riscv64 SBCs similar to the "Generic ARM" one we provide for aarch64 and armv7. I think clandmeter was working on that too
2021-11-27 11:30:09 <Ariadne> yes
2021-11-27 11:32:29 <nmeum> such an apkvol image could that be used by SBC-specific scripts like https://gitlab.alpinelinux.org/nmeum/alpine-unmatched though I think ddevault was also working on UEFI stuff on the unmatched with grub?
2021-11-27 11:34:54 <Ariadne> that is already integrated and what i was referring to
2021-11-27 11:36:18 <nmeum> right
2021-11-27 11:36:34 <nmeum> might still be useful to have that generic apkvol image as an additional installation media
2021-11-27 11:37:40 <psykose> wyk72: do you blacklist simpledrm
2021-11-27 11:39:23 <nmeum> on a related note: I also still want to modify the main/u-boot update-u-boot script in a way that it installs u-boot to the SPI flash on the unmatched, I think that should be possible with recent u-boot now
2021-11-27 12:18:51 <ktprograms> Hmm, the network on the CI seems to be very slow? https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/547739 (Average Dload is 17K?)
2021-11-27 12:21:00 <psykose> that url loads fast for me so it seems like the ci network indeed
2021-11-27 12:22:34 <ktprograms> psykose: Yes, it seems that by re-running the CI it sometimes becomes back to normal speed, but currently it seems to be stuck slow
2021-11-27 12:26:16 <ikke> It's not a general network issue on the builder
2021-11-27 12:26:19 <ikke> other downloads are very fast
2021-11-27 12:26:32 <ikke> 100  145M  100  145M    0     0  19.8M      0  0:00:07  0:00:07 --:--:-- 25.1M
2021-11-27 12:26:54 <ikke> (ci host)
2021-11-27 12:27:38 <ktprograms> ikke: Interesting. So what could be the problem here?
2021-11-27 12:29:13 <ikke> bad link?
2021-11-27 12:29:40 <ikke> latency is ~250 ms
2021-11-27 12:30:05 <ikke> to download.nextcloud.com
2021-11-27 12:31:47 <ktprograms> ikke: What does 'bad link' mean? But it downloads fine for me?
2021-11-27 12:32:00 <ikke> it depends on where you download from
2021-11-27 12:32:59 <ktprograms> ikke: So would there be any fix or just wait for it?
2021-11-27 12:33:56 <ikke> I don't think there is a lot we can do on our side
2021-11-27 12:34:01 <ikke> except for rehosting it
2021-11-27 12:34:15 <ktprograms> ikke: Ok
2021-11-27 12:34:42 <ktprograms> ikke: Although it was fast certain times (in the CI)
2021-11-27 12:35:02 <ikke> yes, I noticed that myself as well
2021-11-27 13:15:09 <omni> reading again, I'm no longer sad that one of my PRs didn't get into alpine-make-vm-image since this is better https://github.com/alpinelinux/alpine-make-vm-image/commit/faf94d8977056ee317cdcd1521a1cc30d85b399c
2021-11-27 22:23:27 <ikke> https://www.sqlite.org/releaselog/3_37_0.html
2021-11-27 22:29:09 <andypost[m]> ikke: is there abi changes for sqlite?
2021-11-27 22:29:17 <ikke> not sure yet
2021-11-27 22:33:15 <andypost[m]> ikke: I filed !27853
2021-11-27 22:34:09 <ikke> Let's see what checkapk says
2021-11-27 22:36:59 <andypost[m]> only license file got rename
2021-11-27 22:38:04 <ikke> usr/lib/sqlite3.36.0/libsqlite3.36.0.so -> usr/lib/sqlite3.37.0/libsqlite3.37.0.so
2021-11-27 22:38:34 <ikke> that's the tcl subpackage
2021-11-27 22:39:32 <ikke> Ok, looks good
2021-11-27 22:44:55 <andypost[m]> I think it's safe to merge to edge and let clandmeter to decide about backport
2021-11-28 00:38:27 <ktprograms> andypost[m]: In https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27815#note_194689 I'm guessing you're saying *I* should do this?
2021-11-28 09:39:11 <nmeum> Ariadne: how would I remove existing patches from alpine-gcc-patches? For example, 0029-gcc-go-Don-t-include-sys-user.h.patch is no longer neccessary
2021-11-28 09:39:32 <Ariadne> if they are upstreamed,
2021-11-28 09:39:40 <Ariadne> then they will go away at the next rebase
2021-11-28 09:39:46 <Ariadne> otherwise a rebase is needed
2021-11-28 09:41:26 <nmeum> ok, and in the meantime it would be fine just to remove it from $source in the gcc APKBUILD?
2021-11-28 15:57:17 <ikke> andypost[m]: can this MR be merged? !24540
2021-11-28 16:19:07 <ikke> maxice8: any reason why you pinged !24178 instead of merging it?
2021-11-28 16:27:02 <Hello71> https://github.com/github/feedback/discussions/8149
2021-11-28 16:35:23 <andypost[m]> ikke: looks like it ready, if it pass
2021-11-28 16:45:58 <ikke> Hello71: ok, nice, it has been rolled back
2021-11-28 20:40:49 <PureTryOut> ikke: I'd advise against merging !24178, I just left a comment on the MR explaining why
2021-11-28 20:41:57 <ikke> PureTryOut: I see
2021-11-28 22:48:28 <Ariadne> Hello71: http://lists.busybox.net/pipermail/busybox/2021-November/089342.html
2021-11-28 22:48:49 <Ariadne> Hello71: "In any case where 553 bytes is critical," is heresy in busybox land, just fyi
2021-11-28 22:51:12 <skarnet> for good reason, because it really adds up in a piece of software like busybox
2021-11-28 22:51:58 <skarnet> not saying I agree with the design of it, but given the choices that have been made, it makes sense that vda (and others) pay a lot of attention to very small size increases
2021-11-28 22:51:58 <psykose> the proposed change is very sane for daily usability
2021-11-28 22:52:04 <psykose> i believe it has been talked about here maybe 5 times
2021-11-28 22:52:30 <skarnet> oh, I'm not disagreeing with that
2021-11-28 22:52:35 <psykose> of course :)
2021-11-28 22:55:49 <psykose> is there a place you are supposed to clone musl libc from that isn't git.musl-libc.org ? i have been cloning it for maybe 10 minutes, it feels like 5KB/s link or something
2021-11-28 22:56:49 <mps> psykose: it works fine for me, though I forgot speed
2021-11-28 22:57:02 <psykose> finally done at least, no issues now
2021-11-28 22:57:24 <psykose> just strange to see things be that slow sometimes, unless it's badly routed through the internet i guess
2021-11-28 23:12:39 <Hello71> Ariadne: but 500 bytes is like two filesystems turned off
2021-11-28 23:12:48 <Ariadne> yes
2021-11-28 23:12:57 <Ariadne> i'm not saying that your logic is wrong
2021-11-28 23:13:07 <Hello71> if that's an argument then we should delete, like, romfs
2021-11-28 23:13:16 <Hello71> or cramfs, who is using blkid on that
2021-11-28 23:13:26 <Ariadne> i'm just saying they will ignore that argument
2021-11-28 23:13:33 <Hello71> really you should be picking on "60 bytes is negligible"
2021-11-28 23:14:09 <Ariadne> yes, they should pick on that, but they will pick on the 533 bytes instead
2021-11-28 23:14:30 <Ariadne> i'm just warning you :)
2021-11-28 23:15:00 <Hello71> *shrug*
2021-11-28 23:15:10 <Hello71> if they really don't want it then just apply it in alpine
2021-11-28 23:15:19 <Hello71> and delete the stupid System.map, that's like 10 MB saved
2021-11-28 23:16:35 <mps> System.map is 2.7M on my armv7
2021-11-28 23:16:59 <Hello71> ok i think it's actually like 3-6 MB but anyways
2021-11-28 23:17:23 <mps> yes, I agree, will remove it from linux-edge
2021-11-28 23:17:37 <Hello71> afaik absolutely nothing actually uses it nowadays, not least because it's useless if kaslr is working
2021-11-28 23:17:50 <Hello71> (almost useless)
2021-11-28 23:18:13 <mps> not almost but totaly imo
2021-11-28 23:18:38 <Hello71> well theoretically you could calculate base offset, then apply that to System.map
2021-11-28 23:18:56 <Hello71> but if you're going to all that effort then just use /proc/kallsyms instead?
2021-11-28 23:19:25 <mps> those who wants this should build kernels locally
2021-11-28 23:19:26 <Hello71> i have patch to delete it in linux-lts but then i got distracted trying to minimize -dev size
2021-11-28 23:20:17 <mps> also -dev subpkg in kernels should gone and use proper kernel-headers
2021-11-28 23:20:23 <Hello71> you don't even have to, there is https://github.com/marin-m/vmlinux-to-elf
2021-11-28 23:21:03 <Hello71> you mean linux-headers? that doesn't have proper files for making kernel modules
2021-11-28 23:21:28 <Hello71> i guess you could deduplicate some of the files but it would be more effective to reduce gcc size
2021-11-28 23:21:35 <Hello71> s/effective/productive/
2021-11-28 23:21:35 <alpine-meetbot> Hello71 meant to say: i guess you could deduplicate some of the files but it would be more productive to reduce gcc size
2021-11-28 23:22:36 <mps> I think akms could use just kernel-headers, though didn't had time to test
2021-11-28 23:23:22 <mps> see you tomorrow
2021-11-28 23:27:09 <Hello71> i don't know what you mean by kernel-headers
2021-11-29 00:42:36 <ericonr> psykose: I have a copy of the repo up on github, if that helps :p 
2021-11-29 08:11:55 <sam_> q
2021-11-29 08:11:56 <sam_> oops
2021-11-29 08:38:13 <ikke> o/
2021-11-29 08:44:25 <mps> ikke: \q
2021-11-29 08:44:40 <mps> s/q/o/
2021-11-29 08:44:40 <alpine-meetbot> mps meant to say: ikke: \o
2021-11-29 08:45:52 <mps> Hello71: I mean linux-headers (sorry for confusion). and make them similarly like Arch and Void linux do
2021-11-29 09:20:23 <alandiwix> skarnet: Hi. Does mdevd execute mdev-coldplug in the background?
2021-11-29 09:22:05 <skarnet> alandiwix: it will if you give it the -C option.
2021-11-29 09:22:44 <skarnet> By default, it doesn't: (because it should be supervised and you don't want to run a coldplug if it happens to restart)
2021-11-29 09:26:20 <alandiwix> maybe we should consider separating it in the openrc init scripts in the future? I'm having an issue where some devices are getting ready after I got login prompt.
2021-11-29 09:29:50 <skarnet> well I'm all for *not* using -C and doing the coldplug in a different service, but that won't help with your display issue
2021-11-29 09:30:49 <skarnet> because you can't block while the coldplug is running (mdev-coldplug blocks until it has triggered all the events, but even after it has done that and exited, the kernel and the device manager still have most of the work to do)
2021-11-29 09:31:27 <skarnet> and tbh you don't want to block, because depending on the devices, it can take a lot of time and is best done in the background unless you have a specific device you need to wait for
2021-11-29 09:32:27 <skarnet> if your issue is just a login prompt aesthetics, my advice is a distro policy one: don't spawn a getty on the VT used for /dev/console :P
2021-11-29 09:33:40 <alandiwix> thanks, didn't know that, I thought blocking on coldplug would resolve the issue
2021-11-29 09:34:18 <skarnet> nope, you'd have the exact same issue with udevd or anything else
2021-11-29 09:39:13 <alandiwix> the reason I'm asking is: I can't make one of my custom oneshot init scripts work on a new machine (even if I execute it after all other scripts), for example alsa card doesn't exist, cpu sysfs entry also doesn't accept writes to disable boost, etc. The other machine with the same software works just fine.
2021-11-29 09:42:02 <alandiwix> I hope it's just the hardware is too new and it will be gone in some next kernel version
2021-11-29 09:43:53 <markand> I just realized there are some packages installing .pc files in /usr/share/pkgconfig
2021-11-29 09:44:13 <markand> shouldn't we merge all in /usr/lib/pkgconfig (which has widely 90% the most of them instead)?
2021-11-29 09:44:33 <markand> and then make abuild complain if there are some files living in /usr/share/pkgconfig 
2021-11-29 09:51:17 <Ariadne> maxice8: why did you merge the ircd-hybrid change?  it was incomplete
2021-11-29 09:54:23 <ktprograms> Hi, can someone please merge !27943 ? I need it merged in order to package https://github.com/tldr-pages/tldr-python-client. Thanks!
2021-11-29 09:55:36 <ktprograms> Oops, sorry. Forgot to add the docs subpackage. Hold on a while.
2021-11-29 10:13:28 <ktprograms> Ok, I think !27943 can be merged now.
2021-11-29 10:24:46 <maxice8> Ariadne: sorry, put the wrong number in my merge script
2021-11-29 12:23:52 <nero> Ariadne: #27909 is meant as a quick fix for the openrc unit being broken
2021-11-29 12:24:20 <nero> i've put the fix into my /etc/default/dhcpcd for now so the unit is working
2021-11-29 12:24:39 <Ariadne> yes, i get that, but i think fixing dhcpcd would not take much more effort.  it's on my to-do list.
2021-11-29 12:24:48 <nero> if someone with more experience with dhcpcd could fix the other things
2021-11-29 12:24:59 <nero> ncopa is maintainer but im unsure if there are time resources available
2021-11-29 12:25:20 <Ariadne> the problem with quickfixes is that things get quickfixed and then ignored
2021-11-29 12:29:24 <nero> you see this https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/dhcpcd/APKBUILD#L29
2021-11-29 12:38:05 <ktprograms> Hi, why would this CI run be stuck: https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/550922, and should I just re-run it?
2021-11-29 13:08:37 <fcolista> can anyone advice on this MR? #27946
2021-11-29 13:08:42 <fcolista> !27946
2021-11-29 13:09:04 <fcolista> I've no clue on what kind of backfire can lead this MR
2021-11-29 13:39:21 <psykose> it will require to fix probably over half of the meson apkbuilds
2021-11-29 13:40:56 <Hello71> auto_features=auto is better
2021-11-29 13:45:52 <Hello71> disabled is only better for legacy source-based distros that compile everything in real system root and want to fully track everything, normally including sonames. arch and alpine were never designed that way, with USE flags, automatic soname rebuilds, etc
2021-11-29 13:52:16 <maxice8> fcolista: meson-using stuff when bumped will need to be checked to see if some desired feature is lost, aports that relied on automagic will lose features until explicitly enabled
2021-11-29 14:00:07 <fcolista> Hello71, maxice8 : thanks for you valuable feedback. So what I understand is that is better to leave auto, if we want to avoid breakage.  
2021-11-29 14:00:37 <fcolista> Moreover, this MR probably should contain more explanation on why should be disabled.
2021-11-29 15:45:43 <minimal> nero: the dhcpcd problem appears to be with the definition of PIDFILE in the code src/defs.h as "/%s%s%spid" as if all the 3 strings are empty then that maps to "/run"
2021-11-29 15:53:21 <nero> minimal: this is also documented in the manpage, so not a bug in the code sense
2021-11-29 15:53:44 <nero> the manpage uses the value given via ./configure --rundir=
2021-11-29 15:54:08 <nero> which the APKBUILD sets to /run
2021-11-29 15:54:19 <minimal> nero: I also noticed in the dhcpcd configure script there is a "--runstatedir" param
2021-11-29 15:55:18 <nero> which defaults to rundir plus a suffix iirc
2021-11-29 15:56:52 <minimal> nero: yupe, the point is that the pidfile should be something like /run/dhcpcd.pid so the package needs patched to achieve that. I also notice sometime ago a warning at startup of dhcpcd related to its privsep functionality that the "dhcpcd" user is missing
2021-11-29 15:57:24 <minimal> I've been meaning to find some time to fix that but haven't had a chance so far
2021-11-29 16:00:10 <nero> might it be that not many people use alpine as a desktop?
2021-11-29 16:00:27 <nero> because the dhcpcd service has been broken for this like almost a year
2021-11-29 16:02:09 <mps> nero: I tried once to use dhcpcd and removed it when saw what it does
2021-11-29 16:02:33 <minimal> nero: dhcpcd can also be used on servers
2021-11-29 16:05:02 <psykose> last time i used dhcpcd it 'segfaults' when run by networking service but still works as its forked processes do everything
2021-11-29 16:07:35 <minimal> psykose: have it running on a VM fine here
2021-11-29 16:07:49 <psykose> it runs fine, but the output says bad system call for me at least
2021-11-29 16:18:15 <minimal> the only issue I had noticed is the "missing dhcpcd user" warning
2021-11-29 16:25:33 <nero> i investigated the missing dhcpcd user warning previously, but i did not find where that username was specified
2021-11-29 16:28:05 <MY-R> Im using dhcpcd since ifupdown-ng wont wait for my usb nic device
2021-11-29 16:28:49 <MY-R> and didnt notice missing pids etc because I never got chance to restart it, all time working fine but ye would be nice to fix it
2021-11-29 16:34:10 <psykose> minimal: looks like this https://termbin.com/cq6w
2021-11-29 16:34:17 <psykose> of course the forks still manage the interface and it runs fine
2021-11-29 16:43:54 <nero> psykose: im puzzled that you run dhcpcd manually
2021-11-29 16:44:36 <nero> like, when you run it manually anyways, you can use the busybox dhcp client, right?
2021-11-29 16:44:48 <psykose> i don't run it manually
2021-11-29 16:44:57 <psykose> it gives the same bad system call run from networking
2021-11-29 16:45:53 <nero> what happens if you strace it?
2021-11-29 16:47:27 <minimal> psykose: tried running dhcpcd manually as non-root (via doas) and do not see that error, just the usual "no such user dhcpcd" one
2021-11-29 16:47:37 <psykose> i have a dhcpcd user
2021-11-29 16:48:34 <psykose> nero: https://termbin.com/wvtx
2021-11-29 16:49:10 <minimal> psykose: that's likely due to the privsep functionality not working correctly then
2021-11-29 16:50:11 <psykose> i assume the sigsys is from the last strace call (madvise), but who knows
2021-11-29 17:05:04 <minimal> psykose: don't see any madvise in the dhcpcd source but for the munmap just before the sigsys I see a #define related to munmap and seccomp in the code
2021-11-29 17:05:19 <minimal> so could be seccomp related
2021-11-29 17:22:33 <psykose> you would know more than me :)
2021-11-29 21:09:00 <mps> anyone have problem that firefox don't start (stuck) on xorg with simpledrm
2021-11-29 21:09:40 <mps> it is stuck reading two FDs (pipes) and getting EAGAIN in loop
2021-11-29 21:09:48 <mps> very strange
2021-11-29 22:37:25 <craftyguy> mps: any reason why you didn't enable DEBUG_FS in the edge kernel?
2021-11-29 22:37:47 <craftyguy> linux-edge, that is
2021-11-29 22:38:36 <craftyguy> I just git blamed the config and you created it, debugfs was disabled there
2021-11-29 22:41:57 <mps> craftyguy: my intention when created it was to have minimum options and drivers enabled to be fast and responsive
2021-11-29 22:42:40 <craftyguy> would you be opposed to enabling debugfs in it?
2021-11-29 22:42:47 <mps> 'normal' users should use -lts
2021-11-29 22:43:08 <craftyguy> 
ACTION not a 'normal' user :P

2021-11-29 22:43:27 <Hello71> mps: how does removing loadable modules make it more fast and responsive?
2021-11-29 22:43:37 <Hello71> if you don't want it then just don't load it
2021-11-29 22:43:41 <mps> craftyguy: yes, I don't like this idea but if we discuss with more people everything is possible
2021-11-29 22:44:18 <mps> Hello71: size also
2021-11-29 22:44:21 <craftyguy> debugfs has to be builtin, IIRC. but it's not mounted by default so it shouldn't(?) have any implication for fast/responsiveness ?
2021-11-29 22:45:00 <Hello71> imo alpine kernel should use more subpackages, then you can just install parts you want
2021-11-29 22:45:05 <craftyguy> it's useful to have when gathering info for issues on the mainline kernel
2021-11-29 22:45:27 <craftyguy> mainline latest release kernel
2021-11-29 22:46:06 <Hello71> and also can reduce iso size, e.g. on alpine-standard we don't need to ship media subsystem
2021-11-29 22:46:17 <mps> craftyguy: 'we' expect that our users know how to build kernels (and any pkg) if they need something
2021-11-29 22:46:40 <craftyguy> mps: yeah I've been building linux-edge with it enabled, but it's annoying to have to build every point release :P
2021-11-29 22:47:10 <craftyguy> and just about everyone else (it seems?) ships kernels with debugfs enabled
2021-11-29 22:47:26 <Hello71> current ad-hoc method of adding whatever people ask for is not good. it is annoying to ask, and also as you point out, many of these things really are needed by just one person, and if they stop using it, it never gets removed
2021-11-29 22:47:44 <mps> craftyguy: I build different kernels with different options nearly every day, sometime few times on day
2021-11-29 22:47:59 <craftyguy> Hello71: you can't 'enable' debugfs with a subpackage? it's built into the kernel, so it would be a totally separate kernel...
2021-11-29 22:48:39 <craftyguy> mps: ok? I don't necessarily have the hardware/time to do that, so I thought I'd ask. it doesn't seem like an unreasonable thing to ask for. but I get your point about why you didn't enable it
2021-11-29 22:49:31 <Hello71> hm, i thought it was modular like configfs
2021-11-29 22:49:49 <craftyguy> let me check
2021-11-29 22:49:56 <craftyguy> I thought it was either 'not set' or =y
2021-11-29 22:49:57 <mps> craftyguy: if you and more people come with really good reasoning, maybe
2021-11-29 22:49:59 <Hello71> it isn't modular
2021-11-29 22:50:15 <Hello71> i checked already because i wasn't sure about configfs either :p
2021-11-29 22:50:38 <craftyguy> Hello71: yep, builtin only :)
2021-11-29 22:52:08 <craftyguy> mps: ok..
2021-11-29 22:52:21 <mps> did anyone looked how many XXX_DEBUGFS are in config
2021-11-29 22:55:21 <craftyguy> Hello71: your point is valid though. there are a few kernel configs in aports, and requests may not be propagated. and config that is no longer necessary may never be removed, etc
2021-11-29 23:13:33 <minimal> mps: happen building my own kernels, the only potentially is that unless using a custom package name for a custom kernel then there's always a risk that a "apk upgrade" installs a newer official over the top (i.e. you build custom 5.15.x kernel and then Alpine releases 5.16.0 kernel and update installs that)
2021-11-29 23:13:38 <minimal> s/happen/happy/
2021-11-29 23:13:38 <alpine-meetbot> minimal meant to say: mps: happy building my own kernels, the only potentially is that unless using a custom package name for a custom kernel then there's always a risk that a "apk upgrade" installs a newer official over the top (i.e. you build custom 5.15.x kernel and then Alpine releases 5.16.0 kernel and update installs that)
2021-11-29 23:21:14 <psykose> funnily -edge has config_preempt and hz=1000 while -lts only has preempt_voluntary and hz=300, so edge is significantly more responsive for desktop under load on x86_64
2021-11-29 23:26:47 <minimal> yet -lts has simpledrm but -edge does not
2021-11-29 23:27:19 <psykose> :p
2021-11-29 23:27:24 <craftyguy> lol
2021-11-29 23:27:50 <psykose> iirc one of the linked things back during the simpledrm decision was the fedora changelog for removing fbdev
2021-11-29 23:27:59 <psykose> but it is for the next fedora release, not out yet
2021-11-29 23:28:13 <psykose> i think alpine is one of the first distros to have simpledrm only by default, but i didnt check
2021-11-29 23:29:50 <psykose> in any case #12933 really should be done at some point
2021-11-29 23:31:41 <minimal> psykose: yes that would be useful to align things between various arches better
2021-11-30 02:16:23 <q66> psykose: we changed back in void because it was causing trouble for users
2021-11-30 02:16:46 <psykose> the simpledrm change?
2021-11-30 02:16:48 <q66> yes
2021-11-30 02:16:53 <psykose> i can see that
2021-11-30 02:37:53 <Hello71> i think arch did too
2021-11-30 02:39:26 <psykose> this is all i can find for arch https://github.com/archlinux/svntogit-packages/commit/126a752c9bbb8ced1ee796fc5f5e7971d61d239d
2021-11-30 02:39:40 <psykose> and the current linux config in the tree has simpledrm enabled
2021-11-30 02:39:52 <ktprograms> Hi, why does using $pkgname-fpm_openrc in subpackages work, but $pkgname-fpm-openrc:fpm_openrc assume that the -fpm-openrc package is noarch?
2021-11-30 02:42:49 <psykose> doesn't it inherit the package arch? if this is for nextcloud, it is ="noarch"
2021-11-30 02:43:16 <ktprograms> psykose: It's for php8, which is ="all"
2021-11-30 02:43:38 <psykose> noarch seems like the correct equivalent for an openrc script
2021-11-30 02:43:43 <ktprograms> It seems to be the hyphen in the subpackage name that causes the problem.
2021-11-30 02:43:52 <psykose> ah
2021-11-30 02:44:16 <psykose> i think -openrc gets detected and converted; _openrc does the default and follows the package arch
2021-11-30 02:44:28 <psykose> but -openrc *should* be noarch, it's just a text file
2021-11-30 02:44:35 <ktprograms> psykose: It's an openrc script but it needs /usr/sbin/php-fpm8
2021-11-30 02:44:53 <psykose> and python programs need /usr/bin/python3 but they are usually mostly noarch
2021-11-30 02:44:55 <ktprograms> Which is an executable arch-specific binary
2021-11-30 02:45:26 <psykose> noarch doesn't mean it will be built for every arch
2021-11-30 02:45:32 <psykose> it will still be limited to the parent package
2021-11-30 02:46:30 <ktprograms> psykose: This is the problematic line it seems: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L579
2021-11-30 02:46:41 <psykose> there is no problem here
2021-11-30 02:47:50 <ktprograms> psykose: The php8 fpm openrc package will need the /usr/sbin/php-fpm8 binary to run, so it HAS to be arch="all" not arch="noarch"
2021-11-30 02:47:58 <psykose> that doesn't make sense
2021-11-30 02:49:07 <ktprograms> psykose: The idea is to have a minimal php8-fpm-openrc package that can be used for the nextcloud-initscript but doesn't have (for example /etc/php8/php-fpm.d/www.conf) which isn't needed for nextcloud-initscript.
2021-11-30 02:49:16 <psykose> if php8 becomes "all !x86_64", then nextcloud will be unable to run on x86_64, and subsequently will become "noarch !x86_64", and so the subpackage will not be built for x86_64
2021-11-30 02:50:01 <ktprograms> psykose: I don't get what you mean
2021-11-30 02:50:07 <psykose> it doesn't matter whether it is "all" or "noarch", it will still be built according to what the apkbuild says, and if nextcloud can't run on the platform it will be disabled for it
2021-11-30 02:50:12 <psykose> i don't see where the issue is here
2021-11-30 02:51:29 <psykose> if you make a php8-fpm-openrc, it will be noarch, and it will only exist on the archs supported by php8-fpm, it's not possible you can install it with php8-fpm not being available on the arch normally
2021-11-30 02:52:21 <psykose> look at any -openrc with limited arches in the repo, they are all limited to the parent package, because the builders skip the build if it's a !arch and so it doesn't exist
2021-11-30 02:52:56 <psykose> basically, the behaviour here is correct/doesn't matter, and you can just keep doing what you were
2021-11-30 02:53:11 <ktprograms> psykose: In the php8 APKBUILD, I've added a php8-fpm-openrc package which contains /etc/init.d/php8-fpm and /usr/sbin/php-fpm8. But when abuild'ing php8, it complains that arch should be set to all (instead of noarch which is the default for -openrc packages) because it contains an arch specific binary.
2021-11-30 02:53:28 <psykose> ah, i see
2021-11-30 02:53:38 <psykose> don't put php-fpm8 in the -openrc
2021-11-30 02:53:58 <ktprograms> psykose: See my earlier message about nextcloud-initscript.
2021-11-30 02:54:12 <psykose> which one
2021-11-30 02:54:32 <psykose> ah, that
2021-11-30 02:54:38 <psykose> you can't put binaries in -openrc
2021-11-30 02:55:02 <ktprograms> psykose: So what would be the solution? It needs that binary in order to work.
2021-11-30 02:55:47 <psykose> if i understand correctly, you want a php8-fpm with some files removed, and also a init.d
2021-11-30 02:55:55 <ktprograms> psykose: Yes
2021-11-30 02:56:13 <psykose> so, make a php8-fpm-openrc with the init script, and a php8-fpm-minimal or whatever else that is 'smaller'
2021-11-30 02:56:26 <psykose> i don't know what exactly you are doing but if it's only removing /etc files then this is not a good idea
2021-11-30 02:56:58 <ktprograms> psykose: Basically this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27815#note_194689
2021-11-30 02:57:03 <Hello71> psykose: https://github.com/archlinux/svntogit-packages/commits/packages/linux/trunk
2021-11-30 02:57:45 <psykose> Hello71: ahh, trunk
2021-11-30 02:58:03 <Hello71> the trunk doesn't really matter, it just makes it cleaner
2021-11-30 02:58:19 <Hello71> i guess technically you can also look at https://github.com/archlinux/svntogit-packages/commits but you'll never find anything in there
2021-11-30 03:05:10 <ktprograms> andypost[m]: What do you think about this (not allowed to have binaries in -openrc packages)?
2021-11-30 03:06:54 <psykose> funnily php8-fpm bundles an init.d without putting it in -openrc, and nextcloud itself names -openrc -initscript for some reason
2021-11-30 03:07:04 <psykose> i guess you can make a php8-fpm-minimal with everything you want in it
2021-11-30 03:08:56 <psykose> i don't know much about what this is doing, but can't packages already install their own "pools"? the nextcloud package installs a fpm-pool with the same name as the service so i assume it works
2021-11-30 03:09:04 <ktprograms> psykose: I think I'll call it php8-fpm-initscript then.
2021-11-30 03:09:38 <ktprograms> psykose: It works, but by nextcloud-initscript depending on the full php8-fpm, it add extra conf files that are unused.
2021-11-30 03:09:46 <psykose> i don't see why this or nextcloud should deviate from the normal -openrc naming and not get autoinstalled
2021-11-30 03:09:56 <psykose> the extra conf files make up like 0.01% of the size of the package though
2021-11-30 03:10:22 <ktprograms> psykose: What does 'not get autoinstalled' mean?
2021-11-30 03:10:38 <psykose> -openrc gets pulled in automatically with openrc installed
2021-11-30 03:11:12 <ktprograms> psykose: This split wasn't my idea, see https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27815#note_194689
2021-11-30 03:13:03 <psykose> do these applications "use" the default pool or is this a good idea just to remove a few KB in config files that don't get used
2021-11-30 03:13:40 <ktprograms> psykose: nextcloud-initscript doesn't use the default pool
2021-11-30 03:14:35 <psykose> so this is just bikeshedding over two config files? well, split it out if you want, your preference
2021-11-30 03:15:29 <psykose> in that case calling it -minimal or somesuch should work fine
2021-11-30 03:16:44 <psykose> originally i thought these default files being there broke nextcloud or something
2021-11-30 03:19:11 <ktprograms> psykose: Ok, thanks.
2021-11-30 03:20:15 <psykose> in any case the default php8-fpm.init.d is designed to do exactly this, you symlink it to run something else, and put the config in https://git.alpinelinux.org/aports/tree/community/php8/php8-fpm.initd#n38
2021-11-30 03:21:17 <psykose> which is what it already does, so everything is fine
2021-11-30 03:23:03 <ktprograms> psykose: Yes, the only thing is the unused config files, but as I said, this split wasn't my idea so I've added a comment in the thread about whether this really is necessary.
2021-11-30 03:25:20 <psykose> the php-fpm8 service shouldn't be enabled if it's not actually used, so you are on the right track there
2021-11-30 03:25:28 <psykose> i think andy assumed something else was the issue
2021-11-30 03:26:28 <psykose> and needing user+group in the conf isn't a 'problem' with php-fpm8, it's just how it works, so everything is fine here
2021-11-30 03:26:37 <psykose> and good work on the other changes
2021-11-30 03:27:01 <ktprograms> psykose: So what are you suggesting to do about php8-fpm? I don't quite follow.
2021-11-30 03:27:15 <psykose> nothing, just keep whatever you were doing before trying to split files is my suggestion
2021-11-30 03:29:13 <ktprograms> psykose: As in let nextcloud-initscript depend on php8-fpm, and let it install the default pools?
2021-11-30 03:29:51 <psykose> yeah, sounds fine to me
2021-11-30 03:30:55 <ktprograms> psykose: Ok, thanks
2021-11-30 06:32:08 <ktprograms> Has anyone tried building eaglemode (http://eaglemode.sourceforge.net) for Alpine before? I used the build commands in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=eaglemode, but the built package only had a eaglemode and eaglemode.sh shell script which called each other. I looked at the official deb package and in there there is an actual eaglemode binary, but it doesn't seem to be getting built for me.
2021-11-30 06:59:09 <psykose> i can't even build it as it doesn't link -lexecinfo or something, and there is no way to pass flags to this that i can find
2021-11-30 07:11:57 <ktprograms> psykose: If you put a sh in build() and add '--link' 'execinfo' below the line '--link' 'emCore' in the file makers/emMain.maker.pl (or something like that) then it works.
2021-11-30 07:13:24 <psykose> oh, thanks
2021-11-30 07:15:12 <ktprograms> psykose: Do you want me to share my APKBUILD? (doesn't work as I said but has the correct deps etc)
2021-11-30 07:15:42 <psykose> no, i got it working
2021-11-30 07:15:45 <psykose> and also, it works
2021-11-30 07:16:21 <ktprograms> psykose: What arch? Didn't work for me on aarch64
2021-11-30 07:16:36 <psykose> x86_64, but you say it executes between two files
2021-11-30 07:17:08 <psykose> the script in the install path is supposed to change dir to it and then call $install/bin/eaglemode
2021-11-30 07:17:55 <psykose> you can see what EM_DIR is at the bottom with an echo or something, it should be the install root (like /opt/eaglemode in the install commands)
2021-11-30 07:18:37 <psykose> aside from that, it could be broken on other arches in another way
2021-11-30 07:19:35 <ktprograms> psykose: So it launches for you?
2021-11-30 07:19:39 <psykose> yep
2021-11-30 07:19:42 <psykose> i see the cute eagle
2021-11-30 07:19:48 <psykose> and the 1995 retro graphics
2021-11-30 07:19:49 <psykose> very cool
2021-11-30 07:21:08 <ktprograms> psykose: I'm going to try building it that it installs into /opt/eaglemode and try again
2021-11-30 07:21:31 <psykose> ah, did you install it to /usr? i think then it would be overlapping
2021-11-30 07:21:47 <psykose> you could do that if you set bin=no i think, maybe
2021-11-30 07:22:13 <psykose> if that is the thing that places the thing that calls th script in the install root
2021-11-30 07:23:32 <psykose> in other news, s390x ci runner is down
2021-11-30 07:27:20 <ktprograms> psykose: Ah, with bin=no /usr/bin/eaglemode is an actual binary and not a recursive call to /usr/eaglemode.sh
2021-11-30 07:28:15 <psykose> the reason why that happened is $root/eaglemode execs into $root/bin/eaglemode, and /usr/bin/eaglemode execs $root/eaglemode, which works if root is anything other than /usr
2021-11-30 07:28:27 <ktprograms> psykose: Yes, makes sense.
2021-11-30 07:29:19 <ktprograms> psykose: Works fine now with installing into /usr but with bin=no, but then I need to run /usr/eaglemode.sh
2021-11-30 07:29:33 <psykose> you could just put it in /opt as it was originally
2021-11-30 07:30:02 <ktprograms> psykose: abuild doesn't like files in /opt and I want the safety net of being able to uninstall everything.
2021-11-30 07:32:17 <psykose> well, it allows it if you add options=!fhs or something
2021-11-30 07:33:11 <ktprograms> psykose: Ah, thanks! Didn't know about options="!fhs"
2021-11-30 07:34:21 <ktprograms> psykose: Although if I package it for Alpine I'll need to figure out how to make it work when installing to /usr (that the user doesn't have to run /usr/eaglemode.sh)
2021-11-30 07:34:46 <psykose> that would take some effort :) good luck
2021-11-30 07:37:18 <ktprograms> psykose: Did you have to add /opt/eaglemode to your library search path?
2021-11-30 07:37:23 <psykose> nope
2021-11-30 07:38:00 <psykose> doesn't the script do that
2021-11-30 07:38:13 <ktprograms> Oh nevermind, /opt/eaglemode/bin/eaglemode is the binary not the shell script wrapper
2021-11-30 09:36:42 <ktprograms> How (or can it even be done?) do I use the bootstrap.sh from aports to just build the cross compiler but not the base packages?
2021-11-30 09:39:05 <ikke> It's not meant to build a generic cross-compiler 
2021-11-30 09:41:34 <ktprograms> ikke: How do I make a cross compiler then? x86_64 host, aarch64 target
2021-11-30 09:48:02 <psykose> if you really want a cross compiler (for musl gcc), you can get one here https://musl.cc/ or use https://github.com/richfelker/musl-cross-make used in the former
2021-11-30 09:49:32 <ikke> ktprograms: qemu-user + binfmt is an option 
2021-11-30 09:50:11 <psykose> the default page is i686-host cross-target, or the native ones which are host=target, the more at the bottom gives you more host- options if you want them
2021-11-30 09:50:23 <psykose> depending on what you are doing cross compiling is usually a worse option than just building on the target though
2021-11-30 09:59:35 <ktprograms> psykose: ikke: I'm trying to rewrite my aarch64 GHC instructions to use an Alpine host, so I can't native compile. I guess I'll use musl-cross-make since that's what I've already been using for my other aarch64 GHC instructions.
2021-11-30 10:00:11 <psykose> ah, makes sense
2021-11-30 12:31:56 <mps> re to last night talk about kernel: yes, I think -lts 'got' simpledrm too early maybe
2021-11-30 12:33:30 <mps> other notes: I think distros should ship usable and fast kernels, not everything enabled especially debugging, profiling and similar options
2021-11-30 12:36:09 <mps> something different now: what name is 'good' for linux kernel pkg in alpine for apple M1? linux-m1? linux-applem1? something else?
2021-11-30 12:36:31 <mps> linux-mone ;)
2021-11-30 12:47:30 <caskd> Has alpine decided yet which directory should be used for distributing s6-rc services?
2021-11-30 13:46:31 <skarnet> policy about that is far out in the future :)
2021-11-30 17:04:57 <Misthios> Linux-asillicon
2021-11-30 17:05:01 <Misthios> ?
2021-11-30 18:19:58 <mps> Misthios: sounds interesting
2021-11-30 18:21:19 <mps> or maybe enable it in next linux-edge, but this will need patches
2021-11-30 18:44:34 <Misthios> i think new kernel flavour would be better since most of those patches are not upstreamed yet?
2021-11-30 19:02:19 <mps> I have it is linux-rc in my local branch with patches
2021-11-30 19:02:33 <mps> s/is/as/
2021-11-30 19:02:33 <alpine-meetbot> mps meant to say: I have it as linux-rc in my local branch with patches
2021-11-30 19:26:21 <bl4ckb0ne> would it be possible to have a review for !24589 please
2021-11-30 23:43:24 <Hello71> ncopa, ikke: is #12767 fixed?