2022-02-01 00:13:14 done 2022-02-01 03:08:19 can someone look at anything else that might be needed for !29839 ? (I think it is good to go..) 2022-02-01 03:09:34 i was waiting to see if nangel would show up, but i guess it's long enough :) 2022-02-01 03:14:29 seems it suddenly wants bash now.. 2022-02-01 03:21:53 oh... weird. I guess one of the build components was upgraded? 2022-02-01 03:21:59 I can add that now. 2022-02-01 03:27:09 I also created !30306 !30307 (security) and !30306 (to have consistent version) 2022-02-01 03:29:09 how do security updates get labled as such? 2022-02-01 03:29:40 there's no autorule i don't think 2022-02-01 03:30:03 ah, was wondering if there was a keyword I was missing.. 2022-02-01 04:04:12 smcavoy: one of those is a duplicate? 2022-02-01 04:07:59 they prolly mean this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30305 2022-02-01 04:08:06 305 306 307 2022-02-01 04:42:36 Ariadne: indeed, as psykose mentioned !30305 was missing from that list and is still open 2022-02-01 05:15:04 how do I appease my alpine machine freaking out about a host key changing? it prints an sha256, but is that what goes in known hosts? looks a bit short 2022-02-01 05:16:02 nvm I had like 3 lines to delete instead of 1 2022-02-01 05:30:50 bdju: ssh-keygen -R and/or ssh-keygen -R 2022-02-01 05:31:19 hm never used -R that I recall 2022-02-01 05:31:33 oh there's a command to remove stuff. sweet 2022-02-01 05:31:36 I always open the file in vim 2022-02-01 05:31:36 thanks 2022-02-01 05:32:22 smcavoy: I typically add the label 2022-02-01 13:27:48 Can I replace a package on stable? It is a Matrix client where upstream is inactive and a community fork has been made, but the name is changed. 2022-02-01 14:02:59 the general idea is that users should be able to do `apk upgrade -U -a` from stable release branches without anything breaking 2022-02-01 14:03:09 they should not need to do any config changes or anything 2022-02-01 14:03:34 so generally, no, we shouldnt rename a package in stable 2022-02-01 14:04:46 there may be exceptions though, if there are critical security fixes that can not be backported, and the package rename can be done with a proper provides etc so that nothing breaks for users 2022-02-01 14:15:22 im having a struggle with p7zip on s390x. the test deadlocks. when I run it under gdb it passes. when I run it under valgrind, valgrind segfaults 2022-02-01 14:17:22 strace? 2022-02-01 14:18:51 also i suggested earlier to switch to upstream 7-zip 2022-02-01 14:21:07 i was able to attach to the deadlocking process with gdb -p 2022-02-01 14:21:12 seems like debian and opensuse have it already, but not fedora 2022-02-01 14:21:18 where do i find upstream 7-zip? 2022-02-01 14:21:31 https://7-zip.org/ 2022-02-01 14:21:42 he added linux support about a year ago 2022-02-01 14:23:04 makes sense to switch 2022-02-01 14:25:02 unfortunately the build system is terrible and there are no tests and the code quality is dubious but point 1 and 3 apply to p7zip too and for point 2 i think most of the test suite value can be replaced by 7z c test.7z test.txt && 7z x test.7z test.txt 2022-02-01 14:25:29 there is also https://github.com/jinfeihan57/p7zip 2022-02-01 14:25:58 MY-R: that is what we currently use 2022-02-01 14:26:22 yes, ncopa switched to that already, but i think upstream 7-zip is possibly still better 2022-02-01 14:26:38 oh 2022-02-01 14:27:36 i don't really see the point of zstd 7z compared to zstd tar. i guess it has better indexing? but aiui it is not interoperable with standard 7-zip program, so if you want that you can compile and install it yourself 2022-02-01 14:27:49 it start being kind of messy with all those *7zip* stuff, time ago to have different language on windows you needed download .exe from different site than official 2022-02-01 14:28:24 and somehow official 7zip still pointed to those site like official but somebody else was making those binaries... 2022-02-01 14:34:14 this is kind of interesting thread: https://github.com/jinfeihan57/p7zip/issues/114 2022-02-01 14:35:05 i think the best value 7z provides is to extract .iso images 2022-02-01 14:46:02 According to that thread, would not be better to move it to community? It only has a required packages which is already on community 2022-02-01 15:14:05 How should I title my MR if I convert subpackage to ordinary package? 2022-02-01 15:31:22 ncopa: libarchive can also do it since at least 2008 2022-02-01 15:34:09 libarchive can also extract (most) 7z archives, only reason to use 7zip is to extract some strange archives with uncommon settings or to compress to 7z format. 7zip lzma/lzma2 implementation is better than xz, and it also supports ppmd 2022-02-01 15:36:44 then I guess there is no real need for 7z 2022-02-01 15:55:27 libarchive kinda stinks too; the rar reader in particular has known crashing bugs: https://github.com/libarchive/libarchive/pull/1491 unfixed for 1 year, many others from oss-fuzz. i'm not sure if these are rce bugs or just dos, but afaik bsdtar has no sandbox so if it is rce then that's game over 2022-02-01 16:39:32 Another day, another broken Telegram release 2022-02-01 16:44:20 there is a reason why some distributions doesnt upgrade it too often and until base function working fine then no problem! :D 2022-02-01 16:44:38 :-p 2022-02-01 16:45:24 even on phone I prefer Telegram X :D 2022-02-01 16:45:53 Telegram X was somehow more buggy in my experience than Telegram. And it wasn't open source back then, I think it is now 2022-02-01 16:47:04 time ago it could be since it suposed to be playground for devs etc but somehow working great since few years already 2022-02-01 16:47:53 ^ https://twitter.com/telegram/status/1134130624653144064 2022-02-01 16:49:48 yes, I'm android user :P 2022-02-01 16:50:14 so since they drop support for ios then is only better! 2022-02-01 16:58:57 damn, Arch linux already have 3.5 version... 2022-02-01 18:20:20 MY-R: If you care about timely versions kindly ask Telegram to stop breaking builds in each release https://github.com/telegramdesktop/tdesktop/issues/23994 2022-02-01 18:23:50 it took them years to build with some mitigations enabled, so don't put too much faith into your issue 2022-02-01 18:24:47 don't they have CI? 2022-02-01 18:25:06 oh, it's red. Excellent. 2022-02-01 18:25:25 time for release right :) 2022-02-01 18:26:08 It's always red btw 2022-02-01 18:26:16 PHP style then 2022-02-01 18:26:38 But it involves building in a CentOS Docker container. The Dockerfile is over 1000 lines long last time I checked 2022-02-01 18:29:45 oh 2022-02-01 18:29:53 i just realized jvoisin is the snuffleupagus author 2022-02-01 18:30:03 ty for making sure my blog does not get popped 2022-02-01 18:32:17 why are you running wordpress :'( 2022-02-01 18:32:29 instead of something static? 2022-02-01 18:33:09 Nulo: I rly dont care and shouldnt people who make packages, project with 10 releases in 2 months which is pain in the ass to make a package 2022-02-01 18:39:41 Is it ... normal to have meson in a cmake project? https://gitlab.alpinelinux.org/Nulo/aports/-/jobs/615290#L6870 2022-02-01 18:40:03 Oh great it's trying to compile wayland-protocols 2022-02-01 19:17:36 jvoisin: two reasons: (1) the wordpress app on my phone, and (2) i like the wordpress editor 2022-02-01 19:32:55 Does anybody have a clue about this https://gitlab.alpinelinux.org/Nulo/aports/-/jobs/615314#L5088 2022-02-01 19:34:23 Ah I guess I need both {plasma-,}wayland-protocols 2022-02-01 19:38:02 It still doesn't work! 2022-02-01 19:38:19 Doesn't it say that it cannot find meson? 2022-02-01 19:38:54 Yes, but this wasn't needed in previous releases. It uses CMake. 2022-02-01 19:39:08 I think it's trying to use a bundled wayland-protocols 2022-02-01 19:39:22 That's what I'm trying to avoid, but I guess it's not possible 2022-02-01 21:46:33 I very much doubt Telegram requires plasma-wayland-protocols... 2022-02-01 21:51:12 :shrug: 2022-02-01 21:52:07 PureTryOut: Just because you insist :P I removed it, let's see what the CI says 2022-02-01 21:52:14 It's in the Arch package 2022-02-01 21:57:25 I mean maybe it does need it, but the Arch package having it doesn't mean it does 😉 2022-02-01 21:58:20 if they didn't change the qt6 part changing it to qt6 makes it build a vendored patched kf5? or something, with qt6 support 2022-02-01 21:58:22 that's what the meson is for 2022-02-01 21:58:53 i remember seeing it last time when i tried 2022-02-01 21:59:08 kwayland not kf5 2022-02-01 21:59:10 or maybe that is wrong too 2022-02-01 21:59:14 something along those lines 2022-02-01 22:00:16 vendored patched kf4? Eewww 2022-02-01 22:00:20 *kf5 2022-02-01 22:01:15 cause the latest release doesn't have qt6 support or something 2022-02-01 22:01:21 so the tarball has a pre-patched one with the support... 2022-02-01 22:01:25 don't ask me why this ships 2022-02-01 22:01:45 i could also be wrong, it was a month ago 2022-02-01 22:03:53 yeah KDE doesn't support Qt6 yet, it's planned for later 2022-02-01 23:42:53 https://www.samba.org/samba/security/CVE-2021-44142.html 2022-02-01 23:43:22 "Samba 4.13.17, 4.14.12 and 4.15.5 have been issued as security releases to correct the defect" 2022-02-01 23:43:50 only edge seems to have 4.15.5 :> 2022-02-01 23:53:43 ncopa: ^ 2022-02-02 00:38:39 if someone wants to prepare the backports i’ll merge them :) 2022-02-02 00:38:47 otherwise will deal with it tonight 2022-02-02 00:48:50 Ariadne: both !27328 !27329 should probably be closed then, yes? 2022-02-02 00:49:21 yes 2022-02-02 00:49:29 since they are obsolete 2022-02-02 00:50:37 I can open the samba security upgrades for 3.13/3.14/3.15 2022-02-02 02:30:43 Ariadne: I opened !30350 !30351 !30352 2022-02-02 02:36:22 actually looks like there is a problem building the needed `ldb` package on x86/armhf/armv7, (3.13/3.14) will check into that 2022-02-02 03:10:59 i assume 4.12 was not affected 2022-02-02 03:11:41 and yeah it seems it wants a newer ldb 2022-02-02 03:13:47 and ldb fails to build hehe 2022-02-02 03:16:21 psykose: actually 4.12 should be affected. I thought that was not suppported any longer... seems it is until 2022-05-01. So that will need to be patched. I can do that. 2022-02-02 03:17:02 the ldb issue seems to be related to 32bitness :| 2022-02-02 03:18:16 i think it's harmless if it's the one i'm thinking of 2022-02-02 03:18:27 harmless in the sense that it's unavoidable and nothing new 2022-02-02 03:18:35 there are a number of confidential issues relating to 3.12 security bugs which nobody seems to have appetite for resolving. it seems like this vulnerability only affects those users who have explicitly enabled vfs_fruit, so i don't think it's worth spending excessive time backporting 2022-02-02 03:18:37 just a test which will definitely fail, there's some upstream discussion, sec 2022-02-02 03:18:56 https://bugzilla.samba.org/show_bug.cgi?id=14558#c18 (https://sources.debian.org/src/ldb/2%253A2.2.3-2/debian/patches/Skip_failing_tests.diff/) 2022-02-02 03:27:59 sam_: thanks. 2022-02-02 03:33:31 psykose: actualy 4.12 is EOL'd 2021-09 2022-02-02 03:33:40 the only option is to upgrade to 4.13 2022-02-02 03:33:51 well it's on alpine 3.12 which 'should' be supported 2022-02-02 03:33:53 yea 2022-02-02 03:34:00 i guess nothing to do then 2022-02-02 03:34:24 is upgrading to 4.13 an option? 2022-02-02 03:38:18 probably not 2022-02-02 05:13:09 Ariadne: samba security ready 2022-02-02 06:09:07 ok? 2022-02-02 06:09:11 links? :P 2022-02-02 06:09:50 looks like they already got merged 2022-02-02 06:12:59 ikke is too fast 2022-02-02 06:15:56 Ariadne: !30352 for 3.15 is still open 2022-02-02 06:25:09 Could I get a review on !29824? 2022-02-02 06:30:12 heh 2022-02-02 06:30:16 i was just reviewing it 2022-02-02 06:30:25 o 2022-02-02 06:30:36 there's a typo in one of the commit messages :p 2022-02-02 06:32:28 Too late to fix that now unless someone wants to live dangerously and interactively rebase master. :p 2022-02-02 06:32:38 absolutely not a chance bestie 2022-02-02 06:32:46 you will live in shame forever... 2022-02-02 06:33:29 I can only imagine the absolute mess of problems that would create. 2022-02-02 06:33:51 for one, we'd have to manually fix each builder 2022-02-02 06:35:05 what, you don't run git pull -f each time? :p 2022-02-02 06:36:00 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build#L135 2022-02-02 06:36:12 too safe 2022-02-02 06:43:58 psykose: The commits just pushed to master also aborted your automatic merge on !30354 2022-02-02 06:44:34 done 2022-02-02 06:44:51 Thank you. 2022-02-02 06:46:27 :3 2022-02-02 06:46:31 nya 2022-02-02 06:53:58 slow rust is slow :( 2022-02-02 06:55:34 it's in the name 2022-02-02 06:55:35 'rust' 2022-02-02 06:57:42 make faster compiler 2022-02-02 06:57:44 call it WD-40 2022-02-02 07:04:19 Lol! 2022-02-02 07:05:08 Coke may help too 2022-02-02 07:08:57 ACTION prefers club-mate 2022-02-02 07:09:23 unfortunate that nothing taste like jolt used to 2022-02-02 07:17:34 try sprinkling copious amounts of amphetamines into a coke zero 2022-02-02 07:17:42 may help 2022-02-02 10:25:25 i try to build a new version of tlsrouter. now i have a problem running abuild -r on it 2022-02-02 10:25:48 it complains that: 2022-02-02 10:25:50 >>> tlsrouter: Entering fakeroot... 2022-02-02 10:25:52 install: can't change ownership of /home/marv/wip/aports/testing/tlsrouter/pkg/tlsrouter/etc/tlsrouter: Permission denied 2022-02-02 10:25:55 Use a pastebin 2022-02-02 10:25:57 please 2022-02-02 10:26:26 https://pastebin.com/Hwt0uqRv 2022-02-02 10:26:29 the full output 2022-02-02 10:31:25 Please take a look at !30324 2022-02-02 10:34:04 it has a problem with the install command for setting user and group. buw how can i handle that in the APKBUILD? 2022-02-02 10:45:00 xsteadfastx: What's the contents of your APKBUILD? (Send in a pastebin please) 2022-02-02 12:31:28 Hello71: Could you please somehow get me a qt5-qtwebengine package with all the debug flags enabled so I can see the actual lines of the code that's causing qutebrowser to crash? 2022-02-02 12:32:08 I don't think I have enough disk space to build it myself (especially not with all the debug symbols that I'll want generated) 2022-02-02 13:22:46 ktprograms: you could make an MR to do it :) 2022-02-02 13:28:51 i'm pretty sure building it works ok and there's something wrong with ktprograms's setup causing them not to be loaded 2022-02-02 13:29:02 https://pkgs.alpinelinux.org/package/edge/community/aarch64/qt5-qtwebengine-dbg seems like an appropriate size 2022-02-02 14:06:01 within APK, what is the version `p` and `r` for? I'm assuming r is for release, but what is `p`? 2022-02-02 14:06:55 Hello71: It does name the function that the segfault happens in, but not the specific line of code 2022-02-02 14:07:07 Any idea what could be wrong with my setup? 2022-02-02 14:13:18 aparcar: patch 2022-02-02 14:24:55 ikke: oh makes sense, thanks 2022-02-02 14:28:32 anyone seen Timo here recently? 2022-02-02 14:30:28 Occasionally 2022-02-02 14:35:33 Can someone review !28976? 2022-02-02 15:01:20 ah, i think qt5-qtwebengine-dbg doesn't actually have debug info for chromium part. it only has symbols for chromium part, debug info is only for qt bindings 2022-02-02 15:26:20 !30372, but i doubt it will pass 2022-02-02 16:21:31 >>> qt5-qtwebengine-dbg*: Package size: 876.9 MB 2022-02-02 16:23:18 "Artifact size: 321548288 bytes" i guess that's not *that* bad 2022-02-02 16:31:50 probably would be better to set up debuginfo server to keep it off the mirrors 2022-02-02 16:34:03 then it can also be jammed into existing builder system by rsync --include \*/ --include \*.debug --exclude \* $pkgdir/* debuginfod.alpinelinux.org:debuginfo/ or something 2022-02-02 16:35:22 plus --delete and then it is just missing handling deleted packages 2022-02-02 21:31:20 connection seems to be restored 2022-02-02 21:58:57 debuginfo server would be great 2022-02-02 22:03:23 PureTryOut: have you seen any issue since the upgrade to vulkan 1.3.204 2022-02-02 22:21:34 Ariadne: would that just be a simple http server? 2022-02-02 22:21:47 i think there is an API 2022-02-02 22:22:49 debuginfod 2022-02-02 22:23:22 https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server 2022-02-02 22:23:28 yep 2022-02-02 22:26:02 Hellooo can somebody please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30380 for me? 2022-02-02 22:27:21 done 2022-02-02 22:33:39 i don't quite understand why a special server program is required 2022-02-02 22:41:30 ah, it is roughly explained in the man page. the point is to serve debuginfo files from unmodified packages (.deb, .rpm, .tar) 2022-02-02 22:41:41 Apparently that's what's scanning for debug files and id's 2022-02-02 22:41:43 not sure how scalable it is 2022-02-02 22:42:18 right but like why can't i just run a preprocessor to move the debuginfo files to the appropriate paths based on the build-id 2022-02-02 22:42:51 then i can probably use gzip_static 2022-02-02 22:43:17 i mean 2022-02-02 22:43:19 maybe you can 2022-02-02 22:43:25 i don't know, i just read that there was an "API" 2022-02-02 22:44:32 i think the answer is that you can but then they won't be unmodified packages anymore 2022-02-02 23:11:36 ikke, thank you! 2022-02-03 00:21:34 Hello71: it indexes them in a SQLite package 2022-02-03 00:21:41 *database 2022-02-03 00:21:58 So indexing can actually run out of memory depending on where you run it 2022-02-03 00:22:28 right but like the filesystem is already an index, why don't we just put regular files and then run a normal static web server which presumably has better scaling 2022-02-03 00:22:51 Because you don't need double the storage space 2022-02-03 00:23:06 Unless you never ship debug packages I guess 2022-02-03 00:23:13 mmhmm 2022-02-03 00:39:32 Hello71: Thanks for creating the MR that adds chromium debug symbols, but it seems that the artifacts weren't uploaded in the CI. Should I just wait for it to be merged and then get the package from the repos? 2022-02-03 00:48:58 i merged it 2022-02-03 00:49:12 hopefully it works 2022-02-03 00:49:59 psykose: Thanks, I'll wait for it in the repos. I assume it'll take at least as long as it took on CI, plus the time for the whole batch to finish, right? 2022-02-03 00:50:07 sure 2022-02-03 00:50:18 forgot how long it is 2022-02-03 00:50:27 qt6-qtwebengine takes like 8 hours... or something 2022-02-03 00:50:35 I think the CI said it took 50 minutes on aarch64 2022-02-03 00:50:37 5 is much less 2022-02-03 00:50:50 Why is qt6 so much longer? 2022-02-03 00:50:54 i have no idea! 2022-02-03 00:50:59 i just noticed it literally holds the builders forever 2022-02-03 02:26:49 Hello71: I've installed the new build of qt5-qtwebengine and the dbg symbols, here's the valgrind log: http://sprunge.us/fW0cbE 2022-02-03 02:27:37 what gpu are you using anyways 2022-02-03 02:27:55 and what happens if you set LIBGL_ALWAYS_SOFTWARE=1 2022-02-03 02:28:21 It's a VM. virgl + qemu for opengl accel, host is mac using UTM as the qemu frontend 2022-02-03 02:28:27 also what does gdb say 2022-02-03 02:28:49 still crashes with LIBGL_ALWAYS_SOFTWARE=1 2022-02-03 02:28:57 Hello71: Using vgdb, or just gdb? 2022-02-03 02:29:05 uh... try both i guess 2022-02-03 02:37:10 Hello71: log of gdb session at https://tpaste.us/Mzl8, there's two backtraces because I continued execution after the first segfault 2022-02-03 02:39:27 bt full? 2022-02-03 02:43:26 Doesn't seem to change the output much: https://tpaste.us/EMmV 2022-02-03 02:45:25 hm. what about disas and info reg then 2022-02-03 02:47:42 https://tpaste.us/0wK8 2022-02-03 02:49:48 The instruction it stops at seems to be 'stp x22, xzr, [x0, #8]' 2022-02-03 02:52:48 Hello71: If I understand it correctly, it's trying to store x22 and xzr at the address pointed to by x0+8 2022-02-03 02:53:10 x0 seems weirdly low for being used to store values (0x35c2c00ff8) 2022-02-03 02:53:10 p $_siginfo? 2022-02-03 02:53:32 pretty sure that's just arm64 2022-02-03 02:53:43 what is? 2022-02-03 02:54:08 https://tpaste.us/aZkl 2022-02-03 02:54:37 the address space layout 2022-02-03 02:54:47 Hello71: Oh I see 2022-02-03 02:55:18 Also ran info reg and disas after the siginfo for more context: https://tpaste.us/qPZB 2022-02-03 02:55:40 Would the segfault have been caused by the instruction being pointed to by the pc, or the one before it? 2022-02-03 02:56:45 pretty sure it's at 2022-02-03 02:57:26 although i think it's theoretically architecture-specific 2022-02-03 02:58:07 any idea how to continue from here? 2022-02-03 02:58:14 Should I try vgdb? 2022-02-03 03:00:17 what does /proc/$(pgrep -f qutebrowser)/maps say 2022-02-03 03:00:28 about 0x4707c00ff8+8 2022-02-03 03:03:08 pgrep -f qutebrowser lists two pids 2022-02-03 03:03:40 Possibly because one is the gdb command, and the other is the python command passed to gdb being run 2022-02-03 03:05:13 ah, right. pgrep -nf :) 2022-02-03 03:05:42 Here: https://tpaste.us/qPZB 2022-02-03 03:11:08 Why is this APKBUILD filled with typos? lol https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/xf86-video-modesetting/APKBUILD 2022-02-03 03:13:01 6 years old https://gitlab.alpinelinux.org/alpine/aports/-/commit/95d050778c1527c92a15f2f72045ef4994dc39f9 2022-02-03 03:15:21 !30394 I guess 2022-02-03 03:15:58 updating pkgdesc needs to bump pkgrel 2022-02-03 03:16:54 psykose, done 2022-02-03 03:18:55 oh 2022-02-03 03:18:57 you made it two commits 2022-02-03 03:18:58 haha 2022-02-03 03:19:12 back to bed for me.. 2022-02-03 03:19:16 zz 2022-02-03 03:22:16 ktprograms: does glxgears and eglgears_x11 work? 2022-02-03 03:23:22 psykose, I have no clue how I managed to do that, I did --amend.. Sorry :# 2022-02-03 03:23:35 the magic of life.. 2022-02-03 03:23:54 Hello71: I can't find eglgears_x11 2022-02-03 03:24:13 hm, i guess alpine doesn't have it 2022-02-03 03:24:47 my guess is that virgl driver is returning something strange which chromium is not handling properly 2022-02-03 03:25:15 Hello71: glxgears is going at 4fps, although window movement is smooth. I think there might be a problem with my host mac because the GPU usage is at 30%. I'm gonna reboot. 2022-02-03 03:25:40 i suspect that virgl on mac is rarely used 2022-02-03 03:25:53 guess so 2022-02-03 03:26:12 and opengl on mac kinda sucks in the first place 2022-02-03 03:26:52 Funny thing is it was still happening when I changed to a non accelerated graphics driver (cpu rendering in the vm) 2022-02-03 07:14:21 bl4ckb0ne: not personally no. Did you experience issues? 2022-02-03 10:23:01 Hi, what is normally supposed to happen after the kernel says 'Mounting root: ok.' when using an Alpine system with an initramfs and ext4 root? (Running in a VM that uses Apple's Virtualization.framework, I've put 'console=hvc0 root=/dev/vda modules=ext4,virtio_console' in the kernel command line (vda is correct because I'm not partitioning the disk)) 2022-02-03 10:23:21 It just seems to hang after that last message, no panics 2022-02-03 10:23:39 If I specify init=/bin/sh or even init=/init, it panics with attempting to kill init 2022-02-03 10:36:01 ktprograms: usually it only moves mounts like /proc to new root and runs busybox switch_root 2022-02-03 10:37:34 judging by "attempting to kill init", it switches root correctly and only fails after that. are you sure the ext4 root is the correct architecture, etc.? 2022-02-03 10:51:25 ptrc: I think so. So does the init kernel parameter not change which init is run in the initramfs? 2022-02-03 10:53:12 seems to be /sbin/init: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L381 2022-02-03 10:54:46 ptrc: So right now there seem to be two problems. One is why it's just hanging without any output, and also why it panics when specifying init 2022-02-03 10:55:47 hm, is there anything meaningful in the kernel panic? 2022-02-03 10:59:14 ptrc: Full kernel output: https://tpaste.us/xn0W 2022-02-03 11:15:59 ptrc: I got it to boot by redoing the install and using lbu package instead of just copying what I thought I needed, but it doesn't seem to go through the initramfs, because the hostname isn't set and fstab is ignored (I have rw specified but it's always mounted ro, I can remount it though) 2022-02-03 11:17:15 ktprograms: i think hostname and fstab are being handled by openrc units, try adding services hostname and localmount to the default runlevel 2022-02-03 11:17:37 also, add "rw" to the kernel command line 2022-02-03 11:18:23 ptrc: The rw didn't seem to change anything 2022-02-03 11:18:31 Any idea why openrc doesn't seem to be started? 2022-02-03 11:18:58 does "rc-status" report anything? 2022-02-03 11:46:31 Hi. How this possible. When getting an update for alpinelinux through squid proxy with c-icap and clamav module - clamav detects 'PUA.Win.Exploit.CVE_2012_1461-1(7c71d608edd54a547359da399bf1301f:1661728) FOUND' in APKINDEX.tar.gz file ? 2022-02-03 11:46:47 false alarm ? 2022-02-03 11:47:23 Please don't cross-post, I just replied in #alpine-linux 2022-02-03 11:49:22 sure 2022-02-03 11:49:27 sorry for that. 2022-02-03 12:01:27 ptrc: rc-status says that sysfs service has been started, ntpd,acpid,crond stopped 2022-02-03 12:01:43 What normally runs openrc during the boot process? 2022-02-03 12:15:59 It's started from inittab iirc 2022-02-03 12:39:25 psykose: tox -e doesn't actually seem to work. it tells me it expects one argument if -e is usd 2022-02-03 12:39:26 s/usd/used/ 2022-02-03 12:39:26 Newbyte meant to say: psykose: tox -e doesn't actually seem to work. it tells me it expects one argument if -e is used 2022-02-03 12:39:44 `tox -e tests` has an argument 2022-02-03 12:39:49 interesting bot. anyway, just doing `tox` works 2022-02-03 12:39:56 ohh 2022-02-03 12:40:34 no point in running code style tests 2022-02-03 12:45:41 ikke: I see. 2022-02-03 12:46:12 ptrc: I managed to get everything to work by booting from the ISO and installing e2fsprogs (for fsck.ext4) to the disk. 2022-02-03 12:46:45 psykose: re downloaded dependencies: I found a parameter called --sitepackages which gives the venv access to globally installed packages, but I don't know if that actually makes it not download them 2022-02-03 12:47:01 you would see some download stuff in the tox output when you run it 2022-02-03 12:47:04 but it's fine 2022-02-03 12:47:06 thanks :) 2022-02-03 12:47:09 Is there any to run setup-alpine and let it perform the install step, but without a bootloader (just the kernel)? 2022-02-03 12:48:26 The way the Apple virtualization framework works is that you provide the vmlinuz and initrd specifically, there isn't a generic EFI bootloader. So I just scp the files for now. 2022-02-03 12:49:18 The problem with trying to install the system manually is that things like this can happen where I didn't install e2fsprogs, so it couldn't perform an fsck, so other services weren't being started. 2022-02-03 12:49:38 Also can I direct openrc output to hvc0? 2022-02-03 13:02:13 ktprograms: I'd have thought that "console=hvc0" in your cmdline would achieve that 2022-02-03 13:02:15 console=hvc0 on the kernel command line, if you have control over that, is the best you can do 2022-02-03 13:02:19 jinx 2022-02-03 13:02:55 skarnet: you read my mind - now give it back, lol 2022-02-03 13:03:10 finders keepers 2022-02-03 13:05:16 ktprograms: is this on a M1 Arm machine? 2022-02-03 13:05:40 It's very weird because dmesg shows up on hvc0 until 'Mounting root: ok', then nothing is visible until the welcome message and login prompt. 2022-02-03 13:06:06 minimal: Yes, VM using https://developer.apple.com/documentation/virtualization/ 2022-02-03 13:06:27 you have set it as your secondary console 2022-02-03 13:06:39 How do I set the default console? 2022-02-03 13:13:28 Hello71: ^ 2022-02-03 13:15:13 the primary console is the last one specified on the kernel command line 2022-02-03 13:15:19 https://unix.stackexchange.com/a/384792 2022-02-03 13:15:42 also https://serverfault.com/a/307810 2022-02-03 13:17:27 Hello71: This is the kernel cmdline I use (verified by checking /proc/cmdline): 'root=/dev/vda modules=ext4 console=hvc0' 2022-02-03 13:17:32 other consoles are secondary and will receive kernel messages, but /dev/console will not output to them (except mumblemumble) 2022-02-03 13:18:09 hm. 2022-02-03 13:19:16 ah, sorry, i misread your problem. 2022-02-03 13:20:39 hmm? 2022-02-03 13:21:15 ktprograms: once you login, does "dmesg" show the full console output? 2022-02-03 13:21:38 minimal: yes 2022-02-03 13:22:34 "Mounting root: ok" isn't a kernel message, it is from initramfs. there shouldn't normally be any kernel log output between initramfs ending and login, unless more modules are loaded by openrc 2022-02-03 13:22:57 Hello71: Ah I see. 2022-02-03 13:23:02 ktprograms: ok, and is there anything of significance in the "dmesg" output shortly after the "Mounting root: ok" bit? perhaps relating to fb or drm? 2022-02-03 13:23:40 minimal: Nope. Besides it's a virtio machine with only a virtio console (hvc0) 2022-02-03 13:24:01 It's fully functional once it gets to the login prompt, just that it doesn't show openrc output 2022-02-03 13:25:46 try console=tty1 console=hvc0 2022-02-03 13:26:34 ktprograms: once a machine with a "normal" console the dmesg would tend to show "Console: switching color frame buffer device", I was just wondering if any similiar line relating to consoles was present 2022-02-03 13:26:39 Hello71: fyi tty1 output goes nowhere, it's strictly a virtio only machine 2022-02-03 13:26:58 virtio-vga is a thing you know 2022-02-03 13:27:11 Hello71: Didn't seem to break anything, but it didn't change anything either 2022-02-03 13:27:17 hm. 2022-02-03 13:27:19 idk then 2022-02-03 13:27:28 Hello71: Sorry, I should have mentioned that it's also text only 2022-02-03 13:29:43 mmhmm 2022-02-03 13:44:16 It's possible that something changed between Alpine 3.14 and 3.15, as my older VM with 3.14 displays all the output. (which I managed to get working by self compiling the kernel, now I'm trying to make it work with the default linux-virt kernel) 2022-02-03 13:47:23 ktprograms: 3.15 introduced the switch to simpledrm from fb, perhaps its having some unexpected side-effect in your situation? 2022-02-03 13:48:10 minimal: Perhaps, I'll test with 3.14 tomorrow 2022-02-03 13:49:52 ktprograms: I believe that mkinitfs' init is loading simpledrm unconditionally - perhaps you could test removing this modprobe and rebuilding the initramfs to see if that makes a difference? 2022-02-03 13:50:32 ktprograms: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L460 2022-02-03 14:07:41 PureTryOut: investigating a radv issue on my system, vulkan-loader asserts 2022-02-03 14:08:46 Interesting. Tried downgrading it yet? 2022-02-03 14:11:29 minimal: Ok, thanks. I'll give it a try tomorrow. 2022-02-03 14:11:32 still investigating the stacktrace 2022-02-03 14:12:12 apparently vulkan loader 1.3 added new checks and it fails somewhere between the program and the driver, so im suspecting everybody 2022-02-03 14:18:05 ncopa: !29072 2022-02-03 16:18:59 bl4ckb0ne: maybe mesa git already has a fix for radv? 2022-02-03 16:19:09 is there a way for apk to disable cache entirely? or at least for packages? right now installed packages end up in /usr/cache/apk which bloats the filesystem 2022-02-03 16:19:13 if not #radeon might be a good place to ask 2022-02-03 16:21:03 havent tried mesa head yet, i'm not on the faulty computer 2022-02-03 16:28:24 aparcar: --no-cache or remove /etc/apk/cache (I think? usually a symlink to the real location, /var/cache/apk or other) 2022-02-03 16:33:05 aparcar: there's also 'apk cache clean' to only keep package files of installed versions of packages 2022-02-03 16:33:05 afaik, --no-cache refers to the APKINDEX cache 2022-02-03 16:33:43 you remove the symlink from /etc/apk/cache to prevent apk from caching packages 2022-02-03 16:33:55 ikke: ah 2022-02-03 16:34:38 with apk cache clean you remove cached packages 2022-02-03 16:35:40 I'll check it out thank you 2022-02-03 16:36:29 ikke: so there is no folder or link at /etc/apk/cache 2022-02-03 16:36:45 but whenever I install something things end up in /usr/cache/apk 2022-02-03 16:36:59 for OpenWrt it doesn't make much sense, it'll like ruin the flash storage 2022-02-03 16:37:18 and asking the user to always add --no-cache is... suboptimal 2022-02-03 16:38:37 right, that's the apkindex files 2022-02-03 16:38:55 afaik there is no persistent toggle for that 2022-02-03 16:39:13 okay... mhhh 2022-02-03 16:39:19 I'll ask Timo that'd be great to have 2022-02-03 16:39:33 Ariadne: do you have an idea? 2022-02-03 16:55:07 put /var/cache/apk on tmpfs 2022-02-03 16:55:49 Hello71: that will fill up the ram 2022-02-03 16:55:59 what's the point of caching that anyway? 2022-02-03 16:56:11 the routers I'm looking at have some 64MB of ram 2022-02-03 16:56:59 aparcar: what is the point of any caching? 2022-02-03 16:57:31 i mean, fundamentally your problem is unsolvable. if you want to install new packages, you need an up-to-date package database. it's very inefficient to download the package database for each operation, so apk stores the database for future operations to reuse 2022-02-03 16:57:38 well from the perspective of a wifi router network is cheap compared to storage and ram 2022-02-03 16:58:01 sure for the index, but not for installed packages 2022-02-03 16:58:11 as in, let's reinstall the package, oh I already got it cached 2022-02-03 16:58:18 it could work like opkg where a separate command is required to download the remote package database but that's annoying 2022-02-03 16:58:21 for those cases it's "cheaper" to just download it again 2022-02-03 16:58:45 Hello71: yea I don't like that, ideally APK keeps those indexes but not the downloaded APK files 2022-02-03 16:59:09 that's the default 2022-02-03 16:59:13 it is still not clear what files you are talking about in "/usr/cache/apk" 2022-02-03 16:59:57 /usr/cache is not a directory on normal Linux systems. apk uses /var/cache/apk for some files but not in the manner you are describing 2022-02-03 17:03:00 sorry for the confusion, I'm using a downstream patch which replaces /var/ with /usr/ since over at OpenWrt /var/ is linked to /tmp/ and that would remove the installed-db after every reboot 2022-02-03 17:03:16 so when I say /usr/cache/apk I'm really talking about var/cache/apk 2022-02-03 17:05:11 aparcar: by default, that would only contain the downloaded APKINDEX files 2022-02-03 17:06:08 ikke: okay maybe my downstream patches did something wired, I'll check that again 2022-02-03 17:06:12 thanks for your patience 2022-02-03 17:08:11 A symlink or directory at /etc/apk/packages would enable storing apk files 2022-02-03 17:08:37 on Alpine system yes 2022-02-03 17:08:42 yes 2022-02-03 17:08:49 (that was implied :)) 2022-02-03 17:08:52 :) 2022-02-03 17:15:30 ikke: https://paste.debian.net/1229487/ 2022-02-03 17:15:37 so right now I see those packages being stored... 2022-02-03 17:15:55 aparcar: that's not default behaviour 2022-02-03 17:16:48 ikke: I'll think more about it, I don't see how this downstream patch would break things https://github.com/openwrt/openwrt/pull/4294/files#diff-f7264dd18cf325f76b4c733b0a261e1f6c40f81e252a0fc3e1e8a4eaa0332146 2022-02-03 17:30:02 it is suspicious that your patch claims "move installed-db to /usr/cache/apk" but the installed db is ordinarily stored at /lib/apk/db/installed, not /var/cache/apk 2022-02-03 18:15:19 Hello71: interestingly enough, /var/cache/apk/installed does exist for me 2022-02-03 18:16:34 i don't have it on my 2-year-old alpine machine or a fresh alpine:edge after apk update && apk upgrade -a 2022-02-03 18:16:45 it contains only a custom virtual 2022-02-03 18:16:45 heh 2022-02-03 18:17:03 it's empty for me 2022-02-03 18:18:01 yeah if i add anything with -t it gets thrown into there 2022-02-03 18:18:08 aha, good to know 2022-02-03 18:18:29 hmm, not for me 2022-02-03 18:19:22 weirx 2022-02-03 18:19:23 weid 2022-02-03 18:19:25 . 2022-02-03 18:19:30 ok i give up 2022-02-03 18:25:55 you need /etc/apk/cache -> /var/cache/apk, and then apk add -t virtual 2022-02-03 18:26:02 ah 2022-02-03 18:26:05 that makes sense 2022-02-03 18:47:57 apk add -t virtual? 2022-02-03 18:48:45 aparcar: you can create 'virtual' packages with arbitrary dependencies 2022-02-03 18:48:58 that's what abuild uses to install the dependencies of a package 2022-02-03 18:49:15 then you just uninstall the virtual packages and the dependencies are removed as well 2022-02-03 18:53:35 sounds like another good reason for installing packages not to have side effects :-p 2022-02-03 18:53:56 certainly 2022-02-03 19:02:41 gitlab down? 2022-02-03 19:02:50 upgrading 2022-02-03 19:02:50 getting a 502 2022-02-03 19:02:56 will wait 2022-02-03 19:04:43 bl4ckb0ne: it's up again 2022-02-03 19:04:51 goody 2022-02-03 19:14:03 PureTryOut: if you have a few seconds to take a look at !30432 it would be neato pls 2022-02-03 19:22:14 aarch64 ci seems to be out of disk? "tar: firefox-95.0.1/testing: Cannot mkdir: No space left on device" 2022-02-03 19:22:43 happens when people happen to build large packages at the same time 2022-02-03 19:22:45 :) 2022-02-03 19:23:03 ah 2022-02-03 19:23:23 ICU rebuild is a lot of packages 2022-02-03 19:23:41 yes 2022-02-03 19:24:08 most are done locally but some made my laptop ram unhappy *points at browsers and qtwebengine* 2022-02-03 19:24:49 I'm working on doing multiple stages for MRs with lots of packages 2022-02-03 19:25:28 like lint-main-com-testing? 2022-02-03 19:25:45 yes, or even more 2022-02-03 19:25:57 dynamically generated based on the amount of packages 2022-02-03 19:27:16 interesting, how would that work 2022-02-03 19:28:06 https://www.linkbynet.com/fr/pilier-cloudtransformer 2022-02-03 19:28:18 Oops 2022-02-03 19:28:26 That used to be an article 2022-02-03 19:29:08 https://docs.gitlab.com/ee/ci/pipelines/parent_child_pipelines.html#dynamic-child-pipelines 2022-02-03 19:29:52 ah 2022-02-03 19:35:58 I already added support to specify the offset and limit CI will build 2022-02-03 19:36:18 so the next step is to dynamically generate the CI 2022-02-03 19:37:35 im interested in the result 2022-02-03 19:38:17 I'm using jsonnet to generate the ci part (because yaml is a superset of json, it accepts json as well) 2022-02-03 19:43:30 Misthios: this was part 1: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/merge_requests/8 2022-02-03 19:46:21 nice 2022-02-03 20:13:20 I think for icu rebuild it would also be fine to just push the upgrade and deal with rebuild failures as they occur on the builders, no? 2022-02-03 20:15:17 i would say let the ci run at least ones to get the easy failures before they hit the builder 2022-02-03 20:15:28 as i already found 2 stupid mistakes i made 2022-02-03 20:20:14 sure 2022-02-03 20:36:11 i feel like the two systems should be one; it is wasteful to build every package at least twice, one or more times on gitlab and then once again later. i think the big distros which use centralized builds (mainly fedora and opensuse?) do this better 2022-02-03 20:38:17 The idea is to mimimally block the builders 2022-02-03 20:38:32 so that they can continue to build things 2022-02-03 20:39:24 If you just push large changes without testing them, you have basically blocked the builders for a long period and nothing can get out 2022-02-03 20:40:30 think it's more in the sense that if the ci works you just push that 2022-02-03 20:41:33 I think that can still cause inconsistent results 2022-02-03 20:41:37 wont that break the current flow like: ci is green so it gets pushed but it has not been merged/reviewed 2022-02-03 20:41:45 CI is parallel, the builders are serial 2022-02-03 20:57:50 https://pkgs.alpinelinux.org/contents?branch=edge&name=newsflash&arch=x86_64&repo=community looks like it shouldn't be like that… unless it's meant to install files in /home/buildozer, which seems doubtful 2022-02-03 20:58:30 is there a way for apk to list locally installed packages? 2022-02-03 20:58:45 apk list --installed 2022-02-03 20:58:49 apk info with no arguments 2022-02-03 20:59:05 i mean the ones installed from a local .apk file 2022-02-03 20:59:18 I just poke at world. They have a hash or something after them 2022-02-03 20:59:22 c7s: hmm, how did that happen.. 2022-02-03 20:59:37 yeah thats what im doing atm, wondered it there was an easier way 2022-02-03 20:59:51 ikke: absolutely no idea, nothing suspicious in the APKBUILD 2022-02-03 21:00:21 bl4ckb0ne: Probably is, but I don't know it 😛 Someone else will though 2022-02-03 21:02:22 seems like `add` on the package after the patch was merged fixed it 2022-02-03 21:08:14 I issue an apk upgrade -al if I want to re-sync back to repository packages when I'm testing stuff locally 2022-02-03 21:15:34 nice, will do ty 2022-02-03 21:15:45 think it uses some weird datadir definition 2022-02-03 21:15:56 and can perhaps be fixed with a -Ddatadir set to something else 2022-02-03 21:15:58 shrug 2022-02-03 21:16:08 not sure what is right though 2022-02-03 21:16:56 oh, it installs to meson.source_root() + data/.. 2022-02-03 21:17:25 add in a destdir and it makes sense 2022-02-03 21:18:24 interesting 2022-02-03 21:18:44 the homedir structure ends up in pkg/ 2022-02-03 21:18:49 and this changes it https://gitlab.com/news-flash/news_flash_gtk/-/commit/3ce5d9353e7d72b1abc964f1227bffe2f801a379 2022-02-03 21:18:55 upstream no longer has those lines 2022-02-03 21:19:05 https://i.imgur.com/gndwnHN.png 2022-02-03 21:19:09 wrong one 2022-02-03 21:19:12 https://tpaste.us/Qrbr 2022-02-03 21:19:18 yea 2022-02-03 21:19:32 anyway they removed it so technically.. just the top two parts fix it 2022-02-03 21:20:26 or something 2022-02-03 21:31:19 aparcar: hmm, i'm looking into the caching 2022-02-03 21:31:37 though, there is presently a blizzard, so my internet is not very stable 2022-02-03 21:41:21 aparcar: what is in /proc/mounts ? 2022-02-03 21:53:16 hmm, i can reproduce this 2022-02-03 21:57:34 problem is apk_db_cache_active() is now returning true in apk-tools 3 2022-02-03 21:58:29 return db->ctx->cache_dir != apk_static_cache_dir; 2022-02-03 21:58:31 hmm 2022-02-03 22:00:43 why 2022-02-03 22:07:17 weird, db->ctx->cache_dir is /etc/apk/cache even though this isn't set 2022-02-03 22:14:37 figured it out 2022-02-03 22:14:49 too much innovation with sed :) 2022-02-03 22:16:26 354713d2 2022-02-03 22:24:54 aparcar: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/96 2022-02-03 22:26:14 that has trailing whitespace ehehe 2022-02-03 22:27:25 and now it doesn't 2022-02-03 22:41:22 if i submitted a patch upstream, but it's a bit different than the patch needed for the stable version, should i still link it in Patch-Source? 2022-02-03 22:41:30 yes 2022-02-03 22:41:40 ok, thanks 2022-02-03 22:41:51 alternatively you cna just use patches directly from git :P 2022-02-03 22:43:25 what do you mean? 2022-02-03 22:48:43 i mean, if you just take a patch from a project's git repo, with format-patch 2022-02-03 22:48:46 that is good enough 2022-02-03 22:49:21 the point was that doesn't work cause it won't apply on stable 2022-02-03 22:49:43 then yes, you need a patch-source defining where it came from 2022-02-03 22:49:47 and how it was modified 2022-02-03 22:49:54 mhm 2022-02-03 22:52:09 hm, i just cloned the repo locally and adapted the patch so it applies to stable 2022-02-03 22:52:40 (it's the first patch in !30444) 2022-02-03 23:40:33 Ariadne: amazing thank you, I'll test it in my builds :)! 2022-02-03 23:40:55 hope it works out because that's the last thing my server built 2022-02-03 23:41:00 before it decided to just totally die 2022-02-03 23:56:43 I'm working on enabling tests for a package that starts a server on localhost and then wants to modify /etc/hosts to add some hostnames that resolve to localhost. Is there any other way to add hostnames? 2022-02-04 00:17:32 xordspar0: ask the user 2022-02-04 00:18:18 Hello71: It's the tests I think 2022-02-04 00:18:35 xordspar0: You could give the name of the package 2022-02-04 00:18:38 this sounds like a dubious idea 2022-02-04 00:39:10 Hello71: Update about init output not being shown, it's still happening with Alpine 3.14. I think then the difference is that on my older VM (the one that shows all output) I have heavily modified the kernel config, to the point of not using initramfs at all, so I think I've probably changed something important about consoles in there. 2022-02-04 00:40:03 probably you turned vga/fbcon off entirely? 2022-02-04 00:46:44 Hello71: I looked at the diff between my config and the virt config, and I think it's either CONFIG_SERIAL_8250_CONSOLE=y or CONFIG_FRAMEBUFFER_CONSOLE=y that could be the problem 2022-02-04 00:47:15 Does it matter that fbcon is enabled if there isn't any framebuffer/display output? 2022-02-04 00:48:53 ktprograms: as mentioned earlier in Alpine 3.15 & Edge the initramfs loads the simpledrm module - not sure what happens then in a serial-only based system 2022-02-04 00:49:42 minimal: It's the same on 3.14, which doesn't load simpledrm 2022-02-04 00:51:23 ok, so that rules that out :-) 2022-02-04 00:53:44 !29193 2022-02-04 01:07:18 Hello71: minimal: Does init output go to /dev/console, or where? 2022-02-04 01:12:31 can anyone look at !26763 ? 2022-02-04 01:13:44 ktprograms: by default it goes to /dev/console 2022-02-04 01:14:38 Hello71: I somehow don't think so, because if I write a messge to /dev/console from the initramfs before the switch_root, it shows up, but init output doesn't 2022-02-04 01:14:53 well initramfs init is also init 2022-02-04 01:15:20 it must be openrc redirecting it somewhere 2022-02-04 01:15:59 Hello71: The initramfs executes /sbin/init after the switch_root, right? 2022-02-04 01:16:11 more or less 2022-02-04 01:16:38 more precisely, initramfs-init calls switch_root which execs /sbin/init 2022-02-04 01:16:58 switch_root cannot (reliably) return because it deletes all the files 2022-02-04 01:17:03 Hello71: Ok makes sense. And that would be in init/init.c in busybox, right? 2022-02-04 01:17:09 yes, normally 2022-02-04 01:23:50 Hello71: I found it. In busybox init.c, lines 1263-1268, it says that the 'id' field in inittab is appended to the string '/dev/' and used as the output console. So I set the 'id' field in inittab to hvc0 for the init and shutdown items 2022-02-04 01:25:31 ktprograms: line 297 & 299 do a getenv for "CONSOLE" and "console" - this would pick up the name passed on the cmdline 2022-02-04 01:27:13 Ah, but is KOPT_console passed to busybox init as an argument or as an envvar? 2022-02-04 01:27:45 as an envvar if it's of the form foo=bar 2022-02-04 01:27:54 as an argument otherwise 2022-02-04 01:28:27 i very vaguely recall that that's not exactly true 2022-02-04 01:28:54 after a -- on the kernel command line everything is passed as an arg, if that's what you recall 2022-02-04 01:29:16 https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html: The kernel parses parameters from the kernel command line up to “--“; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after 2022-02-04 01:29:18 “--” is passed as an argument to init. 2022-02-04 01:29:43 so according to this documentation, console=hvc0 would not be passed in environ because it is recognized 2022-02-04 01:29:56 Hello71: Ah I see. 2022-02-04 01:30:14 although it may not be entirely accurate because console= might be an "early kernel argument 2022-02-04 01:30:23 actually looking on a VM here I see that Grub passed console=tty0 to the kernel/initramfs, but the log when initramfs' init trigger Busybox init does *not* show a CONSOLE env var being passed, only HOME, TERM, BOOT_IMAGE, modules 2022-02-04 01:30:23 ah yes, there is a list of special parameters that the kernel eats 2022-02-04 01:30:58 minimal: Hello71: Also that getenv console only seems to open the file descriptors, but I think that is still overridden in the inittab parsing 2022-02-04 01:31:03 it would be console, not CONSOLE, but indeed the kernel keeps it and does not forward it 2022-02-04 01:31:07 See https://git.busybox.net/busybox/tree/init/init.c#n1263 2022-02-04 01:31:28 why are you trying to use bb init again? 2022-02-04 01:31:42 skarnet: Alpine uses Busybox's init 2022-02-04 01:31:53 ... and? 2022-02-04 01:32:22 skarnet: I'm not trying to, I have to 2022-02-04 01:32:29 I don't understand the question - he's using Alpine which uses Busybox's init so that's why he's using it 2022-02-04 01:33:58 don't mind me, I'm tired, I thought it was aboutdoing stuff in the initramfs 2022-02-04 01:35:13 yeah so the problem with bb init is that it mistakes the id field for a tty name, which is definitely not how sysvinit operates 2022-02-04 01:35:45 but alpine inittab is for bb init 2022-02-04 01:36:10 ktprograms: Busybox switch_root can take a "-c console" option, maybe using that is another way to solve the issue? 2022-02-04 01:36:26 Hello71: yes, and does not specify anything for the openrc lines 2022-02-04 01:36:43 the initramfs' init does not appear to currently pass that option 2022-02-04 01:37:05 minimal: Maybe, but I prefer to edit inittab because that's in /etc, whereas initramfs-init is in /usr/share, so any changes I make will be lost when I upgrade mkinitfs 2022-02-04 01:37:09 I'm too tired to look at the code, but if it's anywhere near logical, init should not switch ttys from /dev/console for openrc boot/sysinit/whatever 2022-02-04 01:37:47 minimal: Unless you mean just adding -c /dev/console in official mkinitfs 2022-02-04 01:37:55 ktprograms: I was thinking in terms of if using that fixes it then it mkinitfs package could then be patches to use it 2022-02-04 01:37:57 yupe 2022-02-04 01:38:29 that init will have access to any console value passed in to it so it could then pass it along during the switch_root 2022-02-04 01:38:48 minimal: Wdym by 'then it mkinitfs package could then be patches to use it'? 2022-02-04 01:39:05 minimal: Ah right, pass on KOPT_init or whatever, right? 2022-02-04 01:39:17 I don't mean adding "-c /dev/console" but rather "-c " 2022-02-04 01:39:44 minimal: Right that's what I realised one message up 2022-02-04 01:40:03 so the question is will using that resolve your issue? 2022-02-04 01:40:19 minimal: Testing it right now 2022-02-04 01:43:29 minimal: I added ' -c "$KOPT_console"' to the end of line 566 of initramfs-init, but it doesn't seem to work (back to not showing init output) 2022-02-04 01:44:45 ktprograms: I think the "-c" needs to include the "/dev" prefix, does $KOPT_console have this? 2022-02-04 01:44:58 minimal: Oh 2022-02-04 01:45:31 the Busybox help doesn't say that but the docs page on their website shows the "/dev/" prefix 2022-02-04 01:47:47 minimal: Is the -c option still used if inittab is used? 2022-02-04 01:47:48 also $KOPT_consoles seems to be a space-separated list so you'd need to select the last/only entry in that 2022-02-04 01:48:08 note its plural, $KOPT_consoles 2022-02-04 01:48:19 ktprograms: no idea 2022-02-04 01:51:35 minimal: It seems to be ignored. I hardcoded ' -c "/dev/console"' (also tried /dev/hvc0), and there's no openrc output 2022-02-04 01:51:36 exec /bin/busybox switch_root -c /dev/${KOPT_consoles##* } $sysroot $chart_init "$KOPT_init" $KOPT_init_args 2022-02-04 01:51:41 that should I think do it 2022-02-04 01:51:50 Oh the -c is on switch_root 2022-02-04 01:51:52 Oops 2022-02-04 01:52:03 it'll strip out all but the last console name 2022-02-04 01:52:50 and that's a single space char between "*" and "}" 2022-02-04 01:53:13 minimal: Ok, thanks 2022-02-04 01:53:45 from Busybox docs: switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGS] 2022-02-04 01:54:49 minimal: doesn't that mean that the entirety of '-c /dev/console' is the optional argument, not '-c' + ? 2022-02-04 01:55:22 Because hardcoding '-c /dev/console' works but your variable substitution doesn't, probably because switch_root doesn't like '-c /dev/hvc0' 2022-02-04 01:55:57 if you do "busybox switch_root --help" it says: switch_root [ -c CONSOLE_DEV] ... 2022-02-04 01:56:28 minimal: Yes, just saw that in the source code. 2022-02-04 01:56:37 So any idea why the variable way doesn't work? 2022-02-04 01:57:32 ok, maybe it should always be /dev/console then, dunno, but as you're switching root then is it /dev/console in the current root or /dev/console in the new root? :-) 2022-02-04 01:58:20 with "-c /dev/console" does that work as expected? 2022-02-04 01:58:35 minimal: Either -c /dev/console or -c /dev/hvc0 both work 2022-02-04 01:59:19 oh? I thought you said switch_root did not like "-c /dev/hvc0" 2022-02-04 01:59:42 minimal: No that was my mistake 2022-02-04 02:00:04 cool, so that seems like a good MR for mkinitfs :-) 2022-02-04 02:00:43 Hmm your substitution doesn't work. I printed out the value of the substitution and it prints just /dev/ 2022-02-04 02:01:35 hmm, what's the value of $KOPT_consoles? 2022-02-04 02:01:44 hvc0 2022-02-04 02:02:36 minimal: I forgot, what's ## inside variable expansions called? 2022-02-04 02:03:22 Parameter expansion I think 2022-02-04 02:04:12 goodness, bash documentation isn't very understandable 2022-02-04 02:04:42 use https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18 instead 2022-02-04 02:05:35 is KOPT_consoles comma separated or space separated? 2022-02-04 02:06:08 Also I think the problem is it doesn't work when there's only one item in KOPT_consoles, cause then there's no separator to delete 2022-02-04 02:06:39 seems space separated: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L360 2022-02-04 02:07:20 ktprograms, nope a single entry is fine with that, it will just find nothing to remove 2022-02-04 02:07:47 minimal: hmm you're right 2022-02-04 02:09:28 What could be wrong then? 2022-02-04 02:12:11 tested it here and it is worked fine - it used the *first* listed "console=" entry from cmdline, not the last 2022-02-04 02:13:58 ah! line 360 is adding each console entry (from cmdline) and adding it to the *front* of KOPT_consoles, not the end 2022-02-04 02:15:13 Ok, but still doesn't explain why the substitution ends up empty for me 2022-02-04 02:15:47 so change the pattern to ${KOPT_consoles%% *} instead 2022-02-04 02:23:05 minimal: Works now. I 2022-02-04 02:23:11 I'll send a MR soon. 2022-02-04 02:23:18 Or if you want you can do it 2022-02-04 02:23:25 Thanks for the help! 2022-02-04 02:24:12 Should this also be added to the switch_root invocation at the bottom of initramfs-init (when root= isn't specified it goes through all the setting up networking etc then does a switch_root) 2022-02-04 02:25:16 there are 2 switch_root calls, one for emergency/recovery shell, and the one at the boot which is for normal boot 2022-02-04 02:25:33 would make sense to add it to both I guess 2022-02-04 02:25:43 minimal: Ok. So are you doing the MR or should I? 2022-02-04 02:26:02 probably quicker if you do the MR, I've got a backlog of other ones I'm trying to prep currently 2022-02-04 02:26:58 minimal: Ok, got other things to do first though. 2022-02-04 03:15:31 ah, consoles is triple-switched :| 2022-02-04 03:18:22 ? 2022-02-04 03:45:29 Hello71: What do you mean? 2022-02-04 03:53:54 ktprograms: sorry, its the earlier "switch_root" call that's for "normal" Sys mode/disk boot, the 2nd one seems to be for run-from-ram mode 2022-02-04 03:55:42 however it doesn't appear to be working for me - I'm only testing with cmdline "console=tty0 console=tty1" and I've resorted to "echo" in the initramfs-init and can see that with the changes "tty1" is being passed to switch_root but once booted the console appears to be tty0 (based on "cat /sys/class/tty/console/active") 2022-02-04 03:56:41 maybe it only impacts on selecting different classes of console (ttyX vs ttySX vs hvcX) ? 2022-02-04 04:03:28 ktprograms: actually its confusingly does appear to be working as "cat /sys/class/tty/tty0/active" returns tty1 :-) 2022-02-04 04:04:25 so tty0 is active, except tty0 isn't tty0, its actually tty1......very weird 2022-02-04 04:17:48 https://unix.stackexchange.com/questions/60641/linux-difference-between-dev-console-dev-tty-and-dev-tty0 2022-02-04 04:17:54 minimal: That's expected 2022-02-04 04:18:16 tty0 isn't 'first tty', it's 'current tty' 2022-02-04 04:21:16 anyway after all this hassle at least its working for you now... 2022-02-04 10:19:25 minimal: yes, tty0 is special 2022-02-04 10:19:37 it's not a real tty :) 2022-02-04 11:29:56 restarting gitlab to apply security upgrades 2022-02-04 11:33:33 upgrade complete 2022-02-04 14:52:04 Ariadne: did you port uclient-fetch or any of the related libs to aports? 2022-02-04 15:12:03 Is there a way to get rid of textrels? 2022-02-04 15:12:03 I try to modify a package which has textrels enabled but it seems that it needs to go? I'm not sure how this can be done, any suggestions? !29274 2022-02-04 17:20:48 aparcar: not yet 2022-02-04 17:21:10 aparcar: will do it next week, i kinda lost my entire home directory yesterday, so trying to put things back together still 2022-02-04 17:21:25 yeah, read about it, crazy 2022-02-04 17:21:48 if only there were a backup solution for continuous backup with cryptography baked into its core 2022-02-04 17:21:58 oh, dalias is making such a thing :P 2022-02-04 17:22:01 yeah 2022-02-04 17:22:04 bakeliet 2022-02-04 17:22:09 lite* 2022-02-04 17:23:03 https://lwn.net/SubscriberLink/882799/cb8f313c57c6d8a6/ 2022-02-04 17:26:30 :) 2022-02-04 17:26:44 ktprograms, Hello71: I'm trying to enable tests for acme-client but the tests expect that you modify /etc/hosts to add some alias hostnames for localhost. Otherwise the tests fail to lookup the hostnames used in the tests. 2022-02-04 17:26:48 Part of the test suite is testing DNS-related things; an example situation is where you have a host with alternate names and you want a cert that includes both names. The acme server will need to verify that you own both names. Here's that test: https://git.sr.ht/~graywolf/acme-client-portable/tree/master/item/tests/acme-client.conf.alternative-names 2022-02-04 17:26:57 Are there any other ways to test this behavior without modifying /etc/hosts? 2022-02-04 17:27:04 ariadne, :) 2022-02-04 18:06:21 aparcar: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10809 2022-02-04 18:06:29 aparcar: why not provides: libmntnl=11 here? 2022-02-04 18:07:45 aparcar: seems like that would solve the same concern as your `abi` tag :) 2022-02-04 18:14:05 oops, libnftnl 2022-02-04 18:14:06 :) 2022-02-04 18:14:57 lib nft nl 2022-02-04 18:59:15 xordspar0: you could create a new mount namespace and mount --bind /dummy/etc/hosts /etc/hosts for the test 2022-02-04 19:14:01 Ah, I was looking into setting up a network namespace but that might be simpler. 2022-02-04 19:35:55 unprivileged user namespaces are not allowed in many contexts, including docker 2022-02-04 19:53:56 Docker is used for the CI builds, right? But not on the builder servers. 2022-02-04 22:20:23 is there any rule which opt level should be used for building? 2022-02-04 22:35:21 $CFLAGS 2022-02-05 00:23:27 after what time would a maintainer be considered unreachable? 2022-02-05 03:33:39 pj: I think I most commonly see Os recommended 2022-02-05 08:35:14 hello all 2022-02-05 08:35:34 I have a question about a kernel config parameter 2022-02-05 08:36:13 it's the CONFIG_BLK_DEV_ZONED parameter 2022-02-05 08:36:48 in the latest kernel from 3.15 (5.15.16-0-lts) it's NOT SET 2022-02-05 08:36:58 cat /boot/config-lts | grep CONFIG_BLK_DEV_ZONED # CONFIG_BLK_DEV_ZONED is not set 2022-02-05 08:37:30 Do I have to recompile the whole kernel to turn it on ? 2022-02-05 08:37:43 or there's a sysctl parameter somewhere ? 2022-02-05 08:38:42 I have a bunch of Toshiba SMR drives that seems to require that parameter enabled to get consistent write performance 2022-02-05 08:52:41 wyk72: it looks like you would have to recompile, it does not appear to be a loadable module 2022-02-05 08:54:39 I see 2022-02-05 08:55:14 There's a guide somewhere about compiling a kernel w aports in the new 3.15 Alpine ? 2022-02-05 08:56:29 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2022-02-05 08:59:37 thanks 2022-02-05 08:59:43 I tried that guide 2022-02-05 08:59:52 but aports does nothing 2022-02-05 09:00:01 it's VERY confusing 2022-02-05 09:00:23 developm@immortality-lvm:~/aports/main/linux-lts$ abuild developm@immortality-lvm:~/aports/main/linux-lts$ abuild -h developm@immortality-lvm:~/aports/main/linux-lts$ abuild -r developm@immortality-lvm:~/aports/main/linux-lts$ abuild --help developm@immortality-lvm:~/aports/main/linux-lts$ 2022-02-05 09:00:28 no output 2022-02-05 09:04:18 it's disturbingpatch-5.15.16.xz: OK >>> ERROR: linux-lts: unpack failed >>> linux-lts: Uninstalling dependencies... 2022-02-05 09:08:03 I get >>> ERROR: linux-lts: unpack failed when using aports compiling linux-lts 2022-02-05 09:08:20 where can I check what is happening ? 2022-02-05 09:08:33 unpack failed...where ? 2022-02-05 09:13:33 wyk72: it would unpack it in the ./src directory 2022-02-05 09:17:03 I reinstalled the aports tree 2022-02-05 09:17:11 still I get this error 2022-02-05 09:17:23 >>> ERROR: linux-lts: unpack failed 2022-02-05 09:17:27 I am puzzled 2022-02-05 09:17:36 I changes a paramater into config 2022-02-05 09:17:48 config-lts-x86_64 2022-02-05 09:18:05 abuild -r spews out >>> ERROR: linux-lts: unpack failed 2022-02-05 09:19:01 I see 2022-02-05 09:19:12 I can't change the parameters directly 2022-02-05 09:19:44 so what should I do to change a parameter into config-lts.x86_64 ? 2022-02-05 09:19:47 ah, you get a checksum failure 2022-02-05 09:19:56 You didn't mention that 2022-02-05 09:20:07 after changing the parameters, you need to run abuild checksum 2022-02-05 09:20:27 oh I see 2022-02-05 09:20:29 thanks 2022-02-05 09:22:25 I get the dm_zoned module compiled in :) 2022-02-05 09:33:42 this "CONFIG_BLK_DEV_ZONED" stuff looks kinda ugly overall 2022-02-05 09:33:49 more like a workaround of some sorts 2022-02-05 09:34:12 but it seems "new" SATA hdds will all be SMR 2022-02-05 09:34:34 so it looks it's here to stay 2022-02-05 09:36:28 it's kinda amazing that OLDER tech CMR hdds cost more (??) because they have less density, but behave as you would expect 2022-02-05 09:38:34 while those "new" SMR HDDs require special handling by kernel because otherwise they HANG during rebuild if put in RAID configurations (too many random writes) 2022-02-05 09:48:37 how can I install the kernel after I compiled it ? 2022-02-05 09:49:01 apk add linux-lts-5.15.18-r0.apk --allow-untrusted ERROR: unable to select packages: linux-lts-5.15.18-r0: breaks: zfs-lts-5.15.16-r0[linux-lts=5.15.16-r0] satisfies: world[linux-lts> do you use zfs? 2022-02-05 09:49:52 nope 2022-02-05 09:50:17 will remove it then 2022-02-05 09:50:49 otherwise you would need to rebuild that package as well with the same kernel version 2022-02-05 09:51:05 I see 2022-02-05 09:51:09 thanks a million 2022-02-05 09:51:10 will try 2022-02-05 09:52:55 it says it breaks dependencies 2022-02-05 09:53:11 >>> zfs-lts: Checking sanity of /home/developm/aports/main/zfs-lts/APKBUILD... >>> zfs-lts: Analyzing dependencies... ERROR: unable to select packages: linux-lts-5.15.16-r0: breaks: .makedepends-zfs-lts-20220205.095154[linux-lts=5.15.18-r0] satisfies: world[linux-lts] linux-lts-dev-5.15.16-r0: breaks: .makedepends-zfs-lts-20220205.095154[linux-lts-dev=5.15.18-r0] linux-virt-dev-5.15.16-r0: breaks: .makedepends-zfs-lts-20220205.0 2022-02-05 09:53:41 you should build it on a machine where you do not have these packages installed 2022-02-05 09:54:17 omg 2022-02-05 09:54:48 any more pitfalls ? 2022-02-05 09:55:46 it worked by removing zfs-lts 2022-02-05 09:58:13 now it can't boot because the vfat module is not loading, and I can't copy it to the EFI partition 2022-02-05 09:58:26 modprobe vfat modprobe: FATAL: Module vfat not found in directory /lib/modules/5.15.16-0-lts root@immortality-lvm:~# mount /dev/nvme0n1p1 /mnt mount: /mnt: unknown filesystem type 'vfat'. 2022-02-05 10:01:03 ls -l /lib/modules 2022-02-05 10:01:22 root@immortality-lvm:~# ls -l /lib/modules total 4 drwxr-xr-x 3 root root 3452 Feb 5 10:55 5.15.18-0-lts 2022-02-05 10:01:35 I have 5.15.18 from the apk 2022-02-05 10:01:42 seems like you booted and older kernel 2022-02-05 10:01:44 uname -r 2022-02-05 10:01:45 but I'm still into 5.15.16 2022-02-05 10:01:53 yes it's the machine I've compiled it 2022-02-05 10:01:57 this machine 2022-02-05 10:02:17 oot@immortality-lvm:~# uname -r 5.15.16-0-lts 2022-02-05 10:02:46 if I reboot it it won't boot 2022-02-05 10:03:13 since I need to copy that .efi kernel into the EFI partition 2022-02-05 10:03:33 I do not have a usb key to boot atm 2022-02-05 10:03:54 any way out :) ? 2022-02-05 10:04:38 I see 2022-02-05 10:04:49 reinstall the old kernel via normal apk 2022-02-05 10:04:52 yes 2022-02-05 10:04:53 then copy the modded file 2022-02-05 10:05:05 omg 2022-02-05 10:08:56 will try boot the thing 2022-02-05 10:09:02 don't know what happens 2022-02-05 10:18:09 oh it worked 2022-02-05 10:18:12 kind of amazingly 2022-02-05 10:20:42 still no joy for the "zoned" smr hdds 2022-02-05 10:21:19 I see why 2022-02-05 10:21:26 this stupid hdd is "drive managed" SMR 2022-02-05 10:21:36 dmesg | grep sda [ 1.138389] sd 3:0:0:0: [sda] Drive-managed SMR disk 2022-02-05 10:21:58 Toshiba P300, el-cheapo 4TB drive 2022-02-05 10:22:29 so all was pretty pointless I guess, maybe there's a stupid firmware "switch" somewhere 2022-02-05 10:23:59 the smr-stupid hdd behaves as a normal-stupid hdd 2022-02-05 10:24:31 you should not use SMR with something like ZFS 2022-02-05 10:24:35 you will lose your data 2022-02-05 10:25:22 I know 2022-02-05 10:25:47 was trying to use the appropriate "zoned" workarounds for this drive 2022-02-05 10:26:05 but it's not host-manageable it seems 2022-02-05 10:26:37 maybe there's a switch in smartctl to make it behave like a host-managed SMR disk? 2022-02-05 10:26:48 Point is 2022-02-05 10:26:57 sine I was ignorant of the problem 2022-02-05 10:27:04 (I mean: a disk is a disk) 2022-02-05 10:27:14 Now I have a business installation 2022-02-05 10:27:18 geuss what ? 2022-02-05 10:27:38 with TWO of these drives in ZFS RAID1/mirror configuration 2022-02-05 10:28:03 wtf knew about this SMR nonsense ? 2022-02-05 10:28:19 yeah SMR is terrible 2022-02-05 10:28:23 I've read about people complaining about it 2022-02-05 10:28:31 the disk seemed like a normal 4TB disk 2022-02-05 10:28:33 you should probably swap those SMR drives out asap 2022-02-05 10:28:38 WD switching to them without notice 2022-02-05 10:28:43 good luck, hope you don't lose any data :( 2022-02-05 10:29:14 if you lose an smr drive and put another one in service 2022-02-05 10:29:19 it will never rebuild correctly 2022-02-05 10:29:29 Yeah 2022-02-05 10:29:56 wyk72 mentioned that before 2022-02-05 10:30:03 will attach a FCKING NORMAL HDD in the array, will build a new zfs filesys and tranfer datat 2022-02-05 10:30:42 then swap the fck out those toshibas 2022-02-05 10:30:58 https://hddscan.com/blog/2020/hdd-wd-smr.html 2022-02-05 10:31:03 nice overview 2022-02-05 10:31:14 I've read f2fs with the -m switch mitigates the problem 2022-02-05 10:31:30 I can "sidecar" that 2022-02-05 10:32:42 with a horrible workaround: SMR DISK -> F2FS filesystem -> RAW FILE on top of F2FS -> LOOP device to wrap the RAW FILE into a device -> Loop device as ZFS member 2022-02-05 10:32:53 brr 2022-02-05 10:32:56 apparently toshiba also has SMR disks 2022-02-05 10:33:03 one of the ugliest thing ever 2022-02-05 10:33:16 those P300 for sure are SMR 2022-02-05 10:33:21 https://toshiba.semicon-storage.com/ap-en/company/news/news-topics/2020/04/storage-20200428-1.html 2022-02-05 10:33:22 even the kernel reports it 2022-02-05 10:33:33 [ 1.131184] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 1.131243] ata1: SATA link down (SStatus 4 SControl 300) [ 1.131267] ata2: SATA link down (SStatus 4 SControl 300) [ 1.133248] ata4.00: ATA-10: TOSHIBA HDWD240, KQ000A, max UDMA/100 [ 1.134134] ata4.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 1.137935] ata4.00: configured for UDMA/100 [ 1.138076] scsi 3:0:0:0: Direct-Access ATA TOSHIBA H 2022-02-05 10:34:27 [sda] Drive-managed SMR disk 2022-02-05 10:34:48 no wonder thay were cheap 2022-02-05 10:34:57 75 EUR for 4 Tb 2022-02-05 10:35:02 too cheap 2022-02-05 10:37:54 root@immortality-lvm:~# mkfs.f2fs -m /dev/sda F2FS-tools: mkfs.f2fs Ver: 1.14.0 (2020-08-24) Info: Disable heap-based policy Info: Debug level = 0 Info: Trim is enabled Info: [/dev/sda] Disk Model: TOSHIBA HDWD240 Error: /dev/sda may not be a zoned block device 2022-02-05 10:38:15 f2fs refuses to format them with -m parameter (zoned block device) 2022-02-05 10:38:52 because the stoopid firmware of the disk "hides" the SATA commands 2022-02-05 10:39:15 can't be uglier that that 2022-02-05 10:46:52 Today’s SMR types include device-managed SMR (DMSMR) and host-managed SMR (HMSMR) technologies, and each are designed for different applications and use cases. In both cases, the data is sequentially recorded on the HDD media. Host-managed SMR drives are purpose-built for the data center and allow for optimized performance, economies of scale, and system-level intelligence of data placement. 2022-02-05 10:48:05 So the HW vendors found yet another creative way of crippling products to sell uncripple dones for a premium 2022-02-05 10:48:48 I thought Intel were the champions in that field 2022-02-05 10:49:09 hdd vendors jumped in 2022-02-05 14:12:38 Would apk v3 support repodirs like repositories.d/? That would probably create some fancy usecases where the repos can update their own upstream without 'install' scripts 2022-02-05 15:13:10 do we want to add -modcacherw to GOFLAGS in /etc/abuild.conf? this way we don't need to use the chmod-clean option for each go aport 2022-02-05 15:13:54 usually instead of chmod-clean everyone adds the former themselves 2022-02-05 15:14:02 but yeah i don't see why it shouldn't be global instead 2022-02-05 15:15:41 yes, some aports also add it locally some also just overwrite default_cleanup_srcdir still 2022-02-05 15:15:54 I will add an MR to abuild 2022-02-05 15:15:59 mhm 2022-02-05 15:16:15 but changing abuild.conf also requires some manuall tinkering with the builders since some have modified /etc/abuild.conf files 2022-02-05 15:17:38 Yes, but should not be too difficult to update ;) 2022-02-05 15:18:01 yea 2022-02-05 15:18:42 i foresee weeklong broken builders for sure 2022-02-05 15:20:08 perhaps it would be good also to add CARGO_PROFILE_RELEASE_{PANIC,_OPT_LEVEL,LTO,_CODEGEN_UNITS} to abuild.conf as well? 2022-02-05 15:20:40 do they override what is in the file 2022-02-05 15:20:47 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/134 2022-02-05 15:21:28 Environment variables will take precedence over TOML configuration files. 2022-02-05 15:21:48 from https://doc.rust-lang.org/cargo/reference/config.html#environment-variables 2022-02-05 15:22:27 sure 2022-02-05 15:23:10 if there will be any issue with it, it should be possible to disable it on per-package basis by just overriding the envvar, which I think won't be that common 2022-02-05 15:23:38 there is an open tsc issue regarding employment of lto by default 2022-02-05 15:23:45 not sure what the other options do, i don't know rust 2022-02-05 15:24:10 nmeum: I was thinking about removing chmod-clean again as well 2022-02-05 15:24:11 opt-level is -O{1,2,3,s,z} 2022-02-05 15:24:30 panic = abort removes unwind 2022-02-05 15:25:02 ikke: yeah, I think it is only used for Go aports, isn't it? 2022-02-05 15:25:06 codegen-units = 1 spends more time compiling all packages but optimising them better 2022-02-05 15:25:20 nmeum: that's why it was introduced (I did it :)) 2022-02-05 15:25:46 ah! :) 2022-02-05 15:27:07 I'm asking because I see mix of -O{s,z} in rust packages and because someone made NMU with -Oz without even saying anything 2022-02-05 15:28:15 feel free to open an issue/mr in the abuild repo regarding improved global rust compilation options, I think that's where it would be discussed best 2022-02-05 15:28:28 cool, will do 2022-02-05 15:28:56 thanks 2022-02-05 18:08:41 ikke: should I just merge the modcacherw abuild.conf change or do you think it needs further discussion? 2022-02-05 18:16:16 nmeum: I'd at least wait for ncopa 2022-02-05 18:16:39 nmeum: i've enabled shared runners for your fork, so that CI works 2022-02-06 03:04:16 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135 2022-02-06 06:03:57 ls 2022-02-06 06:04:10 sorry wrong window 2022-02-06 10:06:59 is there any tools to make a py3 APKBUILD automatically from pypi? 2022-02-06 10:08:41 There is apkbuild-pypi 2022-02-06 10:09:09 But that still assumes setup.py 2022-02-06 10:09:40 While many projects are moving to setup.cfg / pyproject.toml 2022-02-06 10:10:53 great, as long as it pulls the metadata I can fix the other parts accordingly 2022-02-06 10:11:36 thanks 2022-02-06 16:11:57 where does the default black cursor theme comes from in sway? 2022-02-07 07:53:51 ikke, do you see any issue with !30573? 2022-02-07 08:00:25 according to gtest they recommend everything just using the latest main commit and that it shouldn't 'break anything' 2022-02-07 08:00:46 given my prior experience of google 'open source' that isn't always true, but i don't expect this to suddenly break a bunch of tests 2022-02-07 08:00:49 but i haven't checked 2022-02-07 08:01:09 psykose, yeah. I was wondering about having a 'not stable' release on main 2022-02-07 08:01:51 ime it's not that bad, but i have not exactly rebuilt every dependent 2022-02-07 08:02:58 according with the github history, they don't tag a release very often 2022-02-07 08:03:19 i suppose it's okish 2022-02-07 08:03:40 just want a crosscheck with someone else before pushing something on main 2022-02-07 08:03:48 and they recommend projects to use latest anyway 2022-02-07 08:03:59 overall i think there are already quite a few packages that have some version of gtest bundled in 2022-02-07 08:04:15 just because they ship it inside their tarball, and use some newest version 2022-02-07 08:04:34 that's true as well 2022-02-07 08:04:43 if it was not a test framework i would be a bit more cautious, but here i don't expect much to go wrong 2022-02-07 08:07:26 ok. Thx for your feedbacks psykose 2022-02-07 09:37:04 could someone have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30368 2022-02-07 10:11:33 Hi, can someone please look at https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/99 and https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/100? Thanks! 2022-02-07 15:15:54 ikke: how does one assign things to a username? the shitty ui can't actually search for names but must find one to be able to assign.. unless the glab cli can do anything :p 2022-02-07 15:16:56 cannot assign to non-members 2022-02-07 15:20:42 i just did with glab 2022-02-07 15:20:53 strange 2022-02-07 15:21:03 well, nice to get an actually working cli tool i guess 2022-02-07 15:21:19 what's the prefered build type for CMake stuff, relwithdebinfo ? 2022-02-07 15:21:26 MinSizeRel 2022-02-07 15:21:37 or if it actually does anything performant, Release 2022-02-07 15:21:56 ack 2022-02-07 15:22:57 and in case i want to also produce a -dbg package, MinSizeRel too? 2022-02-07 15:23:37 it should work with minsizerel anyway 2022-02-07 15:23:52 ack 2022-02-07 15:23:54 it doesn't strip flags- all -dbg does is append `-g` to flags, then split the info 2022-02-07 15:23:56 thanks 2022-02-07 15:24:00 so it generates it anyway 2022-02-07 15:24:04 good to know 2022-02-07 15:24:11 i mean it's cmake 2022-02-07 15:24:17 there is probably some project that strips all the flags 2022-02-07 15:24:21 hehe 2022-02-07 15:24:25 but yeah, just those two should be fine 2022-02-07 15:27:00 You _can_ assign to non-members, but gitlab does not auto-complete them 2022-02-07 15:27:18 there's no button or thing to click in the interface for some reason 2022-02-07 15:27:29 or well, at least what i tried over 2 minutes 2022-02-07 15:27:36 but i really should have been using glab all along anyway, haha 2022-02-07 15:27:53 thanks for the recommendation before 2022-02-07 18:08:13 ikke: is there an easy way to kill ci after a glab merge 2022-02-07 18:08:24 or is it fine for it to just time itself out after a minute because of the no-changes 2022-02-07 18:08:51 Not through glab AFAIK 2022-02-07 18:09:07 I thought the alpine Gitlab bot was supposed to automatically cancel pipelines after merge? 2022-02-07 18:09:33 i haven't seen that 2022-02-07 18:09:44 i mean they kill themselves because by the time they run, there are no diff changes anymore 2022-02-07 18:09:46 so it just exits 2022-02-07 18:09:49 but that still takes ~1 minute 2022-02-07 18:10:51 The method it uses only works for pipelines from non-members 2022-02-07 18:12:30 ah 2022-02-07 18:12:39 clearly i need to drop my membership then.. 2022-02-07 19:14:21 thanks for the quick review psykose 2022-02-07 19:14:53 iirc this was needed for the new wlroots vulkan backend 2022-02-07 19:15:41 not exactly 2022-02-07 19:16:02 but i have a patch pending that removes the hard link on the layers 2022-02-07 19:16:31 ah 2022-02-07 19:17:20 ah yes you're right, it's this one 2022-02-07 19:27:48 whoa -dev package picked the static lib and headers and left the shared in the base package 2022-02-07 19:27:50 neat 2022-02-07 19:28:38 yes 2022-02-07 19:29:00 i think the usual way is to also add a -static before the -dev too, just to get slightly lower size on the -dev 2022-02-07 19:29:07 since most things will never use it 2022-02-07 19:29:10 depends i guess 2022-02-07 19:29:32 dev is just the headers and the static lib so far 2022-02-07 19:31:34 yes 2022-02-07 19:31:49 -static puts the static lib by itself into its own package, and then all of -dev is just some headers 2022-02-07 19:31:51 so it has like no size 2022-02-07 19:32:11 the .a by itself is usually a bit bigger, and since almost nothing statically links to anything, is just wasted network/disk time later 2022-02-07 19:32:13 (overall) 2022-02-07 19:33:09 shall i do the edit? 2022-02-07 19:35:31 bl4ckb0ne: sure 2022-02-07 19:37:18 done 2022-02-07 19:43:04 bl4ckb0ne: it seems like you don't need net and update_deps, if you package like the missing robin-hood-hashing and add the vulkan deps 2022-02-07 19:43:44 spirv-tools-dev and vulkan-headers exist 2022-02-07 19:43:57 i would assume it all works, just missing another package 2022-02-07 19:44:56 there is some argument that .a files should be just deleted if nobody will be using them 2022-02-07 19:45:37 ah yes, can do without the update_deps stuff, also robin-hood-hashing is optional 2022-02-07 19:46:11 Hello71: the .a seems indeed not used in linux 2022-02-07 19:47:00 or better, not generated in the first place, but ar c is normally fairly cheap 2022-02-07 19:47:15 guess I could just rm it from package step 2022-02-07 19:47:52 is it optional 2022-02-07 19:47:55 must've missed the flag 2022-02-07 19:47:57 hehe 2022-02-07 19:48:04 must just work then i would guess 2022-02-07 19:48:21 normally i don't care too much about random fetched deps, but in this case the vulkan toolchain is profoundly fragile 2022-02-07 19:48:35 we are like months behind on even updating it, i am sure if someone bumped everything nothing would work 2022-02-07 19:49:11 we're up to date this time 2022-02-07 19:51:40 ugh getting a lot of errors with the alpine spirv-tools 2022-02-07 19:52:46 guess im gonna have to bump it 2022-02-07 19:53:06 yeah 2022-02-07 19:53:14 i looked at it before, needs like 5 rebuilds/similar bumps 2022-02-07 19:53:32 2022.1 was released 12 days ago 2022-02-07 19:53:41 alpine is at 2020.3 2022-02-07 19:53:43 wew 2022-02-07 19:53:46 yep 2022-02-07 19:54:06 if you know how to actually '''test the vulkan stack''' go for it 2022-02-07 19:54:16 i don't, so i thought it would be better to not 2022-02-07 19:55:03 iirc i had a script somewhere when i bumped the header 2022-02-07 19:55:31 mm 2022-02-07 19:55:43 huh spirv-headers has no maintainers 2022-02-07 19:55:56 yes, used to be lew 2022-02-07 19:55:58 leo* 2022-02-07 20:12:21 weee, build error from latest spirv-tools 2022-02-07 20:12:28 what is it 2022-02-07 20:13:15 https://github.com/KhronosGroup/SPIRV-Tools/issues/4699 2022-02-07 20:13:54 that's not an error 2022-02-07 20:14:01 you have outdated spirv-headers 2022-02-07 20:14:04 then it will go away 2022-02-07 20:14:22 it's also 1.5 years old 2022-02-07 20:14:34 latest version also changed namingscheme 2022-02-07 20:14:37 to sdk-1.2.198.0 for some reason 2022-02-07 20:15:04 but yeah i've had that before, it's missing that specific header version, that's all :) 2022-02-07 20:15:41 *sigh* 2022-02-07 20:16:11 kek 1.5.4.raytracing and 1.5.4.raytacing.fixed 2022-02-07 20:16:27 and that also adds vkd3d to the list of rebuilds 2022-02-07 20:16:41 and maybe wine, not sure, don't actually know how they interact 2022-02-07 20:17:00 .fixed probably means something to do with 'fixed' in a mathematical sense 2022-02-07 20:17:17 unless that's a tag 2022-02-07 20:17:19 oh yea 2022-02-07 20:17:20 hehe 2022-02-07 20:17:42 not sure how to name the pkgver given the different version that is below the current one 2022-02-07 20:18:11 very annoyin 2022-02-07 20:18:18 the builds are easy at least 2022-02-07 20:38:28 would it be acceptable to let a todo on the validation layer to yeet the update_deps stuff once spirv-* is up to date? 2022-02-07 20:38:57 i would guess there is some issue with something being built against newer spirv-* than everything else 2022-02-07 20:38:59 but i could be wrong 2022-02-07 21:35:40 oh boy, that spirv stuff is a bloody mess 2022-02-07 21:35:53 is it 2022-02-07 21:35:56 everything built fine for me 2022-02-07 21:36:13 spirv-tool is released tracking a commit on spirv-headers 2022-02-07 21:36:18 https://github.com/KhronosGroup/SPIRV-Tools/blob/sdk-1.2.198/DEPS#L9 2022-02-07 21:36:28 good thing is that spirv-tools seems to use the same rev number as vulkan 2022-02-07 21:36:34 bad thing is that they are hecking late 2022-02-07 21:36:51 that's fine 2022-02-07 21:36:54 spirv-headers* 2022-02-07 21:37:02 although i looked at arch as well and they package that commit instead of sdk-* 2022-02-07 21:37:35 https://opensuse.pkgs.org/tumbleweed/opensuse-oss-x86_64/spirv-headers-1.6.g6-1.1.noarch.rpm.html tumbleweed doesnt care 2022-02-07 21:38:18 https://github.com/KhronosGroup/SPIRV-Headers/branches also 2022-02-07 21:40:50 arch isnt all up to date iirc 2022-02-07 21:42:59 PureTryOut: dunno if you've seen https://github.com/cntools/libsurvive/releases/tag/v1.0 2022-02-07 21:43:04 let me know if you want the patch 2022-02-07 21:46:07 psykose: made a release request for spirv-headers 2022-02-07 21:49:42 bl4ckb0ne: i think i saw another request months ago in the issues 2022-02-07 21:49:51 no idea now though 2022-02-07 21:50:14 https://github.com/KhronosGroup/SPIRV-Headers/issues/252 2022-02-07 21:50:38 mar 2021 in the link 2022-02-07 21:50:39 the branch for 1.3.204 exists but is not tagged 2022-02-07 21:51:29 haha 2022-02-07 21:51:36 technically you can package the branch 2022-02-07 21:51:39 if you really want 2022-02-07 21:51:57 waiting on an answer on the issue 2022-02-07 21:52:16 but the commit we need is head of this branch 2022-02-07 21:52:24 might end up doing that if i have no answer shortly 2022-02-07 21:53:34 that vulkan bug is starting to cost me too much time 2022-02-08 05:29:59 bl4ckb0ne: I have 😉 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30564 2022-02-08 08:40:40 will `apk upgrade -l` "downgrade" packages to an earlier pkgrel if that's the latest version available in the configured repositories? 2022-02-08 08:42:44 You need to pass --available 2022-02-08 08:43:14 err, -a is what I meant 2022-02-08 08:43:18 and it does what I said? 2022-02-08 08:44:45 I haven't complained about Python enough lately 2022-02-08 08:44:51 I encountered yet another package manager today 2022-02-08 08:44:56 and of course it's totally broken 2022-02-08 08:45:05 Yes, it will use whatever version is available 2022-02-08 08:45:10 thanks ikke! 2022-02-08 08:59:40 petition to change the standard commit message language from "upgrade" to "downgrade" for any python package which switches to a new and exciting build system in a subsequent release 2022-02-08 09:10:55 Hi, can someone give me a hint how to compile just the -virt kernel? Following this guide all kernels get compiled.. https://wiki.alpinelinux.org/wiki/Custom_Kernel 2022-02-08 09:35:32 ddevault: how about "move to unmaintained" 2022-02-08 09:36:10 if only 2022-02-08 09:36:25 I'm still probably at least a year out from removing python from my stack 2022-02-08 09:37:09 bolzerrr, you can remove config-lts files from source and run 'abuild checksum' 2022-02-08 09:37:25 flavors are based on what configs are available, so that should build only the virt kernel 2022-02-08 09:38:05 i haven't tested it though, it might fail later after compiling 2022-02-08 10:00:42 @ptrc Thank you for the tip, i will give it a try and comback how it worked 2022-02-08 10:23:49 has anyone attempted to package pcsx2 for alpine before? 2022-02-08 10:28:38 not to my knowledge 2022-02-08 10:28:40 maybe i should try 2022-02-08 10:28:45 since my current computer might even run it 2022-02-08 10:29:01 I will probably give it a go soonish 2022-02-08 10:29:08 itching to play an old PS2 favorite 2022-02-08 10:29:13 iirc the wxgtk stuff is mildly broken with wayland? 2022-02-08 10:29:24 something about some upstream bug that crashes instantly without GDK_BACKEND=x11 2022-02-08 10:29:48 I'm prepared to believe that 2022-02-08 10:29:55 and I am also prepared to export GDK_BACKEND=x11 when I run it 2022-02-08 10:30:14 mhm 2022-02-08 10:30:18 i used to do that last time i tested it.. 2022-02-08 10:30:27 on gentoo 2022-02-08 10:32:44 ah, seems rapidyaml is missing 2022-02-08 10:33:07 what on earth does pcsx2 need yaml for 2022-02-08 10:33:10 tweaks database? 2022-02-08 10:33:40 maybe 2022-02-08 10:33:43 also there is a qt option now 2022-02-08 10:33:45 instead of wxgtk.. 2022-02-08 10:33:51 hmm 2022-02-08 10:36:03 oh, it needs both in that case 2022-02-08 10:36:03 funny 2022-02-08 10:37:14 rpcs3 might also be an interesting one to try 2022-02-08 10:46:34 the rapidyaml thing has like 4 vendored submodules in a chain 2022-02-08 10:46:35 fun 2022-02-08 10:46:47 that's helpful 2022-02-08 10:56:44 now it wants a vendored version of glslang, vulkan-headers, and some cpp library 2022-02-08 10:56:56 and with qt6 enabled it wants a vendored version of latest sdl2, hehe 2022-02-08 10:57:06 but i think that is it... hopefully 2022-02-08 11:59:52 could someone take a look at !30412 2022-02-08 12:02:39 openrct2 bumped pkgrel twice 2022-02-08 12:03:26 oh, mb 2022-02-08 12:03:59 also seems like you indented some things with spaces 2022-02-08 12:04:04 aside from that, looks fine to me 2022-02-08 12:04:10 think we should just merge it and see how it goes 2022-02-08 12:04:12 been a while 2022-02-08 12:04:35 ikke: ^ feel like it? 2022-02-08 12:05:41 testing/libvmime/rebuild for icu 70.1 has / instead of : 2022-02-08 12:07:04 i have all day- we can catch the failures as they come 2022-02-08 12:08:25 the commit that adds scons into mapnik doesn't have it sorted into the correct place (and everything in there changed to spaces) 2022-02-08 12:09:28 and i think that's it 2022-02-08 12:11:25 what do u mean with sorted in the correct place? 2022-02-08 12:12:11 they are sorted 2022-02-08 12:12:14 alphabetically 2022-02-08 12:12:27 oh 2022-02-08 12:24:27 should be good now, (as well as the tabs?) 2022-02-08 12:28:54 okay nvm, fcked up the rebase 2022-02-08 12:31:05 should be good now (attempt 2) 2022-02-08 12:32:58 `--jobs=${JOBS-2} \` doesn't look correct 2022-02-08 12:33:07 also what does `scons $(expr "$MAKEFLAGS" : '.*\(\-j[0-9]\+\)')` do 2022-02-08 12:33:54 fwiw there isn't a need for JOBS:-2 as it's always set on the builders anyway 2022-02-08 12:36:52 ah i see, it exprs jobs from makeflags 2022-02-08 12:37:00 no point for that, you can just do `-j $JOBS` 2022-02-08 12:37:49 should also indent the lines after each \ one more 2022-02-08 12:37:51 ah, that scons line came from arch as i never worked with scons before 2022-02-08 12:37:53 and that is enough nitpicking from me 2022-02-08 12:38:57 1 tab or space 2022-02-08 12:40:23 gonna do tab toh this time 2022-02-08 12:41:09 tab 2022-02-08 12:41:42 https://img.ayaya.dev/6ctMTKkJgj16 2022-02-08 12:41:43 like that 2022-02-08 12:51:26 done 2022-02-08 12:55:09 you forgot to build in the build() i think 2022-02-08 12:55:16 before it was scons configure; scons 2022-02-08 12:55:18 now it's just configure 2022-02-08 12:55:21 and it builds in the package step 2022-02-08 12:57:40 just need a `scons --jobs $JOBS` at the bottom and that's it 2022-02-08 13:07:49 done 2022-02-08 13:08:45 ok, now just to wait for ikke 2022-02-08 13:09:14 ty for review 2022-02-08 14:16:21 Ariadne: if you have a better idea on how to implement this please let me know, C is not really my strength https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/95 2022-02-08 14:34:06 ddevault: yep, closes instantly with no errors at all with wayland, and GDK_BACKEND=x11 works https://img.ayaya.dev/n3xeBXRbSBrU.png 2022-02-08 14:34:40 i have a working apkbuild for it and a dependency, not sure if it works outside of x86_64 though 2022-02-08 14:34:54 psykose: nice 2022-02-08 14:35:45 debian only packages it for x86_64 so I think we can presume that your summation is correct 2022-02-08 14:42:20 !30624 if you want to give it a cursory glance 2022-02-08 14:42:30 thanks! I will look at it when I get home (in a few hours) 2022-02-08 14:42:45 enjoy your time outside :) 2022-02-08 14:45:36 why does it need vendored glslang and vulkan-headers? 2022-02-08 14:45:58 because it does 2022-02-08 14:46:09 as in, that is what the build system is doing 2022-02-08 14:46:24 there is a dir with a .cmake file that does a includesources(*.c) of all the files from those and builds them 2022-02-08 14:47:09 patching it out would require.. a bunch of magic, but would also most likely not work with our older headers too 2022-02-08 16:55:28 the pcsx2 repo banned me for trying to fix a regression... 2022-02-08 16:56:15 pcsx2 guys are... difficult 2022-02-08 16:57:09 like 12 years ago when i was doing emu dev still, i found an emulation bug in pcsx2 and it was an uphill battle to get them to fix it, even though behavior was demonstrated to not match the real PS2 2022-02-08 16:57:56 sounds about right 2022-02-08 16:57:59 yea, I couldn't even get them ti discuss the issue with me, trying to coax them into discussion and BANNED 2022-02-08 17:01:33 is that dirt we need to be digging up in #alpine-devel 2022-02-08 17:01:55 given I was a pcsx2 package maintainer, it is fair warning 2022-02-08 17:02:04 fair enough 2022-02-08 19:28:09 ncopa: btw: do you mind if I take over maintainership of busybox? 2022-02-08 20:25:37 nmeum: +1, you're doing a good job at getting our stuff upstreamed 2022-02-08 20:26:17 +1 from me as well 2022-02-09 12:20:05 ikke: i think https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30412 is ready 2022-02-09 12:37:24 I'll look at it when I have some time 2022-02-09 13:28:42 omg, is it likely to break things on edge until full rebuilt? 2022-02-09 13:30:07 somewhat, yes 2022-02-09 13:30:22 well 2022-02-09 13:30:24 not broken 2022-02-09 13:30:33 you just wont be able to upgrade some things at worst, most likely 2022-02-09 13:31:08 ok 2022-02-09 13:31:23 it's one repo at a time, so until all three clear there is a mix of versions 2022-02-09 13:31:39 but if you don't do weird stuff apk just won't update anything on conflict 2022-02-09 13:32:05 there is a chance the rebuilds pass but the actual package is broken afterward 2022-02-09 13:32:14 but i don't expect that to be many 2022-02-09 13:32:47 ok ok, no worries, I will just be ready for doing a rollback 2022-02-09 13:33:27 you can simply not upgrade for a day 2022-02-09 13:33:32 but yeah, you keep snapshots 2022-02-09 13:33:37 all good :) 2022-02-09 13:33:57 they are cheap and very useful when needed hehe 2022-02-09 13:34:00 mhm 2022-02-09 13:34:16 is it possible for the rollback tool to be broken? 2022-02-09 13:34:19 altoguht now I think that my root snapshots are broken 2022-02-09 13:34:28 only @HOME working 2022-02-09 13:34:40 the 'rollback tool' here is whatever you have set up to do it 2022-02-09 13:35:28 psykose: yes, so I'm just wondering what people do when their system is broken _and_ they can't rollback? 2022-02-09 13:35:32 with a basic hook scripts for apk it would be easy to have rollbacks for btrfs, zfs, lvm... 2022-02-09 13:35:42 hmm 2022-02-09 13:35:58 i mean it's very unlikely to have an actual broken system that isn't one package somewhere 2022-02-09 13:36:12 but in that case you can install an apk to the --root of the drive from a recovery usb 2022-02-09 13:36:15 and install whatever you need 2022-02-09 13:36:34 psykose: Ah makes sense 2022-02-09 13:36:37 that you know might've been the issue 2022-02-09 13:36:37 shrug 2022-02-09 13:36:38 ktprograms: I just reboot with an alpine usb, restore some snapshots to a new subvolume 2022-02-09 13:36:40 it really depends how it broke 2022-02-09 13:36:46 and edit the subvol= line on grub 2022-02-09 13:37:25 using btrfs 2022-02-09 13:38:10 a sorry I didn't understand your question well 2022-02-09 13:38:20 the "they can't rollback" part :S 2022-02-09 13:39:29 donoban: I don't really know much about filesystems, but the way you describe it, it seems like you _can't_ be in a situation that you can't restore 2022-02-09 13:40:11 well the drive can randomly die 2022-02-09 13:40:11 poof 2022-02-09 13:40:13 :p 2022-02-09 13:40:13 I just do an automated snapshot everyday, so in the worst case I always can restore my system to one day before 2022-02-09 13:42:18 psykose: with ssd there is no click of death warning 2022-02-09 13:43:08 hehe, I had a hard disk working for years that always failed at first start (doing some kind of ping of death) but worked fine after one or two resets 2022-02-09 13:43:18 s/ping/click 2022-02-09 13:43:18 donoban meant to say: hehe, I had a hard disk working for years that always failed at first start (doing some kind of click of death) but worked fine after one or two resets 2022-02-09 14:56:48 ncopa: hey / ping, I was looking at the libcap-ng package and I noticed the `--disable-static` explicitly being passed to it. Is there any specific reason for that? 2022-02-09 15:52:08 The default option to reduce package sizes 2022-02-09 15:59:40 why are build logs being pruned so aggressively? https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/ghostscript/ghostscript-9.55.0-r0.log is only three months old and already deleted? 2022-02-09 16:00:07 ikke: what's the way to go if one needs the static version of libcap-ng? 2022-02-09 16:00:47 build it yourself 2022-02-09 16:01:20 why 2022-02-09 16:01:27 no option at all to have a static version of the package as part of the distro? 2022-02-09 16:01:55 but why 2022-02-09 16:03:15 Hello71: I am trying to build a software used as part of kata-containers (virtiofsd) and I can't have it built statically (so I can easily distribute it somewhere else) because there's no static version of libcap-ng 2022-02-09 16:04:07 i mean, in theory adding a -static does not affect the rest 2022-02-09 16:04:18 but if you can set up any building at all, it's not very hard to add your own build into there 2022-02-09 16:05:07 psykose: I´d rather go with adding a non-installed-by-default -static package 2022-02-09 16:05:29 that can actually help others looking for the same package and avoid myself and someone else building it on our own 2022-02-09 16:05:35 does virtiofsd even have a stable api 2022-02-09 16:06:15 Hello71: define stable API, it's not a library 2022-02-09 16:06:39 or are you trying to compile all of kata using distro static packages and distribute it to non-alpine systems 2022-02-09 16:06:43 psykose: still takes up space on the mirrors 2022-02-09 16:06:51 yes, of course 2022-02-09 16:07:11 ..sometimes i forget those exist 2022-02-09 16:07:35 Hello71: we already build some of the kata-containers using distro static packages to use those on non-alpine systems 2022-02-09 16:07:37 speaking of, py3-dnspython needs a rel bump 2022-02-09 16:08:45 and the reason I'm asking is because `apk search "-static"` shows me 234 packages already 2022-02-09 16:09:04 which makes me think that I'm not exactly asking for something utterly unusual 2022-02-09 16:12:03 there is some debate about the extent to which such packages should be provided 2022-02-09 16:13:01 Hello71: makes sense 2022-02-09 16:13:13 well, I'd be happy to happy on having a static version of that library around 2022-02-09 16:13:30 kata-containers and virtiofs would benefit from that, and so would their users 2022-02-09 16:13:52 so, if there's something I can help with, please, let me know and I can submit the patches 2022-02-09 16:14:09 You could create a merge request and ask the maintainer if they agree 2022-02-09 16:15:57 i think the majority opinion is that there are too many such packages, and they should be pared down to the minimum (probably just busybox, gcc, llvm, and musl). there is a smaller group which thinks that all libraries should have -static, but this runs into the significant barrier of insufficient mirror space. we are left with the stalemate option, which is an ad-hoc addition 2022-02-09 16:15:58 of -static when someone asks for it 2022-02-09 16:16:43 ikke: sure, I will give it a few and see if ncopa shows up around and replies, if not, I will go ahead an open the MR sooner than later. 2022-02-09 16:17:03 ikke: Hello71: psykose: thanks for the input, very much appreciated! 2022-02-09 16:19:31 personally i am strongly opposed to this third option, for two reasons: first, it disadvantages users who may want something en masse but not enough to come complain about it; second, there is no process for *removing* such packages 2022-02-09 16:28:24 Hello71: but from the POV of the person who shows up here to ask for something, that's a distro and distro policy problem, no? 2022-02-09 16:28:54 what? 2022-02-09 16:29:40 please, don't take me wrong, but the bigger discussion is, indeed, necessary, but the joe doe like myself who shows up asking about "foo-static" can't do much apart from following a (possible good to be added?) policy about package changes / package additions / package removals 2022-02-09 16:30:18 Hello71: but it boils down to the distro having a discussed and documented policy about that 2022-02-09 16:46:35 Hello71: i think it might be worth revisiting -static 2022-02-09 20:41:28 don't touch my static packages, baka 2022-02-09 21:08:15 Misthios: Seems like one commit ended up empty 2022-02-09 21:13:02 skarnet: i meant as in adding more 2022-02-09 21:15:09 if disk space isn't an issue (and if it is, that's what should be fixed) I'm all for it 2022-02-09 21:16:35 sadly fixing disk space issues isn't as easy as everyone makes it out to be 2022-02-09 21:16:47 Unless we change the complete build process 2022-02-09 21:18:46 ncopa: could you take a look at !26763 ? 2022-02-09 21:19:11 ikke will take a look after a shower 2022-02-09 21:20:02 Misthios: I could just bump the pkg myself 2022-02-09 21:22:32 But it think its bumped ? But just in a wrong commit 2022-02-09 21:23:26 ah, right 2022-02-09 21:23:35 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30412/diffs#diff-content-c442dde8b3daede99b0a68b774abee2fe580cf5c 2022-02-09 21:25:36 Misthios: ah, it's just a duplicate commit 2022-02-09 21:25:47 41b5030d7f255c6c90a42359bd073446f5af8b0b 2022-02-09 21:30:21 Oh 2022-02-09 21:30:37 Wonder how i managed to do that 2022-02-09 21:33:47 ikke: can we donate disks to the builders? 2022-02-09 21:33:55 or something? 2022-02-09 21:48:38 i mean, i'm pretty sure coming up with some hard drives 2022-02-09 21:48:42 or funding for hard drives 2022-02-09 21:48:45 is not a huge problem 2022-02-09 21:54:09 if ikke says fixing disk space issues isn't easy, I believe him, so there has to be more than just donating drives 2022-02-09 21:58:11 well, the builders are all sponsored 2022-02-09 21:59:05 hey sponsors gief more disks plz 2022-02-09 21:59:22 some sponsors are more capable of doing that than others 2022-02-09 21:59:33 is the problem AFAIK 2022-02-09 21:59:54 I see. 2022-02-09 22:00:00 if the main builder was not responsible for maintaining the master repo for that arch 2022-02-09 22:00:04 then this would not be a problem 2022-02-09 22:00:08 because we could just be like 2022-02-09 22:00:12 object storage go brrrrrrrr 2022-02-09 22:01:06 i have Opinions on the build system used to build alpine (including Opinions on abuild) 2022-02-09 22:01:47 at $dayjob i need a farm-to-table APK build system, so i am going to write some things 2022-02-09 22:01:58 actually, i am already writing some things 2022-02-09 22:05:14 so instead of fragile lua stuff, lets talk about kubernetes 2022-02-09 22:05:22 that TSC ticket is going to be a trip :) 2022-02-09 22:05:51 or, we could go full meme tier and get jfrog to sponsor alpine 2022-02-09 22:06:07 they have a full APKBUILD to .apk pipeline that, if you ignore the microoutages, is quite robust 2022-02-09 22:06:18 artifactory goes down a *lot* :( 2022-02-09 22:14:02 like honestly, why even have mirrors 2022-02-09 22:14:05 just CDN all the things 2022-02-09 22:14:18 sorry, i know, very 2022 thinking 2022-02-09 22:41:59 "22:00 if the main builder was not responsible for maintaining the master repo for that arch" i've been thinking for a while that this could be hacked around by just uploading -dbg packages separately 2022-02-09 22:42:15 the main problem with this is that it's hacks on hacks, plus another hacks is necessary for pruning old packages 2022-02-09 22:42:29 i'd rather just go through the pain of tossing out the current build system 2022-02-09 22:43:14 i agree, but what is actually better 2022-02-09 22:44:17 i've also been thinking for some time that it would make sense to use gitlab ci to build packages, to reduce our "building packages three times over" problem. it is, after all, "continuous deployment" 2022-02-09 22:44:51 but gitlab ci lacks inter-pipeline dependencies, and also i think less gitlab dependency is better, not more 2022-02-09 22:47:28 ncopa wanted to do some kubernetes thing 2022-02-09 22:47:34 so i'm doing some kubernetes thing 2022-02-09 22:47:54 i'm also abstracting it so that we can replace abuild later :P 2022-02-09 22:48:37 (at $dayjob we don't want to use abuild, we want something fully declarative that builds packages from (ideally) signed git tags) 2022-02-09 22:50:10 how unrecommended is it to package a branch 2022-02-09 22:50:24 depends 2022-02-09 22:50:32 gcc in alpine is basically a soft fork 2022-02-09 22:50:42 spirv-header is very lazy with the release 2022-02-09 22:50:59 https://github.com/KhronosGroup/SPIRV-Headers/tree/sdk-1.3.204 2022-02-09 22:51:10 i opened an issue for a tag 2 days ago, no sign of life 2022-02-09 22:51:39 the branch looks stale, will package it tomorrow if i still have no answer 2022-02-09 23:00:59 bl4ckb0ne: usually you want to wait for the rest of vulkan to be tagged with a sdk release 2022-02-09 23:01:19 its still at sdk-1.2.198.0 I think 2022-02-09 23:02:12 https://vulkan.lunarg.com/sdk/home#linux 2022-02-09 23:02:18 says 1.2.198.1 there 2022-02-09 23:02:52 if they dont reply to issues you can try the issue tracker there too 2022-02-09 23:07:50 how to build a package on a specific arch but make the resultant package available/installable on all archs? 2022-02-09 23:08:51 bl4ckb0ne: also SPIRV-tools has the SDK tags too 2022-02-09 23:37:38 minimal: you can't on the current build system 2022-02-09 23:38:10 Ariadne: ok, so then cross-compilation would be the only approach? 2022-02-09 23:38:20 yes 2022-02-09 23:39:19 Ariadne: this is regarding edk2 - the AAVMF files are aarch64 binaries and the OVMF files are x86/86_64 binaries but both sets of files need to be package so they can be installed on a machine of any arch 2022-02-09 23:39:49 build them by hand and then write an apkbuild that just redistributes the blob ;/ 2022-02-09 23:41:04 at present you cannot run a aarch64 (UEFI) VM on x86_64 nor a x86_^4 (UEFI) VM on arch64 as only the x86_64 package contains the x86_84 files and vice versa 2022-02-09 23:41:42 wheres on a Debian x86_64 laptop I have 2 packages installed and can run both types with QEMU 2022-02-09 23:42:38 I added a comment to !26763 about this 2022-02-10 00:05:42 orbea: its been a while, and spirv-tools has a tag but it tagged this branch 2022-02-10 00:06:05 bl4ckb0ne: the stable tags start with sdk- 2022-02-10 00:06:09 https://github.com/KhronosGroup/SPIRV-Tools/blob/v2022.1/DEPS#L9 2022-02-10 00:06:24 spirv-tools release is 14 days old 2022-02-10 00:06:35 all of the other tags will not neccesarily correspond to any other releases 2022-02-10 00:06:59 which points to https://github.com/KhronosGroup/SPIRV-Headers/tree/sdk-1.3.204 2022-02-10 00:07:16 you mean https://github.com/KhronosGroup/SPIRV-Headers/releases/tag/sdk-1.2.198.0 2022-02-10 00:08:21 https://github.com/KhronosGroup/Vulkan-Headers#version-tagging-scheme 2022-02-10 00:09:36 this one is the previous one 2022-02-10 00:09:40 the new one has not been tagged 2022-02-10 00:09:50 thus is not released yet 2022-02-10 00:09:54 *its 2022-02-10 00:10:09 yeah that's why i want to package the branch 2022-02-10 00:10:21 you might introduce instabilities 2022-02-10 00:10:27 branch is stale 2022-02-10 00:11:03 the vulkan packages are pretty version dependent on each other... 2022-02-10 00:11:11 but thats why i asked how unrecommended it is to package a branch 2022-02-10 00:11:25 well, spirv-tools depends on this branch 2022-02-10 00:11:36 not if you use the sdk tags... 2022-02-10 00:11:48 well 2022-02-10 00:11:50 ill wait then 2022-02-10 04:03:25 is there an example of a package which builds say a single kernel module to match linux-lts for example? I want to make it easy to add the speakup module. 2022-02-10 04:06:31 and really what I am going for is like the debian espeakup package, so speakup kernel module uses espeak software synth: https://tracker.debian.org/pkg/espeakup, https://github.com/williamh/espeakup, so likely would package espeakup as a package and somehow depend on the speakup kernel module 2022-02-10 04:09:02 unfortunately it looks way more complicated than I had thought it would be. I'll do more research I guess as it's not entirely clear how debian handles this, especially the kernel module part. 2022-02-10 04:14:09 this seems... extremely old 2022-02-10 04:15:36 anyways, https://pkgs.alpinelinux.org/packages?name=*-lts&branch=edge&arch=x86_64 2022-02-10 04:15:53 but isn't speakup upstreamed anyways 2022-02-10 04:16:52 as of linux... 3. 2022-02-10 04:30:40 speakup is already available in linux-lts package as a module I see. so that part is done, the connective stuff in espeakup I can try building and see if it works :+1: cool! I was waiting days to build a linux kernel on a 1999 Thinkpad 240 :p (one celeron core at 298MHz :) thanks for checking Hello71 :) 2022-02-10 04:31:10 I didn't check the config at first, assumed it wasn't included, but it is built as a module and included. 🎉 2022-02-10 04:32:33 in-tree modules typically cannot be compiled out-of-tree 2022-02-10 04:34:18 mm, yeah, never really tried it or anything. 👍️ 2022-02-10 10:36:06 ikke, clandmeter : setup-alpine answer file cannot yet be passed via cmdline right? 2022-02-10 10:36:36 An unattended installation still require a custom ISO running the setup-alpine precreated answer file 2022-02-10 10:36:59 correct? 2022-02-10 10:37:33 (or a custom apkovl) 2022-02-10 10:38:11 im not following 2022-02-10 10:38:32 setup-alpine has an option to provide an answer file 2022-02-10 10:38:50 you mean passing it to the iso media? 2022-02-10 10:38:54 this answer file can be passed to an iso? 2022-02-10 10:38:56 Exactly 2022-02-10 10:39:01 no 2022-02-10 10:39:13 so if I want to apply it i need manual intervention 2022-02-10 10:39:18 how would the iso get the file? 2022-02-10 10:39:34 http/tftp 2022-02-10 10:39:54 so you need some sort of tool in the iso 2022-02-10 10:40:38 the only tool we currently have is firstboot init script 2022-02-10 10:40:47 afaik 2022-02-10 10:41:45 is the same idea of apkovl,but just for an answer file 2022-02-10 10:42:15 apkovl can be passed via network in netboot scenario, or automatically is searched in some path 2022-02-10 10:42:31 i was wondering if the same can be done for an answer file 2022-02-10 10:42:33 but ok 2022-02-10 10:42:37 we don't have it 2022-02-10 10:44:21 apkovl is a different animal 2022-02-10 10:45:47 i guess you want to install to disk? 2022-02-10 10:45:56 yes 2022-02-10 10:46:52 we have been talking about adding changing setup-alpine 2022-02-10 10:47:47 converting it to lua or so 2022-02-10 10:47:51 A nice tool I've used in the past is alpine-lift 2022-02-10 10:48:03 and make it support cloud-init config 2022-02-10 10:48:18 but still you need the binary service starting on boot, as you said...a tool 2022-02-10 10:48:32 what is alpine-lift? 2022-02-10 10:48:52 i get pictures of mountains full of snow :D 2022-02-10 10:49:03 lol 2022-02-10 10:49:03 https://github.com/bjwschaap/alpine-lift/blob/master/README.md 2022-02-10 10:49:04 eheheh 2022-02-10 10:50:22 right 2022-02-10 12:25:52 ikke where there others things u noticed in !30412 2022-02-10 12:28:50 Misthios: no, that was the only thing. Just wanted to give the persons you pinged time to respond 2022-02-10 12:29:00 ah okay 2022-02-10 14:42:43 fcolista: alpine-lift / cloud-init / tiny-cloud are typically used to configure a machine on 1st boot (i.e. from a prepared disk image). I guess these could be used instead to "drive" an installer such as setup-alpine where the user-data.yaml could create an answers file, I haven't looked into that so far 2022-02-10 16:08:55 fwiw, i'm working on a "simple/shell" yaml extractor tool that could be used to pull information from user-data while keeping deps lightweight (basically ash, grep, awk, sed) -- and extending tiny-cloud to handle "nocloud"-ish datasources 2022-02-10 18:09:42 ACTION still not understand how cloud-init work with alpine 2022-02-10 18:14:30 fcolista: you have to create a physical/VM/Cloud disk image with cloud-init already installed and then the 1st time this is booted it fetches configuration and applies it 2022-02-10 18:14:54 fcolista: have a look at https://github.com/dermotbradley/create-alpine-disk-image 2022-02-10 18:26:25 ikke: do you know what is wrong with the ci on !30715 2022-02-10 18:33:46 apkbuild is dos format 2022-02-10 18:33:59 oh 2022-02-10 18:33:59 lmao 2022-02-10 18:34:04 how 2022-02-10 18:34:06 also noeol but i bet it's the dos 2022-02-10 18:34:19 that should really get flagged 2022-02-10 18:34:20 jesus 2022-02-10 18:34:31 but it is :p 2022-02-10 18:34:50 where 2022-02-10 18:35:08 well the ci isn't working, isn't that a red flag :p 2022-02-10 18:35:17 no 2022-02-10 18:35:46 i'm not actually sure what exactly is happening 2022-02-10 18:36:49 me either, as the previous ci lints 'pass' 2022-02-10 18:36:52 but the ci is broken there too 2022-02-10 18:36:54 and sees no changes 2022-02-10 18:37:32 but yeah, it is dos 2022-02-10 18:49:29 My bad! I thought touching the file via terminal would set it to LF, but apparently Notepad ignores that when it's an empty file and set it to CRLF 2022-02-10 18:49:57 i thought windows notepad didn't support anything but crlf at all 2022-02-10 18:50:00 fixedup via busybox-vi 2022-02-10 18:50:17 Nope, it does. That was like Windows 7 or before 2022-02-10 18:50:21 ah 2022-02-10 18:50:35 It just doesn't let you reformat a document once it recognizes it 2022-02-10 18:50:37 still confused why there was different lint stage outputs for the same error 2022-02-10 18:50:39 ah 2022-02-10 18:50:56 ACTION uploaded an image: (60KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/LNJrPVDNOkkNVUiSIOAvGfyo/image.png > 2022-02-10 18:51:12 ahh, i see 2022-02-10 18:51:15 so it does 2022-02-10 18:51:16 neat 2022-02-10 18:51:24 can someone please look at !30469 2022-02-10 18:52:10 what... is that font 2022-02-10 18:52:30 it's the font that only cute people can see 2022-02-10 18:52:58 also why are you editing APKBUILDs with notepad 2022-02-10 18:53:03 i have so many questions 2022-02-10 18:53:37 Ariadne: It's my handwriting. It helps me with reading comprehension to see things in my own handwriting (as awful as it may be) 2022-02-10 18:54:10 do you hold an m.d. by any chance 2022-02-10 18:54:13 As for why notepad, my build Alpine is WSL2 2022-02-10 18:54:41 I wish. Scientist? Does that count? 2022-02-10 18:54:47 maybe :p 2022-02-10 18:55:03 ah, its becoming clear now 2022-02-10 18:55:18 WSL2 is microsoft's plan to undermine linux by having people contribute patches using Notepad 2022-02-10 18:55:19 minimal: looks fine to me, though i can't merge it :) 2022-02-10 18:55:33 Ariadne: to be fair that should really be a lint check 2022-02-10 18:55:36 or a rejection.. or something 2022-02-10 18:55:37 -_- I'll keep using busybox-vi from now on 2022-02-10 18:57:04 psykose: yeah, the turn-around time for (some) MRs being merged is slow 2022-02-10 18:57:36 I thought waiting 5-6 days was sufficient before starting to "ping" about it 2022-02-10 18:58:26 thanks Ariadne 2022-02-10 18:58:37 minimal: its red 2022-02-10 18:58:39 minimal: configure: error: raw selected, but required raw.h header file not available 2022-02-10 18:58:45 damn that sure be building 2022-02-10 18:59:17 hm 2022-02-10 18:59:21 isn't that linux-headers 2022-02-10 19:00:10 --enable-raw needs to be removed 2022-02-10 19:00:23 Ariadne: eh? where's its "red"? don't see anything on build.alpinelinux.org 2022-02-10 19:00:36 actually not sure how this built on 3.15 2022-02-10 19:00:36 minimal: literally in #alpine-commits 2022-02-10 19:00:47 build.a.o also shows them failed 2022-02-10 19:00:58 Hello71: it built 5 days ago even 2022-02-10 19:01:07 ah, 3.15 is linux-lts 5.15 but linux-headers 5.10 2022-02-10 19:01:11 linux-headers was upgraded in that time, but idk why it would make this fail 2022-02-10 19:01:25 https://github.com/util-linux/util-linux/issues/1442 2022-02-10 19:01:34 ohh 2022-02-10 19:01:34 raw is gone 2022-02-10 19:01:51 hmm, it built fine previously 2022-02-10 19:01:56 yes 2022-02-10 19:02:02 headers were upgraded from 5.10 to 5.16 2022-02-10 19:02:03 although i didn't investigate why no more raw.h 2022-02-10 19:02:12 since the ci pass 2022-02-10 19:02:57 psykose: ah, ok that make sense 2022-02-10 19:13:40 What's the standard process to raise an MR for a package that already has an MR open? Raise my MR with "r" +1 from existing MR and assume mine will be merged after that? or raise with same "r" number knowing I will have to increment it if the other MR is merged? 2022-02-10 19:15:00 it will usually merge conflict if you raise it +1, and otherwise will be unbumped and need to be manually bumped again anyway 2022-02-10 19:15:14 just leave a comment 'depends xyz' and fix it after 2022-02-10 19:30:56 psykose: thanks 2022-02-11 07:12:48 o/ 2022-02-11 07:13:14 I'm wondering about how pkgusers/pkggroups can ensure a numeric id between where the package was built and where it is *installed* 2022-02-11 07:13:40 especially since the package itself install files using those appropriate permissions 2022-02-11 07:13:57 or I guess the best thing to do is probably to call chown at few places in pre-install script 2022-02-11 07:25:49 looks like no, abuild complains that chown is used in pre-install script 2022-02-11 07:36:01 markand: tar can map named users to the appropriate uid 2022-02-11 07:37:43 ah so it stores the named rather than the uid? 2022-02-11 07:37:47 good to know 2022-02-11 07:54:49 It stores both 2022-02-11 07:55:34 If falls back to the numeric uid if the user does not exist 2022-02-11 08:31:01 thanks ikke 2022-02-11 09:57:50 now util-linux-login conflict with acct over last 2022-02-11 10:01:33 I wonder why I have acct installed, though 2022-02-11 10:22:37 that was intentional, since the util-linux last version is more featureful 2022-02-11 10:35:32 sure, but should it be in acct then? 2022-02-11 10:36:27 yeah, similar to how there is shadow-login too 2022-02-11 10:36:32 hmm... I wonder about packages that depend on util-linux, that is empty and depend on nothing since v3.15 2022-02-11 10:36:53 yeah, think someone needs to update the dependents a bit 2022-02-11 10:42:21 markand: best policy is not to ensure any numeric id, always rely on the user/group name 2022-02-11 10:42:50 the few packages that have to encode uid/gid are usually pretty low level and that should be covered by the alpine-base /etc/passwd 2022-02-11 10:43:24 exceptions always exist I suppose 2022-02-11 11:01:08 #13512 2022-02-11 11:03:10 perhaps it should be "util-linux package" in the title, as aport refer also to sub-packages? 2022-02-11 11:06:24 fine as is 2022-02-11 11:07:30 changed it anyway =) 2022-02-11 11:15:12 so, iiuc, util-linux is now a package providing all its commands in subpackages, the main package itself being empty, and some subpackages can be replaced by alternatives? 2022-02-11 11:15:21 ye 2022-02-11 11:15:48 cool. util-linux is so much of a heterogenous kitchen sink that it's probably the sanest way of dealing with it. 2022-02-11 11:16:45 i prefer the homo kitchen sinks 2022-02-11 11:17:23 I *knew* you would say something of the sort 2022-02-11 11:18:07 you know me so well 2022-02-11 11:18:09 :p 2022-02-11 11:19:44 we're both terribly predictable 2022-02-11 11:21:33 ("awfully too predictable"? "terribly" seems to imply we're not predictable at all. English is hard.) 2022-02-11 11:32:26 !30742 !30743 2022-02-11 11:34:02 I might look at the others later too, but don't depend on it, this one I use myself 2022-02-11 18:52:10 psykose: impressive :) "11.7 GB psykose/aports" 2022-02-11 18:52:24 uhh 2022-02-11 18:52:34 aports build artifacts 2022-02-11 18:52:42 i assume that is not for me to clean 2022-02-11 18:52:45 Once in a while I do some extra cleanup 2022-02-11 18:52:46 or did i forget... 2022-02-11 18:52:48 ahh 2022-02-11 18:52:48 nope 2022-02-11 18:52:50 hehe 2022-02-11 18:52:51 yes 2022-02-11 18:52:55 Built a lot of Things it seems 2022-02-11 18:53:16 alpine/aports is 14G 2022-02-11 18:53:20 you were 2nd :) 2022-02-11 18:54:45 so close 2022-02-11 18:55:51 i guess i have to.. try harder.. 2022-02-12 07:39:41 Hi! I'm trying to fix !29274 for textrels, but I'm not sure how this should be fixed. Anyone a suggestion? 2022-02-12 11:17:41 tig 2022-02-12 11:17:44 heh 2022-02-12 11:20:34 irc cli :D 2022-02-12 19:23:22 could someone take a look at !30721? 2022-02-12 19:23:52 it's been merged while still a draft, so master has broken tests currently 2022-02-12 20:00:35 #13516 would've been a nice opportunity to learn someone how to package things 2022-02-12 20:02:03 maybe 2022-02-12 20:02:12 they can package the three missing dependencies :p 2022-02-12 21:03:32 How can I cross-compile aarch64 packages from x86-64? 2022-02-12 21:04:04 build a cross-compile toolchain 2022-02-12 21:04:05 depends on the language 2022-02-12 21:04:12 for the usual c stuff, you want a cross-toolchain 2022-02-12 21:04:39 note that we do very little cross-compiling for Alpine Linux 2022-02-12 21:04:40 then you can export the PATH to make it first, and it should just work i guess 2022-02-12 21:04:43 yep 2022-02-12 21:08:47 am i going down the wrong path with aposts/scripts/bootstrap.sh aarch64? 2022-02-12 21:08:57 aports, not aposts 2022-02-12 21:08:59 yes 2022-02-12 21:09:01 yes 2022-02-12 21:09:05 it's intended to bootstrap an arch 2022-02-12 21:09:06 (for emphasis) 2022-02-12 21:09:10 not to give you a toolchain to use 2022-02-12 21:09:11 whoops 2022-02-12 21:09:18 my advice: don't cross compile 2022-02-12 21:09:26 tarxvf: an option could be qemu-user 2022-02-12 21:09:28 set up a qemu vm of the arch, or some qemu-user thing 2022-02-12 21:09:39 it is 'slow', but it is at least 'correct' 2022-02-12 21:09:43 qemu bugs notwithstanding 2022-02-12 21:09:52 and less error-prone 2022-02-12 21:09:54 yep 2022-02-12 21:10:03 much appreciated, i'll switch to that 2022-02-12 21:10:41 there are languages that are 'easy' to cross compile, e.g. go without cgo 2022-02-12 21:10:44 but that's a little rare 2022-02-12 21:10:50 rust probably as well? 2022-02-12 21:10:58 hmm 2022-02-12 21:11:20 the time i added another target with rustup and used it it still wanted some cross-gcc on the host 2022-02-12 21:11:25 https://rust-lang.github.io/rustup/cross-compilation.html 2022-02-12 21:11:26 so i think it's limited to the usual toolchains 2022-02-12 21:11:30 ok 2022-02-12 21:11:37 with clang it's a lot easier 2022-02-12 21:11:45 since llvm will just have all the targets 2022-02-12 21:11:51 but still has the usual pains 2022-02-12 21:11:56 it's easier to just have some qemu thing 2022-02-12 21:12:27 yeah, on that rust page, it mentions still needing the other tools 2022-02-12 21:12:32 tarxvf, you can use the mini root from https://alpinelinux.org/downloads/ and chroot into that 2022-02-12 21:12:41 less heavy than a full vm and works just fine for building packages 2022-02-12 21:12:52 but not for cross-compilation 2022-02-12 21:12:58 a thing some people do is use zig as the cross-tool, but that works in the same way a fully set up clang does, since it's the same llvm magic 2022-02-12 21:13:12 But for qemu-user that should work 2022-02-12 21:14:24 also, alpine has qemu-binfmt installed by default 2022-02-12 21:14:37 but that needs to be restarted every time a qemu- package is installed 2022-02-12 21:15:06 i meant, qemu-binfmt is a part of the main qemu package, of course 2022-02-12 21:15:46 every time i read that name i think it's a binary formatter 2022-02-12 21:15:50 heh 2022-02-12 21:16:21 oh yeah, we have poetry in community now 2022-02-12 21:16:32 so hopefully we will have fewer python issues as more things drop etuptools 2022-02-12 21:17:18 our setuptools is still ancient 2022-02-12 21:17:25 i bumped it the other month 2022-02-12 21:17:26 to latest 2022-02-12 21:17:31 and in main/ all but one thing passed 2022-02-12 21:17:38 huh' 2022-02-12 21:17:39 of course that is only like 10% of the packages 2022-02-12 21:17:43 i mean locally 2022-02-12 21:17:46 just to see 2022-02-12 21:17:54 Every time I tried it produced a broken setuptools 2022-02-12 21:18:02 you sure? 2022-02-12 21:18:10 it kinda just worked, though they removed two of the things from it 2022-02-12 21:18:14 https://github.com/pypa/setuptools/issues/2550 2022-02-12 21:18:34 hmm 2022-02-12 21:18:34 KeyError: 'entry_points' 2022-02-12 21:19:05 when I tried to build other packages (though, I mostly concentrated on ipython, because that's why I needed a newer setuptools, because it appears the old one had a bug) 2022-02-12 21:19:23 But that specific error has been happening with other packages as well before 2022-02-12 21:19:34 i just bumped it to latest 2022-02-12 21:19:38 added py3-jaraco.text 2022-02-12 21:19:40 and it rebuilds fine 2022-02-12 21:19:44 can you try ipython? 2022-02-12 21:19:56 preferrably 8.0 2022-02-12 21:20:09 although, that needs new dependencies 2022-02-12 21:23:26 rebuilding ipython with latest setuptools works, same for 8.0, though strangely not in rootbld 2022-02-12 21:23:35 although the error is just some readme missing 2022-02-12 21:23:42 strange, but it's probably some random weird world dep 2022-02-12 21:23:54 psykose: that's the bug I ran into 2022-02-12 21:24:02 it has to do with case difference 2022-02-12 21:24:10 AssertionError: No files match pattern ipython/core/profile/README* 2022-02-12 21:24:11 IP 2022-02-12 21:24:12 yep 2022-02-12 21:24:32 so still happening with the latest version 2022-02-12 21:26:38 oh i'm a fool 2022-02-12 21:27:04 rootbld by default doesn't use local repos 2022-02-12 21:27:08 so it was using setuptools 52 2022-02-12 21:27:10 with 60 it works 2022-02-12 21:27:19 after adding localmain to .rootbld-repositories 2022-02-12 21:27:21 update - using multiarch/qemu-user-static and docker was able to build my packages by just switching docker base image. Thanks for the unstick! 2022-02-12 21:27:26 yeah, that's tricky with rootbld 2022-02-12 21:27:33 error is gone with the latest setuptools for sure 2022-02-12 21:27:34 tarxvf: nice 2022-02-12 21:27:45 psykose: nice, good to know 2022-02-12 21:28:10 But there are other packages broken with that version? 2022-02-12 21:28:33 needs more-itertools as well 2022-02-12 21:28:35 with 60.x? 2022-02-12 21:28:38 probably yes 2022-02-12 21:28:47 i saw at least one that still relied on the removed module 2022-02-12 21:29:12 in main/ 2022-02-12 21:29:25 and then there is community+testing where over 90% of the packages live 2022-02-12 21:29:32 ahuh 2022-02-12 21:29:34 let me try 2022-02-12 21:29:35 maybe the easiest path is to have a setuptools52 2022-02-12 21:29:55 but overall i expect maybe ~20-30 broken overall 2022-02-12 21:29:57 by a guess 2022-02-12 21:30:41 ptrc needed more python fun to do :) 2022-02-12 21:31:10 ACTION rolls eyes 2022-02-12 21:32:23 might be more interesting than #13508 though 2022-02-12 21:32:29 also regarding the wheel method 2022-02-12 21:32:35 ikke: i think most of them can be installed like this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30650/diffs#1287c3bfc7b847f96417c4dcc40458126dff2bc4_0_33 2022-02-12 21:32:46 and we don't need to actually add pip to install the wheels 2022-02-12 21:33:10 noooot entirely sure when this will break 2022-02-12 21:33:35 py3-build is nice for consistency, but it's really just calling the same tools under the hood and still building the same wheel 2022-02-12 21:34:11 ok, so manually unzipping the wheel 2022-02-12 21:34:12 judging by PEP427, it might be actually more complicated sometimes 2022-02-12 21:34:29 i don't doubt it 2022-02-12 21:34:29 sigh 2022-02-12 21:34:32 but they specify two different cases that... do exactly the same 2022-02-12 21:34:56 > If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages). 2022-02-12 21:34:56 > Else unpack archive into platlib (site-packages). 2022-02-12 21:35:52 platlib and purelib can have different paths 2022-02-12 21:35:55 but not in alpine 2022-02-12 21:36:07 bad example: https://stackoverflow.com/questions/10833962/in-python-when-is-platlib-purelib 2022-02-12 21:36:13 what is the difference between platlib and purelib? 2022-02-12 21:36:17 lol 2022-02-12 21:36:20 but we don't have multilib, so i'm not sure what a practical example would be 2022-02-12 21:36:32 for us this definitely doesn't apply 2022-02-12 21:36:49 we don't have a shared 'pure' noarch repo 2022-02-12 21:36:55 nod 2022-02-12 21:37:10 I don't think it makes a lot of sense to differentiate on alpine 2022-02-12 21:37:19 if noarch actually meant something, then we could have python configured to truly install the same package for everything noarch in a different place, from the one where we get cpython .so's 2022-02-12 21:37:34 but currently the .so path is the same as the .py file path 2022-02-12 21:37:47 and i guess that is what platlib is, the former 2022-02-12 21:37:58 hm, apparently there can be other fun quirks in wheels, such as "#!python" hashbang 2022-02-12 21:38:07 amazing 2022-02-12 21:38:23 which should be replaced by the installer with an actual python path 2022-02-12 21:38:51 but only if wheel has $pkgname-$pkgver.data/scripts directory 2022-02-12 21:39:07 which i personally have never seen in the wild 2022-02-12 21:43:08 "21:34 <@ikke> ok, so manually unzipping the wheel" i think this is what gentoo does now 2022-02-12 21:43:13 ok 2022-02-12 21:56:15 psykose: oh, I know what happened with that botched commit now :D 2022-02-12 21:56:31 I backgrounded vim 2022-02-12 21:56:42 with the commit messaget 2022-02-12 21:57:08 and then ~ 2022-02-12 21:57:51 commit --amend 2022-02-12 21:59:59 heh 2022-02-12 22:00:10 but why did that let you push the commit at all 2022-02-12 22:01:39 I rebased after 2022-02-12 22:01:59 which apparently didn't lead to a conflict 2022-02-12 22:15:55 ikke: i think now is the optimal time for icu 2022-02-12 22:15:58 and it has been long enough :p 2022-02-12 22:16:12 psykose: You know what I was just working on? 2022-02-12 22:16:20 ...icu? :p 2022-02-12 22:16:23 :) 2022-02-12 22:19:18 Xd 2022-02-12 22:19:46 Here goes nothing 2022-02-12 22:19:49 lesgo 2022-02-12 22:19:53 i am definitely drunk enough for this 2022-02-12 22:20:03 *fire detected* 2022-02-12 22:20:35 also i will probably merge the wasi-sdk llvm thing after for firefox 2022-02-12 22:21:00 Btw how os llvm13 coming along? 2022-02-12 22:21:10 it's done 2022-02-12 22:21:16 !30563 2022-02-12 22:21:22 let me know if anything jumps out in the file diff 2022-02-12 22:21:27 i use it locally and everything builds fine 2022-02-12 22:21:35 i tested at least asan on compiler-rt x86_64 2022-02-12 22:21:37 everything Looks ok 2022-02-12 22:21:39 and builds 2022-02-12 22:22:06 but i'm not exactly an llvm expert 2022-02-12 22:33:42 i don't understand why 10-add-musl-triples.patch is required. it seems like void has a similar patch, but isn't llvm supposed to support musl 2022-02-12 22:35:57 well the triples are not there in the part of the code it modifies 2022-02-12 22:36:01 not exactly sure honestly 2022-02-12 22:36:20 i /assume/ you need those -musl named triples since everything else (gcc, etc) has them 2022-02-12 22:36:37 although it's only for arm/x86 2022-02-12 22:42:28 that is the nature of clang being cross compiler by nature, and to get correct gcc toolchain (start, end, crt0 and whatnot) from gcc directory, it needs to know the triple where they are 2022-02-12 22:43:04 if you want to do llvm only toolchain, you don't need that musl to be there 2022-02-12 22:45:09 but that does quite lot of work, since first you build compiler-rt builtins, then you start adding runtimes 2022-02-12 22:47:06 because that llvm package is default targeted with libgcc stuff and libstdc++ rather than compiler-rt and libc++, triples are needed (as said, to find gcc toolchain stuff) 2022-02-12 22:49:09 I have done some toolchain building stuff myself, targeting alpine and with standalone llvm toolchain, but having that target triple patch there because wanting to have possibility to build with --rtlib=libgcc --stdlib=libstdc++ 2022-02-12 22:50:29 I've said this before, I have dream of alpine that has llvm toolchain as the default (freebsd style!) 2022-02-12 22:53:30 clang has option for --gcc-toolchain so it would be able to kick in the build without gcc kind of triples, but haven't yet tried to use it with builtins/runtimes with llvm toolchain 2022-02-12 22:55:31 preferred thing by llvm viewpoint is to do at least 2-stage build of the toolchain. first you build clang and ld.lld and runtimes for the build machine, targeting only the host arch, then start building the whole toolchain with desired target archs and then add builtins and runtimes as desired 2022-02-12 22:56:06 check out PHosek's cmake caches from llvm-project/clang/cmake/caches/Fuchsia.cmake (and corresponding -stage2.cmake) 2022-02-12 22:57:07 thing here is, that alpine builds things separately, not with monorepo as the llvm is preferred to be built 2022-02-12 23:03:14 ACTION has ended monologue 2022-02-12 23:16:17 i think the tarballs are still build monorepo style, each of the segments pull in the llvm tree as well 2022-02-12 23:16:28 though only the resulting segment is packaged, instead of everything-in-one-build 2022-02-12 23:16:45 i didn't really check that part 2022-02-12 23:16:57 aside from that, yes, i guess that makes sense 2022-02-12 23:17:03 since it does depend on the gcc things 2022-02-12 23:17:23 long-term there is still a 'potential' to move to clang as the base compiler, eventually 2022-02-12 23:17:26 not any time soon 2022-02-12 23:17:51 since you've worked with it more than me, do you see anything wrong with the llvm13 toolchain upgrade in the mr above 2022-02-12 23:18:02 if at least like 2 people seem to find it ok i will consider it ready :) 2022-02-12 23:18:08 it's just a little outside my wheelhouse 2022-02-12 23:25:18 I'll check it 2022-02-12 23:25:41 comments and stuff might be tomorrow, red wine is kicking in =) 2022-02-12 23:27:58 new mutt version released 2022-02-12 23:28:39 maintainer is apparently stopping (except for bug + security fixes) 2022-02-12 23:29:14 it's been a long run, hasn't it 2022-02-12 23:52:57 damn 2022-02-12 23:54:11 just when I was thinking about going into terminal mail reader back again 2022-02-12 23:55:55 well, that is the thing when dropping usage for few years, it will die 2022-02-12 23:59:41 psykose: btw, one build machine detection patches I've done is wget -O llvm-project/llvm/cmake/config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' 2022-02-13 00:00:15 not sure which part of the apkbuild you are referring to there 2022-02-13 00:00:50 it is generally, to give whole llvm build to detect build triple 2022-02-13 00:01:00 for the build machine 2022-02-13 00:01:19 it already does though 2022-02-13 00:01:29 alpine (the mail reader) is still kicking 2022-02-13 00:02:00 sure it does, but for default target triple, it is convenient 2022-02-13 00:02:34 the default triple is intentionally set to $CBUILD in case it is cross compiled 2022-02-13 00:02:41 although i'm not sure why it is not called ctarget 2022-02-13 00:02:47 the guess doesn't help there 2022-02-13 00:03:27 I just leave that page open for tomorrow when I'm back sober =) 2022-02-13 00:03:54 i can barely sit upright 2022-02-13 00:04:16 Ariadne: oh.. never used. 2022-02-13 00:04:51 Ariadne: pine gone more towards mutt or what? 2022-02-13 00:05:44 pine with apache license 2022-02-13 00:54:14 psykose: Hello71: Thanks for applying the qemu patch! It works now! 2022-02-13 00:54:35 glad to be of service 2022-02-13 01:11:09 psykose: The funny thing is, when I was testing the osu!lazer flatpak on Ubuntu, it had a dotnet error like in https://github.com/dotnet/runtime/issues/47280, but on Alpine running the flatpak through qemu works (but it's waaayyy too slow to play) 2022-02-13 01:11:43 mhm 2022-02-13 01:11:47 sounds about right 2022-02-13 01:11:59 about the speed or the error? 2022-02-13 01:12:24 speed 2022-02-13 01:12:51 yea kinda what I expected just wanted to try 2022-02-13 01:13:42 What's quite interesting is that the flatpak multiarch feature isn't widely advertised anywhere, there's only one reddit post and a GH issue by the same user 2022-02-13 01:14:06 It's actually very useful because all the deps are in one package 2022-02-13 01:14:29 for the most part nobody really ever needs cross-arch things 2022-02-13 01:14:54 this arm64->x86_64 thing is the sole exception, and also quite recent, as the m1 is the only really usable desktop platform that even exists on a wide scale 2022-02-13 01:15:06 hmm true 2022-02-13 01:15:21 for anything else.. i mean, sometimes it's cool, but nobody runs into it except developers doing weird things 2022-02-13 01:15:27 and we are a massive minority 2022-02-13 01:16:32 (emulation of consoles/game stuff aside, of course, but that is entirely separate) 2022-02-13 01:30:10 psykose: Yea and that's emulating 6502 era processors that ran at around 1 MHz 2022-02-13 03:26:42 hi everyone! i have a few aports MRs that havent had any activity in over a month and have been marked stale. the MRs are !28705, !29261, and !29369. is this normal? thanks 2022-02-13 03:27:25 yes, i have complained for some time about the bot 2022-02-13 03:29:16 hm, thats a bit annoying lol. should i just wait it out or is there something i can/should do? 2022-02-13 03:30:01 it's strange because i have other patches that were merged (or closed) very quickly, and i cant figure out why some are handled quickly and others are seemingly ignored 2022-02-13 15:21:36 Hi! Does anybody have a suggestion on how to best deal with a test timeout? I am seeing the problem in !30754. The test has two 20.5s sleeps and a 50s timeout. So armhf builder seems to be too slow to finish on time. 2022-02-13 15:24:28 patch the timeout and increase it :p 2022-02-13 15:26:37 Ok, so that is ok to do in Alpine? 2022-02-13 15:27:03 maybe 2022-02-13 15:27:08 i have committed it at least once 2022-02-13 15:27:56 that timeout seems low tbf especially when it requires the sleep 2022-02-13 15:29:40 I mean, the test does not do much otherwise and all other builders pass. Otherwise I'd definitely ping upstream 2022-02-13 15:31:04 I would test it out with a patch in Alpine and then submit a patch upstream. 2022-02-13 15:31:04 This way you have some 'prove' that 50s is too short 2022-02-13 15:35:00 Makes sense :) 2022-02-13 16:04:56 Patch to use 60 instead of 50 seconds works. I'll also carry it upstream, thanks for the comments! 2022-02-13 16:56:58 Goging to upgrade the gitlab host within 5 minutes, it will be unavailable for a bit 2022-02-13 16:57:37 f, all repos deleted forever 2022-02-13 17:05:31 gitlab is back 2022-02-13 17:09:05 oh it cancelled ci 2022-02-13 17:09:05 wa 2022-02-13 17:09:13 did it? 2022-02-13 17:09:19 Usually it continues 2022-02-13 17:09:35 says canceled in the log 2022-02-13 17:09:41 that's alright 2022-02-13 17:09:45 waiting for qtwebengine anyway 2022-02-13 17:09:52 just wanted to make sure firefox failed to build on ppc 2022-02-13 17:10:04 last little thing and then i will upgrade it to 97 2022-02-13 17:14:25 k 2022-02-13 19:21:55 is there a possibility that alpine would get a package like python-is-python3 in debian? 2022-02-13 19:22:27 asking because there's yet another package that assumes "python" actually is python3 in their tests 2022-02-13 19:22:53 that's a broken package then 2022-02-13 19:23:00 it's as simple as adding the symlink in python 2022-02-13 19:23:06 and i would guess it should be fine 2022-02-13 19:23:14 We had that at some point, but reverted 2022-02-13 19:23:18 we have like 2022-02-13 19:23:22 5 things depending on python2 2022-02-13 19:23:34 but they are easy to remove, i've been planning to do that actually, and to remove py2 entirely 2022-02-13 19:23:39 Habbie: yeah, i know; i intend to patch that so the tests actually pass 2022-02-13 19:23:40 (that is, python linking to pyton3 2022-02-13 19:23:42 ) 2022-02-13 19:23:54 for tests you can make a uhh 2022-02-13 19:23:57 venv 2022-02-13 19:23:59 psykose: even things like chromium? 2022-02-13 19:24:02 ln -s /usr/bin/python3 something/bin/python 2022-02-13 19:24:07 and export path 2022-02-13 19:24:08 or that 2022-02-13 19:24:12 ikke: chromium doesn't use it 2022-02-13 19:24:13 (which basically is what a venv does) 2022-02-13 19:24:16 yeah, i'll probably just make a symlink in builddir i guess 2022-02-13 19:24:28 I thought the build system used python2 2022-02-13 19:24:31 not anymore 2022-02-13 19:24:33 ah ok 2022-02-13 19:24:34 the apkbuild is py3 only 2022-02-13 19:24:44 Then that changed recently I gues 2022-02-13 19:24:46 guess 2022-02-13 19:24:47 the things that need py2 are uhh 2022-02-13 19:24:49 py2 itself 2022-02-13 19:24:51 py2-setuptools 2022-02-13 19:24:54 and literally 2 packages 2022-02-13 19:25:03 or something 2022-02-13 19:25:04 in a chain 2022-02-13 19:25:13 and the next release of that package will drop py2 2022-02-13 19:25:18 there was pypy, which either needs python2 or itself I beleive 2022-02-13 19:25:20 beleive 2022-02-13 19:25:23 Sorry, cannot type 2022-02-13 19:25:35 ikke: not chromium, but qt6-qtwebengine apparently 2022-02-13 19:25:48 mm 2022-02-13 19:25:55 at least it has py2 in makedepends, not sure if it's really used 2022-02-13 19:26:01 `pypy` is py2.7-pypy, but it does not need python2 2022-02-13 19:26:16 we can also probably just drop it as we have pypy3, though i think it hasn't been upgraded in a while 2022-02-13 19:26:18 Yeah, I think the author changed it 2022-02-13 19:26:18 it's testing anyway 2022-02-13 19:26:29 It was first built with python2 2022-02-13 19:26:31 yep 2022-02-13 19:27:11 there's some py2 flask stuff in non-free btw 2022-02-13 19:27:14 ah right, both webengines need it 2022-02-13 19:27:26 that is a little harder to get rid of 2022-02-13 19:27:29 not used in other packages, just sitting there 2022-02-13 19:27:34 but i wonder how likely it is a sed works 2022-02-13 19:37:18 ptrc doesnt qt6-webengine nede it due to chromium 2022-02-13 19:37:32 since they r still porting tests for chromium to py3 2022-02-13 19:37:36 as mentioned above, chromium doesn't need it anymore 2022-02-13 19:38:02 but they might be a version or more behind 2022-02-13 19:47:00 the build tags a specific chromium 2022-02-13 19:47:41 it says 87-branch 2022-02-13 19:47:54 for qt5 2022-02-13 19:47:58 qt6 is part of the tarball, no idea 2022-02-13 19:48:01 i think 87 was still py2 2022-02-13 20:16:00 psykose: pypy3 needs pypy (which is fully support) which needs pypy (or python2 for bootstrapping) 2022-02-13 20:16:15 ah, i see 2022-02-13 20:16:37 is there no py3->pypy3 bootstrap 2022-02-13 20:17:00 !26176 is pending to add pypy-bootstrap building a local python2 2022-02-13 20:18:52 so it's impossible to build pypy3 without having some form of py2 before it? 2022-02-13 20:18:56 pypy* depends on rpython which requires py2 - so there is no bootstrapping from py3 2022-02-13 20:19:01 rip 2022-02-13 20:20:17 this is why I created the pypy-bootstrap MR so there is no depend on cpython2 ;-) 2022-02-13 20:20:22 makes sense 2022-02-13 20:20:30 well, if you get it to build i'll see how it goes 2022-02-13 20:21:10 though is there anything using `pypy` anymore, or does it make more sense to have a pypy3-stage0 creating this py2-pypy to then build pypy3 with 2022-02-13 20:21:50 the newer preferred bootstrap path is to name these -stage0 instead, but here pypy and pypy3 are separate targets post-bootstrap 2022-02-13 20:22:06 -stage0 should be stand-alone though 2022-02-13 20:22:17 not depending on itself 2022-02-13 20:22:54 it doesn't sound like it would be depending on itself 2022-02-13 20:22:55 which means it would probably need to use something pre-built 2022-02-13 20:23:02 ah 2022-02-13 20:23:13 for pypy2 it would 2022-02-13 20:23:50 pypy is (instead of cpython2) fully supported so I would leave it available... and building new pypy3 releases from scratch (cpython2+pypy intermediate steps) would take days to compile 2022-02-13 20:24:22 I don't see an issue of pypy3 depending on pypy2 2022-02-13 20:25:44 liske: how would you bootstrap pypy2 if python2 is no longer available and it would not depend on itself 2022-02-13 20:27:34 The idea is that instead of having an opaque bootstrap path 2022-02-13 20:27:52 like, someone building it from a pre-compiled binary into a package, which then forever depends on itself 2022-02-13 20:28:19 have it transparent by using that path every time. -stage0 would then represent the pre-compiled version 2022-02-13 20:34:12 Isn't it what !2176 already does (although it should be renamed to -stage0)? 2022-02-13 20:34:30 wrong mr? 2022-02-13 20:34:50 s/!2176/!26176/ 2022-02-13 20:34:50 liske meant to say: Isn't it what !26176 already does (although it should be renamed to -stage0)? 2022-02-13 20:35:10 (sorry for spam :-O) 2022-02-13 20:35:16 it does seem that way 2022-02-13 20:35:34 it's not a precompiled blob, but it gets bootstrapped by gcc and some makedeps 2022-02-13 20:35:37 not very opaque 2022-02-13 20:36:32 So you basically first build python2 to then build pypy2, right? 2022-02-13 20:36:39 yes 2022-02-13 20:36:48 Yeah, that could work 2022-02-13 20:37:15 and won't rely on global py2 either 2022-02-13 20:37:16 I've merged the needed parts of python2's APKBUILD into it 2022-02-13 20:37:31 then we just have to figure out the qtwebengine mess 2022-02-13 20:37:59 and by 'figure out' i mean not do anything about for the next 3 years, inevitably 2022-02-13 20:38:16 sounds about right 2022-02-13 20:40:11 Hope upstream will solve it 2022-02-13 20:41:28 Is upstream qt5 even getting anything more than security releases and stuff at this point? 2022-02-13 20:41:33 nope 2022-02-13 20:42:05 Sounds about right. py3-pyside2 has some pretty massive compatibility problems with python 3.10 that just aren’t getting fixed. 2022-02-13 20:42:34 So I suppose !29979 is now superseded? 2022-02-13 20:43:04 what by 2022-02-13 20:43:23 community/firefox: upgrade to 97.0 | http://dup.pw/alpine/aports/27dd3d03e1fb 2022-02-13 20:43:31 well those are separate things 2022-02-13 20:43:40 i would be upgrading it in testing too :p 2022-02-13 20:43:51 it's just not possible to update in stable 2022-02-13 20:43:57 we can't bump icu/nss in 3.15-stable 2022-02-13 20:44:21 -esr doesn't have these issues 2022-02-13 20:44:59 the only reasonable way to upgrade firefox in stable is to drop --system-nss/icuy 2022-02-13 20:45:11 and have it statically link a vendored copy 2022-02-13 20:45:19 why can't we bump nss 2022-02-13 20:45:27 uhh nss we probably can, my mistake 2022-02-13 20:45:34 it is abi safe right 2022-02-13 20:45:41 well it doesn't bump soname 2022-02-13 20:45:50 heh 2022-02-13 20:45:59 why do they even make the .so.nssver links 2022-02-13 20:49:37 dunno. maybe windows related 2022-02-13 20:50:01 so you think this is completely safe !30881 2022-02-13 20:53:17 ikke: I've updated the MR and renamed it to pypy-stage0 and adding the provides variables 2022-02-14 01:39:26 is no one actively maintaining the openscad package? it's a year behind current version 2022-02-14 01:44:40 maribu is listed as the current maintainer and he is pretty active in the project. 2022-02-14 01:45:12 You can send a MR to upgrade it if you want to. 2022-02-14 09:22:07 hello fellow alpine-rs 2022-02-14 09:22:25 I have a question about the Alpine init script 2022-02-14 09:23:22 I have modified it to boot entirely from network using a network block device (AoE and /or iscsi) 2022-02-14 09:23:25 it works 2022-02-14 09:26:48 (sorry got disconnected) 2022-02-14 09:27:28 As I said I have a little question regarding the init script (/usr/share/mkinitfs/initramfs-init) 2022-02-14 09:27:52 how can I make a check against the UUID that is passed in the kernel command line ? 2022-02-14 09:28:38 i.e. "BOOT_IMAGE=/boot/vmlinuz-lts root=UUID=2e73df2a-cd3d-4cce-94ac-1f9411108d62 modules=aoe,sd-mod,usb-storage,f2fs quiet" 2022-02-14 09:28:59 where is this UUID value stored in the script ? 2022-02-14 09:30:30 I need to do a simple while loop against the presence of this UUID in the system before /sysroot gets mounted 2022-02-14 09:30:49 for booting with iscsi/aoe from a network block device 2022-02-14 09:31:54 I've already made one that checks against the presence of the /dev iscsi/aoe block device 2022-02-14 09:32:24 but it's more safe to check against an UUID (to be 100% sure the disk is the right one) 2022-02-14 09:38:59 wouldnt it be $kopt_root 2022-02-14 09:39:02 or whatever 2022-02-14 09:45:49 Ariadne: tried it, but it returns an empty string 2022-02-14 09:48:23 will check it again 2022-02-14 09:49:55 ..and it was there 2022-02-14 09:50:16 $KOPT_root 2022-02-14 09:50:24 many thanks 2022-02-14 09:56:43 anyone knows where the UUID is stored in the kernel when the block device is ready/loaded ? 2022-02-14 09:57:01 is it a file ? 2022-02-14 09:57:39 do I have to check mdev/udev ? 2022-02-14 10:02:45 /dev/disk/by-id/... 2022-02-14 10:04:57 is it populated during boot ? I thought it was an udev-only feature,not mdev 2022-02-14 10:05:35 hmm good point 2022-02-14 10:05:44 in initramfs, there is nlplug-findfs 2022-02-14 10:21:31 notice: I am upgrading listserv.alpinelinux.org to 3.15, there will be a brief outage 2022-02-14 10:29:40 retract last 2022-02-14 10:33:10 Can somebody have a look at !29955 to make sure this is the right approach since BlueZ cannot depend on evolution-data-server? Thanks! 2022-02-14 11:26:57 Hello, I am trying to build a system that supports airgapped installations, with a limited repository for both x86_64 and arm. Hence I am not willing to clone everything. 2022-02-14 11:27:33 Now what I have build, basically works. I can have a local cache, it symlinks the packages in the cache, and a normal http server can do its job. 2022-02-14 11:28:25 But ideally I would like to make a single repository, for the main reason that the code that would allow multiple repositories from the kernel cmdline is not merged yet. 2022-02-14 11:29:53 Is there any current best practice to "fork" a repository including dependency tracking? I don't mind to get my hands dirty, but if there is existing code that could pick package a, b, c including all its dependencies and write out a APKINDEX that would obviously be preferred. Not here to invent the wheel. 2022-02-14 11:30:48 skinkie: I think the closest to what you want is using ap from lua-aports 2022-02-14 11:31:05 It does need to run in the aports repo 2022-02-14 11:32:05 hi 2022-02-14 11:32:08 i have code that does this 2022-02-14 11:35:13 skinkie: https://tpaste.us/Pr6y 2022-02-14 11:35:38 algitbot: shutup :P 2022-02-14 11:36:32 skinkie: use with a file like https://tpaste.us/6WN8 2022-02-14 11:43:31 Ariadne: thanks! going to give it a shot. 2022-02-14 11:43:45 im sure you'll be able to figure it out 2022-02-14 11:44:02 anyway that script lets you compose a new repo from alpine repos 2022-02-14 11:44:07 Ariadne: doe is do any dependency tracking, or does fetch take care of that? 2022-02-14 11:44:14 fetch does the dep tracking 2022-02-14 11:47:09 Ariadne: license of this code is "permissive"? 2022-02-14 11:58:34 skinkie: MIT 2022-02-14 12:04:10 Ariadne: works for me, I gladly give credit where credit is due. 2022-02-14 12:06:32 /dev/disk/by-id is for udev's somewhat vaguely defined "fixed hardware id". uuids are in /dev/disk/by-uuid 2022-02-14 12:15:25 Ariadne: what should be in 'name.repo'? 2022-02-14 12:15:58 that’s just an /etc/apk/repositories type file 2022-02-14 12:21:17 Hello71: /dev/disk/by-uuid is not present in a default/pristine Alpine environment, in initramfs, ad Ariadne pointed out, there is a specific binary for the job, nlplug-findfs 2022-02-14 12:21:23 yes 2022-02-14 12:21:40 I worked around the problem with a hacky "sleep" loop 2022-02-14 12:21:52 that waits for the eth device to be up 2022-02-14 12:21:58 findfs already does this finding task. nlplug-findfs does the waiting 2022-02-14 12:22:24 it's working fine for 3/4 machines I have around 2022-02-14 12:22:31 but it's sub-optimal 2022-02-14 12:23:26 I'll try now with a findfs loop 2022-02-14 14:29:05 can someone please merge !30887 and !30885 2022-02-14 15:19:14 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12327#note_215290 huh? 2022-02-14 15:20:01 we don't support mips anymore 2022-02-14 15:20:03 unless i missed something 2022-02-14 15:22:07 I've finally sorted it out 2022-02-14 15:24:33 I've solved it with a stanza something like while [[ ! $(findfs $KOPT_root) ]] ; do ; done 2022-02-14 15:25:13 now it finally boots from lan as intended 2022-02-14 15:27:45 psykose: ah, i misread it 2022-02-14 15:28:00 mips is gone! save your souls! 2022-02-14 15:28:19 wyk72: so you have rewritten nlplug-findfs but worse? 2022-02-14 15:29:00 Hello71: Oh i modified absolutely nothing 2022-02-14 15:29:33 Hello71: just added a little stanza to the init script 2022-02-14 15:32:54 Hello71: that load the needed modules, turns on eth interface (i..e. ) , and loops until findfs spews out the right device, from the UUID you pass in the kernel line (root=UUID=xxxxxxxxxx) 2022-02-14 15:35:50 wyk72: there's existing functionality in initramfs-init for using network, couldn't you adapt that rather than write similar/duplicate code? 2022-02-14 15:37:04 I think it's a nice addition to the boot options of Alpine: NBD was supported, but it's not my favorite solution (it speaks TCP like iSCSI), AoE is my favorite because it "lives" in L2 ethernet, so no IP, no DHCP, much faster. 2022-02-14 15:38:08 minimal: the only block device I've seen suitable in standard Alpine was NBD: not my favorite meal 2022-02-14 15:38:35 minimal: I used as much as the code present in the init scritpt as possible 2022-02-14 15:39:21 wyk72: I was referring to the configure_ip function in initramfs-init 2022-02-14 15:40:09 minimal: yup I've used the ip_choose_if helper from it 2022-02-14 15:40:46 minimal: but DHCP was not needed, I just wanted eth to be up 2022-02-14 15:41:19 minimal: since I don't need any IP nor DHCP 2022-02-14 15:42:20 minimal: the mods are really .... minimal (little pun intended), 4 lines maybe 2022-02-14 15:47:10 the only problem is that with "network" added to mkinitfs.conf features, the initramfs becomes fat 2022-02-14 15:47:24 well, chubby 2022-02-14 15:47:54 wky72: you can of course tweak/tailor your mkinitfs feature files, its what I do to make them as optimal as possible 2022-02-14 15:48:46 however doing so might cause future pain if you're not possible however (mkinitfs upgrades not adding necessary changes to your modified files) 2022-02-14 15:48:58 s/possible/careful/ 2022-02-14 15:48:58 minimal meant to say: however doing so might cause future pain if you're not careful however (mkinitfs upgrades not adding necessary changes to your modified files) 2022-02-14 15:51:34 seems since a few days that apk in alpine 3.12 and older can not parse this file anymore http://nl.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz 2022-02-14 15:51:51 just get "ERROR: FDB format error (line 34296)" 2022-02-14 15:54:34 minimal: oh I agree, network booting is almost always a pile of troubles , with ethernet cards full of quirks, switches too, iPXE w/UEFI being a ... random roulette 2022-02-14 15:57:14 wyk72: I was referring to things like the Alpine 3.15 change to compressed kernel modules which could have potentially caused problems with modified mkinitfs feature files 2022-02-14 15:58:09 minimal: I see: what can cause problems ? 2022-02-14 15:59:00 minimal: I added aoe.modules & aoe.files in the features of mkinitfs, with the proper aoe modules & the relative /usr/sbin/aoe-discover files 2022-02-14 15:59:53 minimal: setting a new option "aoe" in the /etc/mkinitfs.conf file 2022-02-14 16:00:38 minila: that's about it 2022-02-14 16:01:05 wyk72: pre Alpine 3.15 the /etc/mkinitfs/features.d/*.modules files referred to the likes of "abc.ko", from 3.15 onwards they have the likes of "abc.ko*" as the module filenames themselves changed to either *.ko.zstd or *.ko.gz - if you upgraded to a new version of mkinitfs and a new version of the kernel then the mkinitfs trigger would rebuild/replace your initramfs file but would fail to include the compressed kernel module files so 2022-02-14 16:01:05 potentially resulting in an unbootable system 2022-02-14 16:02:14 minimal: Oh I see 2022-02-14 16:02:23 minimal: I did not know that 2022-02-14 16:03:45 minimal: let me check the features.d dir, I use the latest 3.15 (kernel 5.15.16-lts) 2022-02-14 16:05:15 minimal: if it's a small wildcard (*) it's no biggie 2022-02-14 16:07:49 the aoe driver reads aoe.ko.gz 2022-02-14 16:08:36 its no biggie if you have the wildcard, a biggie if you don't have it 2022-02-14 16:09:48 minimal: oh and btw, the system is UN-bootable by definition with standard tools, since GRUB does not understand AoE devices and does not have an AoE module in it 2022-02-14 16:10:40 minimal: I boot it with a "direct" kernel encapsulated into gummiboot for EFI booting 2022-02-14 16:11:45 minimal: using the linuxx64.efi.stub I mean 2022-02-14 16:13:17 minimal: it's the only option available (not even a swiss knife like refind has a solution for it) , and a better/faster one if you ask me 2022-02-14 16:18:18 wyk72: if all you need to do is wait for an eth interface to be up, you may be interested in https://skarnet.org/software/bcnm/bcnm-waitif.html 2022-02-14 16:18:28 (not packaged by Alpine atm, but I can package it if there's demand) 2022-02-14 16:21:26 skarnet: thanks I solved it all into init with no additional software, using (busybox?) findfs command + the ancient ifconfig 2022-02-14 16:28:00 btw,"legacy" booting (no UEFI) is way faster 2022-02-14 16:28:08 with iPXE 2022-02-14 16:28:23 but BIOS-PC it looks ancient 2022-02-14 16:29:45 UEFI iPXE takes about 6 more seconds to boot (depends on hardware) 2022-02-14 16:42:15 wyk72: UEFI also defines HTTP boot support although I think support for it is optional 2022-02-14 16:50:01 minimal: yes, it indeed does, on "newer" machines (post 2018/2019, maybe) there's the option in the BIOS itself 2022-02-14 16:50:41 minimal: using rEfind you can actually do a lot of fancy stuff too, 2022-02-14 16:51:26 minimal: but I have a bunch of old i5 machines (Optiplex 7010, Fujitsu E520 etc) that only do basic UEFI/pXE boot 2022-02-14 16:52:14 minimal: and for those I had to compile the UEFI iPXE with the sanboot pxe script 2022-02-14 16:54:49 minimal: http boot makes things much, much simpler: you just point it to the gummiboot/stub kernel (w proper initramfs) and voilà 2022-02-14 17:07:01 psykose: thanks for comment but before bumping pkgrel, do you know what could be happening here? http://ix.io/3PBT 2022-02-14 17:07:11 it's running 'abuild rootbld' 2022-02-14 17:07:30 ERROR: busybox-1.35.0-r2.post-install: script exited with error 127 2022-02-14 17:07:56 are you building on some weird -ro filesystem or through qemu or some shit 2022-02-14 17:08:25 uhM, maybe it's due noexec 2022-02-14 17:08:59 oh yes, it works now 2022-02-14 17:09:11 thanks! 2022-02-14 17:09:16 or that 2022-02-14 17:09:17 yep 2022-02-14 17:52:24 Is anyone here cable of actually building alpine-ipxe from aports. After removing the tests folder, which breaks, I am now finding a missing .certificate.pem.1. 2022-02-14 17:57:03 skinkie: as you can see from here: https://pkgs.alpinelinux.org/packages?name=alpine-ipxe&branch=edge it was last built on Edge apparently on November 2020 2022-02-14 18:06:48 Ariadne: evening 2022-02-14 18:07:05 aparcar: hey, i'm in a meeting atm 2022-02-14 18:08:08 Ariadne: all right, I'll write you later 2022-02-14 18:08:27 feel free to PM me anytime, i just might be delayed if i have to say something :P 2022-02-14 18:08:40 minimal: that is quite some time ago ;) 2022-02-14 18:11:51 the same date for Alpine 3.15.0. I'm confused, I thought all packages were build for a release 2022-02-14 18:15:11 minimal: but not for edge 2022-02-14 18:15:34 it has a 2020 build date on 3.15 2022-02-14 18:15:48 ikke: yes, but the 3.15.0 also has the same Nov 2020 date 2022-02-14 18:15:57 and 3.14 2022-02-14 18:16:03 and so on :) 2022-02-14 18:20:29 huh, su - starts asking for a password as root 2022-02-14 18:20:47 but not without the - ? 2022-02-14 18:21:03 correct 2022-02-14 18:21:20 does it work with the password 2022-02-14 18:21:29 I can just press enter to continue 2022-02-14 18:21:41 is the password empty? 2022-02-14 18:22:18 apparently something is set 2022-02-14 18:27:39 minimal: psykose not sure why the build date shows 2020. The buildlog from the builder: 2022-02-14 18:27:41 >>> alpine-ipxe: Building main/alpine-ipxe 1.20.1-r1 (using abuild 3.9.0_rc2-r1) started Sat, 16 Oct 2021 19:10:09 +0000 2022-02-14 18:28:15 i mean the build log on pkgs.a.o doesn't even resolve 2022-02-14 18:28:20 maybe it forgot to update 2022-02-14 18:28:44 We moved things around a bit, I guess not everything was synced to the new host 2022-02-14 18:29:56 ikke: is that buildlog available on a URL somewhere? wants to compare with a failing local buildlog 2022-02-14 18:30:30 minimal: Not yet, but I'll sync it later 2022-02-14 18:30:48 Well, I can make this one available now 2022-02-14 18:30:59 https://tpaste.us/REmW 2022-02-14 18:55:58 ikke: thanks. So many diffs between that log and a current local build that they're really not comparable. Wondering if compiler changes (i.e. gcc 10 -> 11) could be the trigger 2022-02-14 18:58:59 skinkie: modifying the APKBUILD to add "-Wno-error=maybe-uninitialized" to the EXTRA_CFLAGS definition lets the package build as it changes the error to a warning 2022-02-14 19:03:16 is it possible to download an APK index and extend it without having _all_ packages of the index locally present? 2022-02-14 19:25:13 aparcar: I assume you mean apkv3? 2022-02-14 19:26:08 aparcar: at least with v2, apk index has a -x option where you can specify an existing index 2022-02-14 19:35:27 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/38 thumb up count too? ;) 2022-02-14 19:36:17 nope 2022-02-14 19:36:24 suck :\ 2022-02-14 19:36:34 tsc only :) 2022-02-14 19:37:07 :> 2022-02-14 19:37:35 aparcar: today I received a script doing so ;) 2022-02-14 19:37:45 minimal: how do you handle the certificate error then? 2022-02-14 19:37:58 minimal: make[1]: *** No rule to make target 'bin/.certificate.pem.1', needed by 'bin/certstore.o'. Stop. 2022-02-14 19:47:36 minimal: you can get beyond that error by removing the certificate things from the file. But then you will end up in yet another error lzma.h missing. So fixing that. 2022-02-14 19:47:48 since someone else brought it up, i'd like to say that i dislike this process. i dislike the idea of being rejected in a secret committee meeting, with no reason provided and no steps to remedy it. or, supposing i am accepted, how should i explain to prospective developers how to become accepted themselves? important decisions should be made *more* publicly, not less. 2022-02-14 19:48:29 i'm saying this in advance so that nobody claims that i am merely "salty", as the kids would say 2022-02-14 19:48:49 why would you be rejected 2022-02-14 19:50:29 i am not sure why the reason would not be provided 2022-02-14 19:50:40 could you point to an instance of someone being rejected with no reason 2022-02-14 19:51:27 more publicity is fine by me, though i would not call the current system a 'secret committee meeting' 2022-02-14 19:51:32 the notes and resolutions are published 2022-02-14 19:51:36 ACTION thought that is public enough if the "issue" is there or Ariadne was too excited when was opening it ;) 2022-02-14 19:51:38 all that would be missing is the literal recording 2022-02-14 19:52:10 we do not record the meetings because sensitive information may be discussed 2022-02-14 19:52:15 yes 2022-02-14 19:52:25 skinkie: didn't see either of those errors 2022-02-14 19:52:29 and i am curious what is exactly missing afterwards, because i can't think of anything 2022-02-14 19:53:12 however, giving people effective root access to millions of systems is something that does need to be discussed by something 2022-02-14 19:54:52 ACTION starts planning his infiltration of the TSC 2022-02-14 19:55:09 ah, so that's how you plan to move to s6 2022-02-14 19:55:31 minimal: I was also missing 'bash' so I think what this package needs is better dependencies. 2022-02-14 19:56:22 skinkie: yeah, plus its behind the current upstream release 2022-02-14 19:56:35 current release doesn't need the gcc patch 2022-02-14 19:57:01 minimal: I have also created the patch for the atom stuff 2022-02-14 19:57:10 minimal: util/geniso: mkisofs or genisoimage not found, please install or set PATH 2022-02-14 19:57:24 This is really annoying starting everything over every time. 2022-02-14 19:59:19 minimal: and after this is all compiled there is no ipxe.efi... that is even more frustrating. 2022-02-14 19:59:23 skinkie: makedepends in the APKBUILD *does* list bash 2022-02-14 19:59:28 "19:48 why would you be rejected" well, i can't think of a reason, which is why i would be upset if a reason wasn't provided 2022-02-14 19:59:45 why do you think there would be no reason :p 2022-02-14 19:59:58 minimal: without -d i get >>> ERROR: alpine-ipxe: builddeps failed 2022-02-14 20:00:00 skinkie: and xorriso, which is where I guess mkisofs/genisoimage come from 2022-02-14 20:00:24 well there is usually some error that indicates why the builddeps failed 2022-02-14 20:00:28 in the log output 2022-02-14 20:00:38 and obviously then passing -d to just skip that will fail to build 2022-02-14 20:00:43 since the deps are missing 2022-02-14 20:00:55 :p 2022-02-14 20:01:09 psykose: totally makes sense 2022-02-14 20:02:21 well, i am suspicious of secret committee meetings. perhaps a better word would be closed-door 2022-02-14 20:02:42 to be clear, i'm not saying that a reason will not be provided. i'm saying that i'm concerned about this possibility 2022-02-14 20:02:57 Then you could call us out for it 2022-02-14 20:03:06 i can offer you a headpat to ease your head 2022-02-14 20:03:06 ^ 2022-02-14 20:03:34 can I have a shoulder massage? 2022-02-14 20:03:38 sure 2022-02-14 20:03:42 yes please! 2022-02-14 20:03:45 ... 2022-02-14 20:03:47 thanks! 2022-02-14 20:03:50 :3 2022-02-14 20:03:54 :D 2022-02-14 20:03:57 MY-R: get in line 2022-02-14 20:04:07 :\ 2022-02-14 20:05:25 If the TSC meetings would be recorded, everyone would be very cautious to say anything 2022-02-14 20:05:34 Hello71: do you have any proposals to improve TSC transparency, keeping in mind that sensitive data (e.g. personal data, 0days, etc.) is discussed by the TSC 2022-02-14 20:06:40 the tsc should be mandated to post cat pictures 2022-02-14 20:06:48 lol 2022-02-14 20:06:59 https://ukmadcat.com/wp-content/uploads/2019/04/sleepy-cat.jpg 2022-02-14 20:07:06 the present level of cats leaves serious doubts of trust 2022-02-14 20:07:07 the technical sand cat committee 2022-02-14 20:07:12 cute! 2022-02-14 20:07:16 minimal: while abuild failed on various other reasons, I now have an ipxe.efi. 2022-02-14 20:07:19 well, i think this is an issue with committees. suppose there was no tsc, and ncopa was the arbiter. then, even if ncopa asks ikke for advice, and rejects someone, then the decision is clearly ncopa's responsibility. on the other hand, with a committee, there is liable to be buck-passing 2022-02-14 20:07:26 https://public-media.si-cdn.com/filer/18/1d/181d01e1-d0e8-47f7-bbf6-2651f6cd27b9/sand_cat_2.jpg 2022-02-14 20:07:49 problem presented; problem solved 2022-02-14 20:07:51 points of respect like in "need for speed"? :P 2022-02-14 20:07:59 in terms of concrete proposals, gentoo bureaucracy simulator posts all IRC meeting transcripts. i assume if something particularly sensitive were discussed it would be redacted 2022-02-14 20:08:30 These are in-person meetings, not irc chats 2022-02-14 20:08:42 this is arguably harder to do with voice calls 2022-02-14 20:08:43 Not in-person 2022-02-14 20:08:45 voice call 2022-02-14 20:09:00 what you're saying is they need to be upgraded to an irc chat 2022-02-14 20:09:23 now I see kind of nice debate, is great 2022-02-14 20:09:40 it should be on microsoft teams for hippo compliance 2022-02-14 20:09:45 lmao 2022-02-14 20:09:52 not the hippos :( 2022-02-14 20:09:55 hippo not hippa? lol 2022-02-14 20:10:28 thats-the-joke.jpeg 2022-02-14 20:10:38 well it's actually hipaa, but now the joke has been dissected 2022-02-14 20:10:47 perhaps we can resurrect it 2022-02-14 20:11:06 psykose: it's an ex-joke, it's snuffed it... 2022-02-14 20:26:45 Ariadne: did you have a chance too look into updating gcc to a newer snapshot yet? if not, I also can send MRs backporting/updating the -fsplit-stack patch 2022-02-14 20:27:07 yes, will do it this evening 2022-02-14 20:27:26 great, thanks! 2022-02-14 20:27:26 is gdc still broken on x86 2022-02-14 20:27:45 Hello71: yes probably 2022-02-14 20:27:49 i mean, its D 2022-02-14 20:27:52 can you fix it 2022-02-14 20:28:05 i mean, it seems to be working 2022-02-14 20:28:09 we were able to build ldc anyway 2022-02-14 20:28:19 but its probably still broken 2022-02-14 20:28:45 i think we should use your patches instead of matthias lang's 2022-02-14 20:28:52 so i have made a mental note to swap it 2022-02-14 20:29:32 we should really attempt to get more of our patches integrated upstream 2022-02-14 20:29:47 I also still have a few gccgo patches in my queue that I would like to see integrated upstream 2022-02-14 20:30:14 ah, yes, i forgot mathias' patch was merged 2022-02-14 20:31:00 nmeum: some gcc folks are keeping an eye on our tree, i'll talk to them about merging some more :) 2022-02-14 20:57:52 minimal: I've synced the logs for x86_64 3.15 now 2022-02-14 21:04:17 /b 13 2022-02-14 21:54:02 psykose: meson 0.61.2 is released a short while ago, so meson should run the unittests using pytest correctly now. This will help a lot in reading the CI logs :D 2022-02-14 21:54:25 yes, it should be bumped in alpine shortly 2022-02-14 21:54:32 then i can go back to reading the output 2022-02-14 21:54:44 also adding NINJA=samu does not seem to fix the invocation for some reason.. 2022-02-14 21:54:50 (also it fixes some broken things which is its own good thing, of course...) 2022-02-14 21:54:58 it still reports itself as ninja: samustring and matches neither 2022-02-14 21:54:59 hah 2022-02-14 21:56:07 the highlight of the release is, of course, one more fix to the gnome module 2022-02-14 21:56:46 because where would we be without gnome being a mess! 2022-02-14 21:56:56 probably a place of something else being a mess in its place 2022-02-14 21:57:00 :p 2022-02-14 21:57:07 but yes, i will look at it tomorrow 2022-02-14 21:57:10 The universe finds a way 2022-02-14 21:57:12 tired.. late.. 2022-02-14 21:58:30 gnome messes include gems like "if you try to build docs, it will compile the source code again, using a non-cross-compile friendly custom wrapper that does partial compilation and also only works, somehow, *inside the installdir* so it needs to run during install and not during build" 2022-02-14 21:58:45 sadly I have not been able to fix that particular mess... 2022-02-14 21:58:57 phenomenal 2022-02-14 23:11:57 Hey, so I got a bit of a curveball out of CI earlier today. I'm adding CET-IBT support to Xen, for call/jump oriented programming hardening 2022-02-14 23:12:14 and to cover one of the more basic security holes, we have the following build-time check: https://github.com/andyhhp/xen/blob/ecaa5f3096aad5585c0c54dacdba60880d677580/xen/tools/check-endbr.sh#L35-L54 2022-02-14 23:12:41 purpose is to spot any embedded ENDBR64 instructions in the binary which aren't intentional ones 2022-02-14 23:13:01 and it turns out that your grep doesn't do binary searches 2022-02-14 23:13:36 you can install gnu grep 2022-02-14 23:13:41 it's just `grep` 2022-02-14 23:13:41 is there a more complete grep package about? 2022-02-14 23:14:24 ah - excellent. I'll give that a shot 2022-02-14 23:23:04 (alternatively, if anyone doesn't want grep to be a build-time-only dependency for Xen and has a better idea, I'm all ears) 2022-02-14 23:23:36 it doesn't sound that bad to me 2022-02-15 00:05:05 although if you're already using binutils then you could just objdump -d 2022-02-15 00:05:22 ah, you want the file offsets 2022-02-15 00:06:35 and you want it to be potentially misaligned with a natural decoding 2022-02-15 00:06:57 then yeah, i don't have a better solution than installing gnu grep 2022-02-15 00:07:11 you need to set LC_ALL=C though 2022-02-15 00:07:21 andyhhp: 2022-02-15 00:08:42 so yeah, this is a double pass over the file 2022-02-15 00:08:50 to spot this evil case: https://github.com/andyhhp/xen/blob/f44aa29c8349c78f04af60c3aa2c7dc309d983fe/xen/arch/x86/include/asm/endbr.h#L22-L41 2022-02-15 00:10:09 there's one pass which uses objdump -d to find "valid" ENDBR64 instruction 2022-02-15 00:10:35 and a different pass to find any byte sequence which happens to match an ENDBR64 instruction 2022-02-15 00:11:28 then we subtract the valid instructions from all byte sequences, and if the result is nonzero, complain 2022-02-15 01:30:44 i wonder if it wouldn't be more efficient to do asm("endbr64\nud2"); 2022-02-15 01:33:31 asm(".globl endbr64\nendbr64:\nendbr64\nud2"); 2022-02-15 01:34:24 you can branch here if you want, it'll just crash the program. cet doesn't protect against that anyways 2022-02-15 02:02:56 andyhhp: 2022-02-15 02:03:00 yes? 2022-02-15 02:03:21 ^ 2022-02-15 02:03:21 why do I want extra random ud2s that noone branches to? 2022-02-15 02:03:35 well it's better than actually running mov 2022-02-15 02:03:48 er, well, i guess you run mov either way, but then you don't have to run nop 2022-02-15 02:03:52 ? 2022-02-15 02:04:00 s/nop/not/ 2022-02-15 02:04:05 I'm confused 2022-02-15 02:05:27 Oh - I see. No - that's not how the helpers are used 2022-02-15 02:07:01 see https://github.com/andyhhp/xen/commit/2d96a83f702e72211153f44a3d0bfa6ff1cd9fca and https://github.com/andyhhp/xen/commit/75bad5ca489280183a792ca6862ca28269df1043 and https://github.com/andyhhp/xen/commit/58257668f6e7e28be1fd23a765f990258883a3d3 as examples of what they're for 2022-02-15 02:14:42 yes, i'm saying that it seems easier to have a real endbr64 and simply make sure it can't do any harm than to do the not shenanigans 2022-02-15 11:39:26 any idea what might have happened to nodejs on rv64? i don't see the job on build.a.o anymore, but it's not in the repo or buildlogs either 2022-02-15 11:46:28 ptrc: apparently it's still building it, or it's stuck 2022-02-15 11:46:38 oh, thanks 2022-02-15 11:46:58 probably stuck 2022-02-15 12:16:58 Hi, anyone know if b348ca9cdf59637fc712072bb1496c014b438b27 could have relation with https://i.postimg.cc/ydsvNrXx/screenshot-2022-02-15-125117.png ? 2022-02-15 12:19:45 wild 2022-02-15 12:20:57 it started yesterday at the end of the day 2022-02-15 13:09:36 donoban: looks like a feature to me 2022-02-15 13:57:12 hehe, it was fun :) 2022-02-15 17:34:06 hi, I'm trying to build the raspberry pi kernel with abuild at tag 3.15.0. When building with abuild -r installing the dependencies fail with a lot of errors like these: https://paste.sr.ht/~apreiml/51df330c28e922805bf3e728a0b28570bfc1a4b0 Am I missing something? 2022-02-15 17:35:28 is /lib mounted readonly 2022-02-15 17:37:32 /lib/modules is mounted read-only 2022-02-15 17:37:37 er, /lib/firmware 2022-02-15 17:38:03 you could also add linux-firmware-none to world so it doesn't install all this firmware during the build 2022-02-15 17:40:35 ah yes. Thanks! 2022-02-15 20:54:37 Ariadne: I wonder if we should give openssl 3 another try? seems fedora have patches for mariadb now 2022-02-15 20:54:57 what is the rush 2022-02-15 20:55:39 I think we need start with it soonish if we want it into 3.16. 2022-02-15 20:55:57 unless you are fine with a split-world of some things remaining on 1.1, it won't be ready yet 2022-02-15 20:56:24 Was the issue we had with apk-tools fixed as well> 2022-02-15 20:56:26 and to my knowledge there is no real improvement 2022-02-15 20:56:26 ? 2022-02-15 20:56:35 psykose: the license 2022-02-15 20:56:43 sure, but that's just lawyer stuff 2022-02-15 20:56:53 there is no actual functionality, size, performance, security improvement 2022-02-15 20:57:00 just pain and suffering :p 2022-02-15 20:57:08 I think last time we tried we had approx 50% split. To my understanding the majority of those on 1.1 was related mariadb 2022-02-15 20:57:18 it was a good chunk of the 50% yes 2022-02-15 20:57:24 because it kept curl behind with it 2022-02-15 20:57:41 don't remember the numbers with mariadb swapped, maybe it was 80% 2022-02-15 20:57:50 now that fedora has moved to 3.0 I would expect that there are patches available for most of them 2022-02-15 20:59:13 seems like ubuntu is also planning to do 3.0 with the ubuntu 22.04 release 2022-02-15 20:59:43 The discussion about switching to libressl stalled 2022-02-15 21:04:47 the relicensing is sketchy 2022-02-15 21:12:39 imo we should just do nothing 2022-02-15 21:45:24 we should discourage use of openssl ^_^ 2022-02-15 21:46:09 It's entrenched 2022-02-15 22:24:53 what's the best way to package something that uses git submodules? 2022-02-15 22:25:09 you add them as thing in source= 2022-02-15 22:25:22 see e.g. testing/imhex , testing/pcsx2 2022-02-15 22:25:56 then move them to the place in prepare() 2022-02-15 22:27:25 Might mean you need to specify the commits used for each module 2022-02-15 22:29:29 yep 2022-02-15 22:29:39 usually the git forges just show you the sha1 in the links 2022-02-16 01:27:42 hello devel, I am wanting to make some changes in to /sbin/lbu in alpine-conf-3.13.0-r0.apk on a diskless install, is it as simple as extracting the apk, editing /sbin/lbu, then recompress? or will I run into signature issues etc 2022-02-16 01:29:21 I would like to update the KDF to pbkdf2 for the lbu ci -e option, while keeping support for the old kdf 2022-02-16 01:30:20 I'm probably not qualified for such a task but I'd like to try and maybe learn something 2022-02-16 01:30:39 XY problem. rebuild the package with your custom patch 2022-02-16 01:31:33 if you insist on doing it the wrong way, you might be able to add /usr/local/sbin/lbu 2022-02-16 01:51:07 I was mainly wanting to avoid setting up a build environment since I'm on a pi2 but I guess if I must 2022-02-16 01:53:56 "setting up a build environment"? this isn't windows where you need to spend half an hour downloading and installing 20 GB of crap to compile a five-line C program 2022-02-16 02:00:21 I apologize for not knowing all the intricacies of how apks are set up 2022-02-16 02:20:04 and fyi it does take over a half hour just to get alpine sdk and clone aports on my connection and hardware 2022-02-16 02:20:50 atka: Did you do a "--depth=1" clone for aports? 2022-02-16 02:21:26 no, I'm just following the creating an alpine package guide 2022-02-16 02:22:49 atka: If you just want access to the aports code, you can add "--depth=1" to the git clone command, that will skip fetching the history and will only have the single latest commit. Although I'm not sure if you can contribute changes back with a shallow clone (you _should_ be able to I think) 2022-02-16 02:23:13 thanks I'll keep that in mind for next time 2022-02-16 02:23:47 i'm at 47% now, I'll just let it go 2022-02-16 02:26:48 alpine-sdk is only ~200 MiB installed, i guess maybe 50 MB download? that shouldn't take longer than a few minutes unless you're on like dialup 2022-02-16 02:27:14 psykose: submitted another small Meson testsuite fix 2022-02-16 02:27:19 if you really want to save bandwidth, just install abuild and download the package directory directly from gitlab 2022-02-16 02:27:32 which actually makes the tests run faster locally, so that's nice :D 2022-02-16 02:27:34 Hello71: It's the aports clone that can take a long time 2022-02-16 02:28:00 yes, i think that's actually gitlab cpu bounded on a fast connection 2022-02-16 02:28:21 eschwartz: oh, neat :) 2022-02-16 02:28:35 hm 2022-02-16 02:28:42 i wonder why it returned nonzero even though the tests passed 2022-02-16 02:28:44 and i think github doesn't support pushing from shallow clones, not sure about gitlab 2022-02-16 02:31:44 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/632579 this should finally be successful, and i see no failures, though it's still nonzero 2022-02-16 02:31:45 oh 2022-02-16 02:31:51 it raises a systemerror due to the CI things 2022-02-16 02:32:35 i guess we do need to set a MESON_CI_JOBNAME, since otherwise this always raises an error with CI defined 2022-02-16 02:34:55 MESON_CI_JOBNAME is... supposed to flag it as requiring integration into the testsuite's list of which CI runners have which dependencies and can or cannot skip particular jobs 2022-02-16 02:34:57 hmm 2022-02-16 02:35:10 maybe trying to get it to work with $CI set was a fools errand 2022-02-16 02:35:57 or maybe meson shouldn't check that meson's own github workflows set MESON_CI_JOBNAME, but just assume that it is set 2022-02-16 02:36:00 ACTION thinks 2022-02-16 02:36:08 it's defined like that in the uhhh file 2022-02-16 02:36:29 https://github.com/mesonbuild/meson/blob/2e2ca5a877ce8569e9daf78c3a5b32a423531d97/run_project_tests.py#L1508 2022-02-16 02:36:43 under_ci is CI, right is jobname, so you need both or neither 2022-02-16 02:37:02 i forgot what the issue was in the first place with CI defined 2022-02-16 02:37:38 gitlab sets it by default 2022-02-16 02:37:48 right 2022-02-16 02:37:50 oh right 2022-02-16 02:37:52 i can just unset it 2022-02-16 02:37:55 of course 2022-02-16 02:38:09 probably 2022-02-16 02:38:44 it was an interesting thought to try to see if it could just magically work OOTB, but at this point may not be worth me fighting it any longer 2022-02-16 02:49:36 yeah, with both of them defined it then runs some random thing that fails, and with it unset it passes all the first tests and continues to some later steps 2022-02-16 02:49:52 as for the ninja/samu thing you have in the upstream mr there- there is another case where the ninja/samu output differs 2022-02-16 02:50:18 oh hmm, what case? 2022-02-16 02:50:20 specifically there is a case where ninja still prints the usual no work to do, but samu actually prints `ninja: explain all: phony and no inputs` 2022-02-16 02:50:28 i forgot which test invokes that 2022-02-16 02:50:40 but adding that string to self.no_rebuild_stdout does then match it as well 2022-02-16 02:50:46 it's in one of the patches 2022-02-16 02:51:50 sadly this seems like a very.. uninteresting and pointless level of 'compatibility' between samu/ninja, so i don't think this makes sense to propose into samu itself, (or maybe it already has, given how long it's been since a release, as you saw earlier, hah) 2022-02-16 02:53:27 ah, and i see now- that new CI update was actually preventing some of the testsuites from running, so there was actually more failures for me to debug 2022-02-16 02:53:40 (they do now run again with the unset) 2022-02-16 02:54:17 one of the tests seems to always get run regardless of glib-2.0 being present, so fails without, another fails to find boost even though it should be present 2022-02-16 02:54:20 some other assorted failures 2022-02-16 02:55:03 some random tests still have a MALLOC_PERTURB 2022-02-16 02:56:04 ah, this test project has zero rules, and samu prints nothing 2022-02-16 02:56:22 ninja just says "nothing to do" 2022-02-16 02:57:00 # only the ninja backend is competent enough to detect reconfigured 2022-02-16 02:57:02 # no-op builds without build targets 2022-02-16 02:59:19 lol, that test case is my fault even: https://github.com/mesonbuild/meson/pull/9604 2022-02-16 02:59:31 from fighting with MSVC 2022-02-16 03:00:55 :p 2022-02-16 03:06:26 a bunch of things mysteriously fail while trying to run tests 2022-02-16 03:06:51 the gettext6 thing fails because of the mess that is libintl on alpine i would guess 2022-02-16 03:07:20 one of them fails trying to run pkg-config --validate 2022-02-16 03:07:28 that one confused me :/ 2022-02-16 03:07:52 yeah a lot of these are pain 2022-02-16 03:08:33 > Run-time dependency Boost (missing: date_time, system, thread) found: NO (tried system) 2022-02-16 03:09:00 it is most definitely there (and pretty much always works everywhere else, tons of stuff use boost via meson/cmake/pkgconf) 2022-02-16 03:09:05 so i am very confused how that one fails 2022-02-16 03:09:58 the malloc_perturb fails i really have no idea 2022-02-16 03:10:40 are you having as much fun as me running this massive testsuite on a 'new' platform :p 2022-02-16 03:41:07 psykose: oh yes, very fun 2022-02-16 03:41:41 I just found a dumb bash script (not sh) using grep *and* bash var substitution during configure time as a run_program() 2022-02-16 03:41:49 to reimplement meson's builtin .version() function 2022-02-16 03:43:48 and now you get to fix it :) 2022-02-16 03:48:59 it's pretty dumb to require bash as a check dep just to run cmake --version and check the version, yeah 2022-02-16 03:53:12 psykose: https://mesonbuild.com/Unit-tests.html#malloc_perturb_ 2022-02-16 03:53:22 I very much doubt this is the cause of the errors 2022-02-16 03:55:09 oh, i see 2022-02-16 03:55:14 it was just printing that 2022-02-16 03:55:33 i thought it was an error string 2022-02-16 03:56:31 in that case that test output is not very clear on what the error is, as you just get an exit 127 or whatever and some samu logs without a clear 'this failed' 2022-02-16 03:56:39 i suppose i can have more of a look tomorrow 2022-02-16 03:56:57 and ptrc, as she has been going along with me on fixing all of these 2022-02-16 03:57:15 anxious.. 2022-02-16 03:57:16 goodnight 2022-02-16 04:05:49 the boost thing looks very weird, does it reproduce locally if you install meson and boost-dev, checkout the meson git repo, and attempt to build "test cases/frameworks/1 boost/" ? 2022-02-16 04:06:38 if it reproducibly fails from an interactive console, then it may be time to edit mesonbuild/dependencies/boost.py and uncomment all `mlog.debug` print statements 2022-02-16 04:36:06 psykose: https://github.com/mesonbuild/meson/pull/10010/commits/e6216119d7043fa6641821fbbce1159891befe28 2022-02-16 04:36:23 this Should(tm) allow you to set MESON_CI_JOBNAME=thirdparty 2022-02-16 05:30:39 something weird with gitlab builds? jobs for !30976 fail during cleanup: Cleaning up srcdir 2022-02-16 05:30:39 rm: can't remove '/builds/alpine/aports/community/containerd/src/pkg/mod/golang.org/x/net@v0.0.0-20211216030914-fe4d6282115f/codereview.cfg': Permission denied 2022-02-16 05:32:02 tomalok: you need to add `export GOFLAGS="$GOFLAGS -modcacherw"` 2022-02-16 05:36:56 ikke: thanks for the reminder -- i remember adding that for some other docker-y things, looks like containerd caught up with the others. 2022-02-16 05:43:39 Is the ppc64le CI out of disk space? It's failing to upload artifacts on https://gitlab.alpinelinux.org/ktprograms/aports/-/jobs/632638, and I retried the CI and it's just waiting at the upload step again 2022-02-16 05:48:29 ktprograms: no, network related issues 2022-02-16 05:51:51 ktprograms: although right now there does not seem to be any packetloss 2022-02-16 05:52:34 ktprograms: that ci host has way more than enough diskspace 2022-02-16 05:53:43 ikke: I see 2022-02-16 06:05:25 df reports 0% disk usage ;-) 2022-02-16 07:38:51 ikke: The CI timed out again (same problem I think) 2022-02-16 16:03:37 I would like to package an alternative initramfs generation tool, can I have that package provide mkinitfs with provider_priority=0 or would that break stuff? 2022-02-16 16:04:14 (linux, syslinux, … have a dependency on mkinitfs) 2022-02-16 16:29:47 it should be fine 2022-02-16 16:51:30 can someone close #12752? doesn't seem to conflict anymore on any alpine version 2022-02-16 16:54:09 nmeum: isn't there already a MR do add an alternative to mkinitfs that works this way? 2022-02-16 16:54:25 ptrc: it is for upgrades 2022-02-16 16:54:59 nmeum: !28541 and !28538 2022-02-16 16:55:07 Hello71, what do you mean? 2022-02-16 16:55:54 updates as in, new version of setuptools or upgrading alpine? 2022-02-16 16:56:14 upgrading alpine from 3. uh... 10? 2022-02-16 16:59:29 would that be upgrading to any specific version? i tested upgrading 3.10, 3.11 and 3.12 with python3 and py3-setuptools to 3.15 and i can't reproduce any file conflicts 2022-02-16 17:06:35 minimal: yes, that is my mr. I was just wondering if I can do it without a new virtual initramfs-generator package 2022-02-16 17:07:09 ah, didn't realise it was you, doh! 2022-02-16 17:12:30 nmeum: can't you do it in a similar way to how util-linux-login and shadow-login both provide "login-utils"? 2022-02-16 17:13:47 you mean have both packages provide a dedicated virtual package? yeah, that's what my original MR does 2022-02-16 17:14:19 I just don't want to mess with all packages depending on mkinitfs for now. that's why it would be easier to just provide mkinitfs with provider_priority 0 2022-02-16 17:20:06 btw: we should have setup-sshd in the installer ask whether root login should be enabled when openssh is selected or, alternatively, prompt for creation of an unprivileged user. otherwise you end up with a system where you can't login over ssh 2022-02-16 17:21:46 nmeum: using "provides" with a version or without a version? 2022-02-16 17:22:57 as if without a version then, according to https://wiki.alpinelinux.org/wiki/APKBUILD_Reference, "If version is not provided (provides='foo'), apk will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously." 2022-02-16 17:23:31 which I assume is not what you want (the "can be installed simultaneously" bit) 2022-02-16 17:23:51 hmhmhm 2022-02-16 17:23:52 right 2022-02-16 17:24:02 maybe I do need to introduce a virtual initramfs-generator package then 2022-02-16 18:06:41 ptrc: not sure exactly, it could be fixed now (or "fixed") 2022-02-16 20:44:38 hi, I submitted !29744 a little while ago, is there something else I must do? 2022-02-17 01:54:38 Hi, does anyone get a segfault when pressing "h" for help on any of the games in the ace-of-penguins package? 2022-02-17 01:56:03 I've built it with debug symbols and it seems like the segfault is from XTextWidth, called by lib/help.c:183 seemingly handling something with fonts. 2022-02-17 02:56:23 ktprograms: hi, package maintainer here. i'm also getting a segfault there. not sure why that would happen; i'll look into it. thanks for the heads up! 2022-02-17 02:57:36 sebonirc: Ah thanks, I forgot what your nick was. I think it might be related to the three fonts it looks for not being available (courier, helvetica, times) 2022-02-17 02:58:10 FYI you can add $pkgname-dbg to subpackages= in order to build debug symbols. 2022-02-17 03:03:19 yup, that would make sense. i think XLoadQueryFont is returning NULL when the font isnt available, then that's passed into XTextWidth. 2022-02-17 03:05:56 i'm a relatively new packager so i apologize if this is a dumb question, but what do you think the best approach here would be? are there packages that provide those fonts that ace-of-penguins should depend on? or would it make more sense to add a patch that manages to avoid any explicit font dependencies? 2022-02-17 03:06:47 sebonirc: Do you know how to get the default font in C through the X libraries? I think that would be the best way to go. 2022-02-17 03:07:46 i don't, but i could probably figure it out. 2022-02-17 03:07:49 I think the fonts it expects aren't free fonts so Alpine doesn't package them 2022-02-17 03:07:52 i'll try doing that, thanks! 2022-02-17 03:08:20 yeah thats what i assumed, i was wondering if there was a package that provided free alternatives to those fonts but with the names of the nonfree ones, which i assume not 2022-02-17 03:08:23 You can probably test just hardcoding DejaVu or one of the other fonts Alpine packages first, just to see if the theory is correct 2022-02-17 04:41:57 Hi, I'm trying to write an APKBUILD, and I was wondering whether the source tarball should have a top level directory or not? I'm assuming it's not desirable, so I have something like `mv $folder/* .` `rmdir $folder`, does that sound right? 2022-02-17 04:43:25 sm2n: The default builddir is $srcdir/$pkgname-$pkgver, so if your tarball inflates to match that then that's good. Although even if it has another subfolder, it would probably be better to just change builddir= than do a mv/rmdir dance 2022-02-17 04:44:28 thanks, that helps 2022-02-17 04:45:18 I just want to confirm that abuild doesn't extract to $srcdir/$pkgname-$pkgver itself, because I don't want to end up nesting by accident 2022-02-17 04:47:28 okay, that appears to work 2022-02-17 04:49:09 sm2n: It extracts to $srcdir 2022-02-17 04:49:30 great, that means I didn't screw it up 2022-02-17 04:50:53 incidentally, what's the process if your source tarball doesn't have a toplevel folder? 2022-02-17 05:07:13 sm2n: As in the entire source directory gets spewed into the current dir when extracting? I think it should still be fine-ish because it'll be in $srcdir, but otherwise I think you can override unpack(), see https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L489 for the default implementation 2022-02-17 05:07:47 oh, I see, thanks 2022-02-17 05:25:37 Is there a way to make abuild only run the check again in a way that is compatible with abuild -r? abuild check appears to error out saying the makedepends are not found for some reason 2022-02-17 05:43:50 sm2n: Run "abuild deps" before that 2022-02-17 05:44:58 abuild deps check 2022-02-17 05:45:22 ikke: Oh right, you can chain the commands 2022-02-17 05:49:42 And also "abuild undeps" when you're done testing so you don't have the deps kept installed. 2022-02-17 05:50:43 or run abuild -r afterwards if you want to do a clean test and it will do undeps automatically 2022-02-17 06:07:50 psykose: I pushed another fix which hopefully fixes GNU libintl as a separate package 2022-02-17 06:08:33 Hi all, is it expected that expat 2.4.4 ( with the CVECVE-2022-23852 fix) will still be deployed in Alpine 3.12 even though eol is in two months? 2022-02-17 06:10:43 psykose: I do *not* understand this: 2022-02-17 06:10:44 Error relocating /builds/alpine/aports/main/meson/src/meson-0.61.2/b 072d934c27/subprojects/B/libb.so: func_c: symbol not found 2022-02-17 09:20:38 when can we expect an update on the council's resolution to the open CoC questions? 2022-02-17 12:21:25 eschwartz: smells like -z now 2022-02-17 12:35:04 link? 2022-02-17 12:38:13 Hello71: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/633113#L1918 2022-02-17 12:39:55 weirdly enough, i can't reproduce this error locally 2022-02-17 12:40:04 the test fails, but for a different reason - samu reports "nothing to do" 2022-02-17 12:42:05 it seems like a bad idea to write -Wl,-soname,libc.so 2022-02-17 12:42:47 not sure if that is related to this problem specifically but it seems suspicious in general 2022-02-17 12:44:34 seems like -Wl,--no-undefined is passed, so it's probably not -z now. i reckon it's -soname libc.so that's the problem 2022-02-17 12:45:51 eschwartz, does the CI env affect test output in any way? i'm not sure if it doesn't fail, or just fails silently 2022-02-17 12:47:55 ah, nevermind, i just checked and see that it does 2022-02-17 12:53:15 hm, but musl ignores soname... 2022-02-17 13:12:58 "nm -D" reports "U func_c" for that shared library, but i'm not sure how to parse 2022-02-17 13:13:14 Hello71: do you know if that might be significant? 2022-02-17 13:13:31 yes, that's expected. 2022-02-17 13:13:37 oh, okay 2022-02-17 13:14:00 ohh, wait 2022-02-17 13:14:07 libb.so => ./subprojects/B/libb.so (0x7f2f8299a000) 2022-02-17 13:14:07 libc.so => /lib/ld-musl-x86_64.so.1 (0x7f2f829a4000) 2022-02-17 13:14:13 i don't think that's correct.. 2022-02-17 13:18:22 musl linker always claims libc for itself 2022-02-17 13:18:39 meson test is flawed 2022-02-17 13:22:06 yeah, it looks like on glibc it doesn't get matched, only "libc.so.6" 2022-02-17 13:24:08 renaming the library in subprojects/C/meson.build to anything than `c` seems to work 2022-02-17 13:24:15 :) 2022-02-17 14:02:51 alright, patching all 'c' library names (https://tpaste.us/5nB7) makes all common tests pass 2022-02-17 14:05:45 and with the new patch for libintl handling, frameworks test for gettext is also passing 2022-02-17 14:06:26 there's still a bunch of tests that are "UNEXSKIP", not sure why 2022-02-17 14:08:23 ptrc: the unexskip is because I only fixed the unit tests to allow skippable under thirdparty CI. I added another patch to make that work for project tests too 2022-02-17 14:09:09 Also on the libb, libc thing... Now I recall that lattis mentioned this when importing tests from meson to muon and doing weird things on alpine 2022-02-17 14:09:28 So... I will fix that too, I honestly meant to even when lattis reported it 2022-02-17 14:09:54 ah, would that unexskip patch be another PR under the meson project, or..? 2022-02-17 14:13:16 It's in the same PR 2022-02-17 14:13:53 https://github.com/mesonbuild/meson/pull/10010/commits/6dbc3b689dcab16594a180fa19e67332f7d659fd 2022-02-17 14:16:15 oh, i have this patch already applied 2022-02-17 14:16:32 and MESON_CI_JOBNAME is "thirdparty" 2022-02-17 14:19:59 wait, isn't it supposed to be "ci_jobname is None" rather than "is not None"? 2022-02-17 14:20:51 .... yes, that answers my question "is my patch confirmed to be broken or were those results from a previous run" 2022-02-17 14:26:34 well, looks like everything is working now 2022-02-17 14:27:32 at least on my machine, not sure about the actual CI 2022-02-17 16:53:10 ddevault: there have been some serious allegations made about mps, so I'm investigating that, which takes time. In the meantime, we already took actions 2022-02-17 16:53:42 thanks ikke 2022-02-17 16:53:49 has there been any movement on updating the alpine CoC? 2022-02-17 16:54:29 ddevault: We have asked Telmich to work on that 2022-02-17 16:54:50 Who is going to be leading the team to handle these kind of issues 2022-02-17 16:55:55 understood, cheers 2022-02-17 18:12:10 -dkimsign/0.5-1/), whereas arch downloads a tarball from some obscure unofficial mirror that i don't have much confidence in (https://github.com/archlinux/svntogit-community/blob/packages/opensmtpd-filter-dkimsign/trunk/PKGBUILD) . i would prefer debian's approach, but i'm not sure what alpine's policy is in these cases. 2022-02-17 18:12:10 hi! i'm very new to alpine but would like to try adding a new package to the repositories, specifically a DKIM signing filter for OpenSMTPD: http://imperialat.at/dev/filter-dkimsign/ . the problem is that the developer does not really provide any kind of release tarballs; there's apparently just a bunch of files served via http at that url. debian has its own copy of the sources (https://sources.debian.org/src/opensmtpd-filter 2022-02-17 18:17:09 how about https://imperialat.at/releases/filter-dkimsign-0.5.tar.gz ? 2022-02-17 18:17:52 malvo: basically, someone needs to take responsibility and make proper releases (tarballs) 2022-02-17 18:18:30 pj: :facepalm: how did you find that? 2022-02-17 18:18:40 normally, if upstream is not willing to do it, they may have a good reason to not do so (unstable, no guarantees for security fixes etc) 2022-02-17 18:19:00 Repology collects lots of information about packages: https://repology.org/project/opensmtpd-filter-dkimsign/information 2022-02-17 18:19:26 pj: thanks! that's new to me 2022-02-17 18:19:51 ncopa: alright, that makes sense, i'll use the release tarball. 2022-02-17 18:20:04 thanks! 2022-02-17 19:08:08 hi, i'm trying to figure out why i'm getting permission denied errors: https://paste.ee/r/lsegF 2022-02-17 19:08:25 eschwartz: ah, i see. thanks for all the changes! not sure what the correct thing to set is for ci/jobname to make unexskip skip instead (thirdparty still fails), and there are still ~4 generic meson errors that i can't figure out, but the rest is green 2022-02-17 19:09:10 echelon: well it says certificate verify failed on all of them 2022-02-17 19:09:43 so either the mirror cert expired, or your time is in 1980, or something like that, i would guess 2022-02-17 19:10:26 psykose: it's supposed to work, but my patch is buggy :p 2022-02-17 19:10:29 yeah, i have to add certs to /etc/ssl/cert.pem to reach ssl endpoints because of the proxy i'm behind, it would help if i knew where it was trying to download these packages from 2022-02-17 19:11:07 psykose: I just got back so I'm going to push the fix in like 2 minutes 2022-02-17 19:11:29 echelon: it's downloading from /etc/apk/repositories, the list of mirrors there 2022-02-17 19:11:33 eschwartz: ah, i see! thanks :) 2022-02-17 19:11:53 and pushed 2022-02-17 19:11:55 psykose: thanks! 2022-02-17 19:12:51 updated 2022-02-17 19:13:54 psykose: i can `curl https://dl-cdn.alpinelinux.org` just fine, so i guess `abuild -r` isn't honoring /etc/ssl/cert.pem ? 2022-02-17 19:14:08 can you apk add things manually 2022-02-17 19:14:12 abuild -r just calls apk 2022-02-17 19:14:44 i don't remember if apk honors that, and i am generally never in this kind of proxy environment sadly 2022-02-17 19:16:24 psykose: the remaining errors are the libc thing, this patch takes care of that: https://gitlab.alpinelinux.org/ptrcnull/aports/-/blob/meson/main/meson/fix-test-library.patch 2022-02-17 19:17:59 applied 2022-02-17 19:18:03 no, i can't install using apk 2022-02-17 19:18:40 eschwartz: also note the fix-ninja-output-test.patch and the few skips in skip-broken-tests.patch - not sure how feasible an upstream fix for those is, as most of them are just samu differences 2022-02-17 19:24:41 ptrc: I also pushed a libc.so fix by the way 2022-02-17 19:25:44 oh, nice 2022-02-17 19:25:45 thanks 2022-02-17 19:26:36 + @unittest.skip('py3-jsonschema in community') 2022-02-17 19:26:44 this should be automatically skipped now 2022-02-17 19:27:33 it's supposed to be skipped in general, but has an in_ci() check to avoid skipping on the @mesonbuild CI runners. Which should be fixed by the MESON_CI_JOBNAME=thirdparty handling 2022-02-17 19:29:23 nice 2022-02-17 19:31:11 + @unittest.skip('broken with improperly detected sanitizers') 2022-02-17 19:31:20 this could link to the upstream bug https://github.com/mesonbuild/meson/issues/8283 2022-02-17 19:32:36 done and done 2022-02-17 19:37:05 what's the reason for the error in test_pkgconfig_formatting ? 2022-02-17 19:40:39 i don't remember now 2022-02-17 19:40:42 i can try run it again 2022-02-17 19:40:47 also it does still try to find jsonschema 2022-02-17 19:49:28 psykose: ah, it tries to find jsonschema because the unittests now see MESON_CI_JOBNAME=thirdparty and say "okay, there's a CI jobname so make everything required" 2022-02-17 19:49:36 pushed a fix again 2022-02-17 19:49:55 specifically an amendment to "tests: allow setting MESON_CI_JOBNAME=thirdparty" 2022-02-17 19:51:37 we are gradually getting there \o/ 2022-02-17 19:54:26 and the pkgconfig was uhh 2022-02-17 19:54:29 there is a diff of -lintl 2022-02-17 19:54:31 you can see it now 2022-02-17 19:55:03 same as before, we need -lintl for most things, but the test doesn't expect it- and pkgconf correctly returns -lintl for us 2022-02-17 19:55:28 echelon: I would expect apk to use etc/ssl/certs/ca-certificates.crt 2022-02-17 19:55:45 if is_windows() or is_cygwin() or is_osx() or is_openbsd(): 2022-02-17 19:55:47 # On Windows, libintl is a separate library 2022-02-17 19:55:49 deps.append(b'-lintl') 2022-02-17 19:56:17 is_alpine() hehe 2022-02-17 19:56:27 there is a plan to eventually move from gettext libintl to the musl-libintl header 2022-02-17 19:56:32 building against it does not need -lintl 2022-02-17 19:56:32 hmm, but 2022-02-17 19:56:34 ikke: i got it to work, i added the cert to /usr/local/share/ca-certificates/, and did update-ca-certificates 2022-02-17 19:56:48 echelon: right, makes sense 2022-02-17 19:56:53 musl does have a libintl, and meson might even use it as long as GNU libintl isn't *also* installed 2022-02-17 19:58:01 I assume that like the iconv case on FreeBSD, some people install the GNU version as an optional add-on simply because it is more featureful than the platform version? 2022-02-17 19:59:56 in this case i cannot remove it from the chain- musl-libintl conflicts with the gettext-dev header 2022-02-17 19:59:57 ... or occasionally they install it as a dependency for something else and then that contaminates/overrides the platform header 2022-02-17 20:00:11 and the entire world is built against the gettext version essentially, and is pulled in in the chain here 2022-02-17 20:00:28 so, -lintl mess is just the standard 2022-02-17 20:00:36 it's actually the biggest mess on python 2022-02-17 20:00:51 because python3 proper is not compiled against intl, and so the bindtextdomains thing is missing 2022-02-17 20:00:51 that does sound pretty annoying 2022-02-17 20:01:02 we have quite a few patches on py3- packages to try/catch the loading of that 2022-02-17 20:02:06 well, meson certainly cannot add an is_musl() case there, because musl doesn't imply GNU libintl. So if our testsuite did try to handle that, it would need to be is_alpine() 2022-02-17 20:03:23 so I guess just 2022-02-17 20:03:44 long term there is a plan to move to musl-libintl 2022-02-17 20:03:51 not sure what the actual actions to take are 2022-02-17 20:03:51 @unittest.skip('alpine has too much GNU libintl dependencies right now') 2022-02-17 20:03:56 yep 2022-02-17 20:04:30 i added a smily face for good measure 2022-02-17 20:05:25 ktprograms: thanks! 2022-02-17 20:07:11 Anyway, I submitted my first APKBUILD to the aports ML, but it isn't showing up. Is that because the list is moderated and I have to get approved, or is it just slow, or am I doing something wrong? 2022-02-17 20:08:17 Ah, it showed up, I guess I just had to wait 2022-02-17 20:21:28 psykose: you should update [PATCH 3/6] tests: allow setting MESON_CI_JOBNAME=thirdparty 2022-02-17 20:21:34 to fix the jsonschema error 2022-02-17 20:22:03 and after that 2022-02-17 20:22:10 it should finally pass! 2022-02-17 20:23:30 mended' 2022-02-17 20:24:43 alright, fingers crossed that the MR is now ready to merge 2022-02-17 20:26:02 do you think there is something to fix in the samu output expectation too, or is the current edit fine 2022-02-17 20:26:29 the current edit is probably fine 2022-02-17 20:26:57 I will think about that one, because in the current state of things I have fixed everything I'm *sure* is meson's responsibility to fix 2022-02-17 20:27:12 what happened here? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/634698 2022-02-17 20:27:22 the build runner seems to have done nothing and then said it's ok 2022-02-17 20:28:10 so as an MVP I think I'm happy with my current patchset to meson, and we can consider the samurai differences afterward 2022-02-17 20:28:19 the summary says its disabled for that arch 2022-02-17 20:28:28 >> testing/rust-analyzer: disabled for s390x 2022-02-17 20:28:30 BTW 2022-02-17 20:28:36 NINJA=samu NINJA_1_9_OR_NEWER=1 2022-02-17 20:29:00 let me guess, the latter is optional :) 2022-02-17 20:29:04 the latter is technically not needed, because if it isn't set then the testsuite will check it once (respecting $NINJA) 2022-02-17 20:29:11 sure 2022-02-17 20:29:21 Misthios: oh, oops, I disabled it myself, but I had a brainfart and read that as "testing is disabled" 2022-02-17 20:29:53 on the other hand, setting it means you skip a fork+exec to samu --version 2022-02-17 20:30:26 that is probably a 0.1s difference 2022-02-17 20:32:14 well, yes... 2022-02-17 20:32:45 Also, there is a typo in the build runner output, but I assume that is a gitlab thing: "Handeling artifacts" 2022-02-17 20:37:22 sm2n: heh, yes. Was wondering when someone would notice :) 2022-02-17 20:38:53 sm2n: and no, it's our CI script 2022-02-17 20:39:48 hah, I see 2022-02-17 20:40:06 This is gitlab: "Uploading artifacts as "archive" to coordinator" 2022-02-17 20:41:27 so, the coloured text? 2022-02-17 20:43:16 Well, that part I quoted is the default color 2022-02-17 20:44:13 there are multiple typos 2022-02-17 20:44:23 i haven't fixed them because i prefer them 2022-02-17 20:44:24 :) 2022-02-17 20:44:41 lol 2022-02-17 20:44:49 ha 2022-02-17 20:44:52 maybe we should pick a random language each time too 2022-02-17 20:44:55 all typos can be blamed on me :P 2022-02-17 20:44:59 :p 2022-02-17 20:45:12 where is the dutch runner output 2022-02-17 20:45:13 get on it 2022-02-17 20:45:30 People would get soar throats 2022-02-17 20:45:47 sore? :p 2022-02-17 20:45:50 more typos! 2022-02-17 20:45:51 :D 2022-02-17 20:45:53 yes, sore 2022-02-17 20:45:58 See 2022-02-17 20:46:11 moar typos 2022-02-17 20:46:27 typoes evrywhere 2022-02-17 20:47:23 tpyos 2022-02-17 20:47:56 this meson ci sure do be passing 2022-02-17 20:48:09 didn't think we would get here 2022-02-17 20:49:06 well, I put myself on the job, so I had absolute confidence it would work out 2022-02-17 21:19:59 psykose: should I be waiting for the x86/armhf jobs to complete? I'm a little confused because gitlab says there are no running jobs but stuff is still queued up 2022-02-17 21:20:23 sm2n: there is a backlog atm 2022-02-17 21:20:50 ceph and pypy building at the same time 🥲 2022-02-17 21:21:10 that doesn't show up on gitlab? 2022-02-17 21:21:22 Where would you expect to see that? 2022-02-17 21:21:24 2022-02-17 21:21:36 They are running in the scope of the forks 2022-02-17 21:21:57 where can I see that? 2022-02-17 21:22:10 https://gitlab.alpinelinux.org/Dekedro/aports/-/jobs?scope=running 2022-02-17 21:22:14 You'd have to know 2022-02-17 21:22:19 I can see them all in the admin backend 2022-02-17 21:22:45 oh, ok 2022-02-17 21:22:50 I feel always bad just fixing some whitespaces on pypy-stage0's APKBUILD :-O 2022-02-17 21:23:34 i sometimes wish i could see all the jobs 2022-02-17 21:23:42 liske: to be fair it is done and builds 2022-02-17 21:23:45 you can just cancel the ci 2022-02-17 21:23:49 i can probably just merge it 2022-02-17 21:24:09 if ikke says it looks good then we are done :) 2022-02-17 21:24:44 it's just Big so i want a +1 opinion 2022-02-17 21:24:54 Let me take a look 2022-02-17 21:32:26 psykose: nice, 4 passes and 2 pending. I don't know why armv7 failed exactly one test unit, though I did ping the meson maintainer for cmake-related integrations 2022-02-17 21:34:48 i think i saw the same failure before, no idea what caused it or why it went away 2022-02-17 21:36:47 well, it *is* cmake after all 2022-02-17 21:37:42 easy solution: just remove cmake from the list, so it doesn't run that check 2022-02-17 21:37:42 :P 2022-02-17 22:35:11 anyone accepting MRs for 3.15-stable ? 2022-02-17 22:36:51 echelon: not "anyone" but "the one!" ;) and keep in mind older still supported releases 2022-02-17 22:37:24 oh, i'm new here :/ 2022-02-17 22:41:32 they are accepted sure 2022-02-17 22:41:37 depends on the changes 2022-02-18 00:08:39 psykose: it says Habbie cannot merge 2022-02-18 00:08:47 yes 2022-02-18 00:08:50 but i can 2022-02-18 00:09:21 he normally updates pdns himself 2022-02-18 00:09:36 oh, ok.. should we wait for his approval? 2022-02-18 00:10:01 yeah, that is what i mean 2022-02-18 11:08:41 ikke: hey guess what, you need to manually copy a tree tarball again :) 2022-02-18 11:28:19 Can I get another hint? 2022-02-18 11:28:26 tree on the x86 builder 2022-02-18 11:28:29 since it is ip blocked 2022-02-18 11:28:31 ah 2022-02-18 11:28:37 just like all the other times 2022-02-18 11:28:50 hint provided 2022-02-18 11:29:00 I read tree as a general term 2022-02-18 11:29:10 rather than the name of an application 2022-02-18 11:29:52 yes 2022-02-18 11:29:58 i was not being particularly descriptive 2022-02-18 11:57:10 psykose, echelon, i approved !31048 2022-02-18 11:57:43 psykose, thanks! 2022-02-18 11:57:46 :) 2022-02-18 11:58:04 echelon, and thanks, too 2022-02-18 12:15:40 I put up a v2 APKBUILD to the ML last night and the bot still has not picked it up... Could someone check if I did something wrong? and , respectively 2022-02-18 12:18:47 you can't update the same mr, you need to send a new one 2022-02-18 12:18:59 this is also why i don't recommend the ML at all 2022-02-18 12:22:15 oh, that sucks, I'll do that then 2022-02-18 12:22:26 Where is the source code for the bot? 2022-02-18 12:22:52 ddevault would know, as well as the reasons for the update not being integrated 2022-02-18 12:22:56 Part of source hut 2022-02-18 12:23:01 Dispatch 2022-02-18 12:23:02 i forget the technical issues 2022-02-18 12:23:25 sm2n: new versions should be in a new thread 2022-02-18 12:23:33 this is like the 10th time i have to tell someone the update doesn't work and they need a new patch 2022-02-18 12:24:19 ddevault: Can I "close" the old thread when I post the new one? Or how does that work 2022-02-18 12:24:26 just abandon it 2022-02-18 12:24:32 i will close it 2022-02-18 12:24:36 it'll be auto-closed when the gitlab MR is closed 2022-02-18 12:24:44 okay, I see 2022-02-18 13:01:44 ikke: i think chromium is probably stuck on x86_64, could you cycle it 2022-02-18 13:56:09 or i guess it just took 3x the normal time 2022-02-18 14:22:49 psykose: any remaining issues in the meson testsuite MR? 2022-02-18 14:22:56 just the cmake thing failing 2022-02-18 14:23:10 fails on all the arm arches now 2022-02-18 14:23:19 everything else is green 2022-02-18 14:25:34 (cmake can go jump in a lake) I guess we'll see what mensinda thinks about that failure, so hopefully within a few days 2022-02-18 14:25:43 sure, sounds good to me 2022-02-18 14:26:04 then i can bother fcolista about seeing if it makes sense :) but at least we know how to run most of the test suite at all 2022-02-18 14:26:10 and nailed some minor upstream issues in the process 2022-02-18 14:26:55 Yep, that intl thing was a pain 2022-02-18 14:27:03 looked like it :p 2022-02-18 14:49:28 why does setup-alpine -f $answerfile asks for confirm? 2022-02-18 14:50:53 it sounds like it shouldn't 2022-02-18 14:51:06 indeed.. 2022-02-18 14:51:06 so should probably be changed, or at least a flag for it 2022-02-18 15:02:30 clandmeter, re: setup-alpine answer file....looking at the script, this possibility has been implemented 2022-02-18 15:02:31 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in#L52 2022-02-18 15:02:41 commit a684ec45184afa92f60c41f450c1d4afa3833ac0 2022-02-18 15:02:41 Author: Lukas Bestle 2022-02-18 15:02:41 Date: Sat Jul 10 16:01:29 2021 +0200 2022-02-18 15:03:13 i mean the possibility to get the answer file via http url 2022-02-18 15:03:28 yes 2022-02-18 15:03:48 i also applied two fixes 2022-02-18 15:03:54 and backported them 2022-02-18 15:04:08 <3 2022-02-18 15:04:10 but its not in a release 2022-02-18 15:04:18 so you need to get it from repo 2022-02-18 15:04:26 ok so, how this can be used? 2022-02-18 15:04:30 time to release :) 2022-02-18 15:04:30 I mean 2022-02-18 15:04:57 depends what you want to do 2022-02-18 15:05:01 i need an apkovl with a local script that runs setup-alpine -f http://$myurl 2022-02-18 15:05:34 so I need a custom apkovl to pass to the ISO that does this, if I want this setup being done automatically? 2022-02-18 15:05:54 and you need an iso with fixed alpine-conf 2022-02-18 15:06:58 yes, well, that can be part of the custom apkovl as well :D 2022-02-18 15:07:13 not sure an apkovl is designed to do it 2022-02-18 15:07:28 no, that would be done in the local script 2022-02-18 15:07:38 what is your end goal? 2022-02-18 15:07:40 wget the alpine-conf master 2022-02-18 15:07:46 have an unattended setup 2022-02-18 15:09:49 i guess its possible with apkovl 2022-02-18 15:11:20 I think that there are several way to accomplish this...but all of them are quite hackish 2022-02-18 15:11:25 You might as well generate an ovl that has the settings you want 2022-02-18 15:11:44 but he wants to install to disk i guess 2022-02-18 15:12:00 oh, right 2022-02-18 15:12:19 yes 2022-02-18 15:13:24 what you want is the answerfile in the iso and exec setup-alpine 2022-02-18 15:13:49 so if you want to do this via an url you also need network 2022-02-18 15:14:03 in the end, I think that the possibility to have a yaml/json/whatever took via network or via mountpoint and have it used to setup alpine, is something to be considered 2022-02-18 15:14:32 but you still need network which is not possible atm 2022-02-18 15:14:51 clandmeter, yes, you need network of course if you want to pass it via http/ftp 2022-02-18 15:14:54 fcolista: similar to how cloud-init gets its network and user-data config on 1st boot 2022-02-18 15:15:16 we have network support in initramfs 2022-02-18 15:15:18 but might be useful to pass it via mountpoint 2022-02-18 15:15:30 but you need network support in the init for that 2022-02-18 15:15:36 which our iso does not have 2022-02-18 15:15:46 i was thinking of adding network support to firstboot initd 2022-02-18 15:17:21 alpine netboot with pxe could have this as well 2022-02-18 15:19:05 i was able to get an unattended setup with alpine netboot 2022-02-18 15:19:38 but I had to rely on a custom apkovl which runs a binary that does the work (alpine lift, i spoke a while ago) 2022-02-18 15:23:21 fcolista: alpine-lift is a cloud-init alternative. I did chat with tomalok recently about adding support for loading NoCloud-style configuration (from ISO image or VFAT filesystem) to tiny-cloud 2022-02-18 15:25:22 minimal, I was looking to the link you posted a while ago on cloud-init 2022-02-18 15:25:27 thanks! 2022-02-18 15:25:42 Still you need a custom, pre-prepared image 2022-02-18 15:26:31 fcolista: I'll be the first to admit that cloud-init is (relatively) large as it is Python-based. alpine lift and tiny-cloud are alternatives that are more lightweight (though with less functionality) 2022-02-18 15:27:02 alpine-lift it's just a single GO binary that can be easily installed and run jsut withing an apkovl 2022-02-18 15:27:09 yes, general cloud-init and its alternatives are intended to be part of a pre-prepared image and they provide (mainly) 1st time boot configuration 2022-02-18 15:27:27 yeah 2022-02-18 15:27:40 I've not seen tiny-clout though 2022-02-18 15:27:50 fcolista: tiny-cloud is just Shell based (mainly depending on busybox tools but may need some additional non-busybox stuff too) 2022-02-18 15:29:24 the best thing would be supporting this kind of features directly within alpine 2022-02-18 15:29:54 tiny-cloud is a recent package, its a derivative of the previous tiny-ec2 stuff. tomalok is the guy to talk to about it 2022-02-18 15:31:24 i was dreaming about a var "cloud=https://$unattended_data" directly from the boot loader 2022-02-18 15:32:23 where $unattended_data is a structured data file with the various options allowing an unattended installation, like the answer file 2022-02-18 15:32:41 fcolista: well something like alpine-lift/cloud-init/tiny-cloud could be used to handle this if it was part of the base run-from-ram Alpine images 2022-02-18 15:34:05 fcolista: cloud-init uses YAML files like user-data to specify users/groups to create, packages to install, etc 2022-02-18 15:34:40 hi all, i'm getting 'file format error' on edge after update of apk-tools 2022-02-18 15:34:52 are you on <3.12 2022-02-18 15:35:04 that would open the door to a full provisioning of an alpine host 2022-02-18 15:35:23 fcolista/minimal: i've been (slowly) working on a simple/shell yaml extractor tool that will help tiny-cloud implement nocloud (and other things) 2022-02-18 15:35:36 psykose, it was related to apk-tools error? 2022-02-18 15:35:48 indy: can you post your /etc/apk/repositories 2022-02-18 15:36:10 psykose, i can't it is our corporate jfrog :) 2022-02-18 15:36:17 ok, have a good day :) 2022-02-18 15:37:19 the only thing i can think of is https://gitlab.alpinelinux.org/alpine/aports/-/issues/13523 2022-02-18 15:37:28 but that is caused by having edge repos on <3.12 2022-02-18 15:37:33 which is not supported 2022-02-18 15:37:52 both for <3.12 being completely unsupported now, and mixing edge with stable isn't :) 2022-02-18 15:38:42 no it is edge based builder for azure devops pipelines i created yesterday 2022-02-18 15:38:49 or 2 days ago 2022-02-18 15:39:00 fcolista: what i recently hacked into an iso is a check for ip=dhcp in firstboot and enable network if init didnt do it already 2022-02-18 15:39:00 fcolista: have a look here at the sorts of things cloud-init's user-data YAML supports: https://cloudinit.readthedocs.io/en/latest/topics/examples.html 2022-02-18 15:39:02 what is apk --version 2022-02-18 15:39:14 this way you can have ssh_key= and have ssh started on boot 2022-02-18 15:39:25 or rather `apk info apk-tools` 2022-02-18 15:41:03 minimal, yeah is basically a complete way to provisioning an host. 2022-02-18 15:42:20 psykose, apk-tools 2.12.7 passed, after apk upgrade 2.12.9 errors (2.12.7-r0 -> 2.12.9-r1) 2022-02-18 15:42:39 clandmeter, firstboot already looks for http(s)|ftp(s) for ssh 2022-02-18 15:42:42 fcolista: we could add support for answerfile in cmdline 2022-02-18 15:43:01 hm 2022-02-18 15:43:03 and this can be done for answerfile as well, right 2022-02-18 15:44:37 psykose, i have to go for now, i'll check backlog 2022-02-18 15:44:54 indy: no idea then :) you can try open an issue, but you will need to post more info 2022-02-18 15:46:04 psykose, :) i'll try to dig deeper 2022-02-18 15:46:19 psykose, anyway thanks, at least for rustfmt :) 2022-02-18 15:46:28 oh? 2022-02-18 15:47:15 :) 2022-02-18 15:47:38 fcolista: yes, cloud-init is what is used by AWS, Azure, GCE, etc - you create a cloud instance (i.e. VM) using a Debian/Ubuntu/etc base image which is already cloud-init-enabled and you provide user-data that is run when that instance boots to set things up the way you want 2022-02-18 15:58:08 sounds goo 2022-02-18 15:58:09 good 2022-02-18 16:30:26 cloud-init is bloatware 2022-02-18 16:31:25 ncopa had the idea of implementing something that is more lightweight but compatible with the cloud-init syntax 2022-02-18 16:31:50 tomalok created tiny-cloud 2022-02-18 16:33:26 I'm working on a related proof-of-concept on easily managing farms of PXE-booting hosts in data center 2022-02-18 16:39:01 kunkku i'm working on improving cloud-init compatibility 2022-02-18 16:43:24 i'm having CI issue with two packages, the first one is an update but changes version number (downgrades), so when the second one builds it takes the one from the repo https://gitlab.alpinelinux.org/bl4ckb0ne/aports/-/jobs/635839 2022-02-18 16:43:37 is there a way to treat the version change as an upgrade? 2022-02-18 16:45:13 bl4ckb0ne: apk always compares versions absolutely 2022-02-18 16:45:32 there is atm no way to say a lower version should be considered newer 2022-02-18 16:45:42 dammit 2022-02-18 16:46:14 so ci is bound to fail unless i make 2 seperate pull requests 2022-02-18 16:46:20 yes 2022-02-18 16:46:24 lovely 2022-02-18 16:46:30 and wait sufficiently long for the repos to update 2022-02-18 16:46:43 this spirv stuff is lots of fun 2022-02-18 18:30:39 if I have two packages, foo1 and foo2 (two implementations of the same software foo), and foo1 is arch="!aarch64" and foo2 is arch="aarch64", both provide foo-dev, is abuild not smart enough to build the correct one when another package requires foo-dev? 2022-02-18 18:31:25 zv: you tell abuild what to build 2022-02-18 18:31:47 note that makedepends cannot be virtual 2022-02-18 18:32:15 when another package, bar, is built with abuild -R, what do I need to do then? manually build foo1 or foo2 first? 2022-02-18 18:32:29 -R is not supported anymore afaik 2022-02-18 18:32:35 oh! this is news to me. 2022-02-18 18:32:58 It's not something new 2022-02-18 18:33:52 buildrepo replaced abuild -R 2022-02-18 18:36:47 ACTION reads scrollback 2022-02-18 18:36:57 everyone's netbooting alpine this week, huh? (also me) 2022-02-18 18:38:12 i ran into a networking corner I had to work around, worth mentioning -- I had an apkovl (answerfile is just the same) to setup a bridge interface on br0, but this was broken until eth0 lost its own temporary IP gotten by ip=dhcp 2022-02-18 18:38:27 I had to make that happen with `pre-up ip addr flush dev eth0` in the br0 config stanza 2022-02-18 18:40:06 (eth0 was a port on the new bridge, to be clear) 2022-02-18 18:40:14 Does busybox provide ifupdown by default? 2022-02-18 18:41:56 ebb: yes 2022-02-18 18:43:05 ebb: for the time being 2022-02-18 18:44:11 yeah I guess ifupdown-ng may be added to initramfs at some point in time 2022-02-18 18:47:22 iirc the actual problem was probably route metrics -- both eth0 and br0 holding addresses in the same subnet, but eth0's src address for the local subnet being preferred 2022-02-18 18:47:36 I couldn't ping it on the br0 address from local subnet, although not on the eth0 address either 2022-02-18 18:48:44 If it's _always_ invalid for a bridge port to hold an address on its own interface, even in the most esoteric use case, it's probably something that needs fixing in busybox 2022-02-18 19:00:07 minimal: whoa whoa whoa 2022-02-18 19:00:20 this sounds like a cool idea 2022-02-18 19:00:28 but i'm not sure how we would impement it 2022-02-18 19:08:01 Ariadne: you provided me the chopin script right? 2022-02-18 19:09:45 yes 2022-02-18 19:10:09 Ariadne: I think I have found a bug, I thought I had fixed it, but I didn't. 2022-02-18 19:10:21 Ariadne: CHOPIN_ARCH suggest that I could use aarch64 2022-02-18 19:10:47 But when fetching, it seems that under all circumstances it downloads the same file as for x86_64 2022-02-18 19:11:12 so I provided --arch, busybox filesize remained the same. 2022-02-18 19:11:39 (md5 too) 2022-02-18 19:12:04 like I said, --arch does not help 2022-02-18 19:13:20 ikke: sorry missed your message from the other window 2022-02-18 19:13:50 you cannot use apk to fetch packages for a different arch 2022-02-18 19:14:00 ikke: that seems... stupid? 2022-02-18 19:14:40 I suppose the reason is to prevent corrupting the system 2022-02-18 19:15:12 ikke: if a user is explicitly setting a parameter to override, that protection sounds 'nice' but is not 2022-02-18 19:15:47 ikke: there is a way, but it involves making a custom apk subroot 2022-02-18 19:15:49 ikke: I am basically corrupting my arm system over and over again because I assumed this would have behaved as instructed 2022-02-18 19:16:07 Ariadne: yes, I mentioned that in #alpine-linux 2022-02-18 19:16:28 skinkie: i've only ever used it in a qemu environment, something something, as is, no warranty, pls don't sue me 2022-02-18 19:16:43 Ariadne: obviously I want to improve the product :) 2022-02-18 19:16:52 you can have the product :D 2022-02-18 19:17:02 my use case for that thing has long since passed :P 2022-02-18 19:17:15 Ariadne: your hint of subroot, I understand since I watched the init stuff 2022-02-18 19:17:39 Ariadne: you basically say use --sysroot, have a different /etc/apk/arch there? 2022-02-18 19:17:53 yeah 2022-02-18 19:21:52 Ariadne: Doesn't not work... yet. 2022-02-18 19:22:03 apk fetch --root sysroot-aarch64 2022-02-18 19:22:25 skinkie: did you add --arch? 2022-02-18 19:22:28 and --initdb 2022-02-18 19:23:08 ikke: i copied /etc/apk to sysroot-aarch64/etc/apk change arch in the file 2022-02-18 19:23:18 you have to use --initdb 2022-02-18 19:23:21 and set up your repos 2022-02-18 19:23:23 and so on 2022-02-18 19:28:11 are CMAKE_CROSSOPTS important to keep? 2022-02-18 19:30:00 I first do apk add --root sysroot-aarch64 --initdb --arch aarch64 2022-02-18 19:30:09 then attempt: pk fetch --root sysroot-aarch64 -o out/radioscherm/aarch64 --repository http://dl-cdn.alpinelinux.org/alpine/e 2022-02-18 19:30:31 WARNING: Ignoring .... No such file or directory 2022-02-18 19:47:33 bl4ckb0ne: yes 2022-02-18 19:47:56 bl4ckb0ne: without them, it makes adapting the package to support cross compilation a pain later 2022-02-18 19:52:47 dumbly removed them 2022-02-18 19:52:51 time to amend 2022-02-18 19:53:09 im messing with khronos stuff today and found a lot of packages without maintainer 2022-02-18 19:53:13 is it ok if I adopt them? 2022-02-18 19:53:22 yes 2022-02-18 20:13:28 _alice: fyi I got rpcs3 to compile but it segfaults when loading a game 2022-02-18 23:19:34 does anyone know if "fixup_namespace_packages" is still needed on modern python+setuptools? 2022-02-18 23:20:19 importing pkg_resources itself seems to be broken at times (see: https://github.com/pypa/setuptools/issues/2466) and pytest seems to use it a lot in its own tests, which all subsequently fail 2022-02-19 01:50:54 ddevault: as in your own and not the one in packages for x86_64? are you also starting it with GDK_BACKEND=x11? also that account is not me :) 2022-02-19 01:51:24 different alice 2022-02-19 07:09:57 gah, so many alices 2022-02-19 07:10:07 and yes, as in I built it myself from master 2022-02-19 07:10:24 and it's Qt, not GTK 2022-02-19 07:10:54 lemme try it with QT_QPA_PLATFORM=xcb... 2022-02-19 07:16:17 it gets further and then segfaults 2022-02-19 07:19:50 try building rpcs3 with large thread stack size 2022-02-19 07:20:04 it is probably assuming that there is at least 1MB of stack available 2022-02-19 07:20:11 a lot of vulkan stuff does this ive noticed 2022-02-19 07:22:27 ah, if you are building the qt thing, then no idea 2022-02-19 07:22:32 i can try experiment too if you wish 2022-02-19 07:22:43 the repo one has it disabled, as it needed like a bundled sdl2 as well 2022-02-19 07:22:47 no system option 2022-02-19 07:22:50 so i passed for a bit 2022-02-19 07:22:54 gimme a few moment 2022-02-19 07:23:07 psykose: to be clear 2022-02-19 07:23:13 I'm talking about rpcs3, the PS3 emulator 2022-02-19 07:23:23 not pcsx2, the PS2 emulator, which you packaged the other day 2022-02-19 07:23:41 your pcsx2 package has been working great for me, thanks :) 2022-02-19 07:23:47 oh my god 2022-02-19 07:23:50 i totally misread that 2022-02-19 07:23:55 gah 2022-02-19 07:24:51 no worries 2022-02-19 07:25:06 you can try just ulimit a 2MB stack and see if that works 2022-02-19 07:25:48 i also noticed that, i built rpcs3 the other month, and it segfaults on start of any disk 2022-02-19 07:25:58 didn't investigate more, i'll do when i have some time 2022-02-19 07:36:34 no suck luck 2022-02-19 07:36:39 likewise will investigate more later 2022-02-19 07:37:52 maybe even more alices will show up and fix this 2022-02-19 07:38:06 if we could be so lucky 2022-02-19 07:40:02 it needs to be -Wl,-z,stack-size 2022-02-19 07:40:16 ulimit won't influence thread stack size (default 128KB) 2022-02-19 07:41:07 ah 2022-02-19 07:41:38 i forget if most cmake projects would respect arbitrary ldflags, so hopefully it's that easy 2022-02-19 07:43:22 I set it in the LDFLAGS environment out of the vague hope that it would do the thing and I would not have to read any cmake documentation 2022-02-19 07:46:25 afaik its something like 2022-02-19 07:46:27 -DCMAKE_EXE_LINKER_FLAGS_RELEASE_INIT="$LDFLAGS -Wl,-z,stack-size=2097152" 2022-02-19 07:47:38 just CMAKE_EXE_LINKER_FLAGS would suffice, but i would guess they are initialised from LDFLAGS anywya 2022-02-19 07:48:38 i mean 2022-02-19 07:48:40 its cmake 2022-02-19 07:48:57 assuming reasonable behaviour might be too hopeful 2022-02-19 07:49:56 yeah, it does use LDFLAGS 2022-02-19 07:50:05 neat 2022-02-19 07:50:26 probably not the stack then 2022-02-19 10:29:48 ddevault: Did you see my question about the status of osu!web? 2022-02-19 10:32:00 Yes. I'm not going to answer it. Please don't bother me in any other channels 2022-02-19 10:32:29 ddevault: Sorry about that, where should I have asked you? 2022-02-19 10:32:52 email, if anything, but better to not bother me about 7-years-abandoned projects at all 2022-02-19 10:33:18 ddevault: Ok, sorry 2022-02-19 10:33:50 ddevault: You could have let ktprograms know that in a bit of a nicer way 2022-02-19 10:34:13 sorry, you're right 2022-02-19 10:34:20 that was not very cute 2022-02-19 10:34:21 I felt that the unsolicited PM earlier was a bit rude 2022-02-19 10:35:40 ddevault: Sorry, it was because you aren't on #alpine-offtopic and I didn't want to clutter this channel 2022-02-19 13:06:14 hi, could someone try 'apk add wireless-tools' in a v3.15-armv7 setup, please ? 2022-02-19 13:06:19 I am getting msgs like: "package mentioned in index not found" 2022-02-19 13:06:33 maybe a re-index needed 2022-02-19 13:13:51 vkrishn: no issue here 2022-02-19 13:14:47 https://tpaste.us/xn7l 2022-02-19 13:15:14 vkrishn: what have you got in /etc/apk/repositories ? 2022-02-19 13:15:20 vkrishn: Is your mirror up to date? You can check on https://mirrors.alpinelinux.org 2022-02-19 13:17:11 http://dl-4.alpinelinux.org/alpine/v3.15/main/ in /etc/apk/repositories 2022-02-19 13:17:42 /media/usb/apks works ok 2022-02-19 13:20:25 I would give a retry, seems other APKINDEX is same 2022-02-19 13:21:31 vkrishn: works with dl-4 for me as well 2022-02-19 13:21:36 vkrishn: what will happen if you comment /media/usb stuff and leave only dl-4 mirror? after edit run apk update 2022-02-19 13:24:37 commenting out /media/usb/apks , then works 2022-02-19 13:25:04 wasn't a problem in v3.9.6 2022-02-19 14:13:02 ok, solved, usual thing, /media/usb/apks is old, while dl-4.alpinelinux.org got updated 2022-02-19 14:13:14 like openssl-1.1.1l-r7.apk openssl-1.1.1l-r8.apk 2022-02-19 14:13:18 thanks 2022-02-19 15:38:50 if I want to revert a package upgrade because it's having a large regression, what do I need to besides reverting the commit? I'm fine with users needing to `apk upgrade` with the `--available` switch, will it just work? No caching problems or anything? 2022-02-19 15:41:35 i think so. assuming it's a leaf package 2022-02-19 15:52:00 a leaf package? 2022-02-19 15:53:11 if it has reverse dependencies that were rebuilt then obviously those will need a manual re-rebuild 2022-02-19 16:22:13 PureTryOut: bump pkgrel to something new 2022-02-19 16:22:21 so that the new package is unique 2022-02-19 16:30:18 yes, that is the better solution. i guess rolling it back has the other issue that if the dependencies have changed, there may be two copies of the pvr floating around 2022-02-19 16:47:16 ikke: ah yes thanks, that's the tip I was looking for 2022-02-19 16:57:53 PureTryOut: fyi, it's not to make sure the package is built, it's just to make sure dl-cdn is not serving the previous cached package 2022-02-19 16:58:18 ah yeah true 2022-02-19 17:02:34 well it's not only dl-cdn, it may be cached in local proxies or apk cache 2022-02-19 17:03:25 i think apk cache checks only valid signature and pvr, not whole tarball signature 2022-02-19 17:03:33 s/signature$/checksum/ 2022-02-19 17:08:11 need to restart gitlab real quick 2022-02-19 17:09:36 was about to ask what happened to gitlab :p 2022-02-19 17:56:14 does the musl dns resolver cache results? I poked around in getaddrinfo and __lookup_name, and it doesn't seem to. but I am seeing behavior with some basic things (like ping) that suggest it might be somewhere/somehow 2022-02-19 17:59:22 ping surely caches results though 2022-02-19 18:11:41 neither glibc, nor musl cache dns reponses 2022-02-19 19:20:06 wasn't that "traditionally" the preserve of nscd 2022-02-20 00:19:32 MR !31155 is stuck signing indexes for gprc, restarting made no difference 2022-02-20 00:22:05 aye, just looks like a classic case of broken ci 2022-02-20 00:22:09 but everything passes, so all good 2022-02-20 00:22:56 was trying to rebuild arrow and bear as well, shall I drop those and do in a separate MR? 2022-02-20 00:23:18 same mr 2022-02-20 00:23:46 they already are, but don’t currently get built as it’s stuck on arrow 2022-02-20 00:24:09 stuck on grpc 2022-02-20 00:24:43 oh right, just noticed it's the in-between signing and not the final one 2022-02-20 00:25:14 yes thats what I meant 2022-02-20 00:26:04 mhm 2022-02-20 00:26:25 normally i would expect that on only one arch... all of them seems strange 2022-02-20 00:27:46 yes, it did have sudo as a checkdepends but I removed that and in made no difference and doesn’t error out with it so might have been skipped anyway now 2022-02-20 00:30:27 at a guess, it is almost certainly the operation *after* the logged operation. i call it a "Mup.sys hang" 2022-02-20 00:31:14 i guess probably checkapk is stuck 2022-02-20 00:31:52 makes sense 2022-02-20 00:32:41 package should be mostly the same 2022-02-20 00:57:29 psykose: the meson testsuite fixes are now merged! 2022-02-20 00:57:34 i saw ^~^ 2022-02-20 00:57:43 grats 2022-02-20 00:57:48 shall we get out the champagne 2022-02-20 00:57:53 I just did it seconds ago :D 2022-02-20 00:57:56 yes 2022-02-20 00:58:04 :3 2022-02-20 10:49:16 Ariadne: what's the status on the gcc snapshot update? I noticed you updated the alpine/11.2 branch in your repo already but you haven't yet updated main/gcc in aports? just pinging this again because I want to make sure that we integrate the upstream changes to the -fsplit-stack patch asap 2022-02-20 13:45:47 nmeum: the backports don’t work 2022-02-20 13:45:56 i’m missing something 2022-02-20 13:46:00 dunno what :) 2022-02-20 13:46:32 but gcc-go bombs out with fsplit-stack 2022-02-20 14:35:55 psykose, https://dpaste.org/6Jyr 2022-02-20 14:36:27 psykose, reproduce for jfrog issue 2022-02-20 14:47:34 indy, what software is generating the index for that repo? it seems to have properties that aren't recognized by modern apk 2022-02-20 14:59:19 apk assumes that any unrecognized fields are actually features it doesn't even support, thus this error: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/package.c#L567 2022-02-20 15:01:17 ptrc: artifactory 2022-02-20 15:01:57 Which is an application to host all kinds of repositories 2022-02-20 15:02:59 You upload the packages, and it creates the repositories 2022-02-20 15:03:00 yeah, found that in the backlog 2022-02-20 15:03:36 it doesn't look like the alpine repo addon is open source though, or i can't find it 2022-02-20 15:04:49 No it's most likely not 2022-02-20 15:05:47 artifactory is terrible 2022-02-20 15:05:55 i'm building something better ^_^ 2022-02-20 15:06:40 That's easy, build it anything else but Java :-P 2022-02-20 15:14:10 artifactory can also build APKs, and that is terrible too 2022-02-20 15:26:45 hm, looks like between 2.12.7 and 2.12.9 apk has been made a bit more strict with broken packages 2022-02-20 15:33:03 found the specific commit: https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/ff8f5452d7f9e08a6d33713ae76aad573657737e 2022-02-20 15:33:22 so it looks like artifactory generates invalid tar files too 2022-02-20 15:46:41 ptrc, ikke yes jfrog artifactory. it works with edge before apk 2.12.9 2022-02-20 15:47:43 Ariadne, keep me informed :) 2022-02-20 16:09:46 whew, finally tracked down why it's incompatible with artifactory's tars 2022-02-20 16:09:47 https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/100 2022-02-20 16:26:05 uh, did something get corrupted on the builder? qt5-qtdeclarative on x86_64 edge has a bad signature 2022-02-20 16:30:23 not only x86_64, it seems to return "bad signature" on all architectures 2022-02-20 17:00:46 On all mirrors or just dl-cdn? 2022-02-20 17:10:10 ptrc: nice catch :) 2022-02-20 17:10:17 also, boo @ artifactory 2022-02-20 17:22:49 ikke: dl-4 works fine, so probably just dl-cdn 2022-02-20 17:24:23 You can purge it with repo-tools in edge/testing 2022-02-20 17:25:29 Something like repo fastly purge --origin qt5-qtdeclarative --repo community 2022-02-20 17:31:58 oh, thanks, i didn't know such thing even existed 2022-02-20 17:32:18 seems like it worked 2022-02-20 17:35:29 hm, i didn't think through signature checking. i guess with the current builder system, and non-reproducible apks, packages must never be downgraded 2022-02-20 17:37:41 yes, pkgrel must always be +1 on a downgrade 2022-02-20 17:40:20 Ariadne, also interested in a better artifactory here! I'll follow keenly... 2022-02-20 17:40:53 parts already exist, e.g. Tekton 2022-02-20 17:45:06 ah, I saw this come up on the orange leaderboard I think 2022-02-20 17:45:26 oh no 2022-02-20 17:45:30 not orange site 2022-02-20 17:45:39 can't recall 2022-02-20 17:46:34 I came across it _somehow_, and it's actually probably that way 2022-02-20 17:46:37 *probably not 2022-02-20 21:13:34 Ariadne: hmhm, interesting. can you share an error message for the gcc-go error? 2022-02-20 21:16:35 might be neccessary to also backport https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2c31a8be4a5db11a0a0e97c366dded6362421086 (somehow the upstream inclusion process was a bit messy) 2022-02-20 21:21:49 it doesn't fix it either 2022-02-20 21:22:22 what's the error? (: 2022-02-20 21:22:26 we were discussing backports while i was trying the same on gcc-12 and she tried that commit 2022-02-20 21:22:30 uhh, i think the same 2022-02-20 21:23:14 https://img.ayaya.dev/PP1hkxsaPq5F.png 2022-02-20 21:23:27 both without and with that 2022-02-20 21:23:46 hmhm, go1 should catch that error message 2022-02-20 21:23:58 it has a regex for matching that specific error message somewhere in the code 2022-02-20 21:24:21 perhaps something was accidentally skipped or applied incorrectly 2022-02-20 21:24:25 such is life with patchsets 2022-02-20 21:25:25 this is an upstream patch though :p 2022-02-20 21:26:37 https://github.com/gcc-mirror/gcc/blob/master/libgo/go/cmd/go/internal/work/exec.go#L2615-L2622^F 2022-02-20 21:26:47 this is where go1 should do special handling for this error message 2022-02-20 21:26:52 https://github.com/gcc-mirror/gcc/blob/master/libgo/go/cmd/go/internal/work/exec.go#L2615-L2622 2022-02-20 21:26:58 > // For -fsplit-stack GCC says "'-fsplit-stack' is not supported". 2022-02-20 21:28:06 maybe it is confused by the additional "only supported on GNU/Linux" or something? 2022-02-20 21:30:37 it checks for "is not supported" which is in the output 2022-02-20 21:30:58 hmm 2022-02-20 21:31:29 but "is not supported" doesn't match "currently only supported on GNU/Linux" 2022-02-20 21:31:41 idk, I have to start building gcc again to meaningfully debug this 2022-02-20 21:31:48 ah, it has to match both lines? 2022-02-20 21:32:06 I am not sure 2022-02-20 21:32:20 doesn't seem to be per-line 2022-02-20 21:34:26 I will start a gcc build 2022-02-20 21:34:30 yea 2022-02-20 21:34:33 you would know more than me :) 2022-02-20 22:32:27 hm, yeah I can reproduce it too. will try to figure out why the feature detection code in exec.go for -fsplit-stack doesn't work 2022-02-20 23:57:48 yeah i ran out of time to investigate it friday night 2022-02-21 00:02:23 maybe add !bytes.Contains(out, []byte("GNU/Linux")) && 2022-02-21 00:03:15 but 2022-02-21 00:03:24 the others should already catch it 2022-02-21 00:16:36 split-stack should not be used 2022-02-21 00:19:36 is the problem that it's failing to detect that it's not supported and should not be used? 2022-02-21 00:21:01 ah lovely i think i see what's going on 2022-02-21 00:27:00 yes, split-stack should not be used 2022-02-21 00:27:06 so we made it impossible to use in GCC 12 2022-02-21 01:09:28 ah 2022-02-21 07:08:40 Ariadne: I found it. one of the upstream fixup commits broke the feature detection macros for split_stack support. That is, TARGET_CAN_SPLIT_STACK is defined even though gcc doesn't support -fsplit-stack with musl 2022-02-21 07:08:54 I will try to get this fixed upstream again *sigh* 2022-02-21 07:12:26 so what you're saying is someone merged 'fix split stack' and didn't check if it worked 2022-02-21 07:12:28 :) 2022-02-21 07:16:21 yeah, the entire upstream integration of the -fsplit-stack patch was a bit messy (which is also partially my fault) 2022-02-21 07:17:24 that's okay 2022-02-21 07:17:51 you can have a headpat for your good efforts :) 2022-02-21 07:54:08 Ariadne: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590637.html <- if you backport this too it should compile again (at least it does so here) 2022-02-21 07:56:38 nmeum: do you have an mbox for that 2022-02-21 07:56:59 nmeum: also thanks for your work chasing this down! 2022-02-21 08:00:07 Ariadne: https://tpaste.us/zlkj (git format-patch) 2022-02-21 08:00:42 i found this: http://patchwork.ozlabs.org/project/gcc/patch/20220221075116.11790-1-soeren@soeren-tempel.net/ 2022-02-21 08:00:50 for future reference :) 2022-02-21 08:02:34 nmeum: test build running :) 2022-02-21 08:03:20 great, fingers crossed 🤞 2022-02-21 08:07:46 i would do one too but i have already built gcc like 12 times today so i am all gcc'd out 2022-02-21 09:00:15 is 'alice' from gitlab on here? I just wanted to say thank you(!!!) for your attention to patches on gitlab lately :) 2022-02-21 09:02:35 psykose: ^ (: 2022-02-21 09:02:51 me :) 2022-02-21 09:02:57 anytime ^~^ 2022-02-21 09:03:47 psykose: Btw your aerc upgrade commit says 0.8.0 while the change to the APKBUILD is to 0.8.1 2022-02-21 09:03:51 yes 2022-02-21 09:03:55 i noticed 3 seconds after i merged it 2022-02-21 09:03:56 x.x 2022-02-21 09:04:01 :( 2022-02-21 09:04:03 :( 2022-02-21 09:04:22 happens 2022-02-21 09:15:47 `abump` 2022-02-21 09:16:45 it was an amend 2022-02-21 09:17:20 double upgrade :) 2022-02-21 09:18:12 .oO(Should I suggest to the maintainer of aerc that he makes beta releases?) 2022-02-21 09:18:34 i mean i tested 0.8.0 locally, and instantly saw the fixed issue :p 2022-02-21 09:18:40 then saw there was already a 0.8.1 after 5 minutes 2022-02-21 09:18:41 hah 2022-02-21 09:19:10 the new colorize highlighter is nice :) 2022-02-21 09:19:24 psykose: That's why I mean, people shouldn't package a new version of software until it's gone through a round of public testing 2022-02-21 09:19:34 most people don't test master 2022-02-21 09:19:46 they don't test -rc1 either 2022-02-21 09:19:47 :p 2022-02-21 09:19:58 but i guess more 2022-02-21 09:19:58 psykose: hmm true 2022-02-21 09:20:19 at least it's a point that the maintainer considers stable enough to be tested 2022-02-21 09:20:27 yes 2022-02-21 09:20:32 rc's are good 2022-02-21 09:54:42 nmeum: hmm, -fsplit-stack is still broken on 32-bit x86 2022-02-21 09:54:54 uh uh 2022-02-21 09:54:56 in what way? 2022-02-21 09:54:57 this sure is fun 2022-02-21 09:54:58 same error 2022-02-21 09:55:09 puhhh 2022-02-21 09:55:30 did your test build pass? 2022-02-21 09:55:34 yes, on 64-bit 2022-02-21 09:55:47 but build-edge-x86 is choking 2022-02-21 09:55:50 right, I also only tested x86_64 2022-02-21 09:55:58 https://build.alpinelinux.org/buildlogs/build-edge-x86/main/gcc/gcc-11.2.1_git20220219-r1.log 2022-02-21 09:56:00 if only we had some ci to catch this 2022-02-21 09:56:04 :p 2022-02-21 09:56:26 psykose: sure, feel free to implement gitlab CI for our gcc tree :) 2022-02-21 09:56:43 where is TARGET_CAN_SPLIT_STACK defined for x86? 2022-02-21 09:56:44 it would work through a normal mr wouldn't it 2022-02-21 09:56:57 gcc builds in it fine 2022-02-21 09:57:26 psykose: yes, but would rather do it from the raw tree 2022-02-21 09:57:33 x.x 2022-02-21 09:57:37 so we have more granular data 2022-02-21 09:58:04 i should not have backported the gcc 12 -fsplit-stack changes made by gcc from our original patch 2022-02-21 09:58:11 this is absurdity 2022-02-21 09:58:28 my original patch may have introduced some issues with -fstack-protector-strong though 2022-02-21 09:58:35 so we should definitly backport the upstream patches 2022-02-21 09:59:04 it's just super difficult to wrap your head around this split-stack stuff since it's splitted accross 5 different files are something 2022-02-21 09:59:08 the gcc code base is a giant mess 2022-02-21 09:59:10 anyway 2022-02-21 09:59:40 I don't have the time to look into this right now but I would assume I missed a define for TARGET_CAN_SPLIT_STACK somewhere in gcc/config? 2022-02-21 09:59:49 i checked 2022-02-21 10:00:05 you can add an #error case to the TARGET_CAN_SPLIT_STACK ifdef's in gospec.c to check that 2022-02-21 10:00:14 otherwise, I can look into it later today 2022-02-21 10:01:05 https://github.com/gcc-mirror/gcc/blob/master/gcc/go/gospec.cc#L272-L279 <- supports_split_stack must be 0 in gospec.cc 2022-02-21 10:01:44 there's nothing missed that i see.. 2022-02-21 10:02:05 except for some shit in gcc/config/rs6000/linux64.h that surely does not get invoked on x86 alone for some reason 2022-02-21 10:02:10 fuck it 2022-02-21 10:02:15 i'm just going to do a hackfix 2022-02-21 10:02:21 we've wasted enough time on this 2022-02-21 10:02:21 there's no rush 2022-02-21 10:02:37 yeah there is 2022-02-21 10:02:38 actually 2022-02-21 10:02:41 the x86 builder is red 2022-02-21 10:02:49 we need to fix it 2022-02-21 10:04:16 with like 2 packages in the backlog 2022-02-21 10:04:33 the 3.12 x86 builder is also red 2022-02-21 10:04:35 for like 6 days 2022-02-21 10:04:48 I can look into it in 6-7 hours, I am sure it just a minor issue somewhere 2022-02-21 10:05:24 enjoy yer day 2022-02-21 10:05:26 :) 2022-02-21 10:05:33 i'm hackfixing it for now 2022-02-21 10:05:42 we'll fix it properly in next snapshot 2022-02-21 10:05:47 sure 2022-02-21 10:06:02 3.12 builder should be fixed too :) 2022-02-21 10:06:10 and 3.13 2022-02-21 10:06:17 but thats not as major as edge being red 2022-02-21 10:06:25 edge being red means everything stops 2022-02-21 10:06:36 yes but it's x86 2022-02-21 10:45:22 the hackfix seems to work? nice 2022-02-21 10:45:37 but than the problem really is that the macro is defined somewhere else as well wow 2022-02-21 10:45:44 s/than/then/ 2022-02-21 10:45:44 nmeum meant to say: but then the problem really is that the macro is defined somewhere else as well wow 2022-02-21 10:56:21 from what i grep'd it wasn't 2022-02-21 10:56:22 no idea 2022-02-21 11:47:33 Hello, is this the chan for 'aports' discussions ? Or should I move to #alpine-linux instead ? 2022-02-21 11:47:44 No, here is fine 2022-02-21 11:52:43 Cool, I have a few questions then, here is some context: I'd like to start package maintaining, but I have no background whatsoever, I would like to provide the 'supercollider' package. I followed the Wiki and managed to package it. However my concerns are: how should I test if my 'depends' are fine, do you advise to start a container or a VM with a fresh install to check if it's adequite ? Also, 2022-02-21 11:52:49 I found there is a conflict between 'pipewire-jack' and 'jack-dev', 'jack-dev' cannot be installed (at least on my system) while 'pipewire-jack' is, is there a fix for this ? (I need 'jack-dev' to build 'supercollider') 2022-02-21 11:53:45 For now I removed 'pipewire-jack' from my system, and it works, but it is a bit annoying. 2022-02-21 11:53:50 afaik they are mutually exclusive 2022-02-21 11:54:03 And that's why you should build in a clean environment 2022-02-21 11:54:09 a chroot or use abuild rootbld 2022-02-21 11:56:25 okay, seems logic, I didn't know about abuild rootbld (maybe should I have RTFM), I'll look into it, thanks ! 2022-02-21 11:56:35 abuild rootbld is underdocumented :( 2022-02-21 11:56:52 nmeum: hackfix worked, feel free to look into gcc-go whenever you have time, no rush :) 2022-02-21 11:57:05 sure, will do 2022-02-21 12:04:30 Ariadne: seems to work for now 2022-02-21 12:05:09 @ikke: Should I test my executables in the chroot too to ensure depends are fine ? 2022-02-21 12:05:59 (is the chroot destroyed after the abuild rootbld ?) 2022-02-21 12:11:47 you can install the package normally afterward 2022-02-21 12:11:54 if you have your local repos set up 2022-02-21 12:11:59 and no, it remains 2022-02-21 12:12:04 in /var/tmp/abuild.xxx 2022-02-21 12:13:08 Cool 2022-02-21 12:13:48 i'm not in favor of enabling LTO in things until the TSC discusses it 2022-02-21 12:14:05 i am also, generally, opposed to using LTO with GCC, it will make GCC upgrades more fragile 2022-02-21 12:14:16 if we do LTO, it should wait until clang is system compiler 2022-02-21 12:14:18 I know I can install it right away, but I want to make sure my 'depends' key is populated as required, I have a some libraries locally and I dont want them to interfere in my tests 2022-02-21 12:15:01 then sure, do chroot stuff 2022-02-21 12:15:03 :) 2022-02-21 12:29:29 okay, so the build worked, but tests failed because there's no display available in the chroot, (qt.qpa.xcb: could not connect to display :0), how do you usually tackle those problems ? Ignore the tests ? 2022-02-21 12:30:08 mayathebee: The build system has no X server, so you need to use xvfb-run for the tests 2022-02-21 12:30:42 Just add xvfb-run to checkdepends, and prefix the test commands with xvfb-run 2022-02-21 12:31:10 thanks for the advice, will do ! 2022-02-21 15:11:08 @ncopa hi, may I ask what's the different of k0s --single vs --enable-worker ? I'm afraid to use --single, I thought it use kine sqlite 2022-02-21 15:15:10 wener: its kinda off topic but, k0s --single will disable some leader election routines, which means that you cannot add more controllers. while --enable-worker keeps the leader election working, so you can add more controllers if you want. --single will use kine as backed by default, but you can specify etc as storage backend in a k0s.yaml even 2022-02-21 15:15:10 with --single 2022-02-21 15:16:14 thanks, working on deploy some k0s on alpine 2022-02-21 15:24:15 ptrc, hi, is my understanding, that apk-tools 2.12.10 will be usable with jfrog, correct or not? 2022-02-21 15:35:12 indy: it got merged, so i'm pretty sure that it'll make it into the next release 2022-02-21 15:35:26 and that would be 2.12.10 indeed 2022-02-21 15:35:40 (or 2.13, dunno) 2022-02-21 15:52:07 wener: just make sure to start cgroup and machine-id "services" 2022-02-21 15:52:49 how about add tow need in /etc/init.d/k0scontroler ? 2022-02-21 15:53:27 manually install works, but k0sctl stuck on this https://github.com/k0sproject/k0sctl/issues/334 2022-02-21 15:59:35 indy: this seems like a regression in artifactory, its pretty common for people to use artifactory with alpine 2022-02-21 15:59:43 but yes, 2.12.10 will have the fix 2022-02-21 16:00:02 Ariadne, ptrc, any time frame? 2022-02-21 16:14:33 "Ariadne | i'm building something better ^_^" Yes, please! Artifactory is so bad. 2022-02-21 18:33:17 hi, new question about 'aports': what's the policy on optional program features ? As maintainers should we try to include as much as possible or choose for smaller builds ? How do we choose ? 2022-02-21 18:35:28 i 2022-02-21 18:35:59 i'm not sure if there's an official policy, usually if the optional features can be separated file-wise, it's done via subpackages 2022-02-21 18:40:50 and if they can't ? because i'm trying to package supercollider, and AFAIK, adding QT applies to all binaries in the project... the CLI seems to be requiring Qt when the feature is enabled 2022-02-21 18:42:50 can subpackages overwrite files from the root package ? (In example, installing supercollider-gui would overwrite the /usr/bin/sclang CLI ?) 2022-02-21 18:53:59 also, other question, about the `Tracing dependencies...` log, it displays lines with 'so:...', does this mean it has auto-detected those dependencies and it will add them in the apk or that I should make sure manually I 'depends' from every packages having those '.so' ? 2022-02-21 18:55:51 the former, it will add them automatically 2022-02-21 18:57:49 cool, I also kinda noticed it will add the root packages of the `*-dev` packages, am I right ? 2022-02-21 18:58:58 that's the tracing thing, it adds 'so:somelibname.so' to the dependencies 2022-02-21 19:00:08 nice, thanks for the infos 2022-02-21 19:15:35 PureTryOut: any idea why paths in kcoreaddons-dev differ between arches? 2022-02-21 19:16:00 libreoffice tries to include /usr/include/KF5/kcoreaddons_version.h, but that's only present on mips64 and rv64 2022-02-21 19:20:33 because the location has changed and those arches are behind in builders and don't have the updated package yet 2022-02-21 19:20:37 ah, nevermind 2022-02-21 19:20:38 yeah 2022-02-21 19:20:40 just noticed that 2022-02-21 19:20:56 (note the mips64 builder is down forever) 2022-02-21 19:21:36 pkgs.a.o still shows mips64 packages for some reason 2022-02-21 19:21:49 they are still in the DB 2022-02-21 19:21:52 ah, right 2022-02-21 19:21:57 ikke: any plans on removing them? 2022-02-21 19:22:13 that's on the infra board iirc 2022-02-21 20:42:24 is somebody working on vulkan 1.3.206 ? 2022-02-21 20:45:28 also id like to get some feedback for !30599 please, with spirv-headers recent version changes, the package is viewed by apk as a downgrade 2022-02-21 20:58:02 made !31307 fwiw 2022-02-21 22:35:35 hi again, I have another question about aports, the repository states that the code is released under GPL-3.0 (and the included COPYING file is GPL-3.0), but the code states GPL-2.0 or later in random choosen files, what license do I set in the APKBUILD file then ? 2022-02-21 22:36:44 I was going to go for 'GPL-2.0-or-later' but I don't want to mess this up. 2022-02-21 22:36:57 the licence of the software you are packaging 2022-02-21 22:37:44 Yes, but some source files are stating GPL-2.0 or later, and the repository states GPL-3.0 2022-02-21 22:37:56 Oh, I see 2022-02-21 22:38:12 So I don't know which one to set 2022-02-21 22:38:26 Sounds like a bit of a mess 2022-02-21 22:38:47 So, do some other files say GPLv3? 2022-02-21 22:43:40 After some investigations, yes 2022-02-21 22:45:45 supercollider/lang/LangSource/MiscInlineMath.h: GPLv2 2022-02-21 22:45:57 supercollider/editors/sced/scedwin/py/LogPanel.py: GPLv3 2022-02-21 22:49:04 I suppose the combination can only be redistributed under GPLv3 then 2022-02-21 22:50:39 So GPL-3.0-or-later ? 2022-02-21 22:52:06 Only if the GPLv3 bits of it say that a later version of GPL is also OK 2022-02-21 22:52:27 Yes it does 2022-02-21 22:52:39 sgtm then! 2022-02-21 22:52:48 thanks :) 2022-02-21 22:52:57 (and I'm not anyone official, just some dude, fwiw) 2022-02-21 22:55:05 Another tricky question: the repo states 'GPLv2 or later', but some files 'GPLv2 or later' and other 'GPLv3 or later' 2022-02-21 22:55:20 I guess it also falls into GPLv3-or-later then ? 2022-02-21 22:57:30 > (and I'm not anyone official, just some dude, fwiw) 2022-02-21 22:57:33 no worrie 2022-02-21 22:57:35 +s 2022-02-22 07:35:07 hello, sorry for the FAQ: i forked the aports repo, patched and tested some changes to recover an APKBUILD from 'unmainted' to 'community'. The pipelines are green. What should I do from now ? 2022-02-22 07:35:47 ( the page I found, https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work, still points to github) 2022-02-22 07:36:32 you need to make a merge request to alpine/aports/master 2022-02-22 07:37:13 if you did already, then link it to me 2022-02-22 11:59:39 Hi, I am getting failures installing networkmanager-elogind: BAD signature... But only in aarch64 and armhf architectures. Any idea on how to solve it? 2022-02-22 12:00:56 Usually I had seen those if some signature changed, but in all architectures, not just in some. So I assume regenerating checksums wouldn't fix it 2022-02-22 12:00:58 pabloyoyoista: what mirror? 2022-02-22 12:01:11 and what repo? 2022-02-22 12:01:19 (ie, version) 2022-02-22 12:02:10 hmm, I see it on edge with dl-cdn 2022-02-22 12:02:31 I can look at it later 2022-02-22 12:02:40 edge. And I believe it is that same mirror. Which seems the default in postmarketos' pipeline 2022-02-22 12:02:46 that's strange 2022-02-22 12:02:57 Ok, thanks a lot! 2022-02-22 12:03:06 it was update to 1.34.0 recently, but no funny downgrade/rebuild business 2022-02-22 12:03:25 guess the builders did something wrong 2022-02-22 12:04:41 yep, reproduced too 2022-02-22 12:04:58 Yes, I was checking that first before bothering people here. Seemed like a regular upgrade 2022-02-22 12:05:02 just bumping the pkgrel would probably fix it 2022-02-22 12:05:11 but perhaps ikke wants to find the real issue 2022-02-22 13:47:46 psykose: i dont understand your revdeps comment on !30599 2022-02-22 13:48:21 the things that depend on spirv-headers should pull in the 'downgraded' version if you specify a version in the things that use it 2022-02-22 13:48:25 in the same ci 2022-02-22 13:48:38 i am guessing, i didn't check, but it sounds correct 2022-02-22 13:48:50 if you want to do things in the same ci anyway 2022-02-22 13:48:52 i would 2022-02-22 13:50:14 huh 2022-02-22 13:50:16 could be working 2022-02-22 13:50:59 like specifying spirv-headers-1.3.204-r0 in the depends? 2022-02-22 13:52:16 makedeps = spirv-headers~1.3.204 or something 2022-02-22 13:52:30 i forget if that allows it to use a newer one too with ~ 2022-02-22 13:52:35 with = you need the -r0 too 2022-02-22 13:53:31 there's this line in spirv-tools 2022-02-22 13:53:34 >depends_dev="spirv-headers $pkgname=$pkgver-r$pkgrel" 2022-02-22 13:54:53 that's not related to building 2022-02-22 13:55:05 or well 2022-02-22 13:55:08 yes, you can edit that 2022-02-22 13:55:23 if depends_dev is also in makedeps 2022-02-22 13:55:36 it is, neat 2022-02-22 13:55:53 ill try that when im done with the vulkan rebuild 2022-02-22 15:12:05 PureTryOut: if you have time to look at !31307 pls, checklist is done 2022-02-22 15:18:42 should the vulkan-* packages be moved to main? 2022-02-22 15:19:02 the spirv-* are already in main 2022-02-22 15:33:47 if anything the other way around 2022-02-22 15:34:50 spirv move to community? 2022-02-22 15:34:56 the only thing using spirv in main is glslang, and nothing uses that in main 2022-02-22 15:35:36 so move glslang in community too? 2022-02-22 15:35:46 i'm not proposing any changes :) 2022-02-22 15:35:59 but if i did, - 2022-02-22 15:36:02 all is okay 2022-02-22 15:36:09 keep up the good work 2022-02-22 16:13:05 bl4ckb0ne: will do later, thanks! 2022-02-22 16:13:47 ty 2022-02-22 16:30:38 psykose: i think the fix works 2022-02-22 16:30:55 i tagged spirv-tools to pull a tagged version of spirv-headers, and all deps follow 2022-02-22 16:31:14 add it to the ci 2022-02-22 16:31:20 can go away next spirv-headers update and 2022-02-22 16:31:20 you can upgrade spirv-tools in there too 2022-02-22 16:31:22 and the rebuilds 2022-02-22 16:31:33 make 2 PR in one? 2022-02-22 16:31:42 it's just more commits in the same pr 2022-02-22 16:31:50 they're all related 2022-02-22 16:33:09 ack 2022-02-22 16:33:42 time for comfy bed for me :) 2022-02-22 16:33:43 goodnight 2022-02-22 16:33:56 see ya 2022-02-22 16:34:08 wait who's gonna review the spirv stuff :O 2022-02-22 17:57:57 anyone working on updating go to 1.17.7 in edge and v3.15? 2022-02-22 19:10:06 HRio: yes, I have an MR for that 2022-02-22 19:10:09 I should just merge 2022-02-22 19:10:14 we just need to take care of rebuilds 2022-02-22 19:12:10 HRio: pushed, will be in edge soon 2022-02-22 19:12:16 3.15 upgrade should probably be done together with the rebuild 2022-02-22 21:15:12 nmeum: thanks! 2022-02-23 11:33:05 ikke: problem with 2022-02-23 11:33:27 networkmanager-elogind is gone in aarch64, but I keep hitting it with armhf 2022-02-23 11:34:10 Should I wait maybe another day to avoid cdn caching if you think it is resolved? 2022-02-23 11:40:33 that is bizarre 2022-02-23 11:42:26 https://tpaste.us/YEm6 2022-02-23 11:42:46 that'll do it 2022-02-23 11:43:07 non-idempotent index updates :p 2022-02-23 11:43:20 Hmm, but that's on edge, not 3.15 2022-02-23 11:43:21 or rather not fully moved 2022-02-23 11:43:58 I'm seeing the problem in edge though. Haven't tried stable versions 2022-02-23 11:44:25 ah, ok 2022-02-23 11:44:34 I misremembered' 2022-02-23 11:44:44 Then that's most likely it 2022-02-23 11:47:33 Thanks! I guess I'll try again tomorrow then :) 2022-02-23 12:01:04 pabloyoyoista: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10818 2022-02-23 12:28:24 ikke: well, it's been like 3 days with no interrupts, and nodejs cannot build on rv64 2022-02-23 12:28:31 guess we may as well disable it again 2022-02-23 12:33:15 !31361 and cycling the builder :) 2022-02-23 12:33:38 rv64 has a week of backlog now 2022-02-23 12:47:13 Hi, I just tried ngircd for a little experiment and ended !31362 2022-02-23 12:47:33 is there anyone using PAM for irc auth? :\ 2022-02-23 13:21:07 not sure why you removed the user 2022-02-23 13:21:15 i see the init.d doesn't use it, but then it should be amended :) 2022-02-23 13:21:20 running things as nobody is not very good 2022-02-23 13:57:36 ncopa: can we just enable the keymap feature in the default mkinitfs configuration or would there be a downside to doing that? 2022-02-23 13:58:57 #13291 etc 2022-02-23 14:32:48 i think the CI is not having it 2022-02-23 14:32:51 >gzip: invalid magic 2022-02-23 14:44:59 that happens on every ci run and isn't an error 2022-02-23 14:47:19 please take a quick look at !31360 2022-02-23 17:18:04 psykose: ok, better run in as 'ngircd'. Do you see fine to disable pam? 2022-02-23 17:21:43 idk what functionality it provides 2022-02-23 17:32:30 theorically use PAM for users authentication with '/auth', I suppose that if someone really wants this he will/should consider many other things 2022-02-23 17:33:05 lol 2022-02-23 17:36:00 uhM 2022-02-23 17:36:41 sure sounds fine to me 2022-02-23 17:36:43 since it currently doesn't provide a '/etc/pam.d/ngircd', it will rely on /etc/pam.d/others' and according to https://github.com/ngircd/ngircd/blob/master/doc/PAM.txt , "All the PAM modules are executed with the privileges of the user ngIRCd 2022-02-23 17:36:49 is running as. Therefore a lot of PAM modules aren't working as expected, 2022-02-23 17:37:02 ouch, sorry I didn't expect to break the lines :( 2022-02-23 17:37:09 because they need root privileges ("pam_unix", for example)! 2022-02-23 17:37:42 with the current install it's directly broken 2022-02-23 17:58:40 n00b question: what is the difference, in C, between this: 2022-02-23 17:58:51 #include "lib.h" 2022-02-23 17:58:52 and 2022-02-23 17:59:00 #include 2022-02-23 17:59:13 <> means look it up in the system directories 2022-02-23 17:59:41 so /usr/include 2022-02-23 17:59:44 by default 2022-02-23 17:59:54 yes 2022-02-23 18:00:07 while "lib.h" is starting from the current dir 2022-02-23 18:00:29 https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html 2022-02-23 18:00:41 hmm, that's cpp 2022-02-23 18:01:54 i think is the same 2022-02-23 18:03:44 it is 2022-02-23 18:03:58 <> looks in the -I directories, and the compiler has a default set too 2022-02-23 18:04:05 or something 2022-02-23 18:04:24 thx! 2022-02-23 19:56:55 cpp means c pre processor, not c plus plus 2022-02-23 20:03:15 Hello71: ah 2022-02-23 21:43:44 psykose: thanks for taking care of the dotnet MRs btw 2022-02-23 21:44:20 if i didn't they would probably have given up by now 2022-02-23 21:44:20 x.x 2022-02-24 10:35:04 Cogitri, any objection in moving py3-gnupg to community? 2022-02-24 10:42:47 it fails for s390x but i excluded it in arch: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31399 2022-02-24 10:42:49 any ideas? 2022-02-24 10:44:10 the ci is just down 2022-02-24 10:44:26 ah ok 2022-02-24 10:45:08 you also typed !390x and not !s390x 2022-02-24 10:45:14 heh 2022-02-24 11:47:38 fcolista: think it's fine to move anyway, not very actively updated at least :) 2022-02-24 11:47:41 at least to unblock the builders 2022-02-24 11:48:22 also !31370 to unblock riscv, which i can't merge 2022-02-24 11:48:24 packages should not be moved without maintainers consent 2022-02-24 11:48:55 after all i heard the other day about blocked builders :p 2022-02-24 11:49:12 but yes 2022-02-24 11:49:25 psykose: we _can_ disable ospd-openvas :) 2022-02-24 11:49:37 yes, but that is a bit aggressive :) 2022-02-24 11:49:48 for me to do 2022-02-24 12:49:46 hi :) I'm trying to `abuild -r rootbld` a project, but since in the chroot there's no /etc/resolv.conf, the project's cmake fails to `git clone` a dependency (that can't be replaced by a system dependency, since the library is not available in aports). How are these issues tackled usually when creating new aports ? thanks 2022-02-24 12:51:28 you can add `options="net"` to the APKBUILD 2022-02-24 12:51:52 you can vendor the submodule instead in source= 2022-02-24 12:52:02 though some cmake scripts don't really let you do that and force download stuff 2022-02-24 12:52:02 that too 2022-02-24 12:55:13 if I add the dependencies in `source`, I'll have to manage subdependencies myself and ensure that it matches what's required in the project right ? 2022-02-24 12:57:50 (I'm going to try `options="net"` for now, and see if the project is suitable for alpine and investigate the `source=` solution if it is, thanks :)) 2022-02-24 13:00:50 yes, but it's usually as simple as just adding a _subdep=gitsha or _subdep=someversion and just bumping that 2022-02-24 13:03:17 okay, nice, I'll dig into that then 2022-02-24 13:57:06 I wonder if alpine's default fstab should have a tmpfs for /tmp 2022-02-24 14:03:16 ddevault: it would be good, I think 2022-02-24 14:34:44 working with dozens of machines that don't have plenty of RAM it would be the first thing I'd disable 2022-02-24 14:35:46 bootmisc is already cleaning up /tmp at boot 2022-02-24 15:54:25 make it an option in setup-alpine 2022-02-24 15:54:54 lots of distros have /tmp as a tmpfs by default now, and it's surprising that Alpine does not, especially since it makes it impossible to have / read-only 2022-02-24 15:55:20 it would be nice if the default was to have it, with an easy and official way to disable it 2022-02-24 18:36:59 Hello all 2022-02-24 18:37:19 I have found an issue with OVMF package 2022-02-24 18:38:49 basically, OVMF people shit the bed and inserted a nasty bug that prevents video from working in gpu passtrough 2022-02-24 18:39:09 they corrected it in the latest rc1 release 2022-02-24 18:39:33 I can compile OVMF from aports 2022-02-24 18:39:54 but it obviously gets the bugged version 2022-02-24 18:40:22 how can I patch the cose manually using the aports recipe ? 2022-02-24 18:40:30 code 2022-02-24 18:40:57 point the source= at the new version 2022-02-24 18:40:57 wyk72: download the patch, make sure it has a .patch extension and add it to source 2022-02-24 18:41:11 if you're building yourself you can just use the rc1 2022-02-24 18:41:51 update pkgver, update realver and add -rc1 to the end of realver 2022-02-24 18:41:53 and it should just work 2022-02-24 18:42:04 with 0.0.202202 2022-02-24 18:42:19 I tried but it seems it has a lot of patches to run from Alpine 2022-02-24 18:42:20 and you need to set builddir 2022-02-24 18:42:38 I tried 2022-02-24 18:42:41 and probably rebase the patches :) 2022-02-24 18:42:43 not easy 2022-02-24 18:42:44 but it complains about checksums 2022-02-24 18:43:04 run abuild checksum 2022-02-24 18:43:38 and a LOT of other things, since the OVMF code is somewhat complex 2022-02-24 18:43:43 being a firmware 2022-02-24 18:44:10 since older versions do not have the bug 2022-02-24 18:44:23 maybe I can use those? 2022-02-24 18:44:28 probably yes 2022-02-24 18:44:35 when I use the aport tree 2022-02-24 18:44:39 it always points to edge 2022-02-24 18:44:50 there is a way to get an older one ? 2022-02-24 18:45:10 checkout 3.15-stable for example 2022-02-24 18:45:11 what points to edge 2022-02-24 18:45:24 I always use 3.15stable 2022-02-24 18:45:27 for aports you can checkout the stable branches like what ikke says 2022-02-24 18:45:39 I see 2022-02-24 18:45:55 there is some documentation about it ? 2022-02-24 18:46:20 if I follow the instructions 2022-02-24 18:46:31 the git pulls aports tree from edge 2022-02-24 18:46:46 at least the ovmf package 2022-02-24 18:48:51 git doesn't pull any package 2022-02-24 18:48:59 i am confused what issue you actually have 2022-02-24 18:49:34 if you want to read the APKBUILD for the 3.15 ovmf, then checkout the 3.15-stable tree and it will be that one 2022-02-24 18:49:41 then you will be abuild'ing what is in 3.15 or whatever 2022-02-24 18:49:43 I mean 2022-02-24 18:50:12 but if you want to upgrade it to the latest rc1, then it doesn't matter what tree you are in, you are editing the apkbuild anyway 2022-02-24 18:50:37 the dependencies the building itself will pull will depend on /etc/apk/repositories, nothing to do with the actual git repo you cloned 2022-02-24 18:51:06 maybe the depends/makedepends for a package can be something incompatible with 3.15, but this is separate :) 2022-02-24 18:51:12 if I do a "git clone git://git.alpinelinux.org/aports" 2022-02-24 18:51:26 I get the bugged version in the tree 2022-02-24 18:51:31 what is bugged about it 2022-02-24 18:51:58 the bug pertains to the pci IOMMU passtrough via QEMU 2022-02-24 18:52:18 it does not turn on the video card if it's passed to a virtual machine via QEMU 2022-02-24 18:52:28 this bug is to do with the ovmf package 2022-02-24 18:52:28 the version from 3.15-stable WORKS 2022-02-24 18:52:36 then use the version from 3.15 stable 2022-02-24 18:52:45 i am not sure what the git tree has to do with this 2022-02-24 18:52:55 but if I git clone the aports tree I get a version that DOES NOT WORK 2022-02-24 18:53:04 yes, because the version in edge is broken 2022-02-24 18:53:14 ok 2022-02-24 18:53:17 got it 2022-02-24 18:53:24 which is the version described in the master branch of the aports tree 2022-02-24 18:53:29 so what is the command to pull the aports tree from 3.15 ? 2022-02-24 18:53:32 this has nothing to do with aports or git, but just the package versions 2022-02-24 18:53:36 you just checkout the branch 2022-02-24 18:53:42 git checkout 3.15-stable in the repo 2022-02-24 18:54:05 then you will have the text file that corresponds to the.. 3.15 version, which as you say works 2022-02-24 18:54:12 great 2022-02-24 18:54:15 I'll try that tonight 2022-02-24 18:54:44 besically I need to pull an older version of the OVMF soruce tree 2022-02-24 18:54:54 i mean 2022-02-24 18:54:56 source pkg 2022-02-24 18:55:19 the package that it comes from is community/edk2 2022-02-24 18:55:28 yup 2022-02-24 18:55:29 check out the branch of 3.15-stable and go to that 2022-02-24 18:55:46 thanks a lot, will try later 2022-02-24 18:56:53 https://github.com/tianocore/edk2/commit/ee1f8262b83dd88b30091e6e81221ff299796099 2022-02-24 18:56:56 this is the bugfix 2022-02-24 18:57:03 of OVMF 2022-02-24 18:57:52 seems it's into edk2-stable202202-rc1 2022-02-24 19:00:31 psykose: got some time to check !30599 pls? 2022-02-24 19:01:34 looks good to me 2022-02-24 19:01:41 i just can't merge things into main 2022-02-24 19:02:01 personally i would put all the rebuilds in the same mr 2022-02-24 19:02:11 but it's fine as is 2022-02-24 19:02:13 what do you mean? 2022-02-24 19:02:20 the linked mrs 2022-02-24 19:02:46 it's an update on its own 2022-02-24 19:02:59 the other versions build fine without 2022-02-24 19:03:19 could cherry pick them if you want 2022-02-24 19:03:29 the libplacebo one isnt very relevant though, issue on my end 2022-02-24 19:04:32 sure, as you prefer 2022-02-24 19:04:32 :) 2022-02-24 19:04:33 all good 2022-02-24 19:04:35 good work! 2022-02-24 19:05:43 ty 2022-02-24 19:06:29 i can pick up the work on !30596 now :D 2022-02-24 19:06:33 ~ 2022-02-24 19:25:26 The tcpdump secfixes have annotations appended: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/tcpdump/APKBUILD 2022-02-24 19:25:43 I suppose we should change those to comments 2022-02-24 19:26:04 does that break them 2022-02-24 19:26:07 do you want me to do it 2022-02-24 19:26:18 does it just need a # on the same line 2022-02-24 19:26:20 I'm looking broader 2022-02-24 19:26:24 I already have some fixes 2022-02-24 19:26:27 ah 2022-02-24 19:26:57 I added validation (locally) to the tool that generates the secdb 2022-02-24 19:27:34 always convenient 2022-02-24 21:38:42 I managed to compile an older OVMF version that does not have the passtrough bug (edk2-stable201908) 2022-02-24 21:38:58 thanks to the nice people here 2022-02-24 21:39:27 I just had to pull the aports tree from 3.15-stable 2022-02-25 10:42:32 ikke: Is there any chance you can have a look at https://gitlab.alpinelinux.org/alpine/infra/docker/appstream-generator/-/merge_requests/3? And redeploy the generator? Cogitri merged a commit which allows cleanup to work, so should reduce space usage :) 2022-02-25 10:43:10 And thanks a lot anyway :) 2022-02-25 10:43:38 I'll take a look in a bit 2022-02-25 16:41:23 pabloyoyoista: I've deployed the new image 2022-02-25 16:46:10 Thanks a lot! I guess we'll be seeing the logs from tonight :) 2022-02-25 20:44:52 does anyone know why protobuf 3.18.1 has "29.0.1" in .so name? 2022-02-25 20:49:19 because they set soversion to 29 2022-02-25 20:49:28 they're not related 2022-02-25 20:50:08 psykose: I've extracted the script from db.lua and ran it on all apkbuilds in testing, but everything returns successful 2022-02-25 20:50:15 hm 2022-02-25 20:50:29 go a little more back then and do it one command at a time 2022-02-25 20:50:48 the first thing that was called with the path() or whatever failed 2022-02-25 20:50:58 one little step at a time instead of just to where i thought it failed 2022-02-25 21:10:28 If I put an assert around close, it returns "signal" 2022-02-25 21:13:37 hm 2022-02-25 21:16:39 maybe strace? 2022-02-25 21:17:54 wait, segvault? 2022-02-25 21:18:39 that would be strange 2022-02-25 21:19:44 https://tpaste.us/OrRw 2022-02-25 21:20:41 confused why the popen with a for-loop echo would segfault 2022-02-25 21:20:52 yes, me too 2022-02-25 21:21:49 [4858812.379000] sh[14911]: segfault at 1 ip 000055a60f861969 sp 00007ffda97c1390 error 4 in busybox[55a60f81f000+9b000] 2022-02-25 21:21:51 [4858812.379017] Code: 06 00 48 01 d0 48 89 44 24 20 89 f0 83 e0 02 89 44 24 10 0f 84 b0 00 00 00 89 f0 c7 44 24 10 00 00 00 00 83 e0 fd 89 44 24 0c <41> 80 3c 24 7e 0f 85 94 00 00 00 8b 44 24 0c 4c 89 e3 83 e0 04 48 2022-02-25 21:21:59 ah 2022-02-25 21:22:00 of course 2022-02-25 21:22:28 ? 2022-02-25 21:22:39 busybox doing something weird again 2022-02-25 21:22:42 heh 2022-02-25 21:23:02 was it still on 3.14 2022-02-25 21:23:14 ? 2022-02-25 21:23:17 the builder 2022-02-25 21:24:19 3.14 of what? 2022-02-25 21:24:22 alpine 2022-02-25 21:24:28 You mean the host? 2022-02-25 21:24:43 the environment doing the building 2022-02-25 21:24:44 or something 2022-02-25 21:24:57 They are tracking the version they are building 2022-02-25 21:25:00 ah 2022-02-25 21:25:08 right, so just edge 2022-02-25 21:25:12 yes 2022-02-25 21:25:53 /usr/share/abuild/functions.sh does exist and is valid right 2022-02-25 21:26:00 yes 2022-02-25 21:26:01 just in case the source is the thing that does weird stuff 2022-02-25 21:26:01 hm 2022-02-25 21:26:46 https://tpaste.us/w18v 2022-02-25 21:26:53 That's what I tested 2022-02-25 21:27:30 you should extract the str = too 2022-02-25 21:27:31 (I changed the i variable (from the loop) to 1 2022-02-25 21:28:05 I'll try that 2022-02-25 21:29:00 nope 2022-02-25 21:29:27 https://tpaste.us/Jqk0 2022-02-25 21:30:42 sigh 2022-02-25 21:30:51 Yes, might thoughts exactly 2022-02-25 21:37:02 perhaps nmeum has better ideas :) 2022-02-25 21:37:34 it is after all a busybox segfault 2022-02-25 21:38:12 6 2022-02-25 21:38:25 whoops 2022-02-25 21:50:09 fun, it does not seem to segfault with gdb 2022-02-25 21:51:19 i think we figured out how to fix the builder too then 2022-02-25 21:51:25 just invoke it with gdb 2022-02-25 21:51:26 :p 2022-02-25 21:52:10 yes 2022-02-25 23:00:10 set disable-randomization off 2022-02-26 00:05:42 is there a chance that packages from !31384 get moved to main? 2022-02-26 00:06:00 they could come in handy for the pytest test suite 2022-02-26 00:06:48 what if we moved all of python to testing instead 2022-02-26 00:07:08 amazing idea 10/10 2022-02-26 00:08:41 but i guess that one is quite benign 2022-02-26 00:08:49 sounds ok 2022-02-26 00:20:45 will the volume housing the apkovl always be sda? 2022-02-26 00:21:20 I am trying to set up a disk to house both /var and the apkovl 2022-02-26 00:21:46 but the problem is that my uuid based fstab entry fails because the boot disk mounts the volume containing the apkovl as /media/sdx 2022-02-26 03:38:30 ptrc: pretty sure the main criteria for including something in main is a commitment to support for two years (CVEs and dealing with issues and what not). I’d be willing to do that for these two. I’ll probably try and open up a MR to move them tonight to generate discussion and work on meeting any other criteria for migration. 2022-02-26 10:10:30 psykose: how do I reproduce the busybox segfault? the info is scattered too much across across the backlog ^^ 2022-02-26 10:14:07 nmeum: Not sure exactly how to reproduce it. It manifests currently by executing `ap list` on some builders 2022-02-26 10:14:24 ah, hmhm 2022-02-26 10:14:33 but ap is a lua, not a shell script? 2022-02-26 10:14:41 it executes a shell script 2022-02-26 10:14:44 i see 2022-02-26 10:14:45 in particular this: https://tpaste.us/w18v 2022-02-26 10:15:05 Sorry, this one is more accurate: https://tpaste.us/Jqk0 2022-02-26 10:15:13 But just executing that does not reproduce it 2022-02-26 10:16:31 https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/aports/db.lua#L92 2022-02-26 10:16:31 I recently fixed a segfault in the bash pattern substitution code in ash (which we don't apply currently because it hasn't been merged upstream) but this doesn't seem to use string substitutions so no idea from the top of my head 2022-02-26 10:17:10 The close function there is on line 129 returns nil instead of true 2022-02-26 10:17:24 hmhm 2022-02-26 10:17:31 I have an strace 2022-02-26 10:18:21 but it's 1.3M 2022-02-26 10:18:26 I am currently doing something else but if you have a minimal example to reproduce the segfault let me know, I can take a look then (: 2022-02-26 10:18:48 If I have time I'll try to see if I can make it reproducable 2022-02-26 10:18:58 great, thanks 2022-02-26 10:19:55 creating a gitlab issue might also be useful so we don't forget about this 2022-02-26 10:20:52 the builders are currently failing 2022-02-26 10:20:59 so I bet we won't forget about it 2022-02-26 10:21:08 but yes, I'll create an issue to track it 2022-02-26 10:23:07 oh, so it's *always* happening on the builders? 2022-02-26 10:23:18 interessting 2022-02-26 10:23:28 yes 2022-02-26 10:23:32 but not on all of them 2022-02-26 10:23:40 currently x86_64 and ppc64le 2022-02-26 10:23:50 it happens during the start of the testing/ build on x86_64 and ppc64le 2022-02-26 10:23:55 yes 2022-02-26 10:23:56 so both of them are down 2022-02-26 10:24:07 so runnign `ap list` in the testing directory does reproduce it there 2022-02-26 10:26:42 can you add `set -x` to the shell script created by ap so we can see which line causes the segfault? 2022-02-26 10:28:03 nmeum: Not sure how I would get the output 2022-02-26 10:28:06 oh, the shell script generated by ap sources ./APKBUILD, right? 2022-02-26 10:28:17 do you know on which aport it crashes? 2022-02-26 10:28:21 no 2022-02-26 10:28:31 it segfaults when :close() is executed 2022-02-26 10:28:45 maybe there is a aport in testing which uses the bash pattern substitution thing I mentioned earlier 2022-02-26 10:28:55 right 2022-02-26 10:29:02 it certainly sources the APKBUILDs 2022-02-26 10:29:40 ok, so some sort of debugging output to figure out which APKBUILD is being sourced when it crashes would be useful 2022-02-26 10:30:02 yeah 2022-02-26 10:30:57 Just doing this: `for P in */APKBUILD; do sh $P >/dev/null || echo $P; done` does not print anything 2022-02-26 10:31:51 might it be one of the new dotnet5 apkbuilds? 2022-02-26 10:32:10 that forloop would include those 2022-02-26 10:32:16 also bizarre it's only some builders 2022-02-26 10:32:33 https://git.alpinelinux.org/aports/tree/testing/dotnet5-runtime/APKBUILD#n17 2022-02-26 10:32:38 this one uses bash pattern substitutions for example 2022-02-26 10:33:40 in this case that is a '5', wonder if it fixes itself if you just replace it 2022-02-26 10:33:46 granted that same thing is present in the others too 2022-02-26 10:33:47 if this is indeed #13469, then it would not always crash when source'ing something manually since it depends on the stack allocater state 2022-02-26 10:33:57 ah 2022-02-26 10:34:04 it is consistent once it happens once 2022-02-26 10:34:05 hm 2022-02-26 10:35:06 would be useful if we could pin down the line that causes the crash, or get a backtrace, or at least figure out which apkbuild is responsible 2022-02-26 10:35:13 yes 2022-02-26 10:35:29 otherwise we could also try trail-and-error and just apply my busybox patch (though I would ideally like to wait until it is merged upstream before we start shipping this to everyone) 2022-02-26 10:35:35 nmeum: I also tried to run ap list in gdb, but I could not see a segfault then 2022-02-26 10:35:44 did you try the randomisation off thing 2022-02-26 10:35:48 No 2022-02-26 10:35:58 How to do that again? 2022-02-26 10:36:00 `set disable-randomization off` or something 2022-02-26 10:36:11 or on, forgot which was the default 2022-02-26 10:37:07 why can we not just do printf debugging with ap? because the output of the shell script is redirected somewhere else? 2022-02-26 10:37:28 yeah, it's silenced 2022-02-26 10:37:39 granted we could edit the lua to echo it, assuming it would still reproduce it 2022-02-26 10:37:43 Adding str = "/home/buildozer/aports/testing/dotnet5-runtime/APKBUILD" to db.lua succeeds 2022-02-26 10:37:56 what does that do? 2022-02-26 10:38:05 limit ap list to only consider that APKBUILD 2022-02-26 10:38:12 instead of going over all of them 2022-02-26 10:38:14 ah, hm 2022-02-26 10:38:33 could you replace `_pkgver_name=${_pkgver_macro//[.0]}` with `_pkgver_name=${_pkgver_macro%.*}` 2022-02-26 10:38:49 in dotnet5-runtime?> 2022-02-26 10:38:55 in all the dotnet builds 2022-02-26 10:39:01 it's also in other donet apkbuilds 2022-02-26 10:39:10 but idk, not sure if trail and error is the best approach here ':D 2022-02-26 10:39:23 it's not indeed 2022-02-26 10:40:37 I want through recent entries in `git log testing/` and apart from the dotnet apkbuilds everything else seems rather simple in terms of utilized ash features 2022-02-26 10:41:36 if it's this then it would definitely be the patched thing, which is quite unfortunate 2022-02-26 10:41:50 or fortunate, i guess, since we know exactly what it is 2022-02-26 10:42:57 as for the lua debugging, you could change the obj.read definition to just echo stuff from the handle:read() 2022-02-26 10:43:49 psykose: right 2022-02-26 10:44:37 `return print(self.handle:read("*line"))` like this, on that line, seems to echo everything 2022-02-26 10:44:43 then adding set +x into the multiline 2022-02-26 10:44:50 but maybe this also no longer segfaults 2022-02-26 10:48:41 ikke: you could also try installing !31460 on the builders locally so we can rule out this string substitution hypothesis 2022-02-26 10:49:25 dotnet5-bootstrap is the last package that succeeds 2022-02-26 10:50:22 https://tpaste.us/Prnb 2022-02-26 10:51:23 I added echo $i >&2 to the for loop 2022-02-26 10:52:51 if dotnet5-bootstrap is the last one that successeds I assume it fails on dotnet5-build? 2022-02-26 10:55:03 will be afk for a bit, try the busybox patch if you can 🤗 2022-02-26 10:56:39 cannot reproduce it by just limiting the packages 2022-02-26 10:56:49 dotnet-* succeeds as well 2022-02-26 10:57:31 probably because of the hard to trigger aspect above 2022-02-26 10:59:07 I'll try the patch 2022-02-26 11:01:57 nmeum: btw: s/substations/substitutions/ :) 2022-02-26 11:02:15 substantiation 2022-02-26 11:05:25 dotnet5? is it for run c# like mono? 2022-02-26 11:07:34 nmeum: psykose :( 2022-02-26 11:07:36 Installed: 2022-02-26 11:07:38 busybox-1.35.0-r3 2022-02-26 11:07:40 still broken 2022-02-26 11:07:43 agh 2022-02-26 11:07:57 and here i thought it would be the end of our adventure 2022-02-26 11:14:29 if you git checkout 3.15-stable and run it, does it fix it 2022-02-26 11:15:12 of busybox? 2022-02-26 11:15:16 just the aports repo 2022-02-26 11:15:21 ah 2022-02-26 11:19:56 no, that works 2022-02-26 11:20:42 I could bisect it 2022-02-26 11:22:28 i bet it's dotnet 2022-02-26 11:22:32 yea 2022-02-26 11:22:33 the first one was 31 2022-02-26 11:22:54 you could just go straight to the 31 commit, then sed out the 5 places with that subst, but that would mean.. that the patch was incomplete at fixing the same issue 2022-02-26 11:23:00 but a bisect is better 2022-02-26 11:25:45 It's not dotnet 2022-02-26 11:27:23 wowee 2022-02-26 11:27:37 0443eef5060116ee85e508c76480aa782ea3d0c4 2022-02-26 11:28:01 uhh 2022-02-26 11:28:05 i think ppc was down before this commit 2022-02-26 11:28:14 i remember this from yesterday 2022-02-26 11:28:17 ppc has been down for two 2022-02-26 11:29:16 Well, at least on x86_64 if I checkout that commit, it fails 2022-02-26 11:29:20 if I checkout the parent, it suceeds 2022-02-26 11:29:48 and there's nothing sus in it at all 2022-02-26 11:29:48 x.x 2022-02-26 11:30:05 yeah 2022-02-26 11:30:11 let me do the same thing on ppc64 2022-02-26 11:37:09 on ppc64le it's c6fb1ad4b0c84bb4950064c49c5b34847e7c78ae 2022-02-26 11:37:17 so that makes no sense at all 2022-02-26 11:39:02 yep 2022-02-26 11:39:10 it's definitely a niche memory issue 2022-02-26 11:39:15 just lucked into by accident 2022-02-26 11:39:42 but it's consistent 2022-02-26 11:39:46 yes 2022-02-26 11:40:07 something in the iteration of all the apkbuilds made it consistent now, but i don't think its anything to do with their contents 2022-02-26 11:40:26 right 2022-02-26 11:40:29 i expect the other builders to end up in the same state soon 2022-02-26 11:40:48 I have to go now, back later 2022-02-26 11:40:53 aye 2022-02-26 12:11:17 urgs 2022-02-26 12:11:33 I think we need a backtrace then 2022-02-26 12:13:52 if only gdb didn't instantly fix it 2022-02-26 12:14:12 can we not get a coredumb at least? 2022-02-26 12:15:20 probably, i forgot to suggest that 2022-02-26 12:15:29 and i can't reproduce it locally myself 2022-02-26 12:36:48 I can't get a coredumb. In gdb, I do get the error message, but no backtrace, even with set follow-fork-mode child 2022-02-26 12:36:53 coredump* 2022-02-26 12:37:22 does ulimit -c unlimited not place one cause it's a sigsegv 2022-02-26 12:37:26 correct 2022-02-26 12:37:32 bizarre 2022-02-26 12:46:23 oh! 2022-02-26 12:46:38 testing the shell script on x68_64 I do get the segfault 2022-02-26 12:46:45 but outside of aports 2022-02-26 12:47:13 but no corefile 2022-02-26 12:47:42 outside of aports should not matter as the path is harcoded 2022-02-26 12:48:26 yeah 2022-02-26 12:48:38 the cwd does affect memory stuff or some shit so it makes sense 2022-02-26 12:49:02 I do get a backtrace in gdb now 2022-02-26 12:49:06 awesome 2022-02-26 12:49:12 need -dbg for busybox I suppose 2022-02-26 12:49:45 it needs editing for the bbconfigs too 2022-02-26 12:49:52 and probably just !strip, if you're going to build it 2022-02-26 12:49:58 i don't remember if that even works anyway 2022-02-26 12:50:13 and i would bet the segfault goes away if you add that, hah 2022-02-26 12:50:19 adding -dbg already disables stripping 2022-02-26 12:50:29 yes, but iirc that didn't work 2022-02-26 12:50:33 oh, ok 2022-02-26 12:50:39 i have tried that before on some other bb debugging 2022-02-26 12:50:41 Well, lets then just keep it :P 2022-02-26 12:50:45 :) 2022-02-26 12:51:30 still a coredump 2022-02-26 12:51:33 or atleast 2022-02-26 12:51:34 mhm 2022-02-26 12:51:35 segfault 2022-02-26 12:52:08 oh, still need to install it ofcourse :P 2022-02-26 12:52:22 installing software is generally important :p 2022-02-26 12:53:03 (No debugging symbols found in /usr/lib/debug//bin/busybox.debug) 2022-02-26 12:53:09 yep 2022-02-26 12:53:17 Do you know what I needed to adjust? 2022-02-26 12:53:30 CONFIG_DEBUG? 2022-02-26 12:54:10 yeah, then it should prompt you on rebuild 2022-02-26 12:54:13 but even that gave me no symbols 2022-02-26 12:54:23 i think i had to just make it by hand 2022-02-26 12:54:40 "The Busybox Makefile builds two versions of Busybox, one of which (busybox_unstripped) has extra information that various analysis tools can use. (This has nothing to do with CONFIG_DEBUG, leave that off when trying to optimize for size.) " 2022-02-26 12:56:33 SKIP_STRIP 2022-02-26 12:56:41 mm 2022-02-26 12:56:42 yes 2022-02-26 12:56:44 that sounds correct 2022-02-26 12:58:49 ok, success! 2022-02-26 12:59:26 nmeum: https://tpaste.us/mqYR 2022-02-26 12:59:40 we also get random ci failures 2022-02-26 12:59:47 sometimes on ppc, sometimes on x86_64, sometimes on s390x 2022-02-26 12:59:52 Hmm 2022-02-26 12:59:56 What errors? 2022-02-26 12:59:56 and repeating is consistent, but it passes for most mrs 2022-02-26 12:59:59 and i bet, this is the same 2022-02-26 13:00:00 uhh like 2022-02-26 13:00:17 https://gitlab.alpinelinux.org/wonderfulShrineMaidenOfParadise/aports/-/pipelines/112942 2022-02-26 13:00:36 always looks like that, just empty jobs 2022-02-26 13:00:50 hmm, that could indeed be related 2022-02-26 13:00:52 but almost the same thing a few minutes later- different mr 2022-02-26 13:00:52 https://gitlab.alpinelinux.org/wonderfulShrineMaidenOfParadise/aports/-/pipelines/112946 2022-02-26 13:00:53 as they use ap 2022-02-26 13:00:58 yeah 2022-02-26 13:01:36 all i can think of is the git repo magically got big enough to make this somewhat consistent over the past week 2022-02-26 13:02:32 but community is twice as large as testing, why would it fail on testing/ 2022-02-26 13:02:47 that is bizarre isn't it 2022-02-26 13:03:19 maybe the dotnet mrs do enough magic that they do the funky between-mr memory stuff and then it breaks in a random place afterward 2022-02-26 13:03:24 but they're not /that/ magic 2022-02-26 13:03:37 right 2022-02-26 13:03:57 either way, hopefully it's just caused by a single easily fixed bb memory issue and we never think about it again 2022-02-26 13:04:02 because at this rate all of edge will be down 2022-02-26 13:05:11 ey guys could you take a look on !31362? now it runs as ngricd user 2022-02-26 13:06:09 the chown only changes the user and not the group 2022-02-26 13:06:24 yes I know, since it's 600... 2022-02-26 13:06:25 which i guess is fine, but 2022-02-26 13:06:27 ye 2022-02-26 13:06:35 I don't now if its better this way 2022-02-26 13:07:08 maybe 2022-02-26 13:07:15 it could just create the user 2022-02-26 13:07:41 remove pkggroups and the group part of install script 2022-02-26 13:07:43 you need a pre-install to make the user/group too 2022-02-26 13:07:56 yes it was before I did anything 2022-02-26 13:08:06 ah, already there 2022-02-26 13:08:10 yeah, just checking 2022-02-26 13:08:18 since the context doesn't show the folder x.x 2022-02-26 13:08:22 i wish that was a feature 2022-02-26 13:08:22 what do you thing about not adding a new group? 2022-02-26 13:08:32 it should be newgrouped 2022-02-26 13:08:33 the feature is removing pam depdnency hehe 2022-02-26 13:08:47 don't see how it's related to a group 2022-02-26 13:09:23 before I modified it, it ran as 'nobody', so probably a user/group is not needed 2022-02-26 13:09:38 the benefit of having a user is that you can reload the service if the conf file is readable 2022-02-26 13:10:01 but the group is probably unused with default config 2022-02-26 13:16:40 #13560 2022-02-26 13:17:09 nmeum: let me know if you need more details 2022-02-26 13:28:20 psykose: I'm gonna add some change for avoid debug noise messages like Can't change group ID to nobody(65534): Operation not permitted! 2022-02-26 13:28:33 mhm 2022-02-26 13:29:45 looks that it expects to be started as root and then change to ServerUID 2022-02-26 13:30:07 ah 2022-02-26 13:32:13 but I don't see that it really needs it, works fine starting as ngircd 2022-02-26 13:32:44 I'm gonan take a look on the soure code 2022-02-26 13:34:34 I only see it useful for running it chrooted 2022-02-26 13:43:33 well, probably the simple way is 'sed' the default config file and let openrc start it as root 2022-02-26 13:44:41 beh, but it uses UID/GID so it can't be set on the default config 2022-02-26 13:45:12 the other fix could be skip the privelge dropping code if it is not running as root 2022-02-26 13:56:13 there is a precompiler directive, SINGLE_USER_OS which avoids all this uid/gid code 2022-02-26 13:56:24 could I just build it with it enabled? 2022-02-26 13:57:00 no idea 2022-02-26 13:57:29 I think that upstream handles this on a pretty weird way 2022-02-26 13:58:16 but well, that directive only affects this and it just remove some lines 2022-02-26 13:58:53 exactly the same that generate the log noise 2022-02-26 13:59:28 http://ix.io/3QOo 2022-02-26 14:07:37 ikke: does the script from the issue always cause the segfault? 2022-02-26 14:07:48 nmeum: on the same server, yes 2022-02-26 14:07:51 it's not intermittent 2022-02-26 14:12:20 you can probably cycle through the git history one commit at a time until it does, given what we've been seeing 2022-02-26 14:12:38 maybe i should try that 2022-02-26 14:13:26 although new git pulls on the builders on commit don't fix it after it triggers 2022-02-26 14:13:31 correct 2022-02-26 14:13:40 which is also incredibly bizarre given the random nature 2022-02-26 14:13:41 so it's after a certain commit landed, it triggers 2022-02-26 14:13:50 and that commit is different per machine 2022-02-26 14:13:54 yes 2022-02-26 14:14:03 this feels like a murder investigation 2022-02-26 14:14:34 would definitly be nice to reproduce this locally to enable the busybox ash trace debug output etc. 2022-02-26 14:14:54 nmeum: would it help if I enabled that temporarily on the builder? 2022-02-26 14:15:08 I stopped the builder so it's not uploading anything 2022-02-26 14:15:24 I haven't looked into it in detail so far 2022-02-26 14:15:29 ok 2022-02-26 14:15:45 I think it would also be ok to report it upstream 2022-02-26 14:16:05 but probably also annoying for Denys to fix without being able to reproduce it 2022-02-26 14:16:12 yeah 2022-02-26 14:36:52 Any reason why !31011 isn't merged yet? It contains a fix for a bug regarding clipboards 2022-02-26 14:37:07 psykose, Cogitri 2022-02-26 16:00:21 ikke: this is difficult to debug without knowing the shell code that causes this (e.g. the specific line) and without being able to reproduce it locally. it seems it performs a variable/command substitution with a value that points to 0x1 the value itself seems to originate in an AST node but not sure why that node is created with that value 2022-02-26 16:00:56 nmeum: I can execute the script with -x to see of that helps 2022-02-26 16:00:58 https://git.busybox.net/busybox/tree/shell/ash.c#n166 2022-02-26 16:01:05 you could try defining that macro with DEBUG=2 2022-02-26 16:01:11 *as DEBUG=2 2022-02-26 16:01:21 that might allow us to narrow down the code that is causing this 2022-02-26 16:01:45 nmeum: sh -x does not expost the segfault 2022-02-26 16:02:29 `#define DEBUG 2` should enable various trace debug output statements in ash itself 2022-02-26 16:02:35 right 2022-02-26 16:02:36 let me try that 2022-02-26 16:11:35 nmeum: I don't seem to be getting more output 2022-02-26 16:12:49 oh 2022-02-26 16:12:53 written to ./trace 2022-02-26 16:14:57 nmeum: https://dev.alpinelinux.org/~kevin/busybox_trace.log 2022-02-26 16:18:24 large 2022-02-26 16:19:26 yes, that's why I put it on dev 2022-02-26 16:34:24 Is this sus? "[37384] pending s:0 i:0(supp:0) argstr: evalvar('')" 2022-02-26 16:35:20 A 0f byte 2022-02-26 16:38:47 yeah 2022-02-26 16:38:50 at least to me 2022-02-26 16:58:43 There are a lot of non-ascii bytes in that log 2022-02-26 17:11:20 aarch64 is now down as well 2022-02-26 17:11:47 seems to be one a day so far :p 2022-02-26 17:12:05 just 5 more and we can lose every builder 2022-02-26 17:21:09 i've built busybox with clang+ASan 2022-02-26 17:21:12 and am now doing a bisect 2022-02-26 17:21:18 to see what commit caused this in aports 2022-02-26 17:26:13 hmm 2022-02-26 17:29:02 with the patch from !31460 i can no longer make it blow up with ASan 2022-02-26 17:29:19 ikke did say he built it and it still blew up after 2022-02-26 17:29:31 unless he forgot to install it properly :) 2022-02-26 17:29:31 do we have a new backtrace ? 2022-02-26 17:29:36 it was the one posted already 2022-02-26 17:29:40 impossible 2022-02-26 17:29:42 hm 2022-02-26 17:30:37 that would mean it was either never installed, or it was reverted while adding the debugging options 2022-02-26 17:32:21 i'm quite certain that patch fixes it 2022-02-26 17:33:19 huh 2022-02-26 17:33:36 I applied that patch, built, and verified -r3 was installed 2022-02-26 17:35:34 Let me try once more 2022-02-26 17:35:50 aarch64 fixed itself after a new commit as well, hah 2022-02-26 17:35:59 so it's definitely not 'any future' 2022-02-26 17:36:44 you're right, actually 2022-02-26 17:36:48 that patch isn't enough 2022-02-26 17:36:58 ASan complains about mempcpy source+dest overlap 2022-02-26 17:37:02 that's our problem 2022-02-26 17:37:06 is it the same issue, or is it in an entirely place 2022-02-26 17:38:27 dunno i need debug symbols 2022-02-26 17:38:38 silly me forgot to build with -ggdb 2022-02-26 17:38:43 :) 2022-02-26 17:38:49 https://tpaste.us/mqYR 2022-02-26 17:38:52 That was the last bt 2022-02-26 17:40:46 ${foo:0:-1} makes busybox sh explode very reliably 2022-02-26 17:40:52 under ASan 2022-02-26 17:41:57 doing a little more testing to verify my theory 2022-02-26 17:42:39 I just tried again 2022-02-26 17:42:45 still getting the segfault 2022-02-26 17:42:53 with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31460.patch applied 2022-02-26 17:42:54 yes 2022-02-26 17:43:05 its because of this mempcpy thing 2022-02-26 17:43:10 working on it :) 2022-02-26 17:43:13 ok, good :) 2022-02-26 17:50:46 this stackspace thing is fucko 2022-02-26 17:50:52 its getting corrupted 2022-02-26 17:53:23 loc = mempcpy(startp, startp + pos, len); 2022-02-26 17:53:27 this is just... wrong 2022-02-26 17:54:14 lovely... 2022-02-26 17:56:08 changing that to a memmove 2022-02-26 17:56:11 it no longer explodes 2022-02-26 17:56:13 on ASan 2022-02-26 18:04:54 ikke: https://tpaste.us/zlRJ 2022-02-26 18:05:08 Ok, will test 2022-02-26 18:05:58 lol they used mempcpy where memmove was needed too? :/ 2022-02-26 18:08:11 yes 2022-02-26 18:08:17 in some cases, pos is 0 2022-02-26 18:08:19 that's what blows it up 2022-02-26 18:08:42 wonderful :) 2022-02-26 18:11:07 hmm 2022-02-26 18:11:14 Segmentation fault (core dumped) 2022-02-26 18:12:00 abuild clean unpack prepare build rootpkg 2022-02-26 18:12:19 which part of the build 2022-02-26 18:12:20 abuild-apk add ~/packages/main/x86_64/busybox-1.35.0-r4.apk 2022-02-26 18:12:25 mm 2022-02-26 18:12:57 https://tpaste.us/XK5l 2022-02-26 18:16:43 :sadface: 2022-02-26 18:17:19 maybe you should let ariadne do it on the builder directly :p 2022-02-26 18:17:59 ikke: new backtrace, please? 2022-02-26 18:18:09 Ariadne: ok, need to rebuild with debug symbols 2022-02-26 18:18:56 that patch is necessary regardless 2022-02-26 18:21:53 https://tpaste.us/Lm8V 2022-02-26 18:23:05 same location, hah 2022-02-26 18:25:01 not sure why asan isn't dying on it 2022-02-26 18:25:17 okay lets figure out what the fuck argstr actually does 2022-02-26 18:25:20 probably something terrible 2022-02-26 18:25:23 because it's busybox 2022-02-26 18:25:39 busybox is, don't worry, on my list of alpine things to rewrite from scratch 2022-02-26 18:26:54 https://git.busybox.net/busybox/tree/shell/ash_remove_unnecessary_code_in_backquote_expansion.patch 2022-02-26 18:26:57 i love how there's this 2022-02-26 18:27:02 random patch 2022-02-26 18:27:04 just chilling here 2022-02-26 18:27:39 that's a very cute patch 2022-02-26 18:29:21 line 6904 is p = expari(p, flag | inquotes); 2022-02-26 18:29:40 i don't like where this rabbithole is going 2022-02-26 18:30:41 from there, we go to 2022-02-26 18:30:48 line 6744, p = argstr(start, flag & EXP_DISCARD); 2022-02-26 18:31:28 start == start@entry 2022-02-26 18:32:31 that takes us back to argstr, but with EXP_DISCARD flag 2022-02-26 18:34:13 so its shell arithmetic that is triggering it 2022-02-26 18:35:10 we go through argstr again, landing at line 6875, 2022-02-26 18:35:16 p = evalvar(p + 1, flag | EXP_QUOTED) + 1; 2022-02-26 18:35:44 but we cannot be NULL here 2022-02-26 18:36:09 because p@entry is still a valid pointer in evalvar 2022-02-26 18:36:21 however that + 1 is suspicious 2022-02-26 18:38:34 p = strchr(p, '=') + 1; //TODO: use var_end(p)? 2022-02-26 18:38:44 here's our 0x1 2022-02-26 18:39:09 todo :p 2022-02-26 18:39:27 so, we are looking for an APKBUILD with shell arithmetic that does not have '=' 2022-02-26 18:39:35 ok 2022-02-26 18:39:39 let's see if I can find soemthing 2022-02-26 18:40:01 however, if strchr returns NULL, we should fail 2022-02-26 18:40:10 8: --make-jobs $((JOBS > 16 ? 16 : JOBS)) \ 2022-02-26 18:40:20 116: KBUILD_BUILD_VERSION="$((pkgrel + 1 ))-Alpine" 2022-02-26 18:40:37 ah, that last one has =? 2022-02-26 18:40:44 in testing specifically i think 2022-02-26 18:40:52 this is in testing 2022-02-26 18:40:54 ah 2022-02-26 18:41:44 26: pypy ../../rpython/bin/rpython --opt=jit --shared --make-jobs $(( JOBS > 16 ? 16 : JOBS )) targetpypystandalone 2022-02-26 18:42:03 ah, that was recent 2022-02-26 18:42:37 ah no 2022-02-26 18:42:42 pypy itself hasn't been touched in a long time 2022-02-26 18:42:51 pypy-stage0/APKBUILD 2022-02-26 18:43:00 stage0 2022-02-26 18:43:14 that doesn't have it on 26: 2022-02-26 18:43:26 oh, that was pypy3/APKBUILD 2022-02-26 18:43:45 but all 3 do yeah 2022-02-26 18:44:22 try moving those apkbuilds out of the way 2022-02-26 18:44:26 ok 2022-02-26 18:44:27 and seeing if `ap list` still explodes 2022-02-26 18:46:08 pypy/APKBUILD 2022-02-26 18:46:34 pypy-stage0/APKBUILD 2022-02-26 18:47:00 those 2 2022-02-26 18:47:21 rewrite them to remove the shell math? 2022-02-26 18:47:30 i can do that for now 2022-02-26 18:47:39 i think its the ternary 2022-02-26 18:48:10 do i just set it to 16 2022-02-26 18:48:28 [[ "$JOBS" -gt 16 ]] && JOBS=16 2022-02-26 18:48:37 got it 2022-02-26 18:50:52 i would do pypy3 just for good measure too 2022-02-26 18:50:58 psykose did 2022-02-26 18:51:18 i also find this defensive jobs stuff quite weird 2022-02-26 18:51:23 like in all the meson stuff 2022-02-26 18:51:27 ok, let me clean up the builders and start it again 2022-02-26 18:51:33 not the capping, but just JOBS:-something 2022-02-26 18:51:39 it is never not defined in any default config 2022-02-26 18:51:54 psykose: afaik, it's not set by default in abuild.conf 2022-02-26 18:52:02 or at least, it used to be not set 2022-02-26 18:52:08 It was added recently 2022-02-26 18:52:11 it is set these days 2022-02-26 18:52:25 it is 2022-02-26 18:52:28 even in 3.12 2022-02-26 18:52:30 it was like.. =2 2022-02-26 18:52:58 i knew that one since i was doing some 3.12 rebuilds and was wondering why it was so slow :p 2022-02-26 18:53:04 now it's nproc 2022-02-26 18:53:30 psykose: the defensive jobs stuff is likely due to CI 2022-02-26 18:53:39 it was probably running out of ram 2022-02-26 18:53:51 but the abuild in the ci container would always have it set 2022-02-26 18:53:55 i don't mean the ones to reduce the number 2022-02-26 18:54:15 just checking for its existence, but it makes sense that some years ago it wasn't set at all 2022-02-26 18:54:15 :) 2022-02-26 18:54:16 all good 2022-02-26 18:55:20 glad we were able to figure it out 2022-02-26 18:55:27 it still needs fixing 2022-02-26 18:55:30 in busybox 2022-02-26 18:55:41 yeah 2022-02-26 18:55:45 i have no idea 2022-02-26 18:55:45 how to fix that 2022-02-26 18:55:47 :D 2022-02-26 18:55:55 ^_^ me either 2022-02-26 18:55:59 report upstream? 2022-02-26 18:56:08 i'll leave it to our new busybox maintainer 2022-02-26 18:56:09 nmeum 2022-02-26 18:56:11 to figure out 2022-02-26 18:56:12 :D 2022-02-26 18:56:12 wow 2022-02-26 18:56:19 big maintainer nmeum 2022-02-26 18:56:27 i am technically not the busybox maintainer! 2022-02-26 18:56:31 oh 2022-02-26 18:56:37 :p 2022-02-26 18:56:38 i thought you took it from ncopa 2022-02-26 18:56:39 'technically' 2022-02-26 18:56:43 yes you are 2022-02-26 18:56:43 de facto 2022-02-26 18:56:45 be proud of it 2022-02-26 18:56:53 haha 2022-02-26 18:56:55 :p 2022-02-26 18:57:08 thanks for volunteering nmeum ! 2022-02-26 18:57:15 ACTION tripple checks the builder is cleaned up 2022-02-26 18:57:35 make sure world is unfucked for sure :p 2022-02-26 18:57:39 it is 2022-02-26 18:57:40 I might have time to look into fixing it tomorrow or at least report it to Denys 2022-02-26 18:59:03 removed the -r3/-r4 packagexs, aports repo is clean, world is clean, lua-aports is vanilla 2022-02-26 18:59:11 \o/ 2022-02-26 18:59:19 ok 2022-02-26 18:59:21 kick it 2022-02-26 18:59:23 lets goooo 2022-02-26 18:59:26 done 2022-02-26 18:59:44 you forgot ppc 2022-02-26 18:59:53 ..as it deserves to be 2022-02-26 18:59:56 :) 2022-02-26 19:00:00 can we just permanently forget ppc 2022-02-26 19:00:08 awilfox will be so sad :( 2022-02-26 19:00:09 psykose: I was just working on ppc :) 2022-02-26 19:00:12 :p 2022-02-26 19:00:54 pulling git for 10 years 2022-02-26 19:01:18 oops :) 2022-02-26 19:02:32 do we have a minimal shell script for reproducing the crash now btw? is it just `$((JOBS > 16 ? 16 : JOBS))` sufficient? 2022-02-26 19:02:53 i think it still needed more things, since just ap list for me doesn't crash it, but it causes inconsistent things 2022-02-26 19:03:01 yeah 2022-02-26 19:03:04 i mean 2022-02-26 19:03:08 if you spam that line like 45 times 2022-02-26 19:03:12 i expect it to make it easier 2022-02-26 19:03:13 probably 2022-02-26 19:03:25 we had pypy in the repos for forever with that 2022-02-26 19:03:30 recently we added a 3rd copy for stage0 2022-02-26 19:03:31 and poof 2022-02-26 19:03:34 everything broke, slowly 2022-02-26 19:03:43 But not even immediately 2022-02-26 19:03:49 yeah 2022-02-26 19:03:50 fucked up 2022-02-26 19:04:33 right but does it crash immediately with ASAN on that line? 2022-02-26 19:04:35 Ariadne: ^ 2022-02-26 19:04:38 valgrind doesn't complain 2022-02-26 19:06:48 hmm, go seems to be hanging on riscv64 2022-02-26 19:07:08 do you have any metric for how long it usually takes 2022-02-26 19:07:13 i assume 3 days is not intended 2022-02-26 19:07:20 not really 2022-02-26 19:07:35 those would be some fun metrics to have 2022-02-26 19:07:40 hm 2022-02-26 19:10:53 nmeum: no 2022-02-26 19:12:03 so we don't really have a way to reliable reproduce this locally, right? 2022-02-26 19:12:15 correct 2022-02-26 19:12:19 with valgrind I also only get the overlapping memcpy errors when sourcing all apkbuilds from ./testing 2022-02-26 19:12:55 ap list still crashes 2022-02-26 19:13:06 should also be a hell lot of fun to fuzz the parser in ash 🙈 2022-02-26 19:13:44 ikke: you mean right now? 2022-02-26 19:13:46 yes 2022-02-26 19:13:52 x.x 2022-02-26 19:13:53 oh nooo 2022-02-26 19:14:03 ok 2022-02-26 19:14:04 how about 2022-02-26 19:14:11 ln -sf /bin/bash /bin/sh 2022-02-26 19:14:11 see 2022-02-26 19:14:12 very easy 2022-02-26 19:14:13 haha 2022-02-26 19:14:14 webscale! 2022-02-26 19:16:46 how did we come to the conclusion that the problem is the jobs arithmetic in pypy? 2022-02-26 19:17:01 ariadne was reading through the code and thought it would be shell arithmetic without = 2022-02-26 19:17:18 the only 3 instances were in pypy 2022-02-26 19:17:35 i.e. --arg $(()), everything else has a = before 2022-02-26 19:17:38 nmeum: and it fixed once I removed those APKBUILD files completely 2022-02-26 19:17:42 yeah 2022-02-26 19:19:09 ah, they don't check the strchr return value and if it doesn't have '=' they do `NULL + 1` -> 0x1. i see 2022-02-26 19:19:13 oh boyyy 2022-02-26 19:19:19 this code is something else 2022-02-26 19:19:40 ok, but why does ap list still crash then? 2022-02-26 19:19:53 it was just not fixed i guess 2022-02-26 19:19:58 yet another memory issue 2022-02-26 19:20:07 the reason it got 'fixed' is because the issue is sporadic to begin with 2022-02-26 19:20:38 It's consistent when it happens though 2022-02-26 19:21:56 yeah, barring changes 2022-02-26 19:31:34 yep, ppc still dead on testing 2022-02-26 19:31:35 x.x 2022-02-26 19:33:40 removing those 3 packages there does not fix it either 2022-02-26 20:16:41 amazing 2022-02-26 20:16:47 yup 2022-02-26 20:16:55 waiting for the x86_64 builder to go idle again 2022-02-26 20:16:59 but rust.. 2022-02-26 20:17:15 i would let it finish community 2022-02-26 20:17:22 yes 2022-02-26 20:17:24 have fun with ppc in the meantime 2022-02-26 20:17:43 also i wonder why aarch64 died then came back 2022-02-26 20:17:46 it was dead for like 2 commits 2022-02-26 20:17:47 I could not reproduce it with a script under ppc64le 2022-02-26 20:17:51 well 2022-02-26 20:17:53 ah 2022-02-26 20:18:01 "\017" is arithmetic control code 2022-02-26 20:18:08 in their AST 2022-02-26 20:18:08 idk 2022-02-26 20:18:12 Ariadne: ah ok 2022-02-26 20:18:13 busybox ash is a horror show 2022-02-26 20:19:39 I notice 2022-02-26 20:20:35 so i guess the question now is 2022-02-26 20:20:40 where is this \017 coming from 2022-02-26 20:21:00 The script that consistently fails on x86_64 when the problem is there succeeds on ppc64le 2022-02-26 20:21:06 but ap list fails on ppc64le 2022-02-26 20:25:04 could just revert 2022-02-26 20:25:07 to busybox 1.34 2022-02-26 20:25:56 are you sure that even fixes it 2022-02-26 20:26:13 i bet it does not 2022-02-26 20:26:45 could just 2022-02-26 20:26:47 make bash 2022-02-26 20:26:49 the shell 2022-02-26 20:26:50 ^_^ 2022-02-26 20:26:56 i already proposed that above 2022-02-26 20:27:05 2 in agreement, motion passed 2022-02-26 20:27:10 great minds think alike I suppose 2022-02-26 20:27:19 i mean, for now 2022-02-26 20:28:01 i don't think it's a good idea 2022-02-26 20:28:10 having bash exist affects builds 2022-02-26 20:28:13 and it strays from the ci env 2022-02-26 20:28:36 dash is sadly not an option 2022-02-26 20:29:39 x_x 2022-02-26 20:29:41 x_x 2022-02-26 20:30:29 what busybox did 3.13 ship with 2022-02-26 20:30:36 it seems the complaints began with 3.13 2022-02-26 20:30:46 which complaints are you referring to specifically 2022-02-26 20:30:47 1.32.1 2022-02-26 20:31:01 so, bisect all the way back to 1.31 x_x 2022-02-26 20:47:08 bisect? why not just read the log? 2022-02-26 20:47:27 dalias: do you volunteer? :) 2022-02-26 20:47:36 "parser: introduced a memory bug" 2022-02-26 20:48:13 bisect is faster than reading the log 2022-02-26 20:49:41 O(n) vs O(log n) 2022-02-26 20:50:57 But O != O 2022-02-26 20:52:04 in this case it's about even, cause there's about 110 commits to look through 2022-02-26 20:52:40 ~10 vs ~100 steps? 2022-02-26 20:52:57 if we revert to an older busybox version we get all the old bugs back 2022-02-26 20:53:21 are they worse than the new bugs? 2022-02-26 20:53:27 ikke: more in the sense of reading the commit and going 'ah yes this fucked up the behaviour' which is admittedly less scientific than the actual bisect testing 2022-02-26 20:59:59 honestly i want to just port the freebsd shell as /bin/sh and drop busybox ash 2022-02-26 21:02:49 why does nobody ever remember zsh exists 2022-02-26 21:03:26 It's a different shell 2022-02-26 21:03:53 different? 2022-02-26 21:03:58 it's a bourne-compatible shell 2022-02-26 21:04:29 it's the most compliant you'll find when called as /bin/sh 2022-02-26 21:05:12 uh oh 2022-02-26 21:05:15 i see it coming 2022-02-26 21:05:18 s6-sh 2022-02-26 21:05:38 not even in your worst nightmares 2022-02-26 21:05:45 dream for me 2022-02-26 21:08:46 skarnet: i'd prefer to stay in almquist family, but maybe zshell is ok 2022-02-26 21:08:50 busybox shell 2022-02-26 21:08:55 i mean 2022-02-26 21:08:58 its kinda frustratin 2022-02-26 21:08:59 g 2022-02-26 21:09:08 because we put a lot of work in enhancing it 2022-02-26 21:09:13 but 2022-02-26 21:09:14 I really have no horse in this race 2022-02-26 21:09:40 i dont think denys is maintaining it very well x_x 2022-02-26 21:09:41 it's just that people always immediately go back to bash or BSD shells when they're frustrated with small alternatives 2022-02-26 21:09:49 well 2022-02-26 21:09:51 busybox ash 2022-02-26 21:09:52 and that's surprising because zsh is everything bash wishes it could be 2022-02-26 21:09:56 is an almquist-family shell 2022-02-26 21:10:04 but denys has done all of this sizecoding crap to it 2022-02-26 21:10:09 so its a total nightmare to follow 2022-02-26 21:10:14 I know 2022-02-26 21:10:54 so switching to freebsd sh keeps us with an almquist shell 2022-02-26 21:11:05 but without the sizecoding crap 2022-02-26 21:11:12 that's the theory anyway 2022-02-26 21:11:13 busybox makes choices that were valid 20ish years ago, that are more of an inconvenience today 2022-02-26 21:11:29 well, yes 2022-02-26 21:11:41 yeah, instead of sizecoding crap, you get bsdism crap 2022-02-26 21:11:42 at this point, i think clarity of code is more important than sizecoding 2022-02-26 21:11:54 busybox ash is already bsdism crap 2022-02-26 21:12:05 it's an almquist shell, the original one was in 4.3 BSD 2022-02-26 21:12:36 yeah but I mean in the way it's coded, the primitives it uses, etc. 2022-02-26 21:13:22 like, i'm pretty sure these parser bugs are due to sizecoding crap 2022-02-26 21:13:23 there is valid criticism you can throw at Denys but he does understand Linux 2022-02-26 21:13:36 it may be 2022-02-26 21:13:55 but tbh shell parsing is such a nightmare that it's easy to mess up even without sizecoding crap 2022-02-26 21:14:04 how bout we actually fix the builders first :p 2022-02-26 21:14:11 and ternary arithmetic expressions isn't exactly the thing you test every day 2022-02-26 21:14:31 psykose: yeah well, idk how to do that 2022-02-26 21:14:36 me either 2022-02-26 21:14:36 other than making /bin/sh something else 2022-02-26 21:15:15 if the builders use complex arithmetic expressions in shell then I have another idea >.> 2022-02-26 21:15:35 they're not, and apparently that was not even the issue 2022-02-26 21:15:38 it's not complex arithmetic, and it's used in some aports 2022-02-26 21:16:11 i disagree, 2022-02-26 21:16:19 we've been solving this murder case for 2 days now 2022-02-26 21:16:22 because there is parser thing 2022-02-26 21:16:24 CTLARI 2022-02-26 21:16:31 which is for arithmetic 2022-02-26 21:16:36 so it is related somehow 2022-02-26 21:16:51 do you want to remove every $(()) instead 2022-02-26 21:17:10 okay 2022-02-26 21:17:15 what happened 2 days ago 2022-02-26 21:17:18 to make this noticable 2022-02-26 21:17:26 have we tried to rebase aports? 2022-02-26 21:17:44 we have tried bisecting it 2022-02-26 21:17:49 there's only 7 more instances 2022-02-26 21:17:58 nothing happened 2022-02-26 21:18:01 it just randomly failed 2022-02-26 21:18:06 and the specific commit was not the issue 2022-02-26 21:18:10 nothing randomly fails 2022-02-26 21:18:13 it was only on ppc 2022-02-26 21:18:24 Ariadne: they're 'random' commits that seem to trigger it 2022-02-26 21:18:26 yesterday x86_64 failed the same way 2022-02-26 21:18:33 today aarch64, then fixed itself 2022-02-26 21:18:37 there is no commit that causes it 2022-02-26 21:18:53 we reproduced it outside of lua, so it's just ash 2022-02-26 21:19:00 shrug 2022-02-26 21:19:09 it is definitely some other dangling memory issue 2022-02-26 21:19:22 which seems to depend on the hardware 2022-02-26 21:19:24 or something 2022-02-26 21:19:31 because it cannot be reproduced 2022-02-26 21:19:46 memory is affected by lots of things 2022-02-26 21:20:14 "why now" is still a relevant question 2022-02-26 21:20:23 though perhaps "now" is not "now" and we just noticed it now 2022-02-26 21:20:46 Ariadne: there are certain commits, if I checkout the parent, the problem disappears 2022-02-26 21:20:57 but different commits on different builders 2022-02-26 21:21:13 do you have an example commit 2022-02-26 21:21:14 the commit adding apko was one of them 2022-02-26 21:21:24 that one failed for x86_64 2022-02-26 21:21:34 how many packages were in testing 2022-02-26 21:21:39 when apko was added? 2022-02-26 21:21:43 0443eef5060116ee85e508c76480aa782ea3d0c4 2022-02-26 21:21:51 Ariadne: around ~2k packages in testing 2022-02-26 21:22:01 i guess the exact number matters 2022-02-26 21:22:07 ~2.5 2022-02-26 21:22:11 but that number is the same on all the builders 2022-02-26 21:22:13 probably 2022-02-26 21:22:18 unless someone left a stray directory 2022-02-26 21:22:33 since the git is the same 2022-02-26 21:22:45 2592 2022-02-26 21:23:06 hmm 2022-02-26 21:23:25 same one the builder as on my dev instance 2022-02-26 21:23:29 s/one/on/ 2022-02-26 21:23:29 ikke meant to say: same on the builder as on my dev instance 2022-02-26 21:23:30 well valgrind and asan are clean 2022-02-26 21:24:04 should run them on the thing that still crashes 2022-02-26 21:25:03 no, the answer is in the backtrace 2022-02-26 21:25:10 just have to go deeper 2022-02-26 21:45:24 https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/ 2022-02-26 21:47:31 Yes 2022-02-26 21:47:40 I'm aware 2022-02-26 21:48:19 Thanks 2022-02-26 21:48:23 lobotomizing the ash memory pool code 2022-02-26 21:48:29 to see if that makes ASan more... talkative 2022-02-26 21:48:44 why does this have a memory pool 2022-02-26 21:48:44 inb4 fixed issue 2022-02-26 21:48:48 in the year of our lord 2022 2022-02-26 21:49:01 malloc isn't slow anymore damnit 2022-02-26 21:49:18 https://usercontent.irccloud-cdn.com/file/o5zxbEZC/Screen%20Shot%202022-02-26%20at%203.49.13%20PM.png 2022-02-26 21:49:18 it is with malloc-ng 2022-02-26 21:49:26 not that slow 2022-02-26 21:49:29 indeed not 2022-02-26 21:49:49 yes, because busybox 2022-02-26 21:49:50 lmao 2022-02-26 21:49:50 targets 2022-02-26 21:49:51 504 2022-02-26 21:49:52 DEC Ultrix 2022-02-26 21:50:08 there's no BSD crap left in busybox ash 2022-02-26 21:50:11 what are u talking about 2022-02-26 21:50:26 504 timeout 2022-02-26 21:51:36 I think we should first of all fix all the bugs we are aware of at the moment in main/busybox and than see if it behaves any differently 2022-02-26 21:51:54 like the overlapping memcpy issue, the issue with bash pattern substitutions and the issue with certian arithmetic expressions 2022-02-26 21:52:05 first two are fixed 2022-02-26 21:52:15 not in alpine 2022-02-26 21:52:18 in theory 2022-02-26 21:52:19 we fixed it on builder 2022-02-26 21:52:21 sure, but we have patches 2022-02-26 21:52:31 i mean ''fixed'' not deployed 2022-02-26 21:52:34 whatever 2022-02-26 21:52:39 i think i'm done with this for now 2022-02-26 21:52:50 by fixing I mean comitting the patches to aports.git 2022-02-26 21:53:01 sure 2022-02-26 21:53:04 i'll leave you to it 2022-02-26 21:53:05 so we can be certain that we don't run into this anymore 2022-02-26 21:53:08 use the v2 patch 2022-02-26 21:58:20 nmeum: longer term i think we should just replace busybox ash with zsh 2022-02-26 21:59:04 what would we gain from that? 2022-02-26 22:00:39 what do we gain (other than heisenbugs) from keeping ash as default? 2022-02-26 22:00:51 yes, we have put a lot of work into ash 2022-02-26 22:00:55 but... 2022-02-26 22:01:04 don't get me wrong, I would be open to replace ash with something else but not sure if zsh fits our needs 2022-02-26 22:01:48 i guess the question is how minimalized can we make zsh 2022-02-26 22:02:06 I personally use OpenBSD ksh as my default shell but it's also a bit quirky 2022-02-26 22:02:28 (loksh/oksh in alpine) 2022-02-26 22:02:44 i think zsh is attractive because it can be extended 2022-02-26 22:03:08 if we change the shell, it should be to one that is posix-compatible, but also relatively featureful 2022-02-26 22:05:44 *nod* 2022-02-26 22:10:45 zsh is the default on a few systems now, notably MacOS 2022-02-26 22:11:00 so i think there is familiarity with it from that 2022-02-26 22:13:39 i think it needs further discussion (maybe on the ml or the tsc issue tracker) but it's certainly something we could consider doing in the long run 2022-02-26 22:17:20 i have launched a very scientific poll 2022-02-26 22:20:49 so far the very scientific poll overwhelmingly indicates zsh 2022-02-26 22:21:34 we should ask the USG 2022-02-26 22:22:52 we should not 2022-02-27 02:25:59 <__abby__> /part 2022-02-27 04:28:25 new theory: the tree isn't getting corrupted, busybox is just not properly initializing memory 2022-02-27 04:28:45 going to sleep on that theory, but it makes sense to me anyway 2022-02-27 06:24:22 Ariadne: fwiw mksh is a fine shell for sh 2022-02-27 06:31:53 sure 2022-02-27 06:31:57 busybox ash is just tiring 2022-02-27 09:51:44 keep in mind though that all the other shells (zsh, oksh, mksh, …) are also written in C and thus potentially subject to the exact same kind of problems we are facing atm with ash 2022-02-27 09:52:45 I think Ariadne's argument is that busybox' sizecoding practice make issues harder to spot / fix 2022-02-27 09:56:24 right, keep in mind though that the other posix shell also have really ancient code parts (especially the bsd ones) which are also not necessarily easier to comprehend 2022-02-27 09:59:07 mrsh exists but needs debugging 2022-02-27 10:07:04 what is the current status of the builders? they don't crash atm but `ap list` still crashes, right? 2022-02-27 10:10:03 x86_64 and ppc64le still fail when they reach the testing repo 2022-02-27 10:11:16 `ap list is just an easy command to trigger the same issue that the builders are failing on 2022-02-27 10:12:29 so the change to the pypy aports didn't fix anything? 2022-02-27 10:12:35 nmeum: it appears so 2022-02-27 10:13:01 waiting for x86_64 to go idle again to continue investigation 2022-02-27 10:14:00 in the output of ash with `#define DEBUG 2` the last evalvar invocation is also on a dotnet apkbuild, not on a pypy apkbuild 2022-02-27 10:14:46 That was based on the stacktrace we got 2022-02-27 10:15:35 And based on my understanding, earlier packages can affect later packages 2022-02-27 10:21:14 i think it’s uninitialized data in the AST 2022-02-27 10:21:33 make stalloc zero what it returns 2022-02-27 10:21:40 it might help 2022-02-27 10:23:29 I would really like to be able to reproduce this localyl, it would make debugging so much easier ;_; 2022-02-27 10:24:02 certainly 2022-02-27 10:24:45 > [37384] pending s:0 i:0(supp:0) argstr: evalvar:'_referencesdir=/usr/share/dotnet/artifacts/3.1.416SourceBuildReferencePackages' 2022-02-27 10:24:46 > [37384] pending s:0 i:0(supp:0) argstr: evalvar('') 2022-02-27 10:25:14 the second evalvar invocation passes garbage to evalvar 2022-02-27 10:25:29 maybe there is indeed uninitialized data in the AST somewhere 2022-02-27 10:25:37 have we tried running ash with valgrind on the builders yet? 2022-02-27 10:26:58 no 2022-02-27 10:27:11 If I can get some guidance, I can try that 2022-02-27 10:27:53 that test script from the gitlab issue still reproduces the segfault on the builders, yes? if so just run that testscript as `valgrind busybox ash test.sh` 2022-02-27 10:28:01 ok 2022-02-27 10:28:22 the script still segfaults 2022-02-27 10:29:02 does valgrind warn about uninitialized memory accesses? 2022-02-27 10:30:29 https://tpaste.us/dPmx 2022-02-27 10:30:44 it does not segfault under valgrind 2022-02-27 10:31:15 the output you posted is just the summary at the end, doesn't it output anything else? 2022-02-27 10:31:33 Full output: https://tpaste.us/41eJ 2022-02-27 10:31:36 on my system, running the test script with valgrind at least reports the overlapping memcpy's that Ariadne also discovered with asan 2022-02-27 10:31:57 I needed to run it again to suppress stdout 2022-02-27 10:32:05 > Conditional jump or move depends on uninitialised value(s) 2022-02-27 10:32:07 ahahaha! 2022-02-27 10:32:25 I suppose it would help to have debug symbols 2022-02-27 10:32:29 can you run the script with a busybox version that has debug symbols 2022-02-27 10:32:30 yes! 2022-02-27 10:32:37 Then I have to wait 2022-02-27 10:32:59 builder is at 84% 2022-02-27 10:33:26 I think I will also just go ahead and push my fix for the string substitution thing and Ariadne memcpy/memmove fix 2022-02-27 10:33:36 👍 2022-02-27 10:33:58 according to the busybox ml denys is currently busy with other things and might take a while for him to review these patches 2022-02-27 10:34:10 Shells are hard... 2022-02-27 10:39:29 will be afk for a bit, but valgrind output with debug symbols might actually tell us where the uninitialized memory originates which would be great 2022-02-27 10:40:03 nmeum: will work on that 2022-02-27 11:15:53 got the output, added it to the issue 2022-02-27 12:24:18 c7s: isn't mrsh dead: https://git.sr.ht/~emersion/mrsh ? 2022-02-27 12:34:05 jvoisin: emersion isn't actively working on it, but the code is still there, either way it's not finished/usable, there are a few features left to implement plus some bugs to fix 2022-02-27 12:34:11 but it's not like anyone has a monopoly on doing that work 2022-02-27 12:37:51 ikke: can you run valgrind with --track-origins=yes 2022-02-27 12:37:59 that should tell us where the uninitialized memory originates 2022-02-27 12:46:35 nmeum: https://tpaste.us/EMjW 2022-02-27 13:14:07 ok, the tokenizer is scuffed (don't know why yet) but this seems to be triggered by the dotnet apkbuilds 2022-02-27 13:15:05 interesting 2022-02-27 13:15:16 I can reproduce it locally with valgrind as well now 2022-02-27 13:15:52 if I remove the builddir, _sbrpdir, _artifactsdir, _referencesdir, and _cli_root declaration from all dotnet apkbuilds I don't get the warnings 2022-02-27 13:16:01 rm dotnet*/APKBUILD does fix it 2022-02-27 13:16:08 but that did pypy*/APKBUILD as well 2022-02-27 13:16:39 it is a bug in ash that needs fixing, I just need to understand the code first 2022-02-27 13:17:12 that's bizarre cause the same shell stuff is used in other places too 2022-02-27 13:17:57 or hm 2022-02-27 13:18:09 ${_xyz/-*} is not something i've seen much of 2022-02-27 13:18:14 usually has one more slash 2022-02-27 13:19:07 I don't think it has to do with parsing of that particular expression 2022-02-27 13:19:24 those are the only 'fancy' shell things in those variables you mention 2022-02-27 13:19:35 and can be replaced with %%-* 2022-02-27 13:20:07 although yes, it's not the immediate usage, wa 2022-02-27 14:09:01 nmeum it won’t 2022-02-27 14:09:20 ash uses memory pooling code 2022-02-27 14:09:44 which is why ASan has little visibility into it 2022-02-27 14:10:15 what are you refering to? :D 2022-02-27 14:14:00 stalloc 2022-02-27 14:14:09 the “stack” stuff 2022-02-27 14:15:34 yeah, because of the memory pooling valgrind only tells you that the value originates in stalloc which isn't super helpful 2022-02-27 14:31:59 my suggestion is that we do something like this 2022-02-27 14:33:22 https://tpaste.us/0wDy 2022-02-27 14:33:38 i think what happens is that there is uninitialized nodes in the AST 2022-02-27 14:34:12 and so then if things get evaluated in the right order 2022-02-27 14:34:24 we wind up with an AST evaluation with a "ghost" arithmetic node 2022-02-27 14:34:28 because it didn't get zero'd 2022-02-27 14:34:46 we can just replace the ckmalloc with ckzalloc in stalloc but that doesn't really solve the problem 2022-02-27 14:35:08 no, but it allows us to verify a theory 2022-02-27 14:35:20 i already tried it and the valgrind errors disappear if you do that 2022-02-27 14:35:35 yes, but does the *segfault* disappear 2022-02-27 14:35:52 valgrind is useless here 2022-02-27 14:35:54 I assume it does, yes 2022-02-27 14:36:05 can ikke verify this :) 2022-02-27 14:36:23 stalloc still uses malloc internally so I don't understand why valgrind would be useless 2022-02-27 14:36:24 Ariadne: so apply that patch and try again? 2022-02-27 14:36:34 ikke: yes 2022-02-27 14:36:59 nmeum: it only uses malloc to allocate new blocks of memory 2022-02-27 14:37:14 it reuses already allocated blocks 2022-02-27 14:37:19 that's the entire point of it 2022-02-27 14:38:01 in this particular case it accesses uninitilized data in an allocated block 2022-02-27 14:38:20 (previously initialized data, actually) 2022-02-27 14:38:46 i mean, it probably does both, really 2022-02-27 14:38:54 but i think our problem is *previously* initialized data 2022-02-27 14:43:25 var/cache/misc/busybox-1.35.0-r3.trigger: line 7: syntax error: unexpected ")" 2022-02-27 14:43:38 When installing the just built version 2022-02-27 14:44:11 Things seem broken 2022-02-27 14:44:46 just `sh` seems to hang 2022-02-27 14:46:43 The script no longer has any output, nor `ap list` 2022-02-27 14:48:13 So.. doesn't seem to work as intended 2022-02-27 14:49:08 fascinating 2022-02-27 14:49:25 wow 2022-02-27 14:49:30 returning zero'd memory makes it even worse 2022-02-27 14:49:36 how very UNIX 2022-02-27 14:49:55 try memset with `1` instead :p 2022-02-27 14:50:12 please don't make me write a shell 2022-02-27 14:50:38 the more i find out about busybox ash at this depth 2022-02-27 14:50:43 the more i think it needs to go away 2022-02-27 14:50:52 the ash code is god awful 2022-02-27 14:50:57 that's why you don't study the software you use often 2022-02-27 14:51:02 the parser is such a mess 2022-02-27 14:51:06 because if you do, you find out that it needs to be replaced 2022-02-27 14:51:09 I don't think anyone apart from Denys understands this code 2022-02-27 14:51:12 skarnet: guess what i'm supposed to be doing around here 2022-02-27 14:51:17 nmeum: busybox in general is quite messy :/ 2022-02-27 14:51:22 it is true for 90% of the software in a distro 2022-02-27 14:52:00 every time I look at a piece of code, there's a 90% chance I go AAAAGH THIS NEEDS REPLACING YESTERDAY 2022-02-27 14:52:01 ${_bootstrapver/-*} should be equivalent to ${_bootstrapver%-*} for the dotnet cases, right? 2022-02-27 14:52:05 so yeah 2022-02-27 14:52:13 %% 2022-02-27 14:52:17 nmeum: yes i think so 2022-02-27 14:52:18 nmeum: I can try to see if it makes a difference 2022-02-27 14:52:26 my tests confirm that it is equivalent 2022-02-27 14:52:34 also, 1. it's busybox, and 2. it's *shell parsing*, which is intrinsically a nightmare, so yes it's going to be messy 2022-02-27 14:52:48 how about we just try getting rid of ${_bootstrapver/-*}? 2022-02-27 14:53:04 https://img.ayaya.dev/YuhcM2DC4qHd.png 2022-02-27 14:53:04 replace it with ${_bootstrapver%-*} or ${_bootstrapver%%-*} and see if that helps 2022-02-27 14:53:07 ye 2022-02-27 14:53:12 agree 2022-02-27 14:53:17 ok, let's do that 2022-02-27 14:53:24 (it's more POSIX compliant anyhow) 2022-02-27 14:53:31 lets 2022-02-27 14:53:42 bite the bullet and open a TSC item to investigate a new shell 2022-02-27 14:53:47 that too 2022-02-27 14:53:47 also 2022-02-27 14:53:57 powershell? 2022-02-27 14:54:40 jvoisin: I know you're trolling but if you look at powershell's code I'm sure you'll find it's just as bad, if not worse :P 2022-02-27 14:54:56 (and it's c++ isn't it?) 2022-02-27 14:54:59 i would like it to be faster than 1 operation per 10 seconds 2022-02-27 14:55:02 thanks 2022-02-27 14:55:12 i mean, i don't know about you all, but changing stalloc to return zero'd memory breaking *everything* is not confidence inspiring to me 2022-02-27 14:55:39 skarnet: more like a harmless joke than a troll 2022-02-27 14:55:39 skarnet: powershell is .NET 2022-02-27 14:55:42 Ariadne: valgrind it for shiggles 2022-02-27 14:55:54 I'd be happy to throw some money at emersion to finish mrsh 2022-02-27 14:55:59 it's .NET? yeah, same thing :P 2022-02-27 14:57:37 (also, in my definition, trolling is not far from harmlessly joking, because if it isn't harmless then it's not trolling, it's abuse) 2022-02-27 14:58:54 (ack) 2022-02-27 14:59:15 why don't you use msan and poison manually? does it not work on musl/alpine? 2022-02-27 14:59:46 ikke: does a9abe39d3678f94a6964fd5d8f9d072684e079b2 help? 2022-02-27 15:00:00 nmeum: yes, thank you 2022-02-27 15:00:20 does that mean it helps? :D 2022-02-27 15:00:39 nmeum: :P 2022-02-27 15:01:44 i am confused 2022-02-27 15:01:54 you missed a few 2022-02-27 15:02:13 yes,https://tpaste.us/aZJb 2022-02-27 15:02:22 the runtime/sdk ones had them too 2022-02-27 15:02:25 i had just finished them all myself :p 2022-02-27 15:02:45 hehe ooops, feel free to push those too 2022-02-27 15:02:49 done 2022-02-27 15:02:49 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/39 2022-02-27 15:02:58 ikke: great! 2022-02-27 15:03:43 psykose: ty 2022-02-27 15:04:07 seriously i think its time for busybox ash to be sent to a farm upstate 2022-02-27 15:04:17 send me to a farm upstate 2022-02-27 15:04:23 that parser code is the stuff of nightmares 2022-02-27 15:05:10 there are also the //[.0] ones, but i think those are fine if ap list passes 2022-02-27 15:05:15 I wonder if the mksh turns out to be equally worse if we start examining it more closely, I am sure it carries a lot of historic BSD baggage as well 2022-02-27 15:05:19 i guess we can put the builders back up 2022-02-27 15:05:21 this is why i like mksh, it just works and mira will fix pedantic issues :) 2022-02-27 15:05:27 that parser is one of the worst I have ever seen, and I have seen a lot of awful parsers 2022-02-27 15:05:46 psykose: working on it 2022-02-27 15:05:50 sure :) 2022-02-27 15:05:57 also i saw you cancelled the gitlab upgrade 2022-02-27 15:06:05 so regarding that busybox ash issue I will just report this to upstream and let Denys figure out the details 2022-02-27 15:06:13 :D 2022-02-27 15:06:37 and in the meantime we just make sure we don't use this bash substitution pattern stuff anywhere 2022-02-27 15:07:15 nmeum: I think %{foo/a/b} does work 2022-02-27 15:07:18 just not with a single / 2022-02-27 15:07:29 yeah, I think so too 2022-02-27 15:07:38 there are thousands of those 2022-02-27 15:07:41 yup 2022-02-27 15:07:47 /-/_ or whatever 2022-02-27 15:07:47 many python packages 2022-02-27 15:07:49 mhm 2022-02-27 15:07:51 that as well 2022-02-27 15:08:07 though the %{foo/a/b} is buggy as well see #13469 2022-02-27 15:09:24 could you merge the mr with the fix for that, along with the extra ariadne patch 2022-02-27 15:09:28 or do you want to wait longer 2022-02-27 15:10:00 I think I should 2022-02-27 15:10:00 started the x86_64 builder 2022-02-27 15:10:10 I just don't like pushing stuff for code I don't fully understand (i.e. busybox ash) 2022-02-27 15:10:26 yeah, me too 2022-02-27 15:10:30 ppc64le now as well 2022-02-27 15:11:54 Ariadne: http://lists.busybox.net/pipermail/busybox/2022-February/089493.html <- do you want to address this too? I don't think it matters much, or does it? 2022-02-27 15:12:22 nmeum: go ahead and take care of it if you're doing it 2022-02-27 15:12:42 unless you explicitly want me to do it 2022-02-27 15:16:28 hey look 2022-02-27 15:16:29 it fixed it 2022-02-27 15:16:30 :) 2022-02-27 15:17:00 Ariadne: would be nice to also send a v3 to the ml, so maybe easier if you do it 2022-02-27 15:17:07 okay 2022-02-27 15:17:17 I also need a brief break from looking at busybox code 2022-02-27 15:19:07 done :) 2022-02-27 15:21:25 ty 2022-02-27 15:21:34 nmeum: is it that bad? 2022-02-27 15:22:10 the parser for posix shell in ash is pretty awful, yes 2022-02-27 15:24:35 i doubt even denys knows how it works 2022-02-27 15:45:25 Ariadne: is the v3 patch for the memcpy thing actually correct? doesn't memcpy return a pointer to dest? shouldn't it be loc = startp then instead of loc = startp + pos? 2022-02-27 15:45:46 mempcpy is dest + size 2022-02-27 15:46:21 > The memcpy() function returns a pointer to dest. 2022-02-27 15:46:30 'But instead of returning the value of dest it returns a pointer to the byte following the last written byte.' 2022-02-27 15:46:36 its mem*p*cpy 2022-02-27 15:46:48 https://man7.org/linux/man-pages/man3/mempcpy.3.html 2022-02-27 15:46:58 ahahhahh 2022-02-27 15:47:00 my bad! 2022-02-27 15:47:02 i missed that part 2022-02-27 15:47:17 i mean 2022-02-27 15:47:21 all of this is so crap 2022-02-27 15:47:27 that i cannot blame you 2022-02-27 15:47:39 (: 2022-02-27 15:47:46 please, let us find a shell we can actually debug 2022-02-27 15:47:49 :D 2022-02-27 15:48:32 🙏 2022-02-27 16:04:30 I merged !31502, let's hope it doesn't introduce new bugs 2022-02-27 19:47:29 has something changed with regard to ppc64le recently? !31508 just failed on ppc64le with a "unrecognized opcode: `darn'" error whereas older versions of this package (also with DARN support) built fine in the past 2022-02-27 19:48:56 minimal: no, nothing changed recently 2022-02-27 19:49:34 CI host has not changed in ages 2022-02-27 19:50:42 linux-headers was updated from 5.10.41 to 5.16.7 a few weeks ago, maybe something changed in that 2022-02-27 19:51:39 maybe, but instruction wise it should be the same 2022-02-27 19:52:04 you can try the same ci job vs 3.15-stable and you would have old headers if you want to make sure 2022-02-27 19:52:55 found this which gives the impression it might be related to different versions of POWER: https://github.com/randombit/botan/issues/2226 2022-02-27 19:53:57 if you version as in power8/9, then that would still be the same 2022-02-27 19:54:03 you mean* 2022-02-27 19:54:16 unless the changes changed some build semantics 2022-02-27 19:54:24 and check stuff differently 2022-02-27 19:54:25 this rng-tools update is basically the same as the old version (i.e. the additional patches now incorporated into the upstream release), which built fine on Edge months ago 2022-02-27 19:57:18 yeah, most of this was already there 2022-02-27 19:57:19 hm 2022-02-27 19:57:25 try run it vs 3.15-stable 2022-02-27 19:58:59 ah right, needs some manual rebasing for that first 2022-02-27 19:59:04 looks like DARN is a POWER9 instruction 2022-02-27 19:59:35 mhm 2022-02-27 20:07:09 don't see anything relevant in the GCC11 changelog (the 10->11 happened in late Nov) 2022-02-27 20:10:23 I guess I could patch out DARN support to get it to build, but that doesn't explain the change in build behaviour since October 2022-02-27 20:11:23 CI is power9 2022-02-27 20:11:26 builders are power8 2022-02-27 20:11:36 you could just run it against 3.15 and see if it's gcc or the headers 2022-02-27 20:12:41 ikke: ah, if the builders are power8 then how did it ever build in the past? 2022-02-27 20:13:03 minimal: The builders did run for a while one VMs, I think they were power9 2022-02-27 20:13:11 But that was about 6 months to a year 2022-02-27 20:13:49 ok, rng-tools' configure.ac has: AM_CONDITIONAL([DARN], [test $host_cpu = powerpc64le]) 2022-02-27 20:14:08 so its not restricting DARN to POWER9 2022-02-27 20:14:30 i would expect that to still work on ci though, maybe it's not actually p9 2022-02-27 20:16:49 the generic autoconf host/host_cpu list doesn't seem to have versions for power 2022-02-27 20:17:11 i.e. https://git.savannah.gnu.org/cgit/autoconf.git/tree/build-aux/config.sub#n1078 2022-02-27 20:17:15 does "cat /proc/cpuinfo" show "darn" as a cpu instruction on those machines perhaps? 2022-02-27 20:18:01 minimal: on neither of the hosts 2022-02-27 20:18:24 But I don't see any capabilities in there 2022-02-27 20:18:42 does it 'hard' require darn for the ppc code, or can you just patch that one am_conditional line out 2022-02-27 20:19:11 ikke: not under flags: ?? 2022-02-27 20:19:34 that's where all the instructions should be 2022-02-27 20:19:41 psykose: will have to check the code but darn use should be optional for rngd (like RDRAND on x86) 2022-02-27 20:19:42 psykose: there are no flags 2022-02-27 20:19:49 that is weird 2022-02-27 20:20:45 if it's any virt then it could be that 2022-02-27 20:21:01 psykose: should be bare-metal 2022-02-27 20:21:16 mm 2022-02-27 20:22:04 https://tpaste.us/NMVq 2022-02-27 20:23:25 does lscpu also hide them 2022-02-27 20:24:23 psykose: was trying that 2022-02-27 20:24:31 but had to shave some yaks 2022-02-27 20:24:43 hairy yaks 2022-02-27 20:27:46 no flags from lscpu either 2022-02-27 20:28:21 Just a model name 2022-02-27 20:28:47 bizarre 2022-02-27 20:29:00 welcome to ppc :) 2022-02-27 20:29:15 :) 2022-02-27 20:30:58 The __builtin_darn and __builtin_darn_raw functions require a 64-bit environment supporting ISA 3.0 or later 2022-02-27 20:31:33 Hmm, "Deliver A Random Number" 2022-02-27 20:32:22 yeah, it's like rdrand x86 or rndr arm 2022-02-27 20:33:49 so power9 is ISA 3.0 2022-02-27 20:33:58 power8 is ISA 2.07 2022-02-27 20:34:19 and power10 will be isa 3.93, of course 2022-02-27 20:34:21 :^) 2022-02-27 20:39:18 ikke: yupe, that's why rngd wants to use DARN ;-) 2022-02-27 20:40:05 minimal: But I expect it to work on CI 2022-02-27 20:40:12 which is power9 2022-02-27 20:41:04 rngd's configure only checks for powerpc64le rather than a specific POWER version as its only building the code on that machine, not necessarily going to run it there 2022-02-27 20:41:42 so should be able to build on a POWER8 machine and later install and run the package on a POWER9 machine 2022-02-27 20:42:28 ah, so just a runtime detection thing 2022-02-27 20:42:35 no idea why it fails to assemble then 2022-02-27 20:43:32 psykose: not 100% sure, it should be a runtime thing (which the RDRAND for x86/x86_64 and the RNDR for aarch64 is) 2022-02-27 20:43:59 it's obviously failing at buildtime now :) 2022-02-27 20:45:03 yupe, seems like GAS doesn't recognise the darn opcode for some reason 2022-02-27 20:45:17 or is that darn darn opcode ;-) 2022-02-27 20:47:41 hehe :) 2022-02-28 06:55:20 Hi, I'm getting a xorg segfault when running "picom --backend glx" on my Thinkpad X1 Carbon Gen 1. I've used gdb to debug and it seems to be caused by visit->new being 0x0 when being used in present_set_tree_pixmap_visit (present/present.c:122). Full backtrace: https://tpaste.us/5nOB. Any ideas how to fix/further debug this? 2022-02-28 06:55:49 Could it be related to https://bugs.archlinux.org/task/66818? 2022-02-28 08:08:14 hi all. I'm working on !13306 and since bareos 21 has been released, probably this is a good time to go ahead and split it in subpackages. I need an advice though. What's the best way to find which files belongs to which package? e.g. i want to split bareos-sd. Beside looking at the names, which is kinda straightforward, how can I be sure that I'm not missing something else? afaict i would go ahead and test the linked libraries with ldd 2022-02-28 08:08:35 #13306 2022-02-28 09:35:48 hmm something is broken in mkinitfs 2022-02-28 09:38:29 but its not stable to reproduce 2022-02-28 09:39:05 https://tpaste.us/vgwB 2022-02-28 09:44:23 looks like other qemu users are experiencing the same behavior 2022-02-28 16:32:26 shoutout to alpine for being super robust 2022-02-28 16:32:39 spent the last three weeks upgrading 40+ hosts and it all went off without a hitch, including one which started at 3.11 2022-02-28 17:07:37 !31020 looks important, maybe we should merge that? or is that a package for ncopa to merge? 2022-02-28 17:13:55 looks fine to me 2022-02-28 17:14:03 although i don't think the rel actually needs to be bumped 2022-02-28 17:15:06 or at least i think that was the other thing 2022-02-28 17:21:10 not sure, the comment seems to state it must be bumped as well, not sure about the specifics for this package. 2022-02-28 17:22:57 oh yeah 2022-02-28 17:22:59 it's right 2022-02-28 17:23:03 cause the pkgver is separate 2022-02-28 17:23:07 yeah, feel free to merge 2022-02-28 17:52:00 psykose: done, thanks 2022-02-28 18:04:14 Ariadne: any ideas about this PPC build error: "Error: unrecognized opcode: `darn'". Looks like a "gas" related problem. https://gitlab.alpinelinux.org/dbradley/aports/-/jobs/647039 2022-02-28 18:08:27 binutils probably does not support it 2022-02-28 18:10:27 Ariadne: it built fine in the past (last in Oct) but binutils version was updated in Nov, so wondering if that changes gas behaviour 2022-02-28 18:10:40 we did upgrade to latest binutils 2022-02-28 18:10:51 but `darn` is not available on POWER8, which is what we build for 2022-02-28 18:10:58 so i think erroring is right 2022-02-28 18:11:40 Ariadne: right, but this is a compile-time generating a binary, it won't actually use DARN until the binary is run (and the code checks if the runtime machine supports DARN) 2022-02-28 18:12:10 i mean, maybe its a bug in binutils 2022-02-28 18:12:32 yeah I did a diff between current and last version of binutils and there's a lot of POWER10-related changes 2022-02-28 18:17:01 https://gitlab.alpinelinux.org/psykose/aports/-/jobs/647633 2022-02-28 18:17:10 it builds fine against 3.15-stable with the previous binutils 2022-02-28 18:17:17 (i checked it for you since you never did) 2022-02-28 18:17:23 Ariadne: so are you saying we build *for* POWER8 (via some flag) or just build on POWER8? 2022-02-28 18:17:36 we build *for* POWER8, `-march=power8` 2022-02-28 18:17:40 the runners are the same on both of these 2022-02-28 18:18:08 i mean we can downgrade the binutils 2022-02-28 18:18:12 or you can bisect it 2022-02-28 18:18:44 i don't have a ppc64le machine up and running atm 2022-02-28 18:20:46 or rather i linked the wrong pipeline, but it passes ppc two 2022-02-28 18:20:49 too8 2022-02-28 18:21:31 and changing it back to master fails 2022-02-28 18:21:37 so yes, it's probably something to bisect 2022-02-28 19:28:07 FYI, upgrading gitlab in a couple of minutes 2022-02-28 19:35:25 Upgrade finished 2022-02-28 19:40:04 it loads 2022-02-28 19:40:22 and the gitaly log is quiet :) 2022-02-28 19:40:28 :) 2022-02-28 19:41:16 I noticed some 'network issues' lately when applying quick actions, let's see if that's fixed now 2022-02-28 19:42:15 what kind specifically 2022-02-28 19:42:45 A banner from gitlab 2022-02-28 19:42:49 Error 2022-02-28 19:43:04 i mean what counts as a quick action 2022-02-28 19:43:10 /label ~foo 2022-02-28 19:43:10 i got a bunch of those 2022-02-28 19:43:13 ah 2022-02-28 19:43:22 yeah, i get lots of those errors when even doing it by hand 2022-02-28 19:43:29 i.e. stop ci 2022-02-28 19:43:38 ok 2022-02-28 19:43:47 or rather did 2022-02-28 19:43:52 lets see how it goes now over the days 2022-02-28 19:43:55 Yup 2022-02-28 19:44:02 also those errors didn't mean anything, as the action was applied still 2022-02-28 19:44:10 Well, some 2022-02-28 19:44:12 at least for me 2022-02-28 19:44:13 yeah 2022-02-28 19:44:15 like 80% 2022-02-28 19:44:59 libvpx went through 2022-02-28 19:45:02 yep 2022-02-28 19:45:13 afaik everything had gone through except qt6-web so it was safe 2022-02-28 19:46:34 CI failed on qt5-qtwebengine 2022-02-28 19:46:41 or timed out, rather 2022-02-28 19:48:22 qt5 is community and came first 2022-02-28 19:48:27 the last thing in the logs was qt6 2022-02-28 19:49:06 but there were some things after it too, i suppose