2021-07-01 00:44:42 <Ariadne> i am really hesitant to have all this bazel stuff in alpine, it has broken several times
2021-07-01 00:45:48 <minimal> anyone familiar with warning/error: "loadinternal: cannot find runtime/cgo"? Its only happening with 32bit archs (armv7/x86) and not 64bit ones (aarch64/x86_64)
2021-07-01 03:54:38 <jesec> Ariadne: IIRC it only has broken once, and it is the previous version. I think the community can benefit immensely from the availability of Bazel in Alpine, since upstream doesn’t distribute an Alpine binary. I am also working on the Debian package, and I am confident that I will be able to deal with any issue in a timely manner. 
2021-07-01 10:08:27 <markand> hey there
2021-07-01 10:08:48 <markand> I'd like to package a tool from raspberry pi that provide .elf files
2021-07-01 10:09:27 <markand> by default abuild will try to strip them and fails, I could add !strip in options= but that would mean other executables won't be stripped as well
2021-07-01 10:09:39 <markand> strip: Unable to recognise the format of the input file `./usr/share/rpiboot/msd/start.elf'
2021-07-01 10:21:40 <clandmeter> markand: use !strip
2021-07-01 10:21:53 <clandmeter> and if you like to strip the other files, do it manually
2021-07-01 10:23:10 <markand> okay
2021-07-01 10:58:58 <ikke> clandmeter: https://gitlab.alpinelinux.org/kdaudt/bolt
2021-07-01 10:59:38 <clandmeter> ok?
2021-07-01 11:00:35 <ikke> https://gitlab.alpinelinux.org/kdaudt/bolt#this-fork
2021-07-01 11:01:16 <ikke> For go projects that use bolt, which does not support mips64 and riscv64
2021-07-01 11:03:19 <clandmeter> ok, but a simple patch would not be ehough?
2021-07-01 11:03:48 <ikke> You cannot easily patch a dependency
2021-07-01 11:03:57 <ikke> and you have to do the same thing for multiple projects
2021-07-01 11:04:03 <ikke> now you just have to add a replace =>
2021-07-01 11:04:47 <ikke> (You could patch it by fetching the depency, patch it, and then use replace to point to a local path, but that's a lot more complicated)
2021-07-01 11:05:51 <clandmeter> you cannot use bbolt?
2021-07-01 11:05:57 <ikke> Not easily with just a replace
2021-07-01 11:06:06 <ikke> and, apparently, the bbolt quality is not that great
2021-07-01 11:06:48 <ikke> bbolt is a separate module, so you would need to replace all references in imports
2021-07-01 11:07:14 <ikke> (That's what I tried first)
2021-07-01 11:10:03 <clandmeter> I find those host depended files weird
2021-07-01 11:10:16 <clandmeter> it duplicated code
2021-07-01 11:10:24 <clandmeter> duplicates*
2021-07-01 11:54:57 <Ariadne> it would be nice, if pkgs.alpinelinux.org could list provides entries
2021-07-01 11:55:53 <Ariadne> for example, comparing provides=so:foo.so.1 vs so:foo.so.2 allows me to know if a security upgrade is worth pursuing easily
2021-07-01 12:46:21 <markand> it looks like firefox isn't installing a specific desktop file (GNOME/Mate are unable to show it in their prefered application settings)
2021-07-01 12:53:17 <Cogitri> Ah fun, seems like the OFTC bridge was restarted and kicked all Matrix users?
2021-07-01 12:59:10 <Ariadne> matrix :D
2021-07-01 13:11:45 <mps> forever? ;)
2021-07-01 13:25:26 <mercenary> one can but hope
2021-07-01 13:28:37 <minimal> anyone got suggestions why a Golang Alpine package builds fine on 64bit archs but gives "loadinternal: cannot find runtime/cgo" when building 32bit (x86 & armv7) archs?
2021-07-01 13:46:11 <ikke> minimal: have not run into that 
2021-07-01 13:46:24 <ikke> Is it a specific package? 
2021-07-01 13:59:48 <clandmeter> minimal: is that an actual error? i get that on lots of golang builds
2021-07-01 14:06:17 <minimal> clandmeter: not 100% sure, the build does continue.
2021-07-01 14:07:32 <minimal> ikke: step-cli (which I maintain). If it was a general CGO issue I'd expect x86_64 and aarch64 to also behave the same
2021-07-01 14:10:20 <ikke> Does it work though when you disable CGO? 
2021-07-01 14:13:23 <mps> upgrade perl will require rebuilding some modules (perl pkgs). anyone have idea how to find which ones must be rebuilt
2021-07-01 14:14:47 <ikke> ap revdeps perl-dev? 
2021-07-01 14:15:07 <mps> hmm, lets see
2021-07-01 14:15:07 <ikke> Or something like that 
2021-07-01 14:15:41 <minimal> ikke: the Makefile disables CGO by default
2021-07-01 14:16:08 <ikke> Ok
2021-07-01 14:16:13 <minimal> I'm spinning up a x86 VM now to check out if the package actually works
2021-07-01 14:16:37 <mps> no, it gives a modules which don't need rebuild in list
2021-07-01 14:17:45 <mps> if 'ap revdep so:libperl' could work :)
2021-07-01 14:18:33 <ikke> ap only looks at APKBUILDs
2021-07-01 14:18:54 <ikke> So it does not know about so: dependencies 
2021-07-01 14:19:38 <mps> yes, I know
2021-07-01 14:19:49 <ikke> apk info -r so:...
2021-07-01 14:20:43 <mps> so, upgrade perl and follow #alpine-commits and when something fails rebuild pkgs on which failed pkg depends
2021-07-01 14:21:41 <mps> ikke: tried this with info -r already. doesn't work
2021-07-01 14:27:51 <clandmeter> mps: apk list -d so:libperl.so
2021-07-01 14:32:03 <mps> clandmeter: aha, this gives some but not all
2021-07-01 14:35:30 <clandmeter> mps: you said you want to know what depends on libperl perl right?
2021-07-01 14:35:48 <clandmeter> s/perl//
2021-07-01 14:35:48 <alpine-meetbot> clandmeter meant to say: mps: you said you want to know what depends on lib perl right?
2021-07-01 14:35:58 <clandmeter> s/perl //
2021-07-01 14:35:58 <alpine-meetbot> clandmeter meant to say: mps: you said you want to know what depends on lib right?
2021-07-01 14:36:03 <clandmeter> :)
2021-07-01 14:37:12 <mps> right, but after looking on result I see this is not enough
2021-07-01 14:37:37 <clandmeter> its the only packages that depend on libperl
2021-07-01 14:37:49 <mps> yes
2021-07-01 14:38:26 <mps> but some other also needs rebuild
2021-07-01 14:39:02 <clandmeter> maybe anything that depends on perl-dev
2021-07-01 14:40:15 <mps> then I got a lot of pkgs, and most of then don't need rebuild
2021-07-01 14:40:38 <clandmeter> so what is the definition of a rebuild pkg?
2021-07-01 14:40:44 <mps> maybe ncopa have experience with this
2021-07-01 14:40:52 <clandmeter> yes he has 
2021-07-01 14:41:01 <clandmeter> i remember he  did it before
2021-07-01 14:41:18 <mps> clandmeter: rebuild with upgraded perl major version
2021-07-01 14:42:20 <ikke> Is timlegge here? 
2021-07-01 14:43:26 <mps> he is on #perl waiting for him to say something about this
2021-07-01 14:43:45 <clandmeter> who? ncopa?
2021-07-01 14:43:53 <mps> no, timlegge 
2021-07-01 14:48:06 <clandmeter> mps: what about revdep perl-dev and only select non noarch?
2021-07-01 14:49:19 <mps> hmm, could be solution
2021-07-01 14:50:02 <mps> you mean rule out noarch?
2021-07-01 14:50:03 <minimal> clandmeter: tested the package on x86 and it works fine - so that "error" is indeed misleading. Strange it only seems to appear on 32bit builds
2021-07-01 14:50:17 <clandmeter> mps: yes
2021-07-01 14:50:37 <Hello71> aiui perl rebuild is complicated
2021-07-01 14:50:42 <Hello71> gentoo has a whole script for it
2021-07-01 14:51:03 <Hello71> https://github.com/gentoo-perl/perl-cleaner/blob/master/perl-cleaner
2021-07-01 14:51:27 <mps> sounds as good idea
2021-07-01 14:52:47 <Hello71> although i think much of the complexity is due to virtual packages
2021-07-01 14:53:09 <Hello71> i think it's libperl plus basically everything in /usr/**/perl*
2021-07-01 14:55:48 <mps> no, it is modules/pkgs which have so libs (I think)
2021-07-01 15:01:46 <clandmeter> mps: https://tpaste.us/dPjy maybe this? its for main
2021-07-01 15:08:35 <mps> clandmeter: nice, looks like it is. the modules I detected 'by hand' are there
2021-07-01 15:08:53 <clandmeter> https://tpaste.us/4104
2021-07-01 15:08:56 <clandmeter> all repos
2021-07-01 15:10:32 <mps> hmm, not correct, some in the list don't needs rebuild
2021-07-01 15:12:08 <mps> how did you got this list
2021-07-01 15:13:35 <clandmeter> https://tpaste.us/MzMm
2021-07-01 15:14:30 <mps> thanks
2021-07-01 15:19:03 <mps> clandmeter: this script looks very good, just add bump pkgrel and 'git add . ', git commit msg for all this
2021-07-01 15:19:25 <mps> it will not hurt to rebuild all of them
2021-07-01 16:33:49 <handlerug> hi, is this the right channel to ask about aports?
2021-07-01 16:36:30 <handlerug> there's a package for Transmission BT client: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/transmission/APKBUILD, and I wanted to make it also build the Qt version
2021-07-01 16:37:15 <handlerug> however, that would probably require making it either a separate package or making the main one bring in Qt as well, which is not good
2021-07-01 16:42:46 <superduck> handlerug: probably want to define a subpackage in the transmission package so that transmission-gui or transmission-qt gets built at the same time
2021-07-01 16:58:12 <xordspar0> handlerug: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#subpackages
2021-07-01 16:59:43 <xordspar0> Example: https://git.alpinelinux.org/aports/tree/community/kodi/APKBUILD#n200
2021-07-01 17:25:47 <handlerug> thanks superduck xordspar0! I'll try making one tomorrow
2021-07-01 20:53:05 <clandmeter> mps: pong
2021-07-01 20:59:21 <mps> clandmeter: ping :)
2021-07-01 20:59:44 <clandmeter> did you boot riscv64 without foreign blobs? 
2021-07-01 20:59:55 <mps> in qemu?
2021-07-01 21:00:02 <clandmeter> yes
2021-07-01 21:00:08 <clandmeter> or on metal
2021-07-01 21:00:18 <clandmeter> but i guess you dont have metal
2021-07-01 21:00:27 <mps> https://dev.alpinelinux.org/~mps/riscv64/
2021-07-01 21:00:49 <mps> script to create qemu img and to start it
2021-07-01 21:01:20 <mps> no, I don't have riscv machine, and don't plannig to buy for now
2021-07-01 21:02:20 <mps> and the kernel is there, dev.a.o/~mps
2021-07-01 21:02:37 <mps> hah, algitbot don't know this
2021-07-01 21:02:57 <mps> dev.a.o ~/mps/riscv64
2021-07-01 21:04:14 <clandmeter> no initramfs?
2021-07-01 21:04:27 <mps> no
2021-07-01 21:04:52 <mps> how can I create initramfs on host for guest
2021-07-01 21:05:07 <mps> ok, I know but this is not yet finished
2021-07-01 21:06:00 <mps> maybe you noticed that I made u-boot qemu for riscv64 and also pushed opensbi to aports
2021-07-01 21:06:14 <mps> that is with what I 'play' when have time
2021-07-01 21:06:50 <mps> but booting with u-boot in qemu still doesn't work for me
2021-07-01 22:17:46 <Ariadne> rvs wants to do a call re: riscv64 at some point so we can kind of work on a more concrete plan for the port
2021-07-01 23:27:33 <rhatr> work).
2021-07-01 23:27:33 <rhatr> clandmeter: puretryout: Ariadne: I was wondering if 4 of us (plus whoever else maybe interested) could jump on a quick call and talk about next steps when it comes to RISCV-64. It seems I'm getting stuck in a few places upstreaming my changes and I would love to hear your opinions. Also it would be great to break things down into areas and knowing who is working on what so I can ping the right ppl when needed (AND not do double 
2021-07-01 23:28:27 <Ariadne> seems like a reasonable idea, but they probably wont be around until later
2021-07-01 23:29:55 <rhatr> Ariadne: understood -- now that I'm on IRCCloud at least I don't have to worry about missing messages -- so whenever they come back online
2021-07-01 23:30:16 <Ariadne> i think the always on mode is only working on the subscription tho
2021-07-01 23:30:43 <rhatr> Ariadne: I get it free for 7 days (and I'll probably pay if it works well)
2021-07-01 23:30:51 <Ariadne> o
2021-07-01 23:30:58 <Ariadne> works p great for me
2021-07-02 06:51:08 <mps> rhatr: could you test kernel from testing/linux-edge on real hardware, i.e. does it boot at all
2021-07-02 07:02:39 <clandmeter> mps: should opensbi be stripped?
2021-07-02 07:09:15 <mps> clandmeter: not sure, at least till we check it works
2021-07-02 07:09:25 <mps> actually it works
2021-07-02 07:09:37 <mps> so maybe you are right
2021-07-02 07:10:37 <mps> will look after business meeting and daily work
2021-07-02 07:12:06 <PureTryOut> rhatr: sounds good but note that I don't do much for riscv64 other than seeing what fails on the builderse and if it has to be disabled or if I can quickly fix it. I have no technical knowledge related to riscv64 particularly so I don't know how useful it would be to have me in that call
2021-07-02 07:12:54 <PureTryOut> As for not missing IRC messages, if you want to do it for free you could consider Matrix
2021-07-02 09:12:33 <adhawkins> Getting a build error for my recent MR on s390
2021-07-02 09:12:33 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/427919
2021-07-02 09:14:15 <ikke> Did you retry the job
2021-07-02 09:15:30 <Sheila> I would be very surprised if there weren't, considering the `!s390x` in $arch for that package.
2021-07-02 09:18:48 <adhawkins> There wasn't an issue when I did an update to that package yesterday.
2021-07-02 09:20:12 <Sheila> yes, but the particular error here isn't with the package. given that the package is specified to not do s390x, however, I don't see any point in retrying the job.
2021-07-02 09:55:28 <clandmeter> rhatr: sure let me know which time
2021-07-02 10:10:20 <adhawkins> Sheila: It's passed now...odd.
2021-07-02 10:11:15 <ikke> This is just an ephemeral issue
2021-07-02 10:12:34 <adhawkins> That's what it looked like to me ikke, but thought I'd raise it here in case it pointed to an issue with the builder.
2021-07-02 10:55:21 <mps> hmm, 3.11-stable main is still supported, I missed that
2021-07-02 10:55:53 <ikke> yes
2021-07-02 10:56:29 <mps> have to backport dovecot to it also
2021-07-02 14:13:29 <adhawkins> Are there any issues with Python in edge at the moment?
2021-07-02 14:13:40 <adhawkins> Just built a container using borg and emborg, and neither will run.
2021-07-02 14:14:06 <adhawkins> https://paste.debian.net/1203149/
2021-07-02 14:14:56 <ikke> Edge uses python 3.9
2021-07-02 14:15:25 <adhawkins> Ah, looks like I've installed 3.13, with some packages from edge.
2021-07-02 14:15:32 <adhawkins> Is that likely to be the cause?
2021-07-02 14:15:36 <ikke> Yes
2021-07-02 14:15:49 <ikke> That's not supported 
2021-07-02 14:16:02 <adhawkins> Thanks ikke, trying using alpine:edge as the base of the container.
2021-07-02 14:16:31 <ikke> (except for static applications) 
2021-07-02 14:16:58 <adhawkins> That's better. Thanks ikke. Every day is a school day :)
2021-07-02 14:20:49 <adhawkins> I run this when I build the container:
2021-07-02 14:20:50 <adhawkins> apk add --no-cache -X https://dl-cdn.alpinelinux.org/alpine/edge/community webhook emborg openssh-client ssmtp mailx
2021-07-02 14:21:10 <adhawkins> However, it's installing emborg 1.18.1. That URL has v1.22 of emborg available.
2021-07-02 14:21:24 <adhawkins> Within the container, if I do an 'apk add emborg' it doesn't get anything else, even after an apk update
2021-07-02 14:21:47 <ikke> apk policy emborg
2021-07-02 14:22:09 <adhawkins> emborg policy:
2021-07-02 14:22:09 <adhawkins>     https://dl-cdn.alpinelinux.org/alpine/edge/community
2021-07-02 14:22:09 <adhawkins>     lib/apk/db/installed
2021-07-02 14:22:09 <adhawkins>   1.22-r0:
2021-07-02 14:22:25 <ikke> It says you hedge 1.22
2021-07-02 14:22:30 <adhawkins> Yes...odd.
2021-07-02 14:22:31 <ikke> have*
2021-07-02 14:23:10 <adhawkins>  /usr/bin/emborg is 1.18.1 though...odd.
2021-07-02 14:25:53 <adhawkins> Don't suppose you have a means of trying it ikke?
2021-07-02 14:25:58 <adhawkins> Can't work out what I've done wrong...
2021-07-02 14:27:13 <ikke> adhawkins: in a bit 
2021-07-02 14:27:28 <adhawkins> Thanks.
2021-07-02 14:43:17 <adhawkins> Ok, just had the APKBUILD file run the built package during 'check' and it's reporting the correct version as far as I can tell.
2021-07-02 14:49:31 <adhawkins> Ok, this makes no sense. During container build, I have it do 'emborg --version', which prints the correct version. However, if I then docker exec sh in that container, and run emborg --version, I get the wrong one!
2021-07-02 15:19:00 <ikke> adhawkins: 
2021-07-02 15:19:02 <ikke> / # emborg --version
2021-07-02 15:19:04 <ikke> 1.22.0 (2021-06-21)
2021-07-02 15:19:13 <ikke> But that's without a docker file, just installing emborg in docker
2021-07-02 15:38:32 <adhawkins> Yes. I think the issue is with docker. When I build the container, it reports the version correctly. However, when I run the container up and connect into it, the version is wrong.
2021-07-02 15:38:38 <adhawkins> Just trying to work out what the hell is going on!
2021-07-02 15:39:13 <adhawkins> Ok. I've just rebuilt the container, and modified the 'entrypoint.sh' file so I can be sure I'm running the container that's being built. As far as I can see, it is.
2021-07-02 15:39:22 <adhawkins> But it still reports the 'wrong' emborg version!
2021-07-02 15:39:37 <adhawkins> If I look at the contents of /usr/bin/emborg, it references the correct version...
2021-07-02 15:41:02 <adhawkins> Ah, the container seems to have a .local directory in root's home directory. This is a bind mount, so survives container rebuilds. Let me get rid of that. It has some emborg files in it.
2021-07-02 15:41:43 <adhawkins> Bingo...
2021-07-02 15:43:00 <adhawkins> So obviously python was picking up those 'local' files before the 'real' ones...
2021-07-02 15:47:22 <ikke> heh
2021-07-02 16:38:07 <rhatr> mps: I can bet $5 it won't boot -- in fact what to do about the kernel on actual riscv64 SBC is one of the things I wanted to discuss on the RISCv64 sync up with whoever is interested. Seems like for now it is just clandmeter: and PureTryOut: (but maybe there will be others). I was thinking to do it next week sometime in the evening (EU) morning (California). 
2021-07-02 16:39:02 <rhatr> mps: where is the opensbi in alpine? are you building it somehow?
2021-07-02 16:40:35 <rhatr> clandmeter: for now I'm thinking Mon 6PM CET -- will this work for you?
2021-07-02 16:45:45 <mps> rhatr: testing/opensbi in aports
2021-07-02 16:46:04 <mps> and I have it built in dev lxc
2021-07-02 16:46:42 <rhatr> mps: ah! cool -- great to know -- I'm building it separately for EVE -- but would love to switch to yours if that works
2021-07-02 16:46:50 <mps> rhatr: -virt flavor of linux-edge kernel works fine in qemu
2021-07-02 16:47:17 <rhatr> linux-edge is still 5.10 tho, right?
2021-07-02 16:47:40 <mps> no, 5.12 and soon will be 5.13
2021-07-02 16:48:08 <ikke> linux-lts is 5.10
2021-07-02 16:49:09 <mps> and opensbi works but u-boot can't load kernel properly in qemu
2021-07-02 16:49:42 <rhatr> mps: when do you think we can switch to 5.13 -- that has a much higher chance of booting on both of my SBCc (but still requires a few custom patches here and there)
2021-07-02 16:50:29 <mps> I'm waiting for 5.13.1 because 5.13.0 is buggy, hope it will be released in a few days
2021-07-02 16:50:57 <mps> don't want to push 5.13.0 because it could break some users systems
2021-07-02 16:54:53 <rhatr> makes sense -- but 5.13.x is probably the minimum we can have for the actual SBCs -- I'll try to do a local build based on 5.13 over the weekend
2021-07-02 16:56:24 <mps> I'm running 5.13.0 on my arm64 chromebooks but had to patch it to work correctly
2021-07-02 16:56:46 <rhatr> mps: "work correctly" as in?
2021-07-02 16:59:34 <mps> well, usable, no serious bugs or crashes
2021-07-02 17:00:44 <mps> rhatr: here https://git.alpinelinux.org/aports/tree/testing/linux-elm
2021-07-02 17:01:03 <mps> and here https://git.alpinelinux.org/aports/tree/testing/linux-gru
2021-07-02 17:01:16 <rhatr> will take a look
2021-07-02 17:01:30 <mps> these are for arm64
2021-07-02 17:01:57 <mps> riscv64 is here https://git.alpinelinux.org/aports/tree/testing/linux-edge
2021-07-02 18:30:39 <minimal> anyone here familiar with the inner working of nlplug-findfs?
2021-07-02 18:31:19 <rhatr> minimal: shoot
2021-07-02 18:31:33 <rhatr> not an expert but done some hacking around it
2021-07-02 18:33:04 <minimal> trying to work out why its not mounting a LUKS partition - with "-d" I see events related to the partition zoom past but it never tries to actually unlock/mount it.
2021-07-02 18:34:52 <minimal> I should point out that this is remote-unlocking functionality I'm working on - so I've modified the initramfs-init to setup network interface, run dropbear daemon and I'm sshing into the machine as user root, who's shell (in /etc/passwd) has already been modified to run a shellscript which calls nlplug-findfs in the same as the usual init does
2021-07-02 18:42:59 <rhatr> sorry -- never had to work LUKS -- I am useless for that
2021-07-02 18:48:12 <minimal> rhatr: well it doesn't appear to have gotten as far as calling the start_cryptsetup function, it looks like its in the mdev event handling, events scroll past and then it shows a timed out (5 seconds) message then goes through the same events again, and so on
2021-07-02 18:49:41 <minimal> after seeing the following (in debug output) it should then call start_cryptsetup:
2021-07-02 18:51:06 <rhatr> well that's what I'm saying -- LUKS (kernel modules part) maybe messing things up
2021-07-02 18:51:19 <minimal> searchdev: dev='/dev/sda2' type='crypto_LUKS' label='(null)' uuid='bf8b3c8e-3d93-4237-aade-39354aca1662'
2021-07-02 18:52:39 <minimal> nope, kernel modules are all loaded. It works (with exactly the same disk layout and config if I disable the remote-unlock stuff) as expected
2021-07-02 19:02:07 <minimal> rhatr: think I'm going to have to pepper the code with debug statements to figure out what's going on
2021-07-02 19:22:43 <Hello71> there's an aports issue about this
2021-07-02 19:22:47 <Hello71> although i think for lvm
2021-07-02 19:24:10 <minimal> Hello71: I remember seeing something in the past regarding LVM and (I think) ZFS issues with nlplug-findfs. However this works fine normally for LUKS, its only when I'm testing/using the remote-unlock script that I'm working on that there's an issue with LUKS
2021-07-02 19:24:45 <superduck> quit
2021-07-02 19:40:18 <PureTryOut> riscv64 community repo is 99% completed, so close!
2021-07-02 19:42:00 <clandmeter> build/build-edge-riscv64 6/49
2021-07-02 19:42:38 <PureTryOut> 49 packages left?
2021-07-02 19:43:04 <clandmeter> 43
2021-07-02 19:44:32 <PureTryOut> Oh yeah ofc
2021-07-02 19:54:54 <Ariadne> Cogitri: what are your opinions on dropping official firefox branding?
2021-07-02 19:55:09 <Ariadne> i upgraded firefox today on my alpine desktop, and was greeted with an ad
2021-07-02 19:55:20 <Ariadne> i would like to purge this advertising crap
2021-07-02 20:12:57 <c705> Ariadne: thoughts about packaging icecat?
2021-07-02 20:13:18 <c705> gnu fork of firefox without all the telemetry crap
2021-07-02 20:46:05 <clandmeter> mps: ping
2021-07-02 20:47:00 <mps> clandmeter: pong
2021-07-02 20:48:06 <clandmeter> https://tpaste.us/ypax
2021-07-02 20:48:32 <clandmeter> any idea whats going on?
2021-07-02 20:49:30 <clandmeter> btw, iiuc opensbi is part of qemu?
2021-07-02 20:49:49 <mps> clandmeter: yes, it is default -bios option
2021-07-02 20:50:18 <clandmeter> but i dont have to provide a firmware?
2021-07-02 20:50:23 <clandmeter> its already part of qemu?
2021-07-02 20:50:29 <mps> yes
2021-07-02 20:50:39 <clandmeter> so why are we packaging it?
2021-07-02 20:51:08 <mps> if you use '-bios u-boot.bin' the it will skip opensbi in qemu
2021-07-02 20:52:04 <mps> I hope we can use it with u-boot.bin as -kernel option
2021-07-02 20:52:29 <clandmeter> do you have an idea why it does not boot for me?
2021-07-02 20:53:38 <mps> I'll check tomorrow
2021-07-02 20:57:50 <mps> looks like something with modloop
2021-07-02 20:59:55 <mps> ah, no. something else
2021-07-02 21:00:18 <clandmeter> raising smp makes it boot
2021-07-02 21:01:22 <mps> ah, what was you qemu command line
2021-07-02 21:01:41 <mps> my testing machine is down now
2021-07-02 21:02:49 <clandmeter> qemu-system-riscv64 -M virt -smp 8 -m 1G -kernel vmlinuz-edge-virt -initrd initramfs-edge-virt -append modloop=https://dev.alpinelinux.org/~clandmeter/netboot/edge/releases/riscv64/netboot/modloop-edge-virt alpine_repo=https://dev.alpinelinux.org/~clandmeter/packages/riscv64/edge/main -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -nographic
2021-07-02 21:03:22 <clandmeter> mps: please enable xz compression for kernel
2021-07-02 21:03:35 <mps> iirc I got it booting even with -smp 2, but usually use -smp 5
2021-07-02 21:03:46 <clandmeter> [  148.889491] Filesystem uses "xz" compression. This is not supported
2021-07-02 21:03:52 <mps> hah
2021-07-02 21:04:00 <clandmeter> modloop compression
2021-07-02 21:04:06 <mps> how did I missed that?
2021-07-02 21:04:16 <clandmeter> too much red wine
2021-07-02 21:04:54 <mps> no, on these too hot days I don't drink wine (just a little :) )
2021-07-02 21:05:06 <clandmeter> i think netboot is broken
2021-07-02 21:05:21 <clandmeter> it does not include the ca-cert bundle
2021-07-02 21:06:21 <clandmeter> i also wonder why -nic user,model=virtio-net-pci does not work
2021-07-02 21:06:46 <mps> I don't have much experience in creating netboot and initrams for network booting
2021-07-02 21:07:07 <clandmeter> its nothing special
2021-07-02 21:07:40 <clandmeter> it just adds network modules and dhcp script
2021-07-02 21:07:59 <clandmeter> just enough to get ip and fetch pkgs from repo
2021-07-02 21:08:21 <mps> -netdev user,id=n1 -device virtio-net-pci,netdev=n1
2021-07-02 21:08:44 <clandmeter> yes
2021-07-02 21:08:52 <clandmeter> but according the docs, it should be the same
2021-07-02 21:09:15 <clandmeter> https://wiki.qemu.org/Documentation/Networking#The_-nic_option
2021-07-02 21:10:57 <mps> yes, but it doesn't work
2021-07-02 21:20:49 <mps> clandmeter: looking on riscv virt I see CONFIG_RD_XZ=y
2021-07-02 21:21:21 <clandmeter> Yes
2021-07-02 21:21:29 <clandmeter> But modloop
2021-07-02 21:21:41 <mps> CONFIG_SQUASHFS_XZ is not set
2021-07-02 21:21:45 <mps> I see
2021-07-02 21:21:47 <clandmeter> Yup
2021-07-02 21:22:21 <mps> ok, tomorrow will upgrade to 5.12.14 and enable this
2021-07-02 21:22:39 <clandmeter> Thx
2021-07-02 21:22:44 <mps> now is too late and I'm already somewhat tired
2021-07-02 21:23:01 <clandmeter> Makes two of us
2021-07-02 21:23:11 <mps> :)
2021-07-02 21:23:52 <mps> if I'm BDFL or ikke I would say 'fill a issue' :D
2021-07-02 21:24:17 <ikke> You do not need to be BDFL for that :)
2021-07-02 21:24:17 <mps> though ikke don't do that too often
2021-07-02 22:43:14 <rhatr> clandmeter: ping! ;-)
2021-07-02 22:48:35 <Hello71> fwiw zstd added auto block splitting, i think we might consider it for 3.15
2021-07-02 22:48:45 <Hello71> for initramfs
2021-07-03 00:15:02 <minimal> Hello71: sorted my nlplug-findfs LUKS issue..........after peppering lots of debug lines throughout the nlplug-findfs code I spotted that the quotes I'd mistakenly put about part of the arguments passed to it meant it was treading 1 parameters as a single string and so not matching partition UUID. Doh! Quotes removed and its working as expected now.
2021-07-03 00:15:21 <minimal> s/1/2g
2021-07-03 00:15:21 <alpine-meetbot> minimal meant to say: Hello72g: sorted my nlplug-findfs LUKS issue..........after peppering lots of debug lines throughout the nlplug-findfs code I spotted that the quotes I'd mistakenly put about part of the arguments passed to it meant it was treading 1 parameters as a single string and so not matching partition UUID. Doh! Quotes removed and its working as expected now.
2021-07-03 00:15:32 <minimal> s/1/2/g
2021-07-03 00:15:32 <alpine-meetbot> minimal meant to say: Hello72g: sorted my nlplug-findfs LUKS issue..........after peppering lots of debug lines throughout the nlplug-findfs code I spotted that the quotes I'd mistakenly put about part of the arguments passed to it meant it was treading 2 parameters as a single string and so not matching partition UUID. Doh! Quotes removed and its working as expected now.
2021-07-03 07:11:43 <mps> good morning
2021-07-03 07:12:26 <mps> clandmeter: do we need something else in riscv kernel beside xz compression for squashfs
2021-07-03 07:59:04 <mps> clandmeter: riscv kernels 5.13.0 are in my rv64 lxc in /home/mps/packages/testing/riscv64/ dir 
2021-07-03 08:15:05 <mps> clandmeter: https://tpaste.us/YEnP
2021-07-03 08:15:50 <mps> now have to learn how to create efi boot partition and use it with u-boot (which will take time for me)
2021-07-03 09:01:35 <clandmeter> mps: morning
2021-07-03 09:01:46 <clandmeter> rhatr: pong
2021-07-03 09:03:44 <clandmeter> mps: did you set 8 cpu as limit?
2021-07-03 09:09:51 <mps> no, I set 5
2021-07-03 09:15:13 <mps> clandmeter: I don't think that number of cpus is important, but I could be wrong
2021-07-03 09:23:57 <clandmeter> ikke: around?
2021-07-03 09:53:21 <mps> just pushed linux-edge 5.13.0, but it is not yet tested much so anyone who want to upgrade please keep rescue kernel 'handy'
2021-07-03 09:54:30 <ikke> clandmeter: now I am
2021-07-03 10:05:25 <rdavidson> I have successfully built some custom packages following the directions at https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package, and this does create a local "packages" directory tree that I can use as a repository. However, there's a lot of manual steps involved.
2021-07-03 10:07:45 <rdavidson> Is there any guidance for how to set up an "automatic" repository builder, so that I can simply have my own aports-like git repository, and run a command and get a built and signed apk repository out the other end? (preferably something that i can then serve from nginx/etc)
2021-07-03 10:08:35 <ikke> rdavidson: we use buildrepo (+aports-build) to automate it
2021-07-03 10:10:50 <ikke> rdavidson: do you want to build a single package, or a whole tree of packages?
2021-07-03 10:10:56 <yyp> A simpler thing would be to set REPO_DESTDIR= in abuild.conf to the directory served by nginx and then `abuild -r` all packages in a script
2021-07-03 10:11:25 <rdavidson> a whole tree of packages. but, like, only about 10 packages total :P
2021-07-03 10:12:15 <ikke> rdavidson: buildrepo will try to build an antire repo
2021-07-03 10:12:32 <ikke> but, if you install lua-aports, you can do something like:
2021-07-03 10:14:18 <ikke> for pkg in $(ap builddirs pkg1 pkg2 pkg3); do { cd "$pkgdir" && abuild -r; } || break; done
2021-07-03 10:14:44 <rdavidson> specifically i want to do something kind of like an ubuntu PPA, where I have an aports-like tree that just contains my custom packages. and then the repositories list on the end result would contain the main repo plus my custom one.
2021-07-03 10:15:46 <yyp> rdavidson: you can add /home/user/packages/<repository> to /etc/apk/repositories locally and it will work like a PPA
2021-07-03 10:15:51 <ikke> rdavidson: you can just have a custom repo with your custom packages
2021-07-03 10:15:52 <ikke> yes
2021-07-03 10:16:01 <ikke> as long as you make sure the dependencies match
2021-07-03 10:16:55 <rdavidson> yyp: sure, but i need to instead add https://myserver.com/project/packages/<repository> :P which means first i need to create that repository in an automated way. which i think ikke has just told me how to do.
2021-07-03 10:17:37 <ikke> rdavidson: if you have your packages in a dedicated directory, buildrepo will automate the snippet that I gave
2021-07-03 10:17:48 <rdavidson> excellent
2021-07-03 10:18:54 <ikke> and it will only build packages that have been updated
2021-07-03 10:25:00 <rdavidson> i need to build for armv7, so i'm thinking i'll see if i can use AWS's graviton ec2 servers to automate this.
2021-07-03 10:34:38 <rdavidson> or, hm, i might be able to just cross-compile
2021-07-03 10:34:43 <rdavidson> anyway, thanks, ikke
2021-07-03 10:35:07 <ikke> note that we do not have generic cross-compilers, so you would have to setup something yourself
2021-07-03 10:35:56 <yyp> musl.cc works fine as a cross-compiler
2021-07-03 10:44:29 <ikke> the site does not load for me atm
2021-07-03 10:45:03 <yyp> works for me
2021-07-03 10:45:06 <yyp> 
ACTION shrugs

2021-07-03 12:15:32 <caskd> Is this true in apk versioning? 2021.07.03.01-r0 > 2021.06.01.03-r0
2021-07-03 12:15:51 <caskd> if not then apk prefers the latter over the former for some reason
2021-07-03 12:17:51 <ikke> caskd: you can use apk version -t 2021.07.03.01-r0 2021.06.01.03-r0
2021-07-03 12:17:53 <mps> apk version -t 
2021-07-03 12:17:58 <caskd> oh
2021-07-03 12:18:12 <mps> huh, again
2021-07-03 12:18:15 <mps> :)
2021-07-03 12:19:42 <caskd> i've got some weird APKINDEX behaviour going on
2021-07-03 12:19:55 <caskd> gonna look into it
2021-07-03 12:21:55 <z3ntu> Can someone please review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22619 ? CI is read because it just times out for arm*
2021-07-03 12:23:25 <ikke> any idea why it times out?
2021-07-03 12:24:20 <yyp> Looks like ceph is too big for it to handle
2021-07-03 12:25:45 <yyp> nevermind, it's not ceph's fault
2021-07-03 12:26:06 <z3ntu> Too many packages are getting rebuilt I guess
2021-07-03 12:26:24 <yyp> Yeah
2021-07-03 12:32:10 <yyp> I wonder why x86_64 build took 1 hour, but aarch64 didn't finish in 3 hours
2021-07-03 12:34:56 <ikke> I guess, even though the arm host has lots of cores, they all run on the same host
2021-07-03 13:49:52 <timlegge> mps: ikke: mostly its any perl package that is arch dependent usually it contains XS code or enbedded C
2021-07-03 13:50:26 <timlegge> s/enbedded/embedded/
2021-07-03 13:50:26 <alpine-meetbot> timlegge meant to say: mps: ikke: mostly its any perl package that is arch dependent usually it contains XS code or embedded C
2021-07-03 13:52:28 <ikke> so anything that depends on perl and is not arch="all"?
2021-07-03 13:52:48 <mps> timlegge: yes, I know this, the problem for me is/was to find these packages
2021-07-03 13:53:12 <mps> and clandmeter posted nice script to find them
2021-07-03 13:54:24 <mps> but I will wait for ncopa to come back and ask him because he did this earlier and maybe have something better as solution
2021-07-03 13:55:20 <mps> ikke: anything what depends on perl-dev
2021-07-03 13:55:32 <mps> makedepends*
2021-07-03 14:00:15 <Hello71> fwiw it looks plausible to me. gentoo doesn't have "-dev" so cannot do this
2021-07-03 14:00:44 <Hello71> arch and gentoo use versioned vendor_perl so need to rebuild everything
2021-07-03 14:00:52 <ikke> ap revdeps perl-dev
2021-07-03 14:00:54 <Hello71> not sure why, maybe just for added safety
2021-07-03 14:01:06 <ikke> I already mentioned it, but you said it was not good
2021-07-03 14:16:43 <mps> ikke: https://tpaste.us/vgMQ
2021-07-03 14:17:09 <mps> this is my modification to clandmeters script
2021-07-03 14:32:45 <timlegge> finding them is a bit of a problem.  Should probably update the APKBUILD template for perl packages with needsrebuild or something similar.
2021-07-03 14:33:55 <timlegge> I wonder if iterating through the depend and finding every package that has a non perl- depends would find most of them?
2021-07-03 14:33:55 <mps> sounds like a good idea
2021-07-03 14:35:17 <timlegge> example perl-xml-canonicalizexml/APKBUILD:makedepends="libxml2-dev perl-dev"
2021-07-03 14:37:56 <mps> makedepends="perl-dev" in aports/main/perl-test-leaktrace/APKBUILD
2021-07-03 14:38:17 <mps> nothing except perl-dev but this pkg must be rebuilt
2021-07-03 14:38:28 <timlegge> looking
2021-07-03 14:39:05 <mps> main/perl-html-parser also
2021-07-03 14:42:02 <timlegge> yes, they both contain xs code 
2021-07-03 14:44:21 <timlegge> based on perl-dev looks to be valid - that being said it is likely used in places where it is not required
2021-07-03 14:51:13 <mps> that is what I also think
2021-07-03 14:53:58 <ikke> Then I guess we should clean that up? 
2021-07-03 14:55:40 <timlegge> i am starting to look at my packages - thinking of removing perl-dev from all locally and then itterating to see which break
2021-07-03 14:57:10 <mps> side note, I think we don't need -doc subpkg for most of perl pkgs, docs are included in most base pkgs
2021-07-03 15:23:38 <Hello71> Cogitri: do you want some help with llvm12? what is the progress? is it basically build !20759 and see where it explodes?
2021-07-03 17:37:39 <tomalok> anyone here have the secret sauce for booting the aarch64 virtual iso with UEFI bios (via the files in the ovmf apk)?
2021-07-03 17:38:54 <ikke> hmm, I guess we still use legacy boot
2021-07-03 17:39:05 <ikke> let me check
2021-07-03 17:40:05 <ikke> no, we use eufi
2021-07-03 17:40:20 <ikke> efivarfs on /sys/firmware/efi/efivars
2021-07-03 17:41:23 <ikke> tomalok: honestly, we do not do anything special
2021-07-03 17:42:03 <ikke> snippet: -bios /usr/share/ovmf/bios.bin -display none -serial pty -cdrom /var/lib/iso/alpine-virt-3.13.5-aarch64.iso
2021-07-03 17:43:40 <tomalok> @ikke thanks -- it's very possible i was overcomplicating things
2021-07-03 17:44:20 <ikke> I use qemu-openrc
2021-07-03 17:45:06 <mps> tomalok: https://arvanta.net/alpine/install-aarch64-qemu/
2021-07-03 17:45:22 <mps> somewhat outdated but you will get idea
2021-07-03 17:46:12 <tomalok> using macos as the host os at home, but hopefully will divine the packer qemu builder magic to work wherever qemu lives
2021-07-03 17:47:06 <mps> macos on M1 or ?
2021-07-03 17:47:27 <tomalok> M1 on one, intel on the other
2021-07-03 17:48:11 <mps> for M1 you will need to build qemu with HVM patches to get near 'bare metal' performance
2021-07-03 17:50:49 <tomalok> don't need performance as much as i need it to just work :) using qemu 6.0 from brew
2021-07-03 18:20:02 <minimal> tomalok: I've tested UEFI aarch64 with QEMU in the past using the disk image produced by my script here: https://github.com/dermotbradley/create-alpine-disk-image
2021-07-03 18:20:32 <ikke> our CI is running on aarch64 qemu vms
2021-07-03 18:21:23 <minimal> to run it you need to pass QEMU options: "-drive if=pflash,format=raw,readonly,file=/usr/share/AAVMF/AAVMF_CODE.fd -drive if=pflash,format=raw,file=./${FILE}-AAVMF_VARS.fd"
2021-07-03 18:21:57 <minimal> OVMF is UEFI for x86_64, AAVMF is for aarch64
2021-07-03 18:31:05 <tomalok> minimal - thanks...  named a little differently in the ovmf x86_64 and aarch64 packages - https://pkgs.alpinelinux.org/contents?branch=v3.14&name=ovmf&arch=aarch64&repo=community vs https://pkgs.alpinelinux.org/contents?file=&path=&name=ovmf&branch=v3.14&repo=community&arch=x86_64
2021-07-03 18:31:11 <minimal> tomalok: actually the OVMF / AAVMF separate naming is a Debian thing (contained in packages ovmf and qemu-efi-aarch64 respectively). Don't see any AAVMF files for Alpine, not sure if there is such a separation
2021-07-03 18:31:25 <tomalok> (also thanks mps) stepping away for now, may try some of these later
2021-07-03 18:31:31 <ikke> we use the ovmf file 
2021-07-03 18:33:17 <minimal> ikke: so on an x86_64 machine when you want to run a x86_64 UEFI and also to run a aarch64 UEFI machine what do you use? On Debian you install both ovmf and qemu-efi-aarch64 packages and use the OVMF and AAVMF references respectively when running the 2 VMs
2021-07-03 18:34:50 <mps> minimal: by dirs, aarch64/OVMF and x86_64/OVMF ?
2021-07-03 18:35:26 <minimal> mps: but can you install an aarch64 ovmf package on an x86_64 host machine?
2021-07-03 18:35:51 <mps> yes, wget && tar ;)
2021-07-03 18:36:28 <minimal> mps: yes you can install a square peg in a round hole with a big enough hammer and brute force ;-)
2021-07-03 18:36:55 <mps> yes, 'use force Luke'
2021-07-03 18:37:19 <mps> if it doesn't work use bigger hammer
2021-07-03 18:37:26 <minimal> Looking at https://wiki.debian.org/UEFI I see: "Debian includes edk2-based VM firmware for arm64 in the qemu-efi package. For some reason this is often described as AAVMF to distinguish it from OVMF for x86. It's basically the same software."
2021-07-03 18:37:46 <minimal> not sure what exactly "basically" means - either its the same or its not...
2021-07-03 18:38:12 <mps> afaik debian file name is also OVMF for aarch64 and armv7
2021-07-03 18:39:16 <minimal> mps: nope, here on my laptop I see 2 dirs: /usr/share/OVMF and /usr/share/AAVMF
2021-07-03 18:40:04 <mps> my macbook is down so can't check right now
2021-07-03 18:40:24 <minimal> whereas /usr/share/AAVMF has 4: AAVMF32_CODE.fd  AAVMF32_VARS.fd  AAVMF_CODE.fd  AAVMF_VARS.fd
2021-07-03 18:41:02 <minimal> I guess that AAVMF32_CODE.fd is for armv7, haven't (yet) tried armv7 VM
2021-07-03 18:41:14 <mps> ok, we will rename alpine to debian then, it anyway behaves more and more as debian :D
2021-07-03 18:41:54 <mps> yes, AAVMF is official name in edk2
2021-07-03 18:42:48 <mps> maybe we also should rename them, but first build needs to be fixed
2021-07-03 18:43:26 <clandmeter> build/build-edge-riscv64 uploading packages to community
2021-07-03 18:43:29 <clandmeter> \o/
2021-07-03 18:43:44 <mps> oh, finally \o/
2021-07-03 18:43:46 <ikke> \o/
2021-07-03 18:44:16 <mps> algitbot: you learned recursion ;)
2021-07-03 18:44:31 <ikke> :)
2021-07-03 18:44:33 <ikke> smart bto
2021-07-03 18:44:35 <ikke> bot*
2021-07-03 18:44:51 <z3ntu> ikke: so can https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22619 be merged please? :)
2021-07-03 18:45:06 <mps> !22619
2021-07-03 18:45:24 <minimal> mps: I'd expect that the OVMF/AAVMF files should be both packages for all archs - so then you install 1 or other or both packages on your host machine to support the relevant type of UEFI system for your VM
2021-07-03 18:45:34 <minimal> s/packages/packaged/g
2021-07-03 18:45:34 <alpine-meetbot> minimal meant to say: mps: I'd expect that the OVMF/AAVMF files should be both packaged for all archs - so then you install 1 or other or both packaged on your host machine to support the relevant type of UEFI system for your VM
2021-07-03 18:46:01 <mps> can we build it for all arches on one arch
2021-07-03 18:47:17 <minimal> mps: not sure, haven't looked at how the packaging works
2021-07-03 18:48:14 <ikke> z3ntu: I'm working on upgrading our gitlab instance first, trying to look at it after
2021-07-03 18:48:19 <mps> I think this will require cross compile
2021-07-03 18:48:36 <z3ntu> thanks
2021-07-03 18:49:08 <minimal> actually looking at my Debina box, there are 3 packages:
2021-07-03 18:49:09 <minimal> ii  ovmf                                          0~20181115.85588389-3+deb10u3           all          UEFI firmware for 64-bit x86 virtual machines
2021-07-03 18:49:19 <minimal> ii  qemu-efi-aarch64                              0~20181115.85588389-3+deb10u3           all          UEFI firmware for 64-bit ARM virtual machines
2021-07-03 18:49:19 <minimal> ii  qemu-efi-arm                                  0~20181115.85588389-3+deb10u3           all          UEFI firmware for 32-bit ARM virtual machines
2021-07-03 18:51:18 <mps> minimal: yes, I know them, I used them 
2021-07-03 18:55:29 <minimal> mps: I'm virtually familiar with them too ;-)
2021-07-03 19:00:24 <ikke> upgrading gitlab now
2021-07-03 19:02:29 <mps> minimal: I still use debian qemu-efi-arm to boot alpine armv7 iso
2021-07-03 19:03:39 <minimal> mps: yes, that package contains the /usr/share/AAVMF/AAVMF32_CODE.fd file for QEMU to use in that situation
2021-07-03 19:04:42 <mps> right
2021-07-03 19:05:14 <minimal> so to boot alpine armv7 iso on an alpine x86_host with QEMU means we need AAVMF32_CODE.fd packaged
2021-07-03 19:05:23 <mps> but before we can do anything about this someone with good knowledge should fix our edk2 pkg
2021-07-03 19:06:07 <minimal> I haven't had a look yet at the debian/rules files for their 3 packages to see how they are building them
2021-07-03 19:06:13 <ikke> upgrade complete
2021-07-03 19:06:49 <mps> minimal: I did but couldn't find anything useful and what I can understand
2021-07-03 19:07:39 <minimal> having a look now...
2021-07-03 19:10:10 <mps> minimal: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20626
2021-07-03 19:10:24 <mps> !20626
2021-07-03 19:12:35 <mps> minimal: and #12640
2021-07-03 19:14:21 <mps> there is bug report on edk2 bugzilla but I lost url
2021-07-03 19:14:36 <mps> maybe donoban have it
2021-07-03 19:15:15 <minimal> looking at the debian/rules does look like its cross-compiling when host arch and OVMF/AAVMF arch is different
2021-07-03 19:16:51 <mps> iirc debian 'loves' cross compiling
2021-07-03 19:22:40 <mps> minimal: here is edk2 bug report https://bugzilla.tianocore.org/show_bug.cgi?id=3363
2021-07-03 19:27:57 <minimal> I'll have a try and building ovmf locally in a few days to see if I can figure anything out - need to finish off one other thing first as I have too many 1/2-done activities on the go
2021-07-03 19:31:24 <mps> I fully understand (time is human destroyer)
2021-07-03 19:34:23 <maxice8> aports-qa-bot seems to have died
2021-07-03 19:34:32 <ikke> oh
2021-07-03 19:35:22 <ikke> logs look alright
2021-07-03 19:35:51 <ikke> https://tpaste.us/QrDl
2021-07-03 19:36:43 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22824 failed to assign Jirutka 
2021-07-03 19:37:38 <ikke> Failed to assign maintainer error="no users found with email address \"rnalrd@alpinelinux.org\"" MR=22824 Project=1 component="MergeRequestJob Processor" service=AutoMaintainer
2021-07-03 19:38:14 <maxice8> oh I'm an idiot, misread contributor and maintainer again
2021-07-03 19:40:07 <maxice8> also there should be a new version of aports-qa-bot that uses aports-proxy-bot so you can have an user and admin tokens and only use the latter only used in certain paths that are known to be used by aports-qa-bot services
2021-07-03 19:40:17 <ikke> right
2021-07-03 19:40:21 <minimal> mps: doesn't help that I wasted about 3 days this week tracking down a initramfs related issue which turned out to be due to my mistaken use of doublequotes for parameters passed to nlplug-findfs...
2021-07-03 19:40:28 <ikke> heh
2021-07-03 19:41:26 <mps> that's a life, and not boring one ;)
2021-07-03 19:42:21 <mps> I'm 'wasting' days of free time to make riscv64 boot in qemu using u-boot
2021-07-03 19:42:21 <minimal> debugging initramfs-init stuff is slow and mind destroying lol
2021-07-03 20:37:43 <rhatr> clandmeter: seems like we're always at the opposite site of the sleep cycle ;-) at any rate -- if you see this -- please let me know if you'd be available for a call (the reason being -- just to have a quick chance to sync up so we can then go and do everything asynchronously)
2021-07-03 20:39:48 <JuniorJPDJ> hi, I'm building kernel myself and networking stopped working for me on 3.13
2021-07-03 20:39:51 <JuniorJPDJ> 3.12 works
2021-07-03 20:40:00 <JuniorJPDJ> what changed? should I enable something?
2021-07-03 20:44:13 <ikke> JuniorJPDJ: 3.13 switched to openrc-ng
2021-07-03 20:44:30 <JuniorJPDJ> I'm not even starting init tbh
2021-07-03 20:44:35 <MY-R> ifupdown-ng :)
2021-07-03 20:44:40 <JuniorJPDJ> im setting interface to up, adding ip, adding gateway
2021-07-03 20:44:42 <ikke> MY-R: yeah, thank yoy
2021-07-03 20:44:44 <JuniorJPDJ> using init script
2021-07-03 20:44:56 <ikke> JuniorJPDJ: What part of the network is not working?
2021-07-03 20:45:00 <JuniorJPDJ> and I've no connection on 3.13 and working connection on 3.12
2021-07-03 20:45:25 <JuniorJPDJ> It'll be hard to check tbh as ICMP is not working here
2021-07-03 20:45:34 <JuniorJPDJ> I'm using UML (usermode-linux) with slirp
2021-07-03 20:45:56 <JuniorJPDJ> but well
2021-07-03 20:46:04 <JuniorJPDJ> probably nothing is working? >__<
2021-07-03 20:46:23 <JuniorJPDJ> i've interface, but cannot wget any ip nor nc to my other pc
2021-07-03 20:46:39 <ikke> Is there an ip set on the interface?
2021-07-03 20:47:11 <JuniorJPDJ> mhm
2021-07-03 20:47:30 <JuniorJPDJ> in the same way on 3.12 and on 3.13 - using ip command
2021-07-03 20:47:41 <ikke> And a default route?
2021-07-03 20:47:52 <MY-R> JuniorJPDJ: /etc/network/interfaces would help as a starting point
2021-07-03 20:48:14 <JuniorJPDJ> no, it wont, I'm not using init system!
2021-07-03 20:48:15 <JuniorJPDJ> toldya
2021-07-03 20:48:23 <JuniorJPDJ> I'm setting up connection in init script
2021-07-03 20:48:28 <JuniorJPDJ> and it works on 3.12 and doesnt on 3.13
2021-07-03 20:48:36 <JuniorJPDJ> the only thing i change is rootfs tarball url
2021-07-03 20:48:59 <MY-R> ah, sorry then
2021-07-03 20:49:03 <JuniorJPDJ> and I wonder if i need to enable any kernel config option to make it work
2021-07-03 20:49:13 <JuniorJPDJ> maybe something changed
2021-07-03 20:50:00 <JuniorJPDJ> this is what I'm talking about if someone'd like to take a look: https://github.com/JuniorJPDJ/docker-usermode-linux/blob/update/Dockerfile
2021-07-03 20:50:22 <JuniorJPDJ> when i change line 30 to download 3.13 or 3.14 network stops working
2021-07-03 20:51:38 <JuniorJPDJ> ikke: yup, I also set default route and nameserver
2021-07-03 20:51:41 <JuniorJPDJ> and subnet mask
2021-07-03 20:53:03 <JuniorJPDJ> oh well, now netcat works
2021-07-03 20:53:16 <JuniorJPDJ> i can netcat things to my other pc on 3.13
2021-07-03 20:53:30 <ikke> slirp is anoying
2021-07-03 20:53:58 <JuniorJPDJ> what to use then? ;p
2021-07-03 20:54:02 <JuniorJPDJ> in unprivilaged env
2021-07-03 20:54:11 <ikke> yeah, not much alternatives then
2021-07-03 20:54:42 <JuniorJPDJ> i was wondering about using qemu's libslirp and writing own slirp alternative but.. later..
2021-07-03 20:55:09 <JuniorJPDJ> but this time slirp is not a problem as even apk update works on 3.12
2021-07-03 20:55:24 <ikke> yeah, I don't think it is
2021-07-03 20:55:28 <ikke> at least, no reason to think it is
2021-07-03 20:57:56 <JuniorJPDJ> it may not be any connection
2021-07-03 20:58:01 <JuniorJPDJ> it may be another problem
2021-07-03 20:58:18 <JuniorJPDJ> as i can get ip using nslookup and netcat something to other pc
2021-07-03 20:58:19 <JuniorJPDJ> what the...
2021-07-03 21:00:40 <JuniorJPDJ> 
ACTION uploaded an image: (159KiB) < https://matrix.org/_matrix/media/r0/download/juniorjpdj.pl/QgizxWCETVUtXyCgITvnfJGd/image.png >

2021-07-03 21:00:48 <JuniorJPDJ> and it blocks on apk update
2021-07-03 21:02:35 <ikke> do you see the traffic on the host? (wireshark / tcpdump)
2021-07-03 21:02:38 <JuniorJPDJ> 
ACTION uploaded an image: (46KiB) < https://matrix.org/_matrix/media/r0/download/juniorjpdj.pl/pBsaaLIvtjWjebaNcWbjLLok/Screenshot_20210703_230227.png >

2021-07-03 21:02:58 <JuniorJPDJ> meanwhile exactly the same, but with 3.12 rootfs works as it should
2021-07-03 21:02:58 <JuniorJPDJ> apk updates
2021-07-03 21:03:19 <JuniorJPDJ> <ikke "do you see the traffic on the ho"> good question, lemme check, need to install tcpdump
2021-07-03 21:05:41 <JuniorJPDJ> yup, I see apk trying to connect to something, I can see reply
2021-07-03 21:06:05 <JuniorJPDJ> HEY WHAT....
2021-07-03 21:06:11 <JuniorJPDJ> it just worked....
2021-07-03 21:06:17 <JuniorJPDJ> I hate UML
2021-07-03 21:08:02 <JuniorJPDJ> I can see lots of incorrect checksums on https port on tcpdump
2021-07-03 21:09:31 <JuniorJPDJ> ok, it's probably just checksum offload
2021-07-03 21:09:38 <JuniorJPDJ> but I probably see why it doesn't work
2021-07-03 21:09:47 <JuniorJPDJ> 3.12 -> 3.13 moved to https
2021-07-03 21:09:55 <JuniorJPDJ> but.. well.. it still should work i suppose
2021-07-03 21:10:51 <JuniorJPDJ> yup, I changed https to http in repositories on 3.14 and it works
2021-07-03 21:11:01 <JuniorJPDJ> anyway - it's still some sort of problem
2021-07-04 00:03:00 <Ariadne> most TLS issues are related to PMTU
2021-07-04 01:39:11 <dalias> ?
2021-07-04 02:04:24 <Ariadne> in response to JuniorJPDJ saying his https:// uris were not working
2021-07-04 02:04:40 <Ariadne> PMTU = path MTU
2021-07-04 03:09:16 <rdavidson> so this library I'm trying to make a package for does not really have conventional tarballs. it does have tagged releases on github, but you need to actually clone the repo, initialize submodules, and then check out the tagged release or else the submodule folders are empty.
2021-07-04 03:09:37 <rdavidson> i believe the correct answer is to use https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Git_checkout as an example (except adding the initialize submodules step). am I on the right track?
2021-07-04 03:28:11 <rhatr> separate package?
2021-07-04 03:28:11 <rhatr> clandmeter: mps: so the good news on the Nezha SBC is that it seems fairly standard and thus edge-alpine kernels have a pretty good chance of working there (I'm still trying to figure out whether we need a few custom patches or not). Obviously, the next question is kernel config for that SBC. What's a good practice for something like that? Should we just add all the options that SBC requires to the non-virt package? Have a 
2021-07-04 03:34:28 <rhatr> Btw, apparently these SBCs are selling pretty well on Aliexpress -- so we can just order one for every Alpine developer (if it actually ends up working well under Alpine ;-))
2021-07-04 03:40:06 <iggy> rhatr: you saw https://github.com/rvboards/linux_kernel_for_d1 ?
2021-07-04 04:33:19 <rhatr> haven't tried that one yet iggy:
2021-07-04 04:34:03 <rhatr> I am actually working with the original Nezha SBC SDK (or should I say Allwinner’s Tina SDK)
2021-07-04 06:10:06 <mps> good morning
2021-07-04 06:10:40 <mps> (hmm, my adsl is unstable again)
2021-07-04 06:14:50 <mps> looks like we are in opposite TZs
2021-07-04 06:14:58 <mps> rhatr: ^
2021-07-04 06:18:01 <mps> rhatr: changes to kernel (and not only kernel) can be posted mailing list, as merge request, as issue/bug/wishlist on issues at gitlab.a.o, also request here is ok (even with patches sent to tpaste)
2021-07-04 06:18:29 <mps> and I'm not against even in private mail
2021-07-04 06:21:32 <mps> rhatr: about patches to kernel (or anything), we are trying to have minimal number of patches, just bugfixes and essential things. patches which add some features are acceptable but usually needs to be explained very well why are they needed
2021-07-04 06:25:38 <mps> rhatr: also, changes should not be 'big' in one patch/request (you can read in irclog about my 'conflict' for a reference with BDFL about changes for kernel for armv7, month ago :) )
2021-07-04 08:28:49 <mps> why util-linux depends on linux-pam (:
2021-07-04 08:34:45 <ikke> runuser
2021-07-04 08:34:54 <ikke> libpam.so.0 => /lib/libpam.so.0 (0x7f0aa0bf3000)
2021-07-04 08:46:30 <mps> just waiting day when I will see that alpine is renamed to ubuntu :/
2021-07-04 10:47:37 <nmeum> mps: I personally avoid util-linux like the plague
2021-07-04 11:03:35 <donoban> ey mps they closed it
2021-07-04 11:04:52 <donoban> https://bugzilla.tianocore.org/show_bug.cgi?id=3363
2021-07-04 11:05:16 <donoban> nothing very helpful
2021-07-04 11:17:38 <donoban> maybe some of util-linux "required-by" packages could be use directly some sub package instead whole util-linux
2021-07-04 11:17:58 <ikke> that's the idea of the split-up
2021-07-04 11:18:02 <ikke> that was only finished recently
2021-07-04 11:18:33 <donoban> ah I see
2021-07-04 11:38:24 <clandmeter> rhatr: hi
2021-07-04 11:38:26 <clandmeter> im here
2021-07-04 11:40:04 <clandmeter> mps: thx for the kernel. it seems to work
2021-07-04 12:28:53 <mps> donoban: yes, I found edk2 bug url and posted it here last night
2021-07-04 12:29:18 <mps> clandmeter: everything for friends! :)
2021-07-04 12:30:38 <mps> nmeum: I need/like lsblk, findmnt and agetty from util-linux
2021-07-04 12:45:29 <Hello71> why agetty?
2021-07-04 12:45:50 <ikke> mps: then install those tools?
2021-07-04 12:46:33 <ikke> The whole idea of splitting util-linux into subpackages is that you can only install what you need
2021-07-04 12:48:57 <mps> Hello71: agetty supports some nice autologin options
2021-07-04 12:49:55 <mps> ikke: I did, but still wonder why runuser couldn't be separate pkg, and users then don't need to install linux-pam
2021-07-04 12:50:01 <Hello71> for non-serial terminals i just invoke login directly
2021-07-04 12:50:26 <mps> Hello71: and for serial, SBCs around me
2021-07-04 12:50:29 <Hello71> for real serial terminals i guess you could use getty -l
2021-07-04 12:50:34 <ikke> mps: we use subpackages for that, so that we do not need to update 2 (or more) packages at the same time
2021-07-04 12:50:49 <Hello71> mps: https://pkgs.alpinelinux.org/package/edge/main/x86_64/runuser
2021-07-04 12:50:50 <donoban> mps: where did you post? I don't see any new message on that url
2021-07-04 12:51:39 <mps> ikke: then why util-linux intalls linux-pam
2021-07-04 12:52:48 <mps> donoban: 2021-07-03 19:22:40 <mps> minimal: here is edk2 bug report https://bugzilla.tianocore.org/show_bug.cgi?id=3363
2021-07-04 12:53:31 <donoban> ahh, sorry I missunderstood you
2021-07-04 12:53:38 <mps> np :)
2021-07-04 12:53:55 <ikke> mps: because util-linux is a metapackage that installs all util-linux tools for backwards compattibility
2021-07-04 12:55:18 <mps> ikke: I know all this, but still ... (and I think you and me know all about this)
2021-07-04 13:31:42 <minimal> mps: util-linux itself does *not* depend on linux-pam, however if you install util-linux it auto-installs all the util-linux subpackages including runuser (which *does* depend on linux-pam).
2021-07-04 13:33:15 <minimal> if you only want lsblk, findfmt, and agetty then install lsblk, findfmt, and util-linux-misc packages and you won't then have linux-pam installed
2021-07-04 13:33:35 <mps> minimal: already did all this
2021-07-04 13:35:31 <minimal> the util-linux package is not effectively a backwards-compatibility package so as to not break anything and other packages can in future have their dependency on util-linux changed to reflect which of the subpackages they actually need to reduce the number of packages installed
2021-07-04 13:35:50 <minimal> s/not/now/g
2021-07-04 13:35:50 <alpine-meetbot> minimal meant to say: the util-linux package is now effectively a backwards-compatibility package so as to now break anything and other packages can in future have their dependency on util-linux changed to reflect which of the subpackages they actually need to reduce the number of packages installed
2021-07-04 13:36:31 <minimal> s/now break/not break/
2021-07-04 13:36:31 <alpine-meetbot> minimal meant to say: the util-linux package is now effectively a backwards-compatibility package so as to not break anything and other packages can in future have their dependency on util-linux changed to reflect which of the subpackages they actually need to reduce the number of packages installed
2021-07-04 13:39:43 <mps> yes I know
2021-07-04 13:40:25 <mps> but still think we could make separate runuser pkg and keep util-linux as it was before
2021-07-04 13:42:11 <minimal> separate package rather than the existing separate subpackage? As runuser is part of the util-linux source tarball it would seem strange to create 2 distinct packages (rather than subpackages) from the same tarball
2021-07-04 13:45:00 <mps> this is not uncommon in alpine
2021-07-04 13:46:17 <minimal> and what would doing that achieve?
2021-07-04 13:46:48 <mps> simple. small
2021-07-04 13:47:43 <PureTryOut> ikke: could you please purge polkit-elogind-lang on aarch64? As I mentioned a few times earlier it's still causing BAD signature errors and we have more and more users reporting it 😅
2021-07-04 13:47:58 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12814
2021-07-04 13:48:51 <minimal> eh? the whole purpose of the util-linux split work is for "small" - if you want "lsblk" you install lsblk and that's all you get, in the past you also had all other other util-linux stuff autoinstalled as well
2021-07-04 13:49:43 <mps> minimal: yes, I know
2021-07-04 13:50:15 <minimal> so it has already been achieved so I don't understand how what you are proposing changes that
2021-07-04 13:50:46 <mps> and it is not problem for me, but all alpine users will have to pass through this
2021-07-04 13:51:11 <minimal> pass through what? I don't understand what the "problem" currently is
2021-07-04 13:51:16 <mps> minimal: I don't propose changes, just grumbling
2021-07-04 13:52:18 <mps> if user upgrade their old system they will have linux-pam suddenly and they will wonder why
2021-07-04 13:52:25 <ikke> PureTryOut: You know you can do it as well?
2021-07-04 13:52:39 <PureTryOut> I was just told by minecrell yes, I did not know
2021-07-04 13:52:46 <PureTryOut> `curl -X` seems to do it?
2021-07-04 13:52:59 <PureTryOut> *`curl -X PURGE`
2021-07-04 13:53:07 <ikke> yes
2021-07-04 13:55:44 <minimal> mps: suddenly? previously the would have had linux-pam due to runuser's dependency on it. That dep was not something added recently, it was added over 1 year ago.
2021-07-04 13:56:28 <minimal> https://git.alpinelinux.org/aports/commit/main/util-linux/APKBUILD?id=c8e669399eef45338db6c6633baaf157c49eb76e
2021-07-04 13:57:25 <mps> on 3.12 util-linux doesn't depend on linux-pam
2021-07-04 13:58:01 <minimal> mps: that's because 3.12 is before the change I mentioned was committed, right?
2021-07-04 13:58:11 <mps> yes
2021-07-04 13:58:16 <minimal> the linux-pam stuff is completely unrelated to the splitting up of util-linux
2021-07-04 14:02:17 <mps> uh, I'm lost in this discussion
2021-07-04 14:07:23 <minimal> me too. You appeared to be arguing against the util-linux split changes due to the linux-pam dep which was not introduced by the splitting and indeed the splitting resolves the linux-pam dep issue going forward (i.e. in 3.15+), though it can't resolve the unrelated dep issue in 3.13 & 3.14 unless the split changes are backported, which typically wouldn't happen
2021-07-04 14:07:35 <Hello71> mps: your plan doesn't sound "simple"
2021-07-04 14:07:47 <Hello71> and arguably not "small" either
2021-07-04 15:51:19 <nmeum> do we actually need both a arch:riscv and arch:riscv64 label in the aports repo or can the former be deleted?
2021-07-04 15:55:27 <mps> nmeum: also I think we don't need arch:riscv
2021-07-04 15:56:41 <nmeum> there is also only one merge request assigned to this label
2021-07-04 15:56:44 <nmeum> I will just delete it then :)
2021-07-04 15:56:59 <mps> thiugh this is somewhat to discuss with clandmeter and Ariadne 
2021-07-04 15:57:18 <mps> ah, so simple :)
2021-07-04 15:57:19 <nmeum> ok
2021-07-04 15:57:29 <nmeum> well…do you want me to wait or just delete it?
2021-07-04 15:57:42 <Ariadne> i don’t have any interest in riscv32 atm
2021-07-04 15:57:57 <mps> in kernel source arch is riscv dir but there are both 32 and 64 bit
2021-07-04 15:58:59 <mps> nmeum: if you ask me I think we should delete riscv, but would like to hear clandmeter and Ariadne 
2021-07-04 15:59:09 <nmeum> ok, sounds reasonable to me
2021-07-04 15:59:58 <timlegge> mps: ikke: somone may have already scripted something but https://tpaste.us/jNem
2021-07-04 16:00:55 <ikke> timlegge: fyi, parts of this script could use ap revdep instead 
2021-07-04 16:01:01 <mps> timlegge: I did, but waiting for ncopa to 'approve' or come with better idea
2021-07-04 16:01:47 <mps> timlegge: I used apkgrel instead of abump
2021-07-04 16:02:26 <timlegge> there are some issue - it will leave empty make depends - it does not modernize anything and I was not sure if you wanted pkgrel incremented
2021-07-04 16:02:42 <mps> timlegge: what i did is https://tpaste.us/DXkd
2021-07-04 16:03:13 <Ariadne> mps: yes delete riscv, we will add riscv32 arch in future if there is demand for it
2021-07-04 16:03:22 <mps> I think pkgrel is only what is needed for 'just' rebuild pkgs
2021-07-04 16:03:37 <Ariadne> riscv32 is the reserved arch name in abuild/apk
2021-07-04 16:03:55 <mps> Ariadne: good, thank for info
2021-07-04 16:04:36 <mps> Ariadne: this is right how it should be in case riscv32 is added later
2021-07-04 16:04:46 <Ariadne> but all the SoCs out there right now worth a damn are rv64
2021-07-04 16:04:59 <ikke> is there any reason to have rv32?
2021-07-04 16:05:03 <Ariadne> for certain definitions of “worth a damn”
2021-07-04 16:05:17 <Ariadne> ikke: so far, no
2021-07-04 16:05:24 <mps> ikke: small and simple SBCs maybe
2021-07-04 16:05:45 <Ariadne> mps: there aren’t really any on the market tho
2021-07-04 16:06:08 <mps> I mean, in future and if
2021-07-04 16:06:24 <Ariadne> yeah
2021-07-04 16:06:29 <Hello71> if such devices exist in future will they actually run linux?
2021-07-04 16:06:40 <Ariadne> well in that case we will implement rv32 at that time
2021-07-04 16:06:50 <mps> Hello71: what else :)
2021-07-04 16:07:01 <Ariadne> mbedOS
2021-07-04 16:07:07 <Ariadne> freertos
2021-07-04 16:07:09 <Hello71> no os
2021-07-04 16:07:10 <Ariadne> vxworks
2021-07-04 16:07:13 <Ariadne> threadx
2021-07-04 16:07:23 <Ariadne> that redhat one
2021-07-04 16:07:26 <Hello71> arduino but with less crap
2021-07-04 16:08:09 <mps> nowadays if something don't run linux it is considered dead
2021-07-04 16:08:50 <mps> and riscv32 is also open ISA so expected is to run open kernel
2021-07-04 16:09:31 <mps> linux kernel actually have it in repo
2021-07-04 16:10:14 <mps> arch/riscv/configs/rv32_defconfig
2021-07-04 16:11:04 <nmeum> I have a few rv32 devices lying around (hifive1, longan nano, …) but they don't run linux ofc :p
2021-07-04 16:12:18 <nmeum> I deleted the arch:riscv label now btw
2021-07-04 16:13:39 <rzl[m]> Hello, gents. I'm trying to fork alpine/abuild but it returns 500. IIRC there was an upgrade today, maybe it's related?
2021-07-04 16:14:12 <ikke> rzl[m]: hmm, let me see
2021-07-04 16:15:12 <rzl[m]> Actually, it might me my fault. I cloned abuild and created a new private repo by pushing, then deleted said private repo, then tried forking. Maybe a leftover folder in storage?
2021-07-04 16:15:52 <clandmeter> fyi, I had to purge gcc and subpkgs for risv64. Because I had to rebuild it locally. Could be I forgot other pkgs.
2021-07-04 16:15:54 <rzl[m]> s/might me/might be/
2021-07-04 16:15:54 <alpine-meetbot> rzl[m] meant to say: Actually, it might be my fault. I cloned abuild and created a new private repo by pushing, then deleted said private repo, then tried forking. Maybe a leftover folder in storage?
2021-07-04 16:32:56 <ikke> rzl[m]: If I check the logs, I see a fork request seems to be successful
2021-07-04 16:35:50 <rzl[m]> ikke: weird, when I choose where to fork I am presented with a 500 page and no project was forked
2021-07-04 16:37:05 <rzl[m]> /alpine/abuild -> /alpine/abuild/-/forks/new -> /alpine/abuild/-/forks?namespace_key=3400
2021-07-04 16:37:34 <ikke> found a request
2021-07-04 16:39:30 <ikke> https://tpaste.us/Bgeb 
2021-07-04 16:39:51 <rzl[m]> What the heck
2021-07-04 16:41:34 <rzl[m]> In the git-data/repositories folder, is a rzl/abuild folder present by any change?
2021-07-04 16:42:13 <rzl[m]> Nevermind, I don't think Gitlab stores repositories that way anymore
2021-07-04 16:42:18 <ikke> rzl[m]: gitlab switched to hashed structure indeed
2021-07-04 16:51:08 <timlegge> https://tpaste.us/NMRl added ap revdep and apkgrel - I am sure you noticed this script verifies that pkg builds without the perl-dev package before it commits the changes.  If you are okay with the commit messages and limitations I can  process through on a branch and send the commits or you a can use as you see fit
2021-07-04 16:51:32 <ikke> rzl[m]: I don't see an abuild repo for you
2021-07-04 16:51:48 <ikke> rzl[m]: I see rzl/aports and rzl/apk-tools
2021-07-04 16:54:11 <rzl[m]> ikke: yes, exactly. I only have those two. For a while, I had a third that I created by pushing, IIRC. I deleted that one and now when trying to fork abuild, it flops. I'll see if I can fork other repos
2021-07-04 16:54:25 <rzl[m]> Can't fork alpine-baselayout
2021-07-04 16:55:09 <rzl[m]> Managed to create a private abuild by pushing via git
2021-07-04 16:55:39 <ikke> huh?
2021-07-04 16:56:03 <ikke> Can you create projects by just pushing to them?
2021-07-04 16:56:12 <rzl[m]> Still can't fork abuild or alpine-baselayout from the web interface
2021-07-04 16:56:20 <rzl[m]> Yes
2021-07-04 16:56:27 <rzl[m]> As long as they are under my user, ofc
2021-07-04 16:56:39 <ikke> I get a 500 as well
2021-07-04 16:57:30 <rzl[m]> https://tpaste.us/xnW7
2021-07-04 16:58:05 <ikke> Yeah, I see the repo now
2021-07-04 16:58:21 <ikke> But I guess it's not a fork then?
2021-07-04 16:58:53 <rzl[m]> No, it isn't. I initially created the repo this way by accident because I thought I had forked it, since I wanted to create a merge request to abuild
2021-07-04 16:59:03 <ikke> right
2021-07-04 17:00:05 <rzl[m]> But it seems that you can't fork repositories either? Have I borked something
2021-07-04 17:00:18 <rzl[m]> You can nuke my account if it helps :-)
2021-07-04 17:01:04 <ikke> no, I get the same error, so it's not tied to your account
2021-07-04 17:20:43 <ikke> rzl[m]: looking at the code right now, trying to figure out what's going on
2021-07-04 17:40:05 <timlegge> mps: ikke: I created !22857 based on the script https://tpaste.us/NMRl to remove perl-dev from some packages that don't need it. I stopped the processing to not tie up the builders.  Let me know if you want me to process all of the packages and retry the builders for the MR
2021-07-04 17:40:44 <ikke> timlegge: I guess we could make a MR per repo
2021-07-04 17:41:33 <timlegge> thats a good idea would keep the list smaller
2021-07-04 17:41:55 <ikke> timlegge: I suspect that the packages with an empty makedepends still depend on perl?
2021-07-04 17:42:42 <mps> lets see with what will ncopa come in a few days
2021-07-04 17:43:00 <ikke> I don't think we need to wait for ncopa
2021-07-04 17:43:17 <timlegge> I did not change the depends so if they depended on perl previously they still would - not all modules explicitly depended on perl previously though
2021-07-04 17:43:24 <ikke> As long as we make sure all packages that need to rebuild are rebuilt, I think he's ok
2021-07-04 17:43:29 <mps> ikke: he told that he will look at all this when he find time
2021-07-04 17:43:43 <ikke> yes, because people expect him to take a look at it
2021-07-04 17:43:59 <mps> no, because he wanted to take a look
2021-07-04 17:44:01 <ikke> hmmm
2021-07-04 17:44:23 <mps> I intended to merge perl upgrade but he asked to wait
2021-07-04 17:44:30 <timlegge> the script I have doesn not change the status of packages that need to rebuild for a new perl - it simply removes perl-dev from packages that do not need it
2021-07-04 17:44:54 <timlegge> then you can rebuild just the ones that depend on perl-dev
2021-07-04 17:45:03 <ikke> yeah
2021-07-04 17:45:13 <mps> yes, I agree
2021-07-04 17:45:21 <ikke> timlegge: I wonder if this change even warants a pkgrel bump?
2021-07-04 17:45:31 <mps> timlegge: your work is ok
2021-07-04 17:45:35 <timlegge> probably not actually
2021-07-04 17:45:48 <mps> but lets wait few days
2021-07-04 17:46:05 <ikke> If CI succeeds, we know perl-dev is not needed, but then removing it should not have any effect on the package
2021-07-04 17:46:51 <ikke> This is just preperatory work to reduce the amount of package that we think should be rebuilt
2021-07-04 17:47:44 <timlegge> I assume the CI will build without the pkgrel bump
2021-07-04 17:47:47 <ikke> yes
2021-07-04 17:47:54 <ikke> it just looks at the changed APKBUILD files
2021-07-04 17:49:49 <timlegge> ok, I will remove the pkgrel bump.  I assume the commit message is fine?
2021-07-04 17:50:39 <mps> remove perl-dev from makedepends?
2021-07-04 17:51:22 <mps> timlegge: ^
2021-07-04 17:52:07 <timlegge> mps: probably better - although strictly speaking the script removes it wherever it finds it
2021-07-04 17:52:38 <mps> I'm not versed in english but this sounds more precise than 'remove unnecessary perl-dev', at least to me
2021-07-04 17:55:06 <timlegge> you are correct - I might do "remove unnecessary perl-dev from makedepends"
2021-07-04 17:57:14 <mps> ehm, what's happened with your beard :)
2021-07-04 17:58:25 <timlegge> mps: mine? - got tired of the itch
2021-07-04 17:58:57 <mps> haha, understand you fully
2021-07-04 17:59:32 <timlegge> lol - it grew out grey for some reason too
2021-07-04 18:00:03 <timlegge> s/grey/gray/
2021-07-04 18:00:03 <alpine-meetbot> timlegge meant to say: lol - it grew out gray for some reason too
2021-07-04 18:00:14 <mps> eh, also
2021-07-04 18:01:13 <timlegge> can never remember if I spell it grey or gray
2021-07-04 18:01:56 <mps> ah, you also are not native english speaker? I never can remember these two exact meaning
2021-07-04 18:02:53 <ikke> timlegge: depends on if you are in the UK or in the US :)
2021-07-04 18:02:56 <timlegge> lol - I am Canadian english - we generally spell it grey I think like the UK but since we are so close to the US we sometimes get confused
2021-07-04 18:03:54 <ikke> timlegge: there are quite some package with effectively empty makedepends
2021-07-04 18:04:00 <timlegge> does not help that spell checkers default to US english in canada and its just a hassle to change
2021-07-04 18:04:14 <mps> ah, synonyms
2021-07-04 18:04:57 <timlegge> yes.  I could probably sed -i 's/makepepends=""//g' APKBUILD before commiting it
2021-07-04 18:06:26 <ikke> that does not suffice
2021-07-04 18:06:37 <ikke> a number of packages have an empty cmakedepends
2021-07-04 18:06:55 <ikke> cpanmakedepends*
2021-07-04 18:18:50 <PureTryOut> do commits that just add "replaces" to packages require pkgrel bumps? Not sure if it's part of the metadata of the package? I guess it is right?
2021-07-04 18:19:18 <ikke> yes
2021-07-04 18:20:04 <PureTryOut> Ok thanks
2021-07-04 18:37:00 <timlegge> ikke: making some changes and testing
2021-07-04 18:56:15 <timlegge> ikke: I wonder - since I am iterating through if I should cleanup empty cpanmakedepends="" and cpandepends="" as well?  
2021-07-04 19:00:21 <rhatr> mps: oh yeah -- I know the mechanics of it -- I was asking more about which way do we want to go. Right now there's only 2 riscv64 SBCs available -- one appears pretty clean (in terms of kernel patches) the other one not so much
2021-07-04 19:00:52 <rhatr> I guess we can just focus our actual (non-virt) kernel on one for now -- which means I'll just submit the kernel config + whatever few patches in a MR and see where it goes from there
2021-07-04 19:01:14 <rhatr> If we need to start supporting the other SBC for real -- we'll have to wait for 5.13 anyway -- and we can address that question then
2021-07-04 19:01:57 <ikke> timlegge: was doubting about that
2021-07-04 19:02:05 <ikke> timlegge: but if it's easy enough, fine with me
2021-07-04 19:16:05 <mps> rhatr: linux-edge is already 5.13.0
2021-07-04 19:16:35 <mps> my friend need it for qemu :)
2021-07-04 19:17:56 <mps> rhatr: we also for now concentrate on -virt because we don't have 'metal' to test and work, and we need qemu for CI and builders maybe
2021-07-04 19:19:45 <clandmeter> mps: full qemu is so slow :)
2021-07-04 19:20:39 <clandmeter> and fedora builds rv64 with system qemu afaik
2021-07-04 19:20:53 <mps> clandmeter: what about trying on other host arch, maybe aarch64
2021-07-04 19:21:05 <clandmeter> dunno
2021-07-04 19:21:19 <clandmeter> i tried on our host we have our dev boxes on
2021-07-04 19:21:41 <mps> and did we found proper accel option
2021-07-04 19:40:32 <rhatr> mps: "we also for now concentrate on -virt because we don't have 'metal' to test and work" well that's where I come in with my collection of h/w. Although truth be told -- like I said Nezha SBC seems to be very much available on Aliexpress & such
2021-07-04 19:41:47 <rhatr> but in terms of build servers -- for the next 9-12 months we all very much stuck with qemu (although I'm talking to Huawei to get some pre-prod server-level riscv64 gear)
2021-07-04 19:51:34 <mps> rhatr: yes, that is current status afaik. though building in develepor lxc is quite usable
2021-07-04 19:51:53 <mps> not fast as other arches but it is ok
2021-07-04 20:13:19 <iggy> rhatr: what board is available other than the nezha? (you mentioned 2 available above)
2021-07-04 20:13:53 <ikke> Reminds me that I should enable CI for rv64, especially now that community is available
2021-07-04 20:18:35 <rhatr> iggy: honestly, even when BeagleV (the only other one I know about and have on my desk) becomes available for general public -- I'd say it still has a way to go compared to  Nezha. My goal is to basically pick one for now and focus on it as THE riscv64 SBC for Alpine (sort of like RPi is that for ARM/Alpine). So far my money is on Nezha -- but ask me in a few days after I clean up their kernel.
2021-07-04 22:40:51 <Ariadne> rhatr: i wonder if we can do the same for loongarch64
2021-07-05 02:10:32 <timlegge> ikke: mps: I made a few more updates  https://tpaste.us/5nYj the latest version of  !22857 has all of main and looks pretty good (I think).  I did not attempt to fix all issues in older versions of APKBUILDs
2021-07-05 02:13:59 <timlegge> that removes perl-dev from 278 packages leaving only 75 in main that likely need to be rebuilt
2021-07-05 03:09:54 <Sheila> timlegge: if you could remove all of the $cpan* variables, that would be great; they're all legacy from the first iteration of apkbuild-cpan and are entirely unnecessary, and I don't know why I did it that way in the first place.
2021-07-05 06:32:51 <ncopa> good morning
2021-07-05 06:33:07 <ncopa> how are everyone?
2021-07-05 06:40:02 <ikke> ncopa: hey, welcome back 
2021-07-05 06:40:51 <mps> \o
2021-07-05 06:41:23 <mps> 
ACTION still sleeping

2021-07-05 06:42:50 <mps> timlegge: thanks, this will make perl and modules in a lot better shape on alpine
2021-07-05 06:47:41 <ncopa> thanks! has anything interesting happened last week?
2021-07-05 06:54:57 <ikke> riscv64 community had been uploaded 
2021-07-05 06:55:05 <ikke> has*
2021-07-05 06:55:32 <ikke> gitlab upgrade 
2021-07-05 06:59:57 <clandmeter> broke gitlab :|
2021-07-05 07:01:22 <ncopa> sounds fun..
2021-07-05 07:01:25 <ikke> 😶
2021-07-05 07:01:41 <danieli> prod gitlab?
2021-07-05 07:01:46 <ikke> Yes
2021-07-05 07:02:02 <ikke> Forking projects is broken 
2021-07-05 08:49:13 <markand> I think we reach the limit of build with !22793
2021-07-05 08:49:51 <markand> cc1plus: out of memory allocating 65536 bytes after a total of 643072 bytes
2021-07-05 08:50:09 <markand> is there a possibility to increase even more? otherwise the package *seems* to build corretly
2021-07-05 08:53:29 <ikke> X86, can it be address space it ran out of? 
2021-07-05 09:15:08 <andypost[m]> looks ppc64le repo for 3.14 still broken https://gitlab.alpinelinux.org/alpine/aports/-/jobs/429984 or maybe CI image?
2021-07-05 09:17:29 <ikke> The underlying issue is still there 
2021-07-05 10:44:09 <timlegge> Sheila: unless anyone objects I may do that in a separate set of commits.  I tried to touch the minimum in this set for the perl-dev issues
2021-07-05 10:44:55 <Sheila> fair
2021-07-05 10:45:05 <timlegge> mps: no problem - !22875 has community with testing to follow later today
2021-07-05 10:45:59 <ikke> timlegge: no objections from me
2021-07-05 10:49:24 <timlegge> mps: ikke: ran into issues on !22857 looks like I need to add depends=perl for a few of the modules that did not have it.
2021-07-05 10:49:36 <ikke> timlegge: right, I suspected that
2021-07-05 10:49:46 <ikke> they used perl-dev to just get perl
2021-07-05 10:49:54 <ikke> That's why makedepends ended up empty
2021-07-05 10:50:03 <timlegge> will be offline shortly for most of day - 
2021-07-05 10:50:07 <ikke> no worry
2021-07-05 10:50:24 <timlegge> ikke: ah, that explains how they worked (and what you meant)
2021-07-05 10:57:09 <mps> timlegge: good, I see this work as just start of 'putting' perl in better shape, so no hurries
2021-07-05 12:21:14 <fcolista> have you notice that docker when starts overwrite the iptables rules in place? Shouldn't the init start docker *before* iptables?
2021-07-05 12:21:56 <fcolista> the init does the other way round. First starts iptables, then docker
2021-07-05 12:29:12 <clandmeter> fcolista: i think its default behaviour
2021-07-05 12:29:32 <clandmeter> does does not play nice with other apps managing iptables
2021-07-05 12:29:36 <clandmeter> lol
2021-07-05 12:29:48 <clandmeter> s/does/docker/
2021-07-05 12:29:48 <alpine-meetbot> clandmeter meant to say: docker does not play nice with other apps managing iptables
2021-07-05 12:31:26 <fcolista> that's pretty bad
2021-07-05 12:35:10 <ikke> docker injects FORWARD and nat rules
2021-07-05 12:40:56 <clandmeter> fcolista: https://docs.docker.com/network/iptables/
2021-07-05 12:41:48 <ikke> Oh, and it also enables forwarding 
2021-07-05 12:55:57 <Newbyte> is there any chance !22412 could be merged? I don't want it to stay open too long since it touches many packages and I don't want to rebase it over and over. Plus, the package doesn't work at all without this.
2021-07-05 13:01:49 <Ariadne> morning
2021-07-05 13:04:08 <minimal> could someone please merge !22809
2021-07-05 13:04:29 <fcolista> clandmeter, thanks. Interesting.Gotta put all in docker-user
2021-07-05 13:04:42 <fcolista> which, with awall, i need to check how to do  that..
2021-07-05 13:05:26 <fcolista> https://gitlab.alpinelinux.org/alpine/awall/-/issues/9641
2021-07-05 13:05:30 <fcolista> cool :)
2021-07-05 15:27:42 <Kyle_E> Hello, I am trying to set up a cross compile setup targeting aarch64 from x86_64. When I run bootstrap.sh it fails at building gcc-pass2-aarch64. log - https://pastebin.com/J7UdB6YQ
2021-07-05 15:28:20 <Kyle_E> Sorry I don't have the full log, just the error section.
2021-07-05 15:30:06 <PureTryOut> Note that you can also just use `abuild rootbld` nowadays by setting the `CBUILD` env variable. Make sure you have `qemu-<target arch>` and `qemu-openrc` are installed, and that you have enabled the `qemu-binfmt` service afterwards
2021-07-05 15:30:09 <bl4ckb0ne> seems that gedit is missing a runtime dependency on gsettings-desktop-schemas
2021-07-05 15:30:15 <bl4ckb0ne> want a patch?
2021-07-05 15:30:32 <PureTryOut> E.g. `CBUILD=aarch64 abuild rootbld` in the directory of the package you want to build compiles it for aarch64
2021-07-05 15:31:19 <Thermi> libmdbx's (now in testing) dev made some more changes in the build process that check for the existence of the .git directory, so I can't really continue using git archives without undoing all these changes every time. I made an APKBUILD for it that just clones the repo using the snapshot mechanism and checks out the tag for the pkgver. That works fine so far. The checksum will obviously mismatch with the next commit. I guess I can use some 
2021-07-05 15:31:19 <Thermi> special value like SKIP to skip the checksum. But would that APKBUILD be acceptable?
2021-07-05 15:31:57 <PureTryOut> SKIP is not supported
2021-07-05 15:33:00 <Kyle_E> Ok, Thanks a lot!
2021-07-05 15:37:04 <mps> Thermi: you can use specific git commit id
2021-07-05 15:42:29 <Thermi> mps, during cloning?
2021-07-05 15:44:17 <PureTryOut> No, from Github and Gitlab you can directly download a specific git commit tarball, without cloning
2021-07-05 15:45:47 <Thermi> That does not help at all
2021-07-05 15:46:02 <Thermi> "libmdbx's (now in testing) dev made some more changes in the build process that check for the existence of the .git directory, so I can't really continue using git archives without undoing all these changes every time"
2021-07-05 15:46:58 <ikke> using git snapshots is really anoying
2021-07-05 15:47:33 <ikke> and we do require checksums / archives to make sure it's reproducible
2021-07-05 15:49:40 <Thermi> Evidently
2021-07-05 15:49:52 <Thermi> I also can not use "git snapshot" because of that. Instead I use tar cfz
2021-07-05 15:50:45 <ikke> I suspect this makefile will break when git eventually switches to an alternative ref backend
2021-07-05 15:50:59 <ikke> And the devs are evidentily 'lazy'
2021-07-05 15:51:21 <ikke> instead of providing a way to include version information, they go out of their way to make sure it's a git repo
2021-07-05 15:51:28 <mps> Thermi: https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2021-07-05 15:53:18 <ikke> Thermi: we store archives on distfiles, so that we can keep continue building these projects even if upstream disappears
2021-07-05 15:53:50 <mps> any package without release archive is not good/intended for distro packaging
2021-07-05 15:58:19 <Thermi> mps, ikke, the problem is that we need to run the test suite and that's not part of the "amalgated" sources (which have the version file precreated and thus doesn't need the .git directory).
2021-07-05 15:58:57 <Thermi> The dev says he'd test it sufficiently but we already found one bug in libmdbx that occurs on s390x (AFAIR), so his claim is evidently not true
2021-07-05 16:00:17 <Thermi> So we need the tests, and thus the complete repo.
2021-07-05 16:04:59 <ikke> it does not add up to me
2021-07-05 16:05:17 <ikke> How can an archive of the repo not contain something that you get when you clone the repo?
2021-07-05 16:05:37 <ikke> (except submodules, but did not see them)
2021-07-05 16:06:13 <Thermi> The amalgated release is a stripped down version of the git archive that is allegedly suitable for embedding, but does not contain the tests
2021-07-05 16:06:36 <Thermi> Allegedly users should implement their own tests within their application to test the lib for reliability in their test case
2021-07-05 16:06:39 <Thermi> *use case
2021-07-05 16:09:31 <ericonr> ikke: you can drop a config file so archives omit certain files
2021-07-05 16:09:48 <ericonr> it's what ardour does to make packaging their shit complete and utter pain
2021-07-05 16:09:48 <ikke> ericonr: yes, I'm aware of that, but in that case, they would be just sabotaging it
2021-07-05 16:10:02 <ikke> instead of saying something is a limitation
2021-07-05 16:10:17 <ikke> And I checked for a .gitattributes file
2021-07-05 16:10:33 <ikke> (Don't tell the author about them :P)
2021-07-05 16:13:47 <mps> if upstream don't want to fix such things pkg shouldn't be in distro, imo
2021-07-05 16:19:19 <Thermi> It's sadly the only usable embedded database that is an effective replacement for bsddb
2021-07-05 16:19:30 <Thermi> lmdb has bugs like silently dropping keys and values that are too long
2021-07-05 16:20:15 <Thermi> I took a good look at the situation a couple of months ago, which is why I was tasked with packaging libmdbx, writing python bindings for it, and integrating it into kopano to replace bsddb
2021-07-05 16:30:37 <ikke> Thermi: can you use cmake?
2021-07-05 16:30:41 <ikke> it seems to check for VERSION.txt
2021-07-05 16:30:48 <ikke> https://github.com/erthink/libmdbx/blob/master/CMakeLists.txt#L73
2021-07-05 16:31:04 <ikke> so then you can do echo "$pkgver" >VERSION.txt
2021-07-05 16:31:35 <ikke> If it exists, it does not exit
2021-07-05 16:33:26 <Thermi> The problem is that the remaining files besides the check are all generated as part of making the amalgated sources (which do not have the tests)
2021-07-05 16:33:51 <Thermi> It's much easier to just patch that stuff out and just do the VERSION.txt stuff
2021-07-05 16:41:46 <ikke> ugh, the amalgated sources are not even in a subdirectory 😒
2021-07-05 16:43:50 <ikke> so the Gnumake file in the amalgated sources do not include that check 
2021-07-05 16:45:24 <Thermi> I'm dealing with cmake now.
2021-07-05 16:45:31 <ikke> ok
2021-07-05 16:45:42 <Thermi> Luckily it's part of my job so I don't need to do it in my free time.
2021-07-05 16:45:43 <ikke> but shouldn't it be enough to create a VERSION.txt file then?
2021-07-05 16:46:10 <Thermi> No, because it checks for the existence of VERSION.txt _and_ other files that are only generated when it's an amalgated version
2021-07-05 16:46:17 <Thermi> So I had to ship all these generated files too
2021-07-05 16:46:25 <ikke> sigh
2021-07-05 16:46:27 <ikke> sigh
2021-07-05 16:46:29 <ikke> sigh
2021-07-05 16:46:41 <Thermi> and then effectively have two versions of the code where then it's not clear which files are compiled and which are tested against
2021-07-05 16:46:49 <ikke> so it does not even work when you clone it, I guess
2021-07-05 16:46:56 <Thermi> Exactly.
2021-07-05 16:47:05 <Thermi> I am now patching out the tests in the cmake files
2021-07-05 16:47:15 <Thermi> and figuring out how to run the tests from the generated Makefile
2021-07-05 16:48:49 <ikke> In short, it's just a mess
2021-07-05 16:49:55 <Thermi> Yes, a giant mess
2021-07-05 22:21:48 <andypost[m]> clandmeter: is there a reason to wait merging of !22480
2021-07-06 11:24:24 <PureTryOut> Why did the apkbuild-shellcheck on the CI recently start complaining about string replacement? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/430834
2021-07-06 11:26:51 <Hello71> shellcheck bug
2021-07-06 11:32:58 <minimal> yeah I noticed shellcheck in general changed behaviour recently, last week was seeing SC3036 warning (not in an Alpine package) where I'd previously seen SC2169 warning and had added disable lines for the older warning.
2021-07-06 11:35:38 <PureTryOut> Hmm annoying
2021-07-06 11:47:06 <minimal> PureTryOut: SC3060 was added in Shellcheck 0.7.2 which was packaged for Alpine in mid June
2021-07-06 11:48:03 <PureTryOut> That's fine and all but the APKBUILD isn't executed with Dash and string replacements are supported
2021-07-06 11:49:54 <minimal> I've been using Shellcheck a lot recently for other stuff (on Alpine) and I seem to remember that "shellcheck -s ash" is treated as though it was "dash" rather than "ash" and that Alpine's sh (which is Busybox's ash) has a config option to enable some Bashisms and that's why stuff works that shellcheck ciomplains about
2021-07-06 11:50:50 <minimal> there was/is an Issue on Shellcheck's Github to change its ash-related behaviour as basically all distros using ash have the Bashisms config enabled but (from memory) nothing was ever changed in shellcheck to take this into account
2021-07-06 11:53:53 <minimal> PureTryOut: this looks like the issue I was thinking of: https://github.com/koalaman/shellcheck/issues/853
2021-07-06 12:01:25 <PureTryOut> 👍️
2021-07-06 12:06:23 <jesec> any update on !22578? CI is all green. 
2021-07-06 13:42:36 <superduck> I'm unhappy with the change to /etc/profile forcing PAGER=less. Is there a way to undo this forced default behavior?
2021-07-06 13:45:12 <[[sroracle]]> change it in /etc/profile.d
2021-07-06 14:04:12 <nmeum> you should also be able to overwrite it in your shell configuration file as /etc/profile is usually sourced firt
2021-07-06 14:04:13 <nmeum> *first
2021-07-06 14:19:21 <nmeum> who is our goto s390x person? would be neat if the ruby-rexml failure on that architecture could be fixed :)
2021-07-06 14:27:18 <ikke> I guess in practice Ariadne 
2021-07-06 14:28:14 <Ariadne> well, really, tmhoang
2021-07-06 14:29:39 <Ariadne> but dunno where he went :)P
2021-07-06 14:29:41 <Ariadne> :)*
2021-07-06 14:30:46 <ikke> Yes, hence the 'in practice' 
2021-07-06 14:37:58 <Ariadne> Error: test_socket(REXMLTests::SAX2Tester): SystemStackError: stack level too deep
2021-07-06 14:38:10 <Ariadne> probably running out of stack memory
2021-07-06 14:38:27 <Ariadne> i think. just disable that specific test
2021-07-06 15:07:42 <superduck> Well PAGER=less isn't POSIX compliant for a system default PAGER=more would be. In either case, I think it's preferred to *not* have it specified as it was in earlier releases.
2021-07-06 15:22:15 <timlegge> mps: ikke: rewrote my script in perl and should have new PR for the removal of unnecessary perl-dev later today - it cleans up more of the issues at the same time
2021-07-06 15:49:00 <omni> !22648
2021-07-06 16:11:07 <mps> timlegge: good. do you think this changes should be merged before or after upgrade to perl 5.34.0
2021-07-06 16:12:32 <mps> (and new pkgs waiting in my private branches will need to follow)
2021-07-06 16:12:40 <timlegge> Not sure that it matters for the removal of perl-dev but if it's merge before should mean less rebuilds 
2021-07-06 16:13:04 <mps> ok,
2021-07-06 16:13:51 <mps> ncopa: what do you think about work (and good one) timlegge did to make perl pkgs in better shape
2021-07-06 16:13:54 <timlegge> You should probably also look at your local version of apkbuild-cpan  because it currently defaults to adding perl-dev
2021-07-06 16:14:14 <mps> sure
2021-07-06 16:18:01 <timlegge> a few more tweaks needed later today
2021-07-06 18:42:08 <rzl[m]> Howdy! Does anyone know the status of luajit on s390x? I just tried building neovim on s390x and it seems that luajit will not pass cli arguments to the script
2021-07-06 19:11:02 <Ariadne> broken
2021-07-06 19:11:20 <Ariadne> well
2021-07-06 19:11:23 <Ariadne> define 'on s390x'
2021-07-06 19:11:36 <Ariadne> because, qemu-s390x is pretty broken too
2021-07-06 19:58:31 <JuniorJPDJ> hey, I'd like to package cmake-based project, are there any presets for cmake from alpine?
2021-07-06 19:58:49 <rzl[m]> newapkbuild -c, I think
2021-07-06 19:59:04 <rzl[m]> -C :)
2021-07-06 20:13:34 <rzl[m]> Ah, yes, thanks Ariadne 
2021-07-06 20:15:24 <rzl[m]> Unrelated, it seems GCC does not compile due to missing plugins in ar and ranlib when compiling with -flto
2021-07-06 20:18:14 <Hello71> should be fixed back in like 3.13
2021-07-06 20:18:51 <Hello71> 3.12
2021-07-06 20:19:01 <Hello71> e296f565dbf916871242d0551922984f4e2e8b8c
2021-07-06 20:21:42 <rzl[m]> Hmm, I'm running bootstrap.sh with -flto in my CFLAGS. I think LTO is working in general, I did manage to build binutils and musl
2021-07-06 20:26:52 <rzl[m]> I think it may be something else, probably PEBCAK. It seems some step in configure is complaining "cannot run C compiled programs"
2021-07-06 20:27:44 <ericonr> rzl[m]: maybe your musl is broken with -flto
2021-07-06 20:28:45 <Hello71> musl is in fact broken with lto
2021-07-06 20:29:02 <dalias> yeah -flto by default is a really bad idea
2021-07-06 20:29:03 <Hello71> iirc in theory you can just exclude crt*.o
2021-07-06 20:29:21 <Hello71> but i heard that from dalias so probably he can explain better
2021-07-06 20:29:23 <dalias> hello71, there's probably at least some minor amount of UB left in src/string or similar
2021-07-06 20:30:54 <rzl[m]> Well, I looked at https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10023 and I was hoping I could give a hand
2021-07-06 20:31:55 <rzl[m]> I'm doing another build after changing back the bootstrap script. I switched all `abuild -r` for `abuild rootbld` because I wanted clean builds, hence me saying it was probably self-inflicted
2021-07-06 20:32:18 <ericonr> building firefox itself with lto first probably makes more sense
2021-07-06 20:32:50 <ericonr> and should return the most gains
2021-07-06 20:36:46 <rzl[m]> I'll take a look at it
2021-07-06 20:38:27 <rzl[m]> In the meantime, everything in GCC goes well until libgomp, at which point it fails in the first attempt at running the built(?) gcc
2021-07-06 20:39:42 <rzl[m]> I guess it is musl
2021-07-06 20:39:52 <rzl[m]> /usr/x86_64-alpine-linux-musl/bin/ld: error in /tmp/conftest.LDfbjG.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be created
2021-07-06 20:40:06 <rzl[m]> And the resulting binary segfaults
2021-07-06 20:54:13 <dalias> ?
2021-07-06 21:28:14 <timlegge> !22913 should finish the CI soon - a couple of small lint issues that I may go back to after these merge and it removes perl-dev dependency from 99 perl packages in testing.  community is running now
2021-07-06 21:30:23 <rzl[m]> Hmm, maybe it isn't musl. I tried building musl without -flto but only musl-dev was packaged. I'll take a better look tomorrow, but it seems that while building gcc-stage2 it fails to run ./configure for libgomp using gcc/xgcc, which I assume is gcc stage1. It tries "checking whether we are cross compiling" by building a C program and the generated binary segfaults immediately and halts the configure
2021-07-06 21:33:54 <JuniorJPDJ> newapkbuild is bugged or am I just dumb?
2021-07-06 21:34:55 <JuniorJPDJ> https://hastebin.com/oqetikidok.sh
2021-07-06 21:35:07 <JuniorJPDJ> I added `set -x` at start of newapkbuild to see why it crashes
2021-07-06 21:35:10 <JuniorJPDJ> and I still dont know
2021-07-06 21:36:18 <rzl[m]> line 204, curl fails
2021-07-06 21:36:34 <rzl[m]> s/204/214/
2021-07-06 21:36:34 <alpine-meetbot> rzl[m] meant to say: line 214, curl fails
2021-07-06 21:39:49 <JuniorJPDJ> I mean ofc it fails
2021-07-06 21:39:56 <JuniorJPDJ> as newapkbuild modified url I provided
2021-07-06 21:39:59 <JuniorJPDJ> in some weird way
2021-07-06 21:40:21 <JuniorJPDJ> idk whats the reason of fail, I can clearly see this 404
2021-07-06 21:40:43 <JuniorJPDJ> url i provided in cmdline (also in hastebin) works, url it generated doesnt
2021-07-06 21:41:00 <Hello71> ugh, hastebin
2021-07-06 21:42:05 <JuniorJPDJ> oh yeah, sorry, i missed hastebin logo covered the url xD
2021-07-06 21:42:37 <rzl[m]> I think it's trying to have the download go to a file with a proper name instead of just the version
2021-07-06 21:43:18 <rzl[m]> You can try downloading manually and do newapkbuild ... -C tcmu-runner-1.5.4
2021-07-06 21:48:10 <rzl[m]> Try using /archive/<version>.tar.gz rather than /archive/refs/tags/<version>.tar.gz
2021-07-06 21:49:55 <JuniorJPDJ> <rzl[m] "Try using /archive/<version>.tar"> this worked, thanks
2021-07-06 21:50:07 <JuniorJPDJ> I need to create issue to newapkbuild then to handle this urls
2021-07-06 21:50:11 <JuniorJPDJ> as it was confusing
2021-07-06 22:34:35 <JuniorJPDJ> is there something for #include <assert.h> for musl?
2021-07-06 22:34:44 <dalias> ?
2021-07-06 22:36:06 <JuniorJPDJ> oh I see it's inside musl-dev
2021-07-06 22:36:22 <JuniorJPDJ> I'm trying to compile tcmu-runner and it floods me with errors
2021-07-06 22:36:35 <dalias> what kind of errors?
2021-07-06 22:36:59 <JuniorJPDJ> wait a sec I'll first add missing includes to files
2021-07-06 22:37:23 <JuniorJPDJ> well, I can't fix this one: error: implicit declaration of function 'assert_perror'
2021-07-06 22:37:33 <JuniorJPDJ> there's assert.h included in this file
2021-07-06 22:37:40 <JuniorJPDJ> and I've musl-dev in makedeps
2021-07-06 22:38:02 <dalias> maybe that's some glibcism. you can llikely just remove it
2021-07-06 22:39:49 <JuniorJPDJ> it is, that's GNU's extension
2021-07-06 22:47:30 <ericonr> you might want to replace with assert
2021-07-06 22:47:52 <dalias> yeah just assert should work
2021-07-06 22:47:58 <dalias> just without the nice error message
2021-07-06 22:48:38 <dalias> well, assert(!errorcode)
2021-07-06 22:48:52 <dalias> i think
2021-07-06 22:48:58 <dalias> the documentation isnt very clear
2021-07-06 22:49:33 <JuniorJPDJ> I removed it atm
2021-07-06 22:51:36 <JuniorJPDJ> uh, pthread_getname_np
2021-07-06 22:52:09 <JuniorJPDJ> https://www.openwall.com/lists/musl/2019/07/17/3
2021-07-06 22:52:17 <JuniorJPDJ> it was supposed to get added in 2019
2021-07-06 22:52:37 <JuniorJPDJ> oh nvm, thats you, you know that ;D
2021-07-06 22:55:42 <ericonr> iirc it was merged
2021-07-06 22:56:04 <ericonr> but it's arguably a useless interface
2021-07-06 22:56:42 <dalias> it's quite useless but fairly harmless and symmetrical with setname
2021-07-06 22:57:11 <JuniorJPDJ> what am I missing then if it doesnt work?
2021-07-06 22:57:27 <JuniorJPDJ> it's supposed to be in pthread.h and it's included
2021-07-06 22:57:30 <dalias> it's not in release just git master
2021-07-06 22:57:37 <ericonr> ^^
2021-07-06 22:57:43 <JuniorJPDJ> oh well, that makes sense
2021-07-06 22:57:47 <dalias> just comment it out too; it's not doing anything useful
2021-07-06 22:58:13 <dalias> (if the code expects something in the output tho make sure to just initialize the string or whatever with a dummy val)
2021-07-06 23:01:46 <JuniorJPDJ> it was in logging purposes so i removed it from printf
2021-07-06 23:03:22 <JuniorJPDJ> it's close!
2021-07-06 23:03:31 <JuniorJPDJ> last problems I've are format missmatches
2021-07-06 23:03:32 <JuniorJPDJ> error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'pthread_t' {aka 'struct __pthread *'} 
2021-07-06 23:03:32 <JuniorJPDJ> [-Werror=format=]
2021-07-06 23:03:52 <JuniorJPDJ> what should i do? convert the pointer?
2021-07-06 23:04:37 <dalias> pthread_t is an abstract handle type you can't portably print
2021-07-06 23:04:50 <dalias> but to just get this to build and work, (long) cast should suffice
2021-07-06 23:05:17 <JuniorJPDJ> so look at this line:
2021-07-06 23:05:53 <JuniorJPDJ> tcmu_dev_err(dev, "Failed to set name for thread %lu\n", pthread_self());
2021-07-06 23:05:55 <JuniorJPDJ> welp
2021-07-06 23:06:19 <dalias> (long)pthread_self() is not correct usage of the API, but will work for what they wanted
2021-07-06 23:06:20 <JuniorJPDJ> it's a pointer so at the most it's printing address of it as fair as I understand?
2021-07-06 23:06:27 <dalias> or rather (unsigned long)
2021-07-06 23:06:41 <dalias> yes
2021-07-06 23:06:46 <dalias> it's going to print an address
2021-07-06 23:06:58 <JuniorJPDJ> im considering commenting it out, its useless
2021-07-06 23:07:14 <dalias> :)
2021-07-06 23:07:16 <dalias> that works too
2021-07-06 23:11:28 <JuniorJPDJ> ok, I've no idea how to fix this one: https://github.com/open-iscsi/tcmu-runner/blob/master/tcmur_work.c#L46
2021-07-06 23:11:39 <JuniorJPDJ> as it seems like pretty good usage of name getting
2021-07-06 23:12:25 <ericonr> wow I hate it
2021-07-06 23:12:48 <JuniorJPDJ> tid would be better
2021-07-06 23:12:50 <JuniorJPDJ> but well
2021-07-06 23:12:55 <ericonr> you should know what your own thread is doing :p
2021-07-06 23:14:07 <ericonr> accessing that refcnt without locking is probably sketchy too, but i haven't looked at the whole thing
2021-07-06 23:15:14 <JuniorJPDJ> it's not that easy as it can be used as library
2021-07-06 23:15:25 <JuniorJPDJ> so people can do veeery weird things
2021-07-06 23:15:34 <JuniorJPDJ> doing checks like that seems like pretty good idea
2021-07-06 23:15:57 <ericonr> even worse then, what if another library touches the thread name?
2021-07-06 23:17:13 <Hello71> ericonr: mine mine everything is all mine
2021-07-06 23:17:17 <Hello71> [insert political joke here]
2021-07-06 23:17:40 <ericonr> using a thread_local variable to store thread info would be somewhat better, and keep a similar design
2021-07-06 23:17:46 <ericonr> would even save on the strcmp call
2021-07-06 23:18:02 <ericonr> Hello71: lol
2021-07-06 23:18:22 <JuniorJPDJ> how can I get thread id from pthread_t?
2021-07-06 23:18:25 <Hello71> ericonr: you seem to be assuming optimistically that they won't just store a string
2021-07-06 23:18:34 <dalias> the pthread_t is the id you use
2021-07-06 23:18:34 <JuniorJPDJ> I'll rewrite some of code and do PR for them
2021-07-06 23:19:01 <JuniorJPDJ> i mean integer id eg visible in htop
2021-07-06 23:19:02 <JuniorJPDJ> ;o
2021-07-06 23:19:05 <JuniorJPDJ> tid
2021-07-06 23:19:15 <JuniorJPDJ> it's pthread_t?
2021-07-06 23:19:50 <Hello71> although technically i think you could do global const char *MY_THREAD_ID = "whatever"; __thread char *tid; and then if (tid == MY_THREAD_ID)
2021-07-06 23:19:56 <ericonr> Hello71: I guess it saves on typing :( enum is a very long word
2021-07-06 23:20:01 <Hello71> then you're basically writing javascript
2021-07-06 23:20:19 <ericonr> eeew
2021-07-06 23:20:21 <ericonr> lol
2021-07-06 23:20:44 <ericonr> dalias: I would say the linked code counts as harmful usage of pthread_getname_np
2021-07-06 23:21:26 <ericonr> not that I can say much, given that I implemented the version that ended up merged into musl heh
2021-07-06 23:38:41 <ericonr> https://github.com/open-iscsi/tcmu-runner/blob/06d64ab78c2898c032fe5be93f9ae6f64b199d5b/libtcmu.c#L843 wow I hate it
2021-07-06 23:39:56 <ericonr> this really should be a thread local control variable; it would serve the same purpose and work on platforms other than linux
2021-07-06 23:40:32 <ericonr> and not be overwritable by other code
2021-07-06 23:42:14 <Hello71> and also you wouldn't be limited to 16 characters
2021-07-06 23:42:17 <Hello71> creat
2021-07-06 23:43:56 <JuniorJPDJ> <ericonr "this really should be a thread l"> it's not ment to work on non-linux anyway
2021-07-06 23:44:12 <JuniorJPDJ> its userspace daemon for in-kernel target framework
2021-07-06 23:46:43 <ericonr> even so, there's no reason to be using getname/setname for the purpose of controlling what a thread is doing
2021-07-06 23:48:02 <dalias> its mainly for top output ;-p
2021-07-06 23:48:27 <JuniorJPDJ> I've no idea how to patch this
2021-07-06 23:48:43 <JuniorJPDJ> commenting it out doesn't seem like good idea
2021-07-06 23:50:06 <JuniorJPDJ> I'd just do global var holding pthread_t of this thread
2021-07-06 23:50:16 <JuniorJPDJ> but I've no idea if only one thread like that can exist
2021-07-06 23:53:13 <ericonr> JuniorJPDJ: create a static thread_local variable
2021-07-06 23:53:35 <ericonr> set it to 1 when the set thread name function is called with ework-thread
2021-07-06 23:53:36 <JuniorJPDJ> with name.. well.. xD
2021-07-06 23:53:48 <JuniorJPDJ> <ericonr "set it to 1 when the set thread "> even better
2021-07-06 23:54:01 <JuniorJPDJ> still - I'm not C developer, I need to do research about thread-local vars
2021-07-06 23:54:16 <ericonr> check the value of the var instead of doing pthread_getname_np+strcmp
2021-07-06 23:55:08 <ericonr> saves on syscalls, improves reliability, and is easier to reason about
2021-07-06 23:55:23 <dalias> *nod*
2021-07-07 00:06:09 <JuniorJPDJ> i can normally use `thread_local` macro?
2021-07-07 00:06:24 <JuniorJPDJ> (just making sure I found thing I need)
2021-07-07 00:07:31 <dalias> yes that's standard C11 if you include the header that defines it
2021-07-07 00:07:37 <dalias> or you can use _Thread_local without including it
2021-07-07 00:09:02 <JuniorJPDJ> -std=c99
2021-07-07 00:09:03 <JuniorJPDJ> oops
2021-07-07 00:09:21 <JuniorJPDJ> sooo, what's pthreads specific version of this? :X 
2021-07-07 00:10:14 <dalias> prior to C11 there was no official thread-local storage. the pthread api has thread-specific data keys and pthread_[gs]etspecific
2021-07-07 00:10:25 <dalias> but gcc had __thread for a long time before C11
2021-07-07 00:10:38 <dalias> __thread is the same as _Thread_local at least for C
2021-07-07 00:10:46 <dalias> (for C++ there may be subtle differences; not sure)
2021-07-07 00:11:20 <JuniorJPDJ> ok, i'll try `__thread`
2021-07-07 00:14:23 <ericonr> uses linux-only APIs but restricts itself to c99
2021-07-07 00:15:13 <JuniorJPDJ> it was probably written before gcc supported c11 and then not migrated
2021-07-07 00:17:28 <JuniorJPDJ> my god, they use goto
2021-07-07 00:20:56 <ericonr> goto is great when not used to create loops
2021-07-07 00:23:20 <valerius> goto is one of those features of the language that a lot of people say to never use, but it seems that it can be used correctly in the right hands
2021-07-07 00:26:53 <JuniorJPDJ> supercool - I've other file which doesn't include header of file setting name to worker thread (the one I modified to have thread-local var)
2021-07-07 00:26:58 <JuniorJPDJ> but it checks thread name...
2021-07-07 00:28:09 <JuniorJPDJ> should I create new header file with this variable or what..
2021-07-07 00:29:45 <JuniorJPDJ> oh nvm I found good header
2021-07-07 00:34:11 <ericonr> JuniorJPDJ: remember to make it extern in the header 
2021-07-07 00:35:34 <JuniorJPDJ> why should I do that?
2021-07-07 00:36:35 <JuniorJPDJ> oh i see now.. ;x
2021-07-07 00:40:29 <JuniorJPDJ> should I set it's value to 0 in header file?
2021-07-07 00:41:43 <JuniorJPDJ> this doesnt seem like the best idea but idk how to do it other way
2021-07-07 00:41:56 <JuniorJPDJ> to be sure its 0 when not set to 1
2021-07-07 00:42:10 <ericonr> no
2021-07-07 00:42:45 <ericonr> in the header you do 'extern __thread int tccm_is_ework_thread;'
2021-07-07 00:43:09 <ericonr> then in one of the source files (you choose which), do '__thread int tcmu_is_ework_thread = 0;'
2021-07-07 00:43:20 <ericonr> (above it should have been tcmu as well)
2021-07-07 00:43:33 <JuniorJPDJ> makes sense
2021-07-07 00:43:47 <ericonr> the compiler would have screamed at you for trying to initialize an extern, anyway
2021-07-07 00:43:59 <JuniorJPDJ> so I need to redefine it, well, thats what i did bad
2021-07-07 00:44:15 <ericonr> no, this is not redefinition
2021-07-07 00:44:22 <ericonr> extern is a declaration
2021-07-07 00:44:31 <JuniorJPDJ> as i tried exactly that, but in source i did just `tcmu_is_ework_thread=0`
2021-07-07 00:44:49 <ericonr> source still needs info like I showed
2021-07-07 00:44:53 <ericonr> __thread int
2021-07-07 00:48:25 <JuniorJPDJ> it built!
2021-07-07 00:51:43 <JuniorJPDJ> there are no tests and I'm probably not able to check if it'll work reliably
2021-07-07 01:09:32 <JuniorJPDJ> how can I specify `provides` for subpackage?
2021-07-07 01:09:56 <JuniorJPDJ> especially autogenerated -dev one
2021-07-07 01:30:40 <maxice8> dev() {  provide=X ; default_dev }
2021-07-07 01:40:20 <JuniorJPDJ> SP:[AL55]:./APKBUILD:32:CMAKE_BUILD_TYPE must be None: -DCMAKE_BUILD_TYPE=Release
2021-07-07 01:40:24 <JuniorJPDJ> why tho?
2021-07-07 01:41:49 <craftyguy> I think apkbuild sets that?
2021-07-07 01:43:29 <JuniorJPDJ> I set to Release and got this error in jobs
2021-07-07 01:43:40 <JuniorJPDJ> why can't it be release and have to be None?
2021-07-07 01:44:54 <JuniorJPDJ> nevermind, I found answer on archwiki
2021-07-07 01:45:12 <JuniorJPDJ> if someone
2021-07-07 01:45:17 <JuniorJPDJ> is curious too: https://wiki.archlinux.org/title/CMake_package_guidelines#CMake_can_automatically_override_the_default_compiler_optimization_flag
2021-07-07 01:55:16 <JuniorJPDJ> it looks like tcmu-runner is complete trash...
2021-07-07 01:55:25 <JuniorJPDJ> it fails builds on every 32-bit architecture
2021-07-07 01:55:36 <ericonr> 
ACTION pretends to be surprised

2021-07-07 01:55:37 <JuniorJPDJ> and I actually had hope to use it on armv7
2021-07-07 03:07:03 <timlegge> mps: ikke: !22875 and !22913 look in pretty good shape.  and !22857 should hopefully finish successfully soon.  There are a few other packages that likely don't require perl-dev but fail for other reasons that I will take a look at over the next few days.  The script I used  is at https://tpaste.us/gBay  but it has a couple of hard coded values like my home directory...
2021-07-07 03:52:01 <unrznbl> I was trying to fork aports on gitlab.alpinelinux.org and get a 500 error. Am I doing something wrong? I select my user account on a page with this URL: https://gitlab.alpinelinux.org/alpine/aports/-/forks/new
2021-07-07 04:27:08 <ikke> unrznbl[m]: no, there is an issue that we are trying to solve
2021-07-07 04:27:56 <unrznbl[m]> ikke: thanks! appreciate that. I am patient. :)
2021-07-07 07:38:46 <mps> timlegge: good work. we will have perl in better shape thanks to you
2021-07-07 07:54:48 <clandmeter> timlegge: do we need so many individual commits which kind off all do the same thing?
2021-07-07 08:10:01 <markand> can we get a look at !22793 ?
2021-07-07 08:10:19 <markand> it seems to build correctly as long as the builder has higher limits
2021-07-07 09:47:18 <timlegge> clandmeter:  up to you really.   I can squash to one but as it was scripted it was the easiest to do.
2021-07-07 09:48:18 <clandmeter> its about 550 commits right?
2021-07-07 09:49:24 <clandmeter> my pref would be to squash them. it keeps the gitlog a bit sane
2021-07-07 11:26:57 <Hello71> I agree to squash
2021-07-07 11:28:59 <ikke> I agree as well 
2021-07-07 11:39:55 <timlegge> Sounds good, later today I will squash one per repo...
2021-07-07 11:43:37 <ikke> 👍
2021-07-07 12:06:41 <wener_> @clandmeter Hi, please help review !22935 , need pg userdb, also enabled redis for statdb
2021-07-07 13:13:39 <clandmeter> wener_: do you need these changes?
2021-07-07 13:15:45 <wener_> yes, currently coturn only support sqlite, want to use pg
2021-07-07 13:16:37 <clandmeter> do you mind taking over maintenance? im not using it atm
2021-07-07 13:17:18 <wener_> ok, should I change in another commit or same commit ?
2021-07-07 13:19:25 <clandmeter> what you prefer, does not really matter much, just make a note in the specific commit.
2021-07-07 13:19:29 <ikke> Separate commit (but can be same mr) 
2021-07-07 13:19:58 <Aftershock> hey so anyone have experience using python on alpine. I'm trying to run a searX instance but for some reason pip doesn't see the lxml module provided by py3-lxml if I install that apk
2021-07-07 13:20:36 <clandmeter> i think i used coturn when trying matrix
2021-07-07 13:22:04 <wener_> @ikke ok
2021-07-07 13:23:29 <wener_> using coturn with asterisk, but currently alpine's asterisk missing opus, using debian asterisk for now
2021-07-07 13:28:01 <clandmeter> maybe you should add mysql support too
2021-07-07 13:29:38 <clandmeter> asterisk without opus does not sound sane
2021-07-07 13:30:18 <Newbyte> https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/431444
2021-07-07 13:30:23 <Newbyte> is there anything I can do about this failure?
2021-07-07 13:31:22 <clandmeter> ikke: ppc still lacking packages?
2021-07-07 13:32:13 <wener_> add a issues for opus #12808 , fabled is work on this
2021-07-07 13:33:55 <wener_> want to add mysql to coturn, but mariadb or mysql? I choose skip the question.
2021-07-07 13:34:20 <clandmeter> should be mariadb
2021-07-07 13:34:32 <clandmeter> asterisk needs a blob for opus?
2021-07-07 13:35:13 <clandmeter> opus is opensource iirc?
2021-07-07 13:35:15 <wener_> there is an opensource opus impl, I checked the pr, using the open source impl.
2021-07-07 13:35:42 <wener_> the official's is blob
2021-07-07 13:56:33 <dne> uhm, yuck, "for legal reasons"?! https://web.archive.org/web/20161003135358/http://blogs.digium.com/2016/09/30/opus-in-asterisk/
2021-07-07 15:04:54 <dalias> why would any FOSS provider ship a blob like that ?!?! >_<
2021-07-07 15:05:23 <dalias> if they're actually worried about liability for shipping the open source one, document that and tell users they'll have to obtain it from a third party if they want it
2021-07-07 15:05:31 <dalias> don't ship a phone-home-malware blob
2021-07-07 15:08:32 <darkelvenangel> Hello, I need some assistance, I'm running a script from /etc/local.d/ and I need to have a way to determine if the system will poweroff or reboot.
2021-07-07 15:44:02 <ikke> gmid hangs on mips64
2021-07-07 15:44:32 <ikke> clandmeter: yes
2021-07-07 16:51:22 <caskd> Does anyone here know if/when mono msbuild will be available?
2021-07-07 16:51:34 <ikke> caskd: haven't heard anything concrete about it
2021-07-07 16:52:38 <caskd> xbuild is supposed to be deprecated and msbuild should add more compatiblity with micro$oft's C# build system
2021-07-07 17:06:11 <Hello71> in alpine or in general?
2021-07-07 17:06:27 <Hello71> it's available as debs already
2021-07-07 17:06:40 <Hello71> i took a look at packaging it for gentoo but everything is horribly bloated
2021-07-07 17:06:53 <ikke> and there are also already binaries for alpine
2021-07-07 17:18:37 <Hello71> probably
2021-07-07 18:07:01 <bl4ckb0ne> i tried to packaged the binaries not too long ago but it was turned down
2021-07-07 18:09:04 <bl4ckb0ne> aur package for msbuild is also horrible
2021-07-07 18:44:31 <JuniorJPDJ> there was some better way than mv $package/.. $subpackage/...
2021-07-07 18:44:37 <JuniorJPDJ> and docs only talk about this one
2021-07-07 18:45:01 <JuniorJPDJ> can someone remind me what was that better way to move file to subpkg?
2021-07-07 18:45:51 <ikke> JuniorJPDJ: amove
2021-07-07 18:48:46 <JuniorJPDJ> thanks :D
2021-07-07 18:49:37 <JuniorJPDJ> there's literally NO world amove on whole alpine wiki ;x
2021-07-07 18:51:11 <bl4ckb0ne> make an edit :)
2021-07-07 18:53:08 <JuniorJPDJ> i will, i just wanted to find example usage first ;D
2021-07-07 18:53:10 <JuniorJPDJ> just did
2021-07-07 18:53:15 <mps> ikke: you advice something not documented (amove)
2021-07-07 18:53:56 <mps> what's wrong with 'mv'
2021-07-07 18:54:39 <JuniorJPDJ> amove is more handy
2021-07-07 18:54:55 <ikke> mps: nothing
2021-07-07 18:54:55 <JuniorJPDJ> I'll document it, but first i need to register to wiki
2021-07-07 18:55:01 <JuniorJPDJ> and I failed anti-bot xD
2021-07-07 18:55:40 <ikke> mps: but amove can make sure the entire directory structure is replicated without removing it from the main package
2021-07-07 18:55:44 <mps> aren't we earlier talked and did not come to idea to use amove
2021-07-07 18:56:16 <ikke> mps: sorry, that sentence makes little sense
2021-07-07 18:56:38 <mps> we didn't come to conclusion to use amove
2021-07-07 18:57:15 <ikke> amove is not a replacement for mv, it's a helper for a common pattern when you need to move a pattern of files from the main package to a subpackage
2021-07-07 18:57:37 <ikke> instead of having to redo the same logic over and over and over and over again, you can use amove if you want
2021-07-07 18:57:58 <mps> I understand this, but afaik BDFL was against
2021-07-07 18:58:48 <mps> and I'm, till someone write that it is officially supported
2021-07-07 18:59:39 <mps> to be clear I'm not against but would be good it is official
2021-07-07 18:59:49 <ikke> Ok, I'll write it: "I'ts officially supported"
2021-07-07 18:59:57 <ikke> it's part of abuild
2021-07-07 18:59:58 <mps> :P
2021-07-07 19:00:18 <ikke> it's a helper function, don't make such a big deal out of it
2021-07-07 19:00:36 <JuniorJPDJ> +
2021-07-07 19:00:43 <mps> 
ACTION goes back to hack kernels

2021-07-07 20:13:55 <nmeum> is the riscv64 builder stuck on qt or does it just take a few days? 🤔
2021-07-07 20:14:08 <ikke> Who nk
2021-07-07 20:14:10 <ikke> knows :P
2021-07-07 20:15:52 <nmeum> JuniorJPDJ: there is also a APKBUILD(5) man page, but it doesn't mention amove either unfourtunatly. should probably also be added to that
2021-07-07 20:17:00 <ikke> nmeum: seems pretty stale
2021-07-07 20:17:11 <ikke> I mean, the riscv64 builder
2021-07-07 20:17:33 <JuniorJPDJ> i added amove to subpackage section on wiki about creating apkbuilds
2021-07-07 20:17:53 <JuniorJPDJ> https://gitlab.alpinelinux.org/JuniorJPDJ/aports/-/jobs/431674
2021-07-07 20:17:59 <JuniorJPDJ> ERROR: Failed to create usr/bin/ceph-objectstore-tool: Connection aborted
2021-07-07 20:17:59 <JuniorJPDJ> ERROR: ceph-osd-tools-16.2.4-r2: BAD signature
2021-07-07 20:18:00 <JuniorJPDJ> wtf?
2021-07-07 20:18:08 <JuniorJPDJ> ppc64le worker ducked up?
2021-07-07 20:18:36 <ikke> I guess
2021-07-07 20:18:44 <ikke> not sure what 'connection aborted' refers to
2021-07-07 20:19:08 <JuniorJPDJ> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/sYEwHgtjCqHeisoyBtWnUndX/message.txt >

2021-07-07 20:19:14 <JuniorJPDJ> probably repository? or not?
2021-07-07 20:19:31 <JuniorJPDJ> wait, it doesnt seem to be repository
2021-07-07 20:19:38 <JuniorJPDJ> whaaat
2021-07-07 22:12:09 <clandmeter> dalias: got a sec to look at https://tpaste.us/r6ZE  ?
2021-07-07 22:12:35 <clandmeter> rspamd on aarch64
2021-07-07 22:33:09 <JuniorJPDJ> would be cool for someone with neccessary permissions would take a look at this job fail: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22931
2021-07-07 22:33:59 <JuniorJPDJ> ppc64le fails with weird fail while installing deps
2021-07-07 22:44:36 <clandmeter> JuniorJPDJ: ppc ci kind of broken due to mirror is out of sync
2021-07-07 22:45:06 <JuniorJPDJ> oh well
2021-07-07 22:46:22 <clandmeter> ppc builders have some network issues thats causing this, we are looking into it.
2021-07-07 23:14:56 <timlegge> clandmeter: I think I did the squash correctly for !22857
2021-07-07 23:17:52 <timlegge> mps: ikke: ^ it was a merge so the commit message is rather long...
2021-07-07 23:39:33 <dalias> clandmeter, looking
2021-07-07 23:42:46 <dalias> there are no symbols for the interesting part...
2021-07-07 23:42:52 <dalias> libhs.so
2021-07-07 23:49:34 <dalias> can you install the debug package for it and try again??
2021-07-08 01:05:14 <Hello71> dalias: what if it's supposed to throw?
2021-07-08 01:10:07 <dalias> ?
2021-07-08 01:10:21 <dalias> it crashed while throwing
2021-07-08 03:49:47 <tomalok> I've made some progress with packer / qemu / UEFI -- the current situation, however, seems to be that "qemu-system-aarch64 -machine virt" doesn't have anything for a VNC  connection to send characters across for boot_command to function (log into the iso, set up network & ssh)...
2021-07-08 03:59:39 <JuniorJPDJ> can someone ping me when ppc is going to work again?
2021-07-08 04:15:03 <tomalok> closest i can get with aarch64 is to connect with VNC to the qemu monitor console (which isn't all that helpful except to send it a 'quit')
2021-07-08 04:20:20 <tomalok> 
ACTION :facepalm: okay, _just_ got it working (outside of packer) with "-device virtio-gpu-pci" -- which I swear I've tried before.

2021-07-08 04:23:05 <tomalok> 
ACTION ...though it doesn't seem to be taking any keyboard input

2021-07-08 04:29:52 <tomalok> 
ACTION (probably a device for that)

2021-07-08 04:36:46 <tomalok> 
ACTION "-device usb-ehci -device usb-kbd"

2021-07-08 05:21:47 <ikke> JuniorJPDJ: it should be up-to-date for now
2021-07-08 06:11:45 <JuniorJPDJ> ikke: thanks, my MR seems to still have the same problem tho ;/
2021-07-08 06:12:56 <JuniorJPDJ> https://gitlab.alpinelinux.org/JuniorJPDJ/aports/-/jobs/431786#L211
2021-07-08 06:12:57 <JuniorJPDJ> mhm.
2021-07-08 06:51:31 <clandmeter> dalias: looks like it comes from vectorscan. ill need to add the symbols pkg.
2021-07-08 08:11:22 <mps> timlegge: whatever and/or however you make this fixes is good for me. this will fix and clean perl pkgs and that is what is important
2021-07-08 08:24:58 <clandmeter> dalias: https://tpaste.us/6WDz
2021-07-08 09:43:39 <adhawkins> Wow, that was fast! 5 minutes from MR to merge! Thanks Leo :)
2021-07-08 09:43:46 <adhawkins> #22957
2021-07-08 09:43:59 <adhawkins> Ah, the bot not here yet? :)
2021-07-08 09:46:15 <maxice8> !22957
2021-07-08 09:46:27 <maxice8> GitLab uses ! for Merge requests and # for issues
2021-07-08 09:50:16 <adhawkins> Ah, doh. Memory failing. Thanks maxice8.
2021-07-08 11:10:56 <ncopa> dalias: whats your thoughts about this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22958
2021-07-08 14:28:11 <dalias> .....
2021-07-08 14:28:25 <dalias> this code uses exceptions for non-exceptional execution flow in parser
2021-07-08 14:29:16 <dalias> something seems broken with the unwind implementation tho, not the code here
2021-07-08 14:29:28 <dalias> clandmeter, this is about your backtrace
2021-07-08 14:32:08 <dalias> clandmeter, having debug version of libgcc_s might help too
2021-07-08 14:41:43 <dalias> ncopa, i replied on the issue
2021-07-08 14:42:23 <dalias> clandmeter, see:
2021-07-08 14:42:24 <dalias> <ericonr> we had an issue on void at one point, but it was to the point that gdb itself wasn't working
2021-07-08 14:42:29 <dalias> <ericonr> fixed with https://github.com/void-linux/void-packages/blob/master/srcpkgs/gcc/patches/fix-vtv-link-order.patch
2021-07-08 14:43:30 <dalias> looks like gcc has a link bug that makes a broken .eh_frame in libstdc++ with vtv enabled
2021-07-08 14:43:40 <dalias> this patch should probably be in mcm if needed
2021-07-08 14:47:57 <dalias> not sure if alpine has vtv enabled tho
2021-07-08 14:49:09 <ncopa> dalias: thank you sir!
2021-07-08 14:53:15 <ncopa> the alpine-standard aarch64 iso does not boot in qemu on alpples m1 chip. not sure why
2021-07-08 14:54:05 <ncopa> i was able to boot linuxkit kernel with a custom alpine based initramfs though
2021-07-08 14:55:36 <ericonr> ncopa: 16k pages?
2021-07-08 14:58:46 <ncopa> ericonr: how do I check that?
2021-07-08 15:01:01 <ncopa> nope. CONFIG_ARM64_4K_PAGES=y
2021-07-08 15:02:02 <ericonr> idk if it requires it to boot at all, but m1 def requires a 16k kernel to be useful
2021-07-08 15:04:47 <ncopa> i guess i'll have to build a custom kernel then
2021-07-08 15:05:25 <Hello71> linux-m1? :p
2021-07-08 15:05:44 <ericonr> ncopa: https://twitter.com/marcan42/status/1398301933203431426
2021-07-08 15:07:00 <ncopa> um.. this was in qemu
2021-07-08 15:08:35 <dalias> with only 16k pages, how is the m1 able to host *any* virtualized environments?
2021-07-08 15:08:41 <dalias> esp x86 ones
2021-07-08 15:09:32 <ncopa> no idea
2021-07-08 15:14:56 <ikke> ncopa: This moves py3-inotify, maintained by you, to community (from testing): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15720/diffs?commit_id=49399a0e896ff7105c1a443daaadbbf1df4e964b
2021-07-08 15:14:58 <ikke> do you mind
2021-07-08 15:16:02 <mps> ncopa: you need to enable M1 in kernel
2021-07-08 15:16:16 <mps> and it is only present in 5.13
2021-07-08 15:17:50 <mps> I was tempted to enable M1 in linux-edge 5.13.0 but didn't because I'm not sure about 'boot' tools
2021-07-08 15:31:27 <Thermi> Okay, I now have a working libmdbx build that uses snapshotting to get/make stable tar archives that won't change with new commits
2021-07-08 15:31:28 <Thermi> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22961
2021-07-08 15:31:42 <Thermi> The builder is not calling the snapshotting function though, so the build fails.
2021-07-08 15:31:48 <ikke> yes, that's the anoying part
2021-07-08 15:31:55 <ikke> a developer needs to call it
2021-07-08 15:32:00 <Thermi> :(
2021-07-08 15:32:55 <Thermi> Can you please check if my function does the stuff needed? I don't explicitely download any snapshots in any of my functions, so for this to work, it'd need to occur within abuild itself
2021-07-08 15:33:23 <ikke> The goal of the snapshot function is to generate an archive, and upload it to dev.alpinelinux.org
2021-07-08 15:33:34 <ikke> (for which you need permissions)
2021-07-08 15:34:04 <Thermi> Evidently. Is there a way to make it work locally, without permissions, so it just doesn't upload? Is there maybe a check I can add?
2021-07-08 15:34:07 <ikke> after that, it's just general APKBUILD that downloads an archive, but then from dev.a.o
2021-07-08 15:34:32 <Thermi> I ideally can use the same APKBUILD locally and in aports
2021-07-08 15:35:22 <dalias> hmm alpine's gcc build has lots of weird per-arch options
2021-07-08 15:35:27 <ikke> Thermi: Do you actually need to use snapshot? You seem to patch the source you get from github. Could you not just directly download the archive from github?
2021-07-08 15:35:34 <dalias> like disabling decimal float (why?)
2021-07-08 15:35:45 <Thermi> ikke, No, because the dev wants to remove the downloads of the archives at some point
2021-07-08 15:35:56 <Thermi> He really, really hates maintainers it seems
2021-07-08 15:36:03 <ikke> yes
2021-07-08 15:36:05 <Thermi> We discussed this a couple of days ago in here
2021-07-08 15:36:09 <ikke> I kno
2021-07-08 15:36:10 <dalias> and --enable-cld for x86 (why?)
2021-07-08 15:36:11 <ikke> know
2021-07-08 15:36:23 <ikke> Thermi: If I read his arguments, he's not against archives, just the ones that github generates by default
2021-07-08 15:36:36 <ikke> the problem is, the one that _he_ provides are a lot more limited
2021-07-08 15:36:40 <Thermi> Yeah well, then he should upload the ones he wants to have available, but with the damn tests
2021-07-08 15:36:45 <ikke> yes, exactly
2021-07-08 15:37:22 <Thermi> I heard there were package maintainers from other distros here, too
2021-07-08 15:37:38 <Thermi> If anybody wants to package libmdbx for their distro and have problems, please contact me
2021-07-08 15:37:52 <Thermi> I hope if we make enough noise he'll do it right
2021-07-08 15:38:24 <ikke> but at least for now, just using the ones that github provides should work with the patching you do
2021-07-08 15:38:45 <Thermi> Then I need to do even more patching now
2021-07-08 15:38:51 <ikke> how come?
2021-07-08 15:38:56 <Thermi> Oh lord I should just fork it completely
2021-07-08 16:16:33 <craftyguy> is there some reason why the 'notification' switch in alpine gitlab issues is grayed out for me (when I'm logged in)?
2021-07-08 16:17:51 <craftyguy> does the alpine gitlab instance not support notifications(?) I'm not able to toggle this: http://0x0.st/-OsQ.png
2021-07-08 16:20:42 <ikke> Works for me
2021-07-08 16:20:50 <ikke> Some javascript issue?
2021-07-08 16:21:57 <craftyguy> hmm, I don't think so, but let me try a clean FF profile
2021-07-08 16:23:07 <craftyguy> hmmm no, still doesn't work for me. here's the issue I'm trying to toggle it on: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10747
2021-07-08 16:28:32 <ikke> craftyguy: can I impersonate you to check?
2021-07-08 16:28:46 <craftyguy> ikke: sure
2021-07-08 16:29:34 <craftyguy> I'm able to interact with other things, like collapsing sidebar, and the buttons (todo, etc)
2021-07-08 16:30:56 <ikke> Yes, it doesn't allow me either
2021-07-08 16:32:38 <craftyguy> ah so it's not just me I guess. looks like it doesn't work in other repos (just looked at an issue in aports) either on the alpine gitlab
2021-07-08 16:33:38 <ikke> Let me try something
2021-07-08 16:33:55 <craftyguy> sure. thanks for the help
2021-07-08 16:34:08 <ikke> Can you enable them now?
2021-07-08 16:34:17 <ikke> on aports
2021-07-08 16:36:30 <craftyguy> ikke: aports: yes
2021-07-08 16:36:40 <craftyguy> now I can enable it there
2021-07-08 16:36:49 <ikke> hmm, so it's some kind of permission issue
2021-07-08 16:37:13 <ikke> What if you leave a comment on that issue in apk-tools?
2021-07-08 16:37:22 <craftyguy> ya I just saw you added me as a reporter there. I don't think that's necessary on gitlab.com to enable notifications, unless I'm misremembering
2021-07-08 16:37:50 <ikke> yeah, I would not expect it either
2021-07-08 16:37:58 <craftyguy> I guess I can leave a comment there to get notified, but spamming issues just to subscribe seems like I'd piss off people fast :P
2021-07-08 16:38:04 <ikke> yes
2021-07-08 16:38:31 <ikke> I have a feeling this version if gitlab is kinda buggy
2021-07-08 17:10:26 <timlegge> !22857 !22875 and !22913 are ready from my perspective.  I plan to look at cleaning up some of the other packages after these are merged
2021-07-08 17:17:34 <Thermi> I reworked the libmdbx upgrade to 0.10.0: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22963
2021-07-08 17:23:14 <ikke> timlegge: btw, techincally changing the license would warant a pkgrel bump (to update the metadata in the package), but not sure if it's worth it
2021-07-08 17:26:28 <timlegge> ikke: I basically defaulted those based on the existing GPL PerlArtistic which is the default for Perl5 modules.  It is essentially the same but I can remove that if you want
2021-07-08 17:26:50 <timlegge> figured it was an easy cleanup
2021-07-08 17:26:55 <ikke> No need to
2021-07-08 17:55:04 <JuniorJPDJ> https://gitlab.alpinelinux.org/JuniorJPDJ/aports/-/jobs/432297#L224
2021-07-08 17:55:17 <JuniorJPDJ> still ppc failing the same way
2021-07-08 17:55:32 <JuniorJPDJ> while installing deps
2021-07-08 17:55:50 <ikke> hmm
2021-07-08 17:56:15 <ikke> right, I still need to purge it after I fixed it
2021-07-08 18:00:12 <mps> Newbyte: regarding !22966 , we usually don't do such moves for stable releases
2021-07-08 18:00:43 <mps> else we will got chaos in maintaining stables
2021-07-08 18:15:38 <nmeum> hm, I think we should consider cleanup up testing again soonish. There is just so much stuff in there that doesn't build and hasn't been touched in ages
2021-07-08 18:15:52 <ikke> right
2021-07-08 18:15:53 <nmeum> doing something like b6af1e02efe594039707cd882517663d5370f375 perodically would probably be good to ensure that pages migrate to community or main at some point
2021-07-08 18:16:02 <nmeum> s/pages/packages/
2021-07-08 18:16:02 <alpine-meetbot> nmeum meant to say: doing something like b6af1e02efe594039707cd882517663d5370f375 perodically would probably be good to ensure that packages migrate to community or main at some point
2021-07-08 18:17:42 <ikke> JuniorJPDJ: issue is now fixed
2021-07-08 18:17:58 <ikke> apk fetch eph-osd-tools works now on ppc64le
2021-07-08 19:31:43 <caskd> why is amove used so rarely and (afaik) never mentioned in abuild docs?
2021-07-08 19:31:57 <caskd> it's such a useful feature for splitting packages
2021-07-08 19:32:23 <Cogitri> It was only relatively recently added
2021-07-08 19:32:29 <caskd> oh
2021-07-08 19:32:42 <Cogitri> Like a year ago or so
2021-07-08 19:32:54 <caskd> well, then it should be popularized i guess
2021-07-08 19:32:58 <caskd> it eases lots of work
2021-07-08 19:33:02 <Cogitri> And since most APKBUILDs are copy paste most keep using the old idioms
2021-07-08 19:33:16 <Cogitri> Sure, but that’s work that has to be done by someone :)
2021-07-08 19:33:24 <caskd> yeah, i guess
2021-07-08 20:02:11 <PureTryOut> I tend to move packages to amove when I touch them
2021-07-08 20:12:26 <JuniorJPDJ> <caskd "why is amove used so rarely and "> I added it to wiki page as a comment in subpackage example yesterday
2021-07-08 20:12:57 <JuniorJPDJ> <ikke "JuniorJPDJ_: issue is now fixed"> thanks, I'll restart job in my MR
2021-07-08 20:14:58 <caskd> JuniorJPDJ: oh, nice, thanks for that
2021-07-08 20:52:36 <JuniorJPDJ> when should I move packages from testing to community?
2021-07-08 20:58:37 <ikke> JuniorJPDJ: once you verified that the package is working and it's in good shape
2021-07-08 20:59:05 <JuniorJPDJ> How much time should it take?
2021-07-08 20:59:23 <JuniorJPDJ> Eg. I'm using some packages from testing for few months now and those seem to work good, no problems
2021-07-08 20:59:30 <JuniorJPDJ> Should I move them to community?
2021-07-08 20:59:35 <ikke> sure
2021-07-08 20:59:38 <JuniorJPDJ> (I'm talking about package I maintain)
2021-07-08 20:59:51 <JuniorJPDJ> Cool then :D 
2021-07-08 21:27:18 <JuniorJPDJ> are there any queue for workers info?
2021-07-08 21:27:49 <JuniorJPDJ> as I started job more than a hour ago
2021-07-08 21:28:11 <JuniorJPDJ> and its still paused
2021-07-08 21:38:44 <JuniorJPDJ> and I dont know if it's a bug (eg. worker is dead) or its just a queue
2021-07-09 01:17:54 <unrznbl[m]> ikke: does cloning aports on alpine gitlab work again? If not any chance I can help?
2021-07-09 01:31:47 <anjan> Hi, Im trying to understand the feedback here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21949#note_161098
2021-07-09 01:31:53 <anjan> What should the bindir be exactly?
2021-07-09 01:48:08 <orbea> anjan: normally you pass --bindir to configure, but idk if that is a standard build system or not
2021-07-09 01:48:38 <orbea> and given that --prefix is already set, seems not needed to set it at all assuming the build system is not broken
2021-07-09 01:48:56 <anjan> orbea: so take out the bindir arg?
2021-07-09 01:48:58 <anjan> I guess
2021-07-09 01:49:03 <orbea> if that works, yes
2021-07-09 01:49:14 <orbea> same with prefix for install
2021-07-09 01:51:06 <anjan> orbea: install: cannot remove '/sbin/adjtimex': Permission denied
2021-07-09 01:56:28 <orbea> sounds like there is something wrong with the build system/configure script
2021-07-09 01:56:44 <orbea> figure out why its not respecing DESTDIR
2021-07-09 01:56:53 <orbea> *respecting
2021-07-09 01:57:29 <anjan> I see
2021-07-09 01:57:33 <anjan> thank you for your help
2021-07-09 01:59:39 <iggy> did anything change with the repo format for the version of apk that is included in 3.14? I have my own repo that worked on my systems up until 3.14, now I'm getting 'IO ERROR' when trying to do an `apk upgrade`
2021-07-09 02:03:54 <Daanct12> hi, a question about mr
2021-07-09 02:04:17 <JuniorJPDJ> ask it then
2021-07-09 02:04:37 <Daanct12> after submitted a mr to master, do i have to make another merge request for backporting to 3.14?
2021-07-09 03:16:21 <unrznbl[m]> I still can't fork aports on gitlab.alpinelinux.org, is there a ticket somewhere to fix the issue? I get a 500 error. username is same as here: unrznbl
2021-07-09 04:47:01 <ikke> unrznbl[m]: we have an upstream ticket, but no response so for. I seem to have found a issue and trying to fix it, but not sure if that's the actual cause
2021-07-09 04:52:43 <ikke> unrznbl[m]: https://gitlab.com/gitlab-org/gitlab/-/issues/335187
2021-07-09 05:55:32 <JuniorJPDJ> Daanct12: yup
2021-07-09 05:55:41 <JuniorJPDJ> at least i saw people doing so
2021-07-09 05:55:46 <JuniorJPDJ> and did the same
2021-07-09 05:58:25 <mps> Daanct12: only security fixes and important bugs are backported to stable
2021-07-09 05:59:17 <mps> else we should move from using stable release to rolling only distro
2021-07-09 06:16:43 <anjan> Hi, what is the license for the patches and apkbuilds in aports?
2021-07-09 06:16:47 <anjan> Is it all gpl'ed?
2021-07-09 07:28:04 <Danct12> mps, so basically the current version on stable is that it, no more version updates
2021-07-09 07:28:20 <PureTryOut> Yeah, what use would stable otherwise be?
2021-07-09 07:28:40 <PureTryOut> Just patch release upgrades and backports for security fixes and important bugs
2021-07-09 07:28:50 <Danct12> right, i was asking because you mentioned about having to maintain the package on stable for 5 months or something
2021-07-09 07:29:01 <Danct12> on pmos devel, so just asking to be sure
2021-07-09 07:29:11 <PureTryOut> Yes, for security and bug fixes. Also, 6 months normally, just until the next stable release
2021-07-09 07:29:29 <PureTryOut> And the main repository has support for up to 4 years I think? Not sure
2021-07-09 07:29:42 <Danct12> i see, thanks for clarification
2021-07-09 07:30:44 <PureTryOut> Np
2021-07-09 07:30:53 <mps> PureTryOut: right, 2 years for main
2021-07-09 07:31:03 <PureTryOut> Ah 2, I was mistaken. Thanks
2021-07-09 07:43:44 <ikke> 4 releases, with 6 months between releases 
2021-07-09 08:01:53 <clandmeter> looks like we found the issue regarding broken forking on gitlab.
2021-07-09 08:02:06 <clandmeter> need to restart gitlab and co
2021-07-09 08:02:17 <clandmeter> hold your horses
2021-07-09 08:02:40 <ikke> unrznbl[m]: ^
2021-07-09 08:07:05 <clandmeter> restarted and forked successfully 
2021-07-09 08:57:20 <PureTryOut> ikke: just got a report that edge armv7 is giving lots of BAD signatures on dl-cdn, not just a single package
2021-07-09 08:57:53 <ikke> We should investigate what is causing this 
2021-07-09 08:59:47 <PureTryOut> It seems to happen more often now so yes
2021-07-09 09:04:25 <nmeum> is the riscv64 builder stuck again? the build page claims that it is building testing/up but that seems to have failed and it hasn't attempted to build anything else in a while
2021-07-09 09:21:40 <ncopa> could it be the rsync issue? causing bad signatures?
2021-07-09 11:07:43 <ikke> PureTryOut: do you have examples of packages?
2021-07-09 11:09:45 <PureTryOut> pulseaudio (with all subpackages), libcanberra, libgusb, sane, colord
2021-07-09 11:10:34 <ikke> I installed plasma (449 packages) without issue
2021-07-09 11:10:57 <ikke> including pulseaudio
2021-07-09 11:11:04 <PureTryOut> on armv7? from dl-cdn?
2021-07-09 11:11:14 <ikke> yes
2021-07-09 11:11:42 <PureTryOut> Hmm idk then, the user that reported it gave the usual apk output as evidence.
2021-07-09 11:11:48 <PureTryOut> Maybe it fixed itself magically in the mean time?
2021-07-09 11:12:02 <JuniorJPDJ> or that was his unstable network connection
2021-07-09 11:12:24 <clandmeter> or a cdn that is broken
2021-07-09 11:14:08 <ikke> PureTryOut: can you ask that user to try again, see if they still have issues?
2021-07-09 11:15:00 <PureTryOut> Not really, they switched to a different mirror in the mean time
2021-07-09 11:15:57 <ikke> oh, ok
2021-07-09 11:16:42 <ikke> I don't see rsync issues
2021-07-09 11:48:23 <markand> PureTryOut, does it uses a http proxy in an enterprise?
2021-07-09 11:48:30 <markand> I had some issues in the past like this :)
2021-07-09 12:00:47 <PureTryOut> idk, probably not
2021-07-09 12:00:57 <PureTryOut> since this is from a pmOS user, thus a phone
2021-07-09 13:26:41 <unrznbl[m]> ikke: thanks for following up about forking, I'll get to work adding/upgrading a few packages.
2021-07-09 15:20:43 <unrznbl[m]> ncopa: thanks for adding the cfengine package. I have submitted an MR to upgrade edge to our latest LTS: 3.18.0 which we recently released. :)
2021-07-09 15:22:41 <unrznbl[m]> Is there a doc about back porting to releases?
2021-07-09 15:23:15 <ikke> afaik, no
2021-07-09 15:23:44 <ikke> But we typically only backport bugfixes / patch / security upgrades
2021-07-09 15:24:18 <unrznbl[m]> Right. Makes sense. So I will leave this as is. No backports. :)
2021-07-09 16:36:45 <unrznbl[m]> could I trouble someone to merge this upgrade cfengine MR? Appreciate it. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22990
2021-07-09 16:38:49 <unrznbl[m]> I am going to work on supporting OpenRC with services promises as well as try to get users promises working as well. :) So there might be an update or two coming for those as well in the next week or two.
2021-07-09 16:53:09 <unrznbl[m]> Is there a preference for including openrc scripts for daemons in the "same" package versus a separate package? Include in community/cfengine or in a new package: community/cfengine-openrc and then make a dep in cfengine to cfengine-openrc?
2021-07-09 16:53:14 <PureTryOut> Is wpa_supplicant pre-installed on the minimal Alpine image? If not, is it not meant to be installable without ethernet access?
2021-07-09 16:53:37 <ikke> unrznbl[m]: we have default provisions for that
2021-07-09 16:53:48 <PureTryOut> unrznbl: always use `$pkgname-openrc`. No need to manually split it, just add the subpackage and abuild will figure it out
2021-07-09 16:53:53 <ikke> just move the files to the correct location, and add a $pkgname-openrc subpackage
2021-07-09 16:54:22 <unrznbl[m]> PureTryOut (matrix.org): I just installed on an x86_64 laptop and I was able to do `alpine-setup` and connect to wifi so... installed by default?
2021-07-09 16:54:40 <unrznbl[m]> ikke: ack, right. I forgot about sub-packages. Will do that. 👍️
2021-07-09 16:55:14 <unrznbl[m]> PureTryOut (matrix.org): I installed, oops, I installed "standard" not minimal. Right. So I don't know.
2021-07-09 16:55:38 <unrznbl[m]> What is minimal? I don't see it in downloads page FWIW.
2021-07-09 16:56:10 <ikke> standard
2021-07-09 16:56:24 <ikke> (minimal compared to extended :))
2021-07-09 16:56:48 <minimal> I'm minimal :-)
2021-07-09 16:57:16 <mps> unrznbl[m]: minimal are normal install media
2021-07-09 16:58:14 <PureTryOut> Ok thanks
2021-07-09 16:59:51 <mps> standard and extended, besides netboot
2021-07-09 17:00:10 <mps> and standard also have wpa_s
2021-07-09 17:08:14 <unrznbl[m]> it seems pretty straightforward for me to add openrc scripts for cfengine, should I just WIP my 3.18.0 upgrade MR and get that stuff in there too with that? Adding support for services and users promises will be more involved I think so could be a next MR with changes to cfengine-masterfiles most likely.
2021-07-09 17:08:51 <unrznbl[m]> s/WIP/draft/
2021-07-09 17:08:52 <alpine-meetbot> unrznbl[m] meant to say: it seems pretty straightforward for me to add openrc scripts for cfengine, should I just draft my 3.18.0 upgrade MR and get that stuff in there too with that? Adding support for services and users promises will be more involved I think so could be a next MR with changes to cfengine-masterfiles most likely.
2021-07-09 17:13:35 <Danct12> can someone checkout !22989?
2021-07-09 17:26:15 <unrznbl[m]> Danct12: nice! you are making me want to game now :O
2021-07-09 17:45:44 <unrznbl[m]> is there a concept of say an "umbrella" service which controls multiple other services in openrc? (redirect me to #x if need be)
2021-07-09 17:47:09 <ikke> unrznbl[m]: afaik, no
2021-07-09 17:47:41 <unrznbl[m]> cool. I asked ncopa on the MR fwiw. I'll just have three separate services then. 👍️ working so far. :)
2021-07-09 17:47:58 <unrznbl[m]> now have to figure out how to package them... so many examples in aports! :)
2021-07-09 17:48:22 <ikke> You could maybe use something like 'needs' to pull other services
2021-07-09 17:48:51 <eletrotupi> Hello! What is the correct way to deal with ruby packages on Alpine? Should we pack them just like python ones? 
2021-07-09 17:49:41 <eletrotupi> Also, is my assumption correct that Alpine intend to keep only support for the latest ruby's release?
2021-07-09 17:51:59 <ikke> eletrotupi: there are other ruby packages, look how they are packages
2021-07-09 17:52:21 <ikke> eletrotupi: and within one release of alpine, we indeed typically only keep one versions (maintaining more would be a lot of work)
2021-07-09 17:52:30 <dalias> bleh, since getting an upgraded firefox from reinstalling all packages, firefox is crashing all the time now
2021-07-09 17:53:08 <dalias> looks like oom, but i doubled swap and it's still happening
2021-07-09 17:53:27 <dalias> could firefox have introduced some new overcommit bs where it's allocating way more memory than it needs?
2021-07-09 17:53:55 <unrznbl[m]> ikke: right. I think I'll leave them separate for now. All three are rather independent. :)
2021-07-09 17:56:40 <mps> dalias: how much ram you have?
2021-07-09 17:57:04 <mps> FF works for me on 4GB RAM, aarch64
2021-07-09 17:58:28 <dalias> 2GB, 4GB swap
2021-07-09 17:58:36 <dalias> but i do not enable overcommit
2021-07-09 17:58:51 <dalias> never had major problems with it oom'ing before even with just half that swap
2021-07-09 17:59:05 <dalias> it's only the new version doing it
2021-07-09 17:59:15 <mps> could be, it 'likes' to eat memory
2021-07-09 17:59:23 <dalias> (before i had last pre-proton version, now 89)
2021-07-09 17:59:51 <mps> in nearly every new release it is more 'hungry'
2021-07-09 18:00:23 <dalias> yep..
2021-07-09 18:00:24 <dalias> so awful
2021-07-09 18:00:38 <dalias> every release gets worse, but you can't use old releases because they have vulns
2021-07-09 18:00:46 <mps> you can disable proton, though I forgot how
2021-07-09 18:01:19 <dalias> yes, i did that first thing :)
2021-07-09 18:01:28 <dalias> just using it as a reference
2021-07-09 18:01:37 <dalias> since i forget the exact version number
2021-07-09 18:02:06 <mps> I use it in 4GB and no swap
2021-07-09 18:04:04 <dalias> but with overcommit on, i guess
2021-07-09 18:04:35 <mps> yes
2021-07-09 18:05:04 <dalias> i wish there were a good standard command to show memory usage
2021-07-09 18:08:38 <eletrotupi> Ok ikke, thanks. So I'll start packaging some dependencies then
2021-07-09 18:32:48 <markand> hey regarding !22986 do I really need to disable many packages because py3-importlib-metadata is not available on ppc64le?
2021-07-09 18:33:01 <markand> I mean setting arch="all !ppc64le" on almost all of them
2021-07-09 18:33:42 <ikke> yes
2021-07-09 18:33:53 <ikke> anything that depends on it needs to be explicitly disabled
2021-07-09 18:35:32 <markand> (ノಠ益ಠ)ノ彡┻━┻
2021-07-09 18:35:39 <markand> ┬─┬ノ(º _ ºノ) 
2021-07-09 18:35:46 <markand> okay lets do some rebase -i 
2021-07-09 18:36:57 <markand> so arch="noarch !ppc64le" is correct?
2021-07-09 18:37:29 <ikke> yes, but also add a comment why it's disabled (missing py3-importlib-metadata)
2021-07-09 18:37:47 <markand> yes
2021-07-09 18:45:34 <ericonr> zipp having issues on ppc64le seems so arbitrary :o
2021-07-09 18:46:34 <markand> PR ready :)
2021-07-09 18:46:45 <markand> mkdocs is really awesome 
2021-07-09 18:47:09 <markand> with material theme it's pretty great
2021-07-09 19:02:17 <unrznbl[m]> Is there a standard way to perform actions after install, like `rc-update add cf-execd default` and such? I'd like to add three daemons which have working openrc initd scripts to the default runlevel at the end of the install process.
2021-07-09 19:02:48 <ikke> unrznbl[m]: not if you want to contribute it to alpine
2021-07-09 19:02:56 <ikke> packages should not automatically enable services
2021-07-09 19:03:08 <unrznbl[m]> I added such commands to my existing `cfengine.post-install` script which in `APKBUILD` is referenced with `install="$pkgname.post-install"`
2021-07-09 19:03:14 <unrznbl[m]> oh. right on.
2021-07-09 19:04:04 <unrznbl[m]> our thinking was if you install a management software, you want it to run. But I was also thinking the other way which is "this tool can be used without the services, just not normally" so by default do less.
2021-07-09 19:04:21 <unrznbl[m]> which I imagine is the alpine point of view: "do less by default"?
2021-07-09 19:05:45 <unrznbl[m]> so how would I make it "easy" for a user to enable services? Just include docs? If a person "bootstraps" and starts using cfengine, the policy could certainly add the daemons as having them running is pretty much expected for normal use.
2021-07-09 19:06:19 <unrznbl[m]> bootstrap here is a specific cfengine thing if you aren't familiar, basically pull policy from local masterfiles or from a policy server.
2021-07-09 19:06:33 <ikke> It should be done through user action
2021-07-09 19:07:00 <unrznbl[m]> ok. And would you consider this "bootstrapping" process that we typically do to be user action? I would.
2021-07-09 19:07:23 <unrznbl[m]> Like I said, you could use it without bootstrapping, but it's pretty odd/unusual. Of course... I do it all the time ;) But I'm a cfengine developer.
2021-07-09 19:08:11 <unrznbl[m]> I'll do it that way since that makes most sense to me. Anyone who knows cfengine would expect those services to run and new folks should probably have them running. So during bootstrap I
2021-07-09 19:08:24 <unrznbl[m]> I'll make sure they are added to default runlevel and are running.
2021-07-09 19:08:29 <ikke> I'm more familiar with chef
2021-07-09 19:08:36 <ikke> There you also bootstrap a machine
2021-07-09 19:08:43 <ikke> but that certainly does not happen when you install a package
2021-07-09 19:08:56 <markand> I hate debian with passion in regard to this
2021-07-09 19:09:05 <markand> it's not up to a package to start itself
2021-07-09 19:09:23 <markand> especially since some services need lots of configuration before (mpd, http, mail, etc)
2021-07-09 19:13:36 <unrznbl[m]> right. Yeah, we really can't start the services until you bootstrap. But in most cases you would install and bootstrap before say rebooting and having those default runlevel services started.
2021-07-09 19:13:59 <unrznbl[m]> so I will make our bootstrap process add the services to default runlevel and start them the first time to get things going. 👍️
2021-07-09 19:14:07 <ikke> unrznbl[m]: usually you provide documentation to the users how to use it
2021-07-09 19:14:19 <ikke> there you can mention they need to bootstrap and enable services
2021-07-09 19:14:23 <unrznbl[m]> this all stems from me finding cfengine in alpine but finding it not very functional.
2021-07-09 19:14:35 <unrznbl[m]> exactly. Yes. This is pretty well documented at this point I'd say. :)
2021-07-09 19:14:47 <ikke> ok, then it should not be an issue
2021-07-09 19:14:59 <markand> unrznbl[m], some services bootstrap themselve on first start (e.g. sshd) 
2021-07-09 19:15:35 <unrznbl[m]> right. that makes sense also.
2021-07-09 19:15:44 <unrznbl[m]> https://docs.cfengine.com/docs/3.18/guide.html#install-it (install, bootstrap, install, bootstrap) :)
2021-07-09 19:16:02 <mps> markand: these are started by intalling alpine, i.e. setup-*
2021-07-09 19:16:29 <mps> not that they add self to runlevels
2021-07-09 19:16:54 <ikke> mps: markand means that sshd generates host keys on first start of the service
2021-07-09 19:17:34 <mps> that is true, but openssh doesn't add self to any runlevel
2021-07-09 19:17:58 <ikke> I don't think that anyone claimed that
2021-07-09 19:18:13 <markand> nobody said that 
2021-07-09 19:18:14 <mps> then I misunderstood
2021-07-09 19:22:14 <unrznbl[m]> Cool. I put my MR back to Ready from Draft. Removed the runlevel stuff and should be good to go.
2021-07-09 20:44:43 <anjan> Hi, can someone please review this MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22762
2021-07-09 20:48:15 <ikke> anjan: instead of chmod-clean, you can do: `export GOFLAGS="$GOFLAGS -modcacherw"`
2021-07-09 20:48:36 <anjan> ikke: where would I do that?
2021-07-09 20:48:47 <anjan> before build?
2021-07-09 20:49:35 <ikke> yes
2021-07-09 20:50:08 <ikke> And you could also add -ldflags '-w -s'
2021-07-09 20:50:26 <ikke> that should make the binary even smaller
2021-07-09 20:50:45 <anjan> ok done. thank you
2021-07-09 20:51:04 <ikke> sorry, outside of the build function
2021-07-09 20:51:28 <ikke> although, I guess in this case it does not matter
2021-07-09 20:51:51 <anjan> ikke: ya, I just did a quick grep on aports and everyone does in inside the build function
2021-07-10 07:03:27 <nmeum> ikke: is -ldflags '-s -w' really neccessary? shouldn't the symbol and dwarf table be removed by strip(1) anyhow?
2021-07-10 07:04:06 <ikke> nmeum: does it?
2021-07-10 07:06:30 <ikke> It seems it does
2021-07-10 07:06:32 <ikke> size is similar
2021-07-10 07:06:49 <ikke> -s -w: 55775232
2021-07-10 07:06:53 <ikke> strip: 55775544
2021-07-10 07:08:28 <nmeum> not sure where the 300 bytes difference comes from but yeah, strip should remove that information
2021-07-10 07:08:51 <nmeum> regarding -modcacherw: we could just add that to GOFLAGS in /etc/abuild.conf
2021-07-10 07:09:02 <nmeum> makes it a bit easier to oackage go stuff
2021-07-10 07:09:26 <nmeum> I think I will create an MR for that
2021-07-10 07:26:50 <wener> I think is ok in apkbuild, like https://wiki.archlinux.org/title/Go_package_guidelines
2021-07-10 07:27:31 <ikke> nmeum: I was also thinking about adding GOMODCACHE
2021-07-10 07:30:58 <nmeum> ikke: didn't we encounter problems with caching stuff across builds in the past?
2021-07-10 07:31:03 <nmeum> e.g. with rust and CARGO_HOME https://gitlab.alpinelinux.org/alpine/abuild/-/commit/10aa67a0cab480c9df2a050e0d102aca0cf18a02
2021-07-10 07:31:38 <ikke> nmeum: Yes, my idea was to add $arch or something like that in there
2021-07-10 07:31:45 <ikke> or maybe $hostname
2021-07-10 07:32:21 <ikke> The issue was with builders sharing the same /var/cache/distfiles
2021-07-10 07:32:58 <ikke> nmeum: fyi, it's now cached in ~/go / ~/.cache/go-build
2021-07-10 07:33:04 <ikke> so it's already cached between builds
2021-07-10 07:34:03 <nmeum> builds don't start with a clean $HOME on the builders?
2021-07-10 07:34:17 <ikke> no
2021-07-10 07:34:35 <ikke> packages and aports live in $home
2021-07-10 07:34:35 <nmeum> if it's cached anyhow it makes sense to set GOMODCACHE to also cache between builds with abuild rootbld etc
2021-07-10 07:35:42 <nmeum> also: there should be no need for -modcacherw or options="chmod-rw" then if the go cache is in $HOME/.cache and not in $srcdir anyhow
2021-07-10 07:36:09 <ikke> right
2021-07-10 07:37:09 <nmeum> +1 on setting GOMODCACHE in abuild/abuild.conf from me then :)
2021-07-10 07:37:22 <ikke> but I think the build cache should be cleaned somehow
2021-07-10 07:37:36 <ikke> so not ~/go, but ~/.cache/go-build
2021-07-10 07:37:42 <ikke> which can grow pretty big
2021-07-10 07:38:19 <nmeum> I manually clean /var/cache periodically, /var/cache/distfiles can also grow quite large over time
2021-07-10 07:38:41 <ikke> yes, but that's expected
2021-07-10 07:39:00 <ikke> but this is about $HOME/.cache
2021-07-10 07:39:11 <ikke> another one is $HOME/.cache/yarn
2021-07-10 07:39:41 <nmeum> I would simply set GOMODCACHE to /var/cache/distfiles/go analog to that CARGO_HOME setting we had previously
2021-07-10 07:40:44 <ikke> does go handle concurrent writes to GOMODCACHE?
2021-07-10 07:42:45 <nmeum> I don't know, but as you suggested we could use $arch and/or $hostname in $GOMODCACHE e.g. /var/cache/distfilse/go/$arch/$hostname? That should also work for CARGO_HOME and fix the issue we had with it previously, right?
2021-07-10 07:43:01 <ikke> Yes, though, only one is enough
2021-07-10 07:43:24 <nmeum> right
2021-07-10 07:43:51 <ikke> If we want it to be unique between releases, we should use $hostname
2021-07-10 07:43:57 <nmeum> yep
2021-07-10 07:45:54 <ikke> You mentioned rootbld, but I don't think that works because the modules are downloaded during the build phase
2021-07-10 07:46:05 <ikke> unless we add a step to download the modules before
2021-07-10 07:46:30 <ikke> `go mod download`
2021-07-10 08:05:41 <nmeum> ikke: I don't think that's a problem rootbld bind mounts $SRCDEST on startup https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2441
2021-07-10 08:06:20 <ikke> That defaults to $STARTDIR?
2021-07-10 08:06:26 <ikke> $startdir*
2021-07-10 08:06:42 <nmeum> so files written in the build phase to $SRCDEST will afterwards be available on the host and thus to all abuild rootbld invocations invoked afterwards
2021-07-10 08:07:04 <nmeum> $SRCDEST defaults to /var/cache/distfiles https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.conf#L20
2021-07-10 08:07:24 <ikke> ah, right
2021-07-10 08:44:04 <ikke> 0https://blog.appsignal.com/2020/06/24/git-is-about-communication.html
2021-07-10 10:50:56 <clandmeter> Why not put effort in enabling rootbld for builders?
2021-07-10 10:51:28 <clandmeter> It should solve ~ issues
2021-07-10 10:52:18 <ikke> You still might want to cache things, though
2021-07-10 10:53:02 <clandmeter> Which things?
2021-07-10 10:54:32 <ikke> you know, things
2021-07-10 10:59:14 <ikke> But if we want to enable rootbld, we need to verify everything that requires it has options="net"
2021-07-10 10:59:25 <ikke> I believe PureTryOut already did most of the work on that
2021-07-10 11:02:41 <PureTryOut> For main and community at least, but I'm sure there is new stuff
2021-07-10 11:02:45 <PureTryOut> And I didn't do testing yet
2021-07-10 11:05:04 <ikke> and another challenge
2021-07-10 11:05:15 <ikke> I suppose we want to at least be able to verify this in CI
2021-07-10 11:05:58 <ikke> I don't think bubblewrap works in docker without extra privileges, and I think it's superfluous
2021-07-10 11:06:30 <ikke> But maybe we could somehow disable network during the build phase, but I'm not sure if that's easy without abuild support
2021-07-10 11:15:15 <clandmeter> ikke: i think the benefits outweigh the cost.
2021-07-10 11:15:34 <clandmeter> imho no package should directly be able to influence another
2021-07-10 11:15:43 <ikke> yes, I agree on that
2021-07-10 11:16:04 <clandmeter> and i think the others we can work around or maybe even fix
2021-07-10 11:16:49 <ikke> Any idea how to handle CI?
2021-07-10 11:18:39 <PureTryOut> I'd love to have `abuild rootbld` be the default on builders and CI
2021-07-10 11:19:03 <clandmeter> ikke: kill the default route? :)
2021-07-10 11:19:11 <ikke> clandmeter: You need to do it at the right moment
2021-07-10 11:19:24 <ikke> PureTryOut: bubblewrap does not work in docker
2021-07-10 11:19:41 <ikke> well, is blovked
2021-07-10 11:19:43 <ikke> blocked*
2021-07-10 11:19:51 <clandmeter> abuild in steps
2021-07-10 11:20:00 <clandmeter> steps as in general not ci related
2021-07-10 11:20:07 <ikke> yes, understood
2021-07-10 11:20:34 <clandmeter> or kill docker
2021-07-10 11:20:38 <clandmeter> :D
2021-07-10 11:20:56 <ikke> PureTryOut: CI is already isolated, so we do not really need rootbld there
2021-07-10 11:22:00 <ikke> The only thing we need in CI is to verify that no network is used during build
2021-07-10 11:23:02 <clandmeter> ikke: we could change the executor to shell
2021-07-10 11:23:07 <ikke> meh
2021-07-10 11:23:34 <ikke> So you build things on the host just to be able to use rootbld?
2021-07-10 11:23:58 <clandmeter> just so the setup is equal 
2021-07-10 11:24:08 <ikke> It's not in lxc
2021-07-10 11:24:14 <ikke> so it's not equal
2021-07-10 11:24:38 <clandmeter> thats not the same
2021-07-10 11:24:49 <clandmeter> you cannot compare those setups
2021-07-10 11:24:52 <ikke> The advantage of docker is that we control the environment via images
2021-07-10 11:24:58 <clandmeter> you want to run it in rootbld
2021-07-10 11:25:04 <ikke> moving to a shell executor we need to manage everything on the host
2021-07-10 11:25:34 <clandmeter> i bet its not easy
2021-07-10 11:25:40 <clandmeter> probably has lots of downsides
2021-07-10 11:25:48 <clandmeter> im just suggesting it
2021-07-10 11:28:14 <clandmeter> https://docs.gitlab.com/runner/executors/index.html
2021-07-10 11:29:54 <ikke> Right now, the CI hosts are disposable
2021-07-10 11:30:57 <ikke> Just register the runner, and it can execute CI jobs
2021-07-10 11:31:51 <clandmeter> isnt that the same as rootbld?
2021-07-10 11:32:11 <ikke> You need to setup the host so that it can build packages
2021-07-10 11:32:48 <ikke> install alpine-sdk, add the build script
2021-07-10 11:33:12 <ikke> clean up afterwards
2021-07-10 11:41:33 <clandmeter> rootbld doesnt touch the host, only the chroot it setups right?
2021-07-10 11:41:43 <clandmeter> so you need abuild and friends and a copy of aports
2021-07-10 11:43:47 <ikke> yes, though the runner would handle the latter part
2021-07-10 11:44:07 <ikke> but you need to make sure all the rest is installed
2021-07-10 11:45:19 <clandmeter> what about current ci logic
2021-07-10 11:45:23 <clandmeter> can it be kept the same?
2021-07-10 11:45:37 <clandmeter> i see some differences in parallel processing 
2021-07-10 12:38:12 <ikke> clandmeter: fyi, the gitlab build finished now for 14.0
2021-07-10 13:43:13 <nmeum> rootbld on the builders would be nice
2021-07-10 13:43:39 <nmeum> caching things between different rootbld runs is entirely possible
2021-07-10 13:44:07 <nmeum> options="net" is also not an issue, we can just add it as we go and it's actually nice to know which aports require a network connection for building
2021-07-10 13:46:34 <donoban> s
2021-07-10 13:46:59 <donoban> (wops misskey)
2021-07-10 14:08:47 <JuniorJPDJ> it would be supercool to see if my aports crash without network connectivity
2021-07-10 14:08:49 <JuniorJPDJ> +1
2021-07-10 14:08:58 <JuniorJPDJ> as I'm unable to check it now
2021-07-10 14:09:13 <nmeum> you can check with abuild rootbld
2021-07-10 14:09:29 <rzl[m]> You can try with unshare -n, I think
2021-07-10 14:09:36 <JuniorJPDJ> I even wasnt aware that aports arent built in chroot
2021-07-10 14:09:59 <JuniorJPDJ> <rzl[m] "You can try with unshare -n, I t"> cool idea, didnt thought about it
2021-07-10 14:10:41 <JuniorJPDJ> unshare: unshare failed: Operation not permitted
2021-07-10 14:10:50 <JuniorJPDJ> wow, no unprivilaged namespaces enabled by default?
2021-07-10 14:10:57 <rzl[m]> nmeum mentioned rootbld, it uses bubblewrap so it's probably even better since it's also a chroot with only deps installed
2021-07-10 14:13:07 <rzl[m]> Unprivileged namespaces are enabled. Try unshare -rn
2021-07-10 14:16:45 <JuniorJPDJ> i prefer unshare -cn
2021-07-10 14:16:52 <JuniorJPDJ> as i want to build apkbuild
2021-07-10 14:16:54 <JuniorJPDJ> but thanks :D
2021-07-10 14:19:25 <JuniorJPDJ> ok, it's not that easy
2021-07-10 14:21:18 <JuniorJPDJ> easiest way was doing sudo unshare -n sudo -i -u <my username>
2021-07-10 14:21:20 <JuniorJPDJ> and then abuild
2021-07-10 14:29:35 <rzl[m]> See https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2433
2021-07-10 14:33:10 <rzl[m]> If net is not in options, it passes --unshare-net to bubblewrap
2021-07-10 16:29:05 <ikke> nmeum: anything using go or rust we can already make sure in advance
2021-07-10 16:29:12 <ikke> and probably haskell as well
2021-07-10 16:47:55 <orbea> some python modules like to silently download stuff to a .egg directory
2021-07-10 17:12:21 <nmeum> ikke: i am always using abuild rootbld locally and adding options="net" if I encounter packages which need it
2021-07-10 17:12:31 <nmeum> some go packages still vendor dependencies and don't need options="net"
2021-07-10 17:15:17 <ikke> right
2021-07-10 17:30:05 <PureTryOut> same, I always add the option when I encounter a package that requires it
2021-07-10 17:48:16 <nmeum> which mirror has testing/ packages for riscv64? dl-cdn does not seem to have them yet or am I blind?
2021-07-10 17:50:18 <ikke> testing is not uploaded yet
2021-07-10 17:50:35 <ikke> https://dev.alpinelinux.org/~clandmeter/packages/riscv64/edge/testing/riscv64/
2021-07-10 17:51:05 <nmeum> ok, sweet I will use that then
2021-07-11 09:21:34 <Testeree> Is there a way to cache package build process when testing patches with `abuild -r` ?
2021-07-11 09:22:02 <ikke> add -K
2021-07-11 09:23:18 <Testeree> Thanks @ikke
2021-07-11 09:25:11 <ikke> Testeree: note that you can also use separate build steps
2021-07-11 09:25:28 <ikke> abuild unpack deps prepare build check rootpkg index clean
2021-07-11 09:25:31 <ikke> those are the default steps
2021-07-11 09:26:10 <ikke> so you can run abuild unpack deps prepare build the first time, then adjust patches, and run abuild build again to just retry the build
2021-07-11 09:26:42 <Testeree> oh cool
2021-07-11 12:07:30 <bs2k> what should I do to build an alpine rootfs image with custom packages
2021-07-11 12:24:17 <ikke> bs2k: look at the scripts in aports/scripts
2021-07-11 13:45:44 <mps> does xorg-server need to depend on font-misc-misc
2021-07-11 13:46:20 <mps> (no, but rhethorical question)
2021-07-11 13:46:53 <mps> (we want debian dependency hell also on alpine0
2021-07-11 13:46:57 <mps> (we want debian dependency hell also on alpine)
2021-07-11 13:47:57 <mps> actually, *we* want alpine to be ubuntu/fedora
2021-07-11 13:48:38 <mps> or pmOS :D
2021-07-11 13:50:45 <mps> oh, and my FS crashed, very nice day :/
2021-07-11 13:57:54 <ikke> Oh, FS crashed, what happened?
2021-07-11 13:59:48 <mps> investigating. last few days I did a lot of copying between internal emmc and external mmc, so something must be messed
2021-07-11 14:00:35 <mps> and testing different kernels with f2fs which is known to be 'problematic' with kernel changes
2021-07-11 14:01:41 <mps> mkfs.f2fs with new kernel and another rsync will probably fix this problem
2021-07-11 14:02:38 <bs2k> ikke: thanks!
2021-07-11 14:03:03 <mps> (advice to end users: use f2fs only on chromeos or android :) )
2021-07-11 14:04:33 <mps> another advice: smoke only good old Dutch tobacco ;) (not this made by licensed manufacturers)
2021-07-11 15:14:01 <donoban> I'm sorry mps , I hope nothing it's lost
2021-07-11 15:28:04 <nmeum> why is the riscv64 builder failing with old buildlogs?
2021-07-11 15:28:11 <nmeum> for example: https://build.alpinelinux.org/buildlogs/build-edge-riscv64/testing/telegram-tdlib/telegram-tdlib-1.6.0-r1.log
2021-07-11 15:28:16 <nmeum> > started Sun, 06 Jun 2021 15:05:15 +0000
2021-07-11 15:28:29 <nmeum> but for some reason it's the most recent failure
2021-07-11 15:29:47 <ikke> maybe the latest buildlogs are not uploaded
2021-07-11 15:34:09 <mps> donoban: thanks. but no worries, I have backup
2021-07-11 16:04:01 <donoban> :)
2021-07-11 20:18:02 <tomleb> Hi folks, I'm having issue with the CI for armhf, somehow the build timed out after taking 1h (while most other builds take 10m). !23040
2021-07-11 20:32:17 <tomleb> I'm unsure how to debug this since I don't have a armhf machine :/ 
2021-07-11 21:24:35 <kevint> Hmmm judging by the "npm ERR! cb() never called!" error maybe it has to do with an npm caching problem on the runner? Not sure how to fix that though :/
2021-07-11 21:48:30 <qiu3344> hello
2021-07-11 21:49:00 <qiu3344> can someone tell me what work is needed to merge !20759? (WIP: LLVM12)
2021-07-11 21:49:45 <qiu3344> I need this version of llvm to build ziglang form source
2021-07-11 21:59:22 <craftyguy> any chance this could get reviewed soon? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23011
2021-07-11 23:00:54 <tomleb> kevint: Ah, I see it's you! Well, it got merged anyway so I guess that "fixes" it.
2021-07-11 23:26:00 <kevint> tomleb haha works for me, thank you!
2021-07-12 06:35:28 <markand> llvm 12 <3 
2021-07-12 06:37:43 <markand> finally sanitizers for musl
2021-07-12 10:12:22 <ncopa> good day
2021-07-12 10:13:45 <ikke> ncopa: o/
2021-07-12 10:28:35 <donoban> hi guys
2021-07-12 12:10:31 <markand> o/
2021-07-12 12:28:39 <danieli> \\o
2021-07-12 12:28:41 <danieli> dangit
2021-07-12 13:21:22 <Danct12> hi 
2021-07-12 13:27:47 <Ariadne> hi
2021-07-12 13:31:31 <Danct12> how are you all
2021-07-12 14:08:39 <Ariadne> i’m fine
2021-07-12 14:14:03 <Danct12> that's great! =)
2021-07-12 14:39:03 <Newbyte> Is there anything I need to do to get !22412 merged?
2021-07-12 14:40:02 <ikke> Newbyte: I'll try to look at it in a bit
2021-07-12 14:40:11 <Newbyte> Thanks!
2021-07-12 14:40:21 <ikke> If someone is not ahead of me :)
2021-07-12 17:39:15 <craftyguy> also would like to see this one merged soon-ish (new aport to testing) !23011 :D 
2021-07-12 19:54:39 <clandmeter> maxice8: looks like source-hightlight still needs make -j1 check
2021-07-12 20:09:51 <maxice8> noted
2021-07-12 23:47:20 <adamplumb> I've been investigating some issues with the gnome-authenticator port on aarch64 (https://pkgs.alpinelinux.org/package/v3.14/community/aarch64/gnome-authenticator).  There is a patch in the aports folder (c222f505a8bf623fbf057f9e1ae0a52e9df3edb7.patch) that doesn't seem to have been applied cleanly to the package i downloaded
2021-07-12 23:49:15 <adamplumb> I'm running on pmOS, should I report the bug in the aports gitlab?
2021-07-12 23:49:30 <adamplumb>  * I'm running on pmOS, should I report the bug in the aports gitlab?  Not 100% sure it's a bug yet though
2021-07-12 23:51:26 <craftyguy> adamplumb: before you get too far into it, the gnome-authenticator developer's stance on packaging their app is "don't package it": https://gitlab.gnome.org/World/Authenticator/-/issues/219
2021-07-12 23:53:20 <adamplumb> yikes, what an attitude
2021-07-12 23:57:36 <adamplumb> i don't necessarily need to package it, just was trying to help the community.  I was just seeing if I could get it to work, without much luck even with the patch in place
2021-07-13 06:23:17 <Newbyte> adamplumb: what makes you think it wasn't applied cleanly? 
2021-07-13 06:31:21 <Newbyte> Also, could someone push the merge button on !22412? It was going to be merged but the merge was cancelled because someone else merged something while the pipeline was running. 
2021-07-13 06:31:36 <Newbyte> s
2021-07-13 06:31:51 <Newbyte> oops, never mind that 
2021-07-13 07:52:48 <PureTryOut> Newbyte: I clicked the button
2021-07-13 07:53:22 <Newbyte> thank you!
2021-07-13 07:59:14 <ikke> 👍
2021-07-13 09:12:52 <markand> anyone tried finit? looks like a convenient alternative to openrc: https://github.com/troglobit/finit
2021-07-13 10:54:26 <ncopa> I havent tried it, but it does look interesting indeed
2021-07-13 11:17:56 <Sheila> imo it puts too many things under one roof.
2021-07-13 12:54:16 <unrznbl[m]> yeah, bummer, surnia on a fresh install fails to boot it seems. :( I will try to debug when I can. :)
2021-07-13 13:19:02 <adamplumb> There is a bug in the giara package that basically renders it unusable on mobile, where authentication with reddit is broken.  They've merged in a fix upstream (https://gitlab.gnome.org/World/giara/-/merge_requests/12/diffs) four months ago but I don't know when they plan to do another release.  There technically is a workaround, but on my pinephone it was a huge pain in the butt (had to direct stdout to a file and copy/paste and fix a
2021-07-13 13:19:02 <adamplumb> url).  Is this something that would be worth a temporary patch to the giara package to get it working for alpine users?
2021-07-13 13:32:56 <JuniorJPDJ> imo it's a good idea
2021-07-13 14:23:59 <wener> is the s6 author working on a openrc alternative, is there any progress ?
2021-07-13 14:30:59 <ikke> "(Update: the project has found a sponsor! Expect more news in this space in the months to come.)"
2021-07-13 14:31:06 <ikke> https://skarnet.com/projects/service-manager.html
2021-07-13 14:31:54 <wener> 👍
2021-07-13 14:36:37 <valerius> fuck yeah
2021-07-13 14:55:55 <jvoisin> nice
2021-07-13 15:00:09 <minimal> looking forward to it (assuming it will also cover containers) as work on s6-overlay seems to have stopped several months ago
2021-07-13 15:55:40 <craftyguy> what's the recommended way to set number of parallel jobs for make in an APKBUILD? should I leave out -jN and abuild will fill something in, or ??
2021-07-13 15:56:08 <ikke> craftyguy: we set MAKEFLAGS to -j$(nproc) in ./etc/abuild.conf
2021-07-13 15:56:24 <ikke> so in generally, do not set it, unless it's broken
2021-07-13 15:56:28 <craftyguy> ah ok, so I should just leave out any explicit -j
2021-07-13 15:56:31 <ikke> yes
2021-07-13 15:56:33 <craftyguy> thanks!
2021-07-13 18:26:47 <gjabell> can someone take a look at !22291 when they have a sec? build passes now
2021-07-13 18:50:40 <ikke> My vps provider is facing a DDOS attack, yay
2021-07-13 19:07:09 <Cogitri> Yuck
2021-07-13 19:07:22 <ikke> .
2021-07-13 19:45:38 <markand> yesterday french people where able to DDOS a french server without the use of botnets
2021-07-13 19:45:41 <markand> ¯\_(ツ)_/¯
2021-07-13 19:50:44 <markand> ow sounds like he really took the DDOS D:
2021-07-13 20:24:49 <pr78> Does anyone run Alpine in Azure?
2021-07-14 00:29:00 <craftyguy> is gitlab.alpinelinux.org down?
2021-07-14 00:29:27 <craftyguy> I'm getting a "gateway timeout", so I assume yes :(
2021-07-14 00:32:14 <bl4ckb0ne> out for me too
2021-07-14 04:26:43 <ikke> not sure what happened, but it's back
2021-07-14 06:42:21 <ncopa> good morning
2021-07-14 06:56:53 <indy> hi all, what is process to get some package from testing to main/community?
2021-07-14 06:57:49 <indy> pr78, i have pipelines in azure running same steps like on ubuntu (of course in container)
2021-07-14 07:11:47 <ikke> indy: are you the maintainer of that pakcage?
2021-07-14 07:11:52 <ncopa> indy: either create a MR or an issue, and explain that the package is tested and works for you. We will have a look at the packaging, initscripts etc and verify that it has a maintainer
2021-07-14 07:19:26 <indy> ikke, no
2021-07-14 07:19:55 <ikke> Then open an issue like ncopa suggested
2021-07-14 07:20:05 <ikke> Or even an MR if you're up to it
2021-07-14 07:20:22 <ikke> We'll ask the maintainer to look at it
2021-07-14 07:23:08 <indy> ikke, ncopa thanks
2021-07-14 12:26:14 <Newbyte> Cogitri: do you know why phosh is downloaded from repo.purepos.net instead of their Gitlab?
2021-07-14 12:35:26 <Cogitri> Not sure, maybe they package additional stuff in the tarballs over there
2021-07-14 12:43:41 <Newbyte> Cogitri: it seems they append the commit hash to the tarball from their GitLab :^(
2021-07-14 12:44:00 <Newbyte> Not sure how to handle that?
2021-07-14 12:44:13 <Newbyte> Maybe I should just wait for them to update the repo
2021-07-14 12:45:57 <Newbyte> No, never mind, it's the same from the repo
2021-07-14 12:51:20 <Newbyte> Never mind again, I was just confused
2021-07-14 12:54:15 <Cogitri> Ah, Gitlab custom upload always have a shasum in them, it’s super annoying
2021-07-14 13:09:54 <Newbyte> Yeah. Now to wait for Purism's repo to catch up
2021-07-14 13:30:40 <ikke> Cogitri: I think you can use releases to provide friendly urls for them
2021-07-14 13:34:10 <Thalheim> I've been burned by nginx upgrades on alpine one too many times. from 3.13.5 to 3.14: nginx: [emerg] dlopen() "/var/lib/nginx/modules/ngx_http_lua_module.so" failed (Error relocating /var/lib/nginx/modules/ngx_http_lua_module.so: lua_getexdata2: symbol not found) in /etc/nginx/modules/30_http_lua.conf:1
2021-07-14 13:34:43 <caskd-Alex> Thalheim: are you mixing repositories?
2021-07-14 13:35:38 <caskd-Alex> apk upgrade -a should fix this if you don't mix repositories
2021-07-14 13:36:24 <Thalheim> caskd-Alex: ok, that /did/ fix it, thanks! I don't think anything is mixed though.
2021-07-14 13:37:59 <caskd-Alex> interesting, did you upgrade only nginx?
2021-07-14 13:38:28 <Thalheim> ran 'apk upgrade' with no '-a'
2021-07-14 13:38:32 <ikke> Using -a (--available) is always recommended when switching between repos
2021-07-14 13:38:39 <ikke> (versions)
2021-07-14 13:39:11 <caskd-Alex> hm
2021-07-14 13:50:21 <mps> apk upgrade --available --simulate, before big upgrade/downgrade
2021-07-14 16:50:36 <mps> samba fails on rv64 due the segfault, looks related to bind segfaults
2021-07-14 17:09:44 <mps> clandmeter: any new options/drivers needed for linux-edge on riscv64?
2021-07-14 17:10:05 <mps> I'm working on upgrade to 5.13.2 right now
2021-07-14 17:10:13 <clandmeter> Nope
2021-07-14 17:10:30 <mps> ok
2021-07-14 17:13:48 <clandmeter> 12:46 <clandmeter> rndc-confgen
2021-07-14 17:13:48 <clandmeter> 12:46 <clandmeter> and it looks like libatomic related
2021-07-14 17:14:05 <clandmeter> Reg samba
2021-07-14 17:15:07 <mps> yes
2021-07-14 17:16:28 <mps> (people still use bind and batteries (: )
2021-07-14 17:16:29 <minimal> anyone familiar with the gcc predefined "__OPTIMIZE__" macro in Alpine? Trying to compile some C code what doesn't want it defined and haven't figured out where its being set
2021-07-14 17:20:42 <dalias> -U__OPTIMIZE__ should remove it
2021-07-14 17:20:55 <dalias> i think it's a standard gcc behavior tho
2021-07-14 17:21:13 <dalias> hmm no i don't get it on my gcc
2021-07-14 17:21:24 <dalias> on alpine
2021-07-14 17:21:43 <dalias> ohh you have to pass -Osomethingnonzero
2021-07-14 17:21:47 <dalias> so yes i see it now
2021-07-14 17:22:04 <dalias> and on stock gcc too
2021-07-14 17:22:24 <dalias> i would fix whatever broken software is inspecting stuff in __ namespace and expecting it not to match what standard gcc does
2021-07-14 17:23:48 <minimal> dalias: its the latest version of jitterentropy-library that wants to ensure that compiler optimisations are disabled so as not to reduce entropy
2021-07-14 17:26:33 <minimal> dalias: the thing is the Makefile defines "-O0" and I see several of the source files compiled fine with -O0, its only a single file with an ifdef __OPTIMIZE__ that is giving problems
2021-07-14 17:27:38 <ericonr-> 
ACTION still doesn't understand how jitter-entropy can be better than whatever the kernel can do

2021-07-14 17:29:09 <minimal> ericonr: jitter-entropy is in the kernel already (i.e. as a module) for its own "private" use, this is separate lib (from the same author) to be used by the likes of rngd
2021-07-14 17:31:50 <minimal> dalias: https://github.com/smuellerDD/jitterentropy-library/blob/master/src/jitterentropy-base.c#L57
2021-07-14 17:32:43 <minimal> and O0 is used: https://github.com/smuellerDD/jitterentropy-library/blob/master/Makefile#L6
2021-07-14 17:33:52 <Thermi> Err the last released iso for ppc64le doesn't boot in qemu
2021-07-14 17:34:16 <Thermi> grub first errors with an invalid number, then when trying to boot Linux lts, it says the vmlinuz image didn't exist
2021-07-14 17:34:17 <Thermi> %)
2021-07-14 17:36:01 <Thermi> The ppc64le standard image is also suspiciously small at around 18 MB
2021-07-14 17:36:21 <Thermi> Yes, the ISO has no kernel.
2021-07-14 17:37:03 <Thermi> And powerpc.elf file is 0 bytes in size
2021-07-14 17:37:13 <Thermi> mach_kernel is also 0 byte in size
2021-07-14 17:41:49 <dalias> minimal, sounds like nonsense
2021-07-14 17:48:31 <minimal> dalias: which aspect?
2021-07-14 17:57:12 <Thermi> mps, any idea about that ppc64le issue? ^
2021-07-14 17:57:23 <Thermi> Who do I need to bother about?
2021-07-14 17:57:35 <Thermi> (Also, the kopano MR should be finally up to date)
2021-07-14 18:00:44 <dalias> the idea that you get "entropy" out of compiler not performing optimization
2021-07-14 18:01:27 <mps> Thermi: sorry I don't know whom to ask.
2021-07-14 18:01:41 <Thermi> :<
2021-07-14 18:01:45 <dalias> if they really have some kind of dummy loop that's intended to measure slightly-entropic cpu behavior, and it's not properly constrained to actually do anything, they should properly constrain it rather than using -O0
2021-07-14 18:02:03 <dalias> but the whole thing sounds like a bunch of woo to me
2021-07-14 18:02:16 <mps> Thermi: I'm not sure if anyone except you is interested in ppc64le
2021-07-14 18:03:00 <mps> we already talked about ppc64le removal, and I vote for this
2021-07-14 18:03:39 <Thermi> Okay.
2021-07-14 18:03:42 <mps> afaik now we have only qemu for ppc64le, not any real hardware
2021-07-14 18:03:50 <Thermi> If that's the case, I don't even need to debug the issue I found then
2021-07-14 18:04:00 <dalias> :/
2021-07-14 18:04:21 <Thermi> I was/am only interested because the builder for ppc64le segfaulted when running a python test for bindings for a C lib
2021-07-14 18:04:27 <minimal> dalias: I think the idea there is some (measurable) entropy from individual CPUs but enabling compiler optimisation reduces or eliminates that so that's why they don't want it enabled.
2021-07-14 18:05:26 <dalias> if it's eliminating it, that means they didn't properly constrain the code to do anything
2021-07-14 18:05:27 <minimal> dalias: obviously it makes more sense to use a "proper" entropy source (i.e. TPM, hardware RNG, etc) but for machines that don't have those any entropy is better than none
2021-07-14 18:05:44 <dalias> and fixing it would likely be as simple as putting some volatiles in the right places
2021-07-14 18:06:11 <dalias> the kernel already does this with much better resources (e.g. interrupt timings) to mix in
2021-07-14 18:08:06 <minimal> dalias: it "way above my paygrade" but they are checking/ensuring compliance with SP 800-90B standards for this sort of stuff (yes I know standard from NIST, which allegedly == NSA)
2021-07-14 18:09:37 <minimal> dalias: yes kernel mixes in some stuff but on a server you typically don't have any interrupts from keyboard or mouse, which only really leaves network activity interrupts. Every distinct source of entropy helps to mix in.
2021-07-14 18:09:39 <dalias> if the machine really has no such source that the kernel is already using, it's so deterministic that this jitterentropy thing is useless
2021-07-14 18:09:55 <dalias> (which is possible, if you have a whole machine with a single clock source and no real world inputs)
2021-07-14 18:10:21 <dalias> the kernel is *already using* the same things that jitterentropy can measure
2021-07-14 18:10:42 <dalias> sorry for being frustrated. this is a domain with SO MUCH misinformation and snake oil
2021-07-14 18:11:08 <minimal> dalias: are you referring to the jitterentropy-rngd kernel module written by the same author?
2021-07-14 18:11:12 <dalias> no
2021-07-14 18:11:18 <dalias> i'm referring to the standard linux kernel
2021-07-14 18:11:39 <minimal> that's part of the standard kernel (unless you don't enable it)
2021-07-14 18:12:19 <dalias> as of when? :)
2021-07-14 18:12:23 <minimal> CONFIG_CRYPTO_JITTERENTROPY
2021-07-14 18:12:57 <minimal> kernel 4.2
2021-07-14 18:13:13 <minimal> https://cateee.net/lkddb/web-lkddb/CRYPTO_JITTERENTROPY.html
2021-07-14 18:14:24 <dalias> anyway to answer the question
2021-07-14 18:14:33 <dalias> alpine is not doing anything nonstdandard with __OPTIMIZE__
2021-07-14 18:14:45 <dalias> it's defined exactly when -O is not at 0
2021-07-14 18:15:00 <dalias> so if you're getting it when you don't want it, you have some CFLAGS override going on, i think
2021-07-14 18:15:23 <dalias> (if this is from abuild, it's an issue with the APKBUILD not suppressing some CFLAGS defaults i would guess)
2021-07-14 18:15:50 <minimal> dalias: ok so I'm confused as the software's Makefile adds "-O0" to CFLAGS
2021-07-14 18:15:58 <minimal> as can seen here: https://github.com/smuellerDD/jitterentropy-library/blob/master/Makefile#L6
2021-07-14 18:16:20 <dalias> you can see:
2021-07-14 18:16:21 <dalias> gcc -O0 -dM -E - < /dev/null | grep __OPTIMIZE__
2021-07-14 18:16:41 <dalias> so you need to look at how it's being invoked from wherever it's invoked
2021-07-14 18:17:29 <minimal> ok, I'll do some digging. Thanks
2021-07-14 18:36:10 <Newbyte> does abuild keep a http cache somewhere?
2021-07-14 18:36:27 <caskd> /var/cache/distfiles
2021-07-14 18:36:38 <minimal> dalias: yes I was being blind, for each file gcc is being passed BOTH "-Os" (from abuild I assume) and also "-O0"
2021-07-14 18:36:55 <Newbyte> thanks, Mr Denes 
2021-07-14 18:37:05 <caskd> just call me caskd
2021-07-14 18:37:07 <caskd> :P
2021-07-14 18:37:19 <caskd> or even by my first name
2021-07-14 18:37:24 <Newbyte> what's the fun in that?
2021-07-14 18:37:33 <caskd> *shrugs*
2021-07-14 18:37:35 <Newbyte> but, sure
2021-07-14 18:39:08 <Newbyte> does abuild cache files by name and not URL?
2021-07-14 18:39:31 <caskd> yes, exactly why filename collisions can happen and you can get a warning
2021-07-14 20:36:09 <dalias> uhg why is libtbb-dev missing .a ? :(
2021-07-14 20:36:42 <dalias> 1. everything i build keeps breaking every time i upgrade alpine because dll hell
2021-07-14 20:36:46 <dalias> 2. ok, i'll static link
2021-07-14 20:36:55 <dalias> 3. random -dev packages are missing .a files >_<
2021-07-14 20:38:36 <z3ntu> Ariadne: gettext-tiny seems to exist twice in aports :D https://pkgs.alpinelinux.org/packages?name=gettext-tiny&branch=edge
2021-07-14 20:38:50 <Ariadne> yes
2021-07-14 20:43:12 <z3ntu> Ariadne: this doesn't look like it is on purpose, right?
2021-07-14 20:43:18 <z3ntu> a.k.a one should be removed?
2021-07-14 20:43:53 <Ariadne> yes but haven’t gotten to it yet
2021-07-14 20:44:07 <z3ntu> ok understood
2021-07-14 20:45:46 <dalias> i fucking hate cmake, too
2021-07-14 20:45:52 <dalias> i asked this build to static link
2021-07-14 20:45:59 <dalias> and it's got a bunch of .so's in link.txt
2021-07-14 20:46:03 <dalias> why is that even possible
2021-07-14 20:46:31 <dalias> i need to like make a sandboxed build environment container that DOES NOT HAVE ANY .SO's
2021-07-14 20:46:49 <dalias> because this shit is so stupid
2021-07-14 21:51:37 <mps> strace doesn't work on riscv64
2021-07-14 21:51:56 <mps> '/usr/bin/strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Function not implemented'
2021-07-14 21:53:35 <Hello71> i don't think qemu implements ptrace at all
2021-07-14 21:55:16 <mps> ah, yes. I'm runing in lxc but with qemu-user on the host I think
2021-07-14 21:56:58 <ericonr-> dalias: cmake has this pesky habit of hardcoding .so files
2021-07-14 21:57:21 <ericonr-> it does things like -l /usr/lib/libfoo.so
2021-07-14 21:57:40 <ericonr-> not even libtool does shit like that :)
2021-07-14 22:07:57 <Thermi> ericonr, look at the cmakefilelist and look for where that path is constructed. You'll be able to figure out the parameter and can then pass it with the value you require when regenerating the Makefile from the cmake config files
2021-07-14 22:10:12 <ericonr> Thermi: files under /usr/lib/cmake get the stupid path as well :/
2021-07-14 22:10:25 <ericonr> so find_package() does silly things
2021-07-14 22:10:29 <ericonr> quite silly
2021-07-14 22:10:58 <dalias> can the files installed in /usr/lib/cmake be fixed to do -lfoo ?
2021-07-14 22:15:16 <ericonr> idk how variable precedence works inside cmake, but you could try doing something like -DFOO_LIBRARIES=-l
2021-07-14 22:15:34 <ericonr> and if multiple libs are needed, -lfoo;-lbar
2021-07-14 22:15:39 <ericonr> (I think)
2021-07-14 22:17:24 <Thermi> ericonr, what is the actualy problem?
2021-07-14 22:17:26 <Thermi> *actual
2021-07-14 22:19:25 <Hello71> 20:46 <dalias> i need to like make a sandboxed build environment container that DOES NOT HAVE ANY .SO's
2021-07-14 23:51:34 <ericonr> Thermi: ^^ dalias wants cmake to do things statically, cmake wants people to smash their computers in frustration instead
2021-07-15 06:17:54 <mps> I wonder who added 'rndc-confgen' to bind post-install, and why
2021-07-15 06:18:17 <mps> someone wants alpine to be ubuntu?
2021-07-15 06:19:29 <mps> that is the reason samba fails build on rv64, rndc-confgen segfaults. and strace and gdb don't work on my lxc
2021-07-15 06:19:32 <Sheila> s390x seems to have gone walkabout again
2021-07-15 06:28:06 <mps> what this means: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/438095#L424
2021-07-15 06:28:23 <mps> meson.build:40:0: ERROR: Automatic wrap-based subproject downloading is disabled
2021-07-15 06:29:37 <Sheila> the problem is further up, bump girara-gtk3 like it wants.
2021-07-15 06:30:41 <mps> hmm, I pushed girara already. probably not yet on mirrors?
2021-07-15 06:31:02 <Sheila> probably.
2021-07-15 06:50:45 <ikke> Sheila: yes, our monitoring alerted us, it's just CI though
2021-07-15 06:50:54 <ikke> although, no
2021-07-15 06:50:58 <ikke> it's also the builder
2021-07-15 06:51:11 <Sheila> Okay
2021-07-15 09:39:34 <mps> I have to move testing/gumbo-parser to community, needed for new zathura-pdf-mupdf. objections?
2021-07-15 09:39:47 <nmeum> mps: can you reproduce the rndc-confgen segfault? because I cannot in my riscv64 chroot
2021-07-15 09:39:59 <nmeum> #12817 etc
2021-07-15 09:40:05 <mps> nmeum: yes
2021-07-15 09:40:20 <nmeum> sweet, can you post a backtrace?
2021-07-15 09:40:43 <mps> no, gdb or strace doesn't work in my lxc
2021-07-15 09:40:52 <nmeum> :(
2021-07-15 09:41:06 <ikke> also not in the docker container we have with qemu-user
2021-07-15 09:41:35 <mps> nmeum: how do 'run' your chroot? without qemu-user?
2021-07-15 09:42:24 <clandmeter> nmeum: i have it running
2021-07-15 09:42:31 <nmeum> mps:  I just register the binfmt stuff with qemu-binfmt and then use chroot as one would normally
2021-07-15 09:42:38 <clandmeter> i pushed debug symbols yesterday
2021-07-15 09:44:02 <mps> nmeum: aha, this is how I should setup my local chroot (but after returning from vacation)
2021-07-15 09:44:23 <nmeum> ah! I can reproduce it now too
2021-07-15 09:44:24 <nmeum> sweet
2021-07-15 09:45:42 <clandmeter> gdb says something about libatomic iiuc
2021-07-15 09:47:29 <nmeum> hm, gdb does also not seem to work in my chroot
2021-07-15 09:47:36 <clandmeter> no it does not
2021-07-15 09:47:40 <clandmeter> you need qemu system
2021-07-15 09:47:54 <nmeum> right, that would work
2021-07-15 09:47:59 <clandmeter> or else you need to debug it from qemu user
2021-07-15 09:48:14 <nmeum> can you post your backtrace?
2021-07-15 09:48:21 <clandmeter> there is nothing
2021-07-15 09:48:27 <clandmeter> we need dbg pkg
2021-07-15 09:48:35 <clandmeter> and we dont have it cause we cant build it :)
2021-07-15 09:48:56 <clandmeter> need to build it locally, but i dont have a build env atm
2021-07-15 09:51:06 <clandmeter> ah i do, but in lxc, ill have to build it and pull it into qemu system
2021-07-15 09:54:59 <clandmeter> mps: i do have a request for linux-edge
2021-07-15 09:56:17 <mps> clandmeter: your wishes will be fulfilled, I think
2021-07-15 09:56:30 <clandmeter> move it to community ;-)
2021-07-15 09:56:58 <mps> your wish is alpine dev command :)
2021-07-15 09:57:46 <mps> ncopa: sorry if you disagree but .... :)
2021-07-15 09:58:50 <clandmeter> only if ncopa agree ofc :)
2021-07-15 09:59:46 <mps> oh, too late. I was on other terminal ;)
2021-07-15 10:00:40 <mps> lets see how we can keep it community for at least one release cycle
2021-07-15 10:02:08 <ikke> s390x should be b ack
2021-07-15 10:35:30 <ncopa> mps: I don't mind to move linux-edge to community as long as you deal with the issues/confusions that follows
2021-07-15 10:35:59 <ncopa> i'm afraid that users believe its a fresher version of linux-lts
2021-07-15 10:36:05 <ncopa> which is not
2021-07-15 10:39:39 <mps> yes, I agree
2021-07-15 10:39:58 <mps> but we don't have versioned pkgs
2021-07-15 10:40:16 <ikke> octave is segfaulting in it's test suite on x86_64
2021-07-15 10:41:07 <mps> if anyone have (could have) better name for linux-edge I'm open to discussion and/or change
2021-07-15 10:41:40 <donoban> linux-ml ?
2021-07-15 10:41:56 <ikke> machine learning? :p
2021-07-15 10:42:04 <donoban> ^^
2021-07-15 10:42:08 <ncopa> im not clear on what that the purpose of the kernel is
2021-07-15 10:43:18 <donoban> I thought it pointed to kernel mainline
2021-07-15 10:44:08 <ikke> But it also has different config options from lts
2021-07-15 10:45:17 <donoban> pkgdesc="Linux latest stable kernel" , linux-latest?
2021-07-15 10:45:45 <ikke> linux-experimental
2021-07-15 10:49:12 <ikke> linux-fringe
2021-07-15 10:49:52 <mps> it is actually latest stable kernel
2021-07-15 10:50:24 <ncopa> the purpose was only to bring in mainline kernel?
2021-07-15 10:50:57 <ncopa> i though it also was to provide a slimmer kernel
2021-07-15 10:51:04 <mps> ikke: if you remember we discussed naming it linux-stable but we had a fear that it will be confused with lts (long-term-stable)
2021-07-15 10:51:23 <ncopa> mps: what is the purpose of it?
2021-07-15 10:51:41 <nmeum> ikke: I already created an issue for the octave segfault on gitlab and assigned the maintainer, maybe they have an idea what might be causing this
2021-07-15 10:51:55 <mps> provide latest stable kernel for users who need/want to play with it
2021-07-15 10:52:33 <mps> ncopa: ^
2021-07-15 10:52:37 <ikke> linux-mainline
2021-07-15 10:53:10 <mps> ncopa: and also experiment with new features/drivers for next (when happens) -lts
2021-07-15 10:54:08 <ikke> nmeum: thanks
2021-07-15 10:54:24 <mps> for example, riscv64 for now only can work with it (except heavy patching -lts)
2021-07-15 10:55:43 <ncopa> mps: why is the config so different then? maybe we should base it of the current linux-lts
2021-07-15 10:56:17 <ncopa> we could call it linux-mainline if we based it of linux-lts config
2021-07-15 10:56:19 <mps> ncopa: mostly because of new features
2021-07-15 10:56:40 <mps> and trying to make it 'smaller'
2021-07-15 10:56:51 <ncopa> right, thats what i suspected
2021-07-15 10:57:59 <mps> for example -lts for armv7 can't run in qemu using more than 1GB RAM, -edge can use over 4GB
2021-07-15 10:58:51 <ncopa> cd1c7cfdc49b2ed6de504c53a23fb11620786888
2021-07-15 10:58:53 <ncopa> #12758
2021-07-15 10:59:19 <mps> also I'm trying to 'tweak' it for interactive (workstation) usage, thinking that -lts is proper pkg for servers
2021-07-15 10:59:26 <ncopa> -# CONFIG_EARLY_PRINTK is not set
2021-07-15 10:59:26 <ncopa> +CONFIG_EARLY_PRINTK=y
2021-07-15 10:59:45 <mps> yes
2021-07-15 10:59:46 <ncopa> there are tons of minor differences like that
2021-07-15 11:00:27 <mps> those who use new 'things' will need more info, because this is CONFIG_EARLY_PRINTK=y set
2021-07-15 11:00:39 <ncopa> +CONFIG_WATCH_QUEUE=y
2021-07-15 11:00:50 <mps> new feature
2021-07-15 11:01:08 <mps> not new but to test how it helps
2021-07-15 11:01:44 <ncopa> +# CONFIG_PSI is not set
2021-07-15 11:01:59 <ncopa> -CONFIG_LOG_BUF_SHIFT=14
2021-07-15 11:01:59 <ncopa> +CONFIG_LOG_BUF_SHIFT=15
2021-07-15 11:02:09 <mps> that is what I forgot why
2021-07-15 11:02:13 <ncopa> +# CONFIG_CGROUP_PERF is not set
2021-07-15 11:02:13 <ncopa> -CONFIG_CGROUP_PERF=y
2021-07-15 11:02:24 <ncopa> -CONFIG_CHECKPOINT_RESTORE=y
2021-07-15 11:02:24 <ncopa> +# CONFIG_CHECKPOINT_RESTORE is not set
2021-07-15 11:02:40 <mps> we need CONFIG_LOG_BUF_SHIFT=15, we need a little bigger log buffer
2021-07-15 11:02:59 <mps> CONFIG_CHECKPOINT_RESTORE=y is for servers, imo
2021-07-15 11:03:21 <ncopa> can you please create an issue with that and explain why we need bigger buffer?
2021-07-15 11:03:30 <mps> CONFIG_CGROUP_PERF=y should be set, I probably forgot it for some arches
2021-07-15 11:03:35 <ncopa> -CONFIG_RD_BZIP2=y
2021-07-15 11:03:35 <ncopa> -CONFIG_RD_LZMA=y
2021-07-15 11:03:35 <ncopa> +# CONFIG_RD_LZMA is not set
2021-07-15 11:03:35 <ncopa> +# CONFIG_RD_BZIP2 is not set
2021-07-15 11:03:46 <ncopa> -# CONFIG_BOOT_CONFIG is not set
2021-07-15 11:03:46 <ncopa> +CONFIG_BOOT_CONFIG=y
2021-07-15 11:04:10 <mps> ncopa: you want to 'destroy' my vacation :)
2021-07-15 11:04:33 <ncopa> my point is that the configs are fairly different
2021-07-15 11:04:45 <ncopa> so its not just a newer kernel
2021-07-15 11:04:56 <mps> CONFIG_BOOT_CONFIG=y is new, don't exists in -lts
2021-07-15 11:05:17 <ncopa> it exists on x86_64
2021-07-15 11:05:28 <mps> really?
2021-07-15 11:05:35 <ncopa> there will be significant work needed to sync the kernel configs
2021-07-15 11:05:49 <mps> yes
2021-07-15 11:06:02 <mps> but I think we cannot keep them in sync
2021-07-15 11:06:36 <mps> we can pick options/drivers from edge when major upgrade -lts
2021-07-15 11:06:37 <ncopa> then we should not give the impression that they are in sync when we name it
2021-07-15 11:07:09 <mps> ^ I agree with this
2021-07-15 11:07:42 <mps> we should find name which clearly says they are not 'same' thing
2021-07-15 11:07:45 <ikke> But what name can we use that properly communicates it?
2021-07-15 11:08:02 <ncopa> thats why i ask what the purpose of it is
2021-07-15 11:08:07 <mps> linux-shiny :)
2021-07-15 11:08:29 <ncopa> if it is to make a slimmy kernel we can call it linux-slim
2021-07-15 11:08:35 <ncopa> but then it should also be slimmer
2021-07-15 11:08:39 <mps> I don't know english enough to come to some sensible name
2021-07-15 11:08:49 <ncopa> naming is hard :)
2021-07-15 11:09:05 <ncopa> +CONFIG_BSD_DISKLABEL=y
2021-07-15 11:09:15 <ncopa> i have BSD_DISKLABEL disabled on -lts
2021-07-15 11:09:35 <mps> maybe someone mount bsd disks to linux
2021-07-15 11:09:58 <ncopa> nobody asked for it so far
2021-07-15 11:10:09 <ikke> latest-and-experimental
2021-07-15 11:10:18 <ncopa> the general approach i take is to disable stuff by default and enable on request
2021-07-15 11:10:21 <mps> anyone asked for HFS
2021-07-15 11:10:43 <mps> I sometimes mount hfs disks
2021-07-15 11:11:47 <ncopa> -lts has no batman support (nobody asked for it), -edge has support for it
2021-07-15 11:12:14 <ncopa> i actually think its a good idea with a separate, fresher kernel
2021-07-15 11:12:30 <ncopa> we just need to be smart how we configure them
2021-07-15 11:12:37 <mps> one example of diff is ext4 and f2fs are in-kernel (not as modules) on arm because users experiments and need driver ready
2021-07-15 11:13:31 <ncopa> cannot be loaded with initramfs?
2021-07-15 11:13:49 <mps> yes, they can
2021-07-15 11:14:10 <ncopa> i have it disabled in lts to save space, and let user pick either f2fs or ext4 dependin on their need
2021-07-15 11:14:55 <mps> but users testing new SBCs usually install by a lot of 'hand work', creating mmc FS, flashing u-boot, tweaking boot process and don't have ready initramfs
2021-07-15 11:15:27 <Hello71> why do you say that criu is for servers
2021-07-15 11:15:58 <ncopa> so maybe we should enable ext4 in kernel on  arm -lts as well?
2021-07-15 11:16:16 <mps> ncopa: not sure, but maybe
2021-07-15 11:16:38 <ncopa> i think it woudl be nice if we could do: you need X? use linux-edge. you need Y? use linux-lts
2021-07-15 11:16:47 <Hello71> aiui only problem for "desktop" is that it cannot restore gpu state
2021-07-15 11:16:55 <ncopa> splitting them towards more desktop vs server use makes sense
2021-07-15 11:17:31 <mps> yes, that is why PREEMPT is forced
2021-07-15 11:18:30 <mps> Hello71: I doubt that much users needs criu on desktops, but could be wrong
2021-07-15 11:18:37 <ncopa> i think PREEMPT voluntary makes sense
2021-07-15 11:18:39 <Hello71> re CONFIG_*_DISKLABEL, note that you can always do partx -a /dev/whatever. actually i was thinking about writing some scripts to move partition detection to userspace
2021-07-15 11:20:02 <mps> ncopa: imo, PREEMPT voluntary is rarely needed. maybe for some heavy computional (math) environment
2021-07-15 11:24:06 <ncopa> that makes no sense
2021-07-15 11:24:14 <mps> it will be good and of the help if get more response from users
2021-07-15 11:25:24 <mps> ncopa: PREEMPT will be default in new kernels, voluntary will be possible to set only by cmdline, iirc
2021-07-15 11:25:34 <ncopa> PREEMT_NONE = high latency, high system throughput
2021-07-15 11:26:16 <ncopa> PREEMT (forced) = low latency at the cost of system throughput
2021-07-15 11:26:29 <ncopa> PREEMT_VOLUNTARY comes in between
2021-07-15 11:27:52 <ncopa> i think i read somewhere that voluntary is the default for most linux distros
2021-07-15 11:28:04 <mps> probably yes
2021-07-15 11:28:29 <ncopa> https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html
2021-07-15 11:28:33 <mps> but I think it is something to make compromise
2021-07-15 11:29:29 <mps> and as usual compromises are things with which no one satisfied
2021-07-15 11:32:03 <ncopa> looking at the graphs, the difference is not that significant, and voluntary seems like a good compromise
2021-07-15 11:33:19 <mps>  /o\
2021-07-15 11:36:09 <mps> PREEMPT_VOLUNTARY: Select this if you are building a kernel for a desktop system.
2021-07-15 11:36:51 <mps> PREEMPT: Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range
2021-07-15 11:40:06 <ncopa> exactly
2021-07-15 11:41:37 <mps> milliseconds are noticeable by desktop users and those who run alpine kernel in trucks
2021-07-15 11:42:03 <mps> you remember someone asked for CAN 
2021-07-15 11:42:25 <mps> they wanted to run alpine on their trucks
2021-07-15 11:43:23 <mps> if we want alpine in space ships we need to have fast kernels :)
2021-07-15 11:44:16 <mps> oh wait, maybe is better gui is more important for space ships
2021-07-15 11:45:49 <mps> jokes aside, I think we should made 'small, simple, fast' whenever we can
2021-07-15 11:51:40 <ikke> If you have specialized needs, you should probably build your own kernel
2021-07-15 11:52:10 <mercenary> mps: you mean whenever we CAN ?
2021-07-15 11:52:17 <ikke> :D
2021-07-15 11:52:23 <mps> hehe
2021-07-15 11:53:07 <mps> CAN - Controller Area Network (for uninitiated)
2021-07-15 12:26:32 <ncopa> on riscv64:
2021-07-15 12:26:32 <ncopa> Segmentation fault (core dumped)
2021-07-15 12:26:32 <ncopa> Executing bind-9.16.18-r3.post-install
2021-07-15 12:26:46 <ikke> ncopa: yes, clandmeter and others were already looking at it
2021-07-15 12:27:03 <ncopa> should tag an edge release as soon the edge builders are idle
2021-07-15 12:27:12 <mps> yes, disable ndc-codegen in post-install in bind
2021-07-15 12:27:35 <ncopa> or disable bind on riscv64 if its broken?
2021-07-15 12:28:32 <mps> actaully, do anyone need bind nowadays, I wonder
2021-07-15 12:29:00 <ncopa> apparently samba needs it
2021-07-15 12:29:45 <ikke> no one wants to maintain it at least
2021-07-15 12:30:06 <ikke> Which is not good for a package in main
2021-07-15 12:30:50 <ncopa> true
2021-07-15 12:31:07 <mps> we can replace samba with ksmbd (my plan is to add ksmbd in a few months)
2021-07-15 12:44:16 <Thermi> Somebody please review the rest of the packages at !8569 and merge it
2021-07-15 12:44:27 <Thermi> I'll rebase shortly
2021-07-15 12:45:18 <Thermi> rebased
2021-07-15 13:56:13 <dne> ncopa: re: CONFIG_LOG_BUF_SHIFT, the upstream's default is 17 and I agree that 14 (16 KiB) is a bit small
2021-07-15 14:00:32 <nmeum> mps: the solution is not disabling rdnc-codegen in the post install script, the solution is fixing the segfault :p
2021-07-15 14:01:36 <nmeum> we can temporairly disable samba on riscv64 though to unblock the builder I guess…
2021-07-15 14:04:09 <dalias> do you have any info on what the segfault is?
2021-07-15 14:04:34 <mps> nmeum: I agree, so disable it
2021-07-15 14:04:42 <nmeum> not yet, the problem is that you can't easily use gdb in a riscv64 qemu-user chroot
2021-07-15 14:05:14 <dalias> well qemu-user itself can show the fault wiithout gdb
2021-07-15 14:06:03 <nmeum> yep. I personally haven't looked into that yet since clandmeter already seems to working on this
2021-07-15 14:08:12 <nmeum> mps: done
2021-07-15 14:17:51 <nmeum> turns out: the gdb stub provided by qemu-user is actually very easy to use
2021-07-15 14:18:00 <nmeum> seems to segfault in __atomic_compare_exchange_1 from libatomic
2021-07-15 14:19:00 <dalias> ..
2021-07-15 14:20:46 <nmeum> fun fun fun
2021-07-15 14:23:34 <nmeum> hm a -dbg subpackage for libatomic/libgcc/… would be nice in general
2021-07-15 14:24:52 <dalias> why is gcc making a function call for that??
2021-07-15 14:25:02 <dalias> the abi has 32-bit cas
2021-07-15 14:25:27 <dalias> and gcc should implement all smaller cas as round-down-to-alignment and 32-bit cas
2021-07-15 14:25:47 <dalias> only cas *larger* than the abi-guaranteed native ones needs a library
2021-07-15 14:37:39 <ericonr> dalias: https://github.com/riscv/riscv-gcc/issues/12 :P
2021-07-15 14:45:47 <dalias> *sigh*
2021-07-15 14:54:06 <ericonr> hm, I guess changing the size to int would be fine, since the size of atomic_* types isn't standardized, right?
2021-07-15 14:54:14 <ericonr> or guaranteed to match the non-atomic version
2021-07-15 14:55:05 <dalias> no, that's not an appropriate change and would not be valid for the gcc __sync ones
2021-07-15 14:55:22 <dalias> there is a trivially right way to do this and it's ridiculous that gcc needs the target backend to do anything
2021-07-15 14:55:31 <dalias> this should be a high level transform gcc makes:
2021-07-15 14:55:48 <dalias> unless target has 1-byte and 2-byte atomics in the .md, it should translate to a 4-byte or 8-byte one
2021-07-15 15:04:19 <ericonr> dalias: how would you translate to a bigger atomic without changing the size?
2021-07-15 15:04:33 <ericonr> (I meant the underlying size, not that the size should be changed in application code)
2021-07-15 15:11:01 <nmeum> how is this discussion related to the segfault?
2021-07-15 15:15:43 <dalias> well something in the libatomic code seems broken
2021-07-15 15:15:50 <dalias> or else it's being passed an invalid pointer
2021-07-15 15:18:35 <nmeum> to me it looks a bit like a stack overflow but I might be mistaken
2021-07-15 15:19:44 <nmeum> where do I find the RISC-V implementation for __atomic_compare_exchange_1 in the libatomic code base is it autogenerated from .md files? (I am not familiar with gcc internals at all)
2021-07-15 15:22:22 <dalias> .md files are for gcc's codegen not part of target libs like libatomic
2021-07-15 16:14:39 <ikke> maxice8: Cogitri "Assignee changed from Kevin Daudt to Kevin Daudt"
2021-07-15 16:15:10 <maxice8> nice
2021-07-15 16:26:41 <Cogitri> Oh, huh
2021-07-15 16:31:38 <rzl[m]> ncopa: Howdy. What's the schedule for abuild 3.8?
2021-07-15 17:52:40 <maxice8> Ikke: can I get the log related to that ? you can filter by the MR= and action=
2021-07-15 18:16:05 <maxice8> opened an issue for it
2021-07-15 18:21:32 <ikke> thanks
2021-07-15 18:21:36 <ikke> (I assume that was for me)
2021-07-15 18:21:59 <ikke> I've had to move my IRC client somewhere else
2021-07-15 18:23:24 <maxice8> yes,
2021-07-15 18:26:41 <ikke> responded on the issue
2021-07-15 18:39:21 <maxice8> ty
2021-07-16 11:07:14 <PureTryOut1> Anyone any clue how to fix lldb failure on riscv64? It seems to block the builder currently https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/lldb/lldb-11.1.0-r2.log
2021-07-16 11:07:55 <PureTryOut1> Actually, maybe I'll just block it for that arch for now, it only recently got enabled for all arches anyway
2021-07-16 11:28:58 <fcolista> is apk able to deal with proxy? 
2021-07-16 11:29:04 <fcolista> Not transparent proxy
2021-07-16 11:29:31 <fcolista> I've not seen proxy support
2021-07-16 11:43:55 <mps> fcolista: afaik only by setting env variable http_proxy
2021-07-16 11:43:57 <fcolista> ok looks that libfetch support proxy
2021-07-16 11:44:00 <fcolista> with env
2021-07-16 11:44:10 <fcolista> yeah mps that was what I saw right now
2021-07-16 11:44:20 <fcolista> (just grepping proxy in the source code)
2021-07-16 11:45:00 <fcolista> ok..wondering about socks5 proxy
2021-07-16 12:05:00 <PureTryOut1> ikke: got some "package mentioned in index not found" errors on aarch64 with dl-cdn... (edge)
2021-07-16 12:12:03 <PureTryOut1> Actually nvm, it seems that this time apk didn't do an `update` before the upgrade. Strange
2021-07-16 12:17:37 <ikke> The cache is only refreshed every 4h
2021-07-16 12:17:41 <ikke> unless you provide --update
2021-07-16 12:17:46 <ikke> (apk cache)
2021-07-16 12:24:01 <PureTryOut1> This was on my Pinephone which has been shut off for at least a week 🤷‍♂️
2021-07-16 12:24:16 <ikke> hmmm
2021-07-16 12:24:34 <PureTryOut1> It did update when I executed `apk fix` though
2021-07-16 13:52:32 <clandmeter> PureTryOut1: maybe time didnt get updated yet?
2021-07-16 13:58:13 <ikke> Someone forgot to update time? Nothing good comes from that
2021-07-16 13:58:22 <ikke> 😁
2021-07-16 13:59:51 <minimal> ikke: maybe they didn't have the time to do that ;-)
2021-07-16 14:00:03 <PureTryOut1> Yeah probably 🤷‍♂️
2021-07-16 14:08:00 <andypost> Is the edge mips64 builder missing for reason?
2021-07-16 14:08:46 <ikke> It's still there
2021-07-16 14:09:09 <ikke> stuck on gmid
2021-07-16 14:09:14 <ikke> can someone look at that?
2021-07-16 16:03:50 <ikke> Anyone knows where I can find the syscall table for riscv64? It appears to me that it should be similar on all arches, but apparently they can differ quite a bit (this is for py3-inotify, which apparently is making some syscalls directly)
2021-07-16 16:06:53 <dalias> ikke, well musl has a copy of it
2021-07-16 16:08:57 <ikke> ok, found it
2021-07-16 16:09:13 <ikke> dalias: thanks
2021-07-16 16:11:53 <Hello71> https://github.com/seccomp/libseccomp/blob/main/src/syscalls.csv (... /s)
2021-07-16 16:12:14 <ikke> interesting, these ones are much lower on riscv64
2021-07-16 16:12:36 <dalias> much lower?
2021-07-16 16:12:46 <ikke> the inotify related ones
2021-07-16 16:12:57 <ikke> 253, 254, 256 on x86_64
2021-07-16 16:13:06 <Thermi> I'm running abuild in a docker container and it seems the arch doesn't get populated when cross compiling
2021-07-16 16:13:11 <ikke> 26,27,28 on riscv64
2021-07-16 16:13:32 <Thermi> abuild/apk looks for build packages in ~/packages//main instead of ~/packages/x86_64/main, for example
2021-07-16 16:13:32 <dalias> rv uses the generic numbering
2021-07-16 16:13:32 <dalias> and whoever made it up was on crack
2021-07-16 16:13:33 <Thermi> 3.14.0
2021-07-16 16:13:44 <dalias> like, there's a bunch of random junk syscalls at the top of the list
2021-07-16 16:13:52 <dalias> and the useful base ones are interspersed all over the place
2021-07-16 16:14:01 <dalias> making for really poor cache locality of the table
2021-07-16 16:14:12 <Thermi> could work for cache lines
2021-07-16 16:14:20 <donoban> Thermi: do you mean using dabuild?
2021-07-16 16:14:21 <Thermi> But yes, not optimal
2021-07-16 16:14:32 <Thermi> donoban, no, abuild. alpine:3.14.0 container
2021-07-16 16:14:36 <PureTryOut1> Oh fun, crypto++ seems to only build static libraries when executing tests (`make check`). I guess we should make `$pkgname-static` only a thing on `!riscv64` for now?
2021-07-16 16:14:41 <donoban> ah ok
2021-07-16 16:14:49 <dalias> it was probably someone who thought aio was the next big thing and only thing that performance matters for, who put io_* at the top...
2021-07-16 16:15:09 <Thermi> I use it to run bootstrap.sh and in this container, the arch does not get put into the repo path for some reason
2021-07-16 16:15:13 <dalias> is there a standard process for getting lack of .a files fixed on alpine?
2021-07-16 16:15:53 <Thermi> dalias, what do you mean with "lack of"? .a files are static libraries. They're created as a part of the build process. That's up to every developer of a packet individually.
2021-07-16 16:16:03 <Thermi> There are -static packages available in aports
2021-07-16 16:16:20 <Thermi> apk search -- -static
2021-07-16 16:16:22 <ikke> It's a bit in a limbo currently
2021-07-16 16:16:32 <dalias> i mean that some libs lack a -static
2021-07-16 16:16:56 <dalias> which is a huge problem
2021-07-16 16:17:03 <Hello71> sometimes it's in -dev
2021-07-16 16:17:07 <dalias> it's not
2021-07-16 16:17:10 <dalias> there's a -dev package
2021-07-16 16:17:15 <dalias> but it's useless because no .a
2021-07-16 16:17:20 <ikke> We had issues with eudev / pipewire because static libs were used instead of dynamic
2021-07-16 16:17:26 <dalias> and if you dynamic link it will just break every time anything in alpine is upgraded
2021-07-16 16:18:02 <dalias> ikke, that's because it's not actually a dev lib, it's an infrastructure lib for the distro
2021-07-16 16:18:12 <dalias> to make it possible to install packages without an unwanted dynamic dependency
2021-07-16 16:21:51 <ikke> Is __riscv the correct macro to detect riscv? I see the others all have __ appended as well
2021-07-16 16:22:06 <ikke> but `gcc -dM -E - < /dev/null` only returns __riscv
2021-07-16 16:22:49 <ericonr-> ikke: can you show where the syscall happens? i can't find it
2021-07-16 16:23:11 <ikke> ericonr-: I don't know where it happens, I know where they are checking for htem
2021-07-16 16:23:26 <ikke> common/inotify_syscalls.c
2021-07-16 16:23:55 <ikke> well, there it is used as well
2021-07-16 16:24:24 <ikke> ericonr-: https://github.com/seb-m/pyinotify/blob/master/common/inotify_syscalls.c#L122
2021-07-16 16:26:44 <ericonr-> ikke: why isn't that using libc values?
2021-07-16 16:27:03 <ikke> 🤷
2021-07-16 16:27:19 <ikke> I'm not the author of that library
2021-07-16 16:27:53 <Hello71> #if (defined(__NR_inotify_init) && defined(__NR_inotify_add_watch) &&   \ defined(__NR_inotify_rm_watch)) /* System calls numbers obtained from included sys/syscall.h. */
2021-07-16 16:28:23 <ericonr-> line 26 should be picking up libc values, shouldn't it
2021-07-16 16:28:33 <ikke> Well, it apparently does not
2021-07-16 16:28:44 <ericonr-> could try using SYS_* instead of __NR maybe
2021-07-16 16:28:57 <ikke>   115 | #  error "Unsupported architecture!"
2021-07-16 16:29:01 <ericonr-> but wow, that sucks
2021-07-16 16:29:59 <ikke> Should it include bits/syscall.h?
2021-07-16 16:30:29 <ikke> No, sys/syscall.h should include that
2021-07-16 16:30:36 <ericonr-> yeah
2021-07-16 16:31:11 <ikke> Unless _SYS_SYSCALL_H is already defined for some reason
2021-07-16 16:32:36 <Hello71> https://github.com/seccomp/libseccomp/blob/main/src/syscalls.csv: inotify_init  291  253  253  316  PNR  284  243  247  269  269  275  275  PNR  284  284  290
2021-07-16 16:33:32 <ericonr-> using SYS_* shouldn't make any difference, from what i can tell
2021-07-16 16:33:35 <Hello71> i wonder how it works on aarch64
2021-07-16 16:33:42 <ericonr-> all of them are defined in musl
2021-07-16 16:34:02 <ikke> Hello71: fyi, there was already a patch for aarch64 in the package
2021-07-16 16:36:08 <ericonr-> the real question is why don't they use the libc functions
2021-07-16 16:36:15 <Hello71> the aarch64 patch is the same cause
2021-07-16 16:36:17 <ericonr-> 
ACTION considers forking pyinotify

2021-07-16 16:36:18 <Hello71> and it's broken
2021-07-16 16:36:35 <ikke> ericonr-: yeah, that's a good question, something I wondered about myself
2021-07-16 16:36:48 <Hello71> inotify_init isn't inotify_init1
2021-07-16 16:37:17 <ericonr-> Hello71: what's an uninitialized register amongst friends
2021-07-16 16:37:24 <ikke> :D
2021-07-16 16:38:57 <ericonr-> there's https://github.com/smarkets/pyinotify-smarkets 
2021-07-16 16:39:28 <ikke> Named after the author :D
2021-07-16 16:39:32 <ericonr-> as an "active for 1y fork"
2021-07-16 16:39:43 <ericonr-> ikke: they did that to be able to publish on pypi
2021-07-16 16:39:48 <ericonr-> since the original name is taken
2021-07-16 16:39:56 <ikke> nod
2021-07-16 16:39:58 <Hello71> doesn't it have the same problem
2021-07-16 16:40:02 <ericonr-> yeah, it does
2021-07-16 16:40:49 <ericonr-> I'm interested in forking this and cleaning it up, then move at least the Void package to it
2021-07-16 16:40:58 <andypost[m]> Ppc edge builder is very slow on uploading packages
2021-07-16 16:40:59 <ericonr-> I will let you know when done, if you want to move too
2021-07-16 16:43:13 <ikke> ericonr-: sounds good
2021-07-16 16:46:11 <Hello71> i think the aarch64.patch is actually guaranteed to be broken, because PyArg_ParseTuple puts 1 in x0, so flags=1, which is EINVAL
2021-07-16 16:46:41 <Hello71> upside: consistent behavior. downside: consistently broken
2021-07-16 16:46:48 <ikke> andypost[m]: yes, we are quite aware
2021-07-16 16:47:11 <ikke> andypost[m]: Some network issue where rsync suddenly stalls and errors out
2021-07-16 16:47:29 <andypost[m]> Got it, thanks
2021-07-16 16:48:04 <ikke> Combined with another rsync issue it means that some files will no longer sync afterwards :(
2021-07-16 16:48:18 <ikke> I have to manually fix it
2021-07-16 16:49:08 <andypost[m]> And it affects CI as well
2021-07-16 16:49:22 <ikke> yes, because the repos are incomplete
2021-07-16 16:50:53 <andypost[m]> btw, I'm getting this random errors even locally, what could be a cause? Looks like fines are not linked or broker https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22236#note_168431
2021-07-16 16:51:25 <ikke> On all arches?
2021-07-16 16:51:45 <andypost[m]> *linked *broken except s390x(
2021-07-16 16:55:25 <andypost[m]> I used to disable dblib extension as it missing some export too, but it very strange that s390 passes
2021-07-16 16:59:43 <Hello71> ikke: https://bpa.st/HFHA vaguely correct patch
2021-07-16 17:00:43 <ericonr-> lol
2021-07-16 17:01:03 <ericonr-> that's most of the fork work done, I guess :P
2021-07-16 17:01:28 <ikke> 'vaguely correct' 🤐
2021-07-16 18:44:10 <Thermi> ikke, would you please look at !8569?
2021-07-16 18:44:20 <Thermi> It builds fine and works
2021-07-16 18:44:25 <ericonr-> ikke: so
2021-07-16 18:44:41 <ericonr-> it doesn't try to build the module here
2021-07-16 18:44:44 <Thermi> Except for string replacement warnings in the linter of the CI, no issues.
2021-07-16 18:44:51 <ericonr-> because it tries to import libc functions first
2021-07-16 18:45:20 <ericonr-> I think something's wrong in how alpine packages musl, then
2021-07-16 18:51:35 <ericonr-> because on void it manages to import the libc functions just fine...
2021-07-16 18:52:46 <ericonr-> see, the syscall fallback makes sense because they would have already tried the libc route
2021-07-16 18:53:20 <ericonr-> arguably it can be removed because this is 2021 and whatever, but replacing with libc functions doesn't make sense
2021-07-16 18:53:37 <ericonr-> Hello71: ^^
2021-07-16 18:53:56 <Hello71> uh
2021-07-16 18:54:10 <Hello71> i think it might be the libc.so nonsense
2021-07-16 18:56:20 <ericonr-> would it make sense to be because alpine adds soname to musl?
2021-07-16 18:56:38 <bl4ckb0ne> PureTryOut1 have you looked at !22880 ?
2021-07-16 18:58:12 <PureTryOut1> I had not yet no
2021-07-16 18:59:49 <bl4ckb0ne> will give a go to the builds soon, ill post an update then
2021-07-16 19:00:31 <ericonr-> Hello71: anyway, there's fat to trim from the project, but it's not nearly as bad
2021-07-16 19:02:25 <Hello71> probably the python soname crap :/
2021-07-16 19:02:46 <ericonr-> yes, it uses ctypes.util.find_library
2021-07-16 19:02:57 <ericonr-> point is, we use the alpine patch and it's working fine here...
2021-07-16 19:24:01 <ikke> ericonr-: on x86_64, it does use the syscall defines from musl
2021-07-16 19:32:36 <ikke> ericonr-: on aarch64, this is not the case
2021-07-16 19:33:50 <ikke> We do have a patch that forces the c extension
2021-07-16 21:19:05 <craftyguy> is there any precedence in aports for needing to apply a patch *after* prepare() ?
2021-07-16 21:20:54 <craftyguy> I'm trying to package something which needs to have some of the output from cmake patched until upstream accepts the fix.. I can have a 'patch < $srcdir/fix-patch' in build() after calling cmake. but the patch file can't have the .patch extension else abuild will try to use it in prepare()
2021-07-16 21:21:55 <caskd> in that case probably having prepare() consist of the build file preparation and then default_prepare would make sense
2021-07-16 21:22:15 <caskd> but this would mean other patches would also be applied afterwards
2021-07-16 21:22:34 <craftyguy> ah that's 'cleaner' than what I proposed
2021-07-16 21:22:44 <craftyguy> there are currently no other patches, so maybe that's good enough for now
2021-07-16 21:23:33 <caskd> is the fix that complicated that it needs a patch?
2021-07-16 21:23:44 <caskd> probably some sed magic could replace simple things
2021-07-16 21:24:23 <craftyguy> there's nothing to sed until cmake is run
2021-07-16 21:24:31 <craftyguy> basically need to apply this: https://github.com/YukiWorkshop/IODash/pull/3
2021-07-16 21:24:34 <caskd> especially considering that the things cmake generates are not guaranteed to be the same
2021-07-16 21:24:58 <craftyguy> err, iodash is a dependency for another package that I'm building: https://github.com/ReimuNotMoe/ydotool
2021-07-16 21:25:20 <craftyguy> iodash is 'vendored' in cmakelist..
2021-07-16 21:25:58 <caskd> oh that is awful
2021-07-16 21:26:40 <craftyguy> yeah.
2021-07-16 21:27:07 <caskd> CPM
2021-07-16 21:27:08 <caskd> huh
2021-07-16 21:27:17 <caskd> one more thing to the things to avoid
2021-07-16 21:28:06 <caskd> you could also get your hands dirty and patch the actual cmakelists file and fetch the other stuff as well and merge them
2021-07-16 21:28:12 <caskd> but that's more work
2021-07-16 21:28:15 <caskd> so it depends...
2021-07-16 21:38:47 <craftyguy> ya I considered that, but.. meh
2021-07-16 23:06:10 <Hello71> you can also just not call it .patch
2021-07-16 23:06:34 <Hello71> call it .diff /s
2021-07-16 23:08:09 <Hello71> really what you should do is patch out all this downloading nonsense and do it manually
2021-07-17 03:09:26 <craftyguy> meh
2021-07-17 03:10:07 <craftyguy> it's frustrating that so much time is spent fighting developers who insist on vendoring crap themselves
2021-07-17 08:25:36 <maxice8> ikke: can you check aports-qa-bot logs on MR=23312 ?
2021-07-17 08:25:42 <maxice8> it failed to assign cogitri
2021-07-17 08:26:17 <ikke> 8:01AM WRN could not extract maintainer email error="GET https://gitlab.alpinelinux.org/api/v4/projects/1/repository/files/community/totem-pl-parser/APKBUILD/raw: 500 {message: 500 Internal Server Error}" MR=23312 Project=1 component="MergeRequestJob Processor" file=community/totem-pl-parser/APKBUILD reference=master service=AutoMaintainer
2021-07-17 09:47:21 <caskd> Is there a way to tweak where the iso initramfs looks for modloop and how it sets it up?
2021-07-17 09:47:40 <caskd> i want to just copy the kernel, initramfs and modloop to my usb and use existing grub to boot from it
2021-07-17 09:50:41 <caskd> i am pretty sure /media/* needs to contain .boot_repository
2021-07-17 09:51:05 <caskd> but i'm not sure how to tell the initramfs to automatically mount the needed image
2021-07-17 09:51:18 <caskd> plus setup the modloop mount
2021-07-17 09:52:31 <ikke> The modloop gets mounted after switchroot afaik
2021-07-17 09:52:38 <ikke> there is a modloop service
2021-07-17 09:52:54 <caskd> ok, in that case how do i get the /sysroot mounted properly from the initramfs
2021-07-17 09:53:09 <caskd> there is autodetection as kernel cmdline has nothing related to that
2021-07-17 09:53:13 <caskd> but i cannot find it
2021-07-17 09:54:32 <ikke> KOPT_root?
2021-07-17 09:55:09 <caskd> oh wait, the ISO has a tmpfs sysroot
2021-07-17 09:55:14 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L507
2021-07-17 09:55:21 <ikke> yes
2021-07-17 10:21:35 <caskd> ohh
2021-07-17 10:27:35 <caskd> nlplug-findfs searches for .boot_repository and then it uncompresses the apkovl on the root
2021-07-17 10:35:16 <caskd> i am a bit confused, i kinda understand how this autodetection works now
2021-07-17 10:35:23 <caskd> but what exactly is a apk overlay?
2021-07-17 10:35:55 <ikke> It's a snapshot of persisted data
2021-07-17 10:36:03 <ikke> created by lbu
2021-07-17 10:36:21 <caskd> does it have a specific ending i could look for?
2021-07-17 10:36:26 <ikke> apkovl
2021-07-17 10:36:45 <ikke> It's optional, if it's missing, you just get a clean system
2021-07-17 10:37:07 <caskd> well, yes, but i need it in the live system setup
2021-07-17 10:37:19 <caskd> as i'll have only a empty tmpfs with /dev mounted if not
2021-07-17 10:38:19 <ikke> apkovl should not populate the entire tmpfs
2021-07-17 10:38:38 <caskd> well, the modules are in a modloop
2021-07-17 10:38:44 <caskd> but the rest is in the overlay
2021-07-17 10:39:46 <ikke> When you live boot from a USB, you already get a base system without an apkovl
2021-07-17 10:39:56 <ikke> the apkovl just contains changes in addition to this base system
2021-07-17 10:40:24 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L765
2021-07-17 10:41:04 <caskd> oh
2021-07-17 10:42:47 <caskd> oh i seee
2021-07-17 10:42:57 <caskd> now i got it
2021-07-17 10:57:33 <wener> the setup-disk util default to mbr, I think maybe some day should change default to gpt
2021-07-17 10:59:03 <wener> a vm has limited to 2tb due to mbr, these days, 2tb is not very large, mbr is quite old
2021-07-17 10:59:23 <ikke> I managed to change a system from mbr to gpt
2021-07-17 10:59:40 <wener> any details ?
2021-07-17 10:59:52 <ikke> Was long time ago
2021-07-17 11:00:11 <ikke> but it basically amounted to overwrite the mbr and recreate all partitions with the exact same boundaries
2021-07-17 11:00:11 <wener> syslinux dev seems stopped, really prefer syslinux over grub, but have no choose
2021-07-17 11:02:00 <wener> not dare to do that on working vm, maybe I'll try on some demo vms
2021-07-17 11:06:18 <caskd> then it's nonstandard
2021-07-17 11:06:19 <caskd> retard
2021-07-17 11:06:21 <caskd> whoops
2021-07-17 11:06:24 <caskd> wrong chat
2021-07-17 11:31:28 <wener> after extend qcow image to 1.5T, repartitioned, but can not resize, resize2fs report: New size results in too many block group descriptors.
2021-07-17 11:32:13 <ikke> What is the fstype?
2021-07-17 11:33:54 <wener> ext4
2021-07-17 11:34:12 <ikke> Are you sure you specified 1.5TB and not something larger?
2021-07-17 11:35:02 <wener> yes
2021-07-17 11:35:18 <wener> tried 2tb before, then shrink the image to 1.5T
2021-07-17 11:41:48 <wener> maybe related to this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984472
2021-07-17 12:02:07 <Hello71> ikke: mbr to gpt is usually easy (obviously you need to reinstall bootloader and adjust any PARTUUID) but sometimes there is not enough room at beginning or end (because gpt is fatter)
2021-07-17 12:02:26 <Hello71> end is not too bad, beginning is a problem :p
2021-07-17 12:14:08 <PureTryOut1> the riscv64 builder is stuck on `testing/heplify`. I've built it locally for riscv64 just fine already and could have done multiple times if I wanted since the builder started on it
2021-07-17 12:14:23 <wener> setup-disk default to mbr, the boot partation is 100mb, too small for gpt
2021-07-17 12:22:18 <wener> the problem detail is here https://github.com/tytso/e2fsprogs/issues/74 , need some help, can not grow the fs, maybe have to delete some old files.
2021-07-17 12:32:24 <ikke> Hello71: at least in my case, apparently there was enough space :)
2021-07-17 12:38:43 <PureTryOut1> ikke: could you kick the riscv64 builder?
2021-07-17 13:39:20 <timlegge> any chance of getting !22913 merged soon?  I have a few more cleanups I would like to work on
2021-07-17 13:40:30 <ikke> I was going through it, but did not finished yet
2021-07-17 13:40:42 <ikke> s/finished/finish/
2021-07-17 13:40:42 <alpine-meetbot> ikke meant to say: I was going through it, but did not finish yet
2021-07-17 13:43:34 <dalias> after upgrading alpine, screen always says "Utmp slot not found -> not removed" after closing any window. is there a fix for this?
2021-07-17 13:44:09 <timlegge> ikke - no worries, it is a lot didn't know if it had fallen through the cracks
2021-07-17 13:45:14 <timlegge> I plan to work on removing backticks from the perl packages next and ensure that all the cpan variables have been collapsed
2021-07-17 16:38:41 <Newbyte> Is it bad form to ask if someone can look at/merge a merge request with no unresolved feedback?
2021-07-17 16:46:49 <Hello71> depends how long
2021-07-17 16:46:56 <Hello71> (you have waited)
2021-07-17 17:14:59 <adamplumb[m]> i'm trying to build the gnome-authenticator aport with a small update and i'm getting this state: 
2021-07-17 17:15:00 <adamplumb[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/RAARJtrUMjwTaBbFWhztEVxD/message.txt >

2021-07-17 17:15:32 <adamplumb[m]> fyi i'm running on postmarketos and just upgraded to edge, which mostly seems to be fine, but not sure if something in my system is borked
2021-07-17 17:15:45 <yyp> adamplumb[m]: you don't have apk keys setup properly
2021-07-17 17:16:09 <yyp> You need to use abuild-keygen -a -i (and set $SUDO if needed)
2021-07-17 17:17:03 <adamplumb[m]> ah thanks.  i may have changed my git config user.email details
2021-07-17 17:17:34 <adamplumb[m]> anything i need to do after running that command?
2021-07-17 17:18:14 <yyp> You need to purge the old index (is probably at ~/packages)
2021-07-17 17:18:56 <adamplumb[m]> awesome, thanks!
2021-07-17 23:03:43 <Hello71> https://undeadly.org/cgi?action=article;sid=20210717141912
2021-07-17 23:03:58 <Hello71> hm
2021-07-17 23:04:17 <Hello71> did we never have a link bot? or is it broken?
2021-07-17 23:06:22 <Hello71> anyways, "dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)"
2021-07-17 23:08:31 <ikke> We do not have a general link bot
2021-07-17 23:09:59 <Hello71> seems like resolvd is not quite like systemd-resolved though, it only manages /etc/resolv.conf
2021-07-17 23:13:01 <ikke> sounds a bit like resolvconf?
2021-07-17 23:15:45 <Hello71> yes
2021-07-17 23:49:57 <craftyguy> maxice8: how should I split !23249 if the renaming was done when the version was increased? if I upgrade the app before renaming it, that commit won't build
2021-07-17 23:50:29 <dalias> to me the whole model of resolv.conf having anything to do with dhcp seems utterly backwards
2021-07-17 23:50:42 <dalias> resolv.conf should point to a dnssec-validating nameserver on localhost
2021-07-17 23:51:08 <dalias> and it should use whatever upstream servers it trusts, or go straight to dns root. not trust some junk from an unauthenticated dhcp packet
2021-07-18 00:00:53 <Hello71> i think that's the idea behind unwind(8)
2021-07-18 00:01:21 <Hello71> not sure why they have both
2021-07-18 00:01:46 <dalias> yeah it makes no sense
2021-07-18 00:02:01 <dalias> if you're getting rid of the legacy dhcp client behavior, just get rid of it fully
2021-07-18 00:02:19 <dalias> either users can install the broken legacy dhcp client that clobbers resolv.conf
2021-07-18 00:02:36 <dalias> or they can use the new default one that ignores it, and setup dns in a secure manner
2021-07-18 00:02:42 <Hello71> perhaps some people don't want "another daemon", but then why isn't resolvd like openresolv
2021-07-18 00:03:05 <dalias> the local nameserver daemon?
2021-07-18 00:03:15 <Hello71> "backwards compatibility" is another plausible reason but it's not like openbsd has ever cared much about that
2021-07-18 00:03:33 <Hello71> i mean unwind is "an extra daemon" compared to libc stub
2021-07-18 00:03:34 <dalias> i mean they still offer dhclient legacy if you want backwards compat
2021-07-18 00:03:48 <Hello71> and that's what people complain about systemd
2021-07-18 00:04:03 <Hello71> to my and most clueful people's annoyance
2021-07-18 00:04:25 <dalias> well systemd's resolver does a bunch of bad stuff too :-p
2021-07-18 00:04:54 <Hello71> i'm not saying it's good, i'm just saying "too many processes" is a crappy argument, especially if "too many" is 10 instead of 2
2021-07-18 00:05:08 <dalias> *nod*
2021-07-18 00:05:30 <Hello71> the annoying systemd part is that each of those 10 takes like 10 MB unsharable ram -.-
2021-07-18 00:05:56 <dalias> lol how do they make it so huge?
2021-07-18 00:06:03 <dalias> oh they're probably all using glib...
2021-07-18 00:06:09 <Hello71> ok it's not actually that bad
2021-07-18 00:06:17 <Hello71> mainly systemd-journald is super fat for some reason
2021-07-18 00:08:16 <Hello71> they're like 1-3 MB each except for journald which is 10 MB. mostly mmapped files, so in theory swappable, but i bet it'll be even slower if the journal files get uncached
2021-07-18 00:11:35 <ericonr> dalias: I think systemd managed to avoid glib
2021-07-18 00:17:04 <dalias> i thought they like had a forked copy in-tree or something..
2021-07-18 00:18:14 <ericonr> from github search I know they have some functions copied / inspired from there, but idk what the percentage is
2021-07-18 00:18:35 <ericonr> probably low
2021-07-18 00:19:13 <ericonr> after all, libsystemd is the good alternative for speaking to DBus, since libdbus sucks and glib requires glib
2021-07-18 00:19:54 <orbea> can anything related to dbus be consiered good? 
2021-07-18 00:19:59 <orbea> *considered
2021-07-18 00:20:32 <graywolf> I never had to do much with it, is there a tl;dr reading on why dbus sucks that you could recommend?
2021-07-18 00:21:20 <Hello71> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html
2021-07-18 00:21:25 <orbea> i dont have one, just always seems to be a weak point and prone to hard to diagnose and seemingly arbitrary failures
2021-07-18 00:22:56 <ericonr> Hello71: performance / bad main impl isn't the only reason it sucks
2021-07-18 00:23:37 <ericonr> dbus-broker also exists if anyone wants an impl from the folks who tried to push it into the kernel (afaik) ;)
2021-07-18 00:23:46 <graywolf> Ah, you could tell Linux wrote it even without the From:
2021-07-18 00:26:37 <graywolf> Linus*
2021-07-18 00:27:06 <ericonr> ah, the thread starts with a great email already http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04853.html
2021-07-18 07:05:40 <Newbyte> could someone elaborate on why dbus sucks? it's not the first time I hear it, but I've never actually found a concrete explanation for why it sucks
2021-07-18 07:37:08 <Ariadne> there is a high level of complexity
2021-07-18 08:35:41 <PureTryOut1> Hmm, APKINDEX on x86_64 for the testing repository isn't up-to-date. The files for the `jellyfin-mpv-shim` package are there but it's not mentioned in the APKINDEX
2021-07-18 08:36:21 <Ariadne> strange
2021-07-18 10:30:25 <ikke> is ifunc not available on alpine for some reason?
2021-07-18 10:31:40 <ikke> anoying rsync bug
2021-07-18 10:32:29 <ikke> PureTryOut1: should be fixed now (once the APKINDEX is synced)
2021-07-18 10:32:55 <ikke> 'the call requires 'ifunc', which is not supported by this target'
2021-07-18 10:36:56 <PureTryOut1> Thanks!
2021-07-18 10:38:49 <ikke> Reference: https://github.com/WayneD/rsync/issues/192
2021-07-18 12:03:28 <PureTryOut1> Where can I find the compiler flags used by Alpine/abuild?
2021-07-18 12:04:56 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/functions.sh.in
2021-07-18 12:05:05 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.conf
2021-07-18 12:07:57 <PureTryOut1> Thanks, `abuild.conf` seems to be what I need
2021-07-18 12:22:26 <Hello71> ikke: it isn't but should be detected at compile time
2021-07-18 12:40:59 <ikke> Hello71: apparently darktable fails to do so
2021-07-18 12:41:18 <ikke> Or rather, use the wrong indicators
2021-07-18 12:54:18 <Hello71> hm, not sure
2021-07-18 12:54:31 <Hello71> you might try commenting out https://github.com/darktable-org/darktable/blob/master/src/common/darktable.h#L129
2021-07-18 12:55:47 <ikke> Yes, I did
2021-07-18 12:55:57 <ikke> I already had a patch for that, but was wondering about it
2021-07-18 12:56:54 <Hello71> https://discuss.pixls.us/t/a-tone-equalizer-in-darktable/10678/81 recommends similar
2021-07-18 12:57:12 <Hello71> does it still fail?
2021-07-18 12:57:14 <ikke> No
2021-07-18 12:57:23 <ikke> I had that exact link in the patch ;-)
2021-07-18 12:58:33 <ikke> The reason I was wondering about it was because I had to adjust the patch for the latest version
2021-07-18 13:03:40 <Hello71> aiui, musl doesn't support ifunc because it's poorly defined and unsafe in general. target_clones uses ifunc in a safe-ish and defined-ish way, but musl still doesn't support it because nobody's gotten around to it
2021-07-18 13:06:40 <Hello71> the standard-er way is to use __attribute__((target(x))) and then dispatch at runtime with __builtin_cpu_supports
2021-07-18 13:07:10 <Hello71> but that's annoying because it requires juggling function pointers and ifunc is automagic
2021-07-18 13:09:17 <andypost[m]> Lldb build throwing lots of "lit missing in llvm11" looks only broken symlink packaged
2021-07-18 14:59:04 <ericonr-> ikke: see void patch for darktable
2021-07-18 15:04:24 <ikke> Checking for glibc, right
2021-07-18 15:04:36 <ikke> But I can just as well just patch it out
2021-07-18 15:28:54 <ericonr-> well, it would save the trouble of generating the patch ;)
2021-07-18 15:32:40 <ikke> I don't see the difference?
2021-07-18 15:32:43 <ikke> https://github.com/void-linux/void-packages/blob/master/srcpkgs/darktable/patches/0001-define-target_clones-attribute-only-for-glibc.patch
2021-07-18 15:33:29 <ikke> either patch the target to filter for !glibc, or just removing the logic all-together
2021-07-18 15:47:42 <Hello71> ikke: if we're running into rsync issues regularly, maybe disable --delay-updates for now?
2021-07-18 15:48:02 <ikke> Hello71: Yes, was thinking about that
2021-07-18 15:48:06 <ikke> will discuss it with ncopa
2021-07-18 15:48:12 <Hello71> it's not like --delay-updates is fully atomic anyways
2021-07-18 15:48:39 <ikke> no, but it does prevent partial files from making it into the mirror
2021-07-18 15:51:56 <Hello71> huh? i thought rsync does that by default already (without --inplace)
2021-07-18 15:52:22 <ikke> only with --no-whole-file remotely
2021-07-18 15:52:36 <ikke> iirc
2021-07-18 15:52:52 <ikke> sorry, with --whole-file
2021-07-18 15:53:49 <Hello71> i mean i haven't read the whole rsync manual but i was under the impression that rsync always moves files into place unless you specify --partial and/or --inplace
2021-07-18 15:53:57 <Hello71> otherwise what would be the point of those options
2021-07-18 15:54:04 <ikke> Yeah, probably you're right
2021-07-18 19:14:29 <tomalok> is there a way to do a test build of risc64 with !23386 -- the prior patch to get risc64 building may no longer be necessary.
2021-07-18 19:15:03 <PureTryOut1> *riscv64
2021-07-18 19:15:31 <tomalok> 
ACTION yep, that

2021-07-18 19:15:44 <PureTryOut1> `apk add qemu-riscv64 qemu-openrc && rc-service qemu-binfmt start && CBUILD=riscv64 mirror=mirror=https://dev.alpinelinux.org/~clandmeter/packages/riscv64 abuild rootbld` should do it
2021-07-18 19:16:10 <PureTryOut1> *assuming rootbld is already installed
2021-07-18 19:17:52 <tomalok> 
ACTION double mirror= or just one?  (not sure i'll be able to do the qemu stuff inside my dev docker container, but i do have a plan b)

2021-07-18 19:18:26 <PureTryOut1> Oh sorry no double mirror, just the one
2021-07-18 19:18:39 <PureTryOut1>  * `apk add qemu-riscv64 qemu-openrc && rc-service qemu-binfmt start && CBUILD=riscv64 mirror=https://dev.alpinelinux.org/~clandmeter/packages/riscv64 abuild rootbld` should do it
2021-07-18 19:19:06 <PureTryOut1> And yeah this assumes Alpine Linux as the host system which is the only correct setup ofc 😜
2021-07-18 19:20:36 <tomalok> 
ACTION sounds like time to set up plan b :)

2021-07-18 19:27:45 <PureTryOut1> 
ACTION is not sure you understand how /me should be used 😂

2021-07-18 19:28:03 <tomalok> 
ACTION I haven't been typing /me at all, it's strange

2021-07-18 19:28:08 <tomalok> foo
2021-07-18 19:28:11 <ikke> that's better
2021-07-18 19:28:12 <PureTryOut1> Oh wut
2021-07-18 19:28:18 <tomalok> foo -- bar
2021-07-18 19:28:23 <ikke> tomalok is using matrix
2021-07-18 19:28:26 <PureTryOut1> This is better now yes
2021-07-18 19:28:29 <ikke> or a bouncer?
2021-07-18 19:28:32 <PureTryOut1> No they aren't 
2021-07-18 19:28:34 <tomalok> 
ACTION using znc

2021-07-18 19:28:36 <ikke> right
2021-07-18 19:28:48 <PureTryOut1> Some weirdly configured bouncer it seems 😛
2021-07-18 19:28:52 <tomalok> 
ACTION IRC used to be so straightforward in the early 90s

2021-07-18 19:29:08 <PureTryOut1> It can be just as straight forward if you want, just stop using the bouncer and done
2021-07-18 19:30:58 <tomalok> it's either znc or textual
2021-07-18 19:36:55 <ikke> new binutils released
2021-07-18 21:35:08 <tomalok> PureTryOut1: seem to be missing something yet... >>> docker-cli-buildx: Unpacking /var/cache/distfiles/buildx-0.6.0.tar.gz...
2021-07-18 21:35:08 <tomalok> go: github.com/agl/ed25519@v0.0.0-20170116200512-5312a6153412: Get "https://proxy.golang.org/github.com/agl/ed25519/@v/v0.0.0-20170116200512-5312a6153412.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:57858->[::1]:53: read: connection refused
2021-07-18 21:37:37 <tomalok> (also figured out that Textual was prepending /me when I pressed command-Enter -- a slack habit)
2021-07-18 22:21:45 <tomalok> i suppose i could set up a forwarding resolver on the host, but that shouldn't be necessary, should it?
2021-07-19 02:53:09 <craftyguy> This one was a "draft" for a few days, but is ready AFAIK. It's buried far down in the list of open aports MRs.. So here's a bump :P !23093
2021-07-19 06:02:25 <Thermi> Can somebody please merge !8569?
2021-07-19 06:02:35 <Thermi> It's not getting more ready.
2021-07-19 06:02:41 <Thermi> ;D
2021-07-19 06:05:28 <ikke> It's just large
2021-07-19 06:07:33 <Thermi> That's not the first time I heard that.
2021-07-19 06:14:58 <Thermi> Leo also mentioned that it's pretty large
2021-07-19 06:16:56 <Ariadne> indeed
2021-07-19 06:20:03 <Thermi> Ariadne, Btw, the FFS never replied to my AGPL query
2021-07-19 06:38:25 <Ariadne> probably too busy doing their bad vista 11 whatever “advocacy” :p
2021-07-19 06:52:27 <ncopa> good morning!
2021-07-19 06:53:01 <ncopa> looks like it was a good idea to keep my computer off over the weekend :)
2021-07-19 06:53:25 <ikke> :)
2021-07-19 06:53:34 <ikke> I don't think you missed much
2021-07-19 06:54:54 <ikke> ncopa: can we for the time being remove --delay-updates from the rsync commands to the master mirror? right now, it's just broken
2021-07-19 06:56:03 <ncopa> is it reported upstream?
2021-07-19 06:56:08 <ncopa> do we have a minimal reproducer?
2021-07-19 06:56:41 <ikke> https://github.com/WayneD/rsync/issues/192
2021-07-19 06:56:57 <ncopa> i guess we can remove the --delay updates, but I'm a bit afraid inconsistent state beeing mirrored
2021-07-19 06:57:07 <ikke> ncopa: reproducer: try to sync a file when ~.tmp/file exists
2021-07-19 06:57:17 <ikke> .~tmp~/file
2021-07-19 06:57:53 <ikke> ncopa: that's alreayd happening
2021-07-19 06:57:56 <ncopa> ok. good. lets remove the --delay-updates for now
2021-07-19 06:57:57 <ncopa> yeah
2021-07-19 06:58:17 <ikke> without --delay-updates, it at least can be fixed
2021-07-19 06:59:41 <ncopa> i was afraid that we'd just work around it without working on the real fix, but I'm all good now that I see that it is reported upstream and that there exist a reproducer
2021-07-19 06:59:58 <ncopa> if i get time i'll try to git bisect it
2021-07-19 07:10:30 <PureTryOut1> tomalok: rootbld blocks network access by default. All packages that require network access while building need `options="net"` set
2021-07-19 07:10:42 <PureTryOut1> The fact it's still missing from so many packages like yours is a problem
2021-07-19 07:21:59 <clandmeter> Thermi: my advise for next time, do not bundle so many packages. first try to get the deps into aports one by one and in the end when things are fine and merged MR the application.
2021-07-19 07:23:55 <clandmeter> Thermi: also following codestyle guidelines would make life much easier. for instance https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md#line-length
2021-07-19 07:28:32 <clandmeter> nmeum: what is the reasoning behind https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md#case-statement dont indent alternatives? 
2021-07-19 07:31:29 <markand> can we get !22793 merged? it fails to build due to exhaustion/timeout but builds fine otherwise
2021-07-19 07:32:07 <markand> 
ACTION will never understand how can web toolkits can be so bloat those days

2021-07-19 08:11:24 <nmeum> clandmeter: iirc someone suggested it in the MR? don't know for sure anymore
2021-07-19 08:12:50 <nmeum> should probably be changed to indent alternatives with one tab I guess? that seems to be what most aports do
2021-07-19 08:13:44 <clandmeter> ive seen both
2021-07-19 08:13:56 <clandmeter> but most examples online use tabs
2021-07-19 08:23:02 <Thermi> clandmeter, done.
2021-07-19 08:23:17 <Thermi> I split up the MR into 6 seperate ones, one per package.
2021-07-19 08:24:43 <Thermi> *7 seperate ones
2021-07-19 08:25:14 <clandmeter> Thermi: i dont think thats smart to do now, as the CI will fail.
2021-07-19 08:25:21 <Thermi> Obviously.
2021-07-19 08:25:34 <Thermi> CI fails for two, because they depend on others.
2021-07-19 08:25:38 <clandmeter> thats what i mention the deps first to be merged
2021-07-19 08:25:39 <Thermi> The other 5 are fine.
2021-07-19 08:25:53 <Thermi> I'll just rerun the CI job when the dependencies are merged.
2021-07-19 08:25:58 <clandmeter> ok
2021-07-19 08:26:06 <Thermi> Otherwise we'll never get anywhere with this
2021-07-19 08:26:14 <clandmeter> this way is much more friendly for our reviewers
2021-07-19 08:26:41 <clandmeter> but tbh, we normally do combine commits in an MR
2021-07-19 08:26:50 <clandmeter> but those are less complex
2021-07-19 14:44:48 <tomalok> 
ACTION PureTryOut1: `options=net` appears to be the magic sauce.  I'll review the packages i maintain.

2021-07-19 14:45:05 <tomalok> s/\/me //
2021-07-19 14:45:05 <alpine-meetbot> tomalok meant to say: (also figured out that Textual was prepending when I pressed command-Enter -- a slack habit)
2021-07-19 14:45:50 <ikke> :D
2021-07-19 14:50:30 <clandmeter> tomalok: you and irc seem to be friends :)
2021-07-19 14:51:24 <tomalok> 
ACTION shrugs

2021-07-19 14:55:59 <Thermi> plox review MRs !23409 !23410 !23411 !23413 !23414 !23415 !23416
2021-07-19 15:01:32 <clandmeter> Thermi: did you follow https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md#line-length ?
2021-07-19 19:50:00 <Thermi> When I have the choice of building against gnutls or openssl in a package, which one is preferred on Alpine?
2021-07-19 19:57:27 <maxice8> afair OpenSSL
2021-07-20 01:10:28 <kevint> The armhf runner is failing to download packages over the internet for me
2021-07-20 04:53:00 <ikke> kevint: seems to have been intermitten, it now continued
2021-07-20 06:33:34 <pombreda> Hiya... I wonder why APKBUILD's source is often computed while the generated sha512sums is not and is just plain values. Could it be simpler to ensure that source is a plain parameter like sha512sums since that they are parallel lists anyway? 
2021-07-20 06:36:34 <ikke> pombreda: Because then we would have to adjust the source in addition to bumping the version (and if we forget to do that, we would say a package is version N, while the source is version N-1)
2021-07-20 06:36:58 <ikke> the checksums are generated by abuild checksum (and if you forget to do that, abuild will complain)
2021-07-20 06:37:17 <pombreda> ikke: good point... the computed source param is surely hard to read at times though :)
2021-07-20 06:38:27 <ikke> yes, you cannot just copy/paste it to get the source url, but the benefits of having it match the pkgver outway those disadvantages
2021-07-20 06:38:30 <pombreda> ikke:  there are also gradation in computations... bash expansion is easy enough... but I found some APKBUILDs source computes to be rather byzantine :P 
2021-07-20 06:39:15 <pombreda> ikke: I am writing a simple lexer/parser to extract data from APKBUILD ;)
2021-07-20 06:40:36 <pombreda> ikke: in all cases, thank you for the quick reply +1
2021-07-20 06:41:12 <ikke> You get the best result if you actually source / interpret the global parts of the APKBUIKD
2021-07-20 06:41:15 <ikke> APKBUILD
2021-07-20 06:42:54 <pombreda> ikke: yes, but this means sourcing arbitrary shell :| which I am not super comfy with, security wise (or else this would need some isolation of sorts)
2021-07-20 06:43:08 <pombreda> ikke: FYI this is this https://github.com/nexB/scancode.io/issues/191
2021-07-20 06:43:52 <pombreda> and one goal is to fetch the corresponding sources of a given detected installed apk and run it through extra license detection with scancode-toolkit   
2021-07-20 06:44:16 <pombreda> ikke: the goal is to get better and more accurate license information beyond the license tag
2021-07-20 06:45:07 <ikke> I use lhttps://pkg.go.dev/mvdan.cc/sh to parse shell scripts, and then 'manually' evaluate the variables
2021-07-20 06:45:22 <ikke> It's a bit more work, but safer than sourcing arbitrary shell
2021-07-20 06:46:17 <ikke> https://gitlab.alpinelinux.org/kdaudt/atools-go
2021-07-20 06:47:05 <pombreda> interesting :) neat
2021-07-20 06:47:05 <pombreda> I wrote my own simple lexer/parser  grammar for bash variables and I use this https://github.com/kojiromike/parameter-expansion for now... which I helped enhance)
2021-07-20 06:47:12 <pombreda> let me check these go tools
2021-07-20 06:48:50 <ikke> But if the apkbuild is more complex, it becomes harder to use this approach
2021-07-20 06:49:14 <pombreda> ikke:  indeed :D
2021-07-20 06:49:35 <pombreda> I have a mostly working solution in https://github.com/nexB/scancode-toolkit/pull/2598/files (not all yet pushed)
2021-07-20 06:50:17 <pombreda> ikke: on all teh APKBUILD of 3.13 and 3.14 only 152 fail to parse all the key metadata variables
2021-07-20 06:51:09 <pombreda> and most issues are on the "source" (not for bash expansion but "case", and other conditional assignments
2021-07-20 06:53:36 <pombreda> ikke: https://github.com/mvdan/sh looks like quite evolved! thanks for the pointer!
2021-07-20 06:53:48 <pombreda> I reckon you may be getting good mileage from it in https://gitlab.alpinelinux.org/kdaudt/atools-go ?
2021-07-20 06:54:17 <ikke> Yes
2021-07-20 06:54:25 <ikke> Mostly using the AST it provides
2021-07-20 06:54:58 <ikke> My use-case for atools-go is linting
2021-07-20 06:55:12 <ikke> mostly static, but also some dynamic linting
2021-07-20 06:55:18 <pombreda> :)
2021-07-20 06:56:20 <pombreda> ikke: btw, as an outcome of the stuffs I am playing with I might have (maybe quite a few) patches to some "license" tags.
2021-07-20 06:57:00 <ikke> good
2021-07-20 06:57:01 <pombreda> (FWIW, I helped clarify the kernel licensing, so I am not a total bozo in that domain)
2021-07-20 06:57:09 <ikke> That's appreciated
2021-07-20 06:57:41 <pombreda> :)
2021-07-20 07:01:54 <pombreda> ikke: you use a process similar to the kernel overall? and all aports patches are sent over https://lists.alpinelinux.org/~alpine/aports for discussion? is this correct?
2021-07-20 07:02:13 <ikke> pombreda: we mostly use gitlab merge requests nowadays
2021-07-20 07:02:37 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests
2021-07-20 07:03:07 <pombreda> ikke: thx. I could not find the doc for that :P
2021-07-20 07:03:27 <pombreda> ikke: and on merge request per package is best, correct?
2021-07-20 07:04:09 <pombreda> BTW I wonder why the maintainer is not made into its own parameter and is still a comment in APKBUILD ;)
2021-07-20 07:04:18 <pombreda> (probably historical)
2021-07-20 07:04:33 <ikke> Yeah, I suppose so
2021-07-20 07:04:37 <pombreda> * and one merge request per package is best, correct?
2021-07-20 07:05:06 <ikke> No, I would combine these into a single MR (or one MR per repo)
2021-07-20 07:05:15 <ikke> Depending on how much changes they are
2021-07-20 07:12:04 <pombreda> ikke: I am checking your atools-go ... very nice!
2021-07-20 07:12:57 <pombreda> do you recall if https://pkg.go.dev/mvdan.cc/sh handles bash parameter expansion alright? and can it do lightweight function evaluation (e.g. similar to getting global variables, but at the function level?)
2021-07-20 07:13:36 <pombreda> that's a part that's problematic even with sourcing an APKBUILD mostly for subpackages that may redefine globals
2021-07-20 07:13:56 <pombreda> (different license, desc, version, etc)
2021-07-20 07:13:59 <ikke> AT least the way I use it, you only get an AST, so you need to do any evaluation yourself
2021-07-20 07:14:07 <pombreda> ok
2021-07-20 07:14:14 <ikke> But there are helper
2021-07-20 07:14:15 <ikke> helpers
2021-07-20 07:14:46 <pombreda> ikke: I'll play with it for sure :)
2021-07-20 14:26:54 <bl4ckb0ne> would it be a good move to add `nvme` to the default list of modules in mkinitfs.conf
2021-07-20 14:27:35 <bl4ckb0ne> nvme as boot drives are getting more and more common
2021-07-20 14:27:45 <bl4ckb0ne> and i dumbly lost 10 minutes last night because of that 
2021-07-20 14:28:02 <clandmeter> doesnt it automatically detect it?
2021-07-20 14:28:23 <clandmeter> i mean doesnt it look at current loaded modules and add those
2021-07-20 14:29:43 <bl4ckb0ne> seems not
2021-07-20 14:31:04 <clandmeter> ok, its probably i discussed feature that i thought got added somehow
2021-07-20 14:31:36 <clandmeter> ah it is
2021-07-20 14:31:49 <clandmeter> bl4ckb0ne: did you have nvme loaded when installing?
2021-07-20 14:31:55 <bl4ckb0ne> nope
2021-07-20 14:32:04 <clandmeter> thats your problem :)
2021-07-20 14:32:06 <bl4ckb0ne> i moved my install from a ssd onto the nvme
2021-07-20 14:32:22 <bl4ckb0ne> then it does make sense
2021-07-20 14:32:31 <clandmeter> if you move it will never be added 
2021-07-20 14:32:39 <clandmeter> even if its default
2021-07-20 14:32:44 <clandmeter> the conf is static
2021-07-20 14:33:56 <bl4ckb0ne> at least i found the wiki page about nvme reasonably fast
2021-07-20 14:34:34 <clandmeter> btw, this is probably more suitable for #alpine-linux 
2021-07-20 14:35:09 <bl4ckb0ne> hm perhaps, sorry
2021-07-20 14:36:48 <clandmeter> np, just letting you know.
2021-07-20 14:46:19 <Thermi> When I have a comment at the end of makedepends and it goes over the 80 character limit, is it okay to break it and continue it in the next line?
2021-07-20 14:47:05 <ikke> Maybe add the comment in front of it?
2021-07-20 14:47:23 <ikke> But yes, multiline comments are ok
2021-07-20 14:47:53 <Thermi> Okay
2021-07-20 14:48:24 <Thermi> I thought the 'options="!check! # no checks provided' was so if you grep, you can immediately see the reason
2021-07-20 14:48:37 <Thermi> That obviously doesn't work anymore if the comment is on another line
2021-07-20 14:48:52 <Thermi> (Except with -A and -B args)
2021-07-20 14:49:12 <ikke> Yes, but that works only for short comments
2021-07-20 14:49:31 <ikke> for arch= we move the comments in front of it when it becomes more elaborate
2021-07-20 17:10:28 <tiotags> ikke would you mind looking at my merge request ?
2021-07-20 19:28:33 <Thermi> There's an issue with the locale in the builder for the libvmime package. IT seems there's UTF-8 <-> ASCII encoding issues. https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/443554#L2876
2021-07-20 19:28:40 <Thermi> - Expected: [word: charset=ASCII, buffer=local]
2021-07-20 19:28:40 <Thermi> - Actual  : [word: charset=utf-8, buffer=local]
2021-07-20 19:28:54 <Thermi> - Expected: =?UTF-8?Q?Non-quotable_text_=C3=A9?=
2021-07-20 19:28:54 <Thermi> - Actual  : =?ASCII?Q?Non-quotable_text_=3F=3F?=
2021-07-20 19:30:04 <Thermi> It seems it's always substituted for some reason. I have LANG='C.UTF-8' here as locale and the check works.
2021-07-20 19:30:57 <Thermi> I suspect there's an issue with the locale in the builder docker container
2021-07-20 19:31:37 <ikke> hmm
2021-07-20 19:32:07 <ikke> Would setting LANG=C.UTF-8 in the APKBUILD fix it?
2021-07-20 19:33:54 <Thermi> Well, I can test it
2021-07-20 19:41:52 <Thermi> ppc64le repo is now causing issues:
2021-07-20 19:41:52 <Thermi> ERROR: at-spi2-core-dev-2.40.0-r0: package mentioned in index not found (try 'apk update')
2021-07-20 19:41:52 <Thermi> (171/210) Installing at-spi2-core-dev (2.40.0-r0)
2021-07-20 19:41:52 <Thermi> (172/210) Installing at-spi2-atk-dev (2.38.0-r0)
2021-07-20 19:42:16 <ikke> ah, that's a different issue
2021-07-20 19:42:32 <Thermi> yeah
2021-07-20 19:42:47 <Thermi> Considering you want to get rid of ppc64le anyway, I might just negate it in archs
2021-07-20 19:42:57 <ikke> Well, not just yet :)
2021-07-20 19:43:24 <Thermi> The tests pass now
2021-07-20 19:44:13 <Hello71> does musl actually support C.UTF-8?
2021-07-20 19:44:41 <Hello71> yes
2021-07-20 19:44:57 <ikke> I've fixed the ppc64le repo
2021-07-20 19:45:05 <ikke> after sync it should work for the time being
2021-07-20 19:45:56 <[[sroracle]]> is ppc64le on the chopping block? :)
2021-07-20 19:47:33 <ikke> no
2021-07-20 20:16:30 <Thermi> all builds passed
2021-07-20 21:30:41 <danieli> [[sroracle]]: i can imagine it might soon be if the builder isn't made more stable somehow
2021-07-20 21:34:13 <Hello71> isn't it just an rsync issue
2021-07-20 22:13:38 <danieli> it has been a bit unreliable in general, but as far as i understand that's probably unrelated to the rsync issues
2021-07-21 00:45:51 <maxice8> updated apkbuild.vim, secfixes-highlighting should be better
2021-07-21 00:50:46 <maxice8> well, it will be updated once I can push to gitlab.a.o
2021-07-21 00:54:04 <tomalok> something appears to be not happy...
2021-07-21 00:54:22 <maxice8> me
2021-07-21 01:07:38 <andypost[m]> gitlab is down
2021-07-21 02:08:25 <tomalok> looks like it's back now
2021-07-21 04:37:32 <ikke> hmm, again :-/
2021-07-21 07:47:37 <PureTryOut1> fcolista: the upstream source of `testing/nomp` seems to have disappeared. The whole Gitlab org "git-rep" is gone. https://gitlab.com/git-rep/nomp
2021-07-21 07:48:15 <PureTryOut1> Do you still use the package? It's APKBUILD is quite outdated as well and could use some modernization but if you don't use it we might just prefer to move it to unmaintained
2021-07-21 07:50:23 <fcolista> PureTryOut1, nomp I think is no longer supported by OpenVAS. They moved their repo over the time on GitHub, but there's no nomp repo. I think that can be directly removed.
2021-07-21 07:50:38 <fcolista> Thank you
2021-07-21 07:50:46 <PureTryOut1> Sure I'll remove it, thanks
2021-07-21 08:37:35 <nmeum> does anybody know where syscalls numbers for risc-v are "documented"? for x86 they are generated from a syscall.tbl file (e.g. arch/x86/entry/syscalls/syscall_64.tbl) but a similar file doesn't exist for riscv in the kernel tree
2021-07-21 08:39:20 <nmeum> my current understanding is that risc-v uses the syscalls numbers defined in include/uapi/asm-generic/unistd.h as that's the file included by arch/riscv/kernel/syscall_table.c, can someone with more kernel knowledge confirm this?
2021-07-21 08:50:06 <clandmeter> nmeum: i think you could ask in #riscv on libera
2021-07-21 08:58:39 <nmeum> will do, thanks
2021-07-21 10:50:37 <caskd> I am currently working on merging all configs for kernels (flavours) into one metapackage to ease lts/edge management. Is it possible to stop at LTS every time before a release or should i make separate linux-edge and linux-lts packages?
2021-07-21 10:59:02 <caskd> also is there a reason why s390x and mips64 have no virt?
2021-07-21 10:59:22 <caskd> other than no one doing it?
2021-07-21 11:17:46 <Ariadne> no point
2021-07-21 11:17:55 <Ariadne> s390x is always curt
2021-07-21 11:17:58 <Ariadne> …
2021-07-21 11:18:00 <Ariadne> virt
2021-07-21 11:18:09 <caskd> ah i see
2021-07-21 11:18:11 <caskd> okay
2021-07-21 11:18:13 <Ariadne> and mips64 virt is a total clusterfuck
2021-07-21 11:18:57 <caskd> would splitting /lib/modules in a separate package be also welcome?
2021-07-21 11:20:03 <Ariadne> i don’t think so
2021-07-21 11:20:10 <caskd> hm, i see
2021-07-21 11:20:14 <Ariadne> some modules are needed to boot
2021-07-21 11:20:24 <caskd> well, yes but i mean for management?
2021-07-21 11:20:26 <caskd> or something
2021-07-21 11:20:34 <caskd> i am just testing how much i can improve
2021-07-21 11:20:35 <caskd> haha
2021-07-21 13:21:44 <Hello71> I have considered splitting different module groups into subpackages
2021-07-21 13:21:56 <Hello71> then getting rid of virt
2021-07-21 13:27:14 <ikke> how about modloop?
2021-07-21 14:55:44 <clandmeter> does modloop matter?
2021-07-21 14:56:03 <clandmeter> doesnt it just bundle whatever modules are installed?
2021-07-21 14:56:53 <ikke> It's a pre-build bundle of modules
2021-07-21 14:57:03 <ikke> (and signed)
2021-07-21 14:57:23 <ikke> and read-only
2021-07-21 15:13:14 <clandmeter> so it means you can include/exclude what you want when you build it
2021-07-21 15:13:29 <clandmeter> and possible use overlayfs to make it rw
2021-07-21 15:13:42 <ikke> yes, but not by installing more packages
2021-07-21 15:14:06 <clandmeter> what do you mean?
2021-07-21 15:14:32 <ikke> the modloop is part of the boot medium
2021-07-21 15:15:05 <ikke> of the modloop only has basic modules, your out of luck when you need a module that's not included
2021-07-21 15:15:09 <ikke> s/of/if/
2021-07-21 15:15:09 <alpine-meetbot> ikke meant to say: if the modloop only has basic modules, your out of luck when you need a module that's not included
2021-07-21 15:15:11 <clandmeter> i dont follow, if /lib/modules is rw, why cant you install new modules?
2021-07-21 15:15:19 <ikke> with modloop, it's ro
2021-07-21 15:15:30 <ikke> The modloop is squashfs
2021-07-21 15:15:32 <clandmeter> depends on your config
2021-07-21 15:15:41 <clandmeter> check modloop initd
2021-07-21 15:15:47 <ikke> I have not seen any other config
2021-07-21 15:16:02 <clandmeter> you can define a size to mount it with overlayfs
2021-07-21 15:16:37 <clandmeter> the size is for tmpfs which will be part of the overlayfs
2021-07-21 15:18:40 <clandmeter> https://git.alpinelinux.org/aports/tree/main/openrc/modloop.initd#n113
2021-07-21 15:19:27 <ikke> ok, good to know
2021-07-21 15:19:41 <ikke> people sometimes ask how to add modules when using run-from-ram
2021-07-21 15:19:50 <ikke> It's not commonly known apparently
2021-07-21 15:20:03 <clandmeter> dunno, i added it long long time ago
2021-07-21 15:20:24 <clandmeter> i think some rpi ppl used it
2021-07-21 15:20:32 <clandmeter> but rpi memory is limited
2021-07-21 15:20:38 <ikke> yes
2021-07-21 15:20:38 <clandmeter> so the tmpfs cannot be too big
2021-07-21 15:20:54 <ikke> Could it be stored on the sdcard?
2021-07-21 15:21:27 <clandmeter> it can
2021-07-21 15:21:41 <clandmeter> but it will need a hack
2021-07-21 15:21:55 <artok> I need to still modify update-kernel so modloop etc are created on some mass media rather than on /tmp to be able to update rpi kernel =)
2021-07-21 16:46:22 <Thermi> Please re-review !23410
2021-07-21 16:47:35 <Thermi> (also !23411 !23413 !23414 !23415 !23416
2021-07-21 16:47:37 <Thermi> )
2021-07-21 17:27:29 <caskd> is linux-*-dev different between configurations/flavours?
2021-07-21 17:27:58 <caskd> if not, would it make sense to merge it into a arch-independent package?
2021-07-21 17:40:39 <Thermi> Different kernel patches might introduce new variables or stuff that is in headers
2021-07-21 17:41:01 <Thermi> It could make sense to have a per-flavour header package
2021-07-21 17:42:00 <Thermi> I think there's no way to have that in some way "global", except by making the -dev package (the package with the headers) a specific, own APKBUILD, instead of a subpackage
2021-07-21 17:42:08 <Thermi> because then you could set arch="noarch"
2021-07-21 17:42:21 <caskd> it is possible, i am not questioning that
2021-07-21 17:42:47 <caskd> for context, i am trying to merge flavours into one
2021-07-21 17:42:52 <caskd> or at least configurations
2021-07-21 17:43:04 <caskd> so i already have a unique package
2021-07-21 20:19:10 <maxice8> apkbuild.vim has been updated again, should provide accurate handling of `pkgname=` including comments, Error highlight on stray chars and chars know to cause problems in pkgname=
2021-07-21 20:19:36 <ikke> cool
2021-07-21 20:20:24 <ikke> Did you also add riscv64 as known arch?
2021-07-21 20:28:45 <maxice8> synced it with arch_to_hostspec() from /usr/share/abuild/functions.sh
2021-07-21 20:28:53 <ikke> ah
2021-07-21 20:31:03 <maxice8> https://gitlab.alpinelinux.org/Leo/apkbuild.vim/-/blob/master/syntax/apkbuild-arch.vim#L18
2021-07-21 20:40:37 <ed_> hello, is anyone able to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23437?
2021-07-21 20:41:14 <Hello71> why is it called please but in testing/pleaser
2021-07-21 20:42:10 <Hello71> i was wondering how CI possibly passes, turns out it just totally ignored it
2021-07-21 20:42:36 <ikke> yeah, that's due to ap
2021-07-21 20:43:43 <Hello71> otherwise it looks ok, but would be good to see ci actually build it
2021-07-21 20:44:20 <ed_> Hello71: thanks for spotting that, i've updated the PR
2021-07-21 20:45:27 <ikke> I've a couple of remarks
2021-07-21 20:47:29 <andypost[m]> is it ok to provide -j4 inside of aport build()? I'm getting issues in CI otherwise
2021-07-21 20:49:16 <ikke> is this only in CI?
2021-07-21 20:52:00 <ed_> thank you kevin for looking, i'll address those
2021-07-21 20:53:14 <andypost[m]> ikke: just tested on j8 locally and getting same linking issues
2021-07-21 20:54:47 <andypost[m]> That's WIP on PHP 8.1 beta1 !22236
2021-07-21 20:57:54 <Hello71> i'm skeptical that the regex config can be securely used
2021-07-21 20:59:17 <ed_> Hello71: im skeptical that * can be used in sudoers securely :)
2021-07-21 20:59:57 <Hello71> i think sudoers isn't any better, but the solution to sudoers having too many footguns isn't to add more footguns
2021-07-21 21:00:22 <ed_> i think several footguns are removed here
2021-07-21 21:01:06 <ikke> https://www.openwall.com/lists/oss-security/2021/05/18/1
2021-07-21 21:01:14 <ed_> yes, that
2021-07-21 21:01:18 <Hello71> damn i was literally just going to post that
2021-07-21 21:01:44 <ikke> heh
2021-07-21 21:02:00 <ikke> I posted that in #alpine-security, was looking for it again
2021-07-21 21:02:05 <ed_> SUSE's security team did a good review, and its now in tumbleweed
2021-07-21 21:02:22 <Hello71> useradd\s*.* is also equivalent to root, because you can simply do useradd -u 0 -o newroot
2021-07-21 21:02:54 <ed_> that's literally the same as useradd * in sudoers
2021-07-21 21:03:14 <ed_> but why would you do that if you have the ability to use regex?
2021-07-21 21:03:33 <ed_> in fact, i think there's an example in the docs around this
2021-07-21 21:04:22 <Hello71> yes, it says to do useradd\s*.*
2021-07-21 21:04:31 <Hello71> but doesn't explain that that gives full root privileges
2021-07-21 21:05:08 <ed_> indeed, the section around it has require_pass = false, and that the name starts admin_
2021-07-21 21:12:03 <Hello71> https://github.com/jemalloc/jemalloc/issues/173 would be an easy way to get in
2021-07-21 21:12:13 <Hello71> would have been
2021-07-21 21:41:40 <Hello71> i wonder if any of these variables do anything interesting: https://gitlab.com/edneville/please/-/blob/master/src/lib.rs#L1163
2021-07-21 21:41:56 <Hello71> it's suspiciously inconsistent with sudo's list
2021-07-21 21:43:09 <ericonr1> what does sudo pass through?
2021-07-21 21:44:32 <Hello71> https://www.sudo.ws/man/1.9.7/sudoers.man.html has some lists
2021-07-21 21:44:50 <ericonr1> LANG/LANGUAGE are great for accessibility, but can be screwy if no other LC_* are set
2021-07-21 21:46:23 <Hello71> looks like the default list is XAUTHORIZATION XAUTHORITY PS2 PS1 PATH LS_COLORS KRB5CCNAME HOSTNAME DISPLAY COLORS, and the default sudoers offers examples of a bunch, including LANGUAGE
2021-07-21 21:50:25 <ericonr1> oof PATH
2021-07-21 21:53:56 <Hello71> not sure what's going on with PATH
2021-07-21 23:45:24 <tomalok> hopefully a qq -- when something has a version of "2.0.0-beta.6" what'd be a valid 'pkgver' look like?
2021-07-21 23:48:01 <tomalok> nm, managed to figure it out
2021-07-22 02:33:34 <tomalok> !23497 fwiw
2021-07-22 06:15:22 <clandmeter> tomalok: its a drop-in replacement for docker-compose?
2021-07-22 07:53:11 <wener> clandmeter: Hi, please help review !23420 !23418 if you have time
2021-07-22 07:54:51 <clandmeter> why is one 3.13 and other has no branch mentioned?
2021-07-22 07:55:12 <clandmeter> the later seems to target 3.14
2021-07-22 08:04:04 <wener> yes
2021-07-22 08:04:42 <wener> i used to add current version prefix, and told to not do that
2021-07-22 09:31:28 <clandmeter> wener, it would be nice if you could include a link to the changelog, and perhaps reasoning why to upgrade a package in stable.
2021-07-22 09:31:48 <wener> pre17 crash a lot
2021-07-22 09:31:51 <clandmeter> backporting needs careful attention
2021-07-22 09:32:13 <clandmeter> ok
2021-07-22 09:32:24 <clandmeter> and this also happens on stable releases?
2021-07-22 09:32:43 <wener> yes, it's about tinc
2021-07-22 09:33:16 <wener> so I use my openrc file instead current tinc.networks to help restart
2021-07-22 09:33:41 <wener> pre18 fix a lot crash
2021-07-22 09:34:08 <clandmeter> please include the changelog so i can take a look
2021-07-22 09:34:23 <wener> ok
2021-07-22 09:34:38 <clandmeter> thx!
2021-07-22 15:21:29 <tomalok> clandmeter: yes, it's written in Go and is meant to be a drop-in replacement for `docker-compose` (just remove the hypen)
2021-07-22 15:21:43 <clandmeter> nice
2021-07-22 15:22:11 <clandmeter> no more gazillion py deps
2021-07-22 15:24:34 <clandmeter> tomalok: so it already has all features build in?
2021-07-22 15:27:06 <tomalok> clandmeter: current compatability list: https://github.com/docker/compose-cli/issues/1283
2021-07-22 15:27:49 <tomalok> also https://github.com/docker/compose-cli/tree/v2.0.0-beta.6#compose-v2-aka-local-docker-compose
2021-07-22 15:32:32 <clandmeter> ah yes i saw that compat list
2021-07-22 15:32:43 <clandmeter> it was a bit misleading as it are checkboxes
2021-07-22 15:33:06 <tomalok> eventually they get to a comment back in june where they say it's pretty much complete
2021-07-22 15:34:08 <tomalok> after compose, there's one more plugin included with Docker Desktop -- `scan` -- though it's using a third party scanning service
2021-07-22 18:35:21 <Thermi> ikke, I fixed the two issues with testing/libvimem you mentioned in MR !23410
2021-07-22 18:48:14 <ikke> alright
2021-07-22 18:50:06 <ikke> erged
2021-07-22 18:50:09 <ikke> merged
2021-07-22 18:50:37 <Thermi> tyvm
2021-07-22 19:33:06 <Thermi> Could anybody please review !23411
2021-07-22 19:33:17 <Thermi> Also, !23413
2021-07-22 19:33:24 <Thermi> (and -4 and -5)
2021-07-22 19:33:42 <Thermi> !23411 depends on !23414 and !23415
2021-07-22 19:36:10 <maxice8> does riscv64 have !check globally ?
2021-07-22 19:37:10 <ikke> yes
2021-07-22 19:37:53 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L102
2021-07-22 20:08:13 <maxice8> explains a build failure for py3-manageseive, it needs pytest-runner on setup.py but it is in checkdepends=
2021-07-22 20:08:28 <maxice8> python ecosystem is amazing
2021-07-22 20:15:30 <ed_> ikke: hey, updated 23437 if you're happy to take another look
2021-07-23 08:27:23 <ncopa> good morning
2021-07-23 08:28:14 <ncopa> Ariadne: speaking of rust, do you know what the status of proper musl/rust upstream? and status of rust on s390x for alpine
2021-07-23 08:28:26 <Ariadne> fucked
2021-07-23 08:28:39 <Ariadne> it is possible with a lot of convincing to cross-compile rustc for s390x
2021-07-23 08:28:42 <Ariadne> but,
2021-07-23 08:28:49 <Ariadne> rustc crashes
2021-07-23 08:28:53 <Ariadne> at least on my machine
2021-07-23 08:29:07 <Ariadne> will try to get back to it soon
2021-07-23 08:31:08 <ncopa> :-/
2021-07-23 08:31:28 <ncopa> i really wish upstream rust would take musl libc serious
2021-07-23 08:35:47 <Ariadne> this s390x issue is unrelated to musl
2021-07-23 08:35:52 <Ariadne> s390x is just fucked with rust in general
2021-07-23 08:35:59 <Ariadne> rustc crashes on s390x glibc too
2021-07-23 08:50:49 <wener> andypost[m]: hi, should i increase all dependents's rev in one commit ? !23500
2021-07-23 08:51:09 <ikke> wener: preferably, yes
2021-07-23 08:51:35 <wener> what is the command to find the deps ?
2021-07-23 08:52:14 <ikke> ap revdep grpc-dev for each repo
2021-07-23 08:52:21 <ikke> ap is provided by lua-aports
2021-07-23 08:52:37 <wener> thx
2021-07-23 08:53:33 <ikke> apparently only bear?
2021-07-23 08:53:52 <ikke> yup
2021-07-23 08:54:15 <wener> only found bear and webrtc-audio-processing
2021-07-23 08:54:43 <wener> but !23500 list a lot more
2021-07-23 08:55:30 <ikke> Those are just changed files inside this package
2021-07-23 08:55:42 <ikke> See the end of the build log
2021-07-23 08:57:02 <wener> got it, I will increate the rev of bear and webrtc-audio-processing
2021-07-23 08:57:50 <ikke> how did you find webrtc-audio-processing?
2021-07-23 08:58:10 <ikke> ah, community, I needed to update my local repo
2021-07-23 11:18:12 <Ariadne> duncaen: would you be opposed to a patch adding `/etc/doas.d/` support?  we would like to standardize on `doas`, but we need that
2021-07-23 11:24:12 <Ariadne> though maybe we should just write something
2021-07-23 11:49:49 <duncaen> Ariadne: not sure, I've always been a bit hesitant on adding new features not in upstream
2021-07-23 11:50:32 <Ariadne> :D
2021-07-23 11:52:07 <duncaen> i think its a useful feature tho
2021-07-23 11:52:34 <duncaen> would be nice to get it upstreamed, but I'm not sure how open openbsd is to that
2021-07-23 11:52:58 <ikke> lol
2021-07-23 11:53:10 <ikke> so closed bsd? :P
2021-07-23 11:54:26 <Ariadne> i guess i will just write a sudo
2021-07-23 11:54:48 <Ariadne> how hard could it be
2021-07-23 11:54:57 <Ariadne> i'll write it in rust :D
2021-07-23 11:55:00 <Ariadne> just kidding
2021-07-23 11:56:52 <ikke> Insta 100 stars on gh
2021-07-23 11:57:16 <jvoisin> why are people using sudo in the first place :'(
2021-07-23 11:57:45 <Ariadne> in alpine's case, some initscripts use it apparently
2021-07-23 11:58:39 <jvoisin> my heart is filling with sadness and despair
2021-07-23 11:59:20 <ikke> sudo use is quite common
2021-07-23 12:05:22 <minimal> I haven't seen any alternative with the same set/almost same set of functionality as sudo
2021-07-23 12:05:45 <minimal> so alternatives can replace some of the uses of sudo but not all cases
2021-07-23 12:06:17 <ikke> And we do not remove it, but don't want to support it for 2 years either (because upstream does not)
2021-07-23 12:21:04 <santiago> hi there. just to let you know that https://docs.alpinelinux.org/ returns a 404 error
2021-07-23 12:22:00 <ikke> hmm.. not for me
2021-07-23 12:23:16 <Sheila> loads fine here, too.
2021-07-23 12:28:48 <Ariadne> minimal: what requirements do you have
2021-07-23 12:29:57 <minimal> Ariadne: Hi. Basically a "drop-in" replacement for sudo :-)
2021-07-23 12:29:58 <santiago> well, it works fine, now. :-)
2021-07-23 12:30:20 <Ariadne> minimal: that wont happen.  many things sudo does are bad
2021-07-23 12:30:29 <Ariadne> like... plugins
2021-07-23 12:30:31 <Ariadne> sudo has plugins
2021-07-23 12:31:35 <minimal> Ariadne: as the cloud-init maintainer I'd consider writing a module for it to support doas but then that means anyone existing cloud-init YAML documents using sudo wouldn't work unless instead I modified the sudo module to detect and use doas instead
2021-07-23 12:31:55 <Ariadne> minimal: would 'sudo, the sane parts' be acceptable
2021-07-23 12:32:30 <minimal> also in the past I've used sudo with LDAP, so the sudo config was stored centrally in an LDAP server. doas doesn't support LDAP AFAIK
2021-07-23 12:32:49 <Ariadne> i don't count that as "sane parts" fwiw
2021-07-23 12:33:10 <minimal> was just pointing out another way I've used sudo in the past
2021-07-23 12:33:47 <minimal> so what would you define as the sane parts of sudo?
2021-07-23 12:33:50 <Ariadne> what i think we want is something that can parse /etc/sudoers and basically works
2021-07-23 12:33:57 <Ariadne> but doesnt have plugins, LDAP, etc
2021-07-23 12:34:13 <minimal> Ariadne: for cloud-init, also parse files in /etc/sudoers.d/
2021-07-23 12:34:18 <Ariadne> right
2021-07-23 12:35:17 <Ariadne> we will call it
2021-07-23 12:35:18 <Ariadne> sux
2021-07-23 12:35:21 <Ariadne> SU for X
2021-07-23 12:35:23 <Ariadne> :))))
2021-07-23 12:35:46 <Sheila> that makes me think of a gui program tho
2021-07-23 12:35:49 <Ariadne> honestly i dont like the doas config format
2021-07-23 12:35:54 <Ariadne> the sudoers one is better
2021-07-23 12:36:33 <ed_> well doas is closer to pf, but sudoers ebnf, nobody gets
2021-07-23 12:37:01 <Ariadne> uid [modifier] command
2021-07-23 12:37:05 <ed_> id say, since nobody gets what * really means, sudoers is not better
2021-07-23 12:37:09 <Ariadne> %group [modifier] command
2021-07-23 12:37:47 <minimal> Ariadne: I'lll have another look at the cloud-init source to refresh my memory on what use it makes of sudo. Ideally I'd like to support doas as well as sudo in it
2021-07-23 12:38:01 <Ariadne> doas doesn't support /etc/doas.d/
2021-07-23 12:38:38 <mercenary> doas.conf I can just write an entry without looking at the man page. sudoers not so much
2021-07-23 12:39:21 <mercenary> But not having an /etc/doas.d/ is indeed a pain
2021-07-23 12:40:52 <Ariadne> we could just fork doas
2021-07-23 12:40:58 <Ariadne> and add /etc/doas.d/ support
2021-07-23 12:41:34 <mercenary> That. And ideally eventually get it upstreamed
2021-07-23 12:41:41 <Ariadne> openbsd won't want it
2021-07-23 12:41:43 <Ariadne> i am 100% sure
2021-07-23 12:41:44 <ed_> if you're going to standardise on doas anyway, is there point in having choice of different elevation tools? if it isn't going to be accepted, may as welll close the mr for please
2021-07-23 12:42:04 <ed_> i offer it as choice, in the same way i accept your choice to not accept it ;)
2021-07-23 12:42:35 <Ariadne> i have no objection to `please` being an option in alpine for end users, but i have doubts about the current code quality
2021-07-23 12:42:56 <ed_> i saw your comments but i've not followed up. what was the issue?
2021-07-23 12:44:06 <Ariadne> i think your mitigation for CVE-2021-31153 is incorrect
2021-07-23 12:44:25 <ed_> -c will say if a file exists, but doesn't leak content. was that the issue?
2021-07-23 12:44:46 <Ariadne> you should use `stat(2)` instead of the weird `byte_limit` thing you're doing
2021-07-23 12:45:02 <Ariadne> like, `please -c /dev/sda` should be instant fail before any I/O happens really
2021-07-23 12:46:31 <dalias> what is please?
2021-07-23 12:46:42 <ed_> yeah could indeed use stat. would be better i agree. don't know why i didn't use stat at the time. might have been a long term idea to read content on stdin
2021-07-23 12:46:48 <Ariadne> a sudo-type thing, written in rust, and 170x larger than doas on disk
2021-07-23 12:47:13 <ed_> not looked at loc count lately
2021-07-23 12:47:28 <Ariadne> i'm talking about the fact that it is a 3.1MiB binary (!)
2021-07-23 12:47:30 <mercenary> Call it 'just'. (I have an alias just={sudo,doas} depending on what OS)
2021-07-23 12:48:12 <ed_> rustc can be told not to do that iirc
2021-07-23 12:48:24 <Ariadne> it can
2021-07-23 12:48:27 <ed_> just general advice is don't
2021-07-23 12:49:05 <Ariadne> anyway, without using the phrase "memory safety" can you describe why one might want to use `please` over `sudo`?
2021-07-23 12:49:35 <dalias> :)
2021-07-23 12:50:21 <ed_> people generally "get" regex more than ebnf, people also may also want to use the editor to check files meet various checks before putting in place
2021-07-23 12:50:51 <ed_> though, people are not forced to use regex with please, just i like to make that point that it is available
2021-07-23 12:50:53 <Ariadne> regex seems like a great footgun
2021-07-23 12:51:01 <ed_> and ebnf isn't?
2021-07-23 12:51:11 <Ariadne> what do you mean by 'ebnf' there?
2021-07-23 12:51:14 <ed_> *
2021-07-23 12:51:26 <dalias> does rust implement its own regex or call out to some dubious c impl?
2021-07-23 12:51:29 <ed_> cat /var/log/* as a rule will do more than you want
2021-07-23 12:51:52 <Ariadne> that's not what ebnf means :D
2021-07-23 12:52:04 <ed_> no, but thats what it follows
2021-07-23 12:52:11 <dalias> no
2021-07-23 12:52:14 <Ariadne> unless you mean something other than extended backus-naur form
2021-07-23 12:52:32 <ed_> that's what i thought the parsing rules followed
2021-07-23 12:52:42 <dalias> pretty sure you mean globs
2021-07-23 12:52:42 <Ariadne> ebnf is a way of describing parsing rules
2021-07-23 12:53:05 <ed_> well i have no other way to describe * etc within sudoers config
2021-07-23 12:53:19 <ikke> globs :)
2021-07-23 12:53:27 <ed_> nope. wrong it is not a glob.
2021-07-23 12:53:38 <Sheila> how not?
2021-07-23 12:53:52 <ed_> /var/log/* will also match /etc/shadow, that is in the man page, but not well pointed out
2021-07-23 12:53:59 <jvoisin> there is a whole book about sudo configurations: https://mwl.io/nonfiction/tools#sudo2 :/
2021-07-23 12:54:10 <Ariadne> afaik, the sudoers parser just looks for `*` token in the rule to mean "anything"
2021-07-23 12:54:25 <ed_> yes, anything, so ' ' / etc ...
2021-07-23 12:54:33 <Ariadne> even if that `*` is preceded by text in the same token ;/
2021-07-23 12:54:39 <ed_> to work aroung that you need to follow it with ! ' '
2021-07-23 12:54:42 <jvoisin> and the configuration format is __insane__: https://www.sudo.ws/man/1.9.7/sudoers.man.html
2021-07-23 12:54:49 <ed_> and ! '/'
2021-07-23 12:54:55 <ed_> so that's why regex
2021-07-23 12:55:16 <Hello71> Ariadne: i mentioned the big regex footgun when it was discussed here a few days ago
2021-07-23 12:55:19 <Sheila> regex is not a better solution to this problem.
2021-07-23 12:55:22 <Ariadne> idk i don't even use any of this crap
2021-07-23 12:55:36 <Ariadne> nor do i wish to start
2021-07-23 12:55:43 <Hello71> i looked through the readme examples and at least one of them is equivalent to full root access
2021-07-23 12:55:47 <jvoisin> Ariadne: sane attitude
2021-07-23 12:55:48 <Hello71> regex = /usr/sbin/user(add|del)\s.*
2021-07-23 12:55:51 <ed_> it is a more reliable solution imo, i do think more people "get" regex than the bizarre sudoers form
2021-07-23 12:56:08 <ed_> Hello71: yea, i did say i would fix that example. please.ini man page has a better one
2021-07-23 12:56:19 <Sheila> the absolute limit I would accept is globs. sudoers format and regex are both massively overengineered for this purpose.
2021-07-23 12:56:37 <Ariadne> the use-case is broken
2021-07-23 12:56:59 <Hello71> imo the only thing that should be allowed is to run a specific command. you should do all parsing and validation in that command
2021-07-23 12:57:09 <Ariadne> `sudo cat /var/log/*` -> use proper permissions on /var/log
2021-07-23 12:57:14 <Hello71> which i think doas does
2021-07-23 12:57:16 <ed_> Sheila: this is the point about choice. i am, at this point, very likely to add an alternative to 'regex', once i can think of a good label for it
2021-07-23 12:57:32 <Sheila> …globs? globs is a good label. :)
2021-07-23 12:58:18 <ed_> Sheila: maybe, but what if you don't want to use a glob in this rule?
2021-07-23 12:58:39 <Sheila> wildcards = 'none'
2021-07-23 12:58:42 <Ariadne> this talk about "choice" in a security tool is giving me feelings redolent of firejail
2021-07-23 12:58:51 <jvoisin> krkr
2021-07-23 12:59:07 <Sheila> anyway, my opinion in general is: don't give users choices. choices create attack surface.
2021-07-23 12:59:20 <ericonr> dalias: people use the regex crate, which from what I can tell is directly in rust
2021-07-23 12:59:22 <Sheila> the fewer choices they make, the harder it is to fuck up.
2021-07-23 12:59:45 <mercenary> choice is fine. More complexity than the average user realizes is not
2021-07-23 12:59:50 <ikke> Or users give up and do everything as root
2021-07-23 13:00:04 <ed_> Sheila: the linux ecosystem is all about choice
2021-07-23 13:00:07 <ikke> sevurity is hard
2021-07-23 13:00:18 <Ariadne> in my opinion, sudo should not even be considering arguments to the program being run
2021-07-23 13:00:26 <Hello71> pretty sure this one is vulnerable too: regex = /usr/local/housekeeping/.*
2021-07-23 13:00:35 <Ariadne> you're either allowed to run <command> as root or you're not
2021-07-23 13:00:36 <Hello71> please /usr/local/housekeeping/../../../bin/bash
2021-07-23 13:00:48 <Ariadne> :D
2021-07-23 13:00:59 <ikke> Not comparing against realpath?
2021-07-23 13:01:00 <ed_> yes, that's a good point too
2021-07-23 13:01:02 <Hello71> can't find anywhere paths are normalized
2021-07-23 13:01:19 <Hello71> only raw names searched in (hardcoded) path
2021-07-23 13:01:43 <Ariadne> yes, if `please` is not using `realpath(3)`, then that regex is vulnerable
2021-07-23 13:01:45 <mercenary> Arguments can be dangerous. cat /var/log/`adduser foo -u0`
2021-07-23 13:01:45 <dalias> ariadne, well the right way to do restricted commands is wrapper scripts
2021-07-23 13:01:53 <Hello71> dalias: which is what i said
2021-07-23 13:02:07 <Ariadne> mercenary: no they can't
2021-07-23 13:02:08 <Hello71> mercenary: i don't think it's evaluated with sh?
2021-07-23 13:02:19 <dalias> ariadne, realpath not needed. just disallow ..
2021-07-23 13:02:33 <mercenary> not directly. But there are ways to trick programs into doing it
2021-07-23 13:02:37 <ed_> dalias: many applications just expect to 'sudo' a command and it work, regarless of what it is. trouble is that putting a wrapper between them is work
2021-07-23 13:02:38 <Ariadne> mercenary: posix_spawn(3) does not run things in a shell
2021-07-23 13:02:47 <Sheila>  /usr/local/housekeeping/$ENV/bin/bash :D
2021-07-23 13:02:55 <Hello71> yes, probably safer to disallow .., then you can allow programs by making symlinks
2021-07-23 13:02:58 <dalias> programs running sudo for you are a menace
2021-07-23 13:03:02 <ed_> yep, the greedys were lazy on my part
2021-07-23 13:03:15 <dalias> sudo exists only for intentional manual use
2021-07-23 13:03:36 <ed_> usage and abusage
2021-07-23 13:03:37 <dalias> not build scripts and cobfigurators and such
2021-07-23 13:03:38 <Ariadne> anyway, alpine is unlikely to standardize on `please`, and the more this conversation occurs, the more anxious i get about this software
2021-07-23 13:03:49 <ikke> I use sudo to let a CI system run as non-root to install a very specific package
2021-07-23 13:04:01 <Ariadne> i'm going to go pop a xanax and hope i never hear about this software again :D
2021-07-23 13:04:11 <dalias> :p
2021-07-23 13:04:13 <ikke> Ariadne: don't get your hopes up
2021-07-23 13:04:15 <Hello71> ed_edit_ini:root: ^/etc/please.ini$ also looks suspicious, you can edit /etc/please.ini, but also /etc/pleaseaini, /etc/pleasebini, etc. maybe some vulnerability to be had if you try to edit $'/etc/please\nini'?
2021-07-23 13:04:29 <Hello71> Ariadne: when you come back, we'll have found a fedora privesc :p
2021-07-23 13:04:42 <dalias> :)
2021-07-23 13:04:54 <Hello71> or is suse the one that added it?
2021-07-23 13:04:58 <ikke> suse
2021-07-23 13:04:58 <Ariadne> suse yeah
2021-07-23 13:05:11 <ed_> Hello71: my examples are lazy. if you can edit please.ini then you can self elevate
2021-07-23 13:05:13 <Hello71> ubuntu accountsservice v2, here we come
2021-07-23 13:05:17 <Hello71> ed_: true
2021-07-23 13:05:35 <Ariadne> i can self elevate by typing in `su` and hitting enter
2021-07-23 13:05:38 <Sheila> anyway, this all sounds like bad idea after bad idea. globbing + realpath is the way to go. regex is trivial to fuck up.
2021-07-23 13:05:41 <Ariadne> i dont even use root passwords
2021-07-23 13:05:49 <ed_> Hello71: the examples were (no defence) done in a rush and i'm not the most creative. greedys need to go
2021-07-23 13:06:12 <ikke> Examples should show best practices though
2021-07-23 13:06:14 <Ariadne> `PermitRootLogin publickey-only` in sshd_config, so don't waste your time
2021-07-23 13:06:14 <Hello71> but my point is the regex is like holding footguns in each hand, and also hanging a bunch by the triggers off your arms
2021-07-23 13:06:17 <Ariadne> or whatever it is
2021-07-23 13:06:25 <dalias> CI usage case: CI system should have a daemon to request packages. or (probably better) just run in a container where only user is root
2021-07-23 13:06:56 <ed_> Hello71: the alternative is mostly to just give full root to people, which i think is a bigger deliberate footgun
2021-07-23 13:07:02 <Hello71> i think alpine is working on the latter but not there yet
2021-07-23 13:07:08 <Ariadne> anyway, the only `sudo` replacement i would want is one that is command-granular
2021-07-23 13:07:15 <Ariadne> arguments to commands is not my problem
2021-07-23 13:07:25 <ed_> so, docker then?
2021-07-23 13:07:33 <Hello71> wat
2021-07-23 13:07:45 <ed_> well, just let people have docker, with no concern?
2021-07-23 13:08:00 <Ariadne> what does docker have to do with this
2021-07-23 13:08:05 <Sheila> ah yes, because docker affects the present environment… /s
2021-07-23 13:08:11 <ikke> dalias suggested it
2021-07-23 13:08:15 <ed_> well, permit a command and that's as deep as you go
2021-07-23 13:08:16 <Ariadne> i'm talking about `sudo reboot` or whatever
2021-07-23 13:08:17 <Hello71> run *in* docker, not run docker.
2021-07-23 13:08:29 <ikke> fyi, I do have a wrapper script
2021-07-23 13:08:31 <Sheila> running in docker is not a solution to sysadmin tasks for the host.
2021-07-23 13:08:33 <Hello71> and by containers, dalias means unshare
2021-07-23 13:08:54 <Sheila> nor is any other container technology, really.
2021-07-23 13:08:55 <dalias> CI runs in a throwaway container usually anyway
2021-07-23 13:09:04 <ed_> nope, say, if you are command granular, and the command is docker, then you have a breakout. same as if useradd. but more pratical use is for docker
2021-07-23 13:09:27 <Ariadne> ed_: i've never had a usecase where i wanted to grant a user sudo access to cat specific files only
2021-07-23 13:09:29 <dalias> sheila, then CI is out of scope of discussion of usefulness of sudo
2021-07-23 13:09:55 <ed_> Ariadne: no users who need to read logs then?
2021-07-23 13:09:56 <Sheila> if you need to drop to non-root, sudo is not really a good fit anyway
2021-07-23 13:10:12 <Ariadne> ed_: addgroup $USER log
2021-07-23 13:10:14 <Ariadne> wow
2021-07-23 13:10:15 <Ariadne> done
2021-07-23 13:10:30 <ed_> Ariadne: not all logs are group owned conveniently
2021-07-23 13:10:38 <Ariadne> they are on my system
2021-07-23 13:10:58 <dalias> TBF sudo prevents inadvertent read of them by unpriv process
2021-07-23 13:11:01 <ed_> you are in a lucky position
2021-07-23 13:11:05 <Sheila> that sounds like a software problem.
2021-07-23 13:11:13 <dalias> like rsync or tar of too much
2021-07-23 13:11:17 <Ariadne> i'm in a position where i properly configure my systems
2021-07-23 13:11:39 <dalias> i dont think this makes sudo a compelling solution
2021-07-23 13:11:41 <Hello71> on a related note, fun fact: by default, sudo preserves PATH in the executed environment. i'm sure there are no vulnerabilities to be found there
2021-07-23 13:11:50 <Sheila> tools should discourage improper usecases anyway
2021-07-23 13:11:56 <dalias> but i do think its a downside of addgroup
2021-07-23 13:12:09 <dalias> hello71, ....
2021-07-23 13:12:14 <Sheila> Hello71: default config not having secure_path set is a configuration problem, not an app problem.
2021-07-23 13:12:37 <Hello71> eh
2021-07-23 13:12:37 <Ariadne> all i'm hearing here is that we should standardize on `su`
2021-07-23 13:12:46 <Ariadne> and remove both `sudo` and `doas`
2021-07-23 13:12:51 <Ariadne> and reject `please`
2021-07-23 13:12:55 <ed_> su is fine, if you're happy sharing passwords
2021-07-23 13:13:02 <Ariadne> what password?
2021-07-23 13:13:07 <dalias> my vote is for standardizing nosuid in fstab
2021-07-23 13:13:07 <Ariadne> i don't have a root password
2021-07-23 13:13:08 <Hello71> doas seems fine-ish, assuming you agree with the premise
2021-07-23 13:13:37 <Ariadne> if you're in %wheel on my machines
2021-07-23 13:13:40 <dalias> :p
2021-07-23 13:13:40 <Ariadne> you can `su`
2021-07-23 13:13:42 <Ariadne> and get root
2021-07-23 13:13:48 <Sheila> if you don't trust users with root, don't give them access to a computer. :v
2021-07-23 13:13:53 <ed_> do you want all users in wheel?
2021-07-23 13:14:06 <Ariadne> no, but i don't want users not in wheel rebooting my machine anyway
2021-07-23 13:14:13 <dalias> ed_, no, because "all users" have no business with root
2021-07-23 13:14:17 <Ariadne> so why the fuck would i give them sudo
2021-07-23 13:14:32 <dalias> only one or two do
2021-07-23 13:14:47 <ed_> sometimes you have several groups that need to do work on one machine, neither with root
2021-07-23 13:14:56 <Ariadne> no i don't
2021-07-23 13:15:07 <ed_> maybe you don't
2021-07-23 13:15:07 <ikke> You don't, but others might
2021-07-23 13:15:20 <Ariadne> if i have "several groups who need to do work on one machine" they get their own unprivileged LXC containers
2021-07-23 13:15:26 <dalias> if you have larhe number of users who need to perform some root-needing task...
2021-07-23 13:15:29 <Ariadne> or, kubernetes
2021-07-23 13:15:42 <dalias> giving them all access is a gigantic footgun
2021-07-23 13:15:57 <Sheila> if you have a large number of people who need to do a root-requiring task, eliminate the root requirement.
2021-07-23 13:15:59 <minimal> typical example is cloud-init where (usually) the root account is locked and a default account is created wirh sudo config to let it become root
2021-07-23 13:16:08 <dalias> you need to figure out the actual requiremrnt and make a tool to mediate requests
2021-07-23 13:16:08 <ed_> Sheila: it isn't always root level though
2021-07-23 13:16:13 <ericonr> dalias: computer lab computers :p
2021-07-23 13:16:27 <Sheila> computer labs can provide unprivileged lxc containers.
2021-07-23 13:16:28 <ed_> Sheila: sometimes just interaction with other teams application, without full application rights
2021-07-23 13:16:37 <dalias> need root for..?
2021-07-23 13:16:38 <ericonr> but that's usually solved by being able to signal init to reboot/shutdown
2021-07-23 13:16:41 <minimal> so with cloud-init there is *no* root password
2021-07-23 13:16:47 <Sheila> this sounds like a design bug.
2021-07-23 13:17:05 <Ariadne> minimal: yes, same with my setup, except i just use su
2021-07-23 13:17:31 <ed_> Sheila: why? sometimes db and www and email in one computer... each with dedicated teams but some level of visibility of another teams log/config/etc
2021-07-23 13:17:33 <dalias> i use ssh :)
2021-07-23 13:17:42 <ericonr> dalias: basically to shut down and avoid leaving all devices on
2021-07-23 13:18:08 <Ariadne> ed_: and if db or www or email gets popped, then everyone is owned because its all in the same environment
2021-07-23 13:18:12 <Ariadne> great work
2021-07-23 13:18:13 <dalias> no need to shut them down manuslly. enable sleep while logged out
2021-07-23 13:18:40 <dalias> you dont need root for them anyway
2021-07-23 13:18:46 <mercenary> ericonr: in the olden days, there was a login with the shell set to /sbin/shutdown for that
2021-07-23 13:18:49 <ed_> Ariadne: stuff "pops" - but this is why i advocate going granular
2021-07-23 13:19:06 <dalias> run www stuff as www group & user with cfg owned by wwwadmin group
2021-07-23 13:19:11 <Ariadne> if app A needs to interact with app B, you should be designing an actual channel for those apps to interact
2021-07-23 13:19:15 <Ariadne> instead of using `sudo`
2021-07-23 13:19:19 <Sheila> what she said.
2021-07-23 13:19:29 <ed_> Ariadne: i didn't say the apps interact, the teams do
2021-07-23 13:19:50 <Ariadne> not in today's GDPR regime they don't
2021-07-23 13:20:01 <Ariadne> people get fired if teams interact that way
2021-07-23 13:20:16 <minimal> Ariadne: does su let you define restricted set of commands that can be run by certain users like you can with sudo?
2021-07-23 13:20:27 <Ariadne> no
2021-07-23 13:20:29 <ed_> i've never seen that happen, and i think you're still thinking full blown team level access
2021-07-23 13:21:02 <Ariadne> i think you should go work at a real company and see how they do things
2021-07-23 13:21:15 <Ariadne> you're just pulling examples out of your ass
2021-07-23 13:21:24 <ed_> Ariadne: open to offers, but i'm here because that's how they're working
2021-07-23 13:21:58 <ed_> Ariadne: i admitted earlier, the examples were done in a rush
2021-07-23 13:21:59 <minimal> Ariadne: yes that's the reason people use sudo. "su" lets you handle the case of "let certain users become root or run commands as root" but deosn't handle the typical "sudo" use case of "let certain users run only certain commands as root"
2021-07-23 13:22:25 <Ariadne> yes, and i am saying that 90% of the latter usecase is really just `sudo -s`
2021-07-23 13:22:29 <ikke> At $work, they use sudo + ldap, where there is one team responsible setting up the linux system, while members of another team are responsible for any respective application
2021-07-23 13:22:30 <Sheila> if you can't trust people with full access, why give them partial access?
2021-07-23 13:22:44 <ikke> That's a real-world usecase
2021-07-23 13:22:54 <ed_> ikke: that's somewhat similar, but here cross over of some amount exists too
2021-07-23 13:22:58 <Ariadne> the members of another team should be in their own container
2021-07-23 13:23:05 <ikke> No
2021-07-23 13:23:21 <Ariadne> like why are apps being deployed on bare metal at all
2021-07-23 13:23:31 <Ariadne> apps should be delivered in the form of containers
2021-07-23 13:23:33 <ed_> Ariadne: some apps protect the baremetal
2021-07-23 13:23:34 <Ariadne> this is 2021
2021-07-23 13:24:06 <ed_> qualys/trend/etc not saying they're good applications, just sometimes people have to manage them from different departments
2021-07-23 13:24:21 <Ariadne> yeah, aka apps i would never let near any of my systems :D
2021-07-23 13:24:30 <ed_> these are not your systems though
2021-07-23 13:24:32 <minimal> ikke: indeed, as I mention earlier in this chat I previously used LDAP to store sudo config as part of addressing the security policy (and meeting audit requirements) on a past project.
2021-07-23 13:24:50 <Ariadne> anyway, if you want to use sudo
2021-07-23 13:24:51 <Ariadne> use sudo
2021-07-23 13:24:58 <Ariadne> ed_: yes, and i am glad they are not
2021-07-23 13:25:17 <Ariadne> if these companies would like to upgrade to 2021 way of doing things
2021-07-23 13:25:30 <Ariadne> i am sure there are plenty of people here who can help
2021-07-23 13:25:39 <ed_> one of the problems Ariadne is that containers are not trivial to control with the likes of sudo without permitting breakout
2021-07-23 13:25:55 <ikke> the idea of containers is that you should not need sudop
2021-07-23 13:25:56 <Ariadne> why would anyone be controlling containers
2021-07-23 13:25:57 <ikke> sudo*
2021-07-23 13:25:59 <Ariadne> with sudo
2021-07-23 13:26:01 <Sheila> most people should not be controlling containers. next?
2021-07-23 13:26:18 <Ariadne> the app team would be given access
2021-07-23 13:26:21 <Ariadne> to kubernetes
2021-07-23 13:26:23 <Ariadne> or whatever
2021-07-23 13:26:28 <Ariadne> and they would deploy their app
2021-07-23 13:26:30 <Ariadne> in kubernetes
2021-07-23 13:26:33 <Ariadne> or whatever
2021-07-23 13:26:49 <Ariadne> like you don't want them on the bare metal env at all really
2021-07-23 13:27:06 <ed_> ok, maybe you have an answer to the 2021 upgrade. how do you permit running of container_a only for team a?
2021-07-23 13:27:16 <Ariadne> you use
2021-07-23 13:27:18 <Ariadne> kubernetes
2021-07-23 13:27:20 <ikke> Ariadne: kubernetes does add a lot of complexity though
2021-07-23 13:27:21 <Ariadne> which has ACLs
2021-07-23 13:27:25 <ed_> we don't have kubernetes here
2021-07-23 13:27:26 <Sheila> they send in a config to set it up. done
2021-07-23 13:27:34 <ed_> also mounts
2021-07-23 13:27:41 <ed_> if you give apply access
2021-07-23 13:27:48 <eletrotupi> hello, I've sent a patch to the alpine repository, and was given some feedback, how should I proceed now that I've fixed whatever the problem it had? Just send a v2, use in-reply-to?
2021-07-23 13:28:01 <ikke> Just add 2 months of work to make it kubernetes ready
2021-07-23 13:28:04 <ikke> mimimum
2021-07-23 13:28:05 <eletrotupi> s/to the alpine/to the aports/
2021-07-23 13:28:05 <alpine-meetbot> eletrotupi meant to say: hello, I've sent a patch to the aports repository, and was given some feedback, how should I proceed now that I've fixed whatever the problem it had? Just send a v2, use in-reply-to?
2021-07-23 13:28:07 <Sheila> standing up a container should not require the team using the container to access bare metal at all.
2021-07-23 13:28:16 <Ariadne> ikke: ok use oVirt
2021-07-23 13:28:24 <Ariadne> same difference tbh
2021-07-23 13:28:34 <Ariadne> or openshift
2021-07-23 13:28:39 <ed_> here they like to control containers to upgrade/etc
2021-07-23 13:28:39 <Ariadne> though i hate openshift
2021-07-23 13:28:50 <Sheila> that sounds like a process bug.
2021-07-23 13:29:02 <Ariadne> or VMs
2021-07-23 13:29:14 <Ariadne> so many better ways of architecting this other than sudo
2021-07-23 13:30:34 <Ariadne> there isn't a shortage of container/VM orchestration software supporting ACLs
2021-07-23 13:32:48 <ed_> yeah, better is better. imo regex is a great way to express what you want to allow, hence why i wrote it. with time there are ways to redo things, but often the business world doesn't permit time as things must be agile and features have to be done this sprint
2021-07-23 13:33:31 <Ariadne> in my opinion, the business world should use cloud native technologies correctly
2021-07-23 13:33:39 <Ariadne> and leave sudo in the 90s
2021-07-23 13:33:45 <ed_> yea, outsourcing is the way forward
2021-07-23 13:33:58 <Ariadne> you can run cloud-native technologies on your own machines
2021-07-23 13:34:09 <ed_> oh hybrid cloud
2021-07-23 13:34:20 <ikke> Ariadne: I wish it were that simple :)
2021-07-23 13:34:21 <Ariadne> "cloud-native" is just a buzzword
2021-07-23 13:34:21 <ed_> or is that onprem cloud
2021-07-23 13:34:32 <ed_> or is that onprem "in the cloud"
2021-07-23 13:34:37 <Ariadne> anyway
2021-07-23 13:35:08 <Sheila> ed_: it's generally better to write things mostly-correct from the beginning than try to fix it once people are using it. journald is a demonstrator of why. went from proof-of-concept to production software like *snaps fingers*
2021-07-23 13:35:40 <ed_> Sheila: yes, if you get the chance. sometimes you inherit problems. sometimes it is dropped on you.
2021-07-23 13:35:47 <Ariadne> you can run stuff like kubernetes or docker swarm or ovirt on your own hardware in your own "data center" (aka closet with window unit air conditioner hanging off the door)
2021-07-23 13:36:09 <Sheila> i.e. write a design document before you write a sudo alternative, solicit comments on that, and *then* writecode once you have consensus. :)
2021-07-23 13:36:23 <Ariadne> all 3 platforms mentioned support ACLs
2021-07-23 13:36:28 <Sheila> (or anything else really)
2021-07-23 13:36:40 <Ariadne> but regardless,
2021-07-23 13:36:48 <Ariadne> appA and appB should be talking to each other using APIs
2021-07-23 13:37:00 <Ariadne> and if teams have to do things to each others apps
2021-07-23 13:37:07 <Ariadne> you have a serious business process issue
2021-07-23 13:37:17 <Sheila> ^
2021-07-23 13:37:31 <Ariadne> and you will eventually find yourself with a GDPR problem
2021-07-23 13:38:00 <ed_> sometimes various teams need a small amount of information from another team, maybe in terms of config or some log. they are not mutual data owners
2021-07-23 13:38:01 <Ariadne> because one can conclude that you have many other process issues
2021-07-23 13:38:07 <minimal> unfortunately most orgs don't take GDPR seriously
2021-07-23 13:38:13 <Ariadne> have you heard of elasticsearch
2021-07-23 13:38:23 <Ariadne> or, if you like proprietary software, splunk?
2021-07-23 13:38:44 <ed_> yea, i do know about splunk
2021-07-23 13:38:47 <Sheila> ed_: that again sounds like a process issue. you write APIs if you need to share things.
2021-07-23 13:38:48 <Ariadne> spending a little bit of time to properly architect things
2021-07-23 13:38:52 <ed_> been to their offices in london
2021-07-23 13:38:54 <Ariadne> saves you a lot of time and liability later
2021-07-23 13:39:03 <ed_> just behind paddington station
2021-07-23 13:39:14 <Sheila> (and documentation. configs and logs are not documentation.)
2021-07-23 13:39:39 <Ariadne> and why are people looking at logs for service health information anyway
2021-07-23 13:40:00 <ed_> Sheila: write the api once you get concensus from all parties
2021-07-23 13:40:12 <Sheila> ed_: that's what the design process is for.
2021-07-23 13:40:40 <Sheila> if you get to the 'writing code' phase and you find you have to share configuration or logs, your design is incomplete.
2021-07-23 13:40:52 <Ariadne> i have so many questions
2021-07-23 13:40:58 <Ariadne> this is like paleontology
2021-07-23 13:41:05 <dalias> :)
2021-07-23 13:41:15 <Ariadne> or perhaps archeology
2021-07-23 13:41:20 <ikke> That assumes you are writing software in the first place
2021-07-23 13:41:24 <ikke> and not just integrating systems
2021-07-23 13:41:30 <Ariadne> 
ACTION gets behind the duckblind

2021-07-23 13:41:39 <Sheila> systems integration frequently involves writing code…
2021-07-23 13:41:54 <ikke> You can get quite far without it
2021-07-23 13:42:07 <Ariadne> here we see the I.T. professional with Oracle certification, he's carrying a spear and making grunting noises
2021-07-23 13:42:55 <minimal> agree with Ariadne: in past life 1st line support had to use Rundeck to transfer logs to 3rd party vendor as the infrastructure (i.e. shell scripts) behind Rundeck had to remove any "Personal Data" from logs before passed to 3rd party. That was a way to deal with logs without giving people interactive access to machine to fetch them
2021-07-23 13:43:45 <Ariadne> ikke: yes, i hear people run Windows on servers too, but I've yet to see it
2021-07-23 13:44:07 <Ariadne> I don't think it exists
2021-07-23 13:44:29 <ikke> :)
2021-07-23 13:44:55 <minimal> it does exist unfortunately :-(
2021-07-23 13:45:01 <Ariadne> i am kidding :P
2021-07-23 13:46:04 <Ariadne> ed_: "Some people when solving a problem say, I'll use Regular Expressions, now they have two problems." -- jwz
2021-07-23 13:47:09 <Ariadne> ikke: i mean, in all seriousness, i think the commercial vendors have jumped on board the cloud-native movement
2021-07-23 13:47:25 <ed_> Ariadne: yeah, but you could say that about any solution
2021-07-23 13:47:27 <Ariadne> you can even get Oracle Database 11g as a container now
2021-07-23 13:47:37 <Ariadne> and SAP
2021-07-23 13:47:59 <minimal> is SAP HANA available as a container now?
2021-07-23 13:48:07 <Ariadne> fuck if i know :D
2021-07-23 13:48:11 <ed_> perl as a solution, now you need someone who understands perl, cloud as a solution, now you need someone who understands that
2021-07-23 13:48:23 <Ariadne> well, the problem with your statement is
2021-07-23 13:48:32 <Ariadne> the former are an endangered species
2021-07-23 13:48:41 <Ariadne> but you can hire an AWS specialist on any corner really
2021-07-23 13:48:43 <minimal> ah, "SAP HANA express edition" lol
2021-07-23 13:49:26 <ed_> "specialist" who doesn't understand computers
2021-07-23 13:49:32 <Sheila> ed_: hi, I heard you wanted someone who understands Perl and cloud? :)
2021-07-23 13:49:54 <ed_> Sheila: no, just perl is enough
2021-07-23 13:49:59 <Sheila> (this is 90% a shitpost)
2021-07-23 13:50:03 <Ariadne> perl is the cobol of the 2000s
2021-07-23 13:50:16 <minimal> "use up to 32GB", its a toy version of HANA, the real versions of HANA run on bare metal clusters with terrabytes of RAM per machine
2021-07-23 13:50:29 <Sheila> I'm one of the few people I know who actually likes Perl. kind of depressing, sometimes.
2021-07-23 13:50:49 <Ariadne> minimal: oh i'm sure they're willing to give you the real deal in container form if you give them enough $
2021-07-23 13:51:41 <ed_> Sheila: perl users represent!
2021-07-23 13:51:55 <Ariadne> why didnt you write `please` in perl
2021-07-23 13:52:02 <minimal> Ariadne: I worked on the HANA automated deployment team for SAP's bare metal private cloud, truely monstrous cluster sizes (with monstrous HW bills to match!)
2021-07-23 13:52:03 <ed_> suid on a script?
2021-07-23 13:52:14 <Sheila> people have done worse things.
2021-07-23 13:52:27 <Sheila> why, someone said earlier they wrote a suid program in rust :V
2021-07-23 13:52:30 <Ariadne> ed_: i chmod s+ax on shell scripts all the time
2021-07-23 13:52:41 <Ariadne> er, s+x
2021-07-23 13:52:48 <ed_> debian stopped that
2021-07-23 13:52:59 <Ariadne> oh
2021-07-23 13:53:01 <Ariadne> i dont do that
2021-07-23 13:53:03 <Ariadne> in alpine
2021-07-23 13:53:04 <Sheila> debian is not the arbiter of truth and justice
2021-07-23 13:53:08 <Ariadne> i do that in my personal systems
2021-07-23 13:53:40 <ed_> Sheila: they are not, consensus was not reached, but id rather it be a consistent implementation
2021-07-23 13:53:57 <Sheila> well yes
2021-07-23 13:55:06 <ed_> is it always this lively?
2021-07-23 13:55:19 <Ariadne> its fascinating seeing a dinosaur in the flesh
2021-07-23 13:55:32 <ed_> might hang around a bit longer if so
2021-07-23 13:55:35 <Ariadne> i mean, normally, we would run like hell, right?
2021-07-23 13:56:03 <Ariadne> anyway, back to `please`
2021-07-23 13:56:18 <Ariadne> if you could please make `-c` use stat(2) instead of 10MB file limit
2021-07-23 13:56:28 <Ariadne> that would be pretty ok
2021-07-23 13:56:42 <Ariadne> also like, idk, fix the documentation so the examples aren't so... dangerous?
2021-07-23 13:57:00 <ed_> understood i shall do both
2021-07-23 13:57:02 <Sheila> ed_: no, it's not normally this lively. security software is just low-hanging fruit. :)
2021-07-23 13:57:09 <Ariadne> i kind of have this thing against suid binaries
2021-07-23 13:57:18 <Ariadne> like, my goal is to get us to zero suid binaries
2021-07-23 13:57:23 <Ariadne> but we're gonna have to implement capsicum
2021-07-23 13:57:25 <Ariadne> to get there
2021-07-23 13:57:27 <ed_> it is right to challenge it
2021-07-23 13:57:57 <ed_> it is also very right to listen
2021-07-23 13:58:15 <Ariadne> however,
2021-07-23 13:58:26 <Ariadne> have you considered writing a client-server architecture for this
2021-07-23 13:58:31 <Ariadne> instead of having SUID
2021-07-23 13:58:34 <ed_> like polkit?
2021-07-23 13:58:43 <Ariadne> yes, or s6-sudo
2021-07-23 13:59:01 <ed_> maybe - suse wanted me to do that
2021-07-23 13:59:06 <ed_> as in, do that too
2021-07-23 13:59:41 <Ariadne> i mean if it worked like that
2021-07-23 13:59:46 <Ariadne> and didn't have this goofy regex shit
2021-07-23 13:59:50 <Ariadne> it would be a no brainer
2021-07-23 14:00:00 <Ariadne> :D
2021-07-23 14:00:27 <ikke> so the server would run as root, and the client as user?
2021-07-23 14:00:58 <Ariadne> yes
2021-07-23 14:01:02 <ed_> i generally don't like polkit, so there is motivation, and on this weekend's todo list
2021-07-23 14:01:25 <Ariadne> i think it is the right way to do it
2021-07-23 14:01:28 <Ariadne> but, also like
2021-07-23 14:01:28 <ikke> I suppose something like sudo -i would not work in that model?
2021-07-23 14:01:29 <Ariadne> not in rust
2021-07-23 14:01:46 <Ariadne> ikke: i mean, it should be possible to fake it
2021-07-23 14:02:00 <Ariadne> the client would just send along the desired environment
2021-07-23 14:02:08 <Ariadne> as part of the message with SCM_RIGHTS file descriptor passing
2021-07-23 14:02:16 <ed_> suse suggested go, but only because there are mot people using it, not because of any technical reason
2021-07-23 14:02:39 <Ariadne> i suggest C or go, because its portable to all archs we support and/or plan to support
2021-07-23 14:03:04 <Ariadne> rust is not there yet
2021-07-23 14:04:11 <ed_> option and err style in go would convince me to use go for it
2021-07-23 14:04:51 <ikke> yeah, I agree that's a weaker part in go
2021-07-23 14:04:59 <Hello71> lol
2021-07-23 14:06:00 <ikke> but go lacks exhaustive patern matching, which I think is what is required to make options work in a good way
2021-07-23 14:06:19 <Ariadne> i mean the thing is
2021-07-23 14:06:21 <Ariadne> sudo and doas
2021-07-23 14:06:22 <Ariadne> are C
2021-07-23 14:06:33 <Ariadne> it is possible to write C that is memory safe btw, don't believe the hype
2021-07-23 14:06:45 <Ariadne> see, i can be a dinosaur too!  rawr!
2021-07-23 14:07:04 <jvoisin> I haven't seen many memory-safe C tbh
2021-07-23 14:07:10 <ed_> apr went a long way towards some safety
2021-07-23 14:07:13 <Sheila> now i have a mental image of you in a dinosaur kigu
2021-07-23 14:07:52 <ed_> still not quite like a softplay though, you trip, you fall hard
2021-07-23 14:08:03 <Ariadne> APR :D
2021-07-23 14:08:32 <Ariadne> in a previous life, i worked on the server software for a popular virtual world, and we used APR heavily in both the client and server ^_^
2021-07-23 14:08:49 <ed_> fond memories?
2021-07-23 14:09:20 <Ariadne> they would be fonder if the stock options vested into something worthwhile
2021-07-23 14:09:49 <Ariadne> pretty cool to wake up one day to an email saying the CEO was replaced with a spammer who wanted to team up with pornhub
2021-07-23 14:09:51 <jvoisin> (^ https://apr.apache.org/ )
2021-07-23 14:10:27 <Sheila> I still don't understand why they thought that that was a good idea.
2021-07-23 14:10:32 <Sheila> (replacing CEO with spammer, I mean)
2021-07-23 14:10:33 <Ariadne> lots of debian, and later, lots of python microservices
2021-07-23 14:10:56 <ed_> so what you're saying is pornhub runs on APR?
2021-07-23 14:11:02 <Ariadne> i was introduced to the concept of using the package manager for configuration management
2021-07-23 14:11:08 <Ariadne> no, i have no idea
2021-07-23 14:11:12 <Ariadne> but second life do
2021-07-23 14:17:28 <Ariadne> but, in all seriousness, client-server approach for this would be the right way, or at least the alpineish way of doing it
2021-07-23 14:17:33 <Ariadne> SUID is bad
2021-07-23 14:17:45 <Ariadne> i dream of a world where alpine has zero SUID binaries
2021-07-23 14:18:11 <Ariadne> and we can change `abuild` to just error on SUID binaries being found without even having `options=suid`
2021-07-23 14:18:30 <Ariadne> like, polkit
2021-07-23 14:18:32 <Ariadne> is total shit
2021-07-23 14:18:37 <Ariadne> but the underlying concept is valid
2021-07-23 14:19:02 <jvoisin> it would be glorious.
2021-07-23 14:21:40 <Ariadne> 
ACTION mutters about #12864

2021-07-23 14:26:40 <ikke> license=custom
2021-07-23 14:28:00 <ikke> heh, apparently it was me who merged it 🤐
2021-07-23 14:28:43 <ikke> Ariadne: https://www.iozone.org/docs/Iozone_License.txt
2021-07-23 14:36:00 <Ariadne> can you update the APKBUILD to include that :)
2021-07-23 14:36:46 <ikke> You mean download it as source and include it in the package?
2021-07-23 14:36:54 <Ariadne> yes
2021-07-23 14:36:56 <ikke> sure
2021-07-23 14:39:19 <Ariadne> yeah cause i was looking at why it didnt build on riscv64
2021-07-23 14:39:20 <Ariadne> and i was like
2021-07-23 14:39:22 <Ariadne> ??????????
2021-07-23 14:39:46 <ikke> did you also see the embeded license below?
2021-07-23 14:40:07 <jvoisin> https://llvm.org/docs/ScudoHardenedAllocator.html#clang `-fsanitize=scudo` is pretty cool ♥
2021-07-23 14:45:20 <ericonr> Ariadne: except that pkexec is still suid lol
2021-07-23 14:45:53 <Ariadne> ericonr: well yeah, dbus doesn't have SCM_RIGHTS
2021-07-23 14:46:14 <Ariadne> ikke: i did not
2021-07-23 14:47:32 <minimal> I'm intending to move s6-overlay, s6-overlay-preinit, and justc-envdir from community to unmaintained as upstream development appears to have stopped months ago and s6-overlay is currently broken in 3.14 and Edge. Basically its down to the current s6-overlay not working properly with the current execline version (packaged by skarnet).
2021-07-23 14:48:30 <minimal> Its only relevant for Alpine containers. Just wondering if they'll be any kickback if someone using s6-overlay on 3.13.x (where it works due to older execline version) upgrades to Edge (ot 3.15 when its out) and complains about these packages disappearing
2021-07-23 14:49:16 <ericonr> Ariadne: they could have used something other than dbus for that :/
2021-07-23 15:15:23 <Hello71> Ariadne: you mean you can't send fds over dbus?
2021-07-23 15:15:41 <Ariadne> i don’t think so
2021-07-23 15:15:49 <Ariadne> but admittedly i’m not a dbus expert
2021-07-23 15:17:23 <Hello71> dbus fd passing is at least 11 years old
2021-07-23 15:17:46 <Hello71> https://github.com/freedesktop/dbus/commit/869291ea5a98485183bbe1a4d2cdab9eb97fbb0d
2021-07-23 15:17:54 <Hello71> wait, that's 12 years
2021-07-23 15:19:14 <Hello71> as of 2014 there were apparently at least 15 users: https://lists.freedesktop.org/archives/dbus/2014-October/016363.html
2021-07-23 15:35:52 <ericonr> fds in broadcasts sounds nightmarish lol
2021-07-23 15:36:45 <ericonr> Ariadne: thinking about it more, I think the main issue is that PolKit is about *permissions*
2021-07-23 15:38:10 <ericonr> for example, you use polkit so the fwupd server (auto launched by dbus :p) can authenticate the fwupd client and perform the actions that specific client is allowed by policy
2021-07-23 15:39:16 <ericonr> so pkexec is the privileged process in this case, it just queries polkit for "is the user allowed X?"
2021-07-23 15:39:48 <ericonr> and for this sort of decision making, you obviously need a full JS runtime
2021-07-23 15:44:13 <Hello71> do you?
2021-07-23 15:45:04 <Hello71> so far i haven't seen any plausible applications for full turing-complete policy evaluation
2021-07-23 15:46:36 <Hello71> assuming for now that it makes sense to allow a user to run firmware updates but not do anything else as root (does it?), and you want it to be restricted to users in a specific group AND be at a local console, why do you need JS to write declarePolicy("update-firmware", () => { if (userInGroup("fwupd") && userAtLocalConsole()) return true; else return false; });
2021-07-23 15:47:05 <Hello71> why can't it be update-firmware: group(fwupd) && local-console()
2021-07-23 15:47:57 <Hello71> we're straying into sudoers parsing insanity here, but i'd still rather have a complicated parser running as root instead of a full turing-complete language
2021-07-23 15:48:03 <Hello71> (including a complicated parser)
2021-07-23 15:51:28 <ericonr> Hello71: you can also partly represent policy in XML iirc
2021-07-23 15:51:45 <ericonr> idk how exactly the two interact
2021-07-23 15:51:49 <Hello71> aiui you define actions in xml
2021-07-23 15:51:58 <Hello71> then define policies for permitting or denying actions in js
2021-07-23 15:51:59 <ericonr> and I was being sarcastic, JS is a terrible choice
2021-07-23 15:52:17 <ericonr> using mozjs instead of duktape just compounds on the mistake
2021-07-23 15:52:30 <Hello71> it's a plausible design for a web service
2021-07-23 15:53:15 <ericonr> and the duktape PR was stuck on it not having a timeout rhingy to protect the daemon from infinite loops
2021-07-23 15:53:16 <Hello71> xml kinda sucks but i think new actions are supposed to be uncommon, and js is vaguely plausible if you actually do need complicated authorization policies
2021-07-23 15:53:28 <ericonr> because having a turing complete language means that can just happen
2021-07-23 15:54:21 <jvoisin> ericonr: waitwat, js, in polkit?!
2021-07-23 16:03:23 <ikke> yes
2021-07-23 16:03:33 <ikke> mozjs
2021-07-23 16:03:40 <ikke> which depends on rust
2021-07-23 16:04:24 <jvoisin> wtf.
2021-07-23 16:18:29 <mercenary> well, if people make sudo do LDAP lookups, why shouldn't polkit be able to check LDAP (or any other convenient web service)?
2021-07-23 19:03:03 <Thermi> What's the point of #secfixes in APKBUILDs when they refer to old versions of the package?
2021-07-23 19:09:29 <ikke> It's the version of the package where it was fixed in
2021-07-23 19:11:10 <yyp> New aports should go into testing/, right?
2021-07-23 19:11:23 <ikke> yes
2021-07-23 19:11:29 <yyp> Ok cool
2021-07-23 19:12:44 <ericonr> Hello71: idk how I landed there, but see https://gitlab.freedesktop.org/polkit/polkit/-/issues/15 lol
2021-07-23 19:13:17 <ericonr> mercenary: checking other backends is different from implementing unbounded logic for authentication
2021-07-23 19:28:18 <yyp> Out of curiosity, what's the reason for -DCMAKE_BUILD_TYPE=None lint?
2021-07-23 19:29:25 <ikke> The default build type ignores our CFLAGS and other settings
2021-07-23 19:32:15 <Thermi> ikke, Yes, but why keep them?
2021-07-23 19:32:27 <maxice8> see alint.5 /AL55
2021-07-23 19:34:11 <maxice8> Thermi: so we know when we fixed something
2021-07-23 19:44:08 <Thermi> For some automated tool?
2021-07-23 19:45:26 <maxice8> both
2021-07-23 20:00:12 <ikke> huh
2021-07-23 20:00:42 <ikke> apk info -L atools-doc | wc -l
2021-07-23 20:00:44 <ikke> 0
2021-07-23 20:01:24 <ikke> oh, probably fixed later
2021-07-23 20:05:31 <Thermi> Regarding the build failure at https://gitlab.alpinelinux.org/J0WI/aports/-/jobs/440676
2021-07-23 20:05:51 <Thermi> If we could get artifacts made of all the build.log and config.log files, that'd make that easier
2021-07-23 20:06:01 <Thermi> because I can't reproduce that here in a docker container on x86_64 with edge
2021-07-23 20:06:08 <ikke> https://gitlab.alpinelinux.org/J0WI/aports/-/jobs/440676/artifacts/browse
2021-07-23 20:06:36 <Thermi> Yes and that build log from the builder is not what autotools creates
2021-07-23 20:06:50 <Thermi> the config.log from autoconf contains the tests run and the reason they failed
2021-07-23 20:07:48 <ikke> Thermi: If you copy the logs to $CI_PROJECT_DIR/logs/, then they will automatically be made available
2021-07-23 20:08:41 <Thermi> So you propose that for every build failure on the builder that can not be reproduced locally, the APKBUILD should be modified such that the logs are copied in a failure case?
2021-07-23 20:09:00 <Thermi> That could be automated much easier in a generalized case
2021-07-23 20:09:22 <ikke> The generalized case is probably a lot more tricky
2021-07-23 20:09:31 <ikke> And in the short term, that's how you get the logs
2021-07-23 20:09:37 <Thermi> if ! abuild; then ...
2021-07-23 20:10:03 <Thermi> The shortest time between failure and log retrieval is achieved by automatic upload
2021-07-23 20:10:10 <ikke> I mean, right now
2021-07-23 20:10:31 <ikke> Or you provide a MR to alpine-gitlab-ci
2021-07-23 20:30:40 <ericonr> ed_: Ariadne: isn't using stat(2) (or even fstat(2)) subject to TOCTOU issues? someone could also have the file open and write a bunch to it while you have it open... doing a "full_read" loop asking for N+1 bytes where N is the maximum you want, and checking if you read more than N should be the best logic for this, shouldn't it?
2021-07-23 20:32:03 <ericonr> (which is what the version tries to do; I'm unclear on why it fails)
2021-07-23 20:37:29 <ikke> Maybe the issue is not the size?
2021-07-23 20:37:35 <ikke> of the segfault that is
2021-07-23 20:43:42 <ikke> And I guess the TOCTOU issue could be partially mitigated with fstat?
2021-07-23 20:44:01 <ikke> but the filesize could always change
2021-07-23 21:31:10 <nmeum> Thermi: https://secdb.alpinelinux.org/ is for instance generated from the secfixes comments and in turn used by security.alpinelinux.org iirc
2021-07-23 22:00:33 <Thermi> nmeum, I see, but how useful is that to track historical secfixes?
2021-07-23 22:01:24 <ikke> it serves as an indication that a particular CVE has addressed
2021-07-23 22:01:25 <Thermi> E.g. strongSwan current version is 5.9.3 and all the secfixes are for previous versions, so they are already in the sources.
2021-07-23 22:02:29 <Thermi> To me it makes no sense because it's not a full archive of all CVEs pertaining the software historically either
2021-07-23 22:03:27 <ikke> No, just what is relevant to what has been in aports
2021-07-23 22:03:33 <ikke> since we started tracking it
2021-07-23 22:04:09 <Thermi> And how is it then relevant to the current version of the package that has no trace of any secfixes, except that they are annotated in the comment?
2021-07-23 22:04:26 <Thermi> There are no patches that fix it, it's just that they're fixed by having been patched upstream
2021-07-23 22:04:56 <Thermi> So they provide no useful information about the current state of the package.
2021-07-23 22:05:39 <ikke> no
2021-07-24 01:01:27 <Ariadne> nmeum: tbh i’m kinda not convinced by opendoas
2021-07-24 01:01:45 <Ariadne> i like the idea of using a daemon to mediate the privilege escalation
2021-07-24 01:01:52 <Ariadne> i think i will hack this up over weekend
2021-07-24 01:34:14 <ericonr> Ariadne: how would you make it different from s6-sudo, if you have an idea already
2021-07-24 01:34:42 <Ariadne> s6-sudo is not quite the same
2021-07-24 01:35:12 <Ariadne> afaik s6-sudod won’t run arbitrary programs but only the one specified on the command line
2021-07-24 01:41:36 <dalias> well the program you specify on the command line could be one that runs an arbitrary one
2021-07-24 01:41:42 <dalias> exec "$@"
2021-07-24 01:42:04 <dalias> but that's probably not the right way to do it :-p
2021-07-24 05:37:01 <craftyguy> any chance this could get a follow up review soon-ish?
2021-07-24 05:37:04 <craftyguy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23449
2021-07-24 06:13:48 <Ariadne> dalias: yes, i have a pretty reasonable design worked out in my head on how to do this
2021-07-24 06:14:32 <Ariadne> basically,
2021-07-24 06:15:52 <Ariadne> there will be a daemon which runs as root.  it will receive messages with fd 0/1/2 transferred over SCM_RIGHTS
2021-07-24 06:16:15 <Ariadne> that daemon will run an auth program to authorize the user (ask for password or do PAM stuff)
2021-07-24 06:16:30 <Ariadne> it will then run a session program to do the actual pivot, the session program is just a supervisor
2021-07-24 06:16:48 <Ariadne> at the end of the session, the session program will send back to the client the exit code :)
2021-07-24 06:17:21 <craftyguy> maxice8: I don't understand how a -dev package normally depends on the main package, if I'm relying on abuild magic (no custom `dev(){ .. }` in APKBUILD, only using `subpackages="$pkgname-dev"`)
2021-07-24 06:33:24 <yyp> Can someone take a look at !23555? Sorry if I did something stupid, it's my first upstream aport
2021-07-24 07:14:35 <nmeum> Ariadne: sweet, if you want any help let me know :) I personally also find the idea of using a capability device in the kernel, i.e. as proposed in https://doi.org/10.1145/1400097.1400101, very interesting
2021-07-24 07:14:53 <nmeum> in any case I think we can do better than opendoas :p
2021-07-24 07:14:56 <Ariadne> what i would really like is capsicum
2021-07-24 07:15:17 <Ariadne> nmeum: yes, and i think that it is okay to not try to cover 100% of usecases
2021-07-24 07:15:44 <Ariadne> there are scenarios where an SUID approach is needed, i think trying to emulate support for those cases will just get us into trouble
2021-07-24 07:16:14 <nmeum> yep
2021-07-24 07:54:50 <nmeum> 92% of testing/ build on riscv64 if the progress bar on build.alpinelinux.org is accurate \o/
2021-07-24 08:40:38 <Ariadne> 93% now
2021-07-24 08:40:53 <Ariadne> less than 100 packages to go i think
2021-07-24 09:44:37 <donoban> hello
2021-07-24 09:46:38 <donoban> I wonder if the source of the problem is really different from having a suid binary than a always running root service (which interacts with normal users)
2021-07-24 09:49:15 <ikke> separation of concerns
2021-07-24 09:49:52 <ikke> If the root owned process does not any parsing, then that cannot be a source of vulnerabilties
2021-07-24 09:49:57 <ikke> not do*
2021-07-24 09:50:07 <donoban> I mean the root owned process vs the sudo/doas suid binary
2021-07-24 09:51:27 <ikke> the sudo/doas binary, because it's a single binary, must do everythign
2021-07-24 09:52:14 <donoban> the service will be splitted in different binaries and executed with different permissions? 
2021-07-24 09:52:23 <Sheila> Yes
2021-07-24 09:52:32 <donoban> ah, gotcha :D
2021-07-24 09:53:32 <ikke> the disadvantage is that you cannot use it for interactive purposes
2021-07-24 09:54:43 <donoban> I don't uderstand, what you mean by interactive purposes?
2021-07-24 09:56:57 <ikke> a daemon cannot elevate your current shell
2021-07-24 09:57:06 <ikke> or spawn a new process in your current shell
2021-07-24 09:57:30 <donoban> ah, I see
2021-07-24 10:38:42 <Ariadne> ikke: you can
2021-07-24 10:39:02 <Ariadne> ikke: the design i have in mind, the target process will own /dev/tty
2021-07-24 11:14:10 <ed_> ericonr: i don't think it was failing within that read, but a dump would be helpful. i wasn't going to remove the byte count right away, that should serve to reduce OOM, but checking the file is regular and 600 first seems good
2021-07-24 11:27:32 <Ariadne> you should technically use fstat(2) to address TOCTOU
2021-07-24 11:27:37 <Ariadne> but i assume you know that :p
2021-07-24 11:27:41 <Ariadne> also,
2021-07-24 11:28:16 <ikke> Ariadne: does not guard against file size changes, does it?
2021-07-24 11:28:32 <Ariadne> no, but who cares about that
2021-07-24 11:28:42 <Ariadne> you should just not read in /dev/vda to begin with :p
2021-07-24 11:28:43 <ikke> appararently ed_ :)
2021-07-24 11:29:12 <ikke> what about large_backup_50gb.img?
2021-07-24 11:29:38 <Ariadne> i mean
2021-07-24 11:29:54 <Ariadne> bluntly?  i think it is ok to crash if you ask for something stupid
2021-07-24 11:30:15 <Ariadne> play stupid games, win stupid prizes, afterall
2021-07-24 11:34:10 <ed_> byte limit was there as files can change during read. fstat for mode first is sane to add.
2021-07-24 11:38:37 <Ariadne> though, apparently the whole regex thing raised some eyebrows
2021-07-24 11:38:42 <Ariadne> amongst infosec world
2021-07-24 11:40:37 <Hello71> donoban: suid programs have all the vulnerabilities of root daemons plus all the vulnerabilities of implicitly inherited state
2021-07-24 11:43:50 <ed_> Hello71: just throwing it out there, daemons have potential availability issues too
2021-07-24 11:44:54 <Ariadne> yeah
2021-07-24 11:45:00 <Ariadne> they can
2021-07-24 11:45:11 <Ariadne> thats why we have these things called process supervisors
2021-07-24 11:46:00 <Ariadne> also, alpine tends to have people with domain expertise write specific tools, which certainly helps with keeping availability up and CVEs down
2021-07-24 11:47:51 <ed_> oh no, i'm thinking more user error leaving you without a way of starting it up again.
2021-07-24 11:48:19 <Ariadne> if a user does `sudo service sudod stop` then they kind of get what they are asking for, don't they?
2021-07-24 11:48:51 <ed_> you're right, they would indeed
2021-07-24 11:48:54 <ikke> similar to borking up the policy file
2021-07-24 11:49:01 <ed_> sort of
2021-07-24 11:49:21 <Hello71> i don't see why daemon crashes would be any more likely or any less concerning than suid binary crashes
2021-07-24 11:49:25 <ed_> the edit "hook" checks
2021-07-24 11:50:02 <Hello71> in what case would sudod crash that sudo wouldn't, and why should i not be seriously concerned about vulnerabilities in either
2021-07-24 11:50:42 <Hello71> theoretically i guess if a non-permitted user can crash sudod and not sudo, that makes DoS worse, but imo any crash in this type of software should be considered serious
2021-07-24 11:51:06 <ed_> the daemon could get oom, then what?
2021-07-24 11:51:27 <skarnet> sigh
2021-07-24 11:51:32 <skarnet> why are we still talking about this
2021-07-24 11:51:46 <ed_> because it is an interesting topic, for some?
2021-07-24 11:51:53 <skarnet> the correct approach for such a daemon is one process per client, ipcserver-style
2021-07-24 11:52:21 <skarnet> so the daemon does not oom, and all the questions are specific to one connection
2021-07-24 11:52:36 <skarnet> I'm not saying it's not interesting or important, I'm saying those are solved problems
2021-07-24 11:53:18 <skarnet> you want to address unsolved, important questions? wonder about how to transmit terminal commands and job control from client to server
2021-07-24 11:53:35 <skarnet> wonder how to accurately transmit signals
2021-07-24 11:53:49 <skarnet> so that in practice client part and server part are undiscernable
2021-07-24 11:58:28 <Ariadne> well, what i would really like to do is implement capsicum in linux :p
2021-07-24 11:58:49 <Ariadne> then the daemon could just send a capability FD back to the client allowing it to setuid() to root
2021-07-24 11:58:54 <Ariadne> et voila
2021-07-24 11:59:05 <Ariadne> unfortunately, linux world is not ready for such things
2021-07-24 11:59:32 <ikke> What is capsicum?
2021-07-24 11:59:53 <Ariadne> an object-capabilities extension implemented in FreeBSD
2021-07-24 12:00:28 <Ariadne> it allows you to pass around rights as file descriptors
2021-07-24 12:00:52 <Ariadne> it is very much the right thing here
2021-07-24 12:01:09 <Ariadne> https://www.freebsd.org/cgi/man.cgi?capsicum(4) :)
2021-07-24 12:14:45 <Hello71> doesn't that restore the original issue of implicitly inherited state
2021-07-24 12:18:25 <Hello71> also, how does capsicum solve the problem of "you may setreuid(0), but only to run this specific command"
2021-07-24 12:53:56 <Hello71> Ariadne: why are we killing bdb on the basis of potential future license issues, but keeping around zfs despite currently existing license issues? "because canonical said it was ok" seems like a mediocre argument to me, in part because it's disputed, but also because canonical gets paid to take that position, or at least they presumably think so
2021-07-24 13:07:12 <ikke> ubuntu's point of view: https://ubuntu.com/blog/zfs-licensing-and-linux
2021-07-24 13:10:34 <ikke> Linus point of view: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841
2021-07-24 18:41:31 <PureTryOut1> Is there any reason to still have `!mips` in APKBUILDs other than it being a leftover from when mips was originally added to Alpine and we still thought we would offer 32-bit mips support?
2021-07-24 18:43:15 <ikke> I stopped adding it myself
2021-07-24 18:46:29 <PureTryOut1> I've been removing it from APKBUILDs for a while as I swear we dropped it, but I just saw Jakub adding it to some package
2021-07-24 19:12:45 <Thermi> Please review !23413
2021-07-24 19:17:55 <Thermi> tyvm ikke 
2021-07-24 19:24:38 <Thermi> I also require a review of !23414
2021-07-24 19:28:30 <Thermi> Also !23416, which is quite short
2021-07-24 19:28:56 <ikke> taking a look
2021-07-24 19:32:17 <Thermi> Thank you very much
2021-07-24 19:41:29 <Thermi> Now we have the dependencies for !23414 merged
2021-07-24 19:41:43 <Thermi> And afterwards we can do !23415
2021-07-24 19:41:48 <Thermi> and then we can do !123410
2021-07-24 19:41:52 <Thermi> !23410
2021-07-24 19:41:56 <Thermi> Errr !23411
2021-07-24 19:42:00 <Thermi> That, yes
2021-07-24 19:42:04 <Thermi> and then it's finally done
2021-07-24 19:44:35 <ikke> "arch="all !ppc64le" # blocked by py3-libmdbx
2021-07-24 19:44:43 <ikke> I guess that's no longer the case?
2021-07-24 19:45:01 <Thermi> py3-libmdbx is not working on ppc64le for some reason
2021-07-24 19:45:08 <ikke> ok
2021-07-24 19:45:11 <Thermi> it crashes in a python based get function, but works on all other arches
2021-07-24 19:45:54 <Thermi> That's why kopano-core is not to be built on ppc64le. The dependency couldn't be fullfilled and the CI job would fail.
2021-07-24 19:46:09 <ikke> Yes, understood
2021-07-24 19:51:13 <ikke> Thermi: would it make sense to split several components of copano-core up in subpackages?
2021-07-24 19:53:38 <Thermi> No, because they are interdependent
2021-07-24 19:53:45 <ikke> ok
2021-07-24 19:54:32 <ikke> pipeline is green now
2021-07-24 19:55:15 <Thermi> Tyvm
2021-07-24 19:55:18 <Thermi> I'm thinking now.
2021-07-24 19:57:14 <Thermi> -ical and -gateway are optional components but splitting them out makes no sense because only their scripts or binaries themselves would be splittable. The primary size comes from shared libraries
2021-07-24 19:57:27 <Thermi> So it'd be possible, but nonsensical
2021-07-24 19:57:42 <Thermi> -spooler and -dagent are necessary for email delivery and sending
2021-07-24 19:57:48 <Thermi> -server is the core component doing MAPI
2021-07-24 19:58:00 <Thermi> -monitor is for quotas and -search is for a fast search
2021-07-24 19:58:37 <Thermi> -gateway is for imap, pop3, and smtp clients, and -ical is for ical access to the integrated calendar
2021-07-24 19:59:36 <ikke> So there is no way to have certain components on a different server?
2021-07-24 19:59:52 <Thermi> There is, but it makes no sense to split the packages
2021-07-24 19:59:56 <ikke> ok
2021-07-24 20:09:56 <Thermi> Is there a problem with the APKBUILD for kopano-core?
2021-07-24 20:12:23 <ikke> It's a bit larger, still reviewing it
2021-07-24 20:13:12 <Thermi> I see.
2021-07-24 20:13:18 <Thermi> Ty
2021-07-24 20:18:58 <ikke> I have one remark / question, but it's not critical
2021-07-24 20:19:06 <ikke> added it to the MR
2021-07-24 20:20:12 <Thermi> I saw it
2021-07-24 20:20:32 <Thermi> I'm going to investigate it on my test box to see if everything works if I take that access right away
2021-07-24 20:55:04 <ikke> Thermi: py3-libmdbx fails on mips64 because libmdbx is missing
2021-07-24 21:03:03 <Thermi> ikke, Does libmdbx build on mips64?
2021-07-24 21:03:34 <ikke> 622bed6a841313daedd39dbd1dec592aee28e1ec
2021-07-24 21:05:01 <Thermi> I see
2021-07-24 21:07:32 <Ariadne> Hello71: i mean i’d rather people use btrfs than zfs
2021-07-24 21:08:27 <ikke> is btrfs stable enough?
2021-07-24 21:08:40 <ikke> I keep hearing people having issues
2021-07-24 21:10:03 <Ariadne> fedora seem to think so
2021-07-24 21:10:49 <Ariadne> none the less the zfs stuff is a vestige from an earlier time and unlike bdb, we can’t just get rid of it so easily when there are PBs of data being stored in it by alpine users
2021-07-24 21:13:42 <Ariadne> Hello71: so basically i do want to have that conversation at some point but i have no idea how to get us out of that mess.  perhaps ZFS can be shipped in Sheila’s apk fission or something like that.
2021-07-24 23:35:40 <Ariadne> personally i wonder if zfs is actually stable
2021-07-24 23:36:04 <Ariadne> every attempt i’ve made at using it in production in both freebsd and alpine i’ve wound up backing out of using it due to bugs
2021-07-24 23:38:13 <Hello71> aiui it's stable in the sense of "doesn't eat your data", but that doesn't preclude it eating your ram or the userspace tools sucking
2021-07-24 23:38:26 <Hello71> not sure about the latter but the former is definitely true
2021-07-24 23:38:48 <Hello71> even if "it uses all the free ram" isn't really accurate because mumblemumble ARC or whatever
2021-07-24 23:38:54 <dne> it has definitely been stable on freebsd for me, for years
2021-07-24 23:39:46 <Hello71> for a nextgen filesystem i think bcachefs is promising
2021-07-24 23:41:15 <Sheila> I know several folks who’ve used it for years without issue. 🤷
2021-07-24 23:41:57 <Hello71> or, really, currentgen, but filesystem development and uptake moves slowly
2021-07-25 00:05:23 <Ariadne> i believe people are using it, i just found the performance disappointing for the complexity it introduces
2021-07-25 00:05:55 <Ariadne> i think layering LVM and XFS is a better approach in almost all cases
2021-07-25 00:29:55 <adamplumb[m]> I'm trying to play a .amr file (for Visual Voicemail) on pmOS.  It should be a part of gst-plugins-ugly but the alpine distribution doesn't seem to include the amr extension(s)
2021-07-25 00:30:02 <adamplumb[m]>  * I'm trying to play a .amr file (for Visual Voicemail) on pmOS.  It should be a part of gst-plugins-ugly but the alpine distribution doesn't seem to include the amr extension(s).  Is that intentional?
2021-07-25 00:31:15 <adamplumb[m]> We do have opencore-amr installed (fdk-aac), which seems related
2021-07-25 00:41:35 <maxice8> we don't pass any -D so it uses automatic dependencies, seems like it is not enabled explicitly and dependencies are not there to cause it to be automatically activated
2021-07-25 00:58:56 <adamplumb[m]> hmm any idea how i need to get the aport to build with this extension?  I installed fdk-aac-dev but seems to be no change
2021-07-25 01:08:10 <maxice8> edit community/gst-plugins-ugly/APKBUILD and modify the `abuild-meson` call to pass -Damrnb=enabled and -Darmwbdec=enabled and then bump pkgrel= by 1
2021-07-25 01:10:38 <Thermi> ikke, I took care of it.
2021-07-25 01:13:45 <adamplumb[m]> @e8
2021-07-25 01:13:55 <adamplumb[m]>  * @e8 that seems to create a build error
2021-07-25 01:14:05 <adamplumb[m]> ext/amrnb/meson.build:1:0: ERROR: Dependency "opencore-amrnb" not found, tried pkgconfig
2021-07-25 01:14:26 <maxice8> then we need to find whichever package provides the pkg-config for opencore-amrnb
2021-07-25 01:14:28 <adamplumb[m]> it seems the fdk-aac-dev package doesn't provide that
2021-07-25 01:14:30 <maxice8> apk seach pc:opencore-amrnb
2021-07-25 01:15:00 <adamplumb[m]> seems to be an empty resultset
2021-07-25 01:15:10 <maxice8> time to create a new aport :D
2021-07-25 01:15:15 <adamplumb[m]> hah
2021-07-25 01:15:54 <adamplumb[m]> hmm it's weird, because opencore.amrnb points to sourceforge here: https://sourceforge.net/projects/opencore-amr/ which gives me a fdk-aac.tar.gz file
2021-07-25 01:16:03 <maxice8> https://github.com/BelledonneCommunications/opencore-amr
2021-07-25 01:16:04 <adamplumb[m]> trying to build that directly now
2021-07-25 01:16:21 <adamplumb[m]> oh snap... well that's a completely different thing
2021-07-25 01:16:40 <maxice8> let me check fdk-aac
2021-07-25 01:17:38 <maxice8> https://github.com/archlinux/svntogit-packages/blob/packages/opencore-amr/trunk/PKGBUILD archlinux is so useful, love them
2021-07-25 01:18:42 <adamplumb[m]> ah, looks like the download button gave me the file i didn't want there
2021-07-25 01:31:18 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23587
2021-07-25 01:37:45 <Thermi> maxice8, ty
2021-07-25 01:38:40 <Thermi> Could anybody please review !23411? It's one of the kopano related MRs that we can merge without dependencies
2021-07-25 01:44:36 <adamplumb[m]> <maxice8 "https://gitlab.alpinelinux.org/a"> Thanks!  I was actually working on one myself, but I'll test this out
2021-07-25 01:44:56 <maxice8> It will need a maintainer to go to community/ and be used by gst-plugins-ugly
2021-07-25 01:51:15 <adamplumb[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/plDkoqbOvBbFwMJdhHIaAztu/message.txt >

2021-07-25 01:58:54 <adamplumb[m]> oh maybe because i set it up in the community folder, not testing
2021-07-25 01:59:38 <adamplumb[m]>  * oh maybe because i set it up in the community folder, not testing.  Moved to testing and now it built
2021-07-25 03:05:56 <Ariadne> note that whatever opencore amr is
2021-07-25 03:06:13 <Ariadne> if it’s related to AAC audio it needs to be checked for patent issues
2021-07-25 03:06:35 <danieli> looks like opencore-amr is from AOSP (android)
2021-07-25 03:07:46 <danieli> but the license of the one they modified (by Fraunhofer) doesn't have a patent grant
2021-07-25 03:08:04 <Ariadne> that’s what i mean
2021-07-25 03:08:18 <Ariadne> we are already in a mess with this
2021-07-25 03:08:22 <Ariadne> i don’t want to make it worse
2021-07-25 03:08:33 <Ariadne> so is AMR codec patent encumbered ?
2021-07-25 04:17:27 <Hello71> unlikely that original AMR is still patented, since it was released in 1999
2021-07-25 04:17:47 <Hello71> but no need for opencore-amr imo because ffmpeg already comes with amr decoders
2021-07-25 04:18:39 <Hello71> AMR is not related to AAC except that it was also patented and also adamplumb[m] doesn't know how sourceforge works (is broken)
2021-07-25 04:19:14 <Hello71> adamplumb[m]: i bet you can fix your problem without installing crap by just apk add gst-libav
2021-07-25 04:19:38 <Hello71> also -> #alpine-linux
2021-07-25 04:27:27 <Hello71> continuing my previous comment, i don't see any reason to encode new amr. opus is much better, and almost everything supports aac-lc at least, so pick one of those (aac-lc is also patent expired)
2021-07-25 04:28:19 <Hello71> unless you are interfacing with a gsm network i guess?
2021-07-25 06:49:52 <maxice8> considering it is pmOS then possibly
2021-07-25 07:43:01 <Thermi> ikke, is there any change to the commit you just changed, in comparison to mine?
2021-07-25 07:43:08 <Thermi> s/changed/pushed/
2021-07-25 07:43:08 <alpine-meetbot> Thermi meant to say: ikke, is there any change to the commit you just pushed, in comparison to mine?
2021-07-25 07:43:19 <ikke> Thermi: whitespace fix
2021-07-25 07:43:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23414/diffs?diff_id=132129&start_sha=46378aa7d17662269ea66e46ef718ffe505ce36a
2021-07-25 07:43:53 <Thermi> Ah
2021-07-25 07:44:14 <Thermi> tabs, not spaces, I see
2021-07-25 07:44:21 <ikke> indeed
2021-07-25 07:50:16 <Thermi> Thank you, ikke
2021-07-25 07:54:07 <Thermi> I also need z-push and kopano-webapp merged
2021-07-25 07:54:32 <Thermi> That's !23411 and !23415
2021-07-25 07:54:39 <ikke> Will look at those later
2021-07-25 07:55:13 <Thermi> thank you
2021-07-25 08:12:37 <wener> dose this irc archived ? want to know the zfs discuss
2021-07-25 08:13:25 <ikke> 9https://irclogs.alpinelinux.org/
2021-07-25 08:13:31 <wener> thx
2021-07-25 11:04:38 <adamplumb[m]> <Hello71 "unless you are interfacing with "> Yeah i'm on pmOS and this is to play voicemail messages using the new visual voicemail daemon/player app
2021-07-25 14:46:46 <caskd> Does abuild remove dependencies it provides as subpackages?
2021-07-25 14:47:14 <caskd> Tried to include linux-headers in main package and it doesn't install on build
2021-07-25 14:47:23 <ikke> You mean from the main package? It should not do that
2021-07-25 14:47:45 <caskd> yeah, as makedepends
2021-07-25 14:48:50 <caskd> http://0x0.st/-Wbw.txt working on this and it seems like it doesn't want to install linux-headers
2021-07-25 14:50:18 <Hello71> linux-headers shouldn't be tied to linux-lts
2021-07-25 14:50:39 <Hello71> it is technically same source tree but should be treated as separate package
2021-07-25 14:51:07 <caskd> right...
2021-07-25 14:51:27 <caskd> still weird this happens
2021-07-25 14:52:12 <ikke> and linux-headers is not already installed?
2021-07-25 14:52:23 <caskd> i had to install it manually
2021-07-25 14:52:34 <caskd> if i removed it, it would not install on build
2021-07-25 14:55:15 <ikke> We have these kinds of mechanisms in aports
2021-07-25 14:56:09 <caskd> Maybe this got into the distributed abuild?
2021-07-25 15:06:02 <caskd> after renaming subpackage, it doesn't do that anymore
2021-07-25 16:01:25 <graywolf> What is alpine's policy on bug fixing packages ahead of upstream (if the bug is not (alpine|musl)-specific)? I think I've found a bug in openrc's cgroup cleanup, it that something I should send to aports? Or do I need to roll my own openrc package if I want the fix before the next openrc release?
2021-07-25 16:02:59 <ikke> Is the bug already fixed upstream (but no release yet)?
2021-07-25 16:08:48 <graywolf> ikke: Not yet, asking in #openrc if I'm right it's broken (but since it does not work without my tweak I think so). Was just curious what should be my next steps (assuming they confirm the bug and accept the patch).
2021-07-25 16:09:56 <ikke> yeah, I would start with that
2021-07-25 16:46:05 <ikke> kpcyrd: do you mind if I modernize the APKBUILD for acmetool to use go modules? (Reason is that it fails to build on riscv64 atm)
2021-07-25 16:46:19 <nmeum> I have a fix already I think
2021-07-25 16:46:22 <ikke> ah ok
2021-07-25 16:46:40 <nmeum> but yeah that aport should be cleanup up in general
2021-07-25 16:46:49 <nmeum> I just want to fix the build failure on riscv64 for now ':D
2021-07-25 16:47:10 <kpcyrd> ikke: sure, go ahead! I'm not using acmetool myself anymore actually, I wrote my own implementation in the meantime :o
2021-07-25 16:48:11 <ikke> I'll wait for nmeum to push his fix, then I'll modernize it
2021-07-25 16:48:29 <nmeum> pushed :)
2021-07-25 17:09:59 <ikke> fun fact: acmetool apparently ships an APKBUILD itself as well
2021-07-25 17:10:20 <ikke> But it's not to our standards
2021-07-25 20:15:49 <ericonr> Ariadne: how do you feel about libfetch using getlogin() for the username to send to password protected ftp servers
2021-07-25 20:16:35 <ericonr> I mean, password protected ftp is kinda useless anyway, but it still feels wrong to see getlogin() bastardized for that
2021-07-25 20:40:09 <danieli> I feel like that's leaking information without asking the user first (with a flag or interactive)
2021-07-25 20:41:28 <danieli> using getlogin() might work nicely as a default value, something similar to what the `ftp` tool does (overrideable default)
2021-07-25 20:42:06 <ericonr> given that most people use libfetch for package management, it will always send "root" too :D
2021-07-25 22:30:34 <Ariadne> ericonr: we plan to remove the ftp support entirely
2021-07-25 22:32:06 <dalias> ericonr, i feel like that's almost a privacy/infoleak bug
2021-07-25 22:32:53 <dalias> while some oldschool folks might expect it, i dont think anyone not from that kind of background would expect running the ftp command to expose their username to the remote server by default
2021-07-25 22:33:33 <Ariadne> i agree but its a non issue since we plan to remove the ftp support anyway :p
2021-07-25 22:33:40 <dalias> :)
2021-07-25 22:33:57 <Ariadne> there are an entirety of zero mirrors for alpine that are FTP
2021-07-25 22:34:05 <Ariadne> so why support it :D
2021-07-25 22:34:22 <dalias> ?
2021-07-25 22:34:46 <dalias> do you mean the ftp utility or just ftp backend for packages?
2021-07-25 22:45:13 <Ariadne> i mean the ftp:// support in apk-tools
2021-07-25 22:45:19 <Ariadne> thats what we're talking about
2021-07-25 22:45:35 <Ariadne> (and also void-linux since they also use libfetch)
2021-07-25 23:35:06 <ericonr> dalias: given that it's ftp, supposedly the remote server and the entire web too :p
2021-07-25 23:36:25 <ericonr> Ariadne: removal makes sense, I doubt anyone running a mirror isn't as capable of running a proper httpd
2021-07-25 23:36:34 <Ariadne> we have zero mirrors that are ftp-only
2021-07-25 23:36:44 <Ariadne> and alpine mirror network has always been http
2021-07-26 00:04:06 <Ariadne> hmmph
2021-07-26 00:04:29 <Ariadne> `ping 0177.0.0.1` works with musl's getaddrinfo() (it parses it as octal)
2021-07-26 00:04:55 <Ariadne> i wonder if that should be changed
2021-07-26 00:05:02 <Ariadne> dalias: ^
2021-07-26 00:06:57 <dalias> "If the nodename argument is not null, it can be a descriptive name or can be an address string. If the specified address family is AF_INET, [IP6] [Option Start]  AF_INET6, [Option End] or AF_UNSPEC, valid descriptive names include host names. If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr are valid."
2021-07-26 00:07:03 <dalias> inet_addr:
2021-07-26 00:07:08 <dalias> "All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise, the number is interpreted as decimal)."
2021-07-26 00:07:43 <Ariadne> POSIX sucks :(
2021-07-26 00:07:44 <dalias> i.e. it's not just a quirk, it's the required behavior per the spec
2021-07-26 00:08:02 <dalias> you can also do ping 0x7f000001
2021-07-26 00:08:09 <Ariadne> POSIX sucks :(
2021-07-26 00:08:16 <dalias> :)
2021-07-26 00:08:24 <dalias> or
2021-07-26 00:08:35 <Ariadne> no this is definitely " :( "
2021-07-26 00:08:35 <dalias> ping 017700000001
2021-07-26 00:08:56 <Ariadne> this is horrible
2021-07-26 00:09:05 <dalias> what's so horrible about it? :)
2021-07-26 00:09:24 <Ariadne> people can use this 'feature' to obfuscate things like C&C ips
2021-07-26 00:09:32 <dalias> lol
2021-07-26 00:09:44 <dalias> in what context?
2021-07-26 00:09:55 <Ariadne> from like humans looking at it
2021-07-26 00:09:56 <dalias> "antivirus software" grepping shell scripts
2021-07-26 00:10:26 <Ariadne> consider stuff like
2021-07-26 00:10:40 <Ariadne> curl 'http://017700000001/getcommands.php' or whatever
2021-07-26 00:10:46 <Ariadne> nope, this is awful
2021-07-26 00:11:00 <Ariadne> oh well
2021-07-26 00:11:28 <dalias> if you think that's bad try in your browser http://0x934b6577 ;-)
2021-07-26 00:11:35 <Hello71> doesn't glibc do the same thing
2021-07-26 00:11:39 <dalias> yes of course
2021-07-26 00:11:43 <dalias> and browsers do too
2021-07-26 00:11:44 <Hello71> windows supports at least decimal
2021-07-26 00:11:50 <ericonr> there was a perl cve about this recently
2021-07-26 00:11:52 <ericonr> iirc
2021-07-26 00:11:54 <Hello71> although they probably got that from bsd
2021-07-26 00:11:58 <dalias> ericonr, ...
2021-07-26 00:12:08 <dalias> what were they doing where it could be a cve ??
2021-07-26 00:12:21 <ericonr> hang on, lemme see if I can find it
2021-07-26 00:12:52 <Ariadne> dalias: presumably, because they use regex \d\.\d\.\d\.\d to parse the ip parts
2021-07-26 00:13:03 <Ariadne> well
2021-07-26 00:13:08 <Ariadne> whatever the regex actually is
2021-07-26 00:13:09 <ericonr> https://bugzilla.redhat.com/show_bug.cgi?id=1944874
2021-07-26 00:13:24 <ericonr> the first blog post link explains it
2021-07-26 00:15:59 <dalias> sounds like a bogus cve, and like the cve belongs in the perl software using regex matches for ip literal strings rather than matching the binary address..
2021-07-26 00:16:11 <skarnet> the right question is, is there any legitimate use of this ip form, or is it just old rotting hysterical raisins that should have gone into the trash bin 10 years ago?
2021-07-26 00:16:20 <Ariadne> thats what i am saying yes
2021-07-26 00:16:25 <Ariadne> like why do we support this crap :D
2021-07-26 00:16:31 <Ariadne> "because POSIX"
2021-07-26 00:16:36 <Ariadne> but why does POSIX still support this crap
2021-07-26 00:16:47 <dalias> because it's a public interface and always has been
2021-07-26 00:16:52 <dalias> even browsers support it
2021-07-26 00:16:58 <dalias> just because you didn't know about it doesn't mean it's wrong
2021-07-26 00:17:01 <skarnet> posix follows existing behaviour, if the behaviour stops existing, it can be obsoleted and eventually removed
2021-07-26 00:17:19 <skarnet> I knew about it, I just never encountered it in the wild
2021-07-26 00:17:29 <skarnet> and I consider it a good thing that I didn't
2021-07-26 00:17:30 <Ariadne> i mean, i vaguely knew about the hex version
2021-07-26 00:17:38 <Ariadne> but i forgot about it
2021-07-26 00:17:49 <dalias> i dont see how "i can't block FOO by matching ip literal" is a security problem when someone can also just point a dns label at it
2021-07-26 00:18:03 <ericonr> dalias: they were libraries doing the matching
2021-07-26 00:18:09 <dalias> blocking unwanted things by text matching does not work
2021-07-26 00:18:21 <dalias> and never has
2021-07-26 00:18:37 <ericonr> applications passed the string to it, so it would be expected that the libraries did things correcrly
2021-07-26 00:18:58 <skarnet> tbh idc about the context here, I care about expectations for people who write ip addresses
2021-07-26 00:22:32 <Hello71> i think the problem was that the library was poorly programmed in such a way that if you asked it "is 'localhost' in '127.0.0.0/8'", it said "'localhost' is invalid" but if you said "is '0127.0.0.1' in '127.0.0.0/8'" it said "yes of course"
2021-07-26 00:22:59 <Hello71> which seems like a poorly designed system
2021-07-26 00:24:31 <dalias> ah
2021-07-26 00:25:02 <dalias> so it was misparsing 0127 as 127
2021-07-26 00:25:05 <ericonr> yes
2021-07-26 00:26:33 <Ariadne> that’s my concern too (what skarnet said)
2021-07-26 00:26:56 <Ariadne> i think these more exotic formats just serve to confuse people
2021-07-26 00:27:13 <Ariadne> people think IPv4 == quad decimals
2021-07-26 00:31:09 <dalias> individual programs are free not to accept forms without 3 .'s and where any component begins with a 0 but isn't exactly "0"
2021-07-26 00:31:49 <dalias> btw ipv6 has a lot more possible non-canonical ways of writing things
2021-07-26 00:32:07 <dalias> using :: or embedded ipv4 aaa.bbb.ccc.ddd part
2021-07-26 00:32:39 <dalias> so anything built on assumptions about ip literals is just highly dated at best
2021-07-26 00:35:24 <skarnet> dalias: what about embedded [0x934b6577] ? :P
2021-07-26 00:36:21 <skarnet> because if it's supposed to be supported I'm going to write all my ipv6 addresses like that to annoy people until it stops being supported
2021-07-26 00:37:35 <Ariadne> ^^^
2021-07-26 00:38:39 <dalias> skarnet, no, apparently not
2021-07-26 00:38:44 <Ariadne> i think that we can and should make an effort to deprecate and remove stupidity
2021-07-26 00:38:50 <skarnet> ^
2021-07-26 00:39:32 <skarnet> well if it's not supported then we cannot claim that ipv4 addresses can be embedded in ipv6
2021-07-26 00:39:41 <skarnet> so we should deprecated embedded dotted decimal notation as well
2021-07-26 00:39:48 <dalias> the embedded v4 address form for v6 requires 3 .'s and all 4 components decimal
2021-07-26 00:39:49 <skarnet> we should deprecate*
2021-07-26 00:40:17 <skarnet> that sounds like a good requirement, why not adopt it for all ipv4
2021-07-26 00:40:32 <dalias> the claim isn't that you can embed arbitrary representations of v4 addresses in a v6 address string
2021-07-26 00:41:07 <dalias> it's that there's *one form* for representing v4 addresses as part of a v6, for convenience in reading and writing them
2021-07-26 00:41:28 <dalias> btw if you like your v4 in hex, you can just write it in native ipv6 form :)
2021-07-26 00:41:36 <skarnet> my point is that there is a restriction on the representation for good reason: the other forms are unused and unnecessarily difficult to parse
2021-07-26 00:41:38 <dalias> ::7f00:0001
2021-07-26 00:41:52 <dalias> actually in this case the other forms would be ambiguous
2021-07-26 00:43:01 <dalias> f00b::1234 could be read either as plain v6 with 6 0 parts elided, or as embedded v4 "1234" with 5 0 parts elided
2021-07-26 00:43:13 <dalias> the .'s are needed to disambiguate
2021-07-26 00:43:24 <skarnet> I thought you needed square brackets
2021-07-26 00:43:26 <dalias> this is probably the motivation for limiting the form that can be used
2021-07-26 00:43:27 <dalias> no
2021-07-26 00:43:34 <Ariadne> we’re talking about making it sane for humans
2021-07-26 00:43:35 <dalias> square brackets are not meaningful at this layer
2021-07-26 00:43:47 <Ariadne> computers can obviously parse anything
2021-07-26 00:43:52 <skarnet> they really cannot
2021-07-26 00:43:53 <dalias> they're a notation in url syntax for dealing with ipv6's idiotic reassignment of the : characer
2021-07-26 00:43:57 <skarnet> because humans have to write the parsers
2021-07-26 00:44:03 <skarnet> and humans are terrible at writing parsers
2021-07-26 00:44:04 <Ariadne> well you know what i mean
2021-07-26 00:44:17 <Ariadne> they can parse whatever cursed thing somebody comes up with
2021-07-26 00:44:18 <dalias> getaddrinfo for example will not accept [some_ipv6]
2021-07-26 00:44:40 <dalias> rather a url parser sees the [] and uses it to split host and service strings before calling getaddrinfo
2021-07-26 00:44:43 <skarnet> I know, I have written a parser for ipv6 that understands :: and it was painful enough without understanding dotted ipv4
2021-07-26 00:44:51 <dalias> :)
2021-07-26 00:44:59 <Ariadne> we should switch to ipv5
2021-07-26 00:45:08 <Ariadne> which is just ipv4 expanded to be 64 but
2021-07-26 00:45:09 <dalias> the dotted ipv4 thing is really important when you use v4mapped addresses tho
2021-07-26 00:45:11 <skarnet> if I had to add dotted ipv4 support the transition table would triple in size
2021-07-26 00:45:19 <dalias> (binding to just :: and getting ipv4 connections on an ipv6 socket)
2021-07-26 00:45:37 <dalias> otherwise everyone would whine to no end that the v4 address is not legible in their logs
2021-07-26 00:45:51 <skarnet> that's not a parser, that's a formatter
2021-07-26 00:45:55 <skarnet> formatters are obviously easier
2021-07-26 00:45:56 <dalias> but ::ffff:aaa.bbb.ccc.ddd is very legible
2021-07-26 00:46:08 <dalias> well you want it to be round-trippable
2021-07-26 00:47:38 <dalias> for example
2021-07-26 00:47:41 <dalias> Received: from mother.openwall.net ([::ffff:195.42.179.200])
2021-07-26 00:49:08 <skarnet> ah yes I've always wanted to read ipv6 by parsing Received: SMTP headers
2021-07-26 00:49:52 <skarnet> that's a typical case where I don't care that my formatter is roundtrippable
2021-07-26 00:50:23 <Ariadne> skamail when
2021-07-26 00:51:09 <skarnet> when we can purge smtp with fire
2021-07-26 00:57:26 <Ariadne> anyway
2021-07-26 00:57:51 <Ariadne> if i were to convince the austin group to remove this legacy crap from POSIX and they do it
2021-07-26 00:57:59 <Ariadne> can musl remove it :D
2021-07-26 01:00:43 <ericonr> musl didn't remove gets tho :p
2021-07-26 01:02:06 <Ariadne> it’s so useful
2021-07-26 01:02:14 <Ariadne> why would you remove it
2021-07-26 06:47:39 <sircmpwn> is it possible to upgrade from 3.12 directly to 3.14?
2021-07-26 06:48:11 <mps> yes
2021-07-26 06:48:14 <sircmpwn> coolio
2021-07-26 06:48:59 <mps> I upgraded from 3.8 to 3.14 one SBC two weeks ago
2021-07-26 06:58:44 <ikke> I've upgraded a couple of our servers from 3.10/3.11 to 3.13
2021-07-26 06:59:01 <ikke> (before 3.14 was out obviously)
2021-07-26 07:00:57 <mps> ikke: good morning :)
2021-07-26 07:02:01 <mps> and good morning to all, ofc
2021-07-26 07:02:20 <ikke> mps: morning
2021-07-26 07:02:25 <ikke> enjoying your vacation?
2021-07-26 07:03:10 <mps> yes, it was nice break from 'everyday' routine
2021-07-26 07:03:26 <ikke> Can imagine, yes
2021-07-26 07:04:05 <mps> would be nice to repeat such 'things' few times in a year
2021-07-26 07:06:05 <mps> and I meet some very interesting (unusual) and nice people
2021-07-26 07:07:19 <mps> and learned to better understand Slovakian language as a bonus
2021-07-26 07:20:19 <yyp> \o/ opustags merged
2021-07-26 07:20:31 <yyp> Really glad to have an upstream Alpine package :D
2021-07-26 08:07:45 <sircmpwn> py3-click needs a rebuild on 3.14
2021-07-26 08:08:21 <sircmpwn> it was built for python 3.8
2021-07-26 08:11:57 <sircmpwn> hm, strike that, was some other issue, must have installed the package from another source
2021-07-26 08:33:34 <sircmpwn> dl-2's 3.14 community x86_64 repo is empty
2021-07-26 08:34:16 <sircmpwn> http://dl-2.alpinelinux.org/alpine/v3.14/community/x86_64/
2021-07-26 08:48:14 <ikke> sircmpwn: dl-2 is behind due to full disk
2021-07-26 08:52:35 <Thermi> Please somebody review !18285
2021-07-26 08:58:42 <sircmpwn> ikke: maybe it should be removed from the mirror list until it can be resolved
2021-07-26 08:59:21 <ikke> Yes
2021-07-26 08:59:38 <ikke> though, that does not help existing users
2021-07-26 08:59:47 <sircmpwn> no, unfortunately not
2021-07-26 09:00:09 <ikke> But because we control the dns record, we could redirect it to a working mirror
2021-07-26 09:00:19 <sircmpwn> hm, yeah, good idea
2021-07-26 09:22:08 <ncopa> good morning
2021-07-26 09:22:54 <ncopa> i updated the kernel to 5.10.53 but somethign is wrong. I get delays of multiple seconds
2021-07-26 09:23:15 <ncopa> i type in the browser and it takes 2 seconds before something happens
2021-07-26 09:23:33 <ncopa> i move the window and it takes 10 seconds before it moves
2021-07-26 09:24:40 <mps> 'use linux-edge, Luke' :)
2021-07-26 09:25:41 <mps> ncopa: hope you will find problem soon
2021-07-26 09:26:00 <ncopa> hum. its normal again. it happened while doing some io intensive work in a vm
2021-07-26 09:26:37 <mps> force preempt?
2021-07-26 09:27:14 <mps> oh, voluntary still
2021-07-26 09:27:32 <ncopa> no, its preemt none still
2021-07-26 09:27:37 <ncopa> which might be the reason
2021-07-26 09:27:45 <mps> aha
2021-07-26 09:28:58 <mps> I don't want to 'force you' to use 'forced preempt' but I think it is best options for most use cases
2021-07-26 09:50:13 <Ariadne> well either way it’s a regression tho
2021-07-26 10:06:57 <donoban> ncopa: I experiment similar behaviour sometimes and I detect a vm and/or it's related freerdp consuming a lot of CPU, I'm gonna trying with the forced preepmtion
2021-07-26 11:09:41 <mps> ncopa: did you had time to look at perl upgrade to 5.34.0
2021-07-26 11:29:07 <ncopa> mps: no. i kinda forgot it
2021-07-26 11:29:13 <ncopa> i will have a look at it now
2021-07-26 11:29:33 <ikke> timlegge still has some MRs open to fix things up
2021-07-26 11:29:40 <ikke> mostly remove perl-dev where it's not required
2021-07-26 11:30:39 <mps> ikke: yes, his MRs are to fix binary modules builds after upgrading to 5.34.0
2021-07-26 11:31:38 <ikke> mps: generally we want to do that in one go
2021-07-26 11:32:22 <mps> ikke: understand, but not sure how much effort it will require
2021-07-26 11:33:11 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22857
2021-07-26 11:33:20 <mps> (have to move my access point to another hardware, will be off-line for some time)
2021-07-26 11:35:43 <ncopa> im gonna merge the both in same go and rebuild whatever needed to be rebuilt
2021-07-26 11:36:44 <ikke> The idea was to reduce the amount of packages that need to be rebuilt
2021-07-26 13:21:39 <timlegge> yes, !22857 reduces the number of modules depending on perl-dev significantly also https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/103 removes perl-dev as a default in apkbuild-cpan
2021-07-26 14:18:06 <Habbie> i just posted https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23635
2021-07-26 14:18:19 <Habbie> updating pdns to 4.5.1 and changing the maintainer to me (see alpine-devel thread from April/May)
2021-07-26 14:18:28 <Habbie> algitbot auto-assigned the MR to the old maintainer
2021-07-26 14:18:36 <Habbie> is that a problem?
2021-07-26 14:19:51 <ikke> no
2021-07-26 14:23:09 <Habbie> thanks
2021-07-26 14:43:48 <maxice8> That is working exactly as expected
2021-07-26 14:45:04 <ikke> I guess they were concerned that the current maintainer is not active
2021-07-26 14:48:43 <Habbie> maxice8, i figured
2021-07-26 14:48:57 <Habbie> but indeed, the current maintainer is not active
2021-07-26 14:49:08 <Habbie> he took a month to confirm the handover to me :)
2021-07-26 15:02:19 <ncopa> im having issue with perl-convert-uulib with perl 5.34
2021-07-26 15:02:45 <ncopa> https://tpaste.us/ovPq
2021-07-26 15:03:21 <ncopa> for some reason `make test` fails. DynaLoader's bootstrap does not appear to work
2021-07-26 15:03:37 <ncopa> i cannot make any sense of it
2021-07-26 15:03:50 <ikke> timlegge: ^ ?
2021-07-26 15:04:31 <ncopa> the /usr/lib/perl5/core_perl/DynaLoader.pm  does have a sub bootstrap
2021-07-26 15:08:06 <timlegge> looking
2021-07-26 15:14:55 <mps>  standard perl versions 5.022 and up are not supported by Convert::UUlib
2021-07-26 15:16:12 <ikke> ncopa: are you looking at !22857? Otherwise I will finish my review
2021-07-26 15:16:54 <Habbie> mps, you said earlier to me 'contributor field should be removed' - can you comment on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23635#note_170435 to tell me i did the right thing, or not?
2021-07-26 15:17:06 <ncopa> ikke: im including that MR in the perl rebuilds
2021-07-26 15:17:37 <ikke> ncopa: alright, then I'll let you handle it
2021-07-26 15:20:34 <mps> ncopa: timlegge: ikke: above msg is produced by perl-canary-stability
2021-07-26 15:21:34 <mps> Habbie: 'Contributor' field is in most cases misleading
2021-07-26 15:22:01 <mps> people are not sure when to add self there
2021-07-26 15:22:11 <ikke> I never add myself anywhere
2021-07-26 15:22:17 <ikke> Because I do not care
2021-07-26 15:22:26 <mps> for one 'space' change or for important and big fix
2021-07-26 15:22:42 <mps> ikke: yes, I agree
2021-07-26 15:23:00 <Habbie> mps, right, but is my removal of all those people correct?
2021-07-26 15:23:15 <mps> imo, yes
2021-07-26 15:23:22 <Habbie> would you be willing to comment that? :)
2021-07-26 15:24:36 <mps> uh, I don't like idea to argue with someone on that list, this should be done by maintainer and maintainer discretion rights
2021-07-26 15:24:48 <Habbie> ok
2021-07-26 15:25:27 <Habbie> oh it's ikke
2021-07-26 15:25:29 <ikke> yes
2021-07-26 15:25:33 <Habbie> hi!
2021-07-26 15:25:45 <ikke> I do not care personally, but the people on that list might care
2021-07-26 15:25:47 <Habbie> so i removed it based on earlier conversations here
2021-07-26 15:25:58 <Habbie> i can put it back, i don't have an opinion on it
2021-07-26 15:26:12 <ikke> It has become quite a large list though
2021-07-26 15:26:34 <Habbie> the earlier conversation was 'it is pointless, we have git log'
2021-07-26 15:26:38 <Habbie> which makes sense to me
2021-07-26 15:26:39 <ikke> yes
2021-07-26 15:26:42 <Habbie> but does not give 'visible credits' as much
2021-07-26 15:26:47 <mps> also to me
2021-07-26 15:27:12 <mps> git log is right where to look
2021-07-26 15:27:21 <mps> right place*
2021-07-26 15:28:57 <ikke> Maybe we should patch newapkbuild to not include that by default
2021-07-26 15:29:09 <Habbie> that sounds good
2021-07-26 15:29:44 <mps> timlegge: ncopa: perl-convert-uulib is revdep for amavis, and amavis can be built without it
2021-07-26 15:32:24 <timlegge> mps: ncopa: will need to install perl 5.34 to test.  Depends whether the sun comes out today :-)
2021-07-26 15:32:54 <Habbie> ikke, so - do i put them back? i can't decide
2021-07-26 15:35:40 <Habbie> i can also delay the question by putting them back
2021-07-26 15:35:47 <Habbie> and wait and see if the project at one point decides to just drop them all
2021-07-26 15:38:07 <Habbie> i'll do that
2021-07-26 15:38:51 <mps> timlegge: https://gitlab.com/amavis/amavis/-/blob/master/RELEASE_NOTES#L1070
2021-07-26 15:39:47 <mps> so we should remove perl-convert-uulib from aports, imo
2021-07-26 15:44:31 <timlegge> likely the easiest - no longer required (optional)
2021-07-26 15:53:36 <ikke> Habbie: can you please squash your last commit into the main commit?
2021-07-26 15:53:40 <Habbie> yes
2021-07-26 15:54:10 <Habbie> done
2021-07-26 16:36:18 <Habbie> ikke, thanks for the merge!
2021-07-26 16:36:26 <ikke> yw
2021-07-26 17:58:17 <bl4ckb0ne> anybody tried to update libplacebo/mpv recently?
2021-07-26 17:59:25 <caskd> update as in bump?
2021-07-26 17:59:59 <bl4ckb0ne> yes
2021-07-26 18:00:39 <bl4ckb0ne> i bumped them to check my vulkan header update was good and i hit a surprisingly big amount of errors
2021-07-26 18:01:54 <caskd> well, the latest on aports is major version 2
2021-07-26 18:01:59 <caskd> and the latest upstream is 3
2021-07-26 18:02:07 <caskd> that's to be expected
2021-07-26 18:02:26 <caskd> https://code.videolan.org/videolan/libplacebo/-/tags/v3.104.0-rc1
2021-07-26 18:03:09 <bl4ckb0ne> i think i have to wait for a mpv release
2021-07-26 18:03:41 <caskd> likely, yeah
2021-07-26 18:03:50 <bl4ckb0ne> 
ACTION puts a reminder

2021-07-26 18:03:59 <caskd> the 3.x was released 7 months ago but idk why they didn't update it yet
2021-07-26 18:04:08 <bl4ckb0ne> last mpv release was november 2020
2021-07-26 18:04:18 <caskd> no?
2021-07-26 18:04:29 <bl4ckb0ne> there's one april 5 but its minor fixes
2021-07-26 18:04:46 <caskd> oh right
2021-07-26 18:05:52 <bl4ckb0ne> might've found the commit I need, maybe a patch would work
2021-07-26 18:06:09 <caskd> hm
2021-07-26 18:06:14 <caskd> arch uses the 3.x already 
2021-07-26 18:06:22 <caskd> with mpv 0.33.1
2021-07-26 18:07:42 <bl4ckb0ne> ttps://github.com/archlinux/svntogit-community/blob/packages/mpv/trunk/PKGBUILD#L40 yup
2021-07-26 18:07:48 <bl4ckb0ne> https://github.com/archlinux/svntogit-community/blob/packages/mpv/trunk/PKGBUILD#L40 
2021-07-26 18:07:56 <caskd> oh i see
2021-07-26 18:08:14 <caskd> then maybe on next release?
2021-07-26 18:08:27 <bl4ckb0ne> 
ACTION shrugs

2021-07-26 18:08:32 <caskd> should probably ask on mpv-related communcation channels when that's gonna be
2021-07-26 18:09:10 <caskd> but meanwhile, i guess you could prepare a bump for 3.x
2021-07-26 18:09:19 <bl4ckb0ne> aye
2021-07-26 18:10:51 <caskd> oh, this improves on vulkan gpu-api
2021-07-26 18:11:15 <bl4ckb0ne> my goal was bumping the vulkan headers
2021-07-26 18:11:26 <caskd> in that case, i am down to help bump mpv if you need assistance as having that is also in my interest
2021-07-26 18:11:43 <caskd> oh
2021-07-26 18:12:37 <bl4ckb0ne> mostly lacking time atm tbh
2021-07-26 18:12:57 <bl4ckb0ne> but i can definetly do it by mid week
2021-07-26 18:33:41 <mps> how we override -O1 flag in APKBUILD?
2021-07-26 18:34:10 <ikke> CFLAGS="$CFLAGS -Ox"
2021-07-26 18:35:26 <ikke> we default to -Os
2021-07-26 18:35:27 <mps> not LDFLAGS?
2021-07-26 18:35:38 <ikke> No -O1 in LDFLAGS is something else
2021-07-26 18:35:46 <mps> looks like default is -O1
2021-07-26 18:36:00 <ikke> Those are linker flags, not compiler flags
2021-07-26 18:36:22 <mps> yes, I'm asking for linker flags
2021-07-26 18:37:16 <ikke> Then LDFLAGS="$LDFLAGS -O.."
2021-07-26 18:37:23 <Hello71> -Wl,-O
2021-07-26 18:37:34 <mps> ahm, yes
2021-07-26 18:37:34 <ikke> ^
2021-07-26 18:37:45 <ikke> Any specific reason you want to override the linker flags?
2021-07-26 18:37:50 <Hello71> but it's highly unlikely that -Wl,-O0 does anything useful
2021-07-26 18:38:38 <mps> trying to debug crystal segfaults on x86_64
2021-07-26 18:40:43 <caskd> if the compiler optimizes things, in general the linker optimization level doesn't change too much
2021-07-26 18:41:58 <mps> yes, maybe I should use compiler -O2 or -Os
2021-07-26 18:43:02 <ikke> The default is -Os
2021-07-26 18:43:13 <ikke> for compiler optimization
2021-07-26 18:43:27 <mps> isn't it changed to -O1 some time ago?
2021-07-26 18:43:51 <ikke> No: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.conf#L1
2021-07-26 18:44:17 <Newbyte> Why is -Os used?
2021-07-26 18:45:10 <mps> alpine moto 'small, ....'
2021-07-26 18:45:11 <ikke> 1. Alpine optmizes for size. 2. Usually, due to smaller size, due to caching reasons, it might be faster as -O2
2021-07-26 18:45:14 <ikke> (but not always)
2021-07-26 19:29:20 <mps> does geeqie works for someone on edge?
2021-07-26 19:30:08 <caskd> just installed it, seems fine
2021-07-26 19:30:09 <caskd> why?
2021-07-26 19:32:51 <mps> tried under xfce on x86_64 and awesome wm on aarch64 and it starts but closes all windows and stays in background
2021-07-26 19:39:21 <mps> ah, it works in fullscreen mode
2021-07-26 20:02:46 <Thermi> ikke, is there a particular reason you're not continuing the review of MR !23415? Is there anything wrong with it?
2021-07-26 20:03:12 <ikke> Thermi: troubleshooting something else atm
2021-07-26 20:04:02 <Thermi> I see, ty
2021-07-26 20:04:35 <ikke> Just ran into another package btw that does not unpack into a subdir
2021-07-26 20:04:49 <ikke> wondering if we could add something to abuild to specify it
2021-07-26 20:04:50 <Thermi> So maybe we can get a generalized solution?
2021-07-26 20:05:03 <Thermi> Maybe something in between sourcename and source url
2021-07-26 20:05:10 <Thermi> right now it's url or name::url
2021-07-26 20:05:23 <ikke> yeah, but we could potentially break other things
2021-07-26 20:05:24 <Thermi> maybe we can have name::extractdir::url
2021-07-26 20:05:44 <Thermi> check how many elements the line has. If it's 3, use the new behaviour, if it's two, use the old behaviour
2021-07-26 20:05:46 <ikke> not sure how ossified the source syntax is
2021-07-26 20:06:14 <Thermi> or make it a top level variable
2021-07-26 20:06:29 <Thermi> like extracttodirs=0 or somethiong
2021-07-26 20:06:30 <Thermi> *something
2021-07-26 20:07:13 <Thermi> if that's set to something else than 0 and it's not empty, derive a directory to extract into from the file name
2021-07-26 20:09:55 <ikke> Thermi: we would use options then
2021-07-26 22:32:58 <timlegge> ncopa: I can't see any real issues with Convert::UUlib.  I am on edge and installed perl 5.34 with perlbrew so it should be a version with limited modules - had to install common::sense  to my perl 5.34 install via cpan but otherwise it worked.  Not sure what is going on there
2021-07-27 00:33:43 <maxice8> Ikke: void linux's xbps-src has create_wrksrc=
2021-07-27 08:17:24 <ncopa> timlegge: thanks for looking at it. i have no clue what goes wrong either
2021-07-27 08:17:35 <ncopa> also perl-html-tidy5 fails in the tests
2021-07-27 08:32:52 <ikke> maxice8: we would need to be able to specify it for each source archive
2021-07-27 11:52:44 <ncopa> i think i figured out the perl errors. seems like perl-common-sense needs to be rebuilt with perl 5.34, even if it is a noarch
2021-07-27 11:54:20 <ncopa> https://tpaste.us/1EJ4
2021-07-27 11:57:09 <ikke> That does not make sense :P
2021-07-27 11:59:42 <mps> tpaste.us is 'stuck'
2021-07-27 12:00:15 <ikke> https://tpaste.us/plrm 
2021-07-27 12:01:54 <mps> right now it started to work
2021-07-27 12:10:46 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12874 SEVERITY CRITICAL!!!!!!!!!11111oneoneeleven :|
2021-07-27 12:10:55 <Hello71> algitbot: bad bot
2021-07-27 12:15:37 <Habbie> secfixes in an APKBUILD mark the version that -fixes- a CVE?
2021-07-27 12:16:06 <Habbie> (it seems obvious but i want to be sure)
2021-07-27 12:26:35 <Habbie> ok, various entries match that assumption
2021-07-27 12:27:58 <ikke> Yes, it does
2021-07-27 12:28:03 <Habbie> ok
2021-07-27 14:20:55 <Hello71> ikke: have you seen #8476? seems related to your lvm issue or whatever
2021-07-27 14:23:35 <ikke> No, did not see it yet
2021-07-27 15:17:07 <ikke> What is the reason we use -fomit-frame-pointer?
2021-07-27 15:17:21 <ncopa> smaller/faster code
2021-07-27 15:18:13 <ncopa> i think its redundant with -Os and -Os
2021-07-27 15:18:15 <ncopa> -O2
2021-07-27 15:18:46 <ncopa> Yeah, the -O1 enables -fomit-frame-pointer
2021-07-27 15:20:36 <ericonr> if you hear the perf author say it, -fomit-frame-pointer is the devil
2021-07-27 15:20:47 <ikke> I'm debugging an issue with darktable which seems to be related to the flags we pass
2021-07-27 15:21:06 <ikke> still verifying though
2021-07-27 15:21:25 <dalias> frame pointer harms codegen a lot
2021-07-27 15:21:50 <Hello71> i thought only on x86?
2021-07-27 15:21:56 <dalias> no
2021-07-27 15:22:21 <ncopa> i think we can remove the explicit -fomit-frame-pointer since its included with -Os
2021-07-27 15:22:35 <dalias> it's particularly bad when you have functions that are leaf functions (altho gcc has an option to omit frame pointer in leaf functions which i think is on by default anyway) and otherwise-tiny, or "almost-leaf" functions that might make a function call only in a cold path
2021-07-27 15:23:08 <Sheila> there's no real reason to use it on non-x86, afaik.
2021-07-27 15:23:12 <Hello71> hm, the man page changed at some point. last i checked, it said "frame pointer is omitted at -O on platforms where it does not prevent debugging" or something
2021-07-27 15:23:52 <dalias> on i386, -fomit-frame-pointer gets you an extra gpr to use (strictly speaking this is true on all archs but it doesn't matter on the rest because they have more than 5 gprs)
2021-07-27 15:24:05 <Hello71> yes, i thought that was the biggest problem
2021-07-27 15:24:11 <dalias> but it's not the biggest problem
2021-07-27 15:24:37 <dalias> the biggest problem is 4 or 5 extra insns in the hot path setting up and tearing down a stack frame, when there should only be 2 or 3 insns total
2021-07-27 15:24:40 <Hello71> i guess aside from the extra gpr it depends on the size of your functions
2021-07-27 15:24:59 <Hello71> just use lto, that'll fix it
2021-07-27 15:25:06 <dalias> lto is evil for other reasons
2021-07-27 15:25:27 <dalias> and doesn't help if the call is across a shared lib boundary
2021-07-27 15:25:31 <Hello71> but you have to admit it does make frame pointers less bad (assuming you only use your small functions from limited places)
2021-07-27 15:25:48 <Hello71> and also not into a shared lib, and also not within a shared lib unless you use -fno-semantic-whatever
2021-07-27 15:25:53 <dalias> not if you have a library that's setup with stable ABI as a shared lib
2021-07-27 15:26:22 <dalias> where you can't just inline the trivial functions out of the lib in headers, because that breaks the ABI boundary
2021-07-27 15:26:39 <ncopa> Hello71: you are right. i think that might be the reason it was added in the first place
2021-07-27 15:27:06 <ncopa> i mean the "where it does not prevent debugging" part
2021-07-27 15:27:38 <ikke> So darktable is failing to build when I pass -Os: "error: 'l' may be uninitialized in this function [-Werror=maybe-unitialized]'
2021-07-27 15:27:46 <ikke> Without -Os, it succeeds
2021-07-27 15:28:08 <ikke> In our buildlogs, I see:  warning: 'l' may be used uninitialized in this function [-Wmaybe-uninitialized]
2021-07-27 15:28:14 <ikke> so there it's only a warning
2021-07-27 15:28:15 <ncopa> sounds like an unintialized var
2021-07-27 15:28:36 <ikke> Why is it only a warning there
2021-07-27 15:28:42 <ncopa> maybe something enables -Werror?
2021-07-27 15:29:02 <dalias> ikke, because the compiler has no way to tell if the uninitialized use is actually reachable
2021-07-27 15:29:09 <dalias> and if it's not the code is perfectly valid
2021-07-27 15:29:17 <ikke> dalias: I'm wondering about the difference in warning vs error
2021-07-27 15:29:18 <dalias> you can't just error out compiling because the compiler isn't omnisicient
2021-07-27 15:29:44 <ncopa> we normally build without -Werror
2021-07-27 15:29:52 <ikke> And I do nothing to set it
2021-07-27 15:29:59 <ikke> fyi, this is outside of abuild
2021-07-27 15:32:57 <ikke> Hmm, if(NOT SOURCE_PACKAGE); add_definitions(-Werror -Wfatal-errors); endif()
2021-07-27 15:33:18 <ncopa> so it is added when building from git
2021-07-27 15:33:22 <ncopa> makes sense
2021-07-27 15:33:52 <ikke> right
2021-07-27 15:34:06 <ncopa> try change the code to thevar = NULL; or whatever
2021-07-27 15:34:15 <ncopa> so it always is initialized
2021-07-27 15:34:46 <ikke> Just wondering why it fails with -Os
2021-07-27 15:35:03 <ncopa> its the -Werror that makes it fail, not -Os
2021-07-27 15:35:19 <ikke> If I dont explicitly set -Os, the build succeeds
2021-07-27 15:35:25 <ncopa> oh, ok
2021-07-27 15:36:00 <ikke> It started to fail when I sourced /etc/abuild.conf
2021-07-27 15:37:52 <ericonr> ikke: was it using -O2 by default?
2021-07-27 15:38:07 <ikke> yes, and if change -Os to -O2, it succeeds as well
2021-07-27 15:38:17 <ericonr> different optimization levels can lead to different diagnostics for maybe-uninitialized
2021-07-27 15:38:43 <ericonr> because it's very much not exact
2021-07-27 15:38:51 <dalias> that's what i meant by
2021-07-27 15:38:55 <dalias> <dalias> you can't just error out compiling because the compiler isn't omnisicient
2021-07-27 15:39:04 <dalias> -Werror=maybe-uninitialized is a bug in production
2021-07-27 15:39:18 <dalias> it only makes sense when developing in a controlled environment
2021-07-27 15:39:53 <ikke> yes, and they only set -Werror in development environments (building from git repos)
2021-07-27 15:45:37 <ikke> Ok, I can reproduce the crash now
2021-07-27 15:45:44 <ikke> -Os, no -Werrror
2021-07-27 15:46:08 <ikke> apparently it does not crash with -O2
2021-07-27 15:46:28 <ncopa> maybe it is that unintialized var
2021-07-27 15:46:47 <ikke> yes, will now try to fix it
2021-07-27 15:46:53 <ikke> But first needed to be able to reproduce it
2021-07-27 15:47:00 <ncopa> yup
2021-07-27 15:48:20 <ikke> hmm, they do int l; for(l=0;..)
2021-07-27 15:48:43 <ikke> oh, no, l vs i :)
2021-07-27 15:49:27 <ikke> l = i+1 in the loop
2021-07-27 15:50:40 <ikke> hmm, they reuse l outside of the loop, so if the loop never ran, it can be an issue
2021-07-27 15:54:23 <dalias> ikke, did you identify the commit that broke it?
2021-07-27 15:54:57 <ikke> dalias: no, not yet
2021-07-27 15:55:04 <dalias> looks like you have a plausble cause for the crash, if "0 iterations" is a possible runtime  scenario here
2021-07-27 15:55:10 <ikke> yes
2021-07-27 15:55:42 <ikke> Why would -Os vs -O2 matter here? Variable being optimized out?
2021-07-27 15:55:51 <dalias> see if just initializing it to 0 or 1 or whatever it should be for that case works (probably 0 since the 'last i' for 0 iterations is -1 in a sense)
2021-07-27 15:56:00 <ikke> I set it to 0 noiw
2021-07-27 15:56:11 <dalias> ikke, probably just how things happened to be laid out on the stack or registers, and what value happened to be there before
2021-07-27 15:56:17 <ikke> o
2021-07-27 15:56:19 <ikke> k
2021-07-27 15:56:39 <ikke> no, setting the variable to 0 stil crashes
2021-07-27 15:56:40 <dalias> soo no biger conceptual reason
2021-07-27 15:56:51 <dalias> :/
2021-07-27 15:57:29 <ikke> I guess now it's time to bisect
2021-07-27 17:27:03 <ikke> bisect script: https://tpaste.us/WE7B :-)
2021-07-27 17:31:14 <rzl> Good evening! What is the policy regarding out-of-tree kernel modules?
2021-07-27 17:32:11 <mps> rzl: separate pkgs, there are some in repo
2021-07-27 17:33:45 <rzl> mps: Thanks. I only found community/rtl8821ce-lts but I guess the idea is the same
2021-07-27 17:34:01 <mps> zfs, jool etc
2021-07-27 17:34:15 <ikke> rzl: We prefer not too many of those, though
2021-07-27 17:34:32 <ikke> it adds to the maintenance burden of upgrading kernels
2021-07-27 17:34:51 <mps> yes, some rotting in MRs for long time
2021-07-27 17:36:18 <mps> I started to work on dkms some time ago but didn't finished it yet
2021-07-27 17:36:31 <ikke> interesting
2021-07-27 17:37:01 <mps> main problem is where and how to add hooks
2021-07-27 17:37:26 <ikke> apk triggers I suppose
2021-07-27 17:37:32 <mps> dkms pkg is really simple
2021-07-27 17:38:13 <mps> yes, triggers
2021-07-27 17:38:53 <ikke> triggers="$pkgname.trigger=/usr/share/kernel/*"
2021-07-27 17:38:59 <ikke> that's what mkinitfs uses
2021-07-27 17:39:00 <mps> now I wait for perl merge and expect that dependant modules will took some of my time
2021-07-27 17:40:03 <mps> I'm not sure triggers for mkinitfs are good starting point
2021-07-27 17:40:59 <mps> but will look deeply in a few weeks
2021-07-27 17:42:17 <rzl> ikke: due to package rebuilds? Actually, I was wondering about that. Do you guys manually decide which packages to rebuild when dependencies change?
2021-07-27 17:42:35 <ikke> rzl: we have tools to help
2021-07-27 17:42:49 <ikke> And regarding the kernel, ncopa has scripts
2021-07-27 17:44:09 <mps> yesterday I made one out-of-tree module apk but didn't push, don't want to add more of those we already have
2021-07-27 17:44:35 <rzl> mps: DKMS would be nice, yes. Either rebuilding modules at install time when the kernel changes or at boot time, which IIRC is what openSUSE and the like do
2021-07-27 17:45:31 <mps> oh, at boot time? sounds risky. zfs for example
2021-07-27 17:45:31 <ericonr> fedora launches a build in the background, either through systemd or just shell backgrounding :D
2021-07-27 17:46:05 <mps> imo, it is better to trigger build at install/upgrade time
2021-07-27 17:46:22 <rzl> ikke: have you guys considered using something like Open Build System?
2021-07-27 17:46:55 <ikke> Not specifically
2021-07-27 17:46:57 <rzl> It supports PKGBUILDs but I've only used it for RPMs so I don't know what's the state of it
2021-07-27 18:21:57 <ikke> This is the commit that broke darktable: https://github.com/darktable-org/darktable/commit/0ecb5005
2021-07-27 18:25:19 <Hello71> i wonder what #pragma omp declare simd aligned(in,out) even does
2021-07-27 18:26:57 <Hello71> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66676 says "nothing"
2021-07-27 18:45:26 <andypost[m]> why ppc builder missing?
2021-07-27 18:46:08 <ikke> very good question
2021-07-27 18:46:36 <ikke> containers are stopped for some reason
2021-07-27 18:53:18 <ikke> the people in #darktable (libera) argue that we should compile it with -O3
2021-07-27 19:14:21 <Hello71> lol
2021-07-27 19:14:55 <Hello71> i mean, to be fair it kind of makes sense considering they have lots of vectorizable loops
2021-07-27 19:14:59 <ikke> yes
2021-07-27 19:15:23 <ikke> They mention -O3 -ffast-math
2021-07-27 19:15:23 <Hello71> but it still shouldn't crash
2021-07-27 19:15:34 <ikke> I tried it on archlinux, and it does not crash with -Os
2021-07-27 19:16:52 <Hello71> if you can reproduce it now in gdb, can you check disasm and info reg?
2021-07-27 19:17:07 <Hello71> also p $_siginfo is good to have
2021-07-27 19:17:51 <ikke> Ok, let me try
2021-07-27 19:18:35 <ikke> btw, they also mention that commit is just janitary
2021-07-27 19:21:04 <Hello71> what?
2021-07-27 19:21:54 <ikke> janitory*
2021-07-27 19:22:41 <ikke> "nope. Here it works and the commit in question is simply janitorial"
2021-07-27 19:24:50 <ikke> Undefined command "disasm". Try "help"
2021-07-27 19:25:09 <ikke> I guess disassemble?
2021-07-27 19:25:12 <Hello71> disas, short for disassemble
2021-07-27 19:25:14 <Hello71> yeah
2021-07-27 19:26:52 <ikke> https://tpaste.us/gB6l
2021-07-27 19:29:01 <Hello71> 0x7fffffff7818 is definitely mapped, right?
2021-07-27 19:29:31 <Hello71> yeah, i think it's stack
2021-07-27 19:29:55 <Hello71> is bt same as before?
2021-07-27 19:30:10 <ikke> let me check
2021-07-27 19:30:51 <ikke> Yeah, it's the stack
2021-07-27 19:31:14 <ikke> https://tpaste.us/eVjb
2021-07-27 19:31:54 <ikke> backtrace seems different
2021-07-27 19:32:41 <Hello71> the immediate problem is that 0x7fffffff7818 is not aligned
2021-07-27 19:32:42 <ikke> Oh no
2021-07-27 19:33:21 <ikke> the bt is similar
2021-07-27 19:34:03 <ikke> Only I don't see the copy_pixel frame
2021-07-27 19:34:21 <Hello71> it might be hidden depending on compile flags, see e.g. https://stackoverflow.com/questions/31089502/aligned-and-unaligned-memory-access-with-avx-avx2-intrinsics
2021-07-27 19:34:53 <Hello71> er, the alignment issue
2021-07-27 19:36:05 <Hello71> this is on commit 0ecb5005?
2021-07-27 19:36:27 <ikke> yes
2021-07-27 19:36:43 <Hello71> hm. bt full?
2021-07-27 19:37:28 <ikke> https://tpaste.us/kxk9
2021-07-27 19:38:40 <Hello71> found it
2021-07-27 19:38:54 <ikke> ah?
2021-07-27 19:39:27 <Hello71> https://github.com/darktable-org/darktable/blob/0ecb5005c14caa9febbb725ef8b1cfa3bc017349/src/iop/channelmixerrgb.c#L3540 missing DT_ALIGNED_PIXEL
2021-07-27 19:39:31 <Hello71> fixed in https://github.com/darktable-org/darktable/commit/a151f73d65bd4ed1a8800cb6a70ce38e60ee386c
2021-07-27 19:40:24 <Hello71> idfk why they didn't do this dt_aligned_pixel_t to begin with
2021-07-27 19:41:09 <ikke> Ok, let me try to apply that
2021-07-27 19:41:48 <Hello71> i don't think it'll apply cleanly but you can try
2021-07-27 19:42:03 <Hello71> the direct fix is to just jam a DT_ALIGNED_PIXEL in there
2021-07-27 19:42:23 <ikke> I try to apply it onto 3.6.0
2021-07-27 19:43:30 <Hello71> i mean if it applies cleanly it'll fix it
2021-07-27 19:43:43 <Hello71> but it looks like it touches a lot
2021-07-27 19:43:47 <ikke> One conflict
2021-07-27 19:44:17 <Hello71> theoretically you should probably merge the whole PR, not just that one commit
2021-07-27 19:45:07 <Hello71> i guess the problem is they are graphics programmers, not c programmers
2021-07-27 19:45:10 <ikke> :D
2021-07-27 19:46:58 <Hello71> i ran into a similar issue before: https://github.com/rspamd/rspamd/issues/2222#issuecomment-390254669
2021-07-27 19:48:09 <Hello71> but i think that one was genuinely hidden by limited C type system, whereas this one is just because they're bad at C (although, to be fair, probably good at graphics algorithms)
2021-07-27 19:58:21 <ikke> seems like those commits were directly pushed to master, btw
2021-07-27 19:59:00 <ikke> Let me just try to checkout master
2021-07-27 20:08:48 <Hello71> yes
2021-07-27 20:09:04 <ikke> master works
2021-07-27 20:09:08 <Hello71> "master (#9617)"
2021-07-27 20:10:02 <Hello71> well, "directly" through PR
2021-07-27 20:11:13 <ikke> it's an issue, I don't see a merge for that
2021-07-27 20:14:51 <Hello71> huh? https://github.com/darktable-org/darktable/pull/9617
2021-07-27 20:15:26 <Hello71> afaik github only lists branches, tags, and PRs there
2021-07-27 20:15:31 <ikke> hmm
2021-07-27 20:15:39 <ikke> I look at it in a local repo
2021-07-27 20:16:43 <ikke> https://i.imgur.com/t2JVQsx.png
2021-07-27 20:16:59 <ikke> From there, it looks like these commits directly were pushed to master
2021-07-27 20:17:03 <Hello71> they use ff merge i guess
2021-07-27 20:17:07 <ikke> Right
2021-07-27 20:17:11 <ikke> That would make sense
2021-07-27 20:18:03 <Hello71> https://i.imgur.com/QoMER54.png
2021-07-27 20:18:35 <ikke> ahuh
2021-07-27 20:18:38 <Hello71> i guess you can call it "github lock-in"
2021-07-27 20:19:00 <ikke> Well, we do it similar with aports ;-)
2021-07-27 20:33:22 <Hello71> i think some people are grumpy about that
2021-07-28 00:05:16 <Hello71> Ariadne, ncopa: is there a chance we will actually do #10038? if not now or in near future, imo we should close it
2021-07-28 00:05:47 <Ariadne> yes i can work on it this week
2021-07-28 00:08:41 <Hello71> ok. i think it is not urgent, but i am trying to reduce the number of old issues which will clearly not be fixed, cannot be fixed, or are already fixed
2021-07-28 00:09:25 <Hello71> what do you think about what i wrote in the issue?
2021-07-28 00:27:59 <Ariadne> i think the cross compilers are mainly used for end user apps, and you can build up the sysroot with apk
2021-07-28 01:12:09 <Hello71> is there a benefit to using bootstrap.sh instead of mcm?
2021-07-28 01:14:02 <dalias> isn't bootstrap.sh more than the cross toolchain?
2021-07-28 01:34:42 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/bootstrap.sh
2021-07-28 01:35:24 <Hello71> looks to me like it's basically crossdev && export ANNOYINGVARS && abuild -r $crap
2021-07-28 02:38:33 <Ariadne> Hello71: yes.  mcm does not give you alpine’s toolchain
2021-07-28 02:38:50 <Ariadne> whether you actually want that is of course subjective
2021-07-28 02:39:56 <Ariadne> i don’t think mcm also supports gcc 10
2021-07-28 02:42:36 <Ariadne> bootstrap.sh however does give you a toolchain built from the same exact sources that the native toolchain uses
2021-07-28 02:42:48 <Ariadne> again… depends on what you want
2021-07-28 02:43:18 <Ariadne> but alpine gcc 10 snapshots are historically more stable than real gcc 10
2021-07-28 02:43:34 <Ariadne> because i watch for bug fixes
2021-07-28 03:07:35 <andypost[m]> Any pointer why I can get "undefined reference to `getcontext'" trying to build php 8.1 only on riscv64? (qemu) 
2021-07-28 03:09:28 <andypost[m]> Using "export LDFLAGS="$LDFLAGS -lucontext"" is not enough
2021-07-28 03:10:11 <andypost[m]> Also swapcontext() is missing (only on risc) somehow https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22236#note_169878
2021-07-28 03:11:34 <andypost[m]> Woulkd be great to have CI docker image)
2021-07-28 04:28:14 <Ariadne> the symbols are defined
2021-07-28 04:28:22 <Ariadne> other programs depending on libucontext are compiling fine
2021-07-28 04:28:44 <Ariadne> it would be helpful to have the linker command output
2021-07-28 04:29:56 <ikke> andypost[m]: alpinelinux/alpine-gitlab-ci
2021-07-28 04:30:04 <ikke> it's available for risc64
2021-07-28 04:30:16 <ikke> I just need to enable it for aports
2021-07-28 04:31:49 <Ariadne> anyway, you'll be glad to know that riscv64 is working fine on bare metal
2021-07-28 04:32:05 <Ariadne> i just booted up on my sifive board
2021-07-28 04:32:11 <ikke> oh, cool
2021-07-28 04:32:31 <ikke> what do you use for bootloader?
2021-07-28 04:33:38 <Ariadne> i'm using the u-boot tree from sifive
2021-07-28 04:34:00 <Ariadne> with opensbi
2021-07-28 04:34:21 <Ariadne> well, you kinda have to use opensbi :p
2021-07-28 04:35:08 <ikke> That's like a bios?
2021-07-28 04:35:20 <ikke> https://github.com/riscv/opensbi
2021-07-28 04:35:29 <Ariadne> opensbi is kinda like arm-trusted-firmware
2021-07-28 04:35:36 <Ariadne> it chainloads into u-boot
2021-07-28 04:35:48 <Ariadne> but u-boot still does not support the SATA on unleashed
2021-07-28 04:35:54 <Ariadne> so, i am running off SD card :(
2021-07-28 04:37:15 <Ariadne> anyway going to verify libucontext is sane on riscv64
2021-07-28 04:37:20 <Ariadne> it should be
2021-07-28 04:37:28 <Ariadne> because it kinda has to be
2021-07-28 04:37:32 <Ariadne> in order to pass `make check`
2021-07-28 04:37:34 <Ariadne> but admittedly,
2021-07-28 04:37:42 <Ariadne> we don't have tests enabled on the riscv64 builder yet
2021-07-28 04:38:17 <Ariadne> yeah
2021-07-28 04:38:34 <Ariadne> getcontext/makecontext/setcontext/swapcontext are present in the riscv64 `libucontext`
2021-07-28 04:38:38 <Ariadne> as expected
2021-07-28 04:39:34 <Ariadne> ikke: anyway, the sifive unleashed is a garbage board
2021-07-28 04:39:40 <Ariadne> i wouldn't recommend buying it
2021-07-28 04:39:44 <Ariadne> unmatched may be better
2021-07-28 04:39:52 <ikke> I didn't have any plans
2021-07-28 04:41:28 <Ariadne> i think that BeagleV is a decent board (but it is raspi class)
2021-07-28 04:44:24 <Ariadne> and not publicly available yet
2021-07-28 04:45:37 <Ariadne> the starfive core however
2021-07-28 04:45:40 <Ariadne> is a lot faster
2021-07-28 04:45:49 <Ariadne> than the sifive ones
2021-07-28 04:46:11 <Ariadne> well the 7110 will be
2021-07-28 04:48:57 <ikke> our ppc64le vms are in a read-only state 
2021-07-28 04:49:15 <Ariadne> https://starfivetech.com/site/cpu-tianshu
2021-07-28 04:49:20 <Ariadne> 3.5ghz :)
2021-07-28 04:50:46 <Ariadne> and the dmips/mhz is very similar to cortex-a78
2021-07-28 04:51:20 <Ariadne> 11:48 PM <@ikke> our ppc64le vms are in a read-only state
2021-07-28 04:51:40 <Ariadne> a great advertisement for IBM Cloud
2021-07-28 04:51:52 <Ariadne> run your workloads with us, the filesystems will go read only randomly
2021-07-28 04:55:13 <ikke> I already noticed all containers were stopped
2021-07-28 04:57:03 <Ariadne> well yes
2021-07-28 04:57:11 <Ariadne> no reason to be running if the filesystem has gone to lunch
2021-07-28 04:57:20 <Ariadne> maybe the filesystem will be back someday
2021-07-28 04:57:56 <Ariadne> i remember when softlayer stood for uptime, now as IBM cloud, it seems to stand for downtime instead
2021-07-28 04:58:58 <Ariadne> i bet you they are using remote storage and there was a lag spike
2021-07-28 04:59:14 <Ariadne> and the kernel remounted r/o due to excessive iowait
2021-07-28 04:59:14 <alpine-meetbot> No such subreddit.
2021-07-28 04:59:21 <Ariadne> wow ok alpine-meetbot
2021-07-28 05:15:00 <andypost[m]> ikke: Ariadne: thank you set to build using docker image - it takes ~2 hrs
2021-07-28 05:15:18 <Ariadne> multiply by 2.5
2021-07-28 05:15:23 <Ariadne> for emulation overhead
2021-07-28 05:15:41 <Ariadne> or do you mean, it took you 2 hrs to build
2021-07-28 05:15:45 <Ariadne> in emulation
2021-07-28 06:32:45 <Ariadne> ikke: how parallel is the riscv64 runner ?
2021-07-28 06:33:30 <ikke> each job is a separate container
2021-07-28 06:33:40 <ikke> you can define how many may run at the same time
2021-07-28 06:33:58 <ikke> If you mean something else, please clarify :)
2021-07-28 08:14:30 <ncopa> good morning
2021-07-28 08:18:29 <ikke> ncopa: ppc64le is unhealthy
2021-07-28 08:18:34 <ikke> sorry, good morning
2021-07-28 08:20:44 <wener> 😄 still good
2021-07-28 08:20:47 <ncopa> ok. what can we do? reboot it?
2021-07-28 08:21:08 <ncopa> can we ask IBM for help?
2021-07-28 08:21:35 <ikke> we can probably try to reboot
2021-07-28 08:21:48 <ncopa> ikke: should I do that?
2021-07-28 08:22:03 <ikke> I have no time to look at it atm, but I can do it later
2021-07-28 08:22:16 <ncopa> i can try reboot them all
2021-07-28 10:29:25 <Habbie> my ibm ppc64le VM broke recently too
2021-07-28 10:30:29 <ikke> Seems like the reboot fixed it
2021-07-28 10:30:39 <ikke> /dev/sdr2 on / type ext4 (rw,relatime,errors=remount-ro,stripe=8)
2021-07-28 10:52:29 <Thermi> ikke, could you please continue the review of !23415?
2021-07-28 10:52:58 <ikke> At the end of the week I have more time
2021-07-28 10:53:12 <Thermi> I suspect unless you somehow "release" the MR, other devs won't pick it up. I see, ty.
2021-07-28 10:53:33 <ikke> I don't own it atm
2021-07-28 10:54:09 <ikke> It's just a large MR, so it takes a larger investment
2021-07-28 11:51:53 <ncopa> Thermi: i wonder why we ship this as an apk package? wouldnt it make more sense to deploy webapps via docker or similar?
2021-07-28 11:54:58 <Thermi> ncopa, employer wants to run it on alpine without docker
2021-07-28 11:55:11 <ncopa> ok
2021-07-28 11:55:36 <Thermi> Also, if people want to deploy it in an alpine based container, it'd make sense to make sure all problems that could occur are already taken care of
2021-07-28 11:55:53 <Thermi> In the venture to getting this all worked, we found a couple of bugs that required some patching
2021-07-28 11:56:05 <Thermi> Also stuff like too many large objects on the stack
2021-07-28 11:56:16 <Thermi> So it wasn't quite as trivial as expected
2021-07-28 11:58:17 <ikke> ncopa: I'm just wondering about the duplicated extract function
2021-07-28 12:00:46 <mps> ncopa: how goes perl upgrade?
2021-07-28 12:01:41 <ikke> ncopa: it's kind of difficult to extend on that without copying everything
2021-07-28 12:04:52 <ncopa> perl upgrade goes pretty ok. im working on testing now
2021-07-28 12:05:07 <ncopa> got suck on perl-dbix-class-helpers which has a failing test
2021-07-28 12:05:29 <ncopa> apparmor testsuite fails also, and im not sure if its new perl or something else
2021-07-28 12:07:39 <mps> ok, will look if I can help on some pkgs
2021-07-28 12:08:37 <ncopa> https://tpaste.us/RE45
2021-07-28 12:09:29 <mps> for perl-dbix-class, looks like some of makedeps must be rebuilt with perl 5.34.0
2021-07-28 12:11:18 <ncopa> quite possible
2021-07-28 12:12:04 <mps> above tpaste is from dbd-sqlite build?
2021-07-28 12:26:29 <mps> ncopa: iiuc your builds for main and community passed?
2021-07-28 12:30:18 <mps> in my test apparmor passed
2021-07-28 13:11:33 <ncopa> mps: yes they passed
2021-07-28 14:05:50 <mps> aha, good
2021-07-28 14:06:34 <mps> (now reading today kernel release changes)
2021-07-28 14:07:50 <mps> anyone habe anything needed for new linux-edge to add/change?
2021-07-28 14:08:00 <mps> s/habe/have/
2021-07-28 14:08:00 <alpine-meetbot> mps meant to say: anyone have anything needed for new linux-edge to add/change?
2021-07-28 14:12:39 <mallory> What do I need to do for CI to run on my aports fork in GitLab? Is it possible or do I need to submit a MR to run CI?
2021-07-28 14:15:04 <mps> mallory: you need to create MR, I think
2021-07-28 14:16:19 <mallory> ok
2021-07-28 14:26:03 <mallory> yeah it just compiles fine on Alpine's CI, thanks
2021-07-28 14:41:35 <mallory> oops, ^ wrong chat
2021-07-28 14:50:06 <mps> jirutka: if you read irclog: I don't like amove in packages I maintain
2021-07-28 15:17:08 <ncopa> seems like testing/perl-conf-libconfig is broken and it does not seem to be related perl 5.34
2021-07-28 15:22:34 <ncopa> yup, it broke with the libconfig-1.7.3 update 831108208be8b9b447a320386ef31d17d947e660
2021-07-28 15:22:39 <mps> right
2021-07-28 15:22:56 <mps> it fails also on system with perl 5.32.1
2021-07-28 15:41:38 <ncopa> I reported it upstream https://github.com/cnangel/Conf-Libconfig/issues/3
2021-07-28 15:45:04 <ncopa> sweet! perl 5.34 builds are finally done
2021-07-28 15:45:10 <ncopa> except apparmor
2021-07-28 15:45:25 <ncopa> i guess I'll skip apparmor rebuild for now and just push it
2021-07-28 15:45:40 <mps> \o/
2021-07-28 15:46:21 <ncopa> pushed...
2021-07-28 15:47:16 <mps> hmm, did you pushed perl first
2021-07-28 15:51:39 <mps> ah, yes, I see it on builders
2021-07-28 16:54:03 <mallory> If I submit a package to testing, do I need to specify a maintainer? If so, who can be a maintainer, and is there a way to search for someone willing to maintain a package? Couldn't find info in the wiki
2021-07-28 16:56:38 <mps> mallory: fill bug/issue request if you don't want to maintain pkg
2021-07-28 16:56:44 <Hello71> diy
2021-07-28 16:57:21 <mallory> so a maintainer doesn't need to be part of the Alpine team or something?
2021-07-28 16:57:47 <mps> right
2021-07-28 16:58:19 <mps> though maintainer have to seriously maintain pkg
2021-07-28 16:59:24 <mallory> I suppose a package will only be merged into testing if there is a maintainer?
2021-07-28 16:59:50 <mallory> I want to contribute a package but can probably not make the effort to guarantee long-term maintenance of it by myself
2021-07-28 17:02:20 <mps> if the package is worth to have in alpine maybe someone will take it
2021-07-28 17:55:22 <tiotags> does anybody know if openrc has a way to have a unprivileged service use pidfiles in a safe manner
2021-07-28 17:56:44 <tiotags> can it reowner pidfiles after the service completes initialization, or move the pid file one time, or something
2021-07-28 17:57:37 <ikke> pidfiles should be root-owned and not writable
2021-07-28 17:57:52 <tiotags> I know
2021-07-28 17:58:03 <ikke> So what issue are you trying to solve, then?
2021-07-28 17:58:25 <tiotags> but I can't write a root file with a unprivilileged process
2021-07-28 17:59:16 <ikke> then specify 'pidfile', and openrc will create it
2021-07-28 17:59:27 <tiotags> I'm trying to keep a service completly unprivileged from the start
2021-07-28 18:00:55 <tiotags> when I tried that /etc/init.d/service start kept foreground status and started writing to console
2021-07-28 18:01:49 <tiotags> and the pidfile option doesn't allow tracking pid across forks
2021-07-28 18:02:56 <ikke> command_background=true
2021-07-28 18:03:10 <ikke> But that assumes the process itself does not fork
2021-07-28 18:03:24 <ikke> "Finally, if your daemon always forks into the background but fails to create a PID file, then your only option is to use"
2021-07-28 18:03:38 <ikke> https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#dont-write-your-own-startstop-functions
2021-07-28 18:03:51 <ikke> afaik, openrc has no option for what you want
2021-07-28 18:04:22 <ikke> but you can ask #openrc on libera
2021-07-28 18:06:09 <skarnet> supervise your process (openrc can do that) and you won't need a pidfile
2021-07-28 18:06:27 <ikke> But then you need to prevent your service from forking as well
2021-07-28 18:06:36 <skarnet> indeed
2021-07-28 18:06:42 <tiotags> I need forking
2021-07-28 18:07:30 <skarnet> you don't
2021-07-28 18:07:46 <tiotags> openrc/supervise-daemon ?
2021-07-28 18:07:49 <skarnet> yes
2021-07-28 18:08:23 <tiotags> this is basically systemd for openrc ?
2021-07-28 18:08:45 <ikke> It just spawns a supervisor process for your service
2021-07-28 18:08:46 <skarnet> systemd didn't invent supervision
2021-07-28 18:10:34 <ericonr> and arguably systemd does the best support for forking daemons, thanks to cgroups 
2021-07-28 18:10:42 <ericonr> (not that it isn't an ugly hack)
2021-07-28 18:13:34 <tiotags> now I realize, I can't really gracefully restart if I use command_background=true
2021-07-28 18:14:39 <ikke> skarnet: what would not be an ugly hack and still allows you to reliably track a process + forks?
2021-07-28 18:16:49 <Ariadne> cgroups is one way
2021-07-28 18:16:49 <skarnet> ikke: patch the daemon so that it doesn't enforce a fork on you, supervision has been there since 1998
2021-07-28 18:17:10 <tiotags> I wanted to make a helper program that waits till the program writes a userspace pidfile and then copies that number to a root owned file, does that make sense ?
2021-07-28 18:17:12 <skarnet> if a daemon autoforks and doesn't have an option not to, >> unmaintained
2021-07-28 18:17:13 <Ariadne> also what skarnet said :p
2021-07-28 18:17:33 <ikke> Ariadne: skarnet called what systemd did with cgroups an ugly hack
2021-07-28 18:17:39 <ericonr> I did :)
2021-07-28 18:17:43 <ikke> oh, sorry :)
2021-07-28 18:17:43 <Ariadne> i mean, it is
2021-07-28 18:17:46 <ikke> same color 
2021-07-28 18:17:52 <ikke> and same nick length
2021-07-28 18:17:54 <ikke> :P
2021-07-28 18:17:59 <Ariadne> wow
2021-07-28 18:18:06 <ericonr> ikke: weechat? gotta change your color hash ;)
2021-07-28 18:18:13 <ikke> yes
2021-07-28 18:18:30 <skarnet> it's fine, ericonr says smart things most of the time, you can keep colliding us
2021-07-28 18:18:34 <Ariadne> we love IBM here
2021-07-28 18:18:58 <tiotags> guys ?
2021-07-28 18:19:05 <skarnet> tiotags: no
2021-07-28 18:19:09 <ikke> not the galls?
2021-07-28 18:19:25 <ericonr> tiotags: you really want supervision, unless you are using a proprietary daemon
2021-07-28 18:19:41 <ericonr> and then, binary patching could still be an option :p
2021-07-28 18:19:45 <Ariadne> best company ever
2021-07-28 18:19:51 <ericonr> skarnet: :D
2021-07-28 18:19:54 <ikke> Ariadne: who compromised you?
2021-07-28 18:20:15 <tiotags> I would prefer to have the option to not use supervision
2021-07-28 18:20:15 <skarnet> tiotags: you are basically making your life super complex and adding unreliable hacks to work around a defect that should be super easy to patch
2021-07-28 18:21:01 <skarnet> don't use it, use start-stop-daemon as usual, but *still* don't background your daemon
2021-07-28 18:21:11 <skarnet> ssd will write the pidfile for you and you'll be fine
2021-07-28 18:21:23 <tiotags> what's super easy to patch ?
2021-07-28 18:21:32 <skarnet> autoforking
2021-07-28 18:21:48 <tiotags> skarnet I already said, I can't use ssd make-pidfile because I want to handle graceful restarts
2021-07-28 18:22:00 <Ariadne> great news!
2021-07-28 18:22:06 <skarnet> yeah so you basically want all the benefits of supervision without supervision
2021-07-28 18:22:21 <ericonr> usually just a matter of removing two fork() calls; or one daemon() 
2021-07-28 18:23:43 <Sheila> weird how there's some semi-standard mechanism for soft-restarting services…
2021-07-28 18:23:53 <Sheila> (`kill -HUP`)
2021-07-28 18:24:01 <skarnet> that's "reload config", not restart
2021-07-28 18:24:36 <ericonr> there must be *some* daemon that implements that as re-exec() into self
2021-07-28 18:24:44 <tiotags> what's wrong with my idea ? it basically handles older services perfectly
2021-07-28 18:25:09 <skarnet> "perfectly" is a strong word
2021-07-28 18:25:37 <tiotags> if you reexec into self what if it crashes ?
2021-07-28 18:25:49 <skarnet> then the supervisor restarts it
2021-07-28 18:25:51 <skarnet> oh wait
2021-07-28 18:25:51 <tiotags> or exit with a missing config file
2021-07-28 18:26:08 <skarnet> then the supervisor restarts it
2021-07-28 18:26:09 <skarnet> oh wait
2021-07-28 18:26:17 <ikke> ithen you're one crash away from downtime
2021-07-28 18:27:35 <tiotags> supervision is the future
2021-07-28 18:27:47 <skarnet> no, it's the present
2021-07-28 18:28:55 <ikke> 
ACTION wonders why people are still opposed to supervision

2021-07-28 18:29:16 <tiotags> skarnet you have another root program that you need to audit and ensure it doesn't do weird things
2021-07-28 18:29:58 <tiotags> I'm not against supervision, I just want the option to use it, not to be forced to use it
2021-07-28 18:31:01 <skarnet> I think it's also a restriction of your freedom that you have to use a kernel
2021-07-28 18:31:19 <skarnet> I want the option to use my Unix systems without a kernel
2021-07-28 18:31:54 <skarnet> re: another root program you need to audit, that's absolutely true, but I can't answer that without self-plugging
2021-07-28 18:32:22 <skarnet> which I've managed to avoid doing so far and I deserve a medal for it
2021-07-28 18:33:05 <mps> I use supervisor from 90's
2021-07-28 18:33:30 <mps> where it is appropriate, ofc
2021-07-28 18:33:42 <Ariadne> what do you know, IBM was able to find a physical machine for us after all
2021-07-28 18:33:53 <ikke> yes
2021-07-28 18:34:07 <ikke> power8
2021-07-28 18:35:10 <tiotags> skarnet is it bad to self plug ?
2021-07-28 18:35:34 <skarnet> not if you can walk the walk as well as you talk the talk
2021-07-28 18:36:02 <ikke> And for most people here, the self-plug is implied
2021-07-28 18:36:10 <ikke> :P
2021-07-28 18:36:26 <skarnet> which means I've already done it too often :P
2021-07-28 18:37:08 <Ariadne> i think alpine is fairly good at walking what we talk
2021-07-28 19:11:37 <Ariadne> perl-html-tidy5 has the builders red
2021-07-28 19:11:41 <Ariadne> can somebody look into it?
2021-07-28 19:13:24 <Sheila> looks like testsuite failure
2021-07-28 19:14:56 <Sheila> ah. it relies on behavior from the underlying library that has since changed
2021-07-28 19:15:53 <Sheila> last updated back in 2019, so I don't expect it to get fixed upstream.
2021-07-28 19:19:28 <Ariadne> i just disabled tests
2021-07-28 19:19:29 <Ariadne> whatevs
2021-07-28 19:19:52 <Ariadne> all i can do right now :D
2021-07-28 19:20:56 <Sheila> it doesn't really make sense to test output of upstream components anyway.
2021-07-28 19:27:56 <mps> for some reason also perl-io-tty fails on check()
2021-07-28 19:28:22 <mps> on aarch64 and even with perl 5.32.1
2021-07-28 19:28:59 <mps> should we disable check temporary also for it?/
2021-07-28 19:30:58 <Ariadne> yes
2021-07-28 19:31:03 <Ariadne> i agree with that conclusion
2021-07-28 19:31:31 <Ariadne> this is a large rebuild, i'd rather get everything green again
2021-07-28 19:31:36 <Ariadne> we can debug perl-io-tty later
2021-07-28 19:31:45 <mps> ok
2021-07-28 19:37:08 <mps> on mips64 perl failed on one test 'ext/POSIX/t/iv_const ............................................. #   Failed test 'FE_TOWARDZERO is an integer''
2021-07-28 19:44:41 <dalias> huh
2021-07-28 19:45:12 <dalias> is alpine mips soft-float? otherwise it's clearly: #define FE_TOWARDZERO 1
2021-07-28 19:45:18 <ikke> It is
2021-07-28 19:45:22 <dalias> ah
2021-07-28 19:45:28 <dalias> eew
2021-07-28 19:45:40 <ikke> hardfloat is broken on the HW we have
2021-07-28 19:45:42 <dalias> but yeah that test should be expected to fail on softfloat archs
2021-07-28 19:45:56 <dalias> doesn't kernel always support fpu emulation?
2021-07-28 19:46:02 <mps> ah, thanks for info
2021-07-28 19:47:36 <mps> kernel config for mips64 have CONFIG_MIPS_FP_SUPPORT=y
2021-07-28 19:48:02 <mps> and CONFIG_MIPS_FP_SUPPORT=y, whatever it is
2021-07-28 19:48:15 <mps> I don't know much of mips
2021-07-28 19:50:25 <Ariadne> well
2021-07-28 19:50:27 <Ariadne> hardfloat
2021-07-28 19:50:30 <Ariadne> works on the builder
2021-07-28 19:50:45 <Ariadne> but octeon1/2 do not have a working FPU
2021-07-28 19:51:12 <Ariadne> octeon1 does not have a FPU at all, octeon2 has an FPU that does not implement certain instructions due to patents
2021-07-28 19:51:23 <Ariadne> octeon3 (the builder) has a fully working FPU
2021-07-28 19:51:57 <Ariadne> mps: CONFIG_MIPS_FP_SUPPORT is FPU emulation
2021-07-28 19:52:08 <mps> aha
2021-07-28 20:08:17 <ikke> Anyone happens to know how I can get clipboard sharing to work with kvm an an alpine linux guest using remote-viewer?
2021-07-28 20:11:00 <Hello71> spice-vdagent
2021-07-28 20:11:25 <ikke> I don't think we have that
2021-07-28 20:11:40 <Hello71> no
2021-07-28 20:12:08 <Hello71> if you only need it a little bit you can bodge it with virtio-serial
2021-07-28 20:12:19 <ikke> https://gitlab.freedesktop.org/spice/linux/vd_agent
2021-07-28 20:12:47 <Hello71> mmhmm
2021-07-28 20:13:39 <ikke> To enable the virtio serial port you need to pass the following params on
2021-07-28 20:13:42 <ikke> the qemu cmdline:
2021-07-28 21:47:29 <rzl> Hello! What's the policy regarding packages having -dbg in the repos?
2021-07-28 21:48:41 <mps> frowned by me
2021-07-28 21:49:39 <mps> but looks like there is no policy
2021-07-28 21:49:48 <mps> nowadays, I mean
2021-07-28 21:49:50 <rzl> Some packages have them but others don't. I am just wondering about what cuts it
2021-07-28 21:50:19 <rzl> Oh, okay. Not that I mind building locally
2021-07-28 21:50:46 <mps> yes, and is never decided what to do about it
2021-07-28 21:51:10 <rzl> Why are you against it?
2021-07-28 21:52:30 <mps> space on mirrors, longer build time, more load on CIs
2021-07-28 21:54:03 <mps> alpine moto was 'small, simple, ...' and fast as bonus
2021-07-28 21:54:16 <mps> *was*
2021-07-28 21:55:34 <rzl> Why does it put more load on CIs? Can't you run CI jobs without dbg? Though I understand if CI jobs compete with build jobs
2021-07-28 21:56:16 <mps> no, CI build everything
2021-07-28 21:56:57 <mps> though yes, CIs are on different hosts from the builders
2021-07-28 21:58:15 <mps> and worse, some builders are qemu guests
2021-07-28 22:04:29 <rzl> Yeah, I guess running stuff in QEMU makes it a lot worse
2021-07-28 22:06:03 <mps> and I'm not strongly against -dbg subpkgs but not sure how much of them we need
2021-07-28 22:15:47 <rzl> I was just wondering, since sometimes just installing -dbg and getting a decent bt when things go south is handy
2021-07-28 22:18:45 <mps> np
2021-07-28 22:26:15 <Hello71> imo all packages should have -dbg. if we don't have mirror space or build time we should ask for (hosting) donations
2021-07-28 22:27:04 <Hello71> only exception maybe for "minor" archs that we can't get enough build time donated
2021-07-28 22:27:45 <Hello71> i know we don't want to have "lesser" archs, but that's not a good reason to hold back everyone else
2021-07-28 22:29:22 <rzl> Actually, yeah, I don't see any mention of donations in the website. I wouldn't mind giving a few bucks for the distro I use every day...
2021-07-28 22:30:22 <rzl> Though I understand that handling money is a hassle and that some people are against it
2021-07-28 22:33:31 <mps> we don't need money, we need hardware 'leased'
2021-07-28 22:34:16 <Hello71> i wouldn't say we don't need money, but hardware would be good too
2021-07-28 22:34:38 <Hello71> hardware and power and fast internet connections
2021-07-28 22:34:50 <Hello71> are less controversial
2021-07-28 22:35:42 <rzl> All I can offer right now is my time :)
2021-07-28 22:37:44 <Hello71> maybe we should put a page saying more clearly we don't accept money now but are looking for more hosting
2021-07-28 22:38:07 <Hello71> i think even if we don't trust it for builders, we can use it for ci
2021-07-28 22:38:47 <Hello71> mps: actually why would dbg put stress on builders/ci
2021-07-28 22:39:02 <Hello71> it is only temporary disk usage
2021-07-28 22:40:57 <ericonr> Hello71: it increases RAM requirements for linking shit too
2021-07-28 22:41:10 <ericonr> so firefox / chromium get a bit wild
2021-07-28 22:41:14 <Hello71> ugh
2021-07-28 22:41:28 <ericonr> (not that anyone has RAM to launch chromium inside gdb anyway)
2021-07-28 22:41:51 <rzl> 3GB for libxul.so when building Thunderbird. I think it overflows something in apk because it borks when installing the debug file
2021-07-29 05:47:46 <mps> Hello71: as ericonr wrote, we had to disable -dbg for some pkgs because they can't be build when it is enabled
2021-07-29 05:52:22 <ikke> Hello71: It's not only diskspace on mirrors, but also on the builders
2021-07-29 05:52:42 <ikke> and getting more diskspace is not trivial
2021-07-29 05:53:46 <mps> also, I expect that anyone who know how to run gdb know how to build -dbg locally
2021-07-29 06:45:42 <clandmeter> Hello71: as ikke mentioned, its not as simple as asking for a single sponsor to donate a bit more disk space. it's the whole chain that needs it.
2021-07-29 06:46:49 <mps> clandmeter: good morning (and good morning to all)
2021-07-29 06:47:47 <clandmeter> and on some baremetals disk space is the thing that is limited to less than 2TB (which we are growing towards)
2021-07-29 06:48:40 <clandmeter> i bet if we do global gdb the mirrors would grow by more than 100%
2021-07-29 06:48:50 <mps> ncopa: great work on perl upgrade. You did a really good job to make it works with just few not big problems
2021-07-29 06:49:21 <clandmeter> mps: good morning to you too
2021-07-29 06:51:23 <mps> clandmeter: I've seen in git log someone with 'Bobby the Builder' pseudonym and first thinking was related to you :)
2021-07-29 06:51:58 <clandmeter> ok, why?
2021-07-29 06:52:15 <mps> your new house
2021-07-29 06:52:26 <clandmeter> :)
2021-07-29 06:52:47 <mps> hope you are well
2021-07-29 06:54:11 <clandmeter> yes im fine, need to drill a lot of holes, but this is probably not the right channel to discuss that (although its development after all) :)
2021-07-29 06:55:17 <mps> yes, development is development :D
2021-07-29 06:56:17 <mps> don't forget 'backdoor' (in case of emergency)
2021-07-29 06:56:49 <ncopa> good morning
2021-07-29 06:57:57 <ncopa> mps: thanks, and thanks to timlegge for the perl work
2021-07-29 06:59:13 <clandmeter> mps: did anything special change in the logic to detect perl rebuild?
2021-07-29 06:59:46 <mps> next thing about perl pkgs is that we don't need -doc subpkg for most of them. perl doc (perl pod) is included in base pkgs
2021-07-29 07:00:03 <ikke> Removing perl-dev from packages makedepends that not need it
2021-07-29 07:00:20 <mps> clandmeter: your script helped a lot to me and I think it helped to timlegge also
2021-07-29 07:01:54 <mps> and that all shows how 'tools' are not so good for making new aports. apkbuild-cpan I mean
2021-07-29 07:02:37 <mps> humans have to 'give' final words
2021-07-29 07:09:03 <mps> can we 'know' somehow statistic about pkgs used by users
2021-07-29 07:10:16 <mps> (I think network providers and TLA agencies know that)
2021-07-29 07:10:24 <danieli> only (potentially) via web server logs of the few mirrors alpine itself controls
2021-07-29 07:10:30 <danieli> and that's only for downloads, not actual usage
2021-07-29 07:10:57 <mps> danieli: yes, download can be indicator (or hint)
2021-07-29 07:11:21 <danieli> i'm not sure it's very useful data though, except to satisfy some curiosity
2021-07-29 07:11:55 <mps> I'm thinking about removal of pkgs not used by end users
2021-07-29 07:12:25 <danieli> right - problem is that there are a lot of mirrors alpine lacks control of
2021-07-29 07:13:56 <mps> maybe we could add something like 'popularity' package to alpine where people can voluntary (and anonymously) send data
2021-07-29 07:15:09 <ncopa> similar to debians popcon?
2021-07-29 07:15:29 <mps> yes, I think
2021-07-29 07:49:15 <mps> huh, https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.15-Disk-Seq-No
2021-07-29 07:49:55 <mps> microsoft and systemd 'teamed', what a crap (sorry for bad words)
2021-07-29 08:49:33 <Ariadne> the feature seems to be reasonable to me, who cares about its origin
2021-07-29 08:56:10 <mps> yes, feature is ok, but I fear of features added by 'these' entities
2021-07-29 09:00:07 <Sheila> automatic distrust is a bit excessive and, imo, inappropriate. look at the value of the concepts they're offering, instead.
2021-07-29 09:07:30 <mps> 'I don't trust Danans even when they gifts give' - Laokont,  (translation to english from the head)
2021-07-29 09:09:43 <mps> or, https://en.wikipedia.org/wiki/Timeo_Danaos_et_dona_ferentes
2021-07-29 09:09:44 <alpine-meetbot> [WIKIPEDIA] Timeo Danaos et dona ferentes | "Timeo Danaos et dona ferentes is a Latin phrase from Aeneid (II, 49), written by Virgil between 29 and 19 BC. It has been paraphrased in English as the proverb "Beware of Greeks bearing gifts". Its literal meaning is "I fear the Danaans [Greeks], even those bearing gifts" or "even when they bear gifts..."
2021-07-29 09:11:03 <mps> Sheila: I someone is notorious criminal you will trust him/her?
2021-07-29 09:12:29 <Sheila> If they've made restitution for their crimes, I don't see why it matters.
2021-07-29 09:13:00 <mps> (a lot of naive people live in this world, heh)
2021-07-29 09:13:07 <Sheila> this is not a conversation I am interested in pursuing, however, since I already know from past conversations there's no opening your mind.
2021-07-29 09:13:58 <mps> my 'mind' is not house/building with doors or windows to open :D
2021-07-29 09:14:21 <Sheila> 🙄
2021-07-29 09:15:33 <mps> there is old crypto community proverb 'in god we trust, everything else we check with pgp'
2021-07-29 09:17:21 <Sheila> unfortunately, pgp is trash. :)
2021-07-29 09:17:56 <Ariadne> i have a customer who uses Alpine ppc64le
2021-07-29 09:17:58 <mps> heh, what is not (rhetorical question only)
2021-07-29 09:18:01 <Ariadne> they are in an upgrade cycle
2021-07-29 09:18:08 <Ariadne> i think i'll steer them toward aarch64 instead
2021-07-29 09:18:10 <Ariadne> :p
2021-07-29 09:18:33 <mps> good for them if you succeed
2021-07-29 09:19:15 <Ariadne> yes, good for them, because ppc64le is increasingly not worth it
2021-07-29 09:19:55 <mps> Ariadne: btw, thanks for #12883 , I didn't thought of this
2021-07-29 09:20:02 <Ariadne> :)
2021-07-29 09:22:14 <Ariadne> i have a P8 machine and a pair of P9 machines, but i have already deprecated them due to concerns about the viability of Alpine ppc64le's production quality
2021-07-29 09:22:31 <Ariadne> i'll just sell them on ebay and get one of those ampere altra systems
2021-07-29 09:23:00 <mps> iirc BDFL proposed removal of ppc64le from alpine some time ago
2021-07-29 09:24:22 <Ariadne> there is no BDFL
2021-07-29 09:25:05 <Ariadne> :)
2021-07-29 09:25:12 <Ariadne> but yes, i am aware ncopa proposed it
2021-07-29 09:25:21 <Ariadne> that was because we did not have a builder
2021-07-29 09:25:22 <Ariadne> for like
2021-07-29 09:25:24 <Sheila> never really was, considering alpine was historically a group of people with intersecting goals working together.
2021-07-29 09:25:24 <Ariadne> a month
2021-07-29 09:25:30 <mps> oh, when it is 'decomissioned'
2021-07-29 09:25:50 <Ariadne> and then we threatened to drop the port
2021-07-29 09:25:55 <Ariadne> and IBM gave us these crappy VMs
2021-07-29 09:26:28 <Ariadne> err i mean greatest VMs ever made, best ever hosting, i wish i could emulate the "quality"  and "uptime" of IBM cloud
2021-07-29 09:27:27 <Ariadne> i mean, i hate to say it, but even integricloud is more reliable
2021-07-29 09:27:43 <Ariadne> and thats literally running out of a strip mall
2021-07-29 09:28:30 <Ariadne> anyway, i complained loudly, and they promise to give us a real machine again
2021-07-29 09:28:36 <Ariadne> i'll believe it when i see it, but hey
2021-07-29 09:28:41 <mps> I mean when the BDFL position is decomissioned
2021-07-29 09:28:53 <Ariadne> i mean, there never was a BDFL position
2021-07-29 09:29:17 <Ariadne> in the old days, ncopa was willing to delegate basically anything and everything to anyone who looked like they knew what they were doing
2021-07-29 09:29:19 <ikke> ncopa always worked on basis of concensus
2021-07-29 09:29:23 <Ariadne> that evolved into core team
2021-07-29 09:29:36 <Ariadne> which has now evolved into Council and TSC
2021-07-29 09:30:20 <mps> keyword is 'benevolent' in my understanding
2021-07-29 09:30:25 <Ariadne> and that's how its been since 2009 :P
2021-07-29 09:31:48 <Ariadne> when i got involved because there were some debian folks playing with alpine for various things
2021-07-29 09:32:01 <Ariadne> and i needed xen dom0 run from ram
2021-07-29 09:32:20 <Ariadne> and so i ported alpine to x86_64 and fixed uClibc NPTL to work correctly on x86_64
2021-07-29 09:33:18 <Ariadne> :P
2021-07-29 09:37:52 <mps> I see from history that you did a lot of good works on alpine
2021-07-29 09:50:17 <Ariadne> honestly, i am kind of an idiot and i have no idea why anyone takes anything i do seriously :p
2021-07-29 10:07:31 <mps> heh, I have same feelings about my work :)
2021-07-29 10:08:11 <mps> don't understand why anyone use software I packaged and/or fixed
2021-07-29 10:28:22 <mps> Ariadne: are you using linux-elm on your accer chromebook? if yes don't upgrade to latest linux-elm-5.13.6, keyboard doesn't work
2021-07-29 10:28:34 <Ariadne> mine are lenovos
2021-07-29 10:28:56 <Ariadne> but i've been using the M1 instead of the chromebook lately
2021-07-29 10:29:16 <Ariadne> marcan almost has something usable
2021-07-29 10:29:21 <mps> ah, are lenovos mediatek 
2021-07-29 10:29:40 <Ariadne> yes, elm-hana or whatever
2021-07-29 10:30:18 <mps> ok, anyway don't upgrade if you use linux-elm apk
2021-07-29 10:30:44 <mps> and also I'm tempted to buy M1
2021-07-29 10:31:30 <mps> with hope that someone will find replace for apple boot rom on it
2021-07-29 10:32:12 <mps> and marcan done very good job
2021-07-29 10:32:41 <mps> he helped me to boot alpine on M1
2021-07-29 10:35:55 <Ariadne> marcan is great
2021-07-29 10:37:04 <mps> yes
2021-07-29 11:23:07 <mps> how can I know which of APKINDEX /var/cache/apk/ files are outdated? want to untar just current ones
2021-07-29 11:23:29 <mps> in /var/cache/apk/, I mean
2021-07-29 11:31:39 <ikke> you can run apk cache clean to remove outdated packages
2021-07-29 11:32:29 <Ariadne> TIL
2021-07-29 11:34:49 <mps> ikke: 'ERROR: Package cache is not enabled.'
2021-07-29 11:35:41 <ikke> does /etc/apk/cache exist?
2021-07-29 11:35:50 <mps> and I mean '/var/cache/apk/APKINDEX.*gz' files, not apks
2021-07-29 11:35:59 <ikke> ohh
2021-07-29 11:37:10 <mps> hmm, rm -rf /var/cache/apk/APKINDEX.*gz' ; apk update
2021-07-29 11:37:59 <mps> but not good solution for things I'm trying to make
2021-07-29 11:51:50 <Hello71> regarding hosting, i know it is not a matter of disks++, and we are currently designed for vertical scaling, not horizontal. however, i also see we have some deep-pocketed relationships (e.g. microsoft), and there have been a number of offers to donate (unspecified amounts). when i look at arch for example, they have hundreds of mirrors, in part because they are a "popular"
2021-07-29 11:51:53 <Hello71> distro, and lots of people want to donate resources. alpine is increasing in popularity, and as we've discussed, that comes with some cost, like we shouldn't make too much gratuitously breaking changes, but also has some benefits. we should try to manage those costs, but we shouldn't ignore the benefits
2021-07-29 11:53:52 <ikke> Yes, but the current architecture sadly does not scale that way
2021-07-29 11:54:09 <ikke> We need ot make architectural changes first before we can scale horizontally
2021-07-29 12:55:57 <dalias> was the rm -rf * issue ever fixed?
2021-07-29 12:57:19 <ikke> Oh, with bootmisc, right?
2021-07-29 12:59:34 <ikke> I don't think so
2021-07-29 13:01:28 <dalias> yeah
2021-07-29 13:54:55 <Ariadne> mps: weird, apk should garbage collect old indices
2021-07-29 13:59:22 <Ariadne> however on my machine i note stale indices too
2021-07-29 14:04:01 <Ariadne> i opened a bug about it
2021-07-29 14:04:35 <ikke> dalias: Do you know what part of bootmisch caused it?
2021-07-29 14:06:57 <dalias> the part to clean /tmp
2021-07-29 14:07:01 <dalias> which is utterly pointless
2021-07-29 14:07:11 <dalias> normally /tmp is tmpfs, no?
2021-07-29 14:07:51 <Hello71> "that's a systemd invention, systemd bad therefore tmpfs bad" /s
2021-07-29 14:17:22 <dalias> in any case even if it weren't, rm'ing /tmp on boot is malicious behavior. like it you had a crash, /tmp might be a place you could recover stuff from
2021-07-29 14:21:26 <mps> Ariadne: thanks. didn't know apk should remove old ones
2021-07-29 14:22:05 <fcolista> @mps, re: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12883 what was failing on perl-io-tty?
2021-07-29 14:22:37 <mps> fcolista: test on aarch64
2021-07-29 14:22:42 <fcolista> yes 
2021-07-29 14:22:55 <fcolista> which part of the tests?
2021-07-29 14:23:02 <fcolista> which error?
2021-07-29 14:23:14 <mps> ah, you don't have aarch64 box to test?
2021-07-29 14:23:21 <fcolista> nope
2021-07-29 14:23:46 <mps> ok, will do try again and post log to tpaste
2021-07-29 14:24:08 <mps> or maybe better to issue report
2021-07-29 14:24:13 <ericonr> dalias: https://github.com/OpenRC/openrc/commit/1831e433a03fa0e6c5be6b6a87af4550688f1c49 they skip cleanup if tmpfs; but https://github.com/OpenRC/openrc/commit/06ae2e5593fe6b3dac1b2d18e244a08b54da14e1 shows you can at least disable it, I think?
2021-07-29 14:25:25 <fcolista> i need to fire a qemu aarch64 instance 
2021-07-29 14:25:58 <Hello71> funny thing is even systemd-tmpfiles supports cleaning directories by age
2021-07-29 14:26:37 <mps> fcolista: https://tpaste.us/Mzz5
2021-07-29 14:27:25 <mps> fcolista: no, this is bad one
2021-07-29 14:27:35 <mps> have to upgrade perl first
2021-07-29 14:29:41 <mps> fcolista: this one is with perl 5.34.0 https://tpaste.us/EMMO
2021-07-29 14:29:52 <Ariadne> mps: it did at one time
2021-07-29 14:31:21 <fcolista> mps, thx
2021-07-29 14:41:50 <fcolista> what's the quickest way to have qemu aarch64 working for alpine dev?
2021-07-29 14:42:57 <mps> fcolista: https://arvanta.net/alpine/install-aarch64-qemu/
2021-07-29 14:43:33 <mps> two methods, netboot and iso image
2021-07-29 14:43:56 <mps> if you find some errors there please report it to me
2021-07-29 14:44:16 <fcolista> mps, thanks, gr8!
2021-07-29 14:45:41 <Ariadne> mps has done a lot to advance the arm ports :)
2021-07-29 14:45:42 <mps> oh, I see it is somewhat outdated now. have to 'refresh' it with current released alpine
2021-07-29 14:46:45 <mps> Ariadne: thanks :)
2021-07-29 14:47:22 <mps> and I think I have to find time to write similar guide for running armv7 under qemu
2021-07-29 14:48:18 <fcolista> Welcome to Alpine Linux 3.12
2021-07-29 14:48:18 <fcolista> Kernel 5.4.72-0-virt on an aarch64 (/dev/ttyAMA0)
2021-07-29 14:48:18 <fcolista> localhost login: 
2021-07-29 14:48:23 <fcolista> :) thanks mps
2021-07-29 14:48:48 <ikke> I can't help but to read that as TTY Ask me Anything0 
2021-07-29 14:48:53 <mps> fcolista: you are welcome (niente) :)
2021-07-29 14:50:22 <mps> ikke: :D
2021-07-29 15:57:53 <Ariadne> fcolista: thx for the quick fix
2021-07-29 15:58:32 <fcolista> Ariadne, np. Thanks to mps for the good input re: aarch64
2021-07-29 16:18:32 <mps> fcolista: would you report this to upstream?
2021-07-29 16:36:38 <danieli> that's a really neat script mps 
2021-07-29 16:36:41 <danieli> the qemu aarch64 one
2021-07-29 16:52:29 <mps> danieli: thanks, but credit also goes to clandmeter
2021-07-29 16:53:09 <danieli> i saw :) clandmeter is awesome
2021-07-29 16:53:58 <mps> I will try to make same script for armv7 over weekend. actually I have it but have to 'polish' it somewhat and test again
2021-07-29 16:55:00 <mps> and for riscv64, basic is here https://dev.alpinelinux.org/~mps/riscv64/
2021-07-29 16:56:34 <PureTryOut1> riscv64 should be fully uploaded to normal repos now no?
2021-07-29 16:58:43 <mps> PureTryOut1: ikke will know better to answer
2021-07-29 17:02:32 <clandmeter> Yes it is
2021-07-29 17:02:40 <PureTryOut1> Great 👍️
2021-07-29 17:04:09 <clandmeter> You can forget my repo :)
2021-07-29 17:05:20 <ikke> what repo?
2021-07-29 17:11:15 <craftyguy> I'm having trouble finding libasan stuff in alpine, is it under some other name? 
2021-07-29 17:15:01 <craftyguy> oh... https://gitlab.alpinelinux.org/alpine/aports/-/issues/9643 :(
2021-07-29 17:15:43 <craftyguy> (btw I still cannot subscribe to issues like that in alpine's gitlab, earlier someone made me a 'reporter' in another repo and that 'fixed' it, but I'm not in aports...)
2021-07-29 17:19:01 <ikke> so strange
2021-07-29 17:26:55 <ikke> craftyguy: https://gitlab.com/gitlab-org/gitlab/-/issues/331511
2021-07-29 17:28:00 <ikke> so seems like bug
2021-07-29 17:30:55 <craftyguy> ah
2021-07-29 17:36:24 <PureTryOut1> Ah I had that bug on the KDE Gitlab instance as well, quite annoying
2021-07-29 18:07:14 <Hello71> Ariadne: re #10896, you mentioned before that you were going to write a libexecinfo using libunwind instead. how is that going?
2021-07-29 18:07:40 <Ariadne> soon(tm)
2021-07-29 18:13:20 <ericonr> ikke: did you manage to figure out the darktable thing?
2021-07-29 18:16:54 <Hello71> ericonr: misaligned movaps
2021-07-29 18:17:03 <Hello71> fixed in master (unmarked of course)
2021-07-29 18:19:53 <ericonr> https://github.com/darktable-org/darktable/pull/9617 ?
2021-07-29 18:21:33 <Hello71> yes, that one
2021-07-29 19:18:50 <mps> Ariadne: I found problem for keyboard not working in linux-elm, created patch and pushed it to builder. If you need it hope it will be ready soon on mirrors
2021-07-29 20:21:20 <Cogitri> https://twitter.com/matrixdotorg/status/1420748068090040332
2021-07-29 20:21:21 <Cogitri> Neat
2021-07-29 20:41:49 <andypost[m]> Somehow edge mips builder gone
2021-07-29 20:42:21 <ikke> it's still there
2021-07-29 20:42:47 <ikke> It's still building php7
2021-07-29 20:47:54 <andypost[m]> Thanks, I mean it's not displayed at build.a.o
2021-07-29 20:48:19 <ikke> yes, I gathered
2021-07-29 21:34:20 <doggone> Is there a reason why nf_conntrack_bridge.ko is only included for mips64?
2021-07-29 21:49:28 <Hello71> my guess is either it was copied from another mips config or nobody remembers
2021-07-29 21:49:46 <Hello71> ncopa: ^
2021-07-29 22:53:35 <adamplumb[m]> I ran into an issue with pianobar/libao where it couldn't play sound on my pinephone running pmOS (https://gitlab.alpinelinux.org/alpine/aports/-/issues/12885). The default alpine package builds libao with --enable-alsa-mmap, and I found that switching to --enable-pulse gets libao sound working on my phone. What do you guys think is the right way to handle this situation?  I'm not sure if both can be supported (having both enabled
2021-07-29 22:53:35 <adamplumb[m]> seems to not work) and i'm not sure if this is switchable in any way for people with pulse-backed systems
2021-07-29 22:54:02 <adamplumb[m]>  * I ran into an issue with pianobar/libao where it couldn't play sound on my pinephone running pmOS (https://gitlab.alpinelinux.org/alpine/aports/-/issues/12885). The default alpine package builds libao with --enable-alsa-mmap, and I found that switching to --enable-pulse gets libao sound working on my phone. What do you guys think is the right way to handle this situation?  I'm not sure if both can be supported (having both enabled
2021-07-29 22:54:02 <adamplumb[m]> seems to not work when trying to play sounds, haven't figured out the conf file yet) and i'm not sure if this is switchable in any way for people with pulse-backed systems
2021-07-30 00:05:50 <adamplumb[m]> What about making pulse-specific packages for libao and pianobar? Not sure if there are other mechanisms
2021-07-30 01:18:57 <Ariadne> building libao with pulse support is fine
2021-07-30 01:37:22 <adamplumb[m]> you mean adding a pulse dependency to libao? 
2021-07-30 01:37:56 <adamplumb[m]>  * you mean adding a pulse dependency to the existing libao package? 
2021-07-30 01:54:44 <Hello71> isn't pulse supposed to support alsa for basic audio output
2021-07-30 01:56:06 <Hello71> ah, you have to install alsa-plugins-pulse
2021-07-30 01:58:13 <Hello71> seems like libao is already plugin-oriented, so just --with-pulse and add a subpackage?
2021-07-30 02:02:05 <adamplumb[m]> what do you mean by subpackage?
2021-07-30 02:02:25 <valerius> a .so that gives you pulse support in libao
2021-07-30 02:02:34 <valerius> packaged up in its own .apk
2021-07-30 02:02:37 <adamplumb[m]> I can add --enable-pulse to the libao build and add a pulseaudio-dev dependency.  What else needs to happen
2021-07-30 02:03:19 <valerius> the idea of pulse as a dependency to libao makes me grind my teeth
2021-07-30 02:03:20 <adamplumb[m]> any examples of existing packages that do this?
2021-07-30 02:05:03 <Ariadne> like
2021-07-30 02:05:04 <Ariadne> a ton
2021-07-30 02:09:28 <Hello71> grep -r subpackage aports
2021-07-30 06:44:59 <ncopa> good morning
2021-07-30 06:46:38 <ncopa> doggone_: i dont know why nf_conntrack_bridge was enabled on mips64. I did not make the mips64 config. feel free to craete an issue if you need it in som of the other architectures
2021-07-30 06:49:20 <mps> also disabled in linux-edge for x86_64. that is because I copied -lts config
2021-07-30 06:49:38 <mps> but I enabled it for aarch64 and armv7
2021-07-30 06:50:23 <mps> and good morning
2021-07-30 06:51:44 <mps> need to look why it is not enabled for riscv64
2021-07-30 06:52:41 <mps> !23704
2021-07-30 06:54:00 <mps> valerius: re pulse: also
2021-07-30 07:11:30 <mps> testing/linux-amlogic is practically unmaintained. remove?
2021-07-30 08:44:19 <wener> clandmeter: hi, add change log to !23418 !23420 if you still think not worth it, you can just close the mr or let me know, I'll close the mr
2021-07-30 08:50:46 <fcolista> mps, perhaps you have another receipe for running a qemu arm ? :)
2021-07-30 08:51:50 <fcolista> (aarch32/armv7)
2021-07-30 09:21:18 <mps> fcolista: I have it somewhere. will try to find when I come back to home, in about one hour
2021-07-30 09:21:40 <fcolista> mps, thanks :)
2021-07-30 09:21:53 <mps> not sure if the ncopa made armv7 with fixed linxu-lts
2021-07-30 09:22:09 <mps> armv7 iso, I mean
2021-07-30 09:22:53 <mps> if not, linux-edge kernel must be used to have more than 1GB ram and virtio-net
2021-07-30 09:23:30 <mps> give me a hour of time
2021-07-30 09:23:56 <fcolista> virt is avail for armv7 too
2021-07-30 09:24:04 <mps> yes
2021-07-30 09:24:27 <mps> but kernel linux-virt is issue
2021-07-30 09:24:49 <mps> it is not fixed with 3.14 release, at least when I tested it
2021-07-30 09:25:24 <fcolista> ah ok
2021-07-30 09:27:46 <ncopa> hum... the builders are all idle
2021-07-30 09:27:58 <ncopa> i wonder if I should tag an edge snapshot
2021-07-30 09:28:21 <mps> that could be good idea
2021-07-30 09:59:20 <mps> fcolista: https://tpaste.us/qPPa
2021-07-30 09:59:54 <mps> this use netboot files I made and put on dev.a.o/~mps dir
2021-07-30 10:00:50 <mps> you will probably need to change/tweak some parameters and options in script
2021-07-30 10:01:20 <mps> i.e. tweak it to your needs
2021-07-30 10:01:54 <mps> oh, while I type here ncopa tagged snapshot :)
2021-07-30 10:02:23 <mps> ncopa: will you create armv7 iso with this snapshot?
2021-07-30 10:16:56 <ncopa> no
2021-07-30 10:18:25 <mps> so we could create script to netboot files?
2021-07-30 10:18:56 <mps> to use*
2021-07-30 11:58:02 <Habbie> ERROR: perl-5.32.1-r0: package mentioned in index not found (try 'apk update')
2021-07-30 11:58:04 <Habbie> in https://gitlab.alpinelinux.org/Habbie/aports/-/jobs/449870
2021-07-30 11:58:06 <Habbie> anything I can do about that?
2021-07-30 11:59:53 <fcolista> mps, thanks! why do we need qemu-efi-arm_2021.05-1_all.deb  ?
2021-07-30 12:00:32 <fcolista> I mean: isn't something we should have in alpine too?
2021-07-30 12:11:11 <mps> fcolista: no, we don't have it and my latest try to build it failed. so for now we have to use one from other distro
2021-07-30 12:11:35 <fcolista> ah it should be built, is not a binary 
2021-07-30 12:12:19 <mps> we can use u-boot instead and we have it on alpine but building iso img with u-boot would require not small change in aports/scripts
2021-07-30 12:13:00 <mps> though I prefer u-boot instead of grub :)
2021-07-30 12:50:30 <Hello71> ikke: can we close #12887?
2021-07-30 12:51:03 <ikke> I suppose so
2021-07-30 12:54:18 <adamplumb[m]> just made my first MR for the libao-pulse subpackage!
2021-07-30 12:54:19 <adamplumb[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23727
2021-07-30 12:55:56 <mps> we should remove pulse from alpine
2021-07-30 13:57:11 <fcolista> mps, is there a way to start armv7 from a disk?
2021-07-30 13:58:36 <fcolista> i succesfully installed alpine on qemu.img after it started via netboot
2021-07-30 14:04:07 <Ariadne> mps: agreed but many programs only support it
2021-07-30 14:04:14 <mps> fcolista: 'start armv7 from a disk', not sure I understand
2021-07-30 14:04:19 <mps> what you mean
2021-07-30 14:05:31 <mps> Ariadne: yes I know. but just couldn't resist to make a comment :)
2021-07-30 14:05:56 <fcolista> mps, basically I started armv7 withing qemu and installed alpine
2021-07-30 14:06:03 <fcolista> setup-alpine sys disk install
2021-07-30 14:06:08 <fcolista> installation started via netboot
2021-07-30 14:06:29 <mps> aha, need command line to start this installed image
2021-07-30 14:06:33 <fcolista> if i start it again, it restarts via netboot rather than from "disk" (which is the qemu.img virutal disk)
2021-07-30 14:06:36 <fcolista> correct
2021-07-30 14:06:46 <mps> give me few minutes
2021-07-30 14:06:59 <fcolista> thx mps,  i'm looking for this command
2021-07-30 14:07:46 <mps> I'm trying to debug crashe awesome wm on armv7 right now. have to switch to another machine
2021-07-30 14:08:17 <mps> fcolista: did you installed grub in this img?
2021-07-30 14:08:31 <fcolista> yes
2021-07-30 14:08:35 <mps> good
2021-07-30 14:12:06 <mps> fcolista: https://tpaste.us/xnnD
2021-07-30 14:12:18 <mps> you can omit screen from it
2021-07-30 14:12:49 <mps> I prefer to use screen and can detach and re-attach
2021-07-30 14:12:52 <fcolista> thx mps
2021-07-30 14:13:04 <fcolista> heeh
2021-07-30 14:13:06 <fcolista> kernel panic
2021-07-30 14:13:07 <fcolista> EFI stub: Entering in SVC mode with MMU enabled
2021-07-30 14:13:07 <fcolista> [    1.573168] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000
2021-07-30 14:13:09 <mps> fcolista: tutto per gli amici :)
2021-07-30 14:13:28 <mps> huh
2021-07-30 14:13:40 <fcolista> cool:) do you speak italian, mps?
2021-07-30 14:14:02 <fcolista> np let me retry to install it
2021-07-30 14:15:39 <mps> fcolista: long time ago I could talk with italians but nowadays I remember just a little of it
2021-07-30 14:16:46 <mps> and I read italian newspapers but now I doubt I can understand much
2021-07-30 14:17:04 <fcolista> where are you from?
2021-07-30 14:17:14 <fcolista> Russia?
2021-07-30 14:17:27 <mps> but I like to pretend that I understand italian :)
2021-07-30 14:17:37 <mps> no, I'm in Serbia
2021-07-30 14:17:48 <fcolista> ok, not far from here :)
2021-07-30 14:18:11 <mps> traveled few times in Italia for few months
2021-07-30 14:18:55 <mps> I think I visited most of important and famous Italian cities
2021-07-30 14:18:58 <fcolista> gotcha
2021-07-30 14:19:03 <fcolista> Rome?
2021-07-30 14:19:09 <mps> sure :)
2021-07-30 14:19:26 <mps> 'see Rome and die', you know proverb :)
2021-07-30 14:20:24 <mps> coincidence is that I live in city called Ruma, which was oldest know name also for Rome city
2021-07-30 14:20:39 <fcolista> :D
2021-07-30 14:21:24 <valerius> what have the Romans ever done for us?
2021-07-30 14:21:36 <ikke> Except for roads?
2021-07-30 14:21:37 <mps> look here https://en.wikipedia.org/wiki/Rome#Etymology
2021-07-30 14:21:38 <alpine-meetbot> [WIKIPEDIA] Rome#Etymology | "Rome (Italian and Latin: Roma [ˈroːma] (listen)) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in 1,285 km2 (496.1 sq mi), it..."
2021-07-30 14:22:09 <mps> from the Etruscan word 𐌓𐌖𐌌𐌀 (ruma)
2021-07-30 14:23:09 <mps> and Ruma is also now written in cyrillic exactly as this old etruscan, РУМА
2021-07-30 14:25:03 <mps> valerius: water pipes in houses, (aquaducts)
2021-07-30 14:25:49 <valerius> mps: https://www.youtube.com/watch?v=2ozEZxOsanY
2021-07-30 14:25:52 <mps> roads existed before Romans
2021-07-30 14:26:45 <mps> but Romans (or Rumans :) ) extended them over a lot then know lands
2021-07-30 14:27:22 <mps> valerius: you mean movie from monthy python team?
2021-07-30 14:27:29 <valerius> yes
2021-07-30 14:27:53 <mps> I knew without opening url :)
2021-07-30 14:29:01 <mps> watched this movie long time ago, and enjoyed it much. makes me smile even now
2021-07-30 14:30:01 <mps> fcolista: you don't have to answer but I'm curios in which city you live, maybe I were there also
2021-07-30 14:30:33 <fcolista> I'm from Rome, mps!
2021-07-30 14:31:36 <mps> very happy to hear that.
2021-07-30 14:32:04 <mps> you are lucky to live there, I think and feel
2021-07-30 14:32:15 <fcolista> agreed :)
2021-07-30 14:32:46 <fcolista> ok, kernel panic anyway
2021-07-30 14:32:48 <valerius> is the Circus Maximus where you run laps?
2021-07-30 14:33:09 <mps> heh, not :) but I was near
2021-07-30 14:33:51 <mps> yes, I visited it
2021-07-30 14:34:05 <fcolista> eheh
2021-07-30 14:35:59 <mps> when I was there I imagined myself in centre with gladius in hand ;)
2021-07-30 14:37:45 <mps> fcolista: could be issue with old linux-lts version
2021-07-30 14:38:34 <mps> now I remember that I installed self built kernel
2021-07-30 14:39:05 <fcolista> that might explain
2021-07-30 14:39:37 <mps> you can download linux-edge-virt latest and install it during install phase
2021-07-30 14:39:52 <fcolista> good idea
2021-07-30 14:40:56 <mps> as I promised yesterday I will try to make this weekend all this with latest edge netboot files
2021-07-30 14:45:55 <fcolista> thx mps, I appreciate your efforts!
2021-07-30 14:49:51 <wener> current setup-disk do not set ext4 block size
2021-07-30 14:50:01 <wener> default to 1k, too small
2021-07-30 14:52:51 <wener> seems default to 1k is alpine's problem
2021-07-30 14:56:35 <mps> fcolista: np
2021-07-30 14:56:38 <Hello71> isn't it based on disk size
2021-07-30 14:56:47 <wener> debian default to 4k
2021-07-30 14:57:00 <wener> truncate --size 20M test
2021-07-30 14:57:01 <wener> tune2fs -l test
2021-07-30 14:57:01 <wener> mkfs.ext4 -b 4096 test
2021-07-30 14:57:23 <wener> alpine is 1k, debian is 4k on this 20M file
2021-07-30 14:58:03 <wener> https://github.com/tytso/e2fsprogs/issues/74#issuecomment-889894735 
2021-07-30 14:58:14 <fcolista> ok I can confirm that i got kernel panic with latest linux-virt edge kernel
2021-07-30 14:58:59 <wener> my vm stuck on 1t due to this default
2021-07-30 14:59:32 <Hello71> wener: you have made the wrong conclusion from ts'o's comment
2021-07-30 14:59:54 <Hello71> do not resize a 20 MB filesystem to 2 TB
2021-07-30 15:00:05 <Hello71> that is what he is saying
2021-07-30 15:00:29 <Hello71> the block size is the immediate problem here but there are other non-resizable structures
2021-07-30 15:00:52 <Hello71> it may happen to work if you use some ancient e2fsprogs version
2021-07-30 15:02:44 <wener> but from the comment, 1k seems not good for default
2021-07-30 15:03:32 <Hello71> it is very clear
2021-07-30 15:03:42 <Hello71> 1k is a good choice for a 20 MB filesystem
2021-07-30 15:04:24 <wener> but all my vm are extend from 40G qcow2
2021-07-30 15:05:41 <Hello71> http://google.com/search?q=xkcd+spacebar+heating
2021-07-30 15:05:52 <wener> maybe should add a way to force the setup-disk block size ?
2021-07-30 15:06:37 <wener> some vm are extend from 2G, because alpine only need very little initial disk space
2021-07-30 15:07:40 <Hello71> this option already exists
2021-07-30 15:09:47 <wener> thx, found MKFS_OPTS_BOOT
2021-07-30 15:10:18 <wener> and MKFS_OPTS_ROOT
2021-07-30 15:11:43 <Hello71> but resizing ext4 more than 10x is a bad idea anyways
2021-07-30 15:14:17 <ikke> ncopa: you didn't include timlegge's commits for removing perl-dev?
2021-07-30 15:14:47 <mps> clandmeter: ping
2021-07-30 15:15:02 <wener> Hello71: but using vm seems normal, any better way to handle this ?
2021-07-30 15:15:27 <Hello71> use bcachefs :p
2021-07-30 15:16:02 <Hello71> i guess "bad idea" may be too strong
2021-07-30 15:16:06 <Hello71> it will not be best optimized
2021-07-30 15:18:00 <wener> thx, never heard of bcachefs
2021-07-30 15:21:30 <Hello71> it's a joke because it's not in tree
2021-07-30 15:21:46 <mps> ah ok, current edge linux-lts in netboot can't boot with virtio-net
2021-07-30 15:22:13 <Hello71> xfs may be a better option depending on your use. best is to create ext4 roughly the right target size
2021-07-30 15:22:25 <Hello71> ext4 design predates "vm cloning"
2021-07-30 15:23:32 <wener> not using vm clone, image is created by script, it's small, make it easier to upload , share and deploy
2021-07-30 15:24:12 <wener> the above 20m demo in debian still create 4k block size, maybe they default to 4k, instead to check target device size
2021-07-30 15:27:17 <Hello71> debian has different version of e2fsprogs as i said
2021-07-30 15:28:14 <mps> ok we can't boot armv7 in qemu with virtio-net and more than 1GB RAM using netboot because we don't have -virt files in https://dl-cdn.alpinelinux.org/alpine/edge/releases/armv7/netboot/ dir
2021-07-30 15:28:19 <mps> fcolista: ^
2021-07-30 15:29:53 <fcolista> mps, not sure how this applies in my scenario
2021-07-30 15:30:20 <fcolista> perhaps because during the install, -virt is not installed?
2021-07-30 15:30:38 <mps> we can't have netboot for armv7 virt using official alpine repo
2021-07-30 15:30:52 <fcolista> so what is booted?
2021-07-30 15:31:39 <mps> if you are using script I posted you boot using kernel I made to work properly
2021-07-30 15:32:04 <fcolista> ok that's why is booting, then
2021-07-30 15:32:56 <mps> if you install it, you can change to edge repo, update and upgrade, then install linux-virt and linux-edge-virt
2021-07-30 15:33:19 <mps> not sure will this work 'out-of-the-box'
2021-07-30 15:34:12 <mps> or, you can download 'by hand' linux-virt from edge and install it from apk file
2021-07-30 15:34:16 <fcolista> gotcha. Will try again. For sure I've installed edge
2021-07-30 15:34:20 <fcolista> not sure if edge-virt
2021-07-30 15:34:59 <mps> also, try linux-edge-virt, I know it works fine
2021-07-30 15:35:09 <fcolista> sure
2021-07-30 15:37:48 <mps> ofc, maybe I can make script to install linux-lts using less than 1GB ram and not using virtio-net and then when it boots from disk img install linux-virt, but this is 'in more steps' solution
2021-07-30 16:01:35 <minimal> wener: block size is controlled via /etc/mke2fs.conf
2021-07-30 16:03:38 <wener> minimal: thanks
2021-07-30 16:04:18 <unrznbl[m]> Can someone review this pretty straightforward cfengine version upgrade MR? Thanks in advance. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22990
2021-07-30 16:05:00 <minimal> wener: the default in that file *is* 4k, however the "small" fstype overrides that to 1k
2021-07-30 16:05:26 <wener> the only different between alpine and debian is debian has small inode_size = 128
2021-07-30 16:06:02 <minimal> we are talking about the blocksize value though?
2021-07-30 16:08:00 <minimal> so if you run mkfs.ext4 with "-T small" it'll use the small settings in preference to the defaults. If you don't specify "-T" at all then it will use "floppy" / "small" / "big" / "huge" / "default" depending on the size of the filesystem to be created
2021-07-30 16:08:29 <wener> yes, I should check the manual
2021-07-30 16:09:26 <minimal> wener: that's your issue - the size of the partition/device for the filesystem controls which settings are used. For a VM if you want to grow it later then perhaps you should explicitly specify a "-T" or a "-b" value
2021-07-30 16:10:54 <minimal> wener: also node you'll want to ensure the inode size (-I) is >= 256 to avoid Year2038 warnings/problems
2021-07-30 16:11:00 <minimal> s/node/note/
2021-07-30 16:11:00 <alpine-meetbot> minimal meant to say: wener: also note you'll want to ensure the inode size (-I) is >= 256 to avoid Year2038 warnings/problems
2021-07-30 16:12:15 <wener> thanks, I changed the building script to add -b, just curious the difference between alpine and debian on this
2021-07-30 16:15:55 <minimal> wener: looking at a Debian box here the values in /etc/mke2fs.conf look similar
2021-07-30 16:17:14 <wener> maybe I made a mistake before, truncating a wrong size
2021-07-30 16:17:59 <minimal> wener: in your build script if you pass mkfs.ext4 the "-v" option does it show the "-T" value automatically chosen?
2021-07-30 16:20:19 <wener> yes, the -v will show the value
2021-07-30 16:20:51 <minimal> wener: the inode different for "small" is due to a MR I raised 7 months ago, !15716, to fix the YR2038 issue :-)
2021-07-30 16:22:22 <minimal> apart from this change the rest of the Debian and Alpine mke2fs.conf files are the same as they use the file from the upstream package
2021-07-30 16:22:38 <wener> this make sense, retested, they are the same now, I do made a mistake before
2021-07-30 16:26:19 <minimal> wener: you may also want to look at "-i" and "-E resize=??" options to mkfs.ext4 to see if they are of use/significance for your filesystem resizing
2021-07-30 16:28:17 <minimal> wener: also "-m reserved-blocks-percentage" as you may want to reduce the percentage for large filesystems
2021-07-30 16:29:15 <wener> minimal: how can I findout the existing max-online-resize, tune2fs seems do not list these options
2021-07-30 16:31:47 <wener> ext4 is more complex than I expected, emmmm
2021-07-30 16:33:35 <minimal> wener: I've never used it, all I can see is in "man ext4": "By default mke2fs will attempt to reserve enough space so that the filesystem may grow to 1024 times its initial size.  This can be changed using the resize extended option."
2021-07-30 16:34:38 <wener> thanks
2021-07-30 16:35:43 <minimal> wener: for large disks I would tend to use LVM (whether with ext4 or xfs) and grow the filesystems according to need rather than creating 1 big filesystem
2021-07-30 16:37:27 <wener> I still not understand xfs, just using the ext4 as a safe default. the underlay host use zfs
2021-07-30 16:39:25 <wener> lvm add more op burden, I don't want to 1 big fs, but when things happed, 1 big fs can solve the problem for now.
2021-07-30 17:39:15 <mps> fcolista: I made armv7 iso with linux-edge-virt kernel. It boots fine using '-cdrom' qemu option
2021-07-30 17:40:32 <mps> if you want to test it I can upload it on dev.a.o/~mps
2021-07-30 17:40:40 <mps> dev.a.o
2021-07-30 17:40:47 <mps> algitbot: ?
2021-07-30 17:40:54 <mps> hah
2021-07-30 18:49:49 <mps> fcolista: https://tpaste.us/5nnM
2021-07-30 18:50:30 <mps> ofc, also for all interested to run alpine armv7 under qemu
2021-07-30 18:50:55 <mps> bugs, ideas, improvements will be appreciated
2021-07-30 20:14:17 <wej> mps: I'm not exactly sure what you meant with your comment here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23725 is the install command for installing the config file unnecessary?
2021-07-30 20:15:43 <ikke> afaik, abuild does not do that for you
2021-07-30 20:16:07 <ikke> what _is_ present is that it moves it to the openrc subpackage when you defined it (and you should)
2021-07-30 20:16:19 <ikke> and you have
2021-07-30 20:16:51 <wej> yeah, that's what i thought
2021-07-30 20:17:01 <wej> and it looks to build everything as expected
2021-07-30 20:26:37 <mps> wej: I think this part with 'cat ....' already exists
2021-07-30 20:30:10 <wej> mps: oh the parts that's adding the comment to the access.conf file? i didn't want to touch it unless there is a reason to do so
2021-07-30 20:30:56 <mps> yes. I think this part should be removed
2021-07-30 20:31:10 <wej> ok, sure, i can remove it
2021-07-30 20:32:44 <mps> thanks
2021-07-30 20:34:08 <mps> aieee! I nearly finished armv7 qemu guide. weekend will be more pleasant ;)
2021-07-30 20:35:07 <wej> mps: alright, it is gone now :)
2021-07-30 20:36:01 <mps> ok
2021-07-30 20:49:03 <mps> fcolista: https://arvanta.net/alpine/install-armv7-qemu/
2021-07-30 20:49:29 <mps> enough work for alpine today
2021-07-30 20:49:31 <mps> :)
2021-07-30 22:34:30 <craftyguy> is the "CMAKE_BUILD_TYPE must be None" lint error OK to ignore if the CMakeLists.txt in the project doesn't define a "None" type?
2021-07-31 00:38:25 <timlegge> ikke: not sure what happened there.  I rebased and then there were no commits but I ran my script against main again and found some.  I should probably squash them
2021-07-31 05:26:04 <maxice8> <craftyguy "is the "CMAKE_BUILD_TYPE must be"> Never ok to ignore
2021-07-31 05:26:58 <maxice8> most times it is a poorly written CMakeLists.txt (because writing a good one is hard) that checks the CMAKE_BUILD_TYPE against a List and if it doesn't match any in the list it picks Release
2021-07-31 06:03:47 <craftyguy> uh oh
2021-07-31 06:05:49 <craftyguy> well the CMakeLists.txt is checking against a list, and bailing out if it's not Release, Debug, or RelWithDebInfo
2021-07-31 06:07:27 <craftyguy> I'll see about sending a patch upstream for supporting None
2021-07-31 08:53:53 <Jenkler> ncopa, where did the snowball-dev go? I thougt this was fixed by now!
2021-07-31 08:56:39 <Jenkler> ahh libstemmer-dev
2021-07-31 09:01:50 <Jenkler> Seams to works ;)
2021-07-31 10:26:51 <Jenkler> Having issue with stemmer. Have someone seen this https://tpaste.us/vgg5
2021-07-31 10:28:43 <Jenkler> Here is the cpp file https://tpaste.us/Qrrz
2021-07-31 10:29:33 <Jenkler> libstemmer-dev and libstemmer does not work, But it would be nice with some help for a patch
2021-07-31 10:49:18 <Jenkler> configure finds it "Checking for C library stemmer... yes"
2021-07-31 10:52:08 <ikke> These kind of issues do not happen due to missing files
2021-07-31 10:52:27 <ikke> more like mismatching versions
2021-07-31 10:55:55 <ikke> Nice, I have spice-vdagent running on alpine
2021-07-31 11:19:11 <Jenkler> ikke, but why does https://tpaste.us/KMMn
2021-07-31 11:19:44 <Jenkler> still point to #include "third_party/libstemmer_c/include/libstemmer.h"
2021-07-31 11:20:24 <ikke> I guess because they 'vendored' the library
2021-07-31 11:20:39 <Jenkler> does scons modify change the path ?
2021-07-31 11:20:55 <Jenkler> Yes but i have set the --use-steemer 
2021-07-31 11:21:35 <ikke> Jenkler: I don't know scons
2021-07-31 11:21:54 <Jenkler> --use-system-stemmer
2021-07-31 11:22:53 <Jenkler> it seams that make configure finds the lib "Checking for C library stemmer... yes" 
2021-07-31 11:23:33 <ikke> I guess you have to patch that file then
2021-07-31 11:24:59 <Jenkler> Yes, but i need to know how scons work better. Something it strange here. It worked with an old lib 
2021-07-31 11:31:32 <Jenkler> it does not work to change to /usr/include/libstemmer.h
2021-07-31 11:31:53 <ikke> usually <libstemmer.h>
2021-07-31 11:34:10 <Jenkler> ikke, like this #include <libstemmer.h> right?
2021-07-31 11:34:22 <ikke> yes
2021-07-31 11:34:32 <ikke> but in this case, that should not make a difference
2021-07-31 11:34:52 <Jenkler> #include "third_party/libstemmer_c/include/libstemmer.h" was the old one 
2021-07-31 11:35:03 <ikke> yes, but I mean compared to the absolute path
2021-07-31 11:35:24 <Jenkler> yes, it should not matter i know..
2021-07-31 11:37:08 <Jenkler> this error https://tpaste.us/vgg5 must be something else then :(
2021-07-31 11:38:27 <ikke> Can you try to find out the linker command?
2021-07-31 11:38:54 <ikke> It might not try to link to the system libstemmer library
2021-07-31 11:39:10 <ikke> There should be -lstemmer in the invocation
2021-07-31 11:41:07 <Jenkler> ikke, I can only see that in the code right. Not the build log
2021-07-31 11:41:22 <ikke> I don't know scons, but sometimes you can ask for verbose output
2021-07-31 11:42:44 <ikke> For example, make V=1
2021-07-31 11:43:12 <Jenkler> I have SConstruct that seam to deside the fate 
2021-07-31 11:44:33 <Jenkler> add_option('use-system-stemmer',
2021-07-31 11:44:33 <Jenkler>     help='use system version of stemmer',
2021-07-31 11:44:33 <Jenkler>     nargs=0)
2021-07-31 11:45:54 <Jenkler> if use_system_version_of_library("stemmer"):
2021-07-31 11:45:54 <Jenkler>         conf.FindSysLibDep("stemmer", ["stemmer"])
2021-07-31 11:46:28 <Jenkler> thats why configure seams to find stemmer 
2021-07-31 11:48:04 <mps> ikke: good that you made vd_agent, but doesn't it add some risks
2021-07-31 11:48:53 <mps> I thought to make it but didn't because i have some fears of such features
2021-07-31 11:49:31 <mps> and at the end, all risks *are* on the user, anyway
2021-07-31 11:50:26 <mps> use risky thing or  not use them
2021-07-31 11:50:41 <mps> like in real life
2021-07-31 11:50:59 <ikke> I would only use it in trusted vms
2021-07-31 11:53:48 <mps> yes, I would do in same cases
2021-07-31 11:55:08 <ikke> You need to explicitly add a device to the VM for it to work
2021-07-31 11:55:17 <ikke> so as long as you do not add that device, the agent itself is harmless
2021-07-31 11:57:49 <mps> yes, I know, used it on debian
2021-07-31 12:15:11 <Hello71> vdagent is a pretty simple protocol, i wouldn't be too worried about it
2021-07-31 12:15:38 <Hello71> qemu itself is much bigger attack surface
2021-07-31 12:15:45 <Hello71> virtiofsd always runs as root, etc
2021-07-31 12:24:45 <ikke> I was just anoyed I could not share the clipboard
2021-07-31 12:41:24 <Hello71> virgl is of course a huge attack surface
2021-07-31 15:22:07 <adamplumb[m]> I've been working on this libao issue on pmOS, where the built-in main/libao package doesn't really work (it is built for alsa, and pmOS relies on pulse).
2021-07-31 15:22:39 <adamplumb[m]> I've been ping-ponging around with the solution, but have been getting objections (see here: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2395#note_640144328)
2021-07-31 15:23:04 <adamplumb[m]> Would there be objection to creating a new libao-pulse package in community and a new pianobar-pulse package as well?
2021-07-31 15:23:19 <adamplumb[m]> these would be entirely separate packages that built against pulse instead of alsa
2021-07-31 15:23:27 <adamplumb[m]>  * these would be entirely separate packages that built against pulse instead of alsa (or possibly allow both)
2021-07-31 15:27:17 <PureTryOut1> What is the reason for libao being in main? Maybe it's just worth moving to community?
2021-07-31 15:28:10 <ikke> Was there already from before the introduction of community
2021-07-31 15:28:40 <ikke> rdesktop depends on it (which is also in main)
2021-07-31 15:28:46 <PureTryOut1> Ah interesting, an old package then. So yeah maybe it can just be moved to community and just build with both alsa and Pulse support
2021-07-31 15:28:47 <PureTryOut1> Oh
2021-07-31 15:28:58 <PureTryOut1> Is rdesktop also in there because community didn't exist yet?
2021-07-31 15:29:03 <ikke> most likely
2021-07-31 15:29:34 <ikke> 9526ee6 2010-01-25 16:43 +0000 Natanael Copa  ◎ merged x11 repository into main
2021-07-31 15:31:15 <PureTryOut1> Ah yes, a leftover
2021-07-31 15:32:04 <PureTryOut1> adamplumb: so yes easiest (and probably best) solution seems to be to move libao and rdesktop to the community repo. Then you can build libao with both alsa and pulse support
2021-07-31 15:32:23 <PureTryOut1> Building with pulse support normally only makes it depends on libpulse and doesn't require the rest of PulseAudio to be installed, but that has to be verified
2021-07-31 15:32:29 <valerius> is the plan still to keep the libao-pulse package separate?
2021-07-31 15:33:24 <adamplumb[m]> if we move libao to community we can make a libao-pulse subpackage
2021-07-31 15:33:29 <valerius> having trouble parsing/understanding everything sorry
2021-07-31 15:33:48 <valerius> yeah, I like it as a subpackage since I use libao and do not want to have anything related to pulse installed :p
2021-07-31 15:34:20 <adamplumb[m]> i'm not sure if there is a way to have a subpackage that also just works out of the box for pmos users.  
2021-07-31 15:34:42 <adamplumb[m]> If I install pianobar that depends on libao, it wouldn't install libao-pulse automatically
2021-07-31 15:34:51 <adamplumb[m]> unless i update pianobar to depend on libao-pulse
2021-07-31 15:36:36 <PureTryOut1> valerius: Pulse support most of the time just installs libpulse, not the entirety of PulseAudio
2021-07-31 15:37:39 <Hello71> install_if=pulseaudio is an alpine-ish way to do it
2021-07-31 15:37:54 <Hello71> it's not *exactly* correct but consistent with rest of alpine
2021-07-31 15:37:57 <PureTryOut1> If it's easy to split out the support to a subpackage then yes that works
2021-07-31 15:38:11 <Hello71> e.g. apk add openrc automatically installs openrc init scripts, even though you may not actually want them for all packages
2021-07-31 15:38:18 <PureTryOut1> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23727
2021-07-31 15:38:20 <PureTryOut1> Oh seems easy
2021-07-31 15:38:26 <PureTryOut1> Then yes use an install_if in a subpackage
2021-07-31 15:38:38 <Hello71> yes, that's what i said 
2021-07-31 15:38:43 <Hello71> yesterday: 01:58 <Hello71> seems like libao is already plugin-oriented, so just --with-pulse and add a subpackage?
2021-07-31 15:38:53 <PureTryOut1> I know I just wanted to confirm you can actually split out the Pulse support that easy
2021-07-31 15:39:07 <PureTryOut1> As for some other packages the main library/binary depends on libpulse and you can't split it out
2021-07-31 15:39:13 <adamplumb[m]> yeah i built out that MR with the subpackage.  it does work
2021-07-31 15:39:22 <adamplumb[m]> but ran into the issue that libao is in main and pulse is in community
2021-07-31 15:39:40 <PureTryOut1> Should be fixed like we mentioned then 👍️
2021-07-31 15:39:58 <adamplumb[m]> ok cool, so then I can update that MR to move libao and rdesktop to community
2021-07-31 15:40:09 <PureTryOut1> So I guess re-open !23727 and add commits that move both libao and rdesktop to community
2021-07-31 15:41:09 <mps> khm, khm, rename alpine to pmOS ;)
2021-07-31 15:44:19 <Thermi> ikeif you have time this weekend, could you please continue the review of !23415?
2021-07-31 15:44:22 <Thermi> *ikke, if
2021-07-31 15:44:56 <adamplumb[m]> hmm rdesktop doesn't seem to have any relationship to libao
2021-07-31 15:45:46 <adamplumb[m]> https://git.alpinelinux.org/aports/tree/main/rdesktop/APKBUILD
2021-07-31 15:46:22 <adamplumb[m]> though the configure on there does with `--with-sound=ao`.  So maybe it does require libao but it isn't marked as a depends?
2021-07-31 15:46:34 <adamplumb[m]>  * though the configure on there does have `--with-sound=ao`.  So maybe it does require libao but it isn't marked as a depends?
2021-07-31 15:47:15 <ikke> adamplumb[m]: it's part of makedepends (libao-dev)
2021-07-31 15:47:51 <ikke> but
2021-07-31 15:47:53 <adamplumb[m]> oh i see.
2021-07-31 15:48:06 <ikke> It doesn't seem rdesktop has a runtime dependency on libao
2021-07-31 15:48:19 <ikke> https://tpaste.us/yppl
2021-07-31 15:49:25 <adamplumb[m]> i also see this in the main folder of aports: ```$ grep libao -R *
2021-07-31 15:49:25 <adamplumb[m]> a52dec/automake.patch:     doc/Makefile src/Makefile liba52/Makefile libao/Makefile vc++/Makefile])
2021-07-31 15:49:25 <adamplumb[m]> ```
2021-07-31 15:49:34 <adamplumb[m]> a52dec/automake.patch:     doc/Makefile src/Makefile liba52/Makefile libao/Makefile vc++/Makefile])```
2021-07-31 15:49:34 <adamplumb[m]> ```$ grep libao -R *
2021-07-31 15:49:34 <adamplumb[m]>  * i also see this in the main folder of aports: 
2021-07-31 15:50:21 <adamplumb[m]> it seems to have some dependency on libao
2021-07-31 15:51:40 <ikke> Thermi: I'm taking a look
2021-07-31 15:52:24 <adamplumb[m]> should a52dev be moved to community as well?
2021-07-31 15:53:02 <Hello71> ikke: seems like it should be --with-sound=libao: https://github.com/rdesktop/rdesktop/blob/master/configure.ac#L414
2021-07-31 15:53:27 <Hello71> but afaik rdesktop is basically obsolete now, replaced with freerdp
2021-07-31 15:53:52 <mps> everything should be moved to community, so would be easier to maintain stable releases, only for 6 months :)
2021-07-31 15:53:53 <Hello71> i think rdesktop cannot even connect to modern windows
2021-07-31 15:54:09 <Hello71> mps: and move pulseaudio to trash? :p
2021-07-31 15:54:25 <mps> Hello71: you are my today hero :)
2021-07-31 15:54:25 <valerius> that sounds like a great idea
2021-07-31 15:54:37 <mps> and not only my, I think
2021-07-31 15:55:52 <mps> I joined alpine when it didn't had pulse, or it was in testing only, can't remember exactly
2021-07-31 15:56:15 <mps> and that was one of strong reasons to switch to alpine
2021-07-31 16:00:57 <Thermi> ikke, tyvm
2021-07-31 16:03:48 <Hello71> !23765 fix rdesktop libao
2021-07-31 16:06:44 <adamplumb[m]> Hello71: I could also fix that in my MR
2021-07-31 16:07:09 <adamplumb[m]> which i did but can back it out if you want to do that separately
2021-07-31 16:10:08 <Hello71> git can merge it
2021-07-31 16:10:25 <adamplumb[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23727/diffs#23d43bd164ee5cd75cbdd474e88b51182fb0b64b_53_53
2021-07-31 16:15:23 <Hello71> heh, i forgot to update pkgrel
2021-07-31 16:21:22 <Hello71> can someone close https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10037 and https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10036? they are unrelated to abuild
2021-07-31 16:23:16 <mps> yes
2021-07-31 16:24:22 <mps> hmm, no, I don't have rights there, sorry
2021-07-31 16:24:31 <ikke> I'll close it
2021-07-31 18:30:44 <ikke> Thermi: left some feedback / questions
2021-07-31 18:37:09 <Thermi> ikke, Thank you, I think I fixed them as desired.
2021-07-31 18:38:16 <ikke> hmm, seems to fail to build now?
2021-07-31 18:38:29 <ikke> >>> ERROR: kopano-webapp: unpack failed
2021-07-31 18:41:29 <Thermi> Forgot the checksum,.
2021-07-31 18:42:50 <ikke> And, did you on purpose now remove the call to the compress script?
2021-07-31 18:45:57 <Thermi> It's still there, but in the execution of find directly below it
2021-07-31 18:46:11 <Thermi> find [...] -exec 
2021-07-31 18:47:52 <ikke> I see, yes
2021-07-31 18:58:42 <mps> hmm https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a34b13a88caeb2800ab44a4918f230041b37dd9&utm_source=anzwix
2021-07-31 18:59:18 <mps> I think this deserve making reverting patch for our kernels
2021-07-31 19:02:12 <ikke> assuming there is nothing else that relies on this behavior?
2021-07-31 19:05:16 <mps> we would notice it till now if something relies on this 'feature', I think
2021-07-31 21:20:24 <Thermi> ikke, thank you for your work
2021-07-31 21:31:19 <Thermi> Could somebody take a look at !23411 please?
2021-07-31 21:31:37 <Thermi> It's part of kopano. It provides the Active Sync part for Outlook clients.