2018-11-01 02:08:48 oh finally this issue is brought up 2018-11-01 02:08:58 i never thought to report it because i thought i could work around it maybe, but i got lazy 2018-11-01 02:25:14 the issue tracker does markdown, doesnt it 2018-11-01 02:25:29 i didnt realise this 2018-11-01 02:37:14 actually doesnt even seem to support markdown. i'm too lazy to figure that out and am fine with plaintext lol 2018-11-01 03:12:32 use util-linux mount 2018-11-01 07:58:23 anyone knows why rp-pppoe package in main is not available for 3.7 and 3.8, but is available on 3.6 and edge? 2018-11-01 07:58:45 looking at the git log, there was no change (beside http to https source url) 2018-11-01 07:59:09 I got pinged about someone that needs this on 3.8 2018-11-01 07:59:46 I can bump pkgrel on 3.8 and push it, but might be better to check why it wasn't build...maybe is not the only one 2018-11-01 08:01:21 <_ikke_> Some kind of build failure perhaps? 2018-11-01 08:01:32 <_ikke_> though that should have been noticed I guess 2018-11-01 09:16:28 fcolista: weird and no buildlog 2018-11-01 09:17:03 yes 2018-11-01 09:17:23 wondering if other packages have the same issue 2018-11-01 09:17:50 could be a bug in build script 2018-11-01 09:17:55 the pkgdesc has a ' 2018-11-01 09:24:18 yes that was what i was thinking too, but locally it builds just fine. 2018-11-01 09:24:36 btw, the builders are kind of blocked atm 2018-11-01 09:24:54 i stopped build-3-8-x86_64 to troubleshoot this 2018-11-01 09:24:57 oh, interesting 2018-11-01 09:28:06 it thinks that it is not enabled for the arch 2018-11-01 09:28:27 same with pth 2018-11-01 09:29:00 ok, pth has: options="!libc_musl" 2018-11-01 09:37:48 ah, i know why 2018-11-01 09:40:32 introduced with this: https://git.alpinelinux.org/cgit/lua-aports/commit/?id=93e1f0f41e35a7ae7a8907dd7f6b9e508dca219f 2018-11-01 09:41:19 and this: https://git.alpinelinux.org/cgit/lua-aports/commit/?id=c11f855f1eb8bac1f22bb4eb36a9e10fe35ecab5 2018-11-01 09:42:00 the pkgdesc has a backspace, and backspace is used as field delimiter when parsing the APKBUILDs 2018-11-01 09:43:37 fix is to remove the \ in pkgdesc 2018-11-01 09:43:52 <_ikke_> backslash ;) 2018-11-01 09:43:59 <_ikke_> (I was confused for a moment) 2018-11-01 09:44:04 and patch abuild to check for backslash 2018-11-01 09:44:11 yeah, sorry 2018-11-01 10:24:14 ncopa, can we backport this patch to 3.7 and 3.8? 2018-11-01 10:24:34 oh, you already did it 2018-11-01 10:24:35 :) 2018-11-01 10:24:39 thanks! 2018-11-01 13:30:35 ncopa, can you commit it? https://github.com/alpinelinux/aports/pull/5526 2018-11-01 13:53:52 andypost_: i have similar in my openssl 1.1 branch 2018-11-01 13:54:22 if you can wait a couple of days you'll get it linked to openssl 2018-11-01 13:54:35 but i can merge it if you need it sooner 2018-11-01 15:57:48 building svxlink -dev and -doc works on armhf but not on x86_64 using same APKBUILD, and on stable AL. strange 2018-11-01 15:59:05 it is ok for me, because I will use svxlink only on the armhf (and armv7 when it appears) but wanted to test it on x86_64 before posting it to aports 2018-11-01 20:31:46 : host mail.alpinelinux.org[74.117.189.116] said: 551 5.7.1 Go away! (in reply to RCPT TO command) 2018-11-01 20:31:52 why is the mailserver being rude to me? 2018-11-01 20:32:38 <_ikke_> Good question 2018-11-01 20:32:38 im trying to send from mx1.volatile.bz which should be properly configured 2018-11-01 20:33:02 <_ikke_> nangel is the list operator 2018-11-01 20:33:06 k 2018-11-01 20:34:08 i just wanted to ask why testing/keepassxc was using a git snapshot rather than the release source package on their download page. maybe someone here knows 2018-11-01 20:34:46 <_ikke_> most likely the maintainer 2018-11-01 20:34:59 i'll email them for now 2018-11-01 20:35:12 <_ikke_> opal: https://git.alpinelinux.org/cgit/aports/tree/testing/keepassxc/APKBUILD 2018-11-01 20:35:27 <_ikke_> Looks like it's using a proper release 2018-11-01 20:35:27 yeah i have the apkbuild in front of me lol 2018-11-01 20:35:40 source="$pkgname-$pkgver.tar.gz::https://github.com/keepassxreboot/$pkgname/archive/$pkgver.tar.gz" 2018-11-01 20:35:48 that isnt the proper release 2018-11-01 20:35:52 <_ikke_> it is 2018-11-01 20:35:54 source="https://github.com/keepassxreboot/keepassxc/releases/download/2.3.4/keepassxc-2.3.4-src.tar.xz" 2018-11-01 20:35:55 that is 2018-11-01 20:36:10 the former one has a warning when you open a database 2018-11-01 20:36:44 (oops forgot to add $pkgname and $pkgver in the latter link) 2018-11-01 20:37:10 anyway, the maintainer is using hotmail, which means more work for me. cool 2018-11-01 20:37:22 dunno why people still use that shit that blocks like every unknown IP out there 2018-11-01 20:37:31 gotta go through microsoft's stupid whitelist 2018-11-01 20:44:29 ...eh, guess my current dedi ip isnt suspicious. thank god 2018-11-01 20:45:00 bbl 2018-11-01 22:47:55 ncopa, freetds releasing fast so could wait but good to get more reports on usage 2018-11-02 08:17:36 ^ spam 2018-11-02 15:30:30 rnalrd: this is about the default value, right? 2018-11-02 15:30:39 *default support 2018-11-02 15:37:48 AinNero, it's about getting the driver included into initrd 2018-11-02 15:38:04 you can do that via /etc/mkinitfs manually 2018-11-02 15:38:52 works with random files, i used that for weird kernel modules and GNU/wget previously 2018-11-02 15:38:58 sorry didn't read last line, default support, yes 2018-11-02 16:32:19 rnalrd: + AinNero clarified its use in the PR 2018-11-03 21:51:07 need advice about aports. Posted APKBUILD to list and after some comments fixed it. should I post again complete APKBUILD from private git repo or just diff 2018-11-03 23:08:43 hi mps 2018-11-03 23:09:03 neofutur: hi 2018-11-03 23:09:11 ifsomeone here can check new aport pullrequests,I also need advice about https://github.com/alpinelinux/aports/pull/5510 2018-11-03 23:10:33 I send my APKBUILD files to aports.a.o mailing list 2018-11-03 23:12:17 and don't know what to do now, send just patches or complete new APKBUILd 2018-11-03 23:14:07 complete abuild is easier if you're just doing ML 2018-11-03 23:14:25 neofutur: we've been kinda swamped lately so it's not something about your abuild probably! 2018-11-03 23:14:55 neofutur: from a casual glance -- could you separate out different package additions in different commits? 2018-11-03 23:15:49 Shiz: ok, will try to git merge and post. thanks 2018-11-03 23:16:19 neofutur: this reminds me we should update the newapkbuild template, it sitll contains some bad practices 2018-11-03 23:16:33 you can delete the prepare() function from every APKBUILD, that's all handled by default now 2018-11-03 23:16:41 as well as removing empty variable assignments and || return 1's 2018-11-03 23:17:04 rest looks good to me other than did '#source="https://files.pythonhosted.org/packages/source/${_pkgname:0:1}/$_pkgname/$_pkgname-$pkgver.tar.gz"' not work? 2018-11-03 23:18:04 and the makedepends= line in twinte's APKBUILD looks a bit off 2018-11-03 23:18:16 makedepend is for compile-time dependencies, no t the instlal/run-time deps :) 2018-11-03 23:18:23 not* install* 2018-11-03 23:18:41 those go in depends= 2018-11-03 23:19:01 (and you can safely remove the py3-setuptools there, that's covered by py-setuptools) 2018-11-03 23:19:22 err actually it may not be, scratch that last remark 2018-11-03 23:34:42 Shiz: ok, i can wait :) just tell me if something is bad in the title/descripcion,if theres something I should change 2018-11-03 23:35:08 what I said just now is something you should change at least :) 2018-11-03 23:35:41 Shiz: wellI thought it would be better toput the 4 necessary deps together ,I ll need the 5 packages accepted,or its useless :( 2018-11-03 23:35:58 well that's fine, they don't need to be i nseparate PRs 2018-11-03 23:36:02 just eparate commits :) 2018-11-03 23:36:07 oi llsee this prepare thing toremove 2018-11-03 23:36:35 ah understood, 5 commits in one PR 2018-11-03 23:37:08 (00:18) <@ Shiz> makedepend is for compile-time dependencies, no t the instlal/run-time deps :) 2018-11-03 23:37:12 ok,understood 2018-11-03 23:37:22 yeah :> 2018-11-03 23:37:27 but where should I put the package dependencies ? 2018-11-03 23:37:28 (thanks for contributing by the way!) 2018-11-03 23:37:32 in depends= 2018-11-03 23:37:37 ok 2018-11-03 23:38:57 I ll prepare a new PR with 5 commits and those changes 2018-11-03 23:39:01 (00:37) <@ Shiz> (thanks for contributing by the way!) 2018-11-03 23:39:16 thanks to you for your answers and advices ! 2018-11-03 23:39:19 :) 2018-11-03 23:39:27 btw, if you force-push to the same branch you don't need to create a new PR 2018-11-03 23:39:30 the current one will just be updated 2018-11-03 23:51:31 i m not so good with git :( willbe easier tostart from zero I think 2018-11-03 23:54:53 with time i couldbe interesting in maintaining more python packages 2018-11-03 23:55:19 a friend/customer of mine accepted to use alpine and is asking me for more 2018-11-03 23:55:36 he already asks me for python3.7 2018-11-03 23:55:59 which is not yet in alpine it seems. any estimate for python 3.7 ? 2018-11-04 00:07:23 (00:17) <@ Shiz> rest looks good to me other than did '#source="https://files.pythonhosted.org/packages/source/${_pkgname:0:1}/$_pkgname/$_pkgname-$pkgver.tar.gz"' not 2018-11-04 00:07:26 work? 2018-11-04 00:07:48 iwas unsure about that, didnt use it since i didnt really understood it 2018-11-04 00:08:15 ${_plgname:0:1} tkaes the first letter of the package name 2018-11-04 00:09:14 butthe download is https://files.pythonhosted.org/packages/29/4d/801bbad5968e674c1ca047118025243a475f986a6f5b3ca36e5afece0f9f/twine-1.12.1.tar.gz 2018-11-04 00:09:27 /29/4d 2018-11-04 00:09:32 so what that url expands to is https://files.pythonhosted.org/packages/source/t/twine/twine-1.12.1.tar.gz for twine for instance 2018-11-04 00:09:45 whic his a redirect setup by PyPI to point to... your URL 2018-11-04 00:09:47 :P 2018-11-04 00:10:04 we do it this way because it makes it easier to bump package versions -- you don't need to change the source url, they get interpolated from the package name and version 2018-11-04 00:10:14 ok https://files.pythonhosted.org/packages/source/t/twine/twine-1.12.1.tar.gz exists 2018-11-04 00:10:39 ok,so https://files.pythonhosted.org/packages/source/${_pkgname:0:1}/$_pkgname/$_pkgname-$pkgver.tar.gz should work 2018-11-04 00:10:44 I llchange that too 2018-11-04 00:10:47 :) 2018-11-04 00:11:47 as for python 3.7 -- I think it will be there in alpine 3.9, set to release in... december/january 2018-11-04 00:11:54 concerning the "return 1! thing 2018-11-04 00:12:03 I just have to change 2018-11-04 00:12:03 python2 setup.py build || return 1 2018-11-04 00:12:03 python3 setup.py build || return 1 2018-11-04 00:12:05 to 2018-11-04 00:12:09 python2 setup.py build 2018-11-04 00:12:13 python3 setup.py build 2018-11-04 00:12:16 correct, yes 2018-11-04 00:12:17 nothing more ? 2018-11-04 00:12:18 ok 2018-11-04 00:12:24 APKBUILDs are now run with the shell feature of `set -e` 2018-11-04 00:12:30 which does the same thing eimplicitly 2018-11-04 00:12:36 but the newapkbuild templates haven;t been updated it seems 2018-11-04 00:14:10 yes,I took an existing APKBUILD for a python package and copied/modified 2018-11-04 00:14:35 couldbe the next contribution forme,removing those return 1 from all the pyton packages 2018-11-04 00:14:52 (01:11) <@ Shiz> as for python 3.7 -- I think it will be there in alpine 3.9, set to release in... december/january 2018-11-04 00:15:05 great ! my customerfriend will be happy ! 2018-11-04 00:15:40 ah another topic 2018-11-04 00:16:03 I ve always been a fan of grsecurity,use gentoo hardened for more than 10years 2018-11-04 00:16:23 I suppose alpine have the same problem than gentoo,no more free grsec patches 2018-11-04 00:16:52 my customer couldpossibly be interested to pay grsec, for alpine 2018-11-04 00:17:10 would that be possible ? would you be interested ? 2018-11-04 00:17:12 yes, we sadly suffer from the same consequences 2018-11-04 00:17:41 hmm, personally I would be interested but it would also depend on how we could redstribute grsec 2018-11-04 00:17:58 if we cant freely redestribiute it, we can't include it into alpine itself -- however, it could be maintained in the nonfree/ repo 2018-11-04 00:18:09 depending on policies 2018-11-04 00:18:10 I could try to negociate myself with spender, i used totalk philosphy wit him 10 years ago :) 2018-11-04 00:18:46 haha 2018-11-04 00:18:54 ok,so you could be interested, its worth the time and effort to try and negociate with spender ? 2018-11-04 00:19:00 sure :) 2018-11-04 00:19:13 ok, I ll try that 2018-11-04 00:19:43 grsecurity is a very interesting and high-quality effort, it's just such a shame it had to end that way 2018-11-04 00:20:03 we only ended up droppingour own grsec unofficla port because it wasn't viable development-resource wise to maintain it 2018-11-04 00:20:14 very sadly 2018-11-04 00:20:36 I understand that,same problem here 2018-11-04 00:25:59 also seen https://twitter.com/grsecurity/status/936422357757022209?lang=es today :( 2018-11-04 01:49:25 Shiz: done ! new PR with 5commits and fixing prepare,return 1 . . . 2018-11-04 01:49:31 \o/ 2018-11-04 01:49:32 https://github.com/alpinelinux/aports/pull/5552 2018-11-04 01:50:26 something I just noticed 2018-11-04 01:50:39 the depends= in twine/APKBUILD should probably be py-bleach and py--webencodings 2018-11-04 01:50:43 py-webencodings* 2018-11-04 01:50:46 not bleach and webencodings 2018-11-04 01:51:10 (you can fix this easily up in the current PR by editing, doing git commit --amend && git push --force 2018-11-04 01:51:15 (without opening a new one) 2018-11-04 01:52:31 ah yes, true 2018-11-04 01:52:56 i named them bleach and webencodings in the previous PR 2018-11-04 01:53:56 and py-readme_renderer too 2018-11-04 01:55:01 what depends on py-pkginfo and py-readme_renderer btw? 2018-11-04 01:55:11 I added a commit and pushed 2018-11-04 01:55:20 but how doI add the change to the PR ? 2018-11-04 01:55:32 hmm, that should happen automatically 2018-11-04 01:55:38 PRs are tracked by branch you push to 2018-11-04 01:56:01 it doesn't seem like you pushed? :p 2018-11-04 01:56:04 https://github.com/neofutur/aports 2018-11-04 01:56:07 don't see it here 2018-11-04 01:56:14 no,the change is in my for,butnot in the PR 2018-11-04 01:56:59 i don't see it in your fork either :p 2018-11-04 01:57:12 true 2018-11-04 01:58:14 better now ! https://github.com/alpinelinux/aports/pull/5552/commits/923db40b7f4a2e1b2b21c63bbc02d952b809f337 2018-11-04 01:58:29 (02:55) <@ Shiz> what depends on py-pkginfo and py-readme_renderer btw? 2018-11-04 01:58:35 good question 2018-11-04 01:59:01 ah, i see twine depends on readme_renderer 2018-11-04 01:59:08 i don't see anything that depends on py-pkginfo though 2018-11-04 01:59:10 :p 2018-11-04 01:59:51 i had no problems tobuild it and https://pypi.org/project/readme_renderer/ doesnt seem togive tat kind of info 2018-11-04 02:00:50 I just found the twine deps by trying and adding needed deps 2018-11-04 02:01:05 yeah it's no prob, i just didn't see twine's dep on readme_renderer cause I was blind 2018-11-04 02:01:06 :) 2018-11-04 02:01:10 yeah one ofthem needed pginfo 2018-11-04 02:01:20 yeah, if it does that needs to go in depends= 2018-11-04 02:01:22 :P 2018-11-04 02:01:26 ok 2018-11-04 02:01:27 of the package that depends on it 2018-11-04 02:01:34 I see no package in your PR that depends on it namely 2018-11-04 02:01:37 hence my curiosity :) 2018-11-04 02:01:57 yeah,dunno which one it was 2018-11-04 02:02:28 https://github.com/pypa/twine/blob/master/setup.py#L80 2018-11-04 02:02:32 looks like it's twine itself 2018-11-04 02:02:36 could you add that to its depends= ? 2018-11-04 02:02:46 else people are gonna be cconfused when they install py-twine and it doesn't work :P 2018-11-04 02:07:14 depends="py-tqdm py-requests-toolbelt py-requests py-readme_renderer py-six py-pygments py-future py-docutils py-bleach py-webencodings" 2018-11-04 02:07:35 oups 2018-11-04 02:07:40 yup,adding 2018-11-04 02:08:43 :) 2018-11-04 02:09:39 done https://github.com/alpinelinux/aports/pull/5552/commits/b9fb9f19d58541b9afb02919781bd131551c52b8 2018-11-04 02:10:26 (03:02) <@ Shiz> https://github.com/pypa/twine/blob/master/setup.py#L80 2018-11-04 02:10:38 how did you find that link ? 2018-11-04 02:10:55 Iplan tomae more python packages and could use that tip 2018-11-04 02:11:04 searched for twine on pypi -> https://pypi.org/project/twine/ -> 'Twine source' link 2018-11-04 02:11:12 since the pypi.org package page doestnt give that deps info 2018-11-04 02:11:15 and dependencies are always specified in either setup.py or setup.cfg for python packages 2018-11-04 02:11:17 :) 2018-11-04 02:11:23 ok 2018-11-04 02:11:57 nowadays it *should* be setup.cfg, but as with all things that *should* be... check setup.py first~ :) 2018-11-04 02:11:58 if you already have it installed 2018-11-04 02:12:05 then you can also use `pip show ` 2018-11-04 02:12:52 https://txt.shiz.me/ZTZmZWQzYj 2018-11-04 02:12:57 pip3 show twine 2018-11-04 02:13:00 like this, note the 'Requires:' line 2018-11-04 02:13:04 Requires: pkginfo, readme-renderer, requests, requests-toolbelt, setuptools, tqdm 2018-11-04 02:13:09 perfect ! 2018-11-04 02:13:50 if youneed helpformore python packages needes,ping me,here or email 2018-11-04 02:13:58 \o/ sure 2018-11-04 02:14:07 my friend/customer isusing alpine and python a bunch 2018-11-04 02:14:12 for now just adding whatever is missing and you need is more than helpful 2018-11-04 02:14:18 somore orless illget paid topackage alpine ;) 2018-11-04 02:14:18 :) 2018-11-04 02:14:21 haha 2018-11-04 02:14:25 sounds like a good job :> 2018-11-04 02:14:29 and thanks for contributing! 2018-11-04 02:14:37 my pleasure ! 2018-11-04 02:14:38 i'll review it tomori'll give it a final revew pass tomorrow and merge it 2018-11-04 02:14:42 it's past 3am here now 2018-11-04 02:14:48 "i'll give it a final revew pass tomorrow and merge it" 2018-11-04 02:14:50 is what i meant 2018-11-04 02:14:53 concerning grsec,spender already answered me but . . . that wont be easy :( 2018-11-04 02:15:11 > so its impossible for a whole distribution ? since you cant know how many 2018-11-04 02:15:14 > people would use it ? 2018-11-04 02:15:16 Wouldn't be feasible, unless they had enough money to fund all of our work. 2018-11-04 02:15:24 ( this is the tldr ) 2018-11-04 02:15:28 right 2018-11-04 02:15:41 that is what I feared, sadly 2018-11-04 02:15:58 ok,sweet dreams ! see you tomorrow 2018-11-04 02:16:15 'o 2018-11-04 02:16:17 \o * 2018-11-04 02:16:39 licensing model such as theirs doesn't work for purposes of a generally available distro, unfortunately 2018-11-04 02:17:57 my last answer was : "yes thats what I feared :( I hoped you couldconsider that earning a few hundred bucks a months, for having grsec in a distro,could be a good deal, and some kind of marketing/communication for grsec. 2018-11-04 02:18:01 If you ever consider some kind of "distro subscription" price . . . come back to me :) 2018-11-04 02:18:19 "waiting for that we ll probably just try to sell it as an option ,customer per customer ,one system at a time" 2018-11-04 02:18:30 butI fear he wont answer anymore :( 2018-11-04 02:23:29 Shiz: if you merge ityou can also close https://bugs.alpinelinux.org/issues/9507 2018-11-04 02:23:56 which is my friendcustomer feature request for twine :) 2018-11-04 07:14:11 python and python-pip are intentionally split up, aren't they? 2018-11-04 07:14:41 hmhm, nevermind, quite the contrary 2018-11-04 09:06:09 danieli, not for py3 https://github.com/alpinelinux/aports/blob/master/main/python3/APKBUILD#L13 2018-11-04 20:26:27 I am a little confused about the apk package signing ... anyone here that could help out? 2018-11-04 20:26:36 IIUC the packages are getting signed by adding files by the pattern of ".SIGN.RSA.-.rsa.pub" containing a signature to the apk. 2018-11-04 20:26:48 Could anyone point me to the code where this signature is getting generated? Or do you know what exactly is getting signed there? 2018-11-04 20:31:19 tcurdt: did you read https://wiki.alpinelinux.org/wiki/Apkindex_format and https://wiki.alpinelinux.org/wiki/Alpine_package_format 2018-11-04 20:34:22 these are starting points 2018-11-04 20:35:43 and how sign is created: https://git.alpinelinux.org/cgit/abuild/tree/abuild-sign.in#n18 2018-11-04 20:43:13 mps yes, I read https://wiki.alpinelinux.org/wiki/Alpine_package_format and https://wiki.alpinelinux.org/wiki/Apkindex_format but that only mentions the signing of the index 2018-11-04 20:44:16 so I assume for the apk packages it will be similar 2018-11-04 20:44:31 but I don't quite understand what is actually getting signed there 2018-11-04 20:44:48 just the data.tgz? or also the control.tgz? 2018-11-04 20:45:49 mps hope that clears up why I am confused on the details? 2018-11-04 20:45:53 thanks for the links! 2018-11-04 20:47:30 never looked at details about sign in apk, only for index 2018-11-04 21:19:27 mps what I am wondeirng is whether signing the index is good enought for a trusted install 2018-11-04 21:19:51 but would still be nice to understand how the signing of the packages works 2018-11-04 21:22:50 well, AFAIK apk is now under heavy rewrite. format will be changed and signing method will be changed 2018-11-04 21:23:18 but, I don't work on it so I don't know much about it 2018-11-04 21:43:08 mps interesting. that's good to know. any pointers on who is working on that where? 2018-11-04 21:51:46 tcurdt: I know about that from the chat on that channel about month or two ago when last security issue is fixed 2018-11-05 11:49:06 rnalrd, are you ok to subpackage libbson https://github.com/alpinelinux/aports/pull/4910#issuecomment-427126721 2018-11-05 13:59:56 hey ncopa, what was the rationale behind https://github.com/alpinelinux/aports/blob/master/community/go/default-buildmode-pie.patch in the go package in community? I'm seeing evidence internally at work that a cgo program compiled against musl 1.1.10 will fail without -buildmode=pie with errors akin to `relocation R_X86_64_32S against symbol `_fini' can not be used when making a PIE object; recompile 2018-11-05 13:59:59 with -fPIC`, but this error doesn't show up again in musl 1.1.20. Was this intentional? 2018-11-05 14:37:21 the thinking with default build mode as pie is that we do that we want have a slightly more secure compile mode by default 2018-11-05 14:38:19 i think there is a bug on issues.a.o on this 2018-11-05 14:38:47 would be good if you can find it and comment there, or create a new issue 2018-11-05 14:38:52 https://bugs.alpinelinux.org 2018-11-05 14:39:17 this is so I dont forget it 2018-11-05 14:42:41 what is the status of the armv7 port? could it be downloaded or installed from somewhere 2018-11-05 14:42:50 ncopa, how is openssl doing? 2018-11-05 14:43:09 mps, builder is not yet ready. 2018-11-05 14:43:32 we are moving it and need to get it running again 2018-11-05 14:44:36 I thought to try just main locally and maybe to try rebuild some things from community 2018-11-05 14:44:49 clandmeter: i have almost all packages in main and community built 2018-11-05 14:44:55 and the tree is rebased 2018-11-05 14:45:00 :) 2018-11-05 14:45:14 there are a handful that needs a bit more attention 2018-11-05 14:45:21 rust, rethinkdb 2018-11-05 14:45:33 should i turn on the armv7 container on the new host? 2018-11-05 14:45:35 some of those have testsuites that fails 2018-11-05 14:45:55 clandmeter: it would be greate if you can do that 2018-11-05 14:46:10 clandmeter: does it make sense to download Timo's main armv7 to try it? 2018-11-05 14:46:11 ok ill shut it down and sync it and turn on on new one. 2018-11-05 14:46:13 maybe also move the build-edge-armhf to there 2018-11-05 14:46:24 yes 2018-11-05 14:46:44 mps: its a new bootstrap of aports repo using timo's main armv7 2018-11-05 14:46:49 it should "just work" ™️ i guess? 2018-11-05 14:46:58 lets find out :) 2018-11-05 14:47:14 there is nothing beeing pushed to them 2018-11-05 14:47:27 could it be rebuild with buildlab? 2018-11-05 14:48:26 I'll see if I can 'install' it in chroot 2018-11-05 14:49:06 mps, the builder will only push packages ones its completed its full cycle for a repo. 2018-11-05 14:49:16 thats why you dont see any packages on mirror 2018-11-05 14:50:08 ok, understand. maybe I've to be patient a little more 2018-11-05 14:50:21 ill swing it back on. 2018-11-05 14:50:31 and it should be a lot faster iirc 2018-11-05 14:52:12 I have four core machine, but FS is on the microSD so it slow for building big packages 2018-11-05 14:52:38 <_ikke_> A pi? 2018-11-05 14:53:04 mps, http://tpaste.us/wjev :) 2018-11-05 14:53:05 samsung exynos5800 2018-11-05 14:53:29 <_ikke_> Not bad :) 2018-11-05 14:53:48 huh, 64 cpus :) 2018-11-05 14:54:17 the problem is slow SD card 2018-11-05 14:54:39 on my side, I mean 2018-11-05 14:55:50 never mind, I'll wait some time for your build. 2018-11-05 15:13:28 mps, armv7 is building again 2018-11-05 15:17:55 clandmeter: thanks, so we could expect it tomorrow to be ready for test :) 2018-11-05 15:18:14 yeah right, keep on dreaming :) 2018-11-05 15:18:54 even with 64 cores, test suites are slow as.... 2018-11-05 15:19:18 and it will surely break at some point waiting for somebody to supply a fix. 2018-11-05 15:19:29 hehe, don't worry. I see less and less difference between dreams and real world :) 2018-11-05 15:20:19 you can follow status on http://build.alpinelinux.org/ 2018-11-05 15:20:30 ok, jokes aside, where I can look at build status 2018-11-05 15:20:54 oh, you were faster in your answer than I was in question 2018-11-05 15:21:18 its one of my selling points. 2018-11-05 15:23:00 good to know about that when I have to ask you something. it will be enough to just think question and wait for answer :) 2018-11-05 15:23:36 thanks again 2018-11-05 15:37:46 <_ikke_> mps: if you don't get an answer, you probably didn't want to have one anyway :P 2018-11-05 15:39:54 _ikke_: could be, sometimes I (and all of us) have strange questions for which we don't like to know answer 2018-11-05 15:41:55 samba is really slow compiling. 2018-11-05 15:42:10 looks like its not using all cores 2018-11-05 15:42:33 not all as in 1 only. 2018-11-05 15:42:59 ncopa: miniupnpd's iptables scripts are broken if nat-pmp is used; would you rather I submit a bug to b.a.o or just send in a patch once I have it ready? (I'll be making one anyways) 2018-11-05 15:43:05 can't be seen in web interface, but yes looks slow 2018-11-05 15:43:18 (and if you'd rather I just send a patch, should that go to alpine-devel or alpine-aports? :) ) 2018-11-05 17:13:01 hi all 2018-11-05 17:13:13 Shiz: can you helpme with https://github.com/alpinelinux/aports/pull/5552 2018-11-05 17:13:40 neofutur: there are requested changes 2018-11-05 17:13:41 any idea what those tests could be forthose packages ? 2018-11-05 17:14:04 depends on the package, I suppose 2018-11-05 17:14:12 and the sourceproblem isjust that I have a commented likne with # ? 2018-11-05 17:14:32 uh.. you mind re-typing that? lots of typos 2018-11-05 17:15:51 sorry my space bar is weak 2018-11-05 17:16:06 and Im french,somy english is not perfect 2018-11-05 18:05:37 well I think I fixed my space bar now ! 2018-11-06 07:46:20 mps, first batch of main has been uploaded. 2018-11-06 07:48:34 I see. What does it means that before going to sleep I saw 90% finished but now it is about 39% 2018-11-06 07:48:45 community 2018-11-06 07:49:26 aha, 90% I saw was from building main 2018-11-06 07:49:39 builder does main first then community and afterwards testing. 2018-11-06 07:50:00 but its just first spin 2018-11-06 07:50:00 now I understand 2018-11-06 07:50:20 some packages failed so pkgs that dep on them will fail. 2018-11-06 07:51:28 when will be possible to see list of failed packages 2018-11-06 08:11:51 <_ikke_> if you join #alpine-commits, you see all packages that fail building 2018-11-06 08:15:36 mps, packages in main that fail are http://tpaste.us/J6M0 2018-11-06 08:15:55 _ikke_: joined 2018-11-06 08:16:54 oh, packages that could need some investigation and fixes 2018-11-06 08:17:51 or is it some other aports-unrelated failure? 2018-11-06 08:18:15 imm adding kernel support, the rest i didnt check. 2018-11-06 08:18:18 could be anything 2018-11-06 08:20:10 how far back should I apply security patch? I stopped at 3.2 2018-11-06 08:20:25 fcolista, check wiki, it has support list. 2018-11-06 08:21:08 3.3 2018-11-06 08:21:18 if i undestood correctly :) 2018-11-06 08:21:24 that would be your answer :) 2018-11-06 08:21:39 I wonder if armhf kernel is same as v7 2018-11-06 08:21:43 my guess says yes. 2018-11-06 08:22:11 lets see if it will work. 2018-11-06 08:22:28 <_ikke_> What I understood is that armhf could either be targetted at v6 or v7 2018-11-06 08:22:51 armhf is v6 2018-11-06 08:22:58 but with hardfload 2018-11-06 08:23:37 i dont have a test container yet, so i cannot test build it. 2018-11-06 08:23:52 going to push it and see what happens :) 2018-11-06 08:25:21 last night I built kernel 4.19.1 for v7 (sunxi board) and tried it on cubieboard1, it works but need some tweaks 2018-11-06 08:26:32 https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases 2018-11-06 08:27:05 fcolista, it says v3.4 2018-11-06 08:27:11 yes 2018-11-06 08:27:19 3.3 is out 2018-11-06 08:27:21 ok 2018-11-06 08:27:26 i arrived to 3.2 :) 2018-11-06 08:27:30 :) 2018-11-06 08:27:44 I think that is enough :) 2018-11-06 08:28:09 you wanted your name on top of the git log i asume. :p 2018-11-06 08:28:24 <_ikke_> Hard to beat ncopa 2018-11-06 08:28:24 ahahaha 2018-11-06 08:28:34 not really, it's a patch from Andy 2018-11-06 08:28:37 not from me :) 2018-11-06 08:28:51 https://github.com/alpinelinux/aports/pull/5563 2018-11-06 08:28:54 3.2 is easy as nobody is pushing to it (except fcolista) :) 2018-11-06 08:29:04 ahaha 2018-11-06 08:29:12 going to push to 2.7 then :P :D 2018-11-06 08:29:31 first test build :p 2018-11-06 08:29:37 uclibc FTW 2018-11-06 08:30:39 yeah :) 2018-11-06 08:33:50 clandmeter: linux-vanilla is 4.14.28 in git repo. If it is for edge shouldn't it be 4.19.x 2018-11-06 08:35:34 mps ? 2018-11-06 08:36:10 just did 'git pull' and looked at linux-vanilla config files 2018-11-06 08:37:00 just means they didnt get an update since X 2018-11-06 08:37:07 and config-vanilla.armv7 header shows 'Linux/arm 4.14.28 Kernel Configuration' 2018-11-06 08:37:22 its just a symlink 2018-11-06 08:37:33 APKBUILD have 'pkgver=4.14.78' 2018-11-06 08:38:06 I see it is symlink to config-vanilla.armhf 2018-11-06 08:38:50 I expected it will be 4.19.x for edge 2018-11-06 08:39:15 the config was created for 4.14 and reused for newer kernel. 2018-11-06 08:40:48 shouldn't be bumped in APKBUILD to 4.19.1 2018-11-06 08:41:12 4.19.1 is released yesterday 2018-11-06 08:41:59 yes it should. 2018-11-06 08:42:06 many thing should be bumped. 2018-11-06 08:42:25 i think ncopa has 200+ commits in his tree 2018-11-06 08:43:03 patients is a virtue 2018-11-06 08:43:50 yes, right. 2018-11-06 08:45:23 mps, would be nice if you can go over the armv7 list and see if you can fix some of the build failures. 2018-11-06 08:45:43 I promised to local HAM (radio amateur) group today to make SBC for radio repeater so I have to work on it now 2018-11-06 08:46:40 but I hope that this night I will have time to build kernel linux-vanilla and bump it to 4.19 2018-11-06 08:47:08 btw, I made radio repeater on Alpine Linux 2018-11-06 08:47:53 <_ikke_> nice 2018-11-06 08:49:48 maybe I will document it when we put it to operate. I hope it will be finished at the weekend 2018-11-06 08:58:15 i saw the armv7 is being added, isn't that hardfloat as well? 2018-11-06 08:58:52 AinNero, yes. it just targets newer CPUs with enhanced vfpu/instructionset/thumb2 support. 2018-11-06 08:59:31 ah right. i wrongly assumed it was intended like armel 2018-11-06 09:02:38 no, we don't do armel currently. 2018-11-06 09:06:10 i read the issue about considering it 2018-11-06 09:09:35 yes, i think there is a ticket about it. also some other hw too like mips. 2018-11-06 09:17:02 clandmeter: I will, just looked at u-boot (first thing first), will try to fix it 2018-11-06 09:23:55 the armv7 failures mostly look like dependencies missing from the APKBUILD's 2018-11-06 09:25:58 AinNero: yes, just looked at awesome log, it missing imagemagick 2018-11-06 09:26:02 AinNero, yes they depend on things that dont build. 2018-11-06 09:26:42 so fixing the root pkg will probably fix it 2018-11-06 09:27:00 when community finishes more will have that issue. 2018-11-06 09:28:41 ncopa, i set armv7 to continue on error. seems only a few pkgs in main fail. 2018-11-06 09:28:47 so the build will take two or more rounds to solve these missing bugs 2018-11-06 09:29:20 when initial build round is finished we set it back to halt on error 2018-11-06 09:29:43 and we will provide a list of pkgs that fail. 2018-11-06 09:29:45 we don't need to look at these packages which are not built because of missing deps? 2018-11-06 09:29:55 clandmeter: is there an ETA for it? 2018-11-06 09:29:59 so we can all chip in and make it finish. 2018-11-06 09:30:17 mps, nope, just check the deps that it misses. 2018-11-06 09:30:38 AinNero, we are in release month. 2018-11-06 09:31:03 i think we want to ship armv7 with new release 2018-11-06 09:31:17 and new openssl 2018-11-06 09:31:18 i mean like, when is the first round finished 2018-11-06 09:31:33 check build.a.o 2018-11-06 09:31:41 thats all the info i have. 2018-11-06 09:31:55 after community it will go over testing. 2018-11-06 09:32:13 i have 276 commits currently 2018-11-06 09:32:15 i havent started with testing repo yet 2018-11-06 09:32:30 /o\ 2018-11-06 09:32:33 currently building rust 2018-11-06 09:33:00 i have rust, oscam and rethinkdb before i start with testing 2018-11-06 09:33:20 ncopa, oscam i need to bump 2018-11-06 09:33:50 AinNero, because armv7 is similar like armhf, i dont expect too much trouble. 2018-11-06 09:34:14 ok, i'll leave oscam for now then 2018-11-06 09:34:22 ill bump it now 2018-11-06 09:35:30 ok 2018-11-06 09:38:01 done 2018-11-06 10:34:01 clandmeter: tried and built u-boot on armhf without errors. 2018-11-06 10:37:26 for minicom, source url is invalid 2018-11-06 10:37:27 mps, yes the apkbuild is not yet armv7 compat 2018-11-06 10:39:23 so i could not check why u-boot doesn't build 2018-11-06 10:39:50 i pushed a fix 2018-11-06 10:40:10 I need armv7 installed to check it and armv7 couldn't be installed, yet 2018-11-06 10:41:51 looks like alpine-keys also needs a fix 2018-11-06 10:44:10 yes, missing armv7 key 2018-11-06 10:45:15 for mc (midnight commander) libssh is missing 2018-11-06 10:46:31 maybe wait for second build round to look seriously at bugs 2018-11-06 10:49:29 mps, does jemalloc build/test on your system? 2018-11-06 10:49:44 let me see 2018-11-06 10:50:02 just building libssh2 2018-11-06 10:50:43 libssh2 built ok 2018-11-06 10:51:21 I'm guessing most APKBUILDs need to have armv7 added to `$arch` now? will that be done automatically by some script, or will we have to go over the packages manually and test them one by one if they all compile still? 2018-11-06 10:51:43 PureTryOut[m], no, most have all as arch so its ok. 2018-11-06 10:51:48 others have been patched 2018-11-06 10:51:52 oh yeah true 2018-11-06 10:53:14 is the building stuck sometimes? seems it has been building for armv7 for quite a while now 2018-11-06 10:53:21 clandmeter: jemalloc is built ok 2018-11-06 10:53:34 build and test? 2018-11-06 10:53:55 abuild build ; abuild rootpkg 2018-11-06 10:56:18 and jemalloc*apk's are in ~/packages/main/armhf/ 2018-11-06 10:56:47 abuild -r 2018-11-06 10:56:47 how to 'test' it 2018-11-06 10:57:09 emalloc: Updating the main/armhf repository index... 2018-11-06 10:57:11 -r will do all regular steps 2018-11-06 10:57:21 jemalloc: Signing the index... 2018-11-06 10:57:44 jemalloc fails in tests. 2018-11-06 11:00:07 ok, removed it from ~/packages and tried 'abuild -r' and got '>>> ERROR: jemalloc: all failed' 2018-11-06 11:00:23 '>>> jemalloc: Uninstalling dependencies...' 2018-11-06 11:00:31 no need to remove pkgs, abuild -rf 2018-11-06 11:01:57 tried 'abuild deps' and got '>>> ERROR: jemalloc: deps failed' 2018-11-06 11:02:47 interesting is 'abuild build' work 2018-11-06 11:02:52 not sure about your setup, normally you sh ould just cd into apkbuild directory and run abuild -r 2018-11-06 11:03:14 make sure you have repo's setup so it can install deps. 2018-11-06 11:04:27 well, i think i have it 2018-11-06 11:04:59 after build you can run abuild check 2018-11-06 11:05:33 hmm, jemalloc APKBUILD doesn't have deps 2018-11-06 11:11:51 ncopa, do we need to keep jemalloc? it seems not used by anything anymore. 2018-11-06 11:32:51 clandmeter: u-boot is built with your new patch (armv7 support) on my machine 2018-11-06 13:15:31 clandmeter, iirc jemalloc was used in firefox 2018-11-06 13:21:48 andypost: are you sure? firefox APKBUILD have '--disable-jemalloc' 2018-11-06 13:22:49 mps, thanks - it means it was ages ago( 2018-11-06 13:24:39 so only community/monkey depends on it 2018-11-06 13:25:16 yes, I found the same 2018-11-06 15:30:12 clandmeter: if jemalloc is not used then we can probably remove it 2018-11-06 15:31:26 ncopa: only monkey list it in makedepends 2018-11-06 15:33:09 actually, more packages may use it with latest musl, which should make it possible to interpose malloc 2018-11-06 15:34:11 i havent looked into the error much 2018-11-06 15:34:18 i just setup my own armv7 container 2018-11-06 15:34:34 i could simply just diable it for armv7 for now 2018-11-06 15:35:46 monkey could be built --malloc-libc instead 2018-11-06 15:37:04 built with --malloc-libc, ofc 2018-11-06 15:37:30 i think its wrong 2018-11-06 15:37:38 it does not link to jmalloc 2018-11-06 15:37:48 jemalloc 2018-11-06 15:39:35 we need to add "what license is alpine?" to FAQ 2018-11-06 15:40:17 yes, or maybe add a license.txt to aports? 2018-11-06 15:40:45 answer is, "Various. Alpine is built of various different software packages, and each package has its own license" 2018-11-06 15:41:18 right, but what about license of code we added ourselves? 2018-11-06 15:41:22 license of the APKBUILD scripts is more complicated 2018-11-06 15:41:34 apk-tools is gpl-2 iirc 2018-11-06 15:41:39 abuild too 2018-11-06 15:41:57 rebuilt monkey with --malloc-libc and removed jemalloc-dev from makedepends, but didn't tried to run it 2018-11-06 15:42:06 gplv2 can be a headache i remember. 2018-11-06 19:25:06 building of armv7 testing started :) 2018-11-07 03:29:40 sorry (possibly in advance) to everyone on alpine-aports, serves me right for working on things late at night 2018-11-07 09:32:19 ncopa, so we can now leave out cd to builddir? 2018-11-07 10:21:28 clandmeter: technically yes but i'd like us to keep the cd til after v3.9 release at least 2018-11-07 10:21:48 ok i did it two times now :) 2018-11-07 10:54:32 clandmeter, please backport https://github.com/alpinelinux/aports/pull/5392 and related 2018-11-07 10:59:17 ncopa, im bumping into http://tpaste.us/65XB 2018-11-07 11:00:32 fabled, is that hf related? 2018-11-07 11:03:35 clandmeter, seems some files are built with incompatible gcc flags 2018-11-07 11:03:47 sounds makefile issue 2018-11-07 11:04:14 enable-runtime-cpu-detect sounds wrong 2018-11-07 11:05:16 i should disable that feature? 2018-11-07 11:06:13 doesnt matter 2018-11-07 11:08:50 fabled, i can use target generic-gnu, but i guess that will disable some cpu extensions? 2018-11-07 11:11:04 depends on the source code how the stuff is done. best is if the build system optimizes to the target gcc says it is building for. abuild setups gcc flags correctly 2018-11-07 11:30:59 ncopa, i have no idea how to fix libvpx on armv7, so ill target generic-gnu for now. 2018-11-07 12:00:05 sigh, now freeswitch is bumping into the same issue. 2018-11-07 12:02:34 i can have a look at it after openssl is pushed 2018-11-07 12:02:39 it includes freeswitch update 2018-11-07 12:09:50 ncopa, ok please. also look into my libvpx hack. 2018-11-07 12:10:10 ill leave armv7 alone now. 2018-11-07 13:43:39 ncopa, when are you pushing openssl? 2018-11-07 14:27:26 today hopefully 2018-11-07 14:27:46 i just need rebase the ffmpeg4 patches from alpine-aports 2018-11-07 14:28:02 15 patches 2018-11-07 14:28:07 and then i think i'll push 2018-11-07 14:31:09 i also need look over the 300+ patches i have in queue 2018-11-07 16:58:14 ok, here comes openssl 1.1.... 2018-11-07 16:59:28 python 3.7 incoming too then! 2018-11-07 17:00:08 it will require openssl >1.1.1 2018-11-07 17:01:36 i guess there are a zillion py-packages that needs to be rebuild when we push python 3.7 2018-11-07 17:01:48 oh yeah, without doubt 2018-11-07 17:02:02 many aio-packages will need updating since async was made a reserved keyword in 3.7 2018-11-07 17:02:21 sounds like a bigger project then 2018-11-07 17:02:29 indeed, needs some checking out 2018-11-07 17:02:35 i dont think we will have time before v3.9 :-( 2018-11-07 17:02:37 things *will* break 2018-11-07 17:02:42 yeah, true, we have bigger issues 2018-11-07 17:02:43 we need get the v3.9 builders up 2018-11-07 17:03:06 if you by 'we' mean you and clandmeter (and whoever has access?), sure! ;) 2018-11-07 19:28:28 python 3.7.1 almost builds 2018-11-07 19:28:29 *almost* 2018-11-07 19:31:50 Fatal Python error: Segmentation fault 2018-11-07 19:31:52 :) 2018-11-07 20:19:29 danieli, https://github.com/alpinelinux/aports/pull/4840 where you get segfault? 2018-11-07 20:20:06 a test, probably the builder not set up 100% correctly 2018-11-07 20:21:05 last time I did check only test_ssl was reproducable locally 2018-11-07 20:21:21 test_embed and test_c_locale_coercion 2018-11-07 20:21:34 test_ssl solved itself once I pulled a newer openssl 2018-11-07 20:21:46 it doesn't like anything except openssl >1.1.1 2018-11-07 20:21:56 ah... then locale just needs tuning 2018-11-07 20:22:15 it crapped its pants about fs attributes or something similar 2018-11-07 20:22:23 LANG=C- 2018-11-07 20:22:26 darn it 2018-11-07 20:22:33 LANG=C.UTF-8 did not fix it 2018-11-07 20:28:15 ncopa, it needs to decide about removal of php5 before 3.9 release 2018-11-07 20:28:43 btw is there schedule for 3.9? 2018-11-07 21:46:46 andypost: i'd like to get v3.9 out before 1 Dec 2018-11-07 21:47:41 what do we need to do to remove php5? do we need to do anything more than remove the package? 2018-11-07 21:50:29 <_ikke_> php5-cacti as well probably 2018-11-07 21:50:43 <_ikke_> sorry, cacti-php5 2018-11-07 21:50:58 i guess we need to remove everything *php5* 2018-11-07 21:51:09 can cacti be built with php7? 2018-11-07 21:51:46 php5-suhosin 2018-11-07 21:52:04 phpldapadmin, rutorrent and zoneminder also dep on it 2018-11-07 21:52:13 <_ikke_> hmm, I don't think suhosin is supported in php7 2018-11-07 21:52:13 looks like zoneminder can use php7 now 2018-11-07 21:52:27 <_ikke_> SpaceToast: why are those not in the requires list? 2018-11-07 21:52:35 <_ikke_> 'required by' 2018-11-07 21:53:02 _ikke_: I'm just looking through it through pkgs.alpinelinux.org 2018-11-07 21:53:25 I'm not actually responsible for any of those, just going through the projects to see if they've done anything to work with php7 (seeing as 5 goes fully EOL dec 31) 2018-11-07 21:53:26 <_ikke_> me as well 2018-11-07 21:53:34 <_ikke_> ncopa: cacti-php7 already exists 2018-11-07 21:53:42 i suppose the other option is to keep it there, but just not provide security fixes after 31 Dec 2018 2018-11-07 21:53:56 rutorrent #1384 claims php7 works too 2018-11-07 21:54:10 <_ikke_> ncopa: https://git.alpinelinux.org/cgit/aports/tree/community/cacti/APKBUILD#n17 2018-11-07 21:54:32 lets remove cacti-php5 then 2018-11-07 21:55:40 phpldapadmin seems to work on php7 too 2018-11-07 21:56:33 ok, so that means all projects that directly dep on php5 (I didn't check php5-* though) all at least claim to function with 7 now \o/ 2018-11-07 21:56:53 <_ikke_> SpaceToast: zoneminder as well? 2018-11-07 21:57:46 _ikke_: bug 1999 on their github claims their api version 7.1 should work with php7 2018-11-07 21:58:23 looks like they only changed because ubuntu removed php5 (?) 2018-11-07 21:59:30 <_ikke_> yeah, ubuntu 18 only has php7 2018-11-07 21:59:36 <_ikke_> testing zoneminder now 2018-11-07 22:06:01 <_ikke_> PHP Fatal error: Cannot use 'String' as class name as it is reserved in ./lib/Cake/Utility/String.php on line 26 2018-11-07 22:06:09 <_ikke_> ran php lint on all php files 2018-11-07 22:09:41 looked a bit more, they definitely advertise php7 compatibility at this point (there was a PR back in 2016 that was meant to fix most of it, and their installation instructions for ubuntu 16 use php 7.0), but their docs only talk about building from source on a debian-based host using a script that generates a .deb file 2018-11-07 22:11:31 _ikke_, String file may exists but not actually used 2018-11-07 22:11:46 actually, that looks like it's part of cakephp, which is a different project 2018-11-07 22:12:20 it could be just a copy 2018-11-07 22:12:54 aha, they're bundling cake 2.10.8 2018-11-07 22:13:03 while cake upstream is 3.6 2018-11-07 22:13:51 and cake 3.6 had String.php as a stub-file 2018-11-07 22:14:01 still, since they have it running on php 7.0+ I'd guess it's not used 2018-11-07 22:16:20 the list of dependent packages already in https://bugs.alpinelinux.org/issues/9291 2018-11-07 22:16:59 ah, nice; though notably both zoneminder and rutorrent mention php7 (at least they do now) :) 2018-11-07 22:17:15 so only phpldapadmin, zoneminder & rutorrent 2018-11-08 00:58:18 _ikke_: suhosin is practically deprecated 2018-11-08 00:58:44 suhosin7 is something else, suhosin is for php 5.x 2018-11-08 00:59:06 danieli, for php7 we added https://github.com/alpinelinux/aports/pull/5061 2018-11-08 00:59:34 meanwhile phpldap was easy to fix - all PRs filed and waiting for maintainers 2018-11-08 01:00:57 I did not test only cacti & zoneminder 2018-11-08 09:44:22 andypost: what is your opinion, do you want remove php5 or do you want keep it for v3.9. We only need support it til May 2019, and we can do it best-effort 2018-11-08 09:44:41 i.e if there is a security issue and the fix is easy to fix, we backport the fix 2018-11-08 09:45:00 and if its complicated we simply say "sorry, its not supported upstream anymore, switch to php7" 2018-11-08 09:57:54 ncopa, I'd prefer to remove because it will cut-off some maintenance & get more attension to migration 2018-11-08 09:59:28 ncopa, last night I filed all needed PRs but have no idea how to check zoneminder and cacti 2018-11-08 10:00:04 the leftover is drupal7 which has all needed patches and I'm just waiting for release 2018-11-08 10:00:49 andypost: sounds good. lets remove php5 2018-11-08 10:08:20 ncopa, do I need to bump pkgrel for removal? https://github.com/alpinelinux/aports/pull/5573 2018-11-08 10:09:44 andypost: yes, otherwise will the builder not do anything with the package. ie. it will not rebuild the package, nor remove it 2018-11-08 10:09:45 or.... 2018-11-08 10:10:19 actually, it think it may get removed without the pkgrel bump 2018-11-08 10:10:43 but i'd recommend that you bump pkgrel since the final result of the build is different 2018-11-08 10:10:51 but the old version may left... It looks too much in details of builders 2018-11-08 10:11:56 the builder will parse all APKBUILDs and calculate what packages is expected to be in the repo, and remove everything not exepected to be there 2018-11-08 10:12:22 got it thanks! 2018-11-08 10:13:25 ncopa, did you update aarch64 kernel to include those changes i requested? 2018-11-08 10:15:32 no 2018-11-08 10:15:41 do you still have the diff? 2018-11-08 10:16:01 im working on a kernel update now, so it is a good time to do it 2018-11-08 10:16:33 we want that backported to v3.8 too right? 2018-11-08 10:16:53 yes, but i could also take kernel from edge 2018-11-08 10:17:56 im just afraid that when i upgrade i pull in a non compat kernel 2018-11-08 10:18:05 lets backport it 2018-11-08 10:18:51 http://tpaste.us/Er6W 2018-11-08 10:18:55 i think thats the diff 2018-11-08 10:19:09 http://tpaste.us/Er6W 2018-11-08 10:19:16 yeah, just found it 2018-11-08 10:19:28 btw, when do you have time to look at those things from yesterday? 2018-11-08 10:19:33 related to armv7 2018-11-08 10:19:53 if you want to help with armv7 i need some expert support :) 2018-11-08 10:25:37 ncopa, i would like to include the multi threaded gzip in abuild. 2018-11-08 10:25:41 its currently in a PR 2018-11-08 10:25:53 yeah, i think that is a good idea 2018-11-08 10:25:59 its way faster 2018-11-08 10:26:04 for sure on arm boxes 2018-11-08 10:26:07 <_ikke_> \o/ 2018-11-08 10:26:37 ill add it as a patch to abuild in edge. 2018-11-08 10:26:39 i am going to merge that armv7 related kernel config for aarch64 kernel 2018-11-08 10:26:45 and push linux-vanilla 4.14.79 2018-11-08 10:26:52 and possibley backport the kernel to v3.8 2018-11-08 10:27:05 no 19? 2018-11-08 10:27:13 i'll do that later 2018-11-08 10:27:16 ok 2018-11-08 10:27:47 then i'm gonna try unblock the builders 2018-11-08 10:27:54 they fail after the openssl push 2018-11-08 10:28:10 then i can have a look at the armv7 stuff 2018-11-08 10:28:33 i'd like to get the new machine build v3.9 armv7 and armhf 2018-11-08 10:28:59 which means that i'd like to move my ncopa-edge-armhf to there 2018-11-08 10:29:12 so i'd like to configiure awall etc on the new machine 2018-11-08 10:29:15 you know where to find it. 2018-11-08 10:29:29 i just installed dmvpn 2018-11-08 10:29:35 oh, great! 2018-11-08 10:29:37 including its 31 deps :| 2018-11-08 10:29:45 :D 2018-11-08 10:30:03 lets talk about that in #alpine-infra 2018-11-08 10:40:44 ncopa, should we make pigz a dep of abuild? 2018-11-08 10:41:54 then we need make sure it is possible to crosscompile, and that it is in main 2018-11-08 10:42:04 i think we can install it manually for now 2018-11-08 10:42:21 i wonder if we should have a 'alpine-builder' meta package or similar 2018-11-08 10:42:43 or make it a dependency of aports-build 2018-11-08 10:43:10 would be cool if it could be a part of busybox 2018-11-08 10:43:20 pigz? 2018-11-08 10:43:32 multi thread support to gzip 2018-11-08 10:43:44 i dont think thats a goal for busybox 2018-11-08 10:43:46 but yeah... 2018-11-08 10:44:03 i think GNU gzip is multithreaded too 2018-11-08 10:44:12 i dont think so 2018-11-08 10:44:23 why else would we use pigz? 2018-11-08 10:44:54 btw, i added xz support before, but it seems its just a stub for now... 2018-11-08 11:30:42 looks like we problems with the builders 2018-11-08 11:30:54 WARNING: Ignoring /home/buildozer/packages/main/x86_64/APKINDEX.tar.gz: UNTRUSTED signature 2018-11-08 11:31:20 build-edge-x86_64:~$ openssl 2018-11-08 11:31:20 -ash: openssl: not found 2018-11-08 12:30:24 ncopa: ouch 2018-11-08 12:30:34 i saw -commits earlier 2018-11-08 12:30:50 that's one heck of a mean looking log 2018-11-08 12:31:47 ncopa, https://github.com/alpinelinux/aports/pull/5579 it builds and works but not sure about --with-need-dh=no 2018-11-08 12:37:04 andypost: looks good to me 2018-11-08 13:02:42 ncopa, fix for syslog-ng https://github.com/alpinelinux/aports/pull/5153#issuecomment-436984679 2018-11-08 14:33:56 andypost: wonderful! 2018-11-08 14:43:39 ncopa, meanwhile last brick of php5 removal ready https://github.com/alpinelinux/aports/pull/5583 2018-11-08 14:46:27 great! 2018-11-08 14:48:59 checking for perl... no 2018-11-08 14:48:59 configure: error: You need 'perl' to compile libbson 2018-11-08 14:48:59 >>> ERROR: syslog-ng: build failed 2018-11-08 14:49:00 configure: error: ./configure.gnu failed for modules/afmongodb/mongo-c-driver 2018-11-08 14:49:18 i think syslog-ng should use systemprovided mongo-c-driver if possible 2018-11-08 14:49:35 ncopa, autoconf should setup perl 2018-11-08 14:49:55 oh, its old version 2018-11-08 14:51:30 ncopa, and mongo-c-driver in testing 2018-11-08 15:27:07 ncopa, https://github.com/alpinelinux/aports/pull/5584 fixes build 2018-11-08 15:40:42 pushed. thanks! 2018-11-08 15:41:27 im looking at freeswitch 2018-11-08 15:41:46 apparently it chokes on ppc64 due to the -Werror thing 2018-11-08 15:41:59 i dunno why it does not fail on x86_64 2018-11-08 16:30:26 ncopa: i updated both PR with requested changes 2018-11-08 16:30:59 good! 2018-11-08 21:20:44 how do you usually bootstrap self-compiling languages in alpine? 2018-11-08 21:21:02 I'm building some compilers that can be built by themselves for a faster compiler 2018-11-08 21:24:06 you can check some other langs in aports 2018-11-08 21:24:31 good point, will do 2018-11-09 05:43:05 <_ikke_> https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures 2018-11-09 05:43:41 <_ikke_> summary: they will be phasing out containers 2018-11-09 05:43:54 <_ikke_> in favor of full virtual machines 2018-11-09 05:51:59 the reason appears to be... that docker doesn't handle nesting very well 2018-11-09 05:52:07 lol 2018-11-09 05:53:18 <_ikke_> Apparently we have managed to get docker in docker to work 2018-11-09 05:53:27 <_ikke_> (Where I work) 2018-11-09 06:07:09 I use lxc and lxd at work, nesting is literally a stated project goal 2018-11-09 06:07:15 it's never been something I actually needed to consider 2018-11-09 06:28:17 <_ikke_> For CI processes this is often an issue 2018-11-09 06:29:58 I recall setting up jenkins at some point in docker, and only allowing the docker runner (aka docker-in-docker) 2018-11-09 06:30:04 still worked mostly fine, I think 2018-11-09 06:30:24 ah wait no, the jenkins instance was running docker inside of lxd, which might be why it was ok 2018-11-09 07:12:43 hi folks! qt5-qtwebengine is broken after the soname bump in libavformat.so. can somebody merge this pkgrel bump? https://github.com/alpinelinux/aports/pull/5586 2018-11-09 07:12:45 (talking about edge) 2018-11-09 07:38:23 ollieparanoid[m], done 2018-11-09 07:40:53 oh, right 2018-11-09 07:41:03 there may be more packages that needs a bump 2018-11-09 07:43:06 i havent checked. 2018-11-09 07:43:19 im just customer support today. 2018-11-09 07:44:08 clandmeter: thanks! 2018-11-09 07:44:19 i know there are more. i will try rebuild those later today 2018-11-09 07:45:23 ncopa, what about the armv7 issue i pointed out? 2018-11-09 07:45:49 i havent get to it yet sorry 2018-11-09 08:29:22 hi ncopa - are you okay with my comment not to make python a dependency in https://github.com/alpinelinux/aports/pull/5387 because the package can often be used without python? 2018-11-09 08:30:07 if so, is there anything more I should do to get the change merged? 2018-11-09 08:32:29 \o/ 2018-11-09 08:35:09 ncopa: sorry - slightly confusing cases - actually what I mean to say is that I did your requested python 2 elimination fix - are you now happy? 2018-11-09 08:55:04 Mikedlr: hi, thank you for that. I don’t have time to look closer at it right now, but I think it also would be nice if you could squash your commits 2018-11-09 09:46:14 mikedlr: made some local changes (fixed indention, bumped pkgrel, reenabled cl, …) and merged this. let me know if I accidentally broke something 2018-11-09 09:46:33 https://git.alpinelinux.org/cgit/aports/commit/?id=36a9832e79c7a81210bea6400100d5888f10a7db 2018-11-09 09:51:36 fabled: any chance you could take a look at https://github.com/alpinelinux/apk-tools/pull/17 ? 2018-11-09 10:00:00 nmeum, i'm not sure about that. the info output might be parsed by scripts 2018-11-09 10:00:18 yeah, I mentioned this in the 2018-11-09 10:00:36 PR description we could disable this by default and add a -h flag or something like this for enabling it 2018-11-09 12:07:46 Hi, I'm facing problem with syslog system call. All the messages are truncated at 1024 chars. Checking I found out that musl-libc has a hardcoded limit of 1024 to send the messages. Anyone knows why we have this limitation of 1024 chars? 2018-11-09 12:11:19 not an answer, but is that limit a problem? I mean, 1) Can't you split the message before logging? and 2) If not, is 1024 chars log line actually a problem? 2018-11-09 12:12:16 using a small, fixed size is quite handy from a developer point of view. Avoiding dynamic memory allocations is great and greatly simplifies the code. 2018-11-09 12:13:04 as for the size, 1024 seems a good buffer size. What would you obtain from increasing it? 2018-11-09 12:15:54 1024 is default value in many other distributions 2018-11-09 12:16:59 The thing is I need to log all the content for http post request (normally body > 6000). For now I'm currently splitting at every 1024 but it's not easy to guarantee the order of chunked logs once it gets busy 2018-11-09 12:18:24 but I really want to know if there is some particular reason to be 1024, maybe due some other factor that I'm not aware of 2018-11-09 12:19:48 adirkuhn: 1024 is quite enough for syslog, bigger content should be handled at app level 2018-11-09 12:21:15 I have similar app where I log full http request but not over syslog 2018-11-09 12:22:36 interestingly, POSIX defines that `syslog` parameters after level should be treated like fprintf and doesn't defines any limit for neither. 2018-11-09 12:30:06 milliardo, I found that: https://serverfault.com/questions/329794/an-alternative-to-usr-bin-logger-for-getting-logs-from-apache-to-syslog-ng 2018-11-09 12:30:58 fcolista, are you ok with https://github.com/alpinelinux/aports/pull/5571 2018-11-09 12:35:55 @unmy @milliardo so I have recompiled busybox (syslogd and logger) with a bigger limit but there is the limitation for the musl-libc (I think for that i need to recompile the kernel) I will take a look at this sys::syslog 2018-11-09 12:38:54 no, just musl. libc, let it be either glib or musl or uclibc or whatever builds its functionality over the kernel. 2018-11-09 12:43:50 +1 andypost 2018-11-09 12:47:31 yay! only 3 left, maybe rnalrd will approve https://github.com/alpinelinux/aports/pull/5574 2018-11-09 12:48:31 yeah, i plan to do it before EoD 2018-11-09 12:49:24 rnalrd, thanks I wish to get rid of remains before 3.9 2018-11-09 13:54:42 ncopa, do we want ffmpeg 4 in AL3.9? 2018-11-09 13:56:35 there are a number of patches ffmpeg related in aports, I've reviewed several of them and I believe that all modifications I requested have been submitted 2018-11-09 14:24:22 rnalrd: yes. i already pushed ffmpeg 4.0.x 2018-11-09 14:24:52 rnalrd: i pushed the patches from alpine-aports 2018-11-09 14:25:00 oh ok 2018-11-09 14:25:07 i think there is is an upgrade on github 2018-11-09 14:25:18 didn't care to whatch the commit 2018-11-09 14:25:28 i'll mark the patches as accepted 2018-11-09 14:25:29 <_ikke_> Would we be affected if travis would phase out docker containers? 2018-11-09 14:32:54 i dont think so. i think our travis installs alpine in a chroot 2018-11-09 16:09:45 wow, that's a lot of join/quit msgs 2018-11-09 16:10:06 I really need to get that context whatever script set up again 2018-11-09 16:16:36 wow 2018-11-09 16:17:20 can someone ban them for an hour or so? 2018-11-09 16:17:48 milliardo: see -offtopic for a workaround 2018-11-09 16:32:02 <_ikke_> hmm, nmeum 2018-11-09 16:34:10 can't really tell him about it either, he quits so fast 2018-11-09 18:07:42 rnalrd, I think this kind of formatting more readable https://github.com/alpinelinux/aports/pull/5574/files#diff-4721d10b54738a40a24f9ab8eda118cbR10 2018-11-10 19:11:44 <^7heo> Hi. 2018-11-10 19:12:05 <^7heo> I'm using claws-mail, or rather, was using it; and now, when I try to start it, it fails to find a symbol, namely `mailstream_ssl_set_server_name`. 2018-11-10 19:12:18 <^7heo> I have tried to fix -d the package, I also installed `libetpan`. 2018-11-10 19:12:28 <^7heo> it still fails to execute it. 2018-11-10 19:12:38 <^7heo> Any idea? Could the package currently be broken? 2018-11-10 19:12:51 it's possible that the ABI has broken through some update of something, I'll check real quick 2018-11-10 19:13:04 <^7heo> thanks, 2018-11-10 19:15:26 <^7heo> I should add, I just upgraded my install, because I needed to install a claws plugin, and there are a few things that fail to work now. 2018-11-10 19:15:51 <^7heo> namely, the most obvious is the USB subsystem when I disconnect/reconnect my keyboard/mouse hub. 2018-11-10 19:15:55 it might be related to us moving to openssl rather than libressl 2018-11-10 19:16:04 and that's pretty odd 2018-11-10 19:16:05 <^7heo> yeah I thought so. 2018-11-10 19:16:40 <^7heo> for now I can do with the broken USB, I mainly need mail :P 2018-11-10 19:17:04 <^7heo> all I have to do for the USB to work fine is to reboot. 2018-11-10 19:17:26 anything interesting in dmesg? 2018-11-10 19:17:39 <^7heo> again, I'll fix usb as soon as mail works :D 2018-11-10 19:18:00 <^7heo> I promise I won't leave immediately after mail is fixed, but I need mail first. 2018-11-10 19:19:08 argh, I can't really test it, some things on my test system require openssl 2018-11-10 19:19:16 <^7heo> huhu 2018-11-10 19:19:18 I can fix the apkbuild to use openssl instead and test that 2018-11-10 19:19:22 <^7heo> I have both openssl and libressl installed 2018-11-10 19:19:30 <^7heo> might that be the problem? 2018-11-10 19:19:32 they conflict iirc 2018-11-10 19:19:36 <^7heo> ok 2018-11-10 19:19:52 http://tpaste.us/ErLW 2018-11-10 19:20:55 <^7heo> the email package depends on libressl, btw. 2018-11-10 19:21:19 yeah, that's the one I'm patching (claws-mail) 2018-11-10 19:21:30 <^7heo> ah 2018-11-10 19:21:45 holy hell that's a lot of build deps 2018-11-10 19:22:19 and you're free to stick around if you want to 2018-11-10 19:22:31 <^7heo> well I mostly need mail to work :P 2018-11-10 19:22:36 it's compiling right now 2018-11-10 19:23:18 <^7heo> problem is, I need to send encrypted mail, and using pgp on a file like `cat foobar | pgp --encrypt blah bla blah > foobar.enc` does not work for my contact. 2018-11-10 19:23:28 <^7heo> maybe if I attach it with the asc extension? 2018-11-10 19:23:38 <^7heo> just, I can't really try... sucks. 2018-11-10 19:23:51 it built for sure, I could upload some apks for you to test, if it requires X 2018-11-10 19:23:55 my test box is headless 2018-11-10 19:24:08 <^7heo> yeah I could test if you want. 2018-11-10 19:24:15 <^7heo> all I want is claws to work ;P 2018-11-10 19:24:48 don't think I have it set up as a mirror, so I'll just hand you the apks in a zip 2018-11-10 19:25:10 <^7heo> can you tgz it instead? 2018-11-10 19:25:14 sure 2018-11-10 19:27:36 ^7heo: http://uk.alpinelinux.org/alpine/claws-mail.tar.gz 2018-11-10 19:27:56 it was the easiest spot to serve it from lol 2018-11-10 19:28:10 <^7heo> all good 2018-11-10 19:29:45 <^7heo> how do you trust an untrusted package again? 2018-11-10 19:30:09 either --allow-untrusted, or I could give you my build key from that box 2018-11-10 19:30:29 sha512 is 7fb933da2bb96f3944c3b30bf0e83cf57fe6c30dd5a8b8d5dfc77262287d9f89f358acb2eeb7bfbf63fec7c1ba862c66e751156b13e3c07c203fd2f1c9eade77 2018-11-10 19:30:34 <^7heo> nah all good 2018-11-10 19:30:53 <^7heo> same problem 2018-11-10 19:31:05 apk add --allow-untrusted claws-mail-X.apk 2018-11-10 19:31:32 <^7heo> yeah 2018-11-10 19:31:34 <^7heo> did that. 2018-11-10 19:31:38 odd, let me test it 2018-11-10 19:31:43 <^7heo> $ claws-mail 2018-11-10 19:31:44 <^7heo> Error relocating /usr/bin/claws-mail: mailstream_ssl_set_server_name: symbol not found 2018-11-10 19:31:49 oh that, darn it 2018-11-10 19:32:12 hm, https://git.alpinelinux.org/cgit/aports/commit/?id=b4e3d00524860b10b276f992f87f5db7e47860bf 2018-11-10 19:32:31 there's a sni.patch file 2018-11-10 19:32:37 <^7heo> yeah 2018-11-10 19:32:48 <^7heo> but it's not there or? 2018-11-10 19:33:17 let's see if I can't just update the package entirely and ditch the patch 2018-11-10 19:33:25 <^7heo> ok? 2018-11-10 19:34:44 <^7heo> wait, is it possible that apk ignored installing your package since it's the same version number I have installed? 2018-11-10 19:35:13 oh right! I forgot to bump the pkgrel 2018-11-10 19:37:19 <^7heo> do you think you could recompile with a bumped version and upload that? 2018-11-10 19:38:03 sure 2018-11-10 19:38:18 <^7heo> thanks a bunch 2018-11-10 19:41:02 done 2018-11-10 19:41:03 same URL 2018-11-10 19:41:08 sha512 d652ea5133df1bb24a18a8f1904f8f0400e61ec455428261ada0609c5476e589efeac7f97707612d184c025c8d89ed16a04dd1aa6194008d424b8f024216f378 2018-11-10 19:41:12 <^7heo> thanks! 2018-11-10 19:41:50 literally just recompiled with openssl 2018-11-10 19:41:52 it's x86_64 2018-11-10 19:42:12 <^7heo> yeah like my arch 2018-11-10 19:42:13 <^7heo> thanks 2018-11-10 19:42:59 <^7heo> same issue 2018-11-10 19:43:03 argh 2018-11-10 19:43:05 <^7heo> lemme see if I need to install more. 2018-11-10 19:43:15 <^7heo> does not look like it 2018-11-10 19:43:32 <^7heo> $ apk version claws-mail 2018-11-10 19:43:32 <^7heo> Installed: Available: 2018-11-10 19:43:32 <^7heo> claws-mail-3.17.1-r2 > 3.17.1-r1 @community 2018-11-10 19:43:45 <^7heo> $ claws-mail 2018-11-10 19:43:45 <^7heo> Error relocating /usr/bin/claws-mail: mailstream_ssl_set_server_name: symbol not found 2018-11-10 19:43:48 <^7heo> so still. 2018-11-10 19:43:51 <^7heo> but it's updated. 2018-11-10 19:44:01 <^7heo> problem is, it's missing the lib 2018-11-10 19:44:07 the maintainer is ncopa 2018-11-10 19:44:07 <^7heo> somehow it does not find it 2018-11-10 19:44:11 <^7heo> yeah I've seen 2018-11-10 19:44:45 https://github.com/dinhviethoa/libetpan/blob/ee87746075c597385bc552ce4f0365476a919d32/src/data-types/mailstream_ssl.c#L1376 there it is 2018-11-10 19:45:30 <^7heo> libetpan has no symbols in it, is that normal? 2018-11-10 19:45:51 <^7heo> apparently so do a lot of other libs, so it must be. 2018-11-10 19:46:35 <^7heo> oh sorry, I was looking for the wrong symbols. 2018-11-10 19:47:10 <^7heo> $ objdump -T /usr/lib/libetpan.so.20.1.0 | grep mailstream_ssl_set_server 2018-11-10 19:47:10 <^7heo> 0000000000030281 g DF .text 0000000000000004 Base mailstream_ssl_set_server_certicate 2018-11-10 19:47:13 <^7heo> that's the only one. 2018-11-10 19:47:16 <^7heo> so there's your problem. 2018-11-10 19:47:29 <^7heo> I mean, mine, but also, yours :P 2018-11-10 19:48:08 <^7heo> I gotta check that lib. 2018-11-10 19:49:02 looks like the etpan shipped with it lacks that function 2018-11-10 19:49:10 <^7heo> indeed. 2018-11-10 19:49:46 <^7heo> https://git.alpinelinux.org/cgit/aports/tree/main/libetpan/0002-Tls-server-name-indication-support.patch?id=b4e3d00524860b10b276f992f87f5db7e47860bf 2018-11-10 19:49:50 <^7heo> yet it's supposed to have it? 2018-11-10 19:50:23 oh right, it's depending on a pre-patched etpan, nevermind 2018-11-10 19:50:23 <^7heo> could you please recompile that? :) 2018-11-10 19:50:36 <^7heo> ? 2018-11-10 19:50:45 <^7heo> what do you mean? 2018-11-10 19:51:38 <^7heo> I don't see the body of the function in the patch btw 2018-11-10 19:51:59 it's using that github repo I linked earlier 2018-11-10 19:52:09 <^7heo> it is 2018-11-10 19:52:13 <^7heo> ah you mean the build is. 2018-11-10 19:53:18 <^7heo> I find it weird that the patch has the function definition but not the source. 2018-11-10 19:54:28 it's in there, etpan 3.8 2018-11-10 19:55:32 <^7heo> I got the one from edge 2018-11-10 19:55:40 <^7heo> I'll get it from stable 2018-11-10 19:56:26 this is the edge one 2018-11-10 19:57:39 <^7heo> wait, are you saying that there is the symbol in the one from edge? 2018-11-10 19:58:44 it has mailstream_ssl_set_server_certicate and _name 2018-11-10 19:59:01 <^7heo> version 1.8-r2? 2018-11-10 19:59:08 <^7heo> that's the one I have... 2018-11-10 19:59:19 <^7heo> and it definitely has no _name 2018-11-10 19:59:39 <^7heo> check the one in http://nl.alpinelinux.org/alpine/edge/main 2018-11-10 19:59:47 http://tpaste.us/0LNy 2018-11-10 20:00:06 <^7heo> http://nl.alpinelinux.org/alpine/edge/main/x86_64/libetpan-1.8-r2.apk 2018-11-10 20:00:25 <^7heo> wtf. 2018-11-10 20:00:34 <^7heo> check the apk I sent you. 2018-11-10 20:01:37 0000000000033787 g DF .text 000000000000003b Base mailstream_ssl_set_server_name 2018-11-10 20:01:40 <^7heo> yeah 2018-11-10 20:01:45 <^7heo> my point entirely. 2018-11-10 20:01:51 <^7heo> could you please send me your binary? 2018-11-10 20:02:17 I didn't patch it, I just compiled it by hand - and cleaned the temporary directory 2018-11-10 20:02:26 <^7heo> yeah but I use the same platform as you 2018-11-10 20:02:35 <^7heo> so I could just use your shared object 2018-11-10 20:02:40 <^7heo> without touching a package or something 2018-11-10 20:02:43 <^7heo> just replacing the file 2018-11-10 20:03:23 I need to finish something I'm working on before recompiling and all that, you could do it locally if you have the processor to 2018-11-10 20:03:30 + to compile 2018-11-10 20:03:50 <^7heo> nah I'm saying 2018-11-10 20:03:57 <^7heo> could you upload your shared object directly? :) 2018-11-10 20:04:02 <^7heo> no recompiling, nothing 2018-11-10 20:04:10 I cleaned (removed) it so I'd need to recompile 2018-11-10 20:04:23 <^7heo> ah damn 2018-11-10 20:04:25 <^7heo> ok :P 2018-11-10 20:04:27 <^7heo> sorry then 2018-11-10 20:04:31 <^7heo> I can try to compile it I guess. 2018-11-10 20:04:43 probably easier to have someone more familiar with that look into it 2018-11-10 20:04:57 broken ABIs can require some digging around 2018-11-10 20:05:38 <^7heo> do you know how to force a version number with apk fix? 2018-11-10 20:05:40 <^7heo> or apk add? 2018-11-10 20:06:01 you use abuild with the APKBUILD file, you can bump version numbers in the package description file (APKBUILD) 2018-11-10 20:06:04 pkgver/pkgrel 2018-11-10 20:06:42 <^7heo> I'm asking how I replaced the claws-mail you provided with the one from the repo 2018-11-10 20:06:53 I incremented pkgrel by one 2018-11-10 20:06:55 <^7heo> i.e. downgrade it :) 2018-11-10 20:06:59 <^7heo> yeah 2018-11-10 20:07:00 <^7heo> I know 2018-11-10 20:07:02 <^7heo> how do I go back? 2018-11-10 20:07:08 uh, you could `apk del` it 2018-11-10 20:07:10 <^7heo> without deleting the package 2018-11-10 20:07:14 hm 2018-11-10 20:07:14 <^7heo> obviously :P 2018-11-10 20:08:26 to get the one from the repo, you could apk add packagename=1.2.3 2018-11-10 20:09:39 i.e. apk add libetpan=1.8-r1 or whatever it was 2018-11-10 20:09:47 <^7heo> damn 2018-11-10 20:09:50 <^7heo> no space left on drive 2018-11-10 20:09:51 <^7heo> ffs 2018-11-10 20:09:55 jeez 2018-11-10 20:09:58 <^7heo> yea 2018-11-10 20:10:04 <^7heo> updating aports did that 2018-11-10 20:10:31 aports is 222M, mine *should* be clean 2018-11-10 20:10:58 <^7heo> it's fine I deleted some mr robot 2018-11-10 20:11:03 <^7heo> s/some/all/ 2018-11-10 20:11:06 <^7heo> but all good. 2018-11-10 20:11:23 <^7heo> compiling 2018-11-10 20:13:09 <^7heo> symbol there. 2018-11-10 20:13:19 <^7heo> the package in the repo I pointed is broken 2018-11-10 20:13:31 <^7heo> ncopa: http://nl.alpinelinux.org/alpine/edge/main/x86_64/libetpan-1.8-r2.apk is broken 2018-11-10 20:13:37 god, what a pain 2018-11-10 20:14:16 <^7heo> yeah 2018-11-10 20:14:20 <^7heo> it works now. 2018-11-10 20:14:27 <^7heo> had to delete some stuff 2018-11-10 20:14:30 <^7heo> but it works. 2018-11-10 20:14:40 <^7heo> if only there was correct QA :P 2018-11-10 20:15:48 <^7heo> so, now, what was the other problem? 2018-11-10 20:15:51 <^7heo> ah yeah USB subsystem 2018-11-10 20:17:12 we can discuss that in #alpine-linux 2018-11-10 20:22:22 <^7heo> what? The USB thing? 2018-11-10 20:22:29 mhm 2018-11-10 20:22:35 not sure it's a -devel thing 2018-11-10 20:22:40 <^7heo> not sure either. 2018-11-10 20:22:46 <^7heo> the claws-mail thing definitely was. 2018-11-10 20:22:52 <^7heo> but now that's solved. 2018-11-10 20:23:00 <^7heo> or, reported, solved on my end. 2018-11-11 17:59:51 <_ikke_> I try to compile a package, but it fails with this message from boost: "error: #error Boost.Numeric.Interval: Please specify rounding control mechanism.". It appears that because __USE_ISOC99__ is not defined, it falls through. Is there any trivial way to fix this? 2018-11-11 18:00:37 <_ikke_> https://github.com/Gecode/gecode/blob/master/gecode/third-party/boost/numeric/interval/hw_rounding.hpp#L20 2018-11-11 18:04:25 <_ikke_> https://gcc.gnu.org/ml/gcc/2002-09/msg00580.html 2018-11-11 18:08:39 <_ikke_> Should I just patch out the __USE_ISOC99__? 2018-11-11 18:09:57 _ikke_: looking at the source, I'd try replacing the && with || (both on that line and 36) 2018-11-11 18:10:16 because on 22 they show that they're willing to do that with, say, the borland compiler 2018-11-11 18:10:49 <_ikke_> SpaceToast: I think 36 would be redundant 2018-11-11 18:10:57 <_ikke_> both include the same file iirc 2018-11-11 18:11:36 yeah, but it should make the patch less confusing - the intent is to imply that x86_64 doesn't require ISOC99 2018-11-11 18:11:56 <_ikke_> Would it cause issues if the same file is required twice? 2018-11-11 18:12:09 not in well-written code 2018-11-11 18:12:14 (which has header guards of pragma once) 2018-11-11 18:12:18 s/of/or/ 2018-11-11 18:12:22 <_ikke_> It has guards indeed 2018-11-11 18:12:33 then it should be fine, and cover non-x86_64 cases too 2018-11-11 18:12:42 it would make sense to check c99_rounding_control.hpp for any other ISOC99 "requirements" though 2018-11-11 18:12:46 (and obviously test the package afterwards 2018-11-11 18:12:56 <_ikke_> yes, they do have a test suite 2018-11-11 18:13:21 <_ikke_> No extra checks inside those headers 2018-11-11 18:13:36 <_ikke_> SpaceToast: thanks 2018-11-11 18:14:06 _ikke_: looking at the file that'll get included, I don't think there should be any issues :) 2018-11-11 18:14:18 <_ikke_> SpaceToast: alright, thanks 2018-11-11 18:14:19 looks like whoever wrote the include-header just expected ISOC99 to always be present because of silly gcc people 2018-11-11 18:14:25 <_ikke_> heh 2018-11-11 18:14:54 after a few years with clang/musl, it's incredible just *how many* people rely on gcc/glibc internals 2018-11-11 18:15:24 <_ikke_> yes, because it's a defacto standard 2018-11-11 18:16:05 well, the thing with relying on internals is... you're not supposed to (a common example is sys/cdefs.h - that's for internal usage, but people like #include ing it for some reason) :/ 2018-11-11 18:16:12 <_ikke_> if I change the && to || on line 36, it means it will always use that, right? 2018-11-11 18:16:49 if you change && to || it mans it will use that if GECODE_BOOST_NUMERIC_INTERVAL_NO_HARDWARE is defined, ISOC99 is defined, or MSL is defined 2018-11-11 18:17:01 because of line 17 looks like it'll always get used though 2018-11-11 18:17:07 <_ikke_> Yes, that's what I meant 2018-11-11 18:17:24 actually no 2018-11-11 18:17:32 <_ikke_> The included files undef it 2018-11-11 18:17:33 because all of the detail/ files you include *undefine* that 2018-11-11 18:17:35 <_ikke_> yes 2018-11-11 18:17:39 <_ikke_> THat's what I expected 2018-11-11 18:17:51 so that's just in the scenario where nothing is caught, it wants to default to C99 2018-11-11 18:17:52 <_ikke_> But I mean, if non of the earlier clauses match 2018-11-11 18:18:08 <_ikke_> can that cause issues? 2018-11-11 18:18:15 <_ikke_> it means that error is now useless 2018-11-11 18:19:01 hmm... that's true, but looking at the c99 rounding method, it seems like it was intended as a general "fallback" 2018-11-11 18:19:09 the author likely expected C99 to *always* be defined 2018-11-11 18:19:22 so I guess you could remove the ISOC99 sections in general 2018-11-11 18:19:54 <_ikke_> ok 2018-11-11 18:20:37 hmm, it looks like the first whole section is a hardware selection thing with x86_64 getting the cold shoulder, I think it might help to know what __MSL__ is 2018-11-11 18:21:33 <_ikke_> something microsoft related? 2018-11-11 18:21:58 searching (for the 20 seconds I put into it) didn't reveal anything (except that apple mentioned it at some point?) 2018-11-11 18:22:44 maybe microsoft, but either way, the c99 rounding method seems like it's meant to be a general fallback in case hardware acceleration isn't available 2018-11-11 18:22:55 <_ikke_> SpaceToast: I could probably remove the __APPLE__ part on line 20, right? 2018-11-11 18:23:29 <_ikke_> That line implies that when it;s x68_64, it could be either __ISO_C99__ or __APPLE__ 2018-11-11 18:23:45 __APPLE__ means *any* apple computer 2018-11-11 18:23:55 I'm not sure if this includes the older ppc ones 2018-11-11 18:24:13 <_ikke_> In this case, it's only relevant if it's x86_64 2018-11-11 18:24:34 && and || is right-associative? (I legitimately don't recall) 2018-11-11 18:24:42 <_ikke_> There are () 2018-11-11 18:24:48 oh! indeed there are 2018-11-11 18:25:06 ok, I'd just have that line be if defined(__x86_64__) then, yeah 2018-11-11 18:26:16 <_ikke_> http://tpaste.us/aRQb 2018-11-11 18:27:08 ok, looks good to me 2018-11-11 18:27:35 main side effect I can see is a weird compiler that defines __x86_64__ and __i386__ together and misses out on x86 acceleration 2018-11-11 18:27:47 also still wonder what __MSL__ is (microsoft's predefined macro page doesn't list it...) 2018-11-11 18:28:01 <_ikke_> I have no idea 2018-11-11 18:28:03 mainly because it's separate from the rest of the arch-specific selections, and thus pops out for me 2018-11-11 18:28:08 <_ikke_> yea\ 2018-11-11 18:28:46 anyway, if it passes tests like that I think it should be fine (even if some magical compiler-architecture combos might be a bit slower) 2018-11-11 18:30:26 <_ikke_> Let's see if it builds now 2018-11-11 18:32:55 <_ikke_> it does :-) 2018-11-11 18:32:57 <_ikke_> thanks for your help 2018-11-11 18:33:59 \o/ 2018-11-11 18:34:40 <_ikke_> running the test suite now 2018-11-11 18:40:27 <_ikke_> hmmm "Error loading shared library libgecodeflatzinc.so.48: No such file or directory (needed by test/test)" 2018-11-11 18:40:34 <_ikke_> and a lot more errors 2018-11-11 18:41:09 is this a new package, or a version bump? 2018-11-11 18:41:19 <_ikke_> new package 2018-11-11 18:41:23 <_ikke_> that's from the test suite 2018-11-11 18:41:34 <_ikke_> I compiled the test suite, and now trying to run it 2018-11-11 18:41:58 <_ikke_> that lib is located one directory higher 2018-11-11 18:42:07 <_ikke_> so it might expect that the libary is installed? 2018-11-11 18:42:21 maybe 2018-11-11 18:42:32 looks like that repo has both cmake and autotools support, can you try using whatever is the one you're not right now? 2018-11-11 18:42:59 <_ikke_> just run ./configure --prefix=/usr && make && make test 2018-11-11 18:43:01 (it sometimes happens that a project doesn't purge their old build system, until it completely fails to build) 2018-11-11 18:43:28 <_ikke_> I cleaned all files and redownloaded them (with abuild) 2018-11-11 18:43:31 <_ikke_> so it should be a clean slate 2018-11-11 18:44:49 let me see what happens if I do that by hand (with cmake) 2018-11-11 19:01:38 _ikke_: just had tests pass (or, rather single test), but I had to do some funny things to it, can you send me your current APKBUILD and I'll try to poke around? 2018-11-11 19:25:01 <_ikke_> ok 2018-11-11 19:25:18 <_ikke_> http://tpaste.us/qKM4 2018-11-11 19:25:21 <_ikke_> You have the patch file 2018-11-11 19:27:19 alright, ty 2018-11-11 19:27:33 it might take a bit though, my build server is a singlecore, and is hosting other stuff ^^;; (including irc) 2018-11-11 19:27:55 I'll ping you whenever I have it (I'll just get build() and check() going) 2018-11-11 19:28:38 <_ikke_> sure, no worry 2018-11-11 19:28:42 <_ikke_> thanks for your effort 2018-11-11 20:08:05 <_ikke_> Hmm, now running into erlang issues :( 2018-11-11 20:08:21 _ikke_: erlang issues? 2018-11-11 20:08:23 what's the context here? 2018-11-11 20:08:39 <_ikke_> trying to get chef compiled :) 2018-11-11 20:08:47 what are the erlang issues? 2018-11-11 20:08:59 <_ikke_> It tries to compile bear, a dependency 2018-11-11 20:09:14 <_ikke_> Error: _build/default/lib/bear/src/bear.erl:none: internal error in native_compile; crash reason: undef 2018-11-11 20:09:31 ouch, mind sharing the apkbuild? 2018-11-11 20:09:43 I'll have a look at it 2018-11-11 20:09:43 <_ikke_> sure, hold on 2018-11-11 20:10:00 isn't bear that abandoned thing from 2014? 2018-11-11 20:10:06 stange that chef (ruby) uses it 2018-11-11 20:10:08 <_ikke_> someone took it over 2018-11-11 20:10:13 ah 2018-11-11 20:10:16 <_ikke_> https://github.com/folsom-project/bear 2018-11-11 20:10:20 also something something I don't like chef 2018-11-11 20:10:25 mm 2018-11-11 20:10:26 https://hex.pm/packages/bear 2018-11-11 20:10:28 <_ikke_> https://github.com/boundary/bear/issues/25 2018-11-11 20:10:42 <_ikke_> SpaceToast: Why don't you like chef 2018-11-11 20:10:44 <_ikke_> ? 2018-11-11 20:11:00 I've used chef, I don't really mind it that much, except it running on ruby 2018-11-11 20:11:00 I find it to be a bundle of verbose complexity 2018-11-11 20:11:03 ansible is <3 2018-11-11 20:11:05 similar issues to puppet 2018-11-11 20:11:14 salt isn't really the same thing, and ansible has too much magic 2018-11-11 20:11:28 and you can't use rex because their docs don't exist so you need to have a literal developer on your team 2018-11-11 20:11:28 <_ikke_> I've used salt, puppet and chef 2018-11-11 20:11:32 yeah, the magic *can* be annoying 2018-11-11 20:11:34 try out ansible :) 2018-11-11 20:11:43 it's the least-bad-option out there, as far as I'm concerned 2018-11-11 20:11:46 <_ikke_> Not sure if my mind can handle anoter option 2018-11-11 20:11:52 I've used all four over the years 2018-11-11 20:11:55 <_ikke_> I use chef @ work 2018-11-11 20:12:02 (I keep wanting to write my own but the type of work is kind of awful) 2018-11-11 20:12:03 <_ikke_> So I'm familair with it 2018-11-11 20:12:07 mhm 2018-11-11 20:12:22 I got $work to migrate from a broken (and breaking-other-things) puppet setup to ansible 2018-11-11 20:12:27 (mostly because I was the only one working on it) 2018-11-11 20:12:44 <_ikke_> We still have a puppet server running, but slowly migrating it to chef 2018-11-11 20:13:22 I definitely prefer chef to puppet, but I don't really like either :/ 2018-11-11 20:13:35 <_ikke_> Puppet has some nice things over it 2018-11-11 20:13:36 anyway, good luck with erlang! 2018-11-11 20:13:40 anyway, pass me the apkbuild whenever you have time 2018-11-11 20:13:45 I've written a ton of erlang, and used it a lot 2018-11-11 20:14:09 I only really have exposure to elixir 2018-11-11 20:14:17 it's a great language, it's just a shame it's very domain-specific 2018-11-11 20:15:17 <_ikke_> danieli: http://tpaste.us/NKRq 2018-11-11 20:15:53 <_ikke_> gecode is a dependency I've also just packaged 2018-11-11 20:16:15 <_ikke_> http://tpaste.us/qKM4 + http://tpaste.us/aRQb 2018-11-11 20:16:35 aye, I'm getting check() to run reliably atm 2018-11-11 20:16:57 looks like both the configure script and cmake are broken, but cmake seems easier to fix, trying to test that right now 2018-11-11 21:01:00 _ikke_: alright, I have it working, three pastes incoming (feel free to edit the cmake one, I was lazy and just used git diff; it should also probably be pushed upstream, everything is *just* broken) 2018-11-11 21:02:28 _ikke_: APKBUILD: http://sprunge.us/U16FZh ; fix-boost-hw-detection.patch: http://sprunge.us/56G01P (unmodified) ; fix-cmake-test-bin-detection.patch: http://sprunge.us/JyPXnR 2018-11-11 21:02:38 successfully builds and passes tests 2018-11-11 21:02:51 (I also fixed a typo in the description because it was making my head hurt) 2018-11-11 21:04:34 <_ikke_> SpaceToast: Thanks! 2018-11-11 21:04:40 nw, tc ^^ 2018-11-11 21:04:51 oh, you might want to add cmake to makedepends though 2018-11-11 21:04:59 sorry I forgot (I was planning to spend today mostly resting ^^;;) 2018-11-11 21:05:03 gonna go do that now though \o 2018-11-11 23:40:10 hi, anyone who knows how much space i need for an alpine mirror? i will get a 320GB server with unlimited traffic tomorrow and would like to set up a mirror for alpine... ;) 2018-11-11 23:40:29 there is an wiki page for that afaik 2018-11-11 23:40:30 <_ikke_> hanez: depends what versions you want 2018-11-11 23:41:07 oh, it should be a usable public mirror... don't know what you would recommend... 2018-11-11 23:41:42 <_ikke_> All versions would be 400GB 2018-11-11 23:42:14 okay 2018-11-11 23:42:31 makes it sense to provide a mirror though? 2018-11-11 23:44:11 <_ikke_> hanez: http://dl-3.alpinelinux.org/alpine/ serves only recent versions 2018-11-11 23:44:37 <_ikke_> That would be ~230GB 2018-11-11 23:44:44 okay, is there interest in such a mirror? 2018-11-11 23:44:48 if it has a lot of bandwidth available, or serves a region where we have few mirrors, sure 2018-11-11 23:45:00 if not, we could add it if it's stable and has a fair amount of bandwidth 2018-11-11 23:45:24 danieli: i am in germany... but 230GB is my whole disk. then i need to get another machine for that 2018-11-11 23:45:36 danieli: it will be 100Mbit 2018-11-11 23:45:38 wait.. you want to serve a mirror off your regular computer? 2018-11-11 23:45:43 NO! 2018-11-11 23:45:49 in a datacenter 2018-11-11 23:46:05 :) 2018-11-11 23:46:18 <_ikke_> We have 3 mirrors in Germany 2018-11-11 23:46:36 <_ikke_> Falkenstein, Esslingen and Aachen 2018-11-11 23:46:57 but as i can see i have not enough disk space for now. i will order more and will then come back, okay? 2018-11-11 23:47:06 <_ikke_> sure 2018-11-11 23:47:09 :) 2018-11-11 23:47:38 <_ikke_> edge is current 80GB 2018-11-11 23:47:53 but makes it sense to just mirror edge? 2018-11-11 23:48:14 <_ikke_> At least one stable version would make ense 2018-11-11 23:48:36 okay, then maybe latest and edge 2018-11-11 23:48:51 <_ikke_> ~150GB 2018-11-11 23:49:17 <_ikke_> alpine is growing a lot :-) 2018-11-11 23:49:23 okay, that would be possible... i will play around with it and then we will see if everything works 2018-11-11 23:49:26 yeah 2018-11-11 23:49:30 if you need a mirror or really want to provide a mirror, you could 2018-11-11 23:49:40 that's really a big package base 2018-11-11 23:49:54 danieli: i don't need one. i want to provide 2018-11-11 23:50:17 <_ikke_> Well, freel free :-) 2018-11-11 23:50:23 <_ikke_> -r 2018-11-11 23:50:31 :) 2018-11-12 13:10:20 hi 2018-11-12 13:11:57 i want to run alpine on orange-pi zero. but failed to start with debians uboot. alpines ubbot not starts) 2018-11-12 14:22:50 alex_eri: #alpine-linux 2018-11-12 14:22:53 this is the development channel 2018-11-12 14:37:11 fcolista, https://github.com/alpinelinux/aports/pull/5627 needs your approval 2018-11-12 14:40:08 wondering why I don't get notifications ... 2018-11-12 14:41:15 thx andypost 2018-11-12 14:41:19 merged 2018-11-12 14:41:20 hm, really strange... 2018-11-12 14:41:37 yes 2018-11-12 14:43:44 fcolista, then probably you missed the https://github.com/alpinelinux/aports/pull/5442 as well 2018-11-12 14:44:36 looks that GH issue, cos PR is not closed still by bot 2018-11-12 14:46:58 that patch should have $pkgname in nginx() depends, and subpackage too should have $pkgname-nginx:nginx 2018-11-12 14:47:39 moreover, due to the fact that I didn't get any notification, I upgraded to 0.28.0 2018-11-12 14:47:43 so this patch does not apply 2018-11-12 14:49:50 PR commented. 2018-11-12 14:50:03 Now need to check why I'm not notified.. 2018-11-12 14:55:34 @danieli, adding device support is more development issue 2018-11-12 15:31:21 fcolista: may I use the opportunity to ask if you can please check https://github.com/alpinelinux/aports/pull/5511 as well? Seems to be the same case of missing notifications. 2018-11-12 15:40:39 Myhro, 5511 does not build 2018-11-12 15:40:42 !!! [1112 15:40:09] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...) 2018-11-12 15:40:42 !!! [1112 15:40:09] Call tree: 2018-11-12 15:40:42 make: *** [Makefile:92: all] Error 1 2018-11-12 15:40:42 !!! [1112 15:40:09] 1: hack/make-rules/build.sh:27 kube::golang::build_binaries(...) 2018-11-12 15:40:42 >>> ERROR: kubernetes: build failed 2018-11-12 15:40:43 >>> kubernetes: Uninstalling dependencies... 2018-11-12 15:42:20 wut... I just rebased it to make it build on Travis CI. I'll check it again. 2018-11-12 16:03:11 Yup, wasn't able reproduce it here (clean x86_64 alpine:edge container) nor in Travis CI. 2018-11-12 16:07:26 Is your local branch rebased against the current master? It was failing on Travis CI earlier today because of that. 2018-11-12 17:33:40 Hi , I'm on 3.81 x64 edge everything fine. except : a) rofi would be perfect .has anybody running it (i couldnt compile it )? cant find a gtkonly clipboardmanager :clipit ,parcellite etc ( manual compile doesnt work,clipit works under sabotage ,which is also musl libressl but sourcebased) .C) cant force to delete package eg :when alpine-sdk is installed ,to delete only openssl ,even when alpine-sdk pulls it as dependency ... thanks 2018-11-12 17:34:44 jgdjhd: this may be more appropriate in #alpine-linux, this is the development channel 2018-11-12 17:35:53 sorry,just my list didnt show that channel . is that on freenode too ? 2018-11-12 17:36:17 yes, you can simply /join it 2018-11-12 17:36:28 great thanks :) 2018-11-12 17:59:42 Myhro, 5511 got the same failure, but I'm trying in docker, now started test on aarch64 2018-11-12 18:04:00 andypost: Thanks for checking it. The problem is that I can't reproduce it on my (containerized) build environment. Looks like Travis CI is similar. I'll try on a clean VM on EC2 or VirtualBox. 2018-11-12 18:12:32 <_ikke_> Myhro: thank you for taking care of fzf :-)( 2018-11-12 18:15:54 _ikke_: You are welcome. I'm kinda "fixings bugs that annoys me". :-) 2018-11-12 18:16:14 I'm gonna do that once I get alpine running as a daily driver 2018-11-12 18:16:31 it'll improve the experience a lot when you can feel that devs actually use the OS themselves 2018-11-12 18:16:41 <_ikke_> nod 2018-11-12 18:16:48 <_ikke_> you have a lot more itches to scratch 2018-11-12 18:16:56 Myhro, looks it depends on env (RAM at least) https://github.com/alpinelinux/aports/pull/5511#issuecomment-437973940 2018-11-12 18:16:59 yeah, and I use my computers for a lot of things 2018-11-12 18:17:07 right now, I'm running OpenBSD and Arch on my workstations (as daily drivers) 2018-11-12 18:17:15 I'm mostly scratching shell/server itches as of currently 2018-11-12 18:17:57 I'm too accustomed to plasma5 (and a few other non-trivially portable things) right now to switch more user-facing things, but at some point it could happen :) 2018-11-12 18:20:46 andypost: That's interesting. My development box has 32GB, so that's why I haven't seen something similar. Looks like Travis has 4-7.5GB depending on the Ubuntu release: https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system 2018-11-12 18:22:17 danieli: I must shamely admit that my daily laptop is a macOS, but my development box is an Alpine Linux. It's kinda funny to do my entire Alpine development workflow through SSH + WireGuard. 2018-11-12 18:22:48 I'm pretty used to living in the CLI 2018-11-12 18:24:12 Me too, just not a remote CLI. Took me a while to get a sub-30ms latency dedicated server - had to move between continents. It's not funny to use vim over SSH on a 250-300ms line. 2018-11-12 18:24:45 jeez, yeah, it does make a difference 2018-11-12 18:24:52 I've been on poor satlinks and I *had* to use mosh 2018-11-12 18:26:22 <_ikke_> I'm spoilt with 12ms latency 2018-11-12 18:26:45 The only time I had to use satlinks was to manage some Windows servers... I quite the job a while after that. Not a healthy way of working. 2018-11-12 18:27:15 quit* 2018-11-12 18:37:05 im trying to debug a segfault in mpv, how do i tell abuild to not strip the binaries? 2018-11-12 18:38:41 <_ikke_> AinNero: make a dbg subpackage 2018-11-12 18:38:46 <_ikke_> $pkgname-dbg 2018-11-12 18:38:58 there's also !strip iirc 2018-11-12 18:39:03 but yeah ^ 2018-11-12 18:41:38 i did both 2018-11-12 18:41:48 lets home valgrind will find it 2018-11-12 18:42:21 firefox & youtubel is also broken for me, if i cant fix this, i wont be able to procrastinate on youtube 2018-11-12 18:42:39 <_ikke_> haha 2018-11-12 18:42:39 you don't happen to be on edge? 2018-11-12 18:42:45 ye, edge 2018-11-12 18:42:49 <_ikke_> procrastrinating so you can procrastrinate 2018-11-12 18:43:00 stuff breaking isn't really a big surprise in that case 2018-11-12 18:43:48 <_ikke_> danieli: no rush, did you had any chance to look at chef/erlang? 2018-11-12 18:44:01 oh man, no, I've been super busy today 2018-11-12 18:44:07 I'll try building it in a sec 2018-11-12 18:45:28 _ikke_: everything working alright with gecode (or whatever that package was)? 2018-11-12 18:45:35 <_ikke_> was just looking at it 2018-11-12 18:45:55 the cmake patch should ideally be upstreamed 2018-11-12 18:46:01 their current setup shouldn't work... anywhere 2018-11-12 18:46:59 <_ikke_> Could you give a little background on what is broken (so I could explain it to them)? 2018-11-12 18:49:55 CTest looks in specific directories by default 2018-11-12 18:50:04 locations like Release/ and such (I forget the right variable name) 2018-11-12 18:50:23 they're compiling their test executable as not-a-test-executable, and are placing it in a custom directory, *without* telling CTest where to find it 2018-11-12 18:50:36 <_ikke_> ok 2018-11-12 18:50:39 the patch simply tells CTest that "this test binary will be in this location" (which is the location they set as the one to put it into) 2018-11-12 18:50:55 Release and Debug 2018-11-12 18:51:00 <_ikke_> And the -test params? 2018-11-12 18:54:08 the !strip option did not seem to have an effect, but i got an mpv.debug file now, but not sure how to feed it into valgrind 2018-11-12 18:55:22 oh, those are verbatim '-'s 2018-11-12 18:55:27 my patch *just* adds the ${} 2018-11-12 18:55:31 single-word patch :) 2018-11-12 18:55:42 see https://github.com/Gecode/gecode/blob/master/CMakeLists.txt (current state, at the bottom) 2018-11-12 18:56:31 <_ikke_> ah sure 2018-11-12 18:56:48 <_ikke_> 100% tests passed, 0 tests failed out of 1 2018-11-12 18:57:03 <_ikke_> hmm, no target to make install 2018-11-12 18:57:21 yeah, CTest counts each binary as a single test, no matter how many tests the binary contains 2018-11-12 18:57:42 <_ikke_> what was the cmake install method again 2018-11-12 18:58:02 make install is it :/ 2018-11-12 18:58:18 both their cmake and autotools configure methods were broken, cmake was just easier to fix to get things to compile (fully, test included) and pass testing 2018-11-12 18:58:39 <_ikke_> right, but apparently it does not have an install target :-/ 2018-11-12 18:58:40 I do wonder how upstream actually builds/tests their packages, this considered ^^;; 2018-11-12 18:58:43 <_ikke_> heh 2018-11-12 18:58:51 yeah, the CMakeLists.txt doesn't specify what to install :D 2018-11-12 18:59:09 and their "install-sh" script is from 2005! 2018-11-12 19:15:11 is there an metapackage for debug symbols? 2018-11-12 19:38:46 debug symbols for what? 2018-11-12 19:39:00 everything 2018-11-12 19:39:19 analoguous to 'docs' 2018-11-12 19:39:33 oh, we have a meta for docs? TIL 2018-11-12 19:39:35 <_ikke_> most packages don't have debug symbos built 2018-11-12 19:39:35 nice 2018-11-12 19:39:56 finally my daily driver laptop will be useful haha 2018-11-12 21:26:41 Hello! I tried to register to bugs.alpinelinux.org but I did not receive the activation email. 2018-11-12 21:27:18 <_ikke_> jacknite_: if you pm your nickname there, I can take a look 2018-11-12 22:51:36 yay, the new machine that will become an alpine mirror is up and running... and so fast... it's alpine... \o/ 2018-11-12 22:56:07 I've been playing with the GStreamer webrtc demo. The required webrtcbin plugin is currently not built but it does show up when I add libnice-dev to makedepends. 2018-11-12 22:58:08 That's in community/gst-plugins-bad. If this makes sense I can enter a feature request... 2018-11-12 23:11:29 what's the basics required to bootstrap alpine on a new architecture? 2018-11-12 23:22:36 _ikke_: which mirror shoud i use as master? rsync.alpinelinux.org seems to be very slow... 2018-11-12 23:23:00 master mirror for syncing? 2018-11-12 23:23:22 you should use dl-t1-1.alpinelinux.org or dl-t1-2.alpinelinux.org 2018-11-12 23:23:27 danieli: yes... or call it primary 2018-11-12 23:23:28 i should update the wiki for that 2018-11-12 23:23:36 we're in the progress of migrating people to use that instead 2018-11-12 23:23:38 ok, thanks 2018-11-12 23:24:18 also, please use #alpine-infra for infrastructure related stuff 2018-11-12 23:24:22 :) 2018-11-12 23:27:51 okay... sorry 2018-11-12 23:28:07 :) 2018-11-12 23:28:58 no worries 2018-11-12 23:29:37 the second works but the first one is slow too (1Mbit) 2018-11-12 23:29:58 the second: 72MBits 2018-11-12 23:30:35 s/72/720/ 2018-11-12 23:33:23 dl-t1-1 gives 1 Mbps? 2018-11-12 23:35:31 for me, aes 2018-11-12 23:35:33 yes 2018-11-12 23:35:39 odd 2018-11-12 23:35:47 maybe there is traffic actually 2018-11-13 07:52:44 danieli, ppl should use rsync.a.o 2018-11-13 07:53:15 <_ikke_> it's a dns round-robin right? 2018-11-13 07:53:22 yes sir 2018-11-13 07:53:37 they are both 20Gbit 2018-11-13 07:53:47 <_ikke_> so people should have no issues syncing from it 2018-11-13 07:54:05 if we did our jobs correct, it should be good. 2018-11-13 07:54:26 1mbit sounds weird. 2018-11-13 08:04:31 dl-t1-2 is avg 100Mbytes/s 2018-11-13 08:04:55 dl-t1-1 is avg 30Mbytes/s 2018-11-13 08:05:11 from amsterdam 2018-11-13 08:07:49 <_ikke_> hanez: where are you downloading from? 2018-11-13 08:17:21 neat-o, rsync used to be an alias to cz/master, but not anymore ig 2018-11-13 08:17:23 I'm a tad forgetful 2018-11-13 08:18:06 _ikke_: iirc they said a server (probably a fairly small dedi/vps) in DE 2018-11-13 09:41:29 _ikke_: i downloaded from dl-t1-1.alpinelinux.org or dl-t1-2.alpinelinux.org. the first one was very slow yesterday the second one was really fast 2018-11-13 09:42:26 my servers are near mannheimm in germany... 2018-11-13 10:16:55 hanez, one is in us and one is in nl 2018-11-13 10:17:03 so you best bet would be the one in nl 2018-11-13 10:17:36 i am using dl-t1-2 now 2018-11-13 10:18:11 what you prefer 2018-11-13 10:18:22 its not supported to use it. 2018-11-13 10:18:31 rsync.a.o is 2018-11-13 10:18:39 worked nice... i will setup the cron job after work and will then test it for some time... i will then announce it to the mailinglist when ithink it could be used public 2018-11-13 10:18:50 we will not announce if we change things related to t1 mirrors. 2018-11-13 10:19:33 hanez, please do not announce it. 2018-11-13 10:19:42 okay... so which one should i use or am i misunderstanding somethin what do you mean with rsync.a.o? 2018-11-13 10:19:45 if you want to use a local mirror choose one from mirrors.a.o 2018-11-13 10:19:58 i want to create a public mirror... 2018-11-13 10:20:26 if you want to rsync from a local mirror get one from the list on mirrors.alpinelinux.org 2018-11-13 10:20:37 else only use rsync.alpinelinux.org 2018-11-13 10:20:42 thought i could give something back to the community 2018-11-13 10:20:45 hm, ok 2018-11-13 10:21:07 you can, but please follow procedure. 2018-11-13 10:21:55 i do not understand what i did wrong 2018-11-13 10:22:21 i dont understand what you dont understand. 2018-11-13 10:22:31 the information given to you about the t1 mirrors is incorrect. 2018-11-13 10:22:53 dont use them, even if they work now. 2018-11-13 10:23:01 ah, ok... danieli said i shoud use them 2018-11-13 10:23:17 yes and im saying you should not :) 2018-11-13 10:24:06 i will switch to rsync.alpinelinux.org then 2018-11-13 10:24:11 if you want to do a fast init rsync, you can grab one from the mirrors list. 2018-11-13 10:24:15 okay... :)) 2018-11-13 10:24:27 we offically support rsync.a.o 2018-11-13 10:25:20 if you sync per hour speed will not be an issue. 2018-11-13 10:26:38 yes 2018-11-13 10:27:31 i will report success #alpine-infra if everythings fine 2018-11-13 10:27:37 +in 2018-11-13 10:31:58 hanez, yes please dont mix this channel with infra related info. use alpine-linux or infra. thx. 2018-11-13 10:32:20 yes, i am over there now 2018-11-13 10:32:40 sorry. just answered to you. will never happen again 2018-11-13 10:33:47 np, thx for helping out! 2018-11-13 13:24:33 kaniini, xen does not build with gcc8. since you are maintainer, perhaps you could take a look? see also: https://github.com/alpinelinux/aports/pull/5629 2018-11-13 21:43:30 apk could not upgrade from armhf to armv7, or maybe I missed something in it's options? 2018-11-13 21:47:44 could it be done by mounting root filesystem somewhere and force by '--arch=armv7 --root /mnt'? 2018-11-13 21:48:29 from where it will read 'apk/repositoties' in that case? 2018-11-13 21:49:23 force repo by '--repositories-file=/mnt/etc/apk/repositories' ? 2018-11-13 21:50:18 no one could help? 2018-11-13 21:51:17 sorry because I'm so impatient. finger are itching :) 2018-11-13 22:00:24 what did you try? 2018-11-13 22:03:55 clandmeter: just I described above 2018-11-13 22:05:14 and now I have: lrwxrwxrwx 1 root root 18 Nov 13 22:57 /lib/libc.musl-armv7.so.1 -> ld-musl-armhf.so.1 2018-11-13 22:05:27 how did you try it, and what was the result? 2018-11-13 22:08:34 can you boot from another media and mount root somewhere and than apk --root.... --arch... --repository-file... -U upgrade -a? 2018-11-13 22:08:55 copied fs to separate sd card, updated apk-tools-static to armv7 on that fs, reboot to old system, mounted copied armhf root fs, and rest as I described abovve 2018-11-13 22:11:15 i.e. 'apk.static --arch=armv7 --root /mnt --repositories-file=/mnt/etc/apk/repositories upgrade -a -f' 2018-11-13 22:11:44 root have = before /mnt, ofc 2018-11-13 22:13:14 i think if you boot from another media you can use the system apk. 2018-11-13 22:13:27 maybe you need to specify keys 2018-11-13 22:14:17 keysdir 2018-11-13 22:14:30 they use same keys as armhf 2018-11-13 22:14:57 actually I used apk.static from the mounted fs '/mnt/sbin/apk.static ...' 2018-11-13 22:15:22 just use boot system apk 2018-11-13 22:15:31 you can also create an chroot from another arch 2018-11-13 22:16:44 I wanted to test is it possible to upgrade/move from one arch to another 2018-11-13 22:17:07 looks to cumbersome, for now at least. will see 2018-11-13 22:17:51 its not something we do often. 2018-11-13 22:18:17 but apk can handle other arch, thats what the --arch switch is for 2018-11-13 22:18:36 but you need it in conjunction with --root 2018-11-13 22:18:55 know that, I did 2018-11-13 22:19:28 but not worked as I expected 2018-11-13 22:20:26 what happend? 2018-11-13 22:20:45 'apk --print-arch' gives armv7, but /lib/libc.musl-armv7.so.1 is link to /lib/ld-musl-armhf.so.1 2018-11-13 22:21:22 did you upgrade and what was the output? 2018-11-13 22:21:52 yes, and I lost output because I reboot to 'new' system 2018-11-13 22:22:27 thats not much of a help 2018-11-13 22:22:43 can you replace apk and busybox with static ones? 2018-11-13 22:22:56 and try to run the upgrade with --root again? 2018-11-13 22:23:33 know that. it is somewhat strange 'ldd /bin/tcsh' shows 'libc.musl-armv7.so.1 => /lib/ld-musl-armhf.so.1 (0xb6eba000)' 2018-11-13 22:23:50 replaced them before started 2018-11-13 22:24:05 i have no idea what you are doing. 2018-11-13 22:24:13 well, not replaced but added static ones 2018-11-13 22:24:14 you are giving little details 2018-11-13 22:24:32 ok, let me explain 2018-11-13 22:24:36 and its getting late for me. 2018-11-13 22:25:06 I have armhf filesystem which I tried to upgrade/move to armv7 2018-11-13 22:25:26 never mind, I'm not in hurry ;) 2018-11-13 22:25:47 you deserve rest 2018-11-13 22:26:50 the thing is you have to fool apk your chroot is armv7 2018-11-13 22:27:11 so you need to modify /etc/apk/arch to armv7 2018-11-13 22:27:17 I did 2018-11-13 22:27:31 replace apk and busybox with static version (just in case) 2018-11-13 22:28:05 i think it could be that apk calls busybox for some scripts before it pulls in armv7 busybox 2018-11-13 22:28:08 you mean to remove these non static versions 2018-11-13 22:28:17 yes replace them 2018-11-13 22:28:29 will try, good idea 2018-11-13 22:28:31 so dont call then apk.static 2018-11-13 22:28:44 understand, no problem 2018-11-13 22:29:33 apk should first upgrade apk in the chroot, so it can handle post/pre install scripts. 2018-11-13 22:29:54 but if your chroot is uptodate it wont and that could lead into issues. 2018-11-13 22:30:12 but if its static, nobody cares. 2018-11-13 22:30:44 but its just guessing, if you cant solve it ask ncopa or fabled tomorrow. 2018-11-13 22:31:53 looks like it works, will see in few minutes 2018-11-13 22:33:03 need to upgrade 287 packages over slow usb adapter 2018-11-13 22:36:13 looks like only missing piece is to replace /lib/ld-musl-armhf.so.1 with armv7 somehow 2018-11-13 22:36:46 if it upgraded correctly it should all be ok 2018-11-13 22:37:36 you should be able to chroot into your installation 2018-11-13 22:38:14 'apk info -L musl' shows: musl-1.1.20-r2 contains: lib/ld-musl-armhf.so.1 lib/libc.musl-armv7.so.1 (put to one line) 2018-11-13 22:39:13 bedtime for me. gnite. 2018-11-13 22:39:24 ld-musl-armhf.so.1 is binary while libc.musl-armv7.so.1 is link to it 2018-11-13 22:39:46 so reading the above conversation, armv7 is available already? I thought we had to wait till all aports were built for it? 2018-11-13 22:39:48 good night 2018-11-14 15:19:26 clandmeter: armv7 installed and work. :) 2018-11-14 15:20:15 nice 2018-11-14 15:20:27 one question: /lib/ld-musl-armhf.so.1 and not armv7 2018-11-14 15:21:27 looked in the musl apk and see it is armhf, while the link to it is /lib/libc.musl-armv7.so.1 2018-11-14 15:22:44 binaries which i examined with ldd all have libc.musl-armv7.so.1 => /lib/ld-musl-armhf.so. 2018-11-14 15:24:18 that is ok, afaik. but could be (or should be) ld-musl-armhf.so.1 renamed to ld-musl-armv7.so.1 2018-11-14 15:26:48 hm. musl doesn't know armv*, so its internal arch is still armhf (see the musl ./configure) 2018-11-14 15:27:35 the armv7 symlink is done by the musl apkbuild it seems 2018-11-14 15:27:36 https://github.com/alpinelinux/aports/blob/08cfee995aaf35eefff34b6ab7a0db656af4f0e6/main/musl/APKBUILD#L72 2018-11-14 15:28:23 AinNero: I've seen, even rebuilt musl locally to check that 2018-11-14 15:28:46 rebuilt on armv7, I mean 2018-11-14 15:31:21 so, armhf naming for ld-musl-armhf.so is ok on armv7? 2018-11-14 15:35:18 Not sure. This is likely an side effect of aports/f00ea22784d28a92b14dd5b570eda217c7d9a462 2018-11-14 15:35:57 since alpine/armhf should not dynamically load alpine/armv7 libraries, its likely semantically incorrect 2018-11-14 15:36:09 but i would ask dalias 2018-11-14 15:36:42 hm, ok, understand. 2018-11-14 15:37:37 looks like Void Linux have armv7 port 2018-11-14 15:38:51 will look there to see how they made it 2018-11-14 15:39:19 armhf is musl's arch yes 2018-11-14 15:39:33 btw, if no one tried AL armv7, I could tell that it works quite fine 2018-11-14 15:40:15 only had to build awesome wm to start (my) X desktop 2018-11-14 15:40:29 https://github.com/bminor/musl/blob/7bf773a8f9b97875ba67b646c1681ac5ca22016f/arch/arm/reloc.h 2018-11-14 15:40:57 see LDSO_ARCH here 2018-11-14 15:41:02 mps: void has armhf for both armv6 and armv6 2018-11-14 15:41:35 Shiz: just looking 2018-11-14 15:41:57 mps, fyi i have added armv7 to pkgs.a.o 2018-11-14 15:42:16 but it will take some time to build up the db. 2018-11-14 15:42:17 clandmeter: nice :) 2018-11-14 15:42:54 AinNero : since alpine/armhf should not dynamically load alpine/armv7 libraries, its likely semantically incorrect 2018-11-14 15:42:57 this is actually fine 2018-11-14 15:43:09 is it? 2018-11-14 15:43:12 the loader part is not different from armv6hf vs armv7hf aiui 2018-11-14 15:43:17 and the part that may be different, the libc 2018-11-14 15:43:20 has a different SONAME anyway 2018-11-14 15:43:26 (libc.musl-armv7 vs libc.musl-armhf) 2018-11-14 15:43:32 so it won't arbitrarily load diff binaries 2018-11-14 15:43:59 > (libc.musl-armv7 vs libc.musl-armhf) 2018-11-14 15:44:14 they both are symlink to the LDSO path given by musl, armhf for both cases 2018-11-14 15:44:34 AinNero: libc.musl-armv7 is symlink 2018-11-14 15:44:44 that it's a symlink doesn't matter 2018-11-14 15:44:51 libc.musl-armhf won't *exist* on an armv7 system 2018-11-14 15:44:53 and vice-versa 2018-11-14 15:44:54 true 2018-11-14 15:45:18 now it is clearer 2018-11-14 15:47:04 now is time for me to 'make fingers dirty' with new port. Thank you all for good work 2018-11-14 15:47:35 musl uses "/etc/ld-musl-${LDSO_ARCH}.path" for dynamic library lookups 2018-11-14 15:47:52 LDSO_ARCH is armhf for both alpine/armhf and alpine/armv7 2018-11-14 15:48:17 oh, btw, should I write notes about moving from armhf to armv7 2018-11-14 15:48:51 hmm 2018-11-14 15:50:52 we should ask dalias about this 2018-11-14 15:56:17 personally i would keep upstream defaults and dont switch the symlink/libc file around 2018-11-14 15:56:32 but i dont know the reasoning why it was done in the first place 2018-11-14 16:00:04 looks like Void linux also call it ld-musl-armhf.so.1 2018-11-14 16:02:06 they keep the upstream behavior. 2018-11-14 16:04:18 so, till the upstream changes that we have to follow it as is now 2018-11-14 16:05:34 you can verify with 'objdump -a -x'|grep NEEDED that the libc.musl-$(CHOST).so path is hardcoded in 2018-11-14 16:05:43 changing it will be a breaking change. 2018-11-14 16:05:50 actually, i just realised 2018-11-14 16:05:51 it won't be. 2018-11-14 16:06:11 musl ldso will never load any external lib beginning with lib{c,m,pthread,dl,some others}. 2018-11-14 16:06:15 regardless if it exists or not 2018-11-14 16:06:21 due to the libc being already in ldso 2018-11-14 16:07:08 hm, true 2018-11-14 16:07:26 would still break lddtree/mkinitfs 2018-11-14 17:57:56 an email about a breaking change in openssl (*on edge!*) was sent to alpine-aports - whoever replies should point out that edge is unstable and subject to occasional breaking changes 2018-11-14 17:59:12 not only is it edge, it's edge/testing 2018-11-14 17:59:53 that too, double dose of unstable 2018-11-14 18:00:01 now, I get wanting cutting-edge software (I'm like that myself), but I don't expect things to necessarily work, and generally try to fix them myself ^^;; 2018-11-14 18:00:15 if you're using unstable software, things can and usually will break 2018-11-14 18:00:52 I find issue in the definition of unstable, personally - it's not like it's a -git version or anything, just a consequence of how all binary distributions work 2018-11-14 18:01:44 anyway, I'd rather inform them that alpine-aports is more for sending in patches ^^, but I'm probably just going to sit it out, they'll figure things out eventually 2018-11-14 18:02:47 yeah, but I can't give him a thorough reply, so I'd rather just briefly post here about it being in alpine-aports rather than alpine-user instead of uttering a harsh 'this is the wrong list' 2018-11-14 21:47:33 is there a reason erlang's apkbuild compiles it with -j1? 2018-11-14 21:53:35 could be historical 2018-11-14 21:53:47 blame it 2018-11-14 21:53:58 Not Erlang-specific, but based on what I saw, some packages fail to build (at least on Travis CI) if '-j1' isn't used. 2018-11-14 21:56:14 hmhm, i just built 21.1.1 anyway 2018-11-14 21:56:47 it takes half a year to build with -j1 2018-11-14 21:57:08 you can try without it. 2018-11-14 21:57:11 my build server is a single core :D 2018-11-14 21:57:16 everything is -j1! :D 2018-11-14 21:57:21 the build box i have access to is -j48 -l48 2018-11-14 21:57:36 i have some boxes with even more cores sitting around, but they're not alpine boxes 2018-11-14 21:57:53 i have so many cores i lost count... 2018-11-14 21:57:58 all of my personal servers are alpine 2018-11-14 21:58:10 but most of them are smallish since the only high-core count thing I really do is building my own overlay 2018-11-14 21:58:43 I could probably have access to a physical machine with more but I'd have nowhere to put it 2018-11-14 21:58:50 i wish alpine had a little more focus on the desktop experience, it seems largely server-oriented as of now 2018-11-14 21:59:24 I'm not seeing *much* missing besides plasma5 tbh 2018-11-14 21:59:31 unfortunately, plasma5 is my preferred DE 2018-11-14 21:59:42 it's for the most part just the user friendliness and documentation lacking 2018-11-14 21:59:48 it's not super intuitive 2018-11-14 21:59:56 I might be blind to that, tbh 2018-11-14 22:00:14 I came here straight from gentoo (on the server side), so 2018-11-14 22:00:22 yeah, point taken then 2018-11-14 22:00:37 but gentoo isn't un-user-friendly either! ... so yeah I'm blind :) 2018-11-14 22:05:16 I believe we're waiting for team maintainership of packages before submitting KF5 (KDE Frameworks) for merging 2018-11-14 22:06:02 once that's in, it's only a small step towards full Plasma 2018-11-14 22:06:14 yeah, I saw the discussion :) 2018-11-14 22:07:22 hey, not bad! 2018-11-14 22:07:52 re: docs, wanna contribute to the wiki danieli? ;) 2018-11-14 22:08:05 yeah, but there's a lot to do 2018-11-14 22:08:19 i'm gonna get alpine installed on my laptop and document things i do + things that could be handy 2018-11-14 22:08:19 I was/am considering figuring out manual installs and doing a writeup 2018-11-14 22:08:26 objective, consise docs 2018-11-14 22:08:42 fails to boot on my laptop though, unfortunately 2018-11-14 22:21:58 grub just.. doesn't do anything 2018-11-14 22:22:05 needs some further detective work 2018-11-15 05:52:45 <[[sroracle]]> fetch https://dl-3.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz 2018-11-15 05:52:47 <[[sroracle]]> SSL certificate subject doesn't match host dl-3.alpinelinux.org 2018-11-15 05:52:49 <[[sroracle]]> ERROR: https://dl-3.alpinelinux.org/alpine/v3.7/community/: Permission denied 2018-11-15 05:54:35 it's redirecting to fastly now 2018-11-15 05:54:45 (dl-3 was essentially decommissioned and redirected) 2018-11-15 05:54:49 use http and not https 2018-11-15 05:54:53 <[[sroracle]]> ah 2018-11-15 05:54:55 <[[sroracle]]> thanks 2018-11-15 05:55:28 or if you really really want https for whatever reason (apk checks signatures) - https://alpine.global.ssl.fastly.net/alpine/X/Y/Z 2018-11-15 15:47:00 ncopa, the amlogic kernel package should submit to main or community? 2018-11-15 16:08:02 yangxuan: new packages are always added to testing first 2018-11-15 16:08:56 oh he left... 2018-11-15 16:09:05 <^7heo> ncopa: I did not tho 2018-11-15 16:09:40 <^7heo> ncopa: and I'm still unsure if you rebuilt the faulty package on nl 2018-11-15 16:10:54 <^7heo> libetpan, it was. 2018-11-15 16:11:06 it needs rebuild? 2018-11-15 16:11:11 <^7heo> missing an ABI symbol, it is. 2018-11-15 16:11:35 <^7heo> on nl yes, on the rest, not sure. 2018-11-15 16:12:05 should be same package on every mirror 2018-11-15 16:12:07 <^7heo> I got it from nl, it was missing a symbol, recompiled it from aports, all fine 2018-11-15 16:12:23 <^7heo> maybe it was broken everywhere 2018-11-15 16:12:30 what version? 2018-11-15 16:12:40 <^7heo> afaict danieli and I both recompiled from aports 2018-11-15 16:12:55 both alpine version and libetpan version 2018-11-15 16:13:03 i use it on my desktop, from edge 2018-11-15 16:13:06 <^7heo> long story short, it was breaking claws-mail 2018-11-15 16:13:19 i use claws-mail myself 2018-11-15 16:13:22 <^7heo> recompiled, went fine 2018-11-15 16:13:25 from edge 2018-11-15 16:13:33 <^7heo> I took it from 3.8 2018-11-15 16:13:37 <^7heo> I think 2018-11-15 16:13:47 <^7heo> not entirely sure anymore 2018-11-15 16:13:56 <^7heo> I don't have that machine atm 2018-11-15 16:14:15 maybe you used libetpan from edge and the other libs from v3.8? 2018-11-15 16:14:19 <^7heo> long story short, ABI symbol missing, not sure if solved 2018-11-15 16:14:29 <^7heo> nah 2018-11-15 16:14:32 may happen if you mix repos 2018-11-15 16:14:40 <^7heo> I didn't do package black magic 2018-11-15 16:14:48 <^7heo> I tag the rpos 2018-11-15 16:14:51 <^7heo> repos* 2018-11-15 16:58:22 v3.9 builders for armv7 and s390x is up 2018-11-15 21:28:04 it is only x86 and x86_64 builders that are not yet up 2018-11-15 21:28:17 due to compile error on db 2018-11-15 21:28:46 would be nice if someone could help me fix build of main/db 2018-11-16 00:00:07 ncopa: what's up with it? 2018-11-16 00:00:09 did you get it solved? 2018-11-16 00:05:50 ncopa: claws-mail fails on s390x because of libressl/openssl conflict 2018-11-16 00:42:23 is their a devmapper-dev package? I'm trying to build a docker graphdriver that is built ontop of dm but is different than the normal devicemapper graph driver 2018-11-16 05:56:37 ncopa: for main/db: this patch works for me http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-support/db/db/0001-atomic-Rename-local-__atomic_compare_exchange-to-avo.patch 2018-11-16 05:57:08 found at http://lists.busybox.net/pipermail/buildroot/2018-May/220910.html 2018-11-16 06:36:20 I'll look into that chrony bug report 2018-11-16 07:09:13 patch created: https://github.com/alpinelinux/aports/pull/5660 2018-11-16 10:11:15 clandmeter: didn't the Alex K person make another issue a few hours ago? 2018-11-16 10:11:44 looks like separate issues, nevermind 2018-11-16 10:13:08 yes, not sure if he/she knows what its doing. 2018-11-16 10:13:41 using alpine if you don't know the difference between up and down seems like an odd choice 2018-11-16 10:14:05 (that's a hyperbole - I'm aiming at people who don't have enough Linux experience to be able to troubleshoot) 2018-11-16 10:15:38 it sure helps to have some experience when using alpine :) 2018-11-16 10:21:39 Alpine Linux is a Linux distribution based on musl and BusyBox, primarily designed for "power users who appreciate security, simplicity and resource efficiency". 2018-11-16 10:21:45 power users, simplicity 2018-11-16 10:28:00 Well, having issues is fine, everybody has those every once and while, although some more than others. But making bug reports for all of them is wrong imo, better to go ask for help in an IRC channel like this one 2018-11-16 10:30:25 mm, bug trackers are for bugs, 2018-11-16 10:35:54 so i should take my issues elsewhere? :) 2018-11-16 11:07:41 danieli: your quote "designed for "power users who appreciate security, simplicity and resource efficiency" should be on main web page, imho 2018-11-16 11:07:59 I copypasted it off the Google result (preview) of the Wikipedia article 2018-11-16 11:08:11 and I would a something like 'and ready/willing to hack' 2018-11-16 11:10:02 I started a skeleton website for Alpine as a pet project, haven't had the time to work on it 2018-11-16 11:10:16 I'll sketch up some concepts 2018-11-16 11:10:29 current one is simple and quick 2018-11-16 12:08:58 Hey, I have to change the packaging of the docker daemon for docker 18.09.0 and newer versions. Theses versions don't use their own versions of containerd and runc anymore but the use the official ones. I hope I can release the changed package next week. 2018-11-16 12:11:01 But this also requires that one package in testing (containerd) gets moved to community and another new package (runc) needs to go straight to community. Are their any complaints against this way? 2018-11-16 13:28:53 ncopa: just curious, how come we're still on llvm5 and not 6-7? 2018-11-16 14:29:25 I've been testing the armv7 repos and some packages are missing despite the build log showing that they compiled. 2018-11-16 14:29:39 Missing packages: network-manager-applet, libgnome-keyring, gnome-keyring 2018-11-16 14:31:02 <_ikke_> decatf: The builders would only upload the packages at the end of the process 2018-11-16 14:31:41 what _ikke_ says 2018-11-16 14:32:23 after each cycle it will do so. its currently to set to halt on each error, thats why its not uploaded yet. 2018-11-16 14:32:32 I see 2018-11-16 14:35:50 so that's it 2018-11-16 14:36:36 and the main reason is that it has never completed the full cycle yet. 2018-11-16 14:36:50 without errors that is. 2018-11-16 14:37:55 each new arch/version takes time as many pkgs will break for whatever reason. 2018-11-16 15:18:43 ncopa, the linux-amlogic have been submitted to testing 2018-11-16 15:29:53 decatf: I've rebuilt locally missing packages, most builds without problem although didn't tried gnome or network-manager 2018-11-16 15:33:07 the docker library arm64v8/alpine:edge seems can't upgrade to latest package 2018-11-16 15:33:20 ERROR: libcrypto1.1-1.1.1-r5: trying to overwrite etc/ssl/openssl.cnf owned by libressl2.6-libcrypto-2.6.5-r0. 2018-11-16 15:37:50 remove libressl 2018-11-16 15:53:25 guess is related to apk-tools build against with openssl instead of libressl recently, will ask gliderlab upgrade the arm64v8/alpine:edge 2018-11-16 18:45:53 is their anyway to get a devmapper-dev package? can't compile anything that depends on it 2018-11-16 18:51:24 spotter: lvm2-dev, maybe 2018-11-16 19:01:11 it doesn't have it, tried 2018-11-16 19:01:26 trying to build a docker graphdriver plugin that uses devmapper 2018-11-16 19:02:06 while debian/ubuntu have a -dev packge, they don't provide a .a for libdevmapper so can't compile it statically with it :/ 2018-11-16 19:04:56 did you tried search at pkgs.a.o 2018-11-16 19:16:07 yes 2018-11-16 19:17:18 hmm 2018-11-16 19:17:33 https://pkgs.alpinelinux.org/contents?branch=edge&name=lvm2-dev&arch=armv7&repo=main shows what I need 2018-11-16 19:17:39 but pkgconfig wasn't working 2018-11-16 19:41:58 ok, I see, alpine has same problem as debian/ubuntu 2018-11-16 19:42:02 no libdevmapper.a 2018-11-16 19:42:10 /usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -ldevmapper 2018-11-17 10:59:59 ncopa, fabled, we no longer provider gcc-java? 2018-11-17 11:00:12 s/provider/provide 2018-11-17 11:01:56 pdftk seems the only one depending on it. 2018-11-17 11:02:05 73cbccee55 main/fastjar: fix gcc-java bootstrap 2018-11-17 11:02:17 only reference to 'gcc-java' I see in the git log --oneline 2018-11-17 11:02:46 i think its coming from gcc6 2018-11-17 11:03:21 yeah, the only ref I can see to "gcc-java" in aports itself is in the pdftk apkbuild 2018-11-17 11:05:39 iirc ncopa wanted to add gcc6 to have some support for removed features. 2018-11-17 11:06:06 i disabled pdftk for now. 2018-11-17 11:10:05 clandmeter: git log -S java -- main/gcc/APKBUILD 2018-11-17 11:10:14 something there is probably relevant 2018-11-17 11:10:40 77b5897fc3d7f3dabe54c23a0b830dae9d6593c6 says "main/gcc: disable java by default, fix for x86_64" 2018-11-17 11:12:39 hey guys, i just updated apk-tools to 2.10.3 and found out that i cant add new packages to an existing virtual package anymore 2018-11-17 11:12:46 was it intentional? 2018-11-17 11:13:07 didn't you just ask that in #alpine-linux? 2018-11-17 11:13:30 yeah right after i asksd i got dc-ed 2018-11-17 11:13:30 so i cant see if anyone replied 2018-11-17 11:13:30 :/ 2018-11-17 11:13:38 nobody did, it can be a slow channel at times 2018-11-17 11:13:50 dustyhorizon_, best place for this is bugs.a.o 2018-11-17 11:15:03 there are some commits regarding provides, so it could be a bug. 2018-11-17 11:16:39 ah hmm, sorry but whats a good way to file an issue? sorry im sorta new here .. 2018-11-17 11:16:52 bugs.alpinelinux.org 2018-11-17 11:17:22 ah right, thanks! 2018-11-17 11:17:35 dustyhorizon_, thank you for reporting it! 2018-11-17 11:20:23 found it, we need gcc6-jave to bootstrap openjdk 2018-11-17 11:20:35 java* 2018-11-17 11:22:06 iirc it isn't even maintained anymore 2018-11-17 11:22:17 i grepped the irc logs 2018-11-17 11:22:21 gcj i mean 2018-11-17 11:23:03 some small searchable interface would have been nice :) 2018-11-17 11:23:48 elaborate? 2018-11-17 12:05:27 <_ikke_> https://lwn.net/Articles/770784/ 2018-11-17 12:05:33 <_ikke_> Relevant for Alpinelinux as well 2018-11-17 12:14:43 danieli, a small interface to view irc logs from http://dev.alpinelinux.org/irclogs/ 2018-11-17 12:14:51 aha 2018-11-17 12:15:11 should be easy with a small php script 2018-11-17 12:15:24 yep, or lua :) 2018-11-17 12:15:30 or py 2018-11-17 12:15:39 or that, easier to run it under the httpd rather than run a separate server though 2018-11-17 12:16:07 using your own http server seems a bit overkill for this 2018-11-17 12:16:35 maybe make algitbot insert it into sqlite 2018-11-17 12:17:11 again, seems overkill when we're already storing logs flat file 2018-11-17 12:17:25 not if you want to properly search them. 2018-11-17 12:17:36 define properly 2018-11-17 12:17:49 msg time nick 2018-11-17 12:18:12 should be easy even with flat file 2018-11-17 12:18:37 could probably do just that in a short shell script for that sake 2018-11-17 12:18:45 everything is possible, some things just take more time :) 2018-11-17 12:19:49 either way, we're arguing semantics. and yeah, exactly - my argument is to avoid making a mountain out of a molehill 2018-11-17 12:42:43 reminds me, why do we not have llvm6? what is the blocker? 2018-11-17 13:01:25 clandmeter: do you happen to know? ^ 2018-11-17 13:02:00 i have no idea, i think Shiz worked on it before. 2018-11-17 13:02:28 https://github.com/xentec/aports/tree/pr-llvm-6/main/llvm6 2018-11-17 13:02:39 it builds and passes tests on x86_64 2018-11-17 13:02:54 xentec: do you have any insight into this - why was it not upstreamed? 2018-11-17 13:03:48 llvm 6.0.0 is from early march iirc 2018-11-17 13:04:48 danieli, best is to ask ncopa or fabled. i dont try to mix in that part. 2018-11-17 13:05:16 i want to get some more insight into it, poking around is a way to do that i guess 2018-11-17 14:32:58 Hi everyone :) 2018-11-17 14:33:23 Could anybody please give me a hint for which kernel patches are being used by Alpine? 2018-11-17 14:34:03 according to https://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-edge.conf.mk , the grsec patchset is being used 2018-11-17 14:34:16 we do not use it anymore 2018-11-17 14:34:21 but I can't find it anywhere in the alpine git repos 2018-11-17 14:34:21 https://git.alpinelinux.org/cgit/aports/tree/main/linux-vanilla?h=master 2018-11-17 14:34:34 ah okay 2018-11-17 14:34:41 yeah, that's what I found 2018-11-17 14:34:56 I was just confused by the iso-scripts still using grsec 2018-11-17 14:35:14 might be something left-over, anyway, we used linux-hardened 2018-11-17 14:35:40 Was the lack of updates the only reason for it not being used anymore or were there other problems, too? 2018-11-17 14:45:19 Need to commit eol msg to Alpine iso repo 2018-11-17 14:46:17 big thank you already! 2018-11-17 14:49:51 since I can't find anything related to patches, alpine is now using a completely vanilla kernel, right? 2018-11-17 14:50:14 Yes 2018-11-17 14:51:04 okay, thanks 2018-11-17 14:52:44 correct 2018-11-17 15:12:17 <_ikke_> Clubfan: The main reason was that the grsec kernels couldn't be patched for Heartblead / Meltdown 2018-11-17 15:12:24 <_ikke_> (without upstream support) 2018-11-17 15:20:09 ah, that makes sense 2018-11-17 15:20:16 thanks! 2018-11-17 15:42:24 ncopa: void has chrome 70 by the way, plus a patchset 2018-11-17 15:42:33 s/e/ium/ 2018-11-17 15:43:46 <_ikke_> No alpine-meetbot here :P 2018-11-17 15:43:55 yeah, i know :( 2018-11-17 15:44:15 I *generally* use sed syntax to correct myself anyway 2018-11-17 15:44:21 <_ikke_> :) 2018-11-17 15:44:27 alpine-meetbot revived that habit 2018-11-17 15:44:49 man, chromium is such a pain in the arse 2018-11-17 15:45:50 <_ikke_> .uptime 2018-11-17 15:45:51 I've been sitting here for 7 days, 3:19:20 and I keep going! 2018-11-17 15:45:53 <_ikke_> ;-) 2018-11-17 15:45:57 darn you alpine-meetbot 2018-11-17 15:46:53 community/docker is struggling with some broken Go crap 2018-11-17 15:47:00 <_ikke_> hmm 2018-11-17 15:47:57 http://build.alpinelinux.org/buildlogs/build-edge-armv7/community/docker/docker-18.06.1-r0.log 2018-11-17 15:48:25 I'm looking into it 2018-11-17 15:48:35 <_ikke_> Ok, but that's only on armv7? 2018-11-17 15:48:41 no, x86_64 too 2018-11-17 15:48:43 <_ikke_> ok 2018-11-17 15:48:44 probably a global thing 2018-11-17 15:48:56 potentially relevant: https://github.com/bazelbuild/rules_go/issues/1261 2018-11-17 15:49:33 also https://github.com/golang/go/issues/17789 2018-11-17 15:50:04 <_ikke_> so problems with static builds? 2018-11-17 15:50:15 <_ikke_> "--features=static" 2018-11-17 15:51:02 it doesn't seem to be doing a static build of containerd 2018-11-17 15:51:09 containerd-shim is where it's failing 2018-11-17 15:51:38 it just does GOPATH="$PWD" LDFLAGS="" make GIT_COMMIT="$_containerd_ver" 2018-11-17 15:53:48 apparently it even has a fix for golang/go/issues/17789 2018-11-17 15:54:09 it references the last comment there 2018-11-17 15:55:04 it works if i enable cgo 2018-11-17 15:56:34 I have no idea what I did (just changed `make` -> `make -n` for verbosity) but now it works 2018-11-17 15:58:03 what the heck, it works with `make -n`? 2018-11-17 15:58:20 _ikke_: can you confirm it? just to make sure I'm not going insane 2018-11-17 15:58:30 <_ikke_> Sure, hold on 2018-11-17 15:58:54 _ikke_: http://tpaste.us/gMav 2018-11-17 15:59:05 first try without, then with that patch 2018-11-17 15:59:08 <_ikke_> yeah 2018-11-17 15:59:12 that's so weird 2018-11-17 15:59:21 -n just makes make print @-commands to stdout 2018-11-17 15:59:38 maybe there's some weird race condition in the generated makefile and -n slows it down just enough? 2018-11-17 16:00:10 that's actually possible, but seems odd 2018-11-17 16:00:16 <_ikke_> doesn't -n prevent it from building at all? 2018-11-17 16:00:21 no 2018-11-17 16:00:25 `man make` 2018-11-17 16:00:33 <_ikke_> " Print the commands that would be executed, but do not execute them" 2018-11-17 16:00:35 <_ikke_> Was reading that 2018-11-17 16:00:39 welp 2018-11-17 16:00:45 oh well 2018-11-17 16:00:50 "(except in certain circumstances)" 2018-11-17 16:00:52 hmm 2018-11-17 16:00:58 would be interesting to know what those are, manpage 2018-11-17 16:01:09 god damn make 2018-11-17 16:01:10 oh well 2018-11-17 16:01:13 guess it makes sense then 2018-11-17 16:01:33 <_ikke_> I get the same build errors 2018-11-17 16:01:59 setting CGO_ENABLED=1 on line 173 in community/docker/src/containerd-468a545b9edcd5932818eb9de8e72413e616e86e/Makefile worked though 2018-11-17 16:02:20 <_ikke_> cgo is go built from c, while go is go built with go? 2018-11-17 16:02:57 basically lets go packages call C code 2018-11-17 16:03:17 iirc it just uses the gcc rather than the go backend 2018-11-17 16:03:41 er, s/back/front/ 2018-11-17 16:06:12 anyway, it /is/ building containerd with `-buildmode=pie` or `-extldflags "-static"` 2018-11-17 16:12:34 oh well, i made a patch to enable it 2018-11-17 16:13:52 last time I tried go with musl on debian it was: CC=$(which musl-gcc) go build --ldflags '-w -linkmode external -extldflags "-static"' server.go 2018-11-17 16:14:06 but, that was more than a year ago 2018-11-17 16:14:19 <_ikke_> docker *did* build before 2018-11-17 16:14:21 that's not really necessary anymore 2018-11-17 16:14:32 _ikke_: /something/ changed 2018-11-17 16:15:04 <_ikke_> yes 2018-11-17 16:16:20 to be fair, this is edge, it *could* have gone unnoticed 2018-11-17 16:16:39 <_ikke_> failing to build? 2018-11-17 16:17:01 <_ikke_> You mean that someone changed something that caused the docker build to fail 2018-11-17 16:17:03 hm, last commit seems to have been in early september 2018-11-17 16:17:05 scratch that 2018-11-17 16:17:29 and well, something changed - it built in the past 2018-11-17 16:17:40 <_ikke_> yes 2018-11-17 16:17:58 <_ikke_> so some dependency might have changed in a subtle way 2018-11-17 16:18:24 only one commit lately 2018-11-17 16:18:52 looking into the failures, it seems like it wants to be linked to cgo (x_cgo_init etc are all methods from that) 2018-11-17 16:19:01 which would explain why enabling CGO makes the build pass 2018-11-17 16:19:04 yeah 2018-11-17 16:19:19 so the real question is why it isn't enabled by default, I guess 2018-11-17 16:19:22 seems like static just requires it 2018-11-17 16:19:29 but it's only an issue for containerd-shim in this case 2018-11-17 16:19:45 the rest of containerd built fine 2018-11-17 16:21:27 I had the same problem building Kubernetes, hence https://github.com/alpinelinux/aports/blob/master/testing/kubernetes/ensure-cgo-usage.patch 2018-11-17 16:21:50 fair enough, I'll give clandmeter a patch for it 2018-11-17 16:22:14 Reasoning for not enabling it by default is that not all platforms supports it. Usually there are checks for x86_64, but they don't work on musl. 2018-11-17 16:22:34 ah, so perhaps the proper upstream patch would be to fix the x86_64 checks :) 2018-11-17 16:22:52 Exactly. I took the lazy path and forced it downstream... 2018-11-17 16:23:10 hmm... where are the checks made? 2018-11-17 16:23:12 good point, i'll leave it up to ncopa i guess 2018-11-17 16:23:19 he works there, not me ;) 2018-11-17 16:23:29 in each upstream project (e.g separate checks in k8s and docker), or actually inside of cgo? 2018-11-17 16:23:45 sending patches to multiple upstreams definitely sounds more painful 2018-11-17 16:24:34 SpaceToast: https://github.com/kubernetes/kubernetes/blob/v1.12.2/hack/lib/golang.sh#L298 2018-11-17 16:27:39 this seems strange, they seem to actually assume native-compile CC will have CGO_ENABLED 2018-11-17 16:27:59 in containerd, CGO_ENABLED is explicitly disabled 2018-11-17 16:28:16 i.e. CGO_ENABLED=0 make (...) 2018-11-17 16:28:24 looks like the patch for k8s should add "linux/amd64") export CGO_ENABLED=1 ;; 2018-11-17 16:31:23 this dev box is really getting a workout today, so much compiling 2018-11-17 16:31:55 reminds me - getting musl to run on power9 (ppc64le) is going to be a bit of a pain, i'm no floating point arithmetic ninja. i might know a few though, but very few of them are highly familiar with power9s binary128 2018-11-17 16:32:56 I've nevr touched a ppc64le system, but don't we have downloads for that platform as-is? (standard, netboot and rootfs) 2018-11-17 16:33:18 it's power8, built on unicamps machines 2018-11-17 16:33:22 power9 is pretty new, from last year 2018-11-17 16:34:06 it does quad double. https://patchwork.criu.org/patch/9635/ 2018-11-17 16:34:14 seems conversation around it stalled 2018-11-17 16:34:57 hmm... if the two are dissimilar enough, will we still call both of them ppc64le? either way, makes sense, ty :) 2018-11-17 16:36:18 the issue is the abi breaking and musl lacking the support 2018-11-17 16:36:29 they are dissimilar enough 2018-11-17 17:01:11 SpaceToast: I just came across the same Go error in another package 2018-11-17 17:01:34 strange that it used to work 2018-11-17 17:01:51 the go package must've updated 2018-11-17 17:01:55 and something changed in upstream go 2018-11-17 17:02:06 i bet you that's it 2018-11-17 17:02:15 sounds like it, or something similar 2018-11-17 17:02:47 Makefile: GOOS=$(shell echo $* | cut -f1 -d-) GOARCH=$(shell echo $* | cut -f2 -d- | cut -f1 -d.) CGO_ENABLED=0 \ 2018-11-17 17:03:16 we need to know what to do about this before just monkey patching all broken golang packages 2018-11-17 17:05:07 definitely, I'm not very familiar with Go though ^^;; 2018-11-17 17:05:37 i'm asking a buddy of mine who is 2018-11-17 17:05:42 i'm not the best at go 2018-11-17 17:05:47 just adept 2018-11-17 17:05:55 nice... speaking of I should probably poke miniupnp upstream about their scripts already 2018-11-17 17:06:30 i need to practice more go 2018-11-17 17:06:43 it's super powerful, taking quite a big bite out of pythons devops cake 2018-11-17 17:06:58 i'm seeing a trend of python being used even more for ML and data science lately 2018-11-17 17:07:05 my PoV with Go is that it's a domain specific language for handling HTTP 2018-11-17 17:07:10 it's *very* good at that though 2018-11-17 17:07:22 that's a bit narrow minded 2018-11-17 17:07:29 it's definitely not a DSL 2018-11-17 17:07:38 and it's not just good at HTTP 2018-11-17 17:07:47 well, I mean more in the sense that erlang/elixir are domain-specific for long-running services 2018-11-17 17:07:57 rather than full DSL (even though I know that's what it expands to) 2018-11-17 17:08:20 they're not domain-specific languages (DSLs) although they have their niches 2018-11-17 17:08:25 you *can* use it to write just about anything, but in most cases outside of the mentioned one you're likely better off using something else 2018-11-17 17:08:46 being good at something and less good at specific other things doesn't mean it's a DSL 2018-11-17 17:08:52 either way, we can continue this conversation in #alpine-offtopic 2018-11-17 21:54:55 Is there any reason there isn't any buildbot for armhf anymore for edge? 2018-11-18 07:15:42 <_ikke_> MartijnBraam: That's covered by armv7 now 2018-11-18 07:15:47 <_ikke_> iirc 2018-11-18 09:48:57 if a source tarball just contains the files directly within it instead of in a $pkgname-$pkgver directory, what do I do? abuild just unpacks it to $srcdir 2018-11-18 09:51:26 urgh, guess I'll have to use the one not supplied by their website, but the one supplied by their github release page 2018-11-18 09:51:34 yup, midori 6.0 builds with that 2018-11-18 09:55:22 but abuild doesn't unpack it to $pkgname-$pkgver, just directly into $srcdir, argh 2018-11-18 09:55:30 clandmeter: any easy fixes to that? 2018-11-18 09:56:09 ikke: not for armv6 devices 2018-11-18 09:56:25 it only does if it I prepend "${pkgname}-${pkgver}.tar.gz::" to the tarball in $sources 2018-11-18 11:51:19 danieli, you can override the unpack function 2018-11-18 11:51:41 clandmeter: thanks 2018-11-18 11:54:06 ncopa: as of now, if we were to add support for POWER9, we would have to define a different ABI for it due to IEEE 754 binary128 for long double (quad precision float) breaking musls ppc64le ABI 2018-11-18 11:54:49 I managed to build musl using the IBM provided patch fwiw 2018-11-18 12:09:59 clandmeter: for community/midori, see if http://tpaste.us/VaRJ works properly for you 2018-11-18 12:10:18 and just skim over to see that i didn't make any dumb mistakes 2018-11-18 12:27:29 a recurring ARM ABI issue I'm seeing is mentioned in https://gcc.gnu.org/gcc-7/changes.html (-Wpsabi) 2018-11-18 12:27:33 cc clandmeter 2018-11-18 14:58:04 <_ikke_> danieli: ^ 2018-11-18 16:33:47 danieli, i think you are using the incorrect tarball for midori? 2018-11-18 22:34:39 clandmeter: it's possible? 2018-11-18 22:34:42 let me double check 2018-11-18 22:36:46 asked on #alpine-linux but without any answer, so repeating here. /etc/init.d/local script have 'after *' in depend and /etc/init.d/agetty have 'after local'. isn't this some kind of circular depend? 2018-11-18 22:38:11 my problem is that my init.d script which have 'after local' doesn't wait for /etc/init.d/local to finish 2018-11-18 22:38:19 it's a sunday and it's getting pretty late in my time zone, just saying 2018-11-18 22:44:09 mps: https://github.com/OpenRC/openrc/blob/master/src/librc/librc-depend.c#L850 2018-11-18 22:44:31 after/before * + specific after/before is a special case :) 2018-11-18 22:46:18 if your service requires local to function (as strange as that may be), consider using `need` instead of `after` 2018-11-18 22:47:16 (though it may make sense to report a confirmed case of after * + after specific breaking to the openrc development team, you can do so here: https://bugs.gentoo.org/ ) 2018-11-18 22:48:26 SpaceToast: thanks, will try. I need it because in /etc/local.d is a script which sets some hardware which is needed for script in /etc/init.d to run 2018-11-18 22:48:55 have you considered writing a oneshot script for your hardware rather than stuffing it into local.d? :) 2018-11-18 22:49:50 thought about oneshoot, but /etc/local.d looked as more appropriate 2018-11-18 22:50:33 I like simple things and simple solution 2018-11-18 22:51:49 so the existing service meant for something entirely different with a lot of openrc-related baggage was a simpler solution to stuffing your hardware initialization into a small file, with sane shutdown? ;) 2018-11-18 22:51:53 In /etc/local.d I put simple commands and don't play with start, stop, restart and other functions because they are not needed 2018-11-18 22:52:54 well, I can put 'sleep n' (n - seconds) and it will work, that is simplest solution 2018-11-18 22:53:05 but not clean as I would like 2018-11-18 22:53:07 we appear to operate with different definitions for simple 2018-11-18 22:54:36 you are talking to someone who made debian with runit as init 1, about twelve (or more) years ago :) 2018-11-18 22:55:21 I ran gentoo on musl with clang as CC and runit as pid1, with lto for fun at some point, so? ¯\_(ツ)_/¯ 2018-11-18 22:55:45 (before that actually became somewhat supported, may or may not have helped getting that first part working in general :)) 2018-11-18 22:56:12 "less LOC changed" != simple, just like having an empty source file in your project that is required for compiling it due to arcane reasons isn't simple 2018-11-18 22:56:16 you're thinking of easy. 2018-11-18 22:57:12 well, we have different view of the simple. 2018-11-18 22:57:50 indeed, while I believe mine is far more correct, that would be why I said "we appear to operate with different definitions for simple" ;) 2018-11-18 22:58:05 anyway, try using `need` instead of `after` / file a bug / stop (ab)using local 2018-11-18 22:58:34 never mind, I will not go to theoretical discusion here 2018-11-18 23:00:45 SpaceToast: btw, need solved problem for now 2018-11-18 23:01:16 cool, I do still recommend putting your hardware init into a proper initscript though. 2018-11-18 23:02:02 will think about it, as I already thought, but not sure if it worth effort 2018-11-18 23:02:45 I just glanced at this channel and thought it was #alpine-linux for a second 2018-11-18 23:03:27 danieli: I probably should have pointed them to #gentoo to start with, but I could answer the question to begin with so I just went ahead and did so here 2018-11-18 23:03:43 fair enough 2018-11-18 23:03:58 although I have seen in script for other distros that they use init system (systemd). and fyi, software about which I talk is the svxlink (www.svxlink.org) i.e. radio amateur repeater control (and what not) 2018-11-19 07:46:13 ncopa, any plan for openjdk7? 2018-11-19 07:47:10 morning clandmeter 2018-11-19 07:47:26 morning 2018-11-19 11:26:08 clandmeter: got an updated list of broken shit? 2018-11-19 11:27:03 http://tpaste.us/nMq4 2018-11-19 11:30:37 thanks 2018-11-19 13:44:00 i'm gonna try getting us chromium 70 using void's patches 2018-11-19 13:44:30 good luck with that. 2018-11-19 13:46:58 yeah, thanks, i'm gonna need it 2018-11-19 13:57:47 mps: re, /etc/local.d issue ^^^, I usuall do some check in local.d/ if hardware is up, then add line /init.d/ restart 2018-11-19 13:59:03 like you, I prefer not to edit any init.d files or write one 2018-11-19 14:00:56 but if someone comes with a better soln, pls share 2018-11-19 14:03:09 vkrishn: agree with you, I don't like to write another init.d script for simple tasks as activate gpio pins 2018-11-19 14:12:49 vkrishn: I wanted to understand why 'after local' didn't worked as it should, nothing more. and I know that question is more appropriate for #gento but thought it could be something changed in Alpine. 2018-11-19 14:14:03 I see that AL uses busybox init as pid 1 despite the fact openrc is installd 2018-11-19 14:20:07 mps: pid 1 != service supervision 2018-11-19 14:20:43 OpenRC is an RC system. The fact that it bundles in a pid1 (openrc-init) as of version 0.25 is (mostly) incidental. Using it also means standard tools like "shutdown" and "reboot" will no longer function. Notably, even gentoo (writers of openrc) use sysv by default (see: stage3 contents). 2018-11-19 14:23:08 SpaceToast: ah, now understand. Never tried Gento. thank you for explanation 2018-11-19 14:24:00 AinNero: I'm not talking about process supervision, just about starting service (process) 2018-11-19 14:25:48 except for systemd and old inittab style, its a different process 2018-11-19 14:25:51 still 2018-11-19 14:27:40 mps: try adding some kind of check to see hardware is up, before restart[ing] the service, maybe add a simple log if hardware check fails 2018-11-19 14:28:22 I usually add a simple log file in /tmp/ 2018-11-19 14:28:37 vkrishn: solved already by adding 'need local' instead of 'after local' in init.d script 2018-11-19 14:28:56 ok :) 2018-11-19 14:31:19 fyi, this is for running svxlink (www.svxlink.org) on AL (armhf SBC), which is HAM (radio amateur) software package for a lot of things, and not yet packaged in AL. 2018-11-19 14:37:53 just note that, once you upgrade, the edited init.d script will not be overwritten 2018-11-19 14:38:11 any new changes will not work 2018-11-19 14:40:32 vkrishn: I know, I'm using AL on all my working boxes and some servers for more than two years 2018-11-19 21:57:31 https://git.alpinelinux.org/cgit/aports/tree/community/znc/APKBUILD Dropped c-ares years ago for 1.0. https://github.com/znc/znc/commit/717d0596e3723a77d0158a633ec3c37f1d6f02d9 2018-11-20 00:01:17 oh this is fun, I swear go is just awful 2018-11-20 14:20:00 jwh: isn't it just great?! 2018-11-20 14:20:19 this is probably relevant to whatever you're experiencing https://github.com/golang/go/issues/17789#issuecomment-258542220 2018-11-20 14:20:20 cc ncopa 2018-11-20 14:45:52 it's linking ok, just segfaulting heh 2018-11-20 14:46:59 I gave up on that for now but I did the other one I intended to so I'll get that polished and sent over 2018-11-20 16:08:57 sounds like it's time for gdb and self loathing! chromium segfaulting 2018-11-20 19:01:22 heh 2018-11-20 19:01:54 ok quick one, can i load environment files with openrc? 2018-11-20 19:02:06 a la EnvironmentFile in systemd? 2018-11-20 19:03:35 all these hipster go things want envorinment config not args otmr config files 2018-11-20 19:03:44 or* 2018-11-20 19:07:05 <_ikke_> jwh: a file with the same name in /etc/conf.d is automatically loaded 2018-11-20 20:02:38 ah yes of course 2018-11-20 20:02:43 duhhh 2018-11-20 20:02:52 just woke up sorry 2018-11-20 20:03:17 <_ikke_> you're welcome 2018-11-20 20:04:25 thanks :D 2018-11-20 20:07:34 just need to submit new packages to bugs. right? 2018-11-20 20:08:09 <_ikke_> if you have an APKBUILD you can create a PR on github 2018-11-20 20:16:09 oh even better 2018-11-20 20:16:15 thanks 2018-11-20 21:46:41 will we use linux 4.19 in alpine v3.9? 2018-11-20 21:46:59 yes, thats the idea 2018-11-20 21:47:12 great! 2018-11-20 21:51:02 it was quite some time since 4.14.y was stepped in v3.8.y, whats the kernel update "cadence", for stable? 2018-11-20 21:52:03 based on severity of fixes? 2018-11-20 21:53:37 based on lts or not 2018-11-20 21:54:25 yes but 4.14 is LTS. We have 4.14.69 since 2018-09-10 in v3.8 2018-11-20 21:54:54 yes? i dont understand your question 2018-11-20 21:55:43 we try to get the latest lts kernel in new version. 2018-11-20 21:55:44 latest is 4.14.81 in @edge 2018-11-20 21:56:06 we didnt have time yet to do 4.19 2018-11-20 21:56:43 i think its on ncopa's todo 2018-11-20 21:57:44 yes but how often do we upgrade the kernel in our stable releases, i.e. what would trigger i update to 4.14.81 (or later in 4.14.y series) in v3.8 2018-11-20 21:59:29 when another version is released apparently 2018-11-20 21:59:53 im not sure why ncopa didnt backport it to 3.8 2018-11-20 22:00:02 its better to ask him. 2018-11-21 04:17:54 so umm, anyone fancy having a look at this and checking if it works and builds properly for you guys (preferably also on non-amd64)? 2018-11-21 04:17:57 https://github.com/joeholden/aports/commit/ae03aeffbc082797ecfa8a595577e17c5c5f9a62 2018-11-21 04:43:22 I don't have access to any other builders than a x86_64 container 2018-11-21 05:06:36 oh ok, does it look ok otherwise? :D 2018-11-21 05:08:38 jwh: usually, openrc-related files go into an -openrc subpackage 2018-11-21 05:08:44 pretty sure aport is supposed to yell at you about that 2018-11-21 05:09:17 hm, they should be, I just stole the consul one as an example 2018-11-21 05:09:24 also your runscript is pretty awful 2018-11-21 05:09:28 in... a lot of ways 2018-11-21 05:09:40 remind me tomorrow (in about 10-12h) and I'll try helping you write a better one, ok? :) 2018-11-21 05:09:51 that one is entirely s/consul/traefik/ 2018-11-21 05:09:54 so whoever maintains that sucks :D 2018-11-21 05:10:06 quite possibly 2018-11-21 05:10:25 the only thing that really changed is names, and slightly different build params 2018-11-21 05:10:38 one of my "things" is through largely coincidence, I ended up using basically every single modern init system out there 2018-11-21 05:10:51 I've been spoilt by systemd heh 2018-11-21 05:10:55 then I found out how horrible most maintainers are at writing scripts, and started fixing them for personal use 2018-11-21 05:11:06 so I'm going through my stuff and making sure they're on alpine 2018-11-21 05:11:09 you've not seen what some distros ship as unit files then ;) 2018-11-21 05:11:19 oh, well I don't use ubuntu nonsense so yeah :D 2018-11-21 05:11:49 but yeah, one of the things I want to really help contributing is getting all of the initscripts up to par - you'd be surprised how awful some of them are (though alpine has a relatively better track record... just don't look at dnsmasq) 2018-11-21 05:11:58 haha 2018-11-21 05:12:32 our dnsmasq init script has a full on bridge/switch built into it 2018-11-21 05:12:38 nice 2018-11-21 05:12:49 I have no idea why, but once I'm there on my TODO list I'm asking the maintainer :) 2018-11-21 05:13:12 any pointers would be nice though, sooner I can get these ports committed the sooner I can switch things to alpine heh 2018-11-21 05:13:18 I suspect it has something to do with containers/VMs, but I don't see why that couldn't be its separate package, rather than making the primary 6-liner initscript insanity 2018-11-21 05:13:41 gonna have to look now 2018-11-21 05:13:48 yeah, just poke me once I'm not sleep-deprived, I'll be glad to help (as I said, it's one of my goals to make alpine's initscripts best in class) 2018-11-21 05:13:58 for a rough guideline, see https://github.com/OpenRC/openrc/blob/master/service-script-guide.md 2018-11-21 05:14:02 oh wow, that sucks 2018-11-21 05:14:05 lol 2018-11-21 05:14:36 ah ok cool, I'll refactor it 2018-11-21 05:14:40 tl;dr, you shouldn't have a start() or a stop() function 99% of the time 2018-11-21 05:14:52 still, I'd recommend just waiting until I'm in a good state ;) 2018-11-21 05:16:07 heh 2018-11-21 05:16:13 turns out the init script wouldn't work anyway :D 2018-11-21 05:16:17 missed a bit 2018-11-21 05:20:30 oh, it's traefik 2018-11-21 05:20:35 heh 2018-11-21 05:21:04 i think i already made a package for it (together with tons of other 'cloud native' projects), i'll see if i have it laying around 2018-11-21 05:21:06 yes, despite what all this hippy dippy ridiculous projects suggest about untarring a binary and throwing it in /usr/bin, it is a completely unacceptable way to run production services 2018-11-21 05:21:10 :D 2018-11-21 05:21:18 these* 2018-11-21 05:21:54 cockroach is my other one but go is just awful 2018-11-21 05:22:17 it manages to build binaries that just exit 0, or segfault for no apparent reason 2018-11-21 05:23:50 it's so fucking annoying that there now is a "Cloud Native" Computing Foundation *and* "Cloud Native" is a huge buzzword 2018-11-21 05:24:05 it's totally stupid, wasn't like this in my day... 2018-11-21 05:24:07 get off my lawn etc 2018-11-21 05:24:09 hey, at least we're in the center of it, being really good for containers and all ;) 2018-11-21 05:24:30 not for long with the drive for more minimal! 2018-11-21 05:24:35 services as init 2018-11-21 05:24:38 :D 2018-11-21 05:24:56 you're behind on the times, services-as-kernel is a thing 2018-11-21 05:25:03 haha 2018-11-21 05:25:09 (unikernel, actually pretty cool idea, but the implementations tend to suck) 2018-11-21 05:25:10 I get AWS is expensive but really 2018-11-21 05:25:10 let's discuss this in #alpine-linux or #alpine-offtopic 2018-11-21 05:25:14 preferably the latter 2018-11-21 05:25:23 roger 2018-11-21 08:38:59 i m working on a blockchain POC on raspberry PI3 with the RPY3 aarch64 and face an issue with mmap allocation failed (out of memory) while this works with other kernel . 2018-11-21 08:41:08 i suspect something arround TLB or locked memory issue but so far i was not able to spot was is missing 2018-11-21 08:42:19 clandmeter: i've seen multiple reports of memory issues on raspberry pis lately 2018-11-21 08:43:32 ok? 2018-11-21 08:43:56 somebody created an issue? 2018-11-21 08:44:41 how can i first ensure that the kernel i m using has been compiled with the support of huge pages and so on ? 2018-11-21 08:44:56 more or less people complaining on irc 2018-11-21 08:45:07 jpl_: but yeah, make a bug report at bugs.alpinelinux.org so we can track issues properly 2018-11-21 08:45:47 sure will do 2018-11-21 08:48:33 clandmeter: i'm thinking that there is some issue, but nothing really changed, did it? 2018-11-21 08:49:55 <_ikke_> jpl_: can't you do something like zcat /proc/config.gz/ 2018-11-21 08:49:57 <_ikke_> ? 2018-11-21 08:51:49 <_ikke_> jpl_: zgrep HUGEPAGE /proc/config.gz 2018-11-21 08:51:55 <_ikke_> Not sure if that's the right thing to look for 2018-11-21 08:54:21 iirc it's HUGETLBFS and HUGETLB_PAGE 2018-11-21 08:54:55 also `grep Huge /proc/meminfo` 2018-11-21 08:58:25 i dont think its enabled 2018-11-21 08:58:50 its not enabled for the defconfig from upstream 2018-11-21 08:58:55 probably not 2018-11-21 08:59:03 i've seen 3-4 people having memory issues on the RPi over the past couple of days 2018-11-21 09:02:16 <_ikke_> Is that related to huge pages? 2018-11-21 09:02:49 shouldn't be, the Pis don't have that much memory anyway 2018-11-21 09:03:19 <_ikke_> right, was wondering about it 2018-11-21 09:17:54 i confirm /proc/meminfo does not contain any reference to hugetlb 2018-11-21 09:18:55 probs not enabled in the upstream defconfig then 2018-11-21 09:19:00 and you're sure you didn't simply just run out of memory? 2018-11-21 09:19:11 yes i m sure 2018-11-21 09:19:26 odd. i don't see a bug report yet, did you make one? 2018-11-21 09:19:43 doing as we speak 2018-11-21 09:19:43 which alpine version? 2018-11-21 09:19:53 3.8.1 2018-11-21 09:47:52 morning 2018-11-21 09:48:04 i will have a look at the v3.8 kernel update 2018-11-21 10:54:54 On the RPY3 aarch64 alpine build the VmallocTotal is 263061414 kb while on the other distro on the same hardware the size is 1000 times greater 2018-11-21 10:57:29 and actually the mmap call is for a huge number of pages mmap(NULL, 4096000000000, PROT_READ, MAP_SHARED, 9, 0) = 0xfc45ff600000 2018-11-21 10:58:07 this the results on another distro 2018-11-21 11:37:42 ncopa, im looking at rpi kernel to upgrade it to 4.19 2018-11-21 11:39:28 looks like 4.19 needs bison flex and openssl-dev 2018-11-21 11:42:17 yes, i think that sounds correct 2018-11-21 11:42:30 im gonna push 4.14.82 to git master first 2018-11-21 11:42:40 then i'll test boot it on my laptop 2018-11-21 11:42:46 before i push those to v3.8 2018-11-21 11:44:13 ok nice, HRio was asking what the policy was regarding kernels in stable. 2018-11-21 11:44:43 heh, kernel alraedy done 2018-11-21 11:44:59 96 cores makes a difference :) 2018-11-21 11:46:13 so, how kernels works in practice 2018-11-21 11:46:48 if edge runs same kernel as stable (eg 4.14) 2018-11-21 11:46:54 then i try push the kernel to edge first 2018-11-21 11:46:56 and test it 2018-11-21 11:47:03 before i push to v3.8 2018-11-21 11:47:13 i try to push updated kernel to stable when convenient 2018-11-21 11:47:37 and always try push latest kernel to stable before tagging a release 2018-11-21 11:52:34 i'm gonna run on my laptop as well 2018-11-21 12:03:08 rpi patch for 4.14.82 does not apply 2018-11-21 12:03:19 fails? 2018-11-21 12:03:45 yeah, seems that part of the rpi specific patch was upstreamed 2018-11-21 12:04:02 i see 2018-11-21 12:04:13 but i think i managed to rebase it 2018-11-21 12:04:16 in the past, haven't we diffed the rpi version against mainline? 2018-11-21 12:04:28 i don't remember exactly what the process was 2018-11-21 12:04:35 we try keep them in sync if possible 2018-11-21 12:08:02 we couldn't just pull a certain branch from raspberrypi/linux (in this case "rpi-4.19.y") and use that? 2018-11-21 12:08:12 i will add a function to apkbuild to regen the patch 2018-11-21 12:08:47 ncopa, you want a new patch for .82? 2018-11-21 14:20:00 clandmeter: i think you can just push linux-rpi 4.19 2018-11-21 14:20:22 ok 2018-11-21 14:20:48 seems like hotplugging keyboards in xorg is broken 2018-11-21 14:21:44 ncopa: did you test it? 2018-11-21 14:22:01 yes 2018-11-21 14:22:28 i noticed because when i unplug my usb (charger) cable, the BT connection didnt work 2018-11-21 14:22:46 an when reinserting the usb cable didnt give back keyboard via usb 2018-11-21 14:22:47 that's weird as heck 2018-11-21 14:22:52 I'll boot one of my rpis with it and check 2018-11-21 14:22:58 so i tried to plug an old dell usb keyboard 2018-11-21 14:23:00 pass me the apk somewhere? 2018-11-21 14:23:07 well, if you're pushing it, i'll just pull it from the repos 2018-11-21 14:23:25 dmesg shows that kernel detects the keyboard 2018-11-21 14:23:43 ncopa, done 2018-11-21 14:23:46 but xorg does not pick it up 2018-11-21 14:24:26 keyboard works in console (ctrl-alt-f1) 2018-11-21 14:39:48 ok, i was able to reproduce on my laptop. good 2018-11-21 14:40:06 a hotplugged usb keyboard does not work in xorg 2018-11-21 14:40:37 that's odd 2018-11-21 14:41:20 restarting xorg makes it detect it again 2018-11-21 14:41:41 my guess is some udev/systemd related change in xorg 2018-11-21 14:42:55 i'm guessing something with udev 2018-11-21 14:43:04 yes 2018-11-21 14:43:07 me too 2018-11-21 14:43:19 tried running it with `-logverbose 6`? 2018-11-21 14:45:05 @ ncopa 2018-11-21 14:45:20 could help us narrow it down 2018-11-21 14:45:22 Xorg.log.0: http://tpaste.us/Err6 2018-11-21 14:45:45 running x -> unplug -> plug back in? 2018-11-21 14:46:14 or just unplug 2018-11-21 14:47:03 running x, verify dell keyboard works 2018-11-21 14:47:05 unplug 2018-11-21 14:47:15 wait, and plug in again 2018-11-21 14:47:33 how do i pass -logverbose 6 to Xorg? 2018-11-21 14:47:43 i use lxdm 2018-11-21 14:47:52 hm, usually i do it via startx 2018-11-21 14:47:59 pretty sure it passes the flag on to Xorg 2018-11-21 14:48:22 yeah, i usually run something along the lines of `startx -- -logverbose 6 :1` 2018-11-21 14:49:35 stopping lxdm and running startx like that *should* work 2018-11-21 14:50:42 i can start with startx alone, but with -- -logverbose 6 :1 i only get a black screen 2018-11-21 14:51:05 perhaps not the :1 part 2018-11-21 14:51:06 :0 perhaps? 2018-11-21 14:52:07 yeah, removing :1 works 2018-11-21 14:52:26 you should probably install xf86-input-synaptics for that trackpad btw 2018-11-21 14:52:40 libinput? 2018-11-21 14:53:01 synaptics has some more features, should work for the apple trackpad 2018-11-21 14:53:51 usually you don't get two finger scrolling, two finger tap, gestures and stuff without it 2018-11-21 14:54:06 i have two finger scroll 2018-11-21 14:54:25 i thought libinput was preferred 2018-11-21 14:54:33 but im not a desktop user that much 2018-11-21 14:54:54 it's more of a laptop thing, and libinput might have improved, i haven't really kept too up to date on it 2018-11-21 14:55:55 oh, i also suffer from the same hotplug issue like ncope 2018-11-21 14:55:59 but i was unable to debug it 2018-11-21 14:56:06 kernel/X version? 2018-11-21 14:56:24 with -logverbose 6 http://tpaste.us/aRRM 2018-11-21 14:56:42 danieli: xorg-server-1.20.3-r1 linux-vanilla-4.14.81-r0 2018-11-21 14:56:54 it started reproducibly after upgrading from 3.8 to edge 2018-11-21 14:56:56 oh right, you're using the bcm5974 driver 2018-11-21 14:57:07 i missed that 2018-11-21 14:57:22 er, or rather, it's using libinput for bcm5974 2018-11-21 14:58:15 anyway, the only suspicious stuff relating to kbd i see in the xorg log is "No input driver specified, ignoring this device." 2018-11-21 14:59:17 it does not show that keyboard is unplugged either 2018-11-21 14:59:27 odd 2018-11-21 15:00:46 $ dmesg | tpaste 2018-11-21 15:00:46 http://tpaste.us/qKKK 2018-11-21 15:00:50 but kernel shows it 2018-11-21 15:00:59 so i think it does not get notification 2018-11-21 15:01:09 feels like udev is the culprit here 2018-11-21 15:01:19 definitively 2018-11-21 15:01:25 i don't see any obvious regressions or changes in upstream xorg that could've caused this either 2018-11-21 15:01:34 +1 2018-11-21 15:02:05 ncopa-macbook:~$ apk info -R xorg-server | grep udev 2018-11-21 15:02:05 so:libudev.so.1 2018-11-21 15:02:14 udev support is compiled in 2018-11-21 15:02:15 <^7heo> btw I checked my problem with the usb keyboard I have, but I didn't get far yet 2018-11-21 15:02:26 [ 15.421654] udevd[2605]: starting version 3.2.7 2018-11-21 15:02:37 https://github.com/gentoo/eudev/commits/v3.2.7 2018-11-21 15:02:42 commit c52dcff037f66ab3a5ef977fcec5d37ba7ad3f98 2018-11-21 15:02:46 <^7heo> afaict it has to do with the hub I use, which is emulating a device whiule having none "connected" 2018-11-21 15:02:50 Date: Thu Nov 1 12:39:16 2018 +0100 2018-11-21 15:02:50 main/eudev: upgrade to 3.2.7 2018-11-21 15:02:56 <^7heo> so the driver gets confused. 2018-11-21 15:03:07 ^7heo: when did your usb keybord start appear? 2018-11-21 15:03:20 <^7heo> `apk update && apk upgrade` 2018-11-21 15:03:29 <^7heo> that I did to get claws-mail working. 2018-11-21 15:03:37 what date 2018-11-21 15:04:02 <^7heo> because of the installation of its pgp-plugin (the current version at the time) requiring an up-to-date claws-mail. 2018-11-21 15:04:05 <^7heo> lemme check 2018-11-21 15:04:06 a few days ago iirc, let's see 2018-11-21 15:04:16 <^7heo> ah if danieli has logs, it's easier (I don't) 2018-11-21 15:04:26 https://dev.alpinelinux.org/irclogs/ :) 2018-11-21 15:04:53 <^7heo> november 11. 2018-11-21 15:04:57 <^7heo> afaict 2018-11-21 15:05:07 2018-11-10 19:11:44 <^7heo> Hi. 2018-11-21 15:05:17 <^7heo> indeed. 2018-11-21 15:05:48 <^7heo> ncopa: please note, most of the log there is about claws-mail and the wrong binary being installed with the libetcpan package. 2018-11-21 15:05:53 i'm not seeing anything super obviou in eudev either 2018-11-21 15:06:10 <^7heo> sorry, libetpan 2018-11-21 15:06:14 <^7heo> confused that with cpan 2018-11-21 15:06:25 libetc :) 2018-11-21 15:06:33 <^7heo> yeah I know :D 2018-11-21 15:08:12 s/obviou/obvious/ 2018-11-21 15:08:12 danieli meant to say: i'm not seeing anything super obvious in eudev either 2018-11-21 15:09:11 thank you kindly alpine-meetbot 2018-11-21 15:10:16 hm, i think i'm gonna set up a new alpine box with X and mess around with it to see if i can find something 2018-11-21 15:10:47 <^7heo> danieli: I will check if the keyboard works when I don't start X, at home. 2018-11-21 15:10:50 <^7heo> danieli: that's a valid point. 2018-11-21 15:31:07 umh 2018-11-21 15:31:18 re #9673 2018-11-21 15:31:20 https://dpaste.de/XvN1 2018-11-21 15:31:49 this happens also with py-cryptography rebuilt at the latest version 2018-11-21 15:31:51 yeah, i narrowed it down to py-cryptography / openssl linking too 2018-11-21 15:31:57 wonder what happened? 2018-11-21 15:32:15 something related still to libressl maybe 2018-11-21 15:32:45 i'm guessing so, but i didn't see anything related to libressl in the apkbuild, and i didn't see any patches either 2018-11-21 15:32:46 let me look again 2018-11-21 15:33:13 we need to go back to the reverse dependency to figure what is still linked to libressl 2018-11-21 15:33:18 maybe a missing rebuild 2018-11-21 15:33:24 yeah, it's a trivial build, no funky business, libressl patches, or flags to specify linking paths 2018-11-21 15:33:26 libffi perhaps 2018-11-21 15:33:29 that's possible 2018-11-21 15:33:45 SSL_CTX_set_psk_client_callback is defined in libressl (src/ssl/ssl_lib.{c,h}) 2018-11-21 15:33:57 it might be libffi 2018-11-21 15:33:58 commit bdc3cf9b7e9d6917c18a853552a117cccce77cd6 2018-11-21 15:33:58 Author: Natanael Copa 2018-11-21 15:33:58 Date: Mon Sep 3 17:49:46 2018 +0000 2018-11-21 15:33:58 main/libffi: modernize 2018-11-21 15:34:01 sounds like it, yeah 2018-11-21 15:34:09 this is the latest commit 2018-11-21 15:34:13 openssl/ssl.h in openssl 2018-11-21 15:34:16 before the openssl switch 2018-11-21 15:34:43 no 2018-11-21 15:34:50 what am I saying?! 2018-11-21 15:34:56 there's no ssl deps with libffi.. 2018-11-21 15:35:02 lol 2018-11-21 15:35:13 heh 2018-11-21 15:35:20 got confused with this:>>> from cryptography.hazmat.bindings._openssl import ffi, lib 2018-11-21 15:35:23 oh right, what the heck - i missed it too at first glance, neck deep in terminals 2018-11-21 15:35:29 maybe something with the configuration? 2018-11-21 15:35:40 SpaceToast, configuration of what? 2018-11-21 15:35:54 openssl, the prepare()/build() bit 2018-11-21 15:35:55 `cd ~/aports && grep -r libressl` 2018-11-21 15:36:01 haven't looked into it, admittedly 2018-11-21 15:36:15 i'm not really seeing any funky business in py-cryptography's apkbuild 2018-11-21 15:37:02 me either 2018-11-21 15:37:31 if you install certbot via pip, you got the same result 2018-11-21 15:37:43 so it might be related to python 2018-11-21 15:39:06 py-cryptography has the bindings to openssl, it's not external 2018-11-21 15:39:41 danieli, really? How did you figure? 2018-11-21 15:40:39 because the .so file is in /usr/lib/python3.6/site-packages/cryptography/hazmat/bindings/ 2018-11-21 15:41:18 hmm, libssl.so has SSL_CTX_set_psk_find_session_callback and SSL_CTX_set_psk_use_session_callback 2018-11-21 15:41:27 but is indeed missing the three hazmat complains about 2018-11-21 15:41:38 libcrypto has nothing as well 2018-11-21 15:45:55 https://github.com/alpinelinux/aports/commit/abe1dc5988d12f5aca771605b109390f33ce7519#commitcomment-31279291 2018-11-21 15:46:28 there it is, I just saw the lots-of-things-disabled, but I was trying to look at the openssl docs for what they disable 2018-11-21 15:46:40 so I guess we need to enable psk in openssl's APKBUILD 2018-11-21 15:46:50 let's see, testing 2018-11-21 15:48:26 bigger projects are a pain because there's so much code to wade through, thank god for grep 2018-11-21 15:59:23 I removed no-psk and now I can't sign my package index 2018-11-21 15:59:24 darn it. 2018-11-21 16:47:27 re issue #9658 i have included on the bug report outpout of sysctl -a and /proc/meminfo of a fresh working 4.15.0.39-generic ubuntu as requested 2018-11-21 16:49:30 is it just me or did usb hotplugging in xorg stop working recently on edge? 2018-11-21 16:50:34 nmeum: there's something up with it, yeah; iirc it's currently being investigated 2018-11-21 16:52:22 nmeum: several of the maintainers also have this issue 2018-11-21 16:52:36 i think it potentially affects all users 2018-11-21 17:17:49 i went afk for a little bit, i'm checking further when I've eaten 2018-11-21 18:21:20 did anyone look at the CGO_ENABLED stuff in Go? 2018-11-21 18:21:25 or is it still broken? 2018-11-21 18:30:20 also, do we have hooks for builders to bump pkgrel and rebuild packages automatically when certain packages are upgraded? 2018-11-21 18:30:42 such as wireguard, xtables, spl and so on when linux is upgraded - or is it all manual? 2018-11-21 19:20:37 that's done manually or through scripts running on the developers system 2018-11-21 19:21:01 was just wondering if it is automated or not, suppose local scripts make sense 2018-11-21 19:21:59 http://tpaste.us/Q110 this one kind of works in case you are looking for a local script 2018-11-21 19:26:04 wasn't really looking for one, just saw the git activity and got curious 2018-11-21 20:11:57 danieli, what was wrong with cgo? 2018-11-21 20:12:07 i think docker also fails to build? 2018-11-21 20:12:11 bingo 2018-11-21 20:12:14 that, and several other things 2018-11-21 20:12:29 multiple go things are broken 2018-11-21 20:13:13 is there an issue available? 2018-11-21 20:13:42 #9652 / https://bugs.alpinelinux.org/issues/9652 2018-11-21 20:28:18 i have no idea, maybe fabled or ncopa know. 2018-11-22 05:57:32 build-edge-armhf has disappeared on http://build.alpinelinux.org/ (clandmeter, I think you are maintaining that page?) 2018-11-22 05:57:49 I know that armv7 is new, but since armhf is still existing I think this is a bug 2018-11-22 05:58:05 im doing maintenance to our network 2018-11-22 06:04:31 right now? 2018-11-22 06:04:41 it seems that the armhf edge mirrors are not syncing 2018-11-22 06:05:13 e.g. busybox-static should be at 1.29.3-r3: https://pkgs.alpinelinux.org/packages?name=busybox-static&branch=edge 2018-11-22 06:05:21 but all the mirrors only have 1.29.3-r2 2018-11-22 06:05:41 (at least the ones I've checked) 2018-11-22 06:06:05 clandmeter: is this known/because of the maintenance? 2018-11-22 06:07:00 i am doing maintenance, i have no time now to check. 2018-11-22 06:07:14 but for sure they are down now :) 2018-11-22 06:16:44 clandmeter, okay thanks. please ping me when maintenance is over. 2018-11-22 09:13:02 rnalrd: did you have a config for 4.19 kernel? 2018-11-22 09:13:21 yes, I sent it you via email 2018-11-22 09:13:31 i'll search for it. thanks! 2018-11-22 09:14:04 ncopa: good morning! did you figure out why eudev seems to be on the fritz? 2018-11-22 09:14:19 i haven't yet had time to install it on real hardware, and using a VM wasn't feasible for hotplug HIDs 2018-11-22 09:14:51 rnalrd: found it. thanks! 2018-11-22 09:15:11 yw 2018-11-22 09:15:12 danieli: good morning. no i havent looked closer to eudev 2018-11-22 09:15:19 all right, just checking 2018-11-22 09:15:27 i looked at the commit log. there were not many commits 2018-11-22 09:15:38 +1 2018-11-22 09:16:05 i have to narrow it down to when the issue was introduced to figure it out 2018-11-22 09:16:11 yes 2018-11-22 09:16:20 it could be the rules files 2018-11-22 09:16:26 yeah, it's possible 2018-11-22 11:05:01 are there build logs for failed builds, especially armv7 logs. Trying to look at PIC/PIE issues on armv7 2018-11-22 11:15:20 lots of them 2018-11-22 11:15:24 also see #alpine-commits 2018-11-22 11:15:46 aiming at go specifically, or? 2018-11-22 11:17:36 danieli: textrel (-fPIC) on armv7 problem 2018-11-22 11:18:00 aah textrel, of course 2018-11-22 11:18:18 reminds me, what happens to armv6 now? 2018-11-22 11:35:32 are default flags changed in gcc 8.2 (from gcc 6.4)? 2018-11-22 11:46:49 problem with textrel is solved by adding -fpic to CFLAGS in APKBUILD 2018-11-22 13:32:49 should not have changed 2018-11-22 13:50:08 ncopa: not sure if this was discussed, but how come we're lacking gcj? 2018-11-22 13:55:55 danieli: gcj is no longer maintained as of 2017, and is no longer a part of gcc 2018-11-22 13:56:46 right, that's true, it was removed in gcc 7.1 - can we not use gcc6 just to bootstrap java? 2018-11-22 13:59:21 I'm confused, I was under the impression that openjdk can be ./configured and then maked 2018-11-22 13:59:37 in the second stage, yes 2018-11-22 13:59:57 hm, i'm gonna test something 2018-11-22 14:05:19 we need gcc6, its work in progress 2018-11-22 14:07:58 ncopa, did you see the cgo issue? 2018-11-22 14:15:59 i saw 2018-11-22 14:16:06 just have not had time to look at it yet 2018-11-22 14:16:31 or actually 2018-11-22 14:16:47 i was about to look at it, but was not able to ssh to my ppc64 container 2018-11-22 14:17:34 no worries 2018-11-22 14:19:56 ncopa, docker fails to build because of it. 2018-11-22 14:21:01 is this a ppc64le only problem? 2018-11-22 14:21:12 seems like its not... 2018-11-22 14:21:12 no 2018-11-22 14:21:28 also x86 afaik 2018-11-22 14:21:45 ok, then i was looking at different cgo issue 2018-11-22 14:21:46 its somethign related to pie i guess 2018-11-22 14:22:20 i tried to look at it, but it was above my pay-grade 2018-11-22 14:25:44 git log tells: 2018-11-22 14:25:51 go was upgraded to 1.1 2018-11-22 14:25:53 1.11 2018-11-22 14:26:08 docker was upgraded to 18.06.1 2018-11-22 14:26:24 at this point go must have worked 2018-11-22 14:26:45 there are a bunch of commits to go package after that 2018-11-22 14:26:52 and then gcc updated to 8 2018-11-22 14:27:14 sounds like good debug fun 2018-11-22 14:27:15 then there are more go commits 2018-11-22 14:27:23 and update to 11.11.2 2018-11-22 14:27:26 1.11.2 2018-11-22 14:29:00 so it could be some of the go related commits 2018-11-22 14:29:11 or it could be gcc8 that introduced it 2018-11-22 14:34:48 it is not 2018-11-22 14:35:01 it seems to apply to all architectures 2018-11-22 14:35:25 *seems* related to this https://github.com/golang/go/issues/17789#issuecomment-258542220 2018-11-22 14:45:06 reverting 9686793792a2c40a872ebbb2b86fa537f22491ad (community/go: Fix the `cannot find runtime/cgo`-warning) fixes it 2018-11-22 14:47:43 interesting 2018-11-22 14:47:49 docker builds and all? 2018-11-22 14:49:00 yup 2018-11-22 14:49:44 neat! should probably revert it in master and rebuild all go packages that failed after that change was introduced 2018-11-22 14:50:02 i know a few failed because of it on armv7, probably happened in other arches too 2018-11-22 14:56:26 examples: docker, gomplate 2018-11-22 18:16:52 What criteria justifies an update to a stable release's package? Is this evaluated on a package-by-package basis? 2018-11-22 20:37:54 <_ikke_> Usually just security and bug fixes 2018-11-22 20:38:04 <_ikke_> nivardus: ^ 2018-11-23 03:20:19 0x00007ffff7fbf262 in pthread_mutex_lock () from /lib/ld-musl-x86_64.so.1 2018-11-23 03:20:20 ugh 2018-11-23 05:58:56 ncopa: the mirrors are not syncing edge/main/armhf: https://nl.alpinelinux.org/alpine/edge/main/ - the date is stuck at 09-Nov-2018 18:28. Anything I can do to help resolve this? 2018-11-23 06:06:35 <_ikke_> hmm 2018-11-23 06:07:22 <_ikke_> weird, everything looks ok here: https://mirrors.alpinelinux.org/#mirror2 2018-11-23 06:08:31 <_ikke_> So the builders are not uploading new packages 2018-11-23 06:12:38 (ikke: oh nice, I didn't know that page.) 2018-11-23 06:13:50 ollieparanoid[m]: now you do :) that's pretty much the mirror authority 2018-11-23 07:26:43 ollieparanoid[m]: seems like it was stuck in testing/libtorrent-rasterbar 2018-11-23 07:32:43 ncopa: it seems it is still stuck, or did you change something? 2018-11-23 07:39:54 its catching up 2018-11-23 07:39:57 http://build.alpinelinux.org/ 2018-11-23 07:40:06 morning ncopa, _ikke_ 2018-11-23 07:42:52 ncopa: thanks :) 2018-11-23 09:07:35 ollieparanoid[m], ah sorry forgot about that. glad its solved now. 2018-11-23 11:43:11 <_ikke_> morning 2018-11-23 15:31:06 have tested eudev a but 2018-11-23 15:31:28 and the xorg hotplug propblem 2018-11-23 15:31:38 with eudev 3.2.5 hotplugging works 2018-11-23 15:31:48 also with eudev 3.2.6 2018-11-23 15:31:54 with 3.2.7 it breaks 2018-11-23 15:36:27 so it's some commit in 3.2.6 2018-11-23 15:37:01 some commit after 3.2.6 2018-11-23 15:39:39 oh my bad, i misread 2018-11-23 15:39:45 some commit in 3.2.7 2018-11-23 15:46:39 hum 2018-11-23 15:46:52 looks like im wrong 2018-11-23 15:47:29 i think problem was introduced >3.2.5 and <3.2.6 2018-11-23 15:53:17 yeah, some more commits in that range 2018-11-23 15:53:32 20 to be specific 2018-11-23 15:58:11 wonder if b1e47be38 could be related, pretty tiny change (-1 +1) 2018-11-23 16:02:53 https://github.com/gentoo/eudev/commit/9727d157d05b1d691aee8d51882221a88777ff93 2018-11-23 16:03:07 the added rules looks up a hwdb 2018-11-23 16:03:47 it says: "Without this, commits dba4728 2018-11-23 16:03:47 and 5df0137 leave the system without any useable input devices." 2018-11-23 16:04:16 i suspect it leaves system without usable input devices if the hwdb is missing 2018-11-23 16:05:45 i wonder where the hwdb is supposed to be located 2018-11-23 16:06:12 i'm confused, what do you mean? 2018-11-23 16:06:15 the hwdb files are in the repo 2018-11-23 16:12:51 they dont seem to be installed with the eudev package 2018-11-23 16:13:12 right, on the system, hmm 2018-11-23 16:13:37 gentoo package also seem to run udevadm hwdb --update 2018-11-23 16:13:46 which means it compiles a db into a binary format 2018-11-23 16:14:02 or something like that 2018-11-23 16:14:17 aha 2018-11-23 16:14:20 we compile it with --disable-hwdb 2018-11-23 16:14:25 (main/eudev) 2018-11-23 16:14:39 looks like it generate to /etc/udev/hwdb.bin 2018-11-23 16:14:49 correct, but our package just disables it 2018-11-23 16:15:02 gentoo also builds with --disable-hwdb 2018-11-23 16:15:12 odd 2018-11-23 16:15:45 https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/eudev/eudev-3.2.7.ebuild#n109 2018-11-23 16:16:29 i think we ship the data with hwdata 2018-11-23 16:17:03 ok, i need to go 2018-11-23 16:18:31 only relevant *hwdb* file i see is provided by libinput 2018-11-23 20:05:07 ncopa, https://github.com/alpinelinux/aports/pull/5711 should be ready 2018-11-23 20:05:34 oh nice, you opened an issue on it yesterday 2018-11-23 20:05:55 i saw some fuss about it on social media and some news sources today 2018-11-23 20:15:42 Hi everyone. I'm new to alpine. Would someone tell me how can I install the last libgfortran version ? Alpines keeps installing 6.4.0-r5 instead of 8.2.0-r1 2018-11-23 20:16:17 sor2: prefer #alpine-linux for support, this is the development channel 2018-11-23 20:16:55 <_ikke_> sor2: only edge contains 8.2 2018-11-23 20:17:06 yes, 3.7 contains 6.4.0-r5 2018-11-23 20:17:16 3.8 has 6.4.0-r9 2018-11-23 20:20:28 Ah. I'm running 3.7.1. 2018-11-23 20:20:40 I'll go the other channel than. Thanks! 2018-11-23 21:02:25 aww, no bpf cgroups in kernel config :( 2018-11-23 22:56:38 hi, why was grsecurity support dropped? is it too restrictive? 2018-11-23 22:59:40 the license is, yes 2018-11-23 23:00:23 and since the grsec people now demand money, which might be an violation of the GPL terms of the kernel itself... 2018-11-23 23:08:50 AinNero: one cannot use grsec without giving them money? or people can't redistribute grsec freely? under what is grsec licensed? 2018-11-23 23:09:46 grsec might be derived work from Linux and thus must be under GPL 2018-11-23 23:09:54 they're keeping it private 2018-11-23 23:09:59 it's like if they forked it 2018-11-23 23:10:04 mad about their open source software getting ripped off i guess 2018-11-23 23:10:10 what we used was linux-hardened, not grsec 2018-11-23 23:10:31 but.. it's why it's open source? to be used? 2018-11-23 23:10:43 ask grsec, not us 2018-11-23 23:10:47 people do know that w/o funding, they don't get grsec 2018-11-23 23:11:11 grsec isn't free nor public anymore 2018-11-23 23:11:12 so grsec support drop in alpine 3.8 is merely due to license? 2018-11-23 23:11:33 i can't remember the details off the top of my head, i'm super tired - i'm sure some of the opers know 2018-11-23 23:11:39 iirc there are other reasons too 2018-11-23 23:11:53 and as i said, we used linux-hardened, which is not really grsec 2018-11-23 23:12:39 "Grsecurity and gradm are licensed under the GNU GPL version 2 only. 2018-11-23 23:12:39 " 2018-11-23 23:12:58 narispo: see https://grsecurity.net/passing_the_baton_faq.php and the linked announcement 2018-11-23 23:13:05 hence linux-hardened when grsec went private 2018-11-23 23:13:20 if you believe they are violating the GPL (for which you have a pretty good case), feel free to take it up with them in court, not downstream (us) 2018-11-23 23:13:42 there isn't much we can do about it, we don't really have the resources or motivation to fight it 2018-11-23 23:13:43 A lot of alpine-sdk is failing to install for me on both edge and 3.8, with a 'temporary error (try again error)' message. Brand new install (first go at an Alpine instance). 2018-11-23 23:13:50 we're busy floating our own boat 2018-11-23 23:14:16 jsgrant: #alpine-linux please, and I'll give you a hand - this is the development channel 2018-11-23 23:14:20 (the main issue I see is that a lot of external contributors to grsec, that may *not* have given consent to changing the license in the new version; you may try contacting those) 2018-11-23 23:14:35 danieli, k np 2018-11-23 23:15:02 SpaceToast: "Today we are handing over future maintenance of grsecurity test patches to the community." 2018-11-23 23:15:11 just read the announcements and FAQ and it'll make more sense 2018-11-23 23:15:21 danieli: I... literally just linked the FAQ 2018-11-23 23:15:26 oh right, my bad 2018-11-23 23:15:32 lol, I'm tired :) 2018-11-23 23:15:34 I am also aware of how license changes are handled, including in law ;) 2018-11-23 23:15:39 maybe you meant a different target :) 2018-11-23 23:15:48 i don't have complaints, just questions 2018-11-23 23:16:17 nah, I just misread 2018-11-23 23:16:38 they are publishing newer releases with another license, so.. but I believe patches count as a fork of Linux 2018-11-23 23:16:48 the previously public grsec was left to the community, while they took what essentially is a fork private (and retained the name "grsecurity" since it's a registered trademark) 2018-11-23 23:16:54 narispo: derivative work, sure 2018-11-23 23:17:07 but that doesn't really help us in any way 2018-11-23 23:18:04 derivative work must be under the same license terms 2018-11-23 23:18:07 *you* can take it to court if you'd like 2018-11-23 23:18:31 in my opinion, that isn't really relevant to the alpine project 2018-11-23 23:18:36 ^ we're just downstream 2018-11-23 23:18:39 mhm 2018-11-23 23:18:43 yes 2018-11-23 23:18:45 what's done is done, and we don't have the resources to go to court or anything 2018-11-23 23:18:51 its ok 2018-11-23 23:18:56 we dropped it for various reasons i can't remember off the top of my head 2018-11-23 23:18:58 should we expect you in #gentoo as well? ;) 2018-11-23 23:19:07 or are your rounds limited to here? 2018-11-23 23:19:18 have you had any considerations for other solutions? 2018-11-23 23:19:23 is there any? 2018-11-23 23:19:31 we had our reasons for dropping linux-hardened 2018-11-23 23:19:35 the community that was supposed to pick up the baton.... hasn't really (as far as I'm aware) 2018-11-23 23:19:36 (which we recently dropped) 2018-11-23 23:19:43 SpaceToast: I am asking questions, no complans, don't misunderstand me (: 2018-11-23 23:19:51 complaints* 2018-11-23 23:19:52 my primary interest in grsec is PaX, which to the best of my knowledge has not been appropriately updated 2018-11-23 23:20:49 narispo: the point we're trying to make is we're really not the right party to be asking about upstream business 2018-11-23 23:21:04 Alpine is who dropped GrSecurity 2018-11-23 23:21:23 I was not aware of any of the problems before you told me.here 2018-11-23 23:21:28 For a variety of reasons, sure. So has Gentoo, and a variety of other distributions. 2018-11-23 23:21:38 yes, I was looking at alpine 2018-11-23 23:21:48 I am confused what is the problem about my questions 2018-11-23 23:24:52 narispo: the reason -hardened was dropped was because PaX from the -hardened project (post-grsec) needed manual patching for spectre/meltdown, which we couldn't do (and no one really bothered, afaik) - see http://lists.alpinelinux.org/alpine-devel/6022.html 2018-11-23 23:26:07 do note though - this was hardened, not grsec, grsec was dropped even earlier (for the abovementioned reasons) 2018-11-23 23:26:10 does that clear it up? 2018-11-23 23:26:17 oh right, that's what i had on the tip of my tongue 2018-11-23 23:26:57 danieli: I had to perform a supremely difficult google search through the MLs, that no other person could have possibly managed ;) 2018-11-23 23:26:59 yes, thanks, I already did understand the problem before though 2018-11-23 23:27:28 thanks for the additional technical details 2018-11-23 23:27:29 no need for sarcasm, i'm super sleepy and finishing off something important before bed 2018-11-23 23:27:38 I didn't mean you danieli :) 2018-11-23 23:27:48 all right 2018-11-23 23:44:06 heh 2018-11-24 07:18:18 howdy fellas 2018-11-24 13:20:01 hello 2018-11-24 17:52:34 community/libodfgen in armv7 fails because of -Werror=parentheses 2018-11-24 17:55:31 main/gdb fails because of a clash between linux-headers (/usr/include/asm/signal.h) and musl.dev (/usr/include/bits/signal.h) 2018-11-24 21:02:50 any idea how to fix travis error? https://github.com/alpinelinux/aports/pull/5708 2018-11-24 21:09:00 <_ikke_> hmm, rpath 2018-11-24 21:09:19 <_ikke_> you dont get that locally/ 2018-11-24 21:09:21 <_ikke_> ? 2018-11-26 08:07:21 morning ncopa 2018-11-26 08:07:39 hm, should I submit a pr/issue for port bumps or just prod someone on here? 2018-11-26 08:07:42 we have some pending patches for MIPS arch 2018-11-26 08:08:05 what's the status of MIPS? do we have builder for it? should I merge them? 2018-11-26 08:08:38 jwh, pls send patch to aports ML or PR 2018-11-26 08:08:54 okies, thanks 2018-11-26 10:32:42 rnalrd: we dont have any mips builder. i am ok to merge mips specific patches as long as they dont break anything for other arches 2018-11-26 10:36:50 aaa, morning 2018-11-26 10:37:12 rnalrd: if there's interest, i can speed up my dialogues with some companies who are interested in sponsoring mips builders 2018-11-26 10:37:35 <_ikke_> good morning 2018-11-26 10:52:57 danieli, I'm not interested (yet?), but it looks like someone is working on a MIPS port 2018-11-26 10:53:00 ok ncopa 2018-11-26 10:53:09 rnalrd: someone are indeed sending in a buttload of patches 2018-11-26 10:53:24 and yeah, my thinking is the same - wait until it's realistic to bootstrap and build main/ 2018-11-26 10:53:50 good morning 2018-11-26 10:54:48 this udev regression annoys me 2018-11-26 10:54:59 have you narrowed it down to being a regression? 2018-11-26 10:55:36 not really 2018-11-26 10:55:42 it used to work, but doesnt 2018-11-26 10:55:47 so i assume its a regression 2018-11-26 10:56:00 might be a feature... 2018-11-26 10:56:40 not first time udev breaks backwards compat 2018-11-26 10:57:16 ugh, i didn't set up a machine to test it with, guess i'll just have to do it 2018-11-26 11:07:26 i suspect we need hwids now. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/hwids/hwids-20180917.ebuild 2018-11-26 11:11:08 strange how it just fails with hotplug 2018-11-26 12:02:29 ncopa, is there still a plan to start using rootbld on builders? 2018-11-26 12:04:24 um 2018-11-26 12:04:29 not for v3.9 at least 2018-11-26 12:04:40 heh 2018-11-26 12:04:54 understand 2018-11-26 12:05:03 are there any blockers for using it? 2018-11-26 12:05:20 i think there are a few aports that requires network during build 2018-11-26 12:05:29 yes 2018-11-26 12:05:30 and there are some others that fails for some reason 2018-11-26 12:05:42 we dont have time to solve those issues before v3.9 2018-11-26 12:05:48 options="!rootbld" 2018-11-26 12:05:49 network can be enaabled. 2018-11-26 12:06:14 problem is that i have already bootstrapped the v3.9 builders 2018-11-26 12:06:18 and built a lot of packages 2018-11-26 12:06:23 no worries 2018-11-26 12:06:26 we'd need to rebuild all that 2018-11-26 12:06:36 i dont worry about 3.9 2018-11-26 12:06:39 i want 3.9 out asap 2018-11-26 12:07:01 so we add it to our plan for 3.10? 2018-11-26 12:07:02 i am currnently looking a udev issue 2018-11-26 12:07:08 clandmeter: ok 2018-11-26 12:07:12 urgh, i'll setup a machine to test with right now 2018-11-26 12:07:35 udevadm monitor shows that udev gets the KERNEL message 2018-11-26 12:07:41 but never generates andy UDEV event 2018-11-26 12:07:57 so udev never tells xorg that the kwyboard was plugged 2018-11-26 12:08:20 thanks, good to know 2018-11-26 12:08:36 i need this damn grafana apkbuild fixed properly but it's being a huge pain in the ass 2018-11-26 12:08:48 i'm considering just not finishing packaging it for now 2018-11-26 12:09:19 <_ikke_> What is holding it up? 2018-11-26 12:09:40 stupid issues with package() 2018-11-26 12:09:47 i'm just not used to it enough 2018-11-26 12:25:03 ncopa: could /etc/conf.d/udev udev_debug="YES" option help? it helps me sometimes 2018-11-26 12:36:18 good idea. i think i just "bricked" my laptop 2018-11-26 12:36:26 lol 2018-11-26 12:36:29 splendid idea 2018-11-26 12:36:50 I removed an udev rule so now I have not any input devices at all 2018-11-26 12:37:53 im glad i have sshd running... 2018-11-26 12:38:14 i had to ssh in to my desktop from my phone a moment ago to kill -9 virtualbox 2018-11-26 12:39:43 general advice: dont remove /lib/udev/rules.d/60-input-id.rules 2018-11-26 12:40:21 speaking from experience 2018-11-26 12:43:20 <_ikke_> sounds like very good advise 2018-11-26 12:52:27 ncopa: today later I will try to install edge eudev and look at it. Is it built for armv7? I have edge installed on armv7 only 2018-11-26 12:52:49 I mean, new version of eudev 2018-11-26 13:02:02 probably. not sure 2018-11-26 13:02:14 udev_debug options was helpful 2018-11-26 13:03:03 hum 2018-11-26 13:03:20 does not seem to have any effect on the older udev,. 3.2.5 2018-11-26 13:06:20 this is what udev log says when i plug the usb keyboard http://tpaste.us/655r 2018-11-26 13:16:30 ncopa: I tried it with eudev 3.2.5-r2 on stable (3.8). dmesg shows some debug info 2018-11-26 14:23:51 are the ppc64le builders hung or down? 2018-11-26 14:27:01 seems like it failed on http://build.alpinelinux.org/buildlogs/build-3-9-ppc64le/main/py-oauth2client/py-oauth2client-4.1.2-r2.log 2018-11-26 14:27:20 mksully22: wait, which builder, to be precise? 2018-11-26 14:27:26 3.9? 2018-11-26 14:29:47 I don't see any status for them on http://build.alpinelinux.org/ 2018-11-26 14:30:32 me neithre 2018-11-26 14:30:35 s/re/er/ 2018-11-26 14:30:36 danieli meant to say: me neither 2018-11-26 14:31:06 and looks like http://build.alpinelinux.org/buildlogs/build-3-9-ppc64le/main/py-oauth2client/py-oauth2client-4.1.2-r2.log failed on 11/20 so nothing after that for a while 2018-11-26 14:37:23 mksully22: I'll have a look 2018-11-26 14:38:23 ncopa: Thanks! 2018-11-26 14:38:41 i think the service was not configured to autostart 2018-11-26 14:40:27 sould be back now 2018-11-26 14:41:42 glad it wasn't something more serious :) Thanks again 2018-11-26 14:46:51 ncopa: was it just v3.9 or did the other builder levels need to be restarted too? 2018-11-26 14:47:34 hum, i didnt look at the others 2018-11-26 14:47:43 but seems they also need to be restarted 2018-11-26 14:47:43 they're not showing at build.a.o 2018-11-26 14:49:24 build-3-8-ppc64le is back 2018-11-26 14:50:21 build-3-7-ppc64le is back too 2018-11-26 14:51:13 and build-3-6-ppc64le 2018-11-26 15:05:48 no build-edge-ppc64le? 2018-11-26 15:08:17 build-edge-ppc64le is up now 2018-11-26 15:08:18 thanks! 2018-11-26 15:08:28 this is why i want monitoring! 2018-11-26 15:08:29 :) 2018-11-26 15:10:28 hi, ncopa 2018-11-26 15:10:55 would you mind check this PR: https://github.com/alpinelinux/aports/pull/5663 2018-11-26 15:11:10 and also this one: http://lists.alpinelinux.org/alpine-aports/5768.html 2018-11-26 15:19:28 hi. seems like http://lists.alpinelinux.org/alpine-aports/5768.html was already applied 2018-11-26 15:20:19 im looking at the other now 2018-11-26 15:21:40 just found u-boot patch have been applied, I should check github first 2018-11-26 15:27:06 pushed. thanks! 2018-11-26 15:27:17 i wonder how to fix gdb build on aarch64 2018-11-26 15:27:33 there are some conflicting structs in linux-headers an musl headers 2018-11-26 15:27:40 i came across that exact same thing not long ago 2018-11-26 15:27:43 not sure how to properly fix it 2018-11-26 15:27:52 it might have been gdb, i'll dig out my notes 2018-11-26 15:28:03 and yeah, i figured the same thing, i think i mentioned it last night 2018-11-26 15:29:41 thanks 2018-11-26 15:31:26 anybody use xfce4 on alpine? 2018-11-26 15:32:06 the themes seems not work properyly now for xfce4, edge branch 2018-11-26 15:33:55 after install themes package, the icon looks weird, I have tried several themes package 2018-11-26 15:34:17 they never have 2018-11-26 15:34:36 why not 2018-11-26 15:34:39 whatever you do, do -not- change themes at all, that'll break them permanently 2018-11-26 15:35:03 quality of life issues like those are some of my biggest pet peeves in a daily driver OS 2018-11-26 15:36:29 yes, this issues have been exist for month 2018-11-26 15:36:43 ACTION digs through things to open PRs for 2018-11-26 15:36:54 I fear I may start to annoy with PRs eventually :D 2018-11-26 15:36:59 i'm just gonna put noncritical QoL issues in my todo 2018-11-26 15:37:10 if only dd'ing the iso let alpine boot on my laptop, it would be my daily driver right now 2018-11-26 15:38:02 sometime themes change, but I'm not sure what make it work, most time not 2018-11-26 15:39:21 this is last screenshot when I got work: https://github.com/yangxuan8282/img_host/raw/master/2018-09-27-090933_1920x1080_scrot.jpg 2018-11-26 15:40:06 i use xfce4 2018-11-26 15:40:40 which theme? 2018-11-26 15:42:22 paper-icon-theme and arc-theme , also tried adwaita-icon-theme 2018-11-26 15:42:28 i use greybird, which works fairly good 2018-11-26 15:43:03 and i use paper icon theme too 2018-11-26 15:43:24 it was probably the gtk update that triggered it 2018-11-26 15:45:56 ncopa, how did you install it? use alpine package or manual install 2018-11-26 15:46:44 hey ncopa \o - I'm trying to understand/figure out the current state of lbu (including setup-lbu) and how our initramfs works; currently I'm missing how /media/* stuff gets created, as well as seeming fails in detection 2018-11-26 15:47:18 basically trying to figure out if I'm doing it wrong, if it's broken (and I should go fix it), or if it's horribly broken (and I should write my own) 2018-11-26 15:47:55 (example use-case: data mode on btrfs-raid1 -> initramfs never detects that it has an apkovl on it, despite mkinitfs seemingly supporting that) 2018-11-26 15:48:05 yangxuan: alpine package 2018-11-26 15:48:43 SpaceToast: the /media/* stuff is created based on /etc/fstab 2018-11-26 15:50:01 ok, so in data mode booting, /etc/fstab is in the apkovl, which isn't found 2018-11-26 15:51:46 https://git.alpinelinux.org/cgit/aports/tree/main/openrc/0001-call-sbin-mkmntdirs-in-localmount-OpenRC-service.patch 2018-11-26 15:52:05 and https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout/mkmntdirs.c 2018-11-26 15:52:21 I got that, but this is before openrc is involved 2018-11-26 15:52:23 apkovl is supposed to be found during boot 2018-11-26 15:52:32 yes, that is indeed what I'm talking about 2018-11-26 15:53:04 ok 2018-11-26 15:53:05 so 2018-11-26 15:53:19 I'm trying to understand the whole boot process to make sure I don't poke the wrong places :) 2018-11-26 15:53:56 from initramfs, it will run nlplug-findfs, which will set up a netlink listener for kernel hotplug events 2018-11-26 15:54:03 and trigger a cold plug 2018-11-26 15:54:33 for each block device showing up, it will try mount it and look for an apkovl 2018-11-26 15:54:49 it will create /media/$devname 2018-11-26 15:55:12 so for example, sda1 will create /media/sda1 and be mounted there 2018-11-26 15:55:16 and search for apkovl 2018-11-26 15:55:19 hmm... btrfs raid1 doesn't actually have a $devname, but it should be mountable "as if it was single", as long as detection happened beforehand 2018-11-26 15:55:34 is the apkovl found? 2018-11-26 15:55:38 no 2018-11-26 15:55:46 and the apkovl is on btrfs? 2018-11-26 15:55:51 yes 2018-11-26 15:56:05 kernel is on btrfs too? 2018-11-26 15:56:23 no, this is data mode (aka btrfs is mounted /var, it just happens to also have the apkovl) 2018-11-26 15:56:41 I'm guessing mkinitfs on the .isos has btrfs features disabled, or raid1 is interfering with nlplug-findfs then 2018-11-26 15:56:58 well, basically 2018-11-26 15:56:58 is there a specific reason we're not doing busybox mdev -s + shell loop over busybox blkid? 2018-11-26 15:57:30 i guess the problem is that nlplug-findfs does not support raid1 on btrfs 2018-11-26 15:57:43 it does support lvm2 and mdadm 2018-11-26 15:57:54 raid1 is somewhat complicated 2018-11-26 15:58:04 this is strange though, since btrfs should be mountable single, as long as detection happens before then 2018-11-26 15:58:16 so it sounds more like the issue is that coldplugging happens during the trying to mount parts 2018-11-26 15:58:21 (thus the mdev question) 2018-11-26 15:58:35 yes 2018-11-26 15:58:55 when a block device is detected, it will check it with blkid 2018-11-26 15:59:01 if its raid, it will start mdadm 2018-11-26 15:59:08 if its lvm2, it will start lvm 2018-11-26 15:59:33 if blkid says it is a filesystem, it will try load the filesystem kernel module and mount it 2018-11-26 16:00:07 we already have /sbin/btrfs device scan in initramfs-init (line 455) 2018-11-26 16:00:27 it's just that that needs to happen between coldplug and trying to mount 2018-11-26 16:00:40 whereas it happens immediately after nlplug-findfs 2018-11-26 16:00:54 (and only if root= was set) 2018-11-26 16:02:17 if root= was set, then it does not try find any apkovl 2018-11-26 16:02:59 ok, so btrfs is literally not scanned in this scenario 2018-11-26 16:03:19 correct 2018-11-26 16:03:48 I'm still left wondering why we don't use mdev separately for coldplugging, it's probably what I would do if I was to go and write a new initrd 2018-11-26 16:04:04 we used to do that 2018-11-26 16:04:12 and (at least from my perspective), this'd eliminate the problem as seen here (since it'd become possible to separate the stages) 2018-11-26 16:04:27 but the problem is that devices may show up late 2018-11-26 16:05:18 and we dont want wait 5 seconds to make sure all devices are found properly 2018-11-26 16:05:37 just tried install paper-icon-theme and greybird-themes again on fresh install alpine edge, this time it work 2018-11-26 16:06:24 so instead of wait and hope that kernel is done setting up block devices, we wrote nlplug-findfs, so we could mount and search the block device when it appears 2018-11-26 16:07:02 SpaceToast: what does blkid show when you have btrfs? 2018-11-26 16:07:24 TYPE=btrfs should show, yes 2018-11-26 16:07:57 for what device? 2018-11-26 16:08:21 that test setup is back home, let me quickly recreate it (~10ish minutes), but in theory it should show on all devices 2018-11-26 16:08:36 right 2018-11-26 16:09:18 what happens if you run `/sbin/btrfs device scan` and only one of two disks are there? 2018-11-26 16:09:43 lets say you have btfs raid1 on 2 usb disks 2018-11-26 16:09:50 at boot you have only one of the connected 2018-11-26 16:10:16 will it start the raid1 in degraded mode? 2018-11-26 16:10:19 if it's raid1, it should work fine and mount degraded 2018-11-26 16:10:20 thats what I would expect 2018-11-26 16:10:21 yes 2018-11-26 16:10:30 also, you can run `device scan` multiple times with no side-effects 2018-11-26 16:10:36 and if the second disk appears? 2018-11-26 16:10:45 you'll need to re-scan 2018-11-26 16:10:48 there is also `device ready` 2018-11-26 16:11:06 if you re-connect the second disk and do device scan, it will re-attach to the raid1? 2018-11-26 16:11:08 if `device ready` is used, and it detects a multi-device member, it will block until they all show up 2018-11-26 16:11:31 if it hasn't been mounted yet, I believe it should 2018-11-26 16:11:42 I have no idea what'll happen if it has been mounted by then 2018-11-26 16:12:01 because this is exactly what happens 2018-11-26 16:12:10 first disk shows up 2018-11-26 16:12:26 its is detected to be a btrfs disk 2018-11-26 16:12:32 the first 2018-11-26 16:12:52 `device ready` will only block if that btrfs disk is detected to be multi-device, *and* there are missing members 2018-11-26 16:14:02 so if you never plug in that second usb disk, it will blcok forever 2018-11-26 16:15:14 iirc nlplug-findfs will wait(2) for the external command to finish before it continue handle new kevents 2018-11-26 16:16:08 since nlplug-findfs loops, we can just continually device scan, I'm still trying to check and see if it's documented what happens on a scan-after-mount 2018-11-26 16:18:10 will there show up a btrfs device? 2018-11-26 16:18:16 like with mdadm 2018-11-26 16:18:33 I'm not sure what you mean 2018-11-26 16:18:43 if you create mdadm raid1 2018-11-26 16:19:02 i use sdb and sdc and out comes /dev/md0 2018-11-26 16:19:13 no, btrfs does that in the module 2018-11-26 16:19:29 you still have /dev/sdb and /dev/sdc, they both are reported as TYPE=btrfs, and you can mount the array by mounting either 2018-11-26 16:19:50 with mount(2) syscall? 2018-11-26 16:20:38 https://github.com/systemd/systemd/blob/master/rules/64-btrfs.rules.in 2018-11-26 16:21:49 ok, so btrfs raid1 (to blkid) shows up as multple devices (e.g /dev/sda, /dev/sdb) with TYPE=btrfs and the same UUID (since they're the same fs) 2018-11-26 16:22:34 I don't have a raw mount(2) binary lying around, but `busybox mount /dev/sda /mnt` succeeds (with both devices detected) 2018-11-26 16:23:06 ok 2018-11-26 16:23:33 let me try virtualizing the drives as virtual usbs and try plugging them out (might not work) 2018-11-26 16:23:40 looks like udev uses some test to check if the btrfs is ready 2018-11-26 16:24:00 it will re-trigger new events when it is ready 2018-11-26 16:25:59 a bit complicated 2018-11-26 16:26:06 but should be fixable 2018-11-26 16:26:31 SpaceToast: the short answer is: apkovl on btrfs is not supported 2018-11-26 16:27:07 yes, though I ran into something similar with apkovl on lvm (I didn't investigate further though, on plain ext4 it worked) 2018-11-26 16:27:55 to me, this seems like a strange(ish) workaround (nlplug-findfs) - I notice mdev has support for running arbitrary commands on hotplug (including on a per-device basis) 2018-11-26 16:27:57 ncopa: tried eudev 3.2.7-r0 on armv7 hotplugging keyboard under X, works ok 2018-11-26 16:28:35 so I might try and modify/write-a-new mkinitfs - any suggestions to make upstreaming more likely (in the scenario I do it and finish it)? 2018-11-26 16:30:16 i think it needs to be handled in nlplug-findfs to be upstreamable 2018-11-26 16:30:38 and actually 2018-11-26 16:30:44 we run mdev 2018-11-26 16:31:25 nlplug-findfs will run mdev, so you should be able to run the command from /etc/mdev.conf 2018-11-26 16:31:47 mps: huh...? 2018-11-26 16:31:50 if I was to go and write stuff, I'd be removing nlplug-findfs (in favor of mdev custom commands); the stated goal of nlplug-findfs is to avoid waiting for everything to be initialized, so if the alternative solution fulfills the same goal, wouldn't that be upstreamable? 2018-11-26 16:33:01 re: running through mdev; I doubt everyone would be happy with /sbin/btrfs device scan on all block device additions; though that could probably be done 2018-11-26 16:33:02 ncopa: you had a problem with hotplugging and eudev, iirc 2018-11-26 16:33:34 mps: i do, im just surprised it works on arm 2018-11-26 16:34:28 aha, ok. I'm ready to debug if it is needed 2018-11-26 16:35:25 SpaceToast: we used to run initramfs-init without nlplug-findfs so we have sort of been there already 2018-11-26 16:35:41 I realize that 2018-11-26 16:35:46 you can probably just find the old way in the git log 2018-11-26 16:36:04 however, you added nlplug-findfs for a specific purpose 2018-11-26 16:36:16 yes 2018-11-26 16:36:26 im trying to remember why 2018-11-26 16:36:26 I'm asking whether or not it'd be ok to remove nlplug-findfs if I could get initrd to fulfill that purpose without nlplug-findfs, basically 2018-11-26 16:36:47 you said earlier it was to avoid waiting (though that did sounds a bit strange to me) 2018-11-26 16:36:58 one of the problems is that executing mdev from /proc/sys/kernel/hotplug is racy 2018-11-26 16:37:17 there is no way to serialize the events that way 2018-11-26 16:37:19 mdev is not sequenced by default, but it can be made so 2018-11-26 16:37:35 if /dev/mdev.seq exists, mdev serializes events 2018-11-26 16:37:54 right, that was a hack to work around that 2018-11-26 16:38:15 andypost: thanks :D 2018-11-26 16:39:02 ls 2018-11-26 16:39:16 any go wizards got time to help e figure out why this nonsense isn't working properly? (builds but insta segfault) 2018-11-26 16:39:34 jwh: what's the package, and what does gdb say? 2018-11-26 16:41:14 cockroachdb, nothing useful :( 2018-11-26 16:41:19 but I'm no expert 2018-11-26 16:41:47 have you updated go? 2018-11-26 16:42:06 using whatever is in edge 2018-11-26 16:42:19 1.11.2 2018-11-26 16:42:26 SpaceToast: iirc, i decided to write nlplug-findfs to solve the synchronization problem and then busybox added the seq hack 2018-11-26 16:42:35 aha 2018-11-26 16:42:43 or i thought that the seq hack was too hacky 2018-11-26 16:42:55 the "proper" solution to the problem is netlink socket 2018-11-26 16:43:01 I need to rebuilt, but the last hit looked like cpu affinity 2018-11-26 16:43:18 rebuild* 2018-11-26 16:43:26 personally, I find nlplug-findfs somewhat hacky, mostly since (from where I'm standing) it seems to mess with order of operations 2018-11-26 16:43:51 still, if I went and had a tested setup without nlplug-findfs (but with mdev.seq), would that be considered for upstreaming? 2018-11-26 16:44:45 well, the idea is that kernel initializes the block devices, nlplug-findfs gets a notification that there is a new block device, and checks if it is what we are waiting for 2018-11-26 16:45:07 raid devices are a bit special since there are more than one of them 2018-11-26 16:45:24 yes, the way I'd implement that is having mdev be hotplug with seq, and run a shell-script that will busybox mount + busybox find to see if it contains what's looked for 2018-11-26 16:45:35 (in mdev.conf) 2018-11-26 16:46:01 what will the shell-script do? run blkid? 2018-11-26 16:47:21 i'm afraid that it will just move the problem, not solve it 2018-11-26 16:48:08 it'll use $MDEV (which is apparently defined) to mount it 2018-11-26 16:48:32 if an apkovl is found, it'll >> /tmp/apkovls 2018-11-26 16:48:57 what if $MDEV has an ext4 and the ext4 kernel module is not yet loaded? 2018-11-26 16:49:19 will it require that you add modules=ext4 as boot option? 2018-11-26 16:49:30 modprobe is a part of busybox 2018-11-26 16:49:48 yes, but how does it know that it needs to modprobe ext4? 2018-11-26 16:50:02 $MDEV itself does not say anything about that 2018-11-26 16:50:15 MDEV just say "sda" 2018-11-26 16:50:20 or "sda1" etc 2018-11-26 16:50:49 so you will need to run blkid /dev/$MDEV 2018-11-26 16:51:06 which will tell you that it TYPE=ext4 2018-11-26 16:51:18 that's true 2018-11-26 16:51:30 blkid is also built into busybox though 2018-11-26 16:51:54 + we'd be running it against a specific device 2018-11-26 16:51:58 correct, but it is (was) somewhat limited 2018-11-26 16:52:18 it didnt use to have support against a specific device 2018-11-26 16:52:29 i dunno if it supports it now 2018-11-26 16:52:38 it does :D 2018-11-26 16:53:05 (sudo busybox blkid /dev/sda2 -> "/dev/sda2: [...]" 2018-11-26 16:53:27 my earlier scripts needed to do: blkid | grep $MDEV 2018-11-26 16:53:40 i suppose things has happned last decade :) 2018-11-26 16:53:43 :) 2018-11-26 16:53:51 so, the conclusion I'm coming to here is 2018-11-26 16:54:15 busybox and mdev have grown a lot, it may make sense to try to use mdev+shell in place of nlplug-findfs, someone just needs to do the work and make sure it's tested 2018-11-26 16:54:19 does that sound right? 2018-11-26 16:54:42 i still think it makes more sense to do it from C 2018-11-26 16:54:51 because you will have the same problems 2018-11-26 16:55:40 the major difference will be that mdev will spawn the scripts in parallel 2018-11-26 16:55:50 mhm 2018-11-26 16:55:55 and will not wait til script is finished before it spawns next 2018-11-26 16:56:17 locking in shell is doable; will just have to see how to do it properly with busybox 2018-11-26 16:56:26 it's just that this feeds into some of my other complaints 2018-11-26 16:57:01 for example, I'd like to be able to have apkovl be in a subdirectory or a subvolume, but the current detection system gets very funky when you try that 2018-11-26 16:57:11 (it messed up my attempts to add alpine to my multiboot usb) 2018-11-26 16:57:24 right 2018-11-26 16:57:34 with the shell approach, you can have find(1), instead of implementing a tree walker in C; and so on 2018-11-26 16:57:43 I definitely see your point of view though 2018-11-26 16:57:44 there was also a request to find apkovl on a loopback device 2018-11-26 16:57:55 yes, for the multiboot stuff 2018-11-26 16:58:18 loopback might have to wait a bit longer, but I see those things as much simpler in implementation in shell + busybox, rather than C 2018-11-26 16:58:26 someone asked for finding apkovl on a file.iso on an ext4 ... 2018-11-26 16:58:34 :) 2018-11-26 16:58:50 sounds like they're trying to do that, yeah 2018-11-26 16:59:05 i think you will find that it gets equally complicated with shell 2018-11-26 16:59:27 quite possibly, I just want to make sure that it'll at least get considered for upstreaming before I even start putting the work in, essentially 2018-11-26 16:59:51 to be honest, i dont think its the way to go 2018-11-26 17:00:03 also performance is a worry 2018-11-26 17:00:34 most of the performance hit would be during mount(2), regardless of how this is implemented 2018-11-26 17:00:59 or if you mean find(1), having a recursion limit (as is now) seems reasonable, set through kernel arguments 2018-11-26 17:22:59 hm 2018-11-26 17:23:00 0x00007ffff7fbf262 in pthread_mutex_lock () from /lib/ld-musl-x86_64.so.1 2018-11-26 17:23:19 what gdb wizardry do I need? 2018-11-26 17:34:13 jwh: i saw some python app having similar problem 2018-11-26 17:34:24 oh hmmmm 2018-11-26 17:34:34 jwh: apk add musl-dbg 2018-11-26 17:34:46 ulimit -c unlimited 2018-11-26 17:35:10 then run gdb --core ./core /path/to/app 2018-11-26 17:35:19 from gdb you do: bt 2018-11-26 17:35:22 for backtrace 2018-11-26 17:35:48 may be an idea to file an issue on bugs.a.o with the backtrace 2018-11-26 17:35:55 and maybe ask in #musl 2018-11-26 17:36:20 heh, somehow that produces less of a backtrace than execing it with gdb 2018-11-26 17:36:32 hum 2018-11-26 17:36:34 interesting 2018-11-26 17:36:39 pthread_mutex_lock becomes ?? 2018-11-26 17:37:30 https://gist.github.com/joeholden/8d6d6302fffb818e40ca51431453e128 2018-11-26 17:38:15 so that doesn't look right... 2018-11-26 17:39:19 its dynamically linked anyway for no apparent reason 2018-11-26 17:41:17 looksl ike its replacing malloc with jemalloc 2018-11-26 17:41:33 yeah 2018-11-26 17:41:34 hm 2018-11-26 17:48:20 indeed 2018-11-26 17:48:28 see if you can configure it to use system malloc 2018-11-26 17:50:08 does jemalloc generally not work on musl or? 2018-11-26 17:50:16 gonna guess its for portability 2018-11-26 17:51:04 but also... upstream supplies musl binaries that work ok 2018-11-26 17:55:15 think I'll open an issue there as theres obviously something they're not bothering to mention or commit 2018-11-26 17:55:38 don't expect more than "musl is still unsupported" though 2018-11-26 18:32:56 ACTION sighs 2018-11-26 18:34:44 grub upstream is... interesting - turns out they expect initrd-$version, initramfs-$version.img, but not initramfs-$version (what we have) 2018-11-26 18:35:04 so grub is always broken (but it "works" by accident at a later stage; it just fails hilariously when you have btrfs multidevice) 2018-11-26 18:35:19 looks like this is an upstream problem though, I'll ask for a backport once that's solved :D 2018-11-26 20:58:05 ugh, what utter horribleness 2018-11-26 20:59:32 meh, will just package the binaries and keep it in a local repo, can't unpick this disaster 2018-11-26 21:07:59 umm, causes ldd to segfault too :D 2018-11-26 22:06:05 20:34:48 aports:master |William Pitcock| community/erlang: remove the two CORBA applications i somehow missed | http://dup.pw/aports/bf60bdaf 2018-11-26 22:06:14 lol :) i had a patch for that sitting around, completely forgot about it 2018-11-26 22:06:37 lots of stuff was moved into corba 2018-11-26 22:06:56 kaniini: latest release is 21.1.3 by the way 2018-11-26 22:07:16 er, latest patch 2018-11-26 22:08:06 eh, whatever, only major and minor matter in erlang since otp 17.0 2018-11-26 22:11:50 i did not see 2018-11-26 22:11:57 i will update it later 2018-11-26 22:12:13 my reasons for going to OTP 21 were selfish 2018-11-26 22:12:29 namely, Alpine is the recommended way of deploying Pleroma 2018-11-26 22:12:45 and Alpine edge was broken with Pleroma because OTP 20 was broken with OpenSSL 1.1 2018-11-26 22:12:55 apparently the backport was incomplete ;) 2018-11-26 22:13:13 figured as much :) i use erlang a lot too 2018-11-26 22:13:19 well, i actually program a lot of erlang 2018-11-26 22:13:42 but that's pretty interesting, alpine is recommended by name? 2018-11-26 22:13:52 yes danieli it is not that surprising 2018-11-26 22:13:57 my shit recommends my other shit 2018-11-26 22:13:59 go figure 2018-11-26 22:14:05 good point 2018-11-26 22:14:05 SELF DEALING OMG 2018-11-26 22:14:10 dogfooding (y) 2018-11-26 22:14:32 slightly off topic, but whatever: haven't seen you around a lot lately, how have you been? 2018-11-26 22:14:56 have been busy with network reimplementation project 2018-11-26 22:15:20 your network at home? (essentially a DC as far as I've understood) 2018-11-26 22:15:23 20 POPs, complete replacement of network core with new juniper mx10000 equipment from brocade mlxe 2018-11-26 22:15:30 hohoho god damn 2018-11-26 22:15:41 that's some pretty juicy gear 2018-11-26 22:15:45 also i dont use irc that much anymore 2018-11-26 22:16:41 fair enough 2018-11-26 22:16:59 activitypub is the new hotness 2018-11-26 22:17:15 yeah, i've checked it out, but haven't gotten into it 2018-11-26 22:17:22 apropos network, have you played with the newer mellanox gear? 2018-11-26 22:17:40 their 100G gear is doing pretty well for itself 2018-11-26 22:17:47 the vendor kinda grew on me 2018-11-26 22:17:54 kaniini: does activitypub handle the moving-servers problem? 2018-11-26 22:18:23 SpaceToast: not yet. i have a proposal to solve this with new as:alsoKnownAs property 2018-11-26 22:18:23 because that was (and still is, though they're working on it) my issue with OSocial implementations (and does pleroma do anything about it? :D ) 2018-11-26 22:18:28 nice :D 2018-11-26 22:18:33 but the crypto dweebs want to shove crypto in it instead 2018-11-26 22:18:44 nevermind that irrevocable signatures are really problematic 2018-11-26 22:19:51 I hope they're at least trying to shove pubkey crypto, rather than blockchain 2018-11-26 22:20:05 yes, pubkey 2018-11-26 22:20:07 lol 2018-11-26 22:20:15 with an irrevocable signature scheme called JSON LDS 2018-11-26 22:20:21 LDS = Linked Data Signature 2018-11-26 22:20:28 the problem with the whole linked data thing is 2018-11-26 22:20:32 when linked data worms eat into your brain 2018-11-26 22:20:37 you want to solve all things with linked data 2018-11-26 22:20:44 instead of questioning whether or not you *should* 2018-11-26 22:20:50 has *no* one learned from PGP? 2018-11-26 22:20:51 this is similar to docker 2018-11-26 22:21:18 and other technologies 2018-11-26 22:21:27 gotta justify the tech by using it to solve all problems 2018-11-26 22:22:46 anyway, I wasn't aware pleroma was a thing, definitely less questionable than mastodon for me, nice coincidence I saw that kaniini :) might pass by #pleroma if I find the time/will to set that up 2018-11-26 22:23:12 but yeah re: pubkey, revokability is kind of important (and easy, given how simple non-x509 pubkey can be) 2018-11-26 22:24:56 my proposal was to allow blind key rotation, but mastodon does not really like such things ;) 2018-11-27 14:09:30 hi guys! super rude question to you ncopa as maintainer for pdns-recursor, any idea when you can update the package to the 4.1.8 version just released by pdns? 2018-11-27 14:10:09 i just realised i probably should first build it myself to see if it even werks at all :+ 2018-11-27 14:12:28 <_ikke_> xorex: It would help if you could indeed try to update it yourself and provide a patch 2018-11-27 14:13:53 kk! will do, also i also misread the maintainer on that package, is there some delete function in irc so i can save face? 2018-11-27 14:14:29 <_ikke_> ha, no, there isn't :P 2018-11-27 14:20:06 i will look at it 2018-11-27 14:23:26 few days ago I asked qustion on #alpine-linux (but didn't got useful answer) about ash shell expansion. Is it ok to ask this question here? 2018-11-27 14:23:48 related to abuild 2018-11-27 14:25:31 i.e. ash doesn't expands 'rm -f pkg/pkgname/{a,b,c}' 2018-11-27 14:25:46 <_ikke_> mps: so just expand it yourself 2018-11-27 14:25:50 <_ikke_> or use a loop 2018-11-27 14:26:13 <_ikke_> mps: or convince ash to implement it 2018-11-27 14:26:20 _ikke_: I know, but that's a cumbersome 2018-11-27 14:26:56 <_ikke_> mps: That's just how it is 2018-11-27 14:27:06 I'm puzzled because I see in some packages there is such lines 2018-11-27 14:27:17 <_ikke_> what packages? 2018-11-27 14:27:48 linux-firmware/APKBUILD: rm -f "${pkgdir}/usr/lib/firmware/{Makefile,README,configure,GPL-3}" 2018-11-27 14:31:24 <_ikke_> Maybe that's just broken, but not surfacing due to the -f 2018-11-27 14:36:53 _ikke_: could be. ok. will put multiple lines in APKBUILD 2018-11-27 14:37:58 <_ikke_> rm -rf "$dir/a" "$dir/b" "$dir/c" 2018-11-27 14:39:43 yes, but will look ugly for long path/filename 2018-11-27 14:42:44 mps: for x in a b c; do rm -rf "$dir/$x"; done 2018-11-27 14:42:59 (aka "or use a loop", as per _ikke_ :) ) 2018-11-27 14:45:12 SpaceToast: good idea. will try 2018-11-27 14:46:12 ACTION wondering how didn't thougt about that 2018-11-27 14:48:58 likely because you're used to {} existing :) 2018-11-27 14:50:18 probably :) 2018-11-27 14:57:32 older versions link 404's https://wiki.alpinelinux.org/cgi-bin/dl.cgi 2018-11-27 15:08:20 BitL0G1c: that has been broken for some time, I believe 2018-11-27 15:10:24 I thought supported that now or am i going mad 2018-11-27 15:10:38 nope, mad 2018-11-27 15:21:47 mps: i think linux-firmware/APKBUILD is broken 2018-11-27 15:26:23 BitL0G1c, which ref still uses dl.cgi? 2018-11-27 15:26:38 i think i removed it from wiki because i thought it was EOL 2018-11-27 15:29:23 ah i found it 2018-11-27 15:29:38 ill replace it with dl-cdn 2018-11-27 15:32:41 clandmeter - bottom of download page https://alpinelinux.org/downloads/ 2018-11-27 15:33:20 aaah 2018-11-27 15:34:35 BitL0G1c, fixed thx. 2018-11-27 15:36:50 ncopa: aha, should be fixed. does it need bug issue or new aports request 2018-11-27 16:02:48 Thank you 2018-11-27 16:03:00 @ncopa 2018-11-27 18:55:53 Hello there 2018-11-27 18:58:46 hello 2018-11-27 18:59:39 Not sure whether this is in scope of the project but I was looking to see if I could get Alpine running on the Nintendo 3DS 2018-11-27 19:00:07 An existing Linux kernel port exists and it boots nicely with buildroot, although there's currently no networking 2018-11-27 19:00:20 nor r/w storage support 2018-11-27 19:01:25 apologies, had to refresh 2018-11-27 19:01:39 i mean, you're free to do that, i guess? 2018-11-27 19:02:31 true, I was just wondering whether there's tooling to build an Alpine rootfs 2018-11-27 19:04:16 <_ikke_> alpine minirootfs exists 2018-11-27 19:04:23 <_ikke_> so there is tooling around it 2018-11-27 19:06:10 I'll take a look into that and maybe pop back once I've done some reading 2018-11-27 19:06:14 Thanks(: 2018-11-27 19:06:51 <_ikke_> Reversed smiley strikes again :P 2018-11-27 19:07:05 Indeed haha 2018-11-27 19:07:10 P: 2018-11-27 19:07:18 <_ikke_> q: 2018-11-28 09:05:08 is there a way to find firmware dependencies from the kernel image like modinfo does for modules? 2018-11-28 10:17:09 clandmeter: yes 2018-11-28 10:18:54 oh, sorry, i misunderstood the question 2018-11-28 10:19:04 no, i dont know.... 2018-11-28 10:19:13 :) 2018-11-28 10:19:42 so there is actually now way to determine which fw we actually need? 2018-11-28 10:19:53 no* 2018-11-28 10:20:01 thats how i understand it, yes 2018-11-28 12:19:11 if there are dkms like things on alpine? 2018-11-28 12:23:29 a possible way is add triggers like this: triggers="$pkgname.trigger=/usr/share/kernel/*" ,just don't know if there are better option 2018-11-28 13:46:13 yangxuan: we dont have any dkms like thing on alpine 2018-11-28 13:58:18 ncopa: then how we package some drivers like broadcom-wl: https://www.archlinux.org/packages/community/x86_64/broadcom-wl/ 2018-11-28 14:30:23 we normally package those as 3rd party driver module packages 2018-11-28 15:06:44 im working on gcc6 so we can have a gcc6-java 2018-11-28 15:06:52 im making progress: 2018-11-28 15:06:59 ncopa-edge-x86_64:~/test$ gcj-6 --main=HelloWorld HelloWorld.java 2018-11-28 15:06:59 ncopa-edge-x86_64:~/test$ ./a.out 2018-11-28 15:06:59 Hello, World 2018-11-28 16:04:10 ncopa: not sure if this is useful to you, but we also have a gcc6 package in postmarketOS for compiling old kernels. it uses .configure --prefix=/usr/gcc6 and a few hacks to work side by side with the regular gcc 2018-11-28 16:04:11 https://gitlab.com/postmarketOS/pmaports/blob/master/main/gcc6/APKBUILD 2018-11-28 16:04:22 *./configure 2018-11-28 19:20:33 ncopa: is gcc6 still broken? 2018-11-29 06:48:25 sort of works now 2018-11-29 08:53:07 morning 2018-11-29 10:45:49 ncopa: what's the proper way to include ld_library_path in alpine? 2018-11-29 11:08:12 ncopa, do we want to ship wireguard with 3.9? 2018-11-29 11:20:32 possibly 2018-11-29 11:20:42 depends on upstream 2018-11-29 11:21:14 we need a stable upstream release 2018-11-29 14:33:15 sort of, lol 2018-11-29 14:57:33 I think that the wireguard stable release will wait for official kernel inclusion 2018-11-29 15:03:35 its kind of hard now to use it without switching to edge kernel. 2018-11-29 15:05:15 it works quite well with 4.18 kernel on one of my armhf server 2018-11-29 15:06:34 edge kernel is at 4.14 atm 2018-11-29 15:08:32 danieli: I know, but I made 4.18 because needed some new features for that SBC 2018-11-29 15:09:10 if everything builds against it and it works properly, I can't see why not 2018-11-29 15:09:17 but I use wireguard-tools from testing 2018-11-29 15:11:51 a week ago (or maybe two) tried to build 4.19 kernel with new wireguard but had some problems and left it to try later 2018-11-29 15:12:03 I use it just fine on edge kernel 2018-11-29 15:12:08 on a daily basis 2018-11-29 15:13:04 probably will try to rebuild it this weekend because want to have CAKE queue 2018-11-29 15:14:17 it is quite stable for about two years (approximately) in my use on few different machines 2018-11-29 15:14:52 it is included in openwrt where it works quite fine 2018-11-29 15:19:22 are you using it on inbound as well? 2018-11-29 15:19:32 yes 2018-11-29 15:19:41 I heard there were some issues around the time of upstreaming (though I don't recall what they were...) 2018-11-29 15:20:08 would be nice if you didn't need IFB juggling to get inbound tc, but that's not what CAKE's really about anyway 2018-11-29 15:20:49 you are talking about CAKE? 2018-11-29 15:25:57 yes, the new codel, I just had mild hopes qdisks would be able to run bidirectionally without an intermediary device (ifb); do ignore me I have a tendency to ramble and swap topics quickly (and to most unpredictably) 2018-11-29 15:28:10 no, just misunderstood your question about 'are you using it on inbound as well', thought that you mean wireguard 2018-11-29 15:28:24 oh, I see 2018-11-29 15:28:44 and now I'm wondering how one would use wireguard outbound-only 2018-11-29 15:29:06 tried CAKE just once, but didn't had time to play with it 2018-11-29 15:30:38 never mind, I'm not native speaker, so sometimes I'm telling something wrong, and sometimes misunderstand what someone says 2018-11-29 16:55:36 ncopa, please upgrade https://github.com/alpinelinux/aports/pull/5740 2018-11-29 18:26:18 danieli: around ? 2018-11-29 18:26:28 vkrishn: yup, why? 2018-11-29 18:26:31 kinda new to erlang, was trying to install phoenixframework.org, but seems it needs some deps not in al, any guide would be helpful 2018-11-29 18:26:41 right, that's an elixir library 2018-11-29 18:26:52 yes, build with elixir 2018-11-29 18:26:56 see if you can pull and run it via hex.pm 2018-11-29 18:27:43 think it needs ranch/rebar3 2018-11-29 18:27:51 but cannot compile it 2018-11-29 18:28:02 should be able to just use mix, bundled with elixir 2018-11-29 18:28:07 rebar3 is an erlang tool 2018-11-29 18:28:15 yes, its in testing 2018-11-29 18:29:54 http://tpaste.us/lZZ6 2018-11-29 18:30:24 ah, right, it's using rebar3 to compile 2018-11-29 18:30:34 could you paste the stack trace? 2018-11-29 18:30:47 http://tpaste.us/dkkL 2018-11-29 18:31:26 kaniini: you didn't build rebar3 against otp 21, did you? 2018-11-29 18:31:35 i did not yet 2018-11-29 18:31:43 if you want to work on it i'll merge it for you 2018-11-29 18:31:48 that might just be it if it's using precompiled .beams 2018-11-29 18:32:23 Pleroma (because of Phoenix/Elixir) downloads its own copy of rebar3. I was unable to make it use system rebar3. 2018-11-29 18:32:32 so I lost interest in the package ;) 2018-11-29 18:33:01 fair enough 2018-11-29 18:33:11 you're just pulling rebar3 from their s3 bucket? 2018-11-29 18:33:18 that magic .zip 2018-11-29 18:33:23 s/.// 2018-11-29 18:33:23 danieli meant to say: that magic zip 2018-11-29 18:37:55 no i rebuild it from source 2018-11-29 21:00:21 What happened to gcc6 on armhf and aarch64? 2018-11-29 23:06:09 lol wtf 2018-11-29 23:06:29 clandmeter / _ikke_: why can I not see issues in the Alpine Linux project when I'm logged in? 2018-11-29 23:06:43 I have to log out to see them.. 2018-11-29 23:09:52 should probably get rid of #9699 and #9721 since they don't make sense as real bugs 2018-11-30 00:42:14 How to deal with dual licences? https://github.com/alpinelinux/aports/pull/4944#discussion_r237703170 2018-11-30 00:43:25 <[[sroracle]]> "OR" instead of "AND" 2018-11-30 01:14:18 hello 2018-11-30 01:14:59 any plans to upgrade nodejs to latest LTS - 10.14 2018-11-30 05:37:54 <_ikke_> danieli: I've added you to the projects, you should now be able to see them 2018-11-30 08:57:05 ncopa: FYI: build-edge-armhf is not listed on build.alpinelinux.org, and armhf and aarch64 are both stuck. I'd love to look into this more and help out, but I'm really busy atm (and I guess you are too, just making sure you are aware) 2018-11-30 09:44:38 ollieparanoid[m], im going to check it 2018-11-30 09:44:58 it looks like its doing erlang 2018-11-30 09:51:33 ollieparanoid[m], i killed erlang, so it will go on now. 2018-11-30 11:36:33 ncopa, what was providing java-gcj-compat? 2018-11-30 11:36:35 gcc? 2018-11-30 11:37:18 ah its its own pkg 2018-11-30 11:44:28 ncopa, do we need to change something in openjdk7 now that we have gcc6? 2018-11-30 14:14:48 hi, where can I find the project that continues grsecurity gpl? where is coordination organised for updates? thanks 2018-11-30 14:26:51 user234342: grsecurity.net is the only place afaik. we dropped grsec a year ago 2018-11-30 14:27:50 we did unofficial grsecurity port a while ago, the we used minipli's and then we dropped it 2018-11-30 14:30:19 clandmeter: we need fix java-gcj-compat 2018-11-30 14:40:36 ncopa: community/hugo's currently woefully out of date, and I suspect it's because a lot of its tests fail when they're not in a git repo. Disabling them through patches has become unmaintainable, since more get added over time, but snapshot uses git-archive which strips .git. 2018-11-30 14:41:12 What would you rather do? (I have !check in my personal repo, but I'd obviously rather just have the ability to git-checkout and let the tests run, but I don't see how that's possible with current abuild) 2018-11-30 15:47:35 _ikke_: I'm still wondering why I was removed(?) in the first place 2018-11-30 15:48:14 The strange thing is that being not-signed-in (aka a guest) gives more rights (e.g read to those bugs) than being signed in. 2018-11-30 15:48:42 (I experience the same thing ; now admittedly I don't care much about those bugs in particular, but the above seems to point to a strange occurence) 2018-11-30 16:01:41 <_ikke_> danieli: No idea 2018-11-30 16:39:06 any chance to get crystal 0.27 in next stable? Is jirutka still active in AL development? 2018-11-30 16:45:13 <_ikke_> mps: only for personal use 2018-11-30 16:47:49 _ikke_: mind to share APKBUILD for new version, if you have it 2018-11-30 17:07:06 <_ikke_> was referring to jirutka 2018-11-30 17:09:00 never mind, just made it with some tweaks in APKBUILD. Now have to test how it works 2018-11-30 17:13:38 'crystal -v' gives: Crystal 0.27.0 [8c3bc20105] (2018-11-30) 2018-11-30 17:20:47 and it passed my tests. It could be included in next stable, imo 2018-11-30 17:46:06 SpaceToast: maybe just disable tests? 2018-11-30 17:46:42 That's what I have in my personal repo, yeah, but it certainly feels wrong - disabling all tests because a (variable) percentage of them requires a normally available environment :/ 2018-11-30 18:29:55 clandmeter: thanks, now it appears again in the list, and it looks like it has gotten a bit further (stuck again though) 2018-11-30 19:55:36 SpaceToast, there's existing PR for hugo https://github.com/alpinelinux/aports/pull/5293 2018-11-30 19:55:58 andypost: 0.51 is out as well 2018-11-30 19:56:13 and just bumping the old pkgbuild fails 2018-11-30 19:56:18 and 52 too) 2018-11-30 19:56:21 (because the test suite changes) 2018-11-30 19:56:51 I stuck on tests s well when used to try update 2018-11-30 19:56:52 ok, I seem to have missed 52 (I was making the 51 pkgbuild for myself right around that time) 2018-11-30 19:57:42 andypost: basically, they enforce git tests, but abuild will never keep .git, so they all fail. There's a patch that tries to disable some of them in the current APKBUILD, but it needs updating (and I don't think manually patching out a bunch of tests is a good solution) 2018-11-30 19:58:36 SpaceToast, maybe easy to have a file with disabled-tests.list 2018-11-30 19:59:00 I'm not aware of Go allowing you to disable arbitrary tests 2018-11-30 19:59:10 I took a look at maybe just removing the affected files, but they're sprinkled all over the place