2019-05-01 00:40:50 <akjmicro> Hey, anybody here?
2019-05-01 00:49:06 <Cogitri> Sure
2019-05-01 00:49:12 <Cogitri> Oh well, he already left
2019-05-01 05:42:57 <north1> algitbot: that's spamm
2019-05-01 06:40:53 <fcolista> how is the -dbg subpackage created?
2019-05-01 06:41:28 <fcolista> Freeswitch is unable to create -dbg anymore, even with "!strip" option
2019-05-01 06:41:37 <fcolista> ncopa: do you want to review this? http://tpaste.us/ErZJ
2019-05-01 06:41:44 <fcolista> or clandmeter / _ikke_ ^
2019-05-01 06:43:26 <north1> fcolista: license is GPL which is not SPDX and is ambiguous
2019-05-01 06:43:47 <north1> the url is now a https:// redirect
2019-05-01 06:44:56 <north1> we now have a default_static() but i guess that is going to be backported ?
2019-05-01 07:14:14 <fcolista> i guess so
2019-05-01 07:15:47 <north1> Then yes better keep a static() definition
2019-05-01 07:15:58 <clandmeter> o/
2019-05-01 07:16:05 <north1> clandmeter: hi
2019-05-01 07:16:23 <clandmeter> fcolista: you got a log?
2019-05-01 07:16:23 <fcolista> reviewed: http://tpaste.us/0L4x
2019-05-01 07:16:38 <fcolista> clandmeter, log of what?
2019-05-01 07:16:52 <clandmeter> fs dbg
2019-05-01 07:17:16 <fcolista>  no
2019-05-01 07:17:19 <fcolista> wonder how to get it
2019-05-01 07:17:34 <clandmeter> ?
2019-05-01 07:17:58 <fcolista> this is the only "log" i have:
2019-05-01 07:17:59 <fcolista> >>> freeswitch-dbg*: Running split function dbg...
2019-05-01 07:17:59 <fcolista> >>> ERROR: freeswitch*: prepare_subpackages failed
2019-05-01 07:17:59 <fcolista> >>> ERROR: freeswitch: rootpkg failed
2019-05-01 07:17:59 <fcolista> >>> ERROR: freeswitch-dbg*: dbg failed
2019-05-01 07:18:16 <fcolista> if you are referring to another log, dunno which one you are referring to
2019-05-01 07:18:19 <clandmeter> run abuild with -v
2019-05-01 07:18:30 <clandmeter> and please use paste :)
2019-05-01 07:18:39 <clandmeter> it will be much more verbose
2019-05-01 07:18:45 <tcely> fcolista: upgrade abuild
2019-05-01 07:18:56 <fcolista> i did it already
2019-05-01 07:19:11 <fcolista> clandmeter, running build -vr
2019-05-01 07:19:14 <fcolista> *abuild
2019-05-01 07:19:30 <fcolista> will take a while
2019-05-01 07:29:38 <fcolista> nice
2019-05-01 07:29:41 <fcolista> it worked
2019-05-01 07:29:53 <fcolista> -dbg has been built
2019-05-01 07:30:29 <fcolista> sicne is the latest abuild version, should i remove the static() function since there is default_static() now ?
2019-05-01 07:30:45 <fcolista> abuild-3.4.0_rc3-r0
2019-05-01 07:30:49 <north1> only if you don't plan on backporting it i guess
2019-05-01 07:31:22 <fcolista> I don't plan to backport it
2019-05-01 07:31:31 <north1> Feel free to remove it then
2019-05-01 07:32:25 <fcolista> running again without static()
2019-05-01 08:23:55 <Cogitri> What's alpine's policy on requiring SSE2 on i686?
2019-05-01 08:24:05 <Cogitri> Latest webkit-gtk needs it
2019-05-01 08:39:32 <fcolista> ok, all seems fine.
2019-05-01 08:39:33 <fcolista> http://tpaste.us/aRNB
2019-05-01 08:39:40 <fcolista> Moving FS to community then
2019-05-01 08:52:14 <north1> I got into making openjpeg have tests
2019-05-01 08:52:26 <north1> fetching openjpeg-data
2019-05-01 08:53:55 <north1> just 474MB
2019-05-01 09:00:57 <mps> north1: huh, just :)
2019-05-01 09:01:21 <north1> At the same time i didn't expect to be this big and expected it to be bigger
2019-05-01 09:07:24 <ncopa> is there a smaller, simpler test suite we could use?
2019-05-01 09:07:56 <north1> ncopa: nope, doing -DBUILD_TESTING will require OPJ-DATA
2019-05-01 09:08:34 <north1> idk if you manage to make a ctest (cmake test tool) invocation that uses only the first 120 or so tests
2019-05-01 09:08:36 <north1> they will work
2019-05-01 09:08:44 <north1> the rest of the 1200+ testsuite require OPJ-DATA
2019-05-01 09:09:29 <north1> 99% tests passed, 2 tests failed out of 1481
2019-05-01 09:09:30 <north1> Total Test time (real) = 157.52 sec
2019-05-01 09:10:37 <ncopa> Cogitri: we don't have any written policy, but we have previously enabled cpu specific features
2019-05-01 09:11:15 <ncopa> Cogitri: for example chromium required some armv7 instructions to compile. at the time we only had armhf (armv6)
2019-05-01 09:11:32 <ncopa> but we enabled it for armhf
2019-05-01 09:11:45 <ncopa> which meant that chromium wouldn't work on rpi 1
2019-05-01 09:12:08 <ncopa> I guess we could do something similar with SSE2 on i686 and webkitgtk
2019-05-01 09:12:22 <Cogitri> Alright, thanks for the info. I guess having sse2 enabled isn't *that* terrible anyway since it's a thing for so long already
2019-05-01 09:12:43 <ncopa> Cogitri: yes
2019-05-01 09:13:01 <ncopa> fcolista: i think we may want keep freeswitch in main
2019-05-01 09:13:28 <fcolista> ncopa, yeah, it's better. We want support  for it
2019-05-01 09:13:36 <fcolista> for longer time
2019-05-01 09:13:53 <ncopa> i think it is one of the packages we need support for longer time yes
2019-05-01 09:14:03 <fcolista> ok, so we need to move some pkgs in main.
2019-05-01 09:14:17 <ncopa> fcolista: sorry for late response
2019-05-01 09:14:22 <fcolista> np
2019-05-01 09:23:16 <north1> Even debian disables the tests
2019-05-01 09:34:07 <north1> ^ How do you answer this ?
2019-05-01 09:34:42 <_ikke_> Please provide your details so we can send you an invoice
2019-05-01 09:35:17 <north1> genuinely curious
2019-05-01 09:35:29 <north1> on Void i just close and tell them that PRs are welcome for updating packages thy need updated
2019-05-01 09:57:19 <fcolista> ncopa, mod_sangoma is included in freeswitch
2019-05-01 09:57:39 <fcolista> we don't need sngtc_client anymore
2019-05-01 09:58:58 <fcolista> https://dpaste.de/2bFQ
2019-05-01 10:20:31 <Cogitri> Yay, GNOME works now! Does someone here happen to know PAM config?
2019-05-01 12:45:23 <fcolista> can someone help me with this? http://tpaste.us/qKWy
2019-05-01 12:45:42 <fcolista> FS fails to build sangoma with the latest sngtc_client
2019-05-01 12:45:53 <fcolista> cannot find -lsngtc_node
2019-05-01 13:14:06 <ncopa> fcolista: was sngtc_client updated?
2019-05-01 13:14:17 <fcolista> correct
2019-05-01 13:14:21 <fcolista> 1.3.9
2019-05-01 13:14:40 <ncopa> but not pushed?
2019-05-01 13:14:54 <fcolista> not pushed
2019-05-01 13:14:59 <fcolista> my local repo is using it
2019-05-01 13:15:08 <ncopa> can you git format-patch --stdout -1 $hash | tpaste
2019-05-01 13:15:17 <ncopa> so will i build it here
2019-05-01 13:16:36 <fcolista> http://tpaste.us/xpLQ
2019-05-01 13:17:16 <fcolista> this dooes not include FS
2019-05-01 13:18:09 <fcolista> http://tpaste.us/yPl8 <-- this includes FS
2019-05-01 13:18:29 <ncopa> sngtc_client.c:1880:3: error: too many arguments to function 'ortp_set_log_level_mask'
2019-05-01 13:18:29 <ncopa>    ortp_set_log_level_mask(NULL, ORTP_WARNING|ORTP_ERROR|ORTP_FATAL);
2019-05-01 13:18:44 <ncopa> do you have ortp update too?
2019-05-01 13:18:49 <fcolista> yes :)
2019-05-01 13:19:06 <fcolista> ok
2019-05-01 13:19:22 <fcolista> You need -5 rather than -1 :)
2019-05-01 13:19:30 <ncopa> ok
2019-05-01 13:19:32 <ncopa> hit me
2019-05-01 13:20:41 <fcolista> http://tpaste.us/YM1e
2019-05-01 13:22:07 <ncopa> can you in the commit message to mbedtls have a short line telling why it is moved to main?
2019-05-01 13:22:18 <ncopa> "needed by ortp which is needed by freeswitch"
2019-05-01 13:22:21 <ncopa> or similar
2019-05-01 13:22:27 <fcolista> yes sure
2019-05-01 13:25:13 <ncopa> ortp gives me 404 when downloading source
2019-05-01 13:25:19 <ncopa> maybe use this? http://www.linphone.org/releases/sources/ortp/
2019-05-01 13:25:44 <fcolista> ok
2019-05-01 13:30:55 <ncopa> ok i know what the problem is
2019-05-01 13:31:01 <ncopa> but i dont know what the fix is :)
2019-05-01 13:32:20 <fcolista> :)
2019-05-01 13:32:23 <ncopa> fcolista: where did you get the ortp.patch from?
2019-05-01 13:32:28 <fcolista> I did it
2019-05-01 13:32:51 <fcolista> I went to ortp sources
2019-05-01 13:33:06 <fcolista> and saw the function ortp_set_log_level_mask requires one more arg
2019-05-01 13:35:24 <fcolista> looking at other patches using this function, I've set the first arg as NULL since it was not used from that "old" sngtc_client code
2019-05-01 13:36:22 <ncopa> ok
2019-05-01 13:36:39 <ncopa> the new arg is char *domain
2019-05-01 13:36:47 <ncopa> but docs does not explain what it is
2019-05-01 13:37:03 <ncopa> what about rtp_session_set_local_addr()?
2019-05-01 13:37:16 <ncopa> localport+1
2019-05-01 13:37:23 <fcolista> that one is old
2019-05-01 13:37:48 <fcolista> I've jus added the ortp_set_log_level part
2019-05-01 13:37:53 <ncopa> ok
2019-05-01 13:37:59 <fcolista> I've appened the patch since was related to ortp too
2019-05-01 13:38:19 <ncopa> probably good then
2019-05-01 13:39:04 <ncopa> so problem is that libsngtc_node.so is not a symlink pointing to a versioned library
2019-05-01 13:39:32 <ncopa> so it is not available when only libsngtc_client-dev is installed
2019-05-01 13:39:42 <fcolista> basically is missing libsngtc_node.so.$version > libsngtc_node.so
2019-05-01 13:39:49 <ncopa> exactly
2019-05-01 13:40:14 <ncopa> not sure if we bother mess with it
2019-05-01 13:40:15 <fcolista> that means that sngtc_client makefile is  wrong
2019-05-01 13:40:23 <ncopa> correct
2019-05-01 13:40:31 <ncopa> well
2019-05-01 13:40:33 <ncopa> "wrong"
2019-05-01 13:41:11 <ncopa> not sure we bother fix their release to do proper versioned library
2019-05-01 13:41:43 <ncopa> simple fix is to add: depends_dev="$pkgname-$pkgver-r$pkgrel"
2019-05-01 13:43:05 <ncopa> $ git diff . | tpaste
2019-05-01 13:43:05 <ncopa> http://tpaste.us/5wz7
2019-05-01 13:43:06 <fcolista> Probably we need to open a bug to their bugtracker, and put the link in FS APKBUILD
2019-05-01 13:43:37 <ncopa> given how they do their releases, i dont think they would care
2019-05-01 13:43:43 <fcolista> hehe
2019-05-01 13:43:51 <ncopa> they build binary packages and ship sources in there
2019-05-01 13:44:00 <fcolista> I think you are right..
2019-05-01 13:44:26 <fcolista> ncopa, now I understand why -depends_dev="$pkgname" was needed
2019-05-01 13:44:59 <ncopa> i wonder if we should provide a libsngtc-node subpackage
2019-05-01 13:45:05 <fcolista> It appeared to em a circular dependency
2019-05-01 13:45:08 <fcolista> *me
2019-05-01 13:45:13 <ncopa> probably not worth it
2019-05-01 13:45:37 <ncopa> this should be good enough: http://tpaste.us/5wz7
2019-05-01 13:46:00 <fcolista> soudns good
2019-05-01 13:46:04 <fcolista> applied.
2019-05-01 13:46:11 <fcolista> going to build fs now
2019-05-01 13:51:43 <ncopa> hum
2019-05-01 13:51:58 <ncopa> https://downloads.webmproject.org/releases/webp/libwebp-1.0.2.tar.gz
2019-05-01 13:52:03 <ncopa> cert failed
2019-05-01 13:54:35 <ncopa> wrong source url
2019-05-01 13:55:14 <TBK[m]> https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.0.2.tar.gz
2019-05-01 13:55:27 <ncopa> yup. i just found it thank
2019-05-01 13:58:39 <fcolista> ncaop, FS built without issue
2019-05-01 13:58:40 <fcolista> thx
2019-05-01 13:58:57 <ncopa> great! yw
2019-05-01 14:04:46 <TBK[m]> fcolista: $pkgname-$pkgver.tar.gz::https://github.com/BelledonneCommunications/ortp/archive/$pkgver.tar.gz
2019-05-01 14:11:55 <ncopa> s30x is giving me headache...
2019-05-01 14:11:59 <ncopa> s390x
2019-05-01 14:17:51 <tcely> ncopa: pr7201 Would you help me find the dependency problem you pointed out?
2019-05-01 14:28:48 <ncopa> maybe tomorrow
2019-05-01 14:29:19 <ncopa> tcely: its build time dependency
2019-05-01 14:29:24 <ncopa> how do you build python3?
2019-05-01 14:29:25 <Cogitri> Would be nice if more people could test pr7374 to make sure I don't break login for some with the linux-pam changes
2019-05-01 14:29:30 <ncopa> if python3 does not exist
2019-05-01 14:29:54 <ncopa> you will need py3-setuptools to build python3, which means you will need to build py3-setuptools before you build python3
2019-05-01 14:30:03 <ncopa> but you cannot build py3-setuptools if python3 does not existt
2019-05-01 14:30:14 <ncopa> gotta go
2019-05-01 14:32:28 <tcely> ncopa: ah. I see now. thanks.
2019-05-01 15:43:53 <_ikke_> Didn't know that abuild sanitycheck has built-in spdx licence validation (if you installed spdx-licenses)
2019-05-01 15:44:11 <SpaceToast> oh, that's nice
2019-05-01 15:45:17 <_ikke_> I was reading the code to see what it checked for and noticed it
2019-05-01 15:47:10 <north1> _ikke_: yes it is pretty nice
2019-05-01 15:48:11 <_ikke_> I just updated it to the latest version of spdx
2019-05-01 15:49:38 <SpaceToast> aha, full package name is spdx-licenses-list :)
2019-05-01 15:50:45 <_ikke_> Yeah, not sure why it's a subpackage
2019-05-01 15:52:11 <_ikke_> apparently because of all the different formats
2019-05-01 15:53:10 <SpaceToast> it's also in testing, looks like
2019-05-01 15:53:13 <_ikke_> yes
2019-05-01 15:53:27 <_ikke_> I plan to move it to either community, or even main (so that it could be part of alpine-sdk)
2019-05-01 15:54:37 <north1> https://github.com/alpinelinux/aports/pull/7469
2019-05-01 15:54:42 <north1> CI-malfunction please ^
2019-05-01 15:55:11 <_ikke_> done
2019-05-01 15:55:33 <north1> thank you
2019-05-01 15:58:05 <Cogitri> Could someone take a look at https://bugs.alpinelinux.org/issues/7374?
2019-05-01 15:58:42 <Cogitri> GNOME Terminal refuses to start if dbus has been started without an utf-8 locale
2019-05-01 16:03:05 <SpaceToast> north1: ncopa seems to prefer keeping "cd $builddir" and such around, even if they're not strictly necessary
2019-05-01 16:03:13 <SpaceToast> in case backporting to stable branches is needed and all
2019-05-01 16:03:45 <north1> SpaceToast: he asked to keep it in main/
2019-05-01 16:04:00 <SpaceToast> yeah, the main/ cycle is 2 years long
2019-05-01 16:04:05 <SpaceToast> the community one is 6 months
2019-05-01 16:04:15 <SpaceToast> I wonder when that implicit cd was added
2019-05-01 16:04:52 <SpaceToast> and yeah, my bad, I somehow assumed alsa-plugins would be in main
2019-05-01 16:05:02 <north1> https://github.com/alpinelinux/abuild/commit/2fe29d5829c0973ace1db350141b3c810ac888a7
2019-05-01 16:05:02 <north1> October 3 2018
2019-05-01 16:05:06 <north1> SpaceToast: no worries
2019-05-01 17:19:40 <mps> _ikke_: idea about adding spdx-licenses-list and integrate it with sanitycheck is nice, imo
2019-05-01 17:20:22 <_ikke_> mps: It's already there
2019-05-01 17:21:08 <mps> i meant to say, integrated with alpine-sdk
2019-05-01 17:21:21 <_ikke_> Yes, that would be nice indeed
2019-05-01 17:21:47 <mps> i.o.w. to be pulled by alpine-sdk
2019-05-01 17:24:16 <north1> https://cloud.drone.io/alpinelinux/aports/2419/2/1 huh
2019-05-01 17:27:34 <_ikke_> strange indeed
2019-05-01 17:27:37 <_ikke_> lets try again
2019-05-01 17:30:19 <mps> north1: line 219 -- Package 'baseencode', required by 'virtual:world', not found
2019-05-01 17:30:39 <_ikke_> mps: yes, but its just built before, and on other arches it does work
2019-05-01 17:30:56 <north1> mps: the huh is because it works on some and not others
2019-05-01 17:30:58 <mps> maybe not uploaded ye
2019-05-01 17:31:17 <mps> s/ye/yet/
2019-05-01 17:31:17 <alpine-meetbot> mps meant to say: maybe not uploaded yet
2019-05-01 17:31:20 <_ikke_> it should be able to use just built packages
2019-05-01 17:31:22 <north1> it is in the same PR
2019-05-01 17:31:27 <_ikke_> and same repo
2019-05-01 17:32:04 <mps> how drone pulls deps? locally?
2019-05-01 17:32:36 <north1> randomly from my experience
2019-05-01 17:33:07 <_ikke_> abuild automatically adds just built packages to a local repo. It should use both local and remote packages
2019-05-01 17:34:04 <mps> it it's built and added to local repo why then it is not found
2019-05-01 17:34:20 <_ikke_> that's the question
2019-05-01 17:35:09 <mps> ime, if I built local pkg, and then build pkg which depends on it is pulled from local repo
2019-05-01 17:35:25 <_ikke_> yes, that's how it should work
2019-05-01 17:35:33 <_ikke_> and on some arches it does
2019-05-01 17:36:08 <mps> so, drone probably works differently
2019-05-01 17:38:02 <_ikke_> Hmm
2019-05-01 17:38:04 <_ikke_> I can repro it
2019-05-01 17:38:47 <_ikke_> mps: If you look at line 166, you see it gets installed
2019-05-01 17:41:15 <_ikke_> So somehow pkgconf cannot find the library
2019-05-01 17:41:50 <mps> ah, yes. I see. but lines 151 to 153 shows some errors
2019-05-01 17:43:27 <mps> are we sure it is correctly put in local repo. just asking, I don't have experience with drone
2019-05-01 17:43:52 <_ikke_> mps: it happens on my build container as well, so it's not drone related
2019-05-01 17:44:49 <mps> then i have no idea. btw, is this some kind of 'bundled' build
2019-05-01 17:45:13 <_ikke_> north1: Is libbaseencode-dev supposed to only contain a single header file?
2019-05-01 17:47:29 <north1> _ikke_: Nope, should have libcotp.so and cotp.pc
2019-05-01 17:48:11 <_ikke_> That's the issue then
2019-05-01 17:48:15 <_ikke_> it doesn't get built properly
2019-05-01 17:48:40 <_ikke_> apk info -L libbaseencode-dev
2019-05-01 17:48:42 <_ikke_> http://tpaste.us/vbqW
2019-05-01 17:50:16 <north1> ok added -DCMAKE_INSTALL_LIBDIR=lib to it
2019-05-01 17:52:06 <mps> need advice. should I add myself as contributor to pkg which I upgraded, fixed, tested posted patches, for the last three upstream releases
2019-05-01 17:52:46 <north1> zbar-dev is missing on aarch64
2019-05-01 17:52:49 <mps> original maintainer is active but not on ML or IRC
2019-05-01 17:52:53 <north1> x86_64 is fixed
2019-05-01 17:53:07 <_ikke_> mps: your choice. in principle the git history contains a record of who contributed to the package
2019-05-01 17:56:15 <mps> I know, but I don't like to ignore contribution done by original maintainer and to make him feel uncomfortable by removing him or taking maintainership, just thought to add myself as contributor
2019-05-01 17:56:29 <_ikke_> north1: ah, I see, it installs them in lib64
2019-05-01 18:15:43 <iggy> mps: I would think maintainer = who to contact today if there's a problem ; contributor = people that might have some knowledge of said package
2019-05-01 18:16:45 <tcely> +1
2019-05-01 18:17:23 <tcely> mps: If your are doing the work, ask the current maintainer they probably don't care if you take over
2019-05-01 18:17:23 <mps> iggy: yes, but pkg about i talk and its current maintainer are in some 'special' status
2019-05-01 18:18:03 <mps> there were some disputes about this some time ago
2019-05-01 18:20:40 <mps> tcely: maintainer is here but he doesn't speak here, uff, cumbersome situation. I will add myself as contributor for now and see what to do in future
2019-05-01 19:28:54 <tcely> For anyone else using a MacBook I compiled the aports-ghpr for darwin, you can get it from: http://tpaste.us/7vz1
2019-05-01 19:56:25 <_ikke_> How to deal with a project where there is a custom license and can only be found as a header in a source file?
2019-05-01 19:56:40 <_ikke_> (reference: https://github.com/alpinelinux/aports/pull/7424/files)
2019-05-01 19:57:01 <north1> in Void we do sed -n 'N,Np' > LICENSE
2019-05-01 19:57:12 <north1> then vlicense LICENSE
2019-05-01 19:57:27 <_ikke_> what does that last part do?
2019-05-01 19:57:59 <north1> That is just void-specific for install -Dm0644 LICENSE -t /usr/share/licenses/$pkgname
2019-05-01 19:58:13 <_ikke_> right
2019-05-01 19:58:36 <north1> would be nice to have something like vmove
2019-05-01 21:32:28 <north1> https://github.com/alpinelinux/aports/pull/7478 needs CI-malfunction, qt5-qtwebengine breaks the time limit on CI
2019-05-01 21:44:03 <tcely> north1: done
2019-05-01 21:45:04 <north1> Thank you
2019-05-01 22:32:28 <otlabs> hi ppl
2019-05-01 22:32:49 <TBK[m]> hi
2019-05-01 22:33:08 <otlabs> _ikke_ and tcely: thank you for reviewing my PR. I have implemented all you suggestions.
2019-05-01 22:33:17 <otlabs> TBK[m]: greetings!
2019-05-01 22:47:39 <north1> Is there a way to get a rss feed of the flagged packages from pkgs.a.o ?
2019-05-01 22:59:29 <TBK[m]> maxice8: Don't think so. Can't find any mention of rss in the src - https://github.com/alpinelinux/aports-turbo
2019-05-02 04:59:40 <_ikke_> Cogitri: ping
2019-05-02 05:00:40 <Cogitri> ikke: pong
2019-05-02 05:00:47 <Cogitri> Also, morning :)
2019-05-02 05:01:02 <_ikke_> morning (or whatever is relevant for your timezone)
2019-05-02 05:01:25 <north1> 07:00 AM so yes, morning
2019-05-02 05:01:27 <_ikke_> You tagged @timbru31 on pr7483, should he review it before merging?
2019-05-02 05:01:42 <north1> _ikke_: It is relevant for his Firefox PR
2019-05-02 05:01:55 <_ikke_> alright
2019-05-02 05:02:08 <north1> while not strictly required (you can just do cargo install), it is nice to use system packages during the build process
2019-05-02 05:04:16 <_ikke_> Just wanted to be sure
2019-05-02 06:47:59 <north1> https://github.com/alpinelinux/aports/pull/7485
2019-05-02 06:48:06 <north1> apparently CI can't handle cmd:iwlist
2019-05-02 06:54:31 <tcely> Check to make sure wireless-tools is the only thing providing cmd:iwlist
2019-05-02 06:54:53 <north1> apk search cmd:iwlist only returns it
2019-05-02 06:58:09 <tcely> Hmm. apk info -P wireless-tools
2019-05-02 06:58:09 <tcely> wireless-tools-30_pre9-r0 provides:
2019-05-02 06:59:31 <tcely> the wireless-tools from edge isn't providing that from what I can see
2019-05-02 06:59:54 <north1> wfm
2019-05-02 06:59:58 <north1> i am on edge
2019-05-02 07:00:27 <north1> http://ix.io/1HOs
2019-05-02 07:02:02 <tcely> I just spun up a docker container for edge and got the wireless-tools that doesn't provide anything
2019-05-02 07:02:16 <tcely> Maybe you want to bump that package and see if you get better results?
2019-05-02 07:02:41 <north1> ok i'll check it later
2019-05-02 07:02:53 <north1> currently dealing with packagin stuff for buku testing
2019-05-02 07:06:03 <clandmeter> abuild should automatically add them, but it looks like this pkg hasnt been rebuild since this feature has been added.
2019-05-02 07:06:04 <clandmeter> Build time	2014-03-25 22:28:20
2019-05-02 07:06:28 <north1> clandmeter: ohhhh
2019-05-02 07:06:42 <clandmeter> so in stable it will probably be working
2019-05-02 07:11:31 <clandmeter> north1: you can bump the dep and include it in the PR.
2019-05-02 07:11:47 <clandmeter> mention you want to rebuild it due to cmd feature
2019-05-02 07:14:21 <north1> clandmeter: will do, thanks
2019-05-02 07:15:24 <ncopa> morning
2019-05-02 07:15:38 <north1> Morning
2019-05-02 07:16:49 <Cogitri> Morning :)
2019-05-02 07:28:08 <north1> done
2019-05-02 08:18:11 <kr0k0> Hi guys
2019-05-02 08:20:35 <kr0k0> I want to modify/fix testing/vdr
2019-05-02 08:21:47 <kr0k0> Is it the standard way to build main app and all its plugins in one APKBUILD?
2019-05-02 08:22:18 <north1> yes, run the commands for building all the apps and all its plugin during build()
2019-05-02 08:22:58 <kr0k0> ok
2019-05-02 08:23:20 <kr0k0> My problem are the doc and lang packages.
2019-05-02 08:23:29 <north1> What about them ?
2019-05-02 08:23:36 <kr0k0> They have also the files of the plugins.
2019-05-02 08:23:53 <north1> please explain
2019-05-02 08:24:54 <Cogitri> kr0k0: You'll have to make manual doc() and lang() functions then
2019-05-02 08:25:19 <kr0k0> for example the path: "pkg/vdr-lang/usr/share/locale/nl_NL/LC_MESSAGES/" contains "vdr-epgsearch.mo vdr-hello.mo vdr.mo"
2019-05-02 08:25:38 <kr0k0> So, lang of vdr main package
2019-05-02 08:25:49 <kr0k0> And also of epgsearch and hello plugin
2019-05-02 08:26:01 <kr0k0> All this in vdr-lang package
2019-05-02 08:26:30 <tcely> how would you want it to be otherwise?
2019-05-02 08:26:45 <kr0k0> Cogitri: Yes, I have tried to add epgsearch-lang function, but that doesn't work for me
2019-05-02 08:27:00 <north1> kr0k0: well functions can't have dashes in them
2019-05-02 08:27:33 <kr0k0> I thought, that each plugin (package) should have it's own lang and doc package.
2019-05-02 08:27:43 <north1> you can do $pkgname-lang:_lang and have _lang() { default_lang ; do_other_stuff ; }
2019-05-02 08:28:05 <kr0k0> north1: that explains a lot ^^
2019-05-02 08:28:30 <tcely> kr0k0: you could split it up that much, but I don't see much of a point to doing that.
2019-05-02 08:28:50 <tcely> When you install docs they would all trigger via install_if too, correct?
2019-05-02 08:29:33 <kr0k0> tcely: Ok, so you would say it's ok to have all lang and doc files of main and all plugins in the package vdr-lang and vdr-doc?
2019-05-02 08:30:00 <tcely> yeah, I'm fine with that.
2019-05-02 08:30:59 <kr0k0> tcely: There is no install_if
2019-05-02 08:31:57 <tcely> https://github.com/alpinelinux/abuild/blob/f263cb9f49f3861f3141c22a74360b06cec7b868/abuild.in#L1624
2019-05-02 08:33:38 <kr0k0> tcely: Ah ok, you mean abuild internals. I have looked for install_if in vdr APKBUILD ^^
2019-05-02 08:34:04 <tcely> kr0k0: no problem. It's a bit hidden for both -doc and -lang too
2019-05-02 09:42:52 <xsteadfastx> im trying to create a new package for libcanberra with pulse support
2019-05-02 09:43:12 <xsteadfastx> abuild rootpkg fails becuase it says "Has /home/... in rpath"
2019-05-02 09:43:20 <xsteadfastx> what can i do to investigate this?
2019-05-02 09:43:47 <Cogitri> xsteadfastx: Just use alsa libcanberra with pulseaudio-alsa/alsa-plugins-pulse
2019-05-02 09:44:07 <Cogitri> I guess you could build without rpath, should be a configure option
2019-05-02 09:44:29 <xsteadfastx> Cogitri: i want to build pavucontrol and it needs libcanberra with pulse
2019-05-02 09:45:01 <Cogitri> Uh? Pretty sure I used pavucontrol with what's in the repos a few days ago
2019-05-02 09:45:11 <xsteadfastx> there is a pavucontrol now?
2019-05-02 09:45:17 <xsteadfastx> i checked a few weeks ago
2019-05-02 09:45:27 <Cogitri> Ah, no, built it manually not via abuild
2019-05-02 09:45:52 <Cogitri> Was debugging pulse and was in the process of packaging GNOME so I didn't package pavucontrol
2019-05-02 09:46:00 <xsteadfastx> ah ok...
2019-05-02 09:46:24 <xsteadfastx> i wonder if libcanberra with pulse is needed then
2019-05-02 09:46:39 <Cogitri> I doubt it is
2019-05-02 09:47:48 <xsteadfastx> i will try this later... but still i wish i could understand the rpath error
2019-05-02 09:49:50 <xsteadfastx> i used the arch PKGBUILD as base... thats why i thought libcanberra-pulse is needed
2019-05-02 09:52:07 <xsteadfastx> my build dir is in RPATH
2019-05-02 09:52:21 <xsteadfastx> i checked with objdump -a -x
2019-05-02 09:58:44 <Cogitri> It complains that the RPATH points to your home, which is incorrect once it's instead to /
2019-05-02 09:59:04 <Cogitri> I guess the rpath should usually be smth like /usr/lib/libcanberra
2019-05-02 10:01:57 <mps> reading https://git-scm.com/book/en/v1/Distributed-Git-Distributed-Workflows, is the Alpine "Centralized Workflow" category?
2019-05-02 10:02:37 <Cogitri> Yup
2019-05-02 10:03:14 <mps> Cogitri: good, thanks
2019-05-02 10:29:27 <ncopa> tcely: what do you think about this: http://tpaste.us/pWpk
2019-05-02 10:29:56 <ncopa> I think it will make it easier to backport the secfixes to stable branches
2019-05-02 10:31:13 <ncopa> because then we can move the new dnssec tools into a new dnssec-tools package and v3.9 users will not get them with upgrade
2019-05-02 10:32:35 <ncopa> the idea is to create bind-dnssec-tools subpackage in v3.9 (and older stable) and move the new tools to this
2019-05-02 10:32:50 <ncopa> that way we avoid surprises for stable users
2019-05-02 10:33:53 <ncopa> and when they upgrade to v3.10 they will hopefully not notice that more tools moved to bind-dnssec-tools
2019-05-02 10:46:47 <kr0k0> Is it possible to define a function (maybe with params) in APKBUILD, which can be used by others, to not write the same for each subpackage?
2019-05-02 10:47:29 <_ikke_> sure, it's just shell script
2019-05-02 10:47:34 <north1> have a function write in one APKBUILD file that can be used by various different APKBUILD ?
2019-05-02 10:47:47 <kr0k0> No no, all in one ^^
2019-05-02 10:47:48 <_ikke_> _foo() { param1=$1; param2=$2; ... }
2019-05-02 10:47:55 <north1> kr0k0: Then yes, you can
2019-05-02 10:48:11 <north1> se alsa-plugins with _mv_lib and _mv_conf
2019-05-02 10:48:12 <kr0k0> Ah ok
2019-05-02 10:48:15 <north1> see*
2019-05-02 10:48:19 <kr0k0> thanks
2019-05-02 10:48:58 <north1> Speaking of avoiding writing all over again, is there interest in default_{bash,fish,zsh}comp functions ?
2019-05-02 10:50:01 <kr0k0> No, is only for creating directory and copying confs for each plugin (vdr APKBUILD)
2019-05-02 11:05:34 <tcely> ncopa: ddns-confgen, tsig-keygen, named-checkzone, and named-compilezone don't belong in a DNSSEC tools subpackage.
2019-05-02 11:08:21 <tcely> I think those should remain in the bind-tools subpackage. I still don't see how having a python subpackage helps with backporting though.
2019-05-02 11:09:32 <ncopa> thos tools are shipped with fedora's bind-dnssec-utils package: https://src.fedoraproject.org/rpms/bind/blob/master/f/bind.spec#_1286
2019-05-02 11:11:00 <ncopa> python binding supbackage is just a logic split so you can write pythons scripts to interact with daemon, without needing to install dnssec-tools
2019-05-02 11:12:15 <ncopa> there are 2 sides of this: 1) backport 2) how we want it to be with 3.10 release
2019-05-02 11:12:38 <ncopa> im doing the "how we want it to be in 3.10 release" first
2019-05-02 11:13:00 <ncopa> because we probably want the upgrade from 3.9 to 3.10 as smooth as possible
2019-05-02 11:15:21 <ncopa> can you run the ddns-confgen, tsig-keygen named-checkzone and named-compilezone tools without the dnssec tools?
2019-05-02 11:20:46 <ncopa> splitting python parts out helps with backporting because it means we dont need to introduce python dependency to get security update
2019-05-02 11:25:49 <tcely> yep, those are all C
2019-05-02 11:26:05 <tcely> only the python dnssec-* binaries remained in bind (in edge)
2019-05-02 11:27:16 <tcely> dnssec-checkds, dnssec-coverage, and dnssec-keymgr are the scripts that are using the py3-isc module.
2019-05-02 11:27:45 <ncopa> those are the new tools instroduced
2019-05-02 11:28:34 <ncopa> for v3.9 and older i intend to add a bind-dnssec-tools subpackage for those
2019-05-02 11:31:38 <tcely> we still need to add python3 and py3-ply when building, but your idea for backporting is that the upgrade should not pull in py3-isc or this new dnssec tools subpackage?
2019-05-02 11:31:50 <ncopa> correct
2019-05-02 11:32:13 <ncopa> if you run v3.9 and want upgrade so you get security fix
2019-05-02 11:32:21 <ncopa> you may not want those new tools
2019-05-02 11:32:42 <ncopa> but the extra python3 dep may come as surprise
2019-05-02 11:33:35 <tcely> If you have bind-tools installed, I'd say you do want those too. Certainly upgrading bind itself and getting python3 will come as a surprise.
2019-05-02 11:33:58 <ncopa> you shoudl be able to run apk upgrade in stable release branches and things should not break
2019-05-02 11:34:12 <ncopa> existing running things should not break because you pull in security update
2019-05-02 11:34:15 <ncopa> that is the main thing
2019-05-02 11:34:37 <ncopa> if you apk upgrade, and you don't get the new dnssec tools, things will not break
2019-05-02 11:35:03 <ncopa> if you read releasenotes and actually want those new tools, then you will have to apk add bind-dnssec-tools
2019-05-02 11:35:33 <ncopa> and when you upgrade to v3.10 (currently git master), things should go smooth
2019-05-02 11:35:50 <tcely> The problem I have is that only two of those are "new" tools afaik
2019-05-02 11:35:54 <ncopa> (eg package should preferrible not be renamed to something else)
2019-05-02 11:36:01 <ncopa> 3
2019-05-02 11:36:10 <ncopa> +usr/sbin/dnssec-checkds
2019-05-02 11:36:10 <ncopa> +usr/sbin/dnssec-coverage
2019-05-02 11:36:15 <ncopa> +usr/sbin/dnssec-keymgr
2019-05-02 11:36:46 <ncopa> so for stable branches, we can only move those to the newlly introduced bind-dnssec-tools package
2019-05-02 11:36:49 <tcely> Ok, so we limit our subpackage to those alone then and things work as you describe
2019-05-02 11:36:53 <ncopa> not the other dnssec-* tools
2019-05-02 11:36:56 <ncopa> yes
2019-05-02 11:37:09 <ncopa> but for v3.10 we can move them all
2019-05-02 11:40:36 <ncopa> looks like fedora has a bind-libs-lite package as well
2019-05-02 11:41:02 <ncopa> i guess that so you can get `dig` and those tools without pulling in too much
2019-05-02 11:56:45 <tcely> I'm thinking we should call this bind-python-tools instead, that's the split we care about.
2019-05-02 12:01:44 <ncopa> short-term yes
2019-05-02 12:01:58 <ncopa> long term i think bind-dnssec-tools makes more sense
2019-05-02 12:02:48 <ncopa> people normally dont care what language the tools they want are implemented in
2019-05-02 12:02:55 <ncopa> they just want the tool
2019-05-02 12:03:41 <tcely> I agree, which is why I don't see this as something the users should need to know about. If they installed bind-tools, they should get bind-python-tools too.
2019-05-02 12:03:58 <ncopa> that i disagree with
2019-05-02 12:04:03 <tcely> How we split it up has nothing to do with dnssec
2019-05-02 12:04:29 <ncopa> lets say i want `dig`
2019-05-02 12:04:45 <ncopa> im not gonna run any dns server
2019-05-02 12:04:50 <ncopa> i just want run dig
2019-05-02 12:05:04 <ncopa> or other client tools
2019-05-02 12:05:39 <ncopa> then its sort of inconvenient to get pyhon3 pulled in
2019-05-02 12:06:16 <ncopa> even if you run a dns server
2019-05-02 12:06:21 <ncopa> a caching resolver
2019-05-02 12:06:29 <ncopa> you maybe dont need the dnssec tools
2019-05-02 12:07:13 <ncopa> if you do want configure dnssec for an authoritative dns server, then sure
2019-05-02 12:08:05 <tcely> Ok. I'll work on a split that makes sense for just cache / resolver tools
2019-05-02 12:08:12 <ncopa> we could ofc have bind-tools as a catch-all, which pulls in dnssec-tools, bind-client-tools etc
2019-05-02 12:08:25 <ncopa> but then we need adapt for that
2019-05-02 12:08:32 <ncopa> for example, awall depends on bind-tools
2019-05-02 12:09:28 <ncopa> so upgrades gets smoother if we keep bind-tools and add bind-dnssec-tools
2019-05-02 12:09:34 <ncopa> i already pushed that
2019-05-02 12:09:37 <tcely> yeah, I don't think using bind-tools as the catch-all is a smart plan
2019-05-02 12:09:49 <ncopa> look at what i have pushed already
2019-05-02 12:12:52 <tcely> Does that change move all the /usr/sbin/* files that don't start with dnssec-* back to bind?
2019-05-02 12:14:39 <tcely> Oh, I see, 3.9 never moved the rest of the tools out of bind
2019-05-02 12:14:42 <tcely> ok
2019-05-02 12:21:31 <tcely> well, this code we've never compiled before is not so arm friendly. /usr/lib/gcc/armv6-alpine-linux-musleabihf/8.3.0/../../../../armv6-alpine-linux-musleabihf/bin/ld: ../../lib/ns/.libs/libns.so: undefined reference to `isc_atomic_xadd'
2019-05-02 12:25:34 <tcely> ncopa: Looks like we'll need a patch for that version. https://gitlab.isc.org/isc-projects/bind9/commit/d72f436b7d7c697b262968c48c2d7643069ab17f
2019-05-02 12:29:05 <ncopa> seems so yes.
2019-05-02 12:29:14 <ncopa> oh well...
2019-05-02 12:29:27 <ncopa> i was kinda hoping to get done with this sec update of bind
2019-05-02 12:30:11 <ncopa> tcely: are you sure that is the fix?
2019-05-02 12:30:29 <ncopa> do you have any reference?
2019-05-02 12:30:49 <tcely> Nope. It does look very reasonable for fixing the issue we are seeing. Others seem happy with it. https://seclists.org/oss-sec/2019/q2/71
2019-05-02 12:31:43 <ncopa> tcely: that was the reference i was looking for. thanks!
2019-05-02 12:31:57 <tcely> you're welcome
2019-05-02 12:34:19 <tcely> Here's a more canonical reference: https://lists.isc.org/pipermail/bind-users/2019-April/101673.html
2019-05-02 12:41:34 <ncopa> perfect. thanks!
2019-05-02 12:41:46 <ncopa> will add those links to commit message
2019-05-02 12:51:34 <ncopa> lol
2019-05-02 12:51:46 <ncopa> i love how they call "other rare CPU architectures"
2019-05-02 12:51:56 <ncopa> its basically everythin non-x86 :)
2019-05-02 12:54:20 <ncopa> i just got bitten by missing cd $builddir
2019-05-02 12:54:39 <ncopa> $ git diff  | tpaste
2019-05-02 12:54:40 <ncopa> http://tpaste.us/gMQd
2019-05-02 12:54:50 <ncopa> i need that to backport py3-ply to v3.8
2019-05-02 12:56:11 <ncopa> incredible how much friction it is to get bind security update out
2019-05-02 12:59:32 <tcely> when is v3.8 eol?
2019-05-02 13:00:42 <_ikke_> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2019-05-02 13:00:50 <_ikke_> may 2020
2019-05-02 13:01:35 <tcely> thanks
2019-05-02 13:01:52 <_ikke_> 3.6 is EOL according to that list
2019-05-02 13:02:52 <tcely> for this particular case, 3.7 and 3.6 share a bind version, so 6 more months for that
2019-05-02 13:03:22 <tcely> I think at some point we either give up on 3.9 or move them to 9.14 anyway
2019-05-02 13:06:05 <tcely> a bind-esv might be worth it as 3.9 and 9.11 EOL dates match up pretty well
2019-05-02 15:26:56 <andypost[m]> @ncopa please comment your POV on https://github.com/alpinelinux/aports/pull/6848
2019-05-02 18:55:11 <ollieparanoid[m]> ncopa: regarding my "not that controversial" relgroup script, I'd still like to get that into alpine, if I didn't miss the merge window. the next step would still be for alpine github org to fork the repository. here was the last message on the thread: https://lists.alpinelinux.org/alpine-devel/6501.html and here's the source, with working travis ci tests: https://github.com/ollieparanoid/aports-relgroup-check
2019-05-02 19:16:51 <north1> ncopa: accidentally deleted the branch for this PR, re-opened https://github.com/alpinelinux/abuild/pull/73
2019-05-02 19:17:15 <north1> @everyoneelseandncopa https://github.com/alpinelinux/abuild/pull/74
2019-05-02 19:18:25 <Cogitri> mps: Currently working on Rust 1.34 w/ LLVM8, you talked about having done some work for that already?
2019-05-02 19:19:23 <mps> Cogitri: yes, last night I finished with crystal and plan to push it this night
2019-05-02 19:19:32 <SpaceToast> north1: bash-comp depends on bash-completion: is that normal? (I'm a long time zsh user, honestly curious)
2019-05-02 19:19:53 <mps> after that I planed to start on those you mentioned
2019-05-02 19:20:10 <Cogitri> "it" being LLVM8?
2019-05-02 19:20:22 <north1> SpaceToast: yes
2019-05-02 19:20:27 <SpaceToast> ok
2019-05-02 19:20:28 <mps> do you made llvm8
2019-05-02 19:20:44 <north1> all install_if for -bash-completion depend on the bash-completion package being installed
2019-05-02 19:20:46 <SpaceToast> I wonder if it might be possible to take advantage of find's -exec instead of doing looping and 2>/dev/null
2019-05-02 19:20:52 <Cogitri> Ah, "it" is your crystal work
2019-05-02 19:21:00 <Cogitri> Currently building LLVM8
2019-05-02 19:21:24 <mps> eh, nice, don't need to make my fingers 'dirty' with it
2019-05-02 19:21:27 <mps> :)
2019-05-02 19:21:30 <north1> SpaceToast: I tried that but gave up since i want the function to look like default_dev
2019-05-02 19:22:07 <north1> Plus i plan on dealing with packages that install completion in the wrong way like fish-completion files that don't end with .fish and zsh completion files that don't have the prefixed underscore
2019-05-02 19:22:16 <mps> yes, I finished with crystal and right now upgrading some smaller packages
2019-05-02 19:22:56 <mps> zathura and it's 'plugins' and mupdf at the end
2019-05-02 19:23:22 <Cogitri> Ah, alright
2019-05-02 19:23:33 <SpaceToast> I think you don't have to do that: the package() function should be dealing with that
2019-05-02 19:23:48 <north1> SpaceToast: alright, i'll see what i can do with -exec then
2019-05-02 19:24:07 <SpaceToast> let me finish the review first :)
2019-05-02 19:24:12 <SpaceToast> (I'm in-progress there)
2019-05-02 19:24:32 <mps> when you finish with llvm8 and batteries please inform me so I could find my old rust files and try to rebuild with the new llvm8
2019-05-02 19:26:29 <Cogitri> Sure
2019-05-02 19:35:58 <SpaceToast> I think I might try and write a generic "subpackage mover" for all those default_split functions sometime
2019-05-02 19:36:01 <SpaceToast> maybe next weekend :)
2019-05-02 19:39:46 <north1> SpaceToast: subpackage mover ?
2019-05-02 19:40:08 <north1> if i understand what you said correctly, make it like vmove from Void Linux please
2019-05-02 19:40:10 <north1> :D even call it amove
2019-05-02 19:41:00 <SpaceToast> north1: basically all splitter subpackages do something along the lines of `mkdir subpkgdir/destination && cd pkgdir && find destination -exec mv {} subpkgdir/destination`
2019-05-02 19:41:11 <SpaceToast> so I think that can be abstracted away, so you just call that a bunch in all of them
2019-05-02 19:41:17 <SpaceToast> is that what vmove does?
2019-05-02 19:42:39 <north1> yes
2019-05-02 19:42:50 <SpaceToast> oh, alright, sounds like a good idea ;)
2019-05-02 19:43:02 <north1> vmove takes a path and moves from $pkgdir to $subpkgdir
2019-05-02 19:43:34 <SpaceToast> I'm planning to go for more of a 'find-spec', so it can apply to default_static and co
2019-05-02 19:43:44 <north1> like vmove /usr/include ; vmove /usr/lib/.a ; vmove /usr/lib/pkgconfig/xft.pc ; vmove /usr/lib/.so.
2019-05-02 19:43:49 <SpaceToast> but sure, I'll call it amove if I end up writing it to a degree where I'm happy with it
2019-05-02 19:44:21 <north1> find-spec ?
2019-05-02 19:44:46 <north1> anyways it starts here https://github.com/void-linux/void-packages/blob/master/common/environment/setup/install.sh#L198
2019-05-02 19:45:06 <SpaceToast> that's... very stateful ^^;;
2019-05-02 19:45:19 <SpaceToast> anyway I think I have a pretty solid idea of what I want to try to do
2019-05-02 20:19:13 <SpaceToast> north1: FYI: my approval is post-latest-push (by about 3 minutes) :)
2019-05-02 20:19:36 <SpaceToast> though, still, usually mkdir + mv, rather than install + rm, is used, but I don't think it's that big a deal
2019-05-02 20:57:07 <Cogitri> mps: pr7500
2019-05-02 20:58:34 <mps>  Cogitri: I see, how to get complete patch (for both commits) from there
2019-05-02 21:00:05 <Cogitri> Append .patch to the URL algitbot just posted
2019-05-02 21:01:22 <mps> nice, it works. will try later on aarch64
2019-05-02 21:02:10 <Cogitri> Thanks :)
2019-05-02 21:02:22 <Cogitri> I guess I should put Alpine on my RPI3
2019-05-02 21:03:34 <mps> I did on similar HW, and managed to build llvm6 and rust on it, 4GB ram with help of zswap
2019-05-02 21:05:23 <Cogitri> Sounds kind of like a pain though TBH
2019-05-02 21:06:15 <Cogitri> But I guess compiling it in Qemu isn't fun either
2019-05-02 21:07:04 <mps> well, maybe in qemu with a 'big' host, i.e. lot of CPU's and RAM
2019-05-02 21:07:35 <Cogitri> "big host" Would be my laptop ^^
2019-05-02 21:08:56 <mps> I have I7 with 6GB RAM, SSD and for anything serious (crystal, rust, llvm) I must add swap space, and it takes time
2019-05-02 21:09:58 <Cogitri> Oh wew, 6GB RAM is so little :o
2019-05-02 21:10:13 <mps> but if you decide to try aarch64 in qemu, I wrote short guide and script about three weeks ago how to install it
2019-05-02 21:10:40 <Cogitri> I have 16GB in my laptop and I need like 4~6GB for my desktop session (so that includes a browser+IDE)
2019-05-02 21:10:40 <Cogitri> mps: Neat, mind sending me a link?
2019-05-02 21:11:28 <mps> give me few minutes, I will put it on my site to not send it always to tpaste
2019-05-02 21:12:00 <Cogitri> Thanks :)
2019-05-02 21:19:10 <mps> Cogitri: http://arvanta.net/mps/ two last links
2019-05-02 21:21:22 <tmhoang> ncopa: iirc, you once mentioned 'vserver'. Was it ?
2019-05-02 21:21:34 <tmhoang> is it this : http://linux-vserver.org  /
2019-05-02 21:24:46 <tmhoang> 6gb is a little bit 'you need to upgrade' nowadays for devs.
2019-05-02 21:26:05 <mps> Cogitri: what a load is this llvm, 21:25:38 up 187 days, 23:05,  0 users,  load average: 59.73, 28.23, 15.40
2019-05-02 21:26:20 <tmhoang> geez
2019-05-02 21:26:39 <Cogitri> Hum, loaded all my cores to 100% for me
2019-05-02 21:29:15 <mps> Cogitri: finished llvm8 on aarch64, very well done :)
2019-05-02 21:29:50 <Cogitri> Nice! :)
2019-05-02 21:31:10 <mps> curiosity in me just says, try on armv7 ;)
2019-05-02 21:37:08 <mps> too much warning for my taste on armv7 building llvm8
2019-05-02 21:47:28 <mps> tmhoang: you meant to say 6GB is little for packager and not for developer :)
2019-05-02 21:49:06 <tmhoang> mps: in a ideal world, Alpine projects would hand out free cpu time and storage for contributors for development
2019-05-02 21:49:18 <tmhoang> :))
2019-05-02 21:50:39 <mps> heh, not Alpine but those who owns big machines and uses Alpine, I think
2019-05-02 22:02:22 <mps> Cogitri: still here? llvm8 passed build on armv7 also
2019-05-02 23:17:46 <north1> What's the policy on the SPDX `WITH` `OR` `AND` operators
2019-05-03 01:25:02 <north1> mps: Cogitri is in CET timezone.
2019-05-03 06:12:35 <ncopa> mornign
2019-05-03 06:12:39 <fabled> morning
2019-05-03 06:12:46 <north1> morning
2019-05-03 06:12:51 <SpaceToast> evening :)
2019-05-03 06:12:57 <ncopa> tmhoang: yes  that vserver
2019-05-03 06:13:05 <north1> SpaceToast: which timezone ? :o
2019-05-03 06:13:12 <SpaceToast> north1: EST, 2am here
2019-05-03 06:13:28 <SpaceToast> fabled: there's a possible race condition in apk (specifically apkcache) - where would you like to hear of it?
2019-05-03 06:13:36 <north1> SpaceToast: Ah nice, am on BRT 3am here
2019-05-03 06:13:50 <SpaceToast> north1: I have a rough draft for amove btw, is it ok if I poke you tomorrow for feedback/opinions?
2019-05-03 06:14:00 <SpaceToast> (a bit late for work, atm)
2019-05-03 06:14:02 <north1> SpaceToast: anytime
2019-05-03 06:14:08 <SpaceToast> :)
2019-05-03 06:14:40 <north1> feel free to pm on IRC i think it is the most reliable way considering gmail is all too eager to label everything that doesn't come from a big organization as spamm
2019-05-03 06:28:16 <north1> 300 PRs on github
2019-05-03 06:29:29 <ncopa> my plan today is to finish up bind security fix upgrades for stable, bootstrap arm* 3.10 builders, get the builders running
2019-05-03 06:29:34 <ncopa> and then look at the PRs
2019-05-03 06:29:48 <Cogitri> Yay
2019-05-03 06:29:48 <north1> ncopa: good luck
2019-05-03 06:32:39 <fabled> SpaceToast, we are aware of few of them already -- especially if trying to share cache with multiple hosts. it was not originally designed for that. there's been plans to fix those with some redesign but it's been progressing slowly. but please if there's something you found, we are interested to hear.
2019-05-03 06:33:09 <SpaceToast> fabled: it's very much sharing cache with multiple hosts and trying to update concurrently; glad to know you're already aware, then :)
2019-05-03 06:34:05 <fabled> yeah. the apk cache was designed for single host using it on usb-stick. and the need for sharing it come "huge" after going docker / lxc. we are aware. though not sure if the limitations on that are documented properly anywhere.
2019-05-03 06:34:07 <SpaceToast> I would take a look at possible fixes, but my C is quite rusty and I'm doing other things as well; but I'll mark it down as something to do if it's being troublesome
2019-05-03 06:34:26 <SpaceToast> yeah, my use-case is lxc (well, lxd specifically)
2019-05-03 06:34:34 <fabled> we've had idea to rewrite the package/index format for a long time (3-4 years at least). and also fix that issue
2019-05-03 06:35:16 <fabled> the design is basically ready, and i have some code. but it's still a way to go. there's been too many "distractions".
2019-05-03 06:35:29 <SpaceToast> aye, that's understandable
2019-05-03 06:35:36 <SpaceToast> if you're looking for test subjects, I volunteer :)
2019-05-03 06:36:45 <fabled> thanks. i am not sure if the apkcache sharing is fixable easily in the current file format... i was hoping to get the fileformat changes done first...
2019-05-03 06:37:00 <fabled> and those are rather big. basically redo of the format.
2019-05-03 06:37:20 <SpaceToast> okay. if I can help in any way, please do not hesitate to ask
2019-05-03 06:37:32 <fabled> going from text files to binary. in order to improve speed, performance and also security aspects.
2019-05-03 06:39:31 <detha> eew
2019-05-03 06:39:59 <detha> as long as tooling has something that dumps it as text, I guess that's bearable
2019-05-03 06:40:23 <fabled> detha, that was the original motivation to keep text files. but life has changed and requirements
2019-05-03 06:40:47 <fabled> i spent considerable time benchmarking things, and the current bottle neck is parsing the text files (+gunzip) in apk
2019-05-03 06:41:50 <fabled> and the security aspect is to have the format such that we move signed blobs from pkg->index->installed-db. this way the manifest is always asymmetrically verifiable and thus we can also verify all installed files to be unmodified (ultimately against signature)
2019-05-03 06:43:13 <detha> makes sense. mind you, text files can also be signed with sha256 or so, but that defeats the 'quickly edit to try something' anyway
2019-05-03 06:43:14 <fabled> and the slowness is coming more and more evident on embedded hw (arm) now that our package database is growing bigger and bigger
2019-05-03 06:43:44 <fabled> apk was designed for quite different use case when we had about 500 packages.
2019-05-03 06:43:53 <fabled> now alpine is more generic purposes and we have tons of packages
2019-05-03 06:46:29 <detha> yeah. having lots of packages is good, but it puts more strain on things
2019-05-03 06:49:50 <kr0k0> morning
2019-05-03 06:54:59 <Cogitri> kr0k0: Morning
2019-05-03 07:14:05 <eu> Noticed lxc was updated to 3.1 for 3.9/edge which is *not* LTS. Should probably have updated to 3.0 (support upstream to mid 2023) to make long term maintenance easier. Upstream also recommends 3.0 fir production. Don’t know how feasible a downgrade is?
2019-05-03 07:22:26 <mps> eu: this deserves big note in bold text, to not forget, and to be solved somehow, imo
2019-05-03 07:36:22 <clandmeter> i wonder if i missed that, or that page has been updated recently?
2019-05-03 07:57:42 <eu> clandmeter: you bumped it to 3.1 in january
2019-05-03 07:58:33 <clandmeter> i think i just overlooked it :|
2019-05-03 08:33:40 <ncopa> tmhoang: i have problems with bootstrapping the s390x builder
2019-05-03 08:33:52 <tmhoang> ncopa: yes
2019-05-03 08:34:00 <tmhoang> what can i help
2019-05-03 08:36:07 <ncopa> tmhoang: i think you have access to the builder
2019-05-03 08:36:41 <ncopa> it was curl test suite that failed iirc
2019-05-03 08:37:02 <tmhoang> curl was fine the other day
2019-05-03 08:37:11 <tmhoang> I checked after you mentioned.
2019-05-03 08:37:23 <ncopa> yes, it was fine on my dev machine too
2019-05-03 08:37:32 <tmhoang> ok so it's a problem on builder
2019-05-03 08:38:37 <ncopa> tmhoang: can you ssh root@s390x.alpinelinux.org lxc-console -n build-3-10-s390x
2019-05-03 08:38:51 <tmhoang> yes im checking
2019-05-03 08:38:58 <ncopa> log in as root, and then: su - buildozer
2019-05-03 08:39:01 <ncopa> tmux attach
2019-05-03 08:39:18 <ncopa> running build of curl right now
2019-05-03 08:40:46 <ncopa> hm
2019-05-03 08:40:53 <ncopa> i think we have yet another circular dep
2019-05-03 08:42:32 <ncopa> yup
2019-05-03 08:42:36 <ncopa> curl has circular dep
2019-05-03 08:44:00 <ncopa> http://tpaste.us/VaMv
2019-05-03 08:44:52 <ncopa> i think something in last week has introduced circular dep for curl
2019-05-03 08:46:09 <tmhoang> yes, I saw that. Are we debugging this cir dep by hand or ?
2019-05-03 08:46:18 <ncopa> yes
2019-05-03 08:46:20 <tmhoang> ok
2019-05-03 08:46:25 <ncopa> the s390x builder issue is different issue
2019-05-03 08:47:40 <tmhoang> how do you set up the 3.10 builder ? it says 3.9 Alpine Linux but /etc/apk/repositories once pointed to edge and now currently local repo
2019-05-03 08:47:56 <ncopa> where does it say alpine 3.9?
2019-05-03 08:48:05 <tmhoang> Welcome to Alpine Linux 3.9
2019-05-03 08:48:10 <tmhoang> login console tty
2019-05-03 08:48:28 <ncopa> i cloned build-3-9-s390x, removed /home/buildozer/packages
2019-05-03 08:48:39 <ncopa> cd ~/aports/main
2019-05-03 08:49:00 <tmhoang> I want to replicate on my local dev instead of poluting the builder.
2019-05-03 08:49:02 <tmhoang> ok I see
2019-05-03 08:49:04 <ncopa> git pull && for i in $(ap recursdeps build-base  | xargs ap builddirs); do (cd $i && abuild -rk)|| break; done
2019-05-03 08:49:09 <ncopa> and apk upgrade
2019-05-03 08:49:16 <tmhoang> nice
2019-05-03 08:49:26 <ncopa> it means it has no repository
2019-05-03 08:49:38 <ncopa> just the packages it has installed
2019-05-03 08:49:52 <ncopa> after build base is built, i apk upgrade
2019-05-03 08:50:00 <ncopa> and
2019-05-03 08:50:03 <tmhoang> yeah understood. So that it build itself with what (essential build packages) it already had
2019-05-03 08:50:19 <ncopa> git pull && for i in $(ap recursdeps build-base aports-build | xargs ap builddirs); do (cd $i && abuild -rk)|| break; done
2019-05-03 08:50:21 <tmhoang> nice one. I used to not upgrade
2019-05-03 08:50:21 <ncopa> yes
2019-05-03 08:51:30 <tmhoang> ncopa: apk recursdeps ?
2019-05-03 08:51:47 <ncopa> not apk
2019-05-03 08:51:48 <ncopa> ap
2019-05-03 08:51:54 <ncopa> from lua-aports
2019-05-03 08:52:10 <ncopa> which parses the APKBUILDs extracts the makedepends and depends
2019-05-03 08:52:22 <ncopa> and recurses the dependencies
2019-05-03 08:52:22 <tmhoang> wow
2019-05-03 08:52:43 <ncopa> so you get a list of all dependencies
2019-05-03 08:55:55 <ncopa> ok, its a bug in lua-aports
2019-05-03 08:57:45 <tmhoang> sorry I never used lua-aports when I bootstrap stuffs. Should've done it
2019-05-03 08:58:31 <tmhoang> still checking though
2019-05-03 09:10:11 <tmhoang> afaiu, what ap does in above loop would be pretty much the same as looping throught main/* and abuild -R everything
2019-05-03 09:17:25 <tmhoang> maybe the difference is 'everything'
2019-05-03 09:17:29 <tmhoang> :)
2019-05-03 09:20:25 <ncopa> yes, the difference is that ap will calculate the build order before it start to build anything
2019-05-03 09:20:50 <ncopa> abuild -R will try rebuild all missing deps
2019-05-03 09:21:04 <ncopa> so it will try build dep, but then "oh ok it was already built..."
2019-05-03 09:57:22 <ncopa> are there anything we should merge before we start the 3.10 builders to build the world?
2019-05-03 09:57:29 <ncopa> maybe the icu update?
2019-05-03 09:59:01 <Cogitri> I think polkit 0.105 has some open CVEs, but since no one but me and maxice8 seems to have tested my PR with it I'd rather not merge it last minute
2019-05-03 10:00:34 <ncopa> i was more thinking like language upgrades and similar
2019-05-03 10:00:50 <clandmeter> ncopa: so we still keep wireguard in testing?
2019-05-03 10:02:25 <mps> clandmeter: good question
2019-05-03 10:02:49 <ncopa> im ok to move it to community
2019-05-03 10:03:04 <ncopa> i have asked upstream for stable release
2019-05-03 10:03:08 <ncopa> actually
2019-05-03 10:03:13 <ncopa> we should probably ask upstream again
2019-05-03 10:03:16 <clandmeter> what did he say?
2019-05-03 10:03:29 <ncopa> i think he dont want make it stable til its merged in mainline
2019-05-03 10:03:35 <clandmeter> right
2019-05-03 10:03:40 <clandmeter> so next question
2019-05-03 10:03:42 <clandmeter> :)
2019-05-03 10:04:03 <clandmeter> he has a timeline regrading upstream?
2019-05-03 10:04:36 <ncopa> i think he said "soon" a half year ago
2019-05-03 10:04:37 <ncopa> so...
2019-05-03 10:04:53 <ncopa> my guess is 0.5-1 year
2019-05-03 10:05:05 <ncopa> but i dont know really
2019-05-03 10:05:07 <mps> I read Linus comment in ML where he says that he is 1000% for upstreaming it
2019-05-03 10:05:24 <ncopa> yes, it has gotten positive feedback from upstream
2019-05-03 10:05:29 <ncopa> from linus
2019-05-03 10:06:16 <mps> but, no one told about when exactly
2019-05-03 10:07:56 <mps> so, personally I'm not sure what to do although would like to see it in community
2019-05-03 10:08:16 <ncopa> the problem is if we want maintain it for 6 months
2019-05-03 10:08:20 <ncopa> provide security fixes
2019-05-03 10:08:48 <ncopa> what im afraid of may happen is that he changes the format one way or the other, so a new update is not backwards compatible
2019-05-03 10:09:00 <ncopa> and then comes a security update after that
2019-05-03 10:09:43 <ncopa> other worry is that mainline kernel may want some non-backwards compatible changes
2019-05-03 10:09:43 <mps> imo, 6 months is not big problem, problem is that we have to care about it for two years in stable releases
2019-05-03 10:10:11 <ncopa> 2 years is out of the question
2019-05-03 10:10:16 <mps> yes, terra incognita
2019-05-03 10:10:17 <ncopa> community repo is only 6 months
2019-05-03 10:10:58 <mps> only 6, I thought that both, main and community are LTS
2019-05-03 10:11:28 <ncopa> no
2019-05-03 10:11:37 <mps> I see now
2019-05-03 10:11:40 <ncopa> community is only latest stable
2019-05-03 10:13:15 <mps> kernel is not upgraded to new major version in stable, so maybe rethink move of wireguard
2019-05-03 10:14:08 <kr0k0> What's about pr7163?
2019-05-03 10:14:17 <ncopa> i think we can ask upstream. he has been pretty helpful before
2019-05-03 10:14:34 <mps> I had more than 6 months  it's  git repo locally and selected one commit which I use for old kernels for which I build it
2019-05-03 10:15:23 <ncopa> kr0k0: is samba 4.10 ABI compatible with 3.9?
2019-05-03 10:15:33 <ncopa> or do we need rebuild a bunch of packages
2019-05-03 10:16:27 <kr0k0> I'm not aware of any dependency, except the packages included in my pr.
2019-05-03 10:17:56 <kr0k0> Won't be all packages rebuilt for 3.10?
2019-05-03 10:19:16 <ncopa> they will, but we dont want break edge
2019-05-03 10:19:22 <ncopa> looks ok
2019-05-03 10:19:31 <ncopa> the most important is libsmbclient i guess
2019-05-03 10:19:45 <ncopa> but it does not look like it breaks any abi
2019-05-03 10:19:53 <ncopa> so I guess we can merge it
2019-05-03 10:20:05 <ncopa> I havent checked if there are any circular deps isntroduced
2019-05-03 10:20:09 <ncopa> introduced*
2019-05-03 10:20:35 <ncopa> did you check that the different subpackages are okish?
2019-05-03 10:20:49 <ncopa> so we dont pull in server libs when installing samba client
2019-05-03 10:22:03 <kr0k0> Let me check
2019-05-03 10:23:36 <ncopa> x86 and aarch64 builders are ready to go
2019-05-03 10:24:17 <ncopa> tmhoang: are you looking at the s390x builder?
2019-05-03 10:24:28 <tmhoang> ncopa: yes I'm working on it
2019-05-03 10:24:43 <ncopa> good, i'll not mess with it then :)
2019-05-03 10:24:52 <tmhoang> currently on my dev, trying to rebuild.
2019-05-03 10:25:01 <tmhoang> python3 shows a test fail
2019-05-03 10:25:09 <ncopa> also on ppc64le
2019-05-03 10:25:11 <ncopa> dont know why
2019-05-03 10:25:37 <ncopa> oh, it may be due to gcc
2019-05-03 10:25:42 <tmhoang> ncopa: I assumed you fixed lua-aport cir bug in the last commit ?
2019-05-03 10:25:47 <ncopa> yes
2019-05-03 10:25:51 <tmhoang> so it's the matter of 3 curl test fail now
2019-05-03 10:25:56 <ncopa> ok
2019-05-03 10:26:12 <ncopa> im ok to simply disable them for s390x for now
2019-05-03 10:26:37 <ncopa> ppc64le seems to have built python3 now
2019-05-03 10:26:50 <tmhoang> your call
2019-05-03 10:27:15 <ncopa> it is better to fix it
2019-05-03 10:27:27 <ncopa> i mean, it could be a real bug in curl affecting s390x
2019-05-03 10:27:32 <ncopa> or it could be buggy testcase
2019-05-03 10:27:43 <tmhoang> of course, I'm trying to fix in the mean time, but if it delays others
2019-05-03 10:28:13 <ncopa> i'll hold it til afternoon
2019-05-03 10:28:43 <tmhoang> thanks
2019-05-03 10:29:07 <ncopa> need to wait for x86_64 and arm* anyway
2019-05-03 10:33:55 <kr0k0> ncopa: A samba-client install should be ok, the only new files are "usr/bin/dumpmscat usr/lib/samba/libclidns-samba4.so usr/lib/samba/libmscat-samba4.so"
2019-05-03 10:35:06 <ncopa> ok, lets merge it
2019-05-03 10:36:00 <vagrant0> anyone interested in maintaining the alpine/alpine32 and alpine/alpine64 vagrant images?
2019-05-03 10:36:30 <ncopa> i have more than enough things to maintain :)
2019-05-03 10:37:27 <kr0k0> ncopa: Thanks!
2019-05-03 10:40:49 <tmhoang> ncopa: I setup fresh v3.9 Alpine (4.19 kernel though instead of 4.14.104 on v3.8 branch) and curl test pass
2019-05-03 10:41:10 <tmhoang> checking the builder
2019-05-03 10:41:28 <tmhoang> let me check if it fails with python3 or not
2019-05-03 10:42:38 <tmhoang> is that a container ?
2019-05-03 10:42:49 <tmhoang> build-3-10-s390x
2019-05-03 10:53:30 <tmhoang> ok re-run again on the builder, now only 1 test fail : 644
2019-05-03 11:20:37 <ncopa> yes it is a container
2019-05-03 11:21:08 <ncopa> i woner if we should upgrade the host
2019-05-03 11:21:40 <ncopa> its v3.8
2019-05-03 11:21:57 <ncopa> tmhoang: should we try upgrade it to v3.9?
2019-05-03 11:23:17 <tmhoang> ncopa: idk. let see how the debug going on
2019-05-03 11:24:07 <tmhoang> are all builders on on 3.9 ?
2019-05-03 11:24:28 <ncopa> no
2019-05-03 12:03:15 <kmaxwell> what is checkpkg? can anyone point me at it please?
2019-05-03 12:03:54 <kmaxwell> I've seen a few references on PR comments and would like to learn how to use it
2019-05-03 12:09:29 <clandmeter> kmaxwell: it compares new and old pkg for changes.
2019-05-03 12:09:45 <clandmeter> mostly we use it to check soname changes
2019-05-03 12:13:16 <ncopa> kmaxwell: it is a tool that fetches apk from mirror and extract it to temp dir and run a diff against file list with locally built package
2019-05-03 12:14:54 <kmaxwell> thanks both, which package is the tool in? Is there an easy way to install it?
2019-05-03 12:15:13 <clandmeter> apk add cmd:checkpkg
2019-05-03 12:15:16 <kmaxwell> I tried searching but the closest I found was checkapk
2019-05-03 12:16:29 <kmaxwell> clandmeter: I get ERROR: unsatisfiable constraints from that
2019-05-03 12:17:14 <clandmeter> hmm i think its checkapk
2019-05-03 12:17:18 <kmaxwell> also for example https://pkgs.alpinelinux.org/contents?file=checkpkg&path=&name=&branch=edge says no item found
2019-05-03 12:17:27 <kmaxwell> clandmeter: awesome thanks!
2019-05-03 12:17:40 <kmaxwell> I thought I might be missing something :)
2019-05-03 12:17:51 <clandmeter> yes, pkg apk can be misleading
2019-05-03 12:20:41 <kmaxwell> also only came across the cmd: syntax for apk today which I must say is really helpful
2019-05-03 12:21:07 <clandmeter> it can be helpful, but it also a bit tricky
2019-05-03 12:21:54 <ncopa> hm
2019-05-03 12:22:00 <clandmeter> in this case its maybe better to search for cmd:xxx and install the matched pkg.
2019-05-03 12:22:11 <ncopa> community/john does not build with openssl 1.1, so we use it with libressl
2019-05-03 12:22:22 <ncopa> there is a 1.9 release out of john the ripper "core"
2019-05-03 12:22:31 <ncopa> there will be a -jumbo release soon
2019-05-03 12:22:45 <ncopa> john 1.9 builds with openssl 1.1
2019-05-03 12:23:00 <ncopa> and this is blocking the libressl upgrade
2019-05-03 12:43:11 <tmhoang> "ncopa: are there anything we should merge before we start the 3.10 builders to build the world?" : openjdk ?
2019-05-03 12:47:39 <ncopa> they are in community so I dont think it matter if we start the builders first
2019-05-03 12:47:46 <ncopa> but yeah
2019-05-03 12:47:52 <ncopa> openjdk would be nice
2019-05-03 13:38:03 <Cogitri> mps: What version of Rust have you built? I'm kind of considering using an upstream tarball for building 1.34 so we don't need to make multiple bumps to slowly bring Rust from 1.31 to 1.34
2019-05-03 13:56:33 <mps> Cogitri: I've built rust-1.30.1 apk's, which I used to build firefox and some other rust programs (exa, ripgrep and some others)
2019-05-03 13:57:04 <SpaceToast> fyi: latest ripgrep requires 1.34, so you can't actually build it anymore :)
2019-05-03 13:57:15 <SpaceToast> (not in a PR atm because, well, you can't build it)
2019-05-03 13:57:24 <mps> with this rust/cargo I tried to build 1.31 rust and build passed but making apk failed
2019-05-03 13:57:54 <mps> SpaceToast: this was about two months ago
2019-05-03 13:58:01 <SpaceToast> aha
2019-05-03 13:58:27 <mps> ehm, Jan 23 08:37 cargo-1.30.1-r1.apk
2019-05-03 13:58:52 <mps> so more than 2 months
2019-05-03 13:59:30 <tmhoang> ncopa: I have tried setting up diff env and they all pass the test (3.9 Docker container on 3.8 host, 3.8 host, 3.9 host). I may need more time to debug curl perl test code and its C code
2019-05-03 14:00:09 <mps> in these apk's rust is patched with alpine targets and it can build proper alpine binaries
2019-05-03 14:01:22 <mps> I thought to use it to build alpine rust 1.31 which could be used to 'go up' building next version/s
2019-05-03 14:01:26 <tmhoang> even in the builder container, the test fail is unstable. running them a couple of times, random fail, random success.
2019-05-03 14:02:01 <ncopa> hum
2019-05-03 14:02:02 <ncopa> ok
2019-05-03 14:02:03 <tmhoang> $ cd test ; srcdir=. /usr/bin/perl -I. ./runtests.pl -k -a 587 588 644
2019-05-03 14:02:28 <ncopa> do we have a log out put of a fail?
2019-05-03 14:02:39 <tmhoang> I can reproduce
2019-05-03 14:03:42 <tmhoang> 1 sec
2019-05-03 14:04:14 <ncopa> i think this is somethign we may want report upstream
2019-05-03 14:04:41 <tmhoang> my guess is the test data was not available when the test run. because next runs would improve sucess. Report upstream, yes. I'm going to do that
2019-05-03 14:05:05 <tmhoang> ok now I have trouble reproducing lol
2019-05-03 14:05:17 <tmhoang> bc they all succeed ...
2019-05-03 14:05:56 <ncopa> maybe skip the 587 588 644 tests on s390x for now?
2019-05-03 14:07:27 <tmhoang> yeah
2019-05-03 14:08:39 <ncopa> https://src.fedoraproject.org/rpms/curl/blob/master/f/curl.spec#_201
2019-05-03 14:08:47 <ncopa> looks like fedora also have troubles with some tests
2019-05-03 14:09:26 <tmhoang> I guess they should sleep more on some tests. Some tests have proper amount of sleeping time
2019-05-03 14:09:32 <tmhoang> or they should just go to bed
2019-05-03 14:10:35 <tmhoang> wow they have a history of test failures
2019-05-03 14:11:56 <ncopa> i think make -j4 will speed up compile
2019-05-03 14:12:31 <ncopa> https://src.fedoraproject.org/rpms/curl/blob/master/f/curl.spec#_273
2019-05-03 14:12:44 <ncopa> srcdir=../../tests perl -I../../tests ../../tests/runtests.pl -a -p -v '!flaky'
2019-05-03 14:12:54 <ncopa> the '!flaky' is interesting
2019-05-03 14:13:28 <ncopa> maybe we should run our tests same way
2019-05-03 14:17:45 <tmhoang> wtf : test 0587 SKIPPED: disabled by keyword, test 0644 SKIPPED: disabled by keyword
2019-05-03 14:18:11 <tmhoang> okay, !flaky disables 587 + 588
2019-05-03 14:18:17 <tmhoang> hah
2019-05-03 14:18:29 <tmhoang> they disable whole lot more with !flaky
2019-05-03 14:18:32 <ncopa> lets run our tests with !flaky
2019-05-03 14:18:36 <tmhoang> :D
2019-05-03 14:18:48 <tmhoang> shoudl've checked fedora at 1PM ...
2019-05-03 14:18:57 <ncopa> :)
2019-05-03 14:19:25 <tmhoang> sounds like a plan with !flaky. I need to get lunch. Will check again on this topic afterwards
2019-05-03 14:19:41 <ncopa> i'll investigate how to do that
2019-05-03 14:20:09 <tmhoang> on making !flaky ? I can make a patch for it
2019-05-03 14:21:26 <ncopa> make -C tests nonflaky-test
2019-05-03 14:23:04 <tmhoang> ah great! Thanks :D
2019-05-03 14:23:25 <ncopa> i think i can fix it
2019-05-03 14:23:31 <tmhoang> o/
2019-05-03 14:23:37 <ncopa> while you eat your lunch ;)
2019-05-03 14:48:43 <tcely> pr6265 it would be nice to include before the next release
2019-05-03 15:00:14 <ncopa> tcely: have you tested that it works?
2019-05-03 15:02:14 <ncopa> it seems like i can get the 3.10 builders up today
2019-05-03 15:02:52 <ncopa> x86, aarch64, ppc64le are ready to go
2019-05-03 15:15:06 <ncopa> sweet, s390x and x86_64 are also ready
2019-05-03 15:15:33 <ncopa> its just arm* left
2019-05-03 15:16:50 <ncopa> tcely: dhcrelay-openrc does not get installed when expected
2019-05-03 15:17:02 <ncopa> maybe also move from /var/run to /run while at it?
2019-05-03 15:29:23 <tcely> ncopa: thanks for the feedback. For default_openrc, would it be better to use install_if="openrc ${subpkgname%-openrc}=$pkgver-r$pkgrel"
2019-05-03 15:29:54 <ncopa> tcely: yes that looks correct. probably also remove the default_openrc
2019-05-03 15:31:47 <tcely> I man inside default_openrc so that using default_openrc for subpackages works too
2019-05-03 15:31:54 <alpine-meetbot> tcely meant to say: I mean inside default_openrc so that using default_openrc for subpackages works too
2019-05-03 15:31:54 <tcely> s/man/mean/
2019-05-03 15:34:51 <ncopa> that may be
2019-05-03 15:36:20 <ncopa> like this: http://tpaste.us/RgPo
2019-05-03 15:39:02 <tcely> hmm. how would subpkgname not be set?
2019-05-03 15:39:52 <ncopa> i was thinking for the main package, but i was thining wrong
2019-05-03 15:41:37 <tcely> Also name will end in -openrc so that should be removed for the install_if
2019-05-03 15:42:35 <ncopa> like this? http://tpaste.us/9ge7
2019-05-03 15:42:39 <ncopa> can you test if it works?
2019-05-03 15:46:09 <tcely> yes, like that. I'll test that change on my next build.
2019-05-03 15:48:00 <tcely> http://tpaste.us/nMEr resulted in http://tpaste.us/zBmj
2019-05-03 15:56:02 <ncopa> we may need look over `grep -- -openrc */*/APKBUILD` to verify that we dont break anything unexpectedly
2019-05-03 15:56:07 <Cogitri> mps: Alright, will build latest Rust from upstream tarballs then
2019-05-03 16:08:50 <mps> Cogitri: I'm talking about rust on aarch64 and armv7 arch's
2019-05-03 16:09:50 <Cogitri> Yup, I know, but I wasn't sure if you also bumped the version while you were at it
2019-05-03 16:10:14 <Cogitri> Gonna bump it to 1.34.0 first then and then add support for other arches I guess
2019-05-03 16:11:18 <mps> no, I don't built from current community/rust/APKBUILD but from one I put in testing and not pushed it to aports
2019-05-03 16:12:22 <tmhoang> Cogitri: I'm plugged in this weekend. Feel free to ping if you need testing on s390x (or even ppc64le, I have qemu emulation here)
2019-05-03 16:12:24 <tmhoang> thanks
2019-05-03 16:16:28 <mps> Cogitri: I'm too busy now, will have more time in a few hours, I hope
2019-05-03 16:22:30 <tcely> ncopa: Other than $pkgname-openrc::noarch in a lot of places and community/minetest I didn't see anything from grep
2019-05-03 16:22:38 <Cogitri> Alright, thank you, tmhoang&mps! :)
2019-05-03 16:35:22 <ncopa> tcely: ok. i'll push that
2019-05-03 17:12:20 <ncopa> clandmeter: do you mind if I purge tesseract-git?
2019-05-03 17:18:06 <ncopa> are there any of the current PRs that requires lots of rebuilds?
2019-05-03 17:18:43 <SpaceToast> it depends on your definition of "require", I think
2019-05-03 17:18:54 <SpaceToast> https://github.com/alpinelinux/aports/pull/6306 (bison minor version update), for instance
2019-05-03 17:20:16 <ncopa> ugh... should have done that before we bootstrapped the builders...
2019-05-03 17:52:52 <ncopa> so, i had a goal to work on PRs today
2019-05-03 17:53:13 <ncopa> i spent half day on a single PR
2019-05-03 17:53:30 <ncopa> it takes significanlyt more time to close PRs than to open them
2019-05-03 17:54:14 <ncopa> actually, i think closed a few others while working on that single PR
2019-05-03 17:54:37 <ncopa> while doing rebuilds against icu I checked for open PRs and merged those
2019-05-03 17:57:52 <jwh> reminds me, I should really open a couple of PRs :D
2019-05-03 17:58:02 <jwh> once I have a working dev environment again, sigh
2019-05-03 18:00:12 <ncopa> tmhoang: looks like icu build failed on s390x :-(
2019-05-03 18:00:38 <tmhoang> ncopa: okay
2019-05-03 18:00:43 <tmhoang> im looking
2019-05-03 18:00:50 <tmhoang> do you need it tonight or tmr
2019-05-03 18:01:05 <ncopa> i guess tmr is fine
2019-05-03 18:01:16 <ncopa> it will block the builder though
2019-05-03 18:01:25 <ncopa> and it is a 20?+ packages that needs to be rebuilt
2019-05-03 18:01:46 <ncopa> but it will not block the 3.10 builder i think
2019-05-03 18:24:49 <tcely> ncopa: My next PR priorities are https://github.com/alpinelinux/abuild/pull/57 and https://github.com/alpinelinux/aports/pull/7504
2019-05-03 18:25:07 <tcely> I think you closed at least three today :-)
2019-05-03 18:30:54 <_ikke_> tcely: regarding openresty: >>> WARNING: openresty: depends_dev found but no development subpackage found
2019-05-03 18:31:04 <_ikke_> https://github.com/alpinelinux/aports/pull/7168/files
2019-05-03 18:31:44 <_ikke_> Should there be a dev subpackage, or should I merge the depends_dev into makedepends?
2019-05-03 18:32:04 <tcely> I think merging into makedepends is the best opton there
2019-05-03 18:32:08 <_ikke_> ok
2019-05-03 18:33:05 <tcely> pr7223 and pr7225 would be nice to include if anyone can review / approve those
2019-05-03 18:33:32 <_ikke_> Can't help you there :-)
2019-05-03 18:34:43 <tcely> oh. pr7129 I want up to date sqlite
2019-05-03 18:35:52 <tcely> pr7069 is interesting, it doesn't fit my use cases though
2019-05-03 18:36:03 <tmhoang> ncopa: new icu fails on fedora s390x too. so it's s390x problem, not Alpine s390x problem. I will file a report upstream tmr.
2019-05-03 18:36:19 <tmhoang> they prob mess up the Makefile structure I think
2019-05-03 18:36:24 <tmhoang> not very serious
2019-05-03 18:36:43 <tcely> tmhoang: do we skip s390x for now then?
2019-05-03 18:36:58 <tmhoang> maintainer's call :)
2019-05-03 18:37:11 <mps> just looked through repology.org Alpine pkg's and made short list of those which I would like to see upgraded
2019-05-03 18:37:38 <tcely> mps: do they have patches in PW or PRs already?
2019-05-03 18:38:29 <mps> algibot just mentioned some, nginx, openssh and sqlite
2019-05-03 18:38:56 <otlabs> hi ppl
2019-05-03 18:38:59 <_ikke_> hi
2019-05-03 18:39:32 <otlabs> _ikke_: yo!
2019-05-03 18:39:34 <mps> so, I could upgrade some but not sure if it is ok before asking maintainers
2019-05-03 18:39:53 <otlabs> i would like to thank you all for reviewing, commenting and merging my PRs! thanks a lot to all of you!
2019-05-03 18:40:20 <mps> and some updates and fixes on bugs.a.o are needed
2019-05-03 18:40:45 <_ikke_> mps: I feel trivial updates don't necessarily need to be aproved by the maintainer
2019-05-03 18:41:02 <_ikke_> You mean update redmine?
2019-05-03 18:41:21 <mps> no, filled issues there
2019-05-03 18:41:27 <_ikke_> ok
2019-05-03 18:41:42 <tcely> mps: I'm reviewing PRs right now, that's why algitbot is responding. I would suggest go ahead and suggest the upgrade, if the maintainer objects it should be up to that person to say so.
2019-05-03 18:42:13 <otlabs> i see that 2 of my PRs are merged into upstream git but were not closed by bot at github
2019-05-03 18:42:35 <_ikke_> otlabs: which ones
2019-05-03 18:43:00 <otlabs> pr7497
2019-05-03 18:43:15 <otlabs> and pr7495
2019-05-03 18:43:47 <mps> tcely: don't have github account
2019-05-03 18:44:26 <tcely> otlabs: That happens sometimes. Adding a keyword in the hook for git am is an attempt to solve that. https://github.com/alpinelinux/aports/pull/7422
2019-05-03 18:45:01 <tcely> mps: no problem, you can still see what's there. patchwork is the solution used for those without github (for now)
2019-05-03 18:45:19 <otlabs> tcely: ok, ok, thanks
2019-05-03 18:46:37 <mps> I use patchwork for most of my patches
2019-05-03 18:46:54 <_ikke_> patchwork does not get a lot of attention though
2019-05-03 18:47:27 <otlabs> _ikke_: thanks!
2019-05-03 18:47:29 <tcely> _ikke_: yeah, I'd really like it if algitbot posted things from patchwork onto github
2019-05-03 18:47:44 <_ikke_> Not sure if that would work
2019-05-03 18:47:58 <_ikke_> You need to be able to ask for feedback and interact with the submitter
2019-05-03 18:48:06 <tcely> mps: I do review patchwork too, but I do admit I don't do that often
2019-05-03 18:49:11 <ncopa> tmhoang: looks like it can be worked around with mkdir -p data/out
2019-05-03 18:50:18 <mps> any idea about solution for https://bugs.alpinelinux.org/issues/10354
2019-05-03 18:50:44 <mps> i.e. postgresql with readline
2019-05-03 18:50:57 <SpaceToast> my understanding is that building it with readline makes the binary GPL-licensed
2019-05-03 18:51:08 <tmhoang> ncopa: right. interesting
2019-05-03 18:51:34 <SpaceToast> as to the details, it gets complicated
2019-05-03 18:51:46 <SpaceToast> however, with arch and void taking that approach I'm not sure how much it actually matters
2019-05-03 18:51:57 <mps> SpaceToast: I don't understand these legalese
2019-05-03 18:52:12 <SpaceToast> mps: almost no one does, GNU included :)
2019-05-03 18:52:21 <mps> hehe :)
2019-05-03 18:52:25 <SpaceToast> kind of one of the issues I have with the GPL in general
2019-05-03 18:52:28 <ncopa> first 3.10 builder is up \o/
2019-05-03 18:52:28 <tmhoang> must be something with big endian
2019-05-03 18:52:38 <tmhoang> icudt64b vs icudt64l.
2019-05-03 18:52:47 <SpaceToast> but hey, the FSF hasn't sued Arch or Void, so I basically think we don't need to care about it
2019-05-03 18:52:58 <SpaceToast> I would at least hope that they'd ask for a change before they straight up sue, as well
2019-05-03 18:52:59 <tmhoang> lol 3-10-s390x is up first
2019-05-03 18:53:05 <ncopa> yup
2019-05-03 18:53:07 <SpaceToast> ncopa: nice! \o/
2019-05-03 18:53:08 <mps> SpaceToast: as I wrote solution could be wrapper which preloads readline
2019-05-03 18:53:22 <ncopa> intentionally. it is normally s390x that causes most problem so i wanted it up first...
2019-05-03 18:53:22 <tmhoang> troubled chil
2019-05-03 18:53:24 <tmhoang> child
2019-05-03 18:53:29 <ncopa> exacly :)
2019-05-03 18:53:47 <SpaceToast> mps: I personally don't like compromising technical solutions due to weird powerplays of external entities
2019-05-03 18:54:06 <SpaceToast> ld.so is a big enough erm... potential-problem even without preloading
2019-05-03 18:54:11 <tmhoang> I guess s390x is the only big endian arch right now
2019-05-03 18:54:28 <mps> SpaceToast: I agree but would like to have 'normal' history
2019-05-03 18:55:31 <SpaceToast> besides, if we're going to worry about legal technicalities, perhaps we should worry about the fact that apkbuild files aren't technically licensed (which isn't a problem up until someone starts making a fuss about it, and refuses to license their work)
2019-05-03 18:56:12 <SpaceToast> anyway, I think we should just build pgsql with readline, and if the FSF gets upset we can revert it
2019-05-03 18:56:23 <SpaceToast> but that's just my opinion, based on all of the above
2019-05-03 18:56:34 <mps> SpaceToast: +1
2019-05-03 19:03:01 <tcely> pr6660 would be nice to have
2019-05-03 19:03:55 <eu> Why not link it against libedit?
2019-05-03 19:04:40 <_ikke_> eu: it apprently gives issues
2019-05-03 19:05:09 <mps> eu: read https://bugs.alpinelinux.org/issues/10354
2019-05-03 19:05:40 <mps> it is currently linked with libedit
2019-05-03 19:06:20 <eu> Don’t link at all, and make pgsql a wrapper script for: `rlwrap psql -n` :)
2019-05-03 19:06:46 <mps> this is one of my proposal
2019-05-03 19:07:33 <mps> debian have a perl wrapper for this
2019-05-03 19:08:20 <mps> anyone know what fedora/redhat do for this
2019-05-03 19:08:35 <eu> As a former Void core dev, I would not look to them for licensing advice. Dunno about Arch
2019-05-03 19:11:26 <eu> mps: readline: https://src.fedoraproject.org/rpms/postgresql/blob/master/f/postgresql.spec#_117
2019-05-03 19:13:17 <mps> I see, thanks. So SpaceToast's proposal sound good enough
2019-05-03 19:15:04 <eu> Yeah, but IBM has more lawyers than Alpine...
2019-05-03 19:15:34 <mps> but, if we want to be legally safe, steal debian wrapper and add it to pkg
2019-05-03 19:16:38 <eu> Debian links against libedit
2019-05-03 19:16:44 <eu> As does ubuntu
2019-05-03 19:17:05 <mps> yes, but have wrapper which uses readline
2019-05-03 19:17:15 <_ikke_> Do we know why libedit is causing these issues?
2019-05-03 19:18:27 <mps> _ikke_: that question is in my back brain for some time, and don't know answer
2019-05-03 19:18:55 <SpaceToast> _ikke_: same problem as with libressl, afaik
2019-05-03 19:19:10 <SpaceToast> the non-gnu variant slowly diverges, and no one manages to keep up
2019-05-03 19:19:33 <fabled> _ikke_, https://git.alpinelinux.org/aports/commit/?id=e029c357 ... i would have preferred to develop the main/nginx package instead
2019-05-03 19:20:15 <_ikke_> fabled: hmm.. ok
2019-05-03 19:20:49 <fabled> from https://openresty.org/en/ : OpenResty� is not an Nginx fork. It is just a software bundle
2019-05-03 19:21:07 <fabled> it's nginx + mod_lua + some other modules... most of which we ship in main/nginx already
2019-05-03 19:21:20 <fabled> https://openresty.org/en/components.html
2019-05-03 19:21:23 <_ikke_> tcely: ^
2019-05-03 19:21:29 <fabled> some of the other stuff we package individually
2019-05-03 19:21:42 <fabled> see e.g. community/lua-resty-*
2019-05-03 19:21:53 <tcely> we should stop cherry-picking resty items
2019-05-03 19:22:26 <tcely> If we can ensure that nginx isn't modified in incompatible ways, I have no issue with openresty just including our packaged nginx
2019-05-03 19:23:18 <fabled> i'd rather cherry-pick lua-resty-* and make openresty meta package that pulls in nginx + lua-resty-*
2019-05-03 19:23:36 <fabled> it's a bit of more work, but allows user to choose which ones to install
2019-05-03 19:23:44 <SpaceToast> does lua-resty do anything without nginx?
2019-05-03 19:24:05 <fabled> no
2019-05-03 19:24:20 <fabled> lua-resty-* packages depend on lua modules provided by nginx-lua module
2019-05-03 19:24:57 <fabled> but openresty bundles also non-resty modules that are usable without nginx
2019-05-03 19:25:22 <fabled> e.g. lua-cjson
2019-05-03 19:25:58 <SpaceToast> basically, I don't think it makes sense to have a metapackage installing A+B if B always requires A
2019-05-03 19:26:05 <SpaceToast> that's about it for my 2c :)
2019-05-03 19:26:07 <fabled> and some webapps might want only one or two lua-resty-*
2019-05-03 19:26:35 <fabled> but it's A+B+...+ZZ metapackage
2019-05-03 19:26:40 <SpaceToast> perhaps openresty can be a metapackage that installs all of lua-resty-* and lua-resty-* all depend on nginx-lua
2019-05-03 19:26:49 <fabled> and it's perfectly normal that suer wants only A+B+D+Y
2019-05-03 19:27:05 <tcely> SpaceToast: A keeps being modified to pull in things from git repos not packaged properly.
2019-05-03 19:27:11 <tcely> Take a look at our nginx APBUILD
2019-05-03 19:27:15 <tcely> APKBUILD
2019-05-03 19:27:33 <SpaceToast> you're making me scared of doing that :)
2019-05-03 19:28:10 <tcely> fabled: yes, but the users who want openresty are not the set who want openresty -C
2019-05-03 19:28:52 <tcely> If we could replicate the openresty bundle easily using up to date packages I would love that, currently it's easier to just build the whole bundle
2019-05-03 19:29:05 <_ikke_> https://git.alpinelinux.org/aports/tree/main/nginx/APKBUILD
2019-05-03 19:33:08 <fabled> tcely, i understand it's easier. but it's code duplication and means more work for maintainers. it also means it'll conflict with the existing packages.
2019-05-03 19:34:18 <fabled> it also looks like the package split is not done for the resty and other embedded modules
2019-05-03 19:34:55 <fabled> and i do appreciate the intent. i do miss some resty modules at times too
2019-05-03 19:36:19 <fabled> maybe we can continue the discussion later. i need to go get some sleep.
2019-05-03 19:43:01 <tcely> pr6291
2019-05-03 19:44:32 <SpaceToast> I thought we're supposed to keep the $builddir stuff around on main/ :)
2019-05-03 19:46:06 <SpaceToast> oh, gcc9 finally got released :D
2019-05-03 19:46:38 <mps> and is 9.1
2019-05-03 19:46:48 <tcely> SpaceToast: yes, we should. that was just an issue with py-ply recently (entirely my fault)
2019-05-03 19:46:56 <SpaceToast> mps: yes, they changed to that versioning scheme a bit ago
2019-05-03 19:47:09 <SpaceToast> because people kept being afraid to use .0 releases since they were unstable
2019-05-03 19:47:14 <SpaceToast> so they just started calling them .1 releases
2019-05-03 19:47:57 <jwh> SpaceToast: o/
2019-05-03 19:48:05 <SpaceToast> I guess I should start looking into D support, then :)
2019-05-03 19:48:11 <mps> to me it looks now better than llvm family
2019-05-03 19:53:37 <otlabs> time to go, have a nice weekend! bye
2019-05-03 20:03:48 <north1> oh, firefox pkgrel wasn't reset to 0
2019-05-03 20:15:15 <tcely> pr5793
2019-05-03 20:16:28 <tcely> pr5751
2019-05-03 20:17:25 <mps> +1 for perl upgrade
2019-05-03 20:26:39 <ncopa> ouch!
2019-05-03 20:26:47 <ncopa> how could we miss the perl upgrade?
2019-05-03 20:27:00 <ncopa> how could *I* miss the perl upgrade
2019-05-03 20:27:10 <_ikke_> 300+ PRs that's how
2019-05-03 20:27:45 <Cogitri> Heh
2019-05-03 20:28:17 <ncopa> it should have been done before the bootstrap
2019-05-03 20:29:04 <ncopa> and i am starting the 3.10 builders now
2019-05-03 20:29:25 <mps> so, it is late for perl upgrade?
2019-05-03 20:29:31 <ncopa> yes
2019-05-03 20:29:33 <ncopa> well
2019-05-03 20:29:51 <ncopa> i suppose its not too late
2019-05-03 20:30:21 <mps> anyone tried perl base upgrade
2019-05-03 20:30:22 <ncopa> is just meaningless to rebuild all those packages * number_of_arches
2019-05-03 20:30:30 <ncopa> i mean a waste of build time
2019-05-03 20:30:50 <mps> so, for next stable
2019-05-03 20:31:02 <mps> 3.11, I mean
2019-05-03 20:31:06 <ncopa> i will have a look at it next week
2019-05-03 20:31:12 <ncopa> might be we can do it for 3.10
2019-05-03 20:31:43 <mps> I use perl a lot, will help if you decide to upgrade
2019-05-03 20:32:05 <ncopa> it looks like it missed the 3.9 train
2019-05-03 20:32:21 <ncopa> so i think we shoudl make a serious effort to make it happen for 3.10
2019-05-03 20:32:39 <ncopa> just annoying that i missed it
2019-05-03 20:32:53 <mps> 5.28 have a lot better unicode support
2019-05-03 20:35:27 <tcely> 
ACTION made it to the last page of PRs

2019-05-03 20:36:00 <ncopa> i dont think that is something to be proud of :)
2019-05-03 20:36:01 <andypost[m]> ncopa I missed pr5751 as well
2019-05-03 20:36:29 <ncopa> we need to look over the issues on bugs.a.o
2019-05-03 20:36:45 <ncopa> and prioritize those that we need to fix for 3.10
2019-05-03 20:43:01 <tcely> ncopa: Hah! I'm glad to be done reviewing those.
2019-05-03 20:43:23 <tcely> I also looked over the patchwork list and didn't see anything that jumped out.
2019-05-03 20:58:22 <_ikke_> pulsaudio is in community but does not have a maintainer
2019-05-03 20:58:51 <north1> _ikke_: If you want i can take it
2019-05-03 20:58:55 <north1> https://github.com/alpinelinux/aports/pull/7402
2019-05-03 20:59:23 <_ikke_> Yes, I was looking at that PR :-)
2019-05-03 20:59:28 <SpaceToast> it's one of kaniini's old packages
2019-05-03 20:59:39 <_ikke_> I suspected as much
2019-05-03 20:59:49 <_ikke_> north1: feel free to do so
2019-05-03 20:59:57 <SpaceToast> I think adopting it is great :)
2019-05-03 21:00:00 <SpaceToast> especially if you use it
2019-05-03 21:01:32 <tcely> #10115
2019-05-03 21:02:02 <tcely> #10080
2019-05-03 21:03:16 <north1> ok pushed to the pulseaudio PR with adoption
2019-05-03 21:03:17 <north1> back to updating Firefox
2019-05-03 21:03:48 <tcely> #10026
2019-05-03 21:08:18 <tcely> #9933
2019-05-03 21:08:48 <tcely> #9928
2019-05-03 21:21:43 <tcely> #9622 does it make sense to split out pip3 too?
2019-05-03 21:22:49 <tcely> #9633 likely should be resolved
2019-05-03 21:26:03 <tcely> #9744
2019-05-03 21:28:52 <tcely> #9776
2019-05-03 21:31:32 <tcely> #9831
2019-05-03 21:34:07 <tcely> #9826
2019-05-03 21:35:31 <ncopa> tcely: can you set priority hig on the most important ones?
2019-05-03 21:35:47 <tcely> ncopa: I can't change anything I did not report
2019-05-03 21:35:57 <tcely> perhaps someone else in channel can
2019-05-03 21:36:23 <north1> i think cogitri can
2019-05-03 21:36:29 <north1> he is afk now though.
2019-05-03 21:38:01 <Cogitri> Ah, sure, can do
2019-05-03 21:38:34 <tcely> #9492 can be resolved I think
2019-05-03 21:39:50 <tcely> #9511
2019-05-03 21:42:12 <tcely> #9474
2019-05-03 21:43:00 <tcely> #9490
2019-05-03 21:50:16 <tcely> #9280
2019-05-03 21:53:04 <Cogitri> What should I mark duplicate bugs as? We don't seem to have DUPLICATE or INVALID
2019-05-03 21:53:25 <Cogitri> Also, mind putting a link #9490 to explain how it has been fixed, tcely?
2019-05-03 21:54:52 <tcely> Cogitri: I'm not sure it has been. We should certainly put it on our todo list.
2019-05-03 21:56:27 <Cogitri> Ah, alright.
2019-05-03 21:56:52 <tcely> #9125
2019-05-03 21:57:17 <tcely> #9367
2019-05-03 21:57:57 <SpaceToast> #9367 should be closed
2019-05-03 21:58:06 <SpaceToast> wireguard-tools-wg-quick does indeed depend on bash
2019-05-03 22:00:54 <tcely> #9373 should be too from what I can see
2019-05-03 22:02:52 <tcely> #9390
2019-05-03 22:03:34 <tcely> #9391
2019-05-03 22:05:03 <tcely> #9409 how does the repository selection work out when you have two main repos in the file?
2019-05-03 22:06:45 <tcely> #9411
2019-05-03 22:07:38 <danieli> tcely: I'm pretty sure it just picks the package with the highest pkgver/pkgrel in the index independent of the mirror unless you do pinning
2019-05-03 22:08:01 <danieli> but I'm not sure which one it would pick if you have, say, two official main repos with the same packages
2019-05-03 22:08:54 <tcely> knowing that would be very helpful for local mirrors and bandwidth saving
2019-05-03 22:09:02 <danieli> +1
2019-05-03 22:09:08 <danieli> i ujst don't know off the top of my head
2019-05-03 22:09:38 <danieli> s/uj/ju/
2019-05-03 22:09:38 <alpine-meetbot> danieli meant to say: i just don't know off the top of my head
2019-05-03 22:11:53 <tcely> #8998 is probably ready to close
2019-05-03 22:13:00 <danieli> agreed
2019-05-03 22:13:45 <tcely> #8999 is resolved
2019-05-03 22:17:27 <tcely> #9016
2019-05-03 22:20:38 <tcely> #9059
2019-05-03 22:21:33 <mps> does it make sense to find pkcs8 patch for kernel to support eap-tls for iwd
2019-05-03 22:23:57 <Cogitri> tcely: Mind adding a commit to 8999 then? Can't seem to find a specific one which fixed it
2019-05-03 22:26:52 <tcely> Cogitri: https://git.alpinelinux.org/aports/commit/main/bind/APKBUILD?id=68d39a1b32f61d1f0de48593b5197ed14171ae71
2019-05-03 22:27:15 <tcely> blame is usually good for finding changes like that
2019-05-03 22:31:43 <Cogitri> Thanks
2019-05-03 22:32:59 <Cogitri> Yup, but wasn't quite sure if I understood the bugreport correctly since it also mentioned switching to openssl
2019-05-03 22:33:22 <tcely> openssl switch happened in 3.9 IIRC
2019-05-03 22:33:37 <tcely> the changelog / release notes on the version page should say
2019-05-03 22:34:07 <danieli> 3.9.0 yes
2019-05-03 22:34:25 <tcely> https://alpinelinux.org/posts/Alpine-3.9.0-released.html
2019-05-03 22:34:34 <tcely> yeah, I just found it
2019-05-03 22:34:55 <tcely> Cogitri: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2019-05-03 22:37:36 <Cogitri> Ah, read alpine-devel when the switch occured, wasn't quite sure what date it was now :)
2019-05-03 22:47:08 <Cogitri> mps: Soo...we have to cycle through Rust 1.32 w/ LLVM7 to Rust 1.34 w/  LLVM8 it seems
2019-05-03 22:47:22 <Cogitri> We can't use the upstream tarballs due to our custom triplet
2019-05-03 22:47:30 <tcely> #9089 needs more investigation I believe
2019-05-03 22:48:16 <tcely> ok. I've hit my limit. 15 pages of issues and they are all blurred together for me.
2019-05-03 22:48:42 <tcely> Who wants to pick up the torch? https://bugs.alpinelinux.org/projects/alpine/issues?c%5B%5D=project&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=assigned_to&c%5B%5D=updated_on&f%5B%5D=status_id&f%5B%5D=&group_by=&op%5Bstatus_id%5D=%21&page=16&set_filter=1&sort=id%3Adesc&t%5B%5D=&utf8=%E2%9C%93&v%5Bstatus_id%5D%5B%5D=3&v%5Bstatus_id%5D%5B%5D=5
2019-05-03 22:48:44 <TBK[m]> tcely: tunnel vision? :S
2019-05-03 22:49:30 <Cogitri> Good thing that at least Rust compiles fine with LLVM7 although it's kinda broken because they work around it upstream. We'll just have to bump to 1.32 and then to 1.34 in one go I suppose
2019-05-03 22:49:32 <mps> Cogitri: I think so
2019-05-03 22:50:27 <mps> Will you add all alpine arch'es
2019-05-03 22:51:54 <mps> I mean, patch to rust targets for all alpine architectures
2019-05-03 22:52:46 <mps> my experience with llvm7 is not good
2019-05-03 22:53:13 <mps> I tried few times to build some pkgs but always failed
2019-05-03 22:53:36 <mps> llvm6 worked
2019-05-03 22:54:39 <Cogitri> Yes, it doesn't work with optlevel=3 which is the defacto standard for Rust
2019-05-03 22:54:47 <mps> last night I tried build rust 1.31 with llvm8 and it failed but this is expected for this version
2019-05-03 22:54:47 <Cogitri> But Rust compiles itself with optlevel=2 due to that
2019-05-03 22:55:07 <Cogitri> So I want to use 1.32 w/ LLVM7 only for compiling 1.34, nothing more
2019-05-03 22:55:40 <Cogitri> After I have bumped Rust to 1.34 I'll look into the other arches, OK? :)
2019-05-03 22:55:41 <mps> on x86_64 only, or some other arch's
2019-05-03 22:56:15 <Cogitri> Hm?
2019-05-03 22:56:30 <mps> I expect it will work that way on x86_64
2019-05-03 22:57:15 <mps> actually we don't have anything to bootstrap it on all archs
2019-05-03 22:57:34 <mps> only, x86_64, aarch64 and armv7
2019-05-03 22:57:36 <Cogitri> Yes, after 1.34 works on x86_64 with LLVM8 I'll tryout other arches
2019-05-03 22:58:43 <mps> ok, that sounds reasonable in current state
2019-05-03 22:59:15 <Cogitri> We can cross to other arches or use upstream compilers for that, I suppose
2019-05-03 23:00:28 <mps> cross build? I remember I have seen somewhere on github docker image to cross build rust for musl
2019-05-03 23:05:12 <tcely> mps: I tried that and couldn't get it working. I think I ran out of space on my build VM and gave up.
2019-05-03 23:05:32 <Cogitri> I guess upstream tarballs should work too and are easier to work with for initial bootstrapping
2019-05-03 23:05:39 <mps> tcely: perl?
2019-05-03 23:05:53 <tcely> mps: the cross build docker image
2019-05-03 23:06:32 <mps> ah, you are better than me, I didn't managed to start building
2019-05-03 23:06:52 <mps> I don't have much experience with docker
2019-05-03 23:07:58 <mps> Cogitri: hmmm, I wouldn't count on upstream for bootstrap on musl
2019-05-03 23:08:58 <Cogitri> Oh, I do, they provide beta&nightly tarballs already
2019-05-03 23:09:12 <mps> for musl?
2019-05-03 23:09:24 <Cogitri> In fact, I'm using them right now for rust development :)
2019-05-03 23:10:09 <mps> really, that good news. didn't looked there for some time
2019-05-03 23:10:09 <Cogitri> They default to crt-static though, so I have to pass RUSTFLAGS="-C target-feature=-crt-static" to rustc for most stuff
2019-05-03 23:10:12 <Cogitri> Yes, for musl
2019-05-03 23:10:23 <mps> eh, very goog news
2019-05-03 23:10:32 <mps> s/goog/good/
2019-05-03 23:10:33 <alpine-meetbot> mps meant to say: eh, very good news
2019-05-03 23:10:57 <Cogitri> Yes πŸ‘
2019-05-03 23:11:16 <mps> will look tomorrow, here is late night
2019-05-03 23:11:47 <mps> thinking to go to bed
2019-05-03 23:12:17 <Cogitri> Alright, good night
2019-05-03 23:12:26 <mps> good night to all
2019-05-04 03:45:38 <russkel> hi, I am looking at adding support for ROS on Alpine which will likely involve at least a couple of dependencies that do not exist in aports. If I was to use as a base the archlinux build files and modify to work on alpine would this be acceptable to commit to aports?
2019-05-04 03:49:01 <TBK[m]> Arch pkgbuild is an alright starting point. Make it a PR against aports (https://github.com/alpinelinux/aports) and we will comment/review it until it is in good shape to get accepted.
2019-05-04 03:50:42 <russkel> Sounds good to me!
2019-05-04 04:04:22 <TBK[m]> somebody with bug.a.o admin right please nuke this user + comments - https://bugs.alpinelinux.org/users/7335
2019-05-04 07:10:01 <bratkartoffel> TBK[m]: Deleted the comments, thanks
2019-05-04 07:13:04 <clandmeter> :)
2019-05-04 09:41:11 <mps> anyone with main push right will look at mupdf upgrade on patchwork.a.o, please
2019-05-04 09:42:18 <mps> this is needed to add some security fixes after that and not in one big commit
2019-05-04 11:30:04 <_ikke_> north1: network manager fails on s390x: ../libnm/nm-remote-settings.c:35:10: fatal error: introspection/org.freedesktop.NetworkManager.Settings.h: No such file or directory
2019-05-04 11:34:13 <Cogitri> I think that's on me?
2019-05-04 11:34:21 <_ikke_> ah, right, yes
2019-05-04 11:34:36 <_ikke_> north is leo
2019-05-04 11:34:58 <Cogitri> Will look into it after lunch, had hoped that it's fixed with meson
2019-05-04 11:35:20 <_ikke_> alright
2019-05-04 11:35:50 <mps> Cogitri: nice that you took maintainership so I don't need to step there :)
2019-05-04 11:48:14 <_ikke_> Cogitri: sorry, I said s390x, but I meant ppc64le
2019-05-04 12:15:52 <Cogitri> Are there plans to add these arches to CI? I don't really have a way to test changes on them :c
2019-05-04 12:29:29 <_ikke_> 0yes
2019-05-04 12:29:31 <_ikke_> yes
2019-05-04 12:39:42 <_ikke_> Cogitri: drone.io does not have any runners for these
2019-05-04 12:39:52 <_ikke_> Cogitri: clandmeter asked if they would get them
2019-05-04 12:40:04 <_ikke_> but we can also use our own drone.io runners or even another system
2019-05-04 13:16:21 <mps> BSD licensed readline library https://github.com/AmokHuginnsson/replxx . should I post APKBUILD or not?
2019-05-04 13:21:39 <Cogitri> _Ikke_: Alright, thought those are already our own runners, didn't know Drone also offered it own runners (I only run my own)
2019-05-04 13:22:04 <Cogitri> Thanks for the info :)
2019-05-04 13:22:14 <_ikke_> Cogitri: np
2019-05-04 13:57:22 <kaniini> mps it isn't a readline API implementation
2019-05-04 13:58:09 <mps> kaniini: in meantime after posting msg about it i seen that you are right
2019-05-04 13:59:43 <mps> btw, nice to see you here :)
2019-05-04 13:59:51 <SpaceToast> oh, hey kaniini! :)
2019-05-04 14:05:04 <Cogitri> What are the differences between the Travis and the Drone runners? Do they run different Alpine releases or smth? (Wondering why some tests fail on Travis where they work on Drone and the other way around)
2019-05-04 14:05:23 <SpaceToast> Cogitri: drone runs inside containers, travis runs inside vms afaik
2019-05-04 14:05:54 <mps> and drone supports all arch's, afaik
2019-05-04 14:06:08 <SpaceToast> not sure about all, but definitely more than x86
2019-05-04 14:07:45 <tcely> doesn't TravisCI also use containers?
2019-05-04 14:08:44 <SpaceToast> no, see https://docs.travis-ci.com/user/reference/overview/
2019-05-04 14:10:15 <mps> looks like s390x is not supported by drones
2019-05-04 14:16:36 <tcely> They used to have containers. https://changelog.travis-ci.com/the-container-based-build-environment-is-fully-deprecated-84517
2019-05-04 14:17:34 <Cogitri> mps: They don't offer runners for it, we could add our own ones tho
2019-05-04 14:19:08 <mps> I didn't worked with them, but look at it from time to time when helping someones to solve issues
2019-05-04 14:33:39 <tcely> busybox should be backported to 3.9 https://hub.docker.com/_/alpine/scans/library/alpine/latest
2019-05-04 16:01:14 <Cogitri> tmhoang: You have a ppc64le machine, right? Mind testing NM for me in a bit?
2019-05-04 16:02:23 <tmhoang> Cogitri: it's emulation on  x86
2019-05-04 16:02:29 <tmhoang> sure
2019-05-04 16:02:48 <Cogitri> Oh, okay. Thanks
2019-05-04 16:04:04 <mps> uhmm, how to disable package on builders? posted zathura-pdf-mupdf to testing but forgot that the mupdf is not upraged
2019-05-04 16:04:51 <tmhoang> I can test for you just fine. Last time I run ppc64le emulation is pretty ok
2019-05-04 16:05:06 <_ikke_> mps: completely disable?
2019-05-04 16:05:25 <_ikke_> mps: You can set arch to an emtpy value
2019-05-04 16:06:00 <mps> ah, ok, will do now
2019-05-04 16:09:31 <mps> _ikke_: did I it correctly, testing/zathura-pdf-mupdf/APKBUILD
2019-05-04 16:11:44 <mps> uh, I forgot to delete locally upgraded mupdf from lxc container, meh
2019-05-04 16:16:17 <Cogitri> tmhoang: pr7551
2019-05-04 16:16:22 <tmhoang> ok
2019-05-04 16:21:35 <ncopa> tcely: why should busybox be backported to latest?
2019-05-04 16:21:45 <ncopa> i think we backported the fixes for those CVEs
2019-05-04 16:23:48 <mps> _ikke_: looks like empty arch didn't helped
2019-05-04 16:27:13 <_ikke_> mps: ncopa advised the same
2019-05-04 16:27:30 <mps> i see, thanks to both
2019-05-04 16:28:46 <mps> maybe it should be removed from build queue
2019-05-04 16:29:30 <tcely> ncopa: https://ibb.co/TgX3kmh
2019-05-04 16:29:45 <mps> anyway, if it continue to appears on builders I will move it to unmaintained
2019-05-04 16:29:53 <tcely> It looks like there are patches, but that doesn't clear the warning docker hub is showing
2019-05-04 16:29:55 <mps> as ncopa advised
2019-05-04 16:32:43 <ncopa> tcely: I have reported it to the scanner people. I will ping them on monday
2019-05-04 16:33:07 <tcely> ok
2019-05-04 16:33:39 <ncopa> tcely: but in general, better report it to the place where the bug is
2019-05-04 16:34:56 <ncopa> if we have the vulnerability, then we should spend time on fixing it. if the problem is otherwise, then I think we should spend our time on real issues
2019-05-04 16:35:05 <mps> perl-libwww failed test is explained here https://github.com/libwww-perl/libwww-perl/issues/307
2019-05-04 16:35:34 <mps> nntp test should be disabled for now
2019-05-04 16:43:50 <yjftsjthsd> I'm trying to create a PR for i3status, but the steps at https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md appear to be missing a step. I made a local branch with `git checkout -b` per that doc, but when I go to push it errors out because that branch doesn't exist on github.
2019-05-04 16:44:29 <yjftsjthsd> The steps in CONTRIBUTING.md skip from commit to making the PR, so I assume there's a step or explaination missing in the middle there
2019-05-04 16:44:59 <Cogitri> Hum, that should definitely work though, what's the exact error?
2019-05-04 16:45:06 <SpaceToast> yjftsjthsd: you git push -u fork-upstream branch-name
2019-05-04 16:45:23 <SpaceToast> So you have to add your fork as a remote
2019-05-04 16:45:27 <tcely> yjftsjthsd: what does (git status ; git remote show -n) show?
2019-05-04 16:47:50 <clandmeter> yjftsjthsd: did you clone via ssh?
2019-05-04 16:48:39 <tcely> clandmeter: either ssh or https, but when the push happens for https to github it prompted me the last time I tried that to login.
2019-05-04 16:48:58 <ncopa> whee! below 300PRs
2019-05-04 16:49:08 <tcely> :-)
2019-05-04 16:49:10 <doggone> is there a way to submit PRs without github?
2019-05-04 16:49:19 <tcely> doggone: patchwork
2019-05-04 16:49:40 <clandmeter> well its actually patches via ml workflow
2019-05-04 16:49:52 <clandmeter> patchwork is just a tool
2019-05-04 16:51:24 <yjftsjthsd> In order: Error is "fatal: The current branch maintain_i3status has no upstream branch". I just used `git push`, so that's probably the problem. That status/remote command gives "On branch maintain_i3status""nothing to commit, working tree clean""origin". Yes, I cloned my fork via ssh.
2019-05-04 16:52:09 <SpaceToast> yjftsjthsd: the documented you said was missing stuff said to do `git push origin feature` ;)
2019-05-04 16:52:17 <SpaceToast> Not just `git push`
2019-05-04 16:52:39 <yjftsjthsd> In the step about making revisions, yes. I'd not gotten that far
2019-05-04 16:52:52 <yjftsjthsd> lemme try that
2019-05-04 16:52:57 <tcely> yjftsjthsd: git push -u origin maintain_i3status
2019-05-04 16:53:17 <yjftsjthsd> Ah, that worked, thanks.
2019-05-04 16:53:28 <mps> ncopa: I see you replacing libelf with elfutils in some pkg's. could that be solution for dead libelf upstream
2019-05-04 16:54:51 <tcely> clandmeter: does patchwork let you upload patch sets?
2019-05-04 16:55:11 <clandmeter> upload match sets?
2019-05-04 16:55:14 <mps> tcely: bundes
2019-05-04 16:55:29 <mps> s/bundes/bundles/
2019-05-04 16:55:29 <alpine-meetbot> mps meant to say: tcely: bundles
2019-05-04 16:55:51 <tcely> sure, bundles if that's the proper term for a set of patches
2019-05-04 16:55:54 <clandmeter> s/match/patch
2019-05-04 16:55:55 <alpine-meetbot> clandmeter meant to say: upload patch sets?
2019-05-04 16:56:09 <clandmeter> you cannot upload anything
2019-05-04 16:56:27 <clandmeter> patchwork is receiving patches from the ml
2019-05-04 16:56:34 <clandmeter> its subscribed to it
2019-05-04 16:56:36 <mps> it have bundles option although I didn't tried how it works
2019-05-04 16:57:13 <ncopa> mps: yes, it seems that most of those packages builds just fine with elfutils
2019-05-04 16:57:43 <mps> nice, so no need to hunt for archive for libelf
2019-05-04 16:57:52 <ncopa> correct
2019-05-04 16:57:58 <Cogitri> ncopa: Mind if I take maintainership of gnome-bluetooth?
2019-05-04 16:58:14 <ncopa> Cogitri: would be great if you did. Thanks!
2019-05-04 16:59:12 <Cogitri> Alright, thanks :)
2019-05-04 17:04:01 <ncopa> oh no, i cannot turn my back for 5 mins to update chromium before the PR queue goes up above 300 again
2019-05-04 17:04:03 <ncopa> :)
2019-05-04 17:05:29 <mps> I'm trying rpm with elfutils :)
2019-05-04 17:05:52 <Cogitri> ncopa: Hehe, sorry about that :P
2019-05-04 17:06:18 <Cogitri> Are you going to fix those musl 1.22 issues in Chromium too?
2019-05-04 17:09:06 <mps> ncopa: rpm builds fine with elfutils on x86_64 and aarch64
2019-05-04 17:10:37 <yjftsjthsd> That reminds me - why does alpine package other package managers? I'm aware of at least rpm, dpkg, and pacman. Like, it's *neat* and I approve, but was there some specific usecase?
2019-05-04 17:12:00 <mps> yjftsjthsd: to extract or make these pkg formats
2019-05-04 17:12:33 <mps> it is useful for different things for developers
2019-05-04 17:13:05 <clandmeter> chroots or containers
2019-05-04 17:13:48 <yjftsjthsd> Oh, that makes sense. ...ah, I see we also have debootstrap :)
2019-05-04 17:14:02 <mps> rpm with elfutils also builds on armv7
2019-05-04 17:15:36 <mps> ncopa: should I post patch or you will change rpm to use elfutils-dev
2019-05-04 17:16:24 <mps> besides chromium ;)
2019-05-04 17:16:53 <mps> I think only these two left to depends on libelf
2019-05-04 17:17:36 <ncopa> mps: i think i already did rpm
2019-05-04 17:17:56 <ncopa> is there not aything in testing?
2019-05-04 17:18:16 <mps> didn't find anything else
2019-05-04 17:19:11 <mps> s/find/found/
2019-05-04 17:19:11 <alpine-meetbot> mps meant to say: didn't found anything else
2019-05-04 17:19:20 <ncopa> good
2019-05-04 17:19:24 <ncopa> its only chromium left then
2019-05-04 17:19:30 <ncopa> very nice
2019-05-04 17:20:14 <mps> yes, looks like only chromium is left
2019-05-04 17:20:47 <mps> (which I promised to myself to not touch ever :) )
2019-05-04 17:21:06 <ncopa> mps: can you prepare a patch for perl-libwww? remove the broken test
2019-05-04 17:21:26 <ncopa> then: git format-patch -1 --stdout | tpaste
2019-05-04 17:21:31 <ncopa> and i'll apply it from here
2019-05-04 17:21:35 <mps> yes, will do after evening coffee
2019-05-04 17:21:56 <ncopa> coffe at the evening=
2019-05-04 17:21:57 <ncopa> ?
2019-05-04 17:22:11 <ncopa> i cannot sleep after coffe in the evening
2019-05-04 17:22:19 <ncopa> or, i sleep lighter
2019-05-04 17:22:30 <ncopa> i'll have an evening wine instead :)
2019-05-04 17:22:35 <mps> bad habit, you know, have to work late at this night
2019-05-04 17:22:43 <ncopa> ah. sorry :-/
2019-05-04 17:22:49 <mps> wine to, but after work :)
2019-05-04 17:23:00 <ncopa> yeah :)
2019-05-04 17:28:48 <mps> hey, one line at the end of prepare() in perl-libwww is enough: 'rm -rf t/base/protocols/nntp.t' and pkgrel bump probably
2019-05-04 17:29:10 <mps> or to make proper patch?
2019-05-04 17:34:11 <ncopa> no, i think its enough to rm it
2019-05-04 17:34:21 <ncopa> but dont rm -f it
2019-05-04 17:34:37 <ncopa> we want update our APKBUILD in case it gets removed upstream
2019-05-04 17:35:00 <mps> ok, please do however you think is proper :)
2019-05-04 17:35:48 <mps> eh, I see
2019-05-04 17:36:12 <mps> so, make proper patch patch
2019-05-04 17:36:45 <mps> ok, will do
2019-05-04 17:42:32 <ncopa> rm $file is enough
2019-05-04 17:42:34 <ncopa> i think
2019-05-04 17:43:02 <ncopa> `rm $file` is better than `rm -f $file`
2019-05-04 17:43:07 <ncopa> incase upstream remove it from sources
2019-05-04 17:43:18 <ncopa> then we get error and need update our APKBUILD
2019-05-04 17:43:36 <tcely> I'd like it to show it as being removed (rm -v $file) so the build log has some evidence
2019-05-04 17:43:51 <ncopa> sweet! chomrium has fixed a musl related bug upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=935358
2019-05-04 17:44:02 <ncopa> yeah, rm -v  makes sense
2019-05-04 17:46:35 <mps> ok, will do simplest, i.e. 'rm -v' although started perl proper 'use Test::More skip_all => $reason'
2019-05-04 17:46:41 <Cogitri> ncopa: That's the thing that causes tabs to crash?
2019-05-04 17:51:05 <tcely> ncopa: great! that patch doesn't make a bit of sense to me though. is it a scoping issue or something?
2019-05-04 17:52:15 <doggone> submitted my first patch ^.^
2019-05-04 17:52:23 <Cogitri> Nice :)
2019-05-04 17:52:31 <tcely> doggone: Congratulations!
2019-05-04 17:53:35 <mps> ncopa: here is the perl-libww patch https://patchwork.alpinelinux.org/patch/4836/
2019-05-04 17:57:47 <mps> main/perl-list-moreutils depends on community/perl-list-moreutils-xs, one should be moved
2019-05-04 17:58:37 <ncopa> awesome! thanks!
2019-05-04 17:58:45 <ncopa> ok i think its weekend for me finally
2019-05-04 17:58:50 <mps> yw
2019-05-04 19:09:57 <_ikke_> Cogitri: did you manage to test a fix for nm already?
2019-05-04 19:10:16 <_ikke_> Otherwise I'm inclined to disable it for now
2019-05-04 19:10:23 <_ikke_> (for ppc64le)
2019-05-04 19:10:47 <Cogitri> There's https://github.com/alpinelinux/aports/pull/7551, I'm waiting for feedback from tmhoang on that one
2019-05-04 19:11:11 <_ikke_> Cogitri: alright
2019-05-04 19:11:17 <Cogitri> It should work in theory I suppose
2019-05-04 19:12:44 <_ikke_> Let's try it, it's broken there anyway now
2019-05-04 19:13:16 <Cogitri> Sure
2019-05-04 19:14:19 <_ikke_> Cogitri: pkgrel should be bumped, because you adjusted the package function
2019-05-04 19:14:54 <_ikke_> I can fix that
2019-05-04 19:18:46 <_ikke_> Cogitri: sadface
2019-05-04 19:18:49 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/networkmanager/networkmanager-1.18.1-r1.log
2019-05-04 19:19:19 <Cogitri> I only change the README, didn't think I'd need to bump pkgrel just for that
2019-05-04 19:19:54 <_ikke_> Cogitri: Just to make the package consistent across all arches
2019-05-04 19:20:05 <Cogitri> Ah, alright
2019-05-04 19:21:07 <Cogitri> I'll make a ppc64le VM later I guess
2019-05-04 20:09:24 <doggone> If there were a choice for entropy gathering in setup-alpine, what would be the options and what the default? haveged, rngd, none? Default haveged?
2019-05-04 20:12:32 <mps> check if /dev/hwrng exists, and offer user choice
2019-05-04 20:12:58 <mps> if not, then haveged
2019-05-04 20:14:35 <mps> for machines without HWRNG haveged is only option, besides patching kernel to revert crng to previous behavior
2019-05-04 20:49:21 <doggone> mps: what about rngd? will hwrng be used without it, and if so, what is it even for?
2019-05-04 20:52:03 <mps> I didn't used it because haveged is better for my use cases
2019-05-04 20:53:05 <mps> btw, it need to be upgraded in Alpine
2019-05-04 20:58:24 <mps> doggone: rngd - Check and feed random data from hardware device to kernel random device
2019-05-05 00:33:24 <artok> ncopa: musl-dev should be go dependency, right? without installing musl-dev, there is no way to gcc link because crti.o and others are required...
2019-05-05 00:58:56 <Cogitri> mps: You don't happen to also have a setup script for armhf, do you? :p
2019-05-05 01:32:30 <kaniini> ddevault: hopefully my discussion about sourcehut did not attract too much new traffic
2019-05-05 01:33:21 <ddevault> that's a weird hope to have
2019-05-05 01:33:47 <SpaceToast> the next day, every free github user jumped on srht
2019-05-05 01:36:24 <yjftsjthsd> lol
2019-05-05 01:36:32 <yjftsjthsd> That would not be a bad thing
2019-05-05 01:38:08 <kaniini> ddevault: well having a bunch of new people messing with an alpha version is ... suboptimal I guess :)
2019-05-05 01:38:26 <ddevault> not really
2019-05-05 01:38:31 <ddevault> there are over 8,000 users
2019-05-05 01:39:07 <ddevault> understanding how it behaves under load is useful (and the answer is quite well)
2019-05-05 01:39:26 <ddevault> 8,482, it seems
2019-05-05 01:40:52 <SpaceToast> I still would be interested in seeing some sort of federated git platform (i.e cross-instance discovery through tags)
2019-05-05 01:41:14 <SpaceToast> would run my own in a heartbeat
2019-05-05 01:41:15 <ddevault> sourcehut federates via email
2019-05-05 01:41:35 <SpaceToast> erm, I don't think you can have proper cross-instance discovery via email
2019-05-05 01:41:40 <ddevault> no
2019-05-05 01:41:58 <ddevault> but just look to how well user discovery works on the fediverse to see how easy that is
2019-05-05 01:42:06 <SpaceToast> sure, someone just has to make it :)
2019-05-05 01:46:09 <ddevault> tbh I think discovery is mostly suited to external platforms
2019-05-05 01:46:16 <ddevault> I think that forges shouldn't be social platforms
2019-05-05 01:46:24 <ddevault> but just foster collaboration and good engineering first
2019-05-05 01:46:39 <ddevault> post your project on mastodon and HN and lobsters and progit
2019-05-05 01:47:02 <SpaceToast> so now you need 5-6 accounts, at least 2 of which are on the same platform, effectively
2019-05-05 01:47:10 <ddevault> you'll want to do that anyway, probably
2019-05-05 01:47:18 <SpaceToast> and if you're looking for a given type of project, you're left searching through a bunch of social media posts, rather than for actual code
2019-05-05 01:47:24 <ddevault> duckduckgo
2019-05-05 01:47:32 <SpaceToast> yeah that doesn't work very well before the project is big
2019-05-05 01:47:42 <ddevault> 
ACTION shrugs

2019-05-05 01:47:52 <ddevault> federating makes that harder, not easier
2019-05-05 01:48:03 <yjftsjthsd> Do people actually search for projects on github? I wasn't aware that that was a thing that really got any use
2019-05-05 01:48:13 <SpaceToast> federating = you have a guarantee that #zsh has zsh-related projects as a result
2019-05-05 01:48:29 <SpaceToast> not "omg I love zsh", not "zsh is awful use bash", not "we have zsh completions"
2019-05-05 01:48:40 <ddevault> but not that you'll have all of them, or even necessarily a good subset
2019-05-05 01:48:49 <SpaceToast> yjftsjthsd: it's the *only* real reason I'm still on github - discoverability, and the ability to discover
2019-05-05 01:48:59 <SpaceToast> and it's *the* reason I tag my projects
2019-05-05 01:49:34 <SpaceToast> if it wasn't for that I'd be on my own gitea instance off in the distance :)
2019-05-05 01:49:56 <ddevault> this should probably move to -offtopic
2019-05-05 01:50:06 <SpaceToast> ++
2019-05-05 05:02:13 <ddevault> can we bump the pkgrel on borgbackup? it breaks when msgpack updates
2019-05-05 05:03:52 <north1> It happens every time msgpack updates ?
2019-05-05 05:04:07 <ddevault> when the minor version bumps, yes, I believe so
2019-05-05 05:04:31 <ddevault> ah, it was rebuilt, but is broken in 3.9
2019-05-05 05:05:09 <ddevault> strike that, I'm just dumb
2019-05-05 05:05:15 <ddevault> apparently I'm mixing edge and 3.9 on this box
2019-05-05 05:06:48 <north1> It would be nice to have a message telling about it like it is done on libfilezilla
2019-05-05 05:08:13 <ddevault> no, the package is fine
2019-05-05 05:08:18 <ddevault> I am simply dumb
2019-05-05 05:08:32 <ddevault> there is no action item other than to decrement your ability to take my concerns seriously
2019-05-05 05:10:38 <north1> ok
2019-05-05 06:13:07 <_ikke_> Cogitri: gnome-bluetooth is failing on armv7: https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/gnome-bluetooth/gnome-bluetooth-3.32.1-r0.log
2019-05-05 07:06:14 <hrio[m]> Can pr7320 be merged? Its needed on systems lacking a hwrng and using wpa_supplicant.
2019-05-05 07:28:58 <Cogitri> Ikke: Yes, am working on polkit on more arched rn
2019-05-05 08:48:34 <mps> Cogitri: sorry, didn't had time to make armhf/armv7 qemu install script although I intended to make it
2019-05-05 08:49:40 <mps> I think that one for aarch64 could be adapted and tweaked
2019-05-05 08:50:36 <mps> when I find some time I will do that to have complete alpine arm arches to run under qemu
2019-05-05 08:56:24 <Cogitri> Thanks. I guess I'll just use some ready to go Ubuntu iso or smth and run docker-abuild on then for now
2019-05-05 09:13:22 <mps> qemu 4.0 have some fixes and improvements, pity it is not yet upgraded in alpine
2019-05-05 09:33:12 <tcely> Cogitri: I recommend rancheros for rtg dockry
2019-05-05 09:33:24 <tcely> Docker
2019-05-05 09:35:54 <tcely> https://rancher.com/docs/os/v1.x/en/installation/running-rancheros/
2019-05-05 09:38:59 <mps> uhm, it is not hard to install 'by hand' armhf to run under qemu
2019-05-05 09:39:51 <mps> hard part is write script to automate that and write guide
2019-05-05 09:49:47 <ollieparanoid[m]> ikke: polkit is not available for armhf, armv7 anymore, due to its new dependency on mozjs60, I can imagine that a good part of gnome won't build anymore because of this
2019-05-05 09:50:06 <Cogitri> Am working on this in this moment.
2019-05-05 09:50:37 <ollieparanoid[m]> cogitri: oh cool! how are you approaching this?
2019-05-05 09:51:17 <ollieparanoid[m]> (networkmanager depends on polkit, and networkmanager is in postmarketos-base, so I'm quite invested in this)
2019-05-05 09:51:34 <Cogitri> armv7 just works, armhf has some oddness in Mozilla's configure script
2019-05-05 09:51:47 <Cogitri> Success! Configure works no in armhf!
2019-05-05 09:52:17 <ollieparanoid[m]> awesome :D
2019-05-05 09:53:04 <Cogitri> Now I just have to make the fix less hacky :P
2019-05-05 09:54:53 <Cogitri> Would be helpful if someone posted the output of `cc -Os -dM -E - < /dev/null | sed -n 's/.*__ARM_ARCH_\([[0-9]][[0-9]]*\).*/\1/p'` on armhf
2019-05-05 09:55:08 <ollieparanoid[m]> is qemu good enough?
2019-05-05 09:55:26 <Cogitri> Sure
2019-05-05 09:56:17 <ollieparanoid[m]> cogitri, I get nothing back (empty string)
2019-05-05 09:56:52 <ollieparanoid[m]> but I'm using ccache and some other things, so it might be invalid
2019-05-05 09:57:34 <ollieparanoid[m]> same with /usr/bin/cc at the beginning though
2019-05-05 10:00:06 <Cogitri> Huh, could you try with some random C file instead of /dev/null?
2019-05-05 10:00:36 <ollieparanoid[m]> sure, one moment
2019-05-05 10:02:24 <ollieparanoid[m]> cogitri, same result
2019-05-05 10:03:19 <Cogitri> Alright, I guess I'll just hardcode the thing then
2019-05-05 10:03:35 <z3ntu> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/wFmgiJCweZCQdvVHOqQBwBqr >

2019-05-05 10:03:55 <z3ntu> idk if that helps^^
2019-05-05 10:21:59 <Cogitri> Yup, will sed it in place via CTARGET then. Thanks
2019-05-05 10:40:07 <Cogitri> Do I have to pkgrel bump to enable new arches?
2019-05-05 10:46:48 <ollieparanoid[m]> cogitri: afaik not
2019-05-05 10:47:04 <Cogitri> Good
2019-05-05 10:47:08 <ollieparanoid[m]> I mean, if the only change is enabling the arch. if you change other stuff, then I would change the pkgrel
2019-05-05 10:47:18 <Cogitri> https://github.com/alpinelinux/aports/pull/7561
2019-05-05 10:48:27 <ollieparanoid[m]> \o/ thanks so much!
2019-05-05 10:49:13 <_ikke_> hrio[m]: ncopa merged it :-)
2019-05-05 10:53:19 <Cogitri> ollieparanoid: Mind building the thing locally? Seems like the log output is too much for Drone CI
2019-05-05 10:54:41 <_ikke_> Cogitri: afaik you can still download the raw log from drone
2019-05-05 10:54:44 <ollieparanoid[m]> cogitri: I'll build it locally (with qemu)
2019-05-05 10:54:46 <_ikke_> which should contain everything
2019-05-05 10:55:29 <Cogitri> Doesn't seem like it, _ikke_
2019-05-05 10:55:35 <_ikke_> hmm..
2019-05-05 10:55:48 <Cogitri> The downloaded log just ends with `warning: maximum output exceeded`
2019-05-05 10:56:18 <ollieparanoid[m]> oh wow, it also needs to build autoconf
2019-05-05 10:56:28 <ollieparanoid[m]> but I'll try to build all of them locally.
2019-05-05 10:58:10 <Cogitri> Yeah, but autoconf is easy to build ^^
2019-05-05 11:05:51 <mps> ollieparanoid[m]: you run qemu armhf? if so, which driver you use for virtual disks
2019-05-05 11:06:40 <ollieparanoid[m]> mps: I run chroots and execute arm binaries with qemu through binfmt_misc
2019-05-05 11:07:16 <ollieparanoid[m]> (with pmbootstrap: https://gitlab.com/postmarketOS/pmbootstrap )
2019-05-05 11:07:22 <mps> aha, ok
2019-05-05 11:08:09 <mps> I'm preparing qemu armhf images but couldn't find good virtual disk driver
2019-05-05 11:32:24 <ollieparanoid[m]> cogitri: hm, looks like I can't build it with qemu - it stops in configure: https://bpaste.net/show/4a6ab2e42e36
2019-05-05 11:32:34 <ollieparanoid[m]> that is mozjs60
2019-05-05 11:33:08 <Cogitri> Hum, but it works on Travis which is also virtualized
2019-05-05 11:33:28 <Cogitri> I guess I'll make separate PRs then
2019-05-05 11:33:40 <Cogitri> Thanks for trying :)
2019-05-05 11:33:58 <ollieparanoid[m]> that should work. yw :)
2019-05-05 11:39:16 <ollieparanoid[m]> cogitri, in case you did not see: travis built everything except for autotools: https://api.travis-ci.org/v3/job/528411722/log.txt
2019-05-05 11:39:25 <ollieparanoid[m]> Failed to build packages: main/autoconf2.13
2019-05-05 11:39:27 <ollieparanoid[m]> there downloading the source failed
2019-05-05 11:39:34 <ollieparanoid[m]> (maybe consider switching out ftp for http)
2019-05-05 11:41:15 <Cogitri> Travis doesn't build for armv7/armhf, so it's not really relevant to the PR
2019-05-05 11:41:30 <ollieparanoid[m]> ah true
2019-05-05 11:43:10 <nmeum> ollieparanoid[m]: just changed the $source of autoconf2.13, thanks for pointing that out
2019-05-05 12:09:14 <_ikke_> ncopa: https://github.com/alpinelinux/aports/pull/7089 do we want this in for 3.10?
2019-05-05 12:10:00 <_ikke_> update of libpoppler with 15 packages needing a rebuild
2019-05-05 14:28:06 <ollieparanoid[m]> nmeum: nice
2019-05-05 14:28:28 <ollieparanoid[m]> cogitri: `[ "$CTARGET = "armv* ]` <- is that on purpose? (the placement of the second " after the equals sign)
2019-05-05 14:34:13 <Cogitri> Oops, no. Thanks for the ping
2019-05-05 15:31:41 <tcely> Re drone logs the upstream devs just don't seem to understand the issue well https://github.com/drone/drone/pull/2456
2019-05-05 15:36:41 <Cogitri> :c
2019-05-05 16:30:53 <_ikke_> Anyone got an idea why the build logs for mellow player on ppc64le are not showing up?
2019-05-05 16:31:08 <_ikke_> The build is failing but no logs appeared
2019-05-05 16:56:12 <mksully22> _ikke_ I'm not sure why the logs aren't showing up but trying to build mellowplayer on my ppc64le setup generates ERROR: unsatisfiable constraints: qt5-qtwebengine-dev (missing):,  since qt5-qtwebengine isnt available on ppc64le
2019-05-05 17:00:15 <_ikke_> mksully22: alright, thanks
2019-05-05 17:02:51 <_ikke_> Disabled
2019-05-05 17:03:19 <_ikke_> Now waiting for a typo for s390x to be fixed, and the edge builders should be happy again
2019-05-05 17:27:21 <p4Wv1qn095FW> hrmpf i get 'Huh? Error reporter did not find the broken constraints.' for all apk commands, i tried this https://lists.alpinelinux.org/alpine-devel/5994.html - but the result is that each and every package gives this same error. how can i figure out what is wrong?
2019-05-05 17:28:00 <_ikke_> Hmm, I've heard more users report that, but I don't know how/if they solved it
2019-05-05 17:34:05 <_ikke_> Is it me, or is dl-cdn slow atm?
2019-05-05 17:37:35 <clandmeter> It's a cdn. Big chance somebody else uses a different one.
2019-05-05 17:39:09 <_ikke_> nod
2019-05-05 17:42:00 <_ikke_> clandmeter: would you mind applying https://github.com/alpinelinux/aports/pull/7576? It's fixing a typo and the s390x buidler is stuck atm
2019-05-05 17:42:46 <clandmeter> Not behind keyboard atm
2019-05-05 17:42:56 <_ikke_> ok
2019-05-05 17:43:21 <ncopa> merged
2019-05-05 17:43:32 <Cogitri> Thanks for fixing :)
2019-05-05 17:50:23 <_ikke_> thanks
2019-05-05 17:53:12 <p4Wv1qn095FW> _ikke_: where did you hear users with similar symptoms?
2019-05-05 17:53:48 <_ikke_> irc
2019-05-05 17:53:57 <_ikke_> most like #alpine-linux
2019-05-05 17:54:04 <_ikke_> s/like/likely
2019-05-05 17:54:04 <alpine-meetbot> _ikke_ meant to say: most likely #alpine-linux
2019-05-05 17:55:32 <p4Wv1qn095FW> i'll check my logs
2019-05-05 17:55:36 <p4Wv1qn095FW> thx
2019-05-05 17:56:15 <_ikke_> Cogitri: the irony is that I made a typo in the commit message ;-)
2019-05-05 17:59:33 <p4Wv1qn095FW> i cannot even uninstall pkgs :/
2019-05-05 18:00:02 <ncopa> p4Wv1qn095FW: what does `apk fix` give you?
2019-05-05 18:05:32 <p4Wv1qn095FW> ncopa: ERROR: unsatisfiable constraints:\nHuh? Error reporter did not find the broken constraints.
2019-05-05 18:06:52 <ncopa> p4Wv1qn095FW: do you mix edge repositories with v3.9?
2019-05-05 18:07:16 <p4Wv1qn095FW> nope. only edge
2019-05-05 18:08:19 <ncopa> does `apk info -l '?'` give you anything?
2019-05-05 18:08:40 <ncopa> sorry
2019-05-05 18:08:48 <ncopa> apk version -l '?'
2019-05-05 18:09:48 <ncopa> the error message indicates that apk fails to resolve the dependency graph
2019-05-05 18:09:59 <ncopa> and that it fails to report what went wrong
2019-05-05 18:18:18 <mps> this morning I mentioned qemu 4.0 and it appeared now, hmm someone spying on me :)
2019-05-05 18:18:44 <_ikke_> haha :D
2019-05-05 18:29:28 <ncopa> :)
2019-05-05 18:29:59 <ncopa> or someone tried to be nice ;)
2019-05-05 18:31:04 <ncopa> gcc: internal compiler error: Segmentation fault signal terminated program cc1
2019-05-05 18:31:07 <ncopa> sounds scary
2019-05-05 18:31:35 <_ikke_> a segfault in gcc?
2019-05-05 18:32:20 <ncopa> yup
2019-05-05 18:36:31 <mps> ncopa: thanks :)
2019-05-05 18:37:10 <ncopa> looks like we have a problem with the limited arches for mozjs60
2019-05-05 18:37:29 <ncopa> would be nice to fix arm* at least
2019-05-05 18:37:46 <Cogitri> Yes, I've already opened a PR for that
2019-05-05 18:37:56 <ncopa> oh, you have?
2019-05-05 18:37:58 <ncopa> great!
2019-05-05 18:38:00 <ncopa> url?
2019-05-05 18:38:01 <mps> Cogitri: you asked for armhf install script similar to aarch64 one
2019-05-05 18:38:09 <Cogitri> pr7561
2019-05-05 18:38:40 <mps> I made hackish one for armhf and armv7 if you need them
2019-05-05 18:38:45 <Cogitri> Seems like I broke it on the last push though :P
2019-05-05 18:40:02 <Cogitri> Would be appreciated :)
2019-05-05 18:40:03 <ncopa> atleast armv7 passed
2019-05-05 18:40:14 <ncopa> armhf seems to still be broken
2019-05-05 18:40:32 <ncopa> i suppose we dont bother to support gnome for s390x?
2019-05-05 18:40:37 <ncopa> tmhoang?
2019-05-05 18:40:58 <ncopa> would probably be nice to have mozjs60 working for s390x at least
2019-05-05 18:41:24 <_ikke_> abuild warns about a static file not being in a static subpackage. Could that just be safely added or is it situational / can it break things?
2019-05-05 18:42:42 <mps> Cogitri: just another test before posting it
2019-05-05 18:44:07 <Cogitri> Ikke: Can be safely subpackaged, might break the build of some other package which needs the static lib though
2019-05-05 18:44:38 <_ikke_> Ok, it's a new aport, so I don't think that's the case yet
2019-05-05 18:44:41 <Cogitri> ncopa: Yes, I think my [ "$CTARGET" = "armv*" ] thing doesn't work anymore
2019-05-05 18:44:59 <_ikke_> Why would that not work anymore?
2019-05-05 18:45:20 <ncopa> [ "$CTARGET" = "armv*" ] looks wrong
2019-05-05 18:45:38 <Cogitri> Dunno
2019-05-05 18:45:46 <Cogitri> But that's the only thing I changed
2019-05-05 18:46:19 <ncopa> it will not match armv7
2019-05-05 18:46:23 <Cogitri> (between the revisions of that PR)
2019-05-05 18:46:29 <_ikke_> [ armv7 = "arm*" ] && echo yes || echo no -> no
2019-05-05 18:46:31 <Cogitri> It doesn't have to
2019-05-05 18:46:56 <ncopa> it will only be true when CTARGET is literally 'armv*'
2019-05-05 18:46:58 <Cogitri> It's for armhf
2019-05-05 18:47:08 <Cogitri> Oh, so without quoting?
2019-05-05 18:47:12 <_ikke_> still
2019-05-05 18:47:14 <_ikke_> no
2019-05-05 18:47:24 <ncopa> no, it does not work in posix shell
2019-05-05 18:47:37 <ncopa> i think you can do glob matching in bash probably
2019-05-05 18:47:42 <ncopa> but not in posix shell
2019-05-05 18:47:45 <ncopa> you'll have to do
2019-05-05 18:47:57 <ncopa> case "$CTARGET" in
2019-05-05 18:48:02 <ncopa> armv*) .....;;
2019-05-05 18:48:03 <ncopa> esac
2019-05-05 18:48:05 <Cogitri> Weird, pretty sure it worked previously
2019-05-05 18:48:33 <Cogitri> Wil do, thanks.
2019-05-05 18:51:01 <_ikke_> Cogitri: is that regarding nginx?
2019-05-05 18:51:14 <_ikke_> No mozjs60 I guess
2019-05-05 18:51:57 <_ikke_> nginx is failing on edge-s390x due to wanting luajit.h
2019-05-05 18:52:28 <ncopa> luajit does not work on s390x
2019-05-05 18:52:45 <ncopa> i think work is on the way but i dont think its ready
2019-05-05 18:52:46 <_ikke_> The package pulls in lua5.1-dev in that case
2019-05-05 18:52:53 <ncopa> nginx requries luajit?
2019-05-05 18:52:56 <_ikke_> a module
2019-05-05 18:53:06 <_ikke_> /home/buildozer/aports/main/nginx/src/lua-nginx-module-0.10.15/src/ngx_http_lua_common.h:20:10: fatal error: luajit.h: No such file or directory
2019-05-05 18:53:22 <ncopa> we need to disable luajit for that module on s390x
2019-05-05 18:53:40 <_ikke_> How do you do that?
2019-05-05 18:53:45 <ncopa> no clue
2019-05-05 18:53:54 <_ikke_> The header seems to be included unconditionally
2019-05-05 18:53:56 <ncopa> alternatively we disable the module
2019-05-05 18:54:27 <ncopa> if the lua-nginx-modules requires luajit then we need to disable that module for s390x
2019-05-05 18:58:29 <_ikke_> something like http://tpaste.us/xpml ?
2019-05-05 18:59:49 <Cogitri> pr7580 <- let's see if that works
2019-05-05 19:03:44 <_ikke_> north1: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/folks/folks-0.12.1-r0.log
2019-05-05 19:03:51 <_ikke_> Oh,
2019-05-05 19:03:53 <_ikke_> Cogitri: *
2019-05-05 19:04:41 <_ikke_> folks fails on x86_64
2019-05-05 19:04:53 <_ikke_> on the builders at least
2019-05-05 19:05:22 <_ikke_> I tested it locally and there it worked, and on CI as well
2019-05-05 19:07:21 <Cogitri> Seems like it has been built before the evolution-data-server pkgrel bump
2019-05-05 19:08:20 <Cogitri> Because it can't find ev-ds' GIR which I've enabled in that same PR
2019-05-05 19:08:22 <mps> Cogitri: I see that you are busy, so sorry annoying you, I put two scripts on http://arvanta.net/mps/ if you find them useful, last two links
2019-05-05 19:09:08 <Cogitri> mps: No worries, you're not annoying me (and I'm not that busy, waiting for stuff to compile right now ^^)
2019-05-05 19:09:15 <Cogitri> Thank you for the scripts
2019-05-05 19:09:49 <mps> you could change parameters according your needs, and I'm sure this is not problem for you
2019-05-05 19:26:07 <_ikke_> Anyone got a clue why folks is (apparently) being built before it's dep evolution-data-server on the builders?
2019-05-05 19:30:10 <Cogitri> You could check if the pkgrel of ev-ds has increased to make sure that it has been rebuilt with GIR and Vala
2019-05-05 19:30:29 <_ikke_> D'oh, you are right, it hasn't
2019-05-05 19:30:33 <_ikke_> I should've noticed that
2019-05-05 19:34:08 <ncopa> so... we are reducing the PR queue
2019-05-05 19:34:43 <ncopa> a couple of observations:
2019-05-05 19:34:56 <_ikke_> 
ACTION is all ears

2019-05-05 19:35:33 <ncopa> 1) we have an significant increase of number of PRs
2019-05-05 19:35:48 <_ikke_> I concur
2019-05-05 19:35:59 <ncopa> specially since Cogitri and north1 came along ;)
2019-05-05 19:36:08 <ncopa> second observation:
2019-05-05 19:36:14 <Cogitri> Hehe
2019-05-05 19:36:34 <ncopa> i can see a significant improvement in the quality of the PRs
2019-05-05 19:36:48 <_ikke_> Yes, me too
2019-05-05 19:37:03 <ncopa> specially since Cogitri and north1 came along
2019-05-05 19:37:16 <ncopa> also tcely has helped alot with reviewing the PRs
2019-05-05 19:37:36 <kr0k0> ^^
2019-05-05 19:39:30 <ncopa> and others
2019-05-05 19:39:35 <ncopa> not to forget others
2019-05-05 19:40:09 <_ikke_> for reference: amount of pull requests in the last 3 months: https://imgur.com/a/Z0f2tNp
2019-05-05 19:40:36 <ncopa> that is open pullrequests
2019-05-05 19:40:42 <_ikke_> yes, was about to clarify)
2019-05-05 19:41:00 <ncopa> do you have any graph of new pullrequests per day or similar?
2019-05-05 19:41:09 <_ikke_> ncopa: I'm currently working on that
2019-05-05 19:41:16 <ncopa> or even commits per day
2019-05-05 19:41:45 <mps> _ikke_: did you count patchwork.a.o
2019-05-05 19:42:06 <_ikke_> nope, this is just github
2019-05-05 19:42:07 <ncopa> that is excluding patchwork, which is unfortunately falling behind
2019-05-05 19:42:21 <ncopa> mps: maybe you can help us review patchwork?
2019-05-05 19:42:34 <clandmeter> doesnt mps already do that now?
2019-05-05 19:42:51 <mps> I can, but not sure is it ok
2019-05-05 19:42:54 <ncopa> then he does so good work that i dont even notice it happening :)
2019-05-05 19:43:10 <clandmeter> heh, i didnt check, i just presumed.
2019-05-05 19:43:14 <clandmeter> he is the patchwork guy
2019-05-05 19:43:21 <_ikke_> reviewing is appreciated
2019-05-05 19:43:48 <ncopa> any kinda of help is appreciated
2019-05-05 19:44:00 <ncopa> specially the help that reduces work for us
2019-05-05 19:44:09 <mps> I did some reviews earlier but last time didn't
2019-05-05 19:44:21 <_ikke_> does mps have permissions to change status of patches in PW?
2019-05-05 19:44:36 <ncopa> i think we can give him if not
2019-05-05 19:44:37 <mps> only it's own :)
2019-05-05 19:45:40 <clandmeter> what is your username on pw?
2019-05-05 19:45:54 <mps> nick
2019-05-05 19:45:56 <clandmeter> pw interface is so confusing
2019-05-05 19:46:08 <ncopa> the merging of PRs goes pretty quick, and apparently we break things once in a while
2019-05-05 19:46:09 <mps> my nick here
2019-05-05 19:46:26 <ncopa> when builders break i notice that fixes show up very quick
2019-05-05 19:46:55 <_ikke_> Yes, I feel we should not be afraid of breaking things once in a while, as long as they get fixed timely
2019-05-05 19:47:09 <_ikke_> In edge that is :)
2019-05-05 19:47:11 <ncopa> so all in all, i am very happy with the work that gets done
2019-05-05 19:47:13 <Cogitri> (At least on Edge)
2019-05-05 19:47:16 <_ikke_> yes
2019-05-05 19:47:59 <_ikke_> otherwise you get a paralysis that halts work
2019-05-05 19:48:08 <ncopa> and I am very thankful for all the help we get
2019-05-05 19:48:28 <ncopa> and I am thankful for the patiences and understanding everyone shows
2019-05-05 19:48:29 <mps> btw, when we are at pw, could someone check and push mupdf patch, it needs to be upgraded and after that it need some security patches
2019-05-05 19:48:50 <ncopa> its very frustrating to push a PR and it takes ages before its reviewd
2019-05-05 19:48:58 <ncopa> or even gets closed by stale-bot
2019-05-05 19:49:15 <ncopa> so big thank you to everyone
2019-05-05 19:49:21 <_ikke_> ncopa: I've pushed an update to the stale bot message
2019-05-05 19:49:26 <_ikke_> in the PR
2019-05-05 19:49:32 <ncopa> good!
2019-05-05 19:49:45 <ncopa> mps: url?
2019-05-05 19:49:53 <mps> well, keeping distro is not easy task
2019-05-05 19:50:06 <ncopa> indeed
2019-05-05 19:50:13 <_ikke_> https://github.com/alpinelinux/aports/pull/6831
2019-05-05 19:50:34 <ncopa> one thing more
2019-05-05 19:50:37 <mps> ncopa: http://arvanta.net/mps/
2019-05-05 19:51:30 <ncopa> we manage to get all this work done, and despite of frustrations and breakages etc, we manage to keep a friendly and positive work environment
2019-05-05 19:51:33 <clandmeter> mps can you do more now?
2019-05-05 19:51:37 <clandmeter> on pw
2019-05-05 19:51:42 <ncopa> that imho is priceless
2019-05-05 19:53:30 <ncopa> _ikke_: very good
2019-05-05 19:53:41 <ncopa> the tone in the message is much nicer
2019-05-05 19:54:58 <mps> clandmeter: yes, I see options to change status for other's patches
2019-05-05 19:55:14 <clandmeter> good
2019-05-05 19:56:11 <ncopa> mps: nice! but meant the url to the mupdf patch you want me to merge
2019-05-05 19:56:37 <_ikke_> https://patchwork.alpinelinux.org/patch/4834/
2019-05-05 19:57:01 <_ikke_> clandmeter: If you are at it any way, would you mind adding me as well to pw? (kdaudt)
2019-05-05 19:57:01 <mps> oh, sorry, clipboard is stuck
2019-05-05 19:57:05 <Cogitri> ncopa: Well, I have to say thanks to everyone who's looked at my stuff and helped me get started with Alpine (and sorry for the breakage) :)
2019-05-05 19:57:19 <mps> https://patchwork.alpinelinux.org/patch/4834/
2019-05-05 19:58:49 <clandmeter> _ikke_: done
2019-05-05 19:58:53 <clandmeter> inc full admin
2019-05-05 19:58:55 <_ikke_> clandmeter: thanks :)
2019-05-05 20:00:05 <_ikke_> Talking about breaking things, how do I unbreak folks now ..
2019-05-05 20:00:39 <SpaceToast> \o all
2019-05-05 20:00:43 <_ikke_> SpaceToast: hi
2019-05-05 20:00:55 <_ikke_> Join this moment of self-reflection
2019-05-05 20:01:11 <SpaceToast> yeah, I've been watching for a while, and didn't want to poke in :)
2019-05-05 20:02:11 <SpaceToast> which, another "speaking-of-breaking-things"
2019-05-05 20:02:37 <SpaceToast> I've been working on a convenience function for abuild for a bit now, for subpackage splitting in a safe and DRY way
2019-05-05 20:02:49 <SpaceToast> and I think I'm satisfied with it now
2019-05-05 20:03:01 <SpaceToast> any chance someone could take a look (whenever is fine) before I actually open the PR up? :)
2019-05-05 20:03:20 <ncopa> can it wait til post 3.10?
2019-05-05 20:03:35 <SpaceToast> yes
2019-05-05 20:03:56 <SpaceToast> I'd rather it be merged before all the new default_ functions for completions etc
2019-05-05 20:04:06 <SpaceToast> since I think it can significantly simplify those
2019-05-05 20:04:11 <_ikke_> I can imagine
2019-05-05 20:04:22 <_ikke_> is it like vmove that Cogitri / north1 talk about?
2019-05-05 20:04:32 <SpaceToast> roughly
2019-05-05 20:04:45 <SpaceToast> it's significantly simpler (read: "dumber"), but I see that as a good thing for auditing and testing
2019-05-05 20:04:55 <SpaceToast> (which I also have a bats test suite for the pre-abuild.in version)
2019-05-05 20:06:10 <kr0k0> Cogitri: Yes, that's true. A really nice community. I'm currently at that point.
2019-05-05 20:17:42 <SpaceToast> ncopa: anything I can do to help out with 3.10?
2019-05-05 20:21:00 <ncopa> SpaceToast: look over bugs.a.o and try fix things that needs to be fixed before 3.10 release
2019-05-05 20:21:11 <ncopa> also build fixes for the 3.10 builders
2019-05-05 20:21:33 <SpaceToast> okay, I'll mark that as something to do up until the release :)
2019-05-05 20:38:44 <doggone> I have a free unlimited 1Gbps up/down fiber link for about a year. Can I help Alpine with that? Maybe as a mirror?
2019-05-05 20:40:14 <_ikke_> `this is the current mirror list; https://mirrors.alpinelinux.org/
2019-05-05 20:41:00 <_ikke_> In europe we already have 10/20gbps mirrors
2019-05-05 20:41:40 <doggone> I'm based near in Belgium so it's probably not interesting. Also it will only be for a year, I estimate
2019-05-05 20:53:42 <andypost[m]> Why there's no luajit for s390x? Chroot works weird for it
2019-05-05 20:54:06 <andypost[m]> Interesting how nginx passed before
2019-05-05 20:54:26 <_ikke_> Yeah, I'm not sure what changed
2019-05-05 20:56:58 <mps> is the s390x builder updated
2019-05-05 20:58:06 <_ikke_> updated in what sense?
2019-05-05 20:58:19 <mps> for 3.10 build
2019-05-05 20:58:30 <_ikke_> that's a separate builder
2019-05-05 20:59:03 <mps> ah, so this one is edge
2019-05-05 20:59:33 <_ikke_> yes
2019-05-05 20:59:58 <mps> understand now, edge is always active
2019-05-05 21:00:21 <mps> thanks _ikke_
2019-05-05 21:00:45 <_ikke_> no problem
2019-05-05 21:25:45 <jwh> hm, doesn't -virt include the vmxnet drivers?
2019-05-05 21:28:38 <jwh> oh hm
2019-05-05 21:30:14 <jwh> stupid vmware
2019-05-06 01:47:17 <north1> the PR number dropped so much
2019-05-06 01:50:17 <north1> ldpath doesn't appear on APKBUILD reference
2019-05-06 05:11:27 <_ikke_> mps: mupdf is failing on s390x
2019-05-06 05:11:32 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/mupdf/mupdf-1.14.0-r0.log
2019-05-06 05:53:58 <kr0k0> morning
2019-05-06 05:59:12 <Cogitri> Morning
2019-05-06 06:05:22 <ncopa> morning
2019-05-06 06:06:05 <north1> hi
2019-05-06 06:06:48 <kr0k0> Hi guys, sorry, next question from my side.
2019-05-06 06:07:18 <kr0k0> I want to change file owner in a package (testing/vdr)
2019-05-06 06:07:58 <kr0k0> I have added pkgusers, pkggroups and a chown to package function, but I get permission denied.....
2019-05-06 06:08:19 <kr0k0> Is that not the correct way?
2019-05-06 06:08:35 <ncopa> kr0k0: sounds like the correct way to me
2019-05-06 06:08:41 <ncopa> how do you run it?
2019-05-06 06:09:28 <kr0k0> Not with root, but my user is in the abuild group
2019-05-06 06:09:55 <ncopa> `abuild -r`?
2019-05-06 06:10:04 <kr0k0> sorry
2019-05-06 06:10:06 <kr0k0> Yes
2019-05-06 06:10:14 <ncopa> can i have a look at the APKBUID? tpaste < APKBUILD
2019-05-06 06:10:37 <kr0k0> sure, one moment please
2019-05-06 06:11:44 <kr0k0> http://tpaste.us/yPEd
2019-05-06 06:14:44 <ncopa> kr0k0: it looks correct
2019-05-06 06:15:23 <ncopa> can you try run `chmod -v -R ....` so we see what files it tries to modify?
2019-05-06 06:16:12 <kr0k0> Ok, thanks. I have started again the build and paste the log afterwards
2019-05-06 06:16:25 <kr0k0> Ah ok, with verbose option
2019-05-06 06:17:14 <Cogitri> Huh, why have config files owned by the package user though πŸ€”
2019-05-06 06:18:34 <kr0k0> Because configuration can be modified via vdr itself
2019-05-06 06:18:54 <kr0k0> Also the channels will be updated via vdr process.
2019-05-06 06:30:55 <Cogitri> Ah, alright
2019-05-06 07:03:36 <kr0k0> Ok, it works...
2019-05-06 07:03:49 <kr0k0> I don't know, what I did wrong -.-
2019-05-06 07:04:03 <kr0k0> Thanks for your help!
2019-05-06 07:19:29 <ncopa> i woul dlike to tag new edge snapshot today
2019-05-06 07:19:32 <ncopa> and 3.9.4 release
2019-05-06 07:21:22 <kr0k0> Oh no, I want to move vdr to community before 3.10 ^^. I know you have more important things....
2019-05-06 07:21:32 <north1> ncopa: there is pr7588 that fixes 3 CVEs
2019-05-06 07:21:39 <north1> by updating libpng to 1.6.37
2019-05-06 07:24:55 <clandmeter> ncopa: snapshots do not test changes in release scripts right?
2019-05-06 07:28:58 <ncopa> it tests only netboot and minirootfs i think
2019-05-06 07:29:26 <ncopa> we will test the others in release candidates as soon the 3.10 builders are done
2019-05-06 07:31:21 <clandmeter> ok i will merge my rpi changes
2019-05-06 07:31:42 <ncopa> are they bugfixes that should be backported to 3.9?
2019-05-06 07:32:07 <clandmeter> one bugfix yes
2019-05-06 07:32:15 <clandmeter> i htink i already pushed it
2019-05-06 07:32:46 <clandmeter> https://git.alpinelinux.org/aports/commit/scripts?id=a9871bd0b7521a48232094152cb2327d291945e3
2019-05-06 07:33:41 <clandmeter> i can cherry-pick that one
2019-05-06 07:33:56 <ncopa> didt we fix that for 3.9.3?
2019-05-06 07:34:11 <clandmeter> i was past .3 i think?
2019-05-06 07:34:15 <clandmeter> it*
2019-05-06 07:35:05 <ncopa> commit 435e10f2afe2bf11c678706e0df9b40f3648d44f
2019-05-06 07:35:21 <ncopa> oh, i see, it was a regression
2019-05-06 07:35:47 <ncopa> #10155
2019-05-06 07:38:35 <clandmeter> ah you already tagged new mkinitfs release after my changes
2019-05-06 07:38:47 <ncopa> north1: thanks for the libpng  fix
2019-05-06 07:39:06 <ncopa> north1: would be nice to have the CVE's mentioned in commit message as well
2019-05-06 07:39:22 <north1> will keep in mind
2019-05-06 07:39:32 <ncopa> then i dont need to use `git blame` to find the commit that fixes a given CVE
2019-05-06 07:42:31 <clandmeter> ncopa: when will you do a new patch release?
2019-05-06 07:44:43 <ncopa> i was thinking today
2019-05-06 07:47:38 <hrio[m]> ncopa: backport candidate https://git.alpinelinux.org/aports/commit/?id=caec29f551955d6a6392943708652db0f8bc4a17
2019-05-06 08:00:04 <tmhoang> <ncopa> i suppose we dont bother to support gnome for s390x?   ---> I guess yes. Even mozjs stuff, if it costs a lot of man power and man time.
2019-05-06 08:00:41 <tmhoang> <Cogitri> : Hi, long weekend ... (or too short :D) I'm building your patch rn if I still make sense
2019-05-06 08:01:35 <tmhoang> *go back fixing brokage
2019-05-06 08:02:05 <Cogitri> Ah, no worries. Seems like my patch doesn't work though, so I'll open a bug upstream
2019-05-06 08:02:11 <tmhoang> algitbot was drunk during the weekend, he turned red.
2019-05-06 08:17:49 <Cogitri> ikke: Do you have a buildlog for ppc64 NM? Gonna file a bug upstream
2019-05-06 08:18:16 <_ikke_> Cogitri: let me check
2019-05-06 08:19:34 <Cogitri> Thanks
2019-05-06 08:19:50 <_ikke_> Cogitri: here you go: https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/networkmanager/networkmanager-1.18.1-r1.log
2019-05-06 08:29:50 <Cogitri> _ikke_: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/171 thanks :)
2019-05-06 08:33:34 <_ikke_> (y)
2019-05-06 08:36:44 <fabled> hum. i wonder what has happened. after latest apk upgrade on edge, xfce stopped working properly and i'm getting all kind of dbus/polkit/console-kit-daemon errors
2019-05-06 08:37:19 <_ikke_> polkit has been updated
2019-05-06 08:37:24 <mps> _ikke_: yes, I noticed mupdf fail on s390x last night (remember I asked you is it upgraded), please disable it on this arch
2019-05-06 08:37:55 <_ikke_> It's on main, so someone else has to push it
2019-05-06 08:37:58 <Cogitri> You might have to restart, fabled
2019-05-06 08:38:08 <fabled> yes, i've restarted twice
2019-05-06 08:38:27 <Cogitri> Try starting /usr/lib/polkit-1/polkitd then please
2019-05-06 08:38:28 <fabled> it got errors of missing polkitd user, which i created manually. but now i get timeouts
2019-05-06 08:39:05 <Cogitri> Huh, weird, the pre-install definitely should crate that :o
2019-05-06 08:40:17 <fabled> i don't see that kind of install script in any of the packages in aports
2019-05-06 08:41:39 <Cogitri> See main/polkit/polkit.pre-install
2019-05-06 08:44:31 <fabled> oh. needed git pull.
2019-05-06 08:44:35 <fabled> that needs to be in pre-upgrade too
2019-05-06 08:44:50 <_ikke_> git pull?
2019-05-06 08:45:41 <clandmeter> if you upgrade the script wont run
2019-05-06 08:46:06 <clandmeter> so if you add the user afterwards you need to do pre-upgrade
2019-05-06 08:47:11 <Cogitri> Oh, thought that'd be run then too
2019-05-06 08:47:21 <fabled> ok. looks better now after running the script manually. restarting X to see if things work better now
2019-05-06 08:47:26 <Cogitri> I guess I'll have to fix colord too then
2019-05-06 08:47:33 <clandmeter> symlink it
2019-05-06 08:47:37 <clandmeter> and add it
2019-05-06 08:47:53 <Cogitri> Will do, thanks.
2019-05-06 08:49:38 <_ikke_> Does it work better now?
2019-05-06 08:49:50 <fabled> ok. it's better, but now I got after login an error popup: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject
2019-05-06 08:50:08 <fabled> dmesg has: console-kit-daemon[8093]: WARNING: failed to run script: Failed to execute child process “/usr/bin/pm-is-supported” (No such file or directory)
2019-05-06 08:50:29 <fabled> but no more timeouts and hangs
2019-05-06 08:51:18 <north1> There are packages that pass --libexecdir=/usr/lib while others just let it install to /usr/libexec
2019-05-06 08:51:26 <north1> which is it ? or is it a maintainer choice ?
2019-05-06 08:54:23 <Cogitri> fabled: Hum, I don't really know CK2, I use elogind :c
2019-05-06 08:56:03 <mps> north1: imo, it should be /usr/libexec and not choice
2019-05-06 08:57:17 <Cogitri> fabled: Mind install pm-utils and trying again?
2019-05-06 08:57:37 <Cogitri> (Although I doubt that that's it)
2019-05-06 09:01:59 <fabled> mmm. ok. will test after lunch.
2019-05-06 09:02:45 <north1> mps: ok, is there any policy on this ?
2019-05-06 09:03:20 <mps> best practice, afaik
2019-05-06 09:04:10 <TBB> lib for libs, libexec for executables
2019-05-06 09:04:10 <mps> we talked few months ago about writing Alpine packaging policy
2019-05-06 09:04:18 <TBB> in general
2019-05-06 09:06:23 <north1> ok
2019-05-06 09:06:55 <mps> would be nice if someone write proposal for packaging policy, no need for long and exhaustive, just to have something to start from
2019-05-06 09:15:45 <mps> I'm thinking about making slim DM without consolekit/polkit support for people who do not need heavy/featerufull DE. Is it good or bad idea?
2019-05-06 09:18:15 <Cogitri> Well, IMO consolekit/elogind are way better than SUID, but oh well
2019-05-06 09:19:14 <mps> agree, but some people want lightweight system
2019-05-06 09:19:49 <ncopa> looks like polkit broke on my laptop aswell. i cannot power down anymore
2019-05-06 09:20:37 <Cogitri> Most likely the missing polkitd user on upgrade
2019-05-06 09:20:52 <Cogitri> pr7594
2019-05-06 09:21:03 <mps> Cogitri: Alpine is Small, Simple, Secure at the end
2019-05-06 09:21:21 <Cogitri> Yeah, and suid isn't exactly secure
2019-05-06 09:22:16 <mps> yes, I thought to add '^W' after Secure
2019-05-06 09:23:20 <mps> having a lot of moving components is path to instability and less security
2019-05-06 09:47:33 <fabled> Cogitri, added pm-utils. i the pm-is-supported is now there. removed xfce-polkit and the policykit1 error popup disappeared
2019-05-06 09:48:27 <Cogitri> Hum, I suppose it's more on the latter then
2019-05-06 09:48:28 <Cogitri> But then authentication should be broken
2019-05-06 12:57:13 <north1> the builders are failing to build graphicsmagick
2019-05-06 12:57:14 <north1> but it works locally
2019-05-06 13:16:18 <ncopa> looks like parallel `make install` problem
2019-05-06 13:16:37 <ncopa> I cannot reproduce locally either
2019-05-06 13:21:12 <north1> worth trying
2019-05-06 13:47:12 <ncopa> libical update broke abi. we need to rebuild everything linked against so:libical.so.2
2019-05-06 14:06:16 <ncopa> looks like https://www.openprinting.org is offline :-/
2019-05-06 14:22:39 <danieli> lol Secure^w
2019-05-06 14:23:31 <danieli> and yes, it's resolving with SERVFAIL
2019-05-06 14:23:55 <danieli> correction, it's *not* resolving, with SERVFAIL
2019-05-06 14:52:27 <ncopa> stupid me..i pushed cups-filters
2019-05-06 14:52:32 <ncopa> im losing it
2019-05-06 14:53:09 <clandmeter> i never had it
2019-05-06 14:53:56 <ncopa> we need fix edge builders
2019-05-06 14:54:30 <clandmeter> ah thats the openprinting one
2019-05-06 15:28:46 <TBK[m]> ncopa: as an alternative GH could be used as the src - https://github.com/OpenPrinting/cups-filters/releases
2019-05-06 15:31:11 <tmhoang> ncopa: https://github.com/alpinelinux/aports/pull/7618. I will send some others to re-enable mozjs60 rdeps later.
2019-05-06 15:31:46 <tmhoang> oh, nice : @probot-autolabeler probot-autolabeler bot added the R-main label just now
2019-05-06 15:31:52 <tmhoang> algitbot has a friend
2019-05-06 15:33:52 <Cogitri> Nice :)
2019-05-06 15:36:55 <tcely> tmhoang: probot-autolabeler is even quicker than _ikke_ was ;-)
2019-05-06 15:37:33 <tmhoang> :D
2019-05-06 15:37:36 <TBK[m]> cogitri: can mozjs60 be build with py3?
2019-05-06 15:37:54 <tmhoang> TBK[m] : I still see python2 hardcoded
2019-05-06 15:37:57 <Cogitri> Don't think so
2019-05-06 15:38:04 <TBK[m]> :(
2019-05-06 15:38:26 <Cogitri> Actually, I think it probes for py3 somewhere down the line but the config scripts still are py2 IIRC
2019-05-06 15:38:55 <Cogitri> :c
2019-05-06 15:39:20 <TBK[m]> btw the url is broken, should be https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey
2019-05-06 15:40:02 <ncopa> TBK[m]: nice! that github thing works
2019-05-06 15:40:36 <TBK[m]> ncopa: I am working on a pr
2019-05-06 15:41:00 <TBK[m]> to fix the issue related to poppler
2019-05-06 15:56:33 <ncopa> tmhoang: thanks!
2019-05-06 15:57:02 <tmhoang> ncopa: I will try to fix other non-mozjs failures tomorrow. Good night :)
2019-05-06 15:57:12 <ncopa> tmhoang: good night!
2019-05-06 16:08:15 <_ikke_> tcely: that bot took my job ;-)
2019-05-06 16:11:04 <ncopa> firefox is broken
2019-05-06 16:11:18 <ncopa> https://build.alpinelinux.org crashes the tab
2019-05-06 16:15:01 <Cogitri> I think that might be on that seccomp thingie too?
2019-05-06 16:43:25 <ncopa> could be
2019-05-06 16:43:31 <ncopa> i thought we had a patch for that?
2019-05-06 16:43:39 <ncopa> maybe that was only firefox-esr
2019-05-06 18:23:59 <mps> looking to https://patchwork.alpinelinux.org/patch/3916/ I see it is applied year ago but still is marked as new
2019-05-06 18:24:28 <mps> should I change it to Accepted or Superseded
2019-05-06 18:24:43 <_ikke_> If it's applied, I would say accepted
2019-05-06 18:25:18 <mps> ok, then will change it to applied. thanks
2019-05-06 18:25:32 <jwh> hey mps are you doing triage?
2019-05-06 18:26:38 <mps> jwh: yes, trying to resolve some old patches
2019-05-06 18:26:42 <jwh> ah cool
2019-05-06 18:28:02 <_ikke_> mps is keeping an eye on patchwork for us
2019-05-06 18:28:13 <jwh> o/
2019-05-06 18:29:17 <mps> If I can fix one of it in a day will be good
2019-05-06 18:32:08 <mps> Is Laurent B. here? I remember see him from time to time
2019-05-06 18:53:03 <ncopa> no, but i think he hangs around in #musl
2019-05-06 18:58:35 <danieli> yeah, look for skarnet
2019-05-06 19:07:14 <mps> danieli: thanks, although i remember his nick
2019-05-06 19:34:10 <ncopa> seems like i didnt manage to get edge snapshot release today :-/
2019-05-06 19:55:12 <ncopa> whats up with mtd-utils? seems like builders tries to rebuild it ever push
2019-05-06 19:56:45 <ncopa> mtd-utils has subpackages with arch=all
2019-05-06 20:02:19 <mps> ncopa: thanks for fix mupdf
2019-05-06 20:17:46 <_ikke_> ncopa: hmm, I apparently didn't catch that
2019-05-06 20:18:53 <_ikke_> ncopa: should abuild sanitycheck catch that?
2019-05-06 21:12:17 <mps> main/libee site doesn't work, show some loganalyzer site
2019-05-06 21:14:51 <mps> and, looks like nothing in apports depends on libee
2019-05-06 21:18:20 <TBK[m]> note from rsyslogs libee fork: "a now-obsolete library that should no longer be used (and probably is not) "
2019-05-06 21:20:20 <mps> so, I think it could be removed or moved to unmaintained
2019-05-06 21:29:53 <TBK[m]> mps: I think we can remove it since has been replaced and upstream is gone
2019-05-06 21:31:50 <mps> TBK[m]: this should do someone with aports main access
2019-05-06 22:14:48 <mps> fix for build of main/mpt-status is here https://patchwork.alpinelinux.org/patch/4838/
2019-05-06 22:44:34 <jwh> hm
2019-05-06 22:44:45 <jwh> is anyone working on asterisk 1.8?
2019-05-06 22:44:48 <jwh> uh
2019-05-06 22:44:48 <jwh> 18
2019-05-06 22:44:57 <jwh> or am I going masd
2019-05-06 22:45:13 <jwh> nope, mad
2019-05-06 22:45:40 <mps> jwh: maybe freeswitch is better maintained
2019-05-06 22:45:56 <jwh> no its fine, long day... being dumb :P
2019-05-06 22:51:51 <mps> main/debian-archive-keyring build fix on 3.10 is here https://patchwork.alpinelinux.org/patch/4839/
2019-05-06 23:13:37 <jwh> hm, needs some asterisk 17
2019-05-07 02:11:04 <SpaceToast> https://bugs.alpinelinux.org/issues/10219 should be closed
2019-05-07 04:52:47 <north1> Need opinons on this
2019-05-07 04:53:19 <north1> default_openrc should add a dependency on ${subpkgname%-openrc} not $pkgname
2019-05-07 04:56:16 <_ikke_> Some people are of opinion we should avoid sub-subpacakges (Where I can imagine this is the issue)
2019-05-07 06:36:37 <north1> Should -udev-scripts be split ?
2019-05-07 06:36:49 <north1> scripts == rules and other stuff that is part of udev/eudev
2019-05-07 07:23:01 <tmhoang> Morning _ikke_ ! Regarding https://github.com/alpinelinux/aports/pull/7623, you prefer me to enable able 1 arch per commit ?
2019-05-07 07:24:34 <clandmeter> i think he means you bundle the polkit PR as its depends on it?
2019-05-07 07:25:24 <clandmeter> and good morning :)
2019-05-07 07:26:33 <Cogitri> That's merged already though, isn't it?
2019-05-07 07:26:49 <clandmeter> would have been fun to see a single commit per arch :)
2019-05-07 07:27:30 <clandmeter> Cogitri: no not yet
2019-05-07 07:28:09 <clandmeter> mozjs does which is needed for polkit
2019-05-07 07:28:26 <Cogitri> Ah, right, s390x, forgot about that
2019-05-07 07:30:40 <clandmeter> CI doesnt do s390x so in this case its doesnt mater much, but in general we should bundle commits that depend on each other.
2019-05-07 07:43:56 <_ikke_> tmhoang: #7623 depends on #7621
2019-05-07 07:44:01 <_ikke_> oops
2019-05-07 07:44:11 <_ikke_> tmhoang: pr7623 depends on pr7621
2019-05-07 07:44:27 <_ikke_> That in theory could be a single PR
2019-05-07 07:44:46 <tmhoang> clandmeter: bundle commits that depend on each other ?
2019-05-07 07:44:53 <_ikke_> tmhoang: In a single pull request
2019-05-07 07:46:01 <tmhoang> _ikke_ : really ? Interesting. I didn't know that. Do you want me to close those and create a new PR for all these commits ?
2019-05-07 07:46:22 <clandmeter> its ok
2019-05-07 07:46:33 <tmhoang> clandmeter : thanks :D
2019-05-07 07:46:35 <clandmeter> it doesnt work now anyways
2019-05-07 07:46:39 <tmhoang> lol ok
2019-05-07 07:46:39 <clandmeter> due to CI
2019-05-07 07:47:31 <tmhoang> I wonder if drone work in slave-master scheme. So I can provide you an s390x slave, and we could make it join the drone cluster real quick.
2019-05-07 07:47:50 <_ikke_> I think you need your own drone infra for that, right?
2019-05-07 07:47:55 <_ikke_> not drone cloud
2019-05-07 07:48:07 <clandmeter> drone cloud is not managed by us
2019-05-07 07:48:18 <clandmeter> i talked to brad but i didnt see any activity
2019-05-07 07:48:47 <_ikke_> But this is also an issue of a community package depending on a main package in the same PR, right?
2019-05-07 07:48:51 <clandmeter> tmhoang: i think you never hear anything from drone ppl?
2019-05-07 07:49:10 <tmhoang> clandmeter: no. Not a thing
2019-05-07 07:49:35 <clandmeter> tmhoang: you could join https://gitter.im/drone/drone and ping him
2019-05-07 07:50:37 <tmhoang> clandmeter: Good news is with qemu 4.1, or even 4.0 now. You can run qemu in TCG mode (instead of KVM) to run s390x guest. It's still native and not cross-compiling. In fact this is what IBM plans to proceed to allow community where they dont accept s390x slave that they prefer all the builders to be in their infra, aka x86 infra.
2019-05-07 07:51:25 <tmhoang> in fact you can run with qemu 2.11 or 3.0 but it could be a little bit slower to 4.x. I just wonder if this is a path drone or we (Alpine project) would like to consider for CI
2019-05-07 07:51:54 <tmhoang> TCG experience vs KVM experience is the same, except TCG is a little bit slower, so for CI I think it's fine
2019-05-07 07:53:03 <clandmeter> is that on x86 hardware?
2019-05-07 07:53:44 <tmhoang> clandmeter: Could we, Alpine project, set up our own Jenkins (or alternative) master some where in Alpine infra and connects all the slaves (x86, arm*, ppc*, s390x) together ? I think it would work out pretty good, compared to relying on other's infra. I mean we have  more control.
2019-05-07 07:54:07 <tmhoang> clandmeter: Yes, x86 hardware. TCG means emulation.
2019-05-07 07:54:26 <clandmeter> what is the performance impact?
2019-05-07 07:54:50 <tmhoang> I couldn't tell.
2019-05-07 07:54:58 <clandmeter> tmhoang: yes we can setup our own system
2019-05-07 07:55:12 <clandmeter> everything is possible would ncopa say
2019-05-07 07:55:42 <tmhoang> I have nothing against drone, just spitballing here about options for CI
2019-05-07 07:56:03 <clandmeter> i think i like drone
2019-05-07 07:56:21 <_ikke_> We will probably go with gitlab, where you can deploy gitlab runners
2019-05-07 07:56:33 <clandmeter> and currently its easy cause it doesnt need maintenance
2019-05-07 07:56:40 <tmhoang> good points
2019-05-07 07:57:05 <_ikke_> I'm also dabling a bit with buildbot, where you can deploy workers
2019-05-07 07:57:18 <clandmeter> but we could try a test with qemu
2019-05-07 07:58:18 <tmhoang> clandmeter : https://wiki.qemu.org/Documentation/Platforms/S390X#Debian_Install_Example_.28TCG.29. You may need qemu 3.x for debian new kernel (4.4 or 4.9+ iirc)
2019-05-07 08:02:06 <clandmeter> _ikke_: isnt that a general feature for CI?
2019-05-07 08:05:02 <_ikke_> clandmeter: What?
2019-05-07 08:05:19 <_ikke_> I don't think jenkins has remote workers
2019-05-07 08:05:24 <_ikke_> not sure though
2019-05-07 08:05:28 <Cogitri> Gitlab runner is very nice, yes
2019-05-07 08:06:29 <Gottox> jenkins can have remote runners.
2019-05-07 08:07:28 <Cogitri> Gitlab CI is nicely integrated (into Gitlab that is) though and super easy to use
2019-05-07 08:09:00 <tmhoang_> _ikke_: Jenkins do have remote works/slaves
2019-05-07 08:10:05 <_ikke_> ok\
2019-05-07 08:13:55 <_ikke_> And I do agree that gitlab CI integration is nice
2019-05-07 08:19:34 <danieli> jenkins is terrible
2019-05-07 08:20:08 <mps> build fix for main/debian-archive-keyring is here https://patchwork.alpinelinux.org/patch/4839/
2019-05-07 08:20:47 <mps> also, fix for build of main/mpt-status is here https://patchwork.alpinelinux.org/patch/4838/
2019-05-07 08:24:28 <mps> main/libee should be removed or moved to unmaintained, no pkg depends on it and it is not maintained upstream; site is inaccessible
2019-05-07 08:24:58 <north1> mps: I can make a PR for it after i'm done with appstream-glib
2019-05-07 08:26:10 <mps> also I can post patch but wanted to hear what other thinks
2019-05-07 08:26:59 <tmhoang> _ikke_ : any news/progress on moving to gitlab ? I guess we do it after 3.10
2019-05-07 08:27:09 <mps> I mean to say, about main/libee
2019-05-07 08:28:29 <mps> and main/libelf also, no pkg depends on it, afaik
2019-05-07 08:33:39 <north1> mps: chromium depends on libelf
2019-05-07 08:33:52 <north1> doesn't link to it though
2019-05-07 08:33:58 <north1> so it might be an obsolete dependency
2019-05-07 08:35:16 <mps> north1: iirc, ncopa works to make chromium deps to elfutils instead of libelf
2019-05-07 08:35:53 <north1> speaking of elfutils it would be nice to build the eu- tools as well.
2019-05-07 08:36:04 <mps> didn't looked if he finished
2019-05-07 08:36:47 <mps> eu-tools, do you have url?
2019-05-07 08:37:09 <mps> elf utils?
2019-05-07 08:37:48 <north1> elfutils APKBUILD just builds libelf currently
2019-05-07 08:38:29 <mps> yes, now remember. good idea
2019-05-07 08:44:28 <_ikke_> tmhoang: I believe mort___1 was working on something
2019-05-07 08:48:11 <clandmeter> _ikke_: ?
2019-05-07 09:03:46 <tmhoang> I have seen message recently after rebasing aports master : http://tpaste.us/W1zv. Any idea ?
2019-05-07 09:09:46 <ncopa> morning
2019-05-07 09:10:20 <north1> ncopa: morning
2019-05-07 09:10:33 <Cogitri> Morning
2019-05-07 09:10:53 <ncopa> _ikke_: yes, letting abuild sanity check for arch=all in subpackages is probably a good idea
2019-05-07 09:11:34 <ncopa> if nothing uses libee and its dead upstream, then i think we can simply remove it
2019-05-07 09:14:26 <mps> ncopa: last night TBK[m] and I looked at libee, it seems it is dead upstream
2019-05-07 09:18:30 <ncopa> i saw the irc log, im purging it
2019-05-07 09:18:38 <ncopa> re mpt-status url fix
2019-05-07 09:18:58 <ncopa> is there any differenece in the content of the tarballs?
2019-05-07 09:19:08 <ncopa> will the resulting binary be different?
2019-05-07 09:19:22 <ncopa> if so, then we need bump pkgrel
2019-05-07 09:19:47 <ncopa> i wonder if we may want use that -8 number in pkgver somehow
2019-05-07 09:19:52 <ncopa> maybe _p8
2019-05-07 09:20:20 <mps> url have '-8'
2019-05-07 09:21:35 <mps> http://ftp.de.debian.org/debian/pool/main/m/mpt-status/mpt-status_1.2.0-8.debian.tar.gz
2019-05-07 09:22:32 <mps> if you have idea how to rewrite it please do
2019-05-07 09:24:51 <_ikke_> What do we do with s390x/nginx. It still fails
2019-05-07 09:25:18 <_ikke_> Either disable http-lua, or what J0WI suggested, trying to get luajit running for s390x
2019-05-07 09:25:53 <_ikke_> https://github.com/alpinelinux/aports/pull/7223 for reference
2019-05-07 09:27:04 <ncopa> mpt-status is orphaned
2019-05-07 09:27:10 <ncopa> i guess we can move it to unmaintained
2019-05-07 09:27:58 <ncopa> _ikke_: try get luajit running for s390x is non-trivial
2019-05-07 09:28:09 <mps> If it not needed, sure
2019-05-07 09:28:21 <_ikke_> ncopa: J0WI linked to someone who has a fork that says it's runnign
2019-05-07 09:28:31 <_ikke_> https://github.com/LuaJIT/LuaJIT/pull/395
2019-05-07 09:28:55 <_ikke_> but upstream doesn't seem responsive to it
2019-05-07 09:30:27 <ncopa> luajit upstream does not seem to have made any release in 2 years now
2019-05-07 09:30:42 <ncopa> nginx is broken in stable branches too apparently
2019-05-07 09:43:25 <ncopa> that nginx issue is nasty
2019-05-07 09:44:27 <_ikke_> I can imagine
2019-05-07 09:49:23 <fcolista> I've a series of patch re: upgrade from qt5.12.1 to qt5.12.3
2019-05-07 09:49:24 <fcolista> http://tpaste.us/gMzd
2019-05-07 09:49:43 <fcolista> the only pacakges giving me headache is qt5-qtwebengine
2019-05-07 09:51:32 <fcolista> this is the last part of the build log: https://dpaste.de/ZDrQ/raw
2019-05-07 09:51:55 <fcolista> my lxc goes out of mem
2019-05-07 09:52:38 <Cogitri> How much mem do you have?
2019-05-07 09:52:48 <fcolista> 16GB
2019-05-07 09:52:54 <Cogitri> I can build it on my machine, I have 16GB
2019-05-07 09:53:07 <Cogitri> Oh. Well, less link jobs it is then, I guess
2019-05-07 09:53:29 <fcolista> http://tpaste.us/ee4E <- this builds for you?
2019-05-07 09:53:48 <fcolista> It's just an abump
2019-05-07 10:36:00 <tmhoang> _ikke_> What do we do with s390x/nginx. It still fails : I'm working on this
2019-05-07 10:36:30 <tmhoang> getting luajit on s390x is nearly impossible for now. mostly i have to workaround to make lua-nginx-module to support other lua
2019-05-07 10:36:59 <ncopa> upstream does not support that
2019-05-07 10:37:12 <ncopa> i think we can simply remove the lua module for nginx for now
2019-05-07 10:37:54 <ncopa> i think it may be an idea to report to lua-nginx-module that only supporting luajit does not work for s390x
2019-05-07 10:38:10 <tmhoang> ncopa: yes reporting is one
2019-05-07 10:38:19 <_ikke_> tmhoang: thanks
2019-05-07 10:38:28 <ncopa> i have a fix for the package itself
2019-05-07 10:38:53 <ncopa> it was trickier than expected to drop an architecture
2019-05-07 10:39:27 <_ikke_> What was the tricky part?
2019-05-07 10:39:58 <ncopa> the _add_module function
2019-05-07 10:40:38 <_ikke_>  Did you try a declerative approach?
2019-05-07 10:40:39 <ncopa> give you no opportunity to add the source package to $source even if we dont want enable the module
2019-05-07 10:41:08 <ncopa> because we need to add all modules to $source due to the static checksums list
2019-05-07 10:41:15 <_ikke_> ah, ok
2019-05-07 10:41:17 <_ikke_> right
2019-05-07 10:41:21 <tmhoang> ncopa> i think we can simply remove the lua module for nginx for now : remove for s390x is enough I guess. we don't have to remove for everyone
2019-05-07 10:41:39 <_ikke_> yes, that was the idea
2019-05-07 10:42:46 <ncopa> http://tpaste.us/wjke
2019-05-07 10:43:01 <ncopa> bah typo in commit message
2019-05-07 10:44:55 <_ikke_> not pushed yet apparently?
2019-05-07 10:45:52 <tmhoang> hm more complicated than I assumed
2019-05-07 10:46:49 <ncopa> same
2019-05-07 10:47:16 <_ikke_> Welcome to CS101
2019-05-07 10:47:24 <Cogitri> fcolista: Can try in a bit
2019-05-07 10:57:01 <tcely> libzdb can be moved to community, correct?
2019-05-07 10:57:36 <ncopa> as long as it does not depend on anything in testing, and is confirmed to work
2019-05-07 10:57:42 <ncopa> and has a maintainer
2019-05-07 10:57:54 <north1> has no maintainer
2019-05-07 10:58:27 <ncopa> and is packaged good enough (files are installed in proper locations and not in things like /usr/usr/bin and /usr/etc/config)
2019-05-07 11:01:09 <tcely> It is in main now and nothing seems to use it.
2019-05-07 11:02:33 <ncopa> if it has no maintainer, and nothing uses it, then maybe move it to unmaintained?
2019-05-07 11:03:01 <tcely> Maybe
2019-05-07 11:03:40 <tcely> pr7324
2019-05-07 11:05:42 <_ikke_> Ask if north1 wants to maintain it
2019-05-07 11:06:31 <tcely> I saw the ABI change then went looking for packages to bump and found none.
2019-05-07 11:07:26 <tcely> north1: ping
2019-05-07 11:09:24 <tmhoang> it seems builders are now configured to not keep building failed packages.
2019-05-07 11:09:48 <_ikke_> it kept trying to build nginx though?
2019-05-07 11:10:57 <tmhoang> iiuc, the script loops through all packages. if new pr is merged it is triggered to loop through everything. then done. that's why nginx shows up once in a while
2019-05-07 11:11:27 <_ikke_> yes, it won't try to build a package over and over if it fails
2019-05-07 11:11:41 <ncopa> oh well, this nginx lua thing was even more complicated. apparently there are 2 different lua modules
2019-05-07 11:14:19 <tmhoang> github.com is back to society
2019-05-07 11:15:24 <ncopa> this is the benefit of using github vs running our own service
2019-05-07 11:15:59 <ncopa> if service goes down, it will magically be fixed "by itself" rather than us need to investigate what went wrong :)
2019-05-07 11:16:08 <tmhoang> good point
2019-05-07 11:19:42 <danieli> otoh microsoft wouldn't want to buy our gitlab instance lol
2019-05-07 11:27:43 <artok> ncopa: did you see my comment that aports/community/go/APKBUILD needs musl-dev into depends?
2019-05-07 11:27:47 <ncopa> north1: looks like you are right. it does not look like chromium links to libelf
2019-05-07 11:28:06 <artok> otherways running go build will fail linking
2019-05-07 11:28:14 <ncopa> artok: i think i saw something about it
2019-05-07 11:28:35 <artok> so small change that I didn't bother to create PR =)
2019-05-07 11:28:36 <ncopa> i was wondering if gcc need to have musl-dev in its depends
2019-05-07 11:28:43 <artok> oh!
2019-05-07 11:28:56 <ncopa> can go be used without gcc at all?
2019-05-07 11:29:24 <artok> gcc thing depends on target
2019-05-07 11:29:32 <ncopa> artok: can you please file a bug on bugs.a.o with a testcase?
2019-05-07 11:29:39 <ncopa> go has also different targets
2019-05-07 11:31:05 <ncopa> artok: i think its good to have the problem described some place for history, not only push the solution to git
2019-05-07 11:31:19 <artok> just noticed this with simple https://hastebin.com/uxijilicak.sql
2019-05-07 11:32:11 <artok> I'll get some lunch and will be looking more into it
2019-05-07 11:32:59 <tcely> Where is the location to put custom license file?
2019-05-07 11:33:26 <tcely> It seems like there should be a function for this task.
2019-05-07 11:33:38 <_ikke_> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license
2019-05-07 11:34:26 <ncopa> i think we may need to try enforce the /usr/share/licenses for all packages
2019-05-07 11:34:44 <ncopa> but after 3.10 release
2019-05-07 11:36:04 <tcely> More sanity checks :-)
2019-05-07 11:38:19 <_ikke_> Then abuild support for it would certainly be appreciated
2019-05-07 11:41:07 <tmhoang> ncopa: may I trigger a manual `abuild -r` of a package on the builder ?
2019-05-07 11:41:18 <tmhoang> $ cd aports/main/package; abuild -r
2019-05-07 11:41:32 <north1> tcely: answered
2019-05-07 11:42:09 <_ikke_> tmhoang: in #alpine-commits, you can request: algitbot: retry master
2019-05-07 11:42:40 <tmhoang> I guess it is meant for operators ?
2019-05-07 11:43:02 <tmhoang> ah it works
2019-05-07 11:43:13 <tmhoang> feeling like a god
2019-05-07 11:43:49 <_ikke_> :-)
2019-05-07 11:46:47 <_ikke_> You can also specify a branch to do it for that branch
2019-05-07 11:46:49 <tcely> north1: aww. poor orphan aport is moving.
2019-05-07 11:49:02 <tcely> For retry command does it affect all builders?
2019-05-07 11:51:10 <_ikke_> yes
2019-05-07 11:51:45 <_ikke_> But if all packages were built successfully, they won't do anything
2019-05-07 11:53:43 <clandmeter> algitbot: hi
2019-05-07 11:53:54 <clandmeter> algitbot: do you know ca01497574244b8c178d669329eed2b8cb497957
2019-05-07 11:55:14 <tcely> Is that for full hash only?
2019-05-07 11:55:26 <clandmeter> yes
2019-05-07 11:56:26 <clandmeter> or we need to prepend some keyword
2019-05-07 11:56:54 <tcely> pr7324 is ready to move
2019-05-07 11:58:09 <tcely> commit 555f3f3
2019-05-07 11:58:29 <tcely> ^^ for example
2019-05-07 11:58:34 <clandmeter> we could use aports:12345678
2019-05-07 12:00:50 <tcely> Yeah adding the repo is a good idea. alpinelinux/aports:555f3f3636440666f9684b88e8305454756ec97f
2019-05-07 12:02:12 <tcely> That link is wrong, but the message is correct
2019-05-07 12:03:27 <clandmeter> https://git.alpinelinux.org/aports/commit/?id=555f3f3636440666f9684b88e8305454756ec97f
2019-05-07 12:05:32 <clandmeter> thats weird
2019-05-07 12:05:39 <clandmeter> its on github but not git.a.o
2019-05-07 12:06:24 <tcely> It's from a PR so may never reach git.a.o
2019-05-07 12:06:54 <clandmeter> we dont merge from github
2019-05-07 12:07:03 <clandmeter> i mean apply
2019-05-07 12:07:23 <ncopa> i think you mean that we dont push to github?
2019-05-07 12:07:31 <ncopa> i certainly merge PRs from github :)
2019-05-07 12:07:41 <clandmeter> yes sorry
2019-05-07 12:07:56 <clandmeter> any commit on git.a.o should be in github
2019-05-07 12:08:18 <tcely> Yes, but not the other way around
2019-05-07 12:08:45 <clandmeter> ok do explain
2019-05-07 12:08:48 <tcely> I was curious if algitbot would even find it, but it did
2019-05-07 12:09:02 <clandmeter> the bot uses github api
2019-05-07 12:09:31 <tcely> There are commits on GitHub that get changed before being pushed to git.a.o, so the hash changes.
2019-05-07 12:09:42 <clandmeter> i know
2019-05-07 12:09:53 <tcely> Some commits will only exist on GH
2019-05-07 12:10:10 <clandmeter> aports on github is an exact mirror of git.a.o
2019-05-07 12:10:41 <mps> clandmeter: can you teach algitbot to tell us what pkg is uploaded
2019-05-07 12:10:43 <tcely> For some namespace that statement holds
2019-05-07 12:11:32 <clandmeter> ah i see already
2019-05-07 12:11:35 <clandmeter> this is confusing
2019-05-07 12:12:09 <clandmeter> this commit is not in master
2019-05-07 12:12:18 <clandmeter> its in no branch or tag at all
2019-05-07 12:12:34 <tcely> It's in refs/pull/**
2019-05-07 12:13:42 <clandmeter> right
2019-05-07 12:13:48 <clandmeter> anyway, dont cheat :)
2019-05-07 12:14:54 <tcely> Heh. The bot could check the link too.
2019-05-07 12:15:42 <tcely> Most of the GH API results I see have url included
2019-05-07 12:16:58 <clandmeter> i think the usecase is when you are using something like gitlog and point it out here.
2019-05-07 12:19:58 <ncopa> the url here (#7121) points to redmine instead of github https://git.alpinelinux.org/aports/commit/main/nginx?h=3.9-stable&id=4b3d3653aafc7f8b9bff6e4713215d58d9c31cf0
2019-05-07 12:20:53 <ncopa> the fundamental problem is that we have issue IDs from redmine and issue IDs from github
2019-05-07 12:21:47 <ncopa> and now people expect "#<number>"  to be a reference to an issue id on github
2019-05-07 12:22:00 <ncopa> while last 10 years it has been an issue id on our bug tracker
2019-05-07 12:22:27 <clandmeter> thats why i suggest to use GH-xxx instead
2019-05-07 12:22:57 <ncopa> and maybe also add support for RM-xxx and GL-xxx?
2019-05-07 12:23:06 <clandmeter> the problem is that commits doing closes: xxx can also close PRs
2019-05-07 12:23:37 <clandmeter> yes we suggested to use RM-xxx
2019-05-07 12:23:46 <clandmeter> but redmine does not support it
2019-05-07 12:24:11 <clandmeter> you can only change the Closes/resolves prefix
2019-05-07 12:24:51 <tcely> as long as redmine ignores GH-xxx is that a problem?
2019-05-07 12:25:04 <ncopa> so all the references in git history from last 10 years should point to an unrelated github issue?
2019-05-07 12:25:33 <ncopa> can we make github not close issues for us?
2019-05-07 12:25:48 <ncopa> i find this very annoying to be honest
2019-05-07 12:26:48 <clandmeter> that nginx usage ofresolves is incorrect
2019-05-07 12:26:49 <ncopa> it basically means: either we go full github and github only - or we dont use github at all
2019-05-07 12:27:07 <ncopa> brb. lunch
2019-05-07 12:28:58 <clandmeter> even if we disable github issue referencing, we cannot stop developers using it incorrectly.
2019-05-07 12:30:12 <clandmeter> and by the looks of it, you cannot disable that feature.
2019-05-07 12:36:06 <tcely> Please merge pr7129 when you have a chance
2019-05-07 12:55:57 <fcolista> Cogitri, any update?
2019-05-07 13:04:34 <artok> ncopa: yes, gcc is needed for go and musl-dev also
2019-05-07 13:04:42 <artok> go uses gcc for linking
2019-05-07 13:06:41 <Cogitri> fcolista: Building right now, sorry, got stuck with other stuff before :c
2019-05-07 13:07:16 <fcolista> Cogitri, no problem! Thanks for your availability.
2019-05-07 13:12:20 <ncopa> clandmeter: so we need to stop use github or only use github
2019-05-07 13:12:30 <ncopa> i guess gitlab is similar enough
2019-05-07 13:13:16 <clandmeter> gitlab is similar like github
2019-05-07 13:13:21 <clandmeter> but it will also replace redmine
2019-05-07 13:13:26 <clandmeter> this part im not 100% sure
2019-05-07 13:13:50 <ncopa> replacing redmine?
2019-05-07 13:13:57 <telmich> ncopa: 5 cents from our side: we have moved away from github recently, for various reasons. one of them github being ipv4 only
2019-05-07 13:14:04 <clandmeter> you want to run gitlab and redmine together?
2019-05-07 13:14:16 <telmich> and we are actually running redmine + gitlab in our company
2019-05-07 13:14:31 <ncopa> clandmeter: i was hoping to shut down redmine
2019-05-07 13:14:31 <north1> Is there an equivalent of Hub for GitHub ?
2019-05-07 13:14:46 <telmich> north1: what do you mean by that?
2019-05-07 13:14:50 <north1> i use it a lot and makes contributing via GitHub a lot more convenient
2019-05-07 13:14:58 <clandmeter> i think he means gitlab
2019-05-07 13:15:08 <telmich> ahh
2019-05-07 13:15:11 <TBK[m]> clandmeter do you have a test instance running?
2019-05-07 13:15:15 <ncopa> maybe we should move this discussion to #alpine-infra
2019-05-07 13:18:31 <Cogitri> telmich: He means https://github.com/github/hub
2019-05-07 13:18:45 <Cogitri> It's super nice to interact with Github from the CLI with it
2019-05-07 13:20:59 <tcely> Cogitri: I used a fork of that but I can't seem to find it again
2019-05-07 13:22:22 <tcely> git hub pr list -C      <- so much nicer than switching to web browser
2019-05-07 13:22:58 <_ikke_> I mis being able to filter things though
2019-05-07 13:24:50 <north1> Any reason on why armhf is restricted on zstd ?
2019-05-07 13:25:19 <Cogitri> tcely: I guess I only use it for opening PRs via the CLI
2019-05-07 13:28:21 <mps> north1: I see, it's time for me to make armhf lxc and check some issues
2019-05-07 13:51:55 <artok> well there
2019-05-07 14:37:23 <_ikke_> This is a systemd ticket, but talks about RDRAND not returning random data after suspend on some systems: https://github.com/systemd/systemd/issues/11810#issuecomment-490065062
2019-05-07 14:38:20 <ncopa> tmhoang: any idea whats wrong with py-msgpack?  https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/py-msgpack/py-msgpack-0.6.1-r3.log
2019-05-07 14:38:56 <tmhoang> ncopa: no idea yet but looking in. thanks
2019-05-07 14:42:06 <north1> ncopa: It is missing case esac for dealing with builds on s390x
2019-05-07 14:43:13 <north1> adding the missing _pyarch= definition for s390x should fix it
2019-05-07 14:45:43 <tmhoang> ncopa: north1 is right, pyarch is s390x
2019-05-07 14:56:54 <Cogitri> fcolista: Builds fine on x86
2019-05-07 14:56:58 <Cogitri> X86_64*
2019-05-07 15:09:06 <ncopa> north1: thanks!
2019-05-07 15:11:39 <fcolista> Cogitri, thx
2019-05-07 15:32:15 <Cogitri> I think it still crashes tho
2019-05-07 15:38:14 <Cogitri> Testing with http://ix.io/1Ijr right now.
2019-05-07 15:43:23 <ncopa> Cogitri, re 2b17e52599512cd24c7ee55ec5a52c835e057617
2019-05-07 15:44:00 <ncopa> this one specifically:  armhf|armv7) _pyarch=armv8l ;;
2019-05-07 15:44:11 <ncopa> will that not break on rpi1?
2019-05-07 15:46:40 <Cogitri> I think you mean maxice8?
2019-05-07 15:56:35 <ncopa> oh. sorry :)
2019-05-07 15:56:44 <ncopa> i mean maxice8 :)
2019-05-07 15:57:14 <_ikke_> north1 here :-)
2019-05-07 15:58:21 <Cogitri> Hehe ^^
2019-05-07 15:58:53 <Cogitri> ncopa: Mind taking a look at pr7262? All of GNOME kind of stalls on it
2019-05-07 16:01:10 <_ikke_> ncopa: One of the high-prio issues where other PRs wait for ;-)
2019-05-07 16:02:25 <_ikke_> Cogitri: I discussed this with ncopa. The general concensus is that we prefer depending commits to be in a single PR to make it easier to handle. But we also want to prevent PRs becoming too large to make them hard to review.
2019-05-07 16:03:59 <Cogitri> Yes, I did about everything in one PR when I upgraded GNOME to 3.32 for Void which was a pain to review, so I split it up more this time :)
2019-05-07 16:04:14 <Cogitri> Will keep it in mind though. Thank you :)
2019-05-07 16:06:44 <_ikke_> https://bugzilla.kernel.org/show_bug.cgi?id=85911 <- rdrand issue
2019-05-07 16:10:01 <tmhoang> ncopa : you could do this : x86_64|aarch64|ppc64le|s390x) _pyarch="$CARCH" ;;  :p
2019-05-07 16:17:51 <ncopa> north1: i think you have a buch of libx* PRs? see this: https://github.com/alpinelinux/aports/pull/6760
2019-05-07 16:18:56 <north1> Explains why they didn't appear when I searched github PRs for it
2019-05-07 16:20:41 <ncopa> how is LICENSE spelled? LICENSE or LICENCE? when it comes to software licenses
2019-05-07 16:20:55 <_ikke_> license
2019-05-07 16:20:57 <_ikke_> afaik
2019-05-07 16:21:03 <SpaceToast> License
2019-05-07 16:21:32 <ncopa> zsh does not ship a license, it ships a LICENCE
2019-05-07 16:21:36 <ncopa> *shrug*
2019-05-07 16:21:39 <ncopa> thanks
2019-05-07 16:21:51 <_ikke_> "What does licence mean? Licence is not commonly used in American English, but it is the only spelling for the noun in British English."
2019-05-07 16:22:09 <_ikke_> https://writingexplained.org/licence-vs-license-difference
2019-05-07 16:22:12 <north1> For Americans license on both
2019-05-07 16:22:18 <_ikke_> "In American English, however,  license is the spelling of both the noun and the verb."
2019-05-07 16:22:22 <SpaceToast> I referred to spdx and osi, both of which use license
2019-05-07 16:22:24 <north1> For tea drinkers it is licence for the word and license for the verb
2019-05-07 16:22:42 <ncopa> so zsh devs are tea drinkers :)
2019-05-07 16:23:01 <_ikke_> :D
2019-05-07 16:23:14 <ncopa> i learned something new today
2019-05-07 16:23:34 <north1> Just like gray and grey I guess
2019-05-07 16:23:45 <_ikke_> color and colour
2019-05-07 16:23:58 <_ikke_> organization and organisation
2019-05-07 16:25:55 <north1> Making the greatest empire and losing to some farmers as well
2019-05-07 16:28:58 <ncopa> north1: i merged the pr6760 can you please close or rebase your conflicting PRs?
2019-05-07 16:30:41 <tcely> _ikke_: superseded or superceded
2019-05-07 16:30:59 <north1> ncopa: ill close them when I get home
2019-05-07 16:31:02 <north1> I'm at a mechanic currently
2019-05-07 16:32:28 <_ikke_> tcely: heh
2019-05-07 16:32:45 <_ikke_> based on the first one, I would say superseded :D
2019-05-07 16:34:10 <tcely> I was always taught the latter, but was informed it has been a popular misspelling for hundreds of years recently
2019-05-07 16:34:32 <_ikke_> heh
2019-05-07 17:00:15 <north1> ncopa: ok done :D
2019-05-07 17:00:17 <north1> i closed them all
2019-05-07 17:09:36 <Cogitri> fcolista: http://ix.io/1IjX
2019-05-07 17:10:53 <Cogitri> It doesn't throw any errors anymore, but it still goes to a blank window once it has finished loading the webpage :c
2019-05-07 17:11:04 <tcely> ncopa: this is as close to useful issues as I got on GH https://github.com/tcely/aports/projects
2019-05-07 17:33:17 <mps> main/ipfw upstream is inaccessible, there is https://github.com/luigirizzo/dummynet last changed 4 years ago, source from http://distfiles.alpinelinux.org/distfiles//20130607-ipfw3.tgz also disappeared
2019-05-07 17:34:32 <mps> and, is this pkg usable today?
2019-05-07 17:34:56 <jwh> I'd be surprised if that still works - does it still compile?
2019-05-07 17:35:41 <jwh> iirc there were some issues with it anyway where it would upset the kernel
2019-05-07 17:35:49 <north1> It doesn't even fetch
2019-05-07 17:36:03 <jwh> well I mean did it compile when the source was still available
2019-05-07 17:36:13 <north1> https://i.imgur.com/84pFKYx.png
2019-05-07 17:36:40 <jwh> doubt there are any consumers of that package either way
2019-05-07 17:36:44 <jwh> not today
2019-05-07 17:40:03 <mps> well, it could be downloaded from github latest commit, but not sure if it worth efforts, or just move it to unmaintained
2019-05-07 17:55:36 <ncopa> tcely: do you know if gitlab has something similar?
2019-05-07 18:03:19 <tcely> ncopa: I don't know GL well
2019-05-07 18:03:53 <fcolista> Cogitri, umh..that's not comforting.
2019-05-07 18:03:57 <ncopa> north1: thanks!
2019-05-07 18:04:27 <Cogitri> Yes, so it's as broken as 5.12.1 sadly :c
2019-05-07 18:05:05 <tcely> Cogitri: what is it you are discussing?
2019-05-07 18:05:32 <Cogitri> ncopa: See https://about.gitlab.com/product/project-management/ for the project management stuff.
2019-05-07 18:05:40 <Cogitri> tcley: qt5-qtwebengine
2019-05-07 18:06:05 <tcely> thanks
2019-05-07 18:06:18 <fcolista> Ah ok
2019-05-07 18:06:25 <fcolista> so this does not make the things worst
2019-05-07 18:06:39 <Cogitri> <Cogitri "ncopa: See https://about.gitlab."> I can't find a good example project which uses GL's management tools though :c
2019-05-07 18:07:23 <Cogitri> No, it doesn't make things worse, but that's still not exactly good
2019-05-07 18:07:35 <Cogitri> Kind of clueless how to debug it though since I don't know Qt at all
2019-05-07 18:07:47 <Cogitri> Maybe I'll give it a shot at the weekend
2019-05-07 18:09:07 <SpaceToast> ncopa: github projects is more or less the same thing as kanban
2019-05-07 18:09:20 <SpaceToast> so yes, gitlab has those :)
2019-05-07 18:10:16 <ncopa> sox is broken on s390x
2019-05-07 18:10:44 <ncopa> i need get all the builders success before i can tag new edge snapshot
2019-05-07 18:10:57 <_ikke_> It's a test that's failing
2019-05-07 18:11:12 <tcely> ncopa: https://gitlab.labs.nic.cz/knot/knot-dns/boards
2019-05-07 18:12:13 <tcely> So SpaceToast is certainly correct. The kanban board project template in GH is issue boards in GL
2019-05-07 18:12:13 <north1> can they just be disabled ?
2019-05-07 18:15:07 <ncopa> i guess so
2019-05-07 18:15:15 <ncopa> i think i found a patch from fedora
2019-05-07 18:15:23 <mps> Cogitri: have you some time to look at llvm8 patch posted to https://patchwork.alpinelinux.org/patch/4843/
2019-05-07 18:16:09 <mps> is this needed, we have llvm8 but poster mention rust patch
2019-05-07 18:16:43 <ncopa> i wonder if we should update clang at the same time as we add llvm8
2019-05-07 18:16:50 <ncopa> and the other tools as well
2019-05-07 18:18:07 <Cogitri> mps: Ah, no clue, I haven't ever used PW, I've submitted my own PR on GH
2019-05-07 18:18:16 <Cogitri> ncopa: Most likely, yes.
2019-05-07 18:18:49 <Cogitri> How do I see patch 1/2?
2019-05-07 18:18:59 <mps> ncopa: I think Cogitri is right about clang and tools
2019-05-07 18:19:33 <Cogitri> Yup, some stuff that needs both libclang and liblllvm breaks in unnice ways
2019-05-07 18:20:06 <mps> Cogitri: isn't there 'diff' button to download patch
2019-05-07 18:26:08 <tcely> Cogitri: All the patches are in the series. https://patchwork.alpinelinux.org/series/454/mbox/
2019-05-07 18:26:33 <tcely> You could also click the "show" link next to "Related"
2019-05-07 18:41:03 <Cogitri> Ah, thank you
2019-05-07 18:46:37 <_ikke_> So J0WI submitted the s390x patch for luajit
2019-05-07 18:46:43 <_ikke_> Let's see how it goes
2019-05-07 18:51:30 <_ikke_> https://github.com/alpinelinux/aports/pull/7587 this uses a python venv during build, is that a problem/issue?
2019-05-07 18:51:46 <_ikke_> (creating one and building inside the venv)
2019-05-07 18:54:32 <north1> Skimming over it sounds like a workaround of dependencies not being packaged
2019-05-07 18:55:11 <_ikke_> Yes, most likely
2019-05-07 18:55:21 <tcely> yeah, I'm left wondering how well the installed package will work when that venv no longer exists
2019-05-07 18:56:59 <_ikke_> Lots of deps in requirements.txt that are not available
2019-05-07 18:57:08 <_ikke_> http://tpaste.us/9gq7
2019-05-07 19:02:30 <_ikke_> It even hangs during build for me (trying to download python modules via pip)
2019-05-07 20:02:49 <otlabs> hi ppl
2019-05-07 20:03:10 <_ikke_> otlabs: hi
2019-05-07 20:03:16 <ncopa> hi
2019-05-07 20:03:26 <otlabs> _ikke_: yo!
2019-05-07 20:03:31 <otlabs> ncopa: greetings!
2019-05-07 20:03:37 <_ikke_> I'm just checking the spacy PR
2019-05-07 20:03:43 <otlabs> oh
2019-05-07 20:03:50 <otlabs> -me hides in the bushes
2019-05-07 20:03:52 <otlabs> 
ACTION hides in the bushes

2019-05-07 20:04:27 <_ikke_> One issue might be that it uses venvs to build
2019-05-07 20:04:55 <otlabs> i think itis the only way to build it
2019-05-07 20:05:07 <otlabs> installing with pip makes things very nesty
2019-05-07 20:05:16 <_ikke_> But how are those dependencies being installed on the target system?
2019-05-07 20:05:22 <_ikke_> Or do you expect them to do the same?
2019-05-07 20:05:31 <otlabs> e.g. pipi instals out of any abuild recognized directories
2019-05-07 20:05:47 <_ikke_> yes, if you rely on pip
2019-05-07 20:06:26 <_ikke_> For some reason it takes very long to build (quite unexpected for what it does)
2019-05-07 20:06:54 <otlabs> long? maybe due to use of cython?
2019-05-07 20:07:23 <_ikke_> Installing dependencies already takes long for some reason
2019-05-07 20:08:02 <ncopa> looks like i will have to give up edge snapshot today
2019-05-07 20:08:15 <ncopa> the s390x edge builder will not be done anytime soon
2019-05-07 20:08:21 <otlabs> ok, i see, i will try to add packages for those dependencies first
2019-05-07 20:08:25 <_ikke_> due to backlog?
2019-05-07 20:08:48 <_ikke_> 32%, quite some work to do still
2019-05-07 20:16:33 <_ikke_> otlabs: It looks like it's building the extension twice
2019-05-07 20:16:42 <_ikke_> once in the build phase and once in the package phase
2019-05-07 20:43:14 <otlabs> auch
2019-05-07 20:43:21 <otlabs> i wil check that
2019-05-07 20:47:19 <otlabs> _ikke_: got your comment, thanks, will attend it in next days
2019-05-07 20:47:51 <otlabs> i would like to build a package for "Cross-platform library for building Telegram clients", https://core.telegram.org/tdlib
2019-05-07 20:48:08 <otlabs> they have repository at https://github.com/tdlib/td
2019-05-07 20:48:40 <otlabs> which package name should i use - "td", "tdlib", or "libtd"?
2019-05-07 20:49:15 <danieli> i'd call it tdlib since that's what telegram calls it, but the actual repo is named 'td' so i'm not 100% sure
2019-05-07 20:50:35 <otlabs> that's the problem i have
2019-05-07 20:51:07 <otlabs> i see no that package neither in ununtu no in arch
2019-05-07 20:51:44 <_ikke_> https://aur.archlinux.org/packages/telegram-tdlib/
2019-05-07 20:52:07 <otlabs> i also get a warning from abuild that several static libraries are build, but they do not end in -static. how important is that?
2019-05-07 20:52:27 <_ikke_> otlabs: just add a $pkgname-static before $pkgname-dev in subpackages
2019-05-07 20:53:00 <otlabs> _ikke_: thanks, for some reason i have not found it
2019-05-07 20:53:27 <_ikke_> That's the AUR, not sure if you looked there
2019-05-07 20:53:31 <otlabs> _ikke_: ok, i will add a static package!
2019-05-07 20:53:35 <danieli> yeah, that's aur, not the regular arch package index
2019-05-07 20:54:02 <_ikke_> (AUR are community maintained packages, not built / distributed by arch)
2019-05-07 20:54:06 <otlabs> so i assume i can name the package the same way - telegram-tdlib
2019-05-07 20:56:32 <otlabs> _ikke_: wow! thanks again for reviewing my PR!
2019-05-07 20:57:30 <_ikke_> It was an easy one :-)
2019-05-07 20:58:12 <otlabs> :-)
2019-05-07 21:41:06 <otlabs> time to go, see you later!
2019-05-07 23:37:51 <tcely> It looks like all the 3.10 builders are blocked
2019-05-07 23:38:40 <danieli> would you look at that
2019-05-07 23:38:52 <danieli> 3x stuck on main/ipfw, 2x stuck on main/qt
2019-05-07 23:39:21 <danieli> s/2x/3x/
2019-05-07 23:39:21 <alpine-meetbot> danieli meant to say: 3x stuck on main/ipfw, 3x stuck on main/qt
2019-05-07 23:39:39 <danieli> curl: (7) Failed to connect to info.iet.unipi.it port 80: Operation timed out
2019-05-07 23:41:50 <mps> I wrote today that the ipfw inaccessible and moved to github
2019-05-07 23:42:25 <danieli> looks like builders missed that
2019-05-07 23:42:50 <mps> and it's usage is questionable, last update was 4 years ago
2019-05-07 23:43:12 <mps> I think it should be removed or moved to unmaintained
2019-05-07 23:43:41 <mps> danieli: heh, good catch :)
2019-05-07 23:43:58 <danieli> the power of observation :')
2019-05-08 06:11:06 <fabled> morning. ncopa do you know if anyone is working on the firefox tab crash issue?
2019-05-08 06:26:10 <ncopa> morning
2019-05-08 06:26:25 <ncopa> i think I saw a PR
2019-05-08 06:28:10 <ncopa> this is for firefox-esr: https://github.com/alpinelinux/aports/pull/7348
2019-05-08 06:29:02 <north1> ncopa: morning
2019-05-08 06:30:51 <ncopa> this is testing/firefox https://github.com/alpinelinux/aports/pull/5577
2019-05-08 06:31:00 <ncopa> didnt check if the sandbox patch was included
2019-05-08 06:34:08 <ncopa> it isnt included
2019-05-08 06:38:57 <ncopa> fabled: running a build now
2019-05-08 06:39:01 <ddevault> bump https://patchwork.alpinelinux.org/patch/4542/ (cc clandmeter)
2019-05-08 06:40:03 <fabled> ncopa, may or may not be related. for me it crashes in shm_open in open() syscall
2019-05-08 06:40:08 <north1> ddevault: that tabbing on build()                                                 {
2019-05-08 06:41:19 <ddevault> eek
2019-05-08 06:42:27 <mps> ddevault: is this new aport? shouldn't it go to testing first.
2019-05-08 06:42:48 <ddevault> does it have to? there's nothing particularly risky about it
2019-05-08 06:42:53 <ddevault> we already have the other noto fonts in community
2019-05-08 06:43:12 <north1> ddevault: also i don't think you need build to return 0, ignoring it should be good enough
2019-05-08 06:43:14 <mps> yes, I wanted to ask you by mail yesterday
2019-05-08 06:43:29 <ddevault> ask me what by mail?
2019-05-08 06:43:49 <mps> about this post
2019-05-08 06:44:03 <mps> patch*
2019-05-08 06:44:11 <ddevault> ah
2019-05-08 06:45:44 <mps> there are such fonts in community, you are right, and wanted to ask for 'strong' reason to put them right to community instead of testing
2019-05-08 06:46:32 <mps> but had a 'incident' on customer system and didn't found time to post mail to yoy
2019-05-08 06:46:41 <mps> s/yoy/you/
2019-05-08 06:46:41 <alpine-meetbot> mps meant to say: but had a 'incident' on customer system and didn't found time to post mail to you
2019-05-08 06:49:29 <ddevault> I mean
2019-05-08 06:49:33 <ddevault> there are no CJK fonts for alpine linux
2019-05-08 06:49:37 <ddevault> that's a pretty big omission imo
2019-05-08 06:50:23 <ddevault> noto fonts are stable and the package is as simple as they come, and based on work already in community
2019-05-08 06:50:32 <ddevault> I don't think moving things through testing first just for the sake of it is helpful
2019-05-08 06:50:59 <tmhoang> _ikke_ : Morning! Thanks for comments on pr7623.
2019-05-08 06:51:45 <mps> ddevault: this is policy, first to testing
2019-05-08 06:52:04 <ddevault> policies ought to be justified, and common sense ought to prevail
2019-05-08 06:52:33 <mps> although I agree with you that some things can skip this step
2019-05-08 06:53:38 <ddevault> it's no skin off my back if this goes through testing first
2019-05-08 06:53:51 <ddevault> it just feels pretty unnecessary here, and I dislike rules worship
2019-05-08 06:54:01 <mps> and some pkg's actually skip testing, but this is usually discussed first
2019-05-08 06:55:00 <ddevault> well, if you feel strongly about it, v2 will fix the APKBUILD issues and move it to testing
2019-05-08 06:55:10 <_ikke_> Having a package in testing first gives us a little more leaway in accepting aports and making sure they're working before they get added into a release
2019-05-08 06:56:27 <mps> don't take my words to personally, I'm on your side about these things, but if we have to 'break' policy (rules) we have to ask for the reasons to do that
2019-05-08 06:57:04 <mps> (personally, I also don't give much to rules and prefer common sense, like you)
2019-05-08 06:57:11 <_ikke_> ncopa gave one reason to skip testing is when you need a new dependency for a package already in main/community
2019-05-08 06:58:07 <ddevault> usually I'd be on board with starting in testing, and most of my new APKBUILDs end up there
2019-05-08 06:58:25 <_ikke_> (I didn't look into this PR)
2019-05-08 06:58:42 <ddevault> but if we justify the policy as a form of risk mitigation
2019-05-08 06:58:53 <ddevault> we should be able to dismiss policy when the underlying risk is low
2019-05-08 06:59:10 <ddevault> is that a reasonable inference?
2019-05-08 06:59:43 <mps> huh, not so easy to answer :)
2019-05-08 07:01:33 <mps> inference is reasonable, ofc, but what to do in every particular case needs to be discussed
2019-05-08 07:02:04 <ddevault> sure, fair enough
2019-05-08 07:02:24 <mps> if we start to breaking policy arbitrarily we will end in chaos, sooner or later
2019-05-08 07:03:42 <ddevault> sorry, that makes sense, I was just taken aback by the question because this package is so simple
2019-05-08 07:03:59 <ddevault> of course, having the discussion is important for the less clear-cut cases
2019-05-08 07:04:13 <ddevault> and those can't be identified without the discussion :)
2019-05-08 07:05:10 <mps> for example, two days I'm repeating that the ipfw pkg is outdated, not updated 4 years, blocks builder, upstream inaccesible, but still didn't tried to remove although I'm sure it can be safely removed
2019-05-08 07:07:28 <mps> (btw, I like your comment in post about 1.7 extra GB, :) )
2019-05-08 07:08:02 <ddevault> aye, thanks to the C and J
2019-05-08 07:08:04 <ddevault> K is nice and small
2019-05-08 08:43:30 <tmhoang> ncopa forgot to bump pkgver : https://git.alpinelinux.org/aports/commit/testing/firefox?id=14dcd0ce84ba2fcd11d271f35ae1be03ef21a04f
2019-05-08 08:44:11 <ncopa> tmhoang: because i pushed it together with the previous pkgver bump
2019-05-08 08:44:41 <tmhoang> ah to fix other's fault
2019-05-08 08:48:24 <ncopa> fabled: can you test if firefox is ok now? firefox 66
2019-05-08 09:00:13 <fabled> ncopa, tested. and nope. crashes still.
2019-05-08 09:01:51 <fabled> (gdb) where
2019-05-08 09:01:51 <fabled> #0  0x00007f31cde9b972 in __syscall3 (a3=438, a2=0, a1=139851882837376, n=2) at ./arch/x86_64/syscall_arch.h:29
2019-05-08 09:01:51 <fabled> #1  fopen (filename=0x7f31cdcc3580 "/sys/devices/system/cpu/present", mode=0x7f31cdcc422d "r") at src/stdio/fopen.c:21
2019-05-08 09:01:51 <fabled> #2  0x00007f31cdcb061f in PR_GetNumberOfProcessors () from /usr/lib/libnspr4.so
2019-05-08 09:02:01 <fabled> Thread 1 "Web Content" received signal SIGSYS, Bad system call.
2019-05-08 09:02:27 <fabled> i wonder if musl's syscall thingy changed somehow and broke sandboxing
2019-05-08 09:05:55 <fabled> there's tons of SIGSYS from open sys calls
2019-05-08 09:22:50 <kr0k0> Hi guys
2019-05-08 09:25:25 <kr0k0> I'm working on testing/vdr and I have a segfault in a plugin. I can't find the root cause. I don't know if it really belongs to glibc vs musl differences.
2019-05-08 09:26:18 <kr0k0> If sombody has time. gdb output: http://tpaste.us/dkN8
2019-05-08 09:26:28 <kr0k0> APKBUILD: http://tpaste.us/4ymj
2019-05-08 09:27:38 <kr0k0> This happens when I try to open the recordings on streamdev-server webinterface (http://<vdr-ip>:3000/TS/recordings.html)
2019-05-08 09:32:56 <ncopa> fabled: what version of firefox is it?
2019-05-08 09:34:57 <ncopa> $ firefox --version
2019-05-08 09:34:57 <ncopa> Mozilla Firefox 66.0.4
2019-05-08 09:39:20 <ncopa> i cannot reproduce
2019-05-08 09:55:56 <Cogitri> kr0k0: Might be best to ask upstream about it
2019-05-08 09:58:58 <mps> Cogitri: hi, iirc you intended to add some security patches to main/mupdf 1.14.0
2019-05-08 10:00:23 <mps> few days age 1.15.0 is released. not sure should we keep 1.14.0 for 3.10 or upgrade
2019-05-08 10:06:08 <fabled> ncopa, $ firefox --version --> Mozilla Firefox 66.0.4
2019-05-08 10:10:59 <kr0k0> Cogitri: I doubt that it's an upstream problem. But I want  build it first on a other distri, to be sure.
2019-05-08 10:16:54 <ncopa> fabled: weird. i cannot reproduce it
2019-05-08 10:17:26 <ncopa> mps: i think we should try upgrade mupdf
2019-05-08 10:18:41 <mps> I did some preliminary work but not finished yet
2019-05-08 10:18:54 <ncopa> fcolista: i think i will move qjson to community, and build it with qt5
2019-05-08 10:19:38 <fcolista> ok
2019-05-08 10:19:50 <fcolista> I'm goint to push the upgrade ot qt5 5.12.3
2019-05-08 10:19:56 <fcolista> *to
2019-05-08 10:20:12 <mps> have to fix BE patch
2019-05-08 10:20:16 <ncopa> is it ready to push?
2019-05-08 10:20:48 <fcolista> it's just an abump, the only issue is with qt5-qtwebengine, that is not working also now
2019-05-08 10:20:52 <fcolista> with 5.12.1
2019-05-08 10:21:03 <fcolista> Cogitri was looking at that
2019-05-08 10:22:14 <fabled> ncopa, strange. i'm on x86_64. wonder if it's then some library or firefox plugin or similar
2019-05-08 10:22:22 <ncopa> im moving a couple of packages to unmaintained: main/libechonest and main/liblastfm
2019-05-08 10:22:35 <ncopa> fabled: try runwithout plugins or with clean config/env
2019-05-08 10:23:01 <ncopa> fabled: mv .mozilla .mozilla.backup
2019-05-08 10:23:56 <fabled> does not work in --safe-mode
2019-05-08 10:24:32 <fabled> without existing .mozilla did not help
2019-05-08 10:25:16 <ncopa> maybe some of the libs are not updated?
2019-05-08 10:26:06 <ncopa> im trying to get rid of qt4
2019-05-08 10:26:15 <ncopa> i have cleaned main
2019-05-08 10:26:21 <ncopa> those are left: https://tpaste.us/M5x9
2019-05-08 10:33:16 <ncopa> hydrogen updated
2019-05-08 10:35:37 <ncopa> would be great if we could get rid of qt
2019-05-08 10:35:42 <ncopa> qt 4 that is
2019-05-08 10:53:59 <north1> uhhh wtf
2019-05-08 10:54:14 <north1> why is quazip being switched to qt5 when there is quazip-qt5 ?
2019-05-08 11:03:43 <tmhoang> rnalrd: seems like main/poppler-qt5 depends on community/qt5-qtbase
2019-05-08 11:05:07 <Cogitri> mps: Ah right, sorry, forgot about that over GNOME :c
2019-05-08 11:06:16 <north1> ncopa: Please take a look at pr7680
2019-05-08 11:07:37 <mps> Cogitri: np, ncopa told that we should upgrade to 1.15.0 and I'm now testing it to see does it work
2019-05-08 11:07:56 <Cogitri> Alright πŸ‘
2019-05-08 11:09:03 <mps> will see if your security patches are needed, didn't yet looked carefully at their git repo
2019-05-08 11:11:21 <Cogitri> I doubt that they haven't included thrm
2019-05-08 11:11:54 <mps> probably will ask them on #mupdf
2019-05-08 11:16:39 <north1> Some packages will become unmaintained with pr7675
2019-05-08 11:40:31 <tcely> tcely commented 7 hours from now < poor github time is hard
2019-05-08 11:41:50 <Cogitri> Yeah, it likes to do that sometimes
2019-05-08 11:43:36 <north1> tcely: how is it living in the future ?
2019-05-08 11:44:00 <tcely> north1: I believe the server that handled that request is misconfigured
2019-05-08 11:45:34 <north1> one possible explanation
2019-05-08 11:46:07 <north1> i am amused that i my reply is above yours so there is the possiblity of someone thinking you just asked a question to something i just explained
2019-05-08 11:50:18 <north1> What is the way to get the current site-packages version for python ?
2019-05-08 11:50:25 <north1> i mean the path to /usr/lib/python3.X/site-packages
2019-05-08 11:52:53 <ncopa> north1: oh, i missed pr7680 sorry
2019-05-08 11:54:29 <ncopa> oh, you have rebased it. good. i will merge. thanks!
2019-05-08 12:02:13 <north1> ncopa: it was originally meant to move quazip to unmaintained due to quazip-qt5's existance but since you made quazip use qt5 i made it replace quazip-qt5 and changed references to use quazip-dev instead
2019-05-08 12:10:51 <north1> ncopa: qjson is in main/ but depends on qt5-qtbase-dev please see pr7695
2019-05-08 12:16:46 <_ikke_> north1: https://stackoverflow.com/a/46071447/20261 ?
2019-05-08 12:17:55 <north1> _ikke_: thank you
2019-05-08 12:18:10 <north1> i decided to just create /usr/lib and mv /usr/lib/python3* to it
2019-05-08 12:38:39 <north1> zbar's APKBUILD package() function has a stray ls
2019-05-08 13:07:06 <ncopa> north1: fixed
2019-05-08 13:09:34 <north1> ncopa: https://github.com/alpinelinux/aports/pull/7697
2019-05-08 13:10:59 <north1> ^ Merge that to fix it further
2019-05-08 13:12:18 <mksully22> fyi ppc64le 3.10  main/llvm5 bld break fix is in https://github.com/alpinelinux/aports/pull/7615
2019-05-08 13:13:26 <ncopa> mksully22: thanks!
2019-05-08 13:17:11 <ncopa> looks like 3.10 builders are done with main :)
2019-05-08 13:18:19 <_ikke_> \o/
2019-05-08 13:18:41 <_ikke_> edge/s39x is still chugging along
2019-05-08 13:18:59 <Cogitri> Nice
2019-05-08 13:19:40 <north1> zbar is merged which rid my system of Qt4
2019-05-08 13:19:41 <north1> \o/
2019-05-08 13:20:50 <ncopa> any suggestion how to detect what packages needs rebuild after perl upgrade?
2019-05-08 13:21:24 <north1> ncopa: all perl packages with arch=all since they link to libperl ?
2019-05-08 13:23:37 <danieli> I'll upgrade erlang to 21.3.x
2019-05-08 13:23:49 <north1> have fun
2019-05-08 13:23:58 <danieli> _ikke_: that's nice, hopefully it stays that way
2019-05-08 13:24:05 <ncopa> $ apk list --depends so:libperl.so | tpaste
2019-05-08 13:24:05 <ncopa> http://tpaste.us/aRwN
2019-05-08 13:24:21 <ncopa> that is what is linked directly to libperl
2019-05-08 13:24:35 <north1> https://build.alpinelinux.org keeps crashing on firefox-66.0.4
2019-05-08 13:24:58 <danieli> wait, the page?
2019-05-08 13:25:01 <danieli> or a builder?
2019-05-08 13:25:03 <ncopa> hum, fabled had same issue i think
2019-05-08 13:25:13 <ncopa> indeed
2019-05-08 13:25:27 <danieli> build.a.o is dependent on JS anyway, so i might as well finish off what I was working on for that
2019-05-08 13:26:08 <ncopa> there are some packages that builds perl modules
2019-05-08 13:26:19 <ncopa> packages that does not begin with perl-*
2019-05-08 13:26:43 <danieli> do they split out from those as perl-* subpackages?
2019-05-08 13:27:35 <north1> ncopa: zbar also didn't split out py2-zbar for it's python-bindings
2019-05-08 13:28:40 <ncopa> danieli: normally yes
2019-05-08 13:29:03 <ncopa> north1: do we need py2-zbar? or is py3 enough
2019-05-08 13:30:27 <artok> isn't that friends don't let friends to use python2 ? =)
2019-05-08 13:32:01 <tmhoang> a friend of a friend is fine :D
2019-05-08 13:32:09 <danieli> ha :P
2019-05-08 13:32:35 <danieli> _ikke_: while I'm at it, do you have a list of stuff that breaks with py3.7, or was that sorted?
2019-05-08 13:33:27 <_ikke_> I think it's sorted, ncopa managed the py3.7 upgrade
2019-05-08 13:34:01 <danieli> ha, well damn, looks like you're right :)
2019-05-08 13:35:55 <north1> ncopa: zbar only supports py2, if you want i can remove support for it
2019-05-08 13:36:11 <SpaceToast> hey danieli, hope you're feeling better :)
2019-05-08 13:36:15 <SpaceToast> morning \o
2019-05-08 13:36:27 <danieli> SpaceToast: good morning :)"
2019-05-08 13:50:58 <mps> would it ok to move package from testing to community, after it is three months in testing
2019-05-08 13:51:55 <SpaceToast> my understanding is that it's usually less about time, and more about the commitment of the maintainer and positive affirmation that it works as expected
2019-05-08 13:52:03 <_ikke_> nod
2019-05-08 13:52:18 <mps> I'm talking about testing/perl-curses and testing/perl-curses-ui
2019-05-08 13:52:52 <SpaceToast> well, have you made sure they work, and have the intention to fix them if they break for at least the next 6 months?
2019-05-08 13:53:09 <mps> well, we don't have any metric of usage by end users so not sure if it is ok
2019-05-08 13:53:25 <_ikke_> did you test it yourself?
2019-05-08 13:53:48 <mps> SpaceToast: of course, I intend to maintain it
2019-05-08 13:54:07 <mps> _ikke_: yes, ofc, else I wouldn't ask
2019-05-08 13:54:19 <SpaceToast> so you, as an end user, have made sure it works :)
2019-05-08 13:54:21 <_ikke_> Then I'd say move it to community
2019-05-08 13:54:53 <mps> SpaceToast: well, I never 100% sure if anything works
2019-05-08 13:55:24 <mps> I can only say that I didn't noticed any issue
2019-05-08 13:55:33 <SpaceToast> well, none of us are 100% sure the sun is there either, but if you look out and it seems to be there it's probably reasonable to say that it likely is :)
2019-05-08 13:55:59 <mps> 'likely' is good term
2019-05-08 13:57:29 <_ikke_> It should at least not be obviously broken
2019-05-08 13:58:08 <mps> _ikke_: sure
2019-05-08 14:54:30 <ncopa> https://www.defora.org has invalid cert. how to deal with that?
2019-05-08 14:55:09 <danieli> ncopa: I'm assuming you're using it as the source for a package?
2019-05-08 14:55:43 <ncopa> yes community/makepasswd
2019-05-08 14:55:47 <danieli> aaand it redirects to broken https, darn it
2019-05-08 14:56:59 <danieli> I see two options: 1 (bad)) make abuild support broken HTTPS, or 2) store it at dev.a.o until it's un-broken
2019-05-08 14:57:57 <SpaceToast> looks like it's badly configured letsencrypt
2019-05-08 14:58:27 <danieli> yeah, I saw, but knowing that doesn't really help us :(
2019-05-08 14:58:29 <SpaceToast> so they just need to fix their cron or whatever
2019-05-08 14:58:35 <SpaceToast> the whois doesn't return contact info though :(
2019-05-08 14:58:42 <danieli> suppose we could poke them if we figure out where
2019-05-08 14:58:46 <SpaceToast> yeah
2019-05-08 14:58:55 <danieli> [2] #DeforaOS on irc.freenode.net
2019-05-08 14:58:56 <danieli> ha
2019-05-08 14:58:57 <SpaceToast> could try mailing postmaster@defora.org but there's no guarantee that routes somewhere
2019-05-08 14:58:59 <SpaceToast> aha!
2019-05-08 14:59:08 <tcely> I'd create a repo to mirror sources for cases like that.
2019-05-08 14:59:08 <danieli> aaand it's dead
2019-05-08 14:59:09 <SpaceToast> "hi pls fix cert ta"
2019-05-08 14:59:18 <danieli> pass them an email, yeah
2019-05-08 14:59:21 <SpaceToast> perhaps it's abandoned?
2019-05-08 14:59:26 <danieli> tcely: we have that, dev.alpinelinux.org
2019-05-08 14:59:58 <danieli> no 'news' updates since 2016
2019-05-08 15:00:01 <tcely> Can I add things there?
2019-05-08 15:00:16 <danieli> as far as I know, only natanael, clandmeter, and a few more(?) can
2019-05-08 15:00:35 <tcely> That's not so useful then
2019-05-08 15:00:54 <clandmeter> ppl with commit access usually get an account if requested.
2019-05-08 15:01:13 <danieli> aha, i had a feeling there was some catch i couldn't remember :)
2019-05-08 15:02:10 <mps> clandmeter: will remember for next crystal tarball to not annoy you
2019-05-08 15:02:56 <danieli> ouch, erlang 21.3.8 will have to wait, looks like they broke ssl in .8 and that ericsson are working on a patch (.9)
2019-05-08 15:20:53 <ncopa> re https
2019-05-08 15:21:20 <ncopa> i think it only makes sense to verify certs and use https when we run `abuild checksum`
2019-05-08 15:21:51 <ncopa> it does not really matter if cert is valid or if its unenctypted http when builder fetches it
2019-05-08 15:22:02 <SpaceToast> as long as the file's intact, makes sense
2019-05-08 15:22:03 <ncopa> because we will verify against the stored checksum
2019-05-08 15:23:02 <ncopa> same with gpg signatures once we integrate that
2019-05-08 15:23:21 <ncopa> only makes sense to verify that when we download a file that we dont have checksum for
2019-05-08 15:36:01 <tcely> The gpg signature check is hooked up for checksum and verify. I'd rather see abuild-fetch use insecure https only when the scheme in source was http
2019-05-08 15:38:35 <tcely> If we get redirection from http to (broken) https then we can ignore the error. If we specify https and it is invalid, I want to know about that.
2019-05-08 15:40:20 <ncopa> tcely: https://www.defora.org/ has invalid cert
2019-05-08 15:40:40 <ncopa> and it blocks our builders and delays the 3.10 release
2019-05-08 15:41:19 <ncopa> i dont understand why we need to verify gpg signature in addition to the checksum
2019-05-08 15:41:30 <mps> ncopa: I posted mupdf 1.15.0 patch to aports ML
2019-05-08 15:41:57 <ncopa> we used to have 3 different checksum algos, but we removed those too
2019-05-08 15:42:23 <tcely> http://ftp.defora.org/pub/projects/makepasswd/
2019-05-08 15:42:48 <ncopa> it redirects to broken https
2019-05-08 15:43:00 <tcely> We specified http for that so I am fine with having the fetch ignore that error
2019-05-08 15:43:11 <ncopa> lets change it to https
2019-05-08 15:43:48 <ncopa> http://tpaste.us/qK7z
2019-05-08 15:44:18 <tcely> The reason to verify the gpg sig too is because we can't trust where the hash came from.
2019-05-08 15:45:36 <ncopa> aha
2019-05-08 15:46:31 <ncopa> but we can trust where the gpg key came from?
2019-05-08 15:47:01 <tcely> Nope. That is why we record the fingerprint for the key.
2019-05-08 15:47:32 <ncopa> i suppose that makes sense
2019-05-08 15:48:04 <tcely> That fingerprint is the trust anchor and should be widely known and nit subject to change.
2019-05-08 15:48:14 <tcely> not
2019-05-08 15:48:21 <ncopa> *nod*
2019-05-08 15:49:22 <ncopa> in theory it should be enough to verify the gpg signature only when we store the checksum
2019-05-08 15:49:38 <tcely> Sure, but we can't guarantee that happened.
2019-05-08 15:49:54 <tcely> If we have the correct checksum the sig should pass too.
2019-05-08 15:51:07 <ncopa> lets do the gpg after 3.10 release
2019-05-08 15:51:13 <ncopa> now getting 3.10 out is prio
2019-05-08 15:51:43 <tcely> I'd rather have it in now, but that's fine. Give me a bit to work on insecure for http scheme only changes for abuild-fetch
2019-05-08 15:51:55 <tcely> Otherwise, we should mirror broken https sources.
2019-05-08 15:52:26 <ncopa> btw
2019-05-08 15:52:51 <ncopa> i will be afk 12-23 May
2019-05-08 15:53:37 <ncopa> tcely: they way i think would make sense to deal with the cert thingy
2019-05-08 15:53:58 <ncopa> check if we have the checksumfor the file we are fetching
2019-05-08 15:54:07 <ncopa> if we do, append --insecure
2019-05-08 15:54:47 <ncopa> because we can still verify if it is has been modified
2019-05-08 15:55:10 <ncopa> but we should enforce cert verification when checksum is generated
2019-05-08 15:55:19 <tcely> We don't currently pass that detail far enough for the fetch program to know about the checksum
2019-05-08 15:55:30 <tcely> It's a good idea though
2019-05-08 15:55:51 <ncopa> i was thining of adding an --insecure option to abuild-fetch
2019-05-08 15:56:10 <ncopa> and from abuild append that when needed
2019-05-08 15:56:46 <ncopa> but by default abuild-fetch should verify certs
2019-05-08 15:56:52 <tcely> agreed
2019-05-08 16:05:54 <ncopa> gcc: internal compiler error: Segmentation fault signal terminated program cc1
2019-05-08 16:05:56 <ncopa> not good
2019-05-08 16:17:43 <_ikke_> 2nd time, right?
2019-05-08 16:37:30 <tcely> ncopa: https://github.com/alpinelinux/abuild/pull/82
2019-05-08 16:39:06 <_ikke_> s/was/is in 2f6ce22
2019-05-08 17:30:46 <north1> hmmm
2019-05-08 17:31:08 <north1> can someone confirm i am not looking at things wrong, there is a py-sip and a py3-sip packages but py-sip also has a py3-sip subpackage ?
2019-05-08 17:31:56 <ncopa> north1: wouldnt surprise me
2019-05-08 17:32:53 <ncopa> and its fcolista that maintains both :-D
2019-05-08 17:32:54 <north1> ncopa: shouldn't one of them be removed ? preferably py-sip ?
2019-05-08 17:33:03 <ncopa> totally agree
2019-05-08 17:33:29 <ncopa> i would probalby perfer keep py3-sip
2019-05-08 17:33:39 <ncopa> and get rid of the python2 stuff
2019-05-08 17:33:42 <ncopa> if that is possible
2019-05-08 17:34:39 <north1> if py-sip is going to be removed then it needs to be updated
2019-05-08 17:34:51 <Xe> what
2019-05-08 17:34:56 <north1> py-sip is at 4.19.16 and py3-sip at 4.19.15
2019-05-08 17:36:14 <fcolista> tumh, probably at that time py-sip was py2 only
2019-05-08 17:36:24 <fcolista> py3-sip is a dependency of gns3
2019-05-08 17:37:51 <north1> 1cdc776ec163b71f82467299b07341d1fdf02319 made py-sip py3-sip and py2-sip on January 22 of 2018, py3-sip was added on 16 august of 2016 with ada24377d213cae87beec16eaa76fb51f5d1c62c
2019-05-08 17:38:43 <fcolista> py-sip is a dependency of py-qt in testing
2019-05-08 17:38:49 <north1> ah no actually 3a99cf1e7285b5350c74e3ed2dda38b9c6976f92
2019-05-08 17:39:04 <north1> fcolista: i have pr7698
2019-05-08 17:40:06 <fcolista> k
2019-05-08 17:59:37 <ncopa> mksully22: please go ahead and push pr770
2019-05-08 17:59:52 <ncopa> s/770/7700/
2019-05-08 17:59:52 <alpine-meetbot> ncopa meant to say: mksully22: please go ahead and push pr7700
2019-05-08 18:09:33 <ncopa> a CVE specific for Alpine https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782
2019-05-08 18:09:54 <ncopa> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5021
2019-05-08 18:13:29 <ncopa> how can we update the CVE info, and say what versions are fixed?
2019-05-08 18:13:34 <ncopa> https://github.com/docker-library/official-images/pull/5516
2019-05-08 18:13:44 <danieli> cool, a cve from cisco talos
2019-05-08 18:14:51 <ncopa> I just send an email to cve@mitre.org and request to update the CVE with info what version has it fixed?
2019-05-08 18:20:02 <mps> is this issue for Alpine or docker builders
2019-05-08 18:21:12 <mps> ah, official Alpine docker images, I see now
2019-05-08 18:23:16 <ncopa> i wonder if we should write a news article on alpinelinux.org for that
2019-05-08 18:34:44 <ncopa> edge builders are all done!
2019-05-08 18:34:53 <ncopa> i can tag an edge release
2019-05-08 18:34:53 <_ikke_> YAAY
2019-05-08 18:35:13 <_ikke_> I'll hold of submitting more then :P
2019-05-08 18:35:34 <ncopa> since 3.10 builders are up
2019-05-08 18:35:47 <ncopa> i call this 3.10_beta20190508?
2019-05-08 18:36:44 <_ikke_> Yes, makes sense
2019-05-08 18:37:05 <TBK[m]> what about rc instead of beta?
2019-05-08 18:37:10 <_ikke_> It's not an RC
2019-05-08 18:37:19 <_ikke_> It's just a regular edge snapshot
2019-05-08 18:38:20 <TBK[m]> why not then call it snap[date]?
2019-05-08 18:38:27 <ncopa> 3.10 builders will generate the rc
2019-05-08 18:38:35 <ncopa> thats what we will do
2019-05-08 18:38:54 <ncopa> but in /etc/alpine-release it will say 3.10_beta20190508
2019-05-08 18:39:23 <_ikke_> We need something that apk understands, correct?
2019-05-08 18:39:41 <ncopa> correct
2019-05-08 18:39:52 <SpaceToast> I'm guessing apk won't understand 3.10+patch?
2019-05-08 18:40:02 <ncopa> the version of alpine-base
2019-05-08 18:40:08 <ncopa> SpaceToast: correct
2019-05-08 18:40:21 <ncopa> apk version strins are very similar to gentoo version strings
2019-05-08 18:40:33 <ncopa> as they were in 2006 :)
2019-05-08 18:41:04 <SpaceToast> ah :)
2019-05-08 18:41:36 <SpaceToast> I think $version+patch would be the most technically correct - any complaints if I take a look into trying to add that sometime later? (might entail asking you and others for pointers as to where to look)
2019-05-08 18:41:48 <mps> hm, what aobut 5997 J0WI https://github.com/alpinelinux/aports/pull/5997 main/sudo: upgrade to 1.8.27
2019-05-08 18:42:10 <mps> for 3.10, I mean
2019-05-08 18:42:12 <SpaceToast> it's failing a test
2019-05-08 18:42:43 <ncopa> why does test fail?
2019-05-08 18:42:48 <ncopa> it needs to be investigated
2019-05-08 18:43:08 <ncopa> i just pushed v20190508 tag
2019-05-08 18:43:31 <TBK[m]> is that a philosophical question about coding? :P
2019-05-08 18:43:42 <mps> yes, #alpine-commits show
2019-05-08 18:44:27 <mps> SpaceToast: you mean test fails for sudo PR
2019-05-08 18:44:37 <mps> ?
2019-05-08 18:44:59 <SpaceToast> yes
2019-05-08 18:45:29 <mps> thanks, will look later, now have to go out
2019-05-08 19:12:59 <artok> oh.. gcc is version 9 now
2019-05-08 19:36:55 <SpaceToast> aye, it also got D support :D
2019-05-08 19:40:16 <artok> noticed it because updated my homebrew stuff
2019-05-08 19:41:25 <danieli> enhancements for ada too
2019-05-08 19:41:28 <danieli> and a bunch of other stuff
2019-05-08 19:41:40 <danieli> i haven't written ada in a few years but it's still cool
2019-05-08 20:36:27 <mps> sudo patch with fix for test is https://patchwork.alpinelinux.org/patch/4846/
2019-05-08 20:41:43 <mps> samba patch to add dbus-dev to makedepends on https://patchwork.alpinelinux.org/patch/4441/ but in latest samba upgrade it is already there and poster of the patch and commiter of samba upgrade is same (or it looks so, Stefan R. and  Stefan Reiff)
2019-05-08 20:42:22 <mps> question is, should be patch marked as Accepted or Superseded?
2019-05-08 21:15:20 <kr0k0> mps: Yes ^^
2019-05-08 21:15:58 <kr0k0> mps: You can close it, I wanted to enable snapper vfs module.
2019-05-08 21:16:12 <kr0k0> But that's now done with the new version.
2019-05-08 21:18:44 <mps> kr0k0: this is your post, thanks for info. I will close it then with Superseded flag
2019-05-08 21:19:35 <kr0k0> mps: Yes. You are welcome!
2019-05-08 21:19:45 <mps> thanks again
2019-05-09 04:55:42 <north1> if someone that actually develops against qt5 could test pr7712 it would help a lot, i just tested building the default empty window project and running it.
2019-05-09 05:30:23 <north1> # Contributor: <xmingske@gmail.com>
2019-05-09 05:30:36 <north1> the name is missing, is that ok ?
2019-05-09 05:43:21 <ncopa> morning
2019-05-09 05:43:28 <north1> hi
2019-05-09 05:43:43 <ncopa> lots of confusion around the http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5021
2019-05-09 05:43:52 <ncopa> https://news.ycombinator.com/item?id=19861725
2019-05-09 05:45:39 <north1> i'm suprised it didn't make to r/linux
2019-05-09 05:46:37 <north1> f*ck me, just i say there is a 1 hour ago submission to it
2019-05-09 05:47:08 <danieli> lol
2019-05-09 05:47:15 <danieli> it's made its rounds, and more to come, I bet
2019-05-09 05:48:25 <danieli> bleeping computer, zdnet, hacker news, reddit, twitter, and lots of other places
2019-05-09 05:57:26 <ncopa> i wonder how much time we should spend on it
2019-05-09 05:57:43 <ncopa> i guess it would make sense to write an explanation an post it on alpinelinux.org
2019-05-09 05:57:56 <north1> sounds good to me
2019-05-09 05:57:57 <ncopa> so we can simply point people to that
2019-05-09 05:58:08 <danieli> it's still fresh in people's minds so that'd work
2019-05-09 05:59:05 <danieli> i feel like both the severity of 9.8 and the FUD around it is a bit uncalled for
2019-05-09 05:59:18 <danieli> pet peeve, I guess :)
2019-05-09 05:59:24 <ncopa> im not good at write this kind of things
2019-05-09 05:59:37 <ncopa> what would be a good title? :)
2019-05-09 06:01:39 <danieli> I'm guessing a heartfelt essay is out of the picture, so what about something concise like "Missing 'root' password in Docker images"?
2019-05-09 06:10:05 <ncopa> I was thinking of steal the TALOS title: "Docker Image root User Hard-Coded Credential Vulnerability" or similar like that
2019-05-09 06:24:30 <ncopa> this is what I got so far: http://tpaste.us/5w0x
2019-05-09 06:25:32 <fcolista> ncopa, http://tpaste.us/YM76 it's a simple abump of qt-5.12.3. All builds fine and there's no ABI change. Should I wait for 3.10 release before pushing? I don't have many means to test Qt5
2019-05-09 06:25:42 <fcolista> beside the build, ofc
2019-05-09 06:31:56 <ncopa> will not do anything before I get the CVE article out
2019-05-09 06:36:45 <iggy> a TL;DR on a 10 line post... you the best ;)
2019-05-09 06:37:42 <north1> the TL;DR is bigger than the post itself
2019-05-09 06:39:28 <ncopa> its just the start....
2019-05-09 06:39:48 <ncopa> i was thinking of write a bit on what happened and why
2019-05-09 06:40:34 <Cogitri> That's good
2019-05-09 06:41:07 <Cogitri> fcolista: Mind publishing your apks somewhere? I can test w/ a few applications if you want
2019-05-09 07:02:37 <north1> openrc() and static() are now documented on https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2019-05-09 07:04:11 <clandmeter> nice, thx
2019-05-09 07:49:37 <tmhoang> ncopa: so it's a Docker problem, not Alpine problem, correct ?
2019-05-09 07:50:14 <_ikke_> https://news.ycombinator.com/item?id=19861725
2019-05-09 07:50:17 <ncopa> tmhoang: its a problem in the official alpine docker images, which we are responsible for
2019-05-09 07:50:43 <ncopa> _ikke_: that is the reason we need write come clarifying facts
2019-05-09 07:50:52 <ncopa> there is so much confusion
2019-05-09 07:51:06 <ncopa> "Servers and workstations that have been provisioned/installed from Alpine Linux Docker images are now at risk of being hijacked by attackers who can authenticate using the root user and no password."
2019-05-09 07:51:14 <ncopa> https://www.zdnet.com/article/alpine-linux-docker-images-ship-a-root-account-with-no-password/
2019-05-09 07:51:21 <ncopa> which is incredible misleading
2019-05-09 07:51:47 <ncopa> and plain stupid
2019-05-09 07:52:13 <ncopa> you dont provision or install Alpine linux on servers and workstations from docker images
2019-05-09 07:52:40 <ncopa> and even if you did, you would most likely not use PAM and not be affected
2019-05-09 07:53:15 <ncopa> and even if you did use PAM, this would not risk you getting hijacked by an attacker
2019-05-09 07:53:59 <_ikke_> Media don't get clicks if the headline is not dramatic
2019-05-09 07:54:13 <tmhoang> agreed
2019-05-09 07:54:22 <ncopa> that was not from the headline
2019-05-09 07:55:18 <_ikke_> It's good to publish something ourselfs
2019-05-09 07:55:32 <_ikke_> Not sure who can write something up
2019-05-09 07:55:38 <ncopa> i am working on it
2019-05-09 07:55:43 <_ikke_> ok
2019-05-09 07:55:43 <ncopa> but i may need help
2019-05-09 07:56:17 <_ikke_> https://news.ycombinator.com/item?id=19861921
2019-05-09 07:56:32 <_ikke_> Someone saying anything run on Alpine is running slower
2019-05-09 07:56:52 <_ikke_> s/anything/a lot/
2019-05-09 07:56:52 <alpine-meetbot> _ikke_ meant to say: Someone saying a lot run on Alpine is running slower
2019-05-09 07:57:05 <Cogitri> Without benchmarks of course :P
2019-05-09 07:57:26 <ncopa> i think some older version of musl made some python or javascript code run significantly slower
2019-05-09 07:57:37 <ncopa> or was it ruby
2019-05-09 07:58:18 <danieli> to be fair, some software is specifically optimized for glibc
2019-05-09 07:58:23 <ncopa> some workloads may run slower, some may run faster
2019-05-09 08:03:56 <_ikke_> https://www.phoronix.com/scan.php?page=article&item=docker-summer-2018&num=4
2019-05-09 08:03:59 <_ikke_> apparently python
2019-05-09 08:08:23 <_ikke_> https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
2019-05-09 08:22:30 <ncopa> that phoronix comparison is interesting
2019-05-09 09:03:08 <ncopa> this is how far i have come with the article: http://tpaste.us/jXQV
2019-05-09 09:03:35 <ncopa> maybe the last section will be: "how could this happen?"
2019-05-09 09:04:57 <clandmeter> im not sure i like the TL;DR although its true.
2019-05-09 09:05:26 <ncopa> thats why i post the writing progress here :)
2019-05-09 09:06:11 <ncopa> maybe just drop the TL;DR
2019-05-09 09:06:24 <clandmeter> i think the idea is good
2019-05-09 09:06:51 <clandmeter> its just a little arrogantly written imho. but maybe thats just my feeling?
2019-05-09 09:06:58 <ncopa> Im thiking of having a "what is the problem?"
2019-05-09 09:07:00 <ncopa> yeah
2019-05-09 09:08:28 <_ikke_> Maybe change TL;DR to: Am I affected?
2019-05-09 09:08:48 <ncopa> i think we should define the problem first
2019-05-09 09:08:55 <clandmeter> shoudlnt that be an answer?
2019-05-09 09:08:55 <_ikke_> yes
2019-05-09 09:13:06 <clandmeter> tldr should probably say that only in case you are using docker there is a very small case you are affected.
2019-05-09 09:24:21 <ncopa> http://tpaste.us/NKyq
2019-05-09 09:25:07 <ncopa> I wonder if I should bother write the "what happened?" or "how could this happen?" section
2019-05-09 09:27:29 <Cogitri> To be honest, it sounds good to me already
2019-05-09 09:27:55 <ncopa> Good as it is?
2019-05-09 09:28:07 <clandmeter> yes without the last line
2019-05-09 09:28:14 <Cogitri> Although I did like how e.g. Gitlab handled when they deleted their production databases accidentally
2019-05-09 09:28:20 <ncopa> I was thinking of give some background and history what led to this situation
2019-05-09 09:29:05 <ncopa> because people read the headlines and news and think "those people are really stupid that let this happen and be like this for many years"
2019-05-09 09:29:11 <Cogitri> https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
2019-05-09 09:29:40 <Cogitri> They were super open about it, that was pretty cool
2019-05-09 09:29:41 <ncopa> yes, transparency is good
2019-05-09 09:30:52 <Cogitri> I think the sysadmin who did it even had "Professional database deleter" as his Twitter bio, but that isn't necessary :)
2019-05-09 09:32:17 <ncopa> https://wwwtest.alpinelinux.org/
2019-05-09 09:32:21 <ncopa> we should have shorter title
2019-05-09 09:41:27 <ncopa> bah i dont know how to get a proper good looking code section
2019-05-09 09:48:28 <danieli> in regular markdown, `inline code` / ```multiline\ncode\nhere```?
2019-05-09 09:50:48 <ncopa> doesnt seem to work in the markdown parser
2019-05-09 09:52:28 <danieli> it *should*, but I'm not familiar with whatever markdown parser alpine-mksite is using
2019-05-09 09:55:20 <kmaxwell> I like the draft post, only thing I can suggest is a shorter title
2019-05-09 09:55:45 <kmaxwell> what about "docker image security update" or "docker image vulnerability"?
2019-05-09 09:57:52 <kmaxwell> following how Debian (https://www.debian.org/security/#DSAS) or Ubuntu (https://usn.ubuntu.com/) appear to title theirs
2019-05-09 09:58:23 <ncopa> formatting update: https://wwwtest.alpinelinux.org/posts/Docker-Image-root-User-Hard-Coded-Credential-Vulnerability.html
2019-05-09 09:58:40 <ncopa> kmaxwell: yeah, thats a good suggestion
2019-05-09 10:00:40 <kmaxwell> really minor grammar suggestion- compromised your system via **an** unrelated security
2019-05-09 10:00:52 <kmaxwell> just think the an is missing
2019-05-09 10:09:19 <ncopa> should we add a "how could this happen" section?
2019-05-09 10:10:22 <ncopa> what i want to write there is that we dont use pam
2019-05-09 10:10:34 <ncopa> but we needed to login from boot media
2019-05-09 10:10:50 <ncopa> and have a fixed, known password is worse than not have any password
2019-05-09 10:11:12 <kmaxwell> I think it might clear up potential confusion
2019-05-09 10:11:23 <ncopa> so we did root without password, but only for /etc/securetty
2019-05-09 10:11:33 <ncopa> so sshd was never affected
2019-05-09 10:12:04 <kmaxwell> also it is an opportunity to educate users, and disinterested readers can ignore it
2019-05-09 10:12:07 <ncopa> and even if we dont use pam ourselves, we added linux-pam and shadow for those who may want use that
2019-05-09 10:12:19 <ncopa> thats why it is at the bottom
2019-05-09 10:12:48 <kmaxwell> one thing that isn't completely clear to me is the different packages mentioned at the top and the bottom of the draft
2019-05-09 10:13:25 <kmaxwell> so "if you have shadow package installed" then near the end "you could make sure that you don’t have linux-pam installed"
2019-05-09 10:13:34 <ncopa> ah
2019-05-09 10:14:04 <ncopa> so the underlying problem is that shadow uses pam
2019-05-09 10:14:14 <ncopa> which does not verify /etc/securetty by default
2019-05-09 10:15:04 <ncopa> i dont know if there are any other services or tools that uses linux-pam that could accept a root user without password
2019-05-09 10:15:19 <ncopa> so i dont really know if it affects anything else but shadow package
2019-05-09 10:16:02 <kmaxwell> right so I've now realised that shadow depends on linux-pam
2019-05-09 10:16:12 <ncopa> # apk search --rdepends linux-pam | tpaste
2019-05-09 10:16:12 <ncopa> http://tpaste.us/xpOv
2019-05-09 10:16:20 <ncopa> those are potentially vulnerable
2019-05-09 10:16:49 <ncopa> so if you run vsftpd in a docker image, you may have a problem
2019-05-09 10:17:38 <ncopa> or potentially samba too
2019-05-09 10:18:06 <ncopa> any suggestion how to reword that?
2019-05-09 10:19:40 <ncopa> wwtest.alpinelinux.org is updated
2019-05-09 10:23:23 <kmaxwell> I started trying to write a 'background' section, will share in a few minutes
2019-05-09 10:31:17 <ncopa> kmaxwell: appreciate
2019-05-09 10:39:08 <kmaxwell> https://tpaste.us/YM7Z
2019-05-09 10:40:08 <kmaxwell> just throwing this (^^^) out as a starting point with some info for less technical / informed readers
2019-05-09 11:07:53 <mps> intuitively added $_tarball in APKBUILD for pkg with unusual name for source field, but after looking through aports I see there is also $_tarver. what will be appropriate of these two or to invent another one $_tarname
2019-05-09 11:36:50 <MaxPeal_> hey
2019-05-09 11:36:58 <ncopa> hi
2019-05-09 11:38:24 <north1> hi
2019-05-09 11:41:53 <ncopa> kmaxwell: i wonder if i should use your "background" section but call it "How serious is this?"
2019-05-09 11:42:24 <MaxPeal> i need an advise, what is the "right" way to expand the setup-alpine for enabel the posibility to install alpine fully via an answer file (eg for pxe and Vagrant / packer and so)
2019-05-09 11:43:41 <MaxPeal> for this the setup-alpine must be extendet with options for custom commands or custom apk runs
2019-05-09 11:44:14 <MaxPeal> befor the disk install is done
2019-05-09 11:45:24 <ncopa> ok, i think will drop the additional "how could this happen" or "backound" section
2019-05-09 11:47:20 <kmaxwell> ncopa: no problem
2019-05-09 11:47:38 <MaxPeal> i cud expand the libalpine.sh with an function for runing custom commands before and after etch run of the setup tasks
2019-05-09 11:47:59 <kmaxwell> I was struggling to imagine what the section might look like, trying to write it helped
2019-05-09 11:48:18 <MaxPeal> or just add the needed to the setup-alpine
2019-05-09 11:49:15 <kmaxwell> one message that you could try to add to the page is: you probably don't have linux-pam installed
2019-05-09 11:50:07 <_ikke_> Why is linux-pam significant? Do the default mechanisms not allow you to login with an empty password?
2019-05-09 11:56:30 <ncopa> http://tpaste.us/vbeB
2019-05-09 11:56:53 <mps> _ikke_: also I ask myself and don't know answer. What this 'NULL' password mean? without password?
2019-05-09 11:57:03 <ncopa> linux-pam is significant because that is the mechanism shadow's password
2019-05-09 11:57:09 <ncopa> yes, without password
2019-05-09 11:57:26 <north1> mps: yes no pass
2019-05-09 11:57:59 <ncopa> i think what we should do is to fix the linux-pam default config so it verifies /etc/securetty with null passwords
2019-05-09 11:58:01 <north1> ncopa: instead of using fits better
2019-05-09 11:58:39 <mps> then I think it is 'no issue'. If someone download distro or image from the net it is on them to set password or leave it 'empty'
2019-05-09 11:58:41 <ncopa> north1: how do you mean?
2019-05-09 11:58:45 <_ikke_> "linux-pam is significant because that is the mechanism shadow's password" sorry, this sentence is hard to parse
2019-05-09 11:59:06 <north1> ncopa: in the tpaste you sent 'instead of use the default tools.'
2019-05-09 11:59:23 <_ikke_> s/use/using/
2019-05-09 11:59:23 <alpine-meetbot> _ikke_ meant to say: "linux-pam is significant becausing that is the mechanism shadow's password" sorry, this sentence is hard to parse
2019-05-09 11:59:31 <ncopa> _ikke_: sorry, the line is incomplete... and i didnt notice
2019-05-09 12:00:23 <ncopa> linux-pam is significant because that is the mechanism shadow's login/su uses to authenticate
2019-05-09 12:00:32 <ncopa> PAM is a pluggable thing
2019-05-09 12:00:54 <ncopa> so you can make the system using PAM use ldap, or local files etc
2019-05-09 12:01:03 <ncopa> or a db or whatever
2019-05-09 12:01:09 <ncopa> and you can configure the rules
2019-05-09 12:01:27 <ncopa> if ldap password is missing, then fall back to local files
2019-05-09 12:01:29 <ncopa> etc
2019-05-09 12:01:54 <ncopa> in theory, other service may be vulnerable
2019-05-09 12:02:02 <ncopa> for example vsftpd
2019-05-09 12:02:09 <ncopa> it links to linux-pam
2019-05-09 12:02:33 <ncopa> so if you in a docker image run vsftpd, you may be able to log in as root with blank password too
2019-05-09 12:02:41 <ncopa> i havent tested that though
2019-05-09 12:03:28 <ncopa> same if you configure your ngircd instance to require login
2019-05-09 12:03:40 <ncopa> it may let you log in as "root" with blank password
2019-05-09 12:04:13 <ncopa> so it is not a problem that is limited to 'su'
2019-05-09 12:05:19 <mps> eh, I like Alpine because I can remove linux-pam and even shadow
2019-05-09 12:06:02 <ncopa> I like Alpine because you dont need to remove linux-pam or even shadow, because they are not there unless you install them yourself :)
2019-05-09 12:06:35 <mps> yes, I mean if it installed by some dependency
2019-05-09 12:06:52 <ncopa> i know, im just messing with you :)
2019-05-09 12:07:09 <ncopa> is this ok? or better to drop it? http://tpaste.us/Q1vO
2019-05-09 12:07:24 <mps> actually, like it because I have servers/workstation/SBC's etc without linux-pam
2019-05-09 12:08:02 <ncopa> *nod*
2019-05-09 12:08:06 <TBK[m]> I think it is ok and a good addition the rest of the announcement.
2019-05-09 12:08:23 <kmaxwell> +1 from me, I like it! :-)
2019-05-09 12:08:57 <ncopa> the last line is admitting that we messed up, which i think is good
2019-05-09 12:09:34 <SpaceToast> morning
2019-05-09 12:09:38 <SpaceToast> ncopa: LGTM
2019-05-09 12:09:45 <TBK[m]> hi
2019-05-09 12:09:49 <north1> SpaceToast: morning
2019-05-09 12:10:30 <SpaceToast> "i think what we should do is to fix the linux-pam default config so it verifies /etc/securetty with null passwords" +1
2019-05-09 12:12:18 <Cogitri> Morning
2019-05-09 12:12:27 <ncopa> hi SpaceToast
2019-05-09 12:12:40 <ncopa> ok, pushed it to https://wwwtest.alpinelinux.org/
2019-05-09 12:12:46 <ncopa> title is shorter
2019-05-09 12:12:56 <ncopa> i renamed the file so url gets shorter
2019-05-09 12:13:06 <ncopa> https://wwwtest.alpinelinux.org/posts/Docker-image-vulnerability-CVE-2019-5021.html
2019-05-09 12:13:12 <ncopa> kinda nice ot have the CVE in the url
2019-05-09 12:13:24 <SpaceToast> ncopa: fyi: lxd (likely also lxc) containers are also affected
2019-05-09 12:13:39 <SpaceToast> and those are more likely to have pam installed
2019-05-09 12:14:11 <ncopa> hum i missed an url
2019-05-09 12:14:23 <ncopa> [Docker image releases]
2019-05-09 12:19:46 <ncopa> fixed the url and another typo
2019-05-09 12:20:31 <ncopa> https://wwwtest.alpinelinux.org/posts/Docker-image-vulnerability-CVE-2019-5021.html
2019-05-09 12:20:51 <ncopa> can someone please re-read it all and check that i didtn miss anything else?
2019-05-09 12:23:11 <north1> 'and run your service as a non-root user will allow an attacker [...]'
2019-05-09 12:23:17 <kmaxwell> I will try and re-read it now
2019-05-09 12:23:46 <kmaxwell> Should we add "the" to "If you have **the** shadow package"
2019-05-09 12:24:06 <north1> kmaxwell: i think yes
2019-05-09 12:24:27 <ncopa> i think there was a missing comma some place too
2019-05-09 12:24:48 <north1> ncopa:  between 'non-root' and 'an attacker'
2019-05-09 12:24:50 <tmhoang> sorry for late to party... https://wwwtest.alpinelinux.org/posts/CVE-2019-5021.html might be ok I guess
2019-05-09 12:25:04 <north1> tmhoang: 404 on that link for me
2019-05-09 12:25:20 <tmhoang> yes of course I'm proposing how the url should look
2019-05-09 12:25:31 <north1> ah lol, sorry
2019-05-09 12:25:39 <kmaxwell> ncopa: that's me through it! I think its great, good to go :-)
2019-05-09 12:26:39 <ncopa> should maybe have a date there too
2019-05-09 12:32:11 <ncopa> north1: i think no. re 'non-root' and 'an attacker'
2019-05-09 12:32:43 <ncopa> If you ... will allow an attacker
2019-05-09 12:32:51 <mps> that is why rebuilt ngircd for me without pam
2019-05-09 12:33:01 <north1> ncopa: or allows an attacker
2019-05-09 12:33:02 <ncopa> If you have the `shadow` package installed in your Docker container and run
2019-05-09 12:33:02 <ncopa> your service as non-root user will allow an attacker who compromised your
2019-05-09 12:33:02 <ncopa> system via an unrelated security vulnerabillity, or a user with shell access,
2019-05-09 12:33:02 <ncopa> could elevate the privileges to root within the container.
2019-05-09 12:33:40 <ncopa> its a lon sentence
2019-05-09 12:33:43 <ncopa> long*
2019-05-09 12:34:42 <ncopa> If you ... will allow an attacker ..., could elevate the privileges
2019-05-09 12:35:03 <mps> sorry, couldn't resist, but IMHO one word will be enough, i.e. "Fixed"
2019-05-09 12:35:46 <ncopa> I think this is correct:
2019-05-09 12:35:49 <ncopa> If you have the `shadow` package installed in your Docker container and run
2019-05-09 12:35:49 <ncopa> your service as non-root user, an attacker who compromised your system via an
2019-05-09 12:35:49 <ncopa> the privileges to root within the container.
2019-05-09 12:35:49 <ncopa> unrelated security vulnerabillity, or a user with shell access, could elevate
2019-05-09 12:37:19 <ncopa> http://tpaste.us/oalM
2019-05-09 12:38:04 <kmaxwell> the privileges -> their privileges ?
2019-05-09 12:38:34 <kmaxwell> I think overall it is very good, these are much more minor points
2019-05-09 12:39:21 <ncopa> changed to their privileges
2019-05-09 12:39:49 <esainane> ugh, more spam
2019-05-09 12:39:51 <ncopa> spam^^^
2019-05-09 12:40:19 <ncopa> ok im pushing to prod
2019-05-09 12:40:57 <ncopa> and its live
2019-05-09 12:41:03 <_ikke_> Good
2019-05-09 12:41:28 <ncopa> thank you everyone. i appreciate your help
2019-05-09 12:41:42 <kmaxwell> fantastic, good job!
2019-05-09 12:41:58 <ncopa> this kind of writing is not my strong side and its scary with all this publicity
2019-05-09 12:43:14 <ncopa> can someone comment on hackernews and other news sites with the url to that info?
2019-05-09 12:43:24 <ncopa> maybe i should ask in #alpine-linux
2019-05-09 12:43:31 <ncopa> does not need to be devs
2019-05-09 12:43:37 <_ikke_> I already did ;p
2019-05-09 12:43:40 <_ikke_> https://news.ycombinator.com/edit?id=19867737
2019-05-09 12:44:05 <_ikke_> At least hackernews, not other news sites yet
2019-05-09 12:44:51 <north1> https://www.reddit.com/r/linux/comments/bmjcix/alpine_linuxs_response_to_cve20195021/?st=jvgn90hp&sh=afdaae57
2019-05-09 12:44:52 <alpine-meetbot> [REDDIT] Alpine Linux's response to CVE-2019-5021 (https://alpinelinux.org/posts/Docker-image-vulnerability-CVE-2019-5021.html) to r/linux | 1 points (100.0%) | 0 comments | Posted by maxice8 | Created at 2019-05-09 - 12:44:39UTC
2019-05-09 12:45:20 <ncopa> thanks!
2019-05-09 12:45:45 <ncopa> I'll add a tweet
2019-05-09 12:46:04 <north1> welcome
2019-05-09 12:48:25 <ncopa> any point in adding #CVE-2019-5021 hashtag?
2019-05-09 12:48:28 <ncopa> i guess not
2019-05-09 12:48:36 <ncopa> to the tweet
2019-05-09 12:50:04 <_ikke_> I don't think so
2019-05-09 12:52:31 <tmhoang> The following versions are EOL and still vulnerable: v3.5.x v3.4.x v3.3.x
2019-05-09 12:53:15 <_ikke_> THat's in the announcement, right?
2019-05-09 12:53:59 <TBK[m]> not the ".x" part
2019-05-09 12:54:25 <_ikke_> doesn't v3.5 imply v3.5.x?
2019-05-09 12:54:48 <kmaxwell> as fay as I understand version numbers, yes
2019-05-09 12:54:54 <kmaxwell> s/fay/far/
2019-05-09 12:54:54 <alpine-meetbot> kmaxwell meant to say: as far as I understand version numbers, yes
2019-05-09 12:54:55 <tmhoang> not critical though
2019-05-09 12:59:36 <ncopa> we didnt make patches releases of those images
2019-05-09 12:59:44 <ncopa> so there is no v3.5.x
2019-05-09 12:59:51 <ncopa> only v3.5
2019-05-09 13:00:31 <tmhoang> +1
2019-05-09 13:02:10 <kmaxwell> when I mark a draft PR ready for review, it doesn't trigger Travis
2019-05-09 13:02:22 <kmaxwell> is there an easy way to trigger Travis?
2019-05-09 13:03:10 <north1> kmaxwell: only know ways are pushing after rebasing or asking someone with access to the repo
2019-05-09 13:04:15 <kmaxwell> north1: thanks it also looks like closing and reopening the PR does it
2019-05-09 13:04:42 <kmaxwell> there are a few posts on a Travis forum, and a "we're working on it" from the company
2019-05-09 13:07:10 <north1> oh
2019-05-09 13:24:39 <MaxPeal> @ncopa RfC: IMHO it makes sens to add a EOL banner to the motd, with the EOL date  and an warning if the system date is after that
2019-05-09 14:06:45 <ncopa> MaxPeal: thats a pretty good idea
2019-05-09 14:19:59 <MaxPeal> @ncopa mybe also add an info for Companys who need to stick to a EOL version like: "this version is EOL, if you wand to stick to this, please order the suport / updates via [shop / payment site]"
2019-05-09 14:21:16 <mps> MaxPeal: please, without shop/payment words here
2019-05-09 14:22:03 <LucasRamage[m]> I have "translated" the travis configuration to GitLab CI/CD for my personal development fork. Here it is, in case it might be helpful for anyone else developing on gitlab, https://gitlab.com/oxr463/aports/blob/feature_gitlab/.gitlab-ci.yml
2019-05-09 14:23:18 <MaxPeal> @mps it was just a mybe
2019-05-09 14:23:44 <mps> LucasRamage[m]: thanks for sharing. it will be useful for me to look at it
2019-05-09 14:27:08 <mps> MaxPeal: np, just told my opionion
2019-05-09 14:27:34 <MaxPeal> @mps no problem
2019-05-09 14:29:19 <SpaceToast> LucasRamage[m]: might be interesting to have/get build artifacts, since gitlab-runner can do that
2019-05-09 14:45:40 <mps> north1: I tried zstd upgrade on armhf, check fail whatever option I tried
2019-05-09 14:49:27 <north1> mps: you tried running the testsuite or using the program ?
2019-05-09 14:50:50 <mps> it's tests
2019-05-09 14:51:45 <mps> here is error msg: "zstd: error 1 : Rsyncable mode is not compatible with single thread mode"
2019-05-09 14:53:24 <north1> hm, don't have that on x86_64
2019-05-09 14:54:24 <mps> it seems armhf specific, later will try on armv7. It's check() is really slow
2019-05-09 14:54:55 <north1> ok, thank you
2019-05-09 14:55:06 <north1> i rely on CI for running tests for everything but x86_64 and x86 (sometimes)
2019-05-09 14:56:59 <mps> I tried armhf edge under chroot
2019-05-09 15:53:25 <_ikke_> Why is shotcut being rebuilt on edge while the last change to it was in March?
2019-05-09 16:00:46 <ncopa> i will try tag new 3.9.x release later tonight
2019-05-09 16:00:57 <ncopa> would be nice to fix some of the bugs with 3.9.4 target
2019-05-09 16:01:02 <_ikke_> shotcut is unmaintained and currently failing to build
2019-05-09 16:01:28 <ncopa> https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=143&set_filter=1&status_id=o
2019-05-09 16:01:37 <ncopa> _ikke_: will check that later tonight
2019-05-09 16:01:41 <_ikke_> https://github.com/NixOS/nixpkgs/pull/56875
2019-05-09 16:01:46 <_ikke_> Testing update now
2019-05-09 16:02:50 <andypost[m]> ncopa strange but provides does not work for 3.10 pr7709
2019-05-09 16:03:33 <_ikke_> ncopa: any clue why shotcut is being rebuilt in the first place (and apparently only on armv7)
2019-05-09 16:29:42 <_ikke_> ncopa: I have a fix for shotcut probably, will push later
2019-05-09 16:38:28 <doggone> Can I nudge a little to take a look at https://patchwork.alpinelinux.org/patch/4835/ ? The thing is, temporary workarounds get screwed when dovecot is updates, because the .apk-new contains the bug and is still parsed at boot.
2019-05-09 17:06:09 <mps> doggone: I looked at patch but hesitate to propose push because you changed pid handling. is that really needed
2019-05-09 17:11:36 <doggone> the problem is that the pidfile=$(...) gets parsed at boot immediately, before crng init, so I moved it into a function
2019-05-09 17:12:43 <doggone> now it gets parsed only when the service is actually supposed to do something
2019-05-09 17:14:06 <doggone> and only after entropy is provided
2019-05-09 17:14:31 <mps> I do not meant to say it is bad idea, just asked what is rationale for that
2019-05-09 17:15:30 <doggone> apparently the doveconf binary needs randomness. when the script is read (to determine depends etc.) it can hang the whole system, because there is no established randomness yet at that point
2019-05-09 17:17:09 <mps> that's obvious and known issue. Anyway I think it should be reviewed by pkg maintainer before push
2019-05-09 17:17:17 <doggone> that's what happens on my mail servers. and because of the recent security update to dovecot, I got the "bad" file again in /etc/init.d/dovecot.apk-new, which is actually never used but it still gets read at boot and hangs the system.
2019-05-09 17:17:32 <mps> and, I think this needs to be pushed
2019-05-09 17:18:30 <mps> my observation is that the dovecot probably need a dovecot.conf aports file
2019-05-09 17:18:44 <doggone> yep, which means everyone implementing a workaround will get screwed over every update to the package
2019-05-09 17:19:43 <mps> not every pkg update, but on new stable Alpine release
2019-05-09 17:20:32 <doggone> doesn't every update create .apk-new files?
2019-05-09 17:20:57 <mps> only if the conf changed by admin/user
2019-05-09 17:21:23 <doggone> which is required to work around the issue :)
2019-05-09 17:22:07 <mps> to be honest I'm not sure. I would left decision to pkg maintainer
2019-05-09 18:21:15 <andypost[m]> Sounds like sqlite is security upgrade...CVE-2019-5018
2019-05-09 18:36:01 <mps> would someone with push rights to main review and push sudo fixes and upgrade to to 1.8.27, https://patchwork.alpinelinux.org/patch/4846/
2019-05-09 19:04:15 <ncopa> doggone: from 5 sec look at your patch, it looks good. we should not do the pidfile=$() in global scope
2019-05-09 19:05:59 <ncopa> mps: there was a PR with sudo, but the testsuite failed
2019-05-09 19:17:15 <mps> ncopa: I know for PR, I took it and added fixes, mentioned that in annotation
2019-05-09 19:19:07 <ncopa> mps: ah. sorry, i didnt follow the link
2019-05-09 19:19:14 <ncopa> i think need to tag 3.9.4 release now
2019-05-09 19:20:19 <mps> ncopa: np, I see that you are busy
2019-05-09 19:48:10 <ncopa> curl: (6) Could not resolve host: github.com
2019-05-09 19:48:16 <_ikke_> where?
2019-05-09 19:48:25 <ncopa> in my dev machine
2019-05-09 19:48:31 <ncopa> second run it worked
2019-05-09 19:48:38 <ncopa> ncopa-edge-armv7
2019-05-09 19:53:14 <_ikke_> drone builders are faster than travis apparently, even the usual slower arm arches are faster than the travis build
2019-05-09 19:56:03 <danieli> waat, did DNS fail?
2019-05-09 19:56:42 <_ikke_> once at least :)
2019-05-09 20:00:10 <clandmeter> I also have issues with dns
2019-05-09 20:00:25 <clandmeter> It's slow initial req
2019-05-09 20:00:47 <_ikke_> on my container it's fast
2019-05-09 20:01:09 <clandmeter> to tpaste
2019-05-09 20:02:27 <_ikke_> ncopa: I think I have fixed shotcut, just waiting for the armv7 to retry it
2019-05-09 20:04:57 <_ikke_> Yes, it's green now
2019-05-09 20:12:48 <ncopa> is it for v3.9?
2019-05-09 20:13:04 <ncopa> im about to tag v3.9.4 so please dont push anything there right now
2019-05-09 20:13:31 <_ikke_> No, it's in testing
2019-05-09 20:13:34 <_ikke_> so only edge
2019-05-09 20:13:48 <ncopa> ok. good
2019-05-09 20:14:17 <ncopa> im just waiting for the s390x builder to finish build mariadb
2019-05-09 20:14:28 <ncopa> i think 3 mariadb builds is heavy for it
2019-05-09 20:15:04 <_ikke_> I can imagine
2019-05-09 20:15:40 <ncopa> i will be afk from sunday. are there anyone aroudn that can push to main meanwhile?
2019-05-09 20:16:04 <ncopa> i am hoping that the 3.10 builders will be done when i come back ;)
2019-05-09 20:16:58 <_ikke_> clandmeter said he was busy with gitlab integratiin
2019-05-09 20:17:01 <_ikke_> integration
2019-05-09 20:17:11 <ncopa> maybe fcolista and rnalrd
2019-05-09 20:17:15 <_ikke_> right
2019-05-09 20:18:24 <ncopa> and fabled if he has time
2019-05-09 20:39:09 <kr0k0> Hi all
2019-05-09 20:39:55 <kr0k0> Could someone restart travis-ci for pr7753?
2019-05-09 20:40:27 <_ikke_> done
2019-05-09 20:40:35 <kr0k0> I have fixed arm*/aarch64 problem and now travis-ci is unable to load source -.-
2019-05-09 20:40:42 <kr0k0> _ikke_: Thanks!
2019-05-09 20:40:46 <danieli> _ikke_: ninja
2019-05-09 20:40:58 <_ikke_> heh
2019-05-09 20:42:15 <kr0k0> _ikke_: Is it possible to merge this for 3.10, or is it already too late?
2019-05-09 20:43:50 <_ikke_> 3.10 has not been branched yet, so afaik it's not too late yet
2019-05-09 20:44:11 <danieli> I'm gonna make an erlang PR
2019-05-09 20:44:18 <danieli> they fixed their ssl bug
2019-05-09 20:44:49 <danieli> oop, no, it was a patch of the previous version, darn it
2019-05-09 20:45:54 <kr0k0> _ikke_: Ah nice. But fetching source again failed... Sorry to bother you.
2019-05-09 20:46:38 <danieli> curl: (19) RETR response: 425
2019-05-09 20:47:22 <_ikke_> kr0k0: ah, travis does not support ftp\
2019-05-09 20:47:26 <_ikke_> so that won't work
2019-05-09 20:47:28 <danieli> right, it's attempting http lol
2019-05-09 20:47:49 <_ikke_> Some kind of natting issue
2019-05-09 20:47:52 <kr0k0> Ok, didn't know that.
2019-05-09 20:48:04 <_ikke_> You can just ignore it
2019-05-09 20:48:05 <danieli> http://ftp.tvdr.de/vdr-2.4.0.tar.bz2
2019-05-09 20:48:06 <danieli> try this
2019-05-09 20:48:10 <_ikke_> or that
2019-05-09 20:48:26 <kr0k0> If someone has time, please merge if it's ok for you.
2019-05-09 20:49:18 <_ikke_> It's quite big, will take some time to review
2019-05-09 20:49:54 <_ikke_> ie, not just a couple of minutes, it's quite late for me, so I'll try to look at it tomorrow
2019-05-09 20:50:05 <ncopa> whee!! s390x builder is finally done with mariadb
2019-05-09 20:50:12 <_ikke_> nice
2019-05-09 20:50:20 <_ikke_> 3.9.4 time
2019-05-09 20:50:21 <ncopa> and 3.9.4 is tagged
2019-05-09 20:50:54 <kr0k0> _ikke_: N+n++
2019-05-09 20:51:01 <kr0k0> sorry
2019-05-09 20:51:09 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.9.4-released.html
2019-05-09 20:51:12 <kr0k0> _ikke_: No problem
2019-05-09 20:51:32 <_ikke_> ncopa: checking
2019-05-09 20:52:36 <_ikke_> ncopa: looks good
2019-05-09 21:09:17 <ncopa> oh no
2019-05-09 21:10:10 <_ikke_> \/o\
2019-05-09 21:10:12 <MaxPeal> bye
2019-05-09 21:10:19 <ncopa> bye
2019-05-09 21:10:24 <_ikke_> whats up/
2019-05-09 21:10:43 <ncopa> release failed
2019-05-09 21:10:48 <ncopa> for armhf and ppc64le
2019-05-09 21:10:58 <ncopa> and i really want to go to bed
2019-05-09 21:11:06 <_ikke_> Can imagine
2019-05-09 21:11:08 <_ikke_> what failed?
2019-05-09 21:11:13 <ncopa> dunno
2019-05-09 21:12:16 <ncopa> seems like armhf is completely missing
2019-05-09 21:12:30 <_ikke_> I see the release on ppc64le
2019-05-09 21:12:36 <ncopa> ppc64le builder seems to have failed create the last image
2019-05-09 21:12:54 <ncopa> the standard image
2019-05-09 21:13:30 <_ikke_> http://master.alpinelinux.org/alpine/v3.9/releases/ppc64le/alpine-standard-3.9.4-ppc64le.iso
2019-05-09 21:13:32 <_ikke_> this one?
2019-05-09 21:14:24 <ncopa> oh, it showed up
2019-05-09 21:14:26 <ncopa> nice
2019-05-09 21:14:55 <ncopa> so it was just the upload that was slow
2019-05-09 21:15:06 <ncopa> its high latency link
2019-05-09 21:15:15 <ncopa> ok
2019-05-09 21:15:19 <_ikke_> yes, it is
2019-05-09 21:15:40 <ncopa> armhf was missing due to the builder has been off for many days
2019-05-09 21:16:27 <ncopa> its on now again and working
2019-05-09 21:16:35 <ncopa> looks like it has 20 packages to build
2019-05-09 21:16:48 <ncopa> ok, so we are good basically
2019-05-09 21:17:12 <ncopa> i will probably just have to sign the images tomorrow
2019-05-09 21:17:16 <_ikke_> Where do you see how many packages it needs to build?
2019-05-09 21:17:20 <ncopa> and create docker images tomorrow
2019-05-09 21:17:29 <ncopa> it said 5%
2019-05-09 21:17:33 <_ikke_> ah ok
2019-05-09 21:17:34 <_ikke_> yes
2019-05-09 21:17:35 <ncopa> on the first package
2019-05-09 21:17:40 <ncopa> and 10% on the second
2019-05-09 21:17:40 <_ikke_> 15% now
2019-05-10 05:52:58 <ncopa> morning
2019-05-10 06:04:52 <kr0k0> morning
2019-05-10 06:08:09 <Cogitri> Morning
2019-05-10 06:25:44 <north1> Morning
2019-05-10 06:28:25 <danieli> morning
2019-05-10 06:58:43 <telmich> moin moin
2019-05-10 06:59:05 <telmich> is there any interest in an arm64 build server?
2019-05-10 07:02:48 <mps> telmich: HW or VM or container
2019-05-10 07:06:38 <telmich> mps: hW
2019-05-10 07:09:50 <mps> so, machine to be given to alpine project or ssh access for developers?
2019-05-10 07:11:16 <danieli> it's not cheap to colocate servers, so i'd assume they meant something along the lines of the latter option
2019-05-10 07:12:03 <danieli> problem is: i'm not so sure the alpine build system is geared to do queues and distribute builds over multiple builders, except per arch (and possibly per branch/version?)
2019-05-10 07:12:35 <telmich> mps: danieli: it would be a dedicated machine located in Switzerland
2019-05-10 07:13:30 <mps> telmich: with ssh access to shell, I presume, for developers
2019-05-10 07:13:57 <telmich> mps: sure
2019-05-10 07:14:55 <mps> nice, and thanks. I think it could be interesting
2019-05-10 07:15:07 <danieli> i mean, it's up to ncopa and clandmeter
2019-05-10 07:16:21 <mps> danieli: yes, I thought to tell telmich to also join #alpine-infra and post his this there
2019-05-10 07:16:46 <danieli> probably a good idea, but i don't think it'll be buried in #alpine-devel this early in the morning (EU) unless we talk a lot
2019-05-10 07:21:43 <mps>    imo, for free source project is good to have different 'sponsors' however small or big they are
2019-05-10 07:23:40 <danieli> very true, but it (probably) depends on whether there's a use for the machine or not
2019-05-10 07:23:52 <danieli> there's no point in letting it sit completely idle
2019-05-10 07:24:57 <mps> ofc, and I have a hope that the talented developers will find it's usefulness, sooner or later
2019-05-10 07:32:57 <_ikke_> The current build system is geared towards a single builder per arch
2019-05-10 07:35:06 <danieli> yeah, that's what i was thinking. but hey, there's always a use for resources for *something*
2019-05-10 07:35:48 <_ikke_> Note that what we have currently is due for a change, we just need to decide what it's going to be
2019-05-10 07:41:17 <danieli> i don't think there are any existing solutions that could be near drop-in, it's a nontrivial problem
2019-05-10 07:53:29 <_ikke_> There never is
2019-05-10 08:56:56 <mps> Cogitri: you didn't pushed llvm8 to aports, it seems. and there is a pw.a.o for it https://patchwork.alpinelinux.org/patch/4844/
2019-05-10 08:57:29 <mps> when you find some time could you look at it
2019-05-10 09:00:24 <Cogitri> mps: pr7500
2019-05-10 09:01:18 <Cogitri> Will check once I'm home if it's the same
2019-05-10 09:01:58 <mps> ok, thanks
2019-05-10 09:46:21 <eu> for check(), should I use upstream `bundle --quiet && bundle exec ruby acceptance_test.rb` or package the check deps and run the tests without bundler?
2019-05-10 09:47:32 <_ikke_> we prefer the latter
2019-05-10 10:03:44 <eu> thanks, was unsure about check() since it did not exist when I last packaged
2019-05-10 10:39:29 <mps> is pkgrel bump needed for re-enabling build of pkg
2019-05-10 10:40:40 <mps> now it is disabled by set of arch to "" (empty) and I would like to enable it again
2019-05-10 10:40:54 <_ikke_> No
2019-05-10 10:41:11 <_ikke_> If a specific package is not existing, no pkgrel bump is needed to get them to build
2019-05-10 10:41:38 <mps> _ikke_: It exist in aports but is disabled on builders
2019-05-10 10:41:50 <_ikke_> mps: The specific version of the package exists?
2019-05-10 10:41:57 <_ikke_> $pkgname-$pkgver-$pkgrel?
2019-05-10 10:42:16 <mps> testing/zathura-pdf-mupdf
2019-05-10 10:42:29 <_ikke_> but not the specific version that you want to enable again?
2019-05-10 10:43:05 <mps> current version as is in aports, it have now arch=""
2019-05-10 10:43:34 <_ikke_> https://pkgs.alpinelinux.org/packages?name=zathura-pdf-mupdf&branch=edge -> empty
2019-05-10 10:43:58 <_ikke_> So it's not built yet
2019-05-10 10:43:58 <mps> it is not built anytime
2019-05-10 10:44:02 <_ikke_> Right
2019-05-10 10:44:10 <_ikke_> then no pkgrel bump is necessary
2019-05-10 10:44:26 <_ikke_> The builders see the package is not built yet, so they will build it
2019-05-10 10:44:37 <mps> I disabled it because mupdf wasn't built at time when I posted aports
2019-05-10 10:44:40 <_ikke_> nod
2019-05-10 10:45:01 <_ikke_> just setting arch="all" or something is enough
2019-05-10 10:45:12 <mps> so, no bump is needed
2019-05-10 10:45:40 <_ikke_> correct
2019-05-10 10:46:10 <mps> _ikke_: thank you, you are very helpful as always
2019-05-10 10:46:27 <_ikke_> no problem
2019-05-10 10:49:00 <_ikke_> Strange, from my container I have issues downloading a patch from github
2019-05-10 10:49:22 <clandmeter> dns or network?
2019-05-10 10:49:45 <_ikke_> Doesn't seem dns
2019-05-10 10:50:03 <mps> btw, it would be nice if algitbot can tell what pkg is uploaded, on #alpine-commits
2019-05-10 10:50:23 <clandmeter> i dont think we want to make it to verbose
2019-05-10 10:50:34 <_ikke_> It can be multiple packages at once
2019-05-10 10:51:02 <_ikke_> now it's working again btw
2019-05-10 10:51:07 <mps> hmm, 'edge/testing/x86: uploaded'
2019-05-10 10:51:49 <mps> maybe something like: 'edge/testing/x86: pkgname uploaded'
2019-05-10 10:52:20 <mps> not much more verbose, imo
2019-05-10 10:52:28 <_ikke_> mps: What if there are 10 packages?
2019-05-10 10:52:32 <_ikke_> or 20
2019-05-10 10:52:53 <_ikke_> It doesn't upload packages one by one. It builds all packages it needs to rebuild, and then uploads them in one go
2019-05-10 10:53:21 <mps> omg, didn't know that it also uploads 'bundles' of packages
2019-05-10 10:54:08 <_ikke_> The upload happens at the end, once it finished building all packages. So if one package failed, nothing gets uploaded
2019-05-10 10:55:15 <mps> hm, to me it looks like it upload one by one, http://tpaste.us/gMlb
2019-05-10 10:55:31 <_ikke_> Those are different builders
2019-05-10 10:56:02 <clandmeter> the upload function is stupid
2019-05-10 10:56:18 <clandmeter> at least i think it is :)
2019-05-10 10:56:42 <danieli> where is github hosted these days - which cloud?
2019-05-10 10:57:08 <mps> clandmeter: for some unknown reason I tend to agree with you ;)
2019-05-10 10:57:11 <danieli> i think google cloud is having some issues atm
2019-05-10 10:57:28 <tmhoang> danieli: how so
2019-05-10 10:57:58 <danieli> discord went down with HTTP 522 "Origin Connection Time-out" and GitHub resources are giving HTTP 503 "Backend is unhealthy"
2019-05-10 10:58:26 <danieli> _ikke_: so I suspect it might just be GitHub and not us :)
2019-05-10 11:01:17 <danieli> looks better now
2019-05-10 11:01:32 <danieli> GLB was fine so it might have been a network issue with GCP since it was a brief outage
2019-05-10 11:08:34 <clandmeter> ncopa: any comment regarding https://tpaste.us/eelO
2019-05-10 11:14:26 <_ikke_> danieli: maybe one or more nodes that had issues, via my browser everything still worked
2019-05-10 11:14:42 <danieli> i mean, it loaded, but the user content site had issues
2019-05-10 11:15:02 <danieli> got a ton of 503s in the network tab in dev tools when i reloaded
2019-05-10 11:57:28 <tcely> clandmeter: why not a relative link target?
2019-05-10 12:22:32 <tmhoang> is it okay if I run 2 abuild processes at the same time, building 2 packages ?
2019-05-10 12:22:58 <ncopa> clandmeter: I will have to look closer when I get home. I don’t think I understand the problem you’re trying to solve
2019-05-10 12:23:27 <_ikke_> tmhoang: I'd say it should be fine, but I don't know how it interacts when two processest try to update the new package index
2019-05-10 12:23:44 <tmhoang> good point
2019-05-10 12:23:52 <danieli> let's hope they don't finish at the exact same time
2019-05-10 12:24:18 <ncopa> tmhoang: may be ok unless the packages will automatically use dependencies it finds
2019-05-10 12:24:55 <ncopa> I think abuild rootbld will work
2019-05-10 12:25:32 <ncopa> Index generation may be racy
2019-05-10 12:39:11 <TBK[m]> I am having trouble with abuild unpacking gcompat 0.4.0 src - http://tpaste.us/roXD
2019-05-10 12:39:11 <TBK[m]> Any advice?
2019-05-10 12:42:58 <p4Wv1qn095FW> maybe ask awilfox to republish the tar as it seems it has been packaged with some non-standard tar?
2019-05-10 12:43:11 <_ikke_> bsdtar perhaps
2019-05-10 12:43:12 <_ikke_> ?
2019-05-10 12:43:17 <p4Wv1qn095FW> star maybe?
2019-05-10 12:43:53 <p4Wv1qn095FW> or some kde archive like ark or so.
2019-05-10 12:44:15 <p4Wv1qn095FW> but the busybox tar definitely does not cope with that.
2019-05-10 12:46:06 <danieli> adelie uses coreutils, right_
2019-05-10 12:46:07 <danieli> ?
2019-05-10 12:46:25 <danieli> iirc it's an extension, and whatever `tar` you're using doesn't support it
2019-05-10 12:48:40 <TBK[m]> just default busybox for now. Will look at how Adelie handles it - https://code.foxkit.us/adelie/abuild/commits/master
2019-05-10 12:51:16 <danieli> see if it works with gnu tar
2019-05-10 12:51:50 <_ikke_> bsdtar iirc
2019-05-10 12:52:19 <danieli> i haven't hit that issue in some time, but i've seen precisely the same thing before
2019-05-10 13:33:44 <clandmeter> ncopa: for most applications /etc/ssl/certs/ca-certificates.crt is the default certificate source
2019-05-10 13:35:28 <clandmeter> but we have an alternative named /etc/ssl/cert.pem which we use for busybox with libtls-standalone
2019-05-10 13:35:35 <clandmeter> to keep the base image small
2019-05-10 13:36:23 <clandmeter> its provided by ca-certificates-cacert
2019-05-10 13:38:00 <clandmeter> so the symlink would add basic cert support for applications that support it. if you need full fledged certification support you would need to install ca-certificates.
2019-05-10 13:47:36 <ncopa> ok, makes sense
2019-05-10 13:48:30 <ncopa> so what i wonder is why the difference /etc/ssl/certs/ca-certificates.crt and /etc/ssl/cert.pem
2019-05-10 13:48:41 <ncopa> i assume that is due to openssl vs libressl
2019-05-10 13:50:03 <ncopa> i wonder where those paths comes from
2019-05-10 13:50:20 <ncopa> if its from some config file or if its the hardcoded default in code
2019-05-10 13:51:58 <otlabs> hi ppl
2019-05-10 13:52:05 <ncopa> hi
2019-05-10 13:52:27 <otlabs> ncopa: greetings!
2019-05-10 13:52:37 <Cogitri> Hello :)
2019-05-10 13:52:38 <north1> hi
2019-05-10 13:52:47 <otlabs> Cogitri: yo!
2019-05-10 13:53:01 <otlabs> north1: how dee
2019-05-10 13:54:49 <otlabs> we have a package main/py-tz, https://git.alpinelinux.org/aports/tree/main/py-tz/APKBUILD
2019-05-10 13:54:59 <otlabs> i would like to update it to latest one
2019-05-10 13:55:12 <danieli> go ahead
2019-05-10 13:55:23 <otlabs> i have a problem
2019-05-10 13:55:31 <north1> do it
2019-05-10 13:55:32 <north1> please tag the maintainer on your PR
2019-05-10 13:55:48 <otlabs> i am unable to build it
2019-05-10 13:55:53 <danieli> 2019.1 is the latest version apparently
2019-05-10 13:56:01 <otlabs> it tries to read out of build dir
2019-05-10 13:56:09 <north1> well...
2019-05-10 13:56:18 <north1> give us the build logs or no help can be given
2019-05-10 13:56:20 <danieli> could you.. perhaps paste the build output..?
2019-05-10 13:56:27 <danieli> we have no clue what it could be without logs / more inf
2019-05-10 13:56:29 <danieli> o
2019-05-10 13:56:39 <otlabs> danieli: sure, give me a second
2019-05-10 13:57:22 <ncopa> otlabs: a wild guess: a variable is misspelled. If for example $pkgdir is misspelled, it will try read from root
2019-05-10 13:57:39 <otlabs> not the case
2019-05-10 13:57:53 <otlabs> it wants to read /etc/zoneinfo
2019-05-10 13:58:52 <otlabs> danieli: give me a minute, i will create a PR as i am still unable to copy-paste from my VM here
2019-05-10 13:59:08 <danieli> i just built the latest version of py-tz (2019.1)
2019-05-10 13:59:16 <danieli> it took 27 seconds
2019-05-10 13:59:25 <north1> built here
2019-05-10 13:59:52 <otlabs> :-O
2019-05-10 14:24:33 <otlabs> north1: pr7775
2019-05-10 14:24:56 <otlabs> but now i have a new problem: the checksum is broken for source file
2019-05-10 14:26:14 <danieli> uh.. did you run `abuild checksum`?
2019-05-10 14:26:15 <danieli> it worked for me
2019-05-10 14:27:03 <otlabs> yes, i run it localy and run abuild -r to get to my error message
2019-05-10 14:27:15 <otlabs> my proxy must be playing on me
2019-05-10 14:28:44 <otlabs> let me try something to force new download of source file
2019-05-10 14:30:09 <mort___> otlabs: hi! i'm looking at https://github.com/alpinelinux/docker-abuild/issues/11 at the moment :)
2019-05-10 14:30:16 <mort___> i think i don't understand apk repos well
2019-05-10 14:30:46 <otlabs> mort___: hi! nice to meet you here!
2019-05-10 14:30:51 <otlabs> me too
2019-05-10 14:31:12 <otlabs> the problem is in /etc/apk/repositories file
2019-05-10 14:31:18 <mort___> yeah
2019-05-10 14:31:38 <otlabs> it has several lines to enable main, community and testing subdirectories/repos
2019-05-10 14:31:53 <mort___> yeah
2019-05-10 14:32:03 <mort___> i think i'll simplify that first
2019-05-10 14:32:04 <otlabs> and the line corresponding to .../testing/... is commented out
2019-05-10 14:32:13 <mort___> i've uncommented the /testing/ line
2019-05-10 14:32:17 <mort___> so it reads
2019-05-10 14:32:17 <mort___> http://dl-cdn.alpinelinux.org/alpine/edge/testing
2019-05-10 14:32:24 <mort___> but -r still doesn't seem to work
2019-05-10 14:32:26 <mort___> -R does though
2019-05-10 14:32:28 <otlabs> yes! please!
2019-05-10 14:37:23 <otlabs> danieli: could you pelase check the build log at https://cloud.drone.io/alpinelinux/aports/3117 ? it reproduces the same error i have locally
2019-05-10 14:38:57 <otlabs> mort___: i will be able to check the changes in about 6 hours, thank you!
2019-05-10 14:40:17 <otlabs> one more thing i would like to discuss - how to update alpine-sdk packages? from time to time they got updated. should the dabuild script tun apk upgrade? or should be possible to force new docker image be build?
2019-05-10 14:40:59 <mort___> i think clandmeter did propose that we put the build of the images as cron jobs
2019-05-10 14:41:04 <mort___> not done yet tho
2019-05-10 14:41:35 <otlabs> oh, great! so it would be centralized
2019-05-10 14:41:38 <mort___> yeah
2019-05-10 14:42:00 <mort___> so a daily (or more frequent?!) rebuild that pushed to docker hub
2019-05-10 14:42:36 <otlabs> are docker image files compressed?
2019-05-10 14:43:32 <otlabs> as i do not know i am thinking what would be more beneficial - re-download the whole docker image or just update it with apk upgrade as apk packages are compressed?
2019-05-10 14:43:35 <mort___> i believe they're overlay filesystem images which are basically compressed tarballs
2019-05-10 14:43:45 <otlabs> oh, ok
2019-05-10 14:44:14 <mort___> so the pull of hte new image will fetch only the altered layers
2019-05-10 14:44:25 <otlabs> great
2019-05-10 14:44:33 <mort___> if you ran apk update locally, it would not update teh image locally because changes are not retained between container instances
2019-05-10 14:44:45 <mort___> (unless, hopefuly, if you were using the attempt at caching via volumes that i put in the script)
2019-05-10 14:44:59 <mort___> (in which case changes should be cached into the local volumes that get mounted)
2019-05-10 14:45:16 <otlabs> or i can just rebuild the whole image locally
2019-05-10 14:45:39 <Cogitri> mps: Just looked at llvm8. It's the same as my PR, but I've also added libxml2-dev as makedepends, but that's not required, I guess. Please also remove the default_llvm bit from llvm7 and pkgrel bump it
2019-05-10 14:45:44 <mort___> yeah, if you clone the repo and (say) `make images` then you'll get your own copies
2019-05-10 14:46:50 <mps> Cogitri: this is not my post, you should ask original poster
2019-05-10 14:47:25 <mort___> if you set the ORG variable for make then you could cause the dabuild script to point to your own hub images
2019-05-10 14:48:29 <mps> I thought it looks same as your, because that I asked you
2019-05-10 14:49:58 <mps> actually, I built llvm8 from you PR
2019-05-10 14:51:41 <Cogitri> Ah, alright. I don't know patchwork at all, could you maybe comment on it for me?
2019-05-10 14:53:12 <mps> nothing special, people send patch by mail and then reviewers look at it and if it looks ok apply it, else reply to poster to fix it and resend
2019-05-10 14:53:55 <mps> in my view, it is the same as PR on github, only different infra
2019-05-10 14:54:27 <danieli> it's kinda like PRs but with email and sans the forking/branching
2019-05-10 14:54:29 <mps> you can also review it and reply to poster
2019-05-10 14:55:28 <mps> afaik, linux kernel uses only patchwork
2019-05-10 14:57:02 <Cogitri> Soo...I have to send an email to comment on the thing?
2019-05-10 14:57:28 <danieli> yes, patchwork through lkml
2019-05-10 14:57:34 <mps> I think this will not be problem for you
2019-05-10 14:57:43 <Cogitri> Ugh
2019-05-10 14:58:04 <Cogitri> Yeah, I just dislike the ML based workflow a lot
2019-05-10 14:58:26 <mps> ehhm, web generation :)
2019-05-10 14:59:24 <Cogitri> Heh
2019-05-10 14:59:44 <Cogitri> Err...where do I see the email to reply to?
2019-05-10 15:00:25 <mps> mail workflow is similar, and it is not so hard. I think it wouldn't be problem as you have great knowledge and understanding of these things
2019-05-10 15:01:29 <mps> one day, when you made patch for kernel you will have to that anyway
2019-05-10 15:01:42 <mort___> otlabs: ok i've attempted to fix things and am rebuilding and pushing the images now
2019-05-10 15:01:50 <mort___> if you could let me know on the issue if it works, that'd be great
2019-05-10 15:02:49 <otlabs> with pleasure! i will be able to test  new version in about 5 hours and i will let you know about any possible observation i will have! thank you!
2019-05-10 15:02:59 <mort___> (fwiw i think it should now let you build testing/ packages though the particular one you reference in the issue doesn't seem to build successfully for me)
2019-05-10 15:03:01 <mort___> thanks :)
2019-05-10 15:03:04 <otlabs> this dabuild is so a great help for me
2019-05-10 15:04:10 <mort___> good :)
2019-05-10 15:04:15 <SpaceToast> Heya mort___
2019-05-10 15:04:16 <mort___> i'm glad i wrote something useful :)
2019-05-10 15:04:22 <mort___> hi SpaceToast
2019-05-10 15:04:27 <mort___> o/
2019-05-10 15:04:36 <SpaceToast> Theoretical question: could dabuipd work over networked docker?
2019-05-10 15:05:00 <mort___> hm
2019-05-10 15:05:03 <mort___> networked docker?
2019-05-10 15:05:19 <SpaceToast> I.e I dev on my laptop, but my builder is a server on lan
2019-05-10 15:05:32 <SpaceToast> It would be nice if I could run dabuild on my laptop, but the server did the work
2019-05-10 15:05:36 <mort___> i think if you're using UCP then that should just make that work
2019-05-10 15:05:47 <mort___> i will confess to not having a huge amount of experience with that though
2019-05-10 15:06:07 <otlabs> mort___: i used to use a VM with alpine linux running, i was unable (or to lazy) to configure copy-paste and i have very limited resources assigned to that VM. dabuild solves all my primary issues and besides i learn how to use docker ;-) thank you!
2019-05-10 15:06:12 <SpaceToast> I'm mostly worried about data flow, since I'm not sure docker can actually do remote mounts
2019-05-10 15:06:50 <SpaceToast> Sidenote: I'm familiar with namespaces and lxc/lxd, less so docker
2019-05-10 15:07:27 <danieli> docker itself won't do volumes (mounts) over network as far as i know
2019-05-10 15:07:30 <danieli> it is however possible to use nfs
2019-05-10 15:07:37 <danieli> or something else, for that sake
2019-05-10 15:07:41 <mort___> yes, i believe that's correct
2019-05-10 15:07:44 <mort___> SMB? :)
2019-05-10 15:08:04 <[[sroracle]]> TBK[m] danieli: we use libarchive tar by default
2019-05-10 15:08:21 <SpaceToast> That's unfortunate, and means it probably isn't really worth it for me :/
2019-05-10 15:09:18 <TBK[m]> [[sroracle]]: thanks
2019-05-10 15:09:38 <mort___> SpaceToast: mgiht be worth looking to see if there's a volume plugin that enables mounts over the network?
2019-05-10 15:09:48 <mort___> i've not tried myself but there might be one out there
2019-05-10 15:10:01 <TBK[m]> "Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality." https://docs.docker.com/storage/volumes/
2019-05-10 15:10:45 <Cogitri> mps: Alright, I don't feel like wasting more time into struggling with the ML approach, it's good to merge as-is anyway, it just needs an additional commit for LLVM7 to not be the default anymore.
2019-05-10 15:12:13 <mort___> SpaceToast TBK[m]: yes - https://docs.docker.com/storage/volumes/#use-a-volume-driver
2019-05-10 15:12:17 <mort___> has an example using sshfs
2019-05-10 15:12:43 <mps> Cogitri: ok, I will post reply to ML and ask poster to include/rework it according your comments
2019-05-10 15:13:16 <SpaceToast> that looks like it's going the other direction (server <- host rather than host -> server) :/
2019-05-10 15:13:26 <SpaceToast> and is getting into the "I don't really wanna touch it" levels of complexity
2019-05-10 15:13:31 <SpaceToast> I'll figure something out eventually :)
2019-05-10 15:15:20 <Cogitri> mps: Thank you :)
2019-05-10 15:17:38 <mort___> SpaceToast: i thought i remembered something - i think if you use the -H option to your local invocation of docker, you can tell it to talk to a remote docker daemon
2019-05-10 15:17:54 <SpaceToast> mort___: yes, that's what I meant by "networked docker" :)
2019-05-10 15:18:10 <SpaceToast> I was asking if doing that has side-effects (e.g data flow)
2019-05-10 15:19:18 <mort___> i think it just means that your local dokcer client will push things to the remote daemon; i presume (eg) host bind mounts don't work using directories on the client (but coudl be wrong)
2019-05-10 15:19:35 <mort___> it's the daemon that's actually doing all the work
2019-05-10 15:20:09 <mort___> so i'd assume it only has access to things local to it
2019-05-10 15:22:18 <mps> Cogitri: np, you are welcome
2019-05-10 16:03:42 <ncopa> the remote docker build thing is something i have been thinking of
2019-05-10 16:04:08 <ncopa> i think it would be nice to run: abuild --remote --arch aarch64 ...
2019-05-10 16:04:10 <ncopa> or similar
2019-05-10 16:04:36 <ncopa> and it would spawn a aarch64 builders remotely
2019-05-10 16:04:53 <ncopa> give realtime build log in current console
2019-05-10 16:04:58 <ncopa> and return build artifacts
2019-05-10 16:06:35 <danieli> doesn't sound too difficult unless you require remote volumes
2019-05-10 16:06:57 <ncopa> i just want the built package returned in some place
2019-05-10 16:07:05 <ncopa> in my local directory
2019-05-10 16:07:31 <ncopa> eg somethign like ~/packages/edge/main/aarch64/
2019-05-10 16:10:00 <SpaceToast> that's kind of the thing, you'd need to let the server (docker -H target) use a local (invocator) directory (for the sources, and returning the artifact)
2019-05-10 16:20:24 <otlabs> north1: how can i tag the maintainer in my PR?
2019-05-10 16:20:50 <north1> otlabs: @maintainerGithubHandle
2019-05-10 16:21:00 <danieli> yeah, just @ the handle
2019-05-10 16:21:11 <otlabs> ok
2019-05-10 16:21:24 <_ikke_>  In a comment obviously
2019-05-10 16:21:27 <otlabs> any standard procedure to find the handle?
2019-05-10 16:21:33 <_ikke_> No
2019-05-10 16:21:41 <otlabs> ok, thanks!
2019-05-10 16:21:47 <_ikke_> Just try @full_name
2019-05-10 16:21:56 <north1> Yes, trial and failure with guesswork
2019-05-10 16:22:02 <_ikke_> If they provided that info in their profile, github will complete it
2019-05-10 16:22:07 <otlabs> _ikke_: cool, thanks
2019-05-10 16:22:11 <_ikke_> I think you need @fabaf
2019-05-10 16:22:14 <_ikke_> or something liek that
2019-05-10 16:22:20 <north1> Can also try their maintainer name
2019-05-10 16:22:23 <Cogitri> Or search for the email adress of the maintainer in GH's searchbar
2019-05-10 16:22:44 <otlabs> great! i will try all your suggestions! thanks!
2019-05-10 16:23:25 <danieli> yes, fabaff
2019-05-10 16:23:34 <danieli> i googled his full name, that's it
2019-05-10 16:23:44 <otlabs> thanks
2019-05-10 16:24:03 <otlabs> anyway i am unable to get it build for now :-(
2019-05-10 16:24:08 <_ikke_> @fabian would already show it afaik
2019-05-10 16:25:13 <otlabs> wow! github is quite smart for this things!
2019-05-10 16:30:05 <ncopa> im trying to rebuild against perl 5.28
2019-05-10 16:30:14 <ncopa> bumped into a nasty issue
2019-05-10 16:30:36 <ncopa> which turned out be caused by same package in both main and community
2019-05-10 16:30:44 <ncopa> perl-module-implementation
2019-05-10 16:32:38 <_ikke_> The one in main is older
2019-05-10 16:33:07 <_ikke_> In both cases, it went from testing to main
2019-05-10 16:33:25 <_ikke_> s/main/their repo/
2019-05-10 16:33:25 <alpine-meetbot> _ikke_ meant to say: In both cases, it went from testing to their repo
2019-05-10 16:34:23 <ncopa> the community hase a few more deps
2019-05-10 16:34:45 <ncopa> $ diff main/perl-module-implementation/APKBUILD  community/perl-module-implementation/APKBUILD | tpaste
2019-05-10 16:34:45 <ncopa> http://tpaste.us/Var0
2019-05-10 16:34:52 <ncopa> but is maintained by fcolista
2019-05-10 16:34:54 <_ikke_> ncopa: one package (in a PR) has a vendored and patched library that is statically built. Should that be split off from the main package?
2019-05-10 16:35:15 <ncopa> vendored?
2019-05-10 16:35:25 <mps> that's why I think we need a language teams, where could be such things coordinated
2019-05-10 16:35:28 <_ikke_> It's included in the source under contrib
2019-05-10 16:35:41 <ncopa> we should probably not redistribute it at all
2019-05-10 16:35:48 <ncopa> do we have a separate package for it?
2019-05-10 16:35:59 <_ikke_> I don't think so
2019-05-10 16:36:31 <_ikke_> irrxml
2019-05-10 16:36:58 <ncopa> i don tthink we should redistribute it at all
2019-05-10 16:37:25 <ncopa> but diffictul to know without looking at it
2019-05-10 16:37:28 <_ikke_> https://github.com/alpinelinux/aports/pull/7762#issue-277636994
2019-05-10 16:37:56 <_ikke_> https://tpaste.us/mZlR
2019-05-10 16:37:59 <_ikke_> That's a note they included
2019-05-10 16:39:15 <ncopa> so
2019-05-10 16:39:24 <ncopa> https://cloud.drone.io/alpinelinux/aports/3099
2019-05-10 16:39:28 <ncopa> filelist at the end
2019-05-10 16:40:02 <_ikke_> you mean: +usr/lib/libIrrXML.a
2019-05-10 16:40:04 <_ikke_> ?
2019-05-10 16:40:54 <_ikke_> There is a conditional statement in CMakeLists.txt to not build the included library
2019-05-10 16:41:04 <_ikke_> if( NOT SYSTEM_IRRXML )
2019-05-10 16:41:26 <ncopa> that would have been preffered
2019-05-10 16:41:27 <ncopa> but
2019-05-10 16:41:54 <ncopa> i notice
2019-05-10 16:41:58 <ncopa> brb phone
2019-05-10 16:42:00 <_ikke_> k
2019-05-10 16:43:57 <ncopa> so, i notice that there are no static lib of assimp
2019-05-10 16:44:25 <ncopa> which means that irrxml code is included in the libassimp or the assimb binary
2019-05-10 16:44:35 <ncopa> so it should be safe to simply delete it
2019-05-10 16:44:51 <_ikke_> Ok, so it's probably not a dependency?
2019-05-10 16:45:13 <ncopa> i dont think it is
2019-05-10 16:45:15 <_ikke_> Ok
2019-05-10 16:45:20 <ncopa> bug hum...
2019-05-10 16:45:29 <ncopa> s/bug/but/
2019-05-10 16:45:29 <alpine-meetbot> ncopa meant to say: but hum...
2019-05-10 16:46:10 <ncopa> if libassimp has un resolved symbols, then the static lib may be needed
2019-05-10 16:46:22 <ncopa> the best thing to do though
2019-05-10 16:46:35 <ncopa> woudl be to build a system irrxml in a separate package
2019-05-10 16:46:45 <ncopa> link to it dynamically
2019-05-10 16:47:18 <_ikke_> ok
2019-05-10 16:48:44 <_ikke_> Then we might need to find out what they patched
2019-05-10 16:48:56 <_ikke_> "fixed an issue regarding wchar_t/unsigned short"
2019-05-10 16:49:17 <ncopa> you can also nm -D the libassimp
2019-05-10 16:49:40 <ncopa> and see if there are any unresolved symbols provided by IrrXML
2019-05-10 16:49:50 <ncopa> i doubt there are any
2019-05-10 16:50:11 <_ikke_> You're referring to: if( NOT SYSTEM_IRRXML )
2019-05-10 16:50:12 <_ikke_> ?
2019-05-10 16:50:56 <ncopa> nm -D pkg/assimp/usr/lib/libassimp.so.0 or what it is
2019-05-10 16:51:06 <_ikke_> ah
2019-05-10 16:51:32 <ncopa> nm -D pkg/assimp/usr/lib/libassimp.so.4
2019-05-10 16:51:50 <ncopa> nm -D pkg/assimp/usr/lib/libassimp.so.4 | grep -i Irr
2019-05-10 16:51:55 <ncopa> nm -D pkg/assimp/usr/lib/libassimp.so.4 | grep -i xml
2019-05-10 16:52:12 <ncopa> anything that seems to come from libIrrXML
2019-05-10 16:52:53 <ncopa> .... T <symbol> means that the symbol is provided
2019-05-10 16:53:03 <ncopa> .... U <symbol> means that the symbol is needed
2019-05-10 16:53:10 <otlabs> tcely: that build drove me nuts. thank you for saving me :-)
2019-05-10 16:53:38 <ncopa> i think you cannot have an needed symbol without directly link to it
2019-05-10 16:53:48 <otlabs> my PR finally got build, thank you all for help
2019-05-10 16:53:56 <_ikke_> ncopa: via a dynamic lib?
2019-05-10 16:53:59 <ncopa> yes
2019-05-10 16:54:41 <ncopa> i think its safe to delete the static lib
2019-05-10 16:55:23 <_ikke_> I don't see anything referring to xml or irr
2019-05-10 16:55:44 <ncopa> good
2019-05-10 16:55:54 <ncopa> and it was sort of expected
2019-05-10 16:57:03 <_ikke_> So rm -vf "$pkgdir"/usr/lib/libIrrXML.a in package() after install?
2019-05-10 16:57:28 <ncopa> yes
2019-05-10 16:58:38 <mort___> ncopa: for builds on other arches, if you're on docker4{mac,windows) then if you give it a container of the relevant arch, it'll use qemu to run appropriately
2019-05-10 16:58:58 <mort___> not as slick as what you want but can help if just hacking about
2019-05-10 16:59:17 <mort___> i'd need to patch the docker-abuild Makefile/Dockerfile to use the apprpriate arch base image
2019-05-10 16:59:32 <ncopa> right
2019-05-10 17:00:07 <ncopa> so, what i actually had in mind was something that could be reused by official builder
2019-05-10 17:00:16 <ncopa> the idea was to distribute the workload
2019-05-10 17:00:27 <ncopa> and have a pool of builders
2019-05-10 17:01:20 <ncopa> and if there are no available nodes, it would just block til one is available
2019-05-10 17:01:27 <ncopa> or something like that
2019-05-10 17:01:43 <danieli> thing is, artifacts and the recipe (apkbuild) would have to be transferred back and forth between whoever queued the job and the actual builder
2019-05-10 17:01:49 <mort___> i think that's exactly what swarm/ucp are targeting
2019-05-10 17:01:57 <danieli> it's not trivial in a setup like alpine's
2019-05-10 17:02:09 <mort___> which means docker-ee rather than the community version
2019-05-10 17:02:10 <mort___> (i think)
2019-05-10 17:02:19 <ncopa> mort___: hm..
2019-05-10 17:02:33 <ncopa> so you cannot set up your swarm with the ce?
2019-05-10 17:02:53 <mort___> hm actually...
2019-05-10 17:02:57 <mort___> ce has swarm i think
2019-05-10 17:02:59 <mort___> but not ucp?
2019-05-10 17:03:06 <danieli> i believe that is correct
2019-05-10 17:03:10 <danieli> swarm but not ucp
2019-05-10 17:03:15 <danieli> heck, you're the one who works at docker ncopa :)
2019-05-10 17:03:30 <ncopa> :)
2019-05-10 17:03:53 <ncopa> so the theoretical idea is
2019-05-10 17:04:00 <ncopa> you push 200 packages to be built
2019-05-10 17:04:09 <ncopa> the build master resolves the build order
2019-05-10 17:04:24 <ncopa> and splits it into chunks, or batches or what you want to call it
2019-05-10 17:04:48 <ncopa> where each batch contains a list of independent packages, not dependencies between them
2019-05-10 17:04:57 <ncopa> so they could be built in parallel on different machines
2019-05-10 17:05:22 <_ikke_> You probably also need to sync intermediate built packages, right?
2019-05-10 17:05:26 <danieli> mort___: familiar with docker's DTR?
2019-05-10 17:05:40 <mort___> danieli: aware of it, i woudn't say familiar particularly
2019-05-10 17:05:53 <ncopa> and then we store the built packages in to a staging repo and index them
2019-05-10 17:06:05 <ncopa> and then we build next batch
2019-05-10 17:06:16 <danieli> it's an EE thing, and it's meant for use in for instance a CI/CD sysetm
2019-05-10 17:06:26 <mort___> yeah - a local version of hub (aiui)
2019-05-10 17:06:38 <ncopa> the nodes needs to have access to the staging repo
2019-05-10 17:06:49 <danieli> it's all built on ucp if i'm not mistaken
2019-05-10 17:07:03 <tcely> otlabs: you're welcome
2019-05-10 17:07:43 <danieli> it's really ironic how alpine is so popular among docker users, yet alpine has no production infra running on docker - it's all lxc
2019-05-10 17:07:58 <ncopa> danieli: it is :)
2019-05-10 17:08:22 <ncopa> however, we did use container tech early
2019-05-10 17:08:35 <ncopa> we used containers before docker existed
2019-05-10 17:08:52 <danieli> i've worked with openvz in the past
2019-05-10 17:08:52 <ncopa> even before it was officially supported in mainline kernel
2019-05-10 17:09:21 <ncopa> we didnt use openvz, but i was aware of it
2019-05-10 17:09:30 <danieli> i've also done work with solaris zones and bsd jails, mostly solaris zones of those two
2019-05-10 17:09:33 <ncopa> it has virtualized network stack
2019-05-10 17:09:41 <ncopa> what we used was vservers
2019-05-10 17:10:15 <danieli> linux-vserver?
2019-05-10 17:10:20 <ncopa> yes
2019-05-10 17:10:30 <danieli> that's a name i haven't heard in some time
2019-05-10 17:11:05 <ncopa> i even maintained a vserver+grsec patch a short period
2019-05-10 17:11:54 <ncopa> hum, this perl business
2019-05-10 17:11:57 <ncopa> we need to do something
2019-05-10 17:11:59 <mps> my first virtualizaton was UML (User Mode Linux)
2019-05-10 17:12:36 <danieli> yeah, shouldn't get carried away
2019-05-10 17:12:42 <ncopa> so we used vserver instead of VM
2019-05-10 17:12:46 <danieli> it's so warm here, oh my god.. afk
2019-05-10 17:12:50 <ncopa> in a time when VM was the hot thing
2019-05-10 17:13:12 <ncopa> but we realized that VMs are overkill
2019-05-10 17:13:54 <ncopa> lots of bloat for the one thing you want run
2019-05-10 17:14:15 <ncopa> multiple memory managers doing the same thing sharing the same memory
2019-05-10 17:14:19 <_ikke_> I think lxc fits our current workflow a bit better then docker
2019-05-10 17:14:25 <_ikke_> Doesn't mean it can't change though
2019-05-10 17:14:31 <ncopa> so cointainers was the way to go
2019-05-10 17:14:49 <ncopa> then lxc made it to mainline kernel, and vserver didnt
2019-05-10 17:15:02 <ncopa> so we replaced vserver with lxc
2019-05-10 17:15:14 <ncopa> and then came docker
2019-05-10 17:15:15 <danieli> containers are pretty darn nice for development and spinning up/down services
2019-05-10 17:15:16 <mps> containers are now better for most things, but VM's are good for testing corner cases
2019-05-10 17:15:39 <ncopa> right, and i think thats the direction we need to go
2019-05-10 17:16:02 <ncopa> i really like the concept of spinning up a disposable env for building your thing
2019-05-10 17:16:07 <ncopa> and then destroy it
2019-05-10 17:16:17 <ncopa> just keep the build artifact
2019-05-10 17:16:37 <_ikke_> yes, that makes sense, you don't need a persistent machine for that
2019-05-10 17:17:04 <ncopa> persistent machines causes problems
2019-05-10 17:17:08 <mps> build from clean base are nice
2019-05-10 17:17:12 <ncopa> like we do now in lxc
2019-05-10 17:17:14 <danieli> i do a lot of development in temporary containers with docker-compose, it's super easy to deploy as well
2019-05-10 17:17:25 <_ikke_> gitlab CI does that really nice
2019-05-10 17:17:32 <danieli> either way, i digress
2019-05-10 17:17:32 <_ikke_> if you use docker builds
2019-05-10 17:17:39 <ncopa> so i think that is the direction we want to go
2019-05-10 17:17:58 <ncopa> i have always felt that docker is a bit heavyweight
2019-05-10 17:18:08 <ncopa> the binary is big
2019-05-10 17:18:21 <_ikke_> It
2019-05-10 17:18:25 <ncopa> but i suppose that does not matter when you build
2019-05-10 17:18:28 <_ikke_> It's a static go binary, right?
2019-05-10 17:18:36 <ncopa> you need gcc and other heavyweight stuff
2019-05-10 17:18:37 <ncopa> yes
2019-05-10 17:18:44 <_ikke_> although, nowadays they split the daemon from the CLI
2019-05-10 17:18:50 <ncopa> its a set of static go binaries
2019-05-10 17:19:41 <ncopa> but i really like what docker does
2019-05-10 17:19:55 <ncopa> and i think it fits perfect for our usecase
2019-05-10 17:20:00 <ncopa> when it comes to building
2019-05-10 17:20:10 <danieli> docker itself is large, but VMs are even larger, and one tradeoff is not having to deal with artifacts and broken systems
2019-05-10 17:20:15 <danieli> otoh lifecycle management often gets neglected
2019-05-10 17:20:34 <ncopa> when you build from scratch you will re-install same build-base every time, gcc make etc
2019-05-10 17:20:43 <ncopa> so it makes sense to cache that
2019-05-10 17:20:57 <ncopa> and that is what docker does
2019-05-10 17:20:59 <_ikke_> You can make an image with that
2019-05-10 17:21:01 <_ikke_> indeed
2019-05-10 17:21:36 <ncopa> and it makes it more efficient than if we had a local apk cache
2019-05-10 17:21:46 <ncopa> even if apk is fast
2019-05-10 17:21:48 <_ikke_> Do we have some registry for our own images?
2019-05-10 17:22:05 <danieli> alpine? for internal use, no
2019-05-10 17:22:16 <danieli> not that i've seen at least
2019-05-10 17:22:20 <ncopa> we can use hub.docker.com imho
2019-05-10 17:22:21 <_ikke_> I do recall clandmeter mentioning something
2019-05-10 17:22:38 <_ikke_> The standard account only allows you to upload a single images
2019-05-10 17:22:39 <danieli> ncopa: it goes down once in a while, and self hosting is preferable
2019-05-10 17:22:47 <danieli> that might be, i don't remember
2019-05-10 17:23:06 <ncopa> i need to continue on the perl stuff
2019-05-10 17:23:13 <ncopa> my problem at hand is
2019-05-10 17:23:21 <ncopa> that it seems to be more than one duplicate
2019-05-10 17:23:23 <tcely> it's pretty easy to setup a local registry that passes hub.docker.com images through when they aren't local
2019-05-10 17:23:23 <danieli> re: what you said earlier about queuing builds, it won't be possible to build it on top of docker without docker EE
2019-05-10 17:23:39 <danieli> more than one duplicate - what do you mean, the same package 3+ times?
2019-05-10 17:23:44 <ncopa> yes
2019-05-10 17:23:49 <ncopa> no
2019-05-10 17:23:49 <_ikke_> tcely: at $work we use artifactory which does that nicely, but it's heavy and commercial
2019-05-10 17:23:59 <ncopa> more that one package that exists in multiple repos
2019-05-10 17:24:07 <ncopa> eg both in main and community and maybe even testing
2019-05-10 17:24:16 <danieli> right, yeah
2019-05-10 17:24:17 <_ikke_> What do you need docker EE for?
2019-05-10 17:24:22 <danieli> perl-module-implementation is in main and community, not testing
2019-05-10 17:24:33 <danieli> _ikke_: UCP
2019-05-10 17:24:41 <_ikke_> does not ring a bell
2019-05-10 17:25:27 <danieli> universal control plane - cluster stuff, can be used for job queuing and management
2019-05-10 17:25:56 <_ikke_> Right, but you can also arrange that outside of docker, right?
2019-05-10 17:26:14 <danieli> well yes, but you'll most likely end up having to develop and maintain more custom code
2019-05-10 17:26:29 <danieli> being able to use COTS is nice, at least to some extent
2019-05-10 17:26:53 <_ikke_> gitlab might work
2019-05-10 17:26:58 <danieli> for?
2019-05-10 17:27:10 <_ikke_> queing / scheduling build jobs
2019-05-10 17:27:39 <_ikke_> But I don't think you can have a dynamic set of jobs based on what is inside the PR
2019-05-10 17:27:43 <danieli> right, built into their ci/cd stuff
2019-05-10 17:27:47 <_ikke_> yes
2019-05-10 17:28:04 <_ikke_> Most build systems are pretty static
2019-05-10 17:28:22 <danieli> mm, i don't think it'd be impossible to extend it to do that, but we'd have to brainstorm more about the specific constraints our use case imposes, and what COTS could be used for such a CI+CD system
2019-05-10 17:28:26 <danieli> yup
2019-05-10 17:34:27 <otlabs> i am building a python package and it has a huge list of dependencies, some of them might be used during test phase only. how good is dependency tracing in abuild? does it just copy dependencies from *depends? or does it perform some analysis?
2019-05-10 17:35:06 <_ikke_> if you add them to make or checkdepends, it will only use them during build phase
2019-05-10 17:35:07 <ncopa> for python i think abuild doesnothing to trace deps
2019-05-10 17:35:21 <_ikke_> It only traces sodeps
2019-05-10 17:35:31 <ncopa> perl-module-runtime is duplicated too
2019-05-10 17:35:55 <otlabs> thank you
2019-05-10 17:36:12 <otlabs> i will need to check manually what i can through away
2019-05-10 17:40:23 <ncopa> i think we need to check for duplicates in git commit hook
2019-05-10 17:44:19 <danieli> so abuild doesn't trace python deps at all?
2019-05-10 17:44:23 <tcely> _ikke_: I think a first start would be setting up minio and using http://plugins.drone.io/drone-plugins/drone-s3/
2019-05-10 17:44:29 <ncopa> danieli: correct
2019-05-10 17:47:07 <danieli> man, there are multiple ways python projects can be packaged, bleh
2019-05-10 17:47:44 <north1> most use setup.py (setuptools/distutils) from my experience
2019-05-10 17:47:56 <_ikke_> my experience as well
2019-05-10 17:48:01 <danieli> actually
2019-05-10 17:48:21 <danieli> PEP376 defines that there should be a .dist-info directory, and deps for packages are stored in a text file there
2019-05-10 17:48:43 <_ikke_> But is that commonly implemented?
2019-05-10 17:48:46 <danieli> yes
2019-05-10 17:48:51 <_ikke_> a requirements.txt is more common ime
2019-05-10 17:49:03 <danieli> this is what python looks at when pip installs stuff
2019-05-10 17:49:51 <north1> there are just too many ways to spcify deps, requirements.txt, on setup.py or setup.cfg
2019-05-10 17:50:38 <north1> iirc Void Linux's xbps-src (aports equivalent) had a project to trace python module like so: are traced but it never went anywhere
2019-05-10 17:50:47 <danieli> mm, it's painful
2019-05-10 17:52:02 <danieli> wonder if pipdeptree could be useful
2019-05-10 17:52:14 <danieli> i need to dig into the source to see what it does and if it's reproducible outside python
2019-05-10 17:52:34 <north1> Doesn't setup.py packages install info about them into site-packages?
2019-05-10 17:53:05 <danieli> they need a specific format of metadata and all to land in pypi
2019-05-10 17:57:59 <north1> i think all python modules have /usr/lib/pythonVer/site-packages/python-module.egg-info/requires.txt
2019-05-10 17:58:07 <north1> can't dependencies be traced from that ?
2019-05-10 17:58:17 <danieli> that's what i was talking about earlier
2019-05-10 17:58:38 <danieli> i'm just confirming whether that is the case for absolutely all distributed py modules or not, i cannot remember off the top of my head
2019-05-10 18:00:23 <north1> well they are for enough that i think it justifies tracing pydeps
2019-05-10 18:00:57 <danieli> consistency is key, it won't be fun if it chokes on every other package
2019-05-10 18:13:22 <danieli> hm, i'm gonna write a demo if i can wrap my head around the abuild source, i haven't had much of a look at it and idr how it's structured
2019-05-10 18:19:28 <_ikke_> bratkartoffel: ping
2019-05-10 18:24:15 <ncopa> north1: seems like mosquitto tests broke on may arches
2019-05-10 18:46:02 <otlabs> do we have pytest-timeout, https://bitbucket.org/pytest-dev/pytest-timeout/src/default/ , as part of Alpine Linux?
2019-05-10 18:48:21 <_ikke_> https://pkgs.alpinelinux.org/packages?name=*pystest-timeout*&branch=edge
2019-05-10 18:48:39 <north1> ncopa: I ran it a few times and yes, sometimes it works sometimes not, can we disable them with a comment on the tests' flakyness ?
2019-05-10 18:48:50 <otlabs> _ikke_: nope, thank you!
2019-05-10 18:49:13 <north1> ncopa: More specifically: http://ix.io/1IDe
2019-05-10 18:49:41 <otlabs> sometimes packages get different names or already form part of python3
2019-05-10 18:49:58 <_ikke_> otlabs: that's why I use wildcards
2019-05-10 18:50:41 <otlabs> they do not always help, for example pytz -> py-tz
2019-05-10 18:50:57 <_ikke_> sure
2019-05-10 18:51:02 <_ikke_> py*tz* :P
2019-05-10 18:51:17 <otlabs> and unittest2 is a replica for python2 of python3's unittest
2019-05-10 18:51:27 <otlabs> ha-ha-ha!
2019-05-10 19:08:12 <otlabs> time to go, see you later!
2019-05-10 19:48:29 <north1> can i get ci-malfunction on pr7734 ?
2019-05-10 19:48:43 <north1> Tests fail on travis CI, problably due to host configuration, doesn't happen in Drone CI
2019-05-10 19:49:32 <_ikke_> Will check in a sec
2019-05-10 20:36:05 <ncopa> north1: yes i think we can disable flaky tests
2019-05-10 20:36:19 <north1> ncopa: thank you
2019-05-10 20:36:31 <north1> py3-websockets armv7 also has flaky tests under drone CI
2019-05-10 20:41:27 <mps> north1: when you are talking about disabling tests, did you considered disabling test which fails in zstd on armhf
2019-05-10 20:42:08 <north1> mps: i can take a look at it
2019-05-10 20:42:33 <mps> it pass on armv7, but I think on armhf it is timeout problem
2019-05-10 20:42:45 <mps> but not sure, to be clear
2019-05-10 20:45:01 <north1> http://ix.io/1IEb
2019-05-10 20:45:38 <mps> uhm, core dump
2019-05-10 20:46:09 <north1> getting miscompiled on  armhf is my guess
2019-05-10 20:46:11 <mps> I didn't have it in few rebuild tries
2019-05-10 20:46:16 <north1> $ZSTD -f tmp
2019-05-10 20:46:18 <north1> is the test
2019-05-10 20:46:38 <mps> I mean 'abuild -r'
2019-05-10 20:46:44 <north1> maybe drone CI is miscompiling it ?
2019-05-10 20:46:56 <mps> could be
2019-05-10 20:47:37 <mps> I posted yesterday error message for failed test, if you remember
2019-05-10 20:53:52 <ncopa> sweet! perl 5.28 rebuilds for main and community is done
2019-05-10 20:54:04 <ncopa> only problem is postgresql and plperl
2019-05-10 20:54:08 <ncopa> testsuite fails for it
2019-05-10 20:54:33 <_ikke_> ncopa: nice
2019-05-10 20:54:45 <mps> perl-dbd-pg?
2019-05-10 20:55:06 <ncopa> no
2019-05-10 20:55:08 <mps> or just plperl for postgres
2019-05-10 20:55:18 <ncopa> just plperl for postgres
2019-05-10 20:55:29 <ncopa> i did find a regression in perl
2019-05-10 20:55:34 <danieli> sweeeeet
2019-05-10 20:55:38 <ncopa> so I upgraded to 5.28.2
2019-05-10 20:55:39 <danieli> god helg!
2019-05-10 20:55:46 <ncopa> lige mΓ₯te
2019-05-10 20:55:58 <danieli> ./hat tip
2019-05-10 20:56:06 <ncopa> but plperl still failed
2019-05-10 20:56:10 <danieli> what happens with postgres?
2019-05-10 20:56:19 <ncopa> test suite fails
2019-05-10 20:56:26 <ncopa> apparently when loading plperl module
2019-05-10 20:56:29 <danieli> is the apkbuild in aports master?
2019-05-10 20:56:38 <ncopa> no
2019-05-10 20:56:45 <ncopa> there is a PR with perl
2019-05-10 20:56:53 <ncopa> https://github.com/alpinelinux/aports/pull/5751
2019-05-10 20:57:03 <ncopa> then upgrade perl to 5.28.2
2019-05-10 20:57:10 <ncopa> and then there is a PR for postgresql
2019-05-10 20:57:22 <ncopa> which updates it to 11.3 iirc
2019-05-10 20:57:51 <danieli> 11.2 is the newest one afaik
2019-05-10 20:57:55 <danieli> i think it was released the other day
2019-05-10 20:58:05 <danieli> nevermind, it was 11.3
2019-05-10 20:58:35 <mps> I think few days ago 11.3 is released with some bug fixes
2019-05-10 20:58:55 <mps> and older releases also
2019-05-10 20:58:58 <ncopa> it is 11.3 i tried
2019-05-10 20:59:12 <ncopa> i may disable the pl tests
2019-05-10 20:59:23 <ncopa> just to get the rest of the builds done
2019-05-10 20:59:34 <mps> hmm, is that safe
2019-05-10 20:59:41 <ncopa> nope
2019-05-10 20:59:50 <andypost[m]> PG is security release and needs backport
2019-05-10 20:59:56 <danieli> so that patch -> plperl -> postgres?
2019-05-10 21:00:07 <mps> I mean for critical infrastructure package as postgresql is
2019-05-10 21:00:48 <ncopa> danieli: i found one reported issue, and an updated perl version which included the fix
2019-05-10 21:00:51 <ncopa> but it still fails
2019-05-10 21:01:13 <ncopa> second option is that i push it broken and let the builder fail and hope someone else fixes it
2019-05-10 21:01:27 <danieli> hm, I'm not so sure leaving it broken is better than leaving it vulnerable
2019-05-10 21:01:48 <ncopa> third option is that i dont push perl til i come back in 2 weeks
2019-05-10 21:02:08 <danieli> oh f, yeah, you're leaving for a bit
2019-05-10 21:02:10 <ncopa> backporting postgresql should be trivial
2019-05-10 21:02:21 <danieli> should be, yeah, but i'm not so sure if perl is going to be a pain
2019-05-10 21:02:34 <danieli> or.. do we just build 11.3 against the pre-existing perl in that branch?
2019-05-10 21:04:08 <ncopa> thats ok too
2019-05-10 21:04:14 <ncopa> but then i need to rebase my perl work
2019-05-10 21:04:16 <ncopa> which is ok
2019-05-10 21:04:20 <_ikke_> mosquitto is still broken atm
2019-05-10 21:04:31 <danieli> _ikke_: in aports master?
2019-05-10 21:04:33 <ncopa> and same problem will re-appear when perl update arrives
2019-05-10 21:04:47 <_ikke_> danieli: yes
2019-05-10 21:04:56 <ncopa> tests was enabled
2019-05-10 21:05:05 <_ikke_> https://build.alpinelinux.org/buildlogs/build-3-10-x86/main/mosquitto/mosquitto-1.6.2-r1.log
2019-05-10 21:05:42 <ncopa> is it only 32bit that is broken?
2019-05-10 21:05:47 <_ikke_> 2https://build.alpinelinux.org/buildlogs/build-edge-x86/main/mosquitto/mosquitto-1.6.2-r1.log
2019-05-10 21:05:54 <_ikke_> looks like it, yes
2019-05-10 21:05:55 <ncopa> i think atleast some arch passed
2019-05-10 21:06:02 <_ikke_> indeed
2019-05-10 21:06:11 <_ikke_> only x86 it looks like
2019-05-10 21:06:33 <danieli> that's strange. mqtt v5 stuff breaking only on x86?
2019-05-10 21:06:41 <_ikke_> I saw armhf in #alpine-commits as well
2019-05-10 21:07:08 <_ikke_> and ppc64le
2019-05-10 21:07:21 <danieli> yup, they both passed
2019-05-10 21:07:46 <_ikke_> only x86 left
2019-05-10 21:08:03 <_ikke_> they did fail earlier
2019-05-10 21:08:21 <_ikke_> "build-edge-ppc64le: failed to build mosquitto"
2019-05-10 21:09:48 <danieli> they both look successful replacing x86 with armhf and ppc64le in the buildlog url
2019-05-10 21:10:25 <ncopa> so the tests are flaky as north1 said
2019-05-10 21:10:42 <ncopa> ok. i must get some sleep now
2019-05-10 21:10:44 <_ikke_> Yes, so it just retried until it succeeded once
2019-05-10 21:10:49 <_ikke_> ncopa: Good idea
2019-05-10 21:10:51 <_ikke_> sleep tight
2019-05-10 21:11:11 <danieli> looks like the mqtt v5 tests are flaky in that case
2019-05-10 21:11:15 <danieli> good night
2019-05-10 21:17:48 <tcely> ncopa: https://github.com/alpinelinux/abuild/pull/82 is ready as far as I can see
2019-05-10 22:51:34 <danieli> hm
2019-05-10 22:51:52 <danieli> for some reason, this happens with postgres: server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request.
2019-05-10 22:52:55 <danieli> indeed `create extension if not exists "plperl"` that fails
2019-05-11 07:10:31 <ncopa> morning. im ready to merge perl, but i wont be able to deal with breakages
2019-05-11 07:11:25 <ncopa> there are 2 known breakages: postgresql and openresty
2019-05-11 07:13:48 <ncopa> ok, im merging perl
2019-05-11 07:20:06 <ncopa> tcely: im sorry that i dont have time for the abuild-fetch pr :-(
2019-05-11 07:22:36 <ncopa> tcely: testing/openresty is likely broken after perl 5.28 upgrade
2019-05-11 07:22:46 <ncopa> it needs to be rebuilt against perl 5.28
2019-05-11 07:23:23 <ncopa> so
2019-05-11 07:23:31 <ncopa> I'm gonna be unavailable for a couple of weeks
2019-05-11 07:23:55 <ncopa> meanwhile, it would be good if we could focus on main and community repos
2019-05-11 07:24:11 <ncopa> and wait with testing repo til after 3.10 release
2019-05-11 07:25:05 <ncopa> would be great if existing bugs are fixed rather than new introduced while i'm away
2019-05-11 07:25:22 <ncopa> the 3.10 builders needs to bootstrap go and ghc
2019-05-11 07:25:28 <ncopa> that is manual work
2019-05-11 07:27:04 <Cogitri> Morning
2019-05-11 07:27:08 <ncopa> someone with access to the builder needs to: 1) wait til builder is idle and stop mqtt-exec.aports-build service 2) add edge repo and install go (or ghc) 3) remove edge repo 4) build go (or ghc) 5) uninstall the edge version of go (or ghc) 6) reboot the builder (or start mqtt-exec.aports-build service)
2019-05-11 07:27:10 <ncopa> morning
2019-05-11 07:33:09 <clandmeter> maybe write it on infra wiki?
2019-05-11 07:41:20 <bratkartoffel> _ikke_ pong?
2019-05-11 08:27:18 <clandmeter> ncopa: regarding ca-certificates
2019-05-11 08:27:56 <clandmeter>  /etc/ssl/cert.pem was provided by libressl before
2019-05-11 08:29:30 <clandmeter> and we used it in some cases like bb wget and i guess also apk-tools
2019-05-11 08:31:57 <clandmeter> the openssl migration removed certs.pem so we added it back in ca-certificates to generate it from upstream source (mozilla).
2019-05-11 08:37:14 <clandmeter> so in principle when you install ca-certificates you have 2 sources of certificates 1. static cert.pem and 2. trigger generated ca-certificates.crt which can contain user certs as well.
2019-05-11 12:28:58 <_ikke_> bratkartoffel: wanted to ask you about a specific PR, trying to find which one again
2019-05-11 12:29:08 <_ikke_> Ah, yeah
2019-05-11 12:29:12 <_ikke_> openjdk10
2019-05-11 12:34:58 <bratkartoffel> yes, how can i help you?
2019-05-11 12:36:57 <_ikke_> So there are currently 2 PRs openened for openjdk10
2019-05-11 12:37:53 <_ikke_> You advise to use #6500 instead of #6468. Is that mainly because if some additional patches?
2019-05-11 12:38:21 <_ikke_> pr6500 pr6468
2019-05-11 12:38:27 <danieli> i was just about to say that :P
2019-05-11 12:39:38 <bratkartoffel> I would prefer my PR as it's based on the patches from openjdk9. Also I think that these patches are more stable / for more archs as they are built upon the portola project
2019-05-11 12:39:51 <_ikke_> ok
2019-05-11 12:40:06 <bratkartoffel> I could successfully take the patches  (with only minor changes) up to latest openjdk12
2019-05-11 12:40:14 <_ikke_> and hjaekel says openjdk10 should be removed as soon as openjdk11 is built, do you agree?
2019-05-11 12:40:29 <bratkartoffel> I'm unsure about that
2019-05-11 12:40:48 <_ikke_> He says that openjdk10 is no longer supported
2019-05-11 12:40:49 <bratkartoffel> on one hand, these versions are no longer supported by oracle
2019-05-11 12:41:06 <bratkartoffel> on the otehr hand we need them for bootstraping the newer jdk's
2019-05-11 12:41:32 <_ikke_> can openjdk11 also be bootstrapped by itself?
2019-05-11 12:41:52 <bratkartoffel> I haven't tried so far
2019-05-11 12:42:22 <bratkartoffel> i think this might work, if you have a fully compiled and running verison available
2019-05-11 12:42:48 <danieli> freshports has a bootstrap-openjdk11 package, required to build openjdk11 and openjdk12
2019-05-11 12:42:52 <danieli> so i think it can bootstrap itself
2019-05-11 12:42:54 <_ikke_> A lot of these projects (ghc, go, gcc) are bootstrapped by using an alreayd existing package
2019-05-11 12:43:10 <danieli> mm, the java path was gcj
2019-05-11 12:43:32 <danieli> s/was/was via/
2019-05-11 12:43:32 <alpine-meetbot> danieli meant to say: mm, the java path was via gcj
2019-05-11 12:47:09 <bratkartoffel> ok, thanks for clarification. i can confirm that openjdk11 can bootstrap itself
2019-05-11 12:47:24 <bratkartoffel> so, yes, I think we can remove openjdk 9 and 10 once 11 is available
2019-05-11 12:47:43 <bratkartoffel> or should we keep it until it fails to build?
2019-05-11 12:48:13 <_ikke_> What about security issues?
2019-05-11 12:48:47 <danieli> once 11 and 12 are bootstrapped with 11, i'd say we can drop 10 from 3.10?
2019-05-11 12:49:14 <_ikke_> If 10 is only necessary to bootstrap 11, we could even remove it before 3.10 is tagged
2019-05-11 12:50:07 <danieli> from freshports: "Dependency lines: bootstrap-openjdk11>0:java/bootstrap-openjdk11"
2019-05-11 12:50:49 <danieli> but yeah, good point
2019-05-11 12:51:09 <bratkartoffel> _ikke_ yes, removing them before tagging should be possible
2019-05-11 12:51:38 <_ikke_> But openjdk11 should produce a openjdk11-bootstrap package that it then makedepends on
2019-05-11 12:51:42 <_ikke_> instead of depending on openjdk10
2019-05-11 12:51:55 <_ikke_> (It cannot depend on itself directly)
2019-05-11 12:53:03 <_ikke_> danieli: Could you also let your eyes go over 6500 to see if it looks good to you?
2019-05-11 12:53:12 <danieli> yes, sir
2019-05-11 12:55:13 <bratkartoffel> i think we have only one problem left
2019-05-11 12:55:22 <bratkartoffel> currently the packages only build on 64bit archs
2019-05-11 12:55:37 <bratkartoffel> how can we bootstrap the whole stuff for, lets say x86, later?
2019-05-11 12:55:57 <bratkartoffel> re-add openjdk 9 and 10 just for the new arches?
2019-05-11 12:55:57 <_ikke_> Good question
2019-05-11 12:56:42 <_ikke_> How can we bootstrap openjdk9?
2019-05-11 12:56:53 <bratkartoffel> with openjdk8
2019-05-11 12:57:08 <bratkartoffel> which is based on icedtea and available on arches currently
2019-05-11 12:57:17 <danieli> the first step in the bootstrap path for java used to be gcj, which now has been removed
2019-05-11 12:57:23 <danieli> using icedtea should be fine if it's available
2019-05-11 12:58:07 <_ikke_> bratkartoffel: we could move the package to unmaintained to keep it around for a while (and after that, it will still be available in git)
2019-05-11 12:58:29 <_ikke_> So if we want to bootstrap new arches, we would probably need to go through the whole bootstrap chain
2019-05-11 12:58:35 <danieli> yeah, i'd prefer moving it to unmaintained rather than having to dig it out of the git history if we'd need it again
2019-05-11 12:59:02 <_ikke_> Yes, but packages will be removed once in a while from unmaintained
2019-05-11 12:59:07 <danieli> +1
2019-05-11 12:59:09 <bratkartoffel> i agree to that. maybe also adding a comment on top of the apkbuild to _not_ remove it soon
2019-05-11 13:00:32 <bratkartoffel> but, for bootstraping, we could also cross-compile the bootstrap package
2019-05-11 13:00:49 <_ikke_> shelcheck complains about the 'CFLAGS= CXXFLAGS= LDFLAGS=' statements while being referenced later as arguments
2019-05-11 13:00:53 <danieli> hm, openjdk10 isn't building me because libelf-dev isn't available
2019-05-11 13:01:05 <_ikke_> https://github.com/koalaman/shellcheck/wiki/SC2097
2019-05-11 13:01:06 <bratkartoffel> this might work and we don't need to keep it in unmaintained
2019-05-11 13:01:22 <danieli> elfutils-dev exists but not libelf-dev
2019-05-11 13:02:42 <_ikke_> did it used to exist?
2019-05-11 13:02:43 <bratkartoffel> danieli strange, it works on my machine. I just rebased the PR that a new drone and travis build starts
2019-05-11 13:02:54 <danieli> i can see that, but on my edge builder, it isn't working - x86_64
2019-05-11 13:03:01 <bratkartoffel> ok, drone fails too
2019-05-11 13:03:21 <bratkartoffel> oh my...
2019-05-11 13:03:33 <danieli> one of the CI builds failed because it didn't output text for a while
2019-05-11 13:04:06 <bratkartoffel> libelf-dev existed in 3.9
2019-05-11 13:04:15 <danieli> let's check the log then
2019-05-11 13:04:37 <danieli> main/libelf: purge. replaced by elfutils
2019-05-11 13:05:52 <bratkartoffel> ok, i'll update the dependencies
2019-05-11 13:05:53 <bratkartoffel> thanks
2019-05-11 13:05:56 <danieli> :)
2019-05-11 13:06:30 <_ikke_> bratkartoffel: shellcheck output: https://gist.github.com/Ikke/3d3998ea7b46a03931c039564ff60f17
2019-05-11 13:06:31 <mps> anyone with access to main would look at sudo upgrade https://patchwork.alpinelinux.org/patch/4846/
2019-05-11 13:06:52 <mps> it have some bug fixes
2019-05-11 13:07:22 <mps> and I think it should be upgraded for 3.10 release
2019-05-11 13:07:58 <bratkartoffel> _ikke_ I'll add my comments on the gist
2019-05-11 13:08:33 <_ikke_> note it's something that I started checking privately, I don't agree with everything shellcheck comments on and I already disabled some checks
2019-05-11 13:09:46 <danieli> "A good programmer knows the rules but a great programmer knows when to break them."
2019-05-11 13:10:45 <bratkartoffel> _ikke_ i've reasons for every warning it prints out. anything special you want to know?
2019-05-11 13:11:30 <bratkartoffel> except for the "local _java_bin" variable, i might change this and add quotes
2019-05-11 13:12:13 <_ikke_> but the one I linked to does point to a real potential issue
2019-05-11 13:13:09 <_ikke_> FOO= command -arg=$FOO
2019-05-11 13:13:42 <_ikke_> You set FOO empty in the environment for commmand, but -arg=$FOO still uses the original value it might have had
2019-05-11 13:13:51 <bratkartoffel> yes, thats intended
2019-05-11 13:13:56 <_ikke_> Ok
2019-05-11 13:14:28 <bratkartoffel> the build system prints a warning if it finds the CFLAGS, LDFLAGS etc. variables in the environment
2019-05-11 13:14:29 <_ikke_> As long as that's the intention I guess it's ok, though it might warant a comment
2019-05-11 13:14:40 <bratkartoffel> sure, i can add a comment there
2019-05-11 13:15:25 <bratkartoffel> there is already a comment
2019-05-11 13:15:33 <bratkartoffel> see lines 96 - 101
2019-05-11 13:15:43 <_ikke_> Yes, I noticed
2019-05-11 13:17:14 <_ikke_> And ldpath which apparently is unused?
2019-05-11 13:17:24 <danieli> openjdk10 built successfully on x86_64 with elfutils-dev rather than libelf-dev
2019-05-11 13:17:29 <_ikke_> danieli: +1
2019-05-11 13:17:40 <danieli> all tests passed
2019-05-11 13:17:57 <_ikke_> sonameprefix is appears also to be unused
2019-05-11 13:18:07 <bratkartoffel> i'm unsure about that
2019-05-11 13:18:13 <bratkartoffel> _ikke_ i think it's used
2019-05-11 13:18:32 <bratkartoffel> but i can check, sure
2019-05-11 13:18:34 <_ikke_> in abuild.in?
2019-05-11 13:18:49 <danieli> it is in use in abuild.in
2019-05-11 13:18:51 <_ikke_> Rihttps://git.alpinelinux.org/abuild/tree/abuild.in#n1319
2019-05-11 13:18:53 <danieli> i just grepped
2019-05-11 13:18:53 <_ikke_> Right
2019-05-11 13:19:07 <_ikke_> ok, I'll add it to my shim, which declares variables that abuild uses
2019-05-11 13:19:27 <_ikke_> same with sonameprefix I see?
2019-05-11 13:19:41 <bratkartoffel> yes
2019-05-11 13:19:52 <danieli> grep -rn sonameprefix yields 5 results
2019-05-11 13:19:57 <danieli> all in abuild.in
2019-05-11 13:20:23 <bratkartoffel> the .so files are all the same name in openjdk
2019-05-11 13:20:36 <bratkartoffel> so libjvm.so would be provided by openjdk8, 9, 10...
2019-05-11 13:21:03 <bratkartoffel> i just took this line from openjdk7 and 8
2019-05-11 13:22:35 <_ikke_> Ok, except for _java_bin, I fixed / silenced all shellcheck issues
2019-05-11 13:27:29 <bratkartoffel> changed the _java_bin assignment
2019-05-11 13:28:37 <_ikke_> ok
2019-05-11 13:28:46 <eu> can a package in main checkdep on a package in community?
2019-05-11 13:29:08 <_ikke_> no
2019-05-11 13:29:29 <_ikke_> When abuild is building something in main, only the main repo is available
2019-05-11 13:32:04 <danieli> main can only depend on itself, community can depend on itself and main
2019-05-11 13:32:10 <danieli> testing can depend on all three but it's only in edge
2019-05-11 13:35:53 <_ikke_> bratkartoffel: did you push those changes already?
2019-05-11 13:37:23 <bratkartoffel> yes, just pushed it
2019-05-11 13:37:45 <_ikke_> Ah, thanks.
2019-05-11 13:38:03 <_ikke_> I refreshed the page, but the force pushes didn't show up then
2019-05-11 13:40:39 <bratkartoffel> the build will take some time now
2019-05-11 13:40:50 <_ikke_> Yes, no worry
2019-05-11 13:41:12 <bratkartoffel> should i open the pr for openjdk11?
2019-05-11 13:41:38 <_ikke_> I guess hold until this one is merge
2019-05-11 13:41:40 <_ikke_> merged
2019-05-11 13:44:23 <bratkartoffel> great. I'm really looking forward in using a recent java version in alpine
2019-05-11 13:44:42 <bratkartoffel> i'm afk for about 2 hours, i'll open the PR when i'm back home
2019-05-11 13:45:18 <_ikke_> nod
2019-05-11 13:46:04 <andypost[m]> that's strange, pgsql fails only on armv7 in drone https://cloud.drone.io/alpinelinux/aports/3284
2019-05-11 13:46:18 <danieli> neat, they provide prebuilt binaries for recent java (for alpine/musl) @ java.net
2019-05-11 13:46:30 <danieli> andypost[m]: it failed for me on x86_64 last night, i suspect a flaky test or something
2019-05-11 13:46:50 <danieli> it's plperl
2019-05-11 13:47:01 <danieli> 00:51:52 <danieli> for some reason, this happens with postgres: server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request.
2019-05-11 13:47:01 <danieli> 00:52:55 <danieli> indeed `create extension if not exists "plperl"` that fails
2019-05-11 13:47:33 <andypost[m]> danieli: yep, I just can't reproduce locally - as I see it stucks 3.10 builders
2019-05-11 13:47:53 <Cogitri> I think ncoopa disabled tests on that?
2019-05-11 13:47:57 <danieli> what was the PR for that again? I'll retest
2019-05-11 13:48:11 <Cogitri> https://github.com/alpinelinux/aports/commit/a367acffc935e559db1885434723a0318965d557
2019-05-11 13:48:15 <danieli> i see
2019-05-11 13:48:24 <danieli> he was debating whether to leave it at 11.2 or leave it broken
2019-05-11 13:48:35 <_ikke_> But I think ncopa prefers those tests to be enabled again as soon as possible
2019-05-11 13:48:46 <andypost[m]> cogitri: as you see armv7 fails anyway in edge
2019-05-11 13:48:49 <danieli> so would I, I don't like tests being disabled
2019-05-11 13:49:14 <_ikke_> I concur
2019-05-11 13:49:55 <danieli> ouch
2019-05-11 13:50:05 <danieli> the armv7 issue is different from the issue ncopa disabled tests for
2019-05-11 13:50:39 <danieli> actually no, it seems to fail at checks relating to plperl
2019-05-11 13:51:00 <danieli> did armv7 not get the memo that pl tests are disabled?
2019-05-11 13:52:35 <danieli> oop, yeah, this is the same issue - it seems to drop into recovery mode once it loads jsonb_plperl
2019-05-11 13:52:43 <andypost[m]> I did rebase and gonna wait another run of drone
2019-05-11 13:53:02 <danieli> wonder if it's an upstream issue and they just haven't tested with really recent perl
2019-05-11 13:53:53 <andypost[m]> I used to search but found no mentions about it
2019-05-11 13:55:56 <danieli> arch's is still 11.2
2019-05-11 13:56:00 <danieli> let's check tumbleweed
2019-05-11 13:56:56 <danieli> 11.2 there too
2019-05-11 13:58:23 <danieli> i see similar issues from last year, i'm gonna do some testing on it now
2019-05-11 14:13:29 <danieli> aha
2019-05-11 14:14:53 <danieli> it's because of ldap_* symbols not found
2019-05-11 14:15:19 <danieli> Error loading shared library libldap_r-2.4.so.2: No such file or directory (needed by /home/daniel/aports/main/postgresql/src/postgresql-11.3/tmp_install/usr/lib/libpq.so.5)
2019-05-11 14:16:48 <danieli> let's see if it chokes with 'libldap' added to makedepends
2019-05-11 14:23:51 <andypost[m]> it points to wrong library, because it has no *_r* in name https://pkgs.alpinelinux.org/contents?file=libldap*&path=&name=&branch=edge
2019-05-11 14:24:03 <danieli> yeah, that's what it looks like
2019-05-11 14:24:34 <danieli> i'm doing some testing at the moment
2019-05-11 14:28:37 <danieli> come to think of it andypost[m]: https://pkgs.alpinelinux.org/contents?file=*.so*&path=&name=libldap&branch=edge&repo=main&arch=x86_64
2019-05-11 14:30:31 <andypost[m]> Hm, sounds like a bug
2019-05-11 14:30:41 <danieli> it's somehow looking in the wrong path
2019-05-11 14:30:56 <danieli> i'm gonna monkey patch just to see if i can make it work
2019-05-11 14:47:45 <_ikke_> You should not remove any linux users in *install scripts, right? Cannot find a reference where that is mentioned, but I do recall that
2019-05-11 14:51:18 <danieli> andypost[m]: might have been something screwy in my build env, i set it up over again a few days ago.. argh.
2019-05-11 14:55:42 <ncopa> im gonna disble plperl in postgresql
2019-05-11 15:00:16 <danieli> Util.c: loadable library and perl binaries are mismatched (got handshake key 0xce00080, needed 0xde00080)
2019-05-11 15:00:18 <danieli> @ ncopa
2019-05-11 15:00:47 <_ikke_> Anyone know why I suddenly get closed PRs when I add -is:draft to the search query in github?
2019-05-11 15:01:18 <danieli> probably because you're not filtering by is:open too?
2019-05-11 15:01:40 <_ikke_> I do
2019-05-11 15:01:40 <ncopa> danieli: interesting
2019-05-11 15:01:46 <danieli> ncopa: agreed
2019-05-11 15:01:52 <ncopa> sounds like something else needs to be rebuilt
2019-05-11 15:02:04 <danieli> _ikke_: actually, i'm seeing closed ones too.. odd.
2019-05-11 15:02:04 <ncopa> or that they have hardcoded a perl version somewhere
2019-05-11 15:02:16 <_ikke_> danieli: And now I do it again and they are not there :-/
2019-05-11 15:02:27 <_ikke_> Oh, still there
2019-05-11 15:02:53 <danieli> i need to focus on the postgres thing before my mind 'caches it out'
2019-05-11 15:02:59 <_ikke_> sure
2019-05-11 15:12:27 <ncopa> danieli: i suspect its problem in perl itself
2019-05-11 15:12:49 <ncopa> that error message seems to come from ./ext/Hash-Util/Util.xs in perl
2019-05-11 15:13:25 <ncopa> it sounds like something pulled in old version of perl
2019-05-11 15:13:49 <ncopa> but its weird because there are not many perl module deps at all
2019-05-11 15:13:51 <ncopa> if any
2019-05-11 15:14:30 <andypost[m]> Then why ldap lib has this strange soname ncopa?
2019-05-11 15:14:45 <danieli> andypost[m]: that was my build env being broken
2019-05-11 15:15:05 <ncopa> andypost[m]: huh? no clue
2019-05-11 15:15:21 <andypost[m]> https://pkgs.alpinelinux.org/contents?file=*.so*&path=&name=libldap&branch=edge&repo=main&arch=x86_64
2019-05-11 15:15:43 <andypost[m]> There's 2 with _r
2019-05-11 15:16:10 <ncopa> andypost[m]: a wild guess is that they build two libraries, one threadsafe and one that is not
2019-05-11 15:16:58 <danieli> indeed, it's an oooold thing
2019-05-11 15:17:22 <ncopa> we probably only need the threadsafe variant nowdays
2019-05-11 15:17:31 <ncopa> you can check if there is a compile flag for it
2019-05-11 15:18:00 <ncopa> i'm installing go on the 3.10 builders
2019-05-11 15:18:03 <danieli> the reason my build broke on libldap earlier was because my build env removed deps after the failed build, it wasn't meant to do that, but i hadn't configured it not to
2019-05-11 15:18:26 <danieli> and yeah, there are flags for it, i saw it in configure.in
2019-05-11 15:19:05 <ncopa> see what fedora and others do there
2019-05-11 15:19:14 <ncopa> we had something similar with boost
2019-05-11 15:19:41 <ncopa> we simply dropped the non-threadsafe and went for a single threadsafe
2019-05-11 15:24:09 <mps> postgresql 11.3 passes with perl-5.26.3, now will try upgrade perl
2019-05-11 15:24:12 <ncopa> ok, i have installed go on all builders
2019-05-11 15:24:23 <danieli> what do they need go for?
2019-05-11 15:24:43 <ncopa> mps: yes postgresql 11.2 failed with perl-5.28 so that was expected
2019-05-11 15:24:52 <ncopa> danieli: to bootstrap go
2019-05-11 15:24:55 <danieli> mps: i'm building it with perl 5.28.1-r0 from the edge repos
2019-05-11 15:24:57 <danieli> ncopa: aha, neat :)
2019-05-11 15:25:14 <ncopa> so i installed go binary from edge repos
2019-05-11 15:25:41 <ncopa> then its only ghc that needs bootstrap
2019-05-11 15:25:46 <ncopa> but it looks complicated
2019-05-11 15:26:34 <danieli> it's haskell, what'd you expect :P
2019-05-11 15:26:43 <mps> danieli: yes, I've seen, but wanted first to check if it works on previous perl
2019-05-11 15:26:43 <danieli> it feels and looks beautiful, but it's pretty darn complex
2019-05-11 15:26:44 <ncopa> seems like it needs libffi also
2019-05-11 15:27:34 <ncopa> ok, if it blocks the 3.10 builder, then you can disable ghc while im gone
2019-05-11 15:29:46 <_ikke_> ncopa: I will keep an eye on it
2019-05-11 15:30:20 <ncopa> danieli: re the perl module version mismatch, can you figure out which perl module it tries to load?
2019-05-11 15:30:25 <danieli> hm, perl-test-taint is breaking on bulid-3-10-{armv7,ppc64le}
2019-05-11 15:30:35 <danieli> ncopa: i'm about to dig into it, it's not a super easy environment to navigate
2019-05-11 15:30:55 <ncopa> yeah, im impressed that you managed to get that error message fished out
2019-05-11 15:31:03 <ncopa> never figured out how to get the server log out from there
2019-05-11 15:31:04 <danieli> i had to coerce it a bit and then cat a log file
2019-05-11 15:31:15 <_ikke_> ncopa: do you do some kind of double bootstrap, where you first use an older / foreign package to bootstrap the package, then use the just built package to build itself again?
2019-05-11 15:31:35 <danieli> postmaster.log specifically, i made it a little more verbose but it still isn't enough
2019-05-11 15:31:57 <danieli> see: src/pl/plpgsql/src/log/postmaster.log
2019-05-11 15:32:01 <ncopa> _ikke_: normally not. i use the edge go to build the go package in 3.10
2019-05-11 15:32:03 <ncopa> and thats it
2019-05-11 15:32:09 <_ikke_> ok
2019-05-11 15:32:39 <_ikke_> I suppose in this case it won't make a lot of difference anyway
2019-05-11 15:33:11 <ncopa> danieli: i wonder if postgreslqul build at some point downloads cpan module
2019-05-11 15:33:20 <ncopa> and uses that during build
2019-05-11 15:33:22 <danieli> ncopa: it didn't look like it
2019-05-11 15:33:25 <danieli> but i'll double check
2019-05-11 15:34:06 <danieli> it does not, i grepped the entire tarball
2019-05-11 15:35:17 <ncopa> the only perl related packages i can see is perl perl-utils and perl-dev
2019-05-11 15:35:58 <danieli> me too, perhaps there are some perl modules bundled with it
2019-05-11 15:36:31 <danieli> might be through XS (perl ffi)
2019-05-11 15:36:59 <ncopa> ./src/pl/plperl/Util.xs
2019-05-11 15:37:04 <ncopa> is the only
2019-05-11 15:37:29 <ncopa> you know what
2019-05-11 15:37:30 <danieli> yeah, i've seen that, but that's the actual glue layer between perl and C
2019-05-11 15:37:42 <danieli> i just need to dig a little more and force it to give me more output
2019-05-11 15:37:50 <danieli> strace -f isn't much help here
2019-05-11 15:37:58 <ncopa> i wonder if it tries to load Util from plperl
2019-05-11 15:38:07 <ncopa> but end up pull in Util from perl 5.28
2019-05-11 15:38:36 <danieli> the build phase generates Util.c/.so/.o so i doubt it
2019-05-11 15:38:52 <danieli> same with SPI.xs -> XPI.so/.o/.c
2019-05-11 15:39:05 <ncopa> perl 5.28 has a Util.xs -> Util.c too
2019-05-11 15:40:33 <ncopa> usr/lib/perl5/core_perl/auto/List/Util/Util.so
2019-05-11 15:40:33 <ncopa> usr/lib/perl5/core_perl/auto/Hash/Util/Util.so
2019-05-11 15:48:27 <mps> looked at debian, they build 11.3 with perl 5.28
2019-05-11 15:48:43 <danieli> there, debug log
2019-05-11 15:48:43 <danieli> finally
2019-05-11 15:48:52 <danieli> god, that was annoying
2019-05-11 15:52:57 <ncopa> i am not able to reproduce perl test taint on ppc64le either
2019-05-11 15:53:59 <mps> PG failed here: http://tpaste.us/zBXJ
2019-05-11 15:54:17 <danieli> didn't disable the test properly?
2019-05-11 15:54:26 <mps> build log is scrolled up, can't
2019-05-11 15:54:28 <danieli> oh right, it's not building plperl and then tries to package it?
2019-05-11 15:55:18 <mps> I enabled it, omg subpackage, didn't looked configure params, meh
2019-05-11 15:57:23 <_ikke_> bratkartoffel: note that the openjdp11 PR already exists: https://github.com/alpinelinux/aports/pull/6469
2019-05-11 16:05:11 <eu> main/bash-completion need new checkdepends which are in community. I'd prefer to just move bash-completion to community in stead of filling up main. Good idea?
2019-05-11 16:07:09 <_ikke_> eu: I would say yes
2019-05-11 16:07:23 <_ikke_> I don't see a reason why bash-completion needs to be in main
2019-05-11 16:08:38 <eu> _ikke_: yup, I brought it to main when there were no community :)
2019-05-11 16:08:45 <_ikke_> Understood
2019-05-11 16:08:55 <_ikke_> There are still a lot of packages in main that could be moved to community in time
2019-05-11 16:09:35 <eu> Yeah, I'm going over what I used to maintain and for several I'll probably open PRs to move them to community
2019-05-11 16:15:20 <bratkartoffel> _ikke_ yes, the 11 PR is open, but its the same reasons for not taking the other openjdk10 pr
2019-05-11 16:15:39 <bratkartoffel> pr6500 builds fine as far as i can see. can you please merge it?
2019-05-11 16:15:59 <_ikke_> bratkartoffel: understood, but it's maybe better to collaborate with hjaekel to improve that one
2019-05-11 16:16:09 <_ikke_> bratkartoffel: yes, I was looking at it now
2019-05-11 16:16:58 <bratkartoffel> the patches are pretty huge. sure, i can take a look at his, but it may take some time
2019-05-11 16:18:57 <_ikke_> bratkartoffel: pushed
2019-05-11 16:25:48 <ncopa> does oracle not support 32bit openjdk?
2019-05-11 16:26:21 <bratkartoffel> oracle supports it
2019-05-11 16:26:36 <bratkartoffel> and i can crosscompile the whole chan (9,10,11,12)
2019-05-11 16:26:40 <bratkartoffel> only native compilation fails
2019-05-11 16:26:58 <bratkartoffel> thanks _ikke_, i'll open the 11 PR now
2019-05-11 16:31:38 <ncopa> ok, im gonna power off the desktop now
2019-05-11 16:32:22 <ncopa> see you again in 2 weeks
2019-05-11 16:32:48 <bratkartoffel> holidays? have a good time!
2019-05-11 16:32:57 <danieli> have a good one :)
2019-05-11 16:42:25 <_ikke_> ncopa: o/
2019-05-11 16:42:29 <_ikke_> ncopa: enjoy and have a safe trip
2019-05-11 16:47:00 <_ikke_> 
ACTION is waiting for edge builders to complete

2019-05-11 16:50:12 <danieli> hmm.. the 3.10 s390x builder has been working on erlang for an abnormally long time
2019-05-11 16:51:23 <_ikke_> buildlog is not available
2019-05-11 16:51:37 <danieli> probably isn't transferred before the build is done
2019-05-11 16:51:47 <_ikke_> Yup
2019-05-11 16:51:55 <danieli> i mean, it's a large piece of software, but it doesn't take this long on a powerful builder machine
2019-05-11 16:52:06 <danieli> on, say, the x86_64 one, it's reasonably quick
2019-05-11 16:52:12 <_ikke_> tmhoang: can you check if the s390x builder is hanging?
2019-05-11 16:52:36 <tmhoang> _ikke_ : 3-10 or edge ?
2019-05-11 16:52:41 <danieli> 3-10 first
2019-05-11 16:52:47 <danieli> that's the one i saw working on erlang some time ago
2019-05-11 16:52:57 <danieli> idr if edge was working on erlang then
2019-05-11 16:53:04 <_ikke_> also
2019-05-11 16:53:06 <danieli> it might just be slow but it shouldn't be this slow on a powerful box
2019-05-11 16:53:06 <_ikke_> both
2019-05-11 16:53:10 <danieli> all right
2019-05-11 16:55:39 <tmhoang> seems hanging on erlang
2019-05-11 16:56:19 <tmhoang> idk what can I do really, even though I have shell access here
2019-05-11 16:56:25 <tmhoang> we need our guy
2019-05-11 16:56:56 <_ikke_> Do you see some process hanging?
2019-05-11 16:57:00 <tmhoang> yes
2019-05-11 16:57:10 <danieli> got any output from the build?
2019-05-11 16:57:15 <tmhoang> make opt TERTIARY_BOOTSTRAP=true
2019-05-11 16:57:28 <tmhoang> erlc -sbtu -A0 -- -root /home/buildozer/aports/community/erlang/src/otp-OTP-21.2.6/bootstrap -progname erl -- -home /home/buildozer
2019-05-11 16:57:38 <_ikke_> /var/cache/distfiles/buildlogs/ should contain the buildlogs
2019-05-11 16:57:54 <danieli> interesting
2019-05-11 16:59:20 <danieli> what it does is essentially this: build the emulator -> optionally build optimized emulator -> use bootstrap erl + erlc to build the libraries
2019-05-11 17:00:07 <tmhoang> nothing useful
2019-05-11 17:01:01 <danieli> correct :(
2019-05-11 17:01:13 <tmhoang> I was trying to build erlang the other day but reuquires openjdk8 or something
2019-05-11 17:01:15 <tmhoang> let me see
2019-05-11 17:01:23 <danieli> ah, jinterface
2019-05-11 17:01:27 <_ikke_> I guess you can just kill the process
2019-05-11 17:01:37 <_ikke_> If it's just hanging
2019-05-11 17:02:02 <danieli> erlang was bumped yesterday to rebuild against perl apparently
2019-05-11 17:02:25 <danieli> i didn't even realize erlang depended on perl..?
2019-05-11 17:02:28 <tmhoang> _ikke_ : is it okay to do so ?
2019-05-11 17:02:39 <tmhoang> I really dont want to touch anything on the builder
2019-05-11 17:02:50 <danieli> perl seems to be a makedep
2019-05-11 17:02:55 <_ikke_> tmhoang: I have done so previously on request
2019-05-11 17:02:57 <danieli> that does make sense
2019-05-11 17:03:12 <_ikke_> tmhoang: it just fails the build
2019-05-11 17:04:54 <tmhoang> _ikke_: I murdered it
2019-05-11 17:05:14 <tmhoang> here goes my sin
2019-05-11 17:05:16 <_ikke_> ok, it seems to continue now
2019-05-11 17:05:17 <_ikke_> heh
2019-05-11 17:05:43 <_ikke_> edge-x86_64 is now building erlang as well
2019-05-11 17:06:17 <_ikke_> 'build-3-10-s390x: failed to build erlang', which is expected
2019-05-11 17:34:43 <andypost[m]> is it fine that default -dev package does not depend on -static?
2019-05-11 17:35:56 <andypost[m]> maxice8, thank for pointer)
2019-05-11 17:36:12 <north1> andypost: yes
2019-05-11 17:36:17 <north1> the point of having -static is to separate it from -dev
2019-05-11 17:36:27 <mps> building PG 11.3 test I found this "panic: locale.c: 893: Unexpected character in locale name '2E."
2019-05-11 17:36:40 <north1> -static might want to depend on -dev though
2019-05-11 17:36:58 <mps> in 'src/pl/plperl/log/postmaster.log'
2019-05-11 17:37:01 <andypost[m]> hm, why?
2019-05-11 17:37:20 <_ikke_> Don't you need -static only if you want to do create static binary
2019-05-11 17:37:29 <north1> ncopa wants to avoid having the possibility of accidentally linking the static library instead of the shared library
2019-05-11 17:38:57 <andypost[m]> mps, 2e is dot(.) char surely there's no such localr
2019-05-11 17:40:18 <mps> andypost[m]: I don't have experience with this, just noted it and server dies after this. maybe this could help someone to debug issue
2019-05-11 17:41:17 <mps> here is full log, if it could be of the help http://tpaste.us/Xnll
2019-05-11 17:45:10 <andypost[m]> mps, it returns me to perl https://perl5.git.perl.org/perl.git/blob/HEAD:/locale.c#l893
2019-05-11 17:46:36 <mps> maybe locale isn't correctly formated in tests
2019-05-11 17:55:33 <danieli> mps: i saw that now too
2019-05-11 17:55:54 <danieli> the test can be ran and forced to --skip-locale or --no-locale, idr
2019-05-11 17:56:58 <mps> aha, ok, will try when come back to home
2019-05-11 18:10:06 <danieli> wtf is it complaining about locales for now
2019-05-11 18:10:07 <danieli> aaargh
2019-05-11 18:11:42 <danieli> ... what
2019-05-11 18:11:59 <danieli> it just passed all the plperl tests when i mae it use --no-locale ("use C locale")
2019-05-11 18:16:31 <mps> danieli: yes, it looks like it works with this
2019-05-11 18:16:53 <danieli> I'm making a patch to use that flag for the regression tests. I'll clean my env and test it.
2019-05-11 18:22:07 <mps> in PG INSTALL file they say it can fail on some system, here is excerpt http://tpaste.us/Lz1V
2019-05-11 18:22:26 <danieli> it failed with some perl error earlier
2019-05-11 18:22:27 <danieli> what the shit
2019-05-11 18:22:37 <danieli> i'm testing my patch after cleaning my env
2019-05-11 18:23:57 <mps> will try with export LANG=C.utf8 to see if it works
2019-05-11 18:30:07 <danieli> ... it worked
2019-05-11 18:30:08 <danieli> i fixed pg
2019-05-11 18:30:28 <mps> also I do ;)
2019-05-11 18:30:38 <danieli> how'd you do it? env?
2019-05-11 18:30:57 <mps> how did you done, export or --no-locale
2019-05-11 18:31:06 <danieli> patched one of the makefiles
2019-05-11 18:31:19 <mps> heh, we ask each other same question
2019-05-11 18:31:59 <danieli> i'm just curious if you did it with env, i already mentioned what i did
2019-05-11 18:32:01 <mps> uhm, actually i didn't succeeded
2019-05-11 18:32:18 <danieli> all right, I'll make an am'able patch for mine, and you can test it for me
2019-05-11 18:32:23 <_ikke_> wireshark failed on s390x
2019-05-11 18:32:25 <danieli> or I'll just PR it
2019-05-11 18:32:28 <mps> it didn't worked with export LANG=C.utf8 in build()
2019-05-11 18:32:31 <_ikke_> It seems tests are failing
2019-05-11 18:32:41 <danieli> i'm highly familiar with wireshark but not s390x
2019-05-11 18:32:55 <mps> will try in _run_tests
2019-05-11 18:36:02 <otlabs> hi ppl
2019-05-11 18:38:15 <otlabs> I use docker-dauild t build a first package, package builds fine, but I get following message about untrusted signature: >>> libzim: Updating the testing/x86_64 repository index... ERROR: APKINDEX.tar.gz: UNTRUSTED signature
2019-05-11 18:38:31 <danieli> which mirror and architecture?
2019-05-11 18:38:41 <mps> danieli: setting 'export LANG=C.utf8' in APKBUILD didn't worked for me
2019-05-11 18:38:53 <danieli> mps: not a surprise, postgres' build system is pretty complicated
2019-05-11 18:39:16 <mps> true, actually tests are complicated
2019-05-11 18:39:23 <danieli> i also had LANG=C.UTF-8 and CHARSET=UTF-8 set
2019-05-11 18:39:46 <danieli> yup, but i'm rerunning the thing to make sure i cleaned my mess without breaking it, and to check that my patch still holds
2019-05-11 18:40:06 <mps> good work
2019-05-11 18:40:17 <mps> please continue ;)
2019-05-11 18:40:45 <danieli> i wonder why in the flying heck it complained about perl
2019-05-11 18:41:05 <danieli> it complained about ldap because abuild removed deps it wasn't supposed to remove (i changed it a bit)
2019-05-11 18:41:19 <mps> I have to upgrade client's DB server with postgresql in a hour, what a coincidence
2019-05-11 18:41:32 <danieli> going to use 11.2? :P
2019-05-11 18:42:36 <mps> maybe look at diff between these two release, if you have time ofc
2019-05-11 18:43:23 <danieli> https://nvd.nist.gov/vuln/detail/CVE-2019-9193
2019-05-11 18:43:28 <danieli> it's apparently disputed
2019-05-11 18:44:39 <danieli> changelog for 11.3 https://www.postgresql.org/docs/11/release-11-3.html
2019-05-11 18:45:14 <mps> oh, you are so fast
2019-05-11 18:45:28 <danieli> i already knew about the cve and that 11.3 is only a few days old
2019-05-11 18:45:29 <_ikke_> danieli: I think I agree with that
2019-05-11 18:45:50 <_ikke_> Akin like: root users and users in the sudoers group can run arbitrary code on a server
2019-05-11 18:45:55 <mps> although I read release info few days ago
2019-05-11 18:45:57 <danieli> agreed, it was kinda stupid
2019-05-11 18:46:20 <mps> or just one day, can't remember
2019-05-11 18:47:41 <_ikke_> Would be nice that you can see what's in the builders backlog
2019-05-11 18:48:02 <danieli> how is it queued?
2019-05-11 18:48:13 <danieli> i mean, where are the mqtt messages dispatched from / queued up?
2019-05-11 18:48:37 <danieli> wait - all builders store the queue locally after receiving messages about git pushes over mqtt, right?
2019-05-11 18:49:38 <_ikke_> yes, it's just a script that calculated what needs to be rebuilt and loops on that
2019-05-11 18:49:51 <_ikke_> s/rebuilt/(re)built/
2019-05-11 18:49:51 <alpine-meetbot> _ikke_ meant to say: yes, it's just a script that calculated what needs to be (re)built and loops on that
2019-05-11 18:50:32 <_ikke_> https://git.alpinelinux.org/aports/tree/main/aports-build/aports-build
2019-05-11 18:50:43 <_ikke_> Very sophisticated ;-)
2019-05-11 18:50:57 <danieli> here's the patch https://tpaste.us/ZgM9
2019-05-11 18:50:59 <danieli> mind testing it?
2019-05-11 18:51:04 <_ikke_> ugh
2019-05-11 18:51:08 <_ikke_> I still cannot load tpaste :(
2019-05-11 18:51:12 <danieli> darn it
2019-05-11 18:51:21 <danieli> _ikke_: https://hastebin.com/raw/atojakiceg
2019-05-11 18:51:26 <danieli> what about that? it's on heroku iirc
2019-05-11 18:51:32 <_ikke_> yes, it works
2019-05-11 18:51:41 <_ikke_> it's just the HSTS + invalid cert that's preventing it
2019-05-11 18:52:03 <_ikke_> danieli: Test it locally you mean?
2019-05-11 18:52:21 <danieli> yes, and am it if it succeeds
2019-05-11 18:52:29 <_ikke_> I cannot push to main
2019-05-11 18:53:29 <_ikke_> patch does not apply apparently
2019-05-11 18:53:34 <_ikke_> maybe I need to update
2019-05-11 18:53:40 <_ikke_> nope
2019-05-11 18:54:02 <danieli> odd, it should
2019-05-11 18:54:19 <_ikke_> Not sure what's happening
2019-05-11 18:54:35 <danieli> wget it in your ~/aports or whereever, patch -p1 < thefile
2019-05-11 18:54:37 <danieli> doesn't work?
2019-05-11 18:54:42 <_ikke_> error: patch failed: main/postgresql/APKBUILD:3
2019-05-11 18:54:58 <danieli> wot, has something been pushed since the last time i pulled..?
2019-05-11 18:55:16 <danieli> let's see
2019-05-11 18:55:17 <_ikke_> β”‚eecf096 2019-05-11 14:54 +0000 Natanael Copa       βˆ™ main/postgresql: disable plperl to unblock the builders
2019-05-11 18:55:23 <_ikke_> this afternoon
2019-05-11 18:56:06 <danieli> pretty sure I pulled after that, but I'll see if it works here
2019-05-11 18:56:28 <_ikke_> strange thing is git status does not show a conflict
2019-05-11 18:57:06 <_ikke_> it shows git am is in progress, but no conflicted files
2019-05-11 18:57:10 <danieli> hm. I'll make a new patch, might have been working on an older commit
2019-05-11 18:57:14 <_ikke_> I'll try with am -3
2019-05-11 18:57:31 <_ikke_> That worked
2019-05-11 18:58:32 <_ikke_> I think the pkgrel was conflicting
2019-05-11 18:58:38 <_ikke_> your patch does not increase it now
2019-05-11 18:59:07 <danieli> I changed it to 1, but I must've been working on an older commit
2019-05-11 18:59:15 <_ikke_> yes, ncopa changed it to 1 as well
2019-05-11 18:59:25 <danieli> aha, yes, then i was on an older commit
2019-05-11 18:59:28 <danieli> i fiks
2019-05-11 18:59:56 <_ikke_> https://git.alpinelinux.org/aports/diff/?id=eecf096
2019-05-11 19:00:13 <danieli> aah, I see
2019-05-11 19:01:03 <_ikke_> It's interesting with the amount of commits that aports sees, a 7 character abbreviated hash is still unique
2019-05-11 19:01:30 <danieli> inb4 we hit a sha1 collision and everything breaks
2019-05-11 19:02:54 <danieli> so all he did was --without-perl and disabling them in subpackages
2019-05-11 19:03:23 <SpaceToast> pretty sure there's a transition path to sha256 already
2019-05-11 19:03:26 <SpaceToast> https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt ?
2019-05-11 19:03:46 <_ikke_> Anyone got an idea about this licence? https://github.com/cloudflare/cloudflared/blob/master/LICENSE
2019-05-11 19:03:48 <danieli> ha, SHAttered
2019-05-11 19:03:50 <_ikke_> Someone wants to package this
2019-05-11 19:04:16 <_ikke_> relevant issue: https://github.com/cloudflare/cloudflared/issues/53
2019-05-11 19:06:10 <danieli> I'm only seeing it in use by CF, trying to find common parts with existing licenses to match
2019-05-11 19:06:43 <danieli> pretty sure it's something proprietary
2019-05-11 19:06:49 <danieli> i see similarities to licenses used by intel, red hat, and google
2019-05-11 19:07:16 <danieli> probably a generic-ish proprietary license
2019-05-11 19:07:16 <SpaceToast> it's definitely not free or even close to OSI-compatible
2019-05-11 19:07:27 <SpaceToast> the question is mainly on whether or not it's ok to redistribute binaries
2019-05-11 19:07:27 <otlabs> is it possible to use heretic syntaxes in `/bin/sh`? e.g. `abuild-keygen -I -a <<< filename`?
2019-05-11 19:07:30 <_ikke_> https://repology.org/project/cloudflared/versions
2019-05-11 19:07:31 <SpaceToast> from what I can see
2019-05-11 19:07:44 <_ikke_> otlabs: what do you mean with heretic
2019-05-11 19:07:52 <otlabs> s/heretic/heredoc/
2019-05-11 19:07:52 <alpine-meetbot> otlabs meant to say: is it possible to use heredoc syntaxes in `/bin/sh`? e.g. `abuild-keygen -I -a <<< filename`?
2019-05-11 19:08:07 <north1> otlabs: it is not posix so most likely no
2019-05-11 19:08:26 <north1> _ikke_: heretic syntax from the church of BASH
2019-05-11 19:08:36 <danieli> i'd put this in non-free if anything
2019-05-11 19:08:41 <otlabs> oh, o. so `echo ...` will make th ejob
2019-05-11 19:08:46 <danieli> it's proprietary software
2019-05-11 19:09:17 <SpaceToast> otlabs: <<< is a herestring, and is not ok
2019-05-11 19:09:25 <SpaceToast> <<WORD [...] WORD is a heredoc, and is ok
2019-05-11 19:09:50 <otlabs> super! thanks! will try
2019-05-11 19:10:13 <danieli> _ikke_: but yeah, i'd say it's proprietary - and doesn't say anything about distributing/sharing/copying it
2019-05-11 19:10:14 <SpaceToast> heredoc docs: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04
2019-05-11 19:10:14 <_ikke_> anyone knows the etymology of heredoc / herestring?
2019-05-11 19:10:27 <otlabs> SpaceToast: <<- will work too?
2019-05-11 19:10:34 <_ikke_> SpaceToast: danieli Makes sense, thanks
2019-05-11 19:10:55 <otlabs> _ikke_: heredoc = here documentation
2019-05-11 19:11:05 <SpaceToast> otlabs: if you look at the docs I posted... you might notice '<<-' as explicitly mentioned ;)
2019-05-11 19:11:32 <otlabs> _ikke_: https://en.wikipedia.org/wiki/Here_document
2019-05-11 19:11:33 <alpine-meetbot> [WIKIPEDIA] Here document | "In computing, a here document (here-document, here-text, heredoc, hereis, here-string or here-script) is a file literal or input stream literal: it is a section of a source code file that is treated as if it were a separate file. The term is also used for a form of multiline string literals that use..."
2019-05-11 19:12:00 <otlabs> SpaceToast: sorry, missed your message, now I got it ;-)
2019-05-11 19:14:56 <danieli> _ikke_: i fixed it and double checked it
2019-05-11 19:14:56 <danieli> https://hastebin.com/raw/opehesajas
2019-05-11 19:15:23 <danieli> man, i really need to clean up this build box
2019-05-11 19:19:03 <danieli> telegram-desktop on ppc64le says the tarball isn't found @ dev.a.o
2019-05-11 19:19:13 <danieli> yup, it's not there
2019-05-11 19:19:28 <_ikke_> Oh, it relies on a snapshot on dev?
2019-05-11 19:19:30 <danieli> and scapy 2.4.2 on build-3-10-x86_64 says the checksum is invalid
2019-05-11 19:19:31 <danieli> yes
2019-05-11 19:19:37 <_ikke_> :(
2019-05-11 19:20:12 <_ikke_> I mostly looked at the patch, not the complete apkbuild
2019-05-11 19:20:55 <_ikke_> It's just available here: https://github.com/telegramdesktop/tdesktop
2019-05-11 19:20:55 <danieli> i suspect the wireshark test issue is related to endianness, it's a little endian test that fails
2019-05-11 19:21:21 <danieli> yup: https://github.com/telegramdesktop/tdesktop/archive/v1.6.7.tar.gz
2019-05-11 19:21:31 <danieli> 1.7.0 is the latest release
2019-05-11 19:21:45 <_ikke_> Yes, indeed
2019-05-11 19:22:00 <_ikke_> dev snapshots should only used as last resort
2019-05-11 19:22:05 <danieli> agreed
2019-05-11 19:22:23 <danieli> i wonder if the telegram upgrade will be as trivial as pkgver += 1, but it doesn't matter
2019-05-11 19:22:27 <danieli> let's just make 1.6.7 work
2019-05-11 19:22:42 <_ikke_> The snapshot function is not trivial
2019-05-11 19:23:17 <danieli> I'm gonna try disabling the wireshark test on s390x
2019-05-11 19:23:20 <_ikke_> https://github.com/telegramdesktop/tdesktop/tree/dev/Telegram/ThirdParty
2019-05-11 19:23:52 <danieli> i believe the github releases pulls in the submodules?
2019-05-11 19:23:59 <_ikke_> afaik, it doesn't
2019-05-11 19:24:06 <_ikke_> it's just git archive over http
2019-05-11 19:25:32 <danieli> cool, you're right
2019-05-11 19:25:46 <danieli> well, that sucks ***
2019-05-11 19:26:48 <_ikke_> sigh
2019-05-11 19:28:19 <_ikke_> https://github.com/alpinelinux/aports/pull/7212/files
2019-05-11 19:28:42 <danieli> oh god
2019-05-11 19:28:47 <danieli> i guess that's the norm
2019-05-11 19:29:30 <_ikke_> So I guess we have to go that route any way
2019-05-11 19:29:47 <danieli> sounds about right, i believe i've seen that exact thing before
2019-05-11 19:29:50 <danieli> llvm5 on build-3-10-ppc64le fails because of one test: "LLVM :: Bindings/Go/go.test"
2019-05-11 19:30:55 <danieli> this is the error part of the output for llvm5 (pasting it since it's ridiculously long): https://hastebin.com/raw/inopetepud
2019-05-11 19:32:28 <ncopa> LLVM problem on ppc64le is because I installed go
2019-05-11 19:32:51 <ncopa> So we need uninstall go again on ppc64le
2019-05-11 19:33:12 <ncopa> And reinstall it after llvm is built
2019-05-11 19:33:38 <_ikke_> ncopa: you are supposed to go on holliday :P
2019-05-11 19:33:59 <danieli> ^^^ go enjoy your holiday already
2019-05-11 19:34:01 <danieli> workaholic
2019-05-11 19:34:36 <danieli> says I, working on this stuff at 9.30 pm on a Saturday evening
2019-05-11 19:34:39 <_ikke_> ncopa: but thanks for answering anyway
2019-05-11 19:34:59 <_ikke_> For me it's not work though :P
2019-05-11 19:35:24 <danieli> i kinda do it for fun
2019-05-11 19:35:58 <_ikke_> "fatal: Unable to read current working directory: No such file or directory"
2019-05-11 19:36:00 <_ikke_> so anoying
2019-05-11 19:36:05 <_ikke_> every time I switch branches
2019-05-11 19:36:09 <danieli> did you delete it?
2019-05-11 19:36:20 <danieli> right, your cwd was in it?
2019-05-11 19:36:21 <_ikke_> I switched branches where that dir is not present
2019-05-11 19:36:23 <_ikke_> yes
2019-05-11 19:36:24 <danieli> rip
2019-05-11 19:36:32 <_ikke_> It's not an actual issue, just anoying
2019-05-11 19:36:38 <danieli> yeah, can't use relative paths there at all
2019-05-11 19:37:18 <_ikke_> I test a new package, switch to master, want to merge a branch, and then get this message
2019-05-11 19:37:18 <_ikke_> fixed by cd ..
2019-05-11 19:37:29 <_ikke_> common pattern: git ff -; (error); cd ..; git ff -
2019-05-11 19:40:32 <_ikke_> north1: so we probably still need your telegram-desktop changes
2019-05-11 19:40:59 <ncopa> I think rdutra can log in to ppc64le. I cannot
2019-05-11 19:41:17 <danieli> i cannot either :)
2019-05-11 19:52:01 <north1> _ikke_: Well I deleted the branch, am out getting food and will see it in 30 mins or so
2019-05-11 19:52:36 <_ikke_> north1: I can still get it
2019-05-11 19:52:40 <_ikke_> Just fixing the conflicts atm
2019-05-11 19:54:26 <north1> Good
2019-05-11 20:09:19 <_ikke_> building it atm to test it
2019-05-11 20:09:38 <danieli> i'm gonna look at getting some security tools into alpine
2019-05-11 20:10:02 <danieli> and then the tools and utilities i use on a daily basis
2019-05-11 20:17:18 <_ikke_> north1: happen to be around to verify the commit?
2019-05-11 20:18:12 <north1> _ikke_: yes
2019-05-11 20:18:14 <north1> verify as in LGTM or verify as in build it ?
2019-05-11 20:18:55 <_ikke_> I've tested it built
2019-05-11 20:19:25 <_ikke_> http://tpaste.us/dklx
2019-05-11 20:19:48 <_ikke_> so mostly if it makes sense what I made out of it
2019-05-11 20:22:34 <north1> _ikke_:  Error code: SSL_ERROR_BAD_CERT_DOMAIN
2019-05-11 20:22:45 <_ikke_> I have the same :P
2019-05-11 20:22:52 <_ikke_> Need to fix the configuration for ipv6
2019-05-11 20:23:45 <north1> :P use ix.io ?
2019-05-11 20:24:03 <north1> http://ix.io/1m2w
2019-05-11 20:25:41 <_ikke_> http://ix.io/1IKx
2019-05-11 20:28:28 <danieli> i removed my key from nld3 when i left the team so i can't help even if i want to :')
2019-05-11 20:29:54 <north1> _ikke_: LGTM , if you want i can build and test it
2019-05-11 20:30:28 <danieli> I'll build it rn, second opinion
2019-05-11 20:31:55 <north1> One positive of that massive patchset is that it is from Void Linux so cross compilation should be easy to work
2019-05-11 20:32:05 <danieli> i saw, it was quite massive
2019-05-11 20:32:19 <danieli> i almost forgot - i'm gonna make an alpine vm, rice it up, and post it on /r/unixporn
2019-05-11 20:32:30 <danieli> that'll be one of my week(end?) projects
2019-05-11 20:33:25 <north1> danieli: Rate my Alpine Rice https://i.imgur.com/0nbBVxM.png
2019-05-11 20:33:54 <danieli> the font in the middle down there looks off, the characters look like the baseline is at a different level
2019-05-11 20:33:59 <danieli> there's also a margin between the bar and the bottom
2019-05-11 20:34:11 <danieli> except that, i'd say 8/10, it's clean
2019-05-11 20:34:14 <danieli> how does it look dirty/
2019-05-11 20:34:18 <danieli> also, uh, #alpine-offtopic?
2019-05-11 20:35:22 <north1> sure
2019-05-11 20:35:58 <_ikke_> danieli: are you building it?
2019-05-11 20:36:02 <danieli> _ikke_: yes
2019-05-11 20:36:07 <danieli> 44%
2019-05-11 20:36:17 <_ikke_> ok, waiting for your confirmation then
2019-05-11 20:36:19 <danieli> i guess you saw nld5 being busy? :P
2019-05-11 20:36:23 <_ikke_> No
2019-05-11 20:36:34 <_ikke_> Was just waiting
2019-05-11 20:37:49 <north1> it is 50% here
2019-05-11 20:37:56 <north1> but it starts to take long at the later stages
2019-05-11 20:38:54 <_ikke_> danieli: adding listen                  [::]:443 http2; to the server stanza should be enough, right?
2019-05-11 20:39:15 <danieli> _ikke_: i'm not sure how the ssl stuff is set up, but you'll most likely have to include an ssl config file just after doing that
2019-05-11 20:39:29 <_ikke_> There is ssl config in there
2019-05-11 20:39:41 <danieli> yeah, you need *at least* ssl_certificate/ssl_certificate_key
2019-05-11 20:40:04 <danieli> https://hastebin.com/oqiwepipaz.nginx example
2019-05-11 20:40:07 <_ikke_> http://ix.io/1IKG
2019-05-11 20:40:14 <danieli> that's fine, yes
2019-05-11 20:40:45 <_ikke_> yay
2019-05-11 20:40:59 <danieli> you can make one server block listen on both "80", "[::]:80", "[::]:443 http2" and "443 http2"
2019-05-11 20:41:12 <danieli> you don't need to have two separate blocks unless you want 80 to redirect to https
2019-05-11 20:41:31 <_ikke_> Right, that was already there, so I'll just keep it
2019-05-11 20:41:47 <danieli> i mean, it works, it doesn't hurt
2019-05-11 20:41:58 <_ikke_> yes, just a bit redundant
2019-05-11 20:42:06 <tcely> do you need a distinct block just to redirect?
2019-05-11 20:42:24 <danieli> it's the cleanest way to do it imo
2019-05-11 20:43:00 <danieli> one block listening on 80 with "location / { return 301 https://$host$request_uri; }"
2019-05-11 20:43:10 <danieli> and the other listening on 443 http2
2019-05-11 20:43:13 <tcely> I would have thought matching dst port would be fine
2019-05-11 20:44:05 <danieli> you could match $server_port, $scheme or something
2019-05-11 20:44:07 <danieli> but https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
2019-05-11 20:44:22 <_ikke_> north1: tpaste.us should work again
2019-05-11 20:45:01 <north1> _ikke_: ack
2019-05-11 20:45:45 <_ikke_> clandmeter enabled ipv6, but the nginx vserver for tpaste.us was not listening on ipv6, causing the default vserver to be used
2019-05-11 20:46:36 <danieli> the proxy container can terminate both ipv6 and https though?
2019-05-11 20:46:45 <_ikke_> yes
2019-05-11 20:46:48 <_ikke_> it does
2019-05-11 20:47:02 <_ikke_> it just needs to present the correct cert
2019-05-11 20:48:58 <_ikke_> 
ACTION is still waiting

2019-05-11 20:49:56 <danieli> 71%
2019-05-11 20:50:23 <danieli> it doesn't look to be using more than 2 of 48 cores
2019-05-11 20:53:24 <_ikke_> I wonder what happened to deadbeef (checksum mismatch)
2019-05-11 20:53:45 <north1> 81% on telegram
2019-05-11 20:53:53 <danieli> 79%
2019-05-11 20:54:10 <north1> :^) gotta go fast
2019-05-11 20:54:13 <_ikke_> Who is first
2019-05-11 20:54:22 <danieli> 
ACTION casually overclocks

2019-05-11 20:54:26 <danieli> jk, it's alpine's nld5 machine
2019-05-11 20:55:31 <_ikke_> deadbeef has no maintainer
2019-05-11 20:55:39 <_ikke_> Might move it to unmaintained
2019-05-11 20:55:49 <north1> do it
2019-05-11 20:57:37 <_ikke_> done
2019-05-11 20:58:12 <north1> nice
2019-05-11 21:03:02 <danieli> it built btw _ikke_
2019-05-11 21:03:12 <_ikke_> \o/
2019-05-11 21:03:23 <_ikke_> from a PR: `sudo bash -c 'echo 1 > /proc/sys/kernel/perf_event_paranoid'`
2019-05-11 21:03:27 <danieli> gotta package check2 next
2019-05-11 21:03:28 <_ikke_> https://github.com/alpinelinux/aports/pull/4435/files
2019-05-11 21:03:40 <_ikke_> danieli: yes, indeed
2019-05-11 21:04:16 <_ikke_> telegram-desktop pushed
2019-05-11 21:04:17 <danieli> our builders run in non-privileged containers (and chroots inside that), right?
2019-05-11 21:04:34 <_ikke_> yes and no
2019-05-11 21:05:21 <_ikke_> Not sure if they use rootbld
2019-05-11 21:05:38 <danieli> still in non-privileged lxc containers though?
2019-05-11 21:05:56 <danieli> unprivileged*
2019-05-11 21:06:11 <north1> oh it built here too
2019-05-11 21:06:36 <north1> wfm
2019-05-11 21:06:45 <_ikke_> I assume they are unprivileged
2019-05-11 21:13:07 <_ikke_> danieli: how can I confirm whether they are privileged or not?
2019-05-11 21:13:17 <danieli> i'd just check the lxc config for the container
2019-05-11 21:13:28 <danieli> /var/lib/containername/config iirc
2019-05-11 21:13:33 <danieli> /var/lib/lxc *
2019-05-11 21:13:34 <_ikke_> yes
2019-05-11 21:13:39 <_ikke_> What should I look for
2019-05-11 21:13:47 <_ikke_> It drops some capabilities, but not a lot
2019-05-11 21:14:47 <danieli> lxc config show --expanded $name
2019-05-11 21:14:52 <danieli> wait, no
2019-05-11 21:14:56 <danieli> look for lxc.id_map in the config
2019-05-11 21:15:04 <danieli> the lxc config show one is for lxd, not lxc
2019-05-11 21:15:30 <_ikke_> there is none, so I assume it's privileged then
2019-05-11 21:15:57 <danieli> you could also look at the owner of /proc in the container according to a forum post
2019-05-11 21:16:03 <danieli> root/root = privileged, nobody/nobody = unprivileged
2019-05-11 21:37:08 <north1> working on telegram-17.0
2019-05-11 21:37:20 <north1> s/17.0/1.7.0/g
2019-05-11 21:37:20 <alpine-meetbot> north1 meant to say: working on telegram-1.7.0
2019-05-11 21:37:45 <_ikke_> ok, nice
2019-05-11 21:40:35 <tcely> github should just show me when I'm viewing a directory that has a PR open
2019-05-11 21:41:01 <_ikke_> tcely: aports-ghpr?
2019-05-11 21:41:17 <tcely> yes, I'll use that, but it doesn't help on their website
2019-05-11 22:10:18 <otlabs> hi ppl
2019-05-11 22:29:16 <tcely> _ikke_: git aliases are an awesome feature. https://dpaste.de/k53Y
2019-05-11 22:31:56 <danieli> hm, i suspect alpine perl is broken, I keep seeing "panic: locale.c: 893: Unexpected character in locale name '2E."
2019-05-11 22:32:07 <danieli> and after some googling, it looks like that's coming from perl
2019-05-11 22:32:17 <danieli> I've seen it come from postgres, from Xorg, and from urxvt - my urxvt is broken
2019-05-11 22:33:42 <danieli> hex character 2E is .
2019-05-11 22:33:50 <danieli> so it might be failing to parse "C.UTF-8"?
2019-05-11 22:58:28 <mps> danieli: andypost[m]: posted link earlier today to the perl where this happens
2019-05-11 22:58:47 <danieli> yeah, i found it in the source as well, and apparently void has a workaround
2019-05-11 22:58:49 <danieli> i'm gonna test it now
2019-05-11 22:59:17 <mps> that link he posted https://perl5.git.perl.org/perl.git/blob/HEAD:/locale.c#l893
2019-05-11 23:00:23 <mps> just read you discussion with dalias, looks like he is right, looks like the perl introduced this
2019-05-11 23:01:20 <danieli> apparent fix from void: https://github.com/void-linux/void-packages/blob/da7eb611cbc7df8ab379082e0c86e4a871ce0750/srcpkgs/perl/template#L182
2019-05-11 23:01:33 <danieli> the file @ the version we're at https://github.com/Perl/perl5/blame/v5.28.2/locale.c
2019-05-11 23:02:47 <mps> could be, so perl needs fix and try
2019-05-11 23:03:52 <danieli> i already patched it, build it, and transferred it to my vm
2019-05-11 23:04:39 <mps> perl? nice work
2019-05-11 23:05:54 <danieli> yes, but according to north1 everything built against perl-dev will have to be rebuilt with that patch
2019-05-11 23:06:17 <mps> probably he is right
2019-05-11 23:06:55 <mps> pkgs which are linked
2019-05-11 23:06:57 <danieli> it would make sense
2019-05-11 23:06:57 <danieli> yes
2019-05-11 23:07:22 <north1> https://github.com/void-linux/void-packages/pull/1849
2019-05-11 23:08:01 <danieli> oh fucking hell
2019-05-11 23:08:04 <danieli> sorry about the language
2019-05-11 23:08:34 <mps> I looked at debian perl bug reports but didn't see anything related, so it is in some relation to musl, it seems
2019-05-11 23:09:00 <mps> danieli: np, ;)
2019-05-11 23:13:37 <north1> danieli: lol
2019-05-11 23:17:49 <danieli> i patched perl's apkbuild, bumped the pkgrel, and bumped rxvt-unicode's pkgrel
2019-05-11 23:18:03 <danieli> then i build rxvt-unicode, which pulled in the perl i had just built
2019-05-11 23:18:14 <danieli> but now, on that vm, it's saying segfault with perl module version mismatch
2019-05-11 23:18:17 <danieli> i'm done
2019-05-11 23:20:56 <mps> hmm, 'apk search -r so:libperl  |wc -l' shows 291
2019-05-11 23:22:51 <mps> to late is here, good night to all
2019-05-11 23:44:43 <danieli> all right, I sent the postgres patch: https://patchwork.alpinelinux.org/patch/4852/
2019-05-11 23:44:45 <danieli> good night
2019-05-12 00:35:18 <tcely> come again? http://tpaste.us/M5p7
2019-05-12 00:41:22 <danieli> tcely: try logging out then in
2019-05-12 00:41:27 <danieli> it might not have taken effect properly
2019-05-12 00:41:37 <danieli> iirc a trick to bypass that is script /dev/null
2019-05-12 00:45:58 <tcely> ok. sudo -u builder -s worked. now, how to fix docker
2019-05-12 00:47:11 <tcely> that's silly. just removing group from USER fixed it
2019-05-12 00:48:45 <tcely> https://docs.docker.com/engine/reference/builder/#user
2019-05-12 00:49:03 <tcely> ^^ the docs make this seem like a bad idea
2019-05-12 05:05:20 <_ikke_> tcely: aliases are good for simple commands, other wise  i just create a shell script called git-*
2019-05-12 05:05:39 <_ikke_> I have one that I can use to eitehr get a patch from github or patchwork
2019-05-12 05:13:52 <_ikke_> builders are done, yay
2019-05-12 06:01:50 <_ikke_> clandmeter: 2 tests of nbd fail on the builders (3.10)
2019-05-12 09:21:42 <bratkartoffel> Good morning guys. _ikke_ can you please take a look why openjdk10 doesn't build on s390x? I cannot find the build logs
2019-05-12 09:24:10 <Cogitri> Morning
2019-05-12 10:35:38 <_ikke_> bratkartoffel: The builder is stuck on wireshark, so it didn't get to build openjdk10 yet
2019-05-12 10:54:19 <bratkartoffel> thanks for clarification
2019-05-12 12:02:40 <_ikke_> why doesn't replaces="foo"; provides="foo=1.2-0"; seem to work? When I try to install foo, it just says foo is missing
2019-05-12 12:20:20 <north1> shouldn't be provides foo=1.2-r0 ?
2019-05-12 12:23:05 <_ikke_> good point
2019-05-12 12:24:46 <_ikke_> Yes, that works
2019-05-12 12:43:12 <_ikke_> Wireshark armhf build failure reported: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15771
2019-05-12 12:47:40 <_ikke_> For s390x: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15772
2019-05-12 13:11:49 <tmhoang> thanks for reporting _ikke_
2019-05-12 13:16:49 <_ikke_> np
2019-05-12 13:29:12 <kmaxwell> what's the quickest way to see which repository a package is in?
2019-05-12 13:29:35 <kmaxwell> just curious to see if there's a one line check if its main/community/testing
2019-05-12 13:46:37 <[[sroracle]]> kmaxwell: apk policy pkgname
2019-05-12 13:47:04 <[[sroracle]]> apk list too probably
2019-05-12 13:50:52 <danieli> not too sure about list, policy for sure
2019-05-12 13:56:56 <kmaxwell> thanks both, that's awesome, I'd seen apk policy but now I can see how it helps!
2019-05-12 13:56:59 <kmaxwell> ty
2019-05-12 14:20:26 <_ikke_> Yeah, git push fighting with andy :D
2019-05-12 14:22:48 <danieli> _ikke_: the telegram-desktop maintainer dropped maintainership lol
2019-05-12 14:22:59 <danieli> not sure what their nick on here is or if they are here
2019-05-12 14:23:31 <_ikke_> ugh, ok
2019-05-12 14:23:39 <danieli> https://patchwork.alpinelinux.org/patch/4854/
2019-05-12 14:23:47 <danieli> "the aport has been rewritten and now uses an unofficial third party build system that i don't want to maintain"
2019-05-12 14:24:49 <danieli> and, not sure if you caught it, this is the postgres PL/Perl regression test fix, i tested it twice to make sure my build env wasn't completely ****** after cleaning it https://patchwork.alpinelinux.org/patch/4852/
2019-05-12 14:27:09 <_ikke_> Someone else would need to push that
2019-05-12 14:27:41 <danieli> yeah, iirc that's correct, just keep it in mind in case i'm away when someone who can is around
2019-05-12 14:28:17 <danieli> actually, another fix (workaround) would be to rebuild it against patched perl
2019-05-12 14:28:19 <_ikke_> And you say with this patch everything linked against it needs to be rebuilt?
2019-05-12 14:28:28 <danieli> perl one, according to north1, yes
2019-05-12 14:28:30 <_ikke_> ah, this is pg
2019-05-12 14:28:33 <danieli> yes, pg
2019-05-12 14:28:53 <danieli> i have not submitted a patch for perl5 since we just finished rebuilding a metric ton of packages against it
2019-05-12 14:29:36 <danieli> the postgres patch (--no-locale) is good enough, it defaults to the C locale
2019-05-12 14:34:28 <danieli> goood, i hate redmine
2019-05-12 14:35:04 <_ikke_> What's the issue?
2019-05-12 14:35:11 <_ikke_> Ha!
2019-05-12 14:35:15 <danieli> if it sees 'close'/'closing' and #<number> in a message, it closes both?
2019-05-12 14:35:19 <danieli> and it *cannot* be changed whatsoever
2019-05-12 14:35:33 <_ikke_> Both in what sense?
2019-05-12 14:35:38 <_ikke_> Both PR and ticket?
2019-05-12 14:36:09 <danieli> I closed a ticket that's a duplicate of another one, the message included 'closing', some text, and #<ID of other ticket>
2019-05-12 14:36:11 <danieli> it closed both
2019-05-12 14:36:42 <_ikke_> what ticket?
2019-05-12 14:36:49 <danieli> #9324
2019-05-12 14:37:10 <danieli> I was just about to reply to it and then I noticed both it *and* the duplicate got closed
2019-05-12 14:37:49 <_ikke_> And you are sure you didn't accidentally set this one as closed?
2019-05-12 14:38:10 <danieli> I have no idea why it did what it did, I commented on the duplicate
2019-05-12 14:38:44 <danieli> I guess I'll have to re-report it, then I think I'm gonna back off and spend my Sunday on doing something else than fighting redmine
2019-05-12 14:39:30 <_ikke_> It looks like you i can just reopen it
2019-05-12 14:39:46 <_ikke_> s/It looks like you//
2019-05-12 14:39:46 <alpine-meetbot> _ikke_ meant to say:  i can just reopen it
2019-05-12 14:39:51 <danieli> from redmine's tracker > Oh, I see, you need to define in the configuration that this transition is possible. Hm.
2019-05-12 14:40:11 <danieli> another one says >Resolution set to Invalid >Check your workflow
2019-05-12 14:40:34 <danieli> you apparently cannot reopen a closed issue
2019-05-12 14:40:40 <_ikke_> I've never seen that you can close redmine tickets by comments in the ticket
2019-05-12 14:40:47 <_ikke_> Sure I can
2019-05-12 14:41:01 <danieli> I knew that you can close tickets via comments, but not that it'd close both or parse it like that?
2019-05-12 14:41:15 <_ikke_> I've only seen it from scm commits
2019-05-12 14:41:17 <_ikke_> never from comments
2019-05-12 14:41:45 <_ikke_> 9324 should be open, right?
2019-05-12 14:41:49 <danieli> yes
2019-05-12 14:42:11 <danieli> the reason I can't change it might be because I'm developer or something and not admi n
2019-05-12 14:42:13 <danieli> admin*
2019-05-12 14:42:21 <_ikke_> Done
2019-05-12 14:42:25 <_ikke_> Yes
2019-05-12 14:42:36 <_ikke_> In redmine you can define the workflow per role and tracker
2019-05-12 14:44:24 <danieli> #$%^$&
2019-05-12 14:45:09 <_ikke_> ..
2019-05-12 14:45:35 <danieli> hm?
2019-05-12 14:46:41 <_ikke_> You seem to be frustrate
2019-05-12 14:46:43 <_ikke_> d
2019-05-12 14:46:48 <danieli> long day
2019-05-12 14:56:25 <_ikke_> Anyone having an objection temporarily disabling the test suite for wireshark until it's fixed, it's now blocking the builders
2019-05-12 14:56:49 <danieli> we can't make it skip wireshark?
2019-05-12 14:57:13 <_ikke_> nope
2019-05-12 14:57:16 <danieli> i'd prefer to not ship very broken packages until they're fixed rather than disabling tests :/
2019-05-12 14:57:30 <_ikke_> Then we'd have to disable wireshark on those arches
2019-05-12 14:57:46 <danieli> but hm, unless someone has an immediate solution, i don't see any option other than disabling tests
2019-05-12 14:57:58 <_ikke_> I'm fine with disabling it as well
2019-05-12 14:58:07 <_ikke_> For the time being
2019-05-12 14:58:45 <kmaxwell> is it posible to just skip the failing tests?
2019-05-12 14:58:56 <_ikke_> It's a python test suite, so possible
2019-05-12 14:58:56 <danieli> i didn't see a way to easily do that with wireshark
2019-05-12 14:59:03 <_ikke_> possibly*
2019-05-12 14:59:31 <danieli> right, pytest - in that case it *should* be possible
2019-05-12 14:59:45 <danieli> i saw some tests relating to endianness (LE) failing on some arches
2019-05-12 15:00:01 <kmaxwell> I have done this before, let me find where, in case an example helps
2019-05-12 15:00:01 <_ikke_> armhf
2019-05-12 15:00:16 <_ikke_> danieli: Don't know if you have noticed, but I reported these failing tests upstream
2019-05-12 15:00:29 <danieli> I saw
2019-05-12 15:01:11 <kmaxwell> musl handle locale differently so I've used something like:
2019-05-12 15:01:17 <kmaxwell> python3 -m pytest --deselect tests/test_utils.py::test_set_locale
2019-05-12 15:04:08 <SpaceToast> iirc correctly musl only has 2 locales
2019-05-12 15:04:22 <SpaceToast> C.UTF-8 and C (C added in 1.1.11 because of changes in POSIX plans)
2019-05-12 15:05:16 <kmaxwell> _ikke_: would a PR disabling the failing wireshark tests help? the ones you've reported upstream
2019-05-12 15:05:41 <_ikke_> kmaxwell: was just working on that
2019-05-12 15:06:07 <kmaxwell> cool, I'll leave you to it then :)
2019-05-12 15:06:12 <_ikke_> kmaxwell: A review of the patch would be helpfull though
2019-05-12 15:06:18 <kmaxwell> looks like the build logs have the IDs to deselect
2019-05-12 15:06:20 <kmaxwell> happy to!
2019-05-12 15:06:53 <_ikke_> Trying to find the correct node id for the armhf failure
2019-05-12 15:07:13 <_ikke_> uite_wslua.py::case_wslua::test_wslua_tvb_tree
2019-05-12 15:07:25 <_ikke_> tsuite_wslua.py::case_wslua::test_wslua_tvb_no_tree
2019-05-12 15:07:27 <_ikke_> right?
2019-05-12 15:10:47 <kmaxwell> maybe I'm looking at a different error, I was thinking: suite_decryption.case_decrypt_smb2.test_smb300_aes128ccm
2019-05-12 15:11:01 <_ikke_> There are 2
2019-05-12 15:11:03 <kmaxwell> actually ignore that ^^^
2019-05-12 15:11:07 <_ikke_> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15771
2019-05-12 15:11:09 <_ikke_> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15772
2019-05-12 15:13:00 <kmaxwell> possibly the second :: should be .
2019-05-12 15:13:15 <_ikke_> http://tpaste.us/xplv
2019-05-12 15:13:16 <kmaxwell> tsuite_wslua.py::case_wslua.test_wslua_tvb_no_tree
2019-05-12 15:13:39 <_ikke_> ok
2019-05-12 15:13:44 <_ikke_> testing that patch now
2019-05-12 15:15:04 <kmaxwell> and I am trying to check the sytnax (chromebook is slow building :) )
2019-05-12 15:15:10 <kmaxwell> otherwise the patch looks good
2019-05-12 15:17:26 <_ikke_> ============================================ no tests ran in 3.22 seconds =============================================
2019-05-12 15:18:18 <_ikke_> Now replaced the second "::" with .
2019-05-12 15:18:24 <_ikke_> still the same
2019-05-12 15:19:27 <_ikke_> /-d/--deselect/ works
2019-05-12 15:19:54 <_ikke_> kmaxwell: http://tpaste.us/yPX0
2019-05-12 15:20:15 <kmaxwell> just saw that '-d                    load-balance tests. shortcut for '--dist=load''
2019-05-12 15:20:36 <_ikke_> heh
2019-05-12 15:20:41 <kmaxwell> from 'python3 -m pytest --help'
2019-05-12 15:21:29 <_ikke_> pytest is also an executable :)
2019-05-12 15:22:57 <kmaxwell> yep, I can't remember the exact difference, I think the -m just adds cwd to sys.path
2019-05-12 15:23:01 <kmaxwell> force of habit :)
2019-05-12 15:24:28 <danieli> python -m <module> runs the module as a script as if it was an executable
2019-05-12 15:26:57 <_ikke_> kmaxwell: and it sets __name__ to __main__ afaik
2019-05-12 15:27:25 <_ikke_> which is usually what commands use to differentiate between being run or being imported
2019-05-12 15:27:45 <kmaxwell> https://docs.pytest.org/en/latest/usage.html#calling-pytest-through-python-m-pytest
2019-05-12 15:28:09 <kmaxwell> is the reference explaining how the choice change sys.path
2019-05-12 15:29:18 <kmaxwell> I think I got the habit from too many virtualenvs, python or python3 is always the one for the venv
2019-05-12 15:29:51 <_ikke_> Ok, pushed
2019-05-12 15:37:11 <kmaxwell> _ikke_: hope it works, if not I found canonical ids, you were closer to right than I was
2019-05-12 15:37:16 <kmaxwell> test/suite_wslua.py::case_wslua::test_wslua_tvb_tree
2019-05-12 15:37:21 <_ikke_> Hmm, ok
2019-05-12 15:37:27 <kmaxwell> from running 'pytest -rf'
2019-05-12 15:37:36 <kmaxwell> before building anything so it prints all the ids
2019-05-12 15:37:43 <_ikke_> armhf just failed
2019-05-12 15:38:02 <_ikke_> So the dir name is significant?
2019-05-12 15:38:36 <_ikke_> http://tpaste.us/YMlZ
2019-05-12 15:39:47 <kmaxwell> yes, I think that's better I also think all .s should be ::s
2019-05-12 15:40:23 <_ikke_> sorry?
2019-05-12 15:40:39 <_ikke_> ah,
2019-05-12 15:40:48 <kmaxwell> http://tpaste.us/5w6B should have a list of all the node ids
2019-05-12 15:40:58 <_ikke_> I forgot /g
2019-05-12 15:41:07 <kmaxwell> I got this from running 'pytest -rf test/ 2
2019-05-12 15:41:17 <_ikke_> http://tpaste.us/vbLB
2019-05-12 15:41:29 <kmaxwell> sorry 'pytest -rf test/ 2 >&1 | tpaste'
2019-05-12 15:41:40 <kmaxwell> before building anything so everything would fail
2019-05-12 15:42:06 <kmaxwell> _ikke_: yes I think that's it
2019-05-12 15:45:06 <_ikke_> Ok, another try
2019-05-12 15:46:04 <kmaxwell> I just spotted another mistake!
2019-05-12 15:46:06 <kmaxwell> orry
2019-05-12 15:46:08 <kmaxwell> sorry
2019-05-12 15:46:12 <_ikke_> :(
2019-05-12 15:46:25 <kmaxwell> in '--deselect test/suite_wslua::py::case_wslua::test_wslua_tvb_tree \'
2019-05-12 15:46:39 <kmaxwell> the separator before py should be . not ::
2019-05-12 15:46:52 <kmaxwell> '--deselect test/suite_wslua.py::case_wslua::test_wslua_tvb_tree '
2019-05-12 15:47:15 <_ikke_> http://tpaste.us/Q1kO
2019-05-12 15:48:31 <kmaxwell> just running a quick command to see how many tests that disables, one minute please
2019-05-12 15:48:44 <_ikke_> Yes, waiting
2019-05-12 15:51:24 <kmaxwell> _ikke_: I think we have it that time!
2019-05-12 15:51:33 <kmaxwell> 10 tests disabled
2019-05-12 15:51:37 <_ikke_> \o/
2019-05-12 15:53:08 <_ikke_> 
ACTION drumrolls

2019-05-12 15:53:43 <kmaxwell> I waiting with baited breath :)
2019-05-12 15:54:17 <danieli> FAILED test/suite_wslua.py::case_wslua::test_wslua_tvb_tree
2019-05-12 15:54:17 <danieli> FAILED test/suite_wslua.py::case_wslua::test_wslua_tvb_no_tree
2019-05-12 15:54:41 <danieli> from armhf about a minute after the last push
2019-05-12 15:54:45 <_ikke_> failed again?
2019-05-12 15:54:56 <danieli> not sure if it's from the most recent push or the one before that
2019-05-12 15:54:56 <_ikke_> /o\
2019-05-12 15:55:03 <danieli> i'd wait for the other builders to be sure
2019-05-12 15:55:06 <_ikke_> yes
2019-05-12 15:55:08 <danieli> idk which ones you disabled
2019-05-12 15:56:13 <_ikke_> https://git.alpinelinux.org/aports/commit/?id=0606c48a145f3288a90c50519f26cb96ffd83eb6
2019-05-12 15:57:12 <_ikke_> Seems like building takes about 6 minutes, so this was too quick after the last push
2019-05-12 15:59:02 <_ikke_> edge/community/armv7: uploaded
2019-05-12 15:59:06 <_ikke_> \o/
2019-05-12 15:59:25 <_ikke_> hmm
2019-05-12 15:59:29 <_ikke_> but armhf failed
2019-05-12 15:59:43 <_ikke_> I don't get it
2019-05-12 16:00:06 <_ikke_> still waiting
2019-05-12 16:00:09 <_ikke_> build.a.o is confusing
2019-05-12 16:01:19 <kmaxwell> awesome!
2019-05-12 16:01:37 <kmaxwell> I agree on the confusing, including the commit hash in the build log would really help
2019-05-12 16:02:09 <_ikke_> It failed on build.a.o, but #alpine-commits didn't mention another fail
2019-05-12 16:03:05 <kmaxwell> the armhf log showing build failure isn't the latest commit
2019-05-12 16:03:29 <kmaxwell> 527 tests, disable 10, leaves 517
2019-05-12 16:04:15 <kmaxwell> when you deselect they don't show as failed/passed/skipped
2019-05-12 16:04:38 <_ikke_> waiting for s390x
2019-05-12 16:05:59 <kmaxwell> I still don't think build-edge-armhf has tried the latest commit
2019-05-12 16:08:34 <_ikke_> I will retry after s390x finished
2019-05-12 16:08:44 <_ikke_> Not sure where it's hanging on
2019-05-12 16:26:46 <_ikke_> seems like success!!!
2019-05-12 16:26:57 <north1> danieli: thanks for the heads up i updated pr7815 to also adopt it
2019-05-12 16:26:58 <_ikke_> They are continuing now
2019-05-12 16:27:09 <_ikke_> north1: Thanks
2019-05-12 16:28:19 <_ikke_> \o/\o/\o/
2019-05-12 16:30:44 <kmaxwell> I can see new armv7 wirehark packages on the mirrors but not the others yet
2019-05-12 16:30:59 <_ikke_> can take 15-30 minutes
2019-05-12 16:30:59 <danieli> takes a bit to sync when they're done building
2019-05-12 16:31:09 <_ikke_> master.a.o should show it
2019-05-12 16:31:13 <kmaxwell> now I can see armhf as well :)
2019-05-12 16:31:43 <north1> _ikke_: welcome (idk what for)
2019-05-12 16:41:09 <_ikke_> Adopting telegram-desktop
2019-05-12 16:59:14 <kmaxwell> wireshark for s390x is on master.a.o now too
2019-05-12 16:59:21 <kmaxwell> \o/
2019-05-12 17:00:47 <_ikke_> kmaxwell: thanks for the help
2019-05-12 17:14:01 <_ikke_> great, java-jtrek and dependencies fail due to 500 errors :(
2019-05-12 17:14:56 <_ikke_> java-jtreg*
2019-05-12 17:15:45 <_ikke_> curl works, but abuild-fetch fails somehow
2019-05-12 17:16:33 <_ikke_> it's flaky
2019-05-12 17:20:34 <kmaxwell> is a PR on its own against abuild sufficient? or is it better to file an issue in redmine too?
2019-05-12 17:20:51 <SpaceToast> PR is generally sufficient
2019-05-12 17:21:01 <_ikke_> nod
2019-05-12 17:21:25 <kmaxwell> ty, its was a one character change so ... :)
2019-05-12 17:21:31 <_ikke_> Right
2019-05-12 17:24:27 <kmaxwell> I have only recently learnt about SPDX identifiers but really like them
2019-05-12 17:24:34 <_ikke_> nice
2019-05-12 17:24:42 <danieli> yeah, we try using spdx in alpine
2019-05-12 17:24:54 <danieli> i wrote a tool to check all packages in aports and there are a lot without valid spdx
2019-05-12 17:25:10 <_ikke_> You might want to install spdx-licenses-list from testing
2019-05-12 17:25:18 <_ikke_> Then abuild warns when you don't have a valid identifier
2019-05-12 17:25:35 <danieli> it should be in by default imo
2019-05-12 17:25:44 <_ikke_> Yes, but it would have to be in main then
2019-05-12 17:25:50 <danieli> indeed
2019-05-12 17:26:08 <_ikke_> I adopted it, want to at least promote it to community
2019-05-12 17:28:48 <_ikke_> Done :D
2019-05-12 17:29:19 <kmaxwell> that's exactly my line of thinking!
2019-05-12 17:29:44 <kmaxwell> I spotted that abuild sanitycheck was missing some invalid licences
2019-05-12 17:29:55 <kmaxwell> https://github.com/alpinelinux/abuild/pull/84 should fix it
2019-05-12 17:31:30 <danieli> i deleted the scripts to check sources and licenses, i'll rewrite it, won't take too long
2019-05-12 17:38:22 <mps> set env srcdir out of aports tree to unpack and build pkg works but doesn't work for pkgdir, it is made in aports tree
2019-05-12 17:38:57 <mps> anyone know why first works and second doesn't
2019-05-12 17:39:28 <_ikke_> What doesn't work?
2019-05-12 17:40:23 <mps> set env pkgdir out of aports three, i.e. abuild still make pkg dir in aports tree
2019-05-12 17:40:41 <mps> s/three/tree/
2019-05-12 17:40:41 <alpine-meetbot> mps meant to say: set env pkgdir out of aports tree, i.e. abuild still make pkg dir in aports tree
2019-05-12 17:40:56 <_ikke_> I mean, do you get an error or something like that?
2019-05-12 17:41:34 <mps> no error, but doesn't make pkg dir outside of aports
2019-05-12 17:42:08 <_ikke_> No clue
2019-05-12 17:42:36 <mps> setting pkgsrc works as I expected
2019-05-12 17:42:53 <mps> i.e. buildir is out of tree
2019-05-12 17:43:57 <mps> (trying to consolidate my five aports repos)
2019-05-12 17:43:58 <kmaxwell> should abuild sanitycheck be a part of the CI somewhere?
2019-05-12 17:44:07 <_ikke_> it is
2019-05-12 17:44:09 <_ikke_> in drone
2019-05-12 17:44:19 <_ikke_> but it's only warnings
2019-05-12 17:44:41 <kmaxwell> yes, sorry that's right it just displays warnings, doesn't error
2019-05-12 17:45:55 <_ikke_> And I run it manually on packages as well before I push
2019-05-12 17:49:53 <north1> There is also alint http://ix.io/1IPV
2019-05-12 17:51:07 <kmaxwell> right I see it now, abuild itself calls it
2019-05-12 17:52:54 <kmaxwell> north1: ty
2019-05-12 17:53:25 <_ikke_> north1: thanks, will test it
2019-05-12 17:54:07 <north1> I put it on my pre-commit hook
2019-05-12 17:54:31 <north1> https://raw.githubusercontent.com/maxice8/meltryllis/master/alpinelinux/pre-commit
2019-05-12 17:55:18 <kmaxwell> maybe a silly question, but are you maxice8 on GH?
2019-05-12 17:55:42 <north1> kmaxwell: yes
2019-05-12 17:56:03 <north1> maxice8 on GH and IRC (north1 is the main account that holds the nick of maxice8 on freenode), Leo on Alpine
2019-05-12 17:56:08 <north1> i plan to move everything over to Leo after some time
2019-05-12 17:56:45 <_ikke_> north1: I use shellcheck as well btw
2019-05-12 17:57:14 <kmaxwell> shellcheck is awesome!
2019-05-12 17:57:53 <_ikke_> Yes, I want to get it into alpine, but requires quite a lot of dependencies first
2019-05-12 17:58:04 <north1> haskell
2019-05-12 17:58:05 <kmaxwell> north1: ahh cool, then thank you for the reviews! I didn't make the connection between the names before
2019-05-12 17:58:06 <_ikke_> indeed
2019-05-12 17:58:27 <_ikke_> I think I will start after 3.10 is done
2019-05-12 17:58:29 <kmaxwell> pandoc is another haskell package it would be great to see packaged
2019-05-12 17:58:41 <kmaxwell> I appreciate its a lot of work
2019-05-12 17:58:45 <north1> Void just does the Rust approach and downloads and install all the deps via stack or cabal or whatever haskell uses for pkg management like cargo for Rust
2019-05-12 17:59:07 <_ikke_> north1: I tried that approach, but I couldn't get it to work properly
2019-05-12 17:59:31 <_ikke_> In a way that is packagable
2019-05-12 18:00:03 <_ikke_> archlinux has each dependency packaged
2019-05-12 18:00:31 <north1> https://github.com/void-linux/void-packages/blob/a5926668fce398e1e76448d1c37cf4a43b10844e/srcpkgs/shellcheck/template Void just doesn't care
2019-05-12 18:01:53 <_ikke_> build_style=haskell-stack?
2019-05-12 18:02:17 <north1> build_style is just a set of default prepare() build() package() for xbps-src
2019-05-12 18:02:27 <north1> common/build-style/haskell-stack.sh should hold the definitions
2019-05-12 18:02:28 <_ikke_> Yes, I assuemd so
2019-05-12 18:03:12 <_ikke_> Maybe I will do that initially for shellcheck
2019-05-12 18:17:44 <eu> revbump when adding check() to a package with no other changes?
2019-05-12 18:19:22 <eu> for: run the tests on the official builders so that it don't potentially crash some time in the future when other changes are introduced due
2019-05-12 18:19:35 <eu> against: users get an update witout any benefit
2019-05-12 18:25:29 <danieli> I'd say bump the revision. in my opinion, being sure the software works is worth an 'unnecessary' update
2019-05-12 18:30:37 <_ikke_> +1
2019-05-12 18:30:59 <_ikke_> Running them on the builders makes sure all arches are covered
2019-05-12 18:35:25 <north1> Is there a reliable way to find which APKBUILD generates which subpackage ?
2019-05-12 18:36:51 <_ikke_> north1: pkgs.a.o tracks origin of a package
2019-05-12 18:36:54 <danieli> check origin @ pkgs.a.o
2019-05-12 18:36:55 <danieli> yup
2019-05-12 18:37:14 <_ikke_> Not sure if there is a way through the CLI
2019-05-12 18:37:16 <north1> and a reliable way from a commandline for lots of packages in quick succession ?
2019-05-12 18:37:25 <danieli> not too sure off the top of my head
2019-05-12 18:37:53 <north1> i want to find the mainpkg of each package in depends= and makedepends= so i can make alint check if a package from repo X is dependnding on repo Y of which it can't depend on.
2019-05-12 18:37:54 <danieli> uh
2019-05-12 18:38:04 <danieli> testing/mozjs60 has no APKBUILD file
2019-05-12 18:38:06 <danieli> what's up with that..?
2019-05-12 18:38:16 <north1> it has for me
2019-05-12 18:38:47 <north1> oh, it is in main
2019-05-12 18:38:52 <danieli> wait
2019-05-12 18:38:54 <danieli> there's two of it?
2019-05-12 18:39:11 <Cogitri> Uhh, maybe I forgot deleting the testing one
2019-05-12 18:39:14 <danieli> sure is two of it
2019-05-12 18:39:16 <north1> https://github.com/alpinelinux/aports/pull/7837
2019-05-12 18:39:48 <north1> cogitri: :^) should have used `ax m main`
2019-05-12 18:39:53 <_ikke_> north1: there is apk list -o <origin>, but I don't see a reverse one
2019-05-12 18:40:06 <danieli> north1: that was obscenely quick
2019-05-12 18:41:07 <kr0k0> Hi all
2019-05-12 18:41:08 <north1> gotta go fast
2019-05-12 18:41:24 <_ikke_> Funny how the order of builders on build.a.o sometimes just changes
2019-05-12 18:41:28 <_ikke_> kr0k0: hi
2019-05-12 18:41:29 <kr0k0> _ikke_: Thanks for review pr7753!
2019-05-12 18:41:42 <Cogitri> Hello there
2019-05-12 18:41:49 <_ikke_> kr0k0: np
2019-05-12 18:42:22 <kr0k0> _ikke_: I have removed the post deinstall script.
2019-05-12 18:43:02 <_ikke_> I noticed, was just looking at the changes
2019-05-12 18:43:09 <danieli> list of invalid licenses, json format http://tpaste.us/Kg7w
2019-05-12 18:43:28 <danieli> {"branch": { "pkgname": "license", ... }, ... }
2019-05-12 18:43:56 <_ikke_> "perl-convert-uulib": "GPL-2.0 or Artistic"
2019-05-12 18:44:04 <_ikke_> I do believe that's valid
2019-05-12 18:44:10 <north1> that is not right
2019-05-12 18:44:14 <danieli> no
2019-05-12 18:44:25 <north1> spdx uses OR not or
2019-05-12 18:44:31 <_ikke_> ok
2019-05-12 18:44:37 <danieli> rigth
2019-05-12 18:44:37 <north1> and most likely since it is perl it is GPL-1.0-or-later OR Artistic-1.0-Perl
2019-05-12 18:44:41 <danieli> i didn't parse them, i only checked the existing ones
2019-05-12 18:45:03 <danieli> i'll actually parse them this time, i forgot they can be composite
2019-05-12 18:45:23 <_ikke_> AND is also valid I believe
2019-05-12 18:45:30 <danieli> it is, my b
2019-05-12 18:45:42 <north1> AND is also valid but not in the case of the Artistic-1.0-Perl OR GPL-1.0-or-later
2019-05-12 18:46:14 <north1> and WITH can be used with Exceptions
2019-05-12 18:46:15 <north1> like GPL-3.0-or-later WITH foo-exception-for-openssl
2019-05-12 18:46:42 <_ikke_> Though I guess alpine just seperates with whitespace in case of AND, right?
2019-05-12 18:47:02 <andypost[m]> Yep
2019-05-12 18:47:46 <north1> _ikke_: depends on the maintainer
2019-05-12 18:49:25 <_ikke_> kr0k0: fyi it's pushed
2019-05-12 18:51:00 <_ikke_> north1: Would be nice to have some way to get updates for your lint scripts :-)
2019-05-12 18:52:56 <north1> _ikke_: I can make a repo and maintain them separate from my dotfiles if there is interest
2019-05-12 18:53:02 <north1> like xtools from Void Linux
2019-05-12 18:53:25 <_ikke_> I am interested
2019-05-12 18:53:52 <north1> :^) or just make a cron timer to download the raw file from master of my dotfile repo every 5 min or so
2019-05-12 18:53:58 <_ikke_> heh
2019-05-12 18:55:02 <north1> What is the prefered license for Alpine Linux stuff ?
2019-05-12 18:55:12 <_ikke_> MIT I believe
2019-05-12 18:56:14 <kr0k0> _ikke_: Thanks again!
2019-05-12 18:56:50 <_ikke_> oracle is anoying, their source package endpoints constantly give 500 error messages
2019-05-12 18:56:57 <_ikke_> curl: (22) The requested URL returned error: 500 Internal Server Error
2019-05-12 18:57:07 <kmaxwell> I'm interested in alint too, especially if there was a package to install it
2019-05-12 18:58:03 <_ikke_> kr0k0: vdr failed on ppc64le
2019-05-12 18:58:41 <_ikke_> I don't get a buildlog though
2019-05-12 19:00:10 <north1> _ikke_: https://github.com/maxice8/atools/releases
2019-05-12 19:00:37 <_ikke_> Thanks
2019-05-12 19:00:54 <_ikke_> Will create a package for it :-)
2019-05-12 19:11:12 <tmhoang> _ikke_ I build wireshark here on s390x just fine :(
2019-05-12 19:11:22 <_ikke_> tmhoang: with all the tests?
2019-05-12 19:11:35 <tmhoang> jes
2019-05-12 19:11:41 <_ikke_> Strange
2019-05-12 19:11:55 <tmhoang> story of my life : one result on build, one on my dev
2019-05-12 19:12:00 <_ikke_> yup
2019-05-12 19:12:03 <_ikke_> quite anoying
2019-05-12 19:12:22 <_ikke_> north1: http://tpaste.us/jXge
2019-05-12 19:12:53 <north1> needs grep not findutils
2019-05-12 19:13:00 <_ikke_> D'oh, thanks
2019-05-12 19:14:36 <_ikke_> pushed
2019-05-12 19:23:17 <_ikke_> sigh: https://hg.openjdk.java.net/code-tools/jtharness
2019-05-12 19:23:21 <_ikke_> what do you get?
2019-05-12 19:25:38 <Cogitri> Hum, are the armhf builders faster than Drone's machine? If not I'll have to disable tests that long running test in pr7596
2019-05-12 19:26:02 <Cogitri> Times out after 50 minutes, not quite sure if I should keep increasing the time limit
2019-05-12 19:26:43 <_ikke_> Cogitri: not sure
2019-05-12 19:27:48 <andypost[m]> ikke please check pr7838
2019-05-12 19:28:16 <_ikke_> andypost[m]: anythign specific?
2019-05-12 19:29:13 <andypost[m]> It's strange that source gone on next release
2019-05-12 19:29:31 <danieli> man, the spdx spec is massive, and parsing it is going to take a little more effort than just checking if they're in the spdx list
2019-05-12 19:29:44 <danieli> there's no good library that does it for me in py, by the looks of it
2019-05-12 19:29:58 <_ikke_> danieli: Maybe try best effort?
2019-05-12 19:30:13 <danieli> gonna try, but it's a bit too unprecise at the moment
2019-05-12 19:30:26 <_ikke_> split on space, ignore AND / OR / WITH?
2019-05-12 19:30:50 <danieli> https://github.com/spdx/tools-python I'm gonna see if I can rip out some pieces from this, it's for parsing entire 'spdx documents'
2019-05-12 19:31:24 <_ikke_> andypost[m]: they only keep the latest version?
2019-05-12 19:32:17 <andypost[m]> <_ikke_ "andypost: they only keep the lat"> looks we hit this every release
2019-05-12 19:32:27 <danieli> the ex-maintainer of telegram-desktop wasn't too happy about the apkbuild being rewritten, by the looks of it
2019-05-12 19:32:38 <_ikke_> danieli: nope. I replied to his post
2019-05-12 19:32:45 <danieli> he just replied back
2019-05-12 19:32:54 <_ikke_> I see
2019-05-12 19:33:23 <_ikke_> At least I tried
2019-05-12 19:34:17 <_ikke_> github search is broken :/
2019-05-12 19:34:26 <_ikke_> py-linecache -> 0 results, py-linecache2 -> 1 result
2019-05-12 19:36:07 <north1> searching for the package or string on the repo ?
2019-05-12 19:36:27 <_ikke_> looking for a pr
2019-05-12 19:37:04 <north1> this one https://github.com/alpinelinux/aports/pull/7509 ?
2019-05-12 19:37:52 <_ikke_> yes
2019-05-12 19:38:21 <_ikke_> I pushed traceback2, but it depends on py-linecache2, which does not exist
2019-05-12 19:46:38 <_ikke_> bratkartoffel: I had to disable java-jtreg + deps, it is still having issues in downloading the source
2019-05-12 19:48:56 <_ikke_> andypost[m]: There is nothing preventing live-media to be merged afaict, correct?
2019-05-12 20:06:45 <_ikke_> Hmm, seems like the json ruby module is missing here, right? https://build.alpinelinux.org/buildlogs/build-3-10-x86/community/ruby-enum/ruby-enum-0.7.2-r1.log
2019-05-12 20:11:05 <andypost[m]> _ikke_: thank, meantime trying to fix corebird but looks it should gone
2019-05-12 20:13:11 <danieli> _ikke_: take two, I rewrote it in nodejs where there's a spdx expression parser generator package available
2019-05-12 20:13:20 <danieli> http://tpaste.us/DLRe
2019-05-12 20:14:19 <danieli> right, i didn't parse out shell comments - there is a minuscule amount of errors
2019-05-12 20:14:44 <_ikke_> "pkgname": "GPL" ?
2019-05-12 20:14:52 <danieli> it's not valid
2019-05-12 20:14:56 <danieli> s/valid/valid spdx/
2019-05-12 20:14:56 <alpine-meetbot> danieli meant to say: it's not valid spdx
2019-05-12 20:15:14 <_ikke_> why does it say 'pkgname'?
2019-05-12 20:15:16 <danieli> oops
2019-05-12 20:15:20 <_ikke_> Each repo seems to have one
2019-05-12 20:15:31 <danieli> it wasn't supposed to save it as "pkgname", but `pkgname`
2019-05-12 20:15:35 <danieli> i.e. the variable of that name
2019-05-12 20:16:04 <danieli> wait, it does, wut
2019-05-12 20:16:23 <danieli> whaaat
2019-05-12 20:17:56 <north1> I have good news
2019-05-12 20:17:58 <north1> and bad news
2019-05-12 20:18:05 <_ikke_> danieli got a mystery on his hand
2019-05-12 20:18:07 <danieli> aaah, i see.. remind me not to drink alcohol before programming javascript again
2019-05-12 20:18:10 <danieli> :)
2019-05-12 20:18:15 <danieli> north1: give me the good news first, doctor
2019-05-12 20:18:26 <_ikke_> s/to drink alcohol// :P
2019-05-12 20:18:30 <north1> danieli: alint is getting support for finding package from steps up the ladder
2019-05-12 20:18:41 <danieli> and the bad news?
2019-05-12 20:18:49 <north1> so it can now see if a package you're working in 'main' depends on an upper step of the ladder like 'community' or 'testing'
2019-05-12 20:18:49 <danieli> do I have alcohol poisoning?
2019-05-12 20:18:53 <danieli> s/alcohol/javascript//
2019-05-12 20:18:53 <north1> bad news is that 'main' has a few fuckups
2019-05-12 20:18:53 <alpine-meetbot> danieli meant to say: do I have javascript poisoning?
2019-05-12 20:19:08 <danieli> right, that is to be expected
2019-05-12 20:19:14 <danieli> how opinionated and strict is alint?
2019-05-12 20:19:32 <north1> danieli: it is all string warnings for the user to check and fix
2019-05-12 20:24:57 <north1> if there is interest i can make it return 1 so scripts can check its return value
2019-05-12 20:25:33 <_ikke_> You already do
2019-05-12 20:26:01 <_ikke_> at least in some circumstances
2019-05-12 20:26:47 <kr0k0> _ikke_: My fail -.-
2019-05-12 20:27:30 <_ikke_> kr0k0: I disabled it for now. If you have a fix for it, it can be enabled again
2019-05-12 20:27:34 <kr0k0> Unbelievable that it builds on s390x
2019-05-12 20:28:28 <_ikke_> kr0k0: it happens :P
2019-05-12 20:28:34 <kr0k0> Yes, my problem is, that I can't test it before merge.
2019-05-12 20:29:04 <_ikke_> kr0k0: Maybe tmhoang can help
2019-05-12 20:29:32 <kr0k0> _ikke_: I'm afraid so ^^
2019-05-12 20:29:44 <kr0k0> Really?
2019-05-12 20:29:57 <kr0k0> About the ppc64le build?
2019-05-12 20:30:05 <_ikke_> oh, sorry, no not for that
2019-05-12 20:30:16 <_ikke_> rdutra should be
2019-05-12 20:30:44 <kr0k0> Ok
2019-05-12 20:31:15 <danieli> the pkgname thing was because i did `{ pkgname: value }` rather than `{ [pkgname]: value }`
2019-05-12 20:31:17 <danieli> goddamn you js
2019-05-12 20:32:21 <danieli> i can go through all the licenses it sees as invalid and fix the ones i can, then squash it
2019-05-12 20:32:38 <north1> doesn't it also need to be pkgrelbumped ?
2019-05-12 20:32:47 <danieli> for the package to be rebuilt, yes
2019-05-12 20:33:00 <danieli> but it's just the license, it's fine if it takes effect the next time it's updated imo
2019-05-12 20:33:12 <danieli> s/it's u/the license is u/
2019-05-12 20:33:12 <alpine-meetbot> danieli meant to say: but it's just the license, it's fine if it takes effect the next time the license is updated imo
2019-05-12 20:33:16 <north1> I'd rather update it now so users can see the change in their packages
2019-05-12 20:33:38 <danieli> agreed, but it hasn't been an immediate priority to fix it this far, and i don't see why it suddenly has become one
2019-05-12 20:33:40 <_ikke_> danieli: because it's part of the package metadata pkgrel should be bumped
2019-05-12 20:34:00 <danieli> right, but won't the license be applied the next time someone bumps the pkgrel?
2019-05-12 20:34:15 <danieli> oh whatever, i'll bump the pkgrels too then
2019-05-12 20:34:56 <_ikke_> danieli: maybe look at the previous mass update to fix the license
2019-05-12 20:35:26 <danieli> i don't remember when that was
2019-05-12 20:35:43 <danieli> nevermind
2019-05-12 20:35:47 <danieli> https://git.alpinelinux.org/aports/commit/?id=63f5e7d295659a855709901ce22a3e5f40fce455
2019-05-12 20:36:14 <danieli> algitbot: stop
2019-05-12 20:36:18 <_ikke_> LD
2019-05-12 20:36:20 <_ikke_> :D
2019-05-12 20:36:20 <danieli> is it going to read out the entire commit message?
2019-05-12 20:36:25 <_ikke_> yes
2019-05-12 20:36:25 <danieli> LOL
2019-05-12 20:37:02 <danieli> oh for the love of god
2019-05-12 20:37:08 <_ikke_> We got to sit it out
2019-05-12 20:37:17 <danieli> there
2019-05-12 20:39:58 <_ikke_> So no pkgrel bump
2019-05-12 20:40:49 <danieli> correct
2019-05-12 20:59:50 <north1> _ikke_: made a new release of alint
2019-05-12 21:00:25 <_ikke_> ok
2019-05-12 21:02:41 <_ikke_> pushed
2019-05-12 21:07:05 <north1> ikke: pr7844 enjoy
2019-05-12 21:09:20 <_ikke_> north1: will look at it later, thanks
2019-05-12 21:39:13 <otlabs> hi ppl
2019-05-12 21:40:40 <Cogitri> Hello, otlabs
2019-05-12 21:40:58 <otlabs> Cogitri: yo!
2019-05-12 21:43:46 <otlabs> what would be the best possible way to politely ask about the possibility to have `/usr/bin/python` in python3 package?
2019-05-12 21:44:44 <Cogitri> Why though? Scripts should use versioned python binaries anyway
2019-05-12 21:46:05 <otlabs> but some of them still want to use `/usr/bin/python`
2019-05-12 21:46:20 <north1> fix them with sed
2019-05-12 21:46:32 <Cogitri> Yup
2019-05-12 21:46:32 <otlabs> and `/usr/bin/python` is provided in python2 but not in python3
2019-05-12 21:46:57 <north1> Yes, it is painful but like with people that want #!/bin/sh to be bash we need to take a hard stance
2019-05-12 21:47:22 <north1> https://github.com/void-linux/void-packages/issues/10949
2019-05-12 21:47:28 <otlabs> ok, so if i see a use of `python` i should convert it to `python3`?
2019-05-12 21:47:48 <north1> yes, that is how alpine does. Void Linux's xbps-src has hooks to automatically do that with all binaries
2019-05-12 21:48:02 <Cogitri> Or python2 if the script is py2 specific.
2019-05-12 21:48:19 <otlabs> perfect! thank you!
2019-05-12 21:48:57 <otlabs> i would quite appreciate an example of `sed` use if possible
2019-05-12 21:50:20 <kmaxwell> I think the right advice is to use a patch not sed
2019-05-12 21:50:36 <kmaxwell> but am happy to be corrected if that is wrong advice
2019-05-12 21:50:45 <kmaxwell> will try and find an example
2019-05-12 21:51:02 <north1> kmaxwell: dyanagen, getmail
2019-05-12 21:51:06 <north1> gpsd
2019-05-12 21:51:16 <otlabs> thanks!
2019-05-12 21:51:24 <north1> 3 pacakges that uses sed
2019-05-12 21:51:42 <north1> i'd recommend a path for aports since it doesn't have a hook like xbps-src has that automatically does the conversion transparently
2019-05-12 21:51:47 <north1> s/path/patch/g
2019-05-12 21:51:47 <alpine-meetbot> north1 meant to say: i'd recommend a patch for aports since it doesn't have a hook like xbps-src has that automatically does the conversion transparently
2019-05-12 21:53:36 <otlabs> so the patch is the preferred way to fix? ok. which options recommended to use - `diff -up`?
2019-05-12 21:53:41 <kmaxwell> north1: we maybe need to agree to disagree
2019-05-12 21:53:50 <north1> kmaxwell: i declare war
2019-05-12 21:53:57 <mps> otlabs: yes. patch is preferred for packages
2019-05-12 21:54:02 <kmaxwell> gpsd uses a patch - main/gpsd/0001-workaround-for-scons-using-python2.patch
2019-05-12 21:54:36 <north1> line51 of gpsd does conversion for lots of binaries
2019-05-12 21:54:38 <kmaxwell> and sed too!
2019-05-12 21:54:43 <north1> plus the patch is for the build system
2019-05-12 21:54:47 <north1> not the final binaries
2019-05-12 21:55:27 <kmaxwell> otlabs: yes diff -up or I often use diff -urp
2019-05-12 21:55:34 <kmaxwell> to compare directory trees
2019-05-12 21:55:42 <north1> i just use git diff
2019-05-12 22:00:20 <tcely> I typically extract the source, run (git init && git add . && git ci -m 'Initial commit.') before making changes then use the output from git diff
2019-05-12 22:00:29 <otlabs> kmaxwell: thanks!
2019-05-12 22:00:51 <north1> tcely: same, i just have `ax w` for doing that :D
2019-05-12 22:01:10 <kmaxwell> north1: what's the ax command?
2019-05-12 22:01:20 <tcely> north1: is that one of the things just released ?
2019-05-12 22:01:24 <north1> kmaxwell: my own script for making working with aports convenient
2019-05-12 22:01:30 <kmaxwell> think you mentioned it earlier but haven't seen it anywhere else
2019-05-12 22:01:32 <otlabs> tcely: do you get a nice `a/somefile/... b/somefile/...` output this way?
2019-05-12 22:01:39 <north1> http://ix.io/1GTn
2019-05-12 22:01:39 <tcely> otlabs: yes
2019-05-12 22:01:53 <otlabs> cool!
2019-05-12 22:02:02 <north1> tcely: No, that is alint which is in maxice8/atools
2019-05-12 22:02:21 <kmaxwell> ahhh git status
2019-05-12 22:02:27 <north1> ax is in my dotfiles repo maxice8/meltrylis
2019-05-12 22:02:40 <kmaxwell> s/git status/now I understand :)/
2019-05-12 22:02:40 <alpine-meetbot> kmaxwell meant to say: ahhh now I understand :)
2019-05-12 22:05:32 <tcely> Heh. sorry, I forgot to expand my alias in that example. $ git ci --help
2019-05-12 22:05:32 <tcely> 'ci' is aliased to 'commit'
2019-05-12 22:05:55 <north1> i was expecting to call into the travis rubygem to see status of your CIs
2019-05-12 22:06:39 <tcely> north1: no, I've been using that one forever since RCS days
2019-05-12 22:07:14 <tcely> https://www.systutorials.com/docs/linux/man/1-ci/
2019-05-12 22:07:34 <mps> little off of the current discussion but just read this on debian lxc guide: For security reason, container images ship without user accounts and without a root password.
2019-05-12 22:07:47 <mps> so, no root password in containers
2019-05-12 22:08:09 <tcely> mps: do they mean locked or empty password though?
2019-05-12 22:08:58 <mps> lock, it seems: root:*:18028:0:99999:7:::
2019-05-12 22:10:07 <tcely> mps: good. the security reason is usually, we don't want a default password. There are enough devices on the internet that let root/root work already.
2019-05-12 22:10:43 <north1> oh lol
2019-05-12 22:10:49 <mps> yes, right
2019-05-12 22:10:50 <north1> i thought i introduced a false positive in alint
2019-05-12 22:11:04 <north1> the nature of the duplicate was even more insidious
2019-05-12 22:11:55 <north1> pr7856
2019-05-12 22:12:08 <north1> turns out py-pytoml and py-toml both had pkgname=py-toml
2019-05-12 22:56:21 <mps> https://bugs.alpinelinux.org/issues/8548 could be closed, log ago I posted curlftpfs and it is in testing
2019-05-12 22:56:50 <mps> s/log/long/
2019-05-12 22:56:50 <alpine-meetbot> mps meant to say: https://bugs.alpinelinux.org/issues/8548 could be closed, long ago I posted curlftpfs and it is in testing
2019-05-12 23:12:31 <north1> Need opinions on https://github.com/maxice8/atools/issues/1
2019-05-12 23:14:31 <SpaceToast> north1: I think it'd be better to have a pseudo-array
2019-05-12 23:14:44 <SpaceToast> E.g SKIP_TESTS="A1 A2"
2019-05-12 23:14:59 <SpaceToast> Maybe with pseudo groups landing in there as well
2019-05-12 23:15:48 <north1> then i need to have a way to quickly check a substring of a string
2019-05-12 23:16:01 <SpaceToast> Like shell?
2019-05-12 23:16:01 <north1> making sure to arch A1 but not A1[0-9]
2019-05-12 23:16:45 <SpaceToast> If you really think it needs to be quick, I could benchmark a few common POSIX methods at home
2019-05-12 23:17:03 <north1> or i can just loop at the start and set A$LOOPVAL=1
2019-05-12 23:17:06 <SpaceToast> But I don't think linters are performance critical
2019-05-12 23:17:12 <north1> anyways off to get friend on the bus station
2019-05-12 23:17:28 <north1> SpaceToast: It annoys me when they take time, i run them before commiting each package and it is the intent behind alint
2019-05-12 23:17:34 <SpaceToast> I also think tests should be named, and numbers be transient
2019-05-12 23:17:51 <SpaceToast> Aha, I'll do some benchmarks for you then, though do note that I only really use x86
2019-05-12 23:18:03 <SpaceToast> I suspect shell substitutions will be fastest
2019-05-12 23:54:58 <north1> SpaceToast: there is ${string##*$substring*} but that won't deal with matching only a full string like grep -w
2019-05-12 23:55:07 <north1> transient numbers ?
2019-05-12 23:55:31 <SpaceToast> if you need numbering, it can be generated in runtime (i.e what got selected first, if you're multithreading)
2019-05-12 23:55:59 <SpaceToast> anyway grep -w is extra, just use BRE's \b
2019-05-13 00:05:46 <north1> Also i'd like to have an explanation like this for each tag https://lintian.debian.org/tags/build-depends-on-build-essential.html
2019-05-13 00:07:29 <SpaceToast> that could be organized
2019-05-13 00:07:39 <SpaceToast> I'd like to first have the linter be working (tests and all)
2019-05-13 00:07:41 <north1> i mean
2019-05-13 00:07:48 <SpaceToast> once it's relatively stable, we can talk it over in #alpine-docs? :)
2019-05-13 00:07:54 <north1> doesn't need a page
2019-05-13 00:08:07 <north1> just an explanation following each tag so people can look up what it does
2019-05-13 00:10:00 <SpaceToast> maybe I'm missing something, but looks like no shells actually implement BRE in %/# substitution
2019-05-13 00:10:07 <SpaceToast> despite that being POSIX
2019-05-13 00:10:25 <SpaceToast> let me quickly benchmark grep regardless
2019-05-13 00:10:42 <north1> at the moment gnu grep is required
2019-05-13 00:11:43 <north1> I might write the tags and their explanation with scdoc
2019-05-13 00:11:57 <SpaceToast> no, it's really not
2019-05-13 00:12:14 <SpaceToast> echo "$1" | grep -q "\b$2\b"
2019-05-13 00:12:19 <SpaceToast> ^ this is fine with pure POSIX grep
2019-05-13 00:12:24 <north1> i mean
2019-05-13 00:12:27 <SpaceToast> assuming it's a compliant implementation, of course :)
2019-05-13 00:12:29 <north1> gnu grep is required by alint
2019-05-13 00:12:32 <north1> so if you're going to benchmark
2019-05-13 00:12:41 <north1> it doesn't matter what grep you use as long as it is gnu grep
2019-05-13 00:12:51 <SpaceToast> I do use gnu grep as the implementation on my laptop, but I'm going to require POSIX as to avoid future lockin
2019-05-13 00:13:06 <north1> any grep with -P
2019-05-13 00:13:11 <[[sroracle]]> %/# doesn't use regex
2019-05-13 00:13:14 <[[sroracle]]> it uses globs
2019-05-13 00:14:14 <SpaceToast> "In each case, pattern matching notation (see Pattern Matching Notation), rather than regular expression notation, shall be used to evaluate the patterns."
2019-05-13 00:14:34 <SpaceToast> -> section 2.13 on pattern matching talks about BRE, and then adds some exceptions
2019-05-13 00:17:59 <[[sroracle]]> it talks about BRE because it's borrowing the definiton of pattern bracket expressions ([a-z] and the like)
2019-05-13 00:18:12 <[[sroracle]]> it's not saying that it supports BREs
2019-05-13 00:18:21 <SpaceToast> ah, ok
2019-05-13 00:25:25 <SpaceToast> north1: with grep, I'm seeing ~013800000 ish nanoseconds per invocation
2019-05-13 00:25:38 <SpaceToast> (difference of date +%s.%N)
2019-05-13 00:26:05 <SpaceToast> no idea if that's actually 0.0138 seconds though
2019-05-13 00:26:26 <SpaceToast> based on `time` it looks about right
2019-05-13 00:26:43 <SpaceToast> so at ~100 tests you end up waiting approximately 1 second for all the matching
2019-05-13 00:26:54 <SpaceToast> (with grep)
2019-05-13 00:32:23 <SpaceToast> though can't really guarantee date(1) didn't introduce its own latency..
2019-05-13 00:39:48 <SpaceToast> looks like it does introduce significant delay - running 100 tests and only taking date at the start and end results in .769499074
2019-05-13 00:57:29 <north1> SpaceToast: https://i.imgur.com/QCFw9Ps.png
2019-05-13 00:58:12 <SpaceToast> aha
2019-05-13 00:58:23 <north1> take on me ?
2019-05-13 00:59:24 <SpaceToast> ?
2019-05-13 00:59:32 <north1> https://www.youtube.com/watch?v=djV11Xbc914
2019-05-13 02:20:36 <north1> alint takes about 20 seconds to run over community/
2019-05-13 02:26:23 <north1> and 15 with lots of &
2019-05-13 04:59:31 <_ikke_> kr0k0: now vdr failed on s390x as well..
2019-05-13 06:58:03 <telmich> moin moin
2019-05-13 06:59:13 <telmich> who is currently in charge for killing spam? and/or if you are still looking for someone who will kill comments/tickets on a best-effort basis ("when I spot it"), I might be volunteering
2019-05-13 06:59:23 <telmich> background: redmine comment spam
2019-05-13 06:59:27 <Cogitri> Hello
2019-05-13 07:00:30 <clandmeter> telmich: i think this is an infra thing?
2019-05-13 07:01:10 <telmich> clandmeter: ok
2019-05-13 08:55:06 <tmhoang_> Hi fcolista, I think community/openvas-scanner/openvassd.conf has wrong checksum in APKBUILD
2019-05-13 08:55:32 <fcolista> tmhoang_, someone modified it?
2019-05-13 08:55:48 <tmhoang_> you commited the latest :D
2019-05-13 08:56:07 <fcolista> WHen I committed, it built ;-)
2019-05-13 08:56:40 <fcolista> let me check
2019-05-13 08:57:46 <fcolista> It was on April 8 last commit, and openvassd.conf was not touched
2019-05-13 08:58:56 <fcolista> ok
2019-05-13 08:59:23 <fcolista> last opevassd.conf was updated with a755f3a0396871ad5fe7994b050e7cac60f2f1fd
2019-05-13 09:00:06 <fcolista> but no APKBUILD update after that day
2019-05-13 09:00:16 <fcolista> now, due to rebuild of 3.10, the issue came up
2019-05-13 09:06:45 <kr0k0> Hi all
2019-05-13 09:07:06 <Cogitri> Hello there, kr0k0
2019-05-13 09:08:33 <clandmeter> is Stuart Cardall here? or anybody knows his irc nick?
2019-05-13 09:09:20 <_ikke_> itoffshore is his github name, but apparently not present here
2019-05-13 09:09:24 <kr0k0> _ikke_: I'm working on a fix. Please revert merge, if build fails again.
2019-05-13 09:09:55 <Cogitri> I think it's easier to just disable the failing arches
2019-05-13 09:11:49 <kr0k0> Cogitri: Yes, but it has to build successfully on all archs^^
2019-05-13 09:11:53 <clandmeter> _ikke_: i think he uses a diff nickname here, i just dont remember
2019-05-13 09:12:33 <kr0k0> Cogitri: The only real problem is, that I can't test s390x and ppc64le before merge...
2019-05-13 09:13:36 <Cogitri> Yes :c
2019-05-13 09:17:17 <_ikke_> tmhoang_: are you able to help kr0k0 with testing a patch on s390x?
2019-05-13 09:17:34 <tmhoang_> _ikke_, kr0k0: yes
2019-05-13 09:22:13 <kmaxwell> _ikke_: could you please check the labels on pr7859 when you get a minute?
2019-05-13 09:22:42 <kmaxwell> it definitely shouldn't be waiting for feedback now and IMO wasn't before
2019-05-13 09:23:22 <_ikke_> Updated
2019-05-13 09:24:16 <kmaxwell> _ikke_: ty! :)
2019-05-13 09:25:11 <_ikke_> I'm going through a lot of PRs, so I don't have always time to extensively judge the situation
2019-05-13 09:28:52 <kmaxwell> I get it, we're all short of time, I appreciate your help
2019-05-13 09:29:17 <kmaxwell> my role atm is to make it as simple as possible for committers to pick up my changes
2019-05-13 09:29:53 <_ikke_> kmaxwell: did you notice atools in testing?
2019-05-13 09:30:01 <kmaxwell> I should maybe have just packaged the older version as soon as andypost mentioned it
2019-05-13 09:30:22 <_ikke_> Some situations are not that clear on how to properly solve it
2019-05-13 09:32:31 <kmaxwell> _ikke_: atools hadn't realised tools is in testing, ty! going to try it out
2019-05-13 09:38:57 <kr0k0> tmhoang: Thanks! Shall I create a new pull request for the test or other way?
2019-05-13 09:42:07 <kmaxwell> trying out alint, it shows two warnings multiple times on my user aports
2019-05-13 09:42:57 <kmaxwell> are cd $builddir and setting builddir to the default definitely not required any more?
2019-05-13 09:43:38 <Cogitri> Not in community and testing, yes
2019-05-13 09:43:51 <Cogitri> In main at least the former is required
2019-05-13 09:46:50 <kmaxwell> thanks, thought we were keeping the cd lines in main for now
2019-05-13 09:47:30 <_ikke_> Cogitri: fyi, it's not required in main for new aports
2019-05-13 09:47:38 <_ikke_> We should just not remove them from existing aports
2019-05-13 09:48:13 <clandmeter> new aports dont need backporting which would break build on older releases.
2019-05-13 09:58:42 <andypost[m]> I got a question about pr7809 - looks php never linked statically so maybe better just rm *.a
2019-05-13 09:59:05 <kmaxwell> so to double check, should a PR on a package in community remove cd $builddir?
2019-05-13 10:00:16 <_ikke_> kmaxwell: for new aports, I would recommend removing / not adding them. For updating existing aports, it depends a bit on the reviewer / maintinaer
2019-05-13 10:00:18 <_ikke_> maintainer*
2019-05-13 10:06:28 <kmaxwell> super, I understand, thanks
2019-05-13 10:28:03 <tmhoang> kr0k0: either creating a pr (marked as 'work in progress' ?) or paste here is fine
2019-05-13 10:32:52 <kr0k0> tmhoang: Ok, thanks!  I inform you when the patch is ready.
2019-05-13 10:32:58 <tmhoang> o/
2019-05-13 10:35:30 <danieli> lol
2019-05-13 10:35:37 <danieli> it's spam @ Cogitri ^
2019-05-13 10:36:07 <tmhoang> asking serious questions
2019-05-13 10:38:38 <_ikke_> kmaxwell: the comment about no tests in artificact for py3-ansicolor, is that a remnant?
2019-05-13 10:38:58 <_ikke_> kmaxwell: https://github.com/alpinelinux/aports/pull/7859/files#diff-3b52794928eb2a018841b4b4d1515148R13
2019-05-13 10:40:06 <kmaxwell> no it is deliberate, let me explain in case it could be clearer
2019-05-13 10:40:21 <kmaxwell> if you download the tarball from PyPI the test suite is not included
2019-05-13 10:40:27 <_ikke_> ah ok
2019-05-13 10:40:47 <_ikke_> right
2019-05-13 10:40:57 <kmaxwell> if you download a tarball from GH it includes the tests, idea was to explain to reviewer that there was a reason to use GH not PyPI
2019-05-13 10:41:28 <kmaxwell> is there wording that would make that point more clearly?
2019-05-13 10:42:04 <_ikke_> I missed the pypi part of the message
2019-05-13 10:42:16 <_ikke_> I moved the comment above the line so that it does not wrap
2019-05-13 10:43:06 <Cogitri> Thanks, danieli, deleted it
2019-05-13 10:53:27 <kmaxwell> _ikke_: ty!
2019-05-13 10:53:57 <_ikke_> np
2019-05-13 10:56:25 <tmhoang> _ikke_ : seems wireshark is ok on s390x. I think we must have missed some deps for building wireshark in APKBUILD
2019-05-13 10:56:50 <_ikke_> tmhoang: Ah ok, so we just need to add dependencies?
2019-05-13 10:56:51 <tmhoang> too bad the old log was overwritten so I cannot compare
2019-05-13 10:57:05 <_ikke_> tmhoang: I included them in the wireshark issues
2019-05-13 10:57:15 <_ikke_> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15772
2019-05-13 10:57:20 <_ikke_> the tpaste link
2019-05-13 10:57:23 <tmhoang> that's my guess because in the next abuild round, some packages/deps are built.
2019-05-13 10:57:25 <tmhoang> ah
2019-05-13 10:57:30 <tmhoang> right
2019-05-13 10:57:33 <tmhoang> i have it opened here
2019-05-13 11:17:37 <tmhoang> when folks move packages from testing to community, do you use $ mv testing/pkgname community/pkgname or use $ git mv ?
2019-05-13 11:18:40 <tmhoang> ok it seems git mv was used, but cgit marked it as creating new files ?
2019-05-13 11:18:48 <tmhoang> --- /dev/null
2019-05-13 11:18:48 <tmhoang> +++ b/community/vdr/APKBUILD
2019-05-13 11:19:12 <_ikke_> I use git mv, but that's just a macro
2019-05-13 11:19:17 <_ikke_> git does not store that files are moved
2019-05-13 11:23:05 <tmhoang> point is, git mv will save the history of the file instead
2019-05-13 11:23:28 <tmhoang> iiuc
2019-05-13 11:23:39 <_ikke_> git mv == mv $src $dst; git rm --cached $srd; git add $dst;
2019-05-13 11:23:41 <_ikke_> nothing more
2019-05-13 11:24:25 <tmhoang> I trust you
2019-05-13 11:24:38 <_ikke_> git can show file renames by tracking content
2019-05-13 12:25:17 <tmhoang> _ikke_: would you mind having a look at 3 top PR in community/ that's breaking so I could see if something else is broken: https://github.com/alpinelinux/aports/pulls/tuan-hoang1
2019-05-13 12:45:16 <clandmeter> hmm, do we have some rule to not allow sourcing other apkbuilds anymore?
2019-05-13 12:45:58 <_ikke_> tmhoang: I can look at it later
2019-05-13 12:48:32 <clandmeter> hmm, do we have some rule to not allow sourcing other apkbuilds anymore?
2019-05-13 12:48:48 <_ikke_> echo
2019-05-13 12:49:02 <clandmeter> heh
2019-05-13 12:49:17 <clandmeter> sorry, too many chat windows open
2019-05-13 12:49:33 <clandmeter> or i just want to get extra attention
2019-05-13 12:50:12 <tmhoang> here take it
2019-05-13 12:50:32 <clandmeter> thanks
2019-05-13 12:50:42 <danieli> clandmeter: you got it
2019-05-13 12:51:00 <clandmeter> 
ACTION will echo for eternity

2019-05-13 12:51:06 <clandmeter> 
ACTION will echo for eternity

2019-05-13 13:05:21 <_ikke_> tmhoang: did you already confirm it were dependency issues that caused the tests to fail?
2019-05-13 13:05:58 <_ikke_> (wireshark)
2019-05-13 13:57:42 <north1> _ikke_: ncopa asked me to keep them on main, alint doesn't do cd-builddir checks if they are in packages in main
2019-05-13 13:58:32 <_ikke_> north1: yes, that's ok
2019-05-13 13:58:55 <_ikke_> It has mainly to do with having to backport fixes to older releases where abuild is older and doesn't to the cd itself yet
2019-05-13 13:59:29 <north1> I think a build v3.3.0 added it
2019-05-13 14:00:05 <_ikke_> So 3.8 and older don't have it
2019-05-13 14:00:13 <north1> I was looking into cd-builddir and default builddir-value while writing about their lints
2019-05-13 14:00:46 <_ikke_> I made a mistake in my merged pr for newapkbuild btw
2019-05-13 14:01:03 <_ikke_> I removed the cd statements, but that rendered the function empty, which is invalid in sh
2019-05-13 14:01:12 <north1> I made a mistake and my notebook is on repairs :D
2019-05-13 14:01:19 <_ikke_> auch
2019-05-13 14:02:28 <north1> To clarify. Are you German?
2019-05-13 14:02:40 <_ikke_> nope
2019-05-13 14:02:42 <_ikke_> dutch
2019-05-13 14:03:06 <north1> Basically the same thing
2019-05-13 14:03:17 <clandmeter> owjee
2019-05-13 14:03:22 <_ikke_> :D
2019-05-13 14:03:29 <_ikke_> See what you did now
2019-05-13 14:03:43 <danieli> .. that's brash
2019-05-13 14:04:02 <danieli> er, brash might be a poor choice of words
2019-05-13 14:04:18 <danieli> whatever, i'm not a native english speaker either :)
2019-05-13 14:04:39 <danieli> north1: are you american, by any chance?
2019-05-13 14:04:49 <north1> danieli: yes I am American
2019-05-13 14:05:01 <danieli> 'basically the same thing' outed you :P
2019-05-13 14:05:14 <clandmeter> is that a part of canada?
2019-05-13 14:05:23 <SpaceToast> yeah, it's our southernmost province
2019-05-13 14:05:24 <danieli> i think they're the canadians with guns and stuff
2019-05-13 14:05:29 <SpaceToast> never signed the constitution though
2019-05-13 14:05:30 <danieli> the angry ones
2019-05-13 14:05:37 <SpaceToast> morning \o
2019-05-13 14:06:06 <north1> clandmeter: no, Canada is on the top of America I'm more on the southernmost parts of America
2019-05-13 14:06:17 <clandmeter> guten Morgen
2019-05-13 14:06:45 <TBB> now that's an interesting description, angry canadians
2019-05-13 14:07:32 <clandmeter> north1: that part that belongs to mexico?
2019-05-13 14:07:34 <danieli> i usually call canadians the unarmed americans but thought i'd flip the tables today
2019-05-13 14:07:51 <danieli> man, this got *really* off topic :P
2019-05-13 14:07:59 <clandmeter> :)
2019-05-13 14:08:07 <north1> clandmeter: no, even more south
2019-05-13 14:08:10 <SpaceToast> hey, if no one's hurt, and everyone enjoys it... right? :)
2019-05-13 14:11:34 <otlabs> hi ppl
2019-05-13 14:11:59 <p4Wv1qn095FW> north1: you're from chile?
2019-05-13 14:12:25 <north1> p4Wv1qn095FW: close, one argentina east, continue on offtopic
2019-05-13 14:12:56 <otlabs> does apkbuild-pypi is generally available? i saw info about it in wiki
2019-05-13 14:13:50 <danieli> what do you mean by 'generally available'?
2019-05-13 14:14:16 <danieli> it's in abuild if that's what you mean
2019-05-13 14:14:17 <otlabs> i mean i am unable to find it in any package
2019-05-13 14:14:31 <danieli> hmm, let's see
2019-05-13 14:14:49 <danieli> you're right, i'm not seeing a package for it
2019-05-13 14:16:22 <danieli> you could grab it from here https://github.com/alpinelinux/abuild/blob/master/apkbuild-pypi.in
2019-05-13 14:16:41 <_ikke_> so it's part of abuild
2019-05-13 14:17:07 <_ikke_> But maybe not released yet
2019-05-13 14:17:10 <danieli> yes, but in abuild's own APKBUILD it packages apkbuild-cpan and apkbuild-gem-resolver into separate packages
2019-05-13 14:17:14 <danieli> it does not do that for apkbuild-pypi
2019-05-13 14:17:32 <danieli> that file hasn't been touched since 2017
2019-05-13 14:17:38 <_ikke_> I just noticed
2019-05-13 14:18:29 <tmhoang> _ikke_ : i have not had time to look into wireshark again
2019-05-13 14:19:39 <otlabs> danieli: thanks! i will try it as it a recommended way to create packages from PyPi
2019-05-13 14:19:54 <tmhoang> are we still talking about countries because I have a joke about it
2019-05-13 14:20:33 <north1> tmhoang: on offtopic
2019-05-13 14:45:57 <mps> anyone experience issue with llvm5 or llvm6 on edge or 3.10? It can't build package which is built quite fine about week ago
2019-05-13 14:47:56 <mps> or, how to see diff after pkg is moved from main to community, diff between main -> community for package
2019-05-13 14:54:00 <SpaceToast> mps: building brpaste (using out-of-aports ldc2, which links to llvm5) still works just fine
2019-05-13 14:54:04 <SpaceToast> just re-tested it for you :)
2019-05-13 14:54:53 <mps> SpaceToast: thanks, I don't have such luck with crystal
2019-05-13 14:55:12 <SpaceToast> llvm5 is quite old :(
2019-05-13 14:55:34 <SpaceToast> I'll try and look into gcc9 + gdc (for dlang) once 3.10 is out
2019-05-13 14:55:53 <mps> true, but crystal on alpine can only build with it
2019-05-13 14:56:00 <danieli> i'll look into getting my mercury and swi-prolog aports done
2019-05-13 14:56:41 <mps> and llvm3.9 is still in Alpine
2019-05-13 14:56:49 <SpaceToast> I really hope rust 1.35 makes it easier to work with/in alpine
2019-05-13 14:56:59 <SpaceToast> there were some issues that seemed indicative of that direction
2019-05-13 14:57:47 <mps> SpaceToast: I'm losing hope with all llvm incompatibilities between versions
2019-05-13 14:58:07 <SpaceToast> I'm pretty sure that as of llvm4 those are intentional, to some degree
2019-05-13 14:58:18 <SpaceToast> http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
2019-05-13 14:58:53 <mps> I'm starting to prefer gcc
2019-05-13 14:59:14 <SpaceToast> I wouldn't really have any issues with that approach if the releases were bigger, rather than timed
2019-05-13 14:59:21 <SpaceToast> as is it's just a timebomb thing
2019-05-13 14:59:51 <SpaceToast> gcc has its own issues :/ I do still like llvm, but I wish they got their act together in this regard
2019-05-13 15:00:13 <mps> we are dreaming
2019-05-13 15:25:45 <_ikke_> https://ftp.defora.org certificate expired, which is the source for makepasswd
2019-05-13 15:28:35 <mps> _ikke_: yes, this is discussed few days ago. no one contacted them?
2019-05-13 15:29:36 <_ikke_> No clue
2019-05-13 15:31:03 <mps> I think someone (ncopa?) told that he will try to contact them but not sure
2019-05-13 15:31:43 <mps> I looked their site but it looks like as it is abandoned
2019-05-13 15:31:54 <p4Wv1qn095FW> i can contact the owner directly
2019-05-13 15:32:38 <_ikke_> p4Wv1qn095FW: Would be nice
2019-05-13 15:32:41 <mps> p4Wv1qn095FW: good, feel free
2019-05-13 15:32:53 <p4Wv1qn095FW> done
2019-05-13 15:33:07 <_ikke_> \o/
2019-05-13 15:33:23 <north1> Algitbot likes to celebrate
2019-05-13 15:33:30 <_ikke_> mps: I gather you are working on getting crystal building?
2019-05-13 15:33:57 <mps> yes, I think I found solution to llvm5 issue
2019-05-13 15:34:05 <_ikke_> ok, nice
2019-05-13 15:34:31 <mps> will see in a few hours, it is single threaded and needs time
2019-05-13 15:34:39 <_ikke_> yay
2019-05-13 15:34:48 <_ikke_> lmk when you have a fix
2019-05-13 15:35:22 <mps> np, and I will ask on their channel if my fix is/will be ok
2019-05-13 15:36:18 <mps> maybe I will try with llvm6 also
2019-05-13 16:00:07 <Cogitri> SpaceToast: It's not really going to become easier because we use our custom triplet
2019-05-13 16:00:31 <Cogitri> But first I need LLVM8 and Rust 1.32 merged anyway
2019-05-13 16:00:41 <Cogitri> So that'll take a while, I guess
2019-05-13 16:00:58 <SpaceToast> at least one of my packages (not in tree yet) needs rust 1.34 :(
2019-05-13 16:01:27 <north1> ripgrep?
2019-05-13 16:01:46 <SpaceToast> yeah
2019-05-13 16:02:00 <SpaceToast> I have it packaged and all in my personal repo, but 11 came out and reqs 1.34
2019-05-13 16:02:09 <north1> I tried updating it as well
2019-05-13 16:02:11 <SpaceToast> I was going to try to get it into testing not that long ago either
2019-05-13 16:02:23 <SpaceToast> oh, apparently someone else got it in
2019-05-13 16:02:25 <SpaceToast> oh well Β―\_(ツ)_/Β―
2019-05-13 16:02:32 <north1> And someone else too since there is a draft PR for it
2019-05-13 16:02:32 <mps> iirc, I've built ripgrep few months ago with rust 1.31
2019-05-13 16:02:40 <SpaceToast> yeah, from my repo :)
2019-05-13 16:02:48 <SpaceToast> it's been updated since
2019-05-13 16:02:50 <mps> SpaceToast: I think so
2019-05-13 16:02:51 <SpaceToast> version 11 came out
2019-05-13 16:02:57 <SpaceToast> and requires 1.34 now
2019-05-13 16:03:00 <Cogitri> mps: Yes. But not the latest version
2019-05-13 16:03:03 <otlabs> i am getting following error from python program: "OS does not have SIGALRM". is that correct?
2019-05-13 16:03:41 <mps> ah, we always all new batteries
2019-05-13 16:04:03 <mps> s/ all/ need all/
2019-05-13 16:04:03 <alpine-meetbot> mps meant to say: ah, we always need all new batteries
2019-05-13 16:05:05 <mps> does that means the rust still not have stable version
2019-05-13 16:05:08 <SpaceToast> speaking of, I should probably make a few PRs for the rest of the stuff lying around in my personal repo
2019-05-13 16:05:23 <SpaceToast> but it feels kinda bad doing it while 3.10 is getting ready
2019-05-13 16:05:53 <Cogitri> mps: It's stable, but it still adds new API in new releases
2019-05-13 16:06:08 <Cogitri> So if you need that new API you need a new compiler
2019-05-13 16:06:21 <Cogitri> (Well, the ABI isn't stable yet either)
2019-05-13 16:06:39 <mps> so, it is not stable, imo
2019-05-13 16:07:20 <Cogitri> It's not necessarily backwards compatible, yes
2019-05-13 17:24:54 <_ikke_> geany-plugins is failing on x86 with: mv: can't rename '/home/buildozer/aports/community/geany-plugins/pkg/geany-plugins/usr/lib/geany/geanypy.so': No such file or directory
2019-05-13 17:25:11 <_ikke_> I also see this in the log: checking whether the GTK version in use is compatible with plugin Geanypy... no
2019-05-13 17:26:38 <_ikke_> Anyone got an idea?
2019-05-13 17:27:10 <_ikke_> Hmm the last message is the same on x86_64
2019-05-13 17:27:29 <north1> Was geany updated together with the plugins package?
2019-05-13 17:27:45 <_ikke_> No idea
2019-05-13 17:27:59 <north1> Might be mismatched versions
2019-05-13 17:28:13 <_ikke_> ok
2019-05-13 17:28:24 <_ikke_> I just noticed that x86_64 failed with the same error
2019-05-13 17:29:52 <tcely> Regarding apkbuild-pypi: it wasn't listed in the Makefile https://github.com/alpinelinux/abuild/pull/83
2019-05-13 17:30:47 <tcely> Regarding makepasswd: the fixes for abuild-fetch (allowing to ignore TLS errors) need to be included in the next release
2019-05-13 17:40:55 <_ikke_> 
ACTION is manually building ghc on the x86_64 repo right now (on ncopa's instructions) to bootstrap it

2019-05-13 17:41:02 <_ikke_> s/repo/builder
2019-05-13 17:41:02 <alpine-meetbot> _ikke_ meant to say: is manually building ghc on the x86_64 builder right now (on ncopa's instructions) to bootstrap it
2019-05-13 17:42:13 <tcely> _ikke_: do the builder run containers?
2019-05-13 17:42:25 <_ikke_> yes, lxc containers
2019-05-13 17:42:48 <tcely> so the manual build of ghc can happen concurrent to normal building then?
2019-05-13 17:43:01 <_ikke_> No, the builder *is* the container
2019-05-13 17:43:08 <_ikke_> but it was stuck on ghc anyway
2019-05-13 17:43:21 <tcely> Ah
2019-05-13 17:43:46 <_ikke_> So I disabled mqtt-exec so no new builds will be triggered
2019-05-13 18:06:20 <_ikke_> andypost[m]: Any progress in fixing corebird?
2019-05-13 18:06:29 <iggy> is there a way in the license field to say "it's complicated, see URL"?
2019-05-13 18:07:23 <_ikke_> "custom" + including in the package?
2019-05-13 18:07:31 <_ikke_> in what way is it complicated?
2019-05-13 18:07:48 <north1> iggy: custom
2019-05-13 18:08:19 <iggy> there are individual files in the git repo that have a number of different licenses (copied in headers/source, etc)
2019-05-13 18:08:40 <_ikke_> how many different licenses?
2019-05-13 18:09:05 <iggy> at least 17 that I see
2019-05-13 18:09:11 <_ikke_> wow
2019-05-13 18:09:36 <north1> Well you can string them together with AND
2019-05-13 18:09:41 <iggy> maybe more if you count the "only"/"or-later" ones
2019-05-13 18:17:54 <ddevault> ERROR: git-2.21.0-r2: failed to rename /.apk.0a582b6c092627ca31aa82cd454854d44c1fd5a325550d07 to core.
2019-05-13 18:17:57 <ddevault> any idea what might cause this?
2019-05-13 18:18:52 <tmhoang> _ikke_ : would you mind removing community/corebird ? It's dead upstream
2019-05-13 18:20:58 <tmhoang> it's dead upstream since last year
2019-05-13 18:21:21 <_ikke_> Ok
2019-05-13 18:21:44 <_ikke_> Waiting for ghc to complete
2019-05-13 18:22:04 <_ikke_> tmhoang: Can you help later with bootstrapping ghc on s390x?
2019-05-13 18:22:12 <_ikke_> hmm, not sure if it's even available
2019-05-13 18:22:20 <_ikke_> it's only x86_64 now
2019-05-13 18:22:21 <tmhoang> afaik it's wip
2019-05-13 18:22:24 <tmhoang> yes
2019-05-13 18:22:32 <andypost[m]> @ikke in pr7840 I just added patch to pass build, fid not check results
2019-05-13 18:23:17 <tmhoang> no strong argument here, but if it's meant to be dead, god will it
2019-05-13 18:25:24 <andypost[m]> It needs fcolista to mention
2019-05-13 18:33:47 <tmhoang> haven't seen ncopa for a while
2019-05-13 18:33:59 <SpaceToast> he's on vacation
2019-05-13 18:34:04 <tmhoang> ah
2019-05-13 18:34:37 <tmhoang> it's perfect time to break stuffs haah
2019-05-13 18:39:14 <ddevault> yeah it seems that the latest update to the git package broke things
2019-05-13 18:39:35 <ddevault> the timing is suspicious
2019-05-13 18:41:06 <ddevault> there's a coredump in it XD
2019-05-13 18:41:13 <ddevault> can someone rebuild that?
2019-05-13 18:41:58 <ddevault> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/git/git-2.21.0-r2.log
2019-05-13 18:42:07 <ddevault> >>> git*: Stripping binaries
2019-05-13 18:42:09 <ddevault> Bus error (core dumped)
2019-05-13 18:47:39 <_ikke_> Should I bootstrap rust the same way?
2019-05-13 18:47:43 <_ikke_> ghc is done
2019-05-13 18:47:56 <_ikke_> install rust from edge, build rust?
2019-05-13 18:49:18 <tcely> _ikke_: sounds reasonable to me
2019-05-13 18:50:14 <_ikke_> Needed cargo as well
2019-05-13 18:51:58 <_ikke_> building rust now on x86_64
2019-05-13 18:52:10 <mps> _ikke_: in my tries I do this, i.e. install rust and cargo manually
2019-05-13 18:52:30 <_ikke_> Yes, that's how other things are bootstrapped as well
2019-05-13 18:52:33 <_ikke_> I just built ghc
2019-05-13 18:54:47 <ddevault> _ikke_: I think the onus falls on you for kicking off a git rebuild, given you're the only one with a hat on
2019-05-13 18:55:47 <_ikke_> yay
2019-05-13 18:56:11 <_ikke_> Bus error..
2019-05-13 18:56:28 <ddevault> I can't reproduce when building the git package locally, so maybe it's a fluke?
2019-05-13 18:56:44 <_ikke_> ddevault: the builder is now working on rust
2019-05-13 18:56:53 <ddevault> whelp, see you next week
2019-05-13 18:56:55 <_ikke_> Oh no, that's 3.10 builder, not edge builder
2019-05-13 18:57:00 <ddevault> phew
2019-05-13 18:58:19 <_ikke_> hmm, strange, it does not say git failed
2019-05-13 18:59:49 <_ikke_> So it failed during stripping, but the build succeeded
2019-05-13 19:00:04 <_ikke_> So to rebuild, we'd need to bump it
2019-05-13 19:01:18 <ddevault> I'm guessing scanelf was the source of the bus error
2019-05-13 19:01:25 <ddevault> yes
2019-05-13 19:01:36 <_ikke_> What can cause a bus error?
2019-05-13 19:01:44 <ddevault> black magic
2019-05-13 19:01:52 <ddevault> unaligned pointer dereferences
2019-05-13 19:01:54 <tcely> heh
2019-05-13 19:01:55 <ddevault> other forms of black magic
2019-05-13 19:02:13 <SpaceToast> hardware failures could do it
2019-05-13 19:02:23 <SpaceToast> e.g a physical address that your os thinks is there... but isn't
2019-05-13 19:02:30 <SpaceToast> or a virtual page disappearing
2019-05-13 19:02:32 <ddevault> failed disk could also be the culprit
2019-05-13 19:02:42 <_ikke_>  Building [==============================================>         ] 94/112: rustc
2019-05-13 19:02:45 <_ikke_> It seems to hang there
2019-05-13 19:02:54 <ddevault> are these separate builders or the same guy
2019-05-13 19:02:59 <ddevault> I might SSH into it and check the dmesg
2019-05-13 19:04:15 <_ikke_> ah, it's continuing
2019-05-13 19:04:17 <SpaceToast> our builders are packet's, right?
2019-05-13 19:04:23 <SpaceToast> rustc takes a while to build :)
2019-05-13 19:04:32 <ddevault> I wouldn't jump to hardware failure unless there are other symptoms
2019-05-13 19:04:34 <mps> I just had signall 11 building crystal snapshot
2019-05-13 19:04:47 <_ikke_> SpaceToast: No, we have different hardware for the builders
2019-05-13 19:04:49 <SpaceToast> yeah, probably an unaligned pointer within scanelf
2019-05-13 19:04:53 <SpaceToast> ah, I see
2019-05-13 19:05:10 <ddevault> hm, what's signal 11
2019-05-13 19:05:23 <_ikke_> isn't that segfault?
2019-05-13 19:05:23 <ddevault> oh, segfault
2019-05-13 19:05:24 <SpaceToast> segfault
2019-05-13 19:05:25 <ddevault> dur
2019-05-13 19:05:26 <mps> Invalid memory access (signal 11) at address 0xfff4cb507da8
2019-05-13 19:05:42 <_ikke_> ok, let me bump git
2019-05-13 19:05:45 <ddevault> ty
2019-05-13 19:06:03 <_ikke_> oh, it's in main, no dice :)
2019-05-13 19:06:04 <mps> it happens from time to time
2019-05-13 19:06:19 <ddevault> gah
2019-05-13 19:06:29 <_ikke_> clandmeter or fcolista need to do it (or someone else with main access)
2019-05-13 19:07:30 <_ikke_> I have that version of git on my container and it works without issue
2019-05-13 19:07:50 <ddevault> yeah, but you also have a core dump installed to /core
2019-05-13 19:08:21 <_ikke_> Interesting
2019-05-13 19:08:23 <_ikke_> I see
2019-05-13 19:08:29 <SpaceToast> not sure how the builders work, but couldn't you `abuild cleanpkg && abuild -r` or something similar by hand?
2019-05-13 19:08:42 <ddevault> I think only new installations of git are affected
2019-05-13 19:08:46 <ddevault> upgrades work
2019-05-13 19:09:32 <_ikke_> SpaceToast: it also needs to be uploaded
2019-05-13 19:09:40 <_ikke_> Not entirely sure how that works
2019-05-13 19:09:45 <SpaceToast> mhm
2019-05-13 19:10:00 <SpaceToast> my builder just has a shared volume with my web server
2019-05-13 19:10:24 <_ikke_> You just have a single builder (I guess)
2019-05-13 19:10:52 <SpaceToast> well, I could do the same with 2 builders too
2019-05-13 19:10:56 <_ikke_> The alpine builders push the packages to a single master server, where the mirrors pick it up
2019-05-13 19:11:01 <SpaceToast> but they'd all be restricted to a single arch
2019-05-13 19:11:24 <SpaceToast> if I had to setup multiarch I'd probably do that per-arch and have an rproxy handle pathing
2019-05-13 19:11:32 <_ikke_> builder -> master.a.o -> t1-mirrors -> other mirrors
2019-05-13 19:11:48 <_ikke_> where the builders are geographically disperse
2019-05-13 19:11:53 <SpaceToast> aha
2019-05-13 19:17:28 <_ikke_> How many stages does rust build in?
2019-05-13 19:18:03 <tcely> I believe no less than two, but as many as four depending last I looked
2019-05-13 19:18:27 <north1> From 0 to 3?
2019-05-13 19:18:32 <_ikke_> It's now at stage1
2019-05-13 19:19:32 <kr0k0> Hi
2019-05-13 19:19:36 <_ikke_> o/
2019-05-13 19:20:27 <kr0k0> Can you tell me what is wrong with drone-ci on pr7868?
2019-05-13 19:20:59 <_ikke_> kr0k0: You might've missed it, but tmhoang already fixed it
2019-05-13 19:22:23 <_ikke_> https://git.alpinelinux.org/aports/commit/community/vdr/APKBUILD?id=84574037322b7f78cdcc0b7f8944e7f65fa580df
2019-05-13 19:23:22 <tmhoang> sorry
2019-05-13 19:23:55 <tcely> kr0k0: that drone error is usually because you need to rebase against master
2019-05-13 19:24:56 <tcely> I would very much like to not use git am and just fetch the pr/NNNN/merge branch like TravisCI does
2019-05-13 19:25:03 <tcely> clandmeter: does that git am use -3 ?
2019-05-13 19:25:17 <_ikke_> tcely: I suspect it doesn't
2019-05-13 19:27:06 <ddevault> so in the interest of not letting this line of thought die
2019-05-13 19:27:09 <ddevault> I'm gonna file a bug for git
2019-05-13 19:29:31 <tcely> kr0k0: you might also want to file an issue about that drone error you saw
2019-05-13 19:31:01 <_ikke_> stage2 now
2019-05-13 19:33:04 <kr0k0> _ikke_: Fail..
2019-05-13 19:33:10 <kr0k0> ^^
2019-05-13 19:33:26 <kr0k0> My rebase was some hours ago
2019-05-13 19:33:56 <_ikke_> I comitted it 4 hours ago
2019-05-13 19:34:36 <kr0k0> _ikke_ and tcely: Thanks for info, I close my pr.
2019-05-13 19:38:43 <kr0k0> tmhoang: np ^^
2019-05-13 19:44:51 <tcely> TIL I can clone / push gists
2019-05-13 19:44:51 <tcely> [url "git@gist.github.com:"]
2019-05-13 19:44:51 <tcely>         pushInsteadOf = https://gist.github.com/tcely/
2019-05-13 19:46:10 <tcely> If anyone knows PPC assembly better than me I could use some help getting ppc64le LuaJIT conflicts resolved properly
2019-05-13 19:46:14 <tcely> https://gist.github.com/tcely/5b9a145cedfd5ed60ebf15b1d85fb97b
2019-05-13 19:47:19 <tcely> Only 53 conflict markers left in that file according to my browser ;-)
2019-05-13 19:47:46 <tcely> It's the only file left to fix the patch too.
2019-05-13 19:49:16 <_ikke_> Rust done
2019-05-13 19:49:59 <tmhoang> qt5-qtwebkit build log is 7 mil lines @@
2019-05-13 19:50:04 <tmhoang> nice o/
2019-05-13 20:04:46 <SpaceToast> _ikke_: nice! \o/
2019-05-13 20:05:17 <SpaceToast> meanwhile, I have now verified that docker-abuild fails horribly with docker's -H/tcp mode :(
2019-05-13 20:05:23 <SpaceToast> (because volumes)
2019-05-13 20:07:01 <tcely> SpaceToast: Were you expecting host volumes from the docker client?
2019-05-13 20:07:31 <SpaceToast> I was expecting client-to-container (on host) volumes to work
2019-05-13 20:07:37 <SpaceToast> well, rather, I hoped it'd be smart enough
2019-05-13 20:07:47 <SpaceToast> somehow, it created a partial directory structure, but no files etc
2019-05-13 20:07:52 <andypost[m]> SpaceToast which one? And what's wrong with volumes?
2019-05-13 20:08:06 <SpaceToast> andypost[m]: don't worry about it, atypical use-case
2019-05-13 20:08:12 <_ikke_> Fun that each arch has a different package that failed
2019-05-13 20:08:48 <SpaceToast> basically I have a big fat compute/storage host (sauron, runs lxd and most of my infra), but I don't directly dev on it
2019-05-13 20:09:05 <SpaceToast> so I ran docker -H tcp://stuff on it, and DOCKER_HOST=tcp://sauron on my laptop to see if I could use dabuild that way
2019-05-13 20:09:18 <SpaceToast> (it's entirely possible to do stuff like that in theory, not trivial, but possible)
2019-05-13 20:09:38 <SpaceToast> unfortunately, docker doesn't handle that scenario (e.g -v client_dir:container_on_host_dir)
2019-05-13 20:11:17 <SpaceToast> could probably massage it into working using custom storage drivers and patching dabuild a bunch but it's just not worth the effort at that point
2019-05-13 20:11:57 <_ikke_> tmhoang: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15772
2019-05-13 20:13:02 <mps> _ikke_: finished with crystal on both, x86_64 and aarch64
2019-05-13 20:13:29 <mps> should I bump pkgrel before push
2019-05-13 20:14:00 <_ikke_> If you change metadata or something in the build process, you should
2019-05-13 20:14:01 <tmhoang> _ikke_: I can manage one
2019-05-13 20:14:47 <_ikke_> They link to here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15754
2019-05-13 20:16:14 <mps> I added one patch file to fix build and checksum is calculated for it
2019-05-13 20:16:22 <_ikke_> then yes
2019-05-13 20:16:23 <mps> these are only changes
2019-05-13 20:16:38 <mps> ok, will bump and push
2019-05-13 20:16:41 <mps> thanks
2019-05-13 20:19:22 <mps> pushed, let's will it works on builder
2019-05-13 20:19:28 <tcely> SpaceToast: better to dev inside a container with a volume that can be shared
2019-05-13 20:19:50 <SpaceToast> well right now I have a git push -> into container -> git pull -> cd -> abuild workflow
2019-05-13 20:19:55 <SpaceToast> but it's pretty inconvenient
2019-05-13 20:20:07 <SpaceToast> if I wanted to dev remotely I wouldn't be fussing over this ;)
2019-05-13 20:20:19 <tcely> ;-
2019-05-13 20:20:24 <tcely> ;-)
2019-05-13 20:20:44 <mps> SpaceToast: I have about five aports and unconsolidated ;)
2019-05-13 20:20:59 <SpaceToast> multiple remotes + branches :)
2019-05-13 20:21:08 <tcely> You might also consider having your dev volume shared to your laptop
2019-05-13 20:21:18 <mps> yes, geographically dispersed
2019-05-13 20:21:30 <SpaceToast> well we just established that volume sharing isn't great with docker
2019-05-13 20:21:35 <_ikke_> mps: does crystal only build on 2 arches?
2019-05-13 20:21:38 <SpaceToast> and I want to be able to edit stuff away from $server
2019-05-13 20:21:56 <mps> _ikke_: yes, only x86_64 and aarch64
2019-05-13 20:22:00 <_ikke_> alright
2019-05-13 20:22:32 <tcely> I was considering a clustering FS or NFS etc
2019-05-13 20:23:00 <mps> _ikke_: it can sometimes sigfault with signal 11 during build but usually in second try it pass
2019-05-13 20:23:12 <SpaceToast> ceph/nfs/etc is really huge overkill, imo
2019-05-13 20:23:40 <SpaceToast> reverse sshfs might do, since I need ssh on the build container anyway
2019-05-13 20:23:45 <SpaceToast> but that's already complicated ^^;;
2019-05-13 20:24:51 <_ikke_> mps: you know how you can get it to retry?
2019-05-13 20:24:54 <tcely> I usually get used to things that may be overkill and wonder why I didn't switch to using it ages ago.
2019-05-13 20:25:22 <mps> _ikke_: not sure, call algitbot?
2019-05-13 20:25:47 <SpaceToast> tcely: well, let's say I run nfs on a btrfs subvolume on my server, but then take my laptop out for other stuff, and want to preemptively edit a thing before I get home
2019-05-13 20:25:57 <SpaceToast> there are just too many error conditions for something as dynamic
2019-05-13 20:26:04 <SpaceToast> I've considered syncthing but that's super awkward
2019-05-13 20:30:35 <tcely> Yeah, I'm not sure about syncthing or NFS. I'd probably build this with tinc + btrfs replication between server volume and the laptop (or VM/container on the laptop)
2019-05-13 20:34:05 <_ikke_> tmhoang: thanks!
2019-05-13 21:02:22 <p4Wv1qn095FW> _ikke_: got confirmation that the ftp.defora.org cert has been renewed.
2019-05-13 21:02:29 <tmhoang> perfect
2019-05-13 21:03:29 <tmhoang> people with lots of resources screw up sometimes too
2019-05-13 21:03:53 <tcely> I'm curious about why the renewal wasn't happening.
2019-05-13 21:04:22 <p4Wv1qn095FW> i was told it was not on some internal list of hosts that need cert updates.
2019-05-13 21:04:35 <p4Wv1qn095FW> this list has also been updated
2019-05-13 21:05:09 <p4Wv1qn095FW> maintainer also wondered who on earth is still packaging this code
2019-05-13 21:05:40 <tcely> Outdated lists. I prefer self selecting sets for this sort of thing.
2019-05-13 21:06:33 <tcely> We do, but only recently started verifying certs
2019-05-13 21:07:04 <_ikke_> p4Wv1qn095FW: good question :-)
2019-05-13 21:07:34 <_ikke_> Fabian Affolter apparently ;-)
2019-05-13 21:08:01 <_ikke_> Seems like a tool that does not age fast
2019-05-13 21:08:16 <tcely> Who else is using the code is a harder question to answer.
2019-05-13 21:24:56 <tcely> I wonder if reporting installed and selected packages would cause a backlash. It'd be nice to have that data.
2019-05-13 21:27:08 <SpaceToast> I think we could have an optional (not installed or enabled by default) report package/daemon
2019-05-13 21:27:15 <SpaceToast> I forget who else does this, but I'm taking it from there :)
2019-05-13 21:28:31 <tcely> To be useful it should be enabled by default. Having a package to easily del for this is a good idea.
2019-05-13 21:29:11 <SpaceToast> enabling it by default is how you get a huge controversy :)
2019-05-13 21:29:16 <SpaceToast> mostly because of the dubious ethics of it
2019-05-13 21:29:49 <_ikke_> ubuntu has popularity-contest
2019-05-13 21:30:37 <SpaceToast> might be what I was thinking of, yeah
2019-05-13 21:30:58 <mps> it's from debian
2019-05-13 21:31:45 <mps> it tries to preserve privacy of users
2019-05-13 21:32:13 <tcely> mps: do you know what steps they take?
2019-05-13 21:32:55 <mps> didn't looked at for years, but iirc it just counts downloaded deb packages
2019-05-13 21:33:01 <SpaceToast> I'm thinking we could just have a binary that uploads the contents of /etc/apk/world and output of `rc-status -a`
2019-05-13 21:33:09 <SpaceToast> with an enable-able cron thing
2019-05-13 21:33:39 <mps> obviously we need skip 'abuild deps' downloads
2019-05-13 21:33:40 <SpaceToast> but I seriously think it shouldn't be enabled, or even installed by default
2019-05-13 21:33:49 <SpaceToast> well it'd be on a timer
2019-05-13 21:33:59 <SpaceToast> so small fluctuations like that wouldn't matter much :)
2019-05-13 21:34:16 <SpaceToast> also, since `abuild deps` uses a virtual package, we'd just see the virtual package and be able to filter it out
2019-05-13 21:35:01 <mps> it would be interesting to have something like that, I asked few days ago do we count 'usage' of pkg's
2019-05-13 21:35:06 <tcely> world is a superset of selected. knowing about installed is good too.
2019-05-13 21:35:21 <SpaceToast> world is mostly "explicitly installed"
2019-05-13 21:35:32 <SpaceToast> which, imo, is what we care about, if anything
2019-05-13 21:35:36 <tcely> Having a batched reporting file that cleans itself up is another good idea.
2019-05-13 21:35:49 <SpaceToast> e.g who cares if mksh is installed if it's as a dependency to a ksh-only script package?
2019-05-13 21:36:00 <SpaceToast> now if the user explicitly installed mksh because they intend to use it, that's another matter
2019-05-13 21:36:08 <tcely> 
ACTION raises hand

2019-05-13 21:36:25 <SpaceToast> if you really care about that information, consider parsing the package index, then :)
2019-05-13 21:36:44 <SpaceToast> ultimately, you can calculate what dependencies would be present; apk does it, after all
2019-05-13 21:37:13 <SpaceToast> and if something was explicitly installed without being added to world (I forget if you can even do that), I'd imagine the user doesn't intend to keep it around for very long
2019-05-13 21:37:41 <tcely> Yes, it does. Why throw that work away? Deps would need to know release and previous states to be accurately recreated
2019-05-13 21:38:04 <SpaceToast> well, the next question is obviously "why do you care?"
2019-05-13 21:38:12 <SpaceToast> what exact kind of information are you trying to glean?
2019-05-13 21:38:18 <SpaceToast> "everyone has musl installed"? :)
2019-05-13 21:38:24 <mps> also, debian ask users during installation do they wont to participate in popularity-contest
2019-05-13 21:38:26 <tcely> To know when it is safe to purge packages
2019-05-13 21:38:44 <SpaceToast> if nothing depends on it... and no one has it explicitly installed...
2019-05-13 21:38:59 <SpaceToast> if something depends on it, repeat up the tree
2019-05-13 21:39:48 <SpaceToast> I don't see why we should significantly increase the complexity of the reporting algorithm, the amount of data collected, *and* potential transfer/storage requirements (though, less significantly so) just to avoid doing checking work that'd need to be done anyway
2019-05-13 21:41:14 <tcely> To save us from deleting packages because deps have changed in the most recent version.
2019-05-13 21:41:54 <SpaceToast> I'm not sure I understand the argument
2019-05-13 21:42:05 <SpaceToast> let's say A depends on B, but in a newer version, the B dependency switches to C
2019-05-13 21:42:25 <SpaceToast> we then decide that, well, no one has B explicitly installed, and nothing depends on it anymore, and that we want to remove B
2019-05-13 21:42:30 <SpaceToast> so we do... from edge
2019-05-13 21:42:39 <SpaceToast> why is this a scenario we want to explicitly avoid?
2019-05-13 21:43:00 <tcely> Because it breaks reinstall of A
2019-05-13 21:43:37 <tcely> We support package pinning so we can't remove B
2019-05-13 21:43:54 <SpaceToast> how does it break reinstall of A?
2019-05-13 21:44:03 <SpaceToast> if you are on edge (pinned or not), you will use C as the dep
2019-05-13 21:44:11 <SpaceToast> if you are off edge (pinned or not) you will use the same-repo B dep
2019-05-13 21:44:38 <tcely> Why do you think A will use C?
2019-05-13 21:44:59 <SpaceToast> because the dependency switched and we updated A to have that information (which is a prerequisite for saying "oh, nothing depends on B now")
2019-05-13 21:45:07 <north1> SpaceToast: there is PopCorn from Void Linux
2019-05-13 21:45:41 <tcely> The pinned version didn't get updated to C
2019-05-13 21:45:53 <SpaceToast> the pinned version is connected to the pinned repository
2019-05-13 21:45:57 <SpaceToast> that *also* contains B
2019-05-13 21:46:05 <SpaceToast> that's the "if you are off edge" scenario above
2019-05-13 21:46:15 <north1> http://popcorn.voidlinux.org/
2019-05-13 21:46:38 <SpaceToast> I would imagine that a decision to delete B only affects edge and future releases, as we have a commitment to support a given release for 6 months (community) or 2 years (main)
2019-05-13 21:46:56 <SpaceToast> i.e removal of a package in main/ would take 2 years total, and 6 months for community/
2019-05-13 21:47:01 <tcely> I don't think we have the same understanding of package pinning
2019-05-13 21:47:38 <SpaceToast> it's when you have `@tag repo` in repos file, and you run `apk add something@tag`
2019-05-13 21:47:55 <SpaceToast> that also allows pulling in dependencies for something@tag from any repos tagged as @tag
2019-05-13 21:48:10 <SpaceToast> it prefers to use untagged repositories if possible, but in the above scenario it wouldn't be
2019-05-13 21:48:12 <tcely> Yeah, that's not what I am discussing.
2019-05-13 21:48:12 <SpaceToast> did I miss something?
2019-05-13 21:49:07 <SpaceToast> if you mean pinning a specific package version... that will break eventually more or less no matter what
2019-05-13 21:49:42 <SpaceToast> you either keep using upstream repositories (-> any bump where the old package is removed is a breakage)
2019-05-13 21:49:50 <tcely> Say I have A=1.0-r3 installed and r5 changed to C. I want to be able to reinstall that release. Without B that breaks.
2019-05-13 21:49:52 <SpaceToast> or you use apk's cache (-> you have cache of B)
2019-05-13 21:50:42 <SpaceToast> so let me get this straight: you are worried about a scenario where a user is running edge, wants to keep a specific package version around, uses apk cache, but explicitly does not cache the dependencies
2019-05-13 21:50:44 <SpaceToast> ?
2019-05-13 21:52:57 <tcely> For the purposes of safe to remove calculation the history of deps is relevant because we can't guarantee everyone is up to date at all times. That is why letting the client report selected and installed is better than trying to recreate that data after reporting selected packages.
2019-05-13 21:53:48 <SpaceToast> well I'm still trying to come up with scenarios where that's relevant
2019-05-13 21:53:55 <SpaceToast> that's why I asked if the above one is the one you're worried about
2019-05-13 21:55:09 <tcely> I'm unclear how you think being inaccurate to the point of breaking installations is irrelevant
2019-05-13 21:55:35 <SpaceToast> I'm trying to find scenarios in which it would break installations (that would not break otherwise)
2019-05-13 21:55:51 <SpaceToast> looking at http://master.alpinelinux.org/alpine/v3.9/main/x86_64/ and http://master.alpinelinux.org/alpine/edge/main/x86_64/, we do not seem to keep old versions of packages around
2019-05-13 21:56:01 <tcely> Being behind edge is one such scenario
2019-05-13 21:56:11 <SpaceToast> so if you have A=1.0-r3 and -r5 comes out at all, you cannot reinstall A=1.0-r3 without caching the package
2019-05-13 21:56:21 <SpaceToast> if you are caching the package, is it unreasonable to think you would also cache the dependencies?
2019-05-13 21:56:49 <SpaceToast> as such, how would removing B affect this scenario?
2019-05-13 21:57:03 <SpaceToast> the example scenario I came up with is where the user explicitly does not cache the *deps*
2019-05-13 21:57:07 <tcely> Forever, everywhere? Yes, I think so.
2019-05-13 21:57:13 <SpaceToast> and asked if that's the scenario you were asking about
2019-05-13 21:57:22 <SpaceToast> I still haven't gotten an answer on that
2019-05-13 21:57:41 <SpaceToast> so we expect people to uncache the deps, but not the package itself?
2019-05-13 21:58:35 <SpaceToast> I am honestly trying to understand, because from where I'm sitting this seems like a fairly extreme edge-case
2019-05-13 21:58:41 <tcely> I do expect people to copy the package they want from one machine to another and not copy all repos. Users do things like that.
2019-05-13 21:58:43 <SpaceToast> with implied user-error
2019-05-13 21:59:26 <SpaceToast> I would assume that they'd see that X version Y is missing and copy that package over too, then
2019-05-13 21:59:27 <tcely> Also, this is only edge case for you because we routinely purge old releases.
2019-05-13 22:00:02 <SpaceToast> well yes, but if we didn't routinely purge old releases B would actually stick around for a while, even post-removal
2019-05-13 22:03:33 <otlabs> time to go, bye
2019-05-13 22:04:40 <tcely> Anyway knowing which releases are installed and which are selected is the data I would like.
2019-05-13 22:04:57 <SpaceToast> okay
2019-05-13 22:05:16 <SpaceToast> I'd like to see explicitly selected (world) and running services (rc-status) :)
2019-05-13 22:06:35 <tcely> I wonder if cmdlines list wouldn't be faster / better
2019-05-13 22:07:04 <SpaceToast> well, the reason I want running services is because having docker installed and docker currently running (as an example) are separate things
2019-05-13 22:07:21 <SpaceToast> and explicitly selected (world) talks about user intent (moreso than what happens to be installed)
2019-05-13 22:07:30 <SpaceToast> + both are very simple/fast to get
2019-05-13 22:07:45 <tcely> for /proc/*/cmdlines ; report just argv[0] ; done or similar
2019-05-13 22:08:09 <SpaceToast> that seems even more intrusive, to me :/
2019-05-13 22:08:44 <SpaceToast> also, my specific example is particularly easy to sandbox (apparmor/selinux/whatever) - it'd need to read one file, and execute one binary (with known arguments)
2019-05-13 22:09:00 <tcely> What does the rc-status output look like on your system?
2019-05-13 22:09:07 <SpaceToast> which system?
2019-05-13 22:09:18 <tcely> Any
2019-05-13 22:10:15 <SpaceToast> https://brpaste.xyz/AIEWOA
2019-05-13 22:10:49 <SpaceToast> (if I was to start a service by hand, without it being in a runlevel, it'd be under Dynamic Runlevel: manual)
2019-05-13 22:14:10 <tcely> Ok. That does expose less about running processes. I do wonder what is being accessed to report this info.
2019-05-13 22:15:16 <SpaceToast> mostly /etc/runlevels
2019-05-13 22:15:30 <SpaceToast> and openrc's "health" status stuff
2019-05-14 00:05:39 <tcely> Did a typo for openvpn just go by in -commits?
2019-05-14 00:11:56 <tcely> For #10450 https://www.boost.org/users/history/version_1_68_0.html
2019-05-14 00:15:12 <tcely> Also signals v1 is listed as discontinued in https://www.boost.org/users/history/version_1_69_0.html
2019-05-14 06:05:07 <fcolista> SpaceToast, were you trying to make work LXD in a live-migration setup?
2019-05-14 06:05:27 <fcolista> morning all, btw :)
2019-05-14 06:16:13 <danieli> morning
2019-05-14 07:00:08 <tcely> fcolista: SpaceToast was hoping that the docker client would take care of transferring files to the docker server (over socket / TCP) to allow the container to access the contents of the local filesystem using a volume.
2019-05-14 07:05:34 <tcely> fcolista: can you change the settings for aports on GH?
2019-05-14 07:25:41 <fcolista> tcely, which setting?
2019-05-14 07:26:06 <tcely> fcolista: I'm looking to turn on the projects so we can track PRs on the boards
2019-05-14 07:26:47 <fcolista> which setting you want me to change?
2019-05-14 07:29:34 <_ikke_> fcolista: can you perhaps take a look at git in edge? It seems to have packaged a coredump
2019-05-14 07:29:48 <tcely> https://github.com/alpinelinux/aports/settings, under features, check "Projects"
2019-05-14 07:29:56 <_ikke_> There was a coredump during stripping
2019-05-14 07:30:25 <clandmeter> it deps in srcdir?
2019-05-14 07:30:33 <danieli> wait what
2019-05-14 07:30:36 <clandmeter> s/deps/dumps/
2019-05-14 07:30:36 <alpine-meetbot> clandmeter meant to say: it dumps in srcdir?
2019-05-14 07:30:37 <danieli> it.. packaged a coredump?
2019-05-14 07:30:50 <tcely> clandmeter:  wouldn't it need to be in $pkgdir?
2019-05-14 07:31:10 <clandmeter> for it be in pkgdir it firsts need to be in srcdir
2019-05-14 07:31:18 <clandmeter> i thought be default it dumped somewhere else
2019-05-14 07:31:47 <_ikke_> hmm, pkgs.a.o does not show it
2019-05-14 07:31:48 <danieli> there's a file in edge/x86_64/main/git, "//core"
2019-05-14 07:32:01 <danieli> look at the first file https://pkgs.alpinelinux.org/contents?file=&path=&name=git&branch=edge&arch=x86_64
2019-05-14 07:32:30 <fcolista> tcely, I don't have settings for alpinelinux/aports, don't have the rights
2019-05-14 07:32:37 <_ikke_> http://tpaste.us/P0zb
2019-05-14 07:32:47 <clandmeter> Bus error (core dumped)
2019-05-14 07:32:53 <_ikke_> yes
2019-05-14 07:33:01 <tcely> fcolista: ok, thanks for looking.
2019-05-14 07:33:03 <_ikke_> ddevault noticed it
2019-05-14 07:33:21 <fcolista> tcely, np. I have that settings for other repo, but not for alpinelinux/aports, sorry
2019-05-14 07:33:23 <clandmeter> tcely: please add a ticket on bugs.a.o what you want to do
2019-05-14 07:33:35 <danieli> core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'scanelf --recursive --nobanner --osabi --etype ET_DYN ET_EXEC .', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: '/usr/bin/scanelf', platform: 'x86_64'
2019-05-14 07:33:38 <tcely> clandmeter: alright
2019-05-14 07:34:33 <clandmeter> and keep in mind we could migrate to some other solution.
2019-05-14 07:35:37 <tcely> clandmeter: no problem GL has that too, just under issues
2019-05-14 07:35:59 <clandmeter> yes, but does the migration tools support it.
2019-05-14 07:36:58 <clandmeter> tcely: please explain what you want to do so we can think about enabling it.
2019-05-14 07:37:27 <fcolista> +1
2019-05-14 07:38:43 <clandmeter> _ikke_: is the dump reproducable?
2019-05-14 07:39:18 <_ikke_> clandmeter: No, I tried to build it myself and it doesn't dump
2019-05-14 07:39:40 <danieli> i see something in the dump about a missing symbol
2019-05-14 07:40:03 <clandmeter> i can bump it and see what happens.
2019-05-14 07:40:18 <_ikke_> clandmeter: maybe worth a try
2019-05-14 07:40:23 <clandmeter> i think the default coredump location is cwd
2019-05-14 07:40:27 <danieli> .Symbol not found: acl_set_file.
2019-05-14 07:41:03 <danieli> clandmeter: it used to be cwd, but not always, it's a kernel setting
2019-05-14 07:41:26 <clandmeter> i know, but i think default is set to just "core"
2019-05-14 07:41:33 <danieli> it is indeed
2019-05-14 07:41:35 <danieli> i just checked
2019-05-14 07:41:48 <clandmeter> so that means it will popup in srcdir
2019-05-14 07:41:54 <clandmeter> and makefile could pick it up
2019-05-14 07:41:57 <danieli> and if there's no absolute path, i'll imagine it's produced in cwd
2019-05-14 07:43:26 <_ikke_> clandmeter: where is abuild stripping symbols on?
2019-05-14 07:43:49 <clandmeter> ?
2019-05-14 07:44:11 <tcely> clandmeter: I updated the description with a link to an example I created in my fork. As for migration, I'm not sure I care. The working set of PRs changes quickly enough that even if the migration worked it will be outdated very quickly.
2019-05-14 07:46:34 <clandmeter> tcely: ok thx
2019-05-14 07:50:41 <clandmeter> _ikke_: looks ok now
2019-05-14 07:51:00 <clandmeter> i remember ncopa also had some gcc errors?
2019-05-14 07:53:47 <Cogitri> Some SIGSEVs I believe, yes
2019-05-14 09:56:37 <fcolista> clandmeter, do you think we can merge qt5 before 3.10 ?
2019-05-14 09:57:24 <fcolista> https://github.com/alpinelinux/aports/pull/7767
2019-05-14 09:57:29 <fcolista> no ABI change
2019-05-14 09:57:42 <fcolista> s/change/break
2019-05-14 09:57:42 <alpine-meetbot> fcolista meant to say: no ABI break
2019-05-14 10:16:12 <mps> spam ^
2019-05-14 10:17:18 <danieli> cc Cogitri
2019-05-14 10:17:25 <danieli> fieldengineer[.]com spam again
2019-05-14 10:18:11 <Cogitri> Thanks
2019-05-14 10:18:32 <danieli> no, thank you
2019-05-14 10:19:38 <Cogitri> :)
2019-05-14 10:35:11 <danieli> ^ hmm https://git.musl-libc.org/cgit/musl/tree/src/string/explicit_bzero.c
2019-05-14 10:35:25 <danieli> something's screwy
2019-05-14 10:48:48 <clandmeter> looks like system is not correctly upgraded
2019-05-14 10:51:36 <_ikke_> clandmeter: Do you know if there is any reason why go is still explicitly installed on the (x86_64) builders?
2019-05-14 10:51:49 <_ikke_> Or can it be removed alreayd
2019-05-14 10:52:04 <clandmeter> is go build already?
2019-05-14 10:52:25 <_ikke_> Let me check
2019-05-14 10:52:33 <clandmeter> which builder is this?
2019-05-14 10:52:34 <clandmeter> .10?
2019-05-14 10:53:00 <_ikke_> yes
2019-05-14 10:53:20 <clandmeter> if go is build correctly it should be removed immediately
2019-05-14 10:53:37 <clandmeter> else all go pkgs will be build with edge go
2019-05-14 10:53:47 <_ikke_> /home/buildozer/packages/community/x86_64/go-1.12.5-r0.apk exists, so I assume yes
2019-05-14 10:54:03 <_ikke_> I only have access to the x86_(64) builders
2019-05-14 10:54:09 <_ikke_> so cannot remove it from the others
2019-05-14 10:54:26 <clandmeter> you dont have arm access?
2019-05-14 10:54:33 <_ikke_> Not that I'm aware of
2019-05-14 10:54:37 <clandmeter> i remember i added your key before
2019-05-14 10:55:01 <clandmeter> i can check later.
2019-05-14 10:55:04 <_ikke_> I did remember I tried before but couldn't login
2019-05-14 10:56:45 <clandmeter> i think one should run cd go && abuild -r ; sudo apk del go
2019-05-14 10:56:59 <danieli> _ikke_: ncopa installed go on the builders the other day, it's to bootstrap go
2019-05-14 10:57:07 <danieli> iirc that's what he said
2019-05-14 10:57:17 <clandmeter> bootstrap alraedy done
2019-05-14 10:57:28 <clandmeter> it should be removed already
2019-05-14 10:58:46 <_ikke_> danieli: Yes, I'm aware
2019-05-14 10:58:56 <_ikke_> Was just wondering if it could be removed already
2019-05-14 10:58:58 <danieli> yeah, just remove go and ghc then
2019-05-14 10:59:06 <_ikke_> ghc is already removed
2019-05-14 10:59:21 <_ikke_> ncopa only installed go
2019-05-14 11:01:53 <danieli> πŸ‘
2019-05-14 11:02:14 <clandmeter> β›…
2019-05-14 11:02:34 <danieli> πŸ’©
2019-05-14 11:04:54 <_ikke_> 🎈
2019-05-14 12:33:52 <mps> anyone with main push access, please push ell (libell) https://patchwork.alpinelinux.org/patch/4857/ it is simple version bump, I tested build in edge on x86_64, armv7 and aarch64
2019-05-14 12:34:19 <mps> I need it for iwd upgrade
2019-05-14 12:34:59 <mps> fcolista: ^
2019-05-14 12:37:14 <fcolista> mps ok
2019-05-14 12:37:43 <fcolista> test fails
2019-05-14 12:37:46 <mps> thanks
2019-05-14 12:38:10 <mps> oh, on which arch
2019-05-14 12:38:15 <fcolista> x86_64
2019-05-14 12:38:21 <fcolista> unit/test-uuid
2019-05-14 12:38:41 <fcolista> https://dpaste.de/AYwS
2019-05-14 12:38:42 <mps> hmm, strange, for me it worked without issue
2019-05-14 12:38:45 <fcolista> (partial log)
2019-05-14 12:39:24 <danieli> erlang/otp 22.0 is out, so i'm gonna work on that
2019-05-14 12:39:52 <mps> I see, sorry for annoyance, will check again
2019-05-14 12:40:35 <fcolista> np
2019-05-14 12:42:25 <mps> fcolista: this is on builders? I test in lxc containers
2019-05-14 12:42:32 <fcolista> lxc container
2019-05-14 12:43:01 <fcolista> mps can you send the patch to GH, so travis/drone can build this?
2019-05-14 12:43:29 <mps> I don't have GH account, else I would not bother you
2019-05-14 12:44:05 <fcolista> ok, so bother with the check() function then :)
2019-05-14 12:44:07 <mps> again, it pass on my edge lxc container
2019-05-14 12:44:56 <mps> and, I tried on armv7 and aarch64, all went good
2019-05-14 12:45:45 <fcolista> mps can you tpaste the outpug of apk info of your lxc container?
2019-05-14 12:46:11 <mps> here is the result http://tpaste.us/mZOR
2019-05-14 12:47:01 <mps> and here is the 'apk info' http://tpaste.us/RgVv
2019-05-14 12:56:32 <fcolista> https://dpaste.de/EAut
2019-05-14 12:56:37 <fcolista> this is where ell fails here
2019-05-14 12:57:37 <fcolista> https://git.alpinelinux.org/aports/commit/?id=d352f6fcd25514028a93bfa99b45321bfdf89dda
2019-05-14 12:57:47 <mps> I see, will try to reproduce
2019-05-14 12:57:50 <danieli> only fails on ppc64le?
2019-05-14 12:58:28 <mps> ah, this is only on ppc64el ?
2019-05-14 12:58:51 <mps> le*
2019-05-14 12:59:01 <danieli> le/el is tomato/tomato
2019-05-14 12:59:46 <fcolista> mps, no this seems to be an issue with ppc64le that eventually was fixed by upstream
2019-05-14 13:01:01 <mps> yes, I remember
2019-05-14 13:01:48 <mps> very strange, in my lxc tried three times and always went ok, and also on armv7 and aarch64
2019-05-14 13:02:48 <fcolista> wondering if is related to the kernel version
2019-05-14 13:02:56 <fcolista> lxc shares the same kernel of the host
2019-05-14 13:03:05 <fcolista> the only thing different between our lxc
2019-05-14 13:03:55 <mps> could be,  my is 'Linux edge 4.19.40-0-vanilla #1-Alpine SMP Mon May 6 12:31:34 UTC 2019 x86_64 Linux'
2019-05-14 13:04:44 <mps> but on aarch64 it is 'Linux mps-edge-aarch64 4.14.78-1-vanilla #2-Alpine SMP Fri Oct 26 20:28:28 UTC 2018 aarch64 Linux'
2019-05-14 13:05:13 <fcolista> Linux x86_64-edge 4.19.34-0-vanilla #1-Alpine SMP Mon Apr 8 06:03:08 UTC 2019 x86_64 Linux
2019-05-14 13:06:44 <mps> hmm, so kernel shouldn't be issue
2019-05-14 13:07:03 <fcolista> ok
2019-05-14 13:07:09 <fcolista> so it must be a package you have installed
2019-05-14 13:07:43 <danieli> # PASS:  38
2019-05-14 13:07:46 <danieli> x86_64
2019-05-14 13:07:47 <mps> did you looked in my 'apk info' here http://tpaste.us/RgVv
2019-05-14 13:07:52 <fcolista> yes
2019-05-14 13:08:07 <mps> danieli: it pass on your box?
2019-05-14 13:08:10 <danieli> yes
2019-05-14 13:08:28 <danieli> lxc too, alpine infra (nld5)
2019-05-14 13:08:44 <mps> hmmmm?
2019-05-14 13:09:03 <mps> no idea why it fail on fcolista's box
2019-05-14 13:09:10 <fcolista> me either
2019-05-14 13:09:15 <fcolista> but I;ve pushed it
2019-05-14 13:09:34 <mps> ok, let's what builder will do
2019-05-14 13:09:44 <danieli> indeed, let's see
2019-05-14 13:09:54 <fcolista> it worked
2019-05-14 13:11:05 <tmhoang> how to tell builders to try makpasswd again ?
2019-05-14 13:11:20 <mps> does builders build packages in 3.10 and edge on push
2019-05-14 13:12:57 <mps> fcolista: I don't see fails, thanks again and thanks to danieli also
2019-05-14 13:13:17 <fcolista> it worked. Dunno why it does not in my lxc
2019-05-14 13:13:38 <mps> magic ;)
2019-05-14 14:09:28 <mps> if file is added to the pkg which fixes build, should be the pkgrel bumped ?
2019-05-14 14:49:30 <mps> no one, so I will bump it just in case
2019-05-14 14:59:47 <mps> uhm, commit message is not precise: 'community/shard' instead of 'community/shards', i.e. missing 's' at the end
2019-05-14 15:39:36 <_ikke_> TIL you can use tab in tig to switch between windows
2019-05-14 15:40:00 <_ikke_> (switch focus between panes)
2019-05-14 15:51:53 <kmaxwell> haven't used tig much before, looks handy
2019-05-14 15:53:01 <_ikke_> I use it all the time
2019-05-14 15:55:11 <kmaxwell> have to explore a bit more, could be a good way to get rid of a custom alias
2019-05-14 15:55:15 <kmaxwell> ty for mentioning
2019-05-14 15:55:39 <_ikke_> np
2019-05-14 16:04:35 <mksully22> Looks like llvm5 build fail for ppc64le at least is failing because go pkg is still installed from prior go pkg build. Can someone with builder access jump on and apk del it?
2019-05-14 16:05:29 <_ikke_> rdutra: ^?
2019-05-14 16:06:20 <_ikke_> I removed it at least from the x86(_64) builders
2019-05-14 16:08:02 <rdutra> _ikke_: done
2019-05-14 16:08:09 <_ikke_> thanks
2019-05-14 16:08:15 <rdutra> yw
2019-05-14 16:09:01 <_ikke_> ruby-enum test suite fails quite some tests
2019-05-14 16:09:11 <mksully22> rdutra: thanks!
2019-05-14 16:09:23 <_ikke_> 29 examples, 5 failures
2019-05-14 16:10:18 <_ikke_> only ruby-mathematical depends on ruby-enum..
2019-05-14 16:13:00 <mksully22> Ruby-enum build fails once Ruby-i18n upgraded past version 1.1 I think
2019-05-14 16:17:20 <_ikke_> Ah ok
2019-05-14 16:17:45 <_ikke_> https://github.com/dblock/ruby-enum/issues/21
2019-05-14 16:17:51 <_ikke_> Not sure if it will get fixed
2019-05-14 16:23:42 <_ikke_> I'm thinking of disabling those two packages for now in order to get the builders unstack
2019-05-14 16:23:46 <_ikke_> unstuck
2019-05-14 16:40:50 <kmaxwell> _ikke_: nice to see atools moving on :)
2019-05-14 16:41:18 <_ikke_> kmaxwell: :)
2019-05-14 16:52:52 <north1> kmaxwell: :)
2019-05-14 16:57:47 <kmaxwell> are you both running it manually or have you integrated it into anything like https://github.com/w0rp/ale ?
2019-05-14 17:04:39 <_ikke_> I just run it locally
2019-05-14 17:04:43 <_ikke_> manually
2019-05-14 17:05:14 <_ikke_> I have a script that runs abuild sanitycheck, shelcheck and alint
2019-05-14 17:07:30 <kmaxwell> OK thank, I have ALE run ShellCheck and its really handy
2019-05-14 17:07:50 <kmaxwell> north1: is the output format stable at this stage?
2019-05-14 17:08:07 <kmaxwell> might try an integration, have a few I mean to upstream
2019-05-14 17:26:16 <north1> kmaxwell: it is in my pre-commit hook
2019-05-14 17:26:34 <north1> I can make a stable format for usage in ALE and other stuff
2019-05-14 17:27:06 <north1> But then I'll need to split out some extra stuff like finding duplicate packages and packages that depend on an upper repo
2019-05-14 17:28:12 <north1> Maybe have apkbuild-lint for linting apkbuild files and aports-lint for linting stuff that works across multiple packages (like finding duplicate packages)
2019-05-14 17:52:54 <eu> I really hate shellcheck
2019-05-14 17:53:36 <eu> Leads to people never understanding shell quoting
2019-05-14 18:12:54 <_ikke_> geany-plugins fails to build because geanypy is somehow not building
2019-05-14 18:13:12 <_ikke_> "checking whether the GTK version in use is compatible with plugin Geanypy... no"
2019-05-14 18:14:28 <otlabs> hi ppl
2019-05-14 18:15:15 <_ikke_> o/
2019-05-14 18:16:01 <otlabs> _ikke_: how are you!
2019-05-14 18:16:07 <_ikke_> Doing alright
2019-05-14 18:16:16 <otlabs> that's cool!
2019-05-14 18:16:19 <_ikke_> trying to figure out why geany-plugins cannot build geanypy
2019-05-14 18:16:38 <otlabs> do you have a PR already?
2019-05-14 18:16:51 <otlabs> so i will take a humble look
2019-05-14 18:17:04 <_ikke_> It's the one in aports
2019-05-14 18:17:10 <otlabs> ok
2019-05-14 18:17:17 <_ikke_> ./configure output: "checking whether the GTK version in use is compatible with plugin Geanypy... no"
2019-05-14 18:18:32 <otlabs> so you do not upgrading but just re-building?
2019-05-14 18:19:01 <_ikke_> yes, for 3.10
2019-05-14 18:19:46 <otlabs> do you have issues on all architectures?
2019-05-14 18:19:53 <_ikke_> Not sure yet
2019-05-14 18:20:11 <_ikke_> at least aarch6 and x86_64
2019-05-14 18:20:22 <_ikke_> s/ch6/ch64
2019-05-14 18:20:22 <alpine-meetbot> _ikke_ meant to say: at least aarch64 and x86_64
2019-05-14 18:20:37 <_ikke_> I'm looking at the configure script now
2019-05-14 18:20:39 <otlabs> oh, ok
2019-05-14 18:20:57 <otlabs> i got some weird issues today on all arm archies
2019-05-14 18:21:45 <otlabs> better to say arm drone instances
2019-05-14 18:22:22 <_ikke_> I think it only works with gtk2
2019-05-14 18:22:27 <_ikke_>  if test ${GP_GTK_VERSION_MAJOR} = 2; then :
2019-05-14 18:22:33 <_ikke_> { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
2019-05-14 18:25:44 <_ikke_> geany-dev depends on gtk+3.0
2019-05-14 18:29:30 <otlabs> version 1.35 is out
2019-05-14 18:29:41 <_ikke_> hmm
2019-05-14 18:29:55 <otlabs> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/geany-plugins
2019-05-14 18:30:28 <_ikke_> and apparently geany is already on 1.35
2019-05-14 18:31:15 <otlabs> hmmm, not in aports
2019-05-14 18:31:23 <otlabs> it is still 1.34
2019-05-14 18:31:55 <otlabs> and it has depends_dev="gtk+2.0-dev"
2019-05-14 18:32:30 <_ikke_> https://git.alpinelinux.org/aports/tree/community/geany/APKBUILD#n4
2019-05-14 18:33:01 <_ikke_> 11 days ago upgraded to 1.35
2019-05-14 18:33:20 <_ikke_> north1: ping
2019-05-14 18:34:14 <_ikke_> https://github.com/codebrainz/geanypy/pull/10
2019-05-14 18:34:21 <_ikke_> that's ancient
2019-05-14 18:42:38 <mps> iwd 0.18 failed on s390x, anyone here with experience on that arch to help
2019-05-14 18:43:12 <_ikke_> usually tmhoang
2019-05-14 18:45:50 <mps> ok, will wait for him
2019-05-14 18:46:23 <_ikke_> Wonder what I should do with geany-plugins, there already 3 plugins which have a hard dependency on gtk2
2019-05-14 18:46:31 <tmhoang> mps: roger that
2019-05-14 18:47:11 <tmhoang> watching movie atm sorry :D
2019-05-14 18:48:12 <otlabs> _ikke_: i was looking at https://github.com/alpinelinux/aports/blob/95494b2a6ae0d6a436ae3dc7d869580aca8dcf5e/community/geany/APKBUILD
2019-05-14 18:48:15 <mps> tmhoang: np, just don't understand is this issue wtih s390x or some changes in new iwd
2019-05-14 18:48:50 <mps> previous version is built fine on s390x, iirc
2019-05-14 18:50:38 <mps> hmm, maybe ell is not upgraded to 0.20 on s390x yet
2019-05-14 18:50:51 <tcely> eu: how do you mean about the quoting?
2019-05-14 18:52:23 <mps> it is upgraded, i see in log
2019-05-14 18:55:47 <north1> _ikke_: pong
2019-05-14 18:57:47 <_ikke_> Trying to get geany-plugins to build. Noticed that geany was updated to 1.35 but geany-plugins was left behind
2019-05-14 18:58:18 <_ikke_> But that's not the issue. Some plugins seem to require GTK+2.0, while geany depends on GTK+3.0
2019-05-14 18:59:26 <_ikke_> configure: error: Geanypy is not compatible with the GTK version in use
2019-05-14 19:02:54 <_ikke_> I feel we need to drop some plugins
2019-05-14 19:07:33 <_ikke_> http://tpaste.us/zBdJ
2019-05-14 19:24:03 <otlabs> i am upgrading testing/singularity, PR301, x86* archies build fine, but all arm archies through strange error about missing `ld` while building bash completion. the previous version was built for all archies. should i just disable all arm archies?
2019-05-14 19:24:37 <otlabs> pr7pr7877
2019-05-14 19:24:42 <otlabs> pr7877
2019-05-14 19:24:47 <otlabs> sorry
2019-05-14 20:31:02 <eu> tcely: "$blindly" "$quoting" "$every" "$variable" "$under" "$the" "$sun"
2019-05-14 20:31:43 <eu> maybe shellcheck has become better, have not used it for ages
2019-05-14 20:32:28 <eu> does it not warn for: l='a b c'; for i in $l; do echo $i; done ?
2019-05-14 20:33:26 <tcely> Ah. There are few times when not quoted is needed.
2019-05-14 20:34:00 <eu> I use not quoted probably 90% of the time in my scripts
2019-05-14 20:36:50 <tcely> There's a difference between "I use" and "I need" though. I do prefer it tell people to quote and let experts decide when not to than the other way around.
2019-05-14 20:41:38 <_ikke_> And for a static analyzer it
2019-05-14 20:41:49 <_ikke_> it's often impossible to tell whether they are needed or not
2019-05-14 20:55:51 <eu> user='Mr /'; rm -rf $user
2019-05-14 20:56:38 <eu> I guess shellcheck is fine for APKBUILDS, where you have many variables coming from the environment.
2019-05-14 21:09:28 <eu> huh, GH tag tarballs can change hash? or maybe scapy authors force pushed a new tag?
2019-05-14 21:11:25 <otlabs> the program wants to #include <sys/endian.h>, which package i can use to provide this file? or should i use /usr/include/endian.h from musl-dev?
2019-05-14 21:19:24 <mps> otlabs: isn't <sys/endian.h> from libbsd
2019-05-14 21:20:50 <otlabs> it's `/usr/include/bsd/sys/endian.h`
2019-05-14 21:21:13 <otlabs> i have tried it but the program have not picked it up
2019-05-14 21:22:25 <mps> hmm, yes.
2019-05-14 21:22:31 <otlabs> i plan to patch source but i do not know which of 2 packages to use
2019-05-14 21:23:28 <eu> No need for a package I think
2019-05-14 21:23:29 <mps> which package
2019-05-14 21:23:31 <eu> https://git.alpinelinux.org/aports/tree/main/rtpproxy/define-byte-order.patch
2019-05-14 21:24:09 <otlabs> mps: which package?
2019-05-14 21:24:27 <eu> try with <endian.h> from musl
2019-05-14 21:24:50 <mps> otlabs: I meant to ask about what package you are talking
2019-05-14 21:25:02 <otlabs> eu: thanks!
2019-05-14 21:25:20 <otlabs> mps: i am building cython-blis
2019-05-14 21:25:45 <otlabs> https://github.com/explosion/cython-blis
2019-05-14 21:25:56 <mps> oh, will not touch anything with *ython in name
2019-05-14 21:26:24 <otlabs> good idea
2019-05-14 21:26:28 <mps> but I think you could try eu's advice, I did this sometimes
2019-05-14 21:26:36 <otlabs> i will
2019-05-14 21:27:59 <otlabs> i am building spaCy, https://github.com/explosion/spaCy, and this package is one of its dependencies
2019-05-14 21:29:00 <mps> s390x is stuck by iwd, should I disable it there?
2019-05-14 21:31:15 <eu> wifi on mainframes does not make any sense anyways :)
2019-05-14 21:31:33 <eu> or they can use wpa_supplicant...
2019-05-14 21:32:47 <mps> eu: I looked at wpa_supplicant and saw it is arch="all", although don't know does s390x need wifi packages
2019-05-14 21:33:33 <mps> about s390x I know nothing, only that is some kind of big machines
2019-05-14 21:34:25 <mps> and man who 'own' it is not here now
2019-05-14 21:34:32 <otlabs> i have submitted the PR for testing/singularity which fixes high severity security issue CVE-2019-11328 and upgrades the package. new version do not build for all arm archies so i have disabled them. what would happen with old versions of the package for arm archies? will they be deleted?
2019-05-14 21:50:15 <otlabs> sorry, need to go. i would quite appreciate any comments about ^^^^^^
2019-05-14 21:57:11 <north1> eu: they change rarely by themselves when the infra that provides them changes or when an upstream updates the release
2019-05-14 21:59:41 <eu> hmm, why is intel-ucode in testing? given todays new set of cpu vulns it would be nice to have it in main, backported to supported releases
2019-05-14 22:00:19 <north1> re: quoting variables; it is rare and almost always explicit when one wants to have a variable unquoted. Unless shellcheck can determine the value of a variable it will complain.
2019-05-14 22:01:07 <eu> > Linux users should apply kernel and CPU microcode updates as soon as they are available from their distribution vendor, and follow any guidance to adjust system settings.
2019-05-14 22:01:45 <eu> https://www.chromium.org/Home/chromium-security/mds
2019-05-14 22:02:32 <mps> eu: microcode could be easily installed from testing and testing have faster 'upgrade' cycle
2019-05-14 22:06:05 <eu> I would hope nost production systems does not have testing enabled
2019-05-14 22:06:22 <eu> nor is it enables by default (obviously)
2019-05-14 22:06:41 <eu> s/nost/most/
2019-05-14 22:06:41 <alpine-meetbot> eu meant to say: I would hope most production systems does not have testing enabled
2019-05-14 22:07:21 <mps> yes, but alpine also doesn't have fast security fixes
2019-05-14 22:10:03 <mps> and testing could be pinned so packages can be selectively added or upgraged, although I'm not against to move microcode from testing, just thinking aloud
2019-05-14 22:10:26 <eu> I know alpine is not on the oss distros list, but I would not call it slow
2019-05-14 22:11:26 <mps> heh, I used word 'fast' and not 'slow' ;)
2019-05-14 22:12:13 <eu> well, someone ahould at least bump to 4.19.43
2019-05-14 22:12:26 <mps> but again, I'm not against your proposal
2019-05-14 22:15:30 <eu> qemu is also affected
2019-05-14 22:20:18 <mps> five years ago I stopped to by intel's boxes
2019-05-14 22:22:13 <mps> s/by/buy/
2019-05-14 22:22:13 <alpine-meetbot> mps meant to say: five years ago I stopped to buy intel's boxes
2019-05-14 23:15:08 <iggy> can't seem to find the answer to this anywhere, is there a way to change where srcdir points? i.e. I want srcdir to be /tmp/whatever rather than aports/repo/package/src
2019-05-14 23:30:34 <mps> iggy: yes, you can set srcdir in ENV variable wherever you like
2019-05-14 23:31:14 <mps> but setting pkgdir doesn't 'work'
2019-05-14 23:35:27 <iggy> thank you
2019-05-15 03:53:26 <tcely> mps: did you figure out why pkgdir doesn't work? that should be working as far as I can tell.
2019-05-15 03:55:23 <tcely> btw, it's pkgbasedir you need in ENV
2019-05-15 08:18:19 <danieli> unfortunately, security (as with most things) is best effort in alpine
2019-05-15 08:33:31 <danieli> ^ that issue.. "as discussed with natanael copa on slack"?
2019-05-15 08:33:34 <danieli> he's on a vacation lol
2019-05-15 08:34:40 <_ikke_> And what slack channel..?
2019-05-15 08:34:45 <danieli> no clue, i was wondering too
2019-05-15 08:35:10 <_ikke_> But for the rest it's not that controversial I guess?
2019-05-15 08:35:34 <danieli> i don't mind upgrading it, but i want to know what their motivation for it is
2019-05-15 08:36:09 <_ikke_> Because they appeal to ncopa?
2019-05-15 08:37:08 <danieli> 'their' as in both of them - i'm just curious as to which bugs
2019-05-15 08:37:44 <_ikke_> docker-compose, even with pr7115, is still broken :-/
2019-05-15 08:37:55 <_ikke_> pkg_resources.DistributionNotFound: The 'paramiko>=2.4.2' distribution was not found and is required by docker
2019-05-15 08:37:56 <danieli> i can test it
2019-05-15 08:38:14 <danieli> but honestly, i don't use docker much on alpine, so i personally don't care too much
2019-05-15 08:39:18 <danieli> [1;31m>>> ERROR:[1;0m [1;1mdocker-compose[1;0m: docker-compose-1.24.0.tar.gz is missing in checksums
2019-05-15 08:39:20 <danieli> lol
2019-05-15 08:40:46 <danieli> argh, why can't i add comments on parts of the apkbuild that's not displayed?
2019-05-15 08:40:54 <_ikke_> You should be able ot
2019-05-15 08:40:56 <danieli> i hit the button to show the rest and i can't add comments there
2019-05-15 08:40:56 <_ikke_> to
2019-05-15 08:41:12 <_ikke_> note that I fixed those issues locally already
2019-05-15 08:41:17 <_ikke_> just not the last one yet
2019-05-15 08:41:18 <danieli> anyway, the sha256sum is for the 1.23.2 checksum, not 1.24.0
2019-05-15 08:41:52 <_ikke_> yeah, they forgot to run abuild checksum after the last update
2019-05-15 08:42:05 <_ikke_> https://github.com/alpinelinux/aports/pull/7115#issuecomment-491611883
2019-05-15 08:42:17 <danieli> ah
2019-05-15 08:42:18 <danieli> (y)
2019-05-15 08:42:34 <danieli> checks still fail for that though, nobody has fixed it yet
2019-05-15 08:43:06 <_ikke_> only bin/docker-compose
2019-05-15 08:43:12 <_ikke_> -v is run
2019-05-15 08:43:40 <danieli> so no proper check is done either?
2019-05-15 08:43:53 <_ikke_> # many of the tests fail. need more investigation
2019-05-15 08:44:42 <_ikke_> I wonder why it does not fail during building
2019-05-15 08:47:05 <_ikke_> Because it's only setuptools that's adding those requirements
2019-05-15 08:47:18 <_ikke_> So that docker-compose -v is worthless
2019-05-15 08:48:43 <_ikke_> Ok, adding py3-paramiko as dependency works
2019-05-15 08:59:49 <_ikke_> pushed
2019-05-15 09:14:07 <kmaxwell> does 'apk add -X <repo>' imply --allow-untrusted ?
2019-05-15 09:20:38 <_ikke_> No idea
2019-05-15 09:21:29 <danieli> i would assume not
2019-05-15 09:21:53 <artok> it does not
2019-05-15 09:25:06 <kmaxwell> thanks for confirming!
2019-05-15 09:25:29 <kmaxwell> I got in a muddle with cached indexes in /etc/apk/cache
2019-05-15 09:43:25 <cim209> does someone know what this error is https://github.com/MisterTea/EternalTerminal/issues/188
2019-05-15 09:43:32 <cim209> i'm trying to compile eternal terminal
2019-05-15 09:44:53 <danieli> cim209: differences between musl and glibc, you'll find some results about it if you google undefined reference to `backtrace_symbols'
2019-05-15 09:45:10 <clandmeter> you need to pass the correct linker flags
2019-05-15 09:45:27 <clandmeter> for libexecinfo
2019-05-15 09:45:33 <danieli> ah, right, they have libexecinfo, i forgot
2019-05-15 09:45:51 <cim209> so it's a problem with the repo's code?
2019-05-15 09:46:14 <cim209> i have no idea how to do that
2019-05-15 09:48:17 <danieli> try adding "-lexecinfo" to the linker flags
2019-05-15 09:52:41 <cim209> hmm
2019-05-15 09:52:45 <cim209> i noticed a build_static.sh
2019-05-15 09:53:38 <cim209> i executed it, it's building
2019-05-15 09:55:06 <_ikke_> Can someone check this PR to verify it's a good solution? https://github.com/alpinelinux/aports/pull/7883
2019-05-15 10:20:57 <danieli> oh man, a lot of vulns have been disclosed over the past couple of days
2019-05-15 10:21:44 <Cogitri> Yup
2019-05-15 10:21:50 <danieli> CVE-2019-11815, CVE-2018-12130, CVE-2018-12126, CVE-2018-12127, CVE-2019-11091, and (irrelevant to us) CVE-2019-1649, CVE-2019-3568
2019-05-15 10:48:05 <_ikke_> fcolista: Do you mind moving corebird to unmaintained? Upstream says it stops working after August
2019-05-15 10:49:07 <fcolista> sure, done
2019-05-15 10:49:42 <_ikke_> thanks
2019-05-15 11:07:58 <danieli> if there are multiple patch files to be applied in an apkbuild, which order are they applied in?
2019-05-15 11:08:10 <danieli> the order they are specified?
2019-05-15 11:08:49 <Cogitri> I think so, yes
2019-05-15 11:10:30 <mps> danieli: ncopa once explained this to me, in order as they specified, right
2019-05-15 11:10:37 <danieli> thanks
2019-05-15 11:11:32 <mps> I didn't tested, to be fair
2019-05-15 11:12:33 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n643
2019-05-15 11:12:52 <_ikke_> just a for loop over source and if it ends with *.patch, it's applied
2019-05-15 11:12:55 <_ikke_> so yes, source order
2019-05-15 11:13:50 <mps> _ikke_: thanks, so I don't need even to test it :)
2019-05-15 11:46:29 <xorex> h
2019-05-15 11:46:31 <xorex> ah
2019-05-15 11:46:38 <xorex> oh woops, wrong channel
2019-05-15 11:49:42 <mps> tcely: thanks, setting pkgbasedir works
2019-05-15 13:03:36 <tcely> mps: you are welcome
2019-05-15 13:09:39 <tcely> It looks like having an unfinished directory under aports would be a good idea. Ideally, we would not need to go through committees to make changes in that directory. For now, policy for unfinished should be to accept patches there until a move to testing. Before moving to testing we should review for sanity checks.
2019-05-15 13:10:34 <tcely> The idea is to collect "ugly" aports work from forks into unfinished for others to move forward with.
2019-05-15 13:11:44 <danieli> could entice some people to contribute with 'a beginning' for someone else wanting a package in alpine
2019-05-15 13:25:08 <north1> So kinda like exherbo graveyard?
2019-05-15 13:25:11 <north1> @cogitri
2019-05-15 13:29:20 <_ikke_> maybe a seperate repo, not aports
2019-05-15 13:29:54 <danieli> agreed
2019-05-15 13:29:55 <danieli> aports-staging with a fitting description, perhaps?
2019-05-15 13:30:41 <mps> also I think it is better to be separate repo
2019-05-15 13:38:43 <kmaxwell> _ikke_: pr7883 look like a good approach to me
2019-05-15 14:10:55 <tcely> _ikke_: uports? ;-)
2019-05-15 14:11:25 <danieli> clever, i like it
2019-05-15 14:11:34 <danieli> but people could also mis-read it at a glance
2019-05-15 14:12:49 <tcely> U-Ports the U-Haul of aports
2019-05-15 14:13:03 <north1> Alpine User Repositories or AUR for short
2019-05-15 14:13:33 <SpaceToast> could go Alpine User Ports (AUP) for differentiation at that point ;)
2019-05-15 14:13:47 <SpaceToast> lighter due to P having one line less than R!
2019-05-15 14:14:01 <SpaceToast> seriously though, I was under the impression that was the purpose of testing/
2019-05-15 14:14:17 <danieli> i feel like testing is more of a staging area, and it's built for edge
2019-05-15 14:14:35 <danieli> the idea is a repo for ports that are too ugly for upstream alpine to accept them in their current state
2019-05-15 14:14:52 <SpaceToast> so to avoid cluttering aports' issues with [WIP] PRs?
2019-05-15 14:14:53 <danieli> i.e. ports that someone would need to spend some effort on fixing to upstream them
2019-05-15 14:15:09 <tcely> The expectation is that you can build things in testing IIUC
2019-05-15 14:15:23 <danieli> yes, testing is built (on edge)
2019-05-15 14:15:58 <SpaceToast> I'm not sure why one may want a repo for things that don't even really build ^^;;
2019-05-15 14:16:23 <tcely> To encourage help in getting them into testing
2019-05-15 14:17:06 <SpaceToast> ok, I do wonder how/if it'd work out
2019-05-15 14:17:47 <tcely> These things exist all over the place in various states. We want to collect them and encourage their inclusion in aports wherever possible.
2019-05-15 14:17:48 <danieli> i don't see any reason not to do it
2019-05-15 14:17:53 <Cogitri> As long as the AUP doesn't lead to the upstream repos drying out because the majority doesn't want to go through the trouble of upstreaming their stuff
2019-05-15 14:18:17 <Cogitri> The AUR has lead to Arch having pretty slim main repos
2019-05-15 14:18:52 <danieli> perhaps they should've considered making the policies for getting stuff into arch repos more lax if that's considered an issue
2019-05-15 14:19:06 <Cogitri> And the AUR usually just doesn't have good quality packages (especially since the only way to provide feedback is by making comments and those may or may not be applied)
2019-05-15 14:19:47 <danieli> i rarely have issues with aur packages
2019-05-15 14:19:51 <Cogitri> danieli: I don't know Arch well, but I doubt that's the reason. Why go through the trouble of having to deal with a review when you can just put it in the AUR
2019-05-15 14:19:58 <danieli> it's my daily driver
2019-05-15 14:20:40 <tcely> Avoiding fragmentation and encouraging quality improvements both seem like excellent reasons to attempt this to me.
2019-05-15 14:21:40 <eu> what about the man power to merge PRs?
2019-05-15 14:22:03 <danieli> ^ that's more of an issue, i'd say
2019-05-15 14:22:06 <danieli> reviewing and merging them
2019-05-15 14:22:08 <eu> the compelling thing about AUR (and also what makes it awful and a security nightmare) is that it's self service
2019-05-15 14:22:08 <tcely> eu: ideally this should be self-service
2019-05-15 14:22:18 <eu> can't do that with github afaik
2019-05-15 14:22:35 <danieli> not without bots
2019-05-15 14:22:35 <eu> or, could do it with a bot
2019-05-15 14:22:39 <danieli> yup
2019-05-15 14:22:39 <eu> yeah
2019-05-15 14:22:56 <eu> maybe with some light filtering
2019-05-15 14:23:22 <danieli> it's easy with aur because every package is a separate repo
2019-05-15 14:23:26 <danieli> they can be cloned separately too
2019-05-15 14:23:39 <tcely> I see AUR as being a problem only in that you can install from there. I'd like to CI these, but not publish them.
2019-05-15 14:23:44 <eu> but the problem with that aproach is that if some of these AUP APKBUILDs become very popylar, I could just open a PR that is automerged that adds a rm -rf /
2019-05-15 14:24:02 <eu> so the bot would need to track the owner of each build
2019-05-15 14:24:11 <danieli> that has been an issue with aur, yes
2019-05-15 14:24:28 <danieli> malicious code hidden in pkgbuilds/patches/whatever because every package is like a drop in the ocean
2019-05-15 14:24:38 <danieli> it's pretty much self service
2019-05-15 14:25:09 <eu> but I can't go and add a bitcoin miner to the most used AUR builds
2019-05-15 14:25:46 <eu> if I install a fresh new AUR build and don't check the PKGBUILD I'm just stupid
2019-05-15 14:25:56 <eu> with no votes etch
2019-05-15 14:26:02 <eu> s/etch/etc/
2019-05-15 14:26:02 <alpine-meetbot> eu meant to say: with no votes etc
2019-05-15 14:26:06 <tcely> eu: what prevents miners / rm for popular AURs now?
2019-05-15 14:26:07 <north1> eu: Heh, I'll find a way one day
2019-05-15 14:26:32 <eu> the miner/rm would need to be submitted by the package owner
2019-05-15 14:28:26 <danieli> yes, aur helpers should (and most do) offer to display/edit the apkbuild
2019-05-15 14:28:29 <danieli> the pkgbuild*
2019-05-15 14:28:45 <tcely> Ok. I don't see that as an issue with this proposal though. We aren't trying to allow running uports, just CI them before moving them to aports/testing for more review.
2019-05-15 14:30:26 <tcely> If you blow up a docker container then CI should fail.
2019-05-15 14:30:56 <Cogitri> So you want to automerge PRs that target testing/?
2019-05-15 14:31:23 <tcely> No. I want to auto merge in uports.
2019-05-15 14:31:33 <danieli> there's no such thing as "uports" yet
2019-05-15 14:31:37 <danieli> let's not get ahead of ourselves
2019-05-15 14:33:23 <tcely> unfinished / uports should be self-service to avoid adding lots of work for committers / reviewers.
2019-05-15 14:34:09 <tcely> The idea here is to graduate these to testing where normal checks would then apply.
2019-05-15 14:36:17 <danieli> ah, who am i kidding
2019-05-15 14:36:19 <danieli> this is none of my business
2019-05-15 14:44:59 <north1> Who was that wanted stable output for alint?
2019-05-15 14:45:25 <north1> Please open an issue about it on maxice8/atools
2019-05-15 14:45:34 <SpaceToast> I don't think they're here
2019-05-15 14:52:15 <tcely> so to summarize:
2019-05-15 14:52:16 <tcely> * _ikke_ suggests not in aports, so we use uports (or better name TBD later)
2019-05-15 14:52:16 <tcely> * voting is a good idea and we need a merge bot anyway, X number of approvals before merge bots exist already
2019-05-15 14:52:16 <tcely> * CI should be used to encourage improvements
2019-05-15 14:52:16 <tcely> * policy should be to allow broken / unfinished submissions
2019-05-15 14:52:20 <tcely> * No uploading to mirrors from this repository
2019-05-15 14:52:53 <north1> Who can vote?
2019-05-15 14:53:22 <tcely> I'd say anyone not the author would be good
2019-05-15 14:54:06 <north1> What mechanisms to stop someone from faking lots of votes?
2019-05-15 15:02:48 <tcely> None. What does faking votes get them?
2019-05-15 15:03:22 <north1> Why even vote if I can trivially bypass it?
2019-05-15 15:03:55 <tcely> To save on CI resources was my thought.
2019-05-15 15:05:11 <north1> Are we even going to use Alpine resources for that? Much rather it go for something like s390x support on CI
2019-05-15 15:05:57 <tcely> I would expect CI to be cloud like it is for aports
2019-05-15 15:08:41 <ddevault> is it really that hard to get packages into aports? I've never had an issue
2019-05-15 15:09:07 <danieli> ddevault: it isn't imo
2019-05-15 15:09:20 <ddevault> I'm -1 to an AUR-alike option for alpine
2019-05-15 15:09:31 <north1> It can probably be intimidating the first time but I think that is natural with contributing with any new project
2019-05-15 15:09:58 <danieli> north1: the same thing goes for just about anything
2019-05-15 15:10:04 <tcely> I haven't either, we are apparently not in the group that keeps personal aports though
2019-05-15 15:10:22 <ddevault> I do keep personal aports, but not because they'd be hard to get into upstream aports
2019-05-15 15:10:36 <danieli> ddevault: me too, but that's besides the point - i think what they want is a separate repo for unfinished/half-assed work, for someone else to continue working on it
2019-05-15 15:10:53 <ddevault> I think that's called "drop a bad patch on alpine-aports"
2019-05-15 15:11:12 <danieli> to get buried in the practically unsearchable ML?
2019-05-15 15:11:23 <Cogitri> +1 on the -1 for the AUR-ish thing
2019-05-15 15:11:24 <ddevault> it'll be far more searchable when the list.sr.ht migration is complete
2019-05-15 15:11:29 <ddevault> I'll poke clandmeter about that today
2019-05-15 15:11:33 <ddevault> clandmeter: (consider yourself poked)
2019-05-15 15:12:14 <danieli> if i was looking for something to avoid duplicating work, my first reaction wouldn't be "ah! i should check the mailing list"
2019-05-15 15:12:23 <ddevault> that's cause you're weird
2019-05-15 15:12:29 <ddevault> I check the ML for tha all the time
2019-05-15 15:12:36 <danieli> thank you for the compliment.
2019-05-15 15:12:40 <ddevault> np
2019-05-15 15:14:00 <SpaceToast> theory of mind strikes again, I see ;)
2019-05-15 15:14:30 <ddevault> it was a joke, I'll speak with danieli out-of-band about it
2019-05-15 15:15:39 <SpaceToast> I know it was a joke. He, meanwhile, has been taking things seriously and been somewhat defensive since coming back... which is why I've generally tried to avoid directly contradicting even some of the more egregious misunderstandings :/
2019-05-15 15:16:01 <ddevault> perhaps further comment would be more appropriate for a private message
2019-05-15 15:20:38 <tcely> Can I clone the results from parsing the ML?
2019-05-15 15:20:57 <ddevault> ?
2019-05-15 15:21:06 <ddevault> like do you mean can you bring the patch into git locally?
2019-05-15 15:21:48 <tcely> I mean can all the patches be had from sourcehut parsing them on the ML?
2019-05-15 15:22:22 <ddevault> I don't really understand your question
2019-05-15 15:22:29 <ddevault> but if you want to see how sourcehut handles patches on mailing lists
2019-05-15 15:22:37 <ddevault> here's an example: https://lists.sr.ht/~philmd/qemu/patches/5556
2019-05-15 15:24:05 <tcely> So it looks like the answer is there is no repo / fork that I can clone that includes patches from the ML
2019-05-15 15:24:16 <mps> ddevault: nice, although I would like  '>' quoting
2019-05-15 15:24:45 <ddevault> tcely: check out the "export patchset" thing, look at "how do I use this" to see how to get the patch locally
2019-05-15 15:25:05 <ddevault> mps: it's still > in your inbox ;)
2019-05-15 15:25:26 <ddevault> mps: this is generated from normal patch discussion, the participants aren't even aware their emails are being rendered like this
2019-05-15 15:25:30 <mps> aha, good
2019-05-15 15:25:48 <tcely> I'm looking to avoid manual work and centralize these things. The ML doesn't seem to help with either goal.
2019-05-15 15:26:35 <ddevault> it's less work if you subscribe to the ml and use a local mail client like I do
2019-05-15 15:26:36 <mps> my eyes are not accustomed to frames
2019-05-15 15:26:43 <ddevault> cloning the branch is still manual work, too
2019-05-15 15:26:50 <ddevault> it's just _different_ work
2019-05-15 15:27:19 <tcely> It is far less than exporting / patching for each patchset
2019-05-15 15:27:23 <mps> I think mutt have hook somewhere to 'git am' from mail
2019-05-15 15:27:36 <ddevault> no, it's really not
2019-05-15 15:27:43 <ddevault> don't knock it until you've tried it
2019-05-15 15:27:50 <ddevault> this workflow is _much_ less work than github et al
2019-05-15 15:28:40 <tcely> Are you counting only yourself in the work calculation?
2019-05-15 15:28:55 <mps> ddevault: btw, you had post (blog) somewhere about mail workflow, iirc, which explains all that
2019-05-15 15:29:01 <ddevault> I really don't want to argue with you, tcely
2019-05-15 15:29:06 <ddevault> I'm in the middle of other stuff
2019-05-15 15:29:35 <ddevault> as someone who is very comfortable with both workflows, I'd like you to familiarize yourself with both too before you dismiss my arguments
2019-05-15 15:29:58 <ddevault> mps: I have a few, most recently this: https://drewdevault.com/2019/05/13/Git-email-webcast.html
2019-05-15 15:30:57 <tcely> ddevault: I'm asking you to explain your conclusion not dismissing your argument.
2019-05-15 15:31:08 <mps> will look and search your old post, to have it at hand if someone ask ;)
2019-05-15 15:31:35 <ddevault> tcely: well, you'd be about the umpteenth person who wants that
2019-05-15 15:31:44 <ddevault> it's easier to ask you to try the workflow before you dismiss it than it is to repeat myself for the umpteenth time
2019-05-15 15:31:50 <ddevault> and that seems pretty reasonable to me
2019-05-15 15:32:01 <ddevault> regardless, I'll go dig up the last time I went through this
2019-05-15 15:32:46 <ddevault> https://old.reddit.com/r/linux/comments/b9f1e5/gitsendemailio_learn_to_use_email_with_git/ek4hg7p/
2019-05-15 15:32:47 <alpine-meetbot> [REDDIT] git-send-email.io: Learn to use email with Git! (https://git-send-email.io/) to r/linux | 142 points (97.0%) | 45 comments | Posted by emersion_fr | Created at 2019-04-04 - 16:35:55UTC
2019-05-15 15:33:18 <ddevault> for the review side of this, see that link I just gave to mps
2019-05-15 15:33:22 <tcely> ddevault: thank you for the link
2019-05-15 15:36:40 <ddevault> also, you can totally write some kind of script which pulls patches off of a mailing list and onto a branch on some git repo
2019-05-15 15:37:09 <ddevault> it really annoys me that github does that for PRs though
2019-05-15 15:44:28 <Cogitri> Well, IMO it's not really the submitting a patch thing that gives GH an edge but reviewing the patch. But if I could make review comments via some webUI web-based workflow wouldn't be _that_ bad I guesd
2019-05-15 15:45:01 <SpaceToast> Cogitri: since you seem to have missed it - https://lists.sr.ht/~philmd/qemu/patches/5556 - a demo of how st.ht does it
2019-05-15 15:45:04 <_ikke_> ddevault: if I can do curl <url> | git am, I'd be happy :-)
2019-05-15 15:45:12 <ddevault> you can :)
2019-05-15 15:45:19 <Cogitri> ikke: +1
2019-05-15 15:45:20 <SpaceToast> ^ same as _ikke_
2019-05-15 15:45:30 <SpaceToast> also heya _ikke_ :)
2019-05-15 15:45:34 <ddevault> Cogitri: authoring reviews on the web is under development
2019-05-15 15:45:35 <_ikke_> hi
2019-05-15 15:45:42 <_ikke_> reading back on the backlog
2019-05-15 15:45:58 <SpaceToast> can I PM you for a moment?
2019-05-15 15:46:09 <_ikke_> sure
2019-05-15 15:46:19 <Cogitri> SpaceToast: Yup, I think ddevault has shown me that a few days ago in #alpine-infra which sort of turned my options 180Β° on email :P
2019-05-15 15:46:33 <Cogitri> ddevault: Nice :)
2019-05-15 15:51:20 <SpaceToast> Cogitri: ddevault has committed to making a two-way sync thing between gitlab and lists.sr.ht (hopefully sometime this year), iirc
2019-05-15 15:51:34 <SpaceToast> imo that would get us the best of both worlds - everyone can use the workflow they prefer without being isolated
2019-05-15 15:53:05 <Cogitri> Yep, that'd be amazing!
2019-05-15 15:53:25 <SpaceToast> he was the one to come up with it too, very elegant solution :)
2019-05-15 16:36:09 <_ikke_> north1: One thing alint probably does not account for is: cd foo; cd "$builddir"
2019-05-15 16:37:24 <north1> _ikke_: I guess, I'll try to have it match only spaces/tabs before the statement
2019-05-15 16:37:29 <north1> Can you open an issue on atools?
2019-05-15 16:37:31 <north1> I might forget this
2019-05-15 16:37:58 <_ikke_> I mean more that it would complain about cd "$builddir" while in that case it's valid
2019-05-15 17:49:53 <north1> I can problably implement function parsing
2019-05-15 17:51:03 <_ikke_> I was thinking about extending shellcheck
2019-05-15 17:51:55 <north1> For?
2019-05-15 17:52:11 <_ikke_> Tailored checks for apkbuilds
2019-05-15 17:54:41 <north1> It is haskell
2019-05-15 17:54:45 <_ikke_> yes, it is
2019-05-15 17:55:49 <north1> Good luck :D
2019-05-15 17:55:55 <_ikke_> :-)
2019-05-15 17:56:05 <_ikke_> I have a little experience with haskell
2019-05-15 17:56:41 <Cogitri> Hit me up if you do it in Rust or a sane lang :P
2019-05-15 17:56:51 <_ikke_> Well, shellcheck already exists
2019-05-15 17:56:53 <north1> I'll just typeset build and grep
2019-05-15 17:57:17 <_ikke_> I haskell is pretty sane :)
2019-05-15 17:59:34 <Cogitri> At least from a packaging standpoint it doesn't seem like it is :P
2019-05-15 18:00:52 <_ikke_> Talking about rust...
2019-05-15 18:01:43 <SpaceToast> actual rust packages aren't that bad (the ones using clap or w.e for completions are annoying though), but rust itself...
2019-05-15 18:02:03 <SpaceToast> I prefer the ML side of functional langs (F#/OCaml and co) though :)
2019-05-15 18:04:23 <Cogitri> Hm, packaging Rustc isn't that fun but so are other selfhosted compilers
2019-05-15 18:04:42 <_ikke_> rust is making it harder and harder though
2019-05-15 18:04:55 <Cogitri> How come you think clap.rs stuff is annoying?
2019-05-15 18:05:11 <_ikke_> no backwards compattibility, requiring cargo to compile
2019-05-15 18:05:21 <SpaceToast> because you have to go fishing in the build artifacts for the resulting completions
2019-05-15 18:05:30 <SpaceToast> lots of globbing etc
2019-05-15 18:05:41 <SpaceToast> some people explicitly send it to a dir, but that's the minority
2019-05-15 18:06:17 <Cogitri> Ah, alright
2019-05-15 18:06:27 <Cogitri> _ikke_: Alright, that's fair
2019-05-15 18:07:06 <Cogitri> But making a seperate build system just for Rustc seems a bit over the top when one can just build cargo statically
2019-05-15 18:07:26 <SpaceToast> no one said "making", I suspect everyone would be content with "using" :)
2019-05-15 18:12:09 <mps> hmm, there is perl, practical extracting regex lang
2019-05-15 18:12:43 <tcely> I think that r is another word
2019-05-15 18:13:24 <mps> yes, but I screwed it by intention ;)
2019-05-15 18:14:19 <mps> anyway, perl is one of the best solutions for text processing
2019-05-15 18:16:13 <SpaceToast> text processing and language parsing are slightly different things :)
2019-05-15 18:16:26 <SpaceToast> but honestly I don't really care enough, if _ikke_ writes it in haskell and it works well, great!
2019-05-15 18:17:58 <_ikke_> I have no clue if I can get it to work, but I want to at least try it
2019-05-15 18:18:08 <mps> also I don't care, especially if it doesn't pull a lot of dependencies to work
2019-05-15 18:19:10 <_ikke_> You can get a statically compiled binary right now
2019-05-15 18:19:18 <Cogitri> Well, since Haskell builds static binaries that won't be of much concern I guess
2019-05-15 18:23:24 <_ikke_> So there are two tests failing in nbd..
2019-05-15 18:23:32 <_ikke_> Trying to find out what's causing it
2019-05-15 18:25:12 <_ikke_> "Could not run test: Could not read size: Resource temporarily unavailable"
2019-05-15 18:27:09 <mps> _ikke_: I think iwd should be disabled on s390x, at least temporary till someone with access to s390x find time to look at it
2019-05-15 18:27:34 <mps> what do you think
2019-05-15 18:27:49 <_ikke_> Sound like a plan :)
2019-05-15 18:28:10 <mps> ok, will do
2019-05-15 18:28:44 <mps> no need to do pkgrel bump?
2019-05-15 18:28:54 <_ikke_> no, not to disabling a failing build
2019-05-15 18:29:24 <mps> ok, thanks
2019-05-15 18:33:06 <_ikke_> I think nbd segfaults
2019-05-15 18:33:19 <_ikke_> [pid  9154] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x28} ---
2019-05-15 18:33:40 <_ikke_> nbd-server[12668]: segfault at 28 ip 00007f45687b44fb sp 00007ffc20fa71e0 error 4 in ld-musl-x86_64.so.1[7f4568793000+46000]
2019-05-15 18:34:02 <mps> only on x86?
2019-05-15 18:35:25 <_ikke_> I see it on x86_64, ppc64le
2019-05-15 18:35:59 <_ikke_> s390x, armv7
2019-05-15 18:36:04 <_ikke_> So I assume all arches
2019-05-15 18:36:13 <mps> ahm everywhere
2019-05-15 18:36:48 <_ikke_> I guess some incompattibility with musl
2019-05-15 18:37:01 <mps> will try now locally
2019-05-15 18:37:54 <mps> sure, and locally also segfaults
2019-05-15 18:38:20 <_ikke_> yes, for me as well
2019-05-15 18:43:12 <_ikke_> so both the unix and the inetd versions segfault
2019-05-15 18:44:18 <mps> yes
2019-05-15 18:44:42 <_ikke_> https://github.com/NetworkBlockDevice/nbd/
2019-05-15 18:45:50 <mps> have to go, if you solve it i will don't have to look at it when come back
2019-05-15 18:46:22 <_ikke_> I will report it and disable nbd for the time being
2019-05-15 18:49:56 <_ikke_> I think
2019-05-15 18:54:28 <_ikke_> Great, I did something, and now a lot of tests are failing :-/
2019-05-15 18:55:56 <_ikke_> :-/
2019-05-15 19:10:42 <_ikke_> clandmeter: ping
2019-05-15 19:21:02 <clandmeter> Pong
2019-05-15 19:57:55 <_ikke_> clandmeter: What should we do with nbd?
2019-05-15 19:58:10 <_ikke_> 2 tests are failing (and suddenly on my machine, even 13 tests)
2019-05-15 19:58:20 <_ikke_> It's blocking the builders
2019-05-15 19:59:15 <_ikke_> The tests are related to inetd and unix socket (segfault in both cases)
2019-05-15 20:42:47 <clandmeter> _ikke_: it fails on edge?
2019-05-15 20:44:10 <_ikke_> yes
2019-05-15 20:44:33 <clandmeter> but i dont see a commit?
2019-05-15 20:44:54 <_ikke_> Me neither
2019-05-15 20:45:08 <_ikke_> I mean, it's failing on 3.10
2019-05-15 20:45:19 <_ikke_> but if you would try to build it on edge, it would fail as well
2019-05-15 20:45:20 <clandmeter> ok, that makes more sense :)
2019-05-15 20:48:33 <_ikke_> I use to have the same 2 errors on my container, then I started debugging, added a -dbg subpackage, and after that, I suddenly get 13 failed tests
2019-05-15 20:48:53 <clandmeter> i only get 2
2019-05-15 20:49:23 <_ikke_> If you look dmesg output, you'll see you get segfaults
2019-05-15 20:59:39 <clandmeter> _ikke_: im not sure, maybe report upstream and for now disable it.
2019-05-15 20:59:56 <_ikke_> Yeah, that was my idea as well
2019-05-15 21:00:11 <_ikke_> I was working on a nice bug report, until suddenly I got 13 failures
2019-05-15 21:02:01 <clandmeter> are you sure no processes are left running?
2019-05-15 21:02:15 <_ikke_> Hmm, good question, let me check
2019-05-15 21:02:44 <_ikke_> yes, that was it :$
2019-05-15 21:03:01 <clandmeter> :p
2019-05-15 21:03:12 <_ikke_> I started one server in the background, and assumed it crashed
2019-05-15 21:03:22 <_ikke_> fg didn't bring it back
2019-05-15 21:04:02 <_ikke_> 2 of 19 tests failed
2019-05-15 21:04:05 <_ikke_> sanity restored
2019-05-15 21:04:28 <clandmeter> not for long hehe
2019-05-15 21:04:34 <_ikke_> haha :D
2019-05-15 21:39:10 <mps> nbd also segfaults in my test
2019-05-16 00:23:32 <p4Wv1qn095FW> i suspect that #10459 is related to the rebuild against perl 5.28
2019-05-16 00:23:55 <north1> p4Wv1qn095FW: yes, there is a workaround on Void Linux musl
2019-05-16 00:24:07 <north1> I sent the content already, suprised it wasn't sorted out
2019-05-16 00:24:40 <p4Wv1qn095FW> oh. kool. let me check that
2019-05-16 00:24:56 <p4Wv1qn095FW> north1: do you have a link?
2019-05-16 00:25:07 <north1> I'm playing on lichess rn
2019-05-16 00:25:11 <north1> I'll fetch later
2019-05-16 00:27:10 <north1> https://github.com/void-linux/void-packages/pull/1849 https://github.com/void-linux/void-packages/blob/da7eb611cbc7df8ab379082e0c86e4a871ce0750/srcpkgs/perl/template#L182
2019-05-16 00:27:13 <north1> Enjoy
2019-05-16 00:28:15 <north1> Requires rebuild of all Perl modules that link to libperl
2019-05-16 00:30:09 <p4Wv1qn095FW> ohshit.
2019-05-16 00:31:48 <p4Wv1qn095FW> _ikke_: can you handle this please?
2019-05-16 00:36:12 <SpaceToast> let me compile a list real quick...
2019-05-16 00:36:31 <SpaceToast> based on -R and so:libperl.so, at least
2019-05-16 00:37:03 <SpaceToast> (i.e if they put depends=perl it won't show up since libperl.so might not get autodetected)
2019-05-16 00:38:23 <north1> Can also look at the ones that have archs=all
2019-05-16 00:39:09 <SpaceToast> well, that doesn't necessarily mean anything, unfortunately :/
2019-05-16 00:39:25 <SpaceToast> I'm just going for a "these *definitely* need a bump" list :)
2019-05-16 00:39:54 <SpaceToast> https://brpaste.xyz/juhM9A
2019-05-16 00:40:10 <SpaceToast> all of these have a dep on so:libperl.so
2019-05-16 00:40:31 <SpaceToast> if we want to be very careful, we could also just grab all the ones that depend on anything perl
2019-05-16 00:41:10 <p4Wv1qn095FW> thx
2019-05-16 00:41:57 <SpaceToast> (technical details: I looked at all revdeps of perl, and filtered out those that actually dep on so:libperl.so in particular)
2019-05-16 01:13:42 <BTC6760> hello
2019-05-16 01:14:23 <BTC6760> is it possible to cross compile Alpine for ARMv6 (Big endian)?
2019-05-16 01:14:48 <BTC6760> ARMv6EB, also known as TI Puma5
2019-05-16 01:17:44 <BTC6760> TI Puma5 has limited toolchains, but i do have a working uClibc cross compiler. i do not know if there is any working musl cross compilers, though
2019-05-16 01:24:06 <BTC6760> i am just looking for a rootfs, for the most part
2019-05-16 04:37:40 <_ikke_> north1: why do perl modules need a bump in this case?
2019-05-16 04:39:27 <_ikke_> north1: adding -DNO_POSIX_2008_LOCALE to CFLAGS is the fix for perl?
2019-05-16 07:03:06 <clandmeter> https://tpaste.us/ErEW
2019-05-16 08:55:14 <mps> tmhoang: do we need wifi software for s390x
2019-05-16 08:56:15 <mps> I don't know anything about these 'machines'
2019-05-16 10:45:10 <tmhoang> mps: not 100% but confidently I would say no. s390x doesn't even have USB stuffs
2019-05-16 10:45:24 <tmhoang> sorry for late reply and late fix in the last 1-2 days
2019-05-16 10:47:31 <tmhoang> USB and wifi are ones of user-oriented stuffs that I know s390x wouldn't even bother to care
2019-05-16 10:47:52 <tmhoang> about wifi driver iwd : it's a test failure, right ?
2019-05-16 10:52:19 <mps> tmhoang: yes, one test failed. interesting though it worked on previous version (0.17) also on s390x
2019-05-16 10:52:42 <tmhoang> thanks and roger. will find some time today ...
2019-05-16 10:53:09 <mps> ohm btw iwd is Internet Wireless Daemon, not driver
2019-05-16 10:53:44 <mps> and it is wifi client also
2019-05-16 10:55:08 <mps> if the s390x doesn't have wifi hardware then iwd is not useful on it for ordinary users, but maybe could be for those who want to play with wifi simulator
2019-05-16 10:57:31 <mps> I looked at linux-vanilla config for s390x and didn't found anything enabled in relation to wifi
2019-05-16 11:01:48 <Cogitri> IWD needs lots of kernel configs enabled to run (mostly crypto stuff) so yeah
2019-05-16 11:06:07 <mps> most of needed option is already in 4.19, only pkcs8 missing
2019-05-16 11:07:39 <mps> and, iwd will have FILS soon (I think) and built-in dhcp client
2019-05-16 11:10:25 <Cogitri> I use it with NetworkManager because wpa_supplicant wouldn't work for me
2019-05-16 11:12:37 <mps> nice, please report any issue, to bugs.a.o or to me directly, and proposal for enhancements ofc
2019-05-16 11:13:35 <mps> I'm in temptation to enable ead also but don't have environment to test it
2019-05-16 11:18:51 <mps> Cogitri: btw, I noticed you add on text about iwd in networkmanager. nice
2019-05-16 11:20:30 <TBB> wpa_supplicant needs extra configuration to work with networkmanager, just as a side note
2019-05-16 11:20:33 <mps> when I upgraded NM to 1.16 (iirc) I removed it dependency on wpa_supplicant, and you add right thing when you upgrade it
2019-05-16 11:22:11 <mps> TBB: I tried NM with wpa_s earlier but didn't managed to get it working, so switched to wpa_gui and starting dhcp from terminal
2019-05-16 11:25:40 <TBB> it took a change to the starting parameters of wpa_supplicant if I remember correctly; I worked on that for the last couple of weeks before my project ended at the end of the year, and I was silly enough not to take my notes with me when I left
2019-05-16 11:27:49 <Cogitri> mps: Sure, will do
2019-05-16 12:22:33 <nmeum> we have two packages for cython: py-cython and cython
2019-05-16 12:22:45 <nmeum> any preferences regarding which one should be removed?
2019-05-16 12:23:14 <nmeum> only py-msgpack seems to depend on py-cython
2019-05-16 12:34:44 <Cogitri> Well, py2-cython already replaces cython
2019-05-16 12:35:06 <_ikke_> I think we talked about that earlier
2019-05-16 12:36:11 <Cogitri> Ah
2019-05-16 12:39:21 <nmeum> oh
2019-05-16 12:41:24 <_ikke_> I think we deciced then to call it just cython
2019-05-16 12:42:05 <_ikke_> As it's not a python library / module, but more like an interpreter / compiler
2019-05-16 12:43:07 <nmeum> well…technically it also ships a python library
2019-05-16 12:43:22 <Cogitri> So it's going to be just cython with no subpkgs (other than ones for `replaces`?)
2019-05-16 12:43:23 <nmeum> but doesn't matter really regarding the decision which one to remove
2019-05-16 13:08:56 <MartijnBraam> There seems to be a bunch of systemd stuff in the plymouth package in the alpine repositories
2019-05-16 13:14:31 <TBB> there at least was, it used to throw unnecessary files to fs root
2019-05-16 13:15:03 <TBB> haven't really had a closer look in half a year tho, I remember having to fix it for an internal project
2019-05-16 13:32:57 <PureTryOut[m]> Would this be accepted if we would try to upstream it? https://gitlab.com/postmarketOS/pmaports/blob/master/temp/u-boot/APKBUILD#L50
2019-05-16 13:33:16 <PureTryOut[m]> It uses source code downloaded from another project (arm-trusted-firmware). It's required to make Allwinner devices work with u-boot
2019-05-16 13:38:11 <mps> PureTryOut[m]: is that free software
2019-05-16 13:38:29 <PureTryOut[m]> BSD-3 licensed, yes
2019-05-16 13:39:46 <mps> then it probably could be added, but you first need sync with current aports, APKBUILD is old
2019-05-16 13:39:52 <PureTryOut[m]> That repo contains some 3rd party code which is all free software as well
2019-05-16 13:40:36 <PureTryOut[m]> Yeah sure
2019-05-16 13:41:23 <PureTryOut[m]> I was experimenting with having `arm-trusted-firmware` be a separate package, and be a build time dependency for u-boot but only on aarch64. abuild doesn't seem to like it though
2019-05-16 13:43:12 <mps> you can post your APKBUILD and I and probably some other people interested in arm will look at it
2019-05-16 13:43:33 <PureTryOut[m]> Thanks will do
2019-05-16 13:57:24 <nmeum> _ikke_: https://github.com/alpinelinux/aports/pull/7898 would also be fine with removing community/cython instead
2019-05-16 14:30:42 <PureTryOut[m]> mps: made a PR https://github.com/alpinelinux/aports/pull/7899/files
2019-05-16 14:33:53 <mps> PureTryOut[m]: ok, I will try to build it but right now don't have time
2019-05-16 14:34:09 <PureTryOut[m]> No problem
2019-05-16 15:29:35 <tmhoang> civetweb seems to be something cool for aports
2019-05-16 15:32:51 <tmhoang> or even mongoose
2019-05-16 17:06:43 <tmhoang> s390x builder seems down. maintenance is ongoing.
2019-05-16 18:13:56 <tmhoang> clandmeter: s390x.alpinelinux.org is up. Would you mind logging in and enable the builders in lxc ?
2019-05-16 18:17:54 <tmhoang> never mind they are still messing up with outbound interface. haizzz
2019-05-16 18:32:03 <mps> PureTryOut[m]: I tried to build your PR (you forgot checksum update, btw) and it pass 'abuild -r'
2019-05-16 18:34:04 <mps> but after looking at it I think it would be better to make separate package, i.e. `arm-trusted-firmware` APKBUILD
2019-05-16 19:02:55 <north1> Good news, tomorrow at 17:00 (BRT) I'll get my notebook back
2019-05-16 19:09:20 <mps> PureTryOut[m]: well, I made `arm-trusted-firmware` APKBUILD and build it, but don't know where to put resulting .bin file in package()
2019-05-16 23:55:25 <PureTryOut[m]> mps: hmm, even when running `abuild checksum` nothing changes?
2019-05-16 23:57:01 <PureTryOut[m]> Yeah I was trying to make `arm-trusted-firmware` a separate package, however it had trouble resolving the package when adding it as a makedepends for just aarch64. Since I was building it on postmarketOS using our pmbootstrap, that might just be a pmbootstrap problem though
2019-05-16 23:58:03 <PureTryOut[m]> Since `arm-trusted-firmware` would just be used as a `$makedepends`, it doesn't really matter where to put the resulting .bin file. I just put it in `$pkgdir/usr/share/$pkgname`, and used that as `export BL31` in `u-boot`
2019-05-16 23:59:17 <mps> PureTryOut[m]: I'm just preparing for bed, could we continue tomorrow
2019-05-16 23:59:28 <PureTryOut[m]> Of course!
2019-05-16 23:59:36 <SpaceToast> anyone awake right now have access to github tagging?
2019-05-16 23:59:38 <mps> ok, good night to all
2019-05-16 23:59:47 <PureTryOut[m]> Good night!
2019-05-17 04:08:12 <tcely> SpaceToast: what about the tagging?
2019-05-17 04:08:42 <SpaceToast> hey tcely :) https://github.com/alpinelinux/aports/pull/7907 and https://github.com/alpinelinux/aports/pull/7895 need ci-malfunction
2019-05-17 04:08:57 <SpaceToast> bit late here though, so I'ma head (back) off now \o
2019-05-17 04:09:15 <tcely> ok. I'll take a look.
2019-05-17 06:36:36 <clandmeter> tcely: projects are enabled
2019-05-17 06:37:27 <Cogitri> Nice
2019-05-17 07:40:23 <tcely> clandmeter: are you seeing the projects tab under aports? I'm not yet.
2019-05-17 07:40:46 <clandmeter> ah maybe i need to still enable it per repo
2019-05-17 07:41:16 <clandmeter> check now
2019-05-17 07:42:10 <tcely> I see it. Thanks.
2019-05-17 07:42:16 <clandmeter> weird, it said Enable projects for all repositories.
2019-05-17 07:42:28 <clandmeter> but you still need to manually enable them...
2019-05-17 07:42:53 <clandmeter> maybe because it was explicitly disabled before.
2019-05-17 10:48:04 <_ikke_> clandmeter: This is the backtrace I get from nbd (inetd)
2019-05-17 10:48:06 <_ikke_> http://tpaste.us/jX9e
2019-05-17 14:03:08 <clandmeter> _ikke_: is that with both musl and nbd symbols installed?
2019-05-17 14:03:39 <_ikke_> Not entirely sure what you mean with that
2019-05-17 14:03:50 <clandmeter> dbg packages
2019-05-17 14:03:51 <_ikke_> you mean debug symbols?
2019-05-17 14:04:00 <clandmeter> yes
2019-05-17 14:04:05 <_ikke_> I built nbd with -g -O0
2019-05-17 14:04:15 <_ikke_> I didn't install musl debug symbols, so will do that
2019-05-17 14:05:06 <_ikke_> clandmeter: I already found out it's doing a freeaddrinfo on a null pointer
2019-05-17 14:05:26 <_ikke_> so an easy fix would be if (ai) { freeaddrinfo(ai); }
2019-05-17 14:11:21 <clandmeter> ok, i dont think i can help you with that.
2019-05-17 14:12:39 <_ikke_> Yeah, just trying the trivial fix, and if that doesn't help, I'll report it upstream
2019-05-17 14:13:50 <clandmeter> you can also ask in musl if you want
2019-05-17 14:30:02 <TML> I am trying to build a custom kernel, but "abuild -rK" in aports/main/linux-vanilla gives me "linux-4.19.tar.xz is missing in checksums"; however, I can quite clearly see it as the first entry in the sha512sums section of the ABUILD
2019-05-17 14:30:28 <TML> sha512sums="ab67cc746b375a8b135e8b23e35e1d6787930d19b3c26b2679787d62951cbdbc3bb66f8ededeb9b890e5008b2459397f9018f1a6772fdef67780b06a4cb9f6f4  linux-4.19.tar.xz…
2019-05-17 14:31:56 <clandmeter> maybe run it with -v and see what it tries to do
2019-05-17 14:42:32 <TML> clandmeter: Thanks, that did it.
2019-05-17 14:42:44 <TML> seems abuild relies on IFS having space in it
2019-05-17 14:46:25 <TML> (I usually define my IFS as $'\t\n' - no space)
2019-05-17 15:34:47 <_ikke_> clandmeter: thanks, adding musl-dbg improved the situation: http://tpaste.us/DLve
2019-05-17 15:56:04 <_ikke_> clandmeter: Afaik, it's a bug in nbd
2019-05-17 15:56:29 <_ikke_> It does a freeaddrinfo on ai, but not all code paths set it
2019-05-17 16:06:07 <_ikke_> clandmeter: Nice, fixed it
2019-05-17 16:06:27 <_ikke_> at least, I think I fixed it :)
2019-05-17 16:06:50 <_ikke_> http://tpaste.us/NKpm
2019-05-17 16:26:58 <mksully22> fyi, added PR to upgrade and fix hugo for 3.10 build, https://github.com/alpinelinux/aports/pull/7912 if someone wants to review
2019-05-17 16:27:30 <_ikke_> mksully22: checking
2019-05-17 16:27:56 <_ikke_> I have a fix for nbd as well
2019-05-17 16:28:39 <mksully22> awesome!
2019-05-17 16:30:31 <_ikke_> mksully22: https://github.com/alpinelinux/aports/pull/7913
2019-05-17 16:31:37 <_ikke_> now including patch :D
2019-05-17 16:35:01 <_ikke_> mksully22: are you basicaly just removing some tests?
2019-05-17 16:41:28 <mksully22> _ikke_: no not really. In the earlier version the test was already removed/disabled. But there was still the "os" package being imported that was not being used. At the later versions of hugo this seems to cause the error. So the fix really just removed the "os" import
2019-05-17 16:41:56 <_ikke_> mksully22: alright, thanks
2019-05-17 16:42:06 <mksully22> _ikke_: and your patch built fine on my ppc64le setup
2019-05-17 16:42:09 <_ikke_> The diff is a bit confusing
2019-05-17 16:42:11 <_ikke_> mksully22: Nice
2019-05-17 16:42:32 <mksully22> yes it looks messy because it's a patch to a patch :)
2019-05-17 16:42:35 <_ikke_> nbd just carelessly calls freeaddrinfo on ai
2019-05-17 16:44:18 <mksully22> nice
2019-05-17 16:46:56 <_ikke_> mksully22: I wonder why the ppc64le and s390x builder keep building those pacakges
2019-05-17 16:46:58 <_ikke_> packages*
2019-05-17 16:57:13 <mksully22> Not sure, i think for ppc64le there are only 4 packages left that haven't been successfully rebuilt so it just keeps trying them over and over.
2019-05-17 17:06:29 <_ikke_> ah ok
2019-05-17 17:06:42 <_ikke_> I'm looking now at lua-copas
2019-05-17 18:21:01 <_ikke_> apparently lua-copas is failing upstream as well /o\
2019-05-17 18:21:48 <_ikke_> The test is weird. They are testing 1 url and expecting different behaviour
2019-05-17 18:23:09 <_ikke_> And that test hasn't changed for over 3 years :/
2019-05-17 18:25:37 <mps> I looked it at and don't understand that failed test
2019-05-17 18:26:31 <_ikke_> What I see is that in the next test, they query the exact same url
2019-05-17 18:26:38 <_ikke_> and in that case, they say it should not be allowed
2019-05-17 18:26:48 <_ikke_> so the test that is failing tests that that url should just return
2019-05-17 18:26:49 <_ikke_> ok
2019-05-17 18:27:15 <_ikke_> so 1 url, but in one case it's expect to succeed, and in the other case it's expected to return an error
2019-05-17 18:28:29 <mps> I didn't looked deep in but will try it on x86_64 (when come to home) to see if it makes difference
2019-05-17 18:28:44 <_ikke_> I don't think that would make a difference
2019-05-17 18:28:47 <_ikke_> this is just a logic error
2019-05-17 18:29:26 <_ikke_> It's like testing a site with an expired domain. In one test, you verify that it returns 200 ok, and in the next test, you verify that it return an error
2019-05-17 18:29:26 <mps> well, #alpine-commits show only ppc64le
2019-05-17 18:29:36 <_ikke_> Others haven't reached it yet
2019-05-17 18:29:46 <mps> ah, so
2019-05-17 18:30:25 <_ikke_> It fails on my machine as well
2019-05-17 18:31:31 <mps> aha, I don't need to try
2019-05-17 18:32:30 <_ikke_> I patch that specific test out, because it makes no sense to me
2019-05-17 18:33:20 <clandmeter> _ikke_: \o/
2019-05-17 18:34:05 <mps> tried with curl, and got HTTP 301 Moved Permanently
2019-05-17 18:34:26 <_ikke_> Yes, it's just a set of redirecting urls
2019-05-17 18:34:39 <_ikke_> They want to check that it fails when you redirect from https to http
2019-05-17 18:34:58 <_ikke_> But in the test before, they check if the exact same redirect succeeds
2019-05-17 18:35:26 <_ikke_> You cannot expect it to succeed and fail at the same time, unless they have some kind of quantum logic built in
2019-05-17 18:35:43 <_ikke_> Anyone objecting to this? http://tpaste.us/xpz1
2019-05-17 18:36:38 <mps> it have ' assert(tonumber(code)==200)'
2019-05-17 18:37:58 <_ikke_> oh, I missed one small detail in my assertion
2019-05-17 18:38:11 <_ikke_> in one case, they use http, and in the other, https
2019-05-17 18:38:55 <_ikke_> I think what changed is that google started to redirect to https
2019-05-17 18:39:00 <_ikke_> which broke the test
2019-05-17 18:40:22 <_ikke_> So they expect: http://goo.gl/tBfqNu -> http://www.thijsschreijer.nl/blog/, but what happens is: http://goo.gl/tBfqNu -> https://goo.gl/tBfqNu -> http://www.thijsschreijer.nl/blog/
2019-05-17 18:41:06 <mps> yes
2019-05-17 18:41:49 <_ikke_> and because now it's https -> http, the library returns an error
2019-05-17 18:45:07 <_ikke_> https://github.com/keplerproject/copas/issues/75
2019-05-17 18:45:28 <mps> hmm, this test looks strange, but I'm not expert in lua testing
2019-05-17 18:45:46 <_ikke_> It's just something custom
2019-05-17 18:46:08 <_ikke_> I'm not familiar with lua either, but I can at least follow what is happening
2019-05-17 18:46:45 <mps> I see, you posted bug report to upstream.
2019-05-17 18:47:18 <_ikke_> indeed
2019-05-17 18:48:03 <_ikke_> boom
2019-05-17 18:48:04 <_ikke_> pushed
2019-05-17 18:49:43 <_ikke_> It's good that Alpine stimulates to run the test suite, it catches a lot of subtle bugs / errors
2019-05-17 18:50:05 <mps> good, only to remember your bug report if they answer
2019-05-17 18:50:06 <_ikke_> I still recall the incident that triggered this policy
2019-05-17 18:50:27 <_ikke_> I will be notified if they reply
2019-05-17 18:50:44 <tcely> _ikke_: is it story time? ;-)
2019-05-17 18:50:54 <_ikke_> Trying to recall all the details
2019-05-17 18:51:21 <mps> so, GH notify you by mail if your bug is answered?
2019-05-17 18:51:26 <_ikke_> yes
2019-05-17 18:51:30 <_ikke_> and also in the interface as well
2019-05-17 18:52:04 <mps> not bad, only if they 'open source' it :P
2019-05-17 18:52:22 <_ikke_> I reported an issue about ruby-enum, and the author responded within a couple of hours
2019-05-17 18:53:32 <_ikke_> tcely: I don't know the exact details anymore, but someone found out that some certificate was accepted while it should be rejected, due to a bug in one of the ssl libraries
2019-05-17 18:53:49 <_ikke_> Probably in combination with musl
2019-05-17 18:54:15 <_ikke_> The projects own test suite run on Alpine failed though
2019-05-17 19:03:21 <_ikke_> issue for nbd: https://github.com/NetworkBlockDevice/nbd/issues/100
2019-05-17 19:05:36 <_ikke_> great, the libreoffice download url returns 503 :-/
2019-05-17 19:06:55 <_ikke_> nextcloud-client hashes changed :-/
2019-05-17 19:08:21 <Cogitri> :/
2019-05-17 19:09:53 <_ikke_> Hmm, locally it checks out
2019-05-17 19:10:00 <_ikke_> >>> nextcloud-client: Checking sha512sums...
2019-05-17 19:10:01 <_ikke_> nextcloud-client.tar.gz: OK
2019-05-17 19:11:53 <Cogitri> Maybe you still have the old distfile?
2019-05-17 19:12:03 <_ikke_> I never downloaded it
2019-05-17 19:12:16 <_ikke_> I did abuild fetch and I saw it actually downloading
2019-05-17 19:13:52 <Cogitri> Oh, alright
2019-05-17 19:15:21 <kr0k0> Hi all
2019-05-17 19:15:52 <_ikke_> kr0k0: hi
2019-05-17 19:16:01 <Cogitri> Hello there
2019-05-17 19:16:03 <kr0k0> _ikke_: Where do you see the nextcloud-client error?
2019-05-17 19:17:04 <_ikke_> kr0k0: https://build.alpinelinux.org/buildlogs/build-3-10-armv7/community/nextcloud-client/nextcloud-client-2.5.2-r0.log
2019-05-17 19:17:13 <_ikke_> But armhf seems to succeed
2019-05-17 19:17:20 <_ikke_> https://build.alpinelinux.org/buildlogs/build-3-10-armhf/community/nextcloud-client/nextcloud-client-2.5.2-r0.log
2019-05-17 19:17:25 <Cogitri> Maybe it was just a bad fetch then?
2019-05-17 19:17:53 <_ikke_> Yes, I guess so
2019-05-17 19:18:28 <kr0k0> Yes, seems so
2019-05-17 19:18:57 <kr0k0> Ah, you wrote it already _ikke_ ^^
2019-05-17 19:20:11 <_ikke_> Anyone seeing what's failing here? https://build.alpinelinux.org/buildlogs/build-3-10-armhf/community/qt5-qtscript/qt5-qtscript-5.12.1-r2.log
2019-05-17 19:20:25 <_ikke_> I only see warnings
2019-05-17 19:21:02 <Cogitri> jit/JITStubs.cpp:617:5: error: expected '(' before 'volatile' asm volatile (
2019-05-17 19:21:22 <_ikke_> Ah yes, I saw that earler
2019-05-17 19:21:26 <Cogitri> Lots of that and `expected unqualified-id before string constant`
2019-05-17 19:22:37 <_ikke_> Any clue what that might be?
2019-05-17 19:23:13 <_ikke_> https://stackoverflow.com/questions/24646451/error-expected-identifier-or-before-volatile
2019-05-17 19:26:24 <_ikke_> I have the feeling that ppc64le 3.10 finished building
2019-05-17 19:26:30 <_ikke_> uploading packages to community
2019-05-17 19:27:09 <Cogitri> In some other project it was due to setting `-std` to something too modern, but Qt's build system should do that
2019-05-17 19:27:49 <_ikke_> It fails locally for me as well, so probably not arch related
2019-05-17 19:28:32 <_ikke_> Cogitri: That SO post indicated it might be macro related
2019-05-17 19:31:09 <Cogitri> I guess this is the point at which my C(++) knowledge ends, sooo :P
2019-05-17 19:31:37 <_ikke_> Yes, for me as well
2019-05-17 19:37:12 <_ikke_> At passed on ppc64le, probably because it's not doing any JIT
2019-05-17 19:38:30 <_ikke_> Ok, scapy does fail checksums
2019-05-17 19:43:05 <_ikke_> I still have an archive on the builder with the hash in the APKBUILD
2019-05-17 19:49:18 <_ikke_> Seems to be just something technical
2019-05-17 19:49:24 <_ikke_> only difference I can find is git related
2019-05-17 19:49:28 <_ikke_> >             git_archive_id = 'bad14cb1a  (tag: v2.4.2)'
2019-05-17 19:49:33 <_ikke_> <             git_archive_id = 'bad14cb1a  (HEAD -> master, tag: v2.4.2)'
2019-05-17 19:52:06 <_ikke_> It's in a file in the repo, so they must have done somethign
2019-05-17 20:48:18 <_ikke_> weird, now aarch64 failed on nextcloud-client as well
2019-05-17 20:52:07 <Cogitri> Well, Nextcloudclient isn't really usable rn anyway due to QtWebengine not working w/ musl 1.22
2019-05-17 20:53:52 <[[sroracle]]> I have a patch to remove it
2019-05-17 20:53:57 <[[sroracle]]> hold on
2019-05-17 20:55:22 <[[sroracle]]> http://ix.io/1Jld
2019-05-17 20:55:30 <[[sroracle]]> this removes qtwebengine and makes basic auth the default
2019-05-17 20:56:34 <Cogitri> Basic auth == a app password?
2019-05-17 20:56:43 <[[sroracle]]> yeah
2019-05-17 20:57:32 <Cogitri> Alright, guess I'll give that a shot, thanks
2019-05-17 23:03:23 <mksully22> s390 llvm5 build failure is still most likely due to the go pkg still being installed from prior go package build effort. Have you tried to log in to the builder and remove the go package?
2019-05-17 23:23:19 <mksully22> rethinkdb PR https://github.com/alpinelinux/aports/pull/7917
2019-05-18 00:10:17 <LucasRamage[m]> Greetings, I have an upgrade for bash-completion that has new dependencies that needs to be reviewed, https://patchwork.alpinelinux.org/patch/4849
2019-05-18 02:30:23 <tcely> There is also https://github.com/alpinelinux/aports/pull/7873
2019-05-18 02:31:35 <tcely> I do not know if I prefer pw4849 or pr7873 yet.
2019-05-18 05:40:29 <_ikke_> regarding qt5-qtwebscript: https://bugreports.qt.io/browse/QTBUG-74196
2019-05-18 06:01:42 <_ikke_> Version 5.12.2 fixed this issue, I'm upgrading it to 5.12.3
2019-05-18 06:26:06 <kr0k0> Morning
2019-05-18 06:27:02 <kr0k0> _ikke_: great!
2019-05-18 06:28:27 <kr0k0> libreoffice fails also nearly on all archs
2019-05-18 06:32:03 <mps> kr0k0: LO fails because source url responds with HTTP 503 (or 5020
2019-05-18 06:33:09 <kr0k0> mps: Yes, the url is a bit strange....
2019-05-18 06:34:46 <mps> last night I looked their site and they have page which says they have issues (problem) with the server
2019-05-18 06:39:16 <kr0k0> Ah ok
2019-05-18 06:41:02 <mps> https://downloadarchive.documentfoundation.org/libreoffice/old/6.2.3.2/src/
2019-05-18 06:41:36 <mps> "infra team is working on it. Sorry for the inconvenience."
2019-05-18 06:51:20 <kr0k0> Why not using http://download.documentfoundation.org/libreoffice/src/6.2.3/libreoffice-6.2.3.2.tar.xz?
2019-05-18 06:51:46 <kr0k0> Is this downloadarchive a static url?
2019-05-18 06:59:24 <mps> probaly because arhive more stable url, but i'm not sure
2019-05-18 07:03:01 <kr0k0> Ok, then let's hope that it will go online soon.
2019-05-18 10:46:19 <_ikke_> tmhoang: Did you remove go already from the s390x builder to fix llvm5?
2019-05-18 13:34:52 <tmhoang> _ikke_ : sorry busy week I have not done any Alpine work last week. I will try to catch up next week.
2019-05-18 13:35:17 <tmhoang> I did not insta//remove any thing on builder, just reboot it after the upgrade from people I dont know :D
2019-05-18 13:35:43 <tmhoang> maybe we need ncopa for touching the builder packages
2019-05-18 15:43:14 <_ikke_> tmhoang: if you have access to the builder, feel free to just do apk del go
2019-05-18 15:44:00 <tmhoang> _ikke_ that simple ? apk del go on those would make any better for the lxc builders ?
2019-05-18 15:44:15 <tmhoang> *on the host
2019-05-18 15:44:55 <_ikke_> You need to do it on the container of course
2019-05-18 15:46:08 <_ikke_> lxc-attach -n <builder>; apk del go
2019-05-18 15:48:11 <tmhoang> done
2019-05-18 15:51:16 <north1> _ikke_: is it ok to release a new breaking atools version soon ?
2019-05-18 15:57:37 <_ikke_> north1: Sure, don't think it will matter a lot atm
2019-05-18 16:02:31 <north1> _ikke_: alright
2019-05-18 16:03:10 <north1> also the other people that want stuff a stable output for integration with ALE and other stuff need to open issues on maxice8/atools
2019-05-18 17:06:32 <SpaceToast> ping _ikke_ - py3-psutil is an optional dependency for salt, how do we normally deal with that?
2019-05-18 17:06:58 <SpaceToast> (it's not required for it to run, but it's generally desirable for a variety of reasons)
2019-05-18 17:07:47 <iggy> salt has a ton of optional deps
2019-05-18 17:08:00 <SpaceToast> also ping clandmeter, re: pr7907 - would it be ok if I adopted it (caddy)?
2019-05-18 17:08:24 <SpaceToast> iggy: yes, exactly, my question is how we generally deal with optional deps
2019-05-18 17:08:34 <iggy> I'm curious too
2019-05-18 17:08:36 <SpaceToast> because installing them one-by-one seems like kind of a drag, doesn't it?
2019-05-18 17:09:02 <iggy> I've not seen anything about optional deps anywhere
2019-05-18 17:10:48 <SpaceToast> we have "recommended" packages with install_if
2019-05-18 17:10:54 <SpaceToast> but I can't find any way to handle optional deps
2019-05-18 17:11:14 <SpaceToast> I can think of a couple of ways to add that stuff to apk-tools but I don't think anyone asked :)
2019-05-18 17:11:25 <SpaceToast> (so let's start by seeing how things are handled right now)
2019-05-18 17:12:58 <iggy> I too am interested in this topic
2019-05-18 17:13:36 <_ikke_> SpaceToast: Not sure how alpine deals with that. Archlinux just lists the optional dependencies with a description of what it's needed for
2019-05-18 17:14:26 <SpaceToast> arch has a few extra things
2019-05-18 17:15:27 <SpaceToast> e.g you can install optional deps --asdeps
2019-05-18 17:16:06 <SpaceToast> (and they won't get removed, but won't be in "world" (they don't have an explicit one, tbf) either)
2019-05-18 17:56:54 <eu> SpaceToast: maybe create a salt-kitchensink subpkg with zero content but har deps on all those optdepends?
2019-05-18 17:57:10 <eu> s/har/hard/
2019-05-18 17:57:10 <alpine-meetbot> eu meant to say: SpaceToast: maybe create a salt-kitchensink subpkg with zero content but hard deps on all those optdepends?
2019-05-18 17:57:30 <SpaceToast> maybe, but some of them are in testing, and they're not all of the same "type"
2019-05-18 17:57:36 <SpaceToast> lots of ways it could be done, really
2019-05-18 18:22:28 <_ikke_> ppc64le 3.10 is finished \o/
2019-05-18 21:12:12 <north1> _ikke_: version 7 of atools is out
2019-05-19 01:06:32 <TBK[m]> MartijnBraam: Would you be so kind to create an issue on bugs.a.o about plymouth systemd?
2019-05-19 01:27:33 <TBK[m]> Did anybody take a look at py-img2pdf? Could a possible solution to s390x be to just kill the py2 variant? Upsteam has dropped support according to this https://gitlab.mister-muffin.de/josch/img2pdf/issues/60
2019-05-19 02:05:59 <tcely> TBK[m]: I took a look. It's only failing a few checks that I don't believe have anything to do with python2
2019-05-19 02:09:13 <tcely> zip and zlib-dev are more likely to be related
2019-05-19 02:42:14 <north1> _ikke_: https://github.com/maxice8/atools/commit/d2aa699b92a27d63d5610a6b1ceedc1526308156
2019-05-19 02:42:28 <north1> This should help with the possible cd "$builddir" false-positives
2019-05-19 02:50:08 <tcely> north1: lgtm
2019-05-19 02:50:45 <north1> There is no universe in that thing i wrote looks good
2019-05-19 02:51:14 <tcely> heh
2019-05-19 02:53:15 <tcely> you can simplify your code a bit by using awk to walk the function and checking for "cd" = $1
2019-05-19 02:54:19 <north1> won't $1 be the linenumber ?
2019-05-19 02:54:45 <tcely> If you want to get fancy you can split the lines on [;&|] and parse again for complex commands
2019-05-19 02:55:09 <tcely> Sure, it would be if you use cat -n, but not if you just feed awk the file directly.
2019-05-19 02:56:44 <north1> can awk also give me the linenumber ? apkbuild-lint prints the linenumber of the violation
2019-05-19 03:03:19 <tcely> Try something like this: awk -v P=true '/^[^(]+\(/,/^[^}]*}$/ { if(P) {print; P="";} if("cd" == $1) {printf "%d %s\n", FNR, $0;} if("}" == $0) {print; P="true";}}'
2019-05-19 03:04:01 <tcely> Just put the path to the APKBUILD as the last argument
2019-05-19 03:09:10 <tcely> For example, testing/mawk/APKBUILD gives me: http://tpaste.us/5wgX
2019-05-19 03:15:34 <north1> I'll take a look later
2019-05-19 03:15:41 <north1> Sleep time now
2019-05-19 07:14:59 <tmhoang_> _ikke_: when you have a minute : https://github.com/alpinelinux/aports/pull/7941. thans
2019-05-19 07:15:03 <tmhoang_> thanks
2019-05-19 07:15:08 <_ikke_> checking
2019-05-19 07:23:59 <_ikke_> tmhoang: pushed, thanks
2019-05-19 07:43:14 <tmhoang> do we still have problem with x86 + arm 3-10 builders ? http://master.alpinelinux.org/alpine/v3.10/community/
2019-05-19 07:43:18 <tmhoang> interesting
2019-05-19 07:43:35 <tmhoang> ppc64le was up first
2019-05-19 07:55:47 <_ikke_> yES, INDEED
2019-05-19 07:55:53 <_ikke_> sorry, caps
2019-05-19 08:21:49 <PureTryOut[m]> mps: did you have time yet to look at u-boot?
2019-05-19 08:25:58 <_ikke_> So armhf and s390x have finished building as well, nice
2019-05-19 08:42:23 <mps> PureTryOut[m]: I will be in about hour or two back at home and then we can continue
2019-05-19 08:43:11 <mps> I'm now in inconvenient position to work on anything serious
2019-05-19 10:50:16 <mps> PureTryOut[m]: I'm here now
2019-05-19 10:52:02 <mps> as I wrote earlier I think separate package 'arm-trusted-firmware' looks more appropriate, but not sure because didn't worked with it and it's relation to u-boot
2019-05-19 12:45:38 <PureTryOut[m]> mps: yeah I thought so too originally, but when doing it that way it had trouble resolving `arm-trusted-firmware`. That might've just been an issue with `pmbootstrap` though
2019-05-19 12:49:39 <Cogitri> When I add myself as contributor to some APKBUILD, do I add myself at the top or the bottom of the Contributor thingie?
2019-05-19 12:51:03 <eu> Cogitri: you need to quantify your contribution against the others and arrange yourself in the list :P
2019-05-19 12:54:43 <SpaceToast> I usually do it at the top, since maintainer is at the bottom and thus bottom carries most weight (imo)
2019-05-19 14:05:18 <mps> PureTryOut[m]: I don't know how pmbootstrap works, is it plain installer or it build something during installation
2019-05-19 14:07:51 <PureTryOut[m]> It builds the packages that aren't found in the binary repos, but it just uses abuild internally
2019-05-19 14:08:05 <PureTryOut[m]> But it's fine if you don't have resolvement errors
2019-05-19 14:09:02 <Cogitri> SpaceToast: alright, thanks
2019-05-19 14:10:33 <mps> so, it builds u-boot during it's invocation?
2019-05-19 14:12:15 <mps> I read pmOS guide (superficially and some time ago) and pmbootstrap is mentioned there, but I thought it is plain installer, i.e. take pkg's and put them in proper places
2019-05-19 14:14:41 <PureTryOut[m]> No it's way more than that
2019-05-19 14:15:11 <PureTryOut[m]> but as far as `arm-trusted-firmware` goes, it is used when building u-boot by setting the `$BL31` variable
2019-05-19 14:16:22 <PureTryOut[m]> so if you use `arm-trusted-firmware` as a separate package, just put the resulting `.bin` file anywhere and export that location in `u-boot`'s build function
2019-05-19 14:16:58 <mps> aha, but couldn't u-boot then depends on 'arm-trusted-firmware' and use `$BL31` from package
2019-05-19 14:17:28 <PureTryOut[m]> It could in theory, but at least for me it fails to resolve the `arm-trusted-firmware` package
2019-05-19 14:17:57 <mps> that is, I see that in `arm-trusted-firmware` are more variants of 'drivers' (or what is it) which can be built
2019-05-19 14:18:47 <PureTryOut[m]> Yup. At postmarketOS we only needed allwinner for now, but I'm sure there are more useful platforms in there
2019-05-19 14:20:19 <mps> yes, I thought maybe we can have more subpackages in `arm-trusted-firmware`, so pmbootstrap (or other software) can use/depends on needed one for particular box
2019-05-19 14:22:40 <PureTryOut[m]> I guess. I think this package is only required for u-boot though
2019-05-19 14:22:42 <mps> here is the APKBUILD http://tpaste.us/Kgbo , only don't know where to put resulting bin (in package() function)
2019-05-19 14:23:35 <mps> if we have separate pkg (or pkgs) that way we will not hack u-boot APKBUILD too much
2019-05-19 14:27:07 <PureTryOut[m]> That's literally a copy of what I made when testing haha. Just put it in `$pkgdir`/usr/share/$pkgname` or something, it doesn't really matter
2019-05-19 14:28:57 <mps> heh, good thing about APKBUILD is that we can reuse existing ones :) and 'newapkbuild' make it easier
2019-05-19 14:31:04 <mps> and, bin's should go under '/usr/lib/$pkgname' imo
2019-05-19 14:31:32 <PureTryOut[m]> That's fine to me as well
2019-05-19 14:31:50 <PureTryOut[m]> It's only used on build time anyway, it won't end up on any running system
2019-05-19 14:32:07 <mps> well, I'm not sure about this to be fair, '/usr/share' also looks fine
2019-05-19 14:32:53 <PureTryOut[m]> Does it really matter tbh?
2019-05-19 14:32:59 <mps> ok, I will build it and change u-boot to try if it works
2019-05-19 14:33:32 <mps> do you have suggestion how this one subpackage should be named
2019-05-19 14:34:20 <PureTryOut[m]> `arm-trusted-firmware-allwinner` I guess?
2019-05-19 14:34:38 <mps> `arm-trusted-firmware-asun50i_a64` or `arm-trusted-firmware-bl31`
2019-05-19 14:35:35 <mps> isn't allwinner name too broad, I have allwinner boards which doesn't need this
2019-05-19 14:35:56 <PureTryOut[m]> I'm not entirely sure if the `$BL31` variable is just used for this platform, so I guess go with the latter
2019-05-19 14:35:59 <mps> 32-bit ones
2019-05-19 14:36:03 <PureTryOut[m]> Maybe idk, it's my first Allwinner board
2019-05-19 14:36:15 <PureTryOut[m]> Maybe that's the difference? Allwinner on 64 bit?
2019-05-19 14:36:45 <mps> is this required for all 64-bit allwinner's
2019-05-19 14:39:22 <PureTryOut[m]> Sorry, I'm not sure
2019-05-19 14:40:35 <mps> nor do I, anyone else with arm64 have idea
2019-05-19 14:40:59 <mps> s/arm64/arm64 experience/
2019-05-19 14:40:59 <alpine-meetbot> mps meant to say: nor do I, anyone else with arm64 experience have idea
2019-05-19 15:59:41 <tmhoang> there was new vul to x86 cpu recently ?
2019-05-19 16:06:22 <SpaceToast> zombieload, another "intel took shortcuts when implementing SMT" thing
2019-05-19 16:07:36 <Cogitri> https://www.tomshardware.com/news/amd-mds-vulnerability-immune-intel,39367.html
2019-05-19 16:14:21 <tmhoang> amd hot again ?
2019-05-19 16:17:40 <SpaceToast> imo, amd's been hot since zen :)
2019-05-19 16:18:10 <SpaceToast> anyway, technical details: https://zombieloadattack.com/zombieload.pdf
2019-05-19 16:18:43 <SpaceToast> tl;dr there's some cpu storage that is global to the system, and one can potentially access whatever happens to be in it using a fault or similar
2019-05-19 16:19:28 <Cogitri> Yup, now I just need a Ryzen 3xxx notebook to go full AMD :^)
2019-05-19 16:20:42 <SpaceToast> my personal desktop systems are all amd ^^
2019-05-19 16:20:55 <SpaceToast> laptops are hard because intel has such a stranglehold on manufacturers
2019-05-19 16:21:13 <SpaceToast> and epyc is a bit out of my price range (running some old xeons for servers)
2019-05-19 16:21:44 <Cogitri> I use a Ryzen 2600 for my server/NAS thingie
2019-05-19 16:22:06 <Cogitri> <SpaceToast "laptops are hard because intel h"> My dream laptop would be a XPS 15 with some Ryzen APU
2019-05-19 16:22:27 <Cogitri> Or really anything ultrabook-ish without a dGPU
2019-05-19 16:22:32 <SpaceToast> I'd like a razer stealth, but with a ryzen apu, the features of the top-line one, but still without a dGPU
2019-05-19 16:22:55 <Cogitri> That'd be great too
2019-05-19 16:41:43 <north1> _ikke_: do you want a new release for atools to use the redo build system ?
2019-05-19 16:43:03 <_ikke_> north1: Can wait untill next time
2019-05-19 16:45:12 <north1> alright
2019-05-19 16:50:22 <_ikke_> I already released v8
2019-05-19 17:35:39 <mps> trying texmf-live from pw.a.o I got "fatal: not a git repository (or any of the parent directories): .git"
2019-05-19 17:35:53 <mps> is this serious error
2019-05-19 17:38:27 <mps> ofc, I run 'abuild -r' from aports git repo
2019-05-19 17:39:04 <mps> uhm, "texmf-dist-fontsextra*: Package size: 1.2 GB"
2019-05-19 17:39:56 <mps> 1.2 GB ? ;)
2019-05-19 17:40:07 <Cogitri> Well, it does install lots of stuff
2019-05-19 17:40:24 <Cogitri> 66004 files :o
2019-05-19 17:41:06 <mps> aha, every unicode character in separate file, I see :P
2019-05-19 17:56:24 <tcely> "The filesystem is not a database." < A good thing to remember, that not enough people were told.
2019-05-20 10:25:58 <kmaxwell> could someone with access to main/ please take a look at pr7106 ?
2019-05-20 10:26:34 <kmaxwell> it is a straightforward upgrade where clandmeter asked to move to community
2019-05-20 10:27:52 <north1> kmaxwell: reviewed
2019-05-20 10:30:04 <kmaxwell> north1: you already commented three weeks ago
2019-05-20 10:31:20 <kmaxwell> taking out 'cd "$builddir"' lines now just adds more noise
2019-05-20 10:32:44 <north1> ok
2019-05-20 10:34:41 <kmaxwell> just keen to get it merged or rejected :)
2019-05-20 10:51:05 <clandmeter> north1: are you sending in 50+ prs?
2019-05-20 10:53:15 <clandmeter> kmaxwell: thx!
2019-05-20 10:53:44 <mps> it looks like good idea to move it's dependencies to community
2019-05-20 10:54:13 <clandmeter> drone has like 60+ jobs running for aports
2019-05-20 10:54:16 <clandmeter> is this something new?
2019-05-20 10:55:13 <kmaxwell> clandmenter: that's brilliant thank you! I appreciate your help
2019-05-20 10:55:45 <kmaxwell> mps: I don't understand, what dependencies do you mean?
2019-05-20 10:56:04 <mps> clandmeter: when you are here i would like to ask about 'slim' pkg. I would like to build it without consolekit/polkit support
2019-05-20 10:56:25 <mps> kmaxwell: reverse, sorry not was clear
2019-05-20 10:56:59 <kmaxwell> mps: thanks, can you see some reverse dependencies the PR missed?
2019-05-20 10:57:01 <mps> or to make slim subpackage without this dependencies
2019-05-20 10:57:56 <mps> kmaxwell: when I wrote message and after that looked at #alpine-commits I see that everythinkg look ok
2019-05-20 10:59:02 <kmaxwell> mps: super! if you see anything that it might have broken shout and I will try to fix
2019-05-20 10:59:12 <clandmeter> mps: ok elaborate
2019-05-20 10:59:43 <mps> well, polkit now depends on mozjs60, iirc
2019-05-20 11:00:32 <mps> so, by installing slim it will pull all this. i.e. consolekit, polkit, mozjs and maybe something else
2019-05-20 11:00:52 <mps> and, slim can work quite fine without all these things
2019-05-20 11:02:00 <mps> my idea is to make subpackage without these dependencies or separate pkg, for example slim-slimmed
2019-05-20 11:02:07 <clandmeter> heh
2019-05-20 11:02:11 <north1> clandmeter: i rebased them
2019-05-20 11:02:30 <clandmeter> north1: yes i figured :)
2019-05-20 11:02:36 <mps> or, just slim as it is but without these dependencies
2019-05-20 11:02:54 <clandmeter> slim-slimmed-down-even-more
2019-05-20 11:03:20 <mps> :)
2019-05-20 11:03:55 <clandmeter> is slim still maintained?
2019-05-20 11:04:03 <mps> well, I'm using it this way for some months on few boxes
2019-05-20 11:04:14 <mps> you are maintainer
2019-05-20 11:04:26 <clandmeter> of what?
2019-05-20 11:04:52 <clandmeter> ncopa is maintainer of slim
2019-05-20 11:04:52 <mps> slim pkg, you were last time I looked
2019-05-20 11:05:03 <mps> oh, sorry then
2019-05-20 11:05:28 <clandmeter> np
2019-05-20 11:05:35 <clandmeter> what features does it remove?
2019-05-20 11:05:46 <clandmeter> i see fedora doesnt link to consolekit
2019-05-20 11:07:02 <mps> currently in Alpine we have "-DUSE_CONSOLEKIT=yes'
2019-05-20 11:07:41 <mps> 
ACTION wondering why I thought clandmeter is slim maintainer

2019-05-20 11:08:01 <clandmeter> i lost some weight, maybe thats it
2019-05-20 11:08:21 <mps> aha, understand ;)
2019-05-20 11:08:54 <mps> ok, sorry again, will ask ncopa when he come back
2019-05-20 11:09:23 <clandmeter> would be nice to figure out which features will be lost.
2019-05-20 11:09:52 <mps> polkit features, afaik
2019-05-20 11:11:10 <mps> _maybe_ shutdown option from login screen
2019-05-20 11:12:02 <Cogitri> Well, instead of asking for root via polkit it'll have to either be suid or just not support these operations
2019-05-20 11:13:34 <clandmeter> looking at other distros, it seems ok to disable it.
2019-05-20 11:13:39 <mps> why do we not have 'powerdev' group on Alpine, maybe we can add this group and put user in that group
2019-05-20 11:15:01 <clandmeter> north1: i see you created some abuild linter?
2019-05-20 11:15:08 <clandmeter> or somebody else did?
2019-05-20 11:15:38 <mps> at the end, slim is mostly used by 'power' users and they understand and know how to work around these 'shortcommings'
2019-05-20 11:16:34 <Cogitri> clandmeter: Yup he did, see atools
2019-05-20 11:17:37 <clandmeter> hmm, it pulls in grep
2019-05-20 11:18:02 <Cogitri> Yup, for perl regex grep IIRC
2019-05-20 11:19:24 <north1> clandmeter: i did yes
2019-05-20 11:20:43 <mps> busybox grep doesn't understand PCRE?
2019-05-20 11:22:55 <kmaxwell> saw this issue which I think is tracking the grep dependency https://github.com/maxice8/atools/issues/2
2019-05-20 11:23:28 <north1> yes, i want it to be able to work with only stuff in busybox but it is not particularly high priority
2019-05-20 11:24:57 <north1> mps: GNU grep links against libpcre.so.1 for -P i guess
2019-05-20 11:25:39 <clandmeter> i think i could add a step before the build process on drone
2019-05-20 11:25:49 <north1> /usr/libexec/git-core/grep links against libpcre2-8.so.0 for it
2019-05-20 11:25:58 <clandmeter> i dont want regular grep as a hard dep
2019-05-20 11:26:29 <clandmeter> not in the build step at least.
2019-05-20 11:27:09 <north1> can't it be done in travis like Void Linux does it ?
2019-05-20 11:27:16 <north1> they have a matrix: for running their xlint tool
2019-05-20 11:27:51 <clandmeter> i have no experience with travis
2019-05-20 11:30:46 <mps> north1: that is, I know that, but just asked to be sure
2019-05-20 11:31:17 <mps> and, I'm with clandmeter here
2019-05-20 11:33:04 <mps> I think we should always try to make basic tools without to much dependencies and use busybox whenever we can
2019-05-20 11:36:43 <north1> ok
2019-05-20 11:49:25 <clandmeter> i wonder if it makes sense for algitbot to post the lint details in the PR.
2019-05-20 11:50:11 <Cogitri> That'd be very cool
2019-05-20 11:53:58 <clandmeter> north1: for drone it doesn't matter as we would run it in its own container separated from the build step.
2019-05-20 11:54:59 <clandmeter> the problem is, when you want to use the linter in your own build env. it will always have grep installed and could cause build weirdness.
2019-05-20 11:59:46 <north1> never occurred that to me i just use dabuild to separate my buid env from everywhere else
2019-05-20 12:02:58 <mps> LucasRamage[m]: are you here? your mail address from which you sent some patches  dosn't 'work', or it is refused for me
2019-05-20 14:57:33 <opal> so have a lot of people
2019-05-20 15:19:41 <mps> whoever removed this, s/he was fast :)
2019-05-20 15:23:09 <mps> opal: true, maybe patch shouldn't be accepted if mail address from which is posted is invalid
2019-05-20 17:06:23 <opal> whoops, mps: i think i posted that in the wrong channel
2019-05-20 17:07:02 <mps> opal: nvm, it looked quite appropriate :D
2019-05-20 17:07:14 <opal> 14:56.22 < telmich:#alpine-linux> In case you haven't seen it already, we just posted a list of distributions w/o sytemd: https://ungleich.ch/en-us/cms/blog/2019/05/20/linux-distros-without-systemd/ (also on HN/reddit)
2019-05-20 17:07:24 <opal> i was responding to that, the channel names are blending together for me lol
2019-05-20 17:07:53 <opal> i think im the minority who uses merged-window layout on irc
2019-05-20 17:53:49 <hjaekel> Hi, is someone here to review my pull request #7938? It's not just a simple version upgrade, but a package rename, adding some subpackages and a bugfix.
2019-05-20 17:54:36 <hjaekel> agitbot is wrong, this is the link: https://github.com/alpinelinux/aports/pull/7938
2019-05-20 17:55:54 <SpaceToast> # number is for bugs; for prs we have pr number (e.g pr7938 ) (for future reference)
2019-05-20 17:56:43 <hjaekel> thank you SpaceToast
2019-05-20 17:57:25 <mps> hjaekel: didn't you received mail about that PR
2019-05-20 17:58:10 <mps> or it was someone else, with PR for same pkg
2019-05-20 17:58:50 <SpaceToast> a lot of these updated packages seem like they need some modernization
2019-05-20 17:58:52 <mps> hjaekel: look here https://github.com/alpinelinux/aports/pull/7972
2019-05-20 17:58:59 <hjaekel> didn't recieve an email. there is a duplicate for the same package pr7972
2019-05-20 17:59:42 <hjaekel> my PR adds some things, not just a version upgrade
2019-05-20 18:00:57 <mps> hmm, I would ask ncopa because he is maintaner, but he is not here these days
2019-05-20 18:01:24 <SpaceToast> "these days" makes it sound like he's stopped being active with no sight of that changing mps
2019-05-20 18:01:32 <SpaceToast> he's just on vacation right now :)
2019-05-20 18:01:43 <mps> SpaceToast: you know what i think ;)
2019-05-20 18:01:52 <SpaceToast> sure, but not everyone else does
2019-05-20 18:01:57 <SpaceToast> that's what communication is for ;)
2019-05-20 18:02:13 <SpaceToast> hjaekel: he is correct though, you will want to ask the maintainer of a given package before making huge/drastic changes to it
2019-05-20 18:02:49 <hjaekel> OK, I will ask ncopa
2019-05-20 18:02:51 <mps> and you know that I'm self taught in English and my sentences and words could look and sound 'strange'
2019-05-20 18:04:09 <hjaekel> I also want to do similar things to the gdal package, but the maintainer is absent
2019-05-20 18:06:50 <hjaekel> who is maxice8 here on freenode?
2019-05-20 18:07:29 <_ikke_> north1:
2019-05-20 18:07:41 <north1> maxice8 is maxice8
2019-05-20 18:07:45 <_ikke_> Doh
2019-05-20 18:07:48 <mps> hjaekel: subscribe to alpine-devel ML (if you are not already), then post mail to maintainer and ML asking for what you intend to do and wait some time
2019-05-20 18:08:17 <_ikke_> north1: you are maxice / leo, not?
2019-05-20 18:08:52 <mps> if the maintainer doesn't answer in reasonable time than you can take maintainership of pkg
2019-05-20 18:09:24 <mps> _ikke_: he have a lot of nick's
2019-05-20 18:09:34 <mps> and names, probably
2019-05-20 18:09:37 <north1> _ikke_: don't forget the 8, the 8 is **very** important. (Otherwise you reach @Maxice on github and tags the entirely wrong person)
2019-05-20 18:09:48 <hjaekel> mps, thank you, I will do that
2019-05-20 18:09:53 <north1> but yes maxice8 is maxice8 but maxice8 is also Leo and in a future date maxice8 will be deprecated in favor of Leo
2019-05-20 18:10:19 <mps> hjaekel: you are welcome
2019-05-20 18:10:32 <hjaekel> north1, thank you for the review, I will update my PR
2019-05-20 18:13:41 <_ikke_> north1: I'm thinking about adding some tests to atools using BATS (https://github.com/bats-core/bats-core), any objection?
2019-05-20 18:14:34 <north1> _ikke_: if you could add a makefile or command on whatever that .do buildsystem you added to run tests it would be great
2019-05-20 18:14:46 <_ikke_> yes, I would :)
2019-05-20 18:15:32 <north1> no objections (so far)
2019-05-20 18:15:54 <_ikke_> alright, I'll create a PR for it then
2019-05-20 18:21:37 <north1> nice
2019-05-20 18:22:52 <north1> pr7065 can be closed, sorry andypost.
2019-05-20 18:25:11 <_ikke_> done
2019-05-20 18:27:30 <SpaceToast> hey _ikke_ :)
2019-05-20 18:27:40 <_ikke_> SpaceToast: o/
2019-05-20 19:28:38 <TBK[m]> I am contemplating if it is alright if subpkgs have their own related $subpkg-doc or if I just combine all docs in the main doc pkg?
2019-05-20 19:28:58 <_ikke_> Opinions are divided on that.
2019-05-20 19:29:05 <SpaceToast> iirc sub-sub-packages are discouraged
2019-05-20 19:29:08 <_ikke_> nod
2019-05-20 19:30:10 <TBK[m]> 10MB docs it is then : P
2019-05-20 19:32:14 <eu> It would be great if alpine made a distinction between *-doc and *-man
2019-05-20 19:33:26 <eu> or just use *-doc for man pages and create *-html-info-and-other-crap-doc
2019-05-20 19:46:20 <north1> pr6388 can be closed, py3-cachetools already exists and the APKBUILD is wrong anyways
2019-05-20 20:07:02 <kmaxwell> just in case anyone is looking into py3-cachetools, I propose an upgrade in pr7827
2019-05-20 20:21:38 <north1> kmaxwell: reviewed
2019-05-20 20:22:41 <_ikke_> north1: Should this cause a warning? http://tpaste.us/Boqn
2019-05-20 20:27:48 <north1> with the current code, no
2019-05-20 20:27:54 <north1> that is an edgecase i didn't think about
2019-05-20 20:28:16 <_ikke_> Right, I thought that was what you fixed the other day
2019-05-20 20:29:11 <north1> ah no i fixed it detecting all cd "$builddir" as wrong
2019-05-20 20:29:20 <north1> while there are cases where one does cd "$builddir"/foo
2019-05-20 20:29:20 <_ikke_> ah ok
2019-05-20 20:29:32 <north1> and then legitimely wants to switch back to $builddir
2019-05-20 20:29:53 <north1> it will check if the previous command is cd "$builddir" and warn only on the second ocurrence
2019-05-20 20:30:28 <_ikke_> I mark that test case as skipped for now
2019-05-20 20:32:34 <_ikke_> I try to not only test for correct warnings, but also false positives
2019-05-20 20:59:54 <_ikke_> north1: https://github.com/maxice8/atools/pull/6
2019-05-20 21:00:26 <_ikke_> some initial tests, just to verify if I should continue, and because I think I found one test failing that should work
2019-05-20 21:12:06 <eu> _ikke_: maybe https://shellspec.info/ is better suited than bats given the implementation is in posix sh?
2019-05-20 21:15:02 <eu> nevermind, that implementation (while posix compliant) is insanely complicated
2019-05-20 21:15:43 <kmaxwell> north1: when you say reviewed do you just mean you ran automatic checks for "cd $builddir"?
2019-05-20 21:17:11 <north1> kmaxwell: no automatic checks are done, i check the changes in each commit and each APKBUILD that was modified
2019-05-20 21:22:11 <_ikke_> eu: thanks, didn't know about shellspec
2019-05-20 21:32:01 <kmaxwell> I think that the 'cd "$builddir"' is required in split functions, does anyone know for sure?
2019-05-20 21:35:12 <north1> as far as i remember, yes
2019-05-20 21:35:22 <north1> i only check for prepare() build() check() and package()
2019-05-20 21:37:11 <kmaxwell> thank you!
2019-05-20 21:38:30 <kmaxwell> if possible, I think it is work saying as much in review comments so that people don't remove too many and waste time building
2019-05-20 21:40:09 <_ikke_> kmaxwell: nice case to add to the tests
2019-05-20 21:48:58 <north1> i started mentioning default functions some time ago
2019-05-20 21:53:04 <_ikke_> like vmove?
2019-05-20 21:55:46 <north1> no, prepare() build() check() and package()
2019-05-20 21:56:09 <SpaceToast> reminder: amove (simpler vmove variant) is basically done, and should be useful for default subpackages; but ncopa asked that I wait until after 3.10 is out to open up a PR :)
2019-05-20 21:56:28 <north1> nice
2019-05-20 21:56:40 <SpaceToast> north1: you should know, you've literally helped test it ;)
2019-05-20 21:58:33 <north1> I know but didn't remember at the time
2019-05-20 22:01:50 <kmaxwell> _ikke_: I agree, having a look now
2019-05-20 22:02:14 <kmaxwell> was caught out by the testing failing with no error if you don't have GNU grep
2019-05-20 22:02:24 <kmaxwell> should've remembered the chat earlier :)
2019-05-20 22:30:53 <kmaxwell> is there any easy way to pass the output of the command under test to the terminal with BATS?
2019-05-20 23:44:57 <tcely> If you are a maintainer, please check: https://github.com/alpinelinux/aports/projects/1#column-5386375
2019-05-20 23:48:26 <SpaceToast> tcely++
2019-05-20 23:48:30 <SpaceToast> great initiative :)
2019-05-20 23:49:48 <tcely> Thanks. Adding some sanity to the heap of PRs has helped me already.
2019-05-21 06:20:11 <_ikke_> north1: regarding formalizing apkbuild-lint output, it would be nice to give each lint a unique code (like shellcheck does)
2019-05-21 06:57:56 <clandmeter> tcely: i need a wider screen
2019-05-21 07:04:09 <_ikke_> clandmeter: o/
2019-05-21 07:11:12 <clandmeter> _ikke_: morning
2019-05-21 07:12:02 <Cogitri> Morning
2019-05-21 08:07:22 <clandmeter> anyone knows if we support symlinked APKBUILDS?
2019-05-21 08:07:58 <_ikke_> No clue, but might be tricky when the target gets moved or deleted
2019-05-21 08:10:49 <clandmeter> now that i think of it, its kind of hard
2019-05-21 08:10:55 <clandmeter> cause apkbuild get sourced
2019-05-21 08:13:48 <clandmeter> our kernel management is just too stupid/simple. we really need some logic in abuild.
2019-05-21 08:15:15 <clandmeter> i would also like some magic var to be exported so apk trigger knows its been called from abuild. running the kernel trigger on a apkbuild is a waste of time.
2019-05-21 08:16:18 <_ikke_> The trigger that builds the initramfs?
2019-05-21 08:17:03 <clandmeter> yes
2019-05-21 08:18:09 <clandmeter> i think there are more triggers that only need to run on user install.
2019-05-21 08:19:13 <_ikke_> yes, makes sense
2019-05-21 08:21:25 <clandmeter> another abuild thing i would like is a unified way to add system users.
2019-05-21 08:23:50 <mps> clandmeter: as option in apkbuild? sounds good
2019-05-21 08:24:00 <_ikke_> clandmeter: Yes, that's also necessary
2019-05-21 08:24:27 <Cogitri> Yup, that'd be good
2019-05-21 08:24:32 <clandmeter> if somebody could add an issue for that, we can look into it.
2019-05-21 08:24:32 <_ikke_> clandmeter: another thing is a lot of duplication between similar types of projects
2019-05-21 08:24:41 <clandmeter> im currently trying to bring wireguard to community
2019-05-21 08:24:43 <_ikke_> python modules, perl modules
2019-05-21 08:24:51 <Cogitri> BTW, if we do that: how about setting /var/empty has home by default instead of /dev/null?
2019-05-21 08:25:10 <Cogitri> At least colord and gdm don't like that that much I think
2019-05-21 08:25:23 <clandmeter> Cogitri: thats why we need an issue for it, so we can set sane defaults.
2019-05-21 08:25:53 <Cogitri> _ikke_: Maybe we could pull some inspiration from Void's build_styles?
2019-05-21 08:25:58 <clandmeter> let ncopa read over it when he comes back. he will have some opinion, im sure :)
2019-05-21 08:26:00 <_ikke_> clandmeter: :-)
2019-05-21 08:26:02 <_ikke_> Cogitri: *
2019-05-21 08:26:03 <Cogitri> Although I like how simple APKBUILDs are
2019-05-21 08:26:33 <clandmeter> yes, i also like the simplicity of apkbuild.
2019-05-21 08:26:45 <clandmeter> but simplicity should never be a limitation.
2019-05-21 08:26:53 <Cogitri> Yup
2019-05-21 08:27:13 <Cogitri> After using Exherbo for a year I prefer simplicity over trying to be clever though :)
2019-05-21 08:27:37 <clandmeter> im not trashing simplicity, far from it :)
2019-05-21 08:27:57 <mps> Void template's looks too declarative
2019-05-21 08:28:13 <Cogitri> Its buildsystem is super modular (it uses exlibs, basically source-able SH "libs"), but they're super annoying to use
2019-05-21 08:28:18 <Cogitri> mps: wdym?
2019-05-21 08:28:47 <mps> Cogitri: declarative programming, I mean
2019-05-21 08:28:49 <clandmeter> i think its nice to see a build script and know what it does without needing to read a manual.
2019-05-21 08:29:24 <mps> and clandmeter just express my mind clearly :)
2019-05-21 08:30:10 <Cogitri> Yup, but build_styles are so simple that it's not much of a problem IMO
2019-05-21 08:30:42 <Cogitri> And standardises the way packages are built and makes tree-wide changes easier
2019-05-21 08:30:54 <Cogitri> But it's OK with newapkbuild :)
2019-05-21 08:42:53 <clandmeter> heh aports-ghpr is pretty stupid
2019-05-21 08:43:18 <_ikke_> clandmeter: do tell
2019-05-21 08:43:43 <clandmeter> try to search for a custom string
2019-05-21 08:44:12 <clandmeter> it still tries to search to the cwd aport
2019-05-21 08:45:24 <clandmeter> i was hoping APORT means a string i can search for.
2019-05-21 08:54:37 <_ikke_> north1: if I read your comments for superfluous_cd_builddir, it does look like it should account for cd "$builddir/foo"; foo; cd "$builddir"
2019-05-21 09:04:55 <clandmeter> 
ACTION slaps ncopa with rpi kernel naming scheme

2019-05-21 09:05:27 <_ikke_> :D
2019-05-21 09:09:11 <clandmeter> ok looks like i managed it
2019-05-21 09:09:31 <clandmeter> but its just weird to have a different kernel name on different arches.
2019-05-21 09:09:39 <clandmeter> with similar config
2019-05-21 09:18:05 <clandmeter> i read some articles that clearlinux is so performant. are there tests and details about it?
2019-05-21 09:18:25 <_ikke_> I linked to something the other day
2019-05-21 09:19:39 <artok> was it that phoronix article?
2019-05-21 09:19:45 <_ikke_> https://www.phoronix.com/scan.php?page=article&item=docker-summer-2018&num=4
2019-05-21 09:19:47 <_ikke_> yes
2019-05-21 09:20:00 <clandmeter> would be nice if we had some members from our community who looked over it. scanned aports and see if we can optimize.
2019-05-21 09:20:51 <clandmeter> just thinking out loud here. not sure where issues comes from.
2019-05-21 09:21:31 <_ikke_> Some point to optimalizations in glibc that musl is missing
2019-05-21 09:21:58 <clandmeter> thats also the case for clearlinux?
2019-05-21 09:22:02 <_ikke_> https://news.ycombinator.com/item?id=19861921
2019-05-21 09:22:20 <Cogitri> They also enable some optimizations which limit which CPUs Clear Linux can run on
2019-05-21 09:22:27 <_ikke_> "Highly tuned for Intel platforms where all optimization is turned on by default"
2019-05-21 09:22:43 <Cogitri> You can't run CL on something older than Sandy Bridge...or Haswell?
2019-05-21 09:22:47 <clandmeter> but it also runs on AMD iirc
2019-05-21 09:22:54 <clandmeter> so they dont benefit from it?
2019-05-21 09:23:20 <Cogitri> Yup, It's not intel specific but even on AMD it needs more recent CPUs
2019-05-21 09:23:35 <Cogitri> <clandmeter "so they dont benefit from it?"> They do benefit from it as well, but it doesn't work at all on older CPUs :)
2019-05-21 09:25:36 <clandmeter> so all they do is some compiler optimization?
2019-05-21 09:25:37 <artok> LTO, -O3 on clearlinux?
2019-05-21 09:26:01 <artok> by the quick looks of it
2019-05-21 09:38:28 <Cogitri> That + some patches here and there I think
2019-05-21 09:39:31 <Cogitri> See https://openbenchmarking.org/embed.php?i=1801134-FO-CLEARBUNT00&sha=c776928&p=2 for for CPPFLAGS
2019-05-21 09:42:36 <artok> tune just for haswell minimum...
2019-05-21 09:50:31 <_ikke_> tcely: what is the difference between todo and pending on the project board?
2019-05-21 09:51:06 <tcely> _ikke_: todo is where issues are moved to by the automation rules. I'm using it for WIP / Draft PRs
2019-05-21 09:51:19 <Cogitri> artok: Yup, which isn't feasible for us, I guess
2019-05-21 09:52:55 <_ikke_> tcely: If I look at automation, both have "move pull requests here when newly added"
2019-05-21 09:53:32 <_ikke_> On mentions issues, the other pull requests
2019-05-21 09:53:41 <_ikke_> s/On/One
2019-05-21 09:53:41 <alpine-meetbot> _ikke_ meant to say: One mentions issues, the other pull requests
2019-05-21 09:55:18 <tcely> yes, that's the meat of it. The template starts with one column for issues and the other for PRs
2019-05-21 09:56:14 <_ikke_> k
2019-05-21 10:08:11 <_ikke_> What should we do with gcompat, which is in community but has no maintainer? https://github.com/alpinelinux/aports/pull/7904
2019-05-21 10:12:59 <fcolista> re: https://github.com/alpinelinux/aports/pull/7822
2019-05-21 10:13:15 <fcolista> it should notbreak ABI since the .so was not provided before
2019-05-21 10:13:43 <fcolista> I would go ahead and merge it
2019-05-21 10:18:06 <fcolista> _ikke_, any objection ?
2019-05-21 10:18:11 <fcolista> https://abi-laboratory.pro/?view=timeline&l=libsrtp
2019-05-21 10:19:00 <fcolista> clandmeter, <3 re: https://github.com/alpinelinux/aports/pull/7980
2019-05-21 10:21:02 <_ikke_> fcolista: checking
2019-05-21 10:22:17 <_ikke_> fcolista: You are referring to this so, right? usr/lib/libsrtp2.so
2019-05-21 10:22:23 <fcolista> right
2019-05-21 10:22:47 <_ikke_> Does look like a new so indeed, so yes
2019-05-21 10:22:52 <fcolista> before, no .so was provided
2019-05-21 10:22:55 <fcolista> right
2019-05-21 10:22:55 <_ikke_> well, no, no objection
2019-05-21 10:23:14 <fcolista> ok thx for crosscheck
2019-05-21 10:36:02 <clandmeter> fcolista: :)
2019-05-21 10:36:18 <fcolista> :D
2019-05-21 10:36:24 <clandmeter> it even has a windows client now :)
2019-05-21 10:36:42 <fcolista> amazing!
2019-05-21 10:47:41 <mps> clandmeter: finally :) and networkmanager have support for wireguard
2019-05-21 11:02:57 <clandmeter> mps, fcolista please check if new wireguard aports actually work as expected. could be i missed something.
2019-05-21 11:04:17 <mps> will do
2019-05-21 11:11:48 <mps> clandmeter: to build wireguard-vanilla we need to have wireguard-tools first in community? right?
2019-05-21 11:12:47 <clandmeter> i added a check which references community
2019-05-21 11:13:06 <clandmeter> if thats what you mean
2019-05-21 11:13:47 <mps> I see, will now first add tools and then vanilla, I started from wrong direction
2019-05-21 11:14:01 <clandmeter> ?
2019-05-21 11:14:11 <clandmeter> you cannot just install from repo
2019-05-21 11:14:17 <clandmeter> i alraedy pushed it
2019-05-21 11:14:31 <mps> i started to build wireguard-vanilla kernel module first
2019-05-21 11:14:46 <clandmeter> it should already be on our repos
2019-05-21 11:14:49 <clandmeter> or soon
2019-05-21 11:14:53 <mps> let me see
2019-05-21 11:15:49 <mps> oh, yes
2019-05-21 11:16:08 <mps> maybe I add cron job for git pull :)
2019-05-21 11:16:11 <clandmeter> there is some install_if logic i didnt test yet
2019-05-21 11:23:33 <mps> install worked fine
2019-05-21 11:23:54 <clandmeter> if you install the tools, will it also pull in the kernel module?
2019-05-21 11:23:56 <mps> later will try on real system
2019-05-21 11:24:18 <mps> again started from module, lets see
2019-05-21 11:26:25 <mps> no, wireguard-tools don't pull kernel module
2019-05-21 11:33:37 <clandmeter> mps: but you do have the kernel installed?
2019-05-21 11:42:06 <mps> no, kernel is not installed. I mean alpine kernel is not installed
2019-05-21 11:45:14 <mps> clandmeter: now I see that I cannot test this on my real box, will try later on qemu
2019-05-21 12:30:28 <mps> clandmeter: with kernel installed, 'apk add wireguard-tools' pulls wireguard-vanilla. so everything looks ok
2019-05-21 12:30:37 <clandmeter> thx
2019-05-21 12:30:46 <clandmeter> should be a newer version online
2019-05-21 12:31:01 <clandmeter> it should also pull it when just installing wireguard-tools-wg
2019-05-21 12:31:20 <mps> lets see
2019-05-21 12:31:51 <clandmeter> wg is the lightweight alternative without extra deps.
2019-05-21 12:34:02 <mps> 'apk add wireguard-tools-wg' only pulls libmnl
2019-05-21 12:34:13 <clandmeter> do you have r2?
2019-05-21 12:34:53 <mps> uh, no. r0 although did 'apk update'
2019-05-21 12:35:08 <clandmeter> i mean for the kernel module
2019-05-21 12:35:16 <mps> maybe will wait some time for mirror to update
2019-05-21 12:35:51 <mps> it is r1
2019-05-21 12:35:59 <clandmeter> thats not the latest :)
2019-05-21 12:36:18 <clandmeter> workdsfor me :)
2019-05-21 12:36:37 <mps> I see, but 'apk update' didn't help. will wait for mirror to sync
2019-05-21 12:37:12 <mps> wait, r1 wireguard-vanilla is latest?
2019-05-21 12:37:18 <clandmeter> https://tpaste.us/gM9v
2019-05-21 12:37:42 <mps> aha, r2
2019-05-21 12:40:40 <mps> now also wireguard-tools-wg pulls wireguard-vanilla
2019-05-21 12:40:52 <mps> clandmeter: well done :)
2019-05-21 12:41:05 <clandmeter> nice
2019-05-21 14:55:39 <north1> _ikke_: re: atools if i'm understanding correctly it should be . ./$apkbuild not . $apkbuild ?
2019-05-21 15:01:29 <tcely> north1: hmm? For what purpose?
2019-05-21 15:02:16 <tcely> Does including the dot slash avoid PATH search or something?
2019-05-21 15:04:00 <north1> tcely: https://github.com/maxice8/atools/issues/7https://github.com/maxice8/atools/issues/7
2019-05-21 15:10:01 <_ikke_> tcely: bash sh requires sourced files in the current dir to be prefixed with ./, just like executables
2019-05-21 15:11:19 <tcely> "The . and source builtins do not search the current directory for the filename argument if it is not found by searching PATH."
2019-05-21 15:11:34 <_ikke_> right
2019-05-21 15:11:36 <_ikke_> that
2019-05-21 15:11:46 <tcely> More accurately it only searches PATH. That makes sense.
2019-05-21 15:11:50 <_ikke_> yes
2019-05-21 15:11:56 <TML> export PATH="${PATH}:." # no, don't actually do that
2019-05-21 15:11:57 <_ikke_> just like with executables
2019-05-21 15:12:03 <TML> :D
2019-05-21 15:12:17 <SpaceToast> as a quick reference: this is because "sourced files" can be used *as* binaries
2019-05-21 15:12:23 <SpaceToast> (in the current context)
2019-05-21 15:12:29 <_ikke_> I just found out that in one PC, my path was suffixed with a ':', which is apparently similar to :.
2019-05-21 15:12:46 <SpaceToast> iirc some project management things actually take advantage to that, e.g ". proj do --thing"
2019-05-21 15:15:00 <tcely> I don't think I have ever seen . used that way.
2019-05-21 15:17:53 <_ikke_> north1: I think that should work even when you specify a different directory, so that makes sense, yes
2019-05-21 15:18:13 <SpaceToast> it's pretty uncommon nowadays, but it's entirely possible :)
2019-05-21 15:23:22 <north1> ok pushed
2019-05-21 15:23:42 <_ikke_> thanks
2019-05-21 15:37:27 <clandmeter> spam
2019-05-21 15:37:30 <_ikke_> gone
2019-05-21 15:37:35 <clandmeter> grazie
2019-05-21 15:47:05 <tcely> clandmeter: would you push pr7914 ? I dislike abusing WIP to keep stale bot at bay
2019-05-21 15:47:20 <_ikke_> wow
2019-05-21 15:47:30 <_ikke_> They are persistent
2019-05-21 15:48:22 <tcely> They probably just think there was an error posting the first one. ;-)
2019-05-21 15:48:38 <_ikke_> Well, I deleted the account, so they even reregistered
2019-05-21 15:49:25 <tcely> Cheeky
2019-05-21 16:32:26 <PureTryOut[m]> I have a package failing to compile in Alpine, but I can't really pinpoint the issue due to it compiling fine in postmarketOS. It just uses dependencies available in Alpine Linux edge however. `/usr/lib/libudev.so: undefined reference to 'name_to_handle_at'`. It makes me think there is an issue with eudev, but the exact same package is used in postmarketOS...
2019-05-21 16:33:45 <SpaceToast> PureTryOut[m]: what version of musl is being used on alpine?
2019-05-21 16:34:14 <SpaceToast> name_to_handle_at is not a (e)udev symbol, it's a libc one (a syscall wrapper iirc)
2019-05-21 16:35:26 <PureTryOut[m]> 1.1.22
2019-05-21 16:35:51 <SpaceToast> hmm, those were added in 1.1.21
2019-05-21 16:36:03 <SpaceToast> so you SHOULD have them
2019-05-21 16:36:13 <SpaceToast> still, sounds like some linking failure, more than anything
2019-05-21 16:36:32 <PureTryOut[m]> Oh wait my chroot is still using 1.1.20. Sorry my mistake, thanks for the help!
2019-05-21 16:36:37 <SpaceToast> there you go :) no problem
2019-05-21 16:36:54 <PureTryOut[m]> 
ACTION needs to upgrade his chroot more often

2019-05-21 17:34:58 <tcely> clandmeter: thanks
2019-05-21 18:07:33 <SpaceToast> north1: ping re: pr7907 - updated
2019-05-21 18:37:25 <mps> what is length limit of pkg name
2019-05-21 18:37:54 <mps> i have pkg 'arm-trusted-firmware-sun50i_a64', is it to long
2019-05-21 18:43:12 <mps> PureTryOut[m]: do we need DEBUG=1 in build of 'arm-trusted-firmware'
2019-05-21 18:44:53 <north1> SpaceToast: I'll take a look after i finish rewriting pr-fetcher
2019-05-21 19:14:10 <PureTryOut[m]> mps: probably not
2019-05-21 19:16:23 <mps> PureTryOut[m]: I made 'arm-trusted-firmware' and subpackage 'arm-trusted-firmware-sun50i_a64'
2019-05-21 19:16:45 <mps> does this naming scheme looks ok
2019-05-21 19:26:28 <mps> nmeum: are you maintainer of the android-tools
2019-05-21 19:28:01 <mps> I'm trying to upgrade it to 9.0.0_r33 version but 'abuild sanitycheck' gives me 'ERROR: android-tools: 9.0.0_r33 is not a valid version;
2019-05-21 19:29:16 <nmeum> yeah, _r is used to indicate the pkgrel and not a valid version nuber
2019-05-21 19:29:19 <nmeum> *number
2019-05-21 19:29:40 <mps> here is my diff http://tpaste.us/O1WY
2019-05-21 19:29:43 <nmeum> that's why the android-tools aport uses 9.0.0_p33 as a pkgver instead and substitues it later
2019-05-21 19:29:57 <mps> ah, so
2019-05-21 19:30:14 <mps> well, it doesn't need upgrade then, iirc
2019-05-21 19:30:18 <nmeum> yep
2019-05-21 19:30:27 <mps> ok, thanks
2019-05-21 19:30:30 <nmeum> np
2019-05-21 19:31:28 <mps> I learned something, i.e. look carefully to 'r' in pkgver
2019-05-21 20:07:05 <PureTryOut[m]> mps: yeah looks fine to me. I assume you build all the firmware, but only filter out `sun50i_a64` for now?
2019-05-21 20:14:21 <mps> PureTryOut[m]: no, just sun50i_a64 to see how all this could be done
2019-05-21 20:14:50 <PureTryOut[m]> Yeah sure, fine for me
2019-05-21 20:14:52 <mps> later we can add more of these firmwares as subpackages
2019-05-21 20:15:07 <PureTryOut[m]> Sounds good!
2019-05-21 20:16:02 <mps> and thinking to shorten name to 'arm-trusted-firmware-sun50i', sun50 is 64bit afaik
2019-05-21 20:16:27 <mps> so no 32bit version
2019-05-21 20:16:36 <PureTryOut[m]> Makes sense
2019-05-21 20:17:05 <mps> next thing is how to integrate it to u-boot build
2019-05-21 20:17:31 <PureTryOut[m]> With just this module it's easy. Not sure what happens when we add more firmware packages in the future
2019-05-21 20:17:59 <mps> u-boot is in main and main pkg can't depend on packages from community or testing
2019-05-21 20:18:43 <mps> if we made sane subpackages from the start I hope it would be easier later
2019-05-21 20:20:09 <mps> give me few minutes and I will post APKBUILD to you for review
2019-05-21 20:23:21 <mps> PureTryOut[m]: here is the 'arm-trusted-firmware` APKBUILD http://tpaste.us/wjlX
2019-05-21 20:26:15 <PureTryOut[m]> Yeah seems good. Of course remove the empty variables and commented out stuff when committing it, but it seems good
2019-05-21 20:28:17 <mps> now I have to figure how to integrate it to u-boot build. If you have any idea please help
2019-05-21 20:28:55 <mps> I'm adding sun50i subpackage first to u-boot
2019-05-21 20:29:14 <mps> to make separate u-boot for these boards
2019-05-21 20:30:59 <PureTryOut[m]> aarch64 only make dependency though
2019-05-21 20:32:01 <PureTryOut[m]> The problem is that currently the same u-boot image is built no matter what device you're using. However, this firmware is only needed for some devices/platforms
2019-05-21 20:32:07 <PureTryOut[m]> So you can't do a general "if aarch64 then use firmware"
2019-05-21 20:32:51 <PureTryOut[m]> actually, it's not that bad, we already build per board
2019-05-21 20:33:06 <PureTryOut[m]> I guess that board_configs loop needs a check for which platform you're building
2019-05-21 20:33:23 <PureTryOut[m]> for now it'll only contain an allwinner check, and otherwise don't export `$BL31`
2019-05-21 20:33:32 <mps> I see that you added some pine64
2019-05-21 20:33:45 <PureTryOut[m]> Yeah, that one definitely needs this new subpackage
2019-05-21 20:34:04 <mps> and you renamed 'beagleboard:am335x_boneblack' to 'beagleboard:am335x_boneblack_vboot'
2019-05-21 20:34:09 <PureTryOut[m]> so if board_config == pine64 then export `$BL31`
2019-05-21 20:34:33 <PureTryOut[m]> yeah am335x_boneblack isn't available anymore in u-boot. It seems to just be renamed to the vboot one, but I'm not entirely sure about that one
2019-05-21 20:34:41 <PureTryOut[m]> and I don't have a beagleboard to test it on
2019-05-21 20:35:04 <mps> yes, checking board name and then export BL31 makes sense
2019-05-21 20:35:48 <mps> isn't 'vboot' chromeos sign tool
2019-05-21 20:36:16 <PureTryOut[m]> No clue tbh
2019-05-21 20:36:31 <mps> it looks strange to name am335x_boneblack with this addon
2019-05-21 20:37:13 <mps> I have vboot utils built locally because I need it to sign kernels for chromebooks
2019-05-21 20:37:44 <PureTryOut[m]> I don't know tbh, someone with a beagleboard will need to confirm
2019-05-21 20:37:59 <mps> ok
2019-05-21 20:39:03 <mps> will look how to make it, and we have to see if 'arm-trusted-firmware' could be added to main which will need some time
2019-05-21 20:39:33 <PureTryOut[m]> That'd be nice
2019-05-21 20:39:34 <PureTryOut[m]> I'm not in a hurry luckily
2019-05-21 20:39:35 <mps> but I think you can put it on your local repo from which you build pmOS
2019-05-21 20:39:58 <PureTryOut[m]> We have a working setup already, I just wanted to do it properly for Alpine lol
2019-05-21 20:40:07 <mps> btw, I really appreciate your works on pmOS
2019-05-21 20:40:09 <PureTryOut[m]> For pmOS we don't have to care about other boards atm
2019-05-21 20:40:14 <PureTryOut[m]> Thanks!
2019-05-21 20:41:54 <mps> ok, that's all for now I have to say about this. In meantime if some ideas comes to you please tell me
2019-05-21 20:42:47 <PureTryOut[m]> Our current approach seems good to me. I just want someone to make sure this still works on a beagleboard and if not, how to fix it
2019-05-21 20:44:23 <mps> I don't know any with this board
2019-05-21 20:48:26 <PureTryOut[m]> Maybe it's an option to remove it then?
2019-05-21 20:50:29 <mps> If I don't know anyone using it that doesn't mean no one using it, so I wouldn't remove it
2019-05-21 20:51:05 <PureTryOut[m]> That's why I'm saying it might be an option πŸ˜‰
2019-05-21 20:51:50 <mps> np. I understand
2019-05-21 21:06:10 <mps> PureTryOut[m]: I've got u-boot-pine64-2019.01-r0.apk with file in it 'usr/share/u-boot/pine64-lts/u-boot-sunxi-with-spl.bin'
2019-05-21 21:07:11 <mps> (and someone have to send me hardware on which I can check if it works :) )
2019-05-21 21:08:11 <danieli> iirc they're not too expensive
2019-05-21 21:09:29 <mps> danieli: I'm kidding a little, if someone offer it I would not accept it
2019-05-21 21:09:38 <danieli> right
2019-05-21 21:09:39 <danieli> why not?
2019-05-21 21:09:49 <danieli> I mean, if it was a donation
2019-05-21 21:10:16 <mps> I have chromebooks and they are enough hassle for me, no need more
2019-05-21 21:15:38 <PureTryOut[m]> mps: yeah that's the correct content
2019-05-21 21:16:56 <PureTryOut[m]> Although shouldn't it be 2019.04? πŸ€”
2019-05-21 21:17:27 <mps> PureTryOut[m]: I can post changed u-boot APKBUILD to you if you want to try it yourself and test if it works
2019-05-21 21:17:45 <PureTryOut[m]> I rather have the .apk's tbh
2019-05-21 21:17:49 <mps> yes, I noticed older version, will fix it later
2019-05-21 21:18:05 <PureTryOut[m]> There is a bug in our pmbootstrap tool currently which prevents us from using arch specific makedepends
2019-05-21 21:18:09 <mps> ok, I can put apk somewhere
2019-05-21 21:18:16 <PureTryOut[m]> Thanks
2019-05-21 21:18:57 <mps> well, give me some time, now I'm just get out to relax little
2019-05-21 21:19:07 <PureTryOut[m]> If you're going with 2019.01, please make it -r1 otherwise it'll just take our own u-boot lol
2019-05-21 21:19:10 <PureTryOut[m]> Of course!
2019-05-21 21:19:32 <mps> no, I will make 2019.04 later
2019-05-21 21:20:39 <mps> I already thought to upgrade u-boot for next stable alpine release
2019-05-21 21:21:40 <mps> maybe ask rnalrd to upgrade it, he is maintainer at the end
2019-05-21 22:01:18 <clandmeter> docker-abuild now uses "official" alpinelinux docker registry
2019-05-21 22:02:29 <clandmeter> mps, including arm support :)
2019-05-21 22:05:16 <mps> clandmeter: will look at it when I found some time
2019-05-21 22:06:16 <clandmeter> i will add a few more modifications and then probably add it to aports
2019-05-21 22:06:26 <mps> now I'm back to rust, trying to fix llvm to build rust correctly
2019-05-21 22:07:59 <mps> short question, can I run docker-build on x86_64 and build arm on it, or have to run it on native hardware
2019-05-21 22:11:24 <clandmeter> no that wont work
2019-05-21 22:11:33 <clandmeter> you will need qemu or similar
2019-05-21 22:13:03 <mps> so, have to run it on native hardware or lxc container on native hardware
2019-05-21 22:13:18 <clandmeter> if your cpu supports 32bit, you can build for instance x86 on x86_64 and armhf/v7 on aarch64
2019-05-21 22:13:21 <mps> s/or /or in /
2019-05-21 22:13:21 <alpine-meetbot> mps meant to say: so, have to run it on native hardware or in lxc container on native hardware
2019-05-21 22:13:58 <clandmeter> yes on native hardware
2019-05-21 22:14:28 <mps> aha, good thing
2019-05-21 22:14:33 <clandmeter> but it also support multiple branches
2019-05-21 22:15:07 <clandmeter> so if you checkout stable branch dabuild will detect it and pull stable image from hub and build it cleanly in correct env.
2019-05-21 22:15:54 <mps> sounds quite good, will devote some time to test it, but not these days
2019-05-21 22:16:12 <mps> simply put, short time
2019-05-21 22:19:02 <mps> clandmeter: thanks for info and good night :)
2019-05-21 22:51:58 <SpaceToast> how do gcc updates usually go?
2019-05-21 22:52:02 <SpaceToast> (major versions, that is)
2019-05-21 22:52:11 <SpaceToast> we seem to have quite a few patches and they don't apply cleanly
2019-05-21 22:52:20 <SpaceToast> (and the de-facto purpose of some isn't clear)
2019-05-21 22:58:20 <danieli> how they usually go? painstakingly and slowly
2019-05-22 02:19:38 <pete> Anyone home?
2019-05-22 02:21:20 <north1> yes
2019-05-22 02:21:51 <pete> Sweet. I have a question about the lib subpackage
2019-05-22 02:22:54 <north1> throw it
2019-05-22 02:23:19 <pete> When does something go there vs the main package? and obviously .a static libraries are only included in the dev subpackage, but I'm assuming both the main package and the dev subpackage pull in the libraries in the lib subpackage?
2019-05-22 02:25:56 <north1> lib$pkgname and $pkgname-libs usually are done when the package also provides commandline tools (see elogind)
2019-05-22 02:26:05 <north1> .a static libraries should go into a $pkgname-static subpackage
2019-05-22 02:27:05 <pete> Ahh that makes a lot of sense lol
2019-05-22 02:34:02 <pete> Looking at elogind, I see '$pkgname-zsh-completion:zshcomp:noarch', but in the subpackages documentation I don't see a reference to a third field separated by ':'
2019-05-22 02:34:54 <pete> I'm thinking that for custom subpackages one may indicate if that subpackage is NOT architecture-dependent?
2019-05-22 02:35:43 <north1> yes
2019-05-22 02:35:51 <north1> documentation is sore point
2019-05-22 02:36:16 <pete> It's really not too bad compared to say Debian package documentation :p
2019-05-22 02:39:05 <north1> I like void-linux/void-packages' Manual.md
2019-05-22 02:40:20 <pete> I'll definitely check that out
2019-05-22 02:41:05 <pete> So If I'm making a library-only package, I should just call it lib$pkgname and only have a dev subpackage.
2019-05-22 02:42:49 <north1> i'd rather just have $pkgname and have $pkgname-dev
2019-05-22 02:42:59 <north1> i am a fan of following upstream naming convention
2019-05-22 02:45:03 <pete> got it. Well the upstream project is literally called 'libfort'
2019-05-22 02:45:50 <north1> well then the $pkgname is libfort :D
2019-05-22 02:46:13 <pete> I guess my example would have resulted in liblibfort
2019-05-22 02:46:21 <pete> anyway... lol
2019-05-22 02:47:19 <pete> What is the policy for .so names and symlinks? I read somewhere that alpine doesn't use /etc/ld.so.conf.
2019-05-22 02:48:17 <pete> Should I do something like, libx.so.1.0.0; libx.so.1 -> libx.so.1.0.0; libx.so -> libx.so.1 ?
2019-05-22 02:48:35 <north1> the build system of the upstream package should do that automatically
2019-05-22 02:48:43 <north1> but yes that is basically how soname handling works in every distro
2019-05-22 02:48:56 <pete> coolio.
2019-05-22 02:49:04 <north1> libfoo.so.1.0.0 and libfoo.so.1 -> libfoo.so.1.0.0 go into the lib pacakge and libfoo.so goes into the -dev package
2019-05-22 02:49:10 <pete> I am working with the upstream dev to make sure these things get generated properly
2019-05-22 02:49:56 <north1> build systems like GNU autoconf and meson should do it automatically
2019-05-22 02:50:10 <pete> Yeah they are using Cmake
2019-05-22 02:50:50 <pete> Does that mean that libfoo.so.1.0.0 and libfoo.so are both real files and are identical?
2019-05-22 02:51:05 <north1> libfoo.so.1.0.0 is the file
2019-05-22 02:51:13 <north1> libfoo.so.1 and libfoo.so are symlinks to it
2019-05-22 02:51:43 <pete> so installing the dev package implies the lib package?
2019-05-22 02:52:21 <north1> yes, $pkgname-dev will always bring in the lib$pkgname or $pkgname-libs
2019-05-22 02:52:58 <pete> ah i see
2019-05-22 02:53:30 <pete> and $pkgname brings in libs
2019-05-22 02:54:14 <north1> then $pkgname-dev will automatically depend on $pkgname
2019-05-22 02:55:07 <pete> I need to draw out this dependency graph lol
2019-05-22 02:57:51 <pete> so if one's package has no command-line apps, then it should not create a lib subpackage correct? If that is so, then rather than $pkgname-dev requiring $pkgname-libs, it requires $pkgname? Is that correct?
2019-05-22 03:00:10 <north1> Generally Yes. Yes. Yes
2019-05-22 03:01:34 <pete> abuild will figure it out magically ? \
2019-05-22 03:01:37 <pete> :p
2019-05-22 03:02:23 <[[sroracle]]> it figures out where symlinks point to
2019-05-22 03:02:25 <north1> from what i experienced, yes
2019-05-22 03:02:29 <[[sroracle]]> and adds dependencies as necessary
2019-05-22 03:02:40 <pete> I see
2019-05-22 03:02:45 <[[sroracle]]> so in this case it'll add a dependency to whatever package contains the file that the .so symlink points to
2019-05-22 03:02:48 <pete> I've been trying to look around in it
2019-05-22 03:02:50 <north1> I didn't bother to actually check how alpine traces dependencies, i only know how xbps-src does it
2019-05-22 03:03:28 <pete> thanks sroracle
2019-05-22 03:03:44 <[[sroracle]]> in general it traces symlinks, pkgconf files (.pc), sonames, etc
2019-05-22 03:03:51 <pete> and north1
2019-05-22 03:03:55 <pete> sweet
2019-05-22 03:05:52 <pete> And should we always and only assume that everything provided by 'build-base' is available?
2019-05-22 03:06:35 <pete> abuild rootbld seems to catch any dependency assumptions
2019-05-22 03:08:46 <[[sroracle]]> yes
2019-05-22 03:09:22 <[[sroracle]]> unless you're bootstrapping a new arch, in which case you get to assume even less :P
2019-05-22 03:09:51 <pete> Nice lol. What is the preferred method of submitting a new package, via the email
2019-05-22 03:10:01 <pete> +patch route or a Github PR?
2019-05-22 03:10:20 <north1> Github PR seem to be the most popular but both are supported
2019-05-22 03:10:28 <north1> whatever feels more comfortable to you i guess
2019-05-22 03:10:51 <pete> Cool. I'm pretty sure Alpine existed before Github, so it makes sense.
2019-05-22 03:19:41 <pete> I have another Q for your collective intelligence(s)
2019-05-22 03:20:08 <pete> What if for my own purposes I wanted to create a packager for a cross-compiler
2019-05-22 03:20:46 <pete> a package*
2019-05-22 03:23:11 <pete> I suppose I would need to make a build-base and it's dependencies for this cross compiler
2019-05-22 03:23:15 <pete> its*
2019-05-22 03:24:22 <pete> My use case is that my work makes cross toolchains with buildroot and I was thinking about attempting to package buildroot's toolchain output as Alpine packages
2019-05-22 03:24:44 <pete> Creating a new pacakge repo of this cross compiled with this new compiler
2019-05-22 03:24:51 <pete> package*
2019-05-22 03:27:04 <pete> Another hairy aspect is that we use 'cross compiling' on x86_64 for x86_64, where the cross toolchain is an x86_64 compiler tuned to a specific Intel architecture. I need to find a way to indicate a specific x86_64 toolchain to abuild
2019-05-22 05:07:08 <north1> Need a CI-malfunction tag on pr7996
2019-05-22 05:19:32 <tcely> That's a check sum failure
2019-05-22 10:39:12 <hrio[m]> rnalrd I think we should accept pw4887, can you push it? Thanks
2019-05-22 11:27:28 <mps> noticed file 'community/glm/fix-const-expr.patch: unified diff output, ASCII text, with CRLF line terminators'
2019-05-22 11:28:00 <mps> is it ok to accept files with CRLF to aports?
2019-05-22 11:28:22 <_ikke_> shell scripts should be LF only
2019-05-22 11:29:10 <mps> this one is patch file, and I still think it should be LF only
2019-05-22 11:29:28 <_ikke_> Depends on the file being patched I guess
2019-05-22 11:30:42 <mps> right, but in this case it is original file, i.e. file had CRLF when is added in first commit
2019-05-22 11:35:32 <artok> I've gotten many problems when patches are crlf
2019-05-22 11:39:58 <mps> 'find -type f | xargs file | grep CRLF' shows about twenty such files in aports
2019-05-22 11:47:29 <mps> hmm, I see, file which is patched have CRLF, so everything is ok
2019-05-22 11:49:29 <artok> let me guess, zip package for original source rather than tar.gz ?
2019-05-22 11:50:06 <mps> yes, just downloading tar.gz to see if it is ok
2019-05-22 11:50:24 <artok> there you'll have the problem
2019-05-22 11:51:11 <mps> I do not, but original APKBUILD poster
2019-05-22 11:52:28 <mps> tar.gz have LF's and not CRLF's
2019-05-22 11:53:11 <artok> yes as usually .zip are for windows people
2019-05-22 11:54:20 <mps> true, but in this case this is cross platform pkg https://glm.g-truc.net/0.9.9/index.html
2019-05-22 11:55:19 <artok> well I've done cross platform stuff and all goes best if you use tar.gz stuff
2019-05-22 11:56:38 <mps> artok: yes, with little discipline all can work fine
2019-05-22 11:58:28 <artok> when hassling with cmake scripts that should work under macOS, VS2016+, and linux.. you'll learn the hard way =)
2019-05-22 12:01:32 <mps> touched them a little and think I understand what you want to say ;)
2019-05-22 12:07:19 <artok> patch commands fail...
2019-05-22 12:08:54 <mps> yes, :(
2019-05-22 12:10:31 <mps> I'm thinking to ask glm maintainer (ncopa) to remove it and add again with tar.gz in source, but don't know would that be impolite
2019-05-22 12:10:40 <artok> have zip one, patch it, run dos2unix on that whole dir, diff the tar.gz to get proper patch =D
2019-05-22 12:12:47 <mps> that would be a big patch
2019-05-22 12:34:05 <artok> not that big, as it would just handle crlf...
2019-05-22 16:19:57 <Cogitri> Should I file feature request for the packaging format against apk?
2019-05-22 16:21:07 <Cogitri> I want to suggest adding "weak dependencies" support to APK. It is a dependency that is selected _by default_, but can be removed with a `apk del` (or we could add a switch to apk add to not even install them) for optional deps
2019-05-22 16:21:35 <Cogitri> Our current approach of either hard depending or just shrugging it off like "the user will install it at one point if he needs it" doesn't cut it IMHO
2019-05-22 16:22:43 <Cogitri> And with weak dependencies Alpine can still stay super small without sacrificing the experience of users which want stuff to work by default (for a recent example: automatically install the icon theme&gtk theme for XFCE but allow uninstalling/not adding it if you don't want to use that)
2019-05-22 16:22:48 <mps> something like Debian 'Recomends'?
2019-05-22 16:23:11 <danieli> i'd consider recommends opt-in, not opt-out
2019-05-22 16:24:11 <Cogitri> <danieli "i'd consider recommends opt-in, "> Maybe just make it a config option in apk's config file, how about that?
2019-05-22 16:24:26 <danieli> don't get me wrong, that's not a strong opinion
2019-05-22 16:24:28 <Cogitri> <mps "something like Debian 'Recomends"> Like https://fedoraproject.org/wiki/Packaging:WeakDependencies
2019-05-22 16:24:51 <SpaceToast> I'd prefer something like `apk add --include-recommends`
2019-05-22 16:24:58 <Cogitri> <danieli "don't get me wrong, that's not a"> Oh, no worries, I won't ignore your opinion just because it's "not strong" :)
2019-05-22 16:25:13 <SpaceToast> apk del master would remove master-optional, apk del master-optional would not remove master
2019-05-22 16:25:17 <Cogitri> <SpaceToast "I'd prefer something like `apk a"> Which makes it super awkward to use and barely even used at all
2019-05-22 16:25:21 <mps> Cogitri: you don't have to 'quote' our messages when replying
2019-05-22 16:25:26 <SpaceToast> ^
2019-05-22 16:25:38 <danieli> i agree with SpaceToast
2019-05-22 16:25:40 <SpaceToast> people don't have to use it - that's the point
2019-05-22 16:25:45 <SpaceToast> if you want to use it, you can
2019-05-22 16:25:54 <Cogitri> IMHO either a opt-out switch or a config switch in apk's config
2019-05-22 16:26:04 <Cogitri> mps: Ah, sure, got used to it in Matrix
2019-05-22 16:26:08 <mps> to me Cogitri's proposal sounds fine
2019-05-22 16:26:20 <Cogitri> Specifying it every time sounds annoying
2019-05-22 16:26:31 <SpaceToast> alias apk='apk --include-recommends'
2019-05-22 16:26:50 <Cogitri> And prone to simply forgetting it. Maybe we can add it to setup-* with a "Choose flavour:[minimal] [desktop]" or smth
2019-05-22 16:26:59 <mps> switch to apk tools and maybe even config option somewhere in /etc/apk dir
2019-05-22 16:27:09 <SpaceToast> either way, default should be off
2019-05-22 16:27:20 <SpaceToast> why is forgetting to install some optional dependencies such a big deal?
2019-05-22 16:27:38 <Cogitri> Yup, the /etc/apk config thingie sounds good
2019-05-22 16:27:45 <Cogitri> SpaceToast: IMO we should add config switches for things that change frequently, but I don't think that this preference will change often
2019-05-22 16:27:58 <SpaceToast> I think it would change on a package-by-package basis
2019-05-22 16:28:00 <Cogitri> <SpaceToast "why is forgetting to install som"> Because it hurts user experience
2019-05-22 16:28:08 <mps> if there is such option it make sense to be set permanently somewhere, imo
2019-05-22 16:28:30 <SpaceToast> optional dependencies can be quite far-reaching
2019-05-22 16:28:37 <Cogitri> Also, I'd opt for default off + a explicit choice in setup-alpine which sets some config option
2019-05-22 16:28:51 <SpaceToast> command line flag would still be important though
2019-05-22 16:28:58 <SpaceToast> for ansible/salt/etc
2019-05-22 16:29:09 <Cogitri> <SpaceToast "optional dependencies can be qui"> Sure, they shouldn't include _everything_, but what you need for the _standard_ configuration to work
2019-05-22 16:29:22 <mps> yes, setup-alpine could offer user to choose if s/he wants that
2019-05-22 16:29:45 <SpaceToast> what you need for the STANDARD configuration to work should be hard deps.
2019-05-22 16:29:46 <Cogitri> Sure, we can also add a switch, config (with choice in setup-alpine) + switch sounds good?
2019-05-22 16:29:58 <SpaceToast> the whole point of having optional dependencies is to... document *optional* dependencies
2019-05-22 16:30:16 <Cogitri> <SpaceToast "what you need for the STANDARD c"> Well, mps complained when I suggested adding the standard icon & gtk theme to xfce
2019-05-22 16:30:19 <SpaceToast> things like cherrypy for salt-master and py-psutil for salt-minion
2019-05-22 16:30:38 <SpaceToast> you're not really supposed to `apk add xfce`, though
2019-05-22 16:30:45 <SpaceToast> `apk add alpine-desktop` instead :)
2019-05-22 16:32:07 <Cogitri> That seems a bit counterintuitive to me
2019-05-22 16:33:02 <Cogitri> Oh well, I'd be super happy if we'd get weak/optional deps at all, the current setup is a bit unsatisfactory
2019-05-22 16:33:15 <SpaceToast> alpine has, historically, focused on minimal dependencies, from what I can tell - the user can install what they want
2019-05-22 16:33:22 <SpaceToast> if you want to install xfce
2019-05-22 16:33:24 <SpaceToast> you get xfce
2019-05-22 16:33:31 <SpaceToast> not a full desktop environment
2019-05-22 16:33:38 <SpaceToast> similarly, if you want to install xfwm
2019-05-22 16:33:47 <SpaceToast> it won't ALSO install xfce, since most people that want xfwm likely want xfce
2019-05-22 16:33:58 <SpaceToast> instead, you get a metapackage, that gets you what it says on the box - an alpine desktop
2019-05-22 16:35:34 <mps> agree, I prefer minimal deps, but i'm not against adding option to 'weak' ones
2019-05-22 16:35:43 <Cogitri> <SpaceToast "alpine has, historically, focuse"> Yup, so having optional deps to ensure that users who want minimal installs can have just that while users who want a complete experience are also satisfied with the way apk works doesn't sound like a bad idea, does it?
2019-05-22 16:36:31 <mps> more and more people want simple installation of full DE in one command invocation
2019-05-22 16:36:46 <Cogitri> Hm, the alpine-desktop package doesn't seem so well known then, no one in #alpine-linux has mentioned it at least when the xfce Icon-theme thingie came up
2019-05-22 16:36:57 <danieli> mps: yeah, it's an unfortunate situation
2019-05-22 16:36:59 <Cogitri> Yup
2019-05-22 16:37:15 <SpaceToast> Cogitri: start telling'em about it then :)
2019-05-22 16:37:34 <mps> danieli: can't tell how much I agree with you :)
2019-05-22 16:37:36 <SpaceToast> there's nothing wrong with wanting convenience
2019-05-22 16:38:00 <SpaceToast> I'm just against sacrificing other things for it
2019-05-22 16:38:08 <danieli> convenience, in this case, inherently requires bloat
2019-05-22 16:38:20 <SpaceToast> I don't think that's necessarily true
2019-05-22 16:38:24 <Cogitri> <SpaceToast "I'm just against sacrificing oth"> Yup, I'm all for that
2019-05-22 16:38:28 <SpaceToast> but it'd take quite a bit of effort to be optimal
2019-05-22 16:38:30 <Cogitri> That's why it's a config switch :)
2019-05-22 16:38:37 <SpaceToast> (much beyond a "one and done" config switch)
2019-05-22 16:38:58 <tcely> SpaceToast: which other things?
2019-05-22 16:39:05 <danieli> not necessarily true of course, but generally, it seems to be
2019-05-22 16:39:25 <SpaceToast> tcely: things like making technically correct decisions, for instance
2019-05-22 16:39:27 <Cogitri> I don't see anything left to be done other than setting the switch to enable optional deps either
2019-05-22 16:39:42 <SpaceToast> well, consider some example package
2019-05-22 16:39:50 <SpaceToast> let's call it "networkmanager2"
2019-05-22 16:40:06 <SpaceToast> it has integrations to various desktop environments
2019-05-22 16:40:13 <SpaceToast> which ones make it into the optional deps?
2019-05-22 16:40:16 <SpaceToast> do we have optional_install_if?
2019-05-22 16:40:20 <SpaceToast> how is that handled?
2019-05-22 16:40:46 <SpaceToast> I came here from gentoo, where this problem was solved with use-flags, but that seems very overkill for a pure "optional deps" scenario
2019-05-22 16:41:03 <SpaceToast> I think a good starting point would be something similar to arch:
2019-05-22 16:41:13 <SpaceToast> 1. have the ability to list optional deps (and what they're for)
2019-05-22 16:41:19 <Cogitri> Yup, very overkill
2019-05-22 16:41:32 <SpaceToast> 2. have the ability to install things "as deps", and not get removed if they're an optional dep for something still there
2019-05-22 16:41:43 <SpaceToast> once that's done, it'd be possible to think about what to do beyond that
2019-05-22 16:41:48 <Cogitri> Optional deps which are just printed to the terminal?
2019-05-22 16:42:00 <SpaceToast> with formatting, ofc
2019-05-22 16:42:11 <Cogitri> <Cogitri "Optional deps which are just pri"> Which 95% of users don't read?
2019-05-22 16:42:16 <SpaceToast> if you wanted to install them by hand, you could do `apk add $(apk info -q $package)`
2019-05-22 16:42:34 <Cogitri> I mean sure, that's their fault, but you shouldn't have to be on the lookout for optional deps on every install IMHO
2019-05-22 16:42:37 <SpaceToast> you can have your flag (default off) on top of that ;)
2019-05-22 16:43:10 <tcely> networkmanager2-DE seems like the obvious solution. Am u missing something?
2019-05-22 16:43:15 <Cogitri> Sure, have a `optional-deps={print,install,off}` sounds good
2019-05-22 16:43:25 <Cogitri> I guess print could be the default then?
2019-05-22 16:43:46 <Cogitri> <tcely "networkmanager2-DE seems like th"> That would be just a plain metapackage for the deps? That sounds a bit hacky
2019-05-22 16:44:09 <tcely> Now networkmanager2 not depending on say iptables is a bigger problem in my view
2019-05-22 16:44:18 <SpaceToast> tcely: but then how do you auto-select it?
2019-05-22 16:44:39 <tcely> install_if ?
2019-05-22 16:44:39 <SpaceToast> Cogitri: no, optional-deps=on|off; print is an `info` flag
2019-05-22 16:44:50 <SpaceToast> but they're optional!
2019-05-22 16:44:55 <SpaceToast> so we're back to optional_install_if
2019-05-22 16:44:59 <SpaceToast> which seems silly to me :)
2019-05-22 16:45:15 <Cogitri> SpaceToast: Alright, that sounds good
2019-05-22 16:45:38 <SpaceToast> so people that want "auto everything", even with bloat can set it to "on"
2019-05-22 16:45:45 <tcely> why? Install_if with networkmanager2 and DE
2019-05-22 16:46:02 <SpaceToast> tcely: because it's *optional*
2019-05-22 16:46:10 <SpaceToast> you may want networkmanager2, and want DE, but not networkmanager2-DE
2019-05-22 16:46:23 <SpaceToast> everyone else is encouraged to run `apk info -O $package` and see the list with explanations
2019-05-22 16:46:33 <SpaceToast> and then they could `apk add --as-deps` various selections
2019-05-22 16:46:59 <SpaceToast> as further improvement, `apk add --optional=category1[,category2]` would be nice, and could actually be done as tcely suggests, but that'd be more complex
2019-05-22 16:47:00 <Cogitri> Sounds rather cumbersome to me, but sure
2019-05-22 16:47:18 <Cogitri> That would be cool indeed, didn't consider that!
2019-05-22 16:47:52 <Cogitri> Sadly apk is in C, otherwise I'd start working on it :c
2019-05-22 16:47:58 <SpaceToast> however, I don't think any of this could/should happen anytime soon
2019-05-22 16:48:13 <SpaceToast> APKINDEX has been under rework for a while now (e.g to address the cache issue)
2019-05-22 16:48:22 <SpaceToast> so all of this should probably wait until after that :/
2019-05-22 16:48:36 <Cogitri> Alrighty
2019-05-22 16:48:40 <Cogitri> I guess I'll open a bug on b.a.o then
2019-05-22 16:49:41 <tcely> What categories do you propose?
2019-05-22 16:50:20 <Cogitri> I feel like one for each DE would be too much work. Maybe just standard and full?
2019-05-22 16:50:36 <SpaceToast> well, that's the crux of the issue, isn't it?
2019-05-22 16:50:44 <SpaceToast> my mind keeps wandering back to use-flags (i.e maintainer-specified)
2019-05-22 16:50:46 <Cogitri> Where "standard" is what the maintainer considers sane?
2019-05-22 16:50:49 <SpaceToast> but that's likely wrong
2019-05-22 16:51:07 <SpaceToast> Cogitri: this is bigger than just user-interfaces
2019-05-22 16:51:14 <SpaceToast> consider, again, salt-minion and py-psutil
2019-05-22 16:51:18 <SpaceToast> would that be under xfce? ;)
2019-05-22 16:51:35 <Cogitri> That's why I said standard and full :)
2019-05-22 16:52:00 <SpaceToast> I think that's similarly too restrictive - what about the networkmanager2 example
2019-05-22 16:52:14 <SpaceToast> I can't come up with a complete way that isn't basically "maintainer specifies the categories"
2019-05-22 16:52:26 <SpaceToast> but that might just be my portage-contaminated mind
2019-05-22 16:52:42 <Cogitri> Well, we print optional deps, so that should take care of the DE specific deps I suppose?
2019-05-22 16:52:49 <_ikke_> If optional depends are behind a flag / config option, aren't most users forget to specify it, defeating the user convenience?
2019-05-22 16:53:01 <Cogitri> Although about all packages pay attention to such stuff so that we van subpackage it
2019-05-22 16:53:14 <Cogitri> Exactly my point, Ikke
2019-05-22 16:53:25 <Cogitri> But I think it's OK if we put it in the installer
2019-05-22 16:53:27 <tcely> Yes, it would need to be opt-out for convenience
2019-05-22 16:54:05 <SpaceToast> _ikke_: I'm suggesting a tiered system (for long-term)
2019-05-22 16:54:09 <Cogitri> 
ACTION goes afk for a bit

2019-05-22 16:54:48 <_ikke_> I hate that a lot of packages in ubuntu automatically install apache as webserver
2019-05-22 16:54:49 <SpaceToast> I'd recommend reading the history, though it's likely quite long by now
2019-05-22 16:54:57 <SpaceToast> apache is awful :(
2019-05-22 16:55:13 <SpaceToast> but yeah, I'm trying to avoid that, in part
2019-05-22 17:06:46 <SpaceToast> oh, also, heya _ikke_ :)
2019-05-22 17:08:06 <_ikke_> o/
2019-05-22 17:13:02 <north1> _ikke_: o/
2019-05-22 17:14:43 <_ikke_> north1: \o
2019-05-22 17:15:31 <north1> How is the tests PR ? i pushed the . ./$apkbuild change
2019-05-22 17:16:02 <_ikke_> The PR is ready
2019-05-22 17:16:14 <_ikke_> It was not really affected by the issue
2019-05-22 17:16:25 <_ikke_> I just ran into that while working with it manually
2019-05-22 17:24:56 <north1> so good to merge ?
2019-05-22 17:25:35 <_ikke_> I think there is one bug I marked as skipped
2019-05-22 17:25:52 <_ikke_> (in total 3 skipped)
2019-05-22 17:26:14 <_ikke_> ok 8 empty global variable can be removed # skip broken
2019-05-22 17:26:22 <_ikke_> You could check if that's correct or not
2019-05-22 17:29:16 <north1> ok i'll take another look
2019-05-22 17:31:05 <mps> speaking of deps, I rebuilt gimp and cups without dbus and both works fine
2019-05-22 17:43:20 <_ikke_> north1: I rebased the PR on top of your latest change
2019-05-22 17:43:40 <north1> _ikke_: ./$apkbuild breaks bat
2019-05-22 17:43:43 <north1> since $BATS_TMPDIR is $TMPDIR which is /tmp
2019-05-22 17:43:50 <north1> and it tries to source .//tmp/APKBUILD
2019-05-22 17:44:59 <_ikke_> hmm
2019-05-22 17:45:10 <north1> well it works without it
2019-05-22 17:45:57 <north1> ok i pushed to master again, can you rebase ?
2019-05-22 18:01:49 <tcely> north1: the simple solution to that is: cd /; . ./$apkbuild ; cd -
2019-05-22 18:03:44 <north1> sounds good
2019-05-22 18:03:58 <north1> it apparently works here though
2019-05-22 18:04:01 <north1> or i'm doing something wrong ?
2019-05-22 18:05:21 <north1> and the latest commit also fixed empty variable detection so the test doesn't need to be skipped
2019-05-22 18:24:55 <_ikke_> ok, will rebase
2019-05-22 18:25:46 <mps> this https://patchwork.alpinelinux.org/patch/4851/ looks as it is applied and there is https://github.com/alpinelinux/aports/pull/7800 merged. It should be marked on pw.a.o as Rejected or Accepted?
2019-05-22 18:27:21 <danieli> mps: just fyi, i marked my elixir and erlang upgrades as not applicable
2019-05-22 18:29:06 <mps> ahm. pity. erlang is nice language
2019-05-22 18:29:54 <danieli> erlang isn't maintained either, which is a shame
2019-05-22 18:30:20 <_ikke_> north1: done
2019-05-22 18:30:56 <mps> yes, and no one who use erlang would step to maintain it?
2019-05-22 18:31:07 <danieli> seems so
2019-05-22 18:31:34 <danieli> i only know of one erlang (by proxy) user in the alpine community and he's the ex-maintainer
2019-05-22 18:31:38 <mps> is it so complicated
2019-05-22 18:59:01 <tcely> mps: I'd pick accepted
2019-05-22 19:05:30 <danieli> so many raspberry pi issues lately
2019-05-22 19:05:48 <_ikke_> It's a popular device
2019-05-22 19:06:34 <danieli> it is indeed
2019-05-22 19:06:48 <danieli> i have 4 or 5 of them in/around my desk
2019-05-22 19:33:56 <_ikke_> tcely: I think we need a column to move things in that are waiting for the submitter to fix things
2019-05-22 19:35:42 <tcely> _ikke_: what would you like to call that?
2019-05-22 19:38:33 <north1> can pr7922 get merged ? already missed 1 upstream release
2019-05-22 19:51:22 <tcely> _ikke_: review in progress is where those should be now correct?
2019-05-22 19:51:34 <_ikke_> Yes, mostly
2019-05-22 19:51:55 <_ikke_> But now it's a mix of things we need to look at and others, so no idea how actionable they are
2019-05-22 20:08:29 <north1> Need merge on pr7262 https://github.com/alpinelinux/aports/pull/7262#issuecomment-493174541
2019-05-22 20:16:32 <tcely> _ikke_: that makes sense. What should we call that?
2019-05-22 20:16:52 <SpaceToast> perhaps "changes requested"?
2019-05-22 20:16:56 <SpaceToast> (i.e what github calls it)
2019-05-22 20:18:23 <tcely> Is @mati865 from GH here?
2019-05-22 20:18:27 <north1> submitter-plz-fix
2019-05-22 20:18:34 <tcely> north1: +1 ;-)
2019-05-22 20:22:18 <tcely> There is a "Please change" column now. Have at it. :-)
2019-05-22 20:51:22 <_ikke_> tcely: thanks
2019-05-22 20:52:09 <tcely> _ikke_: welcome
2019-05-22 20:57:29 <_ikke_> Should we move drafts/wip more to the right? I don't think it's the most important thing to look at
2019-05-22 21:09:33 <tcely> If you like. I'm not assigning importance based on ordering.
2019-05-22 21:10:46 <_ikke_> Me neither, but columns to the left are the first once that you see
2019-05-22 21:11:17 <_ikke_> funny, I see you almost live changing these things
2019-05-22 21:11:26 <SpaceToast> _ikke_: kanban boards usually organize things in terms of "phases"
2019-05-22 21:11:35 <_ikke_> SpaceToast: indeed
2019-05-22 21:11:35 <SpaceToast> earliest on the left, "done" on the right
2019-05-22 21:11:37 <_ikke_> from left to right
2019-05-22 21:11:41 <SpaceToast> yeah
2019-05-22 21:11:51 <SpaceToast> I think keeping that makes sense, with maybe some exception conditions outside
2019-05-22 21:12:01 <SpaceToast> (such as "changes requested", since it doesn't fit in cleanly)
2019-05-22 21:12:41 <tcely> How's that look?
2019-05-22 21:13:11 <_ikke_> Better
2019-05-22 21:13:16 <tcely> SpaceToast: I don't see any real purpose to keeping a number line type setup.
2019-05-22 21:13:29 <SpaceToast> well, that's just how things are generally done in boards like this
2019-05-22 21:13:35 <SpaceToast> so people familiar with this workflow will get confused ^^
2019-05-22 21:13:45 <SpaceToast> similar to priorities:
2019-05-22 21:13:48 <tcely> If people want to look at the most important things on the left, let's go with that.
2019-05-22 21:13:52 <SpaceToast> sure, you can set P5 to be the highest, since 5 > 4 etc
2019-05-22 21:14:01 <SpaceToast> but that'll just confuse people that are used to existing priority systems
2019-05-22 21:14:53 <tcely> confusion does seem to be the primary state. Priority 1 or Tier 5. ;-)
2019-05-22 21:15:43 <tcely> I'm going with the theory that the column that the most people should look at first goes to the left so far.
2019-05-22 21:17:16 <tcely> You are right, though. Those looking for a factory line presentation will be confused and it makes managing cards a bit harder.
2019-05-22 21:17:23 <SpaceToast> I think that in a number-line style system, people can figure out it's a "progression" system
2019-05-22 21:17:44 <SpaceToast> (even if one isn't necessarily expecting it)
2019-05-22 21:17:53 <tcely> It turns out that GH mobile pages are actually easier to work with for these boards than the desktop layout.
2019-05-22 21:19:50 <tcely> _ikke_: pr7883 is the only remainging PR you can merge it seems.
2019-05-22 21:19:58 <tcely> We really need more help with the main repo
2019-05-22 21:20:30 <Cogitri> Yup :c
2019-05-22 21:20:38 <_ikke_> tcely: isn't that one already merged?
2019-05-22 21:21:48 <tcely> sorry I typo'd: pr7983
2019-05-22 21:22:03 <_ikke_> looking at that now
2019-05-22 21:29:21 <_ikke_> Anyone got a clue why creduce fails building in x86?
2019-05-22 21:29:24 <_ikke_> "configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. "
2019-05-22 21:30:27 <_ikke_> Relevant part of the log: http://tpaste.us/RgkY
2019-05-22 21:31:13 <mps> what is this './configure: eval: line 1: ./conftest: not found'
2019-05-22 21:31:49 <_ikke_> mps: that can happen when a binary is not supported on the system
2019-05-22 21:31:58 <TBK[m]> pytest maybe? https://docs.pytest.org/en/2.7.3/plugins.html?highlight=re
2019-05-22 21:32:14 <mps> _ikke_: does it fail only on x86
2019-05-22 21:32:45 <_ikke_> Apparently, yes
2019-05-22 21:32:46 <_ikke_> https://cloud.drone.io/alpinelinux/aports/4553/3/1
2019-05-22 21:33:19 <mps> uhm, don't know if my x86 lxc can work
2019-05-22 21:33:28 <mps> but will try now
2019-05-22 21:33:40 <_ikke_> I tried it in a 32 bit docker container, and there I got the same error
2019-05-22 21:34:09 <tcely> Is this only clang or gcc too?
2019-05-22 21:34:21 <_ikke_> No clue
2019-05-22 21:34:46 <_ikke_> let me test
2019-05-22 21:35:30 <mps> it is marked as arch="all !x86"
2019-05-22 21:35:56 <mps> are you trying to enable it again
2019-05-22 21:36:10 <_ikke_> https://github.com/alpinelinux/aports/pull/5640/files
2019-05-22 21:36:14 <_ikke_> Was looking at this PR
2019-05-22 21:36:39 <_ikke_> So someone is at least
2019-05-22 21:36:46 <_ikke_> with gcc it seems to work fine
2019-05-22 21:36:56 <_ikke_> It's compiling now
2019-05-22 21:37:00 <mps> I see
2019-05-22 21:38:00 <tcely> https://github.com/alpinelinux/aports/commit/ee9d35d79b67a14acbb55efcbb44631e1b7e7930#diff-f5516ee066879f7ebaf42293b89870d6
2019-05-22 21:38:22 <danieli> gdi algitbot
2019-05-22 21:38:48 <tcely> Ugly error message from when it was disabled for x86
2019-05-22 21:41:43 <_ikke_> It's taking a long time to build, so I'm waiting for the results
2019-05-22 21:41:49 <_ikke_> (with gcc)
2019-05-22 21:43:59 <mps> uhm, first need to upgrade container
2019-05-22 21:45:52 <TBK[m]> there is a newer version 2.10.0 released 9 days ago
2019-05-22 21:46:23 <mps> tcely: regarding my question about status change for pw.a.o (https://patchwork.alpinelinux.org/patch/4851) and your answer, would it be better to mark it 'Superseded'?
2019-05-22 21:46:49 <tcely> mps: that does seem a better option
2019-05-22 21:48:23 <mps> ok, thanks for help
2019-05-22 21:49:24 <mps> number of patches is below 100 again :)
2019-05-22 21:51:04 <tcely> *hooray*
2019-05-22 21:51:17 <tcely> Anyone else want to review pr7998 ?
2019-05-22 22:18:24 <mps> _ikke_: to confirm your findings - yes, creduce can be built with gcc on x86
2019-05-22 22:20:05 <tcely> mps: that points to clang being broken :-(
2019-05-22 22:21:11 <TBK[m]> or the pkg, did anybody try to build 2.10.0?
2019-05-22 22:21:29 <mps> imo, clang and llvm batteries are really broken
2019-05-22 22:23:00 <mps> TBK[m]: ok, will try 2.10.1
2019-05-22 22:23:20 <mps> sorry, 2.10.0
2019-05-22 22:25:10 <mps> with the current llvm in edge I  cannot build rust
2019-05-22 22:25:36 <mps> for crystal only llvm5 worked
2019-05-22 22:26:41 <mps> I think that the llvm7 (and rest of it's batteries) are really broken
2019-05-22 22:27:18 <mps> TBK[m]: same error for 2.10.0
2019-05-22 22:27:30 <TBK[m]> k
2019-05-22 22:38:43 <north1> Contibutor: <email>
2019-05-22 22:38:44 <north1> is that valid ? ^
2019-05-22 22:42:38 <mps> north1: not sure but some pkg's don't have contributor at all
2019-05-22 22:43:13 <north1> well the name is missing, i'll leave as is
2019-05-22 22:43:22 <north1> m
2019-05-22 22:43:32 <mps> that's also ok
2019-05-22 22:44:10 <mps> I usually don't touch these fields if name/e-mail missing
2019-05-22 22:57:52 <SpaceToast> ping _ikke_ - are you still awake?
2019-05-22 22:57:59 <north1> aports-lint now detects mismatches between pkgname= and the directory the APKBUILD is found
2019-05-22 23:13:53 <north1> huh
2019-05-22 23:14:21 <north1> freeswitch-sounds-pt-BR-karina-8000 is the pkgname= of main/freeswitch-sounds-pt-br-karina-8000
2019-05-22 23:19:57 <north1> so there is a package on main with uppercase BR
2019-05-22 23:56:21 <[[sroracle]]> yeah everything should be lowercase
2019-05-22 23:56:31 <[[sroracle]]> but startdir not matching pkgname is not necessarily a problem
2019-05-22 23:57:51 <north1> It does produce confusion for people that expect the directory of the package be named after the package like 99% of it
2019-05-23 02:11:44 <debrox> greetings
2019-05-23 02:12:51 <north1> hi
2019-05-23 02:13:18 <debrox> Looking at `apk version --check`
2019-05-23 02:13:27 <debrox> it seems slightly broken
2019-05-23 02:13:54 <debrox> If it is supposed to implement the comment: /* Gentoo version: {digit}{.digit}...{letter}{_suf{#}}...{-r#} */
2019-05-23 02:15:05 <debrox> I wish there were an issues tab available on the apk-tools Github repo where I could better post this
2019-05-23 02:15:17 <debrox> But it permits strings like '1....2.............................21212121'
2019-05-23 02:16:06 <debrox> Do you think anyone would care enough to merge in a fix of this?
2019-05-23 02:16:15 <debrox> If i submitted one that is
2019-05-23 08:34:42 <artok> builders are drone.io ?
2019-05-23 08:36:02 <tcely> CI is drone.io & Travis. I think builders are different.
2019-05-23 08:55:13 <_ikke_> yes, the builders are lxc containers that run a script that builds on push to git.a.o
2019-05-23 08:55:25 <artok> okies
2019-05-23 09:35:23 <afkpaul> hello everyone
2019-05-23 09:46:52 <Cogitri> Hello there, afkpaul
2019-05-23 09:47:27 <afkpaul> hi Cogitri, I'm Paul, nice to meet you
2019-05-23 09:47:38 <afkpaul> I work as a sysadmin @ YateBTS
2019-05-23 09:48:13 <afkpaul> I've just installed alpine-extended-3.9.4-x86_64.iso in a VM and getting used to it
2019-05-23 09:48:38 <afkpaul> my goal is to make some Yate .apks for this distro
2019-05-23 09:49:01 <mps> afkpaul: what is yate? url?
2019-05-23 09:49:07 <afkpaul> as I read the documentation I found this channel and I said it's a good ideea to be here, maybe I have some questions in the future
2019-05-23 09:49:16 <afkpaul> yate.ro
2019-05-23 09:49:20 <afkpaul> is a telephony engine
2019-05-23 09:50:32 <mps> aha, I see? how it differs from freeswitch? I remember now that I have looked at it some time ago
2019-05-23 09:51:08 <_ikke_> afkpaul: fyi https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2019-05-23 09:51:19 <_ikke_> But you probably already found that
2019-05-23 09:51:27 <afkpaul> yes I am there
2019-05-23 09:51:50 <mps> is it completely free or some kind full commercial and free variant
2019-05-23 09:51:52 <afkpaul> I am here just to socialize a bit, if I need help in the future
2019-05-23 09:52:15 <Cogitri> Ah, alright
2019-05-23 09:52:25 <afkpaul> for the moment seems I on the right way
2019-05-23 09:52:32 <Cogitri> I can recommend you to join #alpine-linux too for more user oriented questions
2019-05-23 09:53:29 <afkpaul> yes, should I leave from here?
2019-05-23 09:53:47 <mps> looks interesting, it have free SS7 stack
2019-05-23 09:54:53 <afkpaul> regarding yate, we have some public versions and some private ones (the private ones are intend for telecom business)
2019-05-23 09:55:17 <Cogitri> afkpaul: Ah, no, you can stay here - didn't mean to
2019-05-23 09:55:29 <Cogitri> dispel you from here :)
2019-05-23 09:55:43 <_ikke_> afkpaul: no, feel free to hang around :-)
2019-05-23 09:56:07 <Cogitri> This channel is mostly about the development part (problems with packaging something, etc.) though, while #alpine-linux is more about how do I setup X in alpine :)
2019-05-23 09:56:53 <afkpaul> (I have the alpine set up already, I've downloaded yate from svn and I am here) - I will issue questions when I won't find answers
2019-05-23 09:57:24 <mps> afkpaul: yate client also looks interesting. is it written in java or some other lang?
2019-05-23 09:58:00 <kmaxwell> _ikke_: you really made me smile pointing out pr 8000 is such a nice round number :-)
2019-05-23 09:59:45 <kmaxwell> I don't know why round numbers seem significant
2019-05-23 10:01:44 <mps> anyone experience issue rebuilding gimp on edge
2019-05-23 10:01:59 <p4Wv1qn095FW> kmaxwell: a nice round number would be 8192
2019-05-23 10:02:23 <mps> here is one I encounter: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
2019-05-23 10:02:40 <mps> and perl-xml-parser is installed
2019-05-23 10:03:33 <p4Wv1qn095FW> yeah all stuff linking to libperl is borked, like spamassassin or urxvt, seems you run into the same problem
2019-05-23 10:04:27 <mps> p4Wv1qn095FW: also I thought this issue could be related to latest perl upgrade
2019-05-23 10:05:14 <p4Wv1qn095FW> #10459
2019-05-23 10:05:19 <p4Wv1qn095FW> https://github.com/void-linux/void-packages/blob/da7eb611cbc7df8ab379082e0c86e4a871ce0750/srcpkgs/perl/template#L182
2019-05-23 10:05:23 <p4Wv1qn095FW> Requires rebuild of all Perl modules that link to libperl
2019-05-23 10:05:26 <p4Wv1qn095FW> -DNO_POSIX_2008_LOCALE to CFLAGS
2019-05-23 10:05:30 <p4Wv1qn095FW> is the solution
2019-05-23 10:05:38 <mps> yes. it is known here
2019-05-23 10:06:16 <mps> maybe perl should be patched instead
2019-05-23 10:06:19 <p4Wv1qn095FW> yeah
2019-05-23 10:06:31 <p4Wv1qn095FW> it needs to compile with -DNO_POSIX_2008_LOCALE to CFLAGS
2019-05-23 10:07:03 <mps> perl recompile with this flag, you mean?
2019-05-23 10:07:06 <p4Wv1qn095FW> yeah
2019-05-23 10:07:18 <mps> tend to agree with you
2019-05-23 10:07:19 <p4Wv1qn095FW> and then everything that links against libperl
2019-05-23 10:08:11 <mps> yes, sounds like it should be tried this way
2019-05-23 10:09:12 <danieli> unfortunately, yes, that seems to be the only solution
2019-05-23 10:09:19 <danieli> a lot of things are broken because of it at the moment
2019-05-23 10:11:47 <mps> will try build now with this flag on armv7
2019-05-23 10:12:17 <mps> to see if can be built without errors
2019-05-23 10:16:47 <danieli> it can on x86_64
2019-05-23 10:18:36 <mps> danieli: did you posted patch somewhere or I didn't remember our discussion about issue clearly
2019-05-23 10:19:05 <danieli> i don't remember, it's not something i upstreamed for sure
2019-05-23 10:19:55 <danieli> should be fine ripping off void's patch and adapting it
2019-05-23 10:20:05 <mps> I added one line in build function: `CFLAGS="$CFLAGS -DNO_POSIX_2008_LOCALE"`
2019-05-23 10:20:17 <mps> is this enough
2019-05-23 10:21:14 <mps> oh, void patch is like this
2019-05-23 10:21:44 <mps> so, probably will work
2019-05-23 10:26:32 <kmaxwell> could someone take a look at pr7750 please? a simple CLI App, just I disagreed with a few review comments
2019-05-23 10:29:14 <mps> kmaxwell: it depends on `py3-setuptools`, is this ok?
2019-05-23 10:43:51 <kmaxwell_> mps: sorry yes that is deliberate, py3-setuptools is required
2019-05-23 10:44:30 <kmaxwell_> there is a pep that explains that it is just an implementation detail that setuptools is installed by default
2019-05-23 10:44:56 <kmaxwell_> so IMO you need to depend on it if the package is relying on it
2019-05-23 10:46:18 <kmaxwell_> https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools
2019-05-23 10:46:27 <mps> I'm not versed in python, but iirc that is discouraged in packaging, but someone who better know python packaging could give clearer explanation
2019-05-23 10:46:31 <kmaxwell_> the key part for me is "other projects which explicitly require setuptools must still provide an appropriate dependency declaration"
2019-05-23 10:48:15 <mps> and these braces in source field should be documented for AAPKBUILD, i.e. which variant is preferred
2019-05-23 10:48:35 <kmaxwell_> which is preferred?
2019-05-23 10:49:23 <mps> not sure, but most are without braces, and I do always without them
2019-05-23 10:49:56 <kmaxwell_> in case anyone else has a strong opinion the question is about source="${pkgname}-${pkgver}.tar.gz::https://... or source="$pkgname-$pkgver.tar.gz::https://
2019-05-23 10:50:14 <mps> what is POSIX proper?
2019-05-23 10:50:59 <mps> posix shell expert's could help
2019-05-23 10:51:23 <kmaxwell_> POSIX accepts both, the braces help split the variable name from what comes after
2019-05-23 10:51:45 <kmaxwell_> can help avoid problems for example _ is a valid part of an POSIX variable name
2019-05-23 10:52:44 <kmaxwell_> so "$pkgname_$pkgver" is just two variables whereas "${pkgname}-${pkgver}" is variable, then string then variable
2019-05-23 10:53:08 <mps> aha, understand. still I'm far from shell expert so don't have strong opinion about this
2019-05-23 10:53:17 <kmaxwell_> I got caught out by that at one stage and started using more {}s
2019-05-23 10:53:51 <kmaxwell_> mps: thanks for taking a look, I appreciate your input
2019-05-23 10:53:55 <mps> wait, and "$pkgname-$pkgver", is this two vars or one
2019-05-23 10:54:26 <kmaxwell_> because - is not a valid part of a POSIX variable name it is also variable string variable
2019-05-23 10:54:49 <[[sroracle]]> it's preferred to not uses braces unless necessary
2019-05-23 10:54:52 <kmaxwell_> but change that - to a _ and you get a very different meaning
2019-05-23 10:55:15 <kmaxwell_> [[sroracle]]: is that something in the documentation?
2019-05-23 10:55:24 <tcely> mps: exactly why I prefer always quote and always brace
2019-05-23 10:55:39 <[[sroracle]]> it's probably not documented anywhere. but that is what the majority of APKBUILDs do
2019-05-23 10:55:46 <[[sroracle]]> same with using tabs instead of spaces for indentation
2019-05-23 10:56:31 <kmaxwell_> [[sroracle]]: I disagree tabs instead of spaces is clearly documented
2019-05-23 10:56:37 <[[sroracle]]> ok
2019-05-23 10:57:01 <kmaxwell_> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Code_review
2019-05-23 10:58:15 <mps> at the end using braces or not should be documented, also
2019-05-23 10:58:53 <mps> I always have dillema what to do, although do not using them mostly
2019-05-23 10:59:24 <kmaxwell_> so seems like tcely and I prefer braces, sroracle, mps and TBK (on GitHub) prefer none
2019-05-23 10:59:43 <kmaxwell_> adding to the wiki is easy, just need to know what to add :-)
2019-05-23 10:59:52 <[[sroracle]]> % find . -name APKBUILD -exec grep --color -F '${pkgname}' {} + | wc -l
2019-05-23 10:59:55 <[[sroracle]]> 594
2019-05-23 11:00:04 <[[sroracle]]> % find . -name APKBUILD -exec grep --color -F '$pkgname' {} + | wc -l
2019-05-23 11:00:07 <[[sroracle]]> 14558
2019-05-23 11:00:17 <[[sroracle]]> a rough estimate
2019-05-23 11:00:21 <tcely> that's a lemmings argument ;-)
2019-05-23 11:00:35 <[[sroracle]]> well it's better to document existing policy then argue if you want to change it
2019-05-23 11:00:54 <tcely> better only if you want the old way
2019-05-23 11:01:02 <[[sroracle]]> ok
2019-05-23 11:01:05 <tcely> We document the new way usually
2019-05-23 11:01:24 <[[sroracle]]> who is "we"?
2019-05-23 11:01:33 <tcely> People writing docs
2019-05-23 11:01:48 <[[sroracle]]> and people writing docs make policy decisions for the whole project?
2019-05-23 11:01:57 <mps> tcely: document current practice is also worth
2019-05-23 11:02:27 <tcely> Sure, but documenting obsolete practice is less worthy
2019-05-23 11:02:45 <[[sroracle]]> it's not obsolete... nothing has been changed...
2019-05-23 11:02:47 <mps> don't agree with this
2019-05-23 11:03:15 <tcely> in a post decision document you want to list all the previous ways it was done?
2019-05-23 11:03:32 <kmaxwell_> sorry didn't mean to start a debate, just want the PR merged :-)
2019-05-23 11:03:33 <mps> [[sroracle]]: meant to say 'don't agree with tcely stance, not your'
2019-05-23 11:04:20 <[[sroracle]]> tcely: if you would like to change this style guideline of braces or no braces bring it to the core team. i do not think you have the authority to be changing it yourself.
2019-05-23 11:05:00 <tcely> I think it's unreasonable to expect everyone who contributes to be an expert on shell syntax. For beginners the best advice is always quote and always brace since they will run into much less unexpected behavior that way. When they learn more they will then know when quoting or bracing can be skipped.
2019-05-23 11:05:11 <[[sroracle]]> sure
2019-05-23 11:05:15 <tcely> [[sroracle]]: I never said I did.
2019-05-23 11:05:19 <[[sroracle]]> and in fact i think braces would be a better style
2019-05-23 11:05:32 <[[sroracle]]> but it's not what is currently being done
2019-05-23 11:05:43 <tcely> that's an untrue statement
2019-05-23 11:05:51 <tcely> it's currently being done both ways
2019-05-23 11:05:56 <[[sroracle]]> ok, nitpicky
2019-05-23 11:06:45 <kmaxwell_> IMO the de facto policy atm is "both is fine"
2019-05-23 11:06:45 <tcely> also, what has been done is not particularly convincing evidence for what should be done in the future
2019-05-23 11:07:08 <tcely> kmaxwell_: I believe it's been left up to the maintainer (so per APKBUILD) at this point
2019-05-23 11:07:12 <Cogitri> Sure
2019-05-23 11:07:21 <Cogitri> Yup, it's up to the maintainer
2019-05-23 11:08:07 <Cogitri> Although I'd personally suggest a treewide change for that, it's a bit awkward when the first reviewer tells you to do X and the second one tells you to do Y then
2019-05-23 11:08:39 <tcely> Cogitri: Yep. Having more of the "in brain" policy written down and agreed upon would be better.
2019-05-23 11:09:00 <kmaxwell_> happy that its down to the maintainer because pr 7750 is a new aport and once I get it merged that'll be me :-)
2019-05-23 11:10:06 <tcely> kmaxwell_: absolutely! your new aport, your call (for now).
2019-05-23 11:10:45 <tcely> I am about to give up on checks for kea. This is such a mess.
2019-05-23 11:10:56 <tcely> https://cloud.drone.io/alpinelinux/aports/4633/2/1
2019-05-23 11:11:03 <tcely> Any thoughts on the latest failure?
2019-05-23 11:11:58 <kmaxwell_> sometimes the checks are the hardest part, I'm having a look
2019-05-23 11:13:39 <kmaxwell_> some checks are failing because dhcp4_srv isn't set, and the error messages are polluting test output
2019-05-23 11:14:58 <tcely> Ugh. Stupid Makefile rules are stupid!
2019-05-23 11:16:30 <tcely> http://tpaste.us/Lz7K
2019-05-23 11:17:02 <tcely> So, I go through the trouble of patching the shbang and it uses $(SHELL) to call the test script.
2019-05-23 11:18:10 <tcely> One less patch hunk to worry about then.
2019-05-23 11:22:12 <tcely> isc has never heard of portability or checkbashisms
2019-05-23 11:27:53 <tcely> 
ACTION crosses fingers that check passes

2019-05-23 11:28:52 <tcely> People don't need DHCP in IPv6 land anyway, right? ;-P
2019-05-23 11:36:58 <tcely> Yay! On to the install function. https://cloud.drone.io/alpinelinux/aports/4635/2/1
2019-05-23 11:37:17 <tcely> woohoo! build done.
2019-05-23 11:54:18 <Cogitri> Nice :)
2019-05-23 12:40:23 <PureTryOut[m]> mps: shall I just add the arm-trusted-firmware stuff to my PR, or will you add your changes yourself (if that is even possible on Github)?
2019-05-23 12:42:03 <tcely> PureTryOut[m]: You can branch from their branch and open a PR in their fork.
2019-05-23 12:42:32 <PureTryOut[m]> Well, he has to do it to my branch then, but sure
2019-05-23 12:42:40 <tcely> Some of the review features make that nicer though. Suggested code changes is a pretty nice feature.
2019-05-23 12:43:04 <mps> PureTryOut[m]: I would prefer to talk with u-boot maintainer first to discuss how to 'integrate' arm-trusted-firmware in alpine
2019-05-23 12:45:35 <PureTryOut[m]> We could point them to the PR though right?
2019-05-23 12:46:28 <mps> new u-boot have support for some boards for which some people asked me to help building it
2019-05-23 12:46:58 <mps> yes, ofc, we could
2019-05-23 12:47:21 <mps> did I posted u-boot change I made to you?
2019-05-23 12:48:18 <mps> rnalrd2: are you here
2019-05-23 12:48:55 <mps> u-boot could be upgraded to 2019.4 I think
2019-05-23 12:50:08 <mps> PureTryOut[m]: let's wait some time for rnalrd2, maybe he will have some ideas of integrating arm-trusted-firmware
2019-05-23 12:50:37 <PureTryOut[m]> I don't think you posted the changed u-boot no
2019-05-23 12:50:55 <mps> ok, will now, just minute
2019-05-23 12:51:25 <PureTryOut[m]> Also the latest version of your arm-trusted-firmware please
2019-05-23 12:52:01 <mps> uhm. last upgrade for u-boot was from me
2019-05-23 12:53:11 <mps> I didn't changed anything for arm-trusted-firmware after I sent it to you
2019-05-23 12:54:25 <PureTryOut[m]> Oh I thought you made subpackages and stuff
2019-05-23 12:55:32 <mps> yes, in arm-trusted-firmware APKBUILD there is subpackage for sun50i
2019-05-23 12:55:50 <mps> and u-boot APKBUILD is http://tpaste.us/Zg9l
2019-05-23 12:56:23 <mps> it is for u-boot 2019.1
2019-05-23 12:57:46 <mps> I named this board/device subpackage `pine64:pine64-lts`, I think this is from your patch
2019-05-23 12:59:12 <mps> in meantime I looked at arch linux alarm (Arch Linux Arm) how they packaged all this things
2019-05-23 12:59:47 <mps> maybe we could take some ideas from their work
2019-05-23 13:07:44 <mps> PureTryOut[m]: http://tpaste.us/dk9L  is the APKBUILD for 2019.4
2019-05-23 13:21:21 <PureTryOut[m]> Yeah that APKBUILD seems good
2019-05-23 14:16:48 <otlabs> hi ppl
2019-05-23 14:17:05 <SpaceToast> hey otlabs
2019-05-23 14:17:18 <otlabs> SpaceToast: greetings!
2019-05-23 14:17:23 <SpaceToast> :)
2019-05-23 14:17:30 <otlabs> :)
2019-05-23 14:20:31 <kmaxwell> is a package name using mixed case, like runVimTests OK?
2019-05-23 14:20:51 <SpaceToast> all lowercase is generally preferred
2019-05-23 14:21:04 <north1> Policy on wiki states all lowercase
2019-05-23 14:21:10 <SpaceToast> also, runVimTests sounds like a... very strange package name
2019-05-23 14:21:21 <_ikke_> north1: does apkbuild-lint verify that?
2019-05-23 14:21:36 <north1> _ikke_: there is a PR I tagged you
2019-05-23 14:21:42 <_ikke_> ok
2019-05-23 14:21:45 <north1> Should be PR number 8
2019-05-23 14:21:47 <SpaceToast> morning _ikke_ :)
2019-05-23 14:22:09 <north1> I got into it last night while I was checking the wiki for inconscistencies
2019-05-23 14:22:39 <SpaceToast> north1: if you could make a general list with links, that'd be quite useful for docs.a.o/developer-handbook
2019-05-23 14:22:54 <SpaceToast> once I figure out what to do with the reorg artifacts
2019-05-23 14:23:37 <north1> General list of?
2019-05-23 14:23:45 <SpaceToast> various policies found on the wiki
2019-05-23 14:23:56 <SpaceToast> not all of those are necessarily official, but would be a good starting point
2019-05-23 14:23:57 <north1> There is a page for them
2019-05-23 14:24:24 <_ikke_> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2019-05-23 14:24:38 <SpaceToast> APKBUILD_Reference isn't complete, at this point :/
2019-05-23 14:24:42 <SpaceToast> gonna be fixing that (in docs.a.o, though)
2019-05-23 14:27:24 <kmaxwell> north1: you're absolutely right, I missed it
2019-05-23 14:27:25 <kmaxwell> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#pkgname
2019-05-23 14:27:54 <kmaxwell> also `man APKBUILD` now I think of it
2019-05-23 14:29:35 <kmaxwell> this is the framework: https://github.com/inkarkat/runVimTests
2019-05-23 14:29:49 <kmaxwell> any suggestions on lowercasing run-vim-tests or runvimtests?
2019-05-23 14:33:16 <otlabs> i am building a package which requires pytest-timeout. i have prepared the package for latter (pr8021), but it fails some tests and i am unable to interpret error messages well. same time the main package uses pytest-timeout without any problem, so i pretend to assume these errors are not (so) critical. i would quite appreciate your opinions on subject.
2019-05-23 14:36:07 <kmaxwell> otlabs: do the tests fail if you build locally? or just on CI?
2019-05-23 14:36:25 <otlabs> kmaxwell: i build in VM and get same errors
2019-05-23 14:38:59 <kmaxwell> a lot of the failures seem to state 'OS does not have SIGALRM'
2019-05-23 14:39:16 <otlabs> yes, and I do not understand that
2019-05-23 14:40:22 <kmaxwell> I really have a dislike of bitbucket, I was going to try and look if upstream have CI running
2019-05-23 14:40:39 <kmaxwell> it is possible to disable individual tests with --deselect
2019-05-23 14:40:41 <north1> SpaceToast: can you private message the request for compiling the alpine wiki policies to me?
2019-05-23 14:41:26 <otlabs> kmaxwell: cool, i will disable those tests, thanks
2019-05-23 14:41:32 <SpaceToast> done
2019-05-23 14:42:46 <kmaxwell> otlabs: I personally don't have any better ideas, upstream CI seems to run fine https://bitbucket.org/pytest-dev/pytest-timeout/addon/pipelines/home
2019-05-23 14:44:21 <otlabs> I will report upstream also
2019-05-23 14:44:32 <kmaxwell> was just about to say that :-)
2019-05-23 14:45:16 <kmaxwell> they dont' run on Python 3.7 in their CI so maybe they haven't tested yet https://bitbucket.org/pytest-dev/pytest-timeout/src/default/tox.ini#lines-6
2019-05-23 14:46:16 <otlabs> yes, i noticed that also, will underscore in my report, thank you
2019-05-23 14:51:04 <otlabs> Reported upstream https://bitbucket.org/pytest-dev/pytest-timeout/issues/37/
2019-05-23 14:51:31 <mps> otlabs: hi, did you looked at new u-boot, it have some nanopi boards added, although not sure if your board added
2019-05-23 14:52:09 <otlabs> mps: oh, great! will check later today! great news!
2019-05-23 14:52:55 <north1> Just to confirm
2019-05-23 14:53:17 <north1> -rN is not allowed in pkgver because it conflicts with pkgrel?
2019-05-23 14:53:50 <mps> north1: even '_rN' is not allowed
2019-05-23 14:54:03 <north1> Oh dear
2019-05-23 14:54:11 <north1> I'll have to update apklint to deal with that
2019-05-23 14:54:37 <north1> Only at the end or at any point of the pkgver definition?
2019-05-23 14:56:30 <otlabs> mps: do you refer to pr7899? u-boot 2019.4?
2019-05-23 14:58:10 <mps> otlabs: no, I mean upstream master
2019-05-23 14:58:24 <otlabs> oh, ok, let me checki it
2019-05-23 14:58:36 <otlabs> I already for sources compiling
2019-05-23 14:58:58 <otlabs> and I need to confirm the offset where to write u-boot
2019-05-23 14:59:10 <otlabs> and run some final tests
2019-05-23 14:59:10 <kmaxwell> north1: man APKBUILD has a pretty detailed spec for a valid version number
2019-05-23 14:59:21 <kmaxwell> easier to read in a pager, but https://github.com/alpinelinux/abuild/blob/master/APKBUILD.5#L50 is alink
2019-05-23 15:00:56 <mps> btw, anyone have experience with arm-trusted-firmware
2019-05-23 15:12:29 <otlabs> mps: found the commit in u-boot which corresponds to nanopi board, but it is not for my architecture
2019-05-23 15:13:00 <otlabs> so I still a chance to finish mine :)
2019-05-23 15:13:15 <otlabs> s/ a/ have a/
2019-05-23 15:13:15 <alpine-meetbot> otlabs meant to say: so I still have a chance to finish mine :)
2019-05-23 15:13:32 <mps> well, life with FOSS ;)
2019-05-23 15:55:47 <Cogitri> Could someone with an armv7 builder test out libplist from pr7597? My Qemu image (thanks mps!) isn't so functional right now :c
2019-05-23 16:24:10 <mps> Cogitri: will try in 10-20 minutes
2019-05-23 16:24:50 <Cogitri> Thank you! :)
2019-05-23 16:25:28 <mps> np, you are welcome
2019-05-23 16:26:08 <_ikke_> Wow, has been a quiet day today, no commits in aports
2019-05-23 16:27:59 <mps> _ikke_: I'm preparing some, but not sure will be finished
2019-05-23 16:28:05 <_ikke_> SpaceToast: btw, you pinged me last night (my time), still something I can help with?
2019-05-23 16:28:16 <SpaceToast> oh, yes, can I PM?
2019-05-23 16:28:25 <_ikke_> k
2019-05-23 16:32:44 <mps> Cogitri: community/libplist failed test, TOTAL: 29 PASS:  16 FAIL:  13
2019-05-23 16:33:41 <mps> can I help somewhat more
2019-05-23 16:35:22 <mps> and PR have more commits, do some of these need to be built before libplist
2019-05-23 17:27:43 <SpaceToast> otlabs: you're Oleg Titov, right?
2019-05-23 17:30:19 <_ikke_> I wonder, should we set $HOME to some temp dir during abuild run? A lot of packages put stuff in $HOME
2019-05-23 17:48:04 <ollieparanoid[m]> maxice8: that linting tool sounds like a very useful project. can somebody link me to the source?
2019-05-23 17:48:27 <north1> maxice8/atools on github
2019-05-23 17:48:37 <ollieparanoid[m]> thx
2019-05-23 17:54:27 <_ikke_> How hard must it be to just print the content of some variable on the console in rust :-/
2019-05-23 17:54:31 <artok> oh boy... I created docker image for abuild (yeah docker-abuild like) and tried to build stuff.. until I found out that as my macOS HD is not case sensitive, docker bind mounting will not work
2019-05-23 17:54:46 <_ikke_> It either returns an error, or keeps hanging forever during build
2019-05-23 17:59:14 <_ikke_> finally managed
2019-05-23 18:00:42 <danieli> hahahaha
2019-05-23 18:00:59 <ollieparanoid[m]> maxice8: this has some great tests! so right now it is in alpha state, and the idea is to add it to alpine's aports some time soon?
2019-05-23 18:05:12 <north1> It is available on aports
2019-05-23 18:05:19 <north1> Under testing/
2019-05-23 18:05:50 <north1> Most tests were written by @_ikke_ as well as the redo build system
2019-05-23 18:07:05 <SpaceToast> isn't redo djb?
2019-05-23 18:07:20 <ollieparanoid[m]> got a link to the redo build system too? :)
2019-05-23 18:07:36 <north1> There are lots of redo implementations
2019-05-23 18:08:37 <ollieparanoid[m]> okay, now I read up about what that is
2019-05-23 18:09:00 <SpaceToast> https://cr.yp.to/redo.html
2019-05-23 18:09:21 <ollieparanoid[m]> yeah, what I meant with adding it to alpine's aports: add it to the CI scripts, so all APKBUILDs have to pass it. is that planned?
2019-05-23 18:10:16 <north1> I plan on that
2019-05-23 18:10:17 <north1> But usage of PCRE means it needs GNU grep
2019-05-23 18:10:20 <north1> Needs to fix that before it gets included
2019-05-23 18:10:31 <ollieparanoid[m]> I see
2019-05-23 18:10:39 <north1> There is an open issue about that
2019-05-23 18:11:52 <ollieparanoid[m]> yep, saw that :) -- we'll probably add this at some point to postmarketOS' aports' CI, it will probably give a nice quality improvement and save some reviewing work
2019-05-23 18:13:01 <north1> Nice
2019-05-23 18:18:19 <Cogitri> mps: Alright, same failure as on CI, kind sending me the log?
2019-05-23 18:19:05 <otlabs> SpaceToast: yep
2019-05-23 18:19:29 <SpaceToast> otlabs: noticed you're the maintainer of k3s, but the openrc stuff is... weird
2019-05-23 18:19:36 <SpaceToast> also it doesn't seem like it'll work very well for agents
2019-05-23 18:19:47 <SpaceToast> any interest in getting that improved sometime? :)
2019-05-23 18:19:59 <SpaceToast> (note: I know quite a bit of openrc, but have 0 experience with k8s and similar tech)
2019-05-23 18:20:01 <otlabs> a lot of interest
2019-05-23 18:20:03 <SpaceToast> (only docker/lxd)
2019-05-23 18:20:16 <SpaceToast> alright, I'll write it down and poke you at some point to try and work it out, okay? :)
2019-05-23 18:20:27 <otlabs> I want it very much for arm architectures
2019-05-23 18:20:41 <otlabs> sure, thank you!
2019-05-23 18:27:43 <Cogitri> Hooray, ZFS 0.8 is out!
2019-05-23 18:28:24 <Cogitri> clandmeter: Since you're added as Contributor: Should we make a zfs08 package for the time being?
2019-05-23 18:34:07 <_ikke_> I use this redo implementation: https://github.com/apenwarr/redo
2019-05-23 18:34:18 <_ikke_> djb never implemented something
2019-05-23 18:51:25 <mps> Cogitri: here is the 'abuild -r' log http://tpaste.us/Erg6
2019-05-23 18:52:18 <Cogitri> Ah yes, I have that from CI too. Could you send me the test-suite.log?
2019-05-23 18:55:16 <mps> 'abuild -r' removes them, let me to rebuild it without '-r'
2019-05-23 18:57:03 <mps> Cogitri: here it is http://tpaste.us/0LrN
2019-05-23 18:57:59 <Cogitri> Thank you :)
2019-05-23 18:59:20 <mps> np
2019-05-23 19:00:34 <TBK[m]> any ideas on "undefined reference to `jump_fcontext'"? - https://build.alpinelinux.org/buildlogs/build-3-10-s390x/community/pdns-recursor/pdns-recursor-4.1.13-r0.log
2019-05-23 19:07:07 <danieli> did the boost version change?
2019-05-23 19:07:09 <danieli> @ TBK[m]
2019-05-23 19:08:35 <danieli> also, you should verify that it is indeed linking against boost's context library
2019-05-23 19:21:05 <clandmeter> zfs 0.8 nice
2019-05-23 19:21:34 <_ikke_> rust takes ages to build..
2019-05-23 19:23:01 <Cogitri> Currently building 1.33
2019-05-23 19:23:15 <_ikke_> ah, I'm building 1.32
2019-05-23 19:23:24 <_ikke_> I #[ignore]
2019-05-23 19:23:29 <_ikke_> I #[ignore]'d those tests
2019-05-23 19:23:45 <Cogitri> clandmeter: Yes. Once my GNOME stuff is (eventually) merged I'll setup a new Alpine install with VDE to test that and GNOME in a clean install
2019-05-23 19:24:24 <Cogitri> ikke: Ah. Will open the Rust 1.33 PR in a bit, can you merge 1.32 then?
2019-05-23 19:24:32 <_ikke_> That is my intention
2019-05-23 19:24:41 <_ikke_> Just verifying that this works
2019-05-23 19:24:46 <Cogitri> Great :)
2019-05-23 19:25:27 <Cogitri> Well, it certainly works for compiling Rust 1.33
2019-05-23 19:25:58 <mps> _ikke_: x86_64 only?
2019-05-23 19:26:35 <_ikke_> mps: yes
2019-05-23 19:26:40 <_ikke_> It's just an upgrade
2019-05-23 19:27:09 <mps> and which llvm version you use
2019-05-23 19:27:19 <_ikke_> I saw references to llvm7
2019-05-23 19:27:30 <_ikke_> (I'm just testing a PR)
2019-05-23 19:27:33 <_ikke_> https://github.com/alpinelinux/aports/pull/6071/files
2019-05-23 19:27:55 <mps> does it builds with llvm7
2019-05-23 19:28:00 <_ikke_> _llvmver=7
2019-05-23 19:28:02 <_ikke_> yes
2019-05-23 19:28:04 <_ikke_> it does
2019-05-23 19:28:11 <_ikke_> Just some cargo tests failed
2019-05-23 19:28:59 <mps> ok, let's see end result, i.e. will it work
2019-05-23 19:29:13 <_ikke_> mps: well, the idea is to eventually upgrade to 1.34
2019-05-23 19:29:20 <_ikke_> but we need 1.32 and 1.33 before that
2019-05-23 19:29:20 <Cogitri> llvm7 works for everything that uses optlevel < 3
2019-05-23 19:29:30 <_ikke_> optlevel?
2019-05-23 19:29:40 <Cogitri> And rustc sets optlevel=2
2019-05-23 19:29:41 <Cogitri> So it's fine
2019-05-23 19:29:44 <awilfox> is there a way to specify an "OR" for install_if?  i.e. install_if openjdk7 OR openjdk8
2019-05-23 19:29:46 <Cogitri> We can't build anything which sets optlevel=3  with it though
2019-05-23 19:29:58 <Cogitri> _Ikke_: Rust's -O3
2019-05-23 19:30:08 <_ikke_> ah ok
2019-05-23 19:30:13 <_ikke_> optimization
2019-05-23 19:30:18 <Cogitri> So yeah, having LLVM8 merged very soon would be super nice
2019-05-23 19:30:31 <mps> looks like we will not have llvm8 in 3.10 release
2019-05-23 19:30:31 <Cogitri> Then I'd work on LLVM8 w/ Rust 1.34 once 1.33 is merged
2019-05-23 19:30:42 <Cogitri> :c
2019-05-23 19:31:23 <_ikke_> awilfox: Don't think so, not sure though
2019-05-23 19:31:40 <mps> I cannot build rust with llvm7 on aarch64 and armv7
2019-05-23 19:31:57 <Cogitri> Well, we can't stay on LLVM5/6 either
2019-05-23 19:32:12 <Cogitri> So the way forward is having LLVM8 merged which fixes all of this
2019-05-23 19:32:16 <awilfox> mps: http://git.musl-libc.org/cgit/musl/commit/?id=6104dae9088da7ffd9346671be867a43a4b03295 + http://git.musl-libc.org/cgit/musl/commit/?id=a60b9e06861e56c0810bae0249b421e1758d281a
2019-05-23 19:32:26 <awilfox> _ikke_: I didn't think so either.  thanks.
2019-05-23 19:32:33 <mps> only with llvm6, but one which I made and not with the current in edge
2019-05-23 19:33:21 <Cogitri> Well, llvm6 doesn't work for i686, soooo
2019-05-23 19:33:45 <Cogitri> IMHO let's get LLVM8 merged and then start worrying about targets other an x86_64
2019-05-23 19:35:56 <_ikke_> Weeje
2019-05-23 19:36:04 <_ikke_> build succeed
2019-05-23 19:36:07 <_ikke_> ed
2019-05-23 19:37:19 <Cogitri> Nice
2019-05-23 19:37:26 <Cogitri> Argh, it's a bit annoying how many downstream patches we have for Rust
2019-05-23 19:37:56 <mps> Cogitri: llvm8 can be built, tried your PR but again cannot build rust with it
2019-05-23 19:38:23 <_ikke_> pushed
2019-05-23 19:38:33 <Cogitri> Thanks, Ikke
2019-05-23 19:38:48 <Cogitri> mps: Yes, you need Rust >=1.34 for LLVM8 compatibility
2019-05-23 19:40:36 <mps> <rant> uhhm, what a mess is rust</rant>
2019-05-23 19:50:31 <_ikke_> clandmeter: do you know what's going on with the s390x and ppc64le builders? They seem to be in a loop trying to build packages
2019-05-23 19:51:11 <north1> Who wanted stable output for atools ? to use in integration with ALE
2019-05-23 19:51:18 <_ikke_> afaik kmaxwel
2019-05-23 19:53:59 <clandmeter> _ikke_: 3.10?
2019-05-23 19:55:15 <_ikke_> yes
2019-05-23 19:57:02 <clandmeter> did they build world?
2019-05-23 19:57:19 <clandmeter> completely i mean
2019-05-23 19:58:00 <_ikke_> yes
2019-05-23 19:58:05 <_ikke_> afaik
2019-05-23 19:58:14 <clandmeter> i restarted mqtt-exec
2019-05-23 19:58:18 <clandmeter> did that help?
2019-05-23 19:58:54 <_ikke_> build.a.o is at least not jumping all the time :-)
2019-05-23 19:59:04 <_ikke_> So I would say, yes
2019-05-23 19:59:43 <_ikke_> I think only armv7 and x86 are left that did not build world completely yet
2019-05-23 20:12:51 <otlabs> north1: tests fail if I modify PYTHONPATH
2019-05-23 20:18:08 <north1> there should be a build/python3.7 or build/lib that can be pointed
2019-05-23 20:18:33 <north1> i used it extensively on Void Linux's xbps-src and used it a little on Alpine's abuild
2019-05-23 20:19:21 <north1> can we get libgudev merged #7262 ?
2019-05-23 20:19:27 <north1> pr7262
2019-05-23 20:22:50 <otlabs> north1: I have tried both and tests begun failing ugly
2019-05-23 20:24:51 <north1> those are examples, you have to find the exact directory
2019-05-23 20:25:02 <otlabs> I did
2019-05-23 20:25:26 <otlabs> they are $PWD/build and $PWD/build/lib
2019-05-23 20:26:45 <otlabs> The last one produces following - https://cloud.drone.io/alpinelinux/aports/4663
2019-05-23 20:54:11 <_ikke_> north1: lol @ last release of atools
2019-05-23 21:58:56 <otlabs> time to go, bye
2019-05-23 23:16:59 <SpaceToast> TBK[m]: any chance at also merging pr7907?
2019-05-23 23:24:54 <TBK[m]> SpaceToast: yup, coming right up
2019-05-23 23:25:01 <SpaceToast> TBK[m]: thank you :)
2019-05-23 23:36:12 <TBK[m]> SpaceToast: any clue why x86 fails? - https://build.alpinelinux.org/buildlogs/build-edge-x86/community/caddy/caddy-1.0.0-r0.log https://github.com/mholt/caddy/blob/master/caddy/caddymain/run_test.go#L24
2019-05-23 23:36:43 <SpaceToast> TBK[m]: is that builder a container?
2019-05-23 23:37:14 <TBK[m]> not sure
2019-05-23 23:37:26 <mps> SpaceToast: builders are lxc containers, afaik
2019-05-23 23:37:33 <SpaceToast> basically this is the kind of failure you generally get when lxcfs isn't running/available
2019-05-23 23:37:40 <SpaceToast> within lxc-style container
2019-05-23 23:37:49 <jwh> heh
2019-05-23 23:37:56 <SpaceToast> all tests reliably pass on real hardware, and in properly managed containers :(
2019-05-23 23:37:58 <mps> I can try on my local
2019-05-23 23:38:02 <jwh> similar errors in cockroach (even on "supported" systems)
2019-05-23 23:38:05 <SpaceToast> mps: feel free, it'll pass just fine :)
2019-05-23 23:38:33 <SpaceToast> TBK[m]: you can disable tests; if you do, please do comment something like "fails on builders due to containerization edge-cases"
2019-05-23 23:38:36 <jwh> but those guys can't write working tests so it's hardly surprising
2019-05-23 23:38:48 <SpaceToast> it's a shame that the environment forces that though :(
2019-05-23 23:39:16 <jwh> oh I discovered a new hilarity as well
2019-05-23 23:39:18 <TBK[m]> Is there an easy way to just disable that test on x86?
2019-05-23 23:39:45 <SpaceToast> not that I know of
2019-05-23 23:39:51 <SpaceToast> also it isn't architecture-dependent
2019-05-23 23:39:59 <SpaceToast> it'll fail on all hosts that are badly configured containers
2019-05-23 23:40:16 <jwh> only docker test :DD
2019-05-23 23:40:19 <jwh> tested8
2019-05-23 23:40:49 <clandmeter> SpaceToast: can you add an issue regrading "badly configured lxc setup"?
2019-05-23 23:40:54 <SpaceToast> my builder is lxd + lxcfs + me managing cgroups by hand because openrc defaults are dumb and I can't be bothered to fight williamh over it
2019-05-23 23:41:00 <SpaceToast> clandmeter: bugs.a.o?
2019-05-23 23:41:05 <clandmeter> si
2019-05-23 23:41:14 <SpaceToast> sure, give me a moment
2019-05-23 23:41:28 <SpaceToast> I obviously don't know the exact details on what you guys have set up, but I can guarantee that you can make this work just fine
2019-05-23 23:42:48 <mps> these go pkg's like to download a lot of things during build
2019-05-23 23:42:57 <SpaceToast> yes, they do :(
2019-05-23 23:43:34 <jwh> booo go, and such
2019-05-23 23:44:02 <mps> run_test.go:56: Test 3: GOMAXPROCS was 8 but expected 1457030025
2019-05-23 23:44:42 <SpaceToast> is your builder a container?
2019-05-23 23:44:51 <mps> yes, lxc
2019-05-23 23:44:53 <SpaceToast> do you have lxcfs running?
2019-05-23 23:45:01 <mps> no, no lxcfs
2019-05-23 23:45:05 <SpaceToast> start lxcfs
2019-05-23 23:45:08 <SpaceToast> and try again :)
2019-05-23 23:45:17 <SpaceToast> you may need to modify the service script
2019-05-23 23:46:28 <mps> obviously
2019-05-23 23:46:50 <SpaceToast> clandmeter: ^ looks good?
2019-05-23 23:47:00 <SpaceToast> I suspect this specific one is lxcfs specifically
2019-05-23 23:47:07 <SpaceToast> but other cgroup-related failures could also happen
2019-05-23 23:47:11 <jwh> hm I wonder if thats also causing some of my issues
2019-05-23 23:47:15 <jwh> I don't think I have lxcfs enabled either
2019-05-23 23:47:58 <mps> interesting, didn't know for this
2019-05-23 23:48:08 <clandmeter> that log is not matching your error
2019-05-23 23:49:19 <SpaceToast> hmm, the log changed
2019-05-23 23:49:36 <SpaceToast> wait a second
2019-05-23 23:49:42 <SpaceToast> clandmeter: looks like abuild is outdated on that builder as well
2019-05-23 23:49:52 <SpaceToast> it's not honoring default_cleanup_srcdir
2019-05-23 23:50:39 <clandmeter> using abuild 3.4.0_rc4-r0
2019-05-23 23:50:56 <clandmeter> looks like the latest version
2019-05-23 23:51:07 <SpaceToast> hmm, still clearly not honoring the function though
2019-05-23 23:52:01 <SpaceToast> that's exactly what happens when you try to "rm -rf" go sources
2019-05-23 23:52:07 <SpaceToast> that's why `go clean -modcache` is in there
2019-05-23 23:53:54 <mps> just managed to make mess with x86 lxc container.
2019-05-23 23:58:29 <TBK[m]> clandmeter: what is the soultion to fix build-edge-x86 in it current state?
2019-05-23 23:58:37 <SpaceToast> ugh, abuild -qr isn't actually quiet :(
2019-05-23 23:59:24 <clandmeter> Tbk disable the test for now with ref to issue
2019-05-23 23:59:41 <TBK[m]> already done
2019-05-23 23:59:52 <SpaceToast> yeah, now it's the second problem
2019-05-24 00:00:00 <SpaceToast> (abuild not respecting cleanup_srcdir)
2019-05-24 00:00:07 <clandmeter> I'm sleeping now
2019-05-24 00:00:11 <TBK[m]> which resulted in the src mess
2019-05-24 00:00:32 <clandmeter> Add a new issue
2019-05-24 00:00:32 <TBK[m]> k, will also head to bed. sleep well
2019-05-24 00:00:33 <SpaceToast> TBK[m]: in the interim, you can run `rm -rf $srcdir` by hand on the builder - as root
2019-05-24 00:00:39 <SpaceToast> I'll write the new bug
2019-05-24 00:00:47 <clandmeter> Or ping tomorrow
2019-05-24 00:00:52 <TBK[m]> k
2019-05-24 00:01:06 <SpaceToast> did the other builders handle it ok?
2019-05-24 00:01:17 <TBK[m]> SpaceToast: appreciated
2019-05-24 00:01:19 <TBK[m]> yes
2019-05-24 00:01:24 <SpaceToast> ugh :)
2019-05-24 00:01:31 <jwh> hm
2019-05-24 00:01:35 <jwh> what are the chances
2019-05-24 00:01:39 <jwh> both drone and travis-ci are broken
2019-05-24 00:01:44 <SpaceToast> jwh: very low
2019-05-24 00:01:49 <jwh> https://cloud.drone.io/alpinelinux/aports/4796/4/1
2019-05-24 00:01:50 <jwh> stalled
2019-05-24 00:01:56 <jwh> travis stalled too
2019-05-24 00:02:01 <SpaceToast> oh my
2019-05-24 00:02:01 <TBK[m]> x86 is giving me a headache
2019-05-24 00:02:04 <jwh> both queued
2019-05-24 00:02:16 <SpaceToast> if I can help in any way, do ping :)
2019-05-24 00:02:26 <TBK[m]> other stuff is properly building atm
2019-05-24 00:02:34 <SpaceToast> (though don't necessarily expect a response until morning if it's night for me)
2019-05-24 00:03:16 <jwh> SpaceToast: the thing is, those architectures aren't even enabled (the ones that are stalling)
2019-05-24 00:03:19 <jwh> :D
2019-05-24 00:04:22 <SpaceToast> ^ second bug made
2019-05-24 00:04:30 <SpaceToast> jwh: funfun
2019-05-24 00:04:45 <TBK[m]> atm Drone still run the pipeline for those archs and then abuild determines that there is nothing to do
2019-05-24 00:04:50 <jwh> yeah
2019-05-24 00:05:23 <jwh> https://travis-ci.org/alpinelinux/aports/builds/536549816
2019-05-24 00:05:25 <jwh> travis is just busted
2019-05-24 00:05:43 <SpaceToast> y u break ci :)
2019-05-24 00:05:54 <jwh> about time, it keeps breaking my builds :D
2019-05-24 00:06:36 <TBK[m]> access to Drone activity feed has been disabled so we can't see what is queued
2019-05-24 00:06:38 <jwh> Backlog Linux Builds for Open Source projects
2019-05-24 00:06:38 <jwh> 0 jobs
2019-05-24 00:06:42 <jwh> lols
2019-05-24 00:07:02 <jwh> TBK[m]: it just looks like the armv7 stuff on drone thats broken, others were fine
2019-05-24 00:07:41 <jwh> but yeah, lack of activity feed sucs
2019-05-24 00:07:42 <jwh> sucks*
2019-05-24 00:07:42 <SpaceToast> perhaps someone should package laminar and just move us to that eh? :^)
2019-05-24 00:08:14 <jwh> eh my builds are better than CI anyway
2019-05-24 00:08:35 <jwh> since I use the things I update in production so they're tested before I send PR
2019-05-24 00:08:42 <jwh> :D
2019-05-24 00:08:45 <SpaceToast> ^ same
2019-05-24 00:08:52 <SpaceToast> I use them through https://build.toastin.space
2019-05-24 00:09:07 <SpaceToast> though I really need to clean that thing
2019-05-24 00:09:10 <jwh> I should really publish mine
2019-05-24 00:09:13 <SpaceToast> (I don't bother removing packages)
2019-05-24 00:09:17 <jwh> yeah
2019-05-24 00:09:21 <SpaceToast> (just move over to non-tagged once it's merged)
2019-05-24 00:09:22 <jwh> thats why I don't atm
2019-05-24 00:09:34 <SpaceToast> I figured publishing unclean > not publishing
2019-05-24 00:09:42 <SpaceToast> just have this huge warning like "BTW THIS UNSTABLE"
2019-05-24 00:09:46 <jwh> also time and stuff :D
2019-05-24 00:10:00 <SpaceToast> some of my consumers are outside the nat
2019-05-24 00:10:07 <SpaceToast> (@ work, mostly internal testing stuff)
2019-05-24 00:10:13 <SpaceToast> so publishing was just easier
2019-05-24 00:11:41 <TBK[m]> SpaceToast: looking forward to your laminar aport :P
2019-05-24 00:11:48 <SpaceToast> I've seriously considered it
2019-05-24 00:11:52 <SpaceToast> several times!
2019-05-24 00:11:56 <jwh> no stop it, hooks first :D
2019-05-24 00:12:00 <SpaceToast> but I generally prefer to only maintain things I de-facto use
2019-05-24 00:12:04 <SpaceToast> and I don't CURRENTLY use laminar
2019-05-24 00:12:10 <SpaceToast> (https://laminar.ohwg.net/ for reference)
2019-05-24 00:12:16 <SpaceToast> but it's definitely a project I'm keeping an eye on
2019-05-24 00:12:51 <SpaceToast> if I ever actually do make the jump, you can expect it to be on a PR to testing/ within the month, though :)
2019-05-24 01:30:37 <ddevault> do we know when we can expect ncopa to return?
2019-05-24 01:30:48 <SpaceToast> he said he was leaving for 2 weeks, I think
2019-05-24 01:30:57 <SpaceToast> so... figure out when he left and count :)
2019-05-24 01:31:32 <ddevault> "he should be back sooner than two weeks from today" is specific enough for me
2019-05-24 01:31:40 <SpaceToast> alright :)
2019-05-24 06:35:15 <ncopa> morning
2019-05-24 06:35:16 <ncopa> im back
2019-05-24 06:37:06 <Cogitri> Morning, and welcome back :)
2019-05-24 06:38:07 <ncopa> thanks!
2019-05-24 06:38:34 <SpaceToast> oh, hey ncopa! welcome back :D
2019-05-24 06:38:45 <ncopa> i was able to completely disconnect from alpine, which means it has been a real vacation
2019-05-24 06:38:51 <ncopa> and i feel refreshed!
2019-05-24 06:38:58 <SpaceToast> that's great! ^^
2019-05-24 06:39:04 <SpaceToast> not everything has burned to the ground, I swear
2019-05-24 06:39:16 <ncopa> good! :)
2019-05-24 06:39:40 <ncopa> looks like there have been progress
2019-05-24 06:40:20 <ncopa> PR queue has increased but that is expected i guess
2019-05-24 06:40:43 <SpaceToast> mostly main/ is posing a particular problem
2019-05-24 06:40:55 <ncopa> figured that
2019-05-24 06:41:01 <SpaceToast> very few seem to actually have access, and I'm not sure if everything in question really should be there
2019-05-24 06:41:04 <SpaceToast> but no one asked me :)
2019-05-24 06:41:15 <ncopa> are there anything i should prioritize?
2019-05-24 06:41:51 <SpaceToast> I'm obviously not aware of everything, but...
2019-05-24 06:42:06 <SpaceToast> pr7895 and pr7631 seem relatively simple ones
2019-05-24 06:43:04 <ncopa> oh, good. so there is nothing particular that is urgent and obvious that needs to be taken care of
2019-05-24 06:44:02 <SpaceToast> I did break the x86 builder
2019-05-24 06:44:22 <SpaceToast> but after some funny workarounds it's going (for now)
2019-05-24 06:44:37 <SpaceToast> bugs are up on bug.a.o (should be the two latest ones), and carlo said he'd take a look once he wakes up
2019-05-24 06:44:42 <SpaceToast> s/bug/bugs/
2019-05-24 06:44:42 <alpine-meetbot> SpaceToast meant to say: bugss are up on bug.a.o (should be the two latest ones), and carlo said he'd take a look once he wakes up
2019-05-24 06:44:49 <SpaceToast> humbug.
2019-05-24 06:46:14 <Cogitri> ncopa: I'd appreciate if you could look at pr7262, it blocks all of GNOME right now :)
2019-05-24 06:47:41 <ncopa> Cogitri: ok. will have a look after breakfast
2019-05-24 06:47:50 <Cogitri> Thank you! :)
2019-05-24 07:11:56 <Cogitri> Can I get a CI-malfunction on pr8028? Gnome-BUILDER can't find the flatpak&flatpak-builder on aarch64 which has been enabled for that arch in the same PR
2019-05-24 07:50:25 <mps> looks likee x86 lxc somewhat specific, I had some issues with it while x86_64, aarch64, armv7 and armhf works fine
2019-05-24 07:56:24 <mps> anyone have any objections to remove dbus build dependencies from gimp?
2019-05-24 07:56:56 <mps> and cups, also
2019-05-24 07:59:16 <mps> I would like to move move fwknop from testing to community, any objections?
2019-05-24 08:00:26 <Cogitri> mps: I'd object to disabling dbus on cups
2019-05-24 08:00:47 <tcely> Cogitri: really? why?
2019-05-24 08:01:26 <mps> Cogitri: explain, please
2019-05-24 08:01:38 <Cogitri> Without it you won't get notifications on your desktop ala "Printing on printer X has finished"
2019-05-24 08:02:15 <Cogitri> Or if printing has failed
2019-05-24 08:02:21 <mps> I run cups without X and DE
2019-05-24 08:03:16 <Cogitri> Well, maybe we can split the stuff that links against dbus off of cups?
2019-05-24 08:05:17 <mps> what you mean, some add-on to cups?
2019-05-24 08:06:33 <ncopa> i did a quick look at the git log. you people have done great while i have been away
2019-05-24 08:06:43 <Cogitri> A subpackage
2019-05-24 08:07:11 <mps> Cogitri: that sounds ok
2019-05-24 08:07:39 <mps> ncopa: welcome back :)
2019-05-24 08:08:13 <clandmeter> TBK[m]: if tests fails on specific arch, please only disable them for that arch.
2019-05-24 08:08:36 <clandmeter> SpaceToast: i think you need to add options chmod-clean
2019-05-24 08:09:01 <SpaceToast> clandmeter: that shouldn't be applicable here
2019-05-24 08:09:11 <clandmeter> why not?
2019-05-24 08:09:22 <SpaceToast> cleanup_srcdir should be respected, option or not
2019-05-24 08:09:36 <SpaceToast> and the de-facto correct way to get rid of those files to let the thing that put them there to begin with remove them
2019-05-24 08:09:51 <SpaceToast> this works just fine normally, both on my builder and yours (for instance, minio's been in testing for a while now)
2019-05-24 08:10:03 <SpaceToast> also it's 4am :)
2019-05-24 08:10:04 <clandmeter> it happens when build fails
2019-05-24 08:10:46 <SpaceToast> I just simulated the build failing on my builder
2019-05-24 08:10:49 <SpaceToast> no such problems.
2019-05-24 08:10:54 <clandmeter> it does on my env
2019-05-24 08:11:06 <SpaceToast> well, why is your env ignoring cleanup_srcdir? :)
2019-05-24 08:11:09 <mps> clandmeter: also on my
2019-05-24 08:11:23 <clandmeter> it happens on the builder
2019-05-24 08:11:34 <clandmeter> i dont care about anyone else system :)
2019-05-24 08:11:42 <SpaceToast> actually, I think I figured out the problem
2019-05-24 08:11:45 <SpaceToast> can I just send you a patch?
2019-05-24 08:11:53 <SpaceToast> it's small, I swear
2019-05-24 08:11:59 <tcely> Is it the undeps?
2019-05-24 08:12:13 <SpaceToast> no
2019-05-24 08:12:18 <SpaceToast> it's the environment variables :)
2019-05-24 08:13:13 <SpaceToast> clandmeter: https://brpaste.xyz/raw/V0USUw
2019-05-24 08:13:33 <SpaceToast> I think the problem is that `go clean -modcache` doesn't know where to look ^^;;
2019-05-24 08:13:43 <SpaceToast> my attempts to change as little as possible actually caused the (isolated) problem
2019-05-24 08:15:56 <tcely> If that solves this, then I don't understand how ash is operating.
2019-05-24 08:20:47 <clandmeter> SpaceToast: thx pushed.
2019-05-24 08:21:14 <SpaceToast> if it doesn't solve it, please avoid pinging me until ~8h from now, ty ^^
2019-05-24 08:21:20 <SpaceToast> (like you, I'm going to be trying to pass out now :) )
2019-05-24 08:21:25 <SpaceToast> (well, like you previously*)
2019-05-24 08:21:27 <clandmeter> its already build
2019-05-24 08:21:31 <SpaceToast> oh, goodie :)
2019-05-24 08:23:28 <OxFEEDBACC> high
2019-05-24 08:23:36 <SpaceToast> low
2019-05-24 08:24:00 <SpaceToast> clandmeter: as a fast check - I'm guessing lxcfs was in fact disabled, and that isn't the normal state of things?
2019-05-24 08:24:03 <OxFEEDBACC> i'm playing around with building some linux (not really from scratch) on the basic level...
2019-05-24 08:24:40 <clandmeter> SpaceToast: we do not have lxcfs enabled and never have.
2019-05-24 08:24:42 <OxFEEDBACC> because some packages are tricky to (pseudo-)cross-compile, i'm borrowing some from alpine... it worked great with zsh, for example...
2019-05-24 08:24:53 <SpaceToast> hm
2019-05-24 08:25:02 <SpaceToast> well, tests will fail unless it is enabled
2019-05-24 08:25:13 <SpaceToast> and I'd prefer testing over not-testing, but not my problem I guess
2019-05-24 08:25:22 <OxFEEDBACC> but there are some packages, that contain a .trigger script, and i wonder, what that's about and how it is called... how can i determine the parameters passed to it?
2019-05-24 08:25:41 <clandmeter> SpaceToast: thats why i asked you to add the ticket, so we can discus it.
2019-05-24 08:26:02 <SpaceToast> ah, good :) https://bugs.alpinelinux.org/issues/10484 for reference
2019-05-24 08:26:08 <SpaceToast> anyway, *actually* going to bed now
2019-05-24 08:26:24 <ncopa> SpaceToast: sounds like a good idea. good night!
2019-05-24 08:27:47 <tcely> OxFEEDBACC: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#triggers
2019-05-24 08:30:02 <OxFEEDBACC> thx
2019-05-24 08:31:59 <OxFEEDBACC> okay, it's clear now :-D
2019-05-24 08:40:53 <tcely> You're welcome
2019-05-24 08:41:25 <tcely> btw, why Ox instead of 0x ?
2019-05-24 08:47:32 <mps> my effort to lower number on the pw.a.o is total fiasco. not sure if it is because I sent mails (to authors) only to aports ML, presuming they are subscribed, or because they ignore mails from random (my) mail address
2019-05-24 08:50:07 <tcely> Did I read apk tools source correctly? Trigger gets the number in the queue as an argument?
2019-05-24 08:53:07 <ncopa> tcely: nice work with https://github.com/libuv/libuv/issues/2297
2019-05-24 08:55:12 <tcely> ncopa: thanks. It's nice to get to the fix.
2019-05-24 08:55:23 <ncopa> +1
2019-05-24 08:55:46 <ncopa> i suspect the other libuv issue may be something similae
2019-05-24 08:55:56 <ncopa> s/similae/similar/
2019-05-24 08:55:56 <alpine-meetbot> ncopa meant to say: i suspect the other libuv issue may be something similar
2019-05-24 08:57:51 <Cogitri> mps: Well, disadvantages of mail based workflow I suppose
2019-05-24 08:58:22 <mps> Cogitri: :-}D
2019-05-24 08:59:15 <tcely> ncopa: did you browse the triage project already? There were > 20 requests for main when I last looked.
2019-05-24 09:00:05 <ncopa> not yet
2019-05-24 09:00:13 <ncopa> url?
2019-05-24 09:02:16 <mps> Cogitri: if the people don't mind to subscribe to ML where they send patches or the the people don't mind to follow their PR on GH/GL not much can be done
2019-05-24 09:02:58 <tcely> https://github.com/alpinelinux/aports/projects/1#column-5385612
2019-05-24 09:04:34 <Cogitri> mps: Yup :c
2019-05-24 09:06:33 <mps> Cogitri: btw, will we continue work on llvm8
2019-05-24 09:07:34 <Cogitri> Is that a question?
2019-05-24 09:07:55 <mps> I would take your PR (patch) and try to test it with some packages, thinking to try rust 1.33
2019-05-24 09:08:24 <mps> well, rhetorical one
2019-05-24 09:09:03 <Cogitri> s/1.33/1.34.2/
2019-05-24 09:09:43 <mps> I have first to try to build 1.33 on aarch64 and armv7
2019-05-24 09:10:04 <Cogitri> Yup, but 1.33 doesn't work with LLVM8
2019-05-24 09:10:28 <mps> uhmm, really
2019-05-24 09:11:59 <mps> looks like Adelie linux built rust 1.33 with llvm8, but not checked to be sure
2019-05-24 09:12:13 <Cogitri> Yup, really
2019-05-24 09:12:17 <Cogitri> Well, then with downstream patching
2019-05-24 09:12:39 <Cogitri> But I did the Rust 1.33 and 1.34 bump for Void and we could only use LLVM8 with Rust 1.34
2019-05-24 09:12:46 <Cogitri> And upstream only switched to LLVM8 with 1.34
2019-05-24 09:14:48 <mps> I will try llvm8 and rust 1.33 over the weekend
2019-05-24 09:15:04 <mps> will see :|
2019-05-24 09:15:33 <ncopa> tcely: wow. that triage thing looks really nice
2019-05-24 09:16:28 <tcely> It is. It is even nicer with project-bot
2019-05-24 09:16:58 <Cogitri> mps: I can guarantee you that it won't work
2019-05-24 09:17:02 <Cogitri> Use rust 1.33 w/ LLVM7 and upgrade to LLVM8 with 1.34.2
2019-05-24 09:18:19 <tcely> #10482
2019-05-24 09:19:18 <mps> Cogitri: thanks for info, maybe will try according your advice
2019-05-24 09:20:10 <tcely> Cogitri mps: good luck to you both
2019-05-24 09:20:27 <Cogitri> Thanks :)
2019-05-24 09:20:46 <Cogitri> What's the plan on LLVM8, mps? Should we wait for the patchwork stuff or should I just reopen my PR?
2019-05-24 09:20:49 <tcely> A newer rust on all architectures would be a huge accomplishment
2019-05-24 09:21:00 <Cogitri> Yup
2019-05-24 09:21:43 <Cogitri> Well, the PR for 1.34.2 is already up, once that is merged we can focus on 1.35 w/ more arch support IMO
2019-05-24 09:23:03 <mps> Cogitri: I posted mail to patch author (and not only about llvm) and didn't received any answer
2019-05-24 09:24:08 <mps> I tested your PR, and build worked, so I tend to think that we could start to work with it
2019-05-24 09:25:07 <Cogitri> Alright, will reopen it then once I get home
2019-05-24 09:29:22 <mps> we are not in hurry, I suspect we can manage to make all this for 3.10 release
2019-05-24 09:30:34 <Cogitri> Well, we're not in a hurry, but yet I'd like to get things done :P
2019-05-24 09:31:29 <mps> ofc, agree fully
2019-05-24 09:34:30 <MY_R> what should be done to accept pr7814 ? :)
2019-05-24 09:35:22 <Cogitri> MY_R: Wait for someone with commit access to merge it :c
2019-05-24 09:35:38 <mps> Cogitri: release time is near, and we will have a lot of work to fix bugs, issues, tests and other things
2019-05-24 09:35:55 <MY_R> ah :)
2019-05-24 09:36:15 <mps> I'm preparing myself for hard work in next days
2019-05-24 09:39:01 <Cogitri> Feel free to ping me if I can help :)
2019-05-24 09:39:40 <mps> most of these will be here
2019-05-24 09:41:28 <mps> I need to buy some gift to someone with access to main who would help me fixing or upgrade some packages ;)
2019-05-24 09:42:20 <Cogitri> Hehe
2019-05-24 09:47:02 <tcely> lol offerings on the alter to main pushing ;-)
2019-05-24 09:48:23 <mps> ncopa: I rebuilt perl with one line fix, `CFLAGS="$CFLAGS -DNO_POSIX_2008_LOCALE"` in build(), and it worked
2019-05-24 09:49:23 <_ikke_> Cogitri: can 1.34 build on 1.32?
2019-05-24 09:49:30 <mps> taken from void linux
2019-05-24 09:50:25 <_ikke_> I wonder why perl modules would need to be bumped when applying this fix
2019-05-24 09:50:32 <_ikke_> at least, that is what void seems to have dne
2019-05-24 09:51:18 <mps> _ikke_: i presume to be rebuilt with change
2019-05-24 09:52:48 <_ikke_> I wonder how that change would affect the modules
2019-05-24 09:53:33 <danieli> it's perl, it doesn't always make sense
2019-05-24 09:53:35 <mps> it will affect modules which must be linkded with libperl.so
2019-05-24 09:54:13 <_ikke_> binary extensions?
2019-05-24 09:54:22 <mps> yes
2019-05-24 09:55:02 <mps> 'source' only modules probably will not be affected so don't need bump
2019-05-24 09:56:01 <_ikke_> So we need a list of modules with binary extensions
2019-05-24 09:57:27 <mps> something like 'apk info -r so:libperl.so'
2019-05-24 09:57:39 <danieli> mps: shouldn't be much harder than that, yeah
2019-05-24 09:58:18 <clandmeter> _ikke_: i already posted the list before
2019-05-24 10:00:04 <clandmeter> _ikke_: https://tpaste.us/ErEW
2019-05-24 10:01:07 <clandmeter> ncopa: not sure you noticed but i moved wireguard.
2019-05-24 10:02:59 <Cogitri> _ikke_: No, Rust 1.32 -> 1.33 -> 1.34 is required
2019-05-24 10:03:04 <Cogitri> That's why I added both commits to the PR
2019-05-24 10:03:46 <tcely> 
ACTION feels like rust goes out of the way to make using it difficult

2019-05-24 10:05:35 <Cogitri> Hm, why?
2019-05-24 10:05:58 <Cogitri> Ah, yeah, that is a bit annoying, but usually you can bootstrap from upstream tarballs
2019-05-24 10:06:22 <danieli> i feel like it was difficult (on musl) in the first place, and that they're *not* going out of their way to make it better
2019-05-24 10:09:13 <Cogitri> Musl is now officially supported by Rust upstream
2019-05-24 10:09:27 <danieli> cool, so we've dropped all patches we had for rust?
2019-05-24 10:09:32 <Cogitri> I use the official stable tarballs for x86_64-unkown-linux-musl for my dev env
2019-05-24 10:10:05 <Cogitri> We could, but then we'd give up the rpath stuff, which would bloat up the size a bit though
2019-05-24 10:10:28 <Cogitri> We could drop the custom targets though
2019-05-24 10:21:10 <_ikke_> Cogitri: is that going to work? The builders are just going to build the last one
2019-05-24 10:21:20 <_ikke_> so it would use 1.32 to build 1.34
2019-05-24 10:22:28 <ncopa> clandmeter: i saw that you have done something with wireguard
2019-05-24 10:24:05 <ncopa> mps: what about perl and -DNO_POSIX_2008_LOCALE? why is that needed?
2019-05-24 10:24:06 <Cogitri> _ikke_: Oh, sorry, thought it'd build it one by one
2019-05-24 10:24:56 <Cogitri> Will remove the 1.34.2 commit and open a new PR for that once 1.33 has been merged
2019-05-24 10:24:57 <clandmeter> _ikke_: did we remove go from 3.10 builders?
2019-05-24 10:25:08 <_ikke_> clandmeter: I'm not sure if it's removed from all of them
2019-05-24 10:25:16 <_ikke_> I took care of x86(_64)
2019-05-24 10:26:15 <MY_R> ncopa, probably: Bug #10459: urxvt : panic: locale.c: 893: Unexpected character in locale name '2E.
2019-05-24 10:27:02 <mps> ncopa: can't remember all issues, but rxvt and some other pkg doesn't work
2019-05-24 10:27:45 <_ikke_> according to dalias, perl is doing some non-sensical things
2019-05-24 10:27:48 <mps> gimp can't be built, and postgresql have issue with plperl test
2019-05-24 10:28:18 <ncopa> ah!
2019-05-24 10:28:28 <ncopa> so this CFLAGS thing fixes it?
2019-05-24 10:29:07 <mps> I didn't tested all these programs, just some, and looks like it fixes them
2019-05-24 10:29:15 <_ikke_> That's at least how Void dealed with it
2019-05-24 10:29:24 <_ikke_> s/dealed/dealt
2019-05-24 10:29:24 <alpine-meetbot> _ikke_ meant to say: That's at least how Void dealt with it
2019-05-24 10:30:16 <ncopa> https://github.com/void-linux/void-packages/issues/1798#issuecomment-413526419
2019-05-24 10:30:38 <_ikke_> https://github.com/void-linux/void-packages/pull/1849
2019-05-24 10:31:29 <mps> gimp 'abuild -r' checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
2019-05-24 10:31:42 <ncopa> requires rebuild of all perl modules :-(
2019-05-24 10:31:53 <_ikke_> ncopa: I wonder why?
2019-05-24 10:31:54 <mps> but with fix I made it builds
2019-05-24 10:32:14 <ncopa> is it true that we need to rebuild all perl modules?
2019-05-24 10:32:23 <clandmeter> i remember someobdy mention only the ones that link to libperl?
2019-05-24 10:32:41 <ncopa> so the same thing that when we upgraded perl to 5.28
2019-05-24 10:32:45 <ncopa> ugh
2019-05-24 10:32:45 <ncopa> ok
2019-05-24 10:32:49 <_ikke_> 2019-05-23 12:05:23     p4Wv1qn095FW    Requires rebuild of all Perl modules that link to libperl
2019-05-24 10:33:03 <clandmeter> that list is limited
2019-05-24 10:33:14 <_ikke_> From clandmeter: https://tpaste.us/ErEW
2019-05-24 10:33:15 <ncopa> yes, but its still 100+
2019-05-24 10:33:17 <mps> yes, only those which are linked
2019-05-24 10:33:39 <clandmeter> 100+?
2019-05-24 10:33:51 <ncopa> not those that are arch specific?
2019-05-24 10:34:11 <clandmeter> i specifically searched for depends on libperl, and that was the list i got.
2019-05-24 10:34:12 <mps> clandmeter: how did you made your list, looks to short to me
2019-05-24 10:34:50 <mps> too short* and not 'to short'
2019-05-24 10:35:12 <ncopa> i would expect it needs to rebuild all perl modules that has C code
2019-05-24 10:35:26 <ncopa> eg all perl modules that are not arch="noarch"
2019-05-24 10:35:30 <mps> probably
2019-05-24 10:35:53 <_ikke_> But don't they need to link against something from perl to be affected?
2019-05-24 10:36:42 <ncopa> the thing is that they are "linked" to libperl but via dlopen from perl
2019-05-24 10:36:58 <ncopa> so they are not directly linked via gcc linker
2019-05-24 10:37:03 <_ikke_> ah ok
2019-05-24 10:37:39 <_ikke_> Then I guess arch!=noarch would make sense
2019-05-24 10:38:25 <ncopa> "Requires rebuild of all Perl modules that link to libperl"
2019-05-24 10:38:47 <ncopa> so my question is: why does it requires rebuild of all Perl modules that link to libperl
2019-05-24 10:40:29 <ncopa> the answer to that question will determine if only https://tpaste.us/ErEW needs to be rebuilt or the 100+
2019-05-24 10:41:05 <_ikke_> How can that be determined?
2019-05-24 10:41:12 <_ikke_> It has to do with ABI compatibility, correct?
2019-05-24 10:41:19 <ncopa> correct
2019-05-24 10:41:31 <_ikke_> So the question is how that change would affect the ABI
2019-05-24 10:41:44 <ncopa> correct
2019-05-24 10:42:49 <ncopa> this would be the list of packages: http://tpaste.us/aRgM
2019-05-24 10:44:33 <ncopa> 217 packages
2019-05-24 10:50:03 <mps> i'm not sure how this works for perl modules but seems they need rebuild, at least to my uneducated eyes about perl intrinsic
2019-05-24 11:08:20 <ncopa> north1: seems like you have experience with it?
2019-05-24 11:08:56 <north1> ncopa: I did the revbump on Void
2019-05-24 11:09:27 <ncopa> do you know why perl modules needs to be rebuilt with that change?
2019-05-24 11:09:35 <ncopa> or have link to details
2019-05-24 11:10:24 <north1> Diagnostics was done by Leah Neukirchen from the Void Linux team
2019-05-24 11:10:25 <north1> no clue you can hit leah2 on freenode / #xbps
2019-05-24 11:10:39 <north1> I'm currently taking a bus so can't grab the links
2019-05-24 11:17:31 <ncopa> ok. thanks!
2019-05-24 12:28:24 <mps> do we have policy for scripts (pkgs) of the using `#!/usr/bin/env interpreter`? i.e. `#!/usr/bin/env perl` or `#!/usr/bin/perl`
2019-05-24 12:37:10 <TBK[m]> ncopa: welcome back. I hope you had an enjoyable vacation.
2019-05-24 12:41:49 <tmhoang> so ncopa come back on a Friday :)
2019-05-24 12:42:25 <danieli> well heck, welcome back ncopa
2019-05-24 12:44:53 <Cogitri> Can I get a merge in pr7241?
2019-05-24 12:45:09 <Cogitri> Now that libgudev is merged most of GNOME can be merged one by one :)
2019-05-24 13:01:12 <z3ntu> Is there a reason there are no -dbg packages for the qt5-* packages?
2019-05-24 13:10:49 <ncopa> z3ntu: nobody asked for it
2019-05-24 13:11:28 <z3ntu> Actually we isn't Alpine building dbg packages by default?
2019-05-24 13:11:45 <ncopa> to save space
2019-05-24 13:12:50 <ncopa> the -dbg are seldomly needed, but they may significantly increase disk usage
2019-05-24 13:13:05 <ncopa> specially for things like chromium and firefox
2019-05-24 13:56:39 <[[sroracle]]> TBK[m]: i have a fix for the laminar test suite. writing a comment and working on a PR
2019-05-24 13:58:36 <TBK[m]> [[sroracle]]: super :)
2019-05-24 14:21:00 <ncopa> hum
2019-05-24 14:21:05 <ncopa> seems like perl 5.30 was released
2019-05-24 14:22:22 <ncopa> atleast it was tagged
2019-05-24 14:23:45 <[[sroracle]]> TBK[m]: https://github.com/ohwgiles/laminar/issues/94#issuecomment-495651512
2019-05-24 14:24:11 <danieli> ncopa: 5.30 will be out some time in the middle of 2019 according to some articles i see
2019-05-24 14:24:30 <danieli> actually, another page says it 'should be released at the end of may 2019'
2019-05-24 14:29:26 <ncopa> ok. building perl with -DNO_POSIX_2008_LOCALE will likely require full rebuild
2019-05-24 14:29:42 <ncopa> oh.. maybe not
2019-05-24 14:30:07 <ncopa> S_emulate_setlocale will disappear
2019-05-24 14:30:10 <ncopa> but its static
2019-05-24 14:39:23 <mps> ncopa: I posted patch to pw.a.o to build 'slim' without consolekit, so it will not pull polkit and mozjs. some people want xDM without polkit/mozjs
2019-05-24 14:40:17 <mps> and clandmeter told me that fedora or redhat (forgot exactly) also build slim without consolekit
2019-05-24 14:41:06 <ncopa> mps: sounds reasonable
2019-05-24 14:41:10 <ncopa> url?
2019-05-24 14:41:42 <ncopa> i think it should be possible to build perl with -DNO_POSIX_2008_LOCALE without rebuilding all perls stuff
2019-05-24 14:41:55 <mps> here https://patchwork.alpinelinux.org/patch/4890/
2019-05-24 14:42:55 <mps> well, i didn't tested other perl packages, but when I rebuilt perl and installed it some packages worked, i.e. gimp
2019-05-24 14:42:55 <ncopa> could you please include why it is disabled in commit message?
2019-05-24 14:43:12 <ncopa> "build 'slim' without consolekit, so it will not pull polkit and mozjs. some people want xDM without polkit/mozjs"
2019-05-24 14:43:41 <mps> complete message? np.
2019-05-24 14:43:58 <ncopa> atleast explain why it is disabled
2019-05-24 14:44:22 <mps> I'm bad at writing good commit messages, but no problem will do
2019-05-24 14:44:59 <ncopa> point is that polkit now uses mozjs and we want an alternative for those who wants avoid it
2019-05-24 14:45:17 <mps> yes, that was reason
2019-05-24 14:45:33 <ncopa> yeah, writing commit message is often harder than the commit itself :)
2019-05-24 14:54:18 <mps> ncopa: https://patchwork.alpinelinux.org/patch/4891/ I hope it is better now
2019-05-24 14:57:40 <ncopa> we should probably move slim to community
2019-05-24 14:57:48 <ncopa> no good reason to keep it in main
2019-05-24 14:58:12 <mps> I thought same
2019-05-24 15:01:30 <mps> how to mark patch V1 which is changed with V2 on pw.a.o, which state? also accepted, superseded or rejected?
2019-05-24 15:04:05 <danieli> i'd say superseded
2019-05-24 15:04:42 <mps> also to me sounds most reasonable
2019-05-24 16:07:14 <mps> I'm working on 'arm-trusted-firmware' pkg, which contains trusted firmares for different boards. Would like to make it similar to linux-firmware pkg, main pkg and subpackages for every different firmware
2019-05-24 16:08:00 <mps> how to make 'empty' main package which will depend on all of the subpackages. Any guide or hint
2019-05-24 16:08:32 <_ikke_> mps: in build(), mkdir -p "$pkgdir"
2019-05-24 16:08:38 <_ikke_> sorry
2019-05-24 16:08:40 <_ikke_> in package()
2019-05-24 16:09:38 <mps> _ikke_: yes, i did, but how then it depends on subpackages
2019-05-24 16:11:04 <_ikke_> Just adding depends on the subpackages
2019-05-24 16:11:05 <mps> I looked through linux-firmware APKBUILD but didn't understood it, looks to complicated
2019-05-24 16:12:18 <mps> _ikke_: thanks, I will prepare new one and post it to you for review and help.
2019-05-24 19:06:52 <_ikke_> Cogitri: rust 1.33 pushed
2019-05-24 19:08:44 <north1> _ikke_: nice, he is out atm
2019-05-24 21:12:42 <Cogitri> Nice, thank you Ikke
2019-05-24 21:12:47 <Cogitri> Will open the 1.34.2 PR and then wait for LLVM8 to be merged I suppose
2019-05-24 22:53:14 <SpaceToast> Oh wow, that's a lot of rust progress all of a sudden!
2019-05-24 22:53:19 <SpaceToast> Great to see :)
2019-05-24 22:59:01 <Cogitri> :)
2019-05-24 23:18:05 <SpaceToast> Cogitri: if you could be so kind, could you ping me if/when 1.34 is merged?
2019-05-24 23:18:10 <SpaceToast> I have packages to upgrade ^^
2019-05-24 23:29:43 <north1> 
ACTION screaming ripgrep in the background

2019-05-24 23:31:34 <SpaceToast> That would be one, yes ;)
2019-05-24 23:31:44 <SpaceToast> Soon!
2019-05-24 23:31:55 <SpaceToast> I'm also going to open a PR for bat(1) once that happens
2019-05-24 23:32:39 <SpaceToast> I forget if I already have fd in but that too :)
2019-05-24 23:33:14 <PureTryOut[m]> Still no Rust for aarch64 and armv7 though 😭
2019-05-24 23:33:36 <north1> What is the reason for not enabling on them ? miscompilation ?
2019-05-24 23:34:18 <SpaceToast> Oh, is it enabled on more than just amd64 now?
2019-05-24 23:36:38 <TBK[m]> nope
2019-05-24 23:36:38 <north1> only x86_64
2019-05-24 23:37:32 <SpaceToast> Oh ok, as before then
2019-05-25 00:53:16 <north1> Can we get pr7849 in ? there are 2 gucharmaps and the one in main is outdated compared to the one in testing.
2019-05-25 01:00:04 <north1> ty
2019-05-25 01:00:31 <TBK[m]> yw
2019-05-25 03:26:39 <north1> @TBK:matrix.org: Any documentation/examples on how to use xvfb-run to run tests ?
2019-05-25 03:27:05 <north1> huh
2019-05-25 03:27:09 <north1> xvfb-run make check seemed to work
2019-05-25 03:27:47 <TBK[m]> you just wrap the command: xvfb-run ninja -C build test
2019-05-25 03:27:59 <north1> sounds good to me
2019-05-25 03:29:00 <TBK[m]> problem is, it is still in testing and somebody other then me needs to merge PR8012 :)
2019-05-25 03:31:23 <north1> ah, i updated the PR to include it in checkdepends=
2019-05-25 03:31:33 <north1> so merge it after your package move is done
2019-05-25 03:36:49 <north1> @TBK:matrix.org: Updated the wiki to recommend xvfb-run
2019-05-25 03:37:22 <TBK[m]> sweet
2019-05-25 03:48:50 <north1> osinfo-db-tools tests fail
2019-05-25 03:49:09 <north1> because it tries to run a user instance and my user has XDG_CONFIG_HOME set to $HOME/etc while it looks at $HOME/.config
2019-05-25 03:53:08 <north1> https://gitlab.com/libosinfo/osinfo-db-tools/issues/3
2019-05-25 03:58:39 <north1> @TBK:matrix.org: osinfo-db-tools is updated to 1.5.0
2019-05-25 04:00:24 <TBK[m]> maxice8: I am just waising for CI
2019-05-25 04:00:25 <TBK[m]> s/waising/waiting/
2019-05-25 04:00:25 <alpine-meetbot> TBK[m] meant to say: maxice8: I am just waiting for CI
2019-05-25 04:00:38 <north1> nice
2019-05-25 04:03:06 <TBK[m]> maxice8: something wonkey is going on - tests run: TOTAL: 0
2019-05-25 04:03:19 <north1> i'll take a look at it tomorrow
2019-05-25 04:03:27 <north1> in the middle of enabling zbar python3 binding
2019-05-25 04:03:51 <TBK[m]> ok, much appreciated
2019-05-25 04:03:56 <north1> +1
2019-05-25 04:07:16 <north1> i think i found the reason
2019-05-25 04:07:23 <north1> no clue why it works on my setup since mine i use dabuild with alpinelinux/docker-abuild
2019-05-25 04:07:28 <north1> ModuleNotFoundError: No module named 'requests'
2019-05-25 04:07:55 <north1> ok pushed with py3-requests on deps, lets see if it works now
2019-05-25 04:08:57 <north1> https://cloud.drone.io/alpinelinux/aports/4992 nice
2019-05-25 04:09:00 <north1> 3 out of 3 tests done
2019-05-25 04:13:47 <TBK[m]> maxice8: thanks for all your hard work. I will head to bed now.
2019-05-25 04:17:41 <north1> @TBK:matrix.org: ty, you too
2019-05-25 06:59:03 <Cogitri> SpaceToast: Will do! :)
2019-05-25 06:59:32 <Cogitri> PureTryOut: Once we have LLVM8 I can work on more arches with mps
2019-05-25 06:59:58 <Cogitri> LLVM7 just straight up dies on aarch64 and segfaults randomly on other arches
2019-05-25 08:46:03 <mps> Cogitri: and you now know why I'm repeating that llvm7 is problematic
2019-05-25 08:50:39 <mps> north1: did you tested xvfb-run on drones on all arch's
2019-05-25 08:56:42 <Cogitri> mps: And you know why I'm repeating that we need LLVM8 merged soon :)
2019-05-25 08:57:47 <Cogitri> I've reopened pr7500 for now.
2019-05-25 08:58:30 <mps> Cogitri: yes, we need it
2019-05-25 08:59:35 <mps> I reserved this weekend to work on it and rust on arm's
2019-05-25 09:00:36 <Cogitri> Nice :)
2019-05-25 09:00:54 <Cogitri> You can use pr8057 for Rust 1.34.2 which works on llvm8
2019-05-25 09:02:21 <mps> no, I will try first to make 1.33 apk and then we will talk how to merge our works in one
2019-05-25 09:03:03 <Cogitri> Uh, sure, but then you'll have to use LLVM7
2019-05-25 09:03:47 <mps> I hope that I can skip it and go straight to llvm8, will see in a few hours is this good idea
2019-05-25 09:05:17 <mps> I have 1.31 built with llvm6 and will try use it to build 1.32, hope will have a luck
2019-05-25 09:08:08 <artok> python3 threading test hangs also on x86_64
2019-05-25 09:09:26 <Cogitri> mps: You'll need https://github.com/rust-lang/rust/commit/0dabf8c835d61b2f7df454be362c23ba6590c761 for llvm8 btw, maybe you can apply it to 1.33 (but I very much doubt it)
2019-05-25 09:11:43 <mps> ufff, this is probably hard
2019-05-25 09:13:54 <mps> btw, you don't have ppc64le box or container?
2019-05-25 09:14:48 <Cogitri> No, I don't happen to gave that
2019-05-25 09:15:05 <Cogitri> Yup, applying that patch is hard, so it's best to just not I guess :P
2019-05-25 09:15:35 <mps> nor do I, and don't know how to make qemu of it
2019-05-25 09:19:12 <mps> yesterday I lost few hours trying to make vifm, it builds on my working v3.9 box  but fail on lxc edge containers
2019-05-25 09:20:22 <mps> would anyone help me, I can post APKBUILD to tpaste
2019-05-25 09:21:10 <mps> it is relatively simple, but I have problem in package()
2019-05-25 09:57:52 <mps> north1: are you here?
2019-05-25 09:58:24 <mps> so, xvfb-run is needed for check for some pkg's in community?
2019-05-25 10:01:19 <Cogitri> He's sleeping
2019-05-25 10:01:32 <Cogitri> xvfb-run is required for all apps which need DISPLAY for check
2019-05-25 10:01:43 <Cogitri> Which means most GUI apps want it
2019-05-25 10:02:47 <mps> I'l move it to community then
2019-05-25 10:08:24 <mps> moved
2019-05-25 10:49:20 <north1> mps: thank you
2019-05-25 10:49:22 <north1> cogitri: Thanks for explaining it while i was sleeping
2019-05-25 10:52:01 <mps> north1: few days ago I thought to ask you do you ever sleep :) I have impression that you are always awake :)
2019-05-25 10:52:38 <north1> mps: it is like that
2019-05-25 10:55:29 <mps> anyone will close GH PR 8012
2019-05-25 12:10:36 <mps> is the something changed in abuild from v3.9 to edge in package() function regarding creating pkg dir
2019-05-25 12:28:45 <Cogitri> Can I get pr7379 merged? It blocks most of the other GNOME stuff
2019-05-25 12:31:39 <mps> is it one commit with a more files for gdm?
2019-05-25 12:32:47 <Cogitri> Sorry?
2019-05-25 12:33:12 <mps> PR 7379 is one commit?
2019-05-25 12:33:52 <mps> you changed more pkg's in this one PR
2019-05-25 12:33:59 <Cogitri> No, it's a whole bunch of stuff needed for GNOME-shell
2019-05-25 12:34:35 <mps> I see, 9 commits
2019-05-25 12:35:05 <Cogitri> Yup
2019-05-25 12:35:10 <TBK[m]> I am reviewing it atm
2019-05-25 12:35:19 <Cogitri> Thank you! :)
2019-05-25 12:37:12 <mps> TBK[m]: ok, thanks. I have to revert it in my local repo
2019-05-25 13:22:43 <TBK[m]> ehh spammers
2019-05-25 13:23:33 <TBK[m]> is there a repo with algitbot's src?
2019-05-25 13:24:11 <Cogitri> <TBK[m] "ehh spammers"> Deleted.
2019-05-25 13:25:29 <TBK[m]> merci
2019-05-25 13:51:27 <_ikke_> TBK[m]: not aware of any repo
2019-05-25 14:36:47 <artok> isn't algibot aports/main/sircbot ?
2019-05-25 14:44:06 <_ikke_> ah, might be, yes
2019-05-25 14:53:08 <danieli> that's the fundament for sure
2019-05-25 15:04:03 <artok> so.
2019-05-25 15:12:41 <artok> builders seem to be latest release rather than some edge stuff
2019-05-25 15:13:09 <_ikke_> ?
2019-05-25 15:13:25 <artok> I have edge as build vm and there is once in a while problems with
2019-05-25 15:14:40 <artok> for example libgpg-error (release version) doesn't compile with gawk 5
2019-05-25 15:19:51 <north1> I can take a look at it soon
2019-05-25 15:19:54 <artok> https://hastebin.com/sotutuyiha
2019-05-25 15:20:00 <artok> there is diff to make it work
2019-05-25 15:20:03 <artok> =)
2019-05-25 15:20:08 <north1> Oh
2019-05-25 15:21:54 <artok> future release of libgpg-error should have that included...
2019-05-25 15:26:50 <north1> At the moment it can be included as a patch I guess
2019-05-25 15:27:08 <artok> yeah, as long as it is version 1.36
2019-05-25 15:27:42 <artok> I can do PR later today for that
2019-05-25 15:34:11 <TBK[m]> artok: That will be appreciated
2019-05-25 16:06:28 <north1> artok: If you need any help or just don't find time for it just ping me
2019-05-25 16:07:58 <artok> well as the patch is already there, only need to fork'n'stuff =)
2019-05-25 16:14:36 <north1> have fun
2019-05-25 16:29:49 <mps> is the python working on edge? trying to build some firefox/rust pkg's i've got: WARNING: Python.h not found. Install Python development headers.
2019-05-25 16:30:12 <north1> I compiled py3 bindings for zbar on edge
2019-05-25 16:31:06 <mps> firefox have python2 in makedepends
2019-05-25 16:31:17 <north1> python2-dev ?
2019-05-25 16:31:35 <mps> no, bare 'python2'
2019-05-25 16:31:56 <north1> well Python.h is part of $pkgname-dev
2019-05-25 16:32:18 <mps> tried to change to python3 but the result is same
2019-05-25 16:32:33 <north1> try python2-dev then
2019-05-25 16:32:53 <mps> I presume so, but why they changed that :/
2019-05-25 16:33:24 <mps> ofc, I will
2019-05-25 16:35:03 <north1> well firefox build system is uhh
2019-05-25 16:35:04 <north1> special
2019-05-25 16:35:11 <mps> to repeat my morning question with hope that now someone will help: yesterday I lost few hours trying to make vifm, it builds on my working v3.9 box  but fail on lxc edge containers
2019-05-25 16:36:32 <mps> north1: looks like python2-dev helps, no more previous error
2019-05-25 16:37:47 <mps> back to vifm packaging issue: it is relatively simple, but I have problem in package()
2019-05-25 16:38:47 <mps> I can post my APKBUILD and build log, if anyone have time to look at it, to give some hints or help
2019-05-25 16:45:15 <artok> I have edge somewhat up and running, could try
2019-05-25 16:45:29 <TBK[m]> hmm x86, s390x & ppc64le are building is the incorrect order: gdb before gnome-shell... How do I resolve this gordian knot?
2019-05-25 16:46:02 <mps> artok: you answered to me?
2019-05-25 16:47:19 <mps> here is vifm APKBUILD http://tpaste.us/YMjr
2019-05-25 16:47:42 <artok> ..yeah =)
2019-05-25 16:47:49 <mps> just arrived some guests, will be later here
2019-05-25 16:48:44 <artok> ... and patch?
2019-05-25 16:49:03 <artok> if it's needed
2019-05-25 16:54:30 <artok> aaand PR8068
2019-05-25 16:55:35 <_ikke_> TBK[m]: Why does gnome-shell need to be built before gdb?
2019-05-25 16:57:23 <Cogitri> I think s/gdb/gdm/
2019-05-25 16:57:34 <TBK[m]> yes
2019-05-25 17:02:21 <_ikke_> TBK[m]: cyclic dependency
2019-05-25 17:02:33 <_ikke_> gone-shell depends on gdm, and gdm depends on gnome-shell
2019-05-25 17:03:17 <_ikke_> Cogitri: ^
2019-05-25 17:05:26 <Cogitri> Oh, weird, how did that not break in CI :o
2019-05-25 17:06:36 <Cogitri> pr8069
2019-05-25 17:09:45 <Cogitri> Thanks :)
2019-05-25 17:34:34 <_ikke_> TBK[m]: gnome-session probably needs to be disabled on ppc64le as well
2019-05-25 17:34:57 <TBK[m]> yup
2019-05-25 17:35:06 <TBK[m]> need food. Will disable and run to the shop
2019-05-25 17:36:06 <_ikke_> food is good
2019-05-25 17:36:11 <artok> almost good idea... only that 10km to nearest foodstore and
2019-05-25 17:36:19 <artok> ...I already opened wine bottle
2019-05-25 17:37:42 <TBK[m]> I have approx. 80m, so no reason to open a bottle :P
2019-05-25 17:38:23 <artok> you can drink that bottle and walk to the store.. I'm stranded here at countryside, but that's why I'm drunk
2019-05-25 17:38:39 <artok> can't even take moped to the store now =)
2019-05-25 17:39:19 <artok> that's why finnish people are so drunk, many live countryside and nothing to do but drink =)
2019-05-25 17:42:36 <Cogitri> TBK: Thanks for the info
2019-05-25 17:43:13 <TBK[m]> cogitri: np :)
2019-05-25 18:45:07 <_ikke_> sigh, github projects page now crashed twice on me (keeps the tab hanging)
2019-05-25 18:54:18 <TBK[m]> GH performance has been bad lately
2019-05-25 18:54:52 <jwh> TBK[m]: poke :D
2019-05-25 18:54:57 <jwh> PR7984 :D
2019-05-25 19:33:15 <jwh> TBK[m]: re; other arches, I'll push a commit to enable them to see if the build - don't have access to any non-x86 hardware atm and I can't tell if they've fixed it on 32bit (rocksdb expects a 64bit int so it just failed on non-64bit in 2.x)
2019-05-25 19:33:46 <jwh> would be nice if it did work heh
2019-05-25 19:36:34 <jwh> does anyone have s390 (or other platfrms) that are supported but not tested in CI?
2019-05-25 19:36:59 <_ikke_> only ppc64le and s390x are currently not supported by drone.io
2019-05-25 19:38:00 <jwh> oh ok not so bad, is there anyone in here that has either?
2019-05-25 19:38:19 <jwh> unexpected fault address 0x59000000
2019-05-25 19:38:19 <jwh> fatal error: fault
2019-05-25 19:38:20 <jwh> [signal SIGSEGV: segmentation violation code=0x2 addr=0x59000000 pc=0x5692615b]
2019-05-25 19:38:27 <jwh> lol nice, more broken on x86 than it was before
2019-05-25 19:39:57 <jwh> they don't seem to really care about non-64bit, which I guess isn't that unreasonable since most modern hardware is heh
2019-05-25 20:04:54 <artok> well it is
2019-05-25 20:05:19 <jwh> it is to which bit?
2019-05-25 20:05:31 <artok> almost everyone has 64bit system on their pocket
2019-05-25 20:05:34 <jwh> yup
2019-05-25 20:20:31 <jwh> TBK[m]: thx
2019-05-25 20:26:10 <TBK[m]> would be nice if IBM could sponsor some IBM Cloud resources so we could run Drone CI for s390x/ppc64le
2019-05-25 20:26:27 <jwh> yeah
2019-05-25 20:28:21 <Cogitri> Yup
2019-05-25 21:19:24 <mps> Cogitri: is your patch to rust related to adelie linux in some details
2019-05-25 21:19:47 <Cogitri> ?
2019-05-25 21:20:17 <mps> how did you made patches for rust, last two patches
2019-05-25 21:20:58 <mps> did you looked at adelie linux
2019-05-25 21:22:21 <mps> I'm asking because I'm working with adelie linux aport now to make it working on other arch's
2019-05-25 21:23:19 <Cogitri> No, I haven't looked at anything
2019-05-25 21:24:00 <Cogitri> I just rebased the patches
2019-05-25 21:25:26 <Cogitri> Although I'm unsure what "the last two patches" are
2019-05-25 21:25:48 <mps> aha, thanks for info, so it will be easier to just take needed alpine targets from current and add it to adelie for bootstrap
2019-05-25 21:26:19 <mps> didn't you posted upgrades to 1.32 and 1.33
2019-05-25 21:27:01 <Cogitri> Ah, patches == PRs, alright.
2019-05-25 21:27:09 <Cogitri> I posted 1.33 and 1.34, yes
2019-05-25 21:28:14 <mps> ehm, PRs are patches at bottom ;)
2019-05-25 21:28:28 <Cogitri> Anyways, wouldn't it be easier to bootstrap with upstream tarballs?
2019-05-25 21:30:22 <mps> I suspect that is posible
2019-05-25 21:30:53 <Cogitri> <mps "ehm, PRs are patches at bottom ;"> Yup, I just associate patches more with patches for packages than patched for aports :)
2019-05-25 21:31:18 <mps> git is based on patch system
2019-05-25 21:32:00 <mps> I actually tried with upstream tarballs but it is somewhat incomplete
2019-05-25 21:33:06 <Cogitri> Hm, the 1.35 are pretty complete as far as I can see
2019-05-25 21:33:23 <Cogitri> I've been building all my Rust stuff with them for the past weeks
2019-05-25 21:33:50 <mps> you mean, x86_64?
2019-05-25 21:34:54 <Cogitri> On x86_64, yes, but I think they also offer them for other arches now?
2019-05-25 21:35:28 <Cogitri> Anyway, we'll have to crosscompile to get our new triplets in anyway
2019-05-25 21:36:28 <mps> they have tarballs there but I didn't managed to do anything with them
2019-05-25 21:41:16 <mps> Cogitri: I have some progress with adelie rust 1.33 and llvm8 patch you posted and because that I use them, and not of some ideological reasons
2019-05-25 21:41:44 <Cogitri> Uh?
2019-05-25 21:42:59 <mps> don't understand your 'Uh?'
2019-05-25 21:44:32 <mps> ok, I'm tired now, going out to take fresh air, see you later
2019-05-25 21:46:57 <Cogitri> Am a bit confused what the "not of some ideological reasons" is for
2019-05-25 21:47:12 <Cogitri> But I'm a bit tired too, so maybe I'm just a bit dense
2019-05-25 21:48:27 <mps> I had impression that you think I should not use adelie aport, sorry
2019-05-25 21:50:22 <Cogitri> Ah no, use what you like :)
2019-05-25 21:50:45 <Cogitri> If it gets the job done then it's great :P
2019-05-25 21:52:11 <mps> well, I would like most that someone else already done all this, to be honest :)
2019-05-25 22:09:32 <Cogitri> If you don't feel like doing it I wouldn't mind doing it once LLVM8 has been merged
2019-05-25 22:31:39 <jwh> meh, fdisk (busybox fdisk?) in base sucks
2019-05-26 00:26:57 <north1> ikke: new version of atools, makedepend-in-depends added
2019-05-26 02:18:00 <north1> Now that is new, a package that uses ksh for the testsuite
2019-05-26 02:42:47 <north1> can someone merge pr8093 ? it is just a cbindgen rebuild to fix #10488
2019-05-26 03:00:31 <north1> TBK: ty
2019-05-26 09:19:51 <artok> mps you tried vifm already on edge builder?
2019-05-26 09:22:05 <mps> artok: hi, I solved issue last night and pushed it already to testing
2019-05-26 09:22:59 <mps> thought to write to you that but didn't wanted to bother you late at night
2019-05-26 09:23:14 <artok> seems to be working
2019-05-26 09:23:50 <mps> it works on edge, but for some reasons it doesn't on stable in my case
2019-05-26 09:25:13 <mps> I had to add coreutils and mdocml to makedepends because upstream uses features from these tools
2019-05-26 09:26:01 <mps> and, thank you for offering help
2019-05-26 09:29:53 <artok> np
2019-05-26 13:21:51 <_ikke_> TBK[m]: ping
2019-05-26 13:22:19 <TBK[m]> hi
2019-05-26 13:22:38 <_ikke_> fyi, i have a branch with several of the PRs that I marked as ready
2019-05-26 13:22:47 <_ikke_> about to push them
2019-05-26 13:22:50 <TBK[m]> k
2019-05-26 13:23:32 <TBK[m]> Will do something else for a while
2019-05-26 13:24:04 <TBK[m]> did you look into py-opencl ppc64le?
2019-05-26 13:24:11 <_ikke_> No, not yet
2019-05-26 13:24:14 <_ikke_> Just noticed it
2019-05-26 13:27:54 <_ikke_> TBK[m]: ok, pushed
2019-05-26 13:31:50 <_ikke_> TBK[m]: I assume you are looking at it then
2019-05-26 13:31:52 <_ikke_> ?
2019-05-26 13:35:50 <_ikke_> Cogitri: regarding Rust, did you mention something about llvm8 being necessary for 1.34?
2019-05-26 13:37:35 <Cogitri> It's not necessary, but LLVM8 fixes compilation of complex crates (e.g. fractal/gxi) and makes Rust not segfault on some arches
2019-05-26 13:38:00 <Cogitri> Rust 1.34 is the first version to be compatible with LLVM8 though
2019-05-26 13:38:35 <Cogitri> So IMHO we can merge 1.34.2 now and then wait for LLVM8 to be merged to then do 1.35 with more arched and less SIGSEVing :P
2019-05-26 13:38:49 <Cogitri> s/arched/arches/
2019-05-26 13:38:49 <alpine-meetbot> Cogitri meant to say: So IMHO we can merge 1.34.2 now and then wait for LLVM8 to be merged to then do 1.35 with more arches and less SIGSEVing :P
2019-05-26 13:58:47 <Cogitri> Also, I think the default static function might be a bit broken in abuild? If I add `$pkgname-dev` before `$pkgname-static` it breaks (because -dev "steals" the static lib), it works the other way around.
2019-05-26 14:06:03 <Cogitri> And can I get a CI-malfunction (or merge :P) on pr7481? gnome-terminal can't pull in the new vte due abuild issue 53
2019-05-26 14:06:50 <Cogitri> Oh, I thought I had outsmarted the bot by not using `#` but that apparently isn't the case
2019-05-26 14:34:46 <_ikke_> Yes, you need to do -static before -dev
2019-05-26 14:35:17 <_ikke_> default_static just looks in $pkdir, where not static libs are left
2019-05-26 14:36:18 <Cogitri> Yup, but it'd be nice if that didn't happen or it would at least give me a proper error message
2019-05-26 14:36:39 <Cogitri> Maybe dev() could check if static() is a thing and if so run that before it runs itself?
2019-05-26 14:41:52 <_ikke_> Cogitri: building rust now locally
2019-05-26 14:42:23 <Cogitri> Nice, thanks
2019-05-26 15:38:44 <_ikke_> tcely: Is the github project page stable for you? It regularly hangs for me
2019-05-26 15:43:51 <SpaceToast> morning
2019-05-26 15:44:15 <_ikke_> o/
2019-05-26 15:44:43 <_ikke_> Rust 1.34 might be coming soon
2019-05-26 15:44:47 <SpaceToast> I saw :)
2019-05-26 15:45:02 <SpaceToast> sorry I didn't do the docs/git thing yday _ikke_, I just wasn't really functioning... at all :/
2019-05-26 15:45:10 <_ikke_> No worry
2019-05-26 15:45:18 <SpaceToast> if you're ok with it, perhaps in about an hour? :)
2019-05-26 15:45:49 <_ikke_> I might be doing some chores, but I'll I should have some time
2019-05-26 15:46:41 <SpaceToast> alright, ty :)
2019-05-26 16:29:18 <TBK[m]> _ikke_: I am looking at it. It is a bit of a rabbit hole. I will disable ppc64le for now, create a bug issue and continue investigating.
2019-05-26 16:29:41 <north1> cogitri: Yes that is a know problem
2019-05-26 16:29:43 <_ikke_> TBK[m]: right, fine with me
2019-05-26 16:30:41 <north1> https://github.com/alpinelinux/abuild/pull/72 cogitri
2019-05-26 16:33:03 <Cogitri> Ah, alright thanks for the info
2019-05-26 16:33:20 <north1> It will be that way until i happen to find a way to get that merged
2019-05-26 16:43:44 <_ikke_> Is it me or is rust taking longer and longer to compile with newer versions?
2019-05-26 16:43:52 <_ikke_> It's still busy
2019-05-26 16:44:50 <Cogitri> Possibly
2019-05-26 16:52:08 <mps> _ikke_: I agree with your observation about rust
2019-05-26 16:55:33 <_ikke_> It's finally finished
2019-05-26 16:59:23 <mps> when we in this field, I'm for push Cogitri's llvm8 patch, if not to community maybe in testing
2019-05-26 17:13:41 <Cogitri> mps: But Rust is in community...
2019-05-26 17:15:08 <mps> Cogitri: yes, because that I told 'community' and testing as alternative. If it tested in testing it could be easily moved
2019-05-26 17:16:15 <Cogitri> But what's to test?
2019-05-26 17:16:38 <_ikke_> That it builds
2019-05-26 17:16:51 <_ikke_> That it's not blatantly broken
2019-05-26 17:17:22 <mps> Cogitri: is the PR still 7500
2019-05-26 17:17:56 <Cogitri> Yup
2019-05-26 17:18:04 <mps> I would like to try it on armv7, on aarch64 it passed
2019-05-26 17:18:06 <Cogitri> _Ikke_: Doesn't CI verify at least the former?
2019-05-26 17:26:33 <_ikke_> Not on ppc64le and s390x atm
2019-05-26 17:38:47 <_ikke_> north1: pushed v10 of atools and moved it to community while at it :-)
2019-05-26 18:01:19 <north1> nice
2019-05-26 18:02:09 <Cogitri> Ikke: Sure, I can add it to testing
2019-05-26 18:02:53 <_ikke_> It doesn't mean it has to be in testing for a long period
2019-05-26 18:05:24 <Cogitri> Okie
2019-05-26 18:42:32 <north1> _ikke_: 11.1 of atools is out with a rather important fix
2019-05-26 19:05:10 <Cogitri> Changed pr7500 to add it to testing
2019-05-26 19:09:48 <_ikke_> north1: updated :-)
2019-05-26 19:10:02 <TBK[m]> _ikke_: atools: atools-11.1.tar.gz is missing in checksums
2019-05-26 19:10:24 <north1> nice
2019-05-26 19:10:25 <north1> not so nice
2019-05-26 19:10:44 <_ikke_> TBK[m]: yes, fixed already
2019-05-26 20:47:28 <HRio> my is netdata now in unmaintained?
2019-05-26 20:49:26 <HRio> its been updated in alpine every now and then
2019-05-26 20:51:17 <HRio> do we now have a new stricter rule for packages to stay in testing?
2019-05-26 20:58:14 <_ikke_> HRio: It didn't have a maintainer listed
2019-05-26 21:00:24 <hrio[m]> Ok, but I have tried to keep it upto date. But the package felt a biy too complex for me to take full maintainer responibility for...
2019-05-26 21:00:27 <hrio[m]> s/biy/bit/
2019-05-26 21:00:27 <alpine-meetbot> hrio[m] meant to say: Ok, but I have tried to keep it upto date. But the package felt a bit too complex for me to take full maintainer responibility for...
2019-05-26 21:01:17 <north1> _ikke_: 11.2 atools is out, it strips \t before sorting dependencies
2019-05-26 21:01:36 <_ikke_> ok, will update it later
2019-05-26 21:01:49 <north1> some dependencies were separated by tabs and it was causing some duplicates not being detected like pulseaudio having 2 eudev-dev
2019-05-26 21:02:24 <_ikke_> north1: any specific reason you chose to move netdata to unmaintained?
2019-05-26 21:02:38 <north1> _ikke_: It has no maintainer
2019-05-26 21:02:56 <_ikke_> Ok, but no other reason
2019-05-26 21:05:06 <north1> No other reason
2019-05-26 21:11:39 <mps> north1: imo, that shouldn't be reason
2019-05-26 21:12:58 <mps> remember some time one of maintainer removed self as maintainer from a lot of important packages
2019-05-26 21:13:12 <mps> s/some time/some time ago/
2019-05-26 21:13:12 <alpine-meetbot> mps meant to say: remember some time ago one of maintainer removed self as maintainer from a lot of important packages
2019-05-26 21:17:56 <TBK[m]> mps: I can understand both arguments. Moving aports to unmaintained will hopefully get people to come out of the woodwork and adopt aports.
2019-05-26 21:18:29 <north1> mps: How long do i leave it there before moving then ?
2019-05-26 21:19:49 <mps> north1: It depends of the importance and popularity of package, imo
2019-05-26 21:21:39 <hrio[m]> I would prefer if we could keep, stuff in testing that has no formal maintainer. But is still kept up to date by different people caring for the package. But does not have the time available to take maintainer reponsiblity for the package.
2019-05-26 21:21:47 <mps> TBK[m]: I think it is case by case and there are no strict rules. I think it will be better to ask on aports or devel ML, or here or even on #alpine-linux before moving package to unmaintained
2019-05-26 21:23:28 <mps> of course, if there obvious reason then pkg could be moved without waiting because it could be moved back if it later become needed
2019-05-26 21:23:53 <TBK[m]> hmm, guess we could weekly automatic post a list of aports without maintainers...
2019-05-26 21:24:36 <mps> TBK[m]: that would be good, or to have wiki or something else with such list
2019-05-26 21:27:11 <TBK[m]> should be automated otherwise it will have no traction - irc, ml and wiki/docs. Anybody want to write a infra ticket with a proposal?
2019-05-26 21:30:58 <tcely> Cogitri: there is a fix for that pending merge. https://github.com/alpinelinux/abuild/pull/72
2019-05-26 21:31:53 <mps> simple `find main -name APKBUILD | xargs grep 'Maintainer:$' | wc -l` shows 51
2019-05-26 21:32:52 <mps> probably some have duplicate maintainer field, but didn't looked carefully
2019-05-26 21:33:18 <tcely> _ikke_: I have noticed slowness responding to shortcuts on that page
2019-05-26 21:34:09 <Cogitri> tcely: Yup, thank you :)
2019-05-26 22:10:33 <north1> Alpine has no wxgtk3 ?
2019-05-26 22:14:02 <TBK[m]> wxgtk 3.0.4
2019-05-26 22:14:54 <TBK[m]> which is gtk2, so guess that is no
2019-05-26 22:15:05 <north1> Yes that is a no
2019-05-26 23:06:14 <mps> testing/llvm8 builds on armv7 and aarch64
2019-05-26 23:06:36 <mps> I mean pr llvm8 from pr 7500
2019-05-27 08:44:25 <kr0k0> Hi guys
2019-05-27 08:49:59 <mps> kr0k0: hi and good morning
2019-05-27 08:50:23 <kr0k0> Good Morning ^^
2019-05-27 08:51:05 <mps> _ikke_: did you tried to build Cogitri's llvm8 on x86 or x86_64
2019-05-27 08:51:27 <_ikke_> `Not yet
2019-05-27 08:51:59 <mps> aha, ok. I could if you are busy
2019-05-27 08:52:28 <mps> I built it on aarch64 and armv7, it passed build
2019-05-27 08:52:31 <_ikke_> Fine with me
2019-05-27 08:52:33 <_ikke_> Nice
2019-05-27 08:52:58 <mps> ok, then I will do on these two arch's
2019-05-27 08:53:26 <_ikke_> There is also an LLVM patch on pw, did you check that one as well?
2019-05-27 08:54:18 <mps> yes, I sent mail to author but didn't received any answer
2019-05-27 08:54:35 <_ikke_> Right
2019-05-27 08:54:59 <_ikke_> north1 said that the PW one should probably be preferred
2019-05-27 08:55:01 <mps> I presume it is my mistake, I sent mail to ML and not added author to Cc
2019-05-27 08:55:11 <_ikke_> cogitri*
2019-05-27 08:55:58 <mps> aha, north1 could you tell us why this from pw are prefered
2019-05-27 08:57:04 <mps> anyone with main push rights would look to chrony upgrade https://patchwork.alpinelinux.org/patch/4892/
2019-05-27 08:57:28 <mps> and u-boot upgrade https://patchwork.alpinelinux.org/patch/4889/
2019-05-27 08:57:41 <_ikke_> "I guess the patch in the ML will take preference over this."
2019-05-27 08:58:06 <_ikke_> That was Cogitri, not north1
2019-05-27 08:58:53 <mps> didn't noticed this message from him
2019-05-27 08:59:15 <mps> ok, I will try that from pw then
2019-05-27 08:59:34 <_ikke_> That seems more like a statement of fact though
2019-05-27 09:00:05 <Cogitri> Ah, because the thing on PW was opened before my PR.
2019-05-27 09:00:39 <Cogitri> However, the PW patch is about the same as mine, so there's not really a reason not to use mine if you want to
2019-05-27 09:01:32 <mps> Cogitri: _ikke_: ok, I will try to see difference and will decide which one to apply or merge them
2019-05-27 09:02:08 <Cogitri> Well, you've left a comment on the PW thing, didn't you?
2019-05-27 09:02:12 <mps> Cogitri: yes, I noticed your mention of pw in your update to PR
2019-05-27 09:03:14 <mps> but didn't received response from author, I thought he is subscribed to ML but looks like he is not
2019-05-27 09:03:28 <Cogitri> <mps "cogitri: _ikke_: ok, I will try "> That sums up the differences
2019-05-27 09:03:29 <Cogitri> Argh, didn't mean to reply
2019-05-27 09:03:50 <mps> np, :)
2019-05-27 09:10:00 <Cogitri> Ah
2019-05-27 09:10:34 <Cogitri> Well, thanks for the effort all of you put in reviewing :)
2019-05-27 10:34:03 <_ikke_> Are all 3.10 builders now finished with building world?
2019-05-27 10:34:33 <_ikke_> Maybe armv7 not yet
2019-05-27 10:34:47 <_ikke_> yup, that's the last one
2019-05-27 11:16:05 <mps> on edge I got next error: configure: error: *** A compiler with support for C++11 language features is required.
2019-05-27 11:17:08 <mps> gcc/g++ is 8.3.0 is it possible that C++11 not supported
2019-05-27 11:19:59 <Cogitri> No, look at your config.log for more info
2019-05-27 11:20:21 <Cogitri> Sounds like some faulty config check
2019-05-27 11:21:35 <mps> probably, will look later, now building llvm8 on x86_64
2019-05-27 11:49:13 <ncopa> are there anything that requires llvm7 that does not work with llvm8?
2019-05-27 11:50:52 <mps> maybe rust 1.33 I think. Cogitri know better
2019-05-27 11:57:24 <mps> ncopa: I'm testing and preparing llvm8 to push it testing. do you agree
2019-05-27 12:01:32 <ncopa> if it makes it possible to remove one older llvm version
2019-05-27 12:02:07 <ncopa> we now have llvm{5,6,7}
2019-05-27 12:02:26 <ncopa> and llvm3.9 apparently
2019-05-27 12:03:17 <mps> afaik we can only replace llvm7 with llvm8, llvm3.9 and llvm5 are in dependencies for some packages
2019-05-27 12:03:39 <Cogitri> We can remove 5, yes
2019-05-27 12:03:46 <Cogitri> But at least in Void we still needed the others
2019-05-27 12:04:10 <mps> Cogitri: crystal depends on llvm5
2019-05-27 12:04:20 <ncopa> julia and ponyc seems to depend on llvm3.9
2019-05-27 12:05:14 <ncopa> crystal, firefox-esr and ghc currently uses llvm5
2019-05-27 12:06:51 <mps> could we have llvm7 and llvm8 both and after what depends on llvm7 upgraded to llvm8 then remove llvm7
2019-05-27 12:07:39 <mps> i know it is a mess to some degree but have no better idea
2019-05-27 12:08:17 <Cogitri> Look at void for patches for julia and ponyc iirc
2019-05-27 12:08:31 <Cogitri> I did the llvm7 bump and am pretty sure that both of those either use 6 or 7
2019-05-27 12:08:55 <Cogitri> Crystal can use 7 too IIRC
2019-05-27 12:08:56 <Cogitri> Dunno about ghc
2019-05-27 12:09:11 <ncopa> julia requires patched llvm
2019-05-27 12:09:20 <ncopa> which is not recommended for system llvm
2019-05-27 12:09:43 <mps> I tried to build crystal with llvm7 but it didn't worked
2019-05-27 12:10:19 <mps> I can try again to see if it could work now
2019-05-27 12:11:09 <mps> but think it is better to use llvm6 for crystal because llvm7 is not in good shape
2019-05-27 12:11:19 <Cogitri> I.. don't think so?
2019-05-27 12:11:21 <Cogitri> Ah, nevermind, Void uses the vendored llvm
2019-05-27 12:11:50 <mps> do void have crystal pkg
2019-05-27 12:12:17 <mps> musl version, I mean
2019-05-27 12:12:42 <Cogitri> Yup, with llvm6 I think
2019-05-27 12:13:22 <mps> ok, will look. last time I looked it wasn't there
2019-05-27 12:16:16 <mps> hm, I see only glibc crystal on https://voidlinux.org/packages/, not musl
2019-05-27 12:33:13 <_ikke_> TBK[m]: thanks for fixing nnn
2019-05-27 12:36:26 <TBK[m]> pretty strange that the src got pulled :/
2019-05-27 12:39:34 <_ikke_> yup
2019-05-27 12:45:40 <HRio> regardning nnn https://github.com/jarun/nnn/commit/5ea8218e4f85336f092fefe077af21673ed6beb5#commitcomment-33685105
2019-05-27 12:47:12 <_ikke_> HRio: thanks
2019-05-27 12:59:45 <artok> tcely: did changes
2019-05-27 12:59:54 <artok> tcely: PR8068 that is
2019-05-27 13:28:02 <tcely> artok: why is gawk used instead of busybox awk?
2019-05-27 13:34:12 <artok> tcely: actually I didn't even test out if it could go with busybox awk
2019-05-27 13:34:47 <artok> basically
2019-05-27 13:35:31 <artok> I just added diff that I saw from libgpg-error upstream repo
2019-05-27 13:36:20 <tcely> Well, patching for a version of awk that is not installed during the build doesn't make a lot of sense.
2019-05-27 13:37:16 <artok> um.. I installed plain alpine, added alpine-sdk and hit abuild -R on that folder... without it, gawk errors =)
2019-05-27 13:38:18 <artok> but now that you say it...
2019-05-27 13:40:02 <artok> that came up from some other package build deps
2019-05-27 13:40:45 <tcely> Try abuild -r
2019-05-27 13:41:05 <TBK[m]> _ikke_: ping pr8171
2019-05-27 13:49:39 <_ikke_> TBK[m]: pong
2019-05-27 13:58:42 <mps> do we need -openrc subpkg for iptables, there is iptables.initd but no iptables-openrc subpkg
2019-05-27 14:00:13 <tcely> mps: link?
2019-05-27 14:00:18 <_ikke_> probably
2019-05-27 14:01:02 <mps> tcely: aports/main/iptables
2019-05-27 14:01:36 <tcely> Yes, it looks like -openrc would be useful
2019-05-27 14:02:00 <mps> _ikke_: I'm preparing upgrade to 1.8.2, should I add -openrc subpkg
2019-05-27 14:02:06 <tcely> https://github.com/alpinelinux/aports/blob/727dd90de36a24ad2173b385de9a04cb98f04330/main/iptables/APKBUILD#L65
2019-05-27 14:03:02 <tcely> mps: yes, just add it to subpackages. That should be enough.
2019-05-27 14:03:06 <TBK[m]> it would need two openrc subpkgs one for iptables and one for ip6tables
2019-05-27 14:04:28 <tcely> Ugh. ip6tables needs a custom function.
2019-05-27 14:06:38 <mps> algitbot did you detected hash collision?
2019-05-27 14:07:11 <_ikke_> mps: probably ambigious abbreviation
2019-05-27 14:07:39 <tcely> No. Just the tip of master.
2019-05-27 14:08:21 <_ikke_> right
2019-05-27 14:08:41 <mps> aha, ok.
2019-05-27 14:08:44 <tcely> algitbot should really ignore URL
2019-05-27 14:16:08 <mps> finished iptables and posted to https://patchwork.alpinelinux.org/patch/4894/
2019-05-27 14:16:23 <mps> anyone would take some time to review it
2019-05-27 14:51:56 <tcely> mps: pr8176
2019-05-27 14:53:32 <mps> tcely: aha, ok. can you push it
2019-05-27 14:54:04 <tcely> mps: it's not passing CI yet
2019-05-27 14:54:24 <mps> heh, it passed my local lxc
2019-05-27 14:55:01 <mps> I think your fixes will not break anything
2019-05-27 14:56:54 <tcely> I forgot to change local paths to absolute paths for one thing ;-)
2019-05-27 14:59:59 <tcely> That's better. https://cloud.drone.io/alpinelinux/aports/5545
2019-05-27 15:03:09 <mps> these drones are nice thing. maybe I should learn github to use them
2019-05-27 15:05:07 <tcely> mps: yes, very handy to have CI on more than a single architecture
2019-05-27 15:31:25 <_ikke_> HRio: I adopted netdata for now, it's back in testing
2019-05-27 15:39:12 <z3ntu> Could someone please look at https://github.com/alpinelinux/aports/pull/5319 ?
2019-05-27 15:39:21 <z3ntu> It's been open since October
2019-05-27 15:40:41 <_ikke_> z3ntu: checking
2019-05-27 15:41:21 <z3ntu> It needs a patch from the mailing list merged before (linked in one of the last comments)
2019-05-27 15:42:00 <_ikke_> ok
2019-05-27 15:43:55 <_ikke_> I do get merge conflicts after those patches though
2019-05-27 15:45:00 <_ikke_> z3ntu: https://tpaste.us/jX6v
2019-05-27 15:46:05 <z3ntu> In April it still worked for me
2019-05-27 15:47:21 <_ikke_> THis patch does the same thing your PR does? https://patchwork.alpinelinux.org/patch/4643/
2019-05-27 15:48:10 <z3ntu> _ikke_: no, that patch is for lttng-ust and my PR is for lttng-tools
2019-05-27 15:49:11 <z3ntu> https://patchwork.alpinelinux.org/patch/4693/ is one which is more or less my PR I think
2019-05-27 15:49:32 <_ikke_> Sorry, yes, I meant that one
2019-05-27 15:50:41 <_ikke_> So if I would apply those two patches, yours would be redundant
2019-05-27 15:51:09 <HRio> ikke: big thanks!
2019-05-27 15:51:45 <z3ntu> except that the mailing list patch doesn't remove the old patch file
2019-05-27 15:51:45 <_ikke_> np
2019-05-27 15:51:47 <z3ntu> I'm not 100% sure about the util-linux checkdepend but at some point there was some command used in the test that's provided by util-linux
2019-05-27 15:52:08 <_ikke_> ok
2019-05-27 15:52:52 <z3ntu> _ikke_: yeah (but don't forget to remove the patch file I mentioned) - but my PR was created earlier than the patch on the ML ;)
2019-05-27 15:53:23 <z3ntu> it's your decision, I just want this change to be merged
2019-05-27 15:55:25 <_ikke_> building it now
2019-05-27 15:56:09 <_ikke_> Is lttng-ust necessary before lttng-tools?
2019-05-27 15:56:41 <_ikke_> I got to go, back later
2019-05-27 15:57:16 <z3ntu> _ikke_: otherwise the test suite of lttng-tools won't succeed
2019-05-27 16:09:26 <otlabs> hi ppl
2019-05-27 16:09:50 <SpaceToast> hey otlabs
2019-05-27 16:10:04 <otlabs> SpaceToast: how are you
2019-05-27 16:10:23 <SpaceToast> quite tired, wasn't functional at all saturday, and still recovering (taking today and tomorrow off :) )
2019-05-27 16:10:47 <otlabs> get well soon!
2019-05-27 16:12:23 <SpaceToast> :)
2019-05-27 16:12:48 <SpaceToast> if you want, we can try and figure out the k3s situation in an hour or two (I have to go to the store, all the liquids in my fridge seem to have gone bad for some reason)
2019-05-27 16:13:08 <otlabs> with pleasure
2019-05-27 16:13:22 <SpaceToast> okay, I'll PM you once I'm ready?
2019-05-27 16:14:09 <otlabs> please
2019-05-27 16:14:52 <otlabs> meanwhile I will ask for some help with pr8021
2019-05-27 16:15:32 <otlabs> could you please take a look on it? what can be done to make it better?
2019-05-27 16:17:08 <SpaceToast> is it specific to python3?
2019-05-27 16:17:25 <otlabs> this PR will form part of massive PR for spaCy Natural Language Processing Python package. I had some issues with py3-pytest-timeout, hope they are solved now
2019-05-27 16:17:35 <SpaceToast> ddevault wrote this up, iirc: https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-05-27 16:17:43 <SpaceToast> I'd try and orient close to whatever's in there
2019-05-27 16:17:56 <otlabs> I hope I did
2019-05-27 16:19:07 <PureTryOut[m]> About Python... What are the plans for Python 2? Upstream support for it is running out and more and more distros are removing it from their repos. Is Alpine planning on doing this soon too?
2019-05-27 16:19:22 <ddevault> yes, there are some plans for removing it soon
2019-05-27 16:19:24 <SpaceToast> the readme thing is kind of unfortunate
2019-05-27 16:19:34 <SpaceToast> it seems to be all the docs they have, but it also contains a changelog...
2019-05-27 16:19:36 <ddevault> there was some confusion around establishing teams that blocked that workstream
2019-05-27 16:19:39 <ddevault> been meaning to try and sort that out
2019-05-27 16:20:31 <SpaceToast> also I think depends can be *just* py3-pytest (dropping the explicit python3)
2019-05-27 16:20:48 <SpaceToast> I remember we at least check some shebangs and co, but even if we don't autodetect python, py3-pytest should pull it in
2019-05-27 16:20:58 <otlabs> SpaceToast: ok, let me check that
2019-05-27 16:21:46 <PureTryOut[m]> ddevault: ah thanks for your answer
2019-05-27 16:21:47 <PureTryOut[m]> I guess it would be nice for new aports to already forbid python 2 support I guess
2019-05-27 16:21:49 <SpaceToast> it's also a bit weird that you install into a temporary directory to run tests
2019-05-27 16:21:52 <SpaceToast> besides that I've got nothing :)
2019-05-27 16:22:03 <ddevault> PureTryOut[m]: yeah I would appreciate new packages only supporting py3
2019-05-27 16:23:09 <otlabs> SpaceToast: yep, the technique to run tests from temporary install directory s weird, I got it from another package but it is the only way ta make them run so far. I was unable to make work another suggestion I got.
2019-05-27 16:23:40 <TBK[m]> I was assuming this was already policy. I for one do not accept new aports that support py2.
2019-05-27 16:23:43 <SpaceToast> what about the excerpt from the python package policies wiki page?
2019-05-27 16:24:05 <p4Wv1qn095FW> what about big things like gnuradio that is still py2 only?
2019-05-27 16:24:47 <otlabs> python3 setup.py test? As I remember it was not working, I can re-check
2019-05-27 16:24:53 <ddevault> we'll deal with those on a case-by-case basis
2019-05-27 16:25:13 <ddevault> once python 2 is officially EoL, gnuradio will probably be removed if they haven't caught up yet
2019-05-27 16:25:52 <ddevault> though if they have a concrete plan and are working on python 3... I wouldn't necessarily be a hardass about it
2019-05-27 16:26:26 <p4Wv1qn095FW> they are working on py3 support, but it is a monster
2019-05-27 16:27:54 <ddevault> wait, alpine doesn't even have gnu radio
2019-05-27 16:28:06 <ddevault> problem solved :)
2019-05-27 16:28:17 <otlabs> SpaceToast: dropped python3 from depends, all ok
2019-05-27 16:31:32 <p4Wv1qn095FW> ddvault it exists in user repos
2019-05-27 16:32:11 <ddevault> that's not really something I consider meaningful
2019-05-27 16:32:58 <p4Wv1qn095FW> others might disagree
2019-05-27 16:35:06 <mps> p4Wv1qn095FW: I agree. there will be software which will not be upgraded in near future and people depends on that old software
2019-05-27 16:36:07 <PureTryOut[m]> You can't keep unmaintained software around just because some user repos might require it. These repos can package what they need themselves
2019-05-27 16:39:11 <p4Wv1qn095FW> that sounds a bit like victim blaming
2019-05-27 16:41:14 <p4Wv1qn095FW> these are stuck between a rock and a hard place i mean. it's not their choice, they are at the mercy of the python/alpine/3rdparty devs
2019-05-27 16:42:51 <otlabs> SpaceToast: with 'python3 setup.py test' there is no luck as testing is not implemented in setup.py, re-checking old suggestions now...
2019-05-27 16:43:09 <otlabs> north1: are you around?
2019-05-27 16:43:31 <Cogitri> If they want support from the Alpine devs they'll need to have it in the Alpine repos
2019-05-27 16:43:34 <SpaceToast> otlabs: usually, the test command under setup.py just runs pytest in the srcdir
2019-05-27 16:43:52 <Cogitri> Making sure that no user repo breaks sounds like hell tbh
2019-05-27 16:44:14 <otlabs> SpaceToast: that part is not implemented in setup.py
2019-05-27 16:44:30 <otlabs> https://bitbucket.org/pytest-dev/pytest-timeout/src/default/setup.py
2019-05-27 16:44:38 <SpaceToast> otlabs: again, I'm telling you that the typical implementation is to just run pytest in the srcdir -> this means that *you* can do that yourself
2019-05-27 16:44:53 <SpaceToast> cd $srcdir && pytest --disable-my-things
2019-05-27 16:45:30 <otlabs> Oh, I have also tested that
2019-05-27 16:45:45 <otlabs> It produces massive tests fail
2019-05-27 16:45:56 <otlabs> let me push it to show you some logs
2019-05-27 16:45:58 <SpaceToast> well, so does the status quo, no?
2019-05-27 16:46:02 <SpaceToast> ok, let's see
2019-05-27 16:49:10 <otlabs> https://cloud.drone.io/alpinelinux/aports/5553
2019-05-27 16:49:35 <SpaceToast> otlabs: I think you misunderstand - you are running the tests in builddir, I'm saying to run them from inside of srcdir, without any PYTHONPATH modifications
2019-05-27 16:49:58 <SpaceToast> I'd test it myself imminently but I'm still not quite back from the store
2019-05-27 16:50:09 <otlabs> oh, sorry, let me try that
2019-05-27 16:51:46 <otlabs> Same tests fail
2019-05-27 16:51:59 <otlabs> Will push it to show the log
2019-05-27 16:57:41 <SpaceToast> hm, perhaps it wants a dev install?
2019-05-27 16:57:53 <SpaceToast> trying to remember how that's done
2019-05-27 16:58:40 <SpaceToast> otlabs: can you try adding py3-pip to checkdepends and running `pip install -e` inside of srcdir before running pytest-3?
2019-05-27 16:58:51 <SpaceToast> if that fails the same way I'll accept defeat (for today)
2019-05-27 17:10:33 <ncopa> I have fix for perl
2019-05-27 17:10:48 <ncopa> that does not require rebuild of 217 packages
2019-05-27 17:11:01 <ncopa> with some help from dalias ofc
2019-05-27 17:13:15 <_ikke_> \o/
2019-05-27 17:13:58 <_ikke_> just out of curiosity, what makes the difference between having to rebuild those packages or not?
2019-05-27 17:17:38 <ncopa> we dont modify the perl.h file
2019-05-27 17:17:48 <mps> I followed your discussion, nice that you found 'proper' solution
2019-05-27 17:17:56 <ncopa> the #ifdef .....
2019-05-27 17:18:21 <ncopa> which potentially may result in different binary
2019-05-27 17:18:49 <ncopa> i would guess that most packages would work but there may have been a couple that broke
2019-05-27 17:19:34 <ncopa> so it was urxvt and postgresql
2019-05-27 17:19:39 <ncopa> was there other package affected by it?
2019-05-27 17:19:51 <mps> gimp, also in my test
2019-05-27 17:20:12 <ncopa> runtime or build time?
2019-05-27 17:20:17 <mps> build
2019-05-27 17:21:21 <p4Wv1qn095FW> spamassassin was also affected i think
2019-05-27 17:23:18 <ncopa> can you test?
2019-05-27 17:27:03 <Mo0O> Hi there
2019-05-27 17:28:08 <Cogitri> Hello
2019-05-27 17:28:51 <Mo0O> I've just made a PR to upgrade community/cabal to 2.4.1.0 https://github.com/alpinelinux/aports/pull/8177 in this PR I've removed a lot of line which where intended to download cabal dependencies in order to let cabal bootstrap script handle this part
2019-05-27 17:29:12 <otlabs> SpaceToast: last log is here https://cloud.drone.io/alpinelinux/aports/5554
2019-05-27 17:29:15 <Mo0O> Do you think it's a good/bad idea? if bad, why?
2019-05-27 17:29:29 <SpaceToast> otlabs: that doesn't implement the final suggestion, does it?
2019-05-27 17:29:29 <otlabs> let me try your suggestions, sorry, was away
2019-05-27 17:29:34 <SpaceToast> no worries
2019-05-27 17:29:40 <otlabs> SpaceToast: does not
2019-05-27 17:29:45 <Mo0O> I mean, in my point of view it is more KISS to do it that way
2019-05-27 17:30:06 <otlabs> SpaceToast: I will try them right now with 'py3-pip'
2019-05-27 17:30:22 <SpaceToast> otlabs: and using `pip3 install -e` before `pytest-3` inside of srcdir, yes
2019-05-27 17:30:48 <SpaceToast> Mo0O: I think it's a good idea, but you'd ultimately need to talk to the maintainer
2019-05-27 17:31:37 <Mo0O> that make sense, I'm going to ping him in the PR
2019-05-27 17:31:45 <Mo0O> SpaceToast: thanks for your feedback
2019-05-27 17:33:18 <Mo0O> cool, looks like somebody was quicker than me
2019-05-27 17:34:18 <TBK[m]> ;)
2019-05-27 17:34:25 <Mo0O> :)
2019-05-27 17:51:30 <SpaceToast> otlabs: no I really do mean *literally* "pip install -e"
2019-05-27 17:51:32 <SpaceToast> no other arguments
2019-05-27 17:51:37 <SpaceToast> no prefix no nothing
2019-05-27 17:52:12 <otlabs> Ok, give me another chance, please ;)
2019-05-27 17:53:34 <otlabs> building locally pip complains about missing argument for '-e'
2019-05-27 17:53:44 <SpaceToast> oh right, argument should be "."
2019-05-27 17:53:55 <otlabs> great!
2019-05-27 17:54:29 <SpaceToast> so literally `pip install -e .`
2019-05-27 17:54:33 <SpaceToast> (from within srcdir :) )
2019-05-27 17:54:49 <otlabs> pip complains now about missing setup.py
2019-05-27 17:55:02 <SpaceToast> setup.py can't be missing
2019-05-27 17:55:06 <SpaceToast> it's right there in srcdir, right?
2019-05-27 17:55:11 <SpaceToast> let me see
2019-05-27 17:55:16 <Mo0O> what's this python module?
2019-05-27 17:55:25 <SpaceToast> Mo0O: pytest-timeout
2019-05-27 17:55:26 <Mo0O> (I'm curious :$)
2019-05-27 17:55:27 <otlabs> it is in $builddir I think
2019-05-27 17:55:52 <SpaceToast> oh, right, sorry
2019-05-27 17:55:58 <SpaceToast> still, let me get my builder up
2019-05-27 17:56:04 <SpaceToast> see if I can figure it out
2019-05-27 17:56:19 <otlabs> quite appreciated
2019-05-27 17:56:45 <otlabs> I need to use this trick in several modules so it would be great to have a second opinion about it
2019-05-27 18:00:05 <SpaceToast> ah it wants a virtualenv
2019-05-27 18:00:07 <SpaceToast> I see
2019-05-27 18:00:21 <SpaceToast> do keep holding on :)
2019-05-27 18:02:18 <Mo0O> I don't understand why you want to install pytest-timeout using dev mode
2019-05-27 18:02:54 <SpaceToast> because tests fail, and the suggested alternative is "install it into a custom prefix and edit pythonpath to point to that prefix while running tests"
2019-05-27 18:03:12 <SpaceToast> if that'll be happening, I'd rather contain it to dev mode, seems cleaner
2019-05-27 18:04:04 <Mo0O> you're are trying to create an alpine pkg for pytest-timeout so
2019-05-27 18:04:15 <Mo0O> what's the traceback?
2019-05-27 18:04:37 <SpaceToast> https://cloud.drone.io/alpinelinux/aports/5554
2019-05-27 18:05:45 <SpaceToast> anyway, looks like even with venv (with system-site-packages etc) the same tests fail
2019-05-27 18:05:52 <SpaceToast> and I don't care enough about not-my-package-anyway
2019-05-27 18:08:31 <otlabs> SpaceToast: :)
2019-05-27 18:09:01 <Mo0O> `pytest.py: error: unrecognized arguments: --timeout=1`
2019-05-27 18:09:59 <SpaceToast> yes, which is weird
2019-05-27 18:10:37 <Mo0O> which version of pytest-timeout it is?
2019-05-27 18:10:59 <Mo0O> I've found the PR
2019-05-27 18:19:24 <Mo0O> SpaceToast: the test run the following command: `/usr/bin/python3 -mpytest...` while I supose the module is named `pytest-3` in your case, so it should be `-mpytest-3` imho
2019-05-27 18:20:30 <SpaceToast> well, it's not like we're specifying the "-mpytest" bit...
2019-05-27 18:20:38 <SpaceToast> and why it changes based on installation type is unclear
2019-05-27 18:24:41 <Mo0O> I know
2019-05-27 18:24:50 <Mo0O> just pointing it
2019-05-27 18:27:16 <otlabs> should I install pytest instead of py3-pytest ?
2019-05-27 18:27:30 <Mo0O> no, will no be compatible
2019-05-27 18:27:33 <SpaceToast> that shouldn't change anything...
2019-05-27 18:27:40 <otlabs> ok, thanks
2019-05-27 18:27:44 <SpaceToast> what's weird is that using `tox -e python3.7` does not cause the failures
2019-05-27 18:27:53 <SpaceToast> (but has no way to skip the expected failures, afaik)
2019-05-27 18:28:55 <SpaceToast> aha, hold on
2019-05-27 18:29:22 <SpaceToast> otlabs: I think I got it
2019-05-27 18:29:31 <SpaceToast> let me clean it up and make it presentable etc. and I'll send you a thing
2019-05-27 18:29:43 <otlabs> wow!
2019-05-27 18:29:46 <SpaceToast> I'm not very comfortable, since I still don't understand why it is different
2019-05-27 18:29:51 <SpaceToast> but... eh?
2019-05-27 18:30:08 <otlabs> sure!
2019-05-27 18:34:19 <SpaceToast> otlabs: https://brpaste.xyz/3_fPIA?python (https://brpaste.xyz/raw/3_fPIA)
2019-05-27 18:34:35 <otlabs> thanks!
2019-05-27 18:35:18 <SpaceToast> wrong highlighter but w.e ^^;;
2019-05-27 18:35:32 <SpaceToast> I suppose tox is wiser than either of us :)
2019-05-27 18:37:40 <SpaceToast> it might make sense to disable failures on missing envs instead of hardcoding python3.7
2019-05-27 18:37:46 <SpaceToast> but that should be fairly straightforward
2019-05-27 18:38:48 <otlabs> I very unfamiliar with tox, need to extend my knowledge to fully understand what you are talking about envs
2019-05-27 18:39:06 <SpaceToast> tox can check against multiple python versions
2019-05-27 18:39:19 <SpaceToast> in this configuration, I think it tests python 2.7, and 3.4 up
2019-05-27 18:39:39 <SpaceToast> I set it to only test 3.7 (what we have now), but it has an alternative flag that simply doesn't cause failures when a python version is missing
2019-05-27 18:44:32 <otlabs> ok, thanks
2019-05-27 18:57:18 <north1> otlabs: i am now
2019-05-27 18:57:59 <otlabs> north1: great! glad to see you! could you please the new tox solution for pr8021?
2019-05-27 18:58:09 <otlabs> check
2019-05-27 18:58:11 <SpaceToast> also the extra \t is weird under check
2019-05-27 18:58:15 <SpaceToast> it's indented a whole extra level
2019-05-27 18:59:35 <otlabs> 
ACTION hides in the bushes

2019-05-27 19:00:13 <SpaceToast> otlabs: have you checked if using `-s true` in place of `-e python3.7` works?
2019-05-27 19:00:23 <SpaceToast> I'd imagine that'd be preferable, if possible :) (for when py3.8 comes out)
2019-05-27 19:00:39 <otlabs> I will
2019-05-27 19:02:32 <otlabs> It permits to build the package but do not run any tests
2019-05-27 19:03:18 <otlabs> I get 5 skipped messages for py27, py35, py36, pypy, and pypy3
2019-05-27 19:03:47 <SpaceToast> but there's also py37
2019-05-27 19:03:54 <SpaceToast> no?
2019-05-27 19:04:13 <SpaceToast> hah, no
2019-05-27 19:04:13 <otlabs> Let me re-check
2019-05-27 19:04:18 <SpaceToast> tox.ini skips 37
2019-05-27 19:04:23 <SpaceToast> oh well, -e python3.7 it is :(
2019-05-27 19:04:41 <otlabs> oh
2019-05-27 19:04:50 <SpaceToast> that's silly though
2019-05-27 19:05:23 <_ikke_> z3ntu: ping
2019-05-27 19:05:43 <otlabs> north1: thank you
2019-05-27 19:05:49 <z3ntu> still here
2019-05-27 19:06:00 <_ikke_> When I run the tests, it seems to hang
2019-05-27 19:06:12 <_ikke_> PASS: tools/notification/test_notification_ust 94 - Subscribe to a condition for which subscription was already done
2019-05-27 19:06:12 <otlabs> SpaceToast: now I got your message on github
2019-05-27 19:08:37 <z3ntu> _ikke_:  with the new lttng-ust?
2019-05-27 19:08:38 <z3ntu> worked the last time I tried :(
2019-05-27 19:09:48 <_ikke_> Hmm, no, it seems to have installed the older version
2019-05-27 19:11:53 <_ikke_> weird
2019-05-27 19:12:07 <_ikke_> ah,
2019-05-27 19:12:49 <_ikke_> trying again
2019-05-27 19:12:57 <_ikke_> lttng-ust is in main, so I cannot push it myself
2019-05-27 19:21:39 <_ikke_> even with the latest lttng-ust, it seems to still hang at the same test
2019-05-27 19:24:16 <_ikke_> z3ntu: ah, that might be the util-linux dep you added
2019-05-27 19:25:11 <_ikke_> it's trying to find taskset
2019-05-27 19:27:21 <ncopa> PRs are down to 315
2019-05-27 19:29:15 <_ikke_> \o/\o/\o/
2019-05-27 19:30:52 <_ikke_> ncopa: Can you potentially apply a patch set for me in a moment?
2019-05-27 19:30:59 <_ikke_> it's 2 patches from PW combined with one PR
2019-05-27 19:31:11 <_ikke_> one is in main
2019-05-27 19:33:53 <_ikke_> z3ntu: now I get actual test failures :(
2019-05-27 19:36:54 <SpaceToast> heya _ikke_ :)
2019-05-27 19:37:05 <SpaceToast> do you have any objections to me modernizing/improving openrc for salt-master/salt-minion?
2019-05-27 19:37:22 <SpaceToast> probably won't happen right away, but I'd like to ask preemptively so as to not worry about it later
2019-05-27 19:37:24 <_ikke_> SpaceToast: No, feel free
2019-05-27 19:37:27 <SpaceToast> alright ^^
2019-05-27 19:37:43 <SpaceToast> one of my long-term goals for alpine is to improve the state of service scripts all over, starting with the ones I actually use :)
2019-05-27 19:41:02 <_ikke_> z3ntu: https://tpaste.us/baeD
2019-05-27 19:42:10 <ncopa> _ikke_: sure. which?
2019-05-27 19:42:44 <_ikke_> ncopa: Tests are failing atm, so it's not fit yet
2019-05-27 19:43:01 <ncopa> ok. ping me when its ready
2019-05-27 19:43:09 <_ikke_> will do
2019-05-27 19:45:00 <_ikke_> is GLOB_ONLYDIR something from glibc? libblockdev is failing on s390x due to it missing
2019-05-27 19:45:21 <_ikke_> https://github.com/kraj/meta-openwrt/blob/master/recipes-core/fstools/files/0001-Define-GLOB_ONLYDIR-if-not-available.patch
2019-05-27 19:45:24 <_ikke_> seems to indicate so
2019-05-27 19:45:51 <z3ntu> _ikke_: or just deactivate the tests, I really don't care about whether they run or not :/
2019-05-27 19:46:08 <_ikke_> z3ntu: alpine does
2019-05-27 19:46:25 <_ikke_> And usually failing tests mean something is broken
2019-05-27 19:47:04 <z3ntu> Well actually the package that had this dependency isn't even used anymore by postmarket, so I really don't care at all anymore. Do what you want ;)
2019-05-27 19:48:24 <_ikke_> hmmm
2019-05-27 20:09:57 <PureTryOut[m]> Would `arch="noarch !armhf"` work?
2019-05-27 20:10:21 <_ikke_> Yes, it should
2019-05-27 20:10:28 <_ikke_> I've used it before
2019-05-27 20:12:18 <PureTryOut[m]> Ok thanks
2019-05-27 20:14:17 <ncopa> less than 300 PRs
2019-05-27 20:14:20 <ncopa> good night!
2019-05-27 20:15:11 <_ikke_> ncopa: time for one last patch?
2019-05-27 20:15:22 <_ikke_> to fix libblockdev?
2019-05-27 20:15:27 <ncopa> i just left... :)
2019-05-27 20:15:28 <ncopa> sure
2019-05-27 20:15:58 <_ikke_> https://tpaste.us/7vYL
2019-05-27 20:17:00 <_ikke_> ncopa: thanks, good night
2019-05-27 20:34:31 <SpaceToast> _ikke_: by the way, you might be interested in https://github.com/saltstack/salt/issues/53244
2019-05-27 20:36:32 <_ikke_> sounds like it should be easy to fix
2019-05-27 20:37:04 <SpaceToast> I hope so :)
2019-05-27 20:37:09 <SpaceToast> I also hope it gets backported
2019-05-27 20:37:27 <SpaceToast> (would be a shame if I couldn't use my shiny new minio instance for static file storage for my salt masters, eh? :) )
2019-05-27 20:37:34 <_ikke_> is this a python3.7 issue
2019-05-27 20:37:45 <_ikke_> ?
2019-05-27 20:38:06 <SpaceToast> I think it's a python3.7 compatibility thing, yeah
2019-05-27 21:39:46 <tmhoang> _ikke_ : Ah Kevin thanks for checking out libblockdev. I just figured that GLOB_ONLYDIR could be defined as a bogus since it's just an optimization that musl would ignore
2019-05-27 21:40:14 <tmhoang> https://tpaste.us/7vYL -> lgtm
2019-05-27 21:40:59 <tmhoang> should've checked -devel channel first
2019-05-27 22:19:31 <mps> llvm8 failed build tests on x86 in lxc contaniner. which doesn't mean it is bad but could be lxc container issue
2019-05-27 22:19:54 <SpaceToast> mps: where could I get the sources for building it?
2019-05-27 22:20:11 <mps> PR 7500
2019-05-27 22:20:15 <SpaceToast> I can test in my container that actually is running all of the stuff (that try to avoid container-related failures)
2019-05-27 22:20:24 <SpaceToast> is there an easy way for me to just plop that in?
2019-05-27 22:20:46 <SpaceToast> (asking you since you've clearly done it :) )
2019-05-27 22:20:57 <mps> I download it as patch and 'git am 7500.patch'
2019-05-27 22:21:28 <SpaceToast> ah so https://github.com/alpinelinux/aports/pull/7500.patch
2019-05-27 22:21:30 <SpaceToast> ty
2019-05-27 22:21:31 <mps> https://patch-diff.githubusercontent.com/raw/alpinelinux/aports/pull/7500.patch
2019-05-27 22:21:40 <SpaceToast> the one I posted works too :)
2019-05-27 22:21:58 <mps> yes, second one is redirect, I think
2019-05-27 22:22:33 <SpaceToast> the PR has a comment requesting a chance
2019-05-27 22:22:40 <SpaceToast> but I'll see if anything happens first
2019-05-27 22:23:24 <mps> I built it on x86_64, aarch64 and armv7, it worked on these arch's
2019-05-27 22:23:47 <SpaceToast> tcely: is suggesting "Fix filesystem test patch"
2019-05-27 22:23:52 <SpaceToast> guessing a patch is broken or something
2019-05-27 22:23:58 <SpaceToast> so weird that it passes
2019-05-27 22:24:08 <mps> failed on x86 with some segfaults, but that is usual on my x86 lxc
2019-05-27 22:24:43 <PureTryOut[m]> Why was aarch64 for gjs disabled? It builds perfectly fine https://git.alpinelinux.org/aports/commit/testing/gjs?id=b31e59f7a01e2a96778fffd5cd17f672bee78e26
2019-05-27 22:25:13 <SpaceToast> ping Cogitri re: PureTryOut[m]'s question
2019-05-27 22:26:07 <SpaceToast> ah, looking at llvm8
2019-05-27 22:26:08 <Cogitri> I think it failed on CI and I didn't really have means to test it via other means back then
2019-05-27 22:26:09 <SpaceToast> most patches have offsets
2019-05-27 22:26:18 <SpaceToast> and one patch has fuzz
2019-05-27 22:26:21 <SpaceToast> two, in fact
2019-05-27 22:26:22 <Cogitri> Feel free to enable it again if it works
2019-05-27 22:26:26 <SpaceToast> I'll try and fix both
2019-05-27 22:26:36 <Cogitri> I don't see the problem with fuzz?
2019-05-27 22:26:41 <Cogitri> As long as it applies
2019-05-27 22:26:54 <SpaceToast> well it's better for patches to apply cleanly, I would think :)
2019-05-27 22:26:56 <PureTryOut[m]> <Cogitri "Feel free to enable it again if "> cogitri: yeah will do
2019-05-27 22:27:04 <SpaceToast> if I fix them, can I just send you a diff, Cogitri?
2019-05-27 22:27:12 <Cogitri> Anyway, I'll need to work on the PR once I have a functional text editor again :P
2019-05-27 22:27:33 <PureTryOut[m]> Actually let me try armv7 too
2019-05-27 22:27:33 <Cogitri> <SpaceToast "if I fix them, can I just send y"> Sure, but I don't see any value attached to it other than making the `git diff` bigger
2019-05-27 22:27:48 <Cogitri> <PureTryOut[m] "Actually let me try armv7 too"> Yeah, that might work now that mozjs60 works on armv7
2019-05-27 22:27:49 <SpaceToast> Β―\_(ツ)_/Β―
2019-05-27 22:28:25 <PureTryOut[m]> gnome-shell doesn't seem to like aarch64 very much though
2019-05-27 22:28:54 <PureTryOut[m]> I'm glad you've taken up maintainership of GNOME btw cogitri , it was a broken mess before
2019-05-27 22:29:14 <Cogitri> Glad to be of help
2019-05-27 22:29:21 <Cogitri> I'll try to get it working on more arches once I have all my GNOME stuff merged
2019-05-27 22:29:41 <Cogitri> But there has been some good progress on that, luckily
2019-05-27 22:29:48 <PureTryOut[m]> On postmarketOS we need the GNOME stuff for Phosh. I finally got it running properly today πŸŽ‰ only on x86_64 though
2019-05-27 22:30:10 <Cogitri> Nice! :)
2019-05-27 22:30:21 <PureTryOut[m]> 
ACTION uploaded an image: Screenshot_20190528_000414.png (49KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/KuFHOaOREJqgnGbRJGiwdeBY >

2019-05-27 22:30:27 <Cogitri> Was there any more setup required other than installing gnome-shell&gdm
2019-05-27 22:30:44 <Cogitri> I'll make a gnome metapkg soon-ish
2019-05-27 22:30:44 <PureTryOut[m]> Yeah a modification of wlroots, and packaging of Phosh stuff
2019-05-27 22:31:13 <Cogitri> Gotta setup a new root with ZFS 0.8 and encryption soon and will install GNOME on it again to test the gnome setup
2019-05-27 22:31:15 <Cogitri> <PureTryOut[m] "Yeah a modification of wlroots, "> Ah, was talking about GNOME related stuff here
2019-05-27 22:31:28 <PureTryOut[m]> Also this is actually launched with lightdm lol, not gdm. Not that it matters much
2019-05-27 22:31:40 <PureTryOut[m]> No everything GNOME was fine already
2019-05-27 22:34:14 <Cogitri> Nice :)
2019-05-27 22:35:50 <tcely> SpaceToast: the patch disabled the test, it should be fixed to pass instead.
2019-05-27 22:36:01 <SpaceToast> ah I see
2019-05-27 22:36:02 <PureTryOut[m]> gjs builds fine for armv7 as well. Trying armhf lastly, and then I'll be PR'ing it
2019-05-27 22:36:03 <PureTryOut[m]> I don't think new arches require a pkgrel bump right?
2019-05-27 22:41:08 <SpaceToast> Cogitri: I'm getting "ImportError: cannot import name 'setup' from 'setuptools' (unknown location)"
2019-05-27 22:41:17 <SpaceToast> looks like there's also a missing checkdepend
2019-05-27 22:42:38 <SpaceToast> yup, just that
2019-05-27 22:42:48 <SpaceToast> it also wants bash for LitConfig.py
2019-05-27 22:46:01 <PureTryOut[m]> <Cogitri "Feel free to enable it again if "> https://github.com/alpinelinux/aports/pull/8183
2019-05-27 22:48:19 <Cogitri> πŸ‘
2019-05-27 23:07:22 <Cogitri> BTW, @PureTryOut, if you need more GNOME packages feel free to ping me, I'll package most of them at one point anyway but I don't mind prioritising something :)
2019-05-27 23:07:42 <PureTryOut[m]> Oh no everything we need is already in Alpine, we just need it for more architectures πŸ˜„
2019-05-27 23:07:46 <PureTryOut[m]> But thanks!
2019-05-27 23:09:56 <PureTryOut[m]> Actually, gnome-terminal would be nice lol
2019-05-27 23:12:04 <north1> pr7481
2019-05-27 23:13:51 <PureTryOut[m]> Ah good
2019-05-27 23:47:48 <north1> big question
2019-05-27 23:47:49 <north1> i'm updating rdesktop from 1.8.3 to 1.8.6
2019-05-27 23:48:10 <north1> the 1.8.4 had like 10 to 15 CVE fixes, in the secfixes section i mentio the version of the package i'm udpating to or the version it was fixed on, even though we never had or will have a package with that version.
2019-05-27 23:51:11 <TBK[m]> you mention the version you upgrade the aport to
2019-05-27 23:51:37 <north1> alright
2019-05-27 23:51:47 <north1> just to confirm
2019-05-28 00:08:50 <north1> pkgdesc="unknown"
2019-05-28 00:18:48 <jwh> alright, what am I doing wrong... file exists in /tmp/mkinitfs.X, but it never makes it into the initramfs in /boot
2019-05-28 00:19:02 <jwh> that is, it's added by mkinitfs
2019-05-28 00:22:17 <SpaceToast> ping north1 re: pr8189
2019-05-28 00:22:27 <SpaceToast> I really think you're being a bit overzealous
2019-05-28 00:22:33 <SpaceToast> yes, we should be going around and removing builddir
2019-05-28 00:22:35 <north1> Yes?
2019-05-28 00:22:38 <SpaceToast> however
2019-05-28 00:22:42 <SpaceToast> this pr is about openrc
2019-05-28 00:22:55 <SpaceToast> adding additional changes breaks the overall "commits should be logically self-contained changes" philosophy
2019-05-28 00:23:09 <SpaceToast> I obviously don't mind it happening, but I don't think it should be wedged into "the latest commit for thing X"
2019-05-28 00:23:19 <SpaceToast> which seems to be/have-been your approach in general :/
2019-05-28 00:23:58 <SpaceToast> it's just annoying because I'm not the maintainer for that package, and my goal is really *just* to try to improve the state of openrc - the cd $builddir thing is just utterly unrelated
2019-05-28 00:24:24 <SpaceToast> it's also not the first time this happens, so I'd rather hear your reasoning before fighting it out in the PR comments
2019-05-28 00:24:41 <jwh> ohhhh
2019-05-28 00:24:46 <jwh> I had one of those comments too :P
2019-05-28 00:24:55 <SpaceToast> I mean it's obviously a thing that *should* be done
2019-05-28 00:25:08 <SpaceToast> I just don't think it needs to be done as a part of "modernize openrc script", or "fix broken dep"
2019-05-28 00:25:19 <SpaceToast> but rather as a part of "modernize apkbuild" and/or similar
2019-05-28 00:25:46 <SpaceToast> it's not like it's a huge problem for it to remain, and I'd rather keep commits logically contained, rather than try to wedge one specific modernization change into unrelated improvements
2019-05-28 00:26:26 <jwh> if not doing it as part of bumps or whatever, then maybe just touch all the aports that do that, reason: a million PRs to remove cd $builddir is excess workload
2019-05-28 00:26:32 <SpaceToast> (especially if the de-facto maintainer is not the submitter, at which point it *also* starts feeling like I'm being pushed to demand further changes from someone else indirectly)
2019-05-28 00:26:58 <SpaceToast> I think doing it as a part of bumps is fine - package updates are a great time to do apkbuild modernization
2019-05-28 00:27:00 <SpaceToast> but this isn't a bump...
2019-05-28 00:27:11 <jwh> hence the "or whatever" :P
2019-05-28 00:27:22 <jwh> any commit I guess
2019-05-28 00:28:31 <SpaceToast> oftentimes it's double-silly because the part that's being suggested for changing isn't even within the diff... ^^;;
2019-05-28 00:28:49 <SpaceToast> (in version updates, that could happen, but again...)
2019-05-28 00:29:05 <SpaceToast> north1: any comments?
2019-05-28 00:29:34 <north1> SpaceToast: meh, just think there is no better time to wedge those fixes at any time you're touching that package
2019-05-28 00:29:37 <north1> better sooner than problably not later
2019-05-28 00:29:55 <SpaceToast> well, what's the worst-case scenario of "probably not later"?
2019-05-28 00:30:08 <SpaceToast> you have ~20 bytes wasted or so
2019-05-28 00:30:36 <SpaceToast> I think the best time is during version upgrades, when other changes may need to be made anyways (e.g tests etc); or alternatively "whenever the maintainer feels like it"
2019-05-28 00:30:49 <SpaceToast> in this case, I'm *not* the maintainer, and the commit isn't even tangentially related
2019-05-28 00:31:03 <SpaceToast> the only reason APKBUILD is being touched at all is for pkgrel bump and new checksums (so it gets rebuilt and doesn't fail)
2019-05-28 00:31:34 <SpaceToast> basically it just comes off as indirectly pressuring me to pressure the maintainer to make an unrelated change to the improvement sooner, and that makes me a bit uncomfortable every time
2019-05-28 00:31:45 <SpaceToast> north1: perhaps we could discuss a list of scenarios under which it would be ok vs not?
2019-05-28 00:32:44 <north1> SpaceToast: no need
2019-05-28 00:32:51 <SpaceToast> Β―\_(ツ)_/Β―
2019-05-28 00:33:12 <SpaceToast> an alternative approach would be to write some automation thing to open a pr with the press of a button (or whatever) that'd automate the creation of a new one with just that as a change
2019-05-28 00:33:23 <SpaceToast> (or just going through all of testing and community in one swoop)
2019-05-28 00:34:27 <north1> That will take a lot of work
2019-05-28 00:34:34 <north1> more power to anyone that wants to do it
2019-05-28 00:35:38 <jwh> ~10k 'cd "$builddir"', so yeah thats a lot to check heh
2019-05-28 00:35:47 <jwh> a lot of those are probably legit
2019-05-28 00:36:13 <SpaceToast> it's usually the first line of build() check() etc
2019-05-28 00:36:21 <SpaceToast> I could probably make an attempt
2019-05-28 00:36:29 <jwh> could awk it or similar perhaps
2019-05-28 00:36:32 <SpaceToast> right now though, I'm busy cleaning and getting ready for cooking :)
2019-05-28 00:36:39 <north1> 1629 out of 1912 packages in main/ has something caught by apkbuild-lint, with 5969 total violations
2019-05-28 00:36:42 <SpaceToast> jwh: that's what I'm thinking, yeah
2019-05-28 00:36:55 <SpaceToast> main/ isn't affected yet, since it has to keep cd $builddir
2019-05-28 00:37:08 <SpaceToast> since it must support the last 4 releases (2 years)
2019-05-28 00:37:24 <SpaceToast> and the implicit cd was introduced late-ish 2018
2019-05-28 00:37:27 <jwh> huh, where is apkbuild-lint
2019-05-28 00:37:35 <north1> jwh atools
2019-05-28 00:37:37 <jwh> ah
2019-05-28 00:37:50 <north1> apkbuild-lint doesn't test cd "$builddir" for packages in main/
2019-05-28 00:38:02 <SpaceToast> perhaps have a `--fix` flag for apkbuild-lint?
2019-05-28 00:38:08 <SpaceToast> to have it try to autofix simple errors
2019-05-28 00:39:31 <north1> SpaceToast: cd "$builddir" detection is the most complex thing on apkbuild-lint
2019-05-28 00:41:49 <jwh> 
ACTION sighs

2019-05-28 00:41:51 <north1> 1162 out of 1487 packages in community/ with 2863 instances of superfluous-cd-builddir
2019-05-28 00:42:02 <jwh> mkinitfs has annoyed me enough now, sleep time
2019-05-28 00:42:34 <jwh> north1: some of those are false positives right?
2019-05-28 00:43:18 <north1> jwh: possibly, i did my best to avoid them, which is why it is the most complex part of apkbuild-lint
2019-05-28 00:43:46 <jwh> yeah, hard to detect that automatically
2019-05-28 00:59:03 <north1> ERROR: perl-extutils-cchecker-0.10-r0: trying to overwrite usr/lib/perl5/core_perl/perllocal.pod owned by perl-common-sense-3.74-r0.
2019-05-28 01:02:28 <jwh> hm, apkbuild-lint path/to/APKBUILD right?
2019-05-28 01:03:40 <north1> jwh yes
2019-05-28 01:03:53 <jwh> hm
2019-05-28 01:04:09 <north1> so pkgs using find "$pkgdir" -name .packlist -name perllocal.pod -delete are silently failing to remove those files
2019-05-28 01:04:11 <north1> find "$pkgdir" \( -name perllocal.pod -o -name .packlist \) -delete should be used instead
2019-05-28 01:04:17 <jwh> abuild:~/aports/testing/cockroach$ apkbuild-lint ./APKBUILD ; echo $?
2019-05-28 01:04:17 <jwh> 0
2019-05-28 01:05:05 <jwh> hm I wonder
2019-05-28 01:05:18 <jwh> cd ${builddir}
2019-05-28 01:06:48 <north1> it is currently impossible to install netdisco because both perl-extutils-cchecker and perl-common-sense provide the perllocal.pod file
2019-05-28 01:06:55 <north1> jwh: yes, it found no problems try testing/2bwm/APKBUILD
2019-05-28 01:07:22 <jwh> ah I see
2019-05-28 01:08:34 <jwh> ${builddir} is the same as "$builddir" obviously, might be worth adding that too?
2019-05-28 01:09:25 <jwh> personally I use ${} to remove any chance of ambiguity, I expect others might too
2019-05-28 01:10:36 <north1> yeah
2019-05-28 01:11:01 <north1> most people use "$builddir"
2019-05-28 01:11:27 <jwh> yeah, abiguous vars work a lot better than they used to
2019-05-28 01:11:34 <jwh> I still have nightmares from those times
2019-05-28 01:11:49 <jwh> so out of habit I always wrap them in {}
2019-05-28 01:23:32 <Shiz> alpine styling is to generally omit braces except if interpolated in a wider string where confusion may occur
2019-05-28 01:23:34 <Shiz> :p
2019-05-28 01:23:55 <Shiz> e.g. foo="$bar $baz" is still fine
2019-05-28 01:24:13 <jwh> yeah, but nobody uses braces inside strings either
2019-05-28 01:24:20 <jwh> where it is potentially ambiguous
2019-05-28 01:25:02 <Shiz> also, it's only the same if both are surrounded by quotes :p
2019-05-28 01:25:31 <jwh> except where theres no spaces, which there aren't ;)
2019-05-28 01:25:35 <Shiz> that perllocal.pod seems problematic
2019-05-28 01:25:40 <Shiz> jwh: in your specific case
2019-05-28 01:25:41 <Shiz> :)
2019-05-28 01:26:01 <jwh> in 99.9% of cases
2019-05-28 01:26:06 <Shiz> i can clone aports to a directory with spaces and it'd likely break
2019-05-28 01:26:10 <Shiz> so please use ""
2019-05-28 01:26:35 <jwh> if you clone with spaces you have other problems, like terrible practices
2019-05-28 01:26:35 <Shiz> unless i'm confused and it doesnt absolutize paths
2019-05-28 01:26:43 <Shiz> nothing terrible about that practice
2019-05-28 01:27:02 <north1> @Shiz: already made a PR for both of them
2019-05-28 01:27:09 <Shiz> north1: sankyu!
2019-05-28 01:27:24 <north1> actually a PR for each of them
2019-05-28 01:27:47 <north1> pr8193 and pr8194
2019-05-28 01:28:23 <north1> Doesn't abuild have linting for package paths ? Void Linux's xbps-src has checks for paths that should never be installed to.
2019-05-28 01:29:07 <Shiz> it does
2019-05-28 01:29:15 <Shiz> but it doesn't include those files it seems :p
2019-05-28 01:30:24 <Shiz> https://git.alpinelinux.org/abuild/tree/abuild.in#n672
2019-05-28 01:30:30 <Shiz> mostly this though
2019-05-28 01:31:58 <north1> that is nice and kinda small
2019-05-28 01:32:41 <Shiz> i'll merge your prs
2019-05-28 01:34:27 <north1> thank you
2019-05-28 01:44:02 <north1> _ikke_: released tag 12 of atools
2019-05-28 01:46:37 <Shiz> merged the one i could, can't push to main/ :p
2019-05-28 01:49:12 <north1> works well enough for that current case
2019-05-28 01:49:26 <north1> now let's hope no other package in main/ also has a faulty find
2019-05-28 01:49:26 <Shiz> north1: re:the custom variable skip in atools, wouldn't that break for this:
2019-05-28 01:49:28 <Shiz> local i
2019-05-28 01:49:30 <Shiz> i=0
2019-05-28 01:49:33 <Shiz> (in a function)
2019-05-28 01:49:45 <Shiz> (good work on that btw, haven't been keeping up but looks very useful)
2019-05-28 01:50:13 <north1> no because a function has a tab of indent and we only check from the start of the line
2019-05-28 01:50:23 <north1> well hopefully it has a tab of indent
2019-05-28 01:51:44 <Shiz> i guess the \s* in that regexp just confused me then
2019-05-28 01:58:55 <north1> jwh: version 12 of atools will detect those cd $builddir properly
2019-05-28 02:01:34 <jwh> ah cool
2019-05-28 02:16:02 <SpaceToast> north1: I think I wrote an awk script that should filter out all definitive unnecessary variations of cd $builddir
2019-05-28 02:16:05 <SpaceToast> could you take a look?
2019-05-28 02:19:18 <north1> I'm not good with awk
2019-05-28 02:21:10 <SpaceToast> it's commented, just want to see if I didn't miss any edge-case :)
2019-05-28 02:22:02 <north1> sure
2019-05-28 02:22:20 <SpaceToast> https://brpaste.xyz/WaeJ1w
2019-05-28 02:22:24 <SpaceToast> what I've got right now
2019-05-28 02:23:19 <SpaceToast> the idea is to *only* remove lines that match `cd $builddir`, `cd ${builddir}`, `cd "$builddir"`, and `cd "${builddir}"`, and only when they immediately follow a line that matches `build() {`, `check() {` or `prepare() {`
2019-05-28 02:23:21 <north1> missing package()
2019-05-28 02:23:38 <SpaceToast> oh, should be s/prepare/package/, I'd imagine
2019-05-28 02:23:51 <SpaceToast> the only thing I can think of that could go bad is if someone has a line ala
2019-05-28 02:23:58 <SpaceToast> `cd $builddir && make`
2019-05-28 02:24:02 <SpaceToast> but that shouldn't *ever* happen, right?
2019-05-28 02:24:19 <SpaceToast> prepare -> package done
2019-05-28 02:25:12 <north1> for that it should work
2019-05-28 02:25:22 <north1> both
2019-05-28 02:26:18 <SpaceToast> are there many instances like the above?
2019-05-28 02:26:22 <SpaceToast> it seems really weird
2019-05-28 02:26:35 <SpaceToast> `set -e` has been the case for a while, and you can generally assume that builddir will exist...
2019-05-28 02:26:49 <north1> i mean, prepare() -> build() -> check() -> package() are the functions to be checked
2019-05-28 02:26:58 <SpaceToast> oh, ok
2019-05-28 02:27:02 <north1> also superfluous-cd-builddir does more
2019-05-28 02:27:02 <SpaceToast> wait...
2019-05-28 02:27:15 <north1> it will warn on cd "$builddir" after the first line with certain conditions
2019-05-28 02:27:28 <SpaceToast> I know, but I intend to run this with auto-replace on the whole tree
2019-05-28 02:27:38 <SpaceToast> so the top priority is to have zero false positives
2019-05-28 02:28:17 <SpaceToast> ok, both package and prepare is in
2019-05-28 02:30:47 <north1> yeah it should work
2019-05-28 02:32:37 <SpaceToast> let's see how horrible everything is
2019-05-28 02:33:07 <SpaceToast> `cd "$builddir"/build`
2019-05-28 02:33:09 <SpaceToast> ugh
2019-05-28 02:33:34 <north1> http://ix.io/1KfC
2019-05-28 02:33:40 <north1> i match $ or space
2019-05-28 02:34:04 <north1> https://github.com/maxice8/atools/blob/master/apkbuild-lint#L130 here
2019-05-28 02:34:08 <SpaceToast> yeah, trying $
2019-05-28 02:36:29 <SpaceToast> looks like we're good!
2019-05-28 02:36:49 <north1> i'd rather just use apkbuild-lint and check the results later
2019-05-28 02:37:06 <SpaceToast> hey, you started this whole process ;)
2019-05-28 02:37:25 <SpaceToast> still, I'm not seeing *any* false positives in this latest iteration
2019-05-28 02:39:09 <SpaceToast> oh found an easy way to check
2019-05-28 02:39:19 <SpaceToast> git diff | grep -E '^- '
2019-05-28 02:39:32 <SpaceToast> nice :) no false positives
2019-05-28 02:39:41 <SpaceToast> (also looked through it by hand already, but that's besides the point)
2019-05-28 02:40:40 <north1> SpaceToast: i'm not the one with the foot on the gas to get this done over quickly though
2019-05-28 02:46:14 <north1> ok
2019-05-28 02:46:54 <SpaceToast> oh wow, rrdbot is still using md5sums and is tripping up the pre-commit checks
2019-05-28 02:55:32 <SpaceToast> https://github.com/alpinelinux/aports/pull/8197
2019-05-28 02:55:38 <SpaceToast> I feel really really sorry for the poor CI
2019-05-28 03:04:23 <north1> that misses a lot of empty lines after cd "$builddir"
2019-05-28 03:04:39 <SpaceToast> whatever Β―\_(ツ)_/Β―
2019-05-28 03:04:48 <SpaceToast> you wanna fix that? ;)
2019-05-28 03:05:38 <SpaceToast> travis is trying so hard
2019-05-28 03:07:00 <north1> That is what i have been doing the whole time but with less enthusiasm
2019-05-28 03:07:33 <SpaceToast> well, you could take my awk script...
2019-05-28 03:07:38 <SpaceToast> modify it slightly to remove empty lines... :D
2019-05-28 03:10:07 <north1> i'm not good with awk
2019-05-28 03:10:27 <SpaceToast> it's not that hard to learn ^^ only took me about an hour or two today :D
2019-05-28 03:13:34 <north1> i'll pass
2019-05-28 03:15:22 <SpaceToast> :)
2019-05-28 03:15:30 <SpaceToast> and I don't care enough to go for round 2
2019-05-28 03:15:38 <SpaceToast> (especially over a blank line)
2019-05-28 03:44:05 <tcely> SpaceToast north1: 2019-05-19 03:03:19 <tcely> Try something like this: awk -v P=true '/^[^(]+\(/,/^[^}]*}$/ { if(P) {print; P="";} if("cd" == $1) {printf "%d %s\n", FNR, $0;} if("}" == $0) {print; P="true";}}'
2019-05-28 03:44:30 <SpaceToast> nah I'm good
2019-05-28 03:44:36 <SpaceToast> hey tcely :)
2019-05-28 03:45:18 <tcely> hey
2019-05-28 04:00:29 <Danct12_> Heey guys
2019-05-28 04:00:36 <Danct12_> I'm interested in maintaining Enlightenment WM
2019-05-28 04:04:12 <SpaceToast> hey Danct12_
2019-05-28 04:04:19 <SpaceToast> that's cool!
2019-05-28 04:04:38 <SpaceToast> feel free to find any relevant apkbuilds, take ownership (assuming they aren't currently maintained), add any required ones and submit a PR
2019-05-28 04:04:51 <Danct12_> Yeah, the Enlightenment WM went unmaintained for sometime now
2019-05-28 04:04:58 <north1> celt051 needs to be rebuilt to provide pc:celt051
2019-05-28 04:05:55 <Danct12_> Actually we want to maintain that for postmarketOS, but PureTryOut[m] suggested me to upstream it to Alpine aports
2019-05-28 04:06:12 <Danct12_> We got the desktop to built and it also ran as well, and also Terminology
2019-05-28 04:07:01 <Danct12_> EFL 1.22.2 and Enlightenment 0.22.4
2019-05-28 04:08:04 <Danct12_> I've submitted a MR for the Bullet Physics which is used for EFL
2019-05-28 04:32:01 <tcely> So, more builddir variations from community:
2019-05-28 04:32:01 <tcely> cd "$builddir" || return 1
2019-05-28 04:32:01 <tcely> cd "$_builddir" || return 1
2019-05-28 04:33:05 <SpaceToast> _builddir I'd leave alone
2019-05-28 04:33:15 <SpaceToast> since it could be customized
2019-05-28 04:33:25 <SpaceToast> and I doubt there are thousands of the former
2019-05-28 04:33:31 <SpaceToast> (see: goal definition in the pr)
2019-05-28 04:34:05 <tcely> Hundreds from my counting
2019-05-28 04:34:18 <SpaceToast> mhm
2019-05-28 04:34:31 <SpaceToast> do you want my terrible awk script for modification?
2019-05-28 04:34:52 <SpaceToast> (I'd rather see the first part get merged first, but won't object to any other attempts, and am willing to provide help, ofc)
2019-05-28 04:34:53 <tcely> I got the earlier link
2019-05-28 04:35:02 <SpaceToast> it's been updated a bit
2019-05-28 04:35:10 <SpaceToast> https://brpaste.xyz/--QV2w - latest
2019-05-28 04:39:53 <tcely> Almost a thousand across community + testing for _builddir
2019-05-28 04:40:45 <_ikke_> honestly I would not fix them all preemptively
2019-05-28 04:41:40 <SpaceToast> _builddir is not implicit within those functions
2019-05-28 04:41:42 <SpaceToast> builddir is
2019-05-28 04:41:48 <SpaceToast> _builddir could be who-knows-what
2019-05-28 04:41:53 <_ikke_> yes
2019-05-28 04:42:01 <tcely> Just fixing the 20 or so unquoted uses might be worth it.
2019-05-28 04:42:02 <SpaceToast> also hey _ikke_, really sorry for the headache I've certainly caused :)
2019-05-28 04:42:06 <SpaceToast> it's north1's fault!
2019-05-28 04:42:16 <SpaceToast> tcely: enjoy! ;)
2019-05-28 05:01:51 <north1> lol don't blame me for that
2019-05-28 05:02:02 <SpaceToast> you're 100% at fault here
2019-05-28 05:02:15 <SpaceToast> you got me sufficiently annoyed to go and do the thing, and even suggested that "someone" do it ;)
2019-05-28 05:02:25 <SpaceToast> I am just the vessel!
2019-05-28 05:05:35 <tcely> pr8011 could use more eyes
2019-05-28 05:07:06 <north1> SpaceToast: lol don't blame me for that
2019-05-28 05:18:16 <north1> _ikke_: can tags like AL{1,2,3,4...} do for apkbuild and aports lint ?
2019-05-28 06:02:58 <_ikke_> north1: Sure
2019-05-28 06:07:17 <north1> _ikke_: check pr 16 on maxice8/atools
2019-05-28 06:10:29 <_ikke_> oh lol
2019-05-28 06:10:33 <_ikke_> that link doesn't work :P
2019-05-28 07:24:49 <ncopa> morning
2019-05-28 07:27:31 <_ikke_> o/
2019-05-28 07:57:14 <Danct12> Ay ncopa, what do you think of retrieving Enlightenment desktop?
2019-05-28 07:57:20 <Danct12> I'm doing it. ;)
2019-05-28 07:57:48 <Danct12> s/I'm/We're/g
2019-05-28 07:57:48 <alpine-meetbot> Danct12 meant to say: We're doing it. ;)
2019-05-28 08:58:54 <ncopa> Danct12: i have no opinion there, as long as I don't need to maintain it
2019-05-28 09:01:36 <mps> good morning all. ncopa: I would like to move fwknop to community from testing. asking you (maintainer) do you have any objection to that
2019-05-28 09:02:29 <ncopa> mps: not problem. feel free to take over maintainership too
2019-05-28 09:02:54 <mps> ok, will do. thanks. It is useful to me
2019-05-28 09:08:13 <mps> btw, should we upgrade ncurses before release? there are some fixes but nothing serious in latest ncurses release
2019-05-28 09:08:57 <mps> I'm on their ML and follow it's fixes and addition
2019-05-28 09:11:41 <ncopa> probably a good idea
2019-05-28 09:12:01 <ncopa> ncurses 6.2 is not out yet?
2019-05-28 09:12:52 <mps> no, not yet, and there are no signs it will be soon
2019-05-28 09:38:32 <PureTryOut[m]> If someone has time I would like this PR to be reviewed (please skip the licensing check, there are enough conversations about that in there already) https://github.com/alpinelinux/aports/pull/7992
2019-05-28 09:42:34 <_ikke_> PureTryOut[m]: I can check in about an hour
2019-05-28 09:44:55 <PureTryOut[m]> Thanks!
2019-05-28 09:50:42 <asriel[m]1> Howdy!
2019-05-28 09:51:38 <Danct12_> Good (almost) to evening, asriel[m]1!
2019-05-28 09:52:56 <Danct12_> We have bullet merged to aports, so we should upstream EFL and Enlightenment to aports later.
2019-05-28 10:08:57 <asriel[m]1> Of course, isn't our goal is to.. upstream and maintain the Enlightenment WM?
2019-05-28 10:21:55 <_ikke_> PureTryOut[m]: Is each tier a set of packages where future packages will depend on?
2019-05-28 10:23:45 <PureTryOut[m]> Basically yes
2019-05-28 10:23:52 <PureTryOut[m]> I'm doing tier 2 atm which all depend on tier 1
2019-05-28 10:23:59 <_ikke_> ok
2019-05-28 10:24:02 <PureTryOut[m]> Read this for clarification https://api.kde.org/frameworks/index.html
2019-05-28 10:24:10 <_ikke_> thanks
2019-05-28 10:24:53 <_ikke_> Is your goal to submit all tiers eventually?
2019-05-28 10:25:18 <PureTryOut[m]> Yup
2019-05-28 10:25:21 <PureTryOut[m]> Like I said, doing tier 2 atm.
2019-05-28 10:26:12 <_ikke_> https://github.com/alpinelinux/aports/pull/7992/commits/6ad8ce16681eccf54a9480605ffd00f611b7128b is conflicting
2019-05-28 10:26:33 <PureTryOut[m]> Yeah I noticed, probably because I didn't bump the pkgrel?
2019-05-28 10:26:44 <_ikke_> prepare function regarding the builddir
2019-05-28 10:26:50 <PureTryOut[m]> I guess now the license is changed I can bump it anyway
2019-05-28 10:27:14 <PureTryOut[m]> Oh, but effectively there isn't any change there. At the end `$builddir/build` is created in both cases
2019-05-28 10:27:22 <_ikke_> yes, indeed
2019-05-28 10:27:34 <PureTryOut[m]> I can still bump the pkgrel though if required
2019-05-28 10:28:29 <_ikke_> The maintainer is part of the package metadata
2019-05-28 10:28:50 <_ikke_> So it would make sense to bump it, but I can fix that
2019-05-28 10:30:54 <_ikke_> PureTryOut[m]: Would you object against this? http://tpaste.us/O1VY
2019-05-28 10:31:03 <_ikke_> Not a strong preference, I just find it slightly cleaner
2019-05-28 10:31:10 <PureTryOut[m]> Ok thanks
2019-05-28 10:32:42 <PureTryOut[m]> I do not, actually I even prefer it. I didn't realize make supported -C as well, I thought that was just a Meson/Ninja thing
2019-05-28 10:33:15 <_ikke_> ok, will squash that in then
2019-05-28 10:33:57 <PureTryOut[m]> πŸ‘
2019-05-28 10:44:26 <_ikke_> PureTryOut[m]: building everything now locally
2019-05-28 10:47:07 <PureTryOut[m]> Awesome!
2019-05-28 10:47:58 <_ikke_> May take a while. I'll keep it running and will continue later
2019-05-28 10:49:11 <mps> ncopa: just posted ncurses upgrade to 6.1-20190518 https://patchwork.alpinelinux.org/patch/4895/
2019-05-28 10:50:44 <PureTryOut[m]> Yeah sure
2019-05-28 10:52:23 <ncopa> looks like main/perl-server-starter hangs on build-edge-x86
2019-05-28 10:54:38 <Danct12_> Can I sign-off a commit that's going to be in the pull request?
2019-05-28 10:55:10 <_ikke_> Danct12_: sure, it doesn't mean anything for alpine though
2019-05-28 10:55:40 <Danct12_> alright.
2019-05-28 10:56:47 <_ikke_> ncopa: should I kill it?
2019-05-28 10:56:54 <mps> ncopa: did you merged/pushed new perl with your fixes
2019-05-28 10:57:01 <_ikke_> received TERM, sending TERM to all workers:28442
2019-05-28 10:57:32 <mps> main/perl-server-starter pass on my x86  lxc
2019-05-28 10:58:50 <mps> although warnings says that some tests are 'bad': have non-clean var definition and assigments
2019-05-28 10:59:15 <ncopa> _ikke_: i can do it
2019-05-28 10:59:58 <ncopa> heh
2019-05-28 11:00:13 <ncopa> apparently i killed the righ(wrong) process
2019-05-28 11:00:16 <ncopa> it continued with succes
2019-05-28 11:00:34 <ncopa> it was supposed to exit with error
2019-05-28 11:04:12 <_ikke_> haha LD
2019-05-28 11:04:24 <mps> when moving pkg from testing to community do we have to bump pkgrel
2019-05-28 11:04:53 <_ikke_> no
2019-05-28 11:05:16 <mps> thanks
2019-05-28 11:28:52 <PureTryOut[m]> _ikke_: I made a PR for tier 2. Will do tier 3 (the last tier) next. https://github.com/alpinelinux/aports/pull/8204
2019-05-28 11:38:44 <_ikke_> alright
2019-05-28 11:39:15 <_ikke_> PureTryOut[m]: It seems to hang already on bluez-qt
2019-05-28 11:39:23 <_ikke_> Start 2: bluezqt-agentmanagertest
2019-05-28 11:42:43 <PureTryOut[m]> Huh
2019-05-28 11:44:07 <_ikke_> strace only shows restart_syscall(<... resuming interrupted restart_syscall ...>
2019-05-28 11:44:24 <PureTryOut[m]> You seem to be right, interesting that I didn't find this earlier
2019-05-28 11:45:16 <PureTryOut[m]> Although for me it hangs on Start1: bluezqt-managertest
2019-05-28 11:45:37 <_ikke_> That one took a couple of minutes, but it got out of it
2019-05-28 11:46:25 <PureTryOut[m]> Ah ok, I'll wait for it then
2019-05-28 11:47:17 <PureTryOut[m]> It seems I did this package too hastly (we don't use it in pmOS so it's new in this PR), it also misses some build time dependencies for extra functionality
2019-05-28 11:47:21 <_ikke_> A deadlock maybe? One thread is waiting on futex
2019-05-28 11:47:36 <PureTryOut[m]> Also, bluezqt-obexmanagertest (test 3) failing because of missing dbus session
2019-05-28 11:49:17 <PureTryOut[m]> I think I'll just disable tests entirely for this package. Basically all of them either hang or are broken
2019-05-28 11:49:17 <PureTryOut[m]> bluezqt-adaptertest also hangs, I guess it's waiting for a Bluetooth adapter?
2019-05-28 11:49:27 <PureTryOut[m]> _ikke_: is it acceptable to you if I just disable those tests entirely?
2019-05-28 11:58:30 <p4Wv1qn095FW> uh. upon apk upgrade, i get a lot of linux-firmware packages that fill up my root partition
2019-05-28 11:58:50 <p4Wv1qn095FW> that's not good.
2019-05-28 12:01:04 <_ikke_> PureTryOut[m]: that might be
2019-05-28 12:01:57 <mps> p4Wv1qn095FW: install those you need, other will be removed
2019-05-28 12:02:28 <PureTryOut[m]> _ikke_: ok. I just updated the PR to disable tests in bluez-qt. Also, extra-cmake-modules didn't require an out-of-source build at all so I removed that entirely
2019-05-28 12:02:38 <PureTryOut[m]> All other packages are untouched
2019-05-28 12:05:44 <_ikke_> will try later
2019-05-28 12:07:25 <PureTryOut[m]> And for some reason that introduced merge conflicts... Rebased
2019-05-28 12:13:56 <Danct12_> can i take over a package maintainer?
2019-05-28 12:14:28 <_ikke_> Danct12_: It's customary to first try to contact the current maintainer (if there is one)
2019-05-28 12:20:44 <Danct12_> Thank you, I just sent the EFL package maintainer an email.
2019-05-28 12:24:04 <PureTryOut[m]> _ikke_: CI seems to go through, it just fails because the maximum output has been exceeded. Can't do much about that
2019-05-28 12:25:52 <p4Wv1qn095FW> mps: thx.
2019-05-28 12:27:09 <_ikke_> PureTryOut[m]: building everything again locally
2019-05-28 13:24:47 <TBK[m]> is build-edge-ppc64le stuck when it says "pulling git" and have been doing so for quite a while?
2019-05-28 13:44:15 <_ikke_> PureTryOut[m]: kcoreaddons failed: " 24 - kdirwatch_qfswatch_unittest (Failed)"
2019-05-28 13:48:58 <PureTryOut[m]> _ikke_: > 100% tests passed, 0 tests failed out of 24
2019-05-28 13:49:01 <PureTryOut[m]> I can't reproduce that locally
2019-05-28 13:49:10 <_ikke_> missing dependency?
2019-05-28 13:49:51 <PureTryOut[m]> I'm building everything with the minimal available.
2019-05-28 13:49:58 <PureTryOut[m]> What is the error?
2019-05-28 13:50:51 <_ikke_> it complains about no space being available, while there should be enough
2019-05-28 13:51:03 <_ikke_> Maybe amount of inotify watches that can be open?
2019-05-28 13:51:22 <PureTryOut[m]> I guess?
2019-05-28 13:51:41 <_ikke_> I'm running this in an lxc container
2019-05-28 13:51:56 <PureTryOut[m]> Ah, I think it needs more than 8192 open fds. According to AdΓ©lie Linux anyway
2019-05-28 13:54:39 <PureTryOut[m]> Does it pass the tests if you just disable that failing one?
2019-05-28 13:54:59 <_ikke_> how do I disable it?
2019-05-28 13:55:28 <PureTryOut[m]> Add `-E '(kdirwatch_qfswatch_unittest)' ` behind the ctest command
2019-05-28 13:55:59 <PureTryOut[m]> Actually it succeeded for me in postmarketOS, but does fail as well in my Alpine Linux chroot
2019-05-28 13:56:13 <_ikke_> with the braces?
2019-05-28 13:56:20 <PureTryOut[m]> Yes
2019-05-28 13:57:45 <_ikke_> PureTryOut[m]: it does pass then
2019-05-28 13:58:06 <PureTryOut[m]> Ok. Disabling that one test will do then
2019-05-28 13:59:37 <PureTryOut[m]> Shall I edit the PR or will you do it when merging?
2019-05-28 14:00:22 <_ikke_> the latter
2019-05-28 14:00:29 <_ikke_> easier for me to squash it in
2019-05-28 14:48:19 <PureTryOut[m]> Cool. Did the rest of the build go through fine _ikke_ ?
2019-05-28 15:24:13 <_ikke_> PureTryOut[m]: Needed to fix the order for dependencies
2019-05-28 15:26:32 <_ikke_> kpackage seems to be missing
2019-05-28 15:26:51 <_ikke_> ERROR: unsatisfiable constraints:
2019-05-28 15:26:53 <_ikke_>   kpackage-dev (missing):
2019-05-28 15:26:55 <_ikke_>     required by: .makedepends-kirigami2-0[kpackage-dev]
2019-05-28 15:27:29 <_ikke_> and kservice as well
2019-05-28 15:30:50 <PureTryOut[m]> That makes no sense. Kirigami2 is a tier 1 package, kpackage a tier 2 package
2019-05-28 15:32:16 <_ikke_> PureTryOut[m]: did you add the dependency by accident?
2019-05-28 15:32:26 <_ikke_> This is purely what you specified in the package
2019-05-28 15:32:45 <PureTryOut[m]> I'm building it in an Alpine Linux chroot atm, works fine
2019-05-28 15:32:52 <PureTryOut[m]> I did not add that dependency no
2019-05-28 15:33:12 <_ikke_> hmm
2019-05-28 15:33:18 <PureTryOut[m]> Wait, huh
2019-05-28 15:33:21 <PureTryOut[m]> It is in there somehow, but how?
2019-05-28 15:33:46 <PureTryOut[m]> This makes no sense...
2019-05-28 15:34:07 <_ikke_> You tell me ;-)
2019-05-28 15:34:24 <PureTryOut[m]> I don't even have kpackage on my local system, then how did it resolve it for me?
2019-05-28 15:34:45 <_ikke_> apk policy kpackage
2019-05-28 15:35:10 <PureTryOut[m]> Well, it's not needed anyway, so you can remove it from the depends
2019-05-28 15:35:15 <_ikke_> I will
2019-05-28 15:35:39 <_ikke_> modemmanager-qt also has failed tests
2019-05-28 15:35:47 <_ikke_> all of them
2019-05-28 15:35:48 <PureTryOut[m]> Oh... Now I get it. Thanks for that `apk policy kpackage` command
2019-05-28 15:36:16 <_ikke_> QWARN  : Modem3gppUssdPropertiesTest::initTestCase() modemmanager-qt: Failed enumerating MM objects: "org.freedesktop.DBus.Error.Disconnected"
2019-05-28 15:36:22 <_ikke_> It requires dbus apparently
2019-05-28 15:36:44 <PureTryOut[m]> Ah, and that's impossible so those tests have to be disabled
2019-05-28 15:36:59 <PureTryOut[m]> I don't understand how I haven't caught some of this stuff earlier...
2019-05-28 15:37:10 <_ikke_> It happens :-)
2019-05-28 15:38:08 <PureTryOut[m]> how can I give abuild more cores to work with? it seems to be using -j1 for everything
2019-05-28 15:38:37 <_ikke_> /etc/abuild.conf
2019-05-28 15:38:52 <_ikke_> there is JOBS variable in there
2019-05-28 15:39:18 <_ikke_> kirigami2 now succeeded
2019-05-28 15:40:46 <PureTryOut[m]> Hmm modemmanager-qt tests go through fine for me
2019-05-28 15:40:54 <_ikke_> Do you have dbus running?
2019-05-28 15:41:09 <PureTryOut[m]> It's a chroot, so no
2019-05-28 15:41:13 <PureTryOut[m]> Actually, I guess I do have that running
2019-05-28 15:41:16 <PureTryOut[m]> According to ps aux
2019-05-28 15:41:36 <_ikke_> a chroot only isolates the file system
2019-05-28 15:41:58 <PureTryOut[m]> Oh that's the host system obviously. Yeah sorry I do have it running. Tests can be disabled then
2019-05-28 15:43:44 <_ikke_> networkmanager-qt has 3 failed tests
2019-05-28 15:44:46 <_ikke_> https://tpaste.us/roQQ
2019-05-28 15:48:25 <PureTryOut[m]> All other tests pass?
2019-05-28 15:48:49 <_ikke_> yes
2019-05-28 15:49:45 <_ikke_> prison misses libdmtx(-dev)
2019-05-28 15:50:05 <mps> _ikke_: one advice please, I tested community/domoticz on armv7 and it pass 'abuild -r' in lxc container and think it could be enabled. should we bump pkgrel before posting push to aports
2019-05-28 15:50:11 <PureTryOut[m]> Why do you think that?
2019-05-28 15:50:28 <_ikke_> PureTryOut[m]: because abuild complains about it ;-)
2019-05-28 15:50:47 <_ikke_> It requires it but it cannot find it
2019-05-28 15:51:41 <_ikke_> ERROR: unsatisfiable constraints:
2019-05-28 15:51:43 <_ikke_>   libdmtx-dev (missing):
2019-05-28 15:51:45 <_ikke_>     required by: .makedepends-prison-0[libdmtx-dev]
2019-05-28 15:52:10 <_ikke_> mps: if it's not build yet on armv7 and has been built on other archers, pkgrel bump is not required
2019-05-28 15:52:16 <_ikke_> arches*
2019-05-28 15:52:31 <_ikke_> PureTryOut[m]: everything else builds
2019-05-28 15:53:08 <PureTryOut[m]> mps: enabling new architectures doesn't require pkgrel bump
2019-05-28 15:53:09 <PureTryOut[m]> Ah, that's obvious then haha
2019-05-28 15:53:20 <mps> I think it is not built because it have `arch="all !armhf !armv7"`
2019-05-28 15:53:44 <_ikke_> Yes, just removing !armv7 is enough
2019-05-28 15:53:58 <mps> ok, thanks
2019-05-28 15:55:58 <PureTryOut[m]> _ikke_: oh yeah hold on
2019-05-28 15:56:54 <_ikke_> 
ACTION grabs rope

2019-05-28 15:56:54 <PureTryOut[m]> _ikke_: prison can be build without libdmtx. I think I'll add it later and introduce libdmtx at that point as well
2019-05-28 15:57:04 <_ikke_> ok, will remove it for now
2019-05-28 15:57:21 <PureTryOut[m]> However, I do seem to have forgotten qt5-qtdeclarative in `$depends_dev` for prison, please add it
2019-05-28 15:57:27 <_ikke_> ok
2019-05-28 15:57:40 <_ikke_> qt5-qtdeclarative-dev
2019-05-28 15:57:43 <_ikke_> it's in there
2019-05-28 15:57:49 <_ikke_> oh
2019-05-28 15:57:50 <_ikke_> wrong package
2019-05-28 15:58:12 <PureTryOut[m]> I'm sorry for all the trouble πŸ™ˆ
2019-05-28 15:58:22 <_ikke_> No problem
2019-05-28 16:02:23 <_ikke_> so networkmanager-qt is the only one left
2019-05-28 16:03:13 <PureTryOut[m]> Those tests right?
2019-05-28 16:04:00 <PureTryOut[m]> Add `-E '(manager|settings|activeconnectiontest)test'` to the end of ctest
2019-05-28 16:04:18 <PureTryOut[m]> Woops, I mean `-E '(manager|settings|activeconnection)test'`
2019-05-28 16:04:45 <_ikke_> any idea why those tests fail?
2019-05-28 16:08:26 <PureTryOut[m]> I do not. Seems like some threading failure, I'm blaming KDE
2019-05-28 16:08:48 <_ikke_> Might be worth to report them upstream
2019-05-28 16:09:17 <PureTryOut[m]> Yeah guess so
2019-05-28 16:12:35 <_ikke_> http://tpaste.us/65yr
2019-05-28 16:14:19 <PureTryOut[m]> Yeah seems good!
2019-05-28 16:18:11 <PureTryOut[m]> I think I'm going to switch out my chroot build environment for a Docker one lol
2019-05-28 16:18:17 <Cogitri> docker-abuild is very nice
2019-05-28 16:26:17 <PureTryOut[m]> Oh yeah I just found it, that is nice indeed
2019-05-28 16:31:28 <Danct12> 
ACTION uploaded an image: image.png (21KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/KzvDzleseqjhlHbbCaojyUaX >

2019-05-28 16:33:45 <Danct12> so the efl apkbuild maintainer has already working on terminology
2019-05-28 16:34:25 <Danct12> so.. did i wasted my time on packaging terminology? πŸ€”
2019-05-28 16:35:12 <asriel[m]1> Maybe, but probably not anyway
2019-05-28 16:35:18 <asriel[m]1> You can try to suggest improvements
2019-05-28 16:37:19 <asriel[m]1> Aside that, Enlightenment isn't in Alpine yet, same goes for it's optional components.
2019-05-28 16:41:25 <Danct12> but one thing, there aren't anything to be done for terminology as far i know of, you can compile with it's own default config and works just fine
2019-05-28 16:43:52 <SpaceToast> ping ncopa: is there any interest in pr8197? I could keep re-generating it as changes come in, but it's pretty high-volume work
2019-05-28 16:44:08 <SpaceToast> so I'd rather not have a solid hour per day spent on something that won't (eventually) get merged :)
2019-05-28 16:44:39 <mps> SpaceToast: hi, did you tried build llvm8 in your lxc
2019-05-28 16:44:45 <SpaceToast> mps: yes, it works fine
2019-05-28 16:45:00 <SpaceToast> I think you'll need to ask clandmeter regarding the tmpfs on the builders to find out why the test fails
2019-05-28 16:45:04 <SpaceToast> (passes fine on my system)
2019-05-28 16:45:30 <SpaceToast> the packages my builder produced are available at https://build.toastin.space/testing/x86_64/ if you're interested
2019-05-28 16:45:39 <mps> nice, I should follow your advice of setting x86 lxc
2019-05-28 16:45:58 <SpaceToast> it's a bit more complex with raw lxc, I use lxd because it simplifies a lot of the tasks
2019-05-28 16:46:07 <SpaceToast> (like shared volumes etc)
2019-05-28 16:46:16 <SpaceToast> but if you're interested in trying out, feel free to ping me for help :)
2019-05-28 16:46:35 <mps> aha, I remember you talk about lxd
2019-05-28 17:08:40 <_ikke_> PureTryOut[m]: still here?
2019-05-28 17:33:14 <_ikke_> PureTryOut[m]: Pushing now
2019-05-28 17:57:30 <mps> what status is appropriate for partially accepted patch from pw.a.o
2019-05-28 17:59:16 <iggy> am I trying to put too much stuff into this PR? https://github.com/alpinelinux/aports/pull/7894
2019-05-28 17:59:50 <iggy> still not quite sure on all the rules for this project's submissions
2019-05-28 18:00:25 <_ikke_> You splitted it into nice commits, should be okay
2019-05-28 18:01:46 <iggy> thanks for looking
2019-05-28 18:02:06 <PureTryOut[m]> _ikke_: yeah sorry am here, was having dinner
2019-05-28 18:03:15 <PureTryOut[m]> Thanks for merging! Up to the next tiers!
2019-05-28 18:03:27 <PureTryOut[m]> I'll be sure to test everything better, should be easier now with docker-abuild πŸ˜„
2019-05-28 18:03:48 <_ikke_> PureTryOut[m]: kcoreaddins is failing in s390x, one test failure
2019-05-28 18:04:01 <_ikke_> s/addins/addons
2019-05-28 18:04:01 <alpine-meetbot> _ikke_ meant to say: PureTryOut[m]: kcoreaddons is failing in s390x, one test failure
2019-05-28 18:04:03 <PureTryOut[m]> Ah, that's an architecture I can't test sadly
2019-05-28 18:04:03 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/kcoreaddons/kcoreaddons-5.58.0-r0.log
2019-05-28 18:04:13 <_ikke_> Nope, me neither
2019-05-28 18:04:33 <_ikke_> Just one test failure, so it doesn't look that bad
2019-05-28 18:04:47 <PureTryOut[m]> Just disable the singular test for now. I'm going to report most of the failures upstream I think
2019-05-28 18:05:02 <_ikke_> ok
2019-05-28 18:05:58 <_ikke_> Where do I find the name to disable?
2019-05-28 18:06:27 <_ikke_> kdirwatch_inotify_unittest
2019-05-28 18:06:29 <_ikke_> that one, right?
2019-05-28 18:06:51 <PureTryOut[m]> Yup
2019-05-28 18:07:05 <PureTryOut[m]> Please do mention in the APKBUILD that it fails on s390x only
2019-05-28 18:07:38 <_ikke_> Yes, I will
2019-05-28 18:07:45 <PureTryOut[m]> Thanks!
2019-05-28 18:14:18 <mps> is Kelvin Nicholson here?
2019-05-28 18:22:12 <_ikke_> PureTryOut[m]: http://dup.pw/aports/e7e923e3
2019-05-28 18:22:58 <PureTryOut[m]> Even better!
2019-05-28 18:23:30 <_ikke_> Let's see if it builds now :)
2019-05-28 18:43:52 <_ikke_> PureTryOut[m]: s390x is now happy as well
2019-05-28 18:45:39 <PureTryOut[m]> Awesome!
2019-05-28 19:02:20 <jwh> SpaceToast: so I've got it sorted now, just writing helpers to make it easy
2019-05-28 19:02:28 <SpaceToast> nice :)
2019-05-28 19:02:51 <jwh> then we'll see what the elders say
2019-05-28 19:03:10 <SpaceToast> I'd probably try converting some of the existing stuff into hooks
2019-05-28 19:03:19 <jwh> yeah thats what I'm donig
2019-05-28 19:03:20 <jwh> doing*
2019-05-28 19:03:29 <jwh> gonna convert crypt root as an example
2019-05-28 19:04:42 <SpaceToast> meanwhile, looks like salt's s3fs module has been broken for a WHILE in py3
2019-05-28 19:04:56 <jwh> :(
2019-05-28 19:04:58 <SpaceToast> which is kind of a problem
2019-05-28 19:05:09 <SpaceToast> since I'm about to start working with it at $dayjob
2019-05-28 19:05:14 <jwh> severely broken?
2019-05-28 19:05:21 <SpaceToast> "doesn't work at all" broken
2019-05-28 19:05:29 <SpaceToast> (wrong argument type, doesn't get past the very start)
2019-05-28 19:05:49 <jwh> lol
2019-05-28 19:06:00 <SpaceToast> trying to decide between using s3fs-fuse temporarily as a workaround, or trying really hard to convince saltstack *and* canonical to make and then backport a fix 3 version families deep
2019-05-28 19:06:05 <SpaceToast> probably that first one :(
2019-05-28 19:06:24 <jwh> yeah I wouldn't hold my breath for the latter
2019-05-28 19:06:50 <SpaceToast> for alpine (personal use) I'd just need it fixed
2019-05-28 19:06:54 <SpaceToast> but for work, it's a bit more complicated
2019-05-28 19:09:11 <jwh> yeah
2019-05-28 19:12:14 <north1> Can i get some attention on pr8205 ? adds gtk3 variant to wxgtk
2019-05-28 19:15:29 <mps> north1: does it passed CI or drone.io
2019-05-28 19:22:18 <iggy> SpaceToast: just get the fixed module, throw it in _modules and sync it out
2019-05-28 19:22:29 <SpaceToast> iggy: it's a master module
2019-05-28 19:22:37 <SpaceToast> for external fileserver and pillar stuff
2019-05-28 19:22:49 <SpaceToast> bit more complicated
2019-05-28 19:22:52 <iggy> there's a thing for that too
2019-05-28 19:25:24 <mps> north1: 8205 passed on armv7 and aarch64. I think it could be pushed. Do you agree?
2019-05-28 19:25:49 <iggy> but using a 3 version old version of salt on py3 sounds like a recipe for disaster (even using the latest one is iffy ;) )
2019-05-28 19:26:06 <_ikke_> iggy: ..?
2019-05-28 19:27:25 <SpaceToast> strange... python3 got corrupted on a bunch of my hosts
2019-05-28 19:27:28 <north1> mps: lgtm
2019-05-28 19:27:44 <SpaceToast> iggy: same issue with all of them; the 3-version-old-one is 'buntu latest lts official package :D
2019-05-28 19:29:38 <mps> north1: ok
2019-05-28 19:30:06 <mps> let's see it
2019-05-28 19:39:57 <_ikke_> north1: interesting case with firejail regarding apkbuild-lint
2019-05-28 19:43:58 <_ikke_> There is a variable `_extrver`, which apparently is only used for some versions, but empty otherwise
2019-05-28 19:44:30 <_ikke_> it first warns about it being empty, and when it's empty, it also warns about builddir being default.
2019-05-28 19:46:59 <north1> only used for some versions ?
2019-05-28 19:47:46 <_ikke_> let me check
2019-05-28 19:48:18 <_ikke_> -_extraver=LTS-release
2019-05-28 19:48:55 <_ikke_> So apparently from time to time they append LTS-release to the version
2019-05-28 19:48:55 <PureTryOut[m]> Is anyone explicitely against me moving Phonon from Qt4 to Qt5?
2019-05-28 19:49:12 <_ikke_> I have no clue what it is :)
2019-05-28 19:50:07 <PureTryOut[m]> Doesn't seem like anything is using it really
2019-05-28 19:50:08 <PureTryOut[m]> KDE requires it, but the Qt5 version πŸ˜‰
2019-05-28 19:50:17 <PureTryOut[m]> And since Qt4 is old and unmaintained anyway, it seems like a good thing to get rid of
2019-05-28 19:50:24 <PureTryOut[m]> *off
2019-05-28 19:50:31 <north1> PureTryOut: i am explicitly and belligerently in favor of it
2019-05-28 19:50:33 <_ikke_> Yeah, I think things are moving that way anyway
2019-05-28 19:50:34 <PureTryOut[m]> Even better
2019-05-28 19:50:52 <_ikke_> north1: Also vehemently?
2019-05-28 19:51:06 <PureTryOut[m]> Cool I'll submit a PR in a minute then. I'll also modernize the APKBUILD because damn it is old
2019-05-28 19:52:28 <north1> _ikke_: nah
2019-05-28 20:01:53 <PureTryOut[m]> https://github.com/alpinelinux/aports/pull/8218
2019-05-28 20:11:09 <_ikke_> PureTryOut[m]: https://cloud.drone.io/alpinelinux/aports/5742
2019-05-28 20:11:46 <PureTryOut[m]> Oh yeah sorry I know, still working on that PR. Was too hasty with it.
2019-05-28 20:11:51 <_ikke_> np
2019-05-28 20:11:57 <_ikke_> I restarted CI to get the status
2019-05-28 20:12:05 <PureTryOut[m]> Ah
2019-05-28 20:12:28 <PureTryOut[m]> The Phonon PR should be good to merge now, thanks @TBK:matrix.org for that quick review
2019-05-28 20:12:45 <_ikke_> marked that one as WIP for now
2019-05-28 20:12:52 <PureTryOut[m]> πŸ‘
2019-05-28 20:14:48 <PureTryOut[m]> Huh, what happened here? https://cloud.drone.io/alpinelinux/aports/5747/3/1
2019-05-28 20:15:16 <_ikke_> No clue
2019-05-28 20:15:41 <_ikke_> I can restart it
2019-05-28 20:15:56 <PureTryOut[m]> Thanks
2019-05-28 20:16:06 <TBK[m]> maybe some stuff got left behind
2019-05-28 20:19:52 <PureTryOut[m]> Β―\_(ツ)_/Β― it went through fine now
2019-05-28 20:33:42 <PureTryOut[m]> _ikke_: the WIP label can be removed again
2019-05-28 20:33:46 <_ikke_> ok
2019-05-28 20:34:17 <PureTryOut[m]> CI will fail because of the Phonon PR it depends on not being merged yet, but otherwise it should be good to go
2019-05-28 20:34:48 <_ikke_> I marked it waiting for dependencies
2019-05-28 20:39:27 <PureTryOut[m]> Thanks!
2019-05-28 20:42:35 <_ikke_> good night
2019-05-28 20:44:27 <TBK[m]> nn
2019-05-28 20:46:26 <mps> is it safe to replace FNM_EXTMATCH with FNM_NOMATCH on musl
2019-05-28 22:38:11 <tcely> I shouldn't think so.
2019-05-28 22:42:47 <mps> tcely: had a net outage, did you answered my question or something else
2019-05-28 22:43:51 <tcely> mps: "is it safe to replace FNM_EXTMATCH with FNM_NOMATCH on musl" < "I shouldn't think so."
2019-05-28 22:44:47 <tcely> I doubt very much that no match can be safely used to replace exact match
2019-05-28 22:44:48 <mps> aha, thanks. I thought so, other option is to '#define FNM_EXTMATCH 0'
2019-05-28 22:45:05 <mps> is this better
2019-05-28 22:46:01 <mps> hmm, net is really unstable now :(
2019-05-28 22:47:31 <tcely> mps: I highly recommend Quassel. Your core can be stable and the client just connects again as many times as needed. ;-)
2019-05-28 22:48:26 <mps> Quassel? apk?
2019-05-28 22:48:43 <PureTryOut[m]> Or use Matrix and join this channel via #freenode_#alpine-devel:matrix.org . You can also be stable without annoying disconnects, and it's federated as well!
2019-05-28 22:49:00 <tcely> https://pkgs.alpinelinux.org/packages?name=quassel&branch=edge
2019-05-28 22:49:21 <mps> I'm too much accustomed to irssi
2019-05-28 22:50:15 <PureTryOut[m]> Irssi with https://github.com/matrix-org/matrix-ircd then? πŸ˜‚
2019-05-28 22:51:37 <mps> PureTryOut[m]: 'cargo' on arm32?
2019-05-28 22:52:55 <PureTryOut[m]> Tbh I'm joking, I'm not sure matrix-ircd would fix the issue of missing messages, as you're still using a regular IRC client at that point
2019-05-28 22:53:26 <mps> back to my question: '#define FNM_EXTMATCH 0' is ok?
2019-05-28 22:53:34 <PureTryOut[m]> You can use Matrix with Weechat though
2019-05-28 22:54:32 <mps> would not change from irssi, I can add whatever need in simple perl script
2019-05-28 22:54:59 <north1> PureTryOut: I don't think weechat with matrix lua plugin syncs messages unless you exit completely and connects again
2019-05-28 22:55:35 <tcely> mps: https://github.com/phhusson/quassel-irssi
2019-05-28 22:55:38 <PureTryOut[m]> maxice8: what verseion of the plugin are you using? There is an old one and a way newer one that should work better iirc
2019-05-28 22:56:55 <north1> PureTryOut: i cloned the git repo
2019-05-28 22:57:14 <mps> tcely: ah, so. quassel is also 'net' ircd. i.e. proxy
2019-05-28 22:57:15 <north1> (1 or 2 weeks ago)
2019-05-28 22:57:56 <PureTryOut[m]> Which repo is that?
2019-05-28 22:58:04 <north1> PureTryOut: https://github.com/torhve/weechat-matrix-protocol-script
2019-05-28 22:58:53 <tcely> mps: the core is the irc client and handles buffer storage, highlights, accounts, etc. The client is a thinner display for the core data. Calling it a proxy is a bit inaccurate.
2019-05-28 22:59:10 <tcely> irssi can be your client with that plugin which could work well for you
2019-05-28 22:59:20 <PureTryOut[m]> <north1 "PureTryOut: https://github.com/t"> Ah it's updated. Never mind then. I assume the bug you're talking about is reported?
2019-05-28 23:00:25 <mps> aha. I use irssi on network server under tmux, and connect to it over mosh from different boxes
2019-05-28 23:01:19 <north1> PureTryOut: no, i never bothered to report it since resyncing messages on my notebok isn't much important
2019-05-28 23:01:53 <tcely> mps: 0 should be fine for FNM_EXTMATCH
2019-05-28 23:01:55 <mps> it stays connected for days, only disconnect (and auto reconnect) when somewhere on the internet some nodes are 'out of brain'
2019-05-28 23:02:40 <tcely> I found a patch for squashfs that does the same
2019-05-28 23:02:52 <mps> tcely: I also thought so, but wanted to ask if someone have more experience with this 'gnuism'
2019-05-28 23:03:44 <mps> aha, I see squashfs patch
2019-05-28 23:04:23 <mps> so I'm more assured. Also found same in openembeded ML
2019-05-28 23:04:51 <mps> looks like right (good enough) solution
2019-05-28 23:04:56 <mps> thanks again
2019-05-28 23:05:04 <tcely> you're welcome
2019-05-29 00:45:10 <north1> How long i need to wait for maintainer response ?
2019-05-29 00:45:44 <SpaceToast> however long it takes :(
2019-05-29 00:47:31 <north1> So if a maintainer just leaves without orphaning then the package is just deadlocked
2019-05-29 00:48:11 <SpaceToast> well, someone with commit access can walk in and say "let's just do it"
2019-05-29 00:48:30 <SpaceToast> but this has resulted in distracted (but otherwise present) maintainers abandoning the package in question
2019-05-29 02:58:21 <north1> pr7696 is good to go
2019-05-29 05:04:12 <north1> _ikke_: i changed the original concept of alint tags
2019-05-29 05:05:44 <_ikke_> I read your comment
2019-05-29 05:07:13 <north1> good
2019-05-29 06:21:21 <jwh> hm, bootstrap.sh is bailing, it seems to install attr-dev but then acl moans about attr/xattr.h being missing
2019-05-29 08:11:14 <jwh> huh, needs libedit adding as well for openssh
2019-05-29 08:20:55 <PureTryOut[m]> mps: u-boot has been updated to 2019.04 in Alpine. Will you submit a PR for the arm-trusted-firmware package and pine64 support or shall I update my existing PR?
2019-05-29 08:22:50 <mps> PureTryOut[m]: yes, I know becauae I posted upgrade patch for u-boot
2019-05-29 08:24:44 <mps> but I haven't had time to push arm-trusted-firmware, maybe will find some time today
2019-05-29 08:25:34 <mps> I'm working my dayjob and trying to fix some packages which doesn't build
2019-05-29 08:26:17 <PureTryOut[m]> Thanks
2019-05-29 08:26:47 <tcely> tests that fail to find an available port to bind to are annoying
2019-05-29 08:27:13 <mps> release is near and we have to concentrate on bug fixes more than on new pkgs
2019-05-29 08:53:57 <PureTryOut[m]> Would it make sense to make qt5-qtbase be built with GLESv2 rather than regular OpenGL on ARM architectures? We do this on postmarketOS, and it doesn't really seem logical to have regular OpenGL on ARM as I believe it's all GLESv2 there
2019-05-29 08:54:07 <mps> ncopa: should we upgrade ifupdown? first, it doesn't have maintainer. I worked yesterday to upgrade it to newest version and I think I'm near to finish it.
2019-05-29 09:04:47 <tcely> PureTryOut[m]: go ahead and move gpgme to community in your PR
2019-05-29 09:05:21 <tcely> We'll need to find out if anything else in main depends on gpgme at all.
2019-05-29 09:05:27 <PureTryOut[m]> Ah thanks
2019-05-29 09:07:55 <PureTryOut[m]> Several packages do it seems
2019-05-29 09:08:08 <tcely> mcabber is the only one I've found so far
2019-05-29 09:08:31 <PureTryOut[m]> mcabber, pacman, sylpheed, volume_key
2019-05-29 09:08:59 <mps> maybe mcabber can also be moved to community
2019-05-29 09:09:44 <tcely> We have to do a similar check for each of those packages if we want to move them to community also
2019-05-29 09:10:02 <tcely> there is also the support length change to be aware of
2019-05-29 09:10:20 <tcely> things in community are supported for less time than packages in main
2019-05-29 09:10:27 <mps> mcabber is not developed much upstream
2019-05-29 09:11:07 <mps> and, pacman, is it really needed in main
2019-05-29 09:11:57 <PureTryOut[m]> Huh, did you not get my last message?
2019-05-29 09:12:24 <tcely> PureTryOut[m]: the last I saw was the list of four packages
2019-05-29 09:12:53 <mps> only volume_key makes sense to keep in main, imo
2019-05-29 09:13:10 <tcely> moving volume_key means also moving libblockdev and udisks2
2019-05-29 09:13:37 <tcely> mps: we can't keep volume_key in main if we move one of its dependencies to community
2019-05-29 09:14:12 <mps> tcely: this is clear, so gpgme have to stay in main
2019-05-29 09:14:28 <PureTryOut[m]> It had 3 commits this month, last commit before that was in september (for mcabber)
2019-05-29 09:15:47 <tcely> mps: we could move all six to community
2019-05-29 09:15:54 <mps> last commit for mcabber was from me, fix colors, iirc
2019-05-29 09:16:07 <tcely> I didn't find anything that means it must be in main
2019-05-29 09:16:38 <mps> tcely: maybe volume_key have to stay in main
2019-05-29 09:16:46 <tcely> why?
2019-05-29 09:17:39 <mps> if it is used for managing volume keys?
2019-05-29 09:17:47 <PureTryOut[m]> Then how would I enable the Qt bindings?
2019-05-29 09:18:37 <mps> liblockdev depends on volume_key-dev
2019-05-29 09:19:26 <tcely> mcabber, pacman, sylpheed, volume_key, libblockdev and udisks2 all moved to community solves the interdependencies from what I can tell
2019-05-29 09:19:45 <tcely> PureTryOut[m]: to install volume_key you just need to enable community repo, like anything else in there
2019-05-29 09:20:24 <mps> tcely: that's true, but if libblockdev can be moved to community
2019-05-29 09:22:03 <tcely> mps: I'm not sure what you are getting at.
2019-05-29 09:22:18 <tcely> libblockdev can be moved as long as udisks2 is too
2019-05-29 09:24:03 <PureTryOut[m]> tcely: did you mean to notify mps there instead of me?
2019-05-29 09:24:05 <mps> yes, I understand. just telling I'm not sure if such important pkg's should be moved from main. I could be wrong, ofc
2019-05-29 09:24:50 <mps> this should be discussed with other devs
2019-05-29 09:26:41 <tcely> sure. for the purposes of the PR (which will be reviewed) PureTryOut[m] should move gpgme, mcabber, pacman, sylpheed, volume_key, libblockdev and udisks2 all to community to avoid creating broken dependencies
2019-05-29 09:28:10 <PureTryOut[m]> Yeah I just did all that, and mentioned the discussion here and at least asked ncopa what to do
2019-05-29 09:28:19 <mps> yes, it is ok, but then this PR will require 'serious' review from devs, again IMO
2019-05-29 09:28:45 <tcely> mps: added labels to reflect that
2019-05-29 09:29:20 <mps> very nice :)
2019-05-29 09:29:31 <tcely> PureTryOut[m]: I see the moves now. I prefer "dst: move from src" because it reflects current state and reads easier
2019-05-29 09:30:36 <mps> what is PR number
2019-05-29 09:30:42 <PureTryOut[m]> Oh other way around, sure
2019-05-29 09:31:14 <tcely> pr8249
2019-05-29 09:31:17 <mps> 'move from' sounds better, imo
2019-05-29 09:31:24 <PureTryOut[m]> 8249
2019-05-29 09:32:35 <PureTryOut[m]> Yeah just changed it
2019-05-29 09:33:31 <mps> I see, thanks
2019-05-29 09:36:46 <tcely> now we get to see how badly CI does building those packages ;-)
2019-05-29 09:38:10 <PureTryOut[m]> They go through fine
2019-05-29 09:38:11 <tcely> x86* is done building already. nice.
2019-05-29 09:38:11 <PureTryOut[m]> Why would it do badly?
2019-05-29 09:38:26 <tcely> lots of output and/or lots of time is often a problem for CI
2019-05-29 09:39:23 <PureTryOut[m]> Luckily it's only a few packages, current length of the output is like 1/6th of the max iirc
2019-05-29 09:55:25 <PureTryOut[m]> CI had no problems with it
2019-05-29 10:52:37 <PureTryOut[m]> When packaging a new Python library, and only caring about Python 3, should I name it py-whatever with the regular splitting stuff but keep out python 2 or should it be py3-whatever?
2019-05-29 10:53:00 <_ikke_> for now, py3-*
2019-05-29 10:53:12 <PureTryOut[m]> Ok thanks
2019-05-29 11:26:16 <ncopa> SpaceToast: i think we can wait with pr8197 til after 3.10 release. Want get the 3.10 rc1 out asap
2019-05-29 11:37:28 <ncopa> i wonder why wireguard-vanilla is rebuilt on armhf, armv7 every git push
2019-05-29 12:01:02 <mps> fcolista: what about move testing/acme.sh to community? You are maintainer so I ask you first
2019-05-29 12:01:34 <fcolista> mps, fine with me. Thx
2019-05-29 12:01:56 <mps> will I do that or you will?
2019-05-29 12:02:17 <fcolista> go ahead
2019-05-29 12:02:29 <mps> grazie mille!
2019-05-29 12:02:38 <fcolista> nessun problema
2019-05-29 12:02:39 <fcolista> :)
2019-05-29 12:02:50 <mps> :)
2019-05-29 12:05:43 <mps> molto lieto :)
2019-05-29 12:12:21 <MY_R> damn, somebody could put 'gpm' package somewhere else than 'testing', was missing it somehow while setting up alpine for desktop :D
2019-05-29 12:14:39 <mps> MY_R: does it work correctly
2019-05-29 12:15:29 <PureTryOut[m]> fcolista: could you review pr8218?
2019-05-29 12:17:17 <MY_R> mps, just checked again now and ye working fine :)
2019-05-29 12:17:53 <mps> MY_R: I think gpm could be moved to community, but we have to ask maintainer first. ncopa: what you think
2019-05-29 12:21:25 <mps> hmm, anyone have idea why oprofile is in unmaintained
2019-05-29 12:22:15 <mps> is it replaced with something better?
2019-05-29 12:22:17 <_ikke_> "This aport is disabled for years."
2019-05-29 12:23:41 <mps> but upstream is still active, and I know some people use oprofile kernel features
2019-05-29 12:24:22 <mps> and it is enabled in linux-vanilla
2019-05-29 12:25:30 <PureTryOut[m]> It still needs someone to maintain it in Alpine though
2019-05-29 12:26:21 <mps> PureTryOut[m]: that's no excuse, we have to force someone to do job :)
2019-05-29 12:26:44 <fcolista> PureTryOut[m], thanks for the PR. LGTM.
2019-05-29 12:26:54 <PureTryOut[m]> Haha sure, you can take it up if you want πŸ˜‰
2019-05-29 12:27:25 <PureTryOut[m]> fcolista: thanks! Do you have the rights to approve the PR on Github? Otherweise please leave a comment saying you approved it
2019-05-29 12:27:36 <fcolista> I've just merged :)
2019-05-29 12:27:44 <PureTryOut[m]> Oh even better! πŸ˜„
2019-05-29 12:28:21 <PureTryOut[m]> Could you remove the "waiting-for-dependencies" label from pr8204 then? And possibly retrigger the CI for it after phonon has been added to the repos?
2019-05-29 12:29:15 <_ikke_> PureTryOut[m]: done
2019-05-29 12:30:54 <_ikke_> PureTryOut[m]: ci might still fail because the new phonon package is not available yet
2019-05-29 12:31:05 <PureTryOut[m]> Thanks! Hopefully phonon is in the repos before the CI needs it then πŸ™ˆ
2019-05-29 12:31:20 <PureTryOut[m]> Yeah that's why I asked for the CI to be retriggerd after the package was available haha
2019-05-29 12:39:06 <ncopa> i get some messages on post-checkout on builders:
2019-05-29 12:39:08 <ncopa> build-edge-armv7:~/aports$ git checkout master 2>&1 | tpaste
2019-05-29 12:39:08 <ncopa> http://tpaste.us/RgyY
2019-05-29 12:39:19 <ncopa> looks for node
2019-05-29 12:41:05 <ncopa> # From npm package
2019-05-29 12:41:05 <ncopa> #   Name: husky
2019-05-29 12:41:05 <ncopa> #   Directory: /home/buildozer/aports/community/greenbone-security-assistant/src/gsa-8.0.0/gsa/node_modules/husky
2019-05-29 12:41:05 <ncopa> #   Homepage: https://github.com/typicode/husky#readme
2019-05-29 12:41:34 <ncopa> looks like greenbone-security-assistant is installing git hooks for aports
2019-05-29 12:45:09 <_ikke_> ouch
2019-05-29 12:45:28 <_ikke_> Should we redirect HOME to a temp dir in abuild?
2019-05-29 12:45:34 <_ikke_> I was thinking about that the other day
2019-05-29 12:45:44 <ncopa> would probably be a good idea yes
2019-05-29 12:46:10 <ncopa> fcolista: do you think you could have a look at greenbone-security-assistant?
2019-05-29 12:46:30 <ncopa> _ikke_: i dont think it modifies the $HOME/.git
2019-05-29 12:46:34 <ncopa> its from aports
2019-05-29 12:46:44 <_ikke_> ah, right, just the current repo
2019-05-29 12:46:57 <fcolista> ncopa, yes. It happened in my repo too :-/
2019-05-29 12:47:00 <ncopa> so i think it checkt top level of current repo
2019-05-29 12:47:55 <ncopa> and it is probably not even greenbone-security-assistant itself that does it
2019-05-29 12:48:13 <ncopa> it probably npm installs something, which pulls in husky
2019-05-29 12:48:22 <ncopa> which installs itself that way
2019-05-29 12:51:20 <danieli> it's possible for both npm and pip to install packages into ~/.npm/ and ~/.local/lib/pythonX.Y/
2019-05-29 12:51:45 <danieli> `npm install -g/--global` without sudo and pip install -U/--user respectively
2019-05-29 12:52:14 <ncopa> but is still dont expect that to modify my ~/aports/.git/hooks/*
2019-05-29 12:52:18 <danieli> oh right, it's trying to install git hooks, hmm
2019-05-29 12:52:20 <danieli> that makes absolutely no sense
2019-05-29 12:52:35 <ncopa> it installs git hooks in some other repo
2019-05-29 12:52:51 <ncopa> just because it happens to be extracted in there
2019-05-29 12:53:17 <_ikke_> Lots of projects expect to be cloned from git
2019-05-29 12:53:21 <ncopa> i think we need to put the srcdir to /var/tmp/abuild/$something
2019-05-29 12:53:51 <ncopa> and symlink to aports/main/$pkgname/srcdir
2019-05-29 12:54:00 <ncopa> for backwards compat
2019-05-29 12:54:56 <ncopa> but we can do that after v3.10
2019-05-29 12:55:24 <mps> I played little with ENV vars for src and pkg
2019-05-29 12:56:27 <mps> to put them out of aports tree
2019-05-29 12:58:20 <ncopa> fcolista: https://github.com/typicode/husky/blob/master/DOCS.md#disable-auto-install
2019-05-29 12:59:05 <ncopa> seems like you can do: export HUSKY_SKIP_INSTALL=1 # prevent husky to install git hooks for aports
2019-05-29 12:59:23 <ncopa> fcolista: can you test and fix that?
2019-05-29 12:59:33 <ncopa> i will have to manually fix all the builders
2019-05-29 13:02:53 <fcolista> doing that right now
2019-05-29 13:03:01 <PureTryOut[m]> _ikke_: Phonon has been built for all architectures used by the CI, could you retrigger the CI for my PR?
2019-05-29 13:04:33 <_ikke_> yes
2019-05-29 13:06:28 <PureTryOut[m]> Thanks! Can Travis be ignored?
2019-05-29 13:08:32 <fcolista> ncopa, export HUSKY_SKIP_INSTALL=1 does not make difference
2019-05-29 13:09:02 <fcolista> http://tpaste.us/9gvl
2019-05-29 13:10:04 <ncopa> fcolista: try move it to package()
2019-05-29 13:10:12 <ncopa> or add it to package as well
2019-05-29 13:10:28 <ncopa> maybe its check too
2019-05-29 13:11:03 <fcolista> isn't global?
2019-05-29 13:11:31 <fcolista> I've added in all three functions()
2019-05-29 13:13:18 <fcolista> nah
2019-05-29 13:13:24 <fcolista> still the same
2019-05-29 13:13:44 <fcolista> it happens before package() though
2019-05-29 13:14:01 <fcolista> it's in build()
2019-05-29 13:14:18 <fcolista> I think I need to patch the makefile for npm somewhere
2019-05-29 13:19:03 <fcolista> anyway, I think we can simply remove husky
2019-05-29 13:19:18 <fcolista> since according to package.json is a dev dependency
2019-05-29 13:22:52 <PureTryOut[m]> Awesome, CI went through successfully. pr8204 should be good to go after a review now
2019-05-29 13:29:06 <jubalh> hi
2019-05-29 13:32:15 <PureTryOut[m]> Hi
2019-05-29 13:59:59 <jubalh> how does one become package maintainer in alpine?
2019-05-29 14:00:38 <jubalh> in particular there is one package that i'm missing and that i would like to contribute and then maintain. but the question is generally interesting to understand the process
2019-05-29 14:01:15 <north1> jubalh: contribute a new package or adopt a package without a maintainer or transfer maintainership of a maintained package
2019-05-29 14:04:27 <TBK[m]> jubalh: make a PR against https://github.com/alpinelinux/aports https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2019-05-29 14:05:38 <jubalh> TBK[m]: awesome that's what i have been looking for. thanks!
2019-05-29 14:06:35 <jubalh> TBK[m]: is there a concept of fixed maintainers for some packages or everybody can contribute wherever he wants and a set of people reviews all PRs?
2019-05-29 14:07:56 <north1> There are fixed maintainers but people with commit access might decide to push without a maintainer review
2019-05-29 14:09:26 <jubalh> And maintainers don't have commit acces but all gets in via the team?
2019-05-29 14:10:35 <jubalh> so in the scenario where I would create such a request to update herbstluftwm (for example) the team would see my PR but the actual maintainer wouldnt get notified?
2019-05-29 14:10:51 <jubalh> 
ACTION looks at https://github.com/alpinelinux/aports/pull/8255/ where the person who created the PR is also the maintainer

2019-05-29 14:12:21 <_ikke_> jubalh: If the changes are significant, we usually notify the maintainer
2019-05-29 14:12:35 <_ikke_> if it's just a trivial fix or a minor upgrade, we just apply it
2019-05-29 14:13:14 <jubalh> _ikke_: alright
2019-05-29 14:13:27 <jubalh> thanks for these infos
2019-05-29 14:14:33 <Cogitri> Someone with arm* up for testing pr8257?
2019-05-29 14:14:33 <TBK[m]> jubalh: all new aports start in the testing repo. PR shoudl be named "testing/xxxxxxx: new aport"
2019-05-29 14:15:01 <_ikke_> usually mps has some arm syste he can test on
2019-05-29 14:15:22 <mps> yes, just looking at it
2019-05-29 14:15:47 <Cogitri> Thank you :)
2019-05-29 14:16:02 <Cogitri> The CI timeout is too short to test it on all arches, sadly
2019-05-29 14:16:16 <mps> np, your work deserves my effort :)
2019-05-29 14:16:32 <clandmeter> nicely spoken!
2019-05-29 14:17:02 <mps> Alpinists are nice people ;)
2019-05-29 14:24:30 <Cogitri> :)
2019-05-29 14:25:55 <PureTryOut[m]> mps: I can agree!
2019-05-29 14:42:20 <PureTryOut[m]> Where can I find the implementation of default_doc?
2019-05-29 14:45:57 <[[sroracle]]> PureTryOut[m]: https://git.alpinelinux.org/abuild/tree/abuild.in#n1620
2019-05-29 14:46:20 <[[sroracle]]> (it is part of /usr/bin/abuild)
2019-05-29 14:46:40 <PureTryOut[m]> Thanks!
2019-05-29 14:57:03 <_ikke_> I regularly consult the source to verify what it does
2019-05-29 15:07:35 <mps> Cogitri: for webkit2gtk on aarch64 I got: make: *** No rule to make target 'install'.  Stop.
2019-05-29 15:15:32 <Cogitri> Huh, mind sending the entire log?
2019-05-29 15:16:54 <mps> have to rerun it because didn't redirected it to file
2019-05-29 15:17:15 <mps> but now trying on armv7
2019-05-29 15:18:22 <Cogitri> Ah, okay
2019-05-29 15:18:33 <Cogitri> Yeah, it's pretty hard to really say anything without having a full log :c
2019-05-29 15:18:52 <mps> but looks like it is stuck on armv7
2019-05-29 15:19:27 <mps> ok, will post when it finish
2019-05-29 15:19:50 <mps> and armv7 stuck with this: [ 55%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-6cbc989f-2.cpp.o
2019-05-29 15:20:33 <Cogitri> Maybe it just takes a long time to build it
2019-05-29 15:20:55 <mps> I'm waiting to see
2019-05-29 15:21:53 <mps> but look time from 'ps'
2019-05-29 15:21:58 <mps> 43782 pts/6    R+     9:48 /usr/libexec/gcc/armv7-alpine-linux-musleabihf/8.3.0/cc1plus -quiet -I /home/mps/aports/community/webkit2gtk/src/webkitgtk-2.24.2/build/
2019-05-29 15:22:26 <Cogitri> Huh, on https://cloud.drone.io/alpinelinux/aports/5900/4/1 it is stuck on the same file
2019-05-29 15:23:07 <Cogitri> Same on x86
2019-05-29 15:23:14 <mps> I'll left it for some time to see
2019-05-29 15:23:27 <Cogitri> And x86_64 has failed with the same error has aarch64, so you don't have to re-run that, thank you
2019-05-29 15:24:21 <mps> I already restarted it on aarch64
2019-05-29 15:25:37 <Cogitri> Ah, you can cancel that one then, I guess
2019-05-29 15:26:10 <mps> np, will let it work to the end and post log so you can see it
2019-05-29 15:57:11 <ncopa> wireguard-vanilla gets rebuilt every git push for some reason
2019-05-29 16:04:44 <PureTryOut[m]> So somebody has removed celt051 from the edge repos, but didn't remove the dependency from spice which is causing issues. Is everybody fine with me just removing celt051 support from spice?
2019-05-29 16:05:58 <north1> PureTryOut: there is an update for spice-gtk
2019-05-29 16:06:04 <north1> I have a PR that removes it and replaces with opus support insteady
2019-05-29 16:06:17 <PureTryOut[m]> Ah, could that be merged quickly please? 😺
2019-05-29 16:06:45 <north1> It is mentioned in the PR that removed celt051 if I remember correctly
2019-05-29 16:07:36 <PureTryOut[m]> One of the tests is failing btw
2019-05-29 16:08:50 <north1> I'm not in a position to fix it right now
2019-05-29 16:23:03 <ncopa> I'll have a look at it
2019-05-29 16:23:35 <ncopa> mksully: e2fsprogs fails on ppc64le
2019-05-29 16:23:49 <ncopa> mksully22: ^^^
2019-05-29 16:24:38 <clandmeter> ncopa, did i break it?
2019-05-29 16:25:13 <ncopa> clandmeter: yes with commit fa40f1448539a367f6d13b48c64b79d64d16105c
2019-05-29 16:26:04 <clandmeter> ?
2019-05-29 16:26:18 <ncopa> sorry i misread
2019-05-29 16:26:26 <ncopa> i read it as "did you break it"
2019-05-29 16:27:07 <clandmeter> I mean wireguard
2019-05-29 16:27:32 <ncopa> clandmeter: i dont know. it looks like a but in lua-aports
2019-05-29 16:27:37 <ncopa> bug*
2019-05-29 16:44:51 <MY_R> hmm so that is why mumble in edge showing that "Unable to find matching CELT codecs with other clients. You will not be able to talk to all users." thought mumble provide that lib by self
2019-05-29 16:48:50 <ncopa> MY_R: it shouldn't make any difference
2019-05-29 16:48:57 <ncopa> its built with bundled celt
2019-05-29 16:49:10 <MY_R> yep I see, just checked build log
2019-05-29 16:50:28 <MY_R> so probably I just misunderstood that "warning" :)
2019-05-29 16:52:06 <MY_R> or maybe it have something to do with this: https://bugzilla.redhat.com/show_bug.cgi?id=1711435
2019-05-29 16:59:57 <MY_R> and 'ldd /usr/bin/mumble' doesnt show anything from '/usr/lib/mumble/', or dunno I'm not good with all that :D
2019-05-29 17:40:17 <mps> Cogitri: where I can send webkit2gtk-build.log, it is 1.5MB size
2019-05-29 17:41:40 <Cogitri> GitHub gists should work, I guess
2019-05-29 17:42:08 <mps> do I must have GH account for that
2019-05-29 17:43:20 <danieli> yes
2019-05-29 17:44:37 <mps> ok, here it is http://arvanta.net/mps/webkit2gtk-build.log.gz
2019-05-29 17:44:51 <Cogitri> Found the reason Aarch64 and x86_64 fail, so I don't need that long anymore, I suppose
2019-05-29 17:45:40 <mps> and armv7 is still at the state I posted you before about two hours
2019-05-29 17:46:09 <mps> I will kill it now
2019-05-29 18:17:35 <_ikke_> any idea why make check succeeds, but abuild check (which calls make check), some tests fail / hang?
2019-05-29 18:19:23 <_ikke_> ah, -j1 I guess
2019-05-29 18:19:57 <_ikke_> yes
2019-05-29 18:49:17 <Cogitri> PureTryOut: I think your Qt upgrade might have broken Nextcloudclient?
2019-05-29 18:49:36 <PureTryOut[m]> My Qt upgrade?
2019-05-29 18:49:39 <Cogitri> At least it only `SIGABRT`s now after the upgrade
2019-05-29 18:49:46 <Cogitri> Didn't you bump Qt, or was that just KDE stuff? πŸ˜…
2019-05-29 18:50:10 <PureTryOut[m]> I didn't bump Qt stuff
2019-05-29 18:50:17 <Cogitri> Oh, sorry then
2019-05-29 18:50:22 <PureTryOut[m]> I did add new KDE stuff
2019-05-29 18:50:40 <_ikke_> Cogitri: He just built phonon against qt56
2019-05-29 18:50:40 <Cogitri> Ah, my bad
2019-05-29 18:50:42 <_ikke_> Cogitri: He just built phonon against qt5
2019-05-29 18:51:01 <_ikke_> PureTryOut[m]: looking at kde-framework tier 2 now
2019-05-29 18:51:02 <PureTryOut[m]> I did move Phonon from Qt4 to Qt5, but I doubt that has anything to do with Nextcloud
2019-05-29 18:51:11 <_ikke_> the test suite is green :-)
2019-05-29 18:51:14 <_ikke_> I mean, CI
2019-05-29 18:51:37 <Cogitri> Ah, alright, somehow I mixed him and fcolista up, my bad
2019-05-29 18:52:23 <PureTryOut[m]> Yup!
2019-05-29 18:52:29 <PureTryOut[m]> Thanks in advance for reviewing it πŸ˜ƒ
2019-05-29 18:54:19 <_ikke_> Anyone got a nice and simple solution for sharing a clipboard over ssh (without X)? Basically I just want to be able to send something from a remote machine back to my workstation with a command
2019-05-29 19:00:51 <_ikke_> PureTryOut[m]: Did you mean to commit these extra files https://github.com/alpinelinux/aports/pull/8204/commits/0e141282a64a8672f4afb1dccd6733a8dc3d2511 ?
2019-05-29 19:01:25 <north1> Need ci-malfunction for pr8264 , drone-ci armv7 failed because it couldn't fetch the source code
2019-05-29 19:01:39 <_ikke_> PureTryOut[m]: they are not listed in source, so I guess not
2019-05-29 19:02:16 <_ikke_> north1: is that a temporary error?
2019-05-29 19:02:25 <_ikke_> I could retrigger the build
2019-05-29 19:03:23 <north1> Sure
2019-05-29 19:03:24 <north1> Please do
2019-05-29 19:03:48 <_ikke_> Done already ;-)
2019-05-29 19:04:24 <north1> thank you
2019-05-29 19:04:54 <_ikke_> armv7 now finished
2019-05-29 19:06:32 <north1> nice
2019-05-29 19:06:34 <_ikke_> all green :)
2019-05-29 19:09:02 <PureTryOut[m]> _ikke_: no not sure how they ended up there. Removed them
2019-05-29 19:12:43 <north1> _ikke_: S U P E R N I C E
2019-05-29 19:17:55 <_ikke_> PureTryOut[m]: pushed
2019-05-29 19:18:33 <PureTryOut[m]> Awesome, thanks!
2019-05-29 19:20:16 <_ikke_> north1: spice-gtk is failing to build
2019-05-29 19:21:52 <_ikke_> north1: 8/10 spice-gtk / test-session                FAIL     0.05 s (killed by signal 5 SIGTRAP)
2019-05-29 19:21:56 <north1> _ikke_: is it failing that one test PureTryOut mentioned ?
2019-05-29 19:22:19 <_ikke_> I guess so
2019-05-29 19:24:22 <PureTryOut[m]> Yeah that's the one
2019-05-29 19:26:07 <north1> Ok i am now
2019-05-29 19:26:07 <north1> in a position to look into it
2019-05-29 19:34:04 <north1> it fails on all arches ?
2019-05-29 19:34:05 <north1> worked for me here
2019-05-29 19:34:56 <TBK[m]> yes all archs
2019-05-29 19:36:36 <north1> seems to be a CI thing then
2019-05-29 19:37:12 <_ikke_> This is no longer CI ;-)
2019-05-29 19:38:29 <_ikke_> north1: fails for me as well, in lxc
2019-05-29 19:38:51 <_ikke_> traps: test-session[734] trap int3 ip:7fbe9fff5994 sp:7fff3e649830 error:0
2019-05-29 19:38:53 <_ikke_>  in libglib-2.0.so.0.5800.1[7fbe9ffcb000+5d000]
2019-05-29 19:39:00 <_ikke_> from dmesg
2019-05-29 19:41:17 <north1> No clue what to do then, works here and i can't run the build inside a docker container
2019-05-29 19:42:06 <_ikke_> It does complain about usbutils missing during build
2019-05-29 19:42:27 <_ikke_> (/home/build/aports/community/spice-gtk/src/spice-gtk-0.37/output/tests/test-session:41046): GSpice-WARNING **: 19:38:07.764: Error initializing USB support: Other error [-99]
2019-05-29 19:42:33 <_ikke_> on stderr from the test
2019-05-29 19:45:33 <north1> adding usbutils didn't actually remove that error for me
2019-05-29 19:46:10 <_ikke_> neither for me
2019-05-29 19:46:37 <_ikke_> How can I disable optimization with meson / ninja?
2019-05-29 19:47:43 <SpaceToast> _ikke_: --buildtype plain
2019-05-29 19:47:45 <SpaceToast> on meson
2019-05-29 19:47:52 <SpaceToast> ninja is just minimal `make`
2019-05-29 19:48:16 <SpaceToast> default is debug (`-g`)
2019-05-29 19:56:24 <north1> need attention on pr8225
2019-05-29 19:56:25 <north1> special case where upstream has a new versioning that is lower than the one used currently
2019-05-29 19:57:31 <_ikke_> north1: :-/
2019-05-29 20:01:35 <north1> _ikke_: :[]
2019-05-29 20:02:13 <_ikke_> north1: I suspect that it requires a usb controller available?
2019-05-29 20:02:18 <_ikke_> (spice-gtk)
2019-05-29 20:03:22 <_ikke_> north1: https://bugzilla.redhat.com/show_bug.cgi?id=1446016
2019-05-29 20:03:42 <TBK[m]> https://gitlab.com/spice/spice-gtk/blob/master/.gitlab-ci.yml
2019-05-29 20:04:27 <_ikke_> meson --buildtype=release build-feat-disabled -Dauto_features=disabled ?
2019-05-29 20:04:28 <north1> _ikke_: i have no clue
2019-05-29 20:13:20 <north1> mkinitfs has no license file or headers
2019-05-29 20:30:32 <_ikke_> north1: any clue how I can disable that specific test?
2019-05-29 20:30:46 <_ikke_> Have been looking, but could not really find an easy way
2019-05-29 20:31:50 <north1> I got a PR for it
2019-05-29 20:32:12 <north1> Just remove session.c from the first array in tests/meson.build
2019-05-29 20:32:29 <north1> There is also the --no-suite option from meson test
2019-05-29 20:33:05 <_ikke_> I just overlooked that file
2019-05-29 20:33:11 <_ikke_> tests/meson.build
2019-05-29 21:51:12 <Cogitri> What license should I add for metapackages?
2019-05-29 22:44:40 <awilfox> hi there- we have found at least six bugs in APK; would it be better to file each individually on bugs.a.o, or one big metabug, or start an ML thread to discuss them?
2019-05-29 22:48:39 <mps> awilfox: whatever you think is appropriate, and maybe both options, i.e. bugs.a.o and alpine-devel ML
2019-05-29 22:48:49 <awilfox> we've been trying to compile a list with examples at https://wiki.adelielinux.org/wiki/APK_bugs
2019-05-29 22:48:53 <Cogitri> Although I'm not involved in APK development I'd say the first option is the best
2019-05-29 22:49:20 <awilfox> but probably over the weekend I'll generate some easy to follow example APKBUILDs to trigger the bugs if I can
2019-05-29 22:51:16 <mps> `apk del pkgname` is discussed already, iirc
2019-05-29 22:53:32 <mps> your list will be useful, to have bugs with examples in one place
2019-05-29 22:54:14 <mps> most reports or complaints about apk bugs were from #alpine-linux channel
2019-05-29 22:54:28 <awilfox> aye :)  we did this once before with notes about python2 and python3, and ddevault had said it was useful
2019-05-29 22:57:09 <mps> as experienced developer you know how good bug report is useful ;)
2019-05-30 04:42:43 <_ikke_> north1: fyi, I pushed a commit to disable that test for spice-gtk
2019-05-30 04:43:27 <north1> I had and have a PR for it
2019-05-30 04:43:29 <north1> Nice anyways
2019-05-30 04:43:41 <_ikke_> I was waiting for that PR
2019-05-30 04:43:43 <_ikke_> but didnt see it
2019-05-30 04:43:46 <_ikke_> and it was blocking the builders
2019-05-30 10:07:47 <mps> main/postgresql now pass perl test (with latest perl upgrade/fix)
2019-05-30 10:09:19 <mps> '_run_tests src/pl' could be commented out in check(), tested it on armv7
2019-05-30 11:19:59 <tmhoang> o/
2019-05-30 11:21:03 <danieli> \o
2019-05-30 11:59:10 <ncopa> awilfox: how will fetch first solve the connection interruption problem?
2019-05-30 11:59:46 <danieli> ncopa: awilfox isn't here
2019-05-30 12:00:39 <ncopa> oh. ok
2019-05-30 12:08:16 <hjaekel> ncopa, do you have time to review my pr7938? it's a substantial change to the proj4 package, and you are the maintainer.
2019-05-30 12:23:08 <mps> ncopa: I looked at awilfox bug list, not sure if the first one is bug at all
2019-05-30 12:24:12 <mps> he told that he will prepare a better list and post it on bugs.a.o or alpine-devel ML
2019-05-30 12:31:31 <mps> what is with these removals of 'cd $builddir' in last aports merges? I noticed a lot of this in last days
2019-05-30 12:32:03 <p4Wv1qn095FW> it is done anyway by abuild, no need to do it explicitly, if builddir is set correctly
2019-05-30 12:32:08 <mps> hjaekel: are you Kelvin by chances?
2019-05-30 12:33:17 <hjaekel> no, I'm not Kelvin.... I removed cd $builddir because maxice8 told me so
2019-05-30 12:33:39 <mps> p4Wv1qn095FW: I thought so, but before start to removing them wanted to ask is it ok and safe
2019-05-30 12:34:07 <p4Wv1qn095FW> for a long time i believe it is like this
2019-05-30 12:34:13 <north1> mps: see alint.5 from atools
2019-05-30 12:34:30 <mps> hjaekel: I asking because there is patch for proj4 upgrade on pw.a.o and there is PR on GH
2019-05-30 12:35:09 <mps> not sure which of these patches should be merged
2019-05-30 12:36:03 <mps> north1: didn't yet added atools. Is it safe to add, i.e. are atools works fine
2019-05-30 12:36:31 <clandmeter> how can a lint tool be unsafe?
2019-05-30 12:36:58 <clandmeter> eats code for breakfast?
2019-05-30 12:37:05 <mps> false negative/positive maybe
2019-05-30 12:37:22 <clandmeter> you still need to verify yourself
2019-05-30 12:37:34 <mps> clandmeter: :D
2019-05-30 12:37:52 <north1> It is a linter not a fixer
2019-05-30 12:38:07 <mps> aha, 'hinter'
2019-05-30 12:38:08 <hjaekel> mps, kelvinn's pr just upgrades the version, but my pr does some more things: rename package, add check() add subpackages fόr java, utilities, and datum grids and fixes bug #10434
2019-05-30 12:38:24 <north1> Assuming it was updated to the last version it will label each violation with severity and certainty
2019-05-30 12:39:31 <mps> hjaekel: ok, I will look for both, just wanted to ask if the patch on pw.a.o and GH PR from same person to skip one of them
2019-05-30 12:41:14 <mps> ncopa: have you seen my note about postgresql plperl test here (few hours ago)
2019-05-30 12:42:00 <hjaekel> thank you mps
2019-05-30 12:42:15 <mps> hjaekel: np, yo're welcome
2019-05-30 13:12:15 <ncopa> mps: possibly :)
2019-05-30 13:13:54 <ncopa> ok. i foudn it
2019-05-30 13:14:34 <mps> ncopa: also tested on aarch64
2019-05-30 13:14:45 <ncopa> im testing x86_64 as we speak
2019-05-30 13:14:52 <ncopa> i think i did that when it broke last time
2019-05-30 13:14:59 <mps> nice, hope it will work
2019-05-30 13:15:03 <ncopa> and thought it would fix it
2019-05-30 13:15:06 <ncopa> but iirc it didnt
2019-05-30 13:15:30 <ncopa> there is no reason why it should not work at this point
2019-05-30 13:15:35 <mps> it breaks before last perl fix, yes. but now it worked for me
2019-05-30 13:15:54 <ncopa> i think i commented out the test as a try to fix it
2019-05-30 13:16:00 <ncopa> but it didnt
2019-05-30 13:16:15 <ncopa> so i removed plperl as temp workaround
2019-05-30 13:16:26 <ncopa> so yes, we should enable the test again
2019-05-30 13:16:33 <ncopa> thanks for reminding me about it
2019-05-30 13:16:43 <mps> I remember. this was my first test after you fixed perl :)
2019-05-30 13:17:08 <ncopa> looks like builders are busy with openjdk7
2019-05-30 13:17:22 <ncopa> i think once openjdk is done we could tag 3.10_rc1?
2019-05-30 13:17:46 <mps> btw, some people asked to move gpm to community.
2019-05-30 13:18:27 <ncopa> ok with me. we should probaly clean it up a git
2019-05-30 13:18:27 <mps> I think it could be moved without problem
2019-05-30 13:18:32 <ncopa> fix license
2019-05-30 13:19:24 <mps> aha, will look later. I made my personal gpm before it appeared in aports, but didn't posted patch
2019-05-30 13:19:54 <mps> I will look again at it, when I finish proj4 fixes and upgraded
2019-05-30 13:21:21 <mps> another question, I started to upgrade ifudown. It needs some fixes and cleanup but not sure should we upgrade it before or after 3.10 release. what you think
2019-05-30 13:22:46 <Cogitri> I guess I don't really know Alpine's release scheme, but I guess there's no chance to get LLVM8&Rust 1.35 in there anymore?
2019-05-30 13:22:59 <Cogitri> Because then I'll have to look into FF 67 w/ Rust 1.34 and LLVM7
2019-05-30 13:26:29 <mps> Cogitri: I understand you. At first look it doesn't look to hard, but when you dive deeper you see a lot of issue. this is my experience with rust+llvm
2019-05-30 13:26:52 <danieli> yeah, it can be like an onion
2019-05-30 13:26:56 <danieli> peel off a layer and there's another beneath
2019-05-30 13:28:20 <mps> and you have known eyes reaction ;)
2019-05-30 13:28:29 <Cogitri> Well, don't mind messing with it to be honest, but LLVM7 + Rust don't do well together it appears
2019-05-30 13:29:18 <mps> llvm7 is bug, imo
2019-05-30 13:29:24 <danieli> my point is that it's nice to defer including it in a stable release until we're fairly sure it actually is stable
2019-05-30 13:29:39 <mps> not worth to waste time on this version
2019-05-30 13:37:02 <mps> hjaekel: your PR have 15 commits
2019-05-30 13:38:36 <tcely> mps: why is that a point worth mentioning?
2019-05-30 13:39:33 <mps> how to test all these different changes? I think we should go one by one
2019-05-30 13:39:45 <Cogitri> danieli: Hm, alright. I guess I'll mess with FF and LLVM7
2019-05-30 13:40:39 <danieli> Cogitri: do you think the potential stability tradeoff is worth it? it might just be if rust with llvm7 works really badly or not at all
2019-05-30 13:40:40 <hjaekel> mps, should I sqash them?
2019-05-30 13:40:46 <Cogitri> Be aware that that'll make FF a fair bit slower because we can't compile the Rust code with (the equivalent of) -O3 then and can't use the new shiny SIMD stuff
2019-05-30 13:40:48 <tcely> why does going one by one help?
2019-05-30 13:42:00 <mps> tcely: less burden to maintainers, reviewers and commiter
2019-05-30 13:42:33 <Cogitri> Yup, PRs can contain multiple commits just fine if they're related
2019-05-30 13:42:52 <mps> looking this one from hjaekel for proj I simply don't dare to apply it and test everything changes
2019-05-30 13:43:08 <Cogitri> danieli: Now I'm confused, do you mean s/llvm7/llvm8/?
2019-05-30 13:43:35 <ncopa> Cogitri: release schema is time based. every 6month, May and November
2019-05-30 13:43:39 <mps> sorry hjaekel, it is too much for my taste
2019-05-30 13:43:44 <tcely> I don't see a reason to care about the number of commits. git am the full set and test once.
2019-05-30 13:44:00 <ncopa> Cogitri: how much work do you think it is with llvm8?
2019-05-30 13:44:09 <ncopa> do we also upgrade clang, lldb and those?
2019-05-30 13:44:30 <ncopa> should we rebuild everything that was built with clang7?
2019-05-30 13:44:33 <mps> 'git am' will do, but check if every package builds is much more
2019-05-30 13:45:15 <ncopa> if llvm7 is known to be broken and llvm8 is known to be a generally good release, then i think we should try get it squezed in
2019-05-30 13:45:45 <hjaekel> mpr, ok then I will split it up into multiple pr
2019-05-30 13:46:24 <tcely> unless CI malfunctioned or doesn't cover the architecture, checking that it builds shouldn't be a manual process.
2019-05-30 13:46:38 <ncopa> re commits and PRs
2019-05-30 13:47:18 <ncopa> i think it makes sense to have multiple commits in a single PR if they are related some way or another
2019-05-30 13:47:37 <ncopa> for example, one library upgrade breaks ABI, and N packages needs to be rebuilt
2019-05-30 13:47:45 <ncopa> makes sense to have them in all same PR
2019-05-30 13:47:56 <mps> ncopa: llvm.org announced llvm7.1 at the beginning on Feb with important fixes, but didn't released and announce about it is removed from their site
2019-05-30 13:47:56 <Cogitri> ncopa: LLVM8 means to at least bump clang to 8 too, otherwise stuff that links against both libllvm and libclang blows up
2019-05-30 13:48:30 <Cogitri> I don't think we have to panic-merge it in 3.10, but can we get it in 3.10.1? Not sure what the rules on that are
2019-05-30 13:49:03 <Cogitri> LLVM7 is generally broken on Aarch64-musl, yes :c
2019-05-30 13:49:20 <mps> imo, keeping llvm6 or upgrade to llvm8 is options. And again to repeat, In My Uneducated Opinion but from my experience
2019-05-30 13:49:30 <ncopa> other packages that may make sense to upgrade in same PR are qt5-* packages, xfce* packages, mate-* packages etc
2019-05-30 13:49:40 <Cogitri> At least on Void LLVM8 was just fine - not that that had to mean much
2019-05-30 13:49:47 <ncopa> if they are connected or related in one way or another, they can go in same PR
2019-05-30 13:50:02 <Cogitri> mps: Sadly Rust doesn't work at least on x86 with llvm6 anymore :/
2019-05-30 13:50:02 <ncopa> multiple commits vs one big big commit
2019-05-30 13:50:29 <ncopa> we normally prefer multiple commits because it makes it easier to cherry pick things to stable branches
2019-05-30 13:50:52 <ncopa> so security fixes that should be backported to stable branches should be in their own commits
2019-05-30 13:50:58 <mps> Cogitri: rust didn't worked on x86 Alpine never
2019-05-30 13:51:19 <ncopa> but commits that are fixups of previously bad commits should be squashed
2019-05-30 13:51:46 <ncopa> so if you got ffedback on things that could be improved, then the improvement can be squashed
2019-05-30 13:51:59 <Cogitri> mps: Yes, bit that's something I want to work on with llvm8 :)
2019-05-30 13:52:13 <ncopa> so that we afterwards, when we do git log, always have "good" commits in our git history
2019-05-30 13:52:46 <ncopa> IOW it does not make sense to have reverts in a PR that revert a commit from the same PR
2019-05-30 13:52:57 <ncopa> then its better to rebase and remove the bad commit
2019-05-30 13:53:36 <ncopa> can llvm8 completely replace llvm7?
2019-05-30 13:53:47 <tcely> Given the current state of llvm7 I'd rather have 8 than 7 no matter how much time / work that costs
2019-05-30 13:53:59 <ncopa> or do we need keep llvm7 in addition to llvm8
2019-05-30 13:54:11 <Cogitri> Let me check that
2019-05-30 13:54:27 <Cogitri> Can I get packages that depend on llvm from pkgs.alpinelinux.org?
2019-05-30 13:54:35 <Cogitri> Not on my laptop rn
2019-05-30 13:55:16 <tcely> I don't think pkgs tracks check/make depends
2019-05-30 13:55:22 <mps> tcely: tend to agree with you about llvm state
2019-05-30 13:56:20 <Cogitri> Only ponyc needs llvm7, but it could do with llvm6 too
2019-05-30 13:56:37 <mps> hjaekel: I hope that you read ncopa's explanation about commits and PR's. so you decide what you will do and do not follow my 'advice' (moaning, tbh)
2019-05-30 13:56:41 <Cogitri> (Or 3.9&5 as it does rn, but I'll work on removing at least 5 too)
2019-05-30 13:58:56 <mps> with Cogitri's llvm8 PR I built llvm8 on aarch64, armv7 and x86_64 without problem
2019-05-30 13:59:55 <mps> tried to build rust on aarch64 with this llmv8 and it build but tests failed
2019-05-30 14:00:23 <Cogitri> What Rust?
2019-05-30 14:00:37 <tcely> Which compiler was used to build llvm8?
2019-05-30 14:00:42 <Cogitri> I think I'll just bootstrap Rust 1.35 from the upstream tarballs
2019-05-30 14:00:50 <Cogitri> (I mean the cross arches)
2019-05-30 14:01:17 <mps> Cogitri: rust 1.33
2019-05-30 14:02:27 <Cogitri> Ah, Rust 1.33 isn't exactly compatible with LLVM8, soooo
2019-05-30 14:02:32 <Cogitri> tcely: I guess gcc
2019-05-30 14:04:42 <tcely> Cogitri: some version of llvm with clang is also an option.
2019-05-30 14:05:15 <mps> Cogitri: yes, I know this versions links with rust and llvm, but tried to see what will happen
2019-05-30 14:06:09 <hjaekel> mps, yes I have read ncopa's explanation. my changes are all related to the proj4 packages, but they can be split up into 1. version upgrade; 2. new subpackages; 3. renaming
2019-05-30 14:06:35 <hjaekel> I will create new pr for this package
2019-05-30 14:08:07 <tcely> All. Which do you prefer? Rename then changes or change then rename?
2019-05-30 14:08:42 <mps> I only successfully build rust on armv7 and aarch64 with llvm6 (my private version) and rust 1.31
2019-05-30 14:09:29 <Cogitri> tcely: Sorry?
2019-05-30 14:10:06 <mps> tcely: for proj I think rename first, don't know why it is named proj4 at all
2019-05-30 14:10:34 <hjaekel> first changes then rename because rename is optional I would say
2019-05-30 14:10:34 <tcely> Do you prefer to move first then make changes or move as last step?
2019-05-30 14:10:46 <mps> hjaekel: I pushed upgrade already
2019-05-30 14:12:21 <hjaekel> mps, OK that would also be my first step
2019-05-30 14:13:43 <mps> out of curiosity, why it needs java
2019-05-30 14:14:26 <hjaekel> mps, now you have to bump all dependent packages, right?
2019-05-30 14:15:17 <mps> doesn't builders detect this?
2019-05-30 14:15:51 <mps> and is there ABI changes by this upgrade
2019-05-30 14:16:05 <hjaekel> last time a upgraded a version I was asked to bump dependent packages
2019-05-30 14:16:37 <hjaekel> mps, there is a dependendy to java because I added a new subpackage for java bindings
2019-05-30 14:17:15 <mps> I think it is needed only on ABI change, and some API changes
2019-05-30 14:18:24 <hjaekel> mps, there is a soname change
2019-05-30 14:19:08 <mps> then it dependants should be bumped
2019-05-30 14:19:30 <mps> s/it /it's /
2019-05-30 14:19:30 <alpine-meetbot> mps meant to say: then it's dependants should be bumped
2019-05-30 14:20:17 <hjaekel> andypost mentiond that in the pr
2019-05-30 14:20:41 <mps> aha, I see
2019-05-30 14:21:41 <hjaekel> I think it is not only libgeotiff, you can see the list of packages from my pr
2019-05-30 14:21:43 <mps> ok, please tell me do you think it is safe to merge your PR
2019-05-30 14:22:02 <hjaekel> some dependent packages even need fixes for the new proj version
2019-05-30 14:22:05 <mps> I have seen all changes
2019-05-30 14:23:22 <hjaekel> e.g. for libgeotiff you need to upgrade the version to work with proj 6
2019-05-30 14:26:16 <mps> hjaekel: please, could you rebase your patches with current proj4 in aports and post it. I will try to apply it and see does it works
2019-05-30 14:30:06 <hjaekel> I will try it, but I think that's not the way ncopa meant it :-)
2019-05-30 14:33:35 <mps> ok, I wrote do whatever you think will work and don't follow my 'advice'. I only can tell for now that I will look when you announce change and help if can
2019-05-30 14:34:16 <mps> and, sorry if I somehow mislead you. that was not my intention
2019-05-30 14:38:04 <hjaekel> mps, no problem, I am trying to rebase now
2019-05-30 14:52:58 <hjaekel> mpr, I rebased my branch. So if you need an immediate fix for the currently broken packages in edge, you can use this branch. I would prefer to create new smaller pr's but then you have to live with the broken packages for some days
2019-05-30 14:57:43 <mps> hjaekel: np, it is edge (i.e. testing) at the end
2019-05-30 14:58:32 <mps> if this pkg is only broken I will go out and start 'singing on the rain'
2019-05-30 15:04:02 <tcely> Those rebuilds that were just merged, will they work?
2019-05-30 15:04:45 <tcely> I would think the upgrade would need to be on mirrors before the rebuild goes to builders
2019-05-30 15:08:57 <hjaekel> mps, it's good that you are so relaxes about testing,but I feel a little pressure on me now to fix all the broken packages. I would have preferred that you did not merge the broken pr from kelvinn
2019-05-30 15:11:27 <mps> hjaekel: it is not broken
2019-05-30 15:13:00 <mps> I tested it on three arch's
2019-05-30 15:13:47 <hjaekel> you tested libgeotiff?
2019-05-30 15:14:12 <mps> no
2019-05-30 15:14:36 <hjaekel> and did you test mapserver, postgis, mapnit, pdal, libspatiallite?
2019-05-30 15:14:44 <hjaekel> those packages are broken now
2019-05-30 15:15:17 <hjaekel> because of the change of soname
2019-05-30 15:15:21 <mps> that's ok, we will fix it when someone send patches or bug reports
2019-05-30 15:15:49 <mps> if we could fix them, of course
2019-05-30 15:16:42 <hjaekel> no, thats not how it should go. Kelvinn should have send the patches
2019-05-30 15:16:50 <hjaekel> as I did in my pr
2019-05-30 15:18:00 <mps> yes, you patch is better but we could not ignore Kelvin's PR also
2019-05-30 15:22:33 <hjaekel> why can we not ignore a pr that breaks 6 previously working packages?
2019-05-30 15:24:41 <mps> I asked few days ago (or week, don't remember exactly) about all these patches to be merged and fixed and if you (authors) could work together but no one tried anything
2019-05-30 15:48:31 <mps> for greenbone-security-assistant on armv7 libhiredis is missing. anyone know why libhiredis isn't on armv7
2019-05-30 15:51:51 <_ikke_> good quest, not sure
2019-05-30 15:52:29 <mps> it should be in hiredis pkg, I think
2019-05-30 15:52:47 <_ikke_> yes
2019-05-30 15:53:02 <_ikke_> hiredis is not built for armv7 for some reason
2019-05-30 15:53:08 <_ikke_> the reason eludes me though
2019-05-30 15:53:18 <mps> ok, will look now
2019-05-30 15:53:32 <_ikke_> I'm checking as well
2019-05-30 15:55:00 <_ikke_> 2019-05-28 10:36:09     algitbot        build-edge-armv7: failed to build hiredis: https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/hiredis/hiredis-0.14.0-r1.log
2019-05-30 15:55:03 <mps> it builds cleanly on my lxc
2019-05-30 15:55:12 <_ikke_> The log is gone though
2019-05-30 15:55:46 <mps> someone need to trigger rebuild of hiredis on armv7
2019-05-30 15:56:00 <_ikke_> Would require a pkgrel bump I guess
2019-05-30 16:15:29 <tcely> TBK[m]: your claim to community/exfat-utils needs to be recorded
2019-05-30 16:15:29 <tcely> I had entered a commit for that but it appears it was lost by a force push
2019-05-30 16:17:04 <tcely> pr7675
2019-05-30 16:21:55 <TBK[m]> tcely: I plan to claim it as part of my sdfat pr.
2019-05-30 17:51:15 <mps> what to do with package which requires privileged container for 'make check'? disable check?
2019-05-30 18:06:30 <tcely> Try disabling single tests first?
2019-05-30 18:09:19 <mps> tcely: it has one test, which depends on usb
2019-05-30 18:11:07 <mps> hjaekel: does this patch for libgeotiff looks good http://tpaste.us/ZgDl
2019-05-30 18:11:23 <tcely> Disabling check appears reasonable in this case
2019-05-30 18:12:43 <mps> ok, will wait for author response and then decide what to do
2019-05-30 18:13:50 <mps> btw, it is this new aport https://patchwork.alpinelinux.org/patch/4766/ if you are interested
2019-05-30 18:20:22 <hjaekel> mps, everything is fine if libgeotiff is upgraded from 1.4.2 to 1.5.1 as I did in my pr
2019-05-30 18:22:16 <hjaekel> I am currently creating smaller pr's that are easier to handle
2019-05-30 18:23:22 <hjaekel> there is already a complaint about broken libspatiallite: https://github.com/alpinelinux/aports/pull/7938#issuecomment-497389862
2019-05-30 18:23:44 <mps> please look my clean up and modernization
2019-05-30 18:24:21 <mps> I just preparing libspatiallite trying 5.0.0-beta0
2019-05-30 18:25:49 <hjaekel> I asked you to either take my pr or to wait until I prepare smaller ones
2019-05-30 18:26:31 <hjaekel> why use beta of libspatiallite?
2019-05-30 18:26:39 <mps> don't worry, I do not plan to push my works, just wanted to help you
2019-05-30 18:27:30 <hjaekel> sounds good but I already know how to build libspatiallite with proj 6: https://github.com/alpinelinux/aports/pull/7938/commits/9874f322ff9241add6f788b90eb05ff01b7c23fc
2019-05-30 18:27:37 <mps> current libspatiallite couldn't be built with upgraded proj 6.1
2019-05-30 18:27:43 <hjaekel> yes it can
2019-05-30 18:27:58 <mps> ok, nice
2019-05-30 18:30:08 <mps> could I push just proj commit and rest after that
2019-05-30 18:32:34 <hjaekel> If you want a fast solution, you have to accept the whole pr7938, or you have to wait until I finish smaller pr's (maybe tomorrow)
2019-05-30 18:32:43 <hjaekel> as you sait, it's just testing
2019-05-30 18:33:14 <mps> I downloaded https://github.com/alpinelinux/aports/pull/7938/commits/a8f98306ef8e50633d9e0f2017c7fe61a96c68ef and it looks fine
2019-05-30 18:34:03 <mps> algitbot: you are annoying sometimes ;)
2019-05-30 18:34:35 <hjaekel> yes it looks fine, but it doesn't solve the problem with libgeotiff, libspatiallite pdal mapmik mapserver and postgis
2019-05-30 18:35:27 <hjaekel> you have also to apply the following commits for those packages
2019-05-30 18:35:32 <mps> we can push libgeotiff just after this one
2019-05-30 18:36:13 <mps> all right, however you prefer, I will wait for your decision
2019-05-30 18:36:16 <hjaekel> you can leave out the modernize commits, I just added them because maxice8 asked for it
2019-05-30 18:37:21 <mps> it's good to replaces spaces with tabs and rearange a little APKBUILD to be more 'proper'
2019-05-30 18:38:00 <mps> for example I moved autogen.sh to prepare() in libgeotiff
2019-05-30 18:38:37 <hjaekel> OK, then merge a8f9830, 234fc4c, 9874f32, 1cd1037, 2c5a8fd, 7a9340e  70e4021
2019-05-30 18:39:39 <hjaekel> autogen.sh i fixed in https://github.com/alpinelinux/aports/pull/7938/commits/c79526e4ac1f83491c8f77a1967d51d5d1805267
2019-05-30 18:39:59 <hjaekel> I even added check()
2019-05-30 18:40:39 <mps> very nice
2019-05-30 18:41:00 <hjaekel> It's all there :-)
2019-05-30 18:41:06 <mps> why the github is so slow last few hours, or it is slow just for me
2019-05-30 18:41:32 <hjaekel> hm, it's normal for me
2019-05-30 18:42:42 <mps> hmm, earlier some people have issue with GH and it worked fine for me. looks like now I'm in 'row'
2019-05-30 18:48:03 <hjaekel> So basically I am not happy with my own pr, because it's too big and handles different issues in one pr, but the result is OK I think.
2019-05-30 18:49:04 <mps> could we push it?
2019-05-30 18:49:42 <clandmeter> mps: github doesnt like you, just like you dont love it back ;-)
2019-05-30 18:50:29 <hjaekel> yes we can push it, I see no problems with it exept it is too big
2019-05-30 18:50:38 <mps> yes, our love is mutual :D
2019-05-30 18:51:53 <mps> hjaekel: give me url. I will risk seeing you are work hard to fix things and I think I can rely on you
2019-05-30 18:54:44 <hjaekel> thank you, I hope you are right :-) just one question: did I handle the renaming of the https://github.com/alpinelinux/aports/pull/7938/commits/a8f98306ef8e50633d9e0f2017c7fe61a96c68ef I just added replaces="proj4" in line 48
2019-05-30 18:55:08 <mps> rename sounds better, imo
2019-05-30 18:55:25 <mps> I mean, i commit message
2019-05-30 18:56:20 <hjaekel> hu? I mean in APKBUILD line 48
2019-05-30 18:56:32 <mps> and because everything will be rebuilt maybe replaces are unimportant, but will not hurt I think
2019-05-30 18:57:26 <mps> looks ok, we will see what builder will 'say'
2019-05-30 18:59:02 <hjaekel> OK lets wait for the builder
2019-05-30 18:59:51 <mps> you mean CI?
2019-05-30 19:00:20 <hjaekel> pdal takes very long to build, at least on my computer. but the drone is quite fast
2019-05-30 19:01:03 <tcely> Drone has way more cores than I gave my builder VM ;-)
2019-05-30 19:01:30 <mps> ok, when you think it can be merged give me url from which I can download patch
2019-05-30 19:02:09 <mps> I'm going out a little, I'm sitting too much now ;)
2019-05-30 19:02:27 <tcely> Which PR? You should just append .patch to URL
2019-05-30 19:02:29 <hjaekel> you can download it from pr7938
2019-05-30 19:02:52 <tcely> https://github.com/alpinelinux/aports/pull/7938.patch
2019-05-30 19:02:54 <mps> tcely: I know, I do that usually with wget
2019-05-30 19:03:13 <mps> thinking to add alias or script for this
2019-05-30 19:04:44 <tcely> A function to set PR number for hooks and run git am is a good idea
2019-05-30 19:06:02 <hjaekel> what build enviroment for locally testing patches are you using. Currently I use the docker container andyshinn/alpine-abuild:edge for that
2019-05-30 19:06:48 <clandmeter> tcely: keep in mind our transition to a possible other solution. I dont want to disappoint ppl who spend lots of time on github features.
2019-05-30 19:06:58 <clandmeter> its just a reminder :)
2019-05-30 19:07:26 <tcely> I built my own. docker-abuild is a good one to try.
2019-05-30 19:07:36 <north1> hjaekel: i use dabuild with alpinelinux/docker-abuild on my main notebook and just the system as is on my shitty notebook
2019-05-30 19:07:39 <tcely> clandmeter: sure
2019-05-30 19:08:13 <clandmeter> but its nice to see gitlab features used. like to see the same if we move to another platform.
2019-05-30 19:08:39 <north1> 
ACTION looks at his hellspawn of scripts using GitHub v3 api

2019-05-30 19:08:45 <clandmeter> oh reminds me
2019-05-30 19:08:45 <hjaekel> ok I will look at docker-abuild
2019-05-30 19:08:48 <ollieparanoid[m]> hey folks!
2019-05-30 19:08:56 <mps> I prefer lxc because builders are lxc
2019-05-30 19:08:59 <clandmeter> i need to trigger dabuild builds on drone
2019-05-30 19:09:09 <clandmeter> periodically
2019-05-30 19:09:38 <mps> but, yes, drones looks very nice
2019-05-30 19:09:49 <ollieparanoid[m]> would alpine accept a patch, that makes qt5-qtbase build against opengl es2 for arm arches, instead of desktop opengl?
2019-05-30 19:10:55 <ollieparanoid[m]> this is what we have in postmarketOS, and the reason why we currently forked qt5-qtbase. we switched to alpine's qt5-qtdeclarative package recently, and now our binary repo is broken becaues of that (not alpine's fault, I didn't see this problem ahead of time)
2019-05-30 19:10:56 <ollieparanoid[m]> so I'm wondering if we could simply upstream that patch?
2019-05-30 19:11:02 <ollieparanoid[m]> https://gitlab.com/postmarketOS/pmaports/blob/master/temp/qt5-qtbase/APKBUILD#L67-70 <- basically that
2019-05-30 19:11:35 <ollieparanoid[m]> clandmeter, maybe you are the relevant person to talk to here?^^
2019-05-30 19:12:19 <ollieparanoid[m]> the thing is, if it was possible to do this in alpine, and rather fast, I could prepare a patch and we could get it merged soon, then I could drop the fork we have and unbreak our repository nicely
2019-05-30 19:12:57 <clandmeter> ollieparanoid[m]: hi
2019-05-30 19:13:06 <ollieparanoid[m]> (note that qt5-qtbase can't be built against both desktop opengl and opengl es2, hence the suggestion to use the latter exclusively on arm)
2019-05-30 19:13:10 <clandmeter> what are the consequences?
2019-05-30 19:13:13 <danieli> well, first of all, will it break anything else on arm?
2019-05-30 19:14:52 <ollieparanoid[m]> danieli: good question. I don't think that there is a qt program in alpine, that relies on qt being compiled against the desktop version of opengl
2019-05-30 19:15:31 <ollieparanoid[m]> but that is vague of course, I'm wondering if there would be a good way to check that
2019-05-30 19:15:38 <danieli> there are 130 packages requiring qt5-qtbase but i'm not sure whether any of them will break when compiled against es2
2019-05-30 19:16:08 <ollieparanoid[m]> clandmeter: the consequences are, that all qt programs on arm on alpine would use opengl es2 from there on
2019-05-30 19:16:17 <danieli> if you could prep a patch i can build it, and test-compile a few of the more important/popular packages against it
2019-05-30 19:16:46 <clandmeter> ollieparanoid[m]: i dont have much experience with opengl whatsoever
2019-05-30 19:16:57 <danieli> it will be fairly time-consuming to do a comprehensive benchmark to see if it would be detrimental to performance, but i don't think that should be necessary
2019-05-30 19:17:01 <clandmeter> does es2 have limitations?
2019-05-30 19:17:05 <clandmeter> compared to its brother
2019-05-30 19:17:58 <ollieparanoid[m]> danieli: thanks! I'll do that
2019-05-30 19:18:36 <danieli> it lacks fixed-function functions and there are some datatype changes to make it fit better on embedded devices
2019-05-30 19:19:06 <danieli> the fixed-function funs were removed from desktop opengl later on too, iirc 3.0 to 3.1?
2019-05-30 19:19:48 <clandmeter> so this is mostly targetted for mobile usage?
2019-05-30 19:20:12 <danieli> embedded devices, not solely mobile
2019-05-30 19:20:14 <clandmeter> what if we have more desktop products next year?
2019-05-30 19:20:40 <clandmeter> right but pmos is targgeting mobile afaik.
2019-05-30 19:21:05 <Cogitri> FWIW, all of Wayland uses GLES too to not pull in X via GLX
2019-05-30 19:21:45 <ollieparanoid[m]> yes, we are
2019-05-30 19:21:48 <ollieparanoid[m]> well, this is the solution I came up with currently. if this isn't the right thing for alpine, that is also fine
2019-05-30 19:22:13 <danieli> i'm not sure whether it will be detrimental to other platforms or packages built against regular opengl
2019-05-30 19:22:36 <clandmeter> ollieparanoid[m]: i think its better to add an issue or send mail to ml.
2019-05-30 19:22:46 <clandmeter> maybe ml is even better
2019-05-30 19:22:57 <danieli> yeah, i'd pass a mail to ml and get some input from people who don't actively watch irc
2019-05-30 19:23:25 <clandmeter> i remember some ppl reacted when we said we wanted to drop armhf
2019-05-30 19:23:33 <clandmeter> ppl i never seen before
2019-05-30 19:23:40 <clandmeter> so they are out there
2019-05-30 19:23:44 <clandmeter> in the wild
2019-05-30 19:23:45 <clandmeter> hiding
2019-05-30 19:24:03 <danieli> i wouldn't say that's unexpected, not all users are vocal
2019-05-30 19:24:22 <ollieparanoid[m]> clandmeter: okay, makes sense. I see now that this is worth discussing more before just switching over
2019-05-30 19:24:43 <ollieparanoid[m]> I'll go with a workaround on our end then, and follow up with a mail on this topic some time soon :)
2019-05-30 19:25:19 <clandmeter> ollieparanoid[m]: ok, sorry but i just dont have enough knowledge about this to make a proper decission.
2019-05-30 19:25:30 <ollieparanoid[m]> yeah, not everybody has time to read IRC all the time ;)
2019-05-30 19:26:59 <ollieparanoid[m]> clandmeter: that is fine, you're doing the right thing then. thanks!
2019-05-30 20:53:16 <ollieparanoid[m]> after more research, and reading a related debian ML thread, I came to the conclusion that using GLES for arm in qt5-qtbase does probably not make sense for alpine. so I'm not going to make a ML post about this, unless I find new reasoning that changes my picture.
2019-05-30 20:53:17 <ollieparanoid[m]> details: https://gitlab.com/postmarketOS/pmaports/issues/232#note_176406830
2019-05-31 00:02:55 <ollieparanoid[m]> multipath-tools needs a rebuild, due to missing missing liburcu.so.6 dependency. Simple pkgrel bump PR: https://github.com/alpinelinux/aports/pull/8319
2019-05-31 00:04:51 <ollieparanoid[m]> (one day I'll build some sort of CI script to throw errors about these kinds of breakages automatically)
2019-05-31 02:03:18 <north1> So alpine dB sends an email on packages flagged out of date?
2019-05-31 04:32:05 <_ikke_> north1: yes
2019-05-31 04:32:22 <north1> Nice
2019-05-31 04:32:28 <north1> Got one for libdwarf
2019-05-31 04:36:44 <_ikke_> north1: atools 15.1 fails to build
2019-05-31 04:36:55 <_ikke_> Error at 284:0: Expected _ before starting new paragraph (began with _ at 281:2)
2019-05-31 04:37:03 <_ikke_> for alint.5
2019-05-31 04:37:12 <north1> Hmm
2019-05-31 04:37:36 <north1> It is 1:38 Am where I am
2019-05-31 04:37:42 <_ikke_> k
2019-05-31 04:37:44 <north1> I'll see it in 4 to 5 hours
2019-05-31 04:39:23 <_ikke_> Just escaping it is enough
2019-05-31 04:40:14 <_ikke_> the '_'
2019-05-31 04:50:50 <_ikke_> submitted PR
2019-05-31 04:51:50 <north1> I saw
2019-05-31 05:20:50 <ncopa> morning
2019-05-31 05:21:09 <ncopa> \o/ all builders are idle
2019-05-31 05:21:25 <Danct12__> \o/
2019-05-31 05:21:39 <Danct12__> Actually it's noon for me here
2019-05-31 05:24:19 <ncopa> some builders seems to be broken though
2019-05-31 05:24:37 <ncopa> build-3-10-aarch64 has lost /usr/sbin/sshd for some reason
2019-05-31 05:25:03 <Danct12__> Something deleted it?
2019-05-31 05:25:12 <ncopa> probably yes
2019-05-31 05:25:12 <Danct12__> That shouldn't happen anyway
2019-05-31 05:26:03 <ncopa> its unexpected yes
2019-05-31 05:29:16 <ncopa> i think it can happen with replaces="openssh-server"
2019-05-31 05:30:58 <Danct12__> Hope that is fixed soon. :P
2019-05-31 05:31:19 <Danct12__> Just curious asking, why armel is unsupported on Alpine?
2019-05-31 05:55:08 <clandmeter> Danct12__: there is not much hardware for armel.
2019-05-31 06:16:27 <ncopa> we dont have resources for all arm variants
2019-05-31 06:33:32 <north1> Lots of PRs being merged, nice
2019-05-31 08:18:35 <ncopa> north1: im specifically merging your PRs
2019-05-31 08:18:46 <ncopa> because they are low hanging fruit :)
2019-05-31 08:19:04 <north1> As long as they are merged I don't mind
2019-05-31 08:55:57 <_ikke_> gtksourceview is failing to build
2019-05-31 08:57:54 <Cogitri> Does someone happen to know mkinitfs a bit? I need it to ask for my ZFS password on boot, so I either need to call `zfs load-key -a` or `zfs import -l` during sysinit, but I'm not really sure how to do that
2019-05-31 09:08:11 <tcely> ncopa: does pushing an upgrade and rebuilds all at once work?
2019-05-31 09:08:36 <_ikke_> tcely: it should, yes
2019-05-31 09:08:46 <tcely> why?
2019-05-31 09:09:24 <_ikke_> It builds things in dependency order
2019-05-31 09:09:26 <jwh> ohhh, a use case for the stuff I'm working on in mkinitfs
2019-05-31 09:09:48 <jwh> other than my use case, that is
2019-05-31 09:09:53 <Cogitri> Oh? :o
2019-05-31 09:10:08 <tcely> jwh: was that the ssh for FDE input?
2019-05-31 09:10:34 <jwh> well eventually yes, but I've implemented the hook framework
2019-05-31 09:11:04 <tcely> _ikke_: that won't work when the rebuilds happen in another repository unless I've missed something
2019-05-31 09:11:10 <jwh> idea is to be able to do whatever you want, so it's generic
2019-05-31 09:11:22 <Cogitri> Cool!
2019-05-31 09:11:54 <jwh> https://i.imgur.com/fvYfKhu.png
2019-05-31 09:11:59 <jwh> right side window
2019-05-31 09:12:17 <Cogitri> How could I work around it for now? Can I unlock the pool, mount my root to /syroot and then go on with the boot after that?
2019-05-31 09:12:32 <jwh> you should be able to do that if it drops to an emergency shell yeah
2019-05-31 09:13:26 <Cogitri> Hm, but if I do `exit` in the emergency shell won't it just do a kernel panic?
2019-05-31 09:13:31 <tcely> jwh: is that a serial console you're using?
2019-05-31 09:13:58 <jwh> tcely: yeah, its running in vmware workstation atm because it's just easier than dealing with libvirt
2019-05-31 09:14:21 <_ikke_> tcely: on the builders, both main and community of the just built packages are in /etc/apk/repositories, so that should not be an issue
2019-05-31 09:14:59 <Cogitri> Oh no, it works! :)
2019-05-31 09:15:08 <_ikke_> tcely: this is mostly an issue on CI, where only remote repositories are used and abuild itself selects the local repositories
2019-05-31 09:15:36 <tcely> _ikke_: interesting. Why do builders and CI work differently?
2019-05-31 09:16:13 <_ikke_> tcely: clandmeter could probably explain that
2019-05-31 09:23:54 <clandmeter> CI does not have local packages
2019-05-31 09:24:25 <_ikke_> Not even during the abuild run?
2019-05-31 09:24:44 <_ikke_> well, between I mean
2019-05-31 09:25:01 <clandmeter> yes it will keep packages for that job
2019-05-31 09:26:07 <clandmeter> but builders dont use external repos, thats one of the differences.
2019-05-31 09:26:27 <_ikke_> What is currently preventing a package from community depending on a package in master on the builders?
2019-05-31 09:26:39 <_ikke_> I mean the other way around
2019-05-31 09:26:47 <clandmeter> in main you mean?
2019-05-31 09:26:56 <_ikke_> packages in main depending on community
2019-05-31 09:27:28 <clandmeter> there is a PR about that
2019-05-31 09:27:33 <_ikke_> I know
2019-05-31 09:27:48 <clandmeter> i need to dig into it again, havent looked at it recently
2019-05-31 09:28:00 <_ikke_> Should /home/buildozer/packages/community be present in /etc/apk/repositories on the builders?
2019-05-31 09:28:18 <tcely> clandmeter: do builders have all local repositories enabled all the time?
2019-05-31 09:28:26 <clandmeter> abuild will do that automatically afaik
2019-05-31 09:28:48 <_ikke_> Right now, it *is* present
2019-05-31 09:29:06 <_ikke_> so if a package in main would depend on a package in community, afaik it will just work
2019-05-31 09:29:33 <clandmeter> i think it will not work?
2019-05-31 09:29:40 <_ikke_> what would prevent that?
2019-05-31 09:30:02 <clandmeter> you should ask our aports master
2019-05-31 09:30:22 <ncopa> Cogitri: i know mkinitfs a bit
2019-05-31 09:30:27 <clandmeter> there he is
2019-05-31 09:31:17 <ncopa> Cogitri: we have similar situation with cryptsetup, which may require user input and thus need to load keybard drivers
2019-05-31 09:31:46 <ncopa> iirc, the way we solved it was to run the kernel module loading in parallel
2019-05-31 09:32:04 <ncopa> so zfs password input should work after a few seconds
2019-05-31 09:32:10 <ncopa> but i need to check that
2019-05-31 09:32:10 <Cogitri> Ah, that works just fine for me
2019-05-31 09:32:17 <Cogitri> I just need to call a custom command instead of `zfs import` I guess
2019-05-31 09:32:33 <Cogitri> <ncopa "so zfs password input should wor"> It works just fine in the emergency shell :)
2019-05-31 09:32:49 <ncopa> oh
2019-05-31 09:33:27 <Cogitri> `zfs import -l` instead of `zfs import` would fix it already :)
2019-05-31 09:33:58 <ncopa> what does `zfs import -l` do? is that something we can run for everyone, by default?
2019-05-31 09:34:03 <ncopa> every zfs user that is
2019-05-31 09:34:22 <tcely> pr8323 should help with the sslh build failure
2019-05-31 09:35:26 <Cogitri> ncopa: Yup. It's in since ZFS 0.8 and means `load the ZFS pool AND asks for encryption keys, if there are any`
2019-05-31 09:37:55 <ncopa> but it will not work with zfs older than 0.8?
2019-05-31 09:38:23 <Cogitri> Dunno to be honest, I can test that once I have a working GNOME again
2019-05-31 09:41:43 <ncopa> i dont think it will solve the problem
2019-05-31 09:42:11 <Cogitri> Ah?
2019-05-31 09:42:56 <ncopa> what happens if you dont use the -l?
2019-05-31 09:43:07 <ncopa> will it prompt for password at all?
2019-05-31 09:44:13 <Cogitri> No
2019-05-31 09:44:18 <north1> big question
2019-05-31 09:44:40 <north1> how did the multipath-tools revbump worked if the builddir is not correct (apparently)
2019-05-31 09:44:41 <Cogitri> Without the `-l` you have to run `zfs load-keys -a` after `zfs import`
2019-05-31 09:44:42 <ncopa> and it will fail to init zfs pool i guess
2019-05-31 09:44:59 <eu> zfs <8 does not have the -l switch
2019-05-31 09:45:33 <Cogitri> ncopa: No, it imports it just fine, but mounting anything in it will fail
2019-05-31 09:46:54 <ncopa> ok...
2019-05-31 09:46:57 <Cogitri> <eu "zfs <8 does not have the -l swit"> Ah :/
2019-05-31 09:47:23 <ncopa> ok you are right, i think `zpool import -l` will fix it
2019-05-31 09:47:32 <ncopa> cryptsetup is different
2019-05-31 09:47:45 <ncopa> because we dont spawn any external program for it
2019-05-31 09:47:47 <eu> at least according to zpool(8)
2019-05-31 09:47:55 <ncopa> we use libcryptsetup directly
2019-05-31 09:48:18 <ncopa> so we run the cryptsetup stuff in a separate thread
2019-05-31 09:48:29 <Cogitri> BTW, can I get `adduser` to not add the `Linux User` comment to new users?
2019-05-31 09:48:42 <ncopa> dunno
2019-05-31 09:48:49 <Cogitri> It's a bit confusing when I have 5 `Linux User`s in my GDM :P
2019-05-31 09:49:05 <ncopa> -g GECOS	GECOS field
2019-05-31 09:49:40 <ncopa> adduser -g "" ....
2019-05-31 09:49:58 <ncopa> is it real users or system users
2019-05-31 09:50:13 <ncopa> for system accounts we should use adduser -S
2019-05-31 09:51:19 <Cogitri> It's real users, GDM doesn't show system users
2019-05-31 09:51:22 <Cogitri> Thank you
2019-05-31 09:51:25 <clandmeter> it would be nice to have some defaults into abuild for user creation.
2019-05-31 09:51:28 <clandmeter> for system users
2019-05-31 09:51:40 <north1> can someone look at why gtksourceview is failing on the builders ?
2019-05-31 09:51:45 <north1> it passed CI and it passed local
2019-05-31 09:54:33 <jwh> clandmeter: I was gonna have a look at that coz it's really messy doing adduser
2019-05-31 10:01:31 <ncopa> north1: I'll have a look at it in a sec
2019-05-31 10:02:58 <north1> thank you
2019-05-31 10:05:19 <ncopa> https://tpaste.us/lZN6
2019-05-31 10:08:36 <north1> ok, the ibus dependency is missing in checkdepends
2019-05-31 10:08:41 <north1> well that is what i can deduce from the logs, can't test since it works on CI and locally
2019-05-31 10:09:27 <north1> ok made a pr
2019-05-31 10:09:35 <north1> pr8325 i'm going out to catch a bus
2019-05-31 10:16:12 <ncopa> ddevault: you are maintainer for ibus. i think we can replace the post-install script with a trigger
2019-05-31 10:16:26 <ncopa> and i think its a trigger that should be run from gtk package
2019-05-31 10:18:49 <ncopa> we should probably also completely disable the gtk2 support for it
2019-05-31 10:39:20 <mps> ncopa: you pushed those lttng-tools and lttng-ust to aports. could they be marked as accepted on pw.a.o
2019-05-31 10:39:44 <_ikke_> were the tests fixed for those?
2019-05-31 10:40:25 <mps> don't know, just have seen they are pushed.
2019-05-31 11:00:55 <mps> are some builders stuck?
2019-05-31 11:01:39 <_ikke_> Which ones do you think are stuck?
2019-05-31 11:02:11 <mps> aarch64 and x86_64
2019-05-31 11:03:45 <mps> ah, they are in 'failed' because of  gtksourceview
2019-05-31 11:04:53 <mps> is it ok to trigger them to retry
2019-05-31 11:08:13 <_ikke_> Not sure if that's going to fix it, they have been built over and over again
2019-05-31 11:09:23 <mps> but will be other pkg's in queue will be built
2019-05-31 11:09:49 <mps> at least, tried
2019-05-31 11:10:15 <_ikke_> No, I don't think the order will change
2019-05-31 11:10:40 <mps> uhm, not good
2019-05-31 11:12:40 <ncopa> mps: yes i think so
2019-05-31 11:13:43 <ncopa> ok, i have finally figured out why wireguard-vanilla is rebuilt every git push
2019-05-31 11:13:51 <ncopa> clandmeter: it turns out that you did break it
2019-05-31 11:16:15 <Cogitri> ncopa: mind taking a look at pr7481? Nautilus is broken until it's merged :/
2019-05-31 11:16:32 <Cogitri> And CI doesn't work because it can't pull in the vte change from main
2019-05-31 11:17:10 <mps> Cogitri: we have unmaintained/gnome-terminal/
2019-05-31 11:17:47 <Cogitri> Yup, the PR title isn't correct, but the commit is fixed
2019-05-31 11:20:20 <mps> ah, ok, just noted you to not have two in aports
2019-05-31 11:21:00 <Cogitri> Yup, thank you :)
2019-05-31 11:21:33 <mps> Cogitri: np, :)
2019-05-31 11:21:36 <_ikke_> ncopa: what is causing it?
2019-05-31 11:22:40 <ncopa> _extra_flavors
2019-05-31 11:22:49 <ncopa> from wirequard-rpi
2019-05-31 11:23:22 <ncopa> lua-aports will source all APKBUILDs, which means that variables set in one APKBUILD will leak over when parsing the next APKBUILD
2019-05-31 11:23:41 <ncopa> lua-aports will reset the known variables, like pkgname, pkgver, subpackages etc
2019-05-31 11:24:03 <ncopa> but it will not touch unknown vars like _extra_flavors
2019-05-31 11:24:49 <_ikke_> aha ok, not something you can easily forsee
2019-05-31 11:24:51 <ncopa> wireguard-rpi will conditionally set _extra_flavors=rpi
2019-05-31 11:25:17 <ncopa> wil only set that if arch is armhf|armv7
2019-05-31 11:25:58 <ncopa> wireguard-vanilla has a similar conditional, for _extra_flavor=virt
2019-05-31 11:26:05 <ncopa> which is only set on x86*
2019-05-31 11:26:39 <ncopa> so lua-aports will first parse wireguard-rpi, and set _extra_flavors=rpi
2019-05-31 11:27:04 <ncopa> then it will parse wireguard-vanilla (with _extra_flavors already set to rpi2)
2019-05-31 11:27:24 <ncopa> since its arm and not x86_64 it will leave _extraflavors untouched
2019-05-31 11:27:58 <ncopa> so later, when the subpackages="$subpackages $pkgname-$_extra_flavors"
2019-05-31 11:28:17 <ncopa> it will basically add wireguard-rpi2 as a subpackage for wireguard-vanilla
2019-05-31 11:28:38 <ncopa> lua-aports will check if it needs to do a build, by check if all subpackages exists
2019-05-31 11:29:17 <ncopa> and will not find any wireguard-rpi2 package
2019-05-31 11:29:23 <ncopa> and thus trigger a rebuild
2019-05-31 11:30:02 <ncopa> fix is to explicitly initialize _extra_flavors in APKBUILD
2019-05-31 11:30:09 <ncopa> regardless of the arch
2019-05-31 11:31:02 <ncopa> 48561ded9e4488766885139258a98f32831f7310
2019-05-31 11:40:24 <_ikke_> And we can't somehow isolate APKBUILDs from eachother in aports-lua?
2019-05-31 11:45:50 <ncopa> we can
2019-05-31 11:46:05 <ncopa> by running each APKBUILD in its own subshell
2019-05-31 11:46:39 <ncopa> but that means we will call fork N times, where N is number of APKBUILDs
2019-05-31 11:46:41 <ncopa> and is slow
2019-05-31 11:49:55 <ncopa> would not been a problem if we only had 10 APKBUILDs
2019-05-31 11:50:03 <ncopa> but is a problem when we have 1000+
2019-05-31 12:01:55 <tcely> ncopa: I wonder if it wouldn't be better to compute that output in parallel using make or something
2019-05-31 12:02:44 <_ikke_> Why use make to parrelalize it?
2019-05-31 12:03:53 <tcely> _ikke_: make is good at tracking sources and outputs and when to rebuild them and has convenient -j flag
2019-05-31 12:27:55 <ncopa> tcely: i have been thinking of something similar, but not using make
2019-05-31 12:28:04 <ncopa> make is dog slow for thins kind of things
2019-05-31 12:29:56 <clandmeter> ncopa: i thought so :)
2019-05-31 12:30:35 <_ikke_> maybe just `parallel`
2019-05-31 12:31:05 <ncopa> tcely: i think also gentoo has similar policy, to avoid forks in global scope
2019-05-31 12:31:16 <ncopa> at least they had it 10 years ago
2019-05-31 12:31:54 <ncopa> parsing them all in a single shell is the simple and stupid thing to do for performance
2019-05-31 12:32:19 <_ikke_> with the chance of cross-contamination
2019-05-31 12:32:28 <ncopa> yup
2019-05-31 12:32:37 <ncopa> (hence "stupid")
2019-05-31 12:33:36 <ncopa> another questionable thing is that some APKBUILDs expect that they are run in current dir
2019-05-31 12:33:58 <ncopa> that cwd is the dir where the APKBUILD is found
2019-05-31 12:35:45 <ncopa> for maximum parsing perfomance we should parse them in N shells, where N is number of cores
2019-05-31 12:38:30 <clandmeter> ncopa: like with xargs -P $(nproc) ?
2019-05-31 13:01:59 <PureTryOut[m]> fcolista: any reason you didn't upgrade qt5-qtwebengine to 5.12.3 when updating qt5?
2019-05-31 13:03:23 <fcolista> PureTryOut[m], yes.
2019-05-31 13:03:24 <fcolista> https://github.com/alpinelinux/aports/pull/7767
2019-05-31 13:05:08 <PureTryOut[m]> Damn...
2019-05-31 13:05:09 <PureTryOut[m]> I currently can't launch plasma-mobile because of it on postmarketOS...
2019-05-31 13:07:35 <PureTryOut[m]> Tbh partially upgrading Qt is a thing that shouldn't really happen
2019-05-31 13:12:09 <fcolista> PureTryOut[m], it wasn't working even before, but I can go ahead  and push the upgrad to 5.12.3. Cogitri told that were goign to test it
2019-05-31 13:12:53 <PureTryOut[m]> I know it didn't work before, but at least applications depending on it launched lol
2019-05-31 13:12:57 <PureTryOut[m]> I'd like it pushed yes thanks
2019-05-31 13:20:48 <tcely> ncopa: It's not terrible performance even from the clean state.
2019-05-31 13:20:48 <tcely> /aports/testing $ time -p make -j 4 -f ../Makefile.makedepends
2019-05-31 13:20:48 <tcely> real 12.44
2019-05-31 13:21:06 <ncopa> 12 seconds?
2019-05-31 13:21:09 <tcely> yep
2019-05-31 13:21:56 <ncopa> how many aports? all testing packages only?
2019-05-31 13:22:35 <tcely> yes, everything in testing was done in that run with no existing files
2019-05-31 13:23:32 <tcely> main is actually bigger but was done in <15 seconds
2019-05-31 13:23:54 <tcely> the benefit of course is the next run doesn't need to recompute everything
2019-05-31 13:24:23 <ncopa> i guess we have different opinion on what "terrible performance" is
2019-05-31 13:24:34 <ncopa> everything more than 1 sec is terrible imho :)
2019-05-31 13:24:49 <ncopa> $ time ap list > /dev/null
2019-05-31 13:24:49 <ncopa> real	0m 0.25s
2019-05-31 13:24:49 <ncopa> user	0m 0.26s
2019-05-31 13:24:49 <ncopa> sys	0m 0.05s
2019-05-31 13:25:16 <ncopa> takes 0.25 sec here to parse all packages in testing
2019-05-31 13:25:35 <_ikke_> and community?
2019-05-31 13:26:03 <ncopa> 0.48s with cold disk cache
2019-05-31 13:26:09 <ncopa> 0.24s with warm cache
2019-05-31 13:26:09 <_ikke_> not bad
2019-05-31 13:27:28 <_ikke_> Many people get used to their tooling being slow
2019-05-31 13:28:14 <_ikke_> Some ruby tools I use take >1s to just show -h
2019-05-31 13:28:28 <tcely> ncopa: if you're looking for <1sec then yes, this solution sucks. The real test though is how long does the abuild call to parse_aports_makedepends take?
2019-05-31 13:29:07 <ncopa> no
2019-05-31 13:29:22 <ncopa> the real test is how long time it takes to calculate the build order
2019-05-31 13:29:38 <ncopa> or to calculate which .apk files it can delete
2019-05-31 13:30:37 <ncopa> FYI
2019-05-31 13:30:49 <ncopa> $ for i in */APKBUILD; do echo 'foo=$(true)' >> $i; done && time ap list >/dev/null
2019-05-31 13:30:56 <ncopa> real	0m 0.68s
2019-05-31 13:30:56 <ncopa> sys	0m 0.16s
2019-05-31 13:30:56 <ncopa> user	0m 0.64s
2019-05-31 13:32:58 <tcely> why is ap list a good comparison? Does ap list source every APKBUILD?
2019-05-31 13:33:26 <ncopa> so simply add a fork in every APKBUILD makes it 283% slower
2019-05-31 13:33:31 <ncopa> yes
2019-05-31 13:34:29 <ncopa> adding 2 forks in every APKBUILD:
2019-05-31 13:34:36 <ncopa> real	0m 1.26s
2019-05-31 13:34:36 <ncopa> sys	0m 0.41s
2019-05-31 13:34:36 <ncopa> user	0m 1.01s
2019-05-31 13:35:17 <ncopa> 5 times slower
2019-05-31 13:35:51 <ncopa> and this is on an i7 with nvme
2019-05-31 13:36:03 <ncopa> i bet it does not goes any faster on an rpi
2019-05-31 13:36:11 <tcely> good bet
2019-05-31 13:36:15 <ncopa> :)
2019-05-31 13:37:22 <danieli> something bad in nginx is coming up soon, RCE in the more recent versions
2019-05-31 13:37:40 <_ikke_> danieli: ..
2019-05-31 13:37:44 <jwh> cve?
2019-05-31 13:37:52 <danieli> pending disclosure
2019-05-31 13:37:54 <ncopa> carefully planned to publish it on a friday afternoon
2019-05-31 13:38:04 <jwh> how considerat
2019-05-31 13:38:05 <jwh> e
2019-05-31 13:38:06 <danieli> it's still pending, i'm just saying it here as a heads up
2019-05-31 13:38:22 <ncopa> so hackers have the weekend and monday to explioit it
2019-05-31 13:38:48 <danieli> https://twitter.com/alisaesage/status/1134400428899127296
2019-05-31 13:58:45 <_ikke_> ncopa: anything that needs to be done for 3.10 rc1?
2019-05-31 14:00:28 <mps> anyone can tell what to do for new aport which doesn't build on our infra but uses upstream prebuilt binaries? https://patchwork.alpinelinux.org/patch/4767/
2019-05-31 14:02:53 <mps> I think we should not allow that, but want to hear from core devs their opinion
2019-05-31 14:07:19 <danieli> why is it using prebuilt binaries / why doesn't it build on the alpine builders?
2019-05-31 14:07:44 <_ikke_> "toolchain is not available"
2019-05-31 14:08:00 <jwh> +# Using prebuild firmware, as required toolchain is not (yet) available on
2019-05-31 14:08:03 <jwh> ah
2019-05-31 14:08:03 <jwh> beat me to it
2019-05-31 14:09:35 <mps> to repeat, I think it should be 'Rejected' with comment
2019-05-31 14:09:50 <jwh> why isn't it in linux-firmware?
2019-05-31 14:11:22 <mps> jwh: I think it is not related to linux kernel
2019-05-31 14:11:39 <jwh> oh is it not driver firmware?
2019-05-31 14:11:54 <jwh> or operational firmware, rather
2019-05-31 14:13:19 <mps> yes, for some external devices
2019-05-31 14:14:51 <p4Wv1qn095FW> ah. i have sigrok stuff in my ugly-aports, but not this firmware
2019-05-31 14:15:52 <mps> p4Wv1qn095FW: your explanation will be welcome :)
2019-05-31 14:19:09 <p4Wv1qn095FW> well, sigrok is for oscilloscopes/multimeters/etc. and some of those have fpgas, and can be programmed on on the fly. this is such a firmware for a nice programmable scope/signanalyzer. i can totally imagine the toolchain for this not be available
2019-05-31 14:19:38 <p4Wv1qn095FW> i have no such device myself, so i never cared for packaging it.
2019-05-31 14:20:23 <ncopa> _ikke_: solve some dependency errors
2019-05-31 14:20:41 <ncopa> apk dot --errors will show that there are some packages that needs to be rebuilt
2019-05-31 14:20:42 <p4Wv1qn095FW> and i also welcome some of my user packages to be included in upstream alpine, i can dump those from my repo then. \o/
2019-05-31 14:21:07 <_ikke_> ncopa: ok, I will look at that soon
2019-05-31 14:21:09 <mps> p4Wv1qn095FW: then it could go to non-free, something like b43-firmware
2019-05-31 14:21:28 <ncopa> _ikke_: im working on cdw rebuild against libcdio
2019-05-31 14:22:03 <mps> p4Wv1qn095FW: post them to pw.a.o or as github PR's
2019-05-31 14:22:16 <p4Wv1qn095FW> fx2lafw is an open-source firmware for Cypress FX2 chips which makes them usable as simple logic analyzer and/or oscilloscope hardware.
2019-05-31 14:22:18 <p4Wv1qn095FW> It is licensed under the terms of the GNU GPL (version 2, or later) and written in C, using sdcc as compiler, and fx2lib as helper library.
2019-05-31 14:22:31 <mps> I'm looking on some of them
2019-05-31 14:23:09 <mps> for example, I'm interested in kicad
2019-05-31 14:24:18 <p4Wv1qn095FW> great, happy to help out if you need anything
2019-05-31 14:24:21 <ncopa> i think we also need to update qt5-qtwebengine
2019-05-31 14:24:51 <p4Wv1qn095FW> oh, sdcc is huh, is interesting: http://sdcc.sourceforge.net/
2019-05-31 14:25:56 <_ikke_> ncopa: I PureTryOut[m] and fcolista talked about that
2019-05-31 14:26:00 <_ikke_> -I
2019-05-31 14:27:43 <PureTryOut[m]> We do need to update it yes. Although it's functionality may be broken (which was already the case in 5.12.1), at least applications using it launched. Now they don't anymore due to qt5-qtwebengine being left behind in the qt5 upgrade
2019-05-31 14:29:09 <detha> sigrok sounds interesting. the HCL has something similar to my little oscilloscope on it
2019-05-31 14:31:31 <mps> ncopa: sorry, I know you are busy, but want to hear your opinion about binary only pkg, before rejecting it or proposing to put it in non-free
2019-05-31 14:32:05 <ncopa> mps: what package is it?
2019-05-31 14:32:23 <mps> anyone can tell what to do for new aport which doesn't build on our infra but uses upstream prebuilt binaries? https://patchwork.alpinelinux.org/patch/4767/
2019-05-31 14:32:26 <ncopa> and what license it is
2019-05-31 14:32:44 <mps> author says it is gpl
2019-05-31 14:33:22 <mps> and here is upstream link https://sigrok.org/wiki/Firmware about it
2019-05-31 14:36:11 <p4Wv1qn095FW> fx2lafw is an open-source firmware for Cypress FX2 chips which makes them usable as simple logic analyzer and/or oscilloscope hardware.
2019-05-31 14:36:13 <p4Wv1qn095FW> It is licensed under the terms of the GNU GPL (version 2, or later) and written in C, using sdcc as compiler, and fx2lib as helper library.
2019-05-31 14:36:28 <p4Wv1qn095FW> is the patch: https://patchwork.alpinelinux.org/patch/4767/
2019-05-31 14:36:46 <p4Wv1qn095FW> it needs sdcc to build the binary, which is also gplv2, but apparently not packaged.
2019-05-31 14:37:11 <p4Wv1qn095FW> maybe it makes sense to ask the submitter to package also sdcc for building it in alpine directly instead of binary only?
2019-05-31 14:37:39 <mps> p4Wv1qn095FW: that sounds as good proposal
2019-05-31 14:41:16 <mps> p4Wv1qn095FW: do you have sdcc in your ugly-aports
2019-05-31 14:41:19 <p4Wv1qn095FW> nope
2019-05-31 14:41:42 <p4Wv1qn095FW> i have no such device needing this firmware, so i never packaged it
2019-05-31 14:41:49 <mps> aha, ok.
2019-05-31 14:55:34 <ncopa> so, we do have linux-firmware
2019-05-31 14:55:38 <ncopa> with the same problem
2019-05-31 14:56:54 <mps> well, other distro do the same with linux firmware, afaik
2019-05-31 14:57:29 <ncopa> so i think we can do the same here
2019-05-31 14:57:51 <ncopa> but the wiki page also says that most firmware is non-redistrib
2019-05-31 14:58:11 <mps> yes, that is what bothers me
2019-05-31 14:58:52 <ncopa> those we cannot redistrib
2019-05-31 14:59:12 <ncopa> we can provide apkbuild in non-free though
2019-05-31 14:59:27 <mps> maybe propose author to package each of firmware as separate package
2019-05-31 14:59:55 <ncopa> isnt that what he is already doing?
2019-05-31 14:59:57 <ncopa> i mean
2019-05-31 15:00:07 <ncopa> he is not allowed to redist the non-free stuff
2019-05-31 15:00:15 <ncopa> so he doesnt do that
2019-05-31 15:00:37 <ncopa> he only redist the fw that vendor given permission to do so
2019-05-31 15:00:54 <ncopa> I assume you need to go to vendor to get the non-free fw
2019-05-31 15:00:54 <mps> yes, but how we can be sure if something wouldn't slip
2019-05-31 15:01:33 <ncopa> we trust sigrok.org to not do that?
2019-05-31 15:01:37 <ncopa> i dont know
2019-05-31 15:02:02 <ncopa> he does not redist the nonfree stuff
2019-05-31 15:02:03 <mps> author clearly stated that it 'package' only those with gpl licence
2019-05-31 15:02:35 <ncopa> he only redist scripts for the non-free stuff
2019-05-31 15:02:43 <ncopa> so i dont tihnk there are any problem
2019-05-31 15:03:06 <mps> but, obviosly some can be built from source, if we have needed progams, i.e. sdcc
2019-05-31 15:04:40 <mps> if the binary allowed to be freely redistributable also I don't see a problem
2019-05-31 15:06:23 <mps> I just don't want to be this one who make such decision. I'm not expert in these fields and know little about different laws about licenses
2019-05-31 15:08:50 <ncopa> tcely: your dhcp "improvements" has circular depends according apk dot
2019-05-31 15:09:12 <tcely> what's the circle?
2019-05-31 15:10:59 <ncopa> $ sudo apk --repositories-file /dev/null --repository http://dl-cdn.alpinelinux.org/alpine/edge/main dot --errors | grep dhcp | tpaste
2019-05-31 15:10:59 <ncopa> http://tpaste.us/NKom
2019-05-31 15:11:38 <ncopa> dhcp-server-vanilla -> dhcp -> dhcp-server -> dhcp-server-vanilla
2019-05-31 15:11:43 <ncopa> and
2019-05-31 15:11:52 <mps> hiredis needs trigger to be built on armv7 to solve greenbone-security-assistant build
2019-05-31 15:11:59 <ncopa> dhcp-server-ldap -> dhcp -> dhcp-server-ldap
2019-05-31 15:13:23 <ncopa> mps?
2019-05-31 15:13:53 <mps> greenbone-security-assistant missing libhiredis to build on armv7
2019-05-31 15:14:14 <mps> I tried build hiredis and it works
2019-05-31 15:14:36 <mps> somehow it is not built on builder, I think
2019-05-31 15:14:41 <ncopa> ok
2019-05-31 15:14:59 <ncopa> so hiredis is missing on armv7?
2019-05-31 15:15:26 <mps> last night that was the state when I tried to fix this
2019-05-31 15:15:42 <ncopa> all builders seems to be done
2019-05-31 15:15:43 <ncopa> and idle
2019-05-31 15:15:49 <mps> give me a few minutes to check again
2019-05-31 15:16:00 <ncopa> so is greenbone-securitu-assistant runtime broken?
2019-05-31 15:16:22 <ncopa> what was tthe problem with qt5-qtwebengine?
2019-05-31 15:16:30 <ncopa> it builds on x86_64 and armv7
2019-05-31 15:16:45 <ncopa> is the problem filed in any bug report?
2019-05-31 15:17:33 <mps> 'apk search hiredis' doesn't list hiredis
2019-05-31 15:19:22 <ncopa> what branch?
2019-05-31 15:19:25 <ncopa> edge?
2019-05-31 15:19:28 <ncopa> 3.10?
2019-05-31 15:19:28 <mps> edge
2019-05-31 15:20:10 <ncopa> interesting
2019-05-31 15:20:13 <ncopa> it is missing indeed
2019-05-31 15:21:10 <p4Wv1qn095FW> ncopa re qt5-qtwebengine: https://github.com/alpinelinux/aports/pull/7767
2019-05-31 15:21:21 <mps> just rebuilt hiredis locally and greenbone-security-assistant started to builds, looks like will take some time for all tests
2019-05-31 15:21:44 <_ikke_> ncopa: hiredis failed to build the other day, and it seems to have never proceeded to build for armv7
2019-05-31 15:22:35 <ncopa> the only thing i foudn on hiredis was #10405
2019-05-31 15:22:55 <ncopa> lets track the issues there and not in some random PR
2019-05-31 15:22:57 <_ikke_> @danieli β”‚ so you're running the busybox ntpd and it's giving out the wrong time (GMT, adjusted from the host time)
2019-05-31 15:22:59 <_ikke_> ugh
2019-05-31 15:23:01 <_ikke_> sorry about that
2019-05-31 15:23:13 <_ikke_> 2019-05-28 10:36:09     algitbot        build-edge-armv7: failed to build hiredis: https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/hiredis/hiredis-0.14.0-r1.log
2019-05-31 15:23:20 <danieli> :)
2019-05-31 15:23:37 <_ikke_> That was still in my tmux buffer :D
2019-05-31 15:25:25 <ncopa> oh
2019-05-31 15:25:35 <ncopa> i think i know what the qt5-qtwebengine issue is
2019-05-31 15:25:58 <ncopa> its probaly the sandbox issue
2019-05-31 15:28:29 <mps> ehm, building greenbone-securitu-assistant: load average: 269.54, 200.67, 99.81 (269, is that posible)
2019-05-31 15:29:30 <mps> it is finished, greenbone-securitu-assistant is built in lxc on armv7 with hiredis built also
2019-05-31 15:30:36 <_ikke_> mps: load can be arbitray high
2019-05-31 15:32:19 <mps> didn't know it is node under the hood :)
2019-05-31 15:34:35 <_ikke_> samba seems to have a giant circular dependency as well
2019-05-31 15:35:30 <_ikke_> samba-client-libs <-> samba-libs <-> samba-common-libs
2019-05-31 15:35:58 <mps> is the pkgrel bump only way to force rebuild hiredis on armv7
2019-05-31 15:36:25 <_ikke_> http://ikke.info/d/alpine-dep-errors.pdf
2019-05-31 15:36:47 <_ikke_> mps: a pkgver bump ;-)
2019-05-31 15:37:30 <mps> no, pkgrel
2019-05-31 15:38:29 <mps> _ikke_: what a graph ;)
2019-05-31 15:39:44 <danieli> ooooohhh, that's a big evil circular dep
2019-05-31 15:40:25 <_ikke_> hmm, great, creduce now fails to build
2019-05-31 15:41:53 <_ikke_> probably to do with the LLVM / clang version
2019-05-31 15:50:43 <mps> ncopa: postgresql patch to enable plperl test again http://tpaste.us/YMkr
2019-05-31 16:07:43 <ncopa> mps: i though i already did that?
2019-05-31 16:08:03 <ncopa> ok, apparently i didnt
2019-05-31 16:08:10 <ncopa> i dont hitnk we need bump pkgrel
2019-05-31 16:10:05 <_ikke_> ncopa: Do you still have access to your container?
2019-05-31 16:11:02 <mps> aha, ok. I thought that the pkgrel bump is needed for rebuild. looks like I will never learn fine points of builders
2019-05-31 16:12:28 <mps> ncopa: would you like me to send new patch or you will fix pkgrel?
2019-05-31 16:14:07 <mps> here it is anyway, not much work http://tpaste.us/5wdX
2019-05-31 16:14:59 <mps> I'm going to drink a glass of red wine :) enough work for now
2019-05-31 16:15:05 <ncopa> tpaste is broken here
2019-05-31 16:15:16 <_ikke_> ncopa: the vpn is broken
2019-05-31 16:15:26 <ncopa> _ikke_: ok
2019-05-31 16:15:29 <mps> for me tpaste works fine
2019-05-31 16:15:54 <_ikke_> mps: it probably tries to go via the vpn
2019-05-31 16:15:56 <ncopa> yeah, its the remote machine thats broke
2019-05-31 16:16:15 <_ikke_> ncopa: Are you connected externally to your build container?
2019-05-31 16:16:25 <ncopa> probably
2019-05-31 16:17:00 <ncopa> mps: i pushed it. thanks!
2019-05-31 16:17:10 <mps> I see, thank you
2019-05-31 16:17:14 <ncopa> _ikke_: i am probably connected via ssh port forward
2019-05-31 16:17:25 <ncopa> ps xa
2019-05-31 16:17:29 <mps> now, wine, see you all later :)
2019-05-31 16:17:36 <_ikke_> mps: enjoy
2019-05-31 16:17:40 <ncopa> mps: have a nice weekend!
2019-05-31 16:17:52 <ncopa> im getting thirsty
2019-05-31 16:18:22 <mps> ehm, come here, I have some 'things' cellar ;)
2019-05-31 16:18:58 <ncopa> :)
2019-05-31 16:19:18 <ncopa> ok i think i will tag the rc1 as soon as the qt5-qtwebengine is done building
2019-05-31 16:19:29 <ncopa> and remind me on monday to fix it
2019-05-31 16:19:33 <ncopa> i think i know what the problem is
2019-05-31 16:40:31 <MY_R> hello, any plan to move "i3blocks" from testing to community? I'm using it since few weeks and all working just great :)
2019-05-31 16:40:59 <_ikke_> Try to contact Marvin Steadfast, the maintainer
2019-05-31 16:41:39 <danieli> yeah, I can also confirm that it works well
2019-05-31 16:41:45 <danieli> same goes for polybar
2019-05-31 16:43:52 <_ikke_> creduce says it needs llvm4
2019-05-31 16:44:51 <_ikke_> I don't think we have llvm 4 anymore
2019-05-31 17:01:19 <ncopa> the 96 core aarch64 builder is the slowest of our builders
2019-05-31 17:04:36 <danieli> that's ironic
2019-05-31 17:04:37 <danieli> why?
2019-05-31 17:05:01 <ncopa> i think each core is significatly slower
2019-05-31 17:05:14 <ncopa> and not all jobs are well parallelized
2019-05-31 17:05:25 <ncopa> specifically things like configure script
2019-05-31 17:05:33 <ncopa> autotools in general
2019-05-31 17:06:39 <ncopa> g++: fatal error: Killed signal terminated program cc1plus
2019-05-31 17:06:45 <ncopa> on aarch64
2019-05-31 17:07:17 <danieli> right, some jobs aren't parallelized at all, and the per-core performance might be crappeier
2019-05-31 17:07:19 <danieli> crappier
2019-05-31 17:07:22 <danieli> which chip, and how many?
2019-05-31 17:07:32 <ncopa> thunderx iirc
2019-05-31 17:09:10 <ncopa> [12887072.339189] Out of memory: Kill process 91394 (cc1plus) score 10 or sacrifice child
2019-05-31 17:09:10 <ncopa> [12887072.347115] Killed process 91394 (cc1plus) total-vm:1479384kB, anon-rss:1358856kB, file-rss:0kB, shmem-rss:0kB
2019-05-31 17:13:09 <ncopa> so 128G ram is not enough for 2 x builds of qtwebengine....
2019-05-31 17:13:15 <ncopa> this is insane...
2019-05-31 17:13:24 <danieli> qt is bloated :)
2019-05-31 17:15:13 <Cogitri> Well, It's more of a case of Chromium/Blink not being fun to build, especially in jumbo build modus
2019-05-31 17:21:11 <Cogitri> How can I do `fixes issue x` for Redmine?
2019-05-31 17:21:35 <PureTryOut[m]> So the CI fails on a PR of mine, but the "download" log button doesn't work for me so I don't know what's wrong
2019-05-31 17:21:43 <mps> Cogitri: fix: #number
2019-05-31 17:21:50 <Cogitri> Ah, thanks
2019-05-31 17:21:57 <mps> or, fixes: #number
2019-05-31 17:22:20 <mps> I forgot exactly, tbh
2019-05-31 17:22:27 <Cogitri> PureTryOut: FWIW, the button doesn't work for me in FF either but it does in Chromium πŸ€”
2019-05-31 17:22:46 <PureTryOut[m]> Oh you're right cogitri , it works in Falkon. Wtf
2019-05-31 17:23:45 <Cogitri> 
ACTION shrugs

2019-05-31 17:26:14 <ncopa> "fixes #<number>"
2019-05-31 17:26:41 <Cogitri> Thank you
2019-05-31 18:04:02 <_ikke_> Trying to get creduce to build
2019-05-31 18:04:07 <ncopa> i will tag rc1 now
2019-05-31 18:04:12 <_ikke_> There is some llvm incompatibility
2019-05-31 18:07:47 <_ikke_> ncopa: Should these still be fixed? http://ikke.info/d/alpine-dep-errors.pdf
2019-05-31 18:08:40 <ncopa> i dont think we need fix them for rc1
2019-05-31 18:08:49 <ncopa> but we should try fix them for rc2
2019-05-31 18:08:51 <Cogitri> BTW, does someone have an opinion about patching the GPL-only symbols required for ZFS's SIMD stuff back into the kernel for non GPL stuff?
2019-05-31 18:08:57 <_ikke_> ncopa: alright
2019-05-31 18:09:07 <Cogitri> The patch is pretty small and noninvasive, other distros apply it too
2019-05-31 18:12:01 <ncopa> my opinion is that we should get rc1 out and nothing else matters
2019-05-31 18:12:58 <_ikke_> builders are idle and now errors
2019-05-31 18:13:06 <_ikke_> s/now/no/
2019-05-31 18:13:06 <alpine-meetbot> _ikke_ meant to say: builders are idle and no errors
2019-05-31 18:13:20 <ncopa> please dont push
2019-05-31 18:13:22 <ncopa> im tagging
2019-05-31 18:13:28 <_ikke_> I'm not pushign
2019-05-31 18:17:12 <Cogitri> Alright
2019-05-31 18:20:04 <ncopa> its done
2019-05-31 18:20:31 <Cogitri> πŸ‘
2019-05-31 18:21:35 <ncopa> sweet
2019-05-31 18:23:07 <_ikke_> \o/
2019-05-31 18:23:27 <_ikke_> I can push again?
2019-05-31 18:25:34 <ncopa> it seems like it all worked
2019-05-31 18:25:37 <ncopa> hang a sec
2019-05-31 18:25:58 <ncopa> wait tilb build.a.o says idle for all v3.10
2019-05-31 18:29:47 <_ikke_> k
2019-05-31 18:30:47 <ncopa> its all done
2019-05-31 18:31:29 <ncopa> feel free to push :)
2019-05-31 18:31:39 <ncopa> 3.10.0_rc1 is out
2019-05-31 18:31:58 <Cogitri> Hooray
2019-05-31 18:51:16 <PureTryOut[m]> Damn, Travis is quite a lot slower than Drone... Drone CI succeeded on all arches (although aarch64 takes way longer than for example x86), and Travis failed due to exceeding maximum time
2019-05-31 18:54:28 <Cogitri> Yeah, Travis is pretty slow overall
2019-05-31 18:57:09 <PureTryOut[m]> So I guess Drone is going to replace it for Alpine?
2019-05-31 19:11:06 <_ikke_> Maybe
2019-05-31 19:12:10 <Cogitri> IMHO having two different CI providers isn't a bad idea
2019-05-31 19:12:43 <Cogitri> But maybe we could use smth other than Travis. I haven't used anything but Travis, Drone and Gitlab CI as of now though
2019-05-31 19:13:52 <danieli> as long as we don't self host jenkins
2019-05-31 19:14:13 <Cogitri> Yup, that'd be nightmare-ish
2019-05-31 19:14:22 <Cogitri> Had to use Jenkins via Gerrit for some months, that wasn't fun
2019-05-31 19:14:27 <danieli> it's just terrible, in nearly every single way
2019-05-31 19:14:32 <danieli> security wise, it's like an open door
2019-05-31 19:14:42 <danieli> or.. it's like 10 open doors next to each other
2019-05-31 19:17:24 <PureTryOut[m]> Hmm. Well, anyways, KDE Frameworks tier 3 PR is up
2019-05-31 19:17:39 <PureTryOut[m]> There is only tier 4 left (which is just a single package) after this, and then KDE Frameworks is fully packaged
2019-05-31 19:39:55 <SpaceToast> nice!
2019-05-31 19:40:38 <SpaceToast> re: jenkins; it's extremely featureful, but security-wise the plugins are... special
2019-05-31 19:44:12 <_ikke_> font-bakoma has 2 subpackages. font-bakoma-ttf and font-bakoma-otf. font-bakoma depends on fontconfig and font-bakoma-ttf. Because font-bakome-ttf does not clear dependencies, it inherits the dependencies and thus depends on itself
2019-05-31 19:45:35 <_ikke_> I can empty the dependencies on font-bakoma-ttf, but then it does not depend on fontconfig (not sure if required),
2019-05-31 19:51:18 <_ikke_> Why would fontconfig be a dependency?
2019-05-31 19:58:28 <SpaceToast> fontconfig handles discovery of fonts, right?
2019-05-31 19:58:40 <SpaceToast> and figured out what they contain (for fallthrough/fallback)
2019-05-31 19:58:44 <SpaceToast> I'd imagine that's related
2019-05-31 19:58:52 <_ikke_> Should the font depend on it though?
2019-05-31 19:59:32 <SpaceToast> hmm
2019-05-31 19:59:44 <SpaceToast> I mean, in what scenario would you want to have the font installed
2019-05-31 19:59:51 <SpaceToast> but be unable to actually use it?
2019-05-31 19:59:55 <SpaceToast> (outside of hardcoding the path etc)
2019-05-31 20:38:30 <PureTryOut[m]> _ikke_: I made a new PR depending on the KDE Frameworks tier 3 PR, could you label it as such? https://github.com/alpinelinux/aports/pull/8334
2019-05-31 20:38:53 <_ikke_> PureTryOut[m]: I think I was just ahead of you ;-)
2019-05-31 20:39:31 <PureTryOut[m]> Oh haha nice, that was quick
2019-05-31 20:39:41 <PureTryOut[m]> It's the very last PR of KDE Frameworks
2019-05-31 20:54:53 <SpaceToast> PureTryOut[m]: are you planning to keep the behemoth up to date?
2019-05-31 20:55:10 <SpaceToast> If so, I'll definitely set up some test environment :)
2019-05-31 20:55:13 <PureTryOut[m]> Yes, very much so
2019-05-31 20:55:20 <PureTryOut[m]> Been doing it for like 2 years already on postmarketOS
2019-05-31 20:55:51 <SpaceToast> :) nice
2019-05-31 20:56:02 <SpaceToast> So you're the one I'm going to bug whenever something breaks ;)
2019-05-31 20:56:40 <PureTryOut[m]> Definitely!
2019-05-31 20:56:54 <PureTryOut[m]> Hopefully nothing breaks ever, but that's just wishful thinking
2019-05-31 20:57:13 <SpaceToast> Well, it's also plasma5
2019-05-31 20:57:47 <SpaceToast> Somehow they still haven't gotten non-integer dpi scaling on Wayland
2019-05-31 20:57:48 <jwh> SpaceToast: o/
2019-05-31 20:59:34 <SpaceToast> heya jwh
2019-05-31 20:59:39 <jwh> hiiii
2019-05-31 21:00:38 <SpaceToast> ?
2019-05-31 21:00:49 <SpaceToast> sorry I'm real tired after dealing with DO today
2019-05-31 21:00:50 <mps> SpaceToast: 'behemoth' ;) I'm trying to escape this term here but it pops too often to my fingers. :D
2019-05-31 21:01:02 <jwh> I dunno, in a 'hiiii' mood
2019-05-31 21:01:05 <jwh> oh :(
2019-05-31 21:01:07 <SpaceToast> mps: I say it lovingly - I've yet to meet a DE I like more than plasma
2019-05-31 21:01:17 <SpaceToast> this should probably move to #alpine-offtopic though
2019-05-31 21:02:05 <mps> I don't know plasma at all. I mean, this could used as generic term for some things
2019-05-31 21:02:17 <mps> yes, right
2019-05-31 21:02:33 <PureTryOut[m]> although Plasma will run fine on X11 (on Alpine too), I personally only care about Wayland really
2019-05-31 21:03:15 <Cogitri> How's Plasma Wayland now?
2019-05-31 21:03:34 <Cogitri> Last time I tried it was pretty bad (but that must've been at about GNOME ~3.28)
2019-05-31 21:03:34 <PureTryOut[m]> If you use 1 screen, alright
2019-05-31 21:03:51 <Cogitri> That's my impression with GNOME too :P
2019-05-31 21:03:54 <PureTryOut[m]> On my desktop with 2 always-on screen, and a 3rd which reconnects itself every time it's turned off or on, it's pretty bad
2019-05-31 21:04:24 <Cogitri> I use GNOME in Xorg mode right now because Wayland likes to crash when I drag applications from my big monitor to my built-in screen
2019-05-31 21:04:35 <Cogitri> It's a shame though, Wayland's touch capabilities are super nice
2019-05-31 21:04:54 <Cogitri> But with Wayland it's so super annoying when the whole session dies when the compositor dies
2019-05-31 21:05:10 <Cogitri> I haven't had Xorg crash on me yet, but I think I'm well over 100 Mutter crashes
2019-05-31 21:06:04 <PureTryOut[m]> Plasma shell has crashed on me on Wayland, but I could relaunch it and the compositor was still fine
2019-05-31 21:06:13 <PureTryOut[m]> KWin itself on Wayland seems stable enough
2019-05-31 21:07:12 <Cogitri> Yeah, sadly gnome-shell, gjs and mutter are super interconnected, so if one of them dies all of them die
2019-05-31 21:07:23 <PureTryOut[m]> Ah that is dissapointing
2019-05-31 21:07:32 <PureTryOut[m]> The shell is really it's own thing on KDE
2019-05-31 21:07:44 <Cogitri> So a bad extension can crash your whole session, which is pretty terrible tbh
2019-05-31 21:07:50 <PureTryOut[m]> That's why you can just swap it out for the mobile one if you want
2019-05-31 21:07:56 <PureTryOut[m]> <Cogitri "So a bad extension can crash you"> Ouch
2019-05-31 21:08:47 <Cogitri> But I still love GNOME's look and how I can use it, so yeah, I'll keep pumping out PRs for GNOME stuff :P
2019-05-31 21:09:15 <PureTryOut[m]> Haha I'm glad that's happening. I'm maintaining Phosh on postmarketOS too (even though I won't use it myself lol), so I need your stuff πŸ˜‰
2019-05-31 21:11:46 <Cogitri> Hehe
2019-05-31 21:13:08 <danieli> i enjoy how gnome-shell looks and feels, but not interacting with the tech it's built on
2019-05-31 21:17:32 <SpaceToast> PureTryOut[m]: if and when they add real dpi scaling to wayland (so including 1.4 etc scaling), call me? :D
2019-05-31 21:17:40 <SpaceToast> that and rofi are the last two major blockers for me
2019-05-31 21:17:53 <PureTryOut[m]> Lol. I don't use scaling so I don't keep track off it sorry
2019-05-31 21:17:58 <SpaceToast> ah
2019-05-31 21:18:07 <SpaceToast> my displays at home are all 1440p
2019-05-31 21:18:32 <PureTryOut[m]> My only bigger tahn 1080 screen is a 4K TV which is set to 1080p and causes crashes on Wayland lol
2019-05-31 21:18:32 <SpaceToast> without dpi (especially on a laptop) it's kind of hard to use
2019-05-31 21:18:37 <SpaceToast> but scaling=2 is way overkill
2019-05-31 21:21:27 <Cogitri> You mean fractional scaling? Didn't they add that already, or is that just GNOME?
2019-05-31 21:30:09 <SpaceToast> Cogitri: plasma5 has it on X11, but not on Wayland (last I checked)
2019-05-31 21:30:17 <SpaceToast> so it's a blocker for wayland, for me
2019-05-31 21:31:32 <Cogitri> Oh :c
2019-05-31 21:34:30 <PureTryOut[m]> At least soon you can run Plasma on Alpine with X11 πŸ˜ƒ
2019-05-31 21:34:37 <PureTryOut[m]> No Discover (packagekit) support though 😭
2019-05-31 21:36:19 <Cogitri> Packagekit support in apk would be very nice indeed
2019-05-31 21:36:48 <Cogitri> But touching C πŸ˜’
2019-05-31 21:49:03 <mps> uhm, were we are from: "Alpine is a modular embedded linux distribution for use in small appliances such as routers, VPN gateways, and more." https://bugs.alpinelinux.org/projects/alpine
2019-05-31 21:49:39 <danieli> Cogitri: i don't mind C at all, but apk's source is pretty much completely undocumented
2019-05-31 21:49:47 <danieli> i worked on apk python bindings for a bit
2019-05-31 21:50:09 <Cogitri> That doesn't make it better :c
2019-05-31 21:53:27 <eu> packagekit was dead last I heard
2019-05-31 21:54:36 <PureTryOut[m]> It might be, but the big DE's use it as backend for their graphical sofware managers
2019-05-31 21:54:53 <north1> eu: It is a walking dead
2019-05-31 21:55:31 <eu> "Over the years, most package managers have withered and died, and for the desktop at least really only two remain, .rpm and .deb. The former being handled by the dnf PackageKit backend, and the latter by aptcc"
2019-05-31 21:55:43 <eu> https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
2019-05-31 21:56:57 <eu> so, debian and redhat derivatives are the only desktop linux systems
2019-05-31 21:57:21 <mps> eu: mostly true
2019-05-31 21:57:49 <jwh> except they're both horrific at desktop uses
2019-05-31 21:57:50 <jwh> lol
2019-05-31 21:58:45 <mps> jwh: for you maybe, but for non professional users it is best choice
2019-05-31 21:59:24 <jwh> debian is way to outdated for desktop use, especially with the way things move (gpus, 3d etc)
2019-05-31 21:59:46 <mps> it is not if you use unstable
2019-05-31 22:00:03 <jwh> meh, its better I guess
2019-05-31 22:01:00 <mps> and debian unstable is stable approximately as alpine stable
2019-05-31 22:48:07 <Cogitri> mps: Could you test the new version of webkit2gtk (pr8257) on armv7 please? :)
2019-05-31 22:49:00 <mps> Cogitri: will do tomorrow, it is late here and I'm tired already
2019-05-31 22:49:24 <mps> except if you are in big hurry
2019-05-31 22:50:44 <Cogitri> Ah, no worries, tomorrow is fine :)
2019-05-31 22:50:54 <Cogitri> Thanks and good night, I guess
2019-05-31 22:58:30 <SpaceToast> mps: main website says we're general purpose :/
2019-05-31 22:58:37 <SpaceToast> Sounds like one should be adjusted
2019-05-31 22:58:54 <SpaceToast> That was indeed a whole thing, and iirc ncopa referred to the about page
2019-05-31 22:59:13 <SpaceToast> https://alpinelinux.org/about/
2019-05-31 22:59:35 <SpaceToast> Obviously, being small and modular is great, but I don't see why that should prevent us from running plasma and other niceties
2019-05-31 22:59:39 <mps>  SpaceToast: well, I'm not against what is on main page, just wanted a little humor
2019-05-31 22:59:44 <SpaceToast> It definitely should t be in main/ though
2019-05-31 22:59:48 <SpaceToast> Ah, okay :)
2019-05-31 23:00:15 <SpaceToast> For instance, I primarily use alpine as a server side os
2019-05-31 23:00:28 <mps> also, I'm adding some things which are far from small
2019-05-31 23:00:48 <SpaceToast> (lxd needs a few tweaks, and can't run systemd guests well, but hey)
2019-05-31 23:01:02 <SpaceToast> Re: discover/packagekit, I find it really annoying
2019-05-31 23:01:17 <SpaceToast> PureTryOut[m]: if you do get it packaged, could you exclude it from auto install stuff? :D
2019-05-31 23:02:34 <mps> Cogitri: to not forget, we need 8257 test on armv7?
2019-05-31 23:04:03 <mps> I have to stay awake, to care about one of my server on problematic cloud provider :(
2019-05-31 23:06:05 <Cogitri> <mps "cogitri: to not forget, we need "> Yes please, CI times out. I think it shouldn't be stuck anymore
2019-05-31 23:06:13 <Cogitri> Oh :c
2019-05-31 23:17:25 <PureTryOut[m]> SpaceToast: exclude it from auto install stuff? What do you mean?
2019-05-31 23:17:38 <SpaceToast> I
2019-05-31 23:17:42 <SpaceToast> I.e no depends
2019-05-31 23:17:54 <SpaceToast> So if I install plasma-meta or whatever it isn't auto included
2019-05-31 23:18:28 <PureTryOut[m]> You mean Discover/packagekit?
2019-05-31 23:18:32 <SpaceToast> Yes
2019-05-31 23:18:38 <SpaceToast> Well discover in general really
2019-05-31 23:18:46 <PureTryOut[m]> I think plasma-meta or something will just contain enough to get a basic shell on X11 and Wayland
2019-05-31 23:18:59 <PureTryOut[m]> I might make a plasma-meta-extra package which contains that type of stuff
2019-05-31 23:19:44 <SpaceToast> I'd just like some way to exclude it, really
2019-05-31 23:20:01 <SpaceToast> I'm fine with most plasma things, but discover actively pops up in your face and such
2019-05-31 23:20:23 <PureTryOut[m]> Well, you can at that point install plasma-meta plus all packages you want, and it won't include Discover
2019-05-31 23:21:00 <SpaceToast> I guess, just means I can't use plasma-meta-extra
2019-05-31 23:21:18 <SpaceToast> Though I'd probably want 95% of what's in there ^^;;
2019-05-31 23:21:23 <PureTryOut[m]> Yeah
2019-05-31 23:21:32 <PureTryOut[m]> For a full featured desktop Discover just makes sense
2019-05-31 23:21:40 <PureTryOut[m]> Well there is no harm in installing all that stuff manually
2019-05-31 23:21:45 <PureTryOut[m]> And you can just copy from the depends line then lol
2019-05-31 23:22:15 <SpaceToast> Yeah probably just run a custom virtual
2019-05-31 23:22:43 <SpaceToast> Wonder if there's a way to do an arch-like "package provides" to pretend it's already installed
2019-05-31 23:23:04 <SpaceToast> Or was that Gentoo?
2019-05-31 23:23:55 <Cogitri> FWIW, with gnome I just do `gnome` for the base stuff and `gnome-apps` for everything else
2019-05-31 23:24:08 <PureTryOut[m]> Yeah I was thinking of just `plasma`
2019-05-31 23:24:12 <Cogitri> Maybe I'll add gnome-game-collection somewhere along the line
2019-05-31 23:24:24 <Cogitri> Just plasma seems better to me
2019-05-31 23:24:32 <PureTryOut[m]> But let's first get KDE Frameworks merged lol
2019-05-31 23:24:57 <SpaceToast> If we wanna be idiomatic it should probably be plasma-desktop
2019-05-31 23:25:35 <PureTryOut[m]> Nope, that is already a KDE package
2019-05-31 23:26:00 <SpaceToast> Ah
2019-05-31 23:26:19 <SpaceToast> But yeah, xfce-desktop and alpine-desktop are the meta packages for that iirc
2019-05-31 23:26:39 <PureTryOut[m]> We're calling it meta packages, so why not `plasma-meta`, `gnome-meta`, `xfce-meta`, etc?
2019-05-31 23:27:08 <PureTryOut[m]> In that case it would be `plasma-desktop-meta` and possibly `plasma-mobile-meta` in the future
2019-05-31 23:28:41 <Cogitri> Dunno, I'd personally wouldn't search for a gnome-meta package
2019-05-31 23:29:05 <Cogitri> I'd do `apk install <desktop>` and expect it to take it from there
2019-05-31 23:29:28 <PureTryOut[m]> That does make sense
2019-05-31 23:29:49 <PureTryOut[m]> Oh well, then it'll be `apk install plasma` and `apk install plasma-mobile`