2019-07-01 00:41:09 so there's a pattern I've been seeing in my work on alpine & sr.ht 2019-07-01 00:41:30 whenever I need a new package for sr.ht, I need it _now_, not "once the reviewers get around to it and also once it can graduate from testing into community" 2019-07-01 00:41:35 the latter being a process which can take months 2019-07-01 00:41:53 so I often pull packages into my third-party repo, which makes it more divergent from upstream alpine linux than I would like it to be 2019-07-01 00:41:57 Yes? 2019-07-01 00:42:01 open to anyone's thoughts on this 2019-07-01 00:42:39 Reviews have become pretty quick in recent time and you can move from testing to community once you're sure that the package isn't broken 2019-07-01 00:42:53 yeah reviews are getting faster 2019-07-01 00:43:04 moving to community isn't something I've done a lot of, I don't know the process 2019-07-01 00:43:10 is there some criteria that needs to be met? 2019-07-01 00:43:32 ddevault: can be moved as soon as it is verified to work 2019-07-01 00:43:38 Yup 2019-07-01 00:43:43 okay, cool 2019-07-01 00:43:55 i moved the whole SPIR-V / glslang / shaderc stack to community for mpv with vulkan in 2 to 3 days 2019-07-01 00:43:58 the other problem is that I live in this world where I want my packages faster than alpine's release cycle and yet I don't want to run production servers on edge 2019-07-01 00:44:01 but this is my problem, not yours :) 2019-07-01 00:45:54 other things that have been on my mind recently: python 2 deprecation and aports python normalization, and riscv64 2019-07-01 00:46:10 the latter was blocked on the team restructuring thing, which seems to be dead in the water 2019-07-01 00:46:27 err, former 2019-07-01 00:46:30 python was blocked 2019-07-01 00:46:47 the latter is not blocked but just heads up that I'll be picking that up again soon - riscv64 just landed in musl 2019-07-01 00:49:41 Neat. I don't really know riscv64 too well, how fast can I expect it to be? 2019-07-01 00:50:26 my board is pretty fast 2019-07-01 00:50:48 I build all of my alpine packages natively, not cross-compiled 2019-07-01 00:51:04 Is it about the speed of a RPI? 2019-07-01 00:51:08 much faster 2019-07-01 00:51:30 Oh, nice 2019-07-01 00:52:04 lemme build a reasonably big package and measure it 2019-07-01 00:52:23 cd aports/main/perl && time abuild -rf 2019-07-01 00:53:45 just for fun let's compare it to 24 cores of bleeding edge AMD x86_64 tech 2019-07-01 01:03:09 24x x86_64: 3m 41.50s 2019-07-01 01:23:10 4x riscv64: 23m 58.93s 2019-07-01 01:23:24 don't have a rpi with alpine prepared for testing with 2019-07-01 01:23:27 Cogitri: ^ 2019-07-01 01:27:22 Oh, cool, thanks for the test 2019-07-01 02:09:31 mps: How are you using Adelie's Rust tarballs? At least the aarch64 ones explode immediately for me :/ 2019-07-01 06:49:08 Morning 2019-07-01 06:49:38 Good afternoon 2019-07-01 06:49:39 breakfast question, how long are community packages maintained ? 6 months ? 2019-07-01 06:49:44 It's 13:49 :) 2019-07-01 06:49:45 Morning, tmhoang 2019-07-01 06:49:54 enjoy the sunday night :) 2019-07-01 06:50:09 It's monday here. :P 2019-07-01 06:50:34 tmhoang: morning, let me check my backlog 2019-07-01 06:50:34 tmhoang: Yup, 6 months 2019-07-01 06:50:43 thanks 2019-07-01 06:51:47 ncopa said "only latest stable" 2019-07-01 06:54:09 (which is roughly 6 months) 2019-07-01 07:05:07 morning 2019-07-01 07:06:31 morning 2019-07-01 07:19:43 Cogitri: will try mentioned PR in few minutes 2019-07-01 07:20:32 Thank you 2019-07-01 07:21:03 Cogitri: about adelie rust, I will post scripts which downloads it, prepare, make local tarball, install it, and script to uninstall it 2019-07-01 07:22:11 I see your msg's with to early time for me, we are in distant TZ's probably 2019-07-01 07:40:23 Ah, .no, my sleep rhythm was just a bit messed up yesterday :) 2019-07-01 07:40:23 It's 9:40 here right now 2019-07-01 07:40:56 aha, we are then in same TZ 2019-07-01 07:42:31 same here 2019-07-01 08:51:24 Cogitri: finished build with error. are there paste service which accepts few MB size files 2019-07-01 08:52:07 or, to post you relevant part to tpaste? 2019-07-01 08:54:25 I usually just Github gists for that 2019-07-01 08:56:23 can I upload it there without account, anonymously 2019-07-01 08:59:35 Cogitri: here it is http://arvanta.net/mps/webkit2gtk-build.log.gz 2019-07-01 09:31:24 Hi all. First time I'm using IRC so I hope I'm doing it correctly =D 2019-07-01 09:32:33 looks good so far. ;) 2019-07-01 09:33:20 I encounter a strange issue, where after a build some packages (e.g. gdbm) it ended with extra dependencies in the APKINDEX (specifically, libreadline.so). The issue is that when gdbm is installed, I can't update readline. 2019-07-01 09:38:25 I believe gdbm can be built with readline, and abuild traces the dependencies (i.e. libreadline.so) at the end of the build process 2019-07-01 09:39:15 roigr: try adding `--without-readline' to the `./configure' arguments 2019-07-01 09:39:57 i can confirm that gdbm uses readline for line editing in gdbmtool etc 2019-07-01 09:40:22 How can it not exists in the official APKINDEX, assuming we are using the same APKBUILD file? 2019-07-01 09:42:06 also, gdbm is just an example. I also checked fsdisk and there are several more 2019-07-01 09:46:03 readline isn't added as a dependency in our APKBUILD 2019-07-01 09:46:27 it might be that you have readline preinstalled on your system and that gdbm autodetects it 2019-07-01 09:47:00 in my opinion our build should explicitly use --without-readline when we build it without readline support 2019-07-01 09:47:21 because readline is not in the list of dependencies 2019-07-01 09:49:13 So, when readline is installed, abuild will recognize it and add it as dependency, and if not it will build without it? 2019-07-01 09:54:41 2 2019-07-01 10:02:21 also, IMO you should never build packages in a system that you use; you should always use an isolated place, because you usually have some optional deps installed in your everyday system, and that leads to lazy packaging 2019-07-01 10:03:00 not that my opinion would explain readline updating problems 2019-07-01 10:06:07 not abuild 2019-07-01 10:06:21 when readline is installed, gdbm will most likely be built with support for readline 2019-07-01 10:06:27 and abuild traces that dependency 2019-07-01 10:06:58 the dependency tracing is done *after* the build, which is defined by the build() function in the APKBUILD file 2019-07-01 10:08:11 I think you are right and I should change my builder(currently its a container with pre-installed packages). I noticed that there are more dependencies like libgmp, libmpfr & libreadline in gawk.. 2019-07-01 10:10:12 I must say it doesn't sounds like the way thing should work.. The expectation is to get the same result in any build, depend-less on the system(as long as you are using the same "tools") 2019-07-01 10:15:23 Sadly that isn't really a thing, automagic deps are in way too many packages 2019-07-01 10:16:56 '=( 2019-07-01 10:19:15 which is exactly why you should have a build container that only has the absolute minimum of packages to build something 2019-07-01 10:19:54 of course, that won't guarantee that something the build depends on won't draw unwanted extra deps with it to the container during build 2019-07-01 10:20:13 ACTION can recommend docker-abuild 2019-07-01 10:21:03 I've, of course, built my own... 2019-07-01 10:23:22 I actually already had one.. 2019-07-01 10:30:26 APKBUILD masters, I have a package that has a doc + man directory at : pkg/libica/usr/local/share/doc/ but I have fololowing error for -doc package : >>> ERROR: libica-doc*: Missing /home/tmhoang/src/aports/main/libica/pkg/libica-doc 2019-07-01 10:31:35 The package doesn't have any docs apparently 2019-07-01 10:32:06 The error message is pretty bad, it means "no docs detected, nothing to put into the -docs subpackage" 2019-07-01 10:32:25 those docs are in /usr/local, which is probably not what abuild expects 2019-07-01 10:32:25 right, I only see a couple of man pages 2019-07-01 10:32:31 `/usr/local` seems wrong 2019-07-01 10:32:46 Most likely a `--prefix=/usr` missing 2019-07-01 10:32:56 hah 2019-07-01 10:33:19 tmhoang: man belongs to -doc too 2019-07-01 10:37:25 Cogitri: --prefix=/usr did the trick thanks :D 2019-07-01 10:37:51 👍 2019-07-01 10:39:57 Can anyone point me, how can I generate a separate -doc package ? 2019-07-01 10:40:45 mps: would you mind testing pr9132 on armv7 when you have some time? 2019-07-01 10:41:00 I am unable to reproduce the error Drone CI had 2019-07-01 10:41:22 but check in elixir was disabled on aarch64, I re-enabled it for that PR 2019-07-01 10:42:38 danieli: yes, only give 15-20 minutes to finish some of $dayjobs 2019-07-01 10:42:52 no worries, do it when you have time, it can wait a bit 2019-07-01 10:43:05 I'm also super busy with $dayjob at the moment 2019-07-01 10:43:27 just wanted it out of my todo and I'm curious if you'd be able to reproduce it on armv7, or of it actually is a CI malfunction once again 2019-07-01 10:44:09 ok, will do 2019-07-01 10:51:21 errn0: Take other APKBUILDs for the APKBUILD reference wiki page as reference 2019-07-01 10:51:49 TL;DR add "$pkgname-doc" to "subpackages" 2019-07-01 10:56:59 cogitri: I see. Thank you :) 2019-07-01 11:24:24 danieli: should I first build erlang and then elixir or order is not important 2019-07-01 11:24:33 erlang first, elixir depends on it 2019-07-01 11:24:45 hm 2019-07-01 11:24:51 I thought so, ok :) 2019-07-01 11:24:52 we already have recent erlang in our repos, you don't have to build it 2019-07-01 11:25:00 it's recent enough that won't be what causes the issue 2019-07-01 11:25:04 that it* 2019-07-01 11:25:13 aha, then just elixir 2019-07-01 11:25:16 yes 2019-07-01 11:25:52 you have two commits in this PR so I thought that have to build both 2019-07-01 11:26:53 yes, i forgot that the erlang commit is a small change for a second :) 2019-07-01 11:26:59 the elixir one is a major upgrade 2019-07-01 11:28:07 I started build of elixir, if it fails I will then build erlang and again will try elixir 2019-07-01 11:38:34 danieli: >>> elixir: Build complete at Mon, 01 Jul 2019 11:32:33 +0000 elapsed time 0h 6m 9s 2019-07-01 11:38:57 thank you - I will do some testing on aarch64 2019-07-01 11:39:08 22.0.2 is in the repos, there might be a bug in 22.0.3 or 22.0.4 2019-07-01 11:40:37 happy to be of help 2019-07-01 11:40:53 Hi. Back to my question, any alpine builder contain alpine-sdk, which is basically what I have in my container, and that include readline, so back to square 1, I still have extra dependencies that I can't explain... 2019-07-01 11:41:21 roigr: readline or readline-dev 2019-07-01 11:41:29 readline is not problem 2019-07-01 11:41:40 readline (libreadline.so) 2019-07-01 11:41:55 I have it everywhere 2019-07-01 11:42:42 oh, not everywhere but on most building boxes 2019-07-01 11:44:37 the problem is that I can't update readline with unknown reason, so I can't build 3.10 packages with 3.9 alpine-sdk (don't ask why, but that what I need to do.... X) ). I'm building it in the currect order so I always have the updated dependencies, but if I can't install the new readline, I'm stuck. 2019-07-01 11:45:49 bash-4.4# apk add readline -l 2019-07-01 11:45:59 bash-4.4# apk add readline readline-dev libhistory -l 2019-07-01 11:45:59 gdbm-1.13-r1[so:libreadline.so.7] python2-2.7.16-r1[so:libreadline.so.7] ruby-libs-2.5.5-r0[so:libreadline.so.7] gawk-4.2.1-r0[so:libreadline.so.7] 2019-07-01 11:46:35 you have a bash, it pulls readline 2019-07-01 11:47:26 use busybox ash on builder, minimum deps 2019-07-01 11:48:11 I will try. 2019-07-01 11:49:13 I looked at the build script, and it use sh.. #!/bin/sh 2019-07-01 11:49:41 CFLAGS += ... does not work with ash right ? We might have to do something like : CFLAGS = "$CFLAGS ..." ? 2019-07-01 11:52:15 roigr: /bin/sh is busybox ash 2019-07-01 11:52:37 tmhoang: usually 2019-07-01 11:52:44 so that what we are using... 2019-07-01 11:53:53 ls -l /bin/sh => lrwxrwxrwx 1 root root 12 Jun 30 11:34 /bin/sh -> /bin/busybox 2019-07-01 11:55:27 bash-4.4# ls -l /bin/sh 2019-07-01 11:57:30 mps: any other way ? 2019-07-01 11:57:44 is there a place to see the script/docker Alpine use to build the official repository? 2019-07-01 11:58:11 we don't use docker for it, our build system listens for commits and runs abuild based on that 2019-07-01 11:58:22 i don't remember the details though 2019-07-01 11:58:56 =L 2019-07-01 11:59:20 roigr : I don't know if we even use alpine-sdk ? 2019-07-01 11:59:39 alpine-sdk is assumed to be installed on all the builders iirc 2019-07-01 12:00:06 maybe ncopa could help ^ 2019-07-01 12:01:02 Is there a way to force update a package, but reinstall everything again? By adding --force to "apk add" it only purge all the "above" packages.. 2019-07-01 12:17:23 tmhoang: I don't know, to be honest I'm not expert in shell programming 2019-07-01 12:21:05 tmhoang: += is a bash feature, use CFLAGS="$CFLAGS -your-flags" 2019-07-01 12:40:41 ncopa: few days ago we upgraded postgresql 11.3 with sec fix in edge and 3.10, but we need to upgrade it in 3.9 also 2019-07-01 12:41:16 do we need separate patch for 3.9 or one of previous could be applied 2019-07-01 12:43:37 and I'm not sure if we need to upgrade 10.8 in Alpine v3.8 2019-07-01 13:24:28 anyone know what is the difference between libunwind and llvm-libunwind ? 2019-07-01 13:25:34 tmhoang: llvm-libunwind is LLVM version of libunwind lib 2019-07-01 13:28:32 mps: so complete re-write or a wrapper ? 2019-07-01 13:30:21 I think it is rewrite/change to be used with llvm 2019-07-01 13:30:43 it is not wrapper, as I know 2019-07-01 13:31:07 I had to compile llvm-libunwind for llvm 2019-07-01 13:31:21 but never used it personally 2019-07-01 13:54:13 Hello, the mate-desktop-environment package seems to be broken in the edge repository 2019-07-01 13:57:26 Define broken 2019-07-01 13:57:27 Oh well 2019-07-01 14:16:10 mps: i can backport it 2019-07-01 14:23:58 ok, and maybe to 3.7 even, it is still supported afaik 2019-07-01 14:42:36 mps: the way to do is is normally to create an issue on bugs.a.o with target for each affecte branch 2019-07-01 14:46:31 cogitri: he left but he did report the bug at https://bugs.alpinelinux.org 😃 He came from postmarketOS, one person told him to report the bug here but I recommended to do it on https://bugs.alpinlinux.org instead. I guess that is why he left 2019-07-01 14:48:07 Yup 2019-07-01 14:57:32 ncopa: understand, but was not sure how to create patches for previous stable releases. do we have to create separate patches for every release 2019-07-01 14:59:16 Checkout the 3.x-stable branch and see if your patch applies 2019-07-01 14:59:30 Then push/pr the thing I guess, no clue how to do it in pw workflow 2019-07-01 14:59:53 hm 2019-07-01 14:59:59 we have libmarco-private.so.2 2019-07-01 15:00:18 guess mate-control-center has to be rebuilt 2019-07-01 15:01:41 Cogitri: for pw you do 'git send-email ....' 2019-07-01 15:13:20 I did a test using official alpine, and the "issue" is also there. I can't update readline while bash is installed. On the other hand, I saw that my container include many packagas that alpine-sdk need just for compilation. I rebuild it only with alpine-sdk and now it seems to work.. 2019-07-01 15:14:14 Another thing I encounter during my builds, is that bison and flex are depending on each other, so it kind of impossible to build them from scratch...(unless I'm missing anything..) 2019-07-01 15:25:17 roigr: iirc its only the test suite that causes circular buildtime deps 2019-07-01 15:29:14 Cogitri: FYI, im working on webkit2gtk 32 bit support. https://bugs.webkit.org/show_bug.cgi?id=199272 2019-07-01 15:29:26 seems like we need to disable the unified build stuff 2019-07-01 15:30:17 Yup, but as mentioned in the bug that's badly broken in 2.24.x 2019-07-01 15:30:35 Could you try my PR which builds webkit2gtk with CLang first? 2019-07-01 15:30:58 pr9218 2019-07-01 15:35:44 it has build failures 2019-07-01 15:36:00 In file included from /home/buildozer/aports/community/webkit2gtk/src/webkitgtk-2.24.2/Source/WebCore/page/EventHandler.cpp:64In file included from /home/buildozer/aports/community/webkit2gtk/src/webkitgtk-2.24.2/build/DerivedSources/WebCore/unified-sources/UnifiedSource-3c72abbe-25.cpp:8: 2019-07-01 15:36:00 15807 /home/buildozer/aports/community/webkit2gtk/src/webkitgtk-2.24.2/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error: an attribute list cannot appear here 2019-07-01 15:36:51 ncopa If you meant that the issue is while building, that what I meant. I needed my container to include also flex and bison (in addition to alpine-sdk) since without it it will failed when building bison/flex (and yes, I need to build them.. :) ) 2019-07-01 15:38:43 Argh, had hoped the first patch fixed that 2019-07-01 16:03:41 Could someone review/merge pr8764 and pr8736? 2019-07-01 16:10:13 PureTryOut: Why the switch to CMake? I think upstream said at one point that they only support CMake for their windows builds 2019-07-01 16:11:48 More modern, easier to read script (I mean CMakeLists.txt vs configure) and thus to find future options, etc. No explicit need for it though 2019-07-01 16:17:51 Well, I guess I equally dislike CMake and Autoconf, but if it works I'm not against it 2019-07-01 16:18:02 Might wanna update the directfb comment though 2019-07-01 16:18:48 Ah true 2019-07-01 16:20:41 I personally prefer how Meson has a separate file with all available build options. But not everything uses it sadly 🤷‍♂️ 2019-07-01 16:28:46 we should keep upstream with decision 2019-07-01 16:31:12 Meson is super nice, yes 2019-07-01 16:36:18 PureTryOut[m]: i can push if you want, but you will not get any packages unless you bump pkgrel. 2019-07-01 16:36:25 dunno if that was intentional 2019-07-01 16:37:19 ncopa: what package are you talking about? 2019-07-01 16:38:13 Ah Mesa 2019-07-01 16:38:16 That was unintentional, fixed it 2019-07-01 16:39:39 Thanks for merging it! 2019-07-01 16:39:47 yw 2019-07-01 16:44:06 Cogitri: seems that it runs out of memory even when not using unified builds 2019-07-01 16:44:15 please review pr9161 2019-07-01 16:44:18 webkit2gtk that is 2019-07-01 16:44:34 Oof 2019-07-01 16:44:39 That's pretty bad 2019-07-01 16:47:14 i wonder if its a bug in code or in compiler 2019-07-01 16:48:08 It don't think you could call that a bug 2019-07-01 16:48:12 ... -o Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/llint/LowLevelInterpreter.cpp.o -c ../Source/JavaScriptCore/llint/LowLevelInterpreter.cpp 2019-07-01 16:48:19 It's just that massive amounts of code take up massive amounts of resources to compile 2019-07-01 16:49:48 does not look like a massive amount of code: https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp 2019-07-01 16:50:23 i wonder if it is somethign that ends up as recursive defines or something 2019-07-01 16:50:58 ACTION doesn't know cpp enough to be of help with that 2019-07-01 16:51:01 @ncopa so there is a dup, should I close the pr9161 ? 2019-07-01 16:52:59 ncopa: that looks like a smart person trying to do something very stupid :D 2019-07-01 16:54:32 the dup pr failed in an unexpected error, the 9161 pr ci failed because build grpc not install the newer protobuf, if merged, will build successfully. 2019-07-01 16:56:11 wener_: i would appreciate if you could could investigate what the difference is. the other PR had lots of comments and i haven't taken the time to read it all (again) to get up to date what the current status is and compare it with your pr 2019-07-01 16:56:51 ok, wait a minute 2019-07-01 16:56:58 the current state (with two PRs) is that I need to read them both, understand exactly what they do and why and how, and know exactly what the difference is to be able to make a decision what PR should be closed 2019-07-01 16:57:09 so its currently double work for me ;) 2019-07-01 16:57:11 also 2019-07-01 16:57:22 from looking at it 30 seconds 2019-07-01 16:58:11 it looks like there are a handful packages that needs to be rebuilt 2019-07-01 16:58:22 so i dont think any can be merged as is 2019-07-01 17:01:15 Yup, protobuf usually breaks ABI 2019-07-01 17:02:44 i wonder if ENABLE_C_LOOP is significant 2019-07-01 17:03:22 i dont even know what ENABLE_C_LOOP does 2019-07-01 17:03:57 @ncopa done, please check https://github.com/alpinelinux/aports/pull/6848#issuecomment-507347089 2019-07-01 17:06:18 pr9161 also upgraded grpc, which depends on protobuf, so I upgrade both in one pr 2019-07-01 17:07:01 ncopa: From what I understand reading the CMake files you have to either enable JIT or C_LOOP 2019-07-01 17:17:31 wener_: good job! i will try have a look at it tomorrow 2019-07-01 17:18:38 Cogitri: looks like jit is disabled for x86 2019-07-01 17:19:11 @ncopa for some package, there is official binary, should I just install the binary or rebuild them all in package ? 2019-07-01 17:19:39 ncopa: Yes it is 2019-07-01 17:19:55 But we don't have C_LOOP enabled there, huh 2019-07-01 17:20:00 Cogitri: i wonder if it was due to PaX kernel 2019-07-01 17:20:12 and i wonder if JIT works for arm at all 2019-07-01 17:20:21 maybe we we could try build with JIT 2019-07-01 17:20:54 I'm pretty sure it failed at least for armv7, but giving it another go won't hurt 2019-07-01 17:22:12 wener_: i dont know. i dont understand the question 2019-07-01 17:23:55 if package only contain a binary, but there is official built binary for musl, should the APKBUILD rebuild the binary or donwload and install ? 2019-07-01 17:24:33 wener_: we build from source whenever possible 2019-07-01 17:24:44 👌 2019-07-01 17:24:56 various reasons 2019-07-01 17:25:15 we have our own compile flags. we compile with optimize for size 2019-07-01 17:25:37 and our compiler has some hardening features enabled by default, like SSP and PIE 2019-07-01 17:26:28 Cogitri: my conclusion is that I'm no longer convinced the problem is unified builds 2019-07-01 17:26:52 i will continue tomorrow. have a nice evening everyone 2019-07-01 17:27:23 Bye bye, ncopa :) 2019-07-01 17:34:47 bye 😴 2019-07-01 21:39:44 PureTryOut[m]: did you tried to build new mesa on aarch64? it requires cbindgen which is not available on aarch64 2019-07-01 21:40:16 "the new" is what version? 19.1.1 works fine afaik 2019-07-01 21:41:11 yes, 19.1.1 2019-07-01 21:42:10 it worked for me few days ago, but not now. says that cbindgen is missing for deps 2019-07-01 21:43:44 Huh 2019-07-01 21:43:56 That doesn't seen write, Mesa isn't written in Rust 2019-07-01 21:43:59 something is strange, not much changed and I can't see why it ask for cbindgen 2019-07-01 21:44:06 s/write/right/ 2019-07-01 21:44:06 Cogitri meant to say: That doesn't seen right, Mesa isn't written in Rust 2019-07-01 21:44:31 probably I messed something in my lxc, sorry for disturbance 2019-07-01 21:48:44 oh, cbindgen was installed earlier, 'apk del cbindgen' solve problem 2019-07-01 21:50:28 👍 2019-07-01 21:50:46 Ah, also mps, have you tried Rust on armhf? 2019-07-01 21:51:04 no, only aarch64 and armv7 2019-07-01 21:52:45 if you want I can post somewhere rust 1.31 apk's 2019-07-01 21:52:54 for armv7, I mean 2019-07-01 21:54:16 Uhh...why would you? 2019-07-01 21:55:33 I have no idea why, to be fair. just told from back head. maybe someone is interested 2019-07-01 21:57:30 Ah no, we have Rust 1.35 tarballs already 2019-07-01 21:59:56 yes, I know, I have firefox-esr on aarch64 already ;) 2019-07-01 22:00:12 lazy to build it for armv7 2019-07-02 07:53:48 although I'm logged in to bugs.a.o I cannot see this issue. kind of some special issues? 2019-07-02 08:17:52 Hi all. 2019-07-02 08:20:14 Is there a way I can build the new abuild (3.4.0) that require to build also curl, but curl now has static subpackage that require to use the new abuild? ( as you can assume, I prefer not to use the official packages). 2019-07-02 08:21:17 weird, curl is in main/ so it should define their own static specifically for that case 2019-07-02 08:22:16 pr9258 2019-07-02 08:23:21 default_static is available with abuild from alpine 3.10.0 2019-07-02 08:23:27 algitbot Thank! 2019-07-02 08:24:24 maxice8 I know, but my builder is still alpine 3.9 and in order to update it I need to build myself the packages.. 2019-07-02 08:31:10 roigr: could bumping pkgrel help 2019-07-02 08:31:55 I mean, bump pkgrel, build curl locally and upgrade it 2019-07-02 08:34:00 I'm not sure I understand what exactly to bump and how will it help. My script build in a way that in order to build a package I build all it dependencies (recursively) 2019-07-02 08:36:14 then I misunderstood your question 2019-07-02 08:48:58 my question was how to build abuild 3.4.0 that depend on curl while curl need abuild 3.4.0 2019-07-02 08:57:17 algitbot solution indeed worked. Thanks! 2019-07-02 09:25:59 im not sure how to deal with https://github.com/alpinelinux/aports/pull/9246 2019-07-02 09:26:18 we dont really support packages in community that long 2019-07-02 09:26:33 however, we can apply security fixes on request, like in this case 2019-07-02 09:26:37 And it's a rather big change 2019-07-02 09:26:54 that is what i am worried about 2019-07-02 09:27:04 it changes the way the packages are splitted 2019-07-02 09:27:13 introduces new packages etc 2019-07-02 09:29:48 i was thinking that we could maybe backport the fix 2019-07-02 09:29:59 but the fix seems pretty intrusive as well 2019-07-02 09:30:05 and seems to have various tries.... 2019-07-02 09:30:14 https://github.com/moby/moby/pull/39357 2019-07-02 11:20:07 And.. another issue (Thanks for all the help so far!!) 2019-07-02 11:20:07 s= in there..) 2019-07-02 14:38:46 Cogitri: would you mind briefly explain how you bootstrap cargo/rustc/rust-bootstrap ? 2019-07-02 14:39:08 using the last version that rust is dependent on other lang (C? ) 2019-07-02 14:39:11 using the last version that rust is dependent on other lang (C? ) ? 2019-07-02 14:39:22 Nop 2019-07-02 14:39:31 also I wonder if llvm-libunwind is actually required 2019-07-02 14:39:55 looking at other distro they dont seem to need libunwind. Has something to do with musl ? 2019-07-02 14:40:11 *llvm-libunwind 2019-07-02 14:40:21 I crosscompile Rustc from x86_64-musl to the respective arch on Void Linux, which supports crosscompiling 2019-07-02 14:41:29 We _could_ use libgcc_s with a downstream patch, but I'm personally against going too far away from upstream on this and Rust 1.37 will tighten the dep on llvm-libunwind IIRC 2019-07-02 14:41:43 Crosscompiling on Alpine is a massive pain/not really possible, so yeah 2019-07-02 14:48:39 Cogitri: thanks for info :D 2019-07-02 14:54:38 👍 2019-07-02 14:57:14 @ncopa pr9161 failed because of travis-ci's linux kernel setting as before 2019-07-02 14:57:29 check pr5893 2019-07-02 23:44:19 maxice8: I see you merged Falkon, did Qt5Webengine get fixed? 2019-07-02 23:44:57 It's just in a page reload loop for me 2019-07-02 23:45:53 I don't see changes to QtWebengine, so I doubt it 2019-07-02 23:46:04 At least MellowPlayer still explodes for me 2019-07-03 00:23:06 PureTryOut: No it wasn't fixed yet 2019-07-03 08:03:43 should we move all community/ and testing/ packages that uses openjdk8 to using openjdk10 ? 2019-07-03 08:07:28 if they build with it, i'd say use the latest one 2019-07-03 08:09:50 most java 8 software seems to run fine on up to around java 10, but that's just a casual observation on my side 2019-07-03 08:14:32 also, I think I can take a look on having adopopenjdk on Alpine 2019-07-03 08:16:06 adopt? 2019-07-03 08:16:29 AdoptOpenJDK 2019-07-03 08:16:34 i'm not sure we'd want to package prebuilt binaries though? 2019-07-03 08:16:53 it has source code available afaik 2019-07-03 08:17:23 yes, so does a lot of software, but packaging prebuilt binaries is generally shady 2019-07-03 08:17:42 and i feel like it would be unnecessary too, if we have our own builds 2019-07-03 08:18:34 not sure what alpine's policies are on that though 2019-07-03 08:19:17 I don't think we need to use prebuilt binaries for adoptopendjk, but to be clear, openjdk7,8 have been packing .jar since forever 2019-07-03 08:19:31 I think it's openjdk thinggy 2019-07-03 08:23:47 correct ? 2019-07-03 08:24:22 dunno off the top of my head, i for the most part avoid java 2019-07-03 08:58:03 tmhoang1: Will prebuilt binaries even work on musl? 2019-07-03 08:58:53 for adoptopenjdk ? I don't think so 2019-07-03 09:07:59 okay it's me bullshitting about openjdk7,8 using binaries. it's just ant binary used for building processes. 2019-07-03 10:07:09 tcely: 34c5eaf34c440e4a13c158a3cf98a3163e34e170 is wrong 2019-07-03 10:08:00 `apk search mumble` says that the current version of mumble in our repos is 1.3.0, while in reality it is 1.3.0 rc1 2019-07-03 10:10:30 argh! 2019-07-03 10:10:36 we shipped it to 3.10 release 2019-07-03 10:17:40 ncopa, you around? An issue with libvirt CVE of 3.9 2019-07-03 10:17:55 This patch: https://libvirt.org/git/?p=libvirt.git;a=blobdiff;f=src/qemu/qemu_driver.c;h=40a2aa440fee2ef5f503bccd24062d634c0b3771;hp=2127a5bc3d0f04505e5b7eb74f75d33f393920fe;hb=aed6a032cead4386472afb24b16196579e239580;hpb=63427110b6ad8f993874aa3c0c3bfb7245ce7676 2019-07-03 10:18:37 cause build to fail: https://dpaste.de/A9C5 2019-07-03 10:18:53 Looking at the source code, I've found this: 2019-07-03 10:19:16 src/access/viraccessapicheck.c:int virDomainSaveImageGetXMLDescEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags) 2019-07-03 10:19:16 src/access/viraccessapicheck.h:extern int virDomainSaveImageGetXMLDescEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags); 2019-07-03 10:20:04 I'm not a C coder, but for what I understand, I need to remove the "unsigned int flags" on src/access/viraccessapicheck.c and src/access/viraccessapicheck.h 2019-07-03 10:20:25 does it make sense? 2019-07-03 10:21:13 patch removes the 'flags' argument, but actually the function is declared with that arg 2019-07-03 10:22:38 hi 2019-07-03 10:23:37 that needs more investigation 2019-07-03 10:23:57 that patch alone cannot be the fix 2019-07-03 10:24:23 iirc i had a quick look at libvirt cve, but concluded with it would be simpler to wait for new release 2019-07-03 10:24:31 right 2019-07-03 10:24:38 but this is a backport for 3.9 2019-07-03 10:25:15 looks that CVE-2019-10161 patch does not apply out-of-the-box to libvirt 4.10.0 2019-07-03 10:25:28 and 4.10.1 has never been shipped 2019-07-03 10:26:03 hum 2019-07-03 10:26:16 wondering if http://tpaste.us/P0xQ would be sufficient... 2019-07-03 10:26:41 no 2019-07-03 10:26:57 you need to ajust all callers of that function also 2019-07-03 10:27:29 so that patch is not enough alone 2019-07-03 10:28:07 http://tpaste.us/P0xQ <- this removes the flags from the callers 2019-07-03 10:28:17 unsigned int flags 2019-07-03 10:30:24 no, its the declaration of the function itself 2019-07-03 10:30:57 this is the full patch: https://libvirt.org/git/?p=libvirt.git;a=patch;h=aed6a032cead4386472afb24b16196579e239580 2019-07-03 10:31:18 yes, but does not apply 2019-07-03 10:31:45 there's no entry for VIR_DOMAIN_SAVE_IMAGE_XML_SECURE in src/remote/remote_protocol.x 2019-07-03 10:33:00 This is how I've applied the CVE-2019-10161 for libvirt 4.10.0 in Alpine 3.9: 2019-07-03 10:33:01 http://tpaste.us/65on 2019-07-03 10:33:46 right, that looks better 2019-07-03 10:33:50 the last hunk is the caller 2019-07-03 10:34:27 but src/remote/remote_protocol.x does not have VIR_DOMAIN_SAVE_IMAGE_XML_SECURE 2019-07-03 10:34:40 infact, the patch fails when apply that part 2019-07-03 10:34:45 i think that is some rpc definition 2019-07-03 10:34:50 im not sure how that works 2019-07-03 10:34:54 it looks like a comment 2019-07-03 10:35:05 right, that is what I thought too 2019-07-03 10:35:08 but i dont know if the parser uses that to generate the header 2019-07-03 10:47:53 seems that the patch applies from libvirt 5.0.0 2019-07-03 10:47:57 not backward 2019-07-03 11:01:06 see i fyou can find patches from debian or some other distro 2019-07-03 11:31:13 https://sources.debian.org/data/main/libv/libvirt/5.0.0-4/debian/patches/security/CVE-2019-10161-api-disallow-virDomainSaveImageGetXMLDesc-.patch 2019-07-03 11:31:27 applied this to libvirt 5.0.0 2019-07-03 18:55:18 mps: had time to look at rust on armhf yet? 2019-07-03 18:55:39 Cogitri: you mean armv7 2019-07-03 18:56:44 I mean armhf 2019-07-03 18:57:28 huh, my armhf is small box 4GB ram and FS is on microSD 2019-07-03 18:57:59 I can try, ofc, but don't expect much from it 2019-07-03 18:58:43 Oh, I thought you had said that you were able to build Rust on it 2019-07-03 18:59:49 only on armv7 and aarch64, never told armhf, iirc. If I told that then it was mistake 2019-07-03 19:00:27 Oh, alright, I guess I got that wrong then 2019-07-03 19:00:31 I'll ask in #alpine-infra then, thanks nontheless :) 2019-07-03 19:00:47 I have armhf as lxc container on armv7 2019-07-03 19:01:21 I mean, armv7 physical box with 4GB and SD card 2019-07-03 19:01:37 Oh, alright 2019-07-03 19:01:54 I have armv7 lxc container with a lot more RAM and CPU's 2019-07-03 22:45:41 mps: Could you try compiling Rust on aarch64? It works fine on my container now, but it SIGBUSes on CI, which makes me a bit nervous 2019-07-04 07:26:13 Cogitri: good morning. sure, give me PR number 2019-07-04 07:28:27 pr9134 2019-07-04 07:29:57 Morning mps :) 2019-07-04 07:31:53 building, will report results, now going to drink something to wake me up 2019-07-04 07:32:50 you should update checksum ;) 2019-07-04 07:34:17 Pretty sure I already did :o 2019-07-04 07:34:19 it was so fast, 'error: Could not compile `getopts`.' 2019-07-04 07:34:44 So it SIGBUSes for you too? :c 2019-07-04 07:37:05 Gonna upload a new tarball in a bit, hopefully that will work. I'm a bit curious why it passes on my aarch64 container now though 2019-07-04 07:38:32 don't see reason, but audit shows something about "/usr/lib/crti.o" 2019-07-04 07:40:36 maybe I need to uninstall 'my' rust first, forgot that 2019-07-04 07:41:37 would be more sapient to work on this after coffee ;) 2019-07-04 07:50:17 Helloo.. 2019-07-04 07:50:17 Why clang depends on gcc: http://0x0.st/z2k6.txt 2019-07-04 07:56:08 runtime 2019-07-04 08:04:27 umm? 2019-07-04 08:32:37 My uneducated guess would be because we don't build it against compiler-rt 2019-07-04 08:32:57 yes 2019-07-04 08:33:11 here be dragons etc 2019-07-04 08:33:32 you should be able to link it against compiler-rt if its installed though 2019-07-04 09:28:11 It turns out that compiler-crt is almost an empty package 2019-07-04 09:51:14 Cogitri: i think im making progress with webkit2gtk 2019-07-04 09:51:54 Nice 👍 2019-07-04 09:51:57 if i add -g1 to CXXFLAGS and make sure those are passed over properly to cmake, the build becomes significantly faster 2019-07-04 09:52:02 and fails faster 2019-07-04 09:52:27 i managed to get it build on armhf a few days ago, but it failed on armv7 with different error 2019-07-04 09:52:40 seems like our patch fix_armv6 is broken 2019-07-04 09:53:14 Oh, I had thought no `-g` option implied no debugging at all 2019-07-04 09:53:59 i think -DCMAKE_BUILD_TYPE=Release adds/overrids our CXXFLAGS 2019-07-04 09:54:41 i now have separate successful builds of armv7 and armv6 2019-07-04 09:54:43 Ah, CMake magic, right 2019-07-04 09:54:48 still no success on x86 though 2019-07-04 09:55:04 Great! 2019-07-04 09:55:21 so i think i can push fixes for arm 32bit today 2019-07-04 09:55:22 Oh, how come it doesn't work on x86? It worked in my x86 chroot just fine (with a 64-bit kernel) 2019-07-04 09:55:29 no idea 2019-07-04 09:56:01 maybe i can play with ulimits or something 2019-07-04 09:56:17 but i think i'll push update + enable arm 32bit first 2019-07-04 09:56:42 Okie 👍 2019-07-04 09:56:48 Thanks for looking into it 2019-07-04 09:56:58 this success is the motivation i needed :) 2019-07-04 09:57:08 im switching to ninja while at it 2019-07-04 09:57:37 How faster is ninja compared to make ? :o 2019-07-04 09:57:50 i havent tested 2019-07-04 09:58:12 i dont think the diff is that big 2019-07-04 10:02:56 If Ninja works for you that's nice 2019-07-04 10:03:06 It failed for me even on x86_64, but maybe I did something wrong 2019-07-04 10:03:38 i can switch back to make if you prefer that 2019-07-04 10:03:45 maxice8: On Exherbo webkit2gtk went from ~22mins to ~20mins on my testbench with ninja 2019-07-04 10:04:14 thats the numbers i'd expect 2019-07-04 10:04:43 Oh, I prefer Ninja if it works :) 2019-07-04 11:03:33 now webkit only need fix for x86 2019-07-04 11:04:16 hum 2019-07-04 11:04:23 this warning looks scary 2019-07-04 11:04:26 ../Source/ThirdParty/xdgmime/src/xdgmimemagic.c:489:5: warning: "LITTLE_ENDIAN" is not defined, evaluates to 0 [-Wundef] 2019-07-04 11:04:26 #if LITTLE_ENDIAN 2019-07-04 11:04:26 ^~~~~~~~~~~~~ 2019-07-04 11:50:50 ncopa: pr9267 could be backported but not sure about argon2 package yet 2019-07-04 13:01:57 mps: Mind trying Rust again on aarch64 with http://sprunge.us/8EPWyH applied? 2019-07-04 14:17:53 Cogitri: PR 9134? 2019-07-04 14:18:10 sorry, I was AFK 2019-07-04 14:19:26 No worries 2019-07-04 14:19:34 Yes please 2019-07-04 14:21:14 Just pushed to pr9134 again, so you don't have to apply the patch yourself 2019-07-04 14:24:17 again same error: 'error: Could not compile `getopts`.' 2019-07-04 14:25:00 no luck 2019-07-04 14:27:56 Huh, with the new tarball? 2019-07-04 14:30:51 I just downloaded and applied patch and run 'abuild -r' 2019-07-04 14:30:58 ah, I see 2019-07-04 14:31:32 I need first remove tarballs from cache? 2019-07-04 14:31:57 Yup 2019-07-04 14:31:59 I build in lxc where cached files are preserved 2019-07-04 14:32:19 ok, will clean cache and try again 2019-07-04 14:32:19 Make sure you have the latest version of that pr 2019-07-04 14:32:21 I changed the aarch64 tarball to a different one 2019-07-04 14:33:22 I do: wget https://github.com/alpinelinux/aports/pull/9134.patch 2019-07-04 14:33:24 Thank you 2019-07-04 14:33:38 git am ../9134.patch 2019-07-04 14:34:19 cd community/rust and 'abuild -r > & ! ~/rust-build.log' 2019-07-04 14:35:05 That should work, although doing curl -L | git am seems easier 2019-07-04 14:35:14 What's your HEAD? 2019-07-04 14:37:03 Alright, it failed with the same error on CI 2019-07-04 14:37:03 Thanks for trying though 2019-07-04 14:37:13 Although I'm confused why it works on my machine now 2019-07-04 14:37:56 yes, failed again 2019-07-04 14:39:00 does it depends on my current HEAD? I don't think so, but could try to sync with current git.a.o 2019-07-04 14:41:46 ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/ILHTJLQOVlAIoXMZdbYsYJFO > 2019-07-04 14:41:47 ^ uh, what? 2019-07-04 14:42:45 PureTryOut[m]: really what, :) 2019-07-04 14:43:16 mps: Ah, meant the HEAD of my branch :) 2019-07-04 14:50:07 Is there anyway to install this updated package? 🤔 2019-07-04 14:50:23 As far as I can see, the APKBUILD has nothing that makes it depend on itself of a specific version 2019-07-04 14:53:26 Oh it worked now 2019-07-04 14:53:27 Maybe I forgot to update APKINDEX? Idk 2019-07-04 15:31:33 andypost[m]: sorry i didnt reach to look at that argon2 thing. can you please ping me tomorrow? 2019-07-04 15:32:26 Sure 2019-07-04 16:32:20 what is the target triple for x86 32bit ? i586-linux-musl? 2019-07-04 19:25:11 artok: i686-alpine-linux-musl IIRC 2019-07-04 19:27:27 i586-alpine-linux-musl 2019-07-04 19:27:37 ? 2019-07-04 19:30:00 Oh, right, i586 2019-07-04 19:33:11 ACTION wonders why it is called triplet 2019-07-04 19:38:24 mps: Because the historically consisted of three strings: arch-os-vendor 2019-07-04 19:38:57 So e.g. aarch64-linux-gnu 2019-07-04 19:40:13 I know, just wondering why we still call it triplet and not quartet 2019-07-04 19:41:11 Well, Debian just calls them tuples, which seems more correct, but oh well 2019-07-04 19:41:28 As long as everyone knows what's meant with triplets it's fine by me 2019-07-04 19:45:35 OT little, personally I prefer words/terms with clear semantic 2019-07-04 19:50:18 yah 2019-07-04 19:51:32 so there is error on clang 2019-07-04 19:52:21 patch adds i686-alpine-linux-musl as triplet on X86 2019-07-04 19:52:39 and that is triplet because arch-os-abi 2019-07-04 19:53:14 that fourth is vendor before os and not necessarily needed but still used =) 2019-07-04 19:57:34 Right, should be i586-alpine-linux-musl, I guess 2019-07-04 23:09:27 I'm working on a package that uses a license very close to BSD-3-Clause but is missing a part of the last sentence. How should I package this if the license is not in a single file but rather a header in each source file? 2019-07-04 23:10:13 https://github.com/gweis/isodate 2019-07-04 23:13:05 I noticed Arch uses `head` to put the license into a separate file at build time. Is this acceptable for in Alpine? 2019-07-04 23:16:35 rmsvc: I'd say open an issue with the upstream maintainer/developers and have them fix it 2019-07-04 23:16:41 that just seems plain broken 2019-07-04 23:27:17 danieli: there's already an open issue about it. I'm guessing the author gave up on the project seeing as though the last commit was almost a year ago 2019-07-04 23:28:06 hm, unless it's critical, I'd personally be against packaging and including unmaintained software in alpine repos 2019-07-04 23:30:06 yeah, this is probably for the better 2019-07-04 23:30:46 do you want to package it because it's a dependency of another package? 2019-07-04 23:32:27 yeah, I was working on packaging streamlink and it's the only dependency not in the alpine repos 2019-07-04 23:33:13 Hm, if it works and doesn't cause problems I don't see the problem with packaging it 2019-07-04 23:33:19 ohhh, streamlink package 2019-07-04 23:33:21 yeahhhh 2019-07-04 23:34:18 right, i was working on streamlink too 2019-07-04 23:34:25 i didn't get super far though, i got busy with other stuff 2019-07-04 23:34:54 I was gonna look at it over the weekend as I noticed it wasn't packaged when I went to use it the other day 2019-07-04 23:35:20 better if someone else does it though :D 2019-07-04 23:35:27 doesn't seem like gweis/isodate has any dependencies other than six, and it seems like a fairly small repo 2019-07-05 03:20:45 lol 2019-07-05 06:04:15 How come it is an issue? 2019-07-05 06:46:02 errn0[m]: maybe we need something better for bug reporting. like Debian's reportbug ? 2019-07-05 07:23:52 mps: Do we? I don't feel a need of it :) 2019-07-05 07:23:53 I would love to know your opinion too 2019-07-05 07:29:02 something which pressure bug reporter to give more info and better descpription would be good, imo 2019-07-05 07:33:17 mps: That bug report was kinda meh.. yeah.. but ... 2019-07-05 07:34:32 I see alpine community as a experinced userbase who knows what they are doing/talking, knows around the debugger and has ability to report bugs accordingly.. so and so 2019-07-05 07:34:40 s/a/an 2019-07-05 07:34:40 errn0[m] meant to say: I see anlpine community as a experinced userbase who knows what they are doing/talking, knows around the debugger and has ability to report bugs accordingly.. so and so 2019-07-05 07:35:10 ay 2019-07-05 07:39:03 well, yes, but I personally have some kind 'laziness' to answer not clearly or ambiguous reported bugs and even to ask additional questions or explanations from reporter 2019-07-05 08:08:59 mps: Not sure what to say... just tag it [Need additional info] 2019-07-05 11:11:33 Cogitri: congrats :) so we only missing rust on aarch64 2019-07-05 11:11:55 Thanks :) 2019-07-05 11:12:04 Am working on that together with Rust 1.36 2019-07-05 11:13:09 good work. now I can delete it from my 'back' brain. *Thank you* 2019-07-05 14:10:12 PureTryOut: Alkimia is failing on ppc64le https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/alkimia/alkimia-8.0.1-r0.log 2019-07-05 14:23:30 Is there a place to drop suggestions for what to put in the next release ? 2019-07-05 14:23:38 next release notes* 2019-07-05 15:34:21 maxice8: maybe alpine-devel ML 2019-07-05 15:34:32 or new wiki page 2019-07-05 15:34:50 Wiki page should be better 2019-07-05 15:35:11 maybe discuss these even here, or just some. 2019-07-05 15:36:17 wiki page is good for list things but not useful for discussions 2019-07-05 15:37:52 although, I posted to ML few months ago some ideas about vim and didn't got any comment 2019-07-05 15:38:11 maybe this channel is best place, after all 2019-07-05 15:39:55 For discussions, sure, but I feel like a Wikipage is a good choice for preserving the points until we actually have to make the release notes 2019-07-05 15:40:15 It's easy to forget about them if we just discuss it here 2019-07-05 15:42:29 agree, combined 'things' till we create something better 2019-07-05 15:45:01 Cogitri: i think i have found a way to make webkit2gtk to build on 32bit x86 2019-07-05 15:45:25 disable _FORTIFY_SOURCE 2019-07-05 15:47:03 Huh, that needs that much RAM? :o 2019-07-05 15:47:16 I wonder if we should disable fortify source on all arches in the LLIntAssembly, or if we should disable fortify source for everything webkitgtk on x86 2019-07-05 15:47:24 Anyway, nice 2019-07-05 15:48:09 It'd be best if we could do the former 2019-07-05 15:48:19 i think i just add -U_FORTIFY_SOURCE on x86 2019-07-05 15:48:21 its simpler 2019-07-05 15:48:34 i think its related to the way our fortify source is implemented 2019-07-05 15:49:37 stateless: webkit2gtk fails to build on 32 bit x86 with fortify-headers: cc1plus: out of memory allocating 65536 bytes after a total of 3131101184 bytes 2019-07-05 15:57:56 Oh, alright 2019-07-05 16:06:07 do we have rust on arm finally? 2019-07-05 16:07:00 we do! 2019-07-05 16:07:10 armv7 and armhf! nice work! 2019-07-05 16:09:01 Cogitri: i think the commit message in 69851bdae1177246337f51a35734e93f1fd7e3d3 should be a comment in APKBUILD 2019-07-05 16:09:23 Cogitri: thanks alot for the work there! its awesome! 2019-07-05 16:10:19 ncopa: It kind of is in the APKBUILD and won't be relevant in a few days anyway when I bump to 1.36.0, so I think the commit msg is more visible :) 2019-07-05 16:11:51 i think the comment is relevant for bootstraping new arch? 2019-07-05 16:11:58 for aarch64 and s390x 2019-07-05 16:12:31 in any case, I'm super happy that we finally have rust on more arches 2019-07-05 16:17:34 Ah, true that. Glad to be of help with that :) 2019-07-05 16:40:29 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas) 2019-07-05 16:40:49 Nice 👍 2019-07-05 16:41:10 :D need other people to contribute as well 2019-07-05 18:19:27 maxice8: that failing test seems to be a hit and miss. Sometimes it fails (on any architecture), sometimes it succeeds 2019-07-05 18:19:48 I think it should just be disabled entirely, it's too unpredictable 2019-07-05 18:19:59 Yes 2019-07-05 18:20:56 I don't have access to a PC till monday though, someone else will have to do it 2019-07-05 18:49:23 done 2019-07-05 18:53:06 pr7873 can be closed 2019-07-05 18:53:17 pr7881 can be closed 2019-07-05 20:08:00 pr4949 pr7873 pr7881 can be closed 2019-07-05 20:16:14 aren't they auto closed when the PR is pushed to aports 2019-07-05 20:17:47 Not if it's a duplicate and another PR is pushed 2019-07-05 20:19:14 aha, thank for explanation 2019-07-05 22:00:36 I want to work on rust on s390x but it seems it's pretty low priority for s390x so I couldn't allocate time to work on it 2019-07-05 22:00:56 also there are some work in progress to port llvm-libunwind to s390x 2019-07-05 22:01:15 libunwind s390x code landed last year, should be available for 1.4 release 2019-07-05 22:01:27 not sure why 1.3.x do not contain it though 2019-07-05 22:01:33 ncopa: aha 2019-07-05 22:01:50 ncopa: any indication as to why it fails? 2019-07-05 22:02:36 tmhoang: If you need help with that feel free to ping me, but I don't have high hopes for it as of now, Rust doesn't even support std for s390x-musl yet 2019-07-05 22:02:52 But it does have full support for s390x-gnu 🤔 2019-07-05 22:04:05 yeah if there are growing numbers of (important) packages that depends on rust, I can allocate time to work on it 2019-07-05 22:04:44 Well, for now it's mostly non-core stuff, so it's not a pressing matter (yet) 2019-07-05 22:04:47 as of for now, it seems only firefox-esr is notable 2019-07-05 22:04:54 And librsvg maybe 2019-07-05 22:05:37 what's wrong with librsvg ? 2019-07-05 22:07:25 It uses Rust too for >= 2.42 2019-07-05 22:07:27 Or 2.44? 2019-07-05 22:09:54 right 2019-07-05 22:22:32 Cogitri: did you forgot to add armv7-alpine-linux-musleabihf to rust or you skip it for now 2019-07-05 22:23:25 Yeah, seems like something went wrong on armv7 and armhf 2019-07-05 22:23:33 Will look into it once I have aarch64 running 2019-07-05 22:24:56 it builds on armv7, and installed it. but it missing target. only have arm-alpine-linux-musleabihf for arm32 2019-07-05 22:25:52 Oh, yes, seems like that's not in the alpine-target.patch 2019-07-05 22:26:04 ls -l => 40423892 Jul 5 12:29 rust-1.35.0-r0.apk 2019-07-05 22:26:09 My bad, somehow I just assumed that it covered all arches! 2019-07-05 22:26:14 I'll add armv7 and ppc64le 2019-07-05 22:27:13 do you have patches for these targets 2019-07-05 22:27:40 Not yet, but will make them 2019-07-05 22:27:59 I only need to create a ~30 line file describing the arch, so it's not a big deal 2019-07-05 22:28:53 true, you can use arm-* or aarch64-* as 'template' 2019-07-05 22:29:14 I can just use the upstream triplets as template :) 2019-07-05 22:29:15 I'm not sure if patches I have could be applied 2019-07-05 22:29:42 actually I suspect 2019-07-05 22:30:35 yes, upstream triplets (quartets, hehe) could be used 2019-07-05 22:33:34 Could you test something for me on aarch64? 2019-07-05 22:34:01 My aarch64 builder apparently only has 60KB of disk space left which isn't sufficient for building rust :P 2019-07-05 22:34:06 ikke: ^ 2019-07-05 22:37:47 Oh, nevermind, the compiler crashes on your machine (and CI) for some reason. I guess I'll wait for more disk space on my aarch64 container then 2019-07-05 22:38:31 yes, fails to build getopt, iirc 2019-07-05 22:41:48 Yup :/ 2019-07-05 22:43:45 strange is that it works on armv7 2019-07-05 22:44:55 aarch64 was problematic on Void too 2019-07-05 22:47:20 I tried with adelie tarballs and rust 1.33 on aarch64, and it worked till the trying internal llvm 2019-07-05 22:47:46 Yup, I'm trying with internal llvm right now too 2019-07-05 22:48:00 What's our ppc64le triplet? 2019-07-05 22:48:04 didn't worked much on it expecting that you find issue and fix it 2019-07-05 22:48:22 let me look 2019-07-05 22:48:34 Thanks 2019-07-05 22:50:18 should be: powerpc64-alpine-linux-musl 2019-07-05 22:50:28 but not sure 2019-07-05 22:53:03 or powerpc64le-alpine-linux-musl 2019-07-05 22:55:12 uhm, even ppc64le-alpine-linux-musl 2019-07-05 22:56:08 never gave enough attention to powerpc 2019-07-05 22:58:55 someone who know powerpc better should tell 2019-07-05 23:05:12 https://github.com/alpinelinux/abuild/blob/master/functions.sh.in#L18 2019-07-05 23:05:16 I guess it's this 2019-07-05 23:07:59 looks like it is 2019-07-05 23:51:10 https://github.com/djazo/alpine-cross-sysroot did that kind of fun thingie 2019-07-05 23:55:40 now waiting for llvm toolchain to complete.. has been building for 5hrs or something like that =D 2019-07-05 23:56:27 PGO enabled 2019-07-06 05:45:45 https://patchwork.alpinelinux.org/patch/4951/ can be changed to accepted 2019-07-06 06:36:26 pr4949 pr7873 pr7881 pr7843 pr7839 can be closed 2019-07-06 07:08:13 pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 can be closed 2019-07-06 17:43:04 has anyone already rpi4 and tested alpine on that? 2019-07-06 18:03:31 artok: to my knowledge: no 2019-07-06 18:03:44 the rpi 4 is brand new, so it's not a big surprise 2019-07-06 18:04:03 i'm considering ordering one or two, perhaps buy some new ones when/if the 8GB variant arrives 2019-07-06 18:11:56 8GB RAM ones? :o 2019-07-06 18:12:00 I might order one once that USB-C powersink defect is fixed 2019-07-06 18:21:59 yeah, the regulatory paper shipped with the RPi 4 1/2/4GB also lists "8GB" as a variant 2019-07-06 18:22:00 and +1 2019-07-06 18:59:52 I'm just wondering if to add my credit card details to the order =) 2019-07-06 19:00:28 but indeed, no hurry at the moment 2019-07-06 19:00:50 first might go trying to use kernel version 5 on rpi3b 2019-07-06 19:36:03 anyone know why installing qemu-system-$arch pulling in mesa and bros ? 2019-07-06 19:37:02 mesa for virgl most likely 2019-07-06 19:38:32 hmm interesting 2019-07-06 19:39:48 let me hit abuild with that disabled and see 2019-07-06 20:25:26 So I finally got a working streamlink package after creating 9 other apkbuilds for its dependencies 2019-07-06 20:25:37 Would anyone be willing to check them out for any obvious mistakes before I submit them to the mailing list? 2019-07-06 20:26:28 If so, it's the last 10 commits here: https://git.sr.ht/~sacks/aports/log 2019-07-06 20:28:39 Uhh...how can I review these? 2019-07-06 20:29:59 To view them you can click on the commit hash... if that's what you mean 2019-07-06 20:30:50 With Github I can just click any line of the commit to comment it which makes reviewing so much easier 2019-07-06 20:33:17 Like create a pull request on Github? 2019-07-06 20:33:44 That'd be the best way to get a review on your stuff, yes 2019-07-06 20:34:14 I mean we do offer Patchwork, bust most coredevs apparently dislike using it (and so do I) 2019-07-06 20:35:01 Ok, I'll work on creating a pull request 2019-07-06 20:35:08 Thanks 2019-07-06 20:40:02 Feel free to `@Cogitri` me in the PR to make sure I don't forget about it :) 2019-07-06 20:41:16 Cogitri: are you sure about patchwork ;) 2019-07-06 20:43:03 mps: Weren't you the one who told me that PW isn't popular with core devs? :P 2019-07-06 20:44:43 maybe I did, but it doesn't mean that codedevs dislike it. Although I agree that it is cumbersome for devs with mostly GUI experience 2019-07-06 20:45:01 s/codedevs/coredevs/ 2019-07-06 20:45:01 mps meant to say: maybe I did, but it doesn't mean that coredevs dislike it. Although I agree that it is cumbersome for devs with mostly GUI experience 2019-07-06 20:52:53 rmsvc: oh sourcehut, I like it 2019-07-06 20:53:58 mps: Ah, my bad, was using `dislike it` in the sense that they don't really use it 2019-07-06 20:56:27 Cogitri: so is it fine I'm creating a pull request with 10 commits in it? 2019-07-06 20:56:41 each commit is a new aport 2019-07-06 20:56:55 Sure 2019-07-06 20:57:33 Since those are dependencies for streamlink it's fine to crowd them into one PR 2019-07-06 20:57:50 Ok, I created it and tagged you in the comment 2019-07-06 20:58:05 Thanks 2019-07-06 20:58:14 And thanks for the help. I really appreciate it 2019-07-06 20:58:18 out of curiosity, what is streamlink 2019-07-06 20:59:02 It's like youtube-dl but specifically for live streams 2019-07-06 20:59:55 aha, thanks for info 2019-07-06 21:15:03 rmsvc: Left some comments 2019-07-06 21:15:12 But now it's time to sleep, gn 2019-07-06 21:29:04 Cogitri: thanks, I'll be working on these later tonight 2019-07-06 22:18:23 pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 pw4941 pw4940 can be closed 2019-07-07 04:52:34 How I can prevent abuild not to uninstall packages after a failure in APKBUILD build? 2019-07-07 04:56:13 <[[sroracle]]> change ERROR_CLEANUP in ~/.abuild/abuild.conf, /etc/abuild.conf 2019-07-07 04:56:33 <[[sroracle]]> or pass the -K option 2019-07-07 05:00:27 [[sroracle]]: That worked 2019-07-07 05:21:28 > Issue (new): [Alpine Linux]: Package request: solc: https://bugs.alpinelinux.org/issues/10660 2019-07-07 05:21:29 I have built this package, everything is working as expected, wrote the APKBUILD file. Now how can I submit? 2019-07-07 05:21:30 Do I need a github account? 2019-07-07 05:22:26 <[[sroracle]]> if you don't want to make a github account you can submit it to the alpine-aports mailing list. github tends to be more responsive though 2019-07-07 05:22:42 M0x32_t[m]: you can send with 'git send-email --to alpine-aports@lists.alpinelinux.org' 2019-07-07 05:23:28 patch will appear at patchwork.a.o 2019-07-07 05:25:04 [[sroracle]]: I see. I have no problems with github 2019-07-07 05:25:41 So it is just regular GitHub PR in aports? 2019-07-07 05:28:29 <[[sroracle]]> yep, https://github.com/alpinelinux/aports/pulls 2019-07-07 06:38:31 Build fails: https://cloud.drone.io/alpinelinux/aports/8287/ 2019-07-07 06:43:13 I am not doing github builds, rather tarball builds, why I am getting this error? "CMake Error at cmake/scripts/buildinfo.cmake:52 (message): 2019-07-07 06:43:14 Unable to determine commit hash. Either compile from within git repository 2019-07-07 06:43:15 or supply a file called commit_hash.txt" 2019-07-07 06:43:36 I have added a dummy commit_hash.txt, still build fails 2019-07-07 06:46:48 M0x32_t[m]: not sure if it related, but I had similar issue when build from aports dir without .git initialized 2019-07-07 06:47:03 and I'm not expert in cmake 2019-07-07 06:50:25 Me neither, cmake is blackbox for me :( 2019-07-07 06:54:46 this channel could be quite calm on weekends and in early morning (europe) especially now in vacation time 2019-07-07 06:55:46 repeat you question later and maybe even tomorrow if you don't find solution in meantime 2019-07-07 06:56:04 Sure.. no probs 2019-07-07 07:44:10 Yay.. build passed: 2019-07-07 07:44:11 https://cloud.drone.io/alpinelinux/aports/8291 2019-07-07 07:44:25 THANKS ALOT 2019-07-07 07:48:49 nice :0 2019-07-07 07:50:17 what is github PR url/number 2019-07-07 07:50:45 mps: https://github.com/alpinelinux/aports/pull/9343 2019-07-07 07:52:19 oh, programming lang, first time hear for it 2019-07-07 07:52:38 mps: Ye.. 2019-07-07 07:53:13 and it doesn't depend on llvm, very nice 2019-07-07 07:54:03 I can push it to aports if someone else didn't started process already 2019-07-07 07:54:16 Lightweight yeah... 2019-07-07 07:55:32 There are still some unaddressed review comments as far as I can see 2019-07-07 07:56:17 cogitri: Such as? 2019-07-07 07:59:35 commit messages repeating 'Update APKBUILD' too much 2019-07-07 08:00:09 mps: I see... will add commit messages 2019-07-07 08:00:20 And will fixed those typos 2019-07-07 08:00:41 and you should prepend commit messages with 'testing/solidity:' 2019-07-07 08:01:16 Well, those should be squashed into one commit anyway, I guess 2019-07-07 08:01:33 maybe even squash all commits to just one, a lot easier for commiters to review PR and apply 2019-07-07 08:01:47 Cogitri: you are faster ;) 2019-07-07 08:02:06 Hehe 2019-07-07 08:04:26 cogitri: 2019-07-07 08:04:27 "Please be more precise, what's actually going wrong?" 2019-07-07 08:04:27 I just disabled the test for my machine.. is it allowed? 2019-07-07 08:04:57 We try to run tests whenever we can 2019-07-07 08:05:12 So don't just disable tests for no specific reason 2019-07-07 08:05:26 I see. o you know how to perform tests in cmake? 2019-07-07 08:05:37 do you..* 2019-07-07 08:05:47 Or I just should make check it? 2019-07-07 08:05:53 M0x32_t[m]: disable test is last thing if nothing else helps and you are sure pkg works correctly 2019-07-07 08:06:31 Either call ctest directly to make test 2019-07-07 08:14:40 Failed again: https://cloud.drone.io/alpinelinux/aports/8293/ 2019-07-07 08:15:27 I will wok on this tomorrow 2019-07-07 08:15:46 work* 2019-07-07 08:17:04 eh, making language to work takes time. sometimes even months 2019-07-07 08:18:19 according to repology.org api we have 842 pkg's with problematic url, mostly http instead of https 2019-07-07 08:18:29 Oh? 2019-07-07 08:18:32 Great 2019-07-07 08:21:29 and there is a lot of perl pkg's with url's 'search.cpan.org' instead of 'metacpan.org' 2019-07-07 08:22:25 Both seems to pint to same domain 2019-07-07 08:22:30 What blocks em up? 2019-07-07 08:22:38 point* 2019-07-07 08:23:23 Ow no redirect 2019-07-07 08:24:52 search.cpan.org is retired, still works but simply redirects to metacpan.org 2019-07-07 08:27:01 ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/EwxkzSvkoRYdUBrSDMeSbUEa > 2019-07-07 08:27:39 If I disable the build check.. it builds.. if I enable tests, it fails... 2019-07-07 08:27:40 Not knowing cmake making things hard for me for sure 2019-07-07 08:28:43 does upstream site have anything on making tests during build 2019-07-07 08:31:22 mps: They already had a discussion on it.. https://github.com/ethereum/solidity/issues/3076#issuecomment-336503636 2019-07-07 08:31:22 Looks like something to do with that commit_hash.txt file.. 2019-07-07 08:31:23 Either I have to add a dummy file or just pull from git head straight. 2019-07-07 08:31:59 The error message is almost identical 2019-07-07 08:32:46 [APKBUILD](https://github.com/b17wise/aports/blob/master/testing/solidity/APKBUILD) 2019-07-07 08:34:13 right. I think it is better to add commit hash text file than build 'in git' dir 2019-07-07 08:35:51 Yeah.. but as now I am building from tarball, so I have no clue 2019-07-07 08:37:30 also you have function 'default_prepare()' in APKBUILD. it should go to prepare() function 2019-07-07 08:38:38 mps: I did that, already 2019-07-07 08:40:06 ah, sorry, I need to reapply new patch 2019-07-07 08:40:51 I am missing something... 2019-07-07 08:40:52 What it might be? 2019-07-07 08:42:18 first, in commit message you should change 'responding to #10660' to start on new line to be 'fixes #10660' 2019-07-07 08:42:47 let me try build it locally 2019-07-07 08:43:24 mps: Ye.. please.. 2019-07-07 08:43:24 That's what I am doing.. I will fix commit messages, as long as it builds :) 2019-07-07 08:44:45 what does this error means: 'CMake Error at cmake/scripts/buildinfo.cmake:34 (string): string sub-command STRIP requires two arguments.' 2019-07-07 08:45:29 mps: I have no clue...that's where I am stuck 2019-07-07 08:45:49 Looks like cmake is generating wrong args into that 2019-07-07 08:46:25 also I don't know, we have to wait for someone who understand cmake or search the internet 2019-07-07 08:46:44 Looking into it 2019-07-07 08:47:15 Ah, you can't have an empty commit_hash.txt 2019-07-07 08:47:29 See like 33 of that script 2019-07-07 08:47:54 It reads the contents of commit_hash.txt into the variable SOL_COMMIT_HASH 2019-07-07 08:48:21 If that's empty then the call to STRIP fails in line 34 2019-07-07 08:48:37 so, in prepare() commit_hash.txt should be written 2019-07-07 08:49:06 No 2019-07-07 08:49:32 Use the proper release from upstream which comes which that files 2019-07-07 08:49:42 s/which/with/ 2019-07-07 08:49:42 Cogitri meant to say: Use the proper release from upstream with comes which that files 2019-07-07 08:49:58 yes, agree, I think this is it: https://github.com/ethereum/solidity/commit/5a6ea5b19793f61c7703d4abe587b2bf40decc31 2019-07-07 08:50:25 or shorten version, if allowed 2019-07-07 08:50:26 s/files/file/ 2019-07-07 08:50:26 Cogitri meant to say: Use the proper release from upstream with comes which that file 2019-07-07 08:50:30 https://github.com/ethereum/solidity/releases/download/v0.5.10/solidity_0.5.10.tar.gz 2019-07-07 08:50:45 cogitri: Even if I remove that file and use tarball, it fails 2019-07-07 08:51:31 "remove that file"? 2019-07-07 08:52:31 Now what I can do else? I am on latest tarball 2019-07-07 08:53:24 it is probably bug, there have empty commit_hash.txt file in tarball 2019-07-07 08:54:53 ' echo -n "5a6ea5b19793f61c7703d4abe587b2bf40decc31" > commit_hash.txt' looks like it works 2019-07-07 08:57:32 building, will take time probably. https://www.xkcd.com/303/ 2019-07-07 08:57:33 https://xkcd.com/303 | Compiling | Alt-text: 'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.' 2019-07-07 08:57:51 mps: Now adding the commit hash builds the project 2019-07-07 08:58:21 > building, will take time probably. https://www.xkcd.com/303/ 2019-07-07 08:58:21 https://xkcd.com/303 | Compiling | Alt-text: 'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.' 2019-07-07 08:58:22 Ahahaha 2019-07-07 08:58:24 I'm trying locally 2019-07-07 08:58:35 same here 2019-07-07 08:59:13 going to take something for breakfast, see you later when building finish 2019-07-07 09:00:37 It is i3 here xD 2019-07-07 09:00:48 Intel i3 2019-07-07 09:01:41 my is i7, but still not fast 2019-07-07 09:04:23 and I remember days when I build kernels on i486 with 33MHz (yes mega not giga) clock 2019-07-07 09:05:50 These days kernel got bigger 2019-07-07 09:06:46 true, and this is my moan ;) 2019-07-07 09:13:56 build finished, but check says 'No tests were found!!!' 2019-07-07 09:14:45 94% here 2019-07-07 09:15:17 Hmm.. tests might not exists.. that's why Arch Linux and Gentoo ebuilds ship it DTESTS=NO 2019-07-07 09:17:06 interesting, compiler without tests :/ 2019-07-07 09:18:30 then you can remove check() and add 'options="!check" # package does not have tests' 2019-07-07 09:18:37 Ahahah xD 2019-07-07 09:18:45 or something similar in comment 2019-07-07 09:18:49 > then you can remove check() and add 'options="!check" # package does not have tests' 2019-07-07 09:18:50 Ye.. I am going to do that 2019-07-07 09:19:54 Pretty sure it has tests 2019-07-07 09:21:02 Btw, 0x32_t: seems like you have lots of trailing spaces in the APKBUILD 2019-07-07 09:23:04 yes, trailing whitespace should be trimmed 2019-07-07 09:23:22 I trimmed ithem in vim now 2019-07-07 09:24:09 M0x32_t[m]: you can run 'abuild sanitycheck' in dir 2019-07-07 09:24:20 Nice feature 2019-07-07 09:24:52 ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/TUkfUkDeSylWLnvrJiRNKfIU > 2019-07-07 09:25:05 ">>> solidity: Checking sanity of /tmp/APKBUILD..." 2019-07-07 09:25:06 Seems fine? 2019-07-07 09:25:09 0x32_t: There is also apkbuild-lint from atools 2019-07-07 09:25:40 I am leaving tests fo for now... no idea why it is ignoring tests 2019-07-07 09:25:41 yes, apkbuild-lint is better 2019-07-07 09:31:35 Try running "$builddir"/test/soltest in check() :) 2019-07-07 09:34:48 ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/zCwkDmkgWsQFpKIWSoqfygTD > 2019-07-07 09:34:56 No tests were found!!! 2019-07-07 09:36:17 That's from the soltest binary? 2019-07-07 09:39:45 No.. what is soltest? 2019-07-07 09:39:45 Also take a look here... https://cloud.drone.io/alpinelinux/aports/8294/ 2019-07-07 09:43:43 ^ 2019-07-07 09:43:58 solidity builds a binary called soltest and puts it in the directory I've mentioned 2019-07-07 09:44:36 It runs soldity's tests, so call that binary in check() 2019-07-07 10:00:57 I see.. 2019-07-07 10:00:58 Well, I am out now 2019-07-07 10:01:27 Okie, no need to rush things :) 2019-07-07 13:07:36 maxice8: FYI, i have disabled rofi for now. 2fd96ce013b3eaafaa0f7a3088b98fe75d6ac273 2019-07-07 13:09:18 I need rofi so I'll give it a spin when I have time 2019-07-07 13:11:18 ncopa: Ack 2019-07-07 19:15:11 How to deal with non-deterministic tarballs ? (google codestorage) 2019-07-07 19:43:59 solved :D 2019-07-07 19:45:23 maxice8: nice :) 2019-07-07 19:45:39 I know whom to ask if need this 2019-07-07 19:46:41 ACTION hides 2019-07-07 19:46:46 i just used a github mirror :D 2019-07-07 19:47:39 ah, even this is good hint 2019-07-07 19:59:42 worrysome news https://utcc.utoronto.ca/%7Ecks/space/blog/unix/XDeathwatchStarts 2019-07-07 20:04:50 p4Wv1qn095FW: more reasons to switch to text mode ;) 2019-07-07 20:05:07 :) 2019-07-07 20:05:21 my gopher client is already running in text mode \o/ 2019-07-07 20:06:08 maxice8: Hey.. you merged by port (/testing/solidity/APKBUILD).. thank you a lot :) 2019-07-07 20:06:14 by coincidencd I looked today that links web browser need upgrade 2019-07-07 20:07:30 b17wise: M0x32_t[m] worked on it today. do you have connection with this person 2019-07-07 20:09:03 mps: Yeh.. we are both same person 2019-07-07 20:09:04 :) 2019-07-07 20:10:06 I thought so, but asked to be sure 2019-07-07 20:13:11 Does someone happen to have a native x86 builder? 2019-07-07 20:13:50 native? 2019-07-07 20:13:52 https://github.com/alpinelinux/aports/pull/9305 fails on CI but I can't reproduce it in my x86 container (on my x86_64 host) :c 2019-07-07 20:14:04 mps: Couldn't able to do that without your help either :) 2019-07-07 20:14:46 clandmeter: As in on a x86 hostos + x86 kernel 2019-07-07 20:14:53 b17wise: np, happy to help 2019-07-07 20:15:06 At least I'm not sure why it works on my machine otherwise 2019-07-07 20:15:14 if you want a 32bit kernel you could use qemu 2019-07-07 20:16:47 Yeah, but I'm not that enthusiastic about that seeing that my last attempt with aarch64 failed :c 2019-07-07 22:28:54 Lot of PRs for stuff in main/ :D 2019-07-07 22:35:03 I'm scared of 'enable pulseaudio support' 2019-07-07 22:38:24 mps: haha same 2019-07-07 22:38:27 also I made a thing 2019-07-07 22:38:28 https://code.foxkit.us/snippets/23 2019-07-07 22:39:26 mepholic: nice to see you :) 2019-07-07 22:39:38 i didn't realize that I hadn't been in devel for months 2019-07-07 22:41:28 Is adelie linux 'desktop oriented' 2019-07-07 22:41:37 yes 2019-07-07 22:42:09 uhhhmmm, where to escape ;-) 2019-07-07 22:42:33 well, not necessarily desktop oriented 2019-07-07 22:42:41 but it is moreso than alpine I guess 2019-07-07 22:44:02 what does red 'X' after PR on github means 2019-07-07 22:44:19 CI failed 2019-07-07 22:44:38 either drone-ci or travis-ci failed to compile the changed APKBUILDs 2019-07-07 22:45:20 hm, I see some of them that are 'superseded' and can be closed 2019-07-07 22:45:58 for example PR #8699 2019-07-07 22:46:34 it is already upgraded and moved to community 2019-07-07 22:46:39 i usually send a message with a list of PR and PW that can be closed 2019-07-07 22:46:53 pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 pw4941 pw4940 can be closed 2019-07-07 22:47:45 maxice8: I noticed your messages but don't know how to close them on GH, and I think I don't have rights for that because I don't have GH account 2019-07-07 22:48:36 hopefully someone with GH access can take a look at them 2019-07-07 22:48:45 although it happens that some GH PR's are closed by me and I have no idea how it is happened 2019-07-07 22:49:09 algitbot closes them ? 2019-07-07 22:49:18 probably 2019-07-07 22:49:46 algibot closes PRs automatically when the relevant commits are merged 2019-07-07 22:50:13 hehe, maybe I can play with algitbot :) 2019-07-07 22:50:16 what the relevant commits are is not well defined since i can fetch a PR amend a few commits and push and algibot will still close the PR 2019-07-07 22:51:00 it also ended up closing 2 PRs when i merged a rust update the one for the main tree and one for 3.10 (which i didn't merge) 2019-07-07 22:51:14 I didn't dived much to this, waiting for gitlab 2019-07-07 22:56:45 maxice8: I can close PW's, sorry didn't noticed that you also post them 2019-07-07 22:57:07 no worries :D 2019-07-07 22:57:16 i'll just keep posting them 2019-07-07 22:58:10 I'll look at them tomorrow, now I'm not behind my working box 2019-07-08 06:37:25 what is the best way to pacakge a software with ruby deps not shipped with alpine? 2019-07-08 06:38:02 I was wondering about a post-install message saying "please run gem install $package" 2019-07-08 06:56:21 fcolista: short answer is: not package it all 2019-07-08 06:56:51 let users ask upstream 2019-07-08 06:57:23 that said, i think that is a good use case for docker 2019-07-08 06:58:50 that's a good point 2019-07-08 06:58:55 use it with docker 2019-07-08 06:59:44 basically, when talking with ruby ppl about difficulties of building system packages (apk packages) it has been like "use gem" 2019-07-08 06:59:55 so i think we should just push users over to that 2019-07-08 07:02:50 agree 2019-07-08 07:19:10 probably bundler 2019-07-08 07:19:44 fcolista: ruby has alpine docker containers 2019-07-08 07:20:04 thats how im doing gitlab now 2019-07-08 07:20:11 cause we dont have 2.6 2019-07-08 07:20:24 I was looking to oxidised 2019-07-08 07:20:36 a rancid replacement 2019-07-08 07:20:53 (backup and restore config of tons of devices) 2019-07-08 07:21:08 they have docker, based on ubuntu 2019-07-08 07:21:33 I suppose that the only thing would be having that image updated using alpine rather than ubuntu 2019-07-08 07:31:36 fcolista: I use bundler for redmine to run it on Alpine 2019-07-08 07:32:11 I never used ruby and related things, so I don't know how these tools work 2019-07-08 07:33:02 also I used ruby first time when I build readmine 2019-07-08 07:33:37 looked at Arch linux and clandmeter helped also 2019-07-08 07:54:48 linux 5.2 stable released. let's will it be LTS (would be nice so we can upgrade) 2019-07-08 07:56:02 s/let's/let's see/ 2019-07-08 07:56:02 mps meant to say: linux 5.2 stable released. let's see will it be LTS (would be nice so we can upgrade) 2019-07-08 07:56:35 speaking of linux 5.2, i have a email from greg about my email address as a contributor. 2019-07-08 07:57:43 Danct12: nice to have kernel dev here :) 2019-07-08 07:58:28 not really a kernel dev because the only change that i've done was adding a new acpi device id to the touch screen driver silead 2019-07-08 07:58:54 but people say if you touch the source code you're a dev 2019-07-08 07:59:26 I have some patches but don't have patience to pass all steps to post any of them 2019-07-08 08:54:11 ncopa: hi, reminder about argon2 & php backport 2019-07-08 09:34:34 andypost[m]: im slightly confused about exactly what i need to do wrt argon2 and php 2019-07-08 09:34:49 https://bugs.alpinelinux.org/issues/10649 is marked as resolved 2019-07-08 09:40:39 ncopa the question of php backport and upgrade of argon2 2019-07-08 09:41:26 ncopa it resolved in edge only 2019-07-08 09:42:37 ncopa upgrade is pr9279 2019-07-08 09:43:36 so 43d556c0cb086ef5d94e22fc362c779cd2268042 and 69cf5153388a8f006da7b816c7b2b9c31f6367e1 needs to be cherry-picked for 3.10-stable? 2019-07-08 09:43:57 i tried to build https://github.com/alpinelinux/aports/pull/9279 on 3.10-stable but it failed 2019-07-08 09:44:37 oh, pr9279 is not merged to edge even 2019-07-08 09:45:00 but build fails? 2019-07-08 09:45:05 Not sure about 7.3.7 - just started testing but cherry pick makes sense 2019-07-08 09:45:05 you still want to merge it? 2019-07-08 09:45:17 or you want me to fix the build? 2019-07-08 09:45:33 It hits timeout as always( 2019-07-08 09:45:41 so i just merge it? 2019-07-08 09:45:49 Yep 2019-07-08 09:45:58 have you tested that it builds? 2019-07-08 09:46:28 i merged it 2019-07-08 09:46:31 to master 2019-07-08 09:47:08 and cherry-picked the two commits for 3.10: 43d556c0cb086ef5d94e22fc362c779cd2268042 and 69cf5153388a8f006da7b816c7b2b9c31f6367e1 2019-07-08 09:47:52 Yes on x8664 and still not sure about how to minimise test suite to fit in 1h limit 2019-07-08 09:48:40 andypost[m]: if a commit has a "fixes #" it will mark the issue as resolved. if it should not be marked as resolved til until its backported to a stable branch, then i normally use "ref #" 2019-07-08 09:48:53 that way it will only be referenced in the issue, but not marked as resolved 2019-07-08 09:49:16 and in the cherry-picked commit i change commit message to "fixes #" 2019-07-08 09:49:35 that way its clear that the issue is not yet resolved til it is solved in all affected branches 2019-07-08 09:50:23 argon failed on edge as well: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/argon2/argon2-20190702-r0.log 2019-07-08 09:50:24 this should be written in developer guides 2019-07-08 09:50:33 mps: yeah 2019-07-08 09:50:59 very clear and concise and now I understand it 2019-07-08 09:57:15 I can now reproduce argon2 build locally - diggin 2019-07-08 09:59:55 hm, how it possible that no such dir if abuild running split 2019-07-08 10:01:14 That's the kind of bad error msg when the subpkg doesn't contain any files 2019-07-08 10:01:32 So there's nothing being moved into the -lib subpackage 2019-07-08 10:13:20 i fixed it 7155035b6f2096543de30afe8ad25a4f017864b3 2019-07-08 10:33:07 ncopa thanks a lot! btw about static packages - how to get https://github.com/alpinelinux/abuild/pull/72 in? 2019-07-08 10:33:33 :D 2019-07-08 12:47:23 friendly ping : pr9044 pr9098 2019-07-08 12:51:54 tmhoang1: feel free to @maxice8 on github when making changes to packages maintained by Leo 2019-07-08 12:53:08 thanks 2019-07-08 13:11:21 maxice8: I noted four PW's which you told could be closed 2019-07-08 13:11:41 pw4942 pw4943 pw4941 pw4940 2019-07-08 13:11:59 yes ? 2019-07-08 13:12:44 yes 2019-07-08 13:13:03 are they accepted, so to mark them according to status 2019-07-08 13:14:32 All superssed 0 1 2 because they were not proper so i did it myself and 3 because there is another version that is under review 2019-07-08 13:15:24 ok, will mark them as superseded then 2019-07-08 13:19:46 closed all four with 'Superseded' status flag 2019-07-08 13:22:04 eh, there were one my patch which I forgot to close :-| 2019-07-08 13:33:07 maxice8: fyi I'm checking retroarch error 2019-07-08 14:06:16 maxice8: pr9367 2019-07-08 14:33:13 re #10663: was abuild changed to not include .a files in -dev packages at all? 2019-07-08 14:33:46 No, it still does that if there's no -static subpkg IIRC 2019-07-08 14:33:54 either libxkbcommon needs to make a libxkbcommon-static subpackage, or upstream changed it 2019-07-08 14:34:37 it hasn't been changed since december 2018 though, so something changed on our side prior to or around the release of 3.10 2019-07-08 15:38:21 danieli: upstream uses meson now which doesn't generate static libraries afaik 2019-07-08 15:38:38 maxice8: the apkbuild hasn't been touched since december though? 2019-07-08 15:40:29 no clue 2019-07-08 16:13:35 maxice8: I see you updated stow recently, does it actually work for you? For me it complains about missing Choose.pm. When installing `perl-clone-choose` which provides that file, it just complains it can not find an appropriate `clone()` function 2019-07-08 16:14:30 Works for me but I'll take a look later 2019-07-08 16:24:43 How did that Stow upgrade pass CI anyway? It checkdepends has a package that's only available in testing while stow is in community 2019-07-08 16:30:44 Ah tests are disabled that's why 2019-07-08 18:47:45 FDI patch: bump 2019-07-08 20:15:07 mps up for closing patchwork patches ? :D 2019-07-08 20:16:33 maxice8: ok 2019-07-08 20:16:42 ready :) 2019-07-08 20:20:38 4962 4963 4964 2019-07-08 20:22:04 what status to put them? Accepted? 2019-07-08 20:22:40 superseeded 2019-07-08 20:22:58 aha, 4962 4963 superseded, what is with 4964 2019-07-08 20:23:27 superseeded 2019-07-08 20:24:22 ok, all are superseded now 2019-07-08 20:25:00 py3-httpretty has wrong perms on its egg-info directory 2019-07-08 20:25:03 :D makes it unusable 2019-07-08 20:25:18 then rejected? 2019-07-08 20:25:49 can't be imported 2019-07-08 20:26:25 don't see py3-httpretty 2019-07-08 20:26:56 ddevault: py3-weasyprint is also missing py3-pillow 2019-07-08 20:27:03 ack 2019-07-08 20:27:11 I thought I fixed httpretty 2019-07-08 20:27:16 maybe I didn't send the patch 2019-07-08 20:27:24 anyway I'll look at these in about 5 mins 2019-07-08 20:27:55 what to do with it, 4966 2019-07-08 20:27:56 :D i pushed a "fix" already 2019-07-08 20:28:02 just made everything inside the egg-info directory into 644 2019-07-08 20:28:14 maxice8: so, accepted? 2019-07-08 20:28:26 will problably be superseeded 2019-07-08 20:28:55 no, it will be superseeded because ddevault will post another patch adding the proper deps 2019-07-08 20:29:31 then 'not applicable' 2019-07-08 20:29:39 4790 4880 can be set to superseeded 2019-07-08 20:30:19 can be as well 2019-07-08 20:31:13 4157 'not applicable' 2019-07-08 20:31:51 3795 'not applicable' 2019-07-08 20:32:29 don't see 4157 2019-07-08 20:34:03 doesn't 3795 better fit for 'rejected' 2019-07-08 20:34:06 maxice8: mps: https://patchwork.alpinelinux.org/patch/4944/ 2019-07-08 20:34:09 v3 should be good with permissions 2019-07-08 20:34:17 v1 & v2 were broken, though 2019-07-08 20:34:31 :D pick what you will 2019-07-08 20:34:33 I have a working package built and in use based on v3 2019-07-08 20:34:49 https://mirror.sr.ht/alpine/v3.10/sr.ht/x86_64/py3-httpretty-0.9.6-r0.apk 2019-07-08 20:34:57 looking at weasyprint now 2019-07-08 20:35:18 is missing provides="py-httpretty=$pkgver-r$pkgrel" 2019-07-08 20:35:23 replaces is OK, both are used 2019-07-08 20:35:41 ddevault: 4944 is accepted 2019-07-08 20:36:10 so it needs a new patch adding provides? 2019-07-08 20:36:34 yes 2019-07-08 20:36:39 ack 2019-07-08 20:36:47 updated weasyprint patch coming momentarily 2019-07-08 20:37:42 httpretty patch out as well 2019-07-08 20:39:04 I also updated the python2 deprecation procedure to mention provides 2019-07-08 20:39:14 here https://wiki.alpinelinux.org/wiki/Python_package_policies 2019-07-08 20:39:15 weasyprint patch is not adding py3-html5lib 2019-07-08 20:41:03 maxice8: you pushed 4968? Can I mark it as 'accepted'? 2019-07-08 20:41:23 wait up 2019-07-08 20:41:31 afaict weasyprint does not depend on pillow 2019-07-08 20:41:36 it does depend on html5lib, though 2019-07-08 20:41:56 let's see will it pass builders, then 2019-07-08 20:42:05 well, let me send you a patch with html5lib 2019-07-08 20:42:20 I build my packages on a system without any python stuff installed 2019-07-08 20:42:25 so I'm surprised I'm not hitting this 2019-07-08 20:42:34 yes, it should actually be marked accepted automatically 2019-07-08 20:42:45 but looks like https://patchwork.alpinelinux.org/patch/4968/ already applied to aports 2019-07-08 20:43:04 new weasyprint patch up 2019-07-08 20:43:11 pw could be sometimes slow 2019-07-08 20:44:12 weasyprint GitHub release notes mention it needs CairoSVG over 2.4.0, ours is 2.3.0 2019-07-08 20:45:01 oh, I didn't pull that upgrade from my repo, sorry 2019-07-08 20:45:03 lemme grab it 2019-07-08 20:47:32 sent along 2019-07-08 20:47:44 I plan on pulling a lot of my packages into community during this release cycle, which should make things easier 2019-07-08 20:48:30 Hi team, what's the criteria for including a new package? 2019-07-08 20:48:47 Does it matter if it's pretty much just me that uses it? 2019-07-08 20:48:51 must be free software, APKBUILD must be pretty/correct (we can help with the latter) 2019-07-08 20:50:03 abuild will also emit warnings that you should correct should things not be ship-shape 2019-07-08 20:51:32 There is also apkbuild-lint and aports-lint from atools to find common mistakes and minor improvments 2019-07-08 20:51:59 ddevault: the py3-cairocffi commit is missing the repo part of the title, i'll reword it and push 2019-07-08 20:52:05 thanks maxice8, cheers 2019-07-08 20:53:00 np 2019-07-08 20:53:41 mps: 4967 -> 'superseeded', 4968 -> 'accepted' 2019-07-08 20:56:04 maxice8: done, and still 60 left :-) 2019-07-08 20:58:03 Sweet, I have an apkbuild and it works fine. I'll run apkbuild-lint and aports-lint and see if they complain 2019-07-08 21:01:45 fyi about pr9371: it's a trivial change 2019-07-08 21:02:35 danieli: i can't push to main :c 2019-07-08 21:03:05 maxice8: it's ok <3 just thought I'd let whoever can know it's a trivial improvement 2019-07-08 21:03:10 danieli: is it for ash? 2019-07-08 21:03:22 it's for any shell that sources /etc/profile.d/color_prompt.sh 2019-07-08 21:03:43 bash doesn't do that by default afaik, only for login shells 2019-07-08 21:03:46 but ash does 2019-07-08 21:03:55 mps: 4939 -> 'superseeded' , 4950 -> 'superseeded' 2019-07-08 21:04:26 I have it for tcsh always set like your patch 2019-07-08 21:04:31 it's similar to a change i make to all my unix hosts, I must have the user and *full* hostname as part of the PS1 (with green color for user and red for root) so I'm less prone to making mistakes 2019-07-08 21:04:51 finally got to thinking 'hmm, I should just upstream this' 2019-07-08 21:05:58 so I know if I'm nobody@ or some-admin@, and if I'm at server1.company.com or server1.personal.io 2019-07-08 21:06:02 maxice8: done 2019-07-08 21:06:23 mps: 4693 -> 'superseeded' 2019-07-08 21:07:08 danieli: I usually put these to $HOME/.profile (or other rc for shells) 2019-07-08 21:07:29 mps: 4542 -> 'superseeded' 2019-07-08 21:07:38 font-noto-cjk landed \o/ 2019-07-08 21:07:48 ddevault: 4542 -> 'i removed the build() { return 0 ; } since it is not required ans pushed' 2019-07-08 21:08:12 thanks! 2019-07-08 21:08:24 aren't lttng-tools upgrade accepted, or it was from GH, can't remember exactly 2019-07-08 21:09:11 please, no, font-noto-cjk (my personal moaning) 2019-07-08 21:09:14 mps: it was done by Luca Weiss 2019-07-08 21:09:18 f699d4f94410ae19e737b942b848484073798747 2019-07-08 21:09:27 aha, ok will mark it 2019-07-08 21:09:50 mps: what's your beef? 2019-07-08 21:09:52 you host a mirror? 2019-07-08 21:11:11 ddevault: don't think we need such big pkg, should be split somehow. It is about 10 times smaller in Debian, iirc 2019-07-08 21:11:44 as originally discussed, it can't really be split 2019-07-08 21:12:07 maxice8: done 2019-07-08 21:12:10 what to do with this old pw https://patchwork.alpinelinux.org/patch/3851/ ? 2019-07-08 21:12:35 it adds an apkbuild on abuild-pkg 2019-07-08 21:13:17 mps: 3786 -> 'broken' 2019-07-08 21:13:22 ah, I see what debian is doing 2019-07-08 21:13:26 not opposed to doing something similar 2019-07-08 21:13:59 I'm not sure if submitter of 3851 is still active on alpine 2019-07-08 21:14:05 but not sure 2019-07-08 21:15:27 maxice8: we don't have 'broken' tag 2019-07-08 21:15:56 ddevault: nice to hear ;-) 2019-07-08 21:16:05 added a reminder, will look into it within the week 2019-07-08 21:16:49 rejected then ? 2019-07-08 21:16:52 I looked few times on your patch and always had split minds, to push or not to push 2019-07-08 21:17:08 I think it's useful to have in its current form as well 2019-07-08 21:17:17 when I split it up the combined packages are not going to be smaller 2019-07-08 21:17:33 rejected sounds better, but we should then post mail to submitter 2019-07-08 21:17:50 erp, you're talking about the old patch, disregard me 2019-07-08 21:18:49 ddevault: don't worry, I have same feelings with some of my patches ;-) 2019-07-08 21:19:29 3786 -> rejected, wrong title, adds an aport but not its dependency and claims the license is GNU 2019-07-08 21:19:57 :D thanks to anyone that emails the person in question 2019-07-08 21:20:33 maxice8: could we make list of PW's for which we should post mail to submitters with explanation why are they rejected/superseded and not just close them 2019-07-08 21:20:54 when I review patches I usually give a short thanks in reply 2019-07-08 21:20:58 he/she will be elated to recieve a rejected email a year, 1 month and 4 days after he/she sent the patch :D 2019-07-08 21:20:59 but I don't use patchwork, I just work out of my inbox 2019-07-08 21:21:51 more than a half of submitters doesn't respond to mail, but anyway, we should be nice and polite 2019-07-08 21:22:00 we could but that is more work than i'm willing to put on patchwork, i'm a GitHub (Futurely GitLab) person 2019-07-08 21:23:27 well, when the lists.sr.ht migration is behind us, you can work through aports patches without ever leaving your mail client 2019-07-08 21:23:30 or touching a browser at all 2019-07-08 21:23:39 much more efficient and makes it easy to give it the human touch with a little "thanks" 2019-07-08 21:25:11 maxice8: nice, 55 left, good job 2019-07-08 21:27:03 enough for me now, going out to walk a little before sleep 2019-07-08 21:31:17 mps: my task is to get under 30 2019-07-08 21:32:17 at last half of them could be simply rejected, imo 2019-07-08 21:32:33 mps: 4875 -> 'rejected' no answer from author for 38 days 2019-07-08 21:35:10 I'm not behind my work machine, but will note this and 'reject' it later 2019-07-08 21:39:20 mps: 3779 -> 'rejected' doesn't apply anymore 2019-07-08 21:40:26 ddevault: 4957 and 4958 are reviewed and need fixes 2019-07-08 21:42:20 did you not Cc me on your replies? 2019-07-08 21:45:10 i used neomutt's mailing list mode no clue if that does 2019-07-08 21:49:53 mps: 4524 -> 'accepted' made some cleanup and pushed 2019-07-08 21:50:42 ok, noted 2019-07-08 22:44:44 what's a good way to get the current version of alpine, major.minor.patch? 2019-07-08 22:44:55 i.e. not just 3.10, but 3.10.0 2019-07-08 22:45:03 i have access to a mirror locally, but is there an easy way to get it? 2019-07-08 22:45:15 i'm just reading the latest-stable symlink at the moment, but it only gives 3.10 2019-07-08 22:45:17 /etc/os-release? 2019-07-08 22:45:35 ah, you mean something else 2019-07-08 22:45:46 the host this application is running on may not be up to date 2019-07-08 22:45:47 you could look at the RSS feed? 2019-07-08 22:45:51 excellent idea 2019-07-08 22:46:57 ^Alpine (.*) released$ 2019-07-08 22:47:04 would it be safe to assume the latest one is always at the top? 2019-07-08 22:47:22 ¯\_(ツ)_/¯ 2019-07-08 22:47:53 i'll go with yes 2019-07-08 23:17:49 ncopa: i wrote a thing for alpine-mksite: http://mirror-size-api.gbr1.alpin.pw/data.json 2019-07-08 23:17:53 i'll implement it in alpine-mksite tomorrow 2019-07-08 23:27:09 ddevault: "finished" dealing with telegram-desktop 2019-07-08 23:27:16 time to look at your patches 2019-07-08 23:28:52 :D they are for main, please put / in the commit title 2019-07-08 23:34:13 didn't I? I'm sorry 2019-07-08 23:34:24 no, I did't :( 2019-07-09 00:09:34 mps: 3784 -> can problably be rejected since it adds an aport with a name that is already claimed 2019-07-09 02:44:26 aha, there's a latest-releases.yaml file 2019-07-09 03:21:36 mps: 4961 -> 'superseeded' 2019-07-09 03:22:50 actually 'accepted' 2019-07-09 09:48:31 maxice8: PW4961 is accepted not superseded as I see 2019-07-09 09:49:18 looks like you fixed it, but at the end it is accepted with your fixes 2019-07-09 09:50:28 mps: Yes i said accepted one line later 2019-07-09 09:50:32 it's a pity PW doesn't have option to add comment when changing status 2019-07-09 09:51:07 oh, I missed this line somehow 2019-07-09 09:51:45 maxice8: did you have time to look at stow? 2019-07-09 09:51:54 PureTryOut: i downgraded it 2019-07-09 09:54:50 maxice8: 3784 is accepted but commiter probably forgot to close it 2019-07-09 09:55:14 Ah ok thanks 2019-07-09 09:55:26 oh 2019-07-09 09:56:09 git log -p testing/singularity/APKBUILD, and go to end 2019-07-09 09:57:15 mps: those singularities are different 2019-07-09 09:57:41 maintainer is the same and version is the same 2019-07-09 09:58:32 ./configure options are different, true 2019-07-09 09:58:36 oh i tis 2019-07-09 09:58:39 then 'accepted' 2019-07-09 09:58:54 already changed 2019-07-09 10:00:18 53 left, something tells me in back head that we need time to achieve goal of less the 30 2019-07-09 10:02:02 algitbot anounce sec bugs but I can't see them 2019-07-09 10:05:08 its a setting in redmine i think 2019-07-09 10:05:13 will have a look at it 2019-07-09 10:06:43 i changd the developer role to see prviate issues 2019-07-09 10:06:57 mps: can you check if you can see them now? 2019-07-09 10:09:05 ncopa: yes, now I see them 2019-07-09 10:09:08 thanks 2019-07-09 10:10:41 mps: 4738 -> 'accepted' 2019-07-09 10:11:52 maxice8: done 2019-07-09 10:12:05 ty 2019-07-09 10:12:14 np 2019-07-09 10:19:17 mps: (4833 4633) -> 'rejected' 2019-07-09 10:20:03 mps: 4739 -> 'superseeded' 2019-07-09 10:20:39 did you sent mail for (4833 4633) to submitter 2019-07-09 10:20:48 no 2019-07-09 10:21:46 hmm, what to do, close without mail? 2019-07-09 10:21:52 ncopa: ^ 2019-07-09 10:23:52 4739 is actually accepted, commit 74ef3e0b4c67a5f0e4dc0d5148e91bc28508d4a1 2019-07-09 10:42:42 mps: 3894 -> 'accepted' 2019-07-09 11:38:08 maxice8: 3894 closed 2019-07-09 11:39:34 nice, ty 2019-07-09 11:39:35 Working on the seamonkey PR :D 2019-07-09 11:40:41 maxice8: ty for your hard work. btw, do you sleep ever 2019-07-09 11:40:57 what is sleep? 2019-07-09 11:41:08 :-D 2019-07-09 11:41:21 Yes but then maxice1 through 7 take over 2019-07-09 11:41:31 Teamwork makes the dream work 2019-07-09 11:41:49 maxice8: could you tell whys https://patchwork.alpinelinux.org/patch/4833/ is rejected 2019-07-09 11:42:13 s/whys/why/ 2019-07-09 11:42:13 mps meant to say: maxice8: could you tell why https://patchwork.alpinelinux.org/patch/4833/ is rejected 2019-07-09 11:42:53 mps: uses source with master from github not a correct commit 2019-07-09 11:43:03 Or a tagged release 2019-07-09 11:43:41 ah, ok, will close it 2019-07-09 11:47:21 anyone with python experience would look at https://patchwork.alpinelinux.org/patch/4094/ 2019-07-09 12:34:11 4887 can be pushed with a pkgrel bump 2019-07-09 12:34:16 after fixing the commit title as well 2019-07-09 12:40:42 maxice8: I don't have rights to push to main 2019-07-09 12:41:19 dammit 2019-07-09 12:41:36 PRs on GItHub are Pilling up for changes in main/ 2019-07-09 12:41:51 And most stuff on pw is now main as well 2019-07-09 12:41:57 you pushed pw4885, can we close it with accepted 2019-07-09 12:42:15 I'm on phone can I get a link? 2019-07-09 12:42:44 https://patchwork.alpinelinux.org/patch/4885/ testing/gajim-plugin-omemo 2019-07-09 12:43:17 and testing/seamonkey looks like you fixed it 2019-07-09 12:44:07 Yes I could swear the gajim one was automatically marked accepted 2019-07-09 12:44:17 If not then please do and seamonkey as well 2019-07-09 12:45:28 yes, sorry, probably my browser cache problem 2019-07-09 12:54:54 this https://patchwork.alpinelinux.org/patch/4828/ and https://patchwork.alpinelinux.org/patch/4827/ could be marked as 'Not applicable' or 'Rejected', submitter didn't answer my question/request to fix for two months. what you think 2019-07-09 13:03:28 how do I add something to run on boot in alpine? 2019-07-09 13:03:57 i'm looking for the equivalent of a systemd oneshot unit 2019-07-09 13:06:04 Cadey: read /etc/local.d/README 2019-07-09 13:07:01 and, user support is better on #alpine-linux channel than here 2019-07-09 13:07:12 interesting, thanks 2019-07-09 13:47:34 What does it mean when abuild finds textrels in a package? 2019-07-09 13:53:55 https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide 2019-07-09 13:56:14 i.e. text relocations 2019-07-09 14:37:52 Thanks 2019-07-09 15:10:17 mps: new syslinux and flask patches up, thanks for your patience 2019-07-09 15:29:14 ddevault: thanks, now we just have to ask someone with main access to push them 2019-07-09 16:22:26 mps: what do you want me to push? 2019-07-09 16:24:17 ncopa: ddevault posted some patches to main on pw.a.o 2019-07-09 16:24:21 let me see 2019-07-09 16:24:36 syslinux update default kernel 2019-07-09 16:24:41 im pushing that now 2019-07-09 16:24:50 yes, https://patchwork.alpinelinux.org/patch/4977/ 2019-07-09 16:25:15 the py3-flask and py3-werkzeug upgrades also affect main 2019-07-09 16:25:56 eh, nice, ddevault is here, he will explain better than me 2019-07-09 16:26:05 ddevault: have checked that there is nothing that dpends on py2-flask or py2-werkzeug? 2019-07-09 16:26:45 eh, that would have been wise to do 2019-07-09 16:27:01 community/py-flask-login/APKBUILD: py2-flask 2019-07-09 16:27:01 community/py-flask-login/APKBUILD:subpackages="py2-flask-login:py2 py3-flask-login:py3" 2019-07-09 16:27:01 testing/py-flask-sqlalchemy/APKBUILD:subpackages="py2-flask-sqlalchemy:py2 py3-flask-sqlalchemy:py3" 2019-07-09 16:27:01 main/py-flask-wtf/APKBUILD:subpackages="py2-flask-wtf:py2 py3-flask-wtf:py3" 2019-07-09 16:27:05 looks like 3 other packages will be affected 2019-07-09 16:27:14 I'll take care of them tonight 2019-07-09 16:27:32 sounds good 2019-07-09 16:27:45 thanks for getting rid of python2 stuff. appreciate 2019-07-09 16:27:59 np 2019-07-09 16:28:13 at some point soon I'll be starting on a larger python2 deprecation project 2019-07-09 20:59:09 Directories in /var/run is an issue I've seen a few times now. Is there a standard way to address this or should one be created? A run sure startup script maybe? 2019-07-09 20:59:50 s/sure/directory/ 2019-07-09 20:59:50 tcely meant to say: Directories in /var/run is an issue I've seen a few times now. Is there a standard way to address this or should one be created? A run directory startup script maybe? 2019-07-09 21:00:34 ACTION needs to review txt replacement rules to see what lead to sure 2019-07-09 21:14:24 tcely: afaik /var/run is created as symlink to run on boot, if your question was about this 2019-07-09 21:16:36 mps: /run (/var/run) is normally empty at boot, but a few packages expect subdirectory with specific permissions to exist before starting 2019-07-09 21:17:06 dhcp and irqbalance come to mind 2019-07-09 21:17:54 A generic solution that happens early in the boot sequence might be better than changes to individual packages 2019-07-09 21:19:07 /var/run/irqbalance is kind of hardcoded now :D the "problem" is just with init scrip which should create directory 2019-07-09 21:19:43 https://github.com/alpinelinux/aports/pull/9384 2019-07-09 21:20:25 same like with iperf* daemons which in init scripts got paths to dir which arent created not to mention that iperf conflict with iperf3 and one init is wrong but ye need bug report that :D 2019-07-09 21:20:50 My opinion is that software expecting directories like this should call mkdir themselves instead of relying on start script. 2019-07-09 21:21:09 tcely, yep 2019-07-09 21:23:42 HRio, thank you! 2019-07-09 21:24:12 simple enough for a 3.10 backport 2019-07-09 21:24:53 That iperf* situation is a good example of why handling these directories in a common way might make better sense 2019-07-09 21:25:06 does systemd does something "magical" for dirs like this? 2019-07-09 21:25:22 irqbalance was still working fine without it but upstream somehow decided to make file-based sock dunno, default? 2019-07-09 21:25:24 do on the second does :-) 2019-07-09 21:26:13 s/d does/d do/ 2019-07-09 21:26:20 ;-) 2019-07-09 21:26:23 :-) 2019-07-09 21:31:29 im going to bed. good night 2019-07-09 21:32:43 gn8! 2019-07-09 22:58:33 ddevault ping 2019-07-09 22:58:49 :D i'm going to review your python batch and it is easier if we talk "real-time" via IRC 2019-07-09 23:01:14 maxice8: I'm here but only somewhat paying attention 2019-07-09 23:01:24 is there some specific reason why cabal and ghc are only built for x86_64? no arm/arm64? 2019-07-09 23:01:50 ddevault: good enough 2019-07-09 23:03:44 tboerger: I guess no one had time/interest making it happen on other arches yet 2019-07-09 23:06:05 no other reason than that? 2019-07-09 23:06:26 tboerger: If there is another it is normally listed near the arch="" definition on the APKBUILD 2019-07-09 23:08:38 mkay, nothing written down there 2019-07-09 23:12:43 maxice8: afk, but I will review my highlights when I return 2019-07-09 23:16:13 ddevault: 4983 -> license is non-SPDX 'BSD' and no need for mkdir -p "$pkgdir" 2019-07-09 23:16:46 mps: 4981 -> 'accepted' 2019-07-09 23:17:53 mps: 4978 4980 -> 'superseeded' 2019-07-09 23:17:55 ddevault: 4984 -> replaces= and provides= are for py-example and not the actual package 2019-07-09 23:18:20 rest looks OK to me 2019-07-09 23:21:04 tboerger[m]: i'll test build it on aarch64 2019-07-09 23:25:44 that's a bit of a messy apkbuild - remind me, how do i bootstrap it? 2019-07-09 23:33:16 thanks... i never tried to build it on my own. i just came accross that because i wanted to build a multi arch docker image for shellcheck :( 2019-07-09 23:34:14 +1 for getting that working 2019-07-10 02:18:43 maxice8: thanks, I'll have another patch tomorrow 2019-07-10 02:18:45 (es) 2019-07-10 02:19:24 one of these days I'll get better at looking over my commits before sending them 2019-07-10 07:57:51 maxice8: done 4981 4978 4980 2019-07-10 11:38:26 mps: ty 2019-07-10 11:46:12 maxice8: you did a hard part so credit goes to you 2019-07-10 11:48:24 Yes, ty maxice8 and mps 2019-07-10 12:02:57 ok, now i also try to find out how to build ghc-bootstrap. do i really need to call `abuild -R` and compile llvm and all the other deps on my own? :( 2019-07-10 12:03:20 <_ikke_> tboerger[m]: that should not be needed 2019-07-10 12:03:26 <_ikke_> tboerger[m]: your should just be able to do abuild -r 2019-07-10 12:03:51 <_ikke_> tboerger[m]: ghc-bootstrap is just ghc 2019-07-10 12:04:12 but `abuild -r` also won't work because the ghc packages references ghc-bootstrap as a make dep 2019-07-10 12:04:38 that shouldnt 2019-07-10 12:04:44 its a bootstrap dep 2019-07-10 12:04:51 if its in aports it should pick that 2019-07-10 12:05:09 ghc provides ghc-bootstrap 2019-07-10 12:05:19 looks like the ghc APKBUILD is pretty hacky 2019-07-10 12:05:28 <_ikke_> tboerger[m]: It needs to be 2019-07-10 12:05:34 <_ikke_> tboerger[m]: because ghc depends on itself 2019-07-10 12:05:59 tboerger: Yup, it's selfhosted 2019-07-10 12:06:38 what means selfhosted in that case? 2019-07-10 12:07:06 <_ikke_> tboerger[m]: that ghc is built in haskell, which requires ghc 2019-07-10 12:07:41 somebody of the maintainers built ghc-bootstrap manually and put it onto the build servers to get the automatic build of it working? 2019-07-10 12:08:02 self hosted = it compiles itself 2019-07-10 12:08:09 iirc yes 2019-07-10 12:08:24 Yup 2019-07-10 12:08:25 Look at how I recently did it for Rust 2019-07-10 12:09:20 <_ikke_> tboerger[m]: Usually a repo is added that already has ghc 2019-07-10 12:09:35 <_ikke_> ghc provides ghc-bootstrap 2019-07-10 12:09:48 <_ikke_> so if ghc is installed, the ghc-bootstrap dependency is fulfilled 2019-07-10 12:10:05 do you have repo enabled that has it? 2019-07-10 12:10:12 and how does it work for a new architecture? 2019-07-10 12:10:21 you need to bootstrap it 2019-07-10 12:10:23 i want to try to build it for arm and arm64 2019-07-10 12:10:44 <_ikke_> I guess you need to cross-compile first? 2019-07-10 12:10:55 new archs are more difficult 2019-07-10 12:11:05 there is probably a good reason its not available yet. 2019-07-10 12:11:16 you should ask the maintainer 2019-07-10 12:11:23 damn haskell -.- 2019-07-10 12:11:27 before you waste your time on it 2019-07-10 12:11:35 haskell isn't the only self-hosting compiler ;) 2019-07-10 12:12:02 with some language runtimes you can compile a limited bootstrap compiler which in turn can compile the 'real' compiler 2019-07-10 12:12:12 other times you may have to cross-compile 2019-07-10 12:12:21 which is a major pain in the buttocks on alpine 2019-07-10 12:12:28 but it's so far the only thing on alpine i'm using where no arm or arm64 version is available. 2019-07-10 12:12:45 i just want to get shellcheck running on arm/arm64 2019-07-10 12:15:57 rust,, 2019-07-10 12:16:39 it's unfortunately not as easy as just getting shellcheck to work 2019-07-10 12:17:46 sounds like i just got to replace this stupid shellcheck stuff :( 2019-07-10 12:18:12 i'll have a quick look at porting haskell to alpine aarch64 2019-07-10 12:18:15 like i said, try contacting the maintainer 2019-07-10 12:18:20 not sure who it is 2019-07-10 12:18:22 i have $dayjob and N other things to do though 2019-07-10 12:18:34 <_ikke_> You can also check for pre-compiled static binaries 2019-07-10 12:19:32 <_ikke_> koalaman is the shellcheck maintainer 2019-07-10 12:20:17 <_ikke_> There is a armv6ht pre-compiled binary available 2019-07-10 12:20:22 <_ikke_> https://storage.googleapis.com/shellcheck/shellcheck-stable.linux.armv6hf.tar.xz 2019-07-10 12:21:06 they are completely static? 2019-07-10 12:21:15 but no arm64 2019-07-10 12:21:59 looks like there's no aarch64 2019-07-10 12:23:47 https://github.com/koalaman/shellcheck/issues/1569 2019-07-10 12:24:31 so i need to cross compile for arm64 on an amd64 host... 2019-07-10 12:25:22 oh great... haven't been a good idea to restart my scaleway arm server... Error relocating /lib/libcrypto.so.43: getentropy: symbol not found 2019-07-10 12:25:23 * ERROR: sshd failed to start 2019-07-10 12:26:20 ask it in #alpine-linux and i'll help you troubleshoot it 2019-07-10 12:27:06 tboerger[m]: did you upgrade with --available switch? 2019-07-10 12:27:11 first i need to launch a rescue system to get acces to it... i have not set a password and can't login via console :( 2019-07-10 12:27:28 ouch, closing the open ssh session without sshd running is not a good idea 2019-07-10 12:27:31 been there, done that 2019-07-10 12:35:02 i had a look at it, i definitely don't have time to do this today 2019-07-10 13:12:43 i will try the cross compile approach... 2019-07-10 13:12:55 (for my shellcheck use case) 2019-07-10 13:15:42 cross compiling wouldn't be for shellcheck, it would be for haskell, which in turn is used for compiling shellcheck 2019-07-10 13:17:28 yeah was just talking about my current problem :D 2019-07-10 16:34:10 Is utmp/wtmp supported by musl yet? Is there any WIP on this? 2019-07-10 16:36:47 b17wise: you can use utmps pkg 2019-07-10 16:38:45 mps: Ok. So should I disable utmp in busybox build (customized build) and install utmps? 2019-07-10 16:57:44 b17wise: just isntall and set up utmps 2019-07-10 17:51:56 mps/maxice8: sent along a patch which breaks up font-noto-cjk into smaller subpackages (I forgot which of you asked for this) 2019-07-10 17:52:06 https://lists.alpinelinux.org/~alpine/aports/patches/2800 2019-07-10 18:00:40 ddevault: mps I think 2019-07-10 18:00:57 Am driving I'll look later 2019-07-10 18:01:36 <_ikke_> and still on irc? 2019-07-10 18:02:35 hasn't noticed all the pedestrians stuck to the under carriage 2019-07-10 18:02:37 :D 2019-07-10 18:02:46 yo don't IRC and drive 2019-07-10 18:07:28 ddevault: I'm also outside home, will look tomorrow if maxice8 does not in finish it in meantime ;) 2019-07-10 18:07:42 no rush 2019-07-10 18:07:53 I did promise to deal with it on Friday so technically that makes me a liar 2019-07-10 18:08:38 friends from far country arrived to visit 2019-07-10 18:09:02 jwh: I was wondering why they added so many new speed bumps 2019-07-10 18:09:07 lol 2019-07-10 18:14:54 f... yeah! that elixir bug got patched :) 2019-07-10 18:14:59 proper ol' heisenbug 2019-07-10 18:36:36 _ikke_: yes 2019-07-10 18:36:43 ddevault: back, i'll take a look at your noto-cjk-thing 2019-07-10 18:36:53 thanks! 2019-07-10 18:37:37 the patch isn't on patchwork 2019-07-10 18:37:38 someone please guide me, i'm scared and confused 2019-07-10 18:37:54 https://lists.alpinelinux.org/~alpine/aports/patches/2801 2019-07-10 18:38:25 ah nice 2019-07-10 18:40:05 i pushed, it didn't change from PROPOSED to APPROVED (or whatever it should be) 2019-07-10 18:40:35 yeah 2019-07-10 18:40:36 <_ikke_> Does not happen automatically for PW 2019-07-10 18:40:37 that may be an issue 2019-07-10 18:40:55 <_ikke_> ah right 2019-07-10 18:41:02 _ikke_: in the old pw it did 2019-07-10 18:41:06 <_ikke_> it did? 2019-07-10 18:41:11 <_ikke_> o 2019-07-10 18:41:13 <_ikke_> k 2019-07-10 18:41:14 yes 2019-07-10 18:41:53 it was very finnicky, if you rebased or modified something it would not register while GitHub rarely had problems 2019-07-10 18:43:12 <_ikke_> isn't a patch on PW rebased by definition? 2019-07-10 18:44:20 what's going to need to happen is that committers are going to need to be given patch triage permissions on the lists 2019-07-10 18:44:25 <_ikke_> the script for github basically looks for commits with the same author and authordate 2019-07-10 18:44:27 where they can then tick a patch over to approved or whatever 2019-07-10 18:44:38 but this isn't something which is supported yet 2019-07-10 18:44:51 I'll make a note and see about adding that ASAP 2019-07-10 18:45:05 <_ikke_> What be nice if we can automate that (like with github / pw) 2019-07-10 18:45:14 aye 2019-07-10 18:45:18 <_ikke_> ie, if pushed, via a commit hook it will be changed 2019-07-10 18:45:25 that github script can be adapted today, I think 2019-07-10 18:45:40 https://man.sr.ht/lists.sr.ht/api.md 2019-07-10 18:45:51 you can fetch patchsets, the emails therein, and update patch status with the lists.sr.ht API 2019-07-10 18:45:56 where does that script live? 2019-07-10 18:46:04 <_ikke_> on git.alpinelinux.org 2019-07-10 18:47:11 looking for it with limited success 2019-07-10 18:47:31 <_ikke_> I mean on the host itself 2019-07-10 18:47:36 oh 2019-07-10 18:47:41 <_ikke_> not sure if it's in a repo somewhere 2019-07-10 18:47:42 can I get a copy of it? 2019-07-10 18:47:48 <_ikke_> I'm looking for it 2019-07-10 18:47:51 cheers 2019-07-10 18:48:05 <_ikke_> I think the hook itself just pushes things to msg.a.o 2019-07-10 18:48:09 <_ikke_> (a message) 2019-07-10 18:52:02 I'm not familiar with fonts, but shouldn't there be a subpackage containing *.otf files too? 2019-07-10 18:52:39 I don't know why, but none of the distros I looked at used the otf files, and my fonts work fine on those systems 2019-07-10 18:52:48 maybe it's cargo culting but it makes for a smaller package /shrug 2019-07-10 18:54:10 The hard-coded list is a subset, correct? I assume that is where most of the size savings are coming from. 2019-07-10 18:54:24 aye 2019-07-10 19:01:13 <_ikke_> ddevault: source: https://github.com/jirutka/github-pr-closer 2019-07-10 19:01:24 capital 2019-07-10 19:01:55 http://tpaste.us/Bolk 2019-07-10 19:02:35 another issue, tcely, is that the set of otf fonts and the set of ttf fonts does not match up 2019-07-10 19:02:52 more research required 2019-07-10 19:02:59 Hmm. Not having otf seems to be the bigger / easier option. 2019-07-10 19:06:31 _ikke_: doesn't look especially reusable but I can put together something similar 2019-07-10 19:19:13 I wonder if using a keyword for closing wouldn't work better. 2019-07-10 19:22:13 That matching code hasn't been error free. J0WI hasn't had it work most times for some reason. 2019-07-10 19:24:16 <_ikke_> Probably, but it does mean everyone needs to consistently add that tag (automated or not) 2019-07-10 19:43:16 What does the backporting to $latest-stable branch look like? Best effort? Whoever feels like doing the work? Security only? 2019-07-10 19:44:36 <_ikke_> security + bug fixes are generally backported 2019-07-10 19:47:10 okay, I saw the `Updates` column on https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases, but wasn't sure if that was the source of truth, thanks for verifying 2019-07-10 20:52:14 maxice8: I thought a pkgrel bump wasn't needed when moving a package between repos? 2019-07-10 20:52:29 <_ikke_> That's what I understood as well 2019-07-10 20:53:52 PureTryOut: i always thought it was required so people that have the package installed from testing get an upgrade to the package in community 2019-07-10 20:57:10 Do they need an upgrade? 2019-07-10 20:57:28 It's the same build, nothing has changed that requires an update for them 2019-07-10 21:45:41 someone here was asking about maximum package name length, iirc 2019-07-10 21:45:47 fyi it's 40 printable characters 2019-07-10 21:45:55 (it's been a bit, but maybe it's still useful :) ) 2019-07-11 16:32:42 need testers for pr9406 2019-07-11 17:27:21 im about to tag 3.10.1 release now 2019-07-11 18:41:52 where we now send mail patches, to pw.a.o or to sr.ht 2019-07-11 18:44:02 another question, main/u-boot have arch="armhf armv7 aarch64" while the community/uboot-tools have arch="all !s390x !ppc64le" 2019-07-11 18:44:17 shouldn't these be same? 2019-07-11 18:52:49 ncopa: any change for 3.10.1 ? 2019-07-11 18:55:51 ok, no answer, I sent patch for main/u-boot to pw.a.o. lets see what will happen 2019-07-11 18:58:28 we really need CI 2019-07-11 18:59:10 for every arch 2019-07-11 18:59:18 tmhoang: you mean release notes for 3.10.1? 2019-07-11 18:59:50 I mean CI, so developer's commit can be checked without having to be merged to see the build result 2019-07-11 19:00:28 ah, yes. 2019-07-11 19:00:40 regarding 3.10.1 ? ah right I'm curious what's significant change from 3.10.0 2019-07-11 19:00:48 something like drones 2019-07-11 19:00:59 didn't keep track for the last month ... 2019-07-11 19:01:09 tmhoang: release notes are on the main site 2019-07-11 19:01:18 thought with gitlab we can have remote slaves ? 2019-07-11 19:01:51 drones host everything in their infra afaik 2019-07-11 19:01:53 gitlab have CI but not sure if for all alpine arch's 2019-07-11 19:03:41 afaik gitlab allows remote slave/builder 2019-07-11 19:03:59 so should be doable to have remote slave for all arch 2019-07-11 19:04:04 so, no, can't send patch to pw.a.o 'host smtp.alpinelinux.org[147.75.101.119] said: 451 4.7.1 Try again later (in reply to end of DATA command)' 2019-07-11 19:04:16 after all that's one of the benefit of gitlab iirc 2019-07-11 19:04:34 to me drones looks really nice 2019-07-11 19:35:06 ncopa; when you enable context + coroutine1,2 in boost on s390x, was there any app depends on those features ? afaik, context support is still being worked on https://github.com/boostorg/build/issues/411 2019-07-11 19:35:17 https://bugs.launchpad.net/ubuntu/+source/boost/+bug/1694926 2019-07-11 19:35:38 I would like to revert to disable them 2019-07-11 19:35:53 pdns-recursor seems to be looking for context functions 2019-07-11 19:36:10 and it fails now 2019-07-11 20:10:30 I can't participate in the alpine mailing lists because of the HTML requirement. My mail client doesn't let me send things in plain text only. What should I do? 2019-07-11 20:12:09 what client do you use? 2019-07-11 20:12:35 Cadey: sounds like you'll be unable to send emails to the list, unfortunately 2019-07-11 20:13:10 ddevault: spark mail for iOS, it has no settings to toggle plain text only 2019-07-11 20:13:26 yeah, you'll have to use another client, and I suggest writing to the maintainers of that client asking for a plaintext option 2019-07-11 20:14:20 it's not even possible to change fonts in that client fyi 2019-07-11 20:19:58 i guess i just won't participate in the mailing list then 2019-07-11 20:20:02 sorry for the bother 2019-07-11 22:42:35 ddevault: patches to the https://lists.alpinelinux.org/~alpine/aports/patches/ have any form of CI ? 2019-07-11 22:42:45 no, but it will soon 2019-07-11 22:43:07 ok, thanks 2019-07-11 22:43:18 hopefully soon enough :D just met a massive patch for updating plasma 2019-07-11 22:44:07 we can do a little CI ad-hoc if you'd like 2019-07-11 22:45:06 I'll do a yolo push and fix as they fail, also registration on meta.a.o.org is intended ? 2019-07-11 22:45:28 let me take a crack at CI'ing this 2019-07-11 22:45:40 too late 2019-07-11 22:45:42 and yeah, registration is closed deliberately, but I can get youa n invite 2019-07-11 22:45:44 you an* 2019-07-11 22:48:41 so, patchwork.a.o is retired now? 2019-07-11 22:49:12 that wasn't discussed 2019-07-11 22:49:25 well new patches didn't appear there 2019-07-11 22:49:27 lists.a.o does offers something similar now 2019-07-11 22:49:31 s/offers/offer/ 2019-07-11 22:49:31 ddevault meant to say: lists.a.o does offer something similar now 2019-07-11 22:49:59 I don't have access to the patchwork server so there isn't much I can do about it 2019-07-11 22:50:29 I see my patch posted to pw.a.o on https://lists.alpinelinux.org/~alpine/aports 2019-07-11 22:51:15 but not on pw.a.o 2019-07-11 22:54:10 maxice8: I see you pushed one patch from https://lists.alpinelinux.org/~alpine/aports/patches/2805 2019-07-11 22:54:30 yes 2019-07-11 22:55:06 how did you do this? download raw and 'git am'? 2019-07-11 22:55:55 click "how do I use this" and it has a pastable curl command 2019-07-11 22:56:20 ddevault: I've seen it 2019-07-11 22:56:25 http://ix.io/1OcP 2019-07-11 22:57:10 small script i use i just scroll around the patches and put pw $num 2019-07-11 22:57:12 ah, I see. thanks both for info 2019-07-11 22:58:00 (big changes when I'm on vacation) 2019-07-11 23:25:16 on the subject of CI 2019-07-11 23:25:24 i'm all ears 2019-07-11 23:25:33 rigged this up to pull that plasma patch off of the ML and build it: https://builds.sr.ht/~sircmpwn/job/75025 2019-07-11 23:25:35 based on the travis stuff 2019-07-11 23:25:43 https://builds.sr.ht/api/jobs/75025/manifest 2019-07-11 23:26:01 little hacky but mainly because it's adapting a script designed for travis 2019-07-11 23:52:20 ddevault: How is automatically changing PROPOSED patches to ACCEPTED when they pushed are going to work ? 2019-07-11 23:52:33 magic 2019-07-11 23:52:35 (I'm busy) 2019-07-12 00:23:05 Alpine Linux now using sourcehut was a good reason for me to finally start figuring out how `git send-email` works. I'm loving it so far! https://git-send-email.io is definitely a big help 2019-07-12 00:27:38 excellent :) 2019-07-12 00:28:06 maxice8: the answer boils down to checking the commit author date against the dates on the ml 2019-07-12 00:28:26 should work even if the commit is amended or endures a certain amount of rebasing 2019-07-12 00:30:20 Nice, thanks for the answer. 2019-07-12 06:28:02 ncopa: Why did you change #10591 from resolved to closed? I thought resolved == closed and no follow up questions 2019-07-12 06:29:02 PureTryOut: Oh.. Alpine moved to sourcehut? Umm... I already use sourcehut 2019-07-12 06:40:50 i was not aware we've moved to sourcehut 2019-07-12 06:41:03 as far as i know, we're moving to our own gitlab instance 2019-07-12 06:45:21 <_ikke_> danieli: the mailing list is using sourcehut 2019-07-12 06:45:40 I think the mailing list has been moved to sourcehut 2019-07-12 06:45:56 isn't it using just two self-hosted component of sourcehut? 2019-07-12 06:47:14 <_ikke_> yes, the mailing list part of sourcehut 2019-07-12 06:50:34 right, i was just making a distinction between the sourcehut service (as in sr.ht) and the software it runs 2019-07-12 12:59:57 PureTryOut[m]: I have been using git send-mail since the beginning with lists.a.o 2019-07-12 13:45:11 PureTryOut[m]: 'upgrade to' not 'update to' is prefered commit message in aports 2019-07-12 14:53:45 Oh ok will change next time 2019-07-12 14:58:51 thank you (heartily) 2019-07-12 17:28:19 Lots of PRs for stuff in main/ are rotting away D: 2019-07-12 17:28:41 <_ikke_> I'll try to take a look at them 2019-07-12 17:28:56 <_ikke_> Just came back from holiday 2019-07-12 17:29:02 _ikke_: Thank you :D 2019-07-12 17:29:24 Hope it was fun 2019-07-12 17:29:29 <_ikke_> it certainly was 2019-07-12 19:15:59 Is there a reason registrations at https://lists.alpinelinux.org are closed? 2019-07-12 19:19:04 its only needed for admins atm 2019-07-12 19:36:51 Hmm ok. 2019-07-12 19:37:31 A bit annoying that I don't get an email for review comments on a patch of mine. I had to manually check the web interface. Also, I can't reply to it because of this and the closed registration 2019-07-12 19:48:48 user registration has been disabled on redmine 2019-07-12 19:49:12 we are doing last minute checks before switching 2019-07-12 19:51:01 please do not create any issues on redmine. 2019-07-12 19:52:51 Switching to what if I may ask? 2019-07-12 19:53:20 <_ikke_> gitlab 2019-07-12 19:53:38 <_ikke_> Which has been in the works for some time already 2019-07-12 19:53:53 Ah nice! 2019-07-12 20:18:06 Interesting to have issues on Gitlab and mailing lists on sr.ht tbh. Any resaon for not using sr.ht's todo service? 2019-07-12 20:18:13 https://todo.sr.ht/ 2019-07-13 02:51:38 PureTryOut[m] : subscribing to mail lists is enough I guess, I don't have to create an account at sr.ht to get emails 2019-07-13 02:52:11 the mailing lists @ lists.a.o is not a part of sr.ht 2019-07-13 02:52:15 it's just using the same software as it 2019-07-13 07:08:49 tmhoang: I don't really want to subscribe to the aports mailing list, as I'd get lots of mails about patches I don't really care about 2019-07-13 08:57:55 How do you properly check which packages need a rebuild and thus a pkgrel bump after a library has been updated? 2019-07-13 09:08:44 PureTryOut[m] : some grep for main,community,testing/*/APKBUILD 2019-07-13 09:09:17 check for runtime dependencies only, I think makedepend dont really need 2019-07-13 09:09:38 git log might have many examples 2019-07-13 09:11:09 tmhoang: Eh? I think you mean the the other way around, runtime deps don't link to the lib and as such don't need to be bumped 2019-07-13 09:11:37 PureTryOut: Search for everything which depends on so: 2019-07-13 09:16:05 Thanks will do 2019-07-13 09:17:27 rebuidl is not needed if there are no api/abi changes in libs 2019-07-13 09:19:11 Just asking, do you guys share work with the project "sabotage linux" ? 2019-07-13 09:25:26 sabotage linux is also musl based linux distro 2019-07-13 10:02:51 i do not know of any cooperation with sabotage linux 2019-07-13 10:02:57 not anything official or noticeable (to me) anyway 2019-07-13 10:04:50 Neither do I, but I guess musl related patches might be shared between us sometimes? 2019-07-13 10:05:03 Dunno, I haven't looked at Sabotage yet 2019-07-13 10:05:25 borrowing patches and stuff like that happens on occasion, but it mostly happens with arch and void afaik 2019-07-13 10:05:44 Arch? :o 2019-07-13 10:06:08 I mean I understand Void for musl, but I haven't seen an occasion where we share smth with Arch 2019-07-13 10:06:18 (Actually, maybe with alarm?) 2019-07-13 10:06:55 arch has a similar build system with their PKGBUILDs 2019-07-13 10:06:56 er 2019-07-13 10:07:15 we sometimes borrow from their pkgbuilds, not their non-existent musl patches 2019-07-13 10:07:44 Ah, alright 2019-07-13 10:08:32 Neat.. 2019-07-13 10:17:01 To be honest, I don't see how we should collaborate more than by sharing some patches 2019-07-13 10:22:38 same 2019-07-13 10:23:24 its opensource, we borrow (check) each others stuff all the time. 2019-07-13 10:24:59 we also co-op regarding reproducible builds. 2019-07-13 10:25:13 but not with sabotage afaik 2019-07-13 10:28:29 Ah, yes, it's more of a common goal than a cooperation I guess 2019-07-13 13:10:56 Cogitri: Yeah. I mean sharing patches is enough.. 2019-07-13 18:43:56 PureTryOut: purpose is failing to build 2019-07-13 18:44:54 Ah shit. Don't have access to pc atm. Got a buid log? 2019-07-13 18:45:04 alpine-commits has URL with logs 2019-07-13 18:45:22 kirigmami2-dev is missing from depends 2019-07-13 18:45:40 Oh new dep which I missed then, easy enough to fix 2019-07-13 18:48:55 i'll add it and work from there 2019-07-13 18:51:13 Thanks 2019-07-13 19:12:48 Once I have the PinePhone ready as a daily driver, I'll setup a dev environment on my phone ;) 2019-07-13 19:15:13 kdewebkit was downgraded to PortingAids and so had an invalid source= 2019-07-13 19:18:37 Oh obviously 2019-07-13 19:18:43 I saw that in changelogs 2019-07-13 19:19:04 Completely forgot the fact that the url wouldn't work anymore 2019-07-13 21:19:51 https://gitlab.alpinelinux.org/alpine/aports/issues/10230 can be closed 2019-07-14 17:41:00 Cogitri: https://github.com/alpinelinux/aports/commit/69851bdae1177246337f51a35734e93f1fd7e3d3#r34296989 2019-07-14 17:41:24 nice! 2019-07-14 18:15:03 tcely: He is on vacation 2019-07-14 18:59:59 maxice8: thanks. There was no rush. 2019-07-14 19:00:44 pr9445 could use a review if anyone is around 2019-07-14 19:02:49 There are others too: https://github.com/alpinelinux/aports/labels/S-needs-review 2019-07-14 23:31:37 tcely: Thanks for the ping 2019-07-14 23:46:51 We had mingw-w64 previously ? 2019-07-15 00:04:02 https://gitlab.alpinelinux.org/alpine/aports/issues/8971 2019-07-15 05:57:10 good morning 2019-07-15 05:58:04 ncopa: Good morning 2019-07-15 07:34:00 'go' throws a missing 'cgo' message. 2019-07-15 08:38:07 b17wise: try CGO_ENABLED=0 go ... 2019-07-15 08:38:43 okay... 2019-07-15 09:44:41 Can pr9384 be committed? I will prepare a backport to 3.10 after that. 2019-07-15 14:37:53 opinons on https://gitlab.alpinelinux.org/alpine/aports/issues/5558 ? 2019-07-15 14:41:29 sounds like a good idea to me 2019-07-15 14:44:06 we normally dont do that 2019-07-15 14:44:48 the thinking is that during build time you will normally need compiler and lots of other stuff anyway 2019-07-15 14:45:04 and i am afraid it will require some work to maintain a splitted boost-dev 2019-07-15 14:45:58 but if its easy to split and does not require any work to deal with dependenceis etc, then sure 2019-07-15 15:24:24 it will most certainly require a lot of work to create each _dev function 2019-07-15 15:24:28 i'll keep it open 2019-07-15 15:41:33 The interdependence of boost-*-dev subpackages will be a nightmare 2019-07-15 16:19:54 tcely: i agree, Void also has a single -dev 2019-07-15 16:57:14 hello 2019-07-15 16:57:20 good day folks! 2019-07-15 16:59:03 can someone guide me on where to begin if I have to make the entire alpine os with ulibc or glibc instead of muslc? should I start with abuild? 2019-07-15 16:59:10 and build rest of the components? 2019-07-15 16:59:29 and build rest of the components using that abuild version? 2019-07-15 17:06:02 basically "just" edit apkbuild files and switch musl -> your libc 2019-07-15 17:06:53 but abuild itself is built against muslc? 2019-07-15 17:07:24 so should i rebuild abuild and then make changes to apkbuild files and then build? 2019-07-15 17:09:09 what would be the reason to do that? 2019-07-15 17:09:34 will i have any dependency issues? 2019-07-15 17:09:36 LFS is good read if you want to have system of your choise 2019-07-15 17:10:01 you need to edit many files at least 2019-07-15 17:11:33 i love alpine ...just trying to understand what happens beneath...yeaa saw it that musl is required by atleast 5468 packages 2019-07-15 17:11:34 https://pkgs.alpinelinux.org/package/edge/main/x86_64/musl 2019-07-15 17:11:51 so what you say is true...need to edit many files 2019-07-15 17:13:07 that's why Linux From Scratch might be good to learn 2019-07-15 17:14:22 oneinsect: You wont able to use prebuild packages with other nin comlatible libc. Other then that, Alpine Linux is just regulat distro. libc is the core, you build entire distro after building the libc first. Before that, everything happens inside external bootstraped env 2019-07-15 17:14:41 non compatible* 2019-07-15 17:15:03 aha 2019-07-15 17:15:14 so i have to build say glibc first 2019-07-15 17:15:17 ACTION maintains an own CLFS 2019-07-15 17:15:38 as said, there is good documentation for (C)LFS 2019-07-15 17:16:22 hmmmm 2019-07-15 17:16:55 oneinsect: It is not hard, but time consuming work 2019-07-15 17:17:30 i want to do it....build glibc and then build alpine over it from source 2019-07-15 17:17:53 oneinsect: Read CLFS and do so 2019-07-15 17:18:12 I did so.. took a month 2019-07-15 17:18:30 ummmmm 2019-07-15 17:18:53 <_ikke_> You might also need to remove some patches that are added in aports to make things work for musl 2019-07-15 17:19:16 ACTION encourage oneinsect to hack so. It is fun 2019-07-15 17:19:40 correct i will remove patches that were added 2019-07-15 17:19:44 and i was looking at 2019-07-15 17:19:45 https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh 2019-07-15 17:19:58 meanwhile i will check http://clfs.org/view/clfs-embedded/x86/ 2019-07-15 17:21:18 oneinsect: Easiest would be follow CLFS... and then port/compile abuild to glibc. Then you should be good to go 2019-07-15 17:21:44 s/to/against 2019-07-15 17:21:44 b17wise meant to say: oneinsect: Easiest would be follow CLFS... and then port/compile abuild against glibc. Then you should be good to go 2019-07-15 17:22:43 i can quickly setup debian and a chroot and then install glibc and compile abuild 2019-07-15 17:22:59 i wrote this guide...ported alpine to a couple of arm boards 2019-07-15 17:22:59 https://wiki.alpinelinux.org/wiki/DIY_Fully_working_Alpine_Linux_for_Allwinner_and_Other_ARM_SOCs 2019-07-15 17:23:45 <_ikke_> I'm not sure why you are refering to cross-compiling though\ 2019-07-15 17:23:46 wouldnt that be easy ? 2019-07-15 17:23:57 sorry 2019-07-15 17:24:09 let me leave cross compiling out of the picture 2019-07-15 17:24:17 its for an x64 build 2019-07-15 17:24:30 alpine os but working fully against glibc including busybox 2019-07-15 17:24:39 including all packages 2019-07-15 17:25:01 <_ikke_> then start with an existing installation where you build glibc first 2019-07-15 17:25:43 _ikke_ let me fireway my debian 10 then 2019-07-15 17:25:48 :-D 2019-07-15 17:26:00 <_ikke_> I would use an alpine installation 2019-07-15 17:26:05 oooh 2019-07-15 17:26:16 i have alpine 2019-07-15 17:26:19 installed 2019-07-15 17:26:21 <_ikke_> or at least an alpine chroot 2019-07-15 17:26:26 having abuild stuff is neat 2019-07-15 17:26:32 oneinsect: You can actually use alpine itself to build a glibc iso 2019-07-15 17:27:20 i can avoid mkinitfs and use my script to build glibc build iso 2019-07-15 17:28:32 thanks b17wise artok and _ikke_ 2019-07-15 17:28:40 i will begin it now 2019-07-15 17:28:54 i will buzz if i am struck ...please help if you have time 2019-07-15 17:29:37 oneinsect: Sure 2019-07-15 17:33:41 over 200 PRs lot of stuff for main/ 2019-07-15 17:34:58 <_ikke_> maxice8: I have some time now, will look at the PRs for main 2019-07-15 17:37:25 _ikke_: thanks :D 2019-07-15 17:54:09 can anyone tell me what is the use of this static version of apk tools? 2019-07-15 17:54:10 https://pkgs.alpinelinux.org/package/edge/main/x86/apk-tools-static 2019-07-15 17:54:39 <_ikke_> maxice8: any specific reason you implemented the static function here yourself? https://github.com/alpinelinux/aports/pull/9415/files 2019-07-15 17:55:27 <_ikke_> oneinsect: It can be used even if your entire system is borked 2019-07-15 17:55:44 aha 2019-07-15 17:56:23 <_ikke_> same for busybox-static 2019-07-15 17:56:31 _ikke_: No 2019-07-15 17:56:50 <_ikke_> ok, because https://git.alpinelinux.org/abuild/tree/abuild.in#n1748 2019-07-15 17:56:55 Could anyone review? https://github.com/alpinelinux/aports/pull/9290 2019-07-15 18:00:06 some lines are hard coded to musl in abuild 2019-07-15 18:00:07 https://git.alpinelinux.org/abuild/tree/abuild.in#n580 2019-07-15 18:01:21 have to see how they work in glibc...need to make some changes 2019-07-15 18:02:09 what exactly does update_config_sub() function do in abuild.in? in pain english? 2019-07-15 18:02:17 <_ikke_> That would only do something for packages which call this function, and then still I think it should be harmless 2019-07-15 18:02:27 ummmm 2019-07-15 18:02:35 <_ikke_> oneinsect: It's a helper function that some packages call to update a projects config.sub 2019-07-15 18:02:55 <_ikke_> same for the config_guess function 2019-07-15 18:03:20 thanks 2019-07-15 18:03:42 <_ikke_> So unless you found it actually prevents a project from building, I would ignore it 2019-07-15 18:04:04 yup 2019-07-15 18:04:43 Also could someone review https://github.com/alpinelinux/aports/pull/9319? 2019-07-15 18:07:10 I've just send a patch to lists.alpinelinux.org with an extra receiver in the CC. However, this patch doesn't seem to be received... https://lists.alpinelinux.org/~alpine/aports?search=from%3ABart+Ribbers doesn't show it 2019-07-15 18:07:20 Oh never mind, it was just a bit slow 2019-07-15 18:07:52 <_ikke_> PureTryOut[m]: Are you receiving notifications already? I think ddevault changed something to improve deliverability 2019-07-15 18:08:19 I have yet to receive a comment on a patch of mine since I last complained about it 2019-07-15 18:08:26 <_ikke_> hmm 2019-07-15 18:08:38 <_ikke_> I did see e-mails being sent to you in the postfix logs 2019-07-15 18:10:45 In that case I have yet to receive an email 2019-07-15 18:10:52 I don't have anything in spam either 2019-07-15 18:11:21 <_ikke_> Jul 15 00:15:32 smtp mail.info postfix/smtp[11033]: A6B5C782C76 2019-07-15 18:11:28 <_ikke_> This was sent to you 2019-07-15 18:11:55 <_ikke_> Jul 14 18:56:31 smtp mail.info postfix/smtp[9187]: 46AE6782C17 2019-07-15 18:12:08 <_ikke_> Are you able to verify you received these? 2019-07-15 18:12:29 <_ikke_> (time is UTC) 2019-07-15 18:17:07 I'm not sure how to determine what emails those are from that info 2019-07-15 18:17:40 But 15th of July, and I have yet to receive any mail from lists.alpinelinux.org 2019-07-15 18:18:28 <_ikke_> message-id=<20190714194503.77421AEE752@mail.distrito09d20.saludzona5.gob.ec 2019-07-15 18:18:51 <_ikke_> to sender is alpine-infra@a.po 2019-07-15 18:19:05 <_ikke_> s/a\.po/a.o 2019-07-15 18:22:07 _ikke_: ill fix libpciaccess after I finish driving 2019-07-15 18:22:12 <_ikke_> maxice8: su 2019-07-15 18:22:14 <_ikke_> sure 2019-07-15 18:22:23 <_ikke_> maxice8: I added a note as a reminder 2019-07-15 18:22:27 Do I have to subscribe to that email list or something? 2019-07-15 18:22:39 <_ikke_> No, you should just receive it 2019-07-15 18:22:45 <_ikke_> they are system notifications 2019-07-15 18:23:12 Well, I'm not receiving them then 😛 2019-07-15 18:23:28 <_ikke_> any way to verify your mail logs? 2019-07-15 18:23:46 Besides checking my mail box? Not that I know off 2019-07-15 18:23:49 <_ikke_> ok 2019-07-15 18:25:42 <_ikke_> and it should be sent to disroot.org? 2019-07-15 18:27:17 <_ikke_> ok, I see something 2019-07-15 18:27:27 <_ikke_> milter-reject: END-OF-MESSAGE from knopi.disroot.org[178.21.23.139]: 4.7.1 Try again later 2019-07-15 18:27:34 Yes it should 2019-07-15 18:28:44 It doesn't say why it's rejected? 2019-07-15 18:28:56 <_ikke_> no 2019-07-15 18:31:03 Well that's useful... 2019-07-15 18:31:25 I'll ask my email host to check 2019-07-15 18:31:33 <_ikke_> What I find online it seems to be some issue on the receiving side 2019-07-15 18:31:37 <_ikke_> (dkim related) 2019-07-15 18:32:13 may not be dkim related 2019-07-15 18:32:17 milters can do any number of things 2019-07-15 18:32:37 <_ikke_> ah ok 2019-07-15 18:32:44 milter -> mail filter 2019-07-15 18:32:49 <_ikke_> right 2019-07-15 18:33:40 So it's still an issue on the sender side? 2019-07-15 18:33:46 <_ikke_> receiver 2019-07-15 18:34:03 PureTryOut[m]: you wouldn't happen to be subscribed to any lists on lists.sr.ht upstream, would you? 2019-07-15 18:34:16 woops that is what I meant 2019-07-15 18:35:06 Not to any sr.ht list no 2019-07-15 18:35:15 okay 2019-07-15 18:35:45 I don't mind subscribing to one for a bit if that helps figuring out this issue though 2019-07-15 18:36:52 ~sircmpwn/sr.ht-announce+subscribe@lists.sr.ht 2019-07-15 18:45:13 I think I just subscribed to it? I just have to send it an email with any content in it right? 2019-07-15 18:45:46 yeah 2019-07-15 18:45:48 did you get a reply? 2019-07-15 18:45:50 confirmation* 2019-07-15 18:47:20 Nope 2019-07-15 18:47:24 Oh actually now I have 2019-07-15 18:48:34 coolio 2019-07-15 18:48:36 thanks 2019-07-15 18:48:54 you can send a similar email to +unsubscribe if you don't want to get the email I'm going to send to it today 2019-07-15 18:50:18 Yeah I read the confirmation mail 😉 2019-07-15 18:51:43 So does this mean there are some setting differences between lists.sr.ht and lists.alpinelinux.org which you've just found out or something? 2019-07-15 18:54:09 it tells us the problem lies in alpine's mail configuration, not in lists.sr.ht, yes 2019-07-15 18:55:16 <_ikke_> PureTryOut[m]: It appears our rspamd is graylisting mails from listserv 2019-07-15 18:55:32 Ah cool 2019-07-15 18:56:12 <_ikke_> I'm just trying to figure out how to configure rspamd to whitelist listserv 2019-07-15 18:56:24 I'd just route the mail around it in postfix 2019-07-15 18:56:46 it's pretty weird to run outgoing mail through rspamd at all 2019-07-15 18:58:06 <_ikke_> What I see is that in postfix, smtpd_milters is set 2019-07-15 18:58:53 <_ikke_> ok, I can disable it for certain clients 2019-07-15 18:59:13 <_ikke_> http://www.postfix.org/MILTER_README.html#per-client 2019-07-15 19:06:19 PureTryOut[m]: can you join #alpine-infra? 2019-07-15 19:19:29 maxice8: why the redundant comment on pr9408 ? 2019-07-15 19:20:30 Because the old url redirects to https://gitlab.alpinelinux.org/ 2019-07-15 19:20:57 <_ikke_> I want to create a rewrite script to redirect to the new issue url 2019-07-15 19:21:30 Ok. I'll clean that up then. 2019-07-15 19:35:32 Still up https://gitlab.alpinelinux.org/alpine/aports/issues/7984 2019-07-15 22:15:53 Holy shit that's a quick merge maxice8, thanks! 2019-07-15 22:16:48 PureTryOut: don't need to wait for CI to be green 2019-07-15 22:20:17 Interesting 2019-07-16 06:50:09 pr7555 looks like an easy merge 2019-07-16 08:38:57 Someone that actually knows about handling different branches please take a look at pr9484 and pr9485 just to check that i'm not doing anything wrong 2019-07-16 09:14:53 should be right. but why not using gitlab ? 2019-07-16 09:16:18 <_ikke_> tmhoang: we don't use gitlab for merge requests just yet 2019-07-16 09:27:51 `fftw` in main doesn't have a maintainer https://git.alpinelinux.org/aports/tree/main/fftw/APKBUILD 2019-07-16 09:29:27 <_ikke_> It used to be maintained by kaniini, but he gave up maintainership of all his packages, no one took it over in the mean time apparently 2019-07-16 09:30:13 It might not be much of a problem in testing, but it seems quite dangerous for stuff in main 2019-07-16 09:49:15 tmhoang: Don't think we fully moved to gitlab 2019-07-16 09:52:59 <_ikke_> correct 2019-07-16 09:53:12 <_ikke_> Major roadblock afaik is CI 2019-07-16 10:05:12 pushed 2019-07-16 10:05:15 :D worse than i thought 2019-07-16 10:05:25 also github bot is easily tricked 2019-07-16 10:05:34 https://github.com/alpinelinux/aports/pull/9485 <- was closed but i pushed the 3.9 one, not the 3.10 one 2019-07-16 10:09:46 https://cloud.drone.io/alpinelinux/aports/8561/2/1 anyone has any idea of why that error happens ? only in 3.10 (no 3.9 or edge) 2019-07-16 10:27:39 <_ikke_> cannot find / open input.s8/u8? 2019-07-16 10:28:04 _ikke_ : is CI the roadblock for fully functional gitlab (i.e. merge PR, etc.) ? 2019-07-16 10:28:21 <_ikke_> At least one of them 2019-07-16 10:28:23 <_ikke_> yes 2019-07-16 10:29:50 <_ikke_> We also need to fix the sync between git.a.o and gitlab.a.o 2019-07-16 10:33:57 _ikke_: yes, no clue why that happens 2019-07-16 10:38:07 <_ikke_> Me neither 2019-07-16 14:24:33 PureTryOut: I wouldn't mind taking over maintainership if no one steps up 2019-07-16 14:34:14 maxice8: it happens because the github PR script does not check which branch it is 2019-07-16 14:34:26 it only compars commit date and author iirc 2019-07-16 14:34:36 when you cherry-pick those will be identical 2019-07-16 14:42:18 I think I'm going to drop python2 from testing tomorrow 2019-07-16 14:46:44 awesome 2019-07-16 14:46:57 <_ikke_> redo is in community and sadly still requires python2 2019-07-16 14:54:17 how should duplicate issues be handeled in the gitlab bugtracker. should they be closed? 2019-07-16 14:54:30 _ikke_: I'm going to make a list of packages which require special discussion 2019-07-16 14:54:56 python2 is EoL in less than 6 months and any packages which don't have a clear path towards python 3 support should be dropped imo 2019-07-16 14:55:06 nmeum: Yup, close and refer to the original issue 2019-07-16 15:15:13 Awesome! 2019-07-16 17:13:23 Yo lxd is failing to build 2019-07-16 17:13:38 why? 2019-07-16 17:13:45 got ci log? 2019-07-16 17:14:16 lulz *buntu 2019-07-16 17:24:49 jwh: see alpine-commits 2019-07-16 17:25:00 I'm not subbed 2019-07-16 17:25:14 whats going on with the lists, are they still archived somewhere? 2019-07-16 17:37:02 _ikke_: she 2019-07-16 19:40:22 curious 2019-07-16 19:40:26 how do you people backport stuff between branches ? 2019-07-16 19:41:59 softly 2019-07-16 19:47:51 maxice8: is the lxd issue to do with raft? 2019-07-16 19:48:01 if so, yeah, I think they broke it 2019-07-16 19:49:00 can someone add ci-malfunction to pr4941 and pr4942 , travis-ci doesn't like ftp:// source, also they are security backports for 3.8 and 3.9 if anyone feels like pushing them :D 2019-07-16 19:49:14 jwh: no the lxd issue was that it was pushed without regenerating the checksums for a new file that was added. 2019-07-16 19:49:19 o 2019-07-16 19:49:27 lol 2019-07-16 19:49:50 oops, pr9491 and pr9492 2019-07-16 19:51:58 just kicked off a build, no checksum mismatch 2019-07-16 19:52:01 fixed already? 2019-07-16 19:52:16 jwh: yes, it was fixed 2019-07-16 19:52:27 ah cool ok 2019-07-16 20:47:22 maxice8: thank you for merging all my patches so quickly, it's a joy to work like this 2019-07-16 20:47:36 welcome 2019-07-16 20:48:45 PureTryOut[m]: Yeh... it feels good when we get responses to patches in quick :) 2019-07-16 20:49:57 <_ikke_> kaniini: sorry 2019-07-16 20:56:41 <_ikke_> maxice8: what is your question regarding backporting? 2019-07-16 21:19:26 _ikke_: how do devs do it ? 2019-07-16 21:28:11 <_ikke_> I don't know how everyone does it, but it's either cherry-picking an existing commit, but it might also require custom changes per branch (ie, different versions to update) 2019-07-16 21:28:22 <_ikke_> or backporting patches if upstream doesn't do it 2019-07-16 21:29:26 <_ikke_> maxice8: in any case, it involves pushing a commit for each branch 2019-07-16 21:31:38 Alright 2019-07-16 22:57:22 _ikke_: I have a basic idea of backporting i just want to know how different devs do it because i want to make the most efficient workflow 2019-07-17 00:18:28 hey can someone help me with my apkbuild 2019-07-17 00:18:30 http://sprunge.us/Du4E2X 2019-07-17 00:19:15 i got it to build-ish using go modules, sadly the project (new kiwiirc websocket thingy) hasn't cut a release 2019-07-17 00:20:00 and all of the git repos it checks out are -r for my user so abuild clean fails 2019-07-17 00:40:35 pr8550 should be a quick merge 2019-07-17 00:42:47 spatulaslap: making a draft pull request on GitHub is a good way to get help 2019-07-17 00:44:37 You may need something like: https://github.com/alpinelinux/aports/blob/0d5fbe25a57c9390258ea0365c6e211ea97b521e/testing/rclone/APKBUILD#L33 2019-07-17 04:30:52 <_ikke_> maxice8: understood. 2019-07-17 08:13:46 Hey, is there a keyword that can be put on commits to close GitLab issues or is it a work in progress ? 2019-07-17 08:14:25 I think just `closes #issuenum` or `fixes` should work 2019-07-17 08:18:24 we have done "fixes #issuenum" in the past, and i would like that to continue work 2019-07-17 08:18:31 and i think it does work 2019-07-17 08:18:33 It does 2019-07-17 08:18:39 thanks 2019-07-17 08:39:27 I wonder if we can use tasklists in gitlab to track wich branches is affected and should be fixed 2019-07-17 08:39:32 for example: https://gitlab.alpinelinux.org/alpine/aports/issues/10662 2019-07-17 08:39:39 i added the "Affected branches" 2019-07-17 08:40:32 i wonder if we could have a bot that would hook of the listed branch when a commit with commit message "fixes #issuenum" is pushed to that branch 2019-07-17 08:41:01 i also wonder if we should add tags for each branch 2019-07-17 08:41:29 and we should start move away from the tags that comes from redmine, "New" "Resolved" etc 2019-07-17 08:41:35 I guess we could do that like we do with GH right now? 2019-07-17 08:42:11 how do we do with GH? 2019-07-17 08:42:31 the idea is to avoid copy the same issue multiple times 2019-07-17 08:42:47 ncopa: branch tags sound like a good idea, also +1 on moving away from the redmine labels 2019-07-17 08:44:30 Ncopa: https://github.com/alpinelinux/aports/projects/1 2019-07-17 08:44:57 We'd just need a project for branches other than edge then 2019-07-17 08:50:17 would be nice with labels similar to the GH ones 2019-07-17 08:50:33 not sure how has bee working on those 2019-07-17 08:50:38 Yup 2019-07-17 08:51:13 *who has been working on those 2019-07-17 08:51:36 tcely i think 2019-07-17 08:52:11 there is a "2 taks of 2 completed" in this #10662 2019-07-17 08:55:38 #10662 2019-07-17 08:56:22 #10662 2019-07-17 09:14:02 mranweil: hi! can you please join #alpine-infra so we can talk about the power9 machine? 2019-07-17 09:26:43 is GitHub login for GitLab going to work? 2019-07-17 09:27:05 <_ikke_> We still need to make that happen 2019-07-17 09:27:13 <_ikke_> It should be possible 2019-07-17 09:48:17 Has anyone gotten GPG keys upload to work in GitLab? 2019-07-17 09:48:46 i did 2019-07-17 09:48:52 i mean its uploaded 2019-07-17 09:48:53 It says my block is invalid, which is nonsense. 2019-07-17 09:49:26 i didnt check if it actually works 2019-07-17 09:49:37 Did you use the same command GL tells you to execute? 2019-07-17 09:49:39 Pretty sure it worked for me, let me check 2019-07-17 09:52:26 Cogitri: I used the pub key exported from my HW device. I can give you a link, but it works everywhere else. 2019-07-17 09:53:53 Just added a key, works just fine with `gpg --armor --export ` 2019-07-17 09:54:35 Oh, I think it wants a single block. Sigh. That error message is completely unhelpful. 2019-07-17 09:57:16 if you find issues and want to test, its pretty simple to make gitlab run local in docker. should just take a few minutes. 2019-07-17 10:10:30 clandmeter: how do I verify an email that doesn't accept mail? 2019-07-17 10:11:12 All I care about is nappi 2019-07-17 10:11:31 All I care about is mapping commits 2019-07-17 10:12:08 tcely@users.noreply.github.com 2019-07-17 10:14:51 ncopa: how does not always hang? while(1) must have some break correct? 2019-07-17 10:15:36 ^ for vtgen patch you just pushed 2019-07-17 10:16:23 Use the gitlab provided no reply email for that 2019-07-17 10:17:04 Cogitri: hard to rewrite git history for that now 2019-07-17 10:17:45 Yup, works for following commits tho 2019-07-17 10:18:29 Not for any definition of works that I'll accept 2019-07-17 10:20:12 Split commit history / signatures, rewrite repos, toggle verified in db. I'll take the last option thanks. 2019-07-17 10:20:35 tcely: it runs as: ./vtgen | dd ... | ./vt 2019-07-17 10:21:03 So is dead by broken pipe? 2019-07-17 10:21:14 it should die by broken pipe 2019-07-17 10:21:17 but it does not 2019-07-17 10:21:24 it continue to run forever 2019-07-17 10:22:01 dont know why 2019-07-17 10:22:09 cogitri: you probably know about Purism's Libhandy and their effort to port GNOME applications to it to make them responsive right? We (postmarketOS) wonder, would you be ok with building Alpine's GNOME applications with Libhandy where available? 2019-07-17 10:23:18 PureTryOut: I think I enabled libhandy everywhere already :) 2019-07-17 10:23:27 GNOME settings definitely not 2019-07-17 10:23:31 I wonder if bs=128 shows the same behavior 2019-07-17 10:23:34 At least that I know of 2019-07-17 10:23:39 Eh? Pretty sure we do 2019-07-17 10:23:55 Well in that case it doesn't work lol 2019-07-17 10:23:56 I don't think you can build it without it 2019-07-17 10:24:10 It uses a vendored version of libhandy if you don't have it installed, you can't turn it off IIRC 2019-07-17 10:24:21 MartijnBraam made a video of Phosh on postmarketOS on the PinePhone and used the GNOME settings app. It most definitely didn't scale 2019-07-17 10:24:34 s/scale/adapt 2019-07-17 10:24:34 PureTryOut[m] meant to say: MartijnBraam made a video of Phosh on postmarketOS on the PinePhone and used the GNOME settings app. It most definitely didn't adapt 2019-07-17 10:25:09 https://github.com/alpinelinux/aports/blob/master/testing/gnome-control-center/APKBUILD 2019-07-17 10:25:14 We enable libhandy 2019-07-17 10:25:25 Huh ok 2019-07-17 10:25:25 Maybe it doesn't recognize that it's on a phone? 2019-07-17 10:28:42 It shouldn't matter, it should adapt depending on the available screen space... 2019-07-17 10:28:53 shrug No clue, sorry 2019-07-17 10:29:03 Yeah we'll look into it 2019-07-17 10:29:09 Can read into it, but am on holidays rn so don't expect a too fast answer 2019-07-17 10:29:14 It's not a problem for Alpine Linux 😛 2019-07-17 10:29:53 Well, I like my GNOME stuff to work :P 2019-07-17 10:31:09 True that 2019-07-17 10:31:14 We're not in a hurry though 2019-07-17 10:32:28 Good 👍 2019-07-17 10:33:38 ncopa: are you ok with upgrading nss? https://github.com/alpinelinux/aports/pull/8965 shouldn't require rebuilds and would allow us to upgrade firefox-esr which fixes various CVEs (see https://www.mozilla.org/en-US/security/advisories/mfsa2019-22/) 2019-07-17 10:41:35 nmeum: ok 2019-07-17 10:42:10 nmeum: i merged it. thanks 2019-07-17 10:42:36 great, I will merge the firefox-esr upgrade with some minor changes then 2019-07-17 10:42:38 thanks 2019-07-17 10:49:03 build fine locally and seems to work, just pushed it 2019-07-17 10:49:38 thanks! 2019-07-17 11:33:25 nmeum: i think we can enable firefox-esr for armv7 and armhf now 2019-07-17 11:33:28 we have cargo for those 2019-07-17 11:33:33 rust 2019-07-17 11:37:18 right, rust was the only reason why it wasn't enabled on those arches (iirc) 2019-07-17 11:38:19 I don't have any arm hardware to test this though 2019-07-17 11:43:24 No 2019-07-17 11:43:29 Unless something had changed during my holidays 2019-07-17 11:43:43 We still don't have our triplets compiled in 2019-07-17 11:47:00 .../src/cbindgen-0.9.0/target/release/deps/libtoml-ab7b0edcee353c43.rlib` (signal: 4, SIGILL: illegal instruction) 2019-07-17 11:47:10 when trying to build cbindgen 2019-07-17 12:06:56 On what arch? 2019-07-17 12:07:24 As noted in the commit msg for Rust on other arches it's not functional on these 2019-07-17 12:20:01 Please merge pr6939 2019-07-17 14:10:09 tcely: i dont like it 2019-07-17 14:10:32 its not reproducible 2019-07-17 14:12:15 if we would have built the 2019031302 version that way, and today rebuilt the package, we would have ended up with different content 2019-07-17 14:12:47 also, it does not solve the problem with us not noticing that upstream has a new version 2019-07-17 14:16:43 actually, it would be detected 2019-07-17 14:17:08 but we'd not been able to rebuild it later 2019-07-17 14:56:17 while I'm removing python2 support from packages 2019-07-17 14:56:26 I'm also normalizing them per the guidelines here: https://wiki.alpinelinux.org/wiki/Python_package_policies 2019-07-17 14:56:32 should I also bump them to the latest upstream version? so far I have been 2019-07-17 14:56:40 but it occurs to me that brings extra risk 2019-07-17 15:01:34 ddevault: btw I made a patch to drop a Python 2 only package with no sight on Python 3 support https://lists.alpinelinux.org/~alpine/aports/patches/2838 2019-07-17 15:02:10 +1 2019-07-17 15:02:35 though I bet the emoji package can be retooled to not use it 2019-07-17 15:04:14 No it can not 2019-07-17 15:04:20 Actually, someone PR'ed Python 3 support literally yesterday, wth 2019-07-17 15:04:52 Still, I'd like to get rid of the current version numbers... They're git packages but have an insane high version due to using the date rather than `0_git` 2019-07-17 15:09:29 <_ikke_> "it cannot be done", "oh someone just did" :D 2019-07-17 15:10:23 It's not that I thought it couldn't be done, I thought nobody was going to do it 2019-07-17 15:20:21 ncopa: it's as reproducible as anything else that only publishes the current version. I don't understand the utility of keeping outdated versions for rebuilds, the IP changed and the old data is not expected to work. 2019-07-17 17:04:27 ncopa: you don't happen to recall why you added the NO_NSEC option to the git abuild 10 years ago in d64426ed5e8726cf74fb2f9790c1a89de514f0d8? ':) 2019-07-17 17:05:11 I am assuming that uclibc (or whatever libc alpine was using back then) didn't support stat.st_mtimespec.tv_nsec 2019-07-17 17:28:03 clandmeter: could you make me a member of the alpine group in gitlab or do me a favor and move #10303 from aports to apk-tools? 2019-07-17 17:34:01 _ikke_, can you help? 2019-07-17 17:34:58 nmeum: can find it on mobile 2019-07-17 17:35:13 clandmeter: seems like he isn't here 2019-07-17 17:35:21 it's low priority anyhow ;) 2019-07-17 17:37:21 Yes that's new to me 2019-07-17 17:37:29 He is back 2019-07-17 17:37:48 great timing 2019-07-17 17:37:50 <_ikke_> my vps crashed 2019-07-17 17:37:59 _ikke_: could you make me a member of the alpine group in gitlab or do me a favor and move #10303 from aports to apk-tools? 2019-07-17 17:38:18 _ikke_, can you make nmeum member of aports 2019-07-17 17:38:22 <_ikke_> sure 2019-07-17 17:38:27 thanks 2019-07-17 17:38:37 <_ikke_> as owner? 2019-07-17 17:38:47 Reporter please 2019-07-17 17:38:53 <_ikke_> ok 2019-07-17 17:38:59 So ppl don't push by accident 2019-07-17 17:39:09 <_ikke_> right 2019-07-17 17:39:11 <_ikke_> Done 2019-07-17 17:39:26 Gitlab is terrible ok mobile 2019-07-17 17:39:30 On 2019-07-17 17:40:07 <_ikke_> The interface says that nmeum was already given access 3 days ago 2019-07-17 17:40:19 hm, still can't move the issue though 2019-07-17 17:40:20 <_ikke_> But he cannot move issues as reporter 2019-07-17 17:40:23 ah 2019-07-17 17:40:30 could you do it for me then? 2019-07-17 17:40:40 <_ikke_> yes 2019-07-17 17:40:51 (just going through old bugs currently and noticed that one) 2019-07-17 17:40:54 <_ikke_> Done 2019-07-17 17:40:58 thanks 2019-07-17 18:58:21 https://lists.alpinelinux.org/~alpine/aports/%3C20190717185749.4463-1-sir%40cmpwn.com%3E 2019-07-17 18:58:24 40 packages down, 243 to go... 2019-07-17 18:58:55 back of the napkin estimate suggest 48ish hours of total work to remove Python 2 from Alpine 2019-07-17 19:22:22 Awesome work! 2019-07-17 19:40:55 Could someone review/merge https://github.com/alpinelinux/aports/pull/9319? 2019-07-17 19:41:12 It's a re-open of a PR which got closed wrongly 2019-07-18 00:51:29 call for aid on python 2 deprecation: 2019-07-18 00:51:31 https://lists.alpinelinux.org/~alpine/devel/%3CBVLYYY50OMSF.91O7O5WI1KE7%40homura%3E 2019-07-18 01:09:15 ddevault: Will come home on monday evening, so I could start working on py2 while I recover from jetlag I guess 2019-07-18 01:09:36 thanks Cogitri, much appreciate the help 2019-07-18 01:09:46 ping me when you want a package range assigned to you 2019-07-18 01:10:13 ddevault: throw one for me, i'm tired of trying to get pulseaudio pass through bubblewrap 2019-07-18 01:10:26 maxice8: how much time can you spare? 2019-07-18 01:10:44 I assume an average of 5 minutes per package and allocate accordingly 2019-07-18 01:10:50 no clue, start small, i can ask for more if i finish them 2019-07-18 01:11:03 okay 2019-07-18 01:11:18 can you start with py-flake8-* (just from testing?) 2019-07-18 01:11:29 do you have the email with the instructions/checklist? 2019-07-18 01:11:46 highly preferable to start with stuff from testing and community since i can push to those 2019-07-18 01:11:51 ddevault: yes i have it here 2019-07-18 01:11:59 coolio 2019-07-18 01:12:06 I plan on doing all of testing first 2019-07-18 01:12:13 then taking a break and waiting for complaints to roll in before moving on to community 2019-07-18 01:13:42 Heh, maybe you're done before I get to it after all :P 2019-07-18 01:14:13 fat chance 2019-07-18 01:14:29 testing alone will require roughly 20 man-hours of work 2019-07-18 01:27:24 ddevault: https://github.com/alpinelinux/aports/pull/8878 that's to move ceph to python3 2019-07-18 01:28:01 cheers 2019-07-18 03:41:44 <_c705> Good evening folks - is there an eta on packages moving from test to community, specifically the package "pass" 2019-07-18 03:42:04 ETA is whenever someone feels like moving it and it passes basic QA 2019-07-18 03:42:24 can be as long as years and as short as minutes (like i did with SPIRV and Vulkan stuff) 2019-07-18 03:42:35 <_c705> Where can I get some unit tests maxice8 2019-07-18 03:43:01 <_c705> Perhaps I'll maintain 2019-07-18 03:43:23 _c705: unit tests ? Just guarantee the tests pass and/or it works, then make a Pull Request/Patch moving it from Testing/ to Community/ 2019-07-18 03:44:02 <_c705> I'm not sure exactly what you mean by "passes basic QA" 2019-07-18 03:48:34 _c705: that you make sure that it actually works, e.g. by testing it running it 2019-07-18 03:59:52 <_c705> Indeed, thank you for the help 2019-07-18 04:24:55 <_c705> jomat: What are your plans for the pass package? 2019-07-18 07:44:48 I just made gitlab label "security" red 2019-07-18 07:44:55 <_ikke_> +1 2019-07-18 08:10:37 👍 2019-07-18 08:24:39 ncopa: you don't happen to recall why you added the NO_NSEC option to the git abuild 10 years ago in d64426ed5e8726cf74fb2f9790c1a89de514f0d8? ':) 2019-07-18 08:25:50 it builds fine without that configuration option nowadays, just wondering if there was any specific reason for enabling it 2019-07-18 09:01:01 nmeum: i dont remember, but i would guess it was due to uclibc 2019-07-18 09:01:04 i think we can remove that 2019-07-18 09:02:01 i would probably have added a comment if it was important reason 2019-07-18 09:12:28 ncopa: great, will remove it then 2019-07-18 14:56:40 hi 2019-07-18 14:58:29 (ucloud-file-scan) localhost:~/ucloud-file-scan# qemu-system-x86_64 rbd:uservms/d412abbdcf7f4d9aa54c8b8f09fbd3 2019-07-18 14:58:29 qemu-system-x86_64: rbd:uservms/d412abbdcf7f4d9aa54c8b8f09fbd3: Unknown protocol 'rbd' 2019-07-18 14:58:50 Which package should I install to make rbd work with qemu? 2019-07-18 15:30:55 manj-gnome : rbd like rbd in ceph ? 2019-07-18 15:37:50 manj-gnome : short answer : qemu from Alpine does not support rbd for ceph block device 2019-07-18 15:40:04 long answer : needs patching qemu/APKBUILD to enable it, which would require librbd or ceph devel. community/ceph package (provides librbd) is in community, but qemu is in main. So we have to request to make moving ceph to main first. 2019-07-18 17:24:11 <_ikke_> PureTryOut[m]: akonadiconsole is failing on ppc64le / s390x 2019-07-18 17:28:11 and adhere 80 chars please 2019-07-18 17:28:14 PureTryOut[m]: 2019-07-18 17:41:11 that's a long line 2019-07-18 18:16:13 ikke: I have sent a patch to remove those arches already 2019-07-18 18:16:14 I'll do another to shorten to 80 chars... 2019-07-18 18:18:40 <_ikke_> PureTryOut[m]: oh, sorry 2019-07-18 18:18:44 <_ikke_> I missed that 2019-07-18 18:25:37 I see someone else made a commit to disable thosr arches now 2019-07-18 18:26:27 <_ikke_> yes, I did 2019-07-18 18:26:41 <_ikke_> Forgot to check if there was a PR for it already 2019-07-18 18:39:27 requesting expeditious review on this patch: https://lists.alpinelinux.org/~alpine/aports/patches/2857 2019-07-18 18:40:46 <_ikke_> checking 2019-07-18 18:42:26 <_ikke_> I gather that you verified that the package / library is working (as it's directly added to main) 2019-07-18 18:42:55 I'll do one more round of testing to be certain 2019-07-18 18:43:06 <_ikke_> ok 2019-07-18 18:45:05 yeah, it's good to go 2019-07-18 18:45:24 <_ikke_> ok 2019-07-18 18:47:35 <_ikke_> Do you mind if I dropped the default builddir / cd builddir (as this is a new package that doesn't need to be backported)? 2019-07-18 18:48:08 ah, go ahead 2019-07-18 18:48:11 good catch 2019-07-18 18:49:17 <_ikke_> >>> WARNING: libidn2-dev*: Found static archive on usr/lib/libidn2.a but name doesn't end with -static 2019-07-18 18:49:46 hm, is that fixable by just adding a -static subpackage and letting abuild do the rest? 2019-07-18 18:49:50 <_ikke_> yes 2019-07-18 18:50:12 testing 2019-07-18 18:51:12 <_ikke_> If it works, it's good to go 2019-07-18 18:51:32 I still get that warning 2019-07-18 18:51:39 are we sure abuild handles it for us? 2019-07-18 18:51:45 <_ikke_> You need to put it in front of the -dev subpackage 2019-07-18 18:51:55 <_ikke_> otherwise it will take the static lib 2019-07-18 18:52:00 bug imo 2019-07-18 18:52:03 <_ikke_> yes 2019-07-18 18:52:13 <_ikke_> There is a PR for that iirc 2019-07-18 18:53:25 v2 sent 2019-07-18 18:53:29 <_ikke_> ok 2019-07-18 18:55:19 <_ikke_> pushed 2019-07-18 18:55:27 thank you! 2019-07-18 18:55:52 <_ikke_> yw 2019-07-18 18:59:07 <_ikke_> Updated the status on lists.a.o 2019-07-18 19:01:02 cheers 2019-07-18 19:52:26 tmhoang: we aren't ready to move ceph to main yet (still have a couple changes that need to make it into aports) 2019-07-18 21:53:06 iggy: what changes, on top of your mind ? 2019-07-18 22:10:21 tmhoang: python3, breaking up some of the packages, making sure ceph-manager actually works, etc 2019-07-18 22:10:35 some of which is already here: https://github.com/alpinelinux/aports/pull/7894 2019-07-18 22:11:23 nice fancy 2019-07-18 22:11:36 will have a closer look 2019-07-18 22:13:51 iirc mgr dasdboard front end still requires py2 2019-07-18 22:32:50 I built the package on a system without py2, but I'm not sure if it runs yet (my lab is still packed from the move) 2019-07-18 22:40:11 hi there! 2019-07-18 22:42:19 I am trying to get my head around cross compiling on alpine and started with cloning aports then using `scripts/bootstrap.sh` to create the bare environment, however I am noticing a number of build failures due to minor issues around dependencies, etc 2019-07-18 22:42:29 is that supposed to be normal? 2019-07-18 22:42:40 step by step was basically: 2019-07-18 22:44:19 1. Built a chroot with minimal fs 2019-07-18 22:44:38 2. apk add alpine-sdk 2019-07-18 22:44:50 3. git clone aports 2019-07-18 22:45:09 4. ./scripts/bootstrap.sh armv7 2019-07-18 22:46:42 trixpan: did you start with http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/armv7/alpine-minirootfs-3.10.1-armv7.tar.gz ? 2019-07-18 22:47:34 no. build host is x86_64 2019-07-18 22:47:58 so I used alpine-minirootfs-3.10.1-x86_64.tar.gz 2019-07-18 22:49:28 the error atm is 2019-07-18 22:50:00 nlplug-findfs.c:940:32: warning: implicit declaration of function 'makedev' [-Wimplicit-function-declaration] return S_ISBLK(st.st_mode) && makedev(maj, min) == st.st_rdev; 2019-07-18 22:51:34 (in mkinitfs) 2019-07-18 22:52:09 armv7-alpine-linux-musleabihf-gcc --sysroot=/home/user/sysroot-armv7/ -Wl,--as-needed -o nlplug-findfs nlplug-findfs.o -L/home/user/sysroot-armv7/usr/lib -lblkid -L/home/user/sysroot-armv7/usr/lib -lkmod -L/home/user/sysroot-armv7/lib -lcryptsetup /usr/lib/gcc/armv7-alpine-linux-musleabihf/8.3.0/../../../../armv7-alpine-linux-musleabihf/bin/ld: n 2019-07-18 22:52:10 lplug-findfs.o: in function `searchdev':nlplug-findfs.c:(.text+0xd20): undefined reference to `makedev'collect2: error: ld returned 1 exit statusmake: *** [Makefile:115: nlplug-findfs] Error 1>>> ERROR: mkinitfs: build failed>>> mkinitfs: Uninstalling dependencies.. 2019-07-19 07:02:09 morning 2019-07-19 07:06:17 Morning clandmeter 2019-07-19 07:07:49 ncopa: can we symlink /etc/ssl/cert.pem to /etc/ssl/certs/ca-certificates.crt via some trigger or similar? 2019-07-19 07:09:24 i think i send a patch previously 2019-07-19 07:09:42 it will allow us to have certificate support without having to install ca-certificates. 2019-07-19 07:13:41 morning 2019-07-19 07:14:02 yeah, i think that needs to be fixed 2019-07-19 07:14:47 and maybe also vice versa, if we install ca-certificates we could remote ca-certificates-cacert (which has the cert.pem) 2019-07-19 07:14:57 s/remote/remove 2019-07-19 07:14:57 clandmeter meant to say: and maybe also vice versa, if we install ca-certificates we could remove ca-certificates-cacert (which has the cert.pem) 2019-07-19 07:15:22 need to think how to handle it 2019-07-19 07:16:06 i also think there was some issue with users not being able to add their own certs 2019-07-19 07:16:27 ive seen issues like that. 2019-07-19 07:16:55 but i never used my own certs so i dont know. 2019-07-19 07:17:29 docker users will benefit from the symlink 2019-07-19 07:18:23 im not convinced that a symlink is the proper way to go 2019-07-19 07:18:59 educate me 2019-07-19 07:19:50 iirc, the cert.pem and ca-certificates.crt are generated differently? 2019-07-19 07:19:56 one is cat *.crt 2019-07-19 07:20:09 the other is built using a small C app 2019-07-19 07:20:22 but the content should be the same 2019-07-19 07:20:39 i think the logic of the c app is the other symlinks? 2019-07-19 07:20:41 not sure though 2019-07-19 07:21:04 the C app generated file is generated via trigger 2019-07-19 07:21:15 its the same i think 2019-07-19 07:21:19 both catted 2019-07-19 07:21:26 ok 2019-07-19 07:21:50 but it extract the serial and creates a symlink? or whatever the number is. 2019-07-19 07:22:11 why is there a difference in the name? cert.pem vs ca-certificates.crt? 2019-07-19 07:22:26 because its what we had before 2019-07-19 07:22:32 from libressl 2019-07-19 07:22:38 so its backwards compat thing? 2019-07-19 07:22:40 i guess a freebsd thingy 2019-07-19 07:23:07 yes and i had to give it a name. 2019-07-19 07:23:18 ok 2019-07-19 07:23:34 they are built from same package? 2019-07-19 07:23:45 same apkbuild yes 2019-07-19 07:24:17 you could also generate it similar like we do now with ca-certificates.crt 2019-07-19 07:24:29 yes, i think we should do that 2019-07-19 07:25:16 and ship it together with the symlink in ca-certificates-cacert as the "default config" for ca-certificates package 2019-07-19 07:25:42 clandmeter: do we have an issue for it in bugtracker? 2019-07-19 07:25:51 dunno 2019-07-19 07:26:11 i need to go out for a few hours, could you please find or file an issue about it 2019-07-19 07:26:18 and i'll have a look at it later 2019-07-19 07:28:23 heh gitlab even searches in git repo 2019-07-19 15:50:29 friendly ping community/ commiters : https://github.com/alpinelinux/aports/pull/9044 2019-07-19 15:53:41 <_ikke_> looking 2019-07-19 15:54:44 <_ikke_> tmhoang: seems like there are conflicts 2019-07-19 15:55:45 ok let me check 2019-07-19 15:55:58 <_ikke_> There has been an update 2019-07-19 15:56:08 <_ikke_> f37c80a85d4121a74600479cc7064a855b83bcd6 2019-07-19 17:12:38 _ikke_: I'm checking ocaml rdeps, opam breaks with 4.08 2019-07-19 17:12:58 it would be nice if contributor takes a look at rdeps when upgrading 2019-07-19 17:15:23 also ocamlbuild, and basically every community/ocaml* packages 2019-07-19 17:15:28 ... 2019-07-19 17:16:05 so let's just leave that ocaml s390x issue aside a for now. I will find sometime to fix this ocaml* upgrade thinggy 2019-07-19 19:56:53 ncopa: for main/openssh/fix-verify-dns-segfault.patch why is the patch moving memory allocation before NULL checking? 2019-07-19 22:35:20 Can pr8932 get merged before I get around to 9.14.4? 2019-07-20 08:38:30 folks, are github PRs acceptable as a contribution mechanism or just patch via emails? (probably I should have asked before sending a PR but asking nonetheless) 2019-07-20 08:38:53 GitHub PR usually is the way to go 2019-07-20 08:39:07 Emails are accepted too though 2019-07-20 08:39:27 Should I submit contributions to the project wiki then? 2019-07-20 08:39:44 (as add this to the how to contribute wiki page) 2019-07-20 09:22:10 trixpan: are you working on documentation? 2019-07-20 09:23:37 I will be happy to 2019-07-20 09:24:03 I am new to the project but noticed a few things that I am happy to document for the benefit of all 2019-07-20 14:56:51 i'm back , what did i miss ? 2019-07-20 14:58:02 <_ikke_> We started using gitlab (mostly for issues now, not yet aports) 2019-07-20 14:58:27 _ikke_: That i know, i closed a few hundred Issues on gitlab 2019-07-20 14:58:31 i mean in the last 2 days where my computer was on repairs 2019-07-20 14:58:34 <_ikke_> ah ok 2019-07-20 14:58:39 <_ikke_> not a lot then 2019-07-20 15:32:08 ddevault: ping, any update on the python2 package assignment ? 2019-07-20 15:32:22 didn't I assign you some? 2019-07-20 15:32:29 py-flake8-* according to my notes 2019-07-20 15:32:31 Not as far as i am aware 2019-07-20 15:32:33 ah 2019-07-20 19:38:29 ddevault: i done all flake8 stuff except py-flake8 itself 2019-07-20 19:39:56 thanks maxice8, I'll take a look when I can 2019-07-20 19:39:59 (moving this weekend) 2019-07-20 19:40:24 if you want i can send you a list of packages i worked into py3 via pm or mail 2019-07-20 19:41:09 mail would be great: sir@cmpwn.com 2019-07-20 19:41:12 thanks for your help and hard work 2019-07-20 19:45:05 Sent, after i'm done with knot-resolver4 (Made a PR for @tcely for that) i can take more packages in 2019-07-20 19:47:32 maxice8: do you want another set of packages? 2019-07-20 19:47:43 Sure 2019-07-20 19:47:52 how about the remainder of py3-django-* 2019-07-20 19:48:11 hmm, there is stuff in main/ 2019-07-20 19:48:18 just testing 2019-07-20 19:48:30 alright then 2019-07-20 19:48:43 many thanks! 2019-07-20 20:02:03 maxice8: pr9398 2019-07-20 20:06:51 pkgdesc for py-django-js-asset is "No description provided" 2019-07-20 20:28:17 maxice8: since you're working pretty fast do you want a larger group to look at? 2019-07-20 20:28:50 Sure 2019-07-20 20:29:08 want to take the remainder of py-f* and py-g*? 2019-07-20 20:29:40 i'll take py-g* 2019-07-20 20:29:45 g* is 3 packages 2019-07-20 20:29:55 i'll take community/ as well 2019-07-20 20:30:02 let's hold on community, if you don't mind 2019-07-20 20:30:16 if you insist 2019-07-20 20:30:31 I just want to get everything sorted in testing so that we can be confident in the approach before we move onto other repos 2019-07-20 20:31:19 I also have some feedback on your earlier patches, you might want to hold them for a second opinion before pushing 2019-07-20 20:53:01 sure 2019-07-21 06:03:51 209 PRs, someone needs to look at the main/ stuff 2019-07-21 09:56:49 I have finally managed to build armv7 v3.10 boostrap on x86_64 host. Has anyone else ever been able to achieve this without modifications to the bootstrap.sh ? 2019-07-21 09:57:12 I had to change a few things before getting it to work 2019-07-21 09:57:24 https://github.com/alpinelinux/aports/pull/9584 2019-07-21 10:00:58 I built an armv7 bootstrap on native hardware 2019-07-21 10:01:05 the problem is getting them to support it 2019-07-21 10:01:06 ¯\_(ツ)_/¯ 2019-07-21 10:01:31 GOLang code should be able to be compiled using GO's built in X-compilation but will require a mass change of APKBUILD files (or hackery of abuild) 2019-07-21 10:01:41 maybe it'll get merged 2019-07-21 10:01:42 good luck 2019-07-21 10:02:07 <_ikke_> alpine's main focus is compiling on native hardware 2019-07-21 10:02:35 hmmmm. and why does bootstrap.sh support cross compilation then? 2019-07-21 10:02:47 `scripts/bootstrap.sh` 2019-07-21 10:03:04 <_ikke_> Because there are cases where you do need to cross-compile. 2019-07-21 10:03:52 Hmmm. but as far as I understood, without the bootstrap, cross compilation is particularly hard? 2019-07-21 10:04:42 <_ikke_> It's main use is to bootstrap a new architecture 2019-07-21 10:04:52 e.g. https://gitlab.alpinelinux.org/alpine/aports/issues/10038 2019-07-21 10:04:53 <_ikke_> but I don't think it's required for general cross-compiling 2019-07-21 10:05:12 it is and it isn't. 2019-07-21 10:05:37 <_ikke_> Well, it does create code to build a cross-compiler, so it's logical that people want to use that 2019-07-21 10:06:12 bootstrap is mostly a wrapper around abuild but it provides things like musl and other code to be linked against, plus sysroot 2019-07-21 10:06:41 BTW. I am not an expert. Just happen to have spent the last 3 days trying to get it to work. 2019-07-21 10:06:54 (so I may be writing bs. :-) ) 2019-07-21 10:07:17 <_ikke_> I'm no expert either :) 2019-07-21 10:12:58 ( : ) ) 2019-07-21 11:25:34 seems like https://github.com/alpinelinux/aports/commit/d1ff02d3584bf422c0d55d7e1b4680ed68c84bb3 introduces a regression and mkinitfs cannot build anymore 2019-07-21 11:47:06 trixpan : I think the idea of bootstrap.sh is to bootstrap a chroot for ARM on x96 with a small set of essential main packages, then use that chroot to run natively on ARM to build the universe. I don't think one can build the universe using that chroot running on x86. 2019-07-21 11:48:14 @tmhoang - I believe this to be the case as well. But was unable to achieve even that without relying on https://github.com/alpinelinux/aports/pull/9584 2019-07-21 11:49:18 that might be correct. we might have changed build dependencies order somehow during the course of bootrstrap.sh 2019-07-21 11:49:38 but I think the idea here is to list the packages that are required 2019-07-21 11:49:39 I am currently trying to bootstrap the master branch but as mentioned above, suspect the upgrade to musl 1.1.23 broke mkinitfs. 2019-07-21 11:49:58 so that porter knows what he might need, more than a out-of-the-box script 2019-07-21 11:50:40 if people don't put community/go in there, for example, you might need to find/trace the dependencies of packages that require go lang 2019-07-21 11:50:51 so feel free to comment out, 1-2 lines , etc 2019-07-21 11:51:05 @tmhoang I believe it may be possible to cross compile most of the things (at least the C/C++ things) without major dramas. Python and other stuff may be painful 2019-07-21 11:51:24 golang should be possible as well but will require changes to abuild 2019-07-21 11:52:20 last time I bootstrap golang I need 1.14 version, the last one that support C to bootstrap go 2019-07-21 11:52:49 I was under the impression go can compile itself? 2019-07-21 11:52:54 now you can use Alpine's go to bootstrap your go. 2019-07-21 11:53:06 which requires you to run your chroot in native ARM, correct ? 2019-07-21 11:53:43 no. I am currently able to bootstrap arm on x86 2019-07-21 11:53:52 but image you dont have golang binary for your arch :) 2019-07-21 11:53:57 ok 2019-07-21 11:54:38 working up to linux-vanilla but ignoring community/go (as per PR). Because go isn't truly required to "mkimage" it works fine. :-) 2019-07-21 11:54:58 the go compiler cross compile out of the box 2019-07-21 11:55:02 so, to summarize I think bootstrap.sh is more to provide information for you rather than out-of-a-box package solution 2019-07-21 11:55:36 `GOARCH=arm go build -v ` should result on a cross compiled binary 2019-07-21 11:55:43 the wonders of golang. :-) 2019-07-21 11:56:25 seems like https://github.com/alpinelinux/aports/commit/d1ff02d3584bf422c0d55d7e1b4680ed68c84bb3 introduces a regression and mkinitfs cannot build anymore -> what's up with it ? 2019-07-21 11:58:00 warning: implicit declaration of function ‘makedev’ 2019-07-21 11:58:05 and then fail 2019-07-21 11:58:22 bear with me and I will submit the PR to mkinitfs 2019-07-21 11:58:29 just trying to confirm that is the case 2019-07-21 12:00:29 debugging bootstrap is such a pain. All the time I delete the sysroot and the packages. Have to recompile the whole thing. :S But it is for a good cause. :-) 2019-07-21 12:01:06 so just include sys/sysmacros.h in mkinitfs/nlplug-findfs.c ? 2019-07-21 12:01:15 I believe so. 2019-07-21 12:01:27 but let me confirm first. ;-) 2019-07-21 12:01:37 you can use docker import or something iirc 2019-07-21 12:02:48 confirmed. musl upgrade caused the regression 2019-07-21 12:03:01 diff 2019-07-21 12:03:02 -pkgver=1.1.23+pkgver=1.1.22 2019-07-21 12:03:12 -sha512sums="a2278de9903852b08352d3e734a39d4616caa602496997ba843e8fea0e1c481761776745faf04536a149d1c4af416b68df681b6fbc9ae2de8794e18c2e853b09 musl-1.1.23.tar.gz+sha512sums="08a40d722672504427238e71c9e52a723c6a14735abe9581d6d4bb3f86662d5d51a3f32a6aed6420c1f9680e22a3a554a9b87ae342635be971e2db49cc9fdb87 musl-1.1.22.tar.gz 2019-07-21 12:03:32 wonder what changed 2019-07-21 12:04:55 compatibility & conformance:- O_TTY_INIT is now defined- sys/types.h no longer pollutes namespace with sys/sysmacros.h in any profile- powerpc asm is now compatible with clang internal assembler 2019-07-21 12:05:20 @tmhoang seems to align with issue? 2019-07-21 12:06:10 here's the issue: 2019-07-21 12:06:16 Uploaded file: https://uploads.kiwiirc.com/files/383198163620ca3fc7b33e53b2deaa95/pasted.txt 2019-07-21 12:12:04 I don't know, maybe fabled could help 2019-07-21 12:18:28 trixpan : http://git.musl-libc.org/cgit/musl/commit/?id=a31a30a0076c284133c0f4dfa32b8b37883ac930 2019-07-21 12:20:14 yep. Same thing I mentioned above crom WHATSNEW 2019-07-21 12:20:26 just confirmed the issue can be fixed importing sysmacros.h 2019-07-21 12:20:29 submitting the PR 2019-07-21 12:25:16 @tmhoang https://github.com/alpinelinux/mkinitfs/pull/55 2019-07-21 18:07:01 Can someone look at PRs for main/ ? 2019-07-21 18:26:37 I can test a few of them on x86_64 and aarch64 in a sec 2019-07-21 18:26:58 see if it builds, works properly, and 'looks' right 2019-07-21 18:27:11 I can't push anything though :P 2019-07-21 18:36:38 That would be nice 2019-07-21 19:12:02 I'm hearing thunder and as far as I've heard a lightning storm is rearing up, so I might have to do it tomorrow 2019-07-21 20:32:31 maxice8: The glog-dev package doesn't contain a pkgconfig file anymore since 0.4.0 (the PR for installing the pkg-config file using cmake was never merged https://github.com/google/glog/pull/239) 2019-07-21 20:41:37 Should it be pc:libglog or pc:glog ? 2019-07-21 20:50:38 z3ntu: can you try pr9603 2019-07-22 05:46:53 lots of PRs for main/, can anyone take a look ? 2019-07-22 06:00:24 morning 2019-07-22 06:00:30 i'll have a look at it today 2019-07-22 06:00:36 morning 2019-07-22 06:00:39 :D thank you i have a few that are CVE fixes 2019-07-22 06:57:51 maxice8: I still get "-- Package 'libglog', required by 'virtual:world', not found" from something using glog, so I think the .pc file should be called libglog.pc instead of glog.pc 2019-07-22 07:00:16 After renaming the file manually, it works "-- Found libglog, version 0.4.0" 2019-07-22 07:43:44 <_ikke_> maxice8: I've merged some prs for main yesterday 2019-07-22 07:46:06 _ikke_ have write permission to main/ ? nice so guess who I'm going to abuse haha 2019-07-22 07:46:26 <_ikke_> ACTION whistles 2019-07-22 07:55:51 maxice8: re #10676 there are a patch release from upstream, so i think we should use that instead of backport patch 2019-07-22 07:57:19 ncopa: sure, I'm in bed RN going to sleep, if you can't wait up from 12 to 16 hours feel free to fill it 2019-07-22 07:59:46 im on it. have a good sleep! 2019-07-22 08:39:29 ncopa: did you look into ca-certs? 2019-07-22 08:57:07 clandmeter: not yet 2019-07-22 08:57:22 the plan is to merge some of the PRs for main 2019-07-22 08:58:12 so you don't manage your issues ala fifo? ;-) 2019-07-22 10:21:31 maxice8: seems like the /var/spool/mail symlink broke builders 2019-07-22 10:26:08 <_ikke_> openrc build fails due to chmod in post-upgrade 2019-07-22 10:26:21 no 2019-07-22 10:26:47 <_ikke_> oh, it's builddeps 2019-07-22 10:27:05 i think it can not create the /var/spool/mail symlink due to the existing /var/spool/mail dir 2019-07-22 10:32:57 I had to: `rmdir /var/spool/mail && apk fix` on each edge builder 2019-07-22 10:34:31 <_ikke_> I see a few related PRs 2019-07-22 10:34:44 <_ikke_> is Leo moving /var/spool/mail to /var/mail? 2019-07-22 10:51:41 yup 2019-07-22 10:52:11 its FHS 3.0 2019-07-22 10:52:27 <_ikke_> ah ok 2019-07-22 10:52:44 <_ikke_> Didn't know it was updated 2019-07-22 10:54:12 neither did i til i saw maxice8's PR 2019-07-22 11:10:10 my feelings about gitlab so far is all positive 2019-07-22 11:13:27 <_ikke_> Nice, the performance holds well as well for now 2019-07-22 11:13:53 <_ikke_> I'm slowly working on getting CI working on all our arches 2019-07-22 16:03:59 ncopa: oops, sorry 2019-07-22 16:31:08 Sooo, almost home now waiting for connection flight, what did I miss during my holidays? :P 2019-07-22 16:31:36 People are working on moving to gitlab even harder 2019-07-22 16:31:59 ddevault is gathering volunteers to exterminate python2 2019-07-22 16:33:48 ncopa: can i take on the libosinfo thingy ? 2019-07-22 17:17:27 ncopa: why didn't you set the shell of the postgres account to /sbin/nologin in 770d8ce7c6c556d952884ad436dd82b17ceb1a9a 2019-07-22 17:23:56 https://github.com/alpinelinux/aports/pull/9627 2019-07-22 17:24:48 maxice8: np. it happens 2019-07-22 17:25:20 nmeum: because its not uncommon to run postgres or postgres tools with su 2019-07-22 17:25:47 <_ikke_> su -s /bin/sh :) 2019-07-22 17:25:57 https://wiki.postgresql.org/wiki/First_steps 2019-07-22 17:26:07 tell that to alll the documentation that exists 2019-07-22 17:26:12 # su - postgres 2019-07-22 17:26:12 <_ikke_> heh 2019-07-22 17:26:13 $ psql 2019-07-22 17:28:08 ncopa: good to know, will close the PR and the issue then 2019-07-22 17:28:13 so its possible to work around it with "su -s /bin/sh -c ..."? 2019-07-22 17:28:25 or using doas or sudo? 2019-07-22 17:28:40 you can workaround 2019-07-22 17:28:40 <_ikke_> Yes, if you explicitly speciy a shell, then it should work 2019-07-22 17:28:44 sudo -u postgres -s should work 2019-07-22 17:28:50 try this: $ sudo su -s /bin/sh - nobody 2019-07-22 17:28:58 hm 2019-07-22 17:29:28 then i think it may be better to disable that user as well 2019-07-22 17:29:48 we're probably gonna have a lot of people wondering what broke if we quietly change it to something non-standard 2019-07-22 17:29:59 https://wiki.debian.org/PostgreSql#User_access 2019-07-22 17:30:08 <_ikke_> is it non-standard to have a login shell for system users? 2019-07-22 17:30:27 the question is how many people who while complain, how much will break 2019-07-22 17:30:51 not non-standard in that sense, non-standard in the sense that it would differ from most documentation for postgres and projects using it 2019-07-22 17:30:55 <_ikke_> It will probably break for people just blindly following documentation 2019-07-22 17:30:56 in general, i think its a good idea to disable the login shell - as long as someone else deal with the user support.... 2019-07-22 17:31:07 ^ 2019-07-22 17:31:22 could tell them to nag at $whoever to update their docs, i guess 2019-07-22 17:31:29 we could print a message informing users of that change from a post-upgrade script 2019-07-22 17:31:36 great idea 2019-07-22 17:31:51 <_ikke_> That doesn't help people just installing postgres 2019-07-22 17:32:04 true 2019-07-22 17:32:33 right, people upgrading postgres also need to modify their /etc/passwd manually anyhow 2019-07-22 17:32:40 yeah 2019-07-22 17:32:46 its for new installs 2019-07-22 17:32:53 possibly docker scripts etc 2019-07-22 17:33:19 <_ikke_> what cases does disabling the login shell actually protect against (assuming the account does not have a password set anyway) 2019-07-22 17:33:41 <_ikke_> (disabled) 2019-07-22 17:33:54 I just brought this up because the issues was still open, I honestly don't think that it makes a big difference anyhow 2019-07-22 17:34:01 it's just a roadblock if someone already managed to break into the systme 2019-07-22 17:34:58 <_ikke_> I'm just curious how they could leverage it 2019-07-22 17:35:38 oh man, i've probably had thousands of reverse shells as 'www-data', 'mysql' and similar 2019-07-22 17:35:44 in total, that is 2019-07-22 17:36:10 and disabling the shell will slow you down? 2019-07-22 17:37:04 <_ikke_> aren't you just executing /bin/sh in those cases? 2019-07-22 17:37:16 <_ikke_> or actually 'logging in' as that user 2019-07-22 17:37:18 i guess it depends 2019-07-22 17:37:54 i guess there may be cases where it will stop or slow down an attacker 2019-07-22 17:38:02 so i think its a good idea to disable it 2019-07-22 17:38:08 <_ikke_> yes, agree 2019-07-22 17:38:09 specially if there is a simple workaround 2019-07-22 17:38:20 <_ikke_> Was just out of interest 2019-07-22 17:39:30 the only thing i am worried about is if it will break stuff for people and create user support work 2019-07-22 17:39:46 but i guess it will not be much of it 2019-07-22 17:39:50 and may be worth it 2019-07-22 17:41:15 including the workaround in the commit message and maybe mentioning that change in the 3.11 release notes could help reducing that 2019-07-22 17:41:39 yeah 2019-07-22 17:41:56 it may be nice to alos check what other distro do. it seem like debian has it disabled 2019-07-22 17:42:06 archlinux has enabled a shell for postgres 2019-07-22 17:42:23 https://git.archlinux.org/svntogit/packages.git/tree/trunk/postgresql.sysusers?h=packages/postgresql 2019-07-22 17:42:48 I doubt that the kind of user that would trip over this will read a commit msg or release notes to be honest 2019-07-22 17:43:12 commit message will be for those who tries to "fix" it 2019-07-22 17:43:41 gentoo also adds a shell https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-db/postgresql/postgresql-9999.ebuild#n127 2019-07-22 17:43:57 Fair enough 2019-07-22 17:43:58 su - postgres broke. why did it break? when did it break? 2019-07-22 17:44:17 nmeum: and debian? 2019-07-22 17:47:00 I'm having an issue with a $pkgname.post-install script that calls install to change owner and permissions. If I run "ls -l" from the .post-install script I see the correct permissions, but after I apk add the package the owner and permissions are not set correctly on the file system. Any ideas? 2019-07-22 17:47:44 <_ikke_> Do you need to do it in a post-install script? 2019-07-22 17:47:45 ncopa: https://salsa.debian.org/postgresql/postgresql-common/blob/master/debian/postgresql-common.postinst#L33-34 seems to add a shell as well 2019-07-22 17:48:30 _ikke_: Possibly not. Was just adapting the package from Arch. I'll try and do it in package() instead 2019-07-22 17:48:34 <_ikke_> zmcgrew: (I would 1) expect it to work, 2) abuild to complain about it) 2019-07-22 17:49:14 nmeum: hum... ok 2019-07-22 17:49:24 so there are no other distro that disable the shell? 2019-07-22 17:49:35 haven't found one so far 2019-07-22 17:49:50 i guess another way to fix it would be to remove it from alpine-baselayout, and create it with the postgresql pre-install only 2019-07-22 17:49:56 yep 2019-07-22 17:50:00 i was about to suggest that 2019-07-22 17:50:09 I think that's a decent compromise 2019-07-22 17:50:26 lets do that. make sure that we keep the uid too 2019-07-22 17:50:39 ok 2019-07-22 17:50:42 gimme a second 2019-07-22 17:53:52 ncopa: ping: libosinfo 2019-07-22 18:00:32 ncopa: changed this accordingly in https://github.com/alpinelinux/aports/pull/9627 currently still building postgres locally to test it 2019-07-22 18:00:58 should probably also mention in the commit messages why this change was made 2019-07-22 18:02:40 <_ikke_> that would be appreciated 2019-07-22 18:03:49 hmm, i got an custom APKBUILD which i built on my other laptop there it works fine. on this laptop i built it using the same APKBUILD, but for some reason gcc compiles a __builtin_trap() - ud2 on x86_64, and it thus crashes my code by throwing an illegal instruction fault. why could this be? 2019-07-22 18:04:14 here's the APKBUILD http://tpaste.us/pW4x 2019-07-22 18:04:26 argh, should have disabled the postgres testsuite this takes forever ;_; 2019-07-22 18:08:30 maxice8: will do libosinfo later. still working on sdl2 breakage doe t omove to cmake 2019-07-22 18:09:08 ncopa: oh 2019-07-22 18:09:22 p4Wv1qn095FW: i think its some buffer overflow. i think its either sta-smash-protector or the hardened source 2019-07-22 18:09:28 Pinged PureTryOut about that already? 2019-07-22 18:09:38 i added a comment to the PR 2019-07-22 18:09:54 i know what broken, but my cmake skills are slowing me down 2019-07-22 18:10:07 i just learned that a cmake list is a string separated with ; 2019-07-22 18:10:12 Okie 2019-07-22 18:10:31 you always learn something new with cmake 2019-07-22 18:10:38 lol 2019-07-22 18:10:40 indeed 2019-07-22 18:10:47 i have a fix though 2019-07-22 18:11:00 i dont think there are many other users that uses both directfb and cmake 2019-07-22 18:11:04 ncopa: nah, gcc actually compiles this ud2 in there, and i actually hit it: see the objdump -DS here: http://tpaste.us/W1p0 2019-07-22 18:11:50 p4Wv1qn095FW: its fortify source 2019-07-22 18:12:04 i bet it does not happen with -U_FORTIFY_SOURCE 2019-07-22 18:12:13 let me try 2019-07-22 18:12:37 i said hardened source, but meant fortify source (its been a long day) 2019-07-22 18:13:05 i got it anyways :) 2019-07-22 18:13:46 \o/ without -U_FORTIFY_SOURCE it indeed does work! 2019-07-22 18:13:54 ncopa: updated the commit messages for the postgres PR and verified that the account exists after installing postgres, however, I don't use postgres and didn't run/configure it 2019-07-22 18:14:12 p4Wv1qn095FW: but really, its a bug in the code 2019-07-22 18:14:27 potentially a security bug 2019-07-22 18:14:33 so how do i make this compile with fortify src? thanks a lot for your quick, sharp and on spot analysis 2019-07-22 18:14:46 _ikke_: Thanks for steering me in the other direction. Works fine if I set permissions in package() instead of post-install 2019-07-22 18:14:52 fortify source is enabled by default 2019-07-22 18:15:00 <_ikke_> zmcgrew: No problem 2019-07-22 18:15:16 its an extra check that there is enough allocated space for the memmove operation 2019-07-22 18:15:51 and if its not it will __builtin_trap() instead of letting an attacker exploit it 2019-07-22 18:15:53 that is strange, because now the code runs as expected, no overflow. 2019-07-22 18:15:58 i see 2019-07-22 18:16:07 there is an overflow 2019-07-22 18:16:15 <_ikke_> p4Wv1qn095FW: it might only happen in certain circumstances 2019-07-22 18:16:16 it writes over another buffer 2019-07-22 18:16:36 maybe that other buffer will never be used 2019-07-22 18:17:14 it may or may not be possible to exploit it, but it is definitively a memory corruption bug 2019-07-22 18:17:32 <_ikke_> p4Wv1qn095FW: it should be reported upstream 2019-07-22 18:17:52 i will report it 2019-07-22 18:18:20 one more question, why was this not triggered on my other laptop? 2019-07-22 18:18:53 although upstream is a bit dead 2019-07-22 18:19:12 but it is a security library, so relevant 2019-07-22 18:21:20 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/issues/10532 could you move this to the apk-tools repo? 2019-07-22 18:21:45 <_ikke_> done 2019-07-22 18:21:49 thanks 2019-07-22 18:22:32 p4Wv1qn095FW: dont know, maybe your laptop uses different architecture, maybe the input was different/smaller, maybe you used another toolchain 2019-07-22 18:22:52 both are alpine/edge x86_64 2019-07-22 18:23:05 both run the same test program. 2019-07-22 18:27:13 interesting. is it the same binary? 2019-07-22 18:27:22 build on same machine? 2019-07-22 18:27:30 did you have same cflags, etc 2019-07-22 18:27:53 unfortunately i have no access to the other laptop atm. 2019-07-22 18:28:11 i guess it worked by "luck" 2019-07-22 18:28:31 or more precise, you were lucky that the other machine found it 2019-07-22 18:28:48 i'll investigate this once i have access to both laptops again. 2019-07-22 18:29:11 genereate a core dump and a backtrace 2019-07-22 18:32:49 maxice8: is libosinfo blocking you? 2019-07-22 18:33:09 no but i already made PRs for them 2019-07-22 18:34:32 nm... im on it 2019-07-22 18:37:59 maxice8: thanks for the ping 2019-07-22 18:38:20 ncopa: :# 2019-07-22 18:38:25 :D* 2019-07-22 18:45:40 maxice8: thanks alot for helping with the sec issues 2019-07-22 18:46:39 :D glad to help 2019-07-22 19:09:22 tcely: i disabled testing/sequoia-sqv due to it failed to build with updated nettle 2019-07-23 06:55:25 This HTML blocking is highly annoying. 2019-07-23 06:58:51 Gmail app doesn't let me change the setting to plain text and also does not display the error in the bounced email. 2019-07-23 07:08:02 as i understand the mailing list does not allow sending html mails? 2019-07-23 07:08:28 do we have an issue in gitlab for it? 2019-07-23 07:08:36 i think we need to fix that somehow 2019-07-23 07:12:02 Pretty sure ddevault blocked that by design 2019-07-23 07:13:40 https://man.sr.ht/lists.sr.ht/etiquette.md 2019-07-23 07:13:53 > HTML emails are rejected by all sr.ht services. 2019-07-23 07:15:06 ncopa: I found no related issue 2019-07-23 07:15:38 Cogitri: All Android Gmail users are lo 2019-07-23 07:16:01 Cogitri: All Android Gmail users are blocked by that without knowing why. 2019-07-23 07:16:04 http://k00.fr/e0usualf 2019-07-23 07:16:13 Hm, can't you use some other email app for GMail which allows setting that? 2019-07-23 07:16:36 Depends on your provider 2019-07-23 07:16:57 we dont want to force our users to do such things. 2019-07-23 07:17:07 Not that I'd have much say in this, I barely use the ML, but I think ddevault's point that a ML without HTML emails are a better experience is fair 2019-07-23 07:17:12 I don't have a better option and switching email apps isn't a solution 2019-07-23 07:17:32 Hm, alright 2019-07-23 07:18:51 there may be various reasons that you cannot change email client or disable html mails 2019-07-23 07:19:42 entrerprise policies 2019-07-23 07:20:11 Like it doesn't matter what the client sends if your message goes through a text to html rewriting gateway. :-( 2019-07-23 07:20:11 disabilities (screen readers) 2019-07-23 07:21:45 the question is if we want use this as gate-keeper to filter out (discrimitate) those kind of users 2019-07-23 07:22:12 Oh, I had expected that enterprises would rather block HTML (due to being an attack vector) and that screen readers would have a better time reading plain text emails :o 2019-07-23 07:22:41 the point is that there are valid reasons that you cannot use another email client 2019-07-23 07:23:03 Hm, clandmeter has suggested a warning which would be fair too, I guess that'd only be sent once (spamming for every email seems annoying) 2019-07-23 07:23:58 you might not be allowed to install/remove software from the work computer 2019-07-23 07:24:23 im personally no fan of html mails, but our goal is to be inclusive 2019-07-23 07:24:26 you never seen an enterprise conversations? its now even bundled into some privacy gdpr related system which adds lots of fun templating to your emails. 2019-07-23 07:25:19 sending patches is one thing 2019-07-23 07:25:37 im sort of ok with blocking html mails to a patches-only mailing list 2019-07-23 07:25:54 yes i agree on that. 2019-07-23 07:26:06 but to be able to participate in discussion, ask for or provide support 2019-07-23 07:26:13 participate in the community 2019-07-23 07:26:23 clandmeter: Now that you mention it I think ${WORK}s outgoing emails actually are html, my bad 2019-07-23 07:26:25 i dont think we should discriminate 2019-07-23 07:26:37 Yup, sounds good to only block it for patches 2019-07-23 07:26:44 but it will still be difficult to review patches from different systems. 2019-07-23 07:27:11 yes 2019-07-23 07:27:28 we used to have send-email patches only previously, before github existed 2019-07-23 07:27:37 i think ddevault has some concerns about dkim or related 2019-07-23 07:27:42 and people had problems with it 2019-07-23 07:27:52 not everyone were able to submit patches 2019-07-23 07:28:25 gmail mangles the patches, inserts linebreaks and stuff 2019-07-23 07:28:47 so there was many people who were not able to participate with patches 2019-07-23 07:28:55 gmail as in just using its smtp server? 2019-07-23 07:28:58 yes 2019-07-23 07:29:09 wow i didnt know that 2019-07-23 07:29:19 basicly, gmail is useless for sending patches 2019-07-23 07:29:45 i think that is also a part of the reason wy github became popular 2019-07-23 07:30:18 basically, we cannot have emails as the only way to communicate 2019-07-23 07:30:24 and send patches 2019-07-23 07:32:02 git send-email bounces in a lot of networks I've used. A purchased account to allow sending email from consumer ISPs became a necessity a while back. 2019-07-23 07:37:55 package request: any gitlab cli (python-gitlab? lab?) 2019-07-23 07:39:58 npm install git-lab-cli -g 2019-07-23 07:40:00 ;-) 2019-07-23 07:56:34 ugh... 2019-07-23 08:47:27 ncopa: any chance you could take a look at the postgres user account patch we discussed yesterday https://github.com/alpinelinux/aports/pull/9627 2019-07-23 09:28:31 ncopa: thanks :) 2019-07-23 09:28:45 thank *you* :) 2019-07-23 09:29:18 ncopa: since you are here 2019-07-23 09:29:21 https://github.com/alpinelinux/mkinitfs/pull/55 2019-07-23 09:29:23 :-) 2019-07-23 09:29:25 hi 2019-07-23 09:29:36 O:3 2019-07-23 09:29:37 ah 2019-07-23 09:30:22 that is related to the impact of upgrading musl to 1.1.23 2019-07-23 09:31:23 tcely: thanks for helping with sequoia-sqv (and sorry for not fixing it myself) 2019-07-23 09:31:47 trixpan: i will have a look at it shortly. need to reboot 2019-07-23 09:40:31 re new release. It currently breaks bootstrap 2019-07-23 09:40:55 reason why I posted the version bump (otherwise we need to include the commit as a patch on aports) 2019-07-23 09:48:45 is there mod_wsgi for httpd for python3 ? 2019-07-23 09:49:22 Seems that https://pkgs.alpinelinux.org/package/v3.10/main/x86_64/apache2-mod-wsgi is for python2 2019-07-23 09:55:36 nmeum: regarding your question on github, pkgusers is for creating users during build-time so packages with proper ownership can be created, .pre-install/upgrade scripts create users before installation/upgrade of the package. so yes, pkgusers is still needed when creating users in pre-install/upgrade script unless packaging does not create/chown dirs/files with such owner. hope you won't be ever 2019-07-23 09:55:42 confused about them from now on. :) 2019-07-23 10:32:21 przemoc: right, thanks for the clarification :) 2019-07-23 10:40:20 ncopa: no problem. I wouldn't expect you to fix it yourself. 2019-07-23 11:08:45 This issue has many mentions :) https://gitlab.alpinelinux.org/alpine/aports/issues/1 2019-07-23 11:10:01 yeah i noticed it after running the migration a gazillion times. 2019-07-23 11:10:33 <_ikke_> lol 2019-07-23 11:11:25 i was not able to delete the label "Closed" because gitlab take too long time to respond, so im unlabeling lots of issues 2019-07-23 11:11:35 got the cli tool "lab" working 2019-07-23 11:43:28 can pr9483 get merged? 2019-07-23 11:44:58 The pdns-recursor devs may have fixed s390x in the next release. 2019-07-23 11:50:19 tcely: i can push the first commit, but i have doubrs about the other two commits 2019-07-23 11:51:03 tcely: btw... i wonder if you can help us think what labels we want for gitlab 2019-07-23 11:51:28 i think you have done a good job with our github, and i think it would benice if you could help us with the gitlab 2019-07-23 11:51:53 ncopa: please push the first commit 2019-07-23 11:52:01 ok. will do 2019-07-23 11:52:03 thanks 2019-07-23 11:52:28 somebody could write me down hos subscribe email should look in that "fall back" form for gmail which doesnt support "~" in email addresses? 2019-07-23 11:52:40 s/hos/how 2019-07-23 11:52:40 MY_R meant to say: somebody could write me down how subscribe email should look in that "fall back" form for gmail which doesnt support "~" in email addresses? 2019-07-23 11:53:13 ddevault: ^^^ 2019-07-23 11:53:17 The labels you want will depend on how you plan to use them. Do we have ideas for how GL will be automated anywhere? 2019-07-23 11:53:49 tcely: im open to ideas, but i dont have the full overview 2019-07-23 11:54:01 maybe we should take this in #alpine-infra 2019-07-23 11:54:18 ncopa, dont highlight him because he already told me to write to google mail... 2019-07-23 11:54:31 oh :) 2019-07-23 11:54:54 u.username.list-name@lists.sr.ht <-- that is example so how should look for alpine and what mean "username" ? 2019-07-23 11:56:08 should be u.alpine.alpine-announce@lists.alpinelinux.org or how else because there is too many assumption how that really should look 2019-07-23 11:57:42 u.alpine.announce@lists.alpinelinux.org or u.MYNAME.alpine-announce@ etc etc etc + not sure if lists.alpinelinux.org support that fall back and maybe should send to lists.sr.ht 2019-07-23 11:58:20 ah ye and forgot to add "+subscribe" to every 2019-07-23 12:02:31 alpine/announce+subscribe@ alpine/alpine-announce+subscribe@ MYNAME/alpine-announce+subscribe@ etc etc all return "550 The mailing list you 2019-07-23 12:02:32 requested does not exist." 2019-07-23 12:03:02 so gmail at least support "/" but for sure not "~" 2019-07-23 12:03:22 gmail does not support ~? 2019-07-23 12:03:34 no because I dont get any answer from ML at all 2019-07-23 12:03:56 or should write to them so they will dunno, unlock it for me? 2019-07-23 12:04:21 with "yandex" everything working just fine with ~ etc etc can subscribe even from their webmail 2019-07-23 12:05:33 and for gmail using text only mode (without html) on phone but have no idea how that address to subscribe can look 2019-07-23 12:06:39 MY_R: can you please create an issue in our bugtracker? 2019-07-23 12:06:52 cant you just use the old addresses? 2019-07-23 12:06:56 i want this problem tracked and recorded 2019-07-23 12:07:00 isnt there a rediect in place? 2019-07-23 12:07:09 should be 2019-07-23 12:07:28 clandmeter, I was subscribed to announce and didnt get any notification with new alpine 2019-07-23 12:08:15 i also see no information on how to subscribe 2019-07-23 12:08:50 ah the button 2019-07-23 12:09:11 saw on irc already few people was talking about all that and for me the only thing which is missing is that "proper" way to subscribe even if client doesnt support "~" 2019-07-23 12:09:11 but i can send to the list fine with the ~ address via gmail 2019-07-23 12:09:41 clandmeter, and I dont get any answer back when used that button 2019-07-23 12:09:50 maybe its gmail that automatically send html mails? 2019-07-23 12:10:17 clandmeter: where can we file and track bug reports for mailing list? 2019-07-23 12:10:25 tried with phone client and same 2019-07-23 12:10:26 infra 2019-07-23 12:10:35 phone wont work 2019-07-23 12:10:40 it will always use html 2019-07-23 12:10:47 K9 mail client? 2019-07-23 12:10:55 that i dont know 2019-07-23 12:10:57 never used it 2019-07-23 12:11:05 here? https://gitlab.alpinelinux.org/alpine/infra/infra 2019-07-23 12:11:25 https://gitlab.alpinelinux.org/alpine/infra/infra/issues 2019-07-23 12:11:27 I set up in options to not use any html but simple text 2019-07-23 12:11:44 ok and you send an email to the subscriiton address? 2019-07-23 12:11:48 and what happens? 2019-07-23 12:12:15 what address, that is the point because not sure how it have to look 2019-07-23 12:12:31 ~alpine/announce+subscribe@lists.alpinelinux.org 2019-07-23 12:12:39 that wont work at all, zero answer back 2019-07-23 12:13:00 ~alpine/announce+subscribe@lists.alpinelinux.org 2019-07-23 12:13:26 can you send an email to me clandmeter@alpinelinux.org 2019-07-23 12:13:39 or cc me 2019-07-23 12:13:39 sure, 1 sec 2019-07-23 12:13:44 when you subscribe 2019-07-23 12:15:26 ok received 2019-07-23 12:15:28 should be ok 2019-07-23 12:15:34 isnt html right? 2019-07-23 12:16:33 its text 2019-07-23 12:16:41 for sure address with "~" is ignored but there is some fall back way but ye, how? 2019-07-23 12:17:19 im sorry, i see the emails coming in from smtp, but i have no clue about the list 2019-07-23 12:17:24 please add an issue to the tracker 2019-07-23 12:17:29 on infra 2019-07-23 12:17:39 and we can ask ddevault what is going on 2019-07-23 12:18:00 https://man.sr.ht/lists.sr.ht/#posting 2019-07-23 12:18:07 Did you already try this? u.alpine/announce+subscribe@lists.alpinelinux.org 2019-07-23 12:18:29 ye wanted try but already sent too many of familiar, one sec 2019-07-23 12:18:51 MY_R: i see your emails coming in 2019-07-23 12:18:58 I know :) 2019-07-23 12:18:59 but i dont see the +subsribe in it 2019-07-23 12:19:14 so maybe + is ignored too 2019-07-23 12:19:44 can you use the offical address and send me cc? 2019-07-23 12:21:02 to:~alpine/announce+subscribe@lists.alpinelinux.org and cc:clandmeter@alpinelinux.org 2019-07-23 12:24:15 now done what tcely wrote and fwd to clandmeter, ah moment 2019-07-23 12:26:34 did you do what i asked you? 2019-07-23 12:26:45 ye one sec, sending 2019-07-23 12:28:12 clandmeter, ye done 2019-07-23 12:29:41 ok and still nothing right? 2019-07-23 12:30:00 zero 2019-07-23 12:30:09 please create a report here:" https://gitlab.alpinelinux.org/alpine/infra/infra/issues 2019-07-23 12:30:31 thanks for your patience 2019-07-23 12:31:04 After reading the page about mailing lists I am unsure which should work: u.alpine.announce+subscribe@lists.alpinelinux.org OR alpine/announce+subscribe@lists.alpinelinux.org 2019-07-23 12:31:22 well, I have working mail for that but prety sure many people will whine about it soon or later :\ 2019-07-23 12:31:45 tcely: there is a subscribe button, it should be the correct address. 2019-07-23 12:32:50 clandmeter: the alternative address and the subscribe and posting addresses all appear to differ 2019-07-23 12:33:34 tcely, none of them but ye is kind of too many options and tried most, and only in few cases didnt get respond at all and i other just error 550 that mailing list doesnt exist blabla 2019-07-23 12:34:14 it is obvious that is gmail issue but many people got them working with everything else just fine 2019-07-23 12:41:10 does it happen to me only? 2019-07-23 12:41:11 http://tpaste.us/ro4E 2019-07-23 12:41:35 lxc-create -n test -t alpine -- -r v3.10 --arch x86_64 2019-07-23 12:42:11 host is alpine 3.10.1 2019-07-23 12:46:13 you have internet connection? 2019-07-23 12:47:25 yes 2019-07-23 12:47:38 I'm connected to this host via internet :) 2019-07-23 12:47:48 check what the uris are 2019-07-23 12:47:53 not sure where it pulls it from 2019-07-23 12:48:11 does it use the /etc/apk/repositories ? 2019-07-23 12:48:20 it fetches the keys 2019-07-23 12:48:24 from somewhere 2019-07-23 12:48:46 yes 2019-07-23 12:49:00 wondering from where...or at least, where it's written from where get the keys 2019-07-23 12:49:14 it's lxc-create that fetches the key 2019-07-23 12:49:16 but it's binary 2019-07-23 12:49:22 umh 2019-07-23 12:49:25 http://alpinelinux.org/keys 2019-07-23 12:49:26 I can check the template 2019-07-23 12:49:49 umh.. 2019-07-23 12:49:59 wget http://alpinelinux.org/keys 2019-07-23 12:49:59 Connecting to alpinelinux.org (147.75.101.119:80) 2019-07-23 12:49:59 Connecting to alpinelinux.org (147.75.101.119:443) 2019-07-23 12:50:02 it 2019-07-23 12:50:08 it's stucked 2019-07-23 12:50:12 let me check the fw.. 2019-07-23 12:50:32 no lxd? :( 2019-07-23 12:50:44 lxd is in testing 2019-07-23 12:50:46 so edge 2019-07-23 12:51:05 well you can still use it, don't need to run edge 2019-07-23 12:51:18 I knw 2019-07-23 12:54:53 for some reason, 443 is filtered. 2019-07-23 12:55:42 morning 2019-07-23 12:55:44 what'd I miss? 2019-07-23 12:56:18 ok, fixed 2019-07-23 12:57:14 ddevault: ncopa & clandmeter are in favour of allowing HTML emails for the mailing lists 2019-07-23 12:58:47 bleh. can we limit that to alpine-user at least? 2019-07-23 12:59:13 bleh, I'm not good writer but maybe somebody else will have something to say or will give other gmail users correct address :D 2019-07-23 12:59:26 oh Hi ddevault :) 2019-07-23 12:59:29 https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10635 2019-07-23 12:59:52 ddevault: I think the point was to allow it everywhere but in the patch ML 2019-07-23 13:00:02 -1 to allowing it in -devel 2019-07-23 13:00:30 MY_R: check your spam folder? 2019-07-23 13:00:53 MY_R: you were subscribed successfully and the confirmation email went out, so it's probably a problem with smtp.alpine.pw 2019-07-23 13:00:56 ddevault: same. 2019-07-23 13:01:06 ddevault, spam is empty 2019-07-23 13:01:49 ddevault, but I sent many of different constructed emails so which one worked? 2019-07-23 13:02:57 I used yandex account with own domain and it working great but I'm talking about gmail account one so other users could use it too 2019-07-23 13:12:29 ddevault: where did the mail to to? 2019-07-23 13:12:37 confirmation email 2019-07-23 13:13:03 MY_R: all of them 2019-07-23 13:13:21 clandmeter: mynotbe@gmail.com at 2019-07-23 12:28:04,929 2019-07-23 13:17:17 ddevault, I sent 12 different and not all were recived probably by ML and most answered back with 550 :P 2019-07-23 13:17:45 you're subscribed. the issue is the follow-up email which tells you so 2019-07-23 13:19:42 ddevault, ye but this one worked "~alpine/announce+subscribe@lists.alpinelinux.org" or other one without "~" in address? 2019-07-23 13:19:57 you use either that, or u.alpine.announce+subscribe@lists.alpinelinux.org 2019-07-23 13:20:03 both work correctly 2019-07-23 13:20:07 and that what I wanted know! 2019-07-23 13:20:32 u.alpine.announce+subscribe@lists.alpinelinux.org 2019-07-23 13:20:39 i wonder if we should have that on the alpinelinux.org/community page, like we previously did 2019-07-23 13:21:27 it's a red herring 2019-07-23 13:21:33 MY_R uses gmail, ~ would have worked 2019-07-23 13:21:48 I've only ever seen 1 or 2 mail servers in the wild which get pissy with ~ 2019-07-23 13:22:12 ye but I tried with "~" week ago and didnt work 2019-07-23 13:22:18 it worked yo 2019-07-23 13:22:28 ah? 2019-07-23 13:22:33 so ok 2019-07-23 13:22:48 the issue is that confirmation emails don't get delivered because smtp.alpine.pw isn't set up to deliver emails reliably 2019-07-23 13:22:53 thought you showed me date of registration few messages above 2019-07-23 13:23:06 that was the date of your last attempt 2019-07-23 13:24:07 ok, so all fine, just need fix that confirmation but why the hell gmail got problem with it :\ 2019-07-23 13:24:20 outgoing mails aren't DKIM signed, and they ought to be 2019-07-23 13:24:27 but I can't fix that, someone who can access the mail server needs to set it up 2019-07-23 13:24:35 I got yandexown domain with DKIM 2019-07-23 13:24:44 and ye worked fine 2019-07-23 13:25:03 so now all is clear :) 2019-07-23 13:25:56 ncopa: clandmeter: regarding allowing HTML emails, can we compromise by leaving it disabled on the aports and devel lists 2019-07-23 13:26:26 why do we need to compromise here? 2019-07-23 13:26:48 because I don't want to get HTML emails in my inbox and I'm subscribed to these lists 2019-07-23 13:26:57 +1 for having it disabled on aports list 2019-07-23 13:27:13 why not devel as well? 2019-07-23 13:27:15 i like to be able to answer to mails on my phone 2019-07-23 13:27:21 but devel list 2019-07-23 13:27:22 without installing another app 2019-07-23 13:27:31 lists i can live with 2019-07-23 13:27:32 well I'd like a million dollars 2019-07-23 13:27:35 err patches 2019-07-23 13:27:47 without doing any work for it 2019-07-23 13:27:49 ¯\_(ツ)_/¯ 2019-07-23 13:27:51 i dont think we want use html mails as gate keeper 2019-07-23 13:28:08 keeping the people who cannot disable html mails out 2019-07-23 13:28:10 ddevault: smtp does sign dkim 2019-07-23 13:28:13 I'm willing to help anyone who uses HTML email get set up for plaintext instead 2019-07-23 13:28:16 clandmeter: it does not 2019-07-23 13:28:17 i think people sending mails to patches and devel should be able to configure their mua accordingly 2019-07-23 13:28:22 ddevault: it does 2019-07-23 13:28:29 just not for lists 2019-07-23 13:28:29 <_ikke_> ddevault: the problem is most people don't even bother to investigate 2019-07-23 13:28:34 cause somebody removed the filter 2019-07-23 13:28:35 <_ikke_> ddevault: they just stay away 2019-07-23 13:28:36 clandmeter: you're getting on my nerves man 2019-07-23 13:28:52 _ikke_: I can improve the rejection email to make it easier to parse 2019-07-23 13:28:53 ddevault: sorry if you dont want to discuss this issue. 2019-07-23 13:28:56 there may be various reasons why a user cannot or dont want disable html mails 2019-07-23 13:29:16 or may not be able to replace email software 2019-07-23 13:29:19 but you are not giving me any time to explain the issue here. 2019-07-23 13:29:28 ncopa: I mean, there may be various reasons why an admin can't disable their open relay, but we still blacklist their IP 2019-07-23 13:29:45 for example in enterprise environments 2019-07-23 13:29:47 _ikke_: you changed something on smtp right? 2019-07-23 13:29:52 <_ikke_> clandmeter: yes 2019-07-23 13:29:53 to trust lists 2019-07-23 13:29:54 sending HTML email by mistake -> no problem, I can help you fix that 2019-07-23 13:30:02 sending HTML email because you refuse not to -> not welcome in my inbox 2019-07-23 13:30:22 btw forgive my misunderstanding ddevault and I'm glad that all cleared out, at least I have got extra mailbox working thanks to yandex :D 2019-07-23 13:30:26 in an enterprise environment they should talk to their sysadmin 2019-07-23 13:30:30 <_ikke_> ddevault: but are you to make that decission for Alpine? 2019-07-23 13:30:36 <_ikke_> for everyone? 2019-07-23 13:30:38 ddevault: so you think we should use it as gate keeper to keep some people out 2019-07-23 13:30:41 ddevault: cant you just filter them out locally? 2019-07-23 13:30:49 plaintext emails are more secure, the admin shouldn't care 2019-07-23 13:31:01 ncopa: not necessarily 2019-07-23 13:31:06 clandmeter: no, because then I miss discussions 2019-07-23 13:31:22 <_ikke_> ddevault: You will miss them either way 2019-07-23 13:31:30 clandmeter: also the lists.sr.ht web archive is not prepared to show HTML emails, and I refuse to add it as it presents a severe security risk 2019-07-23 13:31:35 so you want to force users to send text so you can follow the discussion 2019-07-23 13:31:42 <_ikke_> ddevault: it can just show it plain-text 2019-07-23 13:31:42 _ikke_: I will not miss emails from users who are taught how to correct the problem 2019-07-23 13:31:52 okay, this isn't working 2019-07-23 13:31:57 I can't argue with all of you at once 2019-07-23 13:32:03 I will write up a letter to the infra list 2019-07-23 13:32:08 sounds good 2019-07-23 13:32:09 <_ikke_> ddevault: You expect 100% people comitted to change the way to send e-mails 2019-07-23 13:32:10 +1 2019-07-23 13:32:36 _ikke_: the problem now is that rspamd doesnt kick in, which applies sec features. 2019-07-23 13:32:40 I'm bang in the middle of moving to a new apartment, so I can't promise to address it soon 2019-07-23 13:32:47 <_ikke_> clandmeter: Ok, didn't know that 2019-07-23 13:32:53 me neither 2019-07-23 13:32:59 well i did know rspamd does it 2019-07-23 13:33:30 at least i think this is the issue 2019-07-23 13:37:23 ddevault: FYI, the bounce message is not displaying in Gmail app on Android too. http://k00.fr/e0usualf 2019-07-23 13:37:38 _ikke_: do you remember why you changed the config? 2019-07-23 13:37:49 tcely: this email is written by postfix 2019-07-23 13:38:00 <_ikke_> clandmeter: mails originating from listserv were greylisted 2019-07-23 13:38:08 ok 2019-07-23 13:38:20 ill switch this to infra 2019-07-23 13:39:27 tcely, maybe it have something to do with gmail "problem" with which clandmeter fighting hard :) 2019-07-23 13:43:00 ah ye and sorry people for my noise and bad english :> 2019-07-23 15:10:53 although I dislike HTML mail I think we should allow it for ML's, except aports 2019-07-23 15:11:33 everyone's english is bad, no worries 2019-07-23 15:14:23 :D 2019-07-23 15:20:40 I'm not big fan of html mails too but worst are all those applications and webmails which making from simple pure text a damn "web page" :\ 2019-07-23 15:49:29 Can someone please merge pr9319? 2019-07-23 16:07:45 it is in main D: 2019-07-23 16:08:02 Yup... 2019-07-23 16:08:55 <_ikke_> I'll look at it in a second 2019-07-23 16:23:39 hola folks 2019-07-23 16:23:56 can anyone please throw some light on how to use alpine itself to build a glibc iso.. 2019-07-23 16:24:04 i am trying to use chroot in debian 2019-07-23 16:24:14 able to compile abuild and apk-tools 2019-07-23 16:24:43 however The package alpine-base depends on [alpine-baselayout, alpine-conf, apk-tools, busybox, busybox-suid, busybox-initscripts openrc, libc-utils, alpine-keys] 2019-07-23 16:25:34 and when i try to abuild baselayout it doesnt work and there are no make files as well to just compile it 2019-07-23 16:25:35 want to do alpine that has only glibc and not musl? 2019-07-23 16:25:40 yes 2019-07-23 16:26:28 i dont want to use an musl alpine to build a glibc version least it should contaminate it 2019-07-23 16:26:29 you need to crawl through all build files to remove musl stuff 2019-07-23 16:26:40 i am doing that 2019-07-23 16:26:43 for example 2019-07-23 16:27:13 https://git.alpinelinux.org/alpine-baselayout/tree/ 2019-07-23 16:27:21 this really doesnt depend on musl 2019-07-23 16:27:30 however abuild refuses to compile it 2019-07-23 16:27:45 it will not be a trivial task 2019-07-23 16:28:13 any ideas that i could try out? 2019-07-23 16:29:36 busybox compiles fine....i just need some basic utils to do a bare boot of glibc alpine 2019-07-23 16:29:44 and i am struck there 2019-07-23 16:30:46 alpine is the only distro in the world that is near perfect however deep learning frameworks like caffe, tensorflow 2019-07-23 16:30:51 require glibc 2019-07-23 16:31:14 not just glibc binaries but a distro based on it 2019-07-23 16:31:24 for them to properly function 2019-07-23 16:31:37 guys just throw in some ideas that i can try 2019-07-23 16:32:49 whats the first package alpine looks for in addition to abuild and apk-tools 2019-07-23 16:32:52 while booting? 2019-07-23 16:33:40 is this the base? 2019-07-23 16:33:41 https://git.alpinelinux.org/aports/tree/main/alpine-baselayout/APKBUILD 2019-07-23 16:33:50 the first package i mean? 2019-07-23 16:33:52 well it is openrc init system 2019-07-23 16:34:28 yes i know 2019-07-23 16:35:22 ncopa 2019-07-23 16:35:25 any ideas? 2019-07-23 16:36:25 <_ikke_> Did you package glibc already? 2019-07-23 16:37:39 no not yet....I just setup a chroot of debian, downloaded the source of abuild and apk-tools and compiled them successfully.... 2019-07-23 16:38:10 and using the above said compiled binaries, when i try to download the alpine-baseconf package and compile...it doesnt 2019-07-23 16:38:38 it was something that CLIBC variable is used to determine what libc is used... and that needs to be packaged 2019-07-23 16:38:47 aha 2019-07-23 16:39:07 i have a glibc available 2019-07-23 16:39:22 in my debian chroot 2019-07-23 16:39:25 so first you create glibc package and make glibc-dev sub package... 2019-07-23 16:39:42 using abuild? 2019-07-23 16:39:46 yah 2019-07-23 16:39:54 aaaaaaah! 2019-07-23 16:40:04 so i need an alpine chroot then 2019-07-23 16:40:28 isnt it? 2019-07-23 16:40:40 yeah, to run abuild 2019-07-23 16:41:24 this is hard, an alpine chroot that doesnt actually have musl and which is just enough to start building a glibc 2019-07-23 16:41:46 well you make that after you've built packages 2019-07-23 16:42:00 using your build dir as repo 2019-07-23 16:42:19 perfect 2019-07-23 16:42:20 but 2019-07-23 16:42:23 in here 2019-07-23 16:42:24 https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot 2019-07-23 16:42:34 apk.static -X /your/built/packages/that/use/glibc/ 2019-07-23 16:42:59 Install the alpine base installation onto the chroot./sbin/apk.static -X ${mirror}/latest-stable/main -U --allow-untrusted --root ${chroot_dir} --initdb add alpine-base 2019-07-23 16:43:06 wont i need the alpine-base? 2019-07-23 16:43:21 yes, and you'll build that using alpine chroot and abuild 2019-07-23 16:43:53 musl alpine chroot is just for building for now 2019-07-23 16:44:35 but wont it contaminate the glibc builds? 2019-07-23 16:44:59 no 2019-07-23 16:45:24 alrite let me fire up right up right away 2019-07-23 16:46:00 start building that glibc package and then you'll build everything using that as dependency 2019-07-23 16:46:17 correct 2019-07-23 16:49:03 so you check first that alpine-base is metapackage, check that what it is installing, build those packages (and edit their APKBUILD to use your glibc packages) 2019-07-23 16:49:57 libc-utils namely is the one that you'll need to point to your glibc 2019-07-23 16:51:33 okie let me document these so that it will be useful for others and i can put in the alpine wiki pages 2019-07-23 16:53:11 1. wget http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86_64/apk-tools-static-2.10.4-r2.apk2. tar -xzf apk-tools-static-*.apk 2019-07-23 16:53:17 sorry 2019-07-23 16:53:30 STEP-1. wget http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86_64/apk-tools-static-2.10.4-r2.apk 2019-07-23 16:53:42 STEP-2. tar -xzf apk-tools-static-*.apk 2019-07-23 16:54:05 rather use paste service that flooding channel =) 2019-07-23 16:55:51 in the end, starting with https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot is the first thing, then cloning the aports repo is the next one, then editing needed APKBUILD is next one 2019-07-23 16:56:26 oops sorry i will use the paste service 2019-07-23 16:56:53 fork the abuild repo, and give people access to your modifications, might be that someone will give you PR and help you on your quest 2019-07-23 16:59:00 sure 2019-07-23 16:59:07 i will sit and try now 2019-07-23 17:00:54 what's wrong with ML system. I posted reply to ~alpine/devel@lists.alpinelinux.org, server accepted mail but mail doesn't resent back to me. Do I need to resubscribe to sr.ht or somewhere else 2019-07-23 17:02:25 mps, gmail? :P 2019-07-23 17:03:34 no, mutt and postfix 2019-07-23 17:03:54 <_ikke_> I did receive your e-mail 2019-07-23 17:03:57 not a HTML mail ;) 2019-07-23 17:05:08 hmm, why then it is not resent to me? I presume I'm subscribed because I receive mails from other people to this list 2019-07-23 17:05:56 I think "they" working on it because I reported same 2019-07-23 17:06:19 "they" is ddevault, I think 2019-07-23 17:06:40 not so sure, ask clandmeter 2019-07-23 17:07:50 hmmm, I expected that move to sr.ht will be change to something better 2019-07-23 17:11:38 mps: mails are not sent back to you 2019-07-23 17:11:40 this is by design 2019-07-23 17:12:54 ddevault: please revert design 2019-07-23 17:13:21 ah it wasnt about subscription but resent ok ok me going to corner and shut the hell up.... sorry! 2019-07-23 17:13:40 have a nice day people! :D 2019-07-23 17:14:06 MY_R: :D 2019-07-23 17:15:05 mps: you don't get your reply copied back to you when you email anyone else 2019-07-23 17:15:13 mps: copy sent messages to your sent folder 2019-07-23 17:16:03 if you just want to know your messages got there, you can read them on the archives: 2019-07-23 17:16:04 https://lists.alpinelinux.org/~alpine/devel/%3C1c2e99a3-4995-296d-b6e1-6fbad8261ab8%40schinagl.nl%3E 2019-07-23 17:16:19 ddevault: I know that, but I expected that move to sr.ht will 'replicate' previous ML system behavior 2019-07-23 17:16:29 much of the previous ML system's behavior was broken 2019-07-23 17:16:37 fixing these problems was part of the motivation for the move 2019-07-23 17:16:44 it was never going to be 1:1 2019-07-23 17:17:10 so, I have to fire up browser to check if my mail arrived. That is bad, imo 2019-07-23 17:17:19 or you can just trust that your mail arrived 2019-07-23 17:17:26 like you do with every other recipient you send mail to 2019-07-23 17:18:15 I'm subscribed to a lot of ML's and on every of them I receive back my posts 2019-07-23 17:18:52 and, that was also on Alpine till switch to sr.ht ML system 2019-07-23 17:19:03 I consider this a bug in other mailing lists 2019-07-23 17:19:55 hmmm, such changes should be discussed somewhere before implementation 2019-07-23 17:20:05 the switch to lists.sr.ht was discussed in great detail 2019-07-23 17:20:11 give it some time to get used to 2019-07-23 17:20:47 hmmm :-( 2019-07-23 17:21:43 a great deal of thought has gone into its design, give it a chance 2019-07-23 17:22:00 it's different, yes, but in deliberately thought out ways 2019-07-23 17:23:37 ddevault: although I agree with most of your (somewhat rigid ideas for other people) I think changes should be announced first and after some time implemented, gradually maybe 2019-07-23 17:23:59 at some point we've got to rip off the band-aid 2019-07-23 17:24:12 expecting me to reimplement mlmmj bug-for-bug and gradually replace it with a working system is unreasonable 2019-07-23 17:26:01 I'm far from expert in ML software software, but 'resend back to poster' (maybe all subscribers) doesn't look to complicated for you to implement, according to my talks with you ;-) 2019-07-23 17:26:25 it's not complicated 2019-07-23 17:26:32 in fact, implementing it would only involve removing lines of code 2019-07-23 17:26:36 like I said, it's by design 2019-07-23 17:27:35 ok, don't feel offended by my words. maybe others have to say something about that 2019-07-23 17:29:08 before shut up I have only to add this: I would prefer some feedback that my post arrived to ML, and not looking to web page 2019-07-23 17:29:34 sounds more like repetition than addition 2019-07-23 17:30:44 'repeticium est mater studiorum' 2019-07-23 17:31:04 repetitio* 2019-07-23 17:31:14 <_ikke_> ddevault: I suppose I cannot prevent e-mails to be sent to the account I signed up with at meta.a.o? (I'm already subscribed with another address) 2019-07-23 17:31:28 _ikke_: I don't understand the question 2019-07-23 17:31:34 oh, I see what you mean 2019-07-23 17:31:48 old Latin 2019-07-23 17:31:51 you can just unsubscribe from the web or with the email you don't want to receive emails to, or change the email on meta.a.o 2019-07-23 17:32:07 Why not make it a feature? 2019-07-23 17:32:17 Receiving a copy 2019-07-23 17:32:18 <_ikke_> I have a dedicated e-mail address for mailing lists 2019-07-23 17:32:23 clandmeter: I may in the future, but not soon 2019-07-23 17:33:14 _ikke_: gotcha. lmk if that works for you, I'll rejiggle things manually if you need 2019-07-23 17:44:55 ooh my god! 2019-07-23 17:44:59 Glibc depends on: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo. 2019-07-23 17:45:18 so i have to now compile all those before compiling glibc 2019-07-23 17:45:24 without musl 2019-07-23 17:45:29 phew! 2019-07-23 17:45:34 life sucks! 2019-07-23 17:45:52 oneinsect: no, glibc sucks 2019-07-23 17:45:54 <_ikke_> That's what it means to bootstrap something 2019-07-23 17:46:23 forgot to add ';-)' 2019-07-23 17:46:36 lol 2019-07-23 17:47:40 btw, I'm still out of my working machine, do we upgraded to musl 1.23 2019-07-23 17:48:16 <_ikke_> pkgs.a.o lists musl 1.1.23 :) 2019-07-23 17:49:11 yes we did 2019-07-23 17:49:43 _ikke_: yes, 1.1.23 and not 1.23 ofc 2019-07-23 17:50:07 yes, 1.1.23 2019-07-23 17:50:58 thanks for info, seems 1.1.23 is 'interesting' 2019-07-23 18:10:06 <_ikke_> PureTryOut[m]: ping 2019-07-23 18:11:31 Pong, at dinner in restaurant though lol 2019-07-23 18:16:23 dinner alone 2019-07-23 18:18:49 No, I'm being asocial atm lol 2019-07-23 18:21:50 is anybody running alpine with runit, any comments? 2019-07-23 18:22:59 KH405: yes, not as init 1 but runs fine 2019-07-23 18:23:17 I will be kind and I wish you bon appetit PureTryOut[m] ! :) 2019-07-23 18:23:33 As what then mps ? 2019-07-23 18:24:18 runs from /etc/init.d/runitd 2019-07-23 18:24:50 as supervisor for some 'things' I need 2019-07-23 18:24:58 Ohhh, okay. I was just asking cause apparently OpenRC runs weird with superviors ... 2019-07-23 18:25:43 yes, openrc is weird for supervising, because that I use runit 2019-07-23 18:26:11 Would you recommend dropping openRC all the way amnd run ruinit with S6 ? 2019-07-23 18:27:46 ACTION prefers s6 to runit 2019-07-23 18:28:18 but i also only run it as non-pid1 2019-07-23 18:28:22 I don't know S6 at all, but heard good things about it. But it's not a init system by itself right ? 2019-07-23 18:28:44 it is, as good (or even better) as runit 2019-07-23 18:30:34 Then would you recommend dropping OpenRC and try S6? 2019-07-23 18:31:42 If you're OK with getting your own services/writing them 2019-07-23 18:32:06 s6-rc is kinda clunky and hard to get into at first, I personally like 66 more 2019-07-23 18:32:17 afaik, s6 is not intended to be init 1 2019-07-23 18:33:36 KH405: void linux uses runit as init 1, but we should move to #alpine-linux. this is development channel 2019-07-23 18:33:49 You're right, sorry! 2019-07-23 18:55:42 Cogitri I can't find info on 66, do you have a link on where to start? 2019-07-23 18:56:41 _ikke_: I'm available now, what's up? 2019-07-23 19:05:35 KH405: https://web.obarun.org/software/ 2019-07-23 19:15:26 <_ikke_> PureTryOut[m]: the libdrm change, does that have any impact? 2019-07-23 19:17:53 Besides on tegra and etnaviv platforms? No, shouldn't be. The Meson configuration is the exact same as the autotools one. z3ntu can answer that question better though 2019-07-23 19:18:02 <_ikke_> ok 2019-07-23 19:18:14 Although Meson and Ninja removes the need to manually create the builddir 2019-07-23 19:18:26 <_ikke_> And no issues with dependencies? 2019-07-23 19:18:29 Which this PR doesn't make use of 2019-07-23 19:18:53 What do you mean? 2019-07-23 19:19:00 <_ikke_> reverse dependencies I mean 2019-07-23 19:19:21 <_ikke_> let me check the build output 2019-07-23 19:19:32 I didn't break anything on purpose at least ;) 2019-07-23 19:20:28 <_ikke_> I only see new sonames, so that should be alright 2019-07-23 19:21:47 <_ikke_> (I'm like to at least have an idea about what I'm pushing) 2019-07-23 19:23:16 <_ikke_> pushed 2019-07-23 19:24:06 BTW, do we purge libtool archives (.la files)? 2019-07-23 19:24:18 _ikke_: thanks! 2019-07-23 19:25:00 Then as a follow up I'd like pr9287 to be reviewed 😃 2019-07-23 19:25:10 <_ikke_> heh 2019-07-23 19:25:12 I'll restart the CI 2019-07-23 19:51:08 It passed CI 2019-07-23 20:19:35 ncopa: would you mind if I upgrade sndio to 1.6.0, you are maintainer 2019-07-23 20:20:16 tested build on x86_64, armv7 and aarch64 2019-07-23 20:58:49 Updated my libtasn1 PRs to do security upgrade to 4.14 instead of backporting a patch, except for 3.7 that is in 4.12 (others are on 4.13) 2019-07-23 20:59:00 pr9599 through pr9602 2019-07-24 03:38:37 lol are we actually 'plaintext certifying' email clients now 2019-07-24 03:39:06 ddevault: but an image isnt plain text? how can you possibly commit such a sin 2019-07-24 03:49:19 let's keep the topic to #alpine-offtopic please? I have a feeling it could get lengthy 2019-07-24 03:59:58 eh i feel like someone who got veto privs due to a previous power vacuum gatekeeping contributors based on their choice of email client doesn't really fall under offtopic 2019-07-24 04:00:06 But I'm happy to move it there if you disagree with that 2019-07-24 04:10:02 Good evening. How would one go about including a set of files in the fakeroot filesystem during iso build using aports? 2019-07-24 07:41:15 ncopa can you look at libtasn1 security upgrades ? from pr9598 to pr9602 2019-07-24 07:54:44 maxice8: will do 2019-07-24 08:09:26 Has anyone tried to build podman on Alpine? 2019-07-24 08:10:29 I did but I threw the apkbuild away a while ago, you're free to use me as a rubber duck if you hit a wall 2019-07-24 08:13:22 Thanks danieli ! 2019-07-24 08:30:41 danieli was there any caveats I should be aware of? 2019-07-24 08:30:57 not that I can recall off the top of my head, but my short term memory can be fuzzy 2019-07-24 09:02:42 ncopa: have you seen my msg from last night? i.e. "would you mind if I upgrade sndio to 1.6.0, you are maintainer" 2019-07-24 09:06:54 mps: maybe i did, but i have forgotten it :) 2019-07-24 09:07:16 mps: i dont mind you updating it 2019-07-24 09:07:35 I tested build on x86_64, armv7 and aarch64, and thinking to move it to community 2019-07-24 09:08:09 so, the some packages could be built with it, or tried at least 2019-07-24 09:08:38 I have mpv and firefox-esr in mind for now 2019-07-24 09:13:30 pushed sndio, and it pass builds. what you think about moving it to community? 2019-07-24 09:20:51 hmm, looks like you also don't mind about moving :-) I will move it later 2019-07-24 09:23:22 btw, can we use gitlab MR's now 2019-07-24 09:25:40 I second that question, unsure where to make PR/MRs now 2019-07-24 09:37:27 <_ikke_> terror_: haven't tried it, would be nice to have 2019-07-24 09:53:33 mps: can you try make a MR? 2019-07-24 09:54:48 yes, i think MRs should work at this point 2019-07-24 09:54:52 there is no CI though 2019-07-24 09:54:55 yet 2019-07-24 09:55:20 <_ikke_> I don't think we do MRs for aports yet, do we? 2019-07-24 09:55:41 we already got a couple 2019-07-24 09:55:51 we need to make it work at some point 2019-07-24 09:56:13 things that probably dont work is autoclose 2019-07-24 09:56:29 I'm not sure it is good to make MR without testing build first 2019-07-24 09:57:01 mps: MR at this point is equivalent to sending patch to mailing list 2019-07-24 09:57:09 anyway will try build locally and if it is ok then could try make MR 2019-07-24 09:57:14 sounds good 2019-07-24 09:58:48 would be nice if someone who is experienced in GL workflow make short 'Alpine gitlab development guide' 2019-07-24 10:00:48 <_ikke_> explaining what exactly? 2019-07-24 10:02:37 something about https://docs.gitlab.com/ce/user/project/merge_requests/ but with Alpine aports examples 2019-07-24 10:05:44 it should be trivial to add x86_64 builder for MR's 2019-07-24 10:06:27 _ikke_: do you want to look into converting the current drone pipeline into gitlab-ci? 2019-07-24 10:13:55 just had an internet disconnect, seems i wasn't the only one. 2019-07-24 10:22:28 <_ikke_> clandmeter: yes, that's exactly what I was planning to do 2019-07-24 10:36:31 What is the process to mass-disown all the packages you maintain? 2019-07-24 10:37:42 <_ikke_> I guess send a pull request / patch series doing that 2019-07-24 10:38:26 will a github pull request be sufficient? I can't use the mailing lists with my preferred MUA (iOS Mail) 2019-07-24 10:38:36 <_ikke_> sure 2019-07-24 10:59:33 oof 2019-07-24 10:59:34 another one 2019-07-24 11:25:42 Cadey: what stops iOS Mail from working? I was going to try macOS Mail at some point. The ML is just too much trouble if I can't respond from my mobile. 2019-07-24 11:26:16 <_ikke_> The new mailing list software blocks any e-mail that contains an html part 2019-07-24 11:27:25 iOS mail doesn't let you control when you're sending HTML mail. It does send a plaintext part though, the fact that there's an html part is what kills it. 2019-07-24 11:27:31 its frustrating 2019-07-24 11:28:12 That's horrible! I had thought having a text part meant it would be accepted. 2019-07-24 11:35:46 _ikke_: atools 17.2 is out 2019-07-24 11:37:04 <_ikke_> maxice8: ok, good to know 2019-07-24 11:37:14 <_ikke_> (I am subscribed to releases from atools) 2019-07-24 11:46:41 Do you know if bats' `run` command empty the environment ? 2019-07-24 11:47:39 <_ikke_> No, not from the top of my head 2019-07-24 11:53:28 ok found out 2019-07-24 11:53:38 <_ikke_> and? 2019-07-24 11:59:22 Yes it is no 2019-07-24 11:59:28 BTW 18 is out 2019-07-24 11:59:56 <_ikke_> That's fast :P 2019-07-24 14:28:29 ncopa: (et all) https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3 2019-07-24 14:29:18 comments are welcome, this is my first real MR 2019-07-24 14:30:00 <_ikke_> Time for me to setup CI for merge requests 2019-07-24 14:32:18 I made it just using web UI (hi Cogitri :-) ). After this experience next thing will be to investigate come CLI tools for these works 2019-07-24 14:32:47 <_ikke_> Prepare to dive in the world of node / npm 2019-07-24 14:33:01 <_ikke_> Apparently most existing tools are writtin in node 2019-07-24 14:33:28 mps: you're lucky, i might have the CLI tool for you 2019-07-24 14:33:55 already looked at some in pyrhon, but forgot url, it is on GH somewhere 2019-07-24 14:34:23 mps: there is Hub for GitHub and i'm trying to package Lab which is the same but for GitLab 2019-07-24 14:34:26 maxice8: :-) 'I feel lucky' 2019-07-24 14:36:08 mps: Nice work :P 2019-07-24 14:36:38 Cogitri: thanks :P 2019-07-24 14:38:40 if this workflow shows as good enough I will stop posting patches by ML, probably 2019-07-24 14:39:18 _ikke_: Hub is written in go 2019-07-24 14:39:26 Neat 2019-07-24 14:42:57 hey, does "ulimit -p" option exist? 2019-07-24 14:48:47 if no then that patch can be removed or my system is weird :P https://git.alpinelinux.org/aports/tree/community/docker/docker-openrc-busybox-ash.patch 2019-07-24 14:49:06 and docker service stop/start return: ulimit: unrecognized option: p 2019-07-24 14:52:13 ah ye in "ash" there is no -p but it is in bash... so dunno 2019-07-24 15:40:51 MY_R: i think it is the recent busybox update that introduced it 2019-07-24 15:41:06 MY_R: can you please file an issue on gitlab.a.o so we dont forget it? 2019-07-24 15:41:31 ncopa, ye I was suprised that didnt notice it after docker update but after today updates 2019-07-24 15:41:47 so I wasnt sure what is going on, ok 2019-07-24 15:43:40 https://git.busybox.net/busybox/commit/?id=a92a9601f89d59597b268e29e7098597a8766778 2019-07-24 15:43:45 upstream seems to have renamed -p to -u 2019-07-24 15:44:13 ah ye on 3.10 got -p but no -u 2019-07-24 15:44:48 I would suggest simply removing that docker patch 2019-07-24 15:48:59 probably a good idea yes 2019-07-24 16:03:11 what do you ppl think about this CODESTYLE.md doc? https://tpaste.us/4ypl 2019-07-24 16:05:03 I think we should merge that with what SpaceToast has been working on 2019-07-24 16:06:39 Also, I like Void's Manual.md https://github.com/void-linux/void-packages/blob/master/Manual.md 2019-07-24 16:07:35 ncopa MY_R: just pushed a faix for docker 2019-07-24 16:07:37 *fix 2019-07-24 16:08:12 great, thank you :) so somebody can close the issue 2019-07-24 16:08:23 oh, didn't know there was one 2019-07-24 16:09:00 ncopa: re styleguide: personally don't think that that's specific enough, would rather have a detailed documented like the void linux manual 2019-07-24 16:10:05 Did anyone ever fix the sources= thing where -static needed to be specified before -dev to keep -dev from eating up the static archives? 2019-07-24 16:10:13 nmeum, ncopa wanted to have issue to not forget about it :) 2019-07-24 16:10:17 If not, the sorting advice will cause lots of failure conditions. 2019-07-24 16:11:00 local keyword is undefined behavior in POSIX sh, but the shebangs are still /bin/sh; since we use ash it shouldn't be a big problem, but something to note 2019-07-24 16:11:02 ncopa: I think that is neat and detailed enough. Explaination of eval deprecation would be cool :) 2019-07-24 16:11:19 MY_R: yeah, thanks for creating one. i just closed it 2019-07-24 16:11:29 Search/replace isn't clear - maybe specify the difference between single and double /s? 2019-07-24 16:11:47 nmeum :) 2019-07-24 16:11:52 nmeum: yes, there is still missing things. but its a start 2019-07-24 16:11:54 SpaceToast: Maxice8 has had a PR open for some time now to fix the -static thing but it hasn't been merged yet afaik 2019-07-24 16:12:25 Quoting rules aren't really "complete" but a good starting point 2019-07-24 16:12:35 That's all I've got though :) 2019-07-24 16:12:43 Thanks Cogitri 2019-07-24 16:13:16 ncopa: definitly 2019-07-24 16:15:10 SpaceToast: Actually nevermind, should work now: https://github.com/alpinelinux/abuild/pull/72 2019-07-24 16:15:14 Seems like it has been merged during my holidays :) 2019-07-24 16:15:25 its not pushed to aports yet though 2019-07-24 16:15:36 i have more work planned for abuild 2019-07-24 16:15:45 before i tag new release 2019-07-24 16:19:20 ok, im gonna push it, with the variable expanstion thing removed 2019-07-24 16:19:40 <_ikke_> What variable expansion thing? 2019-07-24 16:20:04 ${var/search/replace} 2019-07-24 16:20:48 <_ikke_> oh, regarding codestyle? 2019-07-24 16:20:56 yes 2019-07-24 16:21:07 <_ikke_> Was still thinking you were talking about abuild 2019-07-24 16:21:18 no, im multitasking :) 2019-07-24 16:21:40 should we call the doe CODESTYLE.md, CODINGSTYLE.md or STYLE.md? 2019-07-24 16:24:03 ncopa: I think variable expansion should be there... isnt that a posix behavior? Are you removing that because of enhanching readability? 2019-07-24 16:24:30 im removing ti because i want to push it today 2019-07-24 16:24:49 in other words, remove the controversial parts 2019-07-24 16:25:02 Yeah... I agree to that 2019-07-24 16:25:12 STYLEGUIDE.md ? 2019-07-24 16:25:19 :D 2019-07-24 16:25:39 MY_R: i was hoping to reduce the number of options :) 2019-07-24 16:25:45 hehe 2019-07-24 16:25:58 but hey even can find it on wiki like that: https://en.wikipedia.org/wiki/Style_guide 2019-07-24 16:25:59 [WIKIPEDIA] Style guide | "A style guide or manual of style is a set of standards for the writing, formatting and design of documents. It is often called a style sheet, although that term may have other meanings. These standards can be applied either for general use, or be required usage for an individual publication, a particular..." 2019-07-24 16:26:00 ncopa: KISS :)) 2019-07-24 16:28:55 or even better: APKBUILDGUIDE.md :D look at examples http://google.github.io/styleguide/ 2019-07-24 16:29:24 i think we will have a more extensive developers handbook 2019-07-24 16:30:36 pushed 2019-07-24 16:31:10 https://gitlab.alpinelinux.org/alpine/aports/blob/master/CODINGSTYLE.md 2019-07-24 16:32:07 mps: you had to pick a complicated PR :) 2019-07-24 16:33:42 errn0: ${parameter/pattern/string} expansion is not POSIX. 2019-07-24 16:34:03 unfortunately it is used in APKBUILDs 2019-07-24 16:34:11 <_ikke_> local is also not POSIX 2019-07-24 16:34:30 those are the two exceptions that i have accepted 2019-07-24 16:34:57 but local is commonly agreed necessary expansion over POSIX, thus supported practically everywhere 2019-07-24 16:36:09 its difficult to implement ${var/parameter/string} in pure posix 2019-07-24 16:36:36 we will have to use temp vars and 2-3 lines for each use 2019-07-24 16:36:37 <_ikke_> Without reverting to sed or similar 2019-07-24 16:36:51 we dont want fork in global scope 2019-07-24 16:36:59 <_ikke_> No, I agree 2019-07-24 16:37:59 <_ikke_> tools that source lots of APKBUILDs will suddenly take a lot more time as you've shown 2019-07-24 16:41:22 I just asked SpaceToast about the user handbook, and it seems to be ready for go official. Would be good with volunteers to read it though. http://docs.alpinelinux.org/user-handbook/0.1a/index.html 2019-07-24 16:42:31 its not expected to be perfect, but good enough to be official 2019-07-24 16:43:09 if you have any actionable concerns, patches (and discussion around them) is welcome, of course :) 2019-07-24 16:43:33 the new gitlab is the preferred platform, at least once the docs/ namespace is migrated 2019-07-24 16:43:42 I guess I have my evening reading then :P 2019-07-24 16:44:02 Thanks for the work, SpaceToast 2019-07-24 16:45:01 shouldn't it consistently use "Alpine Linux" everywhere? for instance the title is Alpine User Handbook. 2019-07-24 16:46:00 "Alpine" is a commonly used abbreviation; for instance, see the front page: "Alpine 3.10.1 released" 2019-07-24 16:46:11 ncopa, alpine-user@lists.alpinelinux.org is correct address or should be "~alpine/users" ? 2019-07-24 16:46:27 the full heading is "Alpine Linux 3.10.1 released", but that still suggests that "Alpine" is an acceptable abbreviation 2019-07-24 16:46:35 still, worst case it's a simple recursive sed patch :) 2019-07-24 16:48:22 my point is that unfortunately we have name collision with email client when using abbreviated form, all of us know that, so I think official docs should be careful to always use full name. outside of official contexts, abbrev form is perfectly fine IMHO. 2019-07-24 16:48:55 well the example I gave is literally on the front page: https://alpinelinux.org/ - it's unambiguous because of the domain name (same as with docs), imo 2019-07-24 16:49:20 same story for ML names - it's not ~/alpinelinux/users 2019-07-24 16:54:30 <_ikke_> If no one objects, I can create a docs group on gitlab 2019-07-24 16:54:58 regarding release news, it's inconsistency that could be easily fixed. regarding MLs, their mail addresses are in alo domain, so this kind of abbrev of logins seems fair there. 2019-07-24 17:07:10 and the domain for docs does in have contain "alpinelinux.org" :) 2019-07-24 17:14:11 _ikke_: thanks for merging the libdrm PR of z3ntu yesterday. Any chance you could do pr9287 today? 2019-07-24 18:05:11 <_ikke_> PureTryOut[m]: done :) 2019-07-24 18:06:02 Thanks for the merge! 2019-07-24 18:11:07 ncopa: MR is complicated? I presume you are kidding :-) 2019-07-24 18:11:47 I picked one from the top of my todo list, which I promised to some people after 3.10 release 2019-07-24 18:12:35 and one which have issue to check auto closing issue with fixes #nr in commit message 2019-07-24 18:13:48 although I don't expect it merged, and because that didn't bumped pkgrel. want to see how fixing MR works with GL 2019-07-24 18:14:06 <_ikke_> mps: force push to the branch you pushed 2019-07-24 18:14:10 <_ikke_> then the MR gets updated 2019-07-24 18:14:23 <_ikke_> (you could also push new commits, but then someone would need to squash them 2019-07-24 18:15:39 _ikke_: I made it without creating branch 2019-07-24 18:16:07 <_ikke_> so pushed to master on your fork? 2019-07-24 18:16:11 <_ikke_> (which is also a branch) 2019-07-24 18:16:18 just forked aport, made change and create MR 2019-07-24 18:16:28 <_ikke_> right 2019-07-24 18:16:48 <_ikke_> especially when you intend to create multiple merge requests, it's recommeded to create separate branches for them 2019-07-24 18:17:42 did the clandmeter set GL to do fast-forward instead of merge 2019-07-24 18:18:12 <_ikke_> no 2019-07-24 18:18:22 <_ikke_> But we still don't merge in gitlab 2019-07-24 18:18:30 <_ikke_> we still push to git.a.o 2019-07-24 18:19:05 when I tested test install of GL I noticed (and told) that merging should be done by 'FF' 2019-07-24 18:19:23 <_ikke_> should be? 2019-07-24 18:19:40 I think, yes 2019-07-24 18:20:15 we don't have branches on git.a.o as I see 2019-07-24 18:20:51 <_ikke_> We do have branches, but we don't push topic branches to git.a.o, now 2019-07-24 18:20:53 <_ikke_> no* 2019-07-24 18:21:41 yes, that is what I mean to say 2019-07-24 18:24:55 <_ikke_> gitlab only allows non-ff merges or squash merges 2019-07-24 18:25:14 <_ikke_> Hmm, you can also enable ff-merges I see 2019-07-24 18:27:00 ACTION votes to only allow ff-merges 2019-07-24 18:28:34 <_ikke_> You can also specify gitlab to require semi-linear merges (the merge should be fast-forwardable, but still create a merge commit) 2019-07-24 18:28:38 <_ikke_> those are my favorite 2019-07-24 18:28:50 _ikke_: yes, ff-merges are disabled by default and need to be enabled explicitly 2019-07-24 18:29:11 <_ikke_> It does require everyone to constantly rebase 2019-07-24 18:29:27 <_ikke_> especially on a high-traffic project, that might be a pain 2019-07-24 18:29:36 But merge commits spam the log so much 2019-07-24 18:29:38 And you can rebase in the webUI 2019-07-24 18:29:44 Both as the user making the MR and as maintainer 2019-07-24 18:29:57 <_ikke_> Cogitri: rebase + merge is quite nice to see 2019-07-24 18:30:10 I have no preference about that, but git.a.o now need 'FF' 2019-07-24 18:30:16 Well, it's two clicks in the GL webUI 2019-07-24 18:30:18 <_ikke_> You don't have overlapping merges, but still see the history 2019-07-24 18:30:39 Which is totally worth it for not having one merge commit per bump 2019-07-24 18:32:12 <_ikke_> If it's just a single commit, it should just be ff indeed 2019-07-24 18:38:12 Which is like 90% of our MRs, I imagine 2019-07-24 18:38:33 And even for multi-commit MRs, rebasing usually is super easy 2019-07-24 18:39:05 <_ikke_> If these commits are related to eachother, it might be worth to record that 2019-07-24 18:41:56 Hm, I don't really see the value attached to that :/ 2019-07-24 18:42:38 I mean e.g. if I have a llvm-8.0.1 MR what does knowing that that branch has been merged into master if llvm, clang, lldb and stuff have been bumped in one go? 2019-07-24 18:43:56 <_ikke_> You can see that these upgrades were related, rather than just coincidentally happening at the same time 2019-07-24 18:44:09 <_ikke_> If you want to revert, you might want to revert all of them, rather than just one 2019-07-24 18:44:31 <_ikke_> Without a proper merge commit, it's hard to see which commits are related to eachother 2019-07-24 18:44:41 Oh, reverting the merge commit would revert all of them? 2019-07-24 18:44:45 <_ikke_> yes 2019-07-24 18:45:42 <_ikke_> and rebase + merge makes history still look mostly linear 2019-07-24 18:45:48 Okay, didn't know that, my bad 2019-07-24 18:46:11 Making merge commits for big MRs does seem like a good idea then if we use ff merges for other MRs 2019-07-24 18:46:24 <_ikke_> yes, I can live with that conclusion 2019-07-24 18:58:05 only have to know where is the line between big and small 2019-07-24 19:00:39 5 commits? 2019-07-24 19:01:29 <_ikke_> It's not the amount of commits that matter 2019-07-24 19:02:43 have no idea, and think we should stick with one method, i.e. FF or normal merge 2019-07-24 19:03:35 have fear that this will be source of a lot of 'bikesheding' 2019-07-24 19:16:38 only FF please, the only downside i have with that is that i need to run pullp sometimes to rebase 2019-07-24 19:17:28 <_ikke_> Merges are not evil... 2019-07-24 19:18:24 <_ikke_> And anyone who claims rebasing is not merging is fooling themselves :) 2019-07-24 19:20:07 rebase is more than simple merge, in my POV 2019-07-24 19:21:44 <_ikke_> rebasing is lots of small merges 2019-07-24 19:22:26 Yes, but without the merge commit which usually is nice 2019-07-24 19:22:51 I use rebase for rewriting history sometimes, for example 2019-07-24 19:22:57 <_ikke_> Well, rebasing itself does not update the main-line :) 2019-07-24 19:23:13 <_ikke_> You still need to do some sort of 'merge' 2019-07-24 19:23:39 true 2019-07-24 19:24:07 <_ikke_> But purely linear history hides a lot of valuable history 2019-07-24 19:25:13 <_ikke_> It pretends each commit happens in isolation, which a lot of time is not the case 2019-07-24 19:26:08 again, true, but linear history is easier to follow, at least for me 2019-07-24 19:26:37 <_ikke_> rebase + non-ff merge creates history which is still easy to follow 2019-07-24 19:27:44 when I started to use git I had a lot of branches, but after some time I flatten all of them 2019-07-24 19:29:22 <_ikke_> I have set merge.ff to false and created an alias called ff which is merge --ff-only 2019-07-24 19:29:41 <_ikke_> So I can precicely decide wether I want to merge or fast-forward 2019-07-24 19:32:40 ah, nice idea 2019-07-24 19:37:17 Sweet 2019-07-24 19:37:44 Lab can be used instead of Hub so i can keep my workflow when we move over to making GitLab MRs instead of GItHub PRs 2019-07-24 19:40:09 maxice8: do you have url of the Lab? 2019-07-24 19:41:10 mps: I have a PR for it on GitHub 2019-07-24 19:41:11 Am on phone 2019-07-24 19:41:29 aha, ok. nice 2019-07-24 19:42:11 https://github.com/zaquestion/lab 2019-07-24 19:43:06 I couldn't get it to build under alpine (see CI failing on github) 2019-07-24 19:43:09 thanks 2019-07-24 19:43:31 But you can build via the classic git clone and make 2019-07-24 19:44:13 will try but tomorrow, now I'm on my $daywork 2019-07-24 19:44:37 My next blog post will be about my workflow in Alpine want a link once I make it 2019-07-24 19:45:37 ofc, would be nice to read about such big productive man experience 2019-07-24 20:32:58 Is there a set date for when MRs are going to be the recommended way over GitHub PRs ? 2019-07-24 20:41:21 maxice8: no 2019-07-24 20:41:38 it depends when we have the builders ready 2019-07-24 20:44:38 and when we converted the drone pipeline to gitlab-ci 2019-07-24 20:45:12 although that should not take too much time. 2019-07-25 05:38:25 mps: ping 2019-07-25 06:55:35 clandmeter: Ok, thanks for the info. 2019-07-25 07:20:43 maxice8: pong 2019-07-25 07:21:12 oh, I see. And good morning 2019-07-25 07:21:39 I sent you my blog post via pm 2019-07-25 07:26:23 I see, and answered you. thanks 2019-07-25 07:30:41 maxice8: please share now im curious. 2019-07-25 07:34:47 maxice8: where can I see (and maybe download) 'ax' script 2019-07-25 07:36:04 https://github.com/maxice8/meltryllis 2019-07-25 07:37:45 In bin/ 2019-07-25 07:38:22 found it, thanks 2019-07-25 07:39:12 i guess its https://maxice8.github.io/25-alpine-workflow/ 2019-07-25 07:40:09 clandmeter: yes 2019-07-25 07:40:30 that wasnt too difficult to find :) 2019-07-25 07:40:34 clandmeter: yes 2019-07-25 07:42:25 maxice8: btw, I've built Lab last night. 2019-07-25 07:45:16 it requires 'token', have to investigate do we have token in gitlab.a.o 2019-07-25 07:49:27 <_ikke_> 16https://gitlab.alpinelinux.org/profile/personal_access_tokens I guess? 2019-07-25 07:52:47 _ikke_: thanks 2019-07-25 08:35:12 '~/lab/lab mr list' => #5 Update CODINGSTYLE.md 2019-07-25 08:35:36 nice 2019-07-25 08:53:05 wrong channel, sorry 2019-07-25 08:54:04 maxice8: i pushed another version of lab to testing. 2019-07-25 08:56:29 clandmeter: nice 2019-07-25 08:58:30 maxice8: there are some issues with it. 2019-07-25 08:58:34 the tests 2019-07-25 08:58:50 Not nice 2019-07-25 08:59:08 it tries to connect to gitlab.com via ssh 2019-07-25 08:59:38 it should auto accept the host key, not sure how to do that. 2019-07-25 09:05:13 maxice8: i didnt add the shell completions. if you like you can add them and take over the aport. 2019-07-25 09:05:37 sure 2019-07-25 09:06:05 and if it works move it please 2019-07-25 09:06:20 seems nice to have. 2019-07-25 09:09:29 Checks require a gitlab account with ssh enabled 2019-07-25 09:11:08 haha what is this 2019-07-25 09:11:22 i can't even run `./lab completion bash > lab.bash` 2019-07-25 09:12:42 it asks me interactive questions to set up configuration 2019-07-25 09:12:43 and i can't run ./lab completion bash after answering those questions with yes because it tries to connect to gitlab 2019-07-25 09:12:58 yes its a bit stupid 2019-07-25 09:13:01 --help also doesnt work 2019-07-25 09:13:07 you needto auth 2019-07-25 09:13:29 i think we should ask them to remove bash 2019-07-25 09:13:34 its a stupid oneliner 2019-07-25 11:42:53 i had problems with lab due to the origin was set to git@git.a.o and not git@gitlab.a.o 2019-07-25 11:43:18 once that was resolved it worked pretty ok 2019-07-25 12:34:07 you can specify origin 2019-07-25 12:38:16 remote i mean 2019-07-25 12:47:51 ncopa: with lab you can specify a remote but i think it uses upstream 2019-07-25 12:47:53 as the remote name 2019-07-25 13:09:24 Hub which is Lab but for GitHub uses github -> upstream -> origin 2019-07-25 20:07:13 what is new url for aport patches 2019-07-25 20:07:29 <_ikke_> The mailing list archive? 2019-07-25 20:07:55 <_ikke_> https://lists.alpinelinux.org/~alpine/aports ? 2019-07-25 20:08:05 yes, where I can see url of just sent patch 2019-07-25 20:08:31 <_ikke_> ^ 2019-07-25 20:09:05 hmm, there is no just posted patch on top of the list 2019-07-25 20:09:18 <_ikke_> I didn't receive it either 2019-07-25 20:09:42 but I received mail from ML that the patch is there 2019-07-25 20:09:54 it is haproxy upgrade 2019-07-25 20:10:27 <_ikke_> This is the last haproxy related post from you I see: https://lists.alpinelinux.org/~alpine/aports/patches/741 2019-07-25 20:10:47 that's old one 2019-07-25 20:11:22 maybe ML system need some time to put it on web server 2019-07-25 20:11:32 should be instant 2019-07-25 20:14:01 oh, postfix log says it is deffered, so git send-email somehow manage to put it in my inbox 2019-07-25 20:14:25 and "(host smtp.alpinelinux.org[147.75.101.119] said: 451 4.7.1 Try again later (in reply to end of DATA command))" 2019-07-25 20:14:32 <_ikke_> mps: `might bey greylisted 2019-07-25 20:14:44 <_ikke_> ie, it expects your mta to send it another time later 2019-07-25 20:15:10 it is in deffered queue on my server 2019-07-25 20:15:22 <_ikke_> yes, that's what happens when it's greylisted 2019-07-25 20:15:44 yes, I know, I use graylisting in my servers for year 2019-07-25 20:16:22 but I put message 'greylisted for $amount_of_time' in msg 2019-07-25 20:22:32 'sendmail -q' and it is there https://lists.alpinelinux.org/~alpine/aports/patches/2870 2019-07-25 20:22:58 <_ikke_> :-) 2019-07-25 20:23:03 question is, should I send same patch for 3.10 2019-07-25 20:23:39 or note somehow commiter to apply this one to 3.10 2019-07-25 20:30:29 yes, on github i send separate PRs for other branches 2019-07-25 20:33:18 maxice8: hmm, I don't see option in 'git send-email' to specify branch to which it should be applied 2019-07-25 20:34:09 (starting to dislike ML for sending patches :-P ) 2019-07-25 20:34:39 ¯_(ツ)_/¯ yeah, i just use hub with my workflow 2019-07-25 20:35:15 <_ikke_> because with patches, you don't specify where to merge things into 2019-07-25 20:35:15 can't wait for GL to become official 2019-07-25 20:35:38 <_ikke_> I'm doing my best to get CI runnig 2019-07-25 20:35:40 <_ikke_> running 2019-07-25 20:35:47 hope it will be easier, especially with 'lab' 2019-07-25 20:35:48 _ikke_: good luck 2019-07-25 20:35:49 <_ikke_> The heat here does not help though 2019-07-25 20:36:20 _ikke_: no need to hurry, I learned to be patient in my life 2019-07-25 20:36:50 'it is ready when it is ready' 2019-07-25 20:37:19 so, easy. best results are achieved with easy steps 2019-07-25 20:37:42 <_ikke_> Yes, the first steps were getting the infra ready for the runners 2019-07-25 20:37:56 <_ikke_> I mean, software wise 2019-07-25 20:38:12 <_ikke_> We are still working on getting hardware for all the arches 2019-07-25 20:39:13 I know, I follow infra channel, when have time 2019-07-25 20:49:56 maxice8: when you commit pathes (PR's and soon MR's) please tech author that the proper commit message is 'upgrade' and not 'update' 2019-07-25 21:00:59 hmm, https://meta.alpinelinux.org/forgot tells me that it cannot find my mail address, and I received email earlier which told me that I'm subscribed 2019-07-25 21:01:46 <_ikke_> a subscription is different from an account 2019-07-25 21:02:49 ah, so. accounts not migrated from patchworks.a.o? 2019-07-25 21:03:00 <_ikke_> No 2019-07-25 21:03:11 <_ikke_> atm there is not a lot to do with your account 2019-07-25 21:03:19 so, someone have to add me then, I presume 2019-07-25 21:03:34 <_ikke_> Changing patch status currently only can be done by the list owner (~alpine) 2019-07-25 21:03:51 <_ikke_> Updating by others is being worked on 2019-07-25 21:04:49 eh, nice. :-) I don't have to walk through and fix patches then 2019-07-25 21:05:30 <_ikke_> Do you want me to update some patches? 2019-07-25 21:06:05 Same here 2019-07-25 21:06:15 Can't focus with this temp 2019-07-25 21:06:33 Still over 30 outside 2019-07-25 21:06:38 Nuts 2019-07-25 21:06:50 I forgot to add 'to' word to last two patches. 'main/haproxy: upgrade 2.0.3' should be 'main/haproxy: upgrade to 2.0.3' 2019-07-25 21:08:05 (and just criticized someone for improper wording on commit msg) 2019-07-25 21:08:18 ACTION hides somewhere 2019-07-25 23:08:46 clandmeter: that's a lotta heat, usually have that during summer but it is winter now 2019-07-25 23:09:06 that's a lotta damage 2019-07-25 23:11:43 mps: i forget that i lot myself 2019-07-25 23:11:46 mainly because i solved that problem with githooks 2019-07-25 23:15:10 yes, just read again (this time with more care) you post about workflow and noticed your mention on githook which formats commit msg 2019-07-25 23:16:16 and looked at it here https://gitlab.alpinelinux.org/alpine/aports/blob/master/.githooks/prepare-commit-msg 2019-07-25 23:16:38 didn't know it exists 2019-07-25 23:16:55 it is not the same as mine 2019-07-25 23:17:01 will be very useful to me 2019-07-25 23:17:13 i just extended it a bit 2019-07-25 23:17:17 aha, then will look at your 2019-07-25 23:17:43 it is a hyperlink in my blogpost 2019-07-25 23:18:07 ah, I see it 2019-07-25 23:18:47 how can I 'include' it in 'git commit -v' 2019-07-25 23:19:42 i have git config commit.verbose true 2019-07-25 23:19:51 globally so it is always verbose 2019-07-25 23:22:55 hm, how to 'invoke' githook? never used them 2019-07-25 23:23:13 have them in .git/hooks and they are invoked in specific situations 2019-07-25 23:24:15 there are some which names ends in .sample 2019-07-25 23:24:31 those are not processed, have them as an executable without the sample 2019-07-25 23:25:24 heh, copied your there and it works 2019-07-25 23:25:39 big thanks :-) 2019-07-25 23:26:27 I learned something new 2019-07-26 07:12:06 ncopa: Can we enable gettext for py3? Some applications like gnome-passworsafe need it for working translations (or do we need to keep the gettext dep out to safe space? I guess I'll just have to break translations then) 2019-07-26 08:05:09 Cogitri: we normally dont enable gettext and native language support 2019-07-26 08:05:35 i am afraid that if we start doing that one place we will end up do it everywhere 2019-07-26 08:06:21 i have previously said that if you need good NLS, then alpine may not be the right tool 2019-07-26 08:06:33 Hm, I don't really see the problem with that to be honest 2019-07-26 08:06:54 But alright, I'll just patch the thing to not support NLS 2019-07-26 08:07:31 i mean, sure, we can evaluate if we want enable NLS, but its a major change for the distro 2019-07-26 08:07:36 and a can of worms.... 2019-07-26 08:07:53 i dont mind raising that issue, but not right now 2019-07-26 08:08:06 after html email and governance discussions has settled 2019-07-26 08:08:34 doesnt musl have some sort of support for gettext? 2019-07-26 08:08:41 we could maybe use what musl provides 2019-07-26 08:08:51 Yup, it's not a pressing matter :) 2019-07-26 08:09:20 Don't think so, glibc does 2019-07-26 08:13:37 it actually have libintl.h 2019-07-26 08:13:47 musl has libintl.h 2019-07-26 08:13:50 but we delete it 2019-07-26 08:14:34 https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/musl/APKBUILD#L101 2019-07-26 08:15:45 Cogitri: i have an idea 2019-07-26 08:16:24 I think NLS will be enabled in future because more and more people use Alpine as workstation. they will pressure to that 2019-07-26 08:16:34 what if we ship musl's libintl.h in musl-libintl subpackage 2019-07-26 08:17:38 So that only a few packages pull it in to explicitly enable support? 2019-07-26 08:17:44 yes 2019-07-26 08:17:59 i think the reason we remove it is because it used to be not-good enough in musl 2019-07-26 08:18:09 and lots of packages would automatically enabled when detected 2019-07-26 08:18:17 and disable nls when not detected 2019-07-26 08:18:46 mps: i think you are right. so i think it may need to re-evaluate 2019-07-26 08:20:23 so, for now we have to keep it 'on radar' and discuss later, maybe on devel ML 2019-07-26 08:20:57 or create issue, if it doesn't exist already 2019-07-26 08:22:30 ncopa: btw, last night I posted patch to upgrade haproxy to 2.0.3 which fixes one critical bug and a number of 'meduim' bugs 2019-07-26 08:47:33 mps: will have a look at your patches later 2019-07-26 08:48:15 np, thanks 2019-07-26 08:49:57 I tested build on x86, x86_64, armv7 and aarch64, on edge 2019-07-26 08:50:13 and on x86_64 on v3.10 2019-07-26 08:54:55 Cogitri: something like this? http://tpaste.us/vbnM 2019-07-26 08:55:32 it will at least allow us to start experimenting with it 2019-07-26 08:55:40 Yup, seems good 👍 2019-07-26 09:06:57 musl-libintl is good starting point, I think 2019-07-26 09:43:12 it was long time since i looked at musl-intl and i think it has improved 2019-07-26 09:43:26 might be we can replace gnu gettext for lots of stuff 2019-07-26 09:49:45 Yup, some stuff hardcodes gnu gettext though (e.g. gettext-rs :/) 2019-07-26 09:53:32 Actually, that seems pretty trivial to replace with modern musl, nice 2019-07-26 14:20:12 duncaen: i'm considering promote your doas port for alpine as the default tool instead of sudo https://github.com/Duncaen/OpenDoas 2019-07-26 14:20:21 ie, in offficial documentation etc 2019-07-26 14:21:10 the readme says: "This is still a work in progress! Please do not deploy yet in a critical environment! " 2019-07-26 14:21:27 nice, I have to finish the release at some point, which adds perist 2019-07-26 14:22:04 i also wonder about stable release support. we will have to support it for 2 years once we ship it from main repository 2019-07-26 14:22:15 The readme is still from the fork. I'm confident that the tagged version is fine 2019-07-26 14:22:17 that is for security fixes 2019-07-26 14:22:23 ok 2019-07-26 14:22:34 maybe we could update the readme then? 2019-07-26 14:23:03 yes, going to do that maybe over the weekend 2019-07-26 14:23:09 great! 2019-07-26 14:23:32 the openbsd-current version changes a bit again, iirc they change the environment variables that are allowed to pass through by default 2019-07-26 14:24:02 will you try follow that? 2019-07-26 14:24:31 yes plan was to follow openbsd stable releases, but I didn't tag any because they didn't change anything except style stuff 2019-07-26 14:24:51 and because I'm a bit unsure about the timestamp file stuff 2019-07-26 14:24:56 i am also curious about stable releases, once we ship to stable branch we cannot introduce breaking changes with security fixes 2019-07-26 14:25:06 timestamp file? 2019-07-26 14:25:35 for the persist feature, master has cookie/timestamp files similiar to sudo 2019-07-26 14:27:17 I'm open to maintain release branches for longer, its very simple and backporting patches for security issues should be easy 2019-07-26 14:28:02 thats what i'd expect 2019-07-26 14:28:17 (never happened in the last 3 years) 2019-07-26 14:28:23 i dont expect too many sec fixes either :) 2019-07-26 14:28:47 the persist/cookies/timestamps could introduce issues, its a bit tricky 2019-07-26 14:29:10 i havent looked into it or why its needed 2019-07-26 14:29:26 i suppose we could build --without-persist in alpine initially 2019-07-26 14:30:04 ah 2019-07-26 14:30:13 "persist After the user successfully authenticates, do not ask for a password again for some time." 2019-07-26 14:31:09 right, it parses some things in /proc to restrict it to the parent pid, using ppid+ttynr+starttime of parent to make sure its not a different terminal/session 2019-07-26 14:32:48 I used sudo as reference, to avoid the obvious issues, but its still not a nice solution like openbsd which just added an ioctl to the tty 2019-07-26 14:33:00 heh 2019-07-26 15:45:54 tcely: i'm sorry, but I stop review when I see things like I comment here: https://github.com/alpinelinux/aports/pull/9540#discussion_r307801120 2019-07-26 15:46:31 you add at least 7 lines with code to be able to give apk-tools a serious headache 2019-07-26 15:50:01 or i simply dont understand what happens (in which case code is not clean and simple) 2019-07-26 15:52:46 if i push that, i am sure that something will break and as consequence there will more clever and complicated solutions for problems that shouldn't be there in the first place 2019-07-26 16:21:51 ok. turns out that it is me that is stupid. i simply misunderstand what the code really does 2019-07-26 16:22:34 i think its better someone more clever does the review. im obviously not smart enough 2019-07-26 16:23:09 lol 2019-07-26 16:35:26 anyone have short guide how we can use git.a.o and gitlab.a.o from one local aports repo to make MR, apply patches and push to git.a.o 2019-07-26 16:36:03 and not to have three aports repo locally, as I have now :P 2019-07-26 17:28:46 Use remotes 2019-07-26 17:31:37 <_ikke_> yes, remotes are meant for that 2019-07-26 17:31:55 <_ikke_> git remote add gitlab ; git remote add github 2019-07-26 17:32:07 Or if you don't like you can apply the pr patch 2019-07-26 17:32:30 If gitlab provides it 2019-07-26 17:32:56 MR i mean 2019-07-26 17:33:09 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2.patch 2019-07-26 17:33:52 Later you can even merge from ui 2019-07-26 17:36:18 I guess lab also provided some features 2019-07-26 17:36:32 Didn't use it yet 2019-07-26 17:40:43 clandmeter: _ikke_: thanks both. I thought multi remote is solution, but never used this git feature (don't have use case for that) 2019-07-26 17:41:22 I have too many 2019-07-26 17:41:36 Had to clean up a few 2019-07-26 17:41:41 will look deeply if 'lab' can do that, although I think it can, it is wrapper around git 2019-07-26 17:43:13 lab can fetch patch, I think, although didn't tested it yet 2019-07-26 17:53:21 'lab mr show 2' and 'wget https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2.patch' works 2019-07-26 18:36:39 <_ikke_> wow, 135 pull requests on github o\o/ 2019-07-26 18:37:06 <_ikke_> 2 months back we had over 400 2019-07-26 18:38:28 and 2 on gitlab 2019-07-26 18:39:46 and one MR is applied to aports today, I think first one 2019-07-26 19:58:57 Thanks for reviewing & merging stuff :) 2019-07-26 21:55:05 mps: i just my pr script which is curl | git am -3 2019-07-26 21:55:29 mps: http://ix.io/1PE5 2019-07-26 21:57:10 maxice8: yes, I thought to use curl, but tested with wget to check if it works 2019-07-26 21:57:19 mps: if you look at my scripts i have 3 remotes, origin, upstream and gitstream :D 2019-07-26 21:57:34 gitstream is git.a.o that i have push access, upstream is github (but can be gitlab on your case) and origin is your fork 2019-07-26 21:57:44 works for me on Hub and will problably work fine on Lab as well 2019-07-26 21:59:43 I plan tomorrow to read about git remote usage a bit 2019-07-26 22:02:33 and, I started to test your scripts, gbr works 2019-07-26 22:03:10 you're also gonna need alpine-stable-prefix 2019-07-26 22:03:14 if you plan to use the others 2019-07-26 22:03:26 since i work on stable branches but just prefixing 3.x- to the branch name 2019-07-26 22:03:40 yes, I copied it to /usr/local/bin 2019-07-26 22:05:22 I will check how 'ax' work, 'ax g' works fine 2019-07-26 22:05:42 it is a mess but work 2019-07-26 22:05:58 the name of the branch is just the hint of where to operate, so naming your branch gnutls and doing ax e will open the gnutls APKBUILD 2019-07-26 22:05:59 'ax e' doesn't 2019-07-26 22:06:44 wfm 2019-07-26 22:06:50 '/usr/local/bin/ax: line 78: e: not found' 2019-07-26 22:07:18 oh, you also need my e script which is basically 2019-07-26 22:07:23 exec "${EDITOR:-vi}" "$@" 2019-07-26 22:07:34 aha, ok 2019-07-26 22:08:15 i got a few scripts that are single letters like m for opening aerc inside dtach. 2019-07-26 22:08:38 now it works, thanks 2019-07-26 22:08:40 Another one important for 'ax' is the 'f' script which is 'exec ranger "$@"' 2019-07-26 22:09:29 will look to change it to vifm, and I don't use aerc 2019-07-26 22:13:00 'ax l', very nice 2019-07-26 22:14:19 ax f too 2019-07-26 22:15:42 /usr/local/bin/ax: line 350: apkbuild-fixer: not found 2019-07-26 22:16:46 probably need newer atools 2019-07-26 22:17:20 17.1 and up has apkbuild-fixer 2019-07-26 22:18:01 have to rebuild it for v3.10 2019-07-26 22:19:18 i'd just the edge version 2019-07-26 22:19:19 just use* 2019-07-26 22:20:39 I use stable, it is my job workstation, although I have edge in lxc 2019-07-26 22:21:55 and I'm trying to understand new workflow so I actually like to see problems to better understand what I'm trying 2019-07-27 00:47:45 mps: can you pin it to an edge repo ? 2019-07-27 06:26:32 <_ikke_> edge has 18.1 2019-07-27 06:26:38 <_ikke_> (re atools) 2019-07-27 06:26:45 _ikke_: Hey you're awake :D 2019-07-27 06:26:55 i tagged a few RPs for you :D 2019-07-27 06:26:55 <_ikke_> yes :-) 2019-07-27 06:27:10 <_ikke_> I think I reacted to those 2019-07-27 06:27:18 <_ikke_> I have no new notifications 2019-07-27 06:27:28 my email says otherwise 2019-07-27 06:27:49 <_ikke_> ah, you mean the backport for atools to 3.10? 2019-07-27 06:28:03 yes 2019-07-27 06:34:18 pr9373 can be closed 2019-07-27 06:39:47 <_ikke_> done 2019-07-27 06:40:11 thank you 2019-07-27 07:28:11 <_ikke_> maxice8: mongo-php7-library is failing atm 2019-07-27 07:28:50 hmpf, i pushed the commits in the wrong order now they keep failing until abuild realizes " i need to build X before Y " 2019-07-27 07:42:06 maxice8: I can pin, but I don't like to mix stable and edge, rather building (backporting) new version on stable 2019-07-27 07:42:18 and good morning :-) 2019-07-27 07:42:25 the only dep of atools is grep 2019-07-27 07:42:38 <_ikke_> morning mps 2019-07-27 07:42:52 _ikke_: good morning 2019-07-27 07:44:21 maxice8: few times I had mess with stable+edge and after that I removed 'edge' from $dayjob workstation 2019-07-27 07:45:02 <_ikke_> There is a difference of adding edge is general repo and pinning a few select packages from edge 2019-07-27 07:45:12 <_ikke_> s/is/as a/ 2019-07-27 07:45:12 _ikke_ meant to say: There as a a difference of adding edge is general repo and pinning a few select packages from edge 2019-07-27 07:45:17 <_ikke_> :P 2019-07-27 07:46:23 And there are a few PRs to main :D 2019-07-27 07:46:47 <_ikke_> I'm focussing on getting gitlab CI to work atm 2019-07-27 07:46:58 ah 2019-07-27 07:47:02 :D good luck 2019-07-27 07:49:41 I used pinning when I switched to Alpine, but nowadays when I learned how to backport pkg (which is usually simple 'abuild -r') do not 2019-07-27 07:53:19 mps: well, anyways use the latest atools since it has the fixes and adapts to policy changes 2019-07-27 07:54:13 ofc, thanks for reminding me 2019-07-27 07:55:14 btw, thanks for making 'zola' pkg 2019-07-27 07:57:44 mps: i use it in my blog so it is vital i get it into the distro i use 2019-07-27 08:00:42 yes, I see, after reading your blog I looked at it from my aarch64 box and looked how to install it. 'apk search zola' didn't found it and I looked how to compile it from source, but when switched to x86_64 I found it ready made 2019-07-27 08:01:08 zola is rust so it only x86_64 for now 2019-07-27 08:01:27 cogitri: is working on Rust 2019-07-27 08:01:37 I have rust (old version) on aarch64 and I can buid some pkg's 2019-07-27 08:03:34 hopefully it can compile zola 2019-07-27 08:04:36 will try today 2019-07-27 08:05:26 I built even firefox-esr 60.7 2019-07-27 08:09:37 nice 2019-07-27 08:13:29 well, six months ago I started to work on bootstrapping rust on armv7 and aarch64 and was nearly finished but Cogitri persuaded me that his approach is better and I stopped and now I'm trying to help him 2019-07-27 08:23:17 _ikke_: pr9546 can be closed 2019-07-27 08:24:05 <_ikke_> why? 2019-07-27 08:24:16 Because i merged it 2019-07-27 08:24:34 but PRs by that specific user never auto close 2019-07-27 08:24:36 <_ikke_> I wonder why algitbot doesn't close PRs for J0WI 2019-07-27 08:24:41 <_ikke_> yea 2019-07-27 08:25:11 <_ikke_> I automatically add Closes GH- to the commit messages I push, so you are certain it gets closed 2019-07-27 08:27:07 _ikke_: ime, fixes #nr (issue number) works 2019-07-27 08:27:27 <_ikke_> yes, but I wanted to prevent it from interfering with redmine issue # 2019-07-27 08:27:33 <_ikke_> When that was still relevant 2019-07-27 08:27:49 aha, good note 2019-07-27 08:28:33 <_ikke_> otherwise you could close a random redmine issue, especially because the github PR numbers came close to recent redmine issue numbers 2019-07-27 08:55:01 _ikke_: pr7530 as well please :D 2019-07-27 08:55:06 also was merged 2019-07-27 10:25:43 _ikke_: 18.3 is now available 2019-07-27 10:26:49 <_ikke_> ok 2019-07-27 10:30:52 mps: Well, help is certainly welcome, currently compiling against our triplets doesn't work :/ 2019-07-27 11:02:18 Cogitri: version in aports doesn't build or something other? 2019-07-27 11:04:14 The rust packages the builders have built fail to build rustc with our triplet for some reason and upstream seems to be a bit clueless too, I'll have to dig pretty deep on this one I guess 2019-07-27 11:05:39 did you look how adelie devs added their triplet (quartet) 2019-07-27 11:06:42 maybe there is a hint for alpine, I did it earlier copying their triplets and changed to alpine 2019-07-27 21:28:56 so should I open MRs on gitlab now? 2019-07-27 21:30:48 <_ikke_> jwh: gitlab has not CI yet, so even though you could, you still (and the ones applying) get better feedback at github atm 2019-07-27 21:30:53 oh 2019-07-27 21:30:56 ok tghx 2019-07-27 21:30:59 thx* 2019-07-28 11:09:29 maxice8: i think cargo is supported on more platforms now? 2019-07-28 11:09:44 armhf and armv7 2019-07-28 11:09:56 i believe aarch64 had support for 5 seconds as well but i had to remove it 2019-07-28 11:10:12 i refer to watchexec 2019-07-28 11:10:29 No that is just me missing something 2019-07-28 11:10:57 cargo works for armv7 but not aarch64? 2019-07-28 11:11:06 as of now, yes 2019-07-28 11:11:09 that sounds weird 2019-07-28 11:11:39 what happens? 2019-07-28 11:12:22 cogitri: can brief you on that, he is the one getting punished by Rust's bootstrapping requirements 2019-07-28 11:30:22 clandmeter: Our triplets aren't functional on other arches yet, will look into it today 2019-07-28 11:41:16 _ikke_: up for merging secfixes to main/ ? :D 2019-07-28 12:26:51 <_ikke_> maxice8: in a moment, first need to have some food and cool down a bit :-) 2019-07-28 12:27:13 sure 2019-07-28 13:29:48 <_ikke_> maxice8: perhaps it would be good to include some context in the patches to tell where they are coming from 2019-07-28 13:30:02 <_ikke_> (libgcrypt) 2019-07-28 13:30:26 Nicked them all from OpenSUSE work on backporting upstream patches 2019-07-28 13:30:38 The patches are linked in the issue 2019-07-28 13:30:47 But I'm out buying stuff in bulk 2019-07-28 13:30:49 <_ikke_> Hmm ok 2019-07-28 13:30:50 So can't do anything 2019-07-28 13:30:56 <_ikke_> Sure, np 2019-07-28 13:31:07 <_ikke_> There was some discussion going on that include that info in the patches itself 2019-07-28 13:36:47 Patch headers? 2019-07-28 13:37:31 <_ikke_> yes 2019-07-28 14:01:26 Cogitri asked for it ? :D 2019-07-28 14:01:47 Yup, SpaceToast added it to the docs afaik 2019-07-28 14:01:58 Nice. 2019-07-28 14:02:17 Originally from Exherbo, i then pushed it on Void Linux with Cogitri's help 2019-07-28 14:02:22 there's a draft for "best practices", but it's been put on hold because no one wants to discuss other stuff that might go on it 2019-07-28 14:02:58 also I'm in the middle of a move, which doesn't help with even attempting that :) 2019-07-28 14:03:40 unfortunately, the draft is currently unavailable since it's hosted on my server, which isn't connected, because, well, see above 2019-07-28 14:03:54 (hopefully it'll be up by friday, but I can't guarantee that) 2019-07-28 14:04:03 No worries 2019-07-28 14:07:08 _ikke_: patches have been upped 2019-07-28 14:07:27 maxice8, http://ix.io/1PQ6 - temporary snapshot of the page 2019-07-28 14:07:40 the format's slightly different from void/exherbo (we discussed it with Cogitri over in #alpine-docs) 2019-07-28 14:09:39 Yup, but still pretty similiar and super useful :) 2019-07-28 14:11:48 <_ikke_> maxice8: upped in what way> 2019-07-28 14:12:08 _ikke_: updated with a futurely non-standard header 2019-07-28 14:12:35 <_ikke_> ok 2019-07-28 14:12:55 <_ikke_> thanks 2019-07-28 14:19:40 :) 2019-07-28 14:26:14 maybe we can move -static (libs) to dev pkg, and use static for statically built binaries 2019-07-28 14:26:46 static libs used to be in dev but were moved to -static by request of ncopa 2019-07-28 14:28:12 should be moved back, then (yes, I remember discussion but forgot to raise issue) 2019-07-28 14:28:49 SpaceToast: nice write, simple and clean 2019-07-28 14:30:07 maxice8: btw and OT, did you use some standard zola theme for you blog or you made it from scratch, looks nice and simple, just what I need 2019-07-28 14:31:00 Used a custom theme from someone else 2019-07-28 14:31:01 https://github.com/maxice8/maxice8.github.io/tree/devel 2019-07-28 14:32:10 thanks, will look to adapt it to my writings 2019-07-28 15:03:13 <_ikke_> maxice8: did you rebase the patch to match Alpines version? 2019-07-28 15:11:05 Do the builders automatically restart builds if they fail? 2019-07-28 15:12:25 Rust with musl and on less common arches (read: anything that isn't x86_64) likes to SIGSEV (I guess due to triggering some LLVM bugs) every now and then (especially with massive packages like gtk-rs) :/ 2019-07-28 15:14:24 <_ikke_> Cogitri: No, you need to trigger it 2019-07-28 15:17:02 That's unfortunate 2019-07-28 15:24:49 <_ikke_> In most cases, it fails due to some issue that would not be fixed the next build 2019-07-28 15:25:04 <_ikke_> The builder would just try to build again and again the same failing package 2019-07-28 15:28:37 I think Void builders try 3 times before giving up 2019-07-28 15:28:57 But fair enough, who can I nag about random build failures (other than Rust/LLVM upstream)? 😅 2019-07-28 20:15:53 hi all 2019-07-28 20:15:56 how to know the mantainer of a package? 2019-07-28 20:17:40 (see #alpine-linux, please don't ask the same question in two channels at the same time, wait a bit at least) 2019-07-28 20:18:01 oki sorry, didn't know if it was the same 2019-07-28 20:30:23 Where do people move pages on the wiki too if they want to archive it? 2019-07-28 22:46:32 two kernel release in two days, guess it is security fix 2019-07-29 06:17:23 dependencies between 2 -dev subpackages of the same pkg can't find each other's pkgconfig files https://gitlab.alpinelinux.org/alpine/abuild/issues/9975 2019-07-29 07:00:11 pr9716 can be closed, was merged 2019-07-29 07:07:21 maxice8: morning 2019-07-29 07:07:32 which timezone are you in? 2019-07-29 07:08:16 UTC -3 2019-07-29 07:08:17 BRT 2019-07-29 07:08:21 maxice8: if you downgrade a package, please make sure the new versions has not been used before. 2019-07-29 07:08:39 s/versions/version 2019-07-29 07:08:39 clandmeter meant to say: maxice8: if you downgrade a package, please make sure the new version has not been used before. 2019-07-29 07:08:43 Is there a reverts= like Void Linux does ? 2019-07-29 07:09:00 what does it do? 2019-07-29 07:09:25 automatically makes a lower version package be considered higher version than the package version present in reverts= 2019-07-29 07:09:45 and how is it used? 2019-07-29 07:09:50 by t he pkg manager? 2019-07-29 07:09:51 so version=1 release=1 reverts="2_1" produces a pkg-1_1 that has precedence over pkg-2_1 2019-07-29 07:10:06 oh it changes the actual version 2019-07-29 07:10:08 The how i have no sure i didn't look into xbps internals 2019-07-29 07:10:39 the problem we have is that the pkg file is same filename as before 2019-07-29 07:11:00 so it will have a cached version in our cdn 2019-07-29 07:11:18 so cdn will provide the old pkg 2019-07-29 07:11:39 i see 2019-07-29 07:11:46 maxice8: you are from brazil? 2019-07-29 07:11:55 Yes 2019-07-29 07:11:59 nice :) 2019-07-29 07:28:17 clandmeter: so how to fix ? bump pkgrel ? 2019-07-29 07:28:55 if its not used yet, then thats the way. 2019-07-29 07:43:40 ok 2019-07-29 08:08:12 Where do people move pages on the wiki too if they want to archive it? 2019-07-29 08:08:18 There is no delete option it seems 2019-07-29 08:22:46 do we have to use libseccomp if they are optional for pkg 2019-07-29 08:23:18 Please do use it, it filters some dangerous syscalls out 2019-07-29 08:24:10 dangerous syscalls? then these syscalls should be removed 2019-07-29 08:26:15 I understand if libseccomp is used for qemu (for example) but not why it is used in zathura 2019-07-29 08:26:29 its used in many more pkgs. 2019-07-29 08:26:53 mps: Imagine it like a super complex sandbox for syscalls 2019-07-29 08:27:15 "My app only needs syscalls X and Y so don't let it make useful but dangerous syscall Z it doesn't need in normal operation" 2019-07-29 08:28:00 'find -name APKBUILD | xargs grep seccomp-dev | wc -l' => 19 2019-07-29 08:39:43 mps: no need for find/xargs ;-) 2019-07-29 08:41:11 you mean 'grep -r libseccomp-dev | wc -l' 2019-07-29 08:45:59 Anyway, I'd enable seccomp wherever possible, 0.6M for syscall filtering is worth it 2019-07-29 08:49:29 I have error: 'zathura 4.pdf' => error: Failed to initialize basic seccomp filter. 2019-07-29 08:50:49 my question is: why zathura uses seccomp and a lot of similar pkg's does not 2019-07-29 08:51:55 or, reformulate, do we have to use seccomp wherever it is possible 2019-07-29 08:51:59 I guess because they haven't had time to implement it or didn't feel like using libseccomp because it's apparently pretty complex 2019-07-29 08:52:57 And for user facing things exposing r/w access to $HOME usually is more dangerous than some syscalls, so something like bwrap is a good idea 2019-07-29 08:53:09 But I feel like we should enable seccomp is possible anyway 2019-07-29 08:53:14 or, maybe, if the pkg doesn't use seccomp properly should we remove it from deps 2019-07-29 08:56:06 grep xxx */*/APKBUILD 2019-07-29 08:57:19 oh, even shorter, didn't know. thanks :-) 2019-07-29 08:58:42 and better, grep just APKBUILD files 2019-07-29 08:59:23 i mostly add -Hi 2019-07-29 08:59:32 or r if needed 2019-07-29 09:09:52 Does nobody know? 🤔 2019-07-29 09:13:11 Nop 2019-07-29 09:14:39 Who has admin access to/maintains the wiki anyway? 2019-07-29 09:16:44 ACTION hides 2019-07-29 09:17:00 ACTION points in _ikke_ direction 2019-07-29 09:21:08 pr9716 can be closed, was merged 2019-07-29 09:50:11 will wiki pages be move gitlab.a.o in some near future 2019-07-29 09:50:29 i doubt 2019-07-29 09:50:35 to be done in a way similar to void-docs ? 2019-07-29 09:50:49 what does void-docs do? 2019-07-29 09:51:23 ncopa: void-docs is a github repo that holds all information that is compiled into a handbook available at docs.voidlinux.org 2019-07-29 09:51:29 GL wiki accept markdown, which is nice feature 2019-07-29 09:51:56 maxice8: ok, i understand 2019-07-29 09:52:05 yes, we will move some of the wiki docs over to gitlab 2019-07-29 09:52:13 it is prefered over wiki because there is at least some QA, there is a style guide and enforcment. 2019-07-29 09:52:14 the official docs will be maintained in gitlab 2019-07-29 09:52:19 yes, exactly 2019-07-29 09:52:21 we will do that 2019-07-29 09:52:22 There is also a subgroup inside the void-linux organization of people that have permission to push to it, i believe it is called doc-writers 2019-07-29 09:52:25 github? https://www.zdnet.com/article/github-starts-blocking-developers-in-countries-facing-us-trade-sanctions/ 2019-07-29 09:53:09 maxice8: that is somethign we can evaluate later i think 2019-07-29 09:53:21 lets get the official docs moved over first and we take it from there 2019-07-29 09:53:41 thanks to clandmeter's (hard) work we will not depend on GH 2019-07-29 09:53:42 alright 2019-07-29 09:53:59 mps: i dunno if thats for either #alpine-infra and/or #alpine-offtopic 2019-07-29 09:54:47 but yes, i think moving to gitlab, our own hosted, will pay off at some point 2019-07-29 09:55:10 ncopa: sorry, I posted that url two days ago to #alpine-infra (with excuse) but couldn't resist now again 2019-07-29 09:56:20 wanted to thank to clandmeter and _ikke_, and other who helped with move 2019-07-29 09:59:19 yeah, they did a good job 2019-07-29 09:59:25 are doing a good job 2019-07-29 10:01:21 btw, what are plans for kernel upgrade? I hoped that the 5.2 will be next LTS, but it is obviously not. maybe 5.3 will (I hope again) 2019-07-29 10:01:44 im not sure what to do with the kernels 2019-07-29 10:02:10 I see Cogitri just added iwd to default backend to NM, and iwd needs at least 4.20+ 2019-07-29 10:02:15 i was thinking we could rename linux-vanilla to linux-lts 2019-07-29 10:02:31 but not sure its worth the job 2019-07-29 10:02:35 mps; Eh? 2019-07-29 10:02:35 No it doesn't 2019-07-29 10:03:01 It needs 4.14+ IIRC 2019-07-29 10:03:02 I've been using iwd w/ 4.19 for months now 2019-07-29 10:03:12 'Rasmus Thomsen| community/networkmanager: enable iwd by default' 2019-07-29 10:03:32 Yes, I enabled iwd by default but it doesn't need >=4.20 2019-07-29 10:03:47 for EAP it needs at least 4.20, iirc 2019-07-29 10:03:56 And introduce non-lts kernels? 2019-07-29 10:04:21 that was the idea yes 2019-07-29 10:04:29 Even if not introducting non-lts kernels, I personally find linux-lts more descriptive of what it is 2019-07-29 10:04:30 but the problem is 3rd party modules 2019-07-29 10:04:42 PureTryOut[m]: yes 2019-07-29 10:04:43 I'd be all for that but with our current setup it'd be a bit annoying supporting external modules that way (because we don't use dkms) 2019-07-29 10:04:49 I agree with ncopa about this, is it worth to have separate kernels? 2019-07-29 10:04:55 +1 PureTryOut 2019-07-29 10:05:10 mps: that is the question 2019-07-29 10:05:30 we do need separate kernels, the question is how many different kernels we are able to support 2019-07-29 10:05:37 I think it is good as it is now 2019-07-29 10:05:56 Well since desktop stuff is being done a lot recently on Alpine, having newer kernels would be good for more hardware support. It is however more work if not using dkms 2019-07-29 10:06:13 just wanted you have it on radar, as I have it 2019-07-29 10:06:19 it will be more work regardles if we use dkms or not 2019-07-29 10:07:20 5.2+ have some arm gpu's support, which is worth to have in mind for next stable release 2019-07-29 10:08:00 pmOS people will be happy I think (hi PureTryOut[m] :-) ) 2019-07-29 10:10:23 I'm using 5.2+ on some of my boxes with v3.10 and edge to test how it works 2019-07-29 10:11:16 ncopa: well, with dkms we wouldn't have to mess with 3rd party modules anymore (other than ensuring compatibility) 2019-07-29 10:11:17 But it would mean that we'd pull in C dev tools which is unfortunate 2019-07-29 10:14:01 i think we need to build 3rd pary modules packages for lts kernels 2019-07-29 10:14:09 at least some of them 2019-07-29 10:14:38 but we may want add support for dkms for the non-lts variant if we add that 2019-07-29 10:15:04 in any case, thats not something im gonna work on today or this week 2019-07-29 10:16:01 On pmOS we have mainline and latest stable kernels packaged 2019-07-29 10:17:49 ncopa: ofc, this is not a one day or week work, it will need some time and thinking 2019-07-29 10:24:33 im also thinking that we should maybe have a desktop and server config 2019-07-29 10:24:43 i am atleast thinking of a headless kernel config 2019-07-29 10:24:58 for or cloud kernel config 2019-07-29 10:25:26 without audio, wifi and blutetooth drivers 2019-07-29 10:26:26 Hm, is that really worth the effort when those modules aren't loaded anyway? 2019-07-29 10:26:38 We might save like 10~20M worth of modules with that 2019-07-29 10:27:03 linux-virt extended? (shrinked maybe better term) 2019-07-29 10:33:12 ncopa: got pr9795 to 9579 , the first 4 add secfixes comments to libembl and the last one does a security upgrade from 1.3.5 to 1.3.6 to deal wih the security issue that is in the gitlab issue. 2019-07-29 10:33:49 actually don't touch the last one just yet 2019-07-29 11:03:11 ok, the last one now is a security backport 2019-07-29 11:03:14 the other 4 can be merged safely 2019-07-29 11:32:37 maxice8: should the new testing/fmt be renamed to testing/fmt-libs 2019-07-29 11:33:48 no 2019-07-29 11:36:03 fmt-dev, maybe? 2019-07-29 11:37:46 'fmt (formerly cppformat) is an open-source formatting library.' from https://fmt.dev/latest/index.html 2019-07-29 11:38:11 wouldn't it be confusing with 'fmt' utility 2019-07-29 11:52:18 maybe libfmt 2019-07-29 11:55:46 maybe this name is good 2019-07-29 11:56:25 we should start to follow some consistent naming for pkg's 2019-07-29 11:57:59 i don't see a problem with having -libs and lib 2019-07-29 12:08:03 also I don't, but 'fmt' for lib pkg is not good, imo 2019-07-29 12:21:28 i personally wouldn't mind because it is the upstream name which i believe takes precedence but considering there are 2 fmt 2019-07-29 12:29:01 well, but again we should try to have some consistency although I suspect we can solve it for all pkg's 2019-07-29 12:31:11 i don't think there is a problem with that inconsistency 2019-07-29 12:32:59 it will appear if we are making mess in naming pkg's, sooner or later, I think 2019-07-29 12:58:52 What will appear 2019-07-29 13:07:05 problems as result of naming mess 2019-07-29 13:07:50 what kind of problems 2019-07-29 13:09:27 I can't tell right from the head, but at least it can lead to confusion for non alpine devs (devs who uses alpine as platform) 2019-07-29 13:11:03 Shouldn't we just use upstream names where possible? If the application/library is called "fmt", why rename it? 2019-07-29 13:11:21 Because there is another upstream project that is fmt 2019-07-29 13:11:23 once someone wants to package the second fmt, what do we do ? 2019-07-29 13:12:14 Huh, what project? 2019-07-29 13:13:08 there is 'first come, first serve' rule, but this rule cannot be applied always and blindly 2019-07-29 13:14:32 oh no i understood it wrong 2019-07-29 13:14:46 i thought the fmt.dev thing that mps showed was another fmt 2019-07-29 13:14:47 why are we even having this discussion then ? just use fmt the upstream name and be done with it 2019-07-29 13:15:07 there is work (beginning) on this, http://ix.io/1PQ6 2019-07-29 13:15:15 Exactly 😛 2019-07-29 13:16:17 how does -libs deals with many libraries under the same project ? like in util-linux which has libcom liberr and libwhatever 2019-07-29 13:16:19 also brb 2019-07-29 13:16:33 maxice8: I addressed you in first msg about this because you commited testing/fmt 2019-07-29 13:17:52 ofc, there can't be 'one size fits all' rule, but in most cases we can have some consistent naming scheme 2019-07-29 13:28:33 That doesn't apply for fmt 2019-07-29 13:34:42 <_ikke_> maxice8: wanting consit 2019-07-29 13:34:49 <_ikke_> Arg 2019-07-29 13:35:32 <_ikke_> Wanting consistent package names makes it even more important to decouple it from the upstream name 2019-07-29 13:59:51 I'd rather just follow upstream name like Void does, greatly avoids confusion. 2019-07-29 14:01:43 +1, it's a bit annoying when I have to guess what name the distro has chosen for a given packages 2019-07-29 14:01:51 hmm, so we should remove linux-vanilla and just name it linux 2019-07-29 14:05:12 <_ikke_> And remove all php*-, py*- and similar prefixes (and deal with potential collisions) 2019-07-29 14:06:10 _ikke_: you forgot perl- lua- ;-) 2019-07-29 14:06:29 <_ikke_> "and similar" 2019-07-29 14:08:01 I'd opt for linux-lts so we can make linux the stable variants 2019-07-29 14:08:02 +1 2019-07-29 14:08:31 (why every developer comming from other distro want to change (impose changes) alpine according to their previous distro) - rhetorical question, please don't answer 2019-07-29 14:08:32 That'd be consistent with other distros (like Arch) too 2019-07-29 14:29:11 _ikke_: don't need to go that extreme, other distros like Void, Arch and others managed to follow upstream naming and keep language specific modules with their prefixes, void even separates modules and applications bindings. 2019-07-29 14:58:22 ncopa: libebml has been fixed 2019-07-29 15:01:52 maxice8: good! thanks 2019-07-29 15:02:34 re changing things, naming practices, coding style etc 2019-07-29 15:02:47 i have some thoughts around changing things in general 2019-07-29 15:03:35 as you may have noticed, I have always liked the BSDs and have deep respect for them 2019-07-29 15:04:10 we do stuff in alpine that has its roots in BSDs 2019-07-29 15:04:47 one of the things that I early wanted to accomplish with alpine 2019-07-29 15:04:57 or one of the early goals with alpine 2019-07-29 15:05:15 was to provide some sort of stability 2019-07-29 15:06:09 thats one of the ideas behind the name alpine and mountains: rock solid, stable 2019-07-29 15:06:18 that is also why we provide stable branches 2019-07-29 15:06:28 lots of work, but it gives stability 2019-07-29 15:06:52 BSD have been pretty good at that, compared to linux - in general 2019-07-29 15:07:21 for example, years ago there was hotplug scripts via /proc/sys/kernel/hotplug 2019-07-29 15:07:25 then there was udev 2019-07-29 15:07:35 then there was systemd 2019-07-29 15:07:48 and users had to adapt to changes all the time 2019-07-29 15:08:05 once there was dnotify, then there was inotify 2019-07-29 15:08:38 once there was sys v boot scripts, then there was upstart then there was systemd 2019-07-29 15:08:55 there was constant changes 2019-07-29 15:09:34 thats one of the things i have always liked with BSDs: they dont have that constant changes 2019-07-29 15:10:02 now, no changes is not good either 2019-07-29 15:10:16 you need to be able to break things once in a while to make progress 2019-07-29 15:10:28 but changes always comes with a price 2019-07-29 15:10:38 even rename packages comes with a price 2019-07-29 15:12:07 for example, we have lists of packages in scripts/mkimg.*.sh that tells which packages should be included in the releases 2019-07-29 15:12:48 if package is renamed, that list needs to be updated too 2019-07-29 15:13:07 users have often similar scripts 2019-07-29 15:13:17 apk add $list_of_packages 2019-07-29 15:13:38 we try to be backwards compat by adding provides etc 2019-07-29 15:14:23 but there is always risk that something breaks for someone in unexpected ways 2019-07-29 15:14:49 when something breaks, it costs time of the user 2019-07-29 15:15:02 they maybe report it upstream 2019-07-29 15:15:12 and we need to spend time on reading the bug report and respond to it 2019-07-29 15:15:21 so it cost time for us also 2019-07-29 15:15:58 my point here is that if we do a change, it should be worth the cost 2019-07-29 15:16:55 specially if it potentially breaks things for end users 2019-07-29 15:17:38 <_ikke_> What do you think about the coupling/decoupling of alpine package names to upstream project names 2019-07-29 15:17:42 so we will not rename lots of packages just because some dev likes those names better 2019-07-29 15:18:15 nor will we rewrite 1000+ APKBUILDs to have a new coding style that some new dev like better 2019-07-29 15:18:58 i think we should try to stick to upstream names when possible or when it makes sense 2019-07-29 15:19:11 <_ikke_> yes, I agree 2019-07-29 15:19:23 i think this is pretty good: http://ix.io/1PQ6 2019-07-29 15:19:33 except of the last section about patches 2019-07-29 15:19:38 <_ikke_> What I'm referring to is for example using $pkgname in the source url for example 2019-07-29 15:20:18 <_ikke_> which couples the pkgname tightly to the upstream name 2019-07-29 15:20:25 you mean source="http://example.com/$pkgname-$pkgver.tar.gz" 2019-07-29 15:20:29 <_ikke_> yes 2019-07-29 15:20:50 vs source="http://example.com/example-$pkgver.tar.gz" 2019-07-29 15:21:20 <_ikke_> It can be static or another variable, but at least decoupled from pkgname 2019-07-29 15:21:36 personally i prefer the latter 2019-07-29 15:21:42 <_ikke_> Right 2019-07-29 15:22:08 right, i saw tcely introduced some style updates which added _pkgname=$pkgname 2019-07-29 15:22:14 <_ikke_> My reasoning is: if we *do* want to rename packages, it requires less changes 2) if someone wants to make a specialized / variant of the package, it's also easier 2019-07-29 15:22:46 yes 2019-07-29 15:23:12 i agree 2019-07-29 15:23:25 but i dont think it always makes sense to add a new variable 2019-07-29 15:23:31 <_ikke_> no, me neither 2019-07-29 15:23:43 and i think _pkgname is a bad variable name for upstream_name 2019-07-29 15:24:00 I'm trying to stick to '$pkgname-$pkgver' whenever is possible 2019-07-29 15:24:20 <_ikke_> mps: the problem is when you use that in the url, we *cannot* change $pkgname 2019-07-29 15:24:26 i normally use example-$pkgver 2019-07-29 15:24:56 the argument against my practice is DRY 2019-07-29 15:25:03 ncopa: i agree that _pkgname is bad, sadly _upstreamname, maybe _projectname ? 2019-07-29 15:25:36 <_ikke_> ncopa: some things are accidentally coupled 2019-07-29 15:25:46 _projname is better than _upstrname 2019-07-29 15:25:59 <_ikke_> The fact that pkgname and the url match at some point, does not mean they match always 2019-07-29 15:26:06 yes 2019-07-29 15:26:14 yes _upstreamname is the most explicit but too long 2019-07-29 15:26:32 _ikke_: which is why think its bad idea to use $pkgname everywhere 2019-07-29 15:26:37 <_ikke_> Me too 2019-07-29 15:26:48 also 2019-07-29 15:27:18 in thinngs like: source=http://example.com/foobar/foobar-$pkgver.gz 2019-07-29 15:27:42 if pkgname=foobar and you do source=http://example.com/$pkgname/$pkgname-$pkgver.gz 2019-07-29 15:27:57 then you cannot copy paste it to find new version 2019-07-29 15:28:16 i often mark the http://example.com/foobar/ with mouse and paste into browser 2019-07-29 15:28:32 but if $pkgname is there, it breaks stuff 2019-07-29 15:28:44 i mean it breaks the copy/paste operation 2019-07-29 15:29:06 so yeah, i think we should only use $pkgname where it makes sense 2019-07-29 15:29:14 not everywhere 2019-07-29 15:29:41 and i think we can use the litteral value instead of a variable name in most cases 2019-07-29 15:29:57 its not very often it makes sense to use a variable for it imho 2019-07-29 15:30:45 upstreamversion or proejctversion is other thing 2019-07-29 15:31:06 thats often useful to have a variable for 2019-07-29 15:37:58 Yup, sounds good to mw 2019-07-29 15:38:45 i prefer having a _upstream= variable 2019-07-29 15:38:52 makes it easier in case upstream itself renames 2019-07-29 15:44:18 they dont often rename upstream, and when they do, a search/replace is relatively simple to do 2019-07-29 15:47:10 Fair I only saw 2 or 3 renames in my Void Linux time and don't even remember them 2019-07-29 15:53:17 so, as you understand, i want prevent meaningless changes 2019-07-29 15:53:41 and when we do changes, i want those to be well thought through 2019-07-29 15:53:50 so we dont need to change soon again 2019-07-29 15:55:04 but at the same time, im not in the "if it aint broke, dont fix it" camp either 2019-07-29 15:55:24 i think we should be able to do changes and breaking changes once in a while 2019-07-29 15:55:38 Nice 2019-07-29 15:55:45 but we should try keep the number of breaking changes down 2019-07-29 15:57:07 and when we do breaking changes, we should have good reasons 2019-07-29 16:00:40 hmm, for the sake of copy-paste with mouse when upgrading we change pkgver var and don't use $pkver in source field? 2019-07-29 16:01:41 mps: That won't make a difference when upgrading from my view 2019-07-29 16:02:06 you'll have two lines changed 2019-07-29 16:02:08 if the link works or not it doesn't matter you want to have the link to the directory to check for new versions, you will have to cut apart the projectname-$pkgver.tar.gz part anyways 2019-07-29 16:02:58 ah ok, looks like i misread original msg 2019-07-29 16:03:14 which 2 lines ? 2019-07-29 16:03:25 pkgver should always be variable 2019-07-29 16:03:29 never litteral 2019-07-29 16:03:37 pkgver and source, sorry for misread 2019-07-29 16:04:03 pkgname can be litteral mostly imho 2019-07-29 16:04:26 Yup, since that's not changed nearly as often as pkgver is 2019-07-29 16:04:38 So we are taking the Void route :D 2019-07-29 16:04:42 that makes sense to me 2019-07-29 16:04:53 Void also recommends using the written out name instead of $pkgname 2019-07-29 16:05:56 if something changes pkgname in source (path) it is good to have it in diff log 2019-07-29 16:07:34 and I agree with that what ncopa wrote above, we need to adapt but gradually and not making big breakage 2019-07-29 16:09:00 and we also have to strive to some consistency in naming, again where it makes sense 2019-07-29 16:10:38 maxice8: im glad its not just me who thinks that makes sense :) 2019-07-29 16:48:35 :D 2019-07-29 16:52:09 So, should abuild add support for parsing /usr/share/pkgconfig ? 2019-07-29 16:52:32 as you mentioned in private 2019-07-29 16:52:37 its arch specific 2019-07-29 16:52:38 so no 2019-07-29 16:52:51 lets use /usr/lib/pkgconfig 2019-07-29 16:53:49 Should we maybe automatically move that then? 2019-07-29 16:55:08 hmm 2019-07-29 16:55:24 it should parse the entire PKG_CONFIG_PATH 2019-07-29 16:58:54 which is unset by default 2019-07-29 16:58:58 but yes, good point 2019-07-29 16:59:24 @ncopa libebml escaped on 3.10 2019-07-29 17:01:02 maxice8: it needs changes 2019-07-29 17:01:07 i can fix it for you 2019-07-29 17:01:56 ah ok, ty 2019-07-29 17:03:49 maxice8: kaniini is right, abuild should parse entire PKG_CONFIG_PATH 2019-07-29 17:04:12 ncopa: yes, but you can ask pkgconf for the default path 2019-07-29 17:05:23 kaniini@localhost:~$ pkgconf --variable=pc_path pkg-config 2019-07-29 17:05:23 /usr/lib64/pkgconfig:/usr/share/pkgconfig 2019-07-29 17:06:41 got /usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig 2019-07-29 17:06:41 here 2019-07-29 17:09:11 yeah 2019-07-29 17:09:19 i'm using fedora on my laptop ;) 2019-07-29 17:09:44 well the local ones certainly should be ignored 2019-07-29 17:10:36 the local ones are irrelevant in an abuild environment 2019-07-29 17:10:52 because you should be using buildlab or abuild rootbld to build in a container 2019-07-29 17:14:05 yes that is why they should be ignored 2019-07-29 17:15:11 well filtering them out is trivial 2019-07-29 17:15:37 yes 2019-07-29 17:37:02 I'm gonna have another look at elixir tomorrow, I need 1.9 for some stuff 2019-07-29 17:58:41 @ncopa i did a blind patch for /usr/share/pkgconfig support 2019-07-29 17:58:42 i'll do a few tests now 2019-07-29 18:05:37 ncopa: the last commit on abuild is broken D: 2019-07-29 18:07:09 ok the patch works! :D 2019-07-29 18:10:02 ncopa: https://github.com/alpinelinux/abuild/pull/99 2019-07-29 18:38:15 _ikke_: 18.4 of atools is out 2019-07-29 18:39:34 <_ikke_> alright 2019-07-29 18:40:02 has your new pkgname-used-in-source lint tag 2019-07-29 18:40:09 <_ikke_> Noticed :) 2019-07-29 18:40:12 <_ikke_> pushed 2019-07-29 19:28:29 I got a pr for adding support for parsing pkg-config files in /usr/share/pkgconfig 2019-07-29 19:29:19 should we also move /usr/share/cmake files to _dev ? 2019-07-29 19:54:57 ncopa: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas)#Changes_in_abuild i wrote an abuild section 2019-07-29 19:56:27 <_ikke_> maxice8: Probably should also mention something about deprecating python 2 in there I guess 2019-07-29 19:58:11 yes 2019-07-29 19:58:13 deprecating or removing? 2019-07-29 19:59:31 artok: it is deprecated and ddevault and others are actively trying to remove it 2019-07-29 20:01:04 <_ikke_> I don't think we officially deprecated python2 yet 2019-07-29 20:01:19 <_ikke_> At least, publically 2019-07-29 20:02:34 <_ikke_> https://wiki.alpinelinux.org/wiki/Python_package_policies mentions something about this, but I don't think it counts as a public announcement 2019-07-29 20:28:56 <_ikke_> maxice8: I ran the raw mail through xxd, and I don't see any 0D characters in there 2019-07-29 20:30:39 it happens to all mails and doesn't happen to others 2019-07-29 20:30:42 i wonder what is screwing up on my end 2019-07-29 20:39:56 <_ikke_> does aerc also support local mailboxes? 2019-07-29 20:40:16 <_ikke_> (watching the screencast atm) 2019-07-29 20:41:13 <_ikke_> I see maildir support 2019-07-29 21:18:26 <_ikke_> I gather it does not support threaded views (yet)? 2019-07-30 05:23:31 PureTryOut: I can't push to main, is it ok if i move utmps to community now ? 2019-07-30 05:56:06 ncopa: good morning 2019-07-30 07:09:23 morning 2019-07-30 07:11:24 maxice8: i saw you updated osinfo-db 2019-07-30 07:11:40 reminds me that we should upstream the alpine data to osinfo-db 2019-07-30 07:26:05 eh, too much work 2019-07-30 07:28:43 Lol 2019-07-30 08:10:51 Got pr9773 to pr9777 as secfixes for main/redis 2019-07-30 09:12:18 Cogitri: what is the status of pr9353? 2019-07-30 09:12:25 can it be merged as is? 2019-07-30 09:13:38 No, currently work in progress 2019-07-30 10:46:40 ncopa: Yup, I should put a WIP on it. I think I mailed down the error at least, so I hope that I'll be able to fix it soon 2019-07-30 10:49:11 great! 2019-07-30 20:33:21 I see both mariadb and mariadb-connector-c have been upgraded today, but now they conflict as they both own `/usr/lib/mariadb/plugin/client_ed25519.so` 2019-07-30 22:10:30 _ikke_: new atools is out 2019-07-31 01:03:38 pr9787 is good to go 2019-07-31 07:11:27 uh that openjdk to 3.9 backport is failing hard 2019-07-31 07:12:28 PureTryOut: the patches you are sending don't appear in the patches section, only in the archives. 2019-07-31 07:23:27 Uhm ok, so what can I do about it? CC ddevault 2019-07-31 07:30:04 Hello, I want to rebuild the kernel. I am on Alpine 3.10. I follow instruction in https://wiki.alpinelinux.org/wiki/Custom_Kernel. However, I do not see the branch corresponding to 3.10 in the https://git.alpinelinux.org/abuild/ How should I proceed? 2019-07-31 07:31:20 'git tag --list' in aports tree 2019-07-31 07:33:51 or look https://git.alpinelinux.org/aports/ 2019-07-31 07:34:04 ah ok, v3.10 is shown after v.3.1.4 not in the end... 2019-07-31 07:34:14 thank you! 2019-07-31 07:35:01 alphabetical order, not numeric 2019-07-31 08:52:17 do you know how much disk space (approx.) do I need to compile new kernel? 2019-07-31 08:52:56 maxice8: your git commit hook to upgrade is nice, saves me some typing and possible error, although I fear I will become lazy :) 2019-07-31 08:54:30 So you're gonna stop using it? :D 2019-07-31 08:56:00 kiwi100: depends on kernel version, size of pkg's of makedepends and number of modules etc, 2-4 GB approx 2019-07-31 08:56:12 maxice8: no, just kidding 2019-07-31 08:56:31 it is nice add-on 2019-07-31 08:56:43 mps: good good :D 2019-07-31 09:05:31 maxice8: thanks for making it :-) 2019-07-31 09:12:09 @ncopa the erlang and elixir commits had the wrong title D: 2019-07-31 09:13:36 oh... 2019-07-31 09:13:48 i just saw the "is good to go".... 2019-07-31 09:22:00 maxice8: seems you only pushed half of my Kodi patched 2019-07-31 09:22:01 *patches 2019-07-31 09:22:16 it is a work in progress 2019-07-31 09:24:37 _ikke_: ping 2019-07-31 09:27:55 ncopa: you got bamboozled 2019-07-31 09:30:06 A work in progress? 2019-07-31 09:30:16 yes 2019-07-31 09:41:25 I'm not sure what you mean... 2019-07-31 09:41:34 i'm still working on merging it 2019-07-31 09:41:53 Uh... 2019-07-31 09:57:35 _ikke_: new atools 2019-07-31 10:01:59 PureTryOut: Turns out Kodi is a big package while fstrcmp and fmt are not :D 2019-07-31 10:47:01 Well, yeah, but I'm not sure what you have to do besides merging my commit lol 2019-07-31 10:47:50 Compile and do the least basic of testing 2019-07-31 10:57:00 Ah. Yeah if you're compiling it yourself, then it'll take a while lol 2019-07-31 10:57:32 maxice8: +1^(2^8) 2019-07-31 10:57:54 mps: ? 2019-07-31 11:14:35 kodi-x11 failed to link due to exhausting my notebook's memory 2019-07-31 11:30:13 PureTryOut[m]: can you share the patch link with me? 2019-07-31 11:35:51 maxice8: 1 plus raised to 256 :) 2019-07-31 11:36:20 which is still 1 but you understand 2019-07-31 12:39:22 ddevault: https://lists.alpinelinux.org/~alpine/aports/%3C20190730224552.19614-4-bribbers%40disroot.org%3E 2019-07-31 12:39:41 thanks 2019-07-31 12:39:49 I think this hit the same libgit2 bug for which a fix was merged last week 2019-07-31 12:39:54 should resolve itself once the new libgit2 release ships 2019-07-31 12:40:31 Ah cool 2019-07-31 13:08:44 <_ikke_> maxice8: I'll look at it tonight 2019-07-31 17:23:53 Hello 2019-07-31 17:24:42 I have a patch to update Asterisk from 16.4.1 to 16.5.0 (+ ldap subpackage support). How can I submit it? 2019-07-31 17:25:53 <_ikke_> vk496: via a pull request on github or a patch to the mailing list 2019-07-31 17:27:12 oh, github. Nice! 2019-07-31 17:27:19 thnks _ikke_ 2019-07-31 17:27:21 <_ikke_> maxice8: is it me, or do you have on duplicate test for the braces 2019-07-31 17:27:33 <_ikke_> Note that we are moving to gitlab 2019-07-31 17:27:38 It is possible 2019-07-31 17:27:48 _ikke_: my main repo is on gitlab 2019-07-31 17:27:59 Bug gitlab hosted by alpine can't do public repos 2019-07-31 17:28:07 So I can't use it in source 2019-07-31 17:28:15 <_ikke_> "valid variable bracing with letter" and "valid variable bracing with capital letter" 2019-07-31 17:28:22 <_ikke_> maxice8: it can, but only if an admin makes it public 2019-07-31 17:28:55 _ikke_: letter is for minor letter 2019-07-31 17:28:59 a A 2019-07-31 17:29:02 <_ikke_> It uses the same test 2019-07-31 17:29:17 :D then yes it is wrong 2019-07-31 17:29:27 <_ikke_> 'pkgname="${pypi_name}Alpine"' in both cases 2019-07-31 17:29:31 I'm laying down watching YouTube Meme videos I'll take care of it later 2019-07-31 17:29:36 <_ikke_> sure, np 2019-07-31 17:29:44 <_ikke_> it's not a big issue, just noticed it when reading 2019-07-31 17:34:23 <_ikke_> maxice8: I pushed 18.7 2019-07-31 17:34:33 Nice 2019-07-31 17:51:49 Done :P 2019-07-31 17:51:51 https://github.com/alpinelinux/aports/pull/9798 2019-07-31 18:38:05 is the s390x edge builder stuck? 2019-07-31 18:38:30 looks like it might just be busy 2019-07-31 18:42:22 no, s390x is on minio for a long time 2019-07-31 19:06:13 ping pong tmhoang 2019-07-31 19:18:23 killed it 2019-07-31 19:18:45 <_ikke_> murderer 2019-07-31 20:16:22 danieli: is there any way with pip to build native extensions with all threads? 2019-07-31 20:18:03 _ikke_: ^ ? 2019-07-31 20:18:17 not sure, let me check 2019-07-31 20:18:27 clandmeter: try `pip install --install-option="--jobs=6"'? 2019-07-31 20:18:33 if its using make it could 2019-07-31 20:18:38 i think i tried that 2019-07-31 20:18:39 and it failed 2019-07-31 20:18:40 yeah, you could wrap make for instance 2019-07-31 20:18:51 i can try it again 2019-07-31 20:19:17 if it didn't work it probably won't do much 2019-07-31 20:19:52 could you pass make flags to make through setup.py? 2019-07-31 20:20:06 i dont think its running make 2019-07-31 20:20:10 esle i can set makefilags 2019-07-31 20:20:18 gotcha. got the source so I can test? 2019-07-31 20:20:23 pikepdf 2019-07-31 20:20:34 as it is in our repos? 2019-07-31 20:20:43 hm, we don't haev it 2019-07-31 20:20:44 have* 2019-07-31 20:20:44 dont think we have it 2019-07-31 20:20:51 can I have the apkbuild? 2019-07-31 20:20:58 its pip 2019-07-31 20:21:08 aaah just installing it, gotcha 2019-07-31 20:21:13 no apkbuild involved 2019-07-31 20:21:28 building a dockerfile 2019-07-31 20:21:31 and i hate waiting :) 2019-07-31 20:21:50 ha, yeah, I'm spoiled when it comes to parallel processing to 2019-07-31 20:21:51 o 2019-07-31 20:29:13 danieli: it passes the jobs to setuptools 2019-07-31 20:29:16 which errors 2019-07-31 20:29:20 I see 2019-07-31 20:31:39 clandmeter: I'm gonna test something and I'll pass you a patch if it works 2019-07-31 20:31:49 grazie 2019-07-31 20:33:37 danieli: its not only pikepdf thats slow 2019-07-31 20:34:09 pillow lxml... all are terrible on single thread 2019-07-31 20:37:53 ah, darn it, it's not using make *at all* 2019-07-31 20:39:08 aaah, I got it, I'm a dummy dum 2019-07-31 20:39:13 clandmeter: set MAX_CONCURRENCY 2019-07-31 20:39:16 So yesterday I apk update, apk upgrade and now all the letters are replaced by squares, I didin't see any bug filled for that. Should I filed one ? 2019-07-31 20:39:20 it defailts to `min(4, cpu_count())' 2019-07-31 20:39:22 I'm using Awesome 2019-07-31 20:39:27 defaults( 2019-07-31 20:39:48 is that en env var? 2019-07-31 20:39:50 KH405: I heard people encountered issues after a pango update, apparently freedesktop changed some things 2019-07-31 20:39:51 clandmeter: yes 2019-07-31 20:39:58 see mp_compile.py 2019-07-31 20:40:20 danieli, Ok, so i'll just wait for a fix then ^^' 2019-07-31 20:40:35 KH405: if there is no issue, it'd be great if you could make one, because that's a fairly severe issue 2019-07-31 20:41:00 I'm not entirely sure what we can do about it though, might have to consult with the upstream source(s) 2019-07-31 20:41:32 I never really did that, and don't remember at all what updated ^^' 2019-07-31 20:41:34 I can try 2019-07-31 20:42:50 But yeah, made my GUI completly unusable, so I guess it's a pretty huge issue :P 2019-07-31 20:43:02 Do you know if it's happening with other DE/WM ? 2019-07-31 20:43:04 it screwed over i3 too 2019-07-31 20:43:11 it uses pango and it broke for people 2019-07-31 20:43:27 danieli: still only seeing a single gcc process 2019-07-31 20:43:50 clandmeter: hrm.. it said it's building with 4 for me, and said 8 if I configured it to use 8 2019-07-31 20:44:12 but you are installing it directly or as a dep? 2019-07-31 20:44:21 try install ocrmypdf 2019-07-31 20:44:50 installed it directly 2019-07-31 20:45:55 i must be holding it wrong 2019-07-31 20:46:07 it didn't build, just installed prebuilt wheel files 2019-07-31 20:46:12 which OS are you on? 2019-07-31 20:46:17 alpine ofc 2019-07-31 20:46:29 right, there probably aren't prebuilts for alpine 2019-07-31 20:46:35 I'm on Arch at the moment, I'll test in an Alpine container 2019-07-31 20:46:46 i just use pip3 install ocrmypdf 2019-07-31 20:47:00 and then its waiting for the sun to go down 2019-07-31 20:47:12 or come up in this case 2019-07-31 20:47:39 we have sun here :) 70°N does that 2019-07-31 20:47:58 i can make a picture of a black sky :) 2019-07-31 20:48:13 its just a black square probably 2019-07-31 21:01:25 clandmeter: the build system is a mess and I don't care to go down that rabbit hole right now, I'll keep digging for hours 2019-07-31 21:02:25 no problem mate 2019-07-31 21:02:49 thx for checking 2019-07-31 21:04:42 I know it's possible but it'll take some printf debugging and grepping