2019-03-01 00:42:17 <LucasRamage[m]> Greetings, I have submitted quiet a few patches to bump my packages in the aports tree and I haven't seen them move in awhile. Most notably, there is a revision bump for efibootmgr to version 17, https://lists.alpinelinux.org/alpine-aports/5602.html
2019-03-01 00:43:37 <SpaceToast> heya LucasRamage[m], going through patches is still taking a while (everyone's tired after the highly troublesome and belated 3.9 release). feel free to come in here and bump it on occasion, but do note that you'll have better success during the daylight hours in europe (where most of the core devs are)
2019-03-01 00:47:40 <LucasRamage[m]> Is it faster to open a pull-request on github? I'd prefer sending a patch, but I do have a github account too.
2019-03-01 00:51:15 <SpaceToast> it might be a bit faster, I only really see rnalrd do email reviews on a regular basis
2019-03-01 00:51:29 <SpaceToast> if your patch is small, you can try putting it on tpaste and pasting it here when one of the core devs is around
2019-03-01 00:51:36 <SpaceToast> (that's the fastest method, generally)
2019-03-01 00:56:01 <LucasRamage[m]> Oh really? Hmm, that might work.
2019-03-01 00:56:18 <LucasRamage[m]> How many people have commit access? Are there only a few core devs?
2019-03-01 00:56:43 <SpaceToast> yes, we have slight organizational problems in that regard
2019-03-01 00:57:13 <SpaceToast> but there's been some movement in favor of team-based management, and I'm planning to submit a proposal once I start working on the developer documentation
2019-03-01 00:57:20 <SpaceToast> so there's a chance things will improve soon :tm:
2019-03-01 00:58:44 <LucasRamage[m]> That doesn't surprise me. I've been working on becoming a Gentoo developer since 2016. Their onboarding process needs some work as well. That sounds really nice though.
2019-03-01 00:58:51 <SpaceToast> heh
2019-03-01 00:58:54 <SpaceToast> I'm ex-gentoo
2019-03-01 00:59:05 <SpaceToast> (well, I never became an official developer, but I did quite a few things)
2019-03-01 00:59:07 <LucasRamage[m]> Yeah? Official dev?
2019-03-01 00:59:22 <LucasRamage[m]> Oh I see
2019-03-01 00:59:23 <SpaceToast> I'm friends with several official devs so whenever there was any roadblock I'd just poke poke nudge nudge
2019-03-01 00:59:33 <SpaceToast> so I never ended up bothering
2019-03-01 00:59:44 <SpaceToast> considered it a few times and would have likely had an accelerated process though
2019-03-01 01:05:09 <jwh> pick me pick me!
2019-03-01 01:24:17 <LucasRamage[m]> SpaceToast: thanks again for the info. I'll try hopping on this weekend some time when I get the chance.
2019-03-01 07:03:01 <ncopa> morning
2019-03-01 07:03:35 <ncopa> imsort of an ex-gentoo as well. i think i got an official mentor assigned to me and started the process to become an official gentoo dev
2019-03-01 07:03:58 <ncopa> but alpine broke out to its own thing
2019-03-01 07:08:47 <SpaceToast> :) hey ncopa
2019-03-01 07:12:02 <ncopa> hi
2019-03-01 07:12:25 <ncopa> LucasRamage[m]: pushed your patch. thanks for the ping
2019-03-01 08:06:25 <mps> ncopa: imagine, we already have ell library in main/libell
2019-03-01 08:09:52 <mps> iwd will not work in it's current state, need enbled glib and reworking of patches
2019-03-01 08:10:20 <mps> i mean, iwd will not work with libell
2019-03-01 08:11:40 <mps> these two packages (main/libell and testing/ell) needs to merged/fixed
2019-03-01 08:52:35 <ncopa> mps: let’s fix main/libell
2019-03-01 08:52:49 <mps> looked through aports and found only bluez depends on libell, and bluez maintainer are ncopa
2019-03-01 08:52:57 <ncopa> and maybe rename it
2019-03-01 08:53:24 <ncopa> yeah, I had a feeling that ell was familiar
2019-03-01 08:53:47 <mps> I'm for simple move from testing/ell to main with name ell, and fix bluez depends
2019-03-01 08:55:07 <mps> tried to conclude right naming scheme for libs in Alpine and see it is not consistent but prevalence is in favour to ell
2019-03-01 08:56:28 <mps> of course, you know better and should decide
2019-03-01 10:45:46 <p4Wv1qn095FW> mps: it seems the kicad dependency bug has been fixed by upstream: https://github.com/g-truc/glm/issues/832#issuecomment-468612087 - so i closed my pr, and i tried to flag it - but i'm not sure i succeed in flagging it.
2019-03-01 10:52:27 <mps> p4Wv1qn095FW: nice to know. does that mean that the glm should be upgraded on Alpine after upstream releases next version with this fix
2019-03-01 10:54:31 <clandmeter> p4Wv1qn095FW: flag on pkgs.a.o?
2019-03-01 10:56:02 <p4Wv1qn095FW> mps there is a new release already with the fix.
2019-03-01 10:57:00 <p4Wv1qn095FW> clandmeter: yeah i tried to flag it on p.a.o. but dunno how it should confirm the fact of being flagged. i checked both the pkg page and the list of flagged pkgs and could not see it.
2019-03-01 10:57:12 <clandmeter> stable or edge?
2019-03-01 10:57:53 <p4Wv1qn095FW> does flagging need a valid email address? i used @example.com...
2019-03-01 10:58:03 <p4Wv1qn095FW> i flagged here: https://pkgs.alpinelinux.org/flag/community/glm/0.9.9.3-r1
2019-03-01 10:58:39 <clandmeter> what was the responce?
2019-03-01 11:00:32 <p4Wv1qn095FW> getting back teh flag form, without any form field hilited as invalid
2019-03-01 11:02:28 <mps> p4Wv1qn095FW: new release with same version number?
2019-03-01 11:16:35 <p4Wv1qn095FW> mps, no new version number 0.9.9.4
2019-03-01 11:16:50 <fabo> ncopa: clandmeter: do you mind if I submit a new ser2net release? 3.5.1
2019-03-01 11:17:36 <mps> p4Wv1qn095FW: so Alpine glm APKBUILD should update pkgrel
2019-03-01 11:18:21 <mps> meh, pkgver
2019-03-01 11:35:06 <p4Wv1qn095FW> yeah, that's what flagging is for afaiu
2019-03-01 11:56:52 <p4Wv1qn095FW> shit, there is no new release, it is only in the releasebranch for 0.9.9.4
2019-03-01 11:57:05 <p4Wv1qn095FW> forget my attempt to flag glm.
2019-03-01 11:57:14 <p4Wv1qn095FW> i'm sooo lame. sorry guys.
2019-03-01 11:57:52 <mps> p4Wv1qn095FW: no problem, we all overlook something from time to time
2019-03-01 12:19:31 <ncopa> fabo: I don’t mind
2019-03-01 12:20:48 <fabo> thanks
2019-03-01 13:31:53 <fabo> ncopa: https://github.com/alpinelinux/aports/pull/6515
2019-03-01 13:35:38 <danieli> looks good to me, but I haven't built it locally to test
2019-03-01 13:36:14 <fabo> danieli: talking to me?
2019-03-01 13:36:52 <danieli> yes
2019-03-01 13:37:04 <danieli> well, to whoever is looking at that PR
2019-03-01 13:37:15 <fabo> danieli: ok :) I did. Build and tested on both x86 and Aarch64.
2019-03-01 13:46:26 <clandmeter> drone builds on more arches :)
2019-03-01 13:47:08 <jwh> hey did someone fix it
2019-03-01 13:47:23 <clandmeter> define it
2019-03-01 13:47:36 <jwh> oh no sorry I'm a potato
2019-03-01 13:47:38 <jwh> as you were
2019-03-01 13:48:56 <ncopa> fabo: good work on that PR
2019-03-01 13:49:18 <ncopa> i have a few nitpicks, but i think maybe just merge it as is and cleanup myself afterwards
2019-03-01 13:49:34 <jwh> hm, shall I open an issue for the drone thing so it's tracked?
2019-03-01 13:49:45 <ncopa> jwh: i think thats a good idea
2019-03-01 13:50:11 <ncopa> becaure there may be amy issues with drone
2019-03-01 13:50:24 <jwh> yes
2019-03-01 13:50:37 <ncopa> and when you say "have you fixed the issue with drone" then we have no idea what you are talking about :)
2019-03-01 13:50:38 <jwh> although I thin this one in particular just needs a bit more sanity checking of the environment in build.sh
2019-03-01 13:50:43 <jwh> think*
2019-03-01 13:51:24 <ncopa> great if you have an idea or suggestion how to fix. write that down on the bug tracker as well
2019-03-01 13:51:45 <fabo> ncopa: if I may abuse your time and get you look at https://github.com/alpinelinux/aports/pull/6446 it will be great
2019-03-01 13:51:49 <jwh> problem is, although the x86 image is used, drone starts an amd64 container - noticed because android-tools seems to use kernel/uname arch
2019-03-01 13:52:02 <jwh> so it may just be worth explicitly setting that for x86
2019-03-01 13:52:04 <ncopa> fabo: its a matter of taste, but i prefer to avoid use $pkgname in url
2019-03-01 13:52:13 <jwh> which repo does build.sh live in?
2019-03-01 13:52:53 <ncopa> fabo: when i look at an APKBUID and want have info from upstream (where to report bugs, or to look for new version), i normally copy paste the url from APKBUILD
2019-03-01 13:53:10 <fabo> ncopa: no problem, just write your comments on the PR and I'll fix them
2019-03-01 13:53:14 <ncopa> if there is a $pkgname there then i will have to manually expand
2019-03-01 13:53:15 <ncopa> ok
2019-03-01 13:53:18 <ncopa> great
2019-03-01 13:53:29 <fabo> sure, it make sense
2019-03-01 13:53:50 <jwh> nm got it
2019-03-01 13:55:21 <jwh> hm, not sure build.sh is the right place to fix this actuall
2019-03-01 13:55:24 <jwh> actually*
2019-03-01 13:57:21 <clandmeter> jwh: im talking with drone ppl to fix this.
2019-03-01 13:57:33 <jwh> oh ok
2019-03-01 13:57:44 <jwh> would be easier if they could do it yeah
2019-03-01 13:57:55 <clandmeter> they are willing
2019-03-01 13:58:04 <clandmeter> not sure yet how
2019-03-01 13:58:15 <clandmeter> initially probably from the entrypoint
2019-03-01 13:58:23 <jwh> if they could define a 32bit platform and just exec stuff with the right arch that would do
2019-03-01 13:58:38 <ncopa> its the linux32 issue on 32 bit containers?
2019-03-01 13:58:45 <jwh> yeah
2019-03-01 13:58:48 <clandmeter> yes
2019-03-01 13:58:56 <ncopa> i think thats something that should be fixed in docker itself
2019-03-01 13:58:57 <jwh> container is actually x86_64
2019-03-01 13:59:03 <jwh> so it's tripping some thing sup
2019-03-01 13:59:06 <jwh> things up*
2019-03-01 13:59:13 <clandmeter> jwh: https://git.alpinelinux.org/alpine-drone-ci/
2019-03-01 13:59:19 <jwh> yeah I'm just looking at that
2019-03-01 13:59:35 <jwh> could fix it there, but  since its an environment thing it should probably be fixed by drone
2019-03-01 13:59:53 <clandmeter> yes we want to fix it in upper level
2019-03-01 14:00:29 <clandmeter> maybe have a switch in docker to call linux32
2019-03-01 14:01:01 <clandmeter> drone could add some option to set amd64 to 32bit
2019-03-01 14:01:06 <jwh> I'm surprised docker doesn't already have the ability to set arch
2019-03-01 14:02:13 <jwh> well I mean, the easiest fix is to just call linux32 build.sh for x86, but heh
2019-03-01 14:02:51 <jwh> feels kinda hacky (although some sanity checking might be worthwhile anyway)
2019-03-01 14:03:18 <ncopa> jwh: agree
2019-03-01 14:03:57 <ncopa> i will try find the right ppl within docker and talk with them
2019-03-01 14:04:06 <ncopa> in theory it should be easy
2019-03-01 14:04:58 <jwh> ok cool
2019-03-01 14:05:26 <jwh> guess I could just add linux32 to the APKBUILD for now
2019-03-01 14:05:35 <clandmeter> you dont have to
2019-03-01 14:05:47 <clandmeter> our builders run in 32bit mode
2019-03-01 14:05:47 <jwh> but if its just the CI thats affected and not the builders its not really worthwhile
2019-03-01 14:05:50 <jwh> yeah
2019-03-01 14:05:53 <ncopa> no, we should not add linux32 to the APKBUILDs
2019-03-01 14:06:14 <jwh> as long as the builders are ok all good I guess
2019-03-01 14:06:47 <ncopa> we may need to add a hack but we should not do that in APKBUILD
2019-03-01 14:06:51 <jwh> yeah
2019-03-01 14:06:52 <jwh> agree
2019-03-01 14:06:53 <ncopa> in worst case we do it in abuild
2019-03-01 14:07:21 <jwh> I was just thinking that might be sensible anyway for non-drone/docker envs
2019-03-01 14:07:58 <ncopa> if [ "$(apk --print-arch)" = "x86" ] && [ "$(uname -m)" = "x86_64" ]; then linux32 $0 "$@"; fi
2019-03-01 14:08:03 <jwh> yup
2019-03-01 14:08:04 <jwh> exactly
2019-03-01 14:08:29 <jwh> mine wasn't quite so elegant, but same result :D
2019-03-01 14:08:48 <ncopa> worst case we add the above to abuild
2019-03-01 14:09:03 <ncopa> other option may be to create a Dockerfile:
2019-03-01 14:09:10 <ncopa> FROM alpine
2019-03-01 14:09:17 <jwh> well, that might be worth doing anyway just for sanity checking
2019-03-01 14:09:20 <ncopa> ENTRYPOINT [ "linux32"]
2019-03-01 14:09:59 <clandmeter> the entrypoint can be overiden right?
2019-03-01 14:10:08 <ncopa> yes, i think so
2019-03-01 14:10:11 <danieli> it can
2019-03-01 14:10:25 <clandmeter> so i think thats maybe not the best way
2019-03-01 14:10:31 <clandmeter> i mean thats what drone does
2019-03-01 14:10:37 <clandmeter> define own entry point
2019-03-01 14:11:00 <ncopa> then we coudl patch drone to set linux32 as entrypoint
2019-03-01 14:11:19 <ncopa> for 32bit x86
2019-03-01 14:11:21 <clandmeter> well we dont control drone on cloud
2019-03-01 14:11:27 <clandmeter> so its not up to us :)
2019-03-01 14:11:38 <danieli> could probably still do a feature request and/or just submit a PR and say that we'd really love to have that feature
2019-03-01 14:11:41 <clandmeter> i think drone should add an option
2019-03-01 14:11:52 <clandmeter> so a 32bit cable machine can switch to it
2019-03-01 14:11:59 <clandmeter> capable..
2019-03-01 14:12:26 <clandmeter> like the aarch64 machine from packet
2019-03-01 14:12:34 <clandmeter> it can also do 32bit
2019-03-01 14:12:52 <jwh> hm, sounds like it might be worth putting those cases in abuild tbf
2019-03-01 14:13:08 <jwh> for 32bit on 64bit, then it's environment agnostic
2019-03-01 14:14:40 <clandmeter> and from drone config it would be clear you run an aarch64 processor in 32bit mode.
2019-03-01 14:24:34 <mps> ncopa: sorry for disturbance, are you decided about ell lib issue what you will do
2019-03-01 14:25:29 <mps> in current state if someone install iwd@testing it pull libell and because that iwd couldn't work
2019-03-01 14:28:23 <mps> if you are short on time I can locally move from testing to main and build bluez with this ell to see how all that works
2019-03-01 14:35:51 <ncopa> looks like there is another maintainer for libeel
2019-03-01 14:35:55 <ncopa> libell
2019-03-01 14:36:35 <ncopa> xpecex
2019-03-01 14:43:40 <mps> yes, I have seen, but it is not important who is maintainer, we need to fix the issue
2019-03-01 15:38:31 <fabo> sourceforge was tempoarary down and caused build failure in CI
2019-03-01 15:38:52 <fabo> can we re-trigger a build for a PR?
2019-03-01 15:41:44 <fabo> nevermind, I just rebased on master and force-pushed
2019-03-01 15:42:11 <clandmeter> fabo: yes thats the easiest
2019-03-01 15:42:49 <clandmeter> i can also re-trigger if really needed
2019-03-01 17:29:13 <mort___> dumb question — does alpine support LSB (specifically, /etc/lsb_release)?
2019-03-01 17:31:35 <SpaceToast> no, but you can find the alpine version in /etc/alpine-release
2019-03-01 17:32:55 <mps> or /etc/os-release
2019-03-01 17:43:43 <mort___> ack thanks!
2019-03-01 18:19:29 <ddevault> py3-sip 4.19.14-r1 made it to the repos, but py3-sip-dev is still at 4.19.5-r0
2019-03-01 18:19:33 <ddevault> cc fcolista
2019-03-01 18:20:15 <ddevault> also, pkgrel in aports is r0, but r1 in the repos
2019-03-01 18:20:36 <ddevault> this caused me a great deal of confusion -_-
2019-03-01 18:24:36 <ddevault> wait a minute
2019-03-01 18:24:47 <ddevault> there's both community/py-sip and community/py3-sip
2019-03-01 18:24:50 <ddevault> and they both define the py3-sip package
2019-03-01 19:59:55 <ace> ncopa we never got that reply from you wrt to the vuln we sent
2019-03-01 20:00:03 <ace> you said you had some questions for us?
2019-03-01 20:51:34 <ncopa> ace: i think i found the answer to my initial question, hot to reproduce it. i realized that the other part i had in mind was more of an excuse so i decided to not send that
2019-03-01 20:59:05 <ace> ah, thanks ncopa, was just checking :)
2019-03-01 21:03:24 <ddevault> does anyone have an opinion on how rust packages ought to be built for alpine
2019-03-01 21:05:09 <SpaceToast> ddevault: you can mostly use cargo build
2019-03-01 21:05:21 <SpaceToast> most of my user-aports is rust-based, so you can look at that for examples
2019-03-01 21:05:44 <ddevault> ty
2019-03-01 21:06:17 <SpaceToast> one thing is enabling static crt, since it's usually autodetected, but the autodetection can be questionable sometimes
2019-03-01 21:06:29 <Mis012[m]> ddevault: for all architectures (firefox)
2019-03-01 21:06:42 <ddevault> SpaceToast: link to your user-aports?
2019-03-01 21:06:55 <SpaceToast> ddevault: https://github.com/5paceToast/user-aports/
2019-03-01 21:07:08 <ddevault> 404
2019-03-01 21:07:10 <ddevault> is this private?
2019-03-01 21:07:19 <SpaceToast> no, I don't have private repos
2019-03-01 21:07:27 <SpaceToast> are you sure it's 404?
2019-03-01 21:07:27 <ddevault> oh, 5, not S
2019-03-01 21:07:36 <Mis012[m]> ddevault: works for me
2019-03-01 21:07:43 <SpaceToast> yeah, S is taken kind of often :/
2019-03-01 21:07:50 <SpaceToast> it's almost always a bot that hasn't done anything ever
2019-03-01 21:08:13 <ncopa> ace: thank you for following it up
2019-03-01 21:09:07 <clandmeter> heh, draft pull requests. didnt see that before.
2019-03-01 21:10:12 <SpaceToast> clandmeter: it was introduced 2 weeks ago or so
2019-03-01 21:10:42 <clandmeter> https://github.blog/2019-02-14-introducing-draft-pull-requests/
2019-03-01 21:11:00 <clandmeter> nice
2019-03-01 21:12:56 <clandmeter> i have a feeling a new release is coming
2019-03-01 21:14:12 <ncopa> im pushing 3.9.1 release now
2019-03-01 22:10:45 <jwh> o/
2019-03-01 22:28:35 <mps> interesting post about musl shebang handling https://www.openwall.com/lists/musl/2018/03/09/1  secure by default :)
2019-03-01 23:26:30 <pixelherodev> How would I go about submitting a patch for Alpine?
2019-03-01 23:27:25 <pixelherodev> Never mind, I found the Wiki. Really need to kick this habit of asking questions Google can answer
2019-03-02 09:42:55 <AinNero> SpaceToast: where did the SIG discussion take place?
2019-03-02 09:47:36 <AinNero> i dont see the advantage of formalizing the teams stuff
2019-03-02 10:02:09 <mps> AinNero: (if you want to disable work make a committee)
2019-03-02 10:14:39 <AinNero> like that. i like the current need-based approach
2019-03-02 10:19:20 <mps> yes, I have (maybe strong) opinion about formalism, special interest groups, CoC's and such, but rather will not write here (maybe on #alpine-offtopic)
2019-03-02 12:38:06 <kaniini> AinNero: there is an advantage.  if it is formalized, then policy can be changed to allow SIGs to hold Maintainer status
2019-03-02 13:30:49 <danieli> AinNero: we discussed it a bit in #alpine-offtopic
2019-03-02 13:31:26 <danieli> there are many advantages, unlike the current semi-disorganized mess
2019-03-02 14:00:14 <clandmeter> ncopa: is there a reason why virt kernel is only included in x86_84 for netboot?
2019-03-02 14:00:40 <AinNero> kaniini: define maintainer status?
2019-03-02 14:25:30 <kaniini> AinNero: Maintainer: ... <foo@bar.com>
2019-03-02 14:27:10 <AinNero> i'd prefer having push access for doing actual work than having my email address written somewhere
2019-03-02 14:29:01 <AinNero> having a badge like 'important person' is surely cool for impressing people, but doing the important work seems like a different show to me
2019-03-02 14:30:58 <SpaceToast> AinNero: the draft simplifies the process of getting push access, and revocation in case it is misused (meaning people are more inclined to give it in the first place)
2019-03-02 14:31:17 <SpaceToast> it also minimizes some of the massive issues we are currently experiencing
2019-03-02 14:31:35 <AinNero> which are?
2019-03-02 14:31:45 <AinNero> the pile of PR requests?
2019-03-02 14:31:56 <SpaceToast> among other things, yes.
2019-03-02 14:32:19 <SpaceToast> less context switching = people that can review are more effective at it. easier access = more people capable of performing review.
2019-03-02 14:33:05 <AinNero> most PRs i look at go at packages that already have a maintainer
2019-03-02 14:33:31 <AinNero> formalizing who is responsible doesn't help with the issue that actual persons need to actually divert time
2019-03-02 14:33:49 <SpaceToast> sure it does, more maintainers = less pressure overall
2019-03-02 14:34:10 <SpaceToast> less context switching = less manhours required to achieve the same tasks
2019-03-02 14:34:41 <SpaceToast> further, being able to document the process of becoming a contributor/developer, as well as a list of developers is important
2019-03-02 14:35:06 <SpaceToast> because right now we're telling people "if you want to contribute, throw your patch in, maybe wait a year, and perhaps something will happen"
2019-03-02 14:35:32 <SpaceToast> and on my list of becoming a developer I have "ask the person you're working with to recommend you to the core team" (what if you're not working with someone directly?)
2019-03-02 14:35:52 <SpaceToast> then you need to have people outside of alpine be able to know who is who when they communicate with us
2019-03-02 14:36:21 <SpaceToast> you also need people within alpine to know that, of course ("who's that person telling me weird things on the user ML?")
2019-03-02 14:36:26 <AinNero> dont take this personally, i dont feel like wanting to think about this ****
2019-03-02 14:36:40 <SpaceToast> then don't?
2019-03-02 14:36:55 <SpaceToast> the proposal is made in such a way that it's close to what's *already present*
2019-03-02 14:37:15 <SpaceToast> you'll have your name listed as a member on an official page, and you'll need to know who else works on the initrd
2019-03-02 14:37:21 <SpaceToast> ... that's about it as far as you're concerned
2019-03-02 14:37:40 <AinNero> if someone wants that, fine
2019-03-02 14:37:46 <SpaceToast> cool :)
2019-03-02 14:37:54 <AinNero> but personally, i'd ask you to do the opposite
2019-03-02 14:38:08 <AinNero> im fine if like, people discover my email address in code i wrote, for cases of support
2019-03-02 14:38:18 <SpaceToast> the opposite clearly has issues, and I just spent 5 minutes listing out reasons that this is an important thing to have
2019-03-02 14:38:32 <AinNero> else i prefer just keeping down with like, badges and self-representation
2019-03-02 14:38:42 <SpaceToast> again, this isn't about badges.
2019-03-02 14:38:47 <SpaceToast> this is about making alpine better.
2019-03-02 14:39:14 <danieli> if you aren't willing to maintain the software you maintain, perhaps it's a bad idea to be a maintainer
2019-03-02 14:39:40 <SpaceToast> and if you are currently a maintainer, and you aren't maintaining it, there would be a process to make you not-the-maintainer anymore
2019-03-02 14:40:27 <danieli> as of right now, every 'active' package should have a maintainer (and optionally contributors) header at the top of the APKBUILD in the format of "# Maintainer $name <$email>"
2019-03-02 14:40:57 <SpaceToast> and yet a bunch of packages that have that are erm, not in the best of states :/
2019-03-02 14:41:21 <danieli> yeah.. it's a shame, lots of flagged, broken(-ish), and unmaintained packages
2019-03-02 14:41:44 <SpaceToast> hugo comes to mind; it's been flagged (by me) since September, and I just threw my own version into user-aports (though we need to adjust how abuild does clean() for go packages in general)
2019-03-02 14:42:05 <SpaceToast> the maintainer hasn't done anything since September of last year to update it
2019-03-02 14:42:46 <AinNero> how do you expect to fix that? replace the maintainer yourself?
2019-03-02 14:43:06 <danieli> it's either that, or moving the package to unmaintained/
2019-03-02 14:43:11 <SpaceToast> no, you kick out the maintainer that isn't doing their job (and remove the Maintainer: line)
2019-03-02 14:43:14 <danieli> because at the current state, it *is* unmaintained
2019-03-02 14:43:27 <SpaceToast> and by making it easier for people to *become* maintainers, a replacement is likely to come along much faster
2019-03-02 14:43:39 <SpaceToast> (especially with the knowledge that there no longer is one, rather than "oh, X is just lazy")
2019-03-02 14:44:03 <SpaceToast> you minimize damage, and you maximize ease of recovery
2019-03-02 14:44:13 <SpaceToast> that's how mitigating bad things generally tends to work :)
2019-03-02 14:45:11 <danieli> if we document the development workflow and tools, perhaps it'd entice the software authors/maintainers to create and maintain alpine packages too
2019-03-02 14:45:40 <danieli> vive la résistance
2019-03-02 14:45:54 <AinNero> i understand your intentions, but i dont see it working out
2019-03-02 14:46:14 <SpaceToast> you keep saying you'd rather not, but you aren't really erm... showing any problems with it
2019-03-02 14:46:21 <SpaceToast> just comparing it to fancy badges and nothing else
2019-03-02 14:46:31 <SpaceToast> even if it was like that, how do fancy badges make things worse?
2019-03-02 14:46:44 <AinNero> example. kaniini is active, i guess?
2019-03-02 14:46:51 <AinNero> and they are the maintainer of communiy/gcompat
2019-03-02 14:47:11 <SpaceToast> that's the context switching problem at work
2019-03-02 14:47:17 <SpaceToast> consider how many packages ncopa maintains
2019-03-02 14:47:20 <AinNero> the libc paths of that pkg are broken for some arches
2019-03-02 14:47:32 <SpaceToast> then look at openrc versions
2019-03-02 14:47:34 <AinNero> my PR to fix that has been open for a month.
2019-03-02 14:47:48 <danieli> they [core devs] have a lot of things to do, and have to switch between them a lot
2019-03-02 14:47:50 <SpaceToast> imagine if there were more, still competent, reviewers ;)
2019-03-02 14:47:51 <danieli> and they have to prioritize
2019-03-02 14:47:59 <danieli> ^
2019-03-02 14:48:04 <SpaceToast> ^ this separates tasks and does improve this situation as well
2019-03-02 14:48:22 <kaniini> fwiw any of my packages can be changed by non-maintainers
2019-03-02 14:48:34 <kaniini> so gcompat is a bad example
2019-03-02 14:48:37 <SpaceToast> further, you've yet to show how the suggestion would make the situation worse, just demonstrating further problems we have currently
2019-03-02 14:48:52 <kaniini> people are just too scared to accept the MR ;)
2019-03-02 14:49:22 <AinNero> kaniini: honestly i dont care much who the maintainer is - it was broken for me, i fixed it for me and i submitted my patch upstream
2019-03-02 14:49:38 <SpaceToast> and due to [issues we are trying to fix], the patch went nowhere
2019-03-02 14:49:57 <kaniini> i mean, i don't really want to be the direct maintainer of most packages i maintain
2019-03-02 14:50:01 <kaniini> gcompat included
2019-03-02 14:50:38 <kaniini> that is why team maintenance is good
2019-03-02 14:50:57 <kaniini> and basically every other distro on the planet has this
2019-03-02 14:51:01 <SpaceToast> ^
2019-03-02 14:51:03 <kaniini> including debian
2019-03-02 14:51:14 <SpaceToast> my proposal was modeled after Gentoo (but with added flexibility to fit our needs)
2019-03-02 14:51:22 <SpaceToast> danieli's proposal was modeled after CentOS
2019-03-02 14:51:33 <AinNero> but for now, the PR not merged, the automated testing is not good enough to have confidence in merging
2019-03-02 14:51:53 <kaniini> if it were up to me
2019-03-02 14:51:56 <AinNero> naming a specialized team for it is just the same problem of finding a person taking responsibility to merge it
2019-03-02 14:52:04 <SpaceToast> mentioning current problems doesn't do much towards the statement that the attempt to solve those problems will make things worse
2019-03-02 14:52:05 <kaniini> i would just restrict gcompat to x86_64 ;)
2019-03-02 14:52:12 <kaniini> oh wait, it is
2019-03-02 14:52:15 <danieli> hahhaha
2019-03-02 14:52:17 <kaniini> so maybe someone else should maintain it
2019-03-02 14:52:33 <kaniini> complaining will get the opposite of what is wanted with me believe that ;)
2019-03-02 14:52:47 <danieli> kaniini: i mean, you *could* move it to unmaintained/ if you just don't have the time to maintain it, and nobody else is stepping up
2019-03-02 14:52:59 <kaniini> danieli: it works on the archs i care about
2019-03-02 14:53:10 <danieli> kaniini: fair enough
2019-03-02 14:53:18 <kaniini> danieli: and the paths being wrong on the archs i do not care about is harmless
2019-03-02 14:53:20 <AinNero> SpaceToast: im not saying its making things worse, but i feel like there is something else behind your confidence that it will make things 'better'
2019-03-02 14:53:39 <danieli> guess you'll have to poke some reviewers :)
2019-03-02 14:53:43 <SpaceToast> o.O
2019-03-02 14:54:00 <SpaceToast> because empirical data and understanding of psychology is evil or something?
2019-03-02 14:54:09 <SpaceToast> I'm confused on what you mean by your statement
2019-03-02 14:54:32 <kaniini> but really stuff like gcompat needs maintenance from specific people on every arch it supports
2019-03-02 14:54:46 <kaniini> which, again, team maintenance provides this
2019-03-02 14:55:14 <kaniini> but again, my packages are allowing zero-threshold non-maintainer updates
2019-03-02 14:55:27 <kaniini> that means just find someone to commit the shit
2019-03-02 14:55:33 <kaniini> it will be 100% fine
2019-03-02 14:55:53 <SpaceToast> (which is easier to do with the proposal in place, since you have a fancy list of people you can try poking, and the list expands easier)
2019-03-02 14:56:08 <kaniini> yes, the other nice thing about having SIGs
2019-03-02 14:56:11 <danieli> needs more reviewers / people with push access :)
2019-03-02 14:56:16 <kaniini> is that we can have a proper mentors SIG
2019-03-02 14:56:20 <kaniini> which can help you
2019-03-02 14:56:23 <kaniini> get your shit in
2019-03-02 14:56:25 <danieli> good idea!
2019-03-02 14:56:37 <SpaceToast> yup, that's what my "Known Contributor" concept is all about
2019-03-02 14:56:51 <SpaceToast> it's based on what kaniini said about becoming a dev - having someone you work with
2019-03-02 14:57:03 <kaniini> well that is the procedure right now
2019-03-02 14:57:06 <SpaceToast> (and is the first step to being a member (getting push access))
2019-03-02 14:57:14 <danieli> creating a mentor SIG/team/whatever would be nice
2019-03-02 14:57:16 <kaniini> you work with people, those people refer to core
2019-03-02 14:57:25 <kaniini> core either ACKs or NAKs the suggestion to make them a dev
2019-03-02 14:57:25 <AinNero> do you know what i would even like more?
2019-03-02 14:57:42 <AinNero> that the testing is good enough that people can merge with confidence
2019-03-02 14:57:55 <SpaceToast> confidence is not a technical issue
2019-03-02 14:57:56 <danieli> that's another issue, something devs will have to fix together with infra
2019-03-02 14:57:58 <kaniini> sure, but testing does not solve gcompat
2019-03-02 14:58:10 <kaniini> gcompat being merged or not is a matter of fact checking
2019-03-02 14:58:11 <SpaceToast> confidence is a psychological issue
2019-03-02 14:58:14 <danieli> bad testing is more or less just a speedbump
2019-03-02 14:58:22 <AinNero> kaniini: but with testing you could verify that the PR is not breaking anything
2019-03-02 14:58:25 <danieli> the core of the issue is that your patch didn't get merged
2019-03-02 14:58:25 <SpaceToast> "we have CI, therefore everything that passes CI is good to go" is a bad view to have
2019-03-02 14:58:28 <kaniini> AinNero: it wont break either way
2019-03-02 14:58:48 <kaniini> gcompat either works (the loader is at the right place) or it does not
2019-03-02 14:58:52 <AinNero> in general, i just picked that PR randomly
2019-03-02 14:58:52 <danieli> yes, all packages should have a check() and proper CI
2019-03-02 14:59:03 <danieli> it's a good example
2019-03-02 14:59:08 <kaniini> you cant check() a path being installed
2019-03-02 14:59:27 <danieli> right, that's only for the built source, not the actual packaging process
2019-03-02 14:59:35 <kaniini> so check() does not fix gcompat
2019-03-02 14:59:37 <danieli> my bad
2019-03-02 14:59:51 <AinNero> i also mean testing in general
2019-03-02 14:59:55 <kaniini> there is really no 'fix' for gcompat other than having it under the purview of arch maintainers
2019-03-02 15:00:03 <kaniini> which requires SIGs
2019-03-02 15:00:10 <kaniini> because then when you send in a PR
2019-03-02 15:00:12 <AinNero> i dont mean we can go as far as rust, where PR's are automatically merged when it passes the testsuite
2019-03-02 15:00:25 <kaniini> that will never happen
2019-03-02 15:00:45 <AinNero> thats what i think as well
2019-03-02 15:00:46 <kaniini> packages and maintainer-scripts have EUID 0 on machines
2019-03-02 15:00:59 <SpaceToast> so maintainers still need to think about each package
2019-03-02 15:00:59 <kaniini> we are not ever going to just turn things over to a purely CI-driven process sorry
2019-03-02 15:01:19 <SpaceToast> good testing is about weeding out the obviously bad, which reduces context-switching between PRs
2019-03-02 15:01:39 <SpaceToast> good testing is not about giving people the confidence to merge other stuff
2019-03-02 15:01:41 <kaniini> maintainers, but also the developers who sponsor these packages
2019-03-02 15:01:56 <kaniini> if a developer sponsors a package change that is ACKed by the maintainer
2019-03-02 15:01:59 <kaniini> and it introduces a rootkit
2019-03-02 15:02:12 <kaniini> both the developer AND the maintainer are responsible for that mess
2019-03-02 15:02:47 <kaniini> if you sponsor something that roots half the alpine userbase on upgrade
2019-03-02 15:02:48 <AinNero> kaniini: i said 'i dont mean', so if you stop being agitated by that suggestion
2019-03-02 15:02:57 <kaniini> you're definitely going to lose your commit access
2019-03-02 15:03:16 <AinNero> it was meant as showing the general direction - rust solved the PR heap that way
2019-03-02 15:03:25 <kaniini> and alpine isn't rust
2019-03-02 15:03:41 <AinNero> thanks captain obvious
2019-03-02 15:03:56 <kaniini> there is no rust changeset that can root people's machines
2019-03-02 15:04:22 <AinNero> because nobody executes rust applications as root?
2019-03-02 15:04:32 <danieli> ping me whenever this gets less [emotional|aggressive|whatever it is], I'm gonna make dinner
2019-03-02 15:04:36 <kaniini> sure, they do, but
2019-03-02 15:04:47 <kaniini> my point is
2019-03-02 15:04:50 <kaniini> when you run apk upgrade
2019-03-02 15:05:02 <kaniini> there's all sorts of maintainer scripts running as root
2019-03-02 15:05:05 <AinNero> i never said that we should introduce automated merging
2019-03-02 15:05:19 <kaniini> i understand that, but you are thinking about the problem the entirely wrong way
2019-03-02 15:05:19 <AinNero> the maintainer responsibility would be still there as it would be before
2019-03-02 15:05:38 <kaniini> if you introduce technical alternatives to actually reviewing packages
2019-03-02 15:05:52 <kaniini> then it makes it easier for rootkits to slip in
2019-03-02 15:05:57 <AinNero> what do you think stalls most rootkits?
2019-03-02 15:05:58 <kaniini> see also: NPM
2019-03-02 15:06:03 <AinNero> *stalls most PR's ?
2019-03-02 15:06:29 <kaniini> AinNero: bad workflow
2019-03-02 15:06:32 <SpaceToast> ^
2019-03-02 15:06:41 <kaniini> not bad testing, but bad workflow
2019-03-02 15:06:52 <AinNero> because i think, its because the person wanting to merge it does not know whether its a good change or not
2019-03-02 15:06:55 <kaniini> i definitely would stop using alpine if reviews became data-oriented
2019-03-02 15:07:07 <kaniini> 99% of the time it really isn't
2019-03-02 15:07:24 <kaniini> and either way, this is what SIGs would fix
2019-03-02 15:07:31 <kaniini> but i grow tired of discussing this
2019-03-02 15:07:54 <kaniini> please let me know when a SIG proposal actually passes and i will reassign my packages to the appropriate SIGs
2019-03-02 15:08:16 <AinNero> lets conclude that we have different views on what stalls PR's
2019-03-02 15:08:33 <AinNero> i see that your view on that justifies the proposals
2019-03-02 15:08:57 <AinNero> but thinking that the problem is elsewhere, im not convinced of its effectiveness
2019-03-02 15:09:32 <SpaceToast> AinNero: except only one of the views is backed by something, and even if it wasn't the case game theory dictates that, there being no downside (you admitted that yourself) it makes sense to attempt it anyway
2019-03-02 15:10:23 <AinNero> ah, formalizing stuff and making commitees is not free of downsides, lets keep that in mind
2019-03-02 15:10:36 <SpaceToast> I asked you how it would make thing worse multiple time
2019-03-02 15:10:49 <SpaceToast> the specific proposal, not "any committee in general"
2019-03-02 15:11:04 <SpaceToast> you failed to come up with any answers, and at some point agreed it wold not make the situation worse
2019-03-02 15:11:16 <AinNero> you are free to invest your effort there
2019-03-02 15:11:28 <SpaceToast> and as I said, you don't need to care ;)
2019-03-02 15:11:35 <SpaceToast> from your perspective the changes are relatively minimal
2019-03-02 15:13:45 <AinNero> you want to know what i do instead?
2019-03-02 15:14:14 <AinNero> automating building git versions for mkinitfs into a iso, and testing that via automated serial console interaction
2019-03-02 15:14:32 <AinNero> to verify that a PR does not break ZFS/grub workflows and doesn't cause known issues to reappear
2019-03-02 15:15:16 <SpaceToast> 1. that won't work for everything
2019-03-02 15:15:17 <AinNero> so one day, i'll be able to tell ncopa 'you can merge this, i have a system setup running on that git revision with ZFS booting'
2019-03-02 15:15:24 <AinNero> but it will work for mkinitfs
2019-03-02 15:15:27 <SpaceToast> 2. there's more to code quality than "it technically works"
2019-03-02 15:15:45 <SpaceToast> 3. if this proposal was to go through, you could make a mkinitfs team and then would have the authority to do that
2019-03-02 15:16:01 <AinNero> it doesn't replace reviews
2019-03-02 15:16:34 <AinNero> i dont need authority, i need trust, that that is not given out, but earned
2019-03-02 15:16:51 <SpaceToast> you think team membership would be given out arbitrarily? o.O
2019-03-02 15:17:08 <SpaceToast> it's literally push access, it would not be "given out"
2019-03-02 15:17:44 <SpaceToast> and yes, the list of members on the team does indeed imply a certain level of trust (for the same reasons)
2019-03-02 15:28:54 <danieli> let's make this simple
2019-03-02 15:29:06 <danieli> AinNero: relevant to your issues or not, why exactly are you opposed to formalizing SIGs?
2019-03-02 15:29:54 <danieli> it's more or less about clear separation of duties/responsibilities, and the process around it
2019-03-02 15:35:17 <AinNero> danieli: i have a different view on why PR's stall, so it seems like a misdirected effort for me.
2019-03-02 15:35:27 <AinNero> personally im more used to the kernel-style sort of OSS development
2019-03-02 15:35:30 <danieli> it's not just about PRs, our point is that it will/should help
2019-03-02 15:35:48 <AinNero> i hoped i made it clear that i understand your reasoning
2019-03-02 15:36:01 <SpaceToast> "misdirected effort" is not a reason to be opposed
2019-03-02 15:36:13 <danieli> the effort isn't directed directly at PRs either way
2019-03-02 15:36:16 <SpaceToast> quite a bit of effort is going into this discussion, likely more than would otherwise
2019-03-02 15:36:28 <SpaceToast> indeed, PRs are just one of the things that will benefit
2019-03-02 15:36:52 <AinNero> i dont think it will work out, but feel free to prove me wrong
2019-03-02 15:37:11 <danieli> but *why*? bring constructive criticism, not just complaints :)
2019-03-02 15:37:13 <SpaceToast> again, why are you *opposed*; "feel free to prove me wrong" suggests you aren't opposed
2019-03-02 15:37:20 <SpaceToast> in which case, why are we having this discussion?
2019-03-02 15:40:11 <AinNero> danieli: i bought up the 'testing to improve non-break confidence' alternative
2019-03-02 15:40:25 <AinNero> which im currently attempting with mkinitfs
2019-03-02 15:40:41 <danieli> but this isn't about PRs, it's just an indirect beneficiary
2019-03-02 15:41:41 <AinNero> im doing this for the exact purpose of being able to tell if a PR will break known usecases
2019-03-02 15:42:04 <SpaceToast> how is that a cause for opposition to something unrelated?
2019-03-02 15:42:08 <danieli> but how does that even relate to being opposed to formalizing SIGs?
2019-03-02 15:42:14 <SpaceToast> (i.e how does this answer the question you were asked)
2019-03-02 15:43:20 <AinNero> why im not neutral?
2019-03-02 15:43:38 <SpaceToast> no, the list of concise reasons as to why you are opposed to the proposal
2019-03-02 15:43:54 <SpaceToast> not unrelated ramblings about how you manage your PRs, not nebulous "I don't think it will work out"
2019-03-02 15:44:06 <SpaceToast> your statement of "feel free to prove me wrong" suggests that you are, in fact, NOT opposed to the proposal
2019-03-02 15:44:16 <danieli> I just don't understand how it relates to what we're proposing - formalizing SIGs
2019-03-02 15:44:18 <danieli> nothing more, nothing less
2019-03-02 15:44:36 <danieli> it doesn't even relate to PRs, it relates to the organizational structure in the Alpine project
2019-03-02 15:44:58 <AinNero> SpaceToast: i alread told you i think its wasted effort
2019-03-02 15:45:11 <AinNero> but i dont exclude the possibility that it will work out, because sometimes im just wrong
2019-03-02 15:45:12 <SpaceToast> less effort than this conversation
2019-03-02 15:45:17 <danieli> this is a pointless discussion, let's end it here
2019-03-02 15:45:20 <SpaceToast> and yet...
2019-03-02 15:45:26 <SpaceToast> I agree, it's going nowhere
2019-03-02 15:45:27 <danieli> if either party wants to continue it, #alpine-offtopic please
2019-03-02 15:45:40 <danieli> we've already littered this channel a bit more than I'd like
2019-03-02 15:45:57 <danieli> at least we didn't disrupt ongoing conversaions
2019-03-02 15:46:10 <danieli> s/sai/sati/
2019-03-02 15:46:11 <alpine-meetbot> danieli meant to say: at least we didn't disrupt ongoing conversations
2019-03-02 17:42:58 <mps> anyone can tell me what is default/preferred dbus policy for network device management in Alpine. netdev group probably but want to be sure before posting patch for iwd
2019-03-02 17:54:42 <otlabs> hi!
2019-03-02 17:56:24 <otlabs> I would like to make a package for zimwriterfs (a tool for creating ZIM files based on contents on a local filesystem, https://github.com/openzim/zimwriterfs), but I get `catching polymorphic type` error while compiling
2019-03-02 17:58:48 <otlabs> I have opened the issue at github, https://github.com/openzim/zimwriterfs/issues/88
2019-03-02 17:59:19 <otlabs> I get same error under Arch Linux with gcc 8.2.1
2019-03-02 18:00:14 <otlabs> Same time I got the comment that under Ubuntu 18.04 the code compiles fine
2019-03-02 18:00:52 <otlabs> Any ideas what should I check to make this package compile for Alpine?
2019-03-02 18:03:20 <SpaceToast> if it fails on Arch, it likely isn't an alpine-specific problem
2019-03-02 18:03:37 <SpaceToast> the main thing differentiating us is the use of the musl libc, but arch uses the more common glibc
2019-03-02 18:03:44 <SpaceToast> so it sounds like an issue with the project
2019-03-02 18:04:08 <SpaceToast> perhaps gcc broke it, or perhaps some library version is too new
2019-03-02 18:04:59 <otlabs> Ohh, I see
2019-03-02 18:25:36 <otlabs> Looks like the error is fixed in master brunch now and code compiles fine. Would ask maintainers to make a release including a fix. Thanks for your comments @SpaceToast!
2019-03-02 18:25:50 <SpaceToast> no worries :)
2019-03-02 18:32:21 <otlabs> bye ppl
2019-03-02 23:06:31 <clandmeter> master brunch sounds delicious
2019-03-02 23:27:37 <clandmeter> jwh: https://git.alpinelinux.org/aports/commit/?id=e695fd5a  that should do for now
2019-03-02 23:27:57 <jwh> heh, yeah thats what I was thinking
2019-03-02 23:28:04 <jwh> what did the drone guys say?
2019-03-02 23:28:40 <clandmeter> they cannot do much i think
2019-03-02 23:28:46 <jwh> ah
2019-03-02 23:28:47 <clandmeter> not for now
2019-03-02 23:28:51 <jwh> fair enough
2019-03-02 23:29:08 <clandmeter> they coud, but then they need to depend on linux32
2019-03-02 23:29:17 <clandmeter> i mean each image has to
2019-03-02 23:30:03 <clandmeter> they could modify the entrypoint to prepend linux32, but the entrypoint is executed in the container.
2019-03-02 23:30:13 <jwh> hm
2019-03-02 23:30:24 <jwh> bleh docker etc :P
2019-03-02 23:31:27 <clandmeter> its should be trivial to fix in docker, but its a feature not a bug so i think i will take some time (if it ever happens)
2019-03-02 23:31:35 <jwh> yeah
2019-03-02 23:33:36 <clandmeter> im glad you catched it early and persisted it was really broken. but next time ill prove you wrong ;-)
2019-03-02 23:33:42 <jwh> lol
2019-03-02 23:33:46 <jwh> never!
2019-03-02 23:34:47 <clandmeter> my girlfriend said never, and now she is my wife ;-)
2019-03-02 23:36:26 <jwh> lol
2019-03-03 02:26:11 <jwh> wow
2019-03-03 02:26:19 <jwh> I've just realised how utterly retarded lxd is
2019-03-03 02:26:36 <SpaceToast> what happened this time?
2019-03-03 02:26:43 <jwh> the build...
2019-03-03 02:26:54 <jwh> why bother using the release archive at all
2019-03-03 02:27:06 <SpaceToast> oh, that's go packages in general
2019-03-03 02:27:09 <jwh> since go get downloads a copy of it ayway
2019-03-03 02:27:12 <jwh> anyway*
2019-03-03 02:27:16 <SpaceToast> release archives are used because... policy
2019-03-03 02:27:28 <SpaceToast> it actually breaks hugo, since hugo expects to have its test be ran in a git repo
2019-03-03 02:27:33 <jwh> lol
2019-03-03 02:27:35 <jwh> it's amazing
2019-03-03 02:27:41 <jwh> pike has a lot to answer for
2019-03-03 02:27:44 <SpaceToast> and of course all of the Go module stuff is borked with abuild
2019-03-03 02:27:55 <SpaceToast> I'm not the biggest fan of golang, to be honest
2019-03-03 02:28:03 <SpaceToast> I tolerate it for specific packages I like
2019-03-03 02:28:04 <jwh> theres a special place in hell reserved for him
2019-03-03 02:28:11 <SpaceToast> (lxd, devd, hugo, mostly)
2019-03-03 02:28:25 <SpaceToast> rust is somewhat similar but release archives, you know, actually work in rust :)
2019-03-03 02:28:26 <jwh> I have no opinion on the language itself
2019-03-03 02:28:38 <jwh> but the build/packaging/whatever system is absolutely hopeless
2019-03-03 02:28:38 <SpaceToast> I mean both the language and the ecosystem in my statement
2019-03-03 02:28:50 <jwh> I'm sure the language is great
2019-03-03 02:28:56 <jwh> but it's totally let down by this ridiculous dance
2019-03-03 02:29:03 <SpaceToast> imo the language is very much not-great
2019-03-03 02:29:09 <SpaceToast> but we can diss on golang in -offtopic ;)
2019-03-03 02:29:14 <jwh> lol
2019-03-03 02:29:17 <SpaceToast> there's really not much we (alpine) can do about the thing :/
2019-03-03 02:29:42 <jwh> I mean, may as well stop using release archives entirely and just add helpers for go
2019-03-03 02:30:02 <jwh> at least sensible projects bundle their entire project
2019-03-03 02:30:10 <jwh> including deps
2019-03-03 02:30:19 <SpaceToast> I actually submitted a patch that would allow using the go module stuff
2019-03-03 02:30:27 <SpaceToast> or, rather, cleaning the go module stuff without horrifying failures
2019-03-03 02:30:39 <SpaceToast> the issue is that alpine has releases
2019-03-03 02:30:48 <SpaceToast> and if alpine has releases, all its software must have releases as well
2019-03-03 02:31:01 <SpaceToast> personally, I only REALLY care about edge and maybe latest-release a tad bit
2019-03-03 02:31:02 <jwh> yup
2019-03-03 02:31:13 <SpaceToast> so I wouldn't mind allowing git sources (maybe with a 'checkout' target)
2019-03-03 02:31:18 <jwh> but the software that's packaged doesn't have releases
2019-03-03 02:31:28 <jwh> since the version you actually get will depend when its built in a lot of cases
2019-03-03 02:31:29 <SpaceToast> well it does ... sort of
2019-03-03 02:31:45 <SpaceToast> go get (and other such systems) have a sort of "soft" lock
2019-03-03 02:31:50 <jwh> yeah, but it's bad
2019-03-03 02:31:52 <jwh> really bad
2019-03-03 02:31:56 <SpaceToast> e.g you can say "I depend on an abi-compatible version of X"
2019-03-03 02:32:03 <SpaceToast> it just works worse in golang than elsewhere
2019-03-03 02:32:57 <jwh> heh
2019-03-03 02:33:09 <jwh> modules will certainly help, but the entire design is still stupid
2019-03-03 02:34:05 <otlabs> hi!
2019-03-03 02:34:15 <SpaceToast> welcome back otlabs
2019-03-03 02:35:13 <otlabs> Greetings SpaceToast
2019-03-03 02:36:10 <otlabs> I got 2 pull requests marked as stale at GitHub. I would quite appreciate if someone can take a look on them as I would like to add new aport for go-ipfs, an InterPlanetary File System, https://ipfs.io/.
2019-03-03 02:36:29 <SpaceToast> unfortunately, your situation is... not unique
2019-03-03 02:36:37 <SpaceToast> alpine currently has quite a few organizational issues
2019-03-03 02:36:57 <SpaceToast> there's currently a proposal floating around that should improve the situation, but until that's in, your best bet is coming in here during daylight CST hours
2019-03-03 02:36:58 <otlabs> Oh, I see
2019-03-03 02:37:16 <SpaceToast> and poking one of the people with +o that you see active
2019-03-03 02:37:16 <jwh> pick me pick me!
2019-03-03 02:37:38 <SpaceToast> speaking of, jwh, what do you think of the proposal? :)
2019-03-03 02:37:44 <jwh> I haven't actually seen it
2019-03-03 02:37:46 <jwh> url?
2019-03-03 02:38:12 <otlabs> SpaceToast: should I leave a commet in my PR to remove stale state?
2019-03-03 02:38:14 <otlabs> https://github.com/alpinelinux/aports/pull/5772
2019-03-03 02:38:20 <otlabs> https://github.com/alpinelinux/aports/pull/5773
2019-03-03 02:38:28 <danieli> jwh: it's in the alpine-devel mailing list, fairly far up
2019-03-03 02:38:31 <jwh> oh
2019-03-03 02:38:35 <danieli> in response to the uh
2019-03-03 02:38:40 <SpaceToast> otlabs: I don't know if we have a policy on that
2019-03-03 02:38:43 <danieli> "Fwd: Improving cross-distribution security" thread
2019-03-03 02:38:49 <SpaceToast> but really, just show up in daylight CST hours and poke
2019-03-03 02:38:49 <otlabs> https://github.com/alpinelinux/aports/pull/5812
2019-03-03 02:39:03 <SpaceToast> hey danieli, innit a bit early/late for you? ;)
2019-03-03 02:39:08 <danieli> 3.39 am
2019-03-03 02:39:13 <danieli> so yes, late
2019-03-03 02:39:16 <SpaceToast> so yes, yes it is :)
2019-03-03 02:39:20 <jwh> mmhmm
2019-03-03 02:39:23 <jwh> tis late
2019-03-03 02:39:25 <SpaceToast> jwh: https://p.toastin.space/F7MDfw?asciidoc
2019-03-03 02:39:30 <jwh> (same timezone here)
2019-03-03 02:39:31 <danieli> i accidentally fell down a rabbit hole.. or three.
2019-03-03 02:39:38 <otlabs> SpaceToast: I will, thank you!
2019-03-03 02:39:56 <SpaceToast> it's a rough draft that would be further discussed (mostly the specifics and wording)
2019-03-03 02:40:42 <jwh> looks good
2019-03-03 02:40:51 <jwh> certainly needed
2019-03-03 02:41:03 <SpaceToast> nice, ty :)
2019-03-03 03:01:10 <otlabs> see you ppl, bye
2019-03-03 08:11:28 <clandmeter> Good morning
2019-03-03 08:12:01 <mps> \o
2019-03-03 08:12:24 <clandmeter> I modified the stale logic on pr's
2019-03-03 08:12:37 <clandmeter> So a lot are marked as stale
2019-03-03 08:14:12 <clandmeter> Could be some users will visit irc asking for support on their pr because of the stale message.
2019-03-03 08:14:45 <clandmeter> Don't kill me for it :)
2019-03-03 08:14:56 <danieli> i mean, it probably wouldn't be wrong
2019-03-03 08:15:11 <clandmeter> To kill me?
2019-03-03 08:15:43 <danieli> that they're stale PRs
2019-03-03 08:16:34 <clandmeter> Ok :)
2019-03-03 08:42:43 <andypost[m]> At least all php73 prs waiting other day still
2019-03-03 08:45:58 <clandmeter> andypost[m]: ?
2019-03-03 08:49:30 <andypost[m]> I mean https://github.com/alpinelinux/aports/pull/5863 and all related @clandmeter
2019-03-03 08:51:34 <clandmeter> you can also add the wip label to exclude the stale tagging
2019-03-03 08:52:28 <andypost[m]> Oh, yep! GH announced drafts dome time ago
2019-03-03 08:53:08 <clandmeter> but i see you commented last month, so its not stale.
2019-03-03 08:53:26 <clandmeter> i wonder if the references also count as comments
2019-03-03 08:56:32 <andypost[m]> I bet only comments
2019-03-03 13:44:22 <_ikke_> clandmeter: redo in the mean time has fixed the tty issue (someone else reported it as well). What we still need to fix is that we need to do chmod +w after the tests has run. Do we have a proper way of doing that?
2019-03-03 13:45:23 <_ikke_> Would overriding clean() help?
2019-03-03 13:53:44 <_ikke_> clandmeter: something like this: http://tpaste.us/jXpK
2019-03-03 13:58:41 <clandmeter> there is no default_clean?
2019-03-03 13:59:26 <clandmeter> i think i talked to ncopa to add an abuild option to set perms
2019-03-03 13:59:33 <_ikke_> no
2019-03-03 14:09:26 <_ikke_> clandmeter: Do you think there is problem pushing something like that for now?
2019-03-03 14:09:43 <clandmeter> if it works it good for me
2019-03-03 14:13:32 <_ikke_> Apparently it calls cleanup srcdir during abuild -r, so clean() is not being used
2019-03-03 14:15:05 <_ikke_> so no, it does not work
2019-03-03 14:15:36 <clandmeter> you could write a patch for abuild
2019-03-03 14:16:42 <_ikke_> Right, what would you suggest it would do?
2019-03-03 14:17:02 <_ikke_> chown + chmod before clean?
2019-03-03 14:17:05 <clandmeter> adjust the permissions liek you do now
2019-03-03 14:17:42 <clandmeter> and call it via options="chmodclean or whatever"
2019-03-03 14:17:54 <clandmeter> i think ncopa had a better name :)
2019-03-03 14:18:12 <clandmeter> but the name we can discus
2019-03-03 14:18:25 <_ikke_> Is there a reason it should be an option? Would it hurt to do it always?
2019-03-03 14:19:08 <clandmeter> it only happens occasionally, so i think its not always needed.
2019-03-03 14:19:11 <_ikke_> ok
2019-03-03 14:19:21 <clandmeter> its up for debate
2019-03-03 14:19:48 <clandmeter> i know ncopa likes micro optimizations
2019-03-03 14:21:03 <_ikke_> right
2019-03-03 14:31:44 <_ikke_> ahttp://tpaste.us/DL0o
2019-03-03 14:34:57 <_ikke_> (cleaned up): http://tpaste.us/Bo0y
2019-03-03 16:08:33 <SpaceToast> clandmeter: there is no default_clean, I sent a patch to -devel to add one (and clean up code duplication in a different clean()) but it went nowhere
2019-03-03 17:27:03 <kpcyrd> hello, my PR was marked as stale, can somebody have a look? https://github.com/alpinelinux/aports/pull/4054
2019-03-03 17:27:54 <SpaceToast> kpcyrd: this is due to a configuration change clandmeter made, don't worry about it too much
2019-03-03 17:28:11 <SpaceToast> (a LOT of PRs are very overdue; there's a proposal floating around atm that would help the situation somewhat)
2019-03-03 17:28:22 <SpaceToast> in the meantime, do feel free to poke people with push access in here :)
2019-03-03 17:28:33 <SpaceToast> 
ACTION coughs in clandmeter's general direction

2019-03-03 17:29:50 <CobHead> SpaceToast, anywhere we could view this proposal?
2019-03-03 17:30:11 <SpaceToast> it's on the alpine-devel mailing list
2019-03-03 17:30:13 <SpaceToast> from me :)
2019-03-03 17:30:25 <danieli> why are you mentioning the SIG/team thing to every single person, no matter what they ask about?
2019-03-03 17:30:33 <danieli> it just seems so unnecessary/unrelated
2019-03-03 17:30:39 <SpaceToast> danieli: I'm mentioning it to people complaining about their PRs being stale
2019-03-03 17:30:45 <SpaceToast> because that'll be affected
2019-03-03 17:31:06 <SpaceToast> or their patch not being seen, for the same reason
2019-03-03 17:31:08 <PureTryOut[m]> "team thing", team maintainership of packages by any chance?
2019-03-03 17:31:13 <danieli> that too
2019-03-03 17:31:16 <danieli> bingo
2019-03-03 17:31:18 <SpaceToast> that'll be the one
2019-03-03 17:31:39 <SpaceToast> I'm not mentioning it to people asking how to use apk-info/search (see: user ML), for example, since that *won't* be affected
2019-03-03 17:32:01 <PureTryOut[m]> Awesome, can't wait for that one. Finally I can upstream KDE stuff 😄
2019-03-03 17:32:25 <SpaceToast> PureTryOut[m]: yup, I made plasma an explicit example because I recall you lamenting the situation :)
2019-03-03 17:33:47 <PureTryOut[m]> Also, having more people maintain GNOME would be awesome. Right now it's still stuck in a half 3.26, half 3.28, limbo state
2019-03-03 17:33:59 <SpaceToast> gnome is complicated, to my understanding
2019-03-03 17:34:06 <SpaceToast> since it hard-depends on systemd (which is kinda hard to rip out)
2019-03-03 17:34:12 <SpaceToast> and the code being such tends to change
2019-03-03 17:37:24 <PureTryOut[m]> yeah but some packages can be upgraded as-is without much trouble, and are still stuck on an older version. it prevents them from being installed currently
2019-03-03 17:37:31 <PureTryOut[m]> either upgrade the entire thing, or none of it.
2019-03-03 18:05:08 <clandmeter> kpcyrd: done
2019-03-03 18:19:26 <Mis012[m]> SpaceToast: I would love if someone managed to rid GNOME of systemd plague
2019-03-03 18:19:48 <SpaceToast> have fun convincing redhat to not use their product A in their product B :)
2019-03-03 18:21:38 <clandmeter> i think KDE has good chance getting into alpine if we have some ppl who want to maintain it.
2019-03-03 18:23:40 <Mis012[m]> just say "we love your product B and want to package it, but unfortunately your product A, althought we love it as well, doesn't fit into our plans at all. Would you mind if someone helped you to make them usable separately, so more people can enjoy their awesomeness"
2019-03-03 19:15:38 <kpcyrd> clandmeter: thanks!
2019-03-03 19:22:45 <PureTryOut[m]> clandmeter: well I definitely am ready to maintain KDE. I think some people from Adélie are as well, as they are the ones that wanted to wait for team maintainership
2019-03-03 19:22:52 <PureTryOut[m]> I currently maintain the KDE stack for postmarketOS already
2019-03-03 20:24:58 <mps> to repeat yesterday question: anyone can tell me what is default/preferred dbus policy for network device management in Alpine. netdev group probably but want to be sure before posting patch for iwd
2019-03-04 01:55:45 <LucasRamage[m]> Greetings once again, this is not my patch, personally, but it does affect software that I am working on make it into Alpine, and I would like to see it pushed if possible, thanks! https://patchwork.alpinelinux.org/patch/4490
2019-03-04 07:45:03 <rnalrd> LucasRamage[m] pushed
2019-03-04 07:45:11 <rnalrd> tnx for pinging
2019-03-04 09:09:14 <ncopa> morning
2019-03-04 09:17:21 <clandmeter> ncopa: what is the policy regarding static libs? ship with dev or static subpkg?
2019-03-04 09:38:01 <ncopa> i prefer to ship with -static subpackage
2019-03-04 09:38:08 <ncopa> because its normally not wanted
2019-03-04 09:38:32 <ncopa> and it may unintentionally result in static link when dynamic is preferred
2019-03-04 09:38:43 <ncopa> and static libs can be very big
2019-03-04 09:38:55 <danieli> +1
2019-03-04 09:39:03 <ncopa> for example for llvm and chromium
2019-03-04 09:39:28 <ncopa> clandmeter: we should document that some place
2019-03-04 09:39:44 <ncopa> do we have a place to doc packaging policies?
2019-03-04 09:39:59 <SpaceToast> not yet, but soon:tm:
2019-03-04 09:40:09 <clandmeter> am asking for: http://dup.pw/aports/cf27e69e
2019-03-04 09:41:16 <SpaceToast> (don't mind me, just waking up in the middle of the night) - perhaps we should also have a default_static or similar function? (static libraries are often desired, and making following the -static policy easier seems like a win)
2019-03-04 09:47:21 <mps> SpaceToast: yesterday, reading your discussion about team I wanted to propose packaging policy first but managed to control self and not 'fall' in yours chat :)
2019-03-04 09:48:15 <mps> but yes, packaging guide (or maybe policy) would be good to have
2019-03-04 09:48:21 <SpaceToast> mps: that's kind of why I was going to wait until I got to the developer handbook to propose it
2019-03-04 09:48:36 <SpaceToast> but it was happening with or without me (as danieli opened up the conversation)
2019-03-04 09:49:19 <danieli> there's some kind of packaging guide on the wiki but it's outdated and fragmented
2019-03-04 09:49:22 <SpaceToast> one advantage of doing management first is that then there'd be a specific resource for packaging policy (the general aports team)
2019-03-04 09:49:25 <danieli> and lacking in important areas
2019-03-04 09:49:44 <SpaceToast> also, re: static libs being big; looking at my system it seems to rather depend on the specific case
2019-03-04 09:49:58 <SpaceToast> (e.g libstdc++.a is 4.8M vs 14M for the .so)
2019-03-04 09:53:43 <mps> and if team never be created we will not have 'policy/guide' about packaging
2019-03-04 09:58:12 <SpaceToast> sure we will, it'll just be a bit harder to collect/determine
2019-03-04 10:00:36 <mps> ncopa: when we talk about policy, last night I posted message here about netdev
2019-03-04 10:00:44 <mps> to repeat yesterday question: anyone can tell me what is default/preferred dbus policy for network device management in Alpine. netdev group probably but want to be sure before posting patch for iwd
2019-03-04 10:02:13 <mps> sorry being annoying about that
2019-03-04 10:16:59 <_ikke_> Linux 5.0 has been released
2019-03-04 10:24:14 <danieli> wow
2019-03-04 10:24:21 <danieli> it has
2019-03-04 10:24:35 <danieli> yesterday even - i didn't notice
2019-03-04 11:23:03 <ncopa> mps: i would guess netdev group yes
2019-03-04 11:36:47 <mps> ncopa: I agree, will make a patch for that. actually I tested it locally already and it works with netdev dbus policy
2019-03-04 11:38:02 <mps> another questions, did you decided what should be done with ell library, i.e. main/libell and testing/ell
2019-03-04 12:04:16 <ncopa> mps: i think we should ask current maintainer of libell
2019-03-04 12:05:39 <mps> that's what I thought, but think that someone from core dev should do that, not I (a random person)
2019-03-04 12:06:12 <SpaceToast> if all suggestions / communication goes through the core devs, that sounds like a serious bottleneck to me :)
2019-03-04 12:07:37 <mps> only have one wish, to be renamed to ell, it looks like it more according Alpine naming scheme/practice
2019-03-04 12:08:52 <mps> SpaceToast: yes, but we don't know how random person will react to 'unsolicited' email
2019-03-04 12:09:06 <clandmeter> its not
2019-03-04 12:09:18 <SpaceToast> mps: when you maintain a publicly available package, you expect people to contact you in case they need help with it, no?
2019-03-04 12:09:19 <clandmeter> if this person is a maintainer he can expect something
2019-03-04 12:09:24 <mps> maybe I can create issue on bugs.a.o
2019-03-04 12:10:20 <clandmeter> SpaceToast: im not sure a maintainer should give enduser support.
2019-03-04 12:10:32 <mps> I expect and have no problem if anyone contact me, but there are diferrent 'characters' around
2019-03-04 12:10:45 <clandmeter> but communication between devs should not be an issue.
2019-03-04 12:11:06 <SpaceToast> well, enduser bug reports, more like
2019-03-04 12:11:30 <clandmeter> its probably something we should mention in the docs what it means to be a maintainer.
2019-03-04 12:11:57 <mps> clandmeter: agree fully
2019-03-04 12:13:55 <SpaceToast> aye, still gotta finish editing the user docs though
2019-03-04 12:13:57 <mps> to conclude and not bother you all too much, I will fill issue and assign it to the current maintainer. hope this will be enough for now
2019-03-04 12:14:05 <SpaceToast> and get the UI so we can publish'em
2019-03-04 12:14:25 <clandmeter> mps: or create a PR on github with the change and let it be reviewed :)
2019-03-04 12:15:17 <mps> hehe, you are kidding with me, because you know I dislike github and don't have account there
2019-03-04 12:17:17 <clandmeter> hence the smiley
2019-03-04 12:18:02 <SpaceToast> something something join infra team and push for alpine gitlab instance ;)
2019-03-04 12:18:25 <clandmeter> with cream on top please!
2019-03-04 12:19:17 <mps> to be fair, I can create account there if it will be of use for Alpine, but have a hope that one who promised to make gitlab for Alpine will do that soon
2019-03-04 12:20:09 <mps> simply, don't want to waste a time to learn github workflow if Alpine will switch to gitlab
2019-03-04 12:20:29 <SpaceToast> gitlab workflow is mostly the same as the github one
2019-03-04 12:21:04 <mps> I don't have strong ideological points, even once argued personally (in real life) with RMS about that ;)
2019-03-04 12:23:12 <mps> SpaceToast: 'interface' on github somewhat strange to me
2019-03-04 12:31:23 <ncopa> i think mort___ may be working on gitlab instance based on alpine
2019-03-04 12:31:37 <ncopa> im also looking forward to switch to gitlab
2019-03-04 12:31:54 <jwh> hosted gitlab?
2019-03-04 12:32:08 <jwh> their public one is kinda annoying as they will often just junk ssh connections
2019-03-04 12:32:15 <jwh> seems to be some sort of scaling problem
2019-03-04 12:32:15 <_ikke_> jwh: self-hosted indeed
2019-03-04 12:35:49 <jwh> good call
2019-03-04 14:26:52 <ncopa> the 3.9.1 release is completely broken
2019-03-04 14:27:09 <_ikke_> :(
2019-03-04 14:27:40 <ncopa> it is the module signing verification that depends on openssl
2019-03-04 14:27:52 <ncopa> but apparently we dont ship openssl with the standard image
2019-03-04 14:28:03 <clandmeter> thats the bug that was just reported
2019-03-04 14:28:12 <clandmeter> i thought it sounded scary
2019-03-04 14:28:13 <ncopa> yup
2019-03-04 14:28:20 <ncopa> its #10042
2019-03-04 14:28:56 <clandmeter> so we need to spin .2 with openssl?
2019-03-04 14:29:24 <ncopa> yeah
2019-03-04 14:29:41 <clandmeter> hmm
2019-03-04 14:30:19 <clandmeter> so apk can only verify apk files
2019-03-04 14:31:38 <ncopa> i didnt even test is setup-alpine worked
2019-03-04 14:31:42 <ncopa> which is a bad thing
2019-03-04 14:32:14 <clandmeter> we should do some testing, preferable automated
2019-03-04 14:32:43 <ncopa> should maybe be as a part of the release checklist
2019-03-04 14:32:47 <clandmeter> i think AinNero was working on something
2019-03-04 14:33:12 <AinNero> oh, i did
2019-03-04 14:33:30 <AinNero> like, it takes a iso as input and then talks qemu via serial to install and reboot and stuff
2019-03-04 14:33:47 <AinNero> https://github.com/nero/alpine-expect
2019-03-04 14:34:16 <AinNero> i did intend to use it both for testing release canidates (especially for ZFS) and testing new mkinitfs revisions
2019-03-04 14:34:28 <AinNero> consider it an PoC
2019-03-04 14:36:29 <AinNero> i'd be glad about some input how people would expect to use it
2019-03-04 14:37:57 <clandmeter> i wonder if we can run qemu in drone
2019-03-04 14:38:35 <SpaceToast> I think ddevault's CI system used qemu?
2019-03-04 14:38:52 <clandmeter> i think docker and drone iirc
2019-03-04 14:39:04 <ddevault> qemu in docker, yes
2019-03-04 14:39:13 <ddevault> docker has been more of a pain than a help, though
2019-03-04 14:39:59 <ddevault> how do you like drone? I looked into it a long time ago and thought the open source hostable version was crap compared to the proprietary hosted version
2019-03-04 14:42:09 <clandmeter> its also using docker
2019-03-04 14:42:34 <clandmeter> ddevault: you need to do some magic for qemu in docker?
2019-03-04 14:42:50 <ddevault> just pass /dev/kvm in
2019-03-04 14:43:01 <clandmeter> hmm
2019-03-04 14:43:17 <clandmeter> i wonder if i have access to kvm on cloud.drone.io
2019-03-04 14:43:28 <ddevault> you do on builds.sr.ht :)
2019-03-04 14:44:03 <clandmeter> ddevault: drone long time ago? their cloud platform is prett ynew?
2019-03-04 14:44:16 <ddevault> it was at least 3-4 years ago
2019-03-04 14:44:24 <ddevault> it's not that new
2019-03-04 14:45:28 <clandmeter> its probably not the same
2019-03-04 14:45:43 <clandmeter> the one that is sponsored by packet is new(er)
2019-03-04 14:45:48 <ddevault> gotcha
2019-03-04 14:46:04 <clandmeter> ddevault: nice thing is they support arm32/64
2019-03-04 14:46:24 <ddevault> native or emulated?
2019-03-04 14:46:30 <clandmeter> native
2019-03-04 14:46:32 <ddevault> neat
2019-03-04 14:46:36 <ddevault> wish I had that kind of dough
2019-03-04 14:46:44 <ddevault> I'll have emulated stuff soon
2019-03-04 14:46:50 <clandmeter> talk to packet :)
2019-03-04 14:47:02 <ddevault> lol
2019-03-04 14:47:19 <ddevault> see travis CI for a case study in taking money from others to build your CI service
2019-03-04 14:47:28 <ddevault> drone will go the same way, probably sooner
2019-03-04 14:48:58 <clandmeter> why do you run qemu in docker?
2019-03-04 14:49:24 <ddevault> easy way to set up a chroot et al, and easy way to compile qemu
2019-03-04 14:49:29 <ddevault> I have plans on getting rid of it
2019-03-04 14:49:51 <ddevault> running untrusted guests means that if there's a KVM vulnerability I want a few more layers of security between you and anything important
2019-03-04 14:50:05 <ddevault> and qemu has had its fair share of userspace vulns too
2019-03-04 14:50:25 <ncopa> do you mount and dir from qemu host to gemu guest?
2019-03-04 14:50:54 <ddevault> I mount the qcow2 (read-only) from outside docker to inside docker
2019-03-04 14:50:58 <ddevault> I don't do any filesystem-level sharing
2019-03-04 14:51:16 <ncopa> ok
2019-03-04 14:53:35 <clandmeter> i guess for iso testing we dont necessarily need kvm support
2019-03-04 14:54:02 <ddevault> qemu does have software emulation of x86_64
2019-03-04 14:54:10 <skarnet> ncopa: quick abuild question: is there a way to say that foo-dev, a subpackage, does not depend on foo at all?
2019-03-04 14:54:16 <AinNero> clandmeter: agree
2019-03-04 14:54:23 <ddevault> it's not awful, about 25% speed
2019-03-04 14:55:13 <AinNero> the expect script is currently bad with handling timeouts, it needs some work to be reliable in a return 0/return 1 fashion
2019-03-04 14:58:10 <mps> skarnet: maybe prepend !, i.e. !foo
2019-03-04 14:58:35 <skarnet> mps: that will make them conflict, won't it? that's not what I want
2019-03-04 15:00:38 <mps> ah, so. didn't tried but maybe add depends in subpackage without foo in it
2019-03-04 15:01:35 <ncopa> skarnet:
2019-03-04 15:01:42 <ncopa> dev() {
2019-03-04 15:01:47 <ncopa>   depends=
2019-03-04 15:01:49 <ncopa>   ...
2019-03-04 15:01:50 <ncopa> }
2019-03-04 15:02:56 <clandmeter> or add depends= after default_dev
2019-03-04 15:03:06 <skarnet> but by default (in default_dev), depends equals $depends_dev, which is... empty
2019-03-04 15:03:08 <skarnet> in my case
2019-03-04 15:03:47 <ncopa> the default_dev function will mote .so symlinks to -dev subpackage
2019-03-04 15:03:57 <skarnet> indeed
2019-03-04 15:04:04 <skarnet> the symlink is the issue. Thanks.
2019-03-04 15:04:07 <ncopa> and it will pull in the symlink target as depends
2019-03-04 15:58:57 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.9.2-released.html
2019-03-04 15:59:49 <fcolista> +1
2019-03-04 16:08:52 <AinNero> ncopa: regression introduced in 3.9.1, not 3.9.2 i think
2019-03-04 16:36:57 <ncopa> AinNero: ofc. thanks
2019-03-04 16:37:45 <ncopa> like this: https://wwwtest.alpinelinux.org/posts/Alpine-3.9.2-released.html
2019-03-04 16:38:57 <SpaceToast> lgtm
2019-03-04 16:41:34 <ncopa> pushed to production. thanks!
2019-03-04 19:24:29 <fassl> hello, i would like to submit a patch for selinux, but before i clean up, i would have some questions which could help me in doing so, may i ask here?
2019-03-04 19:25:11 <_ikke_> fassl: sure, just be patient
2019-03-04 19:25:19 <fassl> ok thanks
2019-03-04 19:25:49 <fassl> first of all i don't know on which tree i should be working, testing? community?
2019-03-04 19:26:19 <mps> fassl: testing is for new things
2019-03-04 19:26:22 <fassl> as i had to patch the kernel config i am not sure if it should be a separate kernel or a patch to linux-vanilla
2019-03-04 19:26:28 <fassl> ok so it would be testing then?
2019-03-04 19:26:55 <mps> you can post patch for kernel
2019-03-04 19:27:38 <fassl> ok, and python binding packages start with py- right?
2019-03-04 19:28:37 <mps> btw, as someone who backported selinux about ten (maybe more) years ago for debian, I dislike selinux but that is just my opinion
2019-03-04 19:29:01 <SpaceToast> mps: what's your preference?
2019-03-04 19:29:04 <SpaceToast> mine's AA
2019-03-04 19:30:08 <mps> AA looks better, I agree, but I stopped to use all these security 'frameworks' and keep systems updated and small
2019-03-04 19:31:33 <SpaceToast> well keeping your system small doesn't make the things in it any safer :)
2019-03-04 19:31:34 <fassl> i read that it has more fine grained control than AA and that it therefore should be more secure. but it can be hard to get it right and potentially you even could introduce security risks with it
2019-03-04 19:32:01 <SpaceToast> fassl: the real issue with selinux, imo, is it's very hard for a human to verify/vet the configuration
2019-03-04 19:32:02 <mps> grsec/pax was promising and simplest but we lost it
2019-03-04 19:32:18 <SpaceToast> pax is linux w^x and w^x is generally a good idea, yeah
2019-03-04 19:33:52 <mps> anyway, I'm against complex frameworks because complexity is enemy of security and (not less important) stability
2019-03-04 19:35:47 <fassl> SpaceToast, yeah probably, didn't play with it too much, just tried if it is working with some runcon command
2019-03-04 19:36:57 <SpaceToast> either way, if it's a new package, it goes into testing/, if it isn't, it stays in-place
2019-03-04 19:37:17 <fassl> also i couldn't figure out how other distros like fedora load the policy, i created a service that loads it after root and before localmount. is that ok, or where should it be loaded? maybe even in the initrd?
2019-03-04 19:41:00 <mps> SpaceToast: I'm writing short guide for iwd on Alpine. would you mind if I post it to skim over it
2019-03-04 19:41:25 <SpaceToast> mps: I'm still at work, in ~2h ok?
2019-03-04 19:42:09 <mps> ok, np
2019-03-04 19:45:30 <fassl> brb
2019-03-05 00:00:08 <LucasRamage[m]> rnalrd:
2019-03-05 01:22:31 <SpaceToast> ddevault: apparently export-ing outside out functions is ok? (my understanding was that any non-abuild vars had to be prefixed with _ which'd make RUSTFLAGS and co. useless, but reviews so far suggest that's fine)
2019-03-05 01:22:36 <SpaceToast> that's really nice to find out :D
2019-03-05 01:22:40 <SpaceToast> ty for trying it, I suppose :)
2019-03-05 02:34:51 <jwh> ah shit I didn't force push before clandmeter merged my PR
2019-03-05 02:34:52 <jwh> fml
2019-03-05 02:35:39 <SpaceToast> that's what the draft button is there for ;)
2019-03-05 02:36:10 <jwh> meh, it's ok, it's a no-op, I'll fix it
2019-03-05 07:10:39 <ncopa> morning. are anyone volunteering for maintain a nodejs8 package, and backport it to v3.9?
2019-03-05 07:11:02 <ncopa> to help out this guy: https://github.com/gliderlabs/docker-alpine/issues/494
2019-03-05 07:11:51 <skarnet> is anyone volunteering to rip their eye out of their socket, and put a hot poker in instead?
2019-03-05 07:12:17 <skarnet> j/k but that's kinda how it sounds :D
2019-03-05 07:12:27 <ncopa> that is exactly why i dont want do to it myself... :)
2019-03-05 07:12:34 <ncopa> actually, i dont think it is difficul
2019-03-05 07:12:52 <ncopa> just find old version from git log, copy the APKBUILD to community/nodejs8
2019-03-05 07:13:09 <ncopa> and cherry-pick to v3.9
2019-03-05 07:13:34 <ncopa> :q
2019-03-05 07:17:49 <jwh> ncopa: hm
2019-03-05 07:17:53 <jwh> uh
2019-03-05 07:17:56 <jwh> just 'hm'
2019-03-05 07:18:40 <jwh> is it worth even backporting? it's EOL this year anyway, and since that project is abandoned...
2019-03-05 07:19:19 <jwh> also 3 major versions old heh
2019-03-05 07:20:45 <ncopa> other question: does nodejs8 support openssl1.1?
2019-03-05 07:21:43 <jwh> doesn't look like it
2019-03-05 07:22:03 <jwh> 1: The 8.x Maintenance LTS cycle is currently scheduled to expire early on December 31, 2019 to align with the scheduled End-of-Life of OpenSSL-1.0.2.
2019-03-05 07:22:10 <jwh> so... probably not heh
2019-03-05 07:29:23 <ncopa> it builds with a shared openssl 1.1
2019-03-05 07:31:16 <ncopa> andypost[m]: if i create an nodejs8 package in community, would you be willing to help me maintain it?
2019-03-05 08:40:35 <fcolista> anyone has an idea on how to make wireguard work on raspberry?
2019-03-05 08:41:24 <danieli> does it not work?
2019-03-05 08:41:27 <fcolista> process would be making a custom alpine iso for rasp including wireguard-vanilla and wireguard-tools
2019-03-05 08:41:36 <fcolista> danieli, it's on sd
2019-03-05 08:41:46 <fcolista> so cannot install the kernel module
2019-03-05 08:42:06 <danieli> right, would probably have to create a custom image for it
2019-03-05 08:42:30 <fcolista> or make a disk install for rasp
2019-03-05 08:43:09 <clandmeter> overlayfs
2019-03-05 08:43:26 <clandmeter> allows you to install kernel modules
2019-03-05 08:44:21 <fcolista> clandmeter, any ref?
2019-03-05 08:44:30 <fcolista> https://wiki.alpinelinux.org/wiki/Raspberry_Pi#Installation
2019-03-05 08:44:35 <fcolista> i see overalyfs here
2019-03-05 08:44:46 <fcolista> but i need to mound /lib/modules as overlayfs
2019-03-05 08:44:51 <fcolista> *mount
2019-03-05 08:44:52 <fcolista> right?
2019-03-05 08:46:34 <clandmeter> check modloop initd
2019-03-05 08:47:53 <fcolista> ok...it says "user overlayfs if available and configured"
2019-03-05 08:47:59 <fcolista> *usaes
2019-03-05 08:48:26 <fcolista> where I can enable it?
2019-03-05 08:48:41 <clandmeter> heh
2019-03-05 08:48:49 <fcolista> it checkjs /proc/filesystems
2019-03-05 08:49:02 <fcolista> so is not only matter of loading the module
2019-03-05 08:49:22 <clandmeter> where do you normally set setttings for init.d files?
2019-03-05 08:49:39 <fcolista> conf.d
2019-03-05 08:49:44 <clandmeter> ;-)
2019-03-05 08:50:14 <fcolista> it is already enabled
2019-03-05 08:50:23 <fcolista> overlay_size=0
2019-03-05 08:51:04 <fcolista> which is 50% of tmpfs
2019-03-05 08:51:20 <clandmeter> i guess overlayfs is not available when modloop starts?
2019-03-05 08:51:24 <fcolista> so this means that overlayfs is already "enabled"
2019-03-05 08:53:06 <fcolista> I don't understand, then
2019-03-05 08:53:50 <clandmeter> is overlayfs loaded?
2019-03-05 08:54:19 <fcolista> it is
2019-03-05 08:54:26 <clandmeter> how did it load?
2019-03-05 08:54:58 <fcolista> modprobe overlay
2019-03-05 08:55:22 <clandmeter> can you add it to /etc/modules and reboot?
2019-03-05 08:55:34 <fcolista> I have in /proc/filesystem "nodev overlay"
2019-03-05 08:55:37 <fcolista> yup
2019-03-05 08:55:38 <fcolista> doing
2019-03-05 08:55:48 <clandmeter> btw, i think this will not really work as expected
2019-03-05 08:56:15 <clandmeter> i mean it works, but it will break when kernel upgrades
2019-03-05 08:56:17 <fcolista> from your words I understood that it jsut worked out-f-the-box due to the conf.d modloop entry
2019-03-05 08:56:24 <clandmeter> module will not match
2019-03-05 08:56:25 <fcolista> which contains overlay_size=0
2019-03-05 08:57:01 <clandmeter> its configured from there, but there are some steps to enable it.
2019-03-05 08:57:14 <fcolista> seems it's loaded
2019-03-05 08:57:19 <fcolista> lsmod reports overlay
2019-03-05 08:58:57 <fcolista> ok so next step would be allowing /lib/modules to be r/w
2019-03-05 08:59:16 <clandmeter> its not yet?
2019-03-05 08:59:22 <fcolista> heh
2019-03-05 08:59:26 <fcolista> interesting
2019-03-05 08:59:31 <fcolista> "no space left on device"
2019-03-05 08:59:45 <clandmeter> yes i bumped into that too
2019-03-05 08:59:47 <fcolista> the /.modloop is 100% in use
2019-03-05 09:00:01 <fcolista> and tmpfs has 3.7M free
2019-03-05 09:00:17 <fcolista> I need to tweak the tmpfs space at this point
2019-03-05 09:00:28 <fcolista> which by default it's 50% of ram
2019-03-05 09:00:56 <fcolista> let me check the tmpfs.txt on kernel docs..
2019-03-05 09:04:19 <clandmeter> fcolista: if you are just ging to use it yourself i would suggest to just create a release with wireguard build in.
2019-03-05 09:12:23 <fcolista> +1
2019-03-05 09:12:40 <fcolista> that would be the best approach, I afree
2019-03-05 09:12:45 <fcolista> *agree
2019-03-05 09:50:49 <fcolista> ok so /.modloop is on squashfs.. even with overlayfs I'm unable to have it in r/w.And /lib/modules is on /.modloop
2019-03-05 09:51:32 <fcolista> when I try to add linux-vanilla it fails
2019-03-05 09:54:32 <clandmeter> what does mount show?
2019-03-05 09:54:37 <clandmeter> and why are you installing the kernel?
2019-03-05 09:55:28 <fcolista> mount shows that /.modloop is "type squashfs" and linux-vanilla is needed for wireguard-vanilla
2019-03-05 09:56:10 <fcolista> wireguard-vanilla modules are compiled against 4.19.26-r0
2019-03-05 09:56:18 <fcolista> (which is on edge/testing)
2019-03-05 09:56:55 <fcolista> while on 3.9 I have 4.19.18
2019-03-05 10:04:20 <mps> fcolista: yesterday we discussed that, my proposal was to move wireguard to main or community because more and more people starting to use it
2019-03-05 10:05:00 <fcolista> when it is going to be inclued on mainstream kernel?
2019-03-05 10:05:14 <fcolista> This is the plan of linus afaik
2019-03-05 10:05:26 <mps> who knows, as usual with mainline
2019-03-05 10:05:28 <clandmeter> mps, this has nothing to do with this issue.
2019-03-05 10:05:57 <mps> clandmeter: yes, I know, but couldn't resist, sorry
2019-03-05 10:06:03 <clandmeter> :)
2019-03-05 10:06:04 <fcolista> lol
2019-03-05 10:06:22 <fcolista> ok, so...let's go for a custom image.
2019-03-05 10:10:07 <mps> fcolista: I do 'git checkout stable' and build wireguard module with current stable kernel, and install it manually
2019-03-05 10:23:47 <fcolista> fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/armhf/APKINDEX.tar.gz
2019-03-05 10:23:47 <fcolista> ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: UNTRUSTED signature
2019-03-05 10:24:22 <fcolista> should I use an armhf device to build the image for rasp?
2019-03-05 10:24:58 <fcolista> this is the script: https://dpaste.de/HV3x/raw
2019-03-05 10:25:11 <fcolista> and the command:
2019-03-05 10:25:12 <fcolista> sh mkimage.sh --tag edge --hostkeys --outdir ~/iso --arch armhf --repository http://dl-
2019-03-05 10:25:12 <fcolista> cdn.alpinelinux.org/alpine/edge/main --extra-repository http://dl-cdn.alpinelinux.org/alpine/edge/testing  --profile
2019-03-05 10:25:12 <fcolista> wireguard
2019-03-05 10:29:50 <clandmeter> yes, but you have an rpi :)
2019-03-05 10:30:09 <fcolista> yeah..just trying to do this on a container..
2019-03-05 10:30:42 <clandmeter> i thought before you could also create images for other arches, but seems its not possible.
2019-03-05 10:31:10 <fcolista> ok..
2019-03-05 10:31:18 <fcolista> let's go with the rasp then
2019-03-05 10:32:07 <clandmeter> i think you have arm container iirc
2019-03-05 10:33:46 <fcolista> I had, but then you have removed it :)
2019-03-05 10:34:12 <clandmeter> you have 2
2019-03-05 10:34:29 <clandmeter> 172.16.3.63
2019-03-05 10:34:59 <fcolista> I don't deserve you
2019-03-05 10:35:02 <fcolista> :D
2019-03-05 10:35:02 <clandmeter> 172.16.7.9
2019-03-05 10:35:09 <clandmeter> later one is aarch64
2019-03-05 10:36:10 <fcolista> right
2019-03-05 10:40:43 <fcolista> is running..
2019-03-05 10:45:36 <mps> fcolista: by running above 'sh mkimage.sh --tag edge ...' you will get ISO image with testing repo? Right?
2019-03-05 10:46:27 <fcolista> yes
2019-03-05 10:46:33 <fcolista> well
2019-03-05 10:46:45 <fcolista> is using the edge packages
2019-03-05 10:46:59 <mps> aha, nice to know, will note that for me. thanks
2019-03-05 10:47:46 <fcolista> clandmeter, looks that a container is not suffice to build an image
2019-03-05 10:47:49 <fcolista> in this case
2019-03-05 10:47:59 <clandmeter> say what?
2019-03-05 10:47:59 <fcolista> since the container is on edge, but the host is not
2019-03-05 10:48:12 <fcolista> OK: 8856 distinct packages available
2019-03-05 10:48:12 <fcolista> >>> mkimage-armhf: Building wireguard
2019-03-05 10:48:12 <fcolista> >>> mkimage-armhf: --> rpi_config 7fe1075dba749273e53c10e8e9904f18d939654b
2019-03-05 10:48:12 <fcolista> >>> mkimage-armhf: --> rpi_blobs
2019-03-05 10:48:12 <fcolista> >>> mkimage-armhf: --> kernel armhf vanilla 124829a6dcd11f213fa4158921104f74c1e93e7f linux-vanilla linux-firmware wireless-regdb
2019-03-05 10:48:14 <fcolista> modinfo: can't open '/lib/modules/4.14.38-1-vanilla/modules.dep': No such file or directory
2019-03-05 10:48:18 <fcolista> modinfo: can't open '/lib/modules/4.14.38-1-vanilla/modules.dep': No such file or directory
2019-03-05 10:48:20 <fcolista> modinfo: can't open '/lib/modules/4.14.38-1-vanilla/modules.dep': No such file or directory
2019-03-05 10:48:35 <clandmeter> add the correct repo via args
2019-03-05 10:48:41 <CobHead> One line of modinfo would be enough :d
2019-03-05 10:48:49 <fcolista> it tries to compile agains the modules.dep which comes from "uname"
2019-03-05 10:49:20 <fcolista> clandmeter, whati is wrong with this?
2019-03-05 10:49:21 <fcolista> --repository http://dl-cdn.alp
2019-03-05 10:49:21 <fcolista> inelinux.org/alpine/edge/main
2019-03-05 10:49:36 <clandmeter> fcolista: please use tpaste or similar
2019-03-05 10:49:43 <fcolista> +1
2019-03-05 10:49:47 <fcolista> sorry
2019-03-05 10:50:41 <clandmeter> linux-vanilla?
2019-03-05 10:51:48 <fcolista> yes
2019-03-05 10:52:02 <clandmeter> ah now i get it
2019-03-05 10:52:08 <clandmeter> we dont have wireguard for rpi?
2019-03-05 10:52:50 <fcolista> we do
2019-03-05 10:52:59 <fcolista> https://pkgs.alpinelinux.org/packages?name=wireguard-vanilla&branch=edge
2019-03-05 10:53:20 <fcolista> and also:
2019-03-05 10:53:20 <fcolista> https://pkgs.alpinelinux.org/packages?name=wireguard-tools&branch=edge
2019-03-05 10:53:26 <clandmeter> thats vanilla
2019-03-05 10:53:37 <clandmeter> rpi does not not run vanilla
2019-03-05 10:53:53 <fcolista> rpi is not armhf ?
2019-03-05 10:54:19 <clandmeter> rpi processor is aarch64
2019-03-05 10:54:30 <clandmeter> but can run armhf or armv7
2019-03-05 10:54:38 <clandmeter> but this has nothing to do with the kernel
2019-03-05 10:54:41 <fcolista> I use armhf
2019-03-05 10:54:47 <clandmeter> we have a custom kernel for rpu
2019-03-05 10:54:49 <clandmeter> RPI
2019-03-05 10:55:03 <fcolista> ?
2019-03-05 10:55:17 <fcolista> Oh man..didn't know that.
2019-03-05 10:55:19 <clandmeter> vanilla kernel does NOT run on rpi
2019-03-05 10:55:37 <clandmeter> well maybe it can nowdays but this is not what we do in alpine.
2019-03-05 10:55:56 <fcolista> what's the link between the kernel flavoru and the arch?
2019-03-05 10:55:58 <clandmeter> so life is even more complicated for you
2019-03-05 10:56:14 <fcolista> flavor*
2019-03-05 10:56:17 <clandmeter> its not the arch
2019-03-05 10:56:20 <clandmeter> its the board
2019-03-05 10:56:43 <clandmeter> most arm boards have custom kernels
2019-03-05 10:56:47 <fcolista> noard is a piece of silicon
2019-03-05 10:56:50 <fcolista> *board
2019-03-05 10:56:58 <clandmeter> board is pcb :)
2019-03-05 10:57:02 <clandmeter> and has silicon yes
2019-03-05 10:57:09 <fcolista> they have an architecture
2019-03-05 10:57:13 <fcolista> the architecture is arm
2019-03-05 10:57:24 <clandmeter> ok?
2019-03-05 10:57:27 <fabo> how can I disable fhs postcheck with abuild? I don't find where I can specify !fhs in abuild.conf or anywhere else actually
2019-03-05 10:57:29 <fcolista> how this is linked to the "flavor" fo the kernel
2019-03-05 10:57:31 <fcolista> ?
2019-03-05 10:57:50 <fcolista> I don't get it
2019-03-05 10:58:07 <clandmeter> vanilla kernel has multiple archs right?
2019-03-05 10:58:12 <fcolista> vanilla is one  of the way the kernel is built
2019-03-05 10:58:22 <fcolista> right
2019-03-05 10:58:26 <clandmeter> vanilla means no patches
2019-03-05 10:58:42 <clandmeter> just as its served by linux
2019-03-05 10:58:47 <fcolista> right. Is how is download ed by kernel.org
2019-03-05 10:58:54 <clandmeter> rpi kernel has a large patch for all different hw on the board
2019-03-05 10:59:07 <fcolista> oooh
2019-03-05 10:59:21 <fcolista> ok
2019-03-05 10:59:26 <fcolista> now I get it
2019-03-05 10:59:39 <fcolista> vanilla is not running on rpi due to the missing patches.
2019-03-05 10:59:59 <fcolista> ok, now I understand.
2019-03-05 11:00:02 <clandmeter> something like that yes
2019-03-05 11:00:26 <clandmeter> saying vanilla wont run could be wrong.
2019-03-05 11:00:27 <fcolista> That means that I cannot use wireguard on RPI
2019-03-05 11:00:31 <clandmeter> its not not optimal
2019-03-05 11:00:34 <clandmeter> grr
2019-03-05 11:00:37 <clandmeter> just not...
2019-03-05 11:00:55 <clandmeter> that means you cannot just apk add it
2019-03-05 11:01:18 <clandmeter> you can cp -r the wireguard vanilla pkg to wireguard rpi
2019-03-05 11:01:35 <clandmeter> modify the apkbuild and build it against rpi kernel
2019-03-05 11:02:02 <fcolista> yes, I got the point. So, wiregard on RPI can be run if I build it, or waiting that wireguard is included on streamline
2019-03-05 11:02:35 <fcolista> ok
2019-03-05 11:02:42 <fcolista> thanks a lot for your time clandmeter
2019-03-05 11:03:06 <clandmeter> it should be trivial to build it for rpu
2019-03-05 11:03:09 <clandmeter> RPi
2019-03-05 11:03:21 <clandmeter> and you have all the tools already
2019-03-05 11:07:44 <fcolista> yes
2019-03-05 11:09:31 <fcolista> https://dpaste.de/FQg8/raw
2019-03-05 11:09:33 <fcolista> built
2019-03-05 11:16:42 <fcolista> umh it ships vanilla anyway...:-/
2019-03-05 11:17:47 <fcolista> this because it pulls linux-firmware
2019-03-05 11:29:26 <clandmeter> fcolista: i added rpi wireguard module
2019-03-05 11:48:26 <andypost[m]> ncopa: not sure node8js makes sense
2019-03-05 11:49:26 <ncopa> andypost[m]: neither am I. Apparently there are a couple of popular(?) node modules that not yet support node 10
2019-03-05 11:49:56 <ncopa> if we add nodejs8, then it will only be in community, and will only be for v3.9 and possibly for v3.10
2019-03-05 11:50:01 <ncopa> but not for v3.11
2019-03-05 11:50:52 <danieli> think it'll require a lot of work to maintain it?
2019-03-05 11:51:34 <andypost[m]> ncopa: the real issue that we can't put latest security releases... but looks 8 will be maintained til'20 https://nodejs.org/en/about/releases/
2019-03-05 11:52:07 <andypost[m]> btw which packages require node*
2019-03-05 11:52:20 <andypost[m]> node8
2019-03-05 11:52:40 <danieli> I'm guessing Alpine users' applications just stop working on later Alpine releases
2019-03-05 11:53:40 <andypost[m]> btw the real blocker is https://github.com/alpinelinux/aports/pull/5939
2019-03-05 11:54:27 <ncopa> andypost[m]: well, i figured we could just just the bundled http-parser for nodejs8
2019-03-05 11:54:33 <ncopa> i have a working package
2019-03-05 11:54:40 <ncopa> question is if we want maintain it
2019-03-05 11:55:28 <andypost[m]> I actually prefer to not stick node apps longer then 3months - this area changing very fast
2019-03-05 11:56:11 <ncopa> ok. fair enough. that is an answer to my question
2019-03-05 11:56:15 <andypost[m]> and if some packages depends on node8 it means they has dependencies on badly maintained ones which 99% has security issues
2019-03-05 11:56:44 <ncopa> that is the problem here, the node package in question has not had release in 3 years
2019-03-05 11:57:00 <ncopa> apparently there is a fix for nodejs10 in git already, but there are no release
2019-03-05 11:57:38 <andypost[m]> ncopa: please point me to this one
2019-03-05 11:57:43 <ncopa> https://github.com/gliderlabs/docker-alpine/issues/494
2019-03-05 11:59:18 <ncopa> so, basically, the question is if we should be nice with this one guy and maintain nodejs8 for half year, or be realistic and dont
2019-03-05 11:59:41 <danieli> if we can find someone willing to commit to maintaining it, i don't see why not
2019-03-05 12:00:26 <ncopa> that was my original question. any volunteer to maintain it. I have made the initial work already
2019-03-05 12:00:37 <ncopa> so its just to make sure its kept update wrt sec fixes
2019-03-05 12:04:17 <andypost[m]> IMO if something in nodejs world has no releases for 3 years.. it should be buried with notice never touch this
2019-03-05 12:05:39 <ncopa> :D
2019-03-05 12:09:46 <danieli> I agree, but the real world isn't always rational
2019-03-05 12:16:01 <mps> any dbus expert here willing to help me with iwd dbus config service file
2019-03-05 12:54:11 <andypost[m]> ncopa: checked with frontenders - thay said this node module used by as dependecy a lot so better to use it's packed version
2019-03-05 12:54:16 <andypost[m]> *patched
2019-03-05 13:23:41 <fcolista> clandmeter, thanks!
2019-03-05 14:12:24 <ncopa> so, Im in the process of moving the official docker-alpine build to github.com/alpinelinux from gliderlabs
2019-03-05 14:12:43 <ncopa> i have the release scripts more or less done now
2019-03-05 14:15:59 <ncopa> there are various docs there that we may want move too
2019-03-05 14:16:46 <ncopa> https://github.com/gliderlabs/docker-alpine/tree/master/docs
2019-03-05 14:36:50 <otlabs> hi ppl
2019-03-05 14:38:41 <otlabs> I am building a package and would like to use "install -o user -g group ..." in it. I create the user and corresponding group in .pre-install script. I am unable to build this package as abuild complains about non existing user and group. How should I manage this?
2019-03-05 14:42:14 <AinNero> the install gets called on the build machine
2019-03-05 14:44:01 <AinNero> hm, it works when using the pkgusers variable
2019-03-05 14:45:27 <AinNero> do `grep -r pkgusers= aports/main/` to find a package as reference, there seems be quite many packages already managing this
2019-03-05 14:47:05 <otlabs> I used main/nginx as an example
2019-03-05 14:49:55 <otlabs> AinNero: Ha! Looks like it was not the best example! Thank you for the tip!
2019-03-05 14:51:17 <otlabs> It was. I just missed the use of pkgusers and pkggroups!
2019-03-05 14:53:04 <otlabs> Great! Now the package builds fine!
2019-03-05 14:57:01 <ncopa> im about to make new stable releases for 3.8, 3.7. and 3.6
2019-03-05 14:57:19 <ncopa> i wonder if i should create new release notes for each, or a single post with all 3?
2019-03-05 15:04:33 <otlabs> I am building a package for InterPlanetary File System, a peer-to-peer hypermedia distribution protocol, https://ipfs.io/. I have created a PR, https://github.com/alpinelinux/aports/pull/5812, would quite appreciate if someone will take a loot at it.
2019-03-05 15:05:18 <_ikke_> O
2019-03-05 15:06:14 <_ikke_> otlabs: can you rebase it on the latest master? We've added drone.io as CI, which can test on more platforms
2019-03-05 15:06:26 <_ikke_> I'll take a look at it later
2019-03-05 15:07:20 <otlabs> _ikke_: sure. I will try to do that right now.
2019-03-05 15:13:57 <otlabs> _ikke_: the build with drone fails as the main packages depends on other 2 packages I also have submitted
2019-03-05 15:14:10 <_ikke_> ok
2019-03-05 15:15:00 <_ikke_> So gx and gx-go, right?
2019-03-05 15:15:08 <otlabs> yes
2019-03-05 15:19:00 <clandmeter> include them in the pr
2019-03-05 15:39:29 <otlabs> I have prepared the upgrade for main/libmicrohttpd package, https://github.com/alpinelinux/aports/pull/6303, but the build fails during tests in check() function. Looks like the test suit do not like IPv6 configuration. What could you recommend to do in this situation?
2019-03-05 15:45:10 <_ikke_> otlabs: I guess report upstream
2019-03-05 15:45:52 <otlabs> _ikke_: thanks!
2019-03-05 15:49:42 <otlabs> _ikke_: same time these tests run fine on my local machine
2019-03-05 16:37:16 <bylaws> Is there a way I can build a package as arm64 but in an x86 environment?
2019-03-05 16:45:28 <mps> bylaws: qemu if the package is not big
2019-03-05 16:52:57 <bylaws> Hmph...
2019-03-05 16:55:56 <mps> yes, it slow a bit but I built some packages for armhf in qemu on x86_64
2019-03-05 17:48:28 <_ikke_> otlabs: still here?
2019-03-05 17:58:06 <otlabs> _ikke_: yes
2019-03-05 18:10:51 <iamphi> Hello. How does a package move from testing to main? I want to use libgdiplus, and it seems to have been in the testing repo for many years
2019-03-05 18:18:12 <_ikke_> otlabs: ah, i see you already responded to clandmeters request
2019-03-05 18:23:49 <otlabs> _ikke_: yes
2019-03-05 18:42:30 <clandmeter> otlabs: sorry i put another remark.
2019-03-05 18:45:07 <otlabs> clandmeter: No problem, it's first time I submit so complex PR, will resubmit it in a half an hour. Thank you for your kind attention!
2019-03-05 19:10:06 <otlabs> clandmeter: submitted as recommended, the build is complete
2019-03-05 20:50:58 <fcolista> clandmeter, if I want to add a local repo when build a custom image, how can I avoid the sign error?
2019-03-05 20:51:11 <fcolista> "failed to sign"
2019-03-05 20:51:43 <fcolista> i need wireguard-rpi2 since my rasp is rpi3
2019-03-05 20:52:01 <fcolista> so I added the wireguard-rpi2 package, but not pushed upstream
2019-03-05 20:52:13 <fcolista> I just want to add it by using a local repo
2019-03-05 20:53:07 <fcolista> when i add it:
2019-03-05 20:53:08 <fcolista> ERROR: /tmp/mkimage.hCdMgb/apks_armhf_f1422452a8d34f52674ab6b37dc695ea8927da1a.work/apks/armhf/wireguard-rpi2-4.19.26-r2.apk: BAD signature
2019-03-05 20:53:43 <clandmeter> you build it yourself?
2019-03-05 20:53:48 <fcolista> yup
2019-03-05 20:54:34 <fcolista> i have keys in /etc/apk/keys
2019-03-05 20:54:58 <clandmeter> doesnt it have a option to add  your own keys?
2019-03-05 20:55:51 <fcolista> i pass the arg --hostkeys
2019-03-05 20:56:02 <fcolista> "Copy system apk signing keys to created images"
2019-03-05 20:58:24 <fcolista> bah. Now it worked.
2019-03-05 20:59:15 <clandmeter> fcolista: why you need your own pkg anyway?
2019-03-05 20:59:22 <clandmeter> its not on mirror?
2019-03-05 20:59:27 <fcolista> just to now push wireguard-rpi2
2019-03-05 20:59:41 <fcolista> I didn't know if that was ok
2019-03-05 21:00:01 <fcolista> no I've not pushed it on testing
2019-03-05 21:00:35 <fcolista> I was wondering if there were a better way to add rpi2 package without creating another APKBUILD
2019-03-05 21:01:06 <clandmeter> possible
2019-03-05 21:01:16 <clandmeter> i forgot about rpi2
2019-03-05 21:01:20 <fcolista> https://dpaste.de/7JDp/raw
2019-03-05 21:01:43 <fcolista> i wonder if we can have like wireguard-raspberry
2019-03-05 21:01:53 <fcolista> and then having subpackage like rpi, rpi2
2019-03-05 21:02:25 <fcolista> but I don't know very well the arch/build combo with rasp
2019-03-05 21:03:09 <fcolista> do you have a chance to add wireguard-rpi2 if https://dpaste.de/7JDp/raw is fine?
2019-03-05 21:04:37 <clandmeter> we can add a subpkg rpi2
2019-03-05 21:05:19 <fcolista> so we will have wireguard-rpi and wireguard-rpi-rpi2 ?
2019-03-05 21:06:31 <clandmeter> no
2019-03-05 21:06:40 <clandmeter> you can name it whatever you want
2019-03-05 21:06:58 <fcolista> yes
2019-03-05 21:07:08 <fcolista> I express myself badly
2019-03-05 21:07:09 <clandmeter> just add a subpkg wireguard-rpi2:rpi2
2019-03-05 21:07:36 <fcolista> I was meant to use a consistent naming with wireguard-$something-rpi and -rpi2
2019-03-05 21:07:49 <fcolista> but is fine wireguard-rpi2 as well..
2019-03-05 22:05:36 <jwh> man, cockroachdb has gotten so much worse
2019-03-05 22:05:51 <jwh> no chance of it ever working on musl, it doesnt even work on glibc anymore
2019-03-05 23:23:58 <otlabs> clandmeter , _ikke_ thank you for your help!
2019-03-05 23:24:06 <otlabs> see you ppl
2019-03-05 23:32:30 <jwh> hm
2019-03-05 23:32:46 <jwh> wonder if I can use drone to build my staging apkbuilds before I open a pr
2019-03-05 23:48:26 <jwh> looks like I can, just need some pointers on setting secrets up :(
2019-03-06 02:46:52 <jwh> hm
2019-03-06 02:47:09 <jwh> so close
2019-03-06 02:56:08 <jwh> so whats wrong with jemalloc? is it being broken is why it got moved to unmaintained?
2019-03-06 02:56:29 <mps> jwh: right
2019-03-06 02:56:45 <jwh> interesting
2019-03-06 02:56:58 <SpaceToast> usually, unmaintained/ means the maintainer isn't there anymore, or isn't doing what they're supposed to
2019-03-06 02:57:10 <SpaceToast> if it's broken, and the maintainer doesn't fix it, I'd imagine that'd suggest the latter case
2019-03-06 02:57:11 <jwh> I wonder if my cockroach troubles are because of jemalloc in general, not their specific use of it
2019-03-06 02:57:26 <jwh> well, it segfaults in the same manner as cockroach (which uses jemalloc)
2019-03-06 02:57:49 <jwh> so if its that in fact jemalloc on musl is broken (or something specific to alpine), that may be easier to fix
2019-03-06 02:57:54 <mps> jemalloc is moved because it is broken and not used
2019-03-06 02:58:22 <jwh> so nobody attempted to fixi t?
2019-03-06 02:58:30 <jwh> or is it just totally hosed
2019-03-06 02:58:32 <mps> I forgot exactly what is broken
2019-03-06 02:59:04 <SpaceToast> I'd imagine that normally the maintainer is supposed to try to fix it :)
2019-03-06 02:59:34 <jwh> well, I just did an abuild and it fails during tests with segfaults
2019-03-06 02:59:50 <jwh> backtrace looks suspiciously similar
2019-03-06 02:59:56 <jwh> doesn't look like anyone managed to fix it though
2019-03-06 03:00:35 <mps> try without it, i.e. native malloc
2019-03-06 03:00:54 <mps> no one tried, iirc
2019-03-06 03:01:02 <jwh> umm
2019-03-06 03:01:05 <jwh> I'm building jemalloc... :P
2019-03-06 03:01:11 <mps> and I think no one wanted to try
2019-03-06 03:01:21 <jwh> yeah thats what it looks like
2019-03-06 03:01:23 <jwh> shame
2019-03-06 03:02:41 <mps> I remember that I skimmed but after short look concluded that it is not worth effort, hope you will prove me wrong :)
2019-03-06 03:02:50 <SpaceToast> if this was ~2 years ago I'd probably be working on it
2019-03-06 03:02:55 <SpaceToast> but nowadays I don't care enough about jemalloc
2019-03-06 03:03:21 <SpaceToast> I'd much rather get dlang in (and I'll probably concentrate my efforts on its built-in gcc support)
2019-03-06 03:03:25 <SpaceToast> (once gcc9 releases)
2019-03-06 03:03:27 <mps> that was few months ago, on Alpine I mean, iirc
2019-03-06 03:03:37 <jwh> I don't care about it either, but some useful projects make questionable decisions and are using it :(
2019-03-06 03:03:44 <SpaceToast> I know, I'm saying I would have had significant interest ~2 years ago
2019-03-06 03:04:01 <SpaceToast> the thing with jemalloc is that it's *miles* ahead of glibc's malloc
2019-03-06 03:04:09 <SpaceToast> but musl is good enough that there's no reason to go out and use it
2019-03-06 03:04:13 <jwh> and its specifically jemalloc which is breaking it on alpine (but not their builders for some reason, they're not very useful at debugging though)
2019-03-06 03:04:19 <jwh> yeah
2019-03-06 03:04:29 <jwh> I wonder how difficult its gonna be to ifdef
2019-03-06 03:04:34 <jwh> depends how they're using it
2019-03-06 03:06:07 <jwh> but umm, if I can convince jemalloc to pass tests on its own, it'll probably fix dependent projects and I can figure out what needs to be fixed in those
2019-03-06 03:06:16 <jwh> because bundling jemalloc is the done thing apparently
2019-03-06 03:07:24 <mps> however you want, but I would rather ask upstream to use native malloc
2019-03-06 03:07:39 <jwh> they won't do that
2019-03-06 03:07:54 <SpaceToast> I'd ask for a compile-time option for that
2019-03-06 03:07:58 <SpaceToast> (citing musl malloc)
2019-03-06 03:08:01 <jwh> they only officially support glibc, so they need the performance
2019-03-06 03:08:21 <jwh> but they do produce unofficial musl binaries, I've had an issue open for months
2019-03-06 03:08:23 <mps> SpaceToast: that is better option ;)
2019-03-06 03:08:25 <jwh> they're not moving on it at all
2019-03-06 03:08:42 <jwh> couldn't even get them to add a simple -D_BSD_SOURCE to the cflas
2019-03-06 03:08:43 <jwh> cflags
2019-03-06 03:08:45 <SpaceToast> tell them that you're an amazing maintainer and are willing to maintain an official alpine package, you just really would like to not use jemalloc because fixing it is out-of scope ;)
2019-03-06 03:08:58 <jwh> well
2019-03-06 03:09:00 <SpaceToast> well you can set your own cflags when you build from source :)
2019-03-06 03:09:02 <mps> +1
2019-03-06 03:09:10 <jwh> what should actually happen is the jemalloc maintainer stops being shit
2019-03-06 03:09:10 <jwh> :D
2019-03-06 03:09:21 <jwh> SpaceToast: not without patching the tree
2019-03-06 03:09:25 <SpaceToast> but that's not the case -> unmaintained/ \o/
2019-03-06 03:09:43 <SpaceToast> set yourself as maintainer and fix it? :^)
2019-03-06 03:09:51 <jwh> https://github.com/jemalloc/jemalloc/issues/1443
2019-03-06 03:09:58 <jwh> that would be a no then
2019-03-06 03:10:41 <SpaceToast> that's... strange
2019-03-06 03:10:49 <SpaceToast> I'm pretty sure you can just define away function calls
2019-03-06 03:10:58 <SpaceToast> whether or not there's "explicit support"
2019-03-06 03:11:02 <jwh> but...
2019-03-06 03:11:03 <SpaceToast> then again, I haven't done much C in a while
2019-03-06 03:11:06 <SpaceToast> (why bother, D exists)
2019-03-06 03:11:11 <jwh> firefox builds on musl?
2019-03-06 03:11:16 <SpaceToast> yeah, that too..
2019-03-06 03:11:21 <jwh> they forked jemalloc
2019-03-06 03:11:22 <jwh> soooo
2019-03-06 03:11:37 <SpaceToast> hahahaha
2019-03-06 03:11:37 <jwh> but maybe they just use it on glibc
2019-03-06 03:11:48 <SpaceToast> I wonder if you could strings(1) the binary to check
2019-03-06 03:11:52 <jwh> or maybe they never used it
2019-03-06 03:11:57 <jwh> because firefox is still dog slow :D
2019-03-06 03:12:07 <SpaceToast> ah
2019-03-06 03:12:11 <SpaceToast> jwh: --disable-jemalloc
2019-03-06 03:12:15 <SpaceToast> line 113 of firefox APKBUILD
2019-03-06 03:12:20 <jwh> ah heh
2019-03-06 03:12:24 <jwh> nevermind that then
2019-03-06 03:12:28 <SpaceToast> jemalloc really doesn't offer any speed bumps on musl though
2019-03-06 03:12:36 <SpaceToast> it does offer lots of tracking features, so it's still nice for developers
2019-03-06 03:13:05 <jwh> yeah, since they don't really support musl I expect it's just that they needed speed that glibc couldn't give them
2019-03-06 03:13:18 <SpaceToast> probably, yes
2019-03-06 03:13:32 <jwh> I mean, I even asked about their builder environments as those build musl binaries just fine
2019-03-06 03:13:35 <SpaceToast> ideally, jemalloc gets fixed, and cockroachdb makes jemalloc conditional ala firefox
2019-03-06 03:13:36 <jwh> presumably with jemalloc...
2019-03-06 03:13:51 <jwh> and they run ok
2019-03-06 03:14:06 <jwh> was hoping they'd actually have tried to fix it, but doesn't look like it at all
2019-03-06 03:15:19 <jwh> for want of a nice db
2019-03-06 03:15:45 <SpaceToast> jwh: oxymoron
2019-03-06 03:16:00 <jwh> wellllll, cockroach *is* pretty nice
2019-03-06 03:16:15 <jwh> convenient and presents postgres so it's not totally unusable
2019-03-06 03:16:26 <SpaceToast> my view is simple
2019-03-06 03:16:28 <jwh> it's not mysql, but it's at least a popular sql dialect
2019-03-06 03:16:28 <SpaceToast> SQL sucks.
2019-03-06 03:16:38 <SpaceToast> therefore, no implementation of SQL can be good.
2019-03-06 03:16:47 <jwh> lol
2019-03-06 03:16:51 <SpaceToast> some (very few) applications do *need* SQL (since it's strongly read-optimized)
2019-03-06 03:16:58 <SpaceToast> but when you really need it, you KNOW you need it
2019-03-06 03:17:03 <jwh> it just takes years of practice to do sql right, most people don't
2019-03-06 03:17:04 <SpaceToast> (and usually have the budget to use HANA or something)
2019-03-06 03:17:19 <SpaceToast> if it takes years of practice to use a storage solution, perhaps the issue is with the storage solution ;)
2019-03-06 03:17:29 <jwh> it isn't a storage solution though
2019-03-06 03:17:49 <jwh> you can write entire applications in it :D
2019-03-06 03:18:03 <SpaceToast> any application will continually expand until [...]
2019-03-06 03:18:37 <SpaceToast> but yeah, if you need atomic transactions, either use redis (no scaling, but fast, and can be persistent); or mongo (lots of scaling, a bit less fast)
2019-03-06 03:18:54 <jwh> kv isn't enough for a lot of applications
2019-03-06 03:18:58 <SpaceToast> if you need sql, at least so far, I recommend postgres (since the core is semi-decent in extreme workloads, which you likely have), or sqlite if it's small
2019-03-06 03:19:09 <SpaceToast> it really is
2019-03-06 03:19:25 <jwh> it's not practical to express complex models with kv
2019-03-06 03:19:28 <jwh> dnw
2019-03-06 03:19:31 <SpaceToast> I went over a list of 100 applications that claim they need SQL super badly and redesigned them (super top level) to make them work elegantly with kv
2019-03-06 03:19:40 <SpaceToast> failed with 1, I think?
2019-03-06 03:19:50 <SpaceToast> and that one had a multi billion dollar budget and was using HANA :)
2019-03-06 03:19:54 <jwh> heh
2019-03-06 03:20:16 <SpaceToast> but let me be more specific:
2019-03-06 03:20:39 <SpaceToast> For MOST applications, SQL is not needed. If you think you need it, think LONG AND HARD about it.
2019-03-06 03:20:54 <SpaceToast> If you still think you need it, use sqlite (no scaling) or postgres (lots of scaling).
2019-03-06 03:21:18 <jwh> I wouldn't actually use either for my workloads (for different reasons)
2019-03-06 03:21:38 <jwh> hm
2019-03-06 03:21:53 <jwh> briefly back to jemalloc...
2019-03-06 03:22:20 <jwh> I don't see anything in strace for their binaries
2019-03-06 03:22:20 <SpaceToast> hmm, you sure?
2019-03-06 03:22:27 <mps> I agree for SQL, postgres or sqlite, rest is hmmm ...... :D
2019-03-06 03:22:33 <SpaceToast> postgres handles petabyte-per-day throughputs
2019-03-06 03:22:39 <SpaceToast> if you set it up correctly
2019-03-06 03:23:13 <jwh> my objection to postgres has always been cobbling together 3rd party products to get even a semblance of streaming replication (triggers aren't good enough)
2019-03-06 03:23:25 <jwh> its better now but why bother when alternatives exist now
2019-03-06 03:23:28 <mps> and also thinking to rewrite one of my application to use redis or something similar
2019-03-06 03:23:59 <jwh> and sqlite well, maybe it's usable with dqlite (more go fun!)
2019-03-06 03:24:07 <SpaceToast> dqlite is quite the thing
2019-03-06 03:24:15 <SpaceToast> broke lxd on alpine for a while until fcolista figured it out :)
2019-03-06 03:24:21 <jwh> heh
2019-03-06 03:24:28 <mps> you can have streaming replication without third party add-ons
2019-03-06 03:24:46 <jwh> sqlite on its own is barely usable for simple applications, its far too easy to hit locks
2019-03-06 03:24:51 <SpaceToast> mps: redis is nice, brpaste uses it as the backend storage
2019-03-06 03:25:06 <SpaceToast> sqlite devs are just "special"
2019-03-06 03:25:15 <jwh> yeah Ive been looking at redis to move some of the existing DB stuff away to a kv store
2019-03-06 03:25:16 <SpaceToast> if you want to see it on display, look into fossil (the scm)
2019-03-06 03:25:23 <mps> I'm using it in some applications and in some in combo with postgres
2019-03-06 03:25:34 <SpaceToast> jwh: mongo is more "real db"-like, redis is pure kv/cache
2019-03-06 03:25:43 <jwh> dumpster fire
2019-03-06 03:25:45 <jwh> :D
2019-03-06 03:26:05 <SpaceToast> eh, it gets a bad rep because weird people expose it to WAN with no password
2019-03-06 03:26:10 <SpaceToast> the actual thing is perfectly fine
2019-03-06 03:26:17 <jwh> I don't think thats why it got a bad rep tbh
2019-03-06 03:26:27 <jwh> but.. malloc!
2019-03-06 03:26:40 <jwh> shouldn't I at least see some malloc calls in a simple strace?
2019-03-06 03:26:41 <SpaceToast> I've not heard of anyone complain about it besides "omg so insecure look at [X that got hacked because they did that]"
2019-03-06 03:28:04 <jwh> oh its broken
2019-03-06 03:28:05 <jwh> nm
2019-03-06 03:31:15 <jwh> oh at some point the guy I was dealin with had a non-jemalloc branch
2019-03-06 03:31:33 <jwh> maybe it's not that difficult to disable it
2019-03-06 03:32:27 <SpaceToast> ooh, patch time!
2019-03-06 03:32:41 <SpaceToast> one nice thing with jemalloc is it *is* supposed to be fairly easy to disable
2019-03-06 03:33:11 <jwh> if they're using it in the same way as generic malloc, it might be feasible to just ifdef it
2019-03-06 03:33:15 <jwh> and send a PR
2019-03-06 03:33:31 <jwh> passing flags to anything in their horrible build system is a nightmare
2019-03-06 03:33:57 <SpaceToast> what do they use?
2019-03-06 03:34:04 <jwh> horrible make wrappers
2019-03-06 03:34:12 <jwh> because go build system is stupid
2019-03-06 03:34:16 <jwh> but they also use cgo
2019-03-06 03:34:23 <SpaceToast> oh no
2019-03-06 03:34:40 <jwh> so much better than C it needs to use... C
2019-03-06 03:34:40 <jwh> :D
2019-03-06 03:35:24 <SpaceToast> that's why you use D
2019-03-06 03:35:27 <SpaceToast> obviously.
2019-03-06 03:35:28 <jwh> heh
2019-03-06 03:36:11 <jwh> I still need to figure out this drone thing as well
2019-03-06 03:36:38 <jwh> would be nice if I could hook my staging repo up so I can do test runs without opening PRs
2019-03-06 03:36:49 <jwh> -- Build files have been written to: /home/jwh/cockroach-v19.1.0-beta.20190304/native/x86_64-alpine-linux-musl/rocksdb_stdmalloc
2019-03-06 03:36:52 <jwh> hmmm
2019-03-06 03:36:57 <jwh> maybe that stuff is still there then
2019-03-06 03:46:49 <jwh> yeah so drone, I don't really know what I'm doing :S
2019-03-06 03:52:17 <jwh> also TIL facebook suck at code as well as ethics
2019-03-06 03:52:36 <jwh> their kv db that cockroach uses assumes everything is 64bit
2019-03-06 03:52:47 <jwh> and its *still* not been fixed after like 4 years
2019-03-06 03:54:23 <SpaceToast> wait till you see google code standards
2019-03-06 03:54:47 <SpaceToast> don't make me link you the pdf of nightmares :)
2019-03-06 03:55:02 <jwh> heh
2019-03-06 03:55:11 <SpaceToast> https://arxiv.org/ftp/arxiv/papers/1702/1702.01715.pdf
2019-03-06 03:55:13 <jwh> I've seen their code standards
2019-03-06 03:55:17 <jwh> :D
2019-03-06 03:56:07 <jwh> lol 86TB repo
2019-03-06 03:56:09 <jwh> ridiculous people
2019-03-06 03:56:36 <SpaceToast> "we couldn't figure git out so we just did weird svn shenanigans until it sorta worked"
2019-03-06 03:56:45 <SpaceToast> anyway, if you wanna continue, we can do it on -offtopic :)
2019-03-06 03:56:54 <jwh> I will once this builds properly
2019-03-06 03:57:01 <jwh> if I don't go to bed
2019-03-06 03:57:28 <SpaceToast> ah, see you in 2020 then
2019-03-06 03:58:22 <jwh> lol
2019-03-06 03:58:31 <jwh> by the time this atom finishes it may well be 2020
2019-03-06 04:17:06 <jwh> abuild-amd64:~/cockroach-v19.1.0-beta.20190304$ /home/jwh/cockroach-v19.1.0-beta.20190304/src/github.com/cockroachdb/cockroach/cockroach
2019-03-06 04:17:09 <jwh> CockroachDB command-line interface and server.
2019-03-06 04:17:10 <jwh> unbelievable
2019-03-06 04:17:23 <jwh> after months of fucking around, the guy who merged the stdmalloc shit forgot to mention it
2019-03-06 04:17:26 <jwh> ...
2019-03-06 04:17:32 <jwh> (he merged it 2 years ago)
2019-03-06 04:17:47 <SpaceToast> so... there's just an undocumented flag to not use jemalloc?
2019-03-06 04:17:55 <jwh> yup
2019-03-06 04:18:01 <jwh> he did it to support openbsd
2019-03-06 04:18:05 <SpaceToast> lol nice
2019-03-06 04:18:07 <jwh> but it applies to all I guess
2019-03-06 04:18:18 <jwh> waste of both of our time
2019-03-06 04:18:19 <jwh> god
2019-03-06 04:18:41 <jwh> since theres no trace of je in their binaries, I'm gonna guess they use that lag
2019-03-06 04:18:44 <jwh> flag
2019-03-06 04:19:00 <jwh> since they do not use the same process as is "documented"
2019-03-06 04:19:31 <jwh> guess I'll tidy that up after my nap and send a PR
2019-03-06 04:21:21 <jwh> I think thats actually the last item on my list to start deploying my alpine containers :D
2019-03-06 04:21:34 <SpaceToast> :D
2019-03-06 04:21:56 <SpaceToast> so far, all of my @home containers (and container-hosts) except one are alpine
2019-03-06 04:22:01 <SpaceToast> the one is because requires dlang
2019-03-06 04:22:49 <jwh> well this is all production stuff, so kinda needs to be a bit more organised than home heh
2019-03-06 04:23:24 <jwh> oh theres one more I've got a PR open for, but thats not a show stopper really, upstream suck
2019-03-06 04:23:34 <SpaceToast> well I also have plenty of alpine containers at work too :)
2019-03-06 04:23:39 <SpaceToast> but not everything, no
2019-03-06 04:26:04 <jwh> heh
2019-03-06 04:26:04 <jwh> same
2019-03-06 04:27:03 <jwh> well if I get this PR in, tidy up roll a silghtly more useful lxd image - I should be set
2019-03-06 04:27:39 <jwh> then I can keep ontop of updates as my time isn't being sucked up by things that don't build properly
2019-03-06 04:27:58 <SpaceToast> :D
2019-03-06 04:47:32 <jwh> SpaceToast: lxd 3.11 is up btw
2019-03-06 04:47:40 <jwh> should fix all the problems
2019-03-06 04:47:45 <SpaceToast> oh cool
2019-03-06 04:48:03 <SpaceToast> I just checked my emails earlier
2019-03-06 04:48:07 <SpaceToast> guessing I'll see the announcement tomorrow
2019-03-06 04:48:19 <jwh> https://github.com/lxc/lxd/releases/tag/lxd-3.11
2019-03-06 04:48:20 <jwh> yeah
2019-03-06 04:49:08 <SpaceToast> ah, he hasn't written the thing yet
2019-03-06 04:49:33 <jwh> yeah
2019-03-06 06:35:25 <ollieparanoid[m]> ncopa: https://bugs.alpinelinux.org/issues/8257#change-27457 <- this can be closed as it is already implemented, no need to change the target version
2019-03-06 06:35:57 <ollieparanoid[m]> (would be nice if users could close their own issues, maybe somebody can configure that?)
2019-03-06 08:23:00 <_ikke_> ollieparanoid[m]: let me check if I can arrange that
2019-03-06 08:55:19 <_ikke_> ollieparanoid[m]: adjusted it so that you can close it yourself now (ncopa just closed this one though)
2019-03-06 08:55:45 <ollieparanoid[m]> _ikke_: great, thanks!
2019-03-06 09:05:37 <ncopa> _ikke_: thanks
2019-03-06 09:28:50 <fabo> any chance to get https://github.com/alpinelinux/aports/pull/6446 reviewed?
2019-03-06 09:29:06 <fabo> it has only minor changes and has been sitting for 11 days
2019-03-06 09:29:29 <fabo> clandmeter: ^^^
2019-03-06 10:30:22 <ncopa> does anyone know alternatige to "expect"? for a test suite that needs input from tty?
2019-03-06 10:32:24 <_ikke_> Hmmm, expect is the usual goto for that
2019-03-06 10:49:21 <ncopa> _ikke_: do you have experience with expect?
2019-03-06 10:50:20 <_ikke_> A little bit
2019-03-06 11:07:09 <terra> Is there a plan regarding relaxing PR's for testing repo? Will maintainers able to update their own packages without PR's?
2019-03-06 11:37:06 <_ikke_> clandmeter: https://github.com/alpinelinux/aports/pull/6554 drone fails because it cannot find botan-dev which is in testing, is that correct?
2019-03-06 11:38:32 <clandmeter> _ikke_: looks like it
2019-03-06 11:38:46 <clandmeter> if its missing a dep it could be a dep downwards which is not allowed
2019-03-06 11:40:05 <_ikke_> ellaborate?
2019-03-06 11:43:04 <clandmeter> main is the top repo followed by community and then testing
2019-03-06 11:43:34 <clandmeter> so things in a higher repo cannot depend on a lower repo
2019-03-06 11:43:47 <_ikke_> ah, like that
2019-03-06 11:43:57 <clandmeter> the build script will apply that logic
2019-03-06 11:44:17 <clandmeter> build for testing will have all 3 repos
2019-03-06 11:44:20 <_ikke_> makes sense
2019-03-06 11:44:36 <clandmeter> build for community remove testing
2019-03-06 11:44:42 <clandmeter> build for main....
2019-03-06 11:44:57 <_ikke_> https://github.com/alpinelinux/aports/pull/6548 has quite a bit of dependent PRs, should that just be a single PR?
2019-03-06 11:45:37 <clandmeter> yes, depends should always go into a single PR
2019-03-06 11:45:45 <_ikke_> ok
2019-03-06 11:46:07 <clandmeter> abuild will handle to logic for local repos
2019-03-06 11:47:18 <clandmeter> terra: that would mean all those ppl need  commit access
2019-03-06 11:48:07 <clandmeter> if you regularly update something in testing, you could consider moving it to community.
2019-03-06 11:51:51 <terra> clandmeter: can this solved by hook scripts?
2019-03-06 11:52:09 <clandmeter> explain the problem
2019-03-06 11:53:14 <terra> to make packagers update their packages on testing repo without PR
2019-03-06 11:53:45 <clandmeter> which problem are you trying to overcome?
2019-03-06 11:53:49 <mps> doesn't sound as good idea
2019-03-06 11:54:45 <terra> to perevent delays of single version bumps on testing repo
2019-03-06 11:55:38 <terra> mps: otherwise maintaining a repo called "TESTING" may not be a good idea as well
2019-03-06 11:57:45 <mps> why not? package from testing could be promoted to community
2019-03-06 11:58:12 <clandmeter> terra: testing repo is a staging area
2019-03-06 11:58:26 <clandmeter> if a package gets frequent updates it doesnt belong in testing.
2019-03-06 11:58:31 <terra> mps: then you could make a strict review when moving from testing to community
2019-03-06 11:58:47 <terra> clandmeter: exactly it is "staging"
2019-03-06 11:59:06 <mps> terra: I'm for strict review by at least two person
2019-03-06 11:59:19 <clandmeter> and  staging needs a review process
2019-03-06 12:00:03 <terra> clandmeter: I agree. Since package is already in testing repo.. no need to delay for single version bumps at all.
2019-03-06 12:00:12 <mps> I'm looking on #alpine-commits and my fear raises from week to week that quality is lowers
2019-03-06 12:00:41 <clandmeter> terra: why do a single version bump in testing?
2019-03-06 12:01:03 <terra> package has a vew version and need to be updated ??
2019-03-06 12:01:14 <clandmeter> so its not a staging area anymore?
2019-03-06 12:01:22 <clandmeter> just a regular repo with different name
2019-03-06 12:01:38 <clandmeter> sure packages should be able to be bumped.
2019-03-06 12:01:56 <clandmeter> but this should not be a regular thing in testing.
2019-03-06 12:02:05 <clandmeter> so it shouldnt happen that often
2019-03-06 12:02:20 <terra> So packages need to be moved to community before getting an version bump?? I don't get it.
2019-03-06 12:02:32 <clandmeter> no, thats not what i said
2019-03-06 12:03:10 <clandmeter> ones the package is ready it should be able to be merged into community.
2019-03-06 12:03:21 <clandmeter> else we should move it to unmaintained
2019-03-06 12:03:50 <clandmeter> beteen new and ready it could happen it has a version change. but this should not happen much.
2019-03-06 12:05:00 <_ikke_> And simple version bumps should not take long to be applied
2019-03-06 12:05:17 <clandmeter> the problem we are currently facing is that we dont have enough ppl to keep the flow of new pr's low
2019-03-06 12:05:18 <terra> clandmeter: what about aur style repo?
2019-03-06 12:05:35 <clandmeter> but its getting better now.
2019-03-06 12:06:23 <clandmeter> i think we are currently getting the count down and respond faster to new contributions.
2019-03-06 12:07:26 <clandmeter> something like aur could be better, but we need ot think about it.
2019-03-06 12:07:38 <clandmeter> personally i dont like testing repo
2019-03-06 12:09:12 <terra> AUR style repo + voting system (+ maybe popularity contest)
2019-03-06 12:09:41 <_ikke_> I don't think Alpine wants something like popularity-contest
2019-03-06 12:09:53 <clandmeter> our project got a bigger over time, so testing is not suitable anymore.
2019-03-06 12:09:57 <mps> _ikke_: +1
2019-03-06 12:10:13 <terra> when a package gets decent reviews/points it can be moved to community
2019-03-06 12:10:38 <clandmeter> popularity doesnt really matter
2019-03-06 12:10:49 <clandmeter> it should be good quality and has a maintainer
2019-03-06 12:10:56 <clandmeter> thats all that we need
2019-03-06 12:11:15 <mps> quality first, imo
2019-03-06 12:11:49 <clandmeter> and main is also kind of confusing
2019-03-06 12:11:52 <terra> I agree with that but we also need to higher amount of flow rate
2019-03-06 12:12:37 <_ikke_> The rate is already higher then it was a couple of weeks ago
2019-03-06 12:12:44 <clandmeter> we need qualified ppl to do that. and we dont pay them anything. thats a problem for any OS project.
2019-03-06 12:13:14 <clandmeter> _ikke_: is it possible to graph merged PR's?
2019-03-06 12:13:28 <_ikke_> https://zabbix.alpinelinux.org/history.php?action=showgraph&itemids[]=28584
2019-03-06 12:13:30 <_ikke_> this?
2019-03-06 12:13:40 <mps> repology have some graphs
2019-03-06 12:13:40 <_ikke_> or amount of merged ones?
2019-03-06 12:13:49 <clandmeter> right number of merged ones
2019-03-06 12:13:58 <clandmeter> so we can see the actual work force
2019-03-06 12:13:58 <_ikke_> If the api exposes that, then yes
2019-03-06 12:14:34 <clandmeter> in 10 days that graph will get a bit lower :)
2019-03-06 12:14:40 <_ikke_> hehe
2019-03-06 12:14:58 <mps> didn't looked deeply at repology but it shows Alpine is in better shape last two weeks
2019-03-06 12:15:46 <terra> I remember PR acount was around 180's past year.
2019-03-06 12:16:11 <terra> recently it was hitting 400
2019-03-06 12:16:11 <clandmeter> yes it was lower
2019-03-06 12:16:11 <_ikke_> yes, and we're working hard to get back to that number and lower
2019-03-06 12:16:24 <clandmeter> come back in 10 days :)
2019-03-06 12:16:54 <terra> what about if the PR's closed automatically by this bot?
2019-03-06 12:16:58 <clandmeter> i think we are reviewer better now.
2019-03-06 12:17:19 <clandmeter> thats why a merge graph would be nice to compare
2019-03-06 12:17:39 <clandmeter> what if what?
2019-03-06 12:18:14 <terra> "This pull request has been automatically marked as stale because it has not had activity in the last 60 days. It will be automatically closed....."
2019-03-06 12:18:49 <terra> https://github.com/alpinelinux/aports/pull/5058#issuecomment-469428408
2019-03-06 12:25:04 <clandmeter> https://github.com/alpinelinux/aports/pull/5058#issuecomment-470088376
2019-03-06 12:27:56 <clandmeter> https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea
2019-03-06 13:42:32 <mps> how to make package alternate depends="foo|bar"
2019-03-06 13:48:06 <clandmeter> you want to depend on foo or bar?
2019-03-06 13:48:40 <mps> yes
2019-03-06 13:48:58 <clandmeter> can you explain the use case?
2019-03-06 13:49:08 <clandmeter> i dont think we support this
2019-03-06 13:49:29 <mps> connman wireless agent could use wpa_supplicant or iwd as backend
2019-03-06 13:50:24 <mps> so, not put anyone of them :)
2019-03-06 13:52:46 <clandmeter> How would connman know what to install?
2019-03-06 13:53:55 <mps> that is the question. maybe conflicts and provides combo?
2019-03-06 13:55:40 <mps> not really. huh, have no idea
2019-03-06 13:55:45 <clandmeter> i think (but im no expert) that you have two options
2019-03-06 13:56:14 <clandmeter> 1. make subpkgs that depends on one of the deps and user can select.
2019-03-06 13:56:19 <mps> two packages? connman-iwd and connman-wpa_supplicant ?
2019-03-06 13:56:46 <clandmeter> 2. make those 2 packages provide the same thing and set provider_priority
2019-03-06 13:57:50 <mps> didn't know for provider_priority. will look at examples. thanks
2019-03-06 13:57:58 <clandmeter> what do that two deps have in common?
2019-03-06 13:58:53 <mps> user can prefer wpa_supplicant or iwd as low level wifi manager and connman as connection manager
2019-03-06 13:59:12 <clandmeter> you could also do install_if if there is another common reference
2019-03-06 14:00:23 <mps> imo, user should have option which of the two wants to be installed
2019-03-06 14:01:30 <mps> easiest solution, do not depend on any one, and then user can install preferred 'by hand'
2019-03-06 14:01:38 <clandmeter> if wifi-manager is the common, you could do provide=wifi-manager and depend on it. you can use provider_priority to make one preferred over the other. not sure if this is an acceptable hack :)
2019-03-06 14:02:41 <mps> that is something for brainstorming, I'm not in hurry
2019-03-06 14:03:03 <_ikke_> I don't apk currently allows you to select what dependency you prefer
2019-03-06 14:04:12 <clandmeter> not directly
2019-03-06 14:04:33 <clandmeter> but it can sort of with install_if or same provides
2019-03-06 14:06:24 <clandmeter> fabled or ncopa can probably answer that better than i can.
2019-03-06 14:08:09 <mps> np, thanks
2019-03-06 15:21:43 <otlabs> hi ppl
2019-03-06 15:22:01 <_ikke_> otlabs: hi
2019-03-06 15:22:14 <otlabs> _ikke_: greetings!
2019-03-06 15:23:30 <otlabs> I got my PR, https://github.com/alpinelinux/aports/pull/5812, compiling well for x86 and x86_64, but all instances for arch architecture do not compile, the error is that gcc is unable to find ld.
2019-03-06 15:24:43 <otlabs> Should I just disable all arch architectures or should I ask for help to check drone configuration?
2019-03-06 15:32:26 <_ikke_> otlabs: You might need to add binutils as a makedep
2019-03-06 15:34:35 <otlabs> _ikke_: wow! thank you! will try right now
2019-03-06 15:35:18 <jwh> hey clandmeter, you know drone right?
2019-03-06 15:35:38 <jwh> or anyone really I guess,
2019-03-06 15:35:39 <_ikke_> jwh: he set it up for us, so most likely
2019-03-06 15:36:00 <jwh> trying to figure out how to connect my own repo so I can push my apkbuilds there first
2019-03-06 15:36:24 <jwh> i've activated it but I dunno what else I need to do like webhooks
2019-03-06 15:36:53 <jwh> rather than opening a PR and having it fail immediately :D
2019-03-06 15:38:29 <clandmeter> did you activate it in drone?
2019-03-06 15:38:36 <clandmeter> on cloud
2019-03-06 15:38:51 <jwh> yeah
2019-03-06 15:39:06 <clandmeter> so the webhook is activated?
2019-03-06 15:39:13 <jwh> do I need keys or tokens or something, docs don't really help me
2019-03-06 15:39:21 <jwh> I guess, I don't see anything on the repo at github though
2019-03-06 15:39:31 <clandmeter> it should show on webhooks
2019-03-06 15:39:36 <clandmeter> in github repo settings
2019-03-06 15:41:08 <jwh> hm
2019-03-06 15:41:25 <clandmeter> thats what activate does on cloud.drone.io
2019-03-06 15:41:51 <jwh> oh I see it actyally
2019-03-06 15:41:52 <jwh> actually
2019-03-06 15:41:54 <jwh> huh
2019-03-06 15:43:57 <clandmeter> did you activcate it on your own aports fork?
2019-03-06 15:44:28 <jwh> I created a new repo as a test, used the same drone config
2019-03-06 15:44:37 <jwh> but i'm not even seeing it trigger
2019-03-06 15:44:49 <jwh> just pushed to it, nothing
2019-03-06 15:44:52 <clandmeter> you dont see webhook coalls?
2019-03-06 15:44:53 <clandmeter> calls
2019-03-06 15:45:14 <clandmeter> if you open the drone webhook on github it should show you activtity
2019-03-06 15:45:36 <jwh> I see a 'ping'
2019-03-06 15:46:02 <jwh> but nothing since
2019-03-06 15:46:03 <clandmeter> thats the inital
2019-03-06 15:46:06 <jwh> yeah
2019-03-06 15:46:09 <clandmeter> make sure you enable it for what you want
2019-03-06 15:46:21 <jwh> well I'm using the defaults, but commits are enabled
2019-03-06 15:46:22 <clandmeter> ie for PR or commits
2019-03-06 15:46:30 <jwh> which is what I want
2019-03-06 15:46:57 <clandmeter> if you use my docker image it will only work for PR
2019-03-06 15:47:04 <jwh> ohh
2019-03-06 15:47:11 <clandmeter> but
2019-03-06 15:47:16 <clandmeter> you should still see the trigger
2019-03-06 15:47:18 <jwh> well even so I should still see it trigger right?
2019-03-06 15:47:19 <jwh> yeah
2019-03-06 15:47:47 <jwh> https://github.com/joeholden/apkbuilds
2019-03-06 15:47:49 <jwh> all I've done
2019-03-06 15:48:40 <clandmeter> there is a gitter channel
2019-03-06 15:48:55 <jwh> whats that
2019-03-06 15:49:12 <clandmeter> chat
2019-03-06 15:49:18 <jwh> oh
2019-03-06 15:49:31 <jwh> gonna recreate it first, just in cas
2019-03-06 15:49:33 <jwh> case*
2019-03-06 15:49:37 <jwh> possible I broke it
2019-03-06 15:51:59 <jwh> I guessss I could just activate it on my aports fork and never merge the PRs, just use for build testing?
2019-03-06 15:52:49 <jwh> although can I even open a PR against my own fork?
2019-03-06 15:53:36 <clandmeter> its not that hard to convert it to commits
2019-03-06 15:53:43 <clandmeter> but for now it cant
2019-03-06 15:54:02 <jwh> yeah
2019-03-06 15:54:03 <jwh> hm
2019-03-06 15:54:11 <SpaceToast> jwh: somewhere down my pipeline (though admittedly a while from now) I have plans to set up a jenkins instance for myself
2019-03-06 15:54:23 <SpaceToast> if you'd like (and you haven't figured it out by then), just ask me and I'll give you an account :)
2019-03-06 15:54:42 <jwh> heh, will I did have a jenkins instance but I'd rather not host one myself tbh, plus drone has non-x86
2019-03-06 15:54:48 <clandmeter> the multi arch thingy is kinda nice from drone
2019-03-06 15:54:52 <jwh> yeah
2019-03-06 15:54:59 <jwh> it's really the non-x86 tests I want
2019-03-06 15:55:07 <SpaceToast> aha
2019-03-06 15:55:15 <SpaceToast> yeah, I don't really care for non-x86 ^^
2019-03-06 15:55:29 <jwh> I don't have aarch64 and having to build on 4 seperate boxes is tedious
2019-03-06 15:55:45 <jwh> x86, x86_64, armhf, aarch64
2019-03-06 15:56:15 <jwh> nm, I'll revisit it later
2019-03-06 16:12:30 <jwh> >>> cockroach: Updating the sha512sums in APKBUILD...
2019-03-06 16:12:30 <jwh> sha512sum: unrecognized option: q
2019-03-06 16:12:31 <jwh> hm
2019-03-06 16:12:38 <jwh> oh nm
2019-03-06 16:12:48 <jwh> copy/paste failure :D
2019-03-06 16:20:18 <jwh> ah hm
2019-03-06 16:20:20 <jwh> how do I fix this...
2019-03-06 16:20:25 <jwh> https://cloud.drone.io/alpinelinux/aports/258/2/2
2019-03-06 16:20:40 <jwh> perms in drone
2019-03-06 16:37:16 <clandmeter> ?
2019-03-06 16:37:52 <_ikke_> ln: ../../../../../../../../.git/hooks/post-merge: Permission denied
2019-03-06 16:37:55 <clandmeter> Does it try to write outside startdir?
2019-03-06 16:38:16 <jwh> don't see anything above build dir on my machin
2019-03-06 16:38:18 <_ikke_> it apparently does
2019-03-06 16:38:19 <jwh> machine*
2019-03-06 16:38:28 <jwh> but maybe thats a weird path thing
2019-03-06 16:38:42 <clandmeter> Probably broken build tools
2019-03-06 16:38:53 <clandmeter> Or retarded
2019-03-06 16:39:02 <jwh> probably both, but it shouldn't fail to build
2019-03-06 16:39:23 <danieli> watch it clandmeter or I'm going to wash your mouth with soap :)
2019-03-06 16:39:27 <_ikke_> Why is it trying to do something with git hooks anyway?
2019-03-06 16:39:42 <clandmeter> There user has only access to the startdir
2019-03-06 16:40:04 <jwh> it's using submodules, maybe something dumb (there is lots of dumb)
2019-03-06 16:40:19 <clandmeter> No soap now. I'm drinking IPA
2019-03-06 16:41:14 <clandmeter> If it's doing git calls it's probably broken
2019-03-06 16:41:55 <_ikke_> It looks like to add submodules, and because there is no git repo, it probably tries to add them to aports
2019-03-06 16:41:57 <jwh> well not really, git submodules is an acceptable build time command
2019-03-06 16:41:58 <jwh> heh
2019-03-06 16:42:00 <jwh> yeah
2019-03-06 16:42:08 <jwh> but... they're not in my aports repo
2019-03-06 16:42:12 <jwh> which is weird
2019-03-06 16:42:39 <jwh> I'll start with a fresh one just in case
2019-03-06 16:42:40 <clandmeter> It's not for reproduceable builds
2019-03-06 16:43:07 <jwh> ahhh I see it
2019-03-06 16:43:10 <jwh> ok
2019-03-06 16:44:34 <jwh> thats kinda stupid
2019-03-06 16:46:53 <jwh> I don't even know how to fix that without patching it out and probably breaking it, github archives don't include .git either
2019-03-06 16:48:13 <jwh> # If we're in a git worktree, the git hooks directory may not be in our root,
2019-03-06 16:48:16 <jwh> # so we ask git for the location.
2019-03-06 16:48:17 <jwh> ...
2019-03-06 16:48:18 <jwh> jeez
2019-03-06 16:50:21 <jwh> @ln -s ../../$(basename $<) $(dir $@)
2019-03-06 16:50:22 <jwh> lol
2019-03-06 17:12:20 <jwh> very good, make CFLAGS=... works locally but not on the drone builder
2019-03-06 17:12:21 <jwh> baahhhh
2019-03-06 17:20:02 <_ikke_> Projects that assume git to be present is very anoying
2019-03-06 17:20:28 <jwh> well... it would be except they assume its present for release archives too
2019-03-06 17:20:37 <jwh> it would be ok*
2019-03-06 17:20:50 <jwh> and even in their pregenerated archives, not just the github ones
2019-03-06 17:20:52 <_ikke_> It makes no sense for a release archive to have a .git dir
2019-03-06 17:20:57 <jwh> yeah
2019-03-06 17:21:02 <jwh> I've patched it ou
2019-03-06 17:21:10 <jwh> out*
2019-03-06 17:21:27 <jwh> other nonsense now like C[XX]FLAGS being ignored
2019-03-06 17:21:55 <SpaceToast> wew, migrating gitlab between remote hosts is quite the adventure
2019-03-06 17:22:30 <jwh> so make -j$(getconf _NPROCESSORS_ONLN) build CFLAGS=-D_BSD_SOURCE CXXFLAGS=-D_BSD_SOURCE TAGS=stdmalloc works manually, but not in the apkgbuild
2019-03-06 17:22:33 <jwh> hm
2019-03-06 17:24:09 <otlabs> Please, advice. I have a PR with 3 commits for 3 packages I would like to add. I need to update the 1st commit. How to achieve this?
2019-03-06 17:24:30 <SpaceToast> rewrite history, pr should auto-update
2019-03-06 17:26:25 <_ikke_> indeed
2019-03-06 17:26:43 <_ikke_> make changes, git add -p; git commit --fixup <hash of first commit>; git rebase -i master
2019-03-06 17:26:45 <_ikke_> something like that
2019-03-06 17:28:27 <otlabs> Ok, let me absorb that. Thank you!
2019-03-06 17:28:55 <_ikke_> git rebase -i --autosquash master
2019-03-06 17:29:26 <otlabs> Great!
2019-03-06 17:30:55 <SpaceToast> well there are lots of ways to rewrite history :)
2019-03-06 17:30:58 <SpaceToast> that's certainly one of them though
2019-03-06 17:31:00 <_ikke_> yes
2019-03-06 17:35:57 <otlabs> wow! running 'git add -p' troughs an error: git: 'add--interactive' is not a git command.
2019-03-06 17:36:30 <jwh> I just reset --soft and commit all the changes
2019-03-06 17:36:40 <jwh> but I have no idea what I'm doing
2019-03-06 17:37:44 <SpaceToast> otlabs: that suggests you have some custom configuration you haven't told us about ;)
2019-03-06 17:39:08 <_ikke_> otlabs: are you on alpine?
2019-03-06 17:39:11 <_ikke_> you need git-perl as well
2019-03-06 17:39:47 <otlabs> I am on Alpine Edge
2019-03-06 17:39:57 <otlabs> let me check for git-perl
2019-03-06 17:40:48 <ddevault> working on a plan for improving the state of Python packaging in aports
2019-03-06 17:40:52 <ddevault> https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-03-06 17:41:03 <ddevault> going to take it to the ML when I have a more concrete plan but consider yourself invited to participate
2019-03-06 17:42:24 <otlabs> git-perl was not installed, now git add 'p works as expected, thank you!
2019-03-06 17:44:07 <SpaceToast> ddevault: I would start on removing python2 right away, instead of trying to fix 2 + 3
2019-03-06 17:44:36 <SpaceToast> also, for the normalization project, assuming the team management initiative goes through, it might make sense to have a python-dedicated team (given the amount of things that there are to do)
2019-03-06 17:44:37 <ddevault> I think that removing python 2 support is going to be Pretty Hard
2019-03-06 17:44:45 <ddevault> whereas normalizing everything would be Not That Hard
2019-03-06 17:44:55 <SpaceToast> sure, I'm just saying that it'll happen anyway, so why normalize things twice?
2019-03-06 17:44:56 <ddevault> so I was thinking normalize first so we have a nice baseline
2019-03-06 17:45:08 <SpaceToast> is your APKBUILD template easy to adapt to py3-only?
2019-03-06 17:45:18 <ddevault> fairly easy
2019-03-06 17:45:24 <SpaceToast> ok, sounds good to me then :)
2019-03-06 17:46:10 <ddevault> https://wiki.alpinelinux.org/wiki/Python_package_policies#No_python2_support
2019-03-06 17:46:38 <ddevault> open question here is, how do alpine devs generally go about removing packages from a repo
2019-03-06 17:47:07 <ddevault> and do we drop the py-x metapackage in favor of py3-x, or merge py3-x into py-x and drop py3- and py2-
2019-03-06 17:47:12 <ddevault> then add the appropriate replaces
2019-03-06 17:47:29 <ddevault> the former is probably easier but the latter makes for a cleaner repo in the long term
2019-03-06 17:47:45 <SpaceToast> re: removal, I've mostly only seen things get thrown (back into) testing/ or into unmaintained/ (e.g see jemalloc)
2019-03-06 17:47:58 <SpaceToast> I think py3-x should be py-x, and py2 should be explicit
2019-03-06 17:48:17 <ddevault> it would be super annoying to move a subpackage into unmaintained/ while leaving the parent package in $otherrepo
2019-03-06 17:48:28 <ddevault> repeated for all python packages
2019-03-06 17:48:33 <SpaceToast> for sure, yeah
2019-03-06 18:01:03 <jwh> yeah sooo
2019-03-06 18:01:12 <jwh> apkbuild works fine locally, but not in drone
2019-03-06 18:01:13 <jwh> whyyyyy
2019-03-06 18:01:33 <jwh> at least it looks like it works
2019-03-06 18:05:51 <danieli> works on my machine™️
2019-03-06 18:26:38 <ddevault> can packages depend upwards (e.g. main -> community) if it's isolated to checkdepends?
2019-03-06 18:27:34 <_ikke_> I don't think community is even available
2019-03-06 18:27:39 <_ikke_> when building something in main
2019-03-06 18:27:44 <ddevault> aight
2019-03-06 18:27:46 <ddevault> cheers
2019-03-06 18:36:11 <_ikke_> clandmeter: apparently it's not as easy to get the number of closed issues
2019-03-06 18:36:56 <jwh> is there a policy on arch-specific patches?
2019-03-06 18:37:06 <jwh> or, can someone versed in go tell me how to ifdef :D
2019-03-06 18:43:37 <clandmeter> _ikke_: is it related to the way we close them?
2019-03-06 18:45:09 <_ikke_> clandmeter: no, I found a way in the mean time
2019-03-06 18:45:22 <clandmeter> :)
2019-03-06 18:45:39 <clandmeter> how do you know its actually merged?
2019-03-06 18:45:46 <_ikke_> Not really
2019-03-06 18:45:48 <clandmeter> when we modified commits
2019-03-06 18:45:50 <_ikke_> that's indeed hard
2019-03-06 18:46:00 <_ikke_> More like closed pull request
2019-03-06 18:46:26 <clandmeter> so it will also display non merged closed requests?
2019-03-06 18:46:39 <_ikke_> yes, there is no way for us to differentiate
2019-03-06 18:46:45 <clandmeter> or you only list the ones by algitbot?
2019-03-06 18:46:49 <_ikke_> all pull requests are just closed
2019-03-06 18:46:54 <clandmeter> that wold make kind of sense
2019-03-06 18:47:37 <clandmeter> there are only a few that are closed manually
2019-03-06 18:47:48 <_ikke_> Not sure if you can filter issues by who closed it
2019-03-06 18:48:18 <clandmeter> closed is ok i guess
2019-03-06 18:49:25 <_ikke_> perhaps involves:algitbot
2019-03-06 18:50:27 <clandmeter> i would like to know a way to auto amend the commit message for a series of patches
2019-03-06 18:50:55 <_ikke_> perhaps filter-branch
2019-03-06 18:51:29 <_ikke_> So total closed issues: 6191, involves:algitbot: 4749
2019-03-06 18:51:38 <clandmeter> so i can write a script to apply a PR and append a reference to the PR so github will auto close it
2019-03-06 18:52:04 <_ikke_> Right, that migth work
2019-03-06 18:52:34 <clandmeter> i played with using something like echo as the editor
2019-03-06 18:52:50 <_ikke_> you want something like sed
2019-03-06 18:54:25 <clandmeter> ill have to check it out ones more. there seems no default tool for the job, but it must be possible somehow.
2019-03-06 18:57:03 <jwh> :(
2019-03-06 18:57:19 <jwh> why is this broken, can I invoke it differently instead to make it work?
2019-03-06 18:57:33 <jwh> make VAR=VALUE works if I invoke it in a shell, but not in build()
2019-03-06 18:57:35 <jwh> :/
2019-03-06 18:58:15 <_ikke_> clandmeter: precommit hook perhaps?
2019-03-06 18:59:30 <clandmeter> i wouldnt know how tht would help
2019-03-06 18:59:59 <otlabs> _ikke_: I have added binutils to makedep but I still receive same error about gcc is unable to find ld on arm platform. Any suggestions?
2019-03-06 19:00:10 <_ikke_> clandmeter: ^?
2019-03-06 19:00:44 <clandmeter> i dont know.
2019-03-06 19:01:15 <clandmeter> I dont think its drone related, but i have been wrong before :)
2019-03-06 19:02:00 <otlabs> ok, I will restrict supported architectures for now
2019-03-06 19:02:26 <clandmeter> binutils is already part of build-base
2019-03-06 19:12:22 <jwh> lol wow, this guy who does all the bitching on the comments about getting various stuff fixed
2019-03-06 19:12:27 <jwh> it's his garbage thats totally broken
2019-03-06 19:12:38 <jwh> asshole
2019-03-06 19:13:01 <jwh> another brauner
2019-03-06 19:13:18 <SpaceToast> o no
2019-03-06 19:13:31 <jwh> knz
2019-03-06 19:13:55 <jwh> pregenerated config.h which is fine it can be fixed
2019-03-06 19:14:11 <jwh> #ifndef HAVE_STRLCAT
2019-03-06 19:14:11 <jwh> #define strlcat libedit_strlcat
2019-03-06 19:14:41 <jwh> this is horrible
2019-03-06 19:14:52 <SpaceToast> ROFL
2019-03-06 19:15:17 <jwh> but if HAVE_STRLCAT is defined, it still doesn't do the right thing
2019-03-06 19:15:30 <jwh> but this is all go stuff, theres no makefiles...
2019-03-06 19:16:19 <jwh> I'm pretty sure something in abuild or maybe drone is tripping meup
2019-03-06 19:20:27 <otlabs> clandmeter: I have restricted the architectures to x86_64 and x86. Got 2 green marks from CIs. Could you please take a look at it, https://github.com/alpinelinux/aports/pull/5812?
2019-03-06 19:21:20 <_ikke_> peaking
2019-03-06 19:21:41 <_ikke_> s/ea/ee/
2019-03-06 19:21:42 <alpine-meetbot> _ikke_ meant to say: peeking
2019-03-06 19:21:51 <jwh> hm, wonder if it'll be easier to just link against libedit
2019-03-06 19:21:58 <otlabs> thank you
2019-03-06 19:22:12 <SpaceToast> libedit is pretty small
2019-03-06 19:22:16 <SpaceToast> probably could just do it
2019-03-06 19:22:41 <jwh> depends how much of a PITFA it is
2019-03-06 19:22:50 <jwh> as it's all wrapped up by go-libedit
2019-03-06 19:22:58 <jwh> so so dumb
2019-03-06 19:30:38 <jwh> // #cgo linux CPPFLAGS: -Isrc -Isrc/c-libedit -Isrc/c-libedit/editline -Isrc/c-libedit/linux-build -D_GNU_SOURCE
2019-03-06 19:30:41 <ncopa> i need to make a new releases of old stable. there was a commit i forgot to check :(
2019-03-06 19:30:41 <jwh> hm
2019-03-06 19:30:42 <jwh> maybe thats enough
2019-03-06 19:37:18 <jwh> sigh
2019-03-06 19:37:26 <jwh> everything go related is such a disaster
2019-03-06 19:37:54 <_ikke_> otlabs: did you take a look at that comment I placed?
2019-03-06 19:37:58 <jwh> either the language itself is nonsense, or everyone who writes stuff in it is terrible
2019-03-06 19:38:19 <SpaceToast> it's the language, I'm pretty sure
2019-03-06 19:38:43 <SpaceToast> you can have good things be written in it (gogs, gitea, lxd, so on), but the language (and the ecosystem even more so) makes it all work worse :/
2019-03-06 19:38:52 <jwh> heh
2019-03-06 19:39:13 <jwh> I haven't come across a single go project yet that isn't a mess
2019-03-06 19:39:31 <jwh> cgo makes it a hundred times worse
2019-03-06 19:39:34 <SpaceToast> well it's expected, look at the boilerplate required to handle possible error conditions :D
2019-03-06 19:39:50 <SpaceToast> tfw every single function call = at least 5 LOC of boilerplate because it has the potential to fail
2019-03-06 19:39:58 <jwh> lol
2019-03-06 19:40:11 <SpaceToast> because pike decided "having a cheat code around the type system is a good idea"
2019-03-06 19:40:23 <SpaceToast> and then everyone used that cheat code to signal errors
2019-03-06 19:42:31 <jwh> heh
2019-03-06 19:42:45 <jwh> so cgo, is it really supposed to be // #cgo or is that still a comment?
2019-03-06 19:42:55 <jwh> or did they redefine what comments are for the sake of it
2019-03-06 19:43:59 <SpaceToast> they redefined what comments are for its sake
2019-03-06 19:44:07 <jwh> lol
2019-03-06 19:44:10 <jwh> ridiculous peopel
2019-03-06 19:44:11 <jwh> people*
2019-03-06 19:45:11 <jwh> I think I'm wasting my time trying to fix the build system, since it will build with the right flags
2019-03-06 19:46:13 <jwh> I've told them whats (still) broken, so they can fix it
2019-03-06 19:50:18 <otlabs> _ikke_: yes. 'go get' is part of make build process. I used Arch Linux as a template to prepare ABUILD and it has no support to fix go dependencies. My knowledge of go is still close to zero. Sorry, I have no any clue how to implement this.
2019-03-06 19:50:55 <_ikke_> I usually try to look at other packages that use go
2019-03-06 19:51:15 <_ikke_> It depends a bit on the project, but usually glider is used to lock down dependencies
2019-03-06 19:52:08 <jwh> umm, from the docs...
2019-03-06 19:52:09 <jwh>  Warning: In the past you could install IPFS using go get. This does not work anymore!
2019-03-06 19:52:22 <jwh> SpaceToast: see!
2019-03-06 19:52:28 <SpaceToast> _ikke_: funny thing about glide
2019-03-06 19:52:32 <SpaceToast> the author deprecated it in favor of dep
2019-03-06 19:52:39 <SpaceToast> and dep is being deprecated in favor of "another prototype"
2019-03-06 19:52:46 <SpaceToast> that other prototype doesn't exist yet
2019-03-06 19:52:47 <_ikke_> lol
2019-03-06 19:52:58 <jwh> bluez syndrome
2019-03-06 19:53:01 <jwh> :D
2019-03-06 19:53:03 <_ikke_> heh
2019-03-06 19:53:08 <SpaceToast> hey, at least iwd actually works!
2019-03-06 19:53:20 <jwh> for simple things yeah
2019-03-06 19:53:38 <SpaceToast> I have a friend using it in high complexity enterprise environments with no problems :)
2019-03-06 19:53:49 <jwh> it actually supports EAP now?
2019-03-06 19:53:50 <SpaceToast> (NSA-levels of security, for reasons, can't say much more though)
2019-03-06 19:53:54 <SpaceToast> yes, has for a while
2019-03-06 19:54:04 <jwh> yeah it did but it didn't actually work :D
2019-03-06 19:54:07 <SpaceToast> it's still in beta, mind you, expecting it to support everything in pre-alpha would have been silly :)
2019-03-06 19:54:16 <otlabs> _ikke_: ok, I will do my best.
2019-03-06 19:54:25 <jwh> SpaceToast: deprecated in a couple of months anyway :D
2019-03-06 19:54:31 <SpaceToast> ¯\_(ツ)_/¯
2019-03-06 19:55:23 <_ikke_> otlabs: Sorry for this work, it's the sad state of how go works, having to do a lot of extra work to lock down dependencies
2019-03-06 19:55:38 <_ikke_> https://github.com/alpinelinux/aports/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+cockroach :(
2019-03-06 19:55:42 <jwh> do they include the dependencies in their release archives?
2019-03-06 19:55:54 <_ikke_> sometimes they vendor the deps indeed
2019-03-06 19:55:58 <_ikke_> but not always
2019-03-06 19:56:08 <jwh> _ikke_: cockroach is *really* getting on my tits
2019-03-06 19:56:18 <_ikke_> jwh: how so?
2019-03-06 19:56:26 <jwh> check the commits in my PR :P
2019-03-06 19:56:44 <SpaceToast> jwh: lewd :P
2019-03-06 19:56:56 <_ikke_> jwh: what PR?
2019-03-06 19:57:04 <_ikke_> The last one?
2019-03-06 19:57:08 <jwh> most recent one
2019-03-06 19:57:08 <_ikke_> 6564?
2019-03-06 19:57:16 <jwh> ye
2019-03-06 19:57:20 <_ikke_> Yeah, I noticed indeed
2019-03-06 19:57:30 <_ikke_> but there are 2 older PRs for cockroah
2019-03-06 19:57:33 <jwh> yeah
2019-03-06 19:58:06 <_ikke_> jwh: note that you can rewrite commits and force push as well
2019-03-06 19:58:08 <jwh> it's changed significantly from then, it's a whole new challenge with every major version
2019-03-06 19:58:30 <jwh> _ikke_: yeah I'm just using it for drone, my fast builder is still not configured, so
2019-03-06 19:59:15 <jwh> the current beta 100% works however
2019-03-06 19:59:19 <jwh> so I'm tempted to just wait
2019-03-06 20:00:07 <jwh> but something still seems to be eating the make command
2019-03-06 20:04:14 <otlabs> _ikke_: go-ipfs uses gx, https://github.com/whyrusleeping/gx. Looks like it handle all that stuff you are asking me for.
2019-03-06 20:06:20 <_ikke_> what about gx itself?
2019-03-06 20:06:58 <otlabs> hahaha, good question!
2019-03-06 20:07:29 <_ikke_> I checked a random file, but it seems to use gx itself
2019-03-06 20:07:35 <_ikke_> not sure how to bootstrap that
2019-03-06 20:07:45 <_ikke_> https://github.com/whyrusleeping/gx/blob/master/check.go#L7
2019-03-06 20:12:40 <_ikke_> otlabs: right, so gx downloads several depedencies itself
2019-03-06 20:15:09 <otlabs> it gets  gx-go
2019-03-06 20:16:35 <_ikke_> "and pulls ideas from other beloved package managers (like npm)" are they serious/
2019-03-06 20:16:37 <_ikke_> ?
2019-03-06 20:18:04 <TBB> good thing I wasn't sipping coffee when I read that, it'd be all over the keyboard by now
2019-03-06 20:18:54 <otlabs> _ikke_: looks like
2019-03-06 20:21:05 <jwh> alright
2019-03-06 20:21:20 <jwh> I need to shift some blame to abuild
2019-03-06 20:21:21 <jwh> :D
2019-03-06 20:21:47 <_ikke_> LEAVE ABUILD ALONE :P
2019-03-06 20:21:53 <jwh> :(
2019-03-06 20:22:00 <jwh> its breaking my commands
2019-03-06 20:22:16 <jwh> I thought I could unbreak the projects build stuff, but I cannot
2019-03-06 20:22:20 <jwh> it's a disaster
2019-03-06 20:22:33 <jwh> so insteasd I need to figure out how to make abuild pass args properly
2019-03-06 20:23:06 <_ikke_> it's just shell..
2019-03-06 20:23:32 <jwh> yeah, but it's not quite working
2019-03-06 20:24:23 <SpaceToast> jwh: the "it's just shell" part is very literal, btw
2019-03-06 20:24:29 <SpaceToast> vim $(which abuild)
2019-03-06 20:24:34 <jwh> yes
2019-03-06 20:24:38 <jwh> I know that :P
2019-03-06 20:24:44 <SpaceToast> so figure out what's broken in busybox ash :D
2019-03-06 20:25:09 <jwh> but for some reason they're getting lost
2019-03-06 20:25:18 <_ikke_> example?
2019-03-06 20:25:31 <SpaceToast> time to back up ~24gb of usb drives
2019-03-06 20:25:38 <jwh> make -j$(getconf _NPROCESSORS_ONLN) build CFLAGS=-D_BSD_SOURCE CXXFLAGS=-D_BSD_SOURCE TAGS=stdmalloc - builds fine if I invoke it manually (caveat; I use bash as my shell)
2019-03-06 20:25:52 <jwh> but in abuild they dont seem to make it
2019-03-06 20:26:23 <jwh> I don't think it'll read environment vars, so
2019-03-06 20:26:44 <_ikke_> jwh: why don't you set an appropriate value for JOBS in /etc/abuild.conf?
2019-03-06 20:26:58 <SpaceToast> ^ that's very strange
2019-03-06 20:27:04 <jwh> the -j is ok
2019-03-06 20:27:10 <jwh> cflags/tags don't seem to make it
2019-03-06 20:27:12 <_ikke_> yeah, more of a sidenote
2019-03-06 20:27:20 <_ikke_> are you sure?
2019-03-06 20:27:23 <jwh> thats just coz I'm building on different boxes
2019-03-06 20:27:34 <jwh> well, it looks like they *should* make it
2019-03-06 20:27:45 <SpaceToast> is build really the target name?
2019-03-06 20:27:45 <_ikke_> these are just arguments to a command
2019-03-06 20:27:47 <jwh> but the output of the build is what is expected if they're missing
2019-03-06 20:27:49 <jwh> SpaceToast: yeah
2019-03-06 20:28:26 <SpaceToast> hm
2019-03-06 20:28:37 <_ikke_> jwh: what if you exchange make with echo?
2019-03-06 20:28:47 <SpaceToast> jwh: what if you put the target ("build") after all of the vars?
2019-03-06 20:28:55 <jwh> SpaceToast: I was just trying that actually
2019-03-06 20:28:57 <SpaceToast> might be different make implementation
2019-03-06 20:29:21 <SpaceToast> alternatively, could just export the vars outside of the invocation
2019-03-06 20:29:51 <_ikke_> note that for ash, these are just plain arguments, no variable assignments
2019-03-06 20:30:00 <_ikke_> (same for bash)
2019-03-06 20:30:30 <SpaceToast> yes, if you put it after `make`, it's make's job to figure out what to do with'em
2019-03-06 20:30:37 <SpaceToast> (thus my suggestion to use actual vars)
2019-03-06 20:31:04 <jwh> lemme see
2019-03-06 20:31:55 <_ikke_> can't it be that CFLAGS is overridden?
2019-03-06 20:32:09 <_ikke_> look in /etc/abuild.conf
2019-03-06 20:32:23 <jwh> hm I wonder
2019-03-06 20:32:24 <_ikke_> not sure what has priority in make
2019-03-06 20:32:35 <jwh> I didn't even check tbh
2019-03-06 20:32:44 <jwh> I had a hunch but I'm sure other packages use CFLAGS=
2019-03-06 20:33:06 <SpaceToast> make VAR=VAL has priority, assuming make reads it at all
2019-03-06 20:33:12 <SpaceToast> but that's in gmake
2019-03-06 20:33:16 <SpaceToast> idk about bmake and other variants
2019-03-06 20:33:50 <jwh> its just gmake
2019-03-06 20:36:05 <jwh> I mean, it would be better if this go piece of shit actually worked as documented
2019-03-06 20:36:08 <jwh> :)
2019-03-06 20:36:26 <jwh> then I wouldn't need to pass stupid flags
2019-03-06 20:46:42 <jwh> well, that one works
2019-03-06 20:48:26 <otlabs> _ikke_: sorry, looks like I will be unable  to lock dependencies.
2019-03-06 20:48:40 <jwh> [ 0%] Building CXX object CMakeFiles/build_version.dir/build_version.cc.o
2019-03-06 20:48:41 <jwh> cc1plus: error: unknown value 'armv8-a-march=armv8-a' for -march
2019-03-06 20:48:43 <jwh> l o l
2019-03-06 20:48:56 <_ikke_> otlabs: :(
2019-03-06 20:49:15 <_ikke_> otlabs: I noticed that a package.json was generated after building
2019-03-06 20:50:20 <otlabs> _ikke_: and...???
2019-03-06 20:50:53 <_ikke_> it does contain a list of the dependencies. Not sure if that's usefull though
2019-03-06 20:53:32 <otlabs> The file go-ipfs/package.json is a part of distribution, it was not generated during build
2019-03-06 20:53:44 <otlabs> https://github.com/ipfs/go-ipfs/blob/master/package.json
2019-03-06 20:53:49 <_ikke_> was talking about gx
2019-03-06 20:55:08 <otlabs> maybe the version lock is done by the file I just mentioned?
2019-03-06 20:55:26 <_ikke_> perhaps
2019-03-06 20:55:45 <_ikke_> if you could verify that
2019-03-06 20:56:41 <otlabs> hmmm... the build logs could provide version info, gimme some time
2019-03-06 21:05:46 <otlabs> confirmed! the multihashes presented in package.json are the same you see in build log
2019-03-06 21:10:49 <jwh> ..
2019-03-06 21:10:51 <jwh> I give up
2019-03-06 21:11:03 <jwh> no package it is
2019-03-06 21:11:37 <_ikke_> :(
2019-03-06 21:12:03 <jwh> fixing the build system isn't enough, exporting cxxflags isn't enough
2019-03-06 21:12:14 <jwh> but one of the builds succeeded
2019-03-06 21:12:31 <jwh> so a combination of both, but thats just using a sledgehammer
2019-03-06 21:12:52 <jwh> utterly awful project and these people should be removed from the internet
2019-03-06 21:13:06 <jwh> perhaps take their computers away
2019-03-06 21:14:03 <jwh> so, I expect the flags abuild exports is actually breaking it
2019-03-06 21:14:40 <jwh> because they're honouring the environment, but not appending their own flags
2019-03-06 21:15:13 <mps> SpaceToast: I see that you are excited about iwd :) if you have some time would you mind to skim over 'my' short note (guide) about it on Alpine
2019-03-06 21:15:15 <jwh> or... cgo flags are ignored entirely
2019-03-06 21:15:32 <SpaceToast> mps: you really need to catch me when I'm not at work ^^;;
2019-03-06 21:15:36 <SpaceToast> I recommend evening EST hours ;)
2019-03-06 21:15:50 <SpaceToast> or waiting until tomorrow, I'm off work then (unless a thing happens)
2019-03-06 21:17:14 <mps> ok, I don't force you, just to tell me if i'm on right path. see you later
2019-03-06 21:17:41 <SpaceToast> erm... it's not a question of forcing
2019-03-06 21:18:01 <SpaceToast> just give me the link when I'm not at work (and thus everything I technically do belongs to the company I work for based on local law)
2019-03-06 21:18:05 <SpaceToast> not hard :)
2019-03-06 21:18:05 <mps> of course, wrong term
2019-03-06 21:21:14 <jwh> argh
2019-03-06 21:21:19 <jwh> now it's really irritating me
2019-03-06 21:21:27 <jwh> works locally
2019-03-06 21:23:29 <jwh> broken ass crap
2019-03-06 21:24:05 <jwh> ohhhh
2019-03-06 21:24:06 <SpaceToast> 
ACTION sighs

2019-03-06 21:24:16 <SpaceToast> help this one guy on the user ML once, suddenly you have to make his package build for him
2019-03-06 21:24:19 <jwh> lol
2019-03-06 21:24:30 <SpaceToast> are you following that convo jwh? I'm getting pretty close to telling them off
2019-03-06 21:24:36 <jwh> url?
2019-03-06 21:24:49 <jwh> I'm not subbed , I rarely check my mail
2019-03-06 21:26:19 <SpaceToast> start from here http://lists.alpinelinux.org/alpine-user/0672.html
2019-03-06 21:26:34 <SpaceToast> in case following the chaotic start of the thread is hard, my first response is here http://lists.alpinelinux.org/alpine-user/0675.html
2019-03-06 21:27:29 <SpaceToast> follow up (finally in a stable manner) in 0700
2019-03-06 21:28:38 <jwh> lol
2019-03-06 21:29:07 <jwh> lesson learnt, don't engage D
2019-03-06 21:29:08 <jwh> :D*
2019-03-06 21:29:37 <SpaceToast> eh, it's my usual nervous tic
2019-03-06 21:30:02 <SpaceToast> when someone fails to represent reality appropriately, I get all flustered and try to correct the stability of the universe
2019-03-06 21:30:09 <SpaceToast> at the expense of my own ^^
2019-03-06 21:30:46 <jwh> lol
2019-03-06 21:30:54 <jwh> fair enough
2019-03-06 21:31:18 <jwh> sounds exhausting though :)
2019-03-06 21:36:29 <SpaceToast> tad bit
2019-03-06 22:47:39 <otlabs> Ok guys, need to go, thank you all for your attention and help! It was so interesting day! Bye
2019-03-06 22:58:45 <jwh> >>> cockroach: Build complete at Wed, 06 Mar 2019 22:54:54 +0000 elapsed time 0h 3m 28s
2019-03-06 22:58:48 <jwh> sigh
2019-03-06 22:59:43 <SpaceToast> \o/
2019-03-06 23:18:57 <jwh> SpaceToast: not sure about \o/ yet - its the same args my PR has heh
2019-03-06 23:19:12 <jwh> >>> cockroach: Package size: 93.0 MB
2019-03-06 23:19:15 <jwh> not absurd
2019-03-06 23:19:28 <SpaceToast> algitbot says it's a \o/ anyway therefore it's a \o/ :)
2019-03-06 23:19:33 <jwh> lol
2019-03-06 23:20:03 <SpaceToast> I am intimately familiar with the concept of abandoning something due to not seeing any progress, so seeing progress (even if it isn't completion) is good
2019-03-06 23:20:20 <jwh> you know when something really gets under your skin?
2019-03-06 23:20:22 <jwh> that
2019-03-06 23:21:27 <SpaceToast> golang got under your skin days ago, yes
2019-03-06 23:21:44 <jwh> lol
2019-03-06 23:21:59 <jwh> pure golang would be less terrible without these horrible build systems :D
2019-03-06 23:22:25 <SpaceToast> ah, but the build system is built into the language
2019-03-06 23:22:29 <SpaceToast> also see // #cgo
2019-03-06 23:22:31 <jwh> lol
2019-03-06 23:22:33 <jwh> yes
2019-03-06 23:22:36 <jwh> seen it, doesn't work :DD
2019-03-06 23:32:33 <jwh> SUCCESS
2019-03-06 23:32:40 <jwh> drone builder is happy
2019-03-06 23:34:09 <SpaceToast> \o/
2019-03-06 23:35:05 <jwh> "release" build is still 93MB, pretty ridiculous
2019-03-06 23:35:37 <SpaceToast> 1. you might be skipping stripping (it's a specific step)
2019-03-06 23:35:43 <SpaceToast> 2. it's statically linked (which can inflate size)
2019-03-06 23:35:56 <SpaceToast> 3. it's golang (which means there's a lot of crap being thrown into the binary, which is statically linked)
2019-03-06 23:36:08 <SpaceToast> so it's not actually as bad as you might think
2019-03-06 23:36:25 <jwh> well
2019-03-06 23:36:26 <SpaceToast> k3s is just under 40mb, for example
2019-03-06 23:36:28 <mps> golang prefers static linking
2019-03-06 23:36:29 <jwh> I shaved like 60MB  off lxd
2019-03-06 23:36:39 <jwh> on glibc, but still
2019-03-06 23:36:52 <jwh> saved 30MB so far by stripping
2019-03-06 23:36:56 <SpaceToast> speaking of, now that lxd is fixed in 3.11 (according to you), arch package? :)
2019-03-06 23:37:08 <jwh> 3.10 works on arch :D
2019-03-06 23:37:16 <jwh> I've pestered, he's being ultra slack
2019-03-06 23:37:18 <SpaceToast> sure, I mean main repos ;)
2019-03-06 23:37:37 <jwh> I ask him and he just insults me now :D
2019-03-06 23:39:32 <SpaceToast> hmm, who's he?
2019-03-06 23:39:38 <SpaceToast> I've only really ever interacted with Eli
2019-03-06 23:39:44 <SpaceToast> who was quite nice :)
2019-03-06 23:40:14 <jwh> alad, eli is far too busy to pander to my demands
2019-03-06 23:40:32 <SpaceToast> he's busy looking over my stupid patches to pacman ;)
2019-03-06 23:40:44 <SpaceToast> well, patch, and not since merging it
2019-03-06 23:40:51 <jwh> heh
2019-03-06 23:41:34 <jwh> have you given 3.11 the once over on alpine yet?
2019-03-06 23:41:50 <SpaceToast> nope, I'm not the maintainer, and it didn't change anything I care about
2019-03-06 23:41:54 <jwh> I've only checked if it starts, been too busy messing about with this nonsense
2019-03-06 23:42:08 <SpaceToast> oh, fcolista got it updated already, nice!
2019-03-06 23:42:14 <SpaceToast> I'll upgrade it tomorrow, I guess :)
2019-03-06 23:42:15 <jwh> oh cool
2019-03-06 23:43:27 <SpaceToast> anyways, time for me to go
2019-03-06 23:43:34 <SpaceToast> EOD, and I have that sangria in the new place to try out
2019-03-06 23:45:00 <jwh> lol, enjoy
2019-03-06 23:45:23 <jwh> ah packaged later hopefully, so soon (tm)
2019-03-07 00:17:40 <jwh> https://github.com/alpinelinux/aports/pull/6564
2019-03-07 00:17:42 <jwh> :D
2019-03-07 00:27:06 <vkrishn> would be nice to have http://people.csail.mit.edu/jaffer/SLIB alongwith guile
2019-03-07 03:15:04 <SpaceToast> Ping ddevault - isn't removing mongo at this stage a bit premature? OSI is still going through it, as of currently. (A decision was due Feb 22, but to the extent of my knowledge it never came, meaning it's deferred another 30 days). I would wait until the revision and review process settles out. However, it obviously isn't free (potentially yet). Perhaps it should be moved to non-free/ in the interim?
2019-03-07 03:17:22 <ddevault> SpaceToast: well, fedora axed it, and the FSF hasn't reviewed it yet either, and imo mongo is acting in bad faith and doesn't deserve the benefit of the doubt
2019-03-07 03:17:41 <ddevault> but we can just leave that patch floating until they figure it out, if you think that wise
2019-03-07 03:17:50 <SpaceToast> I'm ok with that too
2019-03-07 03:18:01 <SpaceToast> also to be noted is my personal opinion, on the matter, I suppose
2019-03-07 03:18:20 <SpaceToast> I don't see any significant difference between the SSPL and various GPL variants - it's "free as long as you do this"
2019-03-07 03:18:39 <SpaceToast> so my PoV is if the OSI is fine with GPL, AGPL and so on, they should (assuming consistency) be fine with the SSPL
2019-03-07 03:19:25 <SpaceToast> (in short, I expect significant fallout from these events, and thus don't want to jump the gun on widespread actions)
2019-03-07 10:16:13 <danieli> ncopa: CVE-2019-5786 (chrome-0day) is apparently being exploited in the wild
2019-03-07 10:16:21 <danieli> it applies to chromium
2019-03-07 10:17:07 <_ikke_> yes, you are advised to upgrade immediately
2019-03-07 10:18:16 <danieli> specifically to 72.0.3626.121
2019-03-07 10:18:43 <danieli> ours is at 72.0.3626.109 in edge
2019-03-07 10:19:01 <danieli> edge and 3.9*
2019-03-07 10:59:34 <rnalrd> trying the new build pushing soon hopefully danieli
2019-03-07 10:59:51 <danieli> :)
2019-03-07 11:46:32 <ncopa> hi
2019-03-07 11:46:41 <ncopa> im gonna update nodejs
2019-03-07 11:51:24 <ncopa> seems like http-parser was updated so nodejs is currently broken
2019-03-07 12:38:17 <rnalrd> ncopa, yes tnx
2019-03-07 12:42:55 <mps> how long to wait for answer to mail from maintainer of the package?
2019-03-07 12:43:34 <andypost[m]> ncopa, also https://github.com/alpinelinux/aports/pull/6482 could be applied
2019-03-07 12:45:18 <ncopa> andypost[m]: im working on it as we speak. build fails for some reason
2019-03-07 12:45:35 <danieli> i saw that the drone one failed, travis in progress
2019-03-07 12:46:05 <danieli> it didn't actually error until it tries to rm the .intermediate files
2019-03-07 12:47:00 <_ikke_> mps: At least a week I guess
2019-03-07 12:47:00 <danieli> make: *** [Makefile:100: node] Error 2
2019-03-07 12:47:19 <mps> _ikke_: ok, thanks
2019-03-07 12:53:40 <ncopa> i think its the --experimental-http-parser thingy. i'll enable the --shared-http-parser again
2019-03-07 15:56:41 <ddevault> been compiling the latest chromium for 16 hours now
2019-03-07 15:56:46 <ddevault> it sure is a beast
2019-03-07 15:56:58 <_ikke_> wow
2019-03-07 15:57:05 <_ikke_> 16 hours consequtive?
2019-03-07 15:57:09 <ddevault> aye
2019-03-07 15:57:17 <ddevault> (on an 11 year old laptop)
2019-03-07 15:57:25 <ddevault> probably should have SSHed into my 32-core monster
2019-03-07 15:58:23 <_ikke_> that would help I guess
2019-03-07 16:02:07 <fabo> _ikke_: care to finish with https://github.com/alpinelinux/aports/pull/6446 ? :p
2019-03-07 16:08:28 <mps> ddevault: on risc-v?
2019-03-07 16:08:35 <_ikke_> fabo: checking
2019-03-07 16:09:02 <mps> ddevault: sorry, no 11 year old laptop have risc-v
2019-03-07 16:09:22 <mps> i misread your post
2019-03-07 16:09:23 <ddevault> no, on x86_64
2019-03-07 16:09:31 <ddevault> there's a vulnerability addressed by the latest chromium version
2019-03-07 16:09:36 <ddevault> once it finishes I'll send the patch along to aports
2019-03-07 16:09:54 <mps> I have seen you bug report
2019-03-07 16:10:07 <ddevault> I wrote a bug report?
2019-03-07 16:10:31 <mps> someone did, sorry I thougt you are
2019-03-07 16:11:58 <_ikke_> fabo: I'll fix it for you, but you have to specify options="!check" with a comment if there is no test suite
2019-03-07 16:14:32 <jwh> comments, bleh
2019-03-07 16:30:56 <fabo> _ikke_: thanks. correct, no testsuite.
2019-03-07 16:31:33 <ddevault> hah, I ended up tasking one of my remote build boxes with building chromium
2019-03-07 16:31:38 <ddevault> it should catch up with my laptop within 5 minutes
2019-03-07 17:39:26 <clandmeter> Anyone know how to get persistent ttyACM0  device name with mdev?
2019-03-07 18:16:54 <ddevault> ncopa: security patch https://patchwork.alpinelinux.org/patch/4578/
2019-03-07 18:18:23 <ddevault> I can share temporary access to my big build box if you wish as well
2019-03-07 18:19:42 <danieli> ddevault: godspeed
2019-03-07 18:25:54 <ddevault> ncopa: I have to get on an airplane but if you do want a big box to build this on, I added your github keys to ncopa@cirno.sr.ht (added clandmeter too). Please limit your build to 24 cores
2019-03-07 18:31:29 <danieli> ddevault: we have a couple fairly big build boxes from packet et. al., so no worries
2019-03-07 18:31:45 <danieli> have a safe trip
2019-03-07 18:32:17 <ddevault> coolio
2019-03-07 18:32:19 <ddevault> thanks :)
2019-03-07 18:32:42 <SpaceToast> ddevault: have a good trip, I hope it's... the strongest ;)
2019-03-07 18:32:59 <danieli> I think the dev machine I have access to has, uh
2019-03-07 18:33:00 <danieli> 48 cores
2019-03-07 18:33:16 <danieli> I have a good bunch of packages brewing there
2019-03-07 18:33:32 <SpaceToast> my @home server is 24, but double that in ram helps
2019-03-07 18:33:34 <ddevault> this box is named because it's the strongest of my boxen :)
2019-03-07 18:33:39 <SpaceToast> :)
2019-03-07 18:33:43 <danieli> 512G RAM on that 48 core box
2019-03-07 18:33:44 <ddevault> it has 32 cores, AMD EPYC
2019-03-07 18:33:53 <danieli> uh
2019-03-07 18:33:53 <danieli> 256*
2019-03-07 18:34:00 <ddevault> built chromium in 1.5 hours
2019-03-07 18:34:02 <danieli> 512 is another box
2019-03-07 18:34:13 <danieli> I can build it to check
2019-03-07 19:11:42 <otlabs> hi ppl
2019-03-07 19:12:49 <otlabs> Is it correct that drone for archv7 reports "armv8l"?
2019-03-07 19:15:38 <AinNero> via uname?
2019-03-07 19:15:50 <otlabs> via cmake
2019-03-07 19:23:59 <danieli> otlabs: we're using an aarch64 machine in 32-bit mode
2019-03-07 19:25:08 <otlabs> auch
2019-03-07 19:26:15 <clandmeter> That's correct
2019-03-07 19:26:21 <otlabs> ok
2019-03-07 19:26:36 <otlabs> what should I expect for armhf?
2019-03-07 19:27:28 <otlabs> I was expecting to get for armv7 something like: armv7|armv7f|armv7s|armv7k|armv7-a|armv7l
2019-03-07 20:09:46 <ncopa> ddevault: thank! i think it got pushed earlier today
2019-03-07 20:12:47 <danieli> just curious, why does it matter?
2019-03-07 20:39:26 <otlabs> I was preparing the package which uses cmake and depending on architecture different configurations will be applied
2019-03-07 20:40:39 <otlabs> In my particular case the package has a special configurations for aarch64 and armv7
2019-03-07 20:40:53 <otlabs> aarch64 was detected correctly
2019-03-07 20:41:09 <_ikke_> otlabs: btw, I did a little research, but found no reference to go itself using package.json
2019-03-07 20:42:49 <otlabs> armv7 had special configuration and it was never activated as cmake was seeing armv8l and default configuration was applied. It was a x86_64 config with unsupported options for arm architecture
2019-03-07 20:43:05 <otlabs> _ikke_: oh, thank you
2019-03-07 20:43:32 <otlabs> gx and gx-go use package.json
2019-03-07 20:43:33 <_ikke_> Anyone knows what the recommended way is regarding go dependencies?
2019-03-07 20:43:46 <_ikke_> otlabs: right, but that doesn't help us to build gx in the first place
2019-03-07 20:44:06 <_ikke_> or is gx already being used while building gx?
2019-03-07 20:44:57 <otlabs> _ikke_: you ask me good but quite tough questions. sorry, I have no clear answers, only my humble assumptions.
2019-03-07 20:45:08 <_ikke_> otlabs: yeah, I don't expect you to know
2019-03-07 20:45:25 <_ikke_> go is a bit of a mess regarding dependencies
2019-03-07 20:45:54 <_ikke_> from what I've read they just expect you to vendor your dependencies
2019-03-07 20:45:58 <otlabs> I assume that gx/gx-go dandem was created to solve the version control issues
2019-03-07 20:46:13 <otlabs> tandem
2019-03-07 20:46:25 <_ikke_> yes, it's a depedency manager, but you got a bootstrap problem
2019-03-07 20:46:58 <otlabs> please, do not shoot my leg, I just a piano man
2019-03-07 20:47:14 <_ikke_> Let me see if I can find how it's done in other packages
2019-03-07 20:47:33 <otlabs> the problem of a hen and the egg is not my favorite one
2019-03-07 20:47:51 <otlabs> thank you, would quite appreciate an example
2019-03-07 21:14:05 <danieli> ddevault: it built and packaged properly
2019-03-07 21:39:34 <_ikke_> andypost[m]: What do you mean here with "too many changes for a patch release. Does that refer to upstream? (https://github.com/alpinelinux/aports/pull/6196)
2019-03-07 22:18:56 <otlabs> jfyi, drone armhf reports in cmake as armv8l, same as drone armv7. I see no way how to differentiate these 2 build environments from inside.
2019-03-07 22:46:42 <otlabs> time to go, thanks for your help! cu
2019-03-07 22:47:10 <jwh> is this another case of 64bit containers?
2019-03-07 22:57:55 <jwh> is anyone planning on bumping go? coz I'll need to re-roll my latest PR if so
2019-03-08 04:52:26 <pixelherodev> Why is vsyscall emulation enabled in the Alpine kernel? musl doesn't need it, does it?
2019-03-08 06:59:02 <clandmeter> otlabs, armv8l is the proper uname for aarch64 in 32bit mode. so it should do that for both arches.
2019-03-08 07:02:30 <ncopa> pixelherodev: good question. it may be for historical reasons, and maybe to get wine working. I dont remember tbh
2019-03-08 07:02:50 <ncopa> may be an idea to disable it
2019-03-08 07:08:17 <clandmeter> _ikke_: i guess currently glide is still prefered. we need to look at go modules to use it instead.
2019-03-08 07:08:56 <clandmeter> ncopa: any comment regarding https://github.com/alpinelinux/abuild/pull/52?
2019-03-08 07:09:14 <clandmeter> i think its what you proposed to me some time ago.
2019-03-08 07:11:31 <clandmeter> ncopa: would you mind if the builders keep their own copy of go modules in $HOME or should we redirect them to src directory and refetch them everytime?
2019-03-08 07:28:49 <ncopa> re https://github.com/alpinelinux/abuild/pull/52 i looked at it the other day
2019-03-08 07:29:04 <ncopa> but i grabbed the other PRs first, which are bugfixes
2019-03-08 07:29:25 <ncopa> i think if .. fi is a bit clearer thatn the &&
2019-03-08 07:29:38 <ncopa> but does not matter that much
2019-03-08 07:29:46 <ncopa> i also like the idea that it is an option
2019-03-08 07:30:13 <ncopa> re let builders have their own copy of go modules
2019-03-08 07:30:25 <ncopa> i think that is fine
2019-03-08 07:31:00 <ncopa> the only problem i can see with it is if for some reason fetching go modules from remote fails and some builders has it in cache already
2019-03-08 07:31:23 <ncopa> then some builders may fail while others succeed
2019-03-08 07:31:48 <ncopa> but i guess it is not much different than what we do with our source cache
2019-03-08 07:32:42 <ncopa> from what I read, the go module cache should be preproducible
2019-03-08 07:34:20 <clandmeter> we probably need something to clean it up over time
2019-03-08 07:34:43 <clandmeter> but thats maybe a bit more difficult with git
2019-03-08 07:36:35 <ncopa> i wonder if we run go clean
2019-03-08 07:36:39 <ncopa> or go mod clean
2019-03-08 07:37:06 <ncopa> i think SpaceToast had an idea on a hook for cleaning stage
2019-03-08 07:38:00 <_ikke_> ncopa: I will change the PR to use if .. fi
2019-03-08 08:01:08 <clandmeter> was there a bug with apk virtuals?
2019-03-08 08:11:35 <fabo> https://bugs.alpinelinux.org/issues/5085 can be closed
2019-03-08 08:14:56 <clandmeter> fabo: can you close it yourself?
2019-03-08 08:15:02 <clandmeter> i thought we changed that
2019-03-08 08:18:49 <fabo> clandmeter: I don't see any ways to close it, so it seems I lack permissions to do so
2019-03-08 08:19:01 <clandmeter> ok ill close it thx :)
2019-03-08 08:19:12 <clandmeter> _ikke_: was my assumption wrong?
2019-03-08 08:32:05 <fabo> clandmeter: you can close 7124 8385 too
2019-03-08 08:50:11 <clandmeter> fabo: bugs.a.o?
2019-03-08 08:50:51 <_ikke_> clandmeter: Let me check
2019-03-08 08:51:50 <_ikke_> clandmeter: I only updated the bug tracker, not the feature tracker
2019-03-08 08:52:14 <clandmeter> i guess we can allow everyone to close their items
2019-03-08 08:52:45 <_ikke_> Right, from all statuses?
2019-03-08 08:53:14 <clandmeter> i think so?
2019-03-08 09:06:59 <ncopa> pixelherodev: re CONFIG_LEGACY_VSYSCALL_EMULATE: https://bugs.archlinux.org/task/57462
2019-03-08 09:07:11 <ncopa> we have it enabled and CONFIG_LEGACY_VSYSCALL_NONE=y
2019-03-08 09:07:41 <ncopa> so you will have to add a boot option to actually enable the emulate
2019-03-08 09:10:20 <clandmeter> ncopa: cant we add deps to virtuals afterwards?
2019-03-08 09:11:42 <ncopa> append deps? no. i think its a bug in apk
2019-03-08 09:12:08 <ncopa> #9957
2019-03-08 09:13:11 <clandmeter> ah right thx
2019-03-08 09:13:18 <clandmeter> i thought it saw it somewhere
2019-03-08 09:18:19 <_ikke_> clandmeter: I've updated it for all trackers to be the same
2019-03-08 09:18:29 <clandmeter> thx!
2019-03-08 09:21:10 <_ikke_> Does this make sense? https://imgur.com/a/ZUiQt7N
2019-03-08 09:27:43 <clandmeter> thats a lot of options
2019-03-08 09:27:50 <clandmeter> but from scanning it looks ok
2019-03-08 09:29:17 <_ikke_> redmine allows for a lot of flexibility in its workflow, but that also requires you to properly configure ti
2019-03-08 09:29:42 <_ikke_> You can apparently even specify what fields they are allowed to modify
2019-03-08 09:54:57 <ncopa> calndmeter: re https://dup.pw/aports/f93ae82b0e9182dc4e903e73e9ac925f6d0614f5
2019-03-08 09:55:16 <ncopa> https://git.alpinelinux.org/aports/commit/?id=f93ae82b0e9182dc4e903e73e9ac925f6d0614f5
2019-03-08 09:55:42 <ncopa> clandmeter: re wireguard-rpi: has Stuard said he wants maintain it?
2019-03-08 09:56:14 <ncopa> im pushing 4.19.27 kernel now and i wonder if i need to test rebuild 3rd party modules for rpi too now
2019-03-08 09:56:21 <ncopa> or if i should just let it rot there
2019-03-08 09:56:57 <clandmeter> hmm, i thought you bumped 3rd party modules
2019-03-08 09:57:18 <ncopa> i do normally do when i push new kernel
2019-03-08 09:57:35 <ncopa> rpi has been sort of easy due to it had no 3rdpary mods
2019-03-08 09:58:04 <ncopa> so i wonder if I should do the extra work with 3rd party mods like i do for linux-vanilla
2019-03-08 09:58:07 <clandmeter> well i thought as it follows the other wg modules it wouldnt be an issue.
2019-03-08 09:58:34 <ncopa> no, it follws the kernel it is compiled against
2019-03-08 09:58:39 <clandmeter> i didnt really look into the consequences
2019-03-08 09:58:57 <ncopa> so if rpi kernel is bumped the 3rd party mods for it needs to be rebuilt
2019-03-08 09:59:38 <clandmeter> im not following here
2019-03-08 09:59:53 <clandmeter> you ask me to ask stuard if he wants to maintain it, but you bump them?
2019-03-08 10:00:08 <ncopa> i ask because he is listed as maintainer for that package
2019-03-08 10:00:22 <ncopa> for wireguard-rpi
2019-03-08 10:00:51 <clandmeter> i thought we kind of officially support rpi
2019-03-08 10:00:59 <ncopa> we do
2019-03-08 10:01:00 <clandmeter> so why support moduels for one kenrel and not the other
2019-03-08 10:01:37 <ncopa> because it increases maintenance work
2019-03-08 10:01:48 <clandmeter> does it in this case?
2019-03-08 10:02:04 <clandmeter> i mean i understand your point
2019-03-08 10:02:06 <ncopa> yes, thats why im asking who will do the extra work
2019-03-08 10:02:22 <clandmeter> i thought it was a simple script you used
2019-03-08 10:02:45 <clandmeter> its nice that its all documented ;-)
2019-03-08 10:03:09 <ncopa> but i still need to start it and do the test run and do the push
2019-03-08 10:03:29 <ncopa> for rpi i dont push from my armv7, i trasnfer the commit to x86_64
2019-03-08 10:03:46 <ncopa> now i need to remember to do that with the extra 3rd aprty modules
2019-03-08 10:03:54 <clandmeter> well we have drone
2019-03-08 10:04:20 <clandmeter> im trying to understand the issue
2019-03-08 10:04:20 <ncopa> it is not much extra work
2019-03-08 10:04:30 <ncopa> but it is currently extra work
2019-03-08 10:04:41 <clandmeter> im ok if you want to remove it.
2019-03-08 10:05:06 <ncopa> and even if it is not much, this little extra work needs to be done every single time there is a kernel version, and potensially * number of supported branches
2019-03-08 10:05:11 <clandmeter> i added it because it was a bit weird we have it but not for rpi kernel.
2019-03-08 10:05:17 <clandmeter> fcolista needed it.
2019-03-08 10:05:39 <ncopa> so worst case scenario
2019-03-08 10:06:13 <ncopa> there is an emergency security issue in wireguard so we need push a security fix immediately
2019-03-08 10:06:51 <ncopa> 3 kernel flavors * 5 maintained branches
2019-03-08 10:06:58 <ncopa> we need fix it 15 places
2019-03-08 10:07:08 <ncopa> if every takes 10 mins
2019-03-08 10:07:22 <clandmeter> but its testing right?
2019-03-08 10:07:23 <ncopa> its 150 mins needed for this simple 1mins fix
2019-03-08 10:07:35 <ncopa> yes
2019-03-08 10:08:08 <clandmeter> so i dont see the relation to branches
2019-03-08 10:08:34 <ncopa> im just saying what happens if it is moved to main
2019-03-08 10:08:53 <clandmeter> we know in this case that wont happen.
2019-03-08 10:09:00 <ncopa> ok
2019-03-08 10:09:09 <clandmeter> well i guess stable means merged into kernel
2019-03-08 10:09:19 <ncopa> i think that is his goal
2019-03-08 10:09:38 <clandmeter> but yes, if we move it earlier then it could happen.
2019-03-08 10:09:47 <clandmeter> but you said you dont want that.
2019-03-08 10:09:58 <clandmeter> i think the request will increase
2019-03-08 10:10:10 <ncopa> ok. my real question is. the little extra work needed to maintain wireguard-rpi, am I expected to do that or should I expect Stuard (official maintainer) to do it
2019-03-08 10:10:24 <clandmeter> :)
2019-03-08 10:10:30 <clandmeter> finally the million dollar question
2019-03-08 10:10:34 <ncopa> testing/wireguard-rpi that is
2019-03-08 10:10:37 <ncopa> yup :)
2019-03-08 10:10:46 <clandmeter> tbh, i think he should.
2019-03-08 10:10:59 <clandmeter> for sure now we have drone to test it
2019-03-08 10:11:25 <mps> what about add wireguard patch to kernel?
2019-03-08 10:11:43 <clandmeter> it would mean even more work i think
2019-03-08 10:11:45 <ncopa> so my next question is: did you ask him? I ask because i see that the commit was from you
2019-03-08 10:11:56 <clandmeter> i didnt talk to him
2019-03-08 10:12:27 <clandmeter> but thats because i know you bump them.
2019-03-08 10:12:52 <ncopa> so I was expected to take care of it... :)
2019-03-08 10:12:55 <clandmeter> should i create a ticket, or what do you want?
2019-03-08 10:13:12 <clandmeter> i think fcolista should do it, its for him ;-)
2019-03-08 10:13:27 <ncopa> yeah, thats probably better
2019-03-08 10:13:35 <clandmeter> or mps, cause he complains about it all the time ;-)
2019-03-08 10:13:58 <mps> clandmeter: ime, it is not hard to create wireguard patch, I do it in script for all my ARM boxes
2019-03-08 10:14:02 <ncopa> tbh, i think it is responsibility of the rpi kernel maintainer
2019-03-08 10:14:15 <ncopa> its similar to shared libs
2019-03-08 10:14:37 <ncopa> if you push update that require rebuilds, then it is the person who pushes the update who should make sure that happens, right?
2019-03-08 10:14:59 <clandmeter> sounds sane
2019-03-08 10:15:30 <mps> clandmeter: I would, but I don't have rpi's
2019-03-08 10:15:40 <clandmeter> the problem is, not many ppl want to maintain the kernel.
2019-03-08 10:15:46 <clandmeter> i only know of one person
2019-03-08 10:15:52 <ncopa> :)
2019-03-08 10:16:02 <ncopa> because it it requires some work
2019-03-08 10:16:12 <clandmeter> thats why i got crazu with rpi
2019-03-08 10:16:15 <clandmeter> and added that patch
2019-03-08 10:16:23 <clandmeter> to follow upstream
2019-03-08 10:18:10 <clandmeter> so the issue only got complexer now?
2019-03-08 10:18:45 <clandmeter> you are the maintainer of the rpi kernel
2019-03-08 10:19:01 <ncopa> yes. i failed to run away from responsibility
2019-03-08 10:19:16 <ncopa> and my abump-kmods script apparently does not work with linux-rpi
2019-03-08 10:19:25 <ncopa> so i need spend time on fixing it
2019-03-08 10:20:06 <clandmeter> 
ACTION looks into fcolista direction 

2019-03-08 10:20:11 <mps> linux-rpi is for old armv6 rpi?
2019-03-08 10:20:43 <clandmeter> its for first gen rpi yes
2019-03-08 10:20:57 <ncopa> and for rpi3, the aarch64
2019-03-08 10:21:10 <clandmeter> i think thats rpi2 kernel
2019-03-08 10:21:24 <ncopa> i think its linux-rpi aarch64
2019-03-08 10:21:31 <ncopa> but i dont remember
2019-03-08 10:21:51 <clandmeter> i do  :)
2019-03-08 10:24:29 <clandmeter> ncopa: and i bet you, rpi4 will introduce rpi3 kernel.
2019-03-08 10:25:28 <clandmeter> at least what i read is it will be a big change for the device.
2019-03-08 10:26:14 <ncopa> i feel like im working in mud, which gets thicker and thinker
2019-03-08 10:26:34 <ncopa> my daily work slowly gets heavier and heavier
2019-03-08 10:27:15 <ncopa> i guess i should stop complain and just work harder
2019-03-08 10:27:38 <clandmeter> i wonder if sig's would help in this case
2019-03-08 10:27:42 <clandmeter> better org structure
2019-03-08 10:27:57 <ncopa> re https://github.com/alpinelinux/aports/pull/6482 i have no clue why it fails to build
2019-03-08 10:28:07 <ncopa> any volunteer to work on it?
2019-03-08 10:28:58 <ncopa> i need move documentation from gliderlabs/docker-alpine to alpinelinux/docker-alpine
2019-03-08 10:30:16 <ncopa> and i promised to clean up ceph and move it to community, this week
2019-03-08 10:30:24 <clandmeter> UV_MAXHOSTNAMESIZE
2019-03-08 10:30:49 <ncopa> so if someone else want to work on nodejs-current let me know, i have some progress
2019-03-08 10:30:51 <ncopa> work in progress
2019-03-08 10:32:17 <ncopa> i think the U_MAXHOSTNAMESIZE was fixed with the libuv update i pushed the other day
2019-03-08 10:32:45 <clandmeter> ok restarting the build
2019-03-08 10:32:47 <clandmeter> lets see
2019-03-08 10:33:11 <clandmeter> ncopa: i guess you are also allowed  to restart builds?
2019-03-08 10:33:19 <ncopa> $ git format-patch --stdout -1 HEAD^^ | tpaste
2019-03-08 10:33:19 <ncopa> http://tpaste.us/M5XX
2019-03-08 10:33:21 <clandmeter> in drone
2019-03-08 10:33:25 <ncopa> dunno
2019-03-08 10:33:34 <clandmeter> should be  a button on top of the log
2019-03-08 10:33:44 <clandmeter> i guess its related to github permissions
2019-03-08 10:34:31 <ncopa> this is the WIP: https://tpaste.us/0LJ1
2019-03-08 10:34:54 <ncopa> we could probably use the shared http-parser
2019-03-08 10:35:26 <clandmeter> i wont be behind keyboard for long. have a nice 4h lunch coming :)
2019-03-08 10:36:32 <ncopa> hmmm maybe its the shared http-parser that is the problem
2019-03-08 10:36:53 <clandmeter> it builds fine now
2019-03-08 10:37:02 <ncopa> ok
2019-03-08 10:37:29 <ncopa> then it was the shared http-parser that i reintroduced when i tried to fix the other issue
2019-03-08 10:38:43 <ncopa> doh
2019-03-08 10:44:13 <clandmeter> https://cloud.drone.io/alpinelinux/aports/353 all green lights
2019-03-08 11:13:18 <fcolista> clandmeter, hi!
2019-03-08 11:15:15 <fcolista> saw the thread, jsut back in the office right now
2019-03-08 11:16:27 <fcolista> so, what can I do?
2019-03-08 11:17:31 <fcolista> I think that the rpi stuff should be refactored or re-engineerd, since i don't want to have $package-rpi[2345n]
2019-03-08 11:17:48 <fcolista> for every rpi that will be shipped
2019-03-08 13:42:18 <nmeum> I am planning on upgrading openrc soonish, in case somebody wants to test it: https://github.com/alpinelinux/aports/pull/6573
2019-03-08 13:42:18 <nmeum> Unless they are any complaints I will probably push it this weekend
2019-03-08 13:43:27 <ncopa> nmeum: great!
2019-03-08 13:43:38 <jwh> hm
2019-03-08 13:43:54 <ncopa> maybe prefix the PR with "WIP" so nobody pushes it by mistake
2019-03-08 13:44:12 <_ikke_> github has draft PRs now
2019-03-08 13:44:19 <ncopa> right
2019-03-08 13:44:22 <jwh> builddir is giving me grief
2019-03-08 13:44:29 <nmeum> ncopa: good idea, will do that
2019-03-08 13:46:29 <jwh> so if I cd to the builddir it succeeds, but it can't figure it out on its own
2019-03-08 13:46:36 <jwh> redundant prepare() it is
2019-03-08 13:47:59 <jwh> couldn't abuild be taught how to figure it out if its the same as the source?
2019-03-08 13:49:44 <jwh> like if the source is $pkgname-$pkgver.whatever::, [ -d $srcdir/$pkgname-$pkgver ] might be a good default?
2019-03-08 13:50:12 <ncopa> i think it is default already
2019-03-08 13:50:51 <jwh> hm, it's not working here, if cd $srcdir/$pkgname-$pkgver exists in prepare() it succeeds, but otherwise it gets upset
2019-03-08 13:51:05 <jwh> hm
2019-03-08 13:51:06 <ncopa> what is your builddir set to
2019-03-08 13:51:10 <jwh> none :P
2019-03-08 13:51:21 <jwh> set it now, just thought it might be able to figure it out itself
2019-03-08 14:39:14 <SpaceToast> ncopa: I had a patch re: go modules in the -devel ML
2019-03-08 14:39:50 <SpaceToast> One part fixed some DRY violations, and the second added a default_clean so it could be overwritten (and reused)
2019-03-08 14:39:57 <SpaceToast> I think I had an example around somewhere
2019-03-08 14:40:10 <_ikke_> What thread?
2019-03-08 14:45:01 <SpaceToast> Let me see if I can find it, it's kind of been a while, and it got buried
2019-03-08 14:46:15 <SpaceToast> _ikke_: http://lists.alpinelinux.org/alpine-devel/6374.html
2019-03-08 14:46:23 <SpaceToast> + following email (part 2 of patch)
2019-03-08 14:47:57 <_ikke_> Ah, I guess it has a similar goal as my PR? https://github.com/alpinelinux/abuild/pull/52
2019-03-08 14:49:28 <_ikke_> yours allows you to customize the behavior
2019-03-08 14:50:03 <SpaceToast> Yes, so there's no overhead for "normal packages" (not even to check for an option)
2019-03-08 14:50:14 <SpaceToast> And it accounts for other potential special cases
2019-03-08 14:51:11 <SpaceToast> The first part of my patch makes sense in general though, I just threw it in there since that general part of the code was being touched
2019-03-08 15:20:23 <ncopa> SpaceToast: i saw the patch in ML but sort of liked _ikke_s variant better
2019-03-08 15:20:42 <ncopa> but it may make sense to implement it as hook
2019-03-08 15:20:55 <ncopa> i mean, it may be useful to have a hook for other things
2019-03-08 15:21:05 <ncopa> so i have no strong opinions either way
2019-03-08 15:21:20 <SpaceToast> ncopa: ok, how about the first part?
2019-03-08 15:27:09 <_ikke_> I think the deduplication of logic makes sense
2019-03-08 16:14:18 <mps> which kernel version is planned for next stable, 4.19 or newer
2019-03-08 16:20:53 <SpaceToast> I hope 5.0 or higher, since swapfile support on btrfs is a very big nice-to-have
2019-03-08 16:23:05 <mps> will the 5.0 be LTS
2019-03-08 16:28:32 <jwh> probably not
2019-03-08 16:28:49 <jwh> likely 5.2
2019-03-08 16:29:05 <jwh> uh, 5.1
2019-03-08 18:00:32 <ScrumpyJack> opensmtpd only supports libressl in the last update. that won't build on alpine linux any more
2019-03-08 18:05:37 <danieli> ouch.. that's not good
2019-03-08 18:07:44 <SpaceToast> we still have a libressl package, right?
2019-03-08 18:07:55 <danieli> conflicts with openssl
2019-03-08 18:08:01 <SpaceToast> hmm
2019-03-08 18:08:18 <danieli> and we build all the stuff against openssl, so if you need opensmtpd, a lot of other stuff will break
2019-03-08 18:08:25 <SpaceToast> mhm
2019-03-08 18:08:33 <SpaceToast> time to figure out switching, I guess :/
2019-03-08 18:13:40 <jwh> private library?
2019-03-08 18:14:08 <jwh> can always just install non-default ssl libraris under another path and link applications that can't be built against openssl there
2019-03-08 18:14:51 <ScrumpyJack> isn't the openssl package just libressl?
2019-03-08 18:15:13 <jwh> umm, no?
2019-03-08 18:15:15 <jwh> :D
2019-03-08 18:16:46 <SpaceToast> we moved back to openssl in the latest release
2019-03-08 18:16:59 <SpaceToast> libressl was breaking too many things, and its peculiarities kept getting harder and harder to deal with
2019-03-08 18:17:06 <ScrumpyJack> sorry, yes i got that the wrong way round :)
2019-03-08 18:17:49 <ScrumpyJack> https://ilet.to/5PYz
2019-03-08 18:19:59 <ScrumpyJack> and here https://poolp.org/posts/2018-11-03/opensmtpd-released-and-upcoming-filters-preview/ :(
2019-03-08 18:20:59 <ScrumpyJack> opensmtpd changelog: "OpenSMTPD now depends on LibreSSL as an SSL library and efforts will no longer be done to accomodate both OpenSSL and LibreSSL"
2019-03-08 18:22:02 <danieli> so it's not immediately broken, but the less libressl conforms to openssl APIs, the harder it'll be for us to support opensmtpd
2019-03-08 18:24:50 <ScrumpyJack> it's immediatly broken: "This allowed me to start removing ifdefs from our code"
2019-03-08 18:25:08 <SpaceToast> :D
2019-03-08 18:26:26 <danieli> oops
2019-03-08 18:26:43 <SpaceToast> I mean, I understand the desire to remove ifdefs and drop support for things you don't care about
2019-03-08 18:27:42 <ScrumpyJack> i just tried building opensmtpd but it failed beyond my patching skills https://ilet.to/4Mpz
2019-03-08 22:05:32 <_ikke_> Any objection in applying this? It seems it has been a revived aport. https://github.com/alpinelinux/aports/pull/6092/files
2019-03-09 01:09:50 <ddevault> ncopa: have you given any attempts at glib 2.60.0? the switch to meson screwed some stuff up
2019-03-09 10:05:01 <AinNero> did someone just pull musl 1.1.21 ?
2019-03-09 10:06:10 <AinNero> oh, my fault
2019-03-09 10:09:42 <_ikke_> libzookeper gives this error on ppc64le: https://github.com/alpinelinux/aports/pull/6595#issue-259640049 Is there a better way then to just silence all errors on all platforms?
2019-03-09 10:16:11 <AinNero> https://www.virustotal.com/#/file/a9f4537b7b514d57f4857496089c29f7df9d50ed61baec1906249b8de9249020/detection
2019-03-09 10:16:14 <AinNero> https://www.virustotal.com/#/file/42a0167325aaa5308e8f56cdfbfe3693fbceb49ab6514e6cd7048b9991353847/detection
2019-03-09 10:16:18 <AinNero> seems like some people dont like our ldso
2019-03-09 16:46:40 <_ikke_> I've pushed libzookeeper r1 to master, but the builders do not seem to pick it up as a new version to build
2019-03-09 16:46:53 <_ikke_> http://dup.pw/aports/d241bac7
2019-03-09 16:48:01 <_ikke_> Anything I'm doing wrong?
2019-03-10 07:43:42 <danieli> judging by python issue 32002, I'm getting a nasty feeling we're gonna have to disable test_c_locale_coercion
2019-03-10 07:46:23 <R3d_Sky> uh, thats a 404
2019-03-10 07:46:32 <danieli> *python* issue, not alpine issue
2019-03-10 07:46:35 <danieli> that's just the bot being stupid
2019-03-10 07:46:41 <R3d_Sky> ohh
2019-03-10 07:47:28 <R3d_Sky> ye, I just disabled that and it worked out for me
2019-03-10 07:50:32 <R3d_Sky> danieli: I'm a bit confused right now - there's 475 py3-* packages in the repos but then only 48 in aports
2019-03-10 07:51:08 <danieli> probably because the py-* APKBUILDs in aports generates both py2- and py3- packages
2019-03-10 07:51:40 <R3d_Sky> ah
2019-03-10 07:52:13 <danieli> I see 737 py-* packages in aports in total
2019-03-10 07:52:19 <danieli> 48 py3-
2019-03-10 07:52:39 <R3d_Sky> ah
2019-03-10 07:56:07 <R3d_Sky> so someone has to check each of those things for breaks? thats gonna take a while
2019-03-10 07:56:11 <danieli> indeed
2019-03-10 07:56:20 <danieli> that's why we've postponed it, it'll have to be a bigger project
2019-03-10 07:56:42 <R3d_Sky> well you can cross py-pygments off the list
2019-03-10 07:57:22 <R3d_Sky> I'm pretty much out of work since my main dev PC broke and I can't do anything very serious on the Pi3
2019-03-10 08:03:29 <danieli> wonder if python patched CVE-2019-5010 in one of the later releases (if I can omit the patch or not)
2019-03-10 08:04:18 <R3d_Sky> well - I checked debian and they still include the patch in the 3.7.2 build
2019-03-10 08:04:30 <R3d_Sky> and 3.7.2 was released before the CVE
2019-03-10 08:04:44 <danieli> good to know, I'm semi-preoccupied, thanks :)
2019-03-10 08:05:08 <R3d_Sky> np
2019-03-10 08:05:32 <R3d_Sky> do the py-* packages have unit tests?
2019-03-10 08:05:50 <R3d_Sky> if they do I could write up a script that would compile each one of them, but
2019-03-10 08:06:48 <R3d_Sky> nope
2019-03-10 08:07:06 <R3d_Sky> danieli: I have too much time to waste, is it good enough if each one of those packages compile
2019-03-10 08:32:47 <_ikke_> R3d_Sky: if they have unittests, the APKBUILD should have a check() function
2019-03-10 09:00:19 <R3d_Sky> _ikke_: unfortunately, no check function
2019-03-10 09:01:03 <_ikke_> which package?
2019-03-10 09:01:15 <R3d_Sky> most of the py-* packages
2019-03-10 09:01:23 <R3d_Sky> trying to upgrade to py3.7 here
2019-03-10 09:02:05 <R3d_Sky> because there's an issue with upstream libpython3.6m.so that causes segfaults in python3 and gdb on the pi3
2019-03-10 09:02:41 <R3d_Sky> tested compiling 3.7 and python3 and gdb now work
2019-03-10 09:03:17 <R3d_Sky> from what I've heard from danieli the py3.7 upgrade work was deferred due to needing to test lots of py3-* packages
2019-03-10 09:04:28 <danieli> not just testing, but fixing
2019-03-10 09:04:33 <danieli> i know that many of them will break with python 3.7
2019-03-10 09:05:06 <danieli> I'd say python 3.7 /most likely/ is not landing until 3.10
2019-03-10 09:06:54 <_ikke_> There is no doubt
2019-03-10 09:07:11 <_ikke_> 3.9 only gets bug fixes and security fixes
2019-03-10 09:07:14 <_ikke_> no breaking changes
2019-03-10 09:07:53 <danieli> :)
2019-03-10 09:08:18 <danieli> edge though.. edge breaks on occasion, some times intentionally - it's the development branch
2019-03-10 09:09:09 <R3d_Sky> I'm writing a script that should automate attempting builds on all packages that depend on python3-dev
2019-03-10 09:09:16 <R3d_Sky> not sure what that'll do
2019-03-10 09:10:15 <_ikke_> "async and await are now reserved keywords." This is one of the backwards incompattible changes
2019-03-10 09:10:39 <danieli> indeed
2019-03-10 09:10:44 <danieli> that'll break quite a few things
2019-03-10 09:10:56 <danieli> already has for me on arch, had to pin myself to 3.6
2019-03-10 09:11:06 <_ikke_> ah, didn't run into that yet
2019-03-10 09:11:10 <_ikke_> what broke for you>
2019-03-10 09:11:12 <_ikke_> ?
2019-03-10 09:11:33 <danieli> a good handful of aio-packages broke when python threw a fit about async/await keywords
2019-03-10 09:11:41 <danieli> they're probably updated by now though
2019-03-10 09:19:47 <R3d_Sky> I'd say they would probably be updated?
2019-03-10 09:20:37 <danieli> it's irrelevant to the python-3.7-in-alpine situation but yeah, point is that it was a breaking change
2019-03-10 09:21:56 <_ikke_> Maybe we devide the work
2019-03-10 09:24:51 <_ikke_> s/dev/div/
2019-03-10 09:24:51 <alpine-meetbot> _ikke_ meant to say: Maybe we divide the work
2019-03-10 09:25:31 <R3d_Sky> i'm willing to help
2019-03-10 09:25:42 <R3d_Sky> I'm just not sure what exactly I can/should do
2019-03-10 09:30:02 <danieli> well, I suggest we first push python 3.7.2 with test_c_locale_coercion disabled, APKBUILD @ http://tpaste.us/YMeg
2019-03-10 09:30:04 <danieli> then work from there
2019-03-10 09:30:18 <danieli> I'd prefer ncopa to take charge on that one though, python is quite important to a lot of things
2019-03-10 09:30:38 <danieli> oh right, I forgot the CVE fix, that 3.7.2 APKBUILD is from before it was patched
2019-03-10 09:30:53 <danieli> *** DO NOT *** use that pasted APKBUILD
2019-03-10 09:32:52 <_ikke_> we can create a shared branch where we combine the work
2019-03-10 09:33:26 <danieli> +1
2019-03-10 09:39:38 <R3d_Sky> +1
2019-03-10 09:40:09 <_ikke_> what are your github usernames?
2019-03-10 09:41:24 <danieli> dunielpls
2019-03-10 09:41:51 <danieli> man, my github is pretty much deserted after using so many private git instances
2019-03-10 09:42:55 <_ikke_> https://github.com/Ikke/aports/tree/update-python-3.7
2019-03-10 09:44:17 <R3d_Sky> Oxylibrium
2019-03-10 09:45:19 <_ikke_> ok, you've been invited to my fork :)
2019-03-10 09:47:41 <_ikke_> danieli: so about that CVE patch, do we have one for 3.7?
2019-03-10 09:48:19 <R3d_Sky> the existing patch compiles, though I'm not sure if it still does what its supposed to
2019-03-10 09:48:32 <danieli> _ikke_: no, but I'll test it in a sec
2019-03-10 09:48:41 <danieli> existing patch probably doesn't have to be rebased to fit
2019-03-10 09:49:03 <_ikke_> ok
2019-03-10 09:49:20 <_ikke_> So I guess the first commit for that branch is to update python to 3.7
2019-03-10 09:52:28 <_ikke_> and what's the issue with test_c_locale_coercion?
2019-03-10 09:52:43 <R3d_Sky> doesnt work when LC_CTYPE!='C' IIRC
2019-03-10 09:52:51 <R3d_Sky> and its another musl locale deficiency
2019-03-10 09:53:00 <danieli> most likely something to do with musl sucking at locales
2019-03-10 09:53:12 <danieli> it's pretty much PEP 538
2019-03-10 09:53:17 <R3d_Sky> ye
2019-03-10 09:53:41 <R3d_Sky> also I just checked and clear linux uses the same CVE patch
2019-03-10 09:54:09 <_ikke_> R3d_Sky: ok nice
2019-03-10 09:57:57 <danieli> building, almost ready to commit it
2019-03-10 09:58:06 <R3d_Sky> built and tested already
2019-03-10 09:58:10 <R3d_Sky> on aarch64 though
2019-03-10 09:58:30 <danieli> I redid the apkbuild again just now to be sure the patch and everything works properly
2019-03-10 09:59:07 <_ikke_> Ok. The prepare tries to remove a dir that no longer exists (Modules/zlib)
2019-03-10 09:59:20 <danieli> yup, fixed that one earlier
2019-03-10 09:59:29 <_ikke_> ok, I'll wait for you to push that hen
2019-03-10 09:59:31 <_ikke_> then
2019-03-10 09:59:38 <R3d_Sky> pushed
2019-03-10 09:59:41 <R3d_Sky> :)
2019-03-10 10:00:00 <danieli> might as well reset then
2019-03-10 10:01:09 <danieli> I'd say test_c_locale_coercion warrants some investigation
2019-03-10 10:01:29 <danieli> except that, should be fine
2019-03-10 10:02:38 <R3d_Sky> https://bugs.python.org/issue32002
2019-03-10 10:02:58 <danieli> yeah, that's the one I was referring to earlier
2019-03-10 10:04:16 <fabo> you'll probably want to add https://github.com/alpinelinux/aports/pull/4963 to your todo in this transition
2019-03-10 10:04:17 <_ikke_> maybe add that as a reference to the APKBUILD?
2019-03-10 10:11:31 <_ikke_> R3d_Sky: I don't think we should only look at packages that depend on python3-dev
2019-03-10 10:11:47 <R3d_Sky> hm, true
2019-03-10 10:11:54 <R3d_Sky> but I'm not very sure where to look
2019-03-10 10:12:24 <_ikke_> I'm currently looking at the output of `ag -G APKBUILD 'makedepends="[^"]*python3'` in main
2019-03-10 10:12:39 <_ikke_> quite a large list
2019-03-10 10:15:23 <R3d_Sky> _ikke_: `ag`?
2019-03-10 10:16:15 <_ikke_> the_silver_searcher
2019-03-10 10:18:20 <R3d_Sky> that's.... pretty big
2019-03-10 10:20:10 <danieli> told you :)
2019-03-10 10:22:14 <R3d_Sky> well, of these packages, which are likely to need a rel bump?
2019-03-10 10:22:19 <R3d_Sky> I know gdb is one for sure
2019-03-10 10:22:19 <_ikke_> http://tpaste.us/5w5y
2019-03-10 10:22:35 <_ikke_> all python libraries at least
2019-03-10 10:24:22 <R3d_Sky> that's 151 unique packages in the list
2019-03-10 10:25:00 <_ikke_> http://tpaste.us/vbjY
2019-03-10 10:26:15 <R3d_Sky> 43 that aren't py-*, and those include some ones that won't be fun to build, like postgresql, mesa and the like
2019-03-10 10:31:38 <R3d_Sky> most of these look like they either 1) use python for build system or tests (and depend on python) or 2) provide python bindings and depend on python-dev, but I'm kinda generalizing
2019-03-10 10:33:26 <danieli> I'm gonna start building them
2019-03-10 10:33:30 <R3d_Sky> _ikke_: do we just bump pkgrel on all packages that use python3-dev and then look for outliers
2019-03-10 10:34:00 <R3d_Sky> I really can't build any packages because I have limited storage and compute power
2019-03-10 10:34:03 <_ikke_> the order might matter
2019-03-10 10:34:04 <R3d_Sky> (RPi3)
2019-03-10 10:34:10 <danieli> the order will matter
2019-03-10 10:34:12 <_ikke_> yes
2019-03-10 10:34:24 <_ikke_> any idea how to quickly get a graph of that?
2019-03-10 10:34:33 <_ikke_> apk dot only does deps, not reverse deps it seems
2019-03-10 10:34:40 <danieli> uhm
2019-03-10 10:34:41 <danieli> one sec
2019-03-10 10:34:46 <_ikke_> and only for depends anyway, not makedepends
2019-03-10 10:35:33 <danieli> _ikke_: https://gist.github.com/jirutka/6717f68c7f76c9425b21d0cbe2eaa007
2019-03-10 10:35:42 <danieli> it'll take a while
2019-03-10 10:36:16 <danieli> abuild-deps -r python3
2019-03-10 10:36:28 <danieli> i put them in my ~/.bin/ on the x86_64 build box
2019-03-10 10:36:53 <_ikke_> right
2019-03-10 10:37:01 <_ikke_> nice
2019-03-10 10:37:13 <danieli> i could probably write a slightly faster one using sqlite3 in python, but it'll take me an hour or so to perfect
2019-03-10 10:37:17 <_ikke_> I'm setting up a chroot so that I can test things
2019-03-10 10:37:25 <danieli> i did too
2019-03-10 10:38:11 <_ikke_> how did you create the chroot?
2019-03-10 10:39:05 <danieli> made a dir, installed base alpine into it, bound the necessary devices (can use arch-chroot as a ref), chrooted in
2019-03-10 10:39:22 <_ikke_> right, I can't bind mount though
2019-03-10 10:39:25 <danieli> it'd probably be easier to just use a container but i was lazy
2019-03-10 10:39:31 <_ikke_> mount: permission denied (are you root?)
2019-03-10 10:42:36 <R3d_Sky> offtopic, but uhh so I ssh'd into brother's PC to "borrow" some of his i5 and Xorg is using 650MB of RAM
2019-03-10 10:42:47 <R3d_Sky> 650 megabytes?!?
2019-03-10 10:44:41 <danieli> seems a bit off-topic, but not far-fetched
2019-03-10 10:44:53 <danieli> mine's using around 165 MB, four monitors, proprietary nvidia driver
2019-03-10 11:11:39 <_ikke_> danieli: can you do bind mounts in your container?
2019-03-10 11:13:35 <danieli> _ikke_: uh, let me check
2019-03-10 11:14:06 <danieli> _ikke_: nope
2019-03-10 11:14:09 <_ikke_> It's probably not allowed for security reasons, but I just wondered how you did it
2019-03-10 11:14:24 <danieli> i didn't do it on the alpine build box
2019-03-10 11:14:27 <_ikke_> ah ok
2019-03-10 11:15:08 <danieli> think you gotta do it in the lxc config, and that's a bit painful
2019-03-10 11:15:13 <_ikke_> yup
2019-03-10 11:17:47 <mps> in my x86 lxc config I have line: lxc.mount.entry = /home/mps/aports home/mps/aports none rw,bind 0 0
2019-03-10 11:23:22 <R3d_Sky> I'm kinda lost again
2019-03-10 11:33:52 <_ikke_> R3d_Sky: How so?
2019-03-10 11:48:41 <_ikke_> mps: I want to bind mount from the container into a chroot
2019-03-10 11:48:56 <_ikke_> although that could be done like that as well
2019-03-10 11:53:47 <mps> ah, from container. can't remember for sure but I think I did something like 'mount -o bind /home/mps/aports edge/home/mps/aports'. will look later
2019-03-10 11:55:08 <mps> as root in container, of course
2019-03-10 11:55:33 <_ikke_> yes, but even as root it's denied for me
2019-03-10 11:55:42 <_ikke_> might have to do with limited capabilities
2019-03-10 11:56:26 <mps> you started lxc container as 'normal' user or root
2019-03-10 11:56:54 <mps> ?
2019-03-10 11:58:21 <_ikke_> It's started by lxc
2019-03-10 11:58:41 <_ikke_> So I guess as root?
2019-03-10 11:58:42 <mps> for me it works because I start lxc as root
2019-03-10 11:58:57 <_ikke_>  root       20   0  7972   228     0 S  0.0  0.0  0:00.22 ├─ lxc-start -n ikke-edge-x86_64
2019-03-10 11:59:39 <mps> hmm... will test later when be back at home
2019-03-10 12:09:05 <R3d_Sky> _ikke_: not sure what to do; though I do have a working alpine chroot to test stuff on
2019-03-10 12:11:32 <_ikke_> R3d_Sky: Maybe you can start tracing dependencies with the scripts danieli pointed to
2019-03-10 12:11:43 <_ikke_> see in what order packages should be updated
2019-03-10 12:22:20 <R3d_Sky> I've never touched packaging before in my life :(
2019-03-10 12:22:26 <R3d_Sky> huge props to maintainers
2019-03-10 12:30:02 <_ikke_> It's not that difficult
2019-03-10 12:36:30 <R3d_Sky> _ikke_: then again, nothing is for those who know what they're doing
2019-03-10 12:40:08 <R3d_Sky> how would this migration work out server side?
2019-03-10 12:40:26 <_ikke_> what do you mean with server side?
2019-03-10 12:41:22 <R3d_Sky> I mean on the buildserver
2019-03-10 12:42:36 <R3d_Sky> abuild-deps is single threaded - my pi 3's kryptonite
2019-03-10 12:42:55 <_ikke_> ok, then I will try it
2019-03-10 12:46:31 <mps> _ikke_: bind mount work on my local machine where I start them by hand, i.e. 'lxc-start --name edge', but doesn't work on alpine-infra
2019-03-10 12:48:23 <_ikke_> mps: we might have some capabilities limited
2019-03-10 12:49:23 <mps> you are talking about lxc on infra?
2019-03-10 12:50:16 <_ikke_> yes
2019-03-10 12:52:44 <mps> aha, yes, probably not allowed there to use bind mount
2019-03-10 12:56:10 <_ikke_> I just created another container
2019-03-10 13:17:36 <_ikke_> R3d_Sky: indexing, but it's going to take a while
2019-03-10 13:44:57 <R3d_Sky> _ikke_: a while is an understatement, this is going to take a day or two
2019-03-10 13:45:07 <R3d_Sky> I'm three hours in and only done about 1k
2019-03-10 13:46:07 <R3d_Sky> you guys okay if I try to rewrite this scriptset in python3?
2019-03-10 13:49:23 <mps> R3d_Sky: do you work all this on mmc card in RPi
2019-03-10 13:49:55 <R3d_Sky> mps: yes, unfortunately
2019-03-10 13:50:26 <mps> with arm's I use usb disks, it is faster then mmc
2019-03-10 13:50:53 <mps> if you have usb disk you could try to see if there is difference
2019-03-10 13:51:40 <R3d_Sky> all my USB disks are the slow USB2 kind
2019-03-10 13:51:57 <mps> with mmc sd card it took me about 11 hours to build firefox with 6 core and 4GB ram
2019-03-10 13:53:12 <mps> with usb3 ssd disk it was a faster but forgot exact time it took
2019-03-10 13:54:11 <R3d_Sky> yeah but I have a 1.2GHz running a single core task
2019-03-10 13:54:35 <mps> ehh, that will last :(
2019-03-10 13:57:37 <R3d_Sky> and its all shell
2019-03-10 13:57:54 <mps> but, with patience it could be done, probably. I built a lot of software on 1GHZ CPU 1GB RAM and sdcard. just start it before going to bed
2019-03-10 14:02:19 <_ikke_> R3d_Sky: it's done already for me
2019-03-10 14:02:48 <_ikke_> R3d_Sky: https://tpaste.us/Q16b
2019-03-10 14:14:52 <R3d_Sky> _ikke_: thanks, and I'm considering rewriting in py, you wouldn't mind if I did that right?
2019-03-10 14:16:00 <R3d_Sky> is there any python API for apk?
2019-03-10 14:16:04 <danieli> there is not
2019-03-10 14:16:11 <danieli> rewriting what, exactly_
2019-03-10 14:16:12 <danieli> ?
2019-03-10 14:17:13 <R3d_Sky> the abuild-deps script
2019-03-10 14:17:23 <danieli> aha
2019-03-10 14:17:32 <danieli> yeah, i'm gonna rewrite it in py, i already started but i've been busy
2019-03-10 14:17:39 <R3d_Sky> ooh
2019-03-10 14:17:48 <R3d_Sky> can I have the work you've done on it so far?
2019-03-10 14:17:58 <danieli> i have to finish some work first, a little later if you're around
2019-03-10 14:18:11 <danieli> also started working on apk bindings in python but i've had to postpone that because it's kinda messy and undocumented
2019-03-10 14:18:17 <danieli> luckily apk's codebase is small
2019-03-10 14:18:47 <R3d_Sky> I won't really be 'around' but irssi runs basically 24/7 on my VPS now
2019-03-10 14:18:54 <danieli> fair enough
2019-03-10 14:19:51 <R3d_Sky> instead of key: value pairs its just a huge text file of key value\n key value\n ad infinitum
2019-03-10 14:20:19 <danieli> what?
2019-03-10 14:20:33 <R3d_Sky> in the bash code for abuild-deps
2019-03-10 14:20:37 <R3d_Sky> sorry for rambling
2019-03-10 15:19:17 <TBB> apk does have some connection to Lua though
2019-03-10 15:20:03 <danieli> yes, there's a half-done lua binding
2019-03-10 15:20:38 <nmeum> https://pkgs.alpinelinux.org/package/edge/main/x86/lua5.2-apk that's the one
2019-03-10 15:22:39 <mps> +1 for lua, simple scripting language :)
2019-03-10 15:23:42 <danieli> agreed, but the apk lua bindings are still in a state of half-completion
2019-03-10 15:24:03 <danieli> i'm going to resume work on my py bindings soon enough, i've been swamped in other stuff
2019-03-10 18:09:36 <clandmeter> The lua bindings are enough to what we need
2019-03-10 18:09:57 <clandmeter> For the build system
2019-03-10 18:11:10 <mps> nice, so I can hack it if I need to adapt for me
2019-03-11 06:48:48 <sadiq[m]> hi. trying to install a package for alpine:latest docker installs the package from 3.9
2019-03-11 06:53:03 <SpaceToast> is that not expected?
2019-03-11 06:53:07 <SpaceToast> 3.9 is the latest release
2019-03-11 07:01:08 <danieli> ^
2019-03-11 07:46:57 <ncopa> morning
2019-03-11 07:47:06 <danieli> good morning ncopa
2019-03-11 07:47:24 <ncopa> ddevault: no i havent looked at glib 2.60 yet
2019-03-11 07:48:17 <ncopa> re python 3.6 and aarch64 on rpi3: https://bugs.python.org/issue36107
2019-03-11 07:48:32 <ncopa> so apparently its only python 3.6 that i broken, and not 3.7
2019-03-11 07:48:43 <ncopa> i would very much want to fix it on 3.6 too
2019-03-11 07:49:22 <danieli> I haven't looked at 3.6 in Alpine altely, just 3.7
2019-03-11 07:49:27 <danieli> s/alt/lat/
2019-03-11 07:49:27 <alpine-meetbot> danieli meant to say: I haven't looked at 3.6 in Alpine lately, just 3.7
2019-03-11 09:15:47 <ScrumpyJack> how do we feel about packaging statcally linked binaries the rely on lbressl? (such as opensmtpd)
2019-03-11 09:19:41 <danieli> not a big fan
2019-03-11 09:26:21 <ScrumpyJack> I don't see how else to build something like opensmtpd. we could have a libressl-stactic package
2019-03-11 09:36:56 <sadiq[m]> SpaceToast: eh, sorry, I was supposed to use edge. :)
2019-03-11 09:37:17 <sadiq[m]> so using alpine:edge still uses 3.9 repo
2019-03-11 09:44:58 <clandmeter> sadiq[m]: this is development channel. please visit #alpine-linux for support.
2019-03-11 09:56:21 <sadiq[m]> ok. sorry
2019-03-11 11:58:08 <clandmeter> hi, we are going to upgrade one of our infra servers. this could cause some downtime to few services.
2019-03-11 12:49:19 <R3d_Sky> hi
2019-03-11 12:52:19 <danieli> hello
2019-03-11 14:37:48 <ddevault> ncopa: I'm running into trouble, can I shoot you an APKBUILD to look at?
2019-03-11 14:39:35 <danieli> ddevault: which package, if I may ask?
2019-03-11 14:40:29 <ddevault> glib
2019-03-11 14:42:29 <tmhoang> clandmeter: stealing a min from you... do you want me to put this tod_s390x.c program in s390-tools, busybox, or openrc ? le, can I shoot you an APKBUILD to look at?
2019-03-11 14:42:29 <tmhoang> <danieli> ddevault: which package, if I may ask?
2019-03-11 14:42:32 <tmhoang> https://github.com/alpinelinux/aports/pull/6183/commits/aaaf59bb8deba12e7105aafae86d1f3052674e9b
2019-03-11 14:42:34 <tmhoang> sorry
2019-03-11 14:42:45 <tmhoang> clandmeter: stealing a min from you... do you want me to put this tod_s390x.c program in s390-tools, busybox, or openrc ? https://github.com/alpinelinux/aports/pull/6183/commits/aaaf59bb8deba12e7105aafae86d1f3052674e9b
2019-03-11 14:44:54 <clandmeter> hi
2019-03-11 14:46:06 <clandmeter> s390-tools is an existing pkg?
2019-03-11 14:46:12 <tmhoang> clandmeter: yes
2019-03-11 14:46:42 <clandmeter> what are your concerns?
2019-03-11 14:47:36 <tmhoang> putting that C program in s390-tools means : booting from netboot means pulling/installing s390-tools.
2019-03-11 14:48:07 <tmhoang> or, I can create a sub-package s390-tools-tod
2019-03-11 14:48:12 <clandmeter> i think if its not going to be upstreamed it would be better served separately.
2019-03-11 14:48:13 <tmhoang> ugly though
2019-03-11 14:48:28 <tmhoang> understood
2019-03-11 14:48:47 <clandmeter> else the maintainers should give their thoughts about it.
2019-03-11 14:49:22 <tmhoang> this C program is actually in qemu code. Don't know how systemd manages though. I read their code but cant find anything related.
2019-03-11 14:49:52 <tmhoang> I guess I need to put this into a separate package
2019-03-11 14:49:59 <tmhoang> with repsective init.d file
2019-03-11 14:50:04 <tmhoang> okay seems fine
2019-03-11 14:50:26 <tmhoang> but it still needs a hook into hwclock.init
2019-03-11 14:50:36 <tmhoang> which might upset ncopa ...
2019-03-11 14:50:54 <clandmeter> i guess its not that intrusive?
2019-03-11 14:51:21 <tmhoang> if it does not touch hwclock.init, it would do something similar to hwclock
2019-03-11 14:51:41 <tmhoang> s390clock ? sounds dumb
2019-03-11 14:52:06 <clandmeter> as a separate pkg?
2019-03-11 14:52:10 <tmhoang> yes
2019-03-11 14:52:25 <tmhoang> aports/s390clock/s390clock.init
2019-03-11 14:55:03 <clandmeter> what does the init look like?
2019-03-11 14:55:25 <clandmeter> it should replace hwclock completely?
2019-03-11 14:58:24 <tmhoang> I don't know. I still prefer to do if else [ arch=s390x ] in hwclock.init. But ncopa prefer not. I kind of agree with him because it would loook ugly. If I make separate package with separate .init, it should be replacing hwclock on s390x
2019-03-11 15:00:01 <clandmeter> how are you going to replace hwclock?
2019-03-11 15:00:10 <clandmeter> modify initramfs?
2019-03-11 15:01:01 <clandmeter> its added by initramfs right?
2019-03-11 15:02:35 <tmhoang> clandmeter: probably yes
2019-03-11 15:02:53 <tmhoang> but I dont know if replacing hwclock is a good idea
2019-03-11 15:03:22 <clandmeter> it sounds to me it belongs in hwclock
2019-03-11 15:03:50 <clandmeter> but i guess ncopa has valid reasons to dislike it.
2019-03-11 15:03:57 <clandmeter> did he propose something else?
2019-03-11 15:03:59 <tmhoang> yeah, current situation is : https://github.com/alpinelinux/aports/pull/6184/commits/2a5f7c32e1746f78585fb9e1c1c975380856fbf3
2019-03-11 15:04:04 <tmhoang> no
2019-03-11 15:05:02 <tmhoang> I don't like it neither. I try to look into openrc code to see if I can upstream that C program into openrc, but I dont see any where it would fit into openrc code
2019-03-11 15:05:59 <tmhoang> this should be an openrc's thing since it takes care of /dev/rtc*
2019-03-11 15:06:16 <tmhoang> meaning, hwclock thing
2019-03-11 15:06:52 <tmhoang> okay I make up my mind.
2019-03-11 15:07:17 <tmhoang> that C program stays in Alpine openrc source tree and I will integrate into hwclock.init
2019-03-11 15:07:33 <tmhoang> and pretify it and pursuade ncopa :D
2019-03-11 16:28:59 <danieli> ncopa: oh yeah, oops, that's a privesc CVE ^
2019-03-11 16:30:01 <_ikke_> The docker upgrade?
2019-03-11 16:30:16 <danieli> yes
2019-03-11 16:30:34 <danieli> it's in runc
2019-03-11 16:30:48 <danieli> it's not super bad but should be fixed
2019-03-11 16:31:26 <_ikke_> runc is it's own package in alpine
2019-03-11 16:33:26 <_ikke_> So should runc be updated, or docker?
2019-03-11 16:34:02 <danieli> the vuln is in runc, but it doesn't look like our docker even depends on it?
2019-03-11 16:34:28 <danieli> oh nevermind, docker -> containerd -> runc
2019-03-11 16:34:34 <danieli> yeah no, we patch runc
2019-03-11 17:18:20 <_ikke_> Is it a problem when pkgname is dynamic, or should it be statically defined?
2019-03-11 17:38:35 <ncopa> sorry for not being responsive today. I have been working on upstream dpdk and made 15 patches, cleaning up various build fixes for musl
2019-03-11 17:39:06 <_ikke_> ncopa: no worry
2019-03-11 17:39:14 <_ikke_> dpdk?
2019-03-11 17:39:47 <ncopa> Data Plane Development Kit
2019-03-11 17:39:57 <ncopa> bundled with ceph
2019-03-11 17:40:18 <ncopa> i think i have seen it used by other projects too
2019-03-11 17:40:30 <_ikke_> ah ok
2019-03-11 17:40:56 <ncopa> I think i will continue tomorrow. have a nice evening!
2019-03-11 17:41:02 <_ikke_> You as well
2019-03-11 17:45:06 <_ikke_> How do you deal when subpackages contain init files?
2019-03-11 17:52:21 <_ikke_> ah, zabbix has the same, looking at that one
2019-03-11 18:32:36 <nmeum> _ikke_: I would simply ship those with the -openrc subpackage
2019-03-11 18:33:37 <_ikke_> It doesnt make a lot of sense to have an init file for a service that is not installed
2019-03-11 18:33:59 <_ikke_> the package has basically multiple services as subpackages, each with their own init files
2019-03-11 18:34:45 <_ikke_> so if you install one service, it would be confusing to have the init files for the other services
2019-03-11 18:35:24 <nmeum> the policy used to be that we don't have subpackage for subpackage, e.g. we usually don't have extra -doc subpackage for subpackages
2019-03-11 18:35:34 <nmeum> *subpackages for subpackages
2019-03-11 18:36:08 <_ikke_> hmmm
2019-03-11 18:36:48 <nmeum> e.g. if you install perl and perl-doc you will have a man page for pl2pm even though that command is only available if you installed perl-utils
2019-03-11 18:36:53 <_ikke_> https://git.alpinelinux.org/aports/tree/community/zabbix/APKBUILD#n192
2019-03-11 18:38:28 <_ikke_> for the end user it would be very confusing to have a zabbix_agent init file, even if you don't have the zabbix agent installed
2019-03-11 18:39:45 <nmeum> maybe, but it might also be confusing for the user to have a pl2pm man page even though the pl2pm command is not available
2019-03-11 18:40:02 <_ikke_> I agree :)
2019-03-11 18:41:08 <nmeum> to a certian degree I agree with you but most APKBUILDs don't have subpackages for subpackages and I am not sure if it is really a good idea to fragment packages further
2019-03-11 18:42:01 <SpaceToast> I disagree - I think getting all the manual pages is expected, but not necessarily all init scripts
2019-03-11 18:42:23 <SpaceToast> one can have various manual pages for non-local programs (and even things that aren't executable - outside of sections 1,7,8)
2019-03-11 18:42:28 <SpaceToast> and they can be useful!
2019-03-11 18:42:39 <SpaceToast> one cannot use a service script for a binary they do not have on the local system
2019-03-11 18:51:15 <_ikke_> nmeum: so you say this wouldn't be a good idea? http://tpaste.us/jXbq
2019-03-11 18:53:47 <danieli> ah, looking into salt I see
2019-03-11 18:54:32 <_ikke_> danieli: someone made a PR for salt
2019-03-11 18:54:39 <SpaceToast> I wonder if we could leverage/modify default_openrc to work with subpackages, perhaps using an (optional) argument?
2019-03-11 18:57:44 <nmeum> _ikke_: I am not juding at all, I just attempted to state how this has been handeled for other subpackages (e.g. -doc) in the past
2019-03-11 18:57:55 <_ikke_> nmeum: yes, I follow
2019-03-11 18:59:00 <_ikke_> but the consequence of that practice is that you get non-working init files on your system
2019-03-11 19:00:12 <nmeum> I am not even sure if putting init files in a seperate subpackage was a good idea to begin with. most services files are only a few kb in size
2019-03-11 19:00:41 <SpaceToast> I'm not sure it's about that
2019-03-11 19:00:43 <_ikke_> nmeum: right, that's the core issue
2019-03-11 19:00:49 <SpaceToast> some of our service files are.... questionable
2019-03-11 19:00:51 <_ikke_> The idea was to be able to switch init systems
2019-03-11 19:00:53 <SpaceToast> some are simply outdated
2019-03-11 19:01:01 <SpaceToast> it's easier for the user to simply write their own if they're in a separate package
2019-03-11 19:01:13 <_ikke_> SpaceToast: not sure, they are automatically installed now
2019-03-11 19:01:24 <SpaceToast> hm
2019-03-11 19:01:26 <_ikke_> if you have openrc installed, then whenever you install the main package, you also get the openrc package
2019-03-11 19:01:31 <nmeum> yep
2019-03-11 19:01:37 <nmeum> there is an install_if rule for the -openrc subpackage
2019-03-11 19:01:43 <SpaceToast> I'd imagine you can stop that with policies or an explicit del
2019-03-11 19:02:04 <SpaceToast> or, at least, you should be able to :)
2019-03-11 19:02:09 <nmeum> and regarding switching init systems: we could just ship multiple servicse files (for different init systems) in a single package since the service files are so small in terms of size it shouldn't make a big difference
2019-03-11 19:02:20 <SpaceToast> I don't mean switching init systems
2019-03-11 19:02:27 <SpaceToast> I mean the contents of the init scripts specifically
2019-03-11 19:02:32 <nmeum> > 20:00:51 (_ikke_) The idea was to be able to switch init systems
2019-03-11 19:02:36 <SpaceToast> ah, ic
2019-03-11 19:03:21 <SpaceToast> I'm not really aware of any plans in that direction, and a lot of (simpler) init systems struggle with bad actors, like SQL servers
2019-03-11 19:04:31 <_ikke_> We are looking at other init systems besides openrc, but afaik no concrete alternative atm
2019-03-11 19:04:54 <SpaceToast> are there any specific issues we have with openrc?
2019-03-11 19:05:11 <SpaceToast> (I do, and have considered forking it a few times, but a standalone fork like that wouldn't do much, obviously)
2019-03-11 19:05:34 <danieli> _ikke_: I see
2019-03-11 19:05:35 <_ikke_> I don't know the specific issues that alpine perceives
2019-03-11 19:05:40 <SpaceToast> to my knowledge, notable alternatives are systemd (highly unlikely), runit (has trouble with bad actors) and s6 (very similar to runit, not sure how it handles bad actors)
2019-03-11 19:05:54 <nmeum> I have quite a few issues with openrc: it still uses pidfiles for monitoring services and our version of openrc is highly patched since upstream doesn't support busybox
2019-03-11 19:07:07 <_ikke_> WHat's specific about busybox that needs to be supported?
2019-03-11 19:07:56 <nmeum> _ikke_: upstream uses various gnuisms in the default services
2019-03-11 19:08:09 <SpaceToast> upstream works mostly fine with busybox, and pidfiles aren't really necessary with supervisor-daemon / s6-integration
2019-03-11 19:08:24 <SpaceToast> yes, upstream default services are crap :) I'd like to change them
2019-03-11 19:08:53 <_ikke_> nmeum: oh, so it's more about the shell / init services
2019-03-11 19:11:06 <nmeum> mostly, take a look at /usr/share/doc/openrc/BUSYBOX.md and our patchset if you want to know more
2019-03-11 19:11:33 <_ikke_> SpaceToast: how does supervisor-daemon deal with monitoring processes?
2019-03-11 19:11:41 <_ikke_> especially ones that double-fork?
2019-03-11 19:12:30 <SpaceToast> _ikke_: it doesn't deal with double-forking; it's basically the original openrc's maintainer's attempt to reach daemontools-parity
2019-03-11 19:12:40 <SpaceToast> for doubleforking s-s-d is still preferred
2019-03-11 19:12:52 <_ikke_> s-s-d?
2019-03-11 19:12:52 <SpaceToast> for other processes, as in daemontools, child/parent supervision is used
2019-03-11 19:12:55 <SpaceToast> start-stop-daemon
2019-03-11 19:13:04 <_ikke_> right, so still pid-files, right?
2019-03-11 19:13:21 <SpaceToast> for doubleforking, yes
2019-03-11 19:13:27 <SpaceToast> but there's not all that much you can do about those bad actors
2019-03-11 19:13:30 <_ikke_> Personally I like how systemd handles hat
2019-03-11 19:13:54 <SpaceToast> you like digging into cgroups and assuming it all works out?
2019-03-11 19:14:07 <SpaceToast> I can see the appeal from the top, but the details get messy very fast :(
2019-03-11 19:14:09 <_ikke_> In practice it turns out quite well
2019-03-11 19:14:18 <_ikke_> But right, I don't know all the details
2019-03-11 19:15:25 <SpaceToast> well, I really doubt systemd is going to be happening, given our scope
2019-03-11 19:15:29 <SpaceToast> it also doesn't run very well on musl
2019-03-11 19:15:43 <_ikke_> Yes, it's not going to happen on alpine
2019-03-11 19:15:57 <SpaceToast> I'd be willing to give s6 a try, but in general I'm perfectly willing to help out with openrc (at least the script side)
2019-03-11 19:16:30 <SpaceToast> forking it is on the table (at least for me), but I definitely wouldn't go at it alone
2019-03-11 19:32:47 <mps> Void linux uses runit, could be investigated. I still prefer openrc besides all it's issues
2019-03-11 19:33:23 <mps> actually, on my system I combine openrc with runit.
2019-03-11 20:12:49 <SpaceToast> oh wow, just noticed we don't have a minio package
2019-03-11 20:12:56 <SpaceToast> gonna have to fix that when I get home (at least in my user-aports)
2019-03-11 20:14:29 <clandmeter> SpaceToast: i think i have a local copy
2019-03-11 20:14:37 <clandmeter> if i didnt delete it yet
2019-03-11 20:15:22 <clandmeter> i didnt
2019-03-11 20:15:39 <clandmeter> pkgver is fun
2019-03-11 20:15:57 <_ikke_> Any points on these errors? https://github.com/alpinelinux/aports/pull/5907#issuecomment-471344640
2019-03-11 20:18:15 <SpaceToast> clandmeter: oh, nice, any chance at getting it into community (or at least testing)? :)
2019-03-11 20:18:20 <clandmeter> did the contributor rebase?
2019-03-11 20:18:37 <SpaceToast> I was just getting around to setting up an object storage for $new_dayjob_office when I realized we didn't have a package
2019-03-11 20:19:04 <_ikke_> clandmeter: probably not
2019-03-11 20:19:21 <clandmeter> the errors are from travis?
2019-03-11 20:20:04 <_ikke_> ues
2019-03-11 20:20:05 <_ikke_> yes
2019-03-11 20:21:06 <clandmeter> SpaceToast: i can push it to testing, if you can add a initd and fix if missed soemthing
2019-03-11 20:21:39 <SpaceToast> clandmeter: sure, I'll write an init.d when I get home - how would you like me to deliver it, roughly?
2019-03-11 20:21:58 <clandmeter> just stick it here in front of my nose :)
2019-03-11 20:22:03 <clandmeter> git am
2019-03-11 20:22:14 <clandmeter> err format-patch to git am
2019-03-11 20:22:27 <SpaceToast> well, git-format-patch is kind of hard without having the APKBUILD in a git repo (on my end) ;)
2019-03-11 20:22:36 <SpaceToast> can I just send you a brpaste.xyz link?
2019-03-11 20:22:44 <SpaceToast> (with just the init.d and conf.d bits)
2019-03-11 20:22:47 <clandmeter> im push it now :)
2019-03-11 20:23:09 <SpaceToast> ah, alright ^^
2019-03-11 20:23:28 <SpaceToast> and the actual patch in a paste, then?
2019-03-11 20:23:41 <clandmeter> it will be minio-20190220-r0.apk
2019-03-11 20:23:49 <clandmeter> or do we have a newer version?
2019-03-11 20:23:58 <clandmeter> cause their versioning is kind of weird
2019-03-11 20:24:50 <clandmeter> oh two new releases again
2019-03-11 20:24:55 <SpaceToast> latest release is RELEASE.2019-03-06T22-47-10Z
2019-03-11 20:25:02 <SpaceToast> so 20190306-r0.apk
2019-03-11 20:25:45 <clandmeter> i hope they will never change versioning cause that will break things
2019-03-11 20:26:01 <clandmeter> i think we should prepend it with 0_
2019-03-11 20:26:19 <SpaceToast> that's up to you, I don't really mind one way or the other :)
2019-03-11 20:26:48 <clandmeter> you will if they change versioning :)
2019-03-11 20:27:00 <clandmeter> new stable release 1.0
2019-03-11 20:27:07 <clandmeter> :)
2019-03-11 20:28:01 <SpaceToast> oh I mean that I'm not bothered by various things like that
2019-03-11 20:28:10 <SpaceToast> (e.g prepending 0_)
2019-03-11 20:28:22 <SpaceToast> I *am* bothered by bad init.d, so let's go and get that set up!
2019-03-11 20:29:01 <clandmeter> crap
2019-03-11 20:29:08 <clandmeter> thats not a valid version
2019-03-11 20:29:45 <_ikke_> SpaceToast: just curious, what do you consider bad in a initd script?
2019-03-11 20:30:51 <SpaceToast> _ikke_: many, many things, would you like a few examples, an extensive list, or a general idea?
2019-03-11 20:31:08 <_ikke_> mostly the latter I guess
2019-03-11 20:31:19 <SpaceToast> well, openrc has many "magic" features
2019-03-11 20:31:25 <SpaceToast> however, avoiding all of them is literally impossible
2019-03-11 20:31:32 <SpaceToast> so trying to "work around" various features is bad
2019-03-11 20:31:43 <SpaceToast> for example, if you're calling s-s-d directly, you're probably doing something horribly wrong
2019-03-11 20:31:48 <_ikke_> yup
2019-03-11 20:31:56 <_ikke_> I prefer declaritive style personally
2019-03-11 20:32:22 <SpaceToast> another example of really bad practice is enforcing something that should not necessarily be enforced
2019-03-11 20:32:38 <SpaceToast> (for an example, see our current handling of wpa_supplicant / wpa_cli - they're basically unusable without some extensive modifications)
2019-03-11 20:33:52 <AinNero> huh
2019-03-11 20:33:55 <AinNero> 
ACTION is confused

2019-03-11 20:34:01 <AinNero> like what?
2019-03-11 20:36:54 <SpaceToast> oh, or dnsmasq!
2019-03-11 20:37:29 <clandmeter> SpaceToast: done
2019-03-11 20:38:04 <clandmeter> i didnt look carefully about which tags it needs
2019-03-11 20:38:08 <SpaceToast> AinNero: wpa_supplicant forces you to use it with a specific interface (see line 7), does weird autodetection (see rest of file) that breaks use-cases, and (out of the box) won't work with wpa_cli, which hard-deps on it
2019-03-11 20:38:10 <clandmeter> you can add it to the patch if i missed one
2019-03-11 20:38:34 <SpaceToast> dnsmasq is even worse, though, it's 134 lines with built-in bridge creation/management
2019-03-11 20:38:41 <SpaceToast> and firewalling
2019-03-11 20:39:12 <AinNero> line 7 of what?
2019-03-11 20:39:25 <clandmeter> yes its to support lxc
2019-03-11 20:39:52 <SpaceToast> /etc/init.d/wpa_supplicant?
2019-03-11 20:40:01 <SpaceToast> clandmeter: lxc should have a separate init.d script, if it needs it
2019-03-11 20:40:08 <clandmeter> dnsmasq
2019-03-11 20:40:10 <SpaceToast> this functionality shouldn't be pushed on dnsmasq-normal, imo :)
2019-03-11 20:40:12 <AinNero> like, im both wpa_supplicant, and dnsmasq bridge user
2019-03-11 20:40:16 <clandmeter> its ncopa's creation :)
2019-03-11 20:40:30 <AinNero> and im surely much less agiated about them than you
2019-03-11 20:40:30 <SpaceToast> sure, I'm just giving examples of things I don't like in openrc scripts, like _ikke_ asked :)
2019-03-11 20:40:37 <_ikke_> :)
2019-03-11 20:40:50 <SpaceToast> AinNero: erm... I'm just responding to a request to talk about things I don't like
2019-03-11 20:41:32 <SpaceToast> running in, claiming to be confused, and saying I'm agitated doesn't bode very well ^^
2019-03-11 20:42:54 <AinNero> you claimed something was unusable that i depend on a daily base
2019-03-11 20:43:18 <SpaceToast> "without some extensive modifications", that I'm sure you've applied
2019-03-11 20:43:22 <AinNero> and i dont get your argument with the forced interface, the interface isn't even set per default?
2019-03-11 20:43:28 <AinNero> like, i wrote a wpa_supplicant config
2019-03-11 20:43:35 <AinNero> with my networks
2019-03-11 20:44:01 <SpaceToast> the goal of wpa_cli is to control wpa_supplicant dynamically (kind of ala iwd)
2019-03-11 20:44:18 <SpaceToast> as-is, it doesn't "just work" when you start that up, partially due to the weird handling within wpa_supplicant
2019-03-11 20:44:36 <SpaceToast> people on and off the ML complain about it constantly, and you need to know how wpa_supplicant works in order to have it be functional
2019-03-11 20:44:52 <SpaceToast> this is unusual, and outside the norm for something that (normally), isn't even that complicated
2019-03-11 20:44:58 <AinNero> how else would you configure the wireless networks?
2019-03-11 20:45:01 <SpaceToast> to further the point, setup-alpine doesn't even use the service!
2019-03-11 20:45:09 <SpaceToast> because it's convoluted
2019-03-11 20:45:36 <AinNero> because of dhcpd maybe
2019-03-11 20:45:53 <AinNero> because dhcpd allows to start wpa_supplicant for hotplugged wifi devices
2019-03-11 20:46:15 <AinNero> *dhcpcd
2019-03-11 20:46:21 <SpaceToast> point being, user installs alpine (succesfuly, mind you) with setup-alpine, reboots, and wireless networking is hopelessly broken (unless they're capable of debugging wpa_supplicant specifically)
2019-03-11 20:46:35 <SpaceToast> again - not typical, convoluted, and could be better
2019-03-11 20:46:53 <SpaceToast> you depending on it and running around saying how you've configured it doesn't make me any more agitated, or the situation any better.
2019-03-11 20:47:23 <AinNero> im using alpine on a mobile device
2019-03-11 20:47:37 <SpaceToast> that's cool :)
2019-03-11 20:48:34 <AinNero> i feel like you are the kind of person who goes around with intent of changing everthing
2019-03-11 20:48:49 <AinNero> at one side, this is a interesting kind of adventurous behavior
2019-03-11 20:49:55 <AinNero> on the other side, i was like that when i was younger, and i had to learn that its much more difficult to actually make things better
2019-03-11 20:50:15 <SpaceToast> I have the intent of fixing things that are broken, and improving things that need improvement
2019-03-11 20:50:22 <AinNero> and instead i just trashed existing structures without ever understanding why they are there
2019-03-11 20:50:25 <SpaceToast> things that are not broken, and are fine as-is, I've no interest in touching
2019-03-11 20:50:47 <AinNero> if you claim wpa_supplicant to be broken, i'd like to know how you expect it to work
2019-03-11 20:51:25 <SpaceToast> I expect wpa_supplicant's init.d script to be trivially usable and configurable, such that setup-alpine can set it up, with the following two goals:
2019-03-11 20:51:45 <SpaceToast> 1. after a reboot, in which setup-alpine was the only thing to have touched it, things should continue to work
2019-03-11 20:51:58 <SpaceToast> 2. enabling/using wpa_cli should not require any additional modifications
2019-03-11 20:52:38 <SpaceToast> if possible, I would also attempt to remove the strange interface detection mechanism within the init.d script - the configuration should be trusted, since either we generated it (so it is known-good), or the user touched it by hand (and thus is responsible for it)
2019-03-11 20:52:39 <AinNero> this sounds more like a issue with setup-alpine
2019-03-11 20:53:10 <SpaceToast> as it is, you cannot start up a cd and run `rc-service wpa_cli start` - this will not work and it will crash.
2019-03-11 20:53:12 <SpaceToast> try it yourself!
2019-03-11 20:53:35 <SpaceToast> if we're going to be providing things, the things we provide should attempt to work (even if minimally so) by default, and the implementation should be maximally elegant.
2019-03-11 20:53:41 <SpaceToast> as it is, neither is true
2019-03-11 20:53:45 <SpaceToast> therefore, I call it broken
2019-03-11 20:53:49 <AinNero> tbh i never tried to start wpa_cli as a service
2019-03-11 20:54:05 <AinNero> my workflowis documented here: https://blog.w1r3.net/2018/03/10/setup-wifi-on-alpine-linux.html
2019-03-11 20:54:09 <SpaceToast> and yet that was a significant part of my complaint
2019-03-11 20:54:18 <SpaceToast> which one of us is hasty and agitated, then? :)
2019-03-11 20:55:24 <SpaceToast> what would one do in the scenario that they go between a large variety of networks, not all of which should be using dhcp? one can configure dhcpcd to work with that, but it's usually quite unfortunate
2019-03-11 20:55:39 <AinNero> use network manager
2019-03-11 20:57:24 <SpaceToast> ah, but that one needs additional work to function by default too, as it relies on wpa_supplicant :)
2019-03-11 20:57:42 <SpaceToast> these things are quite low on priority list, but it's quite hard to argue that everything is as it should be
2019-03-11 20:57:51 <AinNero> are we trying to be a small server distro or a desktop distro?\
2019-03-11 20:58:15 <SpaceToast> we are trying to be a general purpose distro
2019-03-11 20:58:18 <SpaceToast> to be more specific...
2019-03-11 20:58:22 <SpaceToast> "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency."
2019-03-11 20:58:42 <AinNero> oh, power users.
2019-03-11 20:58:44 <SpaceToast> I don't think 137 lines in a dnsmasq init.d script to make it serve two wholly separate functions counts as simple
2019-03-11 20:59:36 <AinNero> i used that setup
2019-03-11 20:59:43 <AinNero> together with jirutka's qemu scripts
2019-03-11 20:59:50 <AinNero> which dont really belong to qemu, either
2019-03-11 21:00:06 <AinNero> i admit i actually read that code.
2019-03-11 21:00:49 <SpaceToast> again, that's kind of the point - it isn't simple, and the complexity can potentially reduce security
2019-03-11 21:01:09 <SpaceToast> the reason for having it appears to be to have one init.d script that serves multiple purposes, instead of just having multiple
2019-03-11 21:01:21 <AinNero> dont break my VM cluster tho
2019-03-11 21:01:50 <SpaceToast> any breaking changes will obviously be announced and go through testing/ first, but again - these things are quite low on my priority list
2019-03-11 21:03:29 <SpaceToast> the top items right now are minio (discussed above), and the top not-very-short-term involve the docs, dlang and a few more packages that'll go through staging in my user-aports first
2019-03-11 21:56:46 <brebs> hi, https://patchwork.alpinelinux.org/project/aports/list/ shows "502 Bad Gateway"
2019-03-11 21:57:18 <_ikke_> brebs: let me check
2019-03-11 22:06:19 <_ikke_> brebs: There is some internal issue, but I cannot find what is causing it
2019-03-11 23:28:55 <fassl> is maybe a certificate expired?
2019-03-12 00:00:48 <R3d_Sky> hey - am still working on the 3.7 build order stuff, but life's pretty busy - sorry; I think I'll have something by the weekend?
2019-03-12 00:01:48 <R3d_Sky> 12th grade is just starting here, lots of books to wrap and homework to write
2019-03-12 00:02:55 <tcely> So patchwork, git, and builders are having issues right now??
2019-03-12 01:05:47 <SpaceToast> meanwhile... abuild claims to take option -i, and it's in the getopts string, but it seems to be ignored
2019-03-12 02:01:52 <R3d_Sky> SpaceToast: can confirm
2019-03-12 02:03:17 <SpaceToast> I mean, by default install happens within all
2019-03-12 02:03:20 <SpaceToast> but still seems awkward
2019-03-12 02:22:34 <SpaceToast> clandmeter: for when you wake up, took some doing, but here you are https://brpaste.xyz/zvHIzw?diff
2019-03-12 02:22:40 <SpaceToast> feel free to change whatever, of course :)
2019-03-12 02:22:56 <SpaceToast> (https://brpaste.xyz/raw/zvHIzw - raw link for curl)
2019-03-12 02:23:41 <SpaceToast> a few specific side-effects haven't been poked, but that's what testing/ is for (I'll surely have messed with them after actually deploying)
2019-03-12 02:25:24 <SpaceToast> oh wait, that didn't include the init.d/conf.d/etc for some reason..
2019-03-12 02:25:30 <SpaceToast> that's what I get for starting at 9pm
2019-03-12 02:27:22 <SpaceToast> make that https://brpaste.xyz/3eiw-Q?diff and https://brpaste.xyz/raw/3eiw-Q
2019-03-12 02:35:34 <clandmeter> SpaceToast: can you make 1 git format-patch with bumped pkgrel?
2019-03-12 02:35:40 <clandmeter> i cant apply those
2019-03-12 02:35:48 <SpaceToast> that last one is format-patch
2019-03-12 02:35:52 <SpaceToast> my bad on the first one
2019-03-12 02:35:58 <SpaceToast> and sure, let me bump pkgrel
2019-03-12 02:36:15 <SpaceToast> (I've been sleepy all day, so please do forgive the lack of attentiveness)
2019-03-12 02:36:27 <clandmeter> ah
2019-03-12 02:36:30 <clandmeter> now i see
2019-03-12 02:37:17 <clandmeter> i prefer git format-patch so we can give you credits :)
2019-03-12 02:37:39 <SpaceToast> fair enough :) but yeah, let me just modify this patch by hand, make sure it still applies...
2019-03-12 02:38:15 <clandmeter> i thought it needed each other
2019-03-12 02:38:22 <SpaceToast> https://brpaste.xyz/raw/KdVAyQ
2019-03-12 02:38:31 <SpaceToast> should be identical to the previous one, just with pkgrel++
2019-03-12 02:40:35 <ddevault> who maintains the mailing lists?
2019-03-12 02:40:43 <ddevault> sysadmin wise
2019-03-12 02:44:37 <clandmeter> that would be nangel
2019-03-12 02:45:22 <clandmeter> SpaceToast: why are you exporting those variables and not use --env?
2019-03-12 02:45:46 <clandmeter> ddevault: something broken?
2019-03-12 02:45:58 <ddevault> was on my end
2019-03-12 02:45:59 <SpaceToast> which --env?
2019-03-12 02:46:03 <ddevault> well, not really
2019-03-12 02:46:20 <ddevault> was getting an esoteric bounce from the list admin inbox, but sussed it out with some educated guessing
2019-03-12 02:46:42 <clandmeter> start-stop-daemon
2019-03-12 02:47:11 <SpaceToast> oh, you mean in conf.d
2019-03-12 02:47:32 <SpaceToast> because a lot of minio functionality is controlled through environment variables (instead of a configuration file), and they're intended to be user-configurable
2019-03-12 02:47:39 <SpaceToast> most also don't have any viable "default"
2019-03-12 02:48:15 <SpaceToast> s-s-d --env is more about things you expect to know programmatically, not things ala authz
2019-03-12 02:49:07 <SpaceToast> basically, this approach makes conf.d/minio the configuration file, rather than having some weird splits and expecting users to modify init.d/minio, or doing other weird things
2019-03-12 02:56:28 <ddevault> mirroring works ^^ https://lists.sr.ht/~sircmpwn/alpine-aports
2019-03-12 02:58:07 <SpaceToast> ddevault: what directions of mirroring do you have, and how are they triggered?
2019-03-12 02:58:19 <SpaceToast> guessing push and pull, push on-push and pull on timer?
2019-03-12 02:58:22 <ddevault> the lists.sr.ht does not accept posts
2019-03-12 02:58:30 <ddevault> the "new post" button leads to the alpine posting address
2019-03-12 02:58:40 <ddevault> emails are imported by subscribing to the list normally
2019-03-12 02:58:47 <SpaceToast> oh!
2019-03-12 02:58:50 <ddevault> so your mail server just forwards to lists.sr.ht like everyone else
2019-03-12 02:58:56 <SpaceToast> sorry, completely misunderstood what this was about :)
2019-03-12 02:59:04 <SpaceToast> I really should stop trying to be productive for today
2019-03-12 02:59:20 <ddevault> the issue I had earlier, by the way
2019-03-12 02:59:34 <ddevault> is that lists.sr.ht tried to subscribe with ~sircmpwn/alpine-aports@lists.sr.ht, which broke your software
2019-03-12 02:59:42 <ddevault> made it use the fallback address instead, u.sircmpwn.alpine-aports@lists.sr.ht
2019-03-12 10:41:08 <nmeum> clandmeter: any idea what this build failure is about https://cloud.drone.io/alpinelinux/aports/352
2019-03-12 10:41:20 <nmeum> to be exact: it's a fetch not a build failure
2019-03-12 10:41:36 <clandmeter> it needs rebase
2019-03-12 10:41:43 <clandmeter> history is older than 50 commits
2019-03-12 10:42:05 <nmeum> ah
2019-03-12 10:43:08 <nmeum> thanks
2019-03-12 10:43:13 <clandmeter> np
2019-03-12 10:43:32 <clandmeter> should doc it somwhere, i did add a comment on github, but i guess that gets lost.
2019-03-12 10:44:31 <nmeum> would be even better if the CI output mentioned this on error
2019-03-12 10:44:57 <clandmeter> the CI doesnt know about it
2019-03-12 10:45:38 <clandmeter> maybe there is a hook if it fails. i can chech.
2019-03-12 10:46:04 <clandmeter> i think i know a way to fix it, but rebase is always good.
2019-03-12 10:46:44 <nmeum> but to me it seems that the problem is that the ci only fetches 50 commits from the master and then tries to merge in the PR branch
2019-03-12 10:46:58 <nmeum> and if the merge base of the PR branch is older then 50 commits it fails
2019-03-12 10:47:06 <clandmeter> correct
2019-03-12 10:47:07 <nmeum> and that can be detected, can't it?
2019-03-12 10:47:22 <clandmeter> the fetch is not done by me
2019-03-12 10:47:29 <clandmeter> i can only limit it
2019-03-12 10:47:41 <clandmeter> the only way is to do our own fetch logic
2019-03-12 10:47:53 <nmeum> so the fetch logic is currently "hardcoded" by drone ci?
2019-03-12 10:48:01 <clandmeter> correct
2019-03-12 10:49:13 <nmeum> ok, but in that case we could ask them to change it in order to output more useful error message
2019-03-12 10:50:02 <nmeum> in the end you would just have to run git merge-base master <branch> || echo 'Please rebase your branch against master' or something along the lines
2019-03-12 11:22:00 <ScrumpyJack> who maintains drone.io/alpinelinux?
2019-03-12 11:22:18 <_ikke_> clandmeter?
2019-03-12 11:41:22 <clandmeter> is that an uri or a question in general?
2019-03-12 14:03:16 <R3d_Sky> I have a set of rudimentary scripts to determine the "upgrade batch" of the packages for a major change, say a new python3 revision
2019-03-12 14:05:12 <mps> R3d_Sky: ah, nice. Alpine will not need developers anymore :)
2019-03-12 14:37:15 <SpaceToast> R3d_Sky: so basically automatic relbump of all dependants?
2019-03-12 14:45:25 <_ikke_> AI will take over the world :P
2019-03-12 14:47:16 <ScrumpyJack> clandmeter: general question - is alpinelinux build on drone.io yours?
2019-03-12 14:47:50 <clandmeter> you mean current aports CI?
2019-03-12 14:49:54 <ScrumpyJack> I'm attempting to use drone to build my alpine packages and send patches to the aports list, but i'm strugging to keep the repos in sync with AL repo. (I have one repo per package). wondering if you use drone, and how (i just saw nmeum mention drone.io/alpinelinux)
2019-03-12 14:51:12 <clandmeter> ScrumpyJack: https://cloud.drone.io/alpinelinux/aports/
2019-03-12 14:56:25 <nmeum> ScrumpyJack: I don't use drone, we use it for github prs. I  use abuild rootbld and buildrepo to build my own alpine packages
2019-03-12 14:56:37 <nmeum> https://github.com/nmeum/aports/blob/master/make.sh
2019-03-12 15:00:48 <ScrumpyJack> clandmeter: do build.sh is in alpinelinux/alpine-drone-ci ?
2019-03-12 15:00:56 <ScrumpyJack> s/do/so
2019-03-12 15:00:56 <alpine-meetbot> ScrumpyJack meant to say: clandmeter: so build.sh is in alpinelinux/alpine-drone-ci ?
2019-03-12 15:01:40 <clandmeter> no, the two things do diff things
2019-03-12 15:02:23 <clandmeter> nmeum script keeps his personal repo uptodate
2019-03-12 15:02:50 <clandmeter> mine will build/verify PR's
2019-03-12 15:03:02 <clandmeter> https://git.alpinelinux.org/alpine-drone-ci/tree/
2019-03-12 15:03:23 <ScrumpyJack> your drone.yml pulls alpine-drone-ci and runs build.sh - where is build.sh?
2019-03-12 15:03:40 <ScrumpyJack> ah got it
2019-03-12 15:04:22 <ScrumpyJack> so build.sh *is* inside alpinelinux/alpine-drone-ci, right?
2019-03-12 15:04:54 <clandmeter> yes, its a minimal image to build updated packages in a PR
2019-03-12 15:12:30 <ScrumpyJack> https://git.alpinelinux.org/alpine-drone-ci/tree/scripts/build.sh#n61 very cool
2019-03-12 15:17:49 <clandmeter> ScrumpyJack: its inspired by the travis integration.
2019-03-12 15:19:16 <R3d_Sky> SpaceToast, mps: that's the idea, yes :)
2019-03-12 15:19:43 <R3d_Sky> but not in the 'alpine won't need deps' way
2019-03-12 15:20:07 <R3d_Sky> in the 'alpine's devs have other things to do and needn't waste their time on this' thing
2019-03-12 15:20:45 <R3d_Sky> I meant to say devs not deps in the last but one (two?) message
2019-03-12 15:26:23 <R3d_Sky> SpaceToast: while my script does manage that kinda, it gets into several issues because python3 is used for pretty much everything, including musl docs
2019-03-12 15:26:42 <R3d_Sky> which results in circular makedepends between musl's APKBUILD and python3's
2019-03-12 15:26:55 <R3d_Sky> so I have a few hacks to avoid that kind of stuff but
2019-03-12 15:27:08 <R3d_Sky> it can be done significantly better
2019-03-12 15:27:09 <_ikke_> yay for circular deps
2019-03-12 15:27:50 <R3d_Sky> _ikke_: the way I avoid that is I track the path taken and look, if dep is circular then exclude that from calculations
2019-03-12 15:27:56 <R3d_Sky> which is rather dumb but
2019-03-12 15:28:15 <R3d_Sky> I use to hit infinite loop on those kinds of situations before
2019-03-12 15:28:33 <_ikke_> yes, that's kind off how you need to deal with this
2019-03-12 15:28:33 <R3d_Sky> now I managed to clean it up enough to avoid that without having a hacky "maximum parse depth"
2019-03-12 15:29:05 <R3d_Sky> I've never done anything close to this before
2019-03-12 15:29:20 <_ikke_> It's a nice excercise then
2019-03-12 15:29:29 <R3d_Sky> life's being actively hell right now unfortunately
2019-03-12 15:29:37 <R3d_Sky> almost fainted in class today
2019-03-12 15:29:44 <R3d_Sky> yay health
2019-03-12 15:31:37 <_ikke_> sad to hear
2019-03-12 15:41:34 <R3d_Sky> _ikke_: not dev related, but you have any advice for balancing school and stuff?
2019-03-12 15:44:27 <_ikke_> Those things are difficult at totally depend on your priorities
2019-03-12 15:44:42 <_ikke_> If you find school important, you should prioritize that
2019-03-12 15:59:25 <R3d_Sky> https://tpaste.us/baDM https://tpaste.us/7vpB can someone do me a favor and test these scripts out? I don't have access to anything more powerful than an RPi3 and running the batching analysis on a single package takes nearly half a minute
2019-03-12 15:59:31 <R3d_Sky> and there's way too many
2019-03-12 16:00:18 <_ikke_> I will check it later
2019-03-12 16:00:38 <R3d_Sky> you should be able to call longest(packages['{pkg}'], packages['python3')), replacing {pkg} of course to get a "batch ID"
2019-03-12 16:01:01 <R3d_Sky> and the idea is that you rebuild by batch ID, so all packages in batch 1, then batch 2, then so on
2019-03-12 16:01:28 <R3d_Sky> CC mps, SpaceToast: ^
2019-03-12 16:01:51 <R3d_Sky> call me when it breaks, I'm pretty sure it will
2019-03-12 16:03:00 <R3d_Sky> oh, and all the WARNINGs you get while running main() in the dependency analyzer is due to the indexer not properly building with "provides" and "replaces"
2019-03-12 16:03:53 <R3d_Sky> apkdepparse.sh: source $1; echo $makedepends $depends; echo $subpackages; return 0
2019-03-12 16:03:59 <R3d_Sky> and that should be it
2019-03-12 16:04:04 <R3d_Sky> good night alpine folks!
2019-03-12 16:25:37 <AinNero> tmhoang: how does the rtc on s390x show in the fs?
2019-03-12 16:25:59 <tmhoang> <AinNero>: not that I know of
2019-03-12 16:26:16 <tmhoang> there is one thing called tod clock source
2019-03-12 16:26:23 <tmhoang> not exposed to fs
2019-03-12 16:26:34 <tmhoang> get it through a (privileged) instruction
2019-03-12 16:26:57 <AinNero> ah i see, you also added a switch case to the init.d script
2019-03-12 16:28:14 <tmhoang> <AinNero> that mkinitfs pr uses this : https://github.com/alpinelinux/aports/pull/6632
2019-03-12 16:29:46 <AinNero> i would assume for rtc_exists to return true on s390x
2019-03-12 16:30:18 <AinNero> but that not problematic since the if block is its only user
2019-03-12 16:31:05 <tmhoang> I considered touching rtc_exists then decided not to
2019-03-12 16:31:28 <AinNero> reasoning?
2019-03-12 16:31:32 <tmhoang> I assume you are the new mkinitfs guy ?
2019-03-12 16:31:43 <tmhoang> introducing more logic ?
2019-03-12 16:32:08 <tmhoang> if I touch rtc_exists wrt s390x, I have to rename to clock_exists
2019-03-12 16:32:13 <tmhoang> or sort of
2019-03-12 16:32:38 <AinNero> oh, mh.
2019-03-12 16:32:46 <AinNero> yeah lets leave it like that
2019-03-12 16:33:26 <tmhoang> so if you are the new mkinitfs guy, I know a new one that I would regularly annoy :D
2019-03-12 16:33:56 <tmhoang> or ask stupid questions :P
2019-03-12 16:34:34 <AinNero> bad idea for annoying for merges, im just sending thumbs up and down for patches to copa, not merging myself
2019-03-12 16:34:38 <AinNero> good idea for questions
2019-03-12 16:35:17 <AinNero> boot sequence outside of kernel and early userspace are my main areas of expertise
2019-03-12 16:35:21 <AinNero> afk train
2019-03-12 16:40:38 <tmhoang> +1
2019-03-12 16:56:00 <jwh> https://github.com/cockroachdb/cockroach/commit/2a92770363e199502bf68ac307d8a5f0af741be6
2019-03-12 16:56:03 <jwh> lol
2019-03-12 16:57:49 <_ikke_> What amazes me more is that there are 35k issue reports
2019-03-12 16:58:10 <_ikke_> 2k open issues
2019-03-12 16:58:28 <AinNero> lol
2019-03-12 16:58:33 <jwh> yes
2019-03-12 16:58:36 <AinNero> look at ansible or docker, they have even more issues
2019-03-12 16:58:48 <jwh> serious lack of actually paying attention (it's an attitude thing)
2019-03-12 16:59:34 <_ikke_> Wasn't aware that cockroach was so popular
2019-03-12 16:59:43 <jwh> it's pretty good
2019-03-12 17:01:04 <jwh> just needs someone useful to take over he
2019-03-12 17:01:06 <jwh> heh*
2019-03-12 17:01:49 <SpaceToast> oh so it's openrc :^)
2019-03-12 17:02:21 <jwh> heh
2019-03-12 17:03:19 <jwh> they made it even harder on themselves by maintaining 2 branches now as well
2019-03-12 17:05:47 <jwh> but v19 is looking niiiiice
2019-03-12 17:05:53 <jwh> if it ever makes it out of beta
2019-03-12 17:09:15 <jwh> hm
2019-03-12 17:09:16 <jwh> (1/6) Installing salt-api-openrc (2019.2.0-r0)
2019-03-12 17:09:19 <jwh> whaaa
2019-03-12 17:09:29 <jwh> did I screw my apkbuild up or am I going mad
2019-03-12 17:09:43 <jwh> only added a specific .apk
2019-03-12 17:09:49 <jwh> with no dependency on that
2019-03-12 17:11:17 <_ikke_> jwh: I expanded on that
2019-03-12 17:12:30 <jwh> oh
2019-03-12 17:12:39 <jwh> what where
2019-03-12 17:12:42 <_ikke_> jwh: there is an install_if directive that automatically installs the openrc init files when you install the package
2019-03-12 17:13:16 <jwh> hmmm
2019-03-12 17:13:21 <jwh> but apparently they're not even installed
2019-03-12 17:13:38 <_ikke_> https://github.com/alpinelinux/aports/commit/709508c840bf5333f2ee5115afdcbf0cf331a263
2019-03-12 17:13:48 <_ikke_> HMm, they're not?
2019-03-12 17:13:52 <jwh> yeah but I didn't install salt :P
2019-03-12 17:14:12 <_ikke_> what did you install?
2019-03-12 17:14:23 <jwh> cockroach apk I just built
2019-03-12 17:14:32 <jwh> db2:~# apk --allow-untrusted add *.apk
2019-03-12 17:14:33 <jwh> (1/6) Installing salt-api-openrc (2019.2.0-r0)
2019-03-12 17:14:33 <jwh> etc
2019-03-12 17:14:41 <_ikke_> hmmm
2019-03-12 17:14:42 <jwh> but,
2019-03-12 17:14:42 <jwh> db2:~# apk del salt-api-openrc
2019-03-12 17:14:42 <jwh> OK: 101 MiB in 32 packages
2019-03-12 17:15:17 <jwh> not in world either
2019-03-12 17:15:21 <jwh> so I'm pretty confused
2019-03-12 17:15:36 <_ikke_> No, it would not be in world if it was installed as a dependency
2019-03-12 17:15:45 <jwh> o
2019-03-12 17:16:35 <jwh> whats the apk magic to get dep list?
2019-03-12 17:17:09 <jwh> ah nm
2019-03-12 17:17:26 <jwh> dep list looks fine
2019-03-12 17:17:49 <_ikke_> Do you have nothing salt related installed?
2019-03-12 17:18:00 <jwh> nope
2019-03-12 17:18:05 <jwh> fresh container
2019-03-12 17:18:18 <_ikke_> trying to reproduce it
2019-03-12 17:18:22 <jwh> except those -openrc things obviously
2019-03-12 17:18:52 <jwh> I'll destroy and recreate, see if it happens again
2019-03-12 17:18:59 <_ikke_> Might be that I screwed things up
2019-03-12 17:19:12 <_ikke_> As soon as I installed openrc in my docker container it installed all those subpackages
2019-03-12 17:19:58 <jwh> ahhhh
2019-03-12 17:20:58 <_ikke_> I think I know what's wrong
2019-03-12 17:21:12 <_ikke_> yup
2019-03-12 17:21:30 <_ikke_> it should be $pkgver-r$pkgrel, I did $pkgver-$pkgrel (missing 'r')
2019-03-12 17:22:32 <jwh> ahhhh
2019-03-12 17:22:42 <jwh> good, I thought I fucked up :D
2019-03-12 17:23:05 <_ikke_> The package had no maintainer, so I took maintainership of it
2019-03-12 17:23:13 <jwh> ahhh
2019-03-12 17:25:54 <_ikke_> compare apk info -I zabbix-agent-openrc vs apk info -I salt-api-openrc
2019-03-12 17:26:25 <jwh> doh
2019-03-12 17:27:41 <jwh> can someone look at PR#6564 when they've got a sec pls :D
2019-03-12 17:27:57 <jwh> hm, PR6564
2019-03-12 17:28:01 <jwh> ah
2019-03-12 17:28:09 <danieli> ha
2019-03-12 17:28:16 <danieli> it posted both a PR and issue
2019-03-12 17:28:20 <jwh> yeah
2019-03-12 17:28:28 <_ikke_> lol
2019-03-12 17:28:55 <_ikke_> there are currently 3 open PRs for cockroach\
2019-03-12 17:29:08 <jwh> yeah
2019-03-12 17:29:24 <jwh> both nearly 2 years old
2019-03-12 17:29:46 <_ikke_> ok
2019-03-12 17:29:49 <jwh> and didn't pass tests
2019-03-12 17:30:04 <_ikke_> I will look at it
2019-03-12 17:30:12 <jwh> thanks
2019-03-12 17:30:13 <_ikke_> first finishing fixing salt :)
2019-03-12 17:30:17 <jwh> :D
2019-03-12 17:30:47 <_ikke_> This looks better: http://tpaste.us/1nj0
2019-03-12 17:31:02 <jwh> a bit :)
2019-03-12 17:31:23 <_ikke_> only a bit?
2019-03-12 17:31:26 <_ikke_> :P
2019-03-12 17:34:01 <_ikke_> Pushed
2019-03-12 17:34:19 <jwh> o/
2019-03-12 17:34:59 <_ikke_> Is the cockroach buildscript seriously installing githooks? :-/
2019-03-12 17:35:14 <_ikke_> Looking at the patch
2019-03-12 17:35:14 <jwh> yup
2019-03-12 17:35:19 <_ikke_> sigh
2019-03-12 17:35:29 <jwh> it expects to be run in a clone
2019-03-12 17:35:47 <danieli> that should be fixed upstream to be honest
2019-03-12 17:35:52 <jwh> yes it should
2019-03-12 17:35:57 <_ikke_> yes, which it imnsho it should not
2019-03-12 17:36:02 <_ikke_> I concur
2019-03-12 17:36:16 <jwh> not holding my breath, but am going to open an issue about it
2019-03-12 17:36:39 <jwh> the build system in general is horrific, but the product is otherwise good
2019-03-12 17:36:54 <_ikke_> Even though I like git a lot, I don't like everyone relying on git for their build system
2019-03-12 17:36:56 <jwh> (they also only officially support building inside docker, so they won't have seen the git hooks issue)
2019-03-12 17:37:07 <_ikke_> sigh
2019-03-12 17:37:18 <jwh> yes, that was my response too
2019-03-12 17:37:50 <jwh> it's lame, but don't think it's a reason to not include it
2019-03-12 17:38:02 <_ikke_> indeed
2019-03-12 17:38:12 <_ikke_> You just patched it out, that's fine for no
2019-03-12 17:38:45 <jwh> it used to be possible to build without using their make nonsense, but it's so horrible now that it just doesn't work with go
2019-03-12 17:38:55 <jwh> although they've been moving towards modules, so maybe soon
2019-03-12 17:39:56 <_ikke_> Does it make sense to have the pkguser/group depend on the package name?
2019-03-12 17:40:16 <jwh> how do you mean?
2019-03-12 17:40:28 <_ikke_> https://github.com/alpinelinux/aports/pull/6564/files#diff-cd129519f60b52e6b3b83b0660374727R12
2019-03-12 17:40:44 <jwh> oh
2019-03-12 17:40:57 <jwh> that should be pkgusers/pkgroup
2019-03-12 17:41:02 <jwh> pkggroups*
2019-03-12 17:43:23 <jwh> did anything come of doing user management btw? coz atm its all stil adduser etc, which is kinda messy
2019-03-12 17:43:51 <_ikke_> jwh: no, nothing afaik
2019-03-12 17:43:57 <jwh> ah
2019-03-12 17:44:03 <jwh> pushed
2019-03-12 17:54:45 <jwh> _ikke_: replied
2019-03-12 17:55:34 <jwh> to expand a bit, the command in the conf.d args is just a sensible default for starting a local node, if you need a cluster or other stuff obviously you'll need to change it to suit
2019-03-12 17:56:10 <_ikke_> Alright, good to know
2019-03-12 17:57:14 <jwh> it's a bit awkward to setup, so I just thought a default that probably caters to most users will be ok
2019-03-12 17:58:23 <_ikke_> I don't see your last push yet
2019-03-12 17:58:29 <jwh> oh
2019-03-12 17:58:31 <jwh> hm
2019-03-12 17:58:41 <_ikke_> Or do you mean https://github.com/alpinelinux/aports/compare/95a99041c131ead1038bf76e194fffa8e97aed29..908b914056c0d88ef27a47225e9c3c45e22a3333
2019-03-12 17:58:54 <jwh> yeah
2019-03-12 17:59:16 <_ikke_> There you still use $pkgname in pkgusers
2019-03-12 17:59:36 <jwh> ohhh, I broke the squash
2019-03-12 17:59:37 <jwh> hang on
2019-03-12 17:59:57 <_ikke_> ok
2019-03-12 18:01:02 <jwh> there we go
2019-03-12 18:01:23 <_ikke_> Alright
2019-03-12 18:04:57 <_ikke_> jwh: waiting for CI to finish. If that passes without warnings, I'll push it
2019-03-12 18:06:01 <_ikke_> drone.io already completed though
2019-03-12 18:06:03 <jwh> okies
2019-03-12 18:06:50 <_ikke_> travis seems to have slower hardware
2019-03-12 18:07:04 <jwh> yeah
2019-03-12 18:12:53 <_ikke_> jwh: salt-*-openrc problem should be fixed now
2019-03-12 18:13:03 <jwh> ah cool ok
2019-03-12 18:13:16 <jwh> thanks
2019-03-12 18:13:25 <_ikke_> Just tested again in a new docker container, and it does not install again once I install openrc
2019-03-12 18:18:27 <_ikke_> jwh: I assume the Gopkg.lock is actually being used?
2019-03-12 18:19:55 <_ikke_> Done, pushed
2019-03-12 18:20:11 <jwh> yeah
2019-03-12 18:20:28 <jwh> the make stuff is really just for cgo and wrappers to set gohome etc properly
2019-03-12 18:20:38 <jwh> I tried to unpick it but life is far too short
2019-03-12 18:20:38 <jwh> heh
2019-03-12 18:21:38 <SpaceToast> lol cgo
2019-03-12 18:21:51 <SpaceToast> yesterday when fixing up minio, I was convinced it was failing
2019-03-12 18:22:02 <SpaceToast> after all, 100% of the output I saw during the build was an error - that it couldn't find cgo
2019-03-12 18:22:09 <SpaceToast> turns out that's actually a warning, and it compiles just fine anyway
2019-03-12 18:22:29 <jwh> yeah
2019-03-12 18:22:49 <SpaceToast> go: stands for bleep yourself ;)
2019-03-12 18:22:51 <jwh> its misleading
2019-03-12 18:23:28 <SpaceToast> but yeah, minio should work now!
2019-03-12 18:23:36 <SpaceToast> gonna set it up at home for testing . . . any moment now
2019-03-12 18:24:24 <_ikke_> jwh: I think I'm not going to comment on the other PRs, then stalebot will close those
2019-03-12 18:24:43 <jwh> yeah
2019-03-12 18:24:59 <jwh> I looked at them but they're all for old versions so they'd need to be rewritten anyway
2019-03-12 18:32:46 <_ikke_> jwh: it's building now
2019-03-12 18:32:52 <jwh> thanks :D
2019-03-12 18:33:01 <jwh> I really wish cloudflare would stop being terrible and clarify the license
2019-03-12 18:33:52 <SpaceToast> oof cloudflare
2019-03-12 18:34:03 <jwh> yeah
2019-03-12 18:34:17 <jwh> too busy posting self congratulatory blog posts
2019-03-12 18:42:52 <otlabs> hi ppl
2019-03-12 18:42:59 <_ikke_> otlabs: hi
2019-03-12 18:43:08 <otlabs> _ikke_: greetings!
2019-03-12 18:43:34 <jwh> SpaceToast: you'd think considering the product enables their paid services that they'd be a bit more cooperative
2019-03-12 18:43:48 <SpaceToast> lol nah
2019-03-12 18:43:52 <SpaceToast> hey otlabs
2019-03-12 18:43:55 <jwh> doesn't help that theres an essay from the nixos people first though
2019-03-12 18:43:59 <jwh> I zoned out reading it too
2019-03-12 18:44:16 <SpaceToast> oof nixos people
2019-03-12 18:44:20 <otlabs> SpaceToast: how r u
2019-03-12 18:44:29 <SpaceToast> a good friend of mine's involved, but he has very specific reqs
2019-03-12 18:44:48 <jwh> https://github.com/cloudflare/cloudflared/issues/53
2019-03-12 18:44:57 <SpaceToast> otlabs: tired, fell down on ice several times today, had to wade through ankle-high freezing water (-2 outside), and lots of semi-scary stuff :)
2019-03-12 18:45:01 <SpaceToast> trying to relax now
2019-03-12 18:45:08 <SpaceToast> oh no
2019-03-12 18:45:14 <_ikke_> SpaceToast: oof
2019-03-12 18:45:15 <jwh> that comment could have been condensed to 1 paragraph
2019-03-12 18:45:24 <jwh> SpaceToast: wait, fun ice falling?
2019-03-12 18:45:39 <SpaceToast> no, slipping and damaging body :D
2019-03-12 18:45:41 <jwh> oh :(
2019-03-12 18:45:55 <SpaceToast> when the temp is right around 0, going above and below, is when all the horrible stuff happens
2019-03-12 18:46:13 <otlabs> SpaceToast: auch. get something hot to please your soul
2019-03-12 18:46:36 <SpaceToast> I've already consumed a pair of my signature piri piri chicken sandwiches ;)
2019-03-12 18:46:40 <SpaceToast> and have dry socks on :D
2019-03-12 18:47:11 <otlabs> wow! you are acting fast!
2019-03-12 18:47:20 <jwh> :D
2019-03-12 18:47:48 <jwh> https://linux.slashdot.org/story/19/03/12/167203/nodejs-and-js-foundations-are-merging-to-form-openjs
2019-03-12 18:48:19 <SpaceToast> well I've been home for like 1.5h ;)
2019-03-12 18:48:49 <SpaceToast> so Dojo is a js standard now, huh?
2019-03-12 18:48:54 <otlabs> great!
2019-03-12 18:56:23 <otlabs> _ikke_: among my PRs there is one for Apache MyNewt OS (small OS for Bluetooth, mesh, etc. enables devices). You have left 2 comments, I have addressed them, hopefully, in total. Would you have an opportunity to express your opinion on future enhancements this PR will need? Here goes the link to this PR for your kind reference: https://github.com/alpinelinux/aports/pull/5921
2019-03-12 18:57:28 <_ikke_> otlabs: Heh, it's easy to loose track of these things
2019-03-12 18:58:55 <otlabs> hahaha, yeah!
2019-03-12 19:04:32 <_ikke_> jwh: what is actually reading Gopkg.lock?
2019-03-12 19:04:49 <_ikke_> I see it's used by dep
2019-03-12 19:05:06 <jwh> I was just looking, that might just be for go get
2019-03-12 19:05:18 <jwh> hm, dep
2019-03-12 19:05:39 <_ikke_> afaict, go get is not using Gopkg.lock
2019-03-12 19:05:46 <jwh> theres a lot of things left over from old versions where it actually used go build
2019-03-12 19:07:11 <jwh> it looks like the deps are bundled in the release archive anyway
2019-03-12 19:07:30 <jwh> but I'm no go expert
2019-03-12 19:07:46 <_ikke_> I was just wondering in general
2019-03-12 19:08:17 <_ikke_> I need to be able to properly assess if dependencies are locked or not
2019-03-12 19:08:34 <jwh> they should be as it doesn't fetch anything
2019-03-12 19:08:58 <jwh> well, I'd hope not anyway
2019-03-12 19:09:03 <jwh> hard to tell with go
2019-03-12 19:09:17 <_ikke_> I know, right
2019-03-12 19:09:26 <_ikke_> it just does some magic in the background, and boom, a go binary
2019-03-12 19:09:32 <jwh> lol pretty much
2019-03-12 19:15:02 <_ikke_> otlabs: done, it has been pushed
2019-03-12 19:18:00 <otlabs> Oh. Thanks a lot!
2019-03-12 19:23:00 <otlabs> 
ACTION dancing jigga

2019-03-12 20:37:30 <_ikke_> ncopa: thanks re fstrm
2019-03-12 20:38:49 <ncopa> _ikke_: lets see if it works
2019-03-12 20:46:04 <_ikke_> Just to be a sure, is it a problem to have pkgver="r2" for a package? (matches what upsstream uses)
2019-03-12 20:48:02 <ncopa> hum
2019-03-12 20:48:15 <ncopa> what does the "r" mean?
2019-03-12 20:49:03 <_ikke_> I guess release
2019-03-12 20:49:09 <ncopa> apk will interprete is similar to 0r2 where "r" corresponds to "c" in 1.1.1c
2019-03-12 20:49:21 <ncopa> maybe only use "2" then
2019-03-12 20:49:26 <_ikke_> right
2019-03-12 20:51:45 <ncopa> im restarting alpine-msg container
2019-03-12 20:51:50 <ncopa> I also upgraded it
2019-03-12 20:51:59 <ncopa> updated*
2019-03-12 20:52:09 <_ikke_> nod
2019-03-12 20:52:14 <danieli> did it break?
2019-03-12 20:52:32 <_ikke_> stable builders can't announce
2019-03-12 20:52:34 <_ikke_> apparently
2019-03-12 20:52:46 <ncopa> for some reason there is a rpblem with websockets to mqtt on the stable builders: https://build.alpinelinux.org/
2019-03-12 20:53:00 <danieli> what exactly is the problem?
2019-03-12 20:53:18 <ncopa> only edge builders show up on build.alpinelinux.org
2019-03-12 20:53:46 <_ikke_> Now I see build-3-9-x86_64
2019-03-12 20:54:08 <ncopa> i restarted it
2019-03-12 20:54:11 <_ikke_> Hard refresh, and now it's empty
2019-03-12 20:54:26 <_ikke_> We probably need to wait for new commits, right?
2019-03-12 20:54:43 <ncopa> shouldnt be needed
2019-03-12 20:54:47 <_ikke_> ij
2019-03-12 20:54:49 <_ikke_> ok
2019-03-12 20:55:05 <danieli> does msg store retained messages on disk?
2019-03-12 20:55:11 <ncopa> no
2019-03-12 20:55:16 <danieli> i see build-edge-aarch64
2019-03-12 20:55:25 <ncopa> aarch64 is the only i see
2019-03-12 20:55:57 <danieli> now i see build-3-9-x86_64
2019-03-12 20:56:07 <ncopa> im messing with it
2019-03-12 20:56:55 <_ikke_> ncopa: is this the issue? apk version --test r1-r1 r2-r1 -> '<'?
2019-03-12 20:57:27 <ncopa> issue is: apk version --test r1 s1
2019-03-12 20:57:50 <ncopa> or r1 vs p1
2019-03-12 20:57:56 <_ikke_> ok
2019-03-12 20:58:08 <ncopa> ok i will contineun tomorrow
2019-03-12 20:58:13 <ncopa> have a nice evening
2019-03-12 20:58:20 <danieli> assuming you're in europe, good night
2019-03-12 20:58:24 <_ikke_> nite
2019-03-12 20:58:34 <ncopa> btw, do we have a redis server running for our infra?
2019-03-12 20:58:42 <ncopa> on the vpn
2019-03-12 20:58:43 <_ikke_> We do have one
2019-03-12 20:58:52 <_ikke_> on gbr1 I believe
2019-03-12 20:58:57 <_ikke_> for patchwork, right danieli?
2019-03-12 20:59:05 <danieli> we do
2019-03-12 20:59:07 <danieli> it's for mirrorbits
2019-03-12 20:59:10 <ncopa> im thinking of use redis instead of mqtt to keep the state of the builders
2019-03-12 20:59:10 <danieli> not in use at the moment
2019-03-12 20:59:20 <_ikke_> http://netbox.alpin.pw/virtualization/virtual-machines/38/
2019-03-12 20:59:20 <danieli> i love data modelling in redis, such a nice api
2019-03-12 20:59:25 <_ikke_> danieli: me too
2019-03-12 20:59:36 <danieli> also https://github.com/JohnSully/KeyDB
2019-03-12 20:59:40 <_ikke_> ncopa: out of curiosity, what does redis provide over mqtt?
2019-03-12 20:59:53 <danieli> just to keep the state, not use its pubsub
2019-03-12 20:59:55 <danieli> i think?
2019-03-12 20:59:57 <ncopa> its a key value store
2019-03-12 21:00:03 <_ikke_> yes
2019-03-12 21:00:19 <ncopa> redis has also support for pubsub, but it is sort of designed to store state
2019-03-12 21:00:21 <_ikke_> But we want pubsub, right?
2019-03-12 21:00:25 <_ikke_> yes
2019-03-12 21:00:30 <ncopa> well, for notifications
2019-03-12 21:00:32 <danieli> ... why both?
2019-03-12 21:00:42 <danieli> we can't just expose redis to the browser
2019-03-12 21:00:51 <ncopa> but we also want to keep the state of what builders are currently doing
2019-03-12 21:01:10 <_ikke_> ok
2019-03-12 21:01:26 <_ikke_> So well-known keys for the state per builder?
2019-03-12 21:01:34 <ncopa> something like that
2019-03-12 21:01:50 <danieli> i can write a poc
2019-03-12 21:01:52 <ncopa> we currently keep state using retained messages
2019-03-12 21:01:56 <_ikke_> yes
2019-03-12 21:02:15 <danieli> could use mqtt from builders -> build.a.o and build.a.o caches (stores state) in redis
2019-03-12 21:02:16 <ncopa> i also think recent redis has support for live streams
2019-03-12 21:02:37 <danieli> redis streams are from 5.0, i wouldn't expose it
2019-03-12 21:02:37 <ncopa> so we could hace things like live logs from builders
2019-03-12 21:02:50 <ncopa> live build logs
2019-03-12 21:03:27 <ncopa> with mqtt retained messages we can only set what builder is doing right now
2019-03-12 21:03:39 <ncopa> with redis we could have a fifo, with the last 10 stages
2019-03-12 21:03:50 <ncopa> or whatever we want keep
2019-03-12 21:04:03 <danieli> i can write a poc web ui and websocket server for it
2019-03-12 21:04:04 <ncopa> like a log
2019-03-12 21:04:12 <danieli> some nice visualization for the different steps
2019-03-12 21:04:18 <ncopa> danieli: would be nice
2019-03-12 21:04:29 <danieli> could still use mqtt for that, and even just use sqlite
2019-03-12 21:04:41 <danieli> i can't imagine there's a *ton* of traffic to build.a.o
2019-03-12 21:04:45 <_ikke_> ncopa: We also started with a couple of persons to look at python3.7 upgrade
2019-03-12 21:04:53 <ncopa> do we need sqlite if we use redis?
2019-03-12 21:05:09 <danieli> i don't see why we /need/ redis
2019-03-12 21:05:14 <danieli> if we use sqlite we won't need another container just for db
2019-03-12 21:05:32 <_ikke_> sqlite concurency is meh though
2019-03-12 21:05:50 <ncopa> current build.alpinelinux.org stores the last 3 steps in the browswer only becase we cannot do that in mqtt
2019-03-12 21:06:02 <ncopa> with redis we could have a fifo
2019-03-12 21:06:15 <ncopa> and store the last steps on the backend
2019-03-12 21:06:30 <ncopa> so when you refresh the page you have the last N builds
2019-03-12 21:07:07 <ncopa> with redis we can also do the pubsub notifications, which means that we dont need mqtt
2019-03-12 21:07:41 <ncopa> so my thinking is that we could replace mqtt with redis
2019-03-12 21:07:42 <danieli> we use mqtt for a lot of other things
2019-03-12 21:07:50 <ncopa> right
2019-03-12 21:07:56 <danieli> replacing it just seems like a lot of unnecessary work to me
2019-03-12 21:08:06 <danieli> for very little gain
2019-03-12 21:08:14 <_ikke_> We don't need to replace it completely in one go though
2019-03-12 21:08:26 <_ikke_> We can keep mqtt for the other things
2019-03-12 21:08:30 <ncopa> we could set up a bridge mqtt-redis
2019-03-12 21:08:37 <ncopa> and take it from there
2019-03-12 21:08:55 <_ikke_> We have a lot of mqtt-exec scripts running
2019-03-12 21:09:12 <ncopa> we dont need to remove mqtt
2019-03-12 21:09:15 <danieli> i'll write a poc using sqlite that can be changed to redis at a later date
2019-03-12 21:09:40 <danieli> shouldn't burn much disk IO
2019-03-12 21:36:55 <_ikke_> ncopa: fstrm still failed to build
2019-03-12 22:20:36 <jwh> hm
2019-03-12 22:59:57 <otlabs> time to go, see you later!
2019-03-13 01:35:07 <R3d_Sky> _ikke_: I'm not really confident about the results of my code, but after a ton of optimizations, it says 2697 packages need a relbump
2019-03-13 01:39:49 <R3d_Sky> okay next issue
2019-03-13 01:40:55 <R3d_Sky> I can't tell apart real depends from stuff like "build system written in python"
2019-03-13 01:41:14 <R3d_Sky> so there's a ton of packages that depend on mesa included in the update tree
2019-03-13 01:54:21 <R3d_Sky> and then fontconfig so there's all of the font-* packages
2019-03-13 02:03:21 <mps> R3d_Sky: you could look at repology.org for Alpine
2019-03-13 02:15:40 <R3d_Sky> mps: thanks, will do
2019-03-13 02:25:48 <mps> R3d_Sky: they have some API (json I think) which could be useful for your idea
2019-03-13 03:14:42 <R3d_Sky> gotta go now
2019-03-13 03:14:46 <R3d_Sky> cya
2019-03-13 04:05:31 <jwh> hm, is there something up with the mariadb package or am I missing something?
2019-03-13 04:05:51 <jwh> run setup, seems to work but it doesn't
2019-03-13 04:06:21 <SpaceToast> yeah I'm not sure what's up with latest mariadb's setup()
2019-03-13 04:06:30 <SpaceToast> you can just do it by hand though :)
2019-03-13 04:06:37 <SpaceToast> make sure to pass --datadir (that might be the problem)
2019-03-13 04:06:38 <jwh> oh
2019-03-13 04:06:41 <jwh> init script is just broken
2019-03-13 04:06:44 <jwh> yeah
2019-03-13 04:06:53 <jwh>         mysql_install_db --user=mysql --rpm
2019-03-13 04:06:54 <jwh> uhhh
2019-03-13 04:07:06 <SpaceToast> this is roughly correct, it's just missing datadir
2019-03-13 04:07:09 <jwh> a) --rpm (no), b) no datadir and it isn't in the distributed config
2019-03-13 04:07:28 <SpaceToast> I'm not sure what --rpm actually... does
2019-03-13 04:07:40 <SpaceToast> but it seems to work fine when used directly
2019-03-13 04:08:12 <jwh> --rpm is only relevant for upstream rpms...
2019-03-13 04:08:15 <jwh> who did this
2019-03-13 04:08:37 <jwh> I mean, if you check the docs it even says *internal use*
2019-03-13 04:09:02 <jwh> https://mariadb.com/kb/en/library/mysql_install_db/
2019-03-13 04:09:59 <SpaceToast> well, let's check git-blame, shall we?
2019-03-13 04:10:12 <jwh> :D
2019-03-13 04:10:37 <jwh> I won't even go into how mariadb is *not* a mysql drop in or replacement :D
2019-03-13 04:10:43 <SpaceToast> Łukasz Jendrysik in Jan 2015
2019-03-13 04:10:55 <SpaceToast> back when it was in testing/
2019-03-13 04:11:01 <jwh> bleh
2019-03-13 04:11:04 <SpaceToast> what's confusing is it worked without any problems on at least one of my machines
2019-03-13 04:11:20 <jwh> start seems ok
2019-03-13 04:11:24 <jwh> but setup() is broken
2019-03-13 04:11:33 <jwh> so if you had an existing datadir
2019-03-13 04:12:17 <jwh>         required_dirs=$(getconf datadir "/var/lib/mysql")
2019-03-13 04:12:25 <SpaceToast> oh yeah that's a funny one too
2019-03-13 04:12:28 <jwh> it works by accident
2019-03-13 04:12:29 <SpaceToast> wanna fix it? :)
2019-03-13 04:12:43 <jwh> not right now :D
2019-03-13 04:12:58 <SpaceToast> the required_dirs thing is Valery Kartel in October 2015, now in main/
2019-03-13 04:13:03 <SpaceToast> but yeah, please do :)
2019-03-13 04:13:07 <jwh> I'm only installing for my kodi instances, normally I'd have nothing to do with maria
2019-03-13 04:13:10 <SpaceToast> (at some point, at least!)
2019-03-13 04:13:17 <jwh> :D
2019-03-13 04:13:19 <SpaceToast> I have to use it at $dayjob, but don't touch SQL otherwise
2019-03-13 04:13:25 <SpaceToast> so I just "got it working" and such, since I really don't care
2019-03-13 04:13:35 <jwh> yea
2019-03-13 04:13:43 <SpaceToast> (it's for a crappy product that only the people working on it actually care about)
2019-03-13 04:13:59 <SpaceToast> maybe one of us should file a bug report then ^^;;
2019-03-13 04:14:12 <jwh> I expect at some point getconf works
2019-03-13 04:14:15 <jwh> worked*
2019-03-13 04:14:16 <SpaceToast> (I didn't at the time because at work, and forgot about it after getting home, immediately passing out, and waking back up, until now)
2019-03-13 04:14:28 <SpaceToast> it might be taken from a glibc-based thing
2019-03-13 04:14:34 <SpaceToast> like a pacman build script
2019-03-13 04:14:35 <jwh> yeah
2019-03-13 04:14:46 <jwh> would also explain the --rpm I expect
2019-03-13 04:14:59 <SpaceToast> I'm still not convinced --rpm is wrong
2019-03-13 04:15:11 <SpaceToast> it's for "internal use" ... by package management
2019-03-13 04:15:15 <SpaceToast> such as apk
2019-03-13 04:15:20 <SpaceToast> so it remains to be seen
2019-03-13 04:15:23 <jwh> it isn't even used on rpm distributions, it's supposed to be executed as part of the setup scripts in the rpm
2019-03-13 04:15:28 <SpaceToast> but missing datadir and the getconf stuff is definitely wrong
2019-03-13 04:15:38 <jwh> but not during a normal init, which is what happens in setup()
2019-03-13 04:15:43 <SpaceToast> ah
2019-03-13 04:16:14 <jwh> tbf it just looks like a bad copy/paste, but I can't fix right now
2019-03-13 04:16:48 <jwh> if it's built with the proper paths we can probably do away with the elaborate start() anyway
2019-03-13 04:17:11 <SpaceToast> the main question is - do we want to allow multiple instances of mariadb on a single host?
2019-03-13 04:17:28 <SpaceToast> (so ln -s /etc/init.d/mariadb /etc/init.d/mariadb.other_namespace)
2019-03-13 04:17:48 <jwh> most people should probably not
2019-03-13 04:18:21 <SpaceToast> well the question is if we want the init.d script to allow it :)
2019-03-13 04:18:32 <SpaceToast> I'm still confused as to how it "just worked" on another host though...
2019-03-13 04:19:17 <jwh> wsrep-data-home-dir                                        /var/lib/mysql/
2019-03-13 04:19:20 <jwh> uh
2019-03-13 04:19:42 <jwh> datadir                                                    /var/lib/mysql/
2019-03-13 04:20:22 <jwh> it works because the default in the daemon is fine, but because maria still uses antiquated scripts instead of importing the useful additions to mysql 5.7, it isn't carried over to the scripts
2019-03-13 04:20:52 <jwh> (mysql 5.7, or 5.6 actually, introduced mysqld --initialize
2019-03-13 04:20:55 <jwh> )
2019-03-13 04:21:22 <jwh> so it has access to all the build time config, the scripts were never generated at build time or anything
2019-03-13 04:22:09 <jwh> maria is a mess and honestly it's actually irresponsible for so many distributions to call it mysql, or install it when asked for mysql
2019-03-13 04:22:12 <jwh> heh
2019-03-13 04:22:28 <jwh> it isn't binary or behaviour compatible, hasnt been for years
2019-03-13 04:22:41 <jwh> doesn't even interop with mysql properly anymore
2019-03-13 04:23:19 <SpaceToast> mysql-proper has.... problems as well :/
2019-03-13 04:23:25 <SpaceToast> and don't get me started on percona sql
2019-03-13 04:23:33 <SpaceToast> does cockroach work on alpine yet?
2019-03-13 04:23:36 <jwh> yes
2019-03-13 04:23:38 <jwh> it's in testing
2019-03-13 04:23:45 <SpaceToast> I might (at least try to) give it a spin at some point :)
2019-03-13 04:23:54 <SpaceToast> does the init.d script handle replication (relatively easily)?
2019-03-13 04:24:10 <jwh> cockroach? no it defaults to a local node
2019-03-13 04:24:13 <jwh> but it won't start OOTB
2019-03-13 04:24:37 <SpaceToast> hmm... that's no good
2019-03-13 04:24:56 <jwh> atm you have to manually create the data dir, I didn't do it as part of the package as theres no real one size fits all default
2019-03-13 04:25:12 <SpaceToast> ok
2019-03-13 04:25:17 <jwh> many people just use ram storage for example, but it will default to looking in /var/lib/cockroach
2019-03-13 04:25:19 <SpaceToast> can you edit conf.d to get replication working?
2019-03-13 04:25:23 <SpaceToast> or do you have to modify init.d
2019-03-13 04:25:24 <jwh> so you just need to create it and chown
2019-03-13 04:25:26 <jwh> yeah it's i conf.d
2019-03-13 04:25:28 <jwh> in*
2019-03-13 04:25:32 <SpaceToast> ok, nice
2019-03-13 04:25:41 <SpaceToast> it does replication over raft, right?
2019-03-13 04:26:02 <jwh> also... the default conf.d leaves it open with no authentication, so I thought an extra step to get it to start might be a good idea
2019-03-13 04:26:09 <SpaceToast> aha
2019-03-13 04:26:32 <jwh> but really if you're installing it, you probably want to use the cluster, so a default config isn't useful
2019-03-13 04:26:41 <SpaceToast> oh, also confirmed that minio (including init.d) works just fine :D
2019-03-13 04:26:47 <jwh> oh cool
2019-03-13 04:26:54 <jwh> and yeah, it's raft iirc
2019-03-13 04:26:59 <SpaceToast> cool!
2019-03-13 04:27:03 <jwh> unless they've changed it, they keep changing stuff
2019-03-13 04:27:10 <SpaceToast> gossip is such a nice feature set for clustering
2019-03-13 04:27:16 <SpaceToast> like... in general :)
2019-03-13 04:27:36 <jwh> db2:~# cat /etc/conf.d/cockroach
2019-03-13 04:27:36 <jwh> cockroach_opts="start --insecure --store=/var/lib/cockroach"
2019-03-13 04:27:56 <jwh> just need to adjust that to suit
2019-03-13 04:27:57 <SpaceToast> oh you're going the "very straightforward" route ok
2019-03-13 04:28:32 <jwh> well I figured if you're just installing locally for development thats enough, but if you're installing for cluster you'll need to do some legwork anyway so you can change the args
2019-03-13 04:29:40 <jwh> unfortunaely cockroach isn't quite as uh, convenient, as mysql
2019-03-13 04:31:02 <_ikke_> nmeum: polyml fails on s390x due to a segfault, would it be an idea to disable it for s390x?
2019-03-13 04:31:24 <jwh> but re cockroach, it likely won't work with many off the shelf applications, it's still missing a lot of "features" (frequently used sql dialect that isnt even useful in the way people use it)
2019-03-13 04:31:49 <SpaceToast> hmm, I thought it just exposed pgsql?
2019-03-13 04:32:07 <jwh> it does, but theres still some bits missing
2019-03-13 04:32:25 <SpaceToast> ah
2019-03-13 04:32:32 <SpaceToast> maybe once it settles down then
2019-03-13 04:32:37 <jwh> v2 is actually usable though
2019-03-13 04:32:44 <SpaceToast> but build-in replication and re-balancing over raft sounds very nice
2019-03-13 04:32:48 <jwh> except with django, because they produce questionable sql
2019-03-13 04:33:05 <SpaceToast> if I got it to be used at $dayjob, it'd be used through pgsql's jdbc
2019-03-13 04:33:30 <jwh> but then django also can't figure out how to use abstraction and work with different sql dialects
2019-03-13 04:33:35 <jwh> so I don't have much faith in their work
2019-03-13 04:34:02 <jwh> yeah
2019-03-13 04:34:38 <jwh> if your applications stick to sensible sql it's fine, but things like deferred constraints don't work but most of the time theres no need for that anyway
2019-03-13 04:34:56 <SpaceToast> > dayjob
2019-03-13 04:35:01 <SpaceToast> > expecting coworkers to write sensible sql ;)
2019-03-13 04:35:05 <jwh> lol
2019-03-13 04:35:13 <jwh> make them unit test against cockroach :D
2019-03-13 04:35:20 <SpaceToast> > expecting unit tests
2019-03-13 04:35:31 <SpaceToast> we run two percona sql clusters - wanna know why?
2019-03-13 04:35:41 <jwh> because percona is awesome and everyone should use it
2019-03-13 04:35:42 <jwh> :D
2019-03-13 04:35:47 <SpaceToast> no! bad jwh!
2019-03-13 04:35:55 <SpaceToast> our developers like using mysql as a logging system
2019-03-13 04:36:10 <SpaceToast> and using the main cluster as logging slows down the actual applications
2019-03-13 04:36:17 <SpaceToast> so we just run a dedicated logging cluster
2019-03-13 04:36:21 <SpaceToast> it's called dbLogs
2019-03-13 04:36:43 <jwh> I (used to) run big multi tiered galera clusters, I evaluated the lot and picked percona as it was actually tested and released as a product, but still 100% mysql
2019-03-13 04:36:54 <jwh> maria had already started to diverge at that point
2019-03-13 04:37:05 <SpaceToast> yeah, we're on galera on percona
2019-03-13 04:37:08 <SpaceToast> it's absolutely awful
2019-03-13 04:37:22 <jwh> it is if you get it wrong, it's very hard to get right
2019-03-13 04:37:23 <SpaceToast> stuck on 5.4 permanently, things go down a lot, impossible to update due to platform
2019-03-13 04:37:30 <jwh> it takes a *lot* of effort
2019-03-13 04:37:33 <SpaceToast> that sounds like something you shouldn't be using :)
2019-03-13 04:37:54 <jwh> dataabases do take a lot of effort and skill to get right
2019-03-13 04:38:00 <jwh> databases*
2019-03-13 04:38:11 <jwh> learned knowledge is invaluable
2019-03-13 04:38:13 <SpaceToast> 
ACTION looks at minio

2019-03-13 04:38:17 <SpaceToast> 
ACTION looks at redis

2019-03-13 04:38:20 <SpaceToast> maybe cockroach... :)
2019-03-13 04:38:32 <jwh> bleh, redis stil doesn't have master-master
2019-03-13 04:38:35 <jwh> so basically no HA
2019-03-13 04:38:44 <SpaceToast> why are you doing distribution with redis tho
2019-03-13 04:38:52 <SpaceToast> it's more of a cache than anything
2019-03-13 04:39:01 <SpaceToast> just run an instance on every host! :D
2019-03-13 04:39:16 <jwh> I need coherency between application instances
2019-03-13 04:39:33 <jwh> but it needs to be fast, so a traditional DB is no good
2019-03-13 04:39:42 <jwh> hoping cockroach will help a little
2019-03-13 04:39:56 <SpaceToast> mm
2019-03-13 04:40:17 <jwh> cockroach is just a distributed KV store underneath, so
2019-03-13 04:40:31 <SpaceToast> either way, cockroach has the *potential* to actually be nice
2019-03-13 04:40:36 <jwh> yeah
2019-03-13 04:40:42 <SpaceToast> (and break the "databases are stupid" trend)
2019-03-13 04:40:45 <jwh> they're still pretty new though and they're not quite sure what they want
2019-03-13 04:40:56 <SpaceToast> but I don't have any opinions until they're semi-stable and I've tried it
2019-03-13 04:41:33 <jwh> if you really want to use it, I'd start by s/oss//g on the APKBUILD
2019-03-13 04:41:33 <jwh> heh
2019-03-13 04:42:08 <jwh> the non-oss portions are really nice
2019-03-13 04:42:08 <SpaceToast> I'm considering it, in case someone asks
2019-03-13 04:42:23 <SpaceToast> definitely not for personal use, though
2019-03-13 04:42:28 <SpaceToast> what they do?
2019-03-13 04:42:44 <jwh> data geo fencing, cute sharding and stuff
2019-03-13 04:42:54 <jwh> region aware stuff
2019-03-13 04:44:20 <SpaceToast> ah, nothing that'll really be important for $dayjob usecases
2019-03-13 04:44:30 <jwh> no
2019-03-13 04:44:37 <jwh> likely not
2019-03-13 04:44:49 <SpaceToast> or for my personal ones :)
2019-03-13 04:45:20 <jwh> I have a feeling they actually removed a bunch of features even from the non-free build so they could license them
2019-03-13 04:45:51 <jwh> binary only most likely
2019-03-13 04:46:42 <SpaceToast> have you ever heard of nginx? ;)
2019-03-13 04:46:55 <SpaceToast> as sad as it is, these practices are a reality we live in ¯\_(ツ)_/¯
2019-03-13 04:46:56 <jwh> yes
2019-03-13 04:46:58 <jwh> same hing
2019-03-13 04:47:00 <jwh> thing*
2019-03-13 04:47:56 <jwh> but crdb has self healing and stuff, if I can make it work it makes my life a bit easier
2019-03-13 04:49:03 <jwh> it's still missing a lot of the mysql ecosystem but so is postgres, applications shouldn't have to care about the state of the data stores
2019-03-13 05:34:10 <_ikke_> R3d_Sky: What is apk-depparse.sh?
2019-03-13 07:14:20 <nmeum> _ikke_: re polyml: yeah, it seems to fail on all arches except x86* I might also downgrade it again instead of disabling all non-x86 arches. what do you think?
2019-03-13 07:14:59 <nmeum> I also created an upstream issue https://github.com/polyml/polyml/issues/110 but I don't think that it will be fixed soonish
2019-03-13 07:57:34 <ncopa> morning. are there any good laternatives to grub?
2019-03-13 07:58:06 <ncopa> " changing the order of menu entries or changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/."
2019-03-13 07:58:21 <ncopa> the "configuration" is complex shell scripts
2019-03-13 07:58:43 <ncopa> if grub cannot auto detect your stuff, or if you want different order, you need patch grub
2019-03-13 07:59:00 <ncopa> i cannot even figure out how to configure the default kernel...
2019-03-13 07:59:34 <ncopa> and ofc it failed to detect my windows
2019-03-13 08:00:01 <ncopa> i also want remove the frame on the boot screen, but apparently you need to patch grub for that too
2019-03-13 08:00:55 <clandmeter> check fedora grub
2019-03-13 08:01:00 <clandmeter> its made out of patches
2019-03-13 08:21:36 <fabo> changing bootloader seems sensible :) patching grub2 could be even considered best practice unfortunately
2019-03-13 08:25:31 <mps> ncopa: do you have any idea what to do with Bug #10041
2019-03-13 08:26:20 <mps> I sent mail to maintaner (and cc to alpine-devel ML) 9 days ago but didn't got any answer
2019-03-13 08:30:55 <fabo> ncopa: not sure about patching grub to remove the frame, you can find a bunch of grub themes without a visible frame (https://www.gnome-look.org/browse/cat/109/)
2019-03-13 09:12:20 <doggone> Hi, I've been getting the following on a newly installed server for a few days now: ERROR: linux-firmware-vxge-20181220-r0: remote server returned error (try 'apk update')
2019-03-13 09:12:28 <doggone> Happens with any repo I choose
2019-03-13 09:16:03 <clandmeter> doggone: can you apk -U upgrade -a?
2019-03-13 09:23:19 <doggone> I can do that but the result is still the same. wget 'http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/linux-firmware-vxge-20181220-r0.apk' also returns an error 500.
2019-03-13 09:24:01 <clandmeter> doggone: btw, this is developement channel. please use #alpine-linux
2019-03-13 09:24:20 <doggone> I'm sorry, I thought this was the right place :) I'll take it there
2019-03-13 09:48:12 <_ikke_> Any idea how we could obtain additional log files from builders? Apparently some test suites only log information about failed tests in a test-suite.log file
2019-03-13 09:50:26 <clandmeter> which builders?
2019-03-13 09:50:36 <clandmeter> official ones?
2019-03-13 09:50:50 <_ikke_> yes
2019-03-13 09:50:58 <_ikke_> or CI
2019-03-13 09:51:20 <_ikke_> fstrm fails on official builders
2019-03-13 09:51:22 <clandmeter> the only way would be to make it configurable
2019-03-13 09:51:37 <_ikke_> (s390x)
2019-03-13 09:51:49 <_ikke_> clandmeter: so that it becomes part of the build output?
2019-03-13 09:52:05 <clandmeter> even if you find the log, without access to a builder its hard.
2019-03-13 09:52:19 <_ikke_> nod
2019-03-13 09:52:47 <clandmeter> the easiest is to just disable it for the exotic arches if you dont know.
2019-03-13 09:53:12 <clandmeter> you can also ping tmhoang for s390x
2019-03-13 09:53:39 <tmhoang> _ikke_ : I'm working on fstrm on s390x
2019-03-13 09:54:22 <tmhoang> build.a.o is down ?
2019-03-13 09:54:39 <_ikke_> hmm
2019-03-13 09:54:51 <_ikke_> it is loading for me?
2019-03-13 09:54:56 <clandmeter> looks like it doesnt show much
2019-03-13 09:55:12 <_ikke_> we were already looking into that last night (ncopa mostly did)
2019-03-13 09:55:23 <_ikke_> since the reboot of nld3
2019-03-13 09:55:39 <tmhoang> _ikke_ : current s390x qemu emulation works pretty ok on x86. In QEMU 4.1, support will be much better with z13 CPU. If you ever need a qemu emulation command, let me know. For reasons, I cannot put it in wiki.a.o/s390x but you could find examples on wiki.qemu.org.
2019-03-13 09:56:31 <tmhoang> actually, various projects prefer to run emulation on their infra to build packages for exotic arch like ppc, arm, s390x
2019-03-13 09:56:55 <tmhoang> agreed
2019-03-13 09:56:55 <_ikke_> Alpine has the opposite, we prefer native hardware
2019-03-13 09:57:02 <tmhoang> just saying
2019-03-13 09:58:03 <_ikke_> but for testing / repro purposes it can be convenient
2019-03-13 09:59:47 <clandmeter> im trying to get support for those 2 arches in drone
2019-03-13 10:01:54 <tmhoang> clandmeter: am I allowed to look into builder containers data files to get the log ? Even though I have root access to the VM, not sure if I could tamper the container builder .
2019-03-13 10:17:44 <tmhoang> _ikke_ : for running on x86 : https://tpaste.us/ee7V
2019-03-13 10:22:33 <ncopa> mps: i think i can handle libell issue
2019-03-13 10:26:50 <mps> ncopa: it is enough to copy APKBUILD from testing/ell
2019-03-13 10:27:29 <mps> I'm testing this with iwd for about then days, it works
2019-03-13 10:28:10 <mps> it works good in AP and STAtion mode
2019-03-13 10:28:34 <mps> didn't tried in AD-HOC mode
2019-03-13 10:29:25 <ncopa> mps: i pushed fix for it
2019-03-13 10:29:30 <mps> if you plan to freeze on April, networkmanager should be upgraded
2019-03-13 10:30:15 <mps> eh, nice you already fixed bluez, I just wanted to mention it
2019-03-13 10:31:11 <mps> btw, if you still follow #iwd you know that connman is not in good 'shape'
2019-03-13 10:33:28 <mps> and I wrote small guide/note how to use iwd in Alpine, don't know where to post it
2019-03-13 10:33:51 <clandmeter> wiki
2019-03-13 10:34:48 <mps> alpine wiki? isn't it planned to be changed to docs.a.o
2019-03-13 10:35:04 <clandmeter> no
2019-03-13 10:35:21 <mps> aha, ok then. will go to wiki
2019-03-13 10:35:31 <clandmeter> its only planned to put the handbook and devbook for now
2019-03-13 10:36:48 <mps> clandmeter: btw I'm little angry, you didn't me told few days ago that you had redmine in aports :)
2019-03-13 10:37:19 <mps> when i nearly finished I found it in git history
2019-03-13 10:37:30 <clandmeter> huh?
2019-03-13 10:37:47 <mps> anyway was helpful to me, thanks
2019-03-13 10:38:03 <clandmeter> first of all you didnt ask me, second of all i did mention we removed ruby from aports.
2019-03-13 10:38:05 <mps> and, no, I wasn't angry, just kidding
2019-03-13 10:38:22 <mps> no worries
2019-03-13 10:38:31 <clandmeter> ruby is problematic to manage in aports
2019-03-13 10:38:43 <mps> I see
2019-03-13 10:38:52 <clandmeter> we tried it, but in the end gave up
2019-03-13 10:39:00 <clandmeter> needed too many rubygemXX versions
2019-03-13 10:40:06 <clandmeter> 2 ruby applications would need 2 different version of gems
2019-03-13 10:40:08 <mps> yes, I also thought it will be easier, but ... for now I have redmine on Alpine for my use case and I'm happy with that ;)
2019-03-13 10:41:49 <mps> nowadays programming languages heads to some inextricable world
2019-03-13 11:14:24 <R3d_Sky> _ikke_: apk-depparse.sh is "source $1; echo $depends $makedepends; echo $subpackages"
2019-03-13 11:14:35 <R3d_Sky> sorry for late response, was at school
2019-03-13 11:25:28 <_ikke_> R3d_Sky: no worry, I just chatted so that you could reply when you had time :)
2019-03-13 11:45:49 <_ikke_> clandmeter: I see quite some packages with Gopkgs.(toml
2019-03-13 11:45:58 <_ikke_> clandmeter: I see quite some packages with Gopkgs.(toml|lock)
2019-03-13 11:46:07 <_ikke_> I understand that uses dep for dependencies
2019-03-13 11:46:21 <clandmeter> yes if you tell it to
2019-03-13 11:46:36 <_ikke_> ok, so APKBUILD should use dep ensure?
2019-03-13 11:46:56 <clandmeter> i think most of them removed the vendor dir?
2019-03-13 11:47:09 <_ikke_> Hmm, this one still has a vendor dir
2019-03-13 11:47:23 <clandmeter> is it populated?
2019-03-13 11:47:39 <_ikke_> yes
2019-03-13 11:47:56 <clandmeter> what is the project?
2019-03-13 11:47:56 <_ikke_> so that should be alright then
2019-03-13 11:47:59 <_ikke_> minikube
2019-03-13 11:48:27 <_ikke_> https://github.com/alpinelinux/aports/pull/6655/files
2019-03-13 11:48:29 <clandmeter> looks like they manage both
2019-03-13 11:48:38 <_ikke_> yes
2019-03-13 11:52:05 <clandmeter> looks like the makefile uses go build
2019-03-13 12:00:23 <R3d_Sky> _ikke_: so I'm manually pruning the tree and I'm down to about 616 packages
2019-03-13 12:05:25 <ncopa> R3d_Sky: are you working on readline 8 upgrade?
2019-03-13 12:05:41 <ncopa> im about to have a look at it
2019-03-13 12:06:43 <danieli> i had some issues with that on arch
2019-03-13 12:06:56 <danieli> it broke gnupg, which broke pacman
2019-03-13 12:11:51 <ncopa> danieli: do you have link to bug report?
2019-03-13 12:12:05 <ncopa> did they rebuild gnupg with new readline?
2019-03-13 12:12:36 <danieli> apparently the solution was to run `mkinitcpio -P` before rebooting, but I didn't do that
2019-03-13 12:12:52 <danieli> what I did was boot into rescue and symlink readline 7 to readline 7 and 8
2019-03-13 12:13:19 <danieli> can't see any bug reports about it
2019-03-13 12:14:08 <_ikke_> ncopa: python3.7
2019-03-13 12:21:14 <R3d_Sky> ncopa: I've been working on python 3.7 :P
2019-03-13 12:21:21 <ncopa> oh, great
2019-03-13 12:21:23 <danieli> yes
2019-03-13 12:21:30 <danieli> _ikke_, him, me
2019-03-13 12:21:53 <ncopa> danieli: i think they use bash in initramfs. we dont, so i tihnk we should be ok
2019-03-13 12:22:55 <ncopa> R3d_Sky: i think the trickies part will be to merge it. we have so many open PRs so the python3.7 merge will cause merge conflicts in lots of open PRs
2019-03-13 12:23:45 <ncopa> and we need to be careful when rebasing, because it may be a pkgrel bump only
2019-03-13 12:24:04 <ncopa> and when git merges that, it will not bump pkgrel another, which is needed when merging
2019-03-13 12:24:16 <R3d_Sky> oh, that is true
2019-03-13 12:24:50 <ncopa> basically, we need to coordinate when we do the final merge
2019-03-13 12:25:34 <ncopa> I am bumping alot of packages now due to readline8 rebuilds
2019-03-13 12:26:13 <R3d_Sky> ah
2019-03-13 12:26:22 <ncopa> fwiw, i tested to build pyhon3.7 on aarch64 not too long ago
2019-03-13 12:26:26 <R3d_Sky> ncopa: so you're working out the bumps manually or do you have tools to help?
2019-03-13 12:26:26 <ncopa> and ran it on rpi3
2019-03-13 12:26:35 <R3d_Sky> worked for me
2019-03-13 12:26:35 <ncopa> i have a script to help
2019-03-13 12:26:40 <R3d_Sky> ah send pls
2019-03-13 12:26:49 <R3d_Sky> I've been trying to write my own, not much success
2019-03-13 12:26:58 <ncopa> its a bit messy
2019-03-13 12:27:15 <R3d_Sky> what lang?
2019-03-13 12:27:22 <ncopa> shell
2019-03-13 12:27:34 <ncopa> $ tpaste < rebuild-since
2019-03-13 12:27:34 <ncopa> http://tpaste.us/O1Z8
2019-03-13 12:29:04 <ncopa> i use it with: apk search -r --exact -q --origin so:libreadline.so.7 so:libhistory.so.7 | sh ../rebuild-since origin/master "rebuild against readline 8"
2019-03-13 12:30:57 <R3d_Sky> I've been investing time to figure out the order in which packages need to be rebuilt if relbumped
2019-03-13 12:31:03 <R3d_Sky> does that really matter?
2019-03-13 12:31:09 <ncopa> yes
2019-03-13 12:31:37 <ncopa> i use the lua-aports package for that
2019-03-13 12:31:45 <ncopa> there is an `ap` tool
2019-03-13 12:31:58 <ncopa> ap builddirs pkg1 pkg2 pkg3
2019-03-13 12:32:06 <ncopa> will list the directories in build order
2019-03-13 12:41:22 <R3d_Sky> ncopa: only problem I have right now is that there's a lot of packages that depend on python3 but then don't really care about the versions
2019-03-13 12:42:04 <R3d_Sky> stuff like musl, postgresql and co require python during make process for docs
2019-03-13 12:42:20 <ncopa> i dont think they need to be rebuilt
2019-03-13 12:43:15 <ncopa> we do need to make sure that they will be able to build once we have pushed the python3.7 update
2019-03-13 12:43:31 <ncopa> which i think means we need to rebuild sphinx and the doc tools and python modules they use
2019-03-13 12:45:09 <ncopa> i think we need to rebuild evertying  that depends on so:libpython3.6m.so.1.0 so:libpython3.so
2019-03-13 12:45:45 <ncopa> and everything that has /usr/lib/python3.6
2019-03-13 12:47:09 <ncopa> and i think that is it
2019-03-13 17:16:11 <ncopa> ok i have a readline8 upgrade ready for push. hold on to your hats!
2019-03-13 17:16:25 <_ikke_> 
ACTION holds tight

2019-03-13 17:16:46 <ncopa> here we go..
2019-03-13 17:16:51 <ncopa> lets se what breaks
2019-03-13 17:17:17 <ncopa> bash was upgraded to 5.0 too while at it
2019-03-13 17:22:26 <danieli> anything break yet?
2019-03-13 17:22:51 <_ikke_> builders are still building
2019-03-13 17:22:58 <_ikke_> check #alpine-commits
2019-03-13 20:10:58 <_ikke_> R3d_Sky: ping
2019-03-13 20:15:20 <_ikke_> R3d_Sky: It errors out on the text= param passed to subprocess.run. I can find that param nowhere in the docs
2019-03-13 20:18:16 <danieli> _ikke_: which package?
2019-03-13 20:19:22 <_ikke_> danieli: the python scripts they created
2019-03-13 20:20:23 <danieli> ah, i haven't even looked at that, so i am afraid i can't help
2019-03-13 20:20:29 <_ikke_> replacing text=True with encoding='utf-8' fixes it
2019-03-13 21:20:55 <_ikke_> nice, just used pythons multiprocess library to parallelize gettings the python3 dependencies
2019-03-13 21:21:16 <_ikke_> I have one single thread version running for a bit longer, wondering which finishes first
2019-03-13 21:41:14 <danieli> careful not to hit a wall with GIL
2019-03-13 22:37:52 <tmhoang> good night danieli
2019-03-14 05:58:04 <_ikke_> R3d_Sky: danieli this is the result from the script http://tpaste.us/P0ZJ
2019-03-14 06:32:54 <ollieparanoid[m]> ncopa, clandmeter, nmenum: could you take a look at https://lists.alpinelinux.org/alpine-devel/6486.html when you have time, and fork it to Alpine's github project if you like the approach? then I could continue with making PRs to aports.git to use the script.
2019-03-14 07:42:33 <danieli> tmhoang: I fell asleep even earlier :)
2019-03-14 07:42:49 <danieli> _ikke_: I'll have a look when I'm up and mentally present
2019-03-14 07:55:51 <_ikke_> danieli: alright
2019-03-14 07:57:17 <ncopa> ollieparanoid[m]: i had a look at it. will try respond after breakfast
2019-03-14 07:57:30 <ollieparanoid[m]> ncopa: thanks!
2019-03-14 07:58:12 <danieli> _ikke_: what exactly was it this script does?
2019-03-14 07:59:14 <_ikke_> danieli: R3d_Sky can tell you more, but the basic idea is that it tells you in what order you should update packages. Each 'batch' is a list of packages that depend on the previous batch
2019-03-14 08:10:58 <_ikke_> danieli: -1 is the list of packages without dependencies
2019-03-14 08:11:06 <_ikke_> on python3 that is
2019-03-14 08:11:09 <danieli> gotcha
2019-03-14 08:16:56 <fcolista> umh..
2019-03-14 08:16:58 <fcolista> 2ua4020qdl:~$ firefox
2019-03-14 08:16:58 <fcolista> [Child 10935, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by peer: file /home/buildozer/aports/testing/firefox/src/firefox-62.0.3/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
2019-03-14 08:16:58 <fcolista> Segmentation fault
2019-03-14 08:17:15 <fcolista> apk info firefox
2019-03-14 08:17:16 <fcolista> firefox-62.0.3-r4 description:
2019-03-14 08:17:16 <fcolista> Firefox web browser
2019-03-14 08:17:16 <fcolista> firefox-62.0.3-r4 webpage:
2019-03-14 08:17:16 <fcolista> https://www.firefox.com/
2019-03-14 08:17:16 <fcolista> firefox-62.0.3-r4 installed size:
2019-03-14 08:17:18 <fcolista> 134082560
2019-03-14 08:17:30 <danieli> _ikke_: have you guys pushed any patched python3-dependent packages to update-python-3.7?
2019-03-14 08:17:35 <fcolista> I'm on edge
2019-03-14 08:17:45 <_ikke_> danieli: no, not yet
2019-03-14 08:18:53 <danieli> okay. to avoid duplication of efforts, what are you working on?
2019-03-14 08:42:22 <Mo0O> hi there
2019-03-14 08:42:46 <danieli> hello
2019-03-14 08:43:22 <Mo0O> I've got this pending PR, do you know if somebody can merge it? or if something is missing?
2019-03-14 08:43:25 <Mo0O> hello danieli
2019-03-14 08:43:38 <_ikke_> Mo0O: What PR is it?
2019-03-14 08:44:11 <Mo0O> _ikke_: it's for s3fs-fuse: https://github.com/s3fs-fuse/s3fs-fuse
2019-03-14 08:44:20 <Mo0O> https://github.com/alpinelinux/aports/pull/5369
2019-03-14 08:44:27 <Mo0O> here is the PR sorry :D
2019-03-14 08:44:41 <_ikke_> I'll take a look at it later
2019-03-14 08:44:50 <Mo0O> thanks a lot _ikke_
2019-03-14 09:00:46 <_ikke_> ah, ncopa already merged it
2019-03-14 09:01:35 <Mo0O> great :)
2019-03-14 09:01:54 <Mo0O> thanks ncopa and thank you also _ikke_
2019-03-14 09:09:05 <ncopa> Mo0O: thanks for you patience with us
2019-03-14 09:13:18 <clandmeter> ncopa: we should change the message of stale to include rebase suggestion. it will remove the stale label iirc.
2019-03-14 10:26:13 <ncopa> clandmeter: maybe also add a .github/STALE.md doc with a bit longer explanation and excuse why we use the stale bot.
2019-03-14 10:26:27 <ncopa> and link to it in the stale message
2019-03-14 10:26:53 <clandmeter> im open to suggestions on how to improve the message.
2019-03-14 10:27:05 <clandmeter> and content of stale.md
2019-03-14 10:58:59 <ncopa> clandmeter: maybe something like: http://tpaste.us/Vale
2019-03-14 10:59:41 <ncopa> $ tpaste < stale.md
2019-03-14 10:59:41 <ncopa> http://tpaste.us/mZvv
2019-03-14 11:14:10 <clandmeter> ncopa: i put a message in docs channel.
2019-03-14 12:18:55 <Mo0O> do you know if it's possible to use a specific package version in makedepends? for example one package I plan to create required xmlsec-dev==1.2.22-r4 because `xmlsec/soap.h` is no longer available since xmlsec-dev==1.2.25-r1
2019-03-14 12:19:39 <Mo0O> I've try specifying xmlsec-dev==1.2.25-r1 in makedepends but it return an error during dependency check
2019-03-14 12:21:20 <danieli> we don't archive packages, so that'd be hard
2019-03-14 12:21:22 <Mo0O> 1.2.22-r4 is still available in v3.6 branch, maybe there's some flags like @v3.6 available?
2019-03-14 12:21:38 <_ikke_> no
2019-03-14 12:21:40 <Mo0O> hard or impossible ?
2019-03-14 12:22:05 <danieli> if you just want to build it for yourself, you could use repository pinning to install it manually
2019-03-14 12:22:14 <danieli> but it wouldn't be fit for inclusion in alpine
2019-03-14 12:22:46 <Mo0O> is there a way to fit it for inclusion?
2019-03-14 12:23:05 <Mo0O> like embeding the lib directly?
2019-03-14 12:23:18 <Mo0O> iduno, just asking
2019-03-14 12:23:54 <danieli> if you are able to patch the software to work with the version of xmlsec we ship, it should be fine
2019-03-14 12:24:10 <Mo0O> seems legit
2019-03-14 12:24:23 <danieli> correct me if I'm wrong _ikke_
2019-03-14 12:24:49 <_ikke_> I think that should work, yes
2019-03-14 12:30:06 <Mo0O> hmm, there's something weird, [xmlsec-1_2_27](https://github.com/lsh123/xmlsec/tree/xmlsec-1_2_27/include/xmlsec) provide `soap.h` but it's not present in [alpine package](https://pkgs.alpinelinux.org/package/v3.9/community/x86_64/xmlsec-dev) / https://pkgs.alpinelinux.org/contents?branch=v3.9&name=xmlsec-dev&arch=x86_64&repo=community
2019-03-14 12:31:26 <Mo0O> 
ACTION is diging through https://git.alpinelinux.org/aports/tree/community/xmlsec/APKBUILD?h=3.6-stable and https://git.alpinelinux.org/aports/tree/community/xmlsec/APKBUILD?h=3.9-stable

2019-03-14 12:33:52 <Mo0O> could be linked to the `--without-gnutls` and `--without-gcrypt` options
2019-03-14 17:27:51 <mksully22> minor change in https://github.com/alpinelinux/aports/pull/6667 to enable ppc64le for testing/iwd. OK on travis integraton but fails all arches on drone.  Is drone build environment somehow different?
2019-03-14 21:12:49 <_ikke_> yes, it might be different
2019-03-14 21:13:34 <_ikke_> What test system is this using, I see that often lately but it decided to put actual usefull info in a log file
2019-03-14 21:22:00 <mps> mksully22: do you have link to drone logs of the failed tests
2019-03-14 21:42:25 <clandmeter> mksully22: travis runs in a chroot and drone in docker.
2019-03-15 00:20:57 <SpaceToast> ncopa: I'm looking into one of the setup-alpine issues you wanted looked at - I notice we have a baselayout repo (https://git.alpinelinux.org/alpine-baselayout/). It hasn't been touched in 2 years, and doesn't seem to be mentioned in the baselayout package. Which one should I be poking? (I suspect it's the package, but the presence of the git repo is quite confusing)
2019-03-15 00:21:46 <jwh> so, maria
2019-03-15 00:22:13 <jwh> I was thinking it should probably be possible to set the datadir
2019-03-15 00:22:24 <jwh> conf.d?
2019-03-15 00:24:55 <SpaceToast> yeah, most likely
2019-03-15 00:26:08 <SpaceToast> something like `: ${MARIADB_DATADIR:=/var/lib/mysql}`, then force-passing it to the main invocation, and using it in setup()
2019-03-15 00:26:12 <SpaceToast> I'm assuming the middle one works
2019-03-15 00:26:47 <jwh> I was just going to ship conf.d with that as the default
2019-03-15 00:27:02 <jwh> but yeah could do that
2019-03-15 00:27:41 <SpaceToast> shipping it as default is fine too
2019-03-15 00:27:50 <SpaceToast> but I usually like shipping as default with RC_SVCNAME
2019-03-15 00:27:58 <SpaceToast> which you can't do if you wanna keep /var/lib/mysql compatibility
2019-03-15 00:28:03 <SpaceToast> (it'd be /var/lib/mariadb, then)
2019-03-15 00:28:33 <jwh> well, arguably it shouldn't even default to /var/lib/mysql as they're two distinct projects now
2019-03-15 00:28:42 <jwh> there is on-disk incompatibility too
2019-03-15 00:28:48 <jwh> plus mysql isn't even available in the repos
2019-03-15 00:29:00 <SpaceToast> fair enough, but you'll be breaking a lot of existing deployments if you change it like that :)
2019-03-15 00:29:20 <SpaceToast> (since we currently have lots of /var/lib/mysql deploys out there, since that's what it setup into previously)
2019-03-15 00:29:24 <jwh> yeah
2019-03-15 00:29:32 <jwh> silly decisions made long ago
2019-03-15 00:30:03 <SpaceToast> basically, if you're gonna be changing that, we better make a big fuss about it
2019-03-15 00:30:21 <jwh> well it's probably fine as a default since mysql isn't available
2019-03-15 00:30:27 <jwh> legacy sucks
2019-03-15 00:31:48 <SpaceToast> aye
2019-03-15 03:00:18 <sodface> Hello, trying to put together a package for squeezelite (headless audio player that works with Logitech Media Server).  I've built it successfully and tested it both directly (not as a package) and then most recently as a package, which also seems to work ok except for the dependencies.
2019-03-15 03:01:11 <sodface> The build dependencies I'm using are flac-dev
2019-03-15 03:01:11 <sodface> alsa-lib-dev
2019-03-15 03:01:11 <sodface> faad2-dev
2019-03-15 03:01:11 <sodface> mpg123-dev
2019-03-15 03:01:11 <sodface> libvorbis-dev
2019-03-15 03:01:11 <sodface> libmad-dev
2019-03-15 03:01:59 <sodface> When I run scanelf on it though it only comes back with ET_DYN libasound.so.2,libc.musl-armhf.so.1 /usr/bin/squeezelite
2019-03-15 03:02:43 <sodface> So if I clean up the environment and then install the squeezelite package it only pulls in libasound but none of the codecs
2019-03-15 03:03:28 <sodface> Should I just add those to the "depends" in the ABUILD file?
2019-03-15 08:16:46 <ncopa> SpaceToast: the git repo for alpine-baselayout should either be archived or deleted. i think we track it in aports only now
2019-03-15 09:28:12 <tmhoang> how to use busybox find to find and print real link of symlink ?
2019-03-15 09:28:39 <tmhoang> find /tmp -type l -print {print real link}
2019-03-15 09:28:52 <tmhoang> *real path
2019-03-15 09:29:04 <tmhoang> s/real link/real path/
2019-03-15 09:29:04 <alpine-meetbot> tmhoang meant to say: find /tmp -type l -print {print real path}
2019-03-15 09:35:27 <clandmeter> find /tmp -exec readlink -f {} \; ?
2019-03-15 09:40:29 <tmhoang> clandmeter: adding -type l to your works. Thanks!
2019-03-15 09:41:24 <tmhoang> wish busybox find support -printf
2019-03-15 10:49:54 <fcolista> uff
2019-03-15 10:50:01 <fcolista> libvirt 5.1.0 fails because of:
2019-03-15 10:50:01 <fcolista> https://www.spinics.net/linux/fedora/libvir/msg177785.html
2019-03-15 10:50:14 <fcolista> got this error:
2019-03-15 10:50:15 <fcolista> qemu/qemu_process.c:8385:20: error: expected identifier before '(' token
2019-03-15 10:50:15 <fcolista>      VIR_FREE(proc->stderr);
2019-03-15 10:50:31 <fcolista> any C coder wants to provide a patch for this?
2019-03-15 10:50:32 <fcolista> :)
2019-03-15 10:50:47 <fcolista> btw: I'm planning to add zfs and hyper-v support to libvirt
2019-03-15 11:23:22 <mps> fcolista: iiuc, you need a patch to add 'VIR_FREE(proc->stderr);'
2019-03-15 11:31:51 <xsteadfastx> im working on a APKBUILD for gmrender and it offers only git... no releases
2019-03-15 11:32:05 <xsteadfastx> now i want to test stuff and if it works with the snapshot feature
2019-03-15 11:32:08 <xsteadfastx> it works so far
2019-03-15 11:32:39 <xsteadfastx> but how can i test it better without upload the source tar.gz to the alpine servers?
2019-03-15 11:32:55 <xsteadfastx> the docs say i should create a symlink... but fromn where to where?
2019-03-15 11:33:19 <_ikke_> xsteadfastx: if you can get a specific commit by commit hash, it's preferred to do that rather than using the snapshot feature
2019-03-15 11:34:29 <xsteadfastx> do you have a example APKBUILD for that case? or should i rewrite the snapshot function for doing this?
2019-03-15 11:35:57 <_ikke_> Where is the source available?
2019-03-15 11:36:40 <xsteadfastx> https://github.com/hzeller/gmrender-resurrect
2019-03-15 11:37:42 <xsteadfastx> ok
2019-03-15 11:37:45 <xsteadfastx> i think im on its way
2019-03-15 11:37:55 <xsteadfastx> download a tarball for a commit from github is possible
2019-03-15 11:38:00 <_ikke_> You can use https://github.com/hzeller/gmrender-resurrect/archive/a7b0b1b9ca482d2d34ac62c2f2dc0cf0dfbb702b.tar.gz
2019-03-15 11:38:07 <xsteadfastx> so i use this as source
2019-03-15 11:38:11 <_ikke_> correct
2019-03-15 11:38:24 <_ikke_> To make it easier to change, use something like _commit=<hash> as a variable
2019-03-15 11:39:06 <xsteadfastx> and what i use now as $pkgver?
2019-03-15 11:39:33 <_ikke_> 0_git<date>
2019-03-15 11:39:55 <_ikke_> That makes sure that as soon as they start using releases, the new releases will be considered newer
2019-03-15 11:40:00 <_ikke_> the date should be the date of the commit
2019-03-15 11:40:09 <xsteadfastx> the day of the commit or the day of creating the APKBUILD file?
2019-03-15 11:40:11 <xsteadfastx> ah ok
2019-03-15 11:40:14 <xsteadfastx> :)
2019-03-15 11:42:41 <xsteadfastx> perfect
2019-03-15 11:50:24 <fabo> anybody familiar with this kind of issue:
2019-03-15 11:50:25 <fabo> # ldd /usr/lib/apache2/mod_wsgi.so
2019-03-15 11:50:25 <fabo>         ldd (0x7f72bc20e000)
2019-03-15 11:50:25 <fabo>         libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x7f72bc032000)
2019-03-15 11:50:28 <fabo>         libc.musl-x86_64.so.1 => ldd (0x7f72bc20e000)
2019-03-15 11:50:31 <fabo> Error relocating /usr/lib/apache2/mod_wsgi.so: apr_pstrmemdup: symbol not found
2019-03-15 11:59:42 <xsteadfastx> i dont get it working... always a SIGSEGV Address boundary error on running it
2019-03-15 12:02:34 <xsteadfastx> anything about muslc?
2019-03-15 12:16:52 <mps> btw, libvirt APKBUILD need to be fixed to some degree
2019-03-15 12:21:57 <xsteadfastx> i thought i read something about different address handling comparing to glibc
2019-03-15 12:22:15 <andypost[m]> ncopa, please comment your POV on https://github.com/alpinelinux/aports/pull/6673
2019-03-15 12:39:57 <xsteadfastx> and i have no idea howto debug it... i tried to use strace but no idea how to find something out with that log
2019-03-15 12:40:45 <danieli> I'd have a look with gdb, but it sounds like it isn't compatible with musl one way or another (I haven't looked at its source)
2019-03-15 12:43:11 <xsteadfastx> https://bpaste.net/show/b7afbcd60144
2019-03-15 12:47:01 <xsteadfastx> Thread 1 "gmediarender" received signal SIGSEGV, Segmentation fault.
2019-03-15 12:47:03 <xsteadfastx> 0x00007ffff7fbf02f in pthread_timedjoin_np () from /lib/ld-musl-x86_64.so.1
2019-03-15 12:47:06 <xsteadfastx> that what i get with gdb
2019-03-15 12:55:14 <xsteadfastx> and maybe it has something to do with https://github.com/hzeller/gmrender-resurrect/blame/a7b0b1b9ca482d2d34ac62c2f2dc0cf0dfbb702b/src/main.c#L208
2019-03-15 12:55:19 <xsteadfastx> but i know nothing ;-)
2019-03-15 12:59:25 <mps> fcolista: regarding libvirt and proc->stderr, to me looks like upstream bug, not sure but they should initialize it somewhere
2019-03-15 13:00:23 <fcolista> mps, hi
2019-03-15 13:00:23 <fcolista> thx
2019-03-15 13:00:35 <fcolista> 'VIR_FREE(proc->stderr);' is initialized already
2019-03-15 13:01:22 <mps> I added initialization and then it passed build
2019-03-15 13:01:47 <fcolista> src/qemu/qemu_process.c: 8385
2019-03-15 13:01:53 <mps> I did just as crude hack
2019-03-15 13:02:43 <mps> in qemu_capabilities.c
2019-03-15 13:03:48 <fcolista> umh
2019-03-15 13:04:34 <fcolista> can you show me how you did that?
2019-03-15 13:04:50 <mps> I don't know much about libvirt source, but to me it bug introduced when they added proc->stderr to VIR_FREE
2019-03-15 13:05:11 <fcolista> right
2019-03-15 13:05:27 <mps> qemuProcessQMPPtr proc = NULL;
2019-03-15 13:05:47 <mps> and after that line:  char *stderr = NULL;
2019-03-15 13:06:01 <mps> line 4370
2019-03-15 13:07:06 <mps> I mean in src/qemu/qemu_capabilities.c
2019-03-15 13:07:15 <fcolista> thx!Why have you patched qamu_capabilities.c ?
2019-03-15 13:08:29 <mps> quick look to the previous patch lead me there, intuition or what ;)
2019-03-15 13:09:15 <fcolista> ok :)
2019-03-15 13:09:16 <fcolista> thanks!
2019-03-15 13:09:53 <mps> if you see new bug introduced always look previous patch
2019-03-15 13:11:08 <fcolista> wondering how some other distro can ship 5.1.0 without this patch...
2019-03-15 13:11:26 <fcolista> I was thinking actually that was due to glibc/musl incompatibility
2019-03-15 13:12:06 <mps> my first thought was right this, i.e. musl
2019-03-15 13:15:20 <mps> just looked at Void linux, they have another patch for musl
2019-03-15 13:15:28 <fcolista> qemu/qemu_capabilities.c:4370:5: error: dereferencing pointer to incomplete type 'FILE' {aka 'struct _IO_FILE'}
2019-03-15 13:15:28 <fcolista>      *stderr = NULL;
2019-03-15 13:16:11 <fcolista> ah-a
2019-03-15 13:16:22 <mps> http://tpaste.us/XnNB
2019-03-15 13:16:23 <fcolista> yes, that makes sens
2019-03-15 13:20:33 <fcolista> thx for the good input on looking at void, mps
2019-03-15 13:20:40 <fcolista> I just copied their patch
2019-03-15 13:20:50 <fcolista> so, it was actually (somehow) related to musl
2019-03-15 13:20:58 <fcolista> even if I don't understand how/why
2019-03-15 13:21:37 <mps> does it build now
2019-03-15 13:22:38 <fcolista> yes
2019-03-15 13:22:43 <mps> and, you have to add one line before make in build function in APKBUILD
2019-03-15 13:23:06 <mps> at least APKBUILD in aports
2019-03-15 13:24:01 <mps> or remove backslash after --with-qemu
2019-03-15 13:24:22 <fcolista> yes, already did it
2019-03-15 13:24:34 <mps> good
2019-03-15 13:24:40 <fcolista> https://dpaste.de/3tLG/raw
2019-03-15 13:25:21 <mps> I did same locally
2019-03-15 13:26:57 <fcolista> good
2019-03-15 13:28:24 <mps> and, I was wrong about fix, it was musl at the end.
2019-03-15 13:28:30 <fcolista> yes
2019-03-15 13:28:33 <fcolista> it was musl
2019-03-15 13:28:40 <fcolista> and I still don't understand why
2019-03-15 13:28:52 <fcolista> but I'm not a c code.
2019-03-15 13:28:54 <fcolista> *coder
2019-03-15 13:28:58 <mps> also to me it unclear
2019-03-15 13:29:27 <mps> but will remember this issue for future cases
2019-03-15 13:29:59 <mps> it is good for me to learn something new about musl
2019-03-15 13:31:00 <mksully22> mps: Here is a link to the x86_64 log that is failing on drone. All of the architetures seem to fail the same tests but on Travis the CI passed.  https://cloud.drone.io/alpinelinux/aports/518/2/2
2019-03-15 13:32:11 <fcolista> ok so to add hyper-v support, is needed libwsman
2019-03-15 13:32:44 <fcolista> I've build it (as well as the corresponding dep like sblim-sfcc)
2019-03-15 13:32:50 <fcolista> :)
2019-03-15 13:33:10 <fcolista> would be cool if it really works  :)
2019-03-15 13:33:50 <mps> mksully22: this looks like drone have something special, iwd build fines on all arch's, except i don't have access to ppc64 so couldn't check but after the ell is built there iwd also should
2019-03-15 13:35:00 <mksully22> mps: I have built it successfully on my ppc64le machine now that ell is available
2019-03-15 13:35:11 <mps> fcolista: stopped to use libvirt few years ago, so couldn't test it
2019-03-15 13:35:25 <fcolista> what are you using?
2019-03-15 13:35:36 <mps> mksully22: so, it is ok probably
2019-03-15 13:36:22 <mps> fcolista: screen and shell, it is enough and I can control it how I like
2019-03-15 13:36:33 <fcolista> ah ok...
2019-03-15 13:37:02 <mksully22> has drone been a pretty reliable predictor of success on the actualy build machines so far or are we seeing some issues on drone like we are now seeing with the iwd prebuild?
2019-03-15 13:37:02 <fcolista> if you don't use windows that's enough
2019-03-15 13:38:03 <mps> I'm one of those who never used windows, and I work in IT more than 30 years :)
2019-03-15 13:39:02 <mps> I tried, but thanks to some unknown source of luck, ditched it really soon after tried
2019-03-15 13:50:20 <R3d_Sky> _ikke_: yeah thats a 3.7(?) feature and sorry for disappearing I had tons of stuff to do (re message from 13 march)
2019-03-15 13:50:49 <_ikke_> R3d_Sky: sure, no worry, I got it fixed
2019-03-15 13:51:01 <R3d_Sky> ty <3
2019-03-15 13:51:12 <_ikke_> DId you see the output I managed to get?
2019-03-15 13:51:19 <R3d_Sky> yep
2019-03-15 13:51:29 <_ikke_> I used pythons multiprocess library to speed it up
2019-03-15 13:52:19 <R3d_Sky> I've been working on adding packages to the exclude list earlier because fontconfig depends on python3 and the fonts depend on fontconfig so
2019-03-15 14:01:59 <mps> mksully22: will you post patch for iwd to enable ppc64 or I should (I'm maintainer and want it to be in good shape)
2019-03-15 14:03:07 <_ikke_> R3d_Sky: If you need me to execute something, let me know
2019-03-15 14:06:35 <R3d_Sky> _ikke_: I don't think I have this in the version of the code I uploaded here but I cut execution time to about a minute without multiprocessing by using a cache so I don't walk down a tree more than once
2019-03-15 14:06:38 <R3d_Sky> its a bit hackier but
2019-03-15 14:08:43 <_ikke_> ah, nice
2019-03-15 16:20:54 <ddevault> I have a bunch of patches backed up, would appreciate some reviews when anyone can spare the time: https://patchwork.alpinelinux.org/project/aports/list/?submitter=274
2019-03-15 16:22:53 <SpaceToast> ddevault: regarding this (and your python3 efforts); there's going to be a meeting Sunday 14:00 GMT where we try and get that organized and drafted
2019-03-15 16:22:59 <SpaceToast> I think you stand to benefit, so perhaps you'd like to attend? :)
2019-03-15 16:23:14 <ddevault> sure thing
2019-03-15 16:23:19 <ddevault> where is the meeting held?
2019-03-15 16:23:19 <SpaceToast> cool ^^
2019-03-15 16:23:22 <SpaceToast> #alpine-meetings
2019-03-15 16:23:26 <SpaceToast> we have sopel as a meetbot there
2019-03-15 16:23:51 <SpaceToast> basically, the whole "team organization" idea is moving forward, so if you'd like you could suggest a python team as well (might make your job easier, eh?)
2019-03-15 16:24:08 <ddevault> aye
2019-03-15 19:00:40 <mksully22> mps: patch for enabling ppc64le on testing/iwd is at https://github.com/alpinelinux/aports/pull/6667
2019-03-15 19:05:23 <mps> mksully22: good, thanks
2019-03-15 19:06:00 <mps> mksully22: thanks for testing it on ppc64
2019-03-15 19:44:24 <ddevault> fcolista: thanks for applying those patches
2019-03-15 19:44:47 <_ikke_> ddevault: which ones did he apply?
2019-03-15 19:44:49 <fcolista> ddevault, does not build with s390 and ppc
2019-03-15 19:44:49 <ddevault> it still segfaults qtbrowser but I'll figure that out separately
2019-03-15 19:44:53 <ddevault> oh :(
2019-03-15 19:45:15 <ddevault> _ikke_: qtwebengine
2019-03-15 19:45:26 <_ikke_> ok
2019-03-15 19:45:33 <_ikke_> I was also looking at your patches in PW
2019-03-15 19:45:35 <ddevault> fcolista: will send another patch
2019-03-15 19:47:56 <fcolista> thx ddevault
2019-03-15 19:48:01 <ddevault> patch out
2019-03-15 19:52:37 <iggy> can anyone tell me if John Coyle (dx9err) is on IRC?
2019-03-15 19:52:57 <_ikke_> No idea
2019-03-15 19:53:17 <fcolista> _ikke_, if you can, please apply last ddevault patch
2019-03-15 19:53:27 <fcolista> since it blocks s390 and ppc builders
2019-03-15 19:53:36 <fcolista> i'm running
2019-03-15 19:53:42 <_ikke_> ok
2019-03-15 19:53:49 <fcolista> (I'll come back in ~2hours)
2019-03-15 19:53:54 <fcolista> thx a lot _ikke_ ;-)
2019-03-15 19:54:01 <_ikke_> [alpine-aports] [PATCH] community/py3-qtwebengine: disable broken arches
2019-03-15 19:54:04 <_ikke_> That one, right?
2019-03-15 19:54:20 <ddevault> ya
2019-03-15 19:54:52 <_ikke_> done
2019-03-15 19:55:03 <ddevault> thx
2019-03-15 19:55:43 <_ikke_> Do you manually have to close patches in patchwork? (I haven't used it a lot yet)
2019-03-15 19:55:56 <iggy> dang, just noticed someone beat me to updating ceph, time to sort out differences
2019-03-15 19:55:58 <ddevault> yeah
2019-03-15 19:56:20 <_ikke_> So 4631 can be closed then
2019-03-15 19:56:21 <ddevault> I can go clean up my patches
2019-03-15 19:57:00 <ddevault> there are a few here which could stand to be closed
2019-03-15 19:57:35 <ddevault> I think that was it
2019-03-15 19:57:47 <mps> ddevault: sorry for nitpick, but why you didn't put comment after 'arch="all !ppc64le !s390x"' instead of separate line above
2019-03-15 19:58:07 <ddevault> copy-pasted the qt5-qtwebengine package
2019-03-15 19:58:09 <ddevault> however
2019-03-15 19:58:12 <ddevault> I like putting the comments first anyway
2019-03-15 19:59:16 <mps> however you like :) to me few words better fits after option
2019-03-15 20:07:46 <ddevault> _ikke_: hm, this is going to be a pain
2019-03-15 20:07:52 <ddevault> suckless changed to a new git system which doesn't provide tarballs
2019-03-15 20:08:21 <_ikke_> ddevault: ugh
2019-03-15 20:08:30 <ddevault> ikr
2019-03-15 20:08:41 <_ikke_> What about suck*less*
2019-03-15 20:08:48 <ddevault> suckless often tends to suckmore
2019-03-15 20:08:52 <ddevault> but ubase & sbase are pretty good
2019-03-15 20:09:08 <SpaceToast> remember sta.li? :^)
2019-03-15 20:09:18 <_ikke_> heard about it
2019-03-15 20:10:05 <ddevault> does anyone know what repo viewer they use
2019-03-15 20:10:09 <ddevault> I used to know
2019-03-15 20:10:16 <ddevault> but it seems to have disappeared
2019-03-15 20:10:29 <ddevault> aha https://git.codemadness.org/stagit/
2019-03-15 20:10:43 <ddevault> I don't think we're going to get tarballs out of this any time soon
2019-03-15 20:11:19 <SpaceToast> sta.li started off decent, but then they couldn't agree on how to do it "right", so it died
2019-03-15 20:11:25 <SpaceToast> a few leftovers are around still, like morpheus
2019-03-15 20:12:53 <ddevault> _ikke_: are you opposed to solving this with a git clone in prepare()?
2019-03-15 20:12:58 <_ikke_> ddevault: I tried to find a reference to the check() policy but couldn't find it, but it has been discussed on irc
2019-03-15 20:12:59 <ddevault> if not I have a new patch ready
2019-03-15 20:15:54 <ddevault> also, the maintainer of this has been afk for >2 years
2019-03-15 20:15:56 <ddevault> I'm going to adopt it
2019-03-15 20:16:31 <_ikke_> alright. Sadly they don't allow git archive either :(
2019-03-15 20:16:52 <ddevault> it looks like this repo viewer is a static website which gets generated in the post-update hook
2019-03-15 20:16:56 <ddevault> so I don't think tarballs really make sense for it
2019-03-15 20:17:09 <_ikke_> yeah, I got the same impression
2019-03-15 20:17:20 <_ikke_> You can still generate tarballs the same way
2019-03-15 20:17:33 <ddevault> one for every commit?
2019-03-15 20:17:37 <ddevault> unlikely
2019-03-15 20:17:47 <_ikke_> github does it :P
2019-03-15 20:17:54 <_ikke_> at least, I get the idea they do
2019-03-15 20:17:55 <ddevault> I don't think github does that
2019-03-15 20:17:59 <ddevault> they just shell out to git archive
2019-03-15 20:18:11 <ddevault> that's what git.sr.ht does, too
2019-03-15 20:18:12 <mps> http://dl.suckless.org/tools/
2019-03-15 20:18:25 <mps> does this could be used
2019-03-15 20:18:31 <ddevault> ubase & sbase aren't here
2019-03-15 20:18:32 <ddevault> and they aren't versioned
2019-03-15 20:18:35 <_ikke_> ddevault: if that would be the case, they could also directly expose git archive, but they don't
2019-03-15 20:18:57 <ddevault> _ikke_: the shas from github tarball downloads match the ones generated by git archive on localhost
2019-03-15 20:19:02 <ddevault> _ikke_: I'm pretty sure that's all they do
2019-03-15 20:19:06 <_ikke_> ok
2019-03-15 20:19:09 <mps> eh, really strange site
2019-03-15 20:19:24 <mps> of all tools there I only use st
2019-03-15 20:19:34 <ddevault> I use dmenu, ubase, and sbase
2019-03-15 20:19:47 <mps> yes, dmenu sometimes
2019-03-15 20:20:00 <ddevault> and sometimes ii
2019-03-15 20:20:08 <_ikke_> ddevault: I see more packages use git clone, so I guess I'm not opposed to it :)
2019-03-15 20:20:15 <ddevault> _ikke_: patch sent :)
2019-03-15 20:20:32 <mps> but I found xst (patched st) on github and use it for few months
2019-03-15 20:21:03 <_ikke_> Is that a terminal?
2019-03-15 20:21:14 <ddevault> yeah
2019-03-15 20:21:19 <ddevault> not a very good one
2019-03-15 20:21:23 <mps> yes, st terminal with some useful pathes
2019-03-15 20:21:52 <SpaceToast> I used to use unpatched st, just custom config.h
2019-03-15 20:21:54 <mps> no need to always patch st
2019-03-15 20:22:00 <ddevault> I like alacritty
2019-03-15 20:22:01 <SpaceToast> but it's definitely lacking
2019-03-15 20:22:04 <ddevault> it's almost done
2019-03-15 20:22:13 <ddevault> too bad it's written in rust
2019-03-15 20:22:26 <_ikke_> It requires GPU acceleration right?
2019-03-15 20:22:34 <ddevault> yeah, which is also annoying on older hardware
2019-03-15 20:22:37 <ddevault> doesn't run on my laptop at all
2019-03-15 20:22:40 <SpaceToast> alacritty would be nice, but it has a killer problem
2019-03-15 20:22:46 <SpaceToast> it resizes during launch
2019-03-15 20:22:49 <SpaceToast> visibly so.
2019-03-15 20:23:19 <SpaceToast> developer doesn't seem to be interested in fixing it (blamed upstream X, upstream X said "not actually our thing, it's Y", Y said "but... you can do that though")
2019-03-15 20:23:23 <ddevault> the main problem for me is shit support for wayland clipboards
2019-03-15 20:23:55 <ddevault> it literally shells out to xclip for clipboard support :/
2019-03-15 20:24:30 <mps> I used rxvt for decades, but switched to x/st about year ago. works quite fine on low end, i.e. arm boxes
2019-03-15 20:24:41 <SpaceToast> I just run konsole nowadays
2019-03-15 20:24:53 <SpaceToast> works on wayland, comes by default with my DE, have a bunch of configs for it pre-made
2019-03-15 20:25:05 <ddevault> I used urxvt before alacritty
2019-03-15 20:25:14 <ddevault> I used an X terminal on Wayland for over 2 years :')
2019-03-15 20:25:55 <_ikke_> still using urxvt
2019-03-15 20:26:47 <mps> urxvt is really good, imo
2019-03-15 20:27:37 <_ikke_> I like it a lot
2019-03-15 20:27:48 <ddevault> which is why I used it for so long
2019-03-15 20:28:00 <ddevault> alacritty was the first terminal to come along that I think could reasonably replace urxvt
2019-03-15 20:28:01 <_ikke_> font support is not ideal though
2019-03-15 20:28:42 <_ikke_> ddevault: 4632 pushed
2019-03-15 20:29:01 <_ikke_> ddevault: https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/syncplay/syncplay-1.5.1-r0.log
2019-03-15 20:29:56 <ddevault> _ikke_: I know you said you don't fully grok patchworks, but could you update the patches when you merge them so I can keep track more easily?
2019-03-15 20:30:13 <_ikke_> sigh, accidentally pushed syncplay as well
2019-03-15 20:30:24 <_ikke_> ddevault: How would I do that?
2019-03-15 20:30:29 <ddevault> do you have a patchworks account?
2019-03-15 20:30:40 <_ikke_> yes
2019-03-15 20:30:49 <ddevault> log in, tick the affected patches, and change their properties at the bottom
2019-03-15 20:31:19 <_ikke_> Would it be 'Accepted' in that case?
2019-03-15 20:31:28 <ddevault> aye
2019-03-15 20:31:35 <ddevault> in the syncplay case it might be 'Fucked up' ;)
2019-03-15 20:31:42 <_ikke_> You don't have permissions to edit patch '[alpine-aports,v2] testing/ubase: update to 20190312' :(
2019-03-15 20:31:47 <ddevault> bleh
2019-03-15 20:31:49 <ddevault> I'll update it, then
2019-03-15 20:32:02 <ddevault> regarding syncplay
2019-03-15 20:32:04 <_ikke_> I'll poke someone to get that fixed
2019-03-15 20:32:06 <ddevault> it was part of a patch series
2019-03-15 20:32:08 <ddevault> https://lists.alpinelinux.org/alpine-aports/5209.html
2019-03-15 20:32:11 <_ikke_> yeah
2019-03-15 20:32:12 <ddevault> the missing deps are here
2019-03-15 20:32:47 <_ikke_> I saw them in my mail client, but not on patchwork
2019-03-15 20:33:04 <ddevault> looks like it didn't pick up the patch series correctly
2019-03-15 20:33:18 <ddevault> this series is over a year old, a bit late for forensics
2019-03-15 20:33:45 <_ikke_> I reverted syncplay for now
2019-03-15 20:33:53 <ddevault> I'll prepare a new patch series
2019-03-15 20:34:09 <ddevault> probably deserves a fresh look anyway
2019-03-15 20:37:31 <ddevault> looks like the patches were partially merged
2019-03-15 20:37:36 <ddevault> last year
2019-03-15 20:37:42 <ddevault> that's probably what broke patchworks
2019-03-15 20:42:42 <ddevault> actually, to be honest
2019-03-15 20:42:46 <ddevault> I haven't used syncplay in a long time
2019-03-15 20:42:54 <ddevault> I'm not even sure I want to maintain this package
2019-03-15 20:44:05 <_ikke_> heh
2019-03-16 19:08:58 <mps> would anyone look at https://github.com/alpinelinux/aports/pull/6667 PR, I'm waiting for it to be applied. I'm preparing patch for iwd to add netdev group in udev config file
2019-03-16 19:09:22 <mps> would anyone look at https://github.com/alpinelinux/aports/pull/6667 PR, I'm waiting for it to be applied. I'm preparing patch for iwd to add netdev group in udev config file
2019-03-16 19:10:09 <mps> oh, sorry for duplicate message, irssi messed something in tmux
2019-03-16 19:14:49 <_ikke_> done
2019-03-16 19:15:16 <_ikke_> I don't think the relbump was necessary though
2019-03-16 19:19:05 <mps> I don't know, I didn't posted this PR
2019-03-16 19:20:50 <mps> just didn't wanted to 'go over it' because mksully22 who posted it, did a god job to test it on ppc64 and deserve credit for that patch, however it looks small
2019-03-16 19:22:08 <mps> _ikke_: thanks
2019-03-16 19:29:12 <_ikke_> np
2019-03-16 20:08:14 <mps> if we add udev config file for pkg do we need to trigger udev reload in pkg.post-install, to reload this new config file
2019-03-16 20:32:26 <_ikke_> I would not know
2019-03-16 20:41:13 <mps> I'm patient, will wait till someone give clear answer. I looked through aports but didn't found anything as example, although I think udev reload should be done
2019-03-16 20:43:09 <_ikke_> hmmm
2019-03-16 20:43:17 <_ikke_> "Note tests should be run as root" :-/
2019-03-16 20:45:24 <mps> _ikke_: where?
2019-03-16 20:46:52 <_ikke_> tcpreplay
2019-03-16 20:47:48 <_ikke_> some tests fail if you don't run them as root
2019-03-16 20:48:07 <mps> hmm, strange, so it should be investigated, imo
2019-03-16 20:48:30 <_ikke_> I guess because the tool they test needs to run as root as well
2019-03-16 20:49:32 <mps> fakeroot couldn't help?
2019-03-16 20:49:32 <_ikke_> "Fatal Error: failed to open device eth0: socket: Operation not permitted"
2019-03-16 20:49:42 <_ikke_> didn't test yet
2019-03-16 20:49:55 <mps> ah, fakeroot not help in that case, probably
2019-03-16 20:50:08 <_ikke_> Yeah, wouldn't expect so
2019-03-16 20:51:33 <mps> maybe because that APKBUILD doesn't have check function
2019-03-16 20:51:45 <_ikke_> It doesn't, which I was trying to fix
2019-03-16 20:52:04 <_ikke_> there is a test suite, but it requires root
2019-03-16 20:55:01 <mps> test expect that the build have eth0
2019-03-16 20:55:30 <_ikke_> yes, that as well
2019-03-16 20:55:45 <mps> seems like they not think thoroughly about tests
2019-03-16 20:56:47 <mps> have configure options --with-testnic= and --with-testnic2=
2019-03-16 20:57:58 <mps> maybe disable these tests which requires root
2019-03-16 21:52:52 <_ikke_> mps: came up with this: https://tpaste.us/M5E1
2019-03-16 22:06:18 <mps> _ikke_: looks fine, you couldn't do much more without extra (and unnecessary, imo) effort
2019-03-17 08:28:00 <Fusl> anyone here who can reopen https://github.com/alpinelinux/aports/pull/4438 ?
2019-03-17 09:53:44 <nmeum> Fusl: done
2019-03-17 09:54:28 <Fusl> nmeum: thanks
2019-03-17 10:05:03 <clandmeter> Fusl: can you rebase it with master?
2019-03-17 10:08:09 <nmeum> the issues pointed out by jirutka should also be addressed imho
2019-03-17 12:29:26 <PureTryOut[m]> My pull request has just been automatically closed from being "stale", even though I commented on the PR to prevent it from doing so
2019-03-17 12:29:44 <PureTryOut[m]> so can someone reopen https://github.com/alpinelinux/aports/pull/4440
2019-03-17 12:42:36 <_ikke_> I can't open it, but I can review the patch
2019-03-17 12:47:32 <_ikke_> PureTryOut[m]: There are 2 commits from different authors?
2019-03-17 12:48:31 <PureTryOut[m]> Hmm I thought I resolved them all already, will look again
2019-03-17 12:49:21 <_ikke_> One commit moves it from testing to community, but that's not clear from the commit message
2019-03-17 12:57:54 <andypost[m]> @PureTryOut reopened
2019-03-17 12:58:07 <_ikke_> andypost[m]: thanks
2019-03-17 13:02:06 <_ikke_> Meeting today at 14.00 GMT about alpine teams and organization in #alpine-meetings
2019-03-17 13:02:21 <_ikke_> (in one hour)
2019-03-17 14:02:31 <_ikke_> Meeting will start soon, join #alpine-meetings to participate
2019-03-17 14:06:18 <_ikke_> ddevault: Were you interested in joining the meeting?
2019-03-17 14:18:26 <nmeum> PureTryOut[m]: unfortunately, commenting alone wont prevent it from being autoclosed. you need to convince someone to remove the stale label
2019-03-17 14:18:34 <nmeum> just fyi
2019-03-17 14:20:17 <_ikke_> nmeum: I've seen the stale label automatically been removed
2019-03-17 14:20:41 <nmeum> ooooh. ok then haven't seen that so far
2019-03-17 14:32:36 <vkrishn> hi, will there be an interest in packging tclkit ?
2019-03-17 14:32:46 <vkrishn> http://kitcreator.rkeene.org/fossil/index (builds newer ones)
2019-03-17 14:33:03 <_ikke_> vkrishn: The quickest way to add a package is to contribute it
2019-03-17 14:33:38 <vkrishn> older ones here, https://equi4.com/tclkit/download.html
2019-03-17 14:34:34 <vkrishn> problem is, I maynot be available for testing, and it gets stuck in /testing, triggering avalache of issues
2019-03-17 14:39:34 <vkrishn> but, would be using it though
2019-03-17 15:29:42 <PureTryOut[m]> nmeum: that is not what the bot message says
2019-03-17 18:35:06 <zbabir> Is it possible to download all alpine source and compile locally ?
2019-03-17 18:35:29 <danieli> what exactly do you mean by 'all alpine source'?
2019-03-17 18:35:45 <danieli> you /could/ download the aports repository and build all packages yourself, yes, but it would take a while
2019-03-17 18:39:18 <zbabir> I actually want to compile alpine for dockers, probably I need only the rootfs, I saw tool called alpine-make-rootfs in github but it seems it just downloads and installs apks while I want to have the sources locally
2019-03-17 18:39:39 <_ikke_> zbabir: why not use one of the alpine:* base images?
2019-03-17 18:40:32 <SpaceToast> zbabir: on https://alpinelinux.org/downloads/, you will find a "Mini Root Filesystem"
2019-03-17 18:40:35 <SpaceToast> use that. :)
2019-03-17 18:40:40 <zbabir> I must have the source code of every tool I use , company policy
2019-03-17 18:41:03 <SpaceToast> I assure you, alpine does not host the source for the linux kernel ;)
2019-03-17 18:41:28 <zbabir> I don't need the kernel since I'm going to run it on docker :)
2019-03-17 18:41:41 <SpaceToast> https://git.alpinelinux.org/aports/ - these are the sources for the "APKBUILD" files - which are used to construct apks
2019-03-17 18:41:52 <SpaceToast> you will need to read each of those to see where we get the sources for each package
2019-03-17 18:41:58 <SpaceToast> and download all of that recursively as well
2019-03-17 18:42:01 <SpaceToast> enjoy
2019-03-17 19:04:57 <mps> btw, IANAL but do Alpine have to have sources for all binaries which are GPL licenced
2019-03-17 19:05:33 <_ikke_> alpine is building everything from source
2019-03-17 19:07:02 <mps> I know, but afaik GPL require if you build and offer binary you must have option for end user to access source for that binary
2019-03-17 19:07:27 <_ikke_> They can
2019-03-17 19:07:29 <danieli> that's what the apkbuild is for, getting the same source as we use
2019-03-17 19:07:32 <_ikke_> We do not have to host it ourselfs
2019-03-17 19:07:38 <_ikke_> We can just point them upstream
2019-03-17 19:08:01 <danieli> we rarely modify the source, and if we do, patches are available
2019-03-17 19:08:23 <mps> yes, but we all have experience with disappeared source at APKBUILD src
2019-03-17 19:08:37 <danieli> it does happen, but then it should be updated or the package removed
2019-03-17 19:09:09 <_ikke_> mps: If that happens, I think we will drop the package as well, not?
2019-03-17 19:09:18 <mps> as I wrote IANAL, just pointed to posible problem
2019-03-17 19:09:43 <_ikke_> mps: I think the stable builders keep the fetched sources
2019-03-17 19:09:56 <mps> _ikke_: yes, drop aport but binary is still in downloads, ISO or tar.gz
2019-03-17 19:10:02 <_ikke_> ^^
2019-03-17 19:10:39 <danieli> if someone challenges us on that, we'll figure it out, it shouldn't be a big issue
2019-03-17 19:11:10 <mps> I'm not expert in this, but maybe Alpine should consult someone in free source community about that
2019-03-17 19:11:31 <danieli> I can ask a lawyer friend
2019-03-17 19:11:33 <mps> I mean lawyer
2019-03-17 19:12:07 <mps> danieli: you are so fast
2019-03-17 19:13:10 <danieli> she mostly does security cases but she's probably familiar with that too
2019-03-17 19:14:03 <mps> maybe is good idea to contact some of the free software law group
2019-03-17 19:14:27 <mps> (better safe than sorry)
2019-03-17 19:14:43 <danieli> if she doesn't know, she'll tell me she doesn't know
2019-03-17 19:14:58 <danieli> and then I'll hit up some of my other contacts who deals more with software licensing
2019-03-17 19:15:39 <mps> of course, I'm not against your idea, everyone who want and can help is welcome, imo
2019-03-17 19:17:11 <mps> Alpine grows in aports numbers and in popularity so sooner or later this could arise as issue
2019-03-17 19:17:36 <SpaceToast> I agree that asking a lawyer makes sense
2019-03-17 19:17:44 <SpaceToast> I don't think we need a special lawyer, though :)
2019-03-17 19:18:00 <danieli> I'm just asking people I know who deal with 'cyber law'
2019-03-17 19:18:18 <SpaceToast> aye, anyone that can provide an authoritative answer should be fine
2019-03-17 19:20:44 <mps> iirc, ncopa work for some free software company, maybe there is 'link'
2019-03-17 19:21:11 <_ikke_> mps: ncopa works for Docker nowadays
2019-03-17 19:22:32 <mps> ah, yes, I remember now :)
2019-03-17 20:29:52 <_ikke_> ddevault: ps, I'm moving ipython + deps to community, and while at it, removing python2 support
2019-03-17 20:30:17 <ddevault> _ikke_: cool
2019-03-17 20:30:48 <_ikke_> just fyi, that we don't do double work :-)
2019-03-17 20:30:57 <ddevault> ^^
2019-03-17 20:31:45 <p4Wv1qn095FW> oh cool, tauthon 2.8 just came out: https://github.com/naftaliharris/tauthon/releases/tag/v2.8.0 - they backported the cool features of py3 to py2 (and had to rename due to trademark issues to tauthon)
2019-03-18 02:57:06 <dimon222[m]> oh nice, new openjdk slowly gets to testing, seems openjdk9 already merged
2019-03-18 02:57:06 <dimon222[m]> maybe once others in, i can try get corretto in
2019-03-18 05:50:55 <_ikke_> clandmeter: https://github.com/alpinelinux/aports/pull/6723 any idea why py-virtualenv here is not built before py-parso (resulting in a build failure)?
2019-03-18 08:06:16 <clandmeter> _ikke_: why should it build py-virtualenv?
2019-03-18 08:06:27 <_ikke_> clandmeter: pkgrel bump
2019-03-18 08:06:58 <clandmeter> i dont see the commit?
2019-03-18 08:07:23 <clandmeter> i only see tox and parse
2019-03-18 08:07:27 <_ikke_> sorry, not virtualenv, py-tox, where virtualenv is added as a dependency
2019-03-18 08:07:27 <clandmeter> parso
2019-03-18 08:07:51 <_ikke_> so it should build py-tox
2019-03-18 08:07:57 <_ikke_> https://github.com/alpinelinux/aports/pull/6723/commits/94364d81965386dbb4a9468b4ce5d51e5ade1c55
2019-03-18 08:22:57 <clandmeter> tox is build before parso, which is correct, but parso pulls in the old tox not the new one.
2019-03-18 08:28:47 <fcolista> uff...firefox on edge segfaults on my ws
2019-03-18 08:29:09 <fcolista> # apk version firefox
2019-03-18 08:29:09 <fcolista> Installed:                                Available:
2019-03-18 08:29:09 <fcolista> firefox-62.0.3-r4                       = 62.0.3-r4
2019-03-18 08:29:19 <fcolista> (x86_64)
2019-03-18 10:33:24 <clandmeter> sigh, ruby gems have such a mess on disk.
2019-03-18 11:31:19 <_ikke_> fcolista: I'm working on updating and moving py-jedi to community, do you have any issues with that?
2019-03-18 11:31:43 <_ikke_> (I want to move ipython to community, which depends on py-jedi)
2019-03-18 11:31:57 <fcolista> np at all
2019-03-18 11:32:22 <_ikke_> fcolista: any issue with removing py2 support? (which is the direction Alpine is going in)
2019-03-18 11:32:43 <fcolista> please check if there's a dependency to py2 first in other packages. If not, go ahead
2019-03-18 11:33:14 <_ikke_> Yes, afaik, there isn't, but I'll double check
2019-03-18 11:39:06 <_ikke_> fcolista: only ipython seems to depend on py-jedi (which is python3 only)
2019-03-18 11:39:23 <fcolista> ok
2019-03-18 11:39:24 <fcolista> go ahead
2019-03-18 11:39:27 <fcolista> thx _ikke_
2019-03-18 11:39:37 <fcolista> is good to remove py2 pkgs
2019-03-18 11:39:53 <_ikke_> thanks, need to wait until parso is merged to be able to run the test suite
2019-03-18 13:36:58 <clandmeter> _ikke_: if you add pr's please check if they dont exist already. ncopa add some tool to easily check it from cmdline.
2019-03-18 13:37:16 <_ikke_> clandmeter: ah sorry :(
2019-03-18 13:37:35 <_ikke_> I just checked pkgs.a.o, forgot to check existing packages
2019-03-18 13:37:42 <clandmeter> np, happens to me to
2019-03-18 13:38:27 <_ikke_> which one did I duplicate?
2019-03-18 13:44:53 <tmhoang> <clandmeter> sigh, ruby gems have such a mess on disk. ---> they should change name to ruby germs
2019-03-18 13:45:51 <clandmeter> they should add gem install --only-shit-thats-really-needed
2019-03-18 13:46:11 <jwh> lol
2019-03-18 13:46:23 <danieli> same with node
2019-03-18 13:46:45 <clandmeter> node is mainly dependencies right?
2019-03-18 13:47:05 <clandmeter> or do they also store tarballs in node_modules
2019-03-18 13:47:06 <_ikke_> node is a mass of dependencies
2019-03-18 13:48:36 <jwh> packages for python/node/ruby/whatever dont really mske sense since its often you need specific versions anyway
2019-03-18 13:48:42 <jwh> mame
2019-03-18 13:48:45 <jwh> make omg
2019-03-18 13:49:11 <jwh> and that sort of thing should really be deployed by your application
2019-03-18 13:50:28 <clandmeter> with gems it has build artifacts tarballs log file and instruction videos included :|
2019-03-18 13:52:48 <clandmeter> oh and to make it backwards compatible we just copy the libraries to two places, just because we can and we dont care.
2019-03-18 13:53:21 <jwh> lol
2019-03-18 14:26:25 <tmhoang> well, I have had conversations with hw + firmware engineers complaining about os-level programmers doing xxx stuffs ...
2019-03-18 14:27:04 <tmhoang> offtopic
2019-03-18 14:28:09 <tmhoang> Oh I just discover we have snapshots for edge now
2019-03-18 14:28:12 <tmhoang> interesting
2019-03-18 14:31:22 <tmhoang> from 2014 ? http://dl-4.alpinelinux.org/alpine/edge/releases/x86_64/
2019-03-18 14:41:25 <_ikke_> clandmeter: repeating, what package was duplicated?
2019-03-18 14:42:23 <clandmeter> uhm
2019-03-18 14:42:27 <clandmeter> your latest one i think
2019-03-18 14:42:31 <clandmeter> the one i commented on
2019-03-18 14:42:42 <_ikke_> parso, but I cannot find another one, or was it on patchwork?
2019-03-18 14:42:48 <clandmeter> github
2019-03-18 14:42:52 <clandmeter> py-parso i think
2019-03-18 14:43:12 <_ikke_> https://github.com/alpinelinux/aports/pulls?q=is%3Apr+tox+py-parso+is%3Aopen
2019-03-18 14:43:18 <_ikke_> 1 result
2019-03-18 14:43:39 <clandmeter> maybe it was almost the same :)
2019-03-18 14:43:56 <clandmeter> seen so many PR's today i got lost
2019-03-18 14:44:00 <_ikke_> hehe :D
2019-03-18 14:44:14 <clandmeter> i went over all closed ones with a stale label
2019-03-18 14:44:44 <clandmeter> was a bit easier with  https://octobox.io
2019-03-18 14:45:11 <_ikke_> indeed, but that only works for issues you interacted with
2019-03-18 14:46:11 <clandmeter> https://github.com/alpinelinux/aports/pull/3426
2019-03-18 14:46:36 <_ikke_> so github search being broken :-/
2019-03-18 14:47:11 <_ikke_> nope, just me being broken
2019-03-18 14:47:25 <_ikke_> thanks
2019-03-18 14:48:15 <clandmeter> i think you can use that tool
2019-03-18 14:48:20 <clandmeter> but i cant remember the name
2019-03-18 14:48:29 <_ikke_> hub?
2019-03-18 14:48:33 <clandmeter> no
2019-03-18 14:48:38 <clandmeter> ncopa help me here
2019-03-18 14:48:48 <ncopa> hi
2019-03-18 14:48:51 <clandmeter> i have the same brain issue as you have.
2019-03-18 14:48:55 <clandmeter> good memory but short
2019-03-18 14:49:11 <_ikke_> WHat is the name of the tool to check for existing PRs for packages
2019-03-18 14:49:13 <_ikke_> ?
2019-03-18 14:49:19 <ncopa> aports-ghpr
2019-03-18 14:49:49 <clandmeter> right, its the name that makes it difficult to remember :)
2019-03-18 14:49:56 <ncopa> :)
2019-03-18 14:50:17 <clandmeter> _ikke_: you can run it from an aports dir
2019-03-18 14:50:24 <clandmeter> should look up for that aport
2019-03-18 14:50:40 <_ikke_> any idea where I can find the tool?
2019-03-18 14:50:47 <clandmeter> abuild?
2019-03-18 14:50:58 <clandmeter> or apk add cmd:...
2019-03-18 14:51:25 <_ikke_> cmd:aports-ghpr (missing):
2019-03-18 14:51:35 <_ikke_> cmd:aport-ghpr (missing):
2019-03-18 14:51:36 <clandmeter> hmm
2019-03-18 14:51:42 <clandmeter> maybe i build it myself
2019-03-18 14:51:46 <clandmeter> i thought it was in aports
2019-03-18 14:52:02 <mps> _ikke_: aports-ghpr and not aport-ghpr
2019-03-18 14:52:13 <_ikke_> I tired both :)
2019-03-18 14:52:23 <_ikke_> s/tired/tried
2019-03-18 14:52:23 <alpine-meetbot> _ikke_ meant to say: I tried both :)
2019-03-18 14:52:29 <clandmeter>  /usr/bin/aports-ghpr is owned by aports-ghpr-0.2-r1
2019-03-18 14:52:42 <clandmeter> im also tired
2019-03-18 14:52:43 <_ikke_> and what repo contains that package?
2019-03-18 14:52:53 <mps> 'apk search aports-ghpr' aports-ghpr-0.2-r1
2019-03-18 14:53:04 <_ikke_> returns nothing for me
2019-03-18 14:53:14 <mps> testing
2019-03-18 14:53:15 <_ikke_> ah
2019-03-18 14:53:26 <danieli> it's only in edge/testing
2019-03-18 14:53:28 <_ikke_> didn't enable testing on my build container
2019-03-18 14:53:46 <clandmeter> https://tpaste.us/qKje
2019-03-18 14:53:53 <_ikke_> thanks
2019-03-18 14:54:00 <_ikke_> got it
2019-03-18 14:55:25 <_ikke_> returns nothing for py-parso
2019-03-18 14:58:02 <_ikke_> clandmeter: but what do you want to do re py-parso?
2019-03-18 14:58:39 <clandmeter> that i dont know. i just wanted to notify you about the issue.
2019-03-18 14:58:54 <clandmeter> i havent looked into it.
2019-03-18 14:59:08 <_ikke_> It doesn't matter a lot to me, I just need it to get checks working for py-jedi
2019-03-18 15:00:05 <clandmeter> in a perfect world we would have a bot do the checking.
2019-03-18 16:01:37 <andypost[m]> kaniini: upgrade is ready to go https://github.com/alpinelinux/aports/pull/6030
2019-03-18 16:02:14 <andypost[m]> also it may affect py3 innitiative, so whould be great to get more eyes on it
2019-03-18 17:31:55 <HRio> ping on this oneliner https://github.com/alpinelinux/aports/pull/6656, its already merged upstream
2019-03-18 18:07:04 <ncopa> HRio: merged. thanks!
2019-03-18 18:10:47 <HRio> thanks, I think we should backport to v3.9 as well: https://github.com/alpinelinux/aports/pull/6736
2019-03-18 18:29:19 <HRio> ncopa: thanks! now we can have swap without bitfaults in Alpine :-)
2019-03-18 18:35:14 <ncopa> thanks!
2019-03-18 18:38:19 <mps> anyone can tell should be dbus reload used in pkg.post-install or pkg.post-upgrade when the new config file is added to dbus
2019-03-18 18:38:46 <mps> I looked through current aports but didn't found anything about that
2019-03-18 18:40:07 <mps> I think it dbus reload should be invoked but not sure if it is according to (not yet written) policy
2019-03-18 18:40:30 <ncopa> mps: i dont know to be honest, but it looks like it need to invoke dbus reload
2019-03-18 18:40:39 <ncopa> apparently there is a trigger taking care of it
2019-03-18 18:41:03 <mps> it could be called by 'dbus send' with some parameters
2019-03-18 18:41:25 <ncopa> any package installing files to /etc/dbus-1/system.d will trigger a reload
2019-03-18 18:41:32 <mps> no need to restart dbus or use /etc/init.d/dbus
2019-03-18 18:41:38 <ncopa> the parameters are in dbus.trigger
2019-03-18 18:41:51 <ncopa> dbus-send --system --type=method_call --dest=org.freedesktop.DBus / \
2019-03-18 18:41:51 <ncopa>         org.freedesktop.DBUS.ReloadConfig >/dev/null 2>&1 || :
2019-03-18 18:42:07 <mps> yes, but in my test it didn't triggered reload
2019-03-18 18:42:37 <ncopa> maybe its broken then
2019-03-18 18:42:47 <mps> I looked at this and thought to add it in post-install
2019-03-18 18:42:59 <mps> ok, will check dbus.trigger
2019-03-18 18:43:34 <ncopa> apk fix dbus should also trigger it
2019-03-18 18:44:44 <mps> don't quite undestand this. we can add dbus.trigger in pkg?
2019-03-18 18:46:42 <mps> or we call it pkgname.trigger and put needed trigger command there
2019-03-18 18:48:15 <ncopa> yes, we call it $pkgname.trigger
2019-03-18 18:48:42 <ncopa> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#triggers
2019-03-18 18:48:45 <mps> thanks for clafification, now I understand this better
2019-03-18 18:49:25 <mps> and sorry because I didn't noticed this on url you just posted
2019-03-18 18:55:14 <ncopa> no worries. thats the purpose of this channel
2019-03-18 18:55:48 <ncopa> to point people to the right section in the docs
2019-03-18 18:56:21 <ncopa> mps: btw, i want merge the llvm patches this week
2019-03-18 18:57:20 <mps> ok, I will be here most of time, only on next Sunday I will be off-line
2019-03-18 18:58:18 <mps> Mart 24, I have a sport seminar which I cannot escape
2019-03-18 18:58:34 <ncopa> ok good. it looks like i tried merge it before but something must have failed
2019-03-18 18:58:51 <ncopa> may also need to look over gihub PRs. iirc there was a PR with the same
2019-03-18 18:59:05 <mps> I tested in on x86_64, aarch64 and armv7
2019-03-18 18:59:32 <mps> yes, I have seen, clandemeter pointed me there
2019-03-18 19:00:34 <mps> tried to test in on x86 in lxc running on x86_64, but don't know how to set correct x86 personality
2019-03-18 19:02:51 <mps> and, I hope after clandemeter manage to make gitlab we will not have dispersed eforts like when I saw these PR's on github
2019-03-18 19:03:22 <_ikke_> yes, we're working hard on it (mostly clandmeter atm though)
2019-03-18 19:04:00 <mps> _ikke_: hehe, I'm following your efforts on infra
2019-03-18 19:04:52 <mps> looks like you are really devoted to make it
2019-03-18 19:14:46 <kaniini> andypost[m]: you can go ahead and push it
2019-03-18 19:40:39 <_ikke_> Someone able to take a look at https://github.com/alpinelinux/aports/pull/6740?
2019-03-18 20:42:23 <clandmeter> ok ill push it
2019-03-18 20:47:46 <clandmeter> ddevault: factory boy is brokenb
2019-03-18 20:48:01 <ddevault> how so
2019-03-18 20:48:11 <clandmeter> check #alpine-commits
2019-03-18 20:48:25 <clandmeter> ah you are not in that channel
2019-03-18 20:48:34 <ddevault> my god there are a lot of alpine channels
2019-03-18 20:48:36 <ddevault> too many
2019-03-18 20:48:39 <_ikke_> :)
2019-03-18 20:49:03 <_ikke_> I'm in 9 alpine related channels atm
2019-03-18 20:51:22 <SpaceToast> I think #alpine-commits is a bot channel, you probably wouldn't want that spam here :)
2019-03-18 20:52:54 <_ikke_> correct
2019-03-18 20:52:59 <_ikke_> It's very spammy
2019-03-18 22:22:35 <andypost[m]> kaniini:
2019-03-18 22:22:58 <andypost[m]> package now moved to main but I see duplicate in testing/py-sqlalchemy7
2019-03-18 22:34:47 <kaniini> remove it
2019-03-18 22:38:17 <jwh> nice job on lowering prs heh
2019-03-18 22:38:50 <jwh> ohhh, cockroach v19 rc, awesome
2019-03-19 07:58:45 <fcolista> clandmeter, you around?
2019-03-19 07:58:53 <clandmeter> no
2019-03-19 07:58:55 <clandmeter> :)
2019-03-19 07:58:59 <fcolista> ok I'll try lter
2019-03-19 07:59:02 <fcolista> :D
2019-03-19 07:59:06 <clandmeter> whats up, i need to go soon
2019-03-19 10:32:50 <ncopa> mps: what was the reason that we went for llvm6 instead of llvm7? there was some issue with gcc8?
2019-03-19 10:48:22 <ncopa> ddevault: py-faker is blocking the builders: https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/py-faker/py-faker-1.0.2-r0.log
2019-03-19 10:52:25 <mps> ncopa: they announced llvm7.1 for Feb 27 but still nothing there
2019-03-19 10:52:56 <ncopa> mps: i see that both void-linux and adelie has upgraded to 7.0.1
2019-03-19 10:53:03 <ncopa> so apparently it builds with gcc8?
2019-03-19 10:53:41 <mps> llvm7.0 with gcc 8.2 and musl is problematic and could not be made to be in 'good shape', because that they have a plan for llvm7.1
2019-03-19 10:53:57 <ncopa> and gcc 8.3?
2019-03-19 10:54:15 <ncopa> do you have links to the specific issues?
2019-03-19 10:54:22 <mps> maybe there is a fix for gcc 8.3, didn't looked at it
2019-03-19 10:55:29 <mps> and, llvm8 announced for the end of Feb but till now it is not released
2019-03-19 10:55:32 <ncopa> i merged https://github.com/alpinelinux/aports/pull/5638
2019-03-19 10:55:42 <ncopa> it was almost identical to your patch
2019-03-19 10:56:09 <ncopa> but it added it to testing repo, and it had the deps slightly better
2019-03-19 10:56:16 <ncopa> so i though that was safer
2019-03-19 10:56:59 <mps> i didn't tried to build that from github PR, in hope for llmv8
2019-03-19 10:59:53 <mps> I'm not sure if we need to add llvm7 to Alpine, obviously llvm8 will be released in some time and llvm7 will be llvm7.1
2019-03-19 11:00:13 <mps> and don't see any package need llvm7
2019-03-19 11:01:00 <mps> at the end, maybe we can just left llvm5 and wait for llvm8
2019-03-19 11:01:35 <mps> I mean. left llvm5 in Alpine as it is now
2019-03-19 11:02:16 <mps> ok, new version of rust will probably need at least llvm6, huh what a mess
2019-03-19 11:03:03 <ncopa> what does not currently work with llvm7?
2019-03-19 11:03:16 <ncopa> apparenly, ponyc works with llvm7
2019-03-19 11:03:24 <ncopa> recent version
2019-03-19 11:04:39 <mps> ok, I didn't followed it in last two (about) and now when we have gcc 8.3 maybe it is worth to try llvm7 again
2019-03-19 11:05:28 <mps> s/two/two week/
2019-03-19 11:05:29 <alpine-meetbot> mps meant to say: ok, I didn't followed it in last two week (about) and now when we have gcc 8.3 maybe it is worth to try llvm7 again
2019-03-19 11:05:49 <ncopa> ok, i will give it a try
2019-03-19 11:06:02 <ncopa> looks like recent julia requires at leaset llvm6
2019-03-19 11:06:07 <ncopa> least*
2019-03-19 11:06:26 <mps> right, and ponyc I think
2019-03-19 11:06:32 <ncopa> which means that we can probably remove llvm3.9
2019-03-19 11:07:05 <mps> no, something depends on that version exactly, but forgot which package
2019-03-19 11:07:13 <ncopa> julia
2019-03-19 11:07:59 <mps> if it is only julia than then ok, if julia can be built with llvm6 or llvm7
2019-03-19 11:08:08 <ncopa> yes, i think it was it
2019-03-19 11:08:25 <ncopa> crystal and ghc i dont know yet
2019-03-19 11:09:23 <mps> crystal depends on llvm5
2019-03-19 11:10:56 <ncopa> ok. we need keep llvm5 then i suppose
2019-03-19 11:11:09 <mps> julia in unmaintained depends on llvm3.9, but don't know what is status of new julia versions
2019-03-19 11:11:25 <ncopa> i checked their webpage
2019-03-19 11:11:38 <ncopa> last release has support for newer llvm
2019-03-19 11:11:57 <ncopa> https://docs.julialang.org/en/v1/NEWS/#External-dependencies-1
2019-03-19 11:11:59 <mps> I think we should keep llvm3.9 for next release, to be safe, it doesn't need any work
2019-03-19 11:14:06 <mps> will look at llvm7.0.1 if could be built with gcc 8.3
2019-03-19 11:14:57 <mps> I tried ponyc with llvm6 but failed
2019-03-19 11:15:33 <ncopa> ghc 8.6 supports llvm6 https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/backends/llvm/installing
2019-03-19 11:17:38 <mps> btw, I noticed that most big distros keep all major versions of llvm
2019-03-19 11:24:48 <ncopa> i think we may need to do that too
2019-03-19 11:28:10 <mps> yes, we don't know what users do with them, maybe they have some works which depends on older versions
2019-03-19 11:42:03 <ncopa> mps: llvm7 builds
2019-03-19 11:42:10 <ncopa> and testsuite passes
2019-03-19 11:43:51 <mps> nice, on which arch's
2019-03-19 11:50:49 <mps> should be pkgrel bumped if patch is added to APKBUILD in testing aports? I think this is must but aks just in case
2019-03-19 11:55:36 <p4Wv1qn095FW> is it possible to postpone the removal of py2 packages? gnuradio is sadly still py2 only.
2019-03-19 11:56:53 <_ikke_> p4Wv1qn095FW: there is a mailing list post on alpine-devel, might be worth mentioning it there
2019-03-19 12:04:25 <ncopa> mps: x86_64 only
2019-03-19 12:05:10 <mps> do you APKBUILD to try on aarch64 and armv7
2019-03-19 12:05:43 <ncopa> mps: if you add a patch and the resulting compiled binary becomes different, then yes, you need bump pkgrel
2019-03-19 12:05:48 <andypost[m]> p4Wv1qn095FW: as I see it was fixed for py3 https://github.com/gnuradio/gnuradio/pull/1435
2019-03-19 12:06:19 <ncopa> the only time where you dont need bump pkgrel is if you dont need trigger rebuild of package
2019-03-19 12:06:41 <ncopa> and that you are sure that a rebuild would result in same thing
2019-03-19 12:06:48 <p4Wv1qn095FW> andypost[m]: there is still no release
2019-03-19 12:07:40 <mps> ncopa: thanks for explanation, I thought so.
2019-03-19 12:08:10 <ncopa> so we never end up with the situation: user1: package foo-1.0-r1 does not work. user2: foo-1.0-r1 works for me. user1: which version of foo-1.0-r1 do you have? the one with the last patch added or the version without?
2019-03-19 12:08:13 <p4Wv1qn095FW> there is ongoing work to port it to py3, but it's a huge f*cking monster this gnuradio
2019-03-19 12:10:07 <andypost[m]> so package could use patches
2019-03-19 12:11:13 <mps> ncopa: ok, I'm adding patch for iwd in which I added netdev group for dbus service, so obviously need pkgrel bump
2019-03-19 12:29:42 <ncopa> p4Wv1qn095FW: i think there should be a reasonable migration time from python2 to python3
2019-03-19 12:29:54 <ncopa> question is what "reasonable time" is
2019-03-19 12:30:00 <ncopa> python 3 have been out for many years now
2019-03-19 12:34:13 <danieli> we should probably announce that we've begun work on migrating from 2 to 3
2019-03-19 12:34:27 <danieli> and by the time we're done in edge (and subsequent releases), people should have had some time to move
2019-03-19 12:34:34 <ncopa> right
2019-03-19 12:34:42 <ncopa> so, what i think is
2019-03-19 12:35:06 <ncopa> we ship python2 with alpine 3.10, and at the same time announce that this is the last version of python2
2019-03-19 12:35:12 <ncopa> in 3.11 we remove it
2019-03-19 12:35:26 <ncopa> because we cannot support it past jan 2020
2019-03-19 12:36:15 <ncopa> i also wonder what to do with armhf (armv6) support
2019-03-19 12:36:19 <ncopa> i would like to drop it
2019-03-19 12:36:32 <ncopa> and only support armv7
2019-03-19 12:36:57 <p4Wv1qn095FW> that sounds reasonable, i hope the gnuradio people manage to get out a py3 compatible release by then...
2019-03-19 12:37:07 <danieli> sounds reasonable to me
2019-03-19 12:54:56 <ncopa> mps: llvm7 builds on armv7 too
2019-03-19 12:56:11 <mps> so, llvm6 and llvm7 now van built on x86_64, aarch64 and armv7
2019-03-19 12:56:22 <mps> s/van/can/
2019-03-19 12:56:22 <alpine-meetbot> mps meant to say: so, llvm6 and llvm7 now can built on x86_64, aarch64 and armv7
2019-03-19 12:57:44 <mps> but, because Alpine never released llvm6, maybe could be skipped. what other developers think about this
2019-03-19 13:11:46 <jomat> jirutka: why is mailman-webui in your user-aports disabled, what needs to be fixed there? https://github.com/jirutka/user-aports/commit/09d392096202da6a595bbc7bd13112d596499bbc
2019-03-19 13:14:02 <ncopa> jomat: jirutka does not respond here.
2019-03-19 13:14:19 <jomat> oh ok :-/
2019-03-19 13:14:34 <jomat> sorry if this question was quite offtopic then :-/
2019-03-19 13:15:07 <ncopa> no worries
2019-03-19 13:27:13 <_ikke_> so main/py-tox is stil failing (missing six as a dependency). I wonder if there is a better way to verify it is even working
2019-03-19 13:28:15 <mps> ncopa: do you have aports patch for llvm7, I'd try to build it on aarch64 and try with it to build rust
2019-03-19 13:40:43 <mps> how we could in APKBUILD force install/upgrade pkg-openrc when we install/upgrade main pkg
2019-03-19 13:43:00 <SpaceToast> if you're using the default pkg-openrc() you should already have that happen (through install_if)
2019-03-19 13:47:10 <ncopa> aarch64 works
2019-03-19 13:47:24 <mps> SpaceToast: care to explain pkg-openrc(), is it something to be added to APKBUILD. I thought that $pkgname-openrc in subpackages is enough
2019-03-19 13:48:00 <SpaceToast> yes, if you have $pkgname-openrc, you're supposed to provide a openrc() subpackage function, but there's already a default one (making it enough)
2019-03-19 13:48:20 <SpaceToast> if you are using a default one, your $pkgname-openrc subpackage gets install_if="openrc $pkgname" in its metadata
2019-03-19 13:48:33 <SpaceToast> which means that, if you have openrc and $pkgname installed, it'll automatically get installed too
2019-03-19 13:48:40 <mps> aha, so I don't need to put openrc() function in APKBUILD
2019-03-19 13:49:04 <SpaceToast> no, there is a default one
2019-03-19 13:49:13 <SpaceToast> in fact, you likely should avoid using a custom one unless you have a very specific reason to
2019-03-19 13:49:37 <SpaceToast> same as with start() and stop() in your openrc init scripts
2019-03-19 13:50:01 <mps> I always try to avoid custom functions in APKBUILD
2019-03-19 13:50:51 <mps> but I have 'install=""', i.e. empty, maybe that is problem.
2019-03-19 13:51:11 <SpaceToast> refer to https://wiki.alpinelinux.org/wiki/APKBUILD_Reference please :)
2019-03-19 13:51:22 <SpaceToast> (at least until the developer-handbook has an updated and upkept variant of it)
2019-03-19 13:52:18 <mps> I have that opened in browser but there is nothing about openrc
2019-03-19 13:53:58 <SpaceToast> there's something about install=""
2019-03-19 13:54:12 <SpaceToast> and the install_if I mentioned.
2019-03-19 13:58:13 <mps> uh, thanks, will read and try to understand
2019-03-19 13:59:12 <ncopa> mps: i have some issues with ppc64le, i will try fix that and then i can just push it
2019-03-19 14:00:13 <mps> ncopa: maybe toolchain triplet is a problem for ppc64
2019-03-19 14:00:56 <mps> no, I see
2019-03-19 14:01:02 <mps> it failed on tests
2019-03-19 14:15:12 <ddevault> ncopa: sent a fix for faker
2019-03-19 14:18:26 <ncopa> ddevault: i think i fixed it already, by upgrade it
2019-03-19 14:18:42 <ncopa> looks like it was an upstream issue
2019-03-19 14:22:38 <ncopa> ha! i think i found a fix for llvm
2019-03-19 14:30:35 <ddevault> ncopa: cool
2019-03-19 15:10:55 <mps> ncopa: you need to add python2 to makedepends in llvm7
2019-03-19 15:11:15 <ncopa> no, i want remove python2
2019-03-19 15:11:17 <ncopa> im on it
2019-03-19 15:12:47 <mps> aha, ok, I tried to build and have seen python2 in some places
2019-03-19 17:59:27 <otlabs> hi ppl
2019-03-19 18:02:45 <_ikke_> hi
2019-03-19 18:04:17 <otlabs> I have submitted PR for main/libuv upgrade. Drone has fails for x86 and x86_64 on one test, same time Drone arm* and Travis pass that test fine. Please, advice!
2019-03-19 18:39:02 <otlabs> andypost[m]: are you around?
2019-03-19 20:24:26 <fcolista> any objection on moving py-pycodestyle to main ? it's for #10137
2019-03-19 20:28:11 <SpaceToast> ping ncopa - there's some weird behavior in pingu - it isn't duplicating all the rules it needs to for things to work properly
2019-03-19 20:28:32 <SpaceToast> should I file a bug? (if so, where?) (or can I just complain in here? :) )
2019-03-19 20:29:21 <fcolista> :)
2019-03-19 20:29:47 <_ikke_> bugs.a.o
2019-03-19 20:30:52 <SpaceToast> sure, but is pingu even a category there?
2019-03-19 20:31:44 <_ikke_> Not sure what pingu is :)
2019-03-19 20:32:07 <fcolista> hehe. pnigu is an utility allowing failover to one connectivity to another
2019-03-19 20:32:11 <fcolista> if one goes down
2019-03-19 20:32:25 <fcolista> it was coded by ncopa years ago
2019-03-19 20:32:48 <_ikke_> ah, something like pacemaker?
2019-03-19 20:33:23 <SpaceToast> it's quite good but it has a very unfortunate side-effect with nat
2019-03-19 20:33:28 <fcolista> i don't knwo peacemaker (my heart works fine) :)
2019-03-19 20:33:30 <SpaceToast> it just needs to do things a bit differently
2019-03-19 20:33:40 <SpaceToast> (rather, in the opposite way)
2019-03-19 20:34:00 <SpaceToast> instead of copying over only for WAN iface X, it should copy over everything except tracked ifaces :)
2019-03-19 20:34:27 <fcolista> _ikke_, much less invasive (looking at https://wiki.clusterlabs.org/wiki/Pacemaker)
2019-03-19 20:34:51 <fcolista> SpaceToast, you need conntrackd  for that i suppose
2019-03-19 20:35:15 <SpaceToast> no no, pingu already does most of this
2019-03-19 20:35:28 <SpaceToast> it sets up an ip rule for src WAN_IP and mirrors all routes that mention WAN_IF
2019-03-19 20:35:35 <SpaceToast> but that breaks loopback nat
2019-03-19 20:35:49 <SpaceToast> all that needs to happen is for LAN routes to be reproduced in each table
2019-03-19 20:35:59 <SpaceToast> (aka routes that do not involve ANY tracked IF)
2019-03-19 20:36:11 <SpaceToast> this is pure `ip route` territory
2019-03-19 20:36:19 <fcolista> yes, definetly
2019-03-19 20:36:58 <fcolista> but iirc pingu reads routing table you can easily manage by yourself
2019-03-19 20:37:09 <fcolista> in /etc/iproute2/rttablewhaterveriscalled
2019-03-19 20:37:13 <SpaceToast> (because what happens otherwise is a LAN IP will try to connect to https://WAN_THING, and, due to the rule, it'll get into the table, and since there's no specific rule for that it replies on WAN IFACE)
2019-03-19 20:37:19 <SpaceToast> no, I mean the implicit rules
2019-03-19 20:37:30 <SpaceToast> things like 192.168.0.0/24 dev eth1
2019-03-19 20:37:40 <SpaceToast> either way, just looked, bugs.a.o has no category for it :)
2019-03-19 20:38:50 <SpaceToast> what I'm doing right now is setting route-table explicitly, and then hard-coding gateway-up-action to add the routes to that
2019-03-19 20:38:59 <SpaceToast> but that's kind of a pain to manage once you have ~20 LAN VLANs
2019-03-19 20:39:30 <SpaceToast> my previous workaround was to set the rule priority higher than default rules, but that breaks outside communication over the static ip
2019-03-19 20:39:36 <SpaceToast> (well over the lower-priority iface*)
2019-03-19 21:00:13 <_ikke_> Anyone knows anything about udev_hwdb on alpine?
2019-03-19 21:26:56 <andypost[m]> otlabs: I'm around
2019-03-19 21:31:49 <andypost[m]> ncopa: so makes no sense to provide py2 package? https://github.com/alpinelinux/aports/pull/6244
2019-03-19 21:35:08 <otlabs> andypost[m]: greetings!
2019-03-19 21:36:36 <otlabs> andypost[m]: some time ago you have checked my PR for cython, https://github.com/alpinelinux/aports/pull/6244. I would like to convert it to py-cython with support for both python 3 and 2. I have addressed all you suggestions. so I wounder if you can take a look on it one more time. Thank you!
2019-03-19 21:49:50 <andypost[m]> otlabs: I read above "ncopa: np, i want remove python2"
2019-03-19 21:50:11 <andypost[m]> also there
2019-03-19 21:50:42 <andypost[m]> some python3 sprint happening, so better to wait
2019-03-19 22:08:36 <mps> anyone with push rights would review patch for iwd at https://patchwork.alpinelinux.org/patch/4641/, where I added netdev in dbus config
2019-03-19 22:11:30 <_ikke_> mps: you added the doc subpkg, but it seems to be empty
2019-03-19 22:11:38 <_ikke_> >>> ERROR: iwd-doc*: Missing /home/build/aports/testing/iwd/pkg/iwd-doc
2019-03-19 22:14:37 <mps> strange, it should install iwmon.1
2019-03-19 22:14:59 <mps> let me see, will rebuild it again locally
2019-03-19 22:16:16 <mps> hmm, 'apk info -L iwd-doc' shows: usr/share/man/man1/iwmon.1.gz
2019-03-19 22:21:44 <mps> I see, it does not create pkg/iwd-doc but copies man page to pkg/iwd/usr/share/man/man1 directly, but somehow rootpkg manage to make correct iwd-doc.apk
2019-03-19 22:22:18 <mps> on local build with 'abuild -r' it works without error
2019-03-19 22:22:30 <_ikke_> default_doc should split it out to the correct subpackage
2019-03-19 22:22:39 <mps> looks like builders are more strict
2019-03-19 22:22:51 <_ikke_> this is on my local build container
2019-03-19 22:22:53 <_ikke_> not on the builders
2019-03-19 22:23:01 <_ikke_> just abuild -r
2019-03-19 22:23:39 <mps> I also run 'abuild -r', but now tried step-by-step to se what happens
2019-03-19 22:25:40 <mps> 'abuild rootkpg' make pkg/iwd-doc and moves man page there
2019-03-19 22:27:11 <mps> strange, it works without issue here :/
2019-03-19 22:28:16 <_ikke_> Let me check
2019-03-19 22:29:57 <mps> could be make dependency issue, txt to man converter
2019-03-19 22:30:32 <_ikke_> yeah
2019-03-19 22:31:20 <otlabs> andypost[m]: ok, thank you, so I will wait
2019-03-19 22:33:13 <mps> _ikke_: yes, it need a2x to convert txt to man, and I have it installed, need to add to makedepends
2019-03-19 22:33:47 <mps> thanks for review and sorry for taking your time
2019-03-19 22:33:52 <_ikke_> No worry
2019-03-19 22:35:32 <mps> I will add asciidoc to makedepends, but not now, I had a hard work day
2019-03-19 22:35:40 <_ikke_> heh
2019-03-19 22:35:47 <_ikke_> ping me if you have a new version
2019-03-19 22:36:12 <mps> tomorrow :)
2019-03-19 22:37:14 <_ikke_> sleep tight
2019-03-19 22:37:47 <mps> will try, and good night to you and all
2019-03-19 22:44:43 <otlabs> need to go, see you
2019-03-19 22:53:33 <dimon222[m]> any specific reason why edge/community repo is not included for drone builds?
2019-03-19 22:53:57 <clandmeter> elaborate?
2019-03-19 22:54:53 <dimon222[m]> i made PR for aports with some things used from community repo, but apparently travis/drone only pick up stuff from edge/main, but not for edge/community. I'm sure i saw it was using stuff from testing and community previously
2019-03-19 22:54:55 <_ikke_> dimon222[m]: if it's building something from main, community is not inlcuded
2019-03-19 22:55:16 <_ikke_> dimon222[m]: packages in main cannot depend on packages in community
2019-03-19 22:55:36 <dimon222[m]> @_ikk
2019-03-19 22:56:09 <dimon222[m]> _ikke_: damn, can we consider moving some packages from community to main?
2019-03-19 22:56:34 <clandmeter> we prefer the other way around if possible.
2019-03-19 22:57:25 <clandmeter> which PR is it/
2019-03-19 22:57:38 <dimon222[m]> if somebody can assist me, the problem is py-sqlalchemy tests that take over 1 hour if using single-threaded pytest. Plugin for paralellize tests pytest-xdist is part of community
2019-03-19 22:57:39 <dimon222[m]> https://github.com/alpinelinux/aports/pull/6030
2019-03-19 22:59:33 <clandmeter> what does the -n4 do?
2019-03-19 23:00:20 <dimon222[m]> 4 parallel workers, one per cpu
2019-03-19 23:00:34 <clandmeter> you have 4 cpus?
2019-03-19 23:01:49 <dimon222[m]> well i have 6, i dont know how many do we have assigned for travis/drone, probably 2
2019-03-19 23:02:19 <clandmeter> i guess you mean you have 6 cores?
2019-03-19 23:02:23 <dimon222[m]> yep
2019-03-19 23:02:45 <clandmeter> so what happens if somebody tries to build it with 1 core?
2019-03-19 23:02:50 <dimon222[m]> cpu in this sense is cores, terminology problem
2019-03-19 23:02:51 <dimon222[m]> https://pypi.org/project/pytest-xdist/
2019-03-19 23:02:52 <dimon222[m]> they mention it as cpu anyway
2019-03-19 23:03:02 <clandmeter> or somebody has 96 cores?
2019-03-19 23:04:13 <clandmeter> Especially for longer running tests or tests requiring a lot of I/O this can lead to considerable speed ups. This option can also be set to auto for automatic detection of the number of CPUs.
2019-03-19 23:04:21 <dimon222[m]> yep, auto might be considered
2019-03-19 23:04:34 <dimon222[m]> anyway, this plugin is part of community, not main, thats the main catch
2019-03-19 23:05:47 <_ikke_> Can we reuse the JOBS variable in abuild.conf?
2019-03-19 23:06:10 <clandmeter> that would be even better
2019-03-19 23:06:45 <clandmeter> i had to move a lot of python pkgs to main yesterday befoer of this aport.
2019-03-19 23:07:04 <clandmeter> s/befoer/because
2019-03-19 23:07:04 <alpine-meetbot> clandmeter meant to say: i had to move a lot of python pkgs to main yesterday because of this aport.
2019-03-19 23:07:57 <dimon222[m]> i agree, makes sense.
2019-03-19 23:07:58 <dimon222[m]> Worth to mention that I just tried to put it to auto, but it created only 2 workers for me. However, i'm able to manually specify -n 4 and even -n 100
2019-03-19 23:08:07 <clandmeter> one you move 1 python pkg to main, in a few version bumps all of them need to be moved due to added deps.
2019-03-19 23:08:14 <clandmeter> s/one/ones
2019-03-19 23:08:14 <alpine-meetbot> clandmeter meant to say: ones you move 1 python pkg to main, in a few version bumps all of them need to be moved due to added deps.
2019-03-19 23:08:26 <clandmeter> its late and i have a new keyboard...
2019-03-19 23:08:35 <SpaceToast> ooh~ whatcha get clandmeter? :)
2019-03-19 23:08:49 <clandmeter> mionix
2019-03-19 23:09:07 <clandmeter> was on offer, so i couldnt resist :)
2019-03-19 23:09:23 <clandmeter> i think keyboards are starting to be some kind of addiction...
2019-03-19 23:09:44 <SpaceToast> looks kind of like the corsair basic stuff, still reds, but less bumps
2019-03-19 23:09:47 <SpaceToast> not bad :D
2019-03-19 23:09:51 <clandmeter> but this is way offtopic :)
2019-03-19 23:10:20 <SpaceToast> yeah, sorry, caffeine addiction - anyway re: main; main is meant to be kind of self-contained
2019-03-19 23:10:32 <SpaceToast> like "I can throw just main on some router and have it work"
2019-03-19 23:10:38 <SpaceToast> there's no shame to being in community :)
2019-03-19 23:11:30 <clandmeter> its one of those things that needs to be proper documented.
2019-03-19 23:11:40 <dimon222[m]> well yeah, but its one of this catastrophic cases... tests already take 1 hour right now for py-sqlalchemy
2019-03-19 23:11:50 <SpaceToast> I just generally got the idea from how it's approached
2019-03-19 23:11:52 <dimon222[m]> i dont even know how current version was built if tests take that long
2019-03-19 23:11:59 <SpaceToast> clandmeter: perhaps we should move main into a separate git repo?
2019-03-19 23:12:09 <SpaceToast> this'll make handling the differing teams easier as well
2019-03-19 23:12:58 <clandmeter> i think main and testing are bad names.
2019-03-19 23:13:14 <clandmeter> we should talk about it ones. maybe not now :)
2019-03-19 23:13:26 <SpaceToast> that's fair ^^
2019-03-19 23:13:35 <clandmeter> dimon222[m]: i build it yesterday, it didnt take 1 hour
2019-03-19 23:13:40 <clandmeter> but it took long yes
2019-03-19 23:14:04 <clandmeter> the sqlite test specifically
2019-03-19 23:14:21 <dimon222[m]> i tried to build with -n 100, many workers were just failing yep, reuse of JOBS make sense
2019-03-19 23:14:50 <clandmeter> so we have two options here, a simple one like you requested, or a hard one to figure out if we can move it to community.
2019-03-19 23:14:56 <dimon222[m]> but imho test and everything related honestly better be part of main, its something that we probably should be making discount on... musl afterall
2019-03-19 23:15:08 <dimon222[m]> *shouldn't
2019-03-19 23:15:27 <clandmeter> ?
2019-03-19 23:15:39 <clandmeter> test should be part of main?
2019-03-19 23:16:03 <dimon222[m]> pytest plugins
2019-03-19 23:16:55 <dimon222[m]> moving sqlalchemy from main to community doesn't make sense, but moving pytest-xdist to main - maybe, but as u mentioned, if its not preferred option...
2019-03-19 23:17:56 <dimon222[m]> what are prereqs to make possible move from community to main?
2019-03-19 23:17:57 <dimon222[m]> i'm the maintainer/contributor of that specific package currently
2019-03-19 23:18:33 <SpaceToast> if we have significant python packages in main/ it might make sense to add their testdepends to main/
2019-03-19 23:18:38 <clandmeter> you need to support it for the entire support cycle
2019-03-19 23:18:42 <SpaceToast> but do things in main/ depend on sqlalchemy?
2019-03-19 23:18:56 <SpaceToast> my understanding is it's a large ORM, don't know if it really has to be in main/
2019-03-19 23:19:36 <clandmeter> well i guess we can never remove all py from main
2019-03-19 23:19:49 <clandmeter> and pytest is pretty std test suite right?
2019-03-19 23:20:14 <dimon222[m]> hm, i just checked, actually nothing in main seem to be referring to py-sqlalchemy. Something from community and something from testing
2019-03-19 23:20:15 <dimon222[m]> https://pkgs.alpinelinux.org/package/edge/main/armhf/py-sqlalchemy
2019-03-19 23:20:47 <SpaceToast> yeah, pytest is the main test suite, but it's still third party
2019-03-19 23:21:16 <dimon222[m]> yep, tho, one of the most actively used. If we want to encourage tests, they have to be runnable :D
2019-03-19 23:21:50 <clandmeter> looks like nothing in main depends on pytest
2019-03-19 23:22:01 <SpaceToast> I think any pytest plugins that need to be used in main/ should be moved to it on a need-by-need basis, but nothing but sqlalchemy seems to fit that
2019-03-19 23:22:09 <SpaceToast> and sqlalchemy itself might not need to be in main/
2019-03-19 23:22:39 <clandmeter> so the question is, why is it in main after all
2019-03-19 23:22:41 <dimon222[m]> ye after checking tree, i guess i'm closer to agreeing about this
2019-03-19 23:24:05 <dimon222[m]> https://github.com/alpinelinux/aports/commit/edf2ae4e43f54c657a32156b0f92faca217107b0
2019-03-19 23:24:05 <dimon222[m]> i felt like there was some specific reason mentioned for that, but forgot
2019-03-19 23:24:33 <SpaceToast> dimon222[m]: I'd take a look at the ML
2019-03-19 23:24:37 <SpaceToast> or ping ddevault
2019-03-19 23:24:56 <SpaceToast> if there's a specific reason, the one making the change should know what it was, right? :)
2019-03-19 23:25:03 <ddevault> I brought it in for py-factory-boy
2019-03-19 23:25:21 <ddevault> checkdepends
2019-03-19 23:25:38 <ddevault> py-factory-boy was already in main but was missing check()
2019-03-19 23:25:46 <ddevault> I'm open to moving the whole gang out to community
2019-03-19 23:26:03 <dimon222[m]> oh its not hard dependency, its the test dependency wow
2019-03-19 23:26:28 <dimon222[m]> not visible by alpine dep tree through UI
2019-03-19 23:26:28 <ddevault> I'm generally in favor of shrinking main wherever possible
2019-03-19 23:26:29 <dimon222[m]> https://pkgs.alpinelinux.org/
2019-03-19 23:26:49 <ddevault> the only thing in main which depends on py-factory-boy is py-django-oscar, which is not depended on by anything else in main
2019-03-19 23:27:11 <clandmeter> +1 for moving py to community
2019-03-19 23:27:31 <clandmeter> dimon222[m]: can you add it to your pr and see if it builds?
2019-03-19 23:27:48 <dimon222[m]> @clan
2019-03-19 23:28:12 <clandmeter> is that  some matix magic?
2019-03-19 23:28:30 <SpaceToast> +1
2019-03-19 23:28:49 <ddevault> matrix: making IRC worse since 2014
2019-03-19 23:29:03 <dimon222[m]> yep i keep forgetting Riot is expecting Ctrl+Enter instead of Enter key for newlines.
2019-03-19 23:29:04 <dimon222[m]> do u mean move py-sqlalchemy back to community?
2019-03-19 23:29:15 <ddevault> aye, along with the things in main that depend on it
2019-03-19 23:29:20 <dimon222[m]> i probably shouldn't do that, since i will break builds for py-factory-boy now
2019-03-19 23:29:25 <clandmeter> matrix, if latency is your favorite waste of time.
2019-03-19 23:31:12 <dimon222[m]> i'll try move it back to community, lets see
2019-03-19 23:33:26 <clandmeter> dimon222[m]: thanks!
2019-03-19 23:36:18 <dimon222[m]> actually nonsense, py-sqlalchemy is in two places
2019-03-19 23:37:26 <dimon222[m]> nvm, getting tired prolly
2019-03-19 23:50:09 <dimon222[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/MBSDBDiQKDLGAPKzQmVPcinu >

2019-03-20 00:39:03 <andypost[m]> Then maybe drop py2 right after move?
2019-03-20 00:52:39 <dimon222[m]> idk, is it worth it? maybe better drop py2 all at once when time comes?
2019-03-20 00:53:18 <dimon222[m]> actually i'm not sure about plan, basically most of metapackages for python become absolete once it comes. Correct?
2019-03-20 06:51:09 <ncopa> morning
2019-03-20 06:51:42 <ncopa> SpaceToast: I havent maintained pingu in a while. I guess it can be considered abandoned
2019-03-20 07:17:02 <ollieparanoid[m]> good morning ncopa
2019-03-20 07:18:22 <ollieparanoid[m]> I know there's a lot going on in Alpine right now, but it would be great if you could take another look at the relgroups script again. is it fine to not parse each APKBUILD? https://lists.alpinelinux.org/alpine-devel/6501.html
2019-03-20 07:18:42 <ollieparanoid[m]> clandmeter: also there was a question for the infra team at the end of this thread: https://lists.alpinelinux.org/alpine-devel/6487.html
2019-03-20 07:19:09 <ncopa> ollieparanoid[m]: thanks for the ping. I appreciate
2019-03-20 07:19:35 <ollieparanoid[m]> yw :)
2019-03-20 07:21:38 <ncopa> so
2019-03-20 07:22:10 <ncopa> my general feeling is: if it works, then lets use it and improve it as we go
2019-03-20 07:23:13 <ncopa> i think we could have implemented it with lua-aports in lua
2019-03-20 07:23:53 <ncopa> but then I would probably have to do it, and I cannot rewrite evertying the way i prefer :)
2019-03-20 07:25:03 <ollieparanoid[m]> sounds good :)
2019-03-20 07:25:44 <ollieparanoid[m]> so the next step is copying/forking to github.com/alpinelinux, and then I can make a PR to aports.git to actually use it
2019-03-20 07:26:19 <ollieparanoid[m]> (creating as new repository without the fork button would be slightly better, because then it shows up in the github search, if anybody cares about that)
2019-03-20 07:26:55 <ncopa> i should also respond to the email, for the record
2019-03-20 07:27:15 <ollieparanoid[m]> right
2019-03-20 07:29:37 <ncopa> im gonna have breakfast now and then i need to go out for a while. feel free to ping me later today in case i forget follow up
2019-03-20 07:30:11 <ollieparanoid[m]> later I'll be at work (dayjob), but I can ping you tomorrow if necessary
2019-03-20 10:39:11 <PureTryOut[m]> Could somebody review https://github.com/alpinelinux/aports/pull/5362?
2019-03-20 11:35:27 <_ikke_> PureTryOut[m]: looking
2019-03-20 11:37:20 <PureTryOut[m]> Thanks!
2019-03-20 11:43:10 <_ikke_> PureTryOut[m]: Because openrct2 is not yet added, would it make sense to squash the 2 commits together?
2019-03-20 11:43:28 <PureTryOut[m]> Yeah that
2019-03-20 11:43:31 <PureTryOut[m]> *that's fine with me
2019-03-20 11:43:34 <_ikke_> ok\
2019-03-20 11:50:33 <_ikke_> PureTryOut[m]: Pushed
2019-03-20 11:50:47 <PureTryOut[m]> Awesome thanks!
2019-03-20 12:29:14 <SpaceToast> ncopa: ack - perhaps archive it over on github? (to avoid further confusion)
2019-03-20 12:44:26 <ncopa> SpaceToast: good idea
2019-03-20 13:11:12 <tmhoang> https://blog.overops.com/my-alpine-desktop-setting-up-a-software-development-environment-on-alpine-linux/
2019-03-20 13:17:09 <mps> tmhoang: interesting and nice written except for hardened kernel
2019-03-20 13:17:59 <tmhoang> seems to be on hackernews
2019-03-20 13:20:21 <danieli> i'm not seeing it there
2019-03-20 13:22:40 <tmhoang> page 2
2019-03-20 13:22:45 <tmhoang> #3x
2019-03-20 13:22:54 <tmhoang> ycombinator to be axact
2019-03-20 13:23:00 <danieli> aah yeah
2019-03-20 13:23:19 <danieli> i tried looking at /from?site=blog.overops.com but it only goes by the root domain (overops.com)
2019-03-20 13:39:17 <tmhoang> i heard somebody mentions java 11/12/13 has support for Alpine/musl
2019-03-20 13:48:23 <tmhoang> portola openjdk it seems \
2019-03-20 16:07:44 <mps> _ikke_: when you find some free time, I'm not in hurry, so easy :) updated iwd patch  https://patchwork.alpinelinux.org/patch/4642/ tried it on two different edge box
2019-03-20 16:16:24 <aragon> Does anyone know that the RPi release of 3.9.2 is broken?
2019-03-20 16:17:48 <mps> aragon: it depends what you mean by 'broken'
2019-03-20 16:18:28 <mps> there are people who installed it successfully
2019-03-20 16:19:19 <aragon> mps: I've only tried on a Pi3, but it's definitely broken there. I think it will work on pi0 and pi1.
2019-03-20 16:21:14 <aragon> Looks like there was a change after 3.9.0 where there were different kernel images for different hardware variants, and config.txt had different kernel images+initramfs for rpi0/rpi1 vs. rpi2/rpi3. Now 3.9.2 only seems to have config and images for rpi0/rpi1.
2019-03-20 16:22:46 <SpaceToast> rpi3 should be in the aarch64 image anyway, shouldn't it?
2019-03-20 16:23:01 <mps> right
2019-03-20 16:24:08 <mps> aarch64 version is intended for RPi3
2019-03-20 16:26:00 <aragon> I'm going to test that quick
2019-03-20 16:33:24 <aragon> Yes, 3.9.2's aarch64 release works on rpi3.
2019-03-20 16:34:23 <aragon> So armhf on Pi3 is no more for future releases?
2019-03-20 16:35:19 <mps> armhf is for first RPi, don't know how it is called
2019-03-20 16:35:33 <mps> armv7 is for RPi2
2019-03-20 16:36:09 <mps> difference are in Hard Float
2019-03-20 16:36:30 <mps> and aarc64 is 64-bit of course
2019-03-20 16:37:40 <_ikke_> mps: weird, still the same issue
2019-03-20 16:38:22 <mps> _ikke_: huh, could you tpaste build log, please
2019-03-20 16:38:27 <_ikke_> sure
2019-03-20 16:38:32 <aragon> I thought armhf was hard float for all hardware versions, and armv7 soft float for all hardware versions.
2019-03-20 16:39:19 <_ikke_> http://tpaste.us/DLwq
2019-03-20 16:39:58 <bratkartoffel> @tmhoang: yes, I'm currently working on it
2019-03-20 16:40:33 <bratkartoffel> btw, can anyone please review and merge this one? https://github.com/alpinelinux/aports/pull/6500
2019-03-20 16:41:49 <mps> _ikke_: in last few lines abuild doesn't remove asciidoc pkg alhough it say at the top that it installing it
2019-03-20 16:42:39 <mps> and in configure lines says 'checking for a2x... no'
2019-03-20 16:43:17 <mps> somehow it didn't installed asciidoc on you builder
2019-03-20 16:43:47 <_ikke_> let me try again
2019-03-20 16:46:58 <_ikke_> ok, now it succeeds
2019-03-20 16:47:07 <_ikke_> Not sure why it didn't install asciidoc
2019-03-20 16:47:12 <_ikke_> before
2019-03-20 16:48:02 <mps> sometimes we all meet some quirks, that's a life of software developers :)
2019-03-20 16:48:14 <_ikke_> :)
2019-03-20 16:48:17 <_ikke_> Pushed it
2019-03-20 16:48:19 <mps> nice that it works, and thanks again
2019-03-20 16:49:50 <mps> now I can announce that iwd is ready for testing on Alpine edge, and if rebuilt also on stable :)
2019-03-20 17:11:15 <mps> huh, networkmanager build depends on 213 packages
2019-03-20 18:20:21 <_ikke_> can someone open pr5897?
2019-03-20 18:29:12 <_ikke_> Any feedback on https://github.com/alpinelinux/aports/pull/6765#issuecomment-474863180?
2019-03-20 18:41:35 <danieli> i had a patch for polybar a while back but it was flawed
2019-03-20 18:41:57 <danieli> oh, ncopa is having a look
2019-03-20 18:42:30 <ncopa> no, i just reopened it
2019-03-20 18:42:38 <_ikke_> I'm looking at it :-)
2019-03-20 18:43:20 <_ikke_> danieli: because you apparently have experience with it, do you see anything wrong with that APKBUILD?
2019-03-20 18:49:22 <danieli> _ikke_: I unfortunately won't be able to do a simple functional test but I can have a quick look
2019-03-20 18:49:37 <_ikke_> yeah, just that
2019-03-20 18:49:55 <danieli> hm. I'm getting some readline issues on my build box because of my py 3.7 build, I'll have to remove it
2019-03-20 18:50:21 <_ikke_> yeah, me too
2019-03-20 18:50:28 <danieli> and it's building
2019-03-20 18:50:50 <danieli> looks like that will build polybar with *nearly* all X extensions
2019-03-20 18:50:58 <danieli> not xcb-{render,damage,sync}
2019-03-20 18:51:51 <_ikke_> is that bad?
2019-03-20 18:52:24 <danieli> not really, it just dictates which features will be available to users
2019-03-20 18:52:30 <danieli> looks fine to me
2019-03-20 18:52:32 <_ikke_> ok
2019-03-20 18:52:45 <_ikke_> thanks
2019-03-20 18:55:06 <_ikke_> It's nowhere documented, but it has come up in this channel. Do we have it somewhere documented whether ./program -v would be acceptable as a check() {}?
2019-03-20 18:56:20 <danieli> preferably not but I'd say it's better than nothing if it has no test suite?
2019-03-20 18:57:31 <_ikke_> Some people have a stronger opinion on that
2019-03-20 18:59:15 <danieli> I would expect nothing less
2019-03-20 19:03:16 <_ikke_> But would be nice if we had that officially documented then
2019-03-20 19:03:22 <_ikke_> So that we can point people to it
2019-03-20 19:47:19 <andypost[m]> Needs bsckport https://github.com/alpinelinux/aports/pull/6780
2019-03-20 21:45:31 <fcolista> eheh, going through some entries in b.a.o, there are requests for glibc :)
2019-03-20 21:46:21 <SpaceToast> that's fun
2019-03-20 21:46:32 <SpaceToast> would they also like ntoskrnl.exe while they're at it? :D
2019-03-20 21:47:07 <clandmeter> newapkbuild https://ftp.gnu.org/gnu/libc/glibc-2.29.tar.gz
2019-03-20 21:47:13 <fcolista> rotfl
2019-03-20 21:47:16 <fcolista> btw
2019-03-20 21:47:23 <danieli> lol glibc
2019-03-20 21:47:24 <fcolista> this remember me something about minigw
2019-03-20 21:48:19 <fcolista> ..umh..
2019-03-20 21:48:55 <danieli> MinGW?
2019-03-20 21:49:13 <SpaceToast> cross-compiling environment for windows
2019-03-20 21:49:19 <SpaceToast> (and foss windows sdk)
2019-03-20 21:49:21 <fcolista> yes
2019-03-20 21:49:39 <danieli> yes, I know what it is, was wondering if that's what he meant
2019-03-20 21:49:39 <fcolista> I remember I've filled several years ago about this (needed for openvas-smb)
2019-03-20 21:49:54 <fcolista> SpaceToast, danieli : right
2019-03-20 21:50:07 <fcolista> aha
2019-03-20 21:50:08 <fcolista> https://bugs.alpinelinux.org/issues/5011
2019-03-20 21:50:10 <fcolista> figured
2019-03-20 21:51:03 <SpaceToast> "we'll sponsor it!" - someone that does not represent their company...
2019-03-20 21:51:03 <fcolista> is the only part missing for openvas :-/
2019-03-20 21:51:09 <SpaceToast> did I read that correctly?
2019-03-20 21:51:18 <fcolista> re: discotroy?
2019-03-20 21:51:24 <SpaceToast> yeah
2019-03-20 21:51:28 <fcolista> yup
2019-03-20 21:51:35 <SpaceToast> I'd imagine that if they were indeed going to sponsor it it'd be done by now :/
2019-03-20 21:51:38 <fcolista> but I haven't seen he around
2019-03-20 21:51:43 <fcolista> *hime
2019-03-20 21:51:50 <fcolista> SpaceToast, yeah :)
2019-03-20 21:52:04 <fcolista> still, i think it would be a nice feature to have
2019-03-20 21:52:06 <SpaceToast> I'd promise I'd take a look, but the reality is that I probably won't ^^;;
2019-03-20 21:52:13 <fcolista> :)
2019-03-20 21:52:18 <fcolista> no worries
2019-03-20 21:52:37 <SpaceToast> (I gave up on cross compiling between nt and linux a long time ago, I had a very weird custom set up on gentoo once, and that was a huge pain)
2019-03-20 21:52:50 <fcolista> yeah, I bet it.
2019-03-20 21:52:57 <SpaceToast> my recommendation nowadays is to write in explicitly crossy languages
2019-03-20 21:53:09 <SpaceToast> (D if you want it closer to C, but better yet python, lua, and so on)
2019-03-20 21:53:23 <fcolista> hehe... I've had already a discussion (on another topic) with openvas devs
2019-03-20 21:55:10 <fcolista> https://github.com/greenbone/gvm-libs/issues/197
2019-03-20 21:55:47 <fcolista> nice to see several maintainers from different distro supporting what I said to them a while ago:
2019-03-20 21:55:48 <fcolista> https://github.com/greenbone/gvm-libs/issues/189
2019-03-20 21:57:00 <fcolista> gentoo, arch, debian and kali..
2019-03-20 22:00:50 <SpaceToast> looks like the issue is just that they decided to change the name before they changed the version (and didn't change all the names)
2019-03-20 22:01:41 <fcolista> SpaceToast, not only this
2019-03-20 22:01:51 <fcolista> they also break the ABI from 9.0.0 to 1.0.0
2019-03-20 22:01:54 <fcolista> rather than 10.0.0
2019-03-20 22:02:19 <SpaceToast> well if they changed the version and name at the same time, that'd be fine :)
2019-03-20 22:02:48 <fcolista> if they would have gone to 10.0.0 yes
2019-03-20 22:03:06 <fcolista> for ABI and version
2019-03-20 22:03:18 <SpaceToast> if we treated gvm as a new package in 1.0.0 it'd be fine too, I think
2019-03-20 22:03:21 <fcolista> otherwise apk sees this as downgrade
2019-03-20 22:03:22 <fcolista> no
2019-03-20 22:03:37 <SpaceToast> it can't be a downgrade if it's an entirely new package
2019-03-20 22:04:02 <fcolista> if they would have done a new package, yes
2019-03-20 22:04:09 <SpaceToast> which is exactly what I said :)
2019-03-20 22:04:10 <fcolista> that's what i asked
2019-03-20 22:04:23 <fcolista> "SpaceToast> if we treated gvm as a new package"
2019-03-20 22:04:24 <fcolista> right
2019-03-20 22:04:27 <fcolista> :)
2019-03-20 22:04:52 <SpaceToast> the issue is that they announced the name change before the version reset
2019-03-20 22:04:59 <SpaceToast> so everyone (us included) just renamed the apkbuild
2019-03-20 22:05:12 <SpaceToast> and that's where the problem appeared
2019-03-20 22:05:20 <fcolista> which, in turn, is not consistent neither with the version that popped up as next version
2019-03-20 22:05:32 <fcolista> 10.0.0 :)
2019-03-20 22:05:43 <fcolista> that lead to confusion
2019-03-20 22:07:02 <fcolista> ok, ttl
2019-03-20 22:07:06 <fcolista> c u 2moro
2019-03-20 22:07:08 <fcolista> n8
2019-03-20 22:30:05 <aragon> 3.9.2 also seems to be missing support for wlan on Pi 3B+. Works fine on older Pi 3B.
2019-03-20 22:36:35 <aragon> 
ACTION wonders if replacing kernels and firmware from rpi's repo will break alpine

2019-03-20 22:58:43 <aragon> That would be a yes. :(
2019-03-21 01:41:35 <dimon222[m]> sudo move main/py-sqlalchemy community/py-sqlalchemy :(
2019-03-21 01:41:38 <dimon222[m]> https://github.com/alpinelinux/aports/pull/6030
2019-03-21 07:17:14 <ollieparanoid[m]> good morning!
2019-03-21 07:17:23 <ollieparanoid[m]> ncopa: here's your ping ;) thanks!
2019-03-21 10:22:09 <tmhoang> ncopa: any objection ? https://github.com/alpinelinux/aports/pull/6666. I have an incoming pr to upgrade to 2.8.0 which bases on this one.
2019-03-21 10:35:57 <clandmeter> ddevault: i moved those py modules to community
2019-03-21 10:36:09 <clandmeter> so your patches to them are out of date.
2019-03-21 10:40:07 <clandmeter> dimon222[m]: merged.
2019-03-21 10:45:21 <ncopa> tmhoang: i have no clue on s390x so im ok to just merge those
2019-03-21 10:45:29 <ncopa> i have lots of other stuff in the queue here though
2019-03-21 11:35:33 <tmhoang> ncopa: sure, I'll take care of this s390-tools, and fix any bug report with it. And yes please merge when you have a minute. thanks
2019-03-21 12:35:24 <xsteadfastx> are autoconf and automake needed as makedepends in a APKBUILD?
2019-03-21 12:36:55 <ncopa> xsteadfastx: only if you run autoreconf
2019-03-21 12:37:03 <xsteadfastx> ok true then :)
2019-03-21 12:37:11 <ncopa> you will normally need libtool too
2019-03-21 12:38:27 <xsteadfastx> ncopa: but i could build it with just this both in makedepends... should i add libtool too?
2019-03-21 12:39:59 <ncopa> depends i guess
2019-03-21 12:40:15 <xsteadfastx> its for this: https://github.com/alpinelinux/aports/pull/6782
2019-03-21 12:40:17 <ncopa> i think you often need libtool, but not sure if you always need it
2019-03-21 12:40:51 <xsteadfastx> oh no... some paste errors
2019-03-21 12:42:11 <ncopa> looks like libtool is not needed. it builds on droid.io
2019-03-21 12:42:18 <ncopa> driodCI
2019-03-21 12:43:19 <xsteadfastx> fixed the typos
2019-03-21 12:43:57 <xsteadfastx> i put alpine on my old netbook today and tried to get my i3 setup from debian up and running... and some packages are missing... so i take this project to add the alpine
2019-03-21 12:46:24 <ncopa> nice
2019-03-21 17:25:16 <otlabs> hi ppl
2019-03-21 17:55:43 <ddevault> <clandmeter:#alpine-devel> ddevault: i moved those py modules to community
2019-03-21 17:55:45 <ddevault> thanks clandmeter
2019-03-21 21:27:33 <KH405> Is there any plan to return on a hardened kernel in the future?
2019-03-21 21:29:33 <_ikke_> KH405: No short-term concrete plans
2019-03-21 21:29:54 <KH405> damn it, thanks for the fast answer!
2019-03-21 21:30:45 <SpaceToast> KH405: the issue is that most hardening techniques are either hard to get (e.g grsec is paid now), or are already in the vanilla kernel
2019-03-21 21:31:19 <KH405> Yeah, I understand that, but the main point I merge to alpine was for the kernel ^^'
2019-03-21 21:31:21 <_ikke_> (the latter I would not consider an issue)
2019-03-21 21:31:48 <KH405> Obviously not ^^
2019-03-21 21:31:51 <SpaceToast> the latter is a good thing, but makes the concept of a "hardened kernel" moot
2019-03-21 21:31:59 <SpaceToast> (which is an issue when you talk about hardened kernels :) )
2019-03-21 21:52:58 <otlabs> _ikke_: Hi! Just a friendly reminder - have you got an extra thought about management of package dependencies for go-ipfs?
2019-03-21 21:53:21 <_ikke_> I'll have a look at it tomorrow
2019-03-21 21:53:35 <_ikke_> I have a tiny bit more insight in how it works
2019-03-21 21:55:14 <otlabs> thank you
2019-03-21 22:35:19 <otlabs> Could you please take a loot at https://github.com/alpinelinux/aports/pull/6794 What is wrong with it? I have no problem compile it locally.
2019-03-21 23:19:57 <danieli> otlabs: looks like it doesn't like `make gumbo_test`
2019-03-22 00:00:25 <KH405> Anyone knows why zfs kernel module dosen't load on  boot?
2019-03-22 00:04:10 <mps> KH405: probably not added to /etc/mkinitfs/mkinitfs.conf
2019-03-22 00:05:14 <KH405> I just add zfs between the quotes ?
2019-03-22 00:05:48 <mps> did you run mkinitfs after that
2019-03-22 00:06:02 <KH405> No!
2019-03-22 00:06:26 <mps> you have to run it as root and reboot
2019-03-22 00:06:32 <KH405> That was probably what I was missing, thank you@!
2019-03-22 00:09:07 <KH405> There is so many small twerks to learn when learning linux ^^'
2019-03-22 00:15:57 <mps> learning is invented for us to not have free time to think :)
2019-03-22 00:20:28 <KH405> Also could you help me with a simple command?
2019-03-22 00:20:42 <KH405> I'm trying to do passwd -d and it dosen't work, what gives ?
2019-03-22 00:22:49 <mps> is it busybox applet or from shadow apk
2019-03-22 00:24:09 <mps> anyway it must be run as root, afaik
2019-03-22 00:41:13 <KH405> busybox
2019-03-22 00:41:31 <KH405> And even as root i get the error like it wasn't use properly
2019-03-22 01:19:37 <KH405> Any other idea ?
2019-03-22 01:24:14 <dimon222[m]> clandmeter: thanks for moving
2019-03-22 01:24:59 <dimon222[m]> andypost: anything left for py-certifi ? i added myself as maintainer
2019-03-22 01:25:00 <dimon222[m]> https://github.com/alpinelinux/aports/pull/6727
2019-03-22 01:25:53 <dimon222[m]> prolly py-requests might be ready as well
2019-03-22 01:40:07 <mps> KH405: could you show you how you use it 'passwd -d username' or just 'passwd -d'
2019-03-22 02:24:37 <KH405> Both
2019-03-22 02:24:40 <KH405> And both dosen't work
2019-03-22 02:25:11 <KH405> passwd -d is suppose to default to the user you ran the command with anyway no ?
2019-03-22 02:33:28 <mps> KH405: no, for that option (-d) you have to specify username
2019-03-22 02:33:45 <mps> and can only be run as root
2019-03-22 02:44:53 <KH405> Ohh, you're right
2019-03-22 02:45:13 <KH405> I've got a password on a container and I can't put the same password on a different container now ...
2019-03-22 02:45:24 <KH405> It says password too weak
2019-03-22 02:47:26 <KH405> That's so weird
2019-03-22 02:52:15 <mps> it could be configured in /etc/login.defs, iirc
2019-03-22 02:56:33 <mps> option PASS_MIN_LEN, but not sure if it works on Alpine with busybox passwd applet
2019-03-22 09:03:18 <xsteadfastx> i have the problem that the build of my PR fails
2019-03-22 09:03:27 <xsteadfastx> https://travis-ci.org/alpinelinux/aports/builds/509798410?utm_source=github_status&utm_medium=notification
2019-03-22 09:03:29 <xsteadfastx> anyone a idea?
2019-03-22 09:03:44 <xsteadfastx> ./script/get_git_rev.sh . ./gitconfig.h
2019-03-22 09:03:46 <xsteadfastx> env: can't execute 'bash': No such file or directory
2019-03-22 09:04:11 <xsteadfastx> i mean bash? so i should handle it as a makedepends?
2019-03-22 09:07:58 <mps> xsteadfastx: probably, although I think better solution is to fix that script to use ash which is closer to POSIX shell
2019-03-22 09:22:27 <xsteadfastx> mps: as patch?
2019-03-22 09:37:20 <mps> xsteadfastx: I'm not sure, if it simple fix for Alpine then maybe but if it is to intrusive then maybe not
2019-03-22 09:38:16 <mps> by 'fix that script to use ash...' I meant to say that the upstream have to fix it
2019-03-22 09:39:13 <mps> for you it is probably simplest solution is to add bash to makedepends
2019-03-22 09:40:21 <mps> I suspect that the upstream of such package will accept patch for that or consider to rewrite script in POSIX compliant shell
2019-03-22 09:41:45 <xsteadfastx> ok :)
2019-03-22 13:01:04 <andypost[m]> @dimon222 looks ready for me but I'm not closely following py conversion happening
2019-03-22 14:27:20 <otlabs> danieli: ouch, will take a closure look. locally it was compiling fine. thanks.
2019-03-22 14:47:04 <otlabs> I have moved testing/gumbo-parser to separate PR (https://github.com/alpinelinux/aports/pull/6805) and it do not build. Locally I have no problem to build it. I would quite appreciate you someone can take a look why it happens.
2019-03-22 14:49:45 <_ikke_> otlabs: get the same issue in my build enviornment
2019-03-22 14:52:23 <otlabs> _ikke_: hmm. looks like I miss some dependencies.
2019-03-22 14:52:34 <otlabs> _ikke_: thanks for checking
2019-03-22 14:52:38 <_ikke_> np
2019-03-22 15:11:57 <otlabs> i found it! it was a missing dependency for check()!
2019-03-22 15:16:13 <_ikke_> Alright!
2019-03-22 15:16:26 <_ikke_> It helps to keep a clean build enviroment
2019-03-22 15:16:37 <otlabs> yep!
2019-03-22 15:16:50 <_ikke_> A regularly check /etc/apk/world and remove things that I don't need
2019-03-22 15:17:30 <otlabs> great tip, thank you! will make part of my routines!
2019-03-22 15:18:43 <_ikke_> there is also apk rootbld to build in a clean chroot
2019-03-22 15:19:04 <mps> also I started that for some time. 'apk info | grep makedep' and apk del .makedep...
2019-03-22 15:19:11 <_ikke_> yup
2019-03-22 15:19:20 <_ikke_> "(263/263) Purging http-parser (2.9.0-r0"
2019-03-22 15:19:27 <_ikke_> I still had a few .makedeps left
2019-03-22 15:19:53 <_ikke_> You can just remove entries from that file and then run apk fix, and it will automatically remove those + dependencies
2019-03-22 15:20:09 <mps> have to make it a custom before any 'abuild -r'
2019-03-22 15:20:55 <mps> not custom, habit :)
2019-03-22 15:24:54 <otlabs> cool
2019-03-22 15:35:10 <otlabs> effectively, I had gtest in /etc/apk/world
2019-03-22 15:35:20 <_ikke_> right
2019-03-22 15:35:27 <otlabs> so I was missing it in makedeps
2019-03-22 15:35:37 <_ikke_> otlabs: there is also checkdepends for those
2019-03-22 15:43:49 <otlabs> _ikke_: I am not yet familiar with the use of checkdepends, will read the docs
2019-03-22 15:45:46 <otlabs> Yoo-hoo! Now my PR compiles good on Drone for all architectures, Travis complains for 1 failed test!
2019-03-22 15:45:50 <_ikke_> same as makedepends
2019-03-22 15:46:59 <otlabs> Oh, ok. But must be some difference. I will find it ;-)
2019-03-22 15:47:55 <otlabs> I would very appreciate a kind volunteer to take a look at PR (https://github.com/alpinelinux/aports/pull/6794) and comment on it.
2019-03-22 15:48:04 <_ikke_> Yes, I will look at it as soon as I have time
2019-03-22 15:48:35 <otlabs> Thanks a lot _ikke_ !
2019-03-22 18:00:12 <fabled> clandmeter, ncopa : i'm testing now http://sprunge.us/ZCBZA1 and will push if it works. does it look ok to you?
2019-03-22 20:15:48 <_ikke_> andypost[m]: py-zmq is now failing to build on s390x since the tests are enabled
2019-03-22 20:50:44 <mps> do I have to fill issue in bugs.a.o for upgrading pkg for which I prepared patch and ready to send, or just send it to patchwork.a.o
2019-03-22 20:51:50 <_ikke_> just for upgrades it's not necessary to create an issue
2019-03-22 20:54:42 <mps> thanks, in a minute it will be there
2019-03-22 20:58:05 <otlabs> _ikke_: thank you for checking PR and merging it!
2019-03-22 20:58:15 <_ikke_> otlabs: no problem
2019-03-22 20:58:23 <_ikke_> the aports looked good! :)
2019-03-22 20:58:24 <otlabs> eventually would be nice to enable cython3 for it
2019-03-22 20:58:37 <otlabs> _ikke_: thank you!
2019-03-22 20:58:57 <mps> maybe not, looks like patchwork is little stuck
2019-03-22 20:59:06 <_ikke_> mps: let me check
2019-03-22 20:59:31 <mps> eh, it is there
2019-03-22 21:00:01 <mps> five minutes to wait, not much :)
2019-03-22 21:00:11 <_ikke_> ah
2019-03-22 21:01:00 <mps> ok, patch is for awesome WM https://patchwork.alpinelinux.org/patch/4649/
2019-03-22 21:01:21 <_ikke_> heh
2019-03-22 21:01:23 <mps> tested build on x86_64, armv7 and aarch64
2019-03-22 21:01:42 <_ikke_> I'll look at it in a moment
2019-03-22 21:01:53 <mps> and using it 24 hours on x86_64 and aarch64
2019-03-22 21:02:15 <_ikke_> I'm using awesomewm myself (not on alpine though)
2019-03-22 21:02:29 <mps> not needed to hurry, just want it to be in next stable
2019-03-22 21:02:38 <_ikke_> Should not be that hard
2019-03-22 21:02:53 <mps> only pkgver is changed
2019-03-22 21:03:04 <_ikke_> right, those should be trivial
2019-03-22 21:03:47 <mps> I built it on stable also and use it, didn't noticed any issue, even didn't restart X to upgrade it
2019-03-22 21:03:53 <_ikke_> building a cargo package, takes a long time
2019-03-22 21:04:14 <mps> you are looking what I'm doing right now? :)
2019-03-22 21:04:41 <_ikke_> nope :P
2019-03-22 21:05:25 <mps> just finished build, now comes hard part, rootpkg
2019-03-22 21:06:21 <mps> even don't dare to try check ;)
2019-03-22 21:06:43 <_ikke_> ha
2019-03-22 21:06:47 <_ikke_> w00t, finished
2019-03-22 21:06:54 <mps> and this time with llvm7
2019-03-22 21:12:33 <_ikke_> mps: "WARNING: awesome: APKBUILD does not run any tests! "
2019-03-22 21:14:01 <mps> it doesn't had test in previos version also, and I think it doesn't have test at all
2019-03-22 21:14:17 <_ikke_> Right, I'll mark it as such then
2019-03-22 21:15:11 <mps> I though to add option !check but didn't wnated to be intrusive because of the current maintainer
2019-03-22 21:15:39 <_ikke_> I don't think that matter so much
2019-03-22 21:15:40 <mps> s/though/thought/
2019-03-22 21:15:41 <alpine-meetbot> mps meant to say: I thought to add option !check but didn't wnated to be intrusive because of the current maintainer
2019-03-22 21:16:15 <_ikke_> Unless they are substantive changes, I don't think it matters a lot
2019-03-22 21:16:19 <mps> I like to be nice, or pretend that I'm at least
2019-03-22 21:16:36 <andypost[m]> _ikke_:
2019-03-22 21:16:51 <andypost[m]> can't get why test fails zmq/tests/test_proxy_steerable.py
2019-03-22 21:17:16 <andypost[m]> maybe better to disable it for s390x?
2019-03-22 21:17:41 <_ikke_> maybe open a ticket upstream as well?
2019-03-22 21:18:17 <andypost[m]> good idea
2019-03-22 21:21:36 <_ikke_> mps: Pushed awesome, the pw patch can be closed now
2019-03-22 21:22:19 <mps> closed should be done by someone who have rights
2019-03-22 21:22:30 <_ikke_> I don't
2019-03-22 21:22:46 <_ikke_> Need to arrange that still
2019-03-22 21:23:33 <mps> btw, I was wrong awesome have 'make check' but it needs Xephir or Xvfb for this and not shure will such things work on builders
2019-03-22 21:24:09 <_ikke_> Don't think that is going to work
2019-03-22 21:24:32 <mps> so, in next upgrade !check should be added
2019-03-22 21:25:05 <_ikke_> I added it
2019-03-22 21:25:22 <mps> nice :)
2019-03-22 21:25:36 <mps> _ikke_: thank you for help and work
2019-03-22 21:25:42 <_ikke_> no problem
2019-03-22 21:26:43 <mps> 
ACTION looking on #alpine-commits to see will it be built on all arch's

2019-03-23 02:31:41 <KH405> So i rebooted my server and my ZFS pool hasn't mounted correctly even after making a mkinitfs, what gives ?
2019-03-23 07:54:34 <hrio[m]> You have enabled the zfs related rc scripts? Import shall run in level boot, the rest are fine in default.
2019-03-23 09:28:27 <mps> KH405: I cannot talk for zfs but I added f2fs to mkinitfs and it loads modules from the initramfs during boot without issue
2019-03-23 09:30:23 <mps> never tried to use zfs so I cannot tell how it starts but module should be loaded from initramfs, you check by 'lsmod' and see if they are loaded
2019-03-23 10:25:15 <hrio[m]> No need for the zfs module in initramfs if not trying to boot from a zfs rootfs.
2019-03-23 10:28:37 <mps> hrio[m]: right, but KH405 asked previously (two days ago, iirc) asked how to add zfs to initramfs
2019-03-23 12:53:29 <KH405> Sorry, was sleeping, but yeah U added zfs to initramfs and it still is not loading the module on bootup ...
2019-03-23 12:55:27 <KH405> And lsmod has no mention of zfs
2019-03-23 12:56:02 <mps> KH405: ( OT: no problem, I'm awake but feel like I still sleep :) ) If you added it and made new initramfs and it doesn't load modules on boot then somewhere is error which needs to be resolved
2019-03-23 12:56:53 <clandmeter> Add it to kernel cmdline option
2019-03-23 12:57:05 <KH405> how to ?
2019-03-23 12:57:23 <clandmeter> You boot from it?
2019-03-23 12:57:53 <KH405> I'm not sure I understand what you are saying
2019-03-23 12:57:57 <clandmeter> I mean is root on it?
2019-03-23 12:58:03 <KH405> root on what ?
2019-03-23 12:58:07 <clandmeter> On zfs
2019-03-23 12:58:17 <KH405> No
2019-03-23 12:58:46 <clandmeter> Are you starting zfs on boot?
2019-03-23 12:59:13 <KH405> I want to
2019-03-23 12:59:17 <KH405> But it won't
2019-03-23 12:59:42 <KH405> Also what's the difference between /etc/modules and initramfs ?
2019-03-23 13:01:20 <clandmeter> You don't need it
2019-03-23 13:01:31 <clandmeter> What is you hw?
2019-03-23 13:01:38 <clandmeter> Your..
2019-03-23 13:01:56 <clandmeter> Just regular x86?
2019-03-23 13:02:45 <KH405> x64
2019-03-23 13:03:19 <clandmeter> What happens if you start zfs manually?
2019-03-23 13:03:43 <KH405> modprobe zfs?
2019-03-23 13:04:02 <clandmeter> No from init.d
2019-03-23 13:04:21 <clandmeter> It's a service
2019-03-23 13:05:17 <clandmeter> Btw, please move this conversation to #alpine-linux
2019-03-23 13:05:26 <KH405> Will do!
2019-03-23 14:03:36 <Shiz> https://github.com/alpinelinux/aports/pull/6816
2019-03-23 14:03:41 <Shiz> cc ncopa clandmeter  ;p
2019-03-23 14:04:11 <Shiz> specifc problem here triggered by WG config
2019-03-23 14:04:13 <Shiz>  snh : zx2c4: Are you aware of the `warning: the frame size of 1040 bytes is larger than 1024 bytes` warnings being thrown while compiling allowedips.c on Alpine
2019-03-23 14:04:25 <Shiz> s/WG config/WG compilation/
2019-03-23 14:04:25 <alpine-meetbot> Shiz meant to say: specifc problem here triggered by WG compilation
2019-03-23 14:12:13 <xsteadfastx> this is really depressing... added a make check to the rofi package and a test is failing... but no idea why... i use the package for some days without problems
2019-03-23 14:13:03 <xsteadfastx> thats the build: https://cloud.drone.io/alpinelinux/aports/841/1/2
2019-03-23 14:13:51 <xsteadfastx> line 1339 is the test that fails
2019-03-23 14:14:02 <xsteadfastx> but i dont think its a problem of the alpine package...
2019-03-23 14:36:41 <xsteadfastx> i wrote a bugreport on the rofi github: https://github.com/DaveDavenport/rofi/issues/940
2019-03-23 19:14:36 <z3ntu> Any reason `libxml++-2.6-dev` is not available for armv7?
2019-03-23 19:14:51 <_ikke_> probably some build issues?
2019-03-23 19:16:14 <z3ntu> Found https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/libxml%2b%2b-2.6/libxml%2b%2b-2.6-2.40.1-r0.log, some issue with perl apparently
2019-03-23 19:26:54 <z3ntu> fcolista: could you maybe look into that? :)
2019-03-23 19:36:57 <mps> z3ntu: it passes in my lxc container
2019-03-23 19:38:44 <mps> I mean, testing/libxml++-2.6 is built with 'abuild -r' on armv7 edge
2019-03-23 19:43:41 <tcely> _ikke_: please explain your comment on https://github.com/alpinelinux/aports/pull/6554
2019-03-23 19:46:58 <_ikke_> tcely: Hmm, I read a todo in the APKBUILD somewhere
2019-03-23 19:47:13 <_ikke_> Does the project have tests?
2019-03-23 19:47:34 <tcely> Yes, and check uses it.
2019-03-23 19:47:45 <_ikke_> ok
2019-03-23 19:47:55 <_ikke_> Maybe I had an older version?
2019-03-23 19:48:26 <tcely> I really can't figure what you were looking at
2019-03-23 19:49:13 <_ikke_> Maybe I confused it with a different PR
2019-03-23 19:52:30 <andypost[m]> Looks good IMO
2019-03-23 19:58:51 <tcely> Mine too ;-)
2019-03-23 20:41:47 <tcely> Who can help to merge https://github.com/alpinelinux/aports/pull/5950 ?
2019-03-23 20:42:24 <_ikke_> Someone with push rights to main (not me)
2019-03-23 20:44:38 <tcely> Ah, the ever vague "someone" again.
2019-03-23 21:06:01 <_ikke_> yes
2019-03-23 21:08:58 <_ikke_> Most devs mostly working during working hours
2019-03-23 21:14:34 <tcely> Lol. Working hours lacks meaning to a global audience.
2019-03-23 21:14:41 <_ikke_> yes, I know
2019-03-23 21:15:18 <_ikke_> But you know now is not working hours
2019-03-23 21:16:35 <AinNero> its 14:16 in SF
2019-03-23 21:16:58 <AinNero> ah right, saturday
2019-03-23 21:17:44 <tcely> Well, that I might be able to infer and also not you. While not totally useless, the information you have provided doesn't amount to very much.
2019-03-23 21:18:28 <_ikke_> tcely: Because it's not meant to give absolute meaning, just a general idea
2019-03-23 21:18:40 <tcely> Weekend work is not that uncommon for open source when it is not your day job.
2019-03-23 21:19:12 <_ikke_> Like is the case for me
2019-03-23 21:26:22 <tcely> Hmm. That's an interesting musl bug:
2019-03-23 21:26:22 <tcely> https://github.com/alpinelinux/aports/pull/6675#issuecomment-474594182
2019-03-23 21:26:22 <tcely> Is that something we'd patch and back port?
2019-03-23 21:31:18 <clandmeter> i think so
2019-03-23 21:32:33 <clandmeter> fabled ncopa or kaniini should look into it.
2019-03-23 21:33:23 <clandmeter> tcely: im looking at your drone git depth pr
2019-03-23 21:35:12 <clandmeter> _ikke_: did you rebase parso?
2019-03-23 21:35:27 <_ikke_> just about to
2019-03-23 21:35:35 <clandmeter> ok nice
2019-03-23 21:35:49 <clandmeter> should finally build correctly i hope
2019-03-23 21:35:58 <_ikke_> yes, I hope so as well
2019-03-23 21:36:18 <_ikke_> And I need to figure out why vault is failing on x86(_64)
2019-03-23 21:36:39 <clandmeter> that looks like an interesting issue :)
2019-03-23 21:36:50 <clandmeter> good luck with that
2019-03-23 21:37:00 <_ikke_> thanks
2019-03-23 21:38:48 <_ikke_> parso fails on aarch64 and armv7
2019-03-23 21:39:28 <clandmeter> builders not ready
2019-03-23 21:39:31 <_ikke_> right
2019-03-23 21:39:51 <clandmeter> can you restart the build from drone?
2019-03-23 21:40:03 <clandmeter> not sure how that works
2019-03-23 21:40:22 <clandmeter> i guess its github permissions that allow that.
2019-03-23 21:40:25 <_ikke_> There is a restart button, but it's disabled
2019-03-23 21:41:03 <clandmeter> hmm
2019-03-23 21:41:31 <clandmeter> can y ou login to cloud.drone.io?
2019-03-23 21:43:54 <_ikke_> right, now I can
2019-03-23 21:44:55 <tcely> clandmeter: good to know
2019-03-23 21:55:05 <clandmeter> tcely: we can probably fix it with a depth of 1 and apply the github PR patch, so we dont have to merge the feature branch at all.
2019-03-23 23:17:52 <tcely> If you fetch the PR merge instead of the head you can also avoid the merge step.
2019-03-23 23:18:22 <tcely> Are the edge x86 builders stuck?
2019-03-23 23:38:21 <andypost[m]> @tcely yep, on vault https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/vault/vault-1.1.0-r0.log
2019-03-24 00:09:40 <opal> yo is anyone aware of the spam on the bug tracker https://bugs.alpinelinux.org/users/8600
2019-03-24 00:10:04 <opal> i got excited that someone replied to the issue i filed just to see some roblox crap
2019-03-24 03:53:04 <opal> also ncopa: ✔ Proof for alpinelinux.org failed: Checked 1 TXT entries of alpinelinux.org, but didn't find signature keybase-site-verification=7gs17_-4xJ_IFtjFyVcZZsQRPlBQe7yTTzg8OBCVPWs; Checked 0 TXT entries of _keybase.alpinelinux.org, but didn't
2019-03-24 03:53:05 <opal> find signature keybase-site-verification=7gs17_-4xJ_IFtjFyVcZZsQRPlBQe7yTTzg8OBCVPWs (code=201)
2019-03-24 03:54:19 <opal> i've been looking through my gpg keychain for people on keybase, im guessing the txt records for alpinelinux.org got changed since then
2019-03-24 04:07:54 <danieli> I didn't even know keybase was set up for alpinelinux.org?
2019-03-24 04:08:19 <danieli> nor that it was supposed to be
2019-03-24 04:08:26 <danieli> _ikke_: ?
2019-03-24 05:36:58 <_ikke_> No clue
2019-03-24 14:03:50 <andypost[m]> Anyone can restart s390x build bot?
2019-03-24 14:06:58 <_ikke_> I guess clandmeter
2019-03-24 14:19:43 <andypost[m]> I think ee should disable vault to unblock x86 builders
2019-03-24 14:28:44 <clandmeter> Build bot?
2019-03-24 14:40:23 <_ikke_> Builder I guess
2019-03-24 14:58:19 <danieli> yes builder
2019-03-24 15:02:05 <clandmeter> It does not respond to retry?
2019-03-24 15:06:31 <_ikke_> vault failing is frustrating me
2019-03-24 15:58:25 <clandmeter> x86?
2019-03-24 15:59:21 <_ikke_> and 64
2019-03-25 10:11:04 <_ikke_> github is having issues
2019-03-25 10:11:12 <_ikke_> https://www.githubstatus.com/incidents/zzm4nczlpjyy
2019-03-25 11:55:55 <tcely> When do the x86 builders move past vault?
2019-03-25 11:56:09 <_ikke_> tcely: I'm trying to figure out what's wrong with vault
2019-03-25 11:56:20 <_ikke_> If it takes too long, I'll revert the change
2019-03-25 11:56:24 <_ikke_> sorry about that
2019-03-25 12:58:29 <Mo0O> Hi there, I'm using alpine as docker host and trying to run a concourse worker which requiered "privileged" option because it runs docker inside the container, unfortunatly event if `/sys/fs/cgroup` is available inside the container it returns the following error when starting a new job: `docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown.`
2019-03-25 12:58:56 <Mo0O> do you know if it's possible to fix that?
2019-03-25 13:07:11 <AinNero> yes
2019-03-25 14:16:44 <Mo0O> AinNero: realy? how do you do that?
2019-03-25 14:18:40 <AinNero> dont know, but its the docer-in-docker scenario
2019-03-25 14:18:54 <AinNero> which is mostly messing with the kernel interface, so not much specific to alpine
2019-03-25 14:19:21 <SpaceToast> Mo0O: on the host, run `rc-update add cgroups boot`
2019-03-25 14:19:35 <SpaceToast> then `rc-service cgroups start`
2019-03-25 14:19:50 <AinNero> why on the host?
2019-03-25 14:20:00 <SpaceToast> because the host passes down cgroups to the guests
2019-03-25 14:20:10 <SpaceToast> if the host does not have cgroups, the guest will not magically inherit nothingness
2019-03-25 14:20:33 <AinNero> does docker do the mounts itself?
2019-03-25 14:20:38 <AinNero> for the cgroups?
2019-03-25 14:20:45 <SpaceToast> it should, I know lxd does
2019-03-25 14:20:54 <AinNero> i'd claim he already has cgroups set up if he is able to run docker at all
2019-03-25 14:20:57 <SpaceToast> Mo0O: also, consider bind-mounting the docker socket inside your guest
2019-03-25 14:21:05 <SpaceToast> you'd think so ;)
2019-03-25 14:21:41 <Mo0O> SpaceToast: thanks a lot, I try that right now :)
2019-03-25 14:22:29 <AinNero> SpaceToast: grep need /etc/init.d/docker
2019-03-25 14:23:11 <SpaceToast> oh nice, we have a patch adding that now
2019-03-25 14:23:40 <Mo0O> true, cgroups is already in docker's needs
2019-03-25 14:24:03 <Mo0O> hmm, then my issue should be related to something else
2019-03-25 14:24:14 <SpaceToast> have you tried bind-mounting the host's socket inside?
2019-03-25 14:24:24 <SpaceToast> docker-in-docker is pretty buggy, and upstream recommends just reusing the daemon
2019-03-25 14:25:21 <SpaceToast> might also need to mount the cgroups inside, normally that should be done by docker on your host, but it also should happen automatically...
2019-03-25 14:25:51 <Mo0O> I'm trying this right now
2019-03-25 14:28:31 <SpaceToast> Mo0O: based on https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md you need to have "cgroup" inside your OCI container definition
2019-03-25 14:33:54 <Mo0O> hmm, ok I'll find for a way to define that using docker
2019-03-25 15:48:47 <otlabs> hi ppl
2019-03-25 16:08:42 <ncopa> hi
2019-03-25 17:22:14 <andypost[m]> ncopa please fix s390x builder
2019-03-25 17:35:00 <nmeum> ncopa: do you have any opinions on https://github.com/alpinelinux/aports/pull/6711 ? upstream changed the default luks format to luks2 in this version
2019-03-25 18:05:01 <ncopa> will check tomorrow
2019-03-25 18:05:49 <ncopa> andypost[m]: whats wrong with s390x builder?
2019-03-25 18:06:00 <ncopa> is it hang or just not building the package
2019-03-25 18:57:14 <andypost[m]> ncopa it hangs 3rd day
2019-03-25 18:58:28 <kunkku> I'm looking into https://github.com/alpinelinux/abuild/pull/53
2019-03-25 18:59:44 <kunkku> should "abuild deps" install the dependencies from the checked out branch or according to the host's release?
2019-03-25 19:49:12 <_ikke_> This PR fails due to a bug in musl which is fixed in musl master. What should we do with it? https://github.com/alpinelinux/aports/pull/6675
2019-03-25 20:39:43 <clandmeter> _ikke_: ask fabled if musl can be fixed
2019-03-25 20:41:23 <_ikke_> ok
2019-03-25 21:20:57 <HRio> _ikke_: this? http://lists.alpinelinux.org/alpine-aports/6390.html
2019-03-25 21:21:06 <HRio> or something else?
2019-03-25 21:21:44 <HRio> sorry, its unrelated
2019-03-25 21:22:41 <HRio> clandmeter
2019-03-25 21:23:30 <HRio> what do you think about this? https://github.com/alpinelinux/aports/pull/6833, became an issue in 3.9 with linux 4.19
2019-03-25 21:27:26 <mps> HRio: is this related to https://bugs.alpinelinux.org/issues/9960
2019-03-25 21:27:43 <HRio> yes
2019-03-25 21:29:15 <mps> if this happens on machines without good entropy source there is no good solution, only to patch kernel to revert crng changes, imo
2019-03-25 21:29:29 <HRio> haveged works
2019-03-25 21:30:19 <mps> haveged works to some degree, right
2019-03-25 21:30:20 <HRio> that why I add a provides entropy to that package, rng-tools works on amd64 and quite a few arm boards
2019-03-25 21:31:10 <mps> rng-tools help on machines which have hardware random source, rdrand or tpm
2019-03-25 21:31:19 <HRio> yes
2019-03-25 21:32:20 <mps> but on small machines without hardware random source even with haveged there is delays although haveged helps
2019-03-25 21:32:48 <mps> on on my arm box boot lasts more than 10 minutes even with haveged
2019-03-25 21:32:51 <HRio> rng-tools should probably work on VMs with vTPM as well.
2019-03-25 21:34:10 <mps> should be, I even thought to add that on https://bugs.alpinelinux.org/issues/9960 for VM's and to install virtio-rng on them
2019-03-25 21:34:56 <mps> actually I would but don't have good combo of host/guest to test that
2019-03-25 21:35:34 <HRio> virtio-rng is a bit KVM specific?
2019-03-25 21:35:53 <HRio> need to enable it in the KVM host
2019-03-25 21:35:54 <mps> I think it works on xen too
2019-03-25 21:36:22 <mps> but didn't tried, I'm using KVM VM's only
2019-03-25 21:36:39 <HRio> with virtio-rng, you can provide a rate limited RNG from the host
2019-03-25 21:39:46 <mps> rng_core
2019-03-25 21:39:53 <HRio> if you have a OpenGPG/OpenPGP card you can feed the rng pool with scdrand
2019-03-25 21:40:41 <mps> yes, any good hardware source can be 'injected' to give entropy
2019-03-25 21:41:03 <HRio> e.g https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
2019-03-25 21:41:57 <mps> even there are guides on the net how to build with atmel avr or arduinos
2019-03-25 21:42:32 <mps> not only atmel's but other small CPU's
2019-03-25 21:44:04 <HRio> yes, but then you can have that "provide entopy" (via an openRC script) and have bind or what ever start after that.
2019-03-25 21:44:29 <mps> but, without hardware solution could be save randomness from time to time to /var/lib/misc/random-seed and 'populate' /dev/random from it during boot
2019-03-25 21:44:30 <HRio> feels better than "revert crng changes", for all systems
2019-03-25 21:44:50 <HRio> yes if not running from ramfs
2019-03-25 21:45:14 <mps> good point, it was out of my 'radar'
2019-03-25 21:45:37 <HRio> but also the open-rc script for random-seed can "provide entropy"
2019-03-25 21:46:12 <mps> it can, but the question is how good this entropy
2019-03-25 21:46:58 <HRio> if you need entropy, you have to wait or fix a RNG
2019-03-25 21:47:18 <mps> right, that is.
2019-03-25 21:47:42 <mps> risk without good entropy or wait enough for it
2019-03-25 21:48:41 <HRio> yes, if you do not care /dev/urandom -> /dev/random during boot.. or if you do not care at all /dev/zero -> /dev/random, just a few bytes with dd
2019-03-25 21:49:17 <mps> that should be end user decision, imo, and I proposed to add question for user during setup-bootable is run on https://bugs.alpinelinux.org/issues/9960#change-27714
2019-03-25 21:50:31 <HRio> yes but if all user options "provide entropy" and stuff needing entropy declares "after entropy", we should be set, to add more providers later
2019-03-25 21:52:26 <mps> actually I'm don't think that the good entropy is of 'prime importancy' at boot, but that is a field where crypto experts cannot agree
2019-03-25 21:53:01 <HRio> what if ssh-keygen generates host keys?
2019-03-25 21:53:41 <mps> without good entropy source only be patient
2019-03-25 21:54:38 <HRio> yes, but good entropy is important for cases where long lived keys are generated.
2019-03-25 21:54:55 <HRio> patient or HWRNG or a combo
2019-03-25 21:55:33 <mps> HWRNG is solution but only if you trust HWRNG manufacturer
2019-03-25 21:56:11 <mps> and a lot of crypto experts don't trust Intel and some other
2019-03-25 21:57:04 <mps> imo, this all is not much of techical problem but problem of trust
2019-03-25 22:00:02 <mps> for ARM boxes I built kernel with crng patch (one line) and for Intel box I press keyboard randomly and move mouse and it waits about 30 seconds, good enough for me
2019-03-25 22:01:49 <mps> on the cloud provider for VM's virtio-rng is enoguh, 10 seconds pause (speaking from memory)
2019-03-25 22:02:26 <HRio> Ok, I use the rng in rpi3 or in the Sitara I am using, but thats to only ARM i use.
2019-03-25 22:02:42 <mps> if I really need good and trustable source for entropy I will build one
2019-03-25 22:02:46 <HRio> s/to/the/
2019-03-25 22:02:46 <alpine-meetbot> HRio meant to say: Ok, I use the rng in rpi3 or in the Sitara I am using, but thats the only ARM i use.
2019-03-25 22:03:19 <mps> RPi3 have HWRNG, I think. Or I'm wrong
2019-03-25 22:04:11 <mps> I have exynos and rockchip and they boot have HWRNG, but older ARM's (32 bit) don't have it
2019-03-25 22:04:26 <mps> s/boot/both/
2019-03-25 22:04:27 <alpine-meetbot> mps meant to say: I have exynos and rockchip and they both have HWRNG, but older ARM's (32 bit) don't have it
2019-03-25 22:04:54 <HRio> yes RPi3 comes with hwrng "bcm2835-rng 3f104000.rng: hwrng registered"
2019-03-25 22:07:30 <mps> the problem with kernel 4.19 and up is only on low end or old machines without hwrng, on newer is the question of trust
2019-03-25 22:08:23 <mps> VM's is another story, do you trust host (as there are choice ;) ) and how good host in 'giving' entropy to guests
2019-03-25 22:11:02 <HRio> lots of cloud providers give access to rdrand as well, so virtio-rng or vTPM are not the only options.
2019-03-25 22:11:54 <HRio> anyhow, time to sleep.
2019-03-25 22:14:10 <mps> yes, that is for long (neverending) talk. :) good night !
2019-03-25 22:14:26 <HRio> good night ! :-)
2019-03-25 22:58:35 <otlabs> time to go, see you
2019-03-26 12:12:51 <AinNero> andypost[m]: dont mind that PR
2019-03-26 12:13:12 <AinNero> kaniini would have been the one responsible, but they are busy setting up alpine teams
2019-03-26 12:13:38 <_ikke_> fyi, kanini resigned
2019-03-26 12:15:00 <AinNero> oh, interesting
2019-03-26 12:16:30 <AinNero> didn't notice the new ci tho
2019-03-26 12:27:14 <Gottox> do you guys have tried to get autofs work properly on musl?
2019-03-26 13:08:01 <hrio[m]> Gottox I did basic testing before pushing. Only tested direct.
2019-03-26 13:19:24 <Gottox> hmmm... ok it's broken on void. Build works, but it doesn't create mountpoints.
2019-03-26 13:22:13 <hrio[m]> Ok I tested with kerberised monts
2019-03-26 13:46:35 <Gottox> hmm... so it's a void issue. thanks for the info! :)
2019-03-26 13:50:45 <tmhoang> Hi, what is the apk command to force upgrade newest packages being available on repo ?
2019-03-26 13:51:10 <tmhoang> instead of forcing # apk add package=version-release
2019-03-26 13:51:17 <AinNero> what prevents the 'normal' upgrade?
2019-03-26 13:51:42 <tmhoang> I happened to force install / pin to a certain tag.
2019-03-26 13:51:53 <tmhoang> now newer version is out
2019-03-26 13:52:03 <tmhoang> I remembered there is a way because I already did in the past
2019-03-26 13:52:31 <AinNero> personally i would edit /etc/apk/world and remove version tag
2019-03-26 13:52:56 <tmhoang> AinNero: Yes, editing /etc/apk/world. Bingo. Thanks !
2019-03-26 19:04:57 <mps> does it make sense to build irssi with --enable-true-color ? asking because working on upgrade 1.2.0
2019-03-26 19:05:48 <mps> and with OTR, 1.2.0 now have OTR
2019-03-26 20:55:52 <tcely> _ikke_: would you please merge https://github.com/alpinelinux/aports/pull/6553 and https://github.com/alpinelinux/aports/pull/6558 when you have some time?
2019-03-26 21:04:34 <_ikke_> I'll look at it later
2019-03-26 21:26:52 <_ikke_> tcely: ping
2019-03-26 21:46:56 <_ikke_> I squashed commit 2 and 3 together (basically removing the one that added the commend for checkdepends that would get removed again in the next commit (PR6553)
2019-03-26 22:07:00 <tcely> _ikke_: Thanks. I rebased, but until the builders upload the CI won't build knot-resolver
2019-03-26 22:22:42 <tcely> _ikke_: https://github.com/alpinelinux/aports/pull/6558 passed CI now
2019-03-27 00:13:35 <nmeum> if there is any bored GitHub API expert around: it would be really neat to have some sort of github bot which automatically assigns GitHub PRs to the maintainer of the aport the PR changes
2019-03-27 00:23:25 <danieli> that's not a bad idea, assuming that person has a github account
2019-03-27 01:15:07 <tcely> danieli: can you even assign a PR to me if I'm not in alpinelinux org?
2019-03-27 01:15:25 <danieli> tcely: not sure, haven't used github much in some time
2019-03-27 01:16:35 <SpaceToast> that sounds like a great idea
2019-03-27 01:16:46 <danieli> should be possible
2019-03-27 01:17:44 <tcely> We should get alpinelinux going with GitHub Actions that way we don't need to run the bot on external hosts
2019-03-27 01:18:33 <tcely> https://github.com/features/actions
2019-03-27 01:21:48 <SpaceToast> I'm not sure if we want to get locked into github
2019-03-27 01:21:56 <SpaceToast> there's regular talk of moving to gitlab, and similar
2019-03-27 01:22:02 <danieli> indeed
2019-03-27 01:27:41 <tcely> That's a non-concern from my point of view. Nothing on AlpineLinux is actually hosted on GitHub now anyway.
2019-03-27 01:28:09 <SpaceToast> well, your proposal is to change that :)
2019-03-27 01:28:17 <tcely> How?
2019-03-27 01:28:48 <SpaceToast> using github actions means effectively signing that part of the infrastructure up for being locked in
2019-03-27 01:29:02 <SpaceToast> if we have an external CI bot, and we switch, it's a matter of swapping the webhooks
2019-03-27 01:29:12 <SpaceToast> if we set up github actions, and we switch, suddenly all that has to be remade
2019-03-27 01:29:30 <tcely> This isn't a CI bot. It's a GH feature to manage other GH features.
2019-03-27 01:29:58 <SpaceToast> action "Deploy to Production" {;  needs = "Provision Database";  uses = "actions/azure";  runs = "azure deploy" }...
2019-03-27 01:30:13 <SpaceToast> if we wanted X to be assigned to Y based on inputs Z, ideally, we'd like to have a portable way of doing that
2019-03-27 01:30:23 <SpaceToast> as opposed to using something github-specific
2019-03-27 01:30:38 <tcely> You are looking for a portable way to assign GH users to GH PRs?
2019-03-27 01:31:36 <tcely> You are taking an example as my proposal when you shouldn't. We were discussing a bot (hosted externally) to assign PRs to maintainers' GH accounts.
2019-03-27 01:31:39 <SpaceToast> I would look for a portable way to parse a diff, figure out what package it pertains to, and then locate a user (with a pluggable API) that is related to that
2019-03-27 01:31:50 <SpaceToast> then, you would simply need to rewrite the API if we are to switch platforms
2019-03-27 01:32:02 <SpaceToast> (or it could even support multiple APIs from the get-go; e.g gitlab, gitea and github)
2019-03-27 01:32:18 <SpaceToast> interfaces are a beautiful thing, sometimes ;)
2019-03-27 01:32:25 <tcely> If we switch platforms there's no guarantee you'd even have PR as a concept, or part of the API, or even mapped accounts.
2019-03-27 01:32:37 <tcely> This smacks of overengineering in my opinion.
2019-03-27 01:32:39 <SpaceToast> note the abovementioned platforms
2019-03-27 01:32:45 <SpaceToast> gitlab is often discussed,
2019-03-27 01:32:56 <SpaceToast> then we have sr.ht, which is maintained by ddevault (we could always ask for an API of that sort :) )
2019-03-27 01:33:03 <SpaceToast> and finally, gitea is a relatively popular one
2019-03-27 01:33:10 <SpaceToast> (that does indeed have that concept)
2019-03-27 01:33:19 <SpaceToast> other options have basically no traction and thus can be ignored
2019-03-27 01:33:58 <tcely> SpaceToast: I look forward to your framework for handling all of these non-ignored options.
2019-03-27 01:34:22 <SpaceToast> I didn't say "definitely don't do it" or "definitely do that" ¯\_(ツ)_/¯
2019-03-27 01:34:28 <SpaceToast> my specific statement was
2019-03-27 01:34:30 <tcely> Signing up for access to GH Actions and putting together the logic to assign new PRs is something I might tackle. Your suggestion is not.
2019-03-27 01:34:33 <SpaceToast> "I'm not sure if we want to get locked into github"
2019-03-27 01:34:36 <SpaceToast> that still stands
2019-03-27 01:34:45 <SpaceToast> hey, if you wanna tackle it, go for it!
2019-03-27 01:35:23 <SpaceToast> existing "I already did this" is always much preferable to "ideally we should do X" :)
2019-03-27 01:35:39 <SpaceToast> but if we're discussing what SHOULD be done by preference, a solution that does not involve lock-in should be preferred
2019-03-27 01:35:45 <tcely> Nothing about this leads to "locked into github" in my opinion. I don't see why this is a concern anyway, we have the mirror. It could remain even if you switch to GitLab, whatever later.
2019-03-27 01:36:08 <SpaceToast> if we were to switch to gitlab, PRs would likely only go through it from that point on
2019-03-27 01:36:14 <SpaceToast> (otherwise that kind of defeats the point)
2019-03-27 01:36:45 <tcely> The reason we have GH now is that so many contributors are already there. Switching to GL and removing GH will defeat that purpose.
2019-03-27 01:37:18 <SpaceToast> the reason we have GH now, from what I understand, is more because a lot of contributors find using git-send-email a large pain
2019-03-27 01:38:13 <tcely> patchwork is objectively more of a PITA than GH all the way around. I'm for making GH much easier, but it already is a huge win over anything else from my point of view.
2019-03-27 01:39:19 <danieli> gitea isn't an option for us, unfortunately
2019-03-27 01:39:28 <tcely> My main point about this "locked in" concern is that the bridge has already been crossed. Switching away from GH for aports is going to drastically reduce the input from the community.
2019-03-27 01:39:49 <danieli> github is at the moment more or less an interface to access aports at git.a.o
2019-03-27 01:39:56 <SpaceToast> considering we currently can't keep up with the input... :)
2019-03-27 01:40:07 <SpaceToast> though that (hopefully) will change in the relatively near future
2019-03-27 01:40:27 <danieli> hopefully by increasing the amount of developers and reviewers, not reducing the amount of feedback
2019-03-27 01:40:33 <SpaceToast> yes
2019-03-27 01:40:48 <SpaceToast> but basic supply and demand does apply; feedback has undoubtedly already decreased due to insufficient processing
2019-03-27 01:41:06 <danieli> agreed
2019-03-27 01:41:33 <danieli> i'm not sure we're ditching github for gitlab, i can't remember that being decided on - but we do wish to move off cgit+gitolite iirc
2019-03-27 01:41:53 <tcely> Sure. I'm not exactly willing to push my queued PRs past 20. As they clear, I do more work.
2019-03-27 01:41:54 <SpaceToast> we're not; it's one of the things that's been considered as a replacement for cgit+gitolite
2019-03-27 01:44:51 <tcely> Anyway, we could certainly add more bots to help with PRs. I think we should and said as much a while ago. http://lists.alpinelinux.org/alpine-devel/6208.html
2019-03-27 01:45:24 <tcely> I do like the idea of having automatic assignments where possible. I just don't think we should build new external bots when GH will host the logic for us.
2019-03-27 01:48:29 <Adran> whats going to happen to all those orphaned packages?
2019-03-27 01:48:47 <SpaceToast> do you care about any of them?
2019-03-27 01:51:45 <Adran> yes
2019-03-27 01:51:50 <SpaceToast> have you considered taking up maintainership? :)
2019-03-27 01:52:48 <tcely> lol. I knew that was coming.
2019-03-27 01:52:55 <SpaceToast> a very obvious setup, I know.
2019-03-27 01:52:58 <Adran> SpaceToast: i have bad luck with maintaining packages here
2019-03-27 01:53:12 <SpaceToast> is it because your PRs take forever to get merged?
2019-03-27 01:53:14 <Adran> never got my stuff accepted
2019-03-27 01:53:19 <SpaceToast> because we're trying really hard to fix that!
2019-03-27 01:53:21 <SpaceToast> I swear!
2019-03-27 01:53:25 <Adran> i stopped caring
2019-03-27 01:53:26 <Adran> lol
2019-03-27 01:53:29 <SpaceToast> ¯\_(ツ)_/¯
2019-03-27 01:53:37 <SpaceToast> then, surely, you don't care about the packages enough ;)
2019-03-27 01:53:38 <tcely> SpaceToast: I'm waiting for PR from last year.
2019-03-27 01:53:48 <SpaceToast> tcely: a lot of people are
2019-03-27 01:53:49 <Adran> SpaceToast: I meant I stopped caring about the merging lol
2019-03-27 01:54:12 <SpaceToast> the problems that lead to this have mostly been identified, and we're getting close(r?) to accepting a proposal that should set us on the road to fixing that
2019-03-27 01:54:17 <SpaceToast> ... any day now
2019-03-27 01:54:37 <SpaceToast> therefore, hopefully, the situation improves and the above situation/question comes up less (and less over time)
2019-03-27 01:59:04 <Adran> SpaceToast: once the pr stuff is fixed i migth be more willing to help out haha
2019-03-27 01:59:20 <tcely> Ugh. I just realized the CI is useless for testing this boost upgrade. When I bump aports that are building against boost it's using the old version. That's not a useful test.
2019-03-27 01:59:20 <SpaceToast> :)
2019-03-27 02:01:37 <tcely> What is the purpose of this hierarchy of repositories anyway? It just seems to cause problems from what I can see.
2019-03-27 02:02:34 <SpaceToast> main is supported for 2 years
2019-03-27 02:02:43 <SpaceToast> community is still in releases, but only supported for one release (6 months)
2019-03-27 02:02:47 <SpaceToast> testing is "anything goes"
2019-03-27 02:03:10 <SpaceToast> the idea is to minimize potential impact of mistakes - if someone does an oops and something has to be maintained for 2 years, that's a big problem - sometimes people come and go
2019-03-27 02:03:22 <SpaceToast> if someone does an oops and something has to be maintained for half a year, it's more manageable
2019-03-27 02:03:25 <SpaceToast> and testing/ is ... testing/
2019-03-27 02:04:36 <tcely> Ok. That all sounds reasonable. The current problem is when community/testing doesn't use aports built in main. Another problem is that I have to move things to main in order to use them as depends in other main aports.
2019-03-27 02:04:59 <SpaceToast> that's intentional, yes
2019-03-27 02:05:09 <SpaceToast> always consider - might it make sense to go the other direction?
2019-03-27 02:05:13 <tcely> Right. That intention is what I don't understand.
2019-03-27 02:05:16 <SpaceToast> (move the thing you want as a depend *out* of main)
2019-03-27 02:05:32 <SpaceToast> main/ is meant to be a "full system" in an embedded context
2019-03-27 02:05:40 <SpaceToast> you should have a self-hosting router with just main, for example
2019-03-27 02:05:57 <tcely> Yep. I have considered that. For example. https://github.com/alpinelinux/aports/pull/5140
2019-03-27 02:06:01 <SpaceToast> so if something doesn't quite fit that, maybe it should be moved out of there
2019-03-27 02:06:41 <tcely> Worrying about how badly the interactions between main/community/testing work out is a lot of trouble.
2019-03-27 02:07:21 <SpaceToast> yes, it's an unfortunate side effect
2019-03-27 02:07:26 <SpaceToast> it gets even worse, though
2019-03-27 02:07:38 <SpaceToast> for instance, right now, the packaging people only have access to community and testing
2019-03-27 02:07:45 <SpaceToast> while main is handled by the core developers
2019-03-27 02:08:02 <SpaceToast> so moving things around is a huge pain, because of the intersection being awkward
2019-03-27 02:08:16 <SpaceToast> that's also getting addressed within the same proposal (in fact the last couple of days were spent discussing that)
2019-03-27 02:08:49 <SpaceToast> but in this case, I think fossil should probably be moved into community, yes
2019-03-27 02:09:15 <SpaceToast> we don't have anything in main that depends on fossil, and I can't see a router needing it (even for self-hosting reasons)
2019-03-27 02:09:18 <SpaceToast> that's just my opinion though
2019-03-27 02:53:33 <opal> was the keybase verification issue expanded upon in here? i havent been paying much attention to the channel in the past while
2019-03-27 03:17:45 <helloterra> exit
2019-03-27 03:24:58 <ddevault> >whats going to happen to all those orphaned packages?
2019-03-27 03:25:10 <ddevault> fwiw "examine the list of orphaned packages and adopt the ones I care about" is on my todo list
2019-03-27 03:25:24 <ddevault> probably for thursday
2019-03-27 09:33:48 <mps> to repeat my yesterday question: does it make sense to build irssi with --enable-true-color ? asking because working on upgrade 1.2.0
2019-03-27 09:36:21 <mps> and with OTR, 1.2.0 now have OTR included
2019-03-27 09:51:17 <ncopa> mps: i dont know what --enable-tru-color means. does it pull in more dependencies? will the build becomes much bigger?
2019-03-27 09:51:46 <ncopa> i would believe it makes sense to enable it unless the "cost" is too big
2019-03-27 09:53:11 <mps> ncopa: no, it is to work with modern terminal emulator
2019-03-27 09:53:56 <AinNero> yeah, just support for sgr terminal sequences for RGB colors
2019-03-27 09:54:08 <mps> no extra deps but could be problematic on older term which do not reports their capabilities correctly
2019-03-27 09:54:21 <AinNero> is it enabled per default?
2019-03-27 09:54:42 <mps> AinNero: not in current APKBUILD
2019-03-27 09:54:56 <AinNero> oh, i meant, is irssi actually using these codes per default
2019-03-27 09:55:21 <mps> I think not
2019-03-27 09:55:29 <ncopa> mps: i'd say that you can enable it. just explain why it was enabled in the commit message
2019-03-27 09:55:52 <mps> I will test it before sending patch
2019-03-27 09:56:13 <AinNero> im currently researching this as well, i would be one of the users of it
2019-03-27 09:56:19 <ncopa> "older terms which do not report their capabilities correctly"
2019-03-27 09:56:23 <ncopa> sounds like bug in the term
2019-03-27 09:56:33 <ncopa> so the proper thing to do would be to fix the term
2019-03-27 09:56:39 <ncopa> instead of working around it in irssi
2019-03-27 09:56:51 <mps> not bug, but their state when they are made
2019-03-27 09:57:03 <AinNero> actually, its clearly specified with setting of $TERM
2019-03-27 09:57:08 <mps> I have to test it on linux console
2019-03-27 09:58:10 <mps> with modern terms it works fine, have to check with mosh sessions also
2019-03-27 09:58:45 <AinNero> good news, irssi requires /set colors_ansi_24bit on
2019-03-27 09:58:58 <mps> AinNero: right
2019-03-27 09:59:20 <AinNero> this is a 'go for it' from me
2019-03-27 09:59:53 <mps> other question was about OTR, it is included now, and can be built as module or static
2019-03-27 10:00:28 <mps> I think it should be built as module so users which needs it can load it
2019-03-27 10:00:29 <ncopa> we generally want build things as modules and place those in subpackages if possible
2019-03-27 10:00:37 <ncopa> yes
2019-03-27 10:01:03 <mps> good, thanks for help
2019-03-27 14:38:34 <p4Wv1qn095FW> i find this very interesting, and am hopeful maybe alpine does switch to tls repos soon: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/
2019-03-27 14:52:52 <otlabs> hi ppl
2019-03-27 14:54:54 <mps> p4Wv1qn095FW: as a long time Debian user (and packages some system apps) I'm not sure in merit in the post
2019-03-27 14:56:34 <p4Wv1qn095FW> i'm not sure a user (even if longtime) has the same view as an attacker
2019-03-27 14:57:35 <p4Wv1qn095FW> anyway enabling tls is not a big deal (except maybe busybox wget will not play)
2019-03-27 14:57:55 <mps> I do argue about the security of apt management, but think that the article have no merit
2019-03-27 14:58:10 <mps> s/ do/don't/
2019-03-27 14:58:10 <alpine-meetbot> mps meant to say: Idon't argue about the security of apt management, but think that the article have no merit
2019-03-27 14:58:48 <mps> look this sentence: Always use TLS for serving APT repositories. This will prevent an attacker from being able to perform a MitM.
2019-03-27 14:59:32 <mps> after that will not discuss article anymore
2019-03-27 15:02:06 <p4Wv1qn095FW> managing a good CA store is part of running TLS and if so, it makes total sense
2019-03-27 15:02:54 <p4Wv1qn095FW> of course if you let your CA store be infested with MITM certs, that is a different story, yet it still means you have to have such a CA yourself, and reduces the set of attackers slightly
2019-03-27 15:04:19 <mps> you are right, but the problem is that article trying to say that enough to use TLS to have secure apt, which is plain wrong
2019-03-27 15:05:08 <p4Wv1qn095FW> lot's of attacks become limited to nationstates which are otherwise possible for anyone without even a CA
2019-03-27 15:05:21 <p4Wv1qn095FW> that still makes sense
2019-03-27 15:05:58 <p4Wv1qn095FW> today i can simply run a freeze or replay attack with known vulnerable packages.
2019-03-27 15:06:01 <mps> again I agree with you, but worse than no security is false sense of security
2019-03-27 15:06:18 <p4Wv1qn095FW> this is not a false sense of security. this is defense in depth
2019-03-27 15:06:43 <p4Wv1qn095FW> another defense would be of course to not allow nationstate cas in there ca store
2019-03-27 15:06:52 <p4Wv1qn095FW> but that is a different discussion.
2019-03-27 15:07:56 <mps> right, security is complex, isn't it :)
2019-03-27 15:13:39 <fcolista> 	/j #alpine-devel
2019-03-27 15:13:39 <fcolista> 	/j #alpine-commits
2019-03-27 15:13:39 <fcolista> 	/j #alpine-linux
2019-03-27 15:13:39 <fcolista> 	/j #alpine-team
2019-03-27 15:13:39 <fcolista> 	/j #alpine-infra
2019-03-27 15:13:40 <fcolista> 	/j #alpine-meetings
2019-03-27 15:13:42 <fcolista> 	/j #alpine-offtopic
2019-03-27 15:13:50 <fcolista>  /j #alpine-meetings
2019-03-27 15:13:56 <fcolista> DOH
2019-03-27 15:14:31 <fcolista> sorry
2019-03-27 15:14:31 <_ikke_> :-)
2019-03-27 15:14:39 <fcolista> wrong window ..
2019-03-27 15:14:40 <fcolista> uff
2019-03-27 15:16:06 <AinNero> meetings is there twice
2019-03-27 15:16:39 <_ikke_> lol
2019-03-27 15:17:08 <TBB> damn, can't even accidentally paste optimally :/
2019-03-27 15:56:27 <otlabs> _ikke_: Greetings! Any chance to continue with go-ipfs package? I had in mind to get ZIM files production tool (already done) and put ZIM files on IPFS for distribution (not done yet).
2019-03-27 16:10:41 <nmeum> p4Wv1qn095FW: you can instruct apk to fetch packages over https if you want to
2019-03-27 16:10:54 <nmeum> it's not the default but just FYI
2019-03-27 16:16:10 <p4Wv1qn095FW> nmeum: oh? that is super good news, didn't know! am a bit ashamed about this ignorance. sorry
2019-03-27 16:17:50 <TBB> it's a lesser known feature and hasn't been there that long
2019-03-27 16:19:26 <nmeum> really? it should work since 2014 at least https://git.alpinelinux.org/apk-tools/commit/?id=555363f056377508040d3a555d198c4b87aff3a3
2019-03-27 16:19:59 <TBB> ah, right, I was thinking of using your own certs for https
2019-03-27 16:20:43 <mps> AinNero: ncopa: have another question about irssi and want to hear what you think. there is testing/irssi-otr pkg which should be removed by irssi upgrade to 1.2.0
2019-03-27 16:22:02 <mps> should I add subpackage irssi-otr (like there is irssi-perl) with otr module in that subpackage
2019-03-27 16:23:52 <mps> proxy module could be sample for otr module subpackage
2019-03-27 16:24:03 <AinNero> is there an alternative?
2019-03-27 16:24:37 <AinNero> (i parsed this as only 1 choice yet)
2019-03-27 16:24:38 <mps> well, to keep otr module in main package ?
2019-03-27 16:26:49 <AinNero> irssi-otr is a different upstream, right?
2019-03-27 16:27:59 <AinNero> oh, not anymore, was just included..
2019-03-27 16:28:12 <AinNero> yeah, then it would make sense to have it as subpackage
2019-03-27 16:29:22 <tmhoang> So there is a project I'm testing uses GNU extension argz that musl would not support. I have 2 choices : split the argz functions in GNU and create libargz package (is it legal ?) or copy the .c and .h file in my package and build them, link them while building my package.
2019-03-27 16:29:56 <mps> I think so, canonical way, but module is just 37689 bytes on armv7 and help is 338 bytes, so small that I'm not sure if it is worth supbackage
2019-03-27 16:30:12 <artok> newbie question about abuild cross compiling... I'm just bootstrapping aarch64 crosscompiler thingies
2019-03-27 16:30:20 <tmhoang> *copy the argz .c and .h files into my package and build them
2019-03-27 16:30:31 <tmhoang> artok: yes ?
2019-03-27 16:31:01 <artok> what command to use then to build for aarch64 or does APKBUILD handle that automatically?
2019-03-27 16:31:32 <_ikke_> artok: Alpine itself never cross-compiles
2019-03-27 16:31:40 <_ikke_> artok: Everything is built on native hardware
2019-03-27 16:32:21 <AinNero> tmhoang: indecisive about this, is this really the first case where a package needs the argz functionality?
2019-03-27 16:32:49 <tmhoang> _ikke_ : why ? scripts/bootstrap.sh is for that purpose.
2019-03-27 16:33:14 <_ikke_> tmhoang: That does not negate my statements
2019-03-27 16:33:45 <_ikke_> You have to bootstrap the compiler ofcourse
2019-03-27 16:33:47 <tmhoang> _ikke_ : the folk just wants to make his cross toolchains and I guess bootstrap.sh serves it right
2019-03-27 16:34:15 <tmhoang> _ikke_ : yeah he mentioned aarch64 crosscompiler thingies
2019-03-27 16:35:19 <tmhoang> AinNero: I don't know for others. argz might be not the first gnu ext that musl would not support.
2019-03-27 16:35:58 <artok> so how to use that crosstoolchain ?
2019-03-27 16:36:09 <tmhoang> AinNero: there were other cases like feenableexcept
2019-03-27 16:38:21 <tmhoang> artok: you need to run aports/scripts/bootstrap.sh on your x86 to create an aarch64 cross-toolchains. Then use this toolchains (run on x86), and produce aarch64 binaries.
2019-03-27 16:41:15 <tmhoang> after running boostrap.sh you will have an aarch64 repo containing a bunch of aarch64 apk packages (base system), which can be used to netboot (for example) your aarch64 Alpine system on aarch64 hardware/qemu.
2019-03-27 16:41:34 <artok> yeah, that is known, I have used cmake + llvm for cross compiling, so is there abuild settings to use ? or do I need to set all CC CXX CFLAGS?
2019-03-27 16:41:35 <tmhoang> or you can create an aarch64 Alpine rootfs
2019-03-27 16:42:02 <tmhoang> bootstrap.sh and abuild do that for you
2019-03-27 16:42:37 <artok> btw there is bug on bootstrap.sh, ncurses should be before openssh
2019-03-27 16:42:54 <artok> and also needs libedit to work
2019-03-27 16:42:55 <artok> =)
2019-03-27 16:43:27 <AinNero> tmhoang: im tempted to redirect the argz matter to #musl, i guess they might have more knowledge about potential implications
2019-03-27 16:43:52 <tmhoang> AinNero: yes I'm about to go there. Let's see how it goes ...
2019-03-27 18:08:29 <andypost[m]> ncopa: I'd like to get your POV on #9958 patch is huge but looks that's only way now, so no idea about backport
2019-03-27 18:34:47 <artok> here is diff needed to get bootstrap.sh run through https://hastebin.com/payafokoki.diff
2019-03-27 20:21:04 <_ikke_> otlabs: I don't think the deps are currently versioned
2019-03-27 20:21:28 <_ikke_> otlabs: You should be able to do something like this: https://git.alpinelinux.org/aports/tree/community/easypki/APKBUILD
2019-03-27 20:21:47 <_ikke_> otlabs: The idea is to maintain a glide.lock file ourself
2019-03-27 20:21:59 <otlabs> _ikke_: thank you, I will take a look
2019-03-27 20:24:30 <otlabs> just a reminder, it looks like all versions are fixed by https://github.com/ipfs/go-ipfs/blob/master/package.json
2019-03-27 20:25:22 <_ikke_> otlabs: afaik, there is nothing in go looking at that file though (unless you can find a reference telling otherwise)
2019-03-27 20:26:10 <otlabs> oh, i see. let me check that too.
2019-03-27 20:26:40 <_ikke_> I looked for references to package.json, but only see references to other projects
2019-03-27 20:28:02 <_ikke_> otlabs: I found this, but it doesn't seem to be related to dependencies: https://golang.org/pkg/encoding/json/
2019-03-27 20:30:36 <otlabs> _ikke_: tha file package.json is handled i "gx"
2019-03-27 20:30:51 <otlabs> s/ i/ by/
2019-03-27 20:30:52 <alpine-meetbot> otlabs meant to say: _ikke_: tha file package.json bys handled i "gx"
2019-03-27 20:31:11 <_ikke_> Right, but that is not yet available, right?
2019-03-27 20:31:24 <otlabs> it is in the same PR
2019-03-27 20:31:31 <_ikke_> Yes, but you don't make use of it
2019-03-27 20:31:38 <otlabs> gx, gx-go, and go-ipfs
2019-03-27 20:31:42 <_ikke_> yes, I see them there
2019-03-27 20:32:00 <otlabs> go-ipfs do uses gx
2019-03-27 20:32:24 <_ikke_> right, but gx and gx-go themself not I assume?
2019-03-27 20:32:58 <otlabs> you mean bootstrap problem?
2019-03-27 20:33:02 <_ikke_> yes
2019-03-27 20:33:37 <otlabs> gx has its out package.json
2019-03-27 20:34:46 <otlabs> https://github.com/whyrusleeping/gx/blob/master/package.json
2019-03-27 20:37:24 <_ikke_> but is `go get` in gx already using that?
2019-03-27 20:37:54 <_ikke_> What I understand is that go-gx is a language extension that lets go use gx to fetch dependencies?
2019-03-27 20:38:59 <_ikke_> otlabs: bootstrap needs to be properly solved. The builders for each version always start from scratch, they don't rely on packages from earlier versions
2019-03-27 20:39:08 <otlabs> I am afraid I have no enogth knowledge in go to answer  if "go get" is using it
2019-03-27 20:39:39 <_ikke_> Under normal circumstences, go get just fetches the latest version of each lib
2019-03-27 20:39:47 <otlabs> yes, I also understand that gx-go is a link between go and gx
2019-03-27 20:39:50 <_ikke_> the way to 'fix' depencies is by vendoring
2019-03-27 20:40:12 <_ikke_> ie, put all dependencies in the vendor folder and ship that with the project
2019-03-27 20:40:38 <_ikke_> later, people came up with package/dependency managers like glide, dep and now gx
2019-03-27 20:41:25 <otlabs> sorry, I am not that familiar with go to complete this task of vendoring
2019-03-27 20:41:59 <_ikke_> my knowledge of go is also supervisial. But doesn't that easypki package help?
2019-03-27 20:42:20 <_ikke_> It shows how to create the glide.yml/glide.lock files
2019-03-27 20:43:10 <otlabs> yes, your are right
2019-03-27 20:43:35 <otlabs> I took a recipe for go-ipfs from Arch Linux repo
2019-03-27 20:44:07 <otlabs> rebuilding abuild with glide would be fun but somehow out of my skills
2019-03-27 20:44:10 <otlabs> I assume I need to give up and leave this abuild for my local use only
2019-03-27 20:44:35 <_ikke_> I can take a stab in doing it
2019-03-27 20:44:50 <otlabs> Thank you for your so kind attention and constant help
2019-03-27 20:44:59 <artok> ok so how do I crossbuild using abuild -r ? how to tell it about sysroot ?
2019-03-27 20:46:23 <otlabs> _ikke_: i really appreciate your so kind offer
2019-03-27 20:46:34 <otlabs> you are busy person
2019-03-27 20:46:47 <artok> giving CHOST yeah but then there is problem with linux-headers
2019-03-27 20:46:48 <otlabs> and that task is somehow out of my skills
2019-03-27 20:47:16 <_ikke_> I'm checking now how archlinux is doing it
2019-03-27 20:47:17 <otlabs> i think i would wait for ipfs implementation in c ;-)
2019-03-27 20:48:29 <_ikke_> I don't see dependencies on gx / go-gx here though: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/go-ipfs
2019-03-27 20:51:48 <otlabs> let me check. I used that file as a guide
2019-03-27 20:54:56 <otlabs> Must be I took that dependencies from go-ipfs build instructions
2019-03-27 20:55:39 <_ikke_> I think arch just relies on them being installed automatically
2019-03-27 20:56:20 <otlabs> https://github.com/ipfs/go-ipfs#download-and-compile-ipfs
2019-03-27 20:57:05 <_ikke_> "This process may break if gx (used for dependency management) or any of its dependencies break as go get will always select the latest code for every dependency, often resulting in mismatched APIs."
2019-03-27 20:57:23 <_ikke_> That's what we're trying to avoid
2019-03-27 20:57:28 <otlabs> I overprotected adding explicit dependency for gx and gx-go from "Building on less common systems"
2019-03-27 20:57:36 <otlabs> yes
2019-03-27 20:57:59 <_ikke_> but we need to start with gx and gx-go first
2019-03-27 21:01:15 <_ikke_> It doesn't look archlinux is protecting themself against this
2019-03-27 21:01:22 <otlabs> yep
2019-03-27 21:01:27 <_ikke_> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/gx#n30
2019-03-27 21:01:30 <_ikke_> just a got get
2019-03-27 21:01:34 <_ikke_> go get*
2019-03-27 21:06:37 <otlabs> yes
2019-03-27 21:07:07 <mps> artok: crossbuild hardly to work on Alpine
2019-03-27 21:07:42 <artok> well that seems to be the thing
2019-03-27 21:07:51 <_ikke_> otlabs: I like this patter btw for GOPATH: https://git.alpinelinux.org/aports/tree/community/vault/APKBUILD#n23
2019-03-27 21:08:23 <mps> Alpine build packages native by intention
2019-03-27 21:08:53 <artok> I need to then have aarch64 emu
2019-03-27 21:10:05 <mps> artok: if the package is build hog you can use qemu, I built some packages for armhf with qemu
2019-03-27 21:10:59 <otlabs> _ikke_: looks quite nice, I hope I can do that
2019-03-27 21:14:51 <_ikke_> otlabs: I'm building that in already
2019-03-27 21:15:29 <otlabs> _ikke_: cool ;-)
2019-03-27 21:32:33 <_ikke_> otlabs: This seems to work: http://tpaste.us/robx
2019-03-27 21:33:52 <otlabs> wow
2019-03-27 21:33:58 <otlabs> thank you
2019-03-27 21:34:15 <_ikke_> I just copied some concepts from vault and easypki
2019-03-27 21:34:20 <otlabs> i will add this to gx and update PR
2019-03-27 21:34:45 <_ikke_> You also need to run abuild glide_init and add the glide.yaml/lock files
2019-03-27 21:35:34 <otlabs> thanks a lot!
2019-03-27 21:36:01 <_ikke_> no problem
2019-03-27 21:36:23 <otlabs> same thing should be done for go-ipfs package i assume?
2019-03-27 21:37:22 <_ikke_> first go-fx I guess
2019-03-27 21:37:33 <otlabs> ok
2019-03-27 21:37:50 <_ikke_> It might be the go-ipfx is already using go-gx / package.json
2019-03-27 21:37:54 <_ikke_> like you said
2019-03-27 21:38:38 <otlabs> ok
2019-03-27 21:38:50 <otlabs> thanks a lot again!
2019-03-27 21:39:03 <otlabs> will incorporate that changes ASAP
2019-03-27 21:40:43 <_ikke_> I'll see the update
2019-03-27 22:01:52 <artok> mps any docs how to start qemu arm ?
2019-03-27 22:05:26 <artok> just x86 stuff have bootable iso...
2019-03-27 22:08:28 <mps> artok: I have somewhere start script, will look later for it
2019-03-27 22:08:56 <clandmeter> you should be able to boot from kernel + initramfs
2019-03-27 22:09:14 <clandmeter> append the modloop from cmdline
2019-03-27 22:09:32 <mps> I'm just preparing upgrade of my Internet router
2019-03-27 22:11:02 <artok> oh.. so long time since used qemu, sorry bout that =)
2019-03-27 22:24:08 <mps> artok: here is the start script http://tpaste.us/P0bJ
2019-03-27 22:25:11 <mps> basically, you download tar.gz, unpack it somewhere and add needed files and parameters to script
2019-03-27 22:29:50 <artok> yah, the root parameter just on the first boot might do some hassle
2019-03-27 22:30:27 <otlabs> _ikke_: drone has successfully compiled the package while travis is still starting virtual machine
2019-03-27 22:30:37 <mps> that's a qemu image without partition table
2019-03-27 22:31:12 <artok> mounting boot media failed.. watta
2019-03-27 22:31:18 <mps> easier for loop mount
2019-03-27 22:32:17 <mps> you have to build it, I think you know how to do that
2019-03-27 22:38:41 <artok> well yeah but problem is boot media, not root..
2019-03-27 22:40:47 <mps> artok: you create it and unpack tar.gz there
2019-03-27 22:41:38 <mps> sorry, going to upgrade. see you later, (I hope will not make big mess with upgrade)
2019-03-27 22:42:21 <artok> upgrading software and alcohol is my favourite mix
2019-03-27 22:42:30 <artok> just after music + girlies
2019-03-28 00:49:53 <otlabs> _ikke_: ok, now both systems compiled the package fine
2019-03-28 00:50:03 <otlabs> need to go, see you later, bye
2019-03-28 09:41:41 <jwh> aww
2019-03-28 09:41:57 <jwh> I thought ipfw might be in testing by now since theres been quite a bit of chatter about it
2019-03-28 09:46:00 <_ikke_> ipfw?
2019-03-28 09:46:06 <jwh> ipfs even
2019-03-28 09:46:19 <_ikke_> hehe
2019-03-28 09:46:21 <_ikke_> right
2019-03-28 09:46:34 <_ikke_> You need to be careful with packaging go projects
2019-03-28 09:46:57 <jwh> go makes me sad
2019-03-28 09:48:55 <jwh> https://github.com/alpinelinux/aports/tree/master/testing/
2019-03-28 09:48:58 <jwh> uh
2019-03-28 09:49:06 <jwh> good oen github
2019-03-28 09:49:10 <jwh> https://github.com/alpinelinux/aports/pull/5812
2019-03-28 09:50:10 <_ikke_> Yes, but the dependencies for gx / gx-go are not fixed yet
2019-03-28 09:50:14 <jwh> ah
2019-03-28 09:50:20 <_ikke_> I helped otlabs with a fix for that
2019-03-28 10:02:30 <mps> jwh: I stopped to program in go about ten months ago, language is ok, but 'ecosystem' is mess. switched to crystal for application programming and started to learn rust for system but now thinking to forget all that new easy/productive languages and go back old goog C :)
2019-03-28 10:02:57 <jwh> wish people would stop creating new languages
2019-03-28 10:02:59 <mps> good*
2019-03-28 10:03:09 <jwh> ridiculous fragmentaiton and broken ecosystems everywhere because there are so many
2019-03-28 10:04:55 <mps> if i wake in the morning and read news (with coffee, of course) and don't see that some smart guy and his dog didn't invented new language I have feeling that the world is over :D
2019-03-28 10:05:02 <jwh> lol
2019-03-28 10:05:32 <mps> sorry all for OT
2019-03-28 10:20:55 <mps> community/tcsh is not in 'good shape' and needs fixes and some add-on files. Because most of fixes in it's Alpine life are from me (can be seen at bugs.a.o) I'm asking is it ok to take maintainership, not because I want to take credits, but to add myself as a person which could be contacted in case of bugs or whatever with it
2019-03-28 10:22:08 <mps> I use tcsh as my primary shell for more than 30 years so want it to be in good shape
2019-03-28 10:25:37 <mps> I lie a little, it is about 25 years and not 30, sorry, to early is here and memory deceive me a little  :)
2019-03-28 10:27:27 <AinNero> im not even that old lol
2019-03-28 10:28:02 <mps> AinNero: one day you will be, I hope :)
2019-03-28 10:28:13 <AinNero> ugh
2019-03-28 10:29:08 <AinNero> hm, someone could make a shell using s-expressions
2019-03-28 12:46:49 <andypost[m]> mps, I think you need to provide PR with changes and try contact current maintainer
2019-03-28 12:48:47 <mps> andypost[m]: I agree, and had a hope that maybe maintainer is here to start conversation
2019-03-28 12:51:04 <andypost[m]> as I see 184585c046cdd56512f1a76e426dd799b368f8cf is only commit from this author
2019-03-28 12:52:39 <mps> I see the same, so don't know is he active
2019-03-28 12:55:00 <mps> original commit (dea5ad8e70c49c9685e5485d85b591652fa03560) doesn't have Contributor nor Maintainer
2019-03-28 12:55:46 <mps> because all that I wrote that tcsh is not in 'good shape' and wan't to fix what I can
2019-03-28 12:56:44 <mps> but, ok, I can do that without changing maintainer, but think it will be good if packages have 'real' maintainer
2019-03-28 15:11:16 <otlabs> hi ppl
2019-03-28 16:04:18 <otlabs> I would like to move a package from makedepends to checkdepends. Should I increment pkgrel in this case?
2019-03-28 16:10:39 <mps> otlabs: I think so, because bumping pkgrel should trigger rebuild, if the package have to be rebuilt by these changes.
2019-03-28 16:10:59 <_ikke_> right, that's the question, should it be rebuilt
2019-03-28 16:11:14 <_ikke_> and I don't think that's the case for just moving a dependency make makedepends to checkdepends
2019-03-28 16:11:40 <mps> that is about what I'm not sure, also
2019-03-28 16:12:09 <tmhoang> _ikke_, AinNero, andypost[m]: would you mind having a look ? https://github.com/alpinelinux/aports/pull/6807
2019-03-28 16:13:17 <_ikke_> tmhoang: I can't push that one
2019-03-28 16:13:37 <tmhoang> _ikke_: anything I can do ?
2019-03-28 16:13:52 <_ikke_> tmhoang: I don't have rights :-), so no
2019-03-28 16:14:01 <tmhoang> n_copa is busy, so don't really want to ping him
2019-03-28 16:14:20 <tmhoang> _ikke_: interesting, I thought you have write permission to main
2019-03-28 16:14:22 <_ikke_> shouldn't depend on him, there are other capable of doing that
2019-03-28 16:14:22 <tmhoang> thanks anyway
2019-03-28 16:19:48 <otlabs> mps, _ikke: I do not want to rebuild the package. The package I plan to move is used during check() only.
2019-03-28 16:23:42 <_ikke_> exactly, so no pkgrel bump requires
2019-03-28 16:23:49 <_ikke_> required*
2019-03-28 16:24:11 <otlabs> ok, thanks!
2019-03-28 16:25:41 <otlabs> as a side note I would like to mention that ABUILD Reference, https://wiki.alpinelinux.org/wiki/APKBUILD_Reference, has no any subsection for checkdepends. That option was mentioned in a hidden fashion in check() subsection.
2019-03-28 16:26:29 <_ikke_> I guess because it's relatively new
2019-03-28 16:26:41 <_ikke_> Would be good to add it indeed
2019-03-28 16:27:04 <tcely> I'd rather see the rebuild immediately so that if that change causes a problem it can be fixed rather than showing up later for no apparent reason.
2019-03-28 16:33:03 <_ikke_> From the wiki: "Creating a very simple check function, that calls program --version is better than disabling tests completely." That's a different policy then has been mentioned elsewhere. Is this correct?
2019-03-28 16:34:51 <tcely> I agree with that statement. Any positive confirmation of a working program is better than nothing.
2019-03-28 16:36:38 <_ikke_> It has been said that it because --version|--help often just exit early, that it doesn't give a lot of coverage and can give a false sense that things are being tested
2019-03-28 16:42:16 <tcely> Anything that always reports success is a poor test, but just running at all is useful information.
2019-03-28 16:43:33 <tcely> I've had simple checks like this stop the package from building when the binary wasn't linking correctly. It is useful for that alone to me.
2019-03-28 16:43:52 <ncopa> andypost[m]: sorry that i didnt have time to look at php libssh today.
2019-03-28 16:44:21 <tcely> We should encourage thorough checks, but prefer something to none in my opinion.
2019-03-28 16:48:51 <ncopa> tcely: im working boost
2019-03-28 16:49:20 <ncopa> it seems that building with --layout=system makes lucene++ build
2019-03-28 16:51:34 <tcely> ncopa: would you build boost on s390x? I'd like to see how the layout names work for that arch.
2019-03-28 16:51:55 <ncopa> --layout=system will remove arch from the filename
2019-03-28 16:52:31 <tcely> lucene++ builds with Boost_ARCHITECTURE set too
2019-03-28 16:52:40 <ncopa> i also think the _skip_lib logic is still broken
2019-03-28 16:53:06 <tcely> Oh? How is it broken?
2019-03-28 16:53:15 <ncopa> i think the most sensible thing to do is to build with --layout=system
2019-03-28 16:53:18 <ncopa> its the default too
2019-03-28 16:53:57 <ncopa> once _skip_lib is set to 1 it will skip all of the rest
2019-03-28 16:54:04 <tcely> With system we collide on mt and such
2019-03-28 16:54:05 <ncopa> which i dont think is the intention
2019-03-28 16:54:27 <ncopa> i think we dont need build single threaded at all
2019-03-28 16:54:46 <tcely> Yep. That is broken. I missed a line it seems.
2019-03-28 16:54:52 <ncopa> i need to go now
2019-03-28 16:55:02 <ncopa> will try get boost merged this week
2019-03-28 16:55:08 <ncopa> thanks!
2019-03-28 16:55:10 <tcely> Thanks
2019-03-28 16:55:29 <andypost[m]> ncopa np, just need opinion about to add so huge patch while upstream not releasing new version
2019-03-28 16:57:02 <andypost[m]> And really discouraged by inline function - not good enough in c to get why inline not working
2019-03-28 17:34:29 <bratkartoffel> Can someone please take a look and merge my openjdk PRs? They are done from my side and I'm eager to open the openjdk11 PR: https://github.com/alpinelinux/aports/pull/6489 and https://github.com/alpinelinux/aports/pull/6500
2019-03-28 17:56:59 <mps> now when the kaniini resigned, will someone take care of the network-manager, or I have to try, it needs upgrade and change patches
2019-03-28 19:42:11 <clandmeter> mps: take what you can :)
2019-03-28 19:43:14 <mps> clandmeter: I did, nearly built nm 1.16.0 it have your loved wireguard support :)
2019-03-28 19:43:28 <SpaceToast> \o/
2019-03-28 19:43:39 <clandmeter> Nice
2019-03-28 19:44:10 <mps> and IWD support, I'm trying make it in good shape because of iwd
2019-03-28 19:45:20 <mps> a week ago I thought to ask kaniini to upgrade it
2019-03-28 22:55:17 <otlabs> time to go, see you, bye
2019-03-29 12:57:52 <_ikke_> Open call for testing latest openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html
2019-03-29 12:58:08 <_ikke_> (well, upcomming, not latest)
2019-03-29 12:59:47 <SpaceToast> _ikke_: there are a few features in there that I've been waiting for; can we get a copy of openssh in testing/ with all that?
2019-03-29 12:59:55 <SpaceToast> I'd check it out in that case :)
2019-03-29 13:01:07 <_ikke_> What features are you interested in?
2019-03-29 13:01:24 <SpaceToast> ECDSA on PKCS11
2019-03-29 13:01:30 <SpaceToast> actually waited a few years for that
2019-03-29 13:01:49 <SpaceToast> also -J on scp
2019-03-29 13:02:06 <SpaceToast> ssh-add -T seems nice too
2019-03-29 13:05:57 <mps> security_team: postgresql needs upgrade because of serious issue, https://www.postgresql.org/about/news/1920/
2019-03-29 13:06:34 <SpaceToast> we don't have a security team yet, so I'd say contact the maintainer (which seems to be jirutka)
2019-03-29 13:07:24 <mps> hmm, I had impression that is 'informal' team which cares of security issues
2019-03-29 13:07:56 <SpaceToast> we want to make a formal one, but in the process of trying to document the informal one we realized no one's in it atm
2019-03-29 13:08:05 <SpaceToast> so it's basically "poke ncopa" and that's it :/
2019-03-29 13:08:08 <SpaceToast> so for now, maintainer it is
2019-03-29 13:08:24 <_ikke_> There are some security reporters
2019-03-29 13:08:32 <mps> maintainer of postgresql is jirutka
2019-03-29 13:10:03 <mps> anyway, right now I'm testing postgresql 11.2 (i.e. needed upgrade) to see does it build correctly
2019-03-29 13:43:55 <mps> postgresql upgrade just need pkgver=11.2 to be upgraded, just tested and it passed 'abuild -r' without error
2019-03-29 13:44:22 <mps> I think it is not worth to send a patch for this
2019-03-29 13:45:28 <mps> and I think older versions in previous Alpine releases also need to be upgraded, because bug is serious
2019-03-29 15:43:40 <mps> anyone would review patch https://patchwork.alpinelinux.org/patch/4694/ for upgrade irssi to 1.2.0
2019-03-29 15:45:07 <mps> also, within this upgrade is add irssi-otr (which is now included in irssi upstream) so should I post patch to remove testing/irssi-otr
2019-03-29 16:02:12 <otlabs> hi ppl
2019-03-29 16:05:01 <_ikke_> otlabs: hi
2019-03-29 16:15:32 <otlabs> _ikke_: greetings!
2019-03-29 19:20:24 <opal> is my scrollback really this bad that it goes away after forgetting this channel for two days
2019-03-29 19:20:26 <opal> whatever
2019-03-29 19:49:59 <otlabs> _ikke_: thank you for checking PR!
2019-03-29 19:50:03 <andypost[m]> mps, btw https://hub.docker.com/_/postgres?tab=tags 2 days ago
2019-03-29 19:50:27 <_ikke_> otlabs: no problem
2019-03-29 19:51:28 <otlabs> may i remind you about go-ipfs next week?
2019-03-29 19:52:58 <_ikke_> You were still going to add the glide lock files, right?
2019-03-29 19:53:19 <otlabs> I have added them for gx already
2019-03-29 19:53:31 <otlabs> lock and yaml
2019-03-29 19:53:49 <mps> andypost[m]: I see, but it is not updated in Alpine
2019-03-29 19:54:10 <_ikke_> otlabs: ok, nice, and gx-go?
2019-03-29 19:54:59 <otlabs> _ikke_: i was waiting for your comments. i will add the glide to gx-go too.
2019-03-29 19:55:58 <_ikke_> ok
2019-03-29 20:49:30 <mps> is it possible to set alternate package in depends field of APKBUILD
2019-03-29 21:07:08 <mps> to be more specific, networkmanager now depends on wpa_supplicant, but edge have iwd also. my question is should I remove wpa_supplicant from depends in networkmanager and let user to select which backend will be used
2019-03-29 21:08:04 <mps> oh, the question is related to upgrade NM from 1.10.x to 1.16.x
2019-03-29 21:18:04 <mps> hmmm, after some thinking NM could be useful even without wireless network. I think that the remove wpa_supplicant from depends is ok. any objection?
2019-03-29 21:28:27 <SpaceToast> that sounds correct to me
2019-03-29 21:28:39 <SpaceToast> I wonder if we can "recommend" wpa_supplicant and/or iwd though
2019-03-29 21:28:52 <SpaceToast> instead of most distros we have "install_if" but that doesn't seem to make sense here
2019-03-29 21:29:39 <danieli> i don't think we have anything along the lines of "optdepends"
2019-03-29 21:30:22 <SpaceToast> yeah, the intent was to use install_if
2019-03-29 21:30:26 <SpaceToast> that just.. doesn't quite fit here :
2019-03-29 21:30:28 <SpaceToast> :(
2019-03-29 21:32:04 <mps> understand, and think Alpine shouldn't follow Debian 'dependency hell' (how I call it)
2019-03-29 21:32:53 <mps> at the end, Alpine is "power users"
2019-03-29 21:34:01 <mps> s/"power/"for power/
2019-03-29 21:34:01 <alpine-meetbot> mps meant to say: at the end, Alpine is "for power users"
2019-03-30 05:18:41 <jwh> https://github.com/alpinelinux/aports/pull/6279
2019-03-30 05:18:41 <jwh> aw
2019-03-30 13:39:44 <tcely> mps: for your nm "suggest" question you might want to look at https://github.com/alpinelinux/aports/blob/67cdc67bc7ebb9b8004d381707999f754c0e4366/main/dhcp/APKBUILD
2019-03-30 13:40:44 <tcely> This chooses vanilla, but lets the user replace it with ldap.
2019-03-30 13:42:56 <mps> tcely: aha, will look if could be done something similar for NM
2019-03-30 13:53:57 <tcely> mps: networkmanager-wifi could be provided by  NM itself and your two options. With correct depends and priorities it should all work out fine.
2019-03-30 14:15:41 <mps> tcely: the issue is in that alpine have two wifi backend pkg's which NM could use
2019-03-30 14:16:24 <mps> how to decide which one of them user wants to install
2019-03-30 14:17:52 <mps> to me solution looks both or none, in depends
2019-03-30 14:19:58 <mps> or create subpackages networkmanager-wpa_supplicant and networkmanager-iwd besides main pkg networkmanager which doesn't depeneds on any of two
2019-03-30 14:22:11 <mps> also, iwd is in testing now and NM is in community, so NM can't depend on pkg in testing which means iwd is out of the issue
2019-03-30 14:23:00 <mps> but, if I understood ncopa he want to have iwd in next release so probably he will move it in community
2019-03-30 14:37:00 <fassl> -
2019-03-30 14:41:29 <fassl> oh sorry, vacuuming the keyboard
2019-03-30 14:42:29 <AinNero> do you have a keyboard vacuum cleaner?
2019-03-30 14:44:23 <fassl> nah, regular vacuum cleaner with this small dust "aufsatz" plug, whatever i don't know the word
2019-03-30 14:46:02 <AinNero> sucking nozzle
2019-03-30 14:46:26 <fassl> yes that :D thx
2019-03-30 14:48:37 <tcely> mps: the networkmanager-wifi subpackage should probably depend on wpa_supplicant for now. Then change wpa_supplicant and iwd to both provide networkmanager-wifi too.
2019-03-30 14:49:20 <tcely> The goal is for when the user chooses iwd for wpa_supplicant to be removed.
2019-03-30 15:01:43 <mps> oh, tcely is gone
2019-03-30 15:02:02 <mps> will consider his advice
2019-03-30 15:04:59 <tcely> This connection is really unstable. I'm still reading the logs.
2019-03-30 19:05:55 <pidydx> Hello!  What would it take to get a gnustep package added to alpine?  I have spent the last day trying to install it from source and I keep running into all kinds of errors
2019-03-30 21:06:46 <_ikke_> pidydx: Someone would need to make the effor to fix these errors
2019-03-30 21:37:27 <pidydx> _ikke_: I'm not sure that it is really errors vs me just not understanding what I am doing wrong.
2019-03-31 07:52:02 <danieli> relating #10179: i think that we should adopt newer versions as fast as possible once the upstream PR (OpenRC support) has been merged and tagged
2019-03-31 12:53:49 <_ikke_> danieli: why as fast as possible?
2019-03-31 12:54:00 <danieli> because it's broken
2019-03-31 13:27:34 <AinNero> is the magiccloud person present here?
2019-03-31 13:30:28 <_ikke_> no clue
2019-03-31 19:26:57 <artok> ums.
2019-03-31 19:27:49 <artok> If I've got diff, how to submit that to review?
2019-03-31 19:29:00 <_ikke_> artok: are you familiar with github?
2019-03-31 19:30:09 <artok> oh so that explains all
2019-03-31 19:30:09 <artok> =)
2019-03-31 19:30:15 <artok> enough to submit pr =)
2019-03-31 19:32:25 <_ikke_> that would work :-)
2019-03-31 19:32:51 <_ikke_> We also accept patches to the mailing list, but github is a bit easier
2019-03-31 19:36:14 <artok> well I've got just slight simplification for bootstrap.sh
2019-03-31 19:36:44 <artok> would be nice to talk with that finnish guy Timo who seems to be behind of those scripts
2019-03-31 19:37:35 <_ikke_> fabled
2019-03-31 19:38:36 <artok> oh
2019-03-31 19:38:55 <artok> like menninkäinen
2019-03-31 19:39:52 <_ikke_> ?
2019-03-31 19:40:07 <artok> menninkäinen is also fabled thing from finland
2019-03-31 19:40:23 <_ikke_> ah ok
2019-03-31 19:43:20 <artok> cross compiling with abuild after bootstrap seems to be almost working
2019-03-31 19:43:26 <artok> documentation just is not there
2019-03-31 19:51:33 <artok> but there, pr done
2019-03-31 19:59:27 <artok> I just would love to get more docs on abuild. I do have boostrapped sysroot etc but then when I hit abuild -r, seems that requirements aren't going to same place as sysroot
2019-03-31 20:07:46 <AinNero> artok: you are aware of build vs host dependencies?
2019-03-31 20:10:26 <artok> I've done cross compiling using cmake + llvm toolchain for arm many times, but to be able to build apk would be nice
2019-03-31 20:11:00 <artok> so yes, I know toolchain and sysroot stuff
2019-03-31 20:12:07 <artok> just how to control those on abuild scripts...
2019-03-31 20:13:51 <artok> hitting: CHOST=aarch64 abuild -r
2019-03-31 20:14:22 <artok> somehow if APKBUILD has linux-headers as dependency, it won't be added to sysroot and can't be found
2019-03-31 20:17:34 <artok> my platform is: macOS with virtualbox runnin alpine linux x86_64
2019-03-31 20:19:23 <artok> aaand all this is because I want to build stuff on raspberrypi that is running aarch64 alpine
2019-03-31 20:28:00 <mps> artok: do you want to build apk or is binary executable enough
2019-03-31 20:28:30 <artok> apk would be good to server other people also
2019-03-31 20:29:15 <artok> for my own use, I truly can use my own toolchain + sysroot and be happy
2019-03-31 20:29:47 <mps> ah, undestand. if binary file is enough there is something called like makecross-muls, or something like that on github
2019-03-31 20:30:04 <artok> but I think when I'm doing these stuff, why not do them so that anyone can use what I'm doing
2019-03-31 20:30:37 <_ikke_> artok: If you submit that APKBUILDS to alpine, the project will compile them and make them available
2019-03-31 20:30:46 <mps> I had similar idea but didn't worked hard on it
2019-03-31 20:31:06 <_ikke_> alpine has native hardware to compile packages
2019-03-31 20:31:33 <artok> _ikke_: well I'd like to test my stuff before committing =)
2019-03-31 20:32:04 <artok> as with wiringPi, yeah I've made edits to the original source so that it should work on aarch64
2019-03-31 20:32:23 <_ikke_> did you try qemu?
2019-03-31 20:32:40 <artok> it is well known fact that Gordon, who is main dev of the wiringPi, doesn't give a s**t
2019-03-31 20:33:22 <mps> if you work on wiringpi it could be built under qemu easilly, I made wiringbp (for banana pi) under armhf qemu
2019-03-31 20:33:24 <artok> running qemu from macOS... not yet
2019-03-31 20:34:56 <artok> problem with qemu is that root filesystem, or the "hda" is not easy to do
2019-03-31 20:35:02 <artok> using mac, that is
2019-03-31 20:35:38 <mps> never used mac for work so don't know
2019-03-31 20:36:29 <artok> mps gave me start script that is good for that it loads the kernel, but then for sysroot... crashes on qemu
2019-03-31 20:37:29 <artok> thing is that I can't easily to mount <any> filesystem to macos and extract boot stuff to it
2019-03-31 20:38:04 <mps> that whas my mistake because I didn't wrote notes about setting alpine arm/aarch64 and now I can't remember exact steps :
2019-03-31 20:38:05 <_ikke_> ncopa dual boots his mac iirc
2019-03-31 20:39:46 <artok> problem then is just that no, I won't be doing dual booting mac unless booting from external hd
2019-03-31 20:39:57 <mps> my son also have some experience with running qemu on macos, I could ask him tomorrow about his work and how far he done
2019-03-31 20:41:14 <artok> qemu -machine raspi3   ... and with aarch64 would be great!
2019-03-31 20:42:04 <mps> I can put online my FS and script to run it, it is barebone Alpine on qemu image
2019-03-31 20:43:24 <mps> I made it because from time to time people ask for such thing
2019-03-31 20:43:58 <artok> well there seems to be reason =)
2019-03-31 20:44:24 <artok> building aarch64 stuff under x86_64 would be great also =)
2019-03-31 20:44:52 <mps> I wanted to polish it, but switched to 'more important' things for Alpine and didn't finished
2019-03-31 20:46:00 <mps> cross build is on my not so short list for alpine, have no idea when will have time to work on it
2019-03-31 20:47:30 <mps> _ikke_: you have rights on main aports?
2019-03-31 20:48:49 <_ikke_> no
2019-03-31 20:49:31 <mps> eh, what a pity, new shiny irssi is on patchwork
2019-03-31 20:50:01 <artok> oh great irssi =)
2019-03-31 20:50:57 <mps> looks nice with true-color
2019-03-31 20:54:42 <artok> true-color... when talking about text app
2019-03-31 20:55:30 <mps> yes, something like html color #RRGGBB
2019-03-31 20:56:04 <artok> aaaand then we go into the depths of what is colour and colour management =)
2019-03-31 20:56:28 <mps> :)
2019-03-31 20:58:42 <artok> i'm just there because of my work
2019-03-31 20:59:08 <artok> AV tech, working with sound, light and video stuff
2019-03-31 20:59:47 <artok> more than RGB for me then ;)
2019-03-31 21:00:30 <mps> than you understand this things better than me
2019-03-31 21:03:55 <mps> artok: you can look here https://designprincipia.com/virtualize-uefi-on-arm-using-qemu/ for starting guide to run aarch64 under qemu
2019-03-31 21:04:52 <artok> well thanks!
2019-03-31 21:07:33 <artok> daaah
2019-03-31 21:07:59 <artok> that is ARM 32bit emu
2019-03-31 21:08:39 <mps> link from this site http://blog.eciton.net/uefi/qemu-arm-uefi.html
2019-03-31 21:08:45 <artok> prebuilt image for arm 64bit would be yeaaaah
2019-03-31 21:09:00 <mps> and linaro guides https://wiki.linaro.org/LEG/UEFIforQEMU
2019-03-31 21:19:56 <mps> I have 512MB qemu image with previous stable (3.8.1)  with external u-boot, it works, just checked it again
2019-03-31 21:23:28 <mps> it could be used to install Alpine with setup-xxxxx
2019-03-31 21:27:14 <artok> if somehow, I'd be wanting to do docs for running latest alpine on any arch with qemu with the latest release, or even with edge
2019-03-31 21:27:31 <artok> ...using qemu
2019-03-31 21:29:18 <mps> I will try to create short guide from memory in few days, I hope. I already intended to do that few days ago, now when I finished with NetworkManager
2019-03-31 22:04:26 <mps> hmm, reached to 'sh: can't access tty; job control turned off' from clean room aarch64 install under qemu
2019-03-31 22:04:42 <mps> this time with notes of every step :)
2019-03-31 22:05:29 <mps>  /init in initramfs need to be changed, will continue tomorrow