<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:20 blueness joined
00:42 StarWarsFan|afk joined
00:55 tmh1999 joined
01:37 tmh1999 joined
01:40 xfix joined
01:58 s33se joined
02:20 doppo joined
02:24 tmh1999 joined
02:50 tmh1999 joined
03:10 lucybun joined
04:38 tmh1999 joined
05:33 fabled joined
05:56 tmh1999 joined
06:01 vakartel joined
06:13 <Shiz> https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.5.4-relnotes.txt
06:13 <Shiz> \o
06:13 <Shiz> >Switched Linux getrandom() usage to non-blocking mode,
06:13 <Shiz> this is a bug though
06:23 <clandmeter> ncopa, I think SPL is cache related iirc.
06:23 <clandmeter> ccache
06:24 <Shiz> >../source/Core/DataExtractor.cpp:(.text._ZNK12lldb_private13DataExtractor4DumpEPNS_6StreamEmN4lldb6FormatEmmmmjjPNS_21ExecutionContextScopeE+0x371c): undefined reference to `std::ostream& std::ostream::_M_insert<__float128>(__float128)'
06:24 <Shiz> this is a fun one
06:24 <Shiz> as we disable float128 on ppc
06:24 <Shiz> i think so at least?
06:38 tty` joined
06:42 blueness joined
06:43 tmh1999 joined
07:01 t0mmy joined
07:10 czart_ joined
07:16 tty` joined
07:20 blueness joined
07:43 __0xAX joined
07:48 consus joined
07:51 shansen joined
07:58 tmh1999 joined
08:06 blueness joined
08:25 tmh1999 joined
08:38 vakartel joined
08:48 cyteen joined
09:13 <pickfire> fabled: Why would I want to revert the mpv upgrade?
09:14 tmh1999 joined
09:14 <* pickfire> checks it's mail
09:22 <^7heo> pickfire: check the ml yeah
09:23 LongyanG joined
09:24 <pickfire> ^7heo: What? mpv broke? It works fine here.
09:44 tmh1999 joined
09:50 <^7heo> pickfire: I do not know in details but "it works on my machine" is typical of amateur distributions like arch; and we do not take that as valid QA
09:52 <^7heo> pickfire: please read the log for more info on why it broke and how it's been fixed
09:52 <^7heo> pickfire: ENOTIME here.
09:53 <pickfire> ENOTIME?
09:58 blahdodo joined
10:00 <fabled> pickfire, which video output driver? it was broke for me too (vaapi)
10:01 <Shiz> as in, he has no time himself
10:01 <Shiz> probably
10:10 tmh1999 joined
10:12 <pickfire> Ah
10:15 <Shiz> i wonder what the need to disparage other distros is for, though
10:55 fekepp joined
11:07 gromero joined
11:12 LouisA joined
11:17 blueness joined
11:23 blueness joined
11:27 tmh1999 joined
12:12 tmh1999 joined
12:14 farosas joined
12:16 czart joined
12:41 tmh1999 joined
12:48 <mosez> yay, looks like all my php apps on alpine docker containers are broken :(
13:11 <pickfire> fabled: I use vaapi
13:11 <pickfire> But it didn't break
13:20 <ncopa> mosez did you use edge?
13:35 lucybun joined
13:39 tmh1999 joined
13:43 <mosez> ncopa: yes
13:47 <ncopa> we do break things in edge once in a while
13:58 <mosez> but even a plain upgrade have not solved it... maybe it's time for a fixed version :(
13:58 <jirutka> <Shiz>: "Switched Linux getrandom() usage to non-blocking mode" – we can finally close one quite old bug report :)
14:01 <jirutka> ncopa: clandmeter: I’ve “accidentally” wrote a blogpost about Alpine mirror at vpsFree.cz :) but it’s in Czech: https://blog.vpsfree.cz/podporujeme-alpine-linux-ma-u-nas-hlavni-mirror/; I wrote accidentally b/c Petr Krcmar sent me an email asking for more information, so he can write a blog post, but then he published directly what I wrote him, just with minor modification XD so I revisited it later; however, it was actually very effective
14:01 <jirutka> approach to force me to write a blog post in less than few months :)
14:02 <jirutka> ncopa: clandmeter: let me know if you wanna translate it to English ;)
14:04 <ncopa> heh
14:04 <ncopa> its work in progress
14:05 <ncopa> i've modified the diagram a bit
14:05 <ncopa> tier1 mirrors are moved down a step
14:05 <ncopa> and we have a "mirror master" instead of the previous tier1
14:07 <clandmeter> jirutka, i updated the pdf
14:12 <jirutka> clandmeter: I think it does not matter for that blogpost, it’s isomorphic (i.e. just changed names) :)
14:12 <jirutka> but thanks for the update of the PDF :)
14:15 <ncopa> but blog post is not accurate
14:15 <ncopa> there will not be any tier3 mirrors
14:16 <ncopa> only tier1 and tier2
14:16 <ncopa> similar to this: https://fedoraproject.org/wiki/Infrastructure/Mirroring/Tiering
14:17 <ncopa> i just want make sure that when we in the future talk about the "tier1 mirrors" we talk about the same thing
14:17 <jirutka> uh, okay, I’ll sent Petr next update
14:17 <jirutka> well, I’ve just used the current version of the diagram (current at 3 AM today)
14:18 <ncopa> still nice with a blog post :)
14:18 <ncopa> thanks!
14:20 tmh1999 joined
14:21 <clandmeter> ncopa, did you see my msg about spl and ccache?
14:21 <ncopa> no?
14:21 <clandmeter> i think its related
14:21 <clandmeter> the builder probably has it installed en enabled?
14:22 <clandmeter> atleast i remember i have to disable ccache to make it build
14:27 <ncopa> clandmeter you mean on the s390x builder
14:27 <ncopa> ok i'll check if it is
14:27 <clandmeter> yes
14:28 fabled joined
14:29 <ncopa> the config.log of spl-vanilla on build-edge-s390x: http://tpaste.us/xWQv
14:29 <ncopa> interesting
14:30 <ncopa> its perl not found
14:32 <tmh1999> thanks
14:32 <tmh1999> ha
14:33 <tmh1999> yeah
14:33 <ncopa> i wonder if its linux-vanilla-dev that should have it as dependency
14:33 <ncopa> or if it is spl
14:34 <ncopa> declaration M=/home/buildozer/aports/main/spl-vanilla/src/spl-0.6.5.9/build
14:34 <ncopa> that one looks wrong too
14:36 <ncopa> no. its correct
14:36 <tmh1999> I thought it means to build kernel module of spl-vanilla
14:40 <ncopa> yes
14:40 <ncopa> it looks like its linux-vanilla-dev that needs perl in its depends
14:40 <tmh1999> so installing perl help the build ? I just tried to remove perl to build and got the same error. with perl ok.
14:40 <tmh1999> yeah
14:40 <ncopa> just weird that it does not happen on x86_64
14:41 <ncopa> ok lets add it to linux-vanilla-dev
14:41 <tmh1999> thank you
14:41 <tmh1999> I gotta run. it's finals week here. I will be back later to work on remaining packages on community.
14:42 <ncopa> thakns!
14:55 <ncopa> i wonder if should try catch the builder's errors better
14:55 <ncopa> eg fix build.alpinelinux.org page
14:55 <ncopa> its currently not very visible if builder is actually building or if it choke on some error
15:01 farosas joined
15:06 <xentec> building cross compiler broke again... could you please install some ci for them in the near future?
15:07 <xentec> hier is the fix for current breakage btw. https://gist.github.com/xentec/81856fc05d32bbaa8f8c7df9d3a0c672
15:14 <clandmeter> fabled, did you update gcc? ^
15:23 BitL0G1c joined
15:28 <TemptorSent> jirutka - Reading backlog -- what about getrandom and non-blocking mode?
15:30 D630 joined
15:30 <TemptorSent> Do all places using getrandom currently handle th EAGAIN properly?
15:58 FilippAndronov joined
17:03 t0mmy joined
18:34 blueness joined
18:45 <jirutka> clandmeter: ncopa: the blog post is updated, now it reflects the latest version :) https://blog.vpsfree.cz/podporujeme-alpine-linux-ma-u-nas-hlavni-mirror/
18:48 <jirutka> fabled: xentec: I can confirm that, I’ve also tried script/bootstrap.sh yesterday, fixed one breakage in binutils package, but then hit another problem
18:49 jasonwhite joined
18:49 <jirutka> fabled: maybe i’d be better to move bootstrapping script(s) to a separate repository, write tests and let them run on CI
18:49 <fabled> jirutka, i've liked to keep it in aports because bootstrap.sh has repository specific knowledge (package ordering, and list of packages which changes across branches)
18:50 <jirutka> fabled: good point
18:53 <jirutka> ncopa: clandmeter: Petr Krčmář has informed me that we have 22 installations of Alpine Linux on vpsFree! that’s not very big number (there are 1 620 VPSes in total), but it increased from 4 to 22 in the last half-year :)
18:54 <ncopa> thats interesting
18:59 leitao joined
19:06 poisonville joined
19:23 blueness joined
19:44 <jirutka> clandmeter: heh, right after we published info about mirrors tearing, I read news on root.cz that mirror of Arch Linux on Silicon Hill (student’s club and network at CTU in Prague) has been moved from Tier 2 to Tier 1 :) from the context I assume that they use the same naming as Fedora and as you proposed, i.e. Tier 1 is *not* the mirror master /cc ^7heo (but please don’t open a flame)
19:50 <jirutka> lol, this is almost ridiculous… MySQL and Oracle… what can possibly be wrong XD http://www.openwall.com/lists/oss-security/2017/05/03/10
20:29 fekepp joined
20:54 <clandmeter> anybody using bonding with alpine linux?
20:54 <_ikke_> have used it
20:55 <clandmeter> which mode?
20:55 <_ikke_> active-backup
20:55 <jirutka> I used to use bonding on Gentoo few years ago and I had a lot of troubles with that; not with configuration, that was easy, but hard-to-troubleshoot problems on network
20:56 <clandmeter> i re-used the debian networking config, but that does not seem to work on alpine.
20:57 <_ikke_> clandmeter: Did you check https://wiki.alpinelinux.org/wiki/Bonding ?
20:57 <clandmeter> yes its very limited
20:57 <_ikke_> right
20:58 <jirutka> I was talking with one admin about that and he told me that implementation of bonding in kernel is not very good and he don’t recommend to use it and he said that if I need boding, then try to use Open vSwitch for that… we had bad experience with 1.x version, but he told me that it was really shitty, but 2.x is good… well, after few years experience with Open vSwitch, I don’t recommend even that…
20:58 <clandmeter> i need to use mode 4
20:58 <clandmeter> 802.3ad
20:58 <jirutka> but we used Open vSwitch for use case where it was quite an overkill
20:59 <jirutka> I should be still able to configure it on Gentoo with netifrc, but I have no idea how to do that with debian-style config we have in Alpine
20:59 <clandmeter> would be nice to get it working on alpine
21:00 <jirutka> ofc :)
21:00 <clandmeter> 20Gbit sounds sweet :)
21:00 <jirutka> but unfortunately I don’t know, I have still some minor trouble even with basic network configuration with multiple interfaces on Alpine, not even talking about bonding
21:01 <jirutka> and also I haven’t studied what “magic” netifrc actually do behind the scene
21:01 <jirutka> 20 Gbps sounds good, but really, do we need it? I don’t think so :)
21:02 <jirutka> 10 Gbps is still way more we actually need imo
21:02 <clandmeter> if you get it, why not use it?
21:02 <_ikke_> 10gb is quite a lot
21:02 <jirutka> yes, I’d also try it…
21:04 <jirutka> but don’t be so crazy as me to waste time on something you just *want* to get working, no matter if you actually need it, just because you refuses to give up… :)
21:04 <clandmeter> its the only way to get things working ;-)
21:05 <jirutka> yes, but the important part is “no matter if you actually *need* it” :)
21:06 <jirutka> sometimes I spend a lot of time on solving some issue and when I get it and *after* that I start thinking if it’s really the best solution and the thing I really want :)
21:07 <xentec> is an apk dev present right now?
21:07 <clandmeter> there are so many settings to bonding.. i should have checked the debian install more carefully
21:07 <jirutka> xentec: you mean fabled?
21:08 <jirutka> clandmeter: yeah, there are multiple modes how to set it up and it *must* be the same that is configured on the switch
21:17 <xentec> well fabled then :) I ask you to look at following apk trace: https://dpaste.de/rH4g#L1,2420,2422,2423 (specifically the lines)
21:18 <xentec> I wanted to fetch a meta-package (with no cache enabled) but apk refuses to do even though it was able to install it
21:18 <jirutka> hmm, this is very nice pastebin service!
21:18 <clandmeter> he is probably sleeping already.
21:19 <xentec> then I hope he'll read it tomorrow.. because to me it looks like a strange bug
21:19 <jirutka> ah, I’ve already stared it on GH some time ago… it’s unfortunately based on Django… ./
21:20 <jirutka> xentec: what exactly “Reply to this snippet” do?
21:21 <xentec> probably creating a new paste with a link to the old one.. I don't use it often ;)
21:21 <xentec> the site I mean
21:22 blueness joined
21:22 <jirutka> xentec: I see, it’s more similar to Gists than classic Pastebin
21:24 <jirutka> I think that I’ll start to use it as default pastebin when I need to paste something from web browser :) (I use our tpaste.us for pasting from terminal)
21:24 <xentec> fabled: strangly enough alpine-base downloads just fine
21:24 <clandmeter> jirutka, you can also paste from browser with tpaste
21:24 <jirutka> clandmeter: huh, how?
21:25 <clandmeter> check tpaste.us
21:25 <clandmeter> it has a form link
21:25 <jirutka> aha, I totally overlooked this XD
21:25 <clandmeter> :)
21:25 LouisA joined
21:25 <jirutka> heh, interesting hack!
21:26 <jirutka> clandmeter: btw you should fix the link, you’ve moved the repo… ;)
21:27 <clandmeter> i need to fix this bond ;-)
21:27 <clandmeter> no not james bond
21:27 <clandmeter> :p
21:27 <clandmeter> is it a kernel option to configure network drivers with ethtool support?
21:28 <jirutka> btw do you remember that outage few days ago? I realized that I depend on tpaste too much, I literally cannot work without it…
21:28 <clandmeter> :)
21:28 <clandmeter> the counter is going up :)
21:28 <jirutka> it’s extremely convenience
21:29 <clandmeter> and fast :D
21:29 <clandmeter> that reminds me
21:29 <clandmeter> i saw some strange piece of code in lua turbo
21:29 <clandmeter> maybe just a typo
21:30 <clandmeter> interesting, it says no link.
21:32 <jirutka> I even shut down my previous paste service already, b/c it needed whole script for pasting and after moving from Gentoo to Alpine I started to be like “wtf, why i should install so much bloat just to paste?” and even copying shell scripts to all servers is still bad in comparison with copying one short curl command
21:33 <jirutka> now I have alias tpaste in my default .profile
21:34 <clandmeter> apk add tpaste is not ok?
21:34 <jirutka> heh, I didn’t know about it XD
21:34 <xentec> jirutka, what reason puts https://github.com/alpinelinux/aports/pull/1250 on 'hold'? :)
21:35 <jirutka> xentec: we haven’t settled on how to treat rust packages yet
21:35 <xentec> too bad
21:35 <jirutka> xentec: and we don’t want to let any third-party package manager download dependencies from Internet
21:37 <jirutka> I have already some proof-of-concept solution, but we haven’t discussed it yet; https://gist.github.com/jirutka/59be5141dd442abcbc183431e0cef8eb
21:37 <xentec> damn
21:39 <xentec> I guess it's even more complicated with go
21:39 <clandmeter> jirutka is a big fan of go :)
21:41 <jirutka> go is total mess, but they converged to “vendoring” dependencies, i.e. the most stupid thing, literally copying sources of all dependencies into the project’s repository; however, despite the fact that it’s plain stupid, it’s very simple for us for packaging
21:42 <clandmeter> that is what makes cargo so slow...
21:42 <jirutka> what?
21:42 <clandmeter> pulling in deps
21:42 <xentec> heh.. and I thought it's a syncthing.. thing
21:42 <xentec> speaking of which.. what about this PR? https://github.com/alpinelinux/aports/pull/1286 :D
21:43 <jirutka> to be honest, cargo already do the right thing (not by default, but with options) – Cargo.lock contains exact versions of all dependencies, including checksums, and they are validated when fetched, so basically the same verification we do in abuilds
21:43 <clandmeter> but its slow...
21:43 <clandmeter> and rust is also slow
21:44 <clandmeter> so its really slow
21:44 <jirutka> that’s bullshit
21:44 <clandmeter> did i mention its slow?
21:44 <xentec> you mean rustc?
21:44 <clandmeter> yes
21:44 <jirutka> Rust is not slow
21:44 <jirutka> wait, so what exactly do you mean that is slow?
21:44 <xentec> rust is as slow as c++14 :D
21:44 <jirutka> rustc like compiler?
21:44 <clandmeter> yes
21:44 <clandmeter> building a rust pkg is slow
21:44 <jirutka> b/c programs written in Rust are definitely not slow
21:45 <jirutka> yes, it is, but not because of fetching deps
21:45 <jirutka> but compiling deps
21:45 <clandmeter> also fetching
21:45 <xentec> rustc is slow because it has shitton of checking
21:45 <clandmeter> i added librespot recently
21:45 <jirutka> and compiling is slow b/c it do many checks and optimizations, the thing C++ never heard of…
21:45 <clandmeter> and it felt slow
21:45 <clandmeter> to build that is.
21:45 <clandmeter> not running.
21:46 <jirutka> if you think that cargo is slow in fetching, then try https://gist.github.com/jirutka/59be5141dd442abcbc183431e0cef8eb … it uses curl to fetch deps and it’s like 100 times slower
21:46 <jirutka> it’s so extremely slow that I’m seriously considering how to use curl more efficiently in abuild or what else to use
21:47 <jirutka> also I think that you have confused fetching deps and fetching index
21:47 <xentec> jirutka, could you please reply about my syncthing pr? https://github.com/alpinelinux/aports/pull/1286 I'd like it to be in aports but you won't tell me what's missing
21:47 <jirutka> cargo must fetch index first, it’s cloning quite big git repo, so it’s indeed slow, then it fetches deps
21:48 <jirutka> everything is what fabled considering for APKINDEX sounds like nano-optimizations in comparison of cargo index… it was imo very stupid idea to do it in that way
21:49 <jirutka> but normally you don’t need to fetch whole index on every build…
21:51 <jirutka> xentec: A-improve doesn’t mean that you should improve something, but that this PR improves apkbuild ;)
21:51 <xentec> that I've figured out
21:52 <jirutka> okay, then it’s not that I don’t wanna tell you what’s missing, I just haven’t reviewed it yet and no one else ;)
21:53 <jirutka> currently I’m adding labels manually, but in mass to all new PRs, before I write a bot to do that instead of me :P
21:53 <jirutka> so when I’ve added the label doesn’t mean that I’ve ever read that PR
21:54 <jirutka> i’ll be hopefully more clear when algitbot start adding label right after PR is created, not me after some time
22:01 <jirutka> clandmeter: actually, maybe I was not clear enough :) curl is so horribly slow in comparison of cargo that it’s one of major reasons why I haven’t pushed that solution further and still thinking if it’s really reasonable to do that, instead of just letting cargo download deps with --frozen (i.e. it requires Cargo.lock and verifies checksums) :)
22:01 <jirutka> however, one of advantages of this solution is that it unpacks sources of all dependencies in $srcdir, so we are able to patch them if needed
22:04 <clandmeter> i just downloaded alpine extended in 1s
22:04 <clandmeter> seems alpine releases are not big enough to properly test network speed
22:05 <jirutka> I’m also considering naming the deps in APKBUILD (or more specifically, using script to gather them from Cargo.lock and write into APKBUILD) like Gentoo do, but I don’t like about it that we would end-up with very long generated list of names in APKBUILD that will just duplicate information from project’s Cargo.lock
22:05 <clandmeter> :)
22:05 <jirutka> heh
22:07 <jirutka> the thing I don’t like probably the most about my proposal is that it requires copying project’s Cargo.lock file into aports repo, to be able to fetch all deps in fetch phase and unpack the project’s tarball in unpack phase, not in fetch phase
22:10 <Shiz> jirutka │ <Shiz>: "Switched Linux getrandom() usage to non-blocking mode" – we can finally close one quite old bug report :)
22:10 <Shiz> no, because it's broken
22:10 <Shiz> and should be reverted
22:10 <jirutka> Shiz: aha
22:10 <jirutka> Shiz: broken in what way?
22:11 <Shiz> because it will lead to providing unsafe entropy
22:11 <Shiz> when the random pool isn't initialized yet
22:13 <jirutka> hm, so another bad commit from OpenBSD devs…? o.O
22:13 <Shiz> well
22:13 <Shiz> we've been wtfing at libressl's getentropy() for a while now
22:14 <jirutka> in what channel? :)
22:14 <Shiz> but basically, if getrandom() fails (which it will with this commit at boot), AND /dev/urandom fails, it will just gather a bunch of 'seemingly-random' data and tell you it's entropy
22:14 <Shiz> #musl, but that was like 2 years go
22:14 <Shiz> :P
22:14 <Shiz> see: https://github.com/openbsd/src/blob/edb2eeb7da8494998d0073f8aaeb8478cee5e00b/lib/libcrypto/arc4random/getentropy_linux.c#L339
22:14 <Shiz> it's just a bunch of nonsense
22:16 <jirutka> well, i don’t speak C, so most of C code, especially in OpenSSL/LibreSSL, looks like bunch of nonsense for me :)
22:19 <Shiz> hopefully you can at least see why getpid(), gettimeofday(), dl_iterate_phdr() and clock_gettime() aren't proper random entropy
22:19 <Shiz> :P
22:21 <jirutka> imo it may be good enough entropy when “true random” entropy is not stricly required
22:24 goberle_ joined
22:26 dfgg_ joined
22:26 pickfire_ joined
22:37 <Shiz> no
22:37 <Shiz> it is not
22:38 <Shiz> the correct solution is to wait, not to provide fake entropy that WILL be used in cryptographic operations
23:05 andypost joined
23:08 <jirutka> andypost: hi, long time no see you!
23:08 <jirutka> andypost: I need your help :)
23:12 <andypost> jirutka, hi there!
23:13 <andypost> jirutka, I seen you commited php7
23:13 <andypost> jirutka, but some clean-ups still could be ported
23:14 <jirutka> andypost: I’m gonna commit some now
23:14 <jirutka> andypost: do you know answer for the question in https://github.com/alpinelinux/aports/pull/1339#discussion_r114595859 ?
23:15 <TemptorSent> Shiz: Any thoughts on a good means of initilizing the entropy pool when we don't have a HWRNG or user activity? (Embedded/VM)
23:16 <andypost> jirutka, ah, pecl for pear!
23:16 <TemptorSent> IMHO, if getrandom fails, crypto startup should be delayed until it succeeds.
23:16 <jirutka> Shiz: ^ that’s pretty good question! is not very good entropy better than no entropy and so no encryption…? ;)
23:16 <TBB> there's no such thing as a good means in that scenario
23:16 <andypost> jirutka, basically build tools are required mostly always to compile src
23:17 <jirutka> andypost: the question is if pear somehow needs pecl
23:17 <andypost> jirutka, pecl & pear are just 2 package delivery tools
23:17 <TBB> although, if you can get any "good" entropy then you can pull /etc/init.d/urandom on it (save seed for next session)
23:17 <jirutka> andypost: or we can move pecl to a separate subpackage
23:17 <jirutka> TBB: I’ve tried that and IIRC it didn’t help at all
23:17 <andypost> jirutka, better separate because pecl is more recent but pear mostly tooo outdated code
23:18 <TemptorSent> TBB: I can think of several, but it requires reordering part of boot to get some at least reasonably unique if not random data to seed a PRNG.
23:18 <jirutka> TBB: andypost so pecl is a replacement for pear?
23:18 <andypost> jirutka, not
23:19 <andypost> jirutka, they are kinda orthogonal http://pear.php.net/ http://pear.php.net/
23:19 <andypost> jirutka, they are kinda orthogonal http://pear.php.net/ http://pecl.php.net/
23:20 <TBB> jirutka: could be it doesn't work, but that's basically how many distros try to circumvent the "not enough entropy" problem. naturally tho, if root is encrypted then it won't help early init
23:20 <TemptorSent> At the very least, using time to key a pair of PRNGs and using those to read random byte ranges from the kernel, xor them, and checksum the resut, then feed that to /dev/urandom.
23:21 Somasis joined
23:21 Somasis joined
23:22 <TemptorSent> Something so your initial entropy seed is not easily guessed, but still should be refilled with cryptographically secure entropy ASAP
23:23 <jirutka> andypost: hm, pear also mentions “extensions”, so both pear and perl extensions are compiled and so needs gcc, autoconf, …?
23:23 <andypost> jirutka, I actually can't remember when I used pear last time( it's not require build tools but pecl require
23:23 <andypost> jirutka, no! pear mostly php "none-compilable" (includable) code
23:24 <jirutka> andypost: and pecl is for compiled extensions…? or both…?
23:24 <andypost> jirutka, pecl is exactly compilable
23:26 <jirutka> andypost: okay, so -pear should depend only on php7-common and pecl on php7 gcc autoconf pcre-dev, right?
23:26 <andypost> jirutka, and pecl is most used
23:31 <jirutka> andypost: I’m gonna fix https://github.com/alpinelinux/aports/pull/1339#discussion_r114501722, https://github.com/alpinelinux/aports/pull/1339#discussion_r114503980, https://github.com/alpinelinux/aports/pull/1339#discussion_r114505813 and most likely https://github.com/alpinelinux/aports/pull/1339#discussion_r114522462 … anything else you think that should be ported?
23:32 <jirutka> andypost: and also any idea about: I totally don’t understand why php refuses to even build them together… There’s actually no problem with building them together, so I thought that they cannot be loaded together (and it even failed when I tried, but just b/c of order as you’ve said).
23:32 <jirutka> andypost: with them I mean recode and imap
23:33 <andypost> jirutka, that's total wtf, I can't find reason as well
23:34 <andypost> jirutka, that's probably could be caused by that some extensions works fragile when bundled, but php suggests to bundle default set of extensions
23:34 <jirutka> aha
23:35 <andypost> jirutka, http://php.net/manual/en/extensions.membership.php#extensions.membership.bundled
23:37 <andypost> jirutka, check here huge warning http://php.net/manual/en/recode.installation.php
23:37 <jirutka> andypost: also I’m thinking about adding some meta subpackage that would pull all extensions, for use cases when you have no idea what extensions some php crap needs and just want it to quickly try it without guessing or manually naming all subpackages; any idea how to name it?
23:37 <andypost> jirutka, in most distros it's php-common
23:38 <jirutka> or maybe metasubpackage for all extensions listed as “bundled” on the site you’ve referenced
23:38 <jirutka> I think that information on that site is incorrect, Tokenizer can be built as shared, I’ve done it…
23:39 <jirutka> and phar as well…
23:39 <jirutka> and sessions
23:39 <jirutka> aha, “with compilation options”
23:40 <jirutka> err, “cannot be left out of a PHP binary with compilation options”
23:41 <jirutka> hm, so maybe php7-core-exts for the ones on the “Core Extensions” list?
23:41 <jirutka> but php7-bundled-exts looks somehow wrong, b/c we don’t bundle them :)
23:41 <andypost> jirutka, I'm checking other distros
23:43 <jirutka> ad php-common, we already use it for configs… vakartel proposed to rename it to php-config, but I’d rather avoid renaming it, it may case a lot of confusion for users :/
23:44 <andypost> jirutka, yes, good point about rename
23:44 <jirutka> I’ve checked Fedora when I was rewriting it and they use different approach, they don’t separate every extension
23:45 blueness joined
23:46 <andypost> jirutka, I also find useless to separate bundled extensions cos average users expects this extensions enabled after "installing php7"
23:47 <jirutka> andypost: I don’t consider it useless, just it’d be nice to provide a metapackage to easily pull all extensions that are usually “bundled”
23:47 <andypost> jirutka, btw I faced many times with issues when php-apps supposes bcmath & gd extensions preinstalled
23:48 <jirutka> just need to figure out proper name for it :)
23:48 <jirutka> especially gd extension should be optional, b/c it has many dependencies
23:48 <andypost> jirutka, on other hand php7-gd require a lot of deps
23:49 <andypost> jirutka, but I expects just a few web-ui scripts that can process media without gd)