2019-07-01 00:41:09 <ddevault> so there's a pattern I've been seeing in my work on alpine & sr.ht
2019-07-01 00:41:30 <ddevault> 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 <ddevault> the latter being a process which can take months
2019-07-01 00:41:53 <ddevault> 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 <Cogitri> Yes?
2019-07-01 00:42:01 <ddevault> open to anyone's thoughts on this
2019-07-01 00:42:39 <Cogitri> 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 <ddevault> yeah reviews are getting faster
2019-07-01 00:43:04 <ddevault> moving to community isn't something I've done a lot of, I don't know the process
2019-07-01 00:43:10 <ddevault> is there some criteria that needs to be met?
2019-07-01 00:43:32 <maxice8> ddevault: can be moved as soon as it is verified to work
2019-07-01 00:43:38 <Cogitri> Yup
2019-07-01 00:43:43 <ddevault> okay, cool
2019-07-01 00:43:55 <maxice8> 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 <ddevault> 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 <ddevault> but this is my problem, not yours :)
2019-07-01 00:45:54 <ddevault> other things that have been on my mind recently: python 2 deprecation and aports python normalization, and riscv64
2019-07-01 00:46:10 <ddevault> the latter was blocked on the team restructuring thing, which seems to be dead in the water
2019-07-01 00:46:27 <ddevault> err, former
2019-07-01 00:46:30 <ddevault> python was blocked
2019-07-01 00:46:47 <ddevault> 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 <Cogitri> Neat. I don't really know riscv64 too well, how fast can I expect it to be?
2019-07-01 00:50:26 <ddevault> my board is pretty fast
2019-07-01 00:50:48 <ddevault> I build all of my alpine packages natively, not cross-compiled
2019-07-01 00:51:04 <Cogitri> Is it about the speed of a RPI?
2019-07-01 00:51:08 <ddevault> much faster
2019-07-01 00:51:30 <Cogitri> Oh, nice
2019-07-01 00:52:04 <ddevault> lemme build a reasonably big package and measure it
2019-07-01 00:52:23 <ddevault> cd aports/main/perl && time abuild -rf
2019-07-01 00:53:45 <ddevault> just for fun let's compare it to 24 cores of bleeding edge AMD x86_64 tech
2019-07-01 01:03:09 <ddevault> 24x x86_64: 3m 41.50s
2019-07-01 01:23:10 <ddevault> 4x riscv64: 23m 58.93s
2019-07-01 01:23:24 <ddevault> don't have a rpi with alpine prepared for testing with
2019-07-01 01:23:27 <ddevault> Cogitri: ^
2019-07-01 01:27:22 <Cogitri> Oh, cool, thanks for the test
2019-07-01 02:09:31 <Cogitri> mps: How are you using Adelie's Rust tarballs? At least the aarch64 ones explode immediately for me :/
2019-07-01 06:49:08 <tmhoang> Morning
2019-07-01 06:49:38 <Danct12> Good afternoon
2019-07-01 06:49:39 <tmhoang> breakfast question, how long are community packages maintained ? 6 months ?
2019-07-01 06:49:44 <Danct12> It's 13:49 :)
2019-07-01 06:49:45 <Cogitri> Morning, tmhoang
2019-07-01 06:49:54 <tmhoang> enjoy the sunday night :)
2019-07-01 06:50:09 <Danct12> It's monday here. :P
2019-07-01 06:50:34 <maxice8> tmhoang: morning, let me check my backlog
2019-07-01 06:50:34 <Cogitri> tmhoang: Yup, 6 months
2019-07-01 06:50:43 <tmhoang> thanks
2019-07-01 06:51:47 <maxice8> ncopa said "only latest stable"
2019-07-01 06:54:09 <Cogitri> (which is roughly 6 months)
2019-07-01 07:05:07 <ncopa> morning
2019-07-01 07:06:31 <danieli> morning
2019-07-01 07:19:43 <mps> Cogitri: will try mentioned PR in few minutes
2019-07-01 07:20:32 <Cogitri> Thank you
2019-07-01 07:21:03 <mps> 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 <mps> I see your msg's with to early time for me, we are in distant TZ's probably
2019-07-01 07:40:23 <Cogitri> Ah, .no, my sleep rhythm was just a bit messed up yesterday :)
2019-07-01 07:40:23 <Cogitri> It's 9:40 here right now
2019-07-01 07:40:56 <mps> aha, we are then in same TZ
2019-07-01 07:42:31 <danieli> same here
2019-07-01 08:51:24 <mps> Cogitri: finished build with error. are there paste service which accepts few MB size files
2019-07-01 08:52:07 <mps> or, to post you relevant part to tpaste?
2019-07-01 08:54:25 <Cogitri> I usually just Github gists for that
2019-07-01 08:56:23 <mps> can I upload it there without account, anonymously
2019-07-01 08:59:35 <mps> Cogitri: here it is http://arvanta.net/mps/webkit2gtk-build.log.gz
2019-07-01 09:31:24 <roigr> Hi all. First time I'm using IRC so I hope I'm doing it correctly =D
2019-07-01 09:32:33 <Gottox> looks good so far. ;)
2019-07-01 09:33:20 <roigr> 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 <danieli> 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 <danieli> roigr: try adding `--without-readline' to the `./configure' arguments
2019-07-01 09:39:57 <danieli> i can confirm that gdbm uses readline for line editing in gdbmtool etc
2019-07-01 09:40:22 <roigr> How can it not exists in the official APKINDEX, assuming we are using the same APKBUILD file?
2019-07-01 09:42:06 <roigr> also, gdbm is just an example. I also checked fsdisk and there are several more
2019-07-01 09:46:03 <danieli> readline isn't added as a dependency in our APKBUILD
2019-07-01 09:46:27 <danieli> it might be that you have readline preinstalled on your system and that gdbm autodetects it
2019-07-01 09:47:00 <danieli> in my opinion our build should explicitly use --without-readline when we build it without readline support
2019-07-01 09:47:21 <danieli> because readline is not in the list of dependencies
2019-07-01 09:49:13 <roigr> 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 <roigr> 2
2019-07-01 10:02:21 <TBB> 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 <TBB> not that my opinion would explain readline updating problems
2019-07-01 10:06:07 <danieli> not abuild
2019-07-01 10:06:21 <danieli> when readline is installed, gdbm will most likely be built with support for readline
2019-07-01 10:06:27 <danieli> and abuild traces that dependency
2019-07-01 10:06:58 <danieli> 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 <roigr> 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 <roigr> 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 <Cogitri> Sadly that isn't really a thing, automagic deps are in way too many packages
2019-07-01 10:16:56 <roigr> '=(
2019-07-01 10:19:15 <TBB> 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 <TBB> 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 <Cogitri> 
ACTION can recommend docker-abuild

2019-07-01 10:21:03 <TBB> I've, of course, built my own...
2019-07-01 10:23:22 <roigr> I actually already had one..
2019-07-01 10:30:26 <tmhoang> 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 <Cogitri> The package doesn't have any docs apparently
2019-07-01 10:32:06 <Cogitri> The error message is pretty bad, it means "no docs detected, nothing to put into the -docs subpackage"
2019-07-01 10:32:25 <TBB> those docs are in /usr/local, which is probably not what abuild expects
2019-07-01 10:32:25 <tmhoang> right, I only see a couple of man pages
2019-07-01 10:32:31 <Cogitri> <TBB "those docs are in /usr/local, wh"> `/usr/local` seems wrong
2019-07-01 10:32:46 <Cogitri> Most likely a `--prefix=/usr` missing
2019-07-01 10:32:56 <tmhoang> hah
2019-07-01 10:33:19 <Cogitri> tmhoang: man belongs to -doc too
2019-07-01 10:37:25 <tmhoang> Cogitri: --prefix=/usr did the trick thanks :D
2019-07-01 10:37:51 <Cogitri> 👍
2019-07-01 10:39:57 <errn0[m]> Can anyone point me, how can I generate a separate -doc package ?
2019-07-01 10:40:45 <danieli> mps: would you mind testing pr9132 on armv7 when you have some time?
2019-07-01 10:41:00 <danieli> I am unable to reproduce the error Drone CI had
2019-07-01 10:41:22 <danieli> but check in elixir was disabled on aarch64, I re-enabled it for that PR
2019-07-01 10:42:38 <mps> danieli: yes, only give 15-20 minutes to finish some of $dayjobs
2019-07-01 10:42:52 <danieli> no worries, do it when you have time, it can wait a bit
2019-07-01 10:43:05 <danieli> I'm also super busy with $dayjob at the moment
2019-07-01 10:43:27 <danieli> 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 <mps> ok, will do
2019-07-01 10:51:21 <Cogitri> errn0: Take other APKBUILDs for the APKBUILD reference wiki page as reference
2019-07-01 10:51:49 <Cogitri> TL;DR add "$pkgname-doc" to "subpackages"
2019-07-01 10:56:59 <errn0[m]> cogitri: I see. Thank you :)
2019-07-01 11:24:24 <mps> danieli: should I first build erlang and then elixir or order is not important
2019-07-01 11:24:33 <danieli> erlang first, elixir depends on it
2019-07-01 11:24:45 <danieli> hm
2019-07-01 11:24:51 <mps> I thought so, ok :)
2019-07-01 11:24:52 <danieli> we already have recent erlang in our repos, you don't have to build it
2019-07-01 11:25:00 <danieli> it's recent enough that won't be what causes the issue
2019-07-01 11:25:04 <danieli> that it*
2019-07-01 11:25:13 <mps> aha, then just elixir
2019-07-01 11:25:16 <danieli> yes
2019-07-01 11:25:52 <mps> you have two commits in this PR so I thought that have to build both
2019-07-01 11:26:53 <danieli> yes, i forgot that the erlang commit is a small change for a second :)
2019-07-01 11:26:59 <danieli> the elixir one is a major upgrade
2019-07-01 11:28:07 <mps> I started build of elixir, if it fails I will then build erlang and again will try elixir
2019-07-01 11:38:34 <mps> danieli: >>> elixir: Build complete at Mon, 01 Jul 2019 11:32:33 +0000 elapsed time 0h 6m 9s
2019-07-01 11:38:57 <danieli> thank you - I will do some testing on aarch64
2019-07-01 11:39:08 <danieli> 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 <mps> happy to be of help
2019-07-01 11:40:53 <roigr> 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 <mps> roigr: readline or readline-dev
2019-07-01 11:41:29 <mps> readline is not problem
2019-07-01 11:41:40 <roigr> readline (libreadline.so)
2019-07-01 11:41:55 <mps> I have it everywhere
2019-07-01 11:42:42 <mps> oh, not everywhere but on most building boxes
2019-07-01 11:44:37 <roigr> 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 <roigr> bash-4.4# apk add readline -l
2019-07-01 11:45:59 <roigr> bash-4.4# apk add readline readline-dev libhistory -l
2019-07-01 11:45:59 <roigr>             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 <mps> you have a bash, it pulls readline
2019-07-01 11:47:26 <mps> use busybox ash on builder, minimum deps
2019-07-01 11:48:11 <roigr> I will try.
2019-07-01 11:49:13 <roigr> I looked at the build script, and it use sh.. #!/bin/sh
2019-07-01 11:49:41 <tmhoang> CFLAGS += ... does not work with ash right ? We might have to do something like : CFLAGS = "$CFLAGS ..." ?
2019-07-01 11:52:15 <mps> roigr: /bin/sh is busybox ash
2019-07-01 11:52:37 <mps> tmhoang: usually
2019-07-01 11:52:44 <roigr> so that what we are using...
2019-07-01 11:53:53 <mps> ls -l /bin/sh => lrwxrwxrwx 1 root root 12 Jun 30 11:34 /bin/sh -> /bin/busybox
2019-07-01 11:55:27 <roigr> bash-4.4# ls -l /bin/sh
2019-07-01 11:57:30 <tmhoang> mps: any other way ?
2019-07-01 11:57:44 <roigr> is there a place to see the script/docker Alpine use to build the official repository?
2019-07-01 11:58:11 <danieli> 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 <danieli> i don't remember the details though
2019-07-01 11:58:56 <roigr> =L
2019-07-01 11:59:20 <tmhoang> roigr : I don't know if we even use alpine-sdk ?
2019-07-01 11:59:39 <danieli> alpine-sdk is assumed to be installed on all the builders iirc
2019-07-01 12:00:06 <tmhoang> maybe ncopa could help ^
2019-07-01 12:01:02 <roigr> 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 <mps> tmhoang: I don't know, to be honest I'm not expert in shell programming
2019-07-01 12:21:05 <danieli> tmhoang: += is a bash feature, use CFLAGS="$CFLAGS -your-flags"
2019-07-01 12:40:41 <mps> 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 <mps> do we need separate patch for 3.9 or one of previous could be applied
2019-07-01 12:43:37 <mps> and I'm not sure if we need to upgrade 10.8 in Alpine v3.8
2019-07-01 13:24:28 <tmhoang> anyone know what is the difference between libunwind and llvm-libunwind ?
2019-07-01 13:25:34 <mps> tmhoang: llvm-libunwind is LLVM version of libunwind lib
2019-07-01 13:28:32 <tmhoang> mps: so complete re-write or a wrapper ?
2019-07-01 13:30:21 <mps> I think it is rewrite/change to be used with llvm
2019-07-01 13:30:43 <mps> it is not wrapper, as I know
2019-07-01 13:31:07 <mps> I had to compile llvm-libunwind for llvm
2019-07-01 13:31:21 <mps> but never used it personally
2019-07-01 13:54:13 <Hacker1245> Hello, the mate-desktop-environment package seems to be broken in the edge repository
2019-07-01 13:57:26 <Cogitri> Define broken
2019-07-01 13:57:27 <Cogitri> Oh well
2019-07-01 14:16:10 <ncopa> mps: i can backport it
2019-07-01 14:23:58 <mps> ok, and maybe to 3.7 even, it is still supported afaik
2019-07-01 14:42:36 <ncopa> 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 <PureTryOut[m]> 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 <Cogitri> Yup
2019-07-01 14:57:32 <mps> 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 <Cogitri> Checkout the 3.x-stable branch and see if your patch applies
2019-07-01 14:59:30 <Cogitri> Then push/pr the thing I guess, no clue how to do it in pw workflow
2019-07-01 14:59:53 <danieli> hm
2019-07-01 14:59:59 <danieli> we have libmarco-private.so.2
2019-07-01 15:00:18 <danieli> guess mate-control-center has to be rebuilt
2019-07-01 15:01:41 <mps> Cogitri: for pw you do 'git send-email ....'
2019-07-01 15:13:20 <roigr> 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 <roigr> 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 <ncopa> roigr: iirc its only the test suite that causes circular buildtime deps
2019-07-01 15:29:14 <ncopa> Cogitri: FYI, im working on webkit2gtk 32 bit support. https://bugs.webkit.org/show_bug.cgi?id=199272
2019-07-01 15:29:26 <ncopa> seems like we need to disable the unified build stuff
2019-07-01 15:30:17 <Cogitri> Yup, but as mentioned in the bug that's badly broken in 2.24.x
2019-07-01 15:30:35 <Cogitri> Could you try my PR which builds webkit2gtk with CLang first?
2019-07-01 15:30:58 <Cogitri> pr9218
2019-07-01 15:35:44 <ncopa> it has build failures
2019-07-01 15:36:00 <ncopa>  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 <ncopa> 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 <roigr> 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 <Cogitri> Argh, had hoped the first patch fixed that
2019-07-01 16:03:41 <PureTryOut[m]> Could someone review/merge pr8764 and pr8736?
2019-07-01 16:10:13 <Cogitri> 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 <PureTryOut[m]> 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 <Cogitri> Well, I guess I equally dislike CMake and Autoconf, but if it works I'm not against it
2019-07-01 16:18:02 <Cogitri> Might wanna update the directfb comment though
2019-07-01 16:18:48 <PureTryOut[m]> Ah true
2019-07-01 16:20:41 <PureTryOut[m]> 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 <mps> we should keep upstream with decision
2019-07-01 16:31:12 <Cogitri> Meson is super nice, yes
2019-07-01 16:36:18 <ncopa> 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 <ncopa> dunno if that was intentional
2019-07-01 16:37:19 <PureTryOut[m]> ncopa: what package are you talking about?
2019-07-01 16:38:13 <PureTryOut[m]> Ah Mesa
2019-07-01 16:38:16 <PureTryOut[m]> That was unintentional, fixed it
2019-07-01 16:39:39 <PureTryOut[m]> Thanks for merging it!
2019-07-01 16:39:47 <ncopa> yw
2019-07-01 16:44:06 <ncopa> Cogitri: seems that it runs out of memory even when not using unified builds
2019-07-01 16:44:15 <wener_> please review pr9161
2019-07-01 16:44:18 <ncopa> webkit2gtk that is
2019-07-01 16:44:34 <Cogitri> Oof
2019-07-01 16:44:39 <Cogitri> That's pretty bad
2019-07-01 16:47:14 <ncopa> i wonder if its a bug in code or in compiler
2019-07-01 16:48:08 <Cogitri> It don't think you could call that a bug
2019-07-01 16:48:12 <ncopa> ... -o Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/llint/LowLevelInterpreter.cpp.o -c ../Source/JavaScriptCore/llint/LowLevelInterpreter.cpp
2019-07-01 16:48:19 <Cogitri> It's just that massive amounts of code take up massive amounts of resources to compile
2019-07-01 16:49:48 <ncopa> 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 <ncopa> i wonder if it is somethign that ends up as recursive defines or something
2019-07-01 16:50:58 <Cogitri> 
ACTION doesn't know cpp enough to be of help with that

2019-07-01 16:51:01 <wener_> @ncopa so there is a dup, should I close the pr9161 ?
2019-07-01 16:52:59 <Gottox> ncopa: that looks like a smart person trying to do something very stupid :D
2019-07-01 16:54:32 <wener_> 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 <ncopa> 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 <wener_> ok, wait a minute
2019-07-01 16:56:58 <ncopa> 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 <ncopa> so its currently double work for me ;)
2019-07-01 16:57:11 <ncopa> also
2019-07-01 16:57:22 <ncopa> from looking at it 30 seconds
2019-07-01 16:58:11 <ncopa> it looks like there are a handful packages that needs to be rebuilt
2019-07-01 16:58:22 <ncopa> so i dont think any can be merged as is
2019-07-01 17:01:15 <Cogitri> Yup, protobuf usually breaks ABI
2019-07-01 17:02:44 <ncopa> i wonder if ENABLE_C_LOOP is significant
2019-07-01 17:03:22 <ncopa> i dont even know what ENABLE_C_LOOP does
2019-07-01 17:03:57 <wener_> @ncopa done, please check https://github.com/alpinelinux/aports/pull/6848#issuecomment-507347089
2019-07-01 17:06:18 <wener_> pr9161 also upgraded grpc, which depends on protobuf, so I upgrade both in one pr
2019-07-01 17:07:01 <Cogitri> ncopa: From what I understand reading the CMake files you have to either enable JIT or C_LOOP
2019-07-01 17:17:31 <ncopa> wener_: good job! i will try have a look at it tomorrow
2019-07-01 17:18:38 <ncopa> Cogitri: looks like jit is disabled for x86
2019-07-01 17:19:11 <wener_> @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 <Cogitri> ncopa: Yes it is
2019-07-01 17:19:55 <Cogitri> But we don't have C_LOOP enabled there, huh
2019-07-01 17:20:00 <ncopa> Cogitri: i wonder if it was due to PaX kernel
2019-07-01 17:20:12 <ncopa> and i wonder if JIT works for arm at all
2019-07-01 17:20:21 <ncopa> maybe we we could try build with JIT
2019-07-01 17:20:54 <Cogitri> I'm pretty sure it failed at least for armv7, but giving it another go won't hurt
2019-07-01 17:22:12 <ncopa> wener_: i dont know. i dont understand the question
2019-07-01 17:23:55 <wener_> 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 <ncopa> wener_: we build from source whenever possible
2019-07-01 17:24:44 <wener_> 👌
2019-07-01 17:24:56 <ncopa> various reasons
2019-07-01 17:25:15 <ncopa> we have our own compile flags. we compile with optimize for size
2019-07-01 17:25:37 <ncopa> and our compiler has some hardening features enabled by default, like SSP and PIE
2019-07-01 17:26:28 <ncopa> Cogitri: my conclusion is that I'm no longer convinced the problem is unified builds
2019-07-01 17:26:52 <ncopa> i will continue tomorrow. have a nice evening everyone
2019-07-01 17:27:23 <Cogitri> Bye bye, ncopa :)
2019-07-01 17:34:47 <wener_> bye 😴
2019-07-01 21:39:44 <mps> 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 <PureTryOut[m]> "the new" is what version? 19.1.1 works fine afaik
2019-07-01 21:41:11 <mps> yes, 19.1.1
2019-07-01 21:42:10 <mps> it worked for me few days ago, but not now. says that cbindgen is missing for deps
2019-07-01 21:43:44 <Cogitri> Huh
2019-07-01 21:43:56 <Cogitri> That doesn't seen write, Mesa isn't written in Rust
2019-07-01 21:43:59 <mps> something is strange, not much changed and I can't see why it ask for cbindgen
2019-07-01 21:44:06 <Cogitri> s/write/right/
2019-07-01 21:44:06 <alpine-meetbot> Cogitri meant to say: That doesn't seen right, Mesa isn't written in Rust
2019-07-01 21:44:31 <mps> probably I messed something in my lxc, sorry for disturbance
2019-07-01 21:48:44 <mps> oh, cbindgen was installed earlier, 'apk del cbindgen' solve problem
2019-07-01 21:50:28 <Cogitri> 👍
2019-07-01 21:50:46 <Cogitri> Ah, also mps, have you tried Rust on armhf?
2019-07-01 21:51:04 <mps> no, only aarch64 and armv7
2019-07-01 21:52:45 <mps> if you want I can post somewhere rust 1.31 apk's
2019-07-01 21:52:54 <mps> for armv7, I mean
2019-07-01 21:54:16 <Cogitri> Uhh...why would you?
2019-07-01 21:55:33 <mps> I have no idea why, to be fair. just told from back head. maybe someone is interested
2019-07-01 21:57:30 <Cogitri> Ah no, we have Rust 1.35 tarballs already
2019-07-01 21:59:56 <mps> yes, I know, I have firefox-esr on aarch64 already ;)
2019-07-01 22:00:12 <mps> lazy to build it for armv7
2019-07-02 07:53:48 <mps> 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 <roigr> Hi all.
2019-07-02 08:20:14 <roigr> 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 <maxice8> weird, curl is in main/ so it should define their own static specifically for that case
2019-07-02 08:22:16 <maxice8> pr9258
2019-07-02 08:23:21 <maxice8> default_static is available with abuild from alpine 3.10.0
2019-07-02 08:23:27 <roigr> algitbot Thank!
2019-07-02 08:24:24 <roigr> 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 <mps> roigr: could bumping pkgrel help
2019-07-02 08:31:55 <mps> I mean, bump pkgrel, build curl locally and upgrade it
2019-07-02 08:34:00 <roigr> 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 <mps> then I misunderstood your question
2019-07-02 08:48:58 <roigr> 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 <roigr> algitbot solution indeed worked. Thanks!
2019-07-02 09:25:59 <ncopa> im not sure how to deal with https://github.com/alpinelinux/aports/pull/9246
2019-07-02 09:26:18 <ncopa> we dont really support packages in community that long
2019-07-02 09:26:33 <ncopa> however, we can apply security fixes on request, like in this case
2019-07-02 09:26:37 <Cogitri> And it's a rather big change
2019-07-02 09:26:54 <ncopa> that is what i am worried about
2019-07-02 09:27:04 <ncopa> it changes the way the packages are splitted
2019-07-02 09:27:13 <ncopa> introduces new packages etc
2019-07-02 09:29:48 <ncopa> i was thinking that we could maybe backport the fix
2019-07-02 09:29:59 <ncopa> but the fix seems pretty intrusive as well
2019-07-02 09:30:05 <ncopa> and seems to have various tries....
2019-07-02 09:30:14 <ncopa> https://github.com/moby/moby/pull/39357
2019-07-02 11:20:07 <roigr>  And.. another issue (Thanks for all the help so far!!)
2019-07-02 11:20:07 <roigr> s= in there..)
2019-07-02 14:38:46 <tmhoang1> Cogitri: would you mind briefly explain how you bootstrap cargo/rustc/rust-bootstrap ?
2019-07-02 14:39:08 <tmhoang1> using the last version that rust is dependent on other lang (C? )
2019-07-02 14:39:11 <tmhoang1> using the last version that rust is dependent on other lang (C? )  ?
2019-07-02 14:39:22 <Cogitri> Nop
2019-07-02 14:39:31 <tmhoang1> also I wonder if llvm-libunwind is actually required
2019-07-02 14:39:55 <tmhoang1> looking at other distro they dont seem to need libunwind. Has something to do with musl ?
2019-07-02 14:40:11 <tmhoang1> *llvm-libunwind
2019-07-02 14:40:21 <Cogitri> I crosscompile Rustc from x86_64-musl to the respective arch on Void Linux, which supports crosscompiling
2019-07-02 14:41:29 <Cogitri> <tmhoang1 "looking at other distro they don"> 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 <Cogitri> Crosscompiling on Alpine is a massive pain/not really possible, so yeah
2019-07-02 14:48:39 <tmhoang1> Cogitri: thanks for info :D
2019-07-02 14:54:38 <Cogitri> 👍
2019-07-02 14:57:14 <wener> @ncopa pr9161 failed because of travis-ci's linux kernel setting as before
2019-07-02 14:57:29 <wener> check pr5893
2019-07-02 23:44:19 <PureTryOut[m]> maxice8: I see you merged Falkon, did Qt5Webengine get fixed?
2019-07-02 23:44:57 <PureTryOut[m]> It's just in a page reload loop for me
2019-07-02 23:45:53 <Cogitri> I don't see changes to QtWebengine, so I doubt it
2019-07-02 23:46:04 <Cogitri> At least MellowPlayer still explodes for me
2019-07-03 00:23:06 <maxice8> PureTryOut: No it wasn't fixed yet
2019-07-03 08:03:43 <tmhoang1> should we move all community/ and testing/ packages that uses openjdk8 to using openjdk10 ?
2019-07-03 08:07:28 <danieli> if they build with it, i'd say use the latest one
2019-07-03 08:09:50 <danieli> 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 <tmhoang1> also, I think I can take a look on having adopopenjdk on Alpine
2019-07-03 08:16:06 <danieli> adopt?
2019-07-03 08:16:29 <tmhoang1> AdoptOpenJDK
2019-07-03 08:16:34 <danieli> i'm not sure we'd want to package prebuilt binaries though?
2019-07-03 08:16:53 <tmhoang1> it has source code available afaik
2019-07-03 08:17:23 <danieli> yes, so does a lot of software, but packaging prebuilt binaries is generally shady
2019-07-03 08:17:42 <danieli> and i feel like it would be unnecessary too, if we have our own builds
2019-07-03 08:18:34 <danieli> not sure what alpine's policies are on that though
2019-07-03 08:19:17 <tmhoang1> 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 <tmhoang1> I think it's openjdk thinggy
2019-07-03 08:23:47 <tmhoang1> correct ?
2019-07-03 08:24:22 <danieli> dunno off the top of my head, i for the most part avoid java
2019-07-03 08:58:03 <errn0[m]> tmhoang1: Will prebuilt binaries even work on musl?
2019-07-03 08:58:53 <tmhoang1> for adoptopenjdk ? I don't think so
2019-07-03 09:07:59 <tmhoang1> 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 <ncopa> tcely: 34c5eaf34c440e4a13c158a3cf98a3163e34e170 is wrong
2019-07-03 10:08:00 <ncopa> `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 <ncopa> argh!
2019-07-03 10:10:36 <ncopa> we shipped it to 3.10 release
2019-07-03 10:17:40 <fcolista> ncopa, you around? An issue with libvirt CVE of 3.9
2019-07-03 10:17:55 <fcolista> 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 <fcolista> cause build to fail: https://dpaste.de/A9C5
2019-07-03 10:18:53 <fcolista> Looking at the source code, I've found this:
2019-07-03 10:19:16 <fcolista> src/access/viraccessapicheck.c:int virDomainSaveImageGetXMLDescEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags)
2019-07-03 10:19:16 <fcolista> src/access/viraccessapicheck.h:extern int virDomainSaveImageGetXMLDescEnsureACL(virConnectPtr conn, virDomainDefPtr domain, unsigned int flags);
2019-07-03 10:20:04 <fcolista> 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 <fcolista> does it make sense?
2019-07-03 10:21:13 <fcolista> patch removes the 'flags' argument, but actually the function is declared with that arg
2019-07-03 10:22:38 <ncopa> hi
2019-07-03 10:23:37 <ncopa> that needs more investigation
2019-07-03 10:23:57 <ncopa> that patch alone cannot be the fix
2019-07-03 10:24:23 <ncopa> 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 <fcolista> right
2019-07-03 10:24:38 <fcolista> but this is a backport for 3.9
2019-07-03 10:25:15 <fcolista> looks that CVE-2019-10161 patch does not apply out-of-the-box to libvirt 4.10.0
2019-07-03 10:25:28 <fcolista> and 4.10.1 has never been shipped
2019-07-03 10:26:03 <ncopa> hum
2019-07-03 10:26:16 <fcolista> wondering if http://tpaste.us/P0xQ would be sufficient...
2019-07-03 10:26:41 <ncopa> no
2019-07-03 10:26:57 <ncopa> you need to ajust all callers of that function also
2019-07-03 10:27:29 <ncopa> so that patch is not enough alone
2019-07-03 10:28:07 <fcolista>  http://tpaste.us/P0xQ  <- this removes the flags from the callers
2019-07-03 10:28:17 <fcolista> unsigned int flags
2019-07-03 10:30:24 <ncopa> no, its the declaration of the function itself
2019-07-03 10:30:57 <ncopa> this is the full patch: https://libvirt.org/git/?p=libvirt.git;a=patch;h=aed6a032cead4386472afb24b16196579e239580
2019-07-03 10:31:18 <fcolista> yes, but does not apply
2019-07-03 10:31:45 <fcolista> there's no entry for  VIR_DOMAIN_SAVE_IMAGE_XML_SECURE in src/remote/remote_protocol.x
2019-07-03 10:33:00 <fcolista> 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 <fcolista> http://tpaste.us/65on
2019-07-03 10:33:46 <ncopa> right, that looks better
2019-07-03 10:33:50 <ncopa> the last hunk is the caller
2019-07-03 10:34:27 <fcolista> but src/remote/remote_protocol.x does not have VIR_DOMAIN_SAVE_IMAGE_XML_SECURE
2019-07-03 10:34:40 <fcolista> infact, the patch fails when apply that part
2019-07-03 10:34:45 <ncopa> i think that is some rpc definition
2019-07-03 10:34:50 <ncopa> im not sure how that works
2019-07-03 10:34:54 <ncopa> it looks like a comment
2019-07-03 10:35:05 <fcolista> right, that is what I thought too
2019-07-03 10:35:08 <ncopa> but i dont know if the parser uses that to generate the header
2019-07-03 10:47:53 <fcolista> seems that the patch applies from libvirt 5.0.0
2019-07-03 10:47:57 <fcolista> not backward
2019-07-03 11:01:06 <ncopa> see i fyou can find patches from debian or some other distro
2019-07-03 11:31:13 <fcolista> 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 <fcolista> applied this to libvirt 5.0.0
2019-07-03 18:55:18 <Cogitri> mps: had time to look at rust on armhf yet?
2019-07-03 18:55:39 <mps> Cogitri: you mean armv7
2019-07-03 18:56:44 <Cogitri> I mean armhf
2019-07-03 18:57:28 <mps> huh, my armhf is small box 4GB ram and FS is on microSD
2019-07-03 18:57:59 <mps> I can try, ofc, but don't expect much from it
2019-07-03 18:58:43 <Cogitri> Oh, I thought you had said that you were able to build Rust on it
2019-07-03 18:59:49 <mps> only on armv7 and aarch64, never told armhf, iirc. If I told that then it was mistake
2019-07-03 19:00:27 <Cogitri> Oh, alright, I guess I got that wrong then
2019-07-03 19:00:31 <Cogitri> I'll ask in #alpine-infra then, thanks nontheless :)
2019-07-03 19:00:47 <mps> I have armhf as lxc container on armv7
2019-07-03 19:01:21 <mps> I mean, armv7 physical box with 4GB and SD card
2019-07-03 19:01:37 <Cogitri> Oh, alright
2019-07-03 19:01:54 <mps> I have armv7 lxc container with a lot more RAM and CPU's
2019-07-03 22:45:41 <Cogitri> 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 <mps> Cogitri: good morning. sure, give me PR number
2019-07-04 07:28:27 <Cogitri> pr9134
2019-07-04 07:29:57 <Cogitri> Morning mps :)
2019-07-04 07:31:53 <mps> building, will report results, now going to drink something to wake me up
2019-07-04 07:32:50 <mps> you should update checksum ;)
2019-07-04 07:34:17 <Cogitri> Pretty sure I already did :o
2019-07-04 07:34:19 <mps> it was so fast, 'error: Could not compile `getopts`.'
2019-07-04 07:34:44 <Cogitri> So it SIGBUSes for you too? :c
2019-07-04 07:37:05 <Cogitri> 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 <mps> don't see reason, but audit shows something about "/usr/lib/crti.o"
2019-07-04 07:40:36 <mps> maybe I need to uninstall 'my' rust first, forgot that
2019-07-04 07:41:37 <mps> would be more sapient to work on this after coffee ;)
2019-07-04 07:50:17 <errn0[m]> Helloo..
2019-07-04 07:50:17 <errn0[m]> Why clang depends on gcc: http://0x0.st/z2k6.txt
2019-07-04 07:56:08 <jwh> runtime
2019-07-04 08:04:27 <errn0[m]> umm?
2019-07-04 08:32:37 <Cogitri> My uneducated guess would be because we don't build it against compiler-rt
2019-07-04 08:32:57 <jwh> yes
2019-07-04 08:33:11 <jwh> here be dragons etc
2019-07-04 08:33:32 <jwh> you should be able to link it against compiler-rt if its installed though
2019-07-04 09:28:11 <errn0[m]> It turns out that compiler-crt is almost an empty package
2019-07-04 09:51:14 <ncopa> Cogitri: i think im making progress with webkit2gtk
2019-07-04 09:51:54 <Cogitri> Nice 👍
2019-07-04 09:51:57 <ncopa> 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 <ncopa> and fails faster
2019-07-04 09:52:27 <ncopa> 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 <ncopa> seems like our patch fix_armv6 is broken
2019-07-04 09:53:14 <Cogitri> Oh, I had thought no `-g` option implied no debugging at all
2019-07-04 09:53:59 <ncopa> i think -DCMAKE_BUILD_TYPE=Release adds/overrids our CXXFLAGS
2019-07-04 09:54:41 <ncopa> i now have separate successful builds of armv7 and armv6
2019-07-04 09:54:43 <Cogitri> Ah, CMake magic, right
2019-07-04 09:54:48 <ncopa> still no success on x86 though
2019-07-04 09:55:04 <Cogitri> <ncopa "i now have separate successful b"> Great!
2019-07-04 09:55:21 <ncopa> so i think i can push fixes for arm 32bit today
2019-07-04 09:55:22 <Cogitri> 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 <ncopa> no idea
2019-07-04 09:56:01 <ncopa> maybe i can play with ulimits or something
2019-07-04 09:56:17 <ncopa> but i think i'll push update + enable arm 32bit first
2019-07-04 09:56:42 <Cogitri> Okie 👍
2019-07-04 09:56:48 <Cogitri> Thanks for looking into it
2019-07-04 09:56:58 <ncopa> this success is the motivation i needed :)
2019-07-04 09:57:08 <ncopa> im switching to ninja while at it
2019-07-04 09:57:37 <maxice8> How faster is ninja compared to make ? :o
2019-07-04 09:57:50 <ncopa> i havent tested
2019-07-04 09:58:12 <ncopa> i dont think the diff is that big
2019-07-04 10:02:56 <Cogitri> If Ninja works for you that's nice
2019-07-04 10:03:06 <Cogitri> It failed for me even on x86_64, but maybe I did something wrong
2019-07-04 10:03:38 <ncopa> i can switch back to make if you prefer that
2019-07-04 10:03:45 <Cogitri> maxice8: On Exherbo webkit2gtk went from ~22mins to ~20mins on my testbench with ninja
2019-07-04 10:04:14 <ncopa> thats the numbers i'd expect
2019-07-04 10:04:43 <Cogitri> Oh, I prefer Ninja if it works :)
2019-07-04 11:03:33 <ncopa> now webkit only need fix for x86
2019-07-04 11:04:16 <ncopa> hum
2019-07-04 11:04:23 <ncopa> this warning looks scary
2019-07-04 11:04:26 <ncopa> ../Source/ThirdParty/xdgmime/src/xdgmimemagic.c:489:5: warning: "LITTLE_ENDIAN" is not defined, evaluates to 0 [-Wundef]
2019-07-04 11:04:26 <ncopa>  #if LITTLE_ENDIAN
2019-07-04 11:04:26 <ncopa>      ^~~~~~~~~~~~~
2019-07-04 11:50:50 <andypost[m]> ncopa: pr9267 could be backported but not sure about argon2 package yet
2019-07-04 13:01:57 <Cogitri> mps: Mind trying Rust again on aarch64 with http://sprunge.us/8EPWyH applied?
2019-07-04 14:17:53 <mps> Cogitri: PR 9134?
2019-07-04 14:18:10 <mps> sorry, I was AFK
2019-07-04 14:19:26 <Cogitri> No worries
2019-07-04 14:19:34 <Cogitri> Yes please
2019-07-04 14:21:14 <Cogitri> Just pushed to pr9134 again, so you don't have to apply the patch yourself
2019-07-04 14:24:17 <mps> again same error: 'error: Could not compile `getopts`.'
2019-07-04 14:25:00 <mps> no luck
2019-07-04 14:27:56 <Cogitri> Huh, with the new tarball?
2019-07-04 14:30:51 <mps> I just downloaded and applied patch and run 'abuild -r'
2019-07-04 14:30:58 <mps> ah, I see
2019-07-04 14:31:32 <mps> I need first remove tarballs from cache?
2019-07-04 14:31:57 <Cogitri> Yup
2019-07-04 14:31:59 <mps> I build in lxc where cached files are preserved
2019-07-04 14:32:19 <mps> ok, will clean cache and try again
2019-07-04 14:32:19 <Cogitri> Make sure you have the latest version of that pr
2019-07-04 14:32:21 <Cogitri> I changed the aarch64 tarball to a different one
2019-07-04 14:33:22 <mps> I do: wget https://github.com/alpinelinux/aports/pull/9134.patch
2019-07-04 14:33:24 <Cogitri> Thank you
2019-07-04 14:33:38 <mps> git am ../9134.patch
2019-07-04 14:34:19 <mps> cd community/rust and 'abuild -r > & ! ~/rust-build.log'
2019-07-04 14:35:05 <Cogitri> That should work, although doing curl -L <url> | git am seems easier
2019-07-04 14:35:14 <Cogitri> What's your HEAD?
2019-07-04 14:37:03 <Cogitri> Alright, it failed with the same error on CI
2019-07-04 14:37:03 <Cogitri> Thanks for trying though
2019-07-04 14:37:13 <Cogitri> Although I'm confused why it works on my machine now
2019-07-04 14:37:56 <mps> yes, failed again
2019-07-04 14:39:00 <mps> 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 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/ILHTJLQOVlAIoXMZdbYsYJFO >

2019-07-04 14:41:47 <PureTryOut[m]> ^ uh, what?
2019-07-04 14:42:45 <mps> PureTryOut[m]: really what, :)
2019-07-04 14:43:16 <Cogitri> mps: Ah, meant the HEAD of my branch :)
2019-07-04 14:50:07 <PureTryOut[m]> Is there anyway to install this updated package? 🤔
2019-07-04 14:50:23 <PureTryOut[m]> 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 <PureTryOut[m]> Oh it worked now
2019-07-04 14:53:27 <PureTryOut[m]> Maybe I forgot to update APKINDEX? Idk
2019-07-04 15:31:33 <ncopa> andypost[m]: sorry i didnt reach to look at that argon2 thing. can you please ping me tomorrow?
2019-07-04 15:32:26 <andypost[m]> Sure
2019-07-04 16:32:20 <artok> what is the target triple for x86 32bit ? i586-linux-musl?
2019-07-04 19:25:11 <Cogitri> artok: i686-alpine-linux-musl IIRC
2019-07-04 19:27:27 <mps> i586-alpine-linux-musl
2019-07-04 19:27:37 <mps> ?
2019-07-04 19:30:00 <Cogitri> Oh, right, i586
2019-07-04 19:33:11 <mps> 
ACTION wonders why it is called triplet

2019-07-04 19:38:24 <Cogitri> mps: Because the historically consisted of three strings: arch-os-vendor
2019-07-04 19:38:57 <Cogitri> So e.g. aarch64-linux-gnu
2019-07-04 19:40:13 <mps> I know, just wondering why we still call it triplet and not quartet
2019-07-04 19:41:11 <Cogitri> Well, Debian just calls them tuples, which seems more correct, but oh well
2019-07-04 19:41:28 <Cogitri> As long as everyone knows what's meant with triplets it's fine by me
2019-07-04 19:45:35 <mps> OT little, personally I prefer words/terms with clear semantic
2019-07-04 19:50:18 <artok> yah
2019-07-04 19:51:32 <artok> so there is error on clang
2019-07-04 19:52:21 <artok> patch adds i686-alpine-linux-musl as triplet on X86
2019-07-04 19:52:39 <artok> and that is triplet because arch-os-abi
2019-07-04 19:53:14 <artok> that fourth is vendor before os and not necessarily needed but still used =)
2019-07-04 19:57:34 <Cogitri> Right, should be i586-alpine-linux-musl, I guess
2019-07-04 23:09:27 <rmsvc> 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 <rmsvc> https://github.com/gweis/isodate
2019-07-04 23:13:05 <rmsvc> 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 <danieli> rmsvc: I'd say open an issue with the upstream maintainer/developers and have them fix it
2019-07-04 23:16:41 <danieli> that just seems plain broken
2019-07-04 23:27:17 <rmsvc> 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 <danieli> hm, unless it's critical, I'd personally be against packaging and including unmaintained software in alpine repos
2019-07-04 23:30:06 <rmsvc> yeah, this is probably for the better
2019-07-04 23:30:46 <danieli> do you want to package it because it's a dependency of another package?
2019-07-04 23:32:27 <rmsvc> yeah, I was working on packaging streamlink and it's the only dependency not in the alpine repos
2019-07-04 23:33:13 <Cogitri> Hm, if it works and doesn't cause problems I don't see the problem with packaging it
2019-07-04 23:33:19 <jwh> ohhh, streamlink package
2019-07-04 23:33:21 <jwh> yeahhhh
2019-07-04 23:34:18 <danieli> right, i was working on streamlink too
2019-07-04 23:34:25 <danieli> i didn't get super far though, i got busy with other stuff
2019-07-04 23:34:54 <jwh> 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 <jwh> better if someone else does it though :D
2019-07-04 23:35:27 <danieli> 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 <jwh> lol
2019-07-05 06:04:15 <errn0[m]> <algitbot "Issue (new): [Alpine Linux]: Dro"> How come it is an issue?
2019-07-05 06:46:02 <mps> errn0[m]: maybe we need something better for bug reporting. like Debian's reportbug ?
2019-07-05 07:23:52 <errn0[m]> mps: Do we? I don't feel a need of it :)
2019-07-05 07:23:53 <errn0[m]> I would love to know your opinion too
2019-07-05 07:29:02 <mps> something which pressure bug reporter to give more info and better descpription would be good, imo
2019-07-05 07:33:17 <errn0[m]> mps: That bug report was kinda meh.. yeah.. but ...
2019-07-05 07:34:32 <errn0[m]> 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 <errn0[m]> s/a/an
2019-07-05 07:34:40 <alpine-meetbot> 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 <errn0[m]> ay
2019-07-05 07:39:03 <mps> 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 <errn0[m]> mps: Not sure what to say... just tag it [Need additional info]
2019-07-05 11:11:33 <mps> Cogitri: congrats :) so we only missing rust on aarch64
2019-07-05 11:11:55 <Cogitri> Thanks :)
2019-07-05 11:12:04 <Cogitri> Am working on that together with Rust 1.36
2019-07-05 11:13:09 <mps> good work. now I can delete it from my 'back' brain. *Thank you*
2019-07-05 14:10:12 <maxice8> 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 <maxice8> Is there a place to drop suggestions for what to put in the next release ?
2019-07-05 14:23:38 <maxice8> next release notes*
2019-07-05 15:34:21 <mps> maxice8: maybe alpine-devel ML
2019-07-05 15:34:32 <mps> or new wiki page
2019-07-05 15:34:50 <maxice8> Wiki page should be better
2019-07-05 15:35:11 <mps> maybe discuss these even here, or just some.
2019-07-05 15:36:17 <mps> wiki page is good for list things but not useful for discussions
2019-07-05 15:37:52 <mps> although, I posted to ML few months ago some ideas about vim and didn't got any comment
2019-07-05 15:38:11 <mps> maybe this channel is best place, after all
2019-07-05 15:39:55 <Cogitri> 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 <Cogitri> It's easy to forget about them if we just discuss it here
2019-07-05 15:42:29 <mps> agree, combined 'things' till we create something better
2019-07-05 15:45:01 <ncopa> Cogitri: i think i have found a way to make webkit2gtk to build on 32bit x86
2019-07-05 15:45:25 <ncopa> disable _FORTIFY_SOURCE
2019-07-05 15:47:03 <Cogitri> Huh, that needs that much RAM? :o
2019-07-05 15:47:16 <ncopa> 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 <Cogitri> Anyway, nice
2019-07-05 15:48:09 <Cogitri> It'd be best if we could do the former
2019-07-05 15:48:19 <ncopa> i think i just add -U_FORTIFY_SOURCE on x86
2019-07-05 15:48:21 <ncopa> its simpler
2019-07-05 15:48:34 <ncopa> i think its related to the way our fortify source is implemented
2019-07-05 15:49:37 <ncopa> 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 <Cogitri> Oh, alright
2019-07-05 16:06:07 <ncopa> do we have rust on arm finally?
2019-07-05 16:07:00 <ncopa> we do!
2019-07-05 16:07:10 <ncopa> armv7 and armhf! nice work!
2019-07-05 16:09:01 <ncopa> Cogitri: i think the commit message in 69851bdae1177246337f51a35734e93f1fd7e3d3 should be a comment in APKBUILD
2019-07-05 16:09:23 <ncopa> Cogitri: thanks alot for the work there! its awesome!
2019-07-05 16:10:19 <Cogitri> 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 <ncopa> i think the comment is relevant for bootstraping new arch?
2019-07-05 16:11:58 <ncopa> for aarch64 and s390x
2019-07-05 16:12:31 <ncopa> in any case, I'm super happy that we finally have rust on more arches
2019-07-05 16:17:34 <Cogitri> Ah, true that. Glad to be of help with that :)
2019-07-05 16:40:29 <maxice8> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas)
2019-07-05 16:40:49 <Cogitri> Nice 👍
2019-07-05 16:41:10 <maxice8> :D need other people to contribute as well
2019-07-05 18:19:27 <PureTryOut[m]> 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 <PureTryOut[m]> I think it should just be disabled entirely, it's too unpredictable
2019-07-05 18:19:59 <maxice8> Yes
2019-07-05 18:20:56 <PureTryOut[m]> I don't have access to a PC till monday though, someone else will have to do it
2019-07-05 18:49:23 <maxice8> done
2019-07-05 18:53:06 <maxice8> pr7873 can be closed
2019-07-05 18:53:17 <maxice8> pr7881 can be closed
2019-07-05 20:08:00 <maxice8> pr4949 pr7873 pr7881 can be closed
2019-07-05 20:16:14 <mps> aren't they auto closed when the PR is pushed to aports
2019-07-05 20:17:47 <Cogitri> Not if it's a duplicate and another PR is pushed
2019-07-05 20:19:14 <mps> aha, thank for explanation
2019-07-05 22:00:36 <tmhoang1> 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 <tmhoang1> also there are some work in progress to port llvm-libunwind to s390x
2019-07-05 22:01:15 <tmhoang1> libunwind s390x code landed last year, should be available for 1.4 release
2019-07-05 22:01:27 <tmhoang1> not sure why 1.3.x do not contain it though
2019-07-05 22:01:33 <stateless> ncopa: aha
2019-07-05 22:01:50 <stateless> ncopa: any indication as to why it fails?
2019-07-05 22:02:36 <Cogitri> 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 <Cogitri> But it does have full support for s390x-gnu 🤔
2019-07-05 22:04:05 <tmhoang1> 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 <Cogitri> Well, for now it's mostly non-core stuff, so it's not a pressing matter (yet)
2019-07-05 22:04:47 <tmhoang1> as of for now, it seems only firefox-esr is notable
2019-07-05 22:04:54 <Cogitri> And librsvg maybe
2019-07-05 22:05:37 <tmhoang1> what's wrong with librsvg ?
2019-07-05 22:07:25 <Cogitri> It uses Rust too for >= 2.42
2019-07-05 22:07:27 <Cogitri> Or 2.44?
2019-07-05 22:09:54 <tmhoang1> right
2019-07-05 22:22:32 <mps> Cogitri: did you forgot to add armv7-alpine-linux-musleabihf to rust or you skip it for now
2019-07-05 22:23:25 <Cogitri> Yeah, seems like something went wrong on armv7 and armhf
2019-07-05 22:23:33 <Cogitri> Will look into it once I have aarch64 running
2019-07-05 22:24:56 <mps> 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 <Cogitri> Oh, yes, seems like that's not in the alpine-target.patch
2019-07-05 22:26:04 <mps> ls -l => 40423892 Jul  5 12:29 rust-1.35.0-r0.apk
2019-07-05 22:26:09 <Cogitri> My bad, somehow I just assumed that it covered all arches!
2019-07-05 22:26:14 <Cogitri> I'll add armv7 and ppc64le
2019-07-05 22:27:13 <mps> do you have patches for these targets
2019-07-05 22:27:40 <Cogitri> Not yet, but will make them
2019-07-05 22:27:59 <Cogitri> 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 <mps> true, you can use arm-* or aarch64-* as 'template'
2019-07-05 22:29:14 <Cogitri> I can just use the upstream triplets as template :)
2019-07-05 22:29:15 <mps> I'm not sure if patches I have could be applied
2019-07-05 22:29:42 <mps> actually I suspect
2019-07-05 22:30:35 <mps> yes, upstream triplets (quartets, hehe) could be used
2019-07-05 22:33:34 <Cogitri> Could you test something for me on aarch64?
2019-07-05 22:34:01 <Cogitri> 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 <Cogitri> ikke: ^
2019-07-05 22:37:47 <Cogitri> 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 <mps> yes, fails to build getopt, iirc
2019-07-05 22:41:48 <Cogitri> Yup :/
2019-07-05 22:43:45 <mps> strange is that it works on armv7
2019-07-05 22:44:55 <Cogitri> aarch64 was problematic on Void too
2019-07-05 22:47:20 <mps> 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 <Cogitri> Yup, I'm trying with internal llvm right now too
2019-07-05 22:48:00 <Cogitri> What's our ppc64le triplet?
2019-07-05 22:48:04 <mps> didn't worked much on it expecting that you find issue and fix it
2019-07-05 22:48:22 <mps> let me look
2019-07-05 22:48:34 <Cogitri> Thanks
2019-07-05 22:50:18 <mps> should be: powerpc64-alpine-linux-musl
2019-07-05 22:50:28 <mps> but not sure
2019-07-05 22:53:03 <mps> or powerpc64le-alpine-linux-musl
2019-07-05 22:55:12 <mps> uhm, even ppc64le-alpine-linux-musl
2019-07-05 22:56:08 <mps> never gave enough attention to powerpc
2019-07-05 22:58:55 <mps> someone who know powerpc better should tell
2019-07-05 23:05:12 <Cogitri> https://github.com/alpinelinux/abuild/blob/master/functions.sh.in#L18
2019-07-05 23:05:16 <Cogitri> <mps "or powerpc64le-alpine-linux-musl"> I guess it's this
2019-07-05 23:07:59 <mps> looks like it is
2019-07-05 23:51:10 <artok> https://github.com/djazo/alpine-cross-sysroot did that kind of fun thingie
2019-07-05 23:55:40 <artok> now waiting for llvm toolchain to complete.. has been building for 5hrs or something like that =D
2019-07-05 23:56:27 <artok> PGO enabled
2019-07-06 05:45:45 <maxice8> https://patchwork.alpinelinux.org/patch/4951/ can be changed to accepted
2019-07-06 06:36:26 <maxice8> pr4949 pr7873 pr7881 pr7843 pr7839 can be closed
2019-07-06 07:08:13 <maxice8> pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 can be closed
2019-07-06 17:43:04 <artok> has anyone already rpi4 and tested alpine on that?
2019-07-06 18:03:31 <danieli> artok: to my knowledge: no
2019-07-06 18:03:44 <danieli> the rpi 4 is brand new, so it's not a big surprise
2019-07-06 18:04:03 <danieli> i'm considering ordering one or two, perhaps buy some new ones when/if the 8GB variant arrives
2019-07-06 18:11:56 <Cogitri> 8GB RAM ones? :o
2019-07-06 18:12:00 <Cogitri> I might order one once that USB-C powersink defect is fixed
2019-07-06 18:21:59 <danieli> yeah, the regulatory paper shipped with the RPi 4 1/2/4GB also lists "8GB" as a variant
2019-07-06 18:22:00 <danieli> and +1
2019-07-06 18:59:52 <artok> I'm just wondering if to add my credit card details to the order =)
2019-07-06 19:00:28 <artok> but indeed, no hurry at the moment
2019-07-06 19:00:50 <artok> first might go trying to use kernel version 5 on rpi3b
2019-07-06 19:36:03 <tmhoang1> anyone know why installing qemu-system-$arch pulling in mesa and bros ?
2019-07-06 19:37:02 <Cogitri> mesa for virgl most likely
2019-07-06 19:38:32 <tmhoang1> hmm interesting
2019-07-06 19:39:48 <tmhoang1> let me hit abuild with that disabled and see
2019-07-06 20:25:26 <rmsvc> So I finally got a working streamlink package after creating 9 other apkbuilds for its dependencies
2019-07-06 20:25:37 <rmsvc> 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 <rmsvc> If so, it's the last 10 commits here: https://git.sr.ht/~sacks/aports/log
2019-07-06 20:28:39 <Cogitri> Uhh...how can I review these?
2019-07-06 20:29:59 <rmsvc> To view them you can click on the commit hash... if that's what you mean
2019-07-06 20:30:50 <Cogitri> 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 <rmsvc> Like create a pull request on Github?
2019-07-06 20:33:44 <Cogitri> That'd be the best way to get a review on your stuff, yes
2019-07-06 20:34:14 <Cogitri> I mean we do offer Patchwork, bust most coredevs apparently dislike using it (and so do I)
2019-07-06 20:35:01 <rmsvc> Ok, I'll work on creating a pull request
2019-07-06 20:35:08 <rmsvc> Thanks
2019-07-06 20:40:02 <Cogitri> Feel free to `@Cogitri` me in the PR to make sure I don't forget about it :)
2019-07-06 20:41:16 <mps> Cogitri: are you sure about patchwork ;)
2019-07-06 20:43:03 <Cogitri> mps: Weren't you the one who told me that PW isn't popular with core devs? :P
2019-07-06 20:44:43 <mps> 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 <mps> s/codedevs/coredevs/
2019-07-06 20:45:01 <alpine-meetbot> 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 <PureTryOut[m]> rmsvc: oh sourcehut, I like it
2019-07-06 20:53:58 <Cogitri> mps: Ah, my bad, was using `dislike it` in the sense that they don't really use it
2019-07-06 20:56:27 <rmsvc> Cogitri: so is it fine I'm creating a pull request with 10 commits in it?
2019-07-06 20:56:41 <rmsvc> each commit is a new aport
2019-07-06 20:56:55 <Cogitri> Sure
2019-07-06 20:57:33 <Cogitri> Since those are dependencies for streamlink it's fine to crowd them into one PR
2019-07-06 20:57:50 <rmsvc> Ok, I created it and tagged you in the comment
2019-07-06 20:58:05 <Cogitri> Thanks
2019-07-06 20:58:14 <rmsvc> And thanks for the help. I really appreciate it
2019-07-06 20:58:18 <mps> out of curiosity, what is streamlink
2019-07-06 20:59:02 <rmsvc> It's like youtube-dl but specifically for live streams
2019-07-06 20:59:55 <mps> aha, thanks for info
2019-07-06 21:15:03 <Cogitri> rmsvc: Left some comments
2019-07-06 21:15:12 <Cogitri> But now it's time to sleep, gn
2019-07-06 21:29:04 <rmsvc> Cogitri: thanks, I'll be working on these later tonight
2019-07-06 22:18:23 <maxice8> pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 pw4941 pw4940 can be closed
2019-07-07 04:52:34 <M0x32_t[m]> 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 <M0x32_t[m]> [[sroracle]]: That worked
2019-07-07 05:21:28 <M0x32_t[m]> > Issue (new): [Alpine Linux]: Package request: solc: https://bugs.alpinelinux.org/issues/10660
2019-07-07 05:21:29 <M0x32_t[m]> 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 <M0x32_t[m]> 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 <mps> M0x32_t[m]: you can send with 'git send-email  --to alpine-aports@lists.alpinelinux.org'
2019-07-07 05:23:28 <mps> patch will appear at patchwork.a.o
2019-07-07 05:25:04 <M0x32_t[m]> [[sroracle]]: I see. I have no problems with github
2019-07-07 05:25:41 <M0x32_t[m]> 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 <M0x32_t[m]> Build fails: https://cloud.drone.io/alpinelinux/aports/8287/
2019-07-07 06:43:13 <M0x32_t[m]> 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 <M0x32_t[m]> Unable to determine commit hash. Either compile from within git repository
2019-07-07 06:43:15 <M0x32_t[m]> or supply a file called commit_hash.txt"
2019-07-07 06:43:36 <M0x32_t[m]> I have added a dummy commit_hash.txt, still build fails
2019-07-07 06:46:48 <mps> 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 <mps> and I'm not expert in cmake
2019-07-07 06:50:25 <M0x32_t[m]> Me neither, cmake is blackbox for me :(
2019-07-07 06:54:46 <mps> this channel could be quite calm on weekends and in early morning (europe) especially now in vacation time
2019-07-07 06:55:46 <mps> repeat you question later and maybe even tomorrow if you don't find solution in meantime
2019-07-07 06:56:04 <M0x32_t[m]> Sure.. no probs
2019-07-07 07:44:10 <M0x32_t[m]> Yay.. build passed:
2019-07-07 07:44:11 <M0x32_t[m]> https://cloud.drone.io/alpinelinux/aports/8291
2019-07-07 07:44:25 <M0x32_t[m]> THANKS ALOT
2019-07-07 07:48:49 <mps> nice :0
2019-07-07 07:50:17 <mps> what is github PR url/number
2019-07-07 07:50:45 <M0x32_t[m]> mps: https://github.com/alpinelinux/aports/pull/9343
2019-07-07 07:52:19 <mps> oh, programming lang, first time hear for it
2019-07-07 07:52:38 <M0x32_t[m]> mps: Ye..
2019-07-07 07:53:13 <mps> and it doesn't depend on llvm, very nice
2019-07-07 07:54:03 <mps> I can push it to aports if someone else didn't started process already
2019-07-07 07:54:16 <M0x32_t[m]> Lightweight yeah...
2019-07-07 07:55:32 <Cogitri> There are still some unaddressed review comments as far as I can see
2019-07-07 07:56:17 <M0x32_t[m]> cogitri: Such as?
2019-07-07 07:59:35 <mps> commit messages repeating 'Update APKBUILD' too much
2019-07-07 08:00:09 <M0x32_t[m]> mps: I see... will add commit messages
2019-07-07 08:00:20 <M0x32_t[m]> And will fixed those typos
2019-07-07 08:00:41 <mps> and you should prepend commit messages with 'testing/solidity:'
2019-07-07 08:01:16 <Cogitri> Well, those should be squashed into one commit anyway, I guess
2019-07-07 08:01:33 <mps> maybe even squash all commits to just one, a lot easier for commiters to review PR and apply
2019-07-07 08:01:47 <mps> Cogitri: you are faster ;)
2019-07-07 08:02:06 <Cogitri> Hehe
2019-07-07 08:04:26 <M0x32_t[m]> cogitri:
2019-07-07 08:04:27 <M0x32_t[m]> "Please be more precise, what's actually going wrong?"
2019-07-07 08:04:27 <M0x32_t[m]> I just disabled the test for my machine.. is it allowed?
2019-07-07 08:04:57 <Cogitri> We try to run tests whenever we can
2019-07-07 08:05:12 <Cogitri> So don't just disable tests for no specific reason
2019-07-07 08:05:26 <M0x32_t[m]> I see. o you know how to perform tests in cmake?
2019-07-07 08:05:37 <M0x32_t[m]> do you..*
2019-07-07 08:05:47 <M0x32_t[m]> Or I just should make check it?
2019-07-07 08:05:53 <mps> 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 <Cogitri> Either call ctest directly to make test
2019-07-07 08:14:40 <M0x32_t[m]> Failed again: https://cloud.drone.io/alpinelinux/aports/8293/
2019-07-07 08:15:27 <M0x32_t[m]> I will wok on this tomorrow
2019-07-07 08:15:46 <M0x32_t[m]> work*
2019-07-07 08:17:04 <mps> eh, making language to work takes time. sometimes even months
2019-07-07 08:18:19 <mps> according to repology.org api we have 842 pkg's with problematic url, mostly http instead of https
2019-07-07 08:18:29 <M0x32_t[m]> Oh?
2019-07-07 08:18:32 <M0x32_t[m]> Great
2019-07-07 08:21:29 <mps> 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 <M0x32_t[m]> Both seems to pint to same domain
2019-07-07 08:22:30 <M0x32_t[m]> What blocks em up?
2019-07-07 08:22:38 <M0x32_t[m]> point*
2019-07-07 08:23:23 <M0x32_t[m]> Ow no redirect
2019-07-07 08:24:52 <mps> search.cpan.org is retired, still works but simply redirects to metacpan.org
2019-07-07 08:27:01 <M0x32_t[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/EwxkzSvkoRYdUBrSDMeSbUEa >

2019-07-07 08:27:39 <M0x32_t[m]> If I disable the build check.. it builds.. if I enable tests, it fails...
2019-07-07 08:27:40 <M0x32_t[m]> Not knowing cmake making things hard for me for sure
2019-07-07 08:28:43 <mps> does upstream site have anything on making tests during build
2019-07-07 08:31:22 <M0x32_t[m]> mps: They already had a discussion on it.. https://github.com/ethereum/solidity/issues/3076#issuecomment-336503636
2019-07-07 08:31:22 <M0x32_t[m]> Looks like something to do with that commit_hash.txt file..
2019-07-07 08:31:23 <M0x32_t[m]> Either I have to add a dummy file or just pull from git head straight.
2019-07-07 08:31:59 <M0x32_t[m]> The error message is almost identical
2019-07-07 08:32:46 <M0x32_t[m]> [APKBUILD](https://github.com/b17wise/aports/blob/master/testing/solidity/APKBUILD)
2019-07-07 08:34:13 <mps> right. I think it is better to add commit hash text file than build 'in git' dir
2019-07-07 08:35:51 <M0x32_t[m]> Yeah.. but as now I am building from tarball, so I have no clue
2019-07-07 08:37:30 <mps> also you have function 'default_prepare()' in APKBUILD. it should go to prepare() function
2019-07-07 08:38:38 <M0x32_t[m]> mps: I did that, already
2019-07-07 08:40:06 <mps> ah, sorry, I need to reapply new patch
2019-07-07 08:40:51 <M0x32_t[m]> I am missing something...
2019-07-07 08:40:52 <M0x32_t[m]> What it might be?
2019-07-07 08:42:18 <mps> 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 <mps> let me try build it locally
2019-07-07 08:43:24 <M0x32_t[m]> mps: Ye.. please..
2019-07-07 08:43:24 <M0x32_t[m]> That's what I am doing.. I will fix commit messages, as long as it builds :)
2019-07-07 08:44:45 <mps> 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 <M0x32_t[m]> mps: I have no clue...that's where I am stuck
2019-07-07 08:45:49 <M0x32_t[m]> Looks like cmake is generating wrong args into that
2019-07-07 08:46:25 <mps> also I don't know, we have to wait for someone who understand cmake or search the internet
2019-07-07 08:46:44 <Cogitri> Looking into it
2019-07-07 08:47:15 <Cogitri> Ah, you can't have an empty commit_hash.txt
2019-07-07 08:47:29 <Cogitri> See like 33 of that script
2019-07-07 08:47:54 <Cogitri> It reads the contents of commit_hash.txt into the variable SOL_COMMIT_HASH
2019-07-07 08:48:21 <Cogitri> If that's empty then the call to STRIP fails in line 34
2019-07-07 08:48:37 <mps> so, in prepare() commit_hash.txt should be written
2019-07-07 08:49:06 <Cogitri> No
2019-07-07 08:49:32 <Cogitri> Use the proper release from upstream which comes which that files
2019-07-07 08:49:42 <Cogitri> s/which/with/
2019-07-07 08:49:42 <alpine-meetbot> Cogitri meant to say: Use the proper release from upstream with comes which that files
2019-07-07 08:49:58 <mps> yes, agree, I think this is it: https://github.com/ethereum/solidity/commit/5a6ea5b19793f61c7703d4abe587b2bf40decc31
2019-07-07 08:50:25 <mps> or shorten version, if allowed
2019-07-07 08:50:26 <Cogitri> s/files/file/
2019-07-07 08:50:26 <alpine-meetbot> Cogitri meant to say: Use the proper release from upstream with comes which that file
2019-07-07 08:50:30 <Cogitri> https://github.com/ethereum/solidity/releases/download/v0.5.10/solidity_0.5.10.tar.gz
2019-07-07 08:50:45 <M0x32_t[m]> cogitri: Even if I remove that file and use tarball, it fails
2019-07-07 08:51:31 <Cogitri> <M0x32_t[m] "cogitri: Even if I remove that f"> "remove that file"?
2019-07-07 08:52:31 <M0x32_t[m]> Now what I can do else? I am on latest tarball
2019-07-07 08:53:24 <mps> it is probably bug, there have empty commit_hash.txt file in tarball
2019-07-07 08:54:53 <mps> ' echo -n "5a6ea5b19793f61c7703d4abe587b2bf40decc31" > commit_hash.txt' looks like it works
2019-07-07 08:57:32 <mps> building, will take time probably. https://www.xkcd.com/303/
2019-07-07 08:57:33 <alpine-meetbot> 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 <M0x32_t[m]> mps: Now adding the commit hash builds the project
2019-07-07 08:58:21 <M0x32_t[m]> > building, will take time probably. https://www.xkcd.com/303/
2019-07-07 08:58:21 <alpine-meetbot> 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 <M0x32_t[m]> Ahahaha
2019-07-07 08:58:24 <mps> I'm trying locally
2019-07-07 08:58:35 <M0x32_t[m]> same here
2019-07-07 08:59:13 <mps> going to take something for breakfast, see you later when building finish
2019-07-07 09:00:37 <M0x32_t[m]> It is i3 here xD
2019-07-07 09:00:48 <M0x32_t[m]> Intel i3
2019-07-07 09:01:41 <mps> my is i7, but still not fast
2019-07-07 09:04:23 <mps> and I remember days when I build kernels on i486 with 33MHz (yes mega not giga) clock
2019-07-07 09:05:50 <M0x32_t[m]> These days kernel got bigger
2019-07-07 09:06:46 <mps> true, and this is my moan ;)
2019-07-07 09:13:56 <mps> build finished, but check says 'No tests were found!!!'
2019-07-07 09:14:45 <M0x32_t[m]> 94% here
2019-07-07 09:15:17 <M0x32_t[m]> Hmm.. tests might not exists.. that's why Arch Linux and Gentoo ebuilds ship it DTESTS=NO
2019-07-07 09:17:06 <mps> interesting, compiler without tests :/
2019-07-07 09:18:30 <mps> then you can remove check() and add 'options="!check" # package does not have tests'
2019-07-07 09:18:37 <M0x32_t[m]> Ahahah xD
2019-07-07 09:18:45 <mps> or something similar in comment
2019-07-07 09:18:49 <M0x32_t[m]> > then you can remove check() and add 'options="!check" # package does not have tests'
2019-07-07 09:18:50 <M0x32_t[m]> Ye.. I am going to do that
2019-07-07 09:19:54 <Cogitri> Pretty sure it has tests
2019-07-07 09:21:02 <Cogitri> Btw, 0x32_t: seems like you have lots of trailing spaces in the APKBUILD
2019-07-07 09:23:04 <mps> yes, trailing whitespace should be trimmed
2019-07-07 09:23:22 <M0x32_t[m]> I trimmed ithem in vim now
2019-07-07 09:24:09 <mps> M0x32_t[m]: you can run 'abuild sanitycheck' in dir
2019-07-07 09:24:20 <M0x32_t[m]> Nice feature
2019-07-07 09:24:52 <M0x32_t[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/TUkfUkDeSylWLnvrJiRNKfIU >

2019-07-07 09:25:05 <M0x32_t[m]> ">>> solidity: Checking sanity of /tmp/APKBUILD..."
2019-07-07 09:25:06 <M0x32_t[m]> Seems fine?
2019-07-07 09:25:09 <maxice8> 0x32_t: There is also apkbuild-lint from atools
2019-07-07 09:25:40 <M0x32_t[m]> I am leaving tests fo for now... no idea why it is ignoring tests
2019-07-07 09:25:41 <mps> yes, apkbuild-lint is better
2019-07-07 09:31:35 <Cogitri> <M0x32_t[m] "I am leaving tests fo for now..."> Try running "$builddir"/test/soltest in check() :)
2019-07-07 09:34:48 <M0x32_t[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/zCwkDmkgWsQFpKIWSoqfygTD >

2019-07-07 09:34:56 <M0x32_t[m]> No tests were found!!!
2019-07-07 09:36:17 <Cogitri> That's from the soltest binary?
2019-07-07 09:39:45 <M0x32_t[m]> No.. what is soltest?
2019-07-07 09:39:45 <M0x32_t[m]> Also take a look here... https://cloud.drone.io/alpinelinux/aports/8294/
2019-07-07 09:43:43 <Cogitri> <Cogitri "Try running "$builddir"/test/sol"> ^
2019-07-07 09:43:58 <Cogitri> solidity builds a binary called soltest and puts it in the directory I've mentioned
2019-07-07 09:44:36 <Cogitri> It runs soldity's tests, so call that binary in check()
2019-07-07 10:00:57 <M0x32_t[m]> I see..
2019-07-07 10:00:58 <M0x32_t[m]> Well, I am out now
2019-07-07 10:01:27 <Cogitri> Okie, no need to rush things :)
2019-07-07 13:07:36 <ncopa> maxice8: FYI, i have disabled rofi for now. 2fd96ce013b3eaafaa0f7a3088b98fe75d6ac273
2019-07-07 13:09:18 <danieli> I need rofi so I'll give it a spin when I have time
2019-07-07 13:11:18 <maxice8> ncopa: Ack
2019-07-07 19:15:11 <maxice8> How to deal with non-deterministic tarballs ? (google codestorage)
2019-07-07 19:43:59 <maxice8> solved :D
2019-07-07 19:45:23 <mps> maxice8: nice :)
2019-07-07 19:45:39 <mps> I know whom to ask if need this
2019-07-07 19:46:41 <clandmeter> 
ACTION hides

2019-07-07 19:46:46 <maxice8> i just used a github mirror :D
2019-07-07 19:47:39 <mps> ah, even this is good hint
2019-07-07 19:59:42 <p4Wv1qn095FW> worrysome news https://utcc.utoronto.ca/%7Ecks/space/blog/unix/XDeathwatchStarts
2019-07-07 20:04:50 <mps> p4Wv1qn095FW: more reasons to switch to text mode ;)
2019-07-07 20:05:07 <p4Wv1qn095FW> :)
2019-07-07 20:05:21 <p4Wv1qn095FW> my gopher client is already running in text mode \o/
2019-07-07 20:06:08 <b17wise> maxice8: Hey.. you merged by port (/testing/solidity/APKBUILD).. thank you a lot :)
2019-07-07 20:06:14 <mps> by coincidencd I looked today that links web browser need upgrade
2019-07-07 20:07:30 <mps> b17wise: M0x32_t[m] worked on it today. do you have connection with this person
2019-07-07 20:09:03 <b17wise> mps: Yeh.. we are both same person
2019-07-07 20:09:04 <b17wise> :)
2019-07-07 20:10:06 <mps> I thought so, but asked to be sure
2019-07-07 20:13:11 <Cogitri> Does someone happen to have a native x86 builder?
2019-07-07 20:13:50 <clandmeter> native?
2019-07-07 20:13:52 <Cogitri> 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 <b17wise> mps: Couldn't able to do that without your help either :)
2019-07-07 20:14:46 <Cogitri> clandmeter: As in on a x86 hostos + x86 kernel
2019-07-07 20:14:53 <mps> b17wise: np, happy to help
2019-07-07 20:15:06 <Cogitri> At least I'm not sure why it works on my machine otherwise
2019-07-07 20:15:14 <clandmeter> if you want a 32bit kernel you could use qemu
2019-07-07 20:16:47 <Cogitri> Yeah, but I'm not that enthusiastic about that seeing that my last attempt with aarch64 failed :c
2019-07-07 22:28:54 <maxice8> Lot of PRs for stuff in main/ :D
2019-07-07 22:35:03 <mps> I'm scared of 'enable pulseaudio support'
2019-07-07 22:38:24 <mepholic> mps: haha same
2019-07-07 22:38:27 <mepholic> also I made a thing
2019-07-07 22:38:28 <mepholic> https://code.foxkit.us/snippets/23
2019-07-07 22:39:26 <mps> mepholic: nice to see you :)
2019-07-07 22:39:38 <mepholic> i didn't realize that I hadn't been in devel for months
2019-07-07 22:41:28 <mps> Is adelie linux 'desktop oriented'
2019-07-07 22:41:37 <mepholic> yes
2019-07-07 22:42:09 <mps> uhhhmmm, where to escape ;-)
2019-07-07 22:42:33 <mepholic> well, not necessarily desktop oriented
2019-07-07 22:42:41 <mepholic> but it is moreso than alpine I guess
2019-07-07 22:44:02 <mps> what does red 'X' after PR on github means
2019-07-07 22:44:19 <maxice8> CI failed
2019-07-07 22:44:38 <maxice8> either drone-ci or travis-ci failed to compile the changed APKBUILDs
2019-07-07 22:45:20 <mps> hm, I see some of them that are 'superseded' and can be closed
2019-07-07 22:45:58 <mps> for example PR #8699
2019-07-07 22:46:34 <mps> it is already upgraded and moved to community
2019-07-07 22:46:39 <maxice8> i usually send a message with a list of PR and PW that can be closed
2019-07-07 22:46:53 <maxice8> pr4949 pr7873 pr7881 pr7843 pr7839 pw4942 pw4943 pw4941 pw4940 can be closed
2019-07-07 22:47:45 <mps> 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 <maxice8> hopefully someone with GH access can take a look at them
2019-07-07 22:48:45 <mps> 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 <maxice8> algitbot closes them ?
2019-07-07 22:49:18 <mps> probably
2019-07-07 22:49:46 <maxice8> algibot closes PRs automatically when the relevant commits are merged
2019-07-07 22:50:13 <mps> hehe, maybe I can play with algitbot :)
2019-07-07 22:50:16 <maxice8> 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 <maxice8> 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 <mps> I didn't dived much to this, waiting for gitlab
2019-07-07 22:56:45 <mps> maxice8: I can close PW's, sorry didn't noticed that you also post them
2019-07-07 22:57:07 <maxice8> no worries :D
2019-07-07 22:57:16 <maxice8> i'll just keep posting them
2019-07-07 22:58:10 <mps> I'll look at them tomorrow, now I'm not behind my working box
2019-07-08 06:37:25 <fcolista> what is the best way to pacakge a software with ruby deps not shipped with alpine?
2019-07-08 06:38:02 <fcolista> I was wondering about a post-install message saying "please run gem install $package"
2019-07-08 06:56:21 <ncopa> fcolista: short answer is: not package it all
2019-07-08 06:56:51 <ncopa> let users ask upstream
2019-07-08 06:57:23 <ncopa> that said, i think that is a good use case for docker
2019-07-08 06:58:50 <fcolista> that's a good point
2019-07-08 06:58:55 <fcolista> use it with docker
2019-07-08 06:59:44 <ncopa> 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 <ncopa> so i think we should just push users over to that
2019-07-08 07:02:50 <fcolista> agree
2019-07-08 07:19:10 <clandmeter> probably bundler
2019-07-08 07:19:44 <clandmeter> fcolista: ruby has alpine docker containers
2019-07-08 07:20:04 <clandmeter> thats how im doing gitlab now
2019-07-08 07:20:11 <clandmeter> cause we dont have 2.6
2019-07-08 07:20:24 <fcolista> I was looking to oxidised
2019-07-08 07:20:36 <fcolista> a rancid replacement
2019-07-08 07:20:53 <fcolista> (backup and restore config of tons of devices)
2019-07-08 07:21:08 <fcolista> they have docker, based on ubuntu
2019-07-08 07:21:33 <fcolista> I suppose that the only thing would be having that image updated using alpine rather than ubuntu
2019-07-08 07:31:36 <mps> fcolista: I use bundler for redmine to run it on Alpine
2019-07-08 07:32:11 <fcolista> I never used ruby and related things, so I don't know how these tools work
2019-07-08 07:33:02 <mps> also I used ruby first time when I build readmine
2019-07-08 07:33:37 <mps> looked at Arch linux and clandmeter helped also
2019-07-08 07:54:48 <mps> linux 5.2 stable released. let's will it be LTS (would be nice so we can upgrade)
2019-07-08 07:56:02 <mps> s/let's/let's see/
2019-07-08 07:56:02 <alpine-meetbot> 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 <Danct12> speaking of linux 5.2, i have a email from greg about my email address as a contributor.
2019-07-08 07:57:43 <mps> Danct12: nice to have kernel dev here :)
2019-07-08 07:58:28 <Danct12> 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 <Danct12> but people say if you touch the source code you're a dev
2019-07-08 07:59:26 <mps> I have some patches but don't have patience to pass all steps to post any of them
2019-07-08 08:54:11 <andypost[m]> ncopa: hi, reminder about argon2 & php backport
2019-07-08 09:34:34 <ncopa> andypost[m]: im slightly confused about exactly what i need to do wrt argon2 and php
2019-07-08 09:34:49 <ncopa> https://bugs.alpinelinux.org/issues/10649 is marked as resolved
2019-07-08 09:40:39 <andypost[m]> ncopa the question of php backport and upgrade of argon2
2019-07-08 09:41:26 <andypost[m]> ncopa it resolved in edge only
2019-07-08 09:42:37 <andypost[m]> ncopa upgrade is pr9279
2019-07-08 09:43:36 <ncopa> so 43d556c0cb086ef5d94e22fc362c779cd2268042 and 69cf5153388a8f006da7b816c7b2b9c31f6367e1 needs to be cherry-picked for 3.10-stable?
2019-07-08 09:43:57 <ncopa> i tried to build https://github.com/alpinelinux/aports/pull/9279 on 3.10-stable but it failed
2019-07-08 09:44:37 <ncopa> oh, pr9279 is not merged to edge even
2019-07-08 09:45:00 <ncopa> but build fails?
2019-07-08 09:45:05 <andypost[m]> Not sure about 7.3.7 - just started testing but cherry pick makes sense
2019-07-08 09:45:05 <ncopa> you still want to merge it?
2019-07-08 09:45:17 <ncopa> or you want me to fix the build?
2019-07-08 09:45:33 <andypost[m]> It hits timeout as always(
2019-07-08 09:45:41 <ncopa> so i just merge it?
2019-07-08 09:45:49 <andypost[m]> Yep
2019-07-08 09:45:58 <ncopa> have you tested that it builds?
2019-07-08 09:46:28 <ncopa> i merged it
2019-07-08 09:46:31 <ncopa> to master
2019-07-08 09:47:08 <ncopa> and cherry-picked the two commits for 3.10: 43d556c0cb086ef5d94e22fc362c779cd2268042 and 69cf5153388a8f006da7b816c7b2b9c31f6367e1
2019-07-08 09:47:52 <andypost[m]> Yes on x8664 and still not sure about how to minimise test suite to fit in 1h limit
2019-07-08 09:48:40 <ncopa> andypost[m]: if a commit has a "fixes #<issunumber>" 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 #<issuenum>"
2019-07-08 09:48:53 <ncopa> that way it will only be referenced in the issue, but not marked as resolved
2019-07-08 09:49:16 <ncopa> and in the cherry-picked commit i change commit message to "fixes #<issue>"
2019-07-08 09:49:35 <ncopa> 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 <ncopa> 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 <mps> this should be written in developer guides
2019-07-08 09:50:33 <ncopa> mps: yeah
2019-07-08 09:50:59 <mps> very clear and concise and now I understand it
2019-07-08 09:57:15 <andypost[m]> I can now reproduce argon2 build locally - diggin
2019-07-08 09:59:55 <andypost[m]> hm, how it possible that no such dir if abuild running split
2019-07-08 10:01:14 <Cogitri> That's the kind of bad error msg when the subpkg doesn't contain any files
2019-07-08 10:01:32 <Cogitri> So there's nothing being moved into the -lib subpackage
2019-07-08 10:13:20 <ncopa> i fixed it 7155035b6f2096543de30afe8ad25a4f017864b3
2019-07-08 10:33:07 <andypost[m]> 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 <maxice8> :D
2019-07-08 12:47:23 <tmhoang1> friendly ping : pr9044 pr9098
2019-07-08 12:51:54 <maxice8> tmhoang1: feel free to @maxice8 on github when making changes to packages maintained by Leo
2019-07-08 12:53:08 <tmhoang1> thanks
2019-07-08 13:11:21 <mps> maxice8: I noted four PW's which you told could be closed
2019-07-08 13:11:41 <mps> pw4942  pw4943 pw4941 pw4940
2019-07-08 13:11:59 <maxice8> yes ?
2019-07-08 13:12:44 <maxice8> yes
2019-07-08 13:13:03 <mps> are they accepted, so to mark them according to status
2019-07-08 13:14:32 <maxice8> 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 <mps> ok, will mark them as superseded then
2019-07-08 13:19:46 <mps> closed all four with 'Superseded' status flag
2019-07-08 13:22:04 <mps> eh, there were one my patch which I forgot to close :-|
2019-07-08 13:33:07 <tmhoang1> maxice8: fyi I'm checking retroarch error
2019-07-08 14:06:16 <tmhoang1> maxice8: pr9367
2019-07-08 14:33:13 <danieli> re #10663: was abuild changed to not include .a files in -dev packages at all?
2019-07-08 14:33:46 <Cogitri> No, it still does that if there's no -static subpkg IIRC
2019-07-08 14:33:54 <danieli> either libxkbcommon needs to make a libxkbcommon-static subpackage, or upstream changed it
2019-07-08 14:34:37 <danieli> 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 <maxice8> danieli: upstream uses meson now which doesn't generate static libraries afaik
2019-07-08 15:38:38 <danieli> maxice8: the apkbuild hasn't been touched since december though?
2019-07-08 15:40:29 <maxice8> no clue
2019-07-08 16:13:35 <PureTryOut[m]> 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 <maxice8> Works for me but I'll take a look later
2019-07-08 16:24:43 <PureTryOut[m]> 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 <PureTryOut[m]> Ah tests are disabled that's why
2019-07-08 18:47:45 <ddevault> FDI patch: bump
2019-07-08 20:15:07 <maxice8> mps up for closing patchwork patches ? :D
2019-07-08 20:16:33 <mps> maxice8: ok
2019-07-08 20:16:42 <mps> ready :)
2019-07-08 20:20:38 <maxice8> 4962 4963 4964
2019-07-08 20:22:04 <mps> what status to put them? Accepted?
2019-07-08 20:22:40 <maxice8> superseeded
2019-07-08 20:22:58 <mps> aha, 4962 4963 superseded, what is with 4964
2019-07-08 20:23:27 <maxice8> superseeded
2019-07-08 20:24:22 <mps> ok, all are superseded now
2019-07-08 20:25:00 <maxice8> py3-httpretty has wrong perms on its egg-info directory
2019-07-08 20:25:03 <maxice8> :D makes it unusable
2019-07-08 20:25:18 <mps> then rejected?
2019-07-08 20:25:49 <maxice8> can't be imported
2019-07-08 20:26:25 <mps> don't see py3-httpretty
2019-07-08 20:26:56 <maxice8> ddevault: py3-weasyprint is also missing py3-pillow
2019-07-08 20:27:03 <ddevault> ack
2019-07-08 20:27:11 <ddevault> I thought I fixed httpretty
2019-07-08 20:27:16 <ddevault> maybe I didn't send the patch
2019-07-08 20:27:24 <ddevault> anyway I'll look at these in about 5 mins
2019-07-08 20:27:55 <mps> what to do with it, 4966
2019-07-08 20:27:56 <maxice8> :D i pushed a "fix" already
2019-07-08 20:28:02 <maxice8> just made everything inside the egg-info directory into 644
2019-07-08 20:28:14 <mps> maxice8: so, accepted?
2019-07-08 20:28:26 <maxice8> will problably be superseeded
2019-07-08 20:28:55 <maxice8> no, it will be superseeded because ddevault will post another patch adding the proper deps
2019-07-08 20:29:31 <mps> then 'not applicable'
2019-07-08 20:29:39 <maxice8> 4790 4880 can be set to superseeded
2019-07-08 20:30:19 <maxice8> can be as well
2019-07-08 20:31:13 <maxice8> 4157 'not applicable'
2019-07-08 20:31:51 <maxice8> 3795 'not applicable'
2019-07-08 20:32:29 <mps> don't see 4157
2019-07-08 20:34:03 <mps> doesn't 3795 better fit for 'rejected'
2019-07-08 20:34:06 <ddevault> maxice8: mps: https://patchwork.alpinelinux.org/patch/4944/
2019-07-08 20:34:09 <ddevault> v3 should be good with permissions
2019-07-08 20:34:17 <ddevault> v1 & v2 were broken, though
2019-07-08 20:34:31 <maxice8> :D pick what you will
2019-07-08 20:34:33 <ddevault> I have a working package built and in use based on v3
2019-07-08 20:34:49 <ddevault> https://mirror.sr.ht/alpine/v3.10/sr.ht/x86_64/py3-httpretty-0.9.6-r0.apk
2019-07-08 20:34:57 <ddevault> looking at weasyprint now
2019-07-08 20:35:18 <maxice8> is missing provides="py-httpretty=$pkgver-r$pkgrel"
2019-07-08 20:35:23 <maxice8> replaces is OK, both are used
2019-07-08 20:35:41 <mps> ddevault: 4944 is accepted
2019-07-08 20:36:10 <ddevault> so it needs a new patch adding provides?
2019-07-08 20:36:34 <maxice8> yes
2019-07-08 20:36:39 <ddevault> ack
2019-07-08 20:36:47 <ddevault> updated weasyprint patch coming momentarily
2019-07-08 20:37:42 <ddevault> httpretty patch out as well
2019-07-08 20:39:04 <ddevault> I also updated the python2 deprecation procedure to mention provides
2019-07-08 20:39:14 <ddevault> here https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-07-08 20:39:15 <maxice8> weasyprint patch is not adding py3-html5lib
2019-07-08 20:41:03 <mps> maxice8: you pushed 4968? Can I mark it as 'accepted'?
2019-07-08 20:41:23 <ddevault> wait up
2019-07-08 20:41:31 <ddevault> afaict weasyprint does not depend on pillow
2019-07-08 20:41:36 <ddevault> it does depend on html5lib, though
2019-07-08 20:41:56 <mps> let's see will it pass builders, then
2019-07-08 20:42:05 <ddevault> well, let me send you a patch with html5lib
2019-07-08 20:42:20 <ddevault> I build my packages on a system without any python stuff installed
2019-07-08 20:42:25 <ddevault> so I'm surprised I'm not hitting this
2019-07-08 20:42:34 <maxice8> yes, it should actually be marked accepted automatically
2019-07-08 20:42:45 <mps> but looks like https://patchwork.alpinelinux.org/patch/4968/ already applied to aports
2019-07-08 20:43:04 <ddevault> new weasyprint patch up
2019-07-08 20:43:11 <mps> pw could be sometimes slow
2019-07-08 20:44:12 <maxice8> weasyprint GitHub release notes mention it needs CairoSVG over 2.4.0, ours is 2.3.0
2019-07-08 20:45:01 <ddevault> oh, I didn't pull that upgrade from my repo, sorry
2019-07-08 20:45:03 <ddevault> lemme grab it
2019-07-08 20:47:32 <ddevault> sent along
2019-07-08 20:47:44 <ddevault> 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 <terror_> Hi team, what's the criteria for including a new package?
2019-07-08 20:48:47 <terror_> Does it matter if it's pretty much just me that uses it?
2019-07-08 20:48:51 <ddevault> must be free software, APKBUILD must be pretty/correct (we can help with the latter)
2019-07-08 20:50:03 <ddevault> abuild will also emit warnings that you should correct should things not be ship-shape
2019-07-08 20:51:32 <maxice8> There is also apkbuild-lint and aports-lint from atools to find common mistakes and minor improvments
2019-07-08 20:51:59 <maxice8> 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 <ddevault> thanks maxice8, cheers
2019-07-08 20:53:00 <maxice8> np
2019-07-08 20:53:41 <maxice8> mps: 4967 -> 'superseeded', 4968 -> 'accepted'
2019-07-08 20:56:04 <mps> maxice8: done, and still 60 left :-)
2019-07-08 20:58:03 <terror_> 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 <danieli> fyi about pr9371: it's a trivial change
2019-07-08 21:02:35 <maxice8> danieli: i can't push to main :c
2019-07-08 21:03:05 <danieli> maxice8: it's ok <3 just thought I'd let whoever can know it's a trivial improvement
2019-07-08 21:03:10 <mps> danieli: is it for ash?
2019-07-08 21:03:22 <danieli> it's for any shell that sources /etc/profile.d/color_prompt.sh
2019-07-08 21:03:43 <danieli> bash doesn't do that by default afaik, only for login shells
2019-07-08 21:03:46 <danieli> but ash does
2019-07-08 21:03:55 <maxice8> mps: 4939 -> 'superseeded' , 4950 -> 'superseeded'
2019-07-08 21:04:26 <mps> I have it for tcsh always set like your patch
2019-07-08 21:04:31 <danieli> 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 <danieli> finally got to thinking 'hmm, I should just upstream this'
2019-07-08 21:05:58 <danieli> 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 <mps> maxice8: done
2019-07-08 21:06:23 <maxice8> mps: 4693 -> 'superseeded'
2019-07-08 21:07:08 <mps> danieli: I usually put these to $HOME/.profile (or other rc for shells)
2019-07-08 21:07:29 <maxice8> mps: 4542 -> 'superseeded'
2019-07-08 21:07:38 <ddevault> font-noto-cjk landed \o/
2019-07-08 21:07:48 <maxice8> ddevault: 4542 -> 'i removed the build() { return 0 ; } since it is not required ans pushed'
2019-07-08 21:08:12 <ddevault> thanks!
2019-07-08 21:08:24 <mps> aren't lttng-tools upgrade accepted, or it was from GH, can't remember exactly
2019-07-08 21:09:11 <mps> please, no, font-noto-cjk (my personal moaning)
2019-07-08 21:09:14 <maxice8> mps: it was done by Luca Weiss
2019-07-08 21:09:18 <maxice8> f699d4f94410ae19e737b942b848484073798747
2019-07-08 21:09:27 <mps> aha, ok will mark it
2019-07-08 21:09:50 <ddevault> mps: what's your beef?
2019-07-08 21:09:52 <ddevault> you host a mirror?
2019-07-08 21:11:11 <mps> 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 <ddevault> as originally discussed, it can't really be split
2019-07-08 21:12:07 <mps> maxice8: done
2019-07-08 21:12:10 <maxice8> what to do with this old pw https://patchwork.alpinelinux.org/patch/3851/ ?
2019-07-08 21:12:35 <maxice8> it adds an apkbuild on abuild-pkg
2019-07-08 21:13:17 <maxice8> mps: 3786 -> 'broken'
2019-07-08 21:13:22 <ddevault> ah, I see what debian is doing
2019-07-08 21:13:26 <ddevault> not opposed to doing something similar
2019-07-08 21:13:59 <mps> I'm not sure if submitter of 3851 is still active on alpine
2019-07-08 21:14:05 <mps> but not sure
2019-07-08 21:15:27 <mps> maxice8: we don't have 'broken' tag
2019-07-08 21:15:56 <mps> ddevault: nice to hear ;-)
2019-07-08 21:16:05 <ddevault> added a reminder, will look into it within the week
2019-07-08 21:16:49 <maxice8> rejected then ?
2019-07-08 21:16:52 <mps> I looked few times on your patch and always had split minds, to push or not to push
2019-07-08 21:17:08 <ddevault> I think it's useful to have in its current form as well
2019-07-08 21:17:17 <ddevault> when I split it up the combined packages are not going to be smaller
2019-07-08 21:17:33 <mps> rejected sounds better, but we should then post mail to submitter
2019-07-08 21:17:50 <ddevault> erp, you're talking about the old patch, disregard me
2019-07-08 21:18:49 <mps> ddevault: don't worry, I have same feelings with some of my patches ;-)
2019-07-08 21:19:29 <maxice8> 3786 -> rejected, wrong title, adds an aport but not its dependency and claims the license is GNU
2019-07-08 21:19:57 <maxice8> :D thanks to anyone that emails the person in question
2019-07-08 21:20:33 <mps> 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 <ddevault> when I review patches I usually give a short thanks in reply
2019-07-08 21:20:58 <maxice8> 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 <ddevault> but I don't use patchwork, I just work out of my inbox
2019-07-08 21:21:51 <mps> 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 <maxice8> 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 <ddevault> 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 <ddevault> or touching a browser at all
2019-07-08 21:23:39 <ddevault> much more efficient and makes it easy to give it the human touch with a little "thanks"
2019-07-08 21:25:11 <mps> maxice8: nice, 55 left, good job
2019-07-08 21:27:03 <mps> enough for me now, going out to walk a little before sleep
2019-07-08 21:31:17 <maxice8> mps: my task is to get under 30
2019-07-08 21:32:17 <mps> at last half of them could be simply rejected, imo
2019-07-08 21:32:33 <maxice8> mps: 4875 -> 'rejected' no answer from author for 38 days
2019-07-08 21:35:10 <mps> I'm not behind my work machine, but will note this and 'reject' it later
2019-07-08 21:39:20 <maxice8> mps: 3779 -> 'rejected' doesn't apply anymore
2019-07-08 21:40:26 <maxice8> ddevault: 4957 and 4958 are reviewed and need fixes
2019-07-08 21:42:20 <ddevault> did you not Cc me on your replies?
2019-07-08 21:45:10 <maxice8> i used neomutt's mailing list mode no clue if that does
2019-07-08 21:49:53 <maxice8> mps: 4524 -> 'accepted' made some cleanup and pushed
2019-07-08 21:50:42 <mps> ok, noted
2019-07-08 22:44:44 <danieli> what's a good way to get the current version of alpine, major.minor.patch?
2019-07-08 22:44:55 <danieli> i.e. not just 3.10, but 3.10.0
2019-07-08 22:45:03 <danieli> i have access to a mirror locally, but is there an easy way to get it?
2019-07-08 22:45:15 <danieli> i'm just reading the latest-stable symlink at the moment, but it only gives 3.10
2019-07-08 22:45:17 <ddevault> /etc/os-release?
2019-07-08 22:45:35 <ddevault> ah, you mean something else
2019-07-08 22:45:46 <danieli> the host this application is running on may not be up to date
2019-07-08 22:45:47 <ddevault> you could look at the RSS feed?
2019-07-08 22:45:51 <danieli> excellent idea
2019-07-08 22:46:57 <danieli> ^Alpine (.*) released$
2019-07-08 22:47:04 <danieli> would it be safe to assume the latest one is always at the top?
2019-07-08 22:47:22 <ddevault> ¯\_(ツ)_/¯
2019-07-08 22:47:53 <danieli> i'll go with yes
2019-07-08 23:17:49 <danieli> ncopa: i wrote a thing for alpine-mksite: http://mirror-size-api.gbr1.alpin.pw/data.json
2019-07-08 23:17:53 <danieli> i'll implement it in alpine-mksite tomorrow
2019-07-08 23:27:09 <maxice8> ddevault: "finished" dealing with telegram-desktop
2019-07-08 23:27:16 <maxice8> time to look at your patches
2019-07-08 23:28:52 <maxice8> :D they are for main, please put <repo>/<package> in the commit title
2019-07-08 23:34:13 <ddevault> didn't I? I'm sorry
2019-07-08 23:34:24 <ddevault> no, I did't :(
2019-07-09 00:09:34 <maxice8> mps: 3784 -> can problably be rejected since it adds an aport with a name that is already claimed
2019-07-09 02:44:26 <danieli> aha, there's a latest-releases.yaml file
2019-07-09 03:21:36 <maxice8> mps: 4961 -> 'superseeded'
2019-07-09 03:22:50 <maxice8> actually 'accepted'
2019-07-09 09:48:31 <mps> maxice8: PW4961 is accepted not superseded as I see
2019-07-09 09:49:18 <mps> looks like you fixed it, but at the end it is accepted with your fixes
2019-07-09 09:50:28 <maxice8> mps: Yes i said accepted one line later
2019-07-09 09:50:32 <mps> it's a pity PW doesn't have option to add comment when changing status
2019-07-09 09:51:07 <mps> oh, I missed this line somehow
2019-07-09 09:51:45 <PureTryOut[m]> maxice8: did you have time to look at stow?
2019-07-09 09:51:54 <maxice8> PureTryOut: i downgraded it
2019-07-09 09:54:50 <mps> maxice8: 3784 is accepted but commiter probably forgot to close it
2019-07-09 09:55:14 <PureTryOut[m]> Ah ok thanks
2019-07-09 09:55:26 <maxice8> oh
2019-07-09 09:56:09 <mps> git log -p testing/singularity/APKBUILD, and go to end
2019-07-09 09:57:15 <maxice8> mps: those singularities are different
2019-07-09 09:57:41 <mps> maintainer is the same and version is the same
2019-07-09 09:58:32 <mps> ./configure options are different, true
2019-07-09 09:58:36 <maxice8> oh i tis
2019-07-09 09:58:39 <maxice8> then 'accepted'
2019-07-09 09:58:54 <mps> already changed
2019-07-09 10:00:18 <mps> 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 <mps> algitbot anounce sec bugs but I can't see them
2019-07-09 10:05:08 <ncopa> its a setting in redmine i think
2019-07-09 10:05:13 <ncopa> will have a look at it
2019-07-09 10:06:43 <ncopa> i changd the developer role to see prviate issues
2019-07-09 10:06:57 <ncopa> mps: can you check if you can see them now?
2019-07-09 10:09:05 <mps> ncopa: yes, now I see them
2019-07-09 10:09:08 <mps> thanks
2019-07-09 10:10:41 <maxice8> mps: 4738 -> 'accepted'
2019-07-09 10:11:52 <mps> maxice8: done
2019-07-09 10:12:05 <maxice8> ty
2019-07-09 10:12:14 <mps> np
2019-07-09 10:19:17 <maxice8> mps: (4833 4633) -> 'rejected'
2019-07-09 10:20:03 <maxice8> mps: 4739 -> 'superseeded'
2019-07-09 10:20:39 <mps> did you sent mail for (4833 4633) to submitter
2019-07-09 10:20:48 <maxice8> no
2019-07-09 10:21:46 <mps> hmm, what to do, close without mail?
2019-07-09 10:21:52 <mps> ncopa: ^
2019-07-09 10:23:52 <mps> 4739 is actually accepted, commit 74ef3e0b4c67a5f0e4dc0d5148e91bc28508d4a1
2019-07-09 10:42:42 <maxice8> mps: 3894 -> 'accepted'
2019-07-09 11:38:08 <mps> maxice8: 3894 closed
2019-07-09 11:39:34 <maxice8> nice, ty
2019-07-09 11:39:35 <maxice8> Working on the seamonkey PR :D
2019-07-09 11:40:41 <mps> maxice8: ty for your hard work. btw, do you sleep ever
2019-07-09 11:40:57 <danieli> what is sleep?
2019-07-09 11:41:08 <mps> :-D
2019-07-09 11:41:21 <maxice8> Yes but then maxice1 through 7 take over
2019-07-09 11:41:31 <maxice8> Teamwork makes the dream work
2019-07-09 11:41:49 <mps> maxice8: could you tell whys https://patchwork.alpinelinux.org/patch/4833/ is rejected
2019-07-09 11:42:13 <mps> s/whys/why/
2019-07-09 11:42:13 <alpine-meetbot> mps meant to say: maxice8: could you tell why https://patchwork.alpinelinux.org/patch/4833/ is rejected
2019-07-09 11:42:53 <maxice8> mps: uses source with master from github not a correct commit
2019-07-09 11:43:03 <maxice8> Or a tagged release
2019-07-09 11:43:41 <mps> ah, ok, will close it
2019-07-09 11:47:21 <mps> anyone with python experience would look at https://patchwork.alpinelinux.org/patch/4094/
2019-07-09 12:34:11 <maxice8> 4887 can be pushed with a pkgrel bump
2019-07-09 12:34:16 <maxice8> after fixing the commit title as well
2019-07-09 12:40:42 <mps> maxice8: I don't have rights to push to main
2019-07-09 12:41:19 <maxice8> dammit
2019-07-09 12:41:36 <maxice8> PRs on GItHub are Pilling up for changes in main/
2019-07-09 12:41:51 <maxice8> And most stuff on pw is now main as well
2019-07-09 12:41:57 <mps> you pushed pw4885, can we close it with accepted
2019-07-09 12:42:15 <maxice8> I'm on phone can I get a link?
2019-07-09 12:42:44 <mps> https://patchwork.alpinelinux.org/patch/4885/ testing/gajim-plugin-omemo
2019-07-09 12:43:17 <mps> and testing/seamonkey looks like you fixed it
2019-07-09 12:44:07 <maxice8> Yes I could swear the gajim one was automatically marked accepted
2019-07-09 12:44:17 <maxice8> If not then please do and seamonkey as well
2019-07-09 12:45:28 <mps> yes, sorry, probably my browser cache problem
2019-07-09 12:54:54 <mps> 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 <Cadey> how do I add something to run on boot in alpine?
2019-07-09 13:03:57 <Cadey> i'm looking for the equivalent of a systemd oneshot unit
2019-07-09 13:06:04 <mps> Cadey: read /etc/local.d/README
2019-07-09 13:07:01 <mps> and, user support is better on #alpine-linux channel than here
2019-07-09 13:07:12 <Cadey> interesting, thanks
2019-07-09 13:47:34 <PureTryOut[m]> What does it mean when abuild finds textrels in a package?
2019-07-09 13:53:55 <mps> https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2019-07-09 13:56:14 <mps> i.e. text relocations
2019-07-09 14:37:52 <PureTryOut[m]> Thanks
2019-07-09 15:10:17 <ddevault> mps: new syslinux and flask patches up, thanks for your patience
2019-07-09 15:29:14 <mps> ddevault: thanks, now we just have to ask someone with main access to push them
2019-07-09 16:22:26 <ncopa> mps: what do you want me to push?
2019-07-09 16:24:17 <mps> ncopa: ddevault posted some patches to main on pw.a.o
2019-07-09 16:24:21 <mps> let me see
2019-07-09 16:24:36 <ncopa> syslinux update default kernel
2019-07-09 16:24:41 <ncopa> im pushing that now
2019-07-09 16:24:50 <mps> yes, https://patchwork.alpinelinux.org/patch/4977/
2019-07-09 16:25:15 <ddevault> the py3-flask and py3-werkzeug upgrades also affect main
2019-07-09 16:25:56 <mps> eh, nice, ddevault is here, he will explain better than me
2019-07-09 16:26:05 <ncopa> ddevault: have checked that there is nothing that dpends on py2-flask or py2-werkzeug?
2019-07-09 16:26:45 <ddevault> eh, that would have been wise to do
2019-07-09 16:27:01 <ncopa> community/py-flask-login/APKBUILD:      py2-flask
2019-07-09 16:27:01 <ncopa> community/py-flask-login/APKBUILD:subpackages="py2-flask-login:py2 py3-flask-login:py3"
2019-07-09 16:27:01 <ncopa> testing/py-flask-sqlalchemy/APKBUILD:subpackages="py2-flask-sqlalchemy:py2 py3-flask-sqlalchemy:py3"
2019-07-09 16:27:01 <ncopa> main/py-flask-wtf/APKBUILD:subpackages="py2-flask-wtf:py2 py3-flask-wtf:py3"
2019-07-09 16:27:05 <ddevault> looks like 3 other packages will be affected
2019-07-09 16:27:14 <ddevault> I'll take care of them tonight
2019-07-09 16:27:32 <ncopa> sounds good
2019-07-09 16:27:45 <ncopa> thanks for getting rid of python2 stuff. appreciate
2019-07-09 16:27:59 <ddevault> np
2019-07-09 16:28:13 <ddevault> at some point soon I'll be starting on a larger python2 deprecation project
2019-07-09 20:59:09 <tcely> 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 <tcely> s/sure/directory/
2019-07-09 20:59:50 <alpine-meetbot> 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 <tcely> 
ACTION needs to review txt replacement rules to see what lead to sure

2019-07-09 21:14:24 <mps> tcely: afaik /var/run is created as symlink to run on boot, if your question was about this
2019-07-09 21:16:36 <tcely> 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 <tcely> dhcp and irqbalance come to mind
2019-07-09 21:17:54 <tcely> A generic solution that happens early in the boot sequence might be better than changes to individual packages
2019-07-09 21:19:07 <MY_R>  /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 <HRio> https://github.com/alpinelinux/aports/pull/9384
2019-07-09 21:20:25 <MY_R> 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 <tcely> 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 <MY_R> tcely, yep
2019-07-09 21:23:42 <MY_R> HRio, thank you!
2019-07-09 21:24:12 <HRio> simple enough for a 3.10 backport
2019-07-09 21:24:53 <tcely> 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 <HRio> does systemd does something "magical" for dirs like this?
2019-07-09 21:25:22 <MY_R> irqbalance was still working fine without it but upstream somehow decided to make file-based sock dunno, default?
2019-07-09 21:25:24 <HRio> do on the second does :-)
2019-07-09 21:26:13 <tcely> s/d does/d do/
2019-07-09 21:26:20 <tcely> ;-)
2019-07-09 21:26:23 <HRio> :-)
2019-07-09 21:31:29 <HRio> im going to bed. good night
2019-07-09 21:32:43 <MY_R> gn8!
2019-07-09 22:58:33 <maxice8> ddevault ping
2019-07-09 22:58:49 <maxice8> :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 <ddevault> maxice8: I'm here but only somewhat paying attention
2019-07-09 23:01:24 <tboerger[m]> is there some specific reason why cabal and ghc are only built for x86_64? no arm/arm64?
2019-07-09 23:01:50 <maxice8> ddevault: good enough
2019-07-09 23:03:44 <Cogitri> tboerger: I guess no one had time/interest making it happen on other arches yet
2019-07-09 23:06:05 <tboerger[m]> no other reason than that?
2019-07-09 23:06:26 <maxice8> tboerger: If there is another it is normally listed near the arch="" definition on the APKBUILD
2019-07-09 23:08:38 <tboerger[m]> mkay, nothing written down there
2019-07-09 23:12:43 <ddevault> maxice8: afk, but I will review my highlights when I return
2019-07-09 23:16:13 <maxice8> ddevault: 4983 -> license is non-SPDX 'BSD' and no need for mkdir -p "$pkgdir"
2019-07-09 23:16:46 <maxice8> mps: 4981 -> 'accepted'
2019-07-09 23:17:53 <maxice8> mps: 4978 4980 -> 'superseeded'
2019-07-09 23:17:55 <maxice8> ddevault: 4984 -> replaces= and provides= are for py-example and not the actual package
2019-07-09 23:18:20 <maxice8> rest looks OK to me
2019-07-09 23:21:04 <danieli> tboerger[m]: i'll test build it on aarch64
2019-07-09 23:25:44 <danieli> that's a bit of a messy apkbuild - remind me, how do i bootstrap it?
2019-07-09 23:33:16 <tboerger[m]> 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 <tcely> +1 for getting that working
2019-07-10 02:18:43 <ddevault> maxice8: thanks, I'll have another patch tomorrow
2019-07-10 02:18:45 <ddevault> (es)
2019-07-10 02:19:24 <ddevault> one of these days I'll get better at looking over my commits before sending them
2019-07-10 07:57:51 <mps> maxice8: done 4981 4978 4980
2019-07-10 11:38:26 <maxice8> mps: ty
2019-07-10 11:46:12 <mps> maxice8: you did a hard part so credit goes to you
2019-07-10 11:48:24 <maxice8> Yes, ty maxice8 and mps
2019-07-10 12:02:57 <tboerger[m]> 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 <tboerger[m]> but `abuild -r` also won't work because the ghc packages references ghc-bootstrap as a make dep
2019-07-10 12:04:38 <clandmeter> that shouldnt
2019-07-10 12:04:44 <clandmeter> its a bootstrap dep
2019-07-10 12:04:51 <clandmeter> if its in aports it should pick that
2019-07-10 12:05:09 <tboerger[m]> ghc provides ghc-bootstrap
2019-07-10 12:05:19 <tboerger[m]> 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 <Cogitri> tboerger: Yup, it's selfhosted
2019-07-10 12:06:38 <tboerger[m]> 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 <tboerger[m]> 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 <danieli> self hosted = it compiles itself
2019-07-10 12:08:09 <danieli> iirc yes
2019-07-10 12:08:24 <Cogitri> Yup
2019-07-10 12:08:25 <Cogitri> 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 <clandmeter> do you have repo enabled that has it?
2019-07-10 12:10:12 <tboerger[m]> and how does it work for a new architecture?
2019-07-10 12:10:21 <clandmeter> you need to bootstrap it
2019-07-10 12:10:23 <tboerger[m]> 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 <clandmeter> new archs are more difficult
2019-07-10 12:11:05 <clandmeter> there is probably a good reason its not available yet.
2019-07-10 12:11:16 <clandmeter> you should ask the maintainer
2019-07-10 12:11:23 <tboerger[m]> damn haskell -.-
2019-07-10 12:11:27 <clandmeter> before you waste your time on it
2019-07-10 12:11:35 <danieli> haskell isn't the only self-hosting compiler ;)
2019-07-10 12:12:02 <danieli> 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 <danieli> other times you may have to cross-compile
2019-07-10 12:12:21 <danieli> which is a major pain in the buttocks on alpine
2019-07-10 12:12:28 <tboerger[m]> 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 <tboerger[m]> i just want to get shellcheck running on arm/arm64
2019-07-10 12:15:57 <clandmeter> rust,,
2019-07-10 12:16:39 <danieli> it's unfortunately not as easy as just getting shellcheck to work
2019-07-10 12:17:46 <tboerger[m]> sounds like i just got to replace this stupid shellcheck stuff :(
2019-07-10 12:18:12 <danieli> i'll have a quick look at porting haskell to alpine aarch64
2019-07-10 12:18:15 <clandmeter> like i said, try contacting the maintainer
2019-07-10 12:18:20 <clandmeter> not sure who it is
2019-07-10 12:18:22 <danieli> 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 <clandmeter> they are completely static?
2019-07-10 12:21:15 <tboerger[m]> but no arm64
2019-07-10 12:21:59 <danieli> looks like there's no aarch64
2019-07-10 12:23:47 <tboerger[m]> https://github.com/koalaman/shellcheck/issues/1569
2019-07-10 12:24:31 <tboerger[m]> so i need to cross compile for arm64 on an amd64 host...
2019-07-10 12:25:22 <tboerger[m]> 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 <tboerger[m]>  * ERROR: sshd failed to start
2019-07-10 12:26:20 <danieli> ask it in #alpine-linux and i'll help you troubleshoot it
2019-07-10 12:27:06 <clandmeter> tboerger[m]: did you upgrade with --available switch?
2019-07-10 12:27:11 <tboerger[m]> 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 <danieli> ouch, closing the open ssh session without sshd running is not a good idea
2019-07-10 12:27:31 <danieli> been there, done that
2019-07-10 12:35:02 <danieli> i had a look at it, i definitely don't have time to do this today
2019-07-10 13:12:43 <tboerger[m]> i will try the cross compile approach...
2019-07-10 13:12:55 <tboerger[m]> (for my shellcheck use case)
2019-07-10 13:15:42 <danieli> 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 <tboerger[m]> yeah was just talking about my current problem :D
2019-07-10 16:34:10 <b17wise> Is utmp/wtmp supported by musl yet? Is there any WIP on this?
2019-07-10 16:36:47 <mps> b17wise: you can use utmps pkg
2019-07-10 16:38:45 <b17wise> mps: Ok. So should I disable utmp in busybox build (customized build) and install utmps?
2019-07-10 16:57:44 <mps> b17wise: just isntall and set up utmps
2019-07-10 17:51:56 <ddevault> 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 <ddevault> https://lists.alpinelinux.org/~alpine/aports/patches/2800
2019-07-10 18:00:40 <maxice8> ddevault: mps I think
2019-07-10 18:00:57 <maxice8> Am driving I'll look later
2019-07-10 18:01:36 <_ikke_> and still on irc?
2019-07-10 18:02:35 <jwh> hasn't noticed all the pedestrians stuck to the under carriage
2019-07-10 18:02:37 <jwh> :D
2019-07-10 18:02:46 <ddevault> yo don't IRC and drive
2019-07-10 18:07:28 <mps> ddevault: I'm also outside home, will look tomorrow if maxice8 does not in finish it in meantime ;)
2019-07-10 18:07:42 <ddevault> no rush
2019-07-10 18:07:53 <ddevault> I did promise to deal with it on Friday so technically that makes me a liar
2019-07-10 18:08:38 <mps> friends from far country arrived to visit
2019-07-10 18:09:02 <maxice8> jwh: I was wondering why they added so many new speed bumps
2019-07-10 18:09:07 <jwh> lol
2019-07-10 18:14:54 <danieli> f... yeah! that elixir bug got patched :)
2019-07-10 18:14:59 <danieli> proper ol' heisenbug
2019-07-10 18:36:36 <maxice8> _ikke_: yes
2019-07-10 18:36:43 <maxice8> ddevault: back, i'll take a look at your noto-cjk-thing
2019-07-10 18:36:53 <ddevault> thanks!
2019-07-10 18:37:37 <maxice8> the patch isn't on patchwork
2019-07-10 18:37:38 <maxice8> someone please guide me, i'm scared and confused
2019-07-10 18:37:54 <ddevault> https://lists.alpinelinux.org/~alpine/aports/patches/2801
2019-07-10 18:38:25 <maxice8> ah nice
2019-07-10 18:40:05 <maxice8> i pushed, it didn't change from PROPOSED to APPROVED (or whatever it should be)
2019-07-10 18:40:35 <ddevault> yeah
2019-07-10 18:40:36 <_ikke_> Does not happen automatically for PW
2019-07-10 18:40:37 <ddevault> that may be an issue
2019-07-10 18:40:55 <_ikke_> ah right
2019-07-10 18:41:02 <maxice8> _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 <maxice8> yes
2019-07-10 18:41:53 <maxice8> 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 <ddevault> 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 <ddevault> where they can then tick a patch over to approved or whatever
2019-07-10 18:44:38 <ddevault> but this isn't something which is supported yet
2019-07-10 18:44:51 <ddevault> 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 <ddevault> 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 <ddevault> that github script can be adapted today, I think
2019-07-10 18:45:40 <ddevault> https://man.sr.ht/lists.sr.ht/api.md
2019-07-10 18:45:51 <ddevault> you can fetch patchsets, the emails therein, and update patch status with the lists.sr.ht API
2019-07-10 18:45:56 <ddevault> where does that script live?
2019-07-10 18:46:04 <_ikke_> on git.alpinelinux.org
2019-07-10 18:47:11 <ddevault> 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 <ddevault> oh
2019-07-10 18:47:41 <_ikke_> not sure if it's in a repo somewhere
2019-07-10 18:47:42 <ddevault> 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 <ddevault> 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 <tcely> I'm not familiar with fonts, but shouldn't there be a subpackage containing *.otf files too?
2019-07-10 18:52:39 <ddevault> 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 <ddevault> maybe it's cargo culting but it makes for a smaller package /shrug
2019-07-10 18:54:10 <tcely> 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 <ddevault> aye
2019-07-10 19:01:13 <_ikke_> ddevault: source: https://github.com/jirutka/github-pr-closer
2019-07-10 19:01:24 <ddevault> capital
2019-07-10 19:01:55 <tcely> http://tpaste.us/Bolk
2019-07-10 19:02:35 <ddevault> 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 <ddevault> more research required
2019-07-10 19:02:59 <tcely> Hmm. Not having otf seems to be the bigger / easier option.
2019-07-10 19:06:31 <ddevault> _ikke_: doesn't look especially reusable but I can put together something similar
2019-07-10 19:19:13 <tcely> I wonder if using a keyword for closing wouldn't work better.
2019-07-10 19:22:13 <tcely> 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 <iggy> 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 <iggy> 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 <PureTryOut[m]> 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 <maxice8> 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 <PureTryOut[m]> Do they need an upgrade?
2019-07-10 20:57:28 <PureTryOut[m]> It's the same build, nothing has changed that requires an update for them
2019-07-10 21:45:41 <SpaceToast> someone here was asking about maximum package name length, iirc
2019-07-10 21:45:47 <SpaceToast> fyi it's 40 printable characters
2019-07-10 21:45:55 <SpaceToast> (it's been a bit, but maybe it's still useful :) )
2019-07-11 16:32:42 <maxice8> need testers for pr9406
2019-07-11 17:27:21 <ncopa> im about to tag 3.10.1 release now
2019-07-11 18:41:52 <mps> where we now send mail patches, to pw.a.o or to sr.ht
2019-07-11 18:44:02 <mps> 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 <mps> shouldn't these be same?
2019-07-11 18:52:49 <tmhoang1> ncopa: any change for 3.10.1 ?
2019-07-11 18:55:51 <mps> 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 <tmhoang> we really need CI
2019-07-11 18:59:10 <tmhoang> for every arch
2019-07-11 18:59:18 <mps> tmhoang: you mean release notes for 3.10.1?
2019-07-11 18:59:50 <tmhoang> 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 <mps> ah, yes.
2019-07-11 19:00:40 <tmhoang> regarding 3.10.1 ? ah right I'm curious what's significant change from 3.10.0
2019-07-11 19:00:48 <mps> something like drones
2019-07-11 19:00:59 <tmhoang> didn't keep track for the last month ...
2019-07-11 19:01:09 <mps> tmhoang: release notes are on the main site
2019-07-11 19:01:18 <tmhoang> thought with gitlab we can have remote slaves ?
2019-07-11 19:01:51 <tmhoang> drones host everything in their infra afaik
2019-07-11 19:01:53 <mps> gitlab have CI but not sure if for all alpine arch's
2019-07-11 19:03:41 <tmhoang> afaik gitlab allows remote slave/builder
2019-07-11 19:03:59 <tmhoang> so should be doable to have remote slave for all arch
2019-07-11 19:04:04 <mps> 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 <tmhoang> after all that's one of the benefit of gitlab iirc
2019-07-11 19:04:34 <mps> to me drones looks really nice
2019-07-11 19:35:06 <tmhoang> 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 <tmhoang> https://bugs.launchpad.net/ubuntu/+source/boost/+bug/1694926
2019-07-11 19:35:38 <tmhoang> I would like to revert to disable them
2019-07-11 19:35:53 <tmhoang> pdns-recursor seems to be looking for context functions
2019-07-11 19:36:10 <tmhoang> and it fails now
2019-07-11 20:10:30 <Cadey> 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 <ddevault> what client do you use?
2019-07-11 20:12:35 <danieli> Cadey: sounds like you'll be unable to send emails to the list, unfortunately
2019-07-11 20:13:10 <Cadey> ddevault: spark mail for iOS, it has no settings to toggle plain text only
2019-07-11 20:13:26 <ddevault> 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 <danieli> it's not even possible to change fonts in that client fyi
2019-07-11 20:19:58 <Cadey> i guess i just won't participate in the mailing list then
2019-07-11 20:20:02 <Cadey> sorry for the bother
2019-07-11 22:42:35 <maxice8> ddevault: patches to the https://lists.alpinelinux.org/~alpine/aports/patches/ have any form of CI ?
2019-07-11 22:42:45 <ddevault> no, but it will soon
2019-07-11 22:43:07 <maxice8> ok, thanks
2019-07-11 22:43:18 <maxice8> hopefully soon enough :D just met a massive patch for updating plasma
2019-07-11 22:44:07 <ddevault> we can do a little CI ad-hoc if you'd like
2019-07-11 22:45:06 <maxice8> 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 <ddevault> let me take a crack at CI'ing this
2019-07-11 22:45:40 <maxice8> too late
2019-07-11 22:45:42 <ddevault> and yeah, registration is closed deliberately, but I can get youa n invite
2019-07-11 22:45:44 <ddevault> you an*
2019-07-11 22:48:41 <mps> so, patchwork.a.o is retired now?
2019-07-11 22:49:12 <ddevault> that wasn't discussed
2019-07-11 22:49:25 <maxice8> well new patches didn't appear there
2019-07-11 22:49:27 <ddevault> lists.a.o does offers something similar now
2019-07-11 22:49:31 <ddevault> s/offers/offer/
2019-07-11 22:49:31 <alpine-meetbot> ddevault meant to say: lists.a.o does offer something similar now
2019-07-11 22:49:59 <ddevault> 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 <mps> I see my patch posted to pw.a.o on https://lists.alpinelinux.org/~alpine/aports
2019-07-11 22:51:15 <mps> but not on pw.a.o
2019-07-11 22:54:10 <mps> maxice8: I see you pushed one patch from https://lists.alpinelinux.org/~alpine/aports/patches/2805
2019-07-11 22:54:30 <maxice8> yes
2019-07-11 22:55:06 <mps> how did you do this? download raw and 'git am'?
2019-07-11 22:55:55 <ddevault> click "how do I use this" and it has a pastable curl command
2019-07-11 22:56:20 <mps> ddevault: I've seen it
2019-07-11 22:56:25 <maxice8> http://ix.io/1OcP
2019-07-11 22:57:10 <maxice8> small script i use i just scroll around the patches and put pw $num
2019-07-11 22:57:12 <mps> ah, I see. thanks both for info
2019-07-11 22:58:00 <mps> (big changes when I'm on vacation)
2019-07-11 23:25:16 <ddevault> on the subject of CI
2019-07-11 23:25:24 <maxice8> i'm all ears
2019-07-11 23:25:33 <ddevault> 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 <ddevault> based on the travis stuff
2019-07-11 23:25:43 <ddevault> https://builds.sr.ht/api/jobs/75025/manifest
2019-07-11 23:26:01 <ddevault> little hacky but mainly because it's adapting a script designed for travis
2019-07-11 23:52:20 <maxice8> ddevault: How is automatically changing PROPOSED patches to ACCEPTED when they pushed are going to work ?
2019-07-11 23:52:33 <ddevault> magic
2019-07-11 23:52:35 <ddevault> (I'm busy)
2019-07-12 00:23:05 <PureTryOut[m]> 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 <ddevault> excellent :)
2019-07-12 00:28:06 <ddevault> maxice8: the answer boils down to checking the commit author date against the dates on the ml
2019-07-12 00:28:26 <ddevault> should work even if the commit is amended or endures a certain amount of rebasing
2019-07-12 00:30:20 <maxice8> Nice, thanks for the answer.
2019-07-12 06:28:02 <Cogitri> 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 <errn0> PureTryOut: Oh.. Alpine moved to sourcehut? Umm... I already use sourcehut
2019-07-12 06:40:50 <danieli> i was not aware we've moved to sourcehut
2019-07-12 06:41:03 <danieli> 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 <Cogitri> I think the mailing list has been moved to sourcehut
2019-07-12 06:45:56 <danieli> 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 <danieli> 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 <tmhoang> PureTryOut[m]: I have been using git send-mail since the beginning with lists.a.o
2019-07-12 13:45:11 <mps> PureTryOut[m]: 'upgrade to' not 'update to' is prefered commit message in aports
2019-07-12 14:53:45 <PureTryOut[m]> Oh ok will change next time
2019-07-12 14:58:51 <mps> thank you (heartily)
2019-07-12 17:28:19 <maxice8> 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 <maxice8> _ikke_: Thank you :D
2019-07-12 17:29:24 <maxice8> Hope it was fun
2019-07-12 17:29:29 <_ikke_> it certainly was
2019-07-12 19:15:59 <PureTryOut[m]> Is there a reason registrations at https://lists.alpinelinux.org are closed?
2019-07-12 19:19:04 <clandmeter> its only needed for admins atm
2019-07-12 19:36:51 <PureTryOut[m]> Hmm ok.
2019-07-12 19:37:31 <PureTryOut[m]> 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 <clandmeter> user registration has been disabled on redmine
2019-07-12 19:49:12 <clandmeter> we are doing last minute checks before switching
2019-07-12 19:51:01 <clandmeter> please do not create any issues on redmine.
2019-07-12 19:52:51 <PureTryOut[m]> 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 <PureTryOut[m]> Ah nice!
2019-07-12 20:18:06 <PureTryOut[m]> 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 <PureTryOut[m]> https://todo.sr.ht/
2019-07-13 02:51:38 <tmhoang> 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 <danieli> the mailing lists @ lists.a.o is not a part of sr.ht
2019-07-13 02:52:15 <danieli> it's just using the same software as it
2019-07-13 07:08:49 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <tmhoang> PureTryOut[m] : some grep for main,community,testing/*/APKBUILD
2019-07-13 09:09:17 <tmhoang> check for runtime dependencies only, I think makedepend dont really need
2019-07-13 09:09:38 <tmhoang> git log might have many examples
2019-07-13 09:11:09 <Cogitri> 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 <Cogitri> PureTryOut: Search for everything which depends on so:<lib>
2019-07-13 09:16:05 <PureTryOut[m]> Thanks will do
2019-07-13 09:17:27 <mps> rebuidl is not needed if there are no api/abi changes in libs
2019-07-13 09:19:11 <fr0xk> Just asking, do you guys share work with the project "sabotage linux" ?
2019-07-13 09:25:26 <fr0xk> sabotage linux is also musl based linux distro
2019-07-13 10:02:51 <danieli> i do not know of any cooperation with sabotage linux
2019-07-13 10:02:57 <danieli> not anything official or noticeable (to me) anyway
2019-07-13 10:04:50 <Cogitri> Neither do I, but I guess musl related patches might be shared between us sometimes?
2019-07-13 10:05:03 <Cogitri> Dunno, I haven't looked at Sabotage yet
2019-07-13 10:05:25 <danieli> borrowing patches and stuff like that happens on occasion, but it mostly happens with arch and void afaik
2019-07-13 10:05:44 <Cogitri> Arch? :o
2019-07-13 10:06:08 <Cogitri> 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 <Cogitri> (Actually, maybe with alarm?)
2019-07-13 10:06:55 <danieli> arch has a similar build system with their PKGBUILDs
2019-07-13 10:06:56 <danieli> er
2019-07-13 10:07:15 <danieli> we sometimes borrow from their pkgbuilds, not their non-existent musl patches
2019-07-13 10:07:44 <Cogitri> Ah, alright
2019-07-13 10:08:32 <fr0xk> Neat..
2019-07-13 10:17:01 <Cogitri> To be honest, I don't see how we should collaborate more than by sharing some patches
2019-07-13 10:22:38 <danieli> same
2019-07-13 10:23:24 <clandmeter> its opensource, we borrow (check) each others stuff all the time.
2019-07-13 10:24:59 <clandmeter> we also co-op regarding reproducible builds.
2019-07-13 10:25:13 <clandmeter> but not with sabotage afaik
2019-07-13 10:28:29 <Cogitri> Ah, yes, it's more of a common goal than a cooperation I guess
2019-07-13 13:10:56 <fr0xk> Cogitri: Yeah. I mean sharing patches is enough..
2019-07-13 18:43:56 <maxice8> PureTryOut: purpose is failing to build
2019-07-13 18:44:54 <PureTryOut[m]> Ah shit. Don't have access to pc atm. Got a buid log?
2019-07-13 18:45:04 <maxice8> alpine-commits has URL with logs
2019-07-13 18:45:22 <maxice8> kirigmami2-dev is missing from depends
2019-07-13 18:45:40 <PureTryOut[m]> Oh new dep which I missed then, easy enough to fix
2019-07-13 18:48:55 <maxice8> i'll add it and work from there
2019-07-13 18:51:13 <PureTryOut[m]> Thanks
2019-07-13 19:12:48 <PureTryOut[m]> 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 <maxice8> kdewebkit was downgraded to PortingAids and so had an invalid source=
2019-07-13 19:18:37 <PureTryOut[m]> Oh obviously
2019-07-13 19:18:43 <PureTryOut[m]> I saw that in changelogs
2019-07-13 19:19:04 <PureTryOut[m]> Completely forgot the fact that the url wouldn't work anymore
2019-07-13 21:19:51 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/issues/10230 can be closed
2019-07-14 17:41:00 <tcely> Cogitri: https://github.com/alpinelinux/aports/commit/69851bdae1177246337f51a35734e93f1fd7e3d3#r34296989
2019-07-14 17:41:24 <danieli> nice!
2019-07-14 18:15:03 <maxice8> tcely: He is on vacation
2019-07-14 18:59:59 <tcely> maxice8: thanks. There was no rush.
2019-07-14 19:00:44 <tcely> pr9445 could use a review if anyone is around
2019-07-14 19:02:49 <tcely> There are others too: https://github.com/alpinelinux/aports/labels/S-needs-review
2019-07-14 23:31:37 <Cogitri> tcely: Thanks for the ping
2019-07-14 23:46:51 <maxice8> We had mingw-w64 previously ?
2019-07-15 00:04:02 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/issues/8971
2019-07-15 05:57:10 <ncopa> good morning
2019-07-15 05:58:04 <b17wise> ncopa: Good morning
2019-07-15 07:34:00 <b17wise> 'go' throws a missing 'cgo' message.
2019-07-15 08:38:07 <danieli> b17wise: try CGO_ENABLED=0 go ...
2019-07-15 08:38:43 <b17wise> okay...
2019-07-15 09:44:41 <hrio[m]> Can pr9384 be committed? I will prepare a backport to 3.10 after that.
2019-07-15 14:37:53 <maxice8> opinons on https://gitlab.alpinelinux.org/alpine/aports/issues/5558 ?
2019-07-15 14:41:29 <danieli> sounds like a good idea to me
2019-07-15 14:44:06 <ncopa> we normally dont do that
2019-07-15 14:44:48 <ncopa> the thinking is that during build time you will normally need compiler and lots of other stuff anyway
2019-07-15 14:45:04 <ncopa> and i am afraid it will require some work to maintain a splitted boost-dev
2019-07-15 14:45:58 <ncopa> 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 <maxice8> it will most certainly require a lot of work to create each _dev function
2019-07-15 15:24:28 <maxice8> i'll keep it open
2019-07-15 15:41:33 <tcely> The interdependence of boost-*-dev subpackages will be a nightmare
2019-07-15 16:19:54 <maxice8> tcely: i agree, Void also has a single -dev
2019-07-15 16:57:14 <oneinsect> hello
2019-07-15 16:57:20 <oneinsect> good day folks!
2019-07-15 16:59:03 <oneinsect> 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 <oneinsect> and build rest of the components?
2019-07-15 16:59:29 <oneinsect> and build rest of the components using that abuild version?
2019-07-15 17:06:02 <artok> basically "just" edit apkbuild files and switch musl -> your libc
2019-07-15 17:06:53 <oneinsect> but abuild itself is built against muslc?
2019-07-15 17:07:24 <oneinsect> so should i rebuild abuild and then make changes to apkbuild files and then build?
2019-07-15 17:09:09 <artok> what would be the reason to do that?
2019-07-15 17:09:34 <oneinsect> will i have any dependency issues?
2019-07-15 17:09:36 <artok> LFS is good read if you want to have system of your choise
2019-07-15 17:10:01 <artok> you need to edit many files at least
2019-07-15 17:11:33 <oneinsect> 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 <oneinsect> https://pkgs.alpinelinux.org/package/edge/main/x86_64/musl
2019-07-15 17:11:51 <oneinsect> so what you say is true...need to edit many files
2019-07-15 17:13:07 <artok> that's why Linux From Scratch might be good to learn
2019-07-15 17:14:22 <b17wise> 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 <b17wise> non compatible*
2019-07-15 17:15:03 <oneinsect> aha
2019-07-15 17:15:14 <oneinsect> so i have to build say glibc first
2019-07-15 17:15:17 <b17wise> 
ACTION maintains an own CLFS

2019-07-15 17:15:38 <artok> as said, there is good documentation for (C)LFS
2019-07-15 17:16:22 <oneinsect> hmmmm
2019-07-15 17:16:55 <b17wise> oneinsect: It is not hard, but time consuming work
2019-07-15 17:17:30 <oneinsect> i want to do it....build glibc and then build alpine over it from source
2019-07-15 17:17:53 <b17wise> oneinsect: Read CLFS and do so
2019-07-15 17:18:12 <b17wise> I did so.. took a month
2019-07-15 17:18:30 <oneinsect> 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 <b17wise> 
ACTION encourage oneinsect to hack so. It is fun

2019-07-15 17:19:40 <oneinsect> correct i will remove patches that were added
2019-07-15 17:19:44 <oneinsect> and i was looking at
2019-07-15 17:19:45 <oneinsect> https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh
2019-07-15 17:19:58 <oneinsect> meanwhile i will check http://clfs.org/view/clfs-embedded/x86/
2019-07-15 17:21:18 <b17wise> 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 <b17wise> s/to/against
2019-07-15 17:21:44 <alpine-meetbot> 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 <oneinsect> i can quickly setup debian and a chroot and then install glibc and compile abuild
2019-07-15 17:22:59 <oneinsect> i wrote this guide...ported alpine to a couple of arm boards
2019-07-15 17:22:59 <oneinsect> 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 <oneinsect> wouldnt that be easy ?
2019-07-15 17:23:57 <oneinsect> sorry
2019-07-15 17:24:09 <oneinsect> let me leave cross compiling out of the picture
2019-07-15 17:24:17 <oneinsect> its for an x64 build
2019-07-15 17:24:30 <oneinsect> alpine os but working fully against glibc including busybox
2019-07-15 17:24:39 <oneinsect> 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 <oneinsect> _ikke_ let me fireway my debian 10 then
2019-07-15 17:25:48 <oneinsect> :-D
2019-07-15 17:26:00 <_ikke_> I would use an alpine installation
2019-07-15 17:26:05 <oneinsect> oooh
2019-07-15 17:26:16 <oneinsect> i have alpine
2019-07-15 17:26:19 <oneinsect> installed
2019-07-15 17:26:21 <_ikke_> or at least an alpine chroot
2019-07-15 17:26:26 <artok> having abuild stuff is neat
2019-07-15 17:26:32 <b17wise> oneinsect: You can actually use alpine itself to build a glibc iso
2019-07-15 17:27:20 <oneinsect> i can avoid mkinitfs and use my script to build glibc build iso
2019-07-15 17:28:32 <oneinsect> thanks b17wise artok and _ikke_
2019-07-15 17:28:40 <oneinsect> i will begin it now
2019-07-15 17:28:54 <oneinsect> i will buzz if i am struck ...please help if you have time
2019-07-15 17:29:37 <b17wise> oneinsect: Sure
2019-07-15 17:33:41 <maxice8> 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 <maxice8> _ikke_: thanks :D
2019-07-15 17:54:09 <oneinsect> can anyone tell me what is the use of this static version of apk tools?
2019-07-15 17:54:10 <oneinsect> 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 <oneinsect> aha
2019-07-15 17:56:23 <_ikke_> same for busybox-static
2019-07-15 17:56:31 <maxice8> _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 <PureTryOut[m]> Could anyone review? https://github.com/alpinelinux/aports/pull/9290
2019-07-15 18:00:06 <oneinsect> some lines are hard coded to musl in abuild
2019-07-15 18:00:07 <oneinsect> https://git.alpinelinux.org/abuild/tree/abuild.in#n580
2019-07-15 18:01:21 <oneinsect> have to see how they work in glibc...need to make some changes
2019-07-15 18:02:09 <oneinsect> 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 <oneinsect> 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 <oneinsect> 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 <oneinsect> yup
2019-07-15 18:04:43 <PureTryOut[m]> Also could someone review https://github.com/alpinelinux/aports/pull/9319?
2019-07-15 18:07:10 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> In that case I have yet to receive an email
2019-07-15 18:10:52 <PureTryOut[m]> 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 <PureTryOut[m]> I'm not sure how to determine what emails those are from that info
2019-07-15 18:17:40 <PureTryOut[m]> 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 <maxice8> _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 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> Yes it should
2019-07-15 18:28:44 <PureTryOut[m]> It doesn't say why it's rejected?
2019-07-15 18:28:56 <_ikke_> no
2019-07-15 18:31:03 <PureTryOut[m]> Well that's useful...
2019-07-15 18:31:25 <PureTryOut[m]> 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 <ddevault> may not be dkim related
2019-07-15 18:32:17 <ddevault> milters can do any number of things
2019-07-15 18:32:37 <_ikke_> ah ok
2019-07-15 18:32:44 <ddevault> milter -> mail filter
2019-07-15 18:32:49 <_ikke_> right
2019-07-15 18:33:40 <PureTryOut[m]> So it's still an issue on the sender side?
2019-07-15 18:33:46 <_ikke_> receiver
2019-07-15 18:34:03 <ddevault> 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 <PureTryOut[m]> woops that is what I meant
2019-07-15 18:35:06 <PureTryOut[m]> Not to any sr.ht list no
2019-07-15 18:35:15 <ddevault> okay
2019-07-15 18:35:45 <PureTryOut[m]> I don't mind subscribing to one for a bit if that helps figuring out this issue though
2019-07-15 18:36:52 <ddevault> ~sircmpwn/sr.ht-announce+subscribe@lists.sr.ht
2019-07-15 18:45:13 <PureTryOut[m]> 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 <ddevault> yeah
2019-07-15 18:45:48 <ddevault> did you get a reply?
2019-07-15 18:45:50 <ddevault> confirmation*
2019-07-15 18:47:20 <PureTryOut[m]> Nope
2019-07-15 18:47:24 <PureTryOut[m]> Oh actually now I have
2019-07-15 18:48:34 <ddevault> coolio
2019-07-15 18:48:36 <ddevault> thanks
2019-07-15 18:48:54 <ddevault> 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 <PureTryOut[m]> Yeah I read the confirmation mail 😉
2019-07-15 18:51:43 <PureTryOut[m]> 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 <ddevault> 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 <PureTryOut[m]> 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 <ddevault> I'd just route the mail around it in postfix
2019-07-15 18:56:46 <ddevault> 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 <ddevault> PureTryOut[m]: can you join #alpine-infra?
2019-07-15 19:19:29 <tcely> maxice8: why the redundant comment on pr9408 ?
2019-07-15 19:20:30 <maxice8> 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 <tcely> Ok. I'll clean that up then.
2019-07-15 19:35:32 <maxice8> Still up https://gitlab.alpinelinux.org/alpine/aports/issues/7984
2019-07-15 22:15:53 <PureTryOut[m]> Holy shit that's a quick merge maxice8, thanks!
2019-07-15 22:16:48 <maxice8> PureTryOut: don't need to wait for CI to be green
2019-07-15 22:20:17 <PureTryOut[m]> Interesting
2019-07-16 06:50:09 <tcely> pr7555 looks like an easy merge
2019-07-16 08:38:57 <maxice8> 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 <tmhoang> 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 <PureTryOut[m]> `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 <PureTryOut[m]> 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 <maxice8> 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 <maxice8> pushed
2019-07-16 10:05:15 <maxice8> :D worse than i thought
2019-07-16 10:05:25 <maxice8> also github bot is easily tricked
2019-07-16 10:05:34 <maxice8> 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 <maxice8> 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 <tmhoang> _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 <maxice8> _ikke_: yes, no clue why that happens
2019-07-16 10:38:07 <_ikke_> Me neither
2019-07-16 14:24:33 <Cogitri> <PureTryOut[m] "`fftw` in main doesn't have a ma"> PureTryOut: I wouldn't mind taking over maintainership if no one steps up
2019-07-16 14:34:14 <ncopa> maxice8: it happens because the github PR script does not check which branch it is
2019-07-16 14:34:26 <ncopa> it only compars commit date and author iirc
2019-07-16 14:34:36 <ncopa> when you cherry-pick those will be identical
2019-07-16 14:42:18 <ddevault> I think I'm going to drop python2 from testing tomorrow
2019-07-16 14:46:44 <ncopa> awesome
2019-07-16 14:46:57 <_ikke_> redo is in community and sadly still requires python2
2019-07-16 14:54:17 <nmeum> how should duplicate issues be handeled in the gitlab bugtracker. should they be closed?
2019-07-16 14:54:30 <ddevault> _ikke_: I'm going to make a list of packages which require special discussion
2019-07-16 14:54:56 <ddevault> 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 <Cogitri> nmeum: Yup, close and refer to the original issue
2019-07-16 15:15:13 <PureTryOut[m]> <Cogitri "PureTryOut: I wouldn't mind taki"> Awesome!
2019-07-16 17:13:23 <maxice8> Yo lxd is failing to build
2019-07-16 17:13:38 <jwh> why?
2019-07-16 17:13:45 <jwh> got ci log?
2019-07-16 17:14:16 <errn0> lulz *buntu
2019-07-16 17:24:49 <maxice8> jwh: see alpine-commits
2019-07-16 17:25:00 <jwh> I'm not subbed
2019-07-16 17:25:14 <jwh> whats going on with the lists, are they still archived somewhere?
2019-07-16 17:37:02 <kaniini> _ikke_: she
2019-07-16 19:40:22 <maxice8> curious
2019-07-16 19:40:26 <maxice8> how do you people backport stuff between branches ?
2019-07-16 19:41:59 <jwh> softly
2019-07-16 19:47:51 <jwh> maxice8: is the lxd issue to do with raft?
2019-07-16 19:48:01 <jwh> if so, yeah, I think they broke it
2019-07-16 19:49:00 <maxice8> 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 <maxice8> 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 <jwh> o
2019-07-16 19:49:27 <jwh> lol
2019-07-16 19:49:50 <maxice8> oops, pr9491 and pr9492
2019-07-16 19:51:58 <jwh> just kicked off a build, no checksum mismatch
2019-07-16 19:52:01 <jwh> fixed already?
2019-07-16 19:52:16 <maxice8> jwh: yes, it was fixed
2019-07-16 19:52:27 <jwh> ah cool ok
2019-07-16 20:47:22 <PureTryOut[m]> maxice8: thank you for merging all my patches so quickly, it's a joy to work like this
2019-07-16 20:47:36 <maxice8> welcome
2019-07-16 20:48:45 <errn0> 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 <maxice8> _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 <maxice8> Alright
2019-07-16 22:57:22 <maxice8> _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 <spatulaslap> hey can someone help me with my apkbuild
2019-07-17 00:18:30 <spatulaslap> http://sprunge.us/Du4E2X
2019-07-17 00:19:15 <spatulaslap> 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 <spatulaslap> and all of the git repos it checks out are -r for my user so abuild clean fails
2019-07-17 00:40:35 <tcely> pr8550 should be a quick merge
2019-07-17 00:42:47 <tcely> spatulaslap: making a draft pull request on GitHub is a good way to get help
2019-07-17 00:44:37 <tcely> 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 <maxice8> 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 <Cogitri> I think just `closes #issuenum` or `fixes` should work
2019-07-17 08:18:24 <ncopa> we have done "fixes #issuenum" in the past, and i would like that to continue work
2019-07-17 08:18:31 <ncopa> and i think it does work
2019-07-17 08:18:33 <maxice8> It does
2019-07-17 08:18:39 <maxice8> thanks
2019-07-17 08:39:27 <ncopa> 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 <ncopa> for example: https://gitlab.alpinelinux.org/alpine/aports/issues/10662
2019-07-17 08:39:39 <ncopa> i added the "Affected branches"
2019-07-17 08:40:32 <ncopa> 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 <ncopa> i also wonder if we should add tags for each branch
2019-07-17 08:41:29 <ncopa> and we should start move away from the tags that comes from redmine, "New" "Resolved" etc
2019-07-17 08:41:35 <Cogitri> <ncopa "I wonder if we can use tasklists"> I guess we could do that like we do with GH right now?
2019-07-17 08:42:11 <ncopa> how do we do with GH?
2019-07-17 08:42:31 <ncopa> the idea is to avoid copy the same issue multiple times
2019-07-17 08:42:47 <nmeum> ncopa: branch tags sound like a good idea, also +1 on moving away from the redmine labels
2019-07-17 08:44:30 <Cogitri> Ncopa: https://github.com/alpinelinux/aports/projects/1
2019-07-17 08:44:57 <Cogitri> We'd just need a project for branches other than edge then
2019-07-17 08:50:17 <ncopa> would be nice with labels similar to the GH ones
2019-07-17 08:50:33 <ncopa> not sure how has bee working on those
2019-07-17 08:50:38 <Cogitri> Yup
2019-07-17 08:51:13 <ncopa> *who has been working on those
2019-07-17 08:51:36 <maxice8> tcely i think
2019-07-17 08:52:11 <ncopa> there is a "2 taks of 2 completed" in this #10662
2019-07-17 08:55:38 <ncopa> #10662
2019-07-17 08:56:22 <ncopa> #10662
2019-07-17 09:14:02 <ncopa> mranweil: hi! can you please join #alpine-infra so we can talk about the power9 machine?
2019-07-17 09:26:43 <tcely> 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 <tcely> Has anyone gotten GPG keys upload to work in GitLab?
2019-07-17 09:48:46 <clandmeter> i did
2019-07-17 09:48:52 <clandmeter> i mean its uploaded
2019-07-17 09:48:53 <tcely> It says my block is invalid, which is nonsense.
2019-07-17 09:49:26 <clandmeter> i didnt check if it actually works
2019-07-17 09:49:37 <Cogitri> Did you use the same command GL tells you to execute?
2019-07-17 09:49:39 <Cogitri> Pretty sure it worked for me, let me check
2019-07-17 09:52:26 <tcely> 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 <Cogitri> Just added a key, works just fine with `gpg --armor --export <key>`
2019-07-17 09:54:35 <tcely> Oh, I think it wants a single block. Sigh. That error message is completely unhelpful.
2019-07-17 09:57:16 <clandmeter> 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 <tcely> clandmeter: how do I verify an email that doesn't accept mail?
2019-07-17 10:11:12 <tcely> All I care about is nappi
2019-07-17 10:11:31 <tcely> All I care about is mapping commits
2019-07-17 10:12:08 <tcely> tcely@users.noreply.github.com
2019-07-17 10:14:51 <tcely> ncopa: how does not always hang? while(1) must have some break correct?
2019-07-17 10:15:36 <tcely> ^ for vtgen patch you just pushed
2019-07-17 10:16:23 <Cogitri> <tcely "tcely@users.noreply.github.com"> Use the gitlab provided no reply email for that
2019-07-17 10:17:04 <tcely> Cogitri: hard to rewrite git history for that now
2019-07-17 10:17:45 <Cogitri> Yup, works for following commits tho
2019-07-17 10:18:29 <tcely> Not for any definition of works that I'll accept
2019-07-17 10:20:12 <tcely> Split commit history / signatures, rewrite repos, toggle verified in db. I'll take the last option thanks.
2019-07-17 10:20:35 <ncopa> tcely: it runs as: ./vtgen | dd ... | ./vt
2019-07-17 10:21:03 <tcely> So is dead by broken pipe?
2019-07-17 10:21:14 <ncopa> it should die by broken pipe
2019-07-17 10:21:17 <ncopa> but it does not
2019-07-17 10:21:24 <ncopa> it continue to run forever
2019-07-17 10:22:01 <ncopa> dont know why
2019-07-17 10:22:09 <PureTryOut[m]> 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 <Cogitri> PureTryOut: I think I enabled libhandy everywhere already :)
2019-07-17 10:23:27 <PureTryOut[m]> GNOME settings definitely not
2019-07-17 10:23:31 <tcely> I wonder if bs=128 shows the same behavior
2019-07-17 10:23:34 <Cogitri> At least that I know of
2019-07-17 10:23:39 <Cogitri> <PureTryOut[m] "GNOME settings definitely not"> Eh? Pretty sure we do
2019-07-17 10:23:55 <PureTryOut[m]> Well in that case it doesn't work lol
2019-07-17 10:23:56 <Cogitri> I don't think you can build it without it
2019-07-17 10:24:10 <Cogitri> 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 <PureTryOut[m]> 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 <PureTryOut[m]> s/scale/adapt
2019-07-17 10:24:34 <alpine-meetbot> 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 <Cogitri> https://github.com/alpinelinux/aports/blob/master/testing/gnome-control-center/APKBUILD
2019-07-17 10:25:14 <Cogitri> We enable libhandy
2019-07-17 10:25:25 <PureTryOut[m]> Huh ok
2019-07-17 10:25:25 <Cogitri> Maybe it doesn't recognize that it's on a phone?
2019-07-17 10:28:42 <PureTryOut[m]> It shouldn't matter, it should adapt depending on the available screen space...
2019-07-17 10:28:53 <Cogitri> shrug No clue, sorry
2019-07-17 10:29:03 <PureTryOut[m]> Yeah we'll look into it
2019-07-17 10:29:09 <Cogitri> Can read into it, but am on holidays rn so don't expect a too fast answer
2019-07-17 10:29:14 <PureTryOut[m]> It's not a problem for Alpine Linux 😛
2019-07-17 10:29:53 <Cogitri> Well, I like my GNOME stuff to work :P
2019-07-17 10:31:09 <PureTryOut[m]> True that
2019-07-17 10:31:14 <PureTryOut[m]> We're not in a hurry though
2019-07-17 10:32:28 <Cogitri> Good 👍
2019-07-17 10:33:38 <nmeum> 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 <ncopa> nmeum: ok
2019-07-17 10:42:10 <ncopa> nmeum: i merged it. thanks
2019-07-17 10:42:36 <nmeum> great, I will merge the firefox-esr upgrade with some minor changes then
2019-07-17 10:42:38 <nmeum> thanks
2019-07-17 10:49:03 <nmeum> build fine locally and seems to work, just pushed it
2019-07-17 10:49:38 <ncopa> thanks!
2019-07-17 11:33:25 <ncopa> nmeum: i think we can enable firefox-esr for armv7 and armhf now
2019-07-17 11:33:28 <ncopa> we have cargo for those
2019-07-17 11:33:33 <ncopa> rust
2019-07-17 11:37:18 <nmeum> right, rust was the only reason why it wasn't enabled on those arches (iirc)
2019-07-17 11:38:19 <nmeum> I don't have any arm hardware to test this though
2019-07-17 11:43:24 <Cogitri> No
2019-07-17 11:43:29 <Cogitri> Unless something had changed during my holidays
2019-07-17 11:43:43 <Cogitri> We still don't have our triplets compiled in
2019-07-17 11:47:00 <ncopa> .../src/cbindgen-0.9.0/target/release/deps/libtoml-ab7b0edcee353c43.rlib` (signal: 4, SIGILL: illegal instruction)
2019-07-17 11:47:10 <ncopa> when trying to build cbindgen
2019-07-17 12:06:56 <Cogitri> On what arch?
2019-07-17 12:07:24 <Cogitri> As noted in the commit msg for Rust on other arches it's not functional on these
2019-07-17 12:20:01 <tcely> Please merge pr6939
2019-07-17 14:10:09 <ncopa> tcely: i dont like it
2019-07-17 14:10:32 <ncopa> its not reproducible
2019-07-17 14:12:15 <ncopa> 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 <ncopa> also, it does not solve the problem with us not noticing that upstream has a new version
2019-07-17 14:16:43 <ncopa> actually, it would be detected
2019-07-17 14:17:08 <ncopa> but we'd not been able to rebuild it later
2019-07-17 14:56:17 <ddevault> while I'm removing python2 support from packages
2019-07-17 14:56:26 <ddevault> I'm also normalizing them per the guidelines here: https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-07-17 14:56:32 <ddevault> should I also bump them to the latest upstream version? so far I have been
2019-07-17 14:56:40 <ddevault> but it occurs to me that brings extra risk
2019-07-17 15:01:34 <PureTryOut[m]> 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 <ddevault> +1
2019-07-17 15:02:35 <ddevault> though I bet the emoji package can be retooled to not use it
2019-07-17 15:04:14 <PureTryOut[m]> No it can not
2019-07-17 15:04:20 <PureTryOut[m]> Actually, someone PR'ed Python 3 support literally yesterday, wth
2019-07-17 15:04:52 <PureTryOut[m]> 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<date>`
2019-07-17 15:09:29 <_ikke_> "it cannot be done", "oh someone just did" :D
2019-07-17 15:10:23 <PureTryOut[m]> 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 <tcely> 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 <nmeum> 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 <nmeum> 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 <nmeum> 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 <clandmeter> _ikke_, can you help?
2019-07-17 17:34:58 <clandmeter> nmeum: can find it on mobile
2019-07-17 17:35:13 <danieli> clandmeter: seems like he isn't here
2019-07-17 17:35:21 <nmeum> it's low priority anyhow ;)
2019-07-17 17:37:21 <clandmeter> Yes that's new to me
2019-07-17 17:37:29 <clandmeter> He is back
2019-07-17 17:37:48 <nmeum> great timing
2019-07-17 17:37:50 <_ikke_> my vps crashed
2019-07-17 17:37:59 <nmeum> _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 <clandmeter> _ikke_, can you make nmeum member of aports
2019-07-17 17:38:22 <_ikke_> sure
2019-07-17 17:38:27 <nmeum> thanks
2019-07-17 17:38:37 <_ikke_> as owner?
2019-07-17 17:38:47 <clandmeter> Reporter please
2019-07-17 17:38:53 <_ikke_> ok
2019-07-17 17:38:59 <clandmeter> 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 <clandmeter> Gitlab is terrible ok mobile
2019-07-17 17:39:30 <clandmeter> 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 <nmeum> 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 <nmeum> ah
2019-07-17 17:40:30 <nmeum> could you do it for me then?
2019-07-17 17:40:40 <_ikke_> yes
2019-07-17 17:40:51 <nmeum> (just going through old bugs currently and noticed that one)
2019-07-17 17:40:54 <_ikke_> Done
2019-07-17 17:40:58 <nmeum> thanks
2019-07-17 18:58:21 <ddevault> https://lists.alpinelinux.org/~alpine/aports/%3C20190717185749.4463-1-sir%40cmpwn.com%3E
2019-07-17 18:58:24 <ddevault> 40 packages down, 243 to go...
2019-07-17 18:58:55 <ddevault> back of the napkin estimate suggest 48ish hours of total work to remove Python 2 from Alpine
2019-07-17 19:22:22 <PureTryOut[m]> Awesome work!
2019-07-17 19:40:55 <PureTryOut[m]> Could someone review/merge https://github.com/alpinelinux/aports/pull/9319?
2019-07-17 19:41:12 <PureTryOut[m]> It's a re-open of a PR which got closed wrongly
2019-07-18 00:51:29 <ddevault> call for aid on python 2 deprecation:
2019-07-18 00:51:31 <ddevault> https://lists.alpinelinux.org/~alpine/devel/%3CBVLYYY50OMSF.91O7O5WI1KE7%40homura%3E
2019-07-18 01:09:15 <Cogitri> 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 <ddevault> thanks Cogitri, much appreciate the help
2019-07-18 01:09:46 <ddevault> ping me when you want a package range assigned to you
2019-07-18 01:10:13 <maxice8> ddevault: throw one for me, i'm tired of trying to get pulseaudio pass through bubblewrap
2019-07-18 01:10:26 <ddevault> maxice8: how much time can you spare?
2019-07-18 01:10:44 <ddevault> I assume an average of 5 minutes per package and allocate accordingly
2019-07-18 01:10:50 <maxice8> no clue, start small, i can ask for more if i finish them
2019-07-18 01:11:03 <ddevault> okay
2019-07-18 01:11:18 <ddevault> can you start with py-flake8-* (just from testing?)
2019-07-18 01:11:29 <ddevault> do you have the email with the instructions/checklist?
2019-07-18 01:11:46 <maxice8> highly preferable to start with stuff from testing and community since i can push to those
2019-07-18 01:11:51 <maxice8> ddevault: yes i have it here
2019-07-18 01:11:59 <ddevault> coolio
2019-07-18 01:12:06 <ddevault> I plan on doing all of testing first
2019-07-18 01:12:13 <ddevault> then taking a break and waiting for complaints to roll in before moving on to community
2019-07-18 01:13:42 <Cogitri> Heh, maybe you're done before I get to it after all :P
2019-07-18 01:14:13 <ddevault> fat chance
2019-07-18 01:14:29 <ddevault> testing alone will require roughly 20 man-hours of work
2019-07-18 01:27:24 <iggy> ddevault: https://github.com/alpinelinux/aports/pull/8878 that's to move ceph to python3
2019-07-18 01:28:01 <ddevault> 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 <maxice8> ETA is whenever someone feels like moving it and it passes basic QA
2019-07-18 03:42:24 <maxice8> 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 <maxice8> _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 <Cogitri> _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 <ncopa> I just made gitlab label "security" red
2019-07-18 07:44:55 <_ikke_> +1
2019-07-18 08:10:37 <Cogitri> 👍
2019-07-18 08:24:39 <nmeum> 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 <nmeum> 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 <ncopa> nmeum: i dont remember, but i would guess it was due to uclibc
2019-07-18 09:01:04 <ncopa> i think we can remove that
2019-07-18 09:02:01 <ncopa> i would probably have added a comment if it was important reason
2019-07-18 09:12:28 <nmeum> ncopa: great, will remove it then
2019-07-18 14:56:40 <manj-gnome> hi
2019-07-18 14:58:29 <manj-gnome> (ucloud-file-scan) localhost:~/ucloud-file-scan# qemu-system-x86_64 rbd:uservms/d412abbdcf7f4d9aa54c8b8f09fbd3
2019-07-18 14:58:29 <manj-gnome> qemu-system-x86_64: rbd:uservms/d412abbdcf7f4d9aa54c8b8f09fbd3: Unknown protocol 'rbd'
2019-07-18 14:58:50 <manj-gnome> Which package should I install to make rbd work with qemu?
2019-07-18 15:30:55 <tmhoang> manj-gnome : rbd like rbd in ceph ?
2019-07-18 15:37:50 <tmhoang> manj-gnome : short answer : qemu from Alpine does not support rbd for ceph block device
2019-07-18 15:40:04 <tmhoang> 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 <clandmeter> and adhere 80 chars please
2019-07-18 17:28:14 <clandmeter> PureTryOut[m]:
2019-07-18 17:41:11 <tmhoang> that's a long line
2019-07-18 18:16:13 <PureTryOut[m]> ikke: I have sent a patch to remove those arches already
2019-07-18 18:16:14 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <ddevault> 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 <ddevault> 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 <ddevault> 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 <ddevault> ah, go ahead
2019-07-18 18:48:11 <ddevault> 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 <ddevault> 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 <ddevault> testing
2019-07-18 18:51:12 <_ikke_> If it works, it's good to go
2019-07-18 18:51:32 <ddevault> I still get that warning
2019-07-18 18:51:39 <ddevault> 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 <ddevault> 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 <ddevault> v2 sent
2019-07-18 18:53:29 <_ikke_> ok
2019-07-18 18:55:19 <_ikke_> pushed
2019-07-18 18:55:27 <ddevault> 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 <ddevault> cheers
2019-07-18 19:52:26 <iggy> 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 <tmhoang> iggy: what changes, on top of your mind ?
2019-07-18 22:10:21 <iggy> tmhoang: python3, breaking up some of the packages, making sure ceph-manager actually works, etc
2019-07-18 22:10:35 <iggy> some of which is already here: https://github.com/alpinelinux/aports/pull/7894
2019-07-18 22:11:23 <tmhoang> nice fancy
2019-07-18 22:11:36 <tmhoang> will have a closer look
2019-07-18 22:13:51 <tmhoang> iirc mgr dasdboard front end still requires  py2
2019-07-18 22:32:50 <iggy> 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 <trixpan> hi there!
2019-07-18 22:42:19 <trixpan> 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 <trixpan> is that supposed to be normal?
2019-07-18 22:42:40 <trixpan> step by step was basically:
2019-07-18 22:44:19 <trixpan> 1. Built a chroot with minimal fs
2019-07-18 22:44:38 <trixpan> 2. apk add alpine-sdk
2019-07-18 22:44:50 <trixpan> 3. git clone aports
2019-07-18 22:45:09 <trixpan> 4. ./scripts/bootstrap.sh armv7
2019-07-18 22:46:42 <iggy> 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 <trixpan> no. build host is x86_64
2019-07-18 22:47:58 <trixpan> so I used alpine-minirootfs-3.10.1-x86_64.tar.gz
2019-07-18 22:49:28 <trixpan> the error atm is
2019-07-18 22:50:00 <trixpan> 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 <trixpan> (in mkinitfs)
2019-07-18 22:52:09 <trixpan> 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 <trixpan> 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 <clandmeter> morning
2019-07-19 07:06:17 <Cogitri> Morning clandmeter
2019-07-19 07:07:49 <clandmeter> 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 <clandmeter> i think i send a patch previously
2019-07-19 07:09:42 <clandmeter> it will allow us to have certificate support without having to install ca-certificates.
2019-07-19 07:13:41 <ncopa> morning
2019-07-19 07:14:02 <ncopa> yeah, i think that needs to be fixed
2019-07-19 07:14:47 <clandmeter> 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 <clandmeter> s/remote/remove
2019-07-19 07:14:57 <alpine-meetbot> 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 <ncopa> need to think how to handle it
2019-07-19 07:16:06 <ncopa> i also think there was some issue with users not being able to add their own certs
2019-07-19 07:16:27 <clandmeter> ive seen issues like that.
2019-07-19 07:16:55 <clandmeter> but i never used my own certs so i dont know.
2019-07-19 07:17:29 <clandmeter> docker users will benefit from the symlink
2019-07-19 07:18:23 <ncopa> im not convinced that a symlink is the proper way to go
2019-07-19 07:18:59 <clandmeter> educate me
2019-07-19 07:19:50 <ncopa> iirc, the cert.pem and ca-certificates.crt are generated differently?
2019-07-19 07:19:56 <ncopa> one is cat *.crt
2019-07-19 07:20:09 <ncopa> the other is built using a small C app
2019-07-19 07:20:22 <ncopa> but the content should be the same
2019-07-19 07:20:39 <clandmeter> i think the logic of the c app is the other symlinks?
2019-07-19 07:20:41 <clandmeter> not sure though
2019-07-19 07:21:04 <ncopa> the C app generated file is generated via trigger
2019-07-19 07:21:15 <clandmeter> its the same i think
2019-07-19 07:21:19 <clandmeter> both catted
2019-07-19 07:21:26 <ncopa> ok
2019-07-19 07:21:50 <clandmeter> but it extract the serial and creates a symlink? or whatever the number is.
2019-07-19 07:22:11 <ncopa> why is there a difference in the name? cert.pem vs ca-certificates.crt?
2019-07-19 07:22:26 <clandmeter> because its what we had before
2019-07-19 07:22:32 <clandmeter> from libressl
2019-07-19 07:22:38 <ncopa> so its backwards compat thing?
2019-07-19 07:22:40 <clandmeter> i guess a freebsd thingy
2019-07-19 07:23:07 <clandmeter> yes and i had to give it a name.
2019-07-19 07:23:18 <ncopa> ok
2019-07-19 07:23:34 <ncopa> they are built from same package?
2019-07-19 07:23:45 <clandmeter> same apkbuild yes
2019-07-19 07:24:17 <clandmeter> you could also generate it similar like we do now with ca-certificates.crt
2019-07-19 07:24:29 <ncopa> yes, i think we should do that
2019-07-19 07:25:16 <ncopa> 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 <ncopa> clandmeter: do we have an issue for it in bugtracker?
2019-07-19 07:25:51 <clandmeter> dunno
2019-07-19 07:26:11 <ncopa> 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 <ncopa> and i'll have a look at it later
2019-07-19 07:28:23 <clandmeter> heh gitlab even searches in git repo
2019-07-19 15:50:29 <tmhoang> 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 <tmhoang> 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 <tmhoang> _ikke_: I'm checking ocaml rdeps, opam breaks with 4.08
2019-07-19 17:12:58 <tmhoang> it would be nice if contributor takes a look at rdeps when upgrading
2019-07-19 17:15:23 <tmhoang> also ocamlbuild, and basically every community/ocaml* packages
2019-07-19 17:15:28 <tmhoang> ...
2019-07-19 17:16:05 <tmhoang> 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 <tcely> 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 <tcely> Can pr8932 get merged before I get around to 9.14.4?
2019-07-20 08:38:30 <trixpan> 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 <Cogitri> GitHub PR usually is the way to go
2019-07-20 08:39:07 <Cogitri> Emails are accepted too though
2019-07-20 08:39:27 <trixpan> Should I submit contributions to the project wiki then?
2019-07-20 08:39:44 <trixpan> (as add this to the how to contribute wiki page)
2019-07-20 09:22:10 <clandmeter> trixpan: are you working on documentation?
2019-07-20 09:23:37 <trixpan> I will be happy to
2019-07-20 09:24:03 <trixpan> 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 <maxice8> 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 <maxice8> _ikke_: That i know, i closed a few hundred Issues on gitlab
2019-07-20 14:58:31 <maxice8> 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 <maxice8> ddevault: ping, any update on the python2 package assignment ?
2019-07-20 15:32:22 <ddevault> didn't I assign you some?
2019-07-20 15:32:29 <ddevault> py-flake8-* according to my notes
2019-07-20 15:32:31 <maxice8> Not as far as i am aware
2019-07-20 15:32:33 <maxice8> ah
2019-07-20 19:38:29 <maxice8> ddevault: i done all flake8 stuff except py-flake8 itself
2019-07-20 19:39:56 <ddevault> thanks maxice8, I'll take a look when I can
2019-07-20 19:39:59 <ddevault> (moving this weekend)
2019-07-20 19:40:24 <maxice8> 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 <ddevault> mail would be great: sir@cmpwn.com
2019-07-20 19:41:12 <ddevault> thanks for your help and hard work
2019-07-20 19:45:05 <maxice8> 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 <ddevault> maxice8: do you want another set of packages?
2019-07-20 19:47:43 <maxice8> Sure
2019-07-20 19:47:52 <ddevault> how about the remainder of py3-django-*
2019-07-20 19:48:11 <maxice8> hmm, there is stuff in main/
2019-07-20 19:48:18 <ddevault> just testing
2019-07-20 19:48:30 <maxice8> alright then
2019-07-20 19:48:43 <ddevault> many thanks!
2019-07-20 20:02:03 <tcely> maxice8: pr9398
2019-07-20 20:06:51 <maxice8> pkgdesc for py-django-js-asset is "No description provided"
2019-07-20 20:28:17 <ddevault> maxice8: since you're working pretty fast do you want a larger group to look at?
2019-07-20 20:28:50 <maxice8> Sure
2019-07-20 20:29:08 <ddevault> want to take the remainder of py-f* and py-g*?
2019-07-20 20:29:40 <maxice8> i'll take py-g*
2019-07-20 20:29:45 <ddevault> g* is 3 packages
2019-07-20 20:29:55 <maxice8> i'll take community/ as well
2019-07-20 20:30:02 <ddevault> let's hold on community, if you don't mind
2019-07-20 20:30:16 <maxice8> if you insist
2019-07-20 20:30:31 <ddevault> 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 <ddevault> 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 <maxice8> sure
2019-07-21 06:03:51 <maxice8> 209 PRs, someone needs to look at the main/ stuff
2019-07-21 09:56:49 <trixpan> 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 <trixpan> I had to change a few things before getting it to work
2019-07-21 09:57:24 <trixpan> https://github.com/alpinelinux/aports/pull/9584
2019-07-21 10:00:58 <mepholic> I built an armv7 bootstrap on native hardware
2019-07-21 10:01:05 <mepholic> the problem is getting them to support it
2019-07-21 10:01:06 <mepholic> ¯\_(ツ)_/¯
2019-07-21 10:01:31 <trixpan> 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 <mepholic> maybe it'll get merged
2019-07-21 10:01:42 <mepholic> good luck
2019-07-21 10:02:07 <_ikke_> alpine's main focus is compiling on native hardware
2019-07-21 10:02:35 <trixpan> hmmmm. and why does bootstrap.sh support cross compilation then?
2019-07-21 10:02:47 <trixpan> `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 <trixpan> 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 <trixpan> 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 <trixpan> 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 <trixpan> 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 <trixpan> 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 <trixpan> (so I may be writing bs. :-)  )
2019-07-21 10:07:17 <_ikke_> I'm no expert either :)
2019-07-21 10:12:58 <mepholic> (    : )    )
2019-07-21 11:25:34 <trixpan> seems like https://github.com/alpinelinux/aports/commit/d1ff02d3584bf422c0d55d7e1b4680ed68c84bb3 introduces a regression and mkinitfs cannot build anymore
2019-07-21 11:47:06 <tmhoang> 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 <trixpan> @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 <tmhoang> that might be correct. we might have changed build dependencies order somehow during the course of bootrstrap.sh
2019-07-21 11:49:38 <tmhoang> but I think the idea here is to list the packages that are required
2019-07-21 11:49:39 <trixpan> 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 <tmhoang> so that porter knows what he might need, more than a out-of-the-box script
2019-07-21 11:50:40 <tmhoang> 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 <tmhoang> so feel free to comment out, 1-2 lines , etc
2019-07-21 11:51:05 <trixpan> @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 <trixpan> golang should be possible as well but will require changes to abuild
2019-07-21 11:52:20 <tmhoang> 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 <trixpan> I was under the impression go can compile itself?
2019-07-21 11:52:54 <tmhoang> now you can use Alpine's go to bootstrap your go.
2019-07-21 11:53:06 <tmhoang> which requires you to run your chroot in native ARM, correct ?
2019-07-21 11:53:43 <trixpan> no. I am currently able to bootstrap arm on x86
2019-07-21 11:53:52 <tmhoang> but image you dont have golang binary for your arch :)
2019-07-21 11:53:57 <tmhoang> ok
2019-07-21 11:54:38 <trixpan> 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 <trixpan> the go compiler cross compile out of the box
2019-07-21 11:55:02 <tmhoang> 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 <trixpan> `GOARCH=arm go build -v ` should result on a cross compiled binary
2019-07-21 11:55:43 <trixpan> the wonders of golang. :-)
2019-07-21 11:56:25 <tmhoang> 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 <trixpan> warning: implicit declaration of function ‘makedev’
2019-07-21 11:58:05 <trixpan> and then fail
2019-07-21 11:58:22 <trixpan> bear with me and I will submit the PR to mkinitfs
2019-07-21 11:58:29 <trixpan> just trying to confirm that is the case
2019-07-21 12:00:29 <trixpan> 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 <tmhoang> so just include sys/sysmacros.h in mkinitfs/nlplug-findfs.c ?
2019-07-21 12:01:15 <trixpan> I believe so.
2019-07-21 12:01:27 <trixpan> but let me confirm first. ;-)
2019-07-21 12:01:37 <tmhoang> you can use docker import or something iirc
2019-07-21 12:02:48 <trixpan> confirmed. musl upgrade caused the regression
2019-07-21 12:03:01 <trixpan> diff
2019-07-21 12:03:02 <trixpan> -pkgver=1.1.23+pkgver=1.1.22
2019-07-21 12:03:12 <trixpan> -sha512sums="a2278de9903852b08352d3e734a39d4616caa602496997ba843e8fea0e1c481761776745faf04536a149d1c4af416b68df681b6fbc9ae2de8794e18c2e853b09  musl-1.1.23.tar.gz+sha512sums="08a40d722672504427238e71c9e52a723c6a14735abe9581d6d4bb3f86662d5d51a3f32a6aed6420c1f9680e22a3a554a9b87ae342635be971e2db49cc9fdb87  musl-1.1.22.tar.gz
2019-07-21 12:03:32 <tmhoang> wonder what changed
2019-07-21 12:04:55 <trixpan> 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 <trixpan> @tmhoang seems to align with issue?
2019-07-21 12:06:10 <trixpan> here's the issue:
2019-07-21 12:06:16 <trixpan> Uploaded file: https://uploads.kiwiirc.com/files/383198163620ca3fc7b33e53b2deaa95/pasted.txt
2019-07-21 12:12:04 <tmhoang> I don't know, maybe fabled could help
2019-07-21 12:18:28 <tmhoang> trixpan : http://git.musl-libc.org/cgit/musl/commit/?id=a31a30a0076c284133c0f4dfa32b8b37883ac930
2019-07-21 12:20:14 <trixpan> yep. Same thing I mentioned above crom WHATSNEW
2019-07-21 12:20:26 <trixpan> just confirmed the issue can be fixed importing sysmacros.h
2019-07-21 12:20:29 <trixpan> submitting the PR
2019-07-21 12:25:16 <trixpan> @tmhoang https://github.com/alpinelinux/mkinitfs/pull/55
2019-07-21 18:07:01 <maxice8> Can someone look at PRs for main/ ?
2019-07-21 18:26:37 <danieli> I can test a few of them on x86_64 and aarch64 in a sec
2019-07-21 18:26:58 <danieli> see if it builds, works properly, and 'looks' right
2019-07-21 18:27:11 <danieli> I can't push anything though :P
2019-07-21 18:36:38 <maxice8> That would be nice
2019-07-21 19:12:02 <danieli> 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 <z3ntu> 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 <maxice8> Should it be pc:libglog or pc:glog ?
2019-07-21 20:50:38 <maxice8> z3ntu: can you try pr9603
2019-07-22 05:46:53 <maxice8> lots of PRs for main/, can anyone take a look ?
2019-07-22 06:00:24 <ncopa> morning
2019-07-22 06:00:30 <ncopa> i'll have a look at it today
2019-07-22 06:00:36 <maxice8> morning
2019-07-22 06:00:39 <maxice8> :D thank you i have a few that are CVE fixes
2019-07-22 06:57:51 <z3ntu> 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 <z3ntu> 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 <tmhoang> _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 <ncopa> 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 <maxice8> 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 <ncopa> im on it. have a good sleep!
2019-07-22 08:39:29 <clandmeter> ncopa: did you look into ca-certs?
2019-07-22 08:57:07 <ncopa> clandmeter: not yet
2019-07-22 08:57:22 <ncopa> the plan is to merge some of the PRs for main
2019-07-22 08:58:12 <clandmeter> so you don't manage your issues ala fifo? ;-)
2019-07-22 10:21:31 <ncopa> 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 <ncopa> no
2019-07-22 10:26:47 <_ikke_> oh, it's builddeps
2019-07-22 10:27:05 <ncopa> 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 <ncopa> 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 <ncopa> yup
2019-07-22 10:52:11 <ncopa> 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 <ncopa> neither did i til i saw maxice8's PR
2019-07-22 11:10:10 <ncopa> 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 <maxice8> ncopa: oops, sorry
2019-07-22 16:31:08 <Cogitri> Sooo, almost home now waiting for connection flight, what did I miss during my holidays? :P
2019-07-22 16:31:36 <maxice8> People are working on moving to gitlab even harder
2019-07-22 16:31:59 <maxice8> ddevault is gathering volunteers to exterminate python2
2019-07-22 16:33:48 <maxice8> ncopa: can i take on the libosinfo thingy ?
2019-07-22 17:17:27 <nmeum> ncopa: why didn't you set the shell of the postgres account to /sbin/nologin in 770d8ce7c6c556d952884ad436dd82b17ceb1a9a
2019-07-22 17:23:56 <nmeum> https://github.com/alpinelinux/aports/pull/9627
2019-07-22 17:24:48 <ncopa> maxice8: np. it happens
2019-07-22 17:25:20 <ncopa> 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 <ncopa> https://wiki.postgresql.org/wiki/First_steps
2019-07-22 17:26:07 <danieli> tell that to alll the documentation that exists
2019-07-22 17:26:12 <danieli> # su - postgres
2019-07-22 17:26:12 <_ikke_> heh
2019-07-22 17:26:13 <danieli> $ psql
2019-07-22 17:28:08 <nmeum> ncopa: good to know, will close the PR and the issue then
2019-07-22 17:28:13 <ncopa> so its possible to work around it with "su -s /bin/sh -c ..."?
2019-07-22 17:28:25 <ncopa> or using doas or sudo?
2019-07-22 17:28:40 <danieli> 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 <nmeum> sudo -u postgres -s should work
2019-07-22 17:28:50 <danieli> try this: $ sudo su -s /bin/sh - nobody
2019-07-22 17:28:58 <ncopa> hm
2019-07-22 17:29:28 <ncopa> then i think it may be better to disable that user as well
2019-07-22 17:29:48 <danieli> 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 <ncopa> 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 <ncopa> the question is how many people who while complain, how much will break
2019-07-22 17:30:51 <danieli> 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 <ncopa> 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 <danieli> ^
2019-07-22 17:31:22 <danieli> could tell them to nag at $whoever to update their docs, i guess
2019-07-22 17:31:29 <nmeum> we could print a message informing users of that change from a post-upgrade script
2019-07-22 17:31:36 <danieli> great idea
2019-07-22 17:31:51 <_ikke_> That doesn't help people just installing postgres
2019-07-22 17:32:04 <danieli> true
2019-07-22 17:32:33 <nmeum> right, people upgrading postgres also need to modify their /etc/passwd manually anyhow
2019-07-22 17:32:40 <ncopa> yeah
2019-07-22 17:32:46 <ncopa> its for new installs
2019-07-22 17:32:53 <ncopa> 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 <nmeum> 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 <danieli> 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 <danieli> oh man, i've probably had thousands of reverse shells as 'www-data', 'mysql' and similar
2019-07-22 17:35:44 <danieli> in total, that is
2019-07-22 17:36:10 <ncopa> 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 <ncopa> i guess it depends
2019-07-22 17:37:54 <ncopa> i guess there may be cases where it will stop or slow down an attacker
2019-07-22 17:38:02 <ncopa> 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 <ncopa> 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 <ncopa> 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 <ncopa> but i guess it will not be much of it
2019-07-22 17:39:50 <ncopa> and may be worth it
2019-07-22 17:41:15 <nmeum> 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 <ncopa> yeah
2019-07-22 17:41:56 <ncopa> it may be nice to alos check what other distro do. it seem like debian has it disabled
2019-07-22 17:42:06 <nmeum> archlinux has enabled a shell for postgres
2019-07-22 17:42:23 <nmeum> https://git.archlinux.org/svntogit/packages.git/tree/trunk/postgresql.sysusers?h=packages/postgresql
2019-07-22 17:42:48 <Cogitri> 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 <ncopa> commit message will be for those who tries to "fix" it
2019-07-22 17:43:41 <nmeum> 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 <Cogitri> Fair enough
2019-07-22 17:43:58 <ncopa> su - postgres broke. why did it break? when did it break?
2019-07-22 17:44:17 <ncopa> nmeum: and debian?
2019-07-22 17:47:00 <zmcgrew> 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 <nmeum> 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 <zmcgrew> _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 <ncopa> nmeum: hum... ok
2019-07-22 17:49:24 <ncopa> so there are no other distro that disable the shell?
2019-07-22 17:49:35 <nmeum> haven't found one so far
2019-07-22 17:49:50 <ncopa> 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 <nmeum> yep
2019-07-22 17:50:00 <nmeum> i was about to suggest that
2019-07-22 17:50:09 <nmeum> I think that's a decent compromise
2019-07-22 17:50:26 <ncopa> lets do that. make sure that we keep the uid too
2019-07-22 17:50:39 <nmeum> ok
2019-07-22 17:50:42 <nmeum> gimme a second
2019-07-22 17:53:52 <maxice8> ncopa: ping: libosinfo
2019-07-22 18:00:32 <nmeum> 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 <nmeum> 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 <p4Wv1qn095FW> 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 <p4Wv1qn095FW> here's the APKBUILD http://tpaste.us/pW4x
2019-07-22 18:04:26 <nmeum> argh, should have disabled the postgres testsuite this takes forever ;_;
2019-07-22 18:08:30 <ncopa> maxice8: will do libosinfo later. still working on sdl2 breakage doe t omove to cmake
2019-07-22 18:09:08 <maxice8> ncopa: oh
2019-07-22 18:09:22 <ncopa> p4Wv1qn095FW: i think its some buffer overflow. i think its either sta-smash-protector or the hardened source
2019-07-22 18:09:28 <Cogitri> Pinged PureTryOut about that already?
2019-07-22 18:09:38 <ncopa> i added a comment to the PR
2019-07-22 18:09:54 <ncopa> i know what broken, but my cmake skills are slowing me down
2019-07-22 18:10:07 <ncopa> i just learned that a cmake list is a string separated with ;
2019-07-22 18:10:12 <Cogitri> Okie
2019-07-22 18:10:31 <maxice8> you always learn something new with cmake
2019-07-22 18:10:38 <ncopa> lol
2019-07-22 18:10:40 <ncopa> indeed
2019-07-22 18:10:47 <ncopa> i have a fix though
2019-07-22 18:11:00 <ncopa> i dont think there are many other users that uses both directfb and cmake
2019-07-22 18:11:04 <p4Wv1qn095FW> 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 <ncopa> p4Wv1qn095FW: its fortify source
2019-07-22 18:12:04 <ncopa> i bet it does not happen with -U_FORTIFY_SOURCE
2019-07-22 18:12:13 <p4Wv1qn095FW> let me try
2019-07-22 18:12:37 <ncopa> i said hardened source, but meant fortify source (its been a long day)
2019-07-22 18:13:05 <p4Wv1qn095FW> i got it anyways  :)
2019-07-22 18:13:46 <p4Wv1qn095FW> \o/ without -U_FORTIFY_SOURCE it indeed does work!
2019-07-22 18:13:54 <nmeum> 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 <ncopa> p4Wv1qn095FW: but really, its a bug in the code
2019-07-22 18:14:27 <ncopa> potentially a security bug
2019-07-22 18:14:33 <p4Wv1qn095FW> 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 <zmcgrew> _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 <ncopa> fortify source is enabled by default
2019-07-22 18:15:00 <_ikke_> zmcgrew: No problem
2019-07-22 18:15:16 <ncopa> its an extra check that there is enough allocated space for the memmove operation
2019-07-22 18:15:51 <ncopa> and if its not it will __builtin_trap() instead of letting an attacker exploit it
2019-07-22 18:15:53 <p4Wv1qn095FW> that is strange, because now the code runs as expected, no overflow.
2019-07-22 18:15:58 <p4Wv1qn095FW> i see
2019-07-22 18:16:07 <ncopa> 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 <ncopa> it writes over another buffer
2019-07-22 18:16:36 <ncopa> maybe that other buffer will never be used
2019-07-22 18:17:14 <ncopa> 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 <p4Wv1qn095FW> i will report it
2019-07-22 18:18:20 <p4Wv1qn095FW> one more question, why was this not triggered on my other laptop?
2019-07-22 18:18:53 <p4Wv1qn095FW> although upstream is a bit dead
2019-07-22 18:19:12 <p4Wv1qn095FW> but it is a security library, so relevant
2019-07-22 18:21:20 <nmeum> _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 <nmeum> thanks
2019-07-22 18:22:32 <ncopa> 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 <p4Wv1qn095FW> both are alpine/edge x86_64
2019-07-22 18:23:05 <p4Wv1qn095FW> both run the same test program.
2019-07-22 18:27:13 <ncopa> interesting. is it the same binary?
2019-07-22 18:27:22 <ncopa> build on same machine?
2019-07-22 18:27:30 <ncopa> did you have same cflags, etc
2019-07-22 18:27:53 <p4Wv1qn095FW> unfortunately i have no access to the other laptop atm.
2019-07-22 18:28:11 <ncopa> i guess it worked by "luck"
2019-07-22 18:28:31 <ncopa> or more precise, you were lucky that the other machine found it
2019-07-22 18:28:48 <p4Wv1qn095FW> i'll investigate this once i have access to both laptops again.
2019-07-22 18:29:11 <ncopa> genereate a core dump and a backtrace
2019-07-22 18:32:49 <ncopa> maxice8: is libosinfo blocking you?
2019-07-22 18:33:09 <maxice8> no but i already made PRs for them
2019-07-22 18:34:32 <ncopa> nm... im on it
2019-07-22 18:37:59 <ncopa> maxice8: thanks for the ping
2019-07-22 18:38:20 <maxice8> ncopa: :#
2019-07-22 18:38:25 <maxice8> :D*
2019-07-22 18:45:40 <ncopa> maxice8: thanks alot for helping with the sec issues
2019-07-22 18:46:39 <maxice8> :D glad to help
2019-07-22 19:09:22 <ncopa> tcely: i disabled testing/sequoia-sqv due to it failed to build with updated nettle
2019-07-23 06:55:25 <tcely> This HTML blocking is highly annoying.
2019-07-23 06:58:51 <tcely> 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 <ncopa> as i understand the mailing list does not allow sending html mails?
2019-07-23 07:08:28 <ncopa> do we have an issue in gitlab for it?
2019-07-23 07:08:36 <ncopa> i think we need to fix that somehow
2019-07-23 07:12:02 <Cogitri> Pretty sure ddevault blocked that by design
2019-07-23 07:13:40 <Cogitri> https://man.sr.ht/lists.sr.ht/etiquette.md
2019-07-23 07:13:53 <Cogitri> > HTML emails are rejected by all sr.ht services.
2019-07-23 07:15:06 <tcely> ncopa: I found no related issue
2019-07-23 07:15:38 <tcely> Cogitri: All Android Gmail users are lo
2019-07-23 07:16:01 <tcely> Cogitri: All Android Gmail users are blocked by that without knowing why.
2019-07-23 07:16:04 <tcely> http://k00.fr/e0usualf
2019-07-23 07:16:13 <Cogitri> Hm, can't you use some other email app for GMail which allows setting that?
2019-07-23 07:16:36 <tcely> Depends on your provider
2019-07-23 07:16:57 <clandmeter> we dont want to force our users to do such things.
2019-07-23 07:17:07 <Cogitri> 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 <tcely> I don't have a better option and switching email apps isn't a solution
2019-07-23 07:17:32 <Cogitri> Hm, alright
2019-07-23 07:18:51 <ncopa> there may be various reasons that you cannot change email client or disable html mails
2019-07-23 07:19:42 <ncopa> entrerprise policies
2019-07-23 07:20:11 <tcely> 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 <ncopa> disabilities (screen readers)
2019-07-23 07:21:45 <ncopa> 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 <Cogitri> 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 <ncopa> the point is that there are valid reasons that you cannot use another email client
2019-07-23 07:23:03 <Cogitri> 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 <ncopa> you might not be allowed to install/remove software from the work computer
2019-07-23 07:24:23 <ncopa> im personally no fan of html mails, but our goal is to be inclusive
2019-07-23 07:24:26 <clandmeter> 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 <ncopa> sending patches is one thing
2019-07-23 07:25:37 <ncopa> im sort of ok with blocking html mails to a patches-only mailing list
2019-07-23 07:25:54 <clandmeter> yes i agree on that.
2019-07-23 07:26:06 <ncopa> but to be able to participate in discussion, ask for or provide support
2019-07-23 07:26:13 <ncopa> participate in the community
2019-07-23 07:26:23 <Cogitri> clandmeter: Now that you mention it I think ${WORK}s outgoing emails actually are html, my bad
2019-07-23 07:26:25 <ncopa> i dont think we should discriminate
2019-07-23 07:26:37 <Cogitri> Yup, sounds good to only block it for patches
2019-07-23 07:26:44 <clandmeter> but it will still be difficult to review patches from different systems.
2019-07-23 07:27:11 <ncopa> yes
2019-07-23 07:27:28 <ncopa> we used to have send-email patches only previously, before github existed
2019-07-23 07:27:37 <clandmeter> i think ddevault has some concerns about dkim or related
2019-07-23 07:27:42 <ncopa> and people had problems with it
2019-07-23 07:27:52 <ncopa> not everyone were able to submit patches
2019-07-23 07:28:25 <ncopa> gmail mangles the patches, inserts linebreaks and stuff
2019-07-23 07:28:47 <ncopa> so there was many people who were not able to participate with patches
2019-07-23 07:28:55 <clandmeter> gmail as in just using its smtp server?
2019-07-23 07:28:58 <ncopa> yes
2019-07-23 07:29:09 <clandmeter> wow i didnt know that
2019-07-23 07:29:19 <ncopa> basicly, gmail is useless for sending patches
2019-07-23 07:29:45 <ncopa> i think that is also a part of the reason wy github became popular
2019-07-23 07:30:18 <ncopa> basically, we cannot have emails as the only way to communicate
2019-07-23 07:30:24 <ncopa> and send patches
2019-07-23 07:32:02 <tcely> 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 <ncopa> package request: any gitlab cli (python-gitlab? lab?)
2019-07-23 07:39:58 <clandmeter> npm install git-lab-cli -g
2019-07-23 07:40:00 <clandmeter> ;-)
2019-07-23 07:56:34 <ncopa> ugh...
2019-07-23 08:47:27 <nmeum> 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 <nmeum> ncopa: thanks :)
2019-07-23 09:28:45 <ncopa> thank *you* :)
2019-07-23 09:29:18 <trixpan> ncopa: since you are here
2019-07-23 09:29:21 <trixpan> https://github.com/alpinelinux/mkinitfs/pull/55
2019-07-23 09:29:23 <trixpan> :-)
2019-07-23 09:29:25 <ncopa> hi
2019-07-23 09:29:36 <trixpan> O:3
2019-07-23 09:29:37 <ncopa> ah
2019-07-23 09:30:22 <trixpan> that is related to the impact of upgrading musl to 1.1.23
2019-07-23 09:31:23 <ncopa> tcely: thanks for helping with sequoia-sqv (and sorry for not fixing it myself)
2019-07-23 09:31:47 <ncopa> trixpan: i will have a look at it shortly. need to reboot
2019-07-23 09:40:31 <trixpan> re new release. It currently breaks bootstrap
2019-07-23 09:40:55 <trixpan> 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 <muhaha> is there mod_wsgi for httpd for python3 ?
2019-07-23 09:49:22 <muhaha> Seems that https://pkgs.alpinelinux.org/package/v3.10/main/x86_64/apache2-mod-wsgi is for python2
2019-07-23 09:55:36 <przemoc> 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 <przemoc> confused about them from now on. :)
2019-07-23 10:32:21 <nmeum> przemoc: right, thanks for the clarification :)
2019-07-23 10:40:20 <tcely> ncopa: no problem. I wouldn't expect you to fix it yourself.
2019-07-23 11:08:45 <ncopa> This issue has many mentions :)  https://gitlab.alpinelinux.org/alpine/aports/issues/1
2019-07-23 11:10:01 <clandmeter> 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 <ncopa> 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 <ncopa> got the cli tool "lab" working
2019-07-23 11:43:28 <tcely> can pr9483 get merged?
2019-07-23 11:44:58 <tcely> The pdns-recursor devs may have fixed s390x in the next release.
2019-07-23 11:50:19 <ncopa> tcely: i can push the first commit, but i have doubrs about the other two commits
2019-07-23 11:51:03 <ncopa> tcely: btw... i wonder if you can help us think what labels we want for gitlab
2019-07-23 11:51:28 <ncopa> 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 <tcely> ncopa: please push the first commit
2019-07-23 11:52:01 <ncopa> ok. will do
2019-07-23 11:52:03 <ncopa> thanks
2019-07-23 11:52:28 <MY_R> 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 <MY_R> s/hos/how
2019-07-23 11:52:40 <alpine-meetbot> 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 <ncopa> ddevault: ^^^
2019-07-23 11:53:17 <tcely> 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 <ncopa> tcely: im open to ideas, but i dont have the full overview
2019-07-23 11:54:01 <ncopa> maybe we should take this in #alpine-infra
2019-07-23 11:54:18 <MY_R> ncopa, dont highlight him because he already told me to write to google mail...
2019-07-23 11:54:31 <ncopa> oh :)
2019-07-23 11:54:54 <MY_R> 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 <MY_R> 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 <MY_R> 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 <MY_R> ah ye and forgot to add "+subscribe" to every
2019-07-23 12:02:31 <MY_R> 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 <MY_R>     requested does not exist."
2019-07-23 12:03:02 <MY_R> so gmail at least support "/" but for sure not "~"
2019-07-23 12:03:22 <clandmeter> gmail does not support ~?
2019-07-23 12:03:34 <MY_R> no because I dont get any answer from ML at all
2019-07-23 12:03:56 <MY_R> or should write to them so they will dunno, unlock it for me?
2019-07-23 12:04:21 <MY_R> with "yandex" everything working just fine with ~ etc etc can subscribe even from their webmail
2019-07-23 12:05:33 <MY_R> 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 <ncopa> MY_R: can you please create an issue in our bugtracker?
2019-07-23 12:06:52 <clandmeter> cant you just use the old addresses?
2019-07-23 12:06:56 <ncopa> i want this problem tracked and recorded
2019-07-23 12:07:00 <clandmeter> isnt there a rediect in place?
2019-07-23 12:07:09 <ncopa> should be
2019-07-23 12:07:28 <MY_R> clandmeter, I was subscribed to announce and didnt get any notification with new alpine
2019-07-23 12:08:15 <clandmeter> i also see no information on how to subscribe
2019-07-23 12:08:50 <clandmeter> ah the button
2019-07-23 12:09:11 <MY_R> 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 <clandmeter> but i can send to the list fine with the ~ address via gmail
2019-07-23 12:09:41 <MY_R> clandmeter, and I dont get any answer back when used that button
2019-07-23 12:09:50 <ncopa> maybe its gmail that automatically send html mails?
2019-07-23 12:10:17 <ncopa> clandmeter: where can we file and track bug reports for mailing list?
2019-07-23 12:10:25 <MY_R> tried with phone client and same
2019-07-23 12:10:26 <clandmeter> infra
2019-07-23 12:10:35 <clandmeter> phone wont work
2019-07-23 12:10:40 <clandmeter> it will always use html
2019-07-23 12:10:47 <MY_R> K9 mail client?
2019-07-23 12:10:55 <clandmeter> that i dont know
2019-07-23 12:10:57 <clandmeter> never used it
2019-07-23 12:11:05 <ncopa> here? https://gitlab.alpinelinux.org/alpine/infra/infra
2019-07-23 12:11:25 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/issues
2019-07-23 12:11:27 <MY_R> I set up in options to not use any html but simple text
2019-07-23 12:11:44 <clandmeter> ok and you send an email to the subscriiton address?
2019-07-23 12:11:48 <clandmeter> and what happens?
2019-07-23 12:12:15 <MY_R> what address, that is the point because not sure how it have to look
2019-07-23 12:12:31 <MY_R> ~alpine/announce+subscribe@lists.alpinelinux.org
2019-07-23 12:12:39 <MY_R> that wont work at all, zero answer back
2019-07-23 12:13:00 <clandmeter> ~alpine/announce+subscribe@lists.alpinelinux.org
2019-07-23 12:13:26 <clandmeter> can you send an email to me clandmeter@alpinelinux.org
2019-07-23 12:13:39 <clandmeter> or cc me
2019-07-23 12:13:39 <MY_R> sure, 1 sec
2019-07-23 12:13:44 <clandmeter> when you subscribe
2019-07-23 12:15:26 <clandmeter> ok received
2019-07-23 12:15:28 <clandmeter> should be ok
2019-07-23 12:15:34 <MY_R> isnt html right?
2019-07-23 12:16:33 <clandmeter> its text
2019-07-23 12:16:41 <MY_R> for sure address with "~" is ignored but there is some fall back way but ye, how?
2019-07-23 12:17:19 <clandmeter> im sorry, i see the emails coming in from smtp, but i have no clue about the list
2019-07-23 12:17:24 <clandmeter> please add an issue to the tracker
2019-07-23 12:17:29 <clandmeter> on infra
2019-07-23 12:17:39 <clandmeter> and we can ask ddevault what is going on
2019-07-23 12:18:00 <MY_R> https://man.sr.ht/lists.sr.ht/#posting
2019-07-23 12:18:07 <tcely> Did you already try this?  u.alpine/announce+subscribe@lists.alpinelinux.org
2019-07-23 12:18:29 <MY_R> ye wanted try but already sent too many of familiar, one sec
2019-07-23 12:18:51 <clandmeter> MY_R: i see your emails coming in
2019-07-23 12:18:58 <MY_R> I know :)
2019-07-23 12:18:59 <clandmeter> but i dont see the +subsribe in it
2019-07-23 12:19:14 <MY_R> so maybe + is ignored too
2019-07-23 12:19:44 <clandmeter> can you use the offical address and send me cc?
2019-07-23 12:21:02 <clandmeter> to:~alpine/announce+subscribe@lists.alpinelinux.org and cc:clandmeter@alpinelinux.org
2019-07-23 12:24:15 <MY_R> now done what tcely wrote and fwd to clandmeter, ah moment
2019-07-23 12:26:34 <clandmeter> did you do what i asked you?
2019-07-23 12:26:45 <MY_R> ye one sec, sending
2019-07-23 12:28:12 <MY_R> clandmeter, ye done
2019-07-23 12:29:41 <clandmeter> ok and still nothing right?
2019-07-23 12:30:00 <MY_R> zero
2019-07-23 12:30:09 <clandmeter> please create a report here:" https://gitlab.alpinelinux.org/alpine/infra/infra/issues
2019-07-23 12:30:31 <clandmeter> thanks for your patience
2019-07-23 12:31:04 <tcely> 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 <MY_R> 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 <clandmeter> tcely: there is a subscribe button, it should be the correct address.
2019-07-23 12:32:50 <tcely> clandmeter: the alternative address and the subscribe and posting addresses all appear to differ
2019-07-23 12:33:34 <MY_R> 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 <MY_R> it is obvious that is gmail issue but many people got them working with everything else just fine
2019-07-23 12:41:10 <fcolista> does it happen to me only?
2019-07-23 12:41:11 <fcolista> http://tpaste.us/ro4E
2019-07-23 12:41:35 <fcolista> lxc-create -n test -t alpine -- -r v3.10 --arch x86_64
2019-07-23 12:42:11 <fcolista> host is alpine 3.10.1
2019-07-23 12:46:13 <clandmeter> you have internet connection?
2019-07-23 12:47:25 <fcolista> yes
2019-07-23 12:47:38 <fcolista> I'm connected to this host via internet :)
2019-07-23 12:47:48 <clandmeter> check what the uris are
2019-07-23 12:47:53 <clandmeter> not sure where it pulls it from
2019-07-23 12:48:11 <fcolista> does it use the /etc/apk/repositories ?
2019-07-23 12:48:20 <clandmeter> it fetches the keys
2019-07-23 12:48:24 <clandmeter> from somewhere
2019-07-23 12:48:46 <fcolista> yes
2019-07-23 12:49:00 <fcolista> wondering from where...or at least, where it's written from where get the keys
2019-07-23 12:49:14 <fcolista> it's lxc-create that fetches the key
2019-07-23 12:49:16 <fcolista> but it's binary
2019-07-23 12:49:22 <fcolista> umh
2019-07-23 12:49:25 <clandmeter> http://alpinelinux.org/keys
2019-07-23 12:49:26 <fcolista> I can check the template
2019-07-23 12:49:49 <fcolista> umh..
2019-07-23 12:49:59 <fcolista>  wget http://alpinelinux.org/keys
2019-07-23 12:49:59 <fcolista> Connecting to alpinelinux.org (147.75.101.119:80)
2019-07-23 12:49:59 <fcolista> Connecting to alpinelinux.org (147.75.101.119:443)
2019-07-23 12:50:02 <fcolista> it
2019-07-23 12:50:08 <fcolista> it's stucked
2019-07-23 12:50:12 <fcolista> let me check the fw..
2019-07-23 12:50:32 <jwh> no lxd? :(
2019-07-23 12:50:44 <fcolista> lxd is in testing
2019-07-23 12:50:46 <fcolista> so edge
2019-07-23 12:51:05 <jwh> well you can still use it, don't need to run edge
2019-07-23 12:51:18 <fcolista> I knw
2019-07-23 12:54:53 <fcolista> for some reason, 443 is filtered.
2019-07-23 12:55:42 <ddevault> morning
2019-07-23 12:55:44 <ddevault> what'd I miss?
2019-07-23 12:56:18 <fcolista> ok, fixed
2019-07-23 12:57:14 <Cogitri> ddevault: ncopa & clandmeter are in favour of allowing HTML emails for the mailing lists
2019-07-23 12:58:47 <ddevault> bleh. can we limit that to alpine-user at least?
2019-07-23 12:59:13 <MY_R> 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 <MY_R> oh Hi ddevault :)
2019-07-23 12:59:29 <MY_R> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10635
2019-07-23 12:59:52 <Cogitri> ddevault: I think the point was to allow it everywhere but in the patch ML
2019-07-23 13:00:02 <ddevault> -1 to allowing it in -devel
2019-07-23 13:00:30 <ddevault> MY_R: check your spam folder?
2019-07-23 13:00:53 <ddevault> 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 <Cogitri> ddevault: same.
2019-07-23 13:01:06 <MY_R> ddevault, spam is empty
2019-07-23 13:01:49 <MY_R> ddevault, but I sent many of different constructed emails so which one worked?
2019-07-23 13:02:57 <MY_R> 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 <clandmeter> ddevault: where did the mail to to?
2019-07-23 13:12:37 <clandmeter> confirmation email
2019-07-23 13:13:03 <ddevault> MY_R: all of them
2019-07-23 13:13:21 <ddevault> clandmeter: mynotbe@gmail.com at 2019-07-23 12:28:04,929
2019-07-23 13:17:17 <MY_R> 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 <ddevault> you're subscribed. the issue is the follow-up email which tells you so
2019-07-23 13:19:42 <MY_R> ddevault, ye but this one worked "~alpine/announce+subscribe@lists.alpinelinux.org" or other one without "~" in address?
2019-07-23 13:19:57 <ddevault> you use either that, or u.alpine.announce+subscribe@lists.alpinelinux.org
2019-07-23 13:20:03 <ddevault> both work correctly
2019-07-23 13:20:07 <MY_R> and that what I wanted know!
2019-07-23 13:20:32 <MY_R> u.alpine.announce+subscribe@lists.alpinelinux.org
2019-07-23 13:20:39 <ncopa> i wonder if we should have that on the alpinelinux.org/community page, like we previously did
2019-07-23 13:21:27 <ddevault> it's a red herring
2019-07-23 13:21:33 <ddevault> MY_R uses gmail, ~ would have worked
2019-07-23 13:21:48 <ddevault> I've only ever seen 1 or 2 mail servers in the wild which get pissy with ~
2019-07-23 13:22:12 <MY_R> ye but I tried with "~" week ago and didnt work
2019-07-23 13:22:18 <ddevault> it worked yo
2019-07-23 13:22:28 <MY_R> ah?
2019-07-23 13:22:33 <MY_R> so ok
2019-07-23 13:22:48 <ddevault> 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 <MY_R> thought you showed me date of registration few messages above
2019-07-23 13:23:06 <ddevault> that was the date of your last attempt
2019-07-23 13:24:07 <MY_R> ok, so all fine, just need fix that confirmation but why the hell gmail got problem with it :\
2019-07-23 13:24:20 <ddevault> outgoing mails aren't DKIM signed, and they ought to be
2019-07-23 13:24:27 <ddevault> but I can't fix that, someone who can access the mail server needs to set it up
2019-07-23 13:24:35 <MY_R> I got yandexown domain with DKIM
2019-07-23 13:24:44 <MY_R> and ye worked fine
2019-07-23 13:25:03 <MY_R> so now all is clear :)
2019-07-23 13:25:56 <ddevault> 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 <clandmeter> why do we need to compromise here?
2019-07-23 13:26:48 <ddevault> 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 <ncopa> +1 for having it disabled on aports list
2019-07-23 13:27:13 <ddevault> why not devel as well?
2019-07-23 13:27:15 <clandmeter> i like to be able to answer to mails on my phone
2019-07-23 13:27:21 <ncopa> but devel list
2019-07-23 13:27:22 <clandmeter> without installing another app
2019-07-23 13:27:31 <clandmeter> lists i can live with
2019-07-23 13:27:32 <ddevault> well I'd like a million dollars
2019-07-23 13:27:35 <clandmeter> err patches
2019-07-23 13:27:47 <ddevault> without doing any work for it
2019-07-23 13:27:49 <ddevault> ¯\_(ツ)_/¯
2019-07-23 13:27:51 <ncopa> i dont think we want use html mails as gate keeper
2019-07-23 13:28:08 <ncopa> keeping the people who cannot disable html mails out
2019-07-23 13:28:10 <clandmeter> ddevault: smtp does sign dkim
2019-07-23 13:28:13 <ddevault> I'm willing to help anyone who uses HTML email get set up for plaintext instead
2019-07-23 13:28:16 <ddevault> clandmeter: it does not
2019-07-23 13:28:17 <nmeum> i think people sending mails to patches and devel should be able to configure their mua accordingly
2019-07-23 13:28:22 <clandmeter> ddevault: it does
2019-07-23 13:28:29 <clandmeter> 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 <clandmeter> cause somebody removed the filter
2019-07-23 13:28:35 <_ikke_> ddevault: they just stay away
2019-07-23 13:28:36 <ddevault> clandmeter: you're getting on my nerves man
2019-07-23 13:28:52 <ddevault> _ikke_: I can improve the rejection email to make it easier to parse
2019-07-23 13:28:53 <clandmeter> ddevault: sorry if you dont want to discuss this issue.
2019-07-23 13:28:56 <ncopa> there may be various reasons why a user cannot or dont want disable html mails
2019-07-23 13:29:16 <ncopa> or may not be able to replace email software
2019-07-23 13:29:19 <clandmeter> but you are not giving me any time to explain the issue here.
2019-07-23 13:29:28 <ddevault> 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 <ncopa> for example in enterprise environments
2019-07-23 13:29:47 <clandmeter> _ikke_: you changed something on smtp right?
2019-07-23 13:29:52 <_ikke_> clandmeter: yes
2019-07-23 13:29:53 <clandmeter> to trust lists
2019-07-23 13:29:54 <ddevault> sending HTML email by mistake -> no problem, I can help you fix that
2019-07-23 13:30:02 <ddevault> sending HTML email because you refuse not to -> not welcome in my inbox
2019-07-23 13:30:22 <MY_R> 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 <ddevault> 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 <ncopa> ddevault: so you think we should use it as gate keeper to keep some people out
2019-07-23 13:30:41 <clandmeter> ddevault: cant you just filter them out locally?
2019-07-23 13:30:49 <ddevault> plaintext emails are more secure, the admin shouldn't care
2019-07-23 13:31:01 <ddevault> ncopa: not necessarily
2019-07-23 13:31:06 <ddevault> 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 <ddevault> 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 <clandmeter> 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 <ddevault> _ikke_: I will not miss emails from users who are taught how to correct the problem
2019-07-23 13:31:52 <ddevault> okay, this isn't working
2019-07-23 13:31:57 <ddevault> I can't argue with all of you at once
2019-07-23 13:32:03 <ddevault> I will write up a letter to the infra list
2019-07-23 13:32:08 <ncopa> 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 <nmeum> +1
2019-07-23 13:32:36 <clandmeter> _ikke_: the problem now is that rspamd doesnt kick in, which applies sec features.
2019-07-23 13:32:40 <ddevault> 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 <clandmeter> me neither
2019-07-23 13:32:59 <clandmeter> well i did know rspamd does it
2019-07-23 13:33:30 <clandmeter> at least i think this is the issue
2019-07-23 13:37:23 <tcely> ddevault: FYI, the bounce message is not displaying in Gmail app on Android too. http://k00.fr/e0usualf
2019-07-23 13:37:38 <clandmeter> _ikke_: do you remember why you changed the config?
2019-07-23 13:37:49 <ddevault> 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 <clandmeter> ok
2019-07-23 13:38:20 <clandmeter> ill switch this to infra
2019-07-23 13:39:27 <MY_R> tcely, maybe it have something to do with gmail "problem" with which clandmeter fighting hard :)
2019-07-23 13:43:00 <MY_R> ah ye and sorry people for my noise and bad english :>
2019-07-23 15:10:53 <mps> although I dislike HTML mail I think we should allow it for ML's, except aports
2019-07-23 15:11:33 <tmhoang> everyone's english is bad, no worries
2019-07-23 15:14:23 <MY_R> :D
2019-07-23 15:20:40 <MY_R> 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 <PureTryOut[m]> Can someone please merge pr9319?
2019-07-23 16:07:45 <maxice8> it is in main D:
2019-07-23 16:08:02 <PureTryOut[m]> Yup...
2019-07-23 16:08:55 <_ikke_> I'll look at it in a second
2019-07-23 16:23:39 <oneinsect> hola folks
2019-07-23 16:23:56 <oneinsect> can anyone please throw some light on how to use alpine itself to build a glibc iso..
2019-07-23 16:24:04 <oneinsect> i am trying to use chroot in debian
2019-07-23 16:24:14 <oneinsect> able to compile abuild and apk-tools
2019-07-23 16:24:43 <oneinsect> 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 <oneinsect> 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 <artok> want to do alpine that has only glibc and not musl?
2019-07-23 16:25:40 <oneinsect> yes
2019-07-23 16:26:28 <oneinsect> i dont want to use an musl alpine to build a glibc version least it should contaminate it
2019-07-23 16:26:29 <artok> you need to crawl through all build files to remove musl stuff
2019-07-23 16:26:40 <oneinsect> i am doing that
2019-07-23 16:26:43 <oneinsect> for example
2019-07-23 16:27:13 <oneinsect> https://git.alpinelinux.org/alpine-baselayout/tree/
2019-07-23 16:27:21 <oneinsect> this really doesnt depend on musl
2019-07-23 16:27:30 <oneinsect> however abuild refuses to compile it
2019-07-23 16:27:45 <danieli> it will not be a trivial task
2019-07-23 16:28:13 <oneinsect> any ideas that i could try out?
2019-07-23 16:29:36 <oneinsect> busybox compiles fine....i just need some basic utils to do a bare boot of glibc alpine
2019-07-23 16:29:44 <oneinsect> and i am struck there
2019-07-23 16:30:46 <oneinsect> 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 <oneinsect> require glibc
2019-07-23 16:31:14 <oneinsect> not just glibc binaries but a distro based on it
2019-07-23 16:31:24 <oneinsect> for them to properly function
2019-07-23 16:31:37 <oneinsect> guys just throw in some ideas that i can try
2019-07-23 16:32:49 <oneinsect> whats the first package alpine looks for in addition to abuild and apk-tools
2019-07-23 16:32:52 <oneinsect> while booting?
2019-07-23 16:33:40 <oneinsect> is this the base?
2019-07-23 16:33:41 <oneinsect> https://git.alpinelinux.org/aports/tree/main/alpine-baselayout/APKBUILD
2019-07-23 16:33:50 <oneinsect> the first package i mean?
2019-07-23 16:33:52 <artok> well it is openrc init system
2019-07-23 16:34:28 <oneinsect> yes i know
2019-07-23 16:35:22 <oneinsect> ncopa
2019-07-23 16:35:25 <oneinsect> any ideas?
2019-07-23 16:36:25 <_ikke_> Did you package glibc already?
2019-07-23 16:37:39 <oneinsect> 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 <oneinsect> 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 <artok> 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 <oneinsect> aha
2019-07-23 16:39:07 <oneinsect> i have a glibc available
2019-07-23 16:39:22 <oneinsect> in my debian chroot
2019-07-23 16:39:25 <artok> so first you create glibc package and make glibc-dev sub package...
2019-07-23 16:39:42 <oneinsect> using abuild?
2019-07-23 16:39:46 <artok> yah
2019-07-23 16:39:54 <oneinsect> aaaaaaah!
2019-07-23 16:40:04 <oneinsect> so i need an alpine chroot then
2019-07-23 16:40:28 <oneinsect> isnt it?
2019-07-23 16:40:40 <artok> yeah, to run abuild
2019-07-23 16:41:24 <oneinsect> 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 <artok> well you make that after you've built packages
2019-07-23 16:42:00 <artok> using your build dir as repo
2019-07-23 16:42:19 <oneinsect> perfect
2019-07-23 16:42:20 <oneinsect> but
2019-07-23 16:42:23 <oneinsect> in here
2019-07-23 16:42:24 <oneinsect> https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in_a_chroot
2019-07-23 16:42:34 <artok> apk.static -X /your/built/packages/that/use/glibc/
2019-07-23 16:42:59 <oneinsect> 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 <oneinsect> wont i need the alpine-base?
2019-07-23 16:43:21 <artok> yes, and you'll build that using alpine chroot and abuild
2019-07-23 16:43:53 <artok> musl alpine chroot is just for building for now
2019-07-23 16:44:35 <oneinsect> but wont it contaminate the glibc builds?
2019-07-23 16:44:59 <artok> no
2019-07-23 16:45:24 <oneinsect> alrite let me fire up right up right away
2019-07-23 16:46:00 <artok> start building that glibc package and then you'll build everything using that as dependency
2019-07-23 16:46:17 <oneinsect> correct
2019-07-23 16:49:03 <artok> 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 <artok> libc-utils namely is the one that you'll need to point to your glibc
2019-07-23 16:51:33 <oneinsect> 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 <oneinsect> 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 <oneinsect> sorry
2019-07-23 16:53:30 <oneinsect> 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 <oneinsect> STEP-2. tar -xzf apk-tools-static-*.apk
2019-07-23 16:54:05 <artok> rather use paste service that flooding channel =)
2019-07-23 16:55:51 <artok> 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 <oneinsect> oops sorry i will use the paste service
2019-07-23 16:56:53 <artok> 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 <oneinsect> sure
2019-07-23 16:59:07 <oneinsect> i will sit and try now
2019-07-23 17:00:54 <mps> 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 <MY_R> mps, gmail? :P
2019-07-23 17:03:34 <mps> no, mutt and postfix
2019-07-23 17:03:54 <_ikke_> I did receive your e-mail
2019-07-23 17:03:57 <mps> not a HTML mail ;)
2019-07-23 17:05:08 <mps> 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 <MY_R> I think "they" working on it because I reported same
2019-07-23 17:06:19 <mps> "they" is ddevault, I think
2019-07-23 17:06:40 <MY_R> not so sure, ask clandmeter
2019-07-23 17:07:50 <mps> hmmm, I expected that move to sr.ht will be change to something better
2019-07-23 17:11:38 <ddevault> mps: mails are not sent back to you
2019-07-23 17:11:40 <ddevault> this is by design
2019-07-23 17:12:54 <mps> ddevault: please revert design
2019-07-23 17:13:21 <MY_R> 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 <MY_R> have a nice day people! :D
2019-07-23 17:14:06 <mps> MY_R: :D
2019-07-23 17:15:05 <ddevault> mps: you don't get your reply copied back to you when you email anyone else
2019-07-23 17:15:13 <ddevault> mps: copy sent messages to your sent folder
2019-07-23 17:16:03 <ddevault> if you just want to know your messages got there, you can read them on the archives:
2019-07-23 17:16:04 <ddevault> https://lists.alpinelinux.org/~alpine/devel/%3C1c2e99a3-4995-296d-b6e1-6fbad8261ab8%40schinagl.nl%3E
2019-07-23 17:16:19 <mps> ddevault: I know that, but I expected that move to sr.ht will 'replicate' previous ML system behavior
2019-07-23 17:16:29 <ddevault> much of the previous ML system's behavior was broken
2019-07-23 17:16:37 <ddevault> fixing these problems was part of the motivation for the move
2019-07-23 17:16:44 <ddevault> it was never going to be 1:1
2019-07-23 17:17:10 <mps> so, I have to fire up browser to check if my mail arrived. That is bad, imo
2019-07-23 17:17:19 <ddevault> or you can just trust that your mail arrived
2019-07-23 17:17:26 <ddevault> like you do with every other recipient you send mail to
2019-07-23 17:18:15 <mps> 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 <mps> and, that was also on Alpine till switch to sr.ht ML system
2019-07-23 17:19:03 <ddevault> I consider this a bug in other mailing lists
2019-07-23 17:19:55 <mps> hmmm, such changes should be discussed somewhere before implementation
2019-07-23 17:20:05 <ddevault> the switch to lists.sr.ht was discussed in great detail
2019-07-23 17:20:11 <ddevault> give it some time to get used to
2019-07-23 17:20:47 <mps> hmmm :-(
2019-07-23 17:21:43 <ddevault> a great deal of thought has gone into its design, give it a chance
2019-07-23 17:22:00 <ddevault> it's different, yes, but in deliberately thought out ways
2019-07-23 17:23:37 <mps> 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 <ddevault> at some point we've got to rip off the band-aid
2019-07-23 17:24:12 <ddevault> expecting me to reimplement mlmmj bug-for-bug and gradually replace it with a working system is unreasonable
2019-07-23 17:26:01 <mps> 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 <ddevault> it's not complicated
2019-07-23 17:26:32 <ddevault> in fact, implementing it would only involve removing lines of code
2019-07-23 17:26:36 <ddevault> like I said, it's by design
2019-07-23 17:27:35 <mps> ok, don't feel offended by my words. maybe others have to say something about that
2019-07-23 17:29:08 <mps> 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 <ddevault> sounds more like repetition than addition
2019-07-23 17:30:44 <mps> 'repeticium est mater studiorum'
2019-07-23 17:31:04 <ddevault> 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 <ddevault> _ikke_: I don't understand the question
2019-07-23 17:31:34 <ddevault> oh, I see what you mean
2019-07-23 17:31:48 <mps> old Latin
2019-07-23 17:31:51 <ddevault> 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 <clandmeter> Why not make it a feature?
2019-07-23 17:32:17 <clandmeter> 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 <ddevault> clandmeter: I may in the future, but not soon
2019-07-23 17:33:14 <ddevault> _ikke_: gotcha. lmk if that works for you, I'll rejiggle things manually if you need
2019-07-23 17:44:55 <oneinsect> ooh my god!
2019-07-23 17:44:59 <oneinsect> Glibc depends on: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.
2019-07-23 17:45:18 <oneinsect> so i have to now compile all those before compiling glibc
2019-07-23 17:45:24 <oneinsect> without musl
2019-07-23 17:45:29 <oneinsect> phew!
2019-07-23 17:45:34 <oneinsect> life sucks!
2019-07-23 17:45:52 <mps> 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 <mps> forgot to add ';-)'
2019-07-23 17:46:36 <oneinsect> lol
2019-07-23 17:47:40 <mps> 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 <maxice8> yes we did
2019-07-23 17:49:43 <mps> _ikke_: yes, 1.1.23 and not 1.23 ofc
2019-07-23 17:50:07 <maxice8> yes, 1.1.23
2019-07-23 17:50:58 <mps> 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 <PureTryOut[m]> Pong, at dinner in restaurant though lol
2019-07-23 18:16:23 <artok> dinner alone
2019-07-23 18:18:49 <PureTryOut[m]> No, I'm being asocial atm lol
2019-07-23 18:21:50 <KH405> is anybody running alpine with runit, any comments?
2019-07-23 18:22:59 <mps> KH405: yes, not as init 1 but runs fine
2019-07-23 18:23:17 <MY_R> I will be kind and I wish you bon appetit PureTryOut[m] ! :) </offtopic>
2019-07-23 18:23:33 <KH405> As what then mps ?
2019-07-23 18:24:18 <mps> runs from /etc/init.d/runitd
2019-07-23 18:24:50 <mps> as supervisor for some 'things' I need
2019-07-23 18:24:58 <KH405> Ohhh, okay. I was just asking cause apparently OpenRC runs weird with superviors ...
2019-07-23 18:25:43 <mps> yes, openrc is weird for supervising, because that I use runit
2019-07-23 18:26:11 <KH405> Would you recommend dropping openRC all the way amnd run ruinit with S6 ?
2019-07-23 18:27:46 <p4Wv1qn095FW> 
ACTION prefers s6 to runit

2019-07-23 18:28:18 <p4Wv1qn095FW> but i also only run it as non-pid1
2019-07-23 18:28:22 <KH405> 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 <p4Wv1qn095FW> it is, as good (or even better) as runit
2019-07-23 18:30:34 <KH405> Then would you recommend dropping OpenRC and try S6?
2019-07-23 18:31:42 <Cogitri> If you're OK with getting your own services/writing them
2019-07-23 18:32:06 <Cogitri> s6-rc is kinda clunky and hard to get into at first, I personally like 66 more
2019-07-23 18:32:17 <mps> afaik, s6 is not intended to be init 1
2019-07-23 18:33:36 <mps> 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 <KH405> You're right, sorry!
2019-07-23 18:55:42 <KH405> Cogitri I can't find info on 66, do you have a link on where to start?
2019-07-23 18:56:41 <PureTryOut[m]> _ikke_: I'm available now, what's up?
2019-07-23 19:05:35 <Cogitri> 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 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> Which this PR doesn't make use of
2019-07-23 19:18:53 <PureTryOut[m]> 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 <z3ntu> 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 <Cogitri> BTW, do we purge libtool archives (.la files)?
2019-07-23 19:24:18 <PureTryOut[m]> _ikke_: thanks!
2019-07-23 19:25:00 <PureTryOut[m]> 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 <PureTryOut[m]> I'll restart the CI
2019-07-23 19:51:08 <PureTryOut[m]> It passed CI
2019-07-23 20:19:35 <mps> ncopa: would you mind if I upgrade sndio to 1.6.0, you are maintainer
2019-07-23 20:20:16 <mps> tested build  on x86_64, armv7 and aarch64
2019-07-23 20:58:49 <maxice8> 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 <maxice8> pr9599 through pr9602
2019-07-24 03:38:37 <lolstarfall> lol are we actually 'plaintext certifying' email clients now
2019-07-24 03:39:06 <lolstarfall> ddevault: but an image isnt plain text? how can you possibly commit such a sin
2019-07-24 03:49:19 <danieli> let's keep the topic to #alpine-offtopic please? I have a feeling it could get lengthy
2019-07-24 03:59:58 <lolstarfall> 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 <lolstarfall> But I'm happy to move it there if you disagree with that
2019-07-24 04:10:02 <c705> 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 <maxice8> ncopa can you look at libtasn1 security upgrades ? from pr9598 to pr9602
2019-07-24 07:54:44 <ncopa> maxice8: will do
2019-07-24 08:09:26 <terror_> Has anyone tried to build podman on Alpine?
2019-07-24 08:10:29 <danieli> 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 <terror_> Thanks danieli !
2019-07-24 08:30:41 <terror_> danieli was there any caveats I should be aware of?
2019-07-24 08:30:57 <danieli> 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 <mps> 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 <ncopa> mps: maybe i did, but i have forgotten it :)
2019-07-24 09:07:16 <ncopa> mps: i dont mind you updating it
2019-07-24 09:07:35 <mps> I tested build on x86_64, armv7 and aarch64, and thinking to move it to community
2019-07-24 09:08:09 <mps> so, the some packages could be built with it, or tried at least
2019-07-24 09:08:38 <mps> I have mpv and firefox-esr in mind for now
2019-07-24 09:13:30 <mps> pushed sndio, and it pass builds. what you think about moving it to community?
2019-07-24 09:20:51 <mps> hmm, looks like you also don't mind about moving :-) I will move it later
2019-07-24 09:23:22 <mps> btw, can we use gitlab MR's now
2019-07-24 09:25:40 <Cogitri> 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 <ncopa> mps: can you try make a MR?
2019-07-24 09:54:48 <ncopa> yes, i think MRs should work at this point
2019-07-24 09:54:52 <ncopa> there is no CI though
2019-07-24 09:54:55 <ncopa> 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 <ncopa> we already got a couple
2019-07-24 09:55:51 <ncopa> we need to make it work at some point
2019-07-24 09:56:13 <ncopa> things that probably dont work is autoclose
2019-07-24 09:56:29 <mps> I'm not sure it is good to make MR without testing build first
2019-07-24 09:57:01 <ncopa> mps: MR at this point is equivalent to sending patch to mailing list
2019-07-24 09:57:09 <mps> anyway will try build locally and if it is ok then could try make MR
2019-07-24 09:57:14 <ncopa> sounds good
2019-07-24 09:58:48 <mps> 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 <mps> something about https://docs.gitlab.com/ce/user/project/merge_requests/ but with Alpine aports examples
2019-07-24 10:05:44 <clandmeter> it should be trivial to add x86_64 builder for MR's
2019-07-24 10:06:27 <clandmeter> _ikke_: do you want to look into converting the current drone pipeline into gitlab-ci?
2019-07-24 10:13:55 <clandmeter> 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 <Cadey> 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 <Cadey> 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 <lolstarfall> oof
2019-07-24 10:59:34 <lolstarfall> another one
2019-07-24 11:25:42 <tcely> 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 <Cadey> 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 <Cadey> its frustrating
2019-07-24 11:28:12 <tcely> That's horrible! I had thought having a text part meant it would be accepted.
2019-07-24 11:35:46 <maxice8> _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 <maxice8> 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 <maxice8> ok found out
2019-07-24 11:53:38 <_ikke_> and?
2019-07-24 11:59:22 <maxice8> Yes it is no
2019-07-24 11:59:28 <maxice8> BTW 18 is out
2019-07-24 11:59:56 <_ikke_> That's fast :P
2019-07-24 14:28:29 <mps> ncopa: (et all) https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3
2019-07-24 14:29:18 <mps> 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 <mps> 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 <maxice8> mps: you're lucky, i might have the CLI tool for you
2019-07-24 14:33:55 <mps> already looked at some in pyrhon, but forgot url, it is on GH somewhere
2019-07-24 14:34:23 <maxice8> 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 <mps> maxice8: :-) 'I feel lucky'
2019-07-24 14:36:08 <Cogitri> mps: Nice work :P
2019-07-24 14:36:38 <mps> Cogitri: thanks :P
2019-07-24 14:38:40 <mps> if this workflow shows as good enough I will stop posting patches by ML, probably
2019-07-24 14:39:18 <maxice8> _ikke_: Hub is written in go
2019-07-24 14:39:26 <Cogitri> Neat
2019-07-24 14:42:57 <MY_R> hey, does "ulimit -p" option exist?
2019-07-24 14:48:47 <MY_R> 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 <MY_R> and docker service stop/start return: ulimit: unrecognized option: p
2019-07-24 14:52:13 <MY_R> ah ye in "ash" there is no -p but it is in bash... so dunno
2019-07-24 15:40:51 <ncopa> MY_R: i think it is the recent busybox update that introduced it
2019-07-24 15:41:06 <ncopa> MY_R: can you please file an issue on gitlab.a.o so we dont forget it?
2019-07-24 15:41:31 <MY_R> ncopa, ye I was suprised that didnt notice it after docker update but after today updates
2019-07-24 15:41:47 <MY_R> so I wasnt sure what is going on, ok
2019-07-24 15:43:40 <nmeum> https://git.busybox.net/busybox/commit/?id=a92a9601f89d59597b268e29e7098597a8766778
2019-07-24 15:43:45 <nmeum> upstream seems to have renamed -p to -u
2019-07-24 15:44:13 <MY_R> ah ye on 3.10 got -p but no -u
2019-07-24 15:44:48 <nmeum> I would suggest simply removing that docker patch
2019-07-24 15:48:59 <ncopa> probably a good idea yes
2019-07-24 16:03:11 <ncopa> what do you ppl think about this CODESTYLE.md doc? https://tpaste.us/4ypl
2019-07-24 16:05:03 <Cogitri> I think we should merge that with what SpaceToast has been working on
2019-07-24 16:06:39 <Cogitri> Also, I like Void's Manual.md https://github.com/void-linux/void-packages/blob/master/Manual.md
2019-07-24 16:07:35 <nmeum> ncopa MY_R: just pushed a faix for docker
2019-07-24 16:07:37 <nmeum> *fix
2019-07-24 16:08:12 <MY_R> great, thank you :) so somebody can close the issue
2019-07-24 16:08:23 <nmeum> oh, didn't know there was one
2019-07-24 16:09:00 <nmeum> 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 <SpaceToast> 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 <MY_R> nmeum, ncopa wanted to have issue to not forget about it :)
2019-07-24 16:10:17 <SpaceToast> If not, the sorting advice will cause lots of failure conditions.
2019-07-24 16:11:00 <SpaceToast> 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 <errn0> ncopa: I think that is neat and detailed enough. Explaination of eval deprecation would be cool :)
2019-07-24 16:11:19 <nmeum> MY_R: yeah, thanks for creating one. i just closed it
2019-07-24 16:11:29 <SpaceToast> Search/replace isn't clear - maybe specify the difference between single and double /s?
2019-07-24 16:11:47 <MY_R> nmeum :)
2019-07-24 16:11:52 <ncopa> nmeum: yes, there is still missing things. but its a start
2019-07-24 16:11:54 <Cogitri> 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 <SpaceToast> Quoting rules aren't really "complete" but a good starting point
2019-07-24 16:12:35 <SpaceToast> That's all I've got though :)
2019-07-24 16:12:43 <SpaceToast> Thanks Cogitri
2019-07-24 16:13:16 <nmeum> ncopa: definitly
2019-07-24 16:15:10 <Cogitri> SpaceToast: Actually nevermind, should work now: https://github.com/alpinelinux/abuild/pull/72
2019-07-24 16:15:14 <Cogitri> Seems like it has been merged during my holidays :)
2019-07-24 16:15:25 <ncopa> its not pushed to aports yet though
2019-07-24 16:15:36 <ncopa> i have more work planned for abuild
2019-07-24 16:15:45 <ncopa> before i tag new release
2019-07-24 16:19:20 <ncopa> 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 <ncopa> ${var/search/replace}
2019-07-24 16:20:48 <_ikke_> oh, regarding codestyle?
2019-07-24 16:20:56 <ncopa> yes
2019-07-24 16:21:07 <_ikke_> Was still thinking you were talking about abuild
2019-07-24 16:21:18 <ncopa> no, im multitasking :)
2019-07-24 16:21:40 <ncopa> should we call the doe CODESTYLE.md, CODINGSTYLE.md or STYLE.md?
2019-07-24 16:24:03 <errn0> 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 <ncopa> im removing ti because i want to push it today
2019-07-24 16:24:49 <ncopa> in other words, remove the controversial parts
2019-07-24 16:25:02 <errn0> Yeah... I agree to that
2019-07-24 16:25:12 <MY_R> STYLEGUIDE.md ?
2019-07-24 16:25:19 <ncopa> :D
2019-07-24 16:25:39 <ncopa> MY_R: i was hoping to reduce the number of options :)
2019-07-24 16:25:45 <MY_R> hehe
2019-07-24 16:25:58 <MY_R> but hey even can find it on wiki like that: https://en.wikipedia.org/wiki/Style_guide
2019-07-24 16:25:59 <alpine-meetbot> [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 <errn0> ncopa: KISS :))
2019-07-24 16:28:55 <MY_R> or even better: APKBUILDGUIDE.md :D look at examples http://google.github.io/styleguide/
2019-07-24 16:29:24 <ncopa> i think we will have a more extensive developers handbook
2019-07-24 16:30:36 <ncopa> pushed
2019-07-24 16:31:10 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/blob/master/CODINGSTYLE.md
2019-07-24 16:32:07 <ncopa> mps: you had to pick a complicated PR :)
2019-07-24 16:33:42 <przemoc> errn0: ${parameter/pattern/string} expansion is not POSIX.
2019-07-24 16:34:03 <przemoc> unfortunately it is used in APKBUILDs
2019-07-24 16:34:11 <_ikke_> local is also not POSIX
2019-07-24 16:34:30 <ncopa> those are the two exceptions that i have accepted
2019-07-24 16:34:57 <przemoc> but local is commonly agreed necessary expansion over POSIX, thus supported practically everywhere
2019-07-24 16:36:09 <ncopa> its difficult to implement ${var/parameter/string} in pure posix
2019-07-24 16:36:36 <ncopa> 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 <ncopa> 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 <ncopa> 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 <ncopa> its not expected to be perfect, but good enough to be official
2019-07-24 16:43:09 <SpaceToast> if you have any actionable concerns, patches (and discussion around them) is welcome, of course :)
2019-07-24 16:43:33 <SpaceToast> the new gitlab is the preferred platform, at least once the docs/ namespace is migrated
2019-07-24 16:43:42 <Cogitri> I guess I have my evening reading then :P
2019-07-24 16:44:02 <Cogitri> Thanks for the work, SpaceToast
2019-07-24 16:45:01 <przemoc> shouldn't it consistently use "Alpine Linux" everywhere?  for instance the title is Alpine User Handbook.
2019-07-24 16:46:00 <SpaceToast> "Alpine" is a commonly used abbreviation; for instance, see the front page: "Alpine 3.10.1 released"
2019-07-24 16:46:11 <MY_R> ncopa, alpine-user@lists.alpinelinux.org is correct address or should be "~alpine/users" ?
2019-07-24 16:46:27 <SpaceToast> 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 <SpaceToast> still, worst case it's a simple recursive sed patch :)
2019-07-24 16:48:22 <przemoc> 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 <SpaceToast> 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 <SpaceToast> 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 <przemoc> 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 <SpaceToast> and the domain for docs does in have contain "alpinelinux.org" :)
2019-07-24 17:14:11 <PureTryOut[m]> _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 <PureTryOut[m]> Thanks for the merge!
2019-07-24 18:11:07 <mps> ncopa: MR is complicated? I presume you are kidding :-)
2019-07-24 18:11:47 <mps> 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 <mps> and one which have issue to check auto closing issue with fixes #nr in commit message
2019-07-24 18:13:48 <mps> 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 <mps> _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 <mps> 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 <mps> 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 <mps> 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 <mps> I think, yes
2019-07-24 18:20:15 <mps> 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 <mps> 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 <Cogitri> 
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 <mps> _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 <Cogitri> But merge commits spam the log so much
2019-07-24 18:29:38 <Cogitri> And you can rebase in the webUI
2019-07-24 18:29:44 <Cogitri> 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 <mps> I have no preference about that, but git.a.o now need 'FF'
2019-07-24 18:30:16 <Cogitri> 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 <Cogitri> 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 <Cogitri> Which is like 90% of our MRs, I imagine
2019-07-24 18:38:33 <Cogitri> 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 <Cogitri> Hm, I don't really see the value attached to that :/
2019-07-24 18:42:38 <Cogitri> 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 <Cogitri> 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 <Cogitri> Okay, didn't know that, my bad
2019-07-24 18:46:11 <Cogitri> 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 <mps> only have to know where is the line between big and small
2019-07-24 19:00:39 <Cogitri> 5 commits?
2019-07-24 19:01:29 <_ikke_> It's not the amount of commits that matter
2019-07-24 19:02:43 <mps> have no idea, and think we should stick with one method, i.e. FF or normal merge
2019-07-24 19:03:35 <mps> have fear that this will be source of a lot of 'bikesheding'
2019-07-24 19:16:38 <maxice8> 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 <mps> 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 <Cogitri> Yes, but without the merge commit which usually is nice
2019-07-24 19:22:51 <mps> 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 <mps> 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 <mps> 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 <mps> 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 <mps> ah, nice idea
2019-07-24 19:37:17 <maxice8> Sweet
2019-07-24 19:37:44 <maxice8> 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 <mps> maxice8: do you have url of the Lab?
2019-07-24 19:41:10 <maxice8> mps: I have a PR for it on GitHub
2019-07-24 19:41:11 <maxice8> Am on phone
2019-07-24 19:41:29 <mps> aha, ok. nice
2019-07-24 19:42:11 <maxice8> https://github.com/zaquestion/lab
2019-07-24 19:43:06 <maxice8> I couldn't get it to build under alpine (see CI failing on github)
2019-07-24 19:43:09 <mps> thanks
2019-07-24 19:43:31 <maxice8> But you can build via the classic git clone and make
2019-07-24 19:44:13 <mps> will try but tomorrow, now I'm on my $daywork
2019-07-24 19:44:37 <maxice8> My next blog post will be about my workflow in Alpine want a link once I make it
2019-07-24 19:45:37 <mps> ofc, would be nice to read about such big productive man experience
2019-07-24 20:32:58 <maxice8> Is there a set date for when MRs are going to be the recommended way over GitHub PRs ?
2019-07-24 20:41:21 <clandmeter> maxice8: no
2019-07-24 20:41:38 <clandmeter> it depends when we have the builders ready
2019-07-24 20:44:38 <clandmeter> and when we converted the drone pipeline to gitlab-ci
2019-07-24 20:45:12 <clandmeter> although that should not take too much time.
2019-07-25 05:38:25 <maxice8> mps: ping
2019-07-25 06:55:35 <maxice8> clandmeter: Ok, thanks for the info.
2019-07-25 07:20:43 <mps> maxice8: pong
2019-07-25 07:21:12 <mps> oh, I see. And good morning
2019-07-25 07:21:39 <maxice8> I sent you my blog post via pm
2019-07-25 07:26:23 <mps> I see, and answered you. thanks
2019-07-25 07:30:41 <clandmeter> maxice8: please share now im curious.
2019-07-25 07:34:47 <mps> maxice8: where can I see (and maybe download) 'ax' script
2019-07-25 07:36:04 <Cogitri> https://github.com/maxice8/meltryllis
2019-07-25 07:37:45 <Cogitri> In bin/
2019-07-25 07:38:22 <mps> found it, thanks
2019-07-25 07:39:12 <clandmeter> i guess its https://maxice8.github.io/25-alpine-workflow/
2019-07-25 07:40:09 <mps> clandmeter: yes
2019-07-25 07:40:30 <clandmeter> that wasnt too difficult to find :)
2019-07-25 07:40:34 <maxice8> clandmeter: yes
2019-07-25 07:42:25 <mps> maxice8: btw, I've built Lab last night.
2019-07-25 07:45:16 <mps> 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 <mps> _ikke_: thanks
2019-07-25 08:35:12 <mps> '~/lab/lab mr list' => #5 Update CODINGSTYLE.md
2019-07-25 08:35:36 <mps> nice
2019-07-25 08:53:05 <mps> wrong channel, sorry
2019-07-25 08:54:04 <clandmeter> maxice8: i pushed another version of lab to testing.
2019-07-25 08:56:29 <maxice8> clandmeter: nice
2019-07-25 08:58:30 <clandmeter> maxice8: there are some issues with it.
2019-07-25 08:58:34 <clandmeter> the tests
2019-07-25 08:58:50 <maxice8> Not nice
2019-07-25 08:59:08 <clandmeter> it tries to connect to gitlab.com via ssh
2019-07-25 08:59:38 <clandmeter> it should auto accept the host key, not sure how to do that.
2019-07-25 09:05:13 <clandmeter> 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 <maxice8> sure
2019-07-25 09:06:05 <clandmeter> and if it works move it please
2019-07-25 09:06:20 <clandmeter> seems nice to have.
2019-07-25 09:09:29 <maxice8> Checks require a gitlab account with ssh enabled
2019-07-25 09:11:08 <maxice8> haha what is this
2019-07-25 09:11:22 <maxice8> i can't even run `./lab completion bash > lab.bash`
2019-07-25 09:12:42 <maxice8> it asks me interactive questions to set up configuration
2019-07-25 09:12:43 <maxice8> 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 <clandmeter> yes its a bit stupid
2019-07-25 09:13:01 <clandmeter> --help also doesnt work
2019-07-25 09:13:07 <clandmeter> you needto auth
2019-07-25 09:13:29 <clandmeter> i think we should ask them to remove bash
2019-07-25 09:13:34 <clandmeter> its a stupid oneliner
2019-07-25 11:42:53 <ncopa> 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 <ncopa> once that was resolved it worked pretty ok
2019-07-25 12:34:07 <clandmeter> you can specify origin
2019-07-25 12:38:16 <clandmeter> remote i mean
2019-07-25 12:47:51 <maxice8> ncopa: with lab you can specify a remote but i think it uses upstream
2019-07-25 12:47:53 <maxice8> as the remote name
2019-07-25 13:09:24 <maxice8> Hub which is Lab but for GitHub uses github -> upstream -> origin
2019-07-25 20:07:13 <mps> 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 <mps> yes, where I can see url of just sent patch
2019-07-25 20:08:31 <_ikke_> ^
2019-07-25 20:09:05 <mps> 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 <mps> but I received mail from ML that the patch is there
2019-07-25 20:09:54 <mps> 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 <mps> that's old one
2019-07-25 20:11:22 <mps> maybe ML system need some time to put it on web server
2019-07-25 20:11:32 <clandmeter> should be instant
2019-07-25 20:14:01 <mps> 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 <mps> 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 <mps> 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 <mps> yes, I know, I use graylisting in my servers for year
2019-07-25 20:16:22 <mps> but I put message 'greylisted for $amount_of_time' in msg
2019-07-25 20:22:32 <mps> '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 <mps> question is, should I send same patch for 3.10
2019-07-25 20:23:39 <mps> or note somehow commiter to apply this one to 3.10
2019-07-25 20:30:29 <maxice8> yes, on github i send separate PRs for other branches
2019-07-25 20:33:18 <mps> 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 <mps> (starting to dislike ML for sending patches :-P )
2019-07-25 20:34:39 <maxice8> ¯_(ツ)_/¯ 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 <mps> 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 <mps> hope it will be easier, especially with 'lab'
2019-07-25 20:35:48 <maxice8> _ikke_: good luck
2019-07-25 20:35:49 <_ikke_> The heat here does not help though
2019-07-25 20:36:20 <mps> _ikke_: no need to hurry, I learned to be patient in my life
2019-07-25 20:36:50 <mps> 'it is ready when it is ready'
2019-07-25 20:37:19 <mps> 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 <mps> I know, I follow infra channel, when have time
2019-07-25 20:49:56 <mps> 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 <mps> 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 <mps> 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 <mps> 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 <mps> 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 <clandmeter> Same here
2019-07-25 21:06:15 <clandmeter> Can't focus with this temp
2019-07-25 21:06:33 <clandmeter> Still over 30 outside
2019-07-25 21:06:38 <clandmeter> Nuts
2019-07-25 21:06:50 <mps> 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 <mps> (and just criticized someone for improper wording on commit msg)
2019-07-25 21:08:18 <mps> 
ACTION hides somewhere

2019-07-25 23:08:46 <maxice8> clandmeter: that's a lotta heat, usually have that during summer but it is winter now
2019-07-25 23:09:06 <danieli> that's a lotta damage
2019-07-25 23:11:43 <maxice8> mps: i forget that i lot myself
2019-07-25 23:11:46 <maxice8> mainly because i solved that problem with githooks
2019-07-25 23:15:10 <mps> 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 <mps> and looked at it here https://gitlab.alpinelinux.org/alpine/aports/blob/master/.githooks/prepare-commit-msg
2019-07-25 23:16:38 <mps> didn't know it exists
2019-07-25 23:16:55 <maxice8> it is not the same as mine
2019-07-25 23:17:01 <mps> will be very useful to me
2019-07-25 23:17:13 <maxice8> i just extended it a bit
2019-07-25 23:17:17 <mps> aha, then will look at your
2019-07-25 23:17:43 <maxice8> it is a hyperlink in my blogpost
2019-07-25 23:18:07 <mps> ah, I see it
2019-07-25 23:18:47 <mps> how can I 'include' it in 'git commit -v'
2019-07-25 23:19:42 <maxice8> i have git config commit.verbose true
2019-07-25 23:19:51 <maxice8> globally so it is always verbose
2019-07-25 23:22:55 <mps> hm, how to 'invoke' githook? never used them
2019-07-25 23:23:13 <maxice8> have them in .git/hooks and they are invoked in specific situations
2019-07-25 23:24:15 <mps> there are some which names ends in .sample
2019-07-25 23:24:31 <maxice8> those are not processed, have them as an executable without the sample
2019-07-25 23:25:24 <mps> heh, copied your there and it works
2019-07-25 23:25:39 <mps> big thanks :-)
2019-07-25 23:26:27 <mps> I learned something new
2019-07-26 07:12:06 <Cogitri> 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 <ncopa> Cogitri: we normally dont enable gettext and native language support
2019-07-26 08:05:35 <ncopa> i am afraid that if we start doing that one place we will end up do it everywhere
2019-07-26 08:06:21 <ncopa> i have previously said that if you need good NLS, then alpine may not be the right tool
2019-07-26 08:06:33 <Cogitri> Hm, I don't really see the problem with that to be honest
2019-07-26 08:06:54 <Cogitri> But alright, I'll just patch the thing to not support NLS
2019-07-26 08:07:31 <ncopa> 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 <ncopa> and a can of worms....
2019-07-26 08:07:53 <ncopa> i dont mind raising that issue, but not right now
2019-07-26 08:08:06 <ncopa> after html email and governance discussions has settled
2019-07-26 08:08:34 <ncopa> doesnt musl have some sort of support for gettext?
2019-07-26 08:08:41 <ncopa> we could maybe use what musl provides
2019-07-26 08:08:51 <Cogitri> <ncopa "i dont mind raising that issue, "> Yup, it's not a pressing matter :)
2019-07-26 08:09:20 <Cogitri> <ncopa "doesnt musl have some sort of su"> Don't think so, glibc does
2019-07-26 08:13:37 <ncopa> it actually have libintl.h
2019-07-26 08:13:47 <ncopa> musl has libintl.h
2019-07-26 08:13:50 <ncopa> but we delete it
2019-07-26 08:14:34 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/musl/APKBUILD#L101
2019-07-26 08:15:45 <ncopa> Cogitri: i have an idea
2019-07-26 08:16:24 <mps> 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 <ncopa> what if we ship musl's libintl.h in musl-libintl subpackage
2019-07-26 08:17:38 <Cogitri> So that only a few packages pull it in to explicitly enable support?
2019-07-26 08:17:44 <ncopa> yes
2019-07-26 08:17:59 <ncopa> i think the reason we remove it is because it used to be not-good enough in musl
2019-07-26 08:18:09 <ncopa> and lots of packages would automatically enabled when detected
2019-07-26 08:18:17 <ncopa> and disable nls when not detected
2019-07-26 08:18:46 <ncopa> mps: i think you are right. so i think it may need to re-evaluate
2019-07-26 08:20:23 <mps> so, for now we have to keep it 'on radar' and discuss later, maybe on devel ML
2019-07-26 08:20:57 <mps> or create issue, if it doesn't exist already
2019-07-26 08:22:30 <mps> 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 <ncopa> mps: will have a look at your patches later
2019-07-26 08:48:15 <mps> np, thanks
2019-07-26 08:49:57 <mps> I tested build on x86, x86_64, armv7 and aarch64, on edge
2019-07-26 08:50:13 <mps> and on x86_64 on v3.10
2019-07-26 08:54:55 <ncopa> Cogitri: something like this? http://tpaste.us/vbnM
2019-07-26 08:55:32 <ncopa> it will at least allow us to start experimenting with it
2019-07-26 08:55:40 <Cogitri> Yup, seems good 👍
2019-07-26 09:06:57 <mps> musl-libintl is good starting point, I think
2019-07-26 09:43:12 <ncopa> it was long time since i looked at musl-intl and i think it has improved
2019-07-26 09:43:26 <ncopa> might be we can replace gnu gettext for lots of stuff
2019-07-26 09:49:45 <Cogitri> Yup, some stuff hardcodes gnu gettext though (e.g. gettext-rs :/)
2019-07-26 09:53:32 <Cogitri> Actually, that seems pretty trivial to replace with modern musl, nice
2019-07-26 14:20:12 <ncopa> 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 <ncopa> ie, in offficial documentation etc
2019-07-26 14:21:10 <ncopa> 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 <duncaen> nice, I have to finish the release at some point, which adds perist
2019-07-26 14:22:04 <ncopa> 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 <duncaen> The readme is still from the fork. I'm confident that the tagged version is fine
2019-07-26 14:22:17 <ncopa> that is for security fixes
2019-07-26 14:22:23 <ncopa> ok
2019-07-26 14:22:34 <ncopa> maybe we could update the readme then?
2019-07-26 14:23:03 <duncaen> yes, going to do that maybe over the weekend
2019-07-26 14:23:09 <ncopa> great!
2019-07-26 14:23:32 <duncaen> 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 <ncopa> will you try follow that?
2019-07-26 14:24:31 <duncaen> 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 <duncaen> and because I'm a bit unsure about the timestamp file stuff
2019-07-26 14:24:56 <ncopa> 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 <ncopa> timestamp file?
2019-07-26 14:25:35 <duncaen> for the persist feature, master has cookie/timestamp files similiar to sudo
2019-07-26 14:27:17 <duncaen> 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 <ncopa> thats what i'd expect
2019-07-26 14:28:17 <duncaen> (never happened in the last 3 years)
2019-07-26 14:28:23 <ncopa> i dont expect too many sec fixes either :)
2019-07-26 14:28:47 <duncaen> the persist/cookies/timestamps could introduce issues, its a bit tricky
2019-07-26 14:29:10 <ncopa> i havent looked into it or why its needed
2019-07-26 14:29:26 <ncopa> i suppose we could build --without-persist in alpine initially
2019-07-26 14:30:04 <ncopa> ah
2019-07-26 14:30:13 <ncopa> "persist After the user successfully authenticates, do not ask for a password again for some time."
2019-07-26 14:31:09 <duncaen> 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 <duncaen> 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 <ncopa> heh
2019-07-26 15:45:54 <ncopa> 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 <ncopa> you add at least 7 lines with code to be able to give apk-tools a serious headache
2019-07-26 15:50:01 <ncopa> or i simply dont understand what happens (in which case code is not clean and simple)
2019-07-26 15:52:46 <ncopa> 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 <ncopa> ok. turns out that it is me that is stupid. i simply misunderstand what the code really does
2019-07-26 16:22:34 <ncopa> i think its better someone more clever does the review. im obviously not smart enough
2019-07-26 16:23:09 <jwh> lol
2019-07-26 16:35:26 <mps> 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 <mps> and not to have three aports repo locally, as I have now :P
2019-07-26 17:28:46 <clandmeter> 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 <gitlab url>; git remote add github <github url>
2019-07-26 17:32:07 <clandmeter> Or if you don't like you can apply the pr patch
2019-07-26 17:32:30 <clandmeter> If gitlab provides it
2019-07-26 17:32:56 <clandmeter> 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 <clandmeter> Later you can even merge from ui
2019-07-26 17:36:18 <clandmeter> I guess lab also provided some features
2019-07-26 17:36:32 <clandmeter> Didn't use it yet
2019-07-26 17:40:43 <mps> 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 <clandmeter> I have too many
2019-07-26 17:41:36 <clandmeter> Had to clean up a few
2019-07-26 17:41:41 <mps> will look deeply if 'lab' can do that, although I think it can, it is wrapper around git
2019-07-26 17:43:13 <mps> lab can fetch patch, I think, although didn't tested it yet
2019-07-26 17:53:21 <mps> '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 <mps> and 2 on gitlab
2019-07-26 18:39:46 <mps> and one MR is applied to aports today, I think first one
2019-07-26 19:58:57 <Cogitri> Thanks for reviewing & merging stuff :)
2019-07-26 21:55:05 <maxice8> mps: i just my pr script which is curl <link-to-raw-pr> | git am -3
2019-07-26 21:55:29 <maxice8> mps: http://ix.io/1PE5
2019-07-26 21:57:10 <mps> maxice8: yes, I thought to use curl, but tested with wget to check if it works
2019-07-26 21:57:19 <maxice8> mps: if you look at my scripts i have 3 remotes, origin, upstream and gitstream :D
2019-07-26 21:57:34 <maxice8> 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 <maxice8> works for me on Hub and will problably work fine on Lab as well
2019-07-26 21:59:43 <mps> I plan tomorrow to read about git remote usage a bit
2019-07-26 22:02:33 <mps> and, I started to test your scripts, gbr works
2019-07-26 22:03:10 <maxice8> you're also gonna need alpine-stable-prefix
2019-07-26 22:03:14 <maxice8> if you plan to use the others
2019-07-26 22:03:26 <maxice8> since i work on stable branches but just prefixing 3.x- to the branch name
2019-07-26 22:03:40 <mps> yes, I copied it to /usr/local/bin
2019-07-26 22:05:22 <mps> I will check how 'ax' work, 'ax g' works fine
2019-07-26 22:05:42 <maxice8> it is a mess but work
2019-07-26 22:05:58 <maxice8> 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 <mps> 'ax e' doesn't
2019-07-26 22:06:44 <Cogitri> wfm
2019-07-26 22:06:50 <mps> '/usr/local/bin/ax: line 78: e: not found'
2019-07-26 22:07:18 <maxice8> oh, you also need my e script which is basically
2019-07-26 22:07:23 <maxice8> exec "${EDITOR:-vi}" "$@"
2019-07-26 22:07:34 <mps> aha, ok
2019-07-26 22:08:15 <maxice8> i got a few scripts that are single letters like m for opening aerc inside dtach.
2019-07-26 22:08:38 <mps> now it works, thanks
2019-07-26 22:08:40 <maxice8> Another one important for 'ax' is the 'f' script which is 'exec ranger "$@"'
2019-07-26 22:09:29 <mps> will look to change it to vifm, and I don't use aerc
2019-07-26 22:13:00 <mps> 'ax l', very nice
2019-07-26 22:14:19 <maxice8> ax f too
2019-07-26 22:15:42 <mps> /usr/local/bin/ax: line 350: apkbuild-fixer: not found
2019-07-26 22:16:46 <mps> probably need newer atools
2019-07-26 22:17:20 <maxice8> 17.1 and up has apkbuild-fixer
2019-07-26 22:18:01 <mps> have to rebuild it for v3.10
2019-07-26 22:19:18 <maxice8> i'd just the edge version
2019-07-26 22:19:19 <maxice8> just use*
2019-07-26 22:20:39 <mps> I use stable, it is my job workstation, although I have edge in lxc
2019-07-26 22:21:55 <mps> 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 <maxice8> 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 <maxice8> _ikke_: Hey you're awake :D
2019-07-27 06:26:55 <maxice8> 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 <maxice8> 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 <maxice8> yes
2019-07-27 06:34:18 <maxice8> pr9373 can be closed
2019-07-27 06:39:47 <_ikke_> done
2019-07-27 06:40:11 <maxice8> thank you
2019-07-27 07:28:11 <_ikke_> maxice8: mongo-php7-library is failing atm
2019-07-27 07:28:50 <maxice8> 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 <mps> 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 <mps> and good morning :-)
2019-07-27 07:42:25 <maxice8> the only dep of atools is grep
2019-07-27 07:42:38 <_ikke_> morning mps
2019-07-27 07:42:52 <mps> _ikke_: good morning
2019-07-27 07:44:21 <mps> 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 <alpine-meetbot> _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 <maxice8> 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 <maxice8> ah
2019-07-27 07:47:02 <maxice8> :D good luck
2019-07-27 07:49:41 <mps> 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 <maxice8> mps: well, anyways use the latest atools since it has the fixes and adapts to policy changes
2019-07-27 07:54:13 <mps> ofc, thanks for reminding me
2019-07-27 07:55:14 <mps> btw, thanks for making 'zola' pkg
2019-07-27 07:57:44 <maxice8> 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 <mps> 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 <maxice8> zola is rust so it only x86_64 for now
2019-07-27 08:01:27 <maxice8> cogitri: is working on Rust
2019-07-27 08:01:37 <mps> I have rust (old version) on aarch64 and I can buid some pkg's
2019-07-27 08:03:34 <maxice8> hopefully it can compile zola
2019-07-27 08:04:36 <mps> will try today
2019-07-27 08:05:26 <mps> I built even firefox-esr 60.7
2019-07-27 08:09:37 <maxice8> nice
2019-07-27 08:13:29 <mps> 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 <maxice8> _ikke_: pr9546 can be closed
2019-07-27 08:24:05 <_ikke_> why?
2019-07-27 08:24:16 <maxice8> Because i merged it
2019-07-27 08:24:34 <maxice8> 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-<PR> to the commit messages I push, so you are certain it gets closed
2019-07-27 08:27:07 <mps> _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 <mps> 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 <maxice8> _ikke_: pr7530 as well please :D
2019-07-27 08:55:06 <maxice8> also was merged
2019-07-27 10:25:43 <maxice8> _ikke_: 18.3 is now available
2019-07-27 10:26:49 <_ikke_> ok
2019-07-27 10:30:52 <Cogitri> mps: Well, help is certainly welcome, currently compiling against our triplets doesn't work :/
2019-07-27 11:02:18 <mps> Cogitri: version in aports doesn't build or something other?
2019-07-27 11:04:14 <Cogitri> 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 <mps> did you look how adelie devs added their triplet (quartet)
2019-07-27 11:06:42 <mps> maybe there is a hint for alpine, I did it earlier copying their triplets and changed to alpine
2019-07-27 21:28:56 <jwh> 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 <jwh> oh
2019-07-27 21:30:56 <jwh> ok tghx
2019-07-27 21:30:59 <jwh> thx*
2019-07-28 11:09:29 <clandmeter> maxice8: i think cargo is supported on more platforms now?
2019-07-28 11:09:44 <maxice8> armhf and armv7
2019-07-28 11:09:56 <maxice8> i believe aarch64 had support for 5 seconds as well but i had to remove it
2019-07-28 11:10:12 <clandmeter> i refer to watchexec
2019-07-28 11:10:29 <maxice8> No that is just me missing something
2019-07-28 11:10:57 <clandmeter> cargo works for armv7 but not aarch64?
2019-07-28 11:11:06 <maxice8> as of now, yes
2019-07-28 11:11:09 <clandmeter> that sounds weird
2019-07-28 11:11:39 <clandmeter> what happens?
2019-07-28 11:12:22 <maxice8> cogitri: can brief you on that, he is the one getting punished by Rust's bootstrapping requirements
2019-07-28 11:30:22 <Cogitri> clandmeter: Our triplets aren't functional on other arches yet, will look into it today
2019-07-28 11:41:16 <maxice8> _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 <maxice8> 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 <maxice8> Nicked them all from OpenSUSE work on backporting upstream patches
2019-07-28 13:30:38 <maxice8> The patches are linked in the issue
2019-07-28 13:30:47 <maxice8> But I'm out buying stuff in bulk
2019-07-28 13:30:49 <_ikke_> Hmm ok
2019-07-28 13:30:50 <maxice8> 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 <maxice8> Patch headers?
2019-07-28 13:37:31 <_ikke_> yes
2019-07-28 14:01:26 <maxice8> Cogitri asked for it ? :D
2019-07-28 14:01:47 <Cogitri> Yup, SpaceToast added it to the docs afaik
2019-07-28 14:01:58 <maxice8> Nice.
2019-07-28 14:02:17 <maxice8> Originally from Exherbo, i then pushed it on Void Linux with Cogitri's help
2019-07-28 14:02:22 <SpaceToast> 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 <SpaceToast> also I'm in the middle of a move, which doesn't help with even attempting that :)
2019-07-28 14:03:40 <SpaceToast> 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 <SpaceToast> (hopefully it'll be up by friday, but I can't guarantee that)
2019-07-28 14:04:03 <Cogitri> No worries
2019-07-28 14:07:08 <maxice8> _ikke_: patches have been upped
2019-07-28 14:07:27 <SpaceToast> maxice8, http://ix.io/1PQ6 - temporary snapshot of the page
2019-07-28 14:07:40 <SpaceToast> the format's slightly different from void/exherbo (we discussed it with Cogitri over in #alpine-docs)
2019-07-28 14:09:39 <Cogitri> 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 <maxice8> _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 <SpaceToast> :)
2019-07-28 14:26:14 <mps> maybe we can move -static (libs) to dev pkg, and use static for statically built binaries
2019-07-28 14:26:46 <maxice8> static libs used to be in dev but were moved to -static by request of ncopa
2019-07-28 14:28:12 <mps> should be moved back, then (yes, I remember discussion but forgot to raise issue)
2019-07-28 14:28:49 <mps> SpaceToast: nice write, simple and clean
2019-07-28 14:30:07 <mps> 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 <maxice8> Used a custom theme from someone else
2019-07-28 14:31:01 <maxice8> https://github.com/maxice8/maxice8.github.io/tree/devel
2019-07-28 14:32:10 <mps> 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 <Cogitri> Do the builders automatically restart builds if they fail?
2019-07-28 15:12:25 <Cogitri> 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 <Cogitri> 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 <Cogitri> I think Void builders try 3 times before giving up
2019-07-28 15:28:57 <Cogitri> But fair enough, who can I nag about random build failures (other than Rust/LLVM upstream)? 😅
2019-07-28 20:15:53 <sickness> hi all
2019-07-28 20:15:56 <sickness> how to know the mantainer of a package?
2019-07-28 20:17:40 <Cogitri> (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 <sickness> oki sorry, didn't know if it was the same
2019-07-28 20:30:23 <PureTryOut[m]> Where do people move pages on the wiki too if they want to archive it?
2019-07-28 22:46:32 <mps> two kernel release in two days, guess it is security fix
2019-07-29 06:17:23 <maxice8> 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 <maxice8> pr9716 can be closed, was merged
2019-07-29 07:07:21 <clandmeter> maxice8: morning
2019-07-29 07:07:32 <clandmeter> which timezone are you in?
2019-07-29 07:08:16 <maxice8> UTC -3
2019-07-29 07:08:17 <maxice8> BRT
2019-07-29 07:08:21 <clandmeter> maxice8: if you downgrade a package, please make sure the new versions has not been used before.
2019-07-29 07:08:39 <clandmeter> s/versions/version
2019-07-29 07:08:39 <alpine-meetbot> 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 <maxice8> Is there a reverts= like Void Linux does ?
2019-07-29 07:09:00 <clandmeter> what does it do?
2019-07-29 07:09:25 <maxice8> automatically makes a lower version package be considered higher version than the package version present in reverts=
2019-07-29 07:09:45 <clandmeter> and how is it used?
2019-07-29 07:09:50 <clandmeter> by t he pkg manager?
2019-07-29 07:09:51 <maxice8> 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 <clandmeter> oh it changes the actual version
2019-07-29 07:10:08 <maxice8> The how i have no sure i didn't look into xbps internals
2019-07-29 07:10:39 <clandmeter> the problem we have is that the pkg file is same filename as before
2019-07-29 07:11:00 <clandmeter> so it will have a cached version in our cdn
2019-07-29 07:11:18 <clandmeter> so cdn will provide the old pkg
2019-07-29 07:11:39 <maxice8> i see
2019-07-29 07:11:46 <clandmeter> maxice8: you are from brazil?
2019-07-29 07:11:55 <maxice8> Yes
2019-07-29 07:11:59 <clandmeter> nice :)
2019-07-29 07:28:17 <maxice8> clandmeter: so how to fix ? bump pkgrel ?
2019-07-29 07:28:55 <clandmeter> if its not used yet, then thats the way.
2019-07-29 07:43:40 <maxice8> ok
2019-07-29 08:08:12 <PureTryOut[m]> Where do people move pages on the wiki too if they want to archive it?
2019-07-29 08:08:18 <PureTryOut[m]> There is no delete option it seems
2019-07-29 08:22:46 <mps> do we have to use libseccomp if they are optional for pkg
2019-07-29 08:23:18 <Cogitri> Please do use it, it filters some dangerous syscalls out
2019-07-29 08:24:10 <mps> dangerous syscalls? then these syscalls should be removed
2019-07-29 08:26:15 <mps> I understand if libseccomp is used for qemu (for example) but not why it is used in zathura
2019-07-29 08:26:29 <clandmeter> its used in many more pkgs.
2019-07-29 08:26:53 <Cogitri> mps: Imagine it like a super complex sandbox for syscalls
2019-07-29 08:27:15 <Cogitri> "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 <mps> 'find -name APKBUILD | xargs grep seccomp-dev | wc -l' => 19
2019-07-29 08:39:43 <clandmeter> mps: no need for find/xargs ;-)
2019-07-29 08:41:11 <mps> you mean 'grep -r libseccomp-dev | wc -l'
2019-07-29 08:45:59 <Cogitri> Anyway, I'd enable seccomp wherever possible, 0.6M for syscall filtering is worth it
2019-07-29 08:49:29 <mps> I have error: 'zathura 4.pdf' => error: Failed to initialize basic seccomp filter.
2019-07-29 08:50:49 <mps> my question is: why zathura uses seccomp and a lot of similar pkg's does not
2019-07-29 08:51:55 <mps> or, reformulate, do we have to use seccomp wherever it is possible
2019-07-29 08:51:59 <Cogitri> 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 <Cogitri> 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 <Cogitri> But I feel like we should enable seccomp is possible anyway
2019-07-29 08:53:14 <mps> or, maybe, if the pkg doesn't use seccomp properly should we remove it from deps
2019-07-29 08:56:06 <clandmeter> grep xxx */*/APKBUILD
2019-07-29 08:57:19 <mps> oh, even shorter, didn't know. thanks :-)
2019-07-29 08:58:42 <mps> and better, grep just APKBUILD files
2019-07-29 08:59:23 <clandmeter> i mostly add -Hi
2019-07-29 08:59:32 <clandmeter> or r if needed
2019-07-29 09:09:52 <PureTryOut[m]> <PureTryOut[m] "Where do people move pages on th"> Does nobody know? 🤔
2019-07-29 09:13:11 <Cogitri> Nop
2019-07-29 09:14:39 <PureTryOut[m]> Who has admin access to/maintains the wiki anyway?
2019-07-29 09:16:44 <clandmeter> 
ACTION hides

2019-07-29 09:17:00 <clandmeter> 
ACTION points in _ikke_ direction

2019-07-29 09:21:08 <maxice8> pr9716 can be closed, was merged
2019-07-29 09:50:11 <mps> will wiki pages be move gitlab.a.o in some near future
2019-07-29 09:50:29 <ncopa> i doubt
2019-07-29 09:50:35 <maxice8> to be done in a way similar to void-docs ?
2019-07-29 09:50:49 <ncopa> what does void-docs do?
2019-07-29 09:51:23 <maxice8> 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 <mps> GL wiki accept markdown, which is nice feature
2019-07-29 09:51:56 <ncopa> maxice8: ok, i understand
2019-07-29 09:52:05 <ncopa> yes, we will move some of the wiki docs over to gitlab
2019-07-29 09:52:13 <maxice8> 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 <ncopa> the official docs will be maintained in gitlab
2019-07-29 09:52:19 <ncopa> yes, exactly
2019-07-29 09:52:21 <ncopa> we will do that
2019-07-29 09:52:22 <maxice8> 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 <mps> github? https://www.zdnet.com/article/github-starts-blocking-developers-in-countries-facing-us-trade-sanctions/
2019-07-29 09:53:09 <ncopa> maxice8: that is somethign we can evaluate later i think
2019-07-29 09:53:21 <ncopa> lets get the official docs moved over first and we take it from there
2019-07-29 09:53:41 <mps> thanks to clandmeter's (hard) work we will not depend on GH
2019-07-29 09:53:42 <maxice8> alright
2019-07-29 09:53:59 <ncopa> mps: i dunno if thats for either #alpine-infra and/or #alpine-offtopic
2019-07-29 09:54:47 <ncopa> but yes, i think moving to gitlab, our own hosted, will pay off at some point
2019-07-29 09:55:10 <mps> 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 <mps> wanted to thank to clandmeter and _ikke_, and other who helped with move
2019-07-29 09:59:19 <ncopa> yeah, they did a good job
2019-07-29 09:59:25 <ncopa> are doing a good job
2019-07-29 10:01:21 <mps> 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 <ncopa> im not sure what to do with the kernels
2019-07-29 10:02:10 <mps> I see Cogitri just added iwd to default backend to NM, and iwd needs at least 4.20+
2019-07-29 10:02:15 <ncopa> i was thinking we could rename linux-vanilla to linux-lts
2019-07-29 10:02:31 <ncopa> but not sure its worth the job
2019-07-29 10:02:35 <Cogitri> mps; Eh?
2019-07-29 10:02:35 <Cogitri> No it doesn't
2019-07-29 10:03:01 <Cogitri> It needs 4.14+ IIRC
2019-07-29 10:03:02 <Cogitri> I've been using iwd w/ 4.19 for months now
2019-07-29 10:03:12 <mps> 'Rasmus Thomsen| community/networkmanager: enable iwd by default'
2019-07-29 10:03:32 <Cogitri> Yes, I enabled iwd by default but it doesn't need >=4.20
2019-07-29 10:03:47 <mps> for EAP it needs at least 4.20, iirc
2019-07-29 10:03:56 <Cogitri> <ncopa "i was thinking we could rename l"> And introduce non-lts kernels?
2019-07-29 10:04:21 <ncopa> that was the idea yes
2019-07-29 10:04:29 <PureTryOut[m]> Even if not introducting non-lts kernels, I personally find linux-lts more descriptive of what it is
2019-07-29 10:04:30 <ncopa> but the problem is 3rd party modules
2019-07-29 10:04:42 <ncopa> PureTryOut[m]: yes
2019-07-29 10:04:43 <Cogitri> 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 <mps> I agree with ncopa about this, is it worth to have separate kernels?
2019-07-29 10:04:55 <Cogitri> +1 PureTryOut
2019-07-29 10:05:10 <ncopa> mps: that is the question
2019-07-29 10:05:30 <ncopa> we do need separate kernels, the question is how many different kernels we are able to support
2019-07-29 10:05:37 <mps> I think it is good as it is now
2019-07-29 10:05:56 <PureTryOut[m]> 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 <mps> just wanted you have it on radar, as I have it
2019-07-29 10:06:19 <ncopa> it will be more work regardles if we use dkms or not
2019-07-29 10:07:20 <mps> 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 <mps> pmOS people will be happy I think (hi PureTryOut[m] :-) )
2019-07-29 10:10:23 <mps> 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 <Cogitri> 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 <Cogitri> But it would mean that we'd pull in C dev tools which is unfortunate
2019-07-29 10:14:01 <ncopa> i think we need to build 3rd pary modules packages for lts kernels
2019-07-29 10:14:09 <ncopa> at least some of them
2019-07-29 10:14:38 <ncopa> but we may want add support for dkms for the non-lts variant if we add that
2019-07-29 10:15:04 <ncopa> in any case, thats not something im gonna work on today or this week
2019-07-29 10:16:01 <PureTryOut[m]> On pmOS we have mainline and latest stable kernels packaged
2019-07-29 10:17:49 <mps> ncopa: ofc, this is not a one day or week work, it will need some time and thinking
2019-07-29 10:24:33 <ncopa> im also thinking that we should maybe have a desktop and server config
2019-07-29 10:24:43 <ncopa> i am atleast thinking of a headless kernel config
2019-07-29 10:24:58 <ncopa> for or cloud kernel config
2019-07-29 10:25:26 <ncopa> without audio, wifi and blutetooth drivers
2019-07-29 10:26:26 <Cogitri> Hm, is that really worth the effort when those modules aren't loaded anyway?
2019-07-29 10:26:38 <Cogitri> We might save like 10~20M worth of modules with that
2019-07-29 10:27:03 <mps> linux-virt extended? (shrinked maybe better term)
2019-07-29 10:33:12 <maxice8> 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 <maxice8> actually don't touch the last one just yet
2019-07-29 11:03:11 <maxice8> ok, the last one now is a security backport
2019-07-29 11:03:14 <maxice8> the other 4 can be merged safely
2019-07-29 11:32:37 <mps> maxice8: should the new testing/fmt be renamed to testing/fmt-libs
2019-07-29 11:33:48 <maxice8> no
2019-07-29 11:36:03 <mps> fmt-dev, maybe?
2019-07-29 11:37:46 <mps> 'fmt (formerly cppformat) is an open-source formatting library.' from https://fmt.dev/latest/index.html
2019-07-29 11:38:11 <mps> wouldn't it be confusing with 'fmt' utility
2019-07-29 11:52:18 <maxice8> maybe libfmt
2019-07-29 11:55:46 <mps> maybe this name is good
2019-07-29 11:56:25 <mps> we should start to follow some consistent naming for pkg's
2019-07-29 11:57:59 <maxice8> i don't see a problem with having <pkgname>-libs and lib<pkgname>
2019-07-29 12:08:03 <mps> also I don't, but 'fmt' for lib pkg is not good, imo
2019-07-29 12:21:28 <maxice8> 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 <mps> 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 <maxice8> i don't think there is a problem with that inconsistency
2019-07-29 12:32:59 <mps> it will appear if we are making mess in naming pkg's, sooner or later, I think
2019-07-29 12:58:52 <maxice8> What will appear
2019-07-29 13:07:05 <mps> problems as result of naming mess
2019-07-29 13:07:50 <maxice8> what kind of problems
2019-07-29 13:09:27 <mps> 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 <PureTryOut[m]> 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 <maxice8> Because there is another upstream project that is fmt
2019-07-29 13:11:23 <maxice8> once someone wants to package the second fmt, what do we do ?
2019-07-29 13:12:14 <PureTryOut[m]> Huh, what project?
2019-07-29 13:13:08 <mps> there is 'first come, first serve' rule, but this rule cannot be applied always and blindly
2019-07-29 13:14:32 <maxice8> oh no i understood it wrong
2019-07-29 13:14:46 <maxice8> i thought the fmt.dev thing that mps showed was another fmt
2019-07-29 13:14:47 <maxice8> 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 <mps> there is work (beginning) on this, http://ix.io/1PQ6
2019-07-29 13:15:15 <PureTryOut[m]> Exactly 😛
2019-07-29 13:16:17 <maxice8> 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 <maxice8> also brb
2019-07-29 13:16:33 <mps> maxice8: I addressed you in first msg about this because you commited testing/fmt
2019-07-29 13:17:52 <mps> 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 <maxice8> 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 <maxice8> I'd rather just follow upstream name like Void does, greatly avoids confusion.
2019-07-29 14:01:43 <Cogitri> +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 <mps> 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 <mps> _ikke_: you forgot perl- lua- ;-)
2019-07-29 14:06:29 <_ikke_> "and similar"
2019-07-29 14:08:01 <Cogitri> I'd opt for linux-lts so we can make linux the stable variants
2019-07-29 14:08:02 <PureTryOut[m]> +1
2019-07-29 14:08:31 <mps> (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 <Cogitri> That'd be consistent with other distros (like Arch) too
2019-07-29 14:29:11 <maxice8> _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 <maxice8> ncopa: libebml has been fixed
2019-07-29 15:01:52 <ncopa> maxice8: good! thanks
2019-07-29 15:02:34 <ncopa> re changing things, naming practices, coding style etc
2019-07-29 15:02:47 <ncopa> i have some thoughts around changing things in general
2019-07-29 15:03:35 <ncopa> as you may have noticed, I have always liked the BSDs and have deep respect for them
2019-07-29 15:04:10 <ncopa> we do stuff in alpine that has its roots in BSDs
2019-07-29 15:04:47 <ncopa> one of the things that I early wanted to accomplish with alpine
2019-07-29 15:04:57 <ncopa> or one of the early goals with alpine
2019-07-29 15:05:15 <ncopa> was to provide some sort of stability
2019-07-29 15:06:09 <ncopa> thats one of the ideas behind the name alpine and mountains: rock solid, stable
2019-07-29 15:06:18 <ncopa> that is also why we provide stable branches
2019-07-29 15:06:28 <ncopa> lots of work, but it gives stability
2019-07-29 15:06:52 <ncopa> BSD have been pretty good at that, compared to linux - in general
2019-07-29 15:07:21 <ncopa> for example, years ago there was hotplug scripts via /proc/sys/kernel/hotplug
2019-07-29 15:07:25 <ncopa> then there was udev
2019-07-29 15:07:35 <ncopa> then there was systemd
2019-07-29 15:07:48 <ncopa> and users had to adapt to changes all the time
2019-07-29 15:08:05 <ncopa> once there was dnotify, then there was inotify
2019-07-29 15:08:38 <ncopa> once there was sys v boot scripts, then there was upstart then there was systemd
2019-07-29 15:08:55 <ncopa> there was constant changes
2019-07-29 15:09:34 <ncopa> thats one of the things i have always liked with BSDs: they dont have that constant changes
2019-07-29 15:10:02 <ncopa> now, no changes is not good either
2019-07-29 15:10:16 <ncopa> you need to be able to break things once in a while to make progress
2019-07-29 15:10:28 <ncopa> but changes always comes with a price
2019-07-29 15:10:38 <ncopa> even rename packages comes with a price
2019-07-29 15:12:07 <ncopa> 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 <ncopa> if package is renamed, that list needs to be updated too
2019-07-29 15:13:07 <ncopa> users have often similar scripts
2019-07-29 15:13:17 <ncopa> apk add $list_of_packages
2019-07-29 15:13:38 <ncopa> we try to be backwards compat by adding provides etc
2019-07-29 15:14:23 <ncopa> but there is always risk that something breaks for someone in unexpected ways
2019-07-29 15:14:49 <ncopa> when something breaks, it costs time of the user
2019-07-29 15:15:02 <ncopa> they maybe report it upstream
2019-07-29 15:15:12 <ncopa> and we need to spend time on reading the bug report and respond to it
2019-07-29 15:15:21 <ncopa> so it cost time for us also
2019-07-29 15:15:58 <ncopa> my point here is that if we do a change, it should be worth the cost
2019-07-29 15:16:55 <ncopa> 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 <ncopa> so we will not rename lots of packages just because some dev likes those names better
2019-07-29 15:18:15 <ncopa> nor will we rewrite 1000+ APKBUILDs to have a new coding style that some new dev like better
2019-07-29 15:18:58 <ncopa> 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 <ncopa> i think this is pretty good: http://ix.io/1PQ6
2019-07-29 15:19:33 <ncopa> 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 <ncopa> you mean source="http://example.com/$pkgname-$pkgver.tar.gz"
2019-07-29 15:20:29 <_ikke_> yes
2019-07-29 15:20:50 <ncopa> 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 <ncopa> personally i prefer the latter
2019-07-29 15:21:42 <_ikke_> Right
2019-07-29 15:22:08 <ncopa> 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 <ncopa> yes
2019-07-29 15:23:12 <ncopa> i agree
2019-07-29 15:23:25 <ncopa> 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 <ncopa> and i think _pkgname is a bad variable name for upstream_name
2019-07-29 15:24:00 <mps> 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 <ncopa> i normally use example-$pkgver
2019-07-29 15:24:56 <ncopa> the argument against my practice is DRY
2019-07-29 15:25:03 <maxice8> 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 <ncopa> _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 <ncopa> yes
2019-07-29 15:26:14 <maxice8> yes _upstreamname is the most explicit but too long
2019-07-29 15:26:32 <ncopa> _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 <ncopa> also
2019-07-29 15:27:18 <ncopa> in thinngs like: source=http://example.com/foobar/foobar-$pkgver.gz
2019-07-29 15:27:42 <ncopa> if pkgname=foobar and you do source=http://example.com/$pkgname/$pkgname-$pkgver.gz
2019-07-29 15:27:57 <ncopa> then you cannot copy paste it to find new version
2019-07-29 15:28:16 <ncopa> i often mark the http://example.com/foobar/ with mouse and paste into browser
2019-07-29 15:28:32 <ncopa> but if $pkgname is there, it breaks stuff
2019-07-29 15:28:44 <ncopa> i mean it breaks the copy/paste operation
2019-07-29 15:29:06 <ncopa> so yeah, i think we should only use $pkgname where it makes sense
2019-07-29 15:29:14 <ncopa> not everywhere
2019-07-29 15:29:41 <ncopa> and i think we can use the litteral value instead of a variable name in most cases
2019-07-29 15:29:57 <ncopa> its not very often it makes sense to use a variable for it imho
2019-07-29 15:30:45 <ncopa> upstreamversion or proejctversion is other thing
2019-07-29 15:31:06 <ncopa> thats often useful to have a variable for
2019-07-29 15:37:58 <Cogitri> <ncopa "and i think we can use the litte"> Yup, sounds good to mw
2019-07-29 15:38:45 <maxice8> i prefer having a _upstream= variable
2019-07-29 15:38:52 <maxice8> makes it easier in case upstream itself renames
2019-07-29 15:44:18 <ncopa> they dont often rename upstream, and when they do, a search/replace is relatively simple to do
2019-07-29 15:47:10 <maxice8> 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 <ncopa> so, as you understand, i want prevent meaningless changes
2019-07-29 15:53:41 <ncopa> and when we do changes, i want those to be well thought through
2019-07-29 15:53:50 <ncopa> so we dont need to change soon again
2019-07-29 15:55:04 <ncopa> but at the same time, im not in the "if it aint broke, dont fix it" camp either
2019-07-29 15:55:24 <ncopa> i think we should be able to do changes and breaking changes once in a while
2019-07-29 15:55:38 <Cogitri> Nice
2019-07-29 15:55:45 <ncopa> but we should try keep the number of breaking changes down
2019-07-29 15:57:07 <ncopa> and when we do breaking changes, we should have good reasons
2019-07-29 16:00:40 <mps> 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 <maxice8> mps: That won't make a difference when upgrading from my view
2019-07-29 16:02:06 <mps> you'll have two lines changed
2019-07-29 16:02:08 <maxice8> 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 <mps> ah ok, looks like i misread original msg
2019-07-29 16:03:14 <maxice8> which 2 lines ?
2019-07-29 16:03:25 <ncopa> pkgver should always be variable
2019-07-29 16:03:29 <ncopa> never litteral
2019-07-29 16:03:37 <mps> pkgver and source, sorry for misread
2019-07-29 16:04:03 <ncopa> pkgname can be litteral mostly imho
2019-07-29 16:04:26 <Cogitri> Yup, since that's not changed nearly as often as pkgver is
2019-07-29 16:04:38 <maxice8> So we are taking the Void route :D
2019-07-29 16:04:42 <mps> that makes sense to me
2019-07-29 16:04:53 <maxice8> Void also recommends using the written out name instead of $pkgname
2019-07-29 16:05:56 <mps> if something changes pkgname in source (path) it is good to have it in diff log
2019-07-29 16:07:34 <mps> 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 <mps> and we also have to strive to some consistency in naming, again where it makes sense
2019-07-29 16:10:38 <ncopa> maxice8: im glad its not just me who thinks that makes sense :)
2019-07-29 16:48:35 <maxice8> :D
2019-07-29 16:52:09 <maxice8> So, should abuild add support for parsing /usr/share/pkgconfig ?
2019-07-29 16:52:32 <ncopa> as you mentioned in private
2019-07-29 16:52:37 <ncopa> its arch specific
2019-07-29 16:52:38 <ncopa> so no
2019-07-29 16:52:51 <ncopa> lets use /usr/lib/pkgconfig
2019-07-29 16:53:49 <Cogitri> Should we maybe automatically move that then?
2019-07-29 16:55:08 <kaniini> hmm
2019-07-29 16:55:24 <kaniini> it should parse the entire PKG_CONFIG_PATH
2019-07-29 16:58:54 <ncopa> which is unset by default
2019-07-29 16:58:58 <ncopa> but yes, good point
2019-07-29 16:59:24 <maxice8> @ncopa libebml escaped on 3.10
2019-07-29 17:01:02 <ncopa> maxice8: it needs changes
2019-07-29 17:01:07 <ncopa> i can fix it for you
2019-07-29 17:01:56 <maxice8> ah ok, ty
2019-07-29 17:03:49 <ncopa> maxice8: kaniini is right, abuild should parse entire PKG_CONFIG_PATH
2019-07-29 17:04:12 <kaniini> ncopa: yes, but you can ask pkgconf for the default path
2019-07-29 17:05:23 <kaniini> kaniini@localhost:~$ pkgconf --variable=pc_path pkg-config
2019-07-29 17:05:23 <kaniini> /usr/lib64/pkgconfig:/usr/share/pkgconfig
2019-07-29 17:06:41 <maxice8> got /usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
2019-07-29 17:06:41 <maxice8> here
2019-07-29 17:09:11 <kaniini> yeah
2019-07-29 17:09:19 <kaniini> i'm using fedora on my laptop ;)
2019-07-29 17:09:44 <maxice8> well the local ones certainly should be ignored
2019-07-29 17:10:36 <kaniini> the local ones are irrelevant in an abuild environment
2019-07-29 17:10:52 <kaniini> because you should be using buildlab or abuild rootbld to build in a container
2019-07-29 17:14:05 <maxice8> yes that is why they should be ignored
2019-07-29 17:15:11 <kaniini> well filtering them out is trivial
2019-07-29 17:15:37 <maxice8> yes
2019-07-29 17:37:02 <danieli> I'm gonna have another look at elixir tomorrow, I need 1.9 for some stuff
2019-07-29 17:58:41 <maxice8> @ncopa i did a blind patch for /usr/share/pkgconfig support
2019-07-29 17:58:42 <maxice8> i'll do a few tests now
2019-07-29 18:05:37 <maxice8> ncopa: the last commit on abuild is broken D:
2019-07-29 18:07:09 <maxice8> ok the patch works! :D
2019-07-29 18:10:02 <maxice8> ncopa: https://github.com/alpinelinux/abuild/pull/99
2019-07-29 18:38:15 <maxice8> _ikke_: 18.4 of atools is out
2019-07-29 18:39:34 <_ikke_> alright
2019-07-29 18:40:02 <maxice8> 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 <maxice8> I got a pr for adding support for parsing pkg-config files in /usr/share/pkgconfig
2019-07-29 19:29:19 <maxice8> should we also move /usr/share/cmake files to _dev ?
2019-07-29 19:54:57 <maxice8> 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 <maxice8> yes
2019-07-29 19:58:13 <artok> deprecating or removing?
2019-07-29 19:59:31 <maxice8> 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 <maxice8> it happens to all mails and doesn't happen to others
2019-07-29 20:30:42 <maxice8> 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 <maxice8> PureTryOut: I can't push to main, is it ok if i move utmps to community now ?
2019-07-30 05:56:06 <maxice8> ncopa: good morning
2019-07-30 07:09:23 <ncopa> morning
2019-07-30 07:11:24 <ncopa> maxice8: i saw you updated osinfo-db
2019-07-30 07:11:40 <ncopa> reminds me that we should upstream the alpine data to osinfo-db
2019-07-30 07:26:05 <maxice8> eh, too much work
2019-07-30 07:28:43 <PureTryOut[m]> Lol
2019-07-30 08:10:51 <maxice8> Got pr9773 to pr9777 as secfixes for main/redis
2019-07-30 09:12:18 <ncopa> Cogitri: what is the status of pr9353?
2019-07-30 09:12:25 <ncopa> can it be merged as is?
2019-07-30 09:13:38 <maxice8> No, currently work in progress
2019-07-30 10:46:40 <Cogitri> 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 <ncopa> great!
2019-07-30 20:33:21 <PureTryOut[m]> 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 <maxice8> _ikke_: new atools is out
2019-07-31 01:03:38 <danieli> pr9787 is good to go
2019-07-31 07:11:27 <maxice8> uh that openjdk to 3.9 backport is failing hard
2019-07-31 07:12:28 <maxice8> PureTryOut: the patches you are sending don't appear in the patches section, only in the archives.
2019-07-31 07:23:27 <PureTryOut[m]> Uhm ok, so what can I do about it? CC ddevault
2019-07-31 07:30:04 <kiwi100> 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 <mps> 'git tag --list' in aports tree
2019-07-31 07:33:51 <mps> or look https://git.alpinelinux.org/aports/
2019-07-31 07:34:04 <kiwi100> ah ok, v3.10 is shown after v.3.1.4 not in the end...
2019-07-31 07:34:14 <kiwi100> thank you!
2019-07-31 07:35:01 <mps> alphabetical order, not numeric
2019-07-31 08:52:17 <kiwi100> do you know how much disk space (approx.) do I need to compile new kernel?
2019-07-31 08:52:56 <mps> 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 <maxice8> So you're gonna stop using it? :D
2019-07-31 08:56:00 <mps> 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 <mps> maxice8: no, just kidding
2019-07-31 08:56:31 <mps> it is nice add-on
2019-07-31 08:56:43 <maxice8> mps: good good :D
2019-07-31 09:05:31 <mps> maxice8: thanks for making it :-)
2019-07-31 09:12:09 <maxice8> @ncopa the erlang and elixir commits had the wrong title D:
2019-07-31 09:13:36 <ncopa> oh...
2019-07-31 09:13:48 <ncopa> i just saw the "is good to go"....
2019-07-31 09:22:00 <PureTryOut[m]> maxice8: seems you only pushed half of my Kodi patched
2019-07-31 09:22:01 <PureTryOut[m]> *patches
2019-07-31 09:22:16 <maxice8> it is a work in progress
2019-07-31 09:24:37 <maxice8> _ikke_: ping
2019-07-31 09:27:55 <maxice8> ncopa: you got bamboozled
2019-07-31 09:30:06 <PureTryOut[m]> A work in progress?
2019-07-31 09:30:16 <maxice8> yes
2019-07-31 09:41:25 <PureTryOut[m]> I'm not sure what you mean...
2019-07-31 09:41:34 <maxice8> i'm still working on merging it
2019-07-31 09:41:53 <PureTryOut[m]> Uh...
2019-07-31 09:57:35 <maxice8> _ikke_: new atools
2019-07-31 10:01:59 <maxice8> PureTryOut: Turns out Kodi is a big package while fstrcmp and fmt are not :D
2019-07-31 10:47:01 <PureTryOut[m]> Well, yeah, but I'm not sure what you have to do besides merging my commit lol
2019-07-31 10:47:50 <maxice8> Compile and do the least basic of testing
2019-07-31 10:57:00 <PureTryOut[m]> Ah. Yeah if you're compiling it yourself, then it'll take a while lol
2019-07-31 10:57:32 <mps> maxice8: +1^(2^8)
2019-07-31 10:57:54 <maxice8> mps: ?
2019-07-31 11:14:35 <maxice8> kodi-x11 failed to link due to exhausting my notebook's memory
2019-07-31 11:30:13 <ddevault> PureTryOut[m]: can you share the patch link with me?
2019-07-31 11:35:51 <mps> maxice8: 1 plus raised to 256 :)
2019-07-31 11:36:20 <mps> which is still 1 but you understand
2019-07-31 12:39:22 <PureTryOut[m]> ddevault: https://lists.alpinelinux.org/~alpine/aports/%3C20190730224552.19614-4-bribbers%40disroot.org%3E
2019-07-31 12:39:41 <ddevault> thanks
2019-07-31 12:39:49 <ddevault> I think this hit the same libgit2 bug for which a fix was merged last week
2019-07-31 12:39:54 <ddevault> should resolve itself once the new libgit2 release ships
2019-07-31 12:40:31 <PureTryOut[m]> Ah cool
2019-07-31 13:08:44 <_ikke_> maxice8: I'll look at it tonight
2019-07-31 17:23:53 <vk496> Hello
2019-07-31 17:24:42 <vk496> 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 <vk496> oh, github. Nice!
2019-07-31 17:27:19 <vk496> 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 <maxice8> It is possible
2019-07-31 17:27:48 <maxice8> _ikke_: my main repo is on gitlab
2019-07-31 17:27:59 <maxice8> Bug gitlab hosted by alpine can't do public repos
2019-07-31 17:28:07 <maxice8> 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 <maxice8> _ikke_: letter is for minor letter
2019-07-31 17:28:59 <maxice8> a A
2019-07-31 17:29:02 <_ikke_> It uses the same test
2019-07-31 17:29:17 <maxice8> :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 <maxice8> 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 <maxice8> Nice
2019-07-31 17:51:49 <vk496> Done :P
2019-07-31 17:51:51 <vk496> https://github.com/alpinelinux/aports/pull/9798
2019-07-31 18:38:05 <danieli> is the s390x edge builder stuck?
2019-07-31 18:38:30 <danieli> looks like it might just be busy
2019-07-31 18:42:22 <maxice8> no, s390x is on minio for a long time
2019-07-31 19:06:13 <danieli> ping pong tmhoang
2019-07-31 19:18:23 <clandmeter> killed it
2019-07-31 19:18:45 <_ikke_> murderer
2019-07-31 20:16:22 <clandmeter> danieli: is there any way with pip to build native extensions with all threads?
2019-07-31 20:18:03 <clandmeter> _ikke_: ^ ?
2019-07-31 20:18:17 <danieli> not sure, let me check
2019-07-31 20:18:27 <danieli> clandmeter: try `pip install --install-option="--jobs=6"'?
2019-07-31 20:18:33 <clandmeter> if its using make it could
2019-07-31 20:18:38 <clandmeter> i think i tried that
2019-07-31 20:18:39 <clandmeter> and it failed
2019-07-31 20:18:40 <danieli> yeah, you could wrap make for instance
2019-07-31 20:18:51 <clandmeter> i can try it again
2019-07-31 20:19:17 <danieli> if it didn't work it probably won't do much
2019-07-31 20:19:52 <danieli> could you pass make flags to make through setup.py?
2019-07-31 20:20:06 <clandmeter> i dont think its running make
2019-07-31 20:20:10 <clandmeter> esle i can set makefilags
2019-07-31 20:20:18 <danieli> gotcha. got the source so I can test?
2019-07-31 20:20:23 <clandmeter> pikepdf
2019-07-31 20:20:34 <danieli> as it is in our repos?
2019-07-31 20:20:43 <danieli> hm, we don't haev it
2019-07-31 20:20:44 <danieli> have*
2019-07-31 20:20:44 <clandmeter> dont think we have it
2019-07-31 20:20:51 <danieli> can I have the apkbuild?
2019-07-31 20:20:58 <clandmeter> its pip
2019-07-31 20:21:08 <danieli> aaah just installing it, gotcha
2019-07-31 20:21:13 <clandmeter> no apkbuild involved
2019-07-31 20:21:28 <clandmeter> building a dockerfile
2019-07-31 20:21:31 <clandmeter> and i hate waiting :)
2019-07-31 20:21:50 <danieli> ha, yeah, I'm spoiled when it comes to parallel processing to
2019-07-31 20:21:51 <danieli> o
2019-07-31 20:29:13 <clandmeter> danieli: it passes the jobs to setuptools
2019-07-31 20:29:16 <clandmeter> which errors
2019-07-31 20:29:20 <danieli> I see
2019-07-31 20:31:39 <danieli> clandmeter: I'm gonna test something and I'll pass you a patch if it works
2019-07-31 20:31:49 <clandmeter> grazie
2019-07-31 20:33:37 <clandmeter> danieli: its not only pikepdf thats slow
2019-07-31 20:34:09 <clandmeter> pillow lxml... all are terrible on single thread
2019-07-31 20:37:53 <danieli> ah, darn it, it's not using make *at all*
2019-07-31 20:39:08 <danieli> aaah, I got it, I'm a dummy dum
2019-07-31 20:39:13 <danieli> clandmeter: set MAX_CONCURRENCY
2019-07-31 20:39:16 <KH405> 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 <danieli> it defailts to `min(4, cpu_count())'
2019-07-31 20:39:22 <KH405> I'm using Awesome
2019-07-31 20:39:27 <danieli> defaults(
2019-07-31 20:39:48 <clandmeter> is that en env var?
2019-07-31 20:39:50 <danieli> KH405: I heard people encountered issues after a pango update, apparently freedesktop changed some things
2019-07-31 20:39:51 <danieli> clandmeter: yes
2019-07-31 20:39:58 <danieli> see mp_compile.py
2019-07-31 20:40:20 <KH405> danieli, Ok, so i'll just wait for a fix then ^^'
2019-07-31 20:40:35 <danieli> 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 <danieli> 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 <KH405> I never really did that, and don't remember at all what updated ^^'
2019-07-31 20:41:34 <KH405> I can try
2019-07-31 20:42:50 <KH405> But yeah, made my GUI completly unusable, so I guess it's a pretty huge issue :P
2019-07-31 20:43:02 <KH405> Do you know if it's happening with other DE/WM ?
2019-07-31 20:43:04 <danieli> it screwed over i3 too
2019-07-31 20:43:11 <danieli> it uses pango and it broke for people
2019-07-31 20:43:27 <clandmeter> danieli: still only seeing a single gcc process
2019-07-31 20:43:50 <danieli> 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 <clandmeter> but you are installing it directly or as a dep?
2019-07-31 20:44:21 <clandmeter> try install ocrmypdf
2019-07-31 20:44:50 <danieli> installed it directly
2019-07-31 20:45:55 <clandmeter> i must be holding it wrong
2019-07-31 20:46:07 <danieli> it didn't build, just installed prebuilt wheel files
2019-07-31 20:46:12 <danieli> which OS are you on?
2019-07-31 20:46:17 <clandmeter> alpine ofc
2019-07-31 20:46:29 <danieli> right, there probably aren't prebuilts for alpine
2019-07-31 20:46:35 <danieli> I'm on Arch at the moment, I'll test in an Alpine container
2019-07-31 20:46:46 <clandmeter> i just use pip3  install ocrmypdf
2019-07-31 20:47:00 <clandmeter> and then its waiting for the sun to go down
2019-07-31 20:47:12 <clandmeter> or come up in this case
2019-07-31 20:47:39 <danieli> we have sun here :) 70°N does that
2019-07-31 20:47:58 <clandmeter> i can make a picture of a black sky :)
2019-07-31 20:48:13 <clandmeter> its just a black square probably
2019-07-31 21:01:25 <danieli> 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 <clandmeter> no problem mate
2019-07-31 21:02:49 <clandmeter> thx for checking
2019-07-31 21:04:42 <danieli> I know it's possible but it'll take some printf debugging and grepping