<     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 mmlb joined
00:50 mmlb joined
00:53 blueness joined
00:54 blueness joined
01:04 minimalism joined
01:05 mmlb joined
01:20 mmlb joined
01:42 s33se joined
01:46 mmlb joined
04:44 ppisati joined
05:17 black_ant joined
05:32 fabled joined
06:37 D630 joined
07:01 t0mmy joined
07:04 vakartel joined
07:09 royger joined
07:21 czart_ joined
07:58 black_ant joined
08:02 <clandmeter> kunkku, is there a way to globally disable logging in awall?
08:17 fekepp joined
08:22 <przemoc> apparently you cannot simply define logging class as false, you can use false as value of log attribute in filter/policy/packet-log rules. but you can temporarily change limit to 0/sec for logging rules you want to quiet down, and if you don't define your own logging classes, provide redefined _default
08:23 <clandmeter> i tried 0 but that makes iptables go mad
08:23 <clandmeter> what i dont want is iptables to fill up my dmesg
08:23 <clandmeter> so redirecting to ulog is also an option
08:23 <clandmeter> but i would also like to know if its just possible to disable it all together.
08:27 <przemoc> ok, haven't checked personally limit 0, good to know it wouldn't work. I'm not aware of such switch in awall, but it would be good thing to have, globally and per logging class with some dedicated attribute, possibly called: suppress
08:45 <clandmeter> you can set it per rule
08:46 <clandmeter> Filter and policy rules can have an attribute named log. If it is a string, it is interpreted as a reference to a logging class, and logging is performed according to the definitions. If the value of the log attribute is true (boolean), logging is done using default settings. If the value is false (boolean), logging is disabled for the rule.
09:08 vakartel joined
09:12 <fcolista> has anyone an idea on how to have a custom alpine iso? I need zfs-grsec on an usb
09:16 <przemoc> clandmeter: I wrote it already in the first ssentence. ;) the problem is that you have to change usage instead of definition, which is very cumbersome, so something like suppress in logging class would be much more useful than false in every rule using particular log class
09:18 <clandmeter> przemoc, ah ok missed that .
09:18 <clandmeter> yes, exactly what i mean.
09:28 rdutra joined
10:06 <przemoc> clandmeter: http://paste.przemoc.net/alpine/awall/0001-Log-Allow-skiping-ignoring-logging-classes.patch
10:06 <przemoc> if you want to disable everything, add "skip": true to all logging classes, including _default class
10:07 <przemoc> hth
10:11 <przemoc> I didn't want to use suppress name in the end, because it doesn't guarantee that packet matching that rule won't be logged, but only that it won't be logged with given logging class, it may still show up from other filter/policy rule with different logging class, that's why I think that skip better describes this feature
10:13 <przemoc> kunkku: http://paste.przemoc.net/alpine/awall/0001-Log-Allow-skiping-ignoring-logging-classes.patch - maybe you'll want to apply this patch, but I rather guess you may not like this approach
10:15 <przemoc> it's one line non-disruptive change, so you can easily add it yourself in /usr/share/lua/5.1/awall/modules/log.lua w/o building awall yourself
10:15 <przemoc> clandmeter: ^
10:16 blueness joined
10:27 <jirutka> Shiz: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/libc++/libc++-4.0.0-r0.log ಠ_ಠ
10:29 <clandmeter> przemoc, that seems to work. thx
10:34 <przemoc> good. I tested it only as far as calling `awall diff`, because I don't want to lose logs.
10:40 <Shiz> jirutka: seems like your new lit subpackage is fucked
10:40 <Shiz> :D
10:40 <jirutka> Shiz: no, it seems that you’ve missed dependency on py-setuptools
10:40 <fcolista> jirutka, have you tried mkimage.sh so far?
10:40 <jirutka> Shiz: also all tests fail for libc++abi on my machine :( how you get it pass?
10:41 <jirutka> fcolista: what mkimage.sh?
10:41 <Shiz> jirutka: that's odd...
10:41 <Shiz> jirutka: i'll look at it when home
10:41 <fcolista> jirutka, one of the scripts in abuild to create an iso
10:41 <clandmeter> not in abuild, aports
10:41 <fcolista> this doc:
10:41 <jirutka> fcolista: not yet
10:41 <fcolista> https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image
10:41 <fcolista> right, aports
10:41 <fcolista> so that doc is old
10:42 <fcolista> anyone tried so far?
10:42 <clandmeter> i think i did :)
10:42 <fcolista> If i want to create a custom ISO with Alpine, how to do that?
10:42 <fcolista> clandmeter, :)
10:42 <jirutka> clandmeter: https://github.com/alpinelinux/aports/commit/b2055137c428ca6c6d5ebe7abe3568ba1312a020 ?
10:43 <clandmeter> ?
10:43 <jirutka> clandmeter: why have you reverted it?
10:43 <clandmeter> is that a question?
10:44 <clandmeter> hmm
10:44 <clandmeter> isnt it included in python3?
10:44 <jirutka> clandmeter: yes, it’s your commit, without any useful commit message :/
10:44 <przemoc> actually apparently I do lose logs, because when I have many logs from iptables, my messages-$DATE.gz are very short, like dozens of lines only. damn, I don't have willpower now to debug it.
10:44 <jirutka> clandmeter: that’s what I’m trying to figure out, if it’s included in python3 or not
10:44 <clandmeter> i think it is
10:45 <clandmeter> and yes, i should have written an better commit msg. sorry about that.
10:45 <jirutka> aha, yeah /usr/lib/python3.6/ensurepip/_bundled/setuptools-28.8.0-py2.py3-none-any.whl
10:46 <clandmeter> przemoc, do you use ulog?
10:46 <jirutka> that reminds me that problem with bundled wheels in python3, Miro Hrončok from Fedora told me about it some time ago, they somehow solved it in Fedora
10:47 <jirutka> it seems that I must let builders rebuild llvm4 again, b/c of missing dependency in subpkg :(
10:48 <przemoc> clandmeter: no, I didn't change the deafult here, so log mode is used, i.e. in-kernel logging
10:48 <clandmeter> you are burning the earths fuel with those rebuilds ;)
10:49 <clandmeter> przemoc, right.
10:49 <jirutka> Shiz: it’s better for libc++ tests, only 4 unexpectedly fail
10:50 <jirutka> clandmeter: yeah, it’s quite silly, but hacking pkindex is probably not an acceptable option :/
10:52 <jirutka> clandmeter: at least your machine is mostly powered from renewable sources, right? NL use wind power a lot IIRC
10:52 <clandmeter> jirutka, you are absolutely incorrect :p
10:52 <jirutka> clandmeter: why so?
10:52 <clandmeter> i think nl has the worse green energy in europe
10:53 <clandmeter> or one of them
10:53 <jirutka> clandmeter: uh, that’s bad
10:55 <clandmeter> we do have a lot of wooden shoes
10:55 BitL0G1c joined
10:55 <jirutka> XD
10:55 <clandmeter> i bet Shiz has a pair of them ;-)
10:56 <clandmeter> seems only France is worse...
10:57 <Shiz> jirutka: what did you change?
10:58 <Shiz> jirutka: oh libc++ nvm
10:58 <jirutka> Shiz: please see git log, I’ve described it ;)
10:58 <Shiz> yeah 4 is about right
10:58 <Shiz> i fixed most the failing tests
10:58 <Shiz> but some are due to the make check happening in fakeroot
10:58 <jirutka> Shiz: I haven’t changed anything in libc++
10:58 <Shiz> which is too permissive
10:58 <jirutka> Shiz: got it, but why ALL libc++abi tests fail on my machine?
10:58 <jirutka> Shiz: maybe grsec…?
10:58 <Shiz> jirutka: my machine is also grsec
10:59 <Shiz> so questionable
10:59 <Shiz> jirutka: can you install lit yourself, go to src/libcxxabi/build/test
10:59 <Shiz> and do lit -v .
10:59 <Shiz> that will show you more info about the failing tests
10:59 BitL0G1c joined
11:02 <jirutka> Shiz: /usr/bin/ld: cannot find -lc++
11:04 <jirutka> Shiz: btw there’s explanation for lit → $pkgname-test-utils https://github.com/alpinelinux/aports/commit/24bd280a18ce673ba4f4f22601c9d5aa949895d6
11:07 <Shiz> jirutka: did you do it through # abuild -r builddeps sh?
11:07 <Shiz> that's usually how i get myself into a build env with all the deps installed to do manual checks
11:07 <jirutka> Shiz: I do abuild -rK
11:08 <Shiz> hmm
11:08 <Shiz> jirutka: thanks though, this explains something at least
11:08 <Shiz> i think i can fix this
11:10 <jirutka> I know what is `abuild -r builddeps` doing, but what `abuild -r builddeps sh`? o.O
11:11 <jirutka> it can’t find libc++, but when I tried LD_LIBRARY_PATH= with path to libcxx/build/libs, it didn’t help
11:12 <Shiz> jirutka: it... simply invokes sh :P
11:13 <Shiz> so you get in an environment with the builddeps installed
11:13 <jirutka> Shiz: but why…?
11:13 <Shiz> and when you exit sh they get removed again
11:13 <jirutka> aha
11:13 <jirutka> interesting
11:13 <jirutka> I just run abuild undeps after I finish
11:26 <jirutka> Shiz: fails on builders too http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/libc++/libc++-4.0.0-r0.log
11:27 <Shiz> yeha
11:27 <Shiz> i'll fix it later
11:27 <Shiz> busy rn
11:27 <jirutka> okay
11:28 blueness joined
11:54 <scadu> clandmeter: jirutka re py3: what's the problem?
11:55 <jirutka> scadu: nothing, just wondering why there’s no py3-setuptools and why it’s still named py-setuptools instead of py2-setuptools
11:56 <jirutka> I’ve already figured out both
11:56 <jirutka> testing/idris is on the way to mirrors :)
11:57 <scadu> jirutka: tell me please :v
11:57 <jirutka> scadu: python3 bundles setuptools
11:58 <jirutka> scadu: provides="py2-setuptools" doesn’t work as I previously thought when I did it, it should be provides="py2-setuptools=$pkgver-$pkgrel"…
11:58 <jirutka> scadu: so I think that we can rename the pkg itself to py2- after v3.6
11:58 <scadu> jirutka: ah, right. I thought about naming convention -- py instead of py2
11:59 <scadu> jirutka: cool
12:04 blueness joined
12:06 blueness joined
12:11 rdutra joined
12:11 gromero joined
12:23 blueness joined
12:25 farosas joined
12:30 leitao joined
12:37 gromero joined
12:58 clandmeter joined
12:58 clandmeter joined
13:04 ncopa joined
13:04 ncopa joined
13:05 <fcolista> ncopa do you have an example on how to use mkimage.sh in order to have a custom iso with custom packages built-in?
13:18 fcolista joined
13:21 <jirutka> Shiz: FYI, I’ve modified libc++ abuild to allow test failures to get it build, the pkgs are already on mirrors, pls fix the tests once you have some time :)
13:28 <ncopa> do we need libc++ for 3.6 release?
13:32 vakartel joined
13:36 <fcolista> I've done with: sh mkimage.sh --tag edge --outdir /home/fcolista/iso --arch x86_64 --repository http://dl-cdn.alpinelinux.org/alpine/edge/main --profile standard
13:36 <fcolista> but i need to figure out how to add "custom" packages
13:39 <fcolista> ah
13:39 <fcolista> figured
13:41 <fcolista> clandmeter, mkimage runs mkimg.$profile
13:41 <fcolista> all_profiles="$all_profiles $(sed -n -e 's/^profile_\(.*\)() {$/\1/p' $1/mkimg.*.sh)"
13:43 fabled joined
13:43 <fcolista> im mkimg.standard there are the various profiles
13:47 minimalism joined
14:08 <Shiz> ncopa: it would be nice
14:08 cyteen joined
14:08 <ncopa> looks like we are almost there too
14:13 fabled joined
14:13 <ncopa> ghc pushed
14:14 <ncopa> looks like it will take a while to compile
14:14 <ncopa> and libc++ is not done yet on armhf
14:15 <ncopa> so i suppose it will not be done until tomorrow
14:15 vakartel joined
14:43 <przemoc> I know why I was losing logs! busybox syslogd's defaults for log rotation are quite modest (200KB, 1 rotated log to keep), which spoil dedicated logrotate functioning if you have it installed
14:44 <przemoc> I think we should somehow improve this horror
14:45 <przemoc> whenever someone comes up with idea to do more things in one tool, such things happen
14:46 <przemoc> ideally logrotate feature should be removed from busybox's syslogd, but I guess it's not an option
14:47 <Shiz> why removed
14:47 <Shiz> just set it to 0
14:48 <przemoc> because if you want to have log rotation, you install dedicated tool for that
14:48 <przemoc> maybe there could be some warning when logrotate pkg is installed and busybox syslogd is used, not sure
14:50 <przemoc> yeah, I can fix it locally by -s 0, but I'm talking about fixing it for AL users who install logrotate at one point and may notice that they're losing logs, if they manage to fill 200KB faster than weekly
14:54 <jirutka> ncopa: huh, libc++ takes just few minutes to compile, at least on x86_64
14:54 <Shiz> jirutka: tests take a while
14:55 <Shiz> they are intense but i enabled them on purpose since it's a pretty fundamental sys component
14:57 <jirutka> Shiz: even tests take just few minutes on my machine o.O but libc++abi tests are currently broken anyway, so we can disabled them instead of just ignoring failures
14:57 <Shiz> jirutka: really?
14:57 <Shiz> the libc++abi tests are fast but
14:57 <Shiz> the libc++ tests take a while
14:57 <Shiz> because there's 5000+ of them
14:57 <Shiz> took ~20 min on my machine
14:58 <przemoc> mind that 200KB in /var/log/messages is not a feat if you use for instance firewall logging. I know, you'll write that I should have separate file for that, and I can agree, but even w/o separate file, I shouldn't be losing logs.
15:12 <jirutka> Shiz: 6 min 45 sec to completely build libc++ including tests on my machine
15:12 <Shiz> that's faster than mine
15:12 <Shiz> :P
15:13 <jirutka> Shiz: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2 sockets, 6 cores per each, HT
15:13 <Shiz> yeah
15:13 <Shiz> my build container gets assigned 4 cores :P
15:14 <Shiz> or
15:14 <Shiz> 4 vcores
15:14 <Shiz> maybe better said
15:14 <Shiz> Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
15:14 <jirutka> Shiz: well, if cgroups actually work here, then it should not use more than 50 % of power of the machine
15:15 <jirutka> Shiz: I thought that I have powerful machine, until kaniini told me about his machine :( XD
15:15 <Shiz> :P
15:18 <kaniini> i don't have my machine fully up yet.
15:18 <jirutka> you need to build a nuclear power plant first, right? XD
15:19 <kaniini> i need to get it booting
15:21 <kaniini> it insists my ram is bad
15:21 <kaniini> even though it works fine in my old server
15:22 <jirutka> maybe you just need 1.2 GW… https://s-media-cache-ak0.pinimg.com/originals/c8/17/37/c81737d57c7841ba5002fdef19d3d8cc.jpg :P
15:22 <kaniini> actually i think that may be the problem
15:22 <kaniini> that i need more than 1 power supply connected
15:23 <przemoc> at work I had access to QorIQ T2080. 4 dual-threaded e6500 cores, 1.53 GHz, but it's apparently meant to be power efficient, so it's not that fast as your machines
15:33 vkrishn joined
15:33 s33se joined
15:33 <vkrishn> I hope none of AL build servers are AMT vulnerable, https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
15:35 <jirutka> wait a moment, web server integrated in a firmware?
15:36 <Shiz> hehe jirutka is not familiar with AMT
15:36 <Shiz> anyway, unlikely
15:36 <jirutka> WHAT THE ACTUAL FUCK?!
15:37 <Shiz> jirutka: https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf
15:37 <Shiz> here's some background reading
15:37 <Shiz> anyway
15:37 <k63ZXXguczqE> wait until he hears about IoT....
15:37 <Shiz> AMT is only available on single-socket xeon CPUs
15:37 <Shiz> i don't think we carry those
15:37 <Shiz> e.g. Xeon 1xxx
15:50 <ncopa> jirutka: seems like it takes a while to run the tests on armhf
15:51 <jirutka> ncopa: well, we can disable tests just for armhf; I’ve already did this in some pkg, maybe it’s even some llvm pkg, b/c it takes forever to run them on that arch
16:00 <ncopa> could be its stuck too
16:01 <ncopa> /home/buildozer/aports/testing/libc++/src/libcxx-4.0.0.src/build/test/libcxx/utilities/memory/util.smartptr/Output/race_condition.pass.cpp.exe
16:01 <jirutka> maybe disable just this test for armhf?
16:03 <ncopa> lets wait a bit more
16:03 <jirutka> okay
16:03 <ncopa> i dont remember if it was edge or 3-6 that was stuck earlier
16:04 <ncopa> ghc will probably take all night
16:04 <ncopa> so it would be good to have it started today
16:05 <ncopa> we dont even have rc1 out
16:05 <ncopa> libc++ will have to wait til after 3.6 release
16:05 <jirutka> why, it’s already built
16:05 <ncopa> we had freeze for that kind of stuff in april already
16:06 <ncopa> its not built on armhf
16:06 <ncopa> and if we move it
16:06 <ncopa> it will take another day
16:06 <jirutka> so we can just disable tests for armhf
16:06 <ncopa> ++
16:06 <ncopa> i think this means i need to enforce feature freezes more strict in future
16:07 <ncopa> why do we need it for 3.6?
16:08 <ncopa> this is exactly why i said that i dont want add new stuff
16:09 <jirutka> tests disabled for amrhf, let’s kill the build, let it rebuilt on armhf and see how long it takes
16:09 <jirutka> I dunno, Shiz wanted it
16:10 <Shiz> i said it would be usful, i don't really require it
16:10 <Shiz> that is all
16:10 <jirutka> ncopa: ghc failed on 3-6 because of missing ghc… :)
16:13 <jirutka> ncopa: question about cargo… currently it cargo downloads rust dependencies (crates) from the cargo repository, but it’s set to use Cargo.lock that defines every dependency (incl. transitive) with exact version and checksum of the crate, cargo verifies them and fail when something is wrong
16:14 <ncopa> http://tpaste.us/qMjK
16:14 <ncopa> i installed ghc manually
16:14 <jirutka> ncopa: is that good enough for us, at least for now, to move it into community, or should I figure out other way, I mean use the solution I’ve showed you today, but include this script in the cargo abuild for now, so every crates would be downloaded and checked by abuild?
16:15 <ncopa> and now ghc is gone
16:16 <ncopa> looks like it build on edge
16:16 <jirutka> ncopa: rust pkg without cargo is not very usable, so I think we need to move also cargo to community; however, even rust itself without cargo is quite a win, b/c upstream provides statically linked cargo binary, so it’s much better than not having rust at all
16:18 <jirutka> ncopa: cargo abuild https://github.com/alpinelinux/aports/blob/master/testing/cargo/APKBUILD
16:19 <ncopa> is that cargo something we can maintain for 6 months?
16:19 <ncopa> and provide support
16:19 <ncopa> if so, then its good enough
16:19 <ncopa> otherwise we wait
16:20 <jirutka> yes, we can maintain it, it’s not a problem
16:20 <ncopa> push it then
16:20 <ncopa> the thing is
16:20 <ncopa> 22 may i will tag the release
16:20 <ncopa> ready or not
16:20 <ncopa> i will just tag it
16:21 <ncopa> so either wew do a release with alot of extra things included, things that works halfway
16:21 <ncopa> or we do a release with fewer things, but the things we ship works good
16:21 <jirutka> the only problem is that it may violate our policy about not letting software download deps itself; however, in the case of cargo, it’s not like downloading random stuff w/o verification, it do the same verifications as we do in abuild
16:21 <ncopa> cargo depend on itself?
16:22 <ncopa> so we need "bootstrap" it?
16:22 <jirutka> yes, we use statically linked binary from upstream to bootstrap it
16:22 <jirutka> so there’s no extra action needed
16:22 <ncopa> i suppose thats good enough
16:22 <ncopa> but remember
16:23 <ncopa> i will tag rleease even if it means there are no release candidate at all
16:23 <ncopa> since 1 may we should have *only* done fixes on the things we have
16:23 <ncopa> otherwise we end up release broken stuff
16:24 <jirutka> don’t worry, cargo doesn’t take much time to build
16:25 <ncopa> push it then
16:25 <ncopa> fcolista: re zfs boot usb
16:25 <ncopa> it is a bug
16:25 <ncopa> but it will have to wait
16:26 <ncopa> i wanted to fix those kind of bugs before the relase but unfortunally we will have to live with the bugs til next release
16:26 <ncopa> due to release got delayed
16:27 <ncopa> can anyone help with this php5 issue? http://bugs.alpinelinux.org/issues/7284
16:28 <ncopa> another relase delay: http://bugs.alpinelinux.org/issues/7281
16:28 <ncopa> that one is important since its CVE
16:29 tmh1999 joined
16:34 <jirutka> ncopa: I’ve added a comment to cargo pkg https://dpaste.de/GHH8
16:35 <ncopa> sounds good
16:35 <ncopa> push it
16:37 <jirutka> done
16:40 <jirutka> where the heck is some page with OpenJDK releases?
16:44 <jirutka> I’m afraid that in long-term we must drop icedtea (it’s not very actively maintained anymore), build directly from openjdk sources and take patches e.g. from Fedora
16:44 fekepp joined
16:54 <jirutka> omg, there’s already http://icedtea.wildebeest.org/download/source/icedtea-3.4.0.tar.gz and http://icedtea.wildebeest.org/download/drops/icedtea8/3.4.0/, according to NEWS in the first tarball 3.4.0 is released, but there’s no 3.4.0 tag in the upstream repository
16:54 <jirutka> it’s very unclear
16:55 <jirutka> ncopa: okay, I’ve updated to icedtea 3.4.0 and trying to build it on my machine now
16:56 <jirutka> ncopa: our patches passed, that’s good
16:56 <ncopa> good sign
16:56 <ncopa> i hope it builds
16:56 <ncopa> we should look over the bugs on bugs.alpinelinux.org and try fix as much as possible
16:56 <jirutka> ehm, no…
16:56 <jirutka> they are just applied later…
16:56 <ncopa> im looking at the resolved stuff and closeing them
16:59 rdutra joined
17:05 <TemptorSent> On the apk tracker, please go ahead and drop the priority and push back release for all my feature requests since we're not migrating until after 3.6
17:10 tty` joined
17:19 <_ikke_> Anyone looked at habitat yet?
17:21 <jirutka> _ikke_: I know about it, but haven’t tried it yet, nor try to make a pkg for it
17:21 <_ikke_> right, I'm trying to make a package from it
17:34 cyteen joined
18:20 <leitao> jirutka: we have the ppc64le patches rebased against 2.1.0_beta3.
18:20 <leitao> do you want to bump to this version?
18:21 <jirutka> leitao: that’s great!
18:22 <jirutka> leitao: yeah, I think that we can make this before v3.6
18:23 <leitao> jirutka: ok. gromero can you handle a PR with the new patchset?
18:24 <jirutka> leitao: gromero: please as soon as possible, 3.6-rc1 is already knocking on door
18:24 <leitao> jirutka: sure. It is just a matter of creating a PR now.
18:24 <leitao> jirutka: should we bump the version ?
18:25 <_ikke_> jirutka: Do you happen to know how to get cargo to run a release build when it's executed from a Makefile?
18:25 <jirutka> leitao: yes, pkgver=2.1.0_beta3, pkgrel=0
18:25 <leitao> jirutka: ack!
18:25 <gromero> jirutka: leitao ack
18:25 BitL0G1c joined
18:25 <jirutka> _ikke_: try CARGOFLAGS="--release"
18:26 <_ikke_> jirutka: thanks
18:29 Guest25648 joined
18:32 black_ant joined
18:37 minimalism joined
18:38 <_ikke_> jirutka: CARGOFLAGS doesn't seem to be a thing
18:38 <jirutka> _ikke_: hm, what about RUSTFLAGS ?
18:39 <jirutka> _ikke_: http://doc.crates.io/environment-variables.html#environment-variables-cargo-reads
18:42 <_ikke_> jirutka: Ok, then I would need to find out what would be the equivalent of cargo build --release
18:43 <_ikke_> https://news.ycombinator.com/item?id=9146694
18:50 Mr_H joined
18:58 <gromero> jirutka: leitao from a ppc64 perspective, simple as https://github.com/alpinelinux/aports/pull/1523
18:59 <jirutka> gromero: I think that you’ve missed a patch…
19:00 <gromero> jirutka: which you mean?
19:01 <jirutka> maybe just a GH glitch, give me a sec
19:01 <gromero> jirutka: you mean because leitao said: "gromero can you handle a PR with the new patchset?"
19:01 ingo__ joined
19:02 <gromero> jirutka: ok
19:02 <jirutka> gromero: no, it’s not a glitch, the only change in enable-support-for-ppc64le.patch is single change in a comment… https://github.com/alpinelinux/aports/pull/1523/files
19:03 <gromero> jirutka: you are saying that because leitao said "a new patchset"?
19:03 <gromero> yes, so out patch applies fine
19:03 <gromero> *our
19:03 <jirutka> gromero: uh, aha
19:08 <_ikke_> jirutka: aha, there is a PROFILE flag
19:10 th left
19:26 HRio joined
19:29 <HRio> I just pushed a CVE regression fix for shadow: https://github.com/alpinelinux/aports/pull/1524 can that make it to v3.6 or to late for the rc?
19:30 ingo___ joined
19:33 <HRio> jirutka: thanks, can you cherry-pick it to v3.5 as well?
19:34 <jirutka> HRio: yeah, but pls remind it me later
19:34 <HRio> or should I open a PR for v3.5?
19:37 <jirutka> HRio: yes please
19:50 <HRio> jirutka: shadow fix for v3.5 https://github.com/alpinelinux/aports/pull/1525 (build failure on fetch of http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/apk-tools-static-2.6.7-r0.apk)
20:13 <_ikke_> just made an ipv6 enabled proxy for dl-4.a.o :P
20:21 D630 joined
20:25 black_ant joined
20:34 <jirutka> ha, that reminds me, clandmeter, why alpinelinux.org doesn’t have AAAA record?
20:40 <_ikke_> if an application requires openssl to build, would libressl work as well?
20:41 <jirutka> _ikke_: usually yes
20:41 <_ikke_> ok
20:44 <_ikke_> jirutka: I just kicked up a bare metal server on scaleway with 8 cores to test building a package
20:49 minimalism joined
20:58 ppisati joined
21:13 BitL0G1c joined
21:29 <Shiz> hello
21:29 <Shiz> i've got some time again
21:29 <Shiz> whats new
21:29 <_ikke_> I'm trying to package habitat
21:30 <_ikke_> building takes ages though
21:31 <jirutka> Shiz: broken tests in libc++ ;)
21:31 <jirutka> Shiz: and someone asked about your progress in some Rust issue on rust-lang/rust ;)
22:12 BitL0G1c joined
22:30 pbregener joined
22:43 rdutra joined
22:59 black_ant joined
23:26 ppisati joined