2021-02-01 05:17:58 1c0fcac07a24822236eeb72ce521e19d49cdddd1 2021-02-01 05:19:20 498c9d1a9d87af66f3cd46d74d40ac1c17e276a8 2021-02-01 05:21:18 ¯\_(ツ)_/¯ a merge commit has been pushed 2021-02-01 06:16:22 huh 2021-02-01 06:18:18 oh 2021-02-01 06:18:19 I see 2021-02-01 06:18:38 nick merged in origin/master into his merge commit 2021-02-01 06:20:35 merge reqyest& 2021-02-01 06:59:50 nice :) 2021-02-01 07:26:26 good monday morning! 2021-02-01 07:28:33 no such thing 2021-02-01 07:34:04 exactly :) 2021-02-01 07:34:31 good coffee, good brandy and somewhat fine tobacco and there _is_ good morning :) 2021-02-01 07:34:59 on any day, ofc 2021-02-01 07:35:48 im gonna make some good coffe, but i'll drop the rest 2021-02-01 07:36:44 I realized today that we build musl libc with -Os. I wonder if it would make sense to build it with -O2 2021-02-01 07:37:06 i thikn most packages in our repos would benefit from that 2021-02-01 07:37:40 without testing I doubt we could know 2021-02-01 07:38:09 and excesive testing 2021-02-01 07:40:15 first question, is the musl somewhere speed bottleneck 2021-02-01 07:40:50 i doubt it is *the* bottleneck anywhere 2021-02-01 07:41:02 I doubt it will solve python speed 2021-02-01 07:41:21 but i would guess it could give a few % performance increase for everything 2021-02-01 07:41:30 while only costing a few extra bytes 2021-02-01 07:42:19 yes, I'm not against, just contemplating aloud 2021-02-01 07:42:27 *nod* 2021-02-01 07:43:54 kernel is built with -O2, and this is good 2021-02-01 07:45:37 (early optimization is root of all evils (or similarly) :) ) 2021-02-01 07:46:35 yes, -Os is also optimization 2021-02-01 07:47:59 hmm, why there is no '-Oc' switch, i.e. optimize for correctness :) 2021-02-01 07:52:39 it's *supposed* to be the default 2021-02-01 07:56:16 only supposed 2021-02-01 10:55:13 mps: ok, thanks :) 2021-02-01 11:53:30 maxice8: re b1e81c8f8a404b1517477b9d00de43ad5844083f it was puched to 3.13-stable but not master? do we only want this package for 3.13 and not future alpine releases? 2021-02-01 11:53:44 s/puched/pushed/ 2021-02-01 11:53:44 ncopa meant to say: maxice8: re b1e81c8f8a404b1517477b9d00de43ad5844083f it was pushed to 3.13-stable but not master? do we only want this package for 3.13 and not future alpine releases? 2021-02-01 11:55:25 i suspect it was not intentional 2021-02-01 12:03:10 Could we do some corrective action regarding 1c0fcac07a24822236eeb72ce521e19d49cdddd1 ? 2021-02-01 12:03:31 TBK[m]: we cannot rewrite history 2021-02-01 12:03:42 (not without causing a lot of issues) 2021-02-01 12:03:51 :/ 2021-02-01 12:06:30 we could and should be more careful when merging 2021-02-01 12:06:59 I'm thinking about writing CI jobs to check for those kinds of things 2021-02-01 12:36:16 Can we make it so that if a certain part of the CI job fails the MR can't be merged? 2021-02-01 12:40:13 Cogitri: yes, there is an option 2021-02-01 12:40:15 but.. 2021-02-01 12:40:30 that also forces you to wait for the pipeline to succeed before you can merge 2021-02-01 12:40:41 after every rebase 2021-02-01 12:41:14 Hm yes, but checking that there's no merge commit should be pretty quick 2021-02-01 12:41:24 I guess it might be problematic if there's no free runner around 2021-02-01 12:42:06 It's not for that check 2021-02-01 12:42:11 It keeps getting more and more annoying there there's no `rebase and merge` button with Gitlab :/ 2021-02-01 12:42:16 The entire build must be finished 2021-02-01 12:42:32 so after a rebase -> wait until build finished 2021-02-01 12:43:35 Oh, that's unfortunate 2021-02-01 12:43:47 I thought it would be possible to only depend on one stage too 2021-02-01 12:44:29 Yeah, having to wait for the entire build would be unfortunate, especially when everything that needs a bit more RAM/time to build fails on CI 2021-02-01 12:44:53 Would a pre-receive hook or something like that work to check that there's no merge commit? 2021-02-01 12:45:05 https://ibb.co/pRLq52m 2021-02-01 13:03:50 ncopa: no, klin was meant for master, I just pushed to the wrong branch 2021-02-01 13:04:00 I was having problem with my `gbr` being "special" 2021-02-01 13:10:58 there is 'merge immediately' option 2021-02-01 13:12:37 so no need to wait full build after 'rebase', I use that often 2021-02-01 13:13:04 mps: yes, but after we enable that option, I don't think you can do that anymore 2021-02-01 13:13:32 which option? 2021-02-01 13:37:52 The one in the screenshot I showed 2021-02-01 13:38:07 The one Cogitri asked about 2021-02-01 13:40:26 ikke: I see 2021-02-01 13:40:48 thanks for showing picture 2021-02-01 15:11:12 One day GitLab will add a rebase_and_merge button like GitHub has 2021-02-01 16:55:20 setuptools removed the bootstrap script 2021-02-01 16:55:27 now they need a pep517 compliant builder 2021-02-01 16:56:14 all need setuptools in directly or indirectly 2021-02-01 16:56:25 ¯\_(ツ)_/¯ python ecosystem 2021-02-01 16:56:47 What would the bootstrap script do? 2021-02-01 16:57:55 ie, what does this mean for us? 2021-02-01 16:58:22 it means we have a circular dependency if we want setuptools>=53.0.0 2021-02-01 16:58:40 ah, fun 2021-02-01 16:58:42 http://ix.io/2NZG 2021-02-01 16:59:05 setuptools depends on itself basically 2021-02-01 16:59:06 I wonder if we should --ensurepip on python3 and have a split setuptools/pip subpkg 2021-02-01 17:00:57 instead of separate aports 2021-02-01 19:09:55 linux-lts needs a bump to 5.10.12 on v3.13 2021-02-01 19:11:20 c705: I think ncopa waits a bit to see what results are on edge 2021-02-01 19:11:21 c705: no, it have xen bug 2021-02-01 19:11:30 .12 has the xen bug? 2021-02-01 19:11:35 wasn't .12 supposed to fix it? 2021-02-01 19:11:41 ^ 2021-02-01 19:11:53 ikke: this time I'm winner :) 2021-02-01 19:12:09 ikke: no, .12 don't have fixes 2021-02-01 19:12:25 mps: I was just reacting to you 2021-02-01 19:12:27 I think ncopa added patch in edge 2021-02-01 19:12:29 wasnt .12 patched by Alpine? 2021-02-01 19:12:56 MY-R: yes 2021-02-01 19:13:02 why does the kernel need patching for an xen bug. xen patched their software 2021-02-01 19:13:16 1507e2c675df7cdba2010f0ed2feb84134bd49e2 2021-02-01 19:14:09 https://lists.debian.org/debian-kernel/2021/01/msg00369.html 2021-02-01 19:14:43 https://lore.kernel.org/xen-devel/20210129005129.GA2452@mail-itl/T/#mc0a7e5fe1659826a5c755dd2f02f9987c2eb0f11 2021-02-01 19:16:05 ncopa: ping, should secfixes recognize GHSA ? 2021-02-01 19:16:11 GitHub Security Advisories 2021-02-01 19:17:19 oh no,yet another 2021-02-01 19:30:29 for what it's worth, CVE-2021-3347 affects 5.10.11 with a local priv escalation, so whether or not 5.10.12 is affected by another bug, this should be patched ASAp 2021-02-01 19:36:26 https://gitlab.alpinelinux.org/alpine/aports/-/commit/ec2640ace7628d7ee40959e5be3e63d0c1bda09e 2021-02-01 19:37:22 thank you 2021-02-01 19:38:12 seems like it's only i edge so far 2021-02-01 19:38:16 in* 2021-02-01 19:38:37 right, I think this should be pushed for 3.13 2021-02-01 19:49:41 I thought that had already happened, #12373 2021-02-01 19:51:23 apparantely not 2021-02-01 19:51:39 if there's a mr, it hasn't cleared yet 2021-02-01 20:33:47 can we 'mention' user who is registered on gitlab.a.o but user is not developer? 2021-02-01 20:34:12 yes, it just doesn't autocomplete 2021-02-01 20:34:14 algitbot: do you know what is g.a.o 2021-02-01 20:35:05 Hello71: so just type as '@username' 2021-02-01 20:35:11 yes 2021-02-01 20:35:17 thanks 2021-02-02 07:19:51 morning 2021-02-02 07:21:48 i pushed 5.10.12 kernel + xen fix to 3.13-stable 2021-02-02 07:24:10 maxice8: do we need support GHSA? look slike each GHSA also has a CVE https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories#cve-identification-numbers 2021-02-02 07:55:30 I'm strongly against !17699 even when BDFL is for enabling this 2021-02-02 07:56:16 reasoning for this is very weak, imo 2021-02-02 07:57:34 mostly around 'false sense of security' 2021-02-02 07:58:37 (and don't like to write comments in MR, it is 'cumbersome' to me) 2021-02-02 08:05:01 I've noticed Arch Linux did this as well 2021-02-02 08:07:25 ikke: yet another distro in bandwagon called 'sense of security' :) 2021-02-02 08:09:30 alpine was (small, simple) secure for years without this. what is changed now 2021-02-02 08:12:22 maybe it is substitute for grsec ;) 2021-02-02 08:13:20 worst security is false sense of security 2021-02-02 10:02:46 how does it give a false sense of security? 2021-02-02 10:03:03 it just tries to reduce the info leak from kernel 2021-02-02 10:03:20 info leak that may be useful to exploit kernel vulns 2021-02-02 10:05:07 I highly doubt it will cover all leaks, but it raises the bar to exploit kernel vulns a bit 2021-02-02 10:05:22 and the cost for it is low 2021-02-02 10:06:49 because it is some kind of 'security by obscurity' 2021-02-02 10:07:50 and provokes normal user to use sudo/doas whenever want to see change kernel events 2021-02-02 10:08:55 or better yet, keep always console/terminal where root is logged in 2021-02-02 10:12:49 or you can do: echo ‘kernel.dmesg_restrict = 0’ >> /etc/sysctl.d/90-security.conf 2021-02-02 10:12:52 problem solved 2021-02-02 10:13:15 :) 2021-02-02 10:13:59 no, general idea is bad 2021-02-02 10:14:58 I don't think restricting dmesg access is a bad idea, we restrict access to stuff in /var/log too 2021-02-02 10:15:02 I can build my kernel always, and I mostly do for more than 25 years 2021-02-02 10:15:25 right, so it does not really matter what we do in linux-lts 2021-02-02 10:15:34 Cogitri: /var/log/ is different 'beast' 2021-02-02 10:16:53 i have always wanted alpine be "hardened" by default. you should not need to harden the install (eg disable things, stop unused services, remove unused things) 2021-02-02 10:16:57 /var/log files can and often contain security sensitive infos, while dmesg doesn't 2021-02-02 10:17:13 instead dont add/enable those things by default. if you need then you enable 2021-02-02 10:17:44 mps: so you don't think that exploiting kernel vulnerabilities is a real thing 2021-02-02 10:18:10 you dont think that kernel info leaks is a real thing 2021-02-02 10:18:14 ? 2021-02-02 10:18:17 do we want 'sense of security' or trying real security, which is imposible at the end 2021-02-02 10:19:00 exactly, but we add thin layers. each layer does not solve all the things, but in combination they are useful 2021-02-02 10:19:04 and that is yet another 'bikesheding' 2021-02-02 10:19:52 too much layers can also be bad for security 2021-02-02 10:20:20 what isn't "security by obscurity" if it's just a sudo/doas away? 2021-02-02 10:20:51 but ok, do what you want, I will not oppose change, but must say that it is something I think is useless 2021-02-02 10:20:59 but this isn't really about adding a protective thin layer of security, rather to remove some information availability by default 2021-02-02 10:21:02 mps: point taken 2021-02-02 10:21:30 otherwise I could agree that a countermeasure could introduce exploitable bugs 2021-02-02 10:24:27 is there a way for more fine grained control of this though? so that if it is on you could give a user/group access to dmesg without having to sudo/doas, instead of just giving access to everyone 2021-02-02 10:24:27 (and now I have to say my daughter that she must always prepend 'doas' to the dmesg when she ask me why something doesn't work) 2021-02-02 10:26:34 security is complex, but nowadays worse because marketers jumped in 2021-02-02 10:37:20 ah, setcap(8) https://bugs.archlinux.org/task/69168 2021-02-02 10:38:42 that seems quite reasonable, to let users in group wheel access dmesg without escalating privileges 2021-02-02 10:40:06 but probably also something for the admin of the system 2021-02-02 10:47:43 omni: at the end admin will have to do all tasks even reading and writing mails and remove 'normal' users from system 2021-02-02 10:49:05 I simply can't believe that very competent and knowledgeable people 'buy' that the dmesg is security hardening 2021-02-02 10:49:54 next are ip/ifconfig, route, lsblb, lsusb, lspci, lscpu ... 2021-02-02 10:50:09 lsblk* 2021-02-02 10:51:36 what I meant is that if dmesg access is restricted by default, it should be for the sysadm to choose to enable access to those in the wheel group without privilege escalation 2021-02-02 10:59:55 ncopa: I agree with mps that a layer of obscurity does nothing to enhance security 2021-02-02 11:00:07 it only makes life harder for whitehat people 2021-02-02 11:00:26 blackhat people will have the motivation and tools to go around it, easily 2021-02-02 11:05:57 I remember when Russel Cooker of debian security when he started to work on selinux for debian, gave me access to his boxes (about 15 years ago) to test and try to break it 2021-02-02 11:06:17 nothing was hidden or obscered 2021-02-02 11:06:27 obscured* 2021-02-02 11:08:43 and I had full selinux policies and rules 2021-02-02 11:24:58 to make it easier to focus on breaking selinux? 2021-02-02 11:32:14 to make it clear that the security of selinux is not in hiding the details 2021-02-02 11:34:08 right 2021-02-02 11:38:17 but if hiding details is "security by obscurity" isn't (K)ASLR just that? just at another level 2021-02-02 11:39:11 I don't think that's about hiding information. 2021-02-02 11:39:43 It's about making it harder to abuse executing code at known addresses 2021-02-02 11:45:44 because you're hiding information by making addresses location less known, is what I try to argue 2021-02-02 11:47:22 but yes, you're moving information location instead of just not providing access to the information 2021-02-02 11:47:55 It's more about predictability (making it less predictable 2021-02-02 11:48:20 obscuring 2021-02-02 11:48:23 The implementation is known 2021-02-02 11:49:08 In the same vain I can argue cryptography is about obscuring details 2021-02-02 11:49:28 yes 2021-02-02 11:49:43 so, kaslr kind of depends on a secret, otherwise it is useless 2021-02-02 11:50:07 comparing fkn dmesg to cryptography 2021-02-02 11:50:15 haha 2021-02-02 11:50:24 how much further can you reach? :P 2021-02-02 11:50:26 skarnet: I'm not 2021-02-02 11:50:55 that wasn't really... it just felt so black & white, the reasoning 2021-02-02 11:50:56 problem is that dmesg may expose pointer values which can be used to go around kaslr 2021-02-02 11:51:05 K/ASLR is not obscurity but randomization 2021-02-02 11:51:19 then mayyybe the kernel shouldn't publish that information? 2021-02-02 11:51:30 exactly 2021-02-02 11:51:46 but there is a history of info leaks in the kernel 2021-02-02 11:52:05 the randimization is based on a secret random base value 2021-02-02 11:52:13 if you know that secret its useless 2021-02-02 11:52:32 now, if kaslr is a good idea is completely other discussion 2021-02-02 11:52:43 well it's really a question of kernel policy 2021-02-02 11:52:58 is the kernel log supposed to contain private security information or not? 2021-02-02 11:53:09 because there's useful public info in the kernel log 2021-02-02 11:53:16 so it's annoying to have to make it private 2021-02-02 11:53:28 K/ASLR is not 'silver bullet' ofc, as there are no 'silver bullets' 2021-02-02 11:53:35 ideally there would be two logging channels: one with the secret stuff and one with the public stuff 2021-02-02 11:53:54 ncopa: Is this more what you had in mind for parsing APKINDEX files in go? https://tpaste.us/nWRx 2021-02-02 11:54:03 I think it's an issue for the kernel devs 2021-02-02 11:54:16 skarnet: I agree 2021-02-02 11:54:23 kaslr is an expesive feature that provides limited value 2021-02-02 11:54:39 for userspace aslr the history is different 2021-02-02 11:54:54 its still limited value, but for userspace its cheap 2021-02-02 11:55:12 stack protector (canaries) also 2021-02-02 11:55:48 yeah, the value of kaslr is completely orthogonal to the question of what kind of information should and should not appear in the kernel log 2021-02-02 11:55:59 something have to be 'traded' 2021-02-02 11:56:32 if user apps needs the info from kernel log is other discussion. I'd think in most cases they dont 2021-02-02 11:56:46 i completely understand that it is handy for a desktop user 2021-02-02 11:57:01 for a server admin as well 2021-02-02 11:57:09 i plug the usb stick and what know what sdX it gets 2021-02-02 11:57:14 dmesg tells me that 2021-02-02 11:57:18 nod 2021-02-02 11:57:54 heh, two days ago I just searched for "Machine Model" in /proc and /sys and couldn't find, only can use it by grep 'dmesg' out 2021-02-02 11:58:28 so i think in those cases it makes sense to allow dmesg on system level via sysctl 2021-02-02 11:58:36 and that was for setting some awesome wm startup params 2021-02-02 11:58:40 i mean, its configurable 2021-02-02 12:53:29 mps: so what is your opinion on grsec 2021-02-02 12:53:44 notwithstanding its current availability 2021-02-02 12:54:38 grsec is also "unnecessary layer". I think kernel copied dmesg restrict from them 2021-02-02 12:57:01 Hello71: tbh I'm not sure what I think about it. on one side it is good for some things without doubt but on other side it is not panacea 2021-02-02 12:57:36 ncopa: watch -d lsblk? 2021-02-02 12:58:06 or cat /proc/partitions 2021-02-02 12:58:19 Hello71: do you know for 'LIDS' (Linux Intrusion and Detection (sub)System) 2021-02-02 13:02:59 disabling dmesg for users on machine which have intel ME, apple T2, arm64 with Cortex M4 inside is 'strange' idea to me 2021-02-02 13:18:23 different threat model 2021-02-02 13:19:38 it's like saying "why do you lock the door in hurricane country" 2021-02-02 13:32:54 CLIP OS discuss CONFIG_RANGOMIZE_BASE=y and motivate with "CLIP OS follows the defense in depth principle and an attack surface reduction approach" here https://docs.clip-os.org/clipos/kernel.html#configuration 2021-02-02 13:34:03 > While this may be seen as a controversial feature, it makes sense for CLIP OS. 2021-02-02 13:34:10 it doesn't make sense for Alpine 2021-02-02 13:34:51 moreover, there are generic bypasses floating around 2021-02-02 13:48:12 mps: more than 20 years old? 2021-02-02 13:50:14 Hello71: who? 2021-02-02 13:50:28 lids 2021-02-02 13:50:31 or better what 2021-02-02 13:50:55 well, about, I forgot exact date 2021-02-02 13:51:32 In the past we have had the discussion on supporting multi version of linux kernel in a single Alpine host. Was that declined, or it is still on the roadmap no one has time to do it ? 2021-02-02 13:51:56 I used LIDS some time before grsec appeared 2021-02-02 13:52:50 tmhoang: you can have it by adding linux-edge, though not yet on s390x 2021-02-02 13:53:18 tmhoang: I think the problem with having support for multi versions is that we'd need to have some way of purging old kernels 2021-02-02 13:53:34 Since you can't manage them with apk (then apk would purge old versions automatically) 2021-02-02 13:53:55 And leaving them unmanaged isn't great either since that'd fill up your disk 2021-02-02 13:54:26 So IMHO we'd need some sort of trigger that keeps `n` kernels around and automatically deletes old kernels upon upgrading the kernel or smth like that 2021-02-02 13:54:56 we could have a trigger script in linux-lts ? 2021-02-02 13:55:06 I'm asking for all arches in general 2021-02-02 13:55:24 yeah apk awareness seems to be a thing 2021-02-02 13:57:50 so 3 things to do : 1. apk awareness 2. trigger script in linux-lts 3. build-system awareness to have multiple versions of linux-lts 2021-02-02 14:03:03 and also backport/patching previous non-latest kernels too - that might be a burden 2021-02-02 14:05:59 well this would only be supported for new alpine releases 2021-02-02 14:06:25 it introduces new points of failure as well as some new behavior (increased disk usage if nothing else) 2021-02-02 14:06:53 unless you mean security patching kernels, which is definitely not in-scope 2021-02-02 14:12:10 Yes, increased disk usage would be a disadvantage, but probably worth it so upgrading kernel doesn't risk breaking the boot of a system 2021-02-02 14:12:17 Most distributions just leave the old kernels hanging around, and leave it up to the user to purge 2021-02-02 14:12:50 Ubuntu and Debian are only keeping two kernels I think 2021-02-02 14:13:10 if so then that changed recently 2021-02-02 14:13:34 iirc ubuntu/debian leave everything, and remove up to current/last kernel on apt-get autoremove 2021-02-02 14:13:41 ^ yes 2021-02-02 14:13:43 my bad 2021-02-02 14:14:09 void just leaves everything, and removes up to current on vkpurge 2021-02-02 14:14:34 according to https://askubuntu.com/questions/2793/how-do-i-remove-old-kernel-versions-to-clean-up-the-boot-menu in 16.04+ apt autoremove does the needful 2021-02-02 14:15:32 it doesn't seem like debian has this functionality 2021-02-02 14:15:35 rhel/centos used to auto-removes up to current-2 or so, in a mostly sensible way 2021-02-02 15:14:02 i think it makes sense to keep old kernel til new kernel successfully booted 2021-02-02 15:19:04 i think there are several use cases here 2021-02-02 16:54:26 ncopa: I think the problem is what you define as "successful boot" 2021-02-02 16:55:49 Since you could be in a half-broken state because e.g. the network module of the new kernel is broken for you but now apk happily purged the old kernel and you can't download it again 2021-02-02 16:56:04 Although that probably won't happen often 2021-02-02 16:59:52 famous last words 2021-02-02 16:59:54 Or some modules not loading correctly. Or trying to start VMs crashing the entire box hard. 2021-02-02 17:00:52 keep 2 kernels, but not more 2021-02-02 17:01:01 (that happened to centos in the early days of firmware backports for various speculative execution CVEs, but _only_ on older hardware) 2021-02-02 17:01:31 Current + two older kernels seems to be the sweet spot yes 2021-02-02 17:06:33 TBK[m]: mumble on 3.13 is broken 2021-02-02 17:11:00 looks like something is wrong with openssl in 3.13, I can't access some sites with browsers (even curl) but on 3.12 everything works fine 2021-02-02 17:11:36 can someone on 3.13 check https://www.perl.com 2021-02-02 17:13:07 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.perl.com:443 2021-02-02 17:13:32 right that 2021-02-02 17:13:45 on 3.12-stable it works 2021-02-02 17:18:26 in docker or no? 2021-02-02 17:18:35 I tried it in docker 2021-02-02 17:18:46 could it be just broken seccomp again? 2021-02-02 17:18:47 doesn't work on gentoo either 2021-02-02 17:18:55 dalias: I ran it with --privileged, same issue 2021-02-02 17:18:56 probably they deployed some shitty waf 2021-02-02 17:18:58 strace and see which syscall it's complaining about 2021-02-02 17:19:08 dalias: was stracing it, but could not see anything 2021-02-02 17:19:53 the SSL_ERROR_SYSCALL is EOF 2021-02-02 17:20:12 remote sends FIN 2021-02-02 17:20:25 SSL_ERROR_SYSCALL seems to be a misnomer 2021-02-02 17:20:40 yeah supposedly it's what happens when remote gives eof 2021-02-02 17:20:49 can you try 3.12 again 2021-02-02 17:20:53 but why is this being treated as error? 2021-02-02 17:21:26 well the connection is gone, what do you want it to do 2021-02-02 17:24:05 https://www.perl.com doesn't work on 3.12.3 either 2021-02-02 17:24:13 looks to me like the website is just down 2021-02-02 17:24:30 An error occurred during a connection to www.perl.com. PR_END_OF_FILE_ERROR 2021-02-02 17:24:32 yup 2021-02-02 17:24:53 Hello71: I see now that it doesn't work with curl and w3m but works with firefox on 3.12 2021-02-02 17:25:01 mps: https? 2021-02-02 17:25:08 yes 2021-02-02 17:25:19 It does not work for me on Archlinux either 2021-02-02 17:26:09 ssl error in links from gentoo and same error like above in firefox too 2021-02-02 17:26:55 ikke: sorry, it is perl.org not com on 3.12 2021-02-02 17:27:19 FF switched it 2021-02-02 17:27:23 yeah, perl.org works, perl.com not 2021-02-02 17:28:41 https://www.slashgear.com/perl-com-domain-for-programming-language-hijacked-tied-to-malware-actors-01657515/ 2021-02-02 17:29:51 ah, bad 2021-02-02 17:29:58 thanks for url 2021-02-02 17:31:38 the part about malware is probably crap 2021-02-02 17:31:47 it's just expired and autoparked 2021-02-02 17:32:35 parking services usually have the worst ads that nobody else wants, so it's not surprising that occasionally they come with viruses 2021-02-02 17:45:36 mps: so which else sites you couldnt open? (excluding "malicious" perl one) :D 2021-02-02 17:51:18 something similar happened about week or two ago but I forgot because was not important to me 2021-02-02 17:51:56 maybe I can find in browser history, if I didn't deleted browsing history in meantime 2021-02-02 17:53:26 mps: don't bother, I thought you got there some bigger list of them :) 2021-02-02 18:11:28 MY-R: no, not much and now I think that perl.com is only one which I had this problem, other failed probably for different reasons but I can't remember now 2021-02-02 18:13:13 understood :) 2021-02-02 18:35:30 heh 2021-02-02 18:35:46 the murmur backport didn't take into account that 3.13 didn't recieve the previous broken patch :D 2021-02-02 18:36:04 ha 2021-02-02 18:36:17 should be fixed now 2021-02-02 18:36:18 hopefully 2021-02-02 18:39:15 :D 2021-02-02 18:46:45 I didn't test it personally 2021-02-02 18:57:29 for anyone interested in this looks like perl.com have new site https://perldotcom.perl.org/ 2021-02-02 18:58:40 maxice8: thanks! working too on 3.13 :) 2021-02-02 18:59:55 mps: like they couldnt just make com.perl.org :D 2021-02-02 19:00:02 lol 2021-02-02 19:00:14 com.perl.www 2021-02-02 19:00:20 :D 2021-02-02 19:01:56 perl.com.perl.org would be nice 2021-02-02 19:05:21 py3-sly with the BSD-1-Clause license 2021-02-02 20:00:30 20:52 user1 │ hi, the alpine-rpi-3.13.1-aarch64.tar.gz.asc file is empty, is it supposed to be? 2021-02-02 20:02:19 ikke: ^ something to debug? :D 2021-02-02 20:06:22 MY-R: that's something ncopa has to fix 2021-02-02 20:28:57 Maxice8 have I picked the wrong licence for oy3-sly? 2021-02-02 20:29:14 s/oy3/py3/ 2021-02-02 20:29:14 adhawkins meant to say: Maxice8 have I picked the wrong licence for py3-sly? 2021-02-02 20:29:38 yes 2021-02-02 20:29:59 Apologies, which should it be? 2021-02-02 20:31:18 BSD-3-Clause 2021-02-02 20:32:05 I'll sort it now. 2021-02-02 20:32:45 I sorted it before merging 2021-02-02 20:34:05 Oh, did you? Thanks. I'll try to work out the difference and how to tell which is which. 2021-02-02 20:37:38 there is a project called licensechecker that compiles to a static binary you can use 2021-02-02 20:37:46 it is hit-and-miss I don't know how to use it exactly 2021-02-02 20:38:14 but if you run it over LICENSE files it is decent at telling the BSD-[0-9]-Clause licenses apart 2021-02-02 20:39:05 https://github.com/boyter/lc 2021-02-02 21:38:58 I'll give that a go, thanks maxice8 2021-02-02 21:43:36 That reckons it should be BSD-3-Clause-Attribution maxice8. Comments? I don't know whether it's right or wrong :) 2021-02-02 21:45:51 But then it guesses emborg as being GPL-3.0-only, whereas setup.py specifically says 'or later' 2021-02-02 21:47:26 test! 2021-02-02 21:48:15 Works FeelingLUKS-y :) 2021-02-02 21:49:40 came here to ask about grub2 luks2 but it appears that the grub package has been updated since that support was added. the LVM on LUKS article is out of date, it appears. 2021-02-02 21:49:48 since it mentions grub not supporting luks2 2021-02-02 21:50:29 Can't help with that I'm afraid. Stick around though, someone may answer. 2021-02-02 21:53:11 yeah, the wiki is always outdated 2021-02-02 21:53:26 ask in ##alpine-linux 2021-02-02 21:53:49 grub 2.04 doesnt have luks2 support 2021-02-02 21:59:33 ah cripes 2021-02-03 01:52:40 Cogitri: https://gitlab.alpinelinux.org/alpine/aports/-/commit/bec5aa9b41a#8ea798ba1c0243a76c58a0b90f89662a3749fcdb_100_100 what happened here? 2021-02-03 01:53:21 i think we actually need to backport the revert part of https://gitlab.alpinelinux.org/alpine/aports/-/commit/d7a1300f153f8171a60c4fc9633f5b36f4f806dd to 3.13 2021-02-03 01:53:39 Hello71: cogitri lives in Central Europe 2021-02-03 01:53:45 mmhmm 2021-02-03 01:53:58 <[[sroracle]]> presumably they will see that message eventually 2021-02-03 01:54:18 yes, in around 4 hours 2021-02-03 01:54:39 better to leave a comment on the commit so he receives an email 2021-02-03 01:56:34 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17774 2021-02-03 01:58:32 actually, hm... 2021-02-03 01:58:57 seems like you actually put that there, maxice8 2021-02-03 01:59:19 at https://gitlab.alpinelinux.org/alpine/aports/-/commit/653fa49568caedccb992c0fd89c6497b6a683576 2021-02-03 02:00:12 put what ? the --sysconfdir line ? 2021-02-03 02:01:04 hmm... was this line always wrong? 2021-02-03 02:03:16 oh ye after that switch to meson my mouse started randomly lag first time since decade when I was using all cores on some slower machine :P 2021-02-03 02:04:21 huh, has alpine xorg really been looking in /etc/X11/X11 all this time 2021-02-03 02:04:52 is that a reason why I couldnt set up rootless xorg with startx? 2021-02-03 02:05:35 huh 2021-02-03 02:05:39 sounds like a yes 2021-02-03 02:06:02 so it is really ncopa's fault! 2021-02-03 02:06:22 https://gitlab.alpinelinux.org/alpine/aports/-/commit/7999ab637b2621022594cdc8951f45715a097ad8 originally added xorg-server 2021-02-03 02:06:28 with --sysconfdir=/etc/X11 2021-02-03 02:06:53 was the autoconf one also wrong ? 2021-02-03 02:07:00 or it was just lost in the autoconf->meson transition ? 2021-02-03 02:07:02 i think so. still checking but pretty sure 2021-02-03 02:07:06 ah ye cus it didnt read those wrapper scripts in /etc/X11 where I was setting "needs_root_rights" 2021-02-03 02:07:15 but it seems that we were saved by xorg checking in /etc/X11 always 2021-02-03 02:07:43 only some other scripts, such as xorg.wrap, checked only in @sysconfdir@/X11 2021-02-03 02:08:11 yup 2021-02-03 02:08:23 looking at arch linux PKGBUILD before meson 2021-02-03 02:08:27 --sysconfdir=/etc 2021-02-03 02:08:34 :D 2021-02-03 02:09:13 this "always check /etc/X11" apparently predates sysconfdir, at least in xorg-server 2021-02-03 02:09:33 fun 2021-02-03 02:11:10 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/31 2021-02-03 02:11:13 closed my MR 2021-02-03 02:13:15 nice 2021-02-03 02:13:36 less auto* the better 😎 2021-02-03 02:33:36 maxice8: having just walked in, I thought you were talking about C's `auto` keyword 2021-02-03 02:33:49 (which is well-known for defining cars in C) 2021-02-03 02:33:56 maxice8: and I was going to disagree 2021-02-03 02:34:05 less C the better too 😎 2021-02-03 02:34:11 lol 2021-02-03 02:34:21 maxice8: well, I'm happy to agree on autohell being a BadThing™ 2021-02-03 02:34:25 but, personally, I like C 2021-02-03 02:34:42 (though, I get the distinct impression that Gustedt is going to ruin C2x enough that I'll probably stick with C18) 2021-02-03 02:46:28 why do you say that? 2021-02-03 02:46:47 i haven't been following, but if you see things that are really bad i'll be happy to raise concerns with him 2021-02-03 02:49:57 dalias: namely, the grafting of as many C++ features as possible into C 2021-02-03 02:50:41 well can you name some specific ones? 2021-02-03 02:50:54 to be fair, I don't actually blame Jens for this eventuality (though, they've made lots of the proposals that bother me), I blame the committee for adopting a charter that aims to minimize differences with C++ 2021-02-03 02:51:02 dalias: shall we bring this to PM? 2021-02-03 02:51:39 i have way too many windows open. if you really insist ok but if it's short here is probably ok, or #musl 2021-02-03 02:51:57 it's fine (I just don't want to flame or anything) 2021-02-03 02:54:48 dalias: the adoption of a brand new syntax for attributes lifted from C++ (rather than using either _Pragma or introducing _Attribute which would be far more C)) 2021-02-03 02:55:21 dalias: let me go fetch some more specific examples 2021-02-03 02:56:05 dalias: essentially everything about the defer mechanism (e.g., no cancellation tokens, function-scoping rather than block-scoping, etc.) 2021-02-03 02:56:51 dalias: having a common C/C++ specification at all 2021-02-03 02:59:18 attribute is completely a non-issue. it's syntax and has no bearing on any important costs (runtime, complexity, ...) 2021-02-03 02:59:38 the defer stuff has some good parts but it's bad by being overpowered 2021-02-03 02:59:41 dalias: making `auto` work like in C++ 2021-02-03 02:59:44 it should be stripped down to a subset of it 2021-02-03 02:59:55 dalias: lambdas 2021-02-03 03:00:22 auto is just an ugly weaker __typeof__, no? 2021-02-03 03:00:30 also no relevant costs i'm aware of 2021-02-03 03:00:37 if you don't like it don't use it 2021-02-03 03:00:55 not sure about lambdas and how they'd be done 2021-02-03 03:01:12 dalias: there's no way they could possibly be done without introducing some version of name mangling 2021-02-03 03:01:20 ? 2021-02-03 03:01:33 dalias: functions in C compile to plain symbols (e.g., in ELF) 2021-02-03 03:01:45 i don't follow. lambdas don't have names 2021-02-03 03:01:52 no, but they are functions 2021-02-03 03:01:53 at least as i understand them 2021-02-03 03:01:57 so? 2021-02-03 03:02:09 and, in order to be callable objects, they'd need to be compiled down to some target, right? 2021-02-03 03:02:14 so, they'll be given some kind of name 2021-02-03 03:02:26 no, not any more than a ipa-constprop 2021-02-03 03:02:31 no, not any more than a ipa-constprop'd static function "has a name" 2021-02-03 03:02:37 it's not linkage 2021-02-03 03:02:39 not familiar with that 2021-02-03 03:02:52 it's and address evaluated locally at the point of use 2021-02-03 03:02:59 that has no bearing on linkage/abi 2021-02-03 03:03:23 overall, I'm entirely against C becoming, in any way at all even a little bit, more compatible or similar to C++ 2021-02-03 03:03:33 i share the sentiment that the c++ stuff is junk 2021-02-03 03:03:51 the vast majority of what I've read Jens proposing falls into that category 2021-02-03 03:04:05 (e.g., nullptr, though I think that might, on very rare occasion actually be useful) 2021-02-03 03:04:16 but aside from defer being slightly overpowered (more than just syntactic sugar in place of explicit cleanup calls/gotos in the right places) they seem mostly harmless 2021-02-03 03:04:55 dalias: I rather disagree, but to each their own, I suppose 2021-02-03 03:04:58 ACTION sticks with C18 2021-02-03 03:05:36 i mean they make no imposition on the library/runtime/translation architecture 2021-02-03 03:05:55 not that it's not harmful to use them in your programs 2021-02-03 03:06:41 aside from gratuitously breaking auto (which no one used or even remembered for decades anyway) c18 programs should be perfectly valid c2x programs 2021-02-03 03:07:01 funnily enough, I've personally used `auto` to specifically disallow the code from compiling with a C++ compiler 2021-02-03 03:07:08 :) 2021-02-03 03:07:10 it's a FeatureNotaBug™ 2021-02-03 03:07:18 int new; does that just as well 2021-02-03 03:08:28 I should learn enough template programming to write a program that will attempt to delete the compiler that's being run and add it to the top of all my C programs 2021-02-03 03:08:30 … 2021-02-03 03:10:46 that can't be done 2021-02-03 03:10:58 at that rate you might as well just write #ifdef __cplusplus 2021-02-03 03:11:00 short of exploiting a bug in the compiler 2021-02-03 03:11:19 dalias: quitter talk 2021-02-03 03:11:29 Hello71: not exactly punitive 2021-02-03 03:11:30 ☺ 2021-02-03 03:11:36 regardless, don't mind me 2021-02-03 03:11:59 the place where the compiler lives is outside the model of compile-time execution 2021-02-03 07:09:42 good morning 2021-02-03 07:10:16 Morning 2021-02-03 07:10:41 Hello71: Yes, I think that change was required since Xorg looked in /etc/X11/X11 2021-02-03 07:10:58 Ideally I would've included that in the commit message though 2021-02-03 07:11:18 if you are fixing the xorg-server's --sysconfig=/etc/X11 in 3.13, then I suggest that you also create a symlink: ln -s . /etc/X11/X11 2021-02-03 07:11:36 just in case 2021-02-03 07:11:46 not in edge, only in stable branch 2021-02-03 07:12:39 That was change a few months ago already 2021-02-03 07:12:55 So I'm not sure if it makes sense adding it anymore 2021-02-03 07:13:27 halosghost: everything have its rise and fall, so will C 2021-02-03 07:13:58 the /etc/X11/X11 is in stable branch already, right? 2021-02-03 07:14:05 mps: that's fine; can I have something that's even remotely as nice in its place? 2021-02-03 07:14:20 so far, the only contender that is even in the same ballpark is Zig afaict 2021-02-03 07:14:25 and it's dramatically more complex 2021-02-03 07:14:38 people, other apps may have worked around it and may have put things in /etc/X11/X11 already, removing will make those "workarounds" break 2021-02-03 07:16:39 halosghost: I doubt anything, programmers do not have (yet) sanskrit (samskrta) which means finished/completed and no more changes 2021-02-03 07:16:45 Yes, I think it makes sense adding the symlink, but if we did break anything then it has been broken for months now 2021-02-03 07:16:59 should've added that symlink directly 2021-02-03 07:17:19 I don't have /etc/X11/X11 and never seen it 2021-02-03 07:17:45 mps: ☹ 2021-02-03 07:18:50 halosghost: also about zig, it will be 'easier' for programmers but I doubt it will be better than C 2021-02-03 07:19:15 mps: yeah… we'll see. I can imagine it being nicer in a lot of ways 2021-02-03 07:19:35 but… right now, I'm curmudgeonly sticking with C18 2021-02-03 07:20:21 in a last about two-three years I only 'program' (huh) in shell :) 2021-02-03 07:20:50 most of my coding is in C# these days for $DAYJOB 2021-02-03 07:20:51 Btw, does Zig have a default async runtime? Curious how they're doing it 2021-02-03 07:21:07 Cogitri: async/await have been merged 2021-02-03 07:21:32 Cogitri: I can't tell you much of the particulars, but from the little I've read, it seems cleaner than every other version of async I've ever seen 2021-02-03 07:21:56 (namely, you can use the exact same error-handling mechanics in async code (and across async boundaries) as you do with synchronous code) 2021-02-03 07:21:58 Yup, it's nice that it's colourless 2021-02-03 07:22:32 Was curious if they have some sort of mainloop&scheduler on the std to queue and unqueue futures 2021-02-03 07:22:36 mps: but, I would happily switch C# for F#, Haskell, C, lua, or posix sh 2021-02-03 07:23:04 Right now I only really use GLib things with Rust or Vala where async is pretty neat too fortunately 2021-02-03 07:23:36 I've never really found myself in need of async in C 2021-02-03 07:24:02 and I'm still a bit dubious about async/await as a construct in general 2021-02-03 07:24:24 Anything that has a GUI isn't fun when blocking for IO 2021-02-03 07:24:53 Cogitri: one of many reasons I don't do GUI programming :P 2021-02-03 07:25:03 though, if libui ever gets reasonably stable, that might change my mind 2021-02-03 07:25:05 Cogitri: yes, just wanted to write this, but you are done already 2021-02-03 07:25:50 any GUI/TUI programming without some 'async' is cumbersome 2021-02-03 07:26:56 Yup, without nice async support it's either slow or a callback hell 2021-02-03 07:27:33 I don't disagree on that point at all 2021-02-03 07:27:50 but async/await (the construct) is… strange 2021-02-03 07:28:03 and it encourages some coding practices that I generally disagree with 2021-02-03 07:29:53 ugh; I deeply wish libui would become stable 2021-02-03 07:29:59 I'd love that 2021-02-03 07:30:11 I'm starting to like channels/fibers 2021-02-03 07:30:23 mps: ever looked into libdill/libmill? 2021-02-03 07:30:38 no, don't know what is it 2021-02-03 07:30:53 mps: http://libdill.org/ 2021-02-03 07:31:19 mps: an idiomatically-C go-esque concurrency library 2021-02-03 07:31:41 thanks, opened tab in FF and will try to read after coffee and breakfast 2021-02-03 07:31:45 👍 2021-02-03 07:32:07 (libmill is libdill's predecessor; it's much more go-like rather than coherently C) 2021-02-03 07:32:14 (but it is still available) 2021-02-03 07:33:54 aha, coroutines 2021-02-03 07:33:54 (I've never really had a ton of use for concurrency, but libdill has always been my candidate should I need it) 2021-02-03 07:34:02 indeed 2021-02-03 07:34:46 C-oroutines :) 2021-02-03 07:34:54 ACTION slow-claps 2021-02-03 07:48:21 Maxice8 Did you see my message about py3-sly licence? That utility suggested it should be BSD-3-Clause-Attribution. Any thoughts? 2021-02-03 07:52:20 fwiw they're probably asleep right now, it's like 5am for them 2021-02-03 08:08:42 Ah ok. He has been active since I sent it last night, so just thought I'd check. Didn't necessarily expect an instant response :) 2021-02-03 08:27:29 i've been looking at python a bit this morning 2021-02-03 08:27:53 and have been trying to define the -gnu problem 2021-02-03 08:29:05 the problem is that cpython's configure.ac script will generate a PLATFORM_TRIPLET based on gcc defines 2021-02-03 08:29:25 and will genereate x86_64-linux-gnu if defined(__linux__) 2021-02-03 08:30:15 as far I can see, this is used by LIBPL, the directory where embedded python config is found 2021-02-03 08:30:27 and also by SOABI 2021-02-03 08:30:44 which is used for the suffix for python modules with C code 2021-02-03 08:31:40 $ python3 -c 'import sysconfig; print(sysconfig.get_config_var(" 2021-02-03 08:31:40 SOABI"))' 2021-02-03 08:31:40 cpython-38-x86_64-linux-gnu 2021-02-03 08:32:07 this is identical with glibc 2021-02-03 08:32:19 on alpine linux it does not matter that much. things works 2021-02-03 08:32:22 the modules are found 2021-02-03 08:32:41 however, this is also used by the pip wheel modules 2021-02-03 08:32:58 which means that there is no way to differ between glibc and musl modules 2021-02-03 08:33:41 i think it would be more correct if python used x86_64-linux-musl instead 2021-02-03 08:34:44 this should be fixed in the python's configure.ac script 2021-02-03 08:35:10 which currently just adds -gnu when __linux__ is defined 2021-02-03 08:36:15 the problem now is: how do we report this upstream? and how do we fix it? 2021-02-03 08:36:38 do we wait for upstream to come up with a solution, or do we simply set it hard, ourselves 2021-02-03 08:37:10 we could use the last component from gcc -dumpmachine 2021-02-03 08:37:14 $ gcc -dumpmachine 2021-02-03 08:37:14 x86_64-alpine-linux-musl 2021-02-03 09:27:05 Filed bug upstream: https://bugs.python.org/issue43112 2021-02-03 10:39:15 It has a response already 2021-02-03 13:05:19 ncopa: i'm not that familiar with apk, but i think the symlink will only fix cases where someone has scripts writing in /etc/X11/X11; if they have regular files there, they won't be fixed 2021-02-03 13:05:38 imo it's good enough to write it in release notes 2021-02-03 13:14:40 also, if you're still around, why do we put those rpi files in boot/boot anyways? why don't we just mount boot partition to /boot like other distros 2021-02-03 13:15:03 boot/boot? 2021-02-03 13:15:53 looks like they are in /boo/ https://pkgs.alpinelinux.org/contents?branch=edge&name=linux-rpi&arch=aarch64&repo=main 2021-02-03 13:16:36 same with bootloader: https://pkgs.alpinelinux.org/contents?branch=edge&name=raspberrypi-bootloader&arch=armhf&repo=main 2021-02-03 13:16:41 let me reword: why is there a boot directory on the boot partition 2021-02-03 13:16:52 where? 2021-02-03 13:17:06 for rpi, when you unpack the tar, it has a directory called "boot" 2021-02-03 13:17:24 using raspbian there is no such directory 2021-02-03 13:17:51 this is the "cause" of #12368 2021-02-03 13:18:39 you mean the kernel itself 2021-02-03 13:19:02 not sure what you mean by that 2021-02-03 13:19:09 boot/vmlinuz-rpi 2021-02-03 13:19:42 $ curl --silent https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/aarch64/alpine-rpi-3.13.1-aarch64.tar.gz | tar -zt ./boot | tpaste 2021-02-03 13:19:42 https://tpaste.us/d5Ry 2021-02-03 13:20:16 because there is where we put things on all other alpine release medias 2021-02-03 13:20:35 and there is where modloop is expected to be found 2021-02-03 13:21:08 i suppose we can move the kernel and initramfs to the top level 2021-02-03 13:21:48 im not going to be able to look at that today 2021-02-03 13:21:49 sorry 2021-02-03 13:22:35 ok, np. this is really an rpi firmware issue, but i'm just wondering why we do it differently from other distros (and if we can change it to work around the issue) 2021-02-03 13:23:22 i think we can change that. is the issue reported to the upstream firmware provider? I understand it is closed source 2021-02-03 13:24:05 in #12368, i linked my upstream issue https://github.com/raspberrypi/firmware/issues/1529 2021-02-03 15:17:12 PureTryOut[m]: I created https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17791 to fix the broken links in lua-luaxml 2021-02-03 15:17:28 since I own the two packages that depend on it :) 2021-02-03 15:18:13 I don't maintain that package but nice 2021-02-03 15:18:18 Maybe you can download the sources from luarocks? 2021-02-03 15:20:11 Didn't figure out how to use https://luarocks.org/manifests/djerius/luaxml-130610-1.src.rock as the source 2021-02-03 15:22:07 Ah, no clue either. A quick grep reveals no package so far downloading from that website so I guess no luck 2021-02-03 15:24:08 \o/ 2021-02-03 15:24:28 Hm, that should have been a 2021-02-03 15:24:37 🤷‍♂️ 2021-02-03 15:45:08 but algitbot won't shrug with you 2021-02-03 15:50:12 currently opened 666 issues 2021-02-03 15:50:30 coincidence or something else :) 2021-02-03 15:50:37 That's it, no more opening or closing bugs from now on! 2021-02-03 15:53:39 sign of 'Alpine Apocalypse' ;) 2021-02-03 16:15:05 Fun, `abuild rootbld` is failing on a local package for me without giving any indication as to why 2021-02-03 16:16:18 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/sNCQMGyLuPFNdqiAFPxPMhbc/message.txt > 2021-02-03 16:16:19 Log ^ 2021-02-03 16:17:42 i'd be inclined to say that "Unpacking /var/cache/distfiles/jellyfin-v10.6.4.tar.gz" failed 2021-02-03 16:17:53 or your build commands 2021-02-03 16:18:28 It didn't even get to my build command. And why would unpacking a regular tar file fail...? 2021-02-03 16:19:36 Actually, nvm it does get to my build function and something in there is failing without being obvious as to why 2021-02-03 16:19:44 ACTION debugs 2021-02-03 16:30:29 cmd || { echo BOOOOO; exit 1; } 2021-02-03 16:47:51 my favorite way of debugging 2021-02-03 16:49:20 sh -x is pretty neat 2021-02-03 16:55:36 maxice8: dare we merge !17783? 2021-02-03 17:03:34 It will be fun to see what breaks 2021-02-03 17:18:51 Tested the stuff that broke last time? 2021-02-03 17:30:39 I made sure everything that depends on vulkan-headers has been rebuilt once. I haven't actually tried running any of those applications though 2021-02-03 18:43:02 merge 2021-02-03 19:15:59 ACTION <3 'lab ci trace build-x86_64' 2021-02-03 19:29:46 :-) 2021-02-03 23:21:04 huh, why GKH releases new kernels when I'm preparing for bed :) 5.10.13 with xen fixes just released 2021-02-03 23:22:56 and Im just finishing compile 5.4.94... ehhh 2021-02-03 23:23:27 thanks Greg, I just spent a day porting stuff to 5.10.12 2021-02-03 23:24:55 too many things touching "drm" stuff in 5.10.x ... 2021-02-03 23:27:07 I will upgrade linux-edge tomorrow, after few glasses of wine i fear I could make breakage 2021-02-03 23:28:50 wine didnt give you more courage? :D 2021-02-03 23:29:35 MY-R: :D 2021-02-03 23:32:15 ;) 2021-02-03 23:45:58 MY-R: you provoked me to push it :) 2021-02-03 23:47:49 it running on builders, hope it will be on mirrors in about half an hour 2021-02-03 23:48:06 MY-R: enjoy and good night :) 2021-02-03 23:52:46 mps: heh, thanks, good night! :) 2021-02-04 01:00:02 maxice8: looks like "tor" is broken after upgrade on 3.13 from logs last message is: [notice] Starting with guard context "default" 2021-02-04 01:00:19 if compare previous version log then only that in new version is new: 2021-02-04 01:00:21 [notice] We compiled with OpenSSL 1010109f: OpenSSL 1.1.1i 8 Dec 2020 and we are running with OpenSSL 1010109f: 1.1.1i. These two versions should be binary compatible. 2021-02-04 01:02:03 hmm 2021-02-04 01:02:17 I'll revert for now 2021-02-04 01:02:30 sure 2021-02-04 01:09:56 maxice8: ah, full logs if you want: https://tpaste.us/qgR9 2021-02-04 01:27:47 smells like dns problems or something 2021-02-04 01:28:29 maxice8: looks like false alarm, I reboot rpi4 and now working fine... what the hell, I didnt do anything on that machine 2021-02-04 01:28:39 Hello71: everything was working fine 2021-02-04 01:28:48 exept tor after upgrade... 2021-02-04 01:29:07 checked on edge and working fine too, sorry for noise maxice8 2021-02-04 01:29:09 or could be clock problems 2021-02-04 01:29:17 can't say without more info 2021-02-04 01:29:24 Hello71: doubt, got rtc there and running chrony 2021-02-04 01:29:41 syslog confusion with backwards time step? idk 2021-02-04 01:35:31 dunno, mystery for me, rpi reboot was in Feb 01 and since that didnt touch anything except that tor upgrade minutes ago 2021-02-04 01:35:31 Hello71: was working fine for you? :) 2021-02-04 01:35:31 i have tor relays but not using alpine tor package 2021-02-04 01:35:31 dunno, mystery for me, rpi reboot was in Feb 01 and since that didnt touch anything except that tor upgrade minutes ago 2021-02-04 01:35:31 oh, ok 2021-02-04 01:35:31 also not using alpine kernel 2021-02-04 01:36:20 so i don't think my experience is representative of stock 2021-02-04 01:36:47 damn, now I will be pedantic and do reboots after upgrades like in windows probably.... 2021-02-04 01:38:21 didnt see anything in logs before, dns for sure was working and clock was correct, restarted/stop/start etc tor multiple times before I wrote that it didnt work for me 2021-02-04 01:39:46 whatever, systems/programs hate me lately :\ 2021-02-04 01:40:24 hardware issue? 2021-02-04 01:42:54 nah, this night was kernel... after downgrade to 5.4 all working great again 2021-02-04 02:01:25 so tor is actually working ? 2021-02-04 02:02:26 maxice8: yes yes, sorry! 2021-02-04 02:03:49 edge and 3.13, I already tested... 2021-02-04 09:16:25 it's confusing that disabled targets are setup and report with success 2021-02-04 11:28:08 adding 'xvfb-run' to checkdepends and running xvfb-run in check() resulted in "xvfb-run: not found", how should this be done? 2021-02-04 11:28:45 Should just work 2021-02-04 11:28:57 yea 2021-02-04 11:29:05 Take a look at e.g. community/geary/APKBUILD for an example 2021-02-04 11:29:26 Did you make sure the dependencies were installed again after you added xvfb-run to checkdepends? 2021-02-04 11:31:53 ikke: xvfb-run does not show up in the "Installing.." part 2021-02-04 11:31:58 https://gitlab.alpinelinux.org/ay/aports/-/jobs/312222 2021-02-04 11:32:52 Cogitri: yup, that's what I thought, I did a grep -r 'xvfb-run' on the entire aport, seems the only difference is some of them added ibus as well, doesn't appear to be the key tho. 2021-02-04 11:33:18 alexy: I see the checkdepends as a suggestion, did you actually commit and push that already? 2021-02-04 11:34:11 ikke: let me double check. (by the way it failed locally as well, exact same error, I thought the build server may be set up differently so I tried pushing it anyway. 2021-02-04 11:34:55 alexy: yeah, you did not add the checkdepends yet 2021-02-04 11:35:16 idde: well what do you know, the checkdepend line is NOT there. 2021-02-04 11:35:23 :) 2021-02-04 11:36:04 ikke: just had a push origin pull commit rebase push nightmare ;0 2021-02-04 11:43:18 Nice, one of the xorg server test passed with xvfb-run, however ClipboardGroup.ms_clip_convert still segfaulted, I assume 'ms' means microsoft here ;) 2021-02-04 11:45:20 alexy: my first thought when saw ms in your msg :) 2021-02-04 11:46:53 mps: not fixing that crap :) 2021-02-04 11:53:21 "build succesfully" 2021-02-04 11:53:39 finally, had a long day, shower + bed time :) 2021-02-04 11:55:18 thank you everyone 2021-02-04 11:58:54 builds sure do take a long time for target armv7... 2021-02-04 11:59:50 btw, how does builds for armhf work? I see that they're not set up and run (at least for what I'm working on) 2021-02-04 12:00:03 We do not have CI for armhf 2021-02-04 12:00:09 check 2021-02-04 12:00:10 but we do have a builder 2021-02-04 12:00:24 But everything runs on aarch64 hardware 2021-02-04 12:01:14 ah, hm, I thought armv7 was emulated 2021-02-04 12:01:41 virtualized, not emulated 2021-02-04 12:01:48 for CI at least 2021-02-04 12:02:01 perhaps that's why I got an error for a test for target armv7? 2021-02-04 12:02:02 the builder runs on aarch64 baremetal in 32-bits mode 2021-02-04 12:02:08 ah, ok 2021-02-04 12:02:10 no then 2021-02-04 12:04:30 but still, why would armv7 be so much slower than aarch64? 2021-02-04 12:04:37 on CI? 2021-02-04 12:04:45 yes 2021-02-04 12:05:53 The host is a lot more busy 2021-02-04 12:07:07 The host runs armv7, armhf and armv7 ci 2021-02-04 12:07:51 so I'm just lucky with the aarch64 builds? 2021-02-04 12:10:24 "Getting source from Git repository" took 00:15 for aarch64 and 16:42 for armv7 2021-02-04 13:10:32 ikke: heh, now I think I get it, aarch64 has its own host and the others share a similar one? 2021-02-04 13:13:37 is this the reason as to why there is no CI for armhf? 2021-02-04 13:14:02 We don't have the HW 2021-02-04 13:17:19 ah, but you use the aarch64 host in armv7 mode to build for armhf? 2021-02-04 13:18:42 hmm.. I have barely a clue at all in this area.. 2021-02-04 13:26:09 armhf is armv7 with hardware floating-point extension? 2021-02-04 13:53:41 do you erally think that updating checksum format (Adding newlines) is worth it? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/73#note_140108 2021-02-04 13:54:21 maybe it a little better, but is it worth the annoyance in the migration period? 2021-02-04 13:54:55 It's nice that the `sha512="` doesn't show up in the diff any more, but the migration period does seem rather annoying 2021-02-04 13:55:15 ollieparanoid[m]:^ 2021-02-04 13:55:48 ACTION shakes head 2021-02-04 14:02:44 the feedback was positive back then: https://lists.alpinelinux.org/~alpine/devel/%3C20200606162435.b7woeh4d7jw6vcgy%40wolfsden.cz%3E 2021-02-04 14:04:07 :) 2021-02-04 14:05:34 we don't need 'sha512=' prefix, that's all :D 2021-02-04 14:07:53 but I can change my opinion, and say "don't fix something which is not broken" 2021-02-04 14:07:54 the shell needs it 2021-02-04 14:08:36 mps: we do that all the time 2021-02-04 14:09:05 ikke: what? we fix non-broken things? 2021-02-04 14:09:25 Yes 2021-02-04 14:09:39 aha, *nod* 2021-02-04 16:08:04 visually broken ;) 2021-02-04 16:09:29 but why not slowly move in that direction? try to remember to do that at every APKBUILD update until eventually it's like that 2021-02-04 16:10:37 but that's instead of that MR, I guess 2021-02-04 16:19:55 (I'm not too familiar with abuild yet) 2021-02-04 16:24:49 With this MR, every abump / abuild checksum will automatically use the new format 2021-02-05 02:44:49 Hello! I was trying to figure out the cause of a failed aports build and was wondering if anyone knows if the build system has internet access? the merge request is here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17397 2021-02-05 02:45:13 usually no. 2021-02-05 02:45:39 I mean, even if it does, it's a good idea to avoid such tests 2021-02-05 02:47:19 Right... Is running tests in general a good idea for aports or just submit a request disabling builds? I'm not real familiar with it 2021-02-05 02:47:49 I mean a request with the tests disabled 2021-02-05 02:51:04 the_count: tests are, generally speaking, preferred 2021-02-05 02:51:21 (that's part of the reason pyinstaller isn't in aports yet because its test suite relaly hates everything) 2021-02-05 02:51:24 the main thing is, how are people supposed to know it works, if they don't know how to use the application? 2021-02-05 02:51:29 so that's why tests are great 2021-02-05 02:51:38 sometimes this involves turning off some tests so they fit in the environment 2021-02-05 02:51:45 (some tests, like network stuff, either need to be adapted or turned off) 2021-02-05 02:52:01 I'm still really tempted to submit pyinstaller without tests 2021-02-05 02:52:08 because its test-suite is just so awfully maintained 2021-02-05 02:52:17 and takes literal hours to run 2021-02-05 02:52:19 -_- 2021-02-05 02:52:46 Ah... That makes sense, thank you for the info! 2021-02-05 02:52:58 i mean in that case, i wouldn't wait for the test suite 2021-02-05 02:53:06 it's of no use to anyone running it if it's that fragile 2021-02-05 02:53:12 plus it's time-consuming for little gain 2021-02-05 02:54:09 sam_: I don't disagree, but I was strongly urged to not just disable it 2021-02-05 02:54:14 we'll see 2021-02-05 02:54:29 the number of spoons I have available right now at all is very minimal because $DAYJOB is kind of sucking my life right now 2021-02-05 02:54:39 (it's slated to get better in March) 2021-02-05 02:54:54 so, perhaps in March, I'll have the spoons to resubmit pyinstaller to aports 2021-02-05 02:54:58 I'd love to get it integrated 2021-02-05 02:55:18 ACTION really likes pyinstaller 2021-02-05 02:55:46 lol 2021-02-05 02:56:52 hg: I think that's fair 2021-02-05 02:57:12 I just mean, there's a difference between "I really tried and upstream use the tests for their purposes" and "it doesn't work" ;) 2021-02-05 02:57:22 yeah 2021-02-05 02:57:33 I even went to their channel and waited days for a response but never got one 2021-02-05 02:58:07 I'm feeling like I've done an adequate job of attempting to use the tests 2021-02-05 03:09:58 I don't want to sound entitled as a user of an open-source project, but I agree with sam_; I'm not really sure what the value of such a test suite is… 2021-02-05 03:12:49 let me give the perspective I have, I merge a lot of user contributions in gentoo and I do package testing 2021-02-05 03:13:11 ultimately a test suite is only useful if it can give me a ~good idea if a package will work on an architecture 2021-02-05 03:13:29 some packages have test suites that take hours and hours to run and often hang, we play whack-a-mole skipping tests and sometimes that works out 2021-02-05 03:13:39 other test suites are made by upstream for them and they don't care if it fails for others 2021-02-05 03:13:57 at a point, you kind of have to call it and say "we'll turn off tests" or "we'll run a (sometimes very) limited subset of them" 2021-02-05 03:14:05 yeh 2021-02-05 03:14:17 I totally hear that 2021-02-05 03:14:30 so while I don't know how lenient the alpine merge folks are, if you explain that you've really tried and upstream don't care and it's fragile, i suspect you will be fine 2021-02-05 03:14:37 in that case, i'd be fine with it 2021-02-05 03:14:44 🤷 2021-02-05 03:14:50 we'll find out in March maybe ☺ 2021-02-05 03:14:54 :D 2021-02-05 03:15:13 I just love the idea of -bin python packages making it into aports 2021-02-05 03:15:21 mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 2021-02-05 03:15:44 lol, yeah 2021-02-05 03:19:13 -bin ? 2021-02-05 03:19:56 maxice8: that is, fully self-contained python packages; no dependency on a python interpreter installed system-wide 2021-02-05 03:20:12 sam_: Thanks for the insight, that's good to know 2021-02-05 03:20:41 maxice8: I use very few python things (namely, just youtube-dl); so, avoiding having a system-wide interpreter is a really nice thing for me 2021-02-05 03:21:07 so one interpreter per-package ? 2021-02-05 03:25:15 maxice8: yes, and if used normally, there's a small start-up performance penalty 2021-02-05 03:25:24 this probably doesn't make sense for most folk 2021-02-05 03:25:28 but I love it 2021-02-05 03:25:31 it doesn't yeah 2021-02-05 03:25:41 haha 2021-02-05 03:26:28 it probably only makes sense for folk like me: who use very few python things, and who really dislike increasing the number of full programming environments without very good reason 2021-02-05 03:26:41 which is why I'm not sure -bin python packages will ever make it into aports 2021-02-05 03:26:52 but, having pyinstaller in aports at least means making them locally is simpler :) 2021-02-05 03:28:59 there is a way to avoid the runtime cost, but then you still have python installed, it's just installed in a place that no one expects 2021-02-05 03:29:30 I'd much rather pay the small start-up cost and have python only even executable on my system specifically when it's running 2021-02-05 03:29:34 because I'm a crazy person 2021-02-05 03:37:55 the_count: no problem! 2021-02-05 03:41:55 maxice8: the other benefit, to be fair, is that it actually does a fabulous job of compression; for example, youtube-dl packaged with pyinstaller actually takes up less space than a regular python install 2021-02-05 03:42:07 so, for really space-conscious folk, it may also be of benefit 2021-02-05 07:19:54 morning ncopa 2021-02-05 07:23:04 morning 2021-02-05 07:24:08 re python 3.9, i think we just go ahead and patch the triplet in PLATFORM_TRIPLET to conatin -musl instead of -gnu. I think its the right thing to do 2021-02-05 07:24:20 sounds good 2021-02-05 07:26:51 i wonder if we should remove the *.pyc files? 2021-02-05 07:27:01 or maybe ship them in a separate subpackage? 2021-02-05 07:28:14 python3-bytecode with install_if="$pkgname=$pkgver-r$pkgrel python3-bytecode" 2021-02-05 07:28:26 then all python*- modules can also be split 2021-02-05 07:28:50 something like that yes 2021-02-05 07:29:01 but i wonder if its worth it? 2021-02-05 07:29:29 it just gives faster startups as i understand 2021-02-05 07:29:47 but i dont know how big the difference is 2021-02-05 07:34:34 eh 2021-02-05 07:35:03 find /usr/lib/python3.8 -iname '*.pyc' -exec du -ch '{}' + 2021-02-05 07:35:07 1.7M total 2021-02-05 07:36:30 du -ch /usr/lib/python3.8/**/*.pyc returns 22.9M total 2021-02-05 07:36:47 worth removing 2021-02-05 07:36:57 but is it worth create a subpackage of it? 2021-02-05 07:37:07 eh 2021-02-05 07:37:12 no as far as I'm aware 2021-02-05 07:38:33 ok, lets just purge those 2021-02-05 07:38:37 with 3.9 2021-02-05 07:38:46 also from all the modules ? 2021-02-05 07:38:59 probably also worth it 2021-02-05 07:39:12 lots of py3-* will need to be adjusted 2021-02-05 07:39:13 fun :D 2021-02-05 07:39:13 we should probably do it from abuild 2021-02-05 07:41:08 https://github.com/void-linux/void-packages/blob/master/common/hooks/post-install/02-remove-python-bytecode-files.sh 2021-02-05 07:42:23 :D abuild-hooks when ? 2021-02-05 08:37:04 should licence files be installed by the -doc package and not the package itself? 2021-02-05 09:18:19 hmm, there's a single udev rule I'd like to package, for a U2F/FIDO key thing (solokey), but it seems kinda silly to make a package just for that one file.. I couldn't find any obvious packages that were collections of related udev rules (like some distros have). should I give up on this idea or is making a package for this rule OK? 2021-02-05 09:19:55 libu2f-host already has udev rules related to u2f devices, maybe it makes sense to add it to that package 2021-02-05 09:20:25 ohh yeah, how did I not find that package earlier :/ 2021-02-05 09:21:11 Cogitri: thanks, I'll take a look 2021-02-05 09:23:07 you know, maybe I should package the solokey cli tool and put the rule in with that 2021-02-05 09:23:27 it would be useful to have that tool for managing the device too 2021-02-05 10:45:20 omni: yes 2021-02-05 11:10:27 That licence utility you pointed to reckons py3-sly should be BSD-3-Clause-Attribution maxice8. Comments? I don't know whether it's right or wrong :) 2021-02-05 11:11:39 No clue im going to doctor rn 2021-02-05 11:16:53 Ok. Hope it's nothing serious maxice8. 2021-02-05 11:17:44 Monthly checkup 2021-02-05 11:18:06 adhawkins: check the license and compare it to the licenses found here: https://spdx.org/licenses/ 2021-02-05 11:19:32 craftyguy: without having had a closer look at it, wouldn't it be better to have it in libu2f-host and have solokey cli package depend on that? 2021-02-05 11:41:00 This is the licence ikke. 2021-02-05 11:41:20 Looks like a standard '3 clause' to me. Maybe the fact that he's edited it to include his name is confusing the tool? 2021-02-05 11:41:22 https://github.com/dabeaz/sly/blob/master/LICENSE 2021-02-05 11:43:24 adhawkins: probably 2021-02-05 11:43:51 And this: "Neither the name of the David Beazley" 2021-02-05 12:06:27 maxice8: thanks, and that also seem to be handled by subpackages="$pkgname-doc:doc" 2021-02-05 12:06:53 omni: :doc is redundant 2021-02-05 12:07:07 wah 2021-02-05 12:07:14 s/wah/ah/ 2021-02-05 12:07:15 omni meant to say: ah 2021-02-05 12:07:27 $pkgname-foo calls function foo 2021-02-05 12:07:35 kewl 2021-02-05 12:08:41 do I need to bump pkgrel if I just add docs? as in add subpackages="$pkgname-doc" and install lines for doc files to package() 2021-02-05 12:12:56 Yes 2021-02-05 12:13:14 Any change that changes the final output needs to bump pkgrel 2021-02-05 12:19:11 hg: that seems more due to filesystem overhead. does it do better than a compressed tar or squashfs? 2021-02-05 13:03:48 any suggestion how to handle a package now in testing that requires a new user/group but also changes to /etc/mdev.conf? I guess mdev.conf does not allow includes? 2021-02-05 13:06:22 indeed it doesn't 2021-02-05 13:06:55 create the user in pre-install and then nag the user in post-install to edit /etc/mdev.conf? or do we have a better solution? 2021-02-05 13:07:41 does Alpine have already existing packages that have to modify conf files on install? 2021-02-05 13:07:52 if so, you should do the same thing they're doing 2021-02-05 13:08:19 the thing that is most close to this is /etc/sudoders.d contibution from pkgs 2021-02-05 13:08:38 (that I can think of) 2021-02-05 13:08:59 maybe we should have a /etc/mdev.conf.d with a script that merges parts into /etc/mdev.conf 2021-02-05 13:09:26 yes a solution like that would be nice for doas as well 2021-02-05 13:10:30 on a related note, mdevd can now auto-coldplug, so it can be used as a 100% drop-in replacement to mdev -d :P 2021-02-05 13:11:49 does mdevd parse /etc/mdev.conf ? 2021-02-05 13:12:23 yes 2021-02-05 13:12:48 and it only does it once, unlike mdev that parses it for every event :P 2021-02-05 13:13:22 OK so there is a reload then, for the user to call after editing the config? 2021-02-05 13:13:29 sighup 2021-02-05 13:14:32 ok but no rc script that allows "service mdevd reload" I guess? 2021-02-05 13:15:23 well it's not exactly hard to write 2021-02-05 13:16:18 s6-svc -h, or whatever command openrc's supervision thing has to send a SIGHUP, if any, or kill -HUP `cat /run/mdevd.pid` 2021-02-05 13:19:28 sure but some software has more "funky" ways of how a reload is done, so its nice if there is an rc script that takes care of the correct reload mech 2021-02-05 13:21:56 yeah, but mdevd is as traditional as you will get ;) 2021-02-05 13:22:04 :-) 2021-02-05 13:23:29 so no "udevadm control --reload-rules; udevadm trigger" :-) 2021-02-05 13:24:39 no need! you have 'mdevd-coldplug' to manually perform a coldplug, but now mdevd has an option to do it automatically at start, for lazy people who want to drop it in as a mdev replacement without thinking about service ordering. 2021-02-05 13:25:58 https://skarnet.org/software/mdevd/ if you're interested in the details :) 2021-02-05 13:27:02 ok so to edit perms of a dev node from root:root to somehing else for an attached device, only edit mdev.conf and sighup to mdevd, and the dev node with ahve correct perms? 2021-02-05 13:27:41 no, the node perms will only be changed if the event happens again 2021-02-05 13:27:58 if the node has already been created with the wrong perms, you need to remove and replug your device 2021-02-05 13:28:11 if I'm not mistaken, this is true with every uevent manager 2021-02-05 13:29:31 Ok so a reboot then, as the device in this case is not unpluggable, or manual chown.... 2021-02-05 13:31:08 if you're going to add an unpluggable device, then yeah you should make sure the uevent manager is correctly configured *before* you do it, else you'll need to do stuff manually or reboot ^^ 2021-02-05 13:38:57 isn't there under /sys for some devices files which can be used for remove/add without physical touch of devices 2021-02-05 13:39:50 I remember I played this with some UAS devices but forgot details 2021-02-05 13:41:23 and I had idea to patch mdev to 'include' other configs but I doubt it will be accepted in alpine, upstream will not I'm sure 2021-02-05 13:41:37 there may be a trigger for a virtual replug, yes, but navigating /sys is a frolicking hike across a minefield 2021-02-05 13:42:25 no need to patch when you can cat /etc/mdev.conf.d/* > /etc/mdev.conf in the start script 2021-02-05 13:43:27 this is too simple for fame ;) 2021-02-05 13:43:39 why do you think I'm not famous 2021-02-05 13:43:49 :) 2021-02-05 13:44:09 I didn't meant about you but me 2021-02-05 13:44:26 yeah and my point is that nobody should do complex things for fame 2021-02-05 13:44:44 how can I become a half famous as you if I use shell script 2021-02-05 13:45:01 I want the sendmail authors' names to fall into oblivion forever 2021-02-05 13:45:11 ofc, it is not for fame but practical 2021-02-05 13:46:36 we can use 'cat ....' for everything but most servers have this included 2021-02-05 13:46:49 as much as I prefer configuration directories to files, and generally hate config files, I think the 'practical' thing is to use a shell one-liner over patching a daemon to add 'include' directives to its config file format 2021-02-05 13:47:50 ok, everyone have its POV 2021-02-05 13:48:00 if anything, patch it to be able to read its config from stdin, and pipe all the files into mdev's stdin 2021-02-05 13:48:32 lol, this is good one 2021-02-05 13:48:42 sorry, wrong channel 2021-02-05 13:48:59 you can already do this with mdevd: mdevd -f /dev/fd/0 2021-02-05 13:49:20 so you don't even have to have a mdev.conf file or a writable rootfs. :P 2021-02-05 13:50:26 I prefer mdev on machines which don't hotplug anything, i.e. everything is set on boot 2021-02-05 13:51:09 for those which are used as workstations mdevd is better 2021-02-05 13:51:24 these* 2021-02-05 13:52:00 there is exactly zero situation where mdev is better, but you could say I'm not impartial. :P 2021-02-05 13:52:31 minimal installation 2021-02-05 13:54:37 count the memory usage and say that again 2021-02-05 13:55:05 :] 2021-02-05 13:56:57 but fyi, I'm playing with mdevd + libudev-zero for my workstation 2021-02-05 14:09:17 yeah libudev-zero is cool :D 2021-02-05 14:20:17 maxice8: ok, I'll do it, but would such a change I described change the existing package? it does not include the files and there is no -doc package yet 2021-02-05 14:33:38 omni: did you read COMMITSTYLE.md, you MRs looks strange 2021-02-05 14:34:18 not sure if this because of GL or they don't have proper commit subject message 2021-02-05 14:35:14 mps: sorry, I forget myself, sometimes it's old habit and sometimes it's that I haven't done proper rtfm 2021-02-05 14:36:06 but please also specify in what way they look strange 2021-02-05 14:37:37 I don't see 'repo/pkgname: ........' 2021-02-05 14:38:32 but maybe GL messed it 2021-02-05 14:39:31 oh, no, that's me, I'll fix 2021-02-05 14:39:38 other small nitpick (which is sign of not reading COMMITSTYLE.md) is 'A' at the beginning 2021-02-05 14:39:59 use lower case whenever possible 2021-02-05 14:40:09 well, that was the obvious tell, wasn't it 2021-02-05 14:40:34 'read the docs' :) 2021-02-05 14:43:12 I did do it right earlier, just forgot, but should've been obvious just from looking at the other 2021-02-05 14:50:35 mps: that's better, right? 2021-02-05 15:03:51 omni: ofc 2021-02-05 15:06:15 hmm, we don't need standard license in files 2021-02-05 15:07:05 and 'subpackages="$pkgname-doc:doc"' looks wrong 2021-02-05 15:08:21 there is also CODINGSTYLE.md in aports 2021-02-05 15:14:10 btw, maxice8 made good 'plugins' for vim to work with aports 2021-02-05 15:31:28 is it the redundant "-doc:doc" that looks wrong? 2021-02-05 15:55:48 Hello71: I don't know 2021-02-05 15:56:00 Hello71: but it leverages UPX which may explain part of it 2021-02-05 15:59:18 upx isn't magic either, it just compresses gunzip myexe; chmod +x myexe; ./myexe into ./myexe 2021-02-05 16:00:38 strictly speaking packers are inherently less efficient than external compressors, if you don't count the external decompressor size 2021-02-05 16:01:09 and i think upx is primarily optimized for speed, not size 2021-02-05 16:02:51 mm 2021-02-05 16:06:57 why isn't it ok to have $pkgname in the source url? (even though that is stated as a question, I don't question the cuice, I'm just curious) 2021-02-05 16:07:42 (also thinking if it's ok or not to have $pkgname-pkgver in sha512sums) 2021-02-05 16:10:45 omni: yes '-doc:doc' doesn't look good 2021-02-05 16:14:20 when would you use :doc? (I caught it from someplace else) 2021-02-05 16:15:19 is community/maturin not built for x86? 2021-02-05 16:16:08 omni: more pkgs have -doc than doesn't 2021-02-05 16:16:50 this :doc must be somewhere which is special case 2021-02-05 16:17:05 or error 2021-02-05 16:23:45 what would be such a special case? 2021-02-05 16:24:28 I have no idea 2021-02-05 16:25:38 I see it only in community/openjdk7/APKBUILD: $pkgname-doc:doc" 2021-02-05 16:27:21 and looks like it should be removed? bratkartoffel ? 2021-02-05 16:28:10 also a couple of others, community/dub and community/bpftrace 2021-02-05 16:28:17 and in a couple of possibly "special cases" 2021-02-05 16:28:36 testing/podman, community/spacefm 2021-02-05 16:29:21 looks like bugs 2021-02-05 16:31:55 but someone who knows and understand abuild should answer 2021-02-05 16:37:35 omni: I looked at it earlier, libu2f-host is a tool specific to yubikey 2021-02-05 16:39:41 ok! 2021-02-05 17:19:34 mps: don't know about the doc-subpackage from openjdk7, but i guess it can be removed (without reading the whole scrollback) 2021-02-05 17:21:00 omni: when the subpackage name does not match the function name 2021-02-05 17:21:12 omni: $pkgname-bar:doc, for example 2021-02-05 17:21:22 which would run the 'doc' function for subpackage bar 2021-02-05 17:31:02 can we bump linux-lts to 5.10.13 2021-02-05 17:33:20 https://nvd.nist.gov/vuln/detail/CVE-2021-26708 2021-02-05 17:34:41 ikke: ok 2021-02-05 17:34:54 omni: so for most subpackages, it would not be necessary 2021-02-05 17:35:06 right 2021-02-05 17:35:18 omni: another case is when the subpackage name is an illegal function name 2021-02-05 17:35:22 $pkgname-foo-bar 2021-02-05 17:36:43 I see that I've been squashing upgrade commits for some of my MRs.. which is what you should do for "new aport" commits but, yeah.. =/ 2021-02-05 17:40:15 c705: it is already upgraded 2021-02-05 17:40:30 maybe builders or mirrors are stuck 2021-02-05 17:40:31 https://pkgs.alpinelinux.org/package/edge/main/x86_64/linux-lts 2021-02-05 17:41:01 https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=v3.13 2021-02-05 17:41:11 Ah, you want it backported 2021-02-05 17:41:44 i want the stable branch of alpine linux to have the stable build of linux, yes 2021-02-05 17:44:15 can I see if something is stuck at builders? like community/maturin missing for x86 2021-02-05 17:45:01 https://build.alpinelinux.org 2021-02-05 17:45:21 x86 is stuck on keepassxc 2021-02-05 17:46:10 ty 2021-02-05 22:09:28 Ikke: https://gitlab.alpinelinux.org/Leo/atools/-/merge_requests/41 2021-02-05 22:11:41 I wonder if we should match (github|gitlab) or just any URL that ends *.patch 2021-02-05 22:14:29 I suppose 2021-02-05 22:15:38 match any URL that ends with *.patch ? 2021-02-05 22:35:43 nod 2021-02-05 23:05:30 several flagged packages seem up-to-date 2021-02-05 23:36:23 <[[sroracle]]> maxice8: patch links to 2021-02-05 23:36:48 <[[sroracle]]> Specific commits (e.g. /user/project/commit/sha1.patch) is stable 2021-02-05 23:37:43 <[[sroracle]]> no more volatile than downloading tarballs from those sites (in fact it's usually LESS so...) 2021-02-05 23:42:26 We just had a situation where they were not 2021-02-06 03:32:26 Looks x86_64 builder hangs after running test on mopidy 2021-02-06 08:02:26 [[sroracle]]: THe index line is unstsable 2021-02-06 08:02:36 [[sroracle]]: the length of the hash can change 2021-02-06 08:03:22 [[sroracle]]: https://tpaste.us/vZRQ 2021-02-06 09:32:57 ikke: atools 20.0.0 :D 2021-02-06 09:37:15 ah, you made an actual release on gl :) 2021-02-06 09:38:15 I made 2 releases before that for AL62 2021-02-06 09:38:34 20.0.1 is tagged as well? 2021-02-06 09:39:04 Yes 2021-02-06 09:39:22 It is tradition for me to find last minute bugs 2021-02-06 09:39:26 yup 2021-02-06 09:39:37 In this case I forgot to add the new tool to the conf file 2021-02-06 09:41:52 85 checks in the test suite, nice 2021-02-06 09:41:59 well, in one 2021-02-06 09:42:20 103 for apkbuild-lint 2021-02-06 12:33:10 speaking of atools: a linter check for ensuring that deluser/delgroup is not used in post-install scripts may be nice 2021-02-06 12:33:15 *post-deinstall 2021-02-06 15:28:26 Please can someone restart x86_64 edge builder? 2021-02-06 15:29:34 mopidy again? 2021-02-06 15:29:38 I already killed it before 2021-02-06 15:29:51 yes 2021-02-06 15:29:54 can someone look at it? 2021-02-06 15:30:24 I mean, I can look at the server side, but I mean, fix / disable the test that hangs 2021-02-06 15:37:30 As I see in logs test passed and it hangs after it 2021-02-06 15:37:56 Seems like a deadlock 2021-02-06 15:37:58 FUTEX_WAIT 2021-02-06 15:38:18 Maybe some docker permission in CI... As I hit with php last night 2021-02-06 15:38:34 builder does not run on docker 2021-02-06 15:39:28 I mean it's hard to replicate as builder is not using docker 2021-02-06 15:39:52 I can test in my lxc container 2021-02-06 15:59:40 andypost[m]: https://tpaste.us/jnRm 2021-02-06 15:59:52 gdb backtrace 2021-02-06 16:00:49 https://live.fosdem.org/watch/dopenjdk 2021-02-06 16:01:02 ^ OpenJDK devs talking about OpenJDK on Alpine right now 2021-02-06 16:01:13 Apparently they'll support this upstream starting with OpenJDK 16 2021-02-06 16:04:07 did they contact anyone at alpine? 2021-02-06 16:06:28 I don't think so 2021-02-06 16:07:11 And asking in the OpenJDK chat it seems like they don't really want to maintain the openjdk packages in the alpine repos but instead just use Alpine as a base image and build OpenJDK themselves in their Docker image 2021-02-06 16:07:52 We have someone here who wants to do that luckily 2021-02-06 16:14:35 andypost[m]: it finishes in my lxc container 2021-02-06 16:24:11 Who is Sören Tempel on Gitlab again? 2021-02-06 16:24:35 nmeum 2021-02-06 16:26:30 Thanks 2021-02-06 16:27:33 PureTryOut[m]2: libpinyin has test failures on mips64 2021-02-06 16:27:41 I saw it 2021-02-06 16:27:43 ok 2021-02-06 16:27:49 on other arches as well 2021-02-06 16:27:51 Just going to disable it there, it's not an architecture that's relevant for it 2021-02-06 16:28:02 armv7 fails as well 2021-02-06 16:28:11 Yeah that is one weird, it succeeded on CI 2021-02-06 16:28:32 And the whole point of that MR was to enable armv7 on kyotocabinet and then libpinyin 2021-02-06 19:50:30 ikke: you can now use `convert-volatile-source` from atools to automatically replace all violations of AL62 with local patches 2021-02-06 19:52:27 aha 2021-02-06 19:59:10 unfortunately I can't put it on apkbuild-fixer 2021-02-06 19:59:19 ^ which automatically fixes violations 2021-02-06 20:16:19 Hello71: hmm, this is a new variant: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12396 /bin/sh not permitted, but they say it's on 3.12 2021-02-06 20:16:52 ikke: i think you misread it 2021-02-06 20:17:29 aha 2021-02-06 20:17:35 works on 3.12, fails on edge 2021-02-06 20:20:35 i wonder if we should patch make to not do this check 2021-02-06 20:33:06 https://bpa.st/Q3EQ 2021-02-06 20:36:04 fails tests :/ 2021-02-06 20:39:15 hm but does it actually fix it 2021-02-06 20:48:42 yes but it fails the tests. giving up on that 2021-02-07 09:12:27 Hello71: and another one :) 2021-02-07 09:12:49 #12402 2021-02-07 11:14:12 What's the right way to create /var/run/rdnssd/ on package installation? using `install -d`? 2021-02-07 11:15:36 the official way is ot use something like checkpath in a pre_start function in the initd 2021-02-07 11:15:56 doing it post-install is not enough 2021-02-07 11:16:05 next reboot the dir is gone again\ 2021-02-07 11:16:26 and if possible it should be /run/something nowadays 2021-02-07 11:16:32 yes 2021-02-07 11:16:38 /var/run is a symlink to /run 2021-02-07 11:16:53 yes, as workaround 2021-02-07 11:17:16 for backwards compattibility 2021-02-07 11:17:45 well, same conotation 2021-02-07 11:18:07 work-around implies bug 2021-02-07 11:18:18 it is bug 2021-02-07 11:18:26 it's not a bug 2021-02-07 11:18:35 the canonical path used to be /var/run 2021-02-07 11:18:37 heh 2021-02-07 11:18:45 then we decide /run is better 2021-02-07 11:18:58 to bot break existing software, we maintain a symlink on /var/run 2021-02-07 11:19:02 s/bot/not 2021-02-07 11:19:02 ikke meant to say: to not break existing software, we maintain a symlink on /var/run 2021-02-07 11:19:43 choosing /run is actually one of the rare GOOD decisions that mainstream distros have taken wrt file hierarchy 2021-02-07 11:19:49 all software must upgrade^Wadapt to our rules 2021-02-07 11:20:22 /run is better than /var/run because it can be mounted/created at boot time even when /var is on a separate filesystem 2021-02-07 11:20:39 which actually makes sense because /var has to be read-write when / can be read-only 2021-02-07 11:21:18 so using /run instead of /var/run means that you can actually have a small root-only read-write filesystem (probably a tmpfs) early in the boot sequence, before mounting disks 2021-02-07 11:21:24 and that's a good thing 2021-02-07 11:21:30 ikke: you explaining to someone who patched runit to do that, on dedicated router 2021-02-07 11:21:50 mps: I'm just arguing that this is not a bug 2021-02-07 11:22:29 meh, on sundays you loose your humor somewhere :) 2021-02-07 11:23:38 true, it is not bug strictly, but it is bug because software doesn't follow *our* rules 2021-02-07 11:23:46 humor? what's that? 2021-02-07 11:24:14 when you trying to be serious ;) 2021-02-07 11:26:43 Do you have an example init script that creates it's run directory before starting? 2021-02-07 11:27:13 Got it, utmpd 2021-02-07 13:18:25 ikke, Ariadne: wondering if we should revert faccessat2? 2021-02-07 13:24:23 but then it will never be fixed 2021-02-07 13:52:46 well it's a question of time here 2021-02-07 13:53:42 it's not like distros will sit on old libseccomp forever 2021-02-07 15:59:49 even our 3.12 is stuck on 2.4.3 2021-02-07 16:00:39 either we should revert it, or at least file bugs at major distros (debian, ubuntu, raspbian at least, as well as ourselves) to have them update to 2.4.4 2021-02-07 16:04:17 additionally it requires docker 20.10, instead of 19.03 2021-02-07 16:06:48 i think the docker version req will be ok by the time we actually get 3.14 out the door, due to ppas, but libseccomp will probably need some poking 2021-02-07 16:07:27 based on previous releases, debian 11 probably won't be out till August or somesuch 2021-02-07 16:16:08 i guess we can actually do both 2021-02-07 16:20:55 or maybe we could convince docker people to add libseccomp? 2021-02-07 16:41:44 hmm, we don't have tshark on armhf and mips64? 2021-02-07 16:58:55 community/wireshark/APKBUILD: arch="all !armhf" # blocked by qt5-qtdeclarative 2021-02-07 16:59:18 but it should sitll be possible to build tshark to armhf, right? 2021-02-07 16:59:41 or could the qt5-qtdeclarative issue be solved already? (haven't had a look) 2021-02-07 17:03:04 Upstream has ignored the issue for some years now, so I doubt it'll get fixed 2021-02-07 17:37:30 Hello71: You mean to bundle it" 2021-02-07 17:37:33 ? 2021-02-07 17:40:39 Hi, not sure if this is the good place to ask, but since I got no reply on GitLab, I'll explain my problem here. 2021-02-07 17:40:40 I try to build an Alpine minirootfs, and I built the necessary packages in the aports tree, but when I try to make a distribution tar.gz, I get this error: 2021-02-07 17:40:40 apk-build:~/aports/scripts$ ./mkimage.sh --arch armv7 --profile minirootfs --repository /home/nicolas/packages/main 2021-02-07 17:40:41 OK: 0 MiB in 0 packages 2021-02-07 17:40:41 main [/home/nicolas/packages/main] 2021-02-07 17:40:42 OK: 46 distinct packages available 2021-02-07 17:40:42 >>> mkimage-armv7: Building minirootfs 2021-02-07 17:40:43 >>> mkimage-armv7: Creating alpine-minirootfs-210207-armv7.tar.gz 2021-02-07 17:40:44 (1/11) Installing musl (1.2.2-r1) 2021-02-07 17:40:44 (2/11) Installing busybox (1.33.0-r1) 2021-02-07 17:40:45 (3/11) Installing alpine-baselayout (3.2.0-r8) 2021-02-07 17:40:45 (4/11) Installing alpine-keys (2.2-r0) 2021-02-07 17:40:46 (5/11) Installing libcrypto1.1 (1.1.1i-r0) 2021-02-07 17:40:46 (6/11) Installing libssl1.1 (1.1.1i-r0) 2021-02-07 17:40:47 (7/11) Installing zlib (1.2.11-r3) 2021-02-07 17:40:47 (8/11) Installing apk-tools (2.12.1-r0) 2021-02-07 17:40:48 (9/11) Installing scanelf (1.2.9-r0) 2021-02-07 17:40:48 (10/11) Installing musl-utils (1.2.2-r1) 2021-02-07 17:40:49 (11/11) Installing libc-utils (0.7.2-r3) 2021-02-07 17:40:49 OK: 4 MiB in 11 packages 2021-02-07 17:42:11 tux-linux: next time please use paste service, for example this: https://tpaste.us/ 2021-02-07 17:42:19 ok thanks 2021-02-07 17:44:40 It's there: 2021-02-07 17:44:41 https://tpaste.us/DMjd 2021-02-07 18:37:54 Uh, why is ca-certificates (on edge) complaining about a malicious file? https://gitlab.com/postmarketOS/pmaports/-/jobs/1013707919#L231 2021-02-07 18:37:58 x86 only it seems 2021-02-07 18:39:12 ikke: yes 2021-02-07 18:41:30 tux-linux: at a guess, you are out of disk or ram 2021-02-07 18:41:48 or are behind some crappy firewall 2021-02-07 18:43:59 PureTryOut[m]2: according to https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/database.c#L2418, it is when there are "control characters" 2021-02-07 18:44:54 i would be inclined to suspect a ram issue 2021-02-07 18:45:02 try running it again 2021-02-07 18:46:00 Keeps happening 🤔 2021-02-07 18:50:23 hm. i would suspect corrupted package but that should be caught by signature... 2021-02-07 18:51:10 Hello71 I don't think I'm running out of RAM, it has largely enough even when running (2.5G free) 2021-02-07 18:51:34 tux-linux: are you counting available or free+cached 2021-02-07 18:51:48 wait I'll check 2021-02-07 18:54:20 Available is about 3.5G now and free is 3.8G 2021-02-07 18:58:00 uh 2021-02-07 18:58:13 that doesn't sound right but it should be enough 2021-02-07 19:00:02 it did the same on two qemu virtual machines and a raspberry pi 400 2021-02-07 19:12:28 I'm also wondering about the ca-certificates apk error 2021-02-07 19:13:16 in pmaports we have build jobs for all arches, like in alpine's aports, and it only happens for x86 as PureTryOut noted above. consistently, it never fails for other arches o_O 2021-02-07 19:14:42 I wonder if it's a regression from https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/b43da45bc31a5d09fc03e8bb1ce7c3f875bdfaaa that only happens to trigger from the x86 package 2021-02-07 19:15:02 gitlab is going down for a brief moment for upgrades 2021-02-07 19:15:34 (fabled is not in this channel, right?) 2021-02-07 19:15:43 He is from time to time 2021-02-07 19:15:50 can we upgrade linux-lts on v3.13 today? 2021-02-07 19:16:04 5.10.14 was releasd this morning as well 2021-02-07 19:16:56 hmm no 2021-02-07 19:16:56 I compiled that on my raspberry pi too, armv7l 2021-02-07 19:17:01 c705_: ncopa is taking care of this, which means it will happen somewhere next week probably 2021-02-07 19:17:46 tux-linux: ca-certificates? 2021-02-07 19:18:23 what's the connection between ca-certificates and gzip compression? 2021-02-07 19:18:56 no, I was wondering if we were talking about the same issue, that's why I asked if you were talking about ca-certificates. so it's a different thing then probably 2021-02-07 19:19:35 ah yes, you posted an unrelated question above, saw it now. sorry 2021-02-07 19:22:02 tux-linux: for your problem, I suggest reading mkimage.sh and figuring out on which command it crashes (e.g. by adding #!/bin/sh -ex as first line in the script), then running strace on that or something. I can't help you with that beyond giving that pointer though, too many things to do right now 2021-02-07 19:25:08 ok, gitlab has been upgraded to 13.7 :) 2021-02-07 19:25:19 One new thing: merge request reviewers 2021-02-07 19:31:51 c705_: linux-edge is already 5.10.14 2021-02-07 19:32:41 i'm asking about v3.13 2021-02-07 19:33:16 it is in testing, so available on all releases ;) 2021-02-07 19:34:23 *linux-lts* 2021-02-07 19:35:11 The ARM builders are at it again with their race conditions 2021-02-07 19:48:20 problematic script is genrootfs.sh 2021-02-07 19:48:37 last line of the file 2021-02-07 19:50:24 hm... false. It seems to be elsewhere too 2021-02-07 20:04:43 Ok. the main command that causes the problem is at line 41 of file genrootfs.sh in aports/scripts. 2021-02-07 20:04:43 tar -zx -C "$tmp" etc/ 2021-02-07 20:04:52 don't know what to do with it... any ideas? 2021-02-07 20:48:33 mopidy blocks x86_64 testing builder for few days 2021-02-07 20:49:30 hmm, it is community 2021-02-07 20:50:03 yes 2021-02-07 20:50:39 I feel it's something on the builder 2021-02-07 21:19:35 [06:18:20] ikke, Ariadne: wondering if we should revert faccessat2? 2021-02-07 21:19:42 i do not support 2021-02-07 21:19:52 i think it is important to fix this for real 2021-02-07 21:27:23 i found that glibc 2.33 uses faccessat2... but still emulates eaccess instead of calling faccessat :/ 2021-02-07 21:27:37 which means that the make issue won't affect glibc 2.33 2021-02-07 21:27:51 Ariadne: my contention is that "fixing this" means... updating libseccomp and docker 2021-02-07 21:28:20 the situation is not that libseccomp and docker have simply ignored the issue (with the exception of docker for windows) 2021-02-07 21:28:40 they've addressed it but downstream distros (including alpine 3.12) have not updated 2021-02-07 21:29:13 is your proposal to use alpine users as leverage in this issue? if so, shouldn't we at least ask politely first? 2021-02-07 21:30:25 i.e. ask those downstream distros which don't have libseccomp 2.4.4 to update, so that when alpine 3.14 comes out and users complain, we can tell them "look, we filed this issue half a year ago, go blame your distro" instead of shrugging 2021-02-07 21:31:14 fwiw i already filed https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1914939 2021-02-07 21:31:27 regarding the apk-tools bug with ca-certificates for x86, reported here: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10737 2021-02-07 21:31:57 ollieparanoid[m]: i'm inclined to suspect that this is an issue with the actual package 2021-02-07 21:32:07 but it's probably fine to put it there for now 2021-02-07 21:32:53 but it works for all other arches... makes me think the order of files in the package was different for the x86 build, and therefore apk doesn't like this specific one 2021-02-07 21:32:57 so it might be an apk bug 2021-02-07 21:33:12 I've attached the apk files for reference 2021-02-07 21:33:37 and I'll try to rebuild it to see if apk will install it then 2021-02-07 21:34:45 actually even if we update libseccomp to 2.4.4 in 3.12, it still won't work because docker is 19.03, and faccessat2 needs 20.10 2021-02-07 21:38:02 hm, but that'll be backported in https://github.com/moby/moby/pull/41381 2021-02-07 21:38:08 so i guess it's not *that* bad 2021-02-07 21:38:35 gonna add a comment poking them 2021-02-07 21:50:54 ollieparanoid[m]: I see fabled just pushed some commits to apk-tools 2021-02-07 21:52:21 and it closes the issue I reported, nice :> 2021-02-07 21:52:53 apk-tools on edge is updated 2021-02-07 21:53:03 awesome, that was fast 2021-02-07 22:01:38 Hello71: I tend to agree with Ariadne, bugs should be fixed 'for real' if possible at all efforts 2021-02-07 22:01:57 and yes, I know it is not 'easy task' but ... 2021-02-07 22:09:05 the question is who should do the fixing 2021-02-07 22:09:17 the idea behind not reverting is to apply pressure on somebody to fix it faster 2021-02-07 22:10:18 I thought so 2021-02-07 22:10:43 you told you reported bug somewhere, iiuc 2021-02-07 22:11:16 https://github.com/opencontainers/runc/pull/2737 2021-02-07 22:15:02 in 'good enough world' bugs should be fixed and not 'suppressed', imo 2021-02-07 22:15:21 yes, but we cannot change the past 2021-02-07 22:16:05 The issue is that the causes issues where the host is not running bleeding edge 2021-02-07 22:16:32 well, we can move to future if can't change past 2021-02-07 22:16:58 We are basically expecting everyone to update all systems to the latest versions 2021-02-07 22:17:09 yes 2021-02-07 22:17:18 which is not reasonable 2021-02-07 22:17:27 :) 2021-02-07 22:18:15 alpine 3.12 and below is affacted as well 2021-02-07 22:18:24 I know 2021-02-07 22:18:52 'all users of alpine 3.12-stable must upgrade' :) 2021-02-07 22:19:43 ikke: sorry for kidding but I don't see what could be done, seriously 2021-02-07 22:20:17 there is no easy solution 2021-02-07 22:20:30 agree 2021-02-07 22:20:51 problem is not one of 'easy' 2021-02-07 22:21:02 the libseccomp interaction kind of prevents this forwards-compattibility 2021-02-07 22:21:38 which is what normally allows us to introduce these new kind of features 2021-02-07 22:21:53 hmmm, this tempting me to write rude words, but I will resist (this time) 2021-02-07 22:22:06 musl can handle the lack of these syscalls, but only if the correct error is returned 2021-02-07 22:23:01 I will say this so: we don't force anyone to use alpine, and we don't sell alpine to anyone in any way 2021-02-07 22:23:38 question is: do we want correct behavior or something else 2021-02-07 22:23:56 I mean, if we know for bug 2021-02-07 22:24:11 upstream acknowled the issue and fixed it 2021-02-07 22:24:18 but it takes time for it to trickle down 2021-02-07 22:24:25 which is good 2021-02-07 22:24:39 and personally I appreciate this 2021-02-07 22:24:40 but in the mean time, everone is running into it 2021-02-07 22:24:53 without a clear clue what is going on 2021-02-07 22:25:01 "bin/sh permission denied" 2021-02-07 22:25:13 iiuc, this is only on edge and/or 3.13? 2021-02-07 22:25:23 only edge 2021-02-07 22:25:32 ah, better 2021-02-07 22:25:33 in 3.13 we disabled faccessat2 2021-02-07 22:25:36 but 2021-02-07 22:25:52 3.13 is still suffering from the time_t 64-bits issue on 32-bits systems 2021-02-07 22:26:44 you mean 'on some 32-bit systems' I think. sorry if my conclusion is wrong 2021-02-07 22:27:17 our CI was affected 2021-02-07 22:27:38 (I'll better 'close mouth' because I didn't had time to follow this in last month) 2021-02-07 22:28:29 but have to 'if I vote for new BDFL my vote will go to ikke' 2021-02-07 22:28:38 have to add* 2021-02-07 22:28:38 So now we get a couple of issues per week asking about this 2021-02-07 22:29:22 I understand that the situation is not pleasant, but 'it is edge, at the end' 2021-02-07 22:29:48 !12402 2021-02-07 22:29:53 wrong one 2021-02-07 22:29:59 #12402 2021-02-07 22:30:31 #12402 2021-02-07 22:30:40 #12396 2021-02-07 22:31:02 I remember 2021-02-07 22:31:34 iirc I was first meet this on CIs 2021-02-07 22:31:49 probably, yes 2021-02-07 22:32:12 and some of these users run against this on systems they have no control over whatsoever 2021-02-07 22:32:12 only problem is I don't like to write bug reports 2021-02-07 22:32:25 ie, travis 2021-02-07 22:32:31 or docker actions 2021-02-07 22:32:39 github actions* 2021-02-07 22:33:16 ACTION wonders how someone can have such patience as ikke have 2021-02-07 22:34:33 ikke: look at clock, I'm going to take glass(es) of red wine and rest you know :) 2021-02-07 22:34:41 :) 2021-02-07 22:35:21 tomorrow is also good day for problems 2021-02-07 22:45:33 filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/12405 for our backporting 2021-02-07 22:46:28 can someone that knows how to correctly finagle the debian bts send an equivalent of https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1914939 to them? 2021-02-07 22:47:14 idk about raspios procedure but i assume they want packages to be in debian first 2021-02-07 22:47:43 fedora already has the right libseccomp for all supported versions 2021-02-07 22:48:11 i think ubuntu+debian+fedora+alpine+raspios is probably 95%+ of alpine docker hosts 2021-02-07 22:49:09 hm, actually i think i can figure it out 2021-02-07 22:50:36 Hello71: i am unaware of alpine users using alpine edge in production 2021-02-07 22:51:01 Ariadne: well see the problem here is people using it in docker 2021-02-07 22:51:12 using alpine edge in docker? 2021-02-07 22:51:15 why would they do that? 2021-02-07 22:51:23 which is not entirely unreasonable at least according to the docker marketing 2021-02-07 22:51:37 package building and whatnot 2021-02-07 22:51:42 i see 2021-02-07 22:51:51 gitlab ci 2021-02-07 22:52:07 well, i see no reason to back faccessat2 out again. take it up with dalias 2021-02-07 22:52:20 i only did it for 3.13 because we were close to shipping 3.13 2021-02-07 22:52:37 even we (alpine linux ci) do that, and we've been bitten by several of these 2021-02-07 22:52:48 ok, so take it up with dalias 2021-02-07 22:53:14 yes, i think after further investigation, we can file bugs at those distros, telling them to backport libseccomp 2.4.4, and also tell docker to hurry up and backport the faccessat2 2021-02-07 22:53:23 i want a solution that is more resilient than patching faccessat2 out 2021-02-07 22:53:27 then we will not need to tell users "you must use the bleeding edge version on your host" 2021-02-07 22:53:41 i don't think dalias will be happy about that :p 2021-02-07 22:54:02 since i think the whole point of using faccessat2 here is that it's the only correct solution available 2021-02-07 22:54:12 yes, so why would we back it back out? 2021-02-07 22:54:18 glibc just fudges it and calculates it based on the file mode 2021-02-07 22:54:30 considering that we are *checks notes* early in the 3.14 development cycle 2021-02-07 22:54:50 i am willing to consider backing it back out if the situation does not change in the next month 2021-02-07 22:55:02 tried the Alpine "mini root filesystem" on qemu-arm with full armv7 emulation 2021-02-07 22:55:21 because as i said it's biting a lot of users. we've gotten at least three (?) issues filed and presumably there's a lot more that just think "alpine is broken" 2021-02-07 22:55:32 had to set up early init by hand because openrc isn't there and init still wants to see it 2021-02-07 22:55:34 it reminds me strongly of the tcp dns case 2021-02-07 22:55:36 those users should perhaps not use alpine edge 2021-02-07 22:55:47 then apk update gave me "Illegal instruction" 2021-02-07 22:56:05 I don't know what's up with Alpine-3.13 but something's up 2021-02-07 22:56:08 i agree with your viewpoint in that case that alpine is not broken, their setup is, but people wll blame alpine 2021-02-07 22:56:55 skarnet: for the openrc issue, minirootfs has never included openrc afaik. you can add it with apk add -p or qemu-user 2021-02-07 22:56:56 skarnet: minirootfs is for docker 2021-02-07 22:57:18 illegal instruction is likely fortify 2021-02-07 22:57:26 yeah but it just doesn't boot as is, you need to fudge the init 2021-02-07 22:57:27 would be interesting to see a coredump 2021-02-07 22:57:35 yeah its not supposed to boot 2021-02-07 22:57:37 its for docker 2021-02-07 22:57:42 and to apk add you need network 2021-02-07 22:58:03 you say 'for docker', I wanted to use it under qemu, I finally made it work 2021-02-07 22:58:13 sure 2021-02-07 22:58:17 but yeah, illegal instruction, and then there's no way to verify the keys 2021-02-07 22:58:28 but i think we are in agreement anyways that the conclusion is that we don't need to revert it now, and we should file bugs at those distros (and ours) to fix it 2021-02-07 22:58:34 fun fact: illegal instruction happens about 50% of the times 2021-02-07 22:58:42 skarnet: that smells like fortify 2021-02-07 22:58:44 i filed #12405 for our backporting efforts 2021-02-07 22:58:45 the other 50% it works, until it can't verify the keys 2021-02-07 22:58:55 Ariadne: how do I disable that, or make it work? 2021-02-07 22:59:10 you would have to rebuild apk with -D_FORTIFY_SOURCE=0 2021-02-07 22:59:44 I want to use pristine alpine-3.13 stuff since my goal is precisely to investigate what's going wrong with skalibs on that version on armv7 2021-02-07 22:59:51 no rebuilding planned 2021-02-07 23:00:00 fortify causes the compiler to emit invalid bytecode when a violation happens 2021-02-07 23:00:01 but if there's a kernel option to activate to make fortify work, I can do that 2021-02-07 23:00:09 no kernel option 2021-02-07 23:00:11 this is compiler 2021-02-07 23:00:13 skarnet: what arch is host 2021-02-07 23:00:20 host is x86_64 2021-02-07 23:00:34 but why would there be a violation in apk 2021-02-07 23:00:55 invalid argument passed to some function guarded by fortify 2021-02-07 23:01:00 hmm, last time I tried on x86_64 it worked, armhf and armv7 2021-02-07 23:01:48 Ariadne: in that case apk would just be broken on that mini-rootfs? 2021-02-07 23:01:55 yes 2021-02-07 23:01:59 but it failed in lxc on aarch64 host 2021-02-07 23:02:05 it would be nice if you could collect a coredump 2021-02-07 23:02:13 that will tell us what the problem is 2021-02-07 23:02:21 with 'illegal instruction' 2021-02-07 23:02:25 I'll try 2021-02-07 23:02:38 illegal instruction is usually caused by fortify 2021-02-07 23:02:53 extracting the coredump from the image without any tool will not be easy :P 2021-02-07 23:02:55 I had to enable 'old emualtion options' for host kernel 2021-02-07 23:02:55 when a fortify violation occurs, gcc emits invalid bytecode 2021-02-07 23:03:55 __builtin_trap() 2021-02-07 23:03:56 :P 2021-02-07 23:04:00 checking harder, debian-backports has 2.4.4 but not for mips/ppc/s390x. i don't think anyone remotely sensible is running debian + docker + alpine edge on those anyways, but it needs special enablement 2021-02-07 23:04:33 Hello71: i think this is at most a documentation issue 2021-02-07 23:04:46 yes, i'm coming to that conclusion too 2021-02-07 23:04:48 "you need libseccomp 2.4.4 or newer to use alpine edge due to faccessat2 syscall" 2021-02-07 23:04:56 i already wrote that like a month ago 2021-02-07 23:05:14 like i said the only reason i held faccessat2 back in 3.13 was because we were close to release 2021-02-07 23:05:31 i think we should make more effort to put user-facing changes in draft release notes, and then tell everybody using alpine edge to review those regularly 2021-02-07 23:05:46 it would be better to send out emails but that might be too much work 2021-02-07 23:06:03 ikke: can we post something on the alpine website (a news entry) about needing libseccomp 2.4.4 or later to run alpine edge containers 2021-02-07 23:06:35 that might be a good step, but there are a lot of other less important changes 2021-02-07 23:07:16 we should have a place to publicize those for edge users. it doesn't have to be super formal but our current system of "rigorously follow #alpine-devel" is not sufficient IMO 2021-02-07 23:07:24 sure 2021-02-07 23:07:38 i'm just saying this is something we can do *immediately* while we figure the rest out 2021-02-07 23:08:09 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0 i put the text there 1.5 weeks ago, basically copied from https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0 2021-02-07 23:08:55 the other problem is that it requires libseccomp 2.4.4 *and* Docker 20.10.0 2021-02-07 23:21:41 Ariadne: also while you're around, is my impression at #12365 wrong, or does libtool actually need to be rebuilt for every gcc bump, otherwise libtool CXX is broken? 2021-02-07 23:22:53 my confusion is if that's the case, why isn't everything that uses libtool broken? 2021-02-07 23:35:52 Ariadne: I have a core, where should I put it? 2021-02-07 23:36:17 (serious answers only, please) 2021-02-07 23:37:16 actually recent studies show that fecal transplants are highly effective against a variety of immunological disorders 2021-02-07 23:38:01 well if anyone's interested, "apk update" on armv7 gave me this: https://skarnet.org/tmp/apk-core 2021-02-07 23:38:59 and with that, I'm yeeting that minirootfs into the Great Void 2021-02-07 23:39:37 Not sure if a core from a self-compiled binary is useful 2021-02-07 23:42:59 execfn: '/sbin/apk', so i assume this is from alpine apk-tools 2021-02-07 23:43:56 Hello72: this is long time know fact, about fecal transplants 2021-02-07 23:44:48 question is how to 'translate' it in context of #alpine-devel 2021-02-07 23:45:01 i mean, not that long, only about 10-15 years 2021-02-07 23:45:23 I know this for about 30 years 2021-02-07 23:46:03 probably it is known a lot longer 2021-02-07 23:46:18 moved to #alpine-offtopic 2021-02-08 00:28:49 Cogitri: it's not from a self-compiled binary, it's straight from Alpine's minirootfs 2021-02-08 00:29:32 I don't know how you have been raised, but I don't dump my own cores in other people's channels for others to study 2021-02-08 01:57:02 Hello72: no libtool does not need to be rebuilt 2021-02-08 01:57:16 Hello72: but sometimes, libtool bundled with a project needs to be replaced with system libtool 2021-02-08 01:57:26 because its some thing from the 2000s 2021-02-08 01:57:37 so you're saying it's correct that libtool on alpine edge references gcc 9.3.0? 2021-02-08 01:57:48 that's what i thought initially too 2021-02-08 01:58:06 yes, shouldn't matter 2021-02-08 01:58:08 but it seems suspicious that /usr/bin/libtool talks about /usr/lib/gcc/.../9.3.0 2021-02-08 01:58:24 ok 2021-02-08 01:58:38 yeah probably those paths were "detected" at the build time 2021-02-08 01:58:43 libtool is broken (upstream) but this particular brokenness doesn't affect anything 2021-02-08 01:58:45 ? 2021-02-08 01:58:52 yes and yes 2021-02-08 02:02:22 i noticed that the tarball referenced in that issue doesn't come with configure.ac (or configure.in). i guess the solution here is supposed to be "run autoreconf -i", but aiui that doesn't work if the configure.ac/in was removed 2021-02-08 02:03:03 and it seems like libtoolize would also fix it but that needs configure.ac/in too. does that mean the user needs to get the development source and autoreconf from that? 2021-02-08 02:07:37 yes 2021-02-08 02:09:52 but if a program is using libtool directly, that's just crazy 2021-02-08 02:28:59 nah it's autoconf, they just deleted the configure.ac -.- 2021-02-08 02:29:07 oh autohell 2021-02-08 02:29:12 how I wish it would just die 2021-02-08 02:48:23 apparently it's generated by an even more ancient build system called "aegis", and the configure.ac is in etc/configure.ac? what nonsense 2021-02-08 02:49:48 and it doesn't use automake but instead its own "aegis" Makefile.in which calls $(LIBTOOL) directly 2021-02-08 02:49:50 ACTION bails 2021-02-08 06:04:53 Hello72: one possible solution might be to use slibtool and LIBTOOL=slibtool 2021-02-08 07:40:54 I am creating a APKBUILD for a package that has various ./configure graphic output options ('none' 'x11' 'qt' etc) 2021-02-08 07:40:56 each installs a binary with the same name but different sizes, only 1 graphic output option can be specified at a time 2021-02-08 07:41:01 what is the correct way to do this? 2021-02-08 07:41:03 Do I use a single APKBUILD with sub function to ./configure? or split them into different packages? 2021-02-08 08:21:35 Is Leo from gitlab in this room? 2021-02-08 08:21:42 yes 2021-02-08 08:21:58 (maxice8 is Leo from Gitlab) 2021-02-08 08:22:24 seems like ccache is on full-on failure 2021-02-08 08:22:32 https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/ccache/ccache-4.2-r0.log all arches 2021-02-08 08:23:38 hmm, room, what strange term 2021-02-08 08:24:12 it is channel, not room 2021-02-08 08:25:14 Channel on IRC, room on Matrix. Does't matter, just leave it 2021-02-08 08:26:00 maxice8: good to see you! Regarding the rdnssd: I can prepare a patch to change uid/gid to rdnssd, but effectively all operations will be done as root anyway, as the main purpose of the daemon is to update /etc/resolv.conf 2021-02-08 08:28:03 PureTryOut[m]2: 'when you in Rome speak as Roman', else make confusion 2021-02-08 08:28:22 They asked about Leo, and he understood, so there was no confusion 2021-02-08 08:28:30 I don't see why you should make a big deal out of it 2021-02-08 08:28:34 meh 2021-02-08 08:29:01 mps: burning Rome down sounds fun though 2021-02-08 08:29:16 telmich: if that is the case then it should be fine as-is 2021-02-08 08:30:48 maxice8: yes, people like to burn 'worlds' for different reasons, but mostly because of understanding (wrong ofc) 2021-02-08 08:33:11 mps: we can also call this `a bucket`, which covers room, channel and probably other definitions of .. oh wait, maybe we can call it a `collection`, even though this reminds one of Java very much... 2021-02-08 08:33:49 in IRC it is called channel, nothing else 2021-02-08 08:42:59 mps: it's Latin not Roman 2021-02-08 08:43:56 travankor: 'as Roman' not 'in Latin' 2021-02-08 08:44:39 okay, how about speak as Roman in Latium 2021-02-08 08:45:25 because it is something totally different 2021-02-08 08:46:29 https://graylinerome.com/blog/when-rome-speak-roman/ 2021-02-08 08:47:01 Latium was just one part of Rome 2021-02-08 08:47:43 it's the province of Rome (the city) 2021-02-08 08:47:49 gtk+2.0 reached EOL :D 2021-02-08 08:48:43 travankor: we have #alpine-offtopic channel 2021-02-08 08:48:54 maxice8: .oO(finally) 2021-02-08 08:49:03 Hey Gottox 2021-02-08 08:49:08 hey maxice8 :) 2021-02-08 08:52:18 I found most multi packages APKBUILD has sub functions for package(), not many have them for build(), the closest I can find is linux-lts which uses different 'flavors' in package() and launches oldconfig() which creates a new subdir for each flavors to run make in, then package() launches _package() for each flavor 2021-02-08 08:52:35 There is libgit2 2021-02-08 08:52:37 for shared and static libraries 2021-02-08 08:52:41 any simpler example for a multi ./configure subpackage build? :) 2021-02-08 08:53:15 alexy: vim? 2021-02-08 08:53:26 mps: let me check 2021-02-08 08:56:06 mps: ahh, that's it 2021-02-08 08:59:24 ncopa: ccache is failing hard 2021-02-08 08:59:26 on all arches 2021-02-08 09:19:07 =( 2021-02-08 09:21:16 seems like tests are failing 2021-02-08 09:22:37 but they passed in ci 2021-02-08 09:26:41 "Bus error" on armhf and file permission errors on the others I have looked at the logs for 2021-02-08 09:49:59 any objection to !17887? I would like to backport it to 3.13 also 2021-02-08 09:50:13 ncopa: ^ 2021-02-08 09:54:16 i need to clean up the ccache mess first 2021-02-08 09:54:26 /bin/sh: perl: not found 2021-02-08 10:01:25 ncopa: sorry! 2021-02-08 10:03:21 omni: no worries. happens 2021-02-08 10:24:45 f75e8d98690791347c4d632f798886bbd11cda91 2021-02-08 10:46:53 since I noticed that several flagged packages actually are up-to-date I'm going through that list now, from oldest to latest 2021-02-08 10:47:03 how are they unflagged? 2021-02-08 10:47:40 I could provide a list of "OK" packages, later, to unflag 2021-02-08 11:40:39 omni: normally when the package is updated 2021-02-08 11:41:01 manually unflagging probably requires directly executing queries on the DB 2021-02-08 11:55:03 ok 2021-02-08 11:55:41 for some the "New version" is just silly or in other ways not matching what the package has been updated to 2021-02-08 11:56:19 so far I've just gone through the last of the six pages of flagged packages 2021-02-08 11:56:20 omni: it's unflagged after any update, not necessarily to the indicated version 2021-02-08 11:56:36 but some packages are rarely updated 2021-02-08 12:41:09 ah, but wouldn't it be nice to clean it up a bit? 2021-02-08 12:41:15 I understand it's low priority 2021-02-08 12:54:36 imo the flag system is not that good, because there is no way to search for earlier flags 2021-02-08 12:54:45 so there is nothing stopping people from filing further erroneous flags 2021-02-08 13:07:03 sure, but I quite like that you can flag a package without having to register 2021-02-08 13:11:58 ncopa: was failing tests related to missing perl in makedepends? 2021-02-08 13:12:09 main/ccache 2021-02-08 14:01:33 omni: tbh dont know if that was the reason the tests failed. the build falied locally due to missing perl though, and a grep showed that perl was needed 2021-02-08 14:07:09 looks like checksum changed on atools? 2021-02-08 14:25:03 do we add a 'lib' prefix to the pkgname when a complete package only contains a library (no bin)? 2021-02-08 14:33:27 alexy_: usually -libs 2021-02-08 14:33:42 not prefix, but suffix 2021-02-08 14:34:16 but if upstream name is 'lib....' then prefix, yes 2021-02-08 14:35:02 primary rule is to keep name as upstream whenever possible 2021-02-08 15:05:01 mps: ahh 2021-02-08 15:11:48 hello72 & ariadne, re: faccessat2 obviously you can patch for alpine as needded but i'd much rather use this as part of the wedge to force ppl to upgrade their broken docker versions 2021-02-08 15:12:51 in theory you could do a reduced back-out: check uid/gid matches first and do the old syscall if real==effective and flags==AT_EACCESS 2021-02-08 15:13:05 but that wastes 4 syscalls at each call to check the uids/gids 2021-02-08 15:17:55 heh, this package's official archive (from a .org) extracts to a different path than the archive from their github, exact same version, different extraction path 2021-02-08 15:19:04 changed the source url at the last minute thinking github's url is more stable, resulting it broken pipeline due to mismatched dirs 2021-02-08 15:19:37 you learn something new everyday ;) 2021-02-08 15:20:26 :/ 2021-02-08 15:40:20 and forget more ;) 2021-02-08 15:42:29 lol 2021-02-08 16:34:07 maxice8: do you still have the original atools-20.0.2 archive that you calculated the checksums over? 2021-02-08 16:38:24 dalias: i agree 2021-02-08 16:38:58 dalias: i was just saying that if hello72 convinced you otherwise i would follow that :) 2021-02-08 16:42:21 Has Hello71 been upgraded to Hello72? :P 2021-02-08 16:42:47 be kinda fun to have it auto-increment 2021-02-08 16:42:53 but this is my new alternate nick 2021-02-08 16:43:01 Yeah, assumed as much 2021-02-08 16:43:29 My client colors nicks based on name, so you now have a totally different color 2021-02-08 16:43:37 dalias: i think i came to the conclusion that for now we should ask politely for people to upgrade, and then if that doesn't work we'll go from there 2021-02-08 16:43:46 hm, does weechat ignore punctuation when coloring? 2021-02-08 16:44:04 I think it's some kind of hash bashed thing 2021-02-08 17:00:02 right, but i think e.g. _ikke_ and ikke show the same 2021-02-08 17:00:14 aha ok, I wouldn't know :P 2021-02-08 17:00:28 my own nick is always white 2021-02-08 18:21:39 1785/2033 Test #1785: fmpz_mpoly-test-t-div_monagan_pearce .................................. Passed 15.37 sec 2021-02-08 18:21:39 ERROR: Job failed: execution took longer than 1h0m0s seconds 2021-02-08 18:21:39 Start 1786: fmpz_mpoly-test-t-divides 2021-02-08 18:21:57 Not enough time to run 2000+ tests :/ 2021-02-08 18:22:07 ugh 2021-02-08 19:57:02 Ikke: I think yes 2021-02-08 19:57:20 maxice8: could you make it available somewhere? I'd like to compare 2021-02-08 19:57:40 I suspect it has to do with the gitlab upgrade, but want to be sure 2021-02-08 20:00:05 Sorry, no longer available 2021-02-08 20:00:18 oh, ok 2021-02-08 20:17:29 https://archlinux.org/todo/cleanup-of-python-setuptools-dependency-for-console-scripts/ 2021-02-08 20:19:15 aha, first we have to add it everywhere, now we have to clean it up again :P 2021-02-08 20:19:26 basically yes 2021-02-08 20:19:36 Python ecosystem is... suboptimal 2021-02-08 20:20:23 Can't wait to start using a pyproject.toml->setup.py converter 2021-02-08 20:29:31 is "CTEST_OUTPUT_ON_FAILURE=TRUE" recommended for ctest in check()? 2021-02-08 20:30:17 As long as the output is reasonable, I would say yes 2021-02-08 20:30:47 ahh 2021-02-08 20:31:16 makes it easier to see what's wrong when things fail on the builders or CI 2021-02-08 20:37:49 i assume it'll also hide the 400kb of 2000 successful tests log? ;) 2021-02-08 20:39:36 oh it doesn't 2021-02-08 20:42:21 From @leo's suggestion I am assuming 'cmake --build build' is preferred over 'make -C build'? 2021-02-08 20:42:45 yes 2021-02-08 20:44:44 --build is -B, right? 2021-02-08 20:45:00 nice, I was using cmake until I noticed a lot of /main/*/APKBUILD was on 'make -C', thought that was the more official style 2021-02-08 20:45:33 we're more conservative on making changes for packages in main to make backporting easier 2021-02-08 20:45:44 so you'll not always see the best style for those packages 2021-02-08 20:45:44 i see 2021-02-08 20:47:10 IIRC 'cmake -B build --target install' did not work, had to use --build build 2021-02-08 20:48:38 but -B is used on the first cmake, hmm 2021-02-08 20:51:04 everywhere I see --build 2021-02-08 20:51:17 DESTDIR="$pkgdir" cmake --build build --target install 2021-02-08 20:52:22 Ikke: fixed py3-setuptools situation on main/ 2021-02-08 20:52:24 on to community! :D 2021-02-08 20:53:43 Error in https://wiki.alpinelinux.org/wiki/Newbie_Alpine_Ecosystem “wiki.alpine.org” 2021-02-08 20:53:47 heh, I guess that's will be a bit more work 2021-02-08 20:53:47 Thanks 2021-02-08 20:54:19 fixed 2021-02-08 20:54:39 Fast :o 2021-02-08 20:54:48 :D 2021-02-08 20:54:55 Thank you ikke 2021-02-08 20:54:59 Bye 2021-02-08 20:55:00 simple fix 2021-02-08 20:55:02 bye 2021-02-08 21:08:09 when should -static not be added to subpackages? 2021-02-08 21:09:00 pkg such as argon2 has "$pkgname-static $pkgname-dev $pkgname-libs" 2021-02-08 21:09:46 alexy_: the default is to not add it, only when necessary 2021-02-08 21:10:17 and, I think we'll be phasing out -static subpackages for libraries 2021-02-08 21:11:26 ahh 2021-02-08 21:21:41 ikke: finally :) 2021-02-08 21:21:56 mps: I knew you would respond 2021-02-08 21:22:31 I'm 'fighting' for this about two years, if you remember 2021-02-08 21:22:48 I sure do 2021-02-08 21:23:00 next is vim split ;) 2021-02-08 21:23:42 just make a vim-minimal that has just basic vim 2021-02-08 21:24:03 this will not be hard, but 'git rm -f kde*' will not be easy :P 2021-02-08 21:24:57 maxice8: seems like borgbackup is missing dependencies 2021-02-08 21:25:12 kde packages should not affect you though 2021-02-08 21:25:19 if you do not use kde 2021-02-08 21:25:20 effing setuptools_scm 2021-02-08 21:25:22 jk 2021-02-08 21:26:04 maxice8: nice work, as #alpine-commits shows 2021-02-08 21:26:15 welcome 2021-02-08 22:32:47 main and community are done with py3-setuptools 2021-02-08 23:18:54 confy on x86_64 has a checksum problem 2021-02-09 00:56:11 https://github.com/pyca/cryptography/issues/5771 oh boy 2021-02-09 00:57:26 Python is like Firefox 2021-02-09 03:42:16 yet everyone is like "python2 must die in fire!!!1" even though it's the only stable version 2021-02-09 05:16:57 python cryptography is not python itself 2021-02-09 05:17:10 maxice8: i guess we hold py3-cryptography to 3.3.x for now 2021-02-09 05:18:36 Ariadne: yes 2021-02-09 05:19:07 sh4rm4^bnc: so dramatic 2021-02-09 05:21:50 sh4rm4^bnc: heh when python 3 first came out, the same fanatics were screaming python 3 must die 2021-02-09 05:22:24 maxice8: ok i mark as restricted 2021-02-09 05:27:38 ty 2021-02-09 05:36:07 wheej 2021-02-09 05:36:11 fun times 2021-02-09 05:36:22 RUST ALL THE THINGS 2021-02-09 05:56:09 their rationale is sound, but rust is not arch=all 2021-02-09 05:56:53 "While it is true that Rust has many benefits, the ecosystem is not ready for distros which are strongly oriented toward architecture portability." 2021-02-09 05:58:21 I guess these kinds of issues will start to happen more an more 2021-02-09 06:15:54 well alex is a rust dev 2021-02-09 06:16:02 and he appears interested in knowing more about our issues 2021-02-09 06:16:06 so maybe something will come of it 2021-02-09 07:03:22 'rust must die!' :) 2021-02-09 07:05:44 rust foundation is formed and by their list of director it can be seen 'what is rust' 2021-02-09 07:15:15 if rust-gcc is really happening, then it solves it soon enough 2021-02-09 08:17:46 Ariadne: Maybe I'm looking at the wrong repos, but did rust-gcc receive commits after June 2018 (or was it 19?)? 2021-02-09 08:26:44 I think the grsec people are being paid to work on it now 2021-02-09 08:57:02 morning! whats up? 2021-02-09 08:57:17 morning, torturing the builders 2021-02-09 08:58:12 heh... I think the servers actually like being tortured :) 2021-02-09 09:06:50 contributing to air pollution by wasting energy 2021-02-09 09:46:54 that python cryptography issue is deep. i thought i was done with the thread when it led me to a second discussion about python wheels for alpine 2021-02-09 09:47:10 https://discuss.python.org/t/wheels-for-musl-alpine/7084 2021-02-09 10:04:50 Neat, although it seems some folks in that thread think musl == alpine 2021-02-09 10:08:17 heh, besides openwrt practically it is :) 2021-02-09 10:12:56 I'm not sure if I did everything right here with this particular upgrade.. I looked for recent examples for similar situations: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18076 2021-02-09 10:17:06 (other than failing lint because of a comment format 'problem') 2021-02-09 10:18:23 nowadays development is done by 'monte carlo method' 2021-02-09 10:25:16 Ariadne: thank you for following up on the pythong crpytography issue. And I think you did a good job using a friendly tone 2021-02-09 10:25:44 1791/2033 Test #1791: fmpz_mpoly-test-t-divrem_ideal_monagan_pearce ......................... Passed 8.58 sec 2021-02-09 10:25:44 ERROR: Job failed: execution took longer than 1h0m0s seconds 2021-02-09 10:25:44 Start 1792: fmpz_mpoly-test-t-divrem_monagan_pearce 2021-02-09 10:25:46 I think we should consider add an instance to the python buildbot: https://github.com/pyca/cryptography/issues/5771#issuecomment-775785332 2021-02-09 10:25:46 Agreed 2021-02-09 10:25:47 so close :) 2021-02-09 10:26:05 alexy_: :) 2021-02-09 10:26:44 clandmeter, ncopa: where I can find the kernel configs that are used on the netboot kernels? 2021-02-09 10:27:00 ppc64le only made it to 688 2021-02-09 10:27:01 (I need to check what filesystems are supported for /sysroot) 2021-02-09 10:27:50 ncopa: who is paying the electricity bill? :) 2021-02-09 10:38:22 uh, first time I removed myself from maintainer field and moved packaged to unmaintained. not pleasant experience, must say 2021-02-09 10:40:26 mps: since you're here, any idea where I could find the kernel configs used in the netboot install? 2021-02-09 10:40:28 + 2021-02-09 10:41:18 skarnet: not sure but I think it is linux-lts what is used for netboot 2021-02-09 10:41:39 vmlinuz-lts, that's the binary 2021-02-09 10:42:01 I can see the binary, what I want to see is the config options that went into it 2021-02-09 10:42:24 skarnet: so, yes, look at main/linux-lts and config*virt.$arch 2021-02-09 10:42:41 I mean, aports repo 2021-02-09 10:42:57 ah, it's all in aports? ok, thanks :) 2021-02-09 10:43:55 skarnet: https://git.alpinelinux.org/aports/tree/main/linux-lts?h=3.13-stable 2021-02-09 10:44:05 thx 2021-02-09 10:44:33 do we have 3.13 netboot release, I wonder 2021-02-09 10:45:44 eh, yes, we have it 2021-02-09 10:49:07 okay, so ext4 is supposed to be supported, but it's not in /lib/modules 2021-02-09 10:49:16 it's marked as =m so it should be a module 2021-02-09 10:49:32 mount -t ext4 /dev/vda1 /sysroot answers EINVAL 2021-02-09 10:49:53 right 2021-02-09 10:49:53 (vda1 has been formatted as ext4) 2021-02-09 10:50:23 so afaict the ext4 module is missing 2021-02-09 10:51:01 I think we should build ext4 and f2fs 'in kernel' (monolithic) and not as modules 2021-02-09 10:51:11 I'm sorry to say this but I've now spent a total of 4 days trying to get an armv7 emulation running and the least I can say is that it's NOT turnkey or streamlined in the slightest 2021-02-09 10:51:36 it's not documented, which I can understand, and *it's not working at all*, which I'm more critical of 2021-02-09 10:52:18 skarnet: I would post my script for installing armv7 in qemu on x86_64 but I know that you don't like to run random script from the net 2021-02-09 10:52:44 you're not helping 2021-02-09 10:53:06 /o\ 2021-02-09 10:53:29 https://arvanta.net/alpine/install-arm-under-qemu/ 2021-02-09 10:54:21 yeah so you're using the vanilla kernel and a lot of manual setup 2021-02-09 10:54:35 yes 2021-02-09 10:54:47 it shouldn't have to be rocket science 2021-02-09 10:55:16 agree, but that is where I reached 2021-02-09 10:55:20 there are minimal installs, what are they good for 2021-02-09 10:55:59 and because I use bare metal arm boxes I didn't tried hard to make it a 'perfect' 2021-02-09 10:56:23 I'm just trying to replicate a minimal environment with Alpine binaries that are run under Docker 2021-02-09 10:56:34 I don't have Docker so I'm trying to launch a qemu instead 2021-02-09 10:56:39 why is it so hard 2021-02-09 10:57:06 minirootfs crashes under me, netboot doesn't have the proper modules 2021-02-09 10:57:36 I guess I'll have to do it your way and go full install 2021-02-09 10:57:37 great 2021-02-09 10:57:50 my 'solution' works, though it is far from perfect, I agree 2021-02-09 10:58:16 there's no virt install for arm, that would have been perfect for me 2021-02-09 10:58:30 and of course the vanilla kernel doesn't support virtio 2021-02-09 10:58:33 alpine-make-vm-image? 2021-02-09 11:00:00 thanks for the pointer 2021-02-09 11:00:27 in my huge naiveté I thought I would be able to, you know, reuse existing things you can download 2021-02-09 11:00:41 guess the only surefire solution is to do everything myself 2021-02-09 11:00:43 as fucking usual 2021-02-09 11:00:54 fwiw, netboot has the modules in the modloop 2021-02-09 11:01:08 in the modloop? 2021-02-09 11:01:13 that is why I made this scripts, we don't have 'ready-made' solution 2021-02-09 11:01:54 dne: is there anything else I'm supposed to do beside booting on the kernel-lts with the initramfs-lts? 2021-02-09 11:02:56 something like (this was is for 3.11): modloop=https://alpine.global.ssl.fastly.net/alpine/v3.11/releases/x86_64/netboot-3.11.6/modloop-lts 2021-02-09 11:02:58 mps: that's what I'm complaining about, it *looks very much like* there are ready-made solutions, but they're all red herrings 2021-02-09 11:03:16 httpswhat 2021-02-09 11:03:18 ncopa: yes, i was willing to personally operate a CI bot for them 2021-02-09 11:03:51 skarnet: that's the fastly domain that backs dl-cdn, which you needed to use for https before we provided our own cert 2021-02-09 11:04:20 skarnet: modloop mounts the kernel modules via a loop device 2021-02-09 11:04:21 yeah, again this is what I used for 3.11 a few months ago 2021-02-09 11:04:34 why are you people talking to me about https and certificates when I'm looking for something that will actually mount my rootfs 2021-02-09 11:04:55 aarch64 is a lot simpler https://arvanta.net/alpine/install-aarch64-qemu/ 2021-02-09 11:05:01 "skarnet │ httpswhat" 2021-02-09 11:05:23 skarnet: just a kernel does not give you any kernel modules, so they need to come from somewhere 2021-02-09 11:05:31 mps, yes, thanks, if I wanted aarch64 I would do aarch64 2021-02-09 11:06:11 ikke: there's an initramfs and it has vfat support in its /lib/modules 2021-02-09 11:06:38 isn't it the place where I'm supposed to get all the modules from? 2021-02-09 11:06:52 all this comes from limitations of qemy-system-arm 2021-02-09 11:07:23 mps: I'm well aware of the limitations of qemu-system-arm and I'm also fighting them, I'm not blaming them on Alpine 2021-02-09 11:07:42 but you just cannot blame it all on qemu-system-arm, no, sorry 2021-02-09 11:07:54 "It contains the full kernel module tree for the built kernel, not the more limited set included in the initramfs / initrd." 2021-02-09 11:08:29 we could make ready made images (as debian does) but no one done that, yet 2021-02-09 11:08:55 i found out about that cryptography thing after "hey, i want to do crypto fast in python, on my s390x machine" 2021-02-09 11:09:01 "LOL YOU NEED RUST FOR THIS" 2021-02-09 11:09:43 ikke: I just don't get how I'm supposed to use this if the initramfs I have just can't boot. Is it a drop-in replacement for the initramfs provided in netboot? 2021-02-09 11:10:05 i guess i should try again to bootstrap rust? 2021-02-09 11:10:06 idk 2021-02-09 11:12:22 jfc 2021-02-09 11:12:39 ikke: if you answered me, sorry, I missed it 2021-02-09 11:16:54 skarnet: I guess you used something like https://dl-cdn.alpinelinux.org/alpine/edge/releases/x86_64/netboot/initramfs-virt? 2021-02-09 11:17:06 (but for armv7 then) 2021-02-09 11:17:42 ikke: I tried this but it didn't worked for me 2021-02-09 11:18:54 actually I made armv7 image for qemu but can't host it on my slow link 2021-02-09 11:19:15 Ariadne: your comments in the thread were also educational, for someone like me 2021-02-09 11:19:18 skarnet: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.netboot.sh#L23 you see the initfs features is quite small 2021-02-09 11:21:18 ikke: I used the netboot tar.gz available on the main downloads page 2021-02-09 11:21:30 if it's not the correct one, this should be fixed 2021-02-09 11:21:48 https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/armv7/alpine-netboot-3.13.1-armv7.tar.gz 2021-02-09 11:22:10 ikke: thanks, but I'm done trying to be smart 2021-02-09 11:22:17 I'm going to use a full install and fuck it 2021-02-09 11:22:34 if you have a virt kernel for armv7 I'll take it 2021-02-09 11:22:37 else I'll use vanilla 2021-02-09 11:23:10 https://dl-cdn.alpinelinux.org/alpine/v3.13/main/armv7/linux-virt-5.10.12-r0.apk 2021-02-09 11:23:54 .apk ? I need to be able to boot on it, if there's no iso with it I can't use it 2021-02-09 11:26:44 ah, of course there's no standard armv7 iso, what was I thinking 2021-02-09 11:27:04 yes, because very little arm devices support booting from an iso 2021-02-09 11:27:16 afaik 2021-02-09 11:28:09 skarnet: I checked, the netbot archive does include a modloop file 2021-02-09 11:28:12 modloop-lts 2021-02-09 11:28:17 netboot* 2021-02-09 11:28:24 boot/modloop-lts 2021-02-09 11:28:40 ikke: but how am I supposed to use it?? 2021-02-09 11:28:48 skarnet: checking 2021-02-09 11:29:25 ah, it's mounted as a squashfs. 2021-02-09 11:29:40 yes, there is a modloop service 2021-02-09 11:29:51 so I need to provide it as a second device 2021-02-09 11:30:27 okay, I'll try, thanks 2021-02-09 11:30:53 the modloop service is what looks at the modloop kernel parameter 2021-02-09 11:31:50 It will look for the file in all mounted partitions 2021-02-09 11:32:00 yeah so it needs a partition to read it from 2021-02-09 11:32:20 that's my problem 2021-02-09 11:32:33 alternatively it can wget it from a url, which is what dne suggested 2021-02-09 11:32:34 my kernel just. won't. mount. any. partition. 2021-02-09 11:32:50 I'm not too familiar with the netboot environment 2021-02-09 11:33:05 But I would suspect that the files should be available 2021-02-09 11:33:17 wait, you set up a working network client in the initramfs? 2021-02-09 11:33:27 I guess it makes sense for something called netboot, eh 2021-02-09 11:33:44 I'll try. 2021-02-09 11:35:12 skarnet: you could try: modloop=boot/modloop-lts 2021-02-09 11:35:33 no, that won't work if there's no boot/ :P 2021-02-09 11:37:10 In a normal boot, you would add the required modules to the initramfs 2021-02-09 11:37:12 ncopa: i do think that it makes sense for the python-cryptography team to use rust for this 2021-02-09 11:38:04 i just think also that 3.3.x needs to be LTS for some period of time while rust finishes maturing 2021-02-09 11:38:29 i haven't read the details, but it sounds good to me 2021-02-09 11:38:52 rust for a thing like asn parsing makes sense. (why not python?) 2021-02-09 11:39:06 python-cryptography is supposed to be fast 2021-02-09 11:39:12 parsing in python is slow 2021-02-09 11:39:15 what i suspected 2021-02-09 11:39:16 ikke: /init still insists on mounting /sysroot before it tried modloop 2021-02-09 11:39:22 using something like cython would defeat the point 2021-02-09 11:39:24 so, no dice 2021-02-09 11:39:43 ncopa: do you know how netboot is supposed to be able to mount ext4 filesystems? 2021-02-09 11:39:44 if it can't mount /sysroot, it fails and drops me to a shell 2021-02-09 11:39:52 do you want me to mail you a raspberry pi 3 2021-02-09 11:40:12 i have like 10 of them 2021-02-09 11:40:19 yeah, i think the proper way forward is LTS cryptography 2021-02-09 11:40:30 i already have an rpi 3 2021-02-09 11:40:39 i was talking to skarnet :) 2021-02-09 11:40:45 oh :) 2021-02-09 11:40:59 Ariadne: isn't rpi3 aarch64? 2021-02-09 11:41:02 no 2021-02-09 11:41:02 it is 2021-02-09 11:41:04 i mean 2021-02-09 11:41:05 yes 2021-02-09 11:41:10 but in practice no 2021-02-09 11:41:17 it boots alpine aarch64 2021-02-09 11:41:29 hmm 2021-02-09 11:41:33 true 2021-02-09 11:41:41 but raspbian for rpi3 is armv7 2021-02-09 11:41:42 :P 2021-02-09 11:41:52 aarch64 works, it's only armv7 that does weird things 2021-02-09 11:42:02 rpi3 can boot either 2021-02-09 11:42:31 ikke, skarnet: the only purpose of initramfs is to mount the rootfs and switch root 2021-02-09 11:42:41 what if rootfs is ext4? 2021-02-09 11:42:50 netboot does not seem to include any modules for that 2021-02-09 11:43:22 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.netboot.sh#L23 2021-02-09 11:44:16 hum 2021-02-09 11:44:18 tbh it also fails with vfat, I tried 2021-02-09 11:44:28 even though it has the module >.> 2021-02-09 11:45:23 right, that's included with usb 2021-02-09 11:45:44 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L460 2021-02-09 11:46:12 yeah, the ext4 modules is not included 2021-02-09 11:46:33 skarnet: you need to add fat to modules=, and rootfstype=fat 2021-02-09 11:46:44 (or vfat, not sure) 2021-02-09 11:46:46 i wonder what the original thinking was with netboot 2021-02-09 11:47:08 it looks like its made to boot virtual machines with tmpfs as rootfs 2021-02-09 11:47:31 let me rephrase 2021-02-09 11:47:37 seems like the thinking was: if you need ext4 you have a disk and if you have a disk you can boot from the dist instead of the network 2021-02-09 11:47:37 also explains the use of modloop 2021-02-09 11:47:47 is there something I can use to do a standard Alpine install on an armv7 target 2021-02-09 11:47:54 given I have a kernel 2021-02-09 11:47:58 and if needed an initramfs 2021-02-09 11:48:09 and a virtual disk I can mount anywhere 2021-02-09 11:48:23 I just want a base Alpine install on my virtual disk so I can actually download apks and test shit 2021-02-09 11:48:46 and this looks harder to obtain than healthcare in the USA 2021-02-09 11:48:50 :) 2021-02-09 11:49:04 can it boot from the virtual disk? 2021-02-09 11:49:14 uboot? uefi? 2021-02-09 11:49:26 I don't need to bother with that 2021-02-09 11:49:33 qemu has a -kernel option 2021-02-09 11:49:54 oh, its virtual machine 2021-02-09 11:50:03 all the fancy stuff with uboot and whatnot is actually making my life *more* difficult 2021-02-09 11:50:14 yeah. it does 2021-02-09 11:50:24 yes, it's a VM because it's supposed to be, you know, easier than real machines 2021-02-09 11:50:29 I'm starting to reconsider 2021-02-09 11:50:31 :) 2021-02-09 11:50:48 skarnet: as long as it's x86_64 :P 2021-02-09 11:50:59 word 2021-02-09 11:51:47 looks like we dont do -virt 32bit arm. only aarch64 2021-02-09 11:51:50 skarnet: we don't provide a complete installed image for generic armv7 2021-02-09 11:52:03 we do provide a tarball though 2021-02-09 11:52:09 https://pkgs.alpinelinux.org/packages?name=linux-virt&branch=edge&repo=&arch=armv7&maintainer=? 2021-02-09 11:52:47 Ah, you mean a complete image 2021-02-09 11:53:03 ikke: yes, I heard that loud and clear from the start: "we don't provide the simple stuff you need", and it's what I've been complaining about for an hour. 2021-02-09 11:53:55 ncopa: I have no idea how to use the tarball, it's full of uboot shit and I don't know what parts of the tarball are relevant to me or what to do with them. 2021-02-09 11:56:43 Ariadne: fwiw there are better options if you're not stuck to tls/asn1/etc, but you probably know already 2021-02-09 11:58:57 skarnet: while i'm not terribly familiar with arm boot (despite spending several hours troubleshooting rpi), it seems like it might be easier to use the big blob, get it working, then delete the parts you don't need 2021-02-09 11:59:36 now if only there *were* a big blob 2021-02-09 12:01:04 the tarball i mean 2021-02-09 12:01:29 arm apparently doesn't understand the idea of self-contained disk images with standardized boot methods 2021-02-09 12:01:32 except efi... 2021-02-09 12:01:46 s/method/protocol/ 2021-02-09 12:01:46 Hello72 meant to say: arm apparently doesn't understand the idea of self-contained disk images with standardized boot protocols 2021-02-09 12:18:04 Hello72: in my case, i am implementing ActivityPub, which uses RSA keypairs in ASN.1 PEM encoding (: 2021-02-09 12:18:14 eww 2021-02-09 12:18:20 ncopa: alpine-rpi-3.13.1-aarch64.tar.gz.asc 28-Jan-2021 22:20 0 2021-02-09 12:18:41 activitypub is only like two years old, couldn't they have picked ed25519 or something -.- 2021-02-09 12:18:41 some guy came few days ago and reported that .asc file is empty 2021-02-09 12:18:46 skarnet: i think you can, create a vfat image with the content of alpine-uboot tar image. untar the boot/ directory from alpine-uboot image to get the kernel and initramfs. use qemu with the extracted kernel and initramfs and add the vfat image 2021-02-09 12:18:50 i havent tested it though 2021-02-09 12:18:58 Hello72: RSA was used for backwards compatibility with OStatus 2021-02-09 12:19:18 and activitypub is more than 2 years old. try like, 5 years old 2021-02-09 12:19:40 i think people still hated asn1 in 2010 though 2021-02-09 12:20:07 yeah well OStatus continued with it to be backwards compatible with Salmon Magic Signatures 2021-02-09 12:20:14 lol 2021-02-09 12:20:15 which was created by... Google. 2021-02-09 12:20:26 is it still actually backwards compatible? 2021-02-09 12:20:37 no 2021-02-09 12:20:45 i mean, OStatus is 2021-02-09 12:21:07 ActivityPub is a totally different protocol built on top of ActivityStreams 2.0 and linked data notifications 2021-02-09 12:21:47 just in case: does alpine-make-rootfs work to create cross-arch rootfses ? 2021-02-09 12:21:48 but to support situations where a homeserver may speak OStatus and ActivityPub at same time, RSA was chosen as the preferred keypair 2021-02-09 12:22:19 in theory you could do ed25519 but i dont think anyone actually implements support for that 2021-02-09 12:28:57 ncopa: do you know if alpine-make-rootfs can cross? 2021-02-09 12:32:05 dunno 2021-02-09 12:43:16 Ariadne: do you have the alpine instance python buildbot farm recorded in any ticket somewhere? so it is possible to follow the progress 2021-02-09 12:43:28 might make sense to have a ticket in our gitlab for it 2021-02-09 12:44:38 Ariadne: i also wonder if it would make sense to ask someone else to build and maintain that, to offload you. I think this might be something new contributors could help with 2021-02-09 12:53:43 could alpine-chroot-install and alpine-make-vm-image be hosted, or at least mirrored, at gitlab.a.o?> 2021-02-09 13:34:00 skarnet: you could use the static APK tools on a x86_64 machine to install a base armv7 Alpine into a disk image you create and partition (using loop device to mount it). Then use qemu-arm-static so that you can chroot into the image to setup bootloader. Finally use the resultant disk image with qemu-system-arm. That's what I do for making disk images for various architectures 2021-02-09 13:49:10 minimal: i dont think that will work 2021-02-09 13:55:28 Hi! I'm quite far into dev scripts and cli to create diskless alpine (apk overlays, basically). It works fine, except when the pkg I want to add a package that requires an additional kernel module. 2021-02-09 13:55:33 example: awall 2021-02-09 13:56:01 is there any place I can find ideas to integrate this kind of pkg into my apkovl? 2021-02-09 13:56:37 minimal: do you have an example, a script you could show me? 2021-02-09 13:56:39 (let me know if it is not the right channel as well) 2021-02-09 13:57:34 without going into complex scripts, it's a simple as installing awall in an APK overlay 2021-02-09 13:58:04 skarnet: if you dont use a bootloader every apk upgrade could break your modules 2021-02-09 13:59:02 clandmeter: what? I want a real installation on a *disk*, just like on a PC, and apk upgrades don't break that afaik 2021-02-09 13:59:21 you meantion you want to use -kernel option? 2021-02-09 13:59:27 *mention 2021-02-09 13:59:44 yeah, but I can extract the kernel np 2021-02-09 13:59:56 or I can use grub, who cares 2021-02-09 14:00:03 yes so you need to do that on each kernel upgrade 2021-02-09 14:00:05 I just want to boot the damn thing 2021-02-09 14:00:42 I'm asking for help, not for advice on what could break possibly in a potential future I have about 0.01% chances of reaching right now 2021-02-09 14:01:19 im trying to help if that is not clear. 2021-02-09 14:01:37 I understand. Thank you for that. But right now apk upgrade is the least of my worries. 2021-02-09 14:02:02 apk static wont help 2021-02-09 14:02:26 apk will run the post/pre install scripts and the arch does not match. 2021-02-09 14:03:53 You could disable post/pre-install script execution for the initial install and then manually generate the initramfs, but I don't know if we have a way to run the post-install scripts at a later point 2021-02-09 14:04:11 Or if you would have to reinstall all packages then to make sure you don't have broken packages (because of missing post-install scripts) 2021-02-09 14:04:17 there are more scripts 2021-02-09 14:04:25 like busybox applets 2021-02-09 14:04:26 skarnet: I have an Ansible playbook rather than a script 2021-02-09 14:04:40 how do you folks generate the rootfs for a vanilla install? it currently exists for about every arch except armv7, if I could just launch the procedure for armv7 it would be cool. 2021-02-09 14:04:57 I could extract the set of commands from the playbook for you 2021-02-09 14:05:14 how would you install a pkg with an additional kernel module for an apk static? 2021-02-09 14:05:36 or even better, if you could add armv7 (or armhf, or *gasp* both) to the list of vanilla isos you make available 2021-02-09 14:05:41 or even virt 2021-02-09 14:05:59 virt would actually be better since no real arm device uses isos 2021-02-09 14:07:07 rn you have virt isos for aarch64, x86 and x86_64. If I have a pointer on how to generate one for arm, I'll manage. 2021-02-09 14:07:10 you could use qemu-user, that would work 2021-02-09 14:07:23 actually, my scripts are exactly doing that... 2021-02-09 14:07:33 inside a docker container 2021-02-09 14:07:39 with qemu 2021-02-09 14:07:54 for armv7 included 2021-02-09 14:09:04 clandmeter: what would qemu-user work for? 2021-02-09 14:09:28 clandmeter: I my case it works fine for building RPI armv7 and aarch64 disk images (to then "dd" onto SDcard). For skarnet's case I guess the issue is the lack of a virt kernel for armv7 though with qemu-system-arm it should still work with the -lts kernel depending on what ARM machine he chooses for QEMU to emulate 2021-02-09 14:09:59 minimal: the lack of an Alpine rootfs that can run apk is more of a problem than the lack of a kernel 2021-02-09 14:10:32 minirootfs can run apk 2021-02-09 14:10:39 no it cannot 2021-02-09 14:10:46 I tried, it crashed 2021-02-09 14:11:08 skarnet: yupe, so like I said you can use the static built apk tool on a x86_64 machine to do a base install for armv7 into a disk image 2021-02-09 14:12:01 I have no idea how to do that or how the fact apk is static would help 2021-02-09 14:12:17 @skarnet: what is your issue? 2021-02-09 14:12:29 I wish I had only one 2021-02-09 14:12:44 then, what's your goal :) ? 2021-02-09 14:12:51 skarnet: i.e. apk --arch armv7 --initdb --allow-untrusted --root --update-cache add alpine-base grub-efi 2021-02-09 14:13:17 it you run that on an x86_64 machine it will install a *armv7* version of Alpine inside the specified directory 2021-02-09 14:13:22 the main issue is that my software packages in Alpine 3.13 break for some people, on armv7 only. It works on 3.12. I want to find out what's happening. 2021-02-09 14:13:40 Built on non-Alpine with the same version of musl, they work. 2021-02-09 14:13:55 so I want to reproduce a pristine Alpine 3.13 on armv7. 2021-02-09 14:14:21 testing on a rpi? 2021-02-09 14:14:34 sure, if I had one 2021-02-09 14:14:41 skarnet: did you see my command example above? 2021-02-09 14:15:09 minimal: yes, thanks. would it also install the base layout? 2021-02-09 14:15:24 alpine-base package achieves that 2021-02-09 14:21:05 chroot "$ROOTFS_DIR" /usr/local/sbin/apk.static \ 2021-02-09 14:21:05 --repository "$ALPINE_MIRROR"/"$ALPINE_BRANCH"/main \ 2021-02-09 14:21:05 --arch "$ARCH" \ 2021-02-09 14:21:05 --update-cache \ 2021-02-09 14:21:05 --initdb \ 2021-02-09 14:21:05 add alpine-base 2021-02-09 14:21:19 will put you in an armv7 chroot 2021-02-09 14:21:44 (replace ARCH and ALPINE_MIRROR and ALPINE_BRANCH 2021-02-09 14:21:57 @skarnet 2021-02-09 14:22:43 thanks. with that and what minimal told me I should be able to manage. 2021-02-09 14:22:51 If not, I'll come raging some more. :P 2021-02-09 14:23:43 :) 2021-02-09 14:23:48 lbu package -v - | tar -C /mnt -zxv > /tmp/ovlfiles 2021-02-09 14:23:48 apk add --root /mnt --initdb --update-cache --clean-protected --overlay-from-stdin --repository acct linux-XXX alpine-base grub grub-efi grub-bios efibootmgr zfs-lts zfs parted cryptsetup lvm2 dosfstools e2fsprogs bash sudo openssh < /tmp/ovlfiles 2021-02-09 14:23:55 if you want to get fancy ;) 2021-02-09 14:24:27 I don't want to get fancy, I want the simplest shit in the world to work 2021-02-09 14:27:21 yeah that's how I started too but once you start you can't stop, you want to go full automation 2021-02-09 14:28:16 I'm perfectly capable of overcomplicating things myself 2021-02-09 14:28:24 lol 2021-02-09 14:28:50 alexy_: there's no such thing as full automation as there's always something new to automate ;-) 2021-02-09 14:29:11 minimal: true ;) 2021-02-09 14:29:43 alexy_: what you using? shell scripts? I've got a monster Ansible playbook here 2021-02-09 14:31:39 minimal: yup, spent 2 months fine tuning a script to auto install alpine on zfs root on lvm/luks, thin efiboot, initramfs, the works 2021-02-09 14:32:40 alexy_: I'm about 14 months in with complete server hardening, cloud-init, and lots of other stuff 2021-02-09 14:32:54 minimal: that wiki is a newbie killer :) 2021-02-09 14:34:18 minimal: nice 2021-02-09 14:38:34 minimal: did you set the hap bit on your bios and reflash it, externally? :) 2021-02-09 14:38:43 heh that keyword just got me on a list 2021-02-09 14:38:59 any of you ever tried to go diskless? 2021-02-09 14:39:24 ...and dealt with kernel modules on the apk overlay? XD 2021-02-09 14:42:03 SrainUser: not to your extent I am sure, I'd like to learn more from you one day :) 2021-02-09 14:42:03 skarnet: yet another url https://arvanta.net/alpine/armhf-setup/ 2021-02-09 14:42:45 or maybe complete https://arvanta.net/alpine/ :) 2021-02-09 14:43:07 it actually is simpler than what you implemented... or should be, if these kernel modules were not an issue 2021-02-09 14:43:08 word of wisdom... never build your zfs pool on the latest zfs version 2021-02-09 14:43:12 alexy_: haven't gone to extreme security lengths, more OS and services hardening, plus automating the setup of the likes of metrics and logging ;-) 2021-02-09 14:43:35 mps: yay more context-free scripts! :P 2021-02-09 14:43:49 skarnet: yes 2021-02-09 14:44:35 but it is not made as script to be executed blindly but more as hints to those who have idea 'how things works' 2021-02-09 14:44:46 they* 2021-02-09 14:45:52 minimal: nice, i wish the grsec guy didn't sell out ;) 2021-02-09 14:46:10 now us minions only get the bugged version ;) 2021-02-09 14:54:13 would be nice to get true luks2 on grub 2021-02-09 14:58:14 alexy_: the next Grub release is due out in a couple of months and it'll have LUKS2 support 2021-02-09 14:58:39 there was mention of it on the Grub list 2021-02-09 15:50:43 alexy: wait, zfs on lvm? 2021-02-09 15:51:41 sure, I too use zfs on luks, even though you can (also) encrypt zfs datasets 2021-02-09 15:53:49 I was pretty happy, last year, when I successfully managed to remote upgrade a server from mdraid+lvm+ext4 to zfs 2021-02-09 15:59:33 omni: yes, zfs encryption is slow 2021-02-09 15:59:49 omni: nice, that's like walking on a wire ;) 2021-02-09 16:04:36 if alpine would add "ZPOOL_VDEV_NAME_PATH=YES" in their mkinitfs trigger that'd be nice too ;) 2021-02-09 16:09:48 grub-probe chokes without it 2021-02-09 16:15:32 alexy: yes, it was a fun challenge, and it'd been fine if I'd had to go to the DC, nothing crucial that server at that point 2021-02-09 16:15:56 alexy: would you file an issue so it's not lost? 2021-02-09 16:20:53 i thikn i broke github... 2021-02-09 16:21:03 github ? 2021-02-09 16:21:19 good news :) 2021-02-09 16:21:35 ^^ 2021-02-09 16:21:39 so, no more github 2021-02-09 16:21:50 Yeah, I rebased and push -f to https://github.com/python/cpython/pull/18380 but got some weird 500 errors. the PR didnt pick up my change 2021-02-09 16:22:30 and not it looks like i cannot comment :) "You can't comment at this time." 2021-02-09 16:22:41 but the comment went through? 2021-02-09 16:26:37 what if you change your TZ? :B 2021-02-09 16:26:48 lol 2021-02-09 16:30:08 :D 2021-02-09 16:31:13 omni: yup, i am writing a MR now 2021-02-09 16:55:06 omni: done, !18085 2021-02-09 16:59:16 during the development of the zfs root install script, I had experienced est over 500 times of "grub-probe: error: failed to get canonical path of X" 2021-02-09 16:59:34 that usually happen after a 5-15 seconds pause waiting for the mkinitfs trigger first :) 2021-02-09 17:00:52 everytime I ran "apk add --root /X --initdb --update-cache .... grub etc etc", that pause+error would show up ;) 2021-02-09 17:01:13 I doubt that zfs will ever be 'first class' subsystem on linux 2021-02-09 17:01:36 also happened alot during kernel module rebuild/testing 2021-02-09 17:02:14 imo, it's a waste of time to 'play' with it 2021-02-09 17:03:26 ubuntu have zfs on root, don't know how they got over the legal issue 2021-02-09 17:06:56 btrfs is good enough, but ZFS is like your first love ;) 2021-02-09 17:07:33 we forgot to add changed exfat drivers and exfatprogs to release note for 3.13-stable 2021-02-09 17:07:45 driver* 2021-02-09 17:08:42 Hello72: ^ 2021-02-09 17:30:19 hm 2021-02-09 17:30:38 is release notes my job now? 2021-02-09 17:38:36 It's everyones job 2021-02-09 17:46:19 #8633 could be closed 2021-02-09 18:03:47 Hello72: in last time I noticed that you care about it, sorry if I misunderstand that 2021-02-09 18:04:37 it's fine, but why can't you do it? :p 2021-02-09 18:05:16 I don't know wiki syntax 2021-02-09 18:06:05 Just edit the existing notes, you'll see soon enough 2021-02-09 18:40:45 hi 2021-02-09 18:41:24 are there any plans for clang 11? 2021-02-09 18:42:06 afaik, there were some issues with it 2021-02-09 18:44:02 what kind of issues? upstream or musl patches? 2021-02-09 18:44:22 trying to find a reference 2021-02-09 18:45:16 thx 2021-02-09 18:46:07 The problem was that there were some test failures and the contributor who opened on the MR didn't have time to fix it 2021-02-09 18:46:16 Currently busy too so I can't look into it either 2021-02-09 18:48:38 ok, thanks! 2021-02-09 18:48:52 aaahh, now I found the MR. I was just stupid, thanks! 2021-02-09 18:48:56 for reference: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13773 2021-02-09 18:50:26 !13773 2021-02-09 18:51:36 I'm waiting for it for zig upgrade 2021-02-09 20:00:56 that cryptography issue did get some attention apparently 2021-02-09 21:02:48 heh 2021-02-09 21:03:04 yes, ddevault pissed them off and they closed the issue 2021-02-09 21:03:26 locked, but yes 2021-02-09 21:03:28 story of my life 2021-02-09 21:04:05 i understand your frustration but i suspect that they are more resistant to having a cryptography LTS as a result of it :/ 2021-02-09 21:04:41 oh well 2021-02-09 21:05:08 we will just continue to maintain py3-cryptography 3.3.x ourselves if necessary until we can ship a newer version as a system package 2021-02-09 21:05:27 I struggle to be reasonable when someone is trying to justify discrimiating against perfectly valid users or use-cases over some dumb bullshit 2021-02-09 21:05:37 what I said in that thread was probably not called for 2021-02-09 21:05:40 sorry 2021-02-09 21:06:04 i agree with you that it was not acceptable to introduce rust so abruptly 2021-02-09 21:06:30 I'm kind of curious how many errors get introduced by porting everything to rust 2021-02-09 21:06:32 though i also agree with them that it is a lot easier to verify the security properties of a rust program than a C program (though that slide deck was incredibly bereft of content) 2021-02-09 21:06:58 I wish that Mozilla had kept quietly ruining the internet instead of making rust so they could ruin everything else 2021-02-09 21:07:16 yeah that slide deck was a complete joke, I hate that people are expecting me to have taken it seriously 2021-02-09 21:07:34 well i think rust ecosystem is now starting to mature 2021-02-09 21:07:41 wasn't even *good* fake science 2021-02-09 21:08:02 once rust gcc backend is merged (which appears like it may land as early as GCC 12, but probably GCC 13) 2021-02-09 21:08:10 i think that these issues are ultimately solved 2021-02-09 21:08:40 I agree, that'll help a lot 2021-02-09 21:08:55 but it'll just be degrading rust from "awful nuisance" to "about as bad as C++" 2021-02-09 21:09:42 hmm, i am not sure i agree. as i said, it's a lot easier to verify rust programs than C (if you do not use unsafe{} anyway) 2021-02-09 21:10:07 oh, better in that sense 2021-02-09 21:10:12 but since I write neither it's the same level of annoying 2021-02-09 21:10:16 takes a long time to compile and I don't like debugging it 2021-02-09 21:10:18 And even then you only have a few spots you have to verify 2021-02-09 21:10:32 Since everything in C is in one big unsafe{} block 2021-02-09 21:10:34 I certainly can understand developers wanting something 'safer' than c 2021-02-09 21:10:54 rust is really good as a C++ replacement 2021-02-09 21:10:55 C can be written safely 2021-02-09 21:11:02 can be 2021-02-09 21:11:03 but understand that I view C++ as toxic waste 2021-02-09 21:11:05 be it's difficult\ 2021-02-09 21:11:08 there is an entire book on how to do it called the MISRA C standard 2021-02-09 21:11:08 so rust is just less toxic waste 2021-02-09 21:11:12 can be, if you're really, really careful 2021-02-09 21:11:14 it is not even that difficult 2021-02-09 21:11:23 you just have to use the correct constructions 2021-02-09 21:11:25 you can also use formal verification, like seL4 2021-02-09 21:11:29 With Rust the compiler does it for you so you can't mess it up 2021-02-09 21:11:30 once you learn them, its easy 2021-02-09 21:11:34 I guarantee you seL4 has fewer bugs than redox, for example 2021-02-09 21:11:48 Cogitri: GCC can verify conformance to MISRA standard actually 2021-02-09 21:13:14 the main safety problem with C is that C strings are just null-terminated arrays 2021-02-09 21:13:31 "but malloc is unsafe" is a red herring, rust uses malloc underneath 2021-02-09 21:13:34 And that arrays don't have a length attached to them 2021-02-09 21:13:51 Sure, rust uses malloc too, but it ensures things live long enough 2021-02-09 21:13:52 which is the same issue 2021-02-09 21:13:59 c strings are arrays 2021-02-09 21:14:18 anyway, those issues are trivially overcome by using a safer array type 2021-02-09 21:14:20 And things like variables being immutable by default is nice in Rust 2021-02-09 21:14:34 they're not immutable though 2021-02-09 21:14:49 Ariadne: but I see every project inventing their own safe strings 2021-02-09 21:14:50 if i can inject code at runtime, it can change them 2021-02-09 21:15:09 ikke: yes, it would be nice to have safe arrays in C standard 2021-02-09 21:15:41 you can get the same result as rust's "immutable" variables by using const 2021-02-09 21:16:00 Ariadne: good point :) 2021-02-09 21:16:07 It's not by default and you don't have transitive const pointers 2021-02-09 21:16:08 best one 2021-02-09 21:16:20 true 2021-02-09 21:16:20 As in you can still manipulate structs if you get a const pointer 2021-02-09 21:16:29 not true 2021-02-09 21:16:49 gcc will complain if you try to write to members of a const struct pointer 2021-02-09 21:18:01 ^ 2021-02-09 21:20:36 my point is largely that if you look at their install directions 2021-02-09 21:20:40 it is basically 2021-02-09 21:20:59 "haha you need rust, and the rust you need is Debian sid, Alpine >3.13 and not in CentOS at all, good luck!" 2021-02-09 21:21:02 https://news.ycombinator.com/item?id=26071379 2021-02-09 21:21:20 we need an LTS for *that* reason 2021-02-09 21:21:29 Ariadne: that's a general tendency in the software world 2021-02-09 21:21:33 only bleeding edge counts 2021-02-09 21:22:53 ah, hacker news 2021-02-09 21:22:59 we can watch hacker news incorrect each other 2021-02-09 21:29:01 the main safety problem with C is that C strings are just null-terminated arrays 2021-02-09 21:29:16 I disagree, that's not the root of the problem, just the most popular example 2021-02-09 21:29:37 the root of the problem is that there are no widely publicized good practices for C object management 2021-02-09 21:29:45 (of which strings are the prime example) 2021-02-09 21:30:21 with good practices for object storage and ownership, C strings become a breeze, just like any typical C memory issue 2021-02-09 21:30:51 what I would really like to see in a real successor for C is syntactic sugar for object storage and ownership 2021-02-09 21:31:07 with that, 95% of common problems would be solved 2021-02-09 21:31:31 unpopular opinion: I actually like C strings 2021-02-09 21:31:42 they make sense with the language 2021-02-09 21:32:08 but since they involve storage, they're inherently harder to manipulate than native types 2021-02-09 21:32:27 which is what should be made easier and less ridden with pitfalls 2021-02-09 21:38:53 fair 2021-02-09 21:40:37 anyone know offhand the magic trick for getting out-of-tree modules to find System.map for linux-lts 2021-02-09 21:43:31 nevermind, figured it out 2021-02-09 21:52:36 in other news, the rust devs reached out to me by email to discuss sponsoring a rust dev to debug the issue we face with bootstrapping rust 2021-02-09 21:52:46 so i outlined the problem to them 2021-02-09 21:53:25 i'm more than capable of finishing the rust bootstrap on mips64 and s390x obviously, i just need the ability to actually generate the cross compilers :) 2021-02-09 21:54:21 that's good news 2021-02-09 21:55:20 i'm like, well 2021-02-09 21:55:33 cash doesn't solve this, unless cash is directed at someone who can debug this issue :P 2021-02-09 21:56:00 right 2021-02-09 21:56:47 you could not pay me enough to touch a rust bootstrap again 2021-02-09 21:56:58 thanks for suffering through it for all of us, Ariadne 2021-02-09 21:57:28 well once this issue is fixed 2021-02-09 21:57:39 it should be easy to bootstrap 2021-02-09 22:11:20 I worked on rust for alpine aarch64 and armv7 about two years ago (iirc), not nice work but not worst 2021-02-09 22:11:59 that was time when I thought rust is (hmmm) ok lang 2021-02-09 22:19:18 Getting Alpine and Void bootstrap working on aarch64, armv7 and so on wasn't so bad 2021-02-09 22:19:29 s390x seems like kind of a pain though 2021-02-09 22:25:04 the issue has nothing to do with s390x 2021-02-09 22:25:14 we can't build a cross compiler for aarch64 on x86_64 2021-02-09 22:25:37 it does not matter what targets we choose 2021-02-09 22:25:46 none of them will cross 2021-02-09 22:27:41 Weird that it doesn't work for us, worked just fine on Void w/ xbps-src 2021-02-09 22:29:12 i suspect it is because we define custom targets 2021-02-09 22:29:29 So does Void 2021-02-09 22:30:09 not from what i saw 2021-02-09 22:30:25 instead they patch the musl targets that already exist to conform to what a musl distro actually wants 2021-02-09 22:32:46 Ah right 2021-02-09 22:33:17 Ah btw, when I emailed Rust devs if we can keep calling our rust rust they said they wouldn't mind us upstreaming our triplets 2021-02-09 22:42:25 relevant: screen buffer overflow found caused by utf8 characters. Can be triggered by running irssi in screen 2021-02-09 22:44:05 Apachez already linked to this in #alpine-linux: https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00000.html 2021-02-09 23:35:50 what is the issue here? 2021-02-10 00:25:30 #10071 was solved by commit 16f328d6e4a9bc97cd6810da641287cb1921a6d9 2021-02-10 00:35:19 dalias: the issue is that py3-cryptography adds rust dependency, but rust is not on all archs 2021-02-10 01:51:03 okay, so I kinda sorta managed to boot an armv7 Alpine VM, and I can definitely confirm that the apk binary is broken 2021-02-10 01:51:13 gets me 'Illegal instruction' every time 2021-02-10 01:51:32 will try with the static version if I can install it 2021-02-10 01:55:01 apk.static seems to work at first glance, so it may be something in the libraries 2021-02-10 02:00:36 nope, apk.static update works but apk.static upgrade and apk.static fix do not 2021-02-10 02:03:03 how is this even working for other people? 2021-02-10 02:03:04 ssh-keygen: generating new host keys: RSA Illegal instruction 2021-02-10 02:04:31 I give up, will wait until someone can get me an account on a real raspberry pi with Alpine 3.13 on it. 2021-02-10 02:09:31 any chance this could get reviewed/merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18075 2021-02-10 02:42:50 it's not exactly uncommon that qemu doesn't emulate something properly 2021-02-10 02:55:53 [20:04] I give up, will wait until someone can get me an account on a real raspberry pi with Alpine 3.13 on it. 2021-02-10 02:56:02 does it need to be rpi? 2021-02-10 02:56:15 i have some honeycombs in my colo and could provision a VM 2021-02-10 03:33:27 i meant this: 2021-02-10 03:33:27 instead they patch the musl targets that already exist to conform to what a musl distro actually wants 2021-02-10 03:37:44 dalias: rust defaults to static linking if target is musl 2021-02-10 03:37:51 dalias: and dynamic linking if target is glibc 2021-02-10 03:38:26 dalias: so they patch the targets in rust so they use dynamic linking instead 2021-02-10 03:39:25 uhg why? 2021-02-10 03:39:27 dalias: this was explained by rust devs as "people only use static linking with musl anyway" 2021-02-10 03:39:40 ... 2021-02-10 03:39:56 yes surely firefox is using static linking 2021-02-10 03:39:58 *facepalm* 2021-02-10 03:40:06 it would be if we did not fix it 2021-02-10 03:40:07 :) 2021-02-10 03:40:18 that would be awesome if firefox would/could 2021-02-10 03:40:42 but pretty sure it uses GL (indirectly) and the libxul framework doesn't support static linking 2021-02-10 03:43:41 "x.py build is broken for cross compiling" 2021-02-10 03:43:47 coooooooool 2021-02-10 03:43:51 thanks, i hate it 2021-02-10 03:55:35 i need some1 with access to builders to help debug grafana 2021-02-10 03:56:13 run cd community/grafana && abuild fetch && abuild unpack && diff src/grafana-7.4.0/public/views/index* 2021-02-10 03:56:21 diff must not be empty 2021-02-10 03:56:56 umm 2021-02-10 03:57:08 what builder do you want that done on 2021-02-10 03:58:03 i checked on x86, amd64 and aarch64 edge, all of them built problematic apk 2021-02-10 04:01:37 this is hopeless 2021-02-10 04:02:02 kaey_: ok, i dont have access to those ones 2021-02-10 04:02:14 you might wait for ikke :) 2021-02-10 04:03:18 ok. but if you have access to some other i can check if it's broken there as well 2021-02-10 04:16:07 the problem with grafana is that index-template.html somehow overwrites index.html 2021-02-10 04:16:35 locally and ci built apk are correct (https://gitlab.alpinelinux.org/kaey/aports/-/jobs/318055) 2021-02-10 04:16:47 so this is a problem only on builders 2021-02-10 05:30:28 kaey_: hey 2021-02-10 05:33:27 whoa 2021-02-10 05:33:54 i might have fixed rust cross compile 2021-02-10 05:34:17 this crap about x.py build might be accurate 2021-02-10 05:34:29 ! 2021-02-10 05:36:11 kaey_: the output is non-empty 2021-02-10 05:39:31 teste in x86_64 2021-02-10 05:44:39 @ikke: hi. can you build full apk then (abuild -r) then unpack it and see if those files differ there? 2021-02-10 05:45:17 I could just unpack the existing package on the builder 2021-02-10 05:45:58 existing package on mirrors is definetly broken rn. need to find what broke it 2021-02-10 05:47:45 probably in the package phase 2021-02-10 05:47:48 (ie, install) 2021-02-10 05:47:54 in the package they are the same indeed 2021-02-10 05:50:11 but if you download artifact from ci job I linked above you'll see they are different there 2021-02-10 05:50:22 going afk 40-60 min 2021-02-10 05:50:25 hmm 2021-02-10 05:57:34 Building stage1 std artifacts (x86_64-alpine-linux-musl -> aarch64-alpine-linux-musl) 2021-02-10 05:57:36 well, this is new 2021-02-10 05:57:56 i'm doing it first with two known good ports 2021-02-10 05:58:07 vs last time where i tried on ppc64le 2021-02-10 05:59:13 wait 2021-02-10 05:59:19 i wonder if my s390x triplet is wrong 2021-02-10 06:21:07 -------------: Os { code: 8, kind: Other, message: "Exec format error" }', src/bootstrap/bin/rustc.rs:152:22 2021-02-10 06:21:10 sad trombone 2021-02-10 06:21:38 :( 2021-02-10 06:22:01 it tried to run the aarch64 compiler 2021-02-10 06:23:27 kaey_: if I build it again, the resulting package does have different files 2021-02-10 06:23:33 (on the builder) 2021-02-10 06:29:48 @ikke: i already tried revbumping and that didn't help https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17954 2021-02-10 06:29:57 odd 2021-02-10 06:52:57 however, in order to try to run aarch64 rustc 2021-02-10 06:53:02 it has to produce an aarch64 rustc :) 2021-02-10 07:00:47 @ikke: should i try bumping it again or are you still looking? 2021-02-10 07:02:10 I have no time to look further atm 2021-02-10 07:02:41 perhaps include some temporary logging statements to check what is happening? 2021-02-10 07:05:18 will do, but can't log anything after package() 2021-02-10 07:21:01 good morning 2021-02-10 07:21:10 morning 2021-02-10 07:29:16 o/ 2021-02-10 07:30:09 \o 2021-02-10 07:35:31 net-snmp was being funny 2021-02-10 07:35:42 net-snmp-gui needs net-snmp-perl, but it depends on perl-net-snmp 2021-02-10 07:35:48 also there was a comment # needs perl-tk 2021-02-10 07:35:53 which is in the repos :D 2021-02-10 07:36:37 to be fair it is easy to confuse `perl-net-snmp` (perl module) and `net-snmp-perl` (bindings) 2021-02-10 07:37:35 !18103 2021-02-10 09:20:52 notcurses is failing on x86_64 2021-02-10 09:21:36 Seems to be used by a single package, can I just disable them both? 2021-02-10 09:21:46 (for that arch) 2021-02-10 09:25:22 PureTryOut[m]2: looks like only test fail, not build 2021-02-10 09:27:12 Yes but seems most of the time the entire package gets disabled then, happened for multiple of mine 2021-02-10 09:29:06 upstream is responsive, maybe inform him about this failed tests 2021-02-10 09:30:02 Him being Nick Black? Is there any chance he is in this channel? 2021-02-10 09:30:38 Oh I can see the Github repo having commits this last minute, I'll make an issue there 2021-02-10 09:30:41 yes, this is name, sometimes he is here but I forgot his irc nick 2021-02-10 09:30:59 There is a Nick here, nickd25, idk if that's the one though 2021-02-10 09:31:13 iirc, first letter is 's' 2021-02-10 09:32:03 uhhh, maybe after yet two coffee ... 2021-02-10 09:32:31 Ok nvm, I'll just create a Github issue 2021-02-10 09:33:00 you mean gitlab? 2021-02-10 09:34:06 I think I have his mail address, will look now 2021-02-10 09:34:36 Nah Github, as in the upstream repo 2021-02-10 09:36:06 A thought prompted by a friend's question on Twitter about updating Alpine containers. Would there be any benefit in providing a docker container built from 'Edge' every time a build was completed? Or perhaps daily? 2021-02-10 09:36:32 PureTryOut[m]2: ah, ok 2021-02-10 09:36:40 Ad 2021-02-10 09:37:32 anno domini ? :) 2021-02-10 09:37:48 adhawkins: at least the current process, it requires tags to be created, which takes care of 2021-02-10 09:38:12 every time a build of a package on the builders was completed ? 2021-02-10 09:39:20 adhawkins: yes, if your friend report bugs, this would benefit to alpine 2021-02-10 09:41:34 PureTryOut[m]2: '# Maintainer: Nick Black ' of notcurses 2021-02-10 09:42:31 mps, ikke, maxice8 He's primarily after a docker container base that's 'responsive' to security fixes and the like. I thought this might be a good way? Failing that, is the docker container automatically updated if a security fix were pushed to the latest stable release say? 2021-02-10 09:44:40 adhawkins: I don't know, but I think update is done only on releases (minor and major) and not 'daily' 2021-02-10 09:44:59 We try to fix security issues on all releases 2021-02-10 09:45:14 just look at the recent merge requests I made that fix CVE-2021-0326 on wpa_supplicant from EDGE to 3.10 2021-02-10 09:45:27 mps: I think that's his 'complaint'. For example, the latest docker container was last built 12 days ago. Have there been any security fixes since then? Or would they have triggered a build? 2021-02-10 09:45:34 the only possible advantage is having a security fix that slips through the release notes 2021-02-10 09:45:45 Complaint is the wrong word, but can't think of a better one. 2021-02-10 09:49:42 maxice8: When your wpa_supplicant fix was made to 3.10, would that have triggered a rebuild of the 3.10 container? 2021-02-10 09:50:14 no, only on the next stable release 2021-02-10 09:50:49 Ok, I think that's his issue. He'd like to see the containers rebuilt if any fixes were made to that release. Would that be possible do you think? 2021-02-10 09:51:36 adhawkins: it would only make sense for the base packages 2021-02-10 09:52:20 musl, busybox 2021-02-10 09:52:54 Mentioned to him that we're discussing it in here to see if he is interested in dropping in. 2021-02-10 09:53:05 Other software you have to always install anyways from the mirrors, sou you'll get the latest version anyway 2021-02-10 09:53:14 This is the tweet where the discussion started: https://twitter.com/GlennPegden/status/1358837516468686849 2021-02-10 09:53:48 That's security theater 2021-02-10 09:54:06 It does not effectively do anything 2021-02-10 09:54:25 He works in security, so I assume he has a reason for asking. 2021-02-10 09:54:58 Other then security theater? 2021-02-10 09:55:10 Yes, I imagine so. 2021-02-10 09:56:15 Rebuilding an image because some package in the repo is updated that is not part of that image does not effectively change anything 2021-02-10 09:57:15 ikke: Yes, I appreciate that. Perhaps his question is relating to how quickly security fixes are pushed to the repos rather than the base images. 2021-02-10 09:57:23 'most frequently updated' sounds like security theater to me 2021-02-10 09:57:57 ikke: +1 2021-02-10 10:00:10 adhawkins: the alpine image is very slimmed down, so there is not a lot to update 2021-02-10 10:01:34 Perhaps I've misunderstood the thrust of the original question. Perhaps it was triggered by security fixes not being included in stable releases 'quickly' enough for him, rather than the images themselves being out of date. 2021-02-10 10:02:44 maybe run apk upgrade every 15 minutes ;) 2021-02-10 10:03:09 alexy: That won't help unless security fixes are applied 'quickly' :) 2021-02-10 10:04:00 Yes, I think they meant that we don't apply security fixes to our packages quickly enough and not that the docker images aren't rebuilt often enough 2021-02-10 10:04:17 Which is a fair point, we tend to not have enough volunteers which backport stuff 2021-02-10 10:04:36 That does sound more likely now that I realise how little is in the actual docker base image. 2021-02-10 10:05:24 I think newer releases are fixed quite soon 2021-02-10 10:05:39 It's the older releases which are harder 2021-02-10 10:06:21 Which we try to fix by moving things to community that we need to backport manually 2021-02-10 10:06:27 Which I tbi k 2021-02-10 10:06:33 Ok. I'd imagine he'd tend to run 'latest-stable', but obviously don't know. 2021-02-10 10:07:10 Which I think we is a security concern on its own 2021-02-10 10:07:11 Yes, for newer releases where backporting things isn't a lot of effort we're pretty OK, but for older releases not so much I think 2021-02-10 10:07:27 I think a huge problem is also that many users aren't aware of the 6 months of support for community 2021-02-10 10:07:42 We really need some mechanism for apk to print that users are using a EOL repo 2021-02-10 10:07:55 Maybe some EOL date encoded in the APKINDEX or something like that 2021-02-10 10:09:44 that's the kind of feature that would need to be backported 2021-02-10 10:11:13 and it's also really easy to just not look at the logs and never notice it, so maybe it would be nice to send a mail on the mailing list 2021-02-10 10:11:31 (and maybe some other channel too) 2021-02-10 10:12:48 Yup, we need to be more explicit about that 2021-02-10 10:13:16 https://alpinelinux.org/releases/ also doesn't mention it :/ 2021-02-10 10:14:21 It does 2021-02-10 10:15:01 Oh, I'm blind, `the community repository is supported until next stable release.` 2021-02-10 10:15:20 I think ideally the EOL date column would be split into main and community 2021-02-10 10:15:38 Easy to just glance at the dates without reading the text at the top 2021-02-10 10:16:49 Is that website a git repo? 2021-02-10 10:19:20 Yes 2021-02-10 10:32:30 Ariadne: at this point I'll take anything I can get, so honeycombs would be great - worst case is I can't reproduce the problem on it 2021-02-10 10:32:34 thanks a lot :) 2021-02-10 10:35:39 skarnet: apk works fine on two of my armv7 SBCs, alpine 3.13-stable 2021-02-10 10:36:20 but I didn't tested 3.13 armv7 under qemu 2021-02-10 10:36:21 yeah I'm not concerned about apk, apk crashing on qemu is a *different* problem that I'm happy to delegate to you folks 2021-02-10 10:36:40 apk crashing was just an additional obstacle in the way of testing what I really want to test 2021-02-10 10:36:53 aha, ok 2021-02-10 10:37:03 and having an account on an armv7 machine with a working apk will be great :P 2021-02-10 10:37:58 I have armv7 lxc, no serious issues 2021-02-10 10:39:22 well some people do have issues with the interaction between my software and the new time64 musl and I want to understand what's going on 2021-02-10 11:07:37 skarnet: I've just run that docker container on our armv7 CI and it works without issue there 2021-02-10 11:07:53 "The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested" This looks suspect 2021-02-10 11:10:54 this _is_ on qemu btw, but not emulated (armv7 on aarch64 hw) 2021-02-10 11:14:08 which docker container? 2021-02-10 11:15:02 it's possible that apk's illegal instruction comes from a bug in qemu-system-arm but I'm not going to spend any time on this 2021-02-10 11:19:40 Just got an email about someone using net-core 2.2 on Alpine 3.8 and libgdiplus from Edge 2021-02-10 11:19:51 skarnet: they link to a dockerfile 2021-02-10 11:20:06 I cloned the project and built the image 2021-02-10 11:20:25 I'll try to run the armv7 image on a aarch64 host, see what happens then 2021-02-10 11:21:00 ACTION wishes net-core was available in the repos actually 2021-02-10 11:21:30 skarnet: oh wait, the qemu vm is actually aarch64 2021-02-10 11:21:41 Microsoft builds images for it apparently 2021-02-10 11:22:10 Yeah they do, but you have to get those separately rather than `apk add net-core` or whatever 2021-02-10 11:22:22 yes, unfortunately 2021-02-10 11:22:53 I took a shot at it at some point https://github.com/dotnet/source-build/issues/1868 2021-02-10 11:23:04 Some problems are blocking it however 2021-02-10 11:23:19 oh 2021-02-10 11:24:12 skarnet: same with arm32v7/alpine:3.12 2021-02-10 11:24:14 as base 2021-02-10 11:24:32 (including that warning that I pasted) 2021-02-10 11:24:37 yeah, never heard any issue with 3.12 2021-02-10 11:24:51 trouble only happens with time64 on armv7 2021-02-10 11:25:03 ah, I need to adjust the dockerfile more 2021-02-10 11:25:42 skarnet: ok, yes, now I can reproduce it 2021-02-10 11:25:55 oh, great :D 2021-02-10 11:26:02 next step: get me a shell on your container :D 2021-02-10 11:26:15 (and install strace) 2021-02-10 11:26:38 skarnet: let's see if I can reproduce it in plain lxc (without docker0 2021-02-10 11:26:45 This is on the actual CI host 2021-02-10 11:26:55 ikke: whatever happens, thanks for the time you're putting into this 2021-02-10 11:27:31 skarnet: which issue are you trying to reproduce? 2021-02-10 11:28:00 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12346 2021-02-10 11:28:51 ^ and also another problem that was independently reported to me on a rpi1b, that I suspect is related 2021-02-10 11:29:15 skarnet: you are on windows? 2021-02-10 11:29:27 :D 2021-02-10 11:29:34 yes, but I don't see how it's relevant 2021-02-10 11:31:34 you can run alpine in armv7 mode on windows 2021-02-10 11:31:45 is that not what you are looking for? 2021-02-10 11:32:36 no, I'm not touching WSL with a 10-foot pole 2021-02-10 11:33:10 given the karma I have with pure 2021-02-10 11:33:25 Linux emulators, I'm *not* adding Windows problems on top of it 2021-02-10 11:35:49 i mean directly from docker, but it uses wsl as you mention. 2021-02-10 11:37:32 the interactions between my windows desktop and my Linux work are limited to virtualbox and putty and I'm not willing to extend the contact surface 2021-02-10 11:39:16 mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16022#note_141369 <- Want me to open an issue about that? 2021-02-10 11:42:19 skarnet: at least for now, an strace: https://termbin.com/oy3q 2021-02-10 11:42:21 Cogitri: to me it looks like gdm problem/bug, but I'm not against closing this MR 2021-02-10 11:43:30 Well, the MR is already merged 2021-02-10 11:43:47 never used gdm so I don't have experince with it 2021-02-10 11:43:55 ah 2021-02-10 11:44:09 Maybe we just have to add the GDM user to an additional group or something, but I don't really have a clue about X 2021-02-10 11:44:12 then yes, make bug report 2021-02-10 11:44:44 will be afk now 2021-02-10 11:45:01 ikke: thanks, but that's hard for me to read like this ^^ that's why I'd like a shell, to have flexibility and be able to trace exactly the parts I need, and work on it dynamically 2021-02-10 11:45:23 yeah, understood 2021-02-10 12:47:58 adapted my script to boot armv7 under qemu on x86_64 in less than few minutes, run it I and got armv7 login prompt 2021-02-10 12:48:09 all took less than 5 minutes 2021-02-10 13:00:17 congratulations, do you want a medal? 2021-02-10 13:00:37 huh 2021-02-10 13:01:46 I have real medals and don't need virtual ones 2021-02-10 13:02:02 :) 2021-02-10 13:02:38 mps: how did you boot it? with bootloader? 2021-02-10 13:03:27 in install phase by -kernel -initrd and -dtb params 2021-02-10 13:03:41 later with qemu u-boot.bin 2021-02-10 13:12:41 /!\ this channel has moved to #nyymit /!\ 2021-02-10 13:13:10 /!\ this channel has moved to #nyymit /!\ 2021-02-10 13:18:11 /!\ this channel has moved to #nyymit /!\ 2021-02-10 13:33:49 ikke: ping 2021-02-10 13:34:25 can you allow edit on !17964 ? 2021-02-10 13:34:41 idk why but it seems like either aports-qa-bot failed to enable collaboration or the author disabled it 2021-02-10 14:10:13 610332073 Dec 30 10:26 supertuxkart-data-1.2-r0.apk 2021-02-10 14:10:15 lol 2021-02-10 14:10:54 so these games are why it took so long to clone the repo ;) 2021-02-10 14:14:21 these games will ruin alpine 2021-02-10 14:16:23 If noarch was actually noarch, it would take less time as it wouldn't be duplicated per arch 😉 2021-02-10 14:29:37 PureTryOut[m]2: lol so it was yours ;) 2021-02-10 14:29:59 !18116 2021-02-10 14:34:19 does it build under an hour? :) 2021-02-10 14:36:52 Yes ofc 2021-02-10 14:39:22 It completed within 3 minutes, only failed because of too big artifacts 😉 2021-02-10 14:39:51 Actually, 15 minutes, depending on the arch 2021-02-10 14:52:02 hah 2021-02-10 15:49:11 telmich_: I disagree about dhcpcd, it is to intrusive 2021-02-10 15:49:21 too* 2021-02-10 16:02:43 Is there any documentation for how alpine-uboot-3.13.1-aarch64.tar.gz is generated? 2021-02-10 16:04:33 lucidone: only aports/scripts 2021-02-10 16:23:44 Thanks. I'm trying to get a Pine64 RockPro64 booted and I can't quite see where the device tree is built/updated 2021-02-10 16:40:55 lucidone: we tried that before but straight Alpine won't boot yet and needs some changes, see https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6677 2021-02-10 16:41:08 In the meantime you can install postmarketOS on it to get Alpine running 2021-02-10 16:43:30 maxice8: done 2021-02-10 17:03:31 Should we enable virgl compatibility in libosinfo for Alpine? Seems like we're missing something like this: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/fedoraproject.org/fedora-24.xml.in#L18 so e.g. GNOME Boxes doesn't offer 3d accel 2021-02-10 17:09:19 Cogitri: i think we should enable all the virtio stuff for the alpine-virt flavor 2021-02-10 17:10:04 not sure if we should enable virtio for other alpine variants 2021-02-10 17:12:18 you mean kernels 2021-02-10 17:12:59 osinfo-db does not detect kernels. they look for label of the iso9660 filesystem 2021-02-10 17:13:32 anyway, some people run full blown is in VMs 2021-02-10 17:13:41 iso* 2021-02-10 17:14:52 might make sense to enable virgl for all variants 2021-02-10 17:15:10 That'd be really nice, LLVM pipe rendering is no fun, even on fast CPUs :) 2021-02-10 17:15:55 the other virtio devices should be enable for alpine-virt 2021-02-10 17:16:02 in addition to virgl 2021-02-10 17:16:41 yes, enable everything on everything. yes it will be bloated but debloat issue reports and irc channels 2021-02-10 17:17:35 https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/alpinelinux.org/alpinelinux-3.13.xml.in#L37 2021-02-10 17:17:53 mps: im not recommending anything. we are talking about osinfo-db. not the kernel config 2021-02-10 17:18:30 iirc, we have all virt drivers enabled in all (most) kernels 2021-02-10 17:19:03 yes, so we could enable virtio devices on all alpine flavors, but i think we shouldnt 2021-02-10 17:19:24 only when the alpine-virt iso is detected 2021-02-10 17:19:24 PureTryOut: I'm pretty close at this point. I'll check out your MR 2021-02-10 17:19:34 I'm not sure what to do, honestly 2021-02-10 17:20:00 mps: do you use virt-manager or osinfo-db? 2021-02-10 17:20:21 no, I only use shell scripts to start VMs 2021-02-10 17:20:50 or cli, ofc 2021-02-10 17:20:51 what i though. so this will have no effect on you in any way 2021-02-10 17:21:20 nothing of changes in alpine have effect on me, mostly 2021-02-10 17:21:46 we are not even discussing a change in alpine 2021-02-10 17:21:51 I'm speaking about alpine as project 2021-02-10 17:22:25 ah, this change will be only for few pkgs 2021-02-10 17:22:29 we are talking about the osinfo-db project 2021-02-10 17:22:31 yeah 2021-02-10 17:22:58 understand 2021-02-10 17:23:59 though I got some kind of allergic illness when I see reasoning 'as other big famuous distro does' 2021-02-10 17:26:33 still, having virgl for virtual servers by default is questionable 2021-02-10 17:27:49 but I'm not against these change 2021-02-10 17:28:01 changes* 2021-02-10 17:29:10 i wondering if it is good to use python platform triplet (and SOABI) with s/linux-gnu/linux-musl/ for python 3.9 2021-02-10 17:29:49 might be good to wait til upstream has proper support for it - hopefully for python 3.10 2021-02-10 17:30:11 ACTION is happy because don't know anything about this :) 2021-02-10 17:30:41 otherwise docker python:alpine users will not be able to reuse the alpine py3-cryptography package 2021-02-10 17:31:36 meaning that alpine:3.14 will have to build from source with rust, which is dead slow 2021-02-10 17:33:52 but it would be nice to have alpine 3.14 with proper python wheels 2021-02-10 17:33:53 something else, do we need BOOTLOADER option for u-boot for /sbin/setup-disk, maybe? 2021-02-10 17:34:22 yeah, that might be a good idea 2021-02-10 17:34:37 i think setup-disk only cares about syslinux and grub atm 2021-02-10 17:34:42 on 3.13 setup-disk doesn't work because there is not syslinux for arm 2021-02-10 17:35:18 I see something 'zipl' which I don't know what is it 2021-02-10 17:35:22 s390x 2021-02-10 17:35:30 aha 2021-02-10 17:35:36 i think it kinda works for s390x and ppc64le 2021-02-10 17:35:50 but i havent tested it for a while 2021-02-10 17:43:29 ncopa: Yes, users will have to build cryptography from source w/ rustc, but ideally they shouldn't install deps each time CI runs anyway but just have a CI image which is built periodically with that stuff installed 2021-02-10 17:46:56 ncopa: can I get linuxlts patched in v3.13? there was a local priv escalation reported for <5.10.13 2021-02-10 17:47:02 thanks 2021-02-10 17:51:54 would be nice to have gzip/br compression on https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/ :) 2021-02-10 17:52:30 xz \o/ 2021-02-10 17:52:44 600kb -> 85k :) 2021-02-10 18:12:50 c705: why not backport kernel 5.10.15 ;) 2021-02-10 18:13:11 oh 5.10.15 is out... 2021-02-10 18:14:03 i will look into update the kernel on 3.13 stable tomorrow 2021-02-10 18:16:48 yes, just reading changelog, full bowl of fixes 2021-02-10 18:18:28 ncopa: thank you 2021-02-10 18:18:57 how is this normally managed? I've been asking in this channel for about a week for a patch to 5.10.12 2021-02-10 18:19:06 is there anything I can do better to flag that the package needs a patch 2021-02-10 18:19:55 enough time is issue, and I decided to not touch -lts kernels 2021-02-10 18:20:34 is 1 week not enough time? doesn't seem that complicated. patch the APKBUILD and send to the builder 2021-02-10 18:20:37 though I was tempted to upgrade it for 3.13 2021-02-10 18:21:59 when I did that few times earlier always some people appear to grumble around 2021-02-10 18:22:15 why? 2021-02-10 18:22:52 well, we all have our views on 'things' 2021-02-10 18:23:38 okay, well I think we can all agree that sitting on a kernel with a local priv escalation bug for a week isn't a good idea 2021-02-10 18:23:59 agree, but that's life 2021-02-10 18:24:22 terrible attitude 2021-02-10 18:24:28 btw, this one was not risky to most of our users 2021-02-10 18:24:57 that doesn't make it any more acceptable 2021-02-10 18:26:00 well, terrible or not, but I think most of developers already know for serious bugs around for some pkgs and they work on them, sometimes this requires a lot of time and effort 2021-02-10 18:26:44 developers aren't some supermagical beings 2021-02-10 18:26:46 and patching a kernel from upstream takes significant effort? 2021-02-10 18:27:33 if you're still outraged by the amount of stuff that's absolutely indispensable, that should have been done two weeks ago, without which the world cannot keep turning, and that still haven't been done despite all that, you must be new in tech 2021-02-10 18:28:26 i'm asking for the patch from upstream. it's not that difficult 2021-02-10 18:28:51 i'm done, just please patch the kernel, thanks 2021-02-10 18:29:01 our policy on kernels is to not patch, except in rare cases 2021-02-10 18:29:31 c705: what patch did you ask for? i already backport the the xen fix 2021-02-10 18:29:44 ncopa: latest stable build would be nice 2021-02-10 18:30:41 specifically CVE-2021-3347 2021-02-10 18:30:49 i'll try update both edge and v3.13 to 5.10.15 tomorrow 2021-02-10 18:31:09 thank you. as I asked before, what is the best way to flag that the package needs updating? 2021-02-10 18:31:15 c705: I told you that you can install linux-edge if you have concern about sec flaw, but you denied this 2021-02-10 18:31:35 linux-edge breaks several packages I use 2021-02-10 18:31:52 which 2021-02-10 18:31:53 If it worked, and it was stable, I would be using it 2021-02-10 18:32:22 firefox, libvirtd last I checked. I gave up dealing with it so I'm using stable now 2021-02-10 18:32:25 I think you can file an issue if there is a CVE 2021-02-10 18:32:51 to notify that an update is requested 2021-02-10 18:32:58 firefox works quite fine on linux-edge, x86_64, armv7 and aarch64 tested 2021-02-10 18:33:38 not under firejail which I prefer to use. again, last I checked 6 months ago 2021-02-10 18:33:41 alpine edge normally get kernel updates within a (work) day or two 2021-02-10 18:34:00 firejail have its bugs and sec flaws 2021-02-10 18:34:01 I will not be using edge repos since I rely on this machine and edge frequently breaks the runtime 2021-02-10 18:34:27 yeah, thats good 2021-02-10 18:35:10 i normally update the kernel for latest stable on request or when i tag new stable release 2021-02-10 18:35:25 goal is to tag release once every month 2021-02-10 18:35:26 but... 2021-02-10 18:35:36 ncopa: how does security fixes get into the stable releases? 2021-02-10 18:35:50 they are reported to the bugtracker 2021-02-10 18:36:07 automatically, or does someone have to do them? 2021-02-10 18:36:15 https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=tag%3Asecurity 2021-02-10 18:36:22 someone do them 2021-02-10 18:36:48 is anyone assigned to watch for a patch and create the issues 2021-02-10 18:36:57 yes 2021-02-10 18:38:16 well, they failed to report the CVE I had mentioned 2021-02-10 18:38:47 I will start creating issues for sec fixes I notice if that means it will get someone to patch 2021-02-10 18:39:16 i think cve's for kernel is not normally reported 2021-02-10 18:39:32 due to historical reasons 2021-02-10 18:40:05 what is that supposed to mean/ 2021-02-10 18:40:46 upstream kernel devs used to not care much about CVE and said that every bug is may be a security bug 2021-02-10 18:40:52 so you should always update 2021-02-10 18:41:19 there are cves reported against the kernel all the time 2021-02-10 18:41:33 and the number of issues are too many so we kinda gave up 2021-02-10 18:41:56 then I don't think it's appropriate to frame alpine linux as a "security focused distro" 2021-02-10 18:42:12 And there are examples where downstream kernels were vulnerable because they skipped non-cve marked patches (cough rhel) 2021-02-10 18:42:29 c705: https://alpinelinux.org/ "Alpine Linux is a security-oriented…" 2021-02-10 18:42:51 yeah, i have considered drop the "security" from that after grsecurity went dark 2021-02-10 18:42:53 patching is the most important security control we have. if there is one thing we should be doing, it's patching, in my opinion 2021-02-10 18:42:54 if time if of the essence, download the files from https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/linux-lts 2021-02-10 18:43:18 we don't need grsec. we just need to stay on top ov CVEs and patch 2021-02-10 18:43:21 i actually at one point did try to track every single cve in kernel 2021-02-10 18:43:25 alexy: yes, I'm aware, thanks 2021-02-10 18:43:26 jvoisin: it should be "Alpine Linux is a security-theatre-oriented…" :) 2021-02-10 18:43:28 that's a path to madness :( 2021-02-10 18:43:29 modify it a bit to linux-custom or something, change the patch number, create your own config-custom.$arch 2021-02-10 18:43:31 unfortunsately 2021-02-10 18:43:34 unfortunately* 2021-02-10 18:44:02 alexy: if i'm going to start compiling things myself, I'll likely just jump to gentoo again 2021-02-10 18:44:10 all it needs to download is https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.10.15.xz 2021-02-10 18:44:23 ncopa: well, it uses musl with its nice allocator, and decent compiling options :) 2021-02-10 18:44:28 we could proably have a person working full time tracking the kernel issues 2021-02-10 18:44:46 jvoisin: thats why we didnt remove the "security" part 2021-02-10 18:44:50 ncopa: i can help out. I already follow all the security lists 2021-02-10 18:45:11 uh, no 2021-02-10 18:45:21 i was under the assumption that someone else had this covered 2021-02-10 18:45:24 c705: creating issues is very much welcomed 2021-02-10 18:45:24 but i felt really bad about the the "security" bit when we dropped grsecurity 2021-02-10 18:45:41 c705 if you can file issues for kernel, that woudl be very helpful 2021-02-10 18:45:47 grsec was unavoidable 2021-02-10 18:45:50 i know 2021-02-10 18:45:54 c705: once it's setup, upgrading kernel is editing a number on the APKBUILD file, run abuild and apk update 2021-02-10 18:45:55 ncopa: i'll start doing what I can 2021-02-10 18:46:05 having some automated tooling for CVE would help. I used to use https://www.cve-search.org/about/ for this 2021-02-10 18:46:09 alexy: i'm aware, thank you 2021-02-10 18:46:12 c705: Alicia CH creates most security issues 2021-02-10 18:46:36 c705: if you want speed that's the fastest way 2021-02-10 18:47:05 i don;t care so much about me, I'm concerned about the community at large 2021-02-10 18:47:38 we're supposed to be security focused, and I think if we stay ontop of sec fixes, it's totally appropriate to keep using that moniker 2021-02-10 18:47:45 c705: the problem i bumped into was that it could be very very hard to find the exact minor stable release that fixed a given cve 2021-02-10 18:48:20 and i discovered that some cve's was never fixed in some stable branches 2021-02-10 18:48:30 ncopa, i don't think dropping grsec merits dropping "security-oriented" 2021-02-10 18:48:37 shrug, a lot of CVE came from bugs discovered months ago 2021-02-10 18:48:40 shipping grsec was security-theater-oriented 2021-02-10 18:48:41 and distros reported them as fixed 2021-02-10 18:49:23 dalias: i did consider drop "security-oriented" but endedup not doing so 2021-02-10 18:49:25 shipping a distro that doesn't pull in loads of gratuitous packages with suid binaries, run unwanted daemons by default, etc. and that builds everything with ssp, fortify, pie, etc. is "security-oriented" in my book 2021-02-10 18:49:37 dalias: you will never become rich (pun intended) :) 2021-02-10 18:49:55 i think grsecurity is pretty good at what it does 2021-02-10 18:50:01 if you want true security you install old stuff and watch the mailing-lists and hangout with blackhats 2021-02-10 18:50:09 the *only* way you can be security-oriented is by minimizing attack surface 2021-02-10 18:50:27 and patching the software 2021-02-10 18:50:34 I doubt of benefits/hasles ratio with grsec 2021-02-10 18:50:43 not to mention policy and procedure 2021-02-10 18:50:56 grsec is irrelevant anyway no no point discuss that anymore 2021-02-10 18:50:59 what mps said. there was very little with actual benefit and all the stuff with actual benefit went upstream a decade or more ago 2021-02-10 18:51:13 what they did back then was making pie effective 2021-02-10 18:51:34 optional extreme aslr is on its way upstream in the kernel now 2021-02-10 18:51:51 righ Cook took most important things and upstreamed to mainline 2021-02-10 18:51:55 yeah. they have got various of the ideas from grsecurity/pax in upstream 2021-02-10 18:52:39 but what grsec also does is track upstream changes, identify what is security issue and backport 2021-02-10 18:53:32 so even if you'd run a grsecurity patched kernel with all the grsecurity features turned off in the config, you'd have a more secure kernel due to the backported fixes 2021-02-10 18:53:50 and they backported much more than what goes to -stable branches 2021-02-10 18:54:15 nowadays most fixes are backported to all LTS kernels 2021-02-10 18:54:18 if you follow latest lts that's not really an issue 2021-02-10 18:54:33 maybe if you were trying to use 3.x still it would matter... 2021-02-10 18:55:07 well, the upstream kernel devs used to miss alot. spender didnt miss much if anything 2021-02-10 18:55:21 but as i said. it does not matter anymore 2021-02-10 18:55:46 i cannot compare anymore 2021-02-10 18:55:58 and we cannot use grsec 2021-02-10 18:56:30 i do understand that people are willing to pay for it though 2021-02-10 18:57:09 c705: help with tracking kernel cves is very appreciated, so thank you for not only complaining, but also offer to help 2021-02-10 18:57:26 right my only point here is that this is not the distinction that makes a distro "security-oriented" and you were completely right not to drop the label over that 2021-02-10 18:58:06 yes, it's really hard 2021-02-10 18:58:48 and removing 'security' will equal to suicide nowadays 2021-02-10 18:58:57 :) 2021-02-10 18:59:15 dalias: yes i agree 2021-02-10 18:59:36 thank you for confirming i was not completely idiot keeping it :) 2021-02-10 18:59:47 :) 2021-02-10 19:01:09 there have been some movement in upstream python to accept musl, which is very positive 2021-02-10 19:01:10 ncopa: no problem, i will be the squeaky wheel if it gets us the grease 2021-02-10 19:02:27 just pushed linux-edge 5.10.15 for security oriented people ;) 2021-02-10 19:04:27 CVE-2021-3156 fixes a hole created back in 2011 2021-02-10 19:04:55 right. this is why it's important to patch 2021-02-10 19:05:09 holes like these are being traded constantly in a world most people don't even know exists 2021-02-10 19:05:56 by the time you hear about it 100 more was created, many on purpose, by digital arms dealers 2021-02-10 19:07:13 alexy: true 2021-02-10 19:07:17 why do you think billion dollars company use md5 for password hashes, they're not stupid 2021-02-10 19:07:33 it happened for a reason, I won't talk about it here but if you know how this works, you know 2021-02-10 19:14:05 fact, no cpu is safe after pentium, antivirus companies are the ones creating "viruses", your harddisk, monitor, usb sticks, even your mouse, keyboard has roms to hide codes, that's before you get to the mandatory backdoor on chips like qualcomms, switches like cisco, wifi's design flaw is unfixable because you can never guarantee safety on step 1, and don't even get me started on bluetooth, ntpd will always have flaws you don't know about, if 2021-02-10 19:14:05 your server don't use a gps timer you're already fked. 2021-02-10 19:15:26 yeah, these days its best-effort regardless what you do 2021-02-10 19:15:30 so yeah, keep reloading that CVE page and pat yourself on the back, while your girlfriend casually walk pass your computer with a phone with 50 apps on it and the camera not covefed. 2021-02-10 19:17:26 you dont even need the camera. the mic is enough to sniff the password you are typing on the keyboard 2021-02-10 19:17:39 bluetooth and wifi constantly on. do an experinment, grab your gf/wife/mother's phone, think of a country you've never talked about in your life, keep talking about you want to go to $country for a vacation, talk about it for an hour. you'll see ads on that country the next day. why do you think that happened. 2021-02-10 19:17:50 too bad there's no password to snuff 2021-02-10 19:17:52 sniff 2021-02-10 19:18:35 and there is no appreciable untargeted attack of this sort 2021-02-10 19:18:36 ncopa: yup, keyboard gives off a electronic signal that can be sniffed through the wall, it's on youtube, 10 years ago, they do it even better now. 2021-02-10 19:18:44 the cpu load, network load, etc. are way too high 2021-02-10 19:19:35 and the 0days needed to do it on a non-shit mobile device are too valuable to burn on at-scale exploitation 2021-02-10 19:20:07 ios at least does not let random junk apps enable mic or camera when not in foreground without very prominent notification that they're active 2021-02-10 19:20:26 so you need to pwn the os too 2021-02-10 19:20:49 yes the landscape is bad but it's nowhere near what your defeatist scaremongering suggests 2021-02-10 19:21:45 true if the stuff you have doesn't worth money or political power 2021-02-10 19:22:35 dalias: yes, life is still beautiful despite all bad news around 2021-02-10 19:22:36 thats why i said untargeted 2021-02-10 19:23:03 there is some targeted but it's mostly used on the most valuable targets 2021-02-10 19:24:17 that is, ones with major political or corporate power roles, or dumbasses with millions of $ in toy money entrusted to third party fake banks with bogus authentication models :-p 2021-02-10 19:25:32 i think i might have been targeted, together with those security researchers 2021-02-10 19:25:34 and i suspect mostly the latter 2021-02-10 19:25:41 interesting 2021-02-10 19:26:18 alexy: all of this is true, which is why it's appropriate to have a proper threat model 2021-02-10 19:26:19 you mean the fake personas trying to make friends by reporting minor vulns? 2021-02-10 19:26:38 someone called me on the phone, threatening me. claimed i hacked his phone. 2021-02-10 19:26:42 i didnt follow it closely but it was interessting 2021-02-10 19:26:45 uhg wtf 2021-02-10 19:27:12 i managed to explein that i wouldnt leave my email in the script he foudn if i was a real hacker 2021-02-10 19:27:24 so then he asked for help with finding the real hacker 2021-02-10 19:27:44 i think that was the real attack 2021-02-10 19:28:03 that'd be interesting if it really was 2021-02-10 19:28:20 was he asking for things that made it sus? 2021-02-10 19:28:35 the whole thing was suspicious 2021-02-10 19:29:10 well yeah but could also be innocent newb 2021-02-10 19:29:49 he might have been stupid. but there are several red flags 2021-02-10 19:30:17 first he threatened. scammers often do 2021-02-10 19:30:28 ncopa: social engineering 101, most technies are INTP or INTJ, if you're identified as an INTJ the best strategy is appeal to their experties. 2021-02-10 19:30:29 then he asked for help. 2021-02-10 19:31:05 let them think they're the best at their job, play it right, play it long, they'll finally let their guard down. 2021-02-10 19:31:16 and it happened right before it was uncovered that many security researchers were targeted 2021-02-10 19:31:48 lol i've talked too much. :) 2021-02-10 19:31:59 afk :) 2021-02-10 19:32:11 yup.the human is teh weakezst security control of them all. an important reason why policy and procedure is equally as important as a competant security team 2021-02-10 19:32:20 pardon my bad typing 2021-02-10 19:32:30 yeah. i recall meeting that type of overconfident hacker newbie ages ago on irc tho 2021-02-10 19:33:06 they'd get mad thinking you were trying to hack them based on some complete misreading of logs/packet dumps/whatever 2021-02-10 19:33:46 then when you revealed to them how little they know, they'd still be convinced someone was trying to hack them, and now you're this amazing l33t h4x0r (!!) they can beg for help 2021-02-10 19:35:19 so short of them trying to get you to do something that could implicate you in wrongdoing, pull you in as an accomplice to something bad they were doing, or reveal personal information or credentials or whatnot, my leaning would be not to assume a targeted attack 2021-02-10 19:36:53 this kind of remind me this story: https://acme.com/software/thttpd/repo.html :D 2021-02-10 19:38:01 ncopa: ^ 2021-02-10 19:49:59 lol 2021-02-10 19:50:48 Imagine a world where people's most important financial, medical, legal and other personal data are entrusted to extremly resourceful companies who "take their security very seriously" 2021-02-10 19:51:32 and/or institutions, departments 2021-02-10 19:51:54 and they all hire minimum wage janitors prone to common social engineering tactics 2021-02-10 19:52:01 that's probably not going to happen without regulation and peanalties for failing to do so 2021-02-10 19:52:23 but, that doesn't mean we should just give up on security entirely. there are things that companies can do to minimize threat 2021-02-10 19:52:29 guess who cleaned the office of your favorite $creditcard company yesterday 2021-02-10 19:53:06 what's your ponit? 2021-02-10 19:53:07 jane the cleaner called in sick, mary took over, mary is a single parent struggling with her young kid 2021-02-10 19:53:45 all she has to do is look at a sticker with a password stuck to a monitor and report what she sees, and she get to go to a vacation with her kid. 2021-02-10 19:53:59 thats not how any of this works 2021-02-10 19:54:27 yeah, I mean even if you get my work LAn credentials, there's not much you can do with that 2021-02-10 19:54:44 maybe start pivoting into a different system, but it's not exactly cut and dry 2021-02-10 19:55:47 who is going to clean the 30000 sqt office? not the ceo, not the manager, not the "security expert" 2021-02-10 19:56:05 not the doctor, not the judge 2021-02-10 19:56:18 not the therapist 2021-02-10 19:56:27 once again, what is your point 2021-02-10 19:57:29 this is all like cheap spy novel theory, not how it actually happens 2021-02-10 19:58:50 you mean the ceo cleans the office? 2021-02-10 19:58:53 no 2021-02-10 19:59:15 you don't even need to step foot into an office to launch an attack 2021-02-10 19:59:48 attackers would be stupid to try to establish a relationship with a person who works at their target to get that person to knowingly act as an accomplice to their attack 2021-02-10 19:59:59 it's high risk for no reward 2021-02-10 20:00:05 instead you just phish 2021-02-10 20:01:21 you 2021-02-10 20:02:22 you're talking about a scenario where the target is worthless 2021-02-10 20:02:39 the key to the castle is worthless 2021-02-10 20:03:19 that's not what's being communicated here 2021-02-10 20:06:35 no single-mom cleaning lady in attack on paypal,microsoft,apple... :https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 2021-02-10 20:17:27 https://losangeles.cbslocal.com/2010/09/17/janitor-steals-patient-records-for-recycling-money/ 2021-02-10 20:17:56 And that's from a "rich" country. 2021-02-10 20:18:55 Sheriff’s spokesman Steve Whitmore says Sanders was known for recycling bottles and cans and he admitted selling the 14 boxes of patient information for $40. 2021-02-10 20:21:01 Would he keep quiet about who hired him if he was offered $5000? 2021-02-10 20:21:23 $50000? 2021-02-10 20:24:34 c705: my point is data exists outside code, cables, signal and harddisks, if one don't pay attention to observ and undertand the physical world (typical "tech expert"), one doesn't understand security. 2021-02-10 20:25:10 alexy, your narrative has no basis in reality and it's just some sexist+racist+classist condescension of people doing low-wage work pretending they're a vector for attack 2021-02-10 20:25:38 dalias: they're based on reality, it's happening as we speak. 2021-02-10 20:26:59 the article you linked had nothing to do with your claim 2021-02-10 20:27:44 the person was not contacted and enlisted to steal information. he was making his own money off of recycling his employer's waste and happened to include paper waste full of pii in that 2021-02-10 20:28:12 right, because everyone tells the truth, or it becomes truth after you read it. 2021-02-10 20:28:33 it's call corporate/political/industrial espionage, look it up. 2021-02-10 20:29:00 umm, of course it's the truth because he was selling other types of waste too and the price is the price for the material for recycling 2021-02-10 20:29:19 what i mentioned reflects a tiny window of reality, it's up to the reader to ignore, reject, or look into it. 2021-02-10 20:29:29 selling one's employer's trash for recycling is actually a fairly common practice 2021-02-10 20:30:07 and people through important information in the trash thinking it's gone for good. 2021-02-10 20:30:12 throw* 2021-02-10 20:30:45 no, there are procedures for handling this sort of information that obviously were not being followed 2021-02-10 20:30:53 which has been the case since long before computers 2021-02-10 20:31:17 lol and why were they not being followed? perhaps they were earning minimum wages? 2021-02-10 20:31:27 no, this person was not the person not following procedure 2021-02-10 20:32:13 in any case 2021-02-10 20:32:14 have you traveled to any third world country, dallas. 2021-02-10 20:32:50 i dont use that term but if you mean to places *you* would describe that way, yes 2021-02-10 20:33:10 most people in this world have more worries than following procedures in an office that doesn't pay well. 2021-02-10 20:33:13 nobody competent is going to go through layers of *physical exposure* for a small chance to get access to information they could get more reliably with ZERO RISK by phishing 2021-02-10 20:33:48 a typical intj/intp would not consider physical,time constraint 2021-02-10 20:33:53 you're talking out of conspiracy brainworms not any actual knowledge of how this stuff works 2021-02-10 20:34:36 $company_a's $competitor just delivered a $500million $lawsuit_doc/$patent to $office and you have 3 days to get it, what do you do. 2021-02-10 20:38:29 dalias: https://www.securonix.com/a-case-of-corporate-espionage/?PageSpeed=noscript 2021-02-10 20:39:55 just because you are the good guy and follow the rules, doesn't mean other people do, dalias. 2021-02-10 20:40:23 human systems are fragile. 2021-02-10 20:42:19 There are temptations, threats, pressure, people make mistakes they regret later. 2021-02-10 20:43:25 o/ 2021-02-10 20:43:45 don't you think we should modify the GNUInstallDirs macro from CMake to remove the default lib64 value? 2021-02-10 20:43:53 so that all recipes don't need to override over and over 2021-02-10 20:44:04 believe whatever you want, it's your life. signing off. Have a nice day. :) 2021-02-10 20:44:11 without mentioning how annoying is to forget to set it each time I install something by hand 2021-02-10 20:59:49 our 'civilization' is screwed, in better civilization security would be minimal 2021-02-11 04:02:43 as for your condescending remarks, dalias, I am going to assume you're going through a phase and offer you this: 2021-02-11 04:03:05 "An expert is one who knows more and more about less and less until he knows absolutely everything about nothing." ~ Nicholas Butler 2021-02-11 04:03:17 keep that in mind, you'll thank me one day. 2021-02-11 04:03:32 and be nice to the hotel maids, they're a lot more powerful than you think :) 2021-02-11 05:05:49 i don't think he has a hostile bone in his body 2021-02-11 05:06:08 anyway let's move on. 2021-02-11 07:43:31 nowadays people think that the knowledge is achieved by reading a lot and having a lot of information and data, and don't need to think even a little 2021-02-11 07:55:53 morning 2021-02-11 07:56:27 as i understand rust is completely broken with musl 1.2 due to rust assumes 32 bit time_t? 2021-02-11 07:58:10 from superficially reading about this I also think so 2021-02-11 08:10:57 Is algitbot down? 2021-02-11 08:11:28 \o/ 2021-02-11 08:11:43 looks like it is 2021-02-11 08:12:24 ncopa: It's not completely broken, since there aren't many places were time_t is used in Rust land 2021-02-11 08:12:40 A few things which use time_t in bindings are probably borked though 2021-02-11 08:13:23 I don't think we can do much other than wait it out until libc (the libc bindings package for Rust) has done that change though 2021-02-11 08:20:51 Apparently upstream is unsure how to support both musl <1.2 and >=1.2 at the same time via libc 2021-02-11 08:23:58 uh. (mouth closed) 2021-02-11 08:51:06 The problem why this isn't as trivial as "if musl >= 1.2 use i64 otherwise use i32" is that Rust is more strict about type conversions 2021-02-11 08:51:34 So if you were to do that u64::from(musl_pre_12_time_t) would work but it wouldn't with 64-bit time_t 2021-02-11 08:52:18 Actually, that wouldn't work either, you need u64::try_from() in case the value is negative 2021-02-11 08:54:16 i'd simply drop support for time32 2021-02-11 08:55:22 i dont think rust users care much about minor/older/different platforms anyway 2021-02-11 08:58:02 i wonder if we can simply patch our rust to use 64bit time_T 2021-02-11 09:01:21 https://tpaste.us/W7D0 2021-02-11 09:05:46 That'd fix it for rust std 2021-02-11 09:06:07 But any other Rust packages which always compiles its own version of libc may still be broken 2021-02-11 09:06:22 Although the chance of them actually using time_t is rather slim 2021-02-11 09:06:43 So fixing rust std sounds like a good idea for now 2021-02-11 09:07:20 First we should get rust to 1.49, maybe I can look into getting ff-esr to compile with >=1.48 today 2021-02-11 09:09:51 i 2021-02-11 09:09:57 i suppose we also need llvm11 2021-02-11 09:10:36 so other packages uses their own copy of vendor/libc? 2021-02-11 09:10:46 they don't do shared libs? 2021-02-11 09:10:58 Nop, everything is statically linked 2021-02-11 09:11:06 And we don't need llvm11 yet 2021-02-11 09:11:10 like go 2021-02-11 09:11:23 rustc 1.49 works just fine with our current setup, the only blocker is ff-esr 2021-02-11 09:11:29 and they pull sources from network too I suppose 2021-02-11 09:12:54 Yup 2021-02-11 09:13:20 Most of the time anyway, some things vendor the dependencies in release tarballs (like rustc) 2021-02-11 09:15:40 no thought on my CMake proposal earlier? 2021-02-11 09:19:39 Which proposal? 2021-02-11 09:20:54 21:43 < markand> don't you think we should modify the GNUInstallDirs macro from CMake to remove the default lib64 value? 2021-02-11 09:20:57 21:43 < markand> so that all recipes don't need to override over and over 2021-02-11 09:20:57 21:44 < markand> without mentioning how annoying is to forget to set it each time I install something by hand 2021-02-11 09:23:27 Imho instead of doing that we should just have a cmake helper like we have for abuild-meson 2021-02-11 09:24:37 yes but when you install things by hand manually with CMake, you always need as a user to specify those paths to while it should just compile, install to the correct places 2021-02-11 09:24:48 just like gcc/clang are configured to search lib rather than lib64 2021-02-11 09:25:02 i think that makes sense 2021-02-11 09:25:14 Ah fair, then that makes sense 2021-02-11 09:26:35 the downside with things like abuild-meson is that it hides what is actually happening, which may make it frustrating to debug things 2021-02-11 09:26:56 i remember digging in to huge gentoo eclasses to try figure out what was actually going on 2021-02-11 09:27:30 oh, I remember when I try to write some gentoo packages, total nightmare 2021-02-11 09:27:42 this is what I actually loved from Slackware SlackBuilds, you really see what will happen 2021-02-11 09:28:07 that was one of the original goals with APKBUILDs 2021-02-11 09:28:23 and i think it has been one of the reasons for its success 2021-02-11 09:29:02 re rust and time64 2021-02-11 09:29:13 i dont know what this is but it sure looks wrong: https://github.com/rust-lang/rust/pull/81455/commits/3408c58bdfc923f9b1b7fbab271a791442de682a 2021-02-11 09:29:34 pub type time_t = c_long; 2021-02-11 09:29:56 these helpers are 'not good things', imo 2021-02-11 09:30:19 they do simplify maintenance 2021-02-11 09:30:25 ncopa: Yes, we shouldn't have too many helpers which make things magical, but IMHO things like abuild-meson are super nice to have some basic DRY 2021-02-11 09:30:31 and makes things consistent 2021-02-11 09:30:41 yeah, for DRY reasons 2021-02-11 09:30:43 And abuild-meson won't really ever cause problems AFAICS 2021-02-11 09:30:48 and the same time complicate debugging 2021-02-11 09:30:59 mps: thats the price for it, yes 2021-02-11 09:31:13 I can understand that we don't want things like Gentoo eclasses though, those sure are a pain to debug or even understand :) 2021-02-11 09:31:37 But it only makes it a tiny bit more complicated to debug because abuild-meson is very simple 2021-02-11 09:32:10 And I doubt that that can take more time than me having to note on every second MR for a package that uses meson to please specify the right buildtype :) 2021-02-11 09:33:55 using abuild-meson and similar helpers is nice for maintainers 2021-02-11 09:34:01 avoiding them is nice to newcomers 2021-02-11 09:34:44 Hm, not sure if I subscribe to that, newcomers don't like having to know 5 options they have to pass to meson 2021-02-11 09:35:41 I think abuild-meson is fine, but what could be easier to debug is to have an abuild option that use set -x so that every commands are listed to help debugging 2021-02-11 09:36:00 one should make gui-abuild 2021-02-11 09:36:30 the situation im thinking of is when you have a package working in alpine, but not working in other distro. the other distro dev wonders what flags was actually used for the alpine package 2021-02-11 09:36:44 so he/she looks up the alpine build recipy 2021-02-11 09:37:08 markand: a sh -x mode would be kinda nice indeed 2021-02-11 09:37:17 i agree that sh -x is a good idea 2021-02-11 09:37:33 i use that occationally, set -x in the APKBUILD 2021-02-11 09:37:38 or in abuild itself 2021-02-11 09:38:09 'abuild -v' 2021-02-11 09:50:27 after having replied to #11377 I somewhat regret it, since I began thinking if it would be possible to have a libc meta package for gcc to depend on, that is provided by either musl-dev or libc-dev 2021-02-11 09:52:29 Can we have `GHSL` numbers for security fixes (apparently they're like CVEs)? 2021-02-11 09:54:40 we could but im not sure we want? 2021-02-11 09:55:00 why do we want those and double the administrative work to keep track of security issues? 2021-02-11 09:55:20 Well, a 0-day against glib only has a GHSL number, that's why I'm asking 2021-02-11 09:55:27 https://gitlab.gnome.org/GNOME/glib/-/issues/2319 2021-02-11 09:56:44 i think we should document the secdb format 2021-02-11 09:56:51 currently we do support other identifiers 2021-02-11 09:56:58 xen XSAs for example 2021-02-11 09:57:07 Cogitri: GHSL are specific to github 2021-02-11 09:57:17 it stand for GitHub Security Lab 2021-02-11 09:57:31 so nothing prevents us to add GHSLs to our secdb 2021-02-11 09:59:16 Alright, so if I add that identifier to the glib APKBUILD nothing will explode? :D 2021-02-11 10:00:32 I think we should remove all these 'cve', they are useless 2021-02-11 10:00:47 or find a better way to track them 2021-02-11 10:01:32 jvoisin: maybe, but I didn't seen anything, yet 2021-02-11 10:13:31 Hi all. Been trying to educate myself after our discussion yesterday about how frequently the alpine docker images are updated. 2021-02-11 10:13:39 The 'base' container has the following packages installed: https://paste.debian.net/1185042/ 2021-02-11 10:14:02 Is it a safe assumption that the base image would be rebuilt if any changes to these packages were made in (say) edge? 2021-02-11 10:14:33 According to the docker registry, the last update of the edge image was 2 months ago. 2021-02-11 10:17:51 udev rules are installed to both `/lib/udev/rules.d` and `/usr/lib/udev/rules.d` depending on the package. Is there any reason to use one location over the other? Shouldn't they all install to the same location? 2021-02-11 10:18:47 PureTryOut[m]2: 'system' rules goes to /lib while 'less system' rules goes to /usr/lib 2021-02-11 10:19:12 I think originally it was "things which are required for boot go to /lib, things which aren't go to /usr/lib" 2021-02-11 10:19:31 distinction between these is not clear, and I doubt it will be ever 2021-02-11 10:19:32 But I think in practise it's more of a "whatever no one uses a split /usr partition any more anyway" right now 2021-02-11 10:21:44 Well when upstream installs it some location I would normally leave it, but if it's installed by the packager, then what would be the preferred location or do we not care and let the packager decide? 2021-02-11 10:22:33 I'd say just install it to /usr/lib 2021-02-11 10:22:48 or use mdev ;) 2021-02-11 10:22:49 Ok 👍️ 2021-02-11 10:24:01 Then other question, I have an udev file that's needed by at least a Flatpak package. Is there any point packaging it for Alpine and if so to what package, or shall we just expect the user to add it themselves since we don't care about Flatpak? 2021-02-11 10:27:08 do we have to care for users? (rhetorical question, no need answer) 2021-02-11 10:27:25 they're the worse 2021-02-11 10:28:32 ACTION going to Bhagdad to find Aladins lamp 2021-02-11 10:28:36 PureTryOut[m]2: I don't see a problem with adding the udev rule if it makes things nicer for users 2021-02-11 10:29:37 Hmm sure. I wonder in what package to install it though, and how in the first place. It's not like we can do `install_if="flatpak:org.whatever.flatpak"` 2021-02-11 10:31:51 Even if we could do that that'd break if the user installed our package first and the flatpak afterwards 2021-02-11 10:32:09 Ideally flatpak would allow installing udev rules already, there are quite a few packages with the same situation 2021-02-11 10:32:22 Yeah... 2021-02-11 10:32:34 adhawkins: from what I understand, ncopa needs to make a pull request against docker-library to get images to be rebuilt 2021-02-11 10:32:36 Maybe I'll just make a wiki package for this flatpak specifically and link to the udev file 2021-02-11 10:32:48 *wiki page 2021-02-11 10:33:49 ikke: Ok. Is that something that's done promptly whenever one of those packages changes? Just trying to understand whether those images get updated 'quickly' whenever fixes are made? 2021-02-11 10:35:17 https://github.com/docker-library/official-images/commit/e427fe3689423d1f82895451e10052f2cea78187#diff-8c805a48d8543a1fe5cdcee8aa34f23366aa01f27b7f2e276df99901bbac86a9 2021-02-11 10:36:24 I think that was done soon after a musl cve was found and fixed 2021-02-11 10:37:29 what's a good python package to look at for reference if I want to package https://github.com/magic-wormhole/magic-wormhole ? 2021-02-11 10:38:22 Ok great. Thanks. I guess the only question then is how long it might take from a CVE being reported to that image being updated. I appreciate Alpine is a volunteer effort, just a friend was 'concerned' about how quickly security fixes made it into Alpine. 2021-02-11 10:39:02 The musl one was very quick because we have close contacts to musl 2021-02-11 10:39:29 Question probably applies to a wide range of packages though I imagine, so is almost impossible to answer :) 2021-02-11 10:40:00 we update the docker images as a manual process when tagging releases 2021-02-11 10:40:14 so to update docker image we need to do a full release 2021-02-11 10:40:20 How about the one for 'edge'? 2021-02-11 10:40:35 edge releases are snapshots, and are lightweight for us to do 2021-02-11 10:40:50 the goal is to tag new snapshot once every month 2021-02-11 10:40:51 Ok. All useful info, thanks ncopa and ikke. 2021-02-11 10:41:28 is the edge snapshot vulnerable for any recent issues? 2021-02-11 10:41:41 s/snapshot/docker image/ 2021-02-11 10:41:41 ncopa meant to say: is the edge docker image vulnerable for any recent issues? 2021-02-11 10:42:40 i think what we need is some sort of notification if any of the mentioned packages in edge changes, that indicates that we should tag new release 2021-02-11 10:43:23 ncopa: this is more a hypothetical discussion 2021-02-11 10:43:59 How frequently are base images updated for security fixes 2021-02-11 10:45:35 docker run --rm -it alpine:3.13 sh -c 'apk update --quiet && apk version' 2021-02-11 10:46:39 docker run --rm -it alpine:edge sh -c 'apk update --quiet && apk version --quiet --limit=\<' 2021-02-11 10:46:55 if that gives any output we should tag new release 2021-02-11 10:47:25 so we should tag new edge release 2021-02-11 10:48:18 i think I'll tag new release as soon all edge builders are 'idle' 2021-02-11 10:52:16 Seems like a few things fcolista pushed yesterday are blocking the builders right now 2021-02-11 10:56:08 checksum mismatch on bitwarden_rs? 2021-02-11 10:57:08 I already disabled bitwarden_rs 2021-02-11 10:57:26 Perl-cbc something something and libupnp are broken on armv7/s390x 2021-02-11 10:57:28 yes, but I was looking into why it was failing 2021-02-11 10:58:17 sorry I didn't noticed that :-( 2021-02-11 10:58:28 so, we should not merge or push new changes? 2021-02-11 10:58:30 a couple of packages are in testing 2021-02-11 10:59:38 fcolista: :D use aports-lint from atools 2021-02-11 11:01:34 maxice8, didn't know that aports-lint does this check too 2021-02-11 11:01:38 that's a good suggestion 2021-02-11 11:03:01 ACTION uploaded an image: original.png (293KiB) < https://synapse.cogitri.dev/_matrix/media/r0/download/cogitri.dev/DQHHlrqPkfYUkZFpKwIQxhXh/original.png > 2021-02-11 11:04:42 ncopa: is is to late for !18145 for next 3.13 2021-02-11 11:05:01 main/busybox: add few serial devices to /etc/securetty 2021-02-11 11:08:06 hmm, 3.13 builders are idle 2021-02-11 11:08:28 the edge builders need to be idle 2021-02-11 11:08:43 but I have CVE fixes to push 2021-02-11 11:09:55 ok, I merged busybox change to 3.13 2021-02-11 11:17:25 ncopa: It's not just whether the image needs an update though, it's also whether security fixes are processed in a 'timely' fashion. I'm trying not to make it sound like I'm suggesting this *doesn't* happen, just passing on a friend's concerns that Alpine didn't seem to be getting security fixes soon enough for him. 2021-02-11 11:17:59 right, we do try to fix them in a timely manner, but it's hard to quantify 2021-02-11 11:26:27 Indeed. I appreciate that. 2021-02-11 11:34:10 maxice8: do you happen to work on main/screen? 2021-02-11 11:34:23 No 2021-02-11 11:34:30 ok 2021-02-11 11:35:40 if anyone work on screen, please remove utmps deps 2021-02-11 11:36:02 feel free to send a MR :) 2021-02-11 11:36:41 jvoisin: :) 2021-02-11 11:36:58 apparently there is no fix released yet for screen 2021-02-11 11:37:19 https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00000.html 2021-02-11 11:37:23 The secfix was leaked 2021-02-11 11:37:35 because it was created as private but it still an email telling it was created 2021-02-11 11:37:38 oops :D 2021-02-11 11:37:49 to the public mailing list 2021-02-11 11:37:58 "I think it wasn't supposed to be public, but it is, so better it's 2021-02-11 11:38:01 visible to security teams" 2021-02-11 11:38:21 Where is the secfix? 2021-02-11 11:38:56 There is no secfix yet 2021-02-11 11:39:14 secinfo is leaked 2021-02-11 11:39:17 ah, there was just a notificaiton 2021-02-11 11:43:07 "Unfortunately setting it to private didn't really hide that bug report from the public as all bug reports reported against Screen via Savannah — as it seems even those marked as private — are forwarded to a publicly archived mailing list." 2021-02-11 11:43:10 heh 2021-02-11 11:43:13 Good UX 2021-02-11 11:43:40 yes, this is good 2021-02-11 11:44:01 there shouldn't be hidden sec flaws 2021-02-11 11:49:14 Should vulnerability issues be disclosed before a proper fix is available? 2021-02-11 11:49:45 yes 2021-02-11 11:50:20 at least we/users will know which software is vulnerable 2021-02-11 11:50:30 and watch it being owned? :P 2021-02-11 11:50:41 and we/users can decide to use it or not 2021-02-11 11:51:11 and not blindly use vulnerable software 2021-02-11 11:52:12 But you also have to think about users who already use it and where it's often not easy to not use the software without introducing large downtimes 2021-02-11 11:52:59 imagine driving car for which manufacturer know defects which can lead to deaths, but manufacturer hide this fact till it find fix. and all this for our security 2021-02-11 11:53:33 there are different opinions on if they should be public or private. i think the most common practice is to have them hidden for a while so there is time to provide security fixes 2021-02-11 11:54:02 and that already happened with boeing jets 2021-02-11 11:54:19 mps: imagine that this flaw can be remotely triggered, and by disclosing it, everyone can trigger the issue 2021-02-11 11:55:09 or triggered accidentally, what is difference if the result is death 2021-02-11 11:55:50 all this security by obscurity is insane 2021-02-11 11:56:44 It all depends on the nature of the issue 2021-02-11 11:57:29 If it's something is already happening randomly in the wild, and it is threatening lives, then yes, of course it should be made public as soon as possible 2021-02-11 11:58:20 else, 'trust us, we will hide everything from you for your safety'. huh 2021-02-11 11:58:35 No, it's not about keeping things hidden 2021-02-11 11:58:41 indefinitely 2021-02-11 11:58:57 i think most upstream devs prefers to have it hidden til a fix is published 2021-02-11 11:58:58 more like: We do not disclose it yet, work on a fix, and then anounce the details 2021-02-11 11:59:05 ah, yes. just enough to 'mentize it' 2021-02-11 11:59:16 It's not about monitization 2021-02-11 11:59:19 monetize* 2021-02-11 11:59:28 *cough* off-topic *cough* 2021-02-11 11:59:36 jvoisin: I think it's very on-topiuc 2021-02-11 11:59:37 yeah. lets move this to offtopic 2021-02-11 12:00:04 I think this is quite fine here 2021-02-11 12:00:22 i thikn its about sec vulns in general, not so much what alpine does? 2021-02-11 12:00:29 alpine is 'security' after all 2021-02-11 12:00:58 debate about full-disclosure/coordinated-disclosure aren't alpine-specific 2021-02-11 12:01:13 and are as useful as vim vs. emacs ones 2021-02-11 12:01:27 but I agree, this is useless to discuss even on #-offtopic 2021-02-11 12:05:36 I'm working on https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/issues/1 2021-02-11 12:05:59 i wonder if our CI could error if there are '# security fixes:" instead of "# secfixes:" 2021-02-11 12:06:37 at least now, it's part of the linting job, which we allow to fail 2021-02-11 12:07:26 I was looking at having the qa bot add comments about linting issues so it becomes more visible 2021-02-11 12:07:45 i wonder if we should have a second lint for some fatal errors 2021-02-11 12:07:58 like not being able to be parsed by the shell 2021-02-11 12:08:14 but the build jobs would fail as well on that 2021-02-11 12:08:22 Never understood why the CI just went "green!" when it failed to source shell 2021-02-11 12:08:24 the ones that get through most likely didn't go through CI at all 2021-02-11 12:08:33 (. ./APKBUILD) || exit 1 2021-02-11 12:08:46 i think the CI will pass them quick 2021-02-11 12:08:53 as "nothing to build" 2021-02-11 12:09:25 hmm, it should not do that. Need to look into that 2021-02-11 12:09:42 we had some this or previous week 2021-02-11 12:10:26 cd46b1bc55e1d42a4611c705861fecd78840942a 2021-02-11 12:10:36 algitbot: hi 2021-02-11 12:10:55 algitbot: please wake up! 2021-02-11 12:11:13 Oh, wanted to look at that, lbut forgot 2021-02-11 12:12:12 ikke: btw, does gitlab provide the stuff for aports-qa-bot to comment failed lints/changes files/sonames now? 2021-02-11 12:12:54 algitbot: hi 2021-02-11 12:15:02 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17998 2021-02-11 12:16:18 hum, the CI failed there 2021-02-11 12:17:05 ncopa: That last CI run was after the MR was merged and the source branch was deleted 2021-02-11 12:17:20 You want to look at this: https://gitlab.alpinelinux.org/Leo/aports/-/jobs/315865 2021-02-11 12:17:38 Which is the actual run that was supposed to test thing 2021-02-11 12:17:50 Kind of unfortunate that we always have a CI pipeline running after merging that will always fail 2021-02-11 12:18:18 https://gitlab.alpinelinux.org/Leo/aports/-/jobs/315865#L79 2021-02-11 12:18:36 it says that there are no packages to build 2021-02-11 12:18:56 ikke: where is the script for that? 2021-02-11 12:19:38 i think the problem might be in lua-aports 2021-02-11 12:21:22 this one? https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci 2021-02-11 12:22:44 Yes 2021-02-11 12:23:27 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L99 2021-02-11 12:24:04 Ah, forgot that uses ap builddirs 2021-02-11 12:24:16 problem is there yes: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L108 2021-02-11 12:24:25 To determine the build ordr 2021-02-11 12:24:58 i think ap builddirs wil actualy exit with error, but with pipes it only picks up last process in the pipe 2021-02-11 12:25:05 and pipefail is not in POSIX 2021-02-11 12:25:20 which is what we'd need 2021-02-11 12:27:47 ncopa: Should we hold off from merging edge things right now? Currently in the progress of upgrading rust 2021-02-11 12:27:55 But I can wait until later with merging that 2021-02-11 12:30:15 ikke: i think this may work: https://tpaste.us/ejYp 2021-02-11 12:30:23 untested though and i dont know how to test it :) 2021-02-11 12:31:13 I was working on a compose setup to make it easier to test 2021-02-11 12:31:14 Cogitri: um yeah. might be nice to hold big builds til edge snapshots is tagged 2021-02-11 12:53:09 fcolista or larena: can you help me with `sed -i -e 's/^# security fixes:$/# secfixes:/' */*/APKBUILD` for 3.10-stable and 3.9-stable? 2021-02-11 12:53:29 s/larena/rnalrd/ 2021-02-11 12:53:29 ncopa meant to say: fcolista or rnalrd: can you help me with `sed -i -e 's/^# security fixes:$/# secfixes:/' */*/APKBUILD` for 3.10-stable and 3.9-stable? 2021-02-11 12:54:07 also '# - CVE N/A ZBX-11023' has got a CVE and should probably be fixed in all branches back to 3.9-stable 2021-02-11 12:54:16 or at least 3.10 2021-02-11 12:55:03 it is a follow up to https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/issues/1 2021-02-11 12:57:03 ncopa: Okie, could you ping me once it's OK to merge Rust? 2021-02-11 12:57:52 if you dont hear anything within 4 hours, then just push it 2021-02-11 12:58:09 Okie 👍️ 2021-02-11 13:02:29 ncopa: !18157 2021-02-11 13:04:07 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18157 2021-02-11 13:35:05 FYI https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/aarch64/alpine-rpi-3.13.1-aarch64.tar.gz.asc is 0 bytes 2021-02-11 13:47:31 ncopa needs to fix that 2021-02-11 13:50:12 Dealing with screen Ikke 2021-02-11 13:50:20 Debian people did a patch 2021-02-11 13:50:34 Alright 2021-02-11 14:20:33 ncopa,here I am 2021-02-11 14:20:37 ok 2021-02-11 14:24:38 ncopa, is this commit too much ugly? 2021-02-11 14:24:39 main/*; community/*: updated security fixes in secfixes 2021-02-11 14:24:42 :) 2021-02-11 14:25:10 Or do you want me to commit correct description for individual package? 2021-02-11 14:25:50 I think we usually do split commits per repo (as in make one for main and one for community) 2021-02-11 14:26:23 Cogitri, yeah. I was wondering the same while i was typing... 2021-02-11 14:27:16 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18157 2021-02-11 14:30:56 ncopa, done for 3.9 and 3.10 2021-02-11 15:07:17 ikke: rust cross compilation is now fixed theoretically 2021-02-11 15:10:12 fcolista: great thanks! maybe close the issue then 2021-02-11 15:12:48 Ariadne: nice! 2021-02-11 15:13:17 attempting s390x bootstrap of rust 2021-02-11 15:13:20 Ariadne: let's see if it also works in practice :-) 2021-02-11 15:13:48 ikke: it works for aarch64 and x86_64 in practice (i crossed x86_64 -> aarch64 and vice versa) 2021-02-11 15:17:36 lucidone: thank you for notifying. I have updated it. 2021-02-11 15:18:14 i think we need to purge the dl-cdn cache once its mirrored 2021-02-11 15:21:36 with any luck, we will have rust on s390x and mips64 very soon 2021-02-11 15:21:52 and riscv64 bootstrap should 'just work' as i did the prerequisite work to enable it already 2021-02-11 15:23:07 Ariadne: fwiw currently working on rust 1.49 2021-02-11 15:23:19 Working as in waiting for the builders to be available 2021-02-11 15:23:53 Adjusted the s390x musl triplet to work with the changes to Target/TargetOptions 2021-02-11 15:24:05 ok 2021-02-11 15:24:10 x.py dist change was important 2021-02-11 15:24:42 it turns out x.py build does not really work anymore for cross 2021-02-11 15:25:00 as for rust 1.49, shouldn't we do 1.48 first? 2021-02-11 15:25:33 afaik you need 1.47 -> 1.48 -> 1.49 2021-02-11 15:25:42 Yes 2021-02-11 15:25:46 We already have a MR for 1.48 2021-02-11 15:25:49 ok 2021-02-11 15:25:59 i guess lets rebase the 1.48 2021-02-11 15:26:00 Will merge that once ncopa gives the go, then wait for it to be built and then immediately push 1.49 2021-02-11 15:26:13 and tackle bootstrap once 1.49 is in 2021-02-11 15:26:18 make sense? 2021-02-11 15:26:25 that timeline works better for me anyway 2021-02-11 15:26:42 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18163 2021-02-11 15:26:54 but going to still try bootstrap s390x rust locally to make sure it is working 2021-02-11 15:26:56 Sure, sound best to get to the most recent rustc first and bootstrap afterwards 2021-02-11 15:28:45 also instead of custom alpine triplets i'd rather they just fix the normal musl ones 2021-02-11 15:29:39 Not gonna happen, for most rustc folks musl == only good for static linking when they're on a glibc host 2021-02-11 15:30:02 Ariadne: how will the cross bootstrap workout go? 2021-02-11 15:30:32 Although there were some talks about a *-unknown-linux-dynmusl or something like that to have a dynamically linked musl flavour 2021-02-11 15:30:33 s/workout/actually 2021-02-11 15:30:33 ikke meant to say: Ariadne: how will the cross bootstrap actually go? 2021-02-11 15:31:05 ikke: most likely i will generate a repo with s390x rust/cargo bootstrap, and then we add that to s390x builder and kick off a rebuild of rust/cargo on it 2021-02-11 15:31:21 Aha 2021-02-11 15:31:34 Making a tarball of a working rustc compiler for that arch, uploading it to d.a.o and adding it as source in the rust APKBUILD and adjusting PATH would work too 2021-02-11 15:31:39 That's how we bootstrapped the other arches 2021-02-11 15:32:31 that is another approach, yes :) 2021-02-11 15:32:48 however, bootstrap.sh already generates rust/cargo package 2021-02-11 15:33:19 we should also finish bootstrapping ghc 2021-02-11 15:33:44 We had some somewhat working ghc tarballs for aarch64 2021-02-11 15:33:55 But it was all a massive pain so I stopped caring at some point to be honest 2021-02-11 15:34:16 well theres no need to generate tarballs, we can generate real apks :) 2021-02-11 15:34:56 Is it a good time to merge ? 2021-02-11 15:34:56 Ah yes, but the pain inducing part weren't the tarballs 2021-02-11 15:35:01 the rust developers suggest that we should do an MCP to sort out the custom target mess 2021-02-11 15:35:29 MCP? 2021-02-11 15:35:51 i pointed out that every distro is either adding custom targets (like we do) or patching the default musl targets to change them to dynamic linking 2021-02-11 15:36:30 i will ask what an MCP is 2021-02-11 15:36:45 maxice8: No edge snapshot has ben made yet 2021-02-11 15:37:04 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18121 2021-02-11 15:37:14 Ariadne: FWIW, Rust devs wouldn't mind us upstreaming our triplets either 2021-02-11 15:37:34 When I emailed them if we can keep calling our rust rust after the trademark stuff they mentioned that that'd work for the core team too 2021-02-11 15:38:52 Cogitri: i'm talking to rust devs, but i don't want to just solve this "for alpine" 2021-02-11 15:39:03 i want to solve this for the entire ecosystem 2021-02-11 15:39:30 Fair, but then either them adding their own triplets too or a dynmusl triplet is the way forward 2021-02-11 15:39:37 so if we upstream the targets/triplets, we should name them something more generic :) 2021-02-11 15:39:41 ikke: btw, does flint just take really long to build or is it stuck? 2021-02-11 15:39:44 maxice8: includes a merge commit! 2021-02-11 15:39:51 dynmusl sounds good 2021-02-11 15:40:19 https://github.com/rust-lang/rust/issues/59302#issue-422994250 2021-02-11 15:40:28 Cogitri: I can check in a bit 2021-02-11 15:40:39 >TODO: Convenient way to link dynamically (e.g. $arch-unknown-linux-dynmusl triple) 2021-02-11 15:40:50 ikke: Thanks :) 2021-02-11 15:42:07 Also https://github.com/rust-lang/rust/pull/58575#issuecomment-568098210 2021-02-11 15:45:12 ok 2021-02-11 15:45:32 well i think we should rework our triplets to be dynmusl and upstream them. then we can transition ours out 2021-02-11 15:47:38 I think I'd rather create a PR upstream about it, see what they think about it and then just drop our triplets once the upstream dynmusl triplets make it into a stable release we use 2021-02-11 15:48:15 if flint does not finish within 10 mins i'll have to wait with the edge snapshot release til tomorrow 2021-02-11 15:48:36 Ariadne: congrats with the rust success! 2021-02-11 15:48:45 very very nice to have rust fixed 2021-02-11 15:49:07 i think we already have fixed the triplets for rust? 2021-02-11 15:49:38 Yes, our triplets already work, but would be nice if we didn't need custom triplets 2021-02-11 15:50:28 On the other hand, we also have custom triplets for clang and so on and they're not a lot of effort to maintain 2021-02-11 15:50:38 And things like firefox don't really expect the cc and rust triplets to differ 2021-02-11 15:51:35 we use same triplets for gcc and clang and rust right now, right? 2021-02-11 15:51:41 Yup 2021-02-11 15:52:08 Oh, seems like armv7 made progress and is on linux-edge now 2021-02-11 15:52:12 ugh.. 2021-02-11 15:52:15 i mean 2021-02-11 15:52:17 great... 2021-02-11 15:52:18 :) 2021-02-11 15:52:21 Heh 2021-02-11 15:52:35 36% 2021-02-11 15:53:40 you know what... just push your stuff. there wont be any release today 2021-02-11 15:53:53 would be nice if builders are idle tomorrow morning though 2021-02-11 15:54:11 imho fixing rust is high prio 2021-02-11 15:54:12 Alrighty, let me push rust 1.48 then, thanks 2021-02-11 15:54:23 Well, there's nothing to be fixed really :) 2021-02-11 15:54:26 The current setup works just fine 2021-02-11 15:56:35 Let's hope linux-edge and flint don't take that long to build, I'll have to wait with for builders to be idle again to push 1.49 too 2021-02-11 15:57:39 hum im not sure i like the rust's -dynmusl 2021-02-11 15:58:08 iirc firefox expectes the rust's target and cc target to have same triplet or bad thigs happens 2021-02-11 16:02:52 -dynmusl looks ugly 2021-02-11 16:04:32 ncopa: Yup, firefox expects rustc triplet == cc triplet, but fixing the configure script probably wouldn't be too hard 2021-02-11 16:05:05 what else will break in the future for same reason? 2021-02-11 16:05:10 But other software probably has the same problem and having the same triplet everywhere is pretty nice imho 2021-02-11 16:10:44 seems like flint passed 2021-02-11 16:10:55 Hooray 2021-02-11 16:19:32 rust 1.50.0 is out 2021-02-11 16:23:00 Lol 2021-02-11 16:24:35 ncopa: is that a joke 2021-02-11 16:24:48 ...that is not a joke 2021-02-11 16:24:58 well then 2021-02-11 16:25:14 i guess we go all the way to 1.50 :) 2021-02-11 16:33:10 Yup 2021-02-11 16:33:50 Gonna merge 1.49 once the builders are done with 1.48 (but that'll take a little since linux-edge takes its time on armv7) 2021-02-11 16:34:07 I do wonder why armv7 is so much slower 2021-02-11 16:34:34 maybe baseline is without proper fpu ? 2021-02-11 16:35:53 sh4rm4^bnc: the host is aarch64 2021-02-11 16:36:13 it runs an lxc container with armv7 userland 2021-02-11 16:42:18 i have AMD EPYC 7742P and rust just sits there wasting cpu on ipc overhead if you try to use -j256 2021-02-11 16:42:59 the builder has 64 threads 2021-02-11 16:43:30 which builder 2021-02-11 16:43:33 x86_64? 2021-02-11 16:43:44 armv7 2021-02-11 16:44:13 sweet spot for rust seems to be -j32 or maybe -j64 2021-02-11 16:44:27 In this case it would use -j64 2021-02-11 16:44:29 anything more aggressive and htop starts showing red 2021-02-11 16:44:34 instead of green 2021-02-11 16:44:37 cpu use 2021-02-11 16:44:41 due to ipc overhead :D 2021-02-11 16:45:03 ikke, i meant that the binaries produced don't use the FPU 2021-02-11 16:47:22 What could cause that? 2021-02-11 16:47:59 Ariadne: Yup, rustc uses 100% CPU on my 3950X w/ -j32 unless it goes into linking mode 2021-02-11 16:48:28 Cogitri: Any chance that clang/llvm gets updated soon? It seems like `-specs` is not supported with clang 10, but it is documented here: https://clang.llvm.org/docs/ClangCommandLineReference.html I assume it was added just recently. 2021-02-11 16:50:11 Cogitri: 100% cpu is fine, but this is 80% cpu spent in kernel doing ipc 2021-02-11 16:50:33 Marian[m]: Maybe after rustc 2021-02-11 16:50:34 Marian[m]: yes going to llvm 11 is planned 2021-02-11 16:51:01 Exams are next month for me though, so I probably wont get to it before that, but maybe someone else can look into it already 2021-02-11 16:51:50 I can open an MR. Should it create an llvm11 package in addition to the existing llvm10, or should llvm10 be dropped? 2021-02-11 16:52:02 keep llvm10 for now 2021-02-11 16:52:19 OK :-) 2021-02-11 16:54:47 I think we already have an MR that's stale 2021-02-11 16:54:50 Maybe you can base your work off of that 2021-02-11 17:03:00 humm 2021-02-11 17:03:05 we might want to stay on 1.47 actually 2021-02-11 17:03:13 oh? 2021-02-11 17:03:14 there are regressions on big endian 2021-02-11 17:03:18 1.48 was already pushed 2021-02-11 17:03:21 f 2021-02-11 17:03:33 well 2021-02-11 17:03:43 dunno 2021-02-11 17:03:48 i guess we go with it 2021-02-11 17:03:49 but 2021-02-11 17:04:06 https://github.com/rust-lang/rust/issues/80810 2021-02-11 17:41:47 clandmeter: please prepare two virtual medals, one big for you and one smaller for me 2021-02-11 17:42:45 following your and my guide about installing alpine aarch64 under qemu my son just booted alpine on macbook pro M1 2021-02-11 17:46:57 Ariadne: Would Rust >1.48 make things worse? 2021-02-11 17:47:04 As in can I push 1.49 and 1.50? 2021-02-11 17:47:55 Building 1.50 right now 2021-02-11 18:03:17 mps: Nice. It's just aarch64? 2021-02-11 18:04:08 clandmeter: yes 2021-02-11 18:04:29 our iso as it is for download 2021-02-11 18:04:41 And a custom kernel 2021-02-11 18:04:46 no 2021-02-11 18:05:14 -boot d -cdrom alpine...aarch64..iso 2021-02-11 18:05:34 Ok, so not all is working 2021-02-11 18:05:39 All hw 2021-02-11 18:06:04 what qenmu support this works 2021-02-11 18:06:19 qemmu* 2021-02-11 18:07:01 Ah in reading it wrong 2021-02-11 18:07:15 but I observed just setup-alpine part, son went to his home after that 2021-02-11 18:08:42 So next thing is to boot it natively 2021-02-11 18:10:12 I prepared everything for native boot, but waiting for apple to upgrade 1TR (one true recovery) because current have bug and doesn't allow to set which kernel to boot 2021-02-11 18:13:15 I already built kernel and preboot tools for M1 on alpine 2021-02-11 18:24:38 mps: there is a list of what is and what is not working? 2021-02-11 18:27:28 well, I just followed discussion on #asahi channel and can try to say from the head, which would be wrong probably 2021-02-11 18:28:11 but some people managed to run ubuntu with X on it 2021-02-11 18:28:44 ubuntu distro for RPi4 2021-02-11 18:29:49 and if ubuntu run I have no doubt that alpine will also 2021-02-11 18:31:09 some things are already posted to linux-next upstream 2021-02-11 18:32:22 but apple is not fast in fixing bugs, especially if these bugs are not important for most of their users 2021-02-11 18:38:00 clandmeter: https://corellium.com/blog/linux-m1 2021-02-11 18:51:04 only ppc64le and armv7 left for rust 2021-02-11 19:10:09 mps: yeah i got alpine arm64 booted fine with the corellium kernel, pretty much the only issue was figuring out the wlan mac address script in their ubuntu distro 2021-02-11 19:11:12 tmlind: ah, how did you set boot kernel in 1TR, for me kmutil didn't worked 2021-02-11 19:11:19 mps: i'd assume the asahi patches will be merged to the mainline linux within few weeks then sorting out the drivers can start 2021-02-11 19:12:26 mps: i followed the usb boot instructions with a usb, i tried asahi kernel with m1n1 first and nothing 2021-02-11 19:12:57 mps: then i downloaded corellium bootloader and kernel mach-o blob and that booted just fine 2021-02-11 19:13:25 I don't know, kmutil on normal boot works but not from 1TR (rescue mode) 2021-02-11 19:13:57 on what machine you tested, pro or air 2021-02-11 19:14:20 mps: then i formatted a nvme partition, installed alpine there, rebooted and the same kernel mounted alpine on nvme 2021-02-11 19:14:26 mps: macbook air 2021-02-11 19:15:08 ah, that can be difference, my son have pro where kmutil doesn't work properly 2021-02-11 19:15:12 mps: had to do that twice :) forgot to add eudev initially.. 2021-02-11 19:15:23 checkdepends is appended to makedepends, right?\ 2021-02-11 19:15:55 abuild installs depends + makedepends + checkdepends 2021-02-11 19:16:05 tmlind: heh, we always forget something in a hurry (or excited state) 2021-02-11 19:16:30 omni: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2166 2021-02-11 19:17:09 thanks 2021-02-11 19:19:43 tmlind: thanks for info, I will ask on #asahi why kmutil on macbook pro doesn't work 2021-02-11 19:20:18 mps: afaik they should be the same, are you not getting the asahi m1n1 boot log on the screen? 2021-02-11 19:20:49 tmlind: I didn't tried m1n1 2021-02-11 19:21:21 well, machine is not mine and I don't want to make mess on it 2021-02-11 19:21:29 mps: ok 2021-02-11 19:22:18 tmlind: I want to try less intrusive options 2021-02-11 19:22:53 mps: typing this on m1 alpine :) battery status won't work, audio won't work, no camera, no acceleration for display, but basics do work 2021-02-11 19:23:36 graphics are fast enough, compiling arm64 defconfig time make -j8 was around 4 mins 2021-02-11 19:23:49 tmlind: yes, I know as I remember first steps with alpine on chromebooks 2021-02-11 19:24:32 mps: that was make -j8 Image dtbs i think i did 2021-02-11 19:24:49 '4 mins', heh not bad 2021-02-11 19:25:25 my son is quite satisfied with this machine for his development work 2021-02-11 19:25:25 mps: yeah it got a bit warm so i bet it does a lot of thermal throttling 2021-02-11 19:29:51 tmlind: I read that Alissa Rosenzvieg (something like this) already started to work on gpu and posted first results 2021-02-11 19:30:17 she made panfrost drivers 2021-02-11 19:31:07 Does someone want to build something before I push rust 1.49? 2021-02-11 19:31:25 Will push it in 30~60 minutes when the builders are idle otherwise 2021-02-11 19:31:36 not me 2021-02-11 19:33:58 Hmm is Gitlab down? 2021-02-11 19:34:00 disappointing 2021-02-11 19:34:20 PureTryOut[m]2: not here 2021-02-11 19:34:28 Do you mean Alpine's GitLab instance PureTryOut (matrix.org) ? 2021-02-11 19:34:31 I read "she made pancakes" and I was like, wow, people who do actual cooking on GPUs, finally a good way to use the heat 2021-02-11 19:34:34 Works fine for me' 2021-02-11 19:34:44 Oh it took a few tries, now it works 2021-02-11 19:34:47 Newbyte: obviously 2021-02-11 19:35:04 and I was looking forward to seeing the pictures of freshly baked pancakes 2021-02-11 19:35:19 'panfrost drivers' is much less interesting 2021-02-11 19:37:45 ikke, maybe default CFLAGS not adding -mfpu=neon or whatever the baseline you use is 2021-02-11 19:39:18 mps: yeah let's hope it all works out as planned 2021-02-11 19:41:35 tmlind: well, I'm not apple fan (actually dislike them) but they made good hardware I must admit 2021-02-11 19:43:51 mps: yup agreed, first time i'm paying for any of their gear since early 90's.. 2021-02-11 19:45:57 tmlind: two months ago I had some 'free' money and thought to buy this box but didn't and now I sorry, and money went for something else 2021-02-11 19:49:36 oh well, let's hope more similar devices become available from other laptop makers too 2021-02-11 19:50:51 tmlind: I have two arm64 chromebooks with 4GB RAM and one 4 CPUs, other one 6, they are quite fine still 2021-02-11 19:54:46 mps: ok cool 2021-02-12 06:36:55 good morning! 2021-02-12 06:37:03 morning 2021-02-12 06:37:28 wow the builders are all idle! 2021-02-12 06:37:38 uh 2021-02-12 06:37:42 thank you! 2021-02-12 06:37:56 Just ctrl-c'd 3 merges 2021-02-12 06:38:10 lol 2021-02-12 06:38:25 ACTION uploaded an image: image.png (12KiB) < https://synapse.cogitri.dev/_matrix/media/r0/download/cogitri.dev/CaHDWktxgEkYhvyPyAyyDvDH/image.png > 2021-02-12 06:38:50 let me just tag an edge release. i just need 5-15 mins 2021-02-12 06:41:45 tmlind, mps: awesome that you got alpine running on the M1 chip 2021-02-12 06:43:22 and the snapshot is done.... maxice8: please feel free to push again 2021-02-12 06:46:28 thanks 2021-02-12 07:33:12 ncopa: it is not yet ready for 'run alpine out-of-the-box' on M1, but more testing and guessing what tools are needed and how it will work 2021-02-12 07:34:17 first patches is sent to lkml just about week ago 2021-02-12 07:36:04 I'm more 'concentrated' to prepare needed tools for booting (m1n1 and preboot tools) and testing out-of-tree kernel 2021-02-12 07:36:32 but, qemu iso aarch64 boots and works fine 2021-02-12 07:36:46 in qemu* 2021-02-12 07:38:08 and good morning to all 2021-02-12 08:54:03 o/ 2021-02-12 09:01:16 yes, i saw that patches was sent to lkml recently. I'm just pleased to see that it boots. it means that it will likely work in not too far future 2021-02-12 09:28:29 we will see on next kernel merge window, which will be probably opened next week, 5.11-rc7 is quite fine already 2021-02-12 10:08:19 Merged Rust 1.50 and FF upgrade, so the builders will be busy for a bit 2021-02-12 10:21:05 heh, I don't have patience to read even subjects of mails in lkml, so I unsubscribed long ago 2021-02-12 11:04:15 I'm using !17649 to load intel ucode for my xen install, what is needed for it to be merged? 2021-02-12 11:04:46 should I squash to one commit? 2021-02-12 11:07:05 I think !17647 is ok to, although I cannot test it 2021-02-12 11:09:02 I kinda liked the bot btw, at least for presenting URLs for MRs and issues 2021-02-12 11:09:18 \o/ 2021-02-12 11:09:33 is algitbot sick? 2021-02-12 11:09:37 algitbot: please wake up! its not weekend yet 2021-02-12 11:10:26 oh, it's still here, it just don't want to talk to us 2021-02-12 12:09:20 It does work in #alpine-commits though, weird 2021-02-12 12:47:41 In #alpine-commits algitbot hasn't responded to me for quite a while, but I do see it responding to others 🤷‍♂️ 2021-02-12 13:12:33 algibot is on strike 2021-02-12 13:20:49 can anyone tell me if alpine kernels are signed at all please? 2021-02-12 13:22:36 You mean kernel modules? 2021-02-12 13:25:39 both 2021-02-12 13:25:48 kernel and any modules 2021-02-12 13:30:06 alpine is described as security oriented, so i was looking to see where it stands with secure boot, working backwards i thought i'd see where the kernel is at, then shim, grub etc, currently there is no signed shim or grub, but they are fairly pointless with out a signed kernel 2021-02-12 13:30:49 just thinking how alpine would go about creating signing infra similar to how debian have done it 2021-02-12 13:31:11 ade______: you consider secure something made by MS? 2021-02-12 13:31:12 for the archs that support secure boot, clearly :) 2021-02-12 13:31:42 i consider it a better option than nothing :) 2021-02-12 13:31:55 :) 2021-02-12 13:32:39 no, alpine is not yet fully engaged in security theaters 2021-02-12 13:44:34 am i missing something with the package signing too, i see iso files are gpg signed too assure downloads are as true as the website pointing to the gpg files, but nothing else 2021-02-12 13:45:14 The iso includes rsa keys that are used to verify apks 2021-02-12 13:45:47 /etc/apk/keys 2021-02-12 13:45:57 ah great so they are verified ... great start 2021-02-12 13:54:01 cool just looked inside a random apk file, now i see what is going on, cheers 2021-02-12 14:01:58 aaaa, qemu build on apple M1 in less 30 seconds, yes seconds 2021-02-12 14:03:50 something must be wrong, ofc 2021-02-12 14:04:51 Obviously 2021-02-12 14:06:46 maybe they have ccache by default 2021-02-12 14:23:56 Opinions on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15422 (moving mercurial to community) 2021-02-12 14:41:03 No strong opinion, as I don't use hg ;-) 2021-02-12 15:05:45 me neither but it seems reasonable, it's pretty good isn't it? 2021-02-12 15:07:10 omni: The MR is about demoting it from main to community 2021-02-12 15:07:22 oh, thought it was in testing 2021-02-12 15:07:37 Since hg is rustifying too and rust is in community 2021-02-12 15:07:48 ah 2021-02-12 15:07:50 if it's just for the rust stuff (experimental) I'm not sure 2021-02-12 15:08:15 mercury oxide isn't named rust 2021-02-12 15:08:27 but you don't want to ingest it either 2021-02-12 15:09:52 "Rust is not required to use (or build) Mercurial" 2021-02-12 15:11:17 What is it used for (Oxide?) 2021-02-12 15:12:57 Seems like firefox still tried to build smoosh 2021-02-12 15:13:14 ikke: "improves performance in some areas": https://www.mercurial-scm.org/repo/hg/file/tip/rust/README.rst 2021-02-12 15:14:12 ikke: make clean ; make -j8 in qemu dir took 50 seconds on M1, tested two times 2021-02-12 15:15:39 e8: ah whoops, forgot to push the commit to disable smoosh to 3.13-stable 2021-02-12 15:19:52 when your codebase is so bad that you have to switch to Rust to improve performance 2021-02-12 15:45:33 ah hop dang, secure boot is not easy to get shim signed now, you need an EV cert for MS to accept signing requests .. soon gets expensive, maybe when alpine has more sponsorship it could be an option.. but for now i can understand the blocker !! 2021-02-12 15:52:59 Much effort, little reward 2021-02-12 15:53:25 "secure" boot 2021-02-12 15:56:33 ideally its about making sure kernel modules are allowed to be loaded, currently it puts the effort on the users rather than on the build system like debian/fedora/whoever does 2021-02-12 15:56:58 *which kernel modules are allowed to be loaded 2021-02-12 15:58:17 rather than (not) seeing some nasty actor popping unknown modules in on you, ala drovorub 2021-02-12 15:58:57 so perhaps a signed kernel / modules from alpine is at least part of the way to a safer system 2021-02-12 16:18:18 hmm, what's up with grafana 2021-02-12 16:19:06 check fails, but I don't see any failed tests 2021-02-12 16:46:37 tmlind: I got alpine boot on M1 with root fs on usb device 2021-02-12 16:47:09 I just copied my current root fs from my workstation to usb 2021-02-12 17:21:12 ade______: mhm, with CONFIG_MODULE_SIG_FORCE=y or module.sig_enforce=1 2021-02-12 17:23:01 requiring module signing breaks out-of-tree modules though, unless you have infrastructure to make sure they are signed with the same keys 2021-02-12 17:25:09 if users are compiling their own modules, their out of luck 2021-02-12 17:25:28 theyr 2021-02-12 17:27:31 theaeire 2021-02-12 17:28:32 ikke: sure, so then not CONFIG_MODULE_SIG_FORCE but allow for module.sig_enforce=1 2021-02-12 17:28:54 omni: can you not allow module.sig_enforce=1? 2021-02-12 17:29:04 if you create a signed kernel for distribution and yes set module.sig_enforce=1 then you have an ok solution, but if the kernel is not signed by alpine, rather moot 2021-02-12 17:29:49 ikke: I mean, if you set CONFIG_MODULE_SIG_FORCE=y module.sig_enforce=0 has no effect 2021-02-12 17:30:08 omni: yes, ofcourse 2021-02-12 17:30:30 so alpine could sign modules and let the user choose to enforce signature checks 2021-02-12 17:30:40 two kernel flavours, 1 signed for xx% of the users, 1 not signed for those who want to compile there own modules ... on alpine how many folks compile there own modules compared with those who don't have a need ?? 2021-02-12 17:30:42 I'd like that 2021-02-12 17:31:16 ade______: we would not know ;-) 2021-02-12 17:31:31 We have no telemetry, you know 2021-02-12 17:31:45 but you wouldn't need to, if it was disabled by default 2021-02-12 17:32:47 or module.sig_enforce=1 boot param could be added by default and if that breaks it for any user they can be advices to set it to 0 to load whatever modules 2021-02-12 17:32:51 But I don't think Alpine should support a signing scheme which only MS controls 2021-02-12 17:33:01 is it? 2021-02-12 17:33:27 dload logs for number of kernel headers and gcc vs iso / update requests, must give rough oder of mag ;) ... maybe 2021-02-12 17:33:49 I thought it was the kernel that was in control of loading signed or unsigned modules 2021-02-12 17:33:53 ade______: there are numerous public and private mirrors 2021-02-12 17:34:14 omni: That was more about signed kernels (secure boot) 2021-02-12 17:34:45 that was where the discussion started, I'm talking about signed modukles 2021-02-12 17:34:47 a signed kernel is not the same thing as secure boot, that is true 2021-02-12 17:35:15 but it is a better trust model than no signing of any modules 2021-02-12 17:35:15 You need something that checks the signature, and trust the thing that checks the signature 2021-02-12 17:35:30 otherwise you could just be evil maidened 2021-02-12 17:35:40 which I guess is what you want to protect against 2021-02-12 17:35:48 yeah, this is just post boot, but still 2021-02-12 17:36:06 yeah, signed modules help against modules that get added post-boot 2021-02-12 17:36:32 I'd want to be protected from some js shit loading some unsigned kernel module through my broken browser 2021-02-12 17:36:34 there is btw also an option to disable loading of modules which cannot be enabled anymore 2021-02-12 17:37:13 like the BSD securelevel? 2021-02-12 17:37:19 https://en.wikipedia.org/wiki/Securelevel 2021-02-12 17:37:20 [WIKIPEDIA] Securelevel | "securelevel is a security mechanism in *BSD kernels, which can optionally restrict certain capabilities. Securelevel is controlled by a sysctl variable kern.securelevel. This value is an integer, which set to a value > 0 enables certain class of restrictions. Any superuser process can raise securelevel..." 2021-02-12 17:37:50 I'd be fine with something like that too 2021-02-12 17:38:34 https://xkcd.com/538/ 2021-02-12 17:38:34 https://xkcd.com/538 | Security | Alt-text: Actual actual reality: nobody cares about his secrets. (Also, I would be hard-pressed to find that wrench for $5.) 2021-02-12 17:39:07 that's so binary 2021-02-12 17:39:49 omni: /proc/sys/kernel/modules_disabled 2021-02-12 17:39:51 https://man7.org/linux/man-pages/man5/proc.5.html 2021-02-12 17:41:03 CONFIG_SECURITY_LOCKDOWN_LSM 2021-02-12 17:41:42 ikke: thanks! 2021-02-12 17:42:12 use case, modules disabled from loading, plug-in usb stick ... user expects a device they can mount .. nothing there as no module loaded, however, with signed modules, you can still load the module as expected, but not some random code compiled as a module like the js web browser example above 2021-02-12 17:43:00 true 2021-02-12 17:44:18 signed modules falls down from a signed at distro level only for things like local users wanting to do nvidia modules etc ... they would need to do their own signing of the kernel and therefore the key to do the new module and sign that too 2021-02-12 17:45:12 so 2 kernels in the tree, signed by distro and one not signed for users to do as they wish 2021-02-12 17:45:31 just a thought 2021-02-12 17:46:47 build time is the same, packaging just adds the signing to one of the 2 variants 2021-02-12 17:46:58 but, I may have gotten this wrong here, can't a user just boot with module.sig_enforce=0 and do as they wish? 2021-02-12 17:47:07 yes 2021-02-12 17:47:31 but a reboot would be noticed on a running system 2021-02-12 17:47:54 and then you wouldn't both signed and unsigned kernels 2021-02-12 17:48:16 *need both 2021-02-12 17:48:50 what if user wants signed kernel _and_ own compiled modules 2021-02-12 17:49:10 boot with module.sig_enforce=0? 2021-02-12 17:49:20 current modules would be signed with distro key, new module would be signed with users own key 2021-02-12 17:50:43 with enforce=0 to allow own compiled module you force the user to not use distro kernel, but own kernel and module .. if they wanted a signed kernel 2021-02-12 17:51:32 isn't a signed kernel only for this secure boot thing??? 2021-02-12 17:51:36 1 distro signed, 1 distro not signed, freedom to chose either option 2021-02-12 17:51:47 ignore secire boot 2021-02-12 17:51:59 * ignore secure boot 2021-02-12 17:52:01 (oups, lag and key repetition rate, didn't mean threee ?) 2021-02-12 17:52:07 for 3 years now I can't remember that someone seriously asked for signed alpine kernels 2021-02-12 17:52:58 ade______: do you mean that someone would want to "secure boot" a kernel and then not care about signed modules? 2021-02-12 17:53:21 all the cool kids want it these days, that and a new phone with a bigger screen and skinny jeans 2021-02-12 17:53:24 ;) 2021-02-12 17:54:13 hmm, maybe this is for #alpine-offtopic channel 2021-02-12 17:55:03 someone without UEFI (with or without secure boot) may want to enforce only modules that are trusted in that they came from a known source (in this case alpine repository) 2021-02-12 17:55:34 so ...enforce=1 in grub for example 2021-02-12 17:55:54 hmm, maybe this is for #alpine-offtopic channel 2021-02-12 17:58:59 I think signed modules are pretty on-topic for a "security-oriented" distro, signed kernel perhaps not 2021-02-12 17:59:44 omni: like every bikesheding, yes 2021-02-12 17:59:46 me too , sorry if it seems too related to security 2021-02-12 18:00:30 perhaps we should open an issue in gitlab and discuss it there instead of spamming the channel though 2021-02-12 18:01:14 omni: yes, this is good (especially because none like to read issue reports :) ) 2021-02-12 18:21:04 would flagging the package as out of date in pkgs.alpinelinux.org be effective, or should I open issues for reported CVEs? What would the developers prefer? 2021-02-12 18:22:59 It depends a bit on whether the users are active on gitlab or not 2021-02-12 18:23:12 you eman the maintainers? 2021-02-12 18:23:50 yes 2021-02-12 18:24:15 what does flagging the package out of date do/ shoot an email off? 2021-02-12 18:24:29 yes 2021-02-12 18:25:08 mps: ok nice :) fyi, firefox javascript is behaving on arm64, while it keep oopsing on armv7. well i have not tried on armv7 for a few weeks 2021-02-12 18:25:11 i suppose that's effective as anything. 2021-02-12 18:25:24 does it auto create issues in gitlab as well? 2021-02-12 18:26:23 no 2021-02-12 18:26:26 tmlind: I didn't upgraded armv7 chromebook to 3.13 yet so I don't know if FF crashes 2021-02-12 18:28:18 mps: the reproducable testcase for me is loading .fi weather forecast for any location like helsinki: ilmatieteenlaitos.fi/saa/Helsinki 2021-02-12 18:28:59 mps: it crashes on armv7 but works on arm64 2021-02-12 18:29:37 mps: the end result is you see some errors in dmesg 2021-02-12 18:30:41 mps: then another issue is that qutebrowser fails for both arm64 and armv7 with some out of memory type errors, while it works fine on x86 2021-02-12 18:32:03 mps: if you have javascript disabled with noscript for example, the armv7 firefox testcase won't trigger until you enable javascript for the current page 2021-02-12 18:36:39 ikke: maybe there's value in having it do that? 2021-02-12 18:38:46 c705: if someone is interested in building that :) 2021-02-12 18:40:54 tmlind: thanks for all info, but I will not have time to upgrade armv7 till next weekend 2021-02-12 18:42:38 today I lost nearly all day to help my son to build qemu with hvc for macbook M1 and to find proper parameters for it to work smootly 2021-02-12 18:43:22 and I have some other things to 'get is some shape', acceptable but far from perfect 2021-02-12 18:44:32 ikke: how does the email get sent? is there a backend api? 2021-02-12 18:45:46 c705: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/mail.lua 2021-02-12 18:46:15 mps: no worrries, i've been also crippled with a cracked radius for past month so i've done only the minimal work related typing 2021-02-12 18:46:48 c705: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/controller.lua#L126 2021-02-12 19:00:31 mps: I've noticed, I read through most of them this week 2021-02-13 09:21:39 that was unfair of me, I know that almost 11k issues have been closed/resolved and there's a lot of activity in the issue and MR trackers, I've also received some very helpful input for some of mine 2021-02-13 09:24:23 I've gone through many of the open issues, from the oldest and forward, to try and help bring the number of open issues down 2021-02-13 11:21:34 hmm, download section on site have https for dl-cdn.alpinelinux.org which doesn't work 2021-02-13 11:26:15 Why not? 2021-02-13 11:26:32 https://dl-cdn.alpinelinux.org/alpine/ 2021-02-13 11:38:23 don't work for me 2021-02-13 11:39:22 huhm, now it works 2021-02-13 11:39:44 interesting 2021-02-13 11:41:08 it has been working for several months (with https) 2021-02-13 12:04:01 for some unknown reason it didn't worked from my link about 5-10 minutes 2021-02-13 16:15:31 Hi All,  I am trying to locate someone with Alpine-Xen experience for a PoC project that I am doing and am considering to try the Alpine-Xen distro for a RAM-based demo to run a few user VM's and initially connect to them via VNC, Spice or other protocol. I found some documentation on the Alpine site (https://wiki.alpinelinux.org/wiki/Xen_Dom0) 2021-02-13 16:15:32 and even the distro to download, but would like to find someone who actually uses it, or develops for the Alpine-Xen distro.  Anyone here have ideas on this? 2021-02-13 16:26:08 I use Xen, but traditional hd install (sys disk mode) 2021-02-13 16:29:01 omni Awesome as I have already tried the HD install of Xen via the XCP-ng project and can connect to it via the XenCenter windows software.  While a very nice setup, the project that I am attempting is a complete RAM-based, ultra-Small footprint Xen that can be booted from an ISO or USB image. 2021-02-13 19:46:31 hmm, again 'All users of the 5.10 kernel series must upgrade. 2021-02-13 19:46:43 what now? 2021-02-13 19:46:52 two times in a week 2021-02-13 19:47:02 yeah but what is it now? 2021-02-13 19:47:09 https://lwn.net/Articles/846116/ 2021-02-13 19:47:38 don't see any CVE, but ... 2021-02-13 19:47:59 CVE-2021-20200 ? 2021-02-13 19:48:09 btw could we remove VM_GROWS* ? 2021-02-13 19:48:10 looks like squashfs is buggy 2021-02-13 19:48:10 they're useless 2021-02-13 19:48:21 squashfs is irrelevant to anyone not using it 2021-02-13 19:48:36 alpine using it for modloop 2021-02-13 19:48:53 yes 2021-02-13 19:49:14 wtf is modloop anyway? i always get an error about not being able to mount it at boot time 2021-02-13 19:49:30 contains the kernel modules for run-from-ram systems 2021-02-13 19:49:35 but anyway a squashfs bug would not be "all users must upgrade" 2021-02-13 19:50:15 this is GKH mantra 2021-02-13 19:50:24 :) 2021-02-13 19:51:02 for well being, I presume 2021-02-13 19:51:13 "all users must upgrade" is only appropriate for bugs in components that affect all users 2021-02-13 19:51:26 this looks like the big new vuln: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=246c320a8cfe0b11d81a4af38fa9985ef0cc9a4c 2021-02-13 19:51:50 to me changes to BPF looks suspicios 2021-02-13 19:51:53 and i dont understand why VM_GROWS* are still a thing 2021-02-13 19:52:17 what is it? 2021-02-13 19:52:24 i will look 2021-02-13 19:53:05 I mean, for what is considered usable = 2021-02-13 19:56:27 I'm in dilemma to upgrade linux-edge because on monday 5.11 will be probably released 2021-02-13 19:57:03 (and I lost a half of day fighting insanity of grub one efi) 2021-02-13 19:57:17 s/one/on/ 2021-02-13 19:57:17 mps meant to say: (and I lost a half of day fighting insanity of grub on efi) 2021-02-13 20:04:28 btw anyone actually *understand* the screen bug? 2021-02-13 20:04:50 i dont understand how the supposed point of crash is reachable with invalid i 2021-02-13 20:06:26 and the patch doesn't look correct 2021-02-13 20:06:33 mps: you didnt notice that GKH add that message to every announcement? "All users of the 5.10 kernel series must upgrade." ? 2021-02-13 20:06:36 it looks like it just breaks combining char support 2021-02-13 20:06:47 (once all slots have been used up) 2021-02-13 20:07:00 MY-R: I'm not blind, still :) 2021-02-13 20:07:30 I wrote above that is his mantra 2021-02-13 20:09:21 i wasn't sure about the patch either 2021-02-13 20:09:26 which is why we haven't applied it 2021-02-13 20:09:33 i'm slightly concerned that nobody from stream upstream did anything 2021-02-13 20:09:39 upstream* 2021-02-13 20:10:48 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/screen/CVE-2021-26937.patch ? 2021-02-13 20:10:48 every bug should have its CVE :) 2021-02-13 20:11:36 CVE-2021-20492291824 2021-02-13 20:12:53 ikke, i see the patch. i'm pretty sure it's wrong 2021-02-13 20:13:28 This was taken from debian 2021-02-13 20:13:37 no i know 2021-02-13 20:13:45 is there a discussion of it anywhere on debian's side? 2021-02-13 20:13:49 also it's still ultimately scary code 2021-02-13 20:13:55 dalias: I think it got replied to on the ML bug thread 2021-02-13 20:13:56 the patch looks like it was written by someone who does not know this code 2021-02-13 20:13:57 let me see 2021-02-13 20:13:59 i knew it like a decade ago 2021-02-13 20:13:59 yes 2021-02-13 20:14:03 give me a mo 2021-02-13 20:14:26 the patch as written just suppresses emitting any further combining chars once all slots have been exhausted 2021-02-13 20:14:34 rather than doing the LRU replacement 2021-02-13 20:14:58 dalias: go from here https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00002.html 2021-02-13 20:15:02 so after a while your screen will stop allowing any combining chars that aren't combinations output in the past to be shown 2021-02-13 20:17:00 uhg nobody in that thread has any idea what they're doing *sigh* 2021-02-13 20:17:35 > + if (c > 0x801) 2021-02-13 20:17:38 return; 2021-02-13 20:17:38 lol 2021-02-13 20:17:49 of course that "fixes" it; it just breaks basically all nonlatin langs 2021-02-13 20:17:59 *sigh* 2021-02-13 20:19:14 this looks more promising: https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00007.html 2021-02-13 20:19:25 comb_tofront is definitely where the root cause of the bug is 2021-02-13 20:20:49 this looks good too: https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00010.html 2021-02-13 20:21:58 lol my screen is immune! 2021-02-13 20:22:07 it's prior to the bug :) 2021-02-13 20:24:19 ok https://lists.gnu.org/archive/html/screen-devel/2021-02/msg00010.html is the right patch to apply 2021-02-13 20:24:34 please update fix with that, since the current patch in alpine just *breaks* multilingual use of screen 2021-02-13 20:42:48 how do I get a proper patch from that? 2021-02-13 20:53:56 not sure, i'll try to follow up in a bit 2021-02-13 20:54:11 I have a patch, but one hunk does not apply 2021-02-13 21:00:02 context whitespace 2021-02-13 21:05:45 dalias: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18238 2021-02-13 21:11:04 dalias: t 2021-02-13 21:11:14 dalias: I was waiting with patching to see that thread work out 2021-02-13 21:57:22 podman checksum failed in the builders but is correct 2021-02-13 21:59:31 fails for me 2021-02-13 22:01:06 just checked again and wfm 2021-02-13 22:01:49 cached distfiles? 2021-02-13 22:02:10 I removed them beforehand 2021-02-13 22:04:54 maxice8: can you compare https://distfiles.alpinelinux.org/distfiles/podman-3.0.0.tar.gz.32279a6a ? 2021-02-13 22:29:53 sup 2021-02-13 22:29:55 testing 2021-02-13 22:29:57 testing 2021-02-13 22:31:20 Ikke: http://ix.io/2PkR 2021-02-13 22:31:30 hello it is I, the guy who tried to set up LVM on LUKS a few weeks ago and was also asking about filesystems. I finally got my wi-fi working in the live environment, turns out it's the Windows Fast Boot thing. Maybe you should put that in the handbook so people know about that bug? That way newbies like myself don't have to spent days wondering why their Wi-Fi won't work 2021-02-13 22:31:37 exit 2021-02-13 23:09:19 hiya, I was looking into build a static libmagic package and I noticed that there's a bunch of libraries that lack static versions even in their dev packages, like libbz2. Why is that? 2021-02-13 23:25:26 xybre: try $package-static 2021-02-13 23:31:08 I'm not seeing that in the documentation? 2021-02-13 23:36:44 if it's the only thing you're not seeing in the documentation, consider yourself happy. ;) 2021-02-13 23:40:23 ahaha 2021-02-13 23:49:25 Okay well I don't see it in the source of that projects I know to grep in either, so how would I go about using such a thing? 2021-02-13 23:50:02 there is a movement going on to delete -static packages 2021-02-13 23:56:05 Really? That seems like an odd choice. I mean, Alpine is the best distro for compiling static binaries. I'd have to build them all by hand. I mean, that is what it's looking like I'll have to do as is. 2021-02-13 23:57:29 fwiw we probably should think about splitting the aports git repo at some point 2021-02-13 23:58:34 but, this will take some time to figure out a solution 2021-02-14 00:01:55 I think having separate repos makes sense enough, so long as it can handle potential name collisions 2021-02-14 00:03:00 Ariadne: splitting aports? what for? what line do you think it needs to be split along? 2021-02-14 00:04:23 skarnet: probably 1 git repo per package 2021-02-14 00:04:35 o.O 2021-02-14 00:04:45 skarnet: aports.git is a very large repo which causes problems with people who have low data caps 2021-02-14 00:05:09 split main/community/testing, but 1 repo per package sounds insane 2021-02-14 00:06:15 I loled but wait you're serious? 2021-02-14 00:09:10 the problem is that splitting main/community/testing won't be enough in the long run 2021-02-14 00:09:47 Per package git repos would be a huge amount of overhead 2021-02-14 00:09:49 so if you do just that, then you have to revisit this again down the line, when *those* repos use GBs of data to clone 2021-02-14 00:10:04 xybre: not really. fedora and debian do it that way already. 2021-02-14 00:10:49 When did Debian transition to using git for package management? 2021-02-14 00:10:55 years ago 2021-02-14 00:11:17 see also: git-buildpackage and friends 2021-02-14 00:11:21 I thought the point of APKBUILDs was that there wasn't much metadata you needed, so the amount per package was super small 2021-02-14 00:11:44 skarnet: yes, but there's over 100k commits and giant patches and so on 2021-02-14 00:11:59 ah so the repo size is mostly in the history 2021-02-14 00:12:01 git clone --depth 50 can help mitigate to an extent 2021-02-14 00:12:25 yeah tbh if it's only history then people can skip it 2021-02-14 00:12:26 but i've heard several people on capped data plans complain about this over the past year 2021-02-14 00:12:39 so would be nice to at least document something 2021-02-14 00:13:22 would it be possible to archive the current repo and make a new one without the history older than a couple versions? 2021-02-14 00:14:04 Yeah shallow clones seems like a better plan. Or else just getting snapshots of the repo without the changes. 2021-02-14 00:23:37 partial clone is a thing now too. seems like gitlab supports it 2021-02-14 01:09:57 last i tried on github it didn't seem to save much downloading though. not sure how hard the server tries to repack stuff for you 2021-02-14 01:16:59 Anyway, I was able to compile everything by hand. It's just a bummer that the static files for bzip2 are missing. 2021-02-14 01:17:04 (and other libs) 2021-02-14 01:48:01 20.6M .git < sabotage, despite having almost 7K commits and ~1200 pkgs :) 2021-02-14 01:48:35 i only made the error to check-in grsecurity patches twice 2021-02-14 01:58:29 aports is 168M with 110k commits and ~7400 APKBUILDs, so sabotage is blot 2021-02-14 02:17:06 main + community ? 2021-02-14 02:36:30 all 2021-02-14 02:37:11 i mean this calculation doesn't work anyways because of pack and delta compression 2021-02-14 02:38:46 i.e. revbumps take negligible space, version bumps take moderate space. if you're purely going for repo size you should use shorter distfile checksums, etc 2021-02-14 03:31:54 I just finished !18242. Please review. Thx! :) 2021-02-14 09:32:53 maxice8: what was the tool again you use to interact with gitlab? 2021-02-14 09:33:57 glab? 2021-02-14 09:35:43 fwiw I recently added `mr = "!sh -c 'git push -o merge_request.create -o merge_request.target=\"${1:-master}\" -o merge_request.remove_source_branch \"${2:-origin}\" $(git branch --show-current)' -"` to my gitconfig as alias, works really nicely for opening MRs 2021-02-14 09:35:59 And it's a fair bit faster than opening the MR via the gitlab API with glab after the fact 2021-02-14 09:36:45 And `glab mr create --fill --yes --push` tended to do weird stuff like trying to push to upstream instead of origin 2021-02-14 09:39:03 ikke: glab 2021-02-14 09:39:18 Cogitri: you picked the wrong head repo 2021-02-14 09:40:15 thanks 2021-02-14 09:40:46 I recommend compiling from source with go 2021-02-14 09:41:27 instead of using the package from edge? 2021-02-14 09:41:34 yes 2021-02-14 09:41:48 any particular reason? 2021-02-14 09:42:11 Release process is 2 weeks and a lot is churned out in terms of fixes and stuff 2021-02-14 09:42:12 just to get the latest version? 2021-02-14 09:42:15 ok 2021-02-14 09:42:30 Cogitri probably had his glab try to push to upstream because there was no head repo implemented yet 2021-02-14 09:43:30 the one currently in edge is at least up-to-date 2021-02-14 09:43:42 It is, one of the devs maintains it 2021-02-14 09:43:47 good 2021-02-14 09:47:49 'glab version 3.13.0-890-g184b92000e (2021-01-28)' 2021-02-14 09:47:58 seems like the version does not get detected properly 2021-02-14 09:48:52 probably uses git commit 2021-02-14 09:49:20 it's not a commit in aports 2021-02-14 09:49:39 oh, it is :) 2021-02-14 09:49:45 missed on character 2021-02-14 09:49:49 GLAB_VERSION ?= $(shell git describe --tags 2>/dev/null || git rev-parse --short HEAD) 2021-02-14 09:49:57 from their makefile 2021-02-14 09:50:02 I think we should set GIT_CEILING_DIRECTORIES in abuild somewhere 2021-02-14 10:16:02 !18252 2021-02-14 10:17:03 !18252 2021-02-14 10:23:40 maxice8: oh, you already fixed it 2021-02-14 10:23:49 yes 2021-02-14 10:24:02 was trivially trivial so just pushed after building and doing `glab --version` locally 2021-02-14 10:24:06 yup 2021-02-14 10:24:11 I did that as well 2021-02-14 10:29:24 I think something like this could be added to abuild: https://tpaste.us/E17e 2021-02-14 10:29:41 That should prevent aports leaking through in packages, and packages affecting aports 2021-02-14 10:36:10 I did something similar for crystal some time ago 2021-02-14 10:41:11 It happens more often 2021-02-14 10:46:14 yes, more and more often. however have no idea could it be solved by abuild 2021-02-14 10:47:23 see the diff that I linked to 2021-02-14 10:48:39 GIT_CEILING_DIRECTORIES basically prevents git from traversing further upwards to find the git repoi 2021-02-14 10:48:50 so it basically looks for packages as if they are not in a git repo at all 2021-02-14 11:41:47 !18238 Ikke, is it good to go ? 2021-02-14 11:42:06 I have a ppc64le CI build that seem to be stuck at the end? https://gitlab.alpinelinux.org/omni/aports/-/jobs/321719 2021-02-14 11:42:14 maxice8: I think so, haven't tested it 2021-02-14 11:42:21 This was on recommendation from dalias 2021-02-14 11:50:41 omni: ppc64le has some network issue from time to time. Uploading artifacts can take a while 2021-02-14 11:50:55 Not a lot we can do about 2021-02-14 11:52:56 ikke: thanks! 2021-02-14 12:55:33 lol.. i am tempted to save hours of leo's time per week by adding new rules and reference APKBUILDs to apkbuild-lint 2021-02-14 13:49:56 Hi folks i see you trying to bootstrap rust on other platforms? 2021-02-14 13:50:07 protonesso: correct 2021-02-14 13:50:15 s390x, mips64 2021-02-14 13:51:11 Have you had issue when rust uses "cc" as it's linker instead of x86_64-linux-musl-something (in my case it's x86_64-linux-musl-clang) 2021-02-14 13:51:31 Ariadne would know the details 2021-02-14 13:52:38 I'm trying to bootstrap rust as well but I'm using clang, I've made patch which forces linkage against libunwind for musl and glibc 2021-02-14 13:52:48 Maybe something wrong with my patches idk 2021-02-14 13:54:49 The last time I cross compiled it when I used gcc 2021-02-14 13:55:26 https://github.com/ataraxialinux/rustie may be useful (use commits before 2021) 2021-02-14 13:59:58 See our Rust APKBUILD for what patches we use 2021-02-14 14:00:13 We use gcc_eh instead of libunwind iirc 2021-02-14 14:04:10 Just setting these https://github.com/void-linux/void-packages/blob/master/srcpkgs/rust/template#L264 worked for me when I did the bootstrap for Void 2021-02-14 18:31:41 ikke: backported your changes to 3.1{3,2,1,0}-stable 2021-02-14 18:31:47 yes, noticed 2021-02-14 19:29:53 maxice8: did you find out the issue with the mismatching checksums? 2021-02-14 19:30:05 on podman ? 2021-02-14 19:30:08 yea 2021-02-14 19:30:10 I posted a link 2021-02-14 19:30:42 one char from a git commit version was changed 2021-02-14 19:30:59 interesting, was it a CDN issue? 2021-02-14 19:31:08 no clue 2021-02-14 20:10:20 fcolista: Hey, what's with license="GPL-2.0-only WITH openssl-exception"? 2021-02-14 20:10:39 That's in ossec-hids-* packages and the linter complains about these license specifiers 2021-02-14 20:11:38 Thermi: It should be valid 2021-02-14 20:11:50 ikke: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/322345 2021-02-14 20:11:53 >>> WARNING: ossec-hids-agent: "openssl-exception" is not a known license 2021-02-14 20:12:07 yea 2021-02-14 20:12:20 Can that be fixed? 2021-02-14 20:12:31 It's something that needs to be fixed in abuild 2021-02-14 20:13:09 Aye, so I can disregard that? 2021-02-14 20:13:37 yea 2021-02-14 20:14:04 OK, ty. 2021-02-14 20:14:25 Hmm 2021-02-14 20:14:36 the spdx-licenses-list only contains openvpn-license-exception 2021-02-14 20:15:13 https://spdx.org/licenses/exceptions-index.html 2021-02-14 20:16:32 https://github.com/spdx/license-list-XML/issues/720 2021-02-14 20:18:45 Thermi: so I guess ignore it for now, is an upstream issue 2021-02-15 06:27:37 ikke: we also need to bring up on riscv64, since riscv64 is hopefully going to be a release architecture for 3.14 2021-02-15 06:28:33 aha, ok 2021-02-15 08:03:45 Ariadne: clang lto doesn't work on riscv64 unfortunately, if that matters 2021-02-15 08:46:57 \o 2021-02-15 08:47:53 will someone with shell scripting knowledge look at setup-disk and fix it for armhf/armv7 to work 2021-02-15 08:48:51 mps: did you create a issue to outline the issues? 2021-02-15 08:49:45 clandmeter: yes, look few lines on this channel backlog :) 2021-02-15 08:51:15 and, I reported that issue here last week, and ncopa agreed that this must be fixed 2021-02-15 08:52:04 mps: i dont see the link, i must be blind. 2021-02-15 08:53:38 clandmeter: I didn't posted link because I didn't created bug/issue report 2021-02-15 08:54:05 I just wrote it (bug report) here 2021-02-15 08:54:25 sorry if I sound ambiguous 2021-02-15 08:56:34 protonesso: we use gcc 2021-02-15 09:04:14 Ariadne: i mean someone would use clang and try to link something with lto and they'll get error... Btw are there any plans on llvm libc++? I've noticed you don't have it 2021-02-15 09:04:33 in repos 2021-02-15 09:43:39 ikke: do we need specify xz explicitly in makedepends now when it is removed from busybox 2021-02-15 09:45:04 morning 2021-02-15 09:45:53 mps: i dont remember what I agreed need to be fixed and if there are no bug/issue then it will almost for sure be forgotten 2021-02-15 09:46:43 I don't think it's an issue for abuild 2021-02-15 09:46:51 and even if i remember that there was an issue, about something, i will likely not be able to remember all the details, so writing it down in the bug tracker is always a good idea 2021-02-15 09:47:44 ikke: linux-edge failed because there is no xz on armv7 builder 2021-02-15 09:48:26 ncopa: np, what I don't remember this is probably is not important 2021-02-15 09:49:22 we need explicitly specify xz in make depends if it is needed 2021-02-15 09:49:35 alternativly patch the package to use unxz 2021-02-15 09:50:03 I thought so, thanks 2021-02-15 10:11:33 ncopa: im looking in adding an option to disable modloop, mainly for netbooting as it makes no sense to have a modloop and only complicates things. 2021-02-15 10:15:31 you mean we should include all the kernel modules and firwmares in initramfs? 2021-02-15 10:15:53 i think we need modloop for netboot as well 2021-02-15 10:16:12 if we use netboot with virt, i dont think we need firmware? 2021-02-15 10:16:30 maybe 2021-02-15 10:17:43 but I don't think we can guarantee that firmware won't be needed 2021-02-15 10:17:48 netboot will fetch the modloop in boot process 2021-02-15 10:18:06 so it could be as well included in the initramfs 2021-02-15 10:18:08 looks so yes, from modloop init script 2021-02-15 10:18:45 it could, but I don't think that belongs in initramfs 2021-02-15 10:18:51 hmm but you cant access it later 2021-02-15 10:19:39 the only thing initramfs is supposed to do is mount the root fs, and swtich_root 2021-02-15 10:19:42 thats it 2021-02-15 10:24:08 I've pushed changed linux-edge-virt for armv7 with all drivers needed to boot it from 'netboot' without needing modloop, but after some tests I think having modloop will not 'hurt' 2021-02-15 10:25:07 some extra FS drivers and maybe some other could be put on modloop, for users convenience 2021-02-15 10:25:11 do we need firmware in modloop for netbooting when using virt kernel? 2021-02-15 10:25:40 not, afaik 2021-02-15 10:26:19 and some apks are not needed for virt install, wpa_s for example 2021-02-15 10:27:09 are there any firmwares at all for the -virt kernel? 2021-02-15 10:27:22 you could lbu add firmware and let it pull in by netboot. 2021-02-15 10:28:28 I can't remember any (with short memory) 2021-02-15 10:29:37 probably we don't need any firmware for -virt flavors 2021-02-15 10:30:39 for alpine-virt on aarch64 there are no firwmare 2021-02-15 10:30:47 i just checked 2021-02-15 10:31:05 i guess you could technically passthru devices in qemu and have a need for firmware? 2021-02-15 10:31:35 yup 2021-02-15 10:31:53 im no kernel expert, but i think there is something called VF drivers nowdays too 2021-02-15 10:32:16 that's true but these are special cases and those who do these things usually knows what and how to do that 2021-02-15 10:32:20 if i understand that correctly is that you can give viortio access to the driver 2021-02-15 10:32:39 vfio 2021-02-15 10:32:44 right 2021-02-15 10:32:59 but i suppose in that case, you need firmware on the host. not in the vm right? 2021-02-15 10:33:36 not sure, maybe you should not load it on the host? 2021-02-15 10:33:43 never used it 2021-02-15 10:34:27 ok, i checked the x86_64 modloop-virt as well 2021-02-15 10:34:31 there is no firwmare there 2021-02-15 10:34:40 I never understood what the point of modloop was when you have an initramfs anyway 2021-02-15 10:34:52 they solve different problems 2021-02-15 10:35:03 what is the problem that modloop is solving? 2021-02-15 10:35:14 on regular media it should boot faster iirc 2021-02-15 10:35:17 modloop is sort of a hack 2021-02-15 10:35:29 also I didn't tested vfio yet, don't have use case for these 2021-02-15 10:35:36 the problem is that kernel with all its modules is huge nowdays 2021-02-15 10:35:38 I guess saving ram on run-from-ran systems? 2021-02-15 10:36:04 yes, modloop cheats when running from tmpfs 2021-02-15 10:36:14 you do know that you can free initramfs ram after booting, right? 2021-02-15 10:36:22 skarnet: not initramfs 2021-02-15 10:36:26 root tmpfs 2021-02-15 10:36:26 instead of extracting the kernel and all the kernel modules to tmpfs, we mount those as a loopback 2021-02-15 10:36:50 ikke: you can also delete stuff from a root tmpfs 2021-02-15 10:37:01 initramfs as a single job: get the root fs mounted and switch root 2021-02-15 10:37:02 thats it 2021-02-15 10:37:06 skarnet: yes, but the idea is to make it available 2021-02-15 10:37:18 to be able to load modules 2021-02-15 10:37:28 initramfs only need the kernel modules for mounting the rootfs 2021-02-15 10:37:40 ... yes and? 2021-02-15 10:37:42 not the kernel modules for the entire system 2021-02-15 10:37:50 ... and? 2021-02-15 10:38:03 so initramfs only needs a subset of the kernel drivers 2021-02-15 10:38:07 the kernel modules for the entire system could be on a *disk* 2021-02-15 10:38:11 like, duh 2021-02-15 10:38:15 exactly 2021-02-15 10:38:34 run-from-ram can run diskless 2021-02-15 10:38:44 so we mount tmpfs, (and make it bootable by installing the packages needed) 2021-02-15 10:38:47 then we witch root 2021-02-15 10:38:54 in a tmpfs system there is no disk 2021-02-15 10:39:08 but we need the kernel modules 2021-02-15 10:39:21 so we find the kernel modules on the boot disk and mount it 2021-02-15 10:39:30 and the way to do that is via a modloop 2021-02-15 10:39:45 > there is no disk 2021-02-15 10:39:52 > find the kernel modules on the boot disk 2021-02-15 10:39:56 usb drive 2021-02-15 10:40:02 thats why i say we cheat 2021-02-15 10:40:13 or dvd 2021-02-15 10:40:43 i think that originally we did have the kernel modules directy on the boot media 2021-02-15 10:40:54 but there was a problem due to limitations in fat 2021-02-15 10:40:54 yeah, what was the problem with that? 2021-02-15 10:41:05 ... lol. 2021-02-15 10:41:13 okay so to summarize 2021-02-15 10:41:19 i think the path got too long or similar 2021-02-15 10:41:27 the hack doesnt really work on netboot, so thats why im trying to work around modlooping. 2021-02-15 10:41:28 so we put them in a cramfs looback device 2021-02-15 10:41:51 and later we moved to squashfs 2021-02-15 10:42:25 tbh i dont remember exactly what the limitation on fat was. it might have been too long file path, or it might have been lack of symlinks or both 2021-02-15 10:42:57 modloop complicates the normal case where you have a disk, is also too complex for the case where you don't because FAT, doesn't work on netboot where it could actually be useful, and doesn't help with virtual machines (as I painfully experienced last week) 2021-02-15 10:42:58 so to avoid limitations of the filesystem of boot media (eg fat boot usbs) we put them in a loopback device 2021-02-15 10:43:09 correct 2021-02-15 10:43:10 sounds like a winner 2021-02-15 10:43:27 normal case where you have disk you dont need modloop and should not use it at all 2021-02-15 10:43:47 there is no point with modloop for the normal disk case 2021-02-15 10:44:10 then I should never, ever, see any modloop message (especially in red with !! errors) in the normal case :P 2021-02-15 10:44:22 correct 2021-02-15 10:44:42 if your root fs is on a disk, then modloop should be disabled 2021-02-15 10:44:56 rc-update del modloop boot 2021-02-15 10:45:48 only time where you need modloop is when your rootfs is tmpfs and you have booted the kernel from some sort of local media 2021-02-15 10:46:06 it still means that on "diskless" you need the boot device plugged in for the whole lifetime of the system 2021-02-15 10:46:21 skarnet: you can choose to unmount modloop and remove it 2021-02-15 10:46:31 only if you need hotplugging of new dvices to work yes 2021-02-15 10:46:50 but you can unmount it and run completely diskless 2021-02-15 10:47:07 but then ofc you wont be able to load any new kernel modules 2021-02-15 10:47:20 which might or might not be what you want 2021-02-15 10:47:25 if you know when you need extra modules and when you don't, then you also know when you can delete all the shit you don't need from your root tmpfs 2021-02-15 10:47:44 correct 2021-02-15 10:48:35 so you could just as well have all the modules in initramfs, moved to root tmpfs, then deleted by the user when they don't need them 2021-02-15 10:48:47 correct 2021-02-15 10:48:58 and the reason we dont do that is 2021-02-15 10:49:30 1) the initramfs would end up huge and would take significantly longer time to load 2021-02-15 10:49:40 fair 2021-02-15 10:50:07 2) the initramfs would now deal with things it is not really supposed to deal with 2021-02-15 10:50:19 the only thin initramfs is supposed to deal iwth is mount the rootfs 2021-02-15 10:50:53 right but rootfs-in-ram is a special case anyway 2021-02-15 10:50:56 3) more ram would needed to boot the system, even if you dont need every available kernel modules 2021-02-15 10:51:20 yeah that's related to 1) and also fair 2021-02-15 10:51:27 by cheating and mounting a disk for the kernel modules, we get ways with less memory usage 2021-02-15 10:51:39 that is the reason we ended up with it as it is 2021-02-15 10:51:49 but yeah, it is a hack 2021-02-15 10:51:57 feels like yet more sleight of hand to save RAM but I get you 2021-02-15 10:52:13 ACTION uses linux-lts for a vm due to passthru needs of firmware 2021-02-15 10:52:16 but thanks for asking those questions 2021-02-15 10:52:42 well thanks for explaining and bearing with my criticism :) 2021-02-15 10:52:55 30 mins ago I was convinced that netboot also needs modloop 2021-02-15 10:53:15 it doesn't but not hurt to have it 2021-02-15 10:53:24 but explaining it made me understand that for netboot, we actually dont need modloop 2021-02-15 10:53:28 someone somewhere told me you could do something like give a kernel argument modloop=https://blah/place 2021-02-15 10:53:35 and *that* would be useful 2021-02-15 10:53:36 and it might actually hurt 2021-02-15 10:53:58 i think you can do that 2021-02-15 10:54:19 modloop=https://path/to/modloop 2021-02-15 10:54:20 being able to load stuff from the net, in initramfs, specifically for net boot, and really need *zero* disk, is cool 2021-02-15 10:54:20 here is script https://tpaste.us/axOm 2021-02-15 10:54:38 well when I tried it it didn't work, but then again, not much of what I tried did work :P 2021-02-15 10:55:13 (I think it's specifically the 3.13 armv7 stuff that is borked) 2021-02-15 10:55:14 mps: does that actually boot? 2021-02-15 10:55:29 yeah, we dont provide any -virt kernel for armv7 2021-02-15 10:55:32 modloop can be removed and it will still boot 2021-02-15 10:55:44 ncopa: that would be a welcome addition :) 2021-02-15 10:55:59 ncopa: yes, tested last night on x86_64 host 2021-02-15 10:56:15 im sorry. correction: we do have -virt kernel for armv7 2021-02-15 10:56:28 but we dont have netboot images for armv7 2021-02-15 10:56:29 ncopa: we have both virt, -lts and -edge 2021-02-15 10:56:50 you do, and you don't have ext4 support in it, ext4 is only in modloop, which is why I tried to get it and raged at it. XD 2021-02-15 10:57:05 sorry about that... 2021-02-15 10:57:08 can !s390x be used with noarch? 2021-02-15 10:57:15 alexy: yes 2021-02-15 10:57:17 I'm working on with great help from clandmeter 2021-02-15 10:57:18 nice 2021-02-15 10:57:28 ext4 in the virt kernel, no matter the arch, would be cool 2021-02-15 10:57:55 (or in the virt initramfs, who cares) 2021-02-15 10:58:09 i thikn we have it as a module because you could in theory run a virtual machine without any ext4 2021-02-15 10:58:09 yes, because that I added ext4 and f2fs 'in-kernel' for this testing 2021-02-15 10:58:23 could use xfs for virtual machines as well 2021-02-15 10:58:29 sure 2021-02-15 10:58:37 or any FS :) 2021-02-15 10:58:44 some prefer btrfs 2021-02-15 10:58:47 thats why its not compiled into the kernel 2021-02-15 10:58:51 some even zfs 2021-02-15 10:58:55 but in case your virtual rootfs is ext4, which is often the case with Linux, it would be nice to have the module in the initramfs :) 2021-02-15 10:59:27 sure. i understand that it would be convenient to have your specific use case compiled into the kernel, but... :) 2021-02-15 11:00:10 then again, why would you need ext4 in initramfs for netboot? 2021-02-15 11:00:36 ah yes, so the specific case of a diskless machine with very little RAM and a boot device that only supports a FAT filesystem is okay, but the specific case of a virtual machine is not, in 2021. I see. 2021-02-15 11:01:42 ncopa: well I wouldn't have tried netboot if there was, like, a vanilla iso for armv7. :P 2021-02-15 11:01:52 or a virt one. 2021-02-15 11:04:03 right 2021-02-15 11:04:48 i thikn that might be good enough reason to provide that for armv7 2021-02-15 11:04:53 skarnet: but like ncopa mentioned, shouldn't netboot boot into a run-from-ram system first? 2021-02-15 11:05:25 ikke: I drop any and every objection if you provide a virt armv7 iso ^^ 2021-02-15 11:06:10 my thinking is that initramfs is *only* for mounting the rootfs, and if you need ex4 there, you have a disk, and then you could boot from the disk instead from the network and do not need netboot 2021-02-15 11:06:36 that was the reasoning, and it seems that reasoning was right, because the real problem is that we dont have armv7 boot iso 2021-02-15 11:07:04 ncopa: yeah, not having fs modules in the initramfs when you don't plan on mounting a real disk is legit 2021-02-15 11:07:44 my next question is: what bootloader should we use for alpine-virt armv7.iso? 2021-02-15 11:08:11 What do we use for aarch64? 2021-02-15 11:09:10 clandmeter: would it make sense for armv7 ci to actually boot an armv7 system, rather than aarch64 with armv7 userspace? 2021-02-15 11:09:34 it's virtual, I don't think the specific bootloader matters - make it as easy as possible 2021-02-15 11:09:41 ikke: that is a good question 2021-02-15 11:16:33 looks like the alpine aarch64 is grub/uefi 2021-02-15 11:19:19 looks like we could do uefi for armv7 too https://fedoraproject.org/wiki/Changes/uEFIforARMv7 2021-02-15 11:19:47 for virtual please keep it simple, stupid 2021-02-15 11:20:30 when I read "EFI", even with a u in front, I'm scared 2021-02-15 11:28:07 Any opinion on https://lists.alpinelinux.org/~alpine/aports/patches/3452 ? Basically packaging a pre-compiled .Net sdk 2021-02-15 11:30:30 gross 2021-02-15 11:33:22 ikke: looks like it depends on manual tracing of dependencies 2021-02-15 11:33:31 yes 2021-02-15 11:33:34 the source url does not look easily maintained either 2021-02-15 11:33:42 so lots of manual work 2021-02-15 11:33:45 nod 2021-02-15 11:34:04 Noy a fan either 2021-02-15 11:34:06 ikke: NAK 2021-02-15 11:34:19 ikke: however if microsoft would like to come work with us to get .NET core into alpine itself, that could be cool 2021-02-15 11:34:33 im not familiar with .net ecosystem. wouldnt it be better to build it from source? 2021-02-15 11:34:39 ncopa: I would say so 2021-02-15 11:34:42 https://github.com/dotnet/source-build/blob/master/Documentation/boostrap-new-os.md 2021-02-15 11:35:03 since its precompiled, does it link to glibc? 2021-02-15 11:35:12 It's a musl version 2021-02-15 11:35:13 no they already bootstrapped it on alpine 2021-02-15 11:35:19 they just don't work directly with us 2021-02-15 11:35:21 which is dumb 2021-02-15 11:35:25 dotnet-sdk-$pkgver-linux-musl-x64.tar.g 2021-02-15 11:36:05 protonesso: there is an aports issue. seems like nobody wants to maintain it 2021-02-15 11:36:07 Trust us, we provide the binaries 2021-02-15 11:36:30 Ariadne: isn't that the same with java? 2021-02-15 11:36:44 oh, its musl binary. interesting 2021-02-15 11:36:45 Hello71: link? 2021-02-15 11:36:47 yes, it would be nice if the Portola people worked directly with us too 2021-02-15 11:37:06 however that is less likely 2021-02-15 11:37:20 because the Portola java builds are under the proprietary Oracle EULA 2021-02-15 11:37:22 :) 2021-02-15 11:37:34 still kinda cool that they provide precompiled binaries for musl 2021-02-15 11:37:38 which obviously we are not going to ship that 2021-02-15 11:38:19 reminds me of my tests with visual studio on linux 2021-02-15 11:38:38 ikke: i lost track how the CI is booted/run 2021-02-15 11:38:48 CI is in qemu? 2021-02-15 11:38:54 however, 2021-02-15 11:39:15 i do have some contacts at MS who can probably assist with getting .NET directly into alpine, as they do with fedora 2021-02-15 11:39:27 vscode has a pretty cool feature to have a backend over ssh, but the plugins they download are precompiled binaries against glibc 2021-02-15 11:39:47 i think it would be cool if i could run vscode on my mac, using alpine backend, and it "just works" 2021-02-15 11:39:50 clandmeter: for aarch64 / armv7 it is 2021-02-15 11:40:00 which woudl require them to redistribute precompield musl binaries 2021-02-15 11:40:03 qemu vm on the builders 2021-02-15 11:40:16 clandmeter: lets move to #-infra 2021-02-15 11:40:47 so i find it interesting that they redist .net sdk precompiled musl binaries 2021-02-15 11:40:49 ncopa: The backend needs electron too afaict 2021-02-15 11:40:57 And electron on musl is a huge pain 2021-02-15 11:41:15 there was something that looked like nodejs yes. might have been electron 2021-02-15 11:41:22 I currently use the VSCode backend thingie in a glibc podman container, works really nicely 2021-02-15 11:41:32 cool 2021-02-15 11:41:42 So would be neat if that worked on Alpine too 2021-02-15 11:41:55 i dropped vscode and use vim instead for now 2021-02-15 11:42:07 ncopa: regarding discussion about removing modloop for netboot, we would build all modules into the kernel? 2021-02-15 11:42:08 but would be cool if we could get it work 2021-02-15 11:42:17 clandmeter: no 2021-02-15 11:42:52 i think the easiest or most convenient way is still the modloop 2021-02-15 11:43:21 netboot is *the* place where downloading an extra set of modules (or whatever data) from the network at boot makes sense 2021-02-15 11:43:23 but technically, what we'd need is modprobe to be able to load modules over network 2021-02-15 11:44:03 download netboot, mount it locally, modprobe what you need, unmount, toss the thing 2021-02-15 11:44:24 s/netboot/modloop/ 2021-02-15 11:44:24 skarnet meant to say: download modloop, mount it locally, modprobe what you need, unmount, toss the thing 2021-02-15 11:44:30 yeah 2021-02-15 11:44:43 i think that is how it currently works 2021-02-15 11:44:49 or how its supposed to work 2021-02-15 11:44:52 well for my use case i dont need modloop, i just want to test if the thing boots 2021-02-15 11:44:59 and make it faster 2021-02-15 11:45:17 i just use qemu thats it 2021-02-15 11:45:30 aha, thats why you wanted option to disable the modloop 2021-02-15 11:45:39 yes 2021-02-15 11:45:46 and i can tell you the use case 2021-02-15 11:45:53 i have a docker image that will build all releases 2021-02-15 11:46:00 with qemu-user 2021-02-15 11:46:05 modloop is the thing which blocking me from update kernel on rpi in diskless mode, I always have to wait for .tar.gz releases to do it :\ 2021-02-15 11:46:22 MY-R: yes, that's a known limitation 2021-02-15 11:46:26 so i could have one script that boots all netboot releases and verifies if it actually boots 2021-02-15 11:47:07 I was wondering maybe would be nice to have some package with modloop and other stuff which provide .tar.gz archive so can use apk update to do it 2021-02-15 11:47:36 MY-R: modloop is signed, afaik only ncopa can create it 2021-02-15 11:47:36 MY-R: i think update-kernel script is supposed to solve that problem 2021-02-15 11:47:38 and because its using qemu, its not super fast. removing modloop would make it faster. 2021-02-15 11:48:01 generating modloop on rpi... need space and taking ages 2021-02-15 11:48:33 ikke: if you generate the release yourself it would use your own keys. 2021-02-15 11:49:37 clandmeter: something like this might work: https://tpaste.us/5Vzj 2021-02-15 11:50:05 which allows you to have boot option modloop=none 2021-02-15 11:50:06 ncopa: nod 2021-02-15 12:06:39 The dotnet source-build project even acknowledges the fact that distros want to build from source 2021-02-15 12:13:42 Is this reasonable? https://tpaste.us/ 2021-02-15 12:14:00 https://tpaste.us/vZqM 2021-02-15 12:16:01 i think we could go softer. soemthing like, we prefer build from source, would that be possible with this package? 2021-02-15 12:16:34 rather than "you break our policy and this is unacceptable" 2021-02-15 12:19:35 What if they say: "No, that's too much work, please accept this"? 2021-02-15 12:27:38 then is the time for "go fuck yourself", but not earlier 2021-02-15 12:28:47 ikke: then we deal with it 2021-02-15 12:28:58 ok 2021-02-15 12:29:31 But that message would leave that option open, while it's not actually there. BUt I understand we do not want to be too harsh 2021-02-15 12:29:53 the thing is that we may have other packages that that are precompiled binaries 2021-02-15 12:30:05 i havent checked that we have actually enforced that policy 2021-02-15 12:30:20 and even then, we may want be able to do exceptions 2021-02-15 12:31:18 so we might end up with, "ok, we understand, lets make do an exception for this due to this and this reasons" 2021-02-15 12:31:54 oh, we do have packages with precompiled binaries 2021-02-15 12:32:02 the rpi bootloader thingy 2021-02-15 12:32:06 linux-firmware( 2021-02-15 12:32:28 "We want to avoid"? 2021-02-15 12:32:29 but those aren't open-source 2021-02-15 12:32:32 yeah 2021-02-15 12:35:55 I was on meeting, but just read backlog. my vote for anything MS is NACK 2021-02-15 12:36:27 I don't think there's a qualitative difference between binary blobs for linux-firmware and binary blobs for MS stuff 2021-02-15 12:36:33 but there's definitely a quantitative difference 2021-02-15 12:36:43 re armv7 boot, I usually use qemu u-boot for booting armv7/armhf VM 2021-02-15 12:37:18 i.e. '-bios u-boot.bin' 2021-02-15 12:38:08 but I downloaded debian uefi pkg for armv7 to test booting qemu, but didn't yet found time for this 2021-02-15 12:39:06 re modloop, I don't think it is much problematic and sometimes it is quite convenient 2021-02-15 13:05:59 ncopa: example of an Alpine opensource package with precompiled binaries: syslinux. The APKBUILD builds the installer, not syslinux itself. A couple of months ago I tried locally to (test a fix a fix for 64bit ext4 /boot) and gave up as couldn't get it to build :-( 2021-02-15 13:08:43 i think syslinux is supposed to be reproducible already though 2021-02-15 13:09:07 although maybe that doesn't matter if nobody can actually do it 2021-02-15 13:12:18 Hello71: there's a code fix regarding being able to boot off 64bit-enabled ext4 filesystems but it requires a rebuild of the syslinux binary - so that's what I was trying to achieve (locally) to test the fix. From looking at the git history for the APKBUILD it seems the binary has never been built in Alpine, the prebuilt binary is used. 2021-02-15 13:13:03 could be 2021-02-15 13:15:20 6.04-pre1 is that last "official" release of syslinux. There are pre2 and pre3 tarballs but they're for "testing". The fix however isn't already in 6.04-pre1 hence why I wanted to test a patch for Alpine - and then I discovered the patch had no effect as the binary wasn't being rebuilt :-( 2021-02-15 13:15:55 minimal: that is (syslinux) not excuse to introduce binaries from MS 2021-02-15 13:16:35 mps: I was replying to ncopa's comment: "the thing is that we may have other packages that that are precompiled binaries" 2021-02-15 13:17:04 yes but in context of MS 2021-02-15 13:17:49 we can construct everything by (nit)picking words from context 2021-02-15 13:19:01 mps: ncopa's comment was not in context of MS, it was in context of any Alpine package with precompiled binaries 2021-02-15 13:19:16 meh 2021-02-15 13:19:32 it is 2021-02-15 13:45:37 ncopa: a couple of fixes for apkbuild-cpan.in in abuild MR !88 2021-02-15 15:33:00 just spent an hour on "undefined reference to `libintl_gettext'", I assume #10825 means it's not fixable? 2021-02-15 15:47:04 alexy: You'll either have to make sure the gettext libintl header isn't used (so musl's is used) or link with -lintl 2021-02-15 15:52:06 alpine has replaced musl's libintl.h with the gnu gettext one so you have to link the gnu gettext library if you use it 2021-02-15 15:52:21 i wish this would get fixed :/ 2021-02-15 15:56:42 Cogitri: ahh 2021-02-15 15:56:52 dalias: thanks 2021-02-15 15:57:49 dalias: We haven't replaced it, we just don't install it by default since we'd get conflicts with gnu gettext otherwise 2021-02-15 15:58:16 I suppose we could just stop using the gettext headers if musl can do all we need now 2021-02-15 15:58:26 i think gnu gettext package should just be dropped 2021-02-15 15:58:38 stuff that insists on gnu gettext ships its own in the source tree anyway 2021-02-15 16:00:15 I think we still need GNU gettext for xgettext, don't we? 2021-02-15 16:01:08 ? 2021-02-15 16:01:42 and envsubst 2021-02-15 16:01:53 Yup 2021-02-15 16:02:19 though we could just ship those utilities 2021-02-15 16:02:36 Yup, that'd also work 2021-02-15 16:05:24 (54/209) Installing gettext-dev (0.21-r0) 2021-02-15 16:05:24 ERROR: gettext-dev-0.21-r0: trying to overwrite usr/include/libintl.h owned by musl-libintl-1.2.2-r1. 2021-02-15 16:05:34 one of the dep insists on installing gettext-dev 2021-02-15 16:06:09 guess this one will take awhile :/ 2021-02-15 16:06:09 Yup, that's the problem we're currently having 2021-02-15 16:06:28 For the time being you could just link against libintl from gettext-dev 2021-02-15 16:12:28 nice, grep -r '\-lintl' shows a lot of patches 2021-02-15 16:12:40 /testing/apparmor/0001-Fix-linking-against-gettext-on-musl-libc.patch 2021-02-15 19:41:42 Does someone with more experience than me feel like giving their opinion on what should be done in !16473? 2021-02-15 19:41:49 (See the unresolved thread) 2021-02-15 19:43:49 Newbyte: regarding the configuration file? 2021-02-15 19:46:54 Yes, precisely 2021-02-15 19:48:45 Newbyte: I don't think there is an easy solution for when you want to rename 2021-02-15 19:49:00 Is it necessary to rename it? 2021-02-15 19:50:11 what file does element-web look for? 2021-02-15 19:51:12 The place where the symlink goes (see line 27) 2021-02-15 19:51:33 right, so you provide a symliunk 2021-02-15 19:51:35 symlink 2021-02-15 19:53:03 Yeah, since it doesn't look for a config in any standard location to my knowledge 2021-02-15 19:54:52 Ah, the symlink is back to the webapp 2021-02-15 19:54:55 that makes sense 2021-02-15 19:55:06 how do you tell gitlab to update a fork of a project to the latest upstream master? I can't find a way to do it, and at fork time the 'mirror' option is greyed out so I can't use it 2021-02-15 19:55:42 context: every time I want to submit a MR I need to fork aports on gitlab, work on the fork, and then create a MR, but having to delete/recreate the whole repo every time is annoying 2021-02-15 19:55:52 why? 2021-02-15 19:56:00 I'd like to just keep skarnet/aports up-to-date with alpine/aports 2021-02-15 19:56:01 Add the alpine/aports repo as a separate remote 2021-02-15 19:56:07 And then fetch it 2021-02-15 19:56:17 Then git reset your new branches to it 2021-02-15 19:56:17 skarnet: there is practically no need to have the target branch in your fork 2021-02-15 19:56:22 (ie, master) 2021-02-15 19:56:28 hm? 2021-02-15 19:56:44 this guide is good: https://www.atlassian.com/git/tutorials/git-forks-and-upstreams 2021-02-15 19:56:47 You fetch the target branch from alpine/aports 2021-02-15 19:56:57 there you create your branch from 2021-02-15 19:57:02 and you push that branch to your fork 2021-02-15 19:57:30 and then I create a MR merging my branch to alpine/aports master? 2021-02-15 19:57:34 iyes 2021-02-15 19:57:48 your forks master would not be involved at all 2021-02-15 19:57:53 makes sense. Kind of a waste to have a useless master in my fork then 2021-02-15 19:57:57 yes 2021-02-15 19:58:33 thanks for the tip, will use it in the future when I'm tired of recreating everything. ;) 2021-02-15 19:59:08 I rarely update the master branch in my fork 2021-02-15 19:59:20 (though I happened to have done that 2 weeks ago) 2021-02-15 19:59:23 I never do, just git branch -u upstream/master 2021-02-15 19:59:35 ye 2021-02-15 20:02:18 yeah but you can actually do it? 2021-02-15 20:02:31 because with the gitlab web UI it certainly seems like I cannot 2021-02-15 20:02:52 cannot do what? 2021-02-15 20:03:06 git pull or git fetch from a fork's upstream 2021-02-15 20:03:22 right, you cannot do that through the interface 2021-02-15 20:03:55 You can fork a repo, then create branches / commits / merge requests, but that's about it 2021-02-15 20:03:58 could the interface be any more useless 2021-02-15 20:04:46 I think they don't bother because most people would work with local repos anyway 2021-02-15 20:05:07 Same with other forges btw 2021-02-15 20:06:02 if I could say "push this branch to my fork then create a MR from this branch on my fork to upstream master and give me an editor to write the MR text" in one command on my local copy, sure 2021-02-15 20:06:16 glab 2021-02-15 20:06:21 or lab 2021-02-15 20:06:53 what is this, where is it documented and what insane language is it written in? 2021-02-15 20:07:10 glab mr create --fill -b master -H kdaudt/aports -l aports:upgrade --allow-collaboration --remove-source-branch --yes 2021-02-15 20:07:19 glab is written in golang 2021-02-15 20:07:30 of course it is 2021-02-15 20:07:37 1https://github.com/profclems/glab 2021-02-15 20:07:51 packaged in alpine? 2021-02-15 20:07:53 yes 2021-02-15 20:07:56 thanks 2021-02-15 20:07:57 apk add glab 2021-02-15 20:07:58 will take a look 2021-02-15 20:09:37 lab is written in go as well 2021-02-15 20:10:09 everything is go 2021-02-15 20:12:25 trying s390x rebootstrap on rust 1.50 2021-02-15 20:27:58 any preferred wording for a MR involving more than one package? (simple abumps) 2021-02-15 20:30:14 skarnet: no, MR title does not matter that much 2021-02-15 20:30:24 As long as it's descriptive 2021-02-15 20:30:24 ok 2021-02-15 20:34:28 there, !18325 2021-02-15 20:35:20 tbfh, the point of this is *mainly* to force a rebuild, so the armv7 binaries stop being broken. :P 2021-02-15 20:36:28 did you manage to find the issue? 2021-02-15 20:37:04 not 100% but everything points to a lack of rebuild after switching to time64 2021-02-15 20:37:29 That's very strange 2021-02-15 20:37:50 which is problematic in my case because I have different codepaths depending on the size of time_t 2021-02-15 20:37:50 Complete new builders were setup which built world from scratch 2021-02-15 20:38:13 well if the new armv7 versions are still broken I'll have to investigate more 2021-02-15 20:38:45 but when I build my software from scratch with gcc and musl-dev on Alpine, it yields working binaries 2021-02-15 20:39:03 whereas the binaries installed by apk exhibit the bug 2021-02-15 21:10:25 I'm considering to remove armhf kernel from linux-edge, I doubt that anyone use it 2021-02-15 21:11:06 afaik it only works on RPi zero 2021-02-15 21:11:17 I know one person who uses that 2021-02-15 21:11:58 oh, really? than removal is no option 2021-02-15 21:12:10 s/than/then/ 2021-02-15 21:12:10 mps meant to say: oh, really? then removal is no option 2021-02-15 21:12:21 but do they use edge? 2021-02-15 21:12:27 linux-edge 2021-02-15 21:12:52 armhf is increasingly a challenge, because upstreams decide to drop armv6 support 2021-02-15 21:13:14 for example qtdeclarative 2021-02-15 21:13:21 yes 2021-02-15 21:13:45 but kernel still works, at least on some SBCs 2021-02-15 21:14:04 as long as rpis exist it would be nice to have kernels for them 2021-02-15 21:14:26 we have linux-rpi still 2021-02-15 21:15:25 hm 2021-02-15 21:15:36 armhf in linux-edge is kernel for rpi zero made from mainline kernel not from branch on github 2021-02-15 21:15:37 I suppose you can't be edgy on an old device 2021-02-15 21:17:03 my intention was to make it for testing mainline kernels on RPis, but looks like no one tested (except me) 2021-02-15 21:17:22 at least no any feedback 2021-02-15 21:21:24 ikke: thanks for the merge! 2021-02-15 22:08:18 heh 2021-02-15 22:51:20 well, i've learned more about rust internals than i ever wanted to know 2021-02-15 22:53:06 may as well do the riscv64 work for libc crate while i'm here 2021-02-15 22:53:19 Oh, got the key to getting it to boostrap nicely now? 2021-02-15 22:59:16 yeah the key is half the shit is missing 2021-02-15 22:59:32 Oof 2021-02-15 22:59:33 ergo add the stuff 2021-02-15 22:59:51 What's missing? Curious since the thing just worked basically when I did it for Void 2021-02-15 23:00:20 nono 2021-02-15 23:00:24 bootstrap works 2021-02-15 23:00:27 s390x is missing 2021-02-15 23:00:37 i might bootstrap mips64 first 2021-02-15 23:00:42 everything is already there for that 2021-02-15 23:01:06 $ rustc --target s390x-alpine-linux-musl -Z unstable-options --print target-spec-json 2021-02-15 23:01:06 error: the option `Z` is only accepted on the nightly compiler 2021-02-15 23:01:07 ok 2021-02-15 23:01:12 this is obnoxious 2021-02-15 23:01:47 guess we switch to "nightly" channel for our package 2021-02-15 23:02:03 or is there a downside to that 2021-02-15 23:02:24 We don't want nightly for our package 2021-02-15 23:02:37 That breaks API every so often and allows unstable stuff 2021-02-15 23:02:51 And FF will so blow up with it, they can't even keep up with stable Rust 2021-02-15 23:03:15 Maybe rust print the JSON from a rustup s390x glibc nightly compiler 2021-02-15 23:03:27 And manually change it, it's not that much effort 2021-02-15 23:03:37 That's how I did it for the other arches as well 2021-02-15 23:03:59 Getting nightly to build is another level of painful, even upstream only gets it to build every other day on most arches 2021-02-15 23:04:19 coooooooool 2021-02-15 23:04:20 ok 2021-02-15 23:04:29 plan B: we patch out that stupid -Z check 2021-02-15 23:04:48 i like when tools do what i tell them to do, instead of treating me like i'm stupid 2021-02-15 23:05:14 so one way or another, rustc in alpine is getting an attitude adjustment 2021-02-15 23:05:44 I think its unstable for a reason 2021-02-15 23:06:37 As in it's subject to change at any time 2021-02-15 23:07:56 apparently env RUSTC_BOOTSTRAP=1 gives it the attitude adjustment i want 2021-02-15 23:08:06 so we can just document that 2021-02-15 23:08:12 Ah neat 2021-02-15 23:24:00 oh? something new with rust? 2021-02-15 23:24:50 look if i want to chop a finger off with a bandsaw that's my business 2021-02-15 23:25:31 just the smug attitude of rustc there is highly frustrating 2021-02-16 00:58:39 /usr/lib/gcc/mips64-alpine-linux-musl/10.2.1/../../../../mips64-alpine-linux-musl/bin/ld: cannot find libstdc++.so.6.0.28 2021-02-16 00:58:43 who fucking split libstdc++ 2021-02-16 00:59:20 wait what 2021-02-16 01:01:26 oh 2021-02-16 01:01:27 my bad 2021-02-16 01:01:31 i had a stale sysroot for mips64 2021-02-16 02:22:33 Well folks, I'm the bearer of bad news 2021-02-16 02:22:40 https://skarnet.org/tmp/alpine-skalibs.txt 2021-02-16 02:22:57 proof that there's something wrong with the Alpine armv7 builder 2021-02-16 02:23:27 I now leave it to your sagacious minds and am going to sleep. 2021-02-16 03:03:20 skarnet: did you build with -Os? 2021-02-16 03:04:09 hmm, actually 2021-02-16 03:04:15 this is stranger than that 2021-02-16 03:04:38 in other news, i am about to kick rust build off on mips64 2021-02-16 03:04:48 so that just leaves us with s390x and riscv64 2021-02-16 03:05:12 the skalibs package was miscompiled 2021-02-16 03:05:55 either poll.h was not included in the file that calls ppoll, or it was included but _GNU_SOURCE was not defined 2021-02-16 03:06:05 and there was a warning about implicit function declaration 2021-02-16 03:06:07 and it was ignored 2021-02-16 03:06:25 error[E0609]: no field `cpu_features` on type `TargetOptions` 2021-02-16 03:06:27 ACTION sobs 2021-02-16 03:06:32 its features not cpu_features :( 2021-02-16 03:06:44 ? 2021-02-16 03:07:03 rust bootstrap 2021-02-16 03:07:07 i'm doing mips64 2021-02-16 03:07:12 but mips64 is softfloat 2021-02-16 03:07:16 ah 2021-02-16 03:07:35 btw it took me 30 seconds to find this error after downloading the armv7 apk file 2021-02-16 03:07:41 because octeon1 FPU is... well 2021-02-16 03:07:41 what is a nice way of saying broken 2021-02-16 03:07:45 :) 2021-02-16 03:08:11 i am thinking about doing a mips64hf port 2021-02-16 03:08:17 which assumes octeon2 or newer 2021-02-16 03:08:24 or i guess, the SGI chips would also work 2021-02-16 03:08:29 i am sure they have FPUs that work 2021-02-16 03:11:08 what is broken on the octeon1 fpu ? 2021-02-16 03:12:09 it does not exist 2021-02-16 03:12:19 or, i should clarify 2021-02-16 03:12:26 many instructions are unimplemented 2021-02-16 03:12:31 because 'licensing fees' 2021-02-16 03:12:36 octeon2 and later have a fpu 2021-02-16 03:14:07 .. 2021-02-16 03:14:35 i dont understand the skalibs build system enough to know where the _GNU_SOURCE is missing 2021-02-16 03:15:05 hells yeah 2021-02-16 03:15:22 building the mips64-alpine-linux-musl rustc 2021-02-16 03:15:35 dalias: unfortunately a lot of mips boards use octeon1 cpus 2021-02-16 03:15:36 tryppoll.c properly defines _GNU_SOURCE 2021-02-16 03:16:07 but libstddjb/iopause_ppoll.c doesn't seem to get it defined from anywhere 2021-02-16 03:16:23 i think -Werror=implicit-function-declaration should be added to the CFLAGS to avoid this 2021-02-16 03:16:33 it would error out at build time and show where the problem is 2021-02-16 03:17:25 unfortunately s390x and riscv64 need actual bringup 2021-02-16 03:17:35 hmm skalibs/nonposix.h is supposed to define it... 2021-02-16 03:22:50 ok when i build skalibs myself i get the right thing too 2021-02-16 03:26:26 i'm still amazed that rust utterly murders a dual AMD EPYC 7742P 2021-02-16 03:27:17 i feel like this is nearly as bad as mining bitcoins 2021-02-16 03:27:22 :-p 2021-02-16 03:27:33 how do we go about figuring out how builders are botching the armv7 package? 2021-02-16 03:27:42 i downloaded the apk and confirmed it was miscompiled 2021-02-16 03:27:46 but i cant see how it would happen 2021-02-16 03:28:24 is it possible alpine build system is putting "-include something.h" in CFLAGS ? 2021-02-16 03:32:48 not likely 2021-02-16 03:33:10 one option would be to build the apk yourself on an armv7 host 2021-02-16 03:33:20 there is also a build log 2021-02-16 03:33:42 where is it? 2021-02-16 03:33:57 https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/skalibs/skalibs-2.10.0.2-r0.log 2021-02-16 03:34:59 hmm it has -Werror=implicit-function-declaration already 2021-02-16 03:35:08 so how did it get wrong ppoll...? 2021-02-16 03:44:42 this is really weird. i wonder if there's like a corrupt header file or something 2021-02-16 09:37:42 Ariadne, dalias: no I don't build with -Os, just -O2 and it's the same in both cases, unless abuild sets weird CFLAGS (which is my current hypothesis). Also nonposix.h defines _GNU_SOURCE which declares ppoll in iopause_ppoll.c, and iopause is aliased to iopause_ppoll in https://github.com/skarnet/skalibs/blob/master/src/libstddjb/iopause.c 2021-02-16 09:38:27 it's definitely an issue either with files on the builder, or the environment abuild gives 2021-02-16 09:40:09 configure under abuild has correctly detected ppoll() so it's really using iopause_ppoll() (and there is no other way ppoll() could have been called) 2021-02-16 09:42:03 another hyupothesis is that ppoll() is doing the right thing but the conversion of TAIA_INFINITE to a struct timespec is not 2021-02-16 10:58:50 skarnet: is there anything I should check on the builder? CFLAGS="-Os -fomit-frame-pointer", so nothing special 2021-02-16 11:12:26 what about LDFLAGS? 2021-02-16 11:15:29 (just tested a local build with -Os, it works, so it's not -Os) 2021-02-16 11:19:35 going to do more tests to see whether tai arithmetic is correct in the Alpine version 2021-02-16 11:22:52 LDFLAGS="-Wl,--as-needed" 2021-02-16 11:40:42 Hi, I did some work on !1825 and I'd like some feedback if it's alright so far 2021-02-16 11:40:45 Errr 2021-02-16 11:40:52 !18285 2021-02-16 11:42:02 fcolista: Hey, in the ossec-hids* packages, you're using some env parameters that don't seem to be picked up at build time. Are they still relevant? It seems to me they're only used by install.sh which isn't called in any of the APKBUILDs 2021-02-16 11:51:10 ikke: a local build also works with -Wl,--as-needed in the LDFLAGS, so that's not it. It's definitely something on the builder. I'll be able to pinpoint where the problem happens later today. 2021-02-16 11:58:56 looks like build-edge-aarch64 2021-02-16 11:58:59 testing/signal-cli 0.8.0-r0 2021-02-16 11:59:06 uhm 2021-02-16 11:59:28 looks like build-edge-aarch64 is stuck by testing/signal-cli 2021-02-16 12:01:43 seems like a dead-lock 2021-02-16 12:04:03 heh, 'Starting a Gradle Daemon (subsequent builds will be faster)' :) 2021-02-16 12:04:21 or be stalled forever 2021-02-16 12:04:40 yes :). btw is the signal free software? 2021-02-16 12:05:44 https://github.com/signalapp 2021-02-16 12:06:20 Licensed under the GPLv3 for clients and AGPLv3 for the server 2021-02-16 12:07:35 yes, but restrictions about crypto software? 2021-02-16 12:07:54 i.e. restriction by countries 2021-02-16 12:08:33 I think it's no more than that, a notice 2021-02-16 12:08:56 It does not say you are not allowed to use it 2021-02-16 12:09:54 lawyers language is not used to be clear and understandable 2021-02-16 12:10:14 till they call you to judge :) 2021-02-16 12:11:37 but thanks for url, now I'm assured to not touch it, as I had vague idea about that earlier 2021-02-16 14:35:30 another hyupothesis is that ppoll() is doing the right thing but the conversion of TAIA_INFINITE to a struct timespec is not 2021-02-16 14:35:45 no, i have verified that it was miscompiled. it's not a behavioral issue 2021-02-16 14:35:59 it actually linked the time32 ppoll symbol not __ppoll_time64 2021-02-16 14:36:22 so either the builder has wrong/corrupted headers or it's doing something wacky with cflags 2021-02-16 14:37:12 dalias: but you said the ppoll() function only called the ppoll_time64() syscall when given a number that doesn't fit in 32 bits 2021-02-16 14:37:25 you mean syscall not function 2021-02-16 14:37:32 this is the wrong *function* called 2021-02-16 14:37:41 so if the conversion to a timespec is wrong and gives something that fits in 32 bits, couldn't that explain the results? 2021-02-16 14:37:45 no 2021-02-16 14:37:58 you can visibly see the error just with objdump 2021-02-16 14:38:02 no need to examine behavior 2021-02-16 14:39:35 http://ix.io/2PCB 2021-02-16 14:39:48 objdump -T shows undefined ppoll, is that wrong? 2021-02-16 14:40:01 yes 2021-02-16 14:40:03 13a7a: f7f9 e8f2 blx cc60 2021-02-16 14:40:05 is wrong 2021-02-16 14:40:38 it should unconditionally be __ppoll_time64 ? 2021-02-16 14:40:41 yes 2021-02-16 14:40:56 the ppoll symbol is a legacy compat wrapper for time32 apps 2021-02-16 14:41:06 I see 2021-02-16 14:41:44 well ikke said the CFLAGS were just -Os -fomit-frame-pointer and I checked that they work locally 2021-02-16 14:41:58 yeah and there's -Werror=implicit-function-declaration 2021-02-16 14:42:03 so it can't be missing _GNU_SOURCE 2021-02-16 14:42:21 according to https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/skalibs/skalibs-2.10.0.2-r0.log 2021-02-16 14:42:23 no, _GNU_SOURCE is unconditionally defined for ppoll :) 2021-02-16 14:42:55 so do they have like a corrupted poll.h on the builder or something? 2021-02-16 14:43:40 I have no idea, I suspect the quickest course of action would be to pyrolyze the builder and rebuild it from scratch :P 2021-02-16 14:44:41 but somehow I'm relieved that an error that was so hard to track down is neither in my code nor in musl ^^ 2021-02-16 14:45:47 who is responsible for the builder and able to check it out? 2021-02-16 14:46:54 not sure but ikke gave me access to an armv7 container somewhere so he must know :) 2021-02-16 14:48:52 I can check later today 2021-02-16 14:49:21 thanks. 2021-02-16 14:50:23 check if it's reproducible if you just rebuild the package 2021-02-16 14:50:38 i wonder if it was just erroneously built concurrently with a musl-dev update or something 2021-02-16 14:50:43 and used a mixed of headers 2021-02-16 14:51:42 the error occurred with skalibs-2.10.0.1 and I precisely pushed 2.10.0.2 yesterday to force a rebuild and see what happened 2021-02-16 14:52:09 I was hoping the rebuild would fix it, but it didn't 2021-02-16 14:59:27 hmm 2021-02-16 14:59:31 really weird 2021-02-16 14:59:42 i guess it could be a buggy gcc version or something 2021-02-16 15:05:25 sure, if the gcc version on the builder is not the same as the one from edge in my test container 2021-02-16 15:44:32 skarnet: gcc (Alpine 10.2.1_pre1) 10.2.1 20201203 2021-02-16 15:44:54 and apk audit --system yields not results 2021-02-16 15:46:35 same one as in the container then 2021-02-16 15:46:49 skarnet: we do run our armv7 containers on aarch64 kernels 2021-02-16 15:47:03 but i think thats the same as the container we gave you 2021-02-16 15:47:10 it is. 2021-02-16 15:47:12 Linux build-edge-armv7 5.4.34-0-lts #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC armv8l Linux 2021-02-16 15:47:49 some build scripts do strange things when it finds armv8l 2021-02-16 15:47:56 Linux skarnet-edge-armv7 5.4.34-0-lts #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC aarch64 Linux 2021-02-16 15:48:06 so, aarch64 vs armv8l 2021-02-16 15:48:16 shut up, algitbot 2021-02-16 15:48:37 armv8l, aarch64 in 32bit mode 2021-02-16 15:48:49 /ignore algitbot 2021-02-16 15:48:53 what kind of strange things? armv8l (builder) vs aarch64 (working container) is the most prominent difference 2021-02-16 15:49:16 in 32bit mode? that could explain why it links time64 musl wrong 2021-02-16 15:49:31 ive run into projects that use uname to identify the machine 2021-02-16 15:49:51 also I 'meet' this few times 2021-02-16 15:49:58 well it's not linking that's wrong. it's the compiling that's wrong 2021-02-16 15:50:11 and this should not depend on uname or anything 2021-02-16 15:50:39 the wrong headers should not even be present on the system (or in the chroot or whatever) 2021-02-16 15:50:39 yes, but some 'smart' build files likes to use uname 2021-02-16 15:50:46 im sure it doesnt, just pointing out what i have experienced before with this setup. 2021-02-16 15:50:59 yes but still it has nowhere to get a wrong poll.h or wrong bits/alltypes.h 2021-02-16 15:53:12 dalias: does __REDIR(x,y) means that instances of symbol x should be replaced with y? 2021-02-16 15:53:34 (the definition has an asm in it, I have no idea what it's supposed to do) 2021-02-16 15:55:06 i checked for corrupt system files but there are non, but that does not mean there could be lingering files from packages that failed to install/uninstall. 2021-02-16 15:55:21 is there something specific i should look for? 2021-02-16 15:56:21 skarnet, it means that the C identifier x is backed by the symbol "y" rather than "x" 2021-02-16 15:56:45 dalias: yeah, thanks. 2021-02-16 15:56:54 clandmeter, i'm not sure. is there a way to pause the build of the package and strace the gcc invocation for that file? 2021-02-16 15:57:01 see if it's finding a bad header from somewhere 2021-02-16 15:57:57 what do you mean pause the build of package? 2021-02-16 15:58:26 a minimal example could be made: #define _GNU_SOURCE #include int main (void) { ppoll(0, 0, 0, 0); return 0; } 2021-02-16 15:58:30 compile it 2021-02-16 15:58:37 check what symbol it uses 2021-02-16 15:58:41 well like manually build the package on the builder, and do something like rm iopause_ppoll.lo and strace make iopause_ppoll.lo 2021-02-16 15:58:45 with the right paths 2021-02-16 15:58:54 skarnet, yeah that could be done too 2021-02-16 15:58:58 on the builder 2021-02-16 16:00:12 my lxc is 'Linux mps-edge-armv7 5.4.34-0-lts #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC armv8l Linux' 2021-02-16 16:01:22 it is host where builder run 2021-02-16 16:01:52 I think the minimal example should be tried first, to see if the compiler is just broken or if something in the skalibs build procedure sets it off 2021-02-16 16:02:19 yeah 2021-02-16 16:02:24 i agree with skarnet here 2021-02-16 16:02:35 it's a cheap test to set up and would be very informative 2021-02-16 16:03:20 dalias: give me a source file to test 2021-02-16 16:03:28 skarnet just did :) 2021-02-16 16:03:33 mps: that does not make a diff 2021-02-16 16:03:42 skarnet already has a container like you have 2021-02-16 16:03:45 compile that and look at objdump -dr of output 2021-02-16 16:03:59 it should reference __ppoll_time64 not poll 2021-02-16 16:04:08 clandmeter: isn't his aarch64 instead of armv8l 2021-02-16 16:04:18 mine is aarch64 indeed 2021-02-16 16:05:09 ok, what should be rebuilt 2021-02-16 16:05:30 mps: #define _GNU_SOURCE #include int main (void) { ppoll(0, 0, 0, 0); return 0; } 2021-02-16 16:05:53 on the aarch64/armv7 container objdump -dr correctly shows __ppoll_time64 2021-02-16 16:06:07 ah 2021-02-16 16:06:10 now i see it 2021-02-16 16:06:25 i think ikke didnt corerctly setup your container 2021-02-16 16:06:45 my container yields *correct results* 2021-02-16 16:07:03 warning: implicit declaration of function 'ppoll' [-Wimplicit-function-declaration] 2021-02-16 16:07:07 skarnet: your container does not run in 32bit mode 2021-02-16 16:07:12 as it says armv8l 2021-02-16 16:07:13 err 2021-02-16 16:07:16 aarch64 2021-02-16 16:07:20 and it should say armv8l 2021-02-16 16:07:29 mps, you didnt omit the #define ? 2021-02-16 16:07:32 ~/tmp # uname -a 2021-02-16 16:07:32 Linux skarnet-edge-armv7 5.4.34-0-lts #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC aarch64 Linux 2021-02-16 16:07:39 skarnet: what does apk --print-arch return? 2021-02-16 16:07:43 dalias: no, I didn't 2021-02-16 16:07:48 mps, can you show the exact test program? 2021-02-16 16:08:00 apk --print-arch says armv7 2021-02-16 16:08:01 and maybe output of strace -f gcc ... 2021-02-16 16:08:16 i wonder if the builder has a bad poll.h installed somewhere in include path 2021-02-16 16:08:19 dalias: https://tpaste.us/prpx 2021-02-16 16:08:31 dalias i have .a.out 2021-02-16 16:08:33 what should i do? 2021-02-16 16:08:41 and the gcc target is armv7-alpine-linux-musleabihf 2021-02-16 16:08:41 mps, #include needs to be on a new line 2021-02-16 16:08:52 otherwise it's part of the macro definition and unused 2021-02-16 16:09:09 yeah I used spaces instead of newlines, easier on irc :P 2021-02-16 16:09:41 https://tpaste.us/W7b0 2021-02-16 16:09:45 is this what you need? 2021-02-16 16:09:46 oh, crap, yes 2021-02-16 16:09:52 now it builds 2021-02-16 16:10:20 ACTION told self, don't hurry 2021-02-16 16:10:25 skarnet, dalias ? 2021-02-16 16:10:30 clandmeter: thanks. it shows __ppoll_time64. was that the minimal example? 2021-02-16 16:10:40 yes 2021-02-16 16:10:53 on the builder 2021-02-16 16:10:54 built on the builder box? 2021-02-16 16:10:55 ok 2021-02-16 16:10:56 hmm 2021-02-16 16:11:02 and what does objdump -T /lib/libskarnet.so | grep ppoll show? 2021-02-16 16:11:28 what should be installed? 2021-02-16 16:11:30 in my case: 4f0: f7ff ef44 blx 37c <__ppoll_time64@plt> 2021-02-16 16:11:33 skalibs 2021-02-16 16:11:45 mps, is that from the test program? 2021-02-16 16:11:46 no, short example you posted 2021-02-16 16:11:54 dalias: yes 2021-02-16 16:12:00 yeah test program seems to be working 2021-02-16 16:12:12 darn, so there's something in the skalibs build that makes it go wrong 2021-02-16 16:12:14 objdump -dr sk | grep poll 2021-02-16 16:12:18 but the apk i downloaded for skalibs has: 2021-02-16 16:12:18 13a7a: f7f9 e8f2 blx cc60 2021-02-16 16:12:27 ikke: i stopped the armv7 for now 2021-02-16 16:12:39 just the listener 2021-02-16 16:12:55 Nod 2021-02-16 16:13:37 does the test program break if you add to command line: -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 2021-02-16 16:13:45 (shouldn't but just checking) 2021-02-16 16:13:53 (since skalibs has that) 2021-02-16 16:14:22 https://tpaste.us/g6Qy 2021-02-16 16:14:37 objdump -T /lib/libskarnet.so.2.10.0.2 | grep ppoll |tpaste 2021-02-16 16:14:47 dalias: those are undef'd by nonposix.h anyway 2021-02-16 16:15:16 clandmeter: wait what 2021-02-16 16:15:32 that's the broken lib from the apk file 2021-02-16 16:15:36 oh 2021-02-16 16:16:08 i have no idea what im doing, so spoonfed me :) 2021-02-16 16:16:41 try building the test program again with those 2021-02-16 16:16:52 skarnet, no other std headers have been included before the #undefs, have they? 2021-02-16 16:17:16 i dont think it would break here, but it could and it's invalid to undef them after any std headers were included 2021-02-16 16:17:17 dalias: it builds 2021-02-16 16:17:21 you need some output? 2021-02-16 16:17:26 yeah the symbols 2021-02-16 16:17:32 dalias: correct, the #undef are first 2021-02-16 16:17:33 or objdump -dr 2021-02-16 16:17:48 skarnet, that agrees with what i'm seeing too.. 2021-02-16 16:17:53 https://tpaste.us/ej5p 2021-02-16 16:18:08 clandmeter, ok it didnt break 2021-02-16 16:18:44 nonposix.h also adds a lot of shit, let me summarize 2021-02-16 16:18:55 :) 2021-02-16 16:18:57 that shouldn't impact musl but who knows 2021-02-16 16:19:34 ohhh is __linux__ maybe not defined on the builder's gcc for some reason? 2021-02-16 16:19:47 but then.. if _GNU_SOURCE were missing you should be missing the declaration entirely 2021-02-16 16:19:53 and get implicit function declaration error 2021-02-16 16:19:56 ikke: if you check the lxc config for skarnet container, i think it will mention aarch64 or linux64 2021-02-16 16:20:15 _XPG4_2, _XPG6, __EXTENSIONS__, _GNU_SOURCE, _BSD_SOURCE, _NETBSD_SOURCE, _INCOMPLETE_XOPEN_C063 (don't ask), and sys/types.h just because 2021-02-16 16:20:36 could any of those macros impact the definitions in poll.h ? 2021-02-16 16:20:43 they shouldnt 2021-02-16 16:20:59 ikke: it will run the container in 64bit mode but with 32bit userland. 2021-02-16 16:21:16 _GNU_SOURCE and _REDIR_TIME64 are the only relevant macros 2021-02-16 16:21:26 _REDIR_TIME64 is defined unconditionally by bits/alltypes.h 2021-02-16 16:21:33 ikke: setting it to linux32 will switch to 32bit mode. 2021-02-16 16:21:38 and.... 2021-02-16 16:22:13 it looks like bits/alltypes.h isn't included (!!) 2021-02-16 16:22:19 but why does it work here? 2021-02-16 16:22:20 o.O 2021-02-16 16:22:53 what sequence of headers fails to include bits/alltypes.h ? 2021-02-16 16:23:49 sys/types.h is the first header included by the C file (because it's unconditionally included by nonposix.h which is first) 2021-02-16 16:24:20 sys/types.h includes it tho 2021-02-16 16:24:27 i mean poll.h itself doesn't seem to 2021-02-16 16:24:33 but you're including sys/types.h which should 2021-02-16 16:24:41 so maybe there's a broken sys/types.h on the builder ? 2021-02-16 16:24:55 but also... why did the test program work with just ? 2021-02-16 16:24:56 i dont think thats possible 2021-02-16 16:25:08 this is really weird.. 2021-02-16 16:25:10 apk audit --system should detect that 2021-02-16 16:25:30 well it could be in /usr/local or something 2021-02-16 16:25:41 interposing rather than replacing the real header 2021-02-16 16:26:07 let me search system for types.h 2021-02-16 16:26:33 http://git.musl-libc.org/cgit/musl/tree/include/poll.h#n43 includes bits/alltypes.h 2021-02-16 16:27:20 after sys/types.h comes errno.h, then time.h, then poll.h 2021-02-16 16:27:22 /usr/include/c++/10.2.1/parallel/types.h 2021-02-16 16:27:22 /usr/include/sys/types.h 2021-02-16 16:27:32 those are the only types.h 2021-02-16 16:27:52 if gcc manages to include the C++ one it deserves an award 2021-02-16 16:28:06 never mind i'm being dumb 2021-02-16 16:28:07 well there are a lot build leftovers in aports 2021-02-16 16:28:11 alltypes.h is not at the top of poll.h 2021-02-16 16:28:15 it's conditional on _GNU_SOURCE 2021-02-16 16:28:19 so it should be fine 2021-02-16 16:28:38 line 43 2021-02-16 16:28:52 and semantically there's no way to miss bits/alltypes.h 2021-02-16 16:29:04 because only functions which depend on libc time types can have a time64 version 2021-02-16 16:29:11 and to get those you need alltypes.h 2021-02-16 16:29:18 https://tpaste.us/kkD7 those are poll.h 2021-02-16 16:29:25 preparing another test for clandmeter 2021-02-16 16:29:34 oooh 2021-02-16 16:29:40 could the fortify header be breaking something? 2021-02-16 16:29:41 i bet so 2021-02-16 16:29:50 thats what i wanted to show you :) 2021-02-16 16:29:59 fortify involvment 2021-02-16 16:30:04 aaaaah 2021-02-16 16:30:15 where does that come from? 2021-02-16 16:30:17 but that should be on your box too 2021-02-16 16:30:34 but it's a nop if _FORTIFY_SOURCE is not defined 2021-02-16 16:30:42 no /usr/include/fortify on my box 2021-02-16 16:30:52 on alpine 2021-02-16 16:31:06 box as in the container 2021-02-16 16:31:19 what would include /usr/include/fortify/poll.h anyway? 2021-02-16 16:31:27 skarnet, alpine's build system 2021-02-16 16:31:38 that puts -D_FORTIFY_SOURCE -I/usr/include/fortify on everything 2021-02-16 16:31:39 clandmeter: yes, my armv7 container doesn't have /usr/include/fortify 2021-02-16 16:31:51 skarnet: its pulled in by buildbase 2021-02-16 16:31:56 build-base 2021-02-16 16:32:08 ah, I just installed gcc and make, not build-base 2021-02-16 16:32:19 there could be other fortify breakage too 2021-02-16 16:32:21 give it a try 2021-02-16 16:32:27 ikke: you told me there were no other CFLAGS than -Os and -fomit-frame-pointer 2021-02-16 16:33:36 __orig_ppoll gets mapped to "ppoll" symbol name regardless of the actual libc headers mapping 2021-02-16 16:34:03 skarnet, oops :-p 2021-02-16 16:34:45 skarnet: the flags are set by abuild.conf 2021-02-16 16:34:56 so.. 2021-02-16 16:34:58 and i think they are default 2021-02-16 16:35:09 the easiest solution would just be dropping ppoll from fortify 2021-02-16 16:35:29 s/ppoll from// 2021-02-16 16:35:50 i wonder why it was even put there to begin with. there's much lower hanging fruit and calling ppoll with wrong nfds is really unlikely 2021-02-16 16:36:09 ppoll is the only function using time types (or any complex types) in the fortify headers 2021-02-16 16:36:23 dalias: why oops? 2021-02-16 16:36:32 i meant ikke made an oops :) 2021-02-16 16:36:52 there are hidden CFLAGS and it's not even clear how they get passed 2021-02-16 16:37:02 ah yes 2021-02-16 16:37:24 but yes fortify is breaking any call to ppoll on 32-bit archs 2021-02-16 16:37:37 i think it should just be patched not to do anything with ppoll 2021-02-16 16:37:51 s/with ppoll// 2021-02-16 16:38:22 git.2f30.org cert is expired :-p 2021-02-16 16:38:24 if there is ONE THING I hate with things that are supposed to be "hardening" and "security" 2021-02-16 16:38:41 it is when they FUCKING BREAK THINGS AND WASTE EVERYONE'S TIME 2021-02-16 16:38:57 well there's nothing else in it that can break like this. ppoll is the only one. 2021-02-16 16:38:58 just kill that shit with fire, forever 2021-02-16 16:39:07 yeah and it had to fall on me 2021-02-16 16:39:10 :( 2021-02-16 16:39:24 because I'm the only one who actually finds ppoll useful or something 2021-02-16 16:40:07 I'm very tempted to just forcefully add #undef _FORTIFY_SOURCE to skalibs 2021-02-16 16:40:07 well yeah... because it's really not :-p 2021-02-16 16:40:59 I don't like millisecond granularity when I can do better, sorry :P 2021-02-16 16:41:07 skarnet: CFLAGS I was aware of (defined in /etc/abuild.conf) 2021-02-16 16:41:16 I would not know where other CFLAGS would come from 2021-02-16 16:41:43 please don't. (1) it actually catches and blocks a large number of real-world vulns. it's a hard trap-on-some-UB, not sloppy 'hardening' like anti-ROP. (2) it'll make for a lot more wasted time when distros find you've done it and start complaining and it makes the front page of HN :-p 2021-02-16 16:42:13 I welcome the HN hate, I'm ready to explain exactly why I did it 2021-02-16 16:42:22 it's not as if HN were valuable anyway 2021-02-16 16:42:29 oh HN is awful 2021-02-16 16:42:37 i just mean it will attract a huge flamewar 2021-02-16 16:42:46 yeah and it will be justified and I will win it 2021-02-16 16:43:09 nobody wins those things. it's a negative sum game 2021-02-16 16:43:25 ncopa: can you take a look at the above here ^? 2021-02-16 16:43:33 you cannot possibly imagine how much hate I have for that kind of shit that is supposed to help and that FUCKS THINGS UP 2021-02-16 16:43:55 this is the kind of thing that makes me want to destroy the world 2021-02-16 16:44:04 you're justified in being mad that it broke. users are justified in being mad at exposure they didnt expect. there's no objective "who's right" here 2021-02-16 16:46:09 there are s6 users on armv7 containers that are having problems and I don't think they would mind exposure to fucking wrong nfds in ppoll if it could make it work 2021-02-16 16:46:09 I know you're right, I'm not being rational, but I'm fucking furious 2021-02-16 16:46:18 anyway, what's the solution here? 2021-02-16 16:47:47 I'd provide a patch to fortify-headers but I have no idea what needs to go in there for scalpel fixing 2021-02-16 16:48:14 I'm more inclined to do axe-fixing but I'm not sure Alpine folks would like it 2021-02-16 16:48:38 Where does that include come from in the first place? 2021-02-16 16:48:45 fortify-headers 2021-02-16 16:49:15 ah, it only happens when you have installed it 2021-02-16 16:49:29 yes 2021-02-16 16:49:38 But how does it hook into CFLAGS? 2021-02-16 16:49:42 I just see it contains header files 2021-02-16 16:49:43 and when you activate it via _D_FORTIFY_SOURCE -I/usr/include/fortify 2021-02-16 16:49:58 right, but where does _that_ come from 2021-02-16 16:50:11 It's not in the builders abuild.conf 2021-02-16 16:50:19 I have no idea, you guys are supposed to know the builders more than I do 2021-02-16 16:51:47 if axing the ppoll replacement is an acceptable solution I can provide a patch right away 2021-02-16 16:52:42 There is a gcc patch 2021-02-16 16:52:43 also, if the certificate is expired, is it really wise to rely on that thing? hmmm? :P 2021-02-16 16:52:46 to turn it on 2021-02-16 16:53:01 It's hardcoded into gcc 2021-02-16 16:53:02 ugh 2021-02-16 16:53:03 ikke, this needs to be fixed in fortify-headers. it's breaking any code calling ppoll 2021-02-16 16:53:07 (on 32-bit archs) 2021-02-16 16:53:16 the fortify dev used to hang out here., but i forgot his/her name. 2021-02-16 16:53:39 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0004-Turn-on-D_FORTIFY_SOURCE-2-by-default-for-C-C-ObjC-O.patch 2021-02-16 16:53:50 you can just remove the whole fortify/poll.h if you like 2021-02-16 16:53:56 there's minimal if any benefit from it 2021-02-16 16:54:10 smaller hammer would be just removing the ppoll replacement from it (keeping poll) 2021-02-16 16:55:08 i think for skarnets case he can temp disable fortify? 2021-02-16 16:55:08 I'm okay with removing the fortify/ subdirectory 2021-02-16 16:55:23 and let ncopa take a look at the bigger problem 2021-02-16 16:55:25 clandmeter, there are almost surely more broken packages 2021-02-16 16:55:51 how would I even disable fortify if you *patch fkn gcc* to activate it 2021-02-16 16:55:58 talk about a big hammer 2021-02-16 16:56:22 i remember there was a switch, i just dont remember which one. 2021-02-16 16:56:30 i would just submit a PR for fortify-headers that rm's poll.h before making the apk file 2021-02-16 16:56:37 -U_FORTIFY_SOURCE 2021-02-16 16:56:48 right 2021-02-16 16:56:51 #L35 2021-02-16 16:57:03 dalias: is there an easy way to detected broken stuff? 2021-02-16 16:57:23 objdump all the things, grep for ppoll@plt ? 2021-02-16 16:57:37 clandmeter, yes. nm | grep "U ppoll" 2021-02-16 16:57:58 on all libs and bins 2021-02-16 16:58:30 it's probably not too many because ppoll is nonstd and obscure 2021-02-16 16:58:39 but i would expect you'll find some 2021-02-16 16:59:02 clandmeter: did you fix skarnets container already? 2021-02-16 16:59:08 ikke: nope 2021-02-16 16:59:11 obscure? when it's one of the few actually decent GNU extensions? 2021-02-16 16:59:11 ok 2021-02-16 16:59:15 but i dont think he needs it anymore :) 2021-02-16 16:59:24 how many people use sendmmsg() or other similar shit? 2021-02-16 16:59:35 clandmeter: heh 2021-02-16 16:59:45 clandmeter: indeed, the container has served its purpose :) thanks (and ikke too) 2021-02-16 17:00:21 clandmeter: for the record, where would I set linux32? 2021-02-16 17:00:43 arch: 2021-02-16 17:00:47 from my head 2021-02-16 17:00:52 ah, yes 2021-02-16 17:01:00 I see it in mps' container 2021-02-16 17:01:44 skarnet, not many ppl are aware of it, and it's mainly (only?) useful if you don't know the self-pipe trick 2021-02-16 17:02:11 if you're writing portable software presumably you already have code for the self-pipe trick and there's really no advantage to special-casing the case where you have ppoll available 2021-02-16 17:02:16 I don't use it for the sigmask but for the nanosecond granularity 2021-02-16 17:02:28 I know you find it useless but I don't. :P 2021-02-16 17:02:35 ah 2021-02-16 17:02:41 yes the granularity is somewhat nice 2021-02-16 17:03:07 te 2021-02-16 17:03:14 (oops, sorry) 2021-02-16 17:03:30 do you hit places where it's really needed? i find when you're waiting for input that would block, <1ms is rather pointless, constantly waiting even just 1ms will give massive cpu load anyway 2021-02-16 17:04:05 but you can do finer granularity with timers :-p 2021-02-16 17:04:25 sure, why not use moar fds for timers 2021-02-16 17:04:39 :) 2021-02-16 17:05:44 anyway i'm not trying to criticize you for using it, just saying ppl probably dont find they want/need it often enough for it to appear much in the wild 2021-02-16 17:05:49 ikke: builder is back online 2021-02-16 17:05:50 also most who would are using epoll anyway :-p 2021-02-16 17:06:34 clandmeter: 👍 2021-02-16 17:07:05 how do you even clone the fortify-headers repo 2021-02-16 17:07:15 the instructions it gives don't even work 2021-02-16 17:08:06 I guess you don't and you just grab a tarball 2021-02-16 17:08:46 yes 2021-02-16 17:09:21 such kwality hosting, definitely worthy of managing the security of my software 2021-02-16 17:19:09 shall I try to package https://github.com/matterhorn-chat/matterhorn or is the state of haskell packaging Hell like in every other distro ? 2021-02-16 17:20:17 jvoisin: look at shellcheck 2021-02-16 17:21:01 (^ https://git.alpinelinux.org/aports/tree/community/shellcheck/APKBUILD ) 2021-02-16 17:21:03 looks ok-ish 2021-02-16 17:21:36 jvoisin: at least for now, we decided not to package every lib seperately, but build everything in one go (like rust and golang) 2021-02-16 17:22:51 And it's probably not worth it to start doing that either 2021-02-16 17:27:26 thanks 2021-02-16 17:29:02 ikke, clandmeter: !18376 2021-02-16 17:30:16 once it's merged, could someone please upgrade the 32-bit builders and then rebuild skalibs? thanks :) 2021-02-16 17:30:48 skarnet: rebuild requires a pkgrel bump 2021-02-16 17:31:02 ok, will do 2021-02-16 17:31:12 builders are automatically upgraded before they start a new build cycle 2021-02-16 17:31:46 and once a MR is merged then it goes directly to the apk repositories the builders pull from? 2021-02-16 17:31:59 (having the builders run on edge is... a choice) 2021-02-16 17:32:14 the builders us their own repos 2021-02-16 17:32:19 use* 2021-02-16 17:32:35 So the builders can only use what they have built 2021-02-16 17:32:48 For edge builders that will be edge 2021-02-16 17:35:43 makes sense 2021-02-16 17:36:46 huh, why I can't remove llvm10 and llvm10-libs from my armv7 lxc, deps doesn't show anything, except that llvm10 depends on llvm10-libs 2021-02-16 17:36:59 all pkgs are up to date 2021-02-16 17:40:24 hmm i think fortify-headers mechanism should be rethought too... 2021-02-16 17:40:42 the redir extern-inline approach used is not valid at all. it breaks function pointer equality 2021-02-16 17:41:29 it should just be using macros that only expand where the function is called directly with no capability to do anything for indirect calls 2021-02-16 17:41:56 i was involved in the original design of this and dont remember all the details so it's probably party my fault it's wrong 2021-02-16 17:42:02 what's the best way to debug a build failure that only shows up in the aports CI and not on my local machine? 2021-02-16 17:42:26 https://gitlab.alpinelinux.org/robertgzr/aports/-/jobs/303556 <-- the failure in question 2021-02-16 17:48:16 Cadey: You can try to run it yourself in docker, alpinelinux/build-base 2021-02-16 17:49:41 Hmm: "panic: test timed out after 10m0s" 2021-02-16 17:50:03 yeah, that's the thing i can't reproduce locally, which is odd, that shouldn't time out 2021-02-16 17:50:22 What is the test doing? 2021-02-16 17:52:34 it's making a DNS server and ensuring that the correct responses are returned 2021-02-16 17:52:49 so all localhost? 2021-02-16 17:52:51 yeah 2021-02-16 17:53:10 what's weird is that it isn't failing in any given test 2021-02-16 17:53:23 interestingly ppc64le works 2021-02-16 17:55:54 what's the right docker incantation to get the build-base image to work on a local machine? 2021-02-16 17:56:31 docker run -it --rm alpinelinux/build-base 2021-02-16 17:56:43 abuild-keygen -ain 2021-02-16 17:57:36 git clone https://gitlab.alpinelinux.org/robertgzr/aports.git --depth=1 -b tailscale 2021-02-16 17:58:16 i commented on the fortify-headers issue 2021-02-16 17:59:36 thanks 2021-02-16 17:59:37 it's failing to fetch the dependencies, almost like it can't contact the outside world: WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/edge/main: No such file or directory 2021-02-16 17:59:58 apk udpate, and you also need to add the community repository 2021-02-16 18:00:08 ah 2021-02-16 18:00:13 right 2021-02-16 18:00:27 (I'm testing it on the actual CI host) 2021-02-16 18:03:03 seems to be hanging there as well 2021-02-16 18:06:23 The hanging test: tailscale.com/wgengine/tsdns 2021-02-16 18:06:32 yeah 2021-02-16 18:06:46 === RUN TestDelegate 2021-02-16 18:07:16 that will help a lot, thanks 2021-02-16 18:09:08 i tried to flag 5.10.15 linux-lts in v3.13 as out of date on pkgs.alpinelinux.org 2021-02-16 18:09:12 i get a 404 with: https://pkgs.alpinelinux.org/flag/main/linux-lts/5.10.15-r0 2021-02-16 18:09:47 yeah, you can only flag edge packages 2021-02-16 18:11:23 failed builds maintain the srctree right? 2021-02-16 18:12:44 Cadey: by default it does, yes 2021-02-16 18:12:46 4server, v4errch := serveDNS("127.0.0.1:0") 2021-02-16 18:12:49 6server, v6errch := serveDNS("[::1]:0") 2021-02-16 18:12:51 It's hanging there somewhere 2021-02-16 18:13:09 yeah that's what i'm trying to trace down, i wonder if docker's ipv6 stack is broken 2021-02-16 18:13:52 There is no ipv6 2021-02-16 18:14:14 inside the container 2021-02-16 18:15:18 anoying that docker has no proper IPv6 support by default 2021-02-16 18:16:09 aha, I did enable it on ppc64, explaining that it works there 2021-02-16 18:17:33 But the test should not hang if ipv6 is not available 2021-02-16 18:18:20 yeah, i think i can handle it from here, what's the best way to submit a patch to a MR? 2021-02-16 18:18:49 I'll be enabling ipv6 2021-02-16 18:19:39 Cadey: You can include a .patch file, and add that to the sources 2021-02-16 18:20:09 Cadey: https://gitlab.alpinelinux.org/robertgzr/aports/-/jobs/324065 2021-02-16 18:20:26 ah okay :+1: 2021-02-16 18:20:42 maybe report it upstream 2021-02-16 18:20:54 i'm one of the upstream devs :) 2021-02-16 18:21:08 aha 2021-02-16 18:21:16 nice 2021-02-16 18:21:19 it's been a while since i alpined 2021-02-16 18:23:27 I have to wait for the CI to be quiet so that I can restart docker 2021-02-16 18:24:11 hmm, aarch64 seems to have failed for a different reason 2021-02-16 18:24:20 (ipv6 was already enabled there) 2021-02-16 18:24:34 https://gitlab.alpinelinux.org/robertgzr/aports/-/jobs/303560#L191 2021-02-16 18:25:41 https://github.com/go-ole/go-ole/issues/202 2021-02-16 18:27:34 And s390x: https://gitlab.alpinelinux.org/robertgzr/aports/-/jobs/303558#L246 2021-02-16 18:37:40 Cadey: btw, with go mods, I don't think it's longer necessary to move the source to src/tailscale.com/... 2021-02-16 18:37:46 signal-cli again block edge aarch64 builder 2021-02-16 18:37:53 (ie, for GOROOT) 2021-02-16 18:38:14 ikke: getting you a patch on the abuild 2021-02-16 18:38:22 (also upgrades you to 1.4.4) 2021-02-16 18:39:03 Cadey: working on getting tailscale into Alpine? 2021-02-16 18:41:24 Cadey: TestIgnoreLocallyBoundPorts is failing on s390x 2021-02-16 18:44:45 is this tailscale open and free 2021-02-16 18:45:20 ikke: can you get me the output of that? that's odd 2021-02-16 18:45:32 I'm adding some debug statements 2021-02-16 18:45:57 jvoisin: right now just fixing a MR that would add tailscale to alpine, it exposed an assertion failure in one of the tests 2021-02-16 18:49:06 mps: https://www.tailscale.com/ 2021-02-16 18:50:04 jvoisin: already looked but can't see 'download source' 2021-02-16 18:50:28 and didn't noticed 'install your server' 2021-02-16 18:51:29 check https://github.com/tailscale 2021-02-16 18:51:49 Cadey: https://tpaste.us/OQ5Z 2021-02-16 18:54:55 jvoisin: thanks 2021-02-16 18:59:57 Cadey: let me know if I can provide more information 2021-02-16 19:04:58 ikke: can you apply that patch i attached into the MR? 2021-02-16 19:06:01 When ipv6 is disabled? 2021-02-16 19:06:23 the disabling s390x patch 2021-02-16 19:06:28 as in apply it to the MR 2021-02-16 19:07:27 Cadey: I only a patch for fixing ipv6 2021-02-16 19:07:51 i mean https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17397#note_142739 2021-02-16 19:08:17 ah 2021-02-16 19:08:18 (we don't have s390x hardware available to fully debug this on) 2021-02-16 19:08:37 yeah, understood 2021-02-16 19:09:39 (I missed the fact that you are not the one who contributed the aport) 2021-02-16 19:10:15 :+1: 2021-02-16 19:12:29 maxice8 already applied them, good 2021-02-16 19:16:30 thanks much for the help ikke 2021-02-16 19:16:54 50 pending jobs on our CI 😶 2021-02-16 19:17:03 Cadey: no problem 2021-02-16 19:17:13 Cadey: did you see the arm issues? 2021-02-16 19:17:22 A problem with ole 2021-02-16 19:18:46 i did not 2021-02-16 19:18:54 i am looking 2021-02-16 19:19:00 (meeting in parallel) 2021-02-16 19:21:27 Ikke: openssl got security upgrade :D 2021-02-16 19:21:41 maxice8: yeah, noticed 2021-02-16 19:22:03 I killed some stale webkit jobs that were still running 2021-02-16 19:22:09 (8+ hours) 2021-02-16 19:27:54 ikke: i'm mystified as to how the arm build is pulling in OLE 2021-02-16 19:28:36 i'm gonna investigate though 2021-02-16 19:29:33 It's in the go.sum file 2021-02-16 19:29:44 and go.mod 2021-02-16 19:32:20 Rust bootstrap goes very nice rn, linked against musl, compiled with clang and no libgcc 2021-02-16 19:40:00 maxice8: there are btw also xen advisories 2021-02-16 20:10:05 Hi everyone! just a quick question: in APKBUILD, is it possible to have a testing package in makedepends? 2021-02-16 20:10:38 You cannot depend on packages in 'lower' repositories 2021-02-16 20:10:49 so packages in community and main cannot depend on packages in testing 2021-02-16 20:11:40 I see. Is that true for build time depends and runtime depends? 2021-02-16 20:12:02 yes 2021-02-16 20:12:56 so in general, which line in APKBUILDS identifies which repo are we targetting? or is that based on /etc/apk/repositories 2021-02-16 20:13:18 the parent directory 2021-02-16 20:13:27 if you clone the aports repo you'll see main/openssl/APKBUILD 2021-02-16 20:14:49 right. thanks a lot :) 2021-02-16 21:25:01 Howdy. I'm trying to find the script being used to generate the apks/* files for the RaspberryPi images. Is that script pulling from upstream, downloading apks, then creating the repository list and then everything just gets installed from there? I'd like to add in a few packages from edge for the initial installation 2021-02-16 21:25:40 as well as set wireless-tools and wpa_supplicant to install at boot. I may be overlooking something simple. 2021-02-16 21:26:54 ACTION extracts the initramfs 2021-02-16 21:33:15 mad props to whomever wrote /init in the initramfs 2021-02-16 21:33:53 ah.. myopts. I got it from here folks.. thanks for the help :) 2021-02-16 21:43:25 aaaand !18398 2021-02-16 22:41:32 lovely, after upgrade to edge with musl 1.2 i can't play doom because SDL_mixer has a buffer overflow and mallocng detects it... 2021-02-16 22:42:33 lol 2021-02-16 22:46:40 looks like it malloc(65891)'d and needed 65892 bytes 2021-02-16 22:51:56 now to figure out where this shit is called from.. 2021-02-16 23:17:38 timidity/instrum.c line 788 2021-02-16 23:17:47 it copies the last sample to the position 1 past the end 2021-02-16 23:17:51 samples are 2 bytes 2021-02-16 23:17:56 but it only allocated +1 byte 2021-02-16 23:18:18 timidity will probably also need this fix 2021-02-16 23:20:18 http://ix.io/2PG0 2021-02-16 23:45:49 fortify-headers bad they use gcc extensions 2021-02-16 23:47:58 protonesso: if you consider using gcc extensions as part of our gcc toolchain hardening effort is 'bad', then i do not know what to tell you 2021-02-16 23:48:14 I mean I fixed it 2021-02-16 23:48:49 Or """"fixed"""" 2021-02-16 23:48:56 what is bad is when it breaks stuff. :P 2021-02-16 23:49:16 oh, the OOM killer killed my quassel 2021-02-16 23:49:28 earlyoom? 2021-02-16 23:49:32 i increased the RAM allocated to my container VM to something much larger 2021-02-16 23:49:36 problem solved 2021-02-16 23:49:48 or something else 2021-02-16 23:49:53 i would not be surprised if quassel was leaking ram tbh 2021-02-16 23:51:17 <[[sroracle]]> i dunno about the client, but the core actually leaks a lot less than weechat :p 2021-02-16 23:51:52 Btw how's rust going? 2021-02-16 23:52:32 protonesso: we have determined that openwrt can cross compile rust, so i am looking at their setup more 2021-02-16 23:53:16 Nice, check out my rustie it can cross compile rust too! My host is Fedora 2021-02-16 23:54:55 Ariadne: should I post it? 2021-02-16 23:55:09 go ahead, but does not really do me any good (: 2021-02-16 23:55:32 s390x and riscv64 need actual code to be written 2021-02-16 23:55:35 https://github.com/ataraxialinux/rustie 2021-02-16 23:55:47 so we focus on mips64 for now 2021-02-16 23:55:51 You can skip clang specific patches 2021-02-16 23:56:44 Haven't tried building cargo, maybe there will be openssl issues idk 2021-02-16 23:57:10 dalias: are you filing upstream? 2021-02-16 23:59:22 yes just did: https://github.com/libsdl-org/SDL_mixer/issues/299 2021-02-17 00:00:01 thanks! 2021-02-17 00:01:34 So basically mallocng can replace asan? 2021-02-17 00:03:08 no 2021-02-17 00:04:39 shit code is revealed in many ways 2021-02-17 00:28:38 protonesso, not really. it can't report a problem it doesn't see, so for example a problem that only touches any memory that dosn't get freed 2021-02-17 00:35:39 Thanks for explaining 2021-02-17 01:23:58 hmm, 3rd days working with the same package, dabuild suddenly stops compiling 2021-02-17 01:24:02 /usr/include/iconv.h:17:23: note: expected 'char ** restrict' but argument is of type 'const char **' 2021-02-17 01:24:03 17 | size_t iconv(iconv_t, char **__restrict, size_t *__restrict, char **__restrict, size_t *__restrict); 2021-02-17 01:24:06 | ^ 2021-02-17 01:24:08 cc1: all warnings being treated as errors 2021-02-17 01:24:19 i reverted to the exact same APKBUILD, same error, tried it local, same error 2021-02-17 01:24:55 puzzling how did it manage to compile in the past 3 days 2021-02-17 01:28:01 -Werror ftw 2021-02-17 01:29:20 lol 2021-02-17 01:32:13 i found your t-shirt ;) https://www.amazon.com/Funny-Developer-Programmer-Tshirt-Compiles/dp/B079BDFQQG 2021-02-17 01:36:36 malloc also can't tell you when it was corrupted (other than it being some time between the malloc and the free) 2021-02-17 01:40:36 half way through splitting a package into 15 subpackages from comparing 120+ sets of binaries resulting from over 5x4x3x2 config combinations, and cmake decides blows up and I have to goto a wedding tomorrow :/ 2021-02-17 01:51:02 alexy, thats a compiler bug, its not a type mismatch 2021-02-17 01:57:23 hmm 2021-02-17 02:00:40 in a function argument the qualified and unqualified type are identical 2021-02-17 02:00:48 const char * and char * are not the same 2021-02-17 02:00:53 but char *const and char * are the same 2021-02-17 02:01:11 the qualifier is just relevant to the local var that receives the value inside the function 2021-02-17 02:01:16 not the the caller/callee relationship 2021-02-17 06:29:41 i wish this verifying modloop thing was skippable 2021-02-17 06:30:02 it really sucks when you are installing over IPMI and you're not in the same room as the server 2021-02-17 06:34:08 this is brutal 2021-02-17 06:50:29 workaround: disconnect cdrom and reconnect it 2021-02-17 06:50:35 then remount /media/cdrom 2021-02-17 06:50:45 and modify modloop service to skip verify 2021-02-17 07:24:55 What's the proper way to to link to lua 5.2 with -llua? 2021-02-17 07:24:55 tested: lua5.2 lua5.2-dev lua5.2-libs lua5.2-pc 2021-02-17 07:24:55 lua 5.2 does not create link to /usr/lib/liblua.so 2021-02-17 07:25:26 -llua isn't 5.2 2021-02-17 07:25:37 you'll need -llua5.2 if you want that 2021-02-17 07:25:42 moan 2021-02-17 07:26:00 -llua is 5.4 2021-02-17 07:26:08 afaik 2021-02-17 07:28:27 morning 2021-02-17 07:28:38 this pkg first detects 5.2, if not found detects 5.1, on 5.1 it gives you botched modules so you need 5.2, so you install 5.2 and then it gives you this: 2021-02-17 07:28:41 /bin/ld: cannot find -llua 2021-02-17 07:28:52 skarnet: good job with fixing the fortify-headers thing 2021-02-17 07:30:38 alexy: iirc the proper way is to do soemthign like: CFLAGS=$(pkg-config --cflags lua5.2); LDFLAGS=$(pkg-config --ldflags lua5.2) 2021-02-17 07:31:46 actually it is LUA_CFLAGS=$(pkg-config --cflags lua5.2); LUA_LIBS=$(pkg-config --ldflags lua5.2) 2021-02-17 07:32:42 s/--ldflags/--libs/ 2021-02-17 07:32:42 ncopa meant to say: actually it is LUA_CFLAGS=$(pkg-config --cflags lua5.2); LUA_LIBS=$(pkg-config --libs lua5.2) 2021-02-17 07:33:05 $ pkg-config --libs lua5.2 2021-02-17 07:33:05 -L/usr/lib/lua5.2 -llua -lm 2021-02-17 07:33:18 ahh 2021-02-17 07:45:39 this modloop shit is brutal 2021-02-17 07:45:52 over IPMI 2021-02-17 07:45:55 over starlink 2021-02-17 07:49:03 it is literally requesting it a sector at a time 2021-02-17 07:49:15 with 100ms rtt for every sector, that's not great :P 2021-02-17 07:50:31 would be nice if can be downloaded and specified in APEND 2021-02-17 07:51:03 well just skipping the verify 2021-02-17 07:51:05 would be good enough 2021-02-17 07:51:32 maybe this also 2021-02-17 07:52:31 its ipmi 2021-02-17 07:52:36 there isnt going to be a media error 2021-02-17 07:52:37 haha 2021-02-17 07:54:38 yeah, we should have a way to disable the modloop verification 2021-02-17 07:54:47 i thikn we should tag 3.13.2 today 2021-02-17 07:55:17 can we add the disable modloop before doing that :P 2021-02-17 08:26:21 Best way to get mongodb 4.2 in alpine? Build from aports? 2021-02-17 08:28:16 Does anyone here use mongodb 4.2 in alpine, I am stuck with mongo due to the nodebb projekt :) 2021-02-17 08:34:10 I think we dropped mongo when they changed license 2021-02-17 08:39:07 Yes, moved to non-free 2021-02-17 08:46:03 Is there something going on with the arm* CI? Both armv7 and aarch64 are failing before they even start building the packages and both fail in the same way 2021-02-17 08:49:23 Restarting CI helped, but it happened for multiple MR's 2021-02-17 08:50:23 Cogitri, Yeah I know 3.9. But mongo is widely used 2021-02-17 08:51:35 ikke, Yes. but there is only a 4.0.x and not 4.2.x build file on non-free 2021-02-17 08:53:02 It's not really maintained 2021-02-17 08:53:04 No one bothered to upgrade it probably 2021-02-17 08:55:23 Actually, it's not just arm, happened on x86_64 just a moment ago as well 2021-02-17 08:55:32 https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/324728#L27 2021-02-17 08:57:58 Cogitri, Yeah. I am going to try to update it hehe 2021-02-17 08:58:16 Cogitri, Maybe need some help. :P 2021-02-17 08:58:44 Learning the abuild tools now :) 2021-02-17 09:21:46 ncopa: thanks, now someone please merge !18398 so I can tell people it's fixed ^^ 2021-02-17 09:23:08 Done 2021-02-17 09:25:23 PureTryOut[m]2: strange 2021-02-17 09:26:32 Cogitri: thanks! 2021-02-17 09:26:42 Ariadne: 6da33daffe1f0b7b35f30abefc5e3877d8c84f44 2021-02-17 09:28:33 i need to check that 2021-02-17 09:28:55 nono 2021-02-17 09:29:03 ncopa: that's not what i need 2021-02-17 09:29:03 that disables use of modloop 2021-02-17 09:29:07 i need modloop itself 2021-02-17 09:29:07 yea i figured 2021-02-17 09:29:16 you need siable verification 2021-02-17 09:29:17 i just don't want to waste 30 minutes on verifying it 2021-02-17 09:29:21 :D 2021-02-17 09:29:39 i wonder if we should do modloop=noverify or similar 2021-02-17 09:30:07 the tricky part is that you can do modloop=path/to/modloop 2021-02-17 09:30:19 Any reason why the pipeline would say "No packages found to be built" where the linter runs happily-ish on !18411 I'm a bit baffled here :) 2021-02-17 09:30:32 Why no option modloop_verify 2021-02-17 09:30:58 to reduce number of different boot options 2021-02-17 09:31:09 but yeah, that woudl make things simpler 2021-02-17 09:32:02 oliv3r[m]: maybe because the APKBUILD has invalid shell synatx? Try: `sh ./APKBUILD` 2021-02-17 09:32:28 ncopawell it's in the CI so I can't really do much there? 2021-02-17 09:32:48 ncopa: could it use local path and have local checksum for verification 2021-02-17 09:33:01 i have my own 'micro-ci' locally :p where i have a docker container that does the whole abuild dance; and that builds fine-ish 2021-02-17 09:33:45 'secure' distro with option to not verify auto downloaded files from net? 2021-02-17 09:33:46 It uses ap builddirs to determine the build order of packages 2021-02-17 09:34:20 mps: a local checksum would still take tens of minutes over ipmi 2021-02-17 09:34:30 oliv3r[m]: you could apply it to local repo: curl -L https://gitlab.alpinelinux.org/alpine/aports/merge_requests/18411.patch | git am 2021-02-17 09:35:03 mps: because you would have to make sure the checksum matches the actual squashfs 2021-02-17 09:35:07 ncopa: not sure i follow, I wrote the patch locally, and pushed it for the CI to build it, so i'd end up with the same patch, no? 2021-02-17 09:35:38 oliv3r[m]: oh., ok yes. does shell successfully parse it locally? 2021-02-17 09:36:06 sh ./APKBUILD && echo "everything is ok" 2021-02-17 09:36:18 Ariadne: if you download modloop and checksum file and check it before installation then you could use no verify option, it it would be added 2021-02-17 09:36:19 yeah, I can build it just fine locally (well not because of some bugs) but the CI doesn't even pick it up, just says 'no package' when trying to do the build (and passes too) 2021-02-17 09:36:37 does it print "everything is ok" or does it giver error message? 2021-02-17 09:36:39 but default should be 'enable verify' 2021-02-17 09:36:49 s390x builds seem to be failing, is that normal? https://gitlab.alpinelinux.org/skarnet/aports/-/jobs/324839 2021-02-17 09:37:16 hum 2021-02-17 09:37:17 mps: i do not disagree and did not ask for that, just an option to skip verification :P 2021-02-17 09:37:26 i think somethign else is broken 2021-02-17 09:37:58 ok, with 'verify=no' and "Yes, I know what I do" :) 2021-02-17 09:38:14 what the fuck 2021-02-17 09:38:20 that is a really weird issue skarnet 2021-02-17 09:38:31 sh ./APKBUILD; echo $? -> 0 2021-02-17 09:38:34 its making an empty git repo instead of cloning the real one 2021-02-17 09:39:07 yeah 2021-02-17 09:39:22 ncopa actually I see this happening on my stuff too: Initialized empty Git repository in /builds/oliver/aports/.git/ 2021-02-17 09:39:31 ACTION wonders why are 'fuck' ok word for CoC but 'idiot' isn't 2021-02-17 09:39:34 but this time I'm not spending a week debugging an Alpine-specific stuff 2021-02-17 09:39:35 ok, i verified all the APKBUILDs problem is not bad syntax in APKBUILDs 2021-02-17 09:39:41 so I'm just reporting the problem and letting you deal with it 2021-02-17 09:39:55 mps: I suppose because idiot is to insult a person, fuck is just an 'outcry' 2021-02-17 09:40:17 skarnet: fair 2021-02-17 09:40:23 oliv3r[m]: it could 'vice versa' also 2021-02-17 09:40:42 mps: I would expect 'motherfucker' on both sides though; as it can be insulting when calling someone; but could be still an outcry; motherfucker, wtf happended here?! vs 'you motherfucker' 2021-02-17 09:40:53 skarnet: i wouldnt worry about it 2021-02-17 09:41:17 skarnet: cogitri already merged it anyway 2021-02-17 09:41:20 oliv3r[m]: though I think that bad words doesn't exists 2021-02-17 09:41:29 @mps: I agree, words are just words :) 2021-02-17 09:41:37 it is all about _intent_ 2021-02-17 09:41:39 sure, but inb4 "I tried to install skalibs on s390x and it didn't work" XD 2021-02-17 09:41:46 oliv3r[m]: agree fully 2021-02-17 09:42:13 in summary, could it be, that the pipeline is failing to properly clone repo's and thus fails to run? 2021-02-17 09:42:15 i dont know whats going on with the git clone tihngy 2021-02-17 09:42:38 i think something is broken wrt cloning the repo yes 2021-02-17 09:42:53 ah, in my case, it is caused dirnames not matching package names (a bit odd of a requirement, something the linter should fail on surely :) 2021-02-17 09:43:06 thanks to starfire 2021-02-17 09:44:22 skarnet: i am using various skalibs consuming programs on my s390x machine 2021-02-17 09:44:32 if it breaks, you'll be the first to know ^_^ 2021-02-17 09:45:10 Ariadne: that's good news :"D 2021-02-17 09:45:42 hum, i dunno whats going with the CI on s390x 2021-02-17 09:51:18 I don't seem to have the rights to close issues on the gitlab, or I can't find out how to do it 2021-02-17 09:51:30 someone please close #12346 :) 2021-02-17 09:57:04 Ah, ideally there would've been a "fixed #12346" in the commit description 2021-02-17 09:57:45 fixes* 2021-02-17 10:03:15 Cogitri: newcomers don't read CODINGSTYLE and COMMITSTYLE 2021-02-17 10:14:27 I'm sorry, it's not exactly intuitive that a line in the commit will automatically act on something unrelated to git 2021-02-17 10:15:06 this is some integrated forge feature that I'm not used to, and that kind of feature is different with every forge 2021-02-17 10:15:53 this is not big issue, I didn't wanted to address you, but comment was more general 2021-02-17 10:16:46 yeah but my point was that if I have the permissions to close issues via a commit, then I should also be able to close them via the web UI 2021-02-17 10:17:07 but it looks more and more like gitlab's web UI is essentially useless 2021-02-17 10:17:19 if you created it you should be able to close it 2021-02-17 10:17:28 I didn't create it 2021-02-17 10:17:32 ah 2021-02-17 10:18:02 I'm not right on workstation, else I would close it 2021-02-17 10:18:11 right now* 2021-02-17 10:18:43 so either only the creator (and admins) should be able to close, or anyone participating should, but there's no reason why I can close via a commit and not via a button 2021-02-17 10:19:16 actually, those who merge 'closes' them 2021-02-17 10:19:25 automatically, ofc 2021-02-17 10:20:00 yeah, that's understandable, but still unintuitive workflow 2021-02-17 10:20:34 well, I don't expect much from web uis :) 2021-02-17 10:21:50 GUI, interface for people with alzheimer illness :D 2021-02-17 10:22:12 please don't make fun of diseases 2021-02-17 10:22:39 it is not about disease 2021-02-17 10:23:42 skarnet: You can close via a commit because then a party which could also close the issue via the webUI is the comitter 2021-02-17 10:24:01 OT, but also taking diseases too seriously is wrong 2021-02-17 10:24:03 As in it's not actually you closing the issue. it's the committer who merges the MR which does it automatically 2021-02-17 10:24:35 yeah, I got that 2021-02-17 10:46:21 i wonder if can require SSE2 for go nowdays 2021-02-17 10:46:56 it means that our go apps will no longer run on athlon xp 2021-02-17 10:46:59 https://gitlab.alpinelinux.org/alpine/aports/-/issues/6788 2021-02-17 10:47:32 Do folks really run latest Alpine on such old chips? 2021-02-17 10:48:02 they did four years ago 2021-02-17 10:48:17 Probably especially alpine, because it's light-weight 2021-02-17 10:48:23 but there are also https://en.wikipedia.org/wiki/Intel_Quark 2021-02-17 10:48:23 [WIKIPEDIA] Intel Quark | "Intel Quark is a line of 32-bit x86 SoCs and microcontrollers by Intel, designed for small size and low power consumption, and targeted at new markets including wearable devices. The line was introduced at Intel Developer Forum in 2013. Quark processors, while slower than Atom processors, are much smaller..." 2021-02-17 10:48:31 I have to admit I'm not quite in the clear how much of a performance difference it makes thoigh 2021-02-17 10:48:32 which seems to be from 2013 2021-02-17 10:53:11 Oh, huh 2021-02-17 10:53:42 I think we probably already require SSE(2) for some libs like ffmpeg which autodetects stuff during configure 2021-02-17 10:54:34 yeah 2021-02-17 10:55:53 im pushing the build fix. if someone complains we can ask if they can build their binary on other machine and copy it over 2021-02-17 10:56:14 worst case we enable GO386=softfloat like we do on other arches 2021-02-17 10:58:38 The failing CI, is not not just merge request that are merged and the source branch has been removed? 2021-02-17 11:06:41 oh that might be 2021-02-17 11:09:32 I think cogitri merged it before those jobs started 2021-02-17 11:31:23 maxice8: ../libfwupdplugin/fu-plugin-vfuncs.h:15:10: fatal error: fu-hash.h: No such file or directory 2021-02-17 12:30:16 Huh, https://pkgs.alpinelinux.org/package/edge/community/s390x/telepathy-mission-control has been disabled on s390x but is still available in the repositories? 2021-02-17 12:34:49 the package wont be removed until a rebuild event occurs 2021-02-17 12:35:39 But in the meantime it can't be used anyway, as it'll just complain that one of it's deps (networkmanager) isn't available. So what use is keeping it? 2021-02-17 14:04:56 Can someone give the aarch64 builder a kick? It seems to have ignored my last commit and algitbot refuses to listen to me 2021-02-17 14:05:21 I think the aarch64 builder might be down completely? 2021-02-17 14:05:25 I pushed a possible fix for fwupd 2021-02-17 14:05:37 it is building signal-cli atm apparently 2021-02-17 14:05:39 CC ikke 2021-02-17 14:05:40 according to build.a.o 2021-02-17 14:05:46 maxice8: it isn't though 2021-02-17 14:05:51 the build failed and I disabled it already 2021-02-17 14:06:02 PureTryOut[m]2: I think signal-cli is stuck 2021-02-17 14:06:05 The builder isn't checking for changes anymore 2021-02-17 14:16:31 Can anyone check that builder? 2021-02-17 15:19:52 I guess edge is master in aports, correct? 2021-02-17 15:20:43 afaik yes 2021-02-17 15:21:36 Tried to build nginx from master but a lot tests fail 2021-02-17 15:22:05 Failed 3/12 subtests 2021-02-17 15:23:02 abuild -r should work in nginx master right? 2021-02-17 15:27:17 https://build.alpinelinux.org/buildlogs/build-3-13-x86_64/main/nginx/nginx-1.18.0-r13.log <-- Latest build for edge. The one in master seams to be r14 2021-02-17 15:53:34 That log is for 3.13 2021-02-17 15:54:36 ikke, Yes 2021-02-17 15:54:48 Master was indeed 14 2021-02-17 15:55:47 ikke, but I was not able to build it. I know that build as root is not that good but abuild -F -r should work 2021-02-17 15:56:06 I am tying nginx in 3.13 now 2021-02-17 15:56:32 I recall there still being issues with building as root 2021-02-17 15:56:33 To see if the tests works. I am building from a chroot. And chmod work 2021-02-17 15:56:56 ikke, ok why is that? 2021-02-17 15:57:33 Not sure, just users reporting it not working despite passing -F 2021-02-17 15:57:37 I understand the security about it. But the build should work 2021-02-17 15:57:53 ikke, ahh 2021-02-17 16:00:46 using this: https://wiki.alpinelinux.org/wiki/Alpine_Linux_in_a_chroot as chroot 2021-02-17 16:04:24 hmm getting /gzip.t ................................... Dubious, test returned 2 (wstat 512, 0x200) 2021-02-17 16:04:24 Failed 2/10 subtests 2021-02-17 16:05:08 ikke, Do you know if that was the issues with root 2021-02-17 16:14:10 Jenkler: No 2021-02-17 16:25:00 ikke, Trying as user now ;) both 3.13 and edge breaks with root. 2021-02-17 16:35:09 ikke, Yes indeed -F is broken. With a user it seams to work ;) Strange 2021-02-17 16:35:38 Jenkler: I would not know how / why it would cause these kinds of issues though 2021-02-17 16:35:51 Jenkler: maybe it's just the nginx test suite that does not run properly as root? 2021-02-17 16:43:17 PureTryOut[m]2: I've killed signal-cli, I saw that you already disabled it 2021-02-17 16:44:46 Yup, thanks 2021-02-17 16:46:22 ikke, seams more safe to fix a user for this ;) 2021-02-17 16:46:31 Jenkler: certainly 2021-02-17 17:34:54 ikke, py2-cheetah does not exist in 3.13 2021-02-17 17:35:56 Jenkler: correct, py2 is mostly deprecated. Any reason you are looking for it? 2021-02-17 17:35:59 Maybe i can try py3-cheetah 2021-02-17 17:36:16 or py2 _is_ deprecated, and most packages have been removed 2021-02-17 17:36:49 https://pastebin.com/CUnwCgBT 2021-02-17 17:37:30 ah, trying to build mongodb 2021-02-17 17:37:35 yepp heeh 2021-02-17 17:37:39 asio-dev missing to 2021-02-17 17:37:51 https://pkgs.alpinelinux.org/packages?name=asio-dev&branch=edge 2021-02-17 17:37:57 It's in community 2021-02-17 17:38:11 ohhh 2021-02-17 17:38:22 byt py2 is gone 2021-02-17 17:51:20 ikke, nope p3 does not work ;) 2021-02-17 17:51:36 yeah, it's probably not that easy 2021-02-17 17:51:43 hehe 2021-02-17 18:52:15 sam_, SDL_mixer bug is fixed upstream now 2021-02-17 19:01:30 off-by-one error strikes again :) 2021-02-17 19:03:57 :) 2021-02-17 19:04:16 can alpine apply the patch so doom works again? :) 2021-02-17 19:04:32 (or anything using sdl_mixer, but the only sdl 1.x app I have left is prboom) 2021-02-17 19:04:35 I don't see why not 2021-02-17 19:17:28 dalias: thanks a bunch! 2021-02-17 19:18:07 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18438 2021-02-17 19:26:25 merged 2021-02-17 19:29:50 yay 2021-02-17 21:20:41 nice 2021-02-17 22:02:37 hmmm, seems like bind libs use a different version scheme in 9.16.12 2021-02-17 22:03:02 Hmm, no, libbind is actually missing 2021-02-18 04:18:28 Hello 2021-02-18 04:18:59 I was wondering if i could get some help compiling the kernel to add extra features to fit lxc 2021-02-18 07:03:30 morning 2021-02-18 07:04:55 mornin 2021-02-18 07:28:19 morning 2021-02-18 07:49:51 Would you have some time today or tomorrow to look at the nlplug-findfs issue we have with linux 5.10? 2021-02-18 07:51:51 I have time to look at it 2021-02-18 07:56:39 I was wondering if i could get some help compiling the kernel to add extra features to fit lxc 2021-02-18 07:57:10 The Custom Kernel wiki is not optimal 2021-02-18 07:57:47 .. 2021-02-18 09:12:19 ikke: im kinda busy today. maybe tomorrow? 2021-02-18 09:12:28 sure 2021-02-18 09:12:54 i tried to reproduce it in qemu without success 2021-02-18 09:14:08 It happens on one of or CI servers and not the others 2021-02-18 09:37:35 I suspect some traefik tests fail due to go1.16 2021-02-18 09:40:22 yes, it fails on other arches as well, not just aarch64 2021-02-18 09:44:53 I wonder if we should move the preamble of default_unpack to a separate runpart or something like that. Right now, it's not really feasible to override default_unapck without having to repeat that part as well 2021-02-18 09:44:58 unpack* 2021-02-18 09:47:58 Not sure if I actually want to override defaul_unpack, but the usecase is that the traefik source does not include a subdir, so it clobbers srcdir now atm 2021-02-18 10:14:31 dunno 2021-02-18 11:06:54 sounds like traefik is in a jam 2021-02-18 11:07:28 !12444 2021-02-18 11:07:35 #12444 2021-02-18 11:17:40 skarnet: I appreciate the pun :) 2021-02-18 11:18:22 ikke: you're one of the 3 people in the world who appreciates my puns, thank you ;) 2021-02-18 11:18:34 :D 2021-02-18 11:18:35 s/appreciates/appreciate/ 2021-02-18 11:18:35 skarnet meant to say: ikke: you're one of the 3 people in the world who appreciate my puns, thank you ;) 2021-02-18 12:49:21 !18464 2021-02-18 14:23:23 question: $pkgname-client-openrc in bacula should be shipped when installed bacula-client. In order to achieve this, it's enoug putting depends="$pkgname-client" in the openrc_client() function? 2021-02-18 14:23:28 Or there's a better way? 2021-02-18 14:24:25 install_if="openrc bacula-client=$pkgver-r$pkgrel" 2021-02-18 14:24:34 ah install_if.. 2021-02-18 14:24:40 thx maxice8 2021-02-18 14:24:41 makes so $pkgname-client-openrc is automatically installed when openrc and bacula-client is installed 2021-02-18 14:25:20 fcolista: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1953 2021-02-18 14:26:08 cool no need to add openrc 2021-02-18 14:27:20 http://dpaste.com/52GXNH6TX.txt 2021-02-18 14:27:38 You need both 2021-02-18 14:27:47 That makes it so it's only installed if openrc is also installed 2021-02-18 14:28:18 Other way around I think 2021-02-18 14:28:31 yes I was thinking the other way round 2021-02-18 14:28:52 maxice8: ? 2021-02-18 14:29:03 Both are needed but the one you posted makes so it is installed if bacula-client is installed, regardless if openrc is installed or not 2021-02-18 14:29:28 but I see the reason...does not make any sense to install the init if openrc is not installed, like in docker case 2021-02-18 14:29:35 fcolista: correct 2021-02-18 14:29:48 fcolista: I think you can even just override install_if and call default_openrc 2021-02-18 14:30:12 There is already an -openrc function 2021-02-18 14:30:17 function/subpkg 2021-02-18 14:30:17 yes 2021-02-18 14:30:32 but that would install it for bacula, not bacula-client 2021-02-18 14:30:54 maxice8, that was I was thinking too but that was misleading, ikke is right 2021-02-18 14:30:58 yes 2021-02-18 14:31:04 the split functions always assume there is only one of them, 1 -dev, 1 -doc, etc 2021-02-18 14:31:23 maxice8: but you can still manually call default_opernc in your custom function 2021-02-18 14:32:30 yes, just make sure to move the other .initd and .confd files back to mainpkg after calling it 2021-02-18 14:32:50 rnalrd, are you ok if i push this? http://dpaste.com/94KM733GH.txt 2021-02-18 14:33:05 I think that it needs to be backported to 3.13 too 2021-02-18 14:33:56 ok 2021-02-18 14:37:03 omni: amfora is for some reason failing on aarch64 2021-02-18 16:20:11 Hi 2021-02-18 16:20:31 Can i get help prepairing the kernel for lxc on raspberry pi 4 2021-02-18 16:23:19 jackaraa: it helps if you stay longer than a few minutes each time 2021-02-18 16:35:11 =D 2021-02-18 17:02:28 ugh.. the kernel builds for stable branches broke. will try fix tomorrow morning 2021-02-18 17:04:06 yup 2021-02-18 17:35:20 thank you maxice8 !18465 2021-02-18 17:38:21 MY-R: the gnutls depedency is kind of a problem 2021-02-18 17:38:38 Yes, it is why I put it as Draft: dep 2021-02-18 17:38:41 * Yes, it is why I put it as Draft: 2021-02-18 17:39:03 sadly chrony wont support openssl because of license if I remember corectly 2021-02-18 17:48:25 ikke: oh, thanks, weird, not sure what to make of that 2021-02-18 17:56:24 hmm, works on my aarch64 container 2021-02-18 18:02:36 omni: aha, I think I know what's going on 2021-02-18 18:04:01 omni: the arguments to -extldflags needs to be quoted 2021-02-18 18:06:16 not sure why it's only an issue on that builder, thoguh 2021-02-18 18:06:18 though* 2021-02-18 18:18:34 aha, it fails when $LDFLAGS is empty 2021-02-18 18:19:45 ncopa: do we need LDLAGS="-Wl --as-needed" on aarch64? 2021-02-18 18:21:31 omni: fixed 2021-02-18 18:32:34 omni: lol, you ran into the same issue as I did with APKBUILD.vim :D 2021-02-18 18:32:38 https://gitlab.alpinelinux.org/Leo/apkbuild.vim/-/issues/2 2021-02-18 19:09:02 any plans on upstreaming it into vim btw? 2021-02-18 19:09:09 no 2021-02-18 19:09:14 shall I do it? 2021-02-18 19:09:51 I won't stop you but I have no will to do it 2021-02-18 19:48:24 hi! does anyone here have experience with bind? I'm updating the package for void to .12 and hit an issue where it gets undefined reference to _Unwind_GetIP on armhf and armv7l 2021-02-18 19:48:47 and only on musl, so I figured someone here might have faced such issues already :D 2021-02-18 19:48:53 Which version ? 2021-02-18 19:49:17 9.16.12 2021-02-18 19:49:28 you currently have 9.16.11 from what I can see 2021-02-18 19:49:46 I also just saw the --disable-backtrace option, so I wonder if that's enough 2021-02-18 19:50:22 I made !18481 2021-02-18 19:50:25 lets see if it is enugh 2021-02-18 19:50:28 yes you need libunwind or to disable in that case 2021-02-18 19:50:29 enough* 2021-02-18 19:52:19 sam_: nm -D said libunwind.so didn't have _Unwind_GetIP, so I figured it wasn't available 2021-02-18 19:52:47 maybe I should have looked at all the other DSOs it provides 2021-02-18 19:53:03 yay, --disable-backtrace worked! 2021-02-18 20:05:48 yay! 2021-02-18 20:08:21 well, thanks for the help :) 2021-02-18 20:08:32 maxice8: and also, that was a fast PR :o 2021-02-18 20:08:56 ericonr: not on arm atm but I see it on amd64, will check arm later out of curiosity 2021-02-18 20:08:56 it is a very streamlined process 2021-02-18 20:09:04 i've personally had fun with it on dovecot 2021-02-18 20:16:00 sam_: it's in the headers, just not an exported symbol of libunwind.so 2021-02-18 20:21:30 ah 2021-02-18 21:12:43 packaging haskell isn't fun 2021-02-18 21:57:29 ikke: cool! 2021-02-19 00:35:33 you guys tracking CVE-2021-3177, python3 RCE? cc ncopa 2021-02-19 00:35:43 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12448 2021-02-19 00:35:56 I'll assume that 404 page is a relevant issue 2021-02-19 00:35:58 thanks 2021-02-19 00:36:03 it is confidential 2021-02-19 05:50:25 Does anyone know when python 3.8.8rc1 will be available for install? I see it listed https://pkgs.alpinelinux.org/flagged but I'm not sure when it will show up in the repos. 2021-02-19 06:28:18 bob17: never 2021-02-19 06:28:27 bob17: we do not ship RCs 2021-02-19 06:29:03 Is there an ETA on an official build? 2021-02-19 06:29:26 Is there a way to download the RCs for testing? 2021-02-19 06:33:11 sure. you can go to www.python.org and compile it yourself 2021-02-19 06:33:22 we do not release RC packages of python 2021-02-19 06:33:41 the very few RC packages we have in the repo are special 2021-02-19 06:34:33 so the answer is, you'll get python 3.8.8 when python 3.8.8 final is released 2021-02-19 06:41:36 bob17: if your concern is the CVE-2021-3177, fixes should be landing for that today 2021-02-19 06:45:31 Yep, that's exactly my concern. Is there a way to track those fixes? 2021-02-19 07:25:06 Hi all, 2021-02-19 07:25:07 porting the edge version. We very much want to share our results with the community. 2021-02-19 07:25:07 Alpine Linux new platform mips64el support? 2021-02-19 07:25:07 If you want to experience the Alpine Linux 3.11 for mips64el, you can visit alpine.loongnix.org 2021-02-19 07:25:07 We have ported Alpine Linux 3.11 to Loongson 3a4000 (mips64el), and we are in the process of 2021-02-19 07:25:07 Or you can use docker pull loongnix/alpine:3.11 2021-02-19 07:25:07 We are very happy to provide Loongson machine to the community as the builder of mips64el 2021-02-19 07:25:08 platform. Can tell me the address to mail the Loongson machine to the community? 2021-02-19 07:26:00 Ariadne: Hi 2021-02-19 09:08:43 Hi, I have some musl issues i guess. Any easy sulution for this? https://pastebin.com/J7Q2Fxsx 2021-02-19 09:08:58 Do I need to patch the code? 2021-02-19 09:21:44 morning 2021-02-19 09:21:52 chenguoqi: hi! 2021-02-19 09:22:28 chenguoqi: sorry for not responding to your email :-( I think what you did with mips64el is very cool! 2021-02-19 09:25:06 Jenkler: if you expect its musl related you can also try in #musl 2021-02-19 09:26:09 Jenkler: i doubt pthread_getname_np is implemented in musl. the _np suffix means "non-portable" iirc 2021-02-19 09:26:44 Jenkler: i think you may need have a look at the code, and refactor it to not use that non-portable function 2021-02-19 09:32:03 ncopa, ok thanks. 2021-02-19 09:32:32 i'd start with reporting it upstream 2021-02-19 09:32:42 clandmeter, I will try to ask in musl too 2021-02-19 09:59:32 ncopa: I think we need new releases for 3.10, 3.11 and 3.12 due to the openssl CVE: #12445 2021-02-19 10:00:03 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12445 2021-02-19 10:19:10 yes, thats why i started to work on update the kernels on those branches 2021-02-19 10:19:36 i think updating kernels was a mistake... seems to be more work than expected 2021-02-19 10:27:57 drdb-lts, right? 2021-02-19 10:41:44 and linux-rpi on aarch64 2021-02-19 10:44:05 error: pasting ")" and "60" does not give a valid preprocessing token 2021-02-19 10:44:19 chenguoqi: hi 2021-02-19 10:45:09 chenguoqi: what would be more ideal is if loongson itself can host the machine. i don't plan to visit my colo space for several months so would not be able to get it up until then otherwise 2021-02-19 10:45:33 chenguoqi: i also think that reworking mips64el as loongson-oriented with hardfloat makes more sense than what we have now 2021-02-19 10:45:44 since we know loongson CPUs will always have a working FPU :) 2021-02-19 11:21:56 i messed up the linux-rpi 5.4.99 kernel merge 2021-02-19 11:22:03 does not build on aarch64 now 2021-02-19 16:16:40 someone please merge !18519 at your convenience :) 2021-02-19 17:15:41 skarnet, everything good with skalibs problem now? :) 2021-02-19 17:32:42 dalias: I haven't heard from people who had the problem, so I figure it's solved :D 2021-02-19 17:33:53 :) 2021-02-19 17:46:40 https://justine.lol/asanlinux/index.html an interesting Alpine fork 2021-02-19 18:03:41 what about that unsafe stuff with suid and ASAN? 2021-02-19 18:05:11 I thought ASAN was considered to be unsafe for general use in production for this reason 2021-02-19 18:05:51 https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html 2021-02-19 18:06:01 => https://www.openwall.com/lists/oss-security/2016/02/17/9 2021-02-19 18:06:38 sam_: read the page further 2021-02-19 18:06:54 oh sorry, I thought I looked for mentions! 2021-02-19 18:07:28 I take the point -- if the tunables are dropped, it should be OK 2021-02-19 18:07:30 thanks jvoisin 2021-02-19 18:08:15 very interesting 2021-02-19 18:09:17 sam_, upstream ASan library is NOT usable with suid 2021-02-19 18:09:39 it might be usable with removal of the env var stuff 2021-02-19 18:09:40 not sure 2021-02-19 18:09:57 i would tend not to trust it unless the diagnostic output were also replaced with simple trap 2021-02-19 18:10:01 "We intend to address any such concerns by using a trimmed-down runtime without the bells and whistles for release builds. For an example of a freestanding ASAN runtime needing fewer than a thousand lines of code" 2021-02-19 18:10:03 I think they're going to use their own library 2021-02-19 18:10:08 that's what I was wondering too though 2021-02-19 18:11:19 dalias: unfortunately, a simple trap would kinda defeat the purpose, since the goal is to get the bugs fixed 2021-02-19 18:11:36 ? 2021-02-19 18:11:51 having a nice stacktrace makes it easier to report bugs 2021-02-19 18:11:51 why would the bug not get fixed when it traps? 2021-02-19 18:12:00 you just run under gdb (or run gdb on the core file if that's your thing) 2021-02-19 18:12:06 there's also going to be an interesting susceptibility to DoS where not necessarily seriously exploitable bugs become more serious 2021-02-19 18:12:11 but that's worth it in the long run, I guess 2021-02-19 18:12:23 dalias: no need for gdb when you have a trace 2021-02-19 18:12:25 jvoisin: "Lastly, to safeguard against scenarios where binaries are crashing so often that the system isn't functional, we intend to add a feature to htop that lets the system administrator flip a bit in a process that causes it to go into log mode rather than crash mode." 2021-02-19 18:12:32 sorry, that was meant for sam 2021-02-19 18:12:40 of do have super-large core-dumps (looking at you, apache2+php+whatever) 2021-02-19 18:13:06 ikke: man I'm not reading well enough today 2021-02-19 18:13:13 too much computers 2021-02-19 18:13:50 jvoisin, the problem is that introspective reporting is unsafe and external observation is (or can be made) safe 2021-02-19 18:14:06 it's really frustrating that the ppl making these tools do not understand that 2021-02-19 18:14:16 I'm well aware 2021-02-19 18:14:26 but I think that the goal here is more to find bugs than not getting pwned 2021-02-19 18:17:09 I guess those 2 go hand in hand :) 2021-02-19 18:17:38 well, I'm ok with having some crashes from time to time running on my preprod 2021-02-19 18:17:50 if it's helping me to make my prod better™ 2021-02-19 18:20:12 i dont see why you need automatic trace printing to find bugs. it might accelerate getting a good bug report slightly 2021-02-19 18:20:24 at the expense of doing dangerous stuff at crash time 2021-02-19 18:20:38 from my experience, most sysadmins have no clue about debugging 2021-02-19 18:20:51 (albeit I didn't work with the birghtest I think) 2021-02-19 18:21:00 then just give them a framework for automating external reporting 2021-02-19 18:21:16 so having a copy/pasteable stacktrace that can be showed into a github issue is nice 2021-02-19 18:21:31 make their systemd or whatever automatically run a sandboxed trace on crashed processes 2021-02-19 18:51:21 so, i test built the 5.4.99 kernel and all our 3rd party modules on x86_64 and pushed it. but apparently drbd does not build on 32 bit arches 2021-02-19 18:51:55 oof 2021-02-19 18:51:55 due to: ERROR: "__udivdi3" [/home/buildozer/aports/main/drbd-lts/src/drbd-9.0.27-1/drbd/drbd.ko] undefined! 2021-02-19 18:51:55 ERROR: "__divdi3" [/home/buildozer/aports/main/drbd-lts/src/drbd-9.0.27-1/drbd/drbd.ko] undefined! 2021-02-19 18:52:08 arm kernels has same problem 2021-02-19 18:52:27 ERROR: "__aeabi_ldivmod" [/home/buildozer/aports/main/drbd-lts/src/drbd-9.0.27-1/drbd/drbd.ko] undefined! 2021-02-19 18:52:27 ERROR: "__aeabi_uldivmod" [/home/buildozer/aports/main/drbd-lts/src/drbd-9.0.27-1/drbd/drbd.ko] undefined! 2021-02-19 18:52:50 problem is that gcc does some optimization for division of 64bit values 2021-02-19 18:53:03 those symbols are apparently provided by gcc 2021-02-19 18:53:08 libgcc 2021-02-19 18:53:20 which is disabled for kernel builds 2021-02-19 18:53:42 instead, it seems that a do_div() should be used instead 2021-02-19 18:54:03 the problem though is to find exactly *where* in the code 2021-02-19 18:54:42 i tried to revert back to drbd 9.0.22 but that fails to build with the 5.4.99 kernel 2021-02-19 18:55:25 so i reverted back to 5.4.84 kernel in my dev env, and found out that problem was introduced between 9.0.25 and 9.0.26 2021-02-19 18:55:40 9.0.25 builds with 5.4.84 kernel. 9.0.26 doesnt 2021-02-19 18:55:55 but 9.0.25 does not build with the 5.4.99 kernel 2021-02-19 18:56:19 so i kinda have to find the commit that introuce the the lack-of-do_div 2021-02-19 18:56:24 so i tried to git bisect 2021-02-19 18:56:31 but 2021-02-19 18:57:14 ./drbd-kernel-compat/gen_compat_patch.sh: line 12: spatch: command not found 2021-02-19 18:57:14 ./drbd-kernel-compat/gen_compat_patch.sh: line 45: hash: spatch: not found 2021-02-19 18:57:14 INFO: not trying spatch-as-a-service because you are trying 2021-02-19 18:57:14 to build DRBD from a git checkout. Please install a suitable 2021-02-19 18:57:14 version of coccinelle (>1.0.8) or try building from a 2021-02-19 18:57:15 release tarball. 2021-02-19 18:57:26 so build from release tarball works 2021-02-19 18:57:39 bu build from git requires something called coccinelle 2021-02-19 18:57:52 which needs ocaml to build 2021-02-19 18:57:57 which we dont have on x86 2021-02-19 18:58:05 so im stuck 2021-02-19 18:58:17 blegh 2021-02-19 18:58:18 how is your weekend going? 2021-02-19 18:58:24 oh 2021-02-19 18:58:42 its the voice here in 2mins and my wife is asking me to stop work 2021-02-19 18:59:03 im giving up 2021-02-19 18:59:04 ah yes, The Voice, the best reason to stop working :D 2021-02-19 18:59:07 :D 2021-02-19 18:59:13 yeah 2021-02-19 18:59:28 "why is there no new alpine docker image to fix the CVEs"? 2021-02-19 18:59:36 "The Voice" 2021-02-19 18:59:38 "because the Voice jst started" 2021-02-19 18:59:39 :D 2021-02-19 19:00:30 ok have a nice weekend everyone! 2021-02-19 19:00:33 You too 2021-02-19 19:00:36 you too! 2021-02-19 19:00:51 I guess we could run coccinelle on x86_64 . 2021-02-19 19:01:51 if someone happens to find the commit between 9.0.25 - 9.0.26 that does a division using / instead of do_div, (or a modulo using %) please let me know 2021-02-19 19:01:54 https://github.com/LINBIT/drbd/commits/drbd-9.0 2021-02-19 19:02:02 now its The Voice! 2021-02-19 19:14:10 ncopa: !18213 2021-02-19 19:17:43 ncopa: https://github.com/LINBIT/drbd/commit/21b9f1ff29b2ea49ab1213df3381bdbcb98699de t 2021-02-19 19:17:45 this is older 2021-02-19 19:17:54 9.0.17 2021-02-19 19:18:10 but I don't find any commits after that do anything with do_div 2021-02-19 22:35:20 dalias: fwiw systemd already does this. sometimes. but the path is not very optimized, i think it needs to buffer the whole core dump in memory at least once, possibly twice 2021-02-19 22:36:16 ncopa: shouldn't you be able to find this with objdump -d? 2021-02-19 22:36:49 on what? 2021-02-19 22:37:02 the ko (with suitable kconfig opts) 2021-02-19 22:37:16 I have reproduced 2021-02-19 22:37:19 it 2021-02-19 22:37:25 That commit says it should have fixed that issue 2021-02-19 22:37:29 but seems like a regression? 2021-02-19 22:38:08 i think the problem is that some commit *doesn't* use do_div, not that it does 2021-02-19 22:38:33 right, in a different place 2021-02-19 22:52:41 https://github.com/LINBIT/drbd/commit/e595bfc635e9ec02192720c2095407aae2ed5976#diff-fe9c0ca1b8ae1c1907992ad46b5833267cd0f322cf8414b2170ce9050b04ad86R5766 2021-02-19 23:36:04 but isn't that just moving it around 2021-02-19 23:36:47 also i assume HZ is divisible by 10 so this shouldn't emit a real division instruction 2021-02-20 00:41:43 https://kodi.tv/article/kodi-190-matrix-release 2021-02-20 06:53:25 https://unix.stackexchange.com/questions/635108/how-can-i-make-an-alpine-package-conflict-with-another-alpine-package 2021-02-20 07:12:53 answered 2021-02-20 07:13:12 (note that this is the offtopic channel, there is #alpine-linux) 2021-02-20 07:14:31 confused, this one says "For discussion of Alpine Linux development and developer support. 2021-02-20 07:15:09 where does it say that? 2021-02-20 07:15:13 https://wiki.alpinelinux.org/wiki/Alpine_Linux:IRC 2021-02-20 07:15:49 just sounds like this is the right chan from the docs, but I'm new here. 2021-02-20 07:15:54 oh, my bad, I thought somehow this was #alpine-offtopic 2021-02-20 07:15:56 anyway, thanks for answering and welcome to unix.se 2021-02-20 07:16:07 it's still early :) 2021-02-20 07:16:09 got ya. confused me there 2021-02-20 07:24:28 This is also super obnoxious "Do not run abuild as root" 2021-02-20 07:25:44 I wouldn't think that wuld be a very meaningful error, unless you were actually on the metal. In this case. I'm just in a new user namespace/container. So it's reporting UID=0 even though I'm a regular user with no capabilities 2021-02-20 07:25:49 not sure if that's a bug or desired. 2021-02-20 07:26:58 still desired, it prevents an APKBUILD from accidentaly trying to modify the system (for example when you forgot to provide DESTDIR to make install) 2021-02-20 07:28:22 EvanCarroll: and note that root in docker is root on the host unless you remap UIDs 2021-02-20 07:29:04 I'm using user namespaces. 2021-02-20 07:29:18 podman run as non-root, runs as a user and remaps for me. 2021-02-20 07:29:59 there is a -F argument to override this check if you must 2021-02-20 07:30:46 if it helps, there is an alpinelinux/build-base image that already has a user setup 2021-02-20 07:32:07 not sure what the point is just spin up and tear down a container a volume map in my aports repo, https://github.com/EvanCarroll/alpine-packaging-image 2021-02-20 07:32:22 but I guess it would skirt the -F stuff 2021-02-20 07:44:02 does alpine still use gitlab? 2021-02-20 07:45:21 Hey I am trying to start lxc but it says “/var/lib/lxc/name/rootfs is on a tmpfs and ALLOW_TMPFS is not set” 2021-02-20 07:47:48 jackaraa: is your rootfs tmpfs? 2021-02-20 07:47:59 Yes 2021-02-20 07:49:10 I made a persist file 2021-02-20 07:49:21 And its mounting at boot 2021-02-20 07:49:43 I could use it, or is there a better solution 2021-02-20 07:50:04 oh no 2021-02-20 07:50:27 jackaraa: a better solution is to mount at least /var/lib/lxc on a persistent disk 2021-02-20 07:50:48 apk add /root/packages/testing/x86_64/perl-singlethreaded-5.32.1-r0.apk 2021-02-20 07:50:48 ERROR: unable to select packages: 2021-02-20 07:50:48 perl-singlethreaded-5.32.1-r0: 2021-02-20 07:50:48 breaks: perl-singlethreaded-5.32.1-r0[!perl] 2021-02-20 07:50:49 satisfies: world[perl-singlethreaded> its because you have something depending on perl itself 2021-02-20 07:51:20 so !perl constraint cant be satisfied 2021-02-20 07:51:38 getting that error now when I add the conflicts (depends='!perl'; provides="perl=$pkgver") 2021-02-20 07:51:56 anyway jart was talking on twitter about doing a friendly fork of alpine with address sanitizer 2021-02-20 07:52:09 Ariadne: yes, it was linked here 2021-02-20 07:52:30 so i proposed maybe this can be done inside alpine instead of forking (: 2021-02-20 07:52:43 Ariadne: yeah, I was thinking the same 2021-02-20 07:52:48 Ariadne: I don't though, at least not that I see. 2021-02-20 07:53:04 yes! here's context https://justine.lol/asanlinux/index.html 2021-02-20 07:53:39 i think there is value to having ASan binaries in alpine if we can make the performance impact minimal 2021-02-20 07:54:08 i got asan working with cosmopolitan libc. i imagine it'd be quite easy to get working with musl libc too. the hard part, i imagine, is the multitude of packages that are going to break when these memory protection features are enabled 2021-02-20 07:54:22 heh 2021-02-20 07:54:31 i think the first step is to get asan supported in musl 2021-02-20 07:54:58 EvanCarroll: Perhaps the combination of conflicts and provides on the same package does not work 2021-02-20 07:55:19 Ariadne: isn't that landing in LLVM12? 2021-02-20 07:55:37 (no idea how it propagates to gcc's libsanitizer, though) 2021-02-20 07:55:46 how does alpine currently implement c++ stl? does it use libgcc's libstdc++? because if so, libsanitizer is part of that same library 2021-02-20 07:55:55 yes, we use libstdc++6 2021-02-20 07:56:15 though we are considering swapping to clang for the improved diagnostics and security features 2021-02-20 07:56:20 ikke: that's what I was thinking. 2021-02-20 07:56:25 however, kernel isn't quite ready yet for this 2021-02-20 07:57:13 ikke: by using fstab and can you give an example? 2021-02-20 07:59:20 I just tried running `cc -fsanitize=address -o hello hello.c` and got `cannot find libasan_preinit.o` so i'm assuming alpine would need to be repackaged somehow to provide that. let me see if i can get it working with musl-cross-make where i have more familiarity 2021-02-20 08:00:23 yes, probably a good starting point 2021-02-20 08:00:33 we will also need to write up a system change proposal 2021-02-20 08:00:45 outlining the risks/benefits to the proposal 2021-02-20 08:01:21 got a link to a template? i'll fill one out now 2021-02-20 08:04:02 my main concern is that, unlike spectre/pie/ffortify-source/etc. which carry single-digit performance impact, the slowdown of enabling ASAN for the whole distro by default is double digit. however that gains you the best security in the industry. would alpine linux users want to pay that cost? or would they prefer in be shipped as part of a separate tree somehow where you have to change a config file 2021-02-20 08:04:08 to get asan-hardened binaries 2021-02-20 08:05:30 Ikke 2021-02-20 08:10:02 jart: https://lists.alpinelinux.org/~alpine/devel/%3Ceb865f14-75ae-491b-179c-f6dc9f5df49%40dereferenced.org%3E is an example of one 2021-02-20 08:13:31 hwasan could help with performance although seems like it's limited to aarch64 for now 2021-02-20 08:17:29 jart: the point of the system change proposal is to figure out what option makes the most sense 2021-02-20 08:17:48 there's a few options i could see 2021-02-20 08:17:53 ikke: how to do it properly ? With fstab 2021-02-20 08:17:54 - do asan by default, period 2021-02-20 08:18:08 - offer a repo with some subset of packages as asan 2021-02-20 08:18:14 - offer a full set of asan repos 2021-02-20 08:21:08 the question ultimately will be where is the sweet spot 2021-02-20 08:21:24 I'm pretty sure ASAN is a very bad idea for production 2021-02-20 08:22:15 It's only meant as a debugging tool, it makes things way slower and may introduce its own set of vulnerabilities since it's very complex 2021-02-20 08:22:20 that's a good point, most people probably don't want their services randomly crashing (: 2021-02-20 08:22:39 however, that's not the value i see from offering a set of packages that are ASan enabled 2021-02-20 08:23:01 the point to me, is more about finding problems proactively, that can then result in security fixes in the distro 2021-02-20 08:23:27 Instead of offering ASAN enabled packages, we should just (finally) offer -dbg subpackages for all packages 2021-02-20 08:23:28 so for example, if someone opts in to running the asan'd packages, and reports a bug with the backtrace output it generates 2021-02-20 08:23:36 That'd be a necessity for ASAN anyway 2021-02-20 08:23:39 Cogitri: yes 2021-02-20 08:23:56 And IIRC ASAN can just be LD_PRELOADed 2021-02-20 08:24:03 interesting 2021-02-20 08:24:24 i think you are right :) 2021-02-20 08:24:48 so then, perhaps the best solution would be to ensure all packages have debug syms 2021-02-20 08:24:57 Yup, that'd be great 2021-02-20 08:25:14 and then if you want to switch ASAN on for everything, document how to do that 2021-02-20 08:25:30 Many issue reports don't have backtraces because users have no clue how to make -dbg packages which is unfortunate 2021-02-20 08:26:06 it would be nice to write a coredump collector which automatically sends the core along to something that can do the backtrace and open a bug :) 2021-02-20 08:26:16 In an ideal world we'd have something like Fedora's thingie where if you attach to a program it tells you what debuginfo packages to install, that's pretty neat to not have missing symbols 2021-02-20 08:26:23 Ariadne: well, they're corecollector 2021-02-20 08:26:31 But it won't open a bug for you 2021-02-20 08:26:38 yeah, corecollector plus some other infrastructure 2021-02-20 08:26:59 Isn't the idea that you'd rather want you service crashing than continue in an inconsistent state? 2021-02-20 08:27:15 ikke: I don't think Alpine supports prompting the user to resolve conflicting packages. 2021-02-20 08:27:27 EvanCarroll: we totally do 2021-02-20 08:27:29 I thikn it just raises notices and the user has to del one, and add the other 2021-02-20 08:27:32 oh 2021-02-20 08:27:36 yes 2021-02-20 08:27:52 but apk is designed to not do anything destructive automatically 2021-02-20 08:28:07 ikke: Depends, but ASAN really isn't meant for production, it's like running everything in gdb (but a lot worse in both performance and security) because it could crash at some point 2021-02-20 08:28:17 every package manager I've used asks the user which one they want. 2021-02-20 08:28:18 we think it is better to error than to run a bizzaroworld transaction that removes the libc like aptitude has done in the past ;) 2021-02-20 08:28:20 Cogitri: the proposal is not to run full ASAN 2021-02-20 08:28:56 "We intend to address any such concerns by using a trimmed-down runtime without the bells and whistles for release builds. For an example of a freestanding ASAN runtime needing fewer than a thousand lines of code" 2021-02-20 08:29:17 also, the idea is to allow you to be able to turn it on or off 2021-02-20 08:29:24 possibly per service 2021-02-20 08:29:45 basically think like PaX but on steroids 2021-02-20 08:29:48 "Lastly, to safeguard against scenarios where binaries are crashing so often that the system isn't functional, we intend to add a feature to htop that lets the system administrator flip a bit in a process that causes it to go into log mode rather than crash mode. " 2021-02-20 08:29:53 and with better control 2021-02-20 08:30:51 But the potential performance impact might be an issue 2021-02-20 08:31:07 yeah i think if this is integrated into the base distro, it needs to have an on/off switch 2021-02-20 08:31:18 Something like setenforce 2021-02-20 08:31:21 yep 2021-02-20 08:33:12 Before we do any of that we really do need something like corecollector but a bit fancier. I think if we do automatic reporting it'll probably be villainized, but at least things like logging the backtrace to syslog and stuff should be pretty trivial (corecollector already does that) 2021-02-20 08:33:30 But I'm a bit afraid that most folks will just notice their stuff crashing at random and move on 2021-02-20 08:33:47 i think if it is opt-in, it is not a problem 2021-02-20 08:33:57 Fair 2021-02-20 08:36:45 EvanCarroll: the problem is, people choose one without thinking 2021-02-20 08:37:01 and then libc is no longer installed 2021-02-20 08:37:38 not proposing solutions, but instead presenting information to the user to infer her own solution, is a design feature of apk 2021-02-20 08:38:21 apk could do a nicer job at error reporting though, trying to do `apk upgrade -a` and nothing is upgraded because some package holds something back isn't really useful and makes the user think they're on the latest version 2021-02-20 08:39:04 yes no doubt 2021-02-20 08:39:12 that is something that is planned to be improved for apk3 :) 2021-02-20 08:39:29 Yay :) 2021-02-20 09:00:40 "< Cogitri> [ASAN is] only meant as a debugging tool" <-- says who? asan is basically the same thing as mmap() style memory protection, except it operates at byte granularity rather than 4096-byte page granularity. 2021-02-20 09:02:20 ASAN can also be implemented in hardware on Aarch64 and Google is starting to use it for Android https://android-developers.googleblog.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html 2021-02-20 09:04:20 libsanitize on the other hand, might not be production worthy since it's tunable via all these environmental variables which might break setuid binaries. solution: i wrote a trimmed down <1kloc runtime we could use. see https://github.com/jart/cosmopolitan/blob/9f149e1de3cb42cb58cfa39ed2b307c7efdb7c58/libc/intrin/asan.c#L43 2021-02-20 09:07:50 Wasn't aware of the proposal so I thought ASAN == libasan 2021-02-20 09:09:29 basically the only thing the -fsanitize=address flag does, is each time a pointer x is dereferenced, it generates a couple more asm opcodes to check that a bit is set at the address x>>3 2021-02-20 09:10:10 the libsanitize runtime basically wraps mmap() / malloc() / free() / etc. so that when you request a piece of memory, it'll map the shadow region and poison/unpoison the shadow bits 2021-02-20 09:10:14 that's basically it 2021-02-20 09:11:04 if you don't have a runtime, then the gcc / clang generated code fails with a segfault because the shadow region (addresses 2mb through 14tb on x86 pie) aren't mapped 2021-02-20 09:13:56 the way virtual memory works is very similar. for example, on x86_64, each time a pointer is dereferenced your cpu under the hood will perform a page table crawl through a four-layer data structure: register char (*(*(*(*ram)[512])[512])[512])[4096] asm(cr3) -- asan is in some respects much less expensive than what intel is already doing, and they'll most likely have hardware support soon since arm did 2021-02-20 09:14:02 it 2021-02-20 09:33:14 i think it is really interesting 2021-02-20 09:35:41 great to hear! the best part of ASAN is it's basically what Google uses to find all the zerodays in Chrome before the bad guys do 2021-02-20 09:36:27 when ASAN was first invented, it enabled them to find 300 buffer / stack / heap / etc. overflows, use after free, etc. in Chromium 2021-02-20 09:38:36 If ASAN is built into a Linux distro, then in log mode ASAN will let us know how at risk our systems are. It will tell you if the small subset of Linux code that your system actually needs has memory bugs in it. Ideally once we fix all the bugs we can use crash mode, which will stop many APTs in their tracks 2021-02-20 09:40:47 maybe i will eventually get around to using pointer offsets in my radix tree implementation 2021-02-20 09:41:54 :) 2021-02-20 09:42:11 (jart probably has forgotten that conversation, it was almost a decade ago) 2021-02-20 10:22:32 I noticed the other day that github project release pages have rss feeds, if you just add .atom, user/project/releases.atom, pretty convenient 2021-02-20 10:29:40 Yup, it's pretty neat, I used that for some time to subscribe to that via email 2021-02-20 10:29:56 Unfortunately Gitlab doesn't have that yet (or at least it didn't last time I checked) 2021-02-20 10:30:09 Fortunately GNOME's ftp-release-list cuts it now 2021-02-20 10:47:46 gitlab seem to have feeds for just the project page itself 2021-02-20 10:48:06 Yup, which also includes issues etc. 2021-02-20 10:48:15 yeah 2021-02-20 11:00:33 Marian: so I'm thinking of making pipewire-pulse provide pulseaudio after all. Right now I'm running into race conditions were sometimes pipewire-pulse is running and sometimes PulseAudio is, I'd like to get rid of that 2021-02-20 11:02:46 Maybe we can install a conf file to `/etc/pipewire/media-session.d/` that'll exec pipewire-pulse when installed, to replace the manual enabling in `/etc/pipewire/pipewire.conf` 2021-02-20 11:12:38 PureTryOut (matrix.org) Sound good to me. 2021-02-20 11:13:28 Good, I'm making the chances locally right now and will MR so we can test it 2021-02-20 11:14:44 It'd be nice to be able to do `apk del pulseaudio` and still have audio with PulseAudio requiring applications afterwards 😃 2021-02-20 11:17:31 Ok got a Pulseaudio free system now. Let's see if I still have audio after rebooting lol 2021-02-20 11:19:37 ``` 2021-02-20 11:19:37 [E][000000035.864641][pulse-server.c:909 do_set_client_name()] pulse-server 0x7f5a2f562300: failed to connect client: Host is down 2021-02-20 11:19:37 ``` 2021-02-20 11:19:50 Hmm that might be why Pulseaudio was running, pipewire-pulse fails to launch for me 🤔 2021-02-20 11:30:02 Hmm anything pipewire fails to launch besides the main executable, they all say "Host is down" 2021-02-20 11:45:39 Found the problem. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/758 They yet again made breaking config change without telling anyone, so I had to replace the existing config for the `.apk-new` one... 2021-02-20 11:46:29 But problem: putting the exec stuff in a file in `/etc/pipewire/media-session.d` does not work 😢 Marian might you know some other way to autostart it? We could try the `/etc/xdg/autostart` thing I guess and hope it figures out itself what order stuff needs to start in? 2021-02-20 11:47:51 Or maybe we should just stick to a message in a `.post-install` that tells you how to configure it 2021-02-20 12:13:41 PureTryOut (matrix.org) Sticking with the message is the most versatile approach. I'm using a very bare metal desktop environment and just put pipewire in the shell script that is executed on start up. 2021-02-20 12:13:41 Others could profit from /etc/xdg/autostart or from /etx/pipewire/media-session.d. It certainly doesn't hurt anyone, providing it: Either your desktop supports it and you're happy having it, or 4 KiB of memory in disk get wasted - which probably nobody running a full desktop cares about. 2021-02-20 12:44:11 regarding asan as hardening, i think asan devs themselves say it is not intended for that: https://www.openwall.com/lists/oss-security/2016/02/18/4 2021-02-20 12:45:27 according to them, it is mainly useful for accidentally finding bugs, not protecting against dedicated attackers 2021-02-20 12:46:14 in part due to the env vars issue but also others (see mail) 2021-02-20 12:47:10 Hello71: Wasn't that addressed already? 2021-02-20 12:47:38 Hello71: they will not use libsanitize, they will use a different implementation thats a lot smaller 2021-02-20 12:48:31 yes but does the algorithm itself work against dedicated attackers 2021-02-20 12:49:08 I'm not sure the primary goal is to detect dedicated attackers 2021-02-20 12:49:25 "We like the idea of doing ASAN as a Linux distro, because it brings a community mandate for developers to more broadly engage from the bottom-up in finding security bugs and ensuring they get fixed." 2021-02-20 12:49:57 doesn't asan increase memory use a lot? 2021-02-20 12:50:53 "This incurs a cost of 1/8th additional memory required. " 2021-02-20 12:51:10 ikke: yes, that's useful, but I think we need to be clear about that 2021-02-20 12:51:35 travankor: it increases virtual memory substantially 2021-02-20 12:51:46 Just like we now use mallocng, which is also a lot more strict and detects issues 2021-02-20 12:51:51 but so does go, java, etc 2021-02-20 12:53:19 mallocng doesn't have a lot of downsides though (afaik) 2021-02-20 12:53:40 yes, was not talking about the resource usage 2021-02-20 12:54:45 The goal of the Sanitized Linux is to find memory bugs and fix them, so we can have a safer more trustworthy Linux for everyone, that's able to work well on recently developed memory tagged hardware. 2021-02-20 12:58:37 One of the things that's made it hard for ASAN to gain traction in the FOSS world is the libgcc and compiler-rt runtimes for it need to schlep in the whole C++ STL and it's super hard to build. Having a lean and mean runtime and prebuilt binaries can fix that. 2021-02-20 13:03:22 With Cosmopolitan Libc I managed to make static ASAN binaries as small as 36kb. The past few hours I've been working ot port ASAN to Musl Libc. 2021-02-20 14:07:21 mps are you there? 2021-02-20 15:39:52 ifupdown-ng bridge not works, the installed script use stub instead linux 2021-02-20 15:39:53 https://github.com/ifupdown-ng/ifupdown-ng/tree/19a5a671eb168b10380af725c584ca7391b5476e/executor-scripts 2021-02-20 15:41:16 the installed bridge only has a depend handler, the linux script handle the create and pre-up https://github.com/ifupdown-ng/ifupdown-ng/blob/19a5a671eb168b10380af725c584ca7391b5476e/executor-scripts/linux/bridge 2021-02-20 15:47:16 according to this https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/ifupdown-ng/APKBUILD#L22 , the result is correct, but how can I make bridge work in interfaces ? 2021-02-20 15:48:50 ok, install the bridge, I thought ifupdown-ng support bridge and bond natively 2021-02-20 15:49:15 Yes, for now bond and bridge packages are still required 2021-02-20 15:50:10 "ifupdown-ng has native vlan support, so the vlan package is no longer required and can be uninstalled. The bridge and bond packages are still required. " 2021-02-20 15:50:17 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#Switching_from_busybox_ifupdown_to_ifupdown-ng 2021-02-20 15:52:11 thanks, missed that,after upgrade mostly reading the ifupdown-ng doc 2021-02-20 16:25:33 Ariadne: It's actually worse than that, imho. 2021-02-20 16:25:38 ERROR: unable to select packages: 2021-02-20 16:25:38 perl-singlethreaded-5.32.1-r0: 2021-02-20 16:25:38 breaks: perl-singlethreaded-5.32.1-r0[!perl] 2021-02-20 16:25:38 satisfies: world[perl-singlethreaded> I'm not sure how a module can break itself. 2021-02-20 16:25:52 or how to even read that. 2021-02-20 16:26:28 "perl-singlethreaded> that's right. but why is unable to install the package? 2021-02-20 16:27:25 I mean iirc the reason because the package depends=!perl and provides=perl 2021-02-20 16:27:48 but that actually what I want. Becuase I want packages that depend on perl to be satisified by the replacement. 2021-02-20 17:36:13 EvanCarroll: try provides=perl=9999 2021-02-20 17:36:21 EvanCarroll: instead of depends=!perl 2021-02-20 17:36:44 (this is a workaround, clearly this is an edge case in our solver that we did not think of yet) 2021-02-20 17:48:07 Ariadne: well if I do that then I assume `apk add perl` becomes a noop rather than a reversion? 2021-02-20 17:49:01 The ideal iterface would be `apk add perl perl-singlethread` conflicts, `apk add perl` `apk add perl-singlethread` provides for removal/install and vise-versa would provide for removal/install. 2021-02-20 17:49:57 since we're talking about one stupid langauge with two different builds, because only single-threaded perl works with the perl compiler and single-threaded perl is ~10% faster. 2021-02-20 17:50:02 and more memory efficient 2021-02-20 19:04:24 How do i change dns and keep it? Every boot it resets it 2021-02-20 19:04:55 jackaraa: I assume you use a dhcp server? 2021-02-20 19:05:12 I do, but i try to config it not to 2021-02-20 19:05:17 Using static 2021-02-20 19:05:26 I want to use static i mean 2021-02-20 19:06:00 dns-nameservers in /etc/network/interfaces wont do anything when i do service networking restart 2021-02-20 19:06:05 ikke^ 2021-02-20 19:07:29 set RESOLV_CONF=no in /etc/udhcp/udhcp.conf 2021-02-20 19:08:13 Thank you 2021-02-20 19:23:34 I have two more things i need help with, dnscrypt-proxy (how to get it in use instead of regulary dns service) and i want to unmount boot up media after it has loaded persist 2021-02-20 19:26:57 Sorry, i will be connected now 2021-02-20 19:27:24 I have two more things i need help with, dnscrypt-proxy (how to get it in use instead of regulary dns service) and i want to unmount boot up media after it has loaded persist 2021-02-20 19:29:24 I know nothing about dnscrypt-proxy 2021-02-20 19:29:35 but to be able to unmount the bootmedium, you need to stop the modloop service 2021-02-20 19:31:19 It runs as tmpfs 2021-02-20 19:33:55 yes 2021-02-20 19:34:03 make sure you have all the kernel modules you need loaded 2021-02-20 19:34:07 then stop the modloop service 2021-02-20 19:34:10 then you can unmount it 2021-02-20 19:35:20 I would like to mount as ro and then mount persist and then umount ro 2021-02-20 19:35:36 btw, this is the dev channel, a better channel for these kinds of questions is #alpine-linux 2021-02-20 19:36:47 Thanks 2021-02-21 01:03:00 oi maybe someone in here can share some more info on this? https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#Deprecation_of_Berkeley_DB_.28BDB.29 2021-02-21 01:03:16 i was looking for maybe a mailing list discussion 2021-02-21 01:04:19 seems like most distros have a db5.3 package that is frozen at the non-agpl version so i wonder why alpine has taken a different tack? 2021-02-21 01:06:00 i think alpine is more forward-thinking whereas other distros just want it to work / want to maintain backwards compatibility 2021-02-21 01:06:29 also, if you can, do 2021-02-21 01:06:41 most useful programs support non-bdb backends anyways 2021-02-21 01:07:27 aw 2021-02-21 01:07:37 for some reason i thought alpine was going for stability 2021-02-21 01:08:17 was there any discussion / debate on the mailing list? 2021-02-21 01:09:10 it's not very stable to use packages not receiving bug fixes :) 2021-02-21 01:09:47 that seems stable to me 2021-02-21 01:09:55 bug fixes are change 2021-02-21 01:10:03 obviously nonsense 2021-02-21 01:12:35 removing packages that are not maintained, thus forcing changes downstream, is obviously the opposite of stability 2021-02-21 01:13:43 i'm just explaining why it's reasonable to move to get rid of it 2021-02-21 01:14:25 reasonable if you prefer forward thinking over stability 2021-02-21 01:15:36 if you want "never change anything, use ancient upstream versions, and aggressively and incorrectly backport patches", try debian. or better, windows 2021-02-21 01:16:41 mhm 2021-02-21 01:16:54 in this case alpine is at the opposite extreme 2021-02-21 01:17:25 "small. simple. secure." you'll note that stagnant is not in the list 2021-02-21 01:19:20 we do in fact have stable releases as well 2021-02-21 01:19:43 just because docker kids install random crap from edge doesn't mean it's the right thing 2021-02-21 01:20:03 whatever i just wanted to see if there had been any discussion before the decision was made, or if the person who made the decision was here 2021-02-21 01:20:21 i wanted a simple distro that would let me use nvi over vim is all 2021-02-21 01:21:02 ok 2021-02-21 01:21:34 seems like it was leo but he is not here 2021-02-21 01:21:46 i am told that some people use busybox vi 2021-02-21 01:22:25 "use" is a stretch when it doesnt have regex 2021-02-21 01:27:11 well it's definitely less popular than ash 2021-02-21 01:30:03 i mean nvi2 is actively maintained and they still depend on db 2021-02-21 01:30:11 plenty of reasonable developers expect it to be available 2021-02-21 01:33:03 cough python2 cough 2021-02-21 01:35:38 has alpine removed packages that depend on python2? 2021-02-21 01:37:28 also note that alpine is shifting support to python 3, not removing python entirely 2021-02-21 01:49:09 python2 will be removed entirely, we are just blocked by Chromium and FIrefox 2021-02-21 01:58:04 yes 2021-02-21 01:58:10 python is still allowed though 2021-02-21 01:58:55 python3 (and future python4+) yes 2021-02-21 02:02:35 but not db 2021-02-21 02:08:06 lol 2021-02-21 02:52:44 Do anyone know how to acutally use dnscrypt-proxy while started? I don’t 2021-02-21 02:53:16 I’ve started the service but it still uses /etc/resolv.conf 2021-02-21 02:59:15 you modify /etc/resolv.conf to point to 127.0.0.1 or whatever 2021-02-21 03:34:18 sam_: thanks 2021-02-21 03:34:29 np! 2021-02-21 03:34:38 Do you know how to apply the right rules in nftables? 2021-02-21 03:40:19 I'm sorry, I don't -- I use dnscrypt-proxy quite heavily, but I just set up resolv.conf appropriately. I guess you want to block all other DNS traffic? 2021-02-21 04:37:33 How do i fix lxc error: not set to ALLOW_TMPFS 2021-02-21 04:47:02 I guess i have to edit the kernel? 2021-02-21 04:47:14 How do i change a setting in the kernel? 2021-02-21 06:58:46 In Custom_Kernel under Configuring kernel I find it difficult to figure out where src/linux-VER is and also how where one should run make menuconfig from, I’m trying to change the kernel on rpi 4 and have copied /boot/config-rpi4 to aports/main/linux-rpi 2021-02-21 07:14:26 . 2021-02-21 07:23:49 bleb: removal of db is discussed few times before it is 'removed' 2021-02-21 07:24:44 . 2021-02-21 07:24:57 Can someone help me please? 2021-02-21 13:40:10 bleb, sabotage linux does value stability. in fact i made everything so far working with py2 (which is not going to be removed) so i don't need to install py3 2021-02-21 14:24:47 [19:02] but not db 2021-02-21 14:24:59 tell oracle to give us db with an acceptable license 2021-02-21 14:26:14 alternatively fork the last non-AGPL and maintain it and demonstrate it is not vulnerable to the CVEs that lead to db’s removal 2021-02-21 14:27:14 it is unfortunate that db was removed but we did not have any choice 2021-02-21 14:27:47 we could continue to ship a vulnerable version or effectively make every package that used it AGPL 2021-02-21 14:31:05 we kept db5.3 for as long as we could. there were CVEs and no upstream fixes other than “upgrade to new db” 2021-02-21 14:31:29 alpine does not negotiate with terrorists (oracle) 2021-02-21 14:35:03 [18:58] python is still allowed though 2021-02-21 14:35:40 actually new packages dependent on python2 will be rejected, and we are working to drop or update packages to use python3 2021-02-21 15:15:51 we could continue to ship a vulnerable version or effectively make 2021-02-21 15:15:55 every package that used it AGPL 2021-02-21 15:16:23 what do you mean by "effectively AGPL"? 2021-02-21 15:16:55 aren't all alpine packages already effectively AGPL, because the source is distributed? 2021-02-21 15:19:20 or do you mean something else? 2021-02-21 15:20:01 programs with gpl compatible licenses can be linked against agpl libraries 2021-02-21 15:21:20 does alpine just have a policy against agpl/gplv3 libraries, because they want people to be able to use gpl-incompatible licenses without worrying about the license of the libraries they link against? 2021-02-21 15:21:58 Ariadne: ^ 2021-02-21 15:26:14 15:16 aren't all alpine packages already effectively AGPL, because the source is distributed? 2021-02-21 15:26:16 uwotm8 2021-02-21 15:27:41 so what does that phrase mean 2021-02-21 15:28:57 ?????????????????? 2021-02-21 15:29:14 yes, alpine has a policy against agpl libraries 2021-02-21 15:29:30 agpl *programs* are fine, however 2021-02-21 15:30:01 we do not wish to saddle end users with obligations to follow AGPL 2021-02-21 15:30:21 anyway, i have given you your options. db will never be returned to alpine 2021-02-21 15:30:40 if you want to fork db 5.3, and figure out the CVE mess, we will be glad to carry your fork, if it is under an acceptable license 2021-02-21 15:31:03 if you wish to modify nvi2 to use a different database library, we will gladly carry nvi2 2021-02-21 15:31:16 there is nothing further to debate, the decision is final 2021-02-21 15:33:42 great 2021-02-21 15:33:45 is this policy documented 2021-02-21 15:34:44 it has been discussed numerous times in bugs and on the mailing list 2021-02-21 15:34:48 i'm not your personal search engine 2021-02-21 15:34:55 if you wish to spend any more of my time, you can pay me 2021-02-21 15:39:02 besides, you're concern trolling anyway 2021-02-21 15:39:13 alpine 3.13 still has db-5.3 in the repo 2021-02-21 15:39:25 we are just not accepting new packages which depend on it 2021-02-21 15:39:59 nothing is stopping you from building nvi2 for yourself right now. 2021-02-21 15:40:14 but it won't be accepted in the repo. 2021-02-21 15:40:32 so, that gives you 3 options. 2021-02-21 15:41:11 we are just not accepting new packages which depend on it 2021-02-21 15:41:14 this isnt quite right 2021-02-21 15:41:20 it is exactly right 2021-02-21 15:41:21 alpine is also removing packages that depend on it 2021-02-21 15:41:27 nvi depended on it and was removed 2021-02-21 15:41:49 nothing stops you from taking the APKBUILD from 3.12 and building it yourself 2021-02-21 15:41:57 yup, glad we agree 2021-02-21 15:42:25 either way, if you want the situation to change 2021-02-21 15:42:29 organize a fork of db 5.3 2021-02-21 15:42:33 and fix the CVEs 2021-02-21 15:43:14 or change nvi2 to not depend on oracle db 2021-02-21 15:43:29 GNU dbm has a mostly compatible API 2021-02-21 15:43:40 using a db for text storage is a weird decision anyway, especially if it is an external package 2021-02-21 15:44:42 my main concern is that a common package that can be found almost every distro was removed (alpine is not _just_ not accepting new packages that depend on db) 2021-02-21 15:45:25 on the other hand it would be good to document alpine's policy against agpl libraries (and does it extend to gplv3?) 2021-02-21 15:45:34 no, it is specific to AGPL 2021-02-21 15:45:44 if i can find the discussion you are referring to i will link it from here https://wiki.alpinelinux.org/wiki/Package_policies 2021-02-21 15:45:58 but so far i haven't found it with google or the sourcehut search 2021-02-21 15:46:18 the actual policy discussion re: AGPL libraries may have occured in IRC :) 2021-02-21 15:46:20 i forget 2021-02-21 15:46:32 but dropping db5.3 has been discussed on the mailing lists 2021-02-21 15:46:38 and the rationale *is* documented there 2021-02-21 15:47:09 also that wiki page is quite old 2021-02-21 15:47:26 an actual packaging manual was being worked on to replace it 2021-02-21 15:47:31 i don't know what happened with that though 2021-02-21 15:48:05 bleb: the problem is that AGPL imposes restrictions on end users to provide source code to their users 2021-02-21 15:48:32 bleb: so, say you install postfix, and AGPL oracle db. now you have to give your end users the source code for your postfix setup. 2021-02-21 15:48:57 this is not a position we want to put users in 2021-02-21 15:50:03 that makes sense 2021-02-21 15:50:18 fwiw we might relax that for packages such as nvi2 2021-02-21 15:50:37 but we want to start from clean slate before we make any decision like that 2021-02-21 15:50:43 that would also make sense, since the rationale only applies to network code 2021-02-21 15:51:02 but the postfix issue is a moot point because the license is not gpl compatible 2021-02-21 15:51:13 yes, the problem is right now we will inadvertantly infect networking packages 2021-02-21 15:51:17 huh? 2021-02-21 15:51:21 postfix is BSD license innit 2021-02-21 15:51:26 naw 2021-02-21 15:51:34 oh, i see. eclipse 2021-02-21 15:51:41 well, either way, it was using bdb 2021-02-21 15:51:49 and we cant mix AGPL with it anyway 2021-02-21 15:52:09 but basically, that's the rationale 2021-02-21 15:52:19 we don't want to cause some docker user to shoot themselves in the foot 2021-02-21 15:52:32 and we don't want to shoot direct users in the foot either 2021-02-21 15:55:05 the db5.3 cves are also a non issue with non-network code fwiw 2021-02-21 15:55:42 so removing a non-network program because it depends on a deprecated db with cves makes even less sense 2021-02-21 16:01:49 its because we want to drop db package 2021-02-21 16:01:51 as i said 2021-02-21 16:02:40 do you know where what was discussed 2021-02-21 16:02:50 i'm not finding it on alpine-devel or alpine-aports 2021-02-21 16:02:57 s/what/that/ 2021-02-21 16:02:57 bleb meant to say: do you know where that was discussed 2021-02-21 16:03:42 your journey begins at https://gitlab.alpinelinux.org/alpine/aports/-/issues/7978 2021-02-21 16:03:47 which is now declassified 2021-02-21 16:03:51 just for you!!!! 2021-02-21 16:04:53 i also declassified the other issue, just for you 2021-02-21 16:05:26 the point is, db 5 is abandoned, db 6 and later are not under an appropriate license 2021-02-21 16:08:56 classified issues huh 2021-02-21 16:09:18 can't tell if joke 2021-02-21 16:09:24 not joke 2021-02-21 16:09:41 almost all unresolved security issues are classified. we declassify them as they are resolved 2021-02-21 16:10:08 but if you follow that, you'll understand how we came to the conclusion to just deprecate db5 2021-02-21 16:10:27 that call was made 6 months ago, so i have slept since then 2021-02-21 16:14:53 we don't want to play this game with bdb5 2021-02-21 16:15:14 once there is a clean slate, we can consider the AGPL version 2021-02-21 16:15:29 but introducing AGPL version right now will create a lot of problems 2021-02-21 16:15:47 that is why the goal is to remove db entirely 2021-02-21 16:16:03 then and only then, can we carefully consider db18 or whatever 2021-02-21 16:16:09 i guess, an alternative 2021-02-21 16:16:12 i cant find where the decision was made 2021-02-21 16:16:15 am i just an idiot 2021-02-21 16:16:27 bleb: i am pretty sure, the final decision was made in irc 2021-02-21 16:16:38 bleb: no you're not 2021-02-21 16:16:39 last authoritative looking thing is "Conclusion back then was that the issues was unlikely affecting db 5, but difficult to get any information that proves anything either direction." 2021-02-21 16:16:45 and "I think we need more exact information." 2021-02-21 16:17:02 unlikely affecting db 5 2021-02-21 16:17:11 look, you're arguing for no reason 2021-02-21 16:17:28 if you want nvi2 back, then package db18 2021-02-21 16:17:33 your fault for piquing my curiousity 2021-02-21 16:17:50 we can put a restriction on it that says no network code is allowed to link to that package 2021-02-21 16:17:54 that solves the problem 2021-02-21 16:18:16 until somebody sponsors a network application that links to it anyway 2021-02-21 16:18:21 at which point i cry 2021-02-21 16:19:11 my honest impression is that it should be left to upstream to protect users, and publicize the fact that they link against an agpl program 2021-02-21 16:19:43 if postfix hypothetically wanted to keep depending on db, they should change their license to agpl so that people know 2021-02-21 16:20:05 postfix switch to lmdb :P 2021-02-21 16:20:15 yeah i know 2021-02-21 16:20:37 is there any example of a network application that depends on db but hasnt switched to agpl? 2021-02-21 16:20:57 no, they have all been dropping the db dependency 2021-02-21 16:21:53 so alpine is killing db just in case they also ship a network program that is developed by people who are so negligent or incompetent that they keep the db dependency but dont update their license or inform their users 2021-02-21 16:22:11 alpine is killing db because we don't know if db5 is vulnerable or not 2021-02-21 16:22:18 and nobody has packaged db18 2021-02-21 16:22:29 seems like the better choice would be to not ship any network program that links against agpl without publicizing that they are effectively agpl 2021-02-21 16:23:23 not aware of any examples of this fwiw, since it would be pretty egregious 2021-02-21 16:23:29 the better choice would be to reject oracle's attempt to monetize berkeley db 2021-02-21 16:23:48 since that's why they changed the license 2021-02-21 16:24:07 you can get db18 under a non-AGPL license if you want to pay :) 2021-02-21 16:24:13 part of that attempt seems to have been vague CVEs that make people think db5 is vulnerable :) 2021-02-21 16:24:26 we do not know if it is or not 2021-02-21 16:24:40 you never know 2021-02-21 16:25:01 yes, so we choose the option that makes the vulnerability scanners shut up (: 2021-02-21 16:25:16 it can't complain about BDB if it's not there 2021-02-21 16:25:50 i think, also, that all of those CVEs against db6/db18 are part of why nobody has wanted to package it 2021-02-21 16:25:55 if a CVE says version 6.whatever or lower are effected, but the vulnerability is only replicable on version 6+, that seems like FUD 2021-02-21 16:26:19 the details to replicate the vulnerability are... not very helpful usually on these 2021-02-21 16:26:36 if you look at the CVEs on the first bug 2021-02-21 16:26:38 it's all vague crap 2021-02-21 16:26:41 what a garbage state of affairs 2021-02-21 16:27:02 i mean, bluntly, our decision to drop BDB is very much motivated by the feeling that we're being jerked around here 2021-02-21 16:27:13 very useful to fuck with the free software community and force them to stop using code that is no longer controlled by huge companies 2021-02-21 16:27:15 as i said earlier, "alpine does not negotiate with terrorists (oracle)" 2021-02-21 16:28:12 however, for packages which are not network-facing, i think db18 would be acceptable 2021-02-21 16:28:23 i am just very concerned that somebody makes a mistake, and suddenly PHP is now AGPL 2021-02-21 16:28:47 which is the mistake i think Oracle's lawyers are salivating while thinking about 2021-02-21 16:29:10 lets say PHP is AGPL, what does that mean from a legal standpoint 2021-02-21 16:29:29 i have significant paralegal experience and i couldn't tell you what the endgame of that would be 2021-02-21 16:29:38 AGPL is unfortunately underspecified 2021-02-21 16:29:47 perhaps the call is coming from inside the house, and the CVE database is also an instrument of jerking people now (with the vagueness and lack of replicability you mentioned) 2021-02-21 16:30:26 but for example, lets say PHP becomes effectively AGPL due to AGPL's copyleft 2021-02-21 16:30:38 does that mean the PHP scripts themselves are now AGPL? 2021-02-21 16:30:40 how did oracle gain the ability to make vulnerability scanners complain about versions of db that they didnt develop and they dont control? 2021-02-21 16:30:42 libglade finally removed 2021-02-21 16:31:07 bleb: Oracle bought Sleepycat when DB5 was still maintained 2021-02-21 16:31:17 ah 2021-02-21 16:31:21 then they rewrote it 2021-02-21 16:31:28 and called it 2021-02-21 16:31:34 Oracle Berkeley DB 11g version 6 2021-02-21 16:31:44 i wish i were kidding, but that was literally what they called the rewrite 2021-02-21 16:31:50 11g? 2021-02-21 16:31:54 yeah 2021-02-21 16:31:58 11g 2021-02-21 16:32:03 groovy 2021-02-21 16:32:28 no i don't know why Oracle puts 11g or 18i or whatever on their products 2021-02-21 16:32:40 but if the code was rewritten, is it not dishonest to say vulnerabilities apply to the original version? 2021-02-21 16:32:54 we don't know to what extent the code was rewritten 2021-02-21 16:32:58 it was not a total rewrite 2021-02-21 16:33:28 i mean, yes, we could figure out to what extent the code was rewritten 2021-02-21 16:33:41 but figuring out this entire mess takes away time that could be spent doing actually useful work 2021-02-21 16:34:12 determining the extent to which oracle are a terrorist organization is not really productive work for us 2021-02-21 16:34:48 the other thing is 2021-02-21 16:34:50 if it wasn't oracle 2021-02-21 16:34:56 we might have been a little more lax on this 2021-02-21 16:34:59 but 2021-02-21 16:35:12 oracle + AGPL + "you can pay for non-AGPL license" 2021-02-21 16:35:23 i mean, we don't want to expose our users to that 2021-02-21 16:35:26 that's just antisocial 2021-02-21 16:35:45 i mean sure, fuck oracle 2021-02-21 16:35:53 because clearly oracle are waiting for somebody to make a mistake and then sue the fuck out of them 2021-02-21 16:36:05 but it seems like all the useful code that still depends on db, depends on db5.3 2021-02-21 16:36:17 yes, but db5.3 is unmaintained 2021-02-21 16:36:47 so you have these CVEs that nobody knows for sure what exposure we actually have (could be zero, could be non-zero) 2021-02-21 16:37:01 and nobody is actually maintaining db5.3 2021-02-21 16:37:09 i mean there is the debian package 2021-02-21 16:37:10 https://metadata.ftp-master.debian.org/changelogs//main/d/db5.3/db5.3_5.3.28+dfsg1-0.8_changelog 2021-02-21 16:37:20 yes, we do similar patching 2021-02-21 16:37:28 that's not the same as real maintenance 2021-02-21 16:37:56 what would be real maintenance 2021-02-21 16:38:07 trying harder to figure out if the CVEs apply? 2021-02-21 16:38:07 actually forking the damn thing and assuming the role of new upstream ;) 2021-02-21 16:38:14 but in actual practice 2021-02-21 16:38:30 i'm willing to accept that the CVEs don't apply if there will be somebody to fix them if it turns out they do 2021-02-21 16:38:37 if that makes sense 2021-02-21 16:39:08 or in other words, if somebody forked it, i am willing to assume they did their due diligence and that there is no applicable CVEs until proven otherwise 2021-02-21 16:39:59 so if the goal is to save db5, then perhaps the best path forward is to get people in a room talking so that we can come up with a plan to cut oracle out of the picture entirely 2021-02-21 16:40:37 are distro packagers categorically not maintainers in that sense 2021-02-21 16:40:46 i'm talking about a proper upstream 2021-02-21 16:41:56 as in, actually forking db5 2021-02-21 16:42:00 and actually improving it 2021-02-21 16:42:17 idk if redhat or debian ever backport security patches 2021-02-21 16:42:24 if they do, that seems like the important part 2021-02-21 16:42:29 if that were to happen, then there would not be any reason to continue deprecation of db5 2021-02-21 16:42:37 lol 14 CVEs 2021-02-21 16:42:39 changing or "improving" it as you say shouldn't be a requirement IMO 2021-02-21 16:42:53 how many security issues can you have in a key-value store :D 2021-02-21 16:42:58 beyond bug fixes and security patches 2021-02-21 16:43:01 skarnet: that is my point yes 2021-02-21 16:43:01 skarnet: indeed 2021-02-21 16:43:06 is there a buffer overflow in every other 2 lines or what 2021-02-21 16:43:30 like clearly db6 is crap 2021-02-21 16:43:38 just seeing the length of that list screams "throw it away and use something else" 2021-02-21 16:43:53 exactly 2021-02-21 16:43:58 which is why we deprecate bdb 2021-02-21 16:44:04 absolutely 2021-02-21 16:44:11 there are many other "something else" options 2021-02-21 16:45:15 bleb: anyway alpine is not interested in carrying berkeley db 5 for the next decade with no upstream 2021-02-21 16:45:31 oh well 2021-02-21 16:45:35 no upstream is music to my ears 2021-02-21 16:45:39 means "peace and quiet" 2021-02-21 16:46:10 qmail all the way 2021-02-21 16:46:13 yeah it also means idiots complaining that db5 is vulnerable to db6 bugs because oracle doesn't clarify 2021-02-21 16:46:20 looks like alpine doesnt package qmail anyway so 2021-02-21 16:46:40 we used to 2021-02-21 16:46:56 i think it got orphaned and then eventually dropped entirely 2021-02-21 16:47:07 caving to those idiots gives oracle more power, just saying 2021-02-21 16:47:32 we're not caving, we're attempting to boycott berkeley db (: 2021-02-21 16:48:32 and to be clear, i'm not anti-AGPL 2021-02-21 16:48:38 i just know a con when i see one 2021-02-21 16:48:57 if you wanna use AGPL, go for it 2021-02-21 16:49:22 i participated in over a dozen conference calls and hundreds of IRC meetings about AGPLv3 2021-02-21 16:49:36 (when the FSF was drafting it) 2021-02-21 16:49:48 i guess qmail didn't have enough bugs to keep the interest of a maintainer, so the maintainer left and the non-bugged code could not be left unsupervised 2021-02-21 16:50:21 any package in alpine cannot be included in a release without a maintainer 2021-02-21 16:50:24 shouldnt the goal be to have as much code as possible free of bugs and thus not requiring maintenance 2021-02-21 16:51:14 i appreciate your enthusiasm for qmail, but policy is policy 2021-02-21 16:51:16 :P 2021-02-21 16:51:16 i guess once you get there you don't need a packager 2021-02-21 16:51:59 packages are for code that has not achieved bug-freeness and this requires a shepherd to keep patching things 2021-02-21 16:52:13 s/this/thus/ 2021-02-21 16:52:13 bleb meant to say: packages are for code that has not achieved bug-freeness and thus requires a shepherd to keep patching things 2021-02-21 16:52:39 hmm, maintainers are responsible for more than just bugfixes in alpine 2021-02-21 16:52:48 they act as a point of contact for inquiries too 2021-02-21 16:53:06 yeah 2021-02-21 16:53:19 but it makes sense that this infrastructure is only justified if the code is still being developed 2021-02-21 16:53:39 no, i mean inquiries like "how do i deploy this" 2021-02-21 16:53:41 :P 2021-02-21 16:54:12 i guess db4 and db5 have reached this state as well 2021-02-21 16:54:31 i am very skeptical 2021-02-21 16:54:54 we actually considered forking db5 2021-02-21 16:54:56 already 2021-02-21 16:55:02 and found the code to be... well 2021-02-21 16:55:05 not great 2021-02-21 16:57:53 there's abstraction layers on abstraction layers 2021-02-21 16:57:57 its a mess 2021-02-21 16:58:05 db4 is probably better 2021-02-21 16:58:28 db5 had already gotten somewhat oracle'd 2021-02-21 17:05:00 i was thinking of making a port for ex-vi 2021-02-21 17:05:12 but this whole maintainer thing doesnt seem necessary for that either 2021-02-21 17:11:41 guess i could make my own apk repo to make it easy to share and install on different hosts 2021-02-21 17:11:55 qmail is a nightmare to package, depending on the features you want, the amount of patches you want included, etc. 2021-02-21 17:12:09 I've packaged it for Adélie and am not willing to do it again 2021-02-21 17:12:36 and I say that as a qmail lover 2021-02-21 17:13:07 is that just because it's impossible to please everyone 2021-02-21 17:13:46 well anyway, happy trolling 2021-02-21 17:13:49 i have shit to do 2021-02-21 17:14:00 happy shitting 2021-02-21 17:14:38 bleb: no, it's because qmail hasn't had a reliable upstream in 25 years and the e-mail landscape has become hellish 2021-02-21 17:15:15 and to keep qmail (even netqmail) up with the requirements of today's e-mail management is a hell of a lot of work 2021-02-21 17:16:46 i want to use it to experiment with possible alternatives to the current morass 2021-02-21 17:17:32 like only accepting emails from a friends list or something 2021-02-21 17:17:35 I've wanted to rewrite qmail for a while, but when I finally felt that I had the necessary skills to do so (say, 5-6 years ago) I had lost all interest in MTAs because today's problems are fundamentally different from 2000's problems and require a lot of compromise I wasn't willing to do 2021-02-21 17:18:26 oh, it works, I mean it's still my MTA, but there's a difference between making it work for yourself and for a distro 2021-02-21 17:18:36 i mean the whole email ecosystem has been sabotaged by companies who want to extract value from it, or push you to more lucrative messaging systems 2021-02-21 17:19:27 even with a "modern" setup you still get spam in your inbox from any website that you type your email into 2021-02-21 17:19:30 that's true for IM, but for original e-mail that's not the real problem 2021-02-21 17:20:02 yeah who would have thought companies you give your e-mail to would actually send you mail 2021-02-21 17:22:08 skarnet: try opensmtpd? 2021-02-21 17:22:23 it is to be expected with no rules against spam or enforcement 2021-02-21 17:22:42 fcc can't even prevent scam robo calls 2021-02-21 17:22:58 not enough resources 2021-02-21 17:24:25 jvoisin: I'm not looking for advice 2021-02-21 17:25:35 my bad 2021-02-21 17:25:54 especially not if this advice implies replacing a piece of software that has worked flawlessly without any change for 25 years by one that had a fkn remote code execution exploit *last year* 2021-02-21 17:26:17 got em 2021-02-21 17:29:49 bleb: they have enough resources, they just have regulatory capture by the telcos that don't want to implement rigorous source checks 2021-02-21 17:30:26 well whoevers job it is to enforce rules against spam calls, doesnt have enough resources 2021-02-21 17:30:49 iirc there is still a place you can report spam calls 2021-02-21 17:31:23 skarnet: so instead of using a mail server that had a remote code execution vulnerability last year, you're deciding to use a mail server that had a remote code execution vulnerability last year? 2021-02-21 17:31:36 https://lwn.net/Articles/820969/ 2021-02-21 17:32:19 is it smartass day or what? 2021-02-21 17:32:55 there may be other reasons to use or not use opensmtpd or qmail, but "had a fkn remote code execution exploit *last year*" seems like a particularly bad differentiator 2021-02-21 17:33:11 dalias: sorry that i appear to have drug us into a twitter thread with somebody who has nothing better to do than debate misogynistic MAGA chuds 2021-02-21 17:34:23 skarnet: yeah i basically went with postfix because it seemed to be the least bad option for what i wanted it to do 2021-02-21 17:34:40 Hello71: I've been aware of this since 2005 and have configured my server so it wouldn't be vulnerable 2021-02-21 17:34:49 which is primarily virtual domains backed by postgresql 2021-02-21 17:35:13 since i am hosting several domains on my infrastructure 2021-02-21 17:36:16 Hello71: for opensmtpd it's particularly hilarious because OpenBSD rejected qmail back then, because they didn't like its architecture model, then years later opensmtpd proceeded to adopt the same model 2021-02-21 17:37:05 again, i'm not saying opensmtpd is *good*, i'm saying your previous argument does not hold water 2021-02-21 17:38:39 i just assume all MTAs are insecure garbage 2021-02-21 17:39:12 Hello71: have you even read the article you linked? I'm tired of the same shit 2021-02-21 17:39:50 new shit, same as the old shit 2021-02-21 17:40:26 no, I mean the "got ya"s and arguing for the sake of arguing 2021-02-21 17:40:42 this is your claim: "replacing a piece of software [...] by one that had a fkn remote code execution exploit *last year*". when pointed out that your preferred software also "had a fkn remote code execution exploit *last year*", your response is... "yes but i configured it in a specific non-default manner so that it would be not susceptible to this specific vulnerability" 2021-02-21 17:42:18 *that's* gotcha games if i ever saw one 2021-02-21 17:43:34 that's not a gotcha, it's a nuh uh 2021-02-21 17:43:59 are you going to drop it or do I really need to explain to you, at the risk of being even less fun than you at parties, what exactly the difference is between a parsing overflow and an assumption that things fit into 32-bit arrays? the difference between a documented assumption that can be made true by configuration and a bug that cannot be worked around? 2021-02-21 17:44:29 between software that has 1 flaw like this in 25 years and software that has 3 CVEs in 1 year? 2021-02-21 17:44:48 between knowing what you're talking about and trying to make a useless point? 2021-02-21 17:44:58 https://en.wikipedia.org/wiki/Moving_the_goalposts 2021-02-21 17:44:58 [WIKIPEDIA] Moving the goalposts | "Moving the goalposts (or shifting the goalposts) is a metaphor, derived from goal-based sports, that means to change the criterion (goal) of a process or competition while it is still in progress, in such a way that the new goal offers one side an advantage or disadvantage...." 2021-02-21 17:45:28 I fucking hate playing to see who's the bigger idiot, I always lose 2021-02-21 17:46:09 please consider you made your point and won the argument, go have your wank somwehere private, and never talk to me again 2021-02-21 17:54:28 skarnet, fwiw i find the qmail bug worse because parser errors are an honest mistake anyone can make. the qmail one was djb doubling down on a wrong programming practice (using int where size_t is needed) that was reported, shown to be exploitable in the wild 15 years ago, & rejected because of djb's ego 2021-02-21 17:55:48 i'll just continue to use postfix because its what i know 2021-02-21 17:56:08 hmm, maybe i should ask random internet angry men what qmail is 2021-02-21 17:56:12 that could be a bit 2021-02-21 17:56:59 dalias: djb had the humility to refuse to parse because he knew parser errors were really hard to avoid. :P 2021-02-21 17:58:01 I agree he was wrong on the int/size_t thing and should have fixed it, but I disagree it's worse 2021-02-21 18:02:36 depends if you care about the personality of the programmer, or the actual security of the code 2021-02-21 18:03:21 humility is one thing djb sorely lacks 2021-02-21 18:03:35 especially in aftermath of JA case 2021-02-21 18:04:10 before i just found him technically annoying. after that i found him a Bad Person too 2021-02-21 18:05:05 julian assange? 2021-02-21 18:06:26 lol there are two horrible JA's 2021-02-21 18:06:47 ah appelbaum 2021-02-21 18:06:53 jacob appelbaum 2021-02-21 18:07:33 at least assange needs to be protected for the sake of freedom and humanity 2021-02-21 18:07:39 whatever you think of his personality 2021-02-21 18:07:43 *eyeroll* 2021-02-21 18:07:46 no 2021-02-21 18:08:09 assange was a grifter who took credit for other people's sacrifices 2021-02-21 18:08:19 like i said he needs to be protected 2021-02-21 18:08:32 no 2021-02-21 18:08:46 he's not being imprisoned and extradited for "taking credit for other people's sacrifices" 2021-02-21 18:09:06 if you think that justifies US govt over reach you are a useful idiot 2021-02-21 18:09:26 i understand the argument about the principle. OTHER PEOPLE from ACTUALLY VULNERABLE GROUPS are already subject to such overreach. this is not setting any new precedent 2021-02-21 18:10:04 i don't play by the aclu playbook 2021-02-21 18:10:28 when someone powerful and deplorable is finally the target of injustice others face all the time, my reaction is not to stand up for them 2021-02-21 18:11:15 people need to stop letting the media delete their brain because a person is bad 2021-02-21 18:11:15 i'll save my energy for the ones who don't have money and powerful ppl defending them already and whom saving actually benefits society 2021-02-21 18:11:59 all saving assange will do is help him assist in more neofascist takeovers 2021-02-21 18:12:19 "assist" 2021-02-21 18:12:27 sounds like your brain has been deleted :( 2021-02-21 18:12:35 Please move to -offtopic 2021-02-21 18:12:51 oh i didnt realize this wasn't already -offtopic, sorry 2021-02-21 18:12:57 :) 2021-02-21 18:13:20 will shut up 2021-02-21 18:13:21 It was my mistake to not intervene earlier 2021-02-21 18:13:55 well you're not in ot so i can't ask about the existing precedents im not aware of 2021-02-21 18:13:59 normally skarnet and folks arguing about djb stuff is a -ot topic :) 2021-02-21 18:14:38 bleb, well i don't have any desire to continue this conversation with someone who's not already part of an -ot community i'm close with, so... 2021-02-21 18:14:39 which i am genuinely curious about and would despirately like to know about 2021-02-21 18:14:46 sorry 2021-02-21 18:14:48 I normally don't argue about djb stuff but I hate it with a passion when someone tries gotchas with me 2021-02-21 18:14:54 that fucking sucks 2021-02-21 18:14:56 skarnet, :) 2021-02-21 18:14:57 i care about this stuff 2021-02-21 18:14:59 oh well 2021-02-21 18:16:24 so much for actually caring about those people who are not julian assange 2021-02-21 18:17:37 !18586 one of the last big blockers for python2 2021-02-21 18:20:08 Should be enough to remove py-bluez, py-pillow and py-setuptools 2021-02-21 18:20:28 also, should we remove the provides="py-module" and replaces="py-module" 2021-02-21 18:20:37 ? 2021-02-21 18:21:12 my 2c, cost is minimal so keep around for another cycle 2021-02-21 18:21:33 yes, the cost is nothing it just allows people to install py3-module by installing py-module 2021-02-21 18:21:52 as far as I remember they have existed for several cycles (here understood as alpine stable releases) 2021-02-21 18:21:57 Yeah, just keep it around a bit 2021-02-21 18:22:12 now that asshat is trying to harass me in pm, *sigh* 2021-02-21 18:24:03 and add a note to alpine release notes 2021-02-21 18:24:44 i guess we could do it for 3.14, "py-* is officially deprecated, make sure you change to py3-*. py-* will be removed in 3.15" something 2021-02-21 18:28:42 makes sense 2021-02-21 18:29:15 Hmm, how could I capture the output of a command (for example with tee), but also know when that command has failed? 2021-02-21 18:29:22 posix sh does not support pipefail 2021-02-21 18:29:44 in bash, pipefail or > >(tee) 2021-02-21 18:29:53 no convenient way in posix sh 2021-02-21 18:30:53 only simulate > >(tee) with fifos and background processes, which really sucks. or i guess you can do a subshell like (cmd; echo $? > cmdexit) | tee 2021-02-21 18:31:13 either way you need a temporary file, but i think the latter is less painful 2021-02-21 18:33:25 ikke, imo it's not too hard 2021-02-21 18:33:49 put the output in a heredoc and end the heredoc *contents* with the exit code 2021-02-21 18:33:56 which you can then peel off 2021-02-21 18:34:13 or if you dont need a heredoc just a string 2021-02-21 18:34:26 foo=$(mycmd ; echo $?) 2021-02-21 18:34:28 or similar 2021-02-21 18:35:20 hm, that's true. you probably want printf '\n%s' $? though, in case the command output ends in a number 2021-02-21 18:35:37 foo=$(mycmd ; echo ,$?) ; code=${foo##*,} foo=${foo%,*} 2021-02-21 18:36:09 that also fixes the shell's mangling (removal) of final newlines from output if you don't want it to do that 2021-02-21 18:36:14 seems right, as long as you're ok with buffering the whole output 2021-02-21 18:36:56 It could pontially be large 2021-02-21 18:37:31 see if you can adapt the same idea to work with your constraints about buffering 2021-02-21 18:37:34 i suspect you can 2021-02-21 18:37:41 actually if you don't want to capture the output then just fiddle with fds 2021-02-21 18:38:00 but there's no way you're going to get the failure status without first reading (at least most of) the part of the output that is generated successfully 2021-02-21 18:38:14 because the process will only make limited forward progress until the pipe is read 2021-02-21 18:39:29 exec 3>&1; code=$(exec 4>&1; (cmd; echo $? >&4) | tee file /dev/fd/3 >/dev/null) 2021-02-21 18:40:09 <@ikke> Hmm, how could I capture the output of a command (for example with tee), but also know when that command has failed? 2021-02-21 18:40:38 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2021-02-21 18:40:54 i think you accidentally too much " " 2021-02-21 18:41:02 yes 2021-02-21 18:41:08 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2021-02-21 18:41:23 i <-'d the timestamp length but not my nick length 2021-02-21 18:41:47 i don't think "capture the output" means "to a shell variable" because "for example with tee" 2021-02-21 18:41:47 Usecase: in our CI, I want to capture the output of abuild -r and also other commands (that should still be written live to stdout), but I still need to know whether they succeeded or not 2021-02-21 18:44:14 script -c 'abuild -r' :p 2021-02-21 18:44:55 I also found https://github.com/cheusov/pipestatus 2021-02-21 18:45:48 yeah, that uses fd fiddling 2021-02-21 18:46:08 basically exec 3>&1; code=$(exec 4>&1; (cmd; echo $? >&4) | tee file /dev/fd/3 >/dev/null) but more general 2021-02-21 18:46:18 :) 2021-02-21 18:46:53 oh wait, you don't need /dev/fd. exec 3>&1; code=$(exec 4>&1; (cmd; echo $? >&4) | tee file >&3) 2021-02-21 18:47:26 https://github.com/cheusov/pipestatus/blob/master/pipestatus#L82 wat 2021-02-21 18:47:46 right. 2021-02-21 18:47:54 /dev/fd should not be needed for anything like this 2021-02-21 18:54:19 exec 3>&1; code=$(exec 4>&1; (cmd 3>&- 4>&-; echo $? >&4) | tee file >&3); exec 3>&- 2021-02-21 18:55:06 huh, apparently for extra confusion you can exec 3>x; exec 3<&- to close it 2021-02-21 18:57:45 https://gitlab.alpinelinux.org/mps/aports/-/jobs/329139#L671 2021-02-21 18:58:02 could someone help with this 2021-02-21 18:58:47 hmm, it goes only to 655 lines for me 2021-02-21 19:00:08 me too 2021-02-21 19:00:26 also this https://gitlab.alpinelinux.org/mps/aports/-/jobs/329139#L512 2021-02-21 19:00:41 'Illegal instruction (core dumped)' 2021-02-21 19:03:16 my advice would be "give up on edk2 and use binaries" 2021-02-21 19:06:20 Hello71: I don't understand, would you mind to explain a little, please 2021-02-21 19:06:29 ikke: do you also need to know the exit code of the consumer part of the pipeline? because the problem here is that $? only holds one exit code at a time 2021-02-21 19:06:53 (also that the shell doesn't know how to report the exit code of the producer part, but that can be worked around) 2021-02-21 19:06:56 skarnet: Not necessarily 2021-02-21 19:06:58 edk2 build system is a mess 2021-02-21 19:07:14 Hello71: heh, yes, already know this 2021-02-21 19:08:26 ikke: do you mind execline? execline -Pc 'pipeline -w { tee something something your consumer } producer' will run with the pid of producer :) 2021-02-21 19:08:46 (and pipe its output into whatever's inside the { }) 2021-02-21 19:20:09 hmm, the execline package does not have a binary called execline? 2021-02-21 19:24:20 skarnet: ? 2021-02-21 19:25:25 ikke: execlineb 2021-02-21 19:25:29 sorry, execlineb 2021-02-21 19:25:30 aha 2021-02-21 19:25:35 typo from me 2021-02-21 19:30:57 I think that can work 2021-02-21 19:31:56 cool :) 2021-02-21 20:34:37 maxice8: thank you for fixing 'ntpsec' on 3.13 working fine and on edge working fine too :) 2021-02-21 20:55:15 welcome 2021-02-21 21:27:34 incoming kodi upgrade and a bunch of added libretro and emulator packages, any day now I'll upgrade my retropie to alpine! 2021-02-21 21:27:58 and probably look at rpi issues in the process 2021-02-21 21:28:16 So many kodi addons 2021-02-21 21:28:29 wish kodi-games could all be compiled once 2021-02-22 10:42:47 morning 2021-02-22 10:43:05 i think i finally solved the drbd-lts thing on 32bit arches 2021-02-22 10:46:52 drbd on 32bit arches is pretty niche, but nice you solved it anyways. 2021-02-22 10:48:12 problem is we build the 3rd party module for our stable branches 2021-02-22 10:48:40 it also shows why we should avoid add 3rd party modules 2021-02-22 10:55:13 If we have something like dkms, we more easily avoid it 2021-02-22 11:00:20 could someone help with !18588 2021-02-22 11:01:21 hmm, algitbot didn't finished its coffee, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18588 2021-02-22 11:01:42 WIP: community/edk2: really upgrade by setting correct _realver 2021-02-22 11:02:36 it fails in call some python build.py, which I don't understand how it works 2021-02-22 11:03:37 besides illegal instruction error on x86_64 2021-02-22 11:06:58 btw, I booted armv7 netboot in uefi mode on x86_64 host and everything works (well) fine 2021-02-22 11:07:11 I had to use linux-edge-virt 2021-02-22 11:07:34 mps: the error is not very clear 2021-02-22 11:08:02 https://github.com/OP-TEE/optee_os/issues/842 2021-02-22 11:09:13 ikke: how you find so fast these things, I think you have internet in your back head 2021-02-22 11:09:40 I just searched for "build.py error 7000" 2021-02-22 11:12:05 ok, I will look how debian build 202011 edk2, but have to finish some other things in queue first 2021-02-22 11:14:48 would be nice if ncopa can post his recipe for building arm iso images, would like to build armv7 one to test it fully 2021-02-22 11:18:42 I think you should try strace -ff or dmesg (SIGILL should be logged) 2021-02-22 11:21:27 Hello71: I thought about using strace but didn't had time (and I think will not have in next days) 2021-02-22 11:22:10 dmesg seems easier 2021-02-22 11:23:53 it didn't show anything, I tried it when was error 2021-02-22 13:19:07 hi all, is there way to store changelog in apk? like %changelog in rpm specfile (returned by rpm -q --changelog)? 2021-02-22 13:19:41 No 2021-02-22 13:20:05 so only to put changelog to doc package? 2021-02-22 13:29:26 Hi, what does options="!check" # out of disk space (>35GB) mean ? 2021-02-22 13:29:47 !check ??? Should it not run check function? 2021-02-22 13:30:03 Seams that I can trigger it anyway with abuild check 2021-02-22 13:41:40 nm https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#check.28.29 2021-02-22 14:45:27 I get "FATAL: too large" for x86, x86_64 and armv7 !18213 2021-02-22 14:47:23 and see "packages/: found 42 matching files and directories" for those archs, compared to 21 for ppc64le and aarch64 (19 for s390x that has ocaml-lablgtk disabled due to rust) 2021-02-22 14:54:51 I triggered a re-run for x86_64, perhaps it was because I aborted a previous pipeline and it didn't clean up properly? 2021-02-22 15:11:12 nope 2021-02-22 16:29:25 i really need help with rust 2021-02-22 16:30:07 What's up? 2021-02-22 16:31:22 I am stuck with this musl error https://pastebin.com/iXRGz6jQ 2021-02-22 16:32:35 Found patches for mozjs60 - https://git.alpinelinux.org/aports/tree/main/mozjs60?h=3.12-stable 2021-02-22 16:32:59 but does not seam to be the issue. 2021-02-22 16:35:27 *sigh* this should be fixed to be conditional on existence of the nonstd function 2021-02-22 16:35:33 but it's a useless operation anyway 2021-02-22 16:35:41 just nopping it out would be fine 2021-02-22 16:37:28 Cogitri: you upgraded to rust 1.50 and it broke cross compilation again 2021-02-22 16:37:39 :/ 2021-02-22 16:38:20 this effort to make rustc work everywhere has taken my imposter syndrome and cranked it up not to 11 but to like 111 2021-02-22 16:38:37 the fact that i am not able to make this work is really fucking me up 2021-02-22 16:38:43 i am just being honest here 2021-02-22 16:39:12 Jenkler_: https://github.com/void-linux/void-packages/pull/28199/commits/ac246782076abbe172fdcf2223809db583ff5eb5 patches used in void 2021-02-22 16:39:17 and now, the net is closing in on us 2021-02-22 16:39:24 first python-cryptography, now curl 2021-02-22 16:39:53 ? 2021-02-22 16:39:57 using rust? 2021-02-22 16:39:58 yes 2021-02-22 16:40:00 uhg 2021-02-22 16:40:10 is it optional in curl? 2021-02-22 16:40:12 yes 2021-02-22 16:40:13 for now 2021-02-22 16:40:17 because curl is needed in ALL SORTS of places that rust is not available 2021-02-22 16:40:26 I don't see curl having a hard dependency on rust 2021-02-22 16:40:30 yes 2021-02-22 16:40:37 rust is available on like 5 archs 2021-02-22 16:40:38 i have put a restriction on curl that basically says do not enable rust components 2021-02-22 16:40:40 bagder is conservative in that regard 2021-02-22 16:40:42 curl runs on maybe 40 2021-02-22 16:40:59 ikke, :) 2021-02-22 16:41:33 i am so very tired 2021-02-22 16:41:38 Ariadne: I can imagine 2021-02-22 16:41:43 this has been literally 2021-02-22 16:41:50 ericonr, but that is not for mozjs60 2021-02-22 16:42:03 "CTARGET=mips64 abuild -r" --> wait 2 hours --> error 2021-02-22 16:42:17 "CTARGET=aarch64 abuild -r" --> wait 2 hours --> error 2021-02-22 16:42:20 Jenkler_: it's a commit removing the package, but it contains all the patches we used 2021-02-22 16:43:06 ericonr, but i need mozjs60 for mongodb to work 2021-02-22 16:43:12 !18213 2021-02-22 16:43:21 Jenkler_: before you waste any further time on this, mongodb will not be accepted into alpine as it is non-free 2021-02-22 16:43:31 i just want to make that clear (: 2021-02-22 16:43:55 if you need mongodb for your own personal use, carry on of course 2021-02-22 16:43:57 Jenkler_: and that is mozjs60, idk what more to day 2021-02-22 16:44:04 Ariadne, I know. But I am need mongodb to work with alpine 2021-02-22 16:44:04 but we wont ship SSPL packages 2021-02-22 16:44:05 ;) 2021-02-22 16:44:28 anyway you can just add a static_cast<> there 2021-02-22 16:44:55 should fix it 2021-02-22 16:45:02 !18213 2021-02-22 16:45:05 oh 2021-02-22 16:45:08 pthread_getname_np 2021-02-22 16:45:11 just rip that part out 2021-02-22 16:45:12 :P 2021-02-22 16:45:21 yes 2021-02-22 16:45:31 that's what i said :) 2021-02-22 16:45:37 Ariadne, Iam not a c++ coder 2021-02-22 16:47:15 i would assume alpine already has a patch for that, no? 2021-02-22 16:47:22 Jenkler_: well i am not a rustc bootstrapper but i have to do it anyway 2021-02-22 16:47:37 dalias: no, because normally autoconf detects its not implemented 2021-02-22 16:47:40 omni: do you have an idea how large the ocaml packages are? 2021-02-22 16:47:43 Ariadne, hehe 2021-02-22 16:50:00 ariadne, ah, so what did they do, hard-code a macro that says it exists? 2021-02-22 16:50:15 (they = mongodb or whoever) 2021-02-22 16:50:32 ikke, i would expect small, no? 2021-02-22 16:51:13 dalias: Well, for some reason gitlab says it's too large for it to be uploaded as artifacts 2021-02-22 16:51:30 ERROR: Uploading artifacts as "archive" to coordinator... too large archive 2021-02-22 16:52:34 dalias: probably 2021-02-22 16:52:40 But only on some platforms 2021-02-22 17:02:54 Ariadne: Do you have a branch with your current rust work somewhere? 2021-02-22 17:03:02 Can't really test the bootstrapping stuff otherwise 2021-02-22 17:09:20 Cogitri: it is literally aports master 2021-02-22 17:09:41 you just run sh bootstrap.sh aarch64 2021-02-22 17:09:43 then do 2021-02-22 17:09:48 CTARGET=aarch64 abuild -r 2021-02-22 17:09:52 in community/rust 2021-02-22 17:09:58 it should give you a cross-compiled rust 2021-02-22 17:10:15 also 1.50 is completely hosed for s390x anyway codegen wise 2021-02-22 17:14:00 Ah 2021-02-22 17:19:04 if you are on rust zulip 2021-02-22 17:19:11 there is a thread in #t-compiler 2021-02-22 17:20:20 i guess we should all focus on this in same spot 2021-02-22 17:35:16 I'll go on the Zulip in a bit 2021-02-22 17:42:52 well i figured out one thing 2021-02-22 17:43:00 EXTRADEPENDS_TARGET != EXTRADEPENDS_HOST 2021-02-22 17:43:04 which i mean, duh 2021-02-22 17:43:20 so maybe 1.50 is not broken for cross and my brain is 2021-02-22 17:51:19 does the contents of https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/ get updated immediately or after a delay? Trying to figure out what the x86_64 arch for a new aport didn't get built whereas all other archs did 2021-02-22 17:51:30 s/what/why/ 2021-02-22 17:51:30 minimal meant to say: does the contents of https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/ get updated immediately or after a delay? Trying to figure out why the x86_64 arch for a new aport didn't get built whereas all other archs did 2021-02-22 17:52:29 minimal: x86_64 should be updated instantly (even while the builder is still building) 2021-02-22 17:53:17 well for some weird reason there's no x86_64 package for hd-idle 2021-02-22 17:54:49 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/hd-idle/hd-idle-1.12-r0.log 2021-02-22 17:55:54 ikke: ah, the dir is timestamped in the last 8 mins so just been created 2021-02-22 17:56:30 I guess the x86_64 builder got backlogged for a whilw 2021-02-22 17:56:39 18:50:39 algitbot │ edge/testing/x86_64: uploaded 2021-02-22 17:56:47 that's 6 minutes ago 2021-02-22 17:56:53 so yes, it was still building 2021-02-22 17:57:18 minimal: https://build.alpinelinux.org/ 2021-02-22 17:57:41 yupe, I'd looked at there earlier and didn't think there was a backlog. The other archs built several hours ago 2021-02-22 17:59:01 ok, my x86_64->aarch64 cross attempt number whatever billion at this point has made it to rustdoc 2021-02-22 17:59:12 so i think there is no regression in 1.47 to 1.50 in the general case 2021-02-22 17:59:48 ok, but s390x is still broken? 2021-02-22 18:00:59 s390x and riscv64 will require additional code to support 2021-02-22 18:01:03 but we can do mips64[el] 2021-02-22 18:01:23 1.52 should be out by the time 3.14 ships 2021-02-22 18:01:33 Neat 2021-02-22 18:01:34 so my plan is to get everything staged for 1.52 2021-02-22 18:18:03 also, dalias shaming the rust devs got the rust build system maintainer to actually read zulip 2021-02-22 18:18:08 soooooo 2021-02-22 18:18:10 :D 2021-02-22 18:20:50 "D 2021-02-22 18:20:53 :D 2021-02-22 18:20:56 source? 2021-02-22 18:21:03 yes, please :D 2021-02-22 18:23:28 https://twitter.com/RichFelker/status/1363901109639741442 ? 2021-02-22 18:27:11 ok, hopefully mips64 will be done today 2021-02-22 18:27:14 for real this time 2021-02-22 19:13:04 ikke: not really, no 2021-02-22 19:14:23 Yesterday I deployed a change to CI which should even prevent uploading artifacts that are too large 2021-02-22 19:19:44 Ariadne: thank you for banging your head into rust 2021-02-22 19:20:47 omni: about 100MB 2021-02-22 19:20:50 make sure your tetanus shot is up to date 2021-02-22 19:20:57 skarnet: :D 2021-02-22 19:21:26 ncopa: i feel like i need a tetanus shot 2021-02-22 19:21:58 that's *my* joke 2021-02-22 19:22:09 o 2021-02-22 19:23:22 ok so far so good 2021-02-22 19:23:51 i succeeded in crossing x86_64 -> aarch64 again 2021-02-22 19:24:20 ikke: is that for the packages combined? 2021-02-22 19:24:34 yes 2021-02-22 19:25:03 I'll add some output in the CI log to show how much it is 2021-02-22 19:25:03 ikke: but I still think it's curious that this happen for x86* and armv7, but not aarch64 and ppc64le 2021-02-22 19:25:10 thanks! 2021-02-22 19:25:13 omni: yes, me too 2021-02-22 19:25:34 can it be that the binary sizes are slightly bigger for those arches? 2021-02-22 19:26:11 perhaps 2021-02-22 19:27:49 still, it should allow for 300M to be uploaedd 2021-02-22 19:28:04 but why is "matching files and directories" twice as many for these archs? 2021-02-22 19:28:20 proceeding to mips64 2021-02-22 19:28:25 perhaps I need to do some clean-up and remove files for those archs 2021-02-22 19:28:52 omni: it only uploads packages and keys 2021-02-22 19:29:58 speaking of mips, I'd also like to remove !mips and !mips64 for ocaml 2021-02-22 19:30:26 is mips being built btw? or only mips64? 2021-02-22 19:31:04 only mips64 2021-02-22 19:32:12 when was mips dropped? just curious, I've seen !mips here and there and added myself 2021-02-22 19:32:31 it was never built 2021-02-22 19:32:53 There were plans, but the issues with wave-technologies put that in the fridge 2021-02-22 19:36:53 ok, thanks 2021-02-22 19:41:29 hell yeah 2021-02-22 19:41:37 o...oh... 2021-02-22 19:41:42 well that's disappointing 2021-02-22 19:42:20 :-/ 2021-02-22 19:43:01 in other news, my contacts at microsoft got me in touch with the .net core alpine maintainer 2021-02-22 19:43:13 so, hopefully we can like, get something going there 2021-02-22 19:43:51 interesting 2021-02-22 19:46:17 at this point, i've kinda just stopped caring about free software purity 2021-02-22 19:46:40 i rather solve problems 2021-02-22 19:46:52 people complain about alpine + .net core being janky 2021-02-22 19:46:58 so, that seems like a problem we can solve 2021-02-22 20:02:12 omni: https://gitlab.alpinelinux.org/omni/aports/-/jobs/330286#L10039 2021-02-22 20:04:21 ikke: I don't see that many lines of output in my browser, it goes to 6313 for that job 2021-02-22 20:05:37 https://gitlab.alpinelinux.org/omni/aports/-/jobs/330286#L6292 2021-02-22 20:06:21 194MB 2021-02-22 20:07:25 thanks 2021-02-22 20:08:07 not sure what to do with it 2021-02-22 20:09:13 I have at least an idea how large the packages are 2021-02-22 20:10:43 Error 413 seems to indicate nginx is rejecting it 2021-02-22 20:10:43 but is the limit for packages combined? in this case we want to upgrade primarily one package and then rebuild a few against the upgraded one 2021-02-22 20:10:47 only the packages that are built in this job 2021-02-22 20:11:02 yes 2021-02-22 20:12:01 community/ocaml, community/ocamlbuild, community/ocaml-findlib, community/ocaml-camlp4, community/ocaml-lablgtk 2021-02-22 20:12:11 yes.. 2021-02-22 20:12:51 but the last one seem to be the culprit here, should I just exclude rebuilding that in this MR? 2021-02-22 20:13:12 and do that one later 2021-02-22 20:13:40 I thought I'd go over ocaml-* and others in testing later either way 2021-02-22 20:14:04 omni: hold on. the limit should be 300M, so I'm verifying why it's still complaining 2021-02-22 20:14:47 ack 2021-02-22 20:14:49 =) 2021-02-22 20:18:01 what's up with the build-aarch64 pipeline? the job is pending for this and the previous commit 2021-02-22 20:18:33 seems to be building kodi, not sure if it's stuck or not 2021-02-22 20:19:59 ah, ok 2021-02-22 20:20:12 I'll abort the not latest job 2021-02-22 20:22:23 Ariadne, is pthread_getname_np supported in musl 2021-02-22 20:23:31 https://pastebin.com/Edp3iCPH Because it default to this 2021-02-22 20:23:42 HAVE_PTHREAD_GETNAME_NP 2021-02-22 20:39:56 jenkler, no. that should be ddetected not hard-coded 2021-02-22 20:40:01 it's likely to be added in next musl 2021-02-22 20:40:11 but it's a nonstd largely-junk function that they should not assume exists 2021-02-22 20:55:48 dalias, https://git.alpinelinux.org/aports/tree/main/mozjs60/fix-musl-build.patch?h=3.12-stable 2021-02-22 20:55:58 That patch maybe fixes this 2021-02-22 20:56:12 Trying to compile it right now 2021-02-22 21:45:36 Hey folks. I'm here in reference to .NET. See: https://twitter.com/weh_kaniini/status/1363937247913934848. We're big Alpine fans. We're interested in enabling .NET on Alpine in new and better ways. 2021-02-22 21:50:24 rich_: welcome 2021-02-22 21:50:28 huh 2021-02-22 21:50:29 Nice to hear 2021-02-22 21:53:59 On .NET, we've worked a ton with Red Hat since .NET Core 1.0. They've been teaching us how to make an application platform that is acceptable to a Linux distro from a source build perspective (reproducibility, two-phase building, no foreign binaries). .NET is now part of RHEL 8 and Fedora 32, built by those communities. That's great. From our perspective, I'd like to know if we should expect a similar model for Alpine, or it 2021-02-22 21:53:59 is different? 2021-02-22 21:55:45 We share lot of those principles 2021-02-22 21:56:43 I've read https://github.com/dotnet/source-build 2021-02-22 21:57:35 Any comment on that? seems good / obvious gaps? 2021-02-22 21:57:55 What does the process look like for an application platform to become part of the Alpine official archives? 2021-02-22 21:58:32 rich_: source code and license 2021-02-22 21:59:04 I think most should be available under a MIT license 2021-02-22 21:59:16 Separately, we care a lot about servicing (particularly as it relates to CVEs). What does update cadence look like for servicing updates (patches) and who is responsible for code flow? 2021-02-22 21:59:38 Ya, the product is mostly MIT. The rest is Apache 2. We will eventually move it all to MIT. 2021-02-22 22:00:00 No proprietary licenses (Microsoft or otherwise). 2021-02-22 22:00:01 rich_: packages have maintainers, they are primarily responsible for providing updates 2021-02-22 22:00:16 alpine has release twice per year 2021-02-22 22:00:30 Oh, we know. we follow your updates closely. 2021-02-22 22:00:42 We have a edge repostiory which is the primary target for updates 2021-02-22 22:00:46 ok 2021-02-22 22:01:05 the stable releases will mostly receive bug / security updates 2021-02-22 22:01:09 I would assume packages can be updated on their own schedule, or do I misunderstand? 2021-02-22 22:01:55 Is the expectation that my team would be the maintainers of the .NET package for Alpine. Is that the usual model? 2021-02-22 22:02:31 It would be nice if someone knowledgable on the project could help maintain it 2021-02-22 22:02:55 what is "the project" here? alpine or dotnet? 2021-02-22 22:03:04 .neT 2021-02-22 22:03:16 omni: good question ;) 2021-02-22 22:03:18 thanks (I'm here to learn =) 2021-02-22 22:04:00 rich_: We have lots of people from the community maintaining their own packages 2021-02-22 22:04:00 rich_: hi! welcome! nice to have you here! 2021-02-22 22:04:18 rich_: updates go through merge requests again the aports git project 2021-02-22 22:05:32 https://gitlab.alpinelinux.org/alpine/aports 2021-02-22 22:05:54 stable branches can receive security and bug upgrades directly 2021-02-22 22:05:56 alpine is distro and .net is pkg 2021-02-22 22:06:20 hmm, maybe pkgs 2021-02-22 22:07:42 (about 30 years this company fighting against us, free/open source, and now they want to be member) 2021-02-22 22:08:18 sorry, but couldn't resist 2021-02-22 22:08:39 What's the lag between making changes to a package and them going live for users? 2021-02-22 22:09:01 Quite alright, mps. 2021-02-22 22:09:24 rich_: pkg must pass builders, that's all 2021-02-22 22:09:27 rich_: as soon as they are merged, the builders will pick it up and synced to the repository mirrors 2021-02-22 22:09:36 rich_: so, about 30 minutes to 1 hour 2021-02-22 22:09:36 Excellent. 2021-02-22 22:09:54 (if all goes well :) 2021-02-22 22:10:33 rich_: don't take my words wrongly, I'm not against you, just too much surprised 2021-02-22 22:10:51 mps: Not taken wrongly. I have a smile on. 2021-02-22 22:11:24 nice:) 2021-02-22 22:12:28 OK. Now I understand the basic model. We now have to decide if we want to maintain packages for this distro. It is a different model than we have with RHEL and Fedora. Not good or bad, just different. 2021-02-22 22:12:49 expectations, 30-60 minutes from when someone from alpine has reviewed, accepted and merged the MR 2021-02-22 22:13:02 yes, other distro's have dedicated maintainers that need to adopt packages 2021-02-22 22:13:26 alpine is more community maintained, a small set of core developers 2021-02-22 22:14:48 ehm, https://nitter.cattube.org/RichFelker/status/1363943317021614081 2021-02-22 22:15:13 following that thread 2021-02-22 22:15:41 didn't know that BDFL is there 2021-02-22 22:15:58 uh, twitter... 2021-02-22 22:20:24 with so much nice looking girls (by their mails) want to talk with me and I'm wasting free time on distro 2021-02-22 22:21:33 one reason I've thought of lately, for packaging rust crates, is that they take a long time to build, providing them prebuilt reduces the amount of cycles spent around the globe building crates 2021-02-22 22:22:12 I thought of this after Ariadne the other day compared building rust things to bitcoin mining 2021-02-22 22:23:11 The problem is that due to the cargo model, you'll probably end up in a dependency version constraint nightmare 2021-02-22 22:23:15 omni: maybe it is, coins goes to energy making companies 2021-02-22 22:23:32 and I wonder if it works with everything being statically compiled in rust 2021-02-22 22:24:02 there is less and less regards to backwards compatibility 2021-02-22 22:26:01 Ariadne: I too appreciate your efforts, btw, I'm afraid I can only cheer you on since what you do is beyond me. if there's anything I _could_ do, please ask 2021-02-22 22:28:29 eh, two years ago I tried (and succeed) to bootstrap rust for aarch64 and armv7 on alpine but it was not accepted in repo, and now I feel so happy about this. big thanks to ncopa 2021-02-22 22:53:11 ikke: oh, last time aarch64 hit the same issue too 2021-02-22 22:53:24 "too large" 2021-02-22 23:13:31 Hello! I'm trying to understand how to build the infrastructure necessary to serve a private apk repository. 2021-02-22 23:14:06 If I'm understood correctly, I need to generate a public/private key to sign my packages (with abuild-keygen) 2021-02-22 23:14:38 And serve the public key so people/other alpine servers can install on their /etc/apk/keys 2021-02-22 23:15:02 I didn't understood how does buildrepo works and what purpose 2021-02-22 23:15:13 s/purpose/purpose it serves/ 2021-02-22 23:15:13 eletrotupi meant to say: I didn't understood how does buildrepo works and what purpose it serves 2021-02-22 23:16:04 also, that command is not available anymore, and appears to be replaced by a buildlab? 2021-02-22 23:16:24 but looking at them, they look like do different things 2021-02-23 00:39:21 ikke: the aarch64 build now report "packages/: found 42 matching files and directories" and fail, it used to report "packages/: found 21 matching files and directories" and succeed and I don't _think_ I've changed anything wrt aarch64 2021-02-23 04:20:45 ikke: if ~194MB is what the packages should be together, if there for some reason exist twice that number of files it will hit the 300MB limit 2021-02-23 05:45:22 omni: Ooh, I think I know what's going on 2021-02-23 05:59:12 omni: I pushed an update to the alpine ci container, but forgot to remove similar functionality from the .gitlab-ci.yml script, so it copied the packages and keys twice 2021-02-23 06:04:03 omni: yes, now it's working! 2021-02-23 07:15:23 eletrotupi: buildrepo is in lua-aports package. 2021-02-23 07:15:46 eletrotupi: btw you can do things like `apk list cmd:buildrepo` and it will tell you what package to look for :) 2021-02-23 07:16:21 sorry, apk list -P cmd:buildrepo 2021-02-23 07:16:22 :) 2021-02-23 09:11:45 ikke: \o/ 2021-02-23 09:11:52 :D 2021-02-23 09:19:49 ncopa: what about 'transfer' maintainership to me 2021-02-23 09:19:56 huh 2021-02-23 09:20:06 of community/linux-tools 2021-02-23 09:20:24 (need to rest eyes a little) 2021-02-23 09:42:35 mps: sure. feel free to take over linux-tools 2021-02-23 09:42:48 good morning 2021-02-23 09:43:12 Morning 👋 2021-02-23 09:43:14 moin 2021-02-23 10:01:03 What do you think about this patch https://pastebin.com/stn4i00F 2021-02-23 10:06:45 for this compile error https://pastebin.com/hC2JVtLy 2021-02-23 10:09:36 Jenkler: I am thinking: why was HAVE_PTHREAD_GETNAME_NP set, when its not defined? 2021-02-23 10:10:01 Seams to be a bug 2021-02-23 10:10:12 But yes, that is my worry too 2021-02-23 10:10:42 but https://git.alpinelinux.org/aports/tree/main/mozjs60/fix-musl-build.patch?h=3.12-stable did not fix mozjs 2021-02-23 10:11:55 I'd use `ag HAVE_PTHREAD_GETNAME_NP` to find out where it was defined andfix it there 2021-02-23 10:11:56 there are no patches regardig fixing HAVE_PTHREAD_GETNAME_NP for musl what I can find :( 2021-02-23 10:15:09 ncopa, what pkg contain ag 2021-02-23 10:17:20 https://pkgs.alpinelinux.org/contents?file=ag&path=&name=&branch=edge 2021-02-23 10:18:07 Jenkler: the_silver_searcher 2021-02-23 10:18:08 laj_, thanks ;) 2021-02-23 10:18:19 missed the content search, sorry 2021-02-23 10:18:54 apk search --exact cmd:ag 2021-02-23 10:22:05 main/python3 3.8.2-r2 hangs on build-3-11-aarch64 2021-02-23 10:23:46 found it #define HAVE_PTHREAD_GETNAME_NP 1 2021-02-23 10:23:58 in platform/x86_64/linux/build/js-confdefs.h 2021-02-23 10:24:29 I dont get why it worked before 2021-02-23 10:24:34 there is probably an ifdef or similar there 2021-02-23 10:24:49 no 2021-02-23 10:26:16 no https://github.com/mongodb/mongo/blob/r4.2.9/src/third_party/mozjs-60/platform/x86_64/linux/build/js-confdefs.h 2021-02-23 10:26:22 line 40 2021-02-23 10:29:22 cant compare with 4.0.5, source is gone from the git three 2021-02-23 10:30:11 *tree 2021-02-23 10:31:35 if my old patch work now i will change it later to set HAVE_PTHREAD_GETNAME_NP 0 in that file. Seams like a better fix 2021-02-23 10:31:53 yeah, or simply remove that line 2021-02-23 10:32:08 ncopa, that smarter ;) 2021-02-23 10:32:19 sometimes they do: #ifdef HAVE_..... 2021-02-23 10:32:43 but why do they use PTHREAD_GETNAME_NP 2021-02-23 10:32:56 when ther are an alternative 2021-02-23 10:33:13 dunno 2021-02-23 10:33:41 maybe better for memory or filesize ? 2021-02-23 10:40:33 is there any mongo alternative gplish that doesn't need mozjs? 2021-02-23 10:43:45 artok, mongodb is kinda hardcoded to mozjs-60 in all 2021-02-23 10:44:29 I am tying to figure this out. Its must be possible to build for mongodb 4.2.9 with musl 2021-02-23 10:45:02 I would change db if i could. But the nodebb projekt needs mongodb 2021-02-23 10:45:26 Some have tried with postgresql, but that seams sucky 2021-02-23 10:48:16 we removed mongodb due to license change, didnt we? 2021-02-23 10:48:23 ncopa, yes 2021-02-23 10:48:28 :-/ 2021-02-23 10:48:40 the mongodb license is still open but 2021-02-23 10:48:54 have some issues with saas 2021-02-23 10:49:31 Jenkler: no, license is not open, it is 'faked free license' 2021-02-23 10:49:47 mongodb want to protect for Software as a service 2021-02-23 10:50:04 its sad that they cannot get proper funding 2021-02-23 10:50:13 we discussed this here a lot before removal 2021-02-23 10:50:30 other nosql dbs struggles, like rethinkdb 2021-02-23 10:50:49 I dont get it. Sure we can have mongodb in non-free but where did the maintainer go 2021-02-23 10:50:50 yes, 2021-02-23 10:51:07 Have everyone stoped using mongodb? 2021-02-23 10:51:17 apparently 2021-02-23 10:51:32 Jenkler: probably no one wants to be associated with non free software 2021-02-23 10:51:32 strange, it kinda big app 2021-02-23 10:51:50 mps, ahh, more like a statment then 2021-02-23 10:52:34 If there was an alternative I would do the work but I am kinda stuck with mongodb :( 2021-02-23 10:52:40 actually, I'm not sure should we keep non-free at all, but will not ask for removal 2021-02-23 10:53:17 mps, its nice to have an option to build stuff with abuild 2021-02-23 10:53:18 because people may want build and use those things themselves, and want share their work 2021-02-23 10:53:20 and yes, it is pity we don't have truly open/free nosql db 2021-02-23 10:53:47 nosql db opensource business seems to be difficult 2021-02-23 10:54:13 The good news it that I have learnd alot about the abuild ;) 2021-02-23 10:55:08 to me looks nosqls started as business idea 2021-02-23 10:56:39 mps, that may be true 2021-02-23 10:57:18 many opensource projects starts that way. some find a way to fund it, others doesnt 2021-02-23 10:57:30 I build everything with alpine packages now so, I dont want my old build of mongodb with gentoo 2021-02-23 10:58:25 and I have averse feeling for such projects started as opensource backed by company 2021-02-23 10:58:39 backend* 2021-02-23 10:59:05 but maybe 'backed' is also good term for this ;) 2021-02-23 11:00:50 most of these 'startups' just trying to grow on the 'shoulders' of opensource and want to be sold for big money to big companies 2021-02-23 11:02:43 its not easy. you do need to pay your bills, even if you make free software 2021-02-23 11:03:00 I prefer projects started by devoted individuals or teams, like zig lang for example 2021-02-23 11:03:03 ncopa, thats true 2021-02-23 11:03:35 I mostly use wordpress for my customers 2021-02-23 11:03:57 yes, I agree, we all need food for sure, but we also have to be honest 2021-02-23 11:04:48 the beauty with open source, is you can do whatever you want with it 2021-02-23 11:04:51 My only goal with my company is to survive 2021-02-23 11:05:09 and work from home ;) 2021-02-23 11:05:27 you can sell it, or make big money if you want, you can contribute back if you want, but you don't need to if you dont want 2021-02-23 11:05:34 its free 2021-02-23 11:05:50 for example, I have one business software which is not used anymore but I didn't put it on net because I don't have time to maintain it in free time, and I don't want to 'fake' people to think and hope I will 2021-02-23 11:06:16 so other are indeed allowed to make big money using it, and they have no obligation to pay anything back 2021-02-23 11:06:33 mps, maybe someone can continue your work then 2021-02-23 11:06:42 ncopa: that is ok, imo 2021-02-23 11:07:15 agree. it is, but sometimes that happens, and the ppl doing the work sees that other make lot of money on top of their work they give for fre, while they struggle them selves 2021-02-23 11:07:21 and find that unfair 2021-02-23 11:07:32 but what is not ok is to give software for 'free' and after some time ask for money else you can't use it anymore 2021-02-23 11:07:41 i agree 2021-02-23 11:07:53 but i do understand that some people find it unfair 2021-02-23 11:08:14 then they change the license to try fix that, but IMHO, that is just shooting yourself in the foot 2021-02-23 11:08:26 I don't, if I give something, I did and this is the 'end' 2021-02-23 11:09:31 _end_ 2021-02-23 11:09:45 ncopa, yes. Seams that void has dropped mongodb too 2021-02-23 11:09:50 (*end* looks better) 2021-02-23 11:10:07 i find the history of git interesting 2021-02-23 11:10:26 linux used bitkeeps, which was (is?) closed source 2021-02-23 11:10:54 yes, example of why not rely on such software 2021-02-23 11:11:03 they sponsored linux development by letting linux devs use it for free 2021-02-23 11:11:03 bitkeeper 2021-02-23 11:11:11 yes bitkeeper 2021-02-23 11:11:20 ncopa: I think in case if Linux, the structure is a lot more decentralized 2021-02-23 11:11:27 I remember drama 2021-02-23 11:11:31 especially at that time 2021-02-23 11:11:56 now, the linux devs was not too happy with using closed source, and wanted an opensource client 2021-02-23 11:12:22 so, someone smart and devoted have to sit for few days and make gitmdb (git mongo db) 2021-02-23 11:12:28 so someone started to reverse engineer the bitkeeper protocol (IIRC it was samba ppl) 2021-02-23 11:12:57 bitkeeper company did not like that, since their business was selling the closed source product 2021-02-23 11:13:25 so they asked them to stop the reverse engineering, or they would no longer be allowed to use bitkeeper 2021-02-23 11:13:40 linus got fed up, and created git 2021-02-23 11:13:59 now, where is bitkeeper now? and where is git? :) 2021-02-23 11:14:01 no, drama started because owner (Larry) wanted to sell linux as it is his property 2021-02-23 11:14:43 I wonder if mongodb will change their license again ;) 2021-02-23 11:14:50 i doubt 2021-02-23 11:14:52 he thought because linux is developed by his software he 'own' it 2021-02-23 11:15:49 you all remember Laokonts words about Danans from Illiad 2021-02-23 11:15:55 I hope 2021-02-23 11:16:18 i dont 2021-02-23 11:16:56 Danans made Troian horse and left it to Troyans 2021-02-23 11:17:24 troyan horse i know 2021-02-23 11:17:49 one of the Troyans (Laokont) told them (to Troyans) 'I don't trust Danans even when they give gifts' 2021-02-23 11:18:42 and, Laokont was right, as the rest of story tells, that you probably know 2021-02-23 11:19:56 Troyans and Danans were warring parties, I think you also know this 2021-02-23 11:21:07 is nonfree purged now and then? 2021-02-23 11:21:26 wow, bitkeeper was also afraid of mercurial 2021-02-23 11:21:29 https://web.archive.org/web/20070929115009/http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481 2021-02-23 11:22:09 non-free isnt that well maintained. I guess we should purge some of the stuff, like adobe flash plugin 2021-02-23 11:22:20 but i don't mind having mongodb there 2021-02-23 11:22:43 and i dont mind that someone maintains it 2021-02-23 11:24:33 ncopa, but do you want my hack in non-free ? 2021-02-23 11:24:35 heh, I had to upgrade non-free/b43-firmware for old macbook here, but didn't dare to push upgrade to aport 2021-02-23 11:25:03 and they even opensourced bitkeeper https://users.bitkeeper.org/t/bk-7-2ce-released-2016-05-09/93 but it was too late. git had already taken over 2021-02-23 11:25:14 amazing 2021-02-23 11:25:41 ncopa, https://pastebin.com/c9XMVbAx 2021-02-23 11:25:43 Jenkler: i don't mind pushing your hack to non-free, unless it is way too ugly 2021-02-23 11:26:06 uhm, so I'm so old because I have all this in head, and don't need to search archives :) 2021-02-23 11:26:07 dont know if i should have some contribs 2021-02-23 11:26:24 Jenkler: looks good to me 2021-02-23 11:26:47 i have remade all the patches but I am not sure if every patch is needed hehe 2021-02-23 11:26:48 mps: you are a living archive :) 2021-02-23 11:27:10 lol 2021-02-23 11:27:56 no, I'm not, I just remember important points, not details 2021-02-23 11:28:14 Jenkler: feel free to send an MR and ping me. I wont test if it actually builds, but if you say it builds I'll merge it 2021-02-23 11:29:43 ncopa, sure, just need to get it to work first hehe 2021-02-23 11:29:55 ncopa, what kinda blame can i get? 2021-02-23 11:31:15 working on opensource expect blames, maybe sometimes even small praise ;) 2021-02-23 11:31:28 mps, haha 2021-02-23 11:31:40 shit it broke down again ;( 2021-02-23 11:31:42 https://pastebin.com/C9t8tGKt 2021-02-23 11:32:09 looks like a missing include 2021-02-23 11:32:18 something with kms-message 2021-02-23 11:32:29 #include 2021-02-23 11:32:40 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html 2021-02-23 11:34:17 Jenkler: btw, thanks for fixing it. believe or not but 3 days ago I thought to build it locally because it will fit very well on one of my needs 2021-02-23 11:34:27 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18608 <- I don't think we want more device specific kernels? 2021-02-23 11:35:12 any aarch64 guru can help with this error: /tmp/ccBCjaIi.s: Assembler messages: 2021-02-23 11:35:12 /tmp/ccBCjaIi.s:1124: Error: immediate out of range at operand 3 -- `bic w1,w0,5' 2021-02-23 11:35:12 make[5]: *** [/home/buildozer/aports/main/linux-vanilla/src/linux-4.19/scripts/Makefile.build:304: drivers/net/xen-netback/rx.o] Error 1 2021-02-23 11:35:12 make[4]: *** [/home/buildozer/aports/main/linux-vanilla/src/linux-4.19/scripts/Makefile.build:544: drivers/net/xen-netback] Error 2 2021-02-23 11:35:39 Cogitri: I tend to agree, but didn't wanted to be one who will say that, again 2021-02-23 11:36:03 yes, we want avoid that if possible 2021-02-23 11:36:27 mps, mostly it was a python2 -> python3 update 2021-02-23 11:36:39 we have testing/linux-amlogic lingering for long time 2021-02-23 11:38:31 and we have linux-rpi 2021-02-23 11:38:39 difficult to know where to draw the line 2021-02-23 11:39:01 Yeah, but I think the rpi is a device that's very common by now, a pinebook, maybe not so much 2021-02-23 11:39:08 So I think keeping those devices in pmOS is fine for now 2021-02-23 11:45:07 nopa: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/RIP5GVME6S7BNF26SG4KBT2ZPW5P3DBY/ 2021-02-23 11:45:36 ncopa ^ 2021-02-23 11:46:14 laj_: thank you sir! 2021-02-23 11:47:13 i found the commit that introduced it and i did suspect the atomic ops 2021-02-23 11:55:05 ncopa, if a build have crashed. Can i run it again or do I need to clean 2021-02-23 11:55:43 You can repeat the build step 2021-02-23 11:57:02 so, i can test to patch the code and rerun 2021-02-23 11:57:19 yes 2021-02-23 11:57:21 without missing somthing in the build step 2021-02-23 11:57:45 https://pastebin.com/cBgxAxUN 2021-02-23 11:57:58 Seams that the added it for win32 2021-02-23 12:01:33 wow, it did compile 2021-02-23 12:09:58 ikke, after build. Can i run package to make the apk file? 2021-02-23 12:10:13 abuild rootpkg 2021-02-23 12:10:44 what is package 2021-02-23 12:11:48 Run 'package', the split functions and create apks as fakeroot 2021-02-23 12:12:18 rootpkg seams the way to go 2021-02-23 12:12:20 The package function is what's defined in the APKBUILD 2021-02-23 12:12:28 but that just copies files to the pkg dir 2021-02-23 12:12:47 rootpkg does that, runs split functions and creates the apk file (and uses fakeroot as well) 2021-02-23 12:14:15 but its seams to rebuild stuff 2021-02-23 12:15:08 does rootpkg fix all the libs needed for the binary 2021-02-23 12:17:28 yep : >>> mongodb*: Tracing dependencies... 2021-02-23 12:20:04 ncopa: I reverted my attempt to build ocaml without debug info, since it upset another test, and it should now be successful and mergeable as earlier (but we'll see when builds complete, phase of the moon etc) 2021-02-23 12:20:59 I just had to try, when I saw that going through the changes 2021-02-23 12:25:09 elastic has billions in the bank 2021-02-23 12:25:20 i would say they have proper funding 2021-02-23 12:29:39 urk valet att låta lab defaulta till att skicka allt till en pager var ju dåligt, nu måste jag lägga till --no-pager då jag inte vill ha det 2021-02-23 12:30:03 omni, svenska killen ;) 2021-02-23 12:30:04 extra dumt är 'lab ci status --no-pager --wait' 2021-02-23 12:30:23 haha, sorry, wrong channel 2021-02-23 12:30:51 *blush* 2021-02-23 12:31:46 ncopa, I dont know if my build is usefull for others. I am only intend to build mongod and mongo 2021-02-23 12:32:54 anyways, rant about new defaults in community/lab to pipe output to a pager, if --no-pager isn't specified 2021-02-23 12:33:17 svenskar altså... 2021-02-23 12:33:31 ncopa, haha Ja / YES 2021-02-23 12:34:36 omni: ok, ping me if it passes and i forget about it. thank you for working on it 2021-02-23 12:35:56 Jenkler: i think someone asked me about mongo not too long ago, so I think your apkbuild might be useful for others 2021-02-23 12:36:21 ncopa: sure, just waiting for ppc64le to complete 2021-02-23 12:36:32 i got the kernel arm64 assembly to build. not sure if it actually works... 2021-02-23 12:37:16 ncopa, ok but then i make my thing and ppl can modify it if they need more than mongo and mongod. I also skip conf files ;) 2021-02-23 12:37:31 sounds good. thanks! 2021-02-23 12:37:39 ncopa, but i have tested tha apk and it seams to work ;) 2021-02-23 12:38:39 ncopa, any docs on how i do MR (Merge request?) 2021-02-23 12:39:20 thanks Ariadne, will take a look 2021-02-23 12:39:26 maybe somewhere.. 2021-02-23 12:40:32 maybe mps kan help me with this. 2021-02-23 12:40:33 Still wonder if is not just throw a bunch of APKBUILD on some folders (like aports do), run abuild for each of them and then just serve ~/packages 2021-02-23 12:44:23 Jenkler: didn't understood. about what maybe I kan help? 2021-02-23 12:45:40 ncopa: what you mean by 'kernel arm64 assembly' 2021-02-23 12:46:08 eletrotupi: that is precisely what it is 2021-02-23 12:46:22 mps, the best way todo a MR (I guess its a merge request) to ncopa 2021-02-23 12:46:23 ncopa: there we go, success! 2021-02-23 12:46:26 nice 2021-02-23 12:46:47 Jenkler: from time to time users comes and asks about mongodb, so I think your build would help them 2021-02-23 12:46:48 Is there space for creating a doc 2021-02-23 12:46:52 sorry 2021-02-23 12:47:15 Will this 'guide' be something of interest to be at Alpine wiki/docs? 2021-02-23 12:47:37 alpine won’t ship SSPL software but maybe a third party repo is helpful 2021-02-23 12:47:46 mps, maybe i can post them to a mailinglist 2021-02-23 12:47:46 On how to setup a private/third party repo 2021-02-23 12:48:10 Jenkler: ok, post the git format patch or git diff and I will look, but not right now, hope will have time this evening 2021-02-23 12:48:53 mps, its standard diff -u format on the patches 2021-02-23 12:48:54 Jenkler: you can on ML, or even tpaste.us and post url here 2021-02-23 12:48:54 Jenkler: unless you want to use gitlab? 2021-02-23 12:50:18 this is how my patches look 2021-02-23 12:50:19 https://pastebin.com/h67Sdrb5 2021-02-23 12:50:21 Jenkler: 'git format-patch -1 --stdout | tpaste' and post url 2021-02-23 12:51:41 Jenkler: if you can please use tpaste, it is better than opening browser and searching for 'raw' 2021-02-23 12:52:37 Jenkler: wait, this is just one line change? 2021-02-23 12:53:03 mps, its only one of the patches 2021-02-23 12:53:10 ah, ok 2021-02-23 12:53:20 I thought so btw :) 2021-02-23 12:53:55 has tpaste an url 2021-02-23 12:54:07 so i can paste in my browser 2021-02-23 12:54:16 like pastebin 2021-02-23 12:54:18 Jenkler: 'apk add tpaste' 2021-02-23 12:54:32 ahhh 2021-02-23 12:55:00 and then 'git format-patch -1 --stdout | tpaste' (just example). tpaste.us is url 2021-02-23 12:56:08 tpaste.us is alpine official paste service 2021-02-23 12:56:30 ncopa: I'm curious to see if they'll also build on mips64, as I've been told they should =) 2021-02-23 12:56:51 omni: i can check after itlands for other archs 2021-02-23 12:57:20 mps, https://tpaste.us/DMPX 2021-02-23 12:57:47 mps, how long will it sta there ? 2021-02-23 12:57:55 *stay 2021-02-23 12:58:48 few days, maybe week, idk 2021-02-23 12:58:59 ok ;) 2021-02-23 12:59:29 Then i clean upp my scripts and tpaste them. 2021-02-23 12:59:43 Ariadne: cool, I've set archs to all 2021-02-23 12:59:51 I send the links in a PM to you 2021-02-23 13:01:42 Jenkler: just to remind myself, you are person from Sweden with who I talked few times about 1-2 years ago? 2021-02-23 13:02:00 whom* 2021-02-23 13:02:42 going to see if go is resurrectable on mips64 2021-02-23 13:02:59 mps, yes ;) lxc guy 2021-02-23 13:03:21 I have my lxc setup working fine now ;) 2021-02-23 13:04:02 ah, yes, I remember now. nice to talk with you again 2021-02-23 13:04:17 this are the packages for my lxc containers. I dropped gentoo and docker 2021-02-23 13:04:34 mps, yes, alpine is a keeper 2021-02-23 13:04:47 mps, nice to talk to you too 2021-02-23 13:04:57 thanks 2021-02-23 13:05:13 my nginx build is 6mb 2021-02-23 13:05:39 https://files.jenkler.com/images/20210216/ 2021-02-23 13:06:04 Love it clean and alpine make my day every day hehe 2021-02-23 13:06:20 2.5 compressed, its insane 2021-02-23 13:08:29 Ariadne: succes 2021-02-23 13:13:39 ikke: ? 2021-02-23 13:14:30 going to see if go is resurrectable on mips64 2021-02-23 13:15:17 looks like it might be 2021-02-23 13:16:18 yeah 2021-02-23 13:16:20 its building 2021-02-23 13:16:48 i guess loongson guys figured it out 2021-02-23 13:16:54 i certainly didn't 2021-02-23 13:20:00 Installed Go for linux/mips64 in /home/buildozer/aports/community/go/src/go 2021-02-23 13:20:01 yep 2021-02-23 13:24:52 just waiting for the testsuite to finish 2021-02-23 13:24:52 \o/ 2021-02-23 13:25:04 Oh, algitbot lives again? 2021-02-23 13:25:50 I had to apply some percussive maintenance 2021-02-23 13:29:16 so that probably means we can get CI going 2021-02-23 13:29:21 i have a second octeon3 board 2021-02-23 13:38:42 Cool 2021-02-23 13:39:03 Does docker already have images for mips64? 2021-02-23 13:39:17 I haven't checked 2021-02-23 13:43:29 mips64el? 2021-02-23 13:46:47 go is alive 2021-02-23 13:48:08 there's all this go crap that is rotten 2021-02-23 13:50:27 https://github.com/alpinelinux/docker-alpine/tree/edge 2021-02-23 13:52:10 Ariadne: mips64el should be the correct arch, right? 2021-02-23 13:52:17 no 2021-02-23 13:52:26 mips64el is little-endian mips64 2021-02-23 13:52:30 mips64 is big-endian 2021-02-23 13:52:41 we will soon have both 2021-02-23 13:52:49 mips64el = loongson 2021-02-23 13:52:54 And mips64el? 2021-02-23 13:53:02 Le* 2021-02-23 13:53:10 same thing as mips64el 2021-02-23 13:53:16 Ok 2021-02-23 13:54:32 What is GOARCH for mips64? 2021-02-23 13:56:50 mips54 2021-02-23 13:56:53 mips64* 2021-02-23 13:58:55 OK, seems like we would be the first 2021-02-23 13:59:17 https://hub.docker.com/u/mips64 2021-02-23 13:59:35 Hmm.. 2021-02-23 13:59:47 Community organization 2021-02-23 15:16:42 mm->e820[j].addr = Map[i].PhysicalStart; | |#define CR4_LA57 0x1000 /* enable level-5 paging */ 2021-02-23 15:16:54 whoops 2021-02-23 15:19:52 hi jart 2021-02-23 15:25:46 omni: ocaml does not build on mips64: Makefile:929: *** The native-code compiler is not supported on this platform. Stop. 2021-02-23 15:28:24 :D 2021-02-23 15:28:39 it would not be too difficult to write a codegen for ocaml 2021-02-23 15:28:48 alas i am still toiling in the RUST MINES 2021-02-23 15:29:06 this is like minecraft, except that all you get is pain and misery 2021-02-23 15:30:17 how are you doin Ariadne? promise me to drop rust on the floor before it drags you down too much 2021-02-23 15:30:53 ACTION is worried when Ariadne is in the rust mines 2021-02-23 15:31:53 oh no.... i was just about to \o/ due to all the builders are done with the kernels, but now there is a new kernel release 2021-02-23 15:32:23 s/is a new kernel release/are new kernel releases/ 2021-02-23 15:32:23 ncopa meant to say: oh no.... i was just about to \o/ due to all the builders are done with the kernels, but now there are new kernel releases 2021-02-23 15:32:36 algitbot: hi! nice to have you back 2021-02-23 15:33:20 ncopa: i do not want to have to get a tetanus shot :))) 2021-02-23 15:33:44 ncopa: go works again on mips at least 2021-02-23 15:34:09 awesome! 2021-02-23 15:34:33 i also saw you had more hardware, which means we could get a CI running for mips64? 2021-02-23 15:35:20 ncopa: I guess we need a mips64 alpine image 2021-02-23 15:35:30 Docker 2021-02-23 15:37:59 yes, but first i guess we need to get docker going 2021-02-23 15:53:47 Ariadne: On Rust's zulip now, do you have the link about the thread you were talking about handy? 2021-02-23 15:54:57 Cogitri: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/bootstrapping.20on.20s390x.2Fmips.20for.20musl 2021-02-23 15:55:58 ncopa: yes, kernel is 'most' developed thing in linux eccosystem, every week one or two releases 2021-02-23 15:56:21 oh, good. my dell open notworking switches are randomly crashing and rebooting themselves 2021-02-23 15:56:28 cumulus is such a high quality distro 2021-02-23 15:56:41 only ncurses is near to this, releases are every sunday 2021-02-23 16:16:09 ncopa: https://github.com/alpinelinux/docker-alpine/pull/148 2021-02-23 16:20:17 ikke: i think that the official libraries does not yet have support for mips64 2021-02-23 16:20:32 ncopa: I had such a feeling 2021-02-23 16:21:40 This seems to be a normal user: https://hub.docker.com/u/mips64 2021-02-23 16:22:56 https://github.com/docker-library/official-images/pull/7899#issuecomment-620808208 2021-02-23 16:30:33 ncopa: I was told in #ocaml that mips* was supported, I'll have a look later (probably not before tomorrow0 2021-02-23 16:31:13 mdadm 4.1 needs this UAF fix: http://ix.io/2QwE 2021-02-23 16:31:38 it was silently fixed as part of a larger change in 2018 upstream but there's been no release since then :( 2021-02-23 16:31:43 UAF - use after free? 2021-02-23 16:31:46 yes 2021-02-23 16:31:51 obvious from the diff contents 2021-02-23 16:32:12 *ent does not exist after the closedir 2021-02-23 16:32:58 no, question is to just confirm that I'm talking with genius in programming 2021-02-23 16:33:23 ncopa: So I guess we would first need to build our own images 2021-02-23 16:33:27 sorry :) 2021-02-23 16:33:56 dalias: I'm fascinated how fast you spotted it 2021-02-23 16:33:59 do you have any references? its for https://gitlab.alpinelinux.org/alpine/aports/-/issues/12314 I suppose 2021-02-23 16:36:11 Ariadne: are you working on docker for mips64 atm? 2021-02-23 16:36:20 ncopa: I could do a quick !mips64 2021-02-23 16:36:38 dalias: thank you! that was incredibly quick indeed :) 2021-02-23 16:37:26 mps, well valgrind showed exactly what the libc functions involved were even before we had mdadm symbols -- strdup (presumably of d_name) after closedir 2021-02-23 16:38:06 so once i had a symbols showing disk_path and policy_check_path in valgrind backtrace.. 2021-02-23 16:38:14 i noted disk_path isn't in current git 2021-02-23 16:38:25 dalias: yes, I followed this on #musl, but again I'm fascinated 2021-02-23 16:38:28 so "duh, we're not finding the bug because it's in code that was changed" 2021-02-23 16:38:46 and i just pulled up history of file with policy_check_path 2021-02-23 16:39:04 and immediately saw -closedir -xstrdup in diff 2021-02-23 16:49:21 do you have an url for the upstream fix? so i can include it in commit message 2021-02-23 16:50:35 ah, found it in #musl, thanks! 2021-02-23 16:54:37 ncopa: I've disabled for mips64 2021-02-23 16:54:50 can look at that later, if it is possible 2021-02-23 16:55:07 to get it working on mips64, that is 2021-02-23 16:55:24 it'd be nice to have it merged for the archs it is working 2021-02-23 16:57:47 +1 2021-02-23 16:57:49 thanks 2021-02-23 17:10:26 Do I need to add some path to my repos for bootstrap.sh to work? Fails for me with `binutils-mips64 (no such package)` (and seems like that didn't end up in $HOME/packages/edge/main/mips64) 2021-02-23 17:12:06 You need to provide a repo 2021-02-23 17:12:09 as argument 2021-02-23 17:13:11 Oh, usage doesn't mention that 2021-02-23 17:14:07 Does it need my $HOME/packages as 2nd argument? 2021-02-23 17:14:22 sorry, I confused it with mkimage 2021-02-23 17:21:43 hmm, docker is still not using go modules? 2021-02-23 17:21:57 it fails to build now on go 1.16 due to that 2021-02-23 17:22:04 (fixable by setting GO111MODULE to off) 2021-02-23 17:50:56 ncopa: ericonr posted patch for mdadm monitor.c here https://0x0.st/-8lb.patch 2021-02-23 17:51:35 I'm wasting time on mongodb right now 2021-02-23 17:52:19 ericonr: thanks, also on this channel :) 2021-02-23 17:52:30 :p np 2021-02-23 17:52:51 (look like we all are on #musl and #alpine-devel) 2021-02-23 18:04:17 I have docker built on mips64, but it requires buildmode=pie to be disabled 2021-02-23 18:22:10 ikke: does it work :D 2021-02-23 18:22:31 Details :P 2021-02-23 18:23:07 I would need to be able to install it somewhere 2021-02-23 18:23:18 inside an lxc container is problematic 2021-02-23 18:26:09 Does someone have a mpfr-4.1.0.tar.xz tarball around? mpfr.org times out for me 2021-02-23 18:26:49 distfiles? 2021-02-23 18:27:56 https://distfiles.alpinelinux.org/distfiles/mpfr-4.1.0.tar.xz 2021-02-23 18:30:59 Oh, somehow I had expected that abuild would automatically fall back to distfiles, but that's only the builders, isn't it? 2021-02-23 18:31:53 You can setup in abuild.conf 2021-02-23 18:31:59 DISTFILES_MIRROR 2021-02-23 18:33:52 Oh, nea 2021-02-23 18:43:44 mps, ericonr: can you please create an isue with the details and the patch? and i'll deal with it when I can. Cannot drop everything in my hands right now 2021-02-23 18:48:02 ncopa: ok 2021-02-23 18:48:28 I'll create MR 2021-02-23 18:50:04 ncopa: btw, I tested mongodb which jenkler posted to me, it builds only on x86_64, but I think it is ok to push it, it is unmaintaned anyway 2021-02-23 18:50:04 awesome. thanks! 2021-02-23 18:50:22 the --prefix=$pkgdir/usr looks a bit fishy 2021-02-23 18:50:35 would have expected it to be --prefix=/usr 2021-02-23 18:50:48 and spaces -> tabs 2021-02-23 18:50:51 yes 2021-02-23 18:50:54 otherwise good 2021-02-23 18:50:56 all this 2021-02-23 18:51:14 the _buildopts var is not needed either. only used once 2021-02-23 18:51:16 I thought to 'fix' APKBUILD before merge 2021-02-23 18:51:23 and paxmark is not needed either 2021-02-23 18:51:24 good 2021-02-23 18:51:45 mps: https://tpaste.us/OQMV 2021-02-23 18:51:46 yes, yes, APKBUILD is 'fishy' 2021-02-23 18:52:12 paxmark…those were the days :D 2021-02-23 18:52:18 exactly... :) 2021-02-23 18:52:29 ncopa: yes, same is sent to me 2021-02-23 18:52:58 mps: the diff is my "fixup"s 2021-02-23 18:53:10 oh, wait 2021-02-23 18:53:55 (don't look to source of anything just after nap ;) ) 2021-02-23 18:54:19 ncopa: right, I see 2021-02-23 19:04:39 ncopa: not sure I understood. will you push this mongodb changes or you left it to me? 2021-02-23 19:05:52 Cogitri: at this point, libc crate needs to be fixed for all targets (including mips) 2021-02-23 19:09:19 mps: feel free to do it. im busy with the security releases 3.10.6, 3.11.8 and 3.12.4 for the docker images 2021-02-23 19:09:46 we dont have an issue in our tracker for the openssl issues right? those got fixed before anyone reached to report them? 2021-02-23 19:11:21 ncopa: ok 2021-02-23 19:11:39 ncopa: I guess it's good to still have them in that cae 2021-02-23 19:12:27 ncopa: I don't see any issuess 2021-02-23 19:13:24 Ariadne: wdym? 2021-02-23 19:14:07 ncopa: seems like those were not reported to the oss-sec mailing list? 2021-02-23 19:18:23 Cogitri: the missing archs need to have code written (or, in the case of mips, fixed) to describe the musl ports of those archs 2021-02-23 19:18:35 we got cross compilation working reliably 2021-02-23 19:23:42 \o/ 2021-02-23 19:24:13 unfortunately libc crate is totally broken 2021-02-23 19:24:16 on mips 2021-02-23 19:24:25 and missing on s390x and riscv64 musl 2021-02-23 19:24:34 im a bit worried about rust in general. they dont want us (distros) to treat rust like we treat C packages, with stable ABI etc 2021-02-23 19:24:36 but hey, that's something that can actually be sorted 2021-02-23 19:25:02 which means that its not really suitable as C replacesment 2021-02-23 19:25:05 a good way to consider crates is like C2a modules 2021-02-23 19:25:28 rust does not seem to provide anythin stable at all. break at will 2021-02-23 19:25:30 end products have stable ABIs, but crates are just little components that go into the end product 2021-02-23 19:25:39 ncopa: as shown by the twitter thread, it's not only rust, it's a lot of languages, and I fear it's a general philosophy in lots of communities that have little contact with distro maintainers 2021-02-23 19:26:04 yeah, pin with a version that happens to work 2021-02-23 19:26:06 what would help would be a multi-distro communication effort 2021-02-23 19:26:14 and dare you if you try unpin it 2021-02-23 19:26:23 security issues? nah... thats only for C 2021-02-23 19:26:32 :D 2021-02-23 19:26:34 what is backwards compattibility? 2021-02-23 19:26:53 i predict that there will lots of unfixed security issues, because if you fix the sec issue you break everything 2021-02-23 19:26:59 our language is safe, we don't need good practices! 2021-02-23 19:27:20 i think these things will evolve in time 2021-02-23 19:27:27 who has the time? 2021-02-23 19:27:28 well, i think their "good practices" is alays run the latest, edge 2021-02-23 19:27:37 Ariadne: yeah, i think so to 2021-02-23 19:27:41 too 2021-02-23 19:27:52 skarnet: they clearly do, given their effectiveness of getting rust into everything 2021-02-23 19:28:10 its just "growing" pains 2021-02-23 19:28:10 they are planning to rewrite python in rust with python 4.x 2021-02-23 19:28:18 lol 2021-02-23 19:28:21 oh dear... 2021-02-23 19:28:24 i'm not even kidding 2021-02-23 19:28:27 what could possibly go wrong 2021-02-23 19:28:29 i believe you 2021-02-23 19:28:36 python-cryptography is the "test run" 2021-02-23 19:28:38 i mean, the idea is not that bad 2021-02-23 19:28:51 its just that rust is inmature 2021-02-23 19:29:12 yes, and they don't listen to distros 2021-02-23 19:29:17 they should rewrite gcc in python-4 afterwards 2021-02-23 19:29:24 just to make it more fun to bootstrap 2021-02-23 19:29:49 Ariadne: has https://github.com/rust-lang/libc/issues/1848 been brought up recently? 2021-02-23 19:29:49 even though we have learned a lot over the past 50 years of UNIX 2021-02-23 19:30:07 in whatever circles these conversations are happening in 2021-02-23 19:30:16 Ariadne: Ah yes, was a bit confused what you meant by "other arches", but it's only s390x (musl) & mips which are broken/missing in libc 2021-02-23 19:30:17 skarnet: fwiw, my way of "resisting" that tweet was to post my (controversial?) tweet about removing rust. I dont really have the intention to do so, just want hear from them that removing it is a bad idea 2021-02-23 19:30:21 Ariadne: that's what's killing me, it's endless reinvention and nobody learns from past mistakes 2021-02-23 19:30:28 Cogitri: riscv64 too 2021-02-23 19:30:34 skarnet: exactly 2021-02-23 19:30:36 Ah right, we want to support that too 2021-02-23 19:30:39 ncopa: you should use that leverage 2021-02-23 19:30:44 projects not using bindgen are extremely for interaction with external C libraries 2021-02-23 19:30:44 ncopa: I'm not sure they think that's an issue? 2021-02-23 19:30:54 and that's why it needs to be a cross-distro effort 2021-02-23 19:31:04 fwiw 2021-02-23 19:31:05 "play nicer and listen to us, or we'll just stop packaging you" 2021-02-23 19:31:08 ncopa: don't they want user to use rustup anyway? 2021-02-23 19:31:10 they are willing to listen now 2021-02-23 19:31:15 and bypass all distro 'nonsense' 2021-02-23 19:31:16 Yeah, would be neat if libc used bindgen too, but that would pull in libclang for almost all Rust crates 2021-02-23 19:31:18 So probably wont happen 2021-02-23 19:31:32 i think i made the point. i dont have more energy for that now 2021-02-23 19:32:07 i think they understand that distros are what gets rust into people's hands 2021-02-23 19:32:27 they just live in a bubble 2021-02-23 19:32:27 Cogitri: bindgen being a build-dependency is what makes this hard 2021-02-23 19:32:39 I know supposedly rust wants to support alternative backends and such 2021-02-23 19:32:42 some people just dont realize that lots of the work devs do builds on top of distros work 2021-02-23 19:32:57 but bundling bindgen into rustc/cargo would solve so much of this 2021-02-23 19:33:13 "just use docker" sure but where do you get the deps from? "build from source? no way! i dont want maintain 30 deps..." 2021-02-23 19:33:30 since you have to build the version of bindgen that's listed in each project's Cargo.toml, instead of using a central thing 2021-02-23 19:33:37 needless to say, the past few weeks in zulip have been a learning experience for them 2021-02-23 19:33:37 Also, Rust can expose a stable C ABI (and utilities like cargo-c can help with this) , it just wont expose a stable Rust ABI for the time being 2021-02-23 19:34:05 Ariadne: thank you for pishing that. I dont have energy for it 2021-02-23 19:34:24 but yeah, i think will eventually sort out one way or the other 2021-02-23 19:34:30 until now they never got to see things in a deep dive from distro POV 2021-02-23 19:34:52 a lot of process changes have already been discussed as a result 2021-02-23 19:35:36 then dalias shaming them on twitter got a lot of people who can actually *do* something involved 2021-02-23 19:35:43 Ariadne: i really like how you ahve handled this. not blaming/flaming them, but more of a "this is the problem. how do we fix it?" approach 2021-02-23 19:36:12 ncopa: i've found that if you give somebody enough rope, they can hang themselves 2021-02-23 19:36:17 err i mean :) 2021-02-23 19:36:20 i thikn we should be careful with the shaming part. its demotivating 2021-02-23 19:36:30 no, i agree 2021-02-23 19:36:34 that doesn't solve anything 2021-02-23 19:36:45 i just want to run rust code on my bootleg mainframe 2021-02-23 19:37:07 being respectful is always good - and is a part of our CoC 2021-02-23 19:37:47 anwyay, my goal is to identify problem areas and find solutions 2021-02-23 19:37:54 .NET core being the latest one 2021-02-23 19:38:27 i basically just keep an ear out on twitter for what pain points people are having 2021-02-23 19:38:40 although this rust thing was a personal pain point (: 2021-02-23 19:41:21 [12:31:05] "play nicer and listen to us, or we'll just stop packaging you" 2021-02-23 19:41:33 at this point, stop packaging rust means we lose like half the packages in the distro 2021-02-23 19:41:45 yay gtk 2021-02-23 19:41:55 a lot of commonly used project have jumped on the rust train 2021-02-23 19:42:03 and, rust itself is not a bad language 2021-02-23 19:42:24 i mean, personally, i'd rather just write ML in a real ML dialect instead of something bastardized to look like C++ but whatevs 2021-02-23 19:42:32 right, which is why several distros need to do this together, to have real leverage 2021-02-23 19:42:49 individually no distro will ever do this 2021-02-23 19:42:50 i want rust to be a successful project 2021-02-23 19:43:08 i just also want rust to be more understanding of distro lifecycle 2021-02-23 19:43:16 I want it to be a successful project iff it adopts good engineering practices 2021-02-23 19:43:28 the engineering practices are improving 2021-02-23 19:43:46 skarnet: i think its a good idea that distros join together to deal with the rust challenges. I just dont have the energy to get involved too much 2021-02-23 19:44:27 I doubt many distros would be too keen on fighting Rust and I doubt even more that most upstreams would care 2021-02-23 19:44:56 librsvg alone is a huge reason to need Rust (and a very nice usecase for Rust) 2021-02-23 19:45:43 not 'fighting' rust 2021-02-23 19:46:04 there are plenty of people on the rust side which, legitimately, want to learn more about life as a distro maintainer 2021-02-23 19:46:44 that's good 2021-02-23 19:46:59 besides, having a dialog with that one guy who basiclaly posted "fuck distros" that ncopa subtweeted was productive 2021-02-23 19:47:26 and i got to use the anecdote of the diaper-wearing furry gentoo user who decided to harass me with death threats when gentoo decided to replace XMMS with audacious back in 2007 ;) 2021-02-23 19:47:37 :) 2021-02-23 19:47:43 (that was totally a thing that happened) 2021-02-23 19:48:21 sigh... 2021-02-23 19:48:39 seems like the releases I pushed are not getting uploaded to dl-master 2021-02-23 19:48:48 i wonder if it is the tcp kernel issue or something 2021-02-23 19:48:53 er.. no its not 2021-02-23 19:49:04 probably just slow upload 2021-02-23 19:49:29 i want shut down my computer for the day 2021-02-23 19:49:52 ncopa: you do that 2021-02-23 19:50:43 it's ok 2021-02-23 19:51:01 i have a halfway built trebuchet 2021-02-23 19:51:15 several computers are going to get trebuchet'd 2021-02-23 19:51:28 :D 2021-02-23 19:51:57 yeah, im gonna sign the releases and do the docker images tomorrow. have a good night! (and dalias: thanks again for that mdadm fix!) 2021-02-23 19:52:09 this damn mellanox switch that decided to be DOA today 2021-02-23 19:52:17 is probably going to be trebuchet'd 2021-02-23 19:52:22 unless i can RMA it 2021-02-23 19:54:14 oh, btw, thank you all for creating and maintaining a really nice distro that is steadily improving, I'm happy to be able to contribute 2021-02-23 19:58:02 I'm not sure that removing rust is bad idea 2021-02-23 19:58:29 resident luddite mps here 2021-02-23 19:58:37 haha just kidding 2021-02-23 19:58:41 hehe 2021-02-23 20:25:50 i didnt follow the discussion. anyone up to tell me whats wrong with rust? i dont know much about it 2021-02-23 20:28:32 it's c++ with a condom 2021-02-23 20:29:44 lol 2021-02-23 20:56:09 g0r3, huge build times, almost impossible to bootstrap from source, no stable API, missing support for many archs, microdependencies, and it's creeping into a lot of mainstream packages. could well result in the death of many smaller distros that can't keep up with the rust shit. 2021-02-23 20:57:17 ACTION adds bundled llvm to the list 2021-02-23 20:58:24 also if you got a rust dependency in your build-from-source distro, you suddenly need 8 GB ram and a fast multicore cpu to build 2021-02-23 20:58:28 orbea: right 2021-02-23 20:59:28 i already see myself maintaining a fork of curl just to avoid that 2021-02-23 20:59:49 curl has no hard dependency on rust, and I don't think it will ever will\ 2021-02-23 21:00:00 yeah that won't happen 2021-02-23 21:00:06 librsvg is a bigger problem 2021-02-23 21:00:34 the current rust integration is just some optional backends 2021-02-23 21:00:38 root of these problems is C++ 2021-02-23 21:00:50 mps, why? 2021-02-23 21:01:41 because C++ is bad and its heirs trying to be better 2021-02-23 21:02:12 the infrstructure around c++ is significantly better 2021-02-23 21:02:29 and it has a standard 2021-02-23 21:02:46 orbea: yes, but there all this started 2021-02-23 21:03:13 rust is just an ever moving target. the source you wrote last year won't compile anymore with latest rustc 2021-02-23 21:03:18 I doubt that anyone in the world understand C++ 2021-02-23 21:03:38 Hm, the source would probably still build unless you use nightly features 2021-02-23 21:06:24 They're not changing existing (stable) API, but they're adding new API, so you may need a newer rust to build new packages 2021-02-23 21:08:20 sh4rm4^bnc: Linus long time ago banned C++ in kernel, I think with good reasons. Hope he will persist 2021-02-23 21:11:53 Sure, but Rust has been allowed for kernel modules now, sooo 2021-02-23 21:12:20 and it might become required in mesa 2021-02-23 21:13:02 Cogitri: I don't think so. which module is built with rust? 2021-02-23 21:14:26 https://lwn.net/Articles/829858/ 2021-02-23 21:16:03 these are intentions, not yet accepted 2021-02-23 21:16:48 rip linux 2021-02-23 21:19:20 when finnish guy says "I'm open in principle"... 2021-02-23 21:19:49 artok: that means .... ? 2021-02-23 21:21:08 not happening soon 2021-02-23 21:21:18 ..if at all 2021-02-23 21:21:50 "kattellaa" 2021-02-23 21:21:54 :) 2021-02-23 21:23:02 iirc, similar was when C++ was discussed for kernel 2021-02-23 21:23:14 no, it was like "fuck off" 2021-02-23 21:23:34 hard to translate that meaning, but it is "we shall (might) see..." 2021-02-23 21:23:40 that was before linus got castrated 2021-02-23 21:24:06 sh4rm4^bnc: nowadays 'fuck off' is written as "I'm open in principle" 2021-02-23 21:24:23 lol 2021-02-23 21:24:23 you know, political correctness :) 2021-02-23 21:28:49 sh4rm4^bnc: what do you mean with > no stable API? 2021-02-23 21:29:19 i mean that you can't compile rust 1.14 with rust 1.12 2021-02-23 21:31:05 you can't build C11 with C99 either 2021-02-23 21:31:30 And the version requirements are only that strict for bootstrapping rustc itself 2021-02-23 21:31:47 the issue is much more that rust releases happen too often and projects using Rust are too eager to use new features 2021-02-23 21:32:07 It's really not that bad, since the API instability is not APIs changing under your feet, but new APIs getting added still 2021-02-23 21:32:21 Cogitri: which can also be a pain; would be nice if bootstrapping rust from a way older version were possible 2021-02-23 21:32:39 ericonr, i can build gcc 4.7.4 just fine with gcc 3.4.6 2021-02-23 21:33:08 Yes, would be neat if bootstrapping rust was simpler 2021-02-23 21:33:27 didn't i hear yesterday in here that latest firefox fails to build with latest rust 1.50 2021-02-23 21:34:18 That's firefox using unstable Rust in-code ASM 2021-02-23 21:34:54 But to be quite frank the bootstrapping not that bad, we don't do upgrades other than last version to most recent version in edge anyway and can bootstrap new releases from edge 2021-02-23 21:38:36 "not that bad"....it doesn't even support stable llvm releases. 2021-02-23 21:38:45 ericonr, you can't build a c11 program with a c99 compiler but you can build a c11 compiler with a c99 compiler 2021-02-23 21:39:56 dalias: yes, I believe I misinterpreted. I took it to mean "compile a rust program using 1.14 features with a 1.12 compiler" 2021-02-23 21:40:10 but sh4rm4^bnc seems to have been talking about the compiler itself 2021-02-23 21:40:24 the big problem is bootstrapping the compiler 2021-02-23 21:40:31 orbea: ? You can build rustc 1.50 with LLVM >= 8 AFAIK 2021-02-23 21:41:11 rust bundles a modified llvm which it depends on 2021-02-23 21:41:23 Yes, but you don't have to use that 2021-02-23 21:41:53 yea, but if you don't have the modified llvm some things stop working 2021-02-23 21:42:14 I haven't ever noticed things which stopped working with system llvm 2021-02-23 21:42:16 rust should just stop doing that and test exclusively against an stable llvm version 2021-02-23 21:43:14 https://bugs.gentoo.org/735154 2021-02-23 21:43:44 They do test against stable llvm versions 2021-02-23 21:44:15 But also ship a vendored version to get the latest fixes in too since LLVM tends to be more tested with the C/C++ frontends 2021-02-23 22:33:52 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:34:02 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:34:06 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:39:52 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:39:59 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:40:04 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 2021-02-23 22:45:23 ekh13VWpqvWGHyjyRNaWZ5jThEzCExtbaI9nPu222Y1xzHAm8Rq3wDzQMt9Roj1ti64qB9LlTQUPGApwC0RQ35p6y0geA5hFwPk0Acd3OkZDPOP45rCah4LW 2021-02-23 22:45:32 G8Q7elcmewAVAn3jYygJFy31gwFZSmluAwhbjGSOc2vS33pxjdfVVyLXmMaymZgxECfTYHRfg8ykzDido7NLVISBm3buoQA0LWGxDqTLeaWxTCmoIszuFtfZ 2021-02-23 22:45:37 TsFsyWLKpo2NyilDMOwMSFsAEX1wp3rqg9kCzymschou3OOTJrviU9olWqhPB9Cb9TmDRFah8c0nwXwww27OZGQ6vmMv5QWeaMntKqmgh8CGZEMztVGpDJNr 2021-02-23 22:45:47 7xPJhG8gVgIHLZ0DUTruskES8oKeCdB91Tsvli9Mq7R1LCD00t0t3kkGmkGYHTeX19ScXT5wT37Heh7JUDB3wkKarU1h1dvGewA3BOrIR0W1w9iOhLqBWNhn 2021-02-23 22:48:52 Huh 2021-02-23 22:51:15 r82R4yOnytSZHHYrhShHDjPObThY5MW8ZamJaLUD15seL48iK8VarEu7YbLsGxnBP2Lp1hOJVyHMCKOprwmRDeOssE7ETowgAQcaWNANJxuOK89yiFfrvhJG 2021-02-23 22:51:21 MrpBm9jZNa4hjw4k8GsxUW31eb0rMTRJOi6dHTQgCiySTmLVE2YwNqP44wcSaFQsuhO7y3vtYFSnpkyT3Na6tpb0d2smLDLZuXrXPXPrWEUWLdtZ382aMGWj 2021-02-23 22:51:25 s5gXWUij5Zmateun2IC2CmKLefH3yGu0CQrBdmtsY3w5YXPtXLddSn4dM6lkvhqPvFwlPQusmnKDaUwr46EyEe3GhsCSsHj8CCRONVnjKLYH9kc4j5Lzbtk0 2021-02-23 22:57:36 someone let out their scripts 2021-02-23 22:58:44 same happening in #musl 2021-02-23 23:12:06 qeeZJNfWpsmygXQ8EB3rVSE23FRsowOuKN3cktUnJQQgKv8OJfySGgr4r 2021-02-23 23:12:11 zPYgsoSl3y4k4cIm14br5d0kAO3DWoc6M5RSy797iY1LChUm3Hlgndkju 2021-02-23 23:12:17 9V8smc1hDzz4LbkVvQjmKhKuEkXRKcI3bMG3u8MfeewzLZln5kRqDDVCh 2021-02-23 23:12:22 0q0ivTMEjM07zfIDah2HpjjFxd9TjFJd0Vpe6UAa2TgKWCcMu2JOB68Mm 2021-02-23 23:12:29 ujD6jLKHnUbwVQezxNXaetrvhrbT6juTPsyrGgOyXqtZHtUs1dFAVFmBb 2021-02-23 23:47:16 Hello, me again 2021-02-23 23:47:35 What's the policy when dealing with software that generates a sample configuration file? 2021-02-23 23:48:22 Should I include one within the package and store at /etc? 2021-02-23 23:48:34 Or should I let the user pick one up, whenever he finished installing? 2021-02-24 00:29:52 eletrotupi: what package? 2021-02-24 00:31:04 satellite, a gemini browser 2021-02-24 00:36:39 oh, cool 2021-02-24 00:36:59 I'd say "$pkgdir"/usr/share/"$pkgname" 2021-02-24 00:37:38 looks like that in the Makefile too 2021-02-24 00:40:41 but the README.md also says "By default, Satellite uses `/etc/satellite.toml`.." 2021-02-24 00:42:45 perhaps both? so the user could edit /etc/satellite.toml and still have a default config to look at in /usr/share/satellite/satellite.toml 2021-02-24 00:42:52 but I don't know what policy is 2021-02-24 00:57:29 Yeah, that's what I thought as well 2021-02-24 00:57:49 Will go with that route, thanks omni 2021-02-24 05:46:20 hey everyone o/ if anyone can please take a look at my PRs 2021-02-24 05:46:50 !18694 !18695 !18696 2021-02-24 05:47:03 for 18695 and 18696 to pass, 18694 is needed 2021-02-24 05:47:29 Please have them all in a single MR with multiple commits, CI will work correctly that way 2021-02-24 05:47:47 alright i'll do that 2021-02-24 05:51:34 done, please check it out 2021-02-24 06:26:55 merged 2021-02-24 06:30:58 thx 2021-02-24 06:34:06 maxice8: qpdf has 1 test failure 2021-02-24 06:34:25 yes, couldn't reproduce it locally 2021-02-24 06:42:18 fails for me as well 2021-02-24 06:45:08 LANG=C 2021-02-24 06:45:15 because libstc++ is stupid 2021-02-24 06:45:37 or at least, that's what I had to do with qpdf 2021-02-24 06:46:05 ericonr: thanks, testing it 2021-02-24 06:50:20 yes, that fixes it, thanks 2021-02-24 07:06:10 np 2021-02-24 07:23:58 eletrotupi: sample file usually goes to -doc if they are not needed for program to run 2021-02-24 07:24:12 files* 2021-02-24 09:06:47 I don't know, there are a lot of sample files under /usr/share/$pkgname/ and they belong to their corresponding main package 2021-02-24 09:07:33 which mode do i set to get rid of these spam msgs? 2021-02-24 09:10:23 clandmeter: I think +R 2021-02-24 09:10:42 nice, someone introduced a bug to libusb back in april 2020 so libimobiledevice won't find your new ipad/phone 2021-02-24 09:10:48 i call that a security feature 2021-02-24 09:11:06 alexy: :) 2021-02-24 09:11:58 <*puts his $500 lightning cable back to the box> 2021-02-24 09:17:24 morning 2021-02-24 09:17:37 morning 2021-02-24 09:17:48 morning ;) 2021-02-24 09:18:06 Or almost lunch 2021-02-24 09:18:10 if you use a $1 cable, apple blocks it after a week, you HAVE to buy the $50 cable 2021-02-24 09:18:15 heh 2021-02-24 09:18:32 can't imagine what happens when tim cooks start building toilets 2021-02-24 09:19:12 it probably won't flush any toilet paper unless it's certified and cost 50x 2021-02-24 09:21:35 omni: yes, I saw a lot of unnecessary files under /usr/share 2021-02-24 09:22:45 packagers inertia from other distros or not understanding of alpine packaging principles - small .... 2021-02-24 09:29:33 it's not documented and if you then look at other packages for reference you see that a lot put sample/example files under /usr/share/$pkgname and you think that is fine 2021-02-24 09:30:02 the files themselves are mostly small, so you'd think that it's fine 2021-02-24 09:31:03 omni: right, but packager should think about 'small' principle 2021-02-24 09:31:42 but in days when alpine strive to debian famous 'dependency hell' all this is not important :( 2021-02-24 09:31:44 and they might think they do, not knowing that mps would disagree 2021-02-24 09:32:33 omni: they should understand meaning of 'small, simple' words 2021-02-24 09:32:34 dependencies are a different subject 2021-02-24 09:33:31 please document someplace what you mean by 'small, simple' so that it can be referenced and cannot be misunderstood 2021-02-24 09:33:41 omni: subject is *small* 2021-02-24 09:34:19 omni: you are kidding with me :) 2021-02-24 09:35:15 if people cannot understand basic meaning of words ...... (I will not write rest, hiding behind CoC) 2021-02-24 09:37:08 the subject was "is sample files under /usr/share/$pkgname/ ok or should they always go under /usr/share/doc/$pkgname and shouldn't that, if so, be clearly documented policy" and "what other packages a package depend on (that could lead to "dependency hell")" is another subject 2021-02-24 09:37:30 hehe 2021-02-24 09:39:49 "small" as a principle is vague and subjective 2021-02-24 09:41:00 for peoples who do not understand meaning of words, yes 2021-02-24 09:41:30 mps: lol I was curious what you meant by debian dependency hell so i looked it up 2021-02-24 09:41:46 "The Debian dependency system is powerful enough to play sudoku on it using aptitude and dose3. In fact, our dependency system is so expressive that it is interesting enough for scientists to research the topic. Unfortunately, because of its complexity it is often hard to talk about Debian dependencies without knowing the underlying terminology." 2021-02-24 09:42:38 🤢 2021-02-24 09:43:34 alexy: good definition which I didn't know (so thanks for finding it), but I talk from personal experience 2021-02-24 09:44:01 our dependency system is so expressive that it is interesting enough for scientists to research the topic -> no, just no. 2021-02-24 09:44:01 This is gold: "Binary packages can be real (Debian policy §7.5 also calls them "actual" or "concrete") or virtual. We are mostly talking about real binary packages, so when we are just talking about a "binary package" we usually mean a real binary package. If we want to talk about virtual binary packages, we explicitly point out that the binary package is virtual. If we want to talk about both, we say "real and virtual binary packages"." 2021-02-24 09:44:06 I'll happily talk package dependencies as well (but that is not where the discussion began, it just slid in) 2021-02-24 09:44:40 I think I removed some unnecessary dependencies from a package I upgraded, but I haven't seen much of that in alpine 2021-02-24 09:46:01 omni: yes, that's fine, and tbh sometimes I also put some 'cruft' there because I'm not sure what to do 2021-02-24 09:46:40 but that doesn't mean we should forget to strive to 'small, simple' 2021-02-24 09:52:48 btw are there docs on how apk works (from a technical POV) 2021-02-24 09:53:08 or just the code is the docs? 2021-02-24 09:53:14 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2021-02-24 09:53:57 i mean the manager itself 2021-02-24 09:54:30 not the apkbuilds 2021-02-24 09:54:31 like, under-the-hood? that the man pages don't cover? 2021-02-24 09:54:39 yes 2021-02-24 09:56:38 Is there any ETA on Python 3.9 in Alpine? 2021-02-24 09:57:18 travankor: not sure... 2021-02-24 09:57:21 haha https://wiki.alpinelinux.org/wiki/Apk_internals 2021-02-24 09:58:40 lmao 2021-02-24 10:03:44 PureTryOut[m]2: there seem to be some ongoing work https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16892 2021-02-24 10:04:21 Ah cool thank you! 2021-02-24 10:04:36 perhaps they need help, haven't looked at it 2021-02-24 10:09:01 I think we wanted to decide if we want to change the triplet before upgrading 2021-02-24 10:10:46 I think we should change the triplet 2021-02-24 10:11:18 maybe i should have a look at python 3.9 next week 2021-02-24 10:11:33 we need to get it done soonish so its included in the 3.14 release 2021-02-24 10:11:51 we should also get llvm11 in soonish 2021-02-24 10:13:06 Define soon-ish 2021-02-24 10:13:21 I can look into it in ~2 weeks if no one beats me to it 2021-02-24 10:14:55 soonish ~2 weeks 2021-02-24 10:15:18 Okie, I can do it then 2021-02-24 10:21:31 I'm thinking of taking maintainership of the orphaned ocaml package, but I don't use e-mail much and don't want to put a private adress I use there 2021-02-24 10:21:55 I've put "omni " in some, so that people at least know where to find me 2021-02-24 10:22:14 does that email work? 2021-02-24 10:22:40 don't think so, just wanted to please the linter ;D 2021-02-24 10:23:15 Well, the linter complains about that for a reason 2021-02-24 10:23:16 but the community/ocaml package seem a bit more important, perhaps someone would try to sen an email 2021-02-24 10:23:27 I think there's a user email in Gitlab too 2021-02-24 10:23:47 hmm.. perhaps @users.gitlab.alpinelinux.org ... 2021-02-24 10:24:08 I'll look into this 2021-02-24 10:24:54 omni: fwiw, im super happy with your work on ocaml. thank you! 2021-02-24 10:29:14 ^__^ 2021-02-24 10:31:19 @Cogitri I got some changes here that need reviewing please https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18285 2021-02-24 10:31:28 maxice8: ^ 2021-02-24 10:31:55 Essentially move ossec-hids-* packages to community and apply a patch so it builds with gcc-9 and -10 2021-02-24 10:32:35 Ah, sorry, I'm currently pretty busy since exams are nearing, but maybe I'll have time for it at the weekend 2021-02-24 10:53:23 the mail server at gitlab.alpinelinux.org replies with "User doesn't exist", so I guess I cannot use omni@gitlab.alpinelinux.org in any meaningful way 2021-02-24 11:01:00 I don't think that gitlab will provide an e-mail address for users 2021-02-24 11:03:17 Hm, somehow I thought we already had a similar thing happening where a user used some gitlab provided email 2021-02-24 11:04:07 gitlab or github? 2021-02-24 11:05:15 I think that was in the Gitlab days already 2021-02-24 11:09:41 the llvm11 testsuite has 11 tests that fails now :-/ 2021-02-24 11:10:04 sorry, 8 tests 2021-02-24 11:11:47 Is that increasing? 2021-02-24 11:13:21 well, thats comared to llvm10 2021-02-24 11:20:06 ah ok 2021-02-24 11:46:09 Ok why does algitbot in #alpine-commits ignore me? 2021-02-24 11:49:13 PureTryOut[m]2: probably you need to register your nick on freenode 2021-02-24 11:54:14 where / when? 2021-02-24 11:54:23 I don't see any message from you on #alpine-commits 2021-02-24 11:56:01 maybe channel is in restricted mode so nobody can see messages from unregistered people 2021-02-24 11:56:42 +nt, so I don't think so 2021-02-24 11:57:23 sending private messages wont work for those people too since now everyone got +R automaticly (because of spams) 2021-02-24 12:39:16 mps: well, they are needed for those programs to run 2021-02-24 12:39:36 Both of them need to be generated using the compiled binary 2021-02-24 12:40:49 eletrotupi: both or just one under /etc 2021-02-24 12:40:52 I was somewhat mislead by this https://gitlab.alpinelinux.org/help/user/profile/index?target=_blank#commit-email 2021-02-24 12:41:17 but I'll set up an email address for this and other things and start using that more 2021-02-24 12:41:21 it would be strange for program to use config file under /usr/share 2021-02-24 12:41:23 perhaps even join the lists 2021-02-24 12:42:31 I've seen that miniflux ships a config file directly with the APKBUILD, and place there 2021-02-24 12:42:44 mps: we're talking about https://git.sr.ht/~gsthnz/satellite 2021-02-24 12:42:47 Is this a better option than generate manually with the compiled binary? 2021-02-24 12:42:52 yes, some pkgs do 2021-02-24 12:43:00 Yes, and honza/smithy as well 2021-02-24 12:43:27 xorg-server is famous of this (buggy) behavior 2021-02-24 12:43:32 I'm packaging for my private repo first (also to understand how it all works), then I think it would be nice to add to aports (community) 2021-02-24 12:44:06 I think it's a more sensible thing to do (ship a sample config file directly with the package) 2021-02-24 12:44:35 s/with the/within the/ 2021-02-24 12:44:35 eletrotupi meant to say: I think it's a more sensible thing to do (ship a sample config file directly within the package) 2021-02-24 12:44:46 eletrotupi: yes, if they 'must', ofc I agree 2021-02-24 12:45:00 nice, thanks mps 2021-02-24 12:45:11 you are the best 2021-02-24 12:45:14 eletrotupi: np :) 2021-02-24 12:45:39 haha, no I'm not, though I strive to this 2021-02-24 17:23:26 ncopa: do you think changing the triplet for python can mesh well with the python manymusl stuff? it's been rather quiet lately, but I would assume they still have plans to push the whole thing forward 2021-02-24 17:23:50 manymusl or manylinux? 2021-02-24 17:24:02 or is manymusl their plan to support musl? 2021-02-24 17:24:43 yeah manylinux is too attached to glibc already, so the working idea was to call it manymusl 2021-02-24 17:25:27 hmm, the pre-PEP uses musllinux actually, sorry 2021-02-24 17:25:39 https://discuss.python.org/t/pre-pep-platform-tag-for-linux-distributions-using-musl/7165 2021-02-24 17:47:59 "How many libs do we rip on the daily? Many, money, say me many many many" 2021-02-24 17:48:30 s/money/musl/ =) 2021-02-24 17:48:30 omni meant to say: "How many libs do we rip on the daily? Many, musl, say me many many many" 2021-02-24 18:02:40 All that shines turns to rust, all that stands in time turns to dust. 2021-02-24 18:04:23 I vaguely remember a time when Firefox was the obvious choice 2021-02-24 18:05:10 2.x something? 2021-02-24 18:05:25 then chrome came, google bought firefox, and now we have 'telemetry' when I click something on it, like it's a fking sports game 2021-02-24 18:05:52 omni: it died somewhere around 3.x 2021-02-24 18:07:44 yeah, it felt like they began fixing their low release numbers rather than issues 2021-02-24 18:08:12 death by thousand cuts, first it was the addons, then they jumped on the 'new version every week' train 2021-02-24 18:09:10 and now we have 20 pages user.js and the damn thing is still spying and singing like a bird 2021-02-24 18:09:11 the new firefox mobile is a joke, can't ctrl-anything or read the source of a page 2021-02-24 18:09:37 I doubt many users need that 2021-02-24 18:10:08 I for one think the new FF mobile is super nice aince it's like 10x faster than the old ff 2021-02-24 18:10:10 yeah, possibly an exaggeration or two there ;) 2021-02-24 18:10:12 and now rust 2021-02-24 18:10:25 I can't even hack the source without waiting hours to see an error 2021-02-24 18:10:47 Incremental compilation after the first go needs only a few seconds 2021-02-24 18:11:56 ahh, guess I can't use dabuild for that 2021-02-24 18:13:09 You can, but instead of dabuild -r you can do dabuild build, then it won't clean the source dir 2021-02-24 18:13:33 ahh 2021-02-24 18:13:45 And Chromium takes even longer to build than FF still :/ 2021-02-24 18:13:54 So imho Rust's still a better choice than C++ 2021-02-24 18:18:30 probably 2021-02-24 18:19:18 seeing a cisco addon in a fresh FF install just gives me a warm and fuzzy feeling 2021-02-24 18:22:46 Well, it's an OSS one, that's Cisco paying H264 royalties for you 2021-02-24 18:26:04 disable addon -> checks youtube -> works 2021-02-24 18:26:11 what is it doing there? ;) 2021-02-24 18:26:56 YouTube uses VP9 2021-02-24 18:27:00 Not H264 2021-02-24 18:27:24 Most websites still use H264, so video probably won't work on most websites without that plugin (e.g. on Twitter) 2021-02-24 18:30:04 you have a good heart Cogitri :) 2021-02-24 18:30:31 this channel is not #complain-about-firefox or #complain-about-rust 2021-02-24 18:30:47 please take that elsewhere 2021-02-24 18:31:56 sorry :) 2021-02-24 18:32:42 in fairness, the H264 addon is possibly a problem, but since the browser downloads it itself... 2021-02-24 18:34:04 "Cisco provides an OpenH264 codec (as a source and a binary), which is their of implementation H.264 codec, and they cover all licensing fees for all parties using their binary. This codec allows you to use H.264 in WebRTC with gstreamer and Firefox. It does not enable generic H.264 playback, only WebRTC (see Mozilla bug 1057646)." 2021-02-24 18:34:23 It's useless. 2021-02-24 18:34:44 yeah, i think h264 comes from gst 2021-02-24 18:35:02 does gst not get used with WebRTC? 2021-02-24 18:39:41 yeah this openh264 seems very useless 2021-02-24 18:39:57 however, if we remove it, it may trigger trademark review from mozilla 2021-02-24 18:40:03 sooooooo 2021-02-24 18:40:36 the real question is whether or not we want to play that game 2021-02-24 18:41:14 If we wanted to we could it ourselves I think 2021-02-24 18:41:23 But IIRC that's kind of a pain 2021-02-24 18:42:22 there is also the current gray area of shipping h264 support in alpine 2021-02-24 18:42:32 h264 is very aggressively patented 2021-02-24 18:45:15 hmm i thought FF dropped gstreamer back in 16' or something 2021-02-24 18:45:37 yeah sorry i misspoke, it uses ffmpeg directly 2021-02-24 18:45:56 either way, point being, the h264 video does not appear to go through that plugin regardless 2021-02-24 18:48:58 For decades I've never used FF for WebRTC (i assume it means video/audio conferences/chat), nor have I seen anyone use it in FF, I think office people use IE for that 2021-02-24 18:50:03 i do use FF for that (via BigBlueButton) 2021-02-24 18:50:23 the question is not whether breaking WebRTC is acceptable (it isn't) 2021-02-24 18:50:44 the question is whether OpenH264 actually impacts WebRTC performance 2021-02-24 18:51:19 nice, so it's actually not completely useless ;) 2021-02-24 18:57:04 (WebRTC) 2021-02-24 18:57:20 i'm pretty sure even webrtc goes through ffmpeg on alpine 2021-02-24 19:13:49 Is it bad to use paxmark ? 2021-02-24 19:15:24 who was the poor bastard trying to build mongodb on alpine? 2021-02-24 19:17:21 meee 2021-02-24 19:17:38 artok, Its builds now 2021-02-24 19:18:40 artok, ikke. Do you know what paxmark is used for? 2021-02-24 19:18:56 Ariadne: sorry! 2021-02-24 19:19:38 artok, Why do you ask? 2021-02-24 19:19:57 Jenkler: much o' patches done ? 2021-02-24 19:20:14 Jenkler: paxmark is used to allow certain things with grsec kernels 2021-02-24 19:20:28 I wouldn't mind try to dockerize that 2021-02-24 19:20:29 It's basically useless now that we don't offer grsec kernels anymore, so feel free to remove it 2021-02-24 19:22:33 Cogitri, in my APKBUILD for mongodb paxmark got removed. I just wonder why 2021-02-24 19:22:57 Cogitri, ahh useless 2021-02-24 19:23:06 Thats why 2021-02-24 19:24:03 artok, it took a few days. But in my case i learned about the alpine build system 2021-02-24 19:24:08 Jenkler: I removed it and as Cogitri already explained it is useless so I don't have to repeat 2021-02-24 19:24:36 artok, but check in non-free/mongodb 2021-02-24 19:25:09 Its builds, i have not verified that everything works but it looks fine 2021-02-24 19:25:18 mps, thanks 2021-02-24 19:27:13 mps, maybe we should remove paxmark from the tree if its useless 2021-02-24 19:28:22 artok, I kept most om the old patches. But I do not know if they all is needed anymore. 2021-02-24 19:29:07 Jenkler: maybe, but this is on BDFL imo 2021-02-24 19:29:09 artok, feel free to build it in a chroot with abuild -r. 2021-02-24 19:29:27 BDFL ? 2021-02-24 19:30:02 Benevolent Dictator For Life 2021-02-24 19:30:42 though he is much too benevolent imo :) 2021-02-24 19:31:13 mps, ahh ;) 2021-02-24 19:31:42 mps, have you tried to build it after the changes you made? 2021-02-24 19:32:35 Jenkler: yes, and it worked on x86_64 but not on aarch64 2021-02-24 19:32:50 We should remove paxmark sometime down the line but it doesn't hurt to have it and may still be useful to someone 2021-02-24 19:33:25 mps, Yes I only added arch="x86_64" 2021-02-24 19:33:56 the unitest scripts was also broken so i skipped the check function 2021-02-24 19:34:13 Cogitri: this was response from BDFL on proposal to remove paxmark, iirc 2021-02-24 19:35:14 Jenkler: yes, but anyway I tried on aarch64 but it failed somewhere near the end, and I didn't preserved build log 2021-02-24 19:36:07 It's not really expensive to keep it, so yeah 2021-02-24 19:36:20 Might be a good idea to remove it from APKBUILDs though 2021-02-24 19:36:24 mps, the next person that need aarch64 may help to patch ;) 2021-02-24 19:36:55 Jenkler: yes, that is what I also think 2021-02-24 19:37:55 Cogitri: yes, I thought to run grep -r paxmark after removed it from mongodb but forgot, a lot of things in the queue 2021-02-24 19:39:44 Could you maybe open an issue? Then I can look into it after exams 2021-02-24 19:40:01 Why is tab prefered in APKBUILD. I always use 2 space. Then it always looks the same in terminal and other places 2021-02-24 19:40:28 Consistency 2021-02-24 19:41:29 ikke, I used to use tabs in everything. But I migrated everything to 2 space ;) 2021-02-24 19:41:31 Liliput VS Blefuscu 2021-02-24 19:41:47 Jenkler: in some sense it doesn't matter 2021-02-24 19:41:51 somebody chose it and now you're sticking with it :) 2021-02-24 19:42:11 sam_, Yeah i guess so ;) 2021-02-24 19:42:31 Easy to convert in vim anyway so ... 2021-02-25 02:10:16 Ariadne: any restrictions on re-enabling go packages in mips(64) or can just be done ? 2021-02-25 05:11:08 maxice8: go for it, we see what breaks i guess 2021-02-25 09:20:09 Maybe https://lwn.net/Articles/847256/ is interesting for us too 2021-02-25 09:24:57 heh, when I got mail announcing debianfod (few days ago) I expected that someone will propose similar for alpine :) 2021-02-25 09:26:07 I have feeling that I'm going back to debian by small steps despite my OS is alpine 2021-02-25 09:26:54 Ok how did py3-zipp pass CI and instantly fail on all arches on builders... Wtf 2021-02-25 09:28:57 Oh huh, it didn't pass CI and the MR didn't get merged, but the commits just appeared in the master branch anyway? 2021-02-25 09:29:22 fcolista: what happened there? 2021-02-25 09:31:18 py3-zipp will need https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16899/diffs?commit_id=7c2899029636792218a76ed1e39278b52432eaa1 to build properly 2021-02-25 09:33:00 PureTryOut[m]2, yes. My mistake, sorry 2021-02-25 09:33:19 Np but you might want to consider merging the commit I linked above 2021-02-25 09:33:27 As that'll fix it 2021-02-25 09:33:39 Yes that's what I'm going to do it. I've overlooked that part, sorry again 2021-02-25 09:33:51 Np, I'm not responsible for `main/` anyway 😜 2021-02-25 09:35:16 Tbh I don't like a single patch for all these changes 2021-02-25 09:35:37 Uh I can split it out if you want 2021-02-25 09:36:01 yes please, is more readable 2021-02-25 09:36:11 less prone to errors (like the one i've just done :) 2021-02-25 09:37:07 PureTryOut[m]2, please split the one that fixes py3-zipp, going to merge it 2021-02-25 09:37:08 Thanks! 2021-02-25 09:37:48 I would put the patch for $package in the same commit that allows $package to build, next time 2021-02-25 09:40:34 !18706 now just contains the patch to fix the build, nothing more 2021-02-25 09:42:03 But... it's broken, wut 2021-02-25 09:42:09 Oh wait, never version ofc, give me a sec 2021-02-25 09:43:12 patch contains trailing spaces too 2021-02-25 09:47:42 We should consider moving py3-zipp to community actually. There is nothing in main depending on it and 3.4.0 has more deps on community packages 2021-02-25 10:04:36 Ariadne: `CTARGET=mips64-alpine-linux-musl abuild -r` should do the trick for building Rust, shouldn't it? Seems like it's trying to build for x86_64 for me but then link with mips64 tools: https://paste.gnome.org/psefulm8b 2021-02-25 10:25:07 fcolista: ok redone !18706. The obsolete dep of pluggy on zipp has been removed, build has been fixed, APKBUILD has been modernize, moved to community and upgraded. All in separate commits 2021-02-25 10:26:27 And if I temporarily enable tests of pluggy locally, they all pass fine without zipp so yes it was obsolete 2021-02-25 10:28:28 Cogitri: I think this should work, iirc when I worked on making it on arm 2021-02-25 10:29:54 Huh 2021-02-25 10:48:19 !18213 I'd like to continue with other ocaml-packages (rebuild, add archs, upgrade) but want/need this to be merged first 2021-02-25 11:36:04 why are some python packages named py3-py$name? 2021-02-25 11:37:53 Because they're called that way upstream 2021-02-25 11:39:42 ah, thanks! 2021-02-25 11:48:44 Some packages have the py bit removed which confuses the heck out of me sometimes. It happened multiple times that I packaged stuff that was already packaged but called differently in our repositories 2021-02-25 11:48:58 whenthe: are you a bot? 2021-02-25 11:51:04 ? 2021-02-25 12:03:52 There is this Matrix user, whenthe, that instantly reads every message posted here according to the read marker. And has been doing so for multiple weeks now 2021-02-25 12:04:43 aha 2021-02-25 12:05:04 i run that bot btw, it pretty much just a irc logger 2021-02-25 12:05:16 mystery solved 2021-02-25 12:05:19 Oh, might consider naming it more obvious then 2021-02-25 12:05:28 Also, afaik there are already IRC logs for this channel somewhere 2021-02-25 12:05:42 https://irclogs.alpinelinux.org/ 2021-02-25 12:05:54 And well the Matrix room history in itself is a log that can be viewed with stuff like matrix-static 2021-02-25 12:06:01 Ah yes that one, thanks 2021-02-25 12:06:59 also, that bot has been running for longer 2021-02-25 12:46:07 PureTryOut[m]2, thanks. Still, having all this patches in one MR messed up the readibility. 2021-02-25 12:46:39 Really? How? They are all related and everything is split into individual commits. I fail to see how it's hard to read 2021-02-25 12:48:18 sorry for my bad english...it was not meant the latest commits (yes, they are related and I've just merged them). I'm referring to the other commits like py3-signedjson and py3-jsonschema 2021-02-25 12:48:48 I should have used /still/ :) 2021-02-25 12:50:13 eletrotupi: usually put in /etc and let config protection take care of it 2021-02-25 12:52:56 omni: you need to actually enable private commit email, not randomly make one up 2021-02-25 12:54:37 Ariadne: gentoo has an option for disable gmp-openh264. not sure if it actually works 2021-02-25 12:55:47 Cogitri: abuild uses scanelf instead of readelf because ??? 2021-02-25 12:56:42 I wouldn't know that, I haven't done much in abuild :) 2021-02-25 12:57:04 i asked ncopa and i think he said he doesn't really know why 2021-02-25 12:57:39 if anyone likes shell script too much you could try to rewrite it. many of those loops are super inefficient 2021-02-25 13:05:15 Hello71: mail me 2021-02-25 13:05:27 wat 2021-02-25 13:05:40 according to the docs it works the same way as github 2021-02-25 13:11:32 oh, I see... in the _commits_ sorry 2021-02-25 13:16:28 like so? 2021-02-25 13:17:24 Hello71: Not sure if a rewrite is worth it, especially if we'd do it in Shell again anyway 2021-02-25 13:17:39 imho abuild is plenty fast, installing packages and building takes way longer anway 2021-02-25 13:17:42 it's probably easier just to install pax-utils 2021-02-25 13:17:44 Hello71: that use flag only set: media.gmp-gmpopenh264.autoupdate to false so ye it doesnt work 2021-02-25 13:49:32 Hello71: I think we should start expanding the abuild test suite. That will make it easier to make such changes in the future. 2021-02-25 13:49:57 omni: well if you make a commit and it has the email address 2021-02-25 13:50:01 and people can send email to the address 2021-02-25 13:50:17 it's not like gitlab can tell if people got the address from the commit message or someone else 2021-02-25 13:50:43 ikke: perhaps, although building aports seems adequate (if slow) 2021-02-25 13:51:21 But you have to manually verify everything 2021-02-25 13:52:46 hm, good point. i guess you can check if it exited 0 but that's not a great indicator that it worked 2021-02-25 13:52:54 No 2021-02-25 13:53:09 There's a lot more that has to be right 2021-02-25 13:53:20 yes, it could create all packages empty or something 2021-02-25 13:53:41 performance optimization :p 2021-02-25 13:53:44 Not trace any dependencies 2021-02-25 13:53:56 yes yes i see your point 2021-02-25 14:03:58 Should new versions of desktop applications/games be backported to stable releases? 2021-02-25 14:05:01 For example Minetest 5.4 does include some security fixes, but it also includes a bunch of other non-security things and I personally don't really feel like cherry-picking those specific fixes and nor do I think most people playing Minetest want to stay on an old version 2021-02-25 14:05:11 99% of the time no especially if they are in community repo 2021-02-25 14:05:22 Why so? 2021-02-25 14:05:27 https://alpinelinux.org/releases/ "The main repository is typically supported for 2 years and the community repository is supported until next stable release." 2021-02-25 14:05:48 Hello71: I updated my local git config and my commits in most of my open merge requests 2021-02-25 14:06:22 Yeah, but on, say, the latest release (3.13). Would it make sense to backport new versions of desktop applications? 2021-02-25 14:07:50 for community repo i think it's basically maintainer's discretion 2021-02-25 14:08:01 fair enough 2021-02-25 14:09:45 i don't think we have real policy in this area, basically just main = high priority for fixes and avoiding regressions, community = kinda meh 2021-02-25 14:10:41 i think community/firefox is applied to latest release even for "major" bumps because they move too fast 2021-02-25 16:25:34 oh, ocaml 4.12.0 was released yesterday, I'll see if I can just bump in the MR 2021-02-25 16:35:25 let me know if you need to do any whacking to make tests run 2021-02-25 16:35:30 they didn't work for me on first go so I postponed it 2021-02-25 17:51:40 is it allowed $pkgname in url 2021-02-25 17:59:37 so if you rename the package the url is broken? 2021-02-25 17:59:39 but sure 2021-02-25 17:59:52 I'm pretty sure the linter will yell at your for that 2021-02-25 17:59:58 So it's preferred not to use $pkgname in the url 2021-02-25 18:01:39 The linter checks the source 2021-02-25 18:01:41 not the url\ 2021-02-25 18:09:10 I'm playing a little with script to check urls and some other things in aports and found some number of pkgs with $pkgname in url 2021-02-25 18:09:55 example 'asciidoctor "https://rubygems.org/gems/$pkgname" 404 Not Found' 2021-02-25 18:12:33 some people have a strong urge to do s/packagename/$pkgname/g in their aports 2021-02-25 18:13:15 even this 'apache-mod-fcgid "http://httpd.apache.org/$_pkgreal/" 404 Not Found' 2021-02-25 18:13:24 $_pkgrel 2021-02-25 18:13:33 $_pkgreal 2021-02-25 18:19:41 maxice8: valse positive in apkbuild-lint: https://tpaste.us/zxmN 2021-02-25 18:20:54 "valse positive" means "positive waltz" in French 2021-02-25 18:20:57 it complains that GOFLAGS is overwritten 2021-02-25 18:21:02 which is something I'd totally dance 2021-02-25 18:21:32 hehe :D 2021-02-25 18:21:50 valse is dutch for false 2021-02-25 18:22:05 (vals) 2021-02-25 18:24:09 My brain thinks: "false", my vingers type "valse" 2021-02-25 18:25:04 should I ask how you say "fingers" in Dutch? 2021-02-25 18:25:56 I guess you don't have to :P 2021-02-25 18:26:39 how to make Dutch: take a generic Germanic/Saxon language, add a bit of sugar, water and mold, put it in a cave, wait a couple centuries 2021-02-25 18:28:57 Something like that, yes 2021-02-25 18:30:45 OT, dutch ~ deutsch? 2021-02-25 18:31:24 deutsch with a bit of mold 2021-02-25 18:32:44 nvm, last weekend I enjoyed 'big' lunch and a lot of drink (and babbling) with two Dutchmen :) 2021-02-25 18:32:53 duits / deutsch == german 2021-02-25 18:33:01 dutch != german 2021-02-25 18:34:04 or it is 'big meal' 2021-02-25 18:43:51 skarnet: ouch 2021-02-25 18:52:04 2021-02-25 18:54:13 sam_: thanks, I managed to get the tests sorted the other day for 4.11.1 and now I think I've got everything working for 4.12.0 \o/ 2021-02-25 19:08:39 list of main APKBUILDs with 'problematic' url https://tpaste.us/X1zJ 2021-02-25 19:08:54 no sure if all but most are 2021-02-25 19:10:10 mps: you got ratelimited on git.a.o 2021-02-25 19:11:03 looks like :) 2021-02-25 19:11:12 for whoever maintains MPD: https://github.com/MusicPlayerDaemon/MPD/pull/1110 and 1111 2021-02-25 19:42:39 actually dutch is a 20% english 20% german 10% french and 50% something alien 2021-02-25 19:45:35 spoken like a true yZ5vlALg86lP 2021-02-25 19:47:49 they have words like capuchon, levancier, and cadeau. and the 50% alien words are like oorlog - meaning war, and not having any relation to de/en/fr 2021-02-25 19:48:24 yZ5vlALg86lP: levancier? do you mean leverancier? 2021-02-25 19:48:47 uhh. the bitgnomes stole some of my bits... 2021-02-25 19:49:12 yes, i meant that 2021-02-25 20:03:02 ikke: that is a known problem, happens with any usage of substitution ${var/x/} 2021-02-25 20:03:26 yup 2021-02-25 21:12:11 Why all the hate on dutch 2021-02-25 21:13:48 https://en.wikipedia.org/wiki/Poe%27s_law 2021-02-25 21:13:48 [WIKIPEDIA] Poe's law | "Poe's law is an adage of Internet culture stating that, without a clear indicator of the author's intent, it is impossible to create a parody of extreme views so obviously exaggerated that it cannot be mistaken by some readers for a sincere expression of the views being parodied. The original statement..." 2021-02-25 21:14:29 Ah 2021-02-25 21:29:48 exception: ime, Dutch is most kind and friendly people in continental europe 2021-02-25 21:32:49 Nice 2021-02-25 22:50:55 there was some discussion the other week wrt listing CVEs/secfixes: in the APKBUILD, what was said/concluded? 2021-02-25 22:56:43 wdym? 2021-02-25 23:00:39 should they be or not? 2021-02-25 23:01:06 I understand the comments could be interesting if you backport secfixes into packages 2021-02-25 23:02:08 but do you need to update the list of secfixes if you follow the upstream release without added security patches? 2021-02-25 23:02:56 Yes 2021-02-25 23:02:59 always 2021-02-25 23:03:03 always add the CVE entries 2021-02-25 23:03:14 ok, thanks 2021-02-25 23:23:50 the discussion was perhaps around additional security tracking TLAs 2021-02-25 23:49:23 Hey - who's best to talk to about what appears to be a GCC packaging bug? 2021-02-25 23:54:09 andyhhp__: just talk, interested in this will react probably, and be patient, most sleeps now 2021-02-25 23:57:00 so Xen has a recently-added alpine container in our CI for build testing 2021-02-25 23:57:57 we've got a failure on x86 which has caused a fair headacke, with at least one bug being ours (now fixed) 2021-02-25 23:58:59 not sure of it is related but I saw some fixes for xen in latest kernels, 5.10 and 5.11 2021-02-25 23:59:09 s/of/if/ 2021-02-25 23:59:09 mps meant to say: not sure if it is related but I saw some fixes for xen in latest kernels, 5.10 and 5.11 2021-02-25 23:59:34 we have certain binaries built by default, which are in-VM firmware 2021-02-25 23:59:58 and we use `gcc -m32 -ffreestanding`, as well as using some of the freestanding headers 2021-02-26 00:00:13 have to say, I don't have much experience with Xen 2021-02-26 00:00:31 thats fine - this is really a build system question 2021-02-26 00:00:57 we've tracked the problem down to something weird which is local to Alpine's GCC package 2021-02-26 00:01:03 i.e. it is a deviation from upstream GCC 2021-02-26 00:01:14 the order of system include paths has been edited 2021-02-26 00:01:23 aha 2021-02-26 00:01:55 and will prefer /usr/include over the system GCC local path 2021-02-26 00:02:36 hmm, we have some tweaks because musl needs them 2021-02-26 00:02:42 this breaks freestanding builds 2021-02-26 00:02:55 right - I was expecting it to be something like that 2021-02-26 00:03:27 so the problem is that musl's stdint isn't compatbile with -m32, but the stdint packaged with your GCC is 2021-02-26 00:04:05 and I know you don't package a 32bit libc - that's fine - freestanding builds don't interact with libc at all 2021-02-26 00:04:55 what GCC expects is to include its own stdint.h first, which has conditional logic based on __STDC_HOSTED__, and reaches out to /usr/include for hosted builds 2021-02-26 00:04:59 I didn't looked and touched gcc after 9.2 series, so wait for someone else to help you 2021-02-26 00:06:16 though yes, that looks like need to look at it 2021-02-26 00:06:32 so I guess the real question is whether anyone knows why the include order was swapped 2021-02-26 00:09:01 i wonder if you should be using x86 instead 2021-02-26 00:10:19 if we were making hosted 32bit binaries, yes 2021-02-26 00:10:24 but that isn't the case 2021-02-26 00:10:27 I think you've already opened an issue for that, right? 2021-02-26 00:10:42 Maybe ncopa can take a look at that tomorrow 2021-02-26 00:10:51 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12477 was opened by a colleage of mine, but I thought I'd try and provide more background 2021-02-26 00:11:35 heh, I saw issue and wondered is that related 2021-02-26 00:11:36 Oh, maybe you could add that to the issue? Stuff on IRC gets lost easily and searching IRC logs isn't fun :) 2021-02-26 00:13:06 tru dat. I just prefer to talk to humans first ;) 2021-02-26 00:17:06 Ah sure, but most European folks sleep by now :) 2021-02-26 00:17:17 Oh, and I should do the same, sooo :p 2021-02-26 00:18:20 I mean, so should I... 2021-02-26 00:30:22 is the best way to implement something like systemd's service ExecStartPre in openrc to add another init script and set "before " ? 2021-02-26 00:41:40 (other than just replacing the init script outright.. which I don't want to do since it belongs to another package) 2021-02-26 00:49:27 I'm looking to basically enable some piece of hardware iif some service is set to start automatically (so, not enabling the hardware if the service is *not* being started) 2021-02-26 01:04:15 the point of execstartpre is that you don't need another service 2021-02-26 01:04:43 and also it has simpler semantics than bindsto/after 2021-02-26 01:06:54 right, but I'm not finding any succinct way to get that same functionality with openrc other than either 1) fork the service init script and modify it, or 2) make a new service that is 'before' the other 2021-02-26 01:07:17 #2 sucks because it won't know if the service it's doing setup for is even enabled to start 2021-02-26 01:09:23 well that's what depends is for 2021-02-26 01:09:44 openrc doesn't have systemd's requiredby which might be a good thing 2021-02-26 01:10:32 depends if good if I want to modify the orignal init script for the service 2021-02-26 01:10:45 but, since that is owned by another package, that's not great 2021-02-26 01:12:06 I'm working on a new package, fwiw. so overwriting an init script from another package (which I could technically do by setting provides=...) wouldn't be very nice to maintain 2021-02-26 06:55:31 morning 2021-02-26 07:00:12 andyhhp__: hi, i do remember the build of 32 bit binary on 64 bit host problem. I was not aware about gcc preferring /usr/include 2021-02-26 08:20:25 ncopa: Hi, for info, I worked on Alpine support for DPDK: https://patches.dpdk.org/project/dpdk/list/?series=15388 2021-02-26 08:21:07 Do you think it should become a package in Alpine? 2021-02-26 08:56:30 tmonjalo: thank you for following that up! I appreciate that. IIRC there are a few packages that already use dpdk 2021-02-26 08:57:34 Such packages are compiling DPDK? 2021-02-26 08:57:39 ceph uses it, but they bundle the dpdk sources 2021-02-26 08:57:42 yup 2021-02-26 08:57:57 I wonder whether it makes sense to have packages dpdk and dpdk-dev 2021-02-26 08:58:22 might be 2021-02-26 08:58:38 I could work on it if you want 2021-02-26 08:59:07 we could check if there are any other specific users 2021-02-26 08:59:48 i mean, i think it makes sense to create dpdk package if there are things that can actually use it 2021-02-26 09:00:00 OK 2021-02-26 09:00:02 so if ceph can use system dpdk, then yes, absolutely makes sense 2021-02-26 09:00:23 i have a feeling that i have seen other projects use it, but i can not remember 2021-02-26 09:00:35 do you know other projects using dpdk? 2021-02-26 09:00:41 Oh yes :) 2021-02-26 09:01:04 https://www.dpdk.org/ecosystem/#projects 2021-02-26 09:01:33 One of the most famous is OVS 2021-02-26 09:03:11 yeah, its probably there that I have seen it 2021-02-26 09:03:50 For non-open projects, dpdk-dev would makes sense 2021-02-26 09:04:29 so , if openvswitch and/or ceph can build with system dpdk, then I think we can create an alpine package 2021-02-26 09:04:44 otherwise i think we can wait til someone actually asks for it 2021-02-26 09:05:02 i mean, it does not make much sense to package it just because we can 2021-02-26 09:05:11 OK, I've started looking at how to create an Alpine package. 2021-02-26 09:05:41 I will follow up probably in a month, when fixes will be merged in DPDK. 2021-02-26 09:05:52 great, thank you 2021-02-26 09:06:10 what i think might make sense though is add dpdk CI with musl libc 2021-02-26 09:06:28 Yes, that's my first goal 2021-02-26 09:06:38 So musl support won't break anymore 2021-02-26 09:07:43 that would be great 2021-02-26 09:07:58 looks like ovs can be built with system dpdk: https://src.fedoraproject.org/rpms/openvswitch/blob/rawhide/f/openvswitch.spec#_95 2021-02-26 09:08:59 ceph probably not 2021-02-26 09:09:52 i think ceph vendor spdk which vendors dpdk 2021-02-26 09:10:29 yep 2021-02-26 09:22:45 im looking over the patches again 2021-02-26 09:23:19 i think its pretty cool, because in most cases, those changes leads to better over-all code 2021-02-26 09:46:01 yes, except for cpu_set_t requiring _GNU_SOURCE 2021-02-26 09:46:13 Is it a POSIX constraint? 2021-02-26 10:01:21 !18213 2021-02-26 11:18:30 tmonjalo: yes i think cpu_set_t is not in POSIX 2021-02-26 11:25:09 omni: good job! is it ready to merge? 2021-02-26 11:32:53 ncopa, andyhhp__ : musl doesn't support multilib, to compile 32 bit binaries you can't use -m32 but a toolchain specifically targeting i?86, e.g. mcm 2021-02-26 11:35:10 ncopa: I beleive so, since your last approval I've also added opam to the MR, so that that too is rebuild against the new version and targeting all archs but mips64 2021-02-26 11:54:10 sh4rm4^bnc: this isn't multilib 2021-02-26 11:54:36 -ffreestanding specifically severs the connection with libc 2021-02-26 11:54:46 so musl's view on the matter isn't applicable 2021-02-26 13:07:28 in that case i'd like to hear dalias opinion on the matter 2021-02-26 13:45:04 would it be possible to merge !18488 ? 2021-02-26 14:06:00 sh4rm4^bnc, i followed up on the issue 2021-02-26 14:06:13 ncopa, too 2021-02-26 14:10:00 thanks, ftr this is the link https://gitlab.alpinelinux.org/alpine/aports/-/issues/12477 2021-02-26 14:16:02 andyhhp__, i think that's a valid perspective but not how it's specified and not one we take 2021-02-26 14:17:29 -ffreestanding just means compiling for a freestanding environment (as defined in the spec, where identifiers that would be reserved in a hosted one are not reserved adn the compiler cannot assume their presence or semantics); the way that's achieved is not further specified 2021-02-26 14:18:16 the musl headers *are* compatible with freestanding use, just not (without further path setup by the distro to make it work) multilib/multiarch 2021-02-26 14:18:55 i think multiarch is a somewhat wanted feature for alpine but it's nontrivial to add 2021-02-26 14:23:25 dalias: imo it is important thing to have 2021-02-26 14:23:56 it is not* 2021-02-26 14:24:18 sorry for confusion 2021-02-26 14:26:35 if one needs a 32 bit toolchain once can bootstrap it with mcm in a few minutes, or download it e.g. from http://ftp.barfooze.de/pub/sabotage/bin/musl-cross-4.4.7-2019-10-22/ - 6.6 MB 2021-02-26 14:27:53 alpine's doing the -nostdinc thing already for some packages that want to build some freestanding -m32 code 2021-02-26 14:28:15 but that depends on them not happening to pull in anything that needs libgcc functions (long division, soft float, etc.) 2021-02-26 14:28:38 since the gcc is not a multilib gcc and does not have 32-bit target libs 2021-02-26 14:29:15 and that's exactly the case here - there is nothing interesting - its a tiny bit of 32bit bootstrapping logic for VMs 2021-02-26 14:29:45 the -nostdinc route is painful, and we really don't want to be shipping our own stdint.h 2021-02-26 14:30:46 the stdint packaged with GCC (and Clang's equivlent) work correctly 2021-02-26 14:39:54 andyhhp__: hi, I was planning to look at the gcc git log today because i think the behavior is in upstream gcc, but been busy with other stuff 2021-02-26 14:40:08 so I did actually find it last night 2021-02-26 14:40:35 this behaviour was upstreamed into GCC (and Clang, I presume) as part of musl support 2021-02-26 14:40:50 thats what i thought 2021-02-26 14:41:40 the question is how to properly solve it 2021-02-26 14:42:40 in alpine's xen package we actually ship and our own stdint.h 2021-02-26 14:43:00 yeah, and someone tried upstreaming that into Xen, which is what kicked off this whole mess :) 2021-02-26 14:43:11 but it would be good to solve it upstream (either musl, gcc or xen or all three) 2021-02-26 14:43:38 shipping our own local stdint isn't viable, because we support a range of non-GNU environments 2021-02-26 14:44:00 so, i guess we need to figure out where and how this should be solved 2021-02-26 14:45:24 and i guess fixing the gcc headers so musl can use those isn't an option for -m32 -ffreestanding? dalias? 2021-02-26 14:46:30 you can do a multiarch/multilib include dir setup 2021-02-26 14:46:39 but then you have to install the headers for the other arch 2021-02-26 14:46:55 the conceptual issue here is that Alpine has difference in behaviour in how gcc's -ffreestanding works 2021-02-26 14:47:14 andyhhp__, no, difference in behavior from how glibc works 2021-02-26 14:47:15 not gcc 2021-02-26 14:47:18 i dont think its alpine specific. i think its musl specific 2021-02-26 14:47:22 gcc is exactly like this on every non-GNU system 2021-02-26 14:47:38 and the Xen build works fine there 2021-02-26 14:47:46 its not a glibc thing 2021-02-26 14:47:57 xen runs on freebsd? 2021-02-26 14:48:01 i think netbsd at least 2021-02-26 14:48:04 and netbsd 2021-02-26 14:48:07 and solaris 2021-02-26 14:48:28 i'm not sure if solaris uses a bsd style header order but netbsd does 2021-02-26 14:48:39 anyway the header order cannot be changed 2021-02-26 14:49:19 -nostdinc is not the right way to do this, but if you want to do that, it does not require shipping your own stdint.h 2021-02-26 14:49:38 i guess we'd need mutiarch/multilib dir setup 2021-02-26 14:49:49 but i'd prefer not make this a alpine-only solution 2021-02-26 14:50:06 debian has something like it already 2021-02-26 14:50:17 debian does full multilib 2021-02-26 14:50:19 their /usr/include does not have bits directory right in it 2021-02-26 14:50:30 as a bodge, `-nostdinc -I/usr/lib/.../include/` does work 2021-02-26 14:50:31 it has /usr/include/$tuple/bits 2021-02-26 14:50:44 andyhhp__, right, and there's a way to automate finding the dir 2021-02-26 14:50:59 alpine does not really support multilib 2021-02-26 14:51:23 if you make gcc search those paths and pick the right one according to -m32 (i'm not sure if this has upstream support or it's debian multiarch patches) then it will work fine 2021-02-26 14:51:25 dalias: is there? that might be an interesting approach 2021-02-26 14:51:38 andyhhp__, i think it involves -print-file-name 2021-02-26 14:52:51 this works, but i'm not sure that it's "supposed to" in principle: 2021-02-26 14:52:55 gcc -print-file-name=include 2021-02-26 14:53:07 the reason it works is because it's the dir named "include" in gcc's library path 2021-02-26 14:53:55 i wonder if would make sense to on multilib arches (like x86_64) musl also install the 32bit x86 headers in different directory, and then patch/upstream gcc to use that dir when -m32 is specified 2021-02-26 14:54:16 or have a `make install-multilib-headers` or similar in musl 2021-02-26 14:54:16 yes, that would be a simple minimal solution 2021-02-26 14:54:40 i think it only affects x86_64 right? 2021-02-26 14:54:45 just have musl-32bit-dev package or something on 64-bit archs 2021-02-26 14:54:46 possibly aarch64? 2021-02-26 14:54:54 and install the headers from there 2021-02-26 14:55:48 and patch gcc -m32 to use the alternate header & lib dir 2021-02-26 14:55:50 however 2021-02-26 14:56:11 just having an empty include dir for it to use with -m32 would make this particular usage case (freestanding only) work 2021-02-26 14:56:33 i'd prefer upstream it to musl and gcc 2021-02-26 14:57:01 the reality is that -m32 -ffreestanding does already work, other than this order-of-includes issue, so it is 99% there 2021-02-26 14:57:52 will -m32 -ffreestanding work with musl if the include order is swapped? 2021-02-26 14:57:58 will musl work with those headers? 2021-02-26 14:58:59 with the order swapped, a freestanding build never leaves the GCC-packaged headers 2021-02-26 14:59:15 i guess we could patch gcc in that case to swap the order when -m32 -ffreestanding is specified 2021-02-26 14:59:17 so never opens a musl-packaged header 2021-02-26 14:59:33 (at least, in the experiments I tried while investigating) 2021-02-26 14:59:45 but to my understanding the gcc headers does not work with musl 2021-02-26 15:01:02 ncopa, no 2021-02-26 15:01:07 musl will not work if the include order is swapped 2021-02-26 15:02:13 yes i think you could patch gcc to just drop the libc header dir when -m32 is used 2021-02-26 15:02:31 it's not even really "patching"; you can just do this with a specs file i think 2021-02-26 15:04:35 question is if that can be upstreamed in gcc 2021-02-26 15:07:45 hmpf... we have already 39 patches for gcc in alpine 2021-02-26 15:09:09 ncopa: on a tangent, we've got a number of fixes in Xen 4.15 which will reduce your patchqueue 2021-02-26 15:10:03 has anyone considered upstreaming the initscripts? We've got SYSV/Systemd and upstart upstream in Xen, and would have no problem with taking support for other init systems 2021-02-26 15:11:39 looks like our init.d scripts are from gentoo originally 2021-02-26 15:11:44 for xen 2021-02-26 15:14:43 ncopa, i'm not sure that's desirable as an upstream change 2021-02-26 15:15:27 really the change that should be upstreamed is using separate include paths for -m64 vs -m32 when multilib is enabled 2021-02-26 15:15:35 and erroring out on -m32 if multilib is not enabled 2021-02-26 15:16:11 we also have a custom specs file 2021-02-26 15:16:23 ACTION blindly assumed that that would already be the default behaviour... 2021-02-26 15:18:56 i find it kinda interesting that clang does not swap the order for either freebsd or openbsd, but swap the order for musl (or alpine) 2021-02-26 15:19:03 i guess maybe if *not* built with multilib and if it's not gonna error out, it should suppress library include paths when using -m32 2021-02-26 15:19:30 ncopa, i wonder if clang has conflicting headers in its include dir to begin with 2021-02-26 15:20:27 the underlying principle here is that the "gnu system" splits responsibility for headers up between gcc and glibc; they cooperate in their implementation internals 2021-02-26 15:21:07 musl and aiui openbsd and netbsd do not have this sort of relationship with gnu header internals and provide the full set of headers 2021-02-26 15:21:18 right /usr/lib/clang/10.0.1/include does not have any stdint.h 2021-02-26 15:21:30 *nod* 2021-02-26 15:23:47 huh - that's weird. clang 10.0.0 does provide a stdint.h 2021-02-26 15:24:32 on alpine linux, indeed 2021-02-26 15:24:47 on freebsd it doesnt 2021-02-26 15:25:29 andyhhp__: does aarch64 have the same problem? 2021-02-26 15:25:43 or is this exclusively an x86_64/x86 problem 2021-02-26 15:26:07 maybe it does just for *-linux-* ... 2021-02-26 15:26:32 dalias: sounds plausible 2021-02-26 15:26:58 personally i think the easiest solution unless you really want to get multiarch working is just pass -nostdinc -isystem $($CC -print-file-name=include) 2021-02-26 15:27:01 ncopa: not sure. the ARM ecosystem has real processors with no 32bit support in 2021-02-26 15:27:29 so there's no such thing as a lowest-common-demoninator for bootstrapping 2021-02-26 15:27:46 but this may not be suitable for upstream since it might not work with clang or other OS's.. ? 2021-02-26 15:27:54 it's fine for the alpine package tho 2021-02-26 15:28:43 would be nice if xen could build on void linux and others too 2021-02-26 15:28:49 i mean upstream xen 2021-02-26 15:29:04 I would like to get upstream working without hacks 2021-02-26 15:29:11 +1 2021-02-26 15:29:36 i think fixing gcc to use a separate dir for -m32 may be a good option 2021-02-26 15:31:02 andyhhp__: im looking at the alpine's init.d scripts. they are kinda ugly 2021-02-26 15:31:06 at least some are 2021-02-26 15:34:52 one really stupid thing you can do without gcc involvement... 2021-02-26 15:34:58 make a wrapper bits header set that does 2021-02-26 15:35:07 #ifdef __x86_64__ (or whatever) 2021-02-26 15:35:19 #include 2021-02-26 15:35:21 #else 2021-02-26 15:35:28 #include 2021-02-26 15:35:29 #endif 2021-02-26 15:35:40 you mean in alpine or xen? 2021-02-26 15:35:52 in alpine of course 2021-02-26 15:36:14 i dont think this is a really good approach but it's a shim for gcc upstream (without debian patches) not doing multiarch right 2021-02-26 15:36:29 maybe debian-style multiarch is upstream now tho 2021-02-26 15:40:55 so, the real issue here is that -m32 requires proper multilib and alpine (musl?) does not really support multilib 2021-02-26 15:42:27 i guess another option would be to provide a 32 bit crosscompiler and use that? 2021-02-26 15:43:11 musl does not support the very limited gcc model (what "multilib" traditionally refers to) where a 64-bit arch and older 32-bit arch it's associated with are treated as one "arch" by gcc with shared set of include files and just different lib files 2021-02-26 15:43:46 the intended usage is to do proper "multiarch" where they can both includes & libs can vary if you want to use the same compiler for both 2021-02-26 15:43:47 that is, fix xen build system to take a different $CC for the -m32 parts 2021-02-26 15:43:50 this is what debian does 2021-02-26 15:44:14 or, of course, just use a separate cross compiler for the foreign 32-bit arch 2021-02-26 15:44:18 that's what works now 2021-02-26 15:44:39 except that xen build cannot use a separate compiler for the 32bit stuff 2021-02-26 15:45:07 i see 2021-02-26 15:45:28 it would probably be nice if it could 2021-02-26 15:45:37 well - I mean, we could, but that would be full of hacks, no? 2021-02-26 15:46:07 we do split HOSTCC away from CC, for doing cross-compiles of the hypervisor 2021-02-26 15:46:08 no, just passing CC32=i386-linux-musl-gcc or whatever should make it work fine, if you had a separate CC32 (or whatever you'd call the var) 2021-02-26 15:46:15 *nod* 2021-02-26 15:46:41 so perhaps a HOSTCC32 ?= $(HOSTCC) would go a reasonable way here 2021-02-26 15:46:43 so CC32 ?= $(CC) 2021-02-26 15:47:17 i always mix HOSTCC vs CC :) 2021-02-26 15:47:18 part of the problem with Xen is that half of it is a Linux kernel-derived build system, and half of it is an autoconf project 2021-02-26 15:47:38 yeah and linux and autoconf/gnu have opposite conventions for what host means :-p 2021-02-26 15:47:50 because back in the day, this repo contained every fork of every piece of software used in a Xen system 2021-02-26 15:48:11 we've got multiple copies of old Linux and FreeBSD kernels in the history 2021-02-26 15:48:59 one of my longterm goals is to be able to cleave it in two, and separate "the hypervisor" from "all the tools and utilties" 2021-02-26 15:54:24 its friday over here 2021-02-26 15:54:59 and my brain has already switched to weekend-mode 2021-02-26 15:55:46 andyhhp__: i appreciate that you are reaching out and want solve this properly. i want to support that, the best way i can 2021-02-26 15:56:08 also thank you dalias for providing different options 2021-02-26 15:56:44 it would be good if we could collect those on the bug tracker, so they survive the weekend 2021-02-26 15:57:11 i am open to provid some kind of musl32-dev package for alpine if that helps 2021-02-26 15:57:15 no problem at all. I'd absolutely prefer to fix this nicely, than to continue piling up hacks 2021-02-26 15:57:23 +1 2021-02-26 15:58:21 i wonder if the proper solution is to add some sort of (partial?) debian-style multilib in alpine, 2021-02-26 15:58:37 but im afraid it might be a can of worms 2021-02-26 15:58:45 for now, the Alpine container in our CI is tagged as non-fatal. It is interfering with our patchew integration, but isn't blocking anything critical 2021-02-26 15:59:47 i guess alpine could patch the gcc to use a separate include for -m32 2021-02-26 16:00:00 but that might need some investigation 2021-02-26 16:00:07 how does debian do that for example 2021-02-26 16:00:20 :) part of me feels that that is only pushing the pile of hacks elsewhere 2021-02-26 16:01:08 right, but i guess the fundamental problem here is: to build 32bit code on an 64 bit machine you either need to: 1) cross compile 2) have support for multilib 2021-02-26 16:01:20 alpine did a decision to not support multilib 2021-02-26 16:02:07 well there are like 5 different things multilib or multiarch could mean :-p 2021-02-26 16:02:08 this would be far easier if we can probe for not-mutlilib by seeing whether -m32 works 2021-02-26 16:02:13 musl does not support the mixed multilib headers, but does support for debian-style multilib 2021-02-26 16:02:16 but that ship has sailed 2021-02-26 16:02:20 dalias: yeah good point 2021-02-26 16:02:51 just because alpine doesn't want to solve the difficult problem of being able to install 32-bit packages on 64-bit dist doesn't mean -m32 can't be made to work somewhat 2021-02-26 16:03:18 "work somewhat", with ephasis on "somewhat" 2021-02-26 16:03:41 the question is if upstream gcc and musl want support that 2021-02-26 16:03:41 well for example it could in theory even work "fully" if you provide your own 32-bit libs 2021-02-26 16:04:02 (just not having access to apk's to install from) 2021-02-26 16:04:21 righ. im willing to provide a musl32-dev package 2021-02-26 16:04:28 btw a really stupid workaround.. 2021-02-26 16:04:41 but i think we still need convince upstream gcc 2021-02-26 16:04:52 to pick the right include for -m32 2021-02-26 16:05:06 you can make a gcc wrapper to use for the 2 or 3 packages that care, that intercepts -m32 and adds -nostdinc -isystem $(gcc -print-file-name=include) 2021-02-26 16:06:45 i think the problem we want so solve here is not the alpine packages, it is upsteram xen that want their build of xen work out of the box with alpine/musl toolchain 2021-02-26 16:10:01 ok 2021-02-26 16:10:43 well i dont think that's going to automatically work on systems that aren't setup for multilib/multiarch even if *some* musl-based dists do 2021-02-26 16:11:19 so if that's part of the goal xen probably needs a way to either manually or automatically specify a different compiler or cflags for 32-bit.. 2021-02-26 16:11:32 or just do the -nostdinc thing unconditionally 2021-02-26 16:12:19 so i was thinking it might make sense to have a build time configure flag for gcc "here you find the 32bit headers" 2021-02-26 16:12:40 and have a `make install-headers32` for musl 2021-02-26 16:13:52 which means that both gcc and musl has some sort for official way to get -m32 work 2021-02-26 16:14:52 well musl just doesn't represent the relationship "arch Y is the 32-bit arch for arch X" 2021-02-26 16:15:22 but you can easily install-headers for ARCH=i386 2021-02-26 16:15:33 so its just make install-headers ARCH=i386 2021-02-26 16:16:02 (you should use a separate build dir for this since it will make intermediate files that conflict with use of the build dir for x86_64, but out-of-tree build works fine for this) 2021-02-26 16:16:15 that does not require any spcecial configure run? 2021-02-26 16:16:25 well ideally you'd just run configure to do it 2021-02-26 16:16:32 ok, i guess it actually does need a configure run 2021-02-26 16:16:49 mkdir build32 && ../configure CC="gcc -m32" && make install-headers ... 2021-02-26 16:16:57 erm 2021-02-26 16:17:03 mkdir build32 && cd build32 && ../configure CC="gcc -m32" && make install-headers ... 2021-02-26 16:19:15 ncopa: andyhhp__: a build using cross compilers would work perfectly for void, since we already have a cross suite of those 2021-02-26 16:19:43 setting CC32 or similar somewhere in the build 2021-02-26 16:20:56 we also use an x86_64 cross compiler when building 64bit GRUB for i686, for example 2021-02-26 16:24:21 re: rust 2021-02-26 16:24:39 hi Ariadne 2021-02-26 16:24:50 too many missing bits in 1.50 2021-02-26 16:24:57 going to focus on 1.52 instead 2021-02-26 16:25:03 i saw on twitter 2021-02-26 16:25:12 1.52 should be released by alpine 3.14 release deadline 2021-02-26 16:25:32 are they fixing the issues you bumped into for 1.52? 2021-02-26 16:25:48 or can you build from rusts git master? 2021-02-26 16:26:28 i mean so we make sure we get all the needed missing bits included in 1.52 2021-02-26 16:26:43 Ariadne: How does bootstrapping on other arches work for you? `CARCH="mips64-alpine-linux-musl" abuild -r` builds normal x86_64 rust for me but then tries to link with mips64 GCC 2021-02-26 16:26:56 ncopa: Would be too late for 1.52 now anyway since stuff goes through nightly and beta first 2021-02-26 16:27:15 Unless it's a bug fix that won't introduce regressions for sure 2021-02-26 16:28:38 after Alpine 3.14 the following release should be 3.141, then 3.1415 etc. 2021-02-26 16:28:51 +1 2021-02-26 16:29:14 and we should drop the 'r' in the rpi edition 2021-02-26 16:29:23 so alpine-pi-3.14 2021-02-26 16:30:55 all-pi-ne-pi-3.14 2021-02-26 16:33:44 skarnet: https://en.wikipedia.org/wiki/TeX "The current version of TeX is 3.14159265" 2021-02-26 16:33:44 [WIKIPEDIA] TeX | "TeX (, see below), stylized within the system as TeX, is a typesetting system (or a "formatting system") which was designed and mostly written by Donald Knuth and released in 1978. TeX is a popular means of typesetting complex mathematical formulae; it has been noted as one of the most sophisticated..." 2021-02-26 16:34:45 Cogitri: CHOST=mips64 2021-02-26 16:34:56 jvoisin: yup, but copying Knuth isn't a bad idea 2021-02-26 16:35:15 Cogitri: 1.52 tree is open right now. we expect to have everything needed for 1.52. 2021-02-26 16:35:29 1.52 is nightly 2021-02-26 16:35:32 1.51 is beta 2021-02-26 16:36:57 awesome 2021-02-26 16:36:57 the worst case is that alpine post-3.14 gets rust everywhere 2021-02-26 16:37:12 however, my plan is to focus on bootstrapping nightly 2021-02-26 16:37:17 and that is what i'm doing now 2021-02-26 16:38:03 patching the vendored crates is a possibility too, but 2021-02-26 16:39:05 Ariadne: Both CHOST and CTARGET? 2021-02-26 16:59:28 all you need is CHOST 2021-02-26 16:59:35 it will set CTARGET appropriately 2021-02-26 17:05:20 https://github.com/rust-lang/rust/pull/82556 is the upstreaming of our targets as dynmusl. 2021-02-26 17:07:53 Ariadne: do you mind a request to add i686 as well? 2021-02-26 17:10:30 Ariadne: Fancy 2021-02-26 17:11:37 ericonr: i do not 2021-02-26 17:13:41 do you prefer I add it in the PR or is here enough? 2021-02-26 17:15:27 i'll add it 2021-02-26 17:15:45 thanks :) 2021-02-26 17:26:02 who is petrochenkov 2021-02-26 17:27:28 is dynmusl the name for "manymusl"? 2021-02-26 17:27:54 no, this is for rust 2021-02-26 19:04:53 at any rate, if that person cockblocks this work, then i say fuck it, let the anti-rust people win the day 2021-02-26 19:12:44 the =\ face guy? 2021-02-26 19:14:18 apparently 2021-02-26 19:25:20 i am just saying, based on knowledge and experience with certain alpine contributors (: 2021-02-26 20:44:30 Hmm, nice, just found out that you can specify specific error codes to allow to fail with gitlab ci. That would us to specify certain linting violations to be more severe than others 2021-02-26 22:51:13 Looks edge x86-64 builder hanging 2021-02-26 23:12:44 andypost[m]: seems idle 2021-02-26 23:13:12 oh, pulling git 2021-02-26 23:15:02 oh, hmm 2021-02-27 03:30:39 FOR FUCK'S SAKE 2021-02-27 03:30:50 someone please ban that IP 2021-02-27 06:21:27 tehcloud: join/quit spam? 2021-02-27 06:22:59 ah ye, turned off smart filter and see that :D 2021-02-27 06:52:22 mort___: 2021-02-27 08:51:33 ppc64le CI 'went to lunch' 2021-02-27 08:53:03 2 long running jobs 2021-02-27 08:53:11 not sure if stuck 2021-02-27 08:53:44 well, 4h sounds like a bit much 2021-02-27 08:54:39 ok, np 2021-02-27 08:54:48 I canceled them 2021-02-27 08:58:12 490 2021-02-27 08:58:13 Pull requests 2021-02-27 08:58:14 508 2021-02-27 08:58:15 Actions 2021-02-27 08:58:15 Security 2021-02-27 08:58:16 Insights 2021-02-27 08:58:17 New issue 2021-02-27 08:58:47 shit sorry 2021-02-27 09:00:57 happens 2021-02-27 09:14:27 I cancelled my ppc64le CI job to free up resources 2021-02-27 09:22:41 The queue is empty again 2021-02-27 10:47:21 is there still any reason to keep paxmark around in APKBUILDs? since we haven't used the grsecurity patchset in ages I don't think it does anything anymore, right? 2021-02-27 10:47:46 nmeum: right 2021-02-27 10:48:32 !18852 I found a few aports in main/ which still use it, can also remove it from community/ and testing/ later on 2021-02-27 10:49:21 this is discussed here more than a year ago, and conclusion was to keep it if someone 'buy' grsec and then can have paxmark ready on alpine 2021-02-27 10:50:06 for aports pkgs it should be removed 2021-02-27 10:50:15 in makedeps I mean 2021-02-27 10:50:30 yeah, I remember that "conclusion" 2021-02-27 10:51:04 :) 2021-02-27 10:51:05 but we can't test aports with PAX anyhow, so in that case one would need to manually paxmark binaries either way 2021-02-27 10:52:30 some people have separate 'aports' local repos 2021-02-27 10:52:46 or that, yes 2021-02-27 10:53:04 but you agreet that there is no need to keep this in our upstream aports.git, right? 2021-02-27 10:53:07 *agree 2021-02-27 10:53:27 nmeum: you mean paxmark? 2021-02-27 10:53:39 yes 2021-02-27 10:54:11 we can keep the shell script itself, I rather mean the invocation of it in APKBUILDs :p 2021-02-27 10:54:13 I agree, and told this at time we discussed it, but BDFL wanted to keep it 2021-02-27 10:54:26 ah ok 2021-02-27 10:54:31 well 2021-02-27 10:54:33 ah, that something else 2021-02-27 10:54:45 hm? 2021-02-27 10:55:07 we should remove invocations of paxmark in aports APKBUILDs 2021-02-27 10:55:24 and also remove from makedepends 2021-02-27 10:55:33 ok, sweet that's what I want to do 2021-02-27 10:55:46 maybe keep the shell script in main/ then? 2021-02-27 10:55:59 now we agree completely 2021-02-27 10:56:04 great :) 2021-02-27 10:56:16 is it worth bumping $pkgrel for this? 2021-02-27 10:57:03 I doubt, ask maxice8 to add some checks in apk linter maybe 2021-02-27 10:58:52 uhm, abuild linter* 2021-02-27 10:59:41 adjusted the PR according to the things we discussed 2021-02-27 11:06:48 should I just merge it? 2021-02-27 11:07:56 ikke: ^ 2021-02-27 11:11:11 What do I need to do ? 2021-02-27 11:15:10 maxice8: looks like nothing, after I saw nmeums MR 2021-02-27 11:16:11 I thought that there are a lot more APKBUILDs with paxmark in makedeps 2021-02-27 11:16:46 maxice8: I found out that with our CI, we can specify exit codes that are allowed to fail, instead of the entire job 2021-02-27 11:17:16 So we could have some linting rules that would fail the entire CI instead of producing just a warning 2021-02-27 11:20:13 nmeum: MR looks ok for me 2021-02-27 11:25:12 mps: there are more in testing/ and community/ would change those separatly though 2021-02-27 11:25:38 ok 2021-02-27 11:26:19 but yeah, I don't think we need a linter rule for this 2021-02-27 11:27:15 People will not start adding this 2021-02-27 11:27:21 yep 2021-02-27 11:27:36 yes, I agree. and I agree with you of removal, looks like we didn't much about this 'issue' for more than a year or two 2021-02-27 11:30:41 ok, merged the change for main/ without pkgrel bump 2021-02-27 11:30:49 will quickly do the same for community 2021-02-27 11:43:41 b3b81b419e84c6f6f7a88adc5cc94ac01b2df777 2021-02-27 11:46:37 also removed it from 2 aports in testing/, no more paxmark invocations left \o/ 2021-02-27 11:47:52 \o/ 2021-02-27 11:50:00 Neat 2021-02-27 11:53:55 Cogitri: I'm still working on getting the buildlogs as artifacts, there are just some gotcha's I did not take into account 2021-02-27 11:56:43 ikke: Oh okie, thanks for working on that :) 2021-02-27 11:57:05 Posix sh has some nasty limitations 2021-02-27 12:44:05 dalias: when do you expect to release musl 1.2.3? 2021-02-27 12:50:02 nmeum: i think we can drop paxmark package 2021-02-27 13:02:14 I think we can remove some more packages 2021-02-27 13:02:48 lets remove rust :D 2021-02-27 13:02:52 haha just kidding 2021-02-27 13:03:47 hehe, maybe you are kidding, but I will support you if you decide to do that 2021-02-27 13:04:03 hahah jk... unless.... 2021-02-27 13:09:14 unfortunately, it is too late for that 2021-02-27 13:09:36 i am at this point framing our requirements as a matter of equity 2021-02-27 13:09:54 whoever did the initial rust musl bringup did not consult distros and ask for requirements 2021-02-27 13:10:12 and instead assumed people only used musl for static linking 2021-02-27 13:10:29 i think correcting this situation is something that will help a lot 2021-02-27 13:15:17 Ariadne: didn't we establish earlier that we need pax-utils for scanelf? or are we only dropping the pax-mark part 2021-02-27 13:15:41 Hello71: main/paxmark is unrelated to paxutils. 2021-02-27 13:15:52 grumble grumble 2021-02-27 13:17:02 anyway i opened #12483 for main/paxmark. if fabled wants to keep it, he can move the script itself out of aports into its own git repo. 2021-02-27 13:17:38 if his intention was that the script only be support infrastructure for aports, then it is now deprecated and should be removed. 2021-02-27 13:17:58 so, we see what he says :) 2021-02-27 13:21:13 previous week we discussed again (a little) paxmark removal and my impression is that ncopa want to keep it. we can talk again about this when he join again 2021-02-27 13:26:17 then it should have a real maintenance plan (: 2021-02-27 13:26:20 hince the bug 2021-02-27 13:44:39 Adran: doesn't hurt keeping the paxmark package around it's just a ~30 line shell script wrapper around attr(1) 2021-02-27 13:45:18 Ariadne: * 2021-02-27 13:45:28 who knows, maybe there is actually someone out there who purchased the grsecurity patch set and uses alpine with a custom kernel with that patchset applied :D 2021-02-27 13:49:26 nmeum: that was reasoning to keep it 2021-02-27 13:49:42 i find it unlikely 2021-02-27 13:49:44 I doubt that such a brave individual exists though :D 2021-02-27 13:49:46 but sure 2021-02-27 13:50:13 does not matter, the asan work justine tunney proposes will be much better than PaX anyway 2021-02-27 13:50:33 i would assume that grsecurity customers are primarly people who run their own embedded buildroot linux stuff. but idk 2021-02-27 13:50:42 Ariadne: uhhh, link? 2021-02-27 13:50:44 on the asan stuff 2021-02-27 13:50:53 most grsecurity customers use debian actually 2021-02-27 13:50:59 really? wow 2021-02-27 13:51:22 dreamhost is the largest customer and all of their infra is debian 2021-02-27 13:51:31 for 5.12 kernel kernel electric fence is merged 2021-02-27 13:52:02 strange written sentence but is correct :) 2021-02-27 13:52:35 nmeum: https://justine.lol/asanlinux 2021-02-27 13:52:58 ty 2021-02-27 13:53:56 ah, that's the author of cosmopolitan libc 2021-02-27 13:58:08 wasn't there some concern that asan is only for devs to find issues, since asan brings its own set of security issues? 2021-02-27 13:58:30 yZ5vlALg86lP: the standard libsanitize, yes 2021-02-27 13:58:41 they actually mention that no the linked web page 2021-02-27 13:58:49 > We intend to address any such concerns by using a trimmed-down runtime without the bells and whistles for release builds 2021-02-27 13:58:50 yZ5vlALg86lP: the goal is to provide a slimmed down asan that is suitable for production 2021-02-27 13:59:28 thx. interesting 2021-02-27 13:59:55 apart from performance asan should also impact memory usage and executable size though, but cool project for sure 2021-02-27 14:00:08 yZ5vlALg86lP: I think you are right, that the asan is for devs or bug hunters 2021-02-27 14:00:36 and not for 'normal' usage 2021-02-27 14:01:19 i read something of 1/8th extra mem usage on that page 2021-02-27 14:01:20 KFENCE, which is merged to 5.12 'can' be used on 'normal' kernels 2021-02-27 14:44:20 Cogitri: rust team counterproposes with fixing the -musl targets to behave the right way when on a musl host 2021-02-27 14:46:41 Makes sense, would be a pretty major break to change it now 2021-02-27 14:49:01 one of the people on the rust team was dumbfounded that nobody asked distros what they wanted when making the -musl targets to begin with 2021-02-27 14:49:12 and pushed to just fix them 2021-02-27 14:49:24 so -dynmusl isn't going to happen after all, and -musl is just going to be fixed 2021-02-27 14:52:06 good 2021-02-27 14:52:20 the "differently static by default" makes no sense 2021-02-27 14:52:26 if you want a static binary just pass -static 2021-02-27 14:52:28 same as all targets 2021-02-27 14:53:03 Sure, but it'll be a rather huge break from the previous behaviour, so my understanding was that they didn't want to do rhat 2021-02-27 14:53:24 *sigh* 2021-02-27 14:53:44 Cogitri: they are adding backwards compatibility code to handle that for glibc hosts 2021-02-27 14:53:54 ... 2021-02-27 14:53:59 so if you do rust build on a glibc host with musl, it will still be static 2021-02-27 14:54:11 that's so broken -- isn't it going to break the rather normal case of cross compiling? 2021-02-27 14:54:11 if you do rust build on musl host with musl it will be dynamic 2021-02-27 14:54:36 dalias: no, it will keep the behavior the same as it is now for cross compiling 2021-02-27 14:54:41 i'll certainly welcome if jart pulls off a musl-compatible asan runtime to be used with gcc (but only for testing code, not for compiling everything with it) 2021-02-27 14:54:46 the behavior now IS BROKEN 2021-02-27 14:54:53 yes, i agree 2021-02-27 14:55:01 but i don't care about glibc to musl cross :P 2021-02-27 14:55:05 if i want to cross compile for arm-linux-musleabihf and don't put -static i want dynamic binaries 2021-02-27 14:55:16 and doing that from glibc host is a fairly common thing ppl do 2021-02-27 14:55:37 for that case, you just use -C features=-crt-static 2021-02-27 14:55:42 as you do now :P 2021-02-27 14:55:50 ... 2021-02-27 14:55:59 no, now i don't use rust 2021-02-27 14:56:11 but if/when i do, i want it not to violate least-surprise in stupid ways 2021-02-27 14:56:27 of course i would assume the gcc frontend will get this right when it's working 2021-02-27 14:56:34 and i really don't plan to ever use the llvm implementation 2021-02-27 14:56:39 because i fucking hate llvm 2021-02-27 14:57:00 same here 2021-02-27 14:57:33 i assume sabotage does not even ship rust 2021-02-27 14:57:39 correct 2021-02-27 14:57:42 it seems... not compatible with sabotage's philosophy 2021-02-27 14:58:08 yeah, we can't bootstrap it from source, so ... *plonk* 2021-02-27 14:58:28 fortunately there's palemoon 2021-02-27 14:58:35 well you can if you don't mind going back to the ocaml days 2021-02-27 14:58:40 or gambling on mrustc 2021-02-27 14:59:37 you can't bootstrap rust from source? 2021-02-27 14:59:44 yeah, but each rust version requires its own in-tree llvm version which we'd have to fix for musl 2021-02-27 14:59:48 skarnet, not in any reasonable way 2021-02-27 14:59:49 it's too much work 2021-02-27 14:59:57 it takes like 10 steps of building version N+1 with version N 2021-02-27 15:00:10 and each takes like 12 hours or something 2021-02-27 15:00:16 ah yes, typical of "open source in letter but not in spirit" 2021-02-27 15:00:44 "you have open source guarantees if you have infinite patience, time, and computing resources" 2021-02-27 15:00:53 gcc frontend and/or revamping mrustc could fix it 2021-02-27 15:00:54 "which we do and you don't, so screw you" 2021-02-27 15:01:40 dalias: each takes about 45 minutes on my threadripper system 2021-02-27 15:01:57 i am pretty sure once we get it working on s390x 2021-02-27 15:02:01 so my estimate sounds about accurate for a non-64-core-behemoth 2021-02-27 15:02:11 my mainframe will be able to chew through rust like its nothing 2021-02-27 15:02:15 "Rust is a safe language with 10 steps of obfuscation in front of any possible trusting trust problem" 2021-02-27 15:02:28 skarnet, basically 2021-02-27 15:02:53 just throw a few hundred cores at the problem np 2021-02-27 15:03:13 Ariadne: yeah, that's what I said: big metal can do it, individual users cannot 2021-02-27 15:03:29 so it's control and guarantees for me, but not for thee 2021-02-27 15:03:34 i've had to reverse engineer a simple rust binary in a CTF challenge, and it was 500 KB of binary crap calling all kinds of pthread functions, tons of dynamic memory allocation just for a "hello world" like functionality 2021-02-27 15:03:35 yay open source 2021-02-27 15:03:43 how can that be a serious C contender 2021-02-27 15:03:59 sh4rm4^bnc: but but memory safety! 2021-02-27 15:04:04 sh4rm4^bnc: most of that code doesn't get used 2021-02-27 15:04:16 sh4rm4^bnc: its because of the static linking 2021-02-27 15:04:26 if it's not used then why is it pulled in 2021-02-27 15:04:36 because rust's linking is stupid 2021-02-27 15:04:50 s/'s linking// 2021-02-27 15:05:11 i am sure once the gcc backend is finished, we will have something more reasonable 2021-02-27 15:07:43 sh4rm4^bnc: you can use system llvm just fine 2021-02-27 15:08:19 Cogitri, even if the shipped version is 6 and the installed one 8 ? 2021-02-27 15:09:04 It usually can take a range of ~4 LLVM versions 2021-02-27 15:09:34 If you go really far back having LLVM 6 and 10 around should do it 2021-02-27 15:09:51 sh4rm4^bnc: re palemoon, is that even an option on sabotage? This is what openbsd got when they tried to package it. https://github.com/jasperla/openbsd-wip/issues/86 2021-02-27 15:10:04 As in you keep using LLVM6 until rustc doesn't support it anymore and by then rusc probably already supports llvm10 2021-02-27 15:10:38 orbea, that only applies to binary builds, not source recipes 2021-02-27 15:11:17 ah, right... 2021-02-27 15:12:07 though it shouldnt be that hard to satisfy their demands, or just rebrand the binary 2021-02-27 15:12:29 sh4rm4^bnc: actually maybe their 8b covers source based... 2021-02-27 15:12:36 dalias: would be nice to have you chime in on https://github.com/rust-lang/rust/pull/82556#issuecomment-787088016 2021-02-27 15:13:25 i had a friend who got a DMCA for his gentoo ebuild... 2021-02-27 15:13:29 *have 2021-02-27 15:13:37 orbea, actually i linked once to my recipe in the palemoon change and an angry tobin showed up claiming i violated the branding due to not using jemalloc, but when i told him there's no binary build he shut up and left 2021-02-27 15:13:45 s/change/channel/ 2021-02-27 15:13:45 sh4rm4^bnc meant to say: orbea, actually i linked once to my recipe in the palemoon channel and an angry tobin showed up claiming i violated the branding due to not using jemalloc, but when i told him there's no binary build he shut up and left 2021-02-27 15:14:05 heh 2021-02-27 15:14:18 sh4rm4^bnc: why would you want to deal with such an upstream tho 2021-02-27 15:15:05 because the browser is cool. it's faster/more responsive than firefox, builds in 1/3th of the time, C++ only, and supports all modern web stuff 2021-02-27 15:16:49 oh, and it still supports GTK+2 <3 2021-02-27 15:19:38 gtk2 does not support hidpi 2021-02-27 15:20:31 i don't even know what that is so i probably don't need it :) but there's now a GTK+3 build option since 1 month 2021-02-27 15:20:53 hidpi = high pixel density displays 2021-02-27 15:21:43 i care a lot about hidpi because of eye strain 2021-02-27 15:23:26 there's an option in about:config to automatically scale stuff though, layout.css.devPixelsPerPx 2021-02-27 15:27:37 ariadne, done 2021-02-27 15:48:14 hmm maybe musl should be trademarked like mozilla trademarks everything 2021-02-27 15:48:18 haha 2021-02-27 15:48:41 then you can be like "i'm sorry but what rust is doing is in violation of our trademark policy, please fix" 2021-02-27 15:51:48 :( 2021-02-27 16:00:42 don't worry that was just a joke 2021-02-27 16:02:23 !18795 looks promising, if only it didn't hit the 1h limit on s390x... 2021-02-27 18:06:15 omni: I've set it to 2h 2021-02-27 21:13:42 I hate flaky tests, especially if it only happens in CI 🙄 2021-02-27 21:17:30 ikke: flaky test suites make me rather angry 2021-02-27 21:17:47 ahuhn 2021-02-27 21:17:59 ikke: if the point of a test suite is to give you some information about whether or not your assumptions hold across a change, then flaky tests completely fail to fulfill their purpose 2021-02-27 21:18:44 I really should resubmit pyinstaller with the tests disabled 2021-02-27 21:18:54 or even just the unit tests; they all work iirc 2021-02-27 21:20:19 the worst part is that I have no idea why it's flaky 2021-02-27 21:20:44 ikke: ☹ 2021-02-27 21:21:09 that's awful 2021-02-27 21:21:13 yup 2021-02-27 21:21:16 ikke: I'm sorry you're having to deal with that 2021-02-27 22:02:55 Mips builder looks providing wrong goflags env somehow 2021-02-27 22:19:28 maybe my fix is doing something wrong 2021-02-27 22:21:17 hmm, seems like someone removed GOFLAGS completely 2021-02-27 22:25:22 ${GOFLAGS/-buildmode=pie/} 2021-02-27 22:25:43 apparently that last / is returned if GOFLAGS is empty 2021-02-28 07:56:25 wener[m]: what's your opinion about idea of build usbip-utils as subpkg of linux-tools instead of separate pkg 2021-02-28 08:46:57 mps: I prefer as subpkg of linux-tools 2021-02-28 08:49:41 Does that mean this pkg should also contain other tools ? 2021-02-28 08:59:15 linux-tools already contains some subpkgs which earlier were separate pkgs 2021-02-28 09:00:17 yesterday I was tempted to close your MR and 'move' usbip-utils to subpkg of linux-tools but didn't before asking you first 2021-02-28 09:01:17 and ask you if you mind to do that, or we can do this together, or however 2021-02-28 09:01:53 wener[m]: but we are not in a hurry 2021-02-28 09:02:38 so, when we find some time we can 'work' on this 2021-02-28 09:36:39 void Linux now also is switching back to OpenSSL 2021-02-28 09:36:49 yes 2021-02-28 09:36:58 also arm*,s390x have no logs or blank logs 2021-02-28 09:37:14 https://voidlinux.org/news/2021/02/OpenSSL.html 2021-02-28 09:37:35 Yes 2021-02-28 09:38:01 hah, now we have to go back to libreSSL :) 2021-02-28 09:41:14 for some time I'm contemplating to add wolfssl suite to alpine, though not sure how much it will be useful for us 2021-02-28 09:42:10 and beside wolfssl there is also bearssl 2021-02-28 09:43:46 and bearssl looks like is very well 'thought out' 2021-02-28 09:44:21 It's only useful if software can use it k 2021-02-28 09:45:52 software is somewhat amorphous 'entity'. I think you mean mainstream software 2021-02-28 10:26:48 mps: linux-tools is a little complex for me, I'll try to move usbip to this pkg. 2021-02-28 10:29:25 wener[m]: look how cpupower is moved to linux-tools, similar will work for usbip-utils I hope 2021-02-28 10:41:36 holly uhm, this Xorg.wrap is suid :/ 2021-02-28 10:46:22 yes, this is fantastic and smart solution to not have /usr/bin/Xorg suid 2021-02-28 10:59:08 my tools can use bearssl, and so can curl (thanks mcf) 2021-02-28 10:59:43 my build fails on 32 bit platforms at the line: static_assert( sizeof(OFF_T) == 8, "OFF_T should be 64 bits !" ); 2021-02-28 10:59:54 any idea how to fix this? 2021-02-28 11:00:46 skarnet: good to hear that 2021-02-28 11:01:17 speaking of which, since bearssl is packaged, we could switch curl to using it instead of openssl :P 2021-02-28 11:03:47 oh, I didn't even looked at that. nice again 2021-02-28 11:56:03 one potential issue with that is it is not too uncommon for servers to have invalid certificate chains (duplicate cert or bad order) and bearssl rejects those 2021-02-28 11:56:44 but the more people complaining about this to server admins, the better 2021-02-28 12:27:12 hjaekel: Probably complain at upstream that they require 64-bit 2021-02-28 12:34:05 The musl FAQ at https://wiki.musl-libc.org/faq.html says that off_t is always 64-bit. Is this also true on Alpine? Upstream also sets all flags necessary under glibc to get 64-bit file offsets, so the same should be possible with musl 2021-02-28 12:34:43 at a guess they're doing something dumb with OFF_T 2021-02-28 12:35:03 it would be good if you actually said what program this is 2021-02-28 12:35:39 I'm talking about !17956 2021-02-28 12:36:39 sure they are doing something dumb, but my C++ skills are not good enough to find it 2021-02-28 13:23:41 Edge x86-64 builder still hangs in pulling 2021-02-28 13:23:54 andypost[m]: was just working on that 2021-02-28 13:24:01 disk is full, was looking at things I could safely delete 2021-02-28 13:24:30 Thank you ikke! 2021-02-28 13:25:08 13G available now 2021-02-28 14:16:29 hjaekel: where is this OFF_T defined? 2021-02-28 14:33:38 anyone have time to help review !18793 2021-02-28 14:34:16 tested on my local, want to test on other host by using testing repo 2021-02-28 14:35:10 in the package function, you do not need to specify $builddir everywhere, $builddir is pwd 2021-02-28 14:45:31 thanks, fixed now, I follow the newapk stub 2021-02-28 14:48:05 seems the builddir is copied from otherwhere 2021-02-28 15:13:41 Any one can tell why it takes 20G of disk space to build cpeh? 2021-02-28 15:13:47 ceph 2021-02-28 15:14:35 c++ with debug info ? 2021-02-28 15:19:26 And it ships some vendored libs, doesn't it? If those also have debug info the output could get huge 2021-02-28 15:20:24 vendored libs are bad 2021-02-28 15:21:19 there is no -dbg package, so there should not be any debug symbols, I guess 2021-02-28 15:22:23 yup, seems quite some vendored libs 2021-02-28 15:22:55 ikke: Could be whatever buildsystem they use introducing -g anyway 2021-02-28 15:23:17 Do you have a `du | sort -u` of the builddir? 2021-02-28 15:25:43 https://tpaste.us/qg7a that's the builddir 2021-02-28 15:26:03 so ceph build 'destroyed' my kernel new config, happily had config.old 2021-02-28 15:26:03 This is the lib dir: https://tpaste.us/N8yB 2021-02-28 15:26:43 I disabled the armhf builder so that they would not build at the same time 2021-02-28 15:27:29 ikke: 240MB shared libs sound like they have debug symbols, could try calling `strip` on them and see if they're smaller afterwards 2021-02-28 15:27:41 Maybe we could also disable the static libs, those are gigantic too 2021-02-28 15:28:01 yes 2021-02-28 16:20:22 Hello71: thats a good question, OFF_T is defined in fitsio.h coming from the cfitsio package, and that definition seems to depend on _OFF_T, otherwise OFF_T is defined as long which explains what is happening here. I will try to fix cfitsio then. Thank you Hello71 2021-02-28 19:18:14 wener[m]: lol: "Your Full Name" 2021-02-28 19:18:43 what !? 2021-02-28 19:18:55 how that slipped 2021-02-28 19:18:58 http://dup.pw/alpine/aports/4d47753c8748 2021-02-28 19:19:23 ikke: I noticed on #alpine-commits 2021-02-28 19:19:24 mps: that's the committer name 2021-02-28 19:19:34 Not something we really verify 2021-02-28 19:19:59 and we should, imo 2021-02-28 19:20:04 we cannot 2021-02-28 19:20:20 why 2021-02-28 19:21:21 Well, we can verify that someone is not personating someone else we know (ie, someone trying to commit as ncopa) 2021-02-28 19:21:37 but other than that, we do not have a policy regarding git author names 2021-02-28 19:22:00 hmm, my trust to alpine going down 2021-02-28 19:22:49 Why? 2021-02-28 19:24:29 not that real names are big assurance, but commits from random people are not 'safe' in my perception 2021-02-28 19:24:50 You can impersonate anyone anyway 2021-02-28 19:25:08 If we want to avoid that we'd have to require GPG signing commits 2021-02-28 19:25:09 yes, I know this, but again ... 2021-02-28 19:25:54 I think the git.git policy is better: We review the commits, no matter who is the author 2021-02-28 19:25:56 the point should be that the commit is reviewed by trusted people, not that it has a "real-looking" name on it 2021-02-28 19:26:22 dalias: exactly 2021-02-28 19:29:22 Yup 2021-02-28 19:30:37 I wouldn't merge MR from someone with name 'Your Full Name' 2021-02-28 19:31:04 The e-mail address is still 'valid' 2021-02-28 19:31:16 heh 2021-02-28 19:31:43 mps, i wouldnt just because it means they likely didnt review their work 2021-02-28 19:31:44 Why is "Your Full Name" invalid, but "RandomJoe123" valid? 2021-02-28 19:31:51 gmail mail address 2021-02-28 19:32:01 Oh! missed that 2021-02-28 19:32:11 ikke, it's not invalid but it calls for review whether it's what they actually intended 2021-02-28 19:32:46 ikke: "RandomJoe123" probably thought a little before creating MR 2021-02-28 19:32:57 ACTION files Home Affairs request for name change to surname 'Name', firstname 'Full' 2021-02-28 19:37:18 The initial commit is from vsc remote, not from docker, using different gitconfig, the latter amend no edit didn't change this. Gitlab has no info on this. 2021-02-28 19:37:19 gitlab just shows the authors name matching the e-mail address, the actual author name is hidden 2021-02-28 19:39:55 Feel sorry for this 2021-02-28 19:40:09 how about lint add a email username match check 2021-02-28 19:41:29 wener[m]: it is not much about your mistake, it is more about 'workflow' 2021-02-28 19:41:31 Thinking about it what is reasonable 2021-02-28 19:42:51 ultimately, what you need is solid review 2021-02-28 19:42:56 regardless of someone's decent fakery or not 2021-02-28 19:43:23 yes, that anyway 2021-02-28 19:44:36 seems there is a gitlab rule for this https://gitlab.com/gitlab-org/gitlab/-/issues/34374 2021-02-28 19:45:34 That one is still open 2021-02-28 19:46:03 And a lot of that functionality is for EE only 2021-02-28 19:47:49 But should be trivial enough to implement as a CI step 2021-02-28 19:51:16 ACTION is quite suspicious about people who want to contribute to open source but hide their identity 2021-02-28 19:52:11 We cannot verify the identity anyway 2021-02-28 19:52:31 so Jon Doe can be just as anonymous 2021-02-28 19:54:34 true, but still 2021-02-28 19:55:03 It's a false sense of security imo 2021-02-28 19:55:48 yes 2021-02-28 19:56:08 wener[m]: you could provide a mailmap entry to 'fix' this a bit 2021-02-28 19:56:27 I can't understand why anyone in the world use something I pushed on alpine 2021-02-28 19:57:14 Collaboration of effort 2021-02-28 19:57:35 I can't understand why anyone in the world use alpine 2021-02-28 19:57:51 right, we don't have anything better than this :) 2021-02-28 20:02:40 wener[m]: there is something better than alpine? 2021-02-28 20:03:00 no 2021-02-28 20:03:23 tell me and I will switch right now ;) 2021-02-28 20:03:27 fix typo: I can't understand why not anyone in the world use alpine 2021-02-28 20:04:01 I won't commit as anything other than what I do now. I'm easier to contact in various ways as this nick than would be the case with my "real" name. I expect others to read my commits befor merging. I have no ambition on having that level of access myself. 2021-02-28 20:04:50 to repeat myself, not that alpine is good but all alternatives I know are worse 2021-02-28 20:05:36 (don't want to offend devs from other distros) 2021-02-28 20:05:39 Can someone test this command on alpine? 2021-02-28 20:05:42 curl -s -o /dev/null --write-out 'time_total: %{time_total}\n' https://distfiles.alpinelinux.org 2021-02-28 20:05:56 is there a way to browse through logs on the builders? I've only found links when jobs've been active 2021-02-28 20:06:12 omni: dir listing is enabled 2021-02-28 20:06:14 there are some packages I think should be available but aren't 2021-02-28 20:06:19 https://build.alpinelinux.org/buildlogs/ 2021-02-28 20:06:25 ikke: time_total: 2381890 2021-02-28 20:06:34 ikke: thanks! 2021-02-28 20:06:45 mps: Interesting. According to the manpage, it should be in seconds, and on archlinux, that's what I get back 2021-02-28 20:07:03 mps: that looks incorrect 2021-02-28 20:07:11 but similar to what I get 2021-02-28 20:07:16 all in alpine about 5 years now. encourage friends all using alpine, help them solves every issues they have when using alpine, give them the pre build images to lower the barriers, hope I can do moe. 2021-02-28 20:07:17 curl version? 2021-02-28 20:07:21 7.74.0 2021-02-28 20:07:43 huh, I get the same on 7.74.0 2021-02-28 20:07:49 sam_: alpinelinux? 2021-02-28 20:08:02 with gentoo and macOS (homebrew) I get seconds 2021-02-28 20:08:12 let's see 2021-02-28 20:08:29 I remember something changed with cURL in 7.7x which broke a Python tool but it's not that recent 2021-02-28 20:08:33 it was a few releases ago 2021-02-28 20:08:34 I use this in our monitoring system, and I noticed that the value is larger than expected 2021-02-28 20:09:02 ikke: time_total: 0.536787 (I use Alpine in Docker) 2021-02-28 20:09:03 oh wait, no, broken on gentoo, OK on brew 2021-02-28 20:09:11 hjaekel: version? 2021-02-28 20:09:41 I use edge in Docker 2021-02-28 20:10:01 time_total: 0.605183, edge on kvm 2021-02-28 20:10:04 on old debian: time_total: 0.207 2021-02-28 20:10:19 yeah, on edge it's working for me 2021-02-28 20:10:39 must be time_t :p 2021-02-28 20:11:00 uhm, I didn't upgraded curl on edge 2021-02-28 20:11:15 curl is 7.75.0 on edger 2021-02-28 20:11:30 7.69.1 is working as well 2021-02-28 20:11:33 https://github.com/curl/curl/issues/6422 2021-02-28 20:11:34 on edge I got: time_total: 0.340569 2021-02-28 20:11:39 => https://github.com/curl/curl/issues/6321 2021-02-28 20:11:46 fixed in 7.75 2021-02-28 20:12:08 sam_: thanks, I tried to search for it, but could not get relevant results 2021-02-28 20:12:08 yes 2021-02-28 20:12:18 7.69.1 first run time_total: 1.159709; second time_total: 0.935453 2021-02-28 20:12:34 wener[m]: That's correct 2021-02-28 20:13:52 add an entry in mailmap, should I remove the empty line ? !18879 2021-02-28 20:14:34 https://termbin.com/is0j 2021-02-28 20:14:42 docker images 2021-02-28 20:14:47 we figured it out :p 2021-02-28 20:14:49 artok: thanks, saw that myself as well 2021-02-28 20:14:55 I'll backport that fix 2021-02-28 20:14:57 aaand lagging =D 2021-02-28 20:15:01 yes i will too 2021-02-28 20:15:18 wener[m]: newline is ok 2021-02-28 20:25:42 programming is like white and black magic in blender. Last night I looked in mmc driver for rk3399 (and I don't know anything about mmc programming) to try add some parameters in a hope build will fail but will give me hint what and where to look 2021-02-28 20:26:41 to my surprise build succeed and I decided to try to boot this kernel expecting it will fail and give me some hints 2021-02-28 20:27:48 surprised again, it worked fine without any hints, and as bonus mmc driver doesn't crash for about 24 hours 2021-02-28 20:28:15 programming by blind poking :) 2021-02-28 20:29:05 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/18880 2021-02-28 20:29:44 ikke: does it apply cleanly? 2021-02-28 20:29:51 yes 2021-02-28 20:29:53 \o/ 2021-02-28 20:29:57 thank you! 2021-02-28 20:31:10 Just tested it 2021-02-28 20:31:12 -r0 broken 2021-02-28 20:31:14 -r1 fixed 2021-02-28 20:42:34 sam_: it's merged 2021-02-28 20:42:42 ikke: thanks a bunch! 2021-02-28 20:50:22 what's with build-edge-armhf? 2021-02-28 20:50:38 oh, I temporarily stopped it 2021-02-28 20:51:36 started it again 2021-02-28 21:07:27 lol, setting the timeout from 10 seconds to 2 minutes finally lets the hugo test suite pass on mips64 :D 2021-02-28 21:13:36 ikke: you don't want to see the timeouts I have to set on aarch64 then 2021-02-28 21:14:10 RootWyrm: at least for us, it builds fine on aarch64, but we do have nice hardware :) 2021-02-28 21:14:46 ikke: mono closed-loop musl cycle for the work I'm doing had to be bumped to 6 hours. On Cavium ThunderX2. 2021-02-28 21:18:01 RootWyrm: note that I'm talking about the timeout of a single test, not the entire build 2021-02-28 21:18:33 ikke: oh, it's a 6 hour timeout... *per test*. 2021-02-28 21:20:02 ugh 2021-02-28 21:20:22 Remember mallocng circa musl 1.2.1? Yeah. "Catastrophic fragmentation patterns" is a colossal understatement. 2021-02-28 21:22:02 The problem is, mallocng seems to also really hate functional GCs. 2021-02-28 21:39:05 functional GCs ? like boehm ? 2021-02-28 21:43:10 like Haskell's GC? 2021-02-28 21:44:08 hm? 2021-02-28 21:58:04 can you see the full queue for builds? 2021-02-28 21:58:18 no, that's not exposed 2021-02-28 21:58:25 ok 2021-02-28 21:58:56 there is nothign really keeping track of the 'queue', buildrepo just checks what needs to be built 2021-02-28 21:59:29 I can run build-repo -n (dry-run) on the builders to see what still needs to be built 2021-02-28 22:00:35 I'm just curious of the ocaml packages from !18213, assuming they're in the pipeline for armhf and x86_64 2021-02-28 22:03:28 ocaml has been built on armhf, so it just needs to be synced 2021-02-28 22:04:17 same for x86_64 2021-02-28 22:06:08 ah, right, I didn't find the logs for the other ocaml packages in that mr for those archs earlier 2021-02-28 22:06:48 the disk was full, so some buildlogs couldn't be uploaded 2021-02-28 22:06:58 oh 2021-02-28 22:08:56 but great stuff! then the packages will be available soonish, so I can work on other ocaml-packages