2019-08-01 10:06:29 <maxice8> there are some PRs for main in  GitHub :D
2019-08-01 10:46:20 <LaFiesta> Hey folks. Is there any tutorial on SR-IOV enabling?
2019-08-01 11:30:27 <maxice8> _ikke_: atools 18.7.1 "ugt-heh" is out
2019-08-01 11:50:22 <_ikke_> :)
2019-08-01 12:11:35 <mps> is there a way to force mkimage.sh to overide some apk's from some other repository which are newer than apk's in default repo
2019-08-01 12:12:32 <mps> or specify exact file path and name of apk's which will wanted to overide default ones
2019-08-01 13:24:07 <mps> hmm, maybe solution to this is to make local mirror and put there files needed to be overridden
2019-08-01 14:36:06 <oneinsect> friends i am trying to use alpine chroot which actually doesnt have musl which is just enough to start building glibc, and then glibc-dev package
2019-08-01 14:36:16 <oneinsect> however i need make which itself is build against musl
2019-08-01 14:36:38 <oneinsect> will that a problem? using make (compiled against musl) to build glibc
2019-08-01 14:36:42 <oneinsect> be*
2019-08-01 15:10:13 <Cogitri> Don't think so, although I'm unsure what you're trying to achieve
2019-08-01 15:11:34 <_ikke_> Cogitri: They want an Alpine installation based on glibc
2019-08-01 15:12:22 <Cogitri> Uhh...but why, IMHO it would be a better decision to use a distro which actually offers a glibc flavour
2019-08-01 15:26:30 <oneinsect> openrc, alpine's simplicity, ability to run from ram, I mean there are so many positives for alpine
2019-08-01 15:26:54 <oneinsect> i am strongly attached to alpine after my wife
2019-08-01 15:28:44 <mps> if you want small and simple how glibc fits there
2019-08-01 15:30:57 <oneinsect> machine learning frameworks like tensorflow, caffe, pytorch have tough time compiling against musl
2019-08-01 15:42:46 <Cogitri> I'm pretty sure that investing your time into getting these to run on musl is better in the longterm (in terms of being more rewarding and easier to maintain in the long run and it's also more useful to more people) than hacking Alpine into using glibc
2019-08-01 15:43:00 <Cogitri> Because you'll have to recompile all packages against glibc
2019-08-01 15:43:20 <Cogitri> And I'm pretty sure that we're breaking glibc compatibility at some places to make it work with musl
2019-08-01 18:48:19 <oneinsect> @cogitri yes I understand
2019-08-01 19:27:29 <mps> where are Alpine mirror script, script which create and update local mirror I mean
2019-08-01 19:28:33 <MY_R> 8h :\
2019-08-01 19:28:46 <MY_R> https://mirrors.alpinelinux.org/#mirror19
2019-08-01 19:29:43 <mps> MY_R: thanks, but I need script to mirror alpine on my box
2019-08-01 19:30:39 <MY_R> mps, ah nah, you just triggerd my need to check mirror status and I saw 8h :\ weird
2019-08-01 21:14:26 <danieli> basically just a cron job to rsync with a service to make mqtt-exec run rsync when new packages are uploaded
2019-08-02 08:05:06 <mps> danieli: good morning. afaik, rsync doesn't work over http/s
2019-08-02 08:05:20 <danieli> mps: morning, and sorry, didn't realize that was a constraint
2019-08-02 08:05:43 <mps> np, will try with wget
2019-08-02 08:06:07 <danieli> the next best is probably something like wget -r or something more intelligent comparing the filenames and fetching + comparing last-modified against a local index to determine what to download
2019-08-02 08:06:10 <mps> or create simple perl script
2019-08-02 08:06:22 <danieli> actually, pulling the filenames alone should be enough
2019-08-02 08:07:14 <mps> I need it as one-time download to test building uboot profile tarballs with mkimage.sh
2019-08-02 08:07:43 <danieli> ah, pulling a mirror only once?
2019-08-02 08:07:44 <mps> so, nothing complicated
2019-08-02 08:08:03 <mps> yes, I don't need it as real mirror
2019-08-02 08:08:05 <danieli> can i ask *why* only using http is a restriction?
2019-08-02 08:08:23 <danieli> rsync does compression and can do parallelism out of the box
2019-08-02 08:08:54 <mps> you mean, why rsync doesn't work over http
2019-08-02 08:09:03 <danieli> no, why you can't use rsync
2019-08-02 08:09:41 <mps> does it work with http://dl-cdn.a.o
2019-08-02 08:10:02 <danieli> i don't believe it works with dl-cdn but it works with a lot of other mirrors
2019-08-02 08:10:06 <mps> or any alpine mirror
2019-08-02 08:10:13 <danieli> see https://mirrors.alpinelinux.org/
2019-08-02 08:10:27 <danieli> lots of them offer rsync and i have collected pretty precise locations for most (all) of the mirrors
2019-08-02 08:10:57 <mps> hmm, I must be blind
2019-08-02 08:11:17 <danieli> i can recommend looking for the one geographically closest to you with decent bandwidth available and rsync from that
2019-08-02 08:11:45 <mps> looked yesterday and didn't noticed 'rsync' on some of them. Thanks for pointing me again
2019-08-02 08:11:57 <danieli> `rsync -avz rsync://mirror.something.tld/alpine/ mirror-path-locally'
2019-08-02 08:12:00 <danieli> :) no worries
2019-08-02 08:12:26 <danieli> you can also do --bwlimit=<KBps>
2019-08-02 08:12:31 <mps> multitasking as usual :D
2019-08-02 08:12:48 <danieli> who, me?
2019-08-02 08:12:50 <mps> yes, I know rsync and use it much for years
2019-08-02 08:12:58 <danieli> yeah me too, it's practically in muscle memory
2019-08-02 08:13:26 <mps> no, multitasking is not good for me, I overlook much fine points
2019-08-02 08:13:52 <danieli> oh yeah, i prefer to focus, but can multitask <= ~4 tasks and do it pretty well
2019-08-02 08:14:54 <mps> meh, maybe it have relation with number of earth moved around sun I remember ;-)
2019-08-02 08:15:30 <danieli> I'm in my early 20s and sometimes struggle pretty badly with my short-term memory, so don't feel bad :P
2019-08-02 08:16:15 <mps> heh, I don't feel bad, just trying to make joke in my bad English
2019-08-02 08:16:40 <danieli> and I'm going along with it
2019-08-02 08:17:18 <mps> thanks for encouraging me
2019-08-02 08:54:23 <jnt> Hi, I am trying to install alpine on qemu-riscv64 from this repo: https://mirror.sr.ht/alpine/main/riscv64/ but the APKINDEX seems to be missing entries for some packages so I cannot install anything due to apk complaining about missing dependencies, can I somehow regenerate it from the apks?
2019-08-02 10:13:28 <danieli> jnt: you can ask ddevault in #alpine-linux :)
2019-08-02 10:19:54 <maxice8> openjdk7 on 3.9 is failing, a lot
2019-08-02 10:33:59 <maxice8> uhh
2019-08-02 10:34:08 <maxice8> i think x86 and x86_64 edge are stuck in python3 test_socket
2019-08-02 13:38:55 <kr0k0> Hi guys
2019-08-02 13:40:11 <kr0k0> Could someone backport pr9551 to 3.10 please?
2019-08-02 13:43:28 <PureTryOut[m]> Hmm about RISC-V, any chance of making that a properly supported arch on Alpine?
2019-08-02 13:44:44 <danieli> given active maintainers / people familiar with it and the infrastructure, i don't see why not
2019-08-02 14:02:30 <maxice8> hey
2019-08-02 14:02:35 <maxice8> x86 and x86_64 builders are stuck on python3 test_socket
2019-08-02 16:07:18 <danieli> I got four raspberry pi 4 4gb btw
2019-08-02 16:07:24 <danieli> if any of the core devs want one to test stuff on
2019-08-02 16:07:30 <danieli> (remotely)
2019-08-02 16:27:41 <andypost[m]> Commit from pr9815 needs backport to 3.10
2019-08-02 16:55:29 <PureTryOut[m]> Could anybody merge https://lists.alpinelinux.org/~alpine/aports/%3C20190729215837.17658-1-bribbers%40disroot.org%3E and https://lists.alpinelinux.org/~alpine/aports/%3C20190729215837.17658-3-bribbers%40disroot.org%3E?
2019-08-02 16:59:19 <danieli> lgtm ^
2019-08-02 17:07:17 <maxice8> x86 and x86_64 builders are stuck on python3 test_socket
2019-08-02 17:07:23 <danieli> again or still?
2019-08-02 17:07:47 <maxice8> still
2019-08-02 17:07:49 <danieli> i wonder if we can hatch a good way to detect when they're stuck and retry N times / continue
2019-08-02 17:08:15 <maxice8> Void Linux's buildbot kills itself after 144000 (i think) seconds without output
2019-08-02 17:08:23 <Cogitri> I guess we could check if there hasn't been output in the last N secs
2019-08-02 17:08:24 <Cogitri> Ah yes
2019-08-02 17:08:37 <maxice8> maybe put an extra 0 there
2019-08-02 17:11:06 <danieli> that number sans the extra zero is 40 hours
2019-08-02 17:11:18 <danieli> an extra zero is 400
2019-08-02 17:11:39 <maxice8> Then yes i did put an extra 0 there
2019-08-02 17:11:41 <mps> he meant zero in front :D
2019-08-02 17:11:46 <danieli> hahahah
2019-08-02 17:12:08 <danieli> but yeah, that would be an idea, but the build system should be revamped in its entirety
2019-08-02 17:12:36 <danieli> i wish we had more elixir programmers, it would be well suited for highly concurrent systems
2019-08-02 17:14:04 <Cogitri> Or maybe that one lang whose motto is "fearless concurrency" :P
2019-08-02 17:15:39 <mps> 'microservices done right' lang
2019-08-02 17:31:21 <danieli> ha
2019-08-02 17:31:31 <danieli> don't need fear when you deal with errors in a sane way
2019-08-02 17:32:05 <Cogitri> As long as sane isn't UB that's good :P
2019-08-02 17:39:11 <danieli> UB?
2019-08-02 18:00:57 <Cogitri> Undefined Behaviour
2019-08-02 18:02:41 <clandmeter> Utterly bullshit
2019-08-02 18:03:30 <Cogitri> Heh
2019-08-02 18:03:30 <Cogitri> Also fitting
2019-08-02 18:03:46 <maxice8> clandmeter: :D please help x86 x86_64 and armv7 are stuck on python3 test
2019-08-02 18:03:56 <clandmeter> I can't
2019-08-02 18:04:24 <clandmeter> Don't have access to x86 builders
2019-08-02 18:04:41 <maxice8> oh well
2019-08-02 18:04:57 <clandmeter> Ping _ikk_
2019-08-02 18:05:11 <clandmeter> _ikke_
2019-08-02 18:05:25 <danieli> yeah no, luckily erlangers are fairly focused on correctness
2019-08-02 18:05:27 <danieli> for better or worse
2019-08-02 18:07:43 <Cogitri> Yup, heard some nice things some Erlang and Elixir
2019-08-02 18:08:33 <mps> for better, I would say. correct work is more important than speed or feature
2019-08-02 18:09:42 <Cogitri> Yup, hopefully langs like Erlang/Elixir and Rust will keep growing while C and friends slowly declines
2019-08-02 18:09:59 <mps> I like erlang although I didn't used in any project, just read a little about it and looked a little in syntax
2019-08-02 18:11:13 <mps> though I think correctness is 'in programmer'
2019-08-02 18:13:00 <mps> but we are OT
2019-08-02 18:15:57 <_ikke_> clandmeter: pong
2019-08-02 18:19:34 <clandmeter> Builders
2019-08-02 18:20:09 <_ikke_> What's with them
2019-08-02 18:20:21 <maxice8> stuck on python3's test_socket for a few hours
2019-08-02 18:23:57 <_ikke_> x86* builders fixed
2019-08-02 18:28:14 <maxice8> thank you :D
2019-08-02 18:29:46 <_ikke_> What packet was it stuck on?
2019-08-02 18:29:58 <maxice8> packet ?
2019-08-02 18:30:05 <_ikke_> package*
2019-08-02 18:30:05 <danieli> package?
2019-08-02 18:30:23 <maxice8> python=3.7.4-r0
2019-08-02 18:32:27 <_ikke_> Ok, it looks like it still finished building it
2019-08-02 18:32:41 <maxice8> yes, test was killed it continued building
2019-08-02 18:32:49 <_ikke_> nod
2019-08-02 18:33:04 <_ikke_> Not sure if that's good or not
2019-08-02 18:33:06 <maxice8> lua-dbi failed now :D
2019-08-02 18:34:24 <_ikke_> checksum mismatch
2019-08-02 18:34:53 <danieli> I'm seeing a segfault in node-rdkafka with something relating to initializing ssl context (libssl)
2019-08-02 18:35:06 <danieli> it's cpp and i haven't dug very deep
2019-08-02 18:37:05 <danieli> wonder if it's building against a bundled librdkafka and not ours
2019-08-02 18:37:28 <danieli> we don't seem to have any patches for it though
2019-08-02 18:40:36 <_ikke_> lua-dbi verifies locally for me
2019-08-02 18:41:08 <maxice8> same
2019-08-02 18:41:15 <_ikke_> I restarted it
2019-08-02 18:53:39 <_ikke_> It succeeded now
2019-08-02 18:54:55 <maxice8> armv7 is also stuck
2019-08-02 18:56:02 <_ikke_> Unstucked
2019-08-02 18:58:13 <maxice8> ty
2019-08-02 21:29:58 <maxice8> Hey i need to print a message to the user when he is upgrading from version X to version Y
2019-08-02 21:30:05 <maxice8> version Y has a CVE fix that requires manual intervention
2019-08-02 21:32:28 <PureTryOut[m]> Do this but in a .post-upgrade script. https://git.alpinelinux.org/aports/tree/community/openrct2/openrct2.post-install#n3
2019-08-02 21:32:51 <mps> yes, $pgname.post-upgrade
2019-08-02 21:33:11 <mps> s/pgname/pkgname/
2019-08-02 21:33:11 <alpine-meetbot> mps meant to say: yes, $pkgname.post-upgrade
2019-08-02 21:35:25 <maxice8> Done, thanks
2019-08-02 23:50:15 <clandmeter> its actually not a good option
2019-08-02 23:50:51 <clandmeter> those scripts are not made for printing information
2019-08-02 23:54:44 <mps> yes, but I think there are some that echoes info to users
2019-08-02 23:56:36 <clandmeter> yes but its not the way to do it. but there is still no function in place to handle it properly.
2019-08-02 23:57:43 <mps> apk can make coffee but don't have option to inform user in some actions ;-)
2019-08-03 00:02:36 <maxice8> clandmeter: is there a better place to do it?
2019-08-03 00:05:14 <mps> I suspect, but after third glass of red wine and trying to build upgrade to llvm-8.0.1 on third arch I can be corrected :-)
2019-08-03 00:07:39 <mps> maxice8: thanks for introducing me to 'zola', finally I can make web pages with markdown
2019-08-03 00:08:15 <clandmeter> maxice8: not really a solution
2019-08-03 00:08:27 <clandmeter> but what we have agreed on befrore was to use:
2019-08-03 00:08:39 <maxice8> There is also Hugo if you're a gopher
2019-08-03 00:08:50 <clandmeter> $pkgdir"/usr/share/doc/$pkgname/README.alpine
2019-08-03 00:09:09 <mps> no, I tried hugo but zola is better for me
2019-08-03 00:09:26 <clandmeter> the idea was to let apk do something with them post install of all pkgs.
2019-08-03 00:09:43 <clandmeter> so just before apk exists
2019-08-03 00:10:06 <maxice8> clandmeter: I'll do the README thing
2019-08-03 00:10:06 <clandmeter> so one could enable --quiet to disable it
2019-08-03 00:10:16 <maxice8> Is It written anywhere?
2019-08-03 00:10:19 <clandmeter> but i think it never got added
2019-08-03 00:10:59 <clandmeter> some apkbuilds used it
2019-08-03 00:11:08 <clandmeter> but only limited
2019-08-03 00:11:21 <clandmeter> not sure if there was ever an issue created for it.
2019-08-03 00:11:27 <maxice8> I'll write it in the wiki
2019-08-03 00:11:50 <clandmeter> but it souldnt be to hard to implement
2019-08-03 00:12:05 <clandmeter> we should make an issue and tag it to fabled.
2019-08-03 00:13:00 <clandmeter> maxice8: another issue with this is, you will need docs installed.
2019-08-03 00:43:41 <maxice8> clandmeter: that is very suboptimal
2019-08-03 00:44:19 <maxice8> so now people upgrading to pdns-4.1.11 will be vulnerable even though our secfixes say otherwise :D
2019-08-03 04:13:39 <_ikke_> apk-tools has it's own project on gitlab
2019-08-03 06:07:17 <tcely> maxice8: would it be possible to use disable instead of limit for removing architecture? Reading limit / enable is a little irksome.
2019-08-03 07:30:53 <mps> tcely: I asked him to do this before but he refused :-(
2019-08-03 07:34:05 <mps> and seeing him using 'enable' when he 'unlimit' (actually enable) pkg for some archicteture looks funny
2019-08-03 10:05:41 <mps> anyone have good/proper x86 machine to test llvm 8.0.1 upgrade, it fails in my lxc x86 with 'traps: lli[20949] trap invalid opcode'
2019-08-03 10:06:05 <Cogitri> Oh, they did release 8.0.1 now?
2019-08-03 10:06:35 <mps> I suspect container is not working well, because I sucessfully build it on armv7 aarch64 and x86_64 lxc's
2019-08-03 10:07:40 <mps> yes, it is released some time ago
2019-08-03 10:08:01 <mps> here is the patch http://tpaste.us/7v5O
2019-08-03 10:08:12 <mps> git diff, to be precise
2019-08-03 10:08:15 <Cogitri> Oh, they still had "Current release: 8.0.0" on the website a few days ago so I didn't look into it
2019-08-03 10:08:24 <Cogitri> But I guess that's good when you already worked on it :)
2019-08-03 10:08:50 <Cogitri> I can test in a x86 docker container if that helps
2019-08-03 10:09:26 <mps> probably will help, I have strange issues with my lxc x86 container
2019-08-03 10:09:48 <mps> not only with this pkg, but with some other
2019-08-03 10:10:29 <Cogitri> Okie, will try
2019-08-03 10:10:40 <Cogitri> But brb now, migrating my Matrix server to an Alpine machine
2019-08-03 10:11:05 <mps> Cogitri: thanks, no need to hurry
2019-08-03 10:11:17 <v> hm
2019-08-03 10:11:26 <mps> we have all day to finish it
2019-08-03 10:11:27 <v> Cogitri: are you using synapse?
2019-08-03 10:17:53 <Cogitri> Yup
2019-08-03 10:17:58 <v> huh
2019-08-03 10:18:03 <v> did it compile fine for you?
2019-08-03 10:18:19 <v> Last time I tried I ran into an issue w/ some python module needing glibc specific stuff
2019-08-03 10:18:24 <Cogitri> Currently am in the process of building it from pr9823
2019-08-03 10:18:26 <v> but it's been a hot minute
2019-08-03 10:18:42 <Cogitri> And it worked fine for me on Void musl
2019-08-03 10:19:01 <mps> Cogitri: btw, looks like llvm is moving development to github
2019-08-03 10:19:03 <v> oh hey that's an idea, use system py3 modules
2019-08-03 10:19:18 <v> sweet
2019-08-03 10:19:22 <Cogitri> mps: Yup, they've been migrating from svn to git for dome time now
2019-08-03 10:19:24 <Cogitri> (luckily)
2019-08-03 10:20:22 <mps> anyone of matrix-ers tried to build 'ruma' matrix server on alpine
2019-08-03 10:21:27 <Cogitri> Sounds interesting, but it's still in its pretty early stages
2019-08-03 10:22:13 <mps> it is written in rust, because that I keep it on my radar
2019-08-03 10:22:37 <Cogitri> Yup
2019-08-03 10:23:15 <mps> and it is named according city where I live :-)
2019-08-03 10:40:53 <PureTryOut[m]> Ruma is still quite WIP
2019-08-03 10:41:10 <PureTryOut[m]> I have yet to try anything other than Synapse
2019-08-03 10:41:22 <PureTryOut[m]> It's promising though, just as Construct
2019-08-03 10:42:20 <PureTryOut[m]> I should see if I can get that one compiling on Alpine
2019-08-03 10:45:13 <mps> PureTryOut[m]: thanks, and please inform me of your results
2019-08-03 12:39:59 <Cogitri> And back, gonna test llvm now, mps
2019-08-03 12:40:31 <mps> nice, I prepared proper patch in meantime
2019-08-03 12:42:22 <mps> Cogitri: http://tpaste.us/1nM4
2019-08-03 12:42:28 <Cogitri> Thanks
2019-08-03 12:43:02 <mps> thank you, I built crystal 0.30.0 with it on x86_64 in meantime
2019-08-03 12:43:54 <mps> now I have to try to learn how to post MR to gitlab.a.o with 'lab' utility
2019-08-03 12:45:26 <maxice8> some do
2019-08-03 12:45:26 <Cogitri> Oh, we do MRs already?
2019-08-03 12:45:27 <maxice8> no CI though so might as well git send-email to sourcehut
2019-08-03 12:46:25 <Cogitri> Oh, I'll stay with GH for now then, thanks for the info
2019-08-03 12:46:31 <Cogitri> And no thanks to email workflow :P
2019-08-03 12:47:55 <mps> maxice8: also send-email doesn't haave CI
2019-08-03 13:17:24 <PureTryOut[m]> Not yet afaik
2019-08-03 13:17:33 <PureTryOut[m]> I saw ddevault messing around with it iirc
2019-08-03 13:18:38 <PureTryOut[m]> cogitri: email workflow is lovely though, can all be done in terminal :D https://git-send-email.io
2019-08-03 13:23:01 <ddevault> yeah I should have CI over email working soon enough
2019-08-03 13:26:27 <Cogitri> mps: llvm8 just passed for me on x86
2019-08-03 13:37:58 <mps> Cogitri: thanks, now I can try to make MR
2019-08-03 13:38:21 <mps> so, my x86 lxc is broken
2019-08-03 13:40:00 <mps> but, ... first going out for a coffee, I'm somewhat sleepy
2019-08-03 16:23:59 <PureTryOut[m]> Can someone with write access to main _please_ merge https://lists.alpinelinux.org/~alpine/aports/%3C20190729215837.17658-1-bribbers%40disroot.org%3E?
2019-08-03 16:24:00 <PureTryOut[m]> And someone with write access to community https://lists.alpinelinux.org/~alpine/aports/%3C20190729215837.17658-3-bribbers%40disroot.org%3E
2019-08-03 16:31:16 <mps> PureTryOut[m]: do they need to be applied in order you posted them here
2019-08-03 16:31:35 <PureTryOut[m]> Yes
2019-08-03 16:31:43 <PureTryOut[m]> They're from the same patchset
2019-08-03 16:32:19 <mps> sorry then, I cannot push to main
2019-08-03 17:23:41 <mps> ldd in git commit d4a7955cc72b9395779c20755df88f983763c43b to musl have problem if invoked with --version (possible other --prefixes)
2019-08-03 17:24:25 <mps> it have extra '--'
2019-08-03 17:25:16 <mps> should it be 'exec /lib/ld-musl-aarch64.so.1 --list "$@"' instead of 'exec /lib/ld-musl-aarch64.so.1 --list -- "$@"'
2019-08-03 18:11:31 <maxice8> Does more than 1 # Maintainer: work ?
2019-08-03 18:12:11 <mps> maxice8: I don't think
2019-08-03 18:14:53 <mps> look at this MR https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4/diffs#dfdb6649eefa1ed433bbaa2bca6f57d0b92872b7_0_136
2019-08-03 18:21:40 <maxice8> openjdk9 on stable-3.9 was missing a patch file that escaped backporting
2019-08-03 18:29:25 <mps> Cogitri: here is MR for llvm8 upgrade https://gitlab.alpinelinux.org/alpine/aports/merge_requests/15
2019-08-03 21:05:06 <maxice8> Does more than 1 # Maintainer: work ?
2019-08-03 21:34:43 <mps> maxice8: you can try but I think it is not 'allowed' by unwritten rules
2019-08-03 21:35:20 <mps> although I think it should be
2019-08-03 21:35:38 <mps> team maintaining pkg's for example
2019-08-03 21:44:03 <mps> ddevault: this new testing/openhmd pkg needs meson in makedepends
2019-08-03 21:44:25 <ddevault> thanks mps, I'll fire off another patch
2019-08-03 21:45:03 <ddevault> patches away
2019-08-03 21:45:05 <ddevault> sorry for the trouble
2019-08-03 21:45:15 <mps> np
2019-08-03 21:45:46 <mps> we all make mistakes, especially if we are tired or overloaded
2019-08-03 21:46:14 <ddevault> or bored in an airport killing time for a delayed flight, in my case
2019-08-03 21:54:54 <danieli> maxice8: afaik no, only contributors
2019-08-03 21:54:59 <danieli> contributor*
2019-08-03 22:58:33 <KH405> umm ... that pango update didin't fix shit :(
2019-08-03 23:00:15 <danieli> pretty sure the pango developers never intended to fix it
2019-08-03 23:00:26 <KH405> Yeah, that's what I read too ...
2019-08-03 23:00:38 <KH405> I had hopes though
2019-08-03 23:03:19 <KH405> How do you fix it if they won't fix it then?
2019-08-03 23:15:37 <danieli> you don't
2019-08-03 23:15:45 <danieli> you downgrade, i suppose
2019-08-03 23:18:26 <ddevault> what broke?
2019-08-03 23:22:54 <KH405> Can't print any character that used a certain font AFAIK
2019-08-03 23:23:16 <KH405> pango stopped supporting it
2019-08-03 23:27:07 <ddevault> lovely
2019-08-03 23:34:32 <KH405> Yes
2019-08-03 23:34:36 <KH405> Nightmare ...
2019-08-03 23:34:42 <KH405> Can't use GUI at all
2019-08-03 23:45:06 <danieli> yup, and they seem to have no intention of fixing it whatsoever, their attitude is pretty much "it's old, update instead of complaining"
2019-08-03 23:46:03 <KH405> ... It's the default
2019-08-03 23:57:01 <danieli> there's nothing we can do about it except downgrade
2019-08-03 23:57:08 <danieli> i'm sure i3 or awesome has an issue about it
2019-08-04 00:00:34 <KH405> What do you think will happen next&
2019-08-04 00:00:46 <KH405> Can someone fix it upstream or something?
2019-08-04 00:04:14 <danieli> check for existing issues about it upstream, if there is none, create one
2019-08-04 00:42:28 <KH405> So waiting is the best COA ?
2019-08-04 12:11:32 <Guest55> ping @Cogitri maxice8
2019-08-04 18:19:15 <maxice8> _ikke_: shellcheck failing on everything but x86_64 due to cabal and ghc
2019-08-04 18:20:26 <_ikke_> maxice8: ugh, thanks
2019-08-04 18:21:06 <_ikke_> Was submitted via GL, so no extensive CI (yet)
2019-08-04 18:23:48 <maxice8> _ikke_: same thing with sr.ht
2019-08-04 19:43:21 <mps> that is why I test on at least two arch's before sending patch
2019-08-04 19:44:53 <Cogitri> Although having just having CI is pretty to verify it
2019-08-04 19:44:54 <Cogitri> Also, not sure if the message got through, llvm worked for me on x86, mps
2019-08-04 19:47:18 <mps> Cogitri: yes, I read it, and sent thanks to you, probably matrix missed it
2019-08-04 19:47:30 <mps> I posted MR yesterday
2019-08-04 19:47:42 <mps> Cogitri: here is MR for llvm8 upgrade https://gitlab.alpinelinux.org/alpine/aports/merge_requests/15
2019-08-04 20:20:19 <Cogitri> Ah good 👍
2019-08-04 21:20:17 <clandmeter> hmm
2019-08-04 21:20:21 <clandmeter> something happend with pango?
2019-08-04 21:30:10 <Cogitri> Yes
2019-08-04 21:30:23 <Cogitri> The 1.44.x update removed support for rather old fonts since they switched from freetype2 to harfbuzz
2019-08-04 21:31:31 <Cogitri> Which doesn't support them
2019-08-04 21:31:32 <Cogitri> So all fonts have to be converted to ttf or similar
2019-08-04 21:31:34 <clandmeter> things are breaking
2019-08-04 21:31:40 <clandmeter> not sure its related to fonts
2019-08-04 21:32:07 <Cogitri> I don't know about breakage other than what I've mentioned
2019-08-04 21:33:57 <clandmeter> looks like missing headers
2019-08-04 23:03:14 <maxice8> clandmeter: 1.44.3 added some headers back (pango-ot)
2019-08-04 23:03:46 <maxice8> pr9861
2019-08-04 23:07:06 <maxice8> There is a lot of main/ PRs as well :D
2019-08-04 23:12:02 <mps> yes, I'm mostly work on pkg's in main and don't send much of them because always have to ask someone to push, and I don't like to bother core devs much
2019-08-04 23:13:20 <mps> only post those which I think are important
2019-08-04 23:20:09 <maxice8> Liking or not (most) those changes need to be merged, specially security fixes like the ansible ones
2019-08-05 06:39:44 <tmlind> hey all, just lurking around for fun linux stuff :)
2019-08-05 07:48:32 <clandmeter> maxice8: i have .3 local but it didnt fix it.
2019-08-05 07:48:39 <clandmeter> seems they moved some headers
2019-08-05 07:48:45 <clandmeter> and they are not automatically included
2019-08-05 07:49:05 <clandmeter> looks like fedora is still on older pango.
2019-08-05 08:53:44 <ncopa> morning
2019-08-05 08:53:49 <ncopa> im continue work on chromium upgrade
2019-08-05 10:01:14 <Cogitri> Good luck
2019-08-05 10:17:23 <clandmeter> fabled: you around?
2019-08-05 10:17:31 <fabled> clandmeter, hey
2019-08-05 10:17:34 <clandmeter> hi
2019-08-05 10:18:00 <clandmeter> did we ever create something for post install/upgrade information hooks?
2019-08-05 10:18:02 <clandmeter> in apk
2019-08-05 10:20:03 <fabled> we have not changed anything there recently
2019-08-05 10:20:06 <clandmeter> i think we have some format to have doc..../README.alpine but no interface in apk to handle it? and also no version aware functions.
2019-08-05 10:49:03 <ncopa> clandmeter and I are upgrading gitlab. it will go down for a few minutes
2019-08-05 12:52:02 <clandmeter> the end of the world is coming, somebody added synapse to aports.
2019-08-05 12:53:26 <maxice8> clandmeter: i did
2019-08-05 12:55:32 <clandmeter> i know
2019-08-05 13:06:45 <maxice8> ncopa: got PRs for main/py-django
2019-08-05 13:38:55 <Cogitri> clandmeter: My server still lives with synapse, huh :P
2019-08-05 14:29:01 <maxice8> and for subversion as well :D all secfixes!
2019-08-05 15:15:22 <clandmeter> "My server still lives" thats says enough :p
2019-08-05 15:26:04 <Cogitri> Heh
2019-08-05 15:36:47 <Cogitri> ncopa: I can steal issues about CVEs that are assigned to you on GL if you aren't working on them, right?
2019-08-05 18:30:27 <maxice8> ddevault: https://lists.alpinelinux.org/~alpine/aports/patches/2888 the last 3 comments were made to the same line when they were actually meant one for each instance
2019-08-05 19:00:56 <MartijnBraam> so I'm having wifi issues in postmarketOS since networkmanager in alpine was changed to be hardcoded to iwd
2019-08-05 19:01:07 <MartijnBraam> is there any reason that isn't done in a subpackage or something?
2019-08-05 19:03:12 <maxice8> According to the commit wpa_supplicant was broken for some time.
2019-08-05 19:03:14 <MartijnBraam> yeah postmarketOS has a patch for that, just add -u to the wpa_supplicant command line
2019-08-05 19:03:15 <MartijnBraam> the issue is that iwd doesn't support nearly as much wifi chipsets as wpa_supplicant
2019-08-05 19:04:59 <Cogitri> Well, you're welcome to upstream that patch
2019-08-05 19:04:59 <MartijnBraam> but if the iwd.conf file was only added when `iwd` is actually installed then it wouldn't be an issue
2019-08-05 19:05:00 <Cogitri> But as long as wpa_supplicant is broken in Alpine w/ NM I don't see us changing back to it
2019-08-05 19:05:00 <MartijnBraam> or if the file was called something with a number so it can be overriden without giving the override a stupid name
2019-08-05 19:05:01 <Cogitri> But the thing with the number is valid, will change that, sorry about that
2019-08-05 19:05:01 <MartijnBraam> we decided to not push that to alpine because by adding -u to wpa_supplicant the wpa_supplicant behavior changes and it won't work without networkmanager anymore
2019-08-05 19:05:39 <MartijnBraam> because -u enables the dbus interface for wpa_supplicant and makes it ignore it's config files
2019-08-05 19:05:40 <Cogitri> Well, I'll number the config file then, but I won't change back to wpa_supplicant by default
2019-08-05 19:06:07 <MartijnBraam> what about adding iwd.conf in a subpackage that's install_if="networkmanager iwd"?
2019-08-05 19:07:43 <Cogitri> Not really interested in that because that'll leave the majority of NM users with broken WiFi anyway
2019-08-05 19:07:43 <MartijnBraam> which also neatly removes the iwd dependency for if you have a non-wifi system like a server
2019-08-05 19:07:44 <Cogitri> Broken by default isn't really satisfactory to me :/
2019-08-05 19:07:44 <MartijnBraam> hmm right
2019-08-05 19:08:03 <MartijnBraam> another fix would be having 2 init scripts for wpa_supplicant, one that runs it with dbus and one that runs it with config files
2019-08-05 19:08:12 <Cogitri> <MartijnBraam "which also neatly removes the iw"> That's a fair point though, but doing smth like a networkmanager-wifi package which does nothing but depend on iwd sounds a bit stupid, recommendations support (or something similar in apk) would be the way to go with this
2019-08-05 19:08:33 <MartijnBraam> yeah recommendations would be nice
2019-08-05 19:08:48 <Cogitri> <MartijnBraam "another fix would be having 2 in"> That sounds a annoying to be honest, other distros support it without messing around with this too
2019-08-05 19:09:05 <MartijnBraam> other distro's have a more integrated config system for this stuff
2019-08-05 19:09:31 <MartijnBraam> or just have wpa_supplicant in dbus mode and hope people know what they're doing when needing wpa_supplicant without dbus
2019-08-05 19:09:40 <MartijnBraam> or have systemd with overridable services
2019-08-05 19:10:37 <MartijnBraam> hmm or have it start in dbus mode unless the config file exists
2019-08-05 19:10:51 <Cogitri> That sounds like the best way to go about thid
2019-08-05 19:11:03 <Cogitri> s/thid/this/
2019-08-05 19:11:03 <alpine-meetbot> Cogitri meant to say: That sounds like the best way to go about this
2019-08-05 19:11:38 <MartijnBraam> lol that bot
2019-08-05 19:11:50 <MartijnBraam> I'll create a MR/PR/email-list-patch something for it
2019-08-05 19:13:42 <Cogitri> If you're making a Github PR feel free to ping me
2019-08-05 19:42:52 <Cogitri> Left a few comments on thay
2019-08-05 19:44:55 <MartijnBraam> heh, I just did `git revert` on the iwd commit, so these are basically issues that were already there :P
2019-08-05 19:46:56 <mps> MartijnBraam: iwd or NM commit?
2019-08-05 19:47:24 <Cogitri> Right, only saw that now in the PR, reviewed via phone
2019-08-05 19:47:29 <MartijnBraam> mps: https://github.com/alpinelinux/aports/commit/54ad8af826871c04215055e2e60d811581742f21
2019-08-05 19:47:33 <Cogitri> Could you please quote pkgdir again though? :)
2019-08-05 19:47:45 <MartijnBraam> yeah I'll clean it up a bit
2019-08-05 19:47:48 <Cogitri> Thank you
2019-08-05 19:48:02 <mps> ah, so this commit is on NM, now iwd pkg
2019-08-05 19:48:36 <MartijnBraam> this will also clean postmarketOS a bit because we now have a post-install script that patches the wpa_supplicant service and creates an empty config file :P
2019-08-05 19:51:57 <Cogitri> Oh
2019-08-05 19:51:58 <Cogitri> Well, thanks for bringing this upstream to us :)
2019-08-05 19:51:58 <MartijnBraam> I updated the PR :)
2019-08-05 19:53:58 <mps> would anyone with main push right look at MR for llvm8 upgrade to 8.0.1 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/15
2019-08-05 19:54:15 <MartijnBraam> well when fixing that in postmarketOS I just thought it was this way because nobody used networkmanager on alpine
2019-08-05 19:54:17 <Cogitri> It was more because no one cared about making wpa_supplicant work with it
2019-08-05 19:54:42 <mps> Cogitri: and I tested it on four arch's i.e. x86_64, x86, aarch64 and armv7
2019-08-05 19:55:39 <mps> I need this to test crystal upgrade to 0.30.0
2019-08-05 19:58:47 <Cogitri> 👍
2019-08-05 22:47:35 <maxice8> I worked on a few initscripts from busybox-initscripts pr9895
2019-08-06 06:26:24 <ncopa> Cogitri: sure! I appreciate help
2019-08-06 14:35:34 <tcely> Please look over pr9921 if you have a few minutes
2019-08-06 14:46:08 <muhaha> is there any package that can output SW info in json format out of the box?
2019-08-06 14:52:25 <QQuo_> If i should migrate a package to python3 (https://wiki.alpinelinux.org/wiki/TODO:py3_packages) i should submit the pullrequest to master, right?
2019-08-06 14:52:38 <maxice8> yes
2019-08-06 14:59:56 <fcolista> muhaha, SW stands for? Software?
2019-08-06 15:00:23 <muhaha> well, at least some basic os stats
2019-08-06 15:00:27 <muhaha> yes
2019-08-06 15:01:56 <maxice8> _ikke_: atools 18.8
2019-08-06 15:03:05 <jokke> hey
2019-08-06 15:03:32 <jokke> i heard of the --virtual option for apk add but i'm not sure how to use it
2019-08-06 15:03:52 <jokke> basically i want to install the dependencies of a package without actually installing the package itself
2019-08-06 15:04:31 <maxice8> released, sadly no longer using codenames made by your sounds
2019-08-06 15:22:31 <mps> jokke: as I wrote on #crystal-lang, you can create virtual package with list of apk's you want to install. virtual pkg is just name, it doesn't contains any 'real' apk
2019-08-06 15:23:14 <jokke> mps: ah i see
2019-08-06 15:23:42 <jokke> so the syntax is: `apk add --virtual crystal-deps gcc llv5-libs ...`
2019-08-06 15:23:43 <jokke> ?
2019-08-06 15:23:47 <_ikke_> abuild uses it to create a virtual package that installs all the dependencies needed to build a certain package
2019-08-06 15:23:56 <_ikke_> jokke: yes
2019-08-06 15:24:01 <jokke> 👍
2019-08-06 15:24:04 <jokke> great!
2019-08-06 15:24:09 <jokke> thanks
2019-08-06 15:24:27 <mps> you're welcome :)
2019-08-06 15:25:31 <mps> jokke: small note, crystal 0.30.0 will use llvm8
2019-08-06 15:26:01 <mps> when I fix tests (specs) build on aarch64
2019-08-06 15:26:21 <jokke> ah
2019-08-06 15:26:26 <jokke> alright
2019-08-06 15:26:44 <mps> it is ready for x86_64
2019-08-06 15:40:08 <QQuo_> Could someone please review my changes before making a pullrequest, my very first time.....
2019-08-06 15:40:10 <QQuo_> https://github.com/alpinelinux/aports/compare/master...johngunnarsson:master
2019-08-06 15:43:21 <Cogitri> Just make a PR, that makes it easier to review it and track progress on it
2019-08-06 15:43:59 <tcely> You can make a draft first if you like.
2019-08-06 15:44:27 <QQuo_> Okay, will make some more functional tests before that, just want to be sure.
2019-08-06 15:44:57 <QQuo_> Should I also post to the mailinglist aports?
2019-08-06 15:45:47 <_ikke_> No, just a PR is enough
2019-08-06 15:47:01 <QQuo_> great, se you later
2019-08-06 19:01:16 <mps> ncopa: regarding git commit d4a7955cc72b9395779c20755df88f983763c43b which change /usr/bin/ldd I talked with dalias few days ago and he told me that it should be changed from 'exec /lib/ld-musl-x86_64.so.1 --list -- "$@"' to 'exec /lib/ld-musl-x86_64.so.1 --list "$@"', i.e. remove ' --'
2019-08-06 19:02:33 <mps> I tested changed version and didn't noticed (yet, to be clear) any issue
2019-08-06 19:03:00 <mps> but want to hear from you and other what do you think about that
2019-08-06 19:05:49 <tcely> It should be fine. If you want to be paranoid about it you can filter the flags allowed.
2019-08-06 19:07:41 <mps> tcely: don't understand. fine as it is now or fine with removal of ' --'
2019-08-06 19:07:59 <tcely> fine with the removal
2019-08-06 19:08:15 <mps> ah, thanks for explanation
2019-08-06 19:14:45 <QQuo_> tcely, i squashed the two commits for the py-gpiozero, was that what you wanted?
2019-08-06 19:14:59 <tcely> Which PR?
2019-08-06 19:15:14 <QQuo_> https://github.com/alpinelinux/aports/pull/9927
2019-08-06 19:16:13 <tcely> QQuo_: lgtm
2019-08-06 19:19:57 <QQuo_> god damn, i pressed the "close pull request" button by mistake in the triage ui, sorry :(  i reopened it again
2019-08-06 19:20:48 <QQuo_> thought i closed the sidebar
2019-08-06 19:22:03 <tcely> No problem. That button is too handy in my opinion.
2019-08-07 07:07:22 <ncopa> morning
2019-08-07 07:07:28 <ncopa> im working on the musl CVE
2019-08-07 07:30:15 <mps> ncopa: good morning! what you think about my last night post regarding ldd bug
2019-08-07 07:38:20 <ncopa> mps: i havent had time to look or think about it yet
2019-08-07 07:41:18 <mps> tcely and dalias agreed it is ok to remove ' --' from it, in my tests I didn't had any issue (yet, to be precise)
2019-08-07 07:44:17 <mps> anyway, I will create MR on gitlab.a.o, to not be forgotten
2019-08-07 07:46:37 <mps> iwd 0.19 with ell 0.21 got dhcp client, had to patch them for alpine but it works :-)
2019-08-07 08:23:29 <ncopa> speaking of iwd, i didnt get it to work on my macbook
2019-08-07 08:23:39 <ncopa> so i have switched bak to wpa_supplicant
2019-08-07 08:24:45 <mps> alpine on macbook, I presume
2019-08-07 08:24:49 <ncopa> yes
2019-08-07 08:25:10 <mps> is the wifi card supported by iwd
2019-08-07 08:25:24 <ncopa> how do i check that?
2019-08-07 08:25:53 <mps> I think some cards are not supported or have issues. what model is your one?
2019-08-07 08:25:53 <ncopa> its currently installing macos update, so it will take another 15-20 mins before i can try again
2019-08-07 08:26:14 <ncopa> 13" macbook pro late 2015 iirc
2019-08-07 08:26:54 <mps> I didn't tested on macbook's
2019-08-07 08:27:12 <ncopa> it worked on my desktop workstation
2019-08-07 08:27:37 <mps> will ask my son to borrow me his macbook (also old one) and test it there
2019-08-07 08:28:21 <ncopa> i can check which kernel module it is
2019-08-07 08:28:38 <mps> it worked for me on atheros and two chromebooks
2019-08-07 08:29:12 <ncopa> we need support wpa_supplicant til iwd has more hw support
2019-08-07 08:29:16 <ncopa> ie newer kernel
2019-08-07 08:30:28 <mps> yes, what stopped me to upgrade iwd (push to git.a.o) is failed tests because old linux-headers
2019-08-07 08:31:28 <mps> not sure what to do, wait for kernel upgrade, disable check, or create patch to disable failed tests
2019-08-07 08:32:37 <mps> but, personally I'm satisfied with it, now with ingrained dhcp it is really fast at network setup
2019-08-07 08:33:26 <mps> although have to fix resolvconf, something is buggy around it
2019-08-07 08:33:33 <mps> have to investigate
2019-08-07 08:34:53 <Gottox> x
2019-08-07 08:35:35 <ncopa> y
2019-08-07 08:36:25 <Gottox> well. :D
2019-08-07 08:36:36 <ncopa> sounds like you need change password? :D
2019-08-07 08:36:56 <Gottox> it's fine. I misstyped my pw.
2019-08-07 08:37:09 <ncopa> lol
2019-08-07 08:56:58 <ncopa> mps: the driver on my macbook is brcmfmac
2019-08-07 08:58:36 <mps> aha, will look if I can test it somewhere
2019-08-07 09:00:52 <mps> or ask on #iwd channel, maybe someone there know if that card have issues
2019-08-07 11:28:10 <tmhoang> I frequenly have troubles with openrc not being able to start service with errors : cannot open pid file or pid not found in pid file. On 2 quite identical alpine machines, one can start a service, another can't. Not sure how to debug this.
2019-08-07 11:28:59 <tmhoang> was openvpn, now named.
2019-08-07 11:31:15 <tmhoang> iiuc, it's that the program failed to run and/or exited, thus  there is no pid for openrc to find
2019-08-07 11:32:13 <Cogitri> Switching the services over to supervise-daemon should end the PID trickery (which is kind of terrible anyway), so that seems like the best way forward
2019-08-07 11:40:32 <ncopa> would be good to know what the problem is though
2019-08-07 11:56:37 <clandmeter> tmhoang: do you log rc in debug?
2019-08-07 12:46:01 <Cogitri> PureTryOut: Can we build plasma-nm without libnm-glib?
2019-08-07 12:46:07 <Cogitri> They've removed it with NM 1.20
2019-08-07 12:46:30 <maxice8> mariadb is failing on ppc64le
2019-08-07 12:55:14 <ncopa> im on it
2019-08-07 12:55:27 <maxice8> ty
2019-08-07 13:11:00 <ncopa> \o/
2019-08-07 13:11:06 <ncopa> chromium finally builds
2019-08-07 13:11:10 <maxice8> \o/
2019-08-07 13:11:15 <ncopa> and it appears to actually work
2019-08-07 13:11:26 <maxice8> (\o/)²
2019-08-07 13:11:49 <ncopa> it took me a while to figure out why the APKBUILD built with g++ instead of clang++
2019-08-07 13:12:19 <ncopa> it also seems to fix the annoying tab craches
2019-08-07 13:12:31 <ncopa> so im super happy with this!
2019-08-07 13:12:37 <Cogitri> Nice
2019-08-07 13:12:56 <ncopa> the g++ thing is sort of embarassing :)
2019-08-07 13:14:03 <ncopa> building it on armv7 now
2019-08-07 13:24:27 <ncopa> looks like clang++ is broken on armv7
2019-08-07 13:24:30 <ncopa> ../../v8/src/libplatform/tracing/trace-buffer.h:8:10: fatal error: 'memory' file not found
2019-08-07 13:24:30 <ncopa> #include <memory>
2019-08-07 13:24:30 <ncopa>          ^~~~~~~~
2019-08-07 13:25:05 <Cogitri> Yeaaah, I think we had oddities with Clang on arm* before too :/
2019-08-07 13:25:11 <Cogitri> With webkit2gtk
2019-08-07 13:28:03 <PureTryOut[m]> <Cogitri "PureTryOut: Can we build plasma-"> Maybe? I don't know, haven't tried. I'll see what I can do when I'm back home
2019-08-07 13:28:29 <Cogitri> Thanks
2019-08-07 13:28:41 <Cogitri> I'll work on NM 1.20 later, so no need to hurry too much :)
2019-08-07 13:33:32 <ncopa> hum, simple helloworld.cpp seems to work
2019-08-07 13:33:41 <ncopa> so its something fishy with the chromium build
2019-08-07 13:38:09 <ncopa> i wonder if i should just disable armv7 and armhf til it is sorted out
2019-08-07 13:38:44 <ncopa> i sort of want it upgraded for x86_64
2019-08-07 13:50:15 <ncopa> Cogitri: i suspect it is this change: https://gitlab.alpinelinux.org/alpine/aports/commit/54db62760803072c5308e62d769048d2f50b68be
2019-08-07 13:50:30 <ncopa> which removes the arm triplets
2019-08-07 13:50:58 <ncopa> from 10-add-musl-triples.patch
2019-08-07 14:10:45 <mps> ncopa: D. Kenzion on #iwd told me that the iwd works with brcmfmac
2019-08-07 14:11:33 <mps> i.e. denkenz told me
2019-08-07 14:12:56 <mps> he will test again later to be sure
2019-08-07 14:38:44 <maxice8> PureTryOut: can you take a look at pr9940
2019-08-07 14:53:41 <mps> ncopa: annoying you again, you are maintainer of openresolv pkg. why it puts helper scripts in /usr/lib and not in subdir, /usr/lib/openresolv (or similar) for example
2019-08-07 14:56:28 <mps> resolvconf have this line 'for script in "$LIBEXECDIR"/*; do' and 'LIBEXECDIR=/usr/lib' at the top
2019-08-07 14:56:54 <mps> could we move helper scripts to separate dir?
2019-08-07 15:06:13 <Cogitri> Aren't we moving to using /usr/libexec as libexec anyway?
2019-08-07 15:08:05 <mps> yes, but we also could/should have subdirs for specific pkg's
2019-08-07 15:09:23 <mps> it is bug to have line 'for script in "$LIBEXECDIR"/*; do', imo
2019-08-07 15:09:29 <Cogitri> Yup, should be /usr/libexec/${pkgmanager}
2019-08-07 15:09:48 <Cogitri> Hm, I don't know Makefiles too well, but why?
2019-08-07 15:10:51 <mps> this is not in Makefile, it is in /usr/sbin/resolvconf script
2019-08-07 15:14:46 <Cogitri> Oh
2019-08-07 15:23:48 <Danct12> pr9894, is there anyone taking this?
2019-08-07 15:25:36 <Cogitri> I'm sure it'll be looked at by someone with commit access soon :)
2019-08-07 17:05:00 <tcely> Pr6353 needs some review. How do we handle other CUPS packages? Is _svnNNN ok?
2019-08-07 17:06:48 <mps> hmm, what a strange commit msg: 'new aport by tanertas'
2019-08-07 17:09:08 <maxice8> It isn't, algitbot adds it to tell you who made it
2019-08-07 17:09:29 <maxice8> the commit title is 'testing/splix: new aport'
2019-08-07 17:09:59 <mps> ah, so, algitbot made me grumpy then ;-)
2019-08-07 17:10:18 <mps> didn't noticed that till now
2019-08-07 17:13:56 <mps> let's see what it does for MR's
2019-08-07 17:13:59 <mps> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/16
2019-08-07 17:14:18 <mps> nothing
2019-08-07 17:18:23 <mps> btw, anyone would review this MR, would like to hear your comments is it good how I made it or have to fix my workflow
2019-08-07 17:21:02 <mps> I made it using 'lab' cli, i.e. lab checkout -b branch-name, do the work, git push mps, and at the end 'lab mr create'
2019-08-07 17:21:20 <mps> so, completely from cli
2019-08-07 17:23:32 <tcely> The GL interface is terrible so I'm not sure what that commit looks like. The actual diff lgtm.
2019-08-07 17:25:28 <tcely> btw, removing -- termination allows arguments. It doesn't just allow -- prefixed long options.
2019-08-07 17:25:41 <mps> to me it looks similar to GH, https://gitlab.alpinelinux.org/alpine/aports/merge_requests/16/diffs?commit_id=c9b84b6baf5274c531158a52b4b22f7283776f35
2019-08-07 17:26:18 <mps> tcely: hm, it works for me
2019-08-07 17:27:09 <tcely> Define "it" and "works" then we can argue. ;-)
2019-08-07 17:27:51 <mps> try 'ldd --version'
2019-08-07 17:28:14 <mps> and then remove ' --' and try again
2019-08-07 17:29:47 <tcely> Oh. Yeah, the change is fine. Your commit message is misleading.
2019-08-07 17:29:51 <tcely> https://gitlab.alpinelinux.org/alpine/aports/commit/c9b84b6baf5274c531158a52b4b22f7283776f35.patch
2019-08-07 17:30:12 <tcely> Geez. Finding that URL in GL is a pain.
2019-08-07 17:31:14 <tcely> Anyone have a link to the musl source that parses those arguments?
2019-08-07 17:31:56 <tcely> list help and version work, but it would be nice to know all the accepted options.
2019-08-07 17:32:13 <mps> Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname [args]
2019-08-07 17:32:36 <mps> options comes first
2019-08-07 17:33:18 <mps> actually dalias told me to remove this ' --'
2019-08-07 17:33:59 <tcely> Sure, but options can be -h -? or --help saying prefixed with -- is misleading
2019-08-07 17:34:38 <tcely> -- alone is a trick for option parsers to know when no more options should be allowed
2019-08-07 17:34:55 <mps> ld-musl doesn't accept short options, afaik
2019-08-07 17:35:00 <tcely> A bit like - is a trick to mean read from stdin
2019-08-07 17:35:42 <mps> yes, I don't know for simple and good fix
2019-08-07 17:37:09 <tcely> Even if we are sure libc.so doesn't take short options, -- is used a lot of places and saying that it only affects long options is misleading it would be better to say we want to enable ldd options and leave it at that
2019-08-07 17:38:38 <mps> ok, I accept that my wording of commit msg is not good, but fix solves some issues
2019-08-07 17:39:10 <mps> 
ACTION is bad in writing good commit msg's

2019-08-07 17:39:23 <tcely> Yes, removing -- from that wrapper is the correct change. Just the message needs revision.
2019-08-07 17:39:59 <mps> tcely: please, change it how you think is better
2019-08-07 17:41:02 <mps> I would like to see GL workflow when more people colaborate on MR's
2019-08-07 17:42:09 <tcely> I wish I could. GL won't even let me set my proper email currently.
2019-08-07 17:43:26 <mps> ahm, you are not in member list
2019-08-07 17:44:11 <tcely> "main/musl: fix ldd to accept options"
2019-08-07 17:44:11 <tcely> "Remove '--' to allow passing options"
2019-08-07 17:45:17 <mps> nice, thanks
2019-08-07 17:46:05 <tcely> welcome
2019-08-07 17:50:34 <mps> tcely: btw, get patch from MR is like this: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/16.patch
2019-08-07 17:50:52 <tcely> ty
2019-08-07 17:51:37 <mps> you're welcome
2019-08-08 07:11:02 <ncopa> maxice8: FYI: 756d41d9187e961cfed2a043f6f402049906bf08
2019-08-08 07:13:12 <ncopa> mps: re https://gitlab.alpinelinux.org/alpine/aports/merge_requests/16 as I understand dalias has ACKed that?
2019-08-08 07:14:36 <mps> ncopa: yes, actually he proposed that change, I just follow his advice
2019-08-08 07:15:57 <mps> but I'm not sure if MR in correct form, I mean commit msg. Don't know how to squash it so you are free to recreate it however you like
2019-08-08 07:19:28 <mps> ncopa: https://dev.alpinelinux.org/irclogs/%23alpine-linux-2019-08.log around date 2019-08-03 08:14:44
2019-08-08 07:21:15 <mps> btw, do you read msg's on #iwd, last night one of developers tested brcmfmac with iwd and confirmed it works
2019-08-08 07:21:24 <ncopa> i saw
2019-08-08 07:21:28 <ncopa> i need to respond there
2019-08-08 07:21:34 <ncopa> and test my mabcbook again
2019-08-08 07:21:38 <ncopa> i'll do so soonish
2019-08-08 07:22:23 <mps> heh, sorry for disclose your identity there
2019-08-08 07:42:42 <ncopa> np
2019-08-08 07:42:55 <ncopa> does anyone use -R with abuild?
2019-08-08 07:42:58 <ncopa> abuild -R
2019-08-08 07:43:03 <ncopa> its broken
2019-08-08 07:43:22 <ncopa> i want remove the functionality from abuild
2019-08-08 07:59:48 <rnalrd> i'm not using it
2019-08-08 08:22:46 <Cogitri> I always use abuild -r because otherwise my laptop turns into a starting aircraft :P
2019-08-08 08:23:05 <ncopa> we need to clean up abuild code
2019-08-08 08:23:11 <ncopa> its pretty messy at this point
2019-08-08 08:25:45 <mps> I never used -R, just -r
2019-08-08 10:34:57 <fcolista> re: building environment. We have buildlab, rootbld, docker, lxc, chroot, qemu. Each of this is used/can be used to setup a stable or on-the-fly build environment. I think that would be good to document the various possibilities, along with howto build for different archs
2019-08-08 10:35:05 <fcolista> we have in the wiki:
2019-08-08 10:35:06 <fcolista> https://wiki.alpinelinux.org/wiki/Buildlab
2019-08-08 10:35:32 <fcolista> https://wiki.alpinelinux.org/wiki/Include:Setup_your_system_and_account_for_building_packages
2019-08-08 10:36:22 <fcolista> I use one lxc for each version of alpine
2019-08-08 10:36:29 <fcolista> with aports shared
2019-08-08 10:36:57 <fcolista> and in the containers then I checkout the branch corresponding to lxc alpine version
2019-08-08 10:37:33 <fcolista> anyone has different setup?
2019-08-08 10:37:49 <fcolista> And how do you use it?
2019-08-08 10:39:06 <_ikke_> My setup is similar
2019-08-08 10:41:27 <mps> I use lxc but only edge on 4 arch's, and have 3 real machines for stable build. sometimes I use chroot for armhf
2019-08-08 10:46:29 <ncopa> i use one lxc for each alpine version
2019-08-08 10:46:33 <ncopa> and arch
2019-08-08 10:46:39 <ncopa> which is cumbersome
2019-08-08 10:47:18 <ncopa> i am planning to make some changes in abuild, so the packages dir includes git branch in addition to arch
2019-08-08 10:47:38 <ncopa> that way it should be possible to git checkout $stablebranch
2019-08-08 10:47:56 <ncopa> and build directly there with dabuild or simlar
2019-08-08 10:49:02 <ncopa> for the long term, i would like to have a client/server model for builds
2019-08-08 10:49:16 <PureTryOut[m]> Why does `java -version` on aarch64 only output RT34 rather than the full version string like on x86_64?
2019-08-08 10:49:29 <PureTryOut[m]> (openjdk8-jre)
2019-08-08 10:49:34 <ncopa> PureTryOut[m]: i have no clue
2019-08-08 10:53:03 <mps> PureTryOut[m]: on my box I got: openjdk version "1.8.0_212"
2019-08-08 10:53:12 <PureTryOut[m]> It breaks the Kodi build system 😕
2019-08-08 10:53:40 <mps> and: OpenJDK Runtime Environment (IcedTea 3.12.0) (Alpine 8.212.04-r0)
2019-08-08 10:53:52 <PureTryOut[m]> Huh, in an aarch64 VM I just get RT34...
2019-08-08 10:54:24 <PureTryOut[m]> Wait, 8.212.04? I'm on 8.222.10
2019-08-08 10:54:46 <mps> I'm on v3.10
2019-08-08 10:54:55 <PureTryOut[m]> Ah edge is ahead
2019-08-08 10:55:12 <PureTryOut[m]> Is there any chance you can test on edge?
2019-08-08 10:56:27 <mps> yes, in my lxc I got: openjdk version "1.8.0_222"
2019-08-08 10:56:44 <mps> and: OpenJDK Runtime Environment (IcedTea 3.13.0) (Alpine 8.222.10-r0)
2019-08-08 10:57:01 <PureTryOut[m]> Huh... How the...
2019-08-08 11:04:42 <mps> does this change for clang source is ok 'source="https://github.com/llvm/llvm-project/releases/download/llvmorg-$pkgver/cfe-$pkgver.src.tar.xz'
2019-08-08 11:05:35 <mps> or should be $pkgname put where is word 'llvm'?
2019-08-08 11:06:19 <mps> I think not, should look more carefully before asking
2019-08-08 11:06:38 <mps> looks like url is ok
2019-08-08 11:20:27 <PureTryOut[m]> Literally every arm architecture returns just "RT34" with `java -version`.... Is the OpenJDK8 maintainer in this channel?
2019-08-08 11:51:27 <PureTryOut[m]> cogitri: wait, you asked me if we can build plasma-nm without libnm-glib, but it doesn't depend on that anyway
2019-08-08 11:51:45 <Cogitri> Yes, apk confused me
2019-08-08 11:51:52 <PureTryOut[m]> Ah lol
2019-08-08 11:51:52 <Cogitri> My bad
2019-08-08 11:51:57 <PureTryOut[m]> Np
2019-08-08 11:52:14 <Cogitri> libnm-glib traced back to networkmanager so it displayed everything that depends on that
2019-08-08 11:52:31 <Cogitri> Would be nice if you could test networkmanager-openvpn though :)
2019-08-08 11:52:44 <PureTryOut[m]> Yeah I saw it, will do it either today or tomorrow
2019-08-08 11:57:18 <mps> ncopa: I'm fixing openresolv to install it's helpers in subdir instead of /usr/lib
2019-08-08 11:58:08 <mps> I think proper dir for helpers is /usr/libexec/openresolv , do you agree
2019-08-08 11:59:24 <mps> I'm asking you because you are maintainer
2019-08-08 12:46:27 <mps> ok, posted MR here https://gitlab.alpinelinux.org/alpine/aports/merge_requests/17
2019-08-08 14:12:32 <tcely> What is the plan for -libs-static? Should that be depending on -devel or the other way around?
2019-08-08 14:13:02 <tcely> * -dev
2019-08-08 14:13:03 <maxice8> I think they should depend on -dev
2019-08-08 14:13:26 <maxice8> if it is the other way around then might as well not have it since the reason ncopa wanted it separated was to avoid linking static by mistake
2019-08-08 14:14:31 <tcely> Alright. -libs-static depending on -dev makes sense and is easy too
2019-08-08 14:18:12 <tcely> What are the thoughts on pr9866?
2019-08-08 14:58:12 <tcely> maxice8: were you planning to backport the latest pdns-auth too?
2019-08-08 14:58:53 <tcely> I got upstream to fix their Makefile :-)
2019-08-08 15:05:43 <MartijnBraam> maxice8: so I rebased pr9894 again, does it need anything fixed before it can be merged?
2019-08-08 15:08:33 <maxice8> tcely: No just fix the CVEs
2019-08-08 15:09:32 <maxice8> MartijnBraam: I guess not, i have no permission to push to main/ and pushing the networkmanager changes don't make much sense without the ones to main/
2019-08-08 15:09:44 <MartijnBraam> I didn't know github had per-directory permissions
2019-08-08 15:09:52 <maxice8> it doesn't
2019-08-08 15:09:58 <maxice8> GitHub is a mirror i think we use gitolite
2019-08-08 15:10:01 <maxice8> git.a.o
2019-08-08 15:10:07 <MartijnBraam> oh ofcourse
2019-08-08 15:11:35 <tcely> maxice8: well, the last change didn't actually fix the CVEs, so I wasn't sure.
2019-08-08 15:16:50 <maxice8> What is missing?
2019-08-08 15:20:36 <tcely> Installing pdns-doc and making use of /usr/share/doc/pdns/4.1.10_to_4.1.11.schema.pgsql.sql is manual.
2019-08-08 15:21:43 <maxice8> Yes, i will  try to get it noted in the release notes of stable versions
2019-08-08 15:26:04 <maxice8> PureTryOut: pushing that huge plasma thingy
2019-08-08 15:26:14 <PureTryOut[m]> 👍️
2019-08-08 15:26:22 <maxice8> will ping you in case something fails
2019-08-08 15:26:40 <PureTryOut[m]> I'm in #freenode_#alpine-commits:matrix.org so I should see it but thanks
2019-08-08 15:29:23 <maxice8> ppc64le failed to fetch milou, problably a temporary error
2019-08-08 15:29:24 <PureTryOut[m]> That first failure doesn't make sense, I guess the internet connection dropped for a bit
2019-08-08 15:29:27 <maxice8> :D from linorg
2019-08-08 15:41:14 <maxice8> plasma-workspace was missing pkgrel
2019-08-08 15:42:12 <PureTryOut[m]> maxice8: woops seems my update script failed there with the pkgrel lol. Not sure how that happened
2019-08-08 15:42:39 <PureTryOut[m]> I know, I just said that
2019-08-08 15:43:10 <maxice8> doesn't the alpine githook checks that ?
2019-08-08 15:43:41 <PureTryOut[m]> I don't use any githooks tbh
2019-08-08 15:43:53 <PureTryOut[m]> I probably should
2019-08-08 15:43:58 <maxice8> yes
2019-08-08 15:44:00 <maxice8> and atools :^)
2019-08-08 15:44:27 <mps> atools are nice :-)
2019-08-08 15:45:42 <PureTryOut[m]> atools?
2019-08-08 15:45:58 <_ikke_> apk add atools
2019-08-08 15:46:05 <_ikke_> a linting package from maxice8
2019-08-08 15:46:38 <PureTryOut[m]> Ah
2019-08-08 15:46:42 <PureTryOut[m]> This PC doesn't run Alpine atm though 😉
2019-08-08 15:47:00 <MartijnBraam> hmm maybe we can add alint to the pmos ci
2019-08-08 15:47:04 <_ikke_> It does not require alpine
2019-08-08 15:47:17 <PureTryOut[m]> Sure, but `apk add atools` won't work lol
2019-08-08 15:47:21 <_ikke_> nod
2019-08-08 15:48:21 <maxice8> the most outstanding dependency is GNU Grep
2019-08-08 15:48:23 <maxice8> because i use -P
2019-08-08 15:49:18 <maxice8> PureTryOut: github.com/maxice8/atools
2019-08-08 15:49:35 <_ikke_> I'm asking if I can make the gitlab project public
2019-08-08 15:50:14 <maxice8> as far as i'm concerned yes
2019-08-08 15:57:45 <mps> _ikke_: gitlab project?
2019-08-08 15:58:14 <_ikke_> mps: maxice8 created a personal project on gitlab for atools
2019-08-08 15:58:27 <mps> ah, so.
2019-08-08 15:58:36 <_ikke_> mps: but we disabled users creating public repositories themselves
2019-08-08 15:58:57 <mps> understand
2019-08-08 18:30:36 <zmcgrew_> If I'm looking to contribute a package do I have to put myself as the maintainer?
2019-08-08 18:31:49 <danieli> you do not
2019-08-08 18:33:07 <zmcgrew_> Perfect. Then I need to open a pull request soon. I wrote a package for Ganglia and Ganglia-web =)
2019-08-08 18:33:49 <zmcgrew_> They work perfectly in my VM, but my end goal is to deploy them via a container
2019-08-08 19:03:38 <maxice8> PureTryOut: shouldn't the secfixes header say -r1 instead of -r0 ?
2019-08-08 19:03:59 <PureTryOut[m]> I don't know tbh, I thought it listed the version in which the issue was?
2019-08-08 19:04:07 <PureTryOut[m]> Or does it list the version in which it's fixed?
2019-08-08 19:04:12 <maxice8> The version the issue is fixed
2019-08-08 19:04:19 <PureTryOut[m]> Ah ok, let me send a fix then
2019-08-08 19:04:25 <maxice8> sure
2019-08-08 19:05:40 <PureTryOut[m]> Send a new patch
2019-08-08 19:19:49 <_ikke_> maxice8: atools is public now on gitlab
2019-08-08 19:25:20 <maxice8> nice, next release can switch to it
2019-08-08 19:58:38 <mps> ncopa: finished clang 8.0.1 and tested build on armv7, aarch64 and x86_64, all passed ok.
2019-08-08 19:59:01 <mps> MR is here https://gitlab.alpinelinux.org/alpine/aports/merge_requests/18
2019-08-08 20:00:29 <mps> lld and llvm-libunwind are in the my build queue, and I can push them without sending MR's, they are in community not main
2019-08-08 20:15:18 <mps> hmm, looks like main/compiler-rt also need upgrade to 8.0.1 together with llvm8
2019-08-08 20:31:58 <ncopa> iirc it was a relatively quick compile
2019-08-08 20:32:02 <ncopa> i can do that now
2019-08-08 20:32:25 <ncopa> done
2019-08-08 20:33:22 <mps> oh, you were faster and saved me to post MR. Also I just built it and tested
2019-08-08 20:34:28 <mps> rest of batteries I will push when builders finishes with these in queue, hope it will be before midnight
2019-08-08 21:14:25 <mps> is the x86_64 builder stuck with building kernel
2019-08-08 21:15:20 <_ikke_> last update 13 hours ago
2019-08-08 21:16:02 <mps> looks like it is stuck
2019-08-08 21:16:15 <mps> anyone can restart it?
2019-08-08 21:16:24 <_ikke_> It looks stuck indeed
2019-08-08 21:16:45 <_ikke_> I don't see any activity in the processes
2019-08-08 21:17:28 <_ikke_> Killed one process and it seems to continue
2019-08-08 21:17:32 <mps> build.a.o shows main/linux-vanilla 4.19.65-r0 at 17% for some time
2019-08-08 21:17:38 <_ikke_> yeah, now it failed
2019-08-08 21:18:29 <mps> now it works, thanks
2019-08-08 21:19:05 <_ikke_> it's trying the kernel again
2019-08-08 21:21:21 <mps> it build llvm8 right now
2019-08-08 21:22:11 <mps> s390x is also in suspicious state
2019-08-08 21:26:36 <mps> I thought that this s390x machines are fastest
2019-08-08 23:21:51 <zmcgrew> maxice8: Thanks for the feedback on the ganglia pull request. I'll try and get these fixed for tomorrow.
2019-08-09 05:03:16 <ncopa> ddevault: `curl https://lists.alpinelinux.org/~alpine/aports/%3C20190809021545.20244-1-sir%40cmpwn.com%3E/mbox | git am` does not work
2019-08-09 05:03:23 <ncopa> seems like the patch is base64
2019-08-09 05:04:22 <ncopa> im not sure where or how it got transcoded to base64
2019-08-09 05:06:05 <ddevault> what version of git are you using?
2019-08-09 05:06:33 <ddevault> ncopa: ^
2019-08-09 05:08:23 <ddevault> actually, I can repro
2019-08-09 05:08:27 <ddevault> this seems like a git bug imo
2019-08-09 05:09:05 <ncopa> git version 2.22.0
2019-08-09 05:09:06 <ddevault> here's a differently encoded patch you can try to apply instead: https://sr.ht/F_Xn.patch
2019-08-09 05:09:42 <ddevault> git send-email base64 encoded it because Sören's name is UTF-8
2019-08-09 05:10:36 <ncopa> pushed
2019-08-09 05:10:41 <ddevault> thanks
2019-08-09 05:10:53 <ncopa> could it be that our postfix dones not support utf8?
2019-08-09 05:11:17 <ncopa> or maybe that was only utf8 IDN
2019-08-09 05:11:18 <ddevault> no, the email seems to be fine
2019-08-09 05:11:23 <ncopa> for the domain names
2019-08-09 05:11:25 <ncopa> ok
2019-08-09 05:12:08 <ddevault> I know git is an ivory tower of sorts to point the blame finger at, but having read the git-am code it would not surprise me
2019-08-09 08:29:10 <ncopa> im tagging an edge snapshot release now
2019-08-09 08:48:19 <ncopa> there are many changes in abuild recently
2019-08-09 08:48:29 <ncopa> i think i'll tag a new release of abuild too
2019-08-09 08:48:34 <ncopa> 4.0.0_alpha1
2019-08-09 09:08:53 <mps> do we backport bugfix releases of packages, or just secfix release (although often bugfix is secfix)
2019-08-09 09:11:04 <mps> and, what is url of the list of actively supported releases
2019-08-09 09:28:17 <ncopa> we backport bugfixes to latest stable
2019-08-09 09:28:27 <ncopa> and only sec fixes for older than latest stable
2019-08-09 09:28:48 <ncopa> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2019-08-09 09:28:56 <ncopa> that needs to move to a more official location
2019-08-09 09:30:00 <mps> yes, and thanks
2019-08-09 09:43:24 <mps> if the patch is same for master and previous release (v3.10) do we need to create separate patch or just add note to MR?
2019-08-09 09:43:57 <mps> example is haproxy bugfix release https://gitlab.alpinelinux.org/alpine/aports/merge_requests/20
2019-08-09 09:45:30 <mps> it is 'Request to merge mps:haproxy-2.0.4 into master' but safely could be 'Request to merge mps:haproxy-2.0.4 into 3.10-stable'
2019-08-09 09:58:13 <ncopa> good question
2019-08-09 09:58:15 <ncopa> i dont know
2019-08-09 09:58:57 <ncopa> in this case, its easier for me to cherry-pick
2019-08-09 09:59:54 <ncopa> which i just did...
2019-08-09 10:01:09 <mps> ok, next time in similar case we can add comment in MR that the cherry-pick can be used and tell to which release to be applied
2019-08-09 10:04:48 <ncopa> or a tag
2019-08-09 10:05:19 <ncopa> maxice8: i wonder what you think about the `amove` API  https://github.com/alpinelinux/abuild/pull/92
2019-08-09 10:05:26 <ncopa> is that similar to what void does?
2019-08-09 10:05:44 <ncopa> what other a* functions may we want add support for?
2019-08-09 10:05:54 <ncopa> which should we *not* add?
2019-08-09 10:06:56 <ncopa> i mean, we could add thinkgs like aconfigure, amake, acmake, aninja, apysetup etc
2019-08-09 10:07:14 <ncopa> there is potential for alot of a* functions
2019-08-09 10:07:18 <ncopa> where do we draw the line
2019-08-09 10:13:02 <Cogitri> I feel like we should only introduce wrappers for very commonly used things like _mv
2019-08-09 10:13:34 <Cogitri> Where it's just kind of a hassle to have to copy it from APKBUILD to APKBUILD (and sometimes deal with minor API differences)
2019-08-09 10:14:50 <Cogitri> It's nice having quality of life improvements but it's not nice having a lot of magic in the build process (see Gentoo or Exherbo where you have to read through a few hundreds of LOC to fully get what they're doing e.g. for python builds whereas it's a few lines in each APKBUILD that are easy to understand for us)
2019-08-09 10:15:42 <Cogitri> Although such wrappers do make big changes easier (when you just have to change one line in the wrapper and then rebuild everything that needs it instead of having to change it in each APKBUILD one by one)
2019-08-09 11:08:23 <andypost[m]> I see not a lot of examples in aports about making apps to build with libucontext, but pr9891 needs help to about common practice to inject libs cross arch way
2019-08-09 11:46:45 <mps> ncopa: could you push this MR https://gitlab.alpinelinux.org/alpine/aports/merge_requests/17
2019-08-09 11:47:10 <mps> I need it to test some of ell and iwd upstream patches
2019-08-09 13:14:14 <maxice8> ncopa: driving but yes I like amove
2019-08-09 16:49:30 <zmcgrew> Whoa. That's a lot of dropped connections from matrix.org
2019-08-09 17:11:01 <_ikke_> I keep forgetting that GL uses ! for closing merge requests, not #
2019-08-09 17:22:23 <danieli> it does?
2019-08-09 17:22:28 <danieli> can I change it to do both?
2019-08-09 17:23:56 <_ikke_> # is for issues, ! for merge requests
2019-08-09 18:12:48 <zmcgrew> maxice8: If you get a bit of time, I fixed up my Ganglia pull-request based on your comments
2019-08-09 18:16:07 <clandmeter> Oh so thats what the ! Is for...
2019-08-09 18:16:24 <clandmeter> Weird
2019-08-09 18:23:13 <danieli> I see
2019-08-09 18:23:26 <danieli> on github PRs are treated as issues
2019-08-09 18:23:41 <maxice8> zmcgrew: ill take a look later, medical problems
2019-08-09 18:24:49 <zmcgrew> maxice8: No worries. I appreciated the feedback you gave. Hope things work out for you.
2019-08-09 18:56:10 <maxice8> ncopa: yes, amove it is directly inspired from vmove.
2019-08-09 18:56:18 <maxice8> I don't have plans for adding any other helper functions
2019-08-09 18:56:39 <maxice8> Besides im focused on the python providers thing
2019-08-09 19:28:00 <mps> postgresql security upgrade https://gitlab.alpinelinux.org/alpine/aports/merge_requests/21 and for v3.10 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/22 and
2019-08-09 19:29:21 <mps> and anyone with older builders (v3.9 and v3.8) would make upgrade
2019-08-09 19:39:03 <mps> is the J0WI on some alpine channel
2019-08-09 19:40:37 <_ikke_> not that I'm aware of
2019-08-09 19:41:27 <mps> anyone know who is he or she
2019-08-09 19:43:08 <_ikke_> not me
2019-08-09 19:45:07 <mps> looks like s/he sometimes make PR's blindly
2019-08-09 20:20:48 <mps> we /lib/udev and /usr/lib/udev for rules and scripts. which one we should use?
2019-08-09 20:20:57 <Quo_> Regarding pull request https://github.com/alpinelinux/aports/pull/9927 is there anything more I can do? Pretty new to contributing to oss projects, what is usaually the next step in the process of accepting the PR?
2019-08-09 20:21:36 <_ikke_> Quo_: Usually a bit of patience, most of the time someone will pick it up
2019-08-09 20:23:18 <Quo_> Did not mean to stress anyone, just curious how the workflow looks like
2019-08-09 20:23:39 <mps> Quo_: looks fine at glance, only I think '|| return 1' is not needed
2019-08-09 20:25:08 <Quo_> Hmm, thought i removed those....
2019-08-09 20:25:20 <mps> Quo_: and empty variables should be removed
2019-08-09 20:25:42 <mps> depends_dev="", etc
2019-08-09 20:26:06 <Quo_> hmmm, are we looking at the same diff?
2019-08-09 20:26:07 <Quo_> https://github.com/alpinelinux/aports/pull/9927/files
2019-08-09 20:27:59 <mps> Quo_: sorry, looks like I'm tired already
2019-08-09 20:29:55 <Quo_> Hehe, np :)
2019-08-09 20:30:31 <mps> multitasking is not for humans ;-)
2019-08-09 20:30:51 <_ikke_> Quo_: is python2 support needed for something?
2019-08-09 20:32:58 <Quo_> _ikke_: I dont know, read something about alpine deprecating python 2, but followed the guide making python 2 packages to python 3, whats the status for python2 deprectation?
2019-08-09 20:37:27 <_ikke_> some are making effort to drop python2 support from packages already
2019-08-09 20:41:21 <Quo_> okay, some kind of consensus regarding this, should I remove python2 support?
2019-08-09 20:42:02 <_ikke_> It doesn't make a lot of sense to add if it's going to be removed soon anyway
2019-08-09 20:42:07 <mps> if it is not needed, yes
2019-08-09 20:43:54 <Quo_> okay, could you paste a link to a APKBUILD file only supporting python3 that I could use as a template?
2019-08-09 20:45:22 <_ikke_> https://wiki.alpinelinux.org/wiki/Python_package_policies#Python_3_only
2019-08-09 20:47:16 <Quo_> great, btw. whats is pkgrel?
2019-08-09 20:48:27 <_ikke_> If you make changes to the package that requires it to be rebuilt, without a version bump, you increase the pkgrel
2019-08-09 20:49:11 <Quo_> aha, okay
2019-08-09 20:59:19 <Quo_> I'm quite trilled about the way a project is managed completely remote, is it possible to describe the process of a PR to be merged to master. I'm currecntly working on a project with a similar geographic spead but a completly diffrent workflow
2019-08-09 21:00:56 <_ikke_> Someome makes a PR, someone looks at the list of open PRs and does a code review (some with the help of tools)
2019-08-09 21:01:57 <_ikke_> after potential feedback has been applied (and the packages has been proven to actually build), someone takes the commits as a patch and applies them on master (or stable branch) and pushes it to aports
2019-08-09 21:03:15 <Quo_> Okay, what about functional tests, is that a part of the core review?
2019-08-09 21:04:50 <_ikke_> Sometimes, but we cannot do a functional test for each and every package
2019-08-09 21:05:04 <_ikke_> We run unit / integration tests if available
2019-08-09 21:05:11 <_ikke_> (part of the apkbuild)
2019-08-09 21:07:40 <Quo_> I understand. I see a lane called maintainer review, when is a PR moved to that lane?
2019-08-09 21:08:25 <_ikke_> When someone updates a package that is maintained by someone else, the maintainer is asked to do a final review
2019-08-09 21:08:45 <_ikke_> (depending on the change)
2019-08-09 21:16:31 <mps> _ikke_: I'm not sure that maintainer is asked often
2019-08-09 21:17:51 <_ikke_> No, it's mostly at the descrection from the one picking up the PR
2019-08-09 21:19:26 <mps> I have a that with move to gitlab this will be better
2019-08-09 21:20:28 <maxice8> Doubt it
2019-08-09 21:20:46 <_ikke_> The problem is, do we want to wait for each MR for the maintainer to review it
2019-08-09 21:21:56 <mps> wait some time and if no answer from maintainer then merge
2019-08-09 23:33:34 <maxice8> Do we track secfixes for chromium/firefox ?
2019-08-10 09:11:36 <_ikke_> Anyone got a clue while https://build.alpinelinux.org/buildlogs/build-edge-x86/community/redo/redo-0.42-r0.log fails. I explicitly install cpio, but it still seems to use busybox cpio on 2 arches
2019-08-10 09:15:09 <mps> what arches?
2019-08-10 09:15:48 <_ikke_> x86 and aarch64
2019-08-10 09:16:11 <mps> aha, will try on aarch64 in few minutes
2019-08-10 09:16:24 <_ikke_> ok, thanks
2019-08-10 09:24:47 <mps> redo has a lot of tests
2019-08-10 09:25:20 <mps> in my lxc aarch64 edge it builds cleanly
2019-08-10 09:25:38 <mps> probably builder have issue with cpio
2019-08-10 09:26:38 <mps> '-rw-r--r--    1 mps      mps          89372 Aug 10 09:24 /home/mps/packages/community/aarch64/redo-0.42-r0.apk'
2019-08-10 09:45:19 <_ikke_> hmm, strange
2019-08-10 09:46:14 <_ikke_> If I install it manually on the builder, it seems to just work
2019-08-10 09:53:37 <mps> I did with 'abuild -r'
2019-08-10 09:54:01 <_ikke_> I confirmed that cpio is properly installed during the build even
2019-08-10 10:01:11 <_ikke_> Some kind of race condition perhaps?
2019-08-10 10:02:04 <mps> yes, strange. I have no idea how to debug this issue
2019-08-10 12:08:54 <danieli> _ikke_: perhaps it has to do with the order of $PATH?
2019-08-10 12:09:14 <danieli> busybox cpio in a directory in path searched before the one you install
2019-08-10 12:19:05 <mps> danieli: cpio apk replaces busybox applet
2019-08-10 12:19:18 <danieli> i'll test real quick
2019-08-10 12:19:20 <danieli> see if i can figure t out
2019-08-10 12:19:25 <danieli> it*
2019-08-10 12:20:21 <mps> I tested in lxc aarch64 and it worked
2019-08-10 12:20:39 <mps> I mean, build redo pkg
2019-08-10 12:22:29 <danieli> yeah, installing cpio does successfully replace it here, in the correct path
2019-08-10 12:44:41 <mps> _ikke_: how do you close MR's on gitlab? simply clicking '
2019-08-10 12:44:41 <mps> Edit
2019-08-10 12:44:46 <mps> Close merge request
2019-08-10 12:44:54 <mps> ohm
2019-08-10 12:45:26 <mps> simply clicking 'Close merge request' or some other way
2019-08-10 12:46:16 <mps> I would like to add comment or status to close
2019-08-10 13:53:46 <_ikke_> mps: Manually, but I use /close in the comment message to close it
2019-08-10 13:54:04 <_ikke_> mps: there is still a feature request to be able to close merge requests via commit messaages
2019-08-10 13:55:19 <mps> _ikke_: well, one of my MR where I added 'fixes #nr' in commit msg was closed automatically, iirc
2019-08-10 13:55:58 <_ikke_> It closes the issue with that number, not a merge request itsel
2019-08-10 13:56:01 <_ikke_> itself
2019-08-10 13:56:12 <_ikke_> merge requests are referred to with ! as prefix
2019-08-10 13:56:31 <_ikke_> !123 is merge request 123, #123 is issue 123 (gitlab makes a difference between the two)
2019-08-10 13:56:38 <_ikke_> sigh
2019-08-10 13:56:53 <mps> here it is ttps://gitlab.alpinelinux.org/alpine/aports/merge_requests/3/diffs?commit_id=d1e3cabb1879bb73111554b43946aa1b564e37a3
2019-08-10 13:57:11 <mps> it has 'fixes #10677 (closed)'
2019-08-10 13:57:55 <mps> oh, algitbot learned about MR's :-) very good
2019-08-10 14:00:57 <_ikke_> Yes, that's an issue that got closed
2019-08-10 14:03:19 <_ikke_> closes ! 123 (without space) does not work
2019-08-10 14:03:19 <mps> so, for now we can write comment about closing MR in message textarea and click button 'Comment & and close merge request'
2019-08-10 14:03:32 <_ikke_> That, or end the comment with /close
2019-08-10 14:03:55 <mps> '/close' in textarea?
2019-08-10 14:04:01 <_ikke_> yes
2019-08-10 14:04:09 <mps> aha, will try
2019-08-10 14:04:12 <_ikke_> gitlab allows commands in the text area
2019-08-10 14:04:20 <_ikke_> /assign @mps would also work
2019-08-10 14:05:58 <mps> I see, noticed when started to write /clo.......
2019-08-10 14:09:13 <mps> PureTryOut[m]: just pushed your dolphin-emu upgrade
2019-08-10 14:09:50 <PureTryOut[m]> Yeah I saw it, thanks
2019-08-10 14:10:03 <_ikke_> hmm, `john` test is failing on ppc64le
2019-08-10 14:11:01 <mps> and maxice8 continues with 'limit' ;-)
2019-08-10 14:12:40 <_ikke_> with limit?
2019-08-10 14:12:51 <_ikke_> ah, just missed his last ocmmit
2019-08-10 14:12:52 <_ikke_> commit
2019-08-10 14:12:53 <maxice8> using limit instead of disable <arch>
2019-08-10 14:14:47 <_ikke_> maxice8: limit on <arch> sounds gramatically wrong. Limit *what* on <arch>?
2019-08-10 14:15:11 <maxice8> that is simple, the package
2019-08-10 14:15:12 <mps> when enabling build on some arch we use 'enable',
2019-08-10 14:15:28 <maxice8> we do the same with upgrade to <version>
2019-08-10 14:15:32 <mps> when disabling we use 'disable'
2019-08-10 14:15:53 <_ikke_> limit on 'foo' does not mean that foo is somehow excluded
2019-08-10 14:16:06 <mps> so we can switch 'enable' to 'unlimit' :P
2019-08-10 14:16:48 <mps> I'm not native English speaker, TBH
2019-08-10 14:22:24 <_ikke_> You can limit someting *to* soemthing
2019-08-10 14:22:26 <_ikke_> something
2019-08-10 14:33:57 <mps> reading more than 3 decades computer's book about hardware and software I always see enable/disable combo, limit has some other connotations
2019-08-10 14:37:28 <mps> 
ACTION is known in everyday life as someone who insist on using right terms

2019-08-10 14:48:38 <maxice8> fair, i'll try to use disable
2019-08-10 14:54:30 <mps> maxice8: nice, so when I fork aports I will have less msg's to rewrite :D
2019-08-10 14:55:19 <maxice8> rewrite ?
2019-08-10 14:56:21 <mps> git rebase --interactive, to rewrite git history
2019-08-10 14:56:51 <maxice8> why ?
2019-08-10 14:57:13 <mps> ofc, I'm joking, I do not plan to fork alpine
2019-08-10 15:54:25 <mps> anyone with main access would review and push https://gitlab.alpinelinux.org/alpine/aports/merge_requests/17
2019-08-10 15:54:45 <mps> openresolv fix helpers subdir
2019-08-10 17:32:08 <maxice8>  PureTryOut the patches you sent about kodi, pugixml and waylandpp are not appearing on https://lists.alpinelinux.org/~alpine/aports/patches only https://lists.alpinelinux.org/~alpine/aports/
2019-08-10 17:32:37 <PureTryOut[m]> Yeah I have that more often. Some bug in git-something. ddevault knows about it and a fix has already landed, the package just has to be updated afaik
2019-08-10 17:32:57 <PureTryOut[m]> Nothing I can do about it
2019-08-10 17:50:58 <maxice8> PureTryOut: pushed pugixml changes, will push waylandpp and kodi later
2019-08-10 17:56:44 <PureTryOut[m]> Yeah saw it thanks
2019-08-10 18:01:18 <Cogitri> Had time looking at nm-openvpn yet, PureTryOut? I'm reasonably sure it's broken with NM 1.20 for now :/
2019-08-10 18:01:54 <PureTryOut[m]> Oh sorry not yet. Eating atm, will test in ~30 minutes
2019-08-10 18:02:19 <Cogitri> Thank you :)
2019-08-10 18:02:42 <Cogitri> Enjoy your meal
2019-08-10 18:36:48 <PureTryOut[m]> cogitri: well it doesn't want to install networkmanager 1.20.0. Just complains that 1.18.2-r2 breaks world[networkmanager=1.20.0]
2019-08-10 18:44:36 <Cogitri> You have rebuild network-manager-applet and networkmanager-openvpn too?
2019-08-10 19:28:54 <maxice8> PureTryOut: waylandpp x86
2019-08-10 19:29:16 <PureTryOut[m]> Yeah noticed it maxice8
2019-08-10 19:29:31 <PureTryOut[m]> Lots of "not declared" stuff, not sure why just on x86
2019-08-10 19:29:41 <PureTryOut[m]> cogitri: not applet, but I don't use that
2019-08-10 19:30:24 <Cogitri> applet is a dep of nm-openvpn
2019-08-10 19:30:40 <Cogitri> So you have to rebuild that too to install nm-openvpn
2019-08-10 19:30:50 <PureTryOut[m]> what... why is that a dep?
2019-08-10 19:31:09 <Cogitri> Because nm-openvpn was built with libnm-gtk, which is provided by network-manager-applet
2019-08-10 19:32:13 <Cogitri> And n-m-a can't provide libnm-gtk anymore because nm has dropped libnm-glib, so my PR builds nm-openvpn without n-m-a
2019-08-10 19:34:39 <PureTryOut[m]> Well that didn't seem to work either
2019-08-10 19:35:05 <Cogitri> Hm?
2019-08-10 19:52:56 <PureTryOut[m]> I've built all the packages in your PR, but it still won't upgrade networkmanager 1.20.0 due to 1.18.2-r2 breaking world[networkmanager=1.20.0] for some reason
2019-08-10 19:53:35 <Cogitri> Huh
2019-08-10 19:53:48 <Cogitri> Not quite sure if you can get apk to give you something more useful
2019-08-10 19:54:51 <[[sroracle]]> Do you have nm pinned in your world?
2019-08-10 19:55:08 <[[sroracle]]> grep networkmanager /etc/apk/world
2019-08-10 19:56:47 <PureTryOut[m]> No I do not
2019-08-10 19:57:20 <PureTryOut[m]> And even then, how would that prevent it from upgrading?
2019-08-10 19:57:58 <[[sroracle]]> it won't upgrade if you have a version pinned in world
2019-08-10 19:58:02 <[[sroracle]]> thats kind of the point
2019-08-10 20:28:17 <mps> Cogitri: I've got something which looks like I've built rust on aarch64 http://tpaste.us/5wbM
2019-08-10 20:28:54 <Cogitri> Neat
2019-08-10 20:29:04 <mps> have to test if it works
2019-08-10 20:29:04 <Cogitri> With upstream triplets or with alpine triplets? :o
2019-08-10 20:29:27 <Cogitri> What has fixed the SIGSEVs for you?
2019-08-10 20:29:32 <mps> this is as you put it in APKBUILD, didn't changed anything
2019-08-10 20:29:49 <Cogitri> Oh, didn't that explode for you earlier on?
2019-08-10 20:29:57 <Cogitri> But thanks for the info
2019-08-10 20:30:01 <mps> only removed cargo and rust from makedepends
2019-08-10 20:30:26 <mps> yes, earlier it didn't worked but now apk's are there
2019-08-10 20:30:52 <PureTryOut[m]> [[sroracle]]: oh sorry I confused pinning
2019-08-10 20:30:57 <Cogitri> <mps "yes, earlier it didn't worked bu"> Okie, magic
2019-08-10 20:31:08 <mps> TBH, I didn't expected it will succeed but 'apkbuild -r' finished
2019-08-10 20:31:13 <PureTryOut[m]> But no it's not pinned
2019-08-10 20:31:33 <[[sroracle]]> PureTryOut[m]: yes, the terminology is not clear between version pinning and repository pinning. sorry i was unclear
2019-08-10 20:31:44 <mps> hey, today is my birthday, so I've got a gift :-)
2019-08-10 20:32:42 <[[sroracle]]> PureTryOut[m]: you may be able to tell what else is not being upgraded with apk version -l '<'
2019-08-10 20:32:49 <[[sroracle]]> that might give a clue
2019-08-10 20:33:33 <Cogitri> mps: Happy Birthday then :)
2019-08-10 20:34:31 <mps> thanks
2019-08-10 20:34:52 <PureTryOut[m]> [[sroracle]]: it only mentions python3, although I'm also not sure why it's not upgrading that
2019-08-10 20:43:01 <mps> Cogitri: ' rustc --print target-list | grep alpine' => http://tpaste.us/vbY5
2019-08-10 20:43:13 <mps> sorry for annoying you
2019-08-10 20:44:10 <Cogitri> No worries, thank you for trying! Could you try changing aarch64-unkown-linux-musl to aarch64-alpine-linux-musl in the APKBUILD?
2019-08-10 20:44:21 <Cogitri> (in the _target var)
2019-08-10 20:44:44 <Cogitri> It'll most likely be unable to successfully compile Rustc again, that's where I've been stuck :/
2019-08-10 20:45:02 <mps> ofc, that is plan for tomorrow, now I'm building some simple rust programs to see does it actually work
2019-08-10 20:45:48 <Cogitri> It'll work for everything that doesn't need dylibs, which isn't a lot
2019-08-10 20:46:56 <mps> I hope it will be possible to rebuild rust with those apk's I've got
2019-08-10 20:47:22 <mps> but first will try firefox-esr
2019-08-10 20:47:49 <Cogitri> Would surprise me if that worked to be honest :)
2019-08-10 20:47:55 <Cogitri> But good luck trying
2019-08-10 20:48:44 <mps> rdedup is in queue, next is cbindgen
2019-08-10 20:49:49 <mps> building rust programs require time and resources (modern langs :P)
2019-08-10 21:07:26 <Cogitri> Yes, rustc still is pretty slow
2019-08-10 22:30:21 <bluckenbill> hello
2019-08-10 22:30:41 <bluckenbill> i am having issues building iso files w/ the mkimage script in aports
2019-08-10 22:32:20 <bluckenbill> it does nothing after '>> mkimage-x86_64: --> kernel x86_64 vanilla 89.....97 linux-vanilla .....'
2019-08-10 22:33:42 <danieli> it literally does nothing, not even in the process list?
2019-08-10 22:34:06 <bluckenbill> there is no output after that message
2019-08-10 22:34:33 <bluckenbill> it flashes a loading bar
2019-08-10 22:34:38 <bluckenbill> then nothing
2019-08-10 22:38:49 <bluckenbill> is https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage accurate?
2019-08-10 22:55:53 <bluckenbill> i am tryint to make a bootable image that i can burn to a usb/cdrom with specific apk packages on it
2019-08-10 23:56:54 <bluckenbill> ok i have progressed in my issue... now after running the mkimage.sh i see a directory called mkimage.oEAieA with subdirectories in it like grub and apkroot
2019-08-11 01:16:26 <bluckenbill> fixed it.. there was a problem w/ the mkimg.base.sh when calling update-kernel, it was not completeing successfully, the command 'apk add' was always returning an error no matter what
2019-08-11 01:17:16 <bluckenbill> i do an 'apk add ...' and it always returns "1 error; 976 MiB in 215 packages"
2019-08-11 01:17:34 <bluckenbill> how can i see what that 1 error is? -v is no help
2019-08-11 01:21:09 <bluckenbill> got a /usr/sbin/grub-probe: error: failed to get canonical path of `overlay'. w/ apk fix
2019-08-11 01:21:14 <bluckenbill> man this place is dead
2019-08-11 01:21:17 <bluckenbill> anyone on?
2019-08-11 01:21:37 <danieli> it's past 3 am in central europe where most of the developers are
2019-08-11 01:21:43 <bluckenbill> ah
2019-08-11 01:21:51 <danieli> you are probably looking for #alpine-linux, but it's probably quiet as well this time of day
2019-08-11 01:22:05 <danieli> the alpine channels can be quite slow, the usual IRC advice is to ask and wait
2019-08-11 10:41:40 <Cogitri> What should I anticipate as "deadline" to get GNOME somewhat comfortably into community until 3.11?
2019-08-11 11:51:52 <mps> closing issue on GL.a.o works with 'fixes #nr'
2019-08-11 12:01:27 <_ikke_> Cogitri: I guess around november/december
2019-08-11 12:04:09 <Cogitri> Alrighty, thanks
2019-08-11 12:04:19 <Cogitri> Will focus on Rust and dbg packages first then
2019-08-11 12:04:53 <_ikke_> 3.9 was released around januari, but officially 3.11 is scheduled the first of november
2019-08-11 12:06:30 <Cogitri> Okie
2019-08-11 12:14:02 <Cogitri> Also, re #10603 can we add `-g` to our CFLAGS?
2019-08-11 12:14:40 <Cogitri> It doesn't come at any runtime penalty since the debugging symbols would be split into -dbg packages anyway
2019-08-11 12:14:58 <Cogitri> It'd mean longer build times and a higher space requirement for builders though
2019-08-11 12:15:59 <Cogitri> But without these dbg packages it's somewhat impossible to debug crashes on Alpine and it's a bit annoying when I first have to add a hundred -dbg packages for the deps of a package to properly debug that package
2019-08-11 12:18:01 <_ikke_> increased storage requirements might be a concern
2019-08-11 12:20:21 <Cogitri> Yup. We might want to disable debugging for really massive packages (e.g. webkit2gtk) anyway
2019-08-11 12:20:34 <Cogitri> But having about no dbg packages at all sucks :/
2019-08-11 12:20:50 <_ikke_> version tagged docker images :-): https://hub.docker.com/r/alpinelinux/docker-cli/tags
2019-08-11 12:24:29 <asriel> Any plans for pr8984 to be merged?
2019-08-11 12:24:53 <asriel> OOPS.
2019-08-11 12:25:00 <asriel> Any plans for pr9894 to be merged?
2019-08-11 12:25:05 <PureTryOut[m]> Lol
2019-08-11 12:25:56 <_ikke_> musl package size is 366.64 kB, musl-dbg package size is 917.87 kB
2019-08-11 12:26:05 <_ikke_> roughly 2-3 times bigger
2019-08-11 12:30:23 <mps> uhm, not small difference
2019-08-11 12:31:34 <_ikke_> Not everything will be that big of a difference
2019-08-11 12:31:54 <_ikke_> python3 16.52 MB, python3-dbg 5.27 MB
2019-08-11 12:35:12 <mps> still, I'm not sure we need -dbg by default
2019-08-11 12:35:18 <Cogitri> To debug stuff
2019-08-11 12:35:56 <Cogitri> If I get a SEGFAULT and everything I get is "process X segfaulted at ip 62947 eshdhe 7272" or smth like that I can't exactly debug what went wrong
2019-08-11 12:37:51 <_ikke_> I understand the need for debug symbols, the question is, can we bear the cost of doing it globally
2019-08-11 12:37:52 <mps> well, I look source in such cases and if this doesn't help, then rebuild pkg locally with -g or add -dbg subpkg
2019-08-11 12:38:25 <mps> sometimes strace helps
2019-08-11 12:38:33 <mps> or ltrace
2019-08-11 12:40:57 <Cogitri> mps: the problem is that the stacktrace might go into one of the deps of that package
2019-08-11 12:41:18 <Cogitri> <algitbot "When should -dbg packages be add"> Just read ^, it contains all the info
2019-08-11 12:41:50 <Cogitri> But yes, dbg packages will take up rather a lot of space, Ikke
2019-08-11 12:43:22 <_ikke_> It will increase the storage cost for every alpinelinux mirror
2019-08-11 12:43:43 <_ikke_> Just for something that is needed once in a while
2019-08-11 12:48:11 <mps> Cogitri: yes, I understand that sometimes is not enough to make just -dbg of package with isssue, but also packages on which it depends
2019-08-11 12:49:05 <mps> but usually strace or ltrace gives 'a glance' view what to do
2019-08-11 13:02:47 <mps> to be clear, I'm not so strongly against -dbg, just have impression that this will add burden. I think this deserve a broader audience
2019-08-11 13:05:14 <MartijnBraam> can't all the -dbg packages just be added to a seperate repository?
2019-08-11 13:06:03 <_ikke_> Probably, but that also requires work to make happen
2019-08-11 13:06:31 <mps> and load on builders
2019-08-11 13:08:01 <mps> a lot of us build pkg's locally on different VM's or containers just to check if pkg builds cleanly
2019-08-11 13:14:38 <Cogitri> I doubt you'll see a noticeable increase in buildtime or RAM consumption in anything but really massive packages like webkit2gtk where we'll want to disable the dbg packages anywya
2019-08-11 13:14:45 <Cogitri> I've added a size overview to the issue.
2019-08-11 13:15:18 <Cogitri> And a seperate repo sounds like a good idea to me, MartijnBraam
2019-08-11 13:20:33 <MartijnBraam> has anyone tried enableing aarch64 for the mono package?
2019-08-11 13:21:10 <danieli> i can try building it on aarch64 and give you the output
2019-08-11 13:22:23 <MartijnBraam> I tried to build it in postmarketOS but the pmos build system seems to be messing with it
2019-08-11 13:22:35 <MartijnBraam> I also can't build it for armv7 in that build system but it's packaged in alpine
2019-08-11 13:27:36 <danieli>   libgdiplus-dev (missing):
2019-08-11 13:27:36 <danieli>     required by: .makedepends-mono-20190811.132724[libgdiplus-dev]
2019-08-11 13:27:38 <danieli> failed nstantly
2019-08-11 13:27:41 <danieli> instantly
2019-08-11 13:28:10 <danieli> i'll try building it first
2019-08-11 13:28:32 <_ikke_> It's in testing
2019-08-11 13:28:35 <_ikke_> did you add the testin repo?
2019-08-11 13:28:41 <danieli> strange, for some reason i have not
2019-08-11 13:28:46 <danieli> should've figured
2019-08-11 13:51:19 <danieli> it spat out a massive traceback while compiling Mono.Cecil.dll
2019-08-11 13:51:23 <danieli> @ MartijnBraam
2019-08-11 13:51:38 <danieli> null reference exception
2019-08-11 13:52:17 <MartijnBraam> Ok, so it isn't as simple as enableing the arch :(
2019-08-11 13:56:14 <danieli> indeed, the traceback was probably a couple hundred lines
2019-08-11 15:04:24 <Cogitri> mps: Had success w/ Rust?
2019-08-11 15:05:30 <mps> Cogitri: it is to hot here, simply can concentrate on anything serious
2019-08-11 15:05:51 <Cogitri> Oh, alright
2019-08-11 15:05:58 <mps> but, built cbindgen and rdedup
2019-08-11 15:06:45 <mps> I had to try to build rust 1.36 with 1.36
2019-08-11 15:07:51 <mps> because currently stdlib is aarch64-unknown-linux-musl and not aarch64-alpine-linux-musl
2019-08-11 15:16:02 <jwh> hm
2019-08-11 15:16:04 <jwh>  * Creating a new MySQL database ...chown: /usr/lib/mariadb/plugin/auth_pam_tool_dir: No such file or directory
2019-08-11 15:17:40 <Cogitri> I think someone else was encountering the same thing a while ago
2019-08-11 15:17:48 <jwh> who broke it
2019-08-11 15:19:01 <jwh> theres nothing packaged matching that name
2019-08-11 15:20:00 <Cogitri> fwiw bexx on #alpine-linux had that issue too
2019-08-11 15:20:19 <Cogitri> My guess is we build without pam support but the config isn't adjusted to that
2019-08-11 15:20:30 <jwh> probably
2019-08-11 15:22:10 <MY_R> jwh, try in script: /usr/bin/mysql_install_db
2019-08-11 15:23:11 <jwh> thats what the init script runs..
2019-08-11 15:23:28 <jwh> since maria still live in the past instead of adopting --initialize
2019-08-11 15:24:10 <MY_R> ye, so that script need a patch :\
2019-08-11 15:26:46 <jwh> if test -n "$user"
2019-08-11 15:26:49 <jwh> then
2019-08-11 15:26:52 <jwh>   chown $user "$pamtooldir/auth_pam_tool_dir" && \
2019-08-11 15:26:53 <jwh> gg
2019-08-11 15:30:19 <_ikke_> PureTryOut[m]: Some packages are failing from the kde framework upgrade
2019-08-11 15:32:16 <PureTryOut[m]> I see. Test failures for kwindowsystem
2019-08-11 15:33:15 <_ikke_> kcoreaddons and kwidgetsaddons also fail on some archers
2019-08-11 15:37:26 <PureTryOut[m]> kcoreaddons are failing tests, but seem to be race conditions as retrying them seems to make them pass
2019-08-11 15:43:42 <PureTryOut[m]> I've send a patch to fix kwayland
2019-08-11 15:50:37 <PureTryOut[m]> And one to fix kwindowsystem
2019-08-11 15:51:35 <_ikke_> the kwayland package fails to build for me. It looks for ECM 5.61.0, but finds 5.60.0
2019-08-11 15:52:16 <PureTryOut[m]> That's just because the builders don't upload the packages before everything has succeeded to build
2019-08-11 15:52:26 <PureTryOut[m]> so ECM is updated in the builder, but not yet in the repos and thus not your local system
2019-08-11 15:52:29 <_ikke_> right
2019-08-11 15:52:35 <_ikke_> Figured something like that
2019-08-11 15:52:55 <PureTryOut[m]> Anyways I've send the fixes for kwayland and kwindowsystem, they should build fine now (they do locally)
2019-08-11 16:19:46 <_ikke_> Hmm, why does this show up as new at this moment?
2019-08-11 16:20:09 <_ikke_> issue is 3 weeks old and last update 2 days ago
2019-08-11 16:21:02 <_ikke_> ah, it comes from redmine..
2019-08-11 16:21:25 <_ikke_> How do they even know how to reach redmine..
2019-08-11 16:21:29 <PureTryOut[m]> Also the title is wrong
2019-08-11 16:21:49 <PureTryOut[m]> I guess the redirect is wrong?
2019-08-11 16:21:55 <_ikke_> It's correct on redmine
2019-08-11 16:22:05 <_ikke_> Someone is creating issues on redmine
2019-08-11 16:22:30 <PureTryOut[m]> Interesting, how do you even get there?
2019-08-11 16:22:52 <_ikke_> It still has a domain, but we never published it
2019-08-11 16:24:18 <PureTryOut[m]> Interesting
2019-08-11 16:45:49 <_ikke_> PureTryOut[m]: kdewebkit is missing Qt5UiPlugin?
2019-08-11 16:46:27 <PureTryOut[m]> not that I know? has the build failed? I don't see it yet in #freenode_#alpine-commits:matrix.org
2019-08-11 16:46:55 <_ikke_> I tried to build it locally
2019-08-11 16:47:19 <_ikke_> (in dependency order)
2019-08-11 16:47:27 <_ikke_> http://tpaste.us/KgLn
2019-08-11 16:47:31 <PureTryOut[m]> How do you properly figure out the dependency order?
2019-08-11 16:47:49 <_ikke_> lua-aports
2019-08-11 16:48:27 <PureTryOut[m]> Oh now that seems useful, thanks!
2019-08-11 16:48:38 <PureTryOut[m]> Anyways, Qt5UiPlugin seems to be part of qt5-qttools
2019-08-11 16:49:11 <PureTryOut[m]> Could you try adding `qt5-qttools-dev` to either `depends_dev` or `makedepends`?
2019-08-11 16:50:22 <_ikke_> it at least installs qt5-qttools, but not the -dev variant
2019-08-11 16:50:50 <PureTryOut[m]> Yeah pretty sure it needs the -dev variant
2019-08-11 16:51:00 <PureTryOut[m]> Ah. From KDEWebkit changelog: "Add option to build Qt Designer plugin (BUILD_DESIGNERPLUGIN, default ON)"
2019-08-11 16:51:05 <_ikke_> ok
2019-08-11 16:51:08 <PureTryOut[m]> That's the bit requiring it
2019-08-11 16:51:10 <_ikke_> Trying now with that
2019-08-11 16:51:30 <_ikke_> Yes, succeeded
2019-08-11 16:52:06 <_ikke_> Continuing
2019-08-11 16:53:51 <PureTryOut[m]> Awesome
2019-08-11 16:54:16 <PureTryOut[m]> I'm off for a few minutes
2019-08-11 16:54:25 <_ikke_> sure
2019-08-11 17:12:52 <PureTryOut[m]> Back
2019-08-11 17:13:49 <_ikke_> It just finished building
2019-08-11 17:13:54 <PureTryOut[m]> Oh did https://build.alpinelinux.org get updated? The "aport total" now seems to be correct
2019-08-11 17:14:02 <PureTryOut[m]> Locally you mean? Awesome
2019-08-11 17:14:10 <_ikke_> Yes, locally
2019-08-11 17:14:19 <_ikke_> PureTryOut[m]: I haven't heard about any updates, but perhaps
2019-08-11 17:14:35 <_ikke_> There is a horizontal scrollbar now as wel
2019-08-11 17:14:37 <PureTryOut[m]> It would be nice if the order of builders could stop jumping around every once and while
2019-08-11 17:14:50 <_ikke_> heh, yeah
2019-08-11 17:16:51 <_ikke_> d'oh, maxice8 alright pushed those two patches :)
2019-08-11 17:16:57 <_ikke_> I'll push the last one then
2019-08-11 17:24:38 <_ikke_> maxice8: networkmanager-qt fails because networkmanager has been disabled on s390x
2019-08-11 17:25:08 <PureTryOut[m]> Oh that's too bad
2019-08-11 17:25:52 <PureTryOut[m]> It's a bit annoying that I can't really test builds on s390x and ppc64le...
2019-08-11 17:26:08 <_ikke_> PureTryOut[m]: I'm working hard on getting CI to work
2019-08-11 17:26:19 <_ikke_> We already have a builder for s390x
2019-08-11 17:26:29 <PureTryOut[m]> For Gitlab? Nice!
2019-08-11 17:26:31 <_ikke_> yes
2019-08-11 17:26:42 <_ikke_> ppc64le should be coming as well, didn't hear anything about it though
2019-08-11 17:26:43 <PureTryOut[m]> Hopefully the ML will have CI too soon
2019-08-11 17:27:24 <_ikke_> Not sure if it's going to support all these arches
2019-08-11 17:32:54 <maxice8> _ikke_: Alright, just finished a phone call, what can i help with ?
2019-08-11 17:33:24 <_ikke_> You pushed an update to networkmanager-qt, but it's failing now on s390x because networkmanager has been disabled
2019-08-11 17:33:42 <maxice8> oh
2019-08-11 17:33:49 <maxice8> i'll push a disable on s390x to networkamanager-qt
2019-08-11 17:33:56 <maxice8> and its children
2019-08-11 17:34:25 <_ikke_> And I found another packagge missing a dependency for kdeframework
2019-08-11 17:35:01 <maxice8> oh dear quite a few things depend on networkmanager-qt
2019-08-11 17:35:41 <maxice8> all of them already disabled s390x
2019-08-11 17:35:43 <maxice8> :D
2019-08-11 17:35:49 <_ikke_> heh
2019-08-11 17:37:45 <PureTryOut[m]> Yeah I think just Plasma depends on networkmanager-qt atm, and that is largely disabled for s390x anyway
2019-08-11 17:37:48 <_ikke_> upgraded atools to 18.8.1
2019-08-11 17:37:56 <maxice8> _ikke_: Switched to gitlab ?
2019-08-11 17:38:02 <_ikke_> Hmm, not yet
2019-08-11 17:38:15 <_ikke_> Not sure if you completely switched to gitlab yet
2019-08-11 17:38:31 <maxice8> I completely switched i just push to github as well because my gitlab repo wasn't public
2019-08-11 17:38:34 <maxice8> now that it is
2019-08-11 17:38:35 <maxice8> i'll push only to it
2019-08-11 17:38:55 <maxice8> anyways i'm going to fix a few things on apkbuild-fixer and push another PATCHVER release on GitLab only
2019-08-11 17:41:00 <_ikke_> Would be nice to enable CI on gitlab as well
2019-08-11 17:41:18 <maxice8> hmmm i didn't think about that
2019-08-11 17:41:23 <maxice8> i run the checks myself and get an email from travis
2019-08-11 17:41:53 <_ikke_> For things like merge requests
2019-08-11 17:42:40 <_ikke_> Nice, the gitlab archive has the same checksum as the github one
2019-08-11 17:42:57 <_ikke_> (probably both generated though git archive)
2019-08-11 17:44:00 <_ikke_> maxice8: switched now
2019-08-11 17:46:31 <maxice8> i think GitLab/GitHub both use git archive to make their autogenerated tarballs
2019-08-11 17:46:36 <_ikke_> yes
2019-08-11 17:46:48 <maxice8> and ppc64le failed
2019-08-11 17:47:20 <_ikke_> Hmm
2019-08-11 17:47:53 <_ikke_> Oh, checksum *is* different, it just used the cached file locally
2019-08-11 20:38:14 <mps> maxice8: are you sure older llvm's could be moved to unmaintained? nothing depends on these versions moved?
2019-08-11 20:39:47 <maxice8> yes, nothing depends on 3.9
2019-08-11 20:41:07 <mps> iirc, I upgraded llvm7.1 and moved to community because some pkg depends on it, but forgot which one
2019-08-11 20:41:22 <mps> I mean, two months ago
2019-08-11 20:42:52 <mps> but not sure why, llvm is mess anyway. I think you are right
2019-08-11 20:44:01 <maxice8> apk search --rdepends --quiet --origin llvm7
2019-08-11 20:44:21 <maxice8> is what i use to check
2019-08-11 20:44:39 <mps> ok, ok. :-) just was suspicios
2019-08-11 20:47:33 <maxice8> Lots of stuff in main/
2019-08-11 20:47:36 <maxice8> including secfixes :D
2019-08-11 20:48:40 <mps> yes, and understand your position
2019-08-11 20:52:11 <mps> also noticed that most pkg's about which I care are in main, and don't like to annoy people to check MR's and push
2019-08-11 21:00:28 <mps> build zola on aarch64 failed, but firefox-esr succeed with yesterdays rust build
2019-08-11 21:00:54 <mps> have to concentrate on fixing rust stdlib build
2019-08-11 21:04:09 <Cogitri> Yeah, it should work with the upstream triplets, but sadly it's borked with ours
2019-08-11 21:04:18 <Cogitri> 
ACTION is thinking about just using the upstream ones for now

2019-08-11 21:08:32 <mps> yes, I added CARCH=native to firefox APKBUILD and fix-rust-target.patch to just replace gnu with musl, unknown is unchanged
2019-08-11 21:08:46 <mps> and remove --disable-elf-hack
2019-08-11 21:10:46 <Cogitri> Yup, setting that or doing `RUST_TARGET=${CTARGET/alpine/unknown}` should work for now
2019-08-11 21:12:38 <mps> hmm, I'm trying with '_target="aarch64-alpine-linux-musl"'
2019-08-11 21:13:34 <mps> lets see will it work
2019-08-12 01:04:16 <ddevault> mps: please use reply all to reply to messages on the mailing lists, so people who aren't subscribed will receive your reply
2019-08-12 01:10:49 <ddevault> mps: (this is not a problem unique to lists.sr.ht, before your inevitable complaint)
2019-08-12 03:20:05 <maxice8> mps: you were right about llvm, ghc still needs llvm5
2019-08-12 08:24:30 <danieli> ddevault: that last part was a bit unnecessary, no?
2019-08-12 08:26:15 <ddevault> with anyone other than mps, perhaps
2019-08-12 09:18:01 <mps> I will continue to read alpine ML's but not post except if something is important
2019-08-12 09:18:40 <mps> (and, I learned long ago that complaining to deaf is waste of time ;-P )
2019-08-12 13:38:26 <tcely> pr10039 makes use of an archive like most other packages. Hopefully, this meets whatever requirement has not been sufficiently explained previously.
2019-08-12 15:04:03 <Cogitri> What is the reason to download that file from the net instead of putting it in source and circumventing the shasum by that?
2019-08-12 15:51:03 <_ikke_> Cogitri: Who are you asking?
2019-08-12 16:27:57 <Cogitri> tcely about pr10039
2019-08-12 16:28:02 <Cogitri> Sorry that I wasn't clear
2019-08-12 17:07:23 <_ikke_> Cogitri: I suspected that, just asked to be sure
2019-08-12 20:48:48 <Cogitri> Maybe someone with access to main/ could take a look at the Github PRs? Quite a lot of security fixes have piled up
2019-08-12 20:52:01 <_ikke_> Those take the most time to apply as well
2019-08-12 20:52:55 <_ikke_> I need to adopt my script so that it can apply on different base branche
2019-08-12 20:57:45 <Cogitri> It's not git checkout ${release}-stable && git am && git push?
2019-08-12 21:06:32 <mps> not sure, for example I didn't made postgresql for older release because I don't have builders for them
2019-08-12 21:07:09 <mps> and don't want to put burden on commiter to fix my (possible) error
2019-08-12 22:12:36 <tcely> Cogitri: if you are asking why download for latest version of names.root it is to ensure we do not end up with stale data
2019-08-12 22:13:12 <tcely> I started this journey after finding years old copies in various packages
2019-08-12 22:13:23 <Cogitri> Ah, was wondering about that already, mps
2019-08-12 22:13:24 <Cogitri> You could just use docker-abuild which does that for you (I build my stuff in docker images of the respective release)
2019-08-12 22:13:25 <Cogitri> tcley: Couldn't we just bump the pkgver then?
2019-08-12 22:14:20 <Cogitri> Having non-reproducable builds sounds problematic to me
2019-08-12 22:14:33 <mps> Cogitri: thanks, maybe I will look at it when I found some time
2019-08-12 22:16:22 <tcely> Someone needs to define non-reproducible in a useful way. Any version that is no longer published is non-reproducible by definition.
2019-08-12 22:17:51 <tcely> I had a version that was just bumping pkgver but for a reason that was never explained that wasn't good enough so I put together a way to have archived sources since internic doesn't archive those files.
2019-08-12 22:18:38 <tcely> If you need to build from the archive remove the net option. Otherwise, I want the outdated versions to fail check.
2019-08-12 22:37:04 <tcely> Cogitri: just for clarification, the download doesn't circumvent any sum checks the build should fail for both bad signature and wrong version by design.
2019-08-12 22:50:49 <Cogitri> It does circumvent abuild's built-in checksumming, but the main problem with it is that your package of version x might be different from my package of version x because you have version x1 of the downloaded content while I have version x2
2019-08-12 22:50:49 <Cogitri> (if I rebuild the package at a later point but with the same version number)
2019-08-12 22:50:50 <Cogitri> IMHO we should just package that file in the git repo as we previously did to ensure that you always get the same package with the same version number
2019-08-12 22:59:28 <tcely> You're concerned that the same serial would be signed twice with different data? If that's the case, using the source archive makes that impossible.
2019-08-13 04:51:12 <_ikke_> "Cogitri| It's not git checkout ${release}-stable && git am && git push?" Mostly, but especially for older branches (<3.9), I want to verify it actually builds.
2019-08-13 06:32:29 <Cogitri> Ah, thought CI would verify that already
2019-08-13 08:02:49 <_ikke_> Not for older branches, there CI has not been enabled
2019-08-13 08:03:43 <_ikke_> Oh, travis does run on 3.7, n',
2019-08-13 08:03:45 <_ikke_> n/m
2019-08-13 08:08:03 <mps> _ikke_: yes, also I prefer to check if build works at least on one arch before sending patch or push
2019-08-13 08:33:08 <ncopa> hum. i have a weird issue
2019-08-13 08:33:12 <ncopa> linux-vanilla-dev
2019-08-13 08:33:23 <ncopa> 4.19.66 on edge works
2019-08-13 08:33:30 <ncopa> but when building the same package on 3.10
2019-08-13 08:33:54 <ncopa> permissions gets different
2019-08-13 08:34:09 <ncopa> $  apk fetch --stdout linux-vanilla-dev | tar -ztv | grep -- ^-r- | tpaste
2019-08-13 08:34:09 <ncopa> http://tpaste.us/8Vp8
2019-08-13 08:35:31 <ncopa> which causes build failure
2019-08-13 08:35:41 <ncopa> when buildling 3rd party modules
2019-08-13 08:36:02 <ncopa> but how does the permissions end up that way?
2019-08-13 08:42:36 <ncopa> and why does it not happen in edge? its identical APKBUILDs
2019-08-13 08:58:48 <tcely> umask maybe?
2019-08-13 09:01:41 <ncopa> they are seemingly identical
2019-08-13 09:01:50 <ncopa> and also, why only this file and not the others?
2019-08-13 09:01:57 <ncopa> those two files
2019-08-13 09:16:28 <tcely> What do the permissions listed for those files say in the source archive?
2019-08-13 09:16:45 <tcely> The umask tar a0
2019-08-13 09:17:29 <tcely> The umask tar applied during extraction was my guess. https://www.gnu.org/software/tar/manual/html_node/Setting-Access-Permissions.html#SEC84
2019-08-13 09:18:05 <ncopa> no, the permssions gets into the tarball creation
2019-08-13 09:18:11 <ncopa> it smells fakeroot bug
2019-08-13 09:18:48 <ncopa> i build with this as only change: http://tpaste.us/P0yx
2019-08-13 09:19:00 <ncopa> and permissions are correct again
2019-08-13 09:20:33 <ncopa> the ls output also shows correct permissions
2019-08-13 09:26:38 <tcely> On both edge and 3.10 that change shows expected permissions?
2019-08-13 10:27:40 <ncopa> on edge it always shows expected permissions
2019-08-13 10:28:03 <ncopa> on 3.10 it shows expected permissions if i do abuild build && abuild package
2019-08-13 10:28:09 <ncopa> it may be umask after all
2019-08-13 12:46:48 <Mischung12> Dear Alpine community. I need to compile QEMU on my own for sake of some performance evaluation. Apparently, I get the performance of the nginx running inside a VM much faster than the performance of the nginx running on the host OS (both host and guest OSes run Alpine 3.10.1 with the same Kernel). My guess for now is that I forgot to compile QEMU
2019-08-13 12:46:49 <Mischung12> with stack-smashing protection and relocation read-only memory corruption mitigation. Is there a documentation how exactly are apk packages compiled, i.e., with what compiler flags? Thank you!
2019-08-13 12:48:59 <artok> after installing alpine-sdk,  /etc/abuild.conf
2019-08-13 17:55:00 <mps> anyone would push MR !17 from gitlab.a.o
2019-08-13 17:55:18 <mps> openresolv fix
2019-08-13 19:19:43 <mps> what to do if pkg doesn't need build() function? remove it from APKBUILD?
2019-08-13 19:20:01 <_ikke_> sure
2019-08-13 19:20:40 <mps> ok, thanks
2019-08-14 00:39:07 <Danct12_> pr9894
2019-08-14 00:39:15 <Danct12_> is there anyone here merging this?
2019-08-14 04:17:34 <ddevault> ncopa et al: libgit2 0.28.3 and 0.27.9 are security releases
2019-08-14 05:25:12 <iggy> how do I remove the stale tag from a PR of mine?
2019-08-14 05:33:57 <tcely> Which PR?
2019-08-14 05:55:17 <ddevault> remember a while back, I was talking about the riscv64 port
2019-08-14 05:55:41 <ddevault> it was mentioned that existing ports are set up so that alpine devs can get a shell on the target hardware to work from and address issues as necessary
2019-08-14 05:56:01 <ddevault> I put this together today: https://asciinema.org/a/A20uXhdZValNVsCspEPIkWPdU
2019-08-14 05:56:24 <ddevault> works for anyone with a sr.ht account, needn't have any special permissions or negotiate with any humans in advance of their work
2019-08-14 06:16:59 <tcely> What kind of guest is that?
2019-08-14 06:18:52 <ddevault> qemu arm64 in software emulation
2019-08-14 06:19:16 <ddevault> riscv64 will be available in hardware once I get it working, and I should have ppcle64 hardware within a couple of months
2019-08-14 06:31:19 <_ikke_> iggy: by rebasing it for example
2019-08-14 06:36:52 <ncopa> ddevault: are they ABI compatible? iirc libgit2 often breaks abi (and rust which needs to be bootstrapped once again)
2019-08-14 06:37:22 <ddevault> let me investigate
2019-08-14 06:37:47 <ddevault> appears to be compatible to me
2019-08-14 06:37:53 <ncopa> ok. good
2019-08-14 06:37:57 <ddevault> https://github.com/libgit2/libgit2/compare/v0.28.2...v0.28.3
2019-08-14 06:38:47 <Gottox> how do you bootstrap rust in alpine?
2019-08-14 06:39:04 <ncopa> looks like its gonna be a busy day. i need my morning coffe
2019-08-14 06:39:34 <_ikke_> https://abi-laboratory.pro/index.php?view=timeline&l=libgit2
2019-08-14 06:39:54 <_ikke_> 0.28.3 is not mentioned there yet
2019-08-14 06:40:54 <_ikke_> They seem to only break ABI on minor version upgrades
2019-08-14 06:41:03 <_ikke_> 0.27 -> 0.28
2019-08-14 06:41:50 <ddevault> there's no CVE yet, but I asked them about it here: https://github.com/libgit2/libgit2/pull/5202
2019-08-14 07:11:30 <Cogitri> Gottox: We have a rust-bootstrap package which is provided by our rust package
2019-08-14 07:11:48 <Cogitri> The initial bootstrapping is done with tarballs
2019-08-14 07:12:19 <Cogitri> <ncopa "ddevault: are they ABI compatibl"> About that, I can make cargo static, that should make the entire situation way easier to deal with
2019-08-14 07:21:43 <tcely> Doesn't static cargo still need to be rebuilt?
2019-08-14 07:24:14 <iggy> _ikke_: it's mergeable, or do the devs just like to see things rebased so they know it's fresh?
2019-08-14 07:25:26 <_ikke_> iggy: That, and that's when the stale lable automatically gets removed
2019-08-14 07:25:40 <Cogitri> <tcely "Doesn't static cargo still need "> tcely: No, since it only needs libc and rust crates then without depending on dynamic libs
2019-08-14 07:26:37 <tcely> Cogitri: using the static lib doesn't remove the bug
2019-08-14 07:26:57 <Cogitri> "the bug"?
2019-08-14 07:27:08 <Cogitri> Ah, you mean the CVE
2019-08-14 07:27:48 <Cogitri> No, that of course not, but it makes it less of a PITA to rebuild Rust when libgit2 or openssl or smth changes the soname
2019-08-14 07:28:25 <tcely> Ah. For ABI issues then.
2019-08-14 07:28:30 <_ikke_> does rust depend on libgit2?
2019-08-14 07:28:40 <Cogitri> cargo does
2019-08-14 07:28:43 <_ikke_> ah ok
2019-08-14 07:28:47 <Cogitri> And cargo is required for bootstrapping :/
2019-08-14 07:28:52 <_ikke_> yes
2019-08-14 07:29:05 <_ikke_> for building rust in general
2019-08-14 07:29:15 <tcely> Makes sense to me to have static cargo then.
2019-08-14 07:29:31 <Cogitri> So we either need statitic cargo or keep libgit<version> until we have rebuilt rust
2019-08-14 07:29:36 <Cogitri> tcely: Same :)
2019-08-14 07:30:36 <mps> Cogitri: also I agree
2019-08-14 07:30:54 <tcely> We still need to rebuild (and lose tracking via so:) but don't need to do custom old versions.
2019-08-14 07:31:08 <Cogitri> Ah mps, did you have success building rust against our triplets?
2019-08-14 07:32:01 <mps> I worked two days on kernel multi platform for armv7 so didn't had time for rust
2019-08-14 07:32:46 <mps> trying to fix some long standing bugs there
2019-08-14 07:33:56 <Cogitri> Oh, alright, good luck with that
2019-08-14 07:34:48 <mps> Cogitri: I think rust can be built on aarch64, just need to change target in APKBUILD
2019-08-14 07:34:48 <tcely> Cogitri: maybe cargo-dev should depend on libgit2-static for tracking purposes if nothing else.
2019-08-14 07:35:30 <Cogitri> mps: It explodes for me as soon as I change the target in the APKBUILD :/
2019-08-14 07:35:55 <tcely> From unknown to alpine ?
2019-08-14 07:36:15 <mps> please post me your change, I would like to try and see
2019-08-14 07:36:22 <mps> tcely: right
2019-08-14 07:36:27 <Cogitri> Yup
2019-08-14 07:37:35 <Cogitri> Tcely: Somehow I don't need a libgit2-static :o
2019-08-14 07:37:36 <mps> I'm becoming suspicious about llvm8 on aarch64
2019-08-14 07:37:40 <Cogitri> s/need/see/
2019-08-14 07:37:40 <alpine-meetbot> Cogitri meant to say: Tcely: Somehow I don't see a libgit2-static :o
2019-08-14 07:38:10 <Cogitri> mps: It happens on all arches other than x86_64. i doubt this one is on llvm
2019-08-14 07:38:58 <tcely> Cogitri: you may need to create such and others for static cargo to work
2019-08-14 07:39:20 <mps> then something else on these archs, have no idea TBH
2019-08-14 07:40:18 <Cogitri> https://gist.github.com/f8c4a17f8a336a40cc30995414dc9bcf
2019-08-14 07:40:57 <Cogitri> tcely: Ah, had hoped they'd be in -dev already
2019-08-14 07:41:11 <Cogitri> 
ACTION looks up how to move CMake to make both static and dynamic libs

2019-08-14 07:42:26 <Cogitri> Oh wow, I can't...
2019-08-14 07:42:37 <tcely> If they are you can just adjust the split. Sometimes packages refuse to build both. Lots are just using --disable-static
2019-08-14 07:43:01 <_ikke_> https://build.alpinelinux.org/buildlogs/build-3-10-x86/main/nginx/nginx-1.16.1-r0.log hmm, strange
2019-08-14 07:43:39 <tcely> 
ACTION hates rebuilds just to get static libs

2019-08-14 07:44:14 <tcely> 
ACTION glares at krb5 in particular

2019-08-14 07:44:59 <mps> _ikke_: looks like checksum issue
2019-08-14 07:45:20 <_ikke_> yes, but only on the builders
2019-08-14 07:45:56 <mps> clean distfiles?
2019-08-14 07:45:57 <_ikke_> looks like a temporary issue
2019-08-14 07:47:14 <tcely> transfer issue probably
2019-08-14 07:47:28 <_ikke_> yup
2019-08-14 07:51:57 <tcely> Are there thoughts on having default_static  depend on $pkgname-dev (when that is in subpackages) by default?
2019-08-14 07:52:19 <Danct12_> Anyone going to merge pr9894?
2019-08-14 07:53:56 <ddevault> libgit2 issue is CVE-2019-1211
2019-08-14 07:54:00 <ddevault> ncopa: CVE-2019-1211
2019-08-14 07:55:51 <ncopa> Danct12_: i can look at it in a bit
2019-08-14 07:58:31 <ncopa> Danct12_: please feel free to ping me in an hour or so if i forget
2019-08-14 07:59:42 <_ikke_> iggy: what is the PR?
2019-08-14 08:03:21 <Cogitri> tcely: Sounds like a good idea
2019-08-14 08:04:20 <tcely> _ikke_: pr7894 I believe
2019-08-14 08:08:34 <tcely> That DroneCI hasn't fixed the max output issue really irks me
2019-08-14 08:09:38 <_ikke_> THat some projects output enorumous amount of output is not that good either
2019-08-14 08:14:29 <tcely> Sure, but at least show the end of the log to me. https://github.com/drone/drone/pull/2456
2019-08-14 08:14:45 <iggy> 7894 is correct
2019-08-14 08:52:28 <ddevault> this https://builds.sr.ht/api/jobs/81220/manifest became this -> https://builds.sr.ht/~sircmpwn/job/81220 became this -> https://asciinema.org/a/wnLYZwDuvkbIHwgTdmnqtQpXh
2019-08-14 08:52:31 <ddevault> not bad imo
2019-08-14 09:03:33 <ncopa> thats pretty cool
2019-08-14 09:05:00 <_ikke_> https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/358
2019-08-14 09:06:12 <ncopa> nice
2019-08-14 09:09:07 <Danct12_> ncopa: quick reminder on pr9894
2019-08-14 09:12:11 <ncopa> Danct12_: i did a review and added a comment
2019-08-14 09:12:28 <Danct12_> ah
2019-08-14 09:12:33 <Danct12_> okay
2019-08-14 09:24:32 <tcely> ddevault: nice progress
2019-08-14 09:32:54 <ddevault> tcely: thanks :)
2019-08-14 10:50:46 <kr0k0> Hi all
2019-08-14 10:51:50 <kr0k0> Is there a reason that pr9551 isn't backported to 3.10?
2019-08-14 10:55:03 <_ikke_> I
2019-08-14 10:55:10 <_ikke_> I'm not sure if there was a specific reason
2019-08-14 10:58:42 <kr0k0> Ok, it would be nice to have latest 4.10 samba in latest stable alpine.
2019-08-14 11:02:33 <MY_R> kr0k0, 4.10.5 is in stable
2019-08-14 11:04:26 <_ikke_> 4.10.6 is latest
2019-08-14 11:04:45 <MY_R> ye but what is the point to backport it to stable?
2019-08-14 11:06:21 <_ikke_> it's a patch release, so it would be eligable to be backported
2019-08-14 11:08:55 <mps> if it fixes or improves some thing it should be backported
2019-08-14 11:09:35 <_ikke_> That's generally the case with patch releases
2019-08-14 11:10:25 <mps> ofc, we should keep eye on important pkg's in latest stable
2019-08-14 11:11:22 <mps> openresolv, for example ;-)
2019-08-14 11:12:37 <MY_R> ook, good to know that is possible to have prety fresh packages in stable :)
2019-08-14 11:13:21 <mps> MY_R: not fresh, but fixed
2019-08-14 11:13:34 <mps> fresh are special case
2019-08-14 11:13:50 <MY_R> well, every version change in any software fix something :)
2019-08-14 11:14:20 <_ikke_> It should *only* fix things, not introduce new (potentially unstable) features
2019-08-14 11:14:52 <mps> true, but most add something totally new and changes some things and that is not good for backport
2019-08-14 11:15:37 <mps> people expect stable to be without sudden and unexpected changes
2019-08-14 11:15:43 <MY_R> yep agree
2019-08-14 11:28:08 <_ikke_> Anyone familiar with lua can give feedback on this? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/14#note_48237
2019-08-14 11:40:04 <kr0k0> So, who is able to backport it?
2019-08-14 11:40:21 <_ikke_> Anyone is able to make a merge request for it :-)
2019-08-14 11:40:34 <kr0k0> Yes ^^
2019-08-14 13:40:27 <nmeum> ddevault: do I recall correctly that you did some work on porting alpine to riscv? if so: what's your progress on this?
2019-08-14 13:40:52 <ddevault> stalled
2019-08-14 13:41:05 <ddevault> at some point I'll retarget my work onto a stable alpine release
2019-08-14 13:41:13 <ddevault> but I don't see much value in it until a better solution for booting is found
2019-08-14 13:41:26 <ddevault> a uboot port exists for my hardware but a crucial component remains unported
2019-08-14 13:41:35 <ddevault> the current solution is not sustainable
2019-08-14 13:42:01 <ddevault> if you want to help, that would be a good place to start. Do you have a HiFive board?
2019-08-14 13:42:11 <ddevault> if not, I will look into it... at some point...
2019-08-14 13:43:15 <nmeum> no, I currently don't have an unleashed board, will get access to one in a few months hopefully
2019-08-14 13:43:51 <ddevault> I normally offer shell access on my board to interested stakeholders... but that won't do much good for booting
2019-08-14 13:44:24 <ddevault> you may be able to coerce qemu into emulating all of the necessary hardware to work on this
2019-08-14 13:44:33 <ddevault> the issue is the lack of mmcblk support from uboot on the hifiveu
2019-08-14 13:44:37 <nmeum> i am asking because i am working in a university research project where we are building a riscv emulator which can boot linux. currently using freedom-u-sdk but want to migrate away from that
2019-08-14 13:45:08 <ddevault> I do have a public package repository, and although it's pretty stale it is self hosting
2019-08-14 13:45:21 <ddevault> https://mirror.sr.ht/alpine/main/riscv64/
2019-08-14 13:45:24 <nmeum> thanks
2019-08-14 13:45:34 <ddevault> there's also (small) community and testing repos on this server at the obvious location
2019-08-14 13:45:40 <ddevault> signing key is one dir up
2019-08-14 13:46:40 <ddevault> YMMV, but this should be suitable to do a foreign bootstrap via apk add --arch=risv64 --root=... --initdb et al
2019-08-14 13:47:14 <ddevault> if you can get a qemu-user-static chroot or something similar working, from that point you can chroot into the system and run apk fix to connect up the fiddly bits
2019-08-14 13:47:32 <nmeum> are your aports patches available somewhere as well?
2019-08-14 13:47:38 <ddevault> https://git.sr.ht/~sircmpwn/aports
2019-08-14 13:47:54 <ddevault> also https://git.sr.ht/~sircmpwn/abuild has a necessary patch
2019-08-14 13:48:05 <nmeum> ok, great
2019-08-14 13:48:15 <ddevault> the system works fairly well if you can get it up and running
2019-08-14 13:48:24 <ddevault> good luck
2019-08-14 13:48:43 <ddevault> it can build itself and the go team used my system to work on porting go to riscv64
2019-08-14 13:49:04 <ddevault> I did run into some issues with nghttp2, which sealed off a sizable portion of aports, however
2019-08-14 13:50:45 <ddevault> @grep riscv@ making a note in my logs for the next time someone asks
2019-08-14 13:59:05 <nmeum> I can probably get around that entire booting issue by using bbl from riscv-pk, will make some experiments with this. thanks for the detailed info!
2019-08-14 14:10:39 <mps> do we have policy where to put udev rules for pkg's? /lib or /usr/lib
2019-08-14 14:11:47 <mps> I think rules for system programs go in /lib and for user programs under /usr/lib
2019-08-14 14:12:05 <mps> right?
2019-08-14 14:12:17 <nmeum> there is also /etc/udev/rules.d
2019-08-14 14:12:45 <mps> I think there goes user generated and created rules
2019-08-14 14:12:57 <nmeum> some packages also install rules to it e.g. communityiccid
2019-08-14 14:12:58 <mps> not from packages
2019-08-14 14:13:02 <nmeum> *community/ccid
2019-08-14 14:13:40 <mps> I think under /etc are rules generated at pkg install time
2019-08-14 14:13:55 <mps> not sure, TBH
2019-08-14 14:14:39 <nmeum> is there any packages which install udev rules to /usr/lib?
2019-08-14 14:15:05 <mps> I think /usr/lib/udev
2019-08-14 14:15:15 <nmeum> hm, community/libwacom seems to do that
2019-08-14 14:15:34 <mps> /usr/lib/udev/rules.d/90-libinput-model-quirks.rules
2019-08-14 14:16:16 <nmeum> I just did grep -R rules.d on aports
2019-08-14 14:16:45 <nmeum> tbh I don't think there is any policy on this
2019-08-14 14:18:28 <mps> I think same, although looks like most pkg's puts them under /lib
2019-08-14 14:19:51 <nmeum> yep
2019-08-14 14:20:48 <mps> thanks for brainstorming, I will put them under /usr/lib for user space program I'm making apk
2019-08-14 14:22:28 <mps> (looks like we need some policy guides for some things)
2019-08-14 14:24:11 <jwh> hey is anyone planning to bump go to .8?
2019-08-14 14:35:08 <mps> ddevault: do you have any image for riscv for qemu, I think it is time to start learn about it
2019-08-14 15:00:36 <_ikke_> I'm going to upgrade gitlab, it will be down for a moment
2019-08-14 15:51:01 <maxice8> Udev rules from packages should go to /usr/lib/udev
2019-08-14 15:52:30 <maxice8> etc/udev is for local admins, it can override rules in /usr/lib/udev with the same name
2019-08-14 17:34:56 <maxice8> It is documented by udev upstream
2019-08-14 17:51:56 <mps> maxice8: do you mean from user space pkgs go to /usr/lib/udev ?
2019-08-14 17:52:36 <maxice8> User space packages mean?
2019-08-14 17:53:01 <mps> programs used by user
2019-08-14 17:53:18 <mps> not system programs/daemons
2019-08-14 17:57:40 <Cogitri> All packages should install to /usr/lib/udev
2019-08-14 17:58:04 <Cogitri> TL;DR Only use /etc/udev when you're manually editing smth yourself
2019-08-14 17:58:21 <Cogitri> (e.g. for the user's custom rules)
2019-08-14 17:58:50 <mps> Cogitri: thats clear, but for what we habe /lib/udev then
2019-08-14 17:59:20 <mps> s/habe/have/
2019-08-14 17:59:20 <alpine-meetbot> mps meant to say: Cogitri: thats clear, but for what we have /lib/udev then
2019-08-14 17:59:29 <Cogitri> Ah right, we don't have usrmerge
2019-08-14 17:59:39 <mps> (german in my soul ;-) )
2019-08-14 18:01:14 <mps> ok, looks like my thought was right, just wanted confirmation from you
2019-08-14 18:03:20 <danieli> it would be 'wir haben' in german
2019-08-14 18:03:47 <_ikke_> (there is a native German here :-))
2019-08-14 18:04:04 <danieli> that's one of the few things i remember from german in school :P
2019-08-14 18:04:43 <_ikke_> ich habe, du hast
2019-08-14 18:05:01 <danieli> ich hab(e), du hast, er/sie/es hat, wir haben, ihr habt, sie haben
2019-08-14 18:05:15 <Cogitri> <_ikke_ "(there is a native German here :"> I think multiple even :P
2019-08-14 18:05:24 <danieli> not a surprise with 180 people here
2019-08-14 18:05:28 <mps> my german from school faded away because I didn't used it for more than two decades
2019-08-14 18:06:18 <mps> although I mostly read german and didn't write or speak much
2019-08-14 18:06:45 <clandmeter> i remember we discussed this recently, but what provides machine-id?
2019-08-14 18:06:54 <clandmeter> dbus i guess
2019-08-14 18:07:03 <mps> dbus, i think
2019-08-14 18:07:21 <clandmeter> so without dbus i will never have it?
2019-08-14 18:07:27 <clandmeter> there is no lightweight alternative?
2019-08-14 18:07:49 <mps> I think something else also can create it, but forgot what
2019-08-14 18:08:20 <mps> (not useful answer, i know)
2019-08-14 18:08:59 <clandmeter> fabled was talking about it
2019-08-14 18:09:02 <clandmeter> not s ure what the result was
2019-08-14 18:09:30 <mps> last week I followed discussion on debian-devel ML about that, but as usual stopped to follow to the end
2019-08-14 18:38:28 <maxice8> clandmeter: i think dbus-uuidgen in dbus.pre-install
2019-08-14 18:39:09 <clandmeter> ok but what if i dont have it installed?
2019-08-14 18:41:11 <maxice8> You won't have machine-id
2019-08-14 18:44:41 <clandmeter> ok, so i need to install dbus to be able to get that file.
2019-08-14 18:49:10 <maxice8> Yes but you can manually make it
2019-08-14 18:50:38 <clandmeter> i understand that much
2019-08-14 18:50:59 <_ikke_> What requires machine-id?
2019-08-14 18:51:25 <clandmeter> cluster env
2019-08-14 18:57:49 <clandmeter>  i guess i can use /proc/sys/kernel/random/uuid
2019-08-14 18:59:26 <mps> or uuidgen from util-linux
2019-08-14 18:59:44 <clandmeter> i dont want any deps
2019-08-14 19:43:58 <MY_R> clandmeter, or /proc/sys/kernel/random/boot_id
2019-08-14 19:44:26 <clandmeter> MY_R: that wont work
2019-08-14 19:45:17 <MY_R> no? :\
2019-08-14 19:45:35 <clandmeter> not if you need it to be unique
2019-08-14 19:45:50 <clandmeter> all containers will have the same uuid
2019-08-14 19:45:52 <MY_R> but it should be but just changing every boot
2019-08-14 19:46:15 <MY_R> ah
2019-08-14 19:46:21 <clandmeter> start 2 containers and see if they both have unique ids :)
2019-08-14 19:46:23 <MY_R> then ye, wont work
2019-08-14 19:46:38 <MY_R> yep
2019-08-14 20:10:00 <_ikke_> ncopa: go failed to build on armv7
2019-08-14 20:10:09 <_ikke_> test failure
2019-08-14 20:12:01 <ncopa> ugh... ok
2019-08-14 20:17:16 <ncopa> interestingly, it only happens on edge armv7 and s390x
2019-08-14 20:20:17 <ncopa> and it does not fail on my dev box
2019-08-14 20:20:23 <ncopa> so test is flaky
2019-08-14 20:27:04 <_ikke_> Those are fun
2019-08-14 22:41:04 <ddevault> mps: no, I don't have a qemu image handy
2019-08-14 22:41:10 <ddevault> mps: I've only worked with it on hardware
2019-08-14 22:45:06 <mps> ok, thanks. I looked at debian page about that, maybe will try to run it in qemu. Is it good idea in your experience
2019-08-15 08:16:57 <mps> ddevault: heh, GKH noted aerc here http://kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/
2019-08-15 08:17:50 <ddevault> he wrote this article at my request, mps :)
2019-08-15 08:19:38 <mps> yes, I presume that you have 'your fingers' there from reading article. btw, nice to read it
2019-08-15 08:20:22 <ddevault> I'll write a follow-up post next week explaining how aerc plans to meet the challenge
2019-08-15 08:20:35 <ddevault> definitely changes what I had planned for mbox support
2019-08-15 08:20:37 <mps> didn't know it is written in go
2019-08-15 08:21:27 <mps> I didn't tried to use it because had (false) thought it is python
2019-08-15 08:21:50 <ddevault> I do know several programming languages :P
2019-08-15 08:22:31 <ddevault> it was originally written in C but I eventually scrapped it and rewrote it in Go
2019-08-15 08:22:33 <mps> yes, I know. I wonder why I thought it is written in python
2019-08-15 08:22:42 <ddevault> implementing a thousand string munging standards is just annoying in C
2019-08-15 08:23:46 <mps> agree fully, C is not for writing bigger user space programs
2019-08-15 08:23:56 <ddevault> I would not go that far
2019-08-15 08:24:27 <mps> ofc, hard to draw line
2019-08-15 08:44:45 <TBB> yeah, I've never been capable of drawing it
2019-08-15 08:45:08 <TBB> I mostly write shell scripts, some of them of the size where most people would go "dude, you don't write shell scripts that long"
2019-08-15 08:47:07 <ddevault> nothing wrong with long shell scripts so long as the entire problem is well solved by shell scripts
2019-08-15 08:57:01 <TBB> but that's almost never the case, with the amount of external programs called by shell sripts and all
2019-08-15 09:12:00 <ddevault> that's not what I mean
2019-08-15 10:21:22 <Cogitri> PureTryOut: since I can't seem to find you on g.a.o , maybe this is interesting to you and PmOS: https://gitlab.alpinelinux.org/alpine/aports/issues/10733
2019-08-15 10:22:40 <PureTryOut[m]> Hmm I am on g.a.o though, just as @PureTryOut
2019-08-15 10:23:31 <PureTryOut[m]> Seems good though! Since we use Phosh on pmOS, we're definitely interested in it
2019-08-15 10:23:57 <PureTryOut[m]> We want to move to Alpine stable sometime soon, my goal is Alpine 3.11, so I'm also planning on having Plasma in community by then
2019-08-15 10:25:11 <_ikke_> Cogitri: step 2 has a typo: s/gnome-shell are/ gnome-shell aren't/
2019-08-15 10:25:38 <Cogitri> <PureTryOut[m] "Hmm I am on g.a.o though, just a"> Huh, it didn't suggest your name when I typed @PureTry so I figured you weren't on GL, but maybe I have to type the name out before it suggests me your name if I haven't mentioned you before
2019-08-15 10:25:57 <Cogitri> ikke: Ah, thanks
2019-08-15 10:26:55 <PureTryOut[m]> Cogitri: https://gitlab.alpinelinux.org/PureTryOut
2019-08-15 10:28:08 <Cogitri> Yeah, works if I ping you manually, somehow GL didn't suggest your name in that handy suggestion box that pops up when you start typing @Name
2019-08-15 10:28:18 <PureTryOut[m]> I'm off for today btw (am on holiday atm)
2019-08-15 10:28:58 <Cogitri> Oh, I'll be on holidays starting tomorrow too :)
2019-08-15 10:29:24 <Cogitri> Have a nice time :)
2019-08-15 10:29:48 <_ikke_> o/
2019-08-15 10:30:14 <_ikke_> I hope you will have better weather than we have now
2019-08-15 10:31:10 <Cogitri> I'll be going to England, so I think I was asking for bad weather :P
2019-08-15 10:31:40 <_ikke_> haha :D
2019-08-15 10:34:06 <danieli> the weather has been nice in the UK this summer but summer is close to ending, we're in the middle of August already
2019-08-15 10:34:10 <danieli> been there a couple times
2019-08-15 10:35:55 <_ikke_> Same here in NLD
2019-08-15 10:36:09 <_ikke_> I hope we still have some nice weather ahead
2019-08-15 10:38:36 <mps> I made simple one line patch for linux-vanilla APKBUILD to move dtb files from /usr/lib to /boot/dtbs/$kver
2019-08-15 10:38:59 <danieli> we're getting 20+ here this weekend apparently
2019-08-15 10:39:19 <mps> before posting it to GL want to ask what you all think about naming it
2019-08-15 10:40:16 <mps> i.e. directly under /boot/$kver or /boot/dtbs/$kver or something else
2019-08-15 10:41:24 <mps> and, /boot/dtbs/$kver seems most appropriate to me
2019-08-15 10:43:41 <Cogitri> +1 for putting it in a subdir
2019-08-15 10:44:45 <mps> thanks, also want to hear if someone have objections about this move
2019-08-15 12:43:30 <Cogitri> ikke: Would it make sense to restrict the linting CI job to only run for MRs filed against master?
2019-08-15 12:43:42 <Cogitri> I don't think we want linting for backports, or do we?
2019-08-15 12:48:10 <_ikke_> It doesn't hurt if you accept the fact that the lint job just gives warnings you can heed or ignore
2019-08-15 12:49:01 <Cogitri> Hm sure, I'm just unsure if those warnings are ever going to be useful for backports
2019-08-15 12:49:54 <Cogitri> And if it warns in about every CI job you get desensitized and just shrug them off
2019-08-15 12:55:24 <Cogitri> Also, for something completely different, znc deletes old releases off their distfiles server and we can't build from github tags (since those don't contain the necessary submodules), what do we do about that? Should we mirror the old release somewhere or bump znc in backports?
2019-08-15 13:05:01 <MY_R> Cogitri, https://znc.in/releases/archive/ ?
2019-08-15 13:05:22 <MY_R> or which distfiles? :\
2019-08-15 13:05:40 <Cogitri> Oh, how did I not see that :D
2019-08-15 13:05:41 <Cogitri> Thanks ^^
2019-08-15 13:05:57 <MY_R> there is also current version too :)
2019-08-15 13:07:48 <Cogitri> I guess I'll just patch the old version
2019-08-15 13:40:47 <mps> _ikke_: nice, it works https://gitlab.alpinelinux.org/mps/aports/pipelines/155/failures
2019-08-15 13:40:58 <mps> lint checker, I mean
2019-08-15 13:41:46 <_ikke_> Nice
2019-08-15 13:51:06 <andypost[m]> any idea what's wrong with libbz2 for arm7 in CI https://cloud.drone.io/alpinelinux/aports/9602/5/1
2019-08-15 13:52:09 <_ikke_> Some kind of issue with the dependencies apparently
2019-08-15 13:54:22 <mps> andypost[m]: bad sig, I had it about hour ago with bzip
2019-08-15 13:54:32 <mps> try again
2019-08-15 13:57:05 <andypost[m]> mps: restarted build but still the same
2019-08-15 13:57:18 <ncopa> oh
2019-08-15 13:57:28 <ncopa> it may be due to I rebuild bzip2 earlier
2019-08-15 13:57:34 <mps> hmm, danieli told me he fixed it
2019-08-15 13:57:37 <ncopa> on the armv7
2019-08-15 13:57:49 <danieli> mps: i just cleared the cache for bzip2
2019-08-15 13:57:54 <danieli> nothing else
2019-08-15 13:57:58 <ncopa> yeah, that should do it
2019-08-15 13:58:06 <mps> I had this with bzip2 on armv7 trying to upgrade clamav
2019-08-15 13:58:20 <ncopa> i wonder if I should just bump pkgrel on bzip2
2019-08-15 13:58:21 <danieli> for arch in x86 x86_64 aarch64 armv7 ppc64le; do curl -X PURGE "http://dl-cdn.alpinelinux.org/alpine/edge/main/$arch/bzip2-dev-1.0.8-r0.apk"; done
2019-08-15 13:58:23 <danieli> that's what i did
2019-08-15 13:58:24 <ncopa> also
2019-08-15 13:58:49 <mps> danieli: that helped me
2019-08-15 13:58:57 <ncopa> i wonder if the static package name should be bzip2-static in stead of libbz2-static
2019-08-15 13:59:52 <mps> I wonder why you named libs with -static at all
2019-08-15 14:00:38 <ncopa> where?
2019-08-15 14:02:14 <mps> a lot of apk's have suffix -static and contains static libs
2019-08-15 14:04:46 <mps> ofc, I don't mean you named it all, but as project leader you allowed that
2019-08-15 14:06:48 <mps> although I understand that is not easy position, it is not criticism to you personally just hint we should think how to consolidate naming schemes for pkg's
2019-08-15 14:07:13 <andypost[m]> hm, it does not help armv7 edge builder https://cloud.drone.io/alpinelinux/aports
2019-08-15 14:11:24 <Cogitri> +1 mps, although I personally think libbz2-static is a good name I feel like it'd be good to have some common rules how to name things so we have some consistency
2019-08-15 14:12:16 <danieli> i was of the impression we stick to the upstream name where possible, so if the bzip2 library calls itself libbz2 we'd call it libbz2
2019-08-15 14:12:27 <danieli> and that -static counterparts are made on demand
2019-08-15 14:14:11 <mps> but we have bzip2-dev
2019-08-15 14:15:21 <mps> andypost[m]: looks like it passed
2019-08-15 14:15:38 <andypost[m]> in builders but not in CI
2019-08-15 14:16:21 <mps> different urls in /etc/apk/repositories ?
2019-08-15 14:17:16 <Cogitri> Or maybe the CDN hasn't synched fully yet?
2019-08-15 14:23:50 <clandmeter> cdn doesnt sync :)
2019-08-15 14:24:42 <_ikke_> CDN fetches from dl-4 on demand
2019-08-15 14:27:38 <danieli> and filenames themselves function as cache busters
2019-08-15 14:35:45 <ncopa> re naming -static
2019-08-15 14:36:26 <ncopa> im kind of leaning towards "$pkgname-static", regardless of if there is a -libs subpackage or similar
2019-08-15 14:36:55 <ncopa> then you only need to worry abour foo-dev and foo-static
2019-08-15 14:37:14 <ncopa> and not figure out what foosomethingelse-static is named
2019-08-15 14:41:35 <ncopa> pushed the change
2019-08-15 14:41:52 <ncopa> should probably fix the cdn issues as well
2019-08-15 15:02:23 <andypost[m]> It fixed CI, thanks @ncopa
2019-08-15 15:55:00 <mps> maxice8: I see mupdf 1.16.0 just pushed and I made MR for 1.16.1 about two hours ago, https://gitlab.alpinelinux.org/alpine/aports/merge_requests/28
2019-08-15 18:35:00 <maxice8> mps: im out of action
2019-08-15 18:35:27 <maxice8> Or rather, was, will be coming back later today
2019-08-15 18:36:37 <mps> maxice8: no, I updated MR
2019-08-15 18:36:57 <mps> s/no/np/
2019-08-15 18:36:57 <alpine-meetbot> mps meant to say: maxice8: np, I updated MR
2019-08-15 18:48:20 <tcely> Re -static: wasn't -libs-static vs -static because static binaries and static libs should be named differently?
2019-08-15 18:50:07 <tcely> cargo-static and bzip2-static being static binaries. Whereas libbz2-static or bzip2-libs-static contain lib*.a files
2019-08-15 18:53:52 <mps> I don't care much, but imo static libs belongs to $pkg-dev together with shared
2019-08-15 18:58:14 <tcely> I'm not familiar with why .a was split from -dev but it does tend to free up space when they are not needed
2019-08-15 18:59:33 <mps> true, but dev boxes need space anyway
2019-08-15 20:21:40 <ncopa> why would we want/need a bzip2 static binary?
2019-08-15 20:31:50 <mps> except apk-tools-static and busybox-static I don't see need for any other static pkg
2019-08-15 20:51:13 <maxice8> I'm back, sorry for being away for a few days
2019-08-15 20:53:18 <mps> maxice8: welcome back, and no need to sorry, we all have life and $dayjobs
2019-08-15 20:55:12 <maxice8> :D went get a surgery
2019-08-15 20:55:58 <mps> uhmm, I hope everything is ok now
2019-08-15 20:58:56 <danieli> welcome back :) hope you're all right
2019-08-15 21:10:35 <maxice8> danieli: just slight discomfort while sitting and walking around but mostly fine
2019-08-16 04:50:16 <Cogitri> https://lwn.net/Articles/795384/ seems very interesting for us to for smaller debug info
2019-08-16 05:47:33 <ncopa> hi maxice8! nice to have you back! I hope everything went well and that you are recovering well
2019-08-16 07:10:10 <mps> Cogitri: yesterday read this article and comments, and I suspect that CTF will become mainstream in near future, if ever
2019-08-16 07:59:21 <Cogitri> s/will/wont/ ?
2019-08-16 09:02:03 <maxice8> ddevault: merged, ammended commit to remove an empty variable
2019-08-16 09:04:00 <ddevault> thanks maxice8
2019-08-16 11:06:46 <maxice8> ddevault: welcome
2019-08-16 11:35:00 <mps> _ikke_: thanks for pushing MR's I posted, and sorry I didn't cleaned them
2019-08-16 11:36:20 <mps> actually when upgrading pkg for which I'm not maintainer I don't like to change it much, just minimal changes enough to build and work
2019-08-16 11:36:44 <mps> cosmetic changes I prefer to left to maintainer or someone else
2019-08-16 11:37:57 <mps> ddevault: thanks for packaging stellarium, I have it for some time in my 'back brain' but never found time to try to make APKBUILD
2019-08-16 11:43:16 <Cogitri> Could someone delete https://gitlab.alpinelinux.org/alpine/aports/issues/10733#note_48743 for me please to remove the advertising link? My mobile net isn't good enough to load the site
2019-08-16 11:53:54 <_ikke_> Cogitri: What link? ;-)
2019-08-16 14:51:40 <ddevault> mps: np, I needed it for something
2019-08-16 14:51:47 <ddevault> / b1
2019-08-16 14:51:50 <ddevault> disregard last
2019-08-16 14:52:50 <mps> nice app, to know what I look at night sky
2019-08-16 15:40:10 <ncopa> this was pretty good. usfeul for patch creators and reviewers https://www.slideshare.net/xen_com_mgr/xpdds19-keynote-patch-review-for-nonmaintainers-george-dunlap-citrix-systems-uk-ltd
2019-08-16 16:16:33 <Cogitri> ikke: Thanks :)
2019-08-16 16:38:09 <_ikke_> Cogitri: gnome-control-center is failing to build for some time on ppc64le
2019-08-16 16:38:53 <_ikke_> "../tests/datetime/test-timezone-gfx.c:5:10: fatal error: cc-datetime-resources.h: No such file or directory"
2019-08-16 17:00:29 <maxice8> _ikke_: I think it is best to disable (or limit) it at the moment
2019-08-16 17:06:45 <Cogitri> Yes, not really available until Monday. I guess it's fails due to some ordering issue during build (no clue why that only happens on ppc64le)
2019-08-16 17:08:18 <Cogitri> You could grep the build.ninja meson generates for that file to see what build target builds it and then manually build it before `ninja -C build` is invoked, see NetworkManager for how that's done
2019-08-16 18:49:22 <maxice8> @ddevault x86 keeps failing too build stellarium
2019-08-17 00:29:46 <ddevault> maxice8: logs?
2019-08-17 00:30:35 <maxice8> ddevault: on #alpine-commits
2019-08-17 00:30:55 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/stellarium/stellarium-0.19.1-r0.log
2019-08-17 00:30:58 <maxice8> first one for free :D
2019-08-17 00:31:37 <ddevault> is this x86 as opposed to x86_64 (in other words, is this 32 bit?)
2019-08-17 00:31:50 <maxice8> yes
2019-08-17 00:32:03 <maxice8> on Void it is i686 and debian uses i386 (i think)
2019-08-17 00:32:10 <maxice8> naming architectures is confusing
2019-08-17 00:33:15 <ddevault> everyone should just name it after what the kernel names it
2019-08-17 00:33:46 <ddevault> anyway, the solution I'm eyeing now is to disable tests on x86
2019-08-17 00:36:04 <maxice8> arch/x86 on the kernel tree
2019-08-17 00:36:14 <maxice8> but arch/arm64 on kernel tree while we use aarch64
2019-08-17 00:41:37 <ddevault> uname -m
2019-08-17 00:41:48 <ddevault> which is aarch64 for linux, so that helps
2019-08-17 00:42:00 <maxice8> i686 for uname -m
2019-08-17 00:42:21 <ddevault> note i386 is a different but mostly compatible architecture
2019-08-17 00:42:28 <ddevault> i486 and i586 as well, though less common
2019-08-17 00:42:49 <ddevault> imo i686 is the only modern descendant of that family which bears any relevance
2019-08-17 08:58:59 <MY_R> hmm, could somebody bump "mpv" rev? :\ should be recompiled with that new ffmpeg
2019-08-17 09:03:32 <MY_R> ^ http://ix.io/1RZ9
2019-08-17 11:54:24 <maxice8> Ah, forgot about that mpv fun quirk
2019-08-17 11:54:36 <maxice8> I think audacious-plugins also has to be rebuilt
2019-08-17 11:58:24 <PureTryOut[m]> _ikke_: could you explain `lua-aports` to me? `buildrepo` just complains that it can't open `/usr/share/abuild/functions.sh` and `/etc/abuild.conf`...
2019-08-17 12:01:50 <PureTryOut[m]> Also, there seems to be no Git repo for it's source?
2019-08-17 12:02:55 <danieli> https://git.alpinelinux.org/lua-aports/
2019-08-17 12:02:59 <danieli> https://github.com/alpinelinux/lua-aports
2019-08-17 12:02:59 <PureTryOut[m]> Ok `lua-aports` should probably depend on `abuild` at runtime...
2019-08-17 12:03:07 <danieli> sounds about right
2019-08-17 12:03:29 <PureTryOut[m]> Is it possible to run this thing with docker abuild?
2019-08-17 12:04:29 <PureTryOut[m]> Oh derp
2019-08-17 12:04:39 <PureTryOut[m]> I was confused by the source not being Gitlab or GIthub
2019-08-17 12:05:19 <MY_R> maxice8, I'm not sure but mpv in 3.10 can be affected too
2019-08-17 12:09:15 <maxice8> MY_R: I think it was a security upgrade and not to 4.2
2019-08-17 12:09:18 <maxice8> But we'll see
2019-08-17 12:11:21 <MY_R> yep it was just 4.1.3 -> 4.1.4 but dunno what to think about mpv: https://github.com/mpv-player/mpv#ffmpeg-abi-compatibility
2019-08-17 12:11:23 <MY_R> :D
2019-08-17 12:11:59 <maxice8> well i'm heading out to hospital and stuff so i'll revbump if someone reports it doesn't work
2019-08-17 12:12:02 <PureTryOut[m]> Ugh I can't use docker-abuild anymore now... `ERROR: abuild-3.4.0-r1: failed to rename etc/.apk.20355fec109a722a4603e5fe831d66fdb8ac5bd4434a4a31 to etc/abuild.conf.`
2019-08-17 12:12:18 <maxice8> PureTryOut: Need to rebuild the docker image, yes it is super annoying
2019-08-17 12:12:21 <PureTryOut[m]> This same thing is also the reason I can't install `libretro-beetle-psx`
2019-08-17 12:12:53 <PureTryOut[m]> Well the image isn't local so I can't rebuild it really... `alpinelinux/docker-abuild`
2019-08-17 12:16:48 <PureTryOut[m]> How do you use buildrepo to just build the changed packages? I rather not build the entire testing repo just because I changed some packages with deps on each other...
2019-08-17 12:16:51 <danieli> but you can get a hold of the source used to build that image
2019-08-17 12:16:55 <danieli> and in turn build it
2019-08-17 12:18:16 <MY_R> maxice8, ok I ran mpv on 3.10 and it didnt cry about so all fine, thank you and good luck! :)
2019-08-17 12:48:47 <maxice8> Ty
2019-08-17 12:59:43 <_ikke_> PureTryOut[m]: I think lua-aports assumes you have alpine-sdk installed
2019-08-17 13:00:56 <_ikke_> PureTryOut[m]: we use git diff to find the changes aports, then feed them to ap builddirs to get them in dependency order
2019-08-17 13:02:17 <PureTryOut[m]> So what would an example command be?
2019-08-17 13:06:51 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/blob/master/overlay/usr/local/bin/build.sh#L85
2019-08-17 13:13:17 <PureTryOut[m]> Ah thanks!
2019-08-17 13:51:06 <PureTryOut[m]> Hmm can't get it to work. `ap builddirs` just sees the contents of `$aports` as a single package name so it complains it can't find the APKBUILD
2019-08-17 14:00:13 <_ikke_> Did you put it in double quotes?
2019-08-17 14:01:46 <_ikke_> You can also do ` | xargs ap builddirs`
2019-08-17 14:03:42 <PureTryOut[m]> The `$aports` variable? No
2019-08-17 17:25:58 <maxice8> git now has switch and restore to deal with checkout
2019-08-17 17:46:03 <PureTryOut[m]> Yeah I can't get `ap builddirs` to work...
2019-08-17 17:46:27 <PureTryOut[m]> I guess I have to loop over the `$aports` variable, but I'm not sure why it would work on the Gitlab CI
2019-08-17 17:46:34 <PureTryOut[m]> *why it works
2019-08-17 18:32:36 <_ikke_> PureTryOut[m]: you need to verify the arguments you are passing
2019-08-17 18:34:19 <PureTryOut[m]> Well I
2019-08-17 18:34:37 <PureTryOut[m]> *I've printed it out, it's just a list of the changed aports
2019-08-17 21:55:38 <_ikke_> PureTryOut[m]: Apparently it needs to be the package/directory name of the aport
2019-08-17 21:56:03 <_ikke_> http://tpaste.us/Q1bz
2019-08-17 21:56:13 <_ikke_> This is what I used to build all the kdeframework packages
2019-08-17 22:07:56 <PureTryOut[m]> ah so you are looping over it then
2019-08-17 22:08:04 <PureTryOut[m]> Thanks, will take another shot at it tomorrow
2019-08-17 22:09:39 <_ikke_> I loop over the output of ap builddirs
2019-08-17 22:10:30 <PureTryOut[m]> Oh wait yeah, you give the git result via xargs
2019-08-17 23:03:32 <PureTryOut[m]> maxice8: how is the testing of my Kodi patch going?
2019-08-18 00:10:54 <maxice8> What patch ? 18.2 ?
2019-08-18 08:10:37 <Geod2441> Hey guys, I am trying to add support for the D programming language to Alpine, and so I am creating my first package and have a few questions. Hope this is the right place to ask them.
2019-08-18 08:11:07 <_ikke_> yes, it certainly is
2019-08-18 08:11:47 <Geod2441> So, I am trying to package a pre-compiled version of the compiler, and bootstrap things from here. The D compilers have their frontend written in D, so it makes things a bit awkward.
2019-08-18 08:12:36 <_ikke_> Is there some way to bootstrap it
2019-08-18 08:13:34 <_ikke_> What you could do is use a pre-compiled compiler (if that works on musl) to build the first package, and then use that package to build itself in the future
2019-08-18 08:13:34 <Geod2441> Well... I've been looking at it for a while. The best way I can see is to use a precompiled distribution that upstream made.
2019-08-18 08:13:53 <_ikke_> The problem is that those are most likely built against glibc, not musl
2019-08-18 08:14:18 <Geod2441> Yep, the prebuild binary is built against musl
2019-08-18 08:14:33 <_ikke_> ok
2019-08-18 08:14:41 <Geod2441> In fact I already raised a PR, but I realized later it is incorrect: https://github.com/alpinelinux/aports/pull/10107
2019-08-18 08:14:57 <mps> Geod2441: do it need gcc 9 for build
2019-08-18 08:15:25 <Geod2441> No it does not (that was the other way to bootstrap, but I abandoned it)
2019-08-18 08:16:16 <_ikke_> For it to be acceptable as a patch, it needs to be able to build from source
2019-08-18 08:16:34 <Geod2441> Arg
2019-08-18 08:16:51 <mps> someone told here few months ago that gcc9 is best option to  build D for alpine
2019-08-18 08:17:09 <mps> I don't know much about that, TBH
2019-08-18 08:17:18 <_ikke_> Geod2441: look at packages like ghc, which also depend on itself to build
2019-08-18 08:17:18 <Geod2441> Well it needs some patches, because musl support for the runtime did not make it into it in time
2019-08-18 08:18:03 <Geod2441> The release I tried to use was https://github.com/ldc-developers/ldc/releases/tag/v1.8.0
2019-08-18 08:18:16 <Geod2441> And from there, I can build from source
2019-08-18 08:18:27 <Geod2441> Will look into ghc
2019-08-18 08:19:04 <_ikke_> The challenge is getting the first package built, which you probably do like you do now
2019-08-18 08:19:08 <mps> also, crystal and rust use bootstrap versions of itself to build
2019-08-18 08:21:12 <Geod2441> But those bootstrap versions need to build from source ?
2019-08-18 08:24:01 <mps> for rust upstream make tarballs ready
2019-08-18 08:24:43 <mps> for crystal we build it from source using previously bootstrapped release
2019-08-18 08:31:38 <Geod2441> Looks like Rust went with the same approach, originally: https://github.com/alpinelinux/aports/commit/2a8472b921baf8c2ac35688df5188f034b526441#diff-0d0f9a278fdcdf00a9167fd4861cdfe7R16-R25
2019-08-18 08:33:42 <nmeum> ncopa: since go is statically linked we actually have to rebuild all go packages after security updates such as f4894bf9bd05edccdac484db35c4d6fb06a3b26c right?
2019-08-18 08:34:35 <Geod2441> So my next question was: Is it acceptable for a package to depend on one of its subpackages ? E.g. the compiler need to depend on the runtime, but you should be able to install the runtime without the compiler.
2019-08-18 08:35:05 <_ikke_> Geod2441: yes
2019-08-18 08:35:12 <_ikke_> it is
2019-08-18 08:35:56 <Geod2441> Great
2019-08-18 08:36:02 <Geod2441> Thanks
2019-08-18 08:39:17 <_ikke_> nmeum: I would think so
2019-08-18 08:57:31 <nmeum> so, should we go ahead and rebuild all go pacckages?
2019-08-18 08:57:53 <nmeum> probably hard to figure out which of them use the affected http/2 functionality
2019-08-18 09:00:31 <_ikke_> yup
2019-08-18 09:06:18 <nmeum> can't do it right away, will create an issue for it so we don't forget about it
2019-08-18 09:06:39 <_ikke_> good
2019-08-18 09:07:09 <PureTryOut[m]> maxice8: 18.2 built with Wayland and GBM support. You merged everything else of the patchset but not the last patch
2019-08-18 09:08:20 <PureTryOut[m]> This one https://lists.alpinelinux.org/~alpine/aports/%3C20190810172648.15624-1-bribbers%40disroot.org%3E#%3C20190810172648.15624-4-bribbers@disroot.org%3E
2019-08-18 09:12:17 <nmeum> is there any easy way to recursively search for makedepends? apk search -r only checks for runtime depends iirc
2019-08-18 09:13:05 <_ikke_> perhaps with ap recursedeps ( from lua-aports)
2019-08-18 09:15:28 <nmeum> ap revdep seems to work
2019-08-18 09:15:31 <nmeum> thanks for the hitn
2019-08-18 09:15:33 <nmeum> *hint
2019-08-18 09:16:02 <_ikke_> alright
2019-08-18 09:24:36 <nmeum> _ikke_: https://github.com/alpinelinux/aports/pull/10190 didn't actually do the rebuilds yet though
2019-08-18 09:24:59 <nmeum> ci will probably time out with that many rebuilds, right?
2019-08-18 09:26:21 <_ikke_> yes, timeout is at 1h
2019-08-18 10:18:34 <PureTryOut[m]> _ikke_: ok I'm really not sure how `ap builddirs` works... Even literally copying your command (with different git hashes) breaks it
2019-08-18 10:20:14 <_ikke_> You need to run it from the correct directory
2019-08-18 10:20:29 <PureTryOut[m]> Not just the aports git directory?
2019-08-18 10:22:13 <PureTryOut[m]> It complains that it can't cd to `$HOME/aports/git/dir/on/my/system/*`
2019-08-18 10:30:18 <_ikke_> So it works only for one aports repo at the time
2019-08-18 10:30:45 <_ikke_> So you need to CD into one of the repos and pass the subdir name
2019-08-18 10:43:49 <PureTryOut[m]> That is what I'm doing though
2019-08-18 10:44:00 <PureTryOut[m]> I execute the command from the root of the git repo
2019-08-18 10:44:12 <PureTryOut[m]> Oh wait you mean `testing` or `community`?
2019-08-18 10:44:46 <PureTryOut[m]> Ah that did the trick
2019-08-18 10:48:00 <_ikke_> Yes, indeed
2019-08-18 11:38:38 <PureTryOut[m]> Who has control over the alpinelinux/docker-abuild docker image? The edge tag needs a rebuild
2019-08-18 11:42:00 <nmeum> _ikke_: regarding the go rebuild: could probably just push it as is, afterall packages should build fine if we simply bump the pkgrel
2019-08-18 11:42:50 <_ikke_> when I have the opportunity
2019-08-18 11:42:57 <nmeum> I can also push it
2019-08-18 11:43:04 <nmeum> just wanted to make sure that someone else is ok with it
2019-08-18 12:04:11 <_ikke_> nmeum: cloudi fails to build
2019-08-18 12:04:17 <_ikke_> (i'm testing it locally)
2019-08-18 12:06:18 <_ikke_> http://tpaste.us/KgQn
2019-08-18 12:15:55 <_ikke_> (not related to go)
2019-08-18 12:45:46 <nmeum> does https://github.com/CloudI/CloudI/commit/479eef923b756fdcfea395d63e2383f18479ada0 fix that?
2019-08-18 12:46:12 <nmeum> I don't speak ML but the commit change the corresponding line in the file
2019-08-18 12:48:17 <_ikke_> Let me test
2019-08-18 12:49:40 <_ikke_> That's a huge patch though
2019-08-18 12:49:56 <nmeum> yeah
2019-08-18 12:50:05 <nmeum> maybe just change the single line in cloudi.ml?
2019-08-18 12:50:29 <nmeum> but the latest release doesn't seem to support ocaml 4.08.0
2019-08-18 12:52:37 <_ikke_> The rest from community built fine
2019-08-18 12:52:53 <nmeum> great
2019-08-18 12:53:45 <_ikke_> building cloudi now
2019-08-18 12:55:26 <_ikke_> Seems to continue now, waiting for it to finish
2019-08-18 12:57:28 <nmeum> if it doesn't work we could also exclude cloudi from the rebuild for now
2019-08-18 13:10:43 <_ikke_> http://tpaste.us/oa0q
2019-08-18 13:11:02 <_ikke_> That worked
2019-08-18 13:16:47 <nmeum> ok, just go ahead and push it then :)
2019-08-18 13:17:01 <nmeum> (since it's not related to the go rebuild we need it anyhow)
2019-08-18 13:21:37 <maxice8> PureTryOut: ill merge once I get home
2019-08-18 13:21:56 <PureTryOut[m]> What patch? Kodi?
2019-08-18 13:21:56 <maxice8> Am at hospital getting band-aid changed then I'll go buy stuff
2019-08-18 13:21:59 <maxice8> Yes
2019-08-18 13:22:03 <PureTryOut[m]> Ah thanks
2019-08-18 13:34:35 <_ikke_> nmeum: cloud-foundry in testing failed
2019-08-18 13:34:57 <nmeum> error message?
2019-08-18 13:36:01 <nmeum> started building it
2019-08-18 13:36:30 <nmeum> you mean testing/cloudfoundry-cli, right?
2019-08-18 13:36:41 <_ikke_> ../go/src/github.com/cloudfoundry/cli/cf/i18n/i18n.go:9:2: cannot find package "github.com/cloudfoundry/cli/cf/resources" in any of:
2019-08-18 13:36:45 <_ikke_> Yes
2019-08-18 13:37:35 <nmeum> gimme a sec
2019-08-18 13:37:49 <nmeum> anything else in testing that didn't build?
2019-08-18 13:47:24 <_ikke_> confd as well
2019-08-18 13:47:39 <_ikke_> Mayve
2019-08-18 13:47:52 <_ikke_> Maybe others as well
2019-08-18 13:51:15 <nmeum> I have a fix for cloudfoundry
2019-08-18 13:52:13 <nmeum> would honestly not like to hold back the rebuild for too long as it has potential security implications
2019-08-18 13:54:51 <_ikke_> I would advise to drop the failing packages then and fix those later
2019-08-18 13:55:48 <nmeum> they will probably never be fixed then
2019-08-18 13:55:57 <nmeum> especially since packages in testing/ don't get rebuild on new releases
2019-08-18 13:59:38 <nmeum> just pushed the fix for cloudfoundry
2019-08-18 14:19:04 <maxice8> Nice
2019-08-18 14:19:17 <maxice8> :D I remember massive go rebuilds on Void Linux
2019-08-18 14:39:26 <_ikke_> Pushed cloudi
2019-08-18 14:46:43 <nmeum> maxice8: yeah, those are neccessary because go is statically linked
2019-08-18 14:47:09 <mps> PureTryOut[m]: I see some patches on aports ML. did you test them, i.e they builds correctly?
2019-08-18 14:47:13 <nmeum> _ikke_: I believe I also have a fix for confd
2019-08-18 14:47:15 <nmeum> anything else?
2019-08-18 14:47:34 <PureTryOut[m]> mps: of course. I've built them on x86_64
2019-08-18 14:48:18 <mps> ok, I have some free time and if you agree I will push them
2019-08-18 14:50:50 <PureTryOut[m]> Of course I agree 😜
2019-08-18 14:51:27 <mps> ok, will at home un about 20-30 minutes
2019-08-18 14:51:37 <PureTryOut[m]> I made an issue for the nheko build failure btw https://github.com/Nheko-Reborn/nheko/issues/85
2019-08-18 14:54:06 <mps> I saw you posted patch for lmdbxx new aport
2019-08-18 14:57:38 <nmeum> _ikke_: I would personally just go ahead and push the rebuild, we can fix stuff in testing/ as it pops up or disable aports that can't be fixed. are you ok with that?
2019-08-18 15:06:57 <_ikke_> nmeum: sure, go ahead
2019-08-18 15:07:10 <_ikke_> Jut wanted to prevents lots of broken stuff being pushed and keeping the builders stuck
2019-08-18 15:07:46 <PureTryOut[m]> Could somebody merge https://lists.alpinelinux.org/~alpine/aports/patches/2838 and https://lists.alpinelinux.org/~alpine/aports/patches/2838?
2019-08-18 15:08:08 <PureTryOut[m]> Oh woops that's the same url with both patches 🙈
2019-08-18 15:13:30 <j8r> mps: I've joined alpine-devel
2019-08-18 15:13:53 <j8r> I'm still compiling LLVM with assertions enabled, very slow
2019-08-18 15:13:59 <mps> j8r: hi! nice to see you here
2019-08-18 15:14:42 <j8r> I hope I will be able to provide a good trace so Crystal core devs can fix the issue
2019-08-18 15:14:59 <mps> I have dilemma about crystal. x86_64 builds fine with llvm8 but aarch64 only with llvm5
2019-08-18 15:15:46 <mps> what to do for alpine? use llvm5 also for x86_64 or make them to use different llvm's
2019-08-18 15:16:31 <j8r> I think we can use LLVM5
2019-08-18 15:16:55 <j8r> there is no problem to still use it
2019-08-18 15:17:17 <mps> I tend to that, also
2019-08-18 15:17:18 <j8r> In fact even LLVM4 is used on the official Docker image :/
2019-08-18 15:18:28 <mps> right, but we would like to get llvm's older than 8 out of aports
2019-08-18 15:18:36 <j8r> Or, we can wait a bit
2019-08-18 15:19:26 <maxice8> PureTryOut: merged kodi
2019-08-18 15:19:31 <j8r> I will send the trace in the issue, maybe it can be fixed before the Alpine 3.11 release
2019-08-18 15:19:35 <PureTryOut[m]> Yeah I saw it thanks!
2019-08-18 15:19:38 <mps> not sure, now we don't have crystal in edge on aarch64
2019-08-18 15:20:05 <PureTryOut[m]> maxice8: could you also merge https://lists.alpinelinux.org/~alpine/aports/patches/2838?
2019-08-18 15:20:46 <mps> j8r: I can post changed APKBUILD if you think it can be useful for upstream
2019-08-18 15:22:13 <mps> are builders stuck? looks like testing/nlohmann-json stalled
2019-08-18 15:22:30 <j8r> mps: I think we can wait few days
2019-08-18 15:22:47 <PureTryOut[m]> Not stalled
2019-08-18 15:22:50 <PureTryOut[m]> Some tests just take quite long
2019-08-18 15:22:57 <PureTryOut[m]> One of the tests took ~350 seconds for me
2019-08-18 15:23:10 <mps> j8r: ok, then we will wait some days
2019-08-18 15:23:17 <PureTryOut[m]> Test 80/88 took 476 seconds on the x86_64 builder but it passed, just give it some time
2019-08-18 15:24:03 <mps> PureTryOut[m]: aha, I see
2019-08-18 15:24:28 <mps> want to push all four and go to lunch
2019-08-18 15:25:01 <maxice8> PureTryOut: yeah sure
2019-08-18 15:30:17 <mps> PureTryOut[m]: source="$pkgname-$pkgver.tar.gz::https://github.com/mobius3/$pkgname/archive/v$pkgver.tar.gz"
2019-08-18 15:30:35 <mps> $pkgname is now not preferred
2019-08-18 15:30:44 <PureTryOut[m]> Is it not? That's new
2019-08-18 15:30:48 <mps> but use literal
2019-08-18 15:30:54 <PureTryOut[m]> I'll change it for future aports
2019-08-18 15:31:07 <maxice8> There was some discussion here and it was implement in alint
2019-08-18 15:31:11 <mps> yes, I learned it last week, ncopa told me, iirc
2019-08-18 15:31:33 <mps> not sure what alint will say
2019-08-18 15:31:49 <maxice8> https://gitlab.alpinelinux.org/Leo/atools/blob/master/alint.5.scd#L316
2019-08-18 15:32:02 <maxice8> alint will tell you that you violated AL29 pkgname-used-in-source
2019-08-18 15:32:25 <mps> alint from atools-15.3-r0 is quiet
2019-08-18 15:33:23 <maxice8> problably wasn't present there, it is recommended to use the latest version from edge
2019-08-18 15:34:23 <mps> also quiet from atools-18.8.1-r1
2019-08-18 15:34:36 <PureTryOut[m]> Shouldn't atools be added to alpine-sdk?
2019-08-18 15:34:48 <maxice8> PureTryOut: it is not an official tool yet it is just very actively developed
2019-08-18 15:35:02 <mps> probably, but for now add it manually
2019-08-18 15:35:11 <maxice8> also it depend son GNU Grep for -P
2019-08-18 15:35:26 <mps> yes, grep is showstopper
2019-08-18 15:35:29 <PureTryOut[m]> Ah
2019-08-18 15:52:21 <nmeum> pushed the go rebuild, will watch alpine-commits for build errors
2019-08-18 15:52:33 <maxice8> have fun :D
2019-08-18 15:53:25 <nmeum> already fixed a few aports, let's hope I didn't miss that many
2019-08-18 15:53:40 <nmeum> community/ should definitly build fine
2019-08-18 15:54:08 <mps> PureTryOut[m]: have you seen failed build due to the timeout for https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/nlohmann-json/nlohmann-json-3.7.0-r0.log
2019-08-18 15:54:15 <nmeum> hm, I guess I will also add a comment to the go APKBUILD to remind upgraders to rebuild packages
2019-08-18 15:54:36 <PureTryOut[m]> mps: I was trying to look at it but I just got a 404. Now it works though
2019-08-18 15:54:48 <PureTryOut[m]> I guess it needs a simple retry?
2019-08-18 15:55:17 <mps> probably
2019-08-18 15:55:19 <PureTryOut[m]> Might disable the test entirely though, it takes ages on every architecture and maybe the aarch64 builder specifically has performance problems with it:?
2019-08-18 15:55:33 <mps> aarch64 is slow, yes
2019-08-18 15:56:27 <mps> for now we can wait for another try and see if it will pass, and if not maybe then disable check
2019-08-18 15:58:01 <PureTryOut[m]> Yeah sure
2019-08-18 15:58:30 <mps> ok, pushed all four. will keep eye on builders for some time to see if all pass
2019-08-18 15:59:26 <mps> btw, I changed $pkgname in last two, in source field
2019-08-18 16:02:36 <PureTryOut[m]> 👍️
2019-08-18 19:07:08 <j8r> where and how is the best way to ask for review of patches?
2019-08-18 19:07:22 <_ikke_> here
2019-08-18 19:10:36 <mps> j8r: post url and ask
2019-08-18 19:11:53 <j8r> I asked on #alpine-linux, this was about compiling the gcc APKBUILD
2019-08-18 19:12:03 <j8r> does anyone succeeded?
2019-08-18 19:13:31 <mps> is it github PR?
2019-08-18 19:15:34 <j8r> the one in aports, master
2019-08-18 19:16:03 <_ikke_> So you mean building gcc in general?
2019-08-18 19:16:13 <mps> if it is in aports it is built, I think
2019-08-18 19:18:16 <j8r> yes, I wonder how
2019-08-18 19:18:41 <mps> did you installed alpine-sdk?
2019-08-18 19:19:22 <j8r> even the CO is failing mps
2019-08-18 19:19:25 <j8r> CI
2019-08-18 19:20:07 <_ikke_> Failing how
2019-08-18 19:20:09 <_ikke_> ?
2019-08-18 19:20:11 <_ikke_> Any links / reference?
2019-08-18 19:20:32 <mps> do you want to build it locally or some other way
2019-08-18 19:21:14 <j8r> https://github.com/alpinelinux/aports/pull/9517
2019-08-18 19:21:41 <j8r> I've reverted the commit, let the Aline CI run - same error
2019-08-18 19:21:51 <_ikke_> "configure: error: GNAT is required to build ada"
2019-08-18 19:21:56 <_ikke_> So looks like a dependency is missing
2019-08-18 19:22:06 <j8r> yep, didn't touch anything
2019-08-18 19:22:13 <j8r> *related to that
2019-08-18 19:22:42 <j8r> you can try yourself, perhaps you won't have the issue
2019-08-18 19:23:33 <j8r> as I said in the PR, adding the dependency doesn't solve the issue. It seems to be ignored by apk
2019-08-18 19:23:50 <_ikke_> What did you add?
2019-08-18 19:24:01 <j8r> `gcc-gnat`
2019-08-18 19:24:22 <_ikke_> https://git.alpinelinux.org/aports/tree/main/gcc/APKBUILD#n132
2019-08-18 19:24:55 <mps> j8r: I don't see that you added anything in makedepends
2019-08-18 19:26:00 <mps> and gcc-gnat is already in section about ADA
2019-08-18 19:26:20 <_ikke_> but still it fails, (just tried it locally)
2019-08-18 19:26:59 <mps> _ikke_: with j8r's patch?
2019-08-18 19:27:42 <_ikke_> No, just from what's in aports
2019-08-18 19:27:57 <mps> aha, let me try
2019-08-18 19:28:27 <mps> right, failed
2019-08-18 19:29:14 <_ikke_> LANG_ADA=false abuild -r works
2019-08-18 19:31:30 <_ikke_> manually installing gcc-gnat before building also works
2019-08-18 19:34:11 <mps> _ikke_: yes, it started. lets see will it finish
2019-08-18 19:34:53 <mps> do we need to add makedepends with it in APKBUILD
2019-08-18 19:35:16 <_ikke_> mps: That section I linked to already adds it to makedepends
2019-08-18 19:35:57 <mps> I have seen, but it doesn't work
2019-08-18 19:36:06 <j8r> yes disabling ADA make it work
2019-08-18 19:36:40 <_ikke_> mps: I'm tracing the output of abuild -v deps to see what is happening
2019-08-18 19:40:19 <Cogitri> I think you're tripping over the bootstrapping magic
2019-08-18 19:41:03 <_ikke_> Cogitri: It's strange that gcc-gnat does not end up in the final list of dependencies though
2019-08-18 19:42:41 <Cogitri> I don't think you can depend on subpkgs or the pkg itseld
2019-08-18 19:42:42 <Cogitri> You need to hack around it with provides like e.g. Rust does with rust-bootstrap
2019-08-18 19:43:15 <Cogitri> <Cogitri "I don't think you can depend on "> abuild will automagically remove those deps to not cycle IIRC
2019-08-18 19:45:48 <mps> hmm, last time I worked it was in commit 8ecdc06d570e1df1b9bfae022660dfbe98d98106
2019-08-18 19:46:02 <mps> and it worked then without issue
2019-08-18 19:46:57 <mps> and after that only change was upgrade from 8.2.0 to 8.3.0
2019-08-18 19:47:21 <mps> maybe abuild added some issues
2019-08-18 19:48:29 <_ikke_> Yes, I suspect something like that
2019-08-18 19:48:35 <_ikke_> a new version of abuild has been released
2019-08-18 19:50:22 <mps> abuild is out of my expertise, to try to find what is the problem
2019-08-18 19:50:43 <_ikke_> It's a shell script, so it should be possible to follow
2019-08-18 19:51:23 <mps> yes, shell scripts are out of my knowledge if they are not few lines and simple
2019-08-18 19:54:43 <danieli> xreffing in emacs makes stuff way easier to understand for me
2019-08-18 19:55:00 <danieli> ggtags
2019-08-18 19:57:55 <_ikke_> would should add options=toolchain to gcc
2019-08-18 19:58:08 <_ikke_> then it would no longer warn about g++ as dependency
2019-08-18 20:00:49 <mps> wouldn't that be too much for other builds
2019-08-18 20:01:05 <mps> although it makes sense for compiler
2019-08-18 20:01:19 <mps> we could try and see results
2019-08-18 20:03:24 <_ikke_> I don't think that's the issue, just something I noticed
2019-08-18 20:04:28 <mps> yes, agree
2019-08-18 20:05:07 <mps> issue is probably in abuild
2019-08-18 20:09:48 <_ikke_> abuild 3.3.0 does not build it either
2019-08-18 20:11:14 <_ikke_> and 3.2.0 neither, so that kind of rules out abuild
2019-08-18 20:11:33 <mps> ohm, ...
2019-08-18 20:19:06 <mps> 'git log -p .' in aports/main/gcc shows just pkgver and pkgrel change in last commit
2019-08-18 20:23:38 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/10738
2019-08-18 20:30:26 <mps> hmm, 'echo $makedepends' show 'gcc-gnat gcc-gnat' (two times) with other deps
2019-08-18 20:30:40 <_ikke_> Yes, I noticed that somehwere in the output of abuild -v deps
2019-08-18 20:56:19 <nmeum> back again, go rebuild seems to be done
2019-08-18 20:56:28 <nmeum> with the exception of singularity that went relatively smooth
2019-08-18 21:10:49 <j8r> thanks _ikke_,mps, Cogitri for your help :)
2019-08-18 21:28:11 <PureTryOut[m]> mps: I've sent a patch to disable the test on aarch64 that is timing out https://lists.alpinelinux.org/~alpine/aports/patches/2924
2019-08-18 21:44:49 <mps> PureTryOut[m]: pushed
2019-08-18 21:45:54 <PureTryOut[m]> Thanks
2019-08-18 21:45:56 <mps> one note though, arch="noarch" are you sure
2019-08-18 21:46:40 <mps> is it compiled binary or script
2019-08-18 21:50:12 <mps> j8r: you're welcome :-)
2019-08-18 21:54:12 <PureTryOut[m]> Yeah I'm sure, it's just a header and some CMake files
2019-08-18 21:55:13 <PureTryOut[m]> Actually, it probably shouldn't have a `-dev` subpackage
2019-08-18 21:55:51 <mps> PureTryOut[m]: ok then
2019-08-18 22:00:04 <PureTryOut[m]> Yeah I've removed the `-dev` subpackage, it doesn't make sense to have it for a header-only package. Also took over maintainership because why not, it didn't had a maintainer https://lists.alpinelinux.org/~alpine/aports/patches/2925
2019-08-18 22:11:14 <mps> PureTryOut[m]: pushed
2019-08-18 22:12:02 <PureTryOut[m]> Thanks!
2019-08-18 22:12:59 <mps> np
2019-08-19 05:31:49 <maxice8> morning
2019-08-19 05:34:44 <pixelherodev> How do I check to make sure that an APKBUILD I'm writing lists all the needed makedepends? There any way other than running it in a minimal chroot?
2019-08-19 05:37:12 <Cogitri> CI will catch it
2019-08-19 05:37:21 <Cogitri> I'd recommend you to use either rootbld or docker-abuild for building though
2019-08-19 05:38:38 <Cogitri> Otherwise you might get some weird things during building, e.g. if a project has an automagic dep (if dep X is available enable feature Y) and you're wondering why you have feature Y on your machine but not on others
2019-08-19 05:42:32 <TBB> I tried rootbld last night; kept complaining about a nonexistent .rootbld-repositories (that existed)
2019-08-19 05:43:42 <Cogitri> Ah, I just use docker-abuild and that works wonderfully for me
2019-08-19 07:32:25 <ncopa> morning
2019-08-19 07:32:32 <ncopa> how was your weekend?
2019-08-19 07:32:38 <Danct12> good morning ncopa! :)
2019-08-19 07:32:43 <_ikke_> I had a good weekend
2019-08-19 07:32:57 <Danct12> my weekend was somewhat good, was playing with the pinetab
2019-08-19 07:33:29 <ncopa> nmeum: yes, in theory we should rebuild all go packages. not sure how many packages actually use the vulnerable components
2019-08-19 07:33:55 <Cogitri> Morning
2019-08-19 07:34:47 <_ikke_> ncopa: nmeum in the mean time already did it
2019-08-19 07:35:24 <_ikke_> https://github.com/alpinelinux/aports/pull/10190
2019-08-19 07:35:44 <Cogitri> Had a good weekend too, although I've noticed that I'm not one for camping apparently, I super look forward to an actual bed now
2019-08-19 07:36:43 <ncopa> Cogitri: ha! :D
2019-08-19 07:36:55 <ncopa> nmeum, _ikke_: thanks!
2019-08-19 07:44:52 <_ikke_> gcc fails to build atm due to a dependency not being installed somehow
2019-08-19 09:11:58 <ncopa> gcc-ada?
2019-08-19 09:19:22 <_ikke_> gcc-gnat
2019-08-19 09:19:27 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/10738
2019-08-19 09:25:22 <ncopa> its a circular dep
2019-08-19 09:26:02 <ncopa> i love this "S-ready" label in github :)
2019-08-19 09:27:08 <ncopa> i have pushed some of those PRs and it makes me in a good mood :)
2019-08-19 09:27:47 <_ikke_> Yes, it helps
2019-08-19 09:33:31 <ncopa> its not the label itself, but its the fact that there is people who have done alot high quality work
2019-08-19 10:04:10 <mps> ncopa: have you some time to look https://gitlab.alpinelinux.org/alpine/aports/issues/10716
2019-08-19 10:04:23 <mps> about hwdata and hwids
2019-08-19 10:04:41 <mps> I think hwdata could be removed from repo
2019-08-19 12:17:23 <maxice8> ncopa: it is even more fun since you can add them with a single curl call
2019-08-19 12:18:15 <maxice8> A long one that requires echo but still
2019-08-19 12:19:25 <nmeum> ncopa: re go rebuild, yeah rebuilding all packages everytime is probably a bad idea. for future updates we need some heuristics to figure out which packages are effected
2019-08-19 12:19:28 <nmeum> *affected
2019-08-19 12:19:49 <nmeum> but fixing a CVE in go without rebuilding the affected packages is useless imho
2019-08-19 12:20:48 <nmeum> also _ikke_ and I encountered a strange issue with singularity where it would output warnings regarding gocache and would fail with a some make target error
2019-08-19 12:21:08 <nmeum> both of us couldn't reproduce this locally and it only happended on the builders https://gitlab.alpinelinux.org/alpine/aports/issues/10737 if someone with builder access wants to investigate this further
2019-08-19 23:36:57 <nicolaus> i'm so sorry I have to ask this here
2019-08-19 23:37:25 <nicolaus> how can I start a new page for the wiki? I made a guide but don't know how to push it
2019-08-19 23:38:12 <danieli> nicolaus: at wiki.alpinelinux.org?
2019-08-19 23:38:16 <nicolaus> yes
2019-08-19 23:38:19 <danieli> what's your username?
2019-08-19 23:38:21 <danieli> same as here?
2019-08-19 23:38:24 <nicolaus> nicolaus yes
2019-08-19 23:38:51 <nicolaus> i started writing things in my "wiki personal page", don't know if that's correct?
2019-08-19 23:38:54 <danieli> try saving / creating pages now
2019-08-19 23:39:08 <danieli> I set your group to emailconfirmed without expiry, I believe that's how they usually sort it
2019-08-19 23:39:31 <nicolaus> many thanks
2019-08-19 23:39:37 <danieli> check if it works first :)
2019-08-19 23:39:54 <nicolaus> where do you click to start creating a new page danieli ?
2019-08-19 23:40:02 <danieli> er
2019-08-19 23:40:15 <danieli> iirc you just go to a non-existent page and hit create or something like that
2019-08-19 23:40:21 <nicolaus> ok
2019-08-19 23:40:43 <danieli> you can use the search function to start new pages apparently
2019-08-19 23:40:47 <danieli> it's been a while since I used mediawiki
2019-08-19 23:40:59 <nicolaus> it says
2019-08-19 23:41:03 <nicolaus>  Create the page "Znc" on this wiki!
2019-08-19 23:41:07 <danieli> yeah, click it
2019-08-19 23:41:08 <nicolaus>  There were no results matching the query.
2019-08-19 23:41:14 <danieli> click the red link
2019-08-19 23:41:15 <nicolaus> ohhh lol
2019-08-19 23:41:20 <nicolaus> the red link was hyperlink hahaha
2019-08-19 23:41:23 <danieli> red link on mediawiki means non-existent page, and it will prompt you to create it
2019-08-19 23:41:26 <nicolaus> didn't know hahaha
2019-08-19 23:41:31 <danieli> the more you know :)
2019-08-19 23:41:47 <nicolaus> it was camouflaged!!!
2019-08-19 23:41:58 <danieli> darn you and you meddling kids
2019-08-19 23:42:05 <danieli> or whatever it is they say
2019-08-20 01:25:40 <nicolaus> ok finished the znc guide
2019-08-20 01:26:04 <nicolaus> now i have to find out how to translate it to spanish
2019-08-20 06:18:58 <ddevault> going to move some of my packages from testing to community
2019-08-20 06:19:13 <maxice8> have fun :D
2019-08-20 06:19:45 <ddevault> should I bump the pkgrel when doing so or no
2019-08-20 06:20:09 <maxice8> no
2019-08-20 06:21:20 <nicolaus> which packages
2019-08-20 06:22:01 <ddevault> grim, slurp, mako, nethack, and imv
2019-08-20 06:23:45 <nicolaus> i finished some guides
2019-08-20 06:24:04 <nicolaus> they aren't the most polished ones, the cgit archwiki is far better but whatever
2019-08-20 06:25:14 <maxice8> nethack and imv are missing updates
2019-08-20 06:25:59 <ddevault> so they are
2019-08-20 06:26:02 <ddevault> surprised I missed them
2019-08-20 06:26:14 <maxice8> :D https://repology.org/projects/?maintainer=sir%40cmpwn.com&outdated=1
2019-08-20 06:27:02 <ddevault> useful
2019-08-20 06:27:25 <maxice8> yes, it has an html feed you can use newsboat or another RSS Reader to recieve notifications when your packages go out of date
2019-08-20 06:42:41 <fcolista> Waht is the status of unattended installation of alpine? We don't have yet a kickstart-like tool or an answer file right?
2019-08-20 06:47:36 <_ikke_> alpine-setup does support an answer file afaik
2019-08-20 06:49:02 <_ikke_> fcolista: https://github.com/alpinelinux/alpine-conf/blob/master/setup-alpine.in#L33
2019-08-20 06:50:55 <fcolista> _ikke_, gr8, thanks! We don't have an example right?
2019-08-20 06:51:20 <fcolista> yes we do
2019-08-20 06:51:21 <fcolista> ok
2019-08-20 06:51:22 <fcolista> good
2019-08-20 06:51:24 <fcolista> thanks _ikke_ !
2019-08-20 06:51:40 <_ikke_> np
2019-08-20 06:57:48 <mps> iirc, AinNero started to work on unattended install but can't remember is he finished before he left
2019-08-20 06:58:37 <mps> or is he left some 'artefacts' somewher
2019-08-20 07:11:51 <ncopa> fcolista: we do support answer file, but i dont think that is the future
2019-08-20 07:12:07 <ncopa> the current answer file implementation is somewhat hackish
2019-08-20 07:13:06 <ncopa> what i would like to do is to have some standard or commonly used yaml/json/soemthingelse file
2019-08-20 07:13:32 <ncopa> maybe a subset of cloud-init or similar
2019-08-20 07:13:47 <fcolista> the naswer file might be passed via bootloader
2019-08-20 07:13:49 <ncopa> not sure which is the most common used config format
2019-08-20 07:13:51 <fcolista> *answer
2019-08-20 07:14:22 <fcolista> for what I understand, you need to manually run setup-alpine -f /path/to/answer/file
2019-08-20 07:14:30 <fcolista> or maybe add it to local.d
2019-08-20 07:14:51 <fcolista> and then remove it at the end of the setup
2019-08-20 07:15:00 <ncopa> i think passing a url file voa boot option or pxe would be a good idea
2019-08-20 07:15:08 <ncopa> it could be executed from firstboot script
2019-08-20 07:15:20 <fcolista> what happens to the next boot?
2019-08-20 07:15:38 <ncopa> firstboot script will remove itselft from autostarting
2019-08-20 07:15:46 <ncopa> so firstboot will not run second boot
2019-08-20 07:15:56 <fcolista> thats' the way
2019-08-20 07:16:19 <nicolaus> gitolite guide is done
2019-08-20 08:20:26 <ddevault> man, apk virtual packages are nice
2019-08-20 08:20:53 <ddevault> fcolista: I found the answer file insufficient for my needs, but a home grown unattended installation script is not difficult to make
2019-08-20 08:21:12 <ddevault> fcolista: in case you find it useful: https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/alpine/genimg
2019-08-20 08:46:04 <fcolista> ddevault, thank you very much.
2019-08-20 08:47:28 <fcolista> would be nice to adapt this for usb install
2019-08-20 08:50:28 <fcolista> (i was thinking to an apkovl builder)
2019-08-20 08:50:55 <ddevault> still not sure what an apkovl is tbh
2019-08-20 08:51:47 <fcolista> the overlay used in bootable usb, that reapply the configuration
2019-08-20 08:52:04 <fcolista> by default saves /etc dir
2019-08-20 08:52:38 <fcolista> and after the usb boot, the overaly is untarred/ungzipped
2019-08-20 08:53:13 <fcolista> since very boot (in usb mode) pacakges are reinstalled
2019-08-20 09:12:26 <Geod2440> Hi, is there someone I need to ping on Github w.r.t new packages being ready for review / merge ?
2019-08-20 09:13:06 <_ikke_> Usually someone picks them up within a couple of days
2019-08-20 09:23:21 <ncopa> i have a gitlab related question, not sure i should ask here or in #alpine-infra
2019-08-20 09:24:04 <ncopa> the problem is that when i did releases in redmine, i had a clear list of issues that was resolved in a given release
2019-08-20 09:24:43 <ncopa> for example http://bugs.alpinelinux.org/versions/146
2019-08-20 09:25:07 <ncopa> hum, it redirects
2019-08-20 09:25:44 <_ikke_> It still exists as redmine
2019-08-20 09:26:25 <ncopa> something like this https://gitlab.alpinelinux.org/alpine/aports/-/milestones/139
2019-08-20 09:27:05 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues?scope=all&utf8=%E2%9C%93&state=all&milestone_title=3.9.3
2019-08-20 09:27:26 <ncopa> right
2019-08-20 09:28:01 <ncopa> so the problem at hand is that we no longer set milestone on security issues
2019-08-20 09:28:17 <_ikke_> So I guess we should?
2019-08-20 09:28:20 <ncopa> because we cannot set multiple milestones on an issue
2019-08-20 09:28:26 <_ikke_> ah ok
2019-08-20 09:28:57 <ncopa> it would be good to have a list of security issues fixed though
2019-08-20 09:29:09 <ncopa> but i dont know how to implement that
2019-08-20 09:29:53 <ncopa> so we get those included in the list of issues solved for that release
2019-08-20 09:30:23 <_ikke_> I don't see how we can do that with just a single issue
2019-08-20 09:30:30 <_ikke_> as you said, an issue can be in just one milestone
2019-08-20 09:30:47 <ncopa> i suppose we could add new labels as well
2019-08-20 09:30:53 <_ikke_> yes
2019-08-20 09:31:05 <ncopa> so for example we could label v3.10.1
2019-08-20 09:31:16 <ncopa> and when we fix the issue we set that label
2019-08-20 09:31:28 <_ikke_> But it's harder to get it in one overview then
2019-08-20 09:31:50 <_ikke_> Unless we drop milestones and only use labels
2019-08-20 09:31:54 <ncopa> right
2019-08-20 09:32:10 <ncopa> mark all issues for that milestone with that label
2019-08-20 09:32:35 <ncopa> another issue i had was
2019-08-20 09:32:54 <ncopa> when i tag release, i used to move unresolved issues to next milestone
2019-08-20 09:33:12 <ncopa> i could do that with mass edit
2019-08-20 09:33:37 <_ikke_> There is no mass edit in gitlab issues :-)
2019-08-20 09:33:49 <ncopa> mark the list of issues I wanted modify, and right click and set target
2019-08-20 09:33:50 <clandmeter> yeah, thats a huge miss
2019-08-20 09:33:53 <clandmeter> but....
2019-08-20 09:33:57 <_ikke_> API..
2019-08-20 09:33:57 <clandmeter> there is an api :)
2019-08-20 09:34:41 <ncopa> ok, i guess that is solvable that way
2019-08-20 09:35:47 <ncopa> so we want use labels for every release?
2019-08-20 09:35:53 <ncopa> i created label for every branch
2019-08-20 09:36:25 <ncopa> alternatively
2019-08-20 09:36:37 <ncopa> i could just drop that from the relase notes
2019-08-20 09:36:47 <ncopa> and let people browse the git log
2019-08-20 09:38:07 <ncopa> like this: https://git.alpinelinux.org/aports/log/?h=v3.10.1
2019-08-20 10:51:09 <_ikke_> Is the s390x edge builder stuck? It seems to hang on minio-client
2019-08-20 11:04:49 <PureTryOut[m]> What is the proper way to add a new user to multiple groups in a .pre-install file? Just multiple `addgroup` calls? Or is there a way to do it in a single command?
2019-08-20 11:07:37 <mps> doesn't 'adduser username group1 group2 ...' work
2019-08-20 11:09:28 <PureTryOut[m]> Oh maybe, let's try
2019-08-20 11:10:23 <PureTryOut[m]> Nope, seems to be just a single group at a time
2019-08-20 11:11:26 <mps> uhm, this is busybox adduser
2019-08-20 11:12:14 <PureTryOut[m]> Yes
2019-08-20 11:12:21 <PureTryOut[m]> Multiple `-G` doesn't work either, it just does the last one
2019-08-20 11:12:40 <PureTryOut[m]> I'll just do multiple addgroup/adduser calls I guess
2019-08-20 11:14:05 <mps> I think so
2019-08-20 11:14:35 <PureTryOut[m]> Let's loop over the groups, a bit cleaner I guess
2019-08-20 11:15:40 <mps> question is, why do you add user in multiple groups? doesn't that belongs to admin
2019-08-20 11:17:10 <PureTryOut[m]> Not in this case. I'm trying to run kodi-gbm in a tty, for which it needs to be in the video group to start at all, the input group to be able to receive input from the user, and the audio group to play audio
2019-08-20 11:17:27 <PureTryOut[m]> And I'm doing it as a dedicated user
2019-08-20 11:20:55 <PureTryOut[m]> Also, should a user added in .pre-install be removed on .post-deinstall?
2019-08-20 11:31:35 <mps> ordinary users should not be added to any group in {pre,post}-install scripts, imo
2019-08-20 11:32:05 <mps> but don't know your use case so not sure, maybe there are exceptions
2019-08-20 11:32:27 <PureTryOut[m]> It's a system user
2019-08-20 11:33:08 <mps> aha, then makes sense
2019-08-20 11:34:56 <PureTryOut[m]> Still, should it be removed again on package uninstall?
2019-08-20 11:36:18 <_ikke_> I don't think you should
2019-08-20 11:36:24 <mps> if the some files left after it then no
2019-08-20 11:39:06 <ncopa> we dont remove users on uninstall
2019-08-20 11:39:23 <ncopa> _ikke_: i rebooted the s390x builder
2019-08-20 11:39:48 <ncopa> it seemed like it was stuck on some git operation
2019-08-20 11:39:58 <PureTryOut[m]> ok thanks
2019-08-20 11:40:23 <_ikke_> ncopa: alright
2019-08-20 11:54:07 <ncopa> looks ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.10.2-released.html
2019-08-20 11:56:35 <_ikke_> Looks good to me
2019-08-20 11:57:01 <danieli>  just curious - when is elixir 1.9.x landing, 3.11?
2019-08-20 11:57:38 <ncopa> danieli: do you have a PR for it?
2019-08-20 11:57:57 <danieli> ncopa: it's already in edge :) https://pkgs.alpinelinux.org/packages?name=elixir&branch=edge
2019-08-20 11:58:10 <danieli> 1.8.2 is in 3.10
2019-08-20 11:58:23 <ncopa> then its landing in 3.11
2019-08-20 11:58:53 <danieli> all right, just checking
2019-08-20 11:59:03 <ncopa> the idea with the stable branches is that we brach the git master (edge) twice a year and maintain that
2019-08-20 11:59:28 <ncopa> so if it is in git master (edge) it will be inculded in next stable
2019-08-20 11:59:37 <ncopa> unless its still in testing
2019-08-20 11:59:47 <ncopa> we dont ship testing for stable
2019-08-20 12:01:27 <danieli> yeah, that's what i thought, but i didn't trust my memory on that one
2019-08-20 12:02:43 <ncopa> :)
2019-08-20 12:05:49 <danieli> is 3.9 still supported?
2019-08-20 12:06:13 <danieli> if so, go should probably be bumped from 1.11.5 to 1.11.13 if the change isn't too big
2019-08-20 12:07:03 <_ikke_> danieli: only security fixes
2019-08-20 12:07:17 <danieli> there are a number of security fixes in that release
2019-08-20 12:35:19 <ncopa> yes
2019-08-20 12:35:29 <ncopa> i mean no
2019-08-20 12:35:52 <ncopa> we dont support community repo for more than latest stable (currently 3.10)
2019-08-20 12:36:11 <ncopa> for packages in main we provide security fixes for 2 years
2019-08-20 12:41:41 <danieli> okay, good to know
2019-08-20 14:00:11 <j8r> mps: hi, I've compiled LLVM8.0.1 on QEMU - it takes several days :/
2019-08-20 14:00:50 <j8r> But I need to recompile it again against LLVM@master, because 8.0.1 has a bug
2019-08-20 14:01:35 <mps> j8r: we have 8.0.1 on edge
2019-08-20 14:02:04 <mps> could you post url to the bug
2019-08-20 14:03:02 <j8r> Oh yes, I needed with -DLLVM_ENABLE_ASSERTIONS=ON
2019-08-20 14:03:31 <j8r> https://github.com/crystal-lang/crystal/issues/8080
2019-08-20 14:03:33 <mps> does this fix llvm 8.0.1
2019-08-20 14:05:16 <j8r> asterite, a Crystal core dev, reported the issue and it was solved in master
2019-08-20 14:05:19 <mps> ok, I will look tomorrow to that
2019-08-20 14:05:42 <mps> yes, I see, I skimmed to the issue
2019-08-20 14:07:04 <mps> this is issue on llvm8 on aarch64, on x86_64 it works
2019-08-20 14:07:30 <artok> one week and llvm 9.0.0 is out!
2019-08-20 14:07:38 <j8r> I will try against master in several hours
2019-08-20 14:07:51 <mps> nice, new pile of bugs :P
2019-08-20 14:08:56 <mps> not sure but I think we will have llvm8 for next stable
2019-08-20 14:09:06 <j8r> they are know to do breaking changes, wanted or not
2019-08-20 14:09:47 <mps> will be afk now, see you
2019-08-20 14:10:01 <j8r> bye, I keep you in touch
2019-08-20 14:22:55 <filoozom> Hi guys, has anyone played with running Alpine on RPi 4?
2019-08-20 14:29:18 <artok> would be nice to know also if someone is doing that, before I start banging my head
2019-08-20 14:30:13 <artok> I did build some stuff already but the vital kernel I haven't yet configured
2019-08-20 14:32:29 <artok> so ask again next week and I might have done something, depending if I have time
2019-08-20 14:41:33 <filoozom> Do you have any idea of what would be required to get it to work? Submitted a PR to update raspberrypi-bootloader for starters
2019-08-20 14:59:56 <danieli> i had a quick look at it but did not immediately see the issue
2019-08-20 16:04:00 <maxice8> ddevault: imv needs freeimage-dev that is in testing/
2019-08-20 16:04:22 <maxice8> i moved freeimage-dev to community/ please use aports-lint from atools to find violations of depending on a package from an upper repo
2019-08-20 16:04:38 <_ikke_> maxice8: kbd has one test failing on s390x
2019-08-20 16:04:48 <maxice8> oh
2019-08-20 16:05:05 <_ikke_> and the last push also has quite a bit of failures
2019-08-20 16:05:36 <mps> I'm starting to use aports-lint even before pushing other people patches, nice tool
2019-08-20 16:06:04 <maxice8> _ikke_: Am dealing with the fallout :D
2019-08-20 16:06:07 <_ikke_> heh
2019-08-20 16:06:21 <_ikke_> mps: yes, that's what I do as well
2019-08-20 16:06:24 <maxice8> i call it the Void Gnome Update method
2019-08-20 16:23:20 <_ikke_> Cogitri: Do you mind if I move gitlab-runner to community?
2019-08-20 16:23:58 <Cogitri> Go ahead, has been working fine for me since a few weeks
2019-08-20 16:24:05 <_ikke_> Yeah, for me (gitlab) as well
2019-08-20 16:57:09 <mps> anyone with main repo push rights could look at ell update MR https://gitlab.alpinelinux.org/alpine/aports/merge_requests/30
2019-08-20 16:57:33 <mps> it is needed for iwd 0.19 upgrade
2019-08-20 16:58:32 <mps> I tested build on x86_64, armv7 and aarch64. everything is ok
2019-08-20 16:59:30 <mps> hmm, except for atools-lint warnings, I see now
2019-08-20 16:59:32 <_ikke_> checking
2019-08-20 16:59:49 <mps> _ikke_: thanks
2019-08-20 17:08:26 <mps> s390x is stuck again by kbd pkg
2019-08-20 17:08:39 <maxice8> Made PR to disable tests on it
2019-08-20 17:09:04 <mps> aha, someone have to push it
2019-08-20 17:10:49 <Cogitri> Do we use some tags for our gitlab-ci runners?
2019-08-20 17:22:33 <_ikke_> x86_86 and docker-alpine for now
2019-08-20 17:22:37 <_ikke_> but I can change that
2019-08-20 17:24:50 <Cogitri> Alrighty, will add those to my runner
2019-08-20 17:25:02 <Cogitri> Ah, "I can change that" == you can do it for my runner, nvm
2019-08-20 17:25:19 <_ikke_> I gave the token for the infra group, I wonder if that would work for forks as well
2019-08-20 17:25:47 <Cogitri> Don't think so
2019-08-20 17:25:54 <mps> sorry for ignorance, but what is runner? newly respawned container which runs CI?
2019-08-20 17:25:59 <Cogitri> It'd need to be a shared runner then
2019-08-20 17:26:22 <Cogitri> It's basically the CI client running on a server running your CI tasks
2019-08-20 17:26:25 <_ikke_> mps: it's a program that can run ci jobs
2019-08-20 17:26:33 <_ikke_> it can use docker for that
2019-08-20 17:27:29 <mps> aha, thought something like that. do the every user have their runners or they are shared by all users
2019-08-20 17:27:44 <_ikke_> shared
2019-08-20 17:28:13 <_ikke_> Cogitri: trying to run a job now, let's see if it works
2019-08-20 17:28:17 <mps> and we as users can somehow trigger it to run
2019-08-20 17:28:29 <Cogitri> ikke; Okie
2019-08-20 17:28:37 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/docker/gitlab-runner/-/jobs/380
2019-08-20 17:28:48 <_ikke_> mps: It runs on merge requests for projects where we've enabled that
2019-08-20 17:29:09 <_ikke_> (it can also run when you just push to a branch)
2019-08-20 17:29:23 <_ikke_> Cogitri: Same issue the running from danieli had
2019-08-20 17:29:24 <mps> ah, for now they just check with atools-lint, I see
2019-08-20 17:29:29 <_ikke_> mps: yes, correct
2019-08-20 17:30:03 <mps> _ikke_: thanks again
2019-08-20 17:30:04 <Cogitri> Huh, docker is running though
2019-08-20 17:30:37 <_ikke_> I think you need to change the runner config a bit
2019-08-20 17:30:46 <danieli> what do we need to do?
2019-08-20 17:30:55 <danieli> docker is running on that socket, and gitlab-runner is running as root
2019-08-20 17:31:25 <_ikke_> in the config.toml (/etc/gitlab-runner/config.toml), you need to have this: volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
2019-08-20 17:31:34 <_ikke_> under runners.toml
2019-08-20 17:31:51 <danieli> so it accesses docker from inside docker containers?
2019-08-20 17:32:09 <_ikke_> Yes
2019-08-20 17:32:11 <danieli> under which level of the config? just at the top?
2019-08-20 17:32:15 <danieli> or under [runners.docker]
2019-08-20 17:32:17 <_ikke_> runners.docker
2019-08-20 17:32:24 <danieli> there, i see it
2019-08-20 17:32:25 <Cogitri> Huh, why's that?
2019-08-20 17:32:35 <danieli> i wonder why it accesses docker from inside containers
2019-08-20 17:32:40 <danieli> that doesn't seem like a good thing
2019-08-20 17:32:40 <_ikke_> The job runs inside the container, which is trying to create docker images
2019-08-20 17:32:44 <danieli> i see
2019-08-20 17:32:54 <_ikke_> Hmm
2019-08-20 17:33:02 <danieli> i restarted it
2019-08-20 17:33:17 <_ikke_> I will probably have a special tag for these kinds of jobs
2019-08-20 17:33:40 <_ikke_> For most CI jobs this is not necessary, just the ones that create docker images themselfs
2019-08-20 17:34:21 <Cogitri> Ah, alrighty
2019-08-20 17:34:26 <Cogitri> Will change the config
2019-08-20 17:35:32 <_ikke_> That specific issue is fixed
2019-08-20 17:35:39 <filoozom> So for RPi 4 the kernel needs to be built with make bcm2711_defconfig instead of make bcm2709_defconfig.
2019-08-20 17:35:53 <filoozom> What's the best way to add that in https://github.com/alpinelinux/aports/blob/master/main/linux-rpi/APKBUILD?
2019-08-20 17:36:36 <Cogitri> Restarted the runner, could you try again, ikke?
2019-08-20 17:37:01 <_ikke_> sure
2019-08-20 17:37:40 <_ikke_> Yeah, works now
2019-08-20 17:37:58 <Cogitri> Nice
2019-08-20 17:38:07 <Cogitri> Gonna restart the server real quick for a kernel upgrade
2019-08-20 17:38:10 <_ikke_> sue,n p
2019-08-20 17:38:14 <_ikke_> sure, np*
2019-08-20 17:39:15 <_ikke_> maxice8: I guess you cannot disable just speicifc tests for kbd?
2019-08-20 17:39:40 <maxice8> I didn't look into individual disabling
2019-08-20 17:40:31 <_ikke_> The problem with just blank disabling tests is that probably no one will bother fixing it / enabling it again
2019-08-20 17:43:57 <mps> filoozom: so, we need separate kernel for rpi4?
2019-08-20 17:45:02 <filoozom> Looks like it. I have an issue while booting Alpine on RPi 4, and I think it must be related to the kernel issue. Also, the documentation seems pretty clear on this: https://www.raspberrypi.org/documentation/linux/kernel/building.md
2019-08-20 17:46:12 <danieli> filoozom: have you tested it?
2019-08-20 17:46:16 <danieli> if not, i can give it a spin
2019-08-20 17:46:24 <filoozom> I'm working on it
2019-08-20 17:47:07 <filoozom> But I'm familiar with neither RPi's kernel nor Alpine so...  :p
2019-08-20 17:47:21 <danieli> i'll build the kernel on a build server
2019-08-20 17:50:37 <filoozom> I've got this: https://github.com/alpinelinux/aports/pull/10260 and this: https://github.com/alpinelinux/aports/pull/10253 for now
2019-08-20 17:50:45 <filoozom> Not quite sure about the kernel part though
2019-08-20 17:51:27 <filoozom> I'd love it if you had more info about it, I could try on my RPi 4 if you don't have one ;)
2019-08-20 17:53:12 <filoozom> How do you build it on your build server for example?
2019-08-20 17:54:25 <danieli> it's a dev container on alpine infrastructure
2019-08-20 17:54:36 <danieli> i run abuild
2019-08-20 17:55:45 <_ikke_> maxice8: https://gitlab.alpinelinux.org/alpine/aports/issues/10747
2019-08-20 17:56:59 <jwh> blehhhh, people who abandon projects suck
2019-08-20 17:57:34 <danieli> if you're serious, that's harsh and seems a bit short sighted
2019-08-20 17:59:10 <filoozom> Can it just be crossbuilt from x86 on Docker? Guess I should have a look at that.
2019-08-20 17:59:23 <jwh> danieli: not really
2019-08-20 17:59:41 <danieli> it's voluntary work and some times people just don't have the opportunity to spend a lot of time and effort without getting paid
2019-08-20 17:59:54 <jwh> sure but like, hand it over to someone else at least
2019-08-20 17:59:58 <danieli> filoozom: cross-compilation on alpine is non-trivial
2019-08-20 18:00:06 <danieli> jwh: it's their project, anyone could fork it
2019-08-20 18:00:35 <jwh> true enough
2019-08-20 18:00:49 <filoozom> So I need to find myself an arm64 server? :p
2019-08-20 18:01:02 <mps> filoozom: or use qemu
2019-08-20 18:02:51 <jwh> main can't depend on other repos right?
2019-08-20 18:03:02 <_ikke_> nope
2019-08-20 18:03:05 <danieli> as far as i can recall: correct
2019-08-20 18:03:09 <_ikke_> main is self-contained
2019-08-20 18:03:22 <jwh> hm
2019-08-20 18:03:59 <jwh> ok
2019-08-20 18:04:16 <_ikke_> now evtest is failing because sys/limits.h is missing
2019-08-20 18:09:01 <_ikke_> sigh, the ppc64le fix seems to break s390x :/
2019-08-20 18:12:17 <_ikke_> maxice8: any idea what I should do with evtest? The fix you applied for ppc64le breaks s390x (due to missing sys/limit.h)
2019-08-20 18:22:37 <joneskoo> Hi. I'm wondering about publishing a package for something that's probably quite niche - I know myself and a couple friends are using it but it's unlikely to have wide interest. Should such package go to aports at all or should I just create my own repo?
2019-08-20 18:23:28 <_ikke_> If you maintain it, I don't see why it cannot be in aports
2019-08-20 18:24:04 <_ikke_> given it's open source
2019-08-20 18:25:16 <joneskoo> I didn't add a LICENSE yet but if it'd make it to aports I figured it'd have to be open source first - shouldn't be a problem.
2019-08-20 18:26:47 <joneskoo> The package in question is a prometheus exporter for bluetooth temperature/humidity sensors - alpine is great for such an application (bluetooth receiver -> prometheus exporter, stateless and low maintenance).
2019-08-20 18:27:46 <joneskoo> https://github.com/alpinelinux/aports/pull/10244 I submitted a PR to fix the example in mdev.conf comment as bluez has deprecated hciattach command. I could update the Raspberry Bluetooth on Alpine wiki page
2019-08-20 18:28:52 <joneskoo> https://wiki.alpinelinux.org/wiki/Raspberry_Pi_3_-_Setting_Up_Bluetooth is rather outdated - the firmware is now included and hciattach is deprecated. I'd edit most of that page away.
2019-08-20 18:29:39 <joneskoo> also rename to be generic for different Pis, it's very similar on Pi Zero W so doesn't make sense to have a specific page for 3.
2019-08-20 18:30:47 <joneskoo> I guess the wiki is a matter of sign up, and edit away and if someone objects they'll revert? Or do you prefer to discuss further first?
2019-08-20 18:33:28 <mps> could the builder skip over failed pkg
2019-08-20 18:34:06 <_ikke_> No
2019-08-20 18:34:39 <mps> ahem
2019-08-20 18:34:42 <mps> ok
2019-08-20 18:35:36 <mps> want to push iwd but s390x still didn't built ell
2019-08-20 18:35:55 <_ikke_> Yes, I'm waiting for it as well
2019-08-20 18:36:35 <mps> heh, we have to learn to be patient :P
2019-08-20 18:38:02 <_ikke_> Do you think this patch would make sense? https://tpaste.us/5wJ0
2019-08-20 18:40:07 <mps> I can try it, if you want
2019-08-20 18:40:52 <joneskoo> Is modloop coming from any package I install or is it part of the distribution? (Would update instructions in wiki)
2019-08-20 18:41:46 <mps> _ikke_: it pass on x86_64
2019-08-20 18:42:24 <_ikke_> yes, for me as well, but I wonder if it still passes on ppc64le
2019-08-20 18:42:45 <mps> eh, don't have such machine
2019-08-20 18:42:54 <_ikke_> me neither
2019-08-20 18:43:08 <mps> and didn't looked on build log for ppc64le
2019-08-20 18:43:10 <danieli> joneskoo: the service comes with openrc
2019-08-20 18:43:47 <mps> _ikke_: failed on armv7
2019-08-20 18:44:04 <_ikke_> hmm, ok
2019-08-20 18:44:13 <mps> evtest.c:62:10: fatal error: sys/limits.h: No such file or directory
2019-08-20 18:45:18 <joneskoo> danieli: I mean, which firmware is included with the modloop
2019-08-20 18:45:40 <joneskoo> danieli: i.e. is the broadcom firmware shipped by default or did I install a package that caused it to be now there.
2019-08-20 18:45:59 <_ikke_> mps: did you apply the patch?
2019-08-20 18:46:18 <_ikke_> line 62 should be the #ifndef line now in evtest.c
2019-08-20 18:46:20 <mps> yes
2019-08-20 18:46:42 <_ikke_> The include should be on line 63
2019-08-20 18:47:10 <_ikke_> can you test this on armv7? https://tpaste.us/vb0L
2019-08-20 18:47:20 <_ikke_> gcc -o path_max path_max.c
2019-08-20 18:47:37 <mps> it starts at '+@@ -59,6 +59,9 @@'
2019-08-20 18:48:46 <mps> oh no, didn't rsynced changes to armv7
2019-08-20 18:48:52 <_ikke_> heh\
2019-08-20 18:49:12 <mps> sorry
2019-08-20 18:50:39 <mps> _ikke_: it builds on armv7, after run rsync :D
2019-08-20 18:51:23 <_ikke_> ok, good
2019-08-20 18:51:40 <mps> and aarch64
2019-08-20 18:53:44 <_ikke_> I went ahead and made a PR it get all arches supported by drone
2019-08-20 18:53:45 <_ikke_> https://github.com/alpinelinux/aports/pull/10262
2019-08-20 18:54:00 <_ikke_> All green
2019-08-20 18:54:05 <_ikke_> thanks mps
2019-08-20 18:54:51 <mps> how do you see results of drones
2019-08-20 18:55:40 <_ikke_> https://cloud.drone.io/alpinelinux/aports/9825
2019-08-20 18:57:07 <mps> I mean, from PR url?
2019-08-20 18:57:29 <_ikke_> It's harder to see now it's closed
2019-08-20 18:57:42 <_ikke_> https://github.com/alpinelinux/aports/pull/10261
2019-08-20 18:57:45 <_ikke_> this shows all checks have passed
2019-08-20 18:57:52 <_ikke_> There is a link "show all checks"
2019-08-20 18:58:03 <_ikke_> then you click on "details" for drone
2019-08-20 19:00:15 <mps> maybe I can't see because I'm not logged in to GH
2019-08-20 19:00:59 <_ikke_> You see a green checkmark apparenyl
2019-08-20 19:01:01 <_ikke_> apparently
2019-08-20 19:01:46 <_ikke_> ttps://imgur.com/a/RcM3aNA
2019-08-20 19:01:49 <_ikke_> https://imgur.com/a/RcM3aNA
2019-08-20 19:02:03 <mps> you mean on drones, yes
2019-08-20 19:02:13 <_ikke_> See that screenshot
2019-08-20 19:05:42 <_ikke_> 55%
2019-08-20 19:06:40 <mps> we don't have drones for s390x and ppc64le?
2019-08-20 19:06:42 <_ikke_> 8 packages to go
2019-08-20 19:06:44 <_ikke_> No
2019-08-20 19:06:55 <mps> ah, that explains
2019-08-20 19:07:11 <_ikke_> on github, we use drone.io cloud
2019-08-20 19:07:29 <_ikke_> they don't have drones for those arches
2019-08-20 19:07:41 <_ikke_> for gitlab, we already have a s390x runner
2019-08-20 19:07:55 <mps> nice, this will help
2019-08-20 19:13:29 <joneskoo> https://wiki.alpinelinux.org/wiki/Raspberry_Pi_3_-_Setting_Up_Bluetooth I basically re-wrote this page now...
2019-08-20 19:20:07 <_ikke_> mps: built finished \o/
2019-08-20 19:20:25 <mps> tmhoang: does it make sense to enable iwd for s390x, does it have wifi
2019-08-20 19:21:39 <mps> _ikke_: s390x is still not idle
2019-08-20 19:21:59 <_ikke_> ah, it finished community, now it moves on to testing
2019-08-20 19:22:18 <mps> and, main? ell is in main
2019-08-20 19:22:27 <_ikke_> main should be finished already
2019-08-20 19:22:48 <mps> aha, main is high priority
2019-08-20 19:23:07 <_ikke_> yes, it first builds main, then community, then testing
2019-08-20 19:51:41 <filoozom> _ikke_ can't you run the s390x on Docker with multiarch?
2019-08-20 19:52:03 <clandmeter> wut?
2019-08-20 19:52:11 <_ikke_> You still need the proper hardware
2019-08-20 19:52:31 <filoozom> danieli: Got it to work for arm64 on Docker with multiarch/alpine, so I'll debug that RPi kernel build there
2019-08-20 19:52:35 <_ikke_> You cannot just run s390x in a docker container on x86* hardware
2019-08-20 19:52:55 <filoozom> In qemu I mean
2019-08-20 19:52:58 <clandmeter> you can only do it with qemu
2019-08-20 19:53:03 <_ikke_> We tend to build on native hardware
2019-08-20 19:53:19 <clandmeter> multiarch is something different
2019-08-20 19:53:23 <filoozom> Yeah, guess that's the most reliable
2019-08-20 19:53:33 <filoozom> I'm talking about this: https://github.com/multiarch/qemu-user-static/releases/
2019-08-20 19:53:56 <filoozom> I guess "multiarch" was ambiguous in my sentence
2019-08-20 19:57:34 <joneskoo> I tried building apk for aarch64 on qemu-user but failed miserably - go segfaults with qemu-user :(
2019-08-20 19:59:58 <clandmeter> there is free ci for those arches on cloud.drone.io
2019-08-20 20:00:06 <clandmeter> no need to emulate
2019-08-20 20:01:10 <_ikke_> great, all kinds of test failures for git-lfs :(
2019-08-20 20:01:22 <_ikke_> on multiple arches
2019-08-20 20:02:45 <clandmeter> disable all tests and cross fingers..
2019-08-20 20:03:16 <_ikke_> heh
2019-08-20 20:03:26 <_ikke_> There is an update available, first testing that
2019-08-20 20:17:10 <_ikke_> Apparently it's failing purely on drone
2019-08-20 20:22:02 <_ikke_> travis is succeeding
2019-08-20 20:24:04 <_ikke_> 
ACTION crosses fingers

2019-08-20 20:31:39 <_ikke_> :(
2019-08-20 20:31:43 <_ikke_> still failing on x86
2019-08-21 10:02:01 <filoozom> So apparently the current version of linux-rpi doesn't actually compile. So of course my PR doesn't either.
2019-08-21 10:07:22 <clandmeter> filoozom: what makes you think that?
2019-08-21 10:07:24 <danieli> i started building linux-rpo on aarch64
2019-08-21 10:07:26 <danieli> just to check
2019-08-21 10:07:55 <filoozom> Well my PR didn't build on Drone, so I built it locally with and without my PR and I always get the same error:
2019-08-21 10:08:00 <filoozom> >>> linux-rpi-dev: Running split function _dev...
2019-08-21 10:08:00 <filoozom> e target 'arch/aarch64/Makefile'.  Stop.
2019-08-21 10:08:03 <filoozom> > ERROR: linux-rpi-dev: _dev failed
2019-08-21 10:08:57 <danieli> it's currently building for me, i think your pr must have broken something
2019-08-21 10:09:06 <clandmeter> its post build
2019-08-21 10:09:09 <danieli> aha
2019-08-21 10:09:13 <clandmeter> filoozom: show me your drone log
2019-08-21 10:09:14 <danieli> right, brainfart
2019-08-21 10:09:20 <filoozom> https://cloud.drone.io/alpinelinux/aports/9823/3/1
2019-08-21 10:09:52 <clandmeter> looks like you broke something
2019-08-21 10:11:06 <filoozom> It's the same on master though, unless I broke my alpine container by only building my PR, but that would be weird, wouldn't it?
2019-08-21 10:12:03 <mps> skimmed through rpi4 kernel and it looks like it should be separate kernel pkg
2019-08-21 10:12:52 <mps> don't have rpi4 board so couldn't check to be sure
2019-08-21 10:12:57 <filoozom> Building this on a 40 core Xeon server in Qemu still takes ages, any way to make it faster?
2019-08-21 10:13:25 <danieli> compiling linux is pretty slow
2019-08-21 10:13:46 <danieli> i'm building on a 96 core (thread?) thunderx
2019-08-21 10:14:08 <mps> filoozom: do you enable acceleration options for qemu
2019-08-21 10:14:11 <filoozom> Where did you get that from? :p
2019-08-21 10:14:17 <danieli> it's part of alpine infrastructure
2019-08-21 10:14:36 <danieli> i use a container on it to test stuff
2019-08-21 10:14:50 <filoozom> I've been wanting to buy a Cavium ThunderX for ages, but I feel like those things are crazy expensive for what they are
2019-08-21 10:15:06 <danieli> depends how much you need arm64
2019-08-21 10:15:27 <mps> danieli: looks like I'm second class dev, just 64 cores :D
2019-08-21 10:15:29 <danieli> linux-rpi build fine from latest aports
2019-08-21 10:15:33 <filoozom> mps: not that I'm aware of, just using the multiarch/alpine docker container
2019-08-21 10:15:37 <danieli> mps: that's armv7 isn't it?
2019-08-21 10:15:48 <clandmeter> mps: yours is faster
2019-08-21 10:15:52 <danieli> ^
2019-08-21 10:16:06 <mps> oh, so I'm first class dev ;-)
2019-08-21 10:16:24 <mps> just kidding, ofc
2019-08-21 10:16:41 <danieli> to be fair, you've done way more work than me lately, i've been terribly busy and somewhat exhausted from $dayjob and various stuff
2019-08-21 10:17:01 <mps> filoozom: do you build in qemu or docker, not clear to me
2019-08-21 10:17:29 <filoozom> Well, it's a docker container containing qemu
2019-08-21 10:17:30 <mps> danieli: we all do what we can and it depends on our time
2019-08-21 10:17:40 <mps> I do not ranking us
2019-08-21 10:18:13 <mps> filoozom: it would be better to run qemu on bare OS, skipping docker
2019-08-21 10:18:33 <filoozom> danieli: Guess I'll try rebuilding it from scratch then.
2019-08-21 10:18:40 <filoozom> @mps
2019-08-21 10:18:55 <filoozom> Whoops, yeah I guess it might be better, but not as easy to set up I fear :p
2019-08-21 10:18:59 <mps> do you run alpine on you build machine
2019-08-21 10:19:10 <filoozom> I'm not really familiar with all of this, I'll see what I can do.
2019-08-21 10:19:35 <filoozom> I run Ubuntu Server
2019-08-21 10:20:16 <mps> here is my short guide how to install alpine aarch64 to run under qemu http://arvanta.net/mps/install-aarch64-under-qemu.txt
2019-08-21 10:20:52 <mps> and a script to do it automatically http://arvanta.net/mps/install-aarch64-under-qemu.sh
2019-08-21 10:21:23 <mps> ofc, needs some tweaks and changing parameters for particular use cases
2019-08-21 10:21:36 <mps> but that could be starting point
2019-08-21 10:22:10 <filoozom> Thanks
2019-08-21 10:22:16 <mps> and I'm here (well, not always) to help, and not only I
2019-08-21 10:23:33 <filoozom> I think I might actually rent an ARM server in order to save some time :p  How long does it take to build on a 64 core ARMv8? :p
2019-08-21 10:27:18 <mps> didn't measured but it takes some time, and I never user more than 16 cpu's on alpine dev machines
2019-08-21 10:29:14 <mps> building cross kernels in my local lxc debian takes about half an hour, with 6 cpus
2019-08-21 10:29:40 <mps> hmm, cross building*
2019-08-21 10:51:26 <clandmeter> filoozom: i added a comment to your commit
2019-08-21 10:51:50 <filoozom> Just saw, thanks
2019-08-21 10:52:48 <filoozom> I see, so basically I just need this:
2019-08-21 10:52:49 <filoozom> rpi4() {
2019-08-21 10:53:43 <clandmeter> the rpi kernel apkbuild is a little complicated. you need to analyze it correctly.
2019-08-21 10:54:04 <clandmeter> you can just add your changes and force push to the pr. the CI will build it again.
2019-08-21 10:54:09 <clandmeter> no need to build anything local
2019-08-21 10:59:27 <filoozom> Yeah, that's what I was planning on doing since it's way faster anyways.
2019-08-21 11:00:03 <filoozom> And I do see that it's complicated, especially since I'm not particularly familiar with alpine nor kernels so yeah
2019-08-21 11:02:32 <clandmeter> im not sure its complicated, but its more complicated as other apkbuilds.
2019-08-21 11:02:43 <clandmeter> in the end its just shell
2019-08-21 11:03:37 <filoozom> Yeah, I'm sure I'll somehow find a solution. It's just the endless build times that are quite painful
2019-08-21 11:07:01 <artok> oh filoozom is doing rpi4 packages.. great!
2019-08-21 11:07:12 <filoozom> Trying*
2019-08-21 11:10:01 <filoozom> Although the bootloader should be working already.
2019-08-21 11:11:33 <filoozom> (With the PR at least)
2019-08-21 11:14:52 <artok> and the kernel behaves good?
2019-08-21 11:15:55 <artok> well at least the travis-ci passed the build
2019-08-21 11:20:31 <filoozom> We'll have to wait for the aarch64 build to finish on Drone
2019-08-21 11:20:41 <filoozom> We're not quite there yet I think
2019-08-21 11:21:08 <artok> yeah, it is in middle of building kernel
2019-08-21 11:33:01 <artok> nearly there!
2019-08-21 11:35:00 <filoozom> Well, looks like it built correctly. Not quite sure what it's doing now, but it's going to take quite a bit more time for the CI to be done :p
2019-08-21 11:38:17 <filoozom> Done already actually! :D
2019-08-21 11:41:06 <ncopa> finally pushed the wpa_supplicant init.d fixes. was harder than expected to get it right
2019-08-21 11:46:54 <filoozom> danieli: You're right, the kernel did build on the current version. Not in my container though, which is why I was getting confused. No clue as to why yet.
2019-08-21 12:59:35 <tmhoang> Hey systemd have firstboot service too. So we were not alone when we introduce firstboot.initd :P /usr/lib/systemd/system/systemd-firstboot.service
2019-08-21 13:06:03 <TBB> _of course_ systemd has firstboot
2019-08-21 13:06:41 <TBB> systemd has * and if it doesn't yet it's got its eyes on the rest of the *
2019-08-21 14:10:37 <mps> PureTryOut[m]: license should be some from spdx, 'none' doesn't looks right
2019-08-21 14:10:48 <PureTryOut[m]> It has no license though
2019-08-21 14:11:09 <mps> strange
2019-08-21 14:11:12 <PureTryOut[m]> I had this discussino before with libretro-core-info
2019-08-21 14:11:24 <PureTryOut[m]> I guess, but there is no code in that package
2019-08-21 14:12:07 <mps> data also have licenses
2019-08-21 14:12:13 <PureTryOut[m]> Not this repo
2019-08-21 14:12:19 <PureTryOut[m]> It can have a license, but it doesn't
2019-08-21 14:13:05 <mps> strange again, but according to IP laws everything has license
2019-08-21 14:15:49 <MY_R> ye and no licene = no permission to use it, share or modify
2019-08-21 14:16:09 <MY_R> s/or/and
2019-08-21 14:16:57 <alpine-meetbot> MY_R meant to say: ye and no licene = no permission to use it, share and modify
2019-08-21 14:17:09 <_ikke_> Everything has copyright
2019-08-21 14:17:23 <_ikke_> a license provides means to distribute something copyrighted
2019-08-21 14:18:32 <MY_R> yep
2019-08-21 14:18:36 <mps> I suspect that distro can distribute content without license
2019-08-21 14:18:53 <_ikke_> WHy?
2019-08-21 14:19:19 <mps> it's a slippery slope
2019-08-21 14:19:47 <_ikke_> So you mean they cannot?
2019-08-21 14:19:55 <mps> who warrants they will not change their minds in future
2019-08-21 14:20:26 <mps> ohm, sorry, my english
2019-08-21 14:20:56 <mps> I suspect^W think that distro can^w cannot distribute content without license
2019-08-21 14:21:19 <_ikke_> Yes, exactly
2019-08-21 14:21:43 <_ikke_> Without license, it's copyrighted, and distros distribute it, they are liable
2019-08-21 15:28:46 <filoozom> Can someone with one of those nifty ARMv8 machine build https://github.com/alpinelinux/aports/pull/10260 and send me a link to the apks? I'd like to try it out on my RPi to make sure there's nothing else to change.
2019-08-21 15:29:03 <danieli> filoozom: i was just about to :)
2019-08-21 15:29:20 <filoozom> Thanks!
2019-08-21 15:29:44 <mps> danieli: you were faster, thanks
2019-08-21 15:29:58 <danieli> oh right, link to the apks too, i would have to expose it somewhere
2019-08-21 15:30:14 <danieli> i'll test it on my rpi, if it works, i'll upload them on some web server
2019-08-21 15:30:34 <filoozom> Sure, or I'll just wait for the merge + release ;p
2019-08-21 15:30:46 <danieli> no point in merging it if it doesn't work
2019-08-21 15:30:59 <filoozom> I meant if it works
2019-08-21 15:31:00 <danieli> it may build but that does not guarantee it will boot :)
2019-08-21 15:31:06 <filoozom> Instead of uploading, I can also just wait.
2019-08-21 15:31:22 <filoozom> Yes, that's why I'd like to try it out :)
2019-08-21 15:32:09 <_ikke_> is the rpi4 armv8?
2019-08-21 15:32:11 <danieli> at the moment, it's easier and quicker for me to test it locally rather than find some web server i can put random stuff on
2019-08-21 15:32:12 <danieli> yes
2019-08-21 15:32:20 <danieli> i believe so anyway, let me double check
2019-08-21 15:33:18 <danieli> yes, armv8-a
2019-08-21 15:33:33 <_ikke_> is it backwards compattible?
2019-08-21 15:33:42 <danieli> as far as i can tell, no
2019-08-21 15:33:45 <filoozom> Or just use wetransfer maybe? I could even give you some FTP/SFTP access or something.
2019-08-21 15:33:48 <_ikke_> Or would we need to have a new repo for it?
2019-08-21 15:34:03 <danieli> but i believe raspbian has a build that supports both rpi3 and 4, but don't quote me on that
2019-08-21 15:34:45 <filoozom> I think their Raspbian builds work for litteraly every Pi
2019-08-21 15:34:51 <artok> raspbian supports all pi
2019-08-21 15:34:54 <filoozom> But they don't have an arm64 version
2019-08-21 15:35:02 <danieli> right, that's a very good point
2019-08-21 15:35:07 <artok> that's because they ... that
2019-08-21 15:35:18 <danieli> they would still have to compile support for the rpi4 soc into the kernel though, arm64 or not
2019-08-21 15:35:36 <mps> I think aarch64 will work on rpi4
2019-08-21 15:35:55 <danieli> it will
2019-08-21 15:36:03 <filoozom> aarch64 works on RPi since revision 1.2 of RPi 2 IIRC
2019-08-21 15:36:06 <mps> only kernel and bootloader need to be added or tweaked
2019-08-21 15:36:26 <filoozom> Yes, and I have a PR for the bootloader already that seems to work
2019-08-21 15:36:39 <danieli> looks like it
2019-08-21 15:36:48 <mps> filoozom: not owning rpi's but I think aarch64 works on rpi3 only
2019-08-21 15:36:53 <artok> https://github.com/sakaki-/bcm2711-kernel one config for kernel
2019-08-21 15:36:59 <danieli> rpi2 1.2, rpi3b, rpi3b+, rpi4b, rpi compute module 3
2019-08-21 15:37:26 <mps> ah, ok
2019-08-21 15:38:11 <filoozom> a22042	Q3 2016	2 Model B (with BCM2837)	1.2
2019-08-21 15:38:16 <filoozom> Yeah, that's what I thought :p
2019-08-21 15:47:52 <filoozom> By the way, y'all are super nice. I'll probably stick around a bit :p
2019-08-21 15:50:14 <_ikke_> filoozom: We try to be a welcomming comunity
2019-08-21 16:01:11 <PureTryOut[m]> mps: I requested a license to be added to the repo and they did, so I've send patches to update the license info in the APKBUILDs
2019-08-21 16:03:57 <mps> just replied to your post on ML
2019-08-21 16:04:16 <PureTryOut[m]> I noticed a mistake lol hold on
2019-08-21 16:04:43 <mps> could you post complete patch so we don't have to go three times with 'git am ...'
2019-08-21 16:05:09 <PureTryOut[m]> What do you mean? I made a mistake, but otherwise the patches I've send are complete
2019-08-21 16:06:01 <mps> your last patches presumes that the previous patch is already applied to git tree
2019-08-21 16:06:17 <PureTryOut[m]> The previous patch being...?
2019-08-21 16:06:31 <mps> or, ML software plays with me
2019-08-21 16:06:34 <PureTryOut[m]> libretro-database and libretro-core-info were already in the git tree
2019-08-21 16:06:40 <mps> let me look at web site
2019-08-21 16:07:28 <mps> ah, I see
2019-08-21 16:07:46 <mps> sorry
2019-08-21 16:07:59 <PureTryOut[m]> Np
2019-08-21 16:09:52 <mps> I'm now busy with some woodwork (just made small pause) and will look later if no one check and push in meantime
2019-08-21 16:12:09 <PureTryOut[m]> 👍️
2019-08-21 16:14:12 <maxice8> Those patches needed to be modified to avoid having a commit that changes arch= to MIT and then to noarch in the next commit
2019-08-21 16:14:32 <maxice8> Pushed as this https://git.alpinelinux.org/aports/commit/?id=9d7aadb9dc2f4e12727d3fb18e0a9b4578982fd4 https://git.alpinelinux.org/aports/commit/?id=1413d577cd23470ca0ee3aebf7e37db9f336105e
2019-08-21 16:20:07 <mps> meantime was short, I see :-)
2019-08-21 16:20:24 <maxice8> I was in the bathroom
2019-08-21 16:20:24 <PureTryOut[m]> 😂
2019-08-21 16:20:32 <PureTryOut[m]> Lovin' it
2019-08-21 16:23:22 <danieli> filoozom: https://duniel.no/tmp/linux-rpi4-4.19.67-r0.apk https://duniel.no/tmp/linux-rpi4-dev-4.19.67-r0.apk
2019-08-21 16:23:27 <danieli> wrong content-type but whatever
2019-08-21 17:05:32 <artok> so now when rpi4 has bootloader on EEPROM, we don't need bootcode.bin. it is ignored . only thing is start.elf
2019-08-21 18:50:52 <joneskoo> hey, if I want to get headless support for alpine (raspberry pi in particular, but I figure it'll work on all variants running from read-only media), how do I? :)
2019-08-21 18:51:47 <joneskoo> in particular, I want 1) setup-alpine answers file editable without booting alpine 2) enable sshd and networking without keyboard, display or serial
2019-08-21 18:52:25 <joneskoo> alpine-headless:/media/mmcblk0p1# head /media/mmcblk0p1/alpine-headless-answers.txt
2019-08-21 18:52:28 <_ikke_> I don't think that's supported at the moment, though there is interest in getting it to work
2019-08-21 18:52:28 <joneskoo> # Answer file for alpine-headless. To execute this on first boot,
2019-08-21 18:52:31 <joneskoo> # create an empty file headless in this directory.
2019-08-21 18:53:04 <joneskoo> I mean, I did a kind of a proof-of-concept with lbu and local.d but it still has issues. I also realized I did it accidentally on 3.8 :facepalm:
2019-08-21 18:53:32 <danieli> headless? you mean unattended?
2019-08-21 18:54:10 <danieli> if I were you I'd do it through scripts in a custom image
2019-08-21 18:54:15 <joneskoo> I mean headless i.e. I don't have display or input. For me I don't care if it's unattended, although that would be ideal.
2019-08-21 18:54:59 <joneskoo> I want it to be built-in to alpine to make it generic - I think this allows building IoT-like applications on top of alpine really easily on rpi and similar devices in particular
2019-08-21 18:56:18 <joneskoo> I think the current fix with ntpd is not right though. https://github.com/alpinelinux/alpine-conf/commit/8c6d977259da9bbf4f416ddc2195bf22483259b5 I think setup-ntp doesn't block until ntpd has set time.
2019-08-21 18:56:49 <joneskoo> At least on 3.8 if I just did that, it didn't set time and failed on the apkrepos as clock was still 1970
2019-08-21 18:58:20 <danieli> alpine is, by default, boots into a live environment with no GUI
2019-08-21 18:58:23 <joneskoo> yes, with apkovl it'd be probably easier to just create the apkovl and call it done, but there's the bootstrap problem to do it for armhf or aarch64.
2019-08-21 18:58:58 <danieli> we don't have any advanced facilities to do what you want other than things like lbu
2019-08-21 18:59:18 <danieli> https://blog.w1r3.net/2018/04/16/automated-provisioning-using-apkovl.html found this on google though
2019-08-21 18:59:23 <joneskoo> well, simply I want to put setup-alpine answers file on the SD card and have it run on first-boot
2019-08-21 19:00:56 <joneskoo> basically just having firstboot facility to run a script if it exists from the SD card would be enough.
2019-08-21 19:08:47 <j8r> mps I think the Crystal aarch64 issue would be longer to solve than expected. We can use LLVM5 then :/
2019-08-21 19:09:08 <joneskoo> hm, KOPT_ip KOPT_ssh_key  https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in  I think this is already supported
2019-08-21 20:24:53 <mps> j8r: I come to same conclusion
2019-08-21 20:25:34 <mps> tried to rebuild llvm8 with '-DLLVM_ENABLE_ASSERTIONS=ON' but it failed
2019-08-21 20:28:16 <tmhoang> joneskoo: ssh_key= should work for remote keys. I don't know why people don't just $ dd Alpine (using qcow image?) to sd card, fix bootloader of sd card, and then boot.
2019-08-21 20:32:03 <mps> j8r: I will try to rebuild crystal with llvm5 on x86_64 and if it works then I will 'upgrade' to the same APKBUILD for both, x86_64 and aarch64
2019-08-21 20:32:34 <mps> with a hope that the upstream developers will fix the issues with llvm8
2019-08-21 20:36:25 <joneskoo> tmhoang: on raspberry no need to fix anything, it's just untar on a FAT partition and done.
2019-08-21 20:41:45 <tmhoang> joneskoo> I give up trying to get ip=dhcp and ssh_key to work on alpine, better approach is to create apkovl for firstboot --> this or make a ready-to-use image as above. Should be fine for you I guess. Strange no rpi users have reported this issue before.
2019-08-21 20:42:46 <joneskoo> I guess most rpi users plug in a display and keyboard and use it like a computer.. crazy.
2019-08-21 20:50:22 <danieli> i have for a couple live display type things, but 95% of my raspberrys are headless
2019-08-21 23:11:04 <maxice8> s390x is stuck on envconsul
2019-08-22 00:40:31 <maxice8> radicale.initd calls --foreground and then uses command_background=yes
2019-08-22 06:03:04 <ncopa> tmhoang: seems like s390x builder hangs when fetching sources from git for some reason
2019-08-22 06:03:44 <ncopa> http://tpaste.us/baRL
2019-08-22 06:03:57 <ncopa> its not the first time
2019-08-22 07:37:59 <tmhoang> ncopa: is there a specific git repo or any of them ? also please help me to delete lxc `tmh1999-edge-s390x`, I have not used it for so long.
2019-08-22 07:38:53 <ncopa> it seems to be go build that fetches stuff from git
2019-08-22 07:39:00 <ncopa> not sure if it is specific repo or not
2019-08-22 07:39:08 <tmhoang> I think it hangs for other reasons, or else it's network issue
2019-08-22 07:39:18 <ncopa> could be network issues
2019-08-22 07:39:56 <tmhoang> s390x builder does not enjoy the datacenter standards equivalentce like ppc64le. there are plans to move it up, next 1-2 years ...
2019-08-22 07:41:47 <tmhoang> no shit 5 hops to 1.1.1.1, 7 hops to 8.8.8.8
2019-08-22 07:43:03 <tmhoang> ncopa: what packages s390x was building and fetching git source that make it hangs ?
2019-08-22 08:43:38 <ncopa> tmhoang: envconsul
2019-08-22 09:19:14 <filoozom> danieli: Did it work?
2019-08-22 09:26:40 <filoozom> danieli: Ah I just saw you answered in the logs, my bad.
2019-08-22 09:31:59 <ncopa> I wonder if we can remove the "Aports" label from gitlab
2019-08-22 09:32:19 <ncopa> it was imported from redmine
2019-08-22 09:32:25 <ncopa> and i dont think the label makes any sense
2019-08-22 09:32:35 <_ikke_> Probably
2019-08-22 10:04:16 <filoozom> Is there a procedure somewhere to build the complete RPi "image"? I frankensteined some things together (modloop and initramfs) with linux-rpi4 but it doesn't work.
2019-08-22 10:05:12 <mps> filoozom: aports/scripts and look mkimg shell scripts
2019-08-22 10:08:39 <filoozom> Ah, perfect! Reminds me I wanted to submit a PR to replace arm_control with arm_64bit=1A
2019-08-22 10:15:23 <mps> ncopa: I'm on patch working to enable CONFIG_XFRM_INTERFACE=m for issue https://gitlab.alpinelinux.org/alpine/aports/issues/10701
2019-08-22 10:15:46 <mps> patch is simple, I'm testing build kernel actually
2019-08-22 10:16:21 <mps> and have a question: do we need linux-firmware in makedepends for linux-vanilla
2019-08-22 10:20:13 <ncopa> mps: i thought about that some time ago
2019-08-22 10:20:20 <ncopa> but i dont remember what the conclusion was
2019-08-22 10:20:47 <ncopa> so
2019-08-22 10:21:08 <ncopa> abuild will pull in the runtime deps together with the makedepends
2019-08-22 10:21:09 <mps> also I can't remember but it builds without linux-firmware
2019-08-22 10:21:27 <ncopa> and linux-firmware is a runtime dep
2019-08-22 10:21:58 <ncopa> the kernel may boot without it, but I was afraid to remove it as runtime dep, because it could break peoples installs
2019-08-22 10:22:12 <mps> commit 238db1dae122512cab656d48d552fd7da5b37351 is where it is added
2019-08-22 10:22:20 <ncopa> the way i solved it was to add provides
2019-08-22 10:22:31 <ncopa> i think we had dependency on it before that
2019-08-22 10:23:01 <mps> look this commit e404e12b126cb0c7f3356aea3685208fb30e23ca
2019-08-22 10:23:22 <ncopa> the linux-firmware-any was so that you could do: apk add linux-firmware-none, in case you didnt need any
2019-08-22 10:23:53 <mps> could it be in depends and not makedepends
2019-08-22 10:24:52 <ncopa> what i am afraid of is that people do apk upgrade and the firmware gets uninstalled
2019-08-22 10:25:03 <ncopa> some firwmare that they dont know they need
2019-08-22 10:25:34 <ncopa> i think linux-fiwmare-any is in depends, not makedepends, but abuild will pull in depends together with makedepends
2019-08-22 10:26:11 <ncopa> i think the workaround is to install linux-firmware-none on your build machine
2019-08-22 10:26:38 <mps> no, makedepends="$_depends_dev sed installkernel bc linux-headers linux-firmware openssl-dev"
2019-08-22 10:27:01 <ncopa> hum
2019-08-22 10:27:04 <mps> and: depends="mkinitfs"
2019-08-22 10:27:23 <ncopa> that does not make sense
2019-08-22 10:27:24 <ncopa> oh
2019-08-22 10:27:26 <ncopa> it does
2019-08-22 10:28:52 <ncopa> # main flavor installs in $pkgdir
2019-08-22 10:28:52 <ncopa> package() {
2019-08-22 10:28:52 <ncopa>         depends="$depends linux-firmware-any"
2019-08-22 10:28:56 <ncopa> thats why
2019-08-22 10:29:05 <mps> hmm, depend = linux-firmware-any is added by abuild?
2019-08-22 10:29:16 <ncopa> mo
2019-08-22 10:29:17 <ncopa> no
2019-08-22 10:29:25 <ncopa> but it was supposed to
2019-08-22 10:29:52 <ncopa> i think we could change the makedepends to include linux-firmware-any
2019-08-22 10:30:08 <mps> here is .PKGINFO from one of my builds http://tpaste.us/7vqj
2019-08-22 10:30:17 <ncopa> http://tpaste.us/1nez
2019-08-22 10:30:32 <ncopa> its added in package() function
2019-08-22 10:30:47 <ncopa> which is why it was added to makedepends in addition
2019-08-22 10:30:55 <ncopa> (i think)
2019-08-22 10:30:58 <mps> could it go to depends
2019-08-22 10:31:30 <mps> then linux-firmware will not be pulled by builders
2019-08-22 10:31:31 <ncopa> the problem with that is that the other supbackages would inherit it
2019-08-22 10:31:55 <ncopa> linux-virt should not depend on any firmware
2019-08-22 10:31:55 <mps> you mean -virt and -dev
2019-08-22 10:32:10 <ncopa> yes
2019-08-22 10:32:22 <mps> aha, makes sense
2019-08-22 10:32:24 <ncopa> i think that is the reason why it was done that way
2019-08-22 10:32:51 <ncopa> i was thinking of adding linux-firmware-none to makedepends
2019-08-22 10:32:57 <ncopa> but i think thats a bad idea
2019-08-22 10:33:07 <mps> I only don't like to pull all firmware when building it on my local boxes
2019-08-22 10:33:38 <mps> but, ok, I added apk-cache some time ago
2019-08-22 10:33:44 <ncopa> if you have a system that has some random firmware installed pulled in by default linux-firmware package
2019-08-22 10:34:14 <ncopa> and when you build the kernel you get linux-firmeware-none installed as dep, it will uninstall the currently installed firmwares
2019-08-22 10:34:26 <mps> I'm trying to keep build containers clean as possible
2019-08-22 10:34:37 <ncopa> if power goes of during kernel build, you may not get your machine back due to missing firmware
2019-08-22 10:34:39 <ncopa> yes
2019-08-22 10:34:45 <ncopa> i understand
2019-08-22 10:34:53 <ncopa> and i want that myself
2019-08-22 10:35:04 <ncopa> i have been annoyed over the same thing
2019-08-22 10:35:11 <ncopa> but never taken the time to actually fix it
2019-08-22 10:35:30 <mps> ok, now i see it is ok as it is
2019-08-22 10:35:35 <mps> case closed
2019-08-22 10:35:41 <ncopa> no
2019-08-22 10:35:43 <ncopa> i think its broken
2019-08-22 10:36:06 <mps> why is broken
2019-08-22 10:36:09 <ncopa> the idea is to install linux-firmware-none on your build machine (lxc container)
2019-08-22 10:36:21 <ncopa> but i think it will still pull in all firwmare
2019-08-22 10:36:44 <mps> you mean, abuild will pull all firmware
2019-08-22 10:36:49 <ncopa> yes
2019-08-22 10:36:57 <ncopa> it does
2019-08-22 10:37:00 <mps> let me try
2019-08-22 10:37:04 <ncopa> i just did
2019-08-22 10:37:06 <ncopa> its broken
2019-08-22 10:37:11 <mps> aha
2019-08-22 10:37:21 <ncopa> this is the fix: http://tpaste.us/1nez
2019-08-22 10:37:54 <mps> linux-firmware-any
2019-08-22 10:38:02 <mps> will that be enougs
2019-08-22 10:38:23 <mps> enough*
2019-08-22 10:40:06 <mps> will try to build with your last patch
2019-08-22 10:41:50 <ncopa> yes, that solves it
2019-08-22 10:42:21 <mps> good
2019-08-22 10:42:40 <ncopa> does not need to do full build. `abuild deps` is enough ;)
2019-08-22 10:43:52 <mps> I want to see final apk content
2019-08-22 10:44:16 <mps> .PKGINFO, I mean
2019-08-22 10:46:50 <mps> for reference: 'sudo apk add linux-firmware-none' and then 'abuild deps' or 'abuild -r' will not pull firmware apks
2019-08-22 10:51:26 <ncopa> that fix is simple but the commit message will be somewhat complicated....
2019-08-22 10:53:25 <mps> hehe, also I'm bad at writing commit messages
2019-08-22 11:04:30 <ncopa> fix was pushed
2019-08-22 11:05:13 <mps> I follow #alpine-commits ;-)
2019-08-22 11:05:15 <ncopa> re gitlab labels. there is a "Kernel" label and a "C-Kernel" label
2019-08-22 11:05:29 <ncopa> i guess we dont need both?
2019-08-22 11:07:27 <mps> when we started about kernel, what is your opinion about MR to move dtb's to /boot
2019-08-22 11:08:20 <mps> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/27
2019-08-22 11:15:59 <ncopa> tmhoang: can you please have a look at https://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/libmodbus/libmodbus-3.1.6-r0.log
2019-08-22 11:17:11 <ncopa> mps: my thinking about that MR is currently that we should delete the "C-kernel" label and rename "Kernel" to "C-kernel" and set that color too :)
2019-08-22 11:17:28 <ncopa> basically, i havent looked at the MR itself
2019-08-22 11:17:30 <ncopa> yet
2019-08-22 11:19:12 <mps> it is one line change, commit msg explains (in short) rationale
2019-08-22 11:24:35 <ncopa> where do other distros store it?
2019-08-22 11:24:50 <ncopa> how big is it?
2019-08-22 11:25:07 <ncopa> as i understand, this is only needed for booting?
2019-08-22 11:25:29 <ncopa> does other scripts needs to be adjusted? (update-kernel, setup-alpine?)
2019-08-22 11:25:29 <mps> I think debian, armbian and arch puts them under /boot
2019-08-22 11:25:53 <ncopa> i guess we should have this discussions in gitlab
2019-08-22 11:25:55 <ncopa> for the record
2019-08-22 11:25:56 <mps> no, it works without any other changes
2019-08-22 11:26:10 <mps> ok, I will open issue
2019-08-22 11:26:35 <ncopa> i mean, i should ask those questions in gitlab
2019-08-22 11:26:43 <ncopa> i'll ask them there
2019-08-22 11:26:48 <mps> on MR?
2019-08-22 11:27:15 <ncopa> yes
2019-08-22 11:28:36 <mps> good, we will start to use gitlab for more things
2019-08-22 11:29:15 <tmhoang> ncopa: ok sure
2019-08-22 12:04:00 <filoozom> Does someone in here have a bit of time and resources (ARMv8 server) to build a complete RPi image with my 3 PRs from GitHub?
2019-08-22 12:17:50 <ncopa> filoozom: which PRs?
2019-08-22 12:18:50 <filoozom> https://github.com/alpinelinux/aports/pull/10342 and the one referenced, so 10342, 10253 and 10260
2019-08-22 12:48:22 <ncopa> gave some feedback
2019-08-22 12:50:01 <mps> (still didn't managed to learn how do build tarball for arm)
2019-08-22 13:01:56 <filoozom> mps: Yeah, that's also part of why I'm asking someone else :p
2019-08-22 13:21:29 <filoozom> By the way, why do you have a gitlab and GitHub? And an external private git as well, right?
2019-08-22 13:22:11 <_ikke_> filoozom: We are switching from github to gitlab
2019-08-22 13:22:34 <_ikke_> And our own git server indeed, which is for the time being the cannonical source for aports
2019-08-22 13:23:15 <filoozom> _ikke_: Why the move? Most open source projects are still on GH, and it's fairly nice to have everything centralized.
2019-08-22 13:24:44 <mps> filoozom: are you sure that centralization is good, especially on proprietary service for open/free source
2019-08-22 13:25:33 <tmhoang> how is the new workflow in gitlab ? Clone aports, add remote gitlab aports, create branch, git push (basically the same on github) ?
2019-08-22 13:25:56 <Cogitri> About the same as GH, yes
2019-08-22 13:25:57 <tmhoang> aka. ignore my old github aports fork ?
2019-08-22 13:26:00 <tmhoang> thanks
2019-08-22 13:26:30 <filoozom> mps: I mean, you could still move if some day something bad happens. You don't lose control of your data if you have a copy lying around somwhere.
2019-08-22 13:28:04 <mps> filoozom: try to export mailing lists from sourceforge.net if you think it is easy or even possible
2019-08-22 13:28:13 <filoozom> I'm not a fan of scattered around git repos, and now you also have to host it which is more work. I mean, that's perfect if it suits your needs, just trying to understand the rationale :)
2019-08-22 13:28:34 <mps> and, two weeks ago github blocked access from some countries
2019-08-22 13:28:46 <filoozom> Oh, wasn't aware of that :o
2019-08-22 13:29:53 <filoozom> Ah, but it's because of US law if I understand correctly.
2019-08-22 13:30:20 <mps> git (software) is made as reaction to similar situation, BitKeeper fiasco, search for it. it is good lecture
2019-08-22 13:33:15 <tmhoang> ncopa: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/31. now looking at  envconsul
2019-08-22 13:33:58 <Cogitri> mps: Yes, git itself being decentralised is a good thing, but it's pretty annoying collaborating with others when you're scattered around many platforms
2019-08-22 13:34:43 <Cogitri> I so kind of dream about Gitlab with federation though, but I guess that can't be done in a performant way :/
2019-08-22 13:35:11 <mps> Cogitri: this is not issue with git, this is the results of 'addons' on top of the git
2019-08-22 13:36:23 <mps> collaboration could be done with git and ML's quite successfully, as the kernel shows
2019-08-22 13:36:52 <_ikke_> or git itself
2019-08-22 13:36:55 <mps> but this needs 'real' developers
2019-08-22 13:37:23 <_ikke_> but just plain mailing lists do not have things like CI
2019-08-22 13:37:27 <mps> _ikke_: ok, kernel uses patchwork and gitolite I think
2019-08-22 13:46:14 <Cogitri> And even so, mailing infrastructure is centralised too
2019-08-22 13:46:26 <Cogitri> You just need some "hub" (heh) for collaboration with Git
2019-08-22 13:48:29 <mps> mailing lists for a lot of open/free projects are mirrored around world
2019-08-22 13:49:23 <_ikke_> but not the service to distribute posts
2019-08-22 14:00:09 <mps> yes, we live in imperfect world and world never was perfect nor it will be
2019-08-22 14:01:11 <mps> but we can take potential risks into account when we deciding how we will organize collaborations
2019-08-22 14:24:07 <ncopa> tmhoang: thanks!
2019-08-22 14:25:35 <_ikke_> tmhoang: type in commit message: s/folk/fork
2019-08-22 14:25:39 <_ikke_> typo
2019-08-22 14:25:54 <_ikke_> (I somehow always typo 'typo' when point out a typo
2019-08-22 14:25:56 <_ikke_> )
2019-08-22 14:26:15 <_ikke_> Maybe some kind of solidarity
2019-08-22 14:26:22 <ncopa> :)
2019-08-22 14:32:28 <artok> filoozom: any luck with pi4?
2019-08-22 14:33:15 <filoozom> artok: Haven't quite managed to build the image to test it correctly. I fucked up my modloop, but the kernel does seem to work quite a bit better.
2019-08-22 14:33:32 <filoozom> Previously it couldn't mount the SD card, now it works without any issue.
2019-08-22 15:15:07 <artok> did you have your rpi4 kernel building on some fork of aports?
2019-08-22 15:16:43 <artok> ..answer seems to be yes
2019-08-22 15:25:38 <danieli> that's generally how the MR/PR workflow works
2019-08-22 15:42:05 <tmhoang> @_ikke_> tmhoang: type in commit message: s/folk/fork -> good eyes :D english is hard yes
2019-08-22 15:42:50 <_ikke_> :-)
2019-08-22 15:43:13 <_ikke_> I don't think a lot of people even bother reading the commit messages
2019-08-22 15:59:10 <artok> ...so yes I opened my eyes and found it
2019-08-22 17:15:54 <filoozom> It boots! https://pastebin.com/raw/KdkV3CGK
2019-08-22 17:16:12 <filoozom> Although it has its fair share of issues.
2019-08-22 17:17:13 <filoozom> "Failed to verify signature of /media/mmcblk0p1/boot/modloop-rpi!" not quite sure how to fix that, is there a special way to edit modloops?
2019-08-22 17:19:23 <filoozom> Also looks like it wasn't compiled with IPv6 support?
2019-08-22 17:21:36 <filoozom> Ah, I see https://github.com/alpinelinux/aports/blob/master/main/openrc/modloop.initd#L44
2019-08-22 17:21:55 <filoozom> So presumably it could work with danieli's key
2019-08-22 17:22:14 <danieli> excuse me?
2019-08-22 17:22:24 <danieli> right, you're using the apk i build?
2019-08-22 17:22:24 <filoozom> Never mind, I'm the one who created the modloop so my key... facepalm
2019-08-22 17:22:51 <filoozom> Yes I am, although I had to manually patch the modloop and things aren't quite how they should be yet.
2019-08-22 17:25:36 <filoozom> So I need to sign the modloop and add a key. And I suppose there's no easy way to disable that thing for now :(
2019-08-22 17:50:11 <tmhoang> filoozom: I'd just ignore that if I were you, or add your key to /etc/apk/keys/ iirc
2019-08-22 17:50:22 <filoozom> danieli: can you try a build of my 3 PRs on your RPi4 if you have some time? https://github.com/alpinelinux/aports/pulls/filoozom
2019-08-22 17:51:00 <danieli> I don't have any RPi4s set up with Alpine nor as builders
2019-08-22 17:52:15 <filoozom> Oh, no problem. Are you familiar with the mkimage.sh script? Is there a way I could build a complete RPi tarball with those 3 PRs?
2019-08-22 18:02:05 <Danct12> maxice8: curious asking, the depends line could be removed entirely?
2019-08-22 18:02:18 <Danct12> since you said that the package manager should look at the linked libs
2019-08-22 18:02:38 <maxice8> Danct12: yes
2019-08-22 18:03:15 <mps> Danct12: if the abuild can find deps during build then yes, but it can't find deps for all pkgs
2019-08-22 18:04:15 <Danct12> hmm, can't be sure if "gd" is required
2019-08-22 18:05:13 <mps> as maintainer you should check that carefully
2019-08-22 18:05:58 <artok> filoozom: what start.elf do you have?
2019-08-22 18:06:00 <mps> keep in mind alpine prefers minimal dependencies
2019-08-22 18:19:46 <filoozom> artok: The one from here: https://github.com/alpinelinux/aports/pull/10253 (start4.elf)
2019-08-22 18:26:35 <Danct12> Can maxice8 review https://github.com/alpinelinux/aports/pull/10345 again?
2019-08-22 18:26:46 <Danct12> I've made changes to the apkbuild as you requested
2019-08-22 18:27:11 <maxice8> No im driving
2019-08-22 18:27:20 <maxice8> Lots of unexpected speedbumps
2019-08-22 18:27:36 <Danct12> okay that's fine, feel free to review it later
2019-08-22 18:27:57 <Danct12> now i can finally play zelda on my tablet
2019-08-22 19:16:58 <joneskoo> https://gitlab.alpinelinux.org/alpine/aports/issues/10750#note_48921 no ip=dhcp for rpi, as there's no af_packet in kernel or module (initramfs)
2019-08-22 19:25:38 <tmhoang> Probably https://git.alpinelinux.org/aports/tree/scripts/mkimg.arm.sh#n91 needs 'network' too
2019-08-22 19:30:44 <joneskoo> If someone can build me an image I'll test
2019-08-22 19:47:56 <tmhoang> joneskoo: dirty trick. copy files listed in these 2 files into your initramfs, and repack it : https://git.alpinelinux.org/mkinitfs/tree/features.d/network.files, https://git.alpinelinux.org/mkinitfs/tree/features.d/network.modules
2019-08-22 19:48:49 <tmhoang> or if could provide qemu emulator cmdline for arm (what arm?) I can do it for you now
2019-08-22 19:51:28 <tmhoang> ah mps have nice script for aarch64 : http://arvanta.net/mps/install-aarch64-under-qemu.sh
2019-08-22 19:52:28 <tmhoang> joneskoo: is your rpi armhf or aarch64 ?
2019-08-22 19:52:41 <mps> tmhoang: little outdated, need some fixes, but not a problem for devs
2019-08-22 19:53:15 <tmhoang> somebody in here provide free/public aarch64 qemu instances iirc
2019-08-22 19:54:04 <mps> I think it was ddevault, but not sure
2019-08-22 19:55:53 <tmhoang> do you remember which channel ? I remember it was in -infra
2019-08-22 19:56:42 <mps> uhm, no, I can't
2019-08-22 20:10:34 <joneskoo> tmhoang: I have 3B+ I use now so it works with both. I run armhf now as I want it to work on zero too, but doesn't matter
2019-08-22 20:15:18 <tmhoang> lol https://git.alpinelinux.org/aports/tree/main/linux-rpi/config-changes-rpi.aarch64 is armhf
2019-08-22 20:15:57 <joneskoo> https://git.alpinelinux.org/aports/tree/main/linux-rpi/config-changes-rpi.armhf nothing there specific to arch..
2019-08-22 20:17:32 <_ikke_> maxice8: lol, I was trying to use ack as a test for CI, apparently you already upgraded it :D
2019-08-22 20:17:52 <maxice8> _ikke_: yes :D
2019-08-22 20:18:04 <_ikke_> I just look at projects at repology
2019-08-22 20:18:08 <maxice8> use something nobody wants to upgrade
2019-08-22 20:18:51 <tmhoang> rpi3 is aarch64 ? http://dl-4.alpinelinux.org/alpine/v3.10/releases/aarch64/
2019-08-22 20:19:04 <tmhoang> armhf only has rpi + rpi2 ?
2019-08-22 20:19:33 <_ikke_> maxice8: I gather you are also watching that list?
2019-08-22 20:19:36 <tmhoang> ah no my bad
2019-08-22 20:21:59 <_ikke_> maxice8: can I claim doas? :D
2019-08-22 20:22:28 <mps> yes, noticed doas on repology
2019-08-22 20:23:14 <maxice8> doas is actually updated
2019-08-22 20:23:18 <maxice8> 6.1 is from openbsd and the freebsd port
2019-08-22 20:23:30 <maxice8> 6.0 is from duncaen (very good void linux dev) and is used on linux
2019-08-22 20:23:39 <_ikke_> ah right
2019-08-22 20:23:40 <_ikke_> name colission
2019-08-22 20:23:49 <_ikke_> Weill, in this case, intentionally
2019-08-22 20:23:51 <_ikke_> but stilll
2019-08-22 20:23:52 <mps> very informed answer, thanks
2019-08-22 20:23:53 <_ikke_> still
2019-08-22 20:24:02 <_ikke_> I sometimes commit fixes to repology
2019-08-22 20:24:27 <joneskoo> tmhoang: alpine-rpi-3.10.2-armhf.tar.gz is what I use on both 3B+ and Zero W
2019-08-22 20:24:29 <duncaen> dont use the freebsd port ever
2019-08-22 20:24:52 <_ikke_> duncaen: o/
2019-08-22 20:25:28 <_ikke_> I was just looking at repology and it mentioned doas as outdated, but that's because it sees 6.1 from the de bsd's
2019-08-22 20:25:33 <duncaen> there was no "real" change since 6.0 and I'm still sitting on the persistence feature
2019-08-22 20:28:37 <_ikke_> Probably this should go to unmaintained I guess: https://github.com/dagwieers/dstat
2019-08-22 20:28:52 <_ikke_> (the APKBUILD is also unmaintained)
2019-08-22 20:29:11 <maxice8> *silently changing his upgrade PR to move to unmaintained* yeah can be
2019-08-22 20:29:27 <_ikke_> maxice8: seriously?
2019-08-22 20:29:33 <_ikke_> Were you working on dstat?
2019-08-22 20:29:49 <danieli> is it not unmaintained upstream?
2019-08-22 20:29:53 <maxice8> no kiddings
2019-08-22 20:29:58 <_ikke_> d'oh
2019-08-22 20:30:08 <_ikke_> danieli: It's archived / set to read-only
2019-08-22 20:30:12 <maxice8> https://github.com/alpinelinux/aports/pull/10146
2019-08-22 20:30:13 <danieli> yeah that's why i asked _ikke_
2019-08-22 20:30:33 <_ikke_> That's why I suggested moving it to unmaintained
2019-08-22 20:30:49 <_ikke_> maxice8: Why do I happen to pick the same packages you do
2019-08-22 20:31:21 <maxice8> It is not you, it is just that i pick a lot
2019-08-22 20:31:27 <_ikke_> :D
2019-08-22 20:33:15 <maxice8> if you feel like it maybe a lua package
2019-08-22 20:33:17 <maxice8> i don't touch lua
2019-08-22 20:33:17 <tmhoang> joneskoo: ok so editing initramfs is not enough, need to update its lib/modules too for net driver, cant do that by hand. So I can instruct you to generate your new initramfs, fair enough ? Good chance to learn this useful skill I guess
2019-08-22 20:33:38 <tmhoang> no idea now to create qemu armhf though
2019-08-22 20:33:41 <maxice8> plus i believe (didn't test) that lua packages are pretty small and fast to build
2019-08-22 20:33:55 <_ikke_> yes, they shoul be
2019-08-22 20:34:00 <_ikke_> nothing to compile / build afaik
2019-08-22 20:34:18 <tmhoang> arm devs, can I just run armhf iso using qemu ? does it boot ?
2019-08-22 20:34:51 <tmhoang> no iso, netboot images ?
2019-08-22 20:37:27 <duncaen> slicer69-doas$ ./doas -u nginx id; uid=990(nginx) gid=1000(duncan) groups=12(audio), 13(video), 101(xbuilder), 995(socklog), 1000(duncan)
2019-08-22 20:37:30 <joneskoo> tmhoang: it's not easy, it involves having a dtb compatible with qemu and the kernel compatible with both and...
2019-08-22 20:37:50 <duncaen> they still didn't fix it, at least on linux it never drops the group of the executing user
2019-08-22 20:46:15 <tmhoang> joneskoo: I boot into normal armhf just fine. dont have correct qemu networking device currently.
2019-08-22 20:49:29 <mps> btw, how do you use git.a.o, gitlab.a.o and privte fork of the gitlab.a.o of aports, I have two separate repos and always make patch from one to other when making MR's
2019-08-22 20:50:34 <mps> and rsync-ing them to remote build boxes, a lot of hassle
2019-08-22 20:52:48 <Cogitri> Why have two different repos instead of just having 3 remotes?
2019-08-22 20:54:03 <mps> that's what I'm thinking about but not sure if it will work without making mess, don't have much experience with remotes
2019-08-22 20:55:14 <Cogitri> I do it for my gitlab fork and the original repo at least
2019-08-22 20:55:40 <Cogitri> So I do `git pull upstream master --rebase` to get upstream changes and push to origin to make a PR
2019-08-22 20:55:41 <_ikke_> yes, using remotes works best for this
2019-08-22 20:55:49 <_ikke_> just give them decriptive names
2019-08-22 20:55:58 <_ikke_> and set correct upstreams
2019-08-22 20:56:21 <_ikke_> and make sure you hae push.default set to something like 'upstream'
2019-08-22 20:56:21 <mps> _ikke_: upstreams? you mean remotes?
2019-08-22 20:56:44 <_ikke_> no, more like upstreams for branches
2019-08-22 20:56:50 <_ikke_> git branch --set-upstream-to
2019-08-22 20:56:59 <_ikke_> or git push --set-upstream
2019-08-22 20:57:26 <mps> I push to gitlab by 'git push mps'
2019-08-22 20:58:52 <mps> and my 'git remote -v' is http://tpaste.us/gMqP
2019-08-22 20:58:55 <_ikke_> origin is for me git.a.o
2019-08-22 20:59:29 <_ikke_> I don't have gitlab aports (non-fork) as a remote
2019-08-22 21:00:00 <mps> and git.a.o aports 'git remote -v' is http://tpaste.us/eezz
2019-08-22 21:00:22 <joneskoo> tmhoang: thanks for helping
2019-08-22 21:00:46 <_ikke_> this is mine: http://tpaste.us/kZ01
2019-08-22 21:02:15 <mps> ahm, so I can add to my git.a.o repo just my private repo from GL
2019-08-22 21:02:34 <_ikke_> yes
2019-08-22 21:02:43 <mps> thanks, will try
2019-08-22 21:03:04 <mps> hope I will not make mess to git.a.o
2019-08-22 21:03:32 <_ikke_> I typically use git push to push the current branch
2019-08-22 21:03:51 <_ikke_> that means if no upstream for that branch has been set (ie, a new branch I just created), it will fail
2019-08-22 21:04:21 <mps> but we cannot push branch to git.a.o, iiuc
2019-08-22 21:04:25 <_ikke_> No
2019-08-22 21:04:35 <_ikke_> except for master / 3.x-stable
2019-08-22 21:04:51 <mps> yes
2019-08-22 21:05:15 <_ikke_> so if I use git push on a topic branch, it will fail
2019-08-22 21:05:18 <mps> we can push branches to our private repos on GL
2019-08-22 21:05:33 <_ikke_> if I want to push it to my fork, I do: git push -u gitlab HEAD
2019-08-22 21:06:08 <_ikke_> I never do git push origin
2019-08-22 21:07:00 <mps> how then you push to git.a.o
2019-08-22 21:07:25 <_ikke_> `git push` while master is checked out
2019-08-22 21:07:42 <mps> aha, so do I for now
2019-08-22 21:08:30 <_ikke_> only master (and the stable branches) have the upstream set to origin/<branchname>
2019-08-22 21:08:41 <_ikke_> so they are the only ones that I can push to origin this way
2019-08-22 21:09:40 <mps> ok, thanks, this is enough for me for now, will play to see if I can do something
2019-08-22 21:31:12 <mps> _ikke_: it works for now, thanks again
2019-08-22 21:31:20 <_ikke_> mps: np
2019-08-22 23:58:38 <ddevault> tmhoang: yes, I provide public aarch64 alpine shells to sourcehut users
2019-08-22 23:59:05 <ddevault> err, no, I provide x86_64 alpine shells or aarch64 debian shells
2019-08-22 23:59:16 <ddevault> alpine still on the todo list
2019-08-22 23:59:20 <tmhoang> +1
2019-08-23 05:14:35 <joneskoo> yay, thanks to tmhoang help, I now have a working image that boots fully headless on Raspberry Pi.
2019-08-23 05:14:53 <joneskoo> https://gitlab.alpinelinux.org/alpine/aports/issues/10750#note_48939
2019-08-23 08:13:45 <tmhoang> +1
2019-08-23 09:40:23 <mps> on ncurses ML was report about some bug, so be careful with latest upgrade
2019-08-23 10:26:40 <mort___> morning! quick question -- where should patches currently be sent? (I see three options -- mailing list, github, gitlab -- all apparently being used :)
2019-08-23 10:28:05 <_ikke_> Yes, at the moment all destinations are acceptable
2019-08-23 10:28:54 <ncopa> mort___: personally i think github is most convenient
2019-08-23 10:29:02 <ncopa> at the moment
2019-08-23 10:29:07 <ncopa> because we have CI there
2019-08-23 10:29:34 <ncopa> but I'd like to move to gitlab as soon CI is put in production there
2019-08-23 10:30:44 <clandmeter> _ikke_: do we have a general ticket to follow CI status?
2019-08-23 10:30:49 <clandmeter> sorry if you told me before
2019-08-23 10:30:49 <_ikke_> yes
2019-08-23 10:30:57 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10637
2019-08-23 10:31:39 <mort___> ta!
2019-08-23 10:31:44 <clandmeter> So it actually works now?
2019-08-23 10:32:06 <_ikke_> What works?
2019-08-23 10:32:36 <clandmeter> x86 CI on aports?
2019-08-23 10:32:56 <_ikke_> It's not enabled yet, but after I fix the last issue, it should work
2019-08-23 10:33:06 <_ikke_> (bug not related to x86)
2019-08-23 10:33:59 <clandmeter> so when its enabled we can ask some people to start adding MR's
2019-08-23 10:34:09 <_ikke_> yes
2019-08-23 10:34:15 <clandmeter> maybe just a few to limit issues
2019-08-23 10:34:18 <_ikke_> https://gitlab.alpinelinux.org/kdaudt/aports/pipelines/194
2019-08-23 10:34:31 <ncopa> how do we merge the MRs?
2019-08-23 10:34:39 <ncopa> the MRs are not autoclosed
2019-08-23 10:34:43 <_ikke_> Currently still by applying patches to git.a.o
2019-08-23 10:34:50 <_ikke_> No, I close them manually
2019-08-23 10:35:07 <clandmeter> they dont close automatically?
2019-08-23 10:35:12 <ncopa> not yet
2019-08-23 10:35:16 <clandmeter> why not?
2019-08-23 10:35:22 <clandmeter> it has no logic?
2019-08-23 10:35:25 <_ikke_> Nope
2019-08-23 10:35:35 <_ikke_> and you cannot close MRs with commit messages either
2019-08-23 10:35:37 <_ikke_> (yet)
2019-08-23 10:35:38 <clandmeter> can we use tags?
2019-08-23 10:35:42 <ncopa> i guess because we dont have bot to do it for us and we dont berge via gitlab
2019-08-23 10:36:05 <clandmeter> i havent looked into it, but what i like with commit msg is that we c an always trace it back
2019-08-23 10:36:40 <_ikke_> Closes !<nr> does not work
2019-08-23 10:37:00 <nmeum> does Fixes !<nr> work?
2019-08-23 10:37:03 <_ikke_> https://gitlab.com/gitlab-org/gitlab-ce/issues/13268
2019-08-23 10:37:05 <_ikke_> No
2019-08-23 10:37:14 <ncopa> commit message means you need to create the MR to get an MR id, and then modify the commit message
2019-08-23 10:37:45 <clandmeter> yes but we have tools for that
2019-08-23 10:37:46 <ncopa> I'd rather merge it via gitlab or have a bot to close it for us
2019-08-23 10:37:51 <clandmeter> it can be automated kind of
2019-08-23 10:37:55 <_ikke_> ncopa: I append 'Closes #<x>' to the commit message when applying them
2019-08-23 10:38:13 <ncopa> ok
2019-08-23 10:38:13 <_ikke_> merging via gitlab requires gitlab to be the cannonical source
2019-08-23 10:38:31 <ncopa> i think there is where we want to go
2019-08-23 10:38:33 <_ikke_> (and we haven't solved restricting push / merge access to main yet)
2019-08-23 10:38:36 <ncopa> in the long term
2019-08-23 10:38:56 <ncopa> so we need port github algitbot for now?
2019-08-23 10:39:07 <ncopa> github algitbot is buggy too
2019-08-23 10:39:12 <_ikke_> yes
2019-08-23 10:39:25 <clandmeter> you mean merge via webif?
2019-08-23 10:39:27 <nmeum> would be an oppertunity to fix this bugs then :)
2019-08-23 10:39:33 <ncopa> but i kind of like that approach
2019-08-23 10:39:40 <nmeum> https://github.com/jirutka/github-pr-closer
2019-08-23 10:39:46 <_ikke_> algitbot consistently never closes any PRs from J0WI
2019-08-23 10:39:50 <nmeum> that's the source github algibot uses iirc
2019-08-23 10:39:55 <_ikke_> correct
2019-08-23 10:39:59 <ncopa> clandmeter: yes it would be nice to merge (fast-forward) via webif
2019-08-23 10:40:37 <clandmeter> right, but i think we have some local tools that you can provide the PR number and merge it locally
2019-08-23 10:40:58 <clandmeter> and then you can also automate to append the commit msg.
2019-08-23 10:41:07 <clandmeter> which would link the commit to the MR
2019-08-23 10:41:20 <ncopa> yeah. we only need to port/rewrite github-pr-closer (and fix the bugs)
2019-08-23 10:41:27 <_ikke_> I have such a script
2019-08-23 10:41:34 <clandmeter> that doesnt solve it
2019-08-23 10:41:43 <clandmeter> the pr closer doesnt not add the MR/PR to the commit msg
2019-08-23 10:41:46 <_ikke_> git mr <nr> and I get the commits from the MR applied locally
2019-08-23 10:42:06 <_ikke_> and with a git hook I append the mr number
2019-08-23 10:42:18 <clandmeter> its nice if you go to git.a.o or local git repo you can see to which MR the commit belongs to.
2019-08-23 10:43:21 <clandmeter> _ikke_: i guess if you merge from webif, you also dont get any relation between MR and commit?
2019-08-23 10:43:37 <_ikke_> clandmeter: The default merge message contains a reference
2019-08-23 10:43:45 <_ikke_> but if you fast-forward, that does not work
2019-08-23 10:44:04 <clandmeter> ok the merge msg, but thats not the actual commit
2019-08-23 10:44:15 <_ikke_> right
2019-08-23 10:44:23 <_ikke_> You can only get that by rewriting the commit messages
2019-08-23 10:44:45 <clandmeter> cool thing is when you do git log to find a change, you can find it and find which MR has the discussion.
2019-08-23 10:45:55 <ncopa> i think git commit message should include enough info so the discussions shouldnt be needed
2019-08-23 10:46:04 <_ikke_> Yes, I agree
2019-08-23 10:46:16 <_ikke_> Well, discussion might always be needed
2019-08-23 10:46:26 <clandmeter> ncopa: thats weird
2019-08-23 10:46:29 <_ikke_> but it should contain enough context
2019-08-23 10:46:33 <clandmeter> you loose so much information
2019-08-23 10:46:46 <ncopa> yes, so i agree that it useful to be able to go to the MR from the commit
2019-08-23 10:46:51 <clandmeter> i agree most important info should be in the commit
2019-08-23 10:46:57 <clandmeter> but loosing the reference is bad practice.
2019-08-23 10:47:12 <ncopa> the commit message should include the "why"
2019-08-23 10:47:20 <ncopa> unless its ovious
2019-08-23 10:47:22 <_ikke_> Most non-trivial commits that are being pushed seem to lack any context in the commit messages
2019-08-23 10:47:25 <_ikke_> yes
2019-08-23 10:47:25 <ncopa> bovious*
2019-08-23 10:47:34 <_ikke_> ;-)
2019-08-23 10:48:02 <Danct12> i like that now everyone can enjoy their nes emulator on alpine linux :)
2019-08-23 10:48:21 <Danct12> i'll upstream snes emulator later
2019-08-23 10:48:22 <ncopa> so basically, we cannot use the webif to merge with fast-forward
2019-08-23 10:48:22 <Danct12> and also n64
2019-08-23 10:48:50 <clandmeter> why not?
2019-08-23 10:49:10 <_ikke_> Because you loose the reference
2019-08-23 10:49:13 <ncopa> because it will not automatically add the MR reference in the commit message
2019-08-23 10:49:25 <clandmeter> but the reference is not in the place you are looking at that moment?
2019-08-23 10:49:27 <ncopa> Danct12: i think i played snes on alpine years ago
2019-08-23 10:49:40 <clandmeter> or you need to view commits surrounding it.
2019-08-23 10:49:40 <ncopa> then I grew old...
2019-08-23 10:49:49 <Danct12> i wonder if the emulator still exist on alpine repo
2019-08-23 10:50:25 <ncopa> 6eccd22bb9dee1c34100d4d50e3d03e09f598058
2019-08-23 10:50:30 <ncopa> 2009
2019-08-23 10:50:38 <clandmeter> you were old back then
2019-08-23 10:50:38 <ncopa> a decade ago :)
2019-08-23 10:50:46 <clandmeter> :p
2019-08-23 10:50:48 <ncopa> i was 🚱
2019-08-23 10:51:36 <Danct12> i wonder how old is ncopa now :)
2019-08-23 10:52:00 <ncopa> about ten years older than then :)
2019-08-23 10:52:23 <ncopa> Danct12: what emulator are you working on? how can i test it?
2019-08-23 10:52:42 <Danct12> <ncopa "Danct12: what emulator are you w"> i just upstreamed fceux
2019-08-23 10:53:06 <Danct12> thats the nes/famicom emulator
2019-08-23 10:53:25 <clandmeter> why does matrix allow people to quote on irc...
2019-08-23 10:53:36 <ncopa> Danct12: cool!
2019-08-23 10:54:25 <Danct12> i kind of have plans to switch to alpine on my tablet
2019-08-23 10:55:00 <ncopa> :)
2019-08-23 10:55:23 <PureTryOut[m]> clandmeter: because the clients do not realize a bridge is being used. The bridge could format it nicer to IRC though
2019-08-23 10:56:02 <Danct12> by the way i'll upstream snes9x to alpine as well
2019-08-23 10:56:09 <PureTryOut[m]> Danct12: I packaged a snes core for libretro btw
2019-08-23 10:56:56 <PureTryOut[m]> NES core is next
2019-08-23 10:57:17 <Danct12> PureTryOut: neat, can't wait for someone to make a retro gaming station based on alpine linux :)
2019-08-23 10:58:21 <PureTryOut[m]> Libretro stuff also runs on Android and has touch controls there, which I'm going to see if I can enable on pmOS/Alpine Linux too. Then it'll be useful on tablets and phones as well
2019-08-23 11:15:58 <mps> little late to party, but yes, I would also like to see better commit messages although must be honest and say that also I don't write it always
2019-08-23 11:16:28 <ncopa> mps: i think we shoudl have a clear and nice doc on how to write commit messages
2019-08-23 11:16:36 <ncopa> official doc
2019-08-23 11:16:42 <_ikke_> +1
2019-08-23 11:16:58 <mps> absolutely agree
2019-08-23 11:17:44 <ncopa> btw, did anyone reviewed the user doc?
2019-08-23 11:17:58 <ncopa> we need to have it officially published with 3.11 release
2019-08-23 11:18:17 <ncopa> docs.alpinelinux.org
2019-08-23 11:18:30 <mps> I read it and don't have any serious objections
2019-08-23 11:19:32 <mps> have some small nitpicks but don't want again go to arguments with author
2019-08-23 11:20:01 <mps> all in all it is good for start
2019-08-23 11:53:51 <tmhoang> ncopa: alpine-docs is still place to give feedback on docs ?
2019-08-23 11:59:46 <ncopa> tmhoang: yes
2019-08-23 11:59:51 <ncopa> or pull requests
2019-08-23 12:04:45 <PureTryOut[m]> oh docs.alpinelinux.org, is that new? Is it intended to replace wiki.alpinelinux.org or be complementary?
2019-08-23 12:21:55 <tmhoang> complementary
2019-08-23 12:22:47 <PureTryOut[m]> Ah ok thanks
2019-08-23 12:26:49 <tmhoang> afaiu
2019-08-23 13:38:27 <wsinatra> Morning everyone, how's everybody doing today?
2019-08-23 14:24:35 <wsinatra> q
2019-08-23 14:31:02 <maxice8> @ncopa: working on ansible CVEs, mind if i ping you when done ?
2019-08-23 15:16:31 <mps> is it possible to delete (not just close) MR on gitlab.a.o
2019-08-23 15:16:56 <_ikke_> admins can
2019-08-23 15:17:49 <_ikke_> You perhaps can as well
2019-08-23 15:17:53 <_ikke_> try to edit the MR
2019-08-23 15:18:06 <_ikke_> There is a red delete button for me in the bottom right
2019-08-23 15:18:16 <mps> _ikke_: ok, can you fully delete https://gitlab.alpinelinux.org/alpine/aports/merge_requests/35
2019-08-23 15:18:46 <_ikke_> Do you see a delete button on the buttom right when you click on edit?
2019-08-23 15:19:02 <mps> no, just green 'save changes'
2019-08-23 15:19:11 <_ikke_> ok
2019-08-23 15:19:48 <_ikke_> commits, 2998 :)
2019-08-23 15:20:11 <_ikke_> It's gone
2019-08-23 15:20:38 <mps> 'page not found', thanks
2019-08-23 15:21:06 <mps> yes, 2998, I made a mess, sorry again
2019-08-23 15:23:37 <_ikke_> it happens
2019-08-23 15:24:31 <mps> not to me, at least often, I'm trying to be careful with my work
2019-08-23 15:24:51 <_ikke_> Me as well, still make a mess from time to time
2019-08-23 15:25:20 <mps> well, no one is perfect
2019-08-23 15:36:44 <triple> Request: update the ClamAV package. It is several months out of date. Thank you!
2019-08-23 15:37:07 <_ikke_> triple: feel free to provide a pull/merge request / patch
2019-08-23 15:37:17 <mps> triple: I'm trying to fix it, some tests fails
2019-08-23 15:37:37 <triple> mps: Excellent!
2019-08-23 15:38:12 <mps> hope will make it at this weekend
2019-08-23 16:34:57 <Danct12> hey everyone, anyone knows what is this license?
2019-08-23 16:35:01 <Danct12> https://github.com/snes9xgit/snes9x/blob/master/LICENSE
2019-08-23 16:36:08 <Danct12> According to my finding there is this
2019-08-23 16:36:14 <Danct12> > This file is licensed under the Snes9x License.
2019-08-23 16:36:37 <joneskoo> https://gitlab.alpinelinux.org/alpine/aports/issues/10750#note_48954 can I test this from some nightly build? It should work but the patch was different from what I tested.
2019-08-23 16:37:44 <Danct12> by the way, the license of the snes9x seems to be alot messed up here
2019-08-23 16:39:11 <mps> Danct12: look like non-free
2019-08-23 16:39:50 <Danct12> non-free but open source?
2019-08-23 16:39:52 <Danct12> hmm
2019-08-23 16:40:33 <mps> 'Snes9x is freeware for PERSONAL USE only.'
2019-08-23 16:41:11 <mps> so, not free
2019-08-23 16:41:53 <Danct12> hmm, i'll look into zsnes then
2019-08-23 16:42:10 <Danct12> the license of zsnes is GPL
2019-08-23 16:44:49 <danieli> looks proprietary to me
2019-08-23 16:46:08 <danieli> other distros have refused to package snes9x too
2019-08-23 16:47:38 <Danct12> right, so i guess let's forget about it then
2019-08-23 16:48:00 <Danct12> zsnes seems to be a good alternative, however it only runs on x86..
2019-08-23 16:48:18 <Danct12> i'll look into higan as it seems to be another alternative
2019-08-23 16:53:37 <Danct12> at least the good thing is we have fceux packaged, which is at least a emulator :)
2019-08-23 17:14:22 <maxice8> PureTryOut: can't mpfr3 be used for kcalc or it requires mpfr>=4
2019-08-23 17:24:48 <jwestman[m]> How does cross-compiling work with abuild? I tried `CHOST=aarch64 abuild -r` and it told me the build-base-aarch64 package is missing.
2019-08-23 17:26:41 <joneskoo> https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh
2019-08-23 17:28:46 <Cogitri> Pretty sure it doesn't work at all
2019-08-23 17:29:07 <joneskoo> I haven't used it, Internet points to it...
2019-08-23 17:31:09 <jwh> is kyle parisi on here?
2019-08-23 17:34:33 <danieli> jwestman[m]: it is not supported and is a non-trivial task
2019-08-23 17:38:28 <jwh> aww, "flag" isn't working for me on pkgs
2019-08-23 17:38:34 <PureTryOut[m]> maxice8: I honestly didn't realize mpfr3 existed.
2019-08-23 17:39:02 <PureTryOut[m]> Why is it called mpfr3 rather than just mpfr and updated to the latest version?
2019-08-23 17:39:47 <maxice8> can't be sure but my guess is parallel installations ?
2019-08-23 17:40:04 <maxice8> i believe you can install mpfr.so.3 and mpfr.so.4 side-by-side
2019-08-23 17:40:22 <maxice8> Void Linux does that for a few packages like libhunspell1.7
2019-08-23 17:40:55 <PureTryOut[m]> Hmm ok. I'll check if kcalc builds with 3 though
2019-08-23 17:43:23 <clandmeter> jwh, you can only flash edge
2019-08-23 17:43:35 <clandmeter> Flag even
2019-08-23 17:44:04 <PureTryOut[m]> maxice8: yeah that works. I'll send a new patch
2019-08-23 17:44:52 <maxice8> nice
2019-08-23 17:46:38 <PureTryOut[m]> I've send a new patch, ignore the other 2 https://lists.alpinelinux.org/~alpine/aports/patches/2943
2019-08-23 17:48:19 <maxice8> seems to fail to apply for me
2019-08-23 17:48:22 <jwh> clandmeter: oh
2019-08-23 17:48:34 <jwh> wait, I am on an edge one
2019-08-23 17:48:51 <PureTryOut[m]> maxice8: my patch? Huh, where?
2019-08-23 17:49:21 <jwh> https://pkgs.alpinelinux.org/package/edge/community/x86_64/zerotier-one - flag just has href=#, guessing whatever js is supposed to fire isn't
2019-08-23 17:50:02 <_ikke_> It is already flagged
2019-08-23 17:50:05 <jwh> oh
2019-08-23 17:50:10 <jwh> I see
2019-08-23 17:50:26 <jwh> just needs a minor bump :(
2019-08-23 17:50:37 <jwh> 1.4.0 is kinda unusable due to performance issues, fixed in 1.4.2
2019-08-23 17:50:47 <_ikke_> 1.4.2 is the latestA
2019-08-23 17:50:50 <_ikke_> ?
2019-08-23 17:51:04 <jwh> ye
2019-08-23 17:54:08 <jwh> new multipathing in 1.4 is awesome, but he misjudged how cpu heavy it was :D
2019-08-23 17:54:14 <maxice8> PureTryOut: on ~patches
2019-08-23 17:54:46 <_ikke_> jwh: building it locally now
2019-08-23 17:55:00 <jwh> thanks
2019-08-23 17:55:09 <maxice8> PureTryOut: using git am -3
2019-08-23 17:55:21 <jwh> I think I may have actually prepped a commit at some point but damned if I can find it
2019-08-23 17:55:56 <PureTryOut[m]> maxice8: uh, not sure. I can rebase my patch on the latest master if that helps
2019-08-23 17:55:59 <PureTryOut[m]> Otherwise idk what to do about it
2019-08-23 17:56:04 <_ikke_> I just did abump zerotier-one-1.4.2 ;-)
2019-08-23 17:56:15 <jwh> hehe
2019-08-23 17:56:39 <_ikke_> Waiting on CI from github
2019-08-23 17:58:40 <PureTryOut[m]> maxice8: I send a v3. If this doesn't apply then idk what to do about it
2019-08-23 17:58:50 <_ikke_> all green
2019-08-23 17:58:57 <_ikke_> pushed
2019-08-23 17:59:35 <jwh> thanks!
2019-08-23 18:01:29 <maxice8> PureTryOut: Still fails, even with the recommended commands by sourcehut curl -s https://lists.alpinelinux.org/~alpine/aports/%3C20190823175709.8681-1-bribbers%40disroot.org%3E/mbox | git am -3
2019-08-23 18:01:46 <PureTryOut[m]> What's the error though?
2019-08-23 18:03:30 <maxice8> http://ix.io/1Tag
2019-08-23 18:04:40 <PureTryOut[m]> Great, it doesn't actually say why it doesn't apply...
2019-08-23 18:05:34 <_ikke_> try git am -v
2019-08-23 18:05:42 <_ikke_> (I think it would pass that to git apply)
2019-08-23 18:14:57 <maxice8> unknown switch -v
2019-08-23 18:15:16 <_ikke_> perhaps you could manually use git apply with -v then
2019-08-23 19:25:13 <mps> triple: hmmm, clamav segfaults on lxc building machines, so it will need more time to be fixed. So my promise about finish on weekend will not 'keep water'
2019-08-23 19:25:42 <_ikke_> s/keep/hold/ :-)
2019-08-23 19:26:13 <mps> yes, my bad english ;-)
2019-08-23 19:26:37 <mps> but all you undestand, I think
2019-08-23 19:26:53 <_ikke_> Just helping you improve :)
2019-08-23 19:27:29 <mps> thanks, I appreciate your help
2019-08-23 19:27:55 <mps> by 'your' I mean all you here
2019-08-23 19:29:38 <clandmeter> thx
2019-08-23 19:48:05 <maxice8> PureTryOut: applied the kde-applications
2019-08-23 19:48:13 <PureTryOut[m]> maxice8: oh I see it worked after all?
2019-08-23 19:48:17 <PureTryOut[m]> what was the problem before then?
2019-08-23 19:48:32 <maxice8> no i just copied the raw patch to a file and did git apply then commited and use your git name-email as --author
2019-08-23 19:49:10 <PureTryOut[m]> Huh ok
2019-08-23 19:49:44 <maxice8> So yeah it worked
2019-08-23 19:51:23 <PureTryOut[m]> Still strange, but thanks!
2019-08-23 20:15:48 <maxice8> 1 test failed on armhf  for libkgapi
2019-08-23 20:16:50 <PureTryOut[m]> Not sure. Just retry for now
2019-08-23 20:21:47 <jwh> sigh, zt fixed the performance regression but its still entirely broken in a VM
2019-08-23 21:14:08 <maxice8>  PureTryOut kpgp failed on armv7
2019-08-23 21:15:10 <PureTryOut[m]> always retry it first, might be race conditions
2019-08-24 03:26:37 <paradigm> Hi!  I'm trying to understand how APKINDEX.tar.gz's checksum field works.  From what I can tell from apk's source, P: indicates the Package name, and C: indicates the Checksum.   The first two characters following C: indicate how the checksum is calculated and encoded, where the apparently now standard Q1 indicates it's a base64 encoded sha1sum.  Given this, I believe I should be able to extract a
2019-08-24 03:26:43 <paradigm> sha1sum of the apk-tools-static package from APKINDEX.tar.gz with:
2019-08-24 03:26:45 <paradigm> `tar xz -f ./APKINDEX.tar.gz - APKINDEX -O | awk '/^C:/{C=0} /^P:apk-tools-static$/{print C;exit}' | sed 's/^C:Q1//' | base64 -d | xxd -p`.  This does indeed produce what looks like a well formatted sha1sum; however, it does not match `sha1sum ./apk-tools-static-2.10.4-r2.apk`.  I'm missing something here.  Can someone point me in the right direction?
2019-08-24 03:57:50 <TBB> the checksum is not of the entire apk file, but of a subset of it
2019-08-24 03:59:33 <TBB> I may be wrong about this, I haven't worked with apk's for about 8 months now, but it could be the same checksum as in the info file inside the apk, which is the checksum of the sub tar containing all the files
2019-08-24 04:00:33 <TBB> details like these tend to fade away from active memory
2019-08-24 04:12:11 <paradigm> Ah, that would explain my difficulty.  I'll see if I can figure out what the subset is.  Many thanks!
2019-08-24 05:14:46 <[[sroracle]]> paradigm: i have actually done some research on this, i can try to get it to you tomorrow if someone else doesn't. going to bed soon though
2019-08-24 05:15:08 <paradigm> I'd be delighted to see it tomorrow.  Sleep well.
2019-08-24 05:45:10 <_ikke_> paradigm: an APK is a container inside a container
2019-08-24 05:46:09 <maxice8> _ikke_: Hey! :D
2019-08-24 05:46:18 <_ikke_> maxice8: o/
2019-08-24 05:46:31 <maxice8> I got a PR for moving libcanberra to community :D
2019-08-24 05:46:39 <_ikke_> ah
2019-08-24 05:46:52 <_ikke_> That does ring a bell
2019-08-24 05:47:04 <maxice8> https://github.com/alpinelinux/aports/pull/6936#issuecomment-481202568 yes
2019-08-24 05:50:59 <_ikke_> oh, libcanberra is still 'unmaintained'
2019-08-24 13:08:58 <hpagseddy[m]> hello, can someone tell me how can i use latest version of chromium or firefox for armv7?
2019-08-24 13:16:39 <mps> hpagseddy[m]: only option for now to try to build firefox yourself, for chromium I'm not sure it is worth to think about to try
2019-08-24 13:16:55 <hpagseddy[m]> oh :(
2019-08-24 13:17:07 <hpagseddy[m]> how hard is it to build firefox
2019-08-24 13:17:26 <hpagseddy[m]> i still remember that i wait near a day for compiling it on gentoo
2019-08-24 13:17:53 <mps> depends on build machine
2019-08-24 13:18:58 <hpagseddy[m]> is the build machine must be alpine?
2019-08-24 13:19:21 <hpagseddy[m]> or a chroot will work
2019-08-24 13:20:22 <mps> I think you can build on any linux but chroot should/must be alpine
2019-08-24 13:20:54 <hpagseddy[m]> chroot must be armv7 right?
2019-08-24 13:21:02 <mps> yes
2019-08-24 13:22:12 <hpagseddy[m]> alright thanks
2019-08-24 13:43:52 <meow> Hi, Why ndisc6 package (containing rdnssd) don't ship rc script by default? I tested gentoo script for rdnssd and it works perfectly with a little change.
2019-08-24 13:58:06 <MY_R> meow, dont ask why, just create the 'issue' or better... pull request on gitlab! :)
2019-08-24 13:59:03 <_ikke_> Asking why is not bad
2019-08-24 13:59:08 <_ikke_> there might be a good reason for it
2019-08-24 13:59:42 <MY_R> for not included rc script!? :D
2019-08-24 14:01:18 <_ikke_> Just in general
2019-08-24 14:02:18 <MY_R> :]
2019-08-24 14:14:24 <meow> I will try to create a patch :)
2019-08-24 16:09:19 <filoozom> Why don't Firefox and chromium have arm builds?
2019-08-24 16:09:37 <maxice8> Firefox depends on rust which is currently x86_64 only
2019-08-24 16:30:33 <filoozom> And chrome?
2019-08-24 16:31:27 <_ikke_> musl related bugs apparently
2019-08-24 16:31:45 <maxice8> clang++ according to arch="'
2019-08-24 16:34:13 <filoozom> Ah. So although rust isn't guaranteed to work on arm, it should still build and be somewhat compatible, right? Couldn't rust for arm be in the testing repo for example?
2019-08-24 16:34:35 <filoozom> I guess the same package can't be in different repos for different architectures
2019-08-24 16:34:46 <_ikke_> nope, it can't
2019-08-24 16:34:52 <_ikke_> Unless you call it differently
2019-08-24 16:35:58 <filoozom> That's what I figured. And then other packages obviously can't depend on it except if they have their own copy with a different name.
2019-08-24 16:36:20 <_ikke_> Are there packages that depend on browsers?
2019-08-24 16:36:31 <filoozom> I meant browsers on rust
2019-08-24 16:36:37 <_ikke_> (barring any embedded browsers)
2019-08-24 16:36:42 <_ikke_> Right
2019-08-24 16:37:05 <_ikke_> filoozom: it's not said that rust would even build on ARM
2019-08-24 16:37:32 <filoozom> Based on this: https://forge.rust-lang.org/platform-support.html it should build (at least std on musl), but might not run.
2019-08-24 16:37:49 <meow> is it possible to enable a service during installation of package? and how to acheive that?
2019-08-24 16:37:58 <filoozom> For glibc even cargo and rustc should build
2019-08-24 16:38:05 <_ikke_> meow: It's a policy to not do that
2019-08-24 16:38:25 <_ikke_> installing packages should not enable / start any services
2019-08-24 16:39:01 <_ikke_> If you want to do it for a package you host yourself, you could use a post-install script to do that
2019-08-24 16:39:16 <meow> Great. OK
2019-08-24 17:20:11 <mps> filoozom: to add 'oil on fire' I'm running firefox-esr on alpine aarch64, but with myself build rust and a some hacks and tweaks
2019-08-24 17:21:10 <mps> we have rust on armv7 but it is not yet complete
2019-08-24 17:23:44 <mps> main issue is that for rust dev musl looks like second class ecosystem
2019-08-24 17:26:58 <filoozom> Got it. I've just started learning Rust, and I've gotta say it would be interesting to have it running on ARM.
2019-08-24 17:27:11 <filoozom> Although I only really care about aarch64 and not armv6/7
2019-08-24 17:27:47 <mps> looks like it run fine on glibc based arm's
2019-08-24 17:33:15 <filoozom> Well according to the docs it should build fine. And on musl std should build too, although rustc and cargo might not.
2019-08-24 17:33:19 <filoozom> Should be interesting to try out
2019-08-24 17:33:47 <_ikke_> People have been working on it
2019-08-24 17:33:54 <_ikke_> It's not that people haven't tried
2019-08-24 17:36:16 <mps> it builds and it works but it is in the state which is not yet acceptable to official repo
2019-08-24 17:37:11 <filoozom> Yeah I get it. Maybe we should publish a rust-testing or rust-arm package for ARM in the test repo though?
2019-08-24 17:37:41 <filoozom> Although it might not be worth the trouble
2019-08-24 17:38:06 <mps> I have impression if upstream add alpine target then it will be ready, but didn't tried to ask them for this
2019-08-24 17:39:15 <mps> I mean, $arch-alpine-linux-musl target
2019-08-24 17:41:14 <mps> showstopper for me is that I lost interest in rust, looks like they don't care much about backward api/abi compatibility
2019-08-24 17:42:12 <mps> and rust is just better c++, so c++ is good enough
2019-08-24 17:42:44 <mps> actually plain c is best ;-)
2019-08-24 17:43:07 <filoozom> Haha, I'm more of a assembly guy myself
2019-08-24 17:44:16 <mps> eh, long time I didn't programmed in any assembly lang
2019-08-24 17:45:17 <filoozom> Yeah I was just kidding. I'm mostly writing JS at this point. I like C too, but why not use a safer higher language
2019-08-24 17:45:56 <mps> safety is in programmer and not in lang or tool
2019-08-24 17:46:31 <mps> in programmer mind*
2019-08-24 17:46:50 <filoozom> Not only :D
2019-08-24 17:47:25 <filoozom> If a language makes it easier to write safer code, then it should generally always be better in the end
2019-08-24 17:47:27 <_ikke_> some languages make it very easy to write bugs in though
2019-08-24 17:47:34 <meow> Rust is system programming language. But, all system calls are written in C. How, would that be safe?
2019-08-24 17:49:39 <mps> ime, there are no safe language
2019-08-24 17:50:24 <meow> I am inclined toward systems. Started Rust but got distracted due to questions like above.
2019-08-24 17:50:50 <filoozom> Well, Rust is gaining a lot of traction, so either way it would be nice to see it officially supported on ARM someday.
2019-08-24 17:51:28 <meow> +1
2019-08-24 17:51:59 <_ikke_> filoozom: you're not the only one :)
2019-08-24 17:52:00 <Cogitri> I'm working on that, just a bit sidetracked with vacation right now :)
2019-08-24 17:52:05 <_ikke_> ^^
2019-08-24 17:52:07 <filoozom> But wait, rust is actually in the community repo for armhf and armv7
2019-08-24 17:52:17 <Cogitri> Yes, but not with our triplets
2019-08-24 17:52:27 <filoozom> Triplets?
2019-08-24 17:52:27 <_ikke_> What does that mean?
2019-08-24 17:52:35 <_ikke_> I mean, what is the consequence
2019-08-24 17:52:40 <Cogitri> I got it semi working on those arches already so feel free to install it and play around with it, but it might break
2019-08-24 17:53:10 <mps> I see rust as just better c++, nothing more. and there are some usable software written in it so it is woth efforts to have it in alpine on all arch's
2019-08-24 17:53:32 <meow> mps: Ok.
2019-08-24 17:53:46 <Cogitri> ikke: Basically, we have our triplets (which we also patch to e.g. CLang) which define some capabilities (e.g. for Rust no crt-static since we want dynamic musl and static pie)
2019-08-24 17:53:52 <Cogitri> Upstream triplets don't have that
2019-08-24 17:54:04 <mps> Cogitri: quartets :-)
2019-08-24 17:54:11 <Cogitri> And I'm not quite sure if building in an abuild environment would work right now
2019-08-24 17:54:18 <Cogitri> mps: heh, right :P
2019-08-24 17:54:42 <Cogitri> But mps had a few builds working for some Rust packages IIRC
2019-08-24 17:55:10 <mps> Cogitri: yes, but with hacks
2019-08-24 17:55:21 <Cogitri> So I'll try to fix it with Rust 1.37 that I'm working on right now and if that doesn't work just use upstream triplets...errr quartets for now with our stuff patched in
2019-08-24 17:55:32 <Cogitri> Which isn't exactly clean but it'll work at least :)
2019-08-24 17:55:51 <Cogitri> And the entirety of Rust on musl isn't exactly what I'd call clean, sooooo :P
2019-08-24 17:56:14 <mps> Cogitri: true
2019-08-24 17:58:30 <filoozom> Meanwhile I'm still fighting the Raspberry Pi 4 thingy :p
2019-08-24 17:59:07 <filoozom> Still not quite sure how to build the tarball. How can I use patched packages in it for example?
2019-08-24 21:30:14 <jwh> aww
2019-08-24 21:31:31 <jwh> still can't install alpine on a v6-only machine
2019-08-24 21:32:12 <jwh> think the only bit that stops it is the mirror lookup
2019-08-24 21:32:52 <_ikke_> armv6?
2019-08-24 21:33:03 <_ikke_> oh, ipv6
2019-08-24 21:33:05 <jwh> and obviously no v6 config at all in the installer, but thats not really an issue
2019-08-24 21:33:09 <jwh> yes, ipv6
2019-08-24 21:33:37 <jwh> mirrors.a.o doesn't have a v6 address so it can't lookup a list, but other than that it should probably work ok
2019-08-24 21:34:09 <_ikke_> Yeah, it's hosted somewhere that does not give ipv6 addresses saidly
2019-08-24 21:34:53 <jwh> adding udhcpc6 like udhcpc is already done shouldn't be difficult tho?
2019-08-24 21:35:13 <_ikke_> no slaac?
2019-08-24 21:35:28 <jwh> I don't have slaac no
2019-08-24 21:36:19 <jwh> also provider networks don't (like vms etc), since they need to be able to hand out a fixed address
2019-08-24 21:37:07 <_ikke_> with ipv6 that's not strictly required
2019-08-24 21:37:33 <jwh> at home I don't have ra or slaac, dhcpv6 only
2019-08-24 21:37:53 <_ikke_> Did you disable it?]
2019-08-24 21:38:09 <jwh> ye
2019-08-24 21:38:12 <_ikke_> ok
2019-08-24 21:38:27 <_ikke_> I have not a lot of experience with dhcpv6
2019-08-24 21:38:49 <jwh> it sends ra to tell clients to not use ra, but thats it
2019-08-24 21:39:03 <_ikke_> lol
2019-08-24 21:39:06 <_ikke_> ok
2019-08-24 21:39:20 <jwh> works fine on everything except android (of course)
2019-08-24 21:39:22 <_ikke_> 'please ignore me'
2019-08-24 21:39:25 <_ikke_> nod
2019-08-24 21:39:36 <_ikke_> they seem to take a principle stance against dhcpv6
2019-08-24 21:39:40 <jwh> yeah
2019-08-24 21:39:54 <jwh> which is stupid considering they're trying to get into enterprise... and enterprise often have just dhcpv6 also
2019-08-24 21:40:01 <_ikke_> yup
2019-08-24 21:40:17 <_ikke_> Apparently there is this one engineer who is blocking it
2019-08-24 21:40:22 <jwh> yeah I saw
2019-08-24 21:40:28 <jwh> its not the first stupid thing hes said tbf
2019-08-24 21:40:58 <jwh> they'll add it eventually when it stops companies buying their devices
2019-08-24 21:41:24 <jwh> so back to this mirror list
2019-08-24 21:41:27 <_ikke_> Where I work we are running against this as well
2019-08-24 21:41:31 <_ikke_> ok
2019-08-24 21:41:35 <jwh> what about bundling the list in the iso, or fallback to dl-cdn?
2019-08-24 21:41:58 <jwh> and yeah, I bet its a nightmare heh
2019-08-24 21:42:11 <jwh> can't do proper address and config management without dhcpv6
2019-08-24 21:42:26 <_ikke_> for us it's mostly an auditing thing
2019-08-24 21:42:42 <jwh> its kinda funny, they argued against having dhcp for ipv6 for so long and tried to extend ra, then introduced slaac etc
2019-08-24 21:43:20 <jwh> so now instead of a properly thoughtout dhcp design for v6, we have 3 methods of doing bits of the same thing
2019-08-24 21:43:23 <jwh> :D
2019-08-24 21:43:24 <jwh> thought*
2019-08-24 21:43:38 <_ikke_> Well, for most situations, I do like slaac better
2019-08-24 21:44:05 <jwh> its certainly useful for most networks, but if you want to manage addressing and access its harder
2019-08-24 21:44:08 <_ikke_> We have a whole management network just based on SLAAC
2019-08-24 21:44:33 <jwh> heh
2019-08-24 21:45:14 <_ikke_> But for end-users we require dhcp(v6)
2019-08-24 21:45:27 <jwh> yeah
2019-08-24 21:46:00 <jwh> I really only do it at home for deterministic addressing and actually having working hostname -> address mapping, same as v4
2019-08-24 21:48:06 <_ikke_> I'm not sure if it's a good idea to bundle the mirror list with the iso
2019-08-24 21:48:18 <_ikke_> perhaps as fallback, but it's easy to get stale
2019-08-24 21:48:23 <jwh> yeah
2019-08-24 21:48:33 <jwh> defaulting to dl-cdn if it can't get one is probably sensible though
2019-08-24 21:48:47 <_ikke_> yeah
2019-08-24 21:49:25 <jwh> would just be nice to get the installer working on v6 only heh
2019-08-24 21:50:33 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/10237 exists already as an issue
2019-08-24 21:50:49 <jwh> oh cool
2019-08-24 21:51:18 <jwh> dhcpcd does v4 and v6 (ra, dhcpv6)
2019-08-24 21:51:21 <jwh> might even do slaac too
2019-08-24 21:51:27 <_ikke_> Maybe you can add your findings if they are not in there yet
2019-08-24 21:52:11 <jwh> but kernel will do ra by default anyway, so if the network supports addressing from that then it doesn't need any configuration (except dns)
2019-08-24 21:52:30 <_ikke_> yeah
2019-08-24 21:53:21 <jwh> depends how you wanna solve it though, personally I'd just switch to dhcpcd as it does it all in one and its pretty small
2019-08-24 22:05:49 <jwh> cool, now its printing all my chars as ^@=
2019-08-24 22:05:52 <jwh> :D
2019-08-24 22:09:56 <jwh> heh, if I ^C setup-alpine and run it again, it breaks after setting the keymap
2019-08-24 22:10:20 <jwh> (had to ^C coz it doesn't prompt for a valid mirror if it fails)
2019-08-24 22:19:16 <jwh> added my 2p to that issue anyway
2019-08-25 00:38:57 <MY_R> jwh, based on mirrors.alpinelinux.org here got little updated list of them with info about ipv6: http://ix.io/1REE
2019-08-25 04:47:14 <iggy> jwh: maybe try through a proxy? Not sure if the client would still try to connect to ipv6 only or if it just passes the name to the proxy
2019-08-25 04:47:55 <jwh> how does that help, I need the box to install to start a proxy :P
2019-08-25 05:42:31 <joneskoo> jwh: do I read you correctly: udhcpc6 is in busybox in alpine already but the setup scripts don't support it? that's basically the only thing missing if a mirror is selected outside mirrors.a.o?
2019-08-25 05:42:56 <jwh> if you use dhcpv6 for DNS etc then it should be enough
2019-08-25 05:43:15 <jwh> but the kernel will do RA for addressing by default anyway once the interface is up
2019-08-25 05:43:46 <joneskoo> I thought you said you need DHCPv6 also for IP in some environments?
2019-08-25 05:44:01 <jwh> yes, I'm not sure how much udhcpc6 supports though
2019-08-25 05:44:08 <jwh> it didn't work for me in the past
2019-08-25 05:44:29 <jwh> but for most networks it should be enough
2019-08-25 05:48:02 <joneskoo> https://patchwork.ozlabs.org/patch/949419/ looks like discussion to make it do address assignment (default route is not part of DHCPv6)
2019-08-25 05:48:41 <joneskoo> I guess it's a matter of udhcpc.script to make it do addresss assignment, based on that thread. I don't know if that got merged
2019-08-25 05:51:26 <jwh> hm, if its all handled in a script that might make it easier to fix without waiting for busybox to merge stuff
2019-08-25 07:09:26 <meow> What is purpose of subpackage variable in APKBUILD? I read https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#subpackages but couldn't wrap my head around.
2019-08-25 07:10:14 <Cogitri> So you have package X, which contains stuff like the package itself but also translations and docs and dev stuff (e.g. headers)
2019-08-25 07:10:44 <Cogitri> Some users may only want the package itself (read its binaries/libs) and don't care about translations or docs, while others may do
2019-08-25 07:11:12 <Cogitri> So you split the package into X, X-doc, X-lang and X-dev so you only install what you want
2019-08-25 07:12:49 <meow> So, I created a patch for ndisc6 package to include init.d script for rdnssd (a binary inside ndisc6). One of reviewer asks me to add $pkgname-openrc into subpackage.
2019-08-25 07:13:02 <_ikke_> Right
2019-08-25 07:13:16 <_ikke_> That's for future-proofing ourselves
2019-08-25 07:13:20 <_ikke_> when we want to switch init systems
2019-08-25 07:13:26 <meow> Why? because init.d script depends on OpenRC?
2019-08-25 07:13:31 <_ikke_> yes
2019-08-25 07:13:44 <meow> Great. But, it is shipped as one package or more?
2019-08-25 07:13:56 <_ikke_> What do you mean?
2019-08-25 07:14:19 <meow> mean would ndisc6 be broken into ndisc6 and ndisc6-openrc?
2019-08-25 07:14:42 <_ikke_> yes, it would
2019-08-25 07:15:00 <_ikke_> but the -openrc package will be automatically installed if you have openrc installed
2019-08-25 07:15:12 <meow> But, when someone install ndisc6 the ndisc6-openrc would be installed automatically because it is a subpackage. Am i right?
2019-08-25 07:15:20 <_ikke_> Not because it's a subpackage
2019-08-25 07:15:43 <_ikke_> But we can define logic that automatically installs packages when some other package is installed
2019-08-25 07:15:47 <mps> meow: you are Ahmed?
2019-08-25 07:15:53 <meow> Woah. Yeah
2019-08-25 07:16:02 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n1812
2019-08-25 07:16:08 <mps> I asked, and _ikke_ explained
2019-08-25 07:16:08 <meow> You are milan :)
2019-08-25 07:16:45 <_ikke_> meow: This is how we do it for all packages, and abuild will even warn about it
2019-08-25 07:17:17 <mps> alint from atools also should warn
2019-08-25 07:17:29 <meow> I still didn't get it. Would it be installed if I do apk add ndisc6
2019-08-25 07:17:33 <mps> meow: yes, I'm
2019-08-25 07:17:47 <mps> uff, I'm Milan
2019-08-25 07:18:26 <mps> meow: should be installed automatically if everything is correct
2019-08-25 07:19:37 <mps> meow: hope, I do not have to answer mail after this discussion ;-)
2019-08-25 07:19:49 <meow> mps: Yeah. :)
2019-08-25 07:22:31 <meow> mps: Another, reviewer asks me to add name= and desciption= ? What should I add there? my name? description what this script do?
2019-08-25 07:24:50 <mps> let me look again
2019-08-25 07:27:35 <mps> probably about licence for rdnssd.rc
2019-08-25 07:28:09 <mps> we prefer SPDX naming scheme for licences
2019-08-25 07:30:15 <mps> but also I have nearly same header as your in .initd in one of my pkg
2019-08-25 07:30:46 <mps> ask maxice8 when he appears here ;-)
2019-08-25 07:40:43 <meow> mps: Thanks I will :)
2019-08-25 07:42:36 <mps> one small note: initd (openrc) file should be named as pkgname (ndisc6.initd) so when someone searches or look other info about it will be less confused
2019-08-25 07:42:56 <meow> Yeah. Renamed it already :)
2019-08-25 07:43:18 <mps> nice :-)
2019-08-25 07:44:51 <meow> mps: No, I renamed at as rdnssd.initd because I am only adding the initd for rdnssd. There are other packages in ndisc6 too which may or may not have initd files as well.
2019-08-25 07:45:20 <mps> aha, ok
2019-08-25 07:45:54 <mps> what the maintainer of pkg thinks ;-)
2019-08-25 07:46:39 <meow> Don't know.
2019-08-25 07:47:12 <mps> he is here, because that I added ';-)'
2019-08-25 07:47:36 <meow> aah
2019-08-25 07:47:50 <mps> but he is busy with more important work for alpine
2019-08-25 07:48:51 <meow> mps: My patch is very little and basically copy of gentoo version. So, people doing more important work should bother themself :-)
2019-08-25 07:49:19 <meow> OohMG. ikke is maintainer :)
2019-08-25 07:49:50 <mps> meow: yes, file is good, I think
2019-08-25 07:50:39 <meow> mps: you mean by point of view of licensing and other stuff
2019-08-25 07:50:57 <mps> yes
2019-08-25 07:51:15 <meow> So, should I push v2?
2019-08-25 07:52:11 <mps> if you have push rights and tested it works without obvious problem, then yes
2019-08-25 07:53:00 <meow> Yeah. i tested it. By push mean "Create and Submit Patch". I don't have rights :)
2019-08-25 07:53:57 <mps> eh, I mean push to aports tree rights
2019-08-25 07:54:37 <meow> Yeah. I don't have it :)
2019-08-25 07:54:41 <mps> you can post patch by mail, gitlab merge request or github pull request always
2019-08-25 07:55:14 <mps> there is no limitation
2019-08-25 07:56:20 <meow> Will try to make PR on Github then. :) Thanks +1
2019-08-25 07:57:06 <mps> np, time for morning coffee for me to wake up ;-)
2019-08-25 08:16:20 <meow> mps: https://github.com/alpinelinux/aports/pull/10470
2019-08-25 08:20:16 <mps> sorry, I'm not on working machine, but from web ui,  $pkgname-openrc now looks wrong to me bacause file name yo added is not same as pkgname
2019-08-25 08:20:49 <mps> I didn't know your reason when I wrote about naming file
2019-08-25 08:21:14 <mps> we should wait for maintainer opionion about that
2019-08-25 08:21:45 <mps> but, at a glance file looks good
2019-08-25 08:23:17 <mps> and, '/var/run/rdnssd.pid' should be '/run/rdnssd.pid'
2019-08-25 08:24:50 <mps> if it isn't hardcoded in source, ofc
2019-08-25 08:26:25 <meow> ok
2019-08-25 09:22:45 <MY_R> mps, in most of packages it point to /var/run/ and not /run/ directly
2019-08-25 09:28:53 <meow> mps: I ls[ed] both /var/run and /run and rdnssd.pid exists in both
2019-08-25 09:35:09 <mps> /var/run is symlink to /run on alpine (for backward compatibility)
2019-08-25 09:35:38 <mps>  /var/fun is discourouged
2019-08-25 09:36:15 <meow> mps: So, i should put /run/rdnssd.pid ?
2019-08-25 09:37:28 <mps> yes, this is preferred. although there are some programs where /var/run is hardcoded so for these there is symlink
2019-08-25 09:37:49 <filoozom> Are there processes in place to keep packages up to date? Is there something one could do?
2019-08-25 09:38:13 <meow> mps: It mean whether we put /var/run or /run it means the samethign but /run is preffered.
2019-08-25 09:38:24 <filoozom> For example I just wrote this quick script to check for the last version of NodeJS and update the APKBUILD and open a pull request. Is that fine?
2019-08-25 09:39:15 <mps> filoozom: auto upgrade/update pkg's, especially big ones as node, is not good idea, imo
2019-08-25 09:39:59 <mps> meow: as I wrote /run is preferred
2019-08-25 09:40:06 <meow> mps: Thanks.
2019-08-25 09:40:20 <mps> you're welcome
2019-08-25 09:41:16 <filoozom> mps: only because of resource constraints?
2019-08-25 09:43:38 <mps> upgrading package can introduce incompatibilities with previous versions, new bugs or other issues
2019-08-25 09:44:23 <filoozom> Yeah, but in that case we can just stay on the same major semver release and it should be fine
2019-08-25 09:44:41 <filoozom> At least for reputable projects like NodeJS that actually respect semver
2019-08-25 09:44:56 <mps> so, it should be tested before upgrade, especilly bigger and important pkgs
2019-08-25 09:45:48 <filoozom> What would be considered sufficient testing in this case?
2019-08-25 09:47:41 <mps> there are no written rules except (my add on)  apply common sense
2019-08-25 09:48:41 <mps> test if it installs and at least basic working
2019-08-25 09:48:46 <filoozom> Because the NodeJS apkbuild for example has a tiny test in it, proving that it does execute.
2019-08-25 09:48:56 <filoozom> So if CI passes it should be fine
2019-08-25 09:50:00 <mps> if it passes CI usually it is enough, but I still prefer to test if it works, especially pkg's I maintain
2019-08-25 09:50:14 <mps> and pkg's in main and community
2019-08-25 09:50:36 <mps> although TBH, not always
2019-08-25 09:51:13 <mps> automated test are good but not panacea
2019-08-25 09:52:18 <mps> for example, we have auto test in postgresql and last night I found bug in psql on which one man just working to make fix
2019-08-25 09:53:49 <mps> but that is distro (project) decision: featurism or quality/stability
2019-08-25 10:02:51 <alpine-user1> Hello it seems building gmp 6.1.2 is failing at make check on Alpine 3.10 ?
2019-08-25 10:03:02 <alpine-user1> 7/8 tests fail for me
2019-08-25 10:05:49 <alpine-user1> x86 qemu on x86 hardware
2019-08-25 10:08:45 <alpine-user1> all segmentation fault
2019-08-25 10:11:50 <alpine-user1> it seems fine with this patch : https://git.alpinelinux.org/aports/tree/main/gmp/gmp-4.1.4-noexecstack.patch
2019-08-25 10:58:00 <meow> Can someone please fix the sed script to enable edge repos at https://wiki.alpinelinux.org/wiki/Edge . I think it is written with single digit of version in mind.
2019-08-25 11:13:32 <filoozom> Should work by adding a + after [[:digit:]], right?
2019-08-25 11:25:10 <meow> I monkey patched it for myself [[:digit:]] :')
2019-08-25 11:25:55 <meow> fileoozom: by adding another [[:digit:]] :)
2019-08-25 11:58:45 <filoozom> Is there a reason why non-free packages can't be found on https://pkgs.alpinelinux.org/packages ?
2019-08-25 12:00:10 <_ikke_> As they are non-free, they are not being built / distributed by alpine, and hence not show up there
2019-08-25 12:05:28 <filoozom> Oh, so they are in the repo but they can't be installed without abuilding the aport manually?
2019-08-25 12:05:43 <_ikke_> correct
2019-08-25 12:05:53 <filoozom> I see, good to know.
2019-08-25 12:06:59 <filoozom> _ikke_: Not sure if you read the messages from earlier, but do you have something against auto-bumping certain packages? I wrote a script that checks latests versions on GitHub then bumps the packages on aport and submits a PR.
2019-08-25 12:07:08 <filoozom> Just tested it for nodejs and nodejs-current for example
2019-08-25 12:16:41 <mps> filoozom: have you seen repology.org
2019-08-25 12:19:37 <filoozom> Can't say I have!
2019-08-25 12:21:30 <filoozom> Well, that's some very interesting data :)
2019-08-25 12:21:53 <mps> they have even API
2019-08-25 12:22:40 <_ikke_> filoozom: Probably not, but we don't want to get the list of open PRs out of hand because we cannot handle the inrush of PRs
2019-08-25 12:22:57 <_ikke_> mps: but repology is always reactive
2019-08-25 12:23:19 <_ikke_> They don't know that a new version is out until someone else has it
2019-08-25 12:23:51 <mps> and I'm against auto upgrade, f.e. I have one 'outdated' pkg which can't be upgraded without serious work and tests
2019-08-25 12:23:57 <filoozom> Yeah, I was just thinking. How could they possibly know the latest version of every package?
2019-08-25 12:24:14 <_ikke_> They just look at the latest version available in other repositories
2019-08-25 12:24:15 <filoozom> mps: Sure, but the CI would catch that.
2019-08-25 12:24:29 <_ikke_> filoozom: CI cannot catch everything
2019-08-25 12:24:31 <mps> no, some will but some will not
2019-08-25 12:24:31 <filoozom> I'm just talking about bumping patch / minor in semver packages
2019-08-25 12:24:36 <_ikke_> filoozom: especially run-time issues
2019-08-25 12:25:05 <filoozom> True, but maintainers can't catch all run-time issues either
2019-08-25 12:27:51 <_ikke_> Mass-updating packages makes that even harder though
2019-08-25 12:28:29 <filoozom> I'm not necessarily talking about mass-updating here :)  Just auto-bumping packages I use personally, which isn't a whole lot.
2019-08-25 12:28:32 <mps> this lists are only good for remind maintainers and contributors, and we have already something which works
2019-08-25 12:30:45 <mps> sometimes I receive mails that some packages are outdated, but don't know who operates this reminding system
2019-08-25 12:31:05 <_ikke_> There is an automated system
2019-08-25 12:31:11 <_ikke_> sometimes it's users who flag things
2019-08-25 14:04:09 <maxice8> mps: yes?
2019-08-25 14:07:34 <mps> maxice8: meow asked about your mail and notes about his patch to ndisc6, so I told he could ask you about your notes
2019-08-25 14:34:19 <maxice8> Ok
2019-08-25 14:35:40 <meow> maxice8: I created a PR at https://github.com/alpinelinux/aports/pull/10470
2019-08-25 14:36:19 <maxice8> I'll look after shower and band-aid change
2019-08-25 14:47:23 <meow> maxice8: oops. hope you are fine
2019-08-25 15:37:04 <maxice8> reviewd
2019-08-25 15:46:18 <minecrell> maxice8: I guess main/bluez should also have an -openrc sub-package? I saw the warning from abuild, but I was mostly looking at bluez as a base and it doesn't have one
2019-08-25 15:46:34 <maxice8> most of the time it should
2019-08-25 15:46:41 <maxice8> there are some edgecasaes but i doubt bluez is in that area
2019-08-25 16:04:10 <filoozom> maxice8: Could you have a look at my RPi PRs? https://github.com/alpinelinux/aports/pulls/filoozom
2019-08-25 16:04:51 <maxice8> no knowledge to review those PRs
2019-08-25 16:09:05 <filoozom> I see. Do you know who has?
2019-08-25 16:10:50 <maxice8> no clue i don't keep tabs on that
2019-08-25 16:44:10 <filoozom> Is the wiki down?
2019-08-25 16:48:20 <_ikke_> filoozom: looks like it
2019-08-25 16:50:25 <filoozom> I'm really sorry to ask the same question 20 times, but how can I run mkimage.sh with my local aports? I see the --repository option but I assume that it requires built packages and I can't simply use the aports dir.
2019-08-25 16:51:32 <_ikke_> yes, it does not a built repository
2019-08-25 16:52:46 <filoozom> So I need to build my 3 packages, make a repository with them and add --extra-repositories in addition to the official cdns?
2019-08-25 17:05:45 <mps> filoozom: that is the question about I opened issue but didn't got solution nor I figured it out how make image/tarball
2019-08-25 21:34:08 <clandmeter> filoozom: if you build packages abuild will generate an apkindex for you. so they are actually a repository.
2019-08-26 01:27:05 <pixelherodev> Is the maintainer of the py3-feedparser package in this channel?
2019-08-26 06:35:51 <meow> is alpinelinux.org down?
2019-08-26 06:48:11 <clandmeter> infra should be back up again
2019-08-26 06:48:37 <clandmeter> probably will need an additional reboot
2019-08-26 07:44:19 <maxice8> new atools released _ikke_
2019-08-26 07:51:27 <_ikke_> thanks
2019-08-26 07:51:33 <maxice8> And there are lots of PRs for main/
2019-08-26 07:51:36 <maxice8> include t-security
2019-08-26 07:51:47 <maxice8> s/include/including
2019-08-26 07:57:10 <ncopa> morning
2019-08-26 07:57:21 <ncopa> maxice8: thanks for helping with the sec isses
2019-08-26 07:57:37 <ncopa> im updating kernel now and will have a look at those after
2019-08-26 07:58:37 <mps> ncopa: when you updating kernel can you look at my MR's for kernel to include them
2019-08-26 07:59:01 <mps> ohm, too late, you already started
2019-08-26 08:06:19 <ncopa> mps: im looking at issues and MRs with C-kernel label
2019-08-26 08:07:27 <clandmeter> what does the C mean?
2019-08-26 08:07:35 <clandmeter> i feel affected
2019-08-26 08:07:51 <_ikke_> copied from github, I assume it stands for category
2019-08-26 08:08:00 <_ikke_> a way to group tags
2019-08-26 08:08:08 <Cogitri> clandmeter: +1 :P
2019-08-26 10:52:59 <ddevault> is "Leo" here?
2019-08-26 10:55:35 <_ikke_> yes
2019-08-26 10:55:42 <_ikke_> maxice8
2019-08-26 10:59:25 <ddevault> maxice8: I sent you an email, but your wpa_supplicant update broke things
2019-08-26 11:03:05 <Cogitri> fwiw he's sleeping right now
2019-08-26 11:04:25 <ncopa> ddevault: i pushed the commit. should I revert it?
2019-08-26 11:04:58 <ddevault> ncopa: please do
2019-08-26 11:05:16 <ncopa> this on, right? 49dc1e0c18666b85e8a1efef01b3cf5de5410f08
2019-08-26 11:05:23 <ddevault> else running updates will leave someone else frantically seeking an alternate way to establish an internet connection to fix it with
2019-08-26 11:05:31 <ddevault> yep
2019-08-26 11:07:25 <ncopa> done
2019-08-26 11:07:35 <ncopa> thanks for reporting it
2019-08-26 11:07:47 <ncopa> and sorry for the breakage
2019-08-26 11:08:07 <ddevault> no worries, thanks for the fix
2019-08-26 11:08:16 <ddevault> I knew what I was signing up for when running edge
2019-08-26 11:09:03 <ncopa> good :)
2019-08-26 11:09:14 <ncopa> it shouldnt happen too often though
2019-08-26 11:09:36 <ddevault> aye, alpine hardly ever breaks
2019-08-26 11:09:37 <ncopa> i run edge myself so i get hit early
2019-08-26 11:09:43 <ddevault> that's part of why I use it
2019-08-26 11:10:15 <ddevault> the stable releases are among the most reliable linux distros available
2019-08-26 11:10:43 <ncopa> the wpa_supplicant init.d script was a bit tricky. i spent almost a day on it to make it work with/without dbus and making it give the proper error messages
2019-08-26 11:10:50 <mps> (hmmm, few weeks I'm grumbling against supervising daemons/services by default)
2019-08-26 11:10:55 <ncopa> oh, nice to hear
2019-08-26 11:11:43 <ncopa> i have mixed feelings about the supervisor thing
2019-08-26 11:11:48 <ddevault> I could easily see wpa_supplicant being an edge case in that respect
2019-08-26 11:12:08 <Cogitri> mps: I wouldn't put that on supervising daemons being bad, but just that sometimes changes break stuff :/
2019-08-26 11:12:37 <ddevault> tbh openrc is easily the worst thing about alpine
2019-08-26 11:12:46 <mps> I'm not against supervising, I use them for decades
2019-08-26 11:12:46 <Cogitri> So much that
2019-08-26 11:12:49 <ddevault> but it's not like there's anything better
2019-08-26 11:13:03 <ddevault> every init system available today has _severe_ drawbacks
2019-08-26 11:13:05 <Cogitri> 
ACTION waits for s6-rc with a usable frontend

2019-08-26 11:13:21 <mps> but not by default. I select what I need to supervise
2019-08-26 11:13:44 <ddevault> skarnet and I have some fundamental disagreements
2019-08-26 11:13:54 <ddevault> s6 has a good heart and a disappointing execution
2019-08-26 11:14:46 <Cogitri> Yeah, it sure isn't nice to use as of now
2019-08-26 11:15:16 <ddevault> it favors correctness and completeness over being something people actually want to use
2019-08-26 11:15:24 <mps> ddevault: tend to agree with you, few times considered usage of s6 but always went back to runit
2019-08-26 11:16:41 <ddevault> runit is nice, I used it when I was trying to build my own distro
2019-08-26 11:16:46 <ddevault> but the problem with runit is dear god have you read the code
2019-08-26 11:18:37 <Cogitri> Also, no dependency management is a shame imo
2019-08-26 11:18:39 <mps> about 16-18 years ago I build router which run from RO rootfs with runit based on debian
2019-08-26 11:19:21 <Cogitri> I can't count the times people in #voidlinux wondered why NetworkManager didn't start when they forgot to enable dbus before that
2019-08-26 11:19:49 <Cogitri> I've used s6-rc for some time on Exherbo, but it sure isn't fun over a longer time
2019-08-26 11:27:20 <ncopa> i agree with ddevault on pretty much all of that, re init systems
2019-08-26 11:27:42 <ncopa> i have mixed feelings about openrc
2019-08-26 11:27:54 <ncopa> but there are not really any perfect alternatives
2019-08-26 11:28:51 <ncopa> s6 is probably the best option, but i dont think it is that much better than openrc that it make the switch worth the work
2019-08-26 11:29:00 <ncopa> i also find s6 "weird"
2019-08-26 11:29:52 <ncopa> and i think runit does things upside-down
2019-08-26 11:30:05 <ncopa> i dont like that runit polls
2019-08-26 11:31:43 <Cogitri> Yeah I don't think s6-rc is a good distro-wide init
2019-08-26 11:31:55 <Cogitri> It might work for individuals who are tinkering though
2019-08-26 11:32:54 <Cogitri> When we tried integrating s6-rc with Exherbo we had way too much trouble managing services installed by the distro (packagemanager) vs user init scripts vs init-wide config
2019-08-26 11:33:12 <Cogitri> 66 sounds interesting, but seems pretty buggy apparently
2019-08-26 11:36:20 <mps> imo, openrc is good enough for now
2019-08-26 11:36:56 <ddevault> not worth the churn to leave openrc until a more compelling alternative emerges
2019-08-26 11:37:40 <ddevault> has adding a logging function to apk ever been considered?
2019-08-26 11:38:02 <ddevault> like just writing everything it does to /var/log/apk.log, with timestamps, for understanding later what happened and when (and might have caused the problem you're looking at)
2019-08-26 11:38:17 <ncopa> yes
2019-08-26 11:38:25 <ddevault> considered and declined?
2019-08-26 11:38:38 <ncopa> i think someone even sent patches at some point
2019-08-26 11:38:45 <mps> '>>!& apk.log'
2019-08-26 11:38:52 <ncopa> not sure why it wasnt merged
2019-08-26 11:39:11 <ddevault> would you revisit those patches?
2019-08-26 11:39:13 <ddevault> assuming they're not too stale
2019-08-26 11:47:30 <ncopa> https://lists.alpinelinux.org/~alpine/devel/patches/471
2019-08-26 12:15:24 <clandmeter> <ddevault> it favors correctness and completeness over being something people actually want to use.  <- exactly this.
2019-08-26 12:15:48 <clandmeter> but i do think he wants to improve the interface, but he just doesnt have time.
2019-08-26 12:17:01 <clandmeter> ddevault: what is wrong with wpa_sup?
2019-08-26 12:17:06 <clandmeter> or was wrong
2019-08-26 12:17:20 <ddevault> did not dig further than "gah this is broken and it's keeping me from the other shit I have to do"
2019-08-26 12:17:45 <ddevault> but I will say it seemed haunted beyond the measure of what I'd expect from a simple supervisor related change
2019-08-26 12:18:21 <clandmeter> i havent looked into it, tought you may have already found the issue.
2019-08-26 12:35:57 <mps> builders are idle, nothing to build or something else?
2019-08-26 12:36:45 <_ikke_> I thing just nothing to build
2019-08-26 12:41:57 <mps> kernel 4.19.68 for 3.10 is not yet on mirrors, so I thought that is because builders didn't built it
2019-08-26 12:44:44 <_ikke_> It's not available on master either, but the builder don't seem to think it needs to be built
2019-08-26 12:45:34 <clandmeter> isnt that for master?
2019-08-26 12:46:51 <clandmeter> 67 stable 68 edge
2019-08-26 12:54:18 <ncopa> i didnt cherry-pick kernel changes to 3.10 stable yet
2019-08-26 12:54:33 <ncopa> want run it on my desktop and laptop first
2019-08-26 12:58:23 <mps> aha, ok
2019-08-26 14:10:29 <systo> So I'm starting down the path of a CS degree and am wanting to learn/help with package porting to alpine.  Any Devs here need help testing, or willing to point me down the right path to start contriuting back to the communty
2019-08-26 14:14:27 <kytart> Hi guys. I'm new to the community and I have a very tasty question. Hopefully someone can at least point me in a right direction. I'm trying to figure out how to build WPE Webkit for Alpine and I'm completely lost. I'm building it for armhf (rpi) and it's not possible to build it directly on rpi because it requires a lot of RAM. Apparently the official Alpine armhf builds are being done on a arm64 system that somehow "emulates" 32bit
2019-08-26 14:14:27 <kytart>  but I don't understand how that works. Any ideas?
2019-08-26 14:15:04 <kytart> https://trac.webkit.org/wiki/WPE
2019-08-26 14:15:55 <clandmeter> i remember seeing that question
2019-08-26 14:16:40 <clandmeter> kytart: we use aarch64 that support 32bit mode
2019-08-26 14:17:03 <clandmeter> the builds run in lxc which are 32bit containers
2019-08-26 14:18:19 <clandmeter> we run it on https://www.packet.com/cloud/servers/c2-large-arm/
2019-08-26 14:46:50 <maxice8> ddevault: I'll take a look, probably something went wrong when rebasing
2019-08-26 14:56:19 <ddevault> maxice8: thanks, cheers
2019-08-26 15:25:29 <ncopa> systo: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute
2019-08-26 15:32:43 <kytart> @clandmeter thanks I'll take a look :) if it works, I'll make a PR with wpe webkit to aports
2019-08-26 15:33:21 <systo> ncopa, cool cool.  Just started writing documentation https://wiki.alpinelinux.org/wiki/Install_Alpine_on_VMWare
2019-08-26 16:50:59 <kytart> clandmeter: on packet.com are you running it on one of the available OS or did you provide custom iPXE?
2019-08-26 17:09:35 <mps> ncopa: we talked about ncurses state few months ago, if you remember. I contacted maintainer (T. Dickey) and he explained status to me
2019-08-26 17:10:23 <mps> can forward his mail to you if you think it is useful for you
2019-08-26 17:10:31 <maxice8> _ikke_: https://gitlab.alpinelinux.org/Leo/atools/issues/22
2019-08-26 17:15:28 <_ikke_> maxice8: hmm, ok, thanks
2019-08-26 17:22:15 <_ikke_> maxice8: Right, I see why
2019-08-26 18:14:25 <clandmeter> kytart: we run alpine on it
2019-08-26 18:15:17 <clandmeter> You can use ipxe or use their rescue os which is alpine based
2019-08-26 18:16:17 <kytart> clandmeter: do you have a ready ipxe script or something to install alpine?
2019-08-26 18:29:47 <maxice8> _ikke_:  pr10404
2019-08-26 18:46:04 <_ikke_> ah yes
2019-08-26 18:55:19 <clandmeter> kytart: boot.a.o
2019-08-26 18:55:36 <clandmeter> Or netboot.xyz
2019-08-26 20:10:40 <terror_> Hi team, can we move mawk out of testing? It's been lingering their for a couple of releases and being a very mature piece of software I see no reason why it can't make it to stable
2019-08-26 20:10:56 <terror_> s/their/there
2019-08-26 20:13:32 <mps> nawk, gawk, mawk and busybox awk. why we have all these
2019-08-26 20:16:39 <mps> terror_: are you maintainer of pkg?
2019-08-26 20:16:40 <_ikke_> terror_: either let the maintainer know, or submit a patch to move it :-)
2019-08-26 23:55:50 <terror_> Oh, yes, I created the package
2019-08-26 23:56:03 <terror_> I didn't know I was allowed to move stuff around :P
2019-08-26 23:56:32 <terror_> mps: in certain scenarios mawk is significantly faster than the alternatives
2019-08-27 00:15:21 <terror_> Done: https://github.com/alpinelinux/aports/pull/10547
2019-08-27 03:50:41 <maxice8> terror_: the commit title is wrong
2019-08-27 03:50:55 <maxice8> community/mawk: move from testing
2019-08-27 05:06:06 <ddevault> I've been meaning to ask
2019-08-27 05:06:12 <ddevault> would there be any objection to adding man pages to apk based on scdoc
2019-08-27 05:06:29 <maxice8> not from me but i'm not in a position to decide that
2019-08-27 05:06:33 <maxice8> atools uses scdoc :D
2019-08-27 05:07:23 <ddevault> :)
2019-08-27 06:02:08 <ddevault> we should think about merging in the first round of py2 droppage from my tree
2019-08-27 06:02:22 <ddevault> I can rebase it and send a request-pull to the aports list, will that be sufficient?
2019-08-27 06:03:10 <ddevault> I'll do another round of removal within the next week or two, maybe polish off the rest of testing at least
2019-08-27 06:38:25 <ddevault> ncopa: https://lists.alpinelinux.org/~alpine/devel/patches/471 not sure how to boil this feedback down to something actionable
2019-08-27 06:38:45 <ddevault> ncopa: unless you want to turn this off if --root is specified and is a tempfs, but you didn't sound confident in that
2019-08-27 08:20:35 <mps> terror_: my question about awk's was 'rhetorical'. I prefer to hear reasons if I have to review and push something
2019-08-27 08:21:31 <mps> and, in time I post question I looked at pkg and seen maintainer name is similar to your nick here
2019-08-27 08:23:03 <mps> but, maxice8 already done it. so all is good now
2019-08-27 16:32:51 <Cogitri> Good news, Rust seems to work now, I'll polish the PR a bit more and we should be able to merge it in a bit then :)
2019-08-27 16:41:13 <mps> \o/
2019-08-27 16:42:37 <mps> 1.37?
2019-08-27 16:44:32 <Cogitri> Yup
2019-08-27 16:44:51 <Cogitri> It's using upstream triplets with some tweaks which isn't the nicest thing ever but works for now and I don't want to block on that anymore
2019-08-27 16:45:09 <mps> if you need test build you know who to ask ;-)
2019-08-27 16:47:39 <Cogitri> Sure :)
2019-08-27 16:47:41 <Cogitri> Thanks
2019-08-27 17:12:16 <maxice8> perl-test-simple-1.302167-r0 is returning BAD signature
2019-08-27 17:20:56 <mps> maxice8: in tests?
2019-08-27 17:21:27 <Cogitri> I guess during installation
2019-08-27 17:22:00 <maxice8> mps: https://cloud.drone.io/alpinelinux/aports/10394
2019-08-27 17:23:21 <mps> aha, I see
2019-08-27 17:25:02 <mps> just tried on stable and edge and it installs without problem
2019-08-27 17:26:19 <mps> maybe the issue is on x86 Rep
2019-08-27 17:26:25 <mps> repo*
2019-08-27 17:26:38 <maxice8> happens on my x86_64 as well
2019-08-27 17:27:07 <mps> don't have access to x86_64 edge right now
2019-08-27 17:28:18 <mps> oh, actually it is active, and yes, failed with BAD signature
2019-08-27 17:31:40 <mps> needs rebuild or reindexing archive
2019-08-27 18:05:44 <maxice8> Just realized mpv doesn't depend on mpv-libs
2019-08-27 18:30:24 <mps> interesting, and mpv doesn't need it to work
2019-08-27 18:32:55 <mps> probably mpv-libs is for third party programs to interact with mpv
2019-08-27 18:33:54 <mps> iirc, we talked here about this one year or more ago
2019-08-27 19:03:18 <Cogitri> Do we retain old packages? If so, do we have the old rust package for x86 somewhere around?
2019-08-27 19:03:30 <Cogitri> Otherwise I'll have to bootstrap the thing on x86 again
2019-08-27 19:04:14 <_ikke_> We experimented with snapshotting packages, but that ended up taking too much space
2019-08-27 19:05:49 <Cogitri> Alrighty then, will bootstrap it again then
2019-08-27 19:06:42 <mps> uhm, that reminds me of something I forgot
2019-08-27 20:58:42 <maxice8> Anyone doing work on poppler ?
2019-08-27 20:59:38 <_ikke_> This was just closed: https://github.com/alpinelinux/aports/pull/7089#issuecomment-525401371
2019-08-27 21:01:24 <maxice8> yes
2019-08-27 21:01:27 <maxice8> it is outdated
2019-08-27 21:27:40 <clandmeter> Cogitri: we do
2019-08-27 21:27:50 <clandmeter> but not for long
2019-08-27 21:28:05 <clandmeter> so it depends how long you want t o go back
2019-08-27 21:28:10 <Cogitri> Ah, I guess Rust x86 is gone already then
2019-08-27 21:28:32 <Cogitri> Well, no worries, the build for it is already in progress
2019-08-27 21:28:45 <clandmeter> from which date?
2019-08-27 21:28:51 <clandmeter> i can link you the pkg
2019-08-27 21:31:30 <Cogitri> Uhh..like a month ago?
2019-08-27 21:31:51 <Cogitri> It was disabled on July 7th
2019-08-27 21:32:26 <clandmeter> which repo was it?
2019-08-27 21:32:28 <clandmeter> testing?
2019-08-27 21:32:50 <clandmeter> http://snapshot.alpinelinux.org/20190706/edge/community/x86/rust-1.35.0-r0.apk
2019-08-27 22:36:51 <maxice8> Need someone to merge pango 1.44.5 so inkscape is fixed
2019-08-27 22:36:58 <maxice8> need to rebuild inkscape for the upcoming poppler 080 update
2019-08-28 11:29:26 <mps> can someone update signature for perl-test-simple in download archive
2019-08-28 11:35:28 <mps> changing mirror fixed it for me, but I think builders also need fix
2019-08-28 11:44:51 <clandmeter> wut?
2019-08-28 11:45:50 <mps> when using dl-cdn.alpinelinux.org I got BAD signature for perl-test-simple
2019-08-28 11:46:05 <mps> and yesterday maxice8 reportded the same problem
2019-08-28 11:46:14 <clandmeter> you can fix it
2019-08-28 11:46:39 <mps> switched to nl.alpinelinux.org and it works
2019-08-28 11:46:45 <clandmeter> curl -X PURGE url to apk
2019-08-28 11:47:01 <mps> ahm, I forgot that
2019-08-28 11:47:53 <clandmeter> age...
2019-08-28 11:49:21 <mps> have to write big note about that
2019-08-28 11:50:49 <clandmeter> that you are getting older?
2019-08-28 11:52:00 <mps> can be, after 60 times I followed earth moving aroud sun ;-)
2019-08-28 11:52:18 <mps> 60 circles
2019-08-28 12:29:10 <mps> could someone push MR 37 and 38 from gitlab.a.o? I would like to make next MR's for sec fixes on top of these two
2019-08-28 13:35:17 <ncopa> !37
2019-08-28 13:35:28 <ncopa> !38
2019-08-28 13:35:50 <clandmeter> !1234567
2019-08-28 13:36:29 <clandmeter> damnit!1
2019-08-28 13:37:50 <clandmeter> !37 !38 does that work?
2019-08-28 13:42:58 <MY_R> hope that wont work !33*
2019-08-28 13:43:06 <MY_R> ok, nice
2019-08-28 14:09:20 <mps> hmm, these '!MR' doesn't shows branch
2019-08-28 15:38:14 <mps> triple: as promised I narrowed clamav build problem with the help from Micah Snyder (clamav developer)
2019-08-28 15:38:34 <mps> hope we will have fix in a few days
2019-08-28 16:50:25 <mps> hmm, not days but hours :)
2019-08-28 16:51:59 <clandmeter> mps: ❤️
2019-08-28 16:53:28 <mps> clandmeter: thanks
2019-08-28 19:03:28 <mps> finished clamav 0.101.4 and tested builds on x86_64, aarch64 and armv7
2019-08-28 19:04:11 <mps> now wait for 'amen' from clamav developer who helped me a lot
2019-08-28 19:27:52 <atdq_> Hello, what is the most correct way to cross-platform build own packages for Alpine.
2019-08-28 19:27:52 <atdq_> I need to build package on x86 for ARM. Should I use something like aport?
2019-08-28 19:27:52 <atdq_> Thanks!
2019-08-28 19:30:02 <mps> atdq_: alpine doesn't support cross build for packages
2019-08-28 19:31:09 <mps> qemu or in some cases containers can help
2019-08-28 19:33:40 <atdq_> mps: Hello, again thanks for help! It's a pity. So I need use "some" toolchain (own "buildroot" or other distro)?
2019-08-28 19:34:53 <mps> for small packages qemu works fine
2019-08-28 19:39:30 <atdq_> Yes, I compiled a few small, now need a few big.
2019-08-28 19:42:41 <mps> there is somewhere on github musl-cross-build by Rich Felker, iirc
2019-08-28 19:43:05 <mps> though not sure how it is useful for big packages
2019-08-28 19:57:13 <Cogitri> mps: Could you test https://github.com/alpinelinux/aports/pull/10572 ? You might need to do `export RUSTFLAGS="-C target-feature=-crt-static"` in the APKBUILDs you're testing as of now, working on that and after that Rust should be good to merge.
2019-08-28 19:57:43 <mps> let me first finish clamav, just writing commit msg
2019-08-28 19:58:59 <Cogitri> Ah sure :)
2019-08-28 20:05:01 <mps> !45
2019-08-28 20:06:03 <mps> Cogitri: rsyncing git to aarch64 build box
2019-08-28 20:06:49 <Cogitri> Thank you
2019-08-28 20:07:44 <mps> would anyone look and maybe push !38 , dovecot to 3.10-stable
2019-08-28 20:11:24 <mps> Cogitri: build rust is started, now have to wait some time
2019-08-28 20:13:48 <Cogitri> Yup, although 1.37 builds significantly faster than 1.36
2019-08-28 20:37:03 <maxice8> need someone to merge pr10339
2019-08-28 20:43:35 <v> so like, does the new mailing list suite not have any kind of spam filtering/approval process?
2019-08-28 20:45:22 <clandmeter> v: it has limited spam filtering. we need to improve it.
2019-08-28 20:45:42 <v> ahh
2019-08-29 05:30:25 <maxice8> Needs someone with main access to merge pr10339
2019-08-29 05:38:11 <[[sroracle]]> maxice8: you renamed beautifulsoup but didn't change the pkgname
2019-08-29 05:38:39 <maxice8> I did
2019-08-29 05:38:44 <maxice8> https://git.alpinelinux.org/aports/commit/?id=6ec90974720214a103eccd411d1cb4b62a7514bd
2019-08-29 05:39:05 <[[sroracle]]> oh i read the first commit backwards, sorry
2019-08-29 05:39:58 <[[sroracle]]> or rather, the first commit title is backwards
2019-08-29 06:33:08 <mps> Cogitri: good morning! rust with your changes is finished.
2019-08-29 07:49:46 <AinNero> rnalrd: would you please backport the dovecot update to 3.8 and 3.9 ?
2019-08-29 07:50:39 <ncopa> AinNero: i can have a look at it
2019-08-29 07:51:19 <Cogitri> mps: Nice :)
2019-08-29 07:51:24 <ncopa> are there any sec issues fixed there?
2019-08-29 07:51:35 <AinNero> ncopa: https://www.openwall.com/lists/oss-security/2019/08/28/3
2019-08-29 07:51:48 <AinNero> this is exploitable on my reference 3.8 production machine
2019-08-29 07:54:55 <mps> yes, dovecot have sec fixes
2019-08-29 07:55:27 <mps> I thought to backport it but don't have older build boxes
2019-08-29 07:55:42 <mps> to test builds
2019-08-29 07:55:52 <mps> AinNero: nice to see you again
2019-08-29 07:56:16 <AinNero> mps: im not here because i enjoy it
2019-08-29 07:56:20 <AinNero> my ass is on fire rn
2019-08-29 07:56:42 <mps> Cogitri: it took time but build fine 'abuild -r' is enough
2019-08-29 07:56:46 <ncopa> im on it
2019-08-29 07:57:17 <AinNero> like, alternatively i could just upgrade to 3.10, but then i risk breaking the other stuff on the machines
2019-08-29 07:57:19 <mps> AinNero: enjoy ;-)
2019-08-29 07:58:24 <AinNero> there were discussions @work to use alpine netboot for setting up debian machines (because the debian installer is crap at being automated)
2019-08-29 07:58:29 <AinNero> but it never came to fruition
2019-08-29 08:00:18 <clandmeter> restarting gitlab
2019-08-29 08:01:39 <rnalrd> AinNero, ncopa I was bulding locally and then pushing
2019-08-29 08:01:46 <rnalrd> I see 3.9 it's donw
2019-08-29 08:01:54 <rnalrd> done*
2019-08-29 08:02:02 <ncopa> im pushing to 3.8 in a sec
2019-08-29 08:02:06 <rnalrd> k
2019-08-29 08:02:11 <ncopa> just testbuilding it first
2019-08-29 08:28:22 <mps> anyone would push to main !47
2019-08-29 08:29:38 <mps> tested build on x86_64, armv7 and aarch64. and it works on aarch64 from last night till now without any noticeable issue
2019-08-29 08:30:20 <mps> need it pushed to push iwd-0.20
2019-08-29 08:39:14 <mps> does the armv7/armhf builders works
2019-08-29 08:40:47 <clandmeter> work you mean?
2019-08-29 08:41:40 <AinNero> rnalrd: landed, thanks!
2019-08-29 08:41:59 <mps> don't see them in build.a.o list and some packages are not in DL repo, dovecot in this case
2019-08-29 08:42:09 <AinNero> ncopa: thanks!
2019-08-29 08:42:56 <mps> and, #alpine-commits doesn't show any upload to them
2019-08-29 08:43:42 <clandmeter> mps: are you sure this time?
2019-08-29 08:43:53 <AinNero> # apk upgrade
2019-08-29 08:43:53 <AinNero> (1/4) Upgrading dovecot (2.3.6-r0 -> 2.3.7.2-r0)
2019-08-29 08:44:15 <AinNero> so its definitely deployed to the repos
2019-08-29 08:44:28 <mps> clandmeter: well, maybe I'm blind but I don't see them
2019-08-29 08:45:01 <clandmeter> you said it yesterday and you were amusing something incorrectly :)
2019-08-29 08:46:52 <mps> hmm, I think what I said yesterday is unrelated to that what I said now
2019-08-29 08:47:41 <clandmeter> i have no time to check
2019-08-29 08:47:45 <clandmeter> so thats why im asking it.
2019-08-29 08:47:54 <mps> aha, ok
2019-08-29 08:50:32 <mps> yesterday I said that I forgot how to 'fix BAD signature' on DL mirror and that is memory issue, now I am looking on build.a.o and can't see armhf or armv7
2019-08-29 08:50:52 <mps> so this time could be vision issue :P
2019-08-29 08:51:02 <clandmeter> i remember you were also missing a pkg
2019-08-29 08:51:06 <clandmeter> a kernel
2019-08-29 08:52:06 <mps> your memory looks better than mine :-)
2019-08-29 08:52:49 <mps> I can't remember missing kernel or anything about that
2019-08-29 08:53:06 <clandmeter> i can :p
2019-08-29 08:53:19 <clandmeter> dont make me scroll up
2019-08-29 08:53:20 <mps> please tell me
2019-08-29 08:53:33 <mps> this channel?
2019-08-29 08:53:43 <clandmeter> ncopa told you that he didnt push the latest kernel to stable yet
2019-08-29 08:54:16 <mps> ok, yes
2019-08-29 08:54:31 <clandmeter> ah crap
2019-08-29 08:54:35 <clandmeter> forgot entropy
2019-08-29 08:54:40 <mps> I remember with help of the grep in my irc logs
2019-08-29 08:54:40 <clandmeter> waiting....
2019-08-29 08:55:11 <mps> no need, found it
2019-08-29 08:55:30 <clandmeter> im booting a vps without entropy....
2019-08-29 08:55:53 <mps> btw, I noticed that the haveged helps a lot on armv7 on boot
2019-08-29 08:56:04 <clandmeter> fixed it :)
2019-08-29 08:56:18 <clandmeter> its nice to install alpine on vps's that dont support it :)
2019-08-29 08:56:41 <mps> on SBC without haveged or patch I made to revert CRNG issues I have to wait more than 15-20 minutes to boot
2019-08-29 08:57:05 <clandmeter> a patch?
2019-08-29 08:57:10 <mps> with haveged delay for entropy is about 5-7 seconds
2019-08-29 08:57:18 <clandmeter> isnt it simple a kernel option you can switch?
2019-08-29 08:57:37 <mps> private patch to revert CRNG change in kernel
2019-08-29 08:58:39 <mps> CRNG go back to 4.18 version
2019-08-29 09:14:53 <MY_R> mps, shouldnt be armhf/armv7 dovecot in newer version than 2.3.7-r0?
2019-08-29 09:16:20 <mps> it should be 2.3.7.2
2019-08-29 09:16:36 <MY_R> ye I thought so too
2019-08-29 09:16:42 <MY_R> but look: https://pkgs.alpinelinux.org/packages?name=dovecot&branch=edge
2019-08-29 09:16:54 <MY_R> weird...
2019-08-29 09:17:53 <mps> armhf/armv7 builder are on vacation ;-)
2019-08-29 09:18:13 <mps> builders*
2019-08-29 09:18:36 <MY_R> or forgot sync with git :D
2019-08-29 09:32:21 <mps> looks like last upload to armv7 was at 2019-08-25 17:53
2019-08-29 09:56:36 <ncopa> I'll have a look at them
2019-08-29 11:33:34 <tmhoang> mps> can be, after 60 times I followed earth moving aroud sun ;-) : have always thought mps is a 30 something guy
2019-08-29 11:48:26 <mps> tmhoang: mps feels like he is about 20 :-)
2019-08-29 13:09:00 <clandmeter> mps: feeling and looking are two complete different things :p
2019-08-29 13:48:21 <mps> clandmeter: yes, must admit that now I look a little older than how I looked 20 years before :P
2019-08-29 13:51:43 <mps> and, you can make me small favour, i.e. review and and merge !45 , you are a maintainer at the end
2019-08-29 13:52:45 <mps> I think it should be backported to 3.10 but would like to will it pass all builders before making MR for 3.10
2019-08-29 14:55:47 <clandmeter> mps: can i get an git am patch from the mr?
2019-08-29 14:55:53 <clandmeter> i have no idea how gitlab works
2019-08-29 14:56:08 <clandmeter> interface is making no sense to me
2019-08-29 14:56:46 <clandmeter> found it
2019-08-29 14:57:41 <clandmeter> mps: you want to take ocer maintainershiop?
2019-08-29 14:59:09 <mps> clandmeter: ocer? over?
2019-08-29 14:59:25 <clandmeter> too ;late
2019-08-29 14:59:28 <clandmeter> alredy pushed
2019-08-29 14:59:39 <mps> I see, thanks
2019-08-29 14:59:42 <clandmeter> but if you want you can take over maintainership
2019-08-29 14:59:59 <clandmeter> i would have amended the patch
2019-08-29 15:00:04 <mps> only if you don't like to maintain it
2019-08-29 15:00:08 <clandmeter> this macbook keyboard is pissing me
2019-08-29 15:00:10 <clandmeter> off
2019-08-29 15:00:46 <mps> same with chromebook keyboards, I'm thinking to add external usb one
2019-08-29 15:07:59 <mps> clandmeter: btw, working with clamav main developer (Micah Snyder) was a pleasure
2019-08-29 15:08:17 <clandmeter> heh
2019-08-29 15:08:32 <clandmeter> i had to wait more than 1 year for me PR
2019-08-29 15:08:37 <clandmeter> maybe even more than 2
2019-08-29 15:09:18 <mps> don't know really, my experience is fine
2019-08-29 15:11:34 <clandmeter> its fine
2019-08-29 18:16:39 <maxice8> @ddevault ping
2019-08-29 20:45:58 <MY_R> maxice8, after "main/py-asn1-modules: upgrade to 0.2.6" I have "pkg_resources.ContextualVersionConflict: (pyasn1 0.4.5 (/usr/lib/python3.7/site-packages), Requirement.parse('pyasn1<0.5.0,>=0.4.6'), {'pyasn1-modules'})"
2019-08-29 20:46:13 <MY_R> looks like py3-asn1 need upgrade too
2019-08-29 20:46:29 <maxice8> ok i'll look on that
2019-08-29 20:46:45 <MY_R> oh, thank you :)
2019-08-29 20:48:37 <terror> Hi, does every new packet have to go to testing before moving to core? Having been bitten by busybox ping as non-root failing I thought of just building it as a standalone utility that can be suid and can be installed by apk add ping
2019-08-29 20:48:50 <maxice8> yes
2019-08-29 20:49:25 <terror> It is just busybox, nothing new or fancy or anything. Maybe just modifying the existing base build so that ping and ping6 are build as separate applets?
2019-08-29 20:50:36 <terror> @ncopa: you seem to be the maintainer of the busybox package, is that something you'd accept as a contribution?
2019-08-29 20:51:15 <terror> I see there's a patch to make ping work without root but doesn't seem to be working or is not being applied correctly
2019-08-29 20:51:22 <terror> https://git.alpinelinux.org/aports/tree/main/busybox/0006-ping-make-ping-work-without-root-privileges.patch
2019-08-29 20:52:02 <Cogitri> wfm
2019-08-29 20:55:33 <AinNero> terror: it seems to be working for me
2019-08-29 20:55:40 <terror> docker run -it --rm --user=1000 alpine ping www.google.com
2019-08-29 20:55:43 <terror> PING www.google.com (172.217.25.164): 56 data bytes
2019-08-29 20:55:45 <terror> ping: permission denied (are you root?)
2019-08-29 20:56:27 <terror> Same with edge
2019-08-29 21:01:16 <AinNero> terror: https://www.cyphar.com/blog/post/20160304-docker-broken-ping
2019-08-29 21:01:59 <AinNero> possibly related
2019-08-29 21:05:44 <MY_R> terror, maybe run docker with userns-remap
2019-08-29 21:06:58 <mps> terror: busybox-suid apk doesn't help
2019-08-29 21:39:24 <terror> AinNero: looking at it now
2019-08-29 21:39:59 <terror> I built just the ping applet, chmod +s it and it does work
2019-08-29 21:40:20 <AinNero> chmod +s would solve it if its a capabilities issue, right?
2019-08-29 21:40:26 <terror> I don't want to suid busybox itself that's why I though building ping as static independent applet was a good idea
2019-08-29 21:47:15 <terror> We can't fix this without having ping as an independent binary
2019-08-29 21:51:46 <AinNero> .. in docker
2019-08-29 21:53:52 <terror> https://pastebin.com/1aJv3siA
2019-08-29 21:54:15 <terror> AinNero: which is probably 95% of the users of Alpine if not more
2019-08-29 21:55:27 <terror> No need to chmod +s, setcap works just fine too
2019-08-29 21:56:24 <AinNero> i wonder how this works on my desktop
2019-08-29 21:56:37 <AinNero> im in the ping group, but i dont see that the ping group has any effect
2019-08-29 22:07:32 <AinNero> terror: i think i found the criteria that is differently in docher
2019-08-29 22:07:33 <AinNero> *doocker
2019-08-29 22:07:51 <AinNero> the /proc/sys/net/ipv4/ping_group_range is setup of differently
2019-08-29 22:08:16 <AinNero> in docker, its "0 1", so unprivileged icmp sockets are forbidden
2019-08-29 22:11:26 <AinNero> terror: docker run --sysctl net.ipv4.ping_group_range="999 2000" --user=1000:1000 -it --rm alpine ping 8.8.8.8
2019-08-29 22:27:44 <ddevault> maxice8: pong
2019-08-29 22:28:08 <maxice8> ddevault: I tagged you a few times on GH
2019-08-29 22:28:15 <ddevault> aye
2019-08-29 22:28:18 <ddevault> I just woke up
2019-08-29 22:28:27 <ddevault> patience is a virtue :)
2019-08-29 23:11:18 <terror> That's great AinNero, I'll see if I can upstream that change
2019-08-30 02:33:07 <meowmeow1234> Hi
2019-08-30 02:36:33 <meowmeow1234> How can I enable Python Wheels on Alpine Linux? I use pipenv with --site-packages flag but even then some packages didn't get used as the pipenv lock show different version of package then the one I installed using apk add {package} so, it compiles them from scratch which is absolutely slow. So, is there any way to use Python wheels on Alpine?
2019-08-30 05:59:35 <maxice8> s390x builder is stuck on apr-1.7.0-r0
2019-08-30 08:56:05 <maxice8> armv7 and aarch64 are stuck on rust-1.37.0-r0
2019-08-30 09:12:02 <mps> rust takes a lot of time to build
2019-08-30 09:13:05 <mps> few days ago I left it overnight to run build,
2019-08-30 11:16:15 <mps> ncopa: ping
2019-08-30 11:33:34 <mps> Cogitri: we have now rust with aarch64-unknown-linux-musl 'triplet'. good
2019-08-30 11:34:21 <mps> firefox can be built with some tweaks, I will make patch when I finish all tests
2019-08-30 11:34:56 <mps> firefox-esr, I mean, but probably also firefox in testing
2019-08-30 12:09:31 <tmhoang> it seems we have troubles hang tests on apr on s390x edge. looking...
2019-08-30 12:09:36 <tmhoang> thanks maxice8
2019-08-30 12:13:28 <tmhoang> hmm actually fine on myself. alpine 3.10 machine though. hmm
2019-08-30 13:04:11 <maxice8> can pr10653 be merged ?
2019-08-30 13:04:23 <maxice8> there is a guy emailing me about it breaking some important stuff
2019-08-30 13:18:41 <tcely> During builds or runtime?
2019-08-30 13:19:00 <maxice8> apparently builds
2019-08-30 13:19:18 <maxice8> most likely
2019-08-30 16:23:27 <Cogitri> mps: Nice, will work on getting other stuff that was previously blocked on rust to other arched
2019-08-30 16:25:19 <mps> hehe, someone already tried zola, it will not work without proper target
2019-08-30 16:25:55 <Cogitri> Hm, how does it fail?
2019-08-30 16:26:21 <mps> people *should not* blindly push changes to aports
2019-08-30 16:26:26 <Cogitri> I guess we'll need to have `export RUSTFLAGS="-C target-feature=-crt-static"` in most APKBUILDs for now :/
2019-08-30 16:28:43 <mps> yes, we should test some pkgs first to see what have to be set in some cases
2019-08-30 16:29:33 <mps> I was in this 6 months ago when I built first versions of rust for armv7 and aarch64
2019-08-30 16:29:56 <mps> without proper triplets it is not easy
2019-08-30 16:30:32 <mps> and because that I didn't pushed rust to aports at that time
2019-08-30 16:30:51 <mps> I wanted it to be Alpine clean
2019-08-30 16:31:29 <mps> my words are not to criticize you
2019-08-30 16:32:18 <mps> I think your decision to push it in this shape is ok
2019-08-30 16:32:57 <mps> I'm too conservative :-)
2019-08-30 16:33:42 <mps> sometimes we have to break things and rules to make all ecosystem better
2019-08-30 16:37:00 <mps> for firefox-esr I added 'CARCH=native' plus disable elf-hack
2019-08-30 16:37:32 <mps> will post diff if you want to see it
2019-08-30 17:38:44 <mps> first time I see this 'ERROR: Unable to open root: No such file or directory' 'abuild -r' community/firefox-esr
2019-08-30 17:43:02 <mps> 'abuild rootpkg' works. hmm, strange
2019-08-30 18:24:14 <Cogitri> <Cogitri "I guess we'll need to have `expo"> Sorry to quote, but it seems like that's actually not the case
2019-08-30 18:24:23 <Cogitri> Just compiled a few crates and those work just fine
2019-08-30 18:24:40 <Cogitri> mps: So the upstream triplets are actually the same as the Alpine ones, but with a different name
2019-08-30 18:25:02 <Cogitri> So they support static pie, no static libc and rpath stuff :)
2019-08-30 18:25:14 <Cogitri> So it's "Alpine clean" (almost) :P
2019-08-30 18:26:34 <mps> yes, they works in some cases, but if the linker need arch$-alpine-linux-musl rust stdlib it will not be found
2019-08-30 18:27:09 <Cogitri> Ah right, I guess it's problematic with mixed C/Rust packages
2019-08-30 18:27:18 <mps> I remember that rdedup is built without any change in APKBUILD, but zola failed
2019-08-30 18:27:30 <Cogitri> Just export RUST_TARGET="<upstream triplet>" and it should work
2019-08-30 18:27:42 <Cogitri> Actually, I might just add that to abuils
2019-08-30 18:27:53 <Cogitri> s/abuils/abuild/
2019-08-30 18:27:55 <mps> right, but not needed in all pkgs
2019-08-30 18:28:08 <Cogitri> But it doesn't hurt either way
2019-08-30 18:28:33 <Cogitri> And for the packages that do need it it means less repeating yourseld
2019-08-30 18:28:49 <mps> right now I'm working on firefox-esr where I had to add CARCH=native, and it builds
2019-08-30 18:29:28 <Cogitri> That works too, but I'll add RUST_TARGET to abuild, that's most certainly the cleanest way to do it
2019-08-30 18:29:30 <mps> and have a patch to change triplet
2019-08-30 18:30:41 <mps> when it finishes I will post it to you for review, if you are ready to help and check did I do all 'correctly'
2019-08-30 18:32:21 <Cogitri> Sure
2019-08-30 18:32:27 <mps> ohm, again failed with 'ERROR: Failed to open apk database: No such file or directory'
2019-08-30 18:32:46 <mps> anyone know why this happens
2019-08-30 18:34:01 <craftyguy> why does the ccache package create a symlink /usr/lib/ccache/bin/aarch64-alpine-linux-musl-cc -> /usr/bin/ccache, but no other package provides an actual compiler at aarch64-alpine-linux-musl-cc?
2019-08-30 19:16:49 <mps> would someone with main push right push !47
2019-08-30 19:17:50 <mps> I need it built on builders to push iwd 0.19, so please
2019-08-30 19:18:07 <mps> iwd 0.20, sorry
2019-08-30 21:49:07 <repu1sion> Hi
2019-08-30 21:50:01 <repu1sion> could someone please tell me how to build an .apk package for armhf (raspberry) from x86_64?
2019-08-30 21:50:21 <repu1sion> is bootstrap.sh from aports is the solution or there are better ways?
2019-08-30 21:52:16 <Cogitri> I guess you'll have to compile it via Qemu
2019-08-30 21:52:47 <repu1sion> isn't cross compile build possible? like in openwrt case for example?
2019-08-30 21:53:24 <Cogitri> Nop, Alpine doesn't have the necessary stuff in place for that to work since we use native builders for our binary packages
2019-08-30 21:53:51 <repu1sion> what 'bootstrap.sh armhf' does then?
2019-08-30 21:54:06 <repu1sion> it seems it builds compilers gcc-armhf etc
2019-08-30 21:54:19 <repu1sion> then minimal base for arm
2019-08-30 21:56:55 <repu1sion> can't we force this local cross-compiler to build also some other packets, not base ones?
2019-08-30 21:59:49 <repu1sion> or the only solution would be to install alpine on qemu and build with its arm gcc binary?
2019-08-30 22:08:30 <repu1sion> any suggestions how to start qemu to build something big on it like webkit2gtk or wpe-webkit?
2019-08-30 22:15:18 <AinNero> repu1sion: qemu-user, not the full system emulation
2019-08-30 22:15:43 <AinNero> just enabled you to run arm binaries in your x86 system
2019-08-30 22:15:46 <AinNero> *enables
2019-08-30 22:19:59 <repu1sion> so should I run gcc arm binary with qemu-user on x86 alpine?
2019-08-30 22:21:02 <repu1sion> is there maybe any guide how alpine developers setup their hosts to build armhf packages for example?
2019-08-30 22:22:42 <repu1sion> what I need is to build an .apk for raspberry
2019-08-30 22:28:35 <repu1sion> I found a guide for gentoo:  https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot
2019-08-30 22:28:45 <repu1sion> is there something like this for alpine also?
2019-08-30 22:35:58 <j8r> repu1sion : what technology you use?
2019-08-30 22:46:37 <j8r> with docker you can use https://github.com/multiarch/alpine
2019-08-30 22:47:12 <TBB> I think the way buildroot does it is quite allright, it either uses an existing toolchain or compiles its own, no need for qemu
2019-08-30 22:56:03 <repu1sion> I was actually going to ask - what alpine developers use to build .apk packages for raspberry ? ;)
2019-08-30 22:57:01 <repu1sion> you somehow release webkit2gtk.apk for armhf
2019-08-30 22:57:18 <repu1sion> so I'm asking - how did you do that? ;)
2019-08-30 22:57:42 <repu1sion> was it qemu-user or buildroot or docker or smth else?
2019-08-30 23:03:33 <mps> repu1sion: big arm boxes as builders
2019-08-30 23:06:02 <mps> personally I have two arm chromebooks with 4GB RAM, one 32bit and one 64bit
2019-08-30 23:08:18 <repu1sion> you won't build webkit with 4GB RAM
2019-08-30 23:10:02 <mps> no, I didn't tried even. but firefox-esr passed
2019-08-30 23:10:53 <repu1sion> hmm, on my x86 3.4GHz quad its like 40 mins for firefox52-esr
2019-08-30 23:11:08 <repu1sion> how much time on chromebook?
2019-08-30 23:11:35 <mps> file system on sd card is what slows it down
2019-08-30 23:12:02 <repu1sion> chromebooks don't have nand?
2019-08-30 23:12:20 <mps> emmc and mmc
2019-08-30 23:12:52 <mps> speed of cards depends on model
2019-08-30 23:13:22 <mps> on external usb ssd it is a lot faster
2019-08-30 23:17:07 <repu1sion> are you not joking about powerful arm builders? am I outdated ;) can't believe you can build on arm something ;)
2019-08-30 23:17:57 <mps> look at packet.com (our sponsor) and you will see ;-)
2019-08-30 23:18:29 <mps> some of us use even qemu
2019-08-31 08:02:19 <MY_R> anyone with edge can check mpv now?
2019-08-31 08:02:35 <maxice8> fixed
2019-08-31 08:03:15 <MY_R> maxice8, so no more: Error relocating /usr/lib/libshaderc_shared.so.1: ?
2019-08-31 08:03:31 <maxice8> yes
2019-08-31 08:03:39 <MY_R> ah, thanks
2019-08-31 08:13:21 <MY_R> maxice8, any progress with upgrade py-asn1 to 0.4.6? or should I just create 'issue'? I feel kind of bad to highlight you on IRC :P
2019-08-31 08:14:32 <maxice8> pr10680
2019-08-31 08:14:33 <maxice8> just waiting someone to merge
2019-08-31 08:15:36 <MY_R> now I feel more bad, next time I will have to remember about github :D thanks!
2019-08-31 15:15:37 <j8r> Hi mps, how are you?
2019-08-31 15:52:26 <mps> j8r: good, although somewhat tired. worked a lot previous week
2019-08-31 15:53:00 <mps> but, usually I work a lot ;-)
2019-08-31 15:53:21 <mps> on $day_job I mean
2019-08-31 15:53:52 <mps> ohm, just noticed that I disconnected from #crystal-lang
2019-08-31 15:55:32 <j8r> do you know how to cross compile this branch https://github.com/j8r/crystal/tree/arm-linux-musleabihf, in x86_64 targeting armhf?
2019-08-31 15:57:52 <mps> I doubt cross compiling it could be done
2019-08-31 15:58:22 <mps> did you asked jirutka, I think he will give better answer
2019-08-31 16:08:47 <mps> and, if upstream devs don't care of the arm32 port I'm not sure that I would play with it
2019-08-31 16:37:16 <mps> j8r: hmm, looking at latest commits maybe it could be possible
2019-08-31 16:37:40 <mps> I mean cross build
2019-08-31 17:32:25 <j8r> mps: how, what do you mean?
2019-08-31 17:36:21 <mps> there is no lib_c/c/arm-linux-musleabihf dir and files
2019-08-31 17:38:20 <mps> it compiles with target arm-linux-gnueabihf but fail in linker
2019-08-31 17:42:17 <j8r> lib_c/c?
2019-08-31 17:42:49 <j8r> there is a src/lib_c/arm-linux-musleabihf directory in my branch
2019-08-31 17:44:23 <mps> then I cloned wrong one
2019-08-31 17:47:12 <j8r> but how do you cross-compile, with aports' bootstrap.sh?
2019-08-31 17:47:38 <mps> please post me your git url so I can clone correct one
2019-08-31 17:48:08 <mps> no, bootstrap.sh is for bootstraping new arch in alpine
2019-08-31 17:48:36 <j8r> mps: that's https://github.com/j8r/crystal/tree/arm-linux-musleabihf
2019-08-31 17:49:15 <j8r> the branch to checkout is `arm-linux-musleabihf`
2019-08-31 17:49:39 <mps> I could try to install armv7 or armhf gcc and tools in aarch64 and use them to build crystal
2019-08-31 17:49:51 <mps> if that will work, ofc
2019-08-31 17:54:12 <mps> ok, I'm busy now, see you later
2019-08-31 18:05:54 <j8r> see you
2019-08-31 20:45:09 <mps> j8r: I downloaded your version, it compiles but have to find how to link it for armhf on aarch64
2019-08-31 20:46:44 <j8r> mps: from https://crystal-lang.org/reference/syntax_and_semantics/cross-compilation.html, probably `cc your_program.o -o your_program -lpcre -lrt -lm -lgc -lunwind`
2019-08-31 20:47:04 <j8r> ho sorry, got it
2019-08-31 20:47:24 <j8r> hum, don't know
2019-08-31 20:47:53 <j8r> I can have an Alpine armhf with Qemu, how did you cross-compile?
2019-08-31 20:48:05 <mps> well, we need to run armhf linker on aarch64 somehow
2019-08-31 20:49:23 <mps> here is my Makefile.local http://tpaste.us/yPml
2019-08-31 20:50:16 <mps> maybe I will try with musl-cross-buil tools
2019-08-31 20:50:42 <mps> but don't have much free time these days :(
2019-08-31 20:50:59 <j8r> not  sure to understand, I already tried that on aarch64
2019-08-31 20:51:17 <mps> and?
2019-08-31 20:51:22 <j8r> it fails, because of missing c files
2019-08-31 20:51:56 <mps> did you installed crystal static from dev.a.o
2019-08-31 20:52:38 <j8r> how is it related?
2019-08-31 20:53:12 <mps> you know, you need crystal to build crystal, iiuc
2019-08-31 20:53:28 <j8r> already exists on aarch64
2019-08-31 20:54:03 <mps> static or dynamic
2019-08-31 20:54:27 <j8r> dynamic, but why I would need static?
2019-08-31 20:55:06 <j8r> I also need to install armhf packages, right?
2019-08-31 20:56:09 <mps> oh, now it doesn't work
2019-08-31 20:56:22 <mps> nevermind
2019-08-31 20:56:36 <mps> it worked earlier but not now
2019-08-31 20:58:02 <j8r> snap :/
2019-08-31 20:58:38 <mps> missing c/sched in your branch
2019-08-31 21:01:16 <j8r> yes, that was the error
2019-08-31 21:01:27 <j8r> don't know what it is
2019-08-31 21:02:47 <j8r> strange, it is present
2019-08-31 21:02:49 <j8r> `src/lib_c/arm-linux-gnueabihf/c/sched.cr`
2019-08-31 21:03:08 <j8r> how, probably we have to compile it first with itself
2019-08-31 21:03:18 <j8r> then do the cross compilation
2019-08-31 21:03:19 <mps> arm-linux-gnueabihf? or arm-linux-musleabihf
2019-08-31 21:03:38 <j8r> sorry, my mistake
2019-08-31 21:03:42 <j8r> yes not present
2019-08-31 21:04:00 <j8r> ok, so I see what I have to do
2019-08-31 21:04:17 <j8r> it may be the same file at the end, though
2019-08-31 21:04:34 <mps> 'ln -s arm-linux-gnueabihf arm-linux-musleabihf' ?
2019-08-31 21:04:56 <j8r> I will copy it
2019-08-31 21:05:26 <j8r> at first with this errors I thought it was a C header file missing
2019-08-31 21:05:31 <mps> already did, but it says something about uncomplete threads
2019-08-31 21:06:06 <mps> LibC.pthread_mutexattr_init(pointerof(attributes))
2019-08-31 21:06:25 <mps> so you included threads
2019-08-31 21:07:25 <mps> and threads are experimental in crystal, afaik
2019-08-31 21:07:43 <mps> can we work with latest release
2019-08-31 21:10:20 <j8r> that's a toggle feature, which isn't enabled by default
2019-08-31 21:11:11 <mps> how to disable it
2019-08-31 21:12:14 <j8r> I see,got the same error
2019-08-31 21:12:50 <j8r> thanks for your time, you unblocked me :)
2019-08-31 21:13:02 <j8r> I will dig into this, push commits
2019-08-31 21:13:16 <mps> good, inform me please when you finish
2019-08-31 21:14:00 <j8r> Absolutely, I don't want to take more of your time with this
2019-08-31 21:15:24 <mps> np, if I don't want to work or don't have time I will be quiet probably ;-)
2019-08-31 23:06:24 <j8r> After adding missing bindings, finally got `/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: _main.o: error adding symbols: file in wrong format`
2019-08-31 23:06:36 <j8r> cc mps