2021-03-01 07:26:11 looking at gonic 2021-03-01 07:26:37 nvm 2021-03-01 07:36:43 I already fixed it 😊 2021-03-01 07:37:12 But I'm at work now, so feel free to continue 2021-03-01 11:34:23 maxice8: working on gopass 2021-03-01 11:34:49 I could swear I fixed it 2021-03-01 11:35:01 This is a different issue 2021-03-01 11:35:08 They provide their own GOFLAGS 2021-03-01 11:36:41 I have an mips64 lxc container where I can verify if it's working 2021-03-01 11:46:28 Hmm, they have in their Makefile BUILDFLAGS_NO_PIE and BUILDFLAGS that includes the former + -buildmode=pie 2021-03-01 11:46:47 I wonder if it's possible to override BUILDFLAGS while still using BUILDFLAGS_NO_PIE 2021-03-01 12:04:34 what happened to community/go-bindata-assetfs? 2021-03-01 12:05:19 dff3709d0c3af70c5eceaf427fa4d430e98b4009 2021-03-01 12:05:37 thanks 2021-03-01 12:14:11 'snow drop' :) 2021-03-01 12:20:06 I wondered since I began working at upgrading community/nomad that makedepends on go-bindata-assetfs, so does community/vault 2021-03-01 12:20:47 "bash: line 1: go-bindata-assetfs: command not found" 2021-03-01 13:51:44 https://twitter.com/steaIth/status/1364940271054712842 was this fixed? 2021-03-01 13:54:31 not as far as I'm aware 2021-03-01 13:54:39 the source package wasn't touched for a while 2021-03-01 13:57:50 What is that bin user in shadow about? 2021-03-01 14:08:52 the issue is that a not root user can access /etc/shadow, I think 2021-03-01 14:15:13 Default permissions from baselayout are 0640 2021-03-01 14:16:22 it's probably an setuid binary 2021-03-01 14:16:30 oh it is 2021-03-01 14:16:43 The Lua one is 2021-03-01 14:17:14 So just to show you can read shadow with that binary 2021-03-01 14:20:05 I'm puzzled why that needs suid 2021-03-01 14:21:28 Apparently a feature 2021-03-01 14:22:04 It's even called privilege escalation 2021-03-01 14:25:35 that seems really weird 2021-03-01 14:25:41 i mean, lua can do anything, right 2021-03-01 14:25:48 so if that's just an interpreter, that's crazy 2021-03-01 14:25:54 what package provides it? 2021-03-01 14:26:49 haserl 2021-03-01 14:27:11 ACTION looks 2021-03-01 14:27:25 It's kind of niche 2021-03-01 14:27:38 oh I see 2021-03-01 14:27:41 "Privilege Escalation: On Linux, if haserl is installed suid root, then it will attempt to drop its privilege to the uid/gid of the owner of the cgi script. This is similar to suexec in Apache." 2021-03-01 14:27:55 hahahaha 2021-03-01 14:28:26 honestly I'd just drop the suid bit by default and then tell users if they want that functionality, to move it somewhere safe (accessible only to e.g. Apache) and re-add it 2021-03-01 14:28:31 but it still sounds like a horrible idea 2021-03-01 14:29:47 it would be nice to advertise (and create if it doesn't exist) security@alpinelinux.org 2021-03-01 15:32:23 ncopa: opinion on heserl suid binary that can be used to run anything as root? 2021-03-01 15:55:13 avoid use haserl if possible 2021-03-01 15:55:45 it was needed because it was used for ACF, to reconfigure your machine 2021-03-01 15:56:26 you will still need to install whatever you want to run as root 2021-03-01 15:56:34 last update in 2015, with last stable in 2005 :/ 2021-03-01 16:05:21 fish 3.2.0 has `apk` completion 2021-03-01 16:26:45 neat 2021-03-01 17:02:52 Cogitri: https://gitlab.alpinelinux.org/Leo/aports/-/jobs/335704/artifacts/browse/logs/ 2021-03-01 17:04:19 ikke: Nice! :) 2021-03-01 17:05:42 there is one build-*.log and one checkapk-*.log file per package built 2021-03-01 17:06:40 Also if checkapk doesn't output anything? 2021-03-01 17:08:12 I think it always outputs something? 2021-03-01 17:21:21 Anyone knows if it's possible to override BUILDFLAGS, but still use the value of BUILDFLAGS_NO_PIE somehow? https://github.com/gopasspw/gopass/blob/master/Makefile#L15 2021-03-01 17:22:37 ikke: Oh, okay, thought it wouldn't output something if nothing changed 2021-03-01 17:22:44 ah, found it, I just found out it's BUILDFLAGS_NOPIE, instead of BUILDFLAG_NO_PIE 2021-03-01 17:27:19 Cogitri: this is a new package: https://gitlab.alpinelinux.org/gjabell/aports/-/jobs/335606#L374 2021-03-01 17:33:18 Fixing mips64 is kind of like a whack-a-mole. One package fails, you fix it, but then another package gets built, which fails, and then you fix that, but then yet another package gets built. After you fix that, the first package fails again for a different reason :P 2021-03-01 17:38:50 why is mips64 so bad?? 2021-03-01 17:39:07 dalias: we just enabled docker 2021-03-01 17:39:10 I mean, go 2021-03-01 17:39:20 and go 1.16 has been released 2021-03-01 17:39:27 that combination leads to a few build failures 2021-03-01 17:39:56 and the fact that buildmode=pie is apparently not supported for mips64 2021-03-01 17:40:15 go: downloading google.golang.org/protobuf v1.21.0 2021-03-01 17:40:17 -buildmode=pie not supported on linux/mips64 2021-03-01 17:42:42 We removed that from GOFLAGS, but some projects add it themselves 2021-03-01 17:43:12 I suspect go-bindata-assetfs does things not (yet) covered by go-bindata 2021-03-01 17:43:28 Can you add new packages to stable releases? 2021-03-01 17:43:41 Newbyte: generally, no 2021-03-01 17:43:51 what's the reasoning behind that? 2021-03-01 17:46:11 we dont automatically add all new packages to the all the stable branches, but we occationally add new packages to latest stable on request, if there are good reasons to do so 2021-03-01 17:50:13 would "I want to use this on stable" be a good reason? 2021-03-01 17:54:59 If the maintainer of the package is OK with maintaining it in the stable release it's a good enough reason, I suppose 2021-03-01 18:17:18 Security problem NULL DT_RPATH in /home/buildozer/aports/testing/kicad/pkg/kicad/usr/lib/python3.8/site-packages/_pcbnew.so 2021-03-01 18:18:11 kicad is failiung 2021-03-01 18:20:30 security problem? 2021-03-01 18:20:49 That's what scanelf returns 2021-03-01 18:20:53 .. 2021-03-01 18:21:18 scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in /home/buildozer/aports/testing/kicad/pkg/kicad/usr/lib/python3.8/site-packages/_pcbnew.so 2021-03-01 18:23:12 do they mean empty path? 2021-03-01 18:23:21 googling this can't find any documentation for it... 2021-03-01 18:24:30 But I think it's failing for a different reason 2021-03-01 18:24:32 it looks like they mean zero-length rpath string 2021-03-01 18:24:44 On CI, it gave the same message, but it continued 2021-03-01 18:24:46 which would be bad semantically (include current dir) 2021-03-01 18:24:55 however musl does not allow that nonsense 2021-03-01 18:24:56 ERROR: kicad*: Has /home/... in rpath 2021-03-01 18:25:19 empty components are skipped 2021-03-01 18:25:25 if you want . in path you need an explicit . 2021-03-01 18:25:41 for LD_LIBRARY_PATH, ld-musl...path, rpath, etc. 2021-03-01 18:28:31 lol i think it''s some cmake shit 2021-03-01 18:28:58 yeah 2021-03-01 18:29:03 they (upstream cmake fixed it but it probably got kept in lots of broken CMakeFiles) put "" in rpath to allow executing program from build dir... 2021-03-01 18:29:16 *facepalm* 2021-03-01 18:29:37 anyway musl is immune to it :) 2021-03-01 18:30:25 yeah, it means empty afaik 2021-03-01 18:30:33 hmm, does mips64 not support fallocate? 2021-03-01 18:30:43 unexpected error: operation not supported 2021-03-01 18:33:05 it's likely some hideous nondefault filesystem that doesn't support it, that just happens to be what's present on the mips64 box, not mips64 2021-03-01 18:33:52 sam_, then the warning should be changed to "relative paths in rpath" and also catch . and any pwd-relative path, not just "" :) 2021-03-01 18:34:01 ext3 2021-03-01 18:34:11 ikke, hm, ext3 should support it 2021-03-01 18:34:52 dalias: https://github.com/gentoo/pax-utils/blob/master/scanelf.c#L773 2021-03-01 18:34:53 it does 2021-03-01 18:34:54 trying strace to see what syscall is used 2021-03-01 18:35:12 sam_, yay 2021-03-01 18:35:16 :D 2021-03-01 18:35:19 ikke, it could be a bug i guess.. 2021-03-01 18:35:21 maybe we should fix that NULL though 2021-03-01 18:36:03 i would call it "implicit ." or something rather than "NULL" 2021-03-01 18:36:22 dalias: isn't it explicitly checking for '\0'? 2021-03-01 18:36:28 https://github.com/gentoo/pax-utils/blob/master/scanelf.c#L778 2021-03-01 18:36:31 to me a "NULL rpath" would mean DT_RPATH is present but (pointer) value is 0 2021-03-01 18:36:57 not a zero-length path component in rpath string 2021-03-01 18:37:09 but it's a silly bikeshed 2021-03-01 18:37:23 and maybe tooling greps for the existing error names 2021-03-01 18:38:09 ikke, strace show anything interesting? 2021-03-01 18:38:33 dalias: still working on it 2021-03-01 18:44:45 dalias: seems like epoll? 2021-03-01 18:44:55 10804 epoll_ctl(4, EPOLL_CTL_ADD, 7, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=255, u64=1098604851016}} 2021-03-01 18:45:05 10804 <... epoll_ctl resumed>) = -1 EPERM (Operation not permitted) 2021-03-01 18:48:41 lol more docker bs ? 2021-03-01 18:48:44 fallocate(7, 0, 0, 1 2021-03-01 18:48:45 <... fallocate resumed>) = -1 EOPNOTSUPP (Not supported) 2021-03-01 18:48:49 no 2021-03-01 18:48:50 this is not docker 2021-03-01 18:48:52 there's the fallocate 2021-03-01 18:49:42 (it's lxc) 2021-03-01 18:50:50 openat(AT_FDCWD, "/tmp/restic-test-346411139/test", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0600 <... openat resumed>) = 7 2021-03-01 18:51:50 /tmp is just ext3, not tmpfs or something like that 2021-03-01 18:52:24 does lxc have seccomp filters too? 2021-03-01 18:52:37 can the kernel version matter? 2021-03-01 18:52:48 maybe 2021-03-01 18:52:51 is this an ancient kernel 2021-03-01 18:53:08 4.9.79 2021-03-01 18:55:19 afaict, lxc does not use seccomp 2021-03-01 18:55:54 hmm ext4 driver has lots of paths that can fail with EOPNOTSUPP 2021-03-01 18:56:22 I guess I'll just disable this for now 2021-03-01 18:56:35 but looks like mode==0 should not hit them 2021-03-01 19:28:05 ikke, regardless, code not prepared to handle EOPNOTSUPP from fallocate is buggy 2021-03-01 19:28:15 there are plenty of filesystems that do not/cannot support it 2021-03-01 19:28:35 dalias: Apparently this is part of golangs stdlib 2021-03-01 19:28:40 .. 2021-03-01 19:28:42 x/sys/unix 2021-03-01 19:32:48 dalias: seems like it's just a light wrapper around the syscall 2021-03-01 19:32:54 https://github.com/golang/sys/blob/8e9945a5478f4f1c3aa024380d3e313cca0430dd/unix/syscall_linux.go#L1897 2021-03-01 19:33:22 ah 2021-03-01 19:33:37 then the calling app is wrong to not handle failure 2021-03-01 19:33:52 It's test code 2021-03-01 19:34:00 :) 2021-03-01 19:34:38 How should the app properly handle it?' 2021-03-01 19:35:05 Just open the file and write to iT? 2021-03-01 19:35:12 depends on what it's doing i guess 2021-03-01 19:35:27 restic is a backup program, this is part of the restore componenet 2021-03-01 19:35:34 note that even writing data does not necessarily reserve space, with broken fs designs 2021-03-01 19:36:10 some ppl make wacky filesystems with deduplication/indexing of fs blocks by a hash of their contents 2021-03-01 19:36:25 or just compression 2021-03-01 19:36:33 whereby overwriting existing data with something different might take more space 2021-03-01 19:36:43 this is not posix compliant and should not be used as the main fs for a system 2021-03-01 19:36:46 but ppl do it :( 2021-03-01 19:37:19 people do what they want 2021-03-01 19:38:17 and generally applications should gracefully degrade for that with warnings about unsafety where necessary (for example it might make transaction structure unsafe) 2021-03-01 19:38:23 rather than just erroring out and terminating 2021-03-01 19:38:48 In this case, they are explicitly just testing fallocate 2021-03-01 19:38:56 *nod* 2021-03-01 19:39:03 that seems like a pointless test tho 2021-03-01 19:39:22 if they want to test it they should run under a seccomp filter that lies that the syscall succeeded :-p 2021-03-01 19:39:31 so they can just see that their wrapper executes :-p 2021-03-01 19:40:20 Hmm, it's not just the testcode, it's the actual code that just calls unix.Fallocate without any fallback 2021-03-01 19:40:23 https://github.com/restic/restic/blob/master/internal/restorer/preallocate_linux.go 2021-03-01 19:41:18 Ok, but they allow it to fail 2021-03-01 19:41:38 https://github.com/restic/restic/blob/99228be623af153cd82e43ca07255b0505b76e71/internal/restorer/fileswriter.go#L67 2021-03-01 19:42:01 So they do expect EOPNOTSUPP 2021-03-01 19:42:30 But then that test makes no sense at all, like you said 2021-03-01 19:43:09 (kicad takes ages to compile) 2021-03-01 19:55:21 https://github.com/rapid7/metasploit-framework/pull/14833 I was bored 2021-03-01 20:09:28 jvoisin: I've created a confidential issue for it 2021-03-01 20:31:03 thanks ♥ 2021-03-01 21:28:03 maxice8: is there a reason you replace -buildmode=pie with -buildmode=exe for browserpass? 2021-03-01 21:28:53 anyway, it suffers the same issue when GOFLAGS is not defined 2021-03-01 22:31:50 sam_: or before that, suidperl 2021-03-01 22:35:23 ncopa / ikke / maxice8 / sam_: haserl must have root access for ACF to modify files owned by root and do lots of fancy admin stuff 2021-03-01 22:35:28 ikke, dalias: https://man7.org/linux/man-pages/man1/fallocate.1.html: Available since Linux 3.14 for ext4 (only for extent-based files) 2021-03-01 22:35:32 translation: not supported on ext3 2021-03-01 22:35:47 however, it does seem quite dangerous to give it suid by default 2021-03-01 22:35:47 Hello71: :D 2021-03-01 22:35:56 tdtrask: yeah, my suggestion is to neuter it by default and warn 2021-03-01 22:36:10 I'm open to suggestions to how to remove suid by default and still turn it on for ACF 2021-03-01 22:36:34 also https://man7.org/linux/man-pages/man5/ext4.5.html "extent: This ext4 feature allows [blah blah blah] a more efficient data structure than the traditional indirect block scheme used by the ext2 and ext3 file systems." 2021-03-01 22:37:03 the ACF install script will set up mini_httpd, but ACF also works with any web server that supports CGI 2021-03-01 22:37:37 ACTION doesn't know how to only give suid access to haserl if it's launched as a cgi script by a web server 2021-03-01 22:49:19 dalias: the runc fix is committed but needs to trickle down through containerd, then possibly docker, then possibly repositories 2021-03-01 22:51:17 yay 2021-03-02 06:26:17 Is there a minimal pep517-builder 2021-03-02 06:26:25 that doesn't need literally anything but pure python 2021-03-02 08:53:27 good morning 2021-03-02 08:53:36 morning 2021-03-02 08:53:39 Gm 2021-03-02 09:33:30 _0/ 2021-03-02 09:34:00 fcolista: I don't think my messages arrive in #alpine-commits, but CI doesn't catch it because there is no CI for armhf 2021-03-02 09:34:37 PureTryOut[m]2: they don't, for some reason 2021-03-02 09:38:27 PureTryOut[m]2, ah ok 2021-03-02 10:20:52 I'm looking at the python 3.9 upgrade now 2021-03-02 10:32:13 I see geoip is still in main. But it seems maxmind discontinued the data feed behind that a good while ago? 2021-03-02 11:14:52 ncopa: how can we limit access to haserl from just the web server binary? 2021-03-02 11:15:16 and prevent suid access when running from commandline? 2021-03-02 11:23:26 or not have it setuid in the first place :/ 2021-03-02 11:35:57 make a group containing only the user you want to give access to 2021-03-02 11:36:05 chgrp the binary to that group 2021-03-02 11:36:22 chmod it to 4750 2021-03-02 11:36:45 only members of that group will be able to run it 2021-03-02 11:37:26 if other users still need to run it but not suid, then you need a wrapper 2021-03-02 11:37:33 make the binary normal 0755 2021-03-02 11:38:25 write a small C wrapper belonging to useritmustrunas:groupthathasaccess that just execs into the binary, and make that wrapper 4750 2021-03-02 11:38:53 (C because suid is disabled for shell, typically - but you could also use execline, j/s :P) 2021-03-02 11:39:16 (uh no you couldn't, sorry, the protection is in the kernel, when there's a shebang the kernel won't do it) 2021-03-02 11:39:25 (so, C) 2021-03-02 11:40:06 the C wrapper thing is the same technique, IIRC, used by Alpine for busybox-suid 2021-03-02 11:40:25 although for different reasons: busybox-suid needs to be suid root but only for certain applets 2021-03-02 12:07:32 On alpine, ACF is the main (only?) user of haserl. A web server is used to load the file /usr/share/acf/www/cgi-bin/acf (via symlink from /var/www/), which starts with a haserl #! 2021-03-02 12:08:05 After reading the acf script, haserl will drop permissions to match the permissions of the acf file, which in this case is root. 2021-03-02 12:09:02 We could limit the access of haserl to only be able to read particular directories / files, rather than any file in the filesystem 2021-03-02 12:09:59 (in addition to only allowing haserl access to users in a new haserl group as skarnet suggested) 2021-03-02 12:10:01 tdtrask: you could also refuse to do anything as root 2021-03-02 12:10:54 ikke: ACF needs root access 2021-03-02 12:11:21 Does haserl need to read files as root? 2021-03-02 12:12:25 the /usr/share/acf/www/cgi-bin/acf script is owned by root and must run with root access 2021-03-02 12:12:42 but, it's launched by a web server, which is not running as root 2021-03-02 12:12:58 right, so it's basically a suid wrapper 2021-03-02 12:29:02 i think we may need to do multiple things. the real challenge is how to solve/work-around this without breaking stuff 2021-03-02 12:30:09 i think we cannot fix this without breaking stuff 2021-03-02 12:31:42 skarnet's idea is good, but it only limits the problem. adding a web server to the haserl group will let any web app be able to read anything on the filesystem via haserl 2021-03-02 12:31:54 but its still better than what we have now 2021-03-02 12:32:25 we could also limit the scripts/files that we allow haserl to read/execute 2021-03-02 12:32:52 and say, for example that haserl only allows scripts that are prefixed by /usr/share 2021-03-02 12:33:32 ncopa: if uid/gid isn't sufficient auth enough, then if you need to be safe you need crypto. :P 2021-03-02 12:38:10 ncopa: We can limit the security hole without breaking existing installations of ACF by simply limiting the directories visible via haserl 2021-03-02 12:38:45 we can go ahead and add a haserl group on edge 2021-03-02 12:42:22 or, how about only run haserl scripts as root if they are owned by haserl user or in haserl group? Then the admin can control which exact files can be run. 2021-03-02 14:24:05 Cogitri: what do you think about !18548? 2021-03-02 14:24:31 maxice8: !16881 can be merged 2021-03-02 14:43:00 oh, is this a working full replacement for pulse ?? 2021-03-02 14:44:39 Yup, pipewire is working pretty nicely 2021-03-02 14:45:18 PureTryOut[m]2: lgtm I suppose, I've been using pipewire on F34 for some time now (and it'll probably become the default pulse implementation for it too) 2021-03-02 14:46:16 dalias: yeah been using it as full replacement (with above MR) on my laptop for a while, works great 2021-03-02 14:47:00 excellent 2021-03-02 14:47:02 I'm just missing the network streaming option to use it on my desktop 2021-03-02 14:47:36 Cogitri: I'll merge it then 2021-03-02 14:47:49 !16881 gonna merge it soon, am eating 2021-03-02 14:49:07 👍️ 2021-03-02 15:16:20 maxice8: what was the issue with python 3.9 and pip? 2021-03-02 15:16:48 https://tpaste.us/K5mn 2021-03-02 15:16:51 don't think those are related 2021-03-02 15:17:18 oh, that is because new setuptools no longer use easy_install 2021-03-02 15:17:36 to silently install missing python modules 2021-03-02 15:17:54 I have a fix for that package, hold on 2021-03-02 15:18:24 part of !16881, 07b50ba2277d95150f2d1ebfa473ec845e7a609a 2021-03-02 15:18:27 so its py3-py that should be fixed, right? 2021-03-02 15:18:42 Yes, it's usage of setuptools_scm should be removed 2021-03-02 15:19:48 py3-py upstream is ok we should provide the missing modules that before were silently fetched 2021-03-02 15:21:56 PureTryOut[m]2: as i understand that commit, the setuptools_scm was only used to get the version? 2021-03-02 15:22:14 Yup, that is for every package that uses setuptools_scm 2021-03-02 15:22:28 I think the whole purpose of setuptools_scm is to get version via git 2021-03-02 15:22:34 It is yes 2021-03-02 15:22:44 "scm" = source control management I guess 2021-03-02 15:22:47 I don't know how they get it when they are in aports tree 2021-03-02 15:23:00 They don't, that's why it's usage should be removed 😉 2021-03-02 15:23:24 We should add GIT_CEILING_DIRECTORIES 2021-03-02 15:23:55 To abuild 2021-03-02 15:24:31 sounds like a good idea (if it does what i think it does) 2021-03-02 15:25:11 I think I've been testing it on my personal abuild 2021-03-02 15:26:17 I've added it around runpart 2021-03-02 15:33:16 ikke: planning on asking for a CVE for the haserl? 2021-03-02 16:12:20 jvoisin: I did suggest it 2021-03-02 20:08:58 just reading my inbox and from debian-security ML got mail about this https://www.debian.org/security/2021-GRUB-UEFI-SecureBoot/ 2021-03-02 20:09:34 though I noticed talks about that few days ago but didn't looked to details 2021-03-02 20:11:02 was also sent to oss-security 2021-03-02 21:23:42 hey, all! https://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/plasma-dialer-0.2-r0.apk gives BAD signature in apk. Can somebody purge the cache for that file? (how does that work again, some special curl command?) 2021-03-02 21:25:41 ollieparanoid[m]: 'curl -X PURGE url_of_apk' 2021-03-02 21:27:00 mps: thanks! 2021-03-02 21:27:29 in this case curl -X PURGE https://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/plasma-dialer-0.2-r0.apk 2021-03-02 21:27:37 I did it already 2021-03-02 21:30:07 yep, I also ran it. and it worked :> great! 2021-03-02 22:47:45 Hi! I read on the list that you are looking to publish official releases on different cloud providers. I happen to be employed by one of them, and I am trying to convince some people to contribute to the initiative 2021-03-02 22:49:29 Besides time, and resources, what do you need from contributors? Do you want to seed a gold image, or are you looking to build specifically tailored images? 2021-03-02 22:54:11 it would probably help if you said which one 2021-03-02 22:57:20 Fair enough: Azure 2021-03-02 22:58:37 I do have "some" bandwidth I can invest on contributing, but I think it would be better if a few more people can be involved 2021-03-02 23:04:14 there are some people working on cloud-init support. i think the plan is to have it done by 3.14 2021-03-02 23:05:51 Ariadne, mcrute, ncopa: ^ 2021-03-02 23:06:19 izaki: there is some information available on the mailing list archives: https://lists.alpinelinux.org/~alpine/devel 2021-03-02 23:06:33 i recommend searching for "azure" and "cloud-init" to start with 2021-03-02 23:06:44 I'll search for that and catch up 2021-03-02 23:11:02 All right, so I see the plan is supporting cloud-init on AWS AMIs first 2021-03-02 23:12:05 Without a doubt, that is the best path towards universal images 2021-03-03 00:02:42 tomorrow's news: MICROSOFT EMPLOYEE STRONGLY RECOMMENDS USING AWS 2021-03-03 00:03:11 oh, well, just cloud-init 2021-03-03 00:04:24 well either way lets make it happen 2021-03-03 00:04:35 i would love to be able to deploy alpine on azure 2021-03-03 00:04:58 though, i am more interested in internet2's federated openstack solution (NET+) 2021-03-03 00:06:11 I cannot speak for my employer, but I strongly recommend using Alpine Linux :D 2021-03-03 00:06:38 Ariadne, I have to read about that... I've had very bad experiences with OpenStack 2021-03-03 00:07:06 But that was a while ago 2021-03-03 00:08:07 not my problem :D 2021-03-03 00:08:42 Mmmm... Is it like a cloud coop? 2021-03-03 00:08:53 cooperative? 2021-03-03 00:09:01 well between grids at educational institutions 2021-03-03 00:09:05 nice 2021-03-03 00:09:13 I am all in for supporting something like that 2021-03-03 00:09:17 ACTION files 100 issues about alpine not working on  2021-03-03 00:09:38 ikke: hey can we disable hello71's bug reporting privileges ;) 2021-03-03 00:10:40 Ok, In any case, I would like to contribute to getting Alpine officially on Azure, and I am willing to look into getting resources from MS into helping out... Can't promise anything concrete, but I would love to help 2021-03-03 00:10:56 I do understand the strategy of getting cloud-init working first 2021-03-03 00:11:05 i think both can happen in parallel 2021-03-03 00:11:17 cloud-init is already working 2021-03-03 00:11:24 Fantastic (haven't tried) 2021-03-03 03:32:23 oh I'm lagging on reading IRC... yeah we're planning cloud-init for the 3.14 series images but I have not yet started actually integrating it yet 2021-03-03 03:32:33 have been backlogged on some unrelated things 2021-03-03 05:33:08 Ariadne: I'll just assign all the tickets to Hello71 :P 2021-03-03 08:18:38 good morning 2021-03-03 08:20:36 Morning 2021-03-03 08:20:49 izaki: welcome! this is great news! mcrute is taking care of the cloud stuff 2021-03-03 08:20:53 good morning (goede morgen, gutte morgen) 2021-03-03 09:12:10 goedemorgen 2021-03-03 09:17:12 Добро јутро 2021-03-03 09:18:06 god morgen 2021-03-03 09:28:35 ikke: \o/ 2021-03-03 09:48:29 wener[m]: I looked at moving usbip-utils to linux-tools, and I see it would probably require some 'smart ash hacks' 2021-03-03 09:49:16 beside this, looks like linux-tools APKBUILD deserve nearly complete rewrite 2021-03-03 09:51:21 but for now (at weekend) I will try to add tmon (thermal monitor) subpkg and see what is needed to refactor APKBUILD 2021-03-03 09:52:49 how does aarch64 & s390x differ from the rest wrt glob (I think?), I have a tor package test that will only fail for these two 2021-03-03 09:56:02 I could patch their src/test/test_util.c to remove that test for all arches, but it's curious that it'll fail for these specific two 2021-03-03 11:23:45 omni: no idea if there is a difference 2021-03-03 11:24:02 do you have an example of what is behaving differently? 2021-03-03 11:52:03 ikke: yes, this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18778/diffs#2cb156d3680dd0dceb95a1ce1103a515d890c74e 2021-03-03 11:54:40 logs from when I run 'make check' instead of 'make test' could be interesting too https://gitlab.alpinelinux.org/omni/aports/-/pipelines/74032 2021-03-03 11:54:58 as the memwipe test will only succeed on ppc64le 2021-03-03 14:18:38 mps: 👍, I hope I have time to do this 2021-03-03 14:20:08 can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18488 ? 2021-03-03 14:25:25 wener[m]: ok, no need to hurry 2021-03-03 14:26:12 jvoisin: what is this 'mathermost' chat system 2021-03-03 14:28:55 mps: https://mattermost.com/ 2021-03-03 14:29:03 jvoisin: btw, CODINGSTYLE says to use lower letters where possible, iirc. I see you removed 'A' at the start but changed 'f' to 'F' at the beginning on pkgdesc 2021-03-03 14:29:27 meh, the linter should warn about this :/ 2021-03-03 14:30:16 (fixed) 2021-03-03 14:30:27 heh 2021-03-03 14:30:41 btw, is the server open sourced? 2021-03-03 14:30:45 the rizin.re project is using it instead of irc/whatever/… 2021-03-03 14:30:47 yes 2021-03-03 14:31:13 ah, ok. then we can merge this MR 2021-03-03 14:32:05 lets wait yet another CI cycle :) 2021-03-03 14:35:44 omni: it should be broken on all arches 2021-03-03 14:36:17 I filed a MR upstream long ago but it was not accepted for this release 2021-03-03 14:37:16 jvoisin: merged 2021-03-03 14:38:22 mps: awesome ♥ 2021-03-03 14:40:22 np 2021-03-03 15:29:56 Hello71: that's the thing, it isn't broken on all archs.. 2021-03-03 15:33:05 Hello71: where can I find that MR? 2021-03-03 15:34:28 I'm having difficulty finding the support timeline for Alpine 3.10. How long will Alpine 3.10 be supported? How long does Alpine support each release? 2021-03-03 15:41:05 https://alpinelinux.org/releases/ 2021-03-03 15:43:48 omni: gitlab.torproject.org 2021-03-03 15:49:18 maxice8 Awesome!! Silly me, I was looking in the wiki and under support for that info. 2021-03-03 15:50:04 What's the best way to request a Python3.7 patch on Alpine 3.10? I'm looking for a patch to mitigate CVE-2021-3177. 2021-03-03 15:55:10 Hello71: yeah, I tried to search through MRs for your nick there but didn't find anything 2021-03-03 15:56:31 I think I'm alxu 2021-03-03 15:56:44 I'll try that 2021-03-03 15:57:05 nope 2021-03-03 16:03:04 NewDev9: looks like it has been fixed already: https://gitlab.alpinelinux.org/alpine/aports/-/commit/ff6a3d6ca05810dd091c545beb899031ade55833 2021-03-03 16:07:15 well, actually it was fixed in https://gitlab.alpinelinux.org/alpine/aports/-/commit/7691cb5e973b9b8023ba87bc4f87aa58b6ce9bb0 2021-03-03 16:09:56 algitbot Thank!! I think I found that before but I wasn't seeing python 3.7.10 in the 3.10 repo. Although, I just checked and it looks like it was built yesterday, https://pkgs.alpinelinux.org/packages?name=python3&branch=v3.10 2021-03-03 16:09:56 I'm going to rebuild and see if I'm good to go. Thanks everyone for the fantastic help!!! :-) 2021-03-03 16:36:36 comments on !17649 and !17647 ? 2021-03-03 20:18:24 i have dilemma about naming linux-tools subpkgs. just added tmon (thermal monitor) there and named it linux-tools-tmon 2021-03-03 20:18:46 not sure should we name it just tmon 2021-03-03 20:19:26 also, maybe we should rename cpupower subpkg to linux-tools-cpupower? 2021-03-03 20:20:19 opinions? 2021-03-03 20:21:13 These seems fairly stand-alone tools, I guess I would just call them 'cpupower' or 'tmon' 2021-03-03 20:21:42 hmm, we have linux-tools-gpio and linux-tools-iio 2021-03-03 20:21:49 yes, I see 2021-03-03 20:23:01 how then to name these two, gpio and iio doesn't look 'right' 2021-03-03 20:23:57 also, in queue is usbip 2021-03-03 20:24:18 probably more in near future 2021-03-03 20:27:45 New version of openssh released btw 2021-03-03 20:27:48 8.5 2021-03-03 20:28:33 why, current work just fine :) 2021-03-03 20:29:06 yeah, let's stop all development :P 2021-03-03 20:29:33 yes, and live in better (good enough) world 2021-03-03 20:36:15 mps: i mean it fixes a vulnerability for one 2021-03-03 20:36:27 but feel free to read the release notes 2021-03-03 20:36:30 :) 2021-03-03 20:38:11 sam_: mps is not being serious here :) 2021-03-03 20:38:28 oh! 2021-03-03 20:38:31 I was worried 2021-03-03 20:39:40 ikke: thanks for explanation :) 2021-03-03 20:44:22 ikke: !18961 :) 2021-03-03 21:32:24 ikke: if you are not went to sleep !18975 2021-03-03 21:32:41 does this subshell looks ok 2021-03-03 21:33:07 also, renamed tmon subpkg according your suggestion 2021-03-03 23:07:28 omni: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/249. i'll send a mail out soon if i remember 2021-03-03 23:10:01 Hello71: thanks! 2021-03-03 23:16:36 I don't know why I didn't find that when searching but I had seen it the other day, not reflecting it came from you 2021-03-03 23:17:32 these changes didn't solve for the tests on aarch64 and s390x, however 2021-03-03 23:18:01 oh, nice. 2021-03-03 23:19:43 Hello71: so I already did use your patch for test_util.c to pass tests on most archs 2021-03-03 23:23:12 and I added another patch, that I only apply for aarch64 and s390x, that remove the wildcard escaping test 2021-03-04 09:03:19 Morning 2021-03-04 09:04:49 good morning 2021-03-04 10:29:33 in nowadays times I come to conclusion that long term stable are not good idea anymore 2021-03-04 10:30:20 one year max 2021-03-04 10:33:47 From a packaging point of view, indeed. From a user point of view, I wish there were some decent 4-year life-cycle products. 2021-03-04 10:50:35 backporting and fixing outdated things takes too much time and effort, and is far from 'good'. not sure if that is good from users POV 2021-03-04 11:04:10 User's POV: devices are out somewhere, with limited connectivity, running some application. Upgrades beyond security/bug fixes occasionally break _something_. 2021-03-04 11:05:13 And in some cases, 'upgrade' means 're-certify'. Which is a 3 to 4 month, expensive, process. 2021-03-04 11:05:15 or device is on new shiny web site/gamebox ..... 2021-03-04 11:07:43 Anyway, I get annoyed when I have to upgrade lots of things that work perfectly well in that function, and that function will remain the same for the next couple of years, just for the sake of upgrading 2021-03-04 11:10:27 I quite well understand you and your reasoning 2021-03-04 11:11:27 but I'm talking from distro maintainers POV 2021-03-04 11:15:41 Indeed. And on any bug reports that come in to the distro and are forwarded to upstream, the first response is 'But you are not running $new.shiny. Please upgrade to $new.shiny and reproduce, before we even look at it' 2021-03-04 11:17:26 It doesn't help that upstreams are less and less caring about stable releases, making it harder for us to do so 2021-03-04 11:18:25 nobody wants to maintain things anymore 2021-03-04 11:18:31 most fast and breank things. 2021-03-04 11:20:47 Which works well at scale, with A/B testing and easy roll-backs, but not at all in custom one-off things 2021-03-04 11:36:23 nice, mips64 is green again 2021-03-04 11:37:36 yes, 'mister disable' :P 2021-03-04 11:38:42 I fixed a lot if things! 2021-03-04 11:38:49 of* 2021-03-04 11:38:55 sure 2021-03-04 11:38:57 jk 2021-03-04 11:39:01 :) 2021-03-04 11:41:02 ncopa: if you working on linux-lts 5.10.20 don't forget to consider ARCH_MESON for aarch64 (librelec cc board). I didn't seen wish/issue opened for that 2021-03-04 11:50:24 huh, these are really big updates for 5.10.20 and 5.11.3 2021-03-04 11:58:51 mps: ye WTF.... not ot mention they again touch drm stuff, maybe they will at least fix all those issues in 5.10 2021-03-04 12:13:37 MY-R: I doubt, all these GPUs are closed from us 2021-03-04 12:15:36 they are too precious for their 'owners' to give specifications in hand to a bunch of hackers 2021-03-04 12:23:11 mps: dont know but looking at https://gitlab.freedesktop.org/drm/intel/-/issues it looks like they working hard since year and pushing much more patches to kernel 2021-03-04 12:35:10 usually they become 'friendly' to open source when they loose on market 2021-03-04 12:38:30 that is good side effect :D 2021-03-04 20:13:00 what is use case for empty depends (depends="") in subpkgs? to not auto add other subpkgs in APKBUILD? 2021-03-04 20:15:47 maxice8: could you merge !16881? 2021-03-04 20:17:28 Thanks! 2021-03-04 20:33:05 welcome 2021-03-04 23:42:56 <[[sroracle]]> mps: yes 2021-03-04 23:43:18 <[[sroracle]]> well, to not include parent (origin) pkg $depends in subpkg 2021-03-04 23:43:55 <[[sroracle]]> since it defaults to inheriting (and it has been discussed more than once if that should remain the default, with no change made yet) 2021-03-05 07:57:12 [[sroracle]]: I thought so, thanks for confirming 2021-03-05 07:58:24 though it has some problems, which I have to look more why 2021-03-05 11:03:27 mps: is there any issue? couldnt find any details for ARCH_MESON 2021-03-05 11:13:17 ncopa: I think issue/wishlist isn't created 2021-03-05 11:14:40 difficult for me to follow up then 2021-03-05 11:15:00 heh 2021-03-05 11:16:04 this time i did check the issues and merge requests, but i forgot to check IRC so I didnt see your reminder til after I had pushed it 2021-03-05 11:16:05 sorry 2021-03-05 11:16:09 yesterday I enabled this on linux-edge, config-egde.aarch64 file, you can see git diff for this file there 2021-03-05 11:18:26 but I see you already upgraded -lts 2021-03-05 11:18:28 i dont think i will have time to follow up kernel today sorry. im working on the python 3.9 upgrade 2021-03-05 11:18:57 yeah, i didnt check my irc before I started on it. i did check the MRs/issues though 2021-03-05 11:19:40 if user ask again I'll point to linux-edge. I tried to ask 'him' before upgrade does that SOC need some more things but didn't got response 2021-03-05 11:20:22 so, I think this is not urgent 2021-03-05 11:21:32 now struggling with new dovecot release, again fail tests on 32bit arches 2021-03-05 11:34:49 py3-cffi testsuite fails 2021-03-05 11:36:28 oh... failures are ignored... 2021-03-05 11:57:31 built over 100 python 3.9 packages now 2021-03-05 12:28:43 'Error: No functional dcrypt backend found - skipping some tests: Couldn't load required plugin ../lib-dcrypt/.libs/libdcrypt_openssl.so: dlopen() failed: Error relocating /home/mps/aports/main/dovecot/src/dovecot-2.3.14/src/lib-ssl-iostream/.libs/libssl_iostream_openssl.so: ssl_iostream_context_unref: symbol not found' 2021-03-05 12:29:09 this is on armv7, dovecot check 2021-03-05 12:29:56 what could be cause of this? (it pass fine on x86_64) 2021-03-05 12:38:38 hmm, maybe this is not important 2021-03-05 12:56:02 can you try: ldd /home/mps/aports/main/dovecot/src/dovecot-2.3.14/src/lib-ssl-iostream/.libs/libssl_iostream_openssl.so 2021-03-05 12:59:02 a lot of 'symbol not found' 2021-03-05 13:00:46 for example Error relocating /home/mps/aports/main/dovecot/src/dovecot-2.3.14/src/lib-ssl-iostream/.libs/libssl_iostream_openssl.so: str_c: symbol not found 2021-03-05 13:06:25 ncopa: upstream posted patch to fix this, will test in about 30 mins 2021-03-05 13:15:28 mkinitfs repo missing on git.a.o 2021-03-05 13:16:21 nvm, missed there is second page 2021-03-05 13:16:36 still would be better to show all repos on a single page 2021-03-05 16:50:39 ncopa: got dovecot fixed, building in lxc (x86_64 and armv7) to see will it pass final test before merging 2021-03-05 22:57:20 how do I tell if the system is rebooting (vs shutting down) in an rc script running in the shutdown runlevel? openrc has a RC_REBOOT env var, but it's not being set presumably because init is *not* calling openrc's reboot 2021-03-05 22:58:00 so is there some other way to accomplish this without changing the init from busybox to openrc-init? 2021-03-05 23:00:12 inittab has a 'shutdown' action, but no corresponding one for reboot (I guess both reboot/shutdown are the same 'action' there?) 2021-03-05 23:04:15 something like this might work ":6::/sbin/openrc reboot", but busybox: "# : The runlevels field is completely ignored." ffs 2021-03-05 23:51:08 you could probably switch to openrc-init 2021-03-05 23:57:14 yeah that seems to be the 'simplest' way 2021-03-06 00:19:01 well that 'solves' that problem, but creates a few more problems :P 2021-03-06 00:20:42 what't the difference between reboot and shutdown other than the time before it comes back on 2021-03-06 00:21:32 Hello71: I need to run something only on shutdown, and *not* on reboot 2021-03-06 00:21:46 seems suspiciously like xy problem 2021-03-06 00:21:57 ok, you asked: 2021-03-06 00:22:16 what if you just alias the reboot command 2021-03-06 00:22:38 it's not like there's a standard way to reboot anyways 2021-03-06 00:23:55 the librem 5 has a 'ship mode' which powers off the battery controller so it doesn't drain when off, it cuts power after about a 10 second delay. if you do this when you're really rebooting (and not halting), the power to the device will be cut when it's booting back up. so it only needs to run on shutdown 2021-03-06 00:24:27 so, silly me for trying to use an openrc documented env variable for testing whether the system is rebooting 2021-03-06 00:26:19 yeah I guess making a /usr/local/bin/shutdown that just puts it in this mode, and then calls /sbin/shutdown might work. I don't know if other things (like elogind?) ultimately call shutdown, and that their paths are set up to use /usr/local first, and so on. the opportunity for it not working in practice is hugh 2021-03-06 00:26:36 s/hugh/high/ 2021-03-06 00:26:36 craftyguy meant to say: yeah I guess making a /usr/local/bin/shutdown that just puts it in this mode, and then calls /sbin/shutdown might work. I don't know if other things (like elogind?) ultimately call shutdown, and that their paths are set up to use /usr/local first, and so on. the opportunity for it not working in practice is high 2021-03-06 00:27:35 what if you use the shutdown command and then turn it back on within 10 seconds 2021-03-06 00:27:44 because you changed your mind 2021-03-06 00:27:54 it'll power back off 2021-03-06 00:28:10 this seems like barely papering over a bad design 2021-03-06 00:28:36 my point being that you probably shouldn't be too worried about finding the "perfect" solution because it's broken no matter what you do 2021-03-06 00:28:49 yeah, if you're always indecisive about whether or not you actually want to shutdown your system, then yeah. but ffs in reality how often do you actually think that'll happen? 2021-03-06 00:29:29 whereas, shutting down the system is far more likely to happen, and there are several popular mechanisms for doing it 2021-03-06 00:30:41 there's no other way to remotely portably contact init to shut down the system (i mean other than, like, poweroff and reboot and halt and telinit etc). you can call reboot(2) but that's not exactly clean even if it syncs the disks 2021-03-06 00:30:59 although i guess systemd-logind probably uses dbus 2021-03-06 00:31:57 yeah I'm not sure how elogind (in the case of alpine...) ultimately does shutdown/restart. I do know that it does cause openrc to run through the 'shutdown' runlevel. that's why I made this an init.d script for that runlevel 2021-03-06 00:32:36 but then quickly realized that RC_REBOOT isn't set alpine doesn't use openrc-init, etc etc, and here I am 2021-03-06 00:33:47 hmm, maybe I can increase the timeout for powering off that controller, then immediately cancel that timeout on boot (so in the case of a reboot, it won't get shut off. and a shitty design gets worse :D 2021-03-06 00:33:59 why doesn't it do that already 2021-03-06 00:34:05 or does the stock firmware do that and you just didn't port it 2021-03-06 00:34:57 ha. they use systemd. so it's trivial to detect if you're rebooting vs shutting down 2021-03-06 00:35:51 trivial in the systemd service which runs this 'enable the ship mode' thing, that is 2021-03-06 00:37:09 this ship mode thing is really useful. it means that the battery won't completely drain in ~2 days when the device is off. with the mode enabled, the battery charge can last weeks (or more) when it's off 2021-03-06 00:37:26 honestly it doesn't sound that bad if the device gives up if it's been booting for more than 10 seconds 2021-03-06 00:37:43 although it sounds like it makes it hard for debugging 2021-03-06 00:37:59 hopefully you can turn it off externally or in some pre-boot environment 2021-03-06 00:39:11 yeah debugging would be a problem, though powering it back on after it shut off would still work without any further timeout 2021-03-06 00:39:45 i see 2021-03-06 00:39:50 so debugging pre-kernel would be something like: 'shut down device, wait >10 seconds, power it on, and debug' 2021-03-06 00:40:18 that's annoying, but there are far, far more annoying things related to debugging on this device that something like that 2021-03-06 01:04:52 wow that just sounds like really broken hardware design 2021-03-06 01:04:59 same flaw as a lot of ups had (have?) 2021-03-06 01:05:22 there's a race condition between telling them to turn off and power coming back 2021-03-06 01:07:15 well, tbh, I'm not sure how else you'd design this thing so that the controller is powered off when it should be 2021-03-06 01:07:39 since it probably doesn't know the difference between 'halt' and 'reboot' 2021-03-06 01:23:57 well here the underlying power device (that soft powers off on most computers) should just do a hard power cut 2021-03-06 01:24:00 instead 2021-03-06 01:25:34 when you shutdown for poweroff, after reaching halted state kernel writes to some register (probably via some awful acpi thing or whatever) that switches the power supply (atx on desktop, for example) to just leave the standby active 2021-03-06 01:25:54 instead kernel should just be writing to whatever register completely shuts down the battery controller 2021-03-06 01:26:05 not "shut it down after 10 seconds" 2021-03-06 01:26:09 shut it down immediately 2021-03-06 02:08:28 yeah, well I didn't design the hardware. I just have it 2021-03-06 02:08:30 ¯\_(ツ)_/¯ 2021-03-06 02:34:02 :) 2021-03-06 02:48:05 dalias: but you gave me an idea, so I'll see if I can hook into the kernel shutdown stuff somehow from the charge controller drier 2021-03-06 02:48:08 *driver 2021-03-06 21:09:38 is Duncan Bellamy here? 2021-03-06 21:10:47 Haven't seen them 2021-03-06 21:11:41 ok, will continue with (bad) gitlab discussion then 2021-03-06 21:34:57 also, maybe try to change console in u-boot append cli params to 'console=ttyAMA0,115200n8' 2021-03-06 21:35:16 I think you meant to mention that in #alpine-linux? 2021-03-06 21:35:53 hmm, yes, thanks ikke 2021-03-06 21:36:09 (obviously I'm tired already) 2021-03-06 21:36:13 :) 2021-03-06 22:37:49 Last gcc commit make all upgrades in CI broken 2021-03-06 22:58:29 if a build failed for a certain arch, do you also need to bump the pkgrel when you fix it for that specific arch? 2021-03-06 22:58:43 omni: no 2021-03-06 22:58:51 andypost: hmm 2021-03-06 22:59:09 mps: ok, thanks 2021-03-06 22:59:55 andypost: strange, bad signature 2021-03-06 23:00:04 meh, I expected this with gcc (don't ask why, I will cease to answer) 2021-03-06 23:01:44 it's community/tor, that was fixed by KDaudt to build on mips64 but hasn't run again 2021-03-06 23:02:31 he also added the patch to ppc64le, that didn't need it in the CI 2021-03-06 23:02:56 and it doesn't seem to have been built for armv7 2021-03-06 23:03:02 perhaps it's just a matter of time 2021-03-06 23:03:35 pkgrel was not bumped 2021-03-06 23:03:41 omni: or restart builders 2021-03-06 23:04:18 amrv7 is stuck atm 2021-03-06 23:04:24 armv7* 2021-03-06 23:04:25 but mips64 is not listed on builds.a.o 2021-03-06 23:04:38 it is? 2021-03-06 23:04:46 hmm 2021-03-06 23:04:50 build-edge-mips64 2021-03-06 23:05:15 ahm yes 2021-03-06 23:07:25 I don't think I can restart the builders, can I? 2021-03-06 23:07:59 algitbot: retry master 2021-03-06 23:08:00 ikke: mps said pkgrel didn't need a bump in this case 2021-03-06 23:08:12 omni: That was regarding gcc 2021-03-06 23:08:43 omni: armv7 is stuck due to xtables-addons-lts 2021-03-06 23:08:48 huh, I didn't say anything about gcc... 2021-03-06 23:08:52 https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/pari/pari-2.13.1-r0.log 2021-03-06 23:08:56 omni: andypost did 2021-03-06 23:09:05 yeah 2021-03-06 23:09:16 that's what I was responding to 2021-03-06 23:09:21 not to you 2021-03-06 23:09:22 oh 2021-03-06 23:09:23 :AD 2021-03-06 23:09:32 ikke, thank you 2021-03-06 23:09:37 ACTION is unconfused 2021-03-06 23:09:59 +! 2021-03-07 07:03:38 ikke: maybe xtables-addons-lts build could be fixed by -Werror tweaking 2021-03-07 07:04:38 omni: ikke: now I'm confused :) 2021-03-07 07:05:25 pkgrel bump is not needed for fixes on pkg which failed build 2021-03-07 07:12:16 mps: right, I just thought that ikkes comment was directed at me and contraficted yours, but it wasn't and didn't 2021-03-07 07:24:11 omni: confusion/pkgrel: bump fixed :) 2021-03-07 07:59:27 I can't test xtables-addons-lts on lxc because it depends on linux-lts-dev 5.10.20 and it is not uploaded to mirrors 2021-03-07 09:32:23 I'm no emacs user, but shouldn't it be possible to build emacs-nox on all archs without depending on gtk (librsvg) and whatnot? 2021-03-07 10:09:53 does check() always need bash? 2021-03-07 10:10:11 hmm, not -Wno-error but s/unsigneg long/unsigned long long/ in few lines, in /extensions/pknock/xt_pknock.c 2021-03-07 10:10:25 for xtables-addons-lts, I mean 2021-03-07 10:11:35 omni: in general? no 2021-03-07 10:15:05 this https://tpaste.us/V7D1 fixes xtables-addons-lts on armv7, not sure will it work on other arches 2021-03-07 10:21:47 ikke: hmm.. but if you run ./thing in check()? 2021-03-07 10:22:00 omni: depends what ./thing does 2021-03-07 10:24:33 right, so it's not that check() need bash to run a binary like that 2021-03-07 10:25:00 correct 2021-03-07 10:25:09 an APKBUILD is a shell script itself 2021-03-07 10:25:22 which is run with `sh` (ash) 2021-03-07 10:25:39 ./foo just executes foo, whatever foo happens to be 2021-03-07 10:26:08 yeah, I wonder what's going on then, and why I need bash... 2021-03-07 10:26:37 If the shell script uses non-posix shell syntax (bashisms), then that could explain 2021-03-07 10:26:47 if the shebang line refers to bash, that could also explain 2021-03-07 10:26:53 no, it's a binary 2021-03-07 10:27:18 why do you think you need bash, then? 2021-03-07 10:27:19 and I've run strings and strace on it 2021-03-07 10:27:48 when I had options="!check" I didn't need bash 2021-03-07 10:28:10 does it do something to make in build()? 2021-03-07 10:29:12 because it almost seems like 'make test' is run somewhere when I allow check 2021-03-07 10:29:50 what APKBUILD? 2021-03-07 10:33:37 !18875 2021-03-07 10:34:42 I'm probably missing something obvious 2021-03-07 10:39:12 interesting, it builds without issue for me 2021-03-07 10:39:28 huh 2021-03-07 10:40:58 I mean, I'd expect it to 2021-03-07 10:43:49 Testing it in a clean docker container now 2021-03-07 10:45:35 bash not being found is not failing the build 2021-03-07 10:46:20 That happens in the build phase, but it still continues 2021-03-07 10:46:57 but in the clean docker container, check does fail 2021-03-07 10:47:52 omni: it works if I install coreutils 2021-03-07 10:48:12 So I guess add coreutils (instead of bash) to checkdepends 2021-03-07 11:07:03 ikke: thanks! I'll try that 2021-03-07 11:31:13 It worked 2021-03-07 12:00:18 yeah, thanks, I beleive it's ready 2021-03-07 12:01:13 Can you squash the fixup commits? 2021-03-07 12:02:22 already did, when you looked the other way ;) 2021-03-07 12:03:04 aha 2021-03-07 12:06:24 w8! *facepalm* 2021-03-07 12:07:09 no ocaml for mips 2021-03-07 12:07:18 :) 2021-03-07 12:07:21 I just commented on it 2021-03-07 12:11:44 there we go, I think 2021-03-07 12:20:39 https://gitlab.alpinelinux.org/omni/aports/-/jobs/340227#L44 2021-03-07 12:21:39 Ok, looks on purpose 2021-03-07 12:22:00 yeah 2021-03-07 12:31:00 https://gitlab.com/cryptsetup/cryptsetup/-/issues/627 careful before upgrading cryptsetup 2021-03-07 13:57:08 does that 'All users of the 5.11 kernel series must upgrade.' man ever sleep :) 2021-03-07 14:01:04 but this time he is serious, swap: fix swapfile read/write offset 2021-03-07 14:04:56 advice to all, don't use swapfile(s) on 5.10 and 5.11 till they are upgraded 2021-03-07 14:05:17 maybe even on 5.4 2021-03-07 14:06:21 yes 5.4 also 2021-03-07 14:07:28 "We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be..." 2021-03-07 16:08:54 do we have somewhere config switch to not do kernel postinstall on kernel installation? 2021-03-07 16:10:03 on builder/dev machines is quite annoying that it do full kernel 'setup' when building pkgs which depends on linux-xxx-dev 2021-03-07 19:20:46 hmmm, !19062 says that I aborted automerge, but I *didn't* 2021-03-07 19:39:59 someone merged in the meantime 2021-03-07 19:43:31 it;s not merged 2021-03-07 19:43:43 yes 2021-03-07 19:43:53 oh, that';s what you eman 2021-03-07 19:44:02 someone merged something else which caused the gitea merge to abort because automatic merges need to be against HEAD 2021-03-07 19:44:58 I thought so, but was not sure 2021-03-07 19:46:34 probably 'git push origin' when I pushed kernel 5.11.4 2021-03-08 07:34:55 good morning 2021-03-08 07:36:25 today im gonna update linux-lts/rpi and the continue on the python 3.9 rebuilds 2021-03-08 07:37:37 mps had an MR for xtables-addons-lts 2021-03-08 07:38:31 !19069 2021-03-08 07:38:53 good morning 2021-03-08 07:39:39 ikke: yes, but warning about casts on incompatible pointer types 'scares' me 2021-03-08 07:40:22 not sure what to do, and how this should be fixed 2021-03-08 07:40:49 did you report it upstream? 2021-03-08 07:41:40 I also wonder if we should backport the fix for cryptsetup: https://gitlab.com/cryptsetup/cryptsetup/-/issues/627 2021-03-08 07:41:46 no, would be nice before that to 'hear' someone who have good understanding of these pointers 2021-03-08 07:42:27 about casting these pointers* 2021-03-08 07:42:31 my thinking is that upstream have good understanding of those pointers 2021-03-08 07:42:44 aha, ok 2021-03-08 07:43:02 :) 2021-03-08 07:44:08 (wonder who invented these ambiguous types in C, long - how long it is :) ) 2021-03-08 07:48:04 moin 2021-03-08 08:27:09 my question from yesterday: do we have somewhere config switch to not do kernel postinstall on kernel installation? on builder/dev machines is quite annoying that it do full kernel 'setup' when building pkgs which depends on linux-xxx-dev 2021-03-08 15:10:17 heh, AMD named CPU using my name :) 2021-03-08 16:38:39 I have a few MRs not marked "WIP:", that I beleive are quite ready and just rebase on latest master now and then 2021-03-08 16:39:04 should I mention them here, one at a time, once in a while? 2021-03-08 16:39:34 that should work well I think 2021-03-08 16:42:28 I'll try with !18405 then =) 2021-03-08 16:47:52 !18981 (not mine) looks fine and would allow to close !16046 2021-03-08 18:44:18 can there be transitional packages that execute a "downgrade" of a package to a lower version number? !19106 2021-03-08 18:56:56 No, unless -a|--available is passed, apk will not automatically downgrade packages 2021-03-08 18:57:29 omni: not sure how that applies to that MR? 2021-03-08 18:57:46 ah, gems 2021-03-08 18:58:20 yeah 2021-03-08 19:05:25 I guess they preferrably should use their real version numbers, and to inform through release notes 2021-03-08 19:05:45 yes 2021-03-08 19:06:11 but it makes me wonder if the bundled gems shouldn't be packaged with their real version numbers too 2021-03-08 19:11:20 replied 2021-03-08 19:14:29 thanks 2021-03-08 21:34:20 We really need https://gitlab.com/gitlab-org/gitlab/-/issues/27955 😔 2021-03-08 21:45:02 Huh, MIPS joined RISC-V? https://archive.is/S1s80 2021-03-08 21:45:48 "MIPS is developing a new industry leading, standards-based, 8th-generation architecture, which will be based on the open-source RISC-V processor standard." 2021-03-08 22:13:42 heh, to confirm what I wrote few days ago, when they (big IT companies) loose on market they become open/free source friendly 2021-03-08 22:35:02 I sent bug report about xtables-addons to upstream, waiting for response (if it ever come) 2021-03-08 23:54:56 Hello! One of the programs I was packaging on a private repo does not have tags, how should I proceed? Should I just fetch the default master zip file and proceed from there? 2021-03-08 23:55:05 No package version whatsoever? 2021-03-09 02:28:03 eletrotupi, usually one can use a sha1 commit hash instead of "master" in the url 2021-03-09 02:29:40 some servers won't let you fetch by untagged hash 2021-03-09 08:27:13 Could somebody merge !19126? It is blocking a different MR from me 2021-03-09 08:33:52 PureTryOut[m]2: sure 2021-03-09 08:34:00 I forgot that 2021-03-09 08:34:25 Thanks! 2021-03-09 08:34:29 done 2021-03-09 08:34:48 thank you for doing that 2021-03-09 08:41:09 Np 2021-03-09 13:12:23 sh4rm4^bnc: nice 2021-03-09 13:12:29 thanks :) 2021-03-09 13:19:25 !18893 2021-03-09 18:07:46 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19147 2021-03-09 18:08:32 about pkgrel, need 'authoritative' stance 2021-03-09 18:19:10 I replied :) 2021-03-09 18:21:59 also I did :P 2021-03-09 18:26:10 wsinatra: https://build.alpinelinux.org/buildlogs/build-edge-x86/community/sbcl/sbcl-2.1.1-r0.log 2021-03-09 18:31:04 ikke: I forgot to say 'thank you' for nice explanation. thank you 2021-03-09 18:39:34 thank from my side as well 2021-03-09 18:39:39 on mps behalf 2021-03-09 18:41:08 thanks* 2021-03-09 18:45:24 oneinsect: namaste, namaste :) 2021-03-09 18:50:48 lol 2021-03-09 18:50:51 namaste 2021-03-09 18:51:23 job has kept me busy, will need to get back to my glibc builds of alpine soon and release to people 2021-03-09 18:51:27 long delayed 2021-03-09 18:52:40 ah man sb-concurrency is broken on x86 again? 2021-03-09 18:53:19 mps: thanks for the catch, I'll poke it and see why it doesn't want to be nice 2021-03-09 18:53:41 wsinatra: strange is that it passed on CI 2021-03-09 18:54:46 yeah I checked a while ago and didn't notice any failures. Really curious why it flagged it as successful 2021-03-09 18:55:00 "task failed successfully" I guess 2021-03-09 19:35:20 oh, git cve 2021-03-09 19:43:46 hm? 2021-03-09 19:43:50 what kind? 2021-03-09 19:44:36 https://github.blog/2021-03-09-git-clone-vulnerability-announced/ 2021-03-09 19:44:57 git clone on case-insensitive file systems with symlink support 2021-03-09 19:45:28 heh so windows-only 2021-03-09 19:45:56 and synology's patched kernels with their custom syscalls 2021-03-09 19:46:07 and modern ext4 and f2fs :P 2021-03-09 19:46:16 (though per directory) 2021-03-09 19:46:35 dalias: yes 2021-03-09 19:46:49 ericonr, play stupid games, win stupid prizes 2021-03-09 19:47:16 (setting a fundamentally broken, non-standards-conforming, option on your filesystem) 2021-03-09 19:47:34 it's funny you say that, because case-insensitive look up on ext4 was implemented because of wine 2021-03-09 19:48:01 from what I understand tho, they went to great lengths to be very UTF-8 aware/conformant 2021-03-09 19:48:34 i'm sure the support is rather large (in code size and attack surface) 2021-03-09 19:48:40 need to make sure it's off in kconfig.. 2021-03-09 19:49:05 iirc it uses a pre-compiled look up table 2021-03-09 19:49:17 I don't know actual sizes 2021-03-09 19:54:13 heh, intentionally I don't enable case-insensitive option for FS on kernel I build, expected something bad sooner or later 2021-03-09 19:55:07 (too much devs wants to 'convert' linux to windows) 2021-03-09 20:03:25 the idea of having this at the fs backend level rather than vfs is so broken, too 2021-03-09 20:03:57 heh, plan is to move this to vfs, afaik 2021-03-09 20:04:18 but i know why. it's because they do dir entry lookup in backend with specialized data structures specific to the fs 2021-03-09 20:04:52 ext4 and f2fs already use a mostly common layer, afaik. it's common infra that i believe is being used for fscrypt and possibly compression as well 2021-03-09 20:05:00 but it needs fs specific hooks anyway 2021-03-09 20:05:35 and at least the initial impl for ext4 had to record some stuff like the unicode version being used (?), so idk if that's implementable in the vfs layer 2021-03-09 20:05:52 >_< 2021-03-09 20:08:59 Marian[m]: are you Maribu (previous nick)? 2021-03-09 20:32:48 ericonr: ha. also zfs. 2021-03-09 20:38:13 @mps: Actually, my user name still is maribu. I just also configured my real name in my Matrix account. The IRC bridge seems to prefer that one over maribu 2021-03-09 20:38:50 https://summerofcode.withgoogle.com/organizations/ no Alpine linux :'( 2021-03-09 20:49:39 Marian[m]: ok, I thought so. Just wanted check before replying to your 'Thanks' in MRs 2021-03-09 20:50:55 Marian[m]: you provoke me with these 'Thanks' to answer you in MRs with same 'word', but it is easier to say this here: Thank you for your work 2021-03-09 20:52:03 jvoisin: this is good, why would alpine make relationship with google (or any big company) 2021-03-09 20:54:29 You're welcome. Being honest, I profit quite a lot from upstreaming packages I use anyway. The review process uncovers issues that would have bitten me and rebuilding against dependencies is often done by those updating the dependencies. 2021-03-09 21:23:41 [12:45:27] heh so windows-only 2021-03-09 21:23:43 macOS too 2021-03-09 21:43:17 and android 2021-03-09 21:43:42 and linux with case-insensitive enabled 2021-03-09 21:48:35 ariadne, eew, isn't that a newish option on mac tho? 2021-03-09 21:48:40 not mandatory 2021-03-09 21:49:18 anyway case-insensitive fs is not suitable for holding source trees 2021-03-09 21:49:24 they may have files that differ only in case 2021-03-09 22:00:26 dalias: apfs (iirc name) is case-insensitive 2021-03-09 23:36:39 nah, mac is historically case insensitive (since... long ago) 2021-03-09 23:37:00 but recently they added case sensitivity both for logic reasons and because some programs don't work with case insensitive (because logic) 2021-03-09 23:37:20 the problem is that some programs require case insensitivity (thus the recent linux move towards it) 2021-03-09 23:37:55 and i think the mac implementation required the whole filesystem to be either case-sensitive or case-insensitive. now i think they require each volume to be either one or the other, which is a decent improvement 2021-03-09 23:43:57 hello71, i thought since OSX is was case sensitive 2021-03-09 23:44:15 and they later added back case-insensitive mode on per-fs or per-dir granularity or something 2021-03-09 23:45:41 https://www.cnet.com/news/case-sensitive-hfs-and-the-risks-of-using-it/ says HFS was case insensitive, then jaguar added journaling, then panther made it on by default and also added case sensitive option (per-fs) 2021-03-09 23:45:57 but some software (particularly poorly written adobe software) requires case insensitivity 2021-03-09 23:46:08 which is fun when you format your filesystem case-sensitive and then have to reformat the whole thing 2021-03-09 23:46:21 ... 2021-03-09 23:46:41 how does this clownware have market share? *sigh* 2021-03-09 23:47:35 considering HFS dates back to 1985 i wouldn't blame apple too much here 2021-03-09 23:48:07 well unix had it right back then :-p 2021-03-09 23:48:30 but i mean making changes poorly scoped so that they break and require reformatting 2021-03-09 23:48:52 when they fixed it to support case-sensitive it shouldn't have been a global option if they weren't sure there wasn't broken software 2021-03-09 23:49:13 it should have been scoped either to dir or to application 2021-03-09 23:49:36 <[[sroracle]]> mmm 2021-03-09 23:49:49 <[[sroracle]]> in the future linux will have "case-insensitive FS" namespaces 2021-03-09 23:49:49 <[[sroracle]]> :p 2021-03-09 23:50:06 apparently adobe applications continue to require case insensitivity. and league of legends. and fortnite. and apparently enough steam games that it warns you 2021-03-09 23:50:36 i assume steam itself probaly works on case sensitive filesystems 2021-03-09 23:51:14 dalias: to your point, probably, but i'm not sure it solves that much, especially for unknowledgeable users, because the type of crappy software that won't work on case sensitive probably also dumps shit all over your system 2021-03-09 23:51:32 it's not like you can confine it to one shitty case insensitive area 2021-03-09 23:52:32 i dont think it can dump shit all over your system on mac 2021-03-09 23:52:36 bbut even if it could 2021-03-09 23:52:41 you can still scope it to app 2021-03-09 23:52:53 just giving legacy apps a case-insensitive view of a case-sensitive fs 2021-03-09 23:53:11 Hello71: steam does work fine on case sensitive fs, wine is the one to implement case insensitive lookup. the idea of putting it in kernel is speeding up the shitty applications 2021-03-09 23:53:30 :-p 2021-03-09 23:53:52 and yes, lots of software is like "create file named resource.json and load RESOURCE.json later" 2021-03-09 23:53:53 dalias: again... assuming they don't just spawn random garbage in the background? :p 2021-03-09 23:54:11 ericonr: allegedly steam warns/blocks you if installing on case-sensitive on mac 2021-03-09 23:54:57 oh, interesting. I don't know how it works on that side, I only know it kinda works on linux (besides being a terrible chromium-based application) 2021-03-09 23:59:21 well presumably something ported straight to linux should work, and everything else runs in wine which obviously handles it 2021-03-09 23:59:46 but "ported to mac" could mean "ported to mac properly" or "ported to shitty mac" and it's too much work for valve to figure out which one it is 2021-03-10 00:00:32 not that i think cef is a good design 2021-03-10 00:09:23 where is maxice8 2021-03-10 00:11:19 the change to alpine-baselayout broke every shell 2021-03-10 00:11:32 sigh 2021-03-10 00:13:31 ? 2021-03-10 00:13:31 i wish we would not do things because some webpage on the internet tells us to do them 2021-03-10 00:13:49 what is this? 2021-03-10 00:13:52 alpine-baselayout 3.2.0-r9 removes the `export PS1=` line, and now my bash shells are `bash-5.2$` 2021-03-10 00:14:10 instead of hostname:~$ 2021-03-10 00:14:13 heh 2021-03-10 00:14:21 because mirbsd says to not export PS1 2021-03-10 00:14:24 well that's not quite "broke every shell" :) 2021-03-10 00:14:29 it broke zsh too 2021-03-10 00:14:34 and ash 2021-03-10 00:14:37 well it made them look ugly 2021-03-10 00:14:49 i dont use system default PS1 etc anyway 2021-03-10 00:14:53 yes 2021-03-10 00:14:59 have them in my .profile/.env 2021-03-10 00:15:10 but i can see how it's annoying 2021-03-10 00:15:12 well, either way, somebody did something to solve a non-bug 2021-03-10 00:15:18 and created a bug in the process 2021-03-10 00:15:22 and mir is wrong, it should of course be exported 2021-03-10 00:15:39 why? 2021-03-10 00:15:48 what should happen is that /etc/mkshrc sets a valid PS1 for mksh after processing /etc/profile 2021-03-10 00:16:09 hello71, so that your preferred shell format propagates 2021-03-10 00:16:24 i agree it should not be exported, if nothing else than because it wastes space, but also because you may use a different shell from the system default 2021-03-10 00:16:41 pushing 3.2.0-r10 to revert that shit 2021-03-10 00:16:56 Hello71: great 2021-03-10 00:17:18 Hello71: you can go fix every single shell to have a reasonable default then 2021-03-10 00:17:56 i thought modern bash ships with a better PS1 /etc/bashrc or whatever 2021-03-10 00:18:00 or is it still distro-specific 2021-03-10 00:18:07 if it's not exported then shells invoked not as login shells will not have it set 2021-03-10 00:18:18 and will print their default prompt 2021-03-10 00:18:25 in this case, it was not being set at all 2021-03-10 00:18:34 ... unless you set it in a system-wide rc file, which is how it should work in the first place? 2021-03-10 00:18:35 so that is even worse than just not exporting it 2021-03-10 00:18:37 well if it's set but not exported that will happen 2021-03-10 00:18:43 hello71, ?? 2021-03-10 00:18:47 Hello71: that's what alpine-baselayout does, please just stop 2021-03-10 00:19:00 bash_profile != bashrc 2021-03-10 00:19:07 hello71, exactly 2021-03-10 00:19:12 that's why it needs to be exported 2021-03-10 00:19:22 many shells only read /etc/profile 2021-03-10 00:19:24 because it needs to be set only in .profile not .bashrc 2021-03-10 00:19:31 and ~/.profile 2021-03-10 00:19:34 my point is you should set it in bashrc not export it in bash_profile. that is more semantically correct 2021-03-10 00:19:38 no it's wrong 2021-03-10 00:19:40 there is no /etc/bashrc equivalent for ash, for example 2021-03-10 00:19:43 but ash doesn't read .shrc or .ashrc 2021-03-10 00:19:47 ariadne, there is, in posix 2021-03-10 00:19:48 or /etc/shrc or whatever 2021-03-10 00:19:53 but it's wrong to set PS1 there 2021-03-10 00:20:03 you want subshells to inherit the PS1 you set manually 2021-03-10 00:20:14 anyway, default PS1 is appropriate in /etc/profile 2021-03-10 00:20:15 not reset to your login default 2021-03-10 00:20:32 i am guessing our default PS1 is broken for mksh 2021-03-10 00:20:41 in which case, it makes sense to improve that 2021-03-10 00:20:47 that's why you put it in your login shell settings (.profile) not your auto-run for all shells 2021-03-10 00:20:48 not get rid of default PS1 entirely 2021-03-10 00:21:16 ariadne, yes, default PS1 should be pure bourne syntax 2021-03-10 00:21:33 "\h:\w\$ " 2021-03-10 00:21:36 to ensure it works with any shell 2021-03-10 00:21:37 should be pure bourne syntax 2021-03-10 00:21:39 should it not? 2021-03-10 00:21:39 yes 2021-03-10 00:21:58 $ PS1="\h:\w\$ " 2021-03-10 00:21:58 \h:\w$ 2021-03-10 00:22:00 woof 2021-03-10 00:22:15 lol is that mksh? :) 2021-03-10 00:22:32 this is how every system has worked since the dawn of time. if mir wants to insist you do it differently, everyone can ignore mir 2021-03-10 00:22:34 i mean it should be ' but that's unrelated 2021-03-10 00:23:54 i do not think mksh even reads /etc/profile 2021-03-10 00:24:41 oh, it does. 2021-03-10 00:25:25 well, either way, the solution is not to kill PS1 2021-03-10 00:25:30 winners use yash 2021-03-10 00:25:59 PS1='${USER:=$(id -un)}'"@${HOSTNAME:=$(hostname)}:\$PWD $( 2021-03-10 00:25:59 if (( USER_ID )); then print \$; else print \#; fi) " 2021-03-10 00:26:03 they recommend *this* 2021-03-10 00:27:01 if it's just about busybox ash then we could export ENV=$HOME/.env or something, except that still breaks mksh 2021-03-10 00:27:25 it's about bash and ash and even zsh 2021-03-10 00:27:34 honestly i am half tempted to just rm mksh 2021-03-10 00:27:36 from aports 2021-03-10 00:27:49 that would be antisocial though 2021-03-10 00:28:05 wouldn't it make more sense to ship default rc files for bash and zsh? 2021-03-10 00:29:41 but less crazy than e.g. gentoo's, just set a basic PS1 and maybe source /etc/bash/bashrc.d/* 2021-03-10 00:30:01 that does not fix zsh 2021-03-10 00:31:14 and zsh 2021-03-10 00:31:36 although zsh needs its own PS1 anyway 2021-03-10 00:31:44 let me put it this way: does any other distro export PS1 2021-03-10 00:31:47 yes 2021-03-10 00:32:00 debian, gentoo, redhat, suse 2021-03-10 00:32:03 all export PS1 2021-03-10 00:32:08 ??? 2021-03-10 00:32:35 all ***set*** PS1. that's not the same as *export*. 2021-03-10 00:33:31 oh, yes 2021-03-10 00:33:36 well either way you are missing the point 2021-03-10 00:33:42 -r9 removed setting it at all 2021-03-10 00:34:13 which is not the correct solution 2021-03-10 00:34:24 probably 2021-03-10 00:34:36 or at least not exclusively 2021-03-10 00:34:56 its not the correct solution at all 2021-03-10 00:36:24 hello71, i already explained why it needs to be exported not set 2021-03-10 00:36:27 well it should be removed. in conjunction with adding bashrc and zshrc files. 2021-03-10 00:36:39 and why it belongs in profile not bashrc 2021-03-10 00:36:50 putting it in bashrc is hostile because it overrides your session setting 2021-03-10 00:37:09 how about this 2021-03-10 00:37:14 for example suppose i have a screen window or xterm where I did PS1=something_else because i need a different form for the work i'm doing in that window 2021-03-10 00:37:25 (e.g. dir names are too long or something and i just want last component) 2021-03-10 00:37:29 so i export a changed PS1 2021-03-10 00:37:33 i'll just mark alpine-baselayout restricted, and anyone who wants to "fix" this problem can go through the process of convincing the entire core team it is acceptable 2021-03-10 00:37:35 and then you start nested shells? that are not through sudo (which obviously ignores your PS1)? 2021-03-10 00:37:36 :D 2021-03-10 00:37:47 yes 2021-03-10 00:37:50 then i start nested shells 2021-03-10 00:38:14 and i am pissed as fuck if that undoes my PS1 because mksh misbehaves and someone was trying to work around mksh being awful 2021-03-10 00:38:36 anyway. i wonder how we can detect broken shells 2021-03-10 00:38:41 so that we can give them a nicer PS1 2021-03-10 00:38:44 this seems like an unusual use case that doesn't justify polluting the PS1 for everybody else in a manner that's incompatible with custom shells 2021-03-10 00:38:47 system default bashrc/etc. (non-login shell rc files) should not set my PS1 2021-03-10 00:38:54 how does your system work if you export PS1 for zsh and then start a bash 2021-03-10 00:39:08 i don't do that 2021-03-10 00:39:15 Hello71: that's really going into "doctor, it hurts when i do that" territory 2021-03-10 00:39:21 and PS1 should only have normal bourne compatible shell prompt formats 2021-03-10 00:39:29 if you're going to make a shell that does its own incompatible thing 2021-03-10 00:39:34 it should use its own env var 2021-03-10 00:39:38 not hijack PS1 for that 2021-03-10 00:39:51 but i dont use zsh 2021-03-10 00:39:51 Ariadne: that's what dalias is doing. it only works in the case where you want to start a shell, then manually start nested shells, that are of the same type, and not using sudo/doas/pkexec/whatever 2021-03-10 00:40:02 thats literally what i do too 2021-03-10 00:40:06 and numerous other alpine users 2021-03-10 00:40:10 yes 2021-03-10 00:40:18 because this is the way it's worked on every unix since the beginning of time 2021-03-10 00:40:33 and there's no reason to break it 2021-03-10 00:40:45 then let's return to my question of "which other distros export PS1 and don't set it in per-shell settings" 2021-03-10 00:41:17 well, in traditional unix, the default is just compiled in usually 2021-03-10 00:41:57 debian seems to do both :/ 2021-03-10 00:42:00 but alpine has done this export PS1 for the past 15 years 2021-03-10 00:42:04 setting it in profile and bashrc 2021-03-10 00:43:34 can we move onto the more productive question of "how can we detect broken shells" ? 2021-03-10 00:43:56 i would like to not give mksh a broken PS1 2021-03-10 00:44:04 while ensuring bourne-compatible shells get a correct PS1 2021-03-10 00:44:13 can mksh just have its own profile/mkshrc that sets it? 2021-03-10 00:45:18 easy, set it in per-interactive shell settings. problem solved, and it's the way everyone else does it, so presumably it's at least not entirely broken 2021-03-10 00:45:38 i'm not saying it works in every case but neither does any alternative plan 2021-03-10 00:45:40 you can do that just for mksh 2021-03-10 00:50:05 yes, /etc/mkshrc 2021-03-10 00:51:56 hmm but mksh does not actually read this file 2021-03-10 00:52:00 how annoying 2021-03-10 00:55:34 anyway, i would prefer if we do not take actions based on what a random website says to do 2021-03-10 00:55:42 without actually testing to see the effects 2021-03-10 00:57:29 yes 2021-03-10 00:57:52 this is a policy change that deserves proper review and room for ppl to express disagreement 2021-03-10 00:58:24 i reverted and reopened the original bug. people can voice their opinion of what is an appropriate outcome there 2021-03-10 00:58:34 #12398 2021-03-10 01:02:27 please feel free to comment on that bug 2021-03-10 01:11:37 done 2021-03-10 07:59:11 morning. I have built main with python 3.9. starting with community now. 2021-03-10 08:03:59 Can anybody look into the xtables-addons-lts build failure on the armv7 builder? 2021-03-10 08:09:39 PureTryOut[m]2: I created patch and MR, and posted bug report upstream, https://www.spinics.net/lists/netfilter-devel/msg70467.html 2021-03-10 08:09:52 Ah good work! 2021-03-10 08:09:56 didn't got answer, yet 2021-03-10 08:10:30 !19069 2021-03-10 08:11:47 oh, right. i should probably have a look at that today 2021-03-10 08:13:31 what is weird is that this is kernel modules, so musl should not be involved at all 2021-03-10 08:14:45 this looks like some time calculations issue in source (I didn't dived deep) and probably use some code from libc for this 2021-03-10 08:16:09 interesting (and at the same time confusing) is that it builds on x86 without issue 2021-03-10 08:16:27 which is also 32bit 2021-03-10 08:25:55 And armhf? 2021-03-10 08:26:55 ikke: oh, yes. I didn't looked at armhf 2021-03-10 10:06:11 ikke: did xtables-addons-lts passed on armhf builder? how can I check this? 2021-03-10 10:43:14 ikke: this explains 'arch="all !armhf !mips64"' 2021-03-10 10:43:43 Ah 2021-03-10 11:24:54 PureTryOut[m]2: gwenview is failing 2021-03-10 11:39:29 ncopa: I think the return type of this function changed upstream 2021-03-10 11:45:10 ikke: yeah I noticed, will do something about it in a bit 2021-03-10 11:45:30 thanks 2021-03-10 11:50:38 Hello71: maybe. but i think the problem is that xtables-addons recently started to use do_div(x, 60) instead of x / 60 2021-03-10 11:51:30 mps: i pushed fix. I used uint64_t which is expected by do_div. tested on armv7, x86 and x86_64 2021-03-10 11:51:51 the ktime_get_seconds returns time64_t 2021-03-10 11:52:04 i tried to use time64_t but it gave type warnings 2021-03-10 11:52:22 1c1ea2256dbf14f2e9a5d5ec01657cb3b5438056 2021-03-10 11:53:19 mps: if you want you can follow up with upstream, showing how we fixed it in alpine ^^^ 2021-03-10 11:54:07 ncopa: I don't see difference between uint64_t and unsigned long long, so not important for me. and also I prefer clean and unambiguos type names so uint64_t is ok 2021-03-10 11:55:03 i thikn unsigned long long may be different on different architectures, while uint64_t is always 64 bit 2021-03-10 11:55:36 will see (wait some time) will upstream answer to my bug report first 2021-03-10 11:55:54 ncopa: yes 2021-03-10 11:57:30 ncopa: 2021-03-08 08:44............. mps| (wonder who invented these ambiguous types in C, long - how long it is :) ) 2021-03-10 13:02:01 always use uint*_t because C types are just... ew 2021-03-10 13:02:28 'long' means 'native pointer length' 2021-03-10 13:02:49 long long means 'the longest type we have' 2021-03-10 13:03:03 which is 64 bits for now but may be 128 in the future on some archs 2021-03-10 13:04:01 C types are meant to be optimized for the architecture it's running on, which makes sense from a "portable asm" pov but isn't programmer-friendly 2021-03-10 13:04:14 uint*_t types are a lot more programmer-friendly 2021-03-10 13:04:14 :) I suggest you don't try to write windows code with those assumptions of C 2021-03-10 13:04:29 windows doesn't exist 2021-03-10 13:04:29 long is 32 bits in 64bit Windows for compatibility reasons 2021-03-10 13:04:46 POSIX is the standard which expects long to be the native pointer width 2021-03-10 13:05:26 if I cared about windows I would be a glazier, not a programmer 2021-03-10 13:17:20 skarnet: you nicely wrote this, and that is what I also think and feel 2021-03-10 13:17:51 (I'm bad at writing in english) 2021-03-10 14:25:26 POSIX is the standard which expects long to be the native pointer width 2021-03-10 14:25:29 this is false 2021-03-10 14:26:36 there's no reason to equate long and "native pointer width" other than historical wrong C programming practices 2021-03-10 14:26:58 if pointers are representable as any integer type, that's uintptr_t. if it's not defined then they are not representable as such at all 2021-03-10 14:27:35 uintptr_t is not a C native type. :P 2021-03-10 14:27:44 it's part of the c language 2021-03-10 14:28:49 I wasn't passing comment on how right POSIX was 2021-03-10 14:29:03 andyhhp__, posix makes no such expectation 2021-03-10 14:29:18 the claim that it does is just false 2021-03-10 14:29:24 uint*_t are also part of the C language, we were talking about 'native types' as understood by the compiler 2021-03-10 14:29:51 if you take the C language in its globality there's basically never any reason to use the native types 2021-03-10 14:30:12 (which is probably close to the truth) 2021-03-10 14:33:19 yeah that's fairly close to the truth 2021-03-10 14:40:27 hi guys, I'm intereseted in maintaining some packages, how does it work in alpine? 2021-03-10 14:40:55 JuniorJPDJ: welcome 2021-03-10 14:40:56 just MRing packages to aports on gitlab is all? 2021-03-10 14:41:02 Yes 2021-03-10 14:41:23 any flag notifications maybe? 2021-03-10 14:41:24 Start packages in testing/ 2021-03-10 14:41:33 or other things making everything easier 2021-03-10 14:42:17 also, how does takeover of package work here? oh-my-zsh seems abandoned and someone stated it in issue I created 2021-03-10 14:42:20 I could take it 2021-03-10 14:43:28 You could first try to send an email to the current maintainer 2021-03-10 14:48:25 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12507 2021-03-10 14:48:39 "The maintainer has not been active for a couple of years either." 2021-03-10 15:50:30 that package is in teting 2021-03-10 15:51:33 JuniorJPDJ: give it a go, people will comment on your MR if there's anything and eventually merge 2021-03-10 15:52:29 the APKBUILD Reference on the wiki is quite good https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2021-03-10 15:57:19 omni: thanks ;) 2021-03-10 16:03:38 JuniorJPDJ: it depends on testing/powerline-extra-symbols and that looks kinda dated too 2021-03-10 16:04:09 they look easy enough to get started 2021-03-10 16:06:01 JuniorJPDJ: they would probably go as two separate commits in the same mr "testing/oh-my-zsh: upgrade to 0_git" and "testing/powerline-extra-symbols: upgrade to 0_git" 2021-03-10 16:14:31 do I need to enable testing repo to be able to install apps from there or what? 2021-03-10 16:14:44 yes 2021-03-10 16:15:10 And note that testing is only available for edge 2021-03-10 16:20:06 should I do this commits in separate MRs or in one is good? 2021-03-10 16:21:54 JuniorJPDJ: for those two, one commit per aport, but I'd say both the MR for oh-my-zsh since it depend on the other 2021-03-10 16:24:05 should I change maintainer to me? 2021-03-10 16:54:15 done: !19176 2021-03-10 19:43:04 I noticed that when flagging a package as out of date there's a "leave a message to the developer" field. Is it possible for me, as a maintainer, to see these messages and/or be notified when someone flags one of my packages as out of date? 2021-03-10 19:44:21 You should receive an e-mail for this 2021-03-10 19:44:31 sent to the address you specified in the maintainer filed 2021-03-10 19:44:34 field* 2021-03-10 19:45:29 what address would that have been sent from? 2021-03-10 19:47:30 pkgs@alpinelinux.org 2021-03-10 19:48:29 weird, it doesn't look like I received an email 2021-03-10 19:48:50 I can't find any emails from that sender 2021-03-10 19:49:19 (and yes, I'm checking the email specified in the author field) 2021-03-10 19:50:34 I have no idea, I have received them, even recently 2021-03-10 19:50:45 curious 2021-03-10 19:50:52 Last one is Feb 27th 2021-03-10 19:54:09 if I want my script to run when someone installs my package i need both, post-install and post-upgrade? or is there any script which will run when other is not present? 2021-03-10 20:02:07 and also when setting maintainer and contributor i need to use my full legal name or I can just write "JuniorJPDJ"? 2021-03-10 20:03:10 JuniorJPDJ: not required but I trust more to people with real name (my personal POV) 2021-03-10 20:03:53 trust as in? 2021-03-10 20:04:13 well, however ... 2021-03-10 20:04:54 why anyone who want to work on distro which is widely used have to hide 2021-03-10 20:05:39 is that a rhetorical question? 2021-03-10 20:06:18 rhetorical in modern understanding but not in original Aristotles idea 2021-03-10 20:07:36 How would you word it? 2021-03-10 20:07:46 what? 2021-03-10 20:10:42 I understood it as you seeing the way I used "rhetorical question" as a modern misinterpretation of Aristotle's idea of it, but perhaps I misunderstood you 2021-03-10 20:11:18 Either way this is off-topic so I digress 2021-03-10 20:11:28 aha, understand now 2021-03-10 20:11:42 it is not OT, imo 2021-03-10 20:12:34 If you don't see it as off-topic I would like to hear your thoughts 2021-03-10 20:12:40 (if you have any further ones) 2021-03-10 20:12:50 for example debian requires for maintainers to be identified by some 'real' proof 2021-03-10 20:13:19 the infamous keysigning stuff? 2021-03-10 20:13:35 one of methods 2021-03-10 20:14:55 would you trust distro (alpine) if person who signs releases (current BDFL) is not known by real name 2021-03-10 20:15:03 I think I get what you mean now. As in, someone anonymous would be more likely to have malicious intent? 2021-03-10 20:15:29 not necessarilly 2021-03-10 20:15:30 as in someone with malicious intent would want to hide who they are presumably 2021-03-10 20:16:00 fair point about the BDFL thing 2021-03-10 20:16:12 even people with well known real names can make malicious change 2021-03-10 20:16:45 and there could be good reason for someone to not give real name 2021-03-10 20:17:06 yes, true 2021-03-10 20:17:22 for example working for big company/government/spy agency etc... 2021-03-10 20:17:54 If people know each other that should be enough trust 2021-03-10 20:18:34 does it help you if a commiters name sounds real instead of John Doe? 2021-03-10 20:18:42 I don't think the Alpine maintainers know me 2021-03-10 20:18:59 and I do contribute 2021-03-10 20:19:23 well, that is natural perception (imo) that people have more trust to people who don't hide themselves behind nick/alias 2021-03-10 20:21:04 Newbyte: you can notice that I wrote to JuniorJPDJ 'not required but I trust more ...' 2021-03-10 20:21:10 In FreeBSD world we have a similar situation and every commit goes thru a committer that is well known within the project but there is no real name policy and contributors can be fully anonymous but need to be able to create a bug ticket 2021-03-10 20:22:22 decke[m]: alpine also don't have 'real name' policy 2021-03-10 20:23:13 if I want my script to run when someone installs my package i need both, post-install and post-upgrade? or is there any script which will run when other is not present? 2021-03-10 20:23:16 mps: yeah I know, most projects don't have it which is good I think 2021-03-10 20:23:28 maybe I'm too old 'fashioned' only 2021-03-10 20:24:06 JuniorJPDJ_: only installs or also upgrades to a new version of? 2021-03-10 20:25:33 I'm asking about both in one script 2021-03-10 20:25:34 JuniorJPDJ: you can read APKBUILD man page, there is something about these scripts 2021-03-10 20:25:43 not initial-install, not only-upgrade 2021-03-10 20:27:18 mps: I'm reading APKBUILD reference on alpine wiki and it doesn't answer my question 2021-03-10 20:27:50 btw, when I joined alpine I intentionally wrote my real name, though I first thought to use pseudonym 2021-03-10 20:28:43 JuniorJPDJ: not sure is the wiki good enough as reference guide 2021-03-10 20:29:23 but I didn't looked at it for long time, so don't know 2021-03-10 20:36:04 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#.24pkgname.post-install 2021-03-10 20:37:10 You should be able to create a symlink from one to the other 2021-03-10 20:37:16 I saw that 2021-03-10 20:37:32 btw, when I joined alpine I intentionally wrote my real name, though I first thought to use pseudonym 2021-03-10 20:37:35 oh, symlink seems to be good idea 2021-03-10 20:37:50 there are a sufficient number of dangerous mentally ill people online that this is the safe thing to do 2021-03-10 20:39:03 tehcloud: :) 2021-03-10 20:39:15 JuniorJPDJ: Just as a general advise, these post-install scripts should not make significant changes to the system 2021-03-10 20:40:11 they run as root, so 'rm -rf /' is forbidden :D 2021-03-10 20:40:17 ikke: I just want to show message - I'm basing on arch PKGBUILD for my new APKBUILD 2021-03-10 20:40:24 mps: xDDD 2021-03-10 20:40:49 JuniorJPDJ: alpine dislike showing messages on install/deinstall 2021-03-10 20:40:52 Just to give an example: pre-install scripts can be used to create users to make sure files / directories can be owned by that user, but starting services post-install for example is against policy 2021-03-10 20:41:41 mps: oh.. how to handle that then? I'm packaging powerline10k zsh theme and using it needs user interaction 2021-03-10 20:42:14 oh-my-zsh package which I updated today also shows message in alpine 2021-03-10 20:42:18 I don't know that any alpine pkg have this 2021-03-10 20:42:19 in similar purpose 2021-03-10 20:42:28 some packages do it, but we generally advise against it 2021-03-10 20:43:56 long time I thought to add message for iwd upgrade when upstream make significant change in config file, but ceased and added comment to new config file 2021-03-10 20:45:41 and I'm not against adding this as option but I follow 'policy' 2021-03-10 21:09:18 JuniorJPDJ: using it needs user interaction, but not installing, right? you'd generally install it as root and not your user anyway 2021-03-10 21:10:04 it's hard to tell when installing ends for me 2021-03-10 21:10:29 I'm talking about file like this: https://aur.archlinux.org/cgit/aur.git/tree/zsh-theme-powerlevel10k.install?h=zsh-theme-powerlevel10k-git 2021-03-10 21:13:09 I found more than one packages doing thing I want to do and in similar situation 2021-03-10 21:13:20 eg. when user is needed to be in some group to use something 2021-03-10 21:15:37 I don't think you should need to print messages like that on install, the user should be able to find out how to use the packaged file through the project url, package-docs if installed, and what files the package installed with help of 'apk info -L ' 2021-03-10 21:18:11 ok, I will not then 2021-03-10 22:12:51 should old libhandy be dropped? should libhandy1 be renamed libhandy? 2021-03-10 22:15:55 No 2021-03-10 22:16:16 It's a separate package for a reason, the API isn't compatible and not everything has switched yet 2021-03-10 22:29:10 ah 2021-03-10 22:30:10 and 0.80 has the new API? 2021-03-10 22:37:13 JuniorJPDJ: e.g. we also don't print "run rc-update add nginx default" 2021-03-10 22:38:16 omni: Yes, >=0.80<2 has the libhandy1 API 2021-03-11 09:20:08 morning 2021-03-11 09:20:20 python 3.9 is giving me a hard time 2021-03-11 09:20:41 Morning 2021-03-11 09:20:59 py3-mock fails in test suite: https://tpaste.us/QWkE 2021-03-11 09:21:03 no idea what the fix is 2021-03-11 09:21:46 apparently py3-mock is a backport of upstream mock, which is included in python itself? 2021-03-11 09:21:49 $ apk info -L python3 | grep mock 2021-03-11 09:21:49 usr/lib/python3.9/unittest/mock.py 2021-03-11 09:22:00 so we might not need py3-mock? 2021-03-11 09:26:31 but if i remove py3-mock, and remove it from py3-pip deps, it will fail during test: 2021-03-11 09:26:31 $ abuild check 2>&1 | tpaste 2021-03-11 09:26:31 https://tpaste.us/K57b 2021-03-11 09:26:48 so im stuck... 2021-03-11 09:30:45 hum 2021-03-11 09:31:05 seems like the way to handle broken checks is to simply drop the test 2021-03-11 09:34:03 ncopa-edge-x86_64:~/aports/community/py3-pip (python-3.9)$ abuild check 2>&1 | tpaste 2021-03-11 09:34:04 https://tpaste.us/jnlK 2021-03-11 09:34:21 py3-pip test fails du to missing py3-py ^^^ 2021-03-11 09:34:37 but py3-py is installed: $ apk info -L py3-py | tpaste 2021-03-11 09:34:37 https://tpaste.us/DMQo 2021-03-11 09:35:17 error indicates that it is pytest that is broken 2021-03-11 09:36:24 py3-py test suite was disabled in a4402ec5c95 2021-03-11 09:44:21 ncopa: voidlinux seem to have that test disabled since mock 4.0.3 https://github.com/void-linux/void-packages/commit/91c20c9ce745669523105bce3f1fc7677c86a30a#diff-4e86ebec88dc72172c5106351ec2fe0526dab6a8b52a1ca95dcaaa5d7f2e1731 2021-03-11 09:50:20 omin: thanks 2021-03-11 09:51:31 np 2021-03-11 09:52:12 now it fails with broken pytest that dont find py>=1.8.2 2021-03-11 09:52:16 ncopa-edge-x86_64:~/aports/community/py3-pip (python-3.9)$ abuild deps 2>&1 | tpaste 2021-03-11 09:52:16 https://tpaste.us/BE5y 2021-03-11 09:52:49 sorry , wrong paste 2021-03-11 09:52:57 ncopa-edge-x86_64:~/aports/community/py3-pip (python-3.9)$ abuild check 2>&1 | tpaste 2021-03-11 09:52:57 https://tpaste.us/bylL 2021-03-11 09:53:12 E pkg_resources.DistributionNotFound: The 'py>=1.8.2' distribution was not found and is required by pytest 2021-03-11 09:53:33 the pytest's abuild check passes 2021-03-11 09:53:44 and py 1.10.1 is installed 2021-03-11 09:54:02 and successfully rebuilt with python 3.9 2021-03-11 10:15:15 ncopa: what if you bump pip to 21.0.1? 2021-03-11 10:15:48 could be this https://github.com/pypa/pip/commit/68a86c53c7719cac5129561c72ed5b74f8c30263 2021-03-11 16:04:33 anyone that has a commit bit for secdb around? https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/merge_requests/2 2021-03-11 16:28:07 omni: Hi, how's llvm11? Could use a hand? :) 2021-03-11 16:30:10 Cogitri: Through your exams? 2021-03-11 16:33:23 Cogitri: yes please! I'm now just occasionally pushing a change and then head off doing something else 2021-03-11 16:33:32 it would be nice to enable check() 2021-03-11 16:33:57 other than that I think it's fine 2021-03-11 16:36:52 ikke: Yup, wrote last one two days ago and went through two days of bring useless now to rebound, so I think I can rejoin society again :D 2021-03-11 16:37:06 omni: Alrighty, I'll look into it soom :) 2021-03-11 16:38:03 haha 2021-03-11 16:45:16 there were 2 MRs for llvm11 !13773 and !13553 2021-03-11 16:50:44 here's the third I've been working on !18795 2021-03-11 16:51:09 without check() the right files seem to be added to/removed from their respective package 2021-03-11 16:51:51 omni: I saw this but thought it is not related to llvm11 2021-03-11 16:52:05 so didn't looked at it 2021-03-11 16:57:47 I've been thinking if clang should be a subpackage to llvmXX.. 2021-03-11 16:58:09 that's what void-linux seem to do 2021-03-11 16:58:37 I don't see much of an advantage to it to be honest 2021-03-11 16:59:37 you want to upgrade them together, don't you? 2021-03-11 16:59:43 no 2021-03-11 17:00:21 iirc, we have a reasons to keep them separate 2021-03-11 17:00:26 and I've been thinking if it couldn't help get the tests to build 2021-03-11 17:00:35 yeah, there are probably reasons I don't know of 2021-03-11 17:08:39 omni: Are other distros patching the python shebangs too? That looks kinda like it could blow up at random when upstream doesn't support py3 properly yet 2021-03-11 17:08:56 Void automatically does it and Arch does it too 2021-03-11 17:09:35 arch has been doing it for quite some time already 2021-03-11 17:11:09 Hmm, well, if it works it's a bit odd upstream doesn't do anything about it but sure 2021-03-11 17:11:56 I think what arch mostly has been doing is s/python/python2 2021-03-11 17:12:01 because python points to python3 2021-03-11 17:12:22 Ah yes, that seems less broken 2021-03-11 17:16:20 Cogitri: I did that to not have to keep track of what files you needed to change the shebangs in, but I've also been thinking of why isn't python a symlink to python3? 2021-03-11 17:17:38 We had that for a while, but it broke a few things, so we decided to roll back 2021-03-11 17:18:25 Many things still assume python == python2 2021-03-11 17:18:52 We should just do s/python/python2 in that case 2021-03-11 17:19:11 but, there are not many things relying on python2 anymore anyway 2021-03-11 17:20:23 True that, but I don't think we'll be able to drop it for 3.14 :/ 2021-03-11 17:20:27 Unless we drop Chromium 2021-03-11 17:20:43 really?? 2021-03-11 17:20:52 huh 2021-03-11 17:21:06 Dunno, Chromium seems just happy on py2 2021-03-11 17:21:09 chromiums build system still uses it 2021-03-11 17:21:24 But I think Google wants us to drop the thing anyway with how they've trashed the Chromium sync keys 2021-03-11 17:21:55 ? 2021-03-11 17:22:07 chromium sync keys? 2021-03-11 17:22:23 The API keys for the sync API 2021-03-11 17:22:32 umm, why would you want that in chromium? 2021-03-11 17:22:32 dalias: google announced it's going to revoce sync keys used to syn things like history and tabs between devices 2021-03-11 17:22:38 the whole point of chromium is a degoogled chrome 2021-03-11 17:22:46 not really 2021-03-11 17:22:47 replace it with that ungoogled-chromium? :D 2021-03-11 17:22:49 Also, fun fact: The chromium source archive is now bigger than an Alpinelinux extended and 2x Alpinelinux standard ISO :D 2021-03-11 17:22:58 omni: That seems like even more of a nightmare to maintain 2021-03-11 17:23:07 right 2021-03-11 17:23:08 Chromium is already not fun, Chromium with a massive amount of patches even less so 2021-03-11 17:23:12 yes chrom{e,ium} is awful in every way 2021-03-11 17:23:34 except for starting sites with --app, which other browsers do not have 2021-03-11 17:23:36 and i thought alpine was building without the sync stuff 2021-03-11 17:23:48 but if you really want it.. 2021-03-11 17:23:57 just extract the key from chrome and put it in :) 2021-03-11 17:23:59 ikke: I think Epiphany and FF have app modes now too, don't they? 2021-03-11 17:24:20 Cogitri: no, firefox had a mode called ssb for a while, but they decided to drop it, and it was not the same anyway 2021-03-11 17:24:27 dalias: Not sure if Google can't give us a bad time for that 2021-03-11 17:24:28 epiphany I don't know 2021-03-11 17:24:33 or rather, since you can't really ship that 2021-03-11 17:24:43 patch it to load the key from ~/.chromium_sync_key 2021-03-11 17:24:50 Epiphany can do it, but webkit2gtk performance is...less than great compared to FF/Chromium 2021-03-11 17:24:52 and tell users where to get the key extracted from chrome :) 2021-03-11 17:26:11 that's what i'd recommend for any case where some malicious party is forcing you to use api keys for something you really need to access 2021-03-11 17:26:25 however sync to google account is really just a misfeature 2021-03-11 17:26:54 Well, lots of users seem to use it (personally I don't use any of that sync stuff either, with the amount of tabs I keep open on my mobile it's be a disservice to me :) 2021-03-11 17:27:06 :/ 2021-03-11 17:27:08 Although the new mobile FF can auto-close stale apps after a day which si great 2021-03-11 17:27:35 new mobile ff is unusable because it's missing about:config :( 2021-03-11 17:27:52 i'm still on an 8-month-old version because of that 2021-03-11 17:28:00 :/ 2021-03-11 17:28:22 Before I sink in huge amounts of time into this: Do we still need Hexagon support in LLVM? :) 2021-03-11 17:28:33 ? 2021-03-11 17:28:39 we = in what sense? 2021-03-11 17:28:49 Hm, we probably do 2021-03-11 17:28:53 We as in Alpine 2021-03-11 17:29:09 The MIR generation for Hexagon seems to be pretty mangled for Hexagon in LLVM11 2021-03-11 17:30:05 i'm confused. is it something you can omit from the supported targets at compile time? 2021-03-11 17:30:11 why would you omit supported targets? 2021-03-11 17:31:14 Because loads of tests for the generated code fail, was just curious if it makes sense putting time into fixing it, but seems like I misunderstood which targets Hexagon supports so it definitely makes sense to keep it 2021-03-11 17:31:58 if tests fail just disable the tests :) 2021-03-11 17:44:00 Cogitri dalias: I believe arch is doing a dance with shipping chrome keys through env vars 2021-03-11 17:46:42 :) 2021-03-11 17:46:52 that's the right way to do it 2021-03-11 17:46:58 also api keys should be illegal 2021-03-11 17:47:44 (arbitrarily restricting access to your service to specific client software that contains a not-a-secret secret identifying itself) 2021-03-11 17:51:35 i understand the model and it makes sense. of course it doesn't prevent individual users from extracting the key and using alt software 2021-03-11 17:52:55 we've found ourselves in a predicament not dissimilar to when IE6 ruled the internet 2021-03-11 17:53:10 rather it allows google (or whoever) to control who can make and achieve widespread adoption of alternate software that interfaces with their service by handing out keys that let them monitor behavior by application and threaten to revoke keys for applications that behave in ways they don't like 2021-03-11 17:54:11 and threaten legal action against any party who says "fuck you we don't need a key", thereby creating fud and preventing widespread adoption 2021-03-11 18:15:39 ncopa: xtables-addons is fixed in new upstream release 2021-03-11 18:16:00 (didn't tested build yet, but patch looks ok) 2021-03-11 18:16:50 just got mail from upstream, don't have much time to work on this 2021-03-11 18:34:45 ncopa: tested on x86_64 and armv7, works without errors or warnings. you will probably upgrade kernel to 5.10.23 soon so upgrade also this 2021-03-11 19:11:26 Link to mail? 2021-03-11 19:11:39 [10:28:21] Before I sink in huge amounts of time into this: Do we still need Hexagon support in LLVM? :) 2021-03-11 19:11:48 Cogitri: if it was Hexagon CPU architecture, we do not 2021-03-11 19:11:57 if there is some other thing called Hexagon, i have no idea 2021-03-11 19:13:48 ikke: you ask me? https://www.spinics.net/lists/netfilter-devel/msg70554.html 2021-03-11 19:14:13 and bug report https://www.spinics.net/lists/netfilter-devel/msg70467.html 2021-03-11 19:20:01 Ariadne: Seems like Hexagon is still used for Snapdragon and stuff? 2021-03-11 19:26:24 Cogitri: yes, hexagon is the media DSP on snapdragon. we have no use for it though. 2021-03-11 19:27:10 the tooling for building code to run on hexagon is still WIP 2021-03-11 19:27:16 there is no production consumers 2021-03-11 19:29:04 Ah, I suppose we can disable it then (or disable the tests) 2021-03-11 19:31:54 basically think of hexagon like say, AMDGPU target, or NVPTX 2021-03-11 19:32:11 the hexagon cores on snapdragon are not the main AP 2021-03-11 19:32:20 that's some ARMv8 core 2021-03-11 19:32:29 and that core does not run hexagon code 2021-03-11 19:32:40 it is possible to turn the ARMv8 core off and run only hexagon code 2021-03-11 19:32:48 for power saving purposes 2021-03-11 19:32:57 but that will likely never be applicable to us 2021-03-11 19:33:12 because i am sure android is going to have to do some true eldritch horror shit to facilitate that 2021-03-11 19:33:54 so basically 2021-03-11 19:34:17 we do not need it *now* but we might in a few years 2021-03-11 19:36:14 Oki, no need to mess with it now them 2021-03-11 19:39:48 Ariadne: if you get news about the rust meeting that will discuss the dynmusl stuff, could you please post a link in #musl? 2021-03-11 19:41:30 ericonr: we are still awaiting a meeting slot 2021-03-11 19:41:59 dalias: does mirabilos' solution in #12398 work for you? 2021-03-11 19:42:55 Ariadne: sure, whenever it's actually scheduled :) 2021-03-11 19:43:40 fwiw most people in zulip agree that the -musl targets are really broken 2021-03-11 19:43:46 so i think we will get what we want 2021-03-11 19:44:01 the only question is how to do the compiler warning for non-musl targets to tell them about the change 2021-03-11 19:44:13 so i am not sure if there is much point in attending the meeting 2021-03-11 19:44:20 but yes will announce it as soon as i know 2021-03-11 19:45:51 thanks :) 2021-03-11 19:55:44 huh, arm64 defconfig kernel tar.gz in 308.7M, with modules and dtbs 2021-03-11 20:01:25 arm64 is bloat 2021-03-11 20:02:37 well, too much different SOCs and SBCs 2021-03-11 20:04:50 TOO MUCH BLOAT 2021-03-11 20:09:48 wow, today roles are reversed and mps is not the one fighting for minimalism 2021-03-11 20:23:52 i fight for minimalism where it makes sense 2021-03-11 20:24:57 i do not feel that giving users bad tools in the name of minimalism is really minimalist though 2021-03-11 20:25:10 since it just encourages users to immediately discard the bad tools 2021-03-11 20:25:26 which is why i am trying to slim busybox down, since half the applets are garbage :P 2021-03-11 20:32:56 I like this garbage instead of bigger garbage 2021-03-11 20:33:44 s/like/prefer/ 2021-03-11 20:33:44 mps meant to say: I prefer this garbage instead of bigger garbage 2021-03-11 20:35:03 afontain_: well, I expected something like this size, just wanted to check 2021-03-11 20:36:46 Ariadne: it looks like the proposed solution wasn't entirely appreciated by dalias 2021-03-11 20:42:25 yes, i found a compromise solution 2021-03-11 20:42:43 i am just testing it on all shells atm before pushing 2021-03-11 20:42:55 we still export PS1, but we make sure PS1 is something sane by default 2021-03-11 20:43:09 and do not mess with $ENV 2021-03-11 21:19:53 seems like a decent compromise 2021-03-11 21:29:35 agreed. i dont like solutions that put more distro-specific config around different shells in place by default 2021-03-11 21:29:48 just making it simple and minimally working with everything is nice 2021-03-11 21:30:02 and users who want something special (doesn't everyone have their own preferences anyway) can set them up 2021-03-11 21:30:58 dalias: yes, agreed, the default should be something simple and sane 2021-03-11 22:04:53 Cogitri: in my MR, I have no issues with the llvm11 build, tests and subpackages, only building and running tests for clang 2021-03-11 22:05:51 would removing hexagon in llvm11 help with clang tests? 2021-03-11 22:09:32 oh, well, I've _removed_ the failing tests on llvm11 ;) 2021-03-11 22:18:07 dalias: I like alpine precisely because I have my own preferences 2021-03-11 22:20:11 omni: I opened a MR myself, gonna get it into shape tomorrow 2021-03-11 22:20:38 No worries, still kept you as author, thanks for working on it 2021-03-11 22:30:18 I wasn't worried not being credited, but thanks =) 2021-03-11 22:30:57 I guess I too began with getting the llvm11 aport sorted before moving to clang, come to think of it 2021-03-11 22:32:13 and it makes sense to have your own MR to play with so you don't have to go through me to test things 2021-03-11 22:32:25 I've just become used to getting suggestions that way 2021-03-11 22:36:00 Yup, it's just important to me to properly credit folks, nothing is worse than working on something only to then get it snatched away, it's really discouraging for contributors 2021-03-11 22:36:15 And as a dev I want contributors to have the best experience possible 2021-03-11 22:55:08 <3 2021-03-11 23:05:51 [16:04:50] if you care about attending the meeting where the rust team decides what the disposition of the -musl targets is, the scheduling meeting for that meeting is tomorrow at 10AM GMT-5 2021-03-11 23:05:51 [16:05:25] they have requested that as many stakeholders attend the scheduling meeting as possible so that an ideal time can be chosen for the discussion meeting 2021-03-11 23:05:51 [16:05:31] thanks 2021-03-11 23:43:34 oof, 6am for me 2021-03-11 23:59:30 huh? 2021-03-11 23:59:39 you're in germany, i thought 2021-03-11 23:59:51 wouldn't it be later than 10AM? 2021-03-12 00:00:53 Oh, I am in Germany, apparently I just suck with timezones 2021-03-12 00:00:54 i would figure that would be like 4PM or so in europe 2021-03-12 00:01:52 Yeah, `10am gmt-5` yielded me `6am in your local time` with google, not sure what that's about 2021-03-12 00:02:08 How does one participate in that meeting? 2021-03-12 00:04:02 it will be a thread on #t-compiler/meetings in zulip 2021-03-12 00:04:27 would be nice if we can have dalias on board too 2021-03-12 00:04:42 i think he can make the best case for making the -musl targets sane 2021-03-12 00:06:15 Yup, that'd be nice 2021-03-12 00:07:02 Let's see if I'm competent enough to use Zulip, the app is so laggy because it marks everything that has ever happened on the Rust zulip as unread message (why) 2021-03-12 00:08:09 if you hit Shift+G or End it will go straight to the end 2021-03-12 00:08:32 half the conversations on zulip are complaints about zulip 2021-03-12 00:11:18 Heh 2021-03-12 00:49:42 ariadne, what is the topic? 2021-03-12 00:50:05 dalias: The future of the -musl triplet for Rust 2021-03-12 00:50:18 :/ why is this controversial?? 2021-03-12 00:50:32 it's not like we're proposing a change in the *language* 2021-03-12 00:51:18 just fixing a wrong default for the tooling. binutils changes small default details all the time 2021-03-12 00:51:24 "no new projects should be written in C" is the reason this is controversial, you are not dealing with a technical discussion 2021-03-12 00:51:37 ? 2021-03-12 00:52:54 so when is this meeting, what platform, how many hours from now ? 2021-03-12 00:54:51 i assume gmt-5 means same thing as EST5 in posix form 2021-03-12 01:13:16 the meeting in question is to figure out when the best time for a comment meeting would be 2021-03-12 01:13:19 yes, i know 2021-03-12 01:13:34 needless to say having now interacted with the rust team, i understand how mozilla blows through so much cash 2021-03-12 01:13:50 these people have meetings to plan other meetings to plan other meetings 2021-03-12 01:14:00 if alpine did this, we would not ever ship anything 2021-03-12 01:25:00 lol 2021-03-12 01:25:50 wtf is this zulip thing? 2021-03-12 01:26:00 do you need a machine that can compile firefox to chat on it? 2021-03-12 03:49:27 dalias: yes, it is IRC but excessively webshit 2021-03-12 06:53:17 gojq fails on mips64 because int(math.Inf(1)) returns 0 2021-03-12 08:22:56 good morgen 2021-03-12 08:24:22 ncopa: did you read channel backlog and my comments about xtables-addons from last night? asking because you maybe working on -lts upgrade 2021-03-12 09:28:36 morning. sorry, no i haven't read the backlog 2021-03-12 09:29:57 mps: thank you for following it up with upstream. will try remember fix it with 5.10.23 2021-03-12 09:30:09 oh.. 5.10.23 is already out 2021-03-12 09:30:25 not sure i will have time for kernel upgrade today 2021-03-12 09:31:30 Ariadne, dalias: https://github.com/zulip/zulip-terminal ? 2021-03-12 09:34:24 Could anyone merge !16899 by any chance? 2021-03-12 09:36:06 ikke: sounds related to softfloat 2021-03-12 09:39:08 ncopa: yes, new pile of kernel is released yesterday. I will upgrade just xtables-addons and xtables-addons-lts later (to not be forgotten) if you don't have time today 2021-03-12 09:39:13 looks like Ariadne did a better review than I did or your MR PureTryOut[m]2 2021-03-12 09:39:29 Resolved it haha 2021-03-12 09:39:32 mps: i'll try get it done today 2021-03-12 09:39:47 ok 2021-03-12 09:40:21 PureTryOut[m]2: those changes conflics with my python 3.9 work, but i think we should merge that MR so i can rebase 2021-03-12 09:40:26 might even fix some of my issues 2021-03-12 09:40:47 Oh yes sure 2021-03-12 09:40:55 Excited to see work on 3.9 done, thanks for that! 2021-03-12 09:41:10 it has been an uphill fight... 2021-03-12 09:41:22 Some big problems? 2021-03-12 09:41:24 i got main rebuilt and are working on community 2021-03-12 09:41:36 mostly tests that fails or dependencies that are broke 2021-03-12 09:42:41 i wonder if i should just push when main and community is done, and start work on testing while main and community are built 2021-03-12 09:42:55 will lead to broken testing repo for a hopefully short time 2021-03-12 09:43:06 but it makes it eaiser for others to help solve those 2021-03-12 09:44:39 Hm, the build of main& community won't take that long with python stuff so I'd vote for porting everything and then pushing 2021-03-12 09:50:27 the shell issue with $PS1 should be sorted too 2021-03-12 09:50:37 \o/ 2021-03-12 09:50:42 i fixed that yesterday 2021-03-12 09:50:51 though, i think mirabilos idea is good and should be pursued 2021-03-12 09:51:03 Cogitri: do you mean with or without things from the testing repo? 2021-03-12 09:51:07 but that would be a breaking change, so it should be discussed on -devel 2021-03-12 09:51:24 use gnome shell :) 2021-03-12 09:51:35 huh? 2021-03-12 09:52:29 which shell? ash have issues? 2021-03-12 09:52:51 /etc/profile vs korn shell vs zsh 2021-03-12 09:52:56 vs bash and ash 2021-03-12 09:53:01 huh 2021-03-12 09:53:15 an incomplete fix was done to remove PS1 definition 2021-03-12 09:53:17 all they read same profile 2021-03-12 09:53:25 which caused PS1 to be garbage 2021-03-12 09:53:36 so i fixed it 2021-03-12 09:53:36 mps: !12398 2021-03-12 09:53:44 oh, wrong 2021-03-12 09:53:44 oh 2021-03-12 09:53:49 now we figure out what shell it is 2021-03-12 09:53:53 and set PS1 appropriately 2021-03-12 09:54:00 mps: #12398 (maybe?) 2021-03-12 09:54:04 yes, that 2021-03-12 09:54:05 (yeah) 2021-03-12 09:54:25 I didn't noticed any issue, but ok, np 2021-03-12 09:54:27 that gitlab uses different serial for merge requests vs issue is annoying 2021-03-12 09:54:43 mps: it only effects people who have default settings 2021-03-12 09:54:54 if you set your own PS1 obviously that supercedes whatever /etc/profile is doing 2021-03-12 09:54:55 aha 2021-03-12 09:55:54 ahm, now remember that I had strange prompt few days ago when tested armv7 in qemu 2021-03-12 09:56:44 yeah 2021-03-12 09:56:59 its fixed in alpine-baselayout 3.2.0-r11 the right way 2021-03-12 09:57:47 good 2021-03-12 10:11:47 Hi, could you merge !19195 ? it fixes a go compilation problem and adds ocaml use for other architectures 2021-03-12 10:12:30 why do we keep the `export` and does not set `PS1` without the export? 2021-03-12 10:54:36 Would break non login shells 2021-03-12 11:10:14 Ariadne: any idea how to deal with that? 2021-03-12 11:11:02 (gojq issue on mips) 2021-03-12 11:33:44 i don't think it is fixable 2021-03-12 11:33:49 i would just disable the package 2021-03-12 11:34:13 i mean, the fix would be "fix the softfloat code in go" 2021-03-12 11:34:18 right 2021-03-12 11:34:22 which, yes, its fixable, but not fixable in gojq 2021-03-12 11:35:00 The test failures is doing "string" * infinite, so perhaps we can just disable that part 2021-03-12 11:35:03 of the test 2021-03-12 11:35:36 It expects null, but it returns "" 2021-03-12 11:35:40 yes 2021-03-12 11:36:03 this seems like a defective test 2021-03-12 11:36:28 one of the things about softfloat is that its stricter 2021-03-12 11:36:50 FPUs will do things that softfloat won't 2021-03-12 11:37:19 I don't think the test itself is defective, but the code it's excercising might be 2021-03-12 11:37:37 "string" * infinite seems defective to me 2021-03-12 11:38:16 https://github.com/itchyny/gojq/blob/main/operator.go#L381 2021-03-12 11:38:54 Ariadne: "string" * 3 returns "stringstringstring" 2021-03-12 11:39:18 yes, that part makes sense 2021-03-12 11:39:20 So this tries to catch an edgecase 2021-03-12 11:39:31 but infinity is not really a number 2021-03-12 11:39:39 https://github.com/itchyny/gojq/commit/0272f670d1d691eadc9a6b05532db2b733624784 2021-03-12 11:39:52 thusly, "string" * infinity returning "" seems legitimate to me 2021-03-12 11:40:09 They try to explicitly catch it and return null instead 2021-03-12 11:40:12 but that part fails 2021-03-12 11:40:13 its mathematically sound 2021-03-12 11:40:55 int(cnt) < 0 seems wrong 2021-03-12 11:41:35 when converting a floating point value to integral domain, you're supposed to use a stable conversion function 2021-03-12 11:41:36 on s390x it returns a very large number 2021-03-12 11:41:45 yes, because big-endian 2021-03-12 11:42:03 Yes, makes sense, I wanted to verify how it behaved on other big-endian systems 2021-03-12 11:42:20 on hardfloat, it would likely behave the same 2021-03-12 11:42:31 but since this is softfloat, 0 also makes sense 2021-03-12 11:42:53 because the compiler can just say "lol cast int(infinity), ok, we'll constexpr that as 0" 2021-03-12 11:43:07 basically, what they are doing is bogus 2021-03-12 11:43:50 I had a suspicion 2021-03-12 11:44:06 (programming based on dogma that math is always correct :) ) 2021-03-12 11:44:07 for example, on python if you try this 2021-03-12 11:44:14 OverflowError: cannot convert float infinity to integer 2021-03-12 11:44:53 you can't take the floor of infinity and cast it to a valid integral number 2021-03-12 11:45:01 much less just raw cast to infinity 2021-03-12 11:45:06 it's an imaginary value 2021-03-12 11:45:24 yup, so it can basically return anything 2021-03-12 11:45:26 so yes, the test case is bogus 2021-03-12 11:45:56 "string" * (some computation that returns infinity) 2021-03-12 11:47:03 multiplyString should take the floor of `cnt` and use that as a number to duplicate by in the integral domain 2021-03-12 11:47:12 this is actually possibly a security vulnerability 2021-03-12 11:47:44 given specially crafted floating point values, you could make gojq consume a lot of RAM generating absurdly large strings 2021-03-12 11:48:10 They do limit it 2021-03-12 11:48:28 no 2021-03-12 11:48:30 return strings.Repeat(s, int(cnt)) 2021-03-12 11:48:32 they don't 2021-03-12 11:48:34 hmnm 2021-03-12 11:48:42 ok, not in this case then 2021-03-12 11:48:49 and casting from float to int is not safe anyway 2021-03-12 11:48:55 "string" * very_large_number returns null 2021-03-12 11:49:10 that might be go's stdlib saying no 2021-03-12 11:49:19 they do test explicitly for it 2021-03-12 11:49:51 this code is so strange 2021-03-12 11:49:54 https://github.com/itchyny/gojq/blob/main/cli/test.yaml#L1862 2021-03-12 11:50:03 they parse the RHS as a string into a float 2021-03-12 11:50:10 then cast it to get an int 2021-03-12 11:50:18 why not just parse it as int to begin with 2021-03-12 11:51:08 is there a way to get a Go repl 2021-03-12 11:51:32 https://play.golang.org/ 2021-03-12 11:51:35 but no cli repl afaik 2021-03-12 11:51:44 perhaps there is, but I'm not aware of any 2021-03-12 11:52:08 https://github.com/golobby/repl 2021-03-12 11:53:08 there seems to be `gore` 2021-03-12 11:53:16 Yeah, was about to link to it 2021-03-12 11:53:19 https://github.com/motemen/gore 2021-03-12 11:56:53 so, what this code should be doing is 2021-03-12 11:56:56 instead of int(cnt) 2021-03-12 11:57:01 it should be int(math.Floor(cnt)) 2021-03-12 11:58:04 seems to still return 0? 2021-03-12 11:58:28 But I guess just out of correctness 2021-03-12 12:00:26 actually, it should be math.Trunc(cnt) 2021-03-12 12:00:41 however, this code should verify that cnt is in the integral domain 2021-03-12 12:01:51 right now, it assumes that +/-Inf will cast as int with the sign bit set 2021-03-12 12:02:03 which is not a portably reasonable assumption 2021-03-12 12:02:28 so, the logic should be 2021-03-12 12:05:12 i am honestly disappointed that go does not have an actual function for testing whether a number is in the integral domain 2021-03-12 12:05:19 even C has this for fucks sake 2021-03-12 12:07:11 I guess that's something float specific? 2021-03-12 12:08:54 yes, you want to verify that the float is not NaN or infinity 2021-03-12 12:10:06 so !(math.isNaN(n) || math.isInf(n, 1) || math.isInf(n, -1)? 2021-03-12 12:10:08 if math.IsNaN(cnt) || math.IsInf(cnt, 0) || math.IsInf(cnt, 1) || cnt <= 0.0 { return nil; } ... return strings.Repeat(s, int(Math.trunc(cnt))) 2021-03-12 12:10:10 is the fix 2021-03-12 12:10:56 math.IsInf(cnt, 0) should be math.IsInf(cnt, -1), right? 2021-03-12 12:11:09 Ah, 0 is for either 2021-03-12 12:11:23 then just a single condition should suffice 2021-03-12 12:23:20 math.IsNaN(cnt - cnt) is faster 2021-03-12 12:23:41 who made this trainwreck of a math library 2021-03-12 12:25:48 so that gives you 2021-03-12 12:26:05 if math.IsNaN(cnt - cnt) || cnt <= 0.0 { return nil; } 2021-03-12 12:28:38 Thanks, I'll report this upstream and will patch it in the meantime 2021-03-12 12:30:41 was surprised that rustc is not smart enough to handle truncation and testing for real values itself 2021-03-12 12:30:57 if you cast float to int in rust, it doesn't even warn about it 2021-03-12 12:31:13 so you'd think that means they just do whatever is needed to make it safe 2021-03-12 12:31:35 :) 2021-03-12 12:31:39 But they don't? 2021-03-12 12:31:49 nope! casting f64::INFINITY to i64 gets the raw binary64 representation of positive infinity 2021-03-12 12:32:00 and these people says that C is 'bad' :/ 2021-03-12 12:32:12 you're not supposed to do that in C either 2021-03-12 12:32:29 sure, but you even not try this 2021-03-12 12:32:30 you're supposed to check if the value is finite and then truncate before casting 2021-03-12 12:33:12 and, iirc C compiler will warn 2021-03-12 12:33:18 yes 2021-03-12 12:34:42 Ariadne: Don't use `as`, use T::from/T::try_from 2021-03-12 12:59:49 GC Warning: Repeated allocation of very large block (appr. size 69632): May lead to memory leak and poor performance 2021-03-12 13:00:17 in building crystal 0.36.1 2021-03-12 13:00:50 invokes methods on empty array of recursive alias (1)Invalid memory access (signal 11) at address 0x7fd920679cc8 2021-03-12 13:02:10 and iirc these people use alpine for lang development 2021-03-12 14:25:59 Ariadne: I made you this !19228 =) 2021-03-12 14:26:48 (perhaps too late and/or broken) 2021-03-12 14:49:26 ariadne, how do i get on this zulip thing? 2021-03-12 14:50:38 ok i think i found it 2021-03-12 14:51:18 I don't see a t-compiler/meeting though? Or is that stream not created yet? 2021-03-12 14:54:05 Cogitri: you have to click "more streams" thingy 2021-03-12 14:54:20 it was not in the side bar for me initially, at least 2021-03-12 14:55:45 and ok it's web-based so no need for hideous client apps 2021-03-12 14:56:09 https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings <-- I think this link works? 2021-03-12 14:56:27 but idk where the musl meeting will be 2021-03-12 14:56:54 and the web tech is actually non-shit 2021-03-12 14:57:05 it's like classic web 2.0 ajax with zero bloat, lightning fast 2021-03-12 14:57:21 clicking shit responds instantly 2021-03-12 14:57:37 whoever developed this should get a $1b contract to rewrite everything important on the web 2021-03-12 14:59:19 ericonr: Ah, found it, thanks 2021-03-12 14:59:39 I can't find the actual thread for the meeting, tho 2021-03-12 14:59:49 dalias: :D it is indeed pretty snappy 2021-03-12 15:00:20 seriously this is like how gmail was in 2004 or so 2021-03-12 15:00:39 maybe 2005 or 6, i forget 2021-03-12 15:02:41 so is there a meeting? where? 2021-03-12 15:03:19 i dont see it under t-compiler/meetings 2021-03-12 15:03:48 yeah me neither... I see you and Cogitri in the right side bar, but not Ariadne 2021-03-12 15:04:23 dalias: ah, it just opened! 2021-03-12 15:04:48 planning meeting 2021-03-12 ? 2021-03-12 15:04:57 with pnkfelix? 2021-03-12 15:04:57 yeah, I believe so 2021-03-12 15:06:04 is there anywhere to see who's attending? 2021-03-12 15:09:59 I don't think so since it's basically like having a meeting on IRC, you can't know who actually attends and who just idles in the channel 2021-03-12 15:42:21 ariadne, are you on? 2021-03-12 15:51:22 sounds like the udp emulation aka matrix :P 2021-03-12 16:11:21 Anyone know of any 'go' packages in alpine? Might add 'webhook' so wanted to see if there was an example I could use. 2021-03-12 16:11:34 there are plenty 2021-03-12 16:12:04 if you have lua-aports installed you can find them using ap revdep go 2021-03-12 16:12:16 from the top of my head: a simple go aport is testing/age 2021-03-12 16:12:28 apparently we just directly install it: https://gitlab.alpinelinux.org/alpine/infra/compose/webhook/-/blob/master/Dockerfile#L5 2021-03-12 16:13:04 There is a lot of bad example left over from the time go did not have native support for modules though 2021-03-12 16:17:57 Ariadne: patch is working 2021-03-12 16:18:23 nmeum: Thanks, will take a look. 2021-03-12 16:18:33 is it a known problem that unshare(2) does not work on the docker CI? seems to return ENOSYS 2021-03-12 16:18:39 ikke: I did consider just copying in the pre-compiled one, but thought I'd try to do it 'properly' :) 2021-03-12 16:18:50 i.e. is that related to some sort of docker libcomp thingy? 2021-03-12 16:18:57 adhawkins: `go get` does compile it 2021-03-12 16:19:08 nmeum: yes 2021-03-12 16:19:18 You need a privileged container for that 2021-03-12 16:19:20 ah 2021-03-12 16:19:29 that explains why the test suite fails 2021-03-12 16:19:38 do you know how that is implemented in docker? 2021-03-12 16:19:53 libseccomp, like you said 2021-03-12 16:20:02 because it seems to return ENOSYS where I would expect it to return EPERM 2021-03-12 16:20:17 :D 2021-03-12 16:20:43 ikke: Is there any benefit in packaging this up for others to use do you think? 2021-03-12 16:20:55 ikke: you don't happen to have any further information on this, do you? 2021-03-12 16:22:18 nmeum: https://github.com/moby/moby/blob/master/profiles/seccomp/default.json#L614 2021-03-12 16:22:36 nmeum: EPERM is wrong. 2021-03-12 16:22:39 I don't know the profile definition that well, but I guess that means they require CAP_SYS_ADMIN 2021-03-12 16:23:05 Hello71: why? 2021-03-12 16:23:05 Hello71: Wouldn't it be correct in this case? 2021-03-12 16:23:17 https://github.com/opencontainers/runc/pull/2750 2021-03-12 16:23:22 Yes 2021-03-12 16:23:22 mm, in general. 2021-03-12 16:23:23 seems like it used to be -EPERM in the past? 2021-03-12 16:23:37 The issue is when it encounters unknown syscalls 2021-03-12 16:23:47 it was wrong but happened to be right but now was changed to be more right but is wrong here 2021-03-12 16:23:50 in any case: the go test suite expects EPERM and it fails because the docker stuff on our CI returns ENOSYS 2021-03-12 16:23:53 I will just path the go test 2021-03-12 16:23:55 it used to return -EPERM where -ENOSYS was expected 2021-03-12 16:24:09 but for know syscalls that are blocked, EPERM is not wrong 2021-03-12 16:24:19 Hello71: very confusing 2021-03-12 16:24:22 in any case it's definitely wrong to fail on ENOSYS because you can still compile out unshare 2021-03-12 16:24:31 well not unshare specifically but namespaces 2021-03-12 16:25:02 I will just add a patch to go which adds handling for ENOSYS and like to this runc PR from above 2021-03-12 16:25:09 nmeum: because libseccomp was still giving issues for us, we changed the default profile so that it would return ENOSYS on our CI hosts 2021-03-12 16:25:09 s/like/link/ 2021-03-12 16:25:10 nmeum meant to say: I will just add a patch to go which adds handling for ENOSYS and link to this runc PR from above 2021-03-12 16:25:22 nmeum: specifically due to faccessat2 2021-03-12 16:25:27 ikke: ah, so it's a matter of configuration? 2021-03-12 16:25:32 yes 2021-03-12 16:25:43 do we have an internal issue I can reference for this? 2021-03-12 16:26:02 I did not create an issue for this 2021-03-12 16:26:20 i will just document it in the patch description then 2021-03-12 16:26:53 I don't think it's a bad idea so that we know to roll the config change back, though 2021-03-12 16:31:29 https://gitlab.alpinelinux.org/alpine/aports/-/commit/ed41c69bd7160222c21ebef6c3515d14dbf82918?merge_request_iid=19238 2021-03-12 16:31:32 that should fix it 2021-03-12 16:31:33 let's see :) 2021-03-12 16:32:46 Shouldn't it be able to handle ENOSYS anyway? 2021-03-12 16:34:14 hm? 2021-03-12 16:34:37 the test case is skipped if EPERM is returned, if ENOSYS is returned that is treated as a test case failure 2021-03-12 16:34:42 (without the patch) 2021-03-12 16:38:46 ENOSYS is perfectly resonable here; it's equivalent to a kernel environmen that lacks unshare (old kernel or namespaces compiled out) 2021-03-12 16:39:37 yeah, I mean technically the go test suite should probably handle that case but I don't want to sign their CLA and I am therefore not interested to send them a clean patch 2021-03-12 16:41:04 if they want a CLA signature for trivial stuff like this they're on crack 2021-03-12 16:41:31 the patch is no different than a comment explaining the desired change on issue tracker 2021-03-12 16:41:44 what next are they going to require CLA to comment on tracker/? 2021-03-12 16:42:08 hehe, I don't a simple change like this is even copyrightable but they have a bureaucratic process for this and I would be suprised if they deviate from it in any case 2021-03-12 16:42:26 *think 2021-03-12 16:42:48 it's not but google's lawyers are allergic to the "not copyrightable" justification 2021-03-12 16:43:04 that's why they wasted our time on the corresponding issue in musl copyright file 2021-03-12 16:44:18 gotta love lawyers 2021-03-12 16:45:20 well, to be fair, they got a trial on that from Oracle very recently. I guess that makes you much more cautious 2021-03-12 16:45:43 this was before that 2021-03-12 16:51:02 Anyone here got any experience of packaging 'go' projects? Build seems to work but tests fail. 2021-03-12 16:51:08 I have zero experience of Go sadly. 2021-03-12 16:51:55 adhawkins: I have some experience 2021-03-12 16:52:58 This is what I have so far ikke: https://paste.debian.net/1189067/ 2021-03-12 16:53:57 adhawkins: I'll check it in a moment 2021-03-12 16:54:18 Thanks. This is what I get at the moment: https://paste.debian.net/1189068/ 2021-03-12 16:55:24 exit code 127 means some command cannot be found 2021-03-12 16:55:58 The binary is being generated in the 'bin' directory. Could that be why? 2021-03-12 16:56:04 That's how 'age' does it. 2021-03-12 16:56:46 No, it's something in the test suite 2021-03-12 16:57:02 Ok. I have no idea if the test suite works in general sadly. 2021-03-12 16:57:25 check webhook_test.go:62 2021-03-12 16:57:36 I'm just finishing up something 2021-03-12 16:57:56 ACTION have enough experience with go to not make packages :) 2021-03-12 16:58:35 Could it be this? err := os.Symlink("/bin/echo", "/tmp/with space") 2021-03-12 16:58:43 That's not line 62, but it's in that general area. 2021-03-12 16:59:10 mps: What's the ETA on a Zig upgrade? 2021-03-12 16:59:21 Current Zig is blocking llvm11 unfortunately 2021-03-12 16:59:53 Looks like it's trying to symlink /bin/echo into /tmp, and then execute that. 2021-03-12 17:00:09 Would you expect that to work? 2021-03-12 17:00:17 Cogitri: huh, you mean zig is blocked by llvm11 missing? 2021-03-12 17:00:42 adhawkins: no, it cannot work 2021-03-12 17:01:03 adhawkins: /bin/echo is a symlink to /bin/busybox 2021-03-12 17:01:12 mps: No, the current version of Zigs only works with LLVM10&CLang10 2021-03-12 17:01:21 busybox checks argv[0] to know what applet to execute 2021-03-12 17:01:26 So we'll need to upgrade Zig in order to upgrade llvm 2021-03-12 17:01:30 Yep, was just trying to work out how to type that :) 2021-03-12 17:01:38 Cogitri: yes, and because that I wait for llvm11 2021-03-12 17:01:39 Cogitri: can't we just move main/llvm to main/llvm10 and keep it for a while? 2021-03-12 17:01:47 So any way around that ikke? 2021-03-12 17:02:02 That's the only test that fails I think. 2021-03-12 17:02:07 nmeum: The problem is that zig needs both clang and llvm 2021-03-12 17:02:11 And we don't version clang 2021-03-12 17:02:13 ah 2021-03-12 17:02:18 And we can't take LLVM10 and clang11 2021-03-12 17:02:23 yeah I agree 2021-03-12 17:02:30 well, just update zig as part of the llvm11 upgrade? 2021-03-12 17:02:40 Cogitri: zig is in testing, so go ahead with llvm11 2021-03-12 17:02:46 + 2021-03-12 17:03:13 mps: I'll disable it then, you can re-enable it once you have it working with llvm11, okay? 2021-03-12 17:03:22 sure 2021-03-12 17:03:36 Thanks for taking a look at it 2021-03-12 17:03:46 np 2021-03-12 17:04:07 Is /bin/true also part of busybox? 2021-03-12 17:04:12 such things were reason to keep zig still in testing 2021-03-12 17:04:17 Trying to think of another command that could be used to test this. 2021-03-12 17:04:33 yes /bin/true is also part of busybox 2021-03-12 17:04:40 Ok, that won't work then :) 2021-03-12 17:04:48 you can check with apk info -W $(which true) 2021-03-12 17:04:58 or ls -l $(which true) 2021-03-12 17:05:06 just write a simple shell script and make it executable 2021-03-12 17:09:58 Ariadne: interesting, even on armv7 it returns a verge large positive number instead of a large negative number 2021-03-12 17:10:40 ikke: Will have to refresh my memory on how to apply a patch within a package build. 2021-03-12 17:10:53 I remember reading about it, but haven't actually had to do it yet. 2021-03-12 17:11:17 add a file ending with .patch to source 2021-03-12 17:11:21 it will automatically be applied 2021-03-12 17:11:44 Thanks ikke. Job for the weekend I suspect :) 2021-03-12 17:12:38 adhawkins: other general advise: no need to run go get, go buil will automatically fetch the required modules 2021-03-12 17:12:43 go build* 2021-03-12 17:13:41 huh, is base64 broken on aarch64? 2021-03-12 17:14:11 hmm, not in general 2021-03-12 17:14:39 ikke: I added that in case that was why the tests were failing. Thanks, will remove it again. 2021-03-12 17:14:47 ikke: in what sense 2021-03-12 17:15:00 mps: base64 -d returning garbled data 2021-03-12 17:15:35 No, user error 2021-03-12 17:15:54 ah 2021-03-12 17:16:10 bad paste in vim (not pasting in insert mode, causing characters to be missing) 2021-03-12 17:16:22 heh, happens 2021-03-12 17:17:07 please merge !19195 2021-03-12 17:18:02 it also fixes a go compilation problem with the newer version that was added that forces go module use 2021-03-12 17:19:31 Is it acceptable to create this shell script in the 'test' part of the package ikke? Or should it be done as part of a patch? If the latter, can it be marked as executable within the patch somehow? 2021-03-12 17:19:56 adhawkins: I would do it as part of the test suite 2021-03-12 17:20:03 though it would be a bit more elaborate 2021-03-12 17:20:20 that way, it could also be upstreamed 2021-03-12 17:20:25 So just something like: "echo -e '#!/bin/sh\necho\n" > /bin/echo-test" 2021-03-12 17:20:35 Oh I see, in the 'go' itself you mean? 2021-03-12 17:20:39 yes 2021-03-12 17:20:46 I'd have to learn some Go to do that :) 2021-03-12 17:22:47 Hi Folks, I have something on my mind and was wondering if someone here would be kind enough to help me out with a small issue I'm having with understanding the Diskless Build System of Alpine linux 2021-03-12 17:25:14 Ariadne: apparently there are more arches where this is broken than where it is working as expected (but the limit saves them) 2021-03-12 17:36:15 robin-rpr: Ask the question, and someone will answer if they know I'm sure. 2021-03-12 17:51:05 Sooo - sorry for interrupting your conversation @ikke - As the question goes, is it possible to Inject Files into an existing ISO Disk Image? I've seen BalenaCloud offer customized ISO Downloads in seconds and was wondering if I can do too with Alpine Linux ISO's in Diskless Mode. My educated guess is that Alpine Linux Diskless makes use of ISO-9660 and initramfs - Sounds good so far, kinda - So my effort was 2021-03-12 17:51:06 to: 2021-03-12 17:51:06 2. "Unzipping" the extracted /boot/initramfs-lts (GZIP) 2021-03-12 17:51:06 1. Mount the ISO with loop (Will mount read-only only!) 2021-03-12 17:51:06 3. Doing some modifications to the extracted Initramfs files (ie. maybe adding a file 'foobar.txt' to /newroot) 2021-03-12 17:51:06 4. Then, repack my Initramfs again. Again with GZIP =) 2021-03-12 17:51:07 5. Make a Copy of the mount in Step 1 to "somewhere/" 2021-03-12 17:51:07 6. Replace /boot/initramfs-lts with my edited Step 3 & 4 2021-03-12 17:51:08 7. Pack the whole thing in "somewhere/" with mkisofs (from apk add cdrkit) 2021-03-12 17:51:09 Outcome: The new ISO generated is half the Size of the old one (Obvious sign that something is wrong), its Partition Table is invalid (As we can expect). Mounting is not a problem though 2021-03-12 17:51:10 Well ... Then i discovered github.com/alpinelinux/mkinitfs 2021-03-12 17:51:11 Kinda made me feel like I have been using the wrong toolchain? But also it was apparent to me the first time I looked at this approach, that, I mean, it's naive to 2021-03-12 17:51:11 think copying the contents of the Mount (Step 5) would make any sense at all, as we are loosing so much information. 2021-03-12 17:55:05 PS: Was aware that ISO-9660 cannot be edited post-creation. So I thought there are things like pycdlib that can edit existing files in an ISO-9660, why don't just make use of that. But thats a number too sketchy for me. 2021-03-12 17:59:52 . 2021-03-12 18:00:00 robin-rpr: I am not sure if this is completely what you are looking for, but for an Alpine live CD I am using https://github.com/CloudI/live_cd/tree/master/alpine 2021-03-12 18:00:59 robin-rpr: the script genapkovl-cloudi.sh makes lots of files as part of the process 2021-03-12 18:04:17 Thanks for chiming in @okeuday! We are on the way, I created an custom ISO x86_64 with the github.com/alpinelinux/aports mkimage.sh. Also made great use of the genapkovl feature, which is wonderful! However, lets think we want to add a file after the ISO was already created. 2021-03-12 18:06:34 robin-rpr: I think of an ISO as read-only, so I would probably always modify the genapkovl script to add a file and recreate the ISO 2021-03-12 18:07:11 Gonna block builders for a little while with LLVM11 and resulting fallout 2021-03-12 18:07:49 So what inspired me was BalenaCloud, they kinda just figured this out and I wanna know how they did it. 2021-03-12 18:07:49 I thought they might do this: 2021-03-12 18:07:49 2. Store that somewhere on their Server 2021-03-12 18:07:49 1. Create their beloved BalenaOS.iso 2021-03-12 18:07:49 3. Wen I Login to BalenaCloud and Download a Image with my configuration they just take that BalenaOS.iso they have and inject those configuration files right in there. 2021-03-12 18:07:49 4. Not a second later I can download my customized OS 2021-03-12 18:11:29 I'm not sure this is #alpine-devel material, but you could just keep the "iso" as a folder, and add a few files each time before creating the iso 2021-03-12 18:14:07 you could use some tricks to avoid modifying the original build, like using overlayfs 2021-03-12 18:19:37 @okeuday: Jup! Good point there! Agree! But how is Balena archiving those super fast downloads. It seems impossible to think they aren't using some loophole for performance in their build strategy. 2021-03-12 18:19:37 @afontain: Also thanks for the fast response =) Would be happy to move this conversation somewhere else if this is offtopic for the channel =) Also, good point there. I tried something with overlayfs, but ultimately discarded it. But when u are already mentioning it I'll happy to dig down further to see if this might be the solution =) 2021-03-12 18:41:48 PS: To edit /boot/initramfs-lts I used this approach https://access.redhat.com/solutions/24029 2021-03-12 18:44:23 for creating the ISO i used https://github.com/t4nz/mkiso 2021-03-12 18:49:48 Whew, I think I'll have to do it the ugly way using pycdlib, wanting to drain out every last peace of performance this is my only option I guess ... 2021-03-12 18:50:20 *piece 2021-03-12 19:00:57 I like to use alpine in a systemd-nspawn container. If I login with systemd-nspawn -D -U --machine on my debian environment I get this message: "-sh: can't access tty; job control turned off" 2021-03-12 19:01:09 any clue how to solv this? 2021-03-12 19:02:21 try --console=interactive 2021-03-12 19:09:15 ikke, this is not an option of systemd-nspawn in debian ;-) 2021-03-12 19:09:34 hmm, ok 2021-03-12 19:09:54 ikke, is it an option under alpine? 2021-03-12 19:10:02 I checked on archlinux 2021-03-12 19:10:07 alpine has no systemd 2021-03-12 19:15:22 [09:42] ariadne, are you on? 2021-03-12 19:15:28 alarm failed 2021-03-12 19:15:29 to 2021-03-12 19:15:32 go off lol 2021-03-12 19:15:54 ariadne, you can read the transcript 2021-03-12 19:17:51 yeah that date works for me 2021-03-12 19:22:16 lol 2021-03-12 19:22:29 ikke, hm I use archlinux only local 2021-03-12 19:51:36 will this work in abuild https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18451/diffs 2021-03-12 19:52:21 I mean '|' (or) in ash '"pine64-lts"|"pinebook")' 2021-03-12 19:57:25 ariadne, yay 2021-03-12 20:04:32 Ariadne: on the matter of a write up, do you have anything worked out already or want to be the one to do it? 2021-03-12 20:11:06 i can do the writeup, but if you guys want to do it, i would not object 2021-03-12 20:11:23 i think dalias can make the strongest case 2021-03-12 20:11:50 I think the write up here is more a summary of the discussion so far, in this case 2021-03-12 20:12:15 oh, yes, i can do that 2021-03-12 20:15:21 okdo 2021-03-12 20:16:10 Ariadne: if you want to open a PM group (does zulip have that?) with Wesley and I, we can help review and such 2021-03-12 20:23:00 fuck if i know 2021-03-12 20:23:18 zulip is a browser tab i have begrudgingly pinned 2021-03-12 20:23:29 i am patiently waiting for them to come full circle and upgrade to IRC 2021-03-12 20:23:32 ;) 2021-03-12 20:24:41 zulip is basically irc with automatic bouncer saving your backlog 2021-03-12 20:24:55 which runs in the browser 2021-03-12 20:24:59 which is disgusting 2021-03-12 20:25:04 :) 2021-03-12 20:28:56 Ariadne: if you don't mind me asking, do you prefer she or they? 2021-03-12 20:29:47 https://twitter.com/weh_kaniini/ 2021-03-12 20:30:26 ah ok, thanks 2021-03-12 20:30:31 ACTION doesn't use twitter 2021-03-12 20:31:51 mps: (late answer) yes that works with ash 2021-03-12 20:33:21 Ariadne: I have now added you to a conversation 2021-03-12 20:37:43 yahal: last time I looked, didn't systemd-nspawn require systemd? 2021-03-12 20:37:56 afontain_: they use debian as host 2021-03-12 20:38:12 both on host and in the container, I mean 2021-03-12 20:38:22 ah 2021-03-12 20:39:57 afontain_, are you sure that on both "sites" systemd is needed? also the guest? 2021-03-12 20:40:36 ericonr: my pronouns are whatever 2021-03-12 20:42:28 ikke: thanks 2021-03-12 20:44:06 uhg wtf. if it does require it doesn't that defeat the whole purpose of having a container?! 2021-03-12 20:44:17 which is *not* having any relationship between what's inside and what's outside 2021-03-12 20:48:02 yahal: Arch Wiki "Note: systemd-nspawn requires that the operating system in the container uses systemd init (has it running as PID 1) and systemd-nspawn is installed in the container. Make sure that the systemd-container package is installed on the container system." 2021-03-12 20:48:32 afontain_, thx! 2021-03-12 20:49:13 but maybe that changed for all I know 2021-03-12 20:50:14 dalias: it's a "special" sort of container, and I don't think they try to advertise it as a general solution 2021-03-12 20:51:35 eew 2021-03-12 20:51:40 what is this for anyway? 2021-03-12 20:53:13 it sounds like just a broken, gratuitously systemd-NIH'd replacement for unshare(1) 2021-03-12 20:53:39 technically speaking it "boots" the system, so it runs init inside 2021-03-12 20:54:09 I don't really know much about it, just that arch does (can do?) chroot builds inside those 2021-03-12 20:54:38 but you could just do unshare ... /sbin/init 2021-03-12 20:59:03 ... being apparently --fork -cp 2021-03-12 20:59:21 but i can't really explain what it's about, you'd have to ask someone who uses it ;) 2021-03-12 21:01:03 dalias: it's "integrated" 2021-03-12 21:01:15 for example i think journal is automagically forwarded to the host 2021-03-12 21:01:24 eew 2021-03-12 21:01:30 which also does sound suspiciously like it defeats the purpose of containerization 2021-03-12 21:01:36 yes 2021-03-12 21:01:54 this is nothing new 2021-03-12 21:02:56 computing history is an endless repetition of fools trying to poke holes in encapsulations because they don't understand the whole purpose of them being there and think they're just there to impede something they're trying to get done 2021-03-12 22:09:43 ... wait, somebody is actually stupid enough to promote systemd-in-systemd? 2021-03-12 22:10:53 yo dawg I herd u like systemd 2021-03-12 22:14:38 iirc i nuked the 'here's how to do it' from my public repos because i realized people might be foolish enough to do it out of laziness. not out of active, harmful stupidity. 2021-03-12 23:28:02 Hi, does someone know how Rock Ridge Filenames are composed? Couldn't find any simple explanation online =( 2021-03-13 01:45:38 robin-rpr, what do you mean how they're composed? 2021-03-13 08:55:33 Hexagon is disabled in llvm11? 2021-03-13 08:57:05 mps: Yes, fails lots of tests in codegen on all arches 2021-03-13 08:57:41 I asked yesterday and the day before that if anyone needs it but Ariadne said that it's only needed for Snapdragon DSPs and we don't target those so we could disable it for now 2021-03-13 08:58:19 We can re-enable it once the LLVM11 port is complete (later today) if someone can get around to looking into those test failures since they look pretty serious 2021-03-13 08:58:42 And I have no clue how we're the only ones hitting that, codegen shouldn't be environment specific 2021-03-13 08:59:34 aha, ok. zig need Hexagon target 2021-03-13 09:00:36 that is so stupid 2021-03-13 09:01:08 well (a lot of things stupid imo, but who cares) 2021-03-13 09:17:27 [01:13:29] alpine/aports:master | Rasmus Thomsen | testing/thunderbird: disable for now, doesnt build with latest rust | http://dup.pw/alpine/aports/d17c4a092193 2021-03-13 09:17:33 WELCOME TO THE WORLD OF THE FUTURE 2021-03-13 09:18:36 thanks :) 2021-03-13 09:24:03 well since we're fucking shit up, who wants to go to GCC 11 2021-03-13 09:24:10 haha don't worry i am kidding 2021-03-13 09:45:35 That thunderbird thingie is because they were using something that has been a warning in Cargo's manifest for quite some time and that was made into an error now though 2021-03-13 09:46:29 running test builds on ppc64le, s390x, aarch64 and x86_64 of gcc 10.2.1_pre2 2021-03-13 09:46:36 will push once they complete 2021-03-13 09:46:51 Could you maybe wait with that? 2021-03-13 09:47:03 I'd prefer to get the LLVM11 stuff done first if that's fine with you 2021-03-13 09:47:10 sure, no rush 2021-03-13 09:48:08 Thanks :) 2021-03-13 09:52:50 i'm disappointed that nobody wants to update to GCC 11 ;) 2021-03-13 09:52:56 could be FUN 2021-03-13 09:54:05 9https://studentaffairscollective.org/wp-content/uploads/2015/09/FUN1.jpg 2021-03-13 09:54:45 yes 2021-03-13 09:54:51 exactly 2021-03-13 10:41:54 Cogitri: test build finished, i'll push when you're done with the builders and they are green 2021-03-13 10:51:32 Ariadne: Alrighty, currently waiting for Rust to finish building, I'll probably only need to rebuild some 10 more packages (which should be way quicker than Rust :) after that and then I'm done 2021-03-13 11:16:46 would missing hexagon support in llvm11 impact pmos in any way? 2021-03-13 11:18:25 I don't think they target Snapdragon DSPs either 2021-03-13 11:18:32 But best to ask them 2021-03-13 11:18:48 PureTryOut[m]: ^ 2021-03-13 11:18:55 Or is it PureTryOut[m]2? :) 2021-03-13 11:19:50 ollieparanoid[m]: 2021-03-13 11:23:34 I'm not sure what hexagon support means 🙈 2021-03-13 11:26:42 PureTryOut[m]2: snapdragon DSP coprocessor iirc 2021-03-13 11:27:02 MartijnBraam: do you know if we need that support? 2021-03-13 11:27:28 probably not used much but zig want to build it as targer 2021-03-13 11:27:34 target* 2021-03-13 11:27:42 mps: Can't we just disable that target in Zig too? 2021-03-13 11:28:14 Cogitri: probably (and that was my first idea) but not sure yet 2021-03-13 11:28:20 I mean in theory we could re-enable the Hexagon target and just disable the codegen tests for it but I don't think it makes sense to re-enable a target when we know it outputs broken code 2021-03-13 11:28:27 We have only closed hexagon stuff 2021-03-13 11:28:37 Would be neat if someone could look into the test failures though 2021-03-13 11:30:34 The only pmos people that might use a hexagon compiler are the people are reversing firmware, and those know how to build it if they need it 2021-03-13 11:32:34 Well, they'd be hit by the broken codegen too so ideally someone would fix that and we could re-enable it in Alpine 2021-03-13 12:17:12 Ariadne: Done with the LLVM11 stuff for now, thanks for waiting 2021-03-13 12:21:17 Any moment I can quickly restart gitlab? 2021-03-13 12:23:26 Fine by me 2021-03-13 12:41:44 Genuine question, not supposed to pick fault. Just trying to work out how the 'real' builds as seen in #alpine-commits sometimes fail? Doesn't stuff have to pass the CI builds before it gets merged? And if it passes them, why should it fail on the 'real' builds? 2021-03-13 12:42:23 1) mips64 and armhf do not have CI 2021-03-13 12:42:33 2) sometimes changes are pushed directly by devs 2021-03-13 12:42:50 3) The environment does also matters, which is not 100% equal 2021-03-13 12:43:26 So yes, ideally passing on CI would mean it would properly build as well, but it's not guaranteed 2021-03-13 12:44:40 Got it ikke. Didn't realise that sometimes stuff gets pushed directly. Makes sense now. It was x86 builds that I saw failing yesterday which prompted the question. I would generally expect that these would be the ones most tested by the devs. 2021-03-13 12:44:50 As I said, was a genuine question and not meant to pick fault :) 2021-03-13 12:44:59 Yes, understood 2021-03-13 12:45:38 Thanks for the info, always learning :) 2021-03-13 12:46:00 Know of any good 'Go' tutorials so I can try to work out how to create a file and make it executable for that package I was on about yesterday? 2021-03-13 12:46:14 https://tour.golang.org/welcome/1 2021-03-13 12:46:27 Great, will take a look. 2021-03-13 12:47:02 And some things are too big to be tested by CI 2021-03-13 12:47:04 If you have questions, feel free to ask 2021-03-13 12:47:08 Cogitri: that as well 2021-03-13 12:47:50 E.g. the LLVM stuff (as in the rebuilds, the new LLVM version themselves were tested on CI) was mostly just tested by me on my local machine since it'd take forever on CI 2021-03-13 12:48:13 And the chance of things working locally but on the builders was very slim in that case 2021-03-13 12:48:23 And I was available to fix stuff in case it goes wrong too 2021-03-13 12:51:31 All useful info, thanks guys. And thanks for the offer of help ikke. I'll try to work it out myself. I'm a developer for work, so it's 'just' a matter of learning a new language :) 2021-03-13 12:52:05 Right, time to tear my daughter away from Minecraft for lunch :) 2021-03-13 12:52:37 :D 2021-03-13 12:52:48 good luck 2021-03-13 13:04:19 She's off minecraft, not to get her off her phone :D 2021-03-13 13:05:59 Now to get... 2021-03-13 13:51:06 Is there any way to have dabuild skip the download and unpack steps so I can edit the source and run the build and test steps? 2021-03-13 13:51:21 Not doing this on an Alpine system so it's helpful to use the docker variant. 2021-03-13 13:52:37 What are you executing? 2021-03-13 13:53:27 I'm not sure what you mean ikke? Typically I run 'dabuild -rfK' in the packaging directory. 2021-03-13 13:53:50 Can I just run 'build' and 'check' and that will only do those two stages? 2021-03-13 13:53:54 yes 2021-03-13 13:53:59 Perfect, thanks. 2021-03-13 13:54:04 unpack prepare build check 2021-03-13 13:54:58 I don't want to do the unpack, as I want to edit the test files and then just re-run, 2021-03-13 13:55:37 right, the unpack part would be the first time only 2021-03-13 13:55:52 Yep. 2021-03-13 13:56:16 don't forget deps either 2021-03-13 13:56:23 after abuild -r fails, it removed the deps 2021-03-13 13:56:28 Yep, just spotted that when it couldn't find 'go' :) 2021-03-13 14:04:25 Does the 'check' function stop as soon as the tests fail? I've put in a 'ls -alR /tmp' at the end in readiness for checking stuff appears, but I'm not getting any output 2021-03-13 14:06:26 It would appear so, I've put an echo before and after the 'go test' and all I see is the before one... 2021-03-13 14:07:21 adhawkins: we have set -e defined in abuild, so that casues this 2021-03-13 14:07:30 not specific to the check function 2021-03-13 14:15:37 Ok, thanks ikke. Think I'm making progress, just about to attempt to create a patch. 2021-03-13 14:23:28 Ok, the patch is failing, presumably because I created it in the wrong directory. What is the current directory when the patch is applied? The unpack directory? 2021-03-13 14:25:55 builddir 2021-03-13 14:29:24 Ok, seems to have found the right file now, but it's failing to apply. Wonder if it's a tabs / spaces thing? 2021-03-13 14:29:51 The patch file seems to contain spaces, but the actual file is tabs I think. 2021-03-13 14:30:16 did you copy the patch through your clipboard? 2021-03-13 14:30:31 I did. Fair point. 2021-03-13 14:30:35 Let me try that again. 2021-03-13 14:30:40 yeah, that's not working 2021-03-13 14:30:47 (I base64 encode it in that case) 2021-03-13 14:31:07 Ok, patch file now contains tabs, let's try again. 2021-03-13 14:42:55 That seems to be working, just trying to wrap it all up. 2021-03-13 14:52:23 ikke: If you get chance, can you take a look over !19263 for me? 2021-03-13 14:52:51 It builds and installs locally. I can run the command and get its version and help. Haven't actually used it yet though so need to do some more testing probably. 2021-03-13 14:56:27 Just spotted the lint warning. Will fix that. 2021-03-13 15:02:02 Thanks for your Help @okeuday @afontain_ ! Implementing pycdlib in Node.js I'm able to get conversion speed in the 2 Seconds range, which is absolutely great! I think we figured this out =) 2021-03-13 15:03:06 Ok, think I've fixed the lint issue ikke. Be interested in your comments. Turned out to be a relatively trivial change. 2021-03-13 15:03:13 I might try to submit it upstream too. 2021-03-13 15:12:16 adhawkins: you're packaging up the "test" binary as well as webhook - just change the install command to refer to bin/webhook rather than bin/* 2021-03-13 15:14:14 Thanks minimal, hadn't spotted that. 2021-03-13 15:15:01 adhawkins: easy to spot if you do: zcat webhook-2.8.0-r0.apk|tar vtf - 2021-03-13 15:15:52 adhawkins: webhook was on my list of "things I'd like to package for Alpine but probably won't find the time to do so" so glad to see you working on it :-) 2021-03-13 15:15:55 Was just asking how to inspect the generated.apk. will add that to my workflow. 2021-03-13 15:30:22 also checkapk 2021-03-13 15:36:40 I generally don't develop on Alpine ikke, so that probably isn't available to me. 2021-03-13 15:40:45 adhawkins: checkapk is part of abuild 2021-03-13 15:40:56 Is the name of the patch file Ok ikke, minimal? 2021-03-13 15:41:09 ikke: I build on Debian using dabuild. 2021-03-13 15:42:30 adhawkins: don't think there's any hard-and-fast rule about it. I prefer filenames with numbers at the start as its obvious the order that patches may be applied 2021-03-13 15:43:07 BTW if you run apkbuild-lint on your APKBUILD file you'll see the various lint warning 2021-03-13 15:43:36 minimal, yeah, it was the rest of the name I was questioning. 2021-03-13 15:43:44 And I did run lint, but managed to miss the warning. 2021-03-13 15:43:47 I'm sort-of-building on Debian too - use an Alpine docker container to do the actual package building 2021-03-13 15:44:32 adhawkins: it is not complicated to set up alpine in lxc (or even qemu) on debian, that is how I did long ago when started to test alpine 2021-03-13 15:45:20 minimal: That's what dabuild does. Basically just fires up a docker container and runs the build in that. The advantage of doing it this way is that I know I'm always working on a 'clean' alpine when I build. 2021-03-13 15:45:50 minimal: the order of patches is defined by the order in sources 2021-03-13 15:46:16 yupe, and if you have qemu/binfmt setup then you can build for (some) other archs as well - I do armv7, aarch64, and x86_64 local builds that way 2021-03-13 15:47:11 ikke: I was thinking "conceptually", to make it apparent what the intended order is 2021-03-13 15:47:38 The doc I've been following does suggest using numbers in the patch names ikke 2021-03-13 15:47:55 adhawkins: That used to be the case, yes 2021-03-13 15:48:08 Ah ok, that could probably do with an update then ikke 2021-03-13 15:48:17 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Patches 2021-03-13 15:49:26 if it's just 1 or 2 patches, it does not matter that much 2021-03-13 15:49:35 aports with lots of patches still use that 2021-03-13 15:49:59 Ok, think I've fixed the 'test' binary being included. 2021-03-13 15:50:10 Anyone actually use webhooks confirm that this package actually works? 2021-03-13 15:52:00 adhawkins: I'll see if I can find some time over the next few days to try it out 2021-03-13 15:52:16 adhawkins: that's why we have packages generally start in testing 2021-03-13 15:52:29 Thanks minimal. I'm going to be actually using it myself soon too, so may well be able to test it out myself too. 2021-03-13 15:54:03 ikke: You happy with my 'Go' for creating the file? It was copied from an example and seems to work Ok :) 2021-03-13 15:55:50 adhawkins: yeah, looks find 2021-03-13 15:55:53 fine* 2021-03-13 15:55:58 Cool, ta. 2021-03-13 17:14:37 PureTryOut[m]2: I wonder why a lot of these kde packages keep failing on the builders while everything in CI was green 2021-03-13 17:14:58 PureTryOut[m]2: not blaming you, but wonder how we can get more reliable CI 2021-03-13 17:25:25 I don't know 2021-03-13 21:31:14 Ok, been doing some reading on webhook so think I know enough to test it if I build it into a container. !19263 is ready to merge, once fully tested I'll move it to community. 2021-03-14 10:27:31 https://lore.kernel.org/lkml/20210313075747.3781593-1-yuzhao@google.com/ 2021-03-14 10:28:46 'reports 96% fewer low-memory tab discards and 59% fewer OOM kills from fully-utilized devices and no UX regressions from underutilized devices.' 2021-03-14 10:28:58 very promising 2021-03-14 10:29:42 now userspace programmers can be less careful :) 2021-03-14 10:30:34 :D, like adding new lanes to a road just causes more traffic 2021-03-14 10:30:45 yes 2021-03-14 10:31:29 multigenerational LRU is good idea 2021-03-14 10:31:41 i had similar ideas a few years ago when i looked at this 2021-03-14 11:34:24 There's been a comment on my MR asking for a patch header to be added. Anyone point me at an example? 2021-03-14 11:35:24 Is it just a question of putting some test before the 'diff' header lines? 2021-03-14 11:36:21 adhawkins: Yes, just at the top (that someone was me) 2021-03-14 11:36:32 Common is to have: 2021-03-14 11:36:34 Description: 2021-03-14 11:36:41 Upstream: 2021-03-14 11:36:44 Url: 2021-03-14 11:36:55 Ok, thanks ikke. I'll sort that this afternoon. If you can point me at a 'good' example that'd help? 2021-03-14 11:37:32 I've submitted a Pull Request against upstream, which someone has 'approved' but it's not been merged (yet?) 2021-03-14 11:37:44 https://github.com/adnanh/webhook/pull/518#pullrequestreview-611610706 2021-03-14 11:38:32 Point to that pull request 2021-03-14 11:38:42 Ok, will do. Thanks ikke 2021-03-14 11:40:07 mps: are you already working on enabling zig again? 2021-03-14 11:40:23 if you don't have the time, I can look into it as well 2021-03-14 11:41:56 nmeum: yes, I tried yesterday and commented here. our llvm11 don't support Hexagon target and zig will not build without it 2021-03-14 11:42:52 also asked on #zig last night and andrewrk told that he is against building zig without this 2021-03-14 11:43:35 hm 2021-03-14 11:43:45 option is 'heavy' patching zig, or wait some time till someone fix our llvm11 2021-03-14 11:44:20 but ofc, feel free to do what you think is good 2021-03-14 11:44:47 I don't have any doubt in you and your work 2021-03-14 11:46:02 was the hexagon target enabled previously in our llvm10 package? because it looks like it has been present in zig for a while 2021-03-14 11:46:39 I think so 2021-03-14 11:46:42 ikke: The 'upstream' field, just signifies that this patch has been submitted upstream, yes? 2021-03-14 11:47:25 afaik currently hexagon target in llvm11 has some test issues on armhf/armv7 2021-03-14 11:47:27 nmeum: hexagon was disabled for llvm11 due to failing tests 2021-03-14 11:48:00 yeah, I got that from the backlog 2021-03-14 11:48:42 How does this look ikke? https://paste.debian.net/1189338/ 2021-03-14 11:48:42 kool 2021-03-14 11:48:43 but if it was enabled with llvm10 (where we also have a check()) it means upstream introduced a regression which broke hexagon on alpine/musl with llvm11, right? 2021-03-14 11:49:17 nmeum: I didn't looked at all in llvm11 2021-03-14 11:50:30 could be, can't say 2021-03-14 11:50:46 i just think that if the hexagon tests passed with llvm10 but don't with llvm11 i think we should just report that upstream 2021-03-14 11:51:25 Cogitri: ^ 2021-03-14 11:52:12 last two months I'm too busy with $day_jobs, so don't have much time for alpine, just trying to keep some things up-to-date and fix urgent things 2021-03-14 11:52:32 where I can, ofc 2021-03-14 11:52:32 Ok, I've pushed that ikke. Let me know if there's any changes you can suggest. 2021-03-14 11:52:52 mps: sure, I wasn't blaming you :p 2021-03-14 11:53:48 nmeum: Yup, we should report that upstream, but it's very weird stuff only breaks for us and not for others since the codegen is bad 2021-03-14 11:55:46 well, maybe upstream can help narrowing down the problem further :) 2021-03-14 11:56:39 adhawkins: it's merged 2021-03-14 11:57:43 Great, thanks. Will try to have a play with it for real to make sure it actually works! 2021-03-14 12:39:29 nmeum: Sure, but needs someone who has time and is willed to use Bugzilla 2021-03-14 16:33:44 the llvm bugzilla is especially annoying: 2021-03-14 16:33:47 > New user self-registration is disabled due to spam. For an account please email bugs-admin@lists.llvm.org with your e-mail address and full name. 2021-03-14 16:33:48 ( 2021-03-14 16:34:12 Oof :/ 2021-03-14 16:34:36 Yeah, Bugzilla is a pain to use in general 2021-03-14 16:41:56 ms github(tm) has flagged two of my accounts without explanation or getting back to when I've tried to contact their "support" (the second I registered after having waited a couple of months for them to get back to me) 2021-03-14 16:42:18 it's a bummer, since many upstream projects use ms github(tm) 2021-03-14 16:44:27 also dislike creating accounts in a bunch of self-hosted bugtracker systems though 2021-03-14 16:44:54 hopefully someone comes up with some kind of federated bug tracking system at some point, like email but better 2021-03-14 16:46:08 on gitlab.a.o you can also log in with your github.com or gitlab.com account, right? 2021-03-14 16:46:18 yes 2021-03-14 16:47:09 I think that's great 2021-03-14 16:54:24 github and gitlab 2021-03-14 16:54:35 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12270#note_147162 the hexagon test failure message (in case anyone has some low-level llvm/hexagon knowledge) 2021-03-14 16:54:46 currently not motivated enough to interact with the llvm bugzilla 2021-03-14 16:55:36 #llvm@irc.oftc.net ? 2021-03-14 16:55:57 I suppose they will tell me to create a bug report :D 2021-03-14 16:56:09 right :D 2021-03-14 16:57:22 could still be worth a mention than nothing at all 2021-03-14 16:57:30 I could drop a link there, if you don't mind 2021-03-14 16:58:31 no, go ahead 2021-03-14 17:05:33 done 2021-03-14 17:07:43 > bugzilla is probably a better place 2021-03-14 17:07:47 well thanks for trying at least :D 2021-03-14 17:08:11 "bugzilla is not accassible" 2021-03-14 17:08:15 accessible* 2021-03-14 17:22:10 invite-only tracker ;) 2021-03-14 17:36:27 how about having aports/templates/ with example APKBUILDs for various languages and build systems? (aports/templates/{golang,cmake,ninja,python,py3-library}/APKBUILD etc) 2021-03-14 17:36:48 ^ yes 2021-03-14 17:36:56 newapkbuild? 2021-03-14 17:38:09 oh, didn't know of newapkbuild(1), thanks! 2021-03-14 19:07:04 Done some testing on webhook, seems to work well. Just remind me, to move it from testing to community, do I need to bump pkgrel? 2021-03-14 19:07:12 no 2021-03-14 19:08:18 Ok, will do that now. 2021-03-14 19:12:15 Done: !19304 2021-03-14 20:12:15 have we figured out a clever way to deal with CVEs in static libraries (e.g. the go standard library) yet? are we rebuilding all packages in -stable and edge for DOS CVEs as fixed in the latest go release? 2021-03-14 20:13:22 I don't think we have anything smart yet 2021-03-14 20:13:39 until now we have been rebuilding everything 2021-03-14 20:13:51 not sure how we could improve on that 2021-03-14 20:17:19 hm, I don't want rebuild all go packages twice (once for edge once for stable) and spend N days fixing every build failure that shows up just for a denial of service in net/http and encoding/xml :S 2021-03-14 20:17:23 there has to be a better way 2021-03-14 20:18:51 What would you imagine? 2021-03-14 20:20:33 idk, at the very least it would be nice to only rebuild packages which actually use net/http or encoding/xml but we would either need to track that somehow or figure that out by inspecting the binary I guess? 2021-03-14 20:20:46 indeed 2021-03-14 20:22:04 go modules does not list stdlib modules 2021-03-14 20:28:26 Hm, I guess we could scan for what symbols the executable contains? 2021-03-14 20:28:29 we might be able to extract from the debugging information if a certain go binary uses a certain function (e.g. encoding/xml.NewTokenDecoder) in that case we would need to provide a -dbg subpackage for each go package 2021-03-14 20:28:49 I am not sure if that works for inlined functions though 2021-03-14 20:30:10 Right, that'd be problematic 2021-03-14 20:32:21 I mean technically we could patch the go compiler to also include symbols for inlined functions which point to a bogus address then or something along those lines 2021-03-14 20:32:43 it's not just a go problem though 2021-03-14 20:33:26 is go compilation slow too ? 2021-03-14 20:36:31 no matter how fast your compiler, rebuilding 2x 82 packages in community/ and 136 in testing/ will take a while though what I am more afraid of is the time it takes to fix packages which don't build cleanly with the latest release of go (mostly a problem in edge I guess…) 2021-03-14 20:37:13 and it's not just go, rust also prefers static linking (if i am informed correctly) 2021-03-14 20:40:26 Yup 2021-03-14 20:40:53 I wouldn't say prefer, it's basically a requirement with how crates work (they're usually microdeps and everything needs different versions) 2021-03-14 20:46:16 with vendored dependencies (i.e. those not tracked by apk) this problem becomes even harder because we also need to update the vendor dependencies / crate version in such cases :S 2021-03-14 20:47:15 the whole go/rust dependency model sucks, right. but in rust's case compilation is dead slow, dunno about go 2021-03-14 20:47:31 i wouldnt mind recompiling 82 minor C libs as they compile quite quickly usually 2021-03-14 20:47:38 To be honest, rustc is pretty fast for how much it compiles 2021-03-14 20:48:22 as I said complilation speed is not the problem 2021-03-14 20:48:49 nmeum: in this case the security issue is in the golang library so vendoring is not affected 2021-03-14 20:49:03 yes, I know 2021-03-14 20:49:46 a simple rebuild with the fixed golang version is all that is needed 2021-03-14 20:50:09 except for the fact that we have to rebuild >250 packages every time and 2021-03-14 20:50:16 and many of these may fail for some reason 2021-03-14 20:50:45 we're doing the same on FreeBSD but it seems fine so far 2021-03-14 20:50:52 Even if Rust were linked dynamically we'd have to recompile due to inlining and generics 2021-03-14 20:50:54 don't know about the exact number though 2021-03-14 20:51:01 Although I suppose the same applies for C++ templates 2021-03-14 20:54:21 nmeum: 406 in the FreeBSD portstree 2021-03-14 20:54:27 decke[m]: I also think the “vulnerability in $vendored go/rust dependency which is not tracked by the package system”-thing will become a problem eventually 2021-03-14 20:54:44 decke[m]: do you run the upstream testsuite as part of your ports? 2021-03-14 20:55:26 nmeum: depends on the actual port - for mass builds definitely no 2021-03-14 20:55:33 Yup, but I'm not sure if the security vulnerability in the 105th implementation of something in C because deps can't be shared as easily is better 2021-03-14 20:56:25 nmeum: yeah the hidden vulnerabilities in the toolchain are problematic to audit 2021-03-14 21:00:49 the problem is not new though - repoline compiler support was very similar 2021-03-14 21:01:09 if the C compiler has a security vulnerability how do you track it? 2021-03-14 21:09:26 sure. but it just gets extended to more code (the compiler, the statically linked standard library, statically linked "hidden" dependencies, …) 2021-03-14 21:10:08 more code → greater likelihood of bugs 2021-03-14 21:13:02 anyways: given that tomorrow is monday I personally can't rebuild all go packages atm and take care of issues that might (or might not) show up the next few days, wouldn't mind if someone else does it though 2021-03-14 23:56:47 should I approve own MR on aports when i feel it's finished, or its used in other purpose? 2021-03-15 00:17:10 JuniorJPDJ: I think that is for developers, who can merge the MRs but want someone else to do it/look at it too, and possibly for maintainers when someone else does an MR for a package they maintain 2021-03-15 00:17:15 ACTION is guessing 2021-03-15 00:18:15 JuniorJPDJ: I think you just need to remove the "WIP: or "Draft:" prefix from your MR when you feel you're ready (and keep it when you don't) 2021-03-15 00:18:50 so it's the same I was thinking about, but I'm suprised that I've ability to click approve there 2021-03-15 03:42:17 JuniorJPDJ: you're better off pinging @teams/mentors 2021-03-15 03:42:42 approving it yourself won't do anything 2021-03-15 03:42:54 if you need a sponsor, @teams/mentors will hook you up with somebody 2021-03-15 06:58:26 moning 2021-03-15 06:58:45 s/moning/morning/ 2021-03-15 06:58:45 ncopa meant to say: morning 2021-03-15 06:59:12 congrats with the llvm11 2021-03-15 07:08:03 Ariadne: thank you for following up nagios issue. i had same fix in my queue last friday but got distracted 2021-03-15 07:39:08 Ariadne: sponsor? 2021-03-15 08:33:05 ncopa: Yup, glad we have llvm11 now, most things (other than crystal & zig) have been ported by now 2021-03-15 08:36:41 Cogitri: crystal builds with llvm11, though it fail on some tests 2021-03-15 08:36:57 crystal 0.36.1 2021-03-15 08:38:29 zig 0.7.1 also need llvm11, though problem is hexagon, but you know this 2021-03-15 08:39:20 Yup, hopefully we should be able to fix that soon 2021-03-15 08:39:50 I'll enable the hexagon target in a bit and just disable its test for now, now that we've reported it upstream we can't really do much other than wait anyway 2021-03-15 09:01:36 what is hexagon? 2021-03-15 09:03:13 snapdragon DSP coprocessor if I understand correctly. Zig wants to be able to generate code for it. llvm11 fails code generation tests for it 2021-03-15 09:04:23 (and zig upstream doesn't want to make it easy to randomly disable targets) 2021-03-15 09:04:24 Yup, I doubt anyone ever uses that target so having a slightly broken Hexagon target is better than having to patch Zig, potentially breaking that too and deviating from upstream 2021-03-15 09:05:02 Quite so 2021-03-15 09:05:53 I'd say patch zig to generate a warning/error message when hexagon target is specified 2021-03-15 09:06:03 want to make it easy to randomly disable targets -> why? 2021-03-15 09:06:54 since a primary use case of zig is cross compiling, you have to patch/fork zig if you want to disable targets. it's not officially supported 2021-03-15 09:08:19 I don't like it when languages don't trust distros to know what's best 2021-03-15 09:10:45 It is what it is. He's not saying you cannot, just that they do not want to deal with the testing matrix for it 2021-03-15 09:28:59 nmeum: Have you opened a bug upstream already? 2021-03-15 09:31:31 detha: yes, I asked Andrew about this few days ago, your quote above is his answer to my question 2021-03-15 09:32:19 af23b53c5edd4be6f0fe72663de3f7ff848ab663 2021-03-15 09:32:24 Cadey: no, I was too annoyed by the fact that account registration in their bugzilla is closed 2021-03-15 09:32:41 Ah, that's fair 2021-03-15 09:33:07 mps: yup, been following this from the sidelines ;) 2021-03-15 09:33:24 test failure log is here https://gitlab.alpinelinux.org/alpine/aports/-/issues/12270#note_147162 if you want to convince them to create an account for you ;) 2021-03-15 09:33:34 detha: heh, didn't noticed this 2021-03-15 09:34:09 nmeum: Wrote them an email, let's see 2021-03-15 09:34:12 mps: your good works don't go unnoticed 2021-03-15 09:34:27 Cogitri: nice 2021-03-15 09:34:32 keep me posted 2021-03-15 09:34:40 Will do :) 2021-03-15 09:34:42 maybe hexagon can be selectively disabled on arm32, zig still doesn't build on it 2021-03-15 09:34:42 ty 2021-03-15 09:35:04 mps: I don't think that's necessary 2021-03-15 09:35:25 that's better than 2021-03-15 09:35:40 i patched out hexagon support for zig, but it still failed with some other error I didn't get around to debugging yet but maybe I made a mistake in my patch. retry with that llvm change from above maybe 2021-03-15 09:35:42 shipping broken hexagon? 2021-03-15 09:36:23 mps: zig. crystal will they become serious languages or be the next D lang? 2021-03-15 09:36:26 > sed -i ./src/codegen/llvm.zig -i ./cmake/Findllvm.cmake -i ./lib/std/target.zig -i src/target.zig -e '/Hexagon/d' -e '/hexagon/d' 2021-03-15 09:36:29 travankor: not broken, iiuc disabled 2021-03-15 09:36:33 ^ this should be sufficient to disable hexagon in zig i think 2021-03-15 09:36:40 just for future reference 2021-03-15 09:37:17 travankor: zig have good chances, not sure about crystal (I have hope only) 2021-03-15 09:38:03 let's all have hope :D 2021-03-15 09:39:29 zig is more system oriented while crystal is more user space programs oriented 2021-03-15 09:40:27 ( plain old C is still best, if we don't count forth) 2021-03-15 09:40:42 I'm curious how Zig vs Rust will play out 2021-03-15 09:41:30 They're both system languages, Rust has way more industry support and has been around for longer and is a bit nicer to write for folks which know C++ 2021-03-15 09:41:32 depends will hipster mindset prevail 2021-03-15 09:41:48 But Zig has some really fancy stuff too like their colorless functions 2021-03-15 09:42:18 Indeed. Rust has the advantage of being there first. Zig has the advantage of not making Rust's mistakes 2021-03-15 09:43:10 as in all human works/activities best solution is least popular 2021-03-15 09:43:10 My only concern for zig is that they keep threatening to add a package manager to it 2021-03-15 09:43:27 s/is/are/ 2021-03-15 09:43:27 mps meant to say: as in all human works/activities best solution are least popular 2021-03-15 09:50:12 zig is also not memory safe, but let's hope they add that in the future 2021-03-15 09:54:23 Retrofitting memory safety into a language usually doesn't work too well 2021-03-15 10:00:26 heh, in search for holly grail^W^Wmemory safety 2021-03-15 10:00:55 well, zig hasn't reached 1.0 yet so I guess they are still open to breaking existing stuff 2021-03-15 10:01:03 rust also used to be garbage collected in early versions 2021-03-15 10:01:28 borrow checker for zig? 2021-03-15 10:01:33 https://github.com/ziglang/zig/issues/2301 etc. pp. 2021-03-15 10:02:48 The problem is that either you break about every Zig package out there by making it a huge, huge breaking change in the language or you make it opt-in which means next to no one will use it (see D for that one) 2021-03-15 10:03:17 D has some neat security features but next to one uses it because it's optional so only a tiny amount of libs use it 2021-03-15 10:36:28 nmeum: https://bugs.llvm.org/show_bug.cgi?id=49592 2021-03-15 10:37:24 nice, thanks for taking care of this 2021-03-15 10:39:12 oh my... /home/ncopa/aports/community/ceph/src/ceph-15.2.9/src/tools/ceph-dencoder/osd_types.cc:34:1: fatal error: error writing to /tmp/ccDEefOi.s: No space left on device 2021-03-15 10:39:25 seems like rebuilding packages for python 3.9 will be harder than expected 2021-03-15 10:48:15 nld-5 disk is full 2021-03-15 10:48:36 JuniorJPDJ: yes, somebody to commit the APKBUILD on your behalf 2021-03-15 10:58:41 Ariadne: I'd like to become maintainer, how does it work then? 2021-03-15 11:06:28 does not change anything 2021-03-15 11:06:53 soembody has to commit the APKBUILD on your behalf until you gain the rights to do it yourself 2021-03-15 11:07:49 the people who commit packages on your behalf can nominate you for developer rights 2021-03-15 11:08:58 but there is no path for going from zero to developer rights in alpine 2021-03-15 11:26:36 JuniorJPDJ: Just do what I've been doing. Create merge requests against the 'aports' repository. They're generally applied within a day or two. 2021-03-15 11:27:28 ikke: i cleaned up some stuff and now it runs again 2021-03-15 11:27:44 I'm now maintaining 9 packages on this basis. Hadn't even considered what's required to become an 'official' developer. This process seems to work well enough for me. I guess if I convince people that my commits are generally 'safe' then someone may nominate me. But I hadn't given it much thought. 2021-03-15 11:27:50 ncopa: noticed, thanks 2021-03-15 11:28:07 re zig vs rust, i read that rust is not dynamic linking friendly. is zig also unfriendly to dynamic linking? 2021-03-15 11:29:21 adhawkins: mine's floating here for a while 2021-03-15 11:29:48 most people just create merge requests 2021-03-15 11:29:50 Ok. I guess you need to find someone interested in it enough to take a look and double check it before it's merged. 2021-03-15 11:30:10 If you post the MR number here, it might trigger someone into looking at it. 2021-03-15 11:30:23 e.g.: !19304 2021-03-15 11:30:26 Rust isn't dynamic linking friendly of how the crates work (microdeps) and that dynamic linking doesn't have that many advantages when using generics lots (since that means Rust will generate new code for each specific instantiation with a different type), but that also applies to C++ templates 2021-03-15 11:30:47 ncopa: didn't noticed that on zig 2021-03-15 11:31:10 I suppose Zig shouldn't have that problem (yet) since it doesn't have a package manager (yet) so it doesn't have as many microdeps 2021-03-15 11:31:19 some of my MRs are merged pretty quickly, others.. not so fast... =) 2021-03-15 11:31:22 though I didn't used it for anything serious, just played a little with it 2021-03-15 11:31:31 adhawkins: I mean that's not a problem, I was just curious why I've permissions to "approve" MR 2021-03-15 11:31:44 Yeah, similar here omni. Most are within a couple of days which is fine by me. 2021-03-15 11:31:45 JuniorJPDJ: that's gitlabs default 2021-03-15 11:31:52 JuniorJPDJ: Yeah, now sure what the 'approve' status actually does. 2021-03-15 11:31:59 Not much 2021-03-15 11:32:01 Cogitri: what i wonder is how zig works, if it is like rust and c++, with copy/paste like templates or if it does things differently 2021-03-15 11:32:03 Not sure how comptime works in Zig (as in does Zig create a new, inlined versions if the comptime func is created with a different type) 2021-03-15 11:32:12 ikke: makes sense xD 2021-03-15 11:32:16 only bugs and sec fixes need quick merge, sometimes 2021-03-15 11:32:33 The opensource version of gitlab does not allow a lot of control with that 2021-03-15 11:33:17 ncopa: I don't really see a way to avoid copy/paste for templates/generics unless you were to use dynamic dispatch which is a pretty slow in comparison 2021-03-15 11:34:04 swift apparently managed to solve that 2021-03-15 11:34:06 JuniorJPDJ: but approving your own MR does not make a lot of sense at least 2021-03-15 11:34:12 https://gankra.github.io/blah/swift-abi/ 2021-03-15 11:35:12 im curious about comments: !19176 2021-03-15 11:37:14 ncopa: Thanks, I'll give that a read 2021-03-15 11:37:28 But I don't think Rust will ever be dynamic-linking first, if only because of how crates currently work 2021-03-15 11:43:37 ncopa: what about add armv7 iso target to scripts? 2021-03-15 11:44:08 or, maybe only -virt iso 2021-03-15 11:57:19 Cogitri: I also don't think that rust will ever be dynamic-link-friendly, which is why I am in doubt if it is a good idea to use it as a C replacement 2021-03-15 11:58:27 mps: what bootloader should we use for -virt-armv7? uefi? 2021-03-15 12:08:27 >>> base-package: Updating the main/x86_64 repository index... 2021-03-15 12:08:30 ERROR: APKINDEX.tar.gz: BAD signature 2021-03-15 12:08:43 This is happening in a test suite once in a while.. 2021-03-15 12:22:56 i'm still primarily bullish on modern C++ 2021-03-15 12:23:14 you can derive many of the same benefits in rust by writing modern C++ 2021-03-15 12:23:30 But C++ is still a huge mess imho 2021-03-15 12:24:48 the modern parts are not too bad 2021-03-15 12:24:51 modules will fix a lot 2021-03-15 12:26:07 there are languages people complain about, and languages people don't use 2021-03-15 12:26:28 I've been learning a lot about C++20 lately, it is not so bad what they're doing with the language 2021-03-15 12:26:37 i think rust is useful for a lot of things. i would like to see a world where apk-tools is written in rust. 2021-03-15 12:26:47 unfortunately in practice, rust needs to change a lot 2021-03-15 12:26:50 to make that happen 2021-03-15 12:31:31 Count me in if you want to RIIR something :p 2021-03-15 12:32:04 C++ at work is not that much fun and we wrap about the entire std to make it usable 2021-03-15 12:32:18 usable as in doesn't blow some dev's foot off every second day 2021-03-15 12:34:34 ncopa: sorry, my link is unstable, just read backlog on irclogs.a.o. yes uefi bootloader for armv7 -virt will ok 2021-03-15 12:34:44 !19137 =) 2021-03-15 12:35:37 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19137/diffs#dd7da270a4303143372d2bf9d092967c7f14f9aa_0_7 2021-03-15 12:36:32 ikke: same as for sccache you mean? 2021-03-15 12:36:33 'Those who don't understand Unix are condemned to reinvent it, poorly.' - Henry Spencer 2021-03-15 12:37:38 same applies to langs 2021-03-15 12:38:50 'those who don't understand C are condemned to reinvent it, poorly' ? except they're all hell-bent on *not* reinventing it (which is why they fail) 2021-03-15 12:39:51 :) 2021-03-15 12:40:34 ACTION agrees 2021-03-15 12:40:53 unfortunately programming language design is a bit out of my forte 2021-03-15 12:41:14 Ariadne: having them in lua would be more than enough ♥ 2021-03-15 12:41:23 no 2021-03-15 12:41:26 never 2021-03-15 12:41:29 that is not happening 2021-03-15 12:42:27 apk does a lot of things that really require a C-like programming language 2021-03-15 12:42:37 not to mention the solver would take forever if it were in lua 2021-03-15 12:42:48 b-b-b-b-but lua-jit :< 2021-03-15 12:42:49 Let's not use a duck typed lang for that :p 2021-03-15 12:43:19 I'll always be religiously attached to C 2021-03-15 12:43:37 jvoisin: we begrudingly supply a lua binding. that's all you're getting 2021-03-15 12:43:40 :D 2021-03-15 12:44:09 ncopa: I have armv7 iso with virt (linux-edge-virt) which boots in uefi mode and grub as bootloader 2021-03-15 12:44:21 👍 2021-03-15 12:44:28 the overarching problem with new languages is that they all focus on the frontend: language theory, guarantees for users, how to program comfortably, etc. 2021-03-15 12:44:39 made it with some hacks, though but it works 2021-03-15 12:44:47 skarnet: if i were to do a programming language it would just transpile to C 2021-03-15 12:44:56 its the only way to do this sanely 2021-03-15 12:45:00 and they all forget, or try to make people forget, how hard the backend part is 2021-03-15 12:45:25 but i have no desire to do this 2021-03-15 12:45:34 i.e. interaction with Unix (and maybe other systems), portability on every arch, how to design a sane runtime, etc. 2021-03-15 12:45:48 which is the whole part that C has down 2021-03-15 12:46:02 and has never been replicated so far because it kinda needs 40 years of experience 2021-03-15 12:46:18 Ariadne: vlang.io ? 2021-03-15 12:46:28 go away 2021-03-15 12:46:39 krkr 2021-03-15 12:46:39 first you're suggesting lua, now you're suggesting vaporware 2021-03-15 12:47:08 and yes, transpiling to C benefits from the strengths of C, its backend, while providing a new frontend, so I'd say it's the best we can get nowadays all-in-all 2021-03-15 12:47:38 however, C itself clearly shows its age and would need some rework to support modern architectures better 2021-03-15 12:48:00 but it's not sexy so it doesn't get any funding or effort 2021-03-15 12:48:06 I think it's sexy 2021-03-15 12:48:20 so do I, but we're clearly kinksters, not mainstream 2021-03-15 12:48:28 tbh what i really want is a macroassembler that isn't hot garbage 2021-03-15 12:49:16 same shit, all the low-level stuff is disregarded by moneyed interests 2021-03-15 12:49:32 with proper funding and research we could do that 2021-03-15 12:56:29 libucontext could be mostly portable code with a real macroassembler :) 2021-03-15 13:02:21 Ariadne: Let's write it in Vala then :D 2021-03-15 13:02:42 hi can i borrow channel ops for a minute 2021-03-15 13:04:10 :D 2021-03-15 13:04:22 Here is an @ 2021-03-15 13:05:39 in all seriousness if vala didn't come with glib baggage 2021-03-15 13:05:43 it would be ok 2021-03-15 13:06:14 You can use Vala in posix mode, then it is glib-less 2021-03-15 13:07:04 does it come with a useful runtime tho 2021-03-15 13:08:32 I suck at packaging ruby gems, or am not motivated enough and just roll my head at the keyboard and see what happen 2021-03-15 13:09:16 Ariadne: Well, it comes with libc if you use it w/o glib 2021-03-15 13:10:28 ah, so you get a syntax sugarred footgun instead of a regular footgun 2021-03-15 13:12:32 Yup 2021-03-15 13:16:12 Although it's less of a footgun because we'd get automatic reference counting and stuff like that 2021-03-15 13:16:23 my main complaint with zig is @import sucks 2021-03-15 13:16:26 like 2021-03-15 13:16:34 that is really maximum suckitude 2021-03-15 13:16:42 first of all, why is it '@import' 2021-03-15 13:16:51 its a programming language, not twitter 2021-03-15 13:17:06 second of all, why would you ever duplicate javascript semantics for this 2021-03-15 13:18:23 Ariadne: re: backend. Nim transpiles to C 2021-03-15 13:18:35 no 2021-03-15 13:18:36 go away 2021-03-15 13:19:20 I haven't used it 2021-03-15 13:19:26 nim, like all the rest of these hipster languages don't actually solve real world problems 2021-03-15 13:19:27 just heard of it 2021-03-15 13:19:31 rust is the only one that attempts to 2021-03-15 13:19:44 unfortunately rust gives you a new set of problems in exchange 2021-03-15 13:20:08 rust is literally many orders of magnitude more complex than C++ 2021-03-15 13:20:29 Is it? 2021-03-15 13:20:35 absolutely 2021-03-15 13:20:53 It takes a little getting used to to get it working compile time but I'd argue it'd magnitudes less complex during runtime in return 2021-03-15 13:21:10 a person with a competent computer science education can be sufficiently competent in C++ within a week of picking it up 2021-03-15 13:21:17 I much rather have a compile error with a clear error message than a memory corruption in production 2021-03-15 13:21:17 with rust, you will never ever learn the entire language 2021-03-15 13:21:21 it is not possible 2021-03-15 13:21:29 even the people in zulip do not know the whole language 2021-03-15 13:21:44 I doubt anyone knows the whole C++ language :D 2021-03-15 13:21:48 they just pick up the parts they care about 2021-03-15 13:22:02 can't you do that with rust as well? 2021-03-15 13:22:23 Yeah, I don't really see the argument here 2021-03-15 13:22:27 Cogitri: no, but there's still a lot less to learn. it is doable 2021-03-15 13:22:53 Both C++ and Rust are rather complex languages but Rust doesn't have any of the blowing-your-foot-off stuff 2021-03-15 13:23:05 that's not really true 2021-03-15 13:23:13 there's plenty of ways to shoot yourself in the foot with rust 2021-03-15 13:23:21 Hm, personally I found Rust like 10x easier to learn than C++ 2021-03-15 13:23:36 for the features you use, sure 2021-03-15 13:23:44 the rust documentation is obviously much better 2021-03-15 13:23:49 Everytime GCC unleashes a storm of error messages because of an error within an error within an error in some arcane STL I wished I used Rust 2021-03-15 13:23:53 the problem is that rust has thousands of features 2021-03-15 13:24:08 and most concepts are unrelated to each other 2021-03-15 13:24:22 i agree with ncopa that swift is interesting 2021-03-15 13:25:09 swift seems to be a middle ground, it's a very simple language but it still tries to keep you from shooting yourself in the foot 2021-03-15 13:25:15 rust wants you to spell out all details 2021-03-15 13:25:40 what i want as a programmer is for the compiler to figure out the details 2021-03-15 13:25:48 that's literally why we made compilers 2021-03-15 13:26:15 that means bloated compilers :) 2021-03-15 13:26:24 And lots of magic 2021-03-15 13:26:30 ^ 2021-03-15 13:26:44 I feel like Rust has found a nice balance between being somewhat nice to write and still being explicit about what happend 2021-03-15 13:26:50 happens* 2021-03-15 13:27:43 any C programmer will howl with laughter at the thought that Rust (or anything else than C, really) is explicit about what happens 2021-03-15 13:28:09 yes, rust is just making you be verbose for the sake of verbosity 2021-03-15 13:28:33 "a".to_string() 2021-03-15 13:28:41 there is no true explicitness in imperative execution environments 2021-03-15 13:29:31 erionr: The separation of &str vs String is pretty nice though 2021-03-15 13:29:38 ? 2021-03-15 13:29:42 why is that nice 2021-03-15 13:29:56 Because you know whether a string is immutable or not 2021-03-15 13:30:23 oh, i thought you were saying it is nice that there is a low-level string type with the same broken semantics as C strings 2021-03-15 13:30:25 ;) 2021-03-15 13:31:00 C strings are cool, some libc-interacting Rust code has to do "a\0" to declare strings :( 2021-03-15 13:31:19 [07:26:14] that means bloated compilers :) 2021-03-15 13:31:19 [07:26:22] And lots of magic 2021-03-15 13:31:21 also, not really 2021-03-15 13:31:31 everyone should do null-terminated strings with a length member 2021-03-15 13:31:42 swift compiler is much less bloated than rustc 2021-03-15 13:31:43 :D 2021-03-15 13:32:31 Cogitri: I don't program enough in Rust to actually know; just some stuff feels unnecessarily verbose. same as i: u8 = 1; array[i as usize] = ... the usize cast being necessary at all 2021-03-15 13:33:14 rustc lets you cast from floating point to integral types 2021-03-15 13:33:37 even if it is known that the floating point value cannot be represented meaningfully in the integral domain 2021-03-15 13:33:41 e.g. NaN or Infinity 2021-03-15 13:33:58 and without an unsafe{} block! 2021-03-15 13:34:02 ericonr: It's nice that it's explicit about casting numbers at times though, not nice when a C compiler just silently lets you pass an i32 into something which u32 which will blow up when you have negative values 2021-03-15 13:34:26 Ariadne: if you want to cover those grounds use T::try_from which will check if the value can be converted 2021-03-15 13:34:33 err 2021-03-15 13:34:38 what i am saying is 2021-03-15 13:34:39 it converts it 2021-03-15 13:34:42 to garbage 2021-03-15 13:34:56 Cogitri: yes, it's a hard balance to reach 2021-03-15 13:35:14 but the u8/i8 thing is a big annoyance 2021-03-15 13:35:17 `let foo: i64 = f64::INFINITY as i64` 2021-03-15 13:35:19 will compile 2021-03-15 13:35:24 a bunch of projects only test their stuff on x86_64 2021-03-15 13:35:26 and i64 will just be garbage 2021-03-15 13:35:30 er, foo 2021-03-15 13:35:46 and then you get signature errors mixing functions that take i8 from c_char 2021-03-15 13:36:01 Fair, that can be a bit annoying 2021-03-15 13:36:11 i mean, use what you want 2021-03-15 13:36:17 It's also a bit annoying in GTK world where cairo mostly takes f64s and pango f32 2021-03-15 13:36:40 i find that rustc tries to enforce the wrong things tho 2021-03-15 13:37:13 for example i am writing an emulation engine in rust but i am thinking i might give up soon 2021-03-15 13:37:56 the benefits i get from rust (ML-like type composition) are outweighed by the fact that rustc needs every minutia explained to it 2021-03-15 13:38:14 even ghc is more capable 2021-03-15 13:39:38 GHC also supports dynamic linking but breaks ABI when you move around lines of code :P 2021-03-15 13:39:54 And Haskell code is way slower when you dynamically link 2021-03-15 13:40:29 Because huge parts of the optimizer of ghc rely being able to optimize throughout all compilation units 2021-03-15 13:41:11 Ariadne: I'm curious what's so verbose in your opinion? I feel like my Rust code isn't that much effort to writr 2021-03-15 13:41:22 what have i done... i deeply regret starting to talk about languages ... :) 2021-03-15 13:41:31 ncopa: vim or emacs? 2021-03-15 13:42:08 Heh 2021-03-15 13:42:10 Cogitri: in an emulator, you have giant blocks of memory which represent the system RAM 2021-03-15 13:42:20 Vimacs 2021-03-15 13:42:27 Cogitri: this leads to lots of superfluous casting in rust 2021-03-15 13:43:11 say you have an instruction that takes a base, and offset, and does a write 2021-03-15 13:43:44 in rust you would have to cast the offset 2021-03-15 13:43:59 i guess what im disapointed of, that those new languages solves some of the problems with C, but not all, while insist of being replacement of C 2021-03-15 13:44:08 i guess C is not going anywhere anytime soon 2021-03-15 13:44:08 unless everything is usize 2021-03-15 13:44:59 ncopa: to paraphrase jwz, "i guess i'll stick to C, since it's the only way to write portable programs" 2021-03-15 13:45:16 exactly 2021-03-15 13:45:43 and same if you need dynamic linking 2021-03-15 13:46:56 it looks like apple did a good thing with swift 2021-03-15 13:47:05 i also think memory-safety issues are not the main concern with C 2021-03-15 13:48:06 Ariadne, what hardware are you emulating? 2021-03-15 13:48:31 tehcloud: audacious has like 15 different machines it emulates for various chiptunes 2021-03-15 13:48:42 ahhh... I see, sound chips 2021-03-15 13:48:50 not just sound chips 2021-03-15 13:48:57 CPUs as well 2021-03-15 13:49:08 yeah, in the case of the NES the sound chip is on the CPU 2021-03-15 13:49:14 audacious has a full PS1 and PS2 emulator built into it 2021-03-15 13:49:24 damn 2021-03-15 13:49:28 a full copy of desmume too 2021-03-15 13:49:43 I've emulated a bunch of sound chips, about to take on the YM2612 and maybe some other Yamaha FM synths :) 2021-03-15 13:50:29 what i do like about rust is that i can teach rustc how to validate things 2021-03-15 13:51:22 for example, if you are simulating firmware, you can teach rustc how to validate that the simulated firmware behaves correctly 2021-03-15 13:51:41 based on trait inheritance 2021-03-15 13:53:58 cargo is a supply chain nightmare tho 2021-03-15 13:55:10 tehcloud: but yeah anyway the goal is to replace crappy emulation cores written by teens (mostly me ~15 years ago) with something good 2021-03-15 13:56:27 emulator development is a hell of a rabbit hole... :p 2021-03-15 13:57:36 Ariadne: speaking of supply-chain, do you know if there are plans to build alpine packages hermetically? 2021-03-15 13:58:13 yes, `abuild rootbld` 2021-03-15 13:58:51 literally generates a clean environment for building 2021-03-15 13:58:56 separate from the host 2021-03-15 13:58:58 I think almost everyone but distros quite like Cargo and microdeps, it's super nice from a dev standpoint 2021-03-15 13:59:08 uhh 2021-03-15 13:59:13 actually as a dev 2021-03-15 13:59:16 i do not like microdeps 2021-03-15 13:59:31 Does not work in lxc without SYS_CAP_ADMIN though 2021-03-15 14:01:26 oh no, i missed out on the language flamewar fun :( 2021-03-15 14:02:26 Ariadne: if not memory-safety what do you believe to be the main concern with C? 2021-03-15 14:04:22 nmeum: the greater superset of generalized logic errors 2021-03-15 14:05:00 Hm, I quite like microdeps for some things, e.g. in the thingie I'm currently working on I was able to use the oauth crate that implements oauth, token refreshes etc. correctly for me, would've taken quite some time to get that right without it 2021-03-15 14:05:10 bruh 2021-03-15 14:05:12 oauth 2021-03-15 14:05:13 But it's annoying when some minor thing pulls in an entire kitchen sink 2021-03-15 14:05:21 is 5 minutes of work as a client 2021-03-15 14:05:44 Ariadne: so undefined behaviour in general? 2021-03-15 14:06:05 nmeum: correct 2021-03-15 14:06:26 Ariadne: Not with csrf tokens and automatic refreshes when the token goes invalid 2021-03-15 14:07:39 if token_invalid() { refresh_token() } logic should only be an additional 1 or 2 minutes really 2021-03-15 14:08:26 i mean, i get what you're saying, but a traditional library could solve that for you too 2021-03-15 14:08:30 multiply it by 10 for the debugging though 2021-03-15 14:09:59 you're doing that, third-party dep or not 2021-03-15 14:10:02 hum.. i thikn py3-py is broken 2021-03-15 14:10:15 py3-py sounds very meta 2021-03-15 14:10:29 i think the setuptools_scm patch broke things 2021-03-15 14:11:08 yo dawg i heard you like python, so i put some py in your python 2021-03-15 14:11:16 :D 2021-03-15 14:11:40 +options="!check" # Broken 2021-03-15 14:11:49 introduced with a4402ec5c952bf43290bb8c65f3ede2702d0d408 2021-03-15 14:11:50 Seems like a collection of libraries 2021-03-15 14:12:28 i'm going to make a collection of libraries and call it rust.rs 2021-03-15 14:13:06 `apt search oauth dev` gives 21 results for me, one for go, one for ruby, quite some for haskell, one for python and some for C or C++ 2021-03-15 14:13:10 oh, that commit did not bump the pkgfel 2021-03-15 14:13:27 s/pkgfel/pkgrel/ 2021-03-15 14:13:27 ncopa meant to say: oh, that commit did not bump the pkgrel 2021-03-15 14:14:03 yup 2021-03-15 14:14:23 afontain_: yeah but rust and npm take it to a new level 2021-03-15 14:14:30 afontain_: i look forward to left-pad.rs 2021-03-15 14:14:47 how to reproduce: 1) rebuild py3-py (so the setuptools_scm change gets in effect), 2) rebuild py3-flask and watch the test suite fail 2021-03-15 14:18:58 [07:56:26] emulator development is a hell of a rabbit hole... :p 2021-03-15 14:19:04 not really 2021-03-15 14:19:37 its actually pretty straight forward, all you do is model side effects 2021-03-15 14:22:19 I'm just saying that the more useful dependencies made their way into the C world 2021-03-15 14:22:53 (now, you have several ways to include those deps and half of them are wrong) 2021-03-15 14:27:25 ok, i have no clue why py3-py fails 2021-03-15 14:27:45 it has a module for interacting with SVN servers 2021-03-15 14:27:48 how USEFUL 2021-03-15 14:28:47 it seems that py3-py package gets broken if setuptools_scm was not available during build 2021-03-15 14:29:33 ERROR tests/test_blueprints.py::test_templates_and_static - pkg_resources.DistributionNotFound: The 'py>=1.8.2' distribution was not found and is required by pytest 2021-03-15 14:29:40 python does not find it 2021-03-15 14:30:10 whoever, diffing the contents when build with or without setuptools_scm does not show anything changed really 2021-03-15 14:32:19 Hm, setting PYTHONPATH doesn't fix it? 2021-03-15 14:34:47 nope 2021-03-15 14:34:56 well, i havent tested setting it 2021-03-15 14:35:08 files are installed in exactly same place anyways 2021-03-15 14:36:23 Did you look in the distfiles directory or however it was called? 2021-03-15 14:37:10 Ff 2021-03-15 14:37:23 *-egg-info 2021-03-15 14:39:57 no. didnt find anything in /var/cache/distfiles 2021-03-15 14:40:08 <[[sroracle]]> if you remove setuptools_scm you have to manually set the version somewhere 2021-03-15 14:40:20 <[[sroracle]]> that's why the other test is failing - the version is probably not 1.8.2 anymore 2021-03-15 14:40:26 that is what the patch does http://dup.pw/alpine/aports/a4402ec5c952 2021-03-15 14:40:40 and its the py3-flake tests that fails 2021-03-15 14:40:45 <[[sroracle]]> well it must not be complete 2021-03-15 14:40:59 <[[sroracle]]> or correct 2021-03-15 14:41:24 so, i have built py3-py without the patch and with py3-setuptools_scm in makedepends 2021-03-15 14:41:32 copied the files to /tmp/a 2021-03-15 14:41:51 rebuilt with the patch, and making sure the py/_version.py gets "right" 2021-03-15 14:41:58 copied files to /tmp/b 2021-03-15 14:42:07 run a diff -ru /tmp/a /tmp/b 2021-03-15 14:42:12 shows no change 2021-03-15 14:42:17 but 2021-03-15 14:42:50 py3-flask will either succeed of fail depending on the two different builds of py3-py 2021-03-15 14:43:22 i have also tested delete the *.pyc files 2021-03-15 14:47:33 i mean py3-flask 2021-03-15 14:51:58 ok, this makes no sense whatsoever 2021-03-15 14:54:15 i wonder if py3-setuptools_scm may install/modify state somehere else? 2021-03-15 14:55:25 im completely stuck. no idea how to solve it 2021-03-15 15:15:18 E pkg_resources.ContextualVersionConflict: (py 0.0.0 (/usr/lib/python3.8/site-packages), Requirement.parse('py>=1.8.2'), {'pytest'}) 2021-03-15 15:15:24 what does that mean? 2021-03-15 15:15:33 does it think that it has py version 0.0.0? 2021-03-15 15:16:10 ncopa: it does, yes. The site-packages is saying it's mangled there, I think. 2021-03-15 15:16:40 Not sure why it's going to py for pytest, but there's a 0.0.0 entry probably. 2021-03-15 15:17:47 Hmm. I wonder if the apk build process isn't causing the site-packages to look in the wrong place. 2021-03-15 15:19:10 indeed. there are both a /usr/lib/python3.8/site-packages/py and a /usr/lib/python3.8/site-packages/py-0.0.0-py3.8.egg-info 2021-03-15 15:19:23 Oh yeah, that's mangled. 2021-03-15 15:19:56 That's what I meant with *-egg-info 2021-03-15 15:21:07 ok 2021-03-15 15:21:20 that explains 2021-03-15 15:21:30 ikke: sorry i looked in wrong dir for -egg info 2021-03-15 15:21:49 ncopa: yeah, everything like that is going to live in a site-packages definition 2021-03-15 15:23:07 the patch introduced with a4402ec5c952bf43290bb8c65f3ede2702d0d408 will install python module with version 0.0.0 2021-03-15 15:23:24 i guess we need to set the version in setup.py or similar? 2021-03-15 15:24:25 Installing with a 0 version is always going to cause problems. 2021-03-15 15:24:45 So yes, would need to install the correct python module with the correct version. 2021-03-15 16:43:28 I guess packages with makedepends ruby-dev would need to be rebuilt? !19106 2021-03-15 16:46:08 ahttps://tpaste.us/9jZP 2021-03-15 16:49:04 yeah, thanks, but I can grep too ;) 2021-03-15 16:49:15 but I guess that should be part of this MR too, no? 2021-03-15 16:49:40 omni: I used ap (lua aports) for this 2021-03-15 16:50:00 a bit more reliable then plain grep 2021-03-15 16:50:18 ok, thanks, I should install 2021-03-15 16:50:19 omni: but yes, they should be bumped 2021-03-15 16:50:54 I've done some elaborate greps where lua aports would probably do even better 2021-03-15 16:54:15 oh, lua-aports pulled in lua5.2 2021-03-15 16:58:01 how to 'clean' my fork on gitlab.a.o i.o.w. remove all cruft 2021-03-15 17:00:32 what a strange things I see there? https://gitlab.alpinelinux.org/mps/aports/-/branches/stale 2021-03-15 17:01:16 main/tiff: fix CVE-2012-5581 · 8 years ago, how this 'fall' in my fork 2021-03-15 17:02:31 that's how forking works? 2021-03-15 17:11:10 mps: when you fork a project, you inherrit all the branches 2021-03-15 19:05:17 nmeum: go ahead and merge if you want !19338 2021-03-15 19:06:06 ok :) 2021-03-15 19:11:56 done 2021-03-15 19:12:22 I see :) 2021-03-15 19:12:30 thanks 2021-03-15 19:13:24 I'm 'fighting' with kernels on arm SOCs 2021-03-15 19:13:45 hmm, fainting ;) 2021-03-15 19:39:38 ACTION editing ruby-concurrent-ruby/APKBUILD 2021-03-15 19:39:47 is there a ruby-redundant-ruby? 2021-03-15 19:40:10 ruby-ruby-ruby-ruby-ruby 2021-03-15 19:51:19 ruby³-ruby 2021-03-15 20:14:16 ruby^ruby 2021-03-15 20:24:39 ruby**ruby 2021-03-15 20:32:11 I wonder if I can try to package rvm 2021-03-15 20:33:18 Would rvm be acceptable on Alpine? 2021-03-15 20:33:46 Sure 2021-03-15 20:34:01 I mean, it allows people to install different ruby versions (and gems) in parallel, but I don't think that's very cool 2021-03-15 20:34:24 python has venv in all sorts, nodejs has npm 2021-03-15 20:34:35 go and rust have their own package managers 2021-03-15 20:39:45 acceptable yes but ruby packages provided by Alpine need to use the system ruby 2021-03-15 20:41:07 Yes, indeed 2021-03-15 20:43:45 Yeah, sure 2021-03-15 20:43:45 Nice, will give it a try during the week 2021-03-15 20:43:52 Shouldn't be hard. Famous last words, of course 2021-03-15 20:49:17 Been using Alpine on my notebook and it's been really good :) 2021-03-15 23:47:59 markand: !18377 2021-03-15 23:48:13 oh not this one 2021-03-15 23:48:34 !12525 2021-03-15 23:48:45 GOD... 2021-03-15 23:48:50 #12525 2021-03-15 23:48:57 yes, this one 2021-03-15 23:52:30 (= 2021-03-16 00:41:41 hmm.. I'm not sure packaged gems should be installed where they are now... 2021-03-16 07:37:55 nice thing https://github.com/rofl0r/svn-lite 2021-03-16 07:38:20 sh4rm4^bnc: are you rofl0r? 2021-03-16 07:43:21 yes 2021-03-16 07:44:07 of course, nobody should really ever use this 2021-03-16 07:44:11 or SVN at all 2021-03-16 07:47:17 yes, but there are still some repos which we have to checkout 2021-03-16 07:49:08 and I'm not one who will tell people which VCS they should use 2021-03-16 07:49:52 I still have some old and small 'things' in rcs 2021-03-16 07:57:01 I still use svn for most things. Never saw a need to migrate off it for our use cases. 2021-03-16 08:12:49 what i want in a programming language is simple 2021-03-16 08:12:52 i want the power of rust 2021-03-16 08:12:58 and the simplicity of visual basic 2021-03-16 08:13:03 somebody make this 2021-03-16 08:13:06 it will be great 2021-03-16 08:13:11 thanks 2021-03-16 08:17:57 C :p 2021-03-16 08:19:30 joke aside, I'm trying to put crystal at this 'basket' 2021-03-16 08:20:10 ruby syntax with compiled lang 2021-03-16 08:28:10 crystal looks nice yes 2021-03-16 08:33:28 one thing which look not much important but I like it is that crystal authors do not impose style rules on programmers, tabs vs space - you choose one or combined, ';' or not -you chose or combined, object or imperative - you chose or combined 2021-03-16 08:34:21 look as long as it doesn't have new or free 2021-03-16 08:34:24 that's all that matters really 2021-03-16 08:34:33 err, malloc or free 2021-03-16 08:35:14 yes 2021-03-16 08:35:26 garbage collect 2021-03-16 08:36:00 though I think it can be built without gc, but didn't tried 2021-03-16 08:36:31 it seems sensible, and not too many sharp edges like you said 2021-03-16 08:37:08 (although the name invokes PTSD to Crystal Reports) 2021-03-16 08:38:07 yes, not easy to search on search engines, a lot of 'junk' as results 2021-03-16 08:55:15 i think i learned how to use crystal reports in university 2021-03-16 08:55:33 but i've never used the software and i've done a lot of drugs since then, so the knowledge is gone now 2021-03-16 08:55:35 :P 2021-03-16 08:56:38 crystal meth 2021-03-16 09:11:46 never done that one (: 2021-03-16 09:14:07 morning 2021-03-16 09:14:27 Morning 2021-03-16 09:19:44 im rebasing my python 3.9 branch again 2021-03-16 09:20:02 i hope i get python 3.9 pushed this week 2021-03-16 09:20:28 are there any other major things we should have in before we do 3.14 release freeze? 2021-03-16 09:21:04 oh, we have an autoconf update that got reverted for 3.13 2021-03-16 09:40:07 Yup, not sure anymore what that broke though 2021-03-16 09:40:15 why would you freeze it so early 2021-03-16 10:00:24 when would 3.14 freeze be? (and shouldn't it've been released last sunday?) 2021-03-16 10:02:33 think we should do the freeze in the beginning of april 2021-03-16 10:02:39 so a couple of weeks 2021-03-16 10:03:03 omni: 3.13 has only been out for 2 months, so 4 momths to to :D 2021-03-16 10:03:13 s/momths to to/months to go/ 2021-03-16 10:03:13 Cogitri meant to say: omni: 3.13 has only been out for 2 months, so 4 months to go :D 2021-03-16 10:03:24 3.13 was delayed, but 3.14 will come out on schedule as it is far more conservative 2021-03-16 10:03:39 would be good to have rust in place 2021-03-16 10:03:43 i still maintain that after 3.14, we should chop the `3.` part 2021-03-16 10:03:46 it won't happen 2021-03-16 10:04:00 the scope has gotten too large 2021-03-16 10:04:21 what happened? 2021-03-16 10:04:21 hehe, freeze it on 2021-04-01 2021-03-16 10:04:33 they basically wish to completely redo the musl port 2021-03-16 10:04:59 so we are having meetings to schedule other meetings to schedule even more meetings to educate them about what musl distros actually want 2021-03-16 10:05:24 a working toolchain that can build binaries? 2021-03-16 10:05:27 :) 2021-03-16 10:05:42 yes, one without patching 2021-03-16 10:05:44 :P 2021-03-16 10:05:53 im no fan of the -dynmusl triplet thingy 2021-03-16 10:06:00 yeah nobody is 2021-03-16 10:06:03 -dynmusl is dead 2021-03-16 10:06:07 are the meetings just about scheduling scheduling meetings or also about naming and colors of the meetings? 2021-03-16 10:06:07 they want to just do it right 2021-03-16 10:06:12 but that takes more time 2021-03-16 10:06:24 i guess its a good thing 2021-03-16 10:06:32 i think as soon as they burn through the remainder of their mozilla $$$ 2021-03-16 10:06:39 they will adopt a more efficient process 2021-03-16 10:06:52 if we did alpine like rust people do rust, we would not ship anything 2021-03-16 10:07:03 it would take like 5 years to do a release 2021-03-16 10:07:14 like slackware 2021-03-16 10:07:28 slackware except run by business process consultants 2021-03-16 10:07:30 oh well 2021-03-16 10:07:42 rust won't be sorted until post-3.14 2021-03-16 10:07:46 ok 2021-03-16 10:07:50 which will hopefully just be Alpine 15 :P 2021-03-16 10:08:00 yeah, I didn't mean to bash slackware, it's just curious why they release rarely 2021-03-16 10:10:41 do you have any links about the rust pogress? upstream issue or similar 2021-03-16 10:10:55 yes, the latest is 2021-03-16 10:11:18 https://github.com/rust-lang/compiler-team/issues/416 2021-03-16 10:11:49 *that* meeting will happen on march 26 2021-03-16 10:12:03 and no action will happen before then 2021-03-16 10:12:24 so we are out of the release windows for rust to get it done before freeze 2021-03-16 10:13:42 regarding versioning, i would say that apk3 would have justified a 4.x bump, but the current plan is to deliver apk3 features incrementally 2021-03-16 10:15:05 "breaking the current behavior" i kinda had the impression they didn't care that much if things breaks 2021-03-16 10:15:17 i don't see us doing another stop-the-world change 2021-03-16 10:15:28 yeah, most do not, but some might 2021-03-16 10:21:51 community/py3-google-api-python-client has checksum errors on a patch 2021-03-16 10:24:19 anyway, we will get rust where it needs to be 2021-03-16 10:24:35 unfortunately there is a lot of politics and bureaucracy first 2021-03-16 10:27:42 I have a couple of things I'd like to have in 3.14, like !17649 (and !17647, that might be of use to someone) 2021-03-16 10:28:25 the first one I use myself 2021-03-16 10:29:25 i don't know if i will personally use rust in any alpine code, though 2021-03-16 10:29:37 but it has certainly challenged my brain a bit 2021-03-16 10:32:01 the main blocker for me for 3.14 is getting ifupdown-ng 0.11 out, so we can ship with the wifi integration 2021-03-16 10:32:22 for post-3.14 we will deprecate the legacy `bridge` and so on packages in favor of the ifupdown-ng ones i guess 2021-03-16 10:36:56 any pipewire guy here? 2021-03-16 10:37:34 I'm trying to use pipewire-jack on any version later than 0.3.21-r1 every jack command just freezes on pipewire 2021-03-16 10:37:47 on arch linux it works btw, so it's something with alpine 2021-03-16 10:37:49 can we keep legacy bridge in parallel with ng-bridge 2021-03-16 10:38:28 ah, this reminds me, post 3.14 remove pulse and pipewire 2021-03-16 10:38:35 :D 2021-03-16 10:39:07 mps: it is likely they can be made compatible yes 2021-03-16 10:39:23 Ariadne: thanks 2021-03-16 10:39:52 !18893 has secfixes for both vault and nomad 2021-03-16 10:40:39 I understand that you want and need better bridge (and I appreciate your work that) but for simple thingies old bridge is 'good enough' 2021-03-16 10:40:57 work on that* 2021-03-16 10:41:42 the new bridge is mostly the same as the old one :P 2021-03-16 10:41:56 well the really interesting stuff comes later when the netlink helpers are written 2021-03-16 10:42:23 ahm, maybe I should find time and look at it more deeply 2021-03-16 10:42:31 then ifupdown-ng will be more compact 2021-03-16 10:43:01 my goal is that ifupdown-ng ops will use netlink directly whenever possible 2021-03-16 10:43:06 but you have to start somewhere 2021-03-16 10:43:17 most of my time this dev cycle got wasted on rust 2021-03-16 10:43:19 but time. 'I'm comming as time, destroyer of humans' - Krishna 2021-03-16 10:43:40 well wasted is wrong word, but spent on rust 2021-03-16 10:44:47 and much of my time is likely to be spent on trust chain enhancements for apk(3), secfixes integration into apk(3), and a web frontend for secfixes 2021-03-16 10:44:49 for 3.14 I would like if we can add some more new arm64 SBCs 2021-03-16 10:44:54 for next dev cycle 2021-03-16 10:45:19 i just need to finish the grant writing for it 2021-03-16 10:45:33 imo, secfixes database is not much useful thing 2021-03-16 10:45:42 i agree at present 2021-03-16 10:45:48 but security people like it 2021-03-16 10:45:55 I mean in general 2021-03-16 10:45:58 i want to build something cooler ;) 2021-03-16 10:46:21 I want something stable and correct 2021-03-16 10:46:38 regarding releases, I mean 2021-03-16 10:51:10 well we need be more """competitive""" vs other distros to shut up """hacker news""" 2021-03-16 10:52:01 CVE system is quite flawed, but allowing people to ascertain the state of their patch compliance will be helpful 2021-03-16 10:53:19 i understand this stance, but 'people' above are mostly 'managers' I tend to think 2021-03-16 10:54:02 yeah well 2021-03-16 10:54:20 the sooner they are happy, the sooner we are over that hurdle 2021-03-16 10:54:33 and thats really the thing 2021-03-16 10:54:50 squeaky wheel gets the grease 2021-03-16 10:54:59 then as a result you see alpine in even more cool places 2021-03-16 10:55:02 heh yes 2021-03-16 10:55:04 which brings more people in 2021-03-16 10:56:21 on the technical fundamentals we are very competitive to the other major distros 2021-03-16 10:56:46 but this squeaky wheel hurts us a lot in terms of IT managers getting cold feet 2021-03-16 10:57:57 debian went through this particular growing pain too as i am sure you remember 2021-03-16 10:59:21 I'm at first user of alpine and as such I want stability and correctness first, that I'm a developer is side effect of that only 2021-03-16 10:59:48 yes and i think we do a reasonable job at delivering that 2021-03-16 11:00:10 agree, reasonable is good word 2021-03-16 11:00:32 i don't think it is possible to be perfect in that regard 2021-03-16 11:01:00 sure, perfect anything doesn't exists 2021-03-16 11:01:02 but i have used alpine in production since 2009 and have been quite happy with it 2021-03-16 11:01:21 That is a balance between 'ooh shiny new' and 'stability over everything' 2021-03-16 11:01:40 and i think we should do a better job at telling that story too 2021-03-16 11:04:04 but improving the secfixes experience will help a lot 2021-03-16 11:07:08 Necessary evil. I used to use RH/centos a lot. I am very tired of explaining the process of backporting security fixes to consultants whose skiddie-scanner detected 'running foo version 1.2.3, vulnerable to CVE-XXX' 2021-03-16 11:08:17 detha: block scanners :) 2021-03-16 11:09:29 there’s also a lot of hardening i want to do in apk(3) itself 2021-03-16 11:09:31 I wish. The garbage those things leave in web server logs is annoying 2021-03-16 11:09:53 for example network i/o shouldn’t be done as root 2021-03-16 11:10:19 detha: ask them for a proof of concept 2021-03-16 11:10:28 "This isn't exploitable. Prove me wrong." 2021-03-16 11:10:59 most companies side with the PCI compliance consultant every time 2021-03-16 11:11:03 it’s not worth it 2021-03-16 11:11:15 heh, yes 2021-03-16 11:11:35 I have to fake PCI tests every 3 months :) 2021-03-16 11:11:46 i have Opinions on PCI-DSS 2021-03-16 11:11:59 jvoisin: heh. They go 'pentesting not included in this service, please pay $$$' 2021-03-16 11:13:45 PCI-DSS was a good idea, but was murdered by committees and 'interests' 2021-03-16 11:15:05 gonna take a nap 2021-03-16 11:15:09 bye 2021-03-16 12:58:43 !18405 2021-03-16 15:09:55 any chance this will ever get fixed? https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/issues/41 2021-03-16 15:29:40 https://www.phoronix.com/scan.php?page=news_item&px=OpenJDK-16-Released 2021-03-16 15:29:43 "OpenJDK 16 also provides concurrent thread-stack processing for its ZGC garbage collector, an official port to Alpine Linux with Musl libc" 2021-03-16 15:30:43 more details here: https://openjdk.java.net/jeps/386 2021-03-16 16:18:01 MartijnBraam: it requires someone with knowledge of aports-turbo / lua-turbo 2021-03-16 16:18:10 MartijnBraam: clandmeter is kind of busy lately 2021-03-16 16:28:13 Has rewriting it to something not Lua been considered? 2021-03-16 16:30:05 That'd require rewriting more things that lua-aports depends on though 2021-03-16 16:30:19 But now I wanna RIIR :p 2021-03-16 16:36:17 RIIR? 2021-03-16 16:36:49 rewrite it in rust 2021-03-16 16:38:14 Ah 2021-03-16 16:40:03 huh, today is not April 1 2021-03-16 16:49:11 Imho Lua or Rust are good choice for it because those have existing bindings for apk 2021-03-16 16:50:23 It's a webapp 2021-03-16 16:50:34 which does not directly interact with apk 2021-03-16 16:51:07 The only interaction is through apkindex / aport files, which is a separate job 2021-03-16 16:53:25 can someone merge !19251 for me? Its been sitting for 3 days... 2021-03-16 17:08:53 ikke: Ah, I had assumed it re-used apk's code for parsing APKINDEX 2021-03-16 17:10:37 https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/tools/import.lua 2021-03-16 17:12:23 Ah :) 2021-03-16 17:12:45 Anyway, for a rewrite to make sense we'd also have a reason other than rewriting just to have it in a different lang 2021-03-16 17:13:02 yes 2021-03-16 17:14:14 And I don't really have complaints about aports-turbo other than it not working on newer Alpines (that shouldn't be too hard to fix though, I suppose?) 2021-03-16 17:14:23 Oh and maybe that file search is a bit hidden 2021-03-16 17:16:57 an API would be nice as well 2021-03-16 17:17:47 heh, I wrote APKINDEX parser in perl in hour or two 2021-03-16 17:17:58 in 2 hours? 2021-03-16 17:18:07 :P 2021-03-16 17:18:15 less, but forgot exactly 2021-03-16 17:18:22 The format is really trivial 2021-03-16 17:18:42 because I played with ncurses displaying data at same time 2021-03-16 17:18:49 Right, an API would be really nice indeed 2021-03-16 17:19:06 Well if we do want to rewrite it you know how to hit me up 2021-03-16 17:19:32 But I don't think you would use rust for the webinterface? 2021-03-16 17:20:47 It's entirely possible to use Rust for that, but I suppose we could just use TS 2021-03-16 17:21:05 ugh, no node pls 2021-03-16 17:22:08 Not complaining about no node :p 2021-03-16 17:22:35 Rust could be used like we currently use Lua for the web backend 2021-03-16 19:31:32 <[[sroracle]]> i did write an apk repository browser for adelie in python 2021-03-16 19:32:05 <[[sroracle]]> it's a simple cgi app but i integrated a lot of the earlier analysis work i did with whatsitcalled 2021-03-16 19:32:31 <[[sroracle]]> arch-tester 2021-03-16 19:32:54 <[[sroracle]]> demo https://dev.sick.bike/apkweb/current 2021-03-16 19:33:05 Ah, neat 2021-03-16 19:52:20 Oh that is neat, thanks for sharing [[sroracle]] 2021-03-16 19:53:17 <[[sroracle]]> np 2021-03-16 19:53:19 <[[sroracle]]> source is at https://code.foxkit.us/sroracle/apkvitrine 2021-03-16 19:53:56 Aw no file search 😢 Definitely looks good though! Even dependency specific packages 2021-03-16 19:54:22 <[[sroracle]]> yeah that could be implemented if people are interested. i certainly didn't have the disk space to do it though :p 2021-03-16 19:54:29 <[[sroracle]]> at least at the time anyway 2021-03-16 20:03:20 [[sroracle]], what does the yellow ~ mean ? 2021-03-16 20:03:36 <[[sroracle]]> means the version on that architecture is older than other architectures 2021-03-16 20:15:56 would be nice to switch to apkfoundry too :P 2021-03-16 20:21:54 <[[sroracle]]> that one needs some quality time to finish its last big feature 2021-03-16 20:22:09 <[[sroracle]]> good thing i am a public school teacher :p 2021-03-16 20:26:14 oh no don't die of COVID 2021-03-16 20:27:09 <[[sroracle]]> i finally have a vax appointment for this thursday, after the feds forced the state government to prioritize educators. fun stuff 2021-03-16 21:07:07 MartijnBraam: this is somewhat what we currently have running: https://gitlab.alpinelinux.org/alpine/infra/docker/aports-turbo 2021-03-16 21:07:31 dockerrrr 2021-03-16 21:07:38 ACTION shakes fist 2021-03-16 21:09:05 [[sroracle]]: the current version of pkgs uses a remove mirror, so storage is limited to db. 2021-03-16 21:09:11 *remote 2021-03-16 21:10:51 MartijnBraam: there is something wrong with lua-turbos ssl implementation. not sure if thats related to your issue. 2021-03-16 21:11:52 not sure either. I get the same error as that issue but no clue what it actually means 2021-03-16 21:11:54 since I don't lua 2021-03-16 21:14:04 lua question? 2021-03-16 21:15:32 MartijnBraam: did you first build the db before starting the app? 2021-03-16 21:15:46 yeah it was running fine, but now it died 2021-03-16 21:16:00 https://pkgs.postmarketos.org/ 2021-03-16 21:17:08 so you upgraded and now it stopped working? 2021-03-16 21:22:13 it would be nice if it could be rewritten with some other framework as lua-turbo is not really maintained much anymore. 2021-03-16 21:22:25 or if somebody wants, rewrite it in some other lang. 2021-03-16 21:25:39 Yeah, I don't think too many folks know Lua these days so it's though finding new contributors 2021-03-16 21:53:03 lua is not hard to learn 2021-03-16 21:54:36 and i had impression that people who knows lua are not rare 2021-03-16 21:55:02 i think using apkvitrine would be fine 2021-03-16 21:55:26 it is something that collaborative maintenance could be facilitated for 2021-03-16 21:55:45 mps: Even if Lua isn't hard to learn, having to learn a new lang to conteibute to a project makes the commitment way bigger 2021-03-16 21:55:57 not sure if it will not diverge in some future 2021-03-16 21:56:19 Ariadne: ^ 2021-03-16 21:56:37 why would it diverge? 2021-03-16 21:56:44 it views apk repositories 2021-03-16 21:56:48 what is there to diverge 2021-03-16 21:56:56 different distro 2021-03-16 21:57:08 what does that have to do with anything? 2021-03-16 21:57:46 maybe some day alpine or adelie will add something incompatible 2021-03-16 21:58:08 incompatible in what way? we are trying to keep the apk infrastructure generic 2021-03-16 21:58:20 the new apk3 format makes it *more* generic 2021-03-16 21:58:33 I hope so, but who knows what can happen in future 2021-03-16 21:58:35 Even if we were to diverge at some point we could still fork at that point 2021-03-16 21:59:08 different distros use RPM but they still collaborate on maintenance of tools related to RPM 2021-03-16 21:59:55 true 2021-03-16 22:00:20 and I'm not against apkvitrine 2021-03-16 22:00:45 but just 'contempating' aloud 2021-03-16 22:00:59 'contemplating'* 2021-03-16 22:01:05 i think it is good praxis to use tools maintained by people who want to actively maintain them, especially when the current software is maintained by somebody who has a lot of other more important tasks to look after 2021-03-16 22:01:43 I don't have final 'think' of anything 2021-03-16 22:01:54 by using apkvitrine and deprecating aports-turbo, it gives clandmeter more time to focus on more urgent issues :) 2021-03-16 22:02:10 sure 2021-03-16 23:48:35 I'm trying to build v3.12.4 with gcc from master and perl's build fails because make minitest crashes during build. It fails in /lib/ld-musl-x86_64.so.1 + 0x1caeb 2021-03-16 23:55:50 Well, important bit: I'm cross compiling for aarch64 2021-03-17 00:16:14 WELL #0 0x00007f6a75497aeb in __stack_chk_fail () from /lib/ld-musl-x86_64.so.1 2021-03-17 00:21:03 so something had a stack based buffer overflow 2021-03-17 00:22:46 Although I set stack size to 30000 2021-03-17 00:22:51 From 8192, the default 2021-03-17 00:23:04 and applying the patch for larger stack size for perl 2021-03-17 00:23:05 not stack overflow 2021-03-17 00:23:06 Hmmmmmh. 2021-03-17 00:23:09 stack based buffer overflow 2021-03-17 00:23:11 Yes. 2021-03-17 00:23:16 this is not a matter of stack size being too small 2021-03-17 00:23:18 But it shouldn't happen. 2021-03-17 00:23:24 That's miniperl from upstream 2021-03-17 00:23:29 it's a buffer overflow bug in miniperl :) 2021-03-17 00:23:31 Built from the sources 2021-03-17 00:23:41 The sources that are hashed 2021-03-17 00:23:43 what's the rest of the backtrace? 2021-03-17 00:24:04 https://bpa.st/EJ7Q 2021-03-17 00:30:32 Thermi: stack overflow is straight up segfault 2021-03-17 00:34:36 i dont see anything that could buffer overflow in there.. 2021-03-17 00:34:46 looking at https://github.com/Perl/perl5/blob/06ea6db364113525b11334d875834cb5ded50dba/pp_ctl.c#L3635 2021-03-17 00:36:04 maybe it's in some macro 2021-03-17 00:36:12 i wish we had line numbers (-g) 2021-03-17 00:40:04 It's too late for me right now to debug that. I might try that tomorrow evening. 2021-03-17 00:43:55 ok 2021-03-17 03:32:58 where can I find build info for repositories? I mean I'd like to see build logs, queues etc 2021-03-17 03:44:12 <[[sroracle]]> queue https://build.alpinelinux.org/ 2021-03-17 03:44:24 <[[sroracle]]> logs https://build.alpinelinux.org/buildlogs/ 2021-03-17 03:44:47 <[[sroracle]]> (logs are also linked from pkgs.alpinelinux.org) 2021-03-17 03:47:12 thanks! :D 2021-03-17 06:24:15 morning 2021-03-17 06:24:25 o/ 2021-03-17 06:24:47 apkvitrine looks nice 2021-03-17 06:26:19 if I'd write web app these days, I'd use Go 2021-03-17 06:26:40 reminds me, we should probably do go libs for parsing APKINDEX and stuff 2021-03-17 06:34:04 looks like community/flawfinder upstream disapeared 2021-03-17 06:34:45 downloads gets redirected to landing page 2021-03-17 06:36:18 i figured it out. it does not work with the www. prefix 2021-03-17 08:28:10 looks like there is a problem with lto when building py3-cx_freeze: 2021-03-17 08:28:11 ncopa-edge-x86_64:~/aports/community/py3-cx_freeze (python-3.9)$ abuild -r 2>&1 | tpaste 2021-03-17 08:28:11 https://tpaste.us/vZdL 2021-03-17 08:36:34 gcc build/temp.linux-x86_64-3.9/source/bases/Console.o -L/usr/lib/python3.9/config-3.9-x86_64-linux-musl -L/usr/lib -lpython3.9 -o build/lib.linux-x86_64-3.9/cx_Freeze/bases/Console -Xlinker -export-dynamic -ldl -lm -lm -flto -Wl,-export_dynamic 2021-03-17 08:36:34 lto1: internal compiler error: in lto_read_decls, at lto/lto-common.c:1956 2021-03-17 08:37:11 it does not happen on my workstation, but it does happen on the x86 and x86_64 dev boxes 2021-03-17 08:43:42 https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide 2021-03-17 08:43:51 but LTO is quite good at triggering it 2021-03-17 09:03:31 thanks. but it seems like it happens during link time 2021-03-17 09:23:54 builds with clang though 2021-03-17 09:24:35 Yup, probably some internal error in GCC that CLang doesn't have 2021-03-17 09:25:46 being LD doesn't change too much 2021-03-17 09:25:54 it's the same basic idea 2021-03-17 09:26:02 minimal reproducer is required 2021-03-17 09:26:25 i cannot generate -save-temps 2021-03-17 09:26:40 thats the difference 2021-03-17 09:30:04 try see if it is reproducible, then get an exact command which segfaults, and the binutils people will walk you through what they need 2021-03-17 09:39:01 it is reproducible, and it seems to happen when static libpython3.9.a is used 2021-03-17 09:46:31 yup, if i remove the libpython3.9.a it builds and links against the shared libpython 2021-03-17 09:54:31 please do not call it CLang 2021-03-17 09:54:40 this literally triggers me 2021-03-17 09:55:12 Ah sorry, got so used to that with GLib 2021-03-17 10:06:38 lol 2021-03-17 10:08:28 huh... upgrading python to 3.9.2 seems to solve it. probably something in the way the libpy3.9.a was generated 2021-03-17 10:10:25 so, my guess it happens when using gcc 10.2.1_pre2 to LTO link a libpython3.9.a built with gcc 10.2.1_pre1 2021-03-17 10:15:28 *clang* xkcd 303 2021-03-17 10:16:18 Me right now :D 2021-03-17 10:33:24 fcolista: im having an issue with the py3-*-gns3 packages 2021-03-17 10:33:41 py3-yarl-gns3 testsuite fails 2021-03-17 10:33:55 looks like it is exactly same version as py3-yarl 2021-03-17 10:34:02 and py3-yarl works 2021-03-17 10:35:26 so i wondered if we could delete py3-yarl-gns3 and use py3-yarl instead, but it seems like py3-aiohttp-gns3 needs multidict < 5 2021-03-17 10:36:03 so py3-multidict-gns3 uses multidict 4.x 2021-03-17 10:37:13 problem is gns3 needs those versions or something 2021-03-17 10:37:15 who knows 2021-03-17 10:37:20 yes 2021-03-17 10:37:21 maybe gns3 is crap 2021-03-17 10:37:22 :D 2021-03-17 10:37:31 thats the problem, they limit the versions 2021-03-17 10:37:46 maybe patch it to unlimit the versions 2021-03-17 10:37:47 :P 2021-03-17 10:39:48 https://src.fedoraproject.org/rpms/gns3-server/blob/rawhide/f/gns3-server.spec#_70 2021-03-17 10:41:59 but my problem is that i want get the python 3.9 rebuild done. i dont really want to spend rest of the week cleaning up python apps depends 2021-03-17 10:43:18 do we reallly need gns3-server as an apk package? cannot users install it with pip, as upstream wants them to? 2021-03-17 10:44:27 this kind of app is better shipped as docker images imho 2021-03-17 10:45:00 Sadly, yes 2021-03-17 10:48:22 so my options are: 1) relax and clean up the gns3-server dependencies 2) find and backport the fix for py3-multidict-gns3 2021-03-17 10:48:58 my guess is that since gns3 server locks the dependency versions, they also don't support python 3.9 at this point 2021-03-17 10:49:33 i would really like to nuke the gns3-server package 2021-03-17 10:49:52 another alternative is to disable tests and let things be broken 2021-03-17 10:52:55 heh... 2021-03-17 10:52:58 https://github.com/GNS3/gns3-server/commit/9665378f44f740c892d67b9d3e9667c7eb4eda2f 2021-03-17 10:54:50 isn't gns3 proprietary now 2021-03-17 10:56:16 i actually wonder if GNS3 is worth packaging 2021-03-17 10:56:25 i don't think it can run modern IOS-XE 2021-03-17 10:57:15 GNS3 has allowed network engineers to virtualize real hardware devices for over 10 years. Originally only emulating Cisco devices using software called Dynamips, GNS3 has now evolved and supports many devices from multiple network vendors including Cisco virtual switches, Cisco ASAs, Brocade vRouters, Cumulus Linux switches, Docker instances, HPE VSRs, multiple Linux appliances and many others. 2021-03-17 10:57:16 o 2021-03-17 10:57:20 its a glorified qemu frontend now 2021-03-17 10:57:22 lol 2021-03-17 10:58:07 fcolista: i think im gonna nuke gns3-server for now, and let you clean it up after python 3.9 i pushed 2021-03-17 11:04:28 this python 3.9 update is significantly more painful that it normally is 2021-03-17 11:07:22 ncopa: any objection to changing the maintainer on gcc to me, since i'm maintaining it? 2021-03-17 11:07:35 please go ahead 2021-03-17 11:07:39 thank you for taking care of it 2021-03-17 11:08:10 i'll probably formally takeover musl as well since i've done most of the work in the past few years :p 2021-03-17 11:31:10 One disadvantage of modules like go and rust use is you get to fix the same issue over and over 2021-03-17 11:31:45 Yup, and it's a real pain patching everything into shape 2021-03-17 12:17:45 built 490+ python 3.9 packages so far 2021-03-17 12:18:11 i think there are ~300-400 left in community and then i'll start with testing 2021-03-17 12:55:33 ncopa, ok 2021-03-17 12:57:55 ok read all the backlog 'bout gns3... 2021-03-17 12:58:16 yes it's a pain due to python requirement nightmare 2021-03-17 12:58:31 which fixes to specific version 2021-03-17 13:05:17 fcolista: sorry that i dont have tom to clean up the deps 2021-03-17 13:05:29 s/tom/to/ 2021-03-17 13:05:29 ncopa meant to say: fcolista: sorry that i dont have to to clean up the deps 2021-03-17 13:05:35 time* 2021-03-17 13:09:45 community/py3-fsspec checksum error: https://tpaste.us/K5Vb 2021-03-17 13:11:23 ncopa, I can go ahead and remove the py3-*-gns3 packages, fix gns3 to work with latest version by patching requirements.txt as fedora does 2021-03-17 13:12:19 dont worry 2021-03-17 13:12:27 (that's what I've been doing at the beginning, but then I realized that some newer version woudln't make gns3 work correctly) 2021-03-17 13:12:34 i do it with the python 3.9 rebuilds merge 2021-03-17 13:12:47 if this is still the case, then makes sense to remove gns3 at all 2021-03-17 13:13:00 so that ppl install it with pip3... 2021-03-17 13:13:05 the question is if we need the apk package 2021-03-17 13:13:06 yeah 2021-03-17 13:13:12 pip install or docker image 2021-03-17 13:13:24 gns3 already ships a docker image 2021-03-17 13:13:36 probably we don't really need an apk 2021-03-17 13:14:04 ok. im purging those packages with the python 3.9 upgrade then 2021-03-17 13:14:14 lgtm 2021-03-17 13:14:24 s/lgtm/sgtm 2021-03-17 13:14:24 fcolista meant to say: sgtm 2021-03-17 13:57:51 Hi Cogitri, when you bootstrap rust, did you need llvm-libunwind ? 2021-03-17 13:59:25 tmhoang: I don't think we need it because of 0006-Prefer-libgcc_eh-over-libunwind-for-musl.patch 2021-03-17 14:13:32 Cogitri : thanks. 2021-03-17 14:56:08 Hi Ariadne, I heard that you are bootstraping rust for mips, would you mind enligntening me on that ? thanks 2021-03-17 15:28:05 huh, does your `apk info -L firefox` include these files? /usr/lib/firefox/firefox /usr/lib/firefox/firefox-bin ? for me these files are identical 2021-03-17 15:28:19 at least their md5sum 2021-03-17 15:50:31 can anyone help making firefox85 more verbose? i need to debug why it silently refuses any ssl connections. when i go to any https site, nothing at all happens on the UI. if i look at it with wireshark i see a > TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Bad Certificate) packet sent from firefox 2021-03-17 15:51:32 this started to happen a few months ago, i hoped with updates it will fix itself. but yesterday my last still functioning firefox died. so i have to look into this now. 2021-03-17 16:09:58 What's your nss version? 2021-03-17 16:10:08 Dev console doesn't contain anything more useful? 2021-03-17 16:10:15 And is your system time correct? :) 2021-03-17 16:10:57 devconsole does not even show the request. :/ 2021-03-17 16:11:35 system time is correct and utc. 2021-03-17 16:11:59 nss-3.62-r0 ? 2021-03-17 16:13:05 Looks good 2021-03-17 16:13:24 just asking since having old nss versions can lead to very strange SSL behaviour in FF 2021-03-17 16:13:32 Odd, everything works for me on a fresh Alpine install 2021-03-17 16:13:59 Which alpine linux version? 2021-03-17 16:14:03 edge 2021-03-17 17:38:35 zstd is broken on armhf 2021-03-17 17:53:25 Cogitri&ikke it was an outdated nss... 2021-03-17 17:53:32 ACTION feels ashamed 2021-03-17 17:54:38 yZ5vlALg86lP: At least nice that you found it :) 2021-03-17 19:23:26 !19462 2021-03-17 19:45:33 can someone take a look? it's here for a while: !19176 2021-03-17 20:06:21 btw how do you handle name change of projects in alpine? 2021-03-17 20:06:35 with provides/replaces 2021-03-17 20:08:01 so if oh-my-zsh should be renamed to ohmyzsh I'd need to provide both set to oh-my-zsh and rename package to ohmyzsh? 2021-03-17 20:10:06 provides="$pkgname=$pkgver-r$pkgrel" 2021-03-17 20:11:15 provides="oldname=$pkgver-r$pkgrel" 2021-03-17 20:12:22 I'm struggling if I should rename it 2021-03-17 20:13:07 github repo was renamed but eg. default home directory in install guide wasnt 2021-03-17 20:32:18 ikke: i sincerely wish alpine targeted the lts stable branch of the kernel in 3.13 rather than one release in the cuurent branch 2021-03-17 20:32:46 5.10.16-0-lts is outdated and needs to either be upgraded or security fixes need to be backported 2021-03-17 20:55:31 c705: that's somethin you have to talk about with ncopa, who maintains the kernels 2021-03-17 20:56:04 well, i'm not awake at 5 in the morning, so if you could pass this on to him, that would be great 2021-03-17 22:25:43 !19476 what am I missing? 2021-03-17 23:24:40 !16046 could be closed since !18981 2021-03-17 23:25:02 (is merged) 2021-03-17 23:30:29 ccache test failing on the builders (passed CI) 2021-03-17 23:30:32 Failure reason: Expected permissions for /home/buildozer/aports/main/ccache/src/ccache-4.2/build/testdir/59972/.ccache to be drwxrwxr-x, actual drwxrwsr-x 2021-03-17 23:58:42 regarding zstd armhf failures, it is a data alignment error 2021-03-18 00:04:51 There is an MR for it by Ikke 2021-03-18 00:05:09 also !18464 xwayland is now split and has its own releases with people working on it 2021-03-18 07:22:24 Anyone got a clue why make check on zstd rebuilds everything again? 2021-03-18 08:32:08 <[[sroracle]]> If i had to guess, different makeflags 2021-03-18 08:33:48 In my MR I aply the same flags, but it still seems to rebuild 2021-03-18 08:35:06 <[[sroracle]]> link? 2021-03-18 08:43:18 !19462 2021-03-18 08:49:29 <[[sroracle]]> It seems tests/Makefile changes a bunch of cflags then calls lib/Makefile again 2021-03-18 09:00:38 !19490 2021-03-18 09:00:43 <[[sroracle]]> yup and it does some horrible hashing of the flags into the build dir 2021-03-18 09:00:49 <[[sroracle]]> yuck 2021-03-18 09:03:29 <[[sroracle]]> Could probably be more easily fixed by setting BUILD_DIR manually 2021-03-18 09:03:33 <[[sroracle]]> later o7 2021-03-18 09:05:02 maxice8: I can test later, but I guess that would supersede my MR 2021-03-18 09:05:12 I am experimenting 2021-03-18 09:05:32 Just using CI to build for more so I can keep AFK-ing runescape 2021-03-18 09:06:37 Lol nice 2021-03-18 09:22:11 morning 2021-03-18 09:22:29 fcolista: ospd-netstat. i dont know what to do with it? 2021-03-18 09:22:49 the source url is invalid and i cannot find where release tarballs are found 2021-03-18 09:23:01 there is a github project but there are no releases there 2021-03-18 09:23:07 https://github.com/greenbone/ospd-netstat 2021-03-18 09:23:18 so im not sure what to do with this 2021-03-18 09:34:55 approx 400 aports lest to reubild against python 3.9 2021-03-18 09:36:55 !19490 Ikke can you check ? the CI looks fine (passes and doesn't rebuild as far as I can tell) 2021-03-18 09:39:28 maxice8: so the problem was that the CFLAGS was different in build and check? 2021-03-18 09:39:47 yes 2021-03-18 09:39:52 the check phase was rebuilding with different flags 2021-03-18 09:40:05 maybe should set _moreflags in global scope 2021-03-18 09:40:17 and set CFLAGS in both build and make 2021-03-18 09:40:43 i dont think we can assume that vars set in build will survive to the check call 2021-03-18 09:42:39 the check phase should not be rebuilding anything they should be using what was compiled in build() 2021-03-18 09:44:02 so the CFLAGS should be the same in build and check, right? 2021-03-18 09:44:13 so thei makefile dont think it needs to be rebuilt 2021-03-18 09:47:58 ncopa: c705 wondered why the kernel on 3.13 is outdated (missing sec fixes) 2021-03-18 09:57:01 In !19462 I moved _moreflags to the global scope 2021-03-18 09:57:14 But that was apparently not enough 2021-03-18 10:14:35 [03:05:30] Just using CI to build for more so I can keep AFK-ing runescape 2021-03-18 10:14:42 maxice8 is an absolute legend 2021-03-18 10:15:05 My notebook is bad 2021-03-18 10:15:31 oh i meant that as compliment 2021-03-18 10:15:40 :) 2021-03-18 10:15:42 I know 2021-03-18 10:16:03 as in, crushing bugs *and* AFKing runescape at the same time? the absolute legend 2021-03-18 10:17:17 :) 2021-03-18 10:25:33 I afk'ed my way to 99 runecrafting while packaging KDE for Alpine originally I believe, it's certainly doable 😛 2021-03-18 10:37:04 I think we should go offtopic 2021-03-18 10:39:11 ncopa, ospd-netstat was hosted to greenbone repo, no longer in use. 2021-03-18 10:39:33 They moved on GH, but not all the project has been moved as yet. 2021-03-18 10:39:41 ospd-netstat appears to be abandoned 2021-03-18 10:39:46 so can be removed. 2021-03-18 10:43:41 I've submitted an issue to GH to tag a release FYI 2021-03-18 10:44:25 in the meanwhile, disable it. Nobody will miss it 2021-03-18 10:52:14 ok. thanks 2021-03-18 10:53:55 i'm so tired of this bait and switch crap oracle is doing with JDK and Alpine 2021-03-18 10:54:03 "JDK 16 will be certified for Alpine!" 2021-03-18 10:54:06 didn't happen 2021-03-18 10:54:13 next it will be done in JDK 17 2021-03-18 10:54:14 haha 2021-03-18 10:56:20 i saw in the release notes that openjdk 16 has official alpine support? 2021-03-18 10:58:12 yeah 2021-03-18 10:58:18 then they pulled the binaries 2021-03-18 10:58:31 its so official you cant download the binaries :D 2021-03-18 11:19:43 Marian[m]: Do you happen to have a guide for how to setup the cross compiling w/ gcc-$TRIPLET ? 2021-03-18 11:20:30 I have to target msp430, not sure how to do that though (do I just have to do CC=gcc-mps430 and everything should work?) 2021-03-18 11:26:00 maxice8: it builds on armhf, the only thing remains is whether we should move the export in the global scopre 2021-03-18 11:26:04 scope* 2021-03-18 11:27:03 which builds? 2021-03-18 11:27:08 armhf is testsuite fail 2021-03-18 11:27:10 for zstd 2021-03-18 11:27:14 yes 2021-03-18 11:27:25 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19490/diffs#1a043581e43f0c9b5ecc0df19dcd21c49517b5c5_26_25 2021-03-18 11:27:44 There was a fix for it: '-DMEM_FORCE_MEMORY_ACCESS=0' 2021-03-18 11:27:55 o 2021-03-18 11:27:56 ok 2021-03-18 11:28:00 but in the check phase, it rebuilt everything, but without those flags 2021-03-18 11:28:09 yeah 2021-03-18 11:28:11 i got you now 2021-03-18 11:28:48 the way to handle this is to share _moreflags outside build() 2021-03-18 11:29:05 i think the export is wrong 2021-03-18 11:29:31 export in build, or export in general? 2021-03-18 11:29:46 in build 2021-03-18 11:29:50 right 2021-03-18 11:30:04 just fix up the cflags in the base APKBUILD 2021-03-18 11:32:19 Cogitri: It is often a bit more involved, as e.g. the MCUs have different RAM and flash layout. Since there is no OS and no virtual address space on bare metal devices, one has to provide those details. Often a custom linker script will take care of this. 2021-03-18 11:35:21 I'm using e.g. RIOT OS, which takes care of all those details. It has the concept of boards. E.g. an arduino-uno would have a matching board entity with all setup provided. But while there are like 200 boards in RIOT, you might still be out of luck and your specific board is not yet supported. That said, adding board support is straight forward when the architecture is already supported, which for MSP430 is the case. 2021-03-18 11:35:50 Also quite popular these days is zephyr, but I don't know if they have MSP430 support 2021-03-18 11:49:55 Oh, okay. Seems like it doesn't support the msp-EXP430G2RT I happen to have around. I guess I'll get myself a STM32 for the thing so I don't have to mess with it, thanks 2021-03-18 11:57:14 Ariadne: gojq upstream fixed the issues with mips64 btw :) 2021-03-18 12:08:32 For STM32 I can recommend the official Nucleo boards. Unlike e.g. Microchip/Atmel and others the are relatively affordable and the integrated debbuger/programmer makes life so much easier. For actual deployment one can easily switch to one of the cheap boards in the "Bluepill Form Factor" without debugger/programmer. You can get those 2 EUR to 4 EUR per board, depending on the MCU. 2021-03-18 12:10:38 Ah, I only need one board that is relatively painless to work with for an university course :) 2021-03-18 12:12:08 I'll get myself a Nucleo board then, thanks :) 2021-03-18 12:17:31 Or maybe I can get my current board to work with mspdebug too, let's see :) 2021-03-18 12:19:01 For mspdebug to work with newer MSP430, you'll need this "open source" library that is not really open source. Let me check where it was. 2021-03-18 12:20:04 Ah right, I think I recall reviewing that MR 2021-03-18 12:25:40 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19501 2021-03-18 12:33:50 Thanks 👍 2021-03-18 12:34:03 I guess we'd also need a version of mspdebug built against that? 2021-03-18 12:40:40 No, just selecting "tilib" as driver will dynamically load the lib. Strange design choice from a development point of view, but actually nice for packaging it. 2021-03-18 12:51:31 Ah okie :) 2021-03-18 16:06:52 anyone faced this before ? https://tpaste.us/g61P 2021-03-18 16:07:42 Can somebody with access to main merge !16881? Already got approvals by ncopa and Ariadne 2021-03-18 17:07:07 PureTryOut[m]2: Merged by Leo 1 week ago (Mar 4, 2021 9:16pm GMT+0100) 1 week ago 2021-03-18 17:33:20 tmhoang: I guess your platform isn't found in rust's libc crate so it doesn't know the new definitions 2021-03-18 17:33:48 anyone familiar with init.d "net" dependancies? when I configure /etc/ssh/sshd_config with a ListenAddress then during boot I get a message to add a line rc_need="net.INTERFACE" to /etc/conf.d/sshd. However there's no mechanism in the standard init.d script to register "provides" entries for each distinct interfaces, /etc/init.d/networking just registers a global "provides: net" 2021-03-18 17:34:30 minimal: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#be-wary-of-need-net-dependencies 2021-03-18 17:38:59 ikke: hadn't seen that doc but read similar ones yesterday. Doesn't really address my issue - have sshd listening only on eth1 so I add rc_need="net.eth1" to /etc/conf.d/sshd . However unless I define a net.eth1 init.d service and rewrite /etc/init.d/networking to *not* setup eth1 then still have an issue 2021-03-18 17:41:11 ideally I'd want /etc/init.d/networking to indicate "provides" net.INTERFACE for each interface automatically 2021-03-18 18:20:47 Anyone using gitlab dark-mode? The top-bar becomes illegible for me (gray text on gray top-bar) 2021-03-18 18:24:10 ikke: I do, and yes not perfect but not so bad be illegible in my FF 2021-03-18 18:24:47 s/bad be/bad to be/ 2021-03-18 18:24:47 mps meant to say: ikke: I do, and yes not perfect but not so bad to be illegible in my FF 2021-03-18 18:25:50 ikke: that doc isn't completely relevant for Alpine, checking a v3.13 ISO I see that /etc/init.d/loopback is not used and /etc/init.d/networking appears to bring up lo0 as well as others so the docs' comment that "They are not satisfied by the loopback interface, so 'need net' requires some other interface to be up" is incorrect for Alpine 2021-03-18 18:27:53 mps: oh, apparently that's only on the preferences page 2021-03-18 18:28:07 https://gitlab.alpinelinux.org/-/profile/preferences 2021-03-18 18:29:16 It's transparent 2021-03-18 18:29:52 don't see difference even there 2021-03-18 18:32:03 actually, it is better in preferences than in aports page 2021-03-18 18:33:08 never liked transparency in any of these 'cool things' 2021-03-18 18:41:55 minimal: you'll want to look at /etc/init.d/net-online 2021-03-18 18:42:17 that'll point you roughly in the right direction, but it's not entirely straightforward 2021-03-18 18:52:52 RootWyrm: that appear oriented to checking if Internet connectivity is active. I'm running sshd on a management interface which is statically configured so need the /etc/init.d/sshd service to run once the relevant interface is up 2021-03-18 18:53:09 minimal: just read through it 2021-03-18 18:53:42 it shows how interfaces are interpreted in openrc 2021-03-18 18:55:12 yupe, will do. Was just pointing out that there appears to be a gap between the OpenRC init.d scripts provided by Alpine plus the OpenRC documentation and the reality of how Alpine is actually using stuff 2021-03-18 18:56:08 I'll probably have a chat with Ariadne, think there's some possible tidyup work 2021-03-19 07:38:38 seems like softhsm locked everything 2021-03-19 07:39:14 How ironic 2021-03-19 07:53:15 and it doesn't hang locally 2021-03-19 08:59:00 Hi Ariadne, I was trying to bootstrap rust on s390x on x86 host. Seeing this issue with rust libc. Any idea ? Thanks. https://tpaste.us/JYV7 2021-03-19 09:56:33 can someone kick the builders ? 2021-03-19 10:20:05 Ikke: https://gitlab.alpinelinux.org/Leo/atools/-/merge_requests/47 2021-03-19 10:25:52 maxice8: in about an hour 2021-03-19 11:38:32 maxice8: done 2021-03-19 11:48:50 tmhoang: haha 2021-03-19 11:49:15 tmhoang: if it was working, i would have already done it. there's missing stuff in 1.50 that won't land until probably 1.52 or later. 2021-03-19 11:50:05 tmhoang: if you wish to take over the bringup task though, feel free to join us in zulip :) 2021-03-19 11:50:43 Ariadne : thanks, zulip ? 2021-03-19 11:51:22 in the mean time I wonder if I could fallback to follow the path that Cogitri did last year to bootstrap 2021-03-19 11:51:59 the problem is the rust stdlib does not support s390x yet in a release 2021-03-19 11:52:05 i wrote the code to support it 2021-03-19 11:52:16 once it is there, you should beable to bootstrap it 2021-03-19 11:52:34 cool ! 2021-03-19 11:52:41 thanks for the info 2021-03-19 11:52:55 but I wonder how other distros bootstrap on s390x 2021-03-19 11:53:05 i should correct myself 2021-03-19 11:53:14 rust stdlib DOES support s390x on glibc in a release 2021-03-19 11:53:19 does not for musl 2021-03-19 11:53:23 right 2021-03-19 11:53:43 the APKBUILD works for bootstrapping if the bits in the code are there to enable it 2021-03-19 11:54:07 for example, CTARGET=aarch64 abuild -r will work 2021-03-19 11:55:10 tmhoang: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/bootstrapping.20on.20s390x.2Fmips.20for.20musl 2021-03-19 11:55:18 tmhoang: you can sign in from github 2021-03-19 11:55:29 thanks 2021-03-19 11:55:50 I have zero knowledge rust btw but curious to see/learn 2021-03-19 11:56:51 well this is learning rust the hard way 2021-03-19 11:56:52 :p 2021-03-19 11:57:20 start learning rust by cross-compiling it into a new arch with not-supported libc :P 2021-03-19 11:59:09 10/10 intro 2021-03-19 12:02:44 botan is hanging on ppc64le 2021-03-19 12:02:47 in the test suite 2021-03-19 12:03:03 hanging on "entropy:" 2021-03-19 12:14:35 https://tpaste.us/zxz5 2021-03-19 13:37:19 Does someone see why ldc doesn't depend on llvm-libunwind-dev? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ldc/APKBUILD#L11 suggests it should, but according to https://pkgs.alpinelinux.org/package/edge/community/x86_64/ldc it only depends on the non-dev version 2021-03-19 17:31:15 xwayland fails to install because it tries to overwrite /usr/bin/Xwayland (owned by xorg-server-xwayland), should the xwayland apkbuild have replaces="xorg-server-xwayland" ? 2021-03-19 17:32:47 Seems like xorg-server-xwayland was renamed to xwayland 2021-03-19 17:32:58 or replaced by 2021-03-19 17:33:40 so I'd think it needs a replaces= so it can take ownership of the files on disk that xorg-server-xwayland installed? 2021-03-19 17:33:51 1ccd8b2174950dc2981da8b2e28ae7837ed4882c 2021-03-19 17:34:03 1ccb8db3fea29605d18ac9531d363013a50fbb94 2021-03-19 17:34:51 the 1st 6 characters of those SHAs matching is... creepy 2021-03-19 17:34:55 Right, it used to be a subpackage of xorg-server, but not it's a stand-alone package 2021-03-19 17:35:06 craftyguy: heh :) 2021-03-19 17:35:46 You know what the proof-of-work challenge for bitcoin is, right? 2021-03-19 17:36:24 craftyguy: first 3 :) look closer 2021-03-19 17:36:35 doh! 2021-03-19 17:36:36 heh, inverted b 2021-03-19 17:36:43 ACTION gets more coffee 2021-03-19 17:37:31 one is d8b, the other b8d 2021-03-19 17:37:35 but indeed, even more creepy now :P 2021-03-19 17:44:00 this fixes the upgrade for me: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19562 2021-03-19 17:44:41 though xorg-server-xwayland stays installed, so I'm not sure how to specify a literal 'replace' in the apkbuild 2021-03-19 17:45:04 craftyguy: add a provides="xorg-server-xwayland=$pkgver-r$pkgrel" 2021-03-19 17:45:06 since 'replaces' doesn't replace (uninstall old, install new) the package 2021-03-19 17:45:17 craftyguy: correct, it's just about files 2021-03-19 17:45:19 ah ok, I'll do that 2021-03-19 17:46:04 thanks! 2021-03-19 17:50:11 hmm why is ppc failing CI on that.. 2021-03-19 17:51:24 "xorg-server-common (no such package):" 2021-03-19 17:51:32 ppc64le is stuck on botan 2021-03-19 17:51:35 I was looking at that 2021-03-19 17:52:06 ah ok, so I didn't break it 2021-03-19 17:56:30 I noticed that xorg-server-wayland was still present for ppc64le 2021-03-19 18:47:31 2/ 2021-03-19 18:47:38 o/ 2021-03-19 18:47:39 ugh, fail 2021-03-19 18:47:44 everytime 2021-03-19 19:35:19 I'm trying to uninstall musl-dbg, what am I doing wrong: https://bpa.st/raw/WBJA 2021-03-19 19:35:36 (the apk del doesn't actually remove it, in case that wasn't clear) 2021-03-19 19:37:18 craftyguy: what does apk version musl-dbg return? 2021-03-19 19:37:32 craftyguy: if it's not installed, apk returns the same message 2021-03-19 19:37:59 ha it's apparently not installed. oops 2021-03-19 19:39:46 omni: sccache is failing on armhf (sigbus during tests) 2021-03-19 21:30:37 Ikke: thanks for the restart, atools should now recognize ${GOFLAGS/-buildmode=pie} and not complain about it 2021-03-19 21:32:46 maxice8: Yeah, thanks, I've read it 2021-03-20 01:17:44 bootstrapping aarch64 from aports is broken again 2021-03-20 01:17:58 gcc dep gcc-pass2-aarch64-gnat-bootstrap on pass-2 2021-03-20 01:18:08 obv. circular dependency in the boot strap 2021-03-20 01:18:24 can't build *-gnat-* without the basic and then full compiler first 2021-03-20 01:45:04 Thermi: i’ll look into fixing it 2021-03-20 01:45:17 Ariadne: ty 2021-03-20 20:40:33 andypost: php7-pecl-imagick has test failures on x86 2021-03-20 21:51:37 Ariadne: Did you look into it yet? 2021-03-20 22:12:51 ikke, it was expected !19196 guess we should disable this test 2021-03-20 22:40:38 Hello alpine devs! I am trying to install alpine to my pi3 in disk-based mode and have run into a problem. I've done everything as directed in the rpi install wiki up to the setup-disk -o command. I can't install my apkovl file to an ext partition, as it errors and says "ext4 is not supported. Only supported are: vfat. 2021-03-20 22:41:00 " is there any way to get through this error and install it anyways? 2021-03-20 22:44:40 make sure the ext4 module is loaded 2021-03-20 22:44:51 Also, that's more #alpine-linux area 2021-03-20 22:45:15 known bug in setup-disk 2021-03-20 22:47:38 Ariadne: NVM 2021-03-20 22:48:55 Accidentally built from an old repo (I now deleted it). 2021-03-21 00:20:09 a'14 2021-03-21 02:46:06 Thermi: :) i was certain i fixed this already, but never know, regressions are possible 2021-03-21 02:46:23 Ariadne: Well, my version was from 2020 2021-03-21 02:46:28 It works fine now with the latest 2021-03-21 02:46:57 I didn't notice it because I was in a container with a mounted volume and edited on the host, so the paths didn't line up in the first place 2021-03-21 02:47:20 I only noticed when the changes I made weren't reflected in the file in the guest I expected them to be 2021-03-21 02:48:21 well either way, i am working on a project to run bootstrap from scratch every night and open a bug if there is a regression 2021-03-21 02:51:42 That is a great project 2021-03-21 02:51:53 For all archs? 2021-03-21 02:52:12 x86_64 -> s390x, armv7, aarch64, mips, ... ? 2021-03-21 02:52:27 yes 2021-03-21 02:52:30 Nice. 2021-03-21 02:57:23 ariadne, :) 2021-03-21 06:39:46 I am reliably sabotaging my merges to alpine/aports, I mark one to merge after CI completes then merge something in the meantime causing the former to not merge after CI completes 2021-03-21 08:53:50 If a package places a file in /etc, and a new version does not place this file there any more, does it automatically get removed? 2021-03-21 08:54:03 (when upgrading the package) 2021-03-21 10:23:07 /etc files are handled differently. I don't think they get cleaned up 2021-03-21 10:46:54 they don't 2021-03-21 10:47:34 if a new package installs files in /etc and there's already one, different from the new one, then the new one doesn't overwrite the old one 2021-03-21 10:47:47 instead it's added as /etc/$file.apk-new 2021-03-21 10:48:33 bottom line is, no matter what you do, manually maintained files in /etc are never removed or overwritten, which is the only sane policy 2021-03-21 10:50:07 that is not specific to /etc 2021-03-21 10:50:22 if you do that to any file on disk, apk will do the same 2021-03-21 10:56:46 Ariadne: Hej, would you know why even with this `depends` ldc doesn't pull in llvm-libunwind-dev but only llvm-libunwind: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/ldc/APKBUILD#L11 2021-03-21 10:56:56 Not sure why abuild strips that 2021-03-21 11:00:30 no, it seems like it should work 2021-03-21 11:06:47 Hmmm, weird 2021-03-21 11:07:29 https://pkgs.alpinelinux.org/package/edge/community/x86_64/ldc only pulls in the non -dev version :/ 2021-03-21 11:50:23 build log ? 2021-03-21 14:19:02 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19612 Ah whoops :) 2021-03-21 14:28:43 oh lol, depends whas overwritten :D 2021-03-21 14:29:13 Yeah, that took a little to spot :D 2021-03-21 18:56:19 strange, gtkd fails right after the package phase, but I cannot manually reporoduce it on the builder 2021-03-21 18:56:24 and there is no error message 2021-03-21 18:59:08 and now it succeeded 2021-03-21 18:59:17 oh well 2021-03-21 19:00:17 the builder works in mysterious ways 2021-03-21 19:01:17 ah, cogitri already fixed tilix 2021-03-21 19:02:03 Yup 2021-03-21 19:02:31 it's still failing 2021-03-21 19:02:48 meson.build:99:0: ERROR: Dependency "libunwind" not found, tried pkgconfig 2021-03-21 19:12:51 Huh 2021-03-21 19:12:52 Whoops 2021-03-21 19:18:51 Pushed a fix, thanks for the notificaito 2021-03-21 19:19:44 Or rather would push a fix if git push did something 2021-03-21 19:24:06 stdx-allocator: so:libdruntime-ldc-shared.so.90 (no such package): 2021-03-21 19:25:13 Huh, did I miss a pkgrel bump somewhere 2021-03-21 19:55:06 appstream-generator fails with sigbus on aarch64 2021-03-21 19:55:18 1/1 asgen_tests FAIL 1.74s killed by signal 7 SIGBUS 2021-03-21 19:56:39 :/ 2021-03-21 20:44:01 git push takes some 30 seconds for me right now on g.a.o but it's as fast as always with other instances 2021-03-21 20:44:45 hmm 2021-03-21 20:45:19 host is not busy 2021-03-21 22:13:12 helmen[m]: welcome 2021-03-21 22:13:28 Thanks ikke 😊 2021-03-21 22:15:46 One moment, i ask again the same question (but in the meantime im finishing to send a merged request for the APKBUILD) 2021-03-21 22:17:49 Im making a new APKBUILD of a python package, I've seen that this does not install any license document in the filesystem even if this is present in the sources (it's a custom license), so how do I integrate it from the APKBUILD? 2021-03-21 22:19:38 In the package function, you can use `install` to copy it to the correct location 2021-03-21 22:20:10 /usr/share/licenses/$pkgname/ 2021-03-21 22:22:58 Ok I'm sercing for it 2021-03-21 22:33:26 ikke: install -Dm644 COPYING "$srcdir"/license "$pkgdir"/usr/share/licenses/$pkgname/COPYING 2021-03-21 22:33:35 do you think that this is correct ? 2021-03-21 22:34:23 and whit this I can also use subpackages="$pkgname-doc" whitout any error? 2021-03-21 22:37:08 (in the meantimes, I'm trying to rebuild the package) 2021-03-21 22:44:38 no, this is wrong, I'm trying with builddir 2021-03-21 23:14:13 it is mandatory to call the license file "COPYING" ? 2021-03-21 23:14:55 no, I think no 2021-03-21 23:38:36 No 2021-03-21 23:38:56 It's only mandatory to list the right license identifier in the license field 2021-03-21 23:39:06 It has to be a spdx license identifier 2021-03-21 23:39:09 One or several 2021-03-21 23:45:29 in my case is license="custom" 2021-03-21 23:46:03 because the license is created by the developer 2021-03-21 23:47:17 OK 2021-03-22 00:00:27 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19628 :) 2021-03-22 07:19:18 good morning 2021-03-22 07:47:41 just in case nobody reads alpine-devel list yet, we are aiming to do the alpine developers conference discussed last year on may 15-16. a repository for talk submissions has been created on gitlab. 2021-03-22 08:16:31 nice! 2021-03-22 10:40:13 Are post-upgrade hooks not triggered when the upgrade happens through a replacement+ 2021-03-22 10:40:16 ?* 2021-03-22 10:47:50 Never mind, seems like I'm doing something else wrong 2021-03-22 12:53:18 Actually it seems post-upgrade hooks in fact are not triggered when a package gets replaced 2021-03-22 15:38:15 Ariadne: what's the progress on the automatic bootstrap build? Or is there a set date that you want to start that task? 2021-03-22 15:43:31 i havent started it yet 2021-03-22 15:43:59 i'm working on CVE aggregation 2021-03-22 16:08:43 Ariadne: I see. Please let me know when. I found some more issues with bootstrapping in which you basically already require pre-built packages in order to fullfill dependencies 2021-03-22 16:39:29 https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/ 2021-03-22 16:48:12 > Notify participants when merge request is marked ready 2021-03-22 16:48:13 yay 2021-03-22 19:08:43 ACTION < https://matrix.org/_matrix/media/r0/download/matrix.org/GaCfsvMkQZPIrgLtkgIGqlHf/message.txt > 2021-03-22 19:08:44 translated :) 2021-03-22 19:09:25 helmen[m]: note that these kinds of messages don't come out that well for irc users 2021-03-22 19:09:56 helmen[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/GaCfsvMkQZPIrgLtkgIGqlHf/message.txt > 2021-03-22 19:09:59 that's what we see 2021-03-22 19:10:51 helmen[m]: there is a proposal to remove these files or python3 itself 2021-03-22 19:11:29 It's a bit of a size vs performance tradeoff, though, it's not clear how much the performance improves with the pyc files 2021-03-22 19:11:41 apart from the ending line, what is the strange part in my messages? 2021-03-22 19:11:58 That we have to open a link in our browser to see what you have to say 2021-03-22 19:12:26 a link without context 2021-03-22 19:13:13 pycache is the dir name, it is not a formatting text character 2021-03-22 19:13:14 everytime? 2021-03-22 19:13:49 helmen[m]: only when you use multiline messages 2021-03-22 19:14:41 I think that there is no improvement with pyc, only at the first running 2021-03-22 19:14:47 but after python create these files another time 2021-03-22 19:15:48 helmen[m]: the problem is that these files are in read-only directories, so python cannot create *.pyc files (in a __pycache__ directory) 2021-03-22 19:16:07 (unless you run things as root) 2021-03-22 19:16:11 ok, im try to not make it 2021-03-22 19:16:22 helmen[m]: I don't say it's wrong 2021-03-22 19:16:27 just the trade-off 2021-03-22 19:17:45 uhm, today i have readed that there is a env variable to ask to python 2021-03-22 19:17:45 to build this file in a specified dir 2021-03-22 19:19:17 Starting with Python 3.8 you can use the environment variable PYTHONPYCACHEPREFIX to define a cache directory for Python. 2021-03-22 19:19:17 https://stackoverflow.com/a/57414078 2021-03-22 19:19:37 hmm, not mentioned in the man page 2021-03-22 19:20:44 maybe I do an experiment with my package to see if it works 2021-03-22 19:22:21 python 3.8, i think that it is recent change 2021-03-22 19:22:21 so nothing strange if it is not well knowed 2021-03-22 19:22:34 I have python 3.9 2021-03-22 19:22:39 I would expect the man page to mention it 2021-03-22 19:22:48 It mentions other environment variables 2021-03-22 19:23:52 https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPYCACHEPREFIX 2021-03-22 19:24:07 yes, I noticed 2021-03-22 19:24:13 Just find it odd the man page is missing it 2021-03-22 19:25:23 Really I don't know, I readed it today only by accident 2021-03-22 19:26:54 ok, give to me a couple of minutes and I try with my testing package (that is already without .pyc) 2021-03-22 20:01:39 ok ikke, sorry for theem byu i have connection problem, seems that it works: https://pastebin.com/D8LUmSs3 2021-03-22 20:02:27 i don know if it is more fast, but it is true, without the env variable no .pyc is created inside /usr.... but with the enviorment variable the local dir is populated 2021-03-22 20:05:09 all pyc are rebuild, not just the missing one 2021-03-22 20:35:05 oops, openssl CVE being released on the 25th 2021-03-22 20:38:18 https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html 2021-03-22 20:38:57 HIGH severity, not critical\ 2021-03-22 21:16:04 The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. 2021-03-22 21:41:18 eons even 2021-03-23 06:48:45 https://crystal-lang.org/2021/03/22/crystal-1.0-what-to-expect.html Crystal lang 1.0 is released, finally 2021-03-23 08:19:45 btw, alpine linux favicon 'looks' in firefox tabs similar to crystal-lang one 2021-03-23 08:20:18 cool 2021-03-23 08:20:20 lets sue them 2021-03-23 08:20:33 (i'm kidding) 2021-03-23 08:20:36 :) 2021-03-23 08:21:21 That's very American of you 2021-03-23 08:23:43 hmm, human stupidity is nearly equally dispersed around planet^Wcosmos, not specific to one continent or country/nation 2021-03-23 08:24:51 PureTryOut[m]2: yet Europe has the software patents now 2021-03-23 08:25:07 i think lawyers are pretty much everywhere 2021-03-23 08:25:10 doing lawyer things 2021-03-23 08:26:16 yes :c 2021-03-23 10:38:20 secfixes !19671 2021-03-23 11:51:14 for some reason, the CI jobs for elixer are hanging hours on 'Signing the index'... 2021-03-23 11:56:05 epmd is hanging 2021-03-23 12:48:20 mps: oh, awesome, yet another language nobody was asking for 2021-03-23 12:51:33 skarnet: heh, I see crystal as scripting lang which is compiled 2021-03-23 12:52:44 big fkn deal 2021-03-23 12:56:17 eh, I don't like to write big financial apps in C (or any system lang) 2021-03-23 13:01:48 thank God for Crystal then, it is *definitely* the perfect solution for when you write a big financial app, all your problems are solved 2021-03-23 13:03:49 heh, sometimes I like your strange sense of humor 2021-03-23 13:05:41 sarcasm is easy ;) 2021-03-23 13:06:34 yes, but not most people are brave to use it (most like to pretend they are serious) 2021-03-23 13:22:34 too many hipster languages 2021-03-23 13:22:55 fuck it, I guess I'll make a hipster language too and then sell training 2021-03-23 13:50:55 tehcloud: don't do that! if you make it you are risking to destroy rust ;) 2021-03-23 13:57:58 ... dude, crystal reports is definitely older than you. 2021-03-23 13:58:56 RootWyrm: I doubt that ;) 2021-03-23 13:59:50 1989, iirc. 2021-03-23 14:01:09 time when I had written small OS for 6502 2021-03-23 14:01:46 mps is older than most typical alpine contributors 2021-03-23 14:02:26 Ariadne: I think I'm not alone 2021-03-23 14:02:30 mps: for BBC micro? 2021-03-23 14:02:39 mps: no definitely not 2021-03-23 14:02:57 but i am older than crystal reports too 2021-03-23 14:03:12 heh, well i ain't exactly a spring chicken either 2021-03-23 14:03:14 minimal: no, I designed industrial computer with 6502 and made small real-time OS 2021-03-23 14:03:15 Ariadne: I guess I'm also in the older category 2021-03-23 14:04:17 mps: wrote a simple GUI for BBC Micro all in 6502 back in the day :-) 2021-03-23 14:04:35 ah, gui 2021-03-23 14:04:58 so you started all this 'nonsense' ;) 2021-03-23 14:04:59 s/all in 6502/all in assembler/ 2021-03-23 14:04:59 minimal meant to say: mps: wrote a simple GUI for BBC Micro all in assembler back in the day :-) 2021-03-23 14:06:32 mps: nope, that was PARC's fault lol 2021-03-23 14:07:02 minimal: yes, I remember. just kidding with you 2021-03-23 14:07:58 WIMP - Windows, Mouse and Pointing. what was I? I forgot 2021-03-23 14:08:14 1989 eh? Hmm, no Linux then, was playing with VMS instead lol 2021-03-23 14:08:24 mps: WIMP, I = Icons? 2021-03-23 14:08:30 ah, yes 2021-03-23 14:08:51 wimp(s) 2021-03-23 14:09:09 i can't even remember what i was fussing with.. probably AIX 2021-03-23 14:11:41 I played with Coherent Unix, but think that was in 1990 2021-03-23 14:12:33 may have looked at whatever BSD-derivative was out then 2021-03-23 14:12:43 BSDi 2021-03-23 14:13:24 ah, wait, would've been prior to that. stop making me feel old. 2021-03-23 14:14:43 BSDi? used that in 1995/6, was it around on 1989? 2021-03-23 14:15:44 at Uni all the machines were VAX VMS boxes so not much chance to get Unix handson 2021-03-23 14:16:48 to show how old I am, my normal CLI editor on Linux is "joe" (rather than "vi") as it supports Wordstar keystrokes lol 2021-03-23 14:19:11 oh, yes, also I used a little 'joe' but quickly switched to vi (elvis iirc) 2021-03-23 14:19:15 would've just been bsd 4.2 probably. 2021-03-23 14:20:13 also: ed is the standard unix editor 2021-03-23 14:21:12 RootWyrm: ed is a line-based editor (from memory) whereas vi is the standard screen-based editor 2021-03-23 14:21:33 loved EDT editor on VMS, wonder if anyone's ever ported it to Unix/Linux 2021-03-23 14:22:04 eh, on DOS there was edlin 2021-03-23 14:22:40 https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard_text_editor.html 2021-03-23 14:23:45 from that doc: "By the by, `vi' started it's life as a visual mode for ed" 2021-03-23 14:27:29 seems like community/py3-oscrypto test suite fails. Can someone help me with it? 2021-03-23 14:27:42 nmeum: looks like its your package 2021-03-23 14:49:13 ncopa: http://www.haproxy.org/download/2.1/src/CHANGELOG is now 'unmaintained' 2021-03-23 14:49:25 haproxy 2.1.x 2021-03-23 14:51:53 I told here some time ago that that could happen, and proposed to 'backport' 2.2 (LTS) but we didn't reached consensus 2021-03-23 14:53:02 what we should do now? (except to form committee for base pkgs) 2021-03-23 15:00:00 mps: does the same issue already apply for Alpine 3.10 & 3.11 which have haproxy 2.0.x packages as the Releases page says Alpine 3.10 and 3.11 are still supported currently? 2021-03-23 15:03:19 minimal: I checked only 3.12 2021-03-23 15:04:23 haproxy 2.0.x is LTS with EOL 2024-Q2 so I think they are ok 2021-03-23 15:06:49 mps: ah, where did you see the EOL mentioned? don't see it on the haproxy homepage. Less relevant for Alpine 3.10 as it goes out of support in just over 1 months time. 2021-03-23 15:07:12 http://www.haproxy.org/ 2021-03-23 15:07:42 mps: yeah just realised I was staring right at it but not seeing it lol 2021-03-23 15:09:05 you need better glasses? ;) 2021-03-23 15:11:43 nope, its a CPU issue, need a higher MHz brain :-) 2021-03-23 15:35:05 mps: i think we can deal with that when the first securiy issue shows up for haproxy-2.1 2021-03-23 15:36:21 i think i have less than 100 python 3.9 rebuilds for community now 2021-03-23 15:36:26 Neat 2021-03-23 15:37:00 766 commits so far 2021-03-23 15:38:20 Wew 2021-03-23 15:38:44 Oof 2021-03-23 15:47:28 and i haven't started with testing 2021-03-23 15:48:13 there are alot of py3-* packages that does nto have correct depends/makedepends/checkdepends. python 3.9 will call thouse out 2021-03-23 15:48:31 there are a few that needs patches to build with python 3.9 2021-03-23 15:51:08 there are a few that i have given up, like py3-adblock 2021-03-23 15:52:16 and py3-openzwave 2021-03-23 16:13:59 not sure what I can do to help 2021-03-23 16:14:13 I've tried to avoid looking at py3 packages till 3.9 is in 2021-03-23 16:15:16 Ariadne: isochronous upstream seems gone, d'you know if it's moved someplace? 2021-03-23 16:15:32 uhh 2021-03-23 16:15:40 i can put it somewhere 2021-03-23 16:36:31 detha got it to me 2021-03-23 16:36:35 i'll put it up on my server 2021-03-23 16:37:01 https://distfiles.alpinelinux.org/distfiles/isochronous-0.1.tar.gz 2021-03-23 16:42:08 o 2021-03-23 16:45:04 looks almost the same, except the one has an install target and openrc script 2021-03-23 16:47:02 vte3 is failing because it cannot detect the MIPS abi 2021-03-23 16:47:35 https://tpaste.us/vZzL 2021-03-23 16:47:38 failing on mips64& 2021-03-23 16:49:25 Did anybody start packaging jigasi, jitsi and jitsi-videobridge for Alpine? 2021-03-23 16:54:51 no 2021-03-23 16:55:07 for the alpine conference i am planning to just get fosshost to deal with that shit so we don't have to 2021-03-23 16:55:09 :P 2021-03-23 17:03:38 ncopa: ok 2021-03-23 17:13:07 PureTryOut[m]: FYI: I finally moved android-tools to community 2021-03-23 19:59:22 restarting gitlab really quick for a minor update 2021-03-23 20:03:02 oh, I still need to push it :( 2021-03-23 20:14:52 hi 2021-03-23 20:15:08 some mergers here atm? 2021-03-23 20:15:14 Yes, I was already loking 2021-03-23 20:15:16 looking 2021-03-23 20:15:30 !19689 is a serious release :D 2021-03-23 20:15:56 dont like to tell you how bad things can go :/ 2021-03-23 20:16:14 good story is, it's fixed now 2021-03-23 20:16:41 Need to see that we can get the test suite running again on most arches 2021-03-23 20:16:56 !19688 is the for master ... 2021-03-23 20:17:13 jup 2021-03-23 20:17:37 MRs will be merged after CI is finished 2021-03-23 20:17:45 big thanks :) 2021-03-23 20:18:58 the6543: are CVE's requested? 2021-03-23 20:19:22 we can not do this ourselfe jet ... 2021-03-23 20:19:30 huh? 2021-03-23 20:19:31 You can always request it 2021-03-23 20:19:39 I'll ask ... 2021-03-23 20:19:40 https://cveform.mitre.org/ 2021-03-23 20:20:29 yes gitea owners do this normaly via MITRE 2021-03-23 20:21:01 yes, the gitea maintainer should do this 2021-03-23 20:21:37 well I'm one of them ... 2021-03-23 20:21:40 ok 2021-03-23 20:22:02 I just never did it so no idear :O 2021-03-23 20:22:09 but others are aware of it 2021-03-23 20:22:11 I just did one the other day 2021-03-23 20:22:18 still waiting for a reply 2021-03-23 20:31:08 well we do for a earlyer XSS vul too 2021-03-23 20:44:53 hmm build-ppc64le act strange 2021-03-23 20:45:12 it pass and try to upload artifacts ... no next reaction :/ 2021-03-23 20:45:19 https://gitlab.alpinelinux.org/6543/aports/-/jobs/354505 2021-03-23 20:45:55 Network issues, uploading artifacts can sometimes take a bit longer 2021-03-23 20:46:07 not sure why, but it happens 2021-03-23 20:47:04 ok it's a known issue - can wait 2021-03-23 20:58:59 "a bit longer" :laughing: 2021-03-23 21:00:29 that might have been a slight understatement :P 2021-03-23 21:01:26 well it's merged and getting builded 2021-03-23 21:01:52 good 2021-03-23 21:02:13 2 jobs left 2021-03-23 21:41:27 the6543: all is merged 2021-03-23 21:41:38 updated my instance already 2021-03-23 21:41:45 its up and running again :rocket: 2021-03-23 21:41:59 thanks mates! 2021-03-23 23:31:05 for what arch should I build x86 packages in aports? 2021-03-23 23:31:14 i386/i486/i586/i686? 2021-03-23 23:32:17 i586-alpine-linux-musl seems to be target 2021-03-23 23:33:06 abuild should do the things 2021-03-23 23:38:36 problem is that that someone wrote big script determining this at himself 2021-03-23 23:40:33 https://github.com/romkatv/powerlevel10k/blob/master/gitstatus/build#L131 2021-03-23 23:40:44 https://github.com/romkatv/powerlevel10k/blob/master/gitstatus/build#L424 2021-03-24 00:22:07 uh? 2021-03-24 00:23:07 also gcc -dumpmachine seems to give quite decent answer when running on the target machine 2021-03-24 01:07:50 /w/w 33 2021-03-24 02:53:08 no-one in their right mind would run s390x or mips, so let them have their editor !19701 2021-03-24 02:53:14 ACTION grabs popcorn 2021-03-24 06:52:51 [20:53:06] no-one in their right mind would run s390x or mips, so let them have their editor !19701 2021-03-24 06:52:54 that's not very nice 2021-03-24 08:46:11 so there will be a new openssl release tomorrow with some important security fix 2021-03-24 08:46:25 Yes 2021-03-24 08:46:43 my plan for today is to update the kernels for stable branches and prepare for stable releases tomorrow 2021-03-24 08:46:54 Though, marked high, not critical 2021-03-24 08:47:31 would be good to make sure that the builders are all idle tomorrow 2021-03-24 08:47:40 so we can tag releases 2021-03-24 08:48:07 then if everythign goes well, i'll probably push python 3.9 on friday 2021-03-24 08:48:23 vte3 is blocking mips64 2021-03-24 08:55:15 im fixing openssh cve 2021-03-24 09:01:24 I need to backport haproxy to 3.12, maybe to 3.11 but have to look at it 2021-03-24 09:02:10 (instead of waste time on #alpine-offtopic :) ) 2021-03-24 09:02:45 :) 2021-03-24 09:33:30 i think this broke mips64 https://github.com/GNOME/vte/commit/6ff6542e902a1b7db6eca18cf8bccf24da431679 2021-03-24 09:34:55 Is it missing an include? 2021-03-24 09:37:30 i was about to say no, but it might actually be 2021-03-24 09:38:51 yes. we do have __NR_close_range in musl headers 2021-03-24 09:39:48 should be sys/syscall.h 2021-03-24 09:41:08 Ariadne: could't help myself, thanks for merging! 2021-03-24 09:41:43 (there are many good reasons to run any architecture and emacs is a very good editor) 2021-03-24 09:43:00 emacs is a pretty decent OS, it just lacks a good text editor :) 2021-03-24 09:43:11 :D 2021-03-24 09:44:10 classic =) 2021-03-24 09:52:59 iirc, I read somewhere that is possible to run vim inside in emacs (OS) 2021-03-24 09:53:48 or it is emulation of vim 2021-03-24 09:54:16 upstream report for vte3: https://gitlab.gnome.org/GNOME/vte/-/issues/342 2021-03-24 09:55:29 mps: both are possible 2021-03-24 09:58:23 being able to "run" vim in terminal emulation doesn't make it an OS though, IMO 2021-03-24 10:00:09 mps spacemacs has one of those vim-like editing settings for emacs 2021-03-24 10:01:37 dne: I meant that emacs is OS, not vim 2021-03-24 10:02:15 and this is well known joke about emacs 2021-03-24 10:02:18 yes I know 2021-03-24 10:05:26 mps: more like emulator than OS 2021-03-24 11:15:13 Did anyone gave the updated pipewire package a try, maybe PureTryOut (matrix.org)? 2021-03-24 11:15:48 Yesterday I installed the update, seemed to work fine? 2021-03-24 11:16:04 In addition to the usual configuration file breakage with every update, pipewire no longer detects my ALSA devices now :-/ 2021-03-24 11:19:21 Oh strange. I did replace the config file with the updated one 2021-03-24 11:19:24 I'll check right now 2021-03-24 11:22:38 Yeah works fine 2021-03-24 11:48:47 Downgrading to 0.3.23 didn't solve the issue for me. pipewire 0.3.21-r1 does work, though. 2021-03-24 11:53:15 The issues seem to be bigger than just ALSA. Screen recording via xdg-desktop-portal-wlr and bluetooth audio doesn't work - with pipewire not registering with bluez. 2021-03-24 11:59:17 0.3.22-r1 is the lasted working for me. 2021-03-24 12:03:13 ah, the sound server of the future is buggier than the previous sound server of the future 2021-03-24 12:03:48 :D 2021-03-24 12:05:36 Hmm, sway is also constantly crashing for me. I have the feeling the issue might not be pipewire directly. Was something dbus related updated recently? 2021-03-24 12:06:16 I don't think so but GNOME 40 bumps are currently being done so maybe that is relevant? 2021-03-24 12:06:59 Ariadne: Those are Alpine issues though, on other distros pipewire just works afaict (and Fedora might even use it as default for 34) 2021-03-24 12:07:25 my skepticism is galaxy-sized on this claim 2021-03-24 12:07:39 No, I don't think so :-( I have no GNOME related packages installed I know of 2021-03-24 12:08:21 The sway package doesn't seem to build anymore :-( 2021-03-24 12:09:21 https://www.youtube.com/watch?v=AbSehcT19u0&t=7 2021-03-24 12:10:07 Heh 2021-03-24 12:10:39 Ariadne: Well, when I rebased my Fedora 33 -> 34 I didn't even notice that it was using pipewire because it just worked 2021-03-24 12:13:39 is anyone doing firefox 87 on alpine? 2021-03-24 12:13:51 they switched minidump to rust and broke the build on musl 2021-03-24 12:14:06 because the libc and nix crate arbitrarily don't define some constants for musl 2021-03-24 12:14:33 and functions 2021-03-24 12:15:14 Ah yes, the bindings are only done per-target and are hand-written so I guess some stuff which folks didn't need yet haven't been added to those crates :/ 2021-03-24 12:15:50 from a further look, they actually managed to make it build only on x86 as well 2021-03-24 12:16:30 or maybe not, they just didn't use all the limitations defined in the nix crate for some stuff 2021-03-24 12:16:46 Cogitri: bindgen should have been used for libc :( 2021-03-24 12:21:18 Certainly, yes :/ 2021-03-24 12:25:08 well, if it works here I will have some patches you can use 2021-03-24 12:56:22 Cogitri: if you want to have Rust fun, https://github.com/msirringhaus/minidump_writer_linux/issues/4 :P 2021-03-24 14:41:42 uh, every few days new kernel release 2021-03-24 15:08:56 mps: new stable kernels again? 2021-03-24 15:09:55 ncopa: 5.10. is still .25 2021-03-24 15:10:27 but all other have new release today 2021-03-24 15:11:05 so, you have one hour of free time, go to walk ;) 2021-03-24 15:11:43 https://www.kernel.org/ 2021-03-24 15:13:28 ok, so 5.10.26 will likely show up soonish 2021-03-24 15:13:54 I would bet 2021-03-24 15:22:25 hey there, !19321 is waiting. is there a problem with it? 2021-03-24 15:23:42 looks ok. teh aarch build times out though 2021-03-24 15:25:08 no big suprise 2021-03-24 15:40:53 rnalrd: any reason why https://git.alpinelinux.org/aports/commit/?id=7c6239b112238719c308c1640f9cf50fcf44a148 ntopng got moved to unmaintained? did it stop building or something? 2021-03-24 16:02:08 ScrumpyJack, I can't remember if there was some issue that needed to be addressed. Anyway I'd be glad if someone else could pick it up from where I left it. 2021-03-24 16:04:03 ACTION nods 2021-03-24 16:14:35 skipfish: been busy sorry. will try merge it later tonight. just want to test build it on my aarch64 dev box first 2021-03-24 16:34:53 mps: i took a walk and there is still not 5.10.26... 2021-03-24 16:34:56 https://lwn.net/Articles/850353/rss 2021-03-24 16:38:07 1https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29133 2021-03-24 16:39:59 ikke: good job! thanks for following that up 2021-03-24 16:40:08 Ariadne: when bootstrapping, all APKs should come from the packages dir in ~/ right? 2021-03-24 16:40:22 yes 2021-03-24 16:40:30 for the target anyway 2021-03-24 16:41:08 Ariadne: Right now I have unmet dependencies when bootstrapping with libstdc++ and all the compilers coming from the host's package cache, instead of the systems, and that getting mixed up with the dependencies of the sysroot, which have different version numbers 2021-03-24 16:41:28 Looks like this: https://bpa.st/SZDQ 2021-03-24 16:41:46 foo_git is in edge. I build a modified version of v3.12.4 2021-03-24 16:41:52 (with newest gcc) 2021-03-24 16:42:16 The version numbers there are the normal (_pre)-r$X ones 2021-03-24 16:43:21 Thermi: system and target have to match 2021-03-24 16:43:37 Why though? 2021-03-24 16:44:02 the APKBUILD for some packages make that assumption 2021-03-24 16:44:05 Ewww 2021-03-24 16:44:14 improvements would be welcome 2021-03-24 16:44:20 I really dislike that. 2021-03-24 16:44:23 me too 2021-03-24 16:44:28 Like _really really_ dislike it 2021-03-24 16:44:32 yeah, me too 2021-03-24 16:44:45 may your strong dislike result in patches to improve it 2021-03-24 16:44:48 Got a possible suggestion on how to work around the issue? 2021-03-24 16:44:58 Well, it's not part of my work orders right now 2021-03-24 16:45:04 i just upgrade everything to latest edge and make sure git is aligned with latest edge 2021-03-24 16:45:07 and let it rip 2021-03-24 16:45:16 I'd rather not go down any more rabbit holes than I already did 2021-03-24 16:45:25 Thank you for your help 2021-03-24 16:47:18 I'm concerned I might become a rabbit really soon 2021-03-24 16:48:21 ncopa: but you enjoyed walk, I hope 2021-03-24 16:58:19 i did :) it was a good suggestion 2021-03-24 17:01:05 ncopa: is that okay to split off a chromium-lang package with one of the next updates? 2021-03-24 17:08:17 sure. sounds like a good idea 2021-03-24 17:08:32 skipfish: thank you for helping looking after chromium 2021-03-24 17:08:41 i appreciate 2021-03-24 18:07:26 ncopa: where are the community/py3-oscrypto tests failing? builds fine in abuild rootbld here 2021-03-24 18:21:27 against python3.9? 2021-03-24 18:25:15 ah, that might be 2021-03-24 18:26:14 ncopa: if you send me a buildlog for py3-oscrypto I can take a look :) 2021-03-24 18:27:45 @Cogitri assigned you to a glib upgrade 2021-03-24 19:39:07 might not be interesting at all, besides dropping the patch since it's now in the release 2021-03-24 21:55:11 Ariadne: Generally, when we bootstrap, the compiler that executes is the one that by itself is cross compiled to the host's architecture and libs, and the only special part is that it contains the code (that is otherwise stripped away at build time?!) to build binaries for other architectures (although the only thing different are probably ELF details, the instruction set, and potentially data type sizes). So what exactly needs to be handled 2021-03-24 21:55:11 seperately? 2021-03-25 05:34:55 Thermi: what do you mean by 'handled separately'? 2021-03-25 05:35:06 Thermi: the APKBUILDs predate bootstrap.sh 2021-03-25 05:35:24 Thermi: so they make assumptions that do not necessarily hold true in an optimal way under bootstrap.sh 2021-03-25 05:36:38 Thermi: if you're asking "why can't GCC just target all architectures" -- the answer is that GCC itself does not support that 2021-03-25 05:36:50 Thermi: it should be possible if clang becomes system compiler 2021-03-25 05:49:27 mps: do you have any objection to extend linux-edge APKBUILD with clang-built variants? 2021-03-25 07:48:46 Ariadne: not sure what you mean. but ofc, I'm not owner of alpine pkgs so you are free to change them 2021-03-25 07:49:21 this will give me excuse to remove pulse/pipewire and similar from other pkgs :) 2021-03-25 07:49:43 and libutmpx from some other 2021-03-25 07:51:49 what is idea? to build two linux-edge variants, one with gcc and one with clang? 2021-03-25 08:03:01 libstdc++ -> libc++ 2021-03-25 08:04:45 and runtimes and everything from llvm world 2021-03-25 08:07:39 heh, building kernel with llvm would be my next question ;) 2021-03-25 08:10:22 ... afaik that works now on arm, and x86 (with 32 and 64bit versions) 2021-03-25 08:12:19 ..let me run ARCH=arm64 CROSS_COMPILE=aarch64-linux-musl- make CC=clang LLVM=1 2021-03-25 08:12:27 mps: yes 2021-03-25 08:12:40 mps: since it is your package, i am asking what you think about it 2021-03-25 08:13:19 right now i am pondering alternatives to GNU make 2021-03-25 08:13:26 remake looks like a possible winner here 2021-03-25 08:13:44 it's a fork which removes all of the bitrot 2021-03-25 08:14:02 and its backward compatible with gmake 2021-03-25 08:14:27 i really, really, really, really, really, really, [* 100000000000] dislike GNU make the more I look at it 2021-03-25 08:14:43 there is also bmake in community/ 2021-03-25 08:14:43 this is just bad code 2021-03-25 08:14:47 Ariadne: do you have something like patch for APKBUILD to test it 2021-03-25 08:15:07 nmeum: yes, but bmake does not support gmake syntax (only the parts which became posix) 2021-03-25 08:15:11 yep 2021-03-25 08:15:21 remake is something we can make /usr/bin/make now 2021-03-25 08:15:44 though i think bmake with gmake extensions is a nice idea 2021-03-25 08:17:17 for now, i will package remake and add a `remake-make` package which provides=make as a symlink 2021-03-25 08:17:18 so, idea is to have gcc-linux-edge and clang-linux-edge 2021-03-25 08:17:23 yes 2021-03-25 08:17:41 so we can evaluate clang's ability to build a production-quality kernel 2021-03-25 08:17:41 https://github.com/rocky/remake 2021-03-25 08:17:42 this? 2021-03-25 08:17:44 yep 2021-03-25 08:17:54 ok 2021-03-25 08:18:50 looks mostly like a patchset on top of gmake though, doesn't it? 2021-03-25 08:20:07 it is an aggressive patchset 2021-03-25 08:21:30 it is a patchset which deletes most of gnu make code 2021-03-25 08:21:47 if you compare remake to gnu make source, it is a lot different 2021-03-25 08:22:16 there is also Google kati/ckati 2021-03-25 08:22:16 ah 2021-03-25 08:22:22 which is used to build Android 2021-03-25 08:22:32 but, it does not seem to be fully compatible 2021-03-25 08:23:13 the benefit of using remake here is that we get a gmake-compatible make without the cruft of supporting UNIX systems from 1980s 2021-03-25 08:23:44 also less awful GNU code 2021-03-25 08:23:58 the additional features also seem nice 2021-03-25 08:25:02 also, build -lts with clang would be good idea, more users could test it 2021-03-25 08:25:10 well 2021-03-25 08:25:21 i do not want to build -lts with clang until we are reasonably confident 2021-03-25 08:25:28 in clang's ability to generate a usable kernel 2021-03-25 08:25:41 because last time i tried, DRI was completely screwed because it compiled the RCU code wrong 2021-03-25 08:26:09 :) 2021-03-25 08:27:16 gcc is not good but I doubt that clang is better 2021-03-25 08:27:35 there are pros and cons to both 2021-03-25 08:27:40 yes 2021-03-25 08:28:11 but I'm not against your idea to test build with clang 2021-03-25 08:28:27 clang will make cross-compile easier 2021-03-25 08:28:37 hmm, not only build but test how it works 2021-03-25 08:28:39 since clang can emit code for anything LLVM supports 2021-03-25 08:29:00 clang is also more stable maintenance wise 2021-03-25 08:29:28 i would say 10 years from now, clang has a higher chance of being around 2021-03-25 08:29:41 gcc is kind of in a slow moving crash into a concrete wall 2021-03-25 08:30:08 i am sure all of this latest drama is only going to serve to accelerate that 2021-03-25 08:41:25 Yogi Berra — 'It's tough to make predictions, especially about the future.' 2021-03-25 08:51:56 CLang already is the first to receive shiny new features 2021-03-25 08:54:52 maybe Alpine will replace Linux as well in 10 years :p 2021-03-25 08:55:09 morning 2021-03-25 09:00:57 travankor: maybe mankind will be extinct in 10 years 2021-03-25 09:01:48 mps: CollapseOS predicts something more or less similar 2021-03-25 09:02:57 morning 2021-03-25 09:03:12 ncopa: good morning :) 2021-03-25 09:04:12 nmeum: the py3-oscrypto tests passes now. weird. im pretty sure they failed the other day from git master with python 3.8 on x86, also on my local python 3.9 branch 2021-03-25 09:06:43 travankor: hah, I'm (actually was) forth programmer so CollapseOS could be something where I can engage :) 2021-03-25 09:07:26 wow, nice :) 2021-03-25 09:07:38 im not sure replacing gnu make is a good idea. lots and lots of packages expects gnu make 2021-03-25 09:07:57 and I wrote one forth implementation on Z80 which runs from ROM 2021-03-25 09:08:01 i mean, how much problem is gnu make currently giving us? 2021-03-25 09:08:30 ncopa: too much, because it is GNU :P 2021-03-25 09:08:59 (I would like that we stop ideologies on alpine) 2021-03-25 09:12:58 replacing gcc with clang as system compiler is a more interesting goal IMHO 2021-03-25 09:13:05 a hardened clang, that is 2021-03-25 09:13:13 with CFI enabled etc 2021-03-25 09:14:06 ncopa: remake is interesting for that reason 2021-03-25 09:14:21 ncopa: it is (a) actually maintained, and (b) a fork of gmake and so compatible with gmake 2021-03-25 09:14:42 ncopa: it also removes all of the crap from GNU make that no longer matters 2021-03-25 09:15:12 sure, but what problem is gnu make causing? 2021-03-25 09:15:25 i agree that code is ugly 2021-03-25 09:15:45 but it kinda works, and doe not give us that much trouble, does it? 2021-03-25 09:15:54 the problem is that gnu make is poorly maintained and poorly maintained code is a security vulnerability waiting to happen 2021-03-25 09:17:13 remake also adds additional functionality which is actually helpful for package maintainers 2021-03-25 09:17:58 for example, you can inspect the state machine internal to make to figure out why make is erroring out 2021-03-25 09:18:25 what im afraid of is that if we replace gnu make, 30-40 packages will need patching and reporting upstream, and for every upstream report we will have to fight for upstream support remake in addition to gnu make 2021-03-25 09:18:56 i am planning to rebuild the entire aports tree with remake to verify that is not the case 2021-03-25 09:18:57 and we end up burning our resources on something that is not that big problem for little gain 2021-03-25 09:18:57 :p 2021-03-25 09:19:33 if gcc, linux kernel and openjdk* builds, then it will likely not be a big problem 2021-03-25 09:20:01 i thikn openjdk has some advanced gnu make usecases, which triggered bugs in gnu make 2021-03-25 09:20:05 remake would also have been helpful when we ad openjdk problems 2021-03-25 09:20:20 because we could have used the debug feature in it to figure out what was broken 2021-03-25 09:21:13 hm 2021-03-25 09:21:36 the more i think about it, the moreI think it might be actually doable 2021-03-25 09:21:42 without too much fuzz 2021-03-25 09:22:14 we could still have a gmake package for those packages that requires gnu make and refuse to support anything else 2021-03-25 09:23:00 yep 2021-03-25 09:23:06 precisely 2021-03-25 09:23:59 remake lets you visualize the rules too, with graphviz 2021-03-25 09:24:23 but still, if it is 100+ packages that needs modification, then it might be worth it 2021-03-25 09:25:51 also for docker users, who currently do `apk add make` would need to do `apk add gmake` or invoke `gmake` instead of `make` 2021-03-25 09:26:12 will potentially create an uproar 2021-03-25 09:27:42 its risky for questionable benefits IMHO 2021-03-25 09:27:50 it should be zero packages that require modification 2021-03-25 09:27:59 but either way, i don't plan to implement this in 3.14 2021-03-25 09:28:10 and zero dockerfiles 2021-03-25 09:28:12 i'm going to check to make sure it builds things that do "weird stuff" in gnu make fine first 2021-03-25 09:28:17 yeah 2021-03-25 09:28:32 in any case, i dont want that alpine is used to push a political agenda, so please make sure that this is for technical reasons, and not political 2021-03-25 09:28:45 it is for technical reasons 2021-03-25 09:29:10 i like the improved error output, cachegrind support, tracing and debugging features 2021-03-25 09:29:24 i also like that the maintainer is visibly maintaining the project 2021-03-25 09:29:39 verses GNU make where it went untouched for years and then GNU make 4.3 is released 2021-03-25 09:29:42 and it had bugs 2021-03-25 09:30:24 ncopa: what about 'pushing hipsters agenda'? :P 2021-03-25 09:30:43 no hipster in their right mind would be using make(1) anyway 2021-03-25 09:30:54 they would be using cargo, because they are writing it in rust 2021-03-25 09:30:59 come on now 2021-03-25 09:31:05 :) 2021-03-25 09:31:15 so we need WD40 2021-03-25 09:31:29 what would that do? convert rust to C? :) 2021-03-25 09:31:50 de-rust 2021-03-25 09:32:14 i.e. remove rust from screws 2021-03-25 09:32:23 yes i know 2021-03-25 09:32:50 uh, I don't know is WD40 widely known 2021-03-25 09:33:19 i suppose hipsters are ok :) 2021-03-25 09:33:41 mps: yes, quite known 2021-03-25 09:34:00 what i would really like is bmake with gnu make extensions 2021-03-25 09:34:05 ncopa: yes, to make serious people laugh 2021-03-25 09:34:17 bmake is, you know 2021-03-25 09:34:20 much faster than gmake 2021-03-25 09:34:30 we could shave entire seconds off our compile times 2021-03-25 09:34:34 if such a thing existed 2021-03-25 09:34:42 i guess anything is much fatster than gmake 2021-03-25 09:34:47 but remake is at least clean enough 2021-03-25 09:34:53 that i can work on making it fast 2021-03-25 09:34:59 which is not possible with GNU make 2021-03-25 09:35:06 i encourage everyone to actually look at GNU make 2021-03-25 09:35:14 the code is not... maintainable 2021-03-25 09:35:46 mps> (I would like that we stop ideologies on alpine) 2021-03-25 09:35:54 i think that is wise ^^^ 2021-03-25 09:36:04 my brain buzz about something 'bsd make'. does such thing exists or it just buzz in brain 2021-03-25 09:36:08 i disagree; some ideologies is good 2021-03-25 09:36:15 like "bloated software is bad" 2021-03-25 09:36:22 and "unmaintainable software is bad to depend on" 2021-03-25 09:36:51 well, what i mean is using alpine for political reasons or political activism 2021-03-25 09:37:11 well, i am not terribly interested in "war on FSF" 2021-03-25 09:37:27 what i am interested in is "war on shite code" 2021-03-25 09:37:36 Ariadne: "bloated software is bad" is not ideological stance, it is plain fact imo 2021-03-25 09:37:47 and the reason is that having a friendly community is a high priority goal 2021-03-25 09:37:51 unfortunately the GNU project is purveyor of many instances of "shite code" 2021-03-25 09:38:05 Ariadne: please 2021-03-25 09:38:10 so it may appear "political" when in reality, i am just offended by the code 2021-03-25 09:38:12 :) 2021-03-25 09:38:19 mps: you know it is true 2021-03-25 09:38:33 there are high quality GNU packages 2021-03-25 09:38:42 but there is a lot of very bad quality GNU packages too 2021-03-25 09:38:46 yes, you are right, but most if not all code is far from perfect 2021-03-25 09:39:14 did you know GNU make supports plugins? 2021-03-25 09:39:24 yes 2021-03-25 09:39:30 Ariadne: i agree with that, but we should probably focus more on the specific packages than that they come from GNU 2021-03-25 09:39:30 and this does not terrify you 2021-03-25 09:39:37 ncopa: agree 2021-03-25 09:39:40 and I don't think this is good 2021-03-25 09:40:12 I mean, gmake plugins 2021-03-25 09:40:18 the guile support in gmake is questionable indeed. i dont want enable it unless it is absolutely necessary 2021-03-25 09:40:32 due to it needs to be bootstrapped 2021-03-25 09:40:37 GNU make is just 2021-03-25 09:40:39 terrifying 2021-03-25 09:40:57 remake can, with some nudging, be a path to sanity on this topic 2021-03-25 09:41:14 i do not think we can expect such sanity out of GNU make (or, really, anything other than a maintenance release per decade) 2021-03-25 09:41:15 i have looked at the gmake code and sent patches to it, no arguing against that 2021-03-25 09:42:14 anyway, im gonna work on kernels and stable branches today so we can tag releases as soon the openssl issue is published 2021-03-25 09:42:19 besides, alpine has done other things people may see as "political", like refuse to touch systemd 2021-03-25 09:42:21 :) 2021-03-25 09:42:41 i just want an actually maintained make 2021-03-25 09:42:46 i would appreciate some help with build-3-12-mips64 2021-03-25 09:42:50 not sure why it fails 2021-03-25 09:42:55 what is up with build-3-12-mips64 2021-03-25 09:43:02 heh, musl doesn't support systemd but you know this 2021-03-25 09:43:40 mps: did not stop OpenEmbedded 2021-03-25 09:43:58 with a few dozen patches, anything is possible 2021-03-25 09:44:00 if dalias make systemd work on musl I bet we will have it in alpine 2021-03-25 09:44:34 i mean, it is possible 2021-03-25 09:44:34 no, if lennart would have supported musl libc or posix, we'd probably already have it 2021-03-25 09:44:45 but 2021-03-25 09:44:52 we talked to lennart at the beginning of systemd 2021-03-25 09:44:56 though I lost my yesterday bet on linux 5.10.26 release 2021-03-25 09:44:59 and he was not interested in cooperating with us 2021-03-25 09:45:20 problem was that s*d explicitly said they only support gnu libc, and that everything else should be bug-by-bug compatible with glibc 2021-03-25 09:45:20 so instead, we will just ship OpenRC 0.42.1-r937 2021-03-25 09:45:38 hah, so he was not bad person then ;) 2021-03-25 09:45:59 they basicly said they dont care about standards, just a specific implementation (glibc) 2021-03-25 09:46:28 mps: anyway i am talking to drobbins (e.g. of funtoo) about collaborative maintenance of OpenRC 2021-03-25 09:46:31 since, uhh 2021-03-25 09:46:55 gentoo isn't doing it and the gentoo devs seem to be pushing systemd these days 2021-03-25 09:47:05 my personal opinion is that we should use runit 2021-03-25 09:47:25 well, we can evaluate alternatives 2021-03-25 09:47:39 but we need something better than a future of openrc-0.42.1-r937 2021-03-25 09:47:48 that's not gonna work 2021-03-25 09:47:59 Didnt skarnet work on a more user friendly s6-rc for alpine? 2021-03-25 09:48:05 so i think it makes sense to work with other openrc users for now 2021-03-25 09:48:14 to ensure maintenance of openrc 2021-03-25 09:48:22 Cogitri: he is working on something yes 2021-03-25 09:48:38 does not change fact that we need a maintenance story for openrc now 2021-03-25 09:48:40 we will need to maintain openrc for some time regardless, yes, due to our stable branches 2021-03-25 09:48:48 Ariadne: I agree about colaboration with other distro who use openrc 2021-03-25 09:48:49 lights are on at openrc, but nobody is actually home anymore 2021-03-25 09:50:00 what i want to ultimately see is something that feels right for alpine 2021-03-25 09:50:09 openrc feels right for alpine in terms of user experience 2021-03-25 09:50:16 but, it has a lot of warts 2021-03-25 09:50:26 on the other hand, we have gotten a lot of mileage out of it 2021-03-25 09:50:39 but in the long term it is definitely time to move on 2021-03-25 09:50:51 *for now* though, we do need to answer this problem of openrc maintenance though 2021-03-25 09:51:10 i actually think that the declarative-style openrc files are relatively nice 2021-03-25 09:51:28 yes, agree 2021-03-25 09:51:40 i would like to see something truly supervisor-first though 2021-03-25 09:51:45 supervise-daemon has a lot of downsides 2021-03-25 09:51:50 yeah 2021-03-25 09:51:52 agree 2021-03-25 09:52:07 thats where skarnet and s6 come in 2021-03-25 09:52:10 that is, runit :) 2021-03-25 09:52:12 if we make s6 pretty 2021-03-25 09:52:15 or runit 2021-03-25 09:52:17 or whatever 2021-03-25 09:52:35 i would like to go with skarnet's solution because skarnet has always been kind and available and helpful to this community 2021-03-25 09:52:59 over runit 2021-03-25 09:53:37 either way, we need to 'solve' openrc 2021-03-25 09:53:37 void is quite fine runit 2021-03-25 09:53:46 good for void 2021-03-25 09:53:59 but no man pages for s6 :( 2021-03-25 09:54:27 mps: i'm sure runit is fine (for what it is) 2021-03-25 09:54:44 but djb style tools do not really provide a user experience that alpine users expect 2021-03-25 09:54:59 as ddevault put it, "alpine is the only linux distribution i can fit in my head" 2021-03-25 09:55:09 this is because the tools all have a similar feel to them 2021-03-25 09:55:10 tbh, i like the systemd-like eventhandler approach better than the runit poll approach 2021-03-25 09:55:37 i think preserving the user experience is the most important thing 2021-03-25 09:55:47 yeah 2021-03-25 09:55:50 how it is "plumbed" is not that important 2021-03-25 09:56:14 then we have to stay with openrc for some future 2021-03-25 09:56:33 i don't think that is necessary 2021-03-25 09:56:46 it is possible to build a modern replacement that has the same feel to it 2021-03-25 09:57:07 ab6376dac461c0b1b7727d4d5b268123dde66cca disabled mips64 2021-03-25 09:57:14 if anything, such a replacement would be even more consistent 2021-03-25 09:57:23 and was backported to 3.12 so containerd fails to build 2021-03-25 09:57:28 let me clean up mips64 2021-03-25 09:58:00 :) 2021-03-25 09:58:17 go is back on mips64 (thanks to loongson) 2021-03-25 09:58:21 oh 2021-03-25 09:58:30 the problem is that 3.12 does not have go 2021-03-25 09:58:47 runit isn't great user experience if only because it doesn't have dependency management 2021-03-25 09:58:48 yeah 2021-03-25 09:59:14 The amount of users we had in Void who complained about networkmanager being broken because they forgot to enable the dbus service was insane :p 2021-03-25 09:59:35 indeed that is my point 2021-03-25 09:59:59 meh 2021-03-25 10:00:01 32c4f23765f4af34a77b425bdf61fc40354a59de enables mips64 2021-03-25 10:00:08 which breaks the build 2021-03-25 10:00:36 build on 3.12? 2021-03-25 10:00:44 yeah 2021-03-25 10:00:48 yeah 2021-03-25 10:00:50 makes sense 2021-03-25 10:00:59 3.12 unfortunately did not ship with go :( 2021-03-25 10:03:35 ok! all builders are idle! 2021-03-25 10:06:23 in other news, i am working on porting OpenBGPD to Alpine 2021-03-25 10:06:55 reminds me, the openntpd needs to be fixed in alpine 2021-03-25 10:07:05 there is an open issue on it 2021-03-25 10:07:24 its gonna be lit 2021-03-25 10:07:39 i thikn the prolbem is that alpine-baselayout ships an ntp user but openntpd needs the home dir to be somewhere else 2021-03-25 10:07:47 and openntpd silently fails 2021-03-25 10:08:31 imo we should deprecate those users in baselayout 2021-03-25 10:08:37 yeah 2021-03-25 10:14:13 i know 2021-03-25 10:14:18 what if we just converted all makefiles 2021-03-25 10:14:22 to ninja files 2021-03-25 10:14:24 at runtime 2021-03-25 10:14:31 and then ran samu(1) against them 2021-03-25 10:15:04 I would expect makefiles to be more complex than ninja files 2021-03-25 10:15:21 Yeah, ninja is a lot simpler (fortunately) 2021-03-25 10:16:09 afontain_: just do some preprocessing duh 2021-03-25 10:16:48 i am mostly kidding don't worry :) 2021-03-25 10:17:45 do like cmake that explicitely lists every file 2021-03-25 10:18:33 though 2021-03-25 10:18:36 imo 2021-03-25 10:18:43 we should use samu everywhere we use cmake 2021-03-25 10:18:54 Yup, using ninja everywhere would be nice 2021-03-25 10:19:02 PureTryOut[m]: ^? 2021-03-25 10:19:35 Sure that's fine by me 2021-03-25 10:48:46 systemd: I was early adopter because I liked declarative syntax, dependencies handling and event-driven actions but after few years changed my 'like' to 'dislike' (not hate, I don't hate much things, if anything) and switched to openrc (all that on debian) 2021-03-25 10:51:13 I'm kinda mixed about systemd. It can be quite practical 2021-03-25 10:51:36 oh, and before systemd I used upstart also 2021-03-25 10:51:47 and for a distro that would like to do some things by default, a systemctl --user is also quite practical 2021-03-25 10:52:02 (that's not Alpine's usecase, I know) 2021-03-25 10:54:01 Yup, things like coredumpctl and journalctl are kind of nice too imho 2021-03-25 10:56:13 it would be practical to get stdout from the programs without explicitely piping to logger 2021-03-25 11:03:20 afontain_: I do this with runit and logger combo for some/most in-house programs 2021-03-25 11:03:35 and daemonless programming 2021-03-25 11:04:27 [09:46:54] gentoo isn't doing it and the gentoo devs seem to be pushing systemd these days 2021-03-25 11:04:33 we're not pushing systemd and we'd welcome help with openrc 2021-03-25 11:05:19 with all due respect, if you want alpine to contribute to direct maintenance of openrc, it needs to be something other than a "gentoo project" 2021-03-25 11:05:27 it's not a gentoo project though 2021-03-25 11:05:38 it has its own github, outside of gentoo, and the bugtracker is on gh 2021-03-25 11:05:42 william doesn't consider it a gentoo proj at all 2021-03-25 11:05:46 the website is on gentoo.org, everyone who commits to it are gentoo devs 2021-03-25 11:06:07 https://github.com/openrc/openrc is the canonical upstream? 2021-03-25 11:06:16 my point is, have you approached him yet? 2021-03-25 11:06:26 he's very friendly 2021-03-25 11:06:41 yes, we have talked a few times over the years 2021-03-25 11:06:50 i'm quite happy to poke him about something if it'd be useful 2021-03-25 11:06:52 but i don't think williamh has much interest in maintaining openrc anymore 2021-03-25 11:07:11 i would like to see an openrc where all distributions are sharing in the maintenance burden 2021-03-25 11:07:16 that includes gentoo of course 2021-03-25 11:07:33 but from what i see, there is not much going on with openrc anymore 2021-03-25 11:07:50 gentoo is shipping a version of openrc that is not even tagged in github 2021-03-25 11:08:13 oh yeah I think that's a pretty fair assessment, I just mean it's not because it's a "gentoo proj" 2021-03-25 11:08:19 i'm not sure that's right though, gentoo has 0.42.1? 2021-03-25 11:08:26 i think gentoo has 0.42.2 2021-03-25 11:08:27 https://github.com/OpenRC/openrc/releases/tag/0.42.1 2021-03-25 11:08:34 0.42.1 is tagged, but 0.42.2 is not 2021-03-25 11:08:36 i've been poking william to make a new release which he's finally doing too 2021-03-25 11:08:44 .2 is not in gentoo 2021-03-25 11:08:58 are you sure? 2021-03-25 11:09:10 i remember seeing a 0.42.2 in gentoo 2021-03-25 11:09:12 basically i'm fully on board with here, i think way more collaboration is needed given we have so many other consumers 2021-03-25 11:09:12 who else should we have on-board? adelie linux? 2021-03-25 11:09:21 honest! https://packages.gentoo.org/packages/sys-apps/openrc 2021-03-25 11:09:25 strange 2021-03-25 11:09:32 idk where i saw openrc 0.42.2 then 2021-03-25 11:09:39 well anyway 2021-03-25 11:09:52 i would suggest that we all have a discussion about the "future" of openrc 2021-03-25 11:10:03 and yes, i think funtoo, gentoo, us and adelie should all be present for that 2021-03-25 11:10:30 that sounds like a good idea 2021-03-25 11:10:37 it's definitely languished 2021-03-25 11:11:10 from our POV nothing is "happening", and i got asked by a funtoo contributor yesterday about our openrc patchset 2021-03-25 11:11:47 and they told me that from what they see, mgorny and some other gentoo devs are pushing heavily for systemd 2021-03-25 11:11:49 a few months ago I ended up doing a bit of a survey and I was alarmed that so many 'downstreams' have to patch 2021-03-25 11:11:55 maybe other gentoo people have other opinions 2021-03-25 11:12:02 honestly the neutrality isn't going anywhere any time soon 2021-03-25 11:12:18 some of us like systemd more but it's not going to be a monoinit or anything 2021-03-25 11:12:27 the neutrality will naturally "go away" if the alternative init is not maintained 2021-03-25 11:12:33 absolutely 2021-03-25 11:12:44 just like i am planning to replace GNU make with a fork that is actually maintained 2021-03-25 11:13:23 ncopa: last time I installed devuan it offered openrc 2021-03-25 11:13:56 devuan should probably be involved too 2021-03-25 11:13:57 a good path would probably be something like working to upstream these patches then once he's happy, discuss commit access, but make clear that's what your aim is up front 2021-03-25 11:14:07 and debian still have openrc as option to install (manually though) 2021-03-25 11:14:08 i suspect he'd be up for this 2021-03-25 11:14:21 my aim is an organization where all stakeholders have commit privs 2021-03-25 11:14:30 yeah that's very reasonable 2021-03-25 11:15:02 the main reason we jumped on the musl train is because we got stuck with maintaining uClibc alone 2021-03-25 11:15:22 to us, it feels like similar situation 2021-03-25 11:20:11 I said this in #gentoo-dev: https://dpaste.com/98GUVRQJ3 2021-03-25 11:20:41 yeah 2021-03-25 11:32:29 Ariadne: is cachegrind actually useful on modern cpus? 2021-03-25 11:36:50 regarding mgorny and systemd, it seems not so much "pushing systemd" as "making stuff that relies on systemd apis because they're better than the hacky alternatives" and expecting people who want it without systemd to put in the work to make it compatible (see: eudev, elogind, utmpfiles or whatever it's called) 2021-03-25 11:37:16 Hello71: cachegrind itself, no, but the reporting format is because there are nice viewers for it 2021-03-25 11:37:23 I don't have an opinion on whether this is a good way to work, just saying that's how I see it 2021-03-25 11:37:43 i think that's more accurate 2021-03-25 11:38:02 although i'd say in reality there's nothing which is actually going to happen to kill openrc 2021-03-25 11:38:10 it's just more likely that openrc will die a death of inactivity right now 2021-03-25 11:38:59 yes 2021-03-25 11:45:15 mps https://termbin.com/tjuv could work 2021-03-25 11:45:41 also https://termbin.com/a42z 2021-03-25 11:45:52 oops I forgot to add -clang into that pkgname 2021-03-25 11:46:19 I don't have builder now on my hands so can't test 2021-03-25 11:46:51 to use LLVM integrated assembler or not, that is question. LLVM_IAS=1 should be added to the make command 2021-03-25 11:47:04 Ariadne: ^ any opinions 2021-03-25 11:47:27 i think we should avoid LLVM_IAS for now 2021-03-25 11:47:39 just the most conservative clang kernel build, please 2021-03-25 11:47:46 that was my thought 2021-03-25 11:48:29 and we want to track latest kernel 2021-03-25 11:48:31 I did LLVM_IAS cross build of rpi kernel (not with abuild) and it looked good 2021-03-25 11:48:33 not the LTS kernel 2021-03-25 11:48:52 i think linux-edge can deploy on RPi 2021-03-25 11:49:19 I could test it 2021-03-25 11:49:35 ... just those overlays need to be there 2021-03-25 11:53:52 (I'm a bit surprised one would start by testing the kernel btw) 2021-03-25 11:54:14 afontain_: I guess the idea is that if it cannot compile the kernel, the rest is moot 2021-03-25 11:54:16 clang things? =) 2021-03-25 11:55:18 Well, I would appreciate to keep a gcc package. You would expect to be able to drop it? 2021-03-25 11:55:29 afontain_: I think it will still remain around 2021-03-25 11:55:37 just not as default system compiler 2021-03-25 11:57:08 when people talk about switching to clang, I must say I didn't expect the "and start by linux" ^^ 2021-03-25 11:57:15 :D 2021-03-25 11:57:16 afontain_: we will have to keep gcc for Ada, D and possibly Rust in future 2021-03-25 11:57:24 afontain_: also fortran 2021-03-25 11:57:24 Ariadne: let's hope re the latteer 2021-03-25 11:57:28 latter* 2021-03-25 11:57:39 re? 2021-03-25 11:57:50 what makes clang interesting is that it will make cross compiling a lot simpler for us 2021-03-25 11:57:59 that is why i want it 2021-03-25 11:58:22 right now to cross compile you have to go build a gcc that cross compiles, then build a musl with it, and then another gcc 2021-03-25 11:58:32 like 3 gcc packages total 2021-03-25 11:59:30 well, it sure would make sense to cross compile the kernels 2021-03-25 11:59:31 with clang, the compiler is already there, we just need to supply a sysroot 2021-03-25 11:59:38 Ariadne: do you happen to have boostrap.sh work done for clang? 2021-03-25 11:59:40 though at least you don't need to compile musl too 2021-03-25 11:59:51 afontain_: im talking about bootstrap.sh 2021-03-25 12:00:01 artok: not yet 2021-03-25 12:00:07 ok 2021-03-25 12:00:22 artok: i want to confirm clang is ready before sinking too much time into this 2021-03-25 12:05:43 fwiw, in terms of the system, most of the issues we hit are lame -Werror ones 2021-03-25 12:05:55 we have a few people who randomly compile packages in gentoo with Clang and LLD 2021-03-25 12:06:17 I can't think of anything critical showstopper other than glibc for us which obviously isn't an issue there, and kernel itself depends 2021-03-25 12:23:33 afontain_: artok: no worries, we will keep gcc for long long time 2021-03-25 12:26:26 ACTION hit just dabuild on clang-linux-edge 2021-03-25 12:30:59 I got question for INIT_STACK_* 2021-03-25 12:33:12 use the default 2021-03-25 12:33:26 [06:23:31] afontain_: artok: no worries, we will keep gcc for long long time 2021-03-25 12:33:32 yes, i have no intention to drop gcc 2021-03-25 12:33:51 i think we have a good workflow for maintaining gcc 2021-03-25 12:42:45 i just think we can do more interesting things with clang 2021-03-25 12:42:52 because clang people want to build interesting things 2021-03-25 12:43:12 though GCC is picking up interesting things too 2021-03-25 12:45:26 sure enough, I did https://github.com/djazo/meson-crossfiles yesterday and build same software from macos for all those targets 2021-03-25 12:46:09 fundamentally loving clang and whole llvm.. and btw libc++ is smaller than libstdc++ ;) 2021-03-25 13:13:33 travankor: there *are* manual pages for s6: https://github.com/flexibeast/s6-man-pages If you want to package them for Alpine, your contribution will be well appreciated! 2021-03-25 13:15:20 Ariadne: thanks for the kind words, speaking of which, where's the dnsfunnel testing at? and the rebuild with utmps? O:-) 2021-03-25 13:18:48 skarnet: i think most things have utmps now 2021-03-25 13:19:10 skarnet: dnsfunnel, i haven't had time to test yet :( 2021-03-25 13:19:59 Ariadne: maybe will not have utmps for long ;) 2021-03-25 13:20:16 re utmps, I reported a bug to busybox a couple months ago that made it impossible to build against it 2021-03-25 13:20:18 vda fixed it 2021-03-25 13:20:24 so now it should be doable 2021-03-25 13:21:01 mps: i don't think it is harming you, why not leave it alone? :) 2021-03-25 13:21:17 mps: we obviously share the same vision about software and what is good for computing so I don't understand why you feel the need to be such a dick with me 2021-03-25 13:21:40 skarnet: please, use kind words 2021-03-25 13:21:53 maybe use kind thoughts and actions and I will 2021-03-25 13:21:56 it is not about you or your software 2021-03-25 13:22:12 you keep saying that but it's obviously not true 2021-03-25 13:22:27 it is about principle to have 'simple, small' distro 2021-03-25 13:22:46 and that's what I'm trying to do, you're welcome 2021-03-25 13:23:13 yeah the utmps stub when staticly linked is only 3KB 2021-03-25 13:23:44 I agree in most thing with you, only sometimes I think you can 'chose' words 2021-03-25 13:23:49 and if you do not run utmpd 2021-03-25 13:23:52 you do not have utmp 2021-03-25 13:24:31 or it is 'choose' 2021-03-25 13:24:59 'choose', but I don't get what you mean 2021-03-25 13:25:09 mps: well i would appeciate it if you leave utmps alone 2021-03-25 13:25:26 because there are people who have asked for utmps 2021-03-25 13:25:38 which is why skarnet wrote it and i started implementing it in alpine 2021-03-25 13:25:43 Ariadne: heh, you know that I will not remove all this 2021-03-25 13:26:07 and please stop promoting runit, which was promising for two minutes and a half and is now unmaintained and obsolete, despite void clinging to it like smallpox on clergy 2021-03-25 13:26:13 actually I will not touch it 2021-03-25 13:26:36 sure, but is unkind to the people working on solving that request to keep joking this way 2021-03-25 13:27:13 no, it is not 2021-03-25 13:27:38 as a person working on this topic, i am telling you i find it unkind 2021-03-25 13:27:45 I told more times that I appreciate skarnets works and software, because I think it is good 2021-03-25 13:27:46 please stop 2021-03-25 13:28:03 Ariadne: also 2021-03-25 13:28:22 stop saying you appreciate my work while undercutting it at every possible opportunity. Choose one or the other. 2021-03-25 13:29:46 I choose whatever I want 2021-03-25 13:30:20 of course, but understand that it makes me antsy when you say black and do white, every time. 2021-03-25 13:31:15 skarnet: ok, understand, and sorry. I thought your 'skin is thicker' and you understand 2021-03-25 13:32:16 well when the jokes are always directed the same way, they stop being just jokes 2021-03-25 13:32:48 you haven't made it clear that you were 'just joking' and it's not unreasonable for me to ask what you have against me 2021-03-25 13:33:56 hmm, just yesterday I mentioned Wittgenstein on other channel 2021-03-25 13:34:01 and I would like this tension to be resolved because as far as software quality and vision is concerned, I think we're on the same side 2021-03-25 13:34:44 yes, I think we are on the same side 2021-03-25 13:35:20 damn I forgot to take -virt away from my package building 2021-03-25 13:35:37 maybe (probably) we don't have 'same mind' but mostly I agree with you 2021-03-25 13:37:16 then I will ask you to please understand how my software works before dismissing it, and I will welcome constructive and detailed criticism 2021-03-25 13:37:42 Ariadne has significant criticism of my software, related to UI, and it's entirely reasonable and actionable 2021-03-25 13:37:54 so I'm working on it 2021-03-25 13:38:01 well i am a greedy distribution maintainer 2021-03-25 13:38:08 who would like to use s6 2021-03-25 13:38:13 but i want s6 to 'feel right' 2021-03-25 13:38:44 alpine focuses a lot of attention on refining the user experience with its tools 2021-03-25 13:38:46 yeah I understand that, my point is I'll gladly take your criticism over mps-style dismissive comments at every opportunity 2021-03-25 13:39:06 openrc is kind of the exception where it mostly felt right out of the box 2021-03-25 13:39:34 and I wish mps would back up his dismissiveness with precise pain points I could work on 2021-03-25 13:40:28 did openrc feel right ootb 1. because of its UI? 2. because it embedded a lot of policy and premade service scripts? 3. both? 2021-03-25 13:40:55 (I think it's a bit of both but I don't want to put words in your mouth) 2021-03-25 13:41:48 mostly 1, if you look at our packaging, we replace a lot of the service scripts 2021-03-25 13:42:49 (FWIW, this is probably another good point for us to work together on) 2021-03-25 13:44:43 sam_: in the long run we want to replace openrc with something else 2021-03-25 13:48:45 hello, I have issues running bootstrap.sh for aarch64 and 3.13.2. 2021-03-25 13:49:00 midasi: bootstrap.sh is only supported for alpine edge 2021-03-25 13:49:15 Ariadne: yes I know 2021-03-25 13:49:39 then why 3.13.2? 2021-03-25 13:49:40 but my issue is imho not related to that 2021-03-25 13:49:50 okay, what is your issue 2021-03-25 13:49:51 libgit2: Analyzing dependencies... / ERROR: unable to select packages: /bin/sh (virtual): / provided by: busybox / required by: ca-certificates-20191127-r5[/bin/sh] 2021-03-25 13:50:06 during building libgit2 the error above is raised 2021-03-25 13:50:11 aha 2021-03-25 13:50:19 i do have a fix for that (in edge) 2021-03-25 13:50:23 ok 2021-03-25 13:50:41 is it an abuild fix? 2021-03-25 13:50:52 it is a bootstrap.sh fix 2021-03-25 13:51:02 fair enough 2021-03-25 13:51:06 midasi: 21313b87823f330c4dbaa50ccc426a081e1cb641 2021-03-25 13:51:41 i don't usually backport bootstrap.sh fixes to release branches 2021-03-25 13:52:08 I thought I backported all fixed but apparently I missed this one 2021-03-25 13:52:29 thank you 2021-03-25 13:52:36 glad we got it sorted 2021-03-25 13:54:37 sam_: what we ultimately want is a reactive service manager that is supervision-first and uses declarative units in a way similar to systemd (so that people who have familiarity with systemd can easily pick up writing units) 2021-03-25 13:54:51 that'd be an absolute dream 2021-03-25 13:55:08 I don't even really dislike systemd, I'd just prefer an alternative to exist 2021-03-25 13:55:24 I find that writing init scripts for OpenRC and friends is a huge pain and involves far more effort 2021-03-25 13:55:55 and we want the UX to be similar to what we have now with openrc 2021-03-25 13:56:04 that's the plan but it's still some ways away 2021-03-25 13:56:30 i wonder if it makes more sense to figure out how to fund skarnet to work on this 2021-03-25 13:56:40 instead of working on some way to continue maintenance of OpenRC 2021-03-25 13:56:47 that's what i thought based on his messages on adelie 2021-03-25 13:56:53 basically everyone other than devuan wants what we want 2021-03-25 13:57:15 that would definitely make me work 100% full-time on it right away 2021-03-25 13:58:21 :) 2021-03-25 13:59:09 Ariadne: Related to 21313b87823f330c4dbaa50ccc426a081e1cb641: Why isn't that dependency automatically picked up without the EXTRADEPENDS_TARGET? 2021-03-25 13:59:35 Thermi: it is an edge case in the apk-tools resolver 2021-03-25 13:59:50 apk-tools 2.13 will likely have a fix 2021-03-25 14:00:00 I see, thank you 2021-03-25 14:09:45 openssl update is out. https://www.openssl.org/news/vulnerabilities.html 2021-03-25 14:09:53 i just pushed to git master 2021-03-25 14:10:03 Cogitri just pushed GNOME 40 2021-03-25 14:10:48 uname -a .... Linux gina 5.11.9-0-edge #1-Alpine-Clang SMP PREEMPT Thu, 25 Mar 2021 12:25:45 +0000 x86_64 Linux 2021-03-25 14:11:01 ok. i'll focus on the stable branches then and tag edge snapshot on monday then 2021-03-25 14:11:03 it builds, and boots, ship it! 2021-03-25 14:11:47 if it builds, it's tested; if it boots, it's shipped! 2021-03-25 14:12:14 Oh, unfortunate timing on my part then 2021-03-25 14:12:40 i think its okish, the only downside is that builders are busy 2021-03-25 14:13:13 Ariadne: gimme a sec, there's an old project i can never remember the name of. 2021-03-25 14:14:30 Ariadne: launchd,relaunchd,nosh - all related. potentially could be picked back up because of permissive licensing. 2021-03-25 14:14:57 mps doing changes to linux-edge soon? 2021-03-25 14:15:00 but in general, supervision is a very very good foot cannon. 2021-03-25 14:15:24 yay more fud 2021-03-25 14:15:26 RootWyrm: yes, those could be picked up 2021-03-25 14:15:34 RootWyrm: however, we know what we already want 2021-03-25 14:15:35 artok: I think you can add clang-linux-edge and maintain it ;) 2021-03-25 14:15:37 RootWyrm: and it's not that 2021-03-25 14:15:54 i assure you, what we want does not exist 2021-03-25 14:16:06 it has to be written, and skarnet is the most qualified person to do it 2021-03-25 14:16:27 which is why i'm saying they could be cherrypicked 2021-03-25 14:16:41 mps thought so, so I'm just asking if you're going through updates, so I can just copy directory and do those small changes to get it building with clang =) 2021-03-25 14:17:10 artok: that is what I think, go ahead 2021-03-25 14:17:13 RootWyrm: bits and pieces could be, but openrc is already a frankenstein init system built out of bits and pieces 2021-03-25 14:17:21 we want to build something solid 2021-03-25 14:17:26 so we do not have to do this again 2021-03-25 14:17:28 you can't cherrypick nosh and launchd I'm afraid, they're completely integrated systems :P 2021-03-25 14:17:35 that too :) 2021-03-25 14:17:49 i'm not terribly interested in implementing Mach ports in Linux either 2021-03-25 14:17:50 ;) 2021-03-25 14:18:19 pretty easy to yank relaunchd's config, launchd's supervisor. supervisor's loosely integrated, and iirc, slightly less braindead than average. 2021-03-25 14:18:30 we already have a supervisor 2021-03-25 14:18:32 it is s6 2021-03-25 14:18:53 if you want to build such a system, go for it 2021-03-25 14:19:16 personally, i rather just find a way to get skarnet some funding so we can just code the right thing and be done with this 2021-03-25 14:19:21 like, really 2021-03-25 14:19:28 we have a *domain expert* in supervision systems 2021-03-25 14:19:38 who has a very solid understanding of what we want 2021-03-25 14:19:46 and is already building it 2021-03-25 14:20:06 this story is more about, if he could work on it full time, he could bang it out in a few months 2021-03-25 14:20:13 exactly 2021-03-25 14:20:18 and thanks for the PR :D 2021-03-25 14:20:43 i could write a libc 2021-03-25 14:20:56 i mean, i fixed NPTL in uClibc 2021-03-25 14:20:58 let me just find some more of the copious free time we all have, right? 2021-03-25 14:21:07 but i guarantee you 2021-03-25 14:21:13 it would not be as good a libc as musl 2021-03-25 14:21:15 same thing here 2021-03-25 14:21:24 let the person who knows what he is doing get it done :D 2021-03-25 14:22:11 for a very limited definition of "fixed" :) 2021-03-25 14:22:27 hey it worked 2021-03-25 14:22:56 we got several years out of service out of uClibc 2021-03-25 14:23:09 don't get me wrong, thank GOD musl came along because that was going south fast 2021-03-25 14:23:26 (the things one will do to not have to deal with drepper) 2021-03-25 14:23:35 i know. i just mean it still had a *lot* of inherent bugs that needed rewrites 2021-03-25 14:23:36 s/limited/generous/ - nptl was one of the many banes of my existence. 2021-03-25 14:23:50 gitlab experts... is there now automatic thing that will keep my fork master synced to the master where project is forked from ? 2021-03-25 14:23:57 because it was forked from glibc long before glibc started fixing any of drepper's mess 2021-03-25 14:23:58 aka "okay why the hell is GC hanging now?!" 2021-03-25 14:24:27 dalias: it did not even build when alpine started looking at NPTL 2021-03-25 14:24:36 i fixed that shit 2021-03-25 14:24:39 on x86_64 2021-03-25 14:24:45 i dont reember who fixed x86 2021-03-25 14:24:48 (at least with musl i know it's because people stuck fingers into malloc() and now it's cranky and now i'm up to my eyeballs in arcade and please kill me now.) 2021-03-25 14:25:58 "unfixable" bugs in uclibc threading implementation was one of the main reasons we switched to musl, which did things correctly 2021-03-25 14:26:20 ncopa: tbh, 'unfixable' can be applied to all of uclibc most days ;P 2021-03-25 14:26:31 iirc the "unfixable" bugs basically meant rewrite the whole threading implementation to actually fix it 2021-03-25 14:26:39 so we switched libc 2021-03-25 14:26:39 RootWyrm: well hopefully we get dotnet core into alpine 3.15 2021-03-25 14:26:47 Ariadne: noooooooope. 2021-03-25 14:27:01 .15 2021-03-25 14:27:04 not .14 2021-03-25 14:27:04 :) 2021-03-25 14:27:13 or do you think we are still a year out 2021-03-25 14:27:39 rootwyrm, i'm probably missing context -- is there a problem you're hitting? 2021-03-25 14:28:13 Ariadne: okay, maaaaaaaaaaaaybe... musl malloc() changes introduced some real weirdness in GC 2021-03-25 14:29:50 dalias: haha, that list is a mile long, but i'm upstream. i just need to find time to ... well, get past item 1 on the priority list for a start. 2021-03-25 14:29:55 meanwhile.... openssl is now fixed in all supported stable branches + 3.9-stable 2021-03-25 14:30:36 dalias: RootWyrm is a .net core developer (I think) who is working with us to get .net core into alpine 2021-03-25 14:30:59 basically the mono stalls and surprise lockups are due to the musl malloc() stuff. jemalloc's fine but i have to rearch build stuff. :( 2021-03-25 14:31:02 Ariadne: yes :) 2021-03-25 14:31:35 I'm more of a mono specialist, but exactly that, and I occasionally toss up other random stuff since I've been at it.. well.. a long damn time ;) 2021-03-25 14:32:06 stalls in sense of deadlocks or unexpectedly low performance? 2021-03-25 14:33:35 dalias: stalls as in the GC internally spins in undesired ways and occasionally can lead to complete deadlock or crash on very large GC hits 2021-03-25 14:35:13 RootWyrm: that is why I think crystal test fail 2021-03-25 14:35:20 do you have minimal testcases showing what's happening? is the GC trying to do UB to GC the C heap/memory space, or just GC'ing .net object space of some sort? 2021-03-25 14:36:20 skarnet: well, half of silicon valley has now seen my thread 2021-03-25 14:36:25 soooo 2021-03-25 14:36:27 :) 2021-03-25 14:36:34 dalias: https://dev.alpinelinux.org/~mps/crystal-1.0.0-aarch64.build.log at the top. maybe can give a hint 2021-03-25 14:36:40 Ariadne: let's hope :D 2021-03-25 14:36:48 maybe not half, but some big names 2021-03-25 14:37:09 :) 2021-03-25 14:37:18 thanks for the thread, now let's see if the seed can grow 2021-03-25 14:38:03 dalias: nah, but i have repro in production. i know what's happening, i just need to find time to do a MAJOR refactor of the runtime build system itself to fix it. the issue is that GC can whack a LOT of slots at once potentially. 2021-03-25 14:38:03 link? 2021-03-25 14:42:15 skarnet: i think zededa will be interested 2021-03-25 14:42:21 Ariadne: package name clang-linux-edge or linux-edge-clang ? 2021-03-25 14:42:24 this is literally right up their alley 2021-03-25 14:42:49 artok: most likely second 2021-03-25 14:43:01 Cogitri: libvirt-glib build failed 2021-03-25 14:43:21 (but I'll let Ariadne confirm) 2021-03-25 14:43:33 afontain_: thinking also that, but just want to be sure for prefs =) 2021-03-25 14:43:34 linux-edge-clang yeah 2021-03-25 14:43:50 Ariadne: that would be awesome. 2021-03-25 14:44:12 ncopa: Yeah, but only on x86 2021-03-25 14:44:20 No clue what abuild is trying to tell me there 2021-03-25 14:49:00 afontain_: link to what 2021-03-25 14:49:21 that PR 2021-03-25 14:49:47 "half of silicon valley saw it" 2021-03-25 14:49:56 "hope the seed can grow" 2021-03-25 14:50:04 I want to see it too now! 2021-03-25 14:52:41 afontain_: https://twitter.com/ariadneconill/status/1375085251526021132 2021-03-25 14:53:42 oh, skarnet is French 2021-03-25 14:53:44 nice 2021-03-25 14:56:14 Ariadne: why build something new instead of maintaining OpenRC? 2021-03-25 14:56:19 that's the point 2021-03-25 14:56:20 fund skarnet 2021-03-25 14:56:34 (which I'd love, and would personally donate to) 2021-03-25 14:56:35 jvoisin: it doesn't do what we want long term and would have to be rewritten 2021-03-25 14:56:42 openrc is not exactly that great. it's not that *bad* but yeah 2021-03-25 14:56:57 Ariadne: fwiw I'm honestly not being gentoo-obsessive here, I'm just trying to be a point of contact if it ends up being helpful 2021-03-25 14:57:06 I like alpine's approach which is why I'm in heree 2021-03-25 14:57:10 we have gotten a lot of mileage out of openrc, but we've outgrown it 2021-03-25 14:57:27 we want to offer things like seccomp and VRFs and firewall integration that just is not possible with openrc 2021-03-25 14:58:01 (well you kind of can do those things in alpine with declarative services, but it's a giant hack) 2021-03-25 14:58:13 adding any sort of mac/rbac to openrc would be a nightmare 2021-03-25 14:58:20 having something that is well maintained is also beneficial :) 2021-03-25 14:58:29 rootwyrm, if it's just really slow because gc is doing something wacky, that's probably expected-ish and there's no real solution except "don't do something wacky" or "use a performance-oriented malloc" 2021-03-25 14:58:35 seccomp is the main thing I'm excited for 2021-03-25 14:59:00 dalias: no, it's not doing anything wacky. it's basically: "hey let's run defrag in parallel, that'll make it twice as fast, right?" 2021-03-25 14:59:02 but if it's deadlocking that's probably UB in the mono runtime stuff 2021-03-25 14:59:02 jvoisin: basically, the question is why put resources into maintaining openrc when we could put resources into building something that gives us the capabilities we actually want 2021-03-25 14:59:31 rootwyrm, yeah, don't parallelize tasks that don't make sense in parallel :) 2021-03-25 14:59:44 rust has a problem with that too... 2021-03-25 14:59:56 dalias: so you have an unavoidable inherent collision because musl is trying to defrag the GC run which is already defragging which causes boom. 2021-03-25 15:00:08 C: translation units, make -jN, operating on N independent data sets infinitely parallelizable 2021-03-25 15:00:08 rust is the only thing i've seen bring my EPYC server to it's knees 2021-03-25 15:00:17 Rust: a bunch of threads operating on the same IR 2021-03-25 15:00:47 like literally 2021-03-25 15:00:53 128 cores, 256 threads, rustc murders it 2021-03-25 15:00:55 rootwyrm, musl isn't "trying to defrag" 2021-03-25 15:00:58 i was shocked 2021-03-25 15:01:07 ariadne, yep. rust should just be invoked with only 1 thread 2021-03-25 15:01:17 but i dont know if it can compile in independent TUs like C can..? 2021-03-25 15:01:51 dalias: it is, because of the way the GC operates. it triggers mallocng's LRU and offset cycling among other things. 2021-03-25 15:01:55 Ariadne: well, people are using OpenRC. Building something else that maybe only Alpine will be using is a bit risky, isn't it? 2021-03-25 15:02:13 jvoisin: what Alpine ships as OpenRC is quite modified 2021-03-25 15:02:20 good point 2021-03-25 15:02:50 LRU isn't defrag, it's more UAF safety 2021-03-25 15:02:57 jvoisin: we can make a service manager that fits the Alpine model instead of bending OpenRC to fit our model 2021-03-25 15:03:18 (yes I'm grossly oversimplifying it, but the GC is extremely complex. i also need to tweak the triggerpoints so it fires more correctly on musl.) 2021-03-25 15:03:23 i wonder why mono gc is even trying to defrag if it's using individual mallocs tho 2021-03-25 15:03:24 jvoisin: and i think other distros will want this too 2021-03-25 15:03:33 defrag makes sense if you malloc a large block and manage it internally yourself 2021-03-25 15:03:47 but if you call malloc you should not try to defrag 2021-03-25 15:03:51 like, what we've been designing over the past few years is basically "systemd done right" 2021-03-25 15:03:53 dalias: well again, oversimplifying. how it all goes together is *extremely* complicated. 2021-03-25 15:04:07 and when it ships, lennart is going to have some actual competition 2021-03-25 15:04:08 can defrag be turned off to see if that fixes it? 2021-03-25 15:04:12 ariadne, :) 2021-03-25 15:04:20 Ariadne: having an article/blogpost to explain the situation and asking for funding would be nice :) 2021-03-25 15:04:22 dalias: https://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen/ 2021-03-25 15:05:00 significantly outdated, mind. (i.e. dtrace is on my 'to be removed' list.) 2021-03-25 15:05:09 this is kind of like how we pursue "ifupdown done right" with ifupdown-ng 2021-03-25 15:05:23 these are all pieces of a puzzle that will form together to build something that is truly great 2021-03-25 15:06:48 rootwyrm, ok, i dont understand the interaction with malloc from reading that tho 2021-03-25 15:07:30 it sounds like it has its own heaps, but i'm guessing that's just an abstraction and these are just families of malloc allocations not a separate allocator 2021-03-25 15:08:52 dalias: it's just several piles of collisions that naturally and inherently occur, which in certain scenarios can lead to boom. but that's incorrect. SGen effectively has four internal allocators. 2021-03-25 15:11:40 mps care to share your config updating process? 2021-03-25 15:12:15 dumb question: why not just have SGen use mmap/munmap to allocate and free memory 2021-03-25 15:12:58 ariadne, rust meeting is tomorrow btw right? 2021-03-25 15:13:03 yes 2021-03-25 15:13:47 sam_: much appreciated, but I don't want to take money from the community and individuals, who are generally hurting for money 2021-03-25 15:14:20 I don't have a patreon or anything for that reason - I actually fund a couple projects, and if everyone in the community does that, it's circular and accomplishes nothing 2021-03-25 15:14:27 real funding has to come from the *outside* 2021-03-25 15:15:08 the only way we can make the community thrive is to have serious funding influx from places with actual money 2021-03-25 15:15:27 corporate money that allow developers to live, and live well, from their work 2021-03-25 15:15:49 not scraps and charity that is kinda passed around among well-meaning but ultimately broke people 2021-03-25 15:15:55 Ariadne: mmap/munmap is used higher in the stack. like i said, it's extremely complicated, because remember that mono has to accommodate !linux 2021-03-25 15:16:34 so making certain changes would basically end the world. 2021-03-25 15:16:50 don't get me wrong, I love the idea of donating to projects you like, but I think the people who benefit most from it are 1. platforms such as Patreon and 2. a small minority of people working on very popular projects 2021-03-25 15:17:12 this commit sponsored by SquareSpace 2021-03-25 15:17:36 I'm sure this could happen 2021-03-25 15:19:56 tbh as long as I have control over the technical part of what goes into the commit I don't mind putting a line of corporate blurb in the log 2021-03-25 15:20:10 all it will do is annoy the people reading it 2021-03-25 15:20:18 it won't even be a good ad for the sponsor 2021-03-25 15:20:18 did I make http://openrc.run/ for nothing? 2021-03-25 15:21:24 MartijnBraam: certainly not for nothing, it looks really cool and I'd like to take a peek at the engine :D 2021-03-25 15:21:26 skarnet: ha, go look at freebsd commit histories sometime 2021-03-25 15:21:52 RootWyrm: really? FreeBSD? my my, how things have changed :D 2021-03-25 15:21:53 'Sponsored by OnlyFans' (not really but basically that, all over the place.) 2021-03-25 15:22:15 no, that goes back.. crap, probably day one honestly. 2021-03-25 15:22:15 skarnet: https://gitlab.com/MartijnBraam/openrc.run 2021-03-25 15:22:36 since it's been commonplace for companies to sponsor very specific work. 2021-03-25 15:23:04 i.e. if you grep -i juniper, probably get a couple thousand hits. 2021-03-25 15:23:44 MartijnBraam: looks like the parts that are easy to convert ;) 2021-03-25 15:23:57 skarnet: that's something I've felt for a long time 2021-03-25 15:24:21 RootWyrm: OnlyFans is probably the more ethical sponsor of the bunch :P 2021-03-25 15:27:07 artok: 'abuild deps unpack prepare' and merge diff to config-edge.* 2021-03-25 15:28:18 though I have somewhere small shell script posted to me by ncopa, but don't use it 2021-03-25 15:28:25 ncopa: that was fast! getting openssl-1.1.1k out there 2021-03-25 15:31:18 ACTION takes popcorn and watch how FOSS is dying ;P 2021-03-25 15:35:16 (but I'm reading that FOSS will die last 30 years :) ) 2021-03-25 15:36:20 dalias, Ariadne: community/zulip-term if you want to avoid the browser for the rust meeting 2021-03-25 15:40:41 browser is a lot less of a problem than installing a new app, and the webapp is actually the only non-awful webapp i've seen in like the past decade 2021-03-25 15:41:00 like it's still designed around reasonable and fast dom manipulation rather than some canvas+shadowdom+react-hell 2021-03-25 15:42:10 RootWyrm: you probably misunderstood that commit lines - FreeBSD committers add that to every commit if they do it as paid work 2021-03-25 15:42:26 decke: no, I didn't, and that's exactly what I was saying 2021-03-25 15:42:58 RootWyrm: it sounded like you meant the company wants those people to work on something - which is not entirely true 2021-03-25 15:43:13 RootWyrm: it's more like a "I am employed by: company xy" 2021-03-25 15:43:33 decke: no, it's not that. those lines go in when a company pays for specific work. 2021-03-25 15:43:44 RootWyrm: nope usually not 2021-03-25 15:43:51 otherwise all of scottl@'s commits would have windriver. 2021-03-25 15:44:57 decke: then the policy changed at some point and someone's going to have to go back and tag like, every single commit ever to mpt(4) and vmx(4) and so on. 2021-03-25 15:45:29 i think im gonna grab some popcorn and join mps watch FOSS die :D 2021-03-25 15:46:05 RootWyrm: many FreeBSD committers have paid jobs at company XY and do stuff in their free time 2021-03-25 15:46:07 well, at least til the 3.13 arm builders finished 2021-03-25 15:46:17 RootWyrm: if you look carefully you will find the difference 2021-03-25 15:46:59 RootWyrm: and there are many people that are just employed by a company and because they are allowed to work on "freebsd stuff" they just add the tags to those commits 2021-03-25 15:47:16 RootWyrm: this does not explain every commit but the majority 2021-03-25 15:48:23 RootWyrm: then there are other people working on contracts for specific topics or port some special feature so they add that companies (if that is okay) 2021-03-25 15:50:00 decke: i've been around since bsd/386 and have cut checks (and maintain ports.) policy used to be, to my knowledge, no tags unless actually sponsored. which reminds me i need to find time for vuxml and unbreaking mono but not even remotely high on the priority list. 2021-03-25 15:53:26 RootWyrm: in ports land we are nowhere near as excessively using the tag but it has become more over time as well 2021-03-25 15:53:59 RootWyrm: and especially those people that are fulltime employed add it 2021-03-25 15:54:31 mps: any idea why on abuild restart config happens? just for asking that INIT_STACK_* question? and on abuild deps unpack prepare nothing happens 2021-03-25 15:54:48 artok: found script ncopa posted https://tpaste.us/BEqY 2021-03-25 15:55:33 thanks! 2021-03-25 15:57:20 RootWyrm: and scott long is currently working for netgate - which is bad enough on it's own 2021-03-25 15:58:45 dalias: yeah, I remember you said something like that last time around, just wanted to let you know there's an option 2021-03-25 15:58:47 decke: yeah, i'd heard. 2021-03-25 16:00:06 artok: you need to copy/merged changed configs from src/build-edge.$arch/.config to these in aports 2021-03-25 16:00:58 MartijnBraam: not for nothing, even if skarnet writes a replacement tomorrow we still have several release branches on openrc 2021-03-25 16:01:08 :) 2021-03-25 16:01:09 MartijnBraam: plus the other users of openrc would likely appreciate the website too 2021-03-25 16:05:57 nah, just throw folks into the deep end with openrc, it'll be fine ;) 2021-03-25 16:08:42 mps: sure, but I did diff to those, came out zero, and still I get that question 2021-03-25 16:09:58 and your configs have already https://termbin.com/l42u 2021-03-25 16:17:50 MartijnBraam: http://openrc.run is cool! 2021-03-25 16:20:36 That's pretty neat indeed 2021-03-25 16:20:48 I created it because I was annoyed with lacking openrc docs :P 2021-03-25 16:21:01 and I'd have to map the options form systemd anyway for most software 2021-03-25 16:24:42 just run everything in systemd in systemd using docker, problem solved 2021-03-25 16:26:42 that sarcasm still hurts =D 2021-03-25 16:27:52 and yet is less painful than systemd-breakdns^Wresolved 2021-03-25 16:27:54 any comments? !17649 2021-03-25 16:34:33 mps: duh! my bad there ! 2021-03-25 16:34:41 (not a surprise) 2021-03-25 16:38:21 omni: sorry been busy with other stuff. will likely not have time today either, due to the releases with openssl fixes 2021-03-25 16:58:24 ncopa: do we want to mention the haserl cve on alpinelinux.org? 2021-03-25 16:58:37 artok: this happens when upgrading to major releases (and lot of them) but seldom on minor versions upgrade 2021-03-25 16:59:17 mps sure, and that one was GCC -> Clang difference 2021-03-25 16:59:39 artok: for major releases upgrade I usually run 'make listnewconfig' on every arch and tweak them 2021-03-25 17:00:18 it's not only ARCH that needs to be set on config and build, also CC 2021-03-25 17:00:49 in this case yes 2021-03-25 17:01:44 ikke: not sure its necessary. i dont think it affects many 2021-03-25 17:02:02 ncopa: ok, fine with me 2021-03-25 17:02:22 im preparing release notes for 3.13.3 and the other stable releases that was just pushed 2021-03-25 17:02:48 now CI's are running whee 2021-03-25 17:04:27 mps was it minimal that was interested in rpi kernel? 2021-03-25 17:05:31 artok: minimal is interested in everything ;) 2021-03-25 17:05:51 but yes, he works on rpi bootloader and kernels 2021-03-25 17:07:50 haha =) 2021-03-25 17:08:37 just wondering if that overlay splitting was somehow done 2021-03-25 17:09:40 not much, and i doubt it will be ever 2021-03-25 17:10:32 we (alpine) are in 'limbo' right now 2021-03-25 17:12:42 we lost 'clear mind' with all these changes in last two years 2021-03-25 17:16:06 artok: which overlay split? 2021-03-25 17:16:48 can someone please just review that this is ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.13.3-released.md 2021-03-25 17:16:51 mps: we honestly haven't, this has always been the trajectory. sorry if you concluded the trajectory was different. 2021-03-25 17:16:55 RootWyrm: raspberry pi needs dtc's 2021-03-25 17:17:12 we have been talking about replacing the network config for literally a decade 2021-03-25 17:17:13 done that is 2021-03-25 17:17:18 artok: yes, I'm aware.. I'm not aware of a split though, thought that had just been merged 2021-03-25 17:17:22 we have been talking about replacing openrc for 5 years 2021-03-25 17:17:41 and this https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.10.7-3.11.9-3.12.5-released.md 2021-03-25 17:17:51 ncopa: looks fine 2021-03-25 17:17:52 RootWyrm: to split dtc fiels from raspberry pi kernel and use mainline, could work 2021-03-25 17:17:54 (also i'll need to bump the rpi/rpi4 image builder) 2021-03-25 17:18:01 thanks 2021-03-25 17:18:02 both look fine 2021-03-25 17:18:45 artok: you mean split the overlays out from linux-rpi4? 2021-03-25 17:19:01 (been a few months so I'm trying to remember the structure) 2021-03-25 17:19:01 RootWyrm: yah 2021-03-25 17:19:14 Ariadne: every distro always talking about replacing networking, init etc 2021-03-25 17:19:22 now the openssl refreshing started 2021-03-25 17:19:39 mps: we ave been talking about clang for years too, starting with Shiz working on it in 2013 2021-03-25 17:20:05 artok: okay, yeah, that one is still 'tbd' afaik but i haven't had time to get back to it and deprioritized it once i had the image builder done 2021-03-25 17:21:45 good, probably some msgs are lost :) 2021-03-25 17:22:00 mps: we have been talking about clang for years too, starting with Shiz working on it in 2013 2021-03-25 17:22:25 boop 2021-03-25 17:22:51 I'm not meant about this 2021-03-25 17:22:56 mps: i mean, bluntly, you're entitled to your opinion, but the reality is that we are executing on things that have been thoughtfully considered on a timespan that on many initiatives has had discussion spread across 5+ years 2021-03-25 17:23:29 mps: i would really appreciate it if you stopped saying alpine is doomed or alpine is in limbo or whatever because we're executing on things we've talked about doing 2021-03-25 17:23:53 I mean, about 'small, simple' and 'everything in and works out-of-the-box' 2021-03-25 17:24:24 Ariadne: I think I'm free to say whatever I think 2021-03-25 17:24:43 you are, but you can phrase it in a way that isn't demoralizing 2021-03-25 17:25:26 i'm trying the best i can to get a lot of work done in alpine and i feel attacked when you do this 2021-03-25 17:25:34 i would appreciate it if you did not do this 2021-03-25 17:26:03 well, then I only allowed to appraise everything, good or bad :) 2021-03-25 17:26:57 https://github.com/Shizmob/aports/commits/system-llvm-elftoolchain/main 2021-03-25 17:27:05 you can see some of the commits when i last worked on this in 2017 :p 2021-03-25 17:27:48 Ariadne: I'd give you atleast bottle of jaloviina if you'd start bootstrap clang now =) 2021-03-25 17:27:52 Shiz: oh goshs! 2021-03-25 17:28:16 3.11.10,3.12.6,3.13.3? 2021-03-25 17:28:27 (getting ready to fire the rpi image builder) 2021-03-25 17:28:51 3.11.9,3.12.5,3.13.3 2021-03-25 17:29:00 i think 2021-03-25 17:29:14 artok: 'jaloviina', interesting word. what it means 2021-03-25 17:29:16 no bump for 11 and 12 for openssl? 2021-03-25 17:29:23 or did those already hit the repos? 2021-03-25 17:29:32 those hit the repos as part of those releases 2021-03-25 17:29:53 ah, so they already have k then, yay. 2021-03-25 17:30:17 (i mean, apk upgrade's safe on the images anyway, but still..) 2021-03-25 17:33:25 mps: even if you do not agree with these initiatives, please understand that we are all on the same team and have the same objectives and have empathy for the people doing the work. that's all i am going to say on it 2021-03-25 17:35:19 mps jaloviina is finnish alcohol drink, at war time brandy was so pricey that vodka was added to it 2021-03-25 17:36:32 ok, i'm going to have to buy some of that 2021-03-25 17:36:39 i am morbidly curious now 2021-03-25 17:36:40 :) 2021-03-25 17:37:01 https://en.wikipedia.org/wiki/Cut_brandy 2021-03-25 17:37:02 [WIKIPEDIA] Cut brandy | "Cut brandy is a liquor made of brandy, neutral grain spirit and water. Sometimes, sugar is used to soften taste. It is often colored with caramel color." 2021-03-25 17:37:25 yep, there is an international liquor store in denver 2021-03-25 17:37:31 i'll get some next time i go into the city 2021-03-25 17:38:59 as finland was again said to be happiest country in the world, there is reason =) 2021-03-25 17:39:52 https://www.reddit.com/r/europe/comments/mbe9pb/the_truth_re_finland_is_yet_again_the_happiest/ 2021-03-25 17:39:54 [REDDIT] The truth re: Finland is yet again the happiest country. Legend in comments (https://i.redd.it/9ct9ivot0so61.jpg) to r/europe | 23 points (67.0%) | 30 comments | Posted by sitruspuserrin | Created at 2021-03-23 - 13:04:36UTC 2021-03-25 17:42:50 argh.. build failed 2021-03-25 17:49:57 artok: in serbian lang 'jalovina' means exhausted. so not much as original one 2021-03-25 17:53:22 I teached (and learned) to critically look at myself (first) and to notice wrongdoing 2021-03-25 17:54:02 and even to make joke about this, world will not be over if I make mistakes 2021-03-25 17:54:37 and words/language *are not* reality 2021-03-25 17:56:20 also, I don't take anything (including my life) too seriously 2021-03-25 17:57:07 so, also alpine (though I'm trying to 'keep' it to be serious OS) 2021-03-25 17:58:16 but if I think something is not good I will say that, and that will be just my opinion 2021-03-25 17:59:08 till I elected to BDFL position, then I will/must be more careful with words ;) 2021-03-25 17:59:38 got elected, elected someone? 2021-03-25 18:00:52 afontain_: sorry, I'm self taught in english so I don't know to express my thinking properly in this lang 2021-03-25 18:01:24 I'm self taught too 2021-03-25 18:01:53 eh, you must be a better teacher then ;) 2021-03-25 18:02:18 I think "elected" means "chose" when used like that 2021-03-25 18:02:22 or "decided" 2021-03-25 18:02:59 elected as in 'election process' 2021-03-25 18:03:19 well, yes 2021-03-25 18:03:27 but who's to be elected 2021-03-25 18:03:27 not self appointed or decided by someone 2021-03-25 18:04:07 this was another joke, I wouldn't accept this position 2021-03-25 18:04:49 I regret sometimes why I accepted developer position 2021-03-25 18:07:50 the solution to the language barrier problem is that we communicate in C99 only from this point forward 2021-03-25 18:08:09 0 2021-03-25 18:08:36 not really. we have to learn sanskrit (samskrta) 2021-03-25 18:10:06 korah matah korah ratahmah 2021-03-25 18:12:11 well, you obviously aren't hipster enough, we have to learn rust 2021-03-25 18:12:12 Tauta da Dannan lang? 2021-03-25 18:13:11 Tuatha 2021-03-25 18:13:20 aha, right 2021-03-25 18:13:25 Irish Gaelic is not as dead as Sanskrit ;) 2021-03-25 18:13:27 didn't learned it 2021-03-25 18:14:12 sanskrit is not dead, it is quite live nowadays 2021-03-25 18:14:25 Latin is also not dead 2021-03-25 18:14:45 latin is poor samskrta 2021-03-25 18:15:39 old latin have 6 cases while samskrta have 9 2021-03-25 18:15:39 tehcloud: i think you mean C++14 2021-03-25 18:15:51 c++17, it has filesystem 2021-03-25 18:16:40 2021-03-25 18:17:06 303 and 927 are best yes 2021-03-25 18:19:33 artok: btw, what is your concern with the overlay splitting exactly? 2021-03-25 18:25:43 RootWyrm: my wet dream is to have small distro on rpi4 where camera, pwm, i2c work on recent kernel and has clang as main compiler and llvm libc++ 2021-03-25 18:26:12 and I just remember the talk about overlay splitting on this channel =) 2021-03-25 18:26:18 artok: oh. so you want https://github.com/rootwyrm/alpine-imager 2021-03-25 18:27:25 basically that exists _because_ of the overlay splitting and installer issues. just slap the img on the sd or emmc, and everything works. even survives major upgrades reliably. 2021-03-25 18:27:30 mps: anyway i'm sorry if i am stressing you out, too 2021-03-25 18:28:20 Ariadne: don't worry, my nerves are made of steel 2021-03-25 18:28:57 artok: libc++ would at least have proper locale code for musl :( 2021-03-25 18:29:06 I'm old samurai ;) 2021-03-25 18:29:31 i really do need to refactor the actions at some point so releases are, uh, not such a damn mess 2021-03-25 18:30:37 and as zen master sometimes think that my keisaku is not long enough :) 2021-03-25 18:31:12 when covid is over, alpine conference on finnish soil and jaloviina sponsorship? 2021-03-25 18:31:34 artok: why wait so long 2021-03-25 18:32:03 regulations 2021-03-25 18:32:17 they're just locking down two biggest cities here 2021-03-25 18:32:20 Ariadne: also sorry if I made you to feel bad 2021-03-25 18:35:40 I think I read that corona/covid is ended on Faroes Islands, maybe there they have also 'jaloviina' 2021-03-25 18:37:25 the real question is if they have karjalan pies 2021-03-25 18:41:33 well there 2021-03-25 19:00:01 gitlab seems to be quite resource hog with all those js 2021-03-25 19:05:01 yes 2021-03-25 19:05:10 gitlab is the worst kinda webapp 2021-03-25 19:05:33 no content served in actual page load, just a giant app that slowly loads all the real content over api requests 2021-03-25 19:05:54 my guess just from how bad the ux is is that it's probably using react, but it could be another one of those frameworks 2021-03-25 19:18:21 aports/main listing is one of those that you need to remember dialup days and how waiting was good =) 2021-03-25 19:19:08 at least gitlab can load all of them, GH stops at 1k :/ 2021-03-25 19:19:59 yeah 2021-03-25 19:25:00 https://git.alpinelinux.org/aports/ 2021-03-25 19:33:30 cgit <3 2021-03-25 19:34:56 oh god 2021-03-25 19:35:01 what 2021-03-25 19:35:23 (even I'm not religious) Buffer I/O error on device sdd1, logical block 44106240 2021-03-25 19:35:56 my build server dies 2021-03-25 19:37:00 artok: yes it was me that was talking about RPI dtc overlays 2021-03-25 19:37:22 minimal: you did some work on it after talk? 2021-03-25 19:39:40 artok: pressing F to pay respects 2021-03-25 19:39:41 artok: its still on my list but I got bogged down on some other stuff. To many things on the list of been trying to get some of them completely finished before tackling anything else. So only did a little bit of initial work around the time we talked and nothing further 2021-03-25 19:42:53 heh /home directory read only 2021-03-25 19:44:34 artok: the problem with the linux-edge kernel is that not all the RPI stuff is upstreamed yet and so for now the linux-rpi kernels are still needed (some of the RPI4/400 stuff isn't in Edge kernel yet) 2021-03-25 19:53:41 now then.. when was last git push of any of my projects 2021-03-25 19:53:43 =D 2021-03-25 19:57:34 oof 2021-03-25 19:57:34 Ariadne: anyways, kernel seems to work on my alpine laptop good, go ahead and start working on bootstrapping =) 2021-03-25 19:58:03 artok: well bootstrap.sh already generates a sysroot you can use with clang 2021-03-25 19:58:16 I just need to now create docker build system onto my mac 2021-03-25 19:58:23 adding clang to bootstrap itself is not too much work 2021-03-25 19:58:52 compiler-rt, libunwind, libc++ to the list 2021-03-25 19:58:59 we dont use those yet 2021-03-25 19:59:16 not even packaged :) 2021-03-25 20:00:16 I crossbuild rpi4 stuff with clang, did target sysroot with docker, copied usr and lib, built llvm monorepo and runtimes for alpine.... 2021-03-25 20:01:42 libc++ may pose some problems for codebases written in more modern C++ standards 2021-03-25 20:01:56 eh? 2021-03-25 20:02:49 pretty sure it doesn't have full C++17 or 20 support... unless I am out of date 2021-03-25 20:03:19 well... "full" is probably a bad word to use here though 2021-03-25 20:06:58 list of standards on 17 isn't as throguh on gnu as in llvm libc++ 2021-03-25 20:09:36 hard to even compare 2021-03-25 20:15:44 but still, confidence on google people and others supporting it is high =) 2021-03-25 20:16:07 ..and as apple fanboy, ofcoz my devices 2021-03-25 20:16:16 yes, it is good to see more toolchain diversity too 2021-03-25 20:17:50 heeehh motherboard seems to be broken on that build computer 2021-03-25 20:17:56 oh well 2021-03-25 20:18:35 yeah yeah, blame it on the hardware 2021-03-25 20:19:11 shall I blame software then? =) 2021-03-25 20:19:21 yes 2021-03-25 20:19:30 or the wetware 2021-03-25 20:19:40 damn abuild -r ! 2021-03-25 20:26:46 hmm, I will push crystal 1.0.0 to builders, if it fails on check() I will disable it later 2021-03-25 20:27:16 upstream developer told me that this is ok for now, he works on this problem 2021-03-25 20:27:30 any objections? 2021-03-25 20:28:33 ncopa: ^ 2021-03-25 20:30:01 it probably fine 2021-03-25 20:30:06 no objections, very good 2021-03-25 20:30:53 actually they build crystal on alpine and they disabled checks in their CIs 2021-03-25 20:32:25 errr 2021-03-25 20:32:31 that's not confidence inspiring 2021-03-25 20:32:32 :P 2021-03-25 20:33:55 agree, but don't have better idea 2021-03-25 20:34:50 now that they porting to this new hipsters machine (apple M1) I hope they will fix it soon 2021-03-25 20:35:39 though I already tested it on some of my local programs (not big though) and it works 2021-03-25 20:40:56 build.a.o gives me this 'Gah. Your tab just crashed.' 2021-03-25 20:41:12 too often 2021-03-25 20:47:06 mps: 👍 2021-03-25 20:48:46 thanks. but I had a hope that BDFL understand that we are on IRC and will not use emoticons 2021-03-25 20:54:22 +1 2021-03-25 20:55:20 i mean, sure go ahead and push it 2021-03-25 20:58:22 ncopa: np, I have fonts in my irc client which show emoticons :) 2021-03-25 20:58:34 jk 2021-03-25 20:58:55 but I think some people don't have these fonts 2021-03-25 20:59:09 inside an OpenRC init.d script is there any easy file to determine the name of the script? writing a script that could be copied with different names and want to react based on the filename (ie. like using argc/argv in shell) 2021-03-25 20:59:53 s/easy file/easy way/ 2021-03-25 20:59:53 minimal meant to say: inside an OpenRC init.d script is there any easy way to determine the name of the script? writing a script that could be copied with different names and want to react based on the filename (ie. like using argc/argv in shell) 2021-03-25 22:03:51 <[[sroracle]]> minimal: $RC_SVCNAME oslt 2021-03-25 22:45:50 sad to hear: https://roy.marples.name/archives/dhcpcd-discuss/0003457.html 2021-03-25 22:48:37 :( 2021-03-26 07:43:02 morning 2021-03-26 07:43:16 can someone help me with the mips64 builder? https://build.alpinelinux.org/buildlogs/build-edge-mips64/community/baobab/baobab-40.0-r0.log 2021-03-26 07:43:31 i'd like to tag new edge snapshot later today if possible 2021-03-26 07:43:45 but im busy with other stuff most of today 2021-03-26 07:47:32 I can, 'git rm mips64' 2021-03-26 07:47:42 and good morning 2021-03-26 07:49:04 artok: do you think that pkgdesc of linux-edge-clang should be changed to more appropriately describe pkg 2021-03-26 07:51:13 interesting notice from GKH with this morning kernel upgrade '... no need to upgrade' 2021-03-26 07:52:09 not as usual 'all users must upgrade' :) 2021-03-26 07:53:10 only 5.11.x is upgraded 2021-03-26 07:55:11 ncopa: I'm positively surprised that one young men as you (i.e. you) is so smart and (dare to say) wise at the same time 2021-03-26 07:56:45 though fact is that you make some big mistakes ;) 2021-03-26 08:53:08 PureTryOut (matrix.org): Found the issue with the new pipewire: I didn't had pipewire-media-session running, only pipewire and pipewire-pulse 2021-03-26 09:03:12 Ah yes I had that earlier as well, quite annoying that they change the config format so often 2021-03-26 09:11:17 mps: thanks, i guess? 2021-03-26 09:11:52 mps: we all do mistakes, but more important question is how we deal with them 2021-03-26 09:12:19 mps: what big mistakes are you thinking of? 2021-03-26 09:13:39 ncopa: first, 'i guess' answer: yes, I meant it as positive 2021-03-26 09:14:24 second, sure we all make mistakes but not all of deal with them calmly 2021-03-26 09:15:00 third, will not say that in public ;) 2021-03-26 09:16:25 probably a good idea. thanks :) 2021-03-26 09:17:35 keeping distro which grows in size and popularity, in a (still) sane state is not easy and requires good mind and even wisdom 2021-03-26 09:19:51 (this morning observation comes to my mind by reading current posts on debian-devel ML about FSF) 2021-03-26 09:44:20 mps: mips64 will be a lot easier once rust is available 2021-03-26 09:45:17 Ariadne: I think you don't understand my sense of humor 2021-03-26 09:45:53 mps: debian has always been a place where people argue about stuff 2021-03-26 09:46:21 and alpine starting to go this path :) 2021-03-26 09:47:51 no, alpine is not 2021-03-26 09:47:52 with my contributions to this not good move 2021-03-26 09:47:59 alpine used to be that way 2021-03-26 09:48:12 we concluded it wasn't working 2021-03-26 09:48:46 i think very few people will vote in that GR btw 2021-03-26 09:49:05 it is a public on the record vote about whether or not you want to endorse that letter 2021-03-26 09:49:14 if people wanted to, they would just sign it 2021-03-26 09:49:18 well, some already left debian because of this 2021-03-26 09:49:26 people leave debian all the time 2021-03-26 09:50:04 I say 'because of this' 2021-03-26 09:51:12 and by this those who planned this attack on FOSS got first results 2021-03-26 09:52:03 i do not consider that letter an 'attack on FOSS', that seems pretty loaded language :) 2021-03-26 09:52:15 anyway, let us drop this 2021-03-26 09:52:28 I have to rephrase 'Hanlons Razor': don't ascribe to incompetence which can be malice 2021-03-26 09:52:45 i ascribe the letter to frustration 2021-03-26 09:52:57 but, let us drop this conversation :) 2021-03-26 09:53:08 agree fully :) 2021-03-26 09:54:00 with small note (sorry), I will always say what I think 2021-03-26 09:56:34 sure 2021-03-26 09:56:55 i just don't want to argue about this here 2021-03-26 09:57:00 we can talk about it on -offtopci 2021-03-26 10:22:13 ncopa: it's ok, I didn't know it was on you alone to evaluate 2021-03-26 10:22:44 I'm fine myself, since I already use my patch, and there may not be many who boot xen with syslinux and want microcodes 2021-03-26 10:37:12 [04:15:37] edge/testing/mips64: uploaded 2021-03-26 10:38:55 fixing chromium 2021-03-26 10:47:08 speaking of chromium, how do you enable for wayland? 2021-03-26 10:47:30 something something ozone, I read... 2021-03-26 10:47:51 dunno 2021-03-26 10:47:55 i dont really use chromium 2021-03-26 10:47:59 its blocking the builders tho 2021-03-26 10:50:43 me neither, but I wanted to try yesterday 2021-03-26 10:51:03 is armv7 CI having some networking issues? 2021-03-26 10:53:06 at build "failed to fetch `https://github.com/rust-lang/crates.io-index` " 2021-03-26 10:54:07 it's the DRM code 2021-03-26 10:54:09 hooray 2021-03-26 10:54:11 also fuck DRM 2021-03-26 11:08:19 yes 2021-03-26 13:45:10 Marian[m]: Thanks a lot for the tip with mspdebug, works like a charm with tilib now :) 2021-03-26 13:46:02 You're welcome :-) 2021-03-26 14:01:50 dalias: meeting starting 2021-03-26 14:05:23 ericonr: ^ 2021-03-26 14:24:10 uhg sorry late 2021-03-26 14:25:16 no, they're early 2021-03-26 14:25:29 was supposed to be in 35mn 2021-03-26 14:25:31 and now ff is ooming lovely 2021-03-26 14:25:37 oh? 2021-03-26 14:25:45 why dst change? 2021-03-26 14:28:08 no looks like it's already in progress 2021-03-26 14:28:24 ah, if we're in the cursed period of time where DST is different in US and in Europe, that may explain 2021-03-26 14:28:34 We are 2021-03-26 14:28:49 i'm on now 2021-03-26 14:28:59 US switched 2 weeks ago 2021-03-26 14:29:00 ariadne, anything important i need to chime in on? 2021-03-26 14:29:25 dalias: no, just read through it 2021-03-26 14:29:42 i think they managed to convince themselves that what they were doing was broken 2021-03-26 14:29:53 "musl embedded inside libc crate" scared them a lot 2021-03-26 14:30:19 maybe give some feedback affirming it all though :) 2021-03-26 14:32:32 lol wtf is that? 2021-03-26 14:32:37 hahahaha :) 2021-03-26 14:32:56 dalias: so libc crate links staticly against libc.a unconditionally, we have to patch it in alpine 2021-03-26 14:38:30 uhg 2021-03-26 14:39:31 i wonder if we could catch that with a diagnostic 2021-03-26 14:40:04 in dynamic linker, if libc.so is in the dso chain but main program does not have a dynamic reference to __libc_start_main, that would mean libc was also static linked 2021-03-26 14:40:09 and that's a hard error -- don't run 2021-03-26 14:40:52 Ariadne: ugh I was counting on it being 20 minutes from now >,M 2021-03-26 14:43:15 ericonr: if it helps, there is legislation in Congress to abolish DST and if it passes, DST will probably be abolished by everyone on this continent 2021-03-26 14:45:07 :) 2021-03-26 14:45:55 well, brazil stopped doing it for now, but it's also president from hell rn 2021-03-26 14:46:11 I would appreciate it if the meeting was kept at UTC times lol 2021-03-26 14:46:31 international meetings should always been given in UTC time >.> 2021-03-26 14:46:32 will schedule a meeting to open an rfc to change their meeting scheduling arrangements 2021-03-26 14:46:52 and you'll be late to this meeting as well 2021-03-26 14:47:00 because of DST 2021-03-26 14:47:21 damnit! 2021-03-26 14:51:11 these guys are being stupid again, sigh 2021-03-26 14:52:23 CoC? 2021-03-26 14:53:37 mps: which CoC do you think that statement applies to? 2021-03-26 14:54:40 doesn't we have one? 2021-03-26 14:57:22 yes, i wrote it 2021-03-26 14:58:46 now you can delete it :) 2021-03-26 15:06:12 well what i said does not violate it, because it's basically "don't be a dick" 2021-03-26 15:06:49 complaining about an unspecified group is not a CoC violation :p 2021-03-26 15:07:27 :D 2021-03-26 15:08:03 good to know, so now I can use these terms freely ;) 2021-03-26 15:20:31 just learned that all crystal binary releases are built on alpine 2021-03-26 15:20:50 and statically linked with musl 2021-03-26 15:21:01 so is .NET (but do not gaze into the build.) 2021-03-26 15:21:25 :) 2021-03-26 15:21:32 be assured I will not 2021-03-26 15:22:06 ariadne, do you have any ideas for how to observe the libc.a embedding thing with stock rust on a non-musl-based/unpatched host? 2021-03-26 15:32:06 dalias: this is moe of a Cogitri thing imo 2021-03-26 15:32:33 ok 2021-03-26 15:32:39 if cogitri can do it even better 2021-03-26 15:38:35 i still say if alpine worked like rust we would never get anything done 2021-03-26 15:38:48 because we would be scheduling meetings to schedule meetings to discuss the things we want to do 2021-03-26 15:38:50 :D 2021-03-26 15:45:36 scheduling meetings to schedule meetings to schedule meetings to discuss meeting scheduling is the best way to move fast and break stuff as per google 2021-03-26 15:47:12 mps sure, I was selfish and pushed that mr just to get build artifacts, but it failed and as I said yesterday, my dev env died.. I'll be doing things later this evening =) 2021-03-26 15:47:27 ... if I get some decent abuild up 2021-03-26 16:13:32 if you need a machine to use, i can give you a VM on something 2021-03-26 16:21:12 dalias: You mean how to install stock rust and build a program with it? 2021-03-26 16:21:25 artok: ok 2021-03-26 16:33:42 mps: so answer is, thanks, noted =) 2021-03-26 16:35:27 cogitri, i thought ariadne was suggesting asking you to check what happens :-p 2021-03-26 16:35:57 no i was suggesting he probably knows more about the rationale behind the rust patches 2021-03-26 16:36:28 ah 2021-03-26 16:40:42 Ah sure, glad to help if I can 2021-03-26 16:54:20 i'm not actually trying to understand the patch 2021-03-26 16:54:38 i'm trying to understand what happens when you link with the embedded libc package 2021-03-26 16:55:55 dalias: so what happens without the patch but dynamic linking is requested for musl? 2021-03-26 16:57:27 even with static linking 2021-03-26 16:57:31 what i would expect to see is 2021-03-26 16:57:57 ld rustprogram.o path/to/libc.a [various library stuff] -lc 2021-03-26 16:58:04 and that is horribly broken 2021-03-26 16:58:21 the [various library stuff] would pull from the system libc while the main program would pull from the bundled libc.a 2021-03-26 16:59:23 that sounds uuuh nice 2021-03-26 16:59:28 yeah 2021-03-26 16:59:46 i'm pretty sure whoever made this did not understand what they were doing at all 2021-03-26 16:59:52 well 2021-03-26 17:00:19 there is no situation in which putting an explicit libc.a on the ld command line is the right thing to do, only situations in which it happens not to break :) 2021-03-26 17:00:21 they decided to hardcode system headers for systems with famously unstable ABI (openbsd) 2021-03-26 17:00:26 so kinda, yes 2021-03-26 17:00:58 if you want to link to a different libc you need the -L path to put the different one first for the whole link 2021-03-26 17:04:57 can you think of a PoC for C? 2021-03-26 17:05:11 like, of a situation where this clearly breaks something 2021-03-26 17:05:29 that would make it easier to figure out a poc in Rust, maybe 2021-03-26 17:09:07 well to get the active breakage with static linking you need a version schism where there's some incompatible change in internal interface surfaces 2021-03-26 17:09:25 however i dont see the point in making concrete examples unless someone is hostile to fixing it 2021-03-26 17:09:47 as soon as you see the pattern "ld foo.o some/other/libc.a bar.o -lc", you have a bug 2021-03-26 17:09:55 it's just a bomb waiting to be triggered 2021-03-26 17:10:22 so just seeing how the linker is invoked is enough to know if it's broken 2021-03-26 17:10:25 got it 2021-03-26 17:11:34 if you want concrete examples, anything with changes to implementation internals, like oldmalloc->mallocng, global thread list lock, etc. could provide a pair of versions that break when mixed 2021-03-26 17:12:22 stdio also makes a great hypothetical one but we don't have any recent changes there that would break it 2021-03-26 17:12:30 (any change in layout of FILE structure would, tho) 2021-03-26 17:12:40 that makes sense, yeah 2021-03-26 17:13:05 https://bsd.ac/r6ort9f is the ld command 2021-03-26 17:13:40 hmm, where is the libc at all? 2021-03-26 17:13:52 not sure, trying to understand it 2021-03-26 17:15:04 /home/ericonr/mypro/rust-time64/target/debug/deps/liblibc-b9cb6b4cf6c028f5.rlib ? 2021-03-26 17:15:19 that sounds... problematic.. 2021-03-26 17:15:39 oooh, that might be 2021-03-26 17:15:53 and there's another 2021-03-26 17:15:56 there was something about them bundling libc.a inside something 2021-03-26 17:16:04 home/ericonr/.rustup/toolchains/nightly-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-a6df7fa84d406b53.rlib 2021-03-26 17:16:23 one from the toolchain, one from the embedded libc dep 2021-03-26 17:16:34 tons of stuff in between 2021-03-26 17:16:38 the toolchain one is probably the more complicated one 2021-03-26 17:16:39 so pretty close to what i expected 2021-03-26 17:17:08 I think the embedded libc one is from `libc = "0.2.86"` in Cargo.toml 2021-03-26 17:17:20 I don't think it contains a libc.a copy 2021-03-26 17:17:30 but I could be wrong 2021-03-26 17:18:49 indeed 2021-03-26 17:19:31 dalias: https://bsd.ac/sywg24e 2021-03-26 17:20:59 uhg that pastebin mangles charset :-p 2021-03-26 17:21:12 I think it fails to specify utf8 :D 2021-03-26 17:21:15 yeah 2021-03-26 17:21:36 because of legacy bogus browser behavior you have to always put "; charset=utf-8" on text/plain 2021-03-26 17:28:04 oooh 2021-03-26 17:28:09 got it to break, I think 2021-03-26 17:28:42 yeah? 2021-03-26 17:29:02 I got it to spit out -lc 2021-03-26 17:30:53 dalias: https://bsd.ac/fs0x4tm 2021-03-26 17:31:27 for some reason it seems to have copied the liblibc file to /tmp ?? but it has the same identifying digest as the one under .rustup/toolchains/nightly-x86_64-unknown-linux-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-a6df7fa84d406b53.rlib 2021-03-26 17:31:54 why did it do that? 2021-03-26 17:32:31 also this looks like dynamic linking 2021-03-26 17:32:56 yes, I used RUSTFLAGS=-Ctarget-feature=-crt-static 2021-03-26 17:33:16 ok well we already know any inclusion of another libc is broken in that case 2021-03-26 17:33:40 which it seems to do, unless the step of copying liblibc to /tmp also strips out the libc.a part? 2021-03-26 17:35:01 ok so stuff is even more broken than we knew.. 2021-03-26 17:38:15 ok, I asked in zulip why this happens 2021-03-26 17:38:23 the /tmp part 2021-03-26 17:38:40 if it removes libc.a from liblibc.rlib, I think that would make the -lc in the command line safe, wouldn't it? 2021-03-26 17:41:06 dalias: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Why.20does.20rustc.20link.20against.20liblibc.20from.20.2Ftmp.3F 2021-03-26 17:47:05 yes. -lc should be there. the problem is linking their own second libc 2021-03-26 17:51:01 http://ix.io/2Ubu :) 2021-03-26 17:51:53 hmm i think the first condition can be removed 2021-03-26 17:52:23 yeah 2021-03-26 17:54:26 hmm i think it's incomplete tho 2021-03-26 17:57:44 dalias: from zulip, it would seem we only get one libc, because the liblibc.rlib from /tmp had libc.a removed from it 2021-03-26 17:58:10 hmm 2021-03-26 18:35:14 skarnet: i reached out to some friends of mine at the linux foundation about funding your work, they're going to look for budget 2021-03-26 18:36:04 skarnet: how much money do you need? 2021-03-26 18:38:39 does anybody want to get paid to rewrite busybox 2021-03-26 18:39:07 isn't landley doing that already :P 2021-03-26 18:39:20 without httpd and others, tho 2021-03-26 18:39:23 (in rust) 2021-03-26 18:39:26 ooh 2021-03-26 18:40:51 I'd have work on proper platform feature detection, which would allow for sane time64 support, before committing to base system developed in rust :p 2021-03-26 18:41:15 Ariadne: thanks :) (and why tf would you want to rewrite bb in rust?...) 2021-03-26 18:41:30 well itdoes not have to be rust 2021-03-26 18:41:40 well 2021-03-26 18:41:43 ericonr: linux foundation is... somewhat allergic to landley 2021-03-26 18:41:49 knowing how to deal with OOM would be nice too 2021-03-26 18:41:56 something about busybox litigation 2021-03-26 18:41:56 since it's panic town in that part 2021-03-26 18:42:26 jvoisin: an engineer's salary for several months, let's say a year, so more than an individual or a group of broke individuals can fund, which is why it probably has to be corporate-backed 2021-03-26 18:42:32 I want a job, not charity 2021-03-26 18:43:40 Ariadne: what interest does the LF have in busybox? aren't they happy with GNU coreutils and util-linux? 2021-03-26 18:44:53 skarnet: they aren't happy because Alpine isn't happy, and they want Alpine to be happy since Alpine is what they are pushing for container devops buzzword bingo 2021-03-26 18:45:48 basically they are very open to finding budget for improving Alpine 2021-03-26 18:45:57 busybox is, you know, a third rail issue 2021-03-26 18:46:03 with the GPL violations project 2021-03-26 18:46:16 so they would like to see it replaced 2021-03-26 18:47:01 can you write my name down on that form too, knowing that the other thing will take priority if it happens? :P 2021-03-26 18:47:46 huh, bad news if LF wants to help us 2021-03-26 18:47:54 because a coreutils replacement is definitely on the list of the things I think would be useful and would write if funded :P 2021-03-26 18:48:39 mps: great news if LF wants to give us money 2021-03-26 18:48:47 great news for my fucking bank account 2021-03-26 18:48:48 I think someone created MR with coreutils written in rust 2021-03-26 18:48:56 skarnet: what is broken with current coreutils? 2021-03-26 18:49:08 I don't like money 2021-03-26 18:49:11 great news if any organization that has money wants to push money to the community 2021-03-26 18:49:12 isnt' landley doing toybox now? 2021-03-26 18:49:14 mps: i like being able to eat 2021-03-26 18:49:22 and I don't need them 2021-03-26 18:49:23 harp on GNU all you want, all their tools are translated to hell and back, which I like a lot 2021-03-26 18:49:24 he's basically as far away from busybox as it gets 2021-03-26 18:49:52 ericonr: I don't think coreutils is broken, but I think there's room for another, lighter suite 2021-03-26 18:50:10 I can earn my money independently from my 'free' work 2021-03-26 18:50:18 good for you 2021-03-26 18:50:20 ACTION sighs 2021-03-26 18:50:57 Eighth_Doctor: toybox is kinda focusing on Android atm 2021-03-26 18:51:13 toybox is really buggy 2021-03-26 18:51:22 yes, but if landley's terribleness is a problem, then avoid toybox, not busybox 2021-03-26 18:51:32 dude hasn't been involved in busybox in almost 10 years, afaik 2021-03-26 18:51:38 Eighth_Doctor: busybox is scary to companies because of the GPL violation lawsuits 2021-03-26 18:51:53 wait, so people are frightened about teeth? 2021-03-26 18:52:01 seems so 2021-03-26 18:52:04 so they do want to violate the GPL ? 2021-03-26 18:52:04 Ariadne: ask the https://nlnet.nl/ 2021-03-26 18:52:07 fuck that 2021-03-26 18:52:09 bb has a lot of problems and landley isn't one of them 2021-03-26 18:52:10 they're throwing money at lot of things 2021-03-26 18:52:32 skarnet: that's fair, but then you'd have to focus on minimal code and compliance, because trying to optimize for speed, like say, by using copy_file_range, you end up also having to implement all the workarounds and domain knowledge for kernel bugs 2021-03-26 18:52:36 if the long-term goal is to be asshats to the community, fuck that 2021-03-26 18:52:39 Eighth_Doctor: busybox is more scary because of the bad code 2021-03-26 18:52:45 (which is what GNU coreutils already do) 2021-03-26 18:52:47 well, that I can get behind 2021-03-26 18:52:54 I use coreutils-single for my stuff because of that 2021-03-26 18:53:02 if you do talk to NLnet, let me know, i will glad to help with some examples. 2021-03-26 18:53:04 that said, they have made a lot of bad decisions, like tar taking remote paths in : 2021-03-26 18:53:09 Eighth_Doctor: yeah i want something lighter than coreutils-single (which we already have as option) 2021-03-26 18:53:11 ericonr: minimal code and compliance are *exactly* what I want to focus on 2021-03-26 18:53:22 Ariadne: please no rust 2021-03-26 18:53:27 I've had my fill of that this week 2021-03-26 18:53:31 and busybox is the unholy trinity of bad code, politics, and liability issues 2021-03-26 18:53:34 ACTION hates firefox builds 2021-03-26 18:53:58 I've had enough rust for a year with today's 40 minutes of meeting :P 2021-03-26 18:54:00 ACTION innocently brings up libtool 2021-03-26 18:54:06 ugh 2021-03-26 18:54:10 NOPE 2021-03-26 18:54:10 that one is easy, slibtool? 2021-03-26 18:54:13 ACTION nope.jpg 2021-03-26 18:54:20 well, pulseaudio still uses libtdl 2021-03-26 18:54:24 I am seeing a lot of slibtool related work going on 2021-03-26 18:54:31 anyway my point is, it turns out finding budget for things in alpine is pretty easy 2021-03-26 18:54:31 idk if you need libtool to integrate libtdl into things 2021-03-26 18:54:32 pipewire is a thing :) 2021-03-26 18:54:33 ACTION nope.gif nope.mkv nope.com nope.py nope.c 2021-03-26 18:54:54 Ariadne: show me the contracts and I'll do the work 2021-03-26 18:54:56 Eighth_Doctor: very very linux specific, tho :/ 2021-03-26 18:55:07 ericonr: it's not intended to be, afaik 2021-03-26 18:55:11 it is 2021-03-26 18:55:11 mostly by accident it is 2021-03-26 18:55:19 they use memfd's all around 2021-03-26 18:55:27 Ariadne: NLnet might be a slightly harder sell, but if it goes that route, LMK and I can help now that docker's stopped eating dnssec 2021-03-26 18:55:36 also, Alpine is Linux based, so... 2021-03-26 18:55:43 well yeah, for linux it's great 2021-03-26 18:55:56 other OSes don't have equivalents to memfds? 2021-03-26 18:55:59 Eighth_Doctor: by accident or on purpose doesn't change the result. 2021-03-26 18:56:02 that seems weird for zero-copy stuff 2021-03-26 18:56:35 skarnet: i should have some insight next week 2021-03-26 18:57:16 Eighth_Doctor: afaik no 2021-03-26 18:58:01 openbsd doesn't even support pshared semaphores, for that matter 2021-03-26 18:58:11 skarnet: so, 40k EUR ? 2021-03-26 18:58:25 ericonr: freebsd has shm_anon for this 2021-03-26 18:58:37 I know that is the approach being used for wayland porting 2021-03-26 18:59:17 > Finally, following the trend of multiple influential system daemons created in the last decade, PipeWire makes extensive use of Linux-kernel-only APIs. This includes memfd, eventfd, timerfd, signalfd, epoll, and dma-buf 2021-03-26 18:59:20 from https://lwn.net/Articles/847412/ 2021-03-26 18:59:32 alpine also wants to target other kernels than linux eventually 2021-03-26 18:59:56 what's the goal with that? 2021-03-26 19:00:05 ericonr: this feels like a thing where other OSes should improve 2021-03-26 19:00:21 well one would hope to not be chained to whatever IBM decides to dictate this week 2021-03-26 19:00:39 if non-linux kernels don't have equivalents, then that should be fixed in those kernels 2021-03-26 19:00:46 it's not like those things are there for no reason 2021-03-26 19:00:49 jvoisin: that's 4 months full-time, or 5 months with 4-week days, it would be at least a very solid start :) 2021-03-26 19:01:10 Eighth_Doctor: most of them are there for no reason other than to make things linux-specific for no valid technical reason. 2021-03-26 19:01:50 I wouldn't say there is no valid technical reason 2021-03-26 19:01:53 alright, I'm nope'ing out of this conversation 2021-03-26 19:02:07 even loops with signalfd are pretty nice 2021-03-26 19:02:11 event 2021-03-26 19:03:04 Eighth_Doctor: it's just unfortunate that pipewire does things in an incompatible way. they have taken advantage of that to provide a great result, tho, from what I have heard 2021-03-26 19:03:06 RootWyrm: i think all of those apis are actually pretty nice 2021-03-26 19:03:10 so I can't really fault them :) 2021-03-26 19:03:50 having had been in the "room" for some of those design conversations, I have some idea of the choices, and I'm pretty happy with the results so far 2021-03-26 19:03:51 RootWyrm: they allow us to wait on kernel resources like you can do in VMS (sys$dispatch()) or in Windows (e.g. WaitForMultipleObjects()) 2021-03-26 19:04:07 Ariadne: except epoll is a bad clone of kqueue 2021-03-26 19:04:16 epoll is misunderstood 2021-03-26 19:04:25 kqueue is actually the bad API, imo 2021-03-26 19:04:25 epoll doesn't serve the same purpose as kqueue 2021-03-26 19:04:28 epoll is great 2021-03-26 19:04:32 just as an example off the top of my head 2021-03-26 19:04:37 epoll is literally WaitForMultipleObjects() 2021-03-26 19:04:41 which is what i want 2021-03-26 19:05:14 epoll does what it says on the tin, which is I think why people are disappointed in it :) 2021-03-26 19:05:24 posix APIs typically don't do what they say they'll do :P 2021-03-26 19:05:36 https://github.com/mono/mono/blob/79b6e3f256a59ede74596ce82547f320bf1e9a99/mono/metadata/threadpool-io-kqueue.c 2021-03-26 19:05:42 with kqueue, it "looks" powerful, but in reality, you are limited to whatever is supported by kqueue (EVFILT_XXX) 2021-03-26 19:05:46 it's all a distraction 2021-03-26 19:05:50 there is a threadpool-io-epoll 2021-03-26 19:06:09 yes, threadpools can be done with it, but it's not great 2021-03-26 19:06:29 first, ideally, a media daemon would need RT priority, and pipewire does not 2021-03-26 19:06:39 skarnet: it can request it 2021-03-26 19:06:55 it does not require it, but it can become RT priority as needed 2021-03-26 19:07:02 what i would like to see is futexes as file descriptors 2021-03-26 19:07:08 so you can epoll on a futex 2021-03-26 19:07:12 and use a futex as a condvar 2021-03-26 19:07:17 Ariadne: isn't that eventfd, kinda? 2021-03-26 19:07:18 then, excepted RT prio, you can do everything a media daemon needs with fkn select() 2021-03-26 19:07:24 epoll() and friends are distractions 2021-03-26 19:07:29 ericonr: yes, you can do it with eventfd 2021-03-26 19:07:33 they're only useful when you're trying to solve the c10k problem 2021-03-26 19:07:37 Eighth_Doctor: alpine doesn't ship rtkit, does it? 2021-03-26 19:07:38 which a media daemon is not 2021-03-26 19:07:53 ericonr: not sure, I'm not exactly a "deep" Alpine user 2021-03-26 19:08:02 they use the sched_setpriority() functions instead of syscalls, so they don't work on musl 2021-03-26 19:08:21 alpine does ship rtkit 2021-03-26 19:08:28 and epoll() and friends are just another instance of the shiny things everyone talks about but that make zero difference in practice and takes attention away from the real important design points 2021-03-26 19:08:42 Ariadne: how do I find it in https://pkgs.alpinelinux.org/packages?name=rtkit&branch=edge ? 2021-03-26 19:08:57 its inside pipewire 2021-03-26 19:09:15 but pulseaudio can use it as well ... 2021-03-26 19:09:41 if epoll made zero difference in practice, i would have a _lot_ less headaches 2021-03-26 19:10:21 Ariadne: do you mean /usr/lib/pipewire-0.3/libpipewire-module-rtkit.so ? 2021-03-26 19:10:32 ericonr: yeah, i guess that is not rtkit :P 2021-03-26 19:10:40 heh 2021-03-26 19:10:54 the polkit powered daemon kinda sucks 2021-03-26 19:11:01 but it can give your audio daemons RT priority :D 2021-03-26 19:11:04 RootWyrm: most likely you are using edge-triggered event notifications when they need to be level-triggered notifications 2021-03-26 19:11:13 Ariadne: nope 2021-03-26 19:11:37 needs to be patched to use syscalls on musl, tho, because linux sucks in treating processes as a group of threads 2021-03-26 19:11:52 well, that's by design 2021-03-26 19:11:58 threads are just processes to linux 2021-03-26 19:12:06 and patching to use syscalls is the wrong approach 2021-03-26 19:12:27 the sched_setpriority function is specified to set priorities for the whole process 2021-03-26 19:12:29 the abstraction needs to be supported above musl if musl can't do it 2021-03-26 19:12:54 RootWyrm: well, i'd love to look at whatever issues mono has (though i dream of a day where mono is gone in favor of dotnet-core) 2021-03-26 19:13:08 well, one day that'll happen 2021-03-26 19:13:14 mono and dotnet are merging over time 2021-03-26 19:13:22 eventually mono will just be dotnet+linuxy things 2021-03-26 19:13:30 Ariadne: these same issues exist in core, and a *lot* of other things. 2021-03-26 19:13:33 Eighth_Doctor: and that's bad design. some newer syscalls affect the entirety of the process, because they realized that only changing the identity inside a single thread is useless 2021-03-26 19:13:44 s/identity/credentials/ 2021-03-26 19:13:44 ericonr meant to say: Eighth_Doctor: and that's bad design. some newer syscalls affect the entirety of the process, because they realized that only changing the credentials inside a single thread is useless 2021-03-26 19:13:59 ACTION shrugs 2021-03-26 19:14:03 Eighth_Doctor: uh, no. mono and dotnet are not 'merging.' mono is part of runtime, runtime is not dotnet, etc. 2021-03-26 19:14:17 the fact that synccall as a mechanism is necessary at all is so wrong to me :P 2021-03-26 19:14:48 RootWyrm: I just repeat what BitIntegrity tells me :D 2021-03-26 19:14:52 RootWyrm: well doing deep dives into shit like this is what i love to do 2021-03-26 19:15:08 so if you ever wanna debug it lmk 2021-03-26 19:15:43 i have a lot of experience with epoll and weird contention issues and so on :P 2021-03-26 19:15:45 Ariadne: tbh, I wouldn't inflict many of these nightmares on anyone I liked. Just because of the build system half the time. 2021-03-26 19:15:58 ericonr, yes, tell the kernel folks to fix it... 2021-03-26 19:16:26 But, no, epoll is necessary in a ton of places for things like async, thread control, global state, etc. 2021-03-26 19:16:53 re: programs using the broken sched_* stuff... 2021-03-26 19:17:03 (meanwhile, elsewhere: "async? Uh. Yeah. Just set it async.") 2021-03-26 19:17:15 you could just make a -lbrokensched library to link them with 2021-03-26 19:17:36 RootWyrm: it would be nice for linux to have completion ports 2021-03-26 19:17:56 you can kinda do that with epoll + eventfd, but it's a bit hairy yes 2021-03-26 19:18:17 the problem here is that posix specified these functions to do something utterly wrong and useless and linux implemented to do them something that's also wrong but differently so :-p 2021-03-26 19:18:38 Ariadne: it would be nicer if Red Hat^W^WIBM didn't dictate everything and deliberately introduce incompatibilities 2021-03-26 19:19:33 ACTION twitches 2021-03-26 19:19:48 ol 2021-03-26 19:19:49 i'm not sure what you mean 2021-03-26 19:20:00 dalias: why would you say the functions are useless/wrong? 2021-03-26 19:21:21 because they're specified to change scheduling properties for the process not for a thread or for all threads in the process, and the way the scheduling properties for the process are defined, they either involve hierarchical contention domains (optional, not implemented anywhere) or they're _specified to be_ no-ops 2021-03-26 19:21:45 and that's not what anyone actually wants 2021-03-26 19:24:35 Ariadne: many portions of linux have never been 'open source' except in that 'sure we'll steal your code.' he who controls the spice, controls the universe. and that's red hat and occasionally their customers. if red hat wants it, no amount of objections will stop it. if red hat decides they don't like it, it will never get in. 2021-03-26 19:25:04 that's a situation that can and will change 2021-03-26 19:26:06 RootWyrm: that's largely changing these days 2021-03-26 19:26:21 Ariadne: only in that now it's IBM instead of red hat. 2021-03-26 19:26:37 I can tell you as someone who works for an "enterprise client" that the changes at Red Hat are unwelcome, and I am sure there are other enterprise clients who feel the same 2021-03-26 19:26:38 except you can come play in our sandbox instead 2021-03-26 19:26:46 the IBM purchase will inevitably kill them 2021-03-26 19:26:47 i agree with you that red hat controls GNU 2021-03-26 19:26:59 but here we are, making a linux OS that is not GNU 2021-03-26 19:27:10 the kernel is not really dominated by redhat anymore 2021-03-26 19:27:25 hell Microsoft is in the top 10 committers to linux (kernel) these days 2021-03-26 19:27:47 ACTION looks at directx over /dev for wsl2 machines 2021-03-26 19:27:58 haha 2021-03-26 19:28:00 dalias: hm, I think I get it 2021-03-26 19:28:04 tehcloud: ohhohohohohoho I see you have not worked with IBM before 2021-03-26 19:28:09 I don't think I like that option very much, ericonr 2021-03-26 19:28:34 I'm reasonably sure they deployed that 2021-03-26 19:28:36 hang on 2021-03-26 19:28:37 ericonr: just don't use sharp sticks. 2021-03-26 19:29:11 here https://lists.freedesktop.org/archives/dri-devel/2020-May/266629.html 2021-03-26 19:29:25 there was also some lkml stuff, but idk where it is 2021-03-26 19:30:25 well, it's worse than dx on linux, it's fake dx on linux requiring windows 2021-03-26 19:30:36 I did say it was for wsl2 ;) 2021-03-26 19:30:39 and yes, it sucks 2021-03-26 19:30:50 i want real directx on linux 2021-03-26 19:31:01 ACTION nods 2021-03-26 19:31:07 it's like the nvidia xwayland PR, which you can't even test because the drivers that work with it aren't available 2021-03-26 19:31:08 no seriously OpenGL sucks 2021-03-26 19:31:25 Ariadne: I'm a gamedev, I *fully* agree 2021-03-26 19:31:34 OpenGL can burn in hell 2021-03-26 19:31:35 isn't OpenGL 4.x good? 2021-03-26 19:31:43 no 2021-03-26 19:31:47 ericonr: it is very aggressively ok 2021-03-26 19:31:50 just because people used a sledgehammer to fit a square peg into a round hole, doesn't make the square peg bad. 2021-03-26 19:32:16 ... 2021-03-26 19:32:24 I have no idea about graphics APIs, anyway 2021-03-26 19:32:32 ericonr: you don't want to 2021-03-26 19:32:35 it's all about writing shaders now 2021-03-26 19:32:36 trust me on that 2021-03-26 19:32:39 if you wanna learn 2021-03-26 19:32:41 for the nvidia thing, https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587 2021-03-26 19:32:42 apk add bonzomatic 2021-03-26 19:32:45 it's a hellscape 2021-03-26 19:32:45 have fun 2021-03-26 19:32:59 opengl 4.x is ridiculously good at certain things. however, one also must consider that the only two remaining graphics manufacturers went on a many years long campaign to eradicate opengl. 2021-03-26 19:33:04 Ariadne: What's the reason you added rust to bootstrap? 2021-03-26 19:33:08 Ariadne: ooh, pretty 2021-03-26 19:33:19 there's an app for that on android 2021-03-26 19:33:29 creatively named Shader Editor 2021-03-26 19:33:31 it's pretty fun 2021-03-26 19:33:47 no touching actual opengl, just GLSL (I think?) 2021-03-26 19:33:52 so opengl4.x on a card designed for opengl doing tasks opengl was designed for will blow the doors off everything. period. trying to do opengl on platforms that have gone to great lengths to destroy it, yeaaaaaaaah. 2021-03-26 19:34:22 ACTION levels a dead stare at RootWyrm  2021-03-26 19:34:24 ACTION hides the 3DLabs swag back under the desk 2021-03-26 19:34:31 can this discussion go somewhere else 2021-03-26 19:34:32 Ariadne: Why did you add community/rust to bootstrap.sh? 2021-03-26 19:34:57 Ariadne: We're trying to figure out if we need it, but haven't found any dependencies on it that we care about 2021-03-26 19:35:01 Thermi: you can just skip it 2021-03-26 19:35:17 Thermi: i'm planning to improve bootstrap.sh to build "just the stuff you need for a toolchain" 2021-03-26 19:35:24 Ariadne: ty 2021-03-26 19:35:35 Thermi: rust is in there because it has to be crosscompiled to bootstrap with 2021-03-26 19:35:52 Ariadne: ? 2021-03-26 19:35:55 ?! 2021-03-26 19:35:56 Nani?! 2021-03-26 19:36:06 Thermi: you have to have rust to build rust 2021-03-26 19:36:15 Wa - wh - nvm 2021-03-26 19:36:17 Thermi: bootstrap.sh is not for making SDKs to cross-compile with 2021-03-26 19:36:30 I see 2021-03-26 19:36:33 Thermi: it is for building a bootstrap environment that gets deployed on a target 2021-03-26 19:36:48 Ariadne: for now... https://github.com/Rust-GCC/gccrs 2021-03-26 19:36:57 ericonr: for now, yes 2021-03-26 19:37:03 last commit from yesterday 2021-03-26 19:38:12 Thermi: my plan is to add bootstrap.sh $arch --sdk-only 2021-03-26 19:38:30 Ariadne: I see, thank you. 2021-03-26 19:38:37 Thermi: which is probably what you want 2021-03-26 19:38:38 Ariadne: so it won't totally murder aarch64 then? 2021-03-26 19:38:50 RootWyrm: ? 2021-03-26 19:39:06 qemu to aarch64 tends to be... unpleasant. (not as unpleasant as ppc64, but.) 2021-03-26 19:39:06 RootWyrm: i'm not following 2021-03-26 19:39:20 i dont see what qemu has to do with this 2021-03-26 19:40:41 Ariadne: may be i'm misunderstanding you then. what i heard was: rust needs to be cross-compiled to non-x86 target arch. 2021-03-26 19:40:53 yes 2021-03-26 19:41:05 so that we can have a rust on that target machine 2021-03-26 19:41:08 to rebuild rust with 2021-03-26 19:41:24 you see when you like rust, you have to put some rust in your rust so you can rust while you rust 2021-03-26 19:41:35 Ariadne: right, so in most of my envs, that means building rust in qemu to aarch64. and generally qemu to aarch64 is about a 15x slowdown. 2021-03-26 19:41:46 oh 2021-03-26 19:41:53 you don't have to do that already 2021-03-26 19:41:57 you can run bootstrap.sh 2021-03-26 19:42:00 and get a rustc 2021-03-26 19:42:11 if you umm 2021-03-26 19:42:12 do 2021-03-26 19:42:17 CBUILD=aarch64 abuild - 2021-03-26 19:42:18 r 2021-03-26 19:42:20 in rust 2021-03-26 19:42:28 it will build you a rustc that is cross compiler 2021-03-26 19:42:35 or it should 2021-03-26 19:42:39 i haven't tested it 2021-03-26 19:43:00 I just mostly want to make sure I don't go 'why is this taking 3 days?!' 2021-03-26 19:43:13 because the usual goal is to have it spit out rustc-whatever aarch64 apk 2021-03-26 19:43:36 oh no 2021-03-26 19:43:43 it wont use qemu 2021-03-26 19:43:47 bootstrap never uses qemu 2021-03-26 19:44:05 the APKBUILDs that bootstrap iterates over have to be adjusted to support cross-compilation 2021-03-26 19:45:00 unless you're, you know, not exactly cross-compiling because it's already inside qemu. 2021-03-26 19:45:38 well if you are intentionally using qemu, you're probably not using bootstrap.sh 2021-03-26 19:45:55 but you can build a rust cross compiler with abuild and not use qemu :) 2021-03-26 19:46:36 though bootstrap.sh builds a cross compiler and then uses that cross compiler to build a native compiler for the target 2021-03-26 21:03:53 hey hey... why topics here and on #alpine-linux arent changed? huh!? ;) 2021-03-26 21:04:11 and why I didnt have any notification from mailing list :/ 2021-03-26 21:05:52 ah, no announce on ML, I guess ncopa was in a hurry :) 2021-03-27 08:54:22 MY-R: /topic 'distro in limbo' : 2021-03-27 08:54:27 :) 2021-03-27 15:06:07 So, I'm going to try and spend a bit of time looking at doing https://gitlab.alpinelinux.org/alpine/aports/-/issues/12540. I'm looking at the lazy setup script for zrepl, and it seems the only go modules it imports are for go build to build some command line tools it uses during the build process 2021-03-27 15:06:38 I'm not sure if the best option would be to break these out into subpackages, that are required to build zrepl, or build them temporarily in the apkbuild 2021-03-27 15:17:26 Oh, derp, there's a module with pinned versions 2021-03-27 15:17:31 that tends to make things easier 2021-03-27 15:24:55 Now, the only thing I really need to do is find some way to verify if this is reproducable 2021-03-27 15:25:41 really it can't be because it includes the go version in the binary and alpine doesn't really like keeping old versions around 2021-03-27 15:33:16 just submitted a MR and its failed with an apkbuild-lint error - for a pre-existing lint condition. So how did did the package get built when last MR went through 8 days ago? 2021-03-27 15:33:52 as that "problematic" line in the APKBUILD file pre-dated the last successful MR on the package 2021-03-27 15:34:32 linting does not fail the pipeline, only produce warning 2021-03-27 15:35:13 sorry you're right, I misread the "script failure" message, doh! 2021-03-27 15:35:29 not enough coffee lol 2021-03-27 15:35:34 (allowed to fail) 2021-03-27 15:35:43 that's the part that's important 2021-03-27 15:36:20 especially with core packages in main, we don't want to drastically change things to make backporting security fixes easier 2021-03-27 15:36:58 Is anyone aware of any apkbuild examples that use go for the build that I can reference? 2021-03-27 15:37:26 ikke: understood, it is a "main" package so I have been extra careful with the changes 2021-03-27 15:38:12 ShaRose: chezmois, fzf 2021-03-27 15:38:33 minimal: I was specifically referring to linting 2021-03-27 15:41:43 That seems perfect: Thanks ikke. Doesn't really seem to be any way to search by something like that, so I was floundering. 2021-03-27 15:42:41 ShaRose: with lua-aports, you could do: ap revdep go 2021-03-27 15:42:50 (in the aports repository) 2021-03-27 15:44:11 if I get this working, I might include that on the wiki: I'd been poking at this for a while when I had the time 2021-03-27 16:06:33 Hello 2021-03-27 16:07:11 today I've discovered that the qemu package from latest 3.13.3 is missing zstd compression support for qcow images 2021-03-27 16:07:36 because the APKBUILD file is missing the "--enable-zstd " line in the features 2021-03-27 16:08:21 and also the zstd-dev & zstd-static libraries in the dependencies 2021-03-27 16:08:51 once you add those in the APKBUILD, zstd in qemu works as expected 2021-03-27 16:09:35 it's a feature of qemu 5.1, I think should be enabled by default in 5.2 2021-03-27 16:11:57 wyk72: care to elaborate, why? 2021-03-27 16:18:18 well, the zlib compression (default) is rather under-performing in qemu, i.e. is really slow 2021-03-27 16:18:45 the zstd algo is superior both in compression ratio & speed 2021-03-27 16:19:38 since is included in qemu since 5.1 I don't see why it should not be enabled by default 2021-03-27 16:38:08 sounds reasonable 2021-03-27 16:38:40 should be considered for qemu 6.0 2021-03-27 21:06:49 mps: qemu 6.0 won't make alpine 3.14 freeze 2021-03-27 21:06:56 mps: we should just do it now imo 2021-03-27 21:31:18 ok 2021-03-28 00:54:12 Hey folks, I hear that some folks are interested in OpenRC, please join #openrc and let's work on it. :-) 2021-03-28 00:55:06 I could actually use some team members; there is a lot to do. :-) 2021-03-28 00:56:51 I can't do all of it. :-) 2021-03-28 00:57:08 I'll be looking for you folks on #openrc. :-) 2021-03-28 01:21:00 If someone has concerns about how I have been working on OpenRC, I would like to hear them. 2021-03-28 01:21:04 :-) 2021-03-28 07:42:48 hmm, openrc is not perfect and need some polishing but other ones are also. for my use cases I would chose openrc for now and probably future 2021-03-28 07:43:35 hm,hm, WilliamH already left channel 2021-03-28 07:44:58 yes 2021-03-28 07:49:30 oh, fun: ERROR: Job failed (system failure): Error response from daemon: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "sh": executable file not found in $PATH: unknown 2021-03-28 07:51:17 yes, complicated setups are prone to failure ;) 2021-03-28 07:52:31 apparently the hadolint docker image no longer has a base OS 2021-03-28 07:52:45 just the hadolint binary 2021-03-28 07:53:21 https://github.com/hadolint/hadolint/issues/578 2021-03-28 07:54:36 Ok, apparently it was wrong tagging on the docker image that made it work 2021-03-28 08:03:19 simple fix :) 2021-03-28 12:39:29 anything still missing on !19694 ? 2021-03-28 12:40:52 nope, looks fin 2021-03-28 12:40:53 e 2021-03-28 12:40:58 i pushed it 2021-03-28 12:41:01 ;D 2021-03-28 12:41:16 thanks for merge 2021-03-28 12:42:01 I thought bb find did not support "+" 2021-03-28 12:42:09 (for -exec) 2021-03-28 12:42:38 it looks like it does 2021-03-28 12:43:07 must have misremembered then 2021-03-28 12:44:34 btw which one is which, as I dont remember now? 2021-03-28 12:44:58 ; does cmd invocation on every file and + appends each file for one command? 2021-03-28 12:45:02 on another way? 2021-03-28 12:45:59 yes, that's correct 2021-03-28 12:46:12 ; is one invocation per argument 2021-03-28 12:52:12 ikke: well the package seems complete and functional either way :P 2021-03-28 12:52:34 yup 2021-03-28 12:57:22 JuniorJPDJ: i did revise your package slightly to add armv5 and armv6 support 2021-03-28 12:57:31 (though armel is no longer a release architecture) 2021-03-28 13:00:00 :D ok 2021-03-28 13:02:06 you checked if it still works btw? as I had loads of trouble with this package 2021-03-28 13:02:27 the change i made wouldn't impact it 2021-03-28 13:02:29 upstream is doing very weird things in his build script 2021-03-28 13:02:40 it was just adding two more _cpu lines 2021-03-28 13:03:03 i mean: did you check if it works for arches you added 2021-03-28 13:03:17 I'm ok with your change, just curious 2021-03-28 13:03:58 yeah it builds fine 2021-03-28 13:04:10 cool 2021-03-28 13:04:29 i do not use zsh so i have not tested it any more than that 2021-03-28 13:04:30 :p 2021-03-28 13:04:34 you are using alpine on armv5/v6? 2021-03-28 13:04:48 armv6 hardfloat 2021-03-28 13:05:04 we build for it 2021-03-28 13:05:09 yes i have some rpi1 still kicking 2021-03-28 13:05:19 And rpi0 2021-03-28 13:05:33 i am not using armv5 though 2021-03-28 13:06:16 but we try to still keep armel building if anyone wants to build it for themselves 2021-03-28 13:06:35 right, I forgot rpi is armv6 2021-03-28 13:06:51 well rpi2/rpi3 are armv7 2021-03-28 13:06:55 and rpi4 is armv8 2021-03-28 13:07:09 but the original and the pi zero are v6 2021-03-28 13:07:17 theres also a lot of clones that are v6 2021-03-28 13:07:27 which is why armhf remains as a release arch 2021-03-28 13:09:37 why isnt armhf built for edge/testing then? 2021-03-28 13:09:52 it is 2021-03-28 13:09:58 we just dont have CI for it 2021-03-28 13:10:07 oh. 2021-03-28 13:10:07 We might be adding it though 2021-03-28 13:10:35 we also don't have CI for mips, but that should also happen soon 2021-03-28 15:28:49 would be nice! 2021-03-28 16:17:36 imagine being held up for a solid 10 minutes trying to figure out your apkbuild because you had an echo in front of the docs install command 2021-03-28 16:18:15 heh 2021-03-28 16:18:18 wow, look at that: Removing that echo and suddenly it works! 2021-03-28 16:19:56 also, while I think of it: Should I include a dummy config in the main package? Right now I'm including https://gist.github.com/ShaRose/56d5c3df37dcb6ad478bfef389dabc7e in the main package, but the /usr/share/zrepl/examples/ stuff is in the docs subpackage 2021-03-28 16:20:03 not sure what best practice is for that 2021-03-28 16:22:14 https://gist.github.com/ShaRose/74eb9e522d8db1afd9ce30f446537d22 that's what the package layout looks like at the moment 2021-03-28 16:22:50 there are also proper docs, but those just build the website so I don't think they are of much use... but I can build them if it's preferred 2021-03-28 16:23:32 usually applications come with a basic default config 2021-03-28 16:23:49 yeah, but in this case you need to modify it before it will accept it 2021-03-28 16:24:05 (you need to have a job configured) 2021-03-28 16:24:34 I'm leaning now to having the examples in the main package, and then building the docs themselves in the docs package actually 2021-03-28 17:00:44 woo, testing on my actual backup system works 2021-03-28 17:14:43 HMMMM. I feel like the syslog system in zrepl is expecting something a tad more complex than alpine's. 2021-03-28 17:14:49 Mar 28 14:31:17 clio local0.err zrepl[30017]: [^[[mthemis^[[0m][^[[mrepl^[[0m][^[[m6dnK$N7LP$N7LP.Nj7g.g6uu.pcD0.5h7M^[[0m]: error listing sender filesystems ^[[merrType^[[0m="*status.statusError" ^[[merr^[[0m="rpc error: code = Canceled desc = context canceled" 2021-03-28 17:45:21 those are terminal escape codes 2021-03-28 17:46:24 I know, but I'm not sure if they should be there or not 2021-03-28 17:47:08 it doesn't seem like tail / cat / less interpret them 2021-03-28 17:47:56 I think less has -R 2021-03-28 17:48:24 I remember I used that for some related problem 2021-03-28 17:48:38 cat should just work though 2021-03-28 17:48:44 it doesn't seem to help... but not sure I can really do anything about it anyways 2021-03-28 18:58:26 >>> gcc-11: Building testing/gcc-11 11.0.1_git20210328-r0 (using abuild 3.7.0-r1) started Sun, 28 Mar 2021 18:58:12 +0000 2021-03-28 18:58:27 :) 2021-03-28 19:24:43 Ariadne: running into issues where ifupdown-ng does not seem to create a bond0 interface for some reason (I can create it manually though) 2021-03-28 19:25:03 what does your /e/n/i look like 2021-03-28 19:25:16 https://tpaste.us/nWy6 2021-03-28 19:25:20 that's -v output 2021-03-28 19:25:40 https://tpaste.us/zx1w 2021-03-28 19:26:19 it seems to be missing bond-members 2021-03-28 19:26:29 oh, right 2021-03-28 19:26:37 I did have them there before 2021-03-28 19:26:42 must have accidentally removed them 2021-03-28 19:27:21 troubleshooting an issue with bonding in the latest stable kernel 2021-03-28 19:27:41 it sets up the bond, but no connecting, and ping says: "sendto: invalid argument" 2021-03-28 19:28:36 strange 2021-03-28 19:28:48 3.12 kernel seems to work 2021-03-28 19:29:01 bond is working fine for me on 3.13 2021-03-28 19:29:31 This is on aarch64 2021-03-28 19:29:44 no idea what the issue is 2021-03-28 19:30:03 ah, i have not set up any of my honeycomb machines yet 2021-03-28 19:30:12 i am waiting for the onboard 10g to be supported in a released kernel 2021-03-28 19:30:33 these do have 10G ports 2021-03-28 19:30:59 Btw Ariadne, what was that thing you spoke of on Telegram a while ago regarding replacing OpenRC in Alpine? 2021-03-28 19:31:22 Newbyte: https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/ 2021-03-28 19:31:29 Newbyte: send all corporate benefactors to skarnet 2021-03-28 19:32:56 ikke: did you check ip route get 2021-03-28 19:33:25 Hello71: yes, was looking fine 2021-03-28 19:33:50 hm. did you add the oif and iif and whatnot 2021-03-28 19:34:05 I had the same setup working in the rescue os (alpine live os) 2021-03-28 19:34:23 Ariadne thanks! 2021-03-28 19:34:27 but that had a different kernel 2021-03-28 19:35:51 was the link physically up? 2021-03-28 19:36:06 dmesg | grep bond0 should yield "link becomes ready" 2021-03-28 19:36:42 can't think of anything that should give sendto: invalid argument 2021-03-28 19:36:58 iptables is operation not permitted. link down should be no route to host 2021-03-28 19:38:12 EINVAL The dest_len argument is not a valid length for the address 2021-03-28 19:38:13 family. 2021-03-28 19:39:19 it's a /31 subnet 2021-03-28 19:39:31 Ariadne: yes, it was up 2021-03-28 19:39:41 I'm now running the 3.12 kernel, so cannot show current output 2021-03-28 19:39:50 weird 2021-03-28 19:39:50 Ariadne: arping was responding 2021-03-28 19:40:02 could be a kernel regression 2021-03-28 19:40:20 a /31 is definitely an edge case 2021-03-28 19:40:24 yes 2021-03-28 19:40:26 all of my p2p links are /30s 2021-03-28 19:40:35 I tried to change it to a /29, but that was not working either 2021-03-28 19:41:11 and we have it working on another host on the same provider 2021-03-28 19:41:41 weird 2021-03-28 19:41:47 no clue :( 2021-03-28 19:41:59 ok 2021-03-28 19:42:00 i could add support for teaming driver if it would hep 2021-03-28 19:42:02 help* 2021-03-28 19:42:10 i don't think it is ifupdown-ng related 2021-03-28 19:42:15 no, me neither 2021-03-28 19:42:48 what does `ip -v link show` say? 2021-03-28 19:42:57 are you using busybox iproute or real iproute 2021-03-28 19:44:03 apparently bb iproute 2021-03-28 19:44:49 was installing iproute 2021-03-28 19:46:31 no, iproute2 was installed 2021-03-28 19:46:41 but it does not recognize the -v option 2021-03-28 19:55:59 ikke: please ask ncopa to upgrade the v3.13 kernel, it is severly outdated 2021-03-28 19:56:40 5.10.26? 2021-03-28 19:57:17 same as on edge 2021-03-28 19:57:32 nevermind then, last I checked it was still on .16 2021-03-28 20:18:45 ikke: sorry, ip -d link show 2021-03-28 20:19:28 ikke: also ip -d addr show 2021-03-28 20:26:39 https://tpaste.us/X1oB 2021-03-28 20:26:59 https://tpaste.us/Lwrx 2021-03-28 20:31:25 all of that seems legit 2021-03-28 20:31:53 In this case, it's working 2021-03-28 20:32:04 I need to reboot with the 3.13 kernel 2021-03-28 20:33:05 yup 2021-03-28 20:33:26 lets compare 2021-03-28 20:41:22 Ariadne: https://tpaste.us/ZEDz 2021-03-28 20:41:46 hmm 2021-03-28 20:41:54 so the bond0 is physically up 2021-03-28 20:42:02 https://tpaste.us/lENo 2021-03-28 20:44:23 for p2p i think you should use ip addr add x peer y 2021-03-28 20:44:43 cat /proc/sys/net/bonding/bond0: https://tpaste.us/d5Ol 2021-03-28 20:44:52 /proc/net/bonding/bond0* 2021-03-28 20:45:05 Hello71: same setup works in other situations 2021-03-28 20:45:24 probably 2021-03-28 20:45:31 hmm, that's a /30 I see now 2021-03-28 20:46:08 i'm not sure /31 is supposed to work on linux 2021-03-28 20:46:33 although recently .0 was freed 2021-03-28 20:46:47 Hello71: it works when I use the 3.12 kernel 2021-03-28 20:48:44 could be a change in arp or something. did you try ip a d 147.75.35.197/31; ip a a 147.75.35.197 peer 147.75.35.196? 2021-03-28 20:49:57 doesn't work either 2021-03-28 20:50:39 hm, if explicit p2p link doesn't work then i think it is definitely a bug 2021-03-28 20:50:53 same error? 2021-03-28 20:50:55 yes 2021-03-28 20:51:14 ping: sendto: Network unreachable 2021-03-28 20:51:22 ip -d route show 2021-03-28 20:51:28 https://lore.kernel.org/lkml/?q=bond -> net: bonding: fix error return code of bond_neigh_init() 2021-03-28 20:51:40 yes, that seems plausible 2021-03-28 20:51:41 unicast 147.75.35.196 dev bond0 proto kernel scope link src 147.75.35.197 2021-03-28 20:51:54 ah, seems like was reverted upstream actually 2021-03-28 20:52:11 Hello71: may have leaked into stable though 2021-03-28 20:52:12 https://github.com/torvalds/linux/commit/080bfa1e6d928a5d1f185cc44e5f3c251df06df5 2021-03-28 20:52:17 GregKH is somewhat sloppy 2021-03-28 20:52:29 hrm reverted on mar 12 2021-03-28 20:52:56 so it shouldn't have landed in https://lore.kernel.org/lkml/161666093914799@kroah.com/ 2021-03-28 20:52:58 unfortunately, i do not have any alpine machine i can just upgrade to latest kernel and see if it is broken 2021-03-28 20:53:03 i need bond to continue working :))) 2021-03-28 20:53:16 yes, i know there are frequent complaints about stable kernel procedure 2021-03-28 20:54:41 seems like 99% caused by cherry-picking 2055a99da8a253a357bdfd359b3338ef3375a26c 2021-03-28 20:55:00 https://github.com/torvalds/linux/commit/2055a99da8a253a357bdfd359b3338ef3375a26c 2021-03-28 21:07:14 so I might work after that is reverted? 2021-03-28 21:07:25 given that it's part of the kernel in the first place 2021-03-28 21:08:04 er, i meant 99% chance, not 99% of it is caused by 2021-03-28 21:08:48 i think reverting it will fix it. probably a good idea to send mail to list to request that 2021-03-28 21:09:08 hmm, I don't see that code in our version of the kernel 2021-03-28 21:13:24 so somehting else :( 2021-03-28 21:25:54 interesting 2021-03-28 21:25:57 linux-edge is working 2021-03-28 21:26:07 so certainly seems like a regression 2021-03-28 21:49:04 yes i think that commit was not cherry-picked to 5.11 2021-03-28 21:49:14 how are you checking it? 2021-03-28 21:49:50 I checked the code in the linux-lts package we have 2021-03-28 22:32:17 weird. For some reason the automated build on x86-64 failed a test, but all the others worked: and retrying it worked. 2021-03-28 22:32:21 Gremlins, clearly. 2021-03-28 22:34:02 Reminds me: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19863/diffs?commit_id=6fc0b7817e8c7b028640265fdb7b392b8f3d92a3 anyone know if it's recommended to cd back to $builddir at the end of package? 2021-03-29 01:51:20 <[[sroracle]]> ShaRose: subpkg split functions don't cd back to $builddir automatically 2021-03-29 01:51:43 <[[sroracle]]> so it'd be easier to cd back to builddir at end of main package() than to have to cd at the start of each split function 2021-03-29 01:52:54 <[[sroracle]]> of course, you may not need to... but it would save headaches later if it was necessary (of course, this could be a candidate for changing abuild behavior, but it would require fixing an unknown but probably small amount of existing packages) 2021-03-29 07:22:07 looks like merging MRs is not good things to do, however much we merge numbers are always grows 2021-03-29 07:58:52 the number of open MRs? 2021-03-29 07:59:32 yes 2021-03-29 08:00:09 probably time to look at adding additional developers 2021-03-29 08:01:28 this would help but not much too, quality of MRs is more important imo 2021-03-29 08:02:12 i mean if we add developers who no longer need mentoring, then it cuts them out of the noise 2021-03-29 08:02:15 :) 2021-03-29 08:55:20 maybe consider setting up e.g. Marge Bot to offload some work from humans? 2021-03-29 08:55:52 Seems to work well for other free software projects 2021-03-29 08:56:05 AI? 2021-03-29 08:56:23 and exterminate developers :) 2021-03-29 08:57:31 No, it's just a bot that handles some things for you, like automatically rebasing, retrying, and then actually merging when the pipeline succeeds (however you need to assign "her" for this to happen, so no unintended merges) 2021-03-29 08:57:54 no spooky AI 2021-03-29 08:58:37 Mesa uses Marge Bot for example 2021-03-29 09:11:01 I don't like idea that 'robot' can review MRs, or anything else. 2021-03-29 09:11:34 it can help for sure, but human have to decide at the end 2021-03-29 09:13:41 Something like marge bot would be super nice 2021-03-29 09:14:07 It's rather frustrating when I need to wait some 30 seconds for the Gitlab webUI to rebase and merge a MR 2021-03-29 09:14:24 huh 2021-03-29 09:14:26 Especially when it needs some 2-3 refreshes to get that the rebase is actually done 2021-03-29 09:15:27 I haven't looked super deeply into Marge Bot, but my understanding is that you need to actually assign her before she does anything, so humans do have a decide. 2021-03-29 09:15:55 Yup 2021-03-29 09:16:28 The bot only does the rebase & merge for you so you don't have to wait for gitlab to rebase the thing 2021-03-29 10:55:40 We want to prevent the bots constantly rebasing MRs and triggering lots of useless CI jobs, though 2021-03-29 10:58:09 Sure, maybe the bot could auto-cancel the CI job though 2021-03-29 10:58:28 Since we don't really need CI there 2021-03-29 10:58:37 no, it needs to pass once 2021-03-29 10:58:43 (agreeing) 2021-03-29 10:59:03 Ah yes,that confused me for a sec :D 2021-03-29 11:06:39 who upgraded squid to beta version 2021-03-29 11:07:09 AI robot :) 2021-03-29 11:07:14 68d321c752a19a3dbc7c68a84908c310693adc16 2021-03-29 11:07:29 6d446c6e6d358a7ebbfa3b88cc7e8f60709b9c70 2021-03-29 11:08:10 hah, BDFL 2021-03-29 11:08:40 didn't expected this from him 2021-03-29 11:09:06 We should have some kind of machine readable package policy 2021-03-29 11:10:05 we have comments in some APKBUILDs for such things, nginx and haproxy comes to mind right now 2021-03-29 11:10:20 yes, but comments can easily be overlooked, especially when just using abump 2021-03-29 11:10:39 right 2021-03-29 11:11:18 but these comments are good for scolding :P 2021-03-29 11:11:24 :) 2021-03-29 11:12:05 now is the question, what to do with squid now 2021-03-29 11:12:21 If it's a betaversion, i'd say just revert it 2021-03-29 11:12:35 btw, don't scold me because of bad edk2 upgrade 2021-03-29 11:12:41 It made it to 3.13 2021-03-29 11:12:57 yes, problem is it is already in 3.13 2021-03-29 11:13:38 I kind of dislike these version policies where beta versions are not clearly marked 2021-03-29 11:14:03 yes 2021-03-29 11:15:07 I doubt we should revert squid to stable in 3.13, or I'm wrong? 2021-03-29 11:15:34 are there incompattible changes? 2021-03-29 11:15:55 probably, didn't analyzed 2021-03-29 11:16:16 it's in main, so we would have to support it for 2 years 2021-03-29 11:16:29 I would not imagine these beta versions getting security / bugfixes 2021-03-29 11:16:34 but usually major versions of squid have changes which are not backward compatible 2021-03-29 11:21:43 hmm, not much info http://www.squid-cache.org/Versions/v5/changesets/ 2021-03-29 11:27:53 the new ampere altra mt jade server is just insane 2021-03-29 11:43:23 insane in good or bad connotation 2021-03-29 12:00:41 probably insane speed 2021-03-29 12:07:01 move my lxcs there then :) 2021-03-29 12:27:30 Will be eventually 2021-03-29 12:28:10 hah, really? 2021-03-29 12:28:15 Yes 2021-03-29 12:29:26 hehe, proof that prayer works ;) 2021-03-29 12:29:27 context: https://twitter.com/n_copa/status/1376494093065457667/photo/1 2021-03-29 12:30:40 :-) 2021-03-29 12:31:47 heh, reminds me when first tested Intels Sitka servers, about 25 years ago 2021-03-29 12:32:31 not same, ofc, but feeling is similar 2021-03-29 13:06:08 the bonding driver has a regression, and im backporting a patch + enable the EFI RTC driver. will probably backport it to 3.13-stable 2021-03-29 13:06:27 but after that we'll have a kernel that works well with this machine 2021-03-29 13:07:01 are you just backporting the revert? 2021-03-29 13:08:47 yup 2021-03-29 13:08:57 Hello71: and thanks for finding it 2021-03-29 13:09:08 i have tested it and it makes bonding work again 2021-03-29 13:09:48 also rebasing my python 3.9 branch 2021-03-29 13:09:52 lots of conflicts... 2021-03-29 13:10:18 which is kinda good though. means lots of work has happend over the weekend :) 2021-03-29 13:10:37 i have ~950 commits now for python 3.9 rebuild 2021-03-29 13:14:02 heh 2021-03-29 15:30:54 omni: i'm digging into this 2021-03-29 15:35:23 make[2]: Entering directory '/home/kaniini/aports/main/s390-tools/src/s390-tools-2.16.0/iucvterm/po' 2021-03-29 15:35:23 /bin/sh: xgettext: not found 2021-03-29 15:35:23 mv: can't rename 'iucvterm.po': No such file or directory 2021-03-29 15:35:25 aha 2021-03-29 15:36:22 what is it? 2021-03-29 15:39:43 the system management tools for s390x machines 2021-03-29 15:40:08 they fail to build because someone sloppily added gettext support 2021-03-29 15:42:58 i think i fixed it 2021-03-29 15:43:06 running build now to be sure 2021-03-29 15:43:42 :/ 2021-03-29 15:44:58 hmm 2021-03-29 15:45:02 kms.c:44:2: error: #error KMS_PLUGIN_LOCATION must be defined 2021-03-29 15:45:05 what is this 2021-03-29 15:45:40 kubernetes????????????? 2021-03-29 15:45:47 what the fuck are you smoking IBM 2021-03-29 15:49:58 well, figured that out 2021-03-29 15:50:34 they smoke same stuff that people at mountain view, california 2021-03-29 15:52:07 ... 2021-03-29 15:55:17 this is the worst build system on the planet 2021-03-29 16:02:00 /usr/bin/install: unrecognized option: T 2021-03-29 16:02:00 BusyBox v1.32.0 () multi-call binary. 2021-03-29 16:02:01 :( 2021-03-29 16:02:16 ? 2021-03-29 16:02:18 .. 2021-03-29 16:02:29 what does ginstall -T even do 2021-03-29 16:02:51 -T, --no-target-directory treat DEST as a normal file 2021-03-29 16:02:52 i see 2021-03-29 16:03:21 so, in other words: nothing 2021-03-29 16:03:48 no, it avoids the annoying behavior of 2021-03-29 16:04:13 install foo bar creating bar/foo rather than erroring out if bar exists and is a directory 2021-03-29 16:04:27 well, right 2021-03-29 16:04:30 :) 2021-03-29 16:04:32 but in this case, it does nothing 2021-03-29 16:04:38 iirc my install.sh already avoids that 2021-03-29 16:04:42 right 2021-03-29 16:04:50 its just robustness against a broken dest dir 2021-03-29 16:11:00 omni: https://git.alpinelinux.org/aports/commit/?id=103603417028 2021-03-29 18:00:48 Ariadne: cool! 2021-03-29 18:04:02 I mentioned this on gitlab 2021-03-29 18:04:12 but ffmpeg/libav needs to be rebuilt following the vp9 update 2021-03-29 18:33:38 could be combined with !19683 =) 2021-03-29 19:08:51 if an initscript has 'need net' in the depends(), what does that mean exactly? that all interfaces should be up, or only that the service that 'provide net' has been started (but it may not have brought up any ifaces, like lo, etc) ? 2021-03-29 19:09:10 need net is frustrating 2021-03-29 19:09:16 craftyguy, i don't know either but i suspect it's just a bug 2021-03-29 19:09:21 yeah tell me about it :P 2021-03-29 19:09:24 https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#be-wary-of-need-net-dependencies 2021-03-29 19:09:26 "needs net" is nonsense without more qualification 2021-03-29 19:09:42 ok, so I'm not completely crazy then 2021-03-29 19:09:47 no you're very much sane here 2021-03-29 19:09:49 :) 2021-03-29 19:10:07 ah how did I miss that section in the user guide! 2021-03-29 19:10:21 https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#be-wary-of-need-net-dependencies 2021-03-29 19:10:24 oh 2021-03-29 19:10:26 I'm too slow 2021-03-29 19:11:31 so i think in this case, 'need loopback' or the conf.d change that section suggests is the 'right' thing 2021-03-29 19:24:02 Yeah "need net" is weird. 2021-03-29 19:24:10 It really doesn't mean much. 2021-03-29 19:24:33 good to know. thanks for the help everyone 2021-03-29 19:24:59 craftyguy: the problem is, net services can be up, but what happens if the cable gets unplugged etc etc... 2021-03-29 19:25:56 yeah, makes sense. I learned that what I was really after wasn't necessarily 'need net' 2021-03-29 19:33:31 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19863 @Ikke can you make it pushable ? 2021-03-29 19:34:04 "Not available for protected branches" 2021-03-29 19:34:13 they used master 2021-03-29 19:34:16 let me fix that 2021-03-29 19:35:05 done 2021-03-29 19:36:48 ty 2021-03-29 20:08:37 omni: PureTryOut[m]2 krita is still missing dependencies on mips64 2021-03-29 20:13:29 Ugh, when is CI for mips64 going to be finished? 2021-03-29 20:13:47 waiting for the hardware 2021-03-29 21:24:06 oh, uhm, didn't check properly then.. 2021-03-29 21:26:16 I guess I just went to see that qt5-qtdeclerative was there.. 2021-03-29 21:26:49 anyone that works on the secdb around? 2021-03-29 21:27:21 specifically, someone that can help the MRs for the scripts that are just languishing? 2021-03-29 21:29:32 https://build.alpinelinux.org/buildlogs/build-edge-mips64/community/krita/krita-4.4.3-r0.log 2021-03-29 21:32:10 I need to make some time for it 2021-03-29 21:32:19 nliadm: * 2021-03-29 21:32:39 I'm not familiar with the code, though 2021-03-29 21:32:43 I'd really appreciate it 2021-03-29 21:33:01 it's mostly an issue around lua only having tables 2021-03-29 21:33:10 yea 2021-03-29 21:33:45 so the resulting json is always an array, but never an empty array 2021-03-29 21:34:24 an object, you mean 2021-03-29 21:36:58 yeah, `[]` always becomes written `{}` 2021-03-29 21:37:34 which throws a wrench into deserializtion for typed languages 2021-03-29 21:38:22 understood 2021-03-29 21:40:38 is the `apk` command considered to have a stable API or is that not strictly guaranteed? 2021-03-29 21:41:17 Thalheim: we plan to change the behavior of several applets as part of apk-tools 3 2021-03-29 21:47:31 when we disable for an arch that didn't build, like mips64 here !19898, we don't need to bump the pkgrel, do we? 2021-03-29 21:48:02 no 2021-03-29 21:48:55 PureTryOut[m]2: oh, you already did that 2021-03-29 21:49:10 Ariadne: thanks 2021-03-30 09:22:10 I have already flagged aws-cli, but I have a question. The AWS CLI 1.x major version is still being maintained, although I think it doesn't receive new features anymore, only fixes. AWS recommends to switch to 2.x which is the newest version since Feb 2020... This is a similar situation to what happened when Python 3.x was introduced, as 2.x was 2021-03-30 09:22:10 still receiving patches for a while... https://pkgs.alpinelinux.org/package/edge/community/x86/aws-cli 2021-03-30 09:22:40 Should we create aws-cli-2, or similar, or just upgrade the entire package to 2.x, considering v1 and v2 have incompatible changes in syntax and such? 2021-03-30 09:23:28 what are other distros doing? 2021-03-30 09:26:54 Good question 2021-03-30 09:27:21 https://archlinux.org/packages/?sort=&q=aws-cli&maintainer=&flagged= Arch didn't even update... 2021-03-30 09:27:45 https://aur.archlinux.org/packages/?O=0&K=aws-cli the AUR has both 2021-03-30 09:29:33 https://pkgs.org/search/?q=aws-cli OpenSUSE Tumbleweed is on 1.x, and Slackware is on 2.x exclusively 2021-03-30 09:30:39 are there reasons to keep 1.x? 2021-03-30 09:30:42 My opinion is that 1.x should remain for aws-cli, and we should make a separate v2, as I can see the use-case of Docker being used for CI/CD, and users expecting v1 to be bundled with apk, whereas if they actually want v2, they can just search the repos and see v2 available easily. 2021-03-30 09:30:55 1.x is still being maintained and v2 introduces breaking changes for syntax 2021-03-30 09:59:17 seems reasonable 2021-03-30 10:16:58 morning 2021-03-30 10:17:13 or good day 2021-03-30 10:17:24 lxc is broken in 3.13 2021-03-30 10:17:42 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12281 2021-03-30 10:17:48 and edge 2021-03-30 10:18:36 alpine template is broken as well. apparently lxc now creates the /dev/urandom and similar device so the template should not 2021-03-30 10:20:22 hmm, didn't noticed this (or other) bug 2021-03-30 10:32:29 moin 2021-03-30 10:34:06 ncopa: in your python 3.9 work, are you ugprading python aports along the way? 2021-03-30 10:34:58 omni: only when they dont work with python 3.9 2021-03-30 10:35:11 right 2021-03-30 10:38:09 ncopa: fun, another CVE in a base package 2021-03-30 10:38:43 (busybox) 2021-03-30 10:40:57 hmm, how this bug report 'find' 'srv/lxc/CONTAINER/config' 2021-03-30 10:41:07 we use /var/lib/lxc 2021-03-30 10:41:30 buggy bug report :) 2021-03-30 10:49:03 ncopa: lxc is working fine for me on edge 2021-03-30 10:49:26 Ariadne: do you drop sys_admin? 2021-03-30 10:49:34 no 2021-03-30 10:49:40 That's what breaks it for us 2021-03-30 10:49:42 stock config i think 2021-03-30 10:49:54 but i only use privileged containers 2021-03-30 10:50:50 We include lxc.cap.drop = sys_admin in all container configs 2021-03-30 10:59:21 yeah, it is lxc.cap.drop = sys_admin that broke with either 5.10 kernel or lxc 4.0.6 2021-03-30 11:20:49 even with 5.11 kernels 2021-03-30 11:21:33 tested with linux-edge 5.11.9 2021-03-30 11:22:03 20210330111905.120 ERROR conf - conf.c:lxc_mount_auto_mounts:725 - Cross-device link - Failed to mount "/sys/fs/cgroup" 2021-03-30 11:23:30 i also tested with linux-edge in a vm 2021-03-30 11:23:36 and i can confirm it 2021-03-30 11:24:58 so, it is related to kernel 2021-03-30 11:25:17 or libcap 2021-03-30 11:25:27 no 2021-03-30 11:25:32 kernel 2021-03-30 11:31:47 https://github.com/lxc/lxc/issues/1737 2021-03-30 11:33:40 but I don't see fix there 2021-03-30 11:52:37 anyone have opinions on !19817 ? 2021-03-30 11:55:47 The MR lacks a rational for this change 2021-03-30 11:57:16 ikke: I indicated that in my comment to Soeren 2021-03-30 11:57:40 Should be part of the commit message 2021-03-30 11:58:46 Ok, I can update the commit message, I guess I assumed it was somewhat obvious that for security-related reason people may want to control the key types generated 2021-03-30 12:16:35 It's good to be explicit about things 2021-03-30 12:19:56 yeah, obvious things aren't always obvious :-) 2021-03-30 12:20:06 have updated commit message 2021-03-30 13:02:24 minimal: im bit worried about the provides=openssh-server 2021-03-30 13:02:43 the openssh-server-pam vs openssh-server clash it a bit nasty 2021-03-30 13:02:58 not sure how to properly fix it 2021-03-30 13:03:38 that was added to add the situation reported in the referred Issue - with openssh-server-pam installed if you then install openssh it depends on openssh-server (which has a sshd binary as does openssh-server-pam) 2021-03-30 13:04:03 basically openssh-server and openssh-server-pam need to conflict 2021-03-30 13:04:23 yeah, it needs to be cleaned up 2021-03-30 13:04:45 though from memory the only package that declares a depends on openssh-server is openssh 2021-03-30 13:05:10 i think i have seen some other package depending on openssh-server-pam 2021-03-30 13:05:28 when builder builds it, abuild would install openssh-server-pam, which replaces openssh-server 2021-03-30 13:05:51 then when uninstalling the build deps, it uninstalls openssh-server-pam 2021-03-30 13:05:57 which removes sshd 2021-03-30 13:06:16 just did a quick search - duo_linux deps on openssh-server-pam 2021-03-30 13:06:28 it seems to be the only one 2021-03-30 13:06:38 yeah, so building duo_linux kills ssh access to build server 2021-03-30 13:07:00 adding a conflict would solve that 2021-03-30 13:07:16 but it also measn that duo_linux will no longer build 2021-03-30 13:07:35 my point here is that the openssh-server-pam thingy is a bit complicated 2021-03-30 13:07:36 the issue reported openssh-server-pam failing to work after the "apk add openssh" as it replace the sshd binary 2021-03-30 13:08:16 and i think it might be good to keep those issues separate 2021-03-30 13:08:27 possibly it related to the sshd_config - if PAM is enabled in there perhaps it openssh-server is installed over the top it doesn't like the pam config 2021-03-30 13:09:04 im kinda ok with the ssh key generation but the pam thingy may need more work 2021-03-30 13:09:21 ok, I will backout the "provide" change for now 2021-03-30 13:09:58 I can submit a separate MR for the pam/non-pam deps issue 2021-03-30 13:10:19 yeah that would be good 2021-03-30 13:11:13 so, from a search of aports, openssh-server is depended on by openssh and monkeysphere, openssh-server-pam is depended on by duo_linux. No other packages 2021-03-30 13:16:29 solution is simple: remove pam from alpine 2021-03-30 13:18:56 ncopa: "provide" change removed 2021-03-30 13:27:19 puzzling authentication methods 2021-03-30 13:33:54 mps: I'll redirect all complaints to you :-p 2021-03-30 13:37:25 ikke: sure, I already set 'from ikke > /dev/null' :) 2021-03-30 13:38:29 btw, any new requests for kernels, we have new releases now 2021-03-30 13:55:28 hmm, '/dev/ikke > /dev/null' :) 2021-03-30 13:55:55 first /dev is developer, not device 2021-03-30 13:56:56 Yes, got that 2021-03-30 13:58:41 something is broken 2021-03-30 13:59:24 on armv7 docker pulls armv6 images 2021-03-30 14:09:05 i wonder if go on armv7 builds GOARM=7 targes by default? seems like it doesnt 2021-03-30 14:09:24 dunno how to check what target go generates 2021-03-30 14:10:43 ncopa: `go env` should show, I think 2021-03-30 14:12:04 ok. says GOARM=7 2021-03-30 14:12:10 however, the docker build logs: 2021-03-30 14:12:13 Building: bundles/dynbinary-daemon/dockerd-20.10.5 2021-03-30 14:12:14 GOOS="" GOARCH="" GOARM="" 2021-03-30 14:12:14 Created binary: bundles/dynbinary-daemon/dockerd-20.10.5 2021-03-30 14:12:22 https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/docker/docker-20.10.5-r1.log 2021-03-30 14:50:27 Can we remove the flag on https://pkgs.alpinelinux.org/package/edge/community/x86/aws-cli ? 2021-03-30 14:50:53 As we discussed earlier, I will be submitting an aws-cli-2. This package is still obsolete, but the version indicated on the flag is 2.x 2021-03-30 14:51:02 It needs to be updated to latest 1.x 2021-03-30 16:01:47 L1Cafe: i wouldn't worry about it too much 2021-03-30 18:55:40 f 2021-03-30 18:55:51 (oups) 2021-03-30 20:48:10 Hi...is there any word when a stable release of Alpine will be available with a fix for CVE-2021-28831 ? 2021-03-30 20:49:53 Kevin21: you can flag the package as out of date on pkgs.alpinelinux.org and open an issue 2021-03-30 20:50:09 otherwise, it will be fixed whenever someone feels like fixing it 2021-03-30 20:52:33 flagging is only for packages in edge 2021-03-30 20:52:44 not in stable branches 2021-03-30 20:58:04 The reason I ask is that our builds are being flagged via security automation because this has been rated "High" on NIST https://nvd.nist.gov/vuln/detail/CVE-2021-28831  as part of Busybox 2021-03-30 20:58:56 Kevin21: making an MR for it right now to backport the fix 2021-03-30 21:00:09 ikke: alpine needs a better way to track security vulnerabilities and flag packages that are out of date 2021-03-30 21:00:18 I tried creating issues, but the few I created went tnowhere 2021-03-30 21:00:27 Thanks ikke! do you have a link to the MR so I can track 2021-03-30 21:00:56 c705: we already have issues for this 2021-03-30 21:01:00 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19932 2021-03-30 21:01:13 c705: more flagging does not help 2021-03-30 21:01:22 Kevin21: that's for 3.13-stable 2021-03-30 21:01:33 Opened 1 minute ago by Kevin Daudt 2021-03-30 21:01:42 it's been out of date for 4 days now 2021-03-30 21:01:50 so what will help? 2021-03-30 21:03:49 people providing merge requests 2021-03-30 21:05:04 i am working on a vulnerability tracker to provide this information and more 2021-03-30 21:05:17 good 2021-03-30 21:05:22 it is fixed 2021-03-30 21:05:27 in edge 2021-03-30 21:05:30 yes 2021-03-30 21:05:30 yes 2021-03-30 21:05:33 but not in stable branches 2021-03-30 21:06:23 mps: i'm building something similar to https://security-tracker.debian.org/ 2021-03-30 21:06:28 lets look if it can be backported 2021-03-30 21:06:30 it's gonna be great 2021-03-30 21:06:35 mps: already working on it 2021-03-30 21:07:01 ah, nice and thanks. I can continue with wine :) 2021-03-30 21:07:35 but real one, not fake, windows 'emulator' 2021-03-30 21:08:39 Ariadne: I'm following debian sec tracker (and ML) for about 20-25 years 2021-03-30 21:09:07 mps: yep, i am working on getting that sort of infrastructure here 2021-03-30 21:09:52 good, I think it will be better than this sec notes in APKBUILDs 2021-03-30 21:10:04 it builds on that 2021-03-30 21:10:12 huh ;P 2021-03-30 21:10:16 you'll still put the secfixes data in APKBUILD :) 2021-03-30 21:10:28 this just enriches the data by colliding the secfixes db with other sources 2021-03-30 21:10:31 I had a hope ;) 2021-03-30 21:10:43 we have to record the fixed version *somehow* :) 2021-03-30 21:11:23 but even something with your idea will be good, better than current state 2021-03-30 21:12:21 coincidence is that I yesterday though about making parser/scanner for aports to extract 'yaml' from APKBUILDs 2021-03-30 21:12:54 thought* 2021-03-30 21:13:39 someone mentioned problem with lua about this, i.e. lua tables and json 2021-03-30 21:14:15 yes, lua cannot distinguish properly between objects and arrays 2021-03-30 21:14:33 so when a list is empty, the json output would be an empty object 2021-03-30 21:16:26 Kevin21: the MRs for 3.13 and 3.12 have been merged and should appear soon 2021-03-30 21:16:50 Thanks @ikke ! 2021-03-30 21:17:27 ikke: is perl acceptable 2021-03-30 21:17:59 Ariadne: great idea 2021-03-30 21:18:23 I already made POC in perl to check urls in APKBUILDs 2021-03-30 21:21:00 well my thing just consumes the json data 2021-03-30 22:36:22 Ariadne: where is the work on replacing openrc? (assuming there's an open 'issue' or some current discussion somewhere about it?) 2021-03-30 22:37:04 craftyguy: it's still quite early. i am working on finding skarnet some funding to work on it full time 2021-03-30 22:37:25 craftyguy: https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/ outlines what our plans are 2021-03-30 22:37:35 oh ok. are you collecting requirements somewhere? I have a request :D 2021-03-30 22:37:58 however skarnet does it for s6 2021-03-30 23:51:34 hey, who updated pipewire to latest version on stable 2021-03-30 23:51:36 as it's bugged.. 2021-03-30 23:51:46 now my sound system is dead 2021-03-30 23:51:53 issue is open, so why was it updated? 2021-03-30 23:55:58 stable as in 3.13? 2021-03-30 23:59:14 mhm 2021-03-30 23:59:32 few days ago it was pp3.21 on alpine3.13 2021-03-30 23:59:37 and now its pw3.24 2021-03-30 23:59:41 which is bugged 2021-03-31 00:04:14 *pw3.21 2021-03-31 07:01:06 9c1a3fe7c5023d88e2435a3ab7939f8bfda4aee8 2021-03-31 07:01:36 maxice8: ^^^ 2021-03-31 07:02:24 mps: we have the yaml/json data extracted from the APKBUILDs already on secdb.alpinelinux.org 2021-03-31 07:07:49 ncopa: aha. then I didn't understood what is the problem 2021-03-31 07:12:19 JuniorJPDJ: What's broken? Have you updated your config? 2021-03-31 07:48:55 Cogitri: that should not be necessary on a stable branch 2021-03-31 07:50:44 Oh, didn't see the 3.13 part, my bad 2021-03-31 08:40:29 i suspect it was unintentionally 2021-03-31 09:11:08 Cogitri: #12528 2021-03-31 09:20:13 mps razor: whenever you see bug in program don't try to fix it, remove it from aports 2021-03-31 09:20:55 mps: so rm - rf aports, I guess 2021-03-31 09:20:57 jk, for uninitiated 2021-03-31 09:22:00 maybe rephrase to 'useless programs' only :P 2021-03-31 09:41:49 mps: there is this old saying "Every program can be made at least one instruction smaller. Every program contains at least one bug. By induction, every program can be reduced to one instruction that is wrong". Makes for a pretty minimal distro 2021-03-31 09:43:04 ARMv9 announced 2021-03-31 09:58:22 detha: yes, there are a lot of 'sayings about programs' ;) 2021-03-31 09:58:47 ikke: yes, I posted link to #alpine-linux last night 2021-03-31 09:59:32 but, nothing revolutionary, predicted speed increase is about 30% 2021-03-31 10:00:39 but maybe it will 'kill' intel bad designed cpu arch, finally 2021-03-31 10:01:22 mps: I wouldnt count on that 2021-03-31 10:01:48 most advanced usages are still on windows with x86 apps 2021-03-31 10:02:15 also imagine gaming on arm, well.. ;/ 2021-03-31 10:02:25 and to kill x86 we need all of that on arm 2021-03-31 10:02:36 JuniorJPDJ: hmm, you are kidding, aren't you 2021-03-31 10:06:46 JuniorJPDJ: first serious nail in intel coffin is apple M1 2021-03-31 10:07:16 yup, thats first 2021-03-31 10:07:22 and far from killing 2021-03-31 10:07:25 though Fujitsu Fugaku is also 'interesting' 2021-03-31 10:07:40 I of course would like to see x86 being finally killed 2021-03-31 10:08:15 hehe, and IBM as collateral damage ;> 2021-03-31 10:10:34 actually, intel is dead, just waiting for funeral ritual and place on cemetery 2021-03-31 10:12:11 intel? yes 2021-03-31 10:12:15 x86? i dont think so ;/ 2021-03-31 10:12:29 AMD rekt them, Apple added their kick 2021-03-31 10:14:49 yes, cpus will be around as service parts for long time 2021-03-31 11:14:22 ncopa: I know you just made new releases for openssl, but does the BB CVE warant another release? 2021-03-31 11:22:40 craftyguy: what's your requirement? 2021-03-31 11:24:47 ikke: i think it does 2021-03-31 11:30:08 2 curl CVE's 2021-03-31 11:33:13 humpf. edk2 is broken. pkgver say 0.0.202102 but it has a _realver=201908 2021-03-31 11:36:27 ncopa: yes, sorry for mess 2021-03-31 11:37:13 I created new MR in hope that someone who knows python will help to fix this 2021-03-31 11:38:24 or, is it good idea to simply revert it to previous state, if it builds on current edge 2021-03-31 11:38:37 but i think it will 2021-03-31 11:54:24 this test fail for libbsd https://gitlab.freedesktop.org/libbsd/libbsd/-/blob/master/test/fpurge.c 2021-03-31 11:54:38 my C knowledge is very shallow so I don't get it 2021-03-31 11:57:33 my ale drinking neovim is smarter than me and says "Variable has incomplete type 'FILE'" on line 32 2021-03-31 11:58:30 is this a test that should be patched or removed? 2021-03-31 12:00:30 from an avr libc doc: "FILE is the opaque structure that is passed around between the various standard IO functions." 2021-03-31 12:00:57 the opaque means that you can only have a pointer to it 2021-03-31 12:01:24 I'd just ignore that test to be honest 2021-03-31 12:05:00 the commit that introduced the test in libbsd seems to be from 6y ago though https://gitlab.freedesktop.org/libbsd/libbsd/-/commit/cfb4d462a9be19c1dfd5e7793ea267a0bb111a11 2021-03-31 12:22:37 yeah 2021-03-31 12:23:07 omni: just disable the test, it's undefined behavior 2021-03-31 12:23:47 they wanted an easy way to have a "zeroed out" FILE struct, for some reason 2021-03-31 12:24:08 ok, thanks ericonr & afontain_ 2021-03-31 12:26:37 invalid tests are such a time waste 2021-03-31 12:26:47 what could a zeroed out FILE possibly be useful for?? 2021-03-31 12:27:45 remove lines 32, 38, and 39. they're extremely invalid UB 2021-03-31 12:28:31 so are 35 and 36 2021-03-31 12:28:43 basically the whole file is invalid 2021-03-31 12:28:50 except the /dev/zero fp part 2021-03-31 12:28:53 :D 2021-03-31 12:29:09 why line 38 UB? 2021-03-31 12:29:14 *is 2021-03-31 12:29:37 ah, wait, I didn't look at the same revision 2021-03-31 12:30:42 it's passing a pointer not obtained by fopen or another stdio function that makes FILE* handles to a stdio function 2021-03-31 12:32:02 I didn't know fread(NULL) was UB, but I guess it's never specified 2021-03-31 12:43:35 well you can't fopen(NULL, ...) either 2021-03-31 12:44:14 in general NULL is not an "optional" in C 2021-03-31 12:44:49 you can use it as one, but it's just a specific invalid pointer that doesn't compare equal to any valid one 2021-03-31 12:50:00 finally! !18785 2021-03-31 13:43:18 arguments against $pkgname in source url? 2021-03-31 13:43:25 more convenient copypastry? 2021-03-31 13:44:30 ACTION is wondering as well 2021-03-31 13:44:30 And that while pkgname/upstream name doesn't have to match 2021-03-31 13:44:40 E.g. py3-somepackage 2021-03-31 13:45:05 And if upstream changes the package name we may want to keep the old name 2021-03-31 13:45:49 right. i find it really annoying for c&p 2021-03-31 13:48:17 Yesterday, a fix went in for 3.13,3.12 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19932 to fix a security vulnerability around Busybox.  Can someone advise on when that will be available as a docker file :latest ?  (i.e. docker pull alpine:latest ) 2021-03-31 13:49:48 Uhm, I'm re-enabling a package for arches where it was disabled first, and now CI is failing on it because the packages already exists in some other arches...? 2021-03-31 13:50:04 Of course it already exists on those other arches, it wasn't disabled there... 2021-03-31 13:50:52 armv7 and x86 specifically, it succeeds fine for e.g. x86_64 where it already exists too 2021-03-31 13:52:20 Ok what the hell and now the builders fail on a package that just compiled fine in CI 2021-03-31 13:57:01 wasm't animatch already enabled on all archs at !14569? 2021-03-31 13:57:29 https://pkgs.alpinelinux.org/packages?name=animatch&branch=edge 2021-03-31 14:00:23 Hi PureTryOut[m], is your comment related to  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19932 to fix a security vulnerability around Busybox. 2021-03-31 14:00:57 omni: the package existed in the binary repos, but it was disabled in the APKBUILDs 2021-03-31 14:01:08 Kevin21: no 2021-03-31 14:06:00 PureTryOut[m]2: but unrelated to animatch, allegro fail to build for x86 and armv7 in !19224 pipelines 2021-03-31 14:06:55 They succeeded in the 3rd to last pipeline though. And with the later ones only animatch seemed to fail 2021-03-31 14:07:11 Oh nvm that was me being blind 2021-03-31 14:07:17 It was actually allegro failing 🤔 2021-03-31 14:07:27 the eyes is where it happens first 2021-03-31 14:07:46 Still, I'm unsure why it succeeded on the 3rd to last pipeline 2021-03-31 14:07:52 yes 2021-03-31 14:08:23 Anyways I disabled the packages on those arches so builders are clear again and made an upstream issue for it 2021-03-31 14:08:32 I cared more about aarch64 with this anyway 2021-03-31 14:10:24 for some reason it said "No packages dound to be built." for the jobs that succeeded for armv7 and x86 2021-03-31 14:10:36 *found 2021-03-31 14:10:40 Huh... 2021-03-31 14:11:48 don't be blinded by green check marks ;) 2021-03-31 14:12:01 Ha indeed 2021-03-31 14:25:04 PureTryOut[m]2: did you bump pkgrel? 2021-03-31 14:25:19 Of what? 2021-03-31 14:25:49 the package you enabled arches for 2021-03-31 14:26:14 No as that is not necessary 2021-03-31 14:52:07 PureTryOut[m]2: I've tried to skim through to find where things may have changed at their end related to the 32bit arch issue https://github.com/liballeg/allegro5/compare/5.2.6.0...5.2.7.0 2021-03-31 14:54:22 Don't worry about, it's not much of a problem. I mainly care about the 64-bit arches for this package, specifically aarch64, and that one is re-enabled now so I'm happy 2021-03-31 14:54:37 huh, fcolista is not here 2021-03-31 14:55:05 huh, huh, merge conflict with prspkt pus 2021-03-31 14:55:19 push* 2021-03-31 14:56:26 interesting that I made fix with same commit msg as prspkt but prspkt was few seconds faster to push it :) 2021-03-31 14:56:40 testing/srain 2021-03-31 15:02:29 PureTryOut[m]2: my completionist side want everything to be available on all archs ;) 2021-03-31 15:02:43 Ha good luck with that 2021-03-31 15:03:18 wat, you mean no intel-ucode for ppc64le? 2021-03-31 15:14:16 Lol 2021-03-31 15:14:29 Inb4 Intel starts making PowerPC processors 2021-03-31 15:15:33 hah, yet another nail 2021-03-31 15:38:36 i think im gonna tag stable releases now due to the busybox thing 2021-03-31 15:39:26 thank you for fixing it nmeum and ikke 2021-03-31 15:39:35 ncopa: nice 2021-03-31 15:40:28 was fixedin all stable branches, right? 2021-03-31 15:40:59 yes 2021-03-31 15:41:28 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12566 2021-03-31 15:43:03 awesome! thanks! 2021-03-31 15:44:23 builders are building synapse 2021-03-31 15:44:55 i wonder if we can hold pushes to stable branches for an hour or so? 2021-03-31 15:45:23 ack 2021-03-31 15:45:28 Going to bike, so fine with me :) 2021-03-31 15:48:33 skarnet: to have a flag like RC_REBOOT, so init scripts in the shutdown runlevel can figure out if the system is really rebooting 2021-03-31 15:49:42 RC_REBOOT is a var set by openrc-init, so it's not available on alpine.. 2021-03-31 16:00:26 the problem is that there's such a thing as a shutdown runlevel 2021-03-31 16:01:05 that "runlevel" is a legacy from the sysvinit model, a wart 2021-03-31 16:03:03 just thing about what "init scripts in the shutdown runlevel" could possibly mean 2021-03-31 16:05:07 for specific actions that need to be taken when rebooting, we'll have a system in place that tells you whether you're halting/rebooting/powering off 2021-03-31 16:05:36 but it definitely shouldn't be handled by openrc or by a service manager in general, it should be pure distro policy :) 2021-03-31 16:33:50 can someone please help me review https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.13.4-released.md 2021-03-31 16:34:19 and https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.10.8-3.11.10-3.12.6-released.md 2021-03-31 16:35:56 Looks good 2021-03-31 16:36:02 +1 2021-03-31 16:45:46 thanks 2021-03-31 16:46:05 just waiting for mips64 to finish its build so i can push the 3.13.4 tag 2021-03-31 17:21:48 ok, releases finally done. thank you everyone! 2021-03-31 17:25:06 thank you! 2021-03-31 18:04:05 thanks! 2021-03-31 20:15:12 Hi ncopa ... thanks again for the security update for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19932   When I look at the versions which have been updated via https://github.com/docker-library/official-images/commit/18cbc2e17bec1e909e6284960af2499403e79322   the builds do not seem to include linux/amd64 architecture. 2021-03-31 20:15:12 This being for 3.13.4 ,  3.12.6 , 3.11.10  3.10.8  I base this on looking at https://hub.docker.com/_/alpine/?tab=tags&page=1&ordering=last_updated  tags .... none of them contain linux/amd64 with the security fix?   Am I missing something or will this architecture get built later? 2021-03-31 20:43:01 I think I see them all? 2021-03-31 20:43:41 any chance this could get reviewed soon? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/19934 2021-03-31 20:49:36 craftyguy: looks fine, i merged it 2021-03-31 20:49:45 Ariadne: thanks! 2021-03-31 20:53:02 sqlite> select * from vulnerability where cve_id='CVE-2021-28831'; 2021-03-31 20:53:03 2494|CVE-2021-28831|decompress_gunzip.c in BusyBox through 1.32.1 mishandles the error bit on the huft_build result pointer, with a resultant invalid free or segmentation fault, via malformed gzip data.|7.5|CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 2021-03-31 20:53:04 :) 2021-03-31 20:57:12 heh 2021-03-31 20:58:22 don't worry it uses sqlalchemy 2021-03-31 20:58:30 and thus can use a better DB than sqlite :P 2021-03-31 21:00:21 lol 2021-03-31 21:02:19 my intention is to have the vulnerability tracker open issues instead of the current bot 2021-03-31 21:02:30 so that it knows what issue IDs are linked to vulnerabilities 2021-03-31 21:02:36 but thats way off :P 2021-03-31 21:05:40 Who controls that bot? 2021-03-31 21:05:56 i have no idea 2021-03-31 21:06:06 i thought you knew 2021-03-31 21:06:07 :D 2021-03-31 21:06:26 heh, maybe ncopa 2021-03-31 21:06:29 is it a bot? 2021-03-31 21:06:36 I have no clue 2021-03-31 21:06:37 i mean, i don't think it is some person manually opening these 2021-03-31 21:06:47 i hope not anyway 2021-03-31 21:07:20 well, that is another reason i am working on this :P 2021-03-31 21:07:34 once this is done, the infra team will have full control over the security pipeline 2021-03-31 21:07:36 :) 2021-03-31 21:09:11 What is used as source? 2021-03-31 21:09:20 for the vulnerabilities 2021-03-31 21:10:07 the NVD feed 2021-03-31 21:10:15 What I do notice is that the issues are often a couple of days later than the CVE anouncement 2021-03-31 21:10:18 we can teach it how to consume other feeds 2021-03-31 21:10:22 yep 2021-03-31 21:10:24 this will be 2021-03-31 21:10:26 real time 2021-03-31 21:10:26 :) 2021-03-31 21:10:36 well near real time 2021-03-31 21:10:39 hourly cron 2021-03-31 21:10:54 quick enough 2021-03-31 21:21:41 this nn, I presume, will also patch & merge, yes? 2021-03-31 21:28:48 omni: that seems like an AI hard problem :) 2021-03-31 22:05:49 (= 2021-03-31 22:06:00 AI is only hard if you think about it 2021-03-31 22:07:29 it's worth investigating 2021-03-31 22:07:38 i dont have high confidence in a success rate though 2021-03-31 23:52:30 is aarch64 CI stuck?