2018-03-01 03:30:05 <kaniini> koldbrutality: http://build.alpinelinux.org/buildlogs/build-edge-x86/testing/py-beautifulsoup4/py-beautifulsoup4-4.6.0-r1.log
2018-03-01 03:37:43 <koldbrutality> push in same branch?
2018-03-01 03:37:47 <koldbrutality> or make a new pull request?
2018-03-01 03:38:15 <koldbrutality> with pkgrel++
2018-03-01 03:53:35 <koldbrutality> on my machine i do not see that error
2018-03-01 03:53:42 <koldbrutality> i cleared out my world file
2018-03-01 04:04:08 <koldbrutality> i can't see the log
2018-03-01 04:04:21 <koldbrutality> https://travis-ci.org/alpinelinux/aports/builds/347596294
2018-03-01 04:20:11 <koldbrutality> my log on my machine for the change https://pastebin.com/CixQ7tt9
2018-03-01 04:25:22 <koldbrutality> https://api.travis-ci.org/v3/job/347596295/log.txt
2018-03-01 14:38:12 <fcolista> anyone has ever used mod_magnet (lua) with lighttpd ?
2018-03-01 14:40:45 <fcolista> I need to open a socket from a lua script run by a webserver :D
2018-03-01 14:40:58 <fcolista> want to read the openvpn status with netcat
2018-03-01 14:41:06 <fcolista> querying the management interface
2018-03-01 14:41:20 <fcolista> i set to openvpn "management 192.168.10.10 8022"
2018-03-01 14:41:30 <fcolista> and then echo status | nc 192.168.10.10 8022
2018-03-01 14:41:38 <fcolista> and i get the info about client list
2018-03-01 14:41:47 <fcolista> I want to do the netcat stuff via lua
2018-03-01 14:41:56 <fcolista> as cgi/web script
2018-03-01 14:42:39 <fcolista> but the io.popen does not seem to work from lighty
2018-03-01 22:43:36 <AWilcox[m]> I have a maybe silly suggestion for abuild
2018-03-01 22:43:56 <AWilcox[m]> It'd be really nice if it could parallelise the "compress data" of subpackages on machines with multiple CPUs.
2018-03-01 22:44:04 <AWilcox[m]> For example, the LLVM4 packages are -static 1 GB, -libs 1 GB, -dbg 1.4 GB
2018-03-01 22:44:10 <AWilcox[m]> It could be doing all of them at once on my 8 core Xeon, and two of them at once on my dual CPU PowerPC.
2018-03-01 22:44:21 <AWilcox[m]> This would also help the builders build packages slightly faster, which would of course be a good thing :)
2018-03-02 05:47:43 <koldbrutality> does anyone know if the command line program /usr/bin/coverage{2,3} work properly for py-coverage package?
2018-03-02 05:51:48 <koldbrutality> is there a restriction that main packages can't refer to testing packages on Travis CI?
2018-03-02 06:49:45 <tmh1999[m]> if I am not wrong, we are going to release 3.8 around May-June?
2018-03-02 08:00:16 <AWilcox[m]> How does one access the test suite logs on the builders?
2018-03-02 09:03:21 <bernhardgruen[m]> Don't know if I am allowed to but I just created a PR for community/docker. Natanael Copa
2018-03-02 09:03:42 <bernhardgruen[m]> It is a one byte change (apart from the checksum)
2018-03-02 09:10:12 <_ikke_> bernhardgruen[m]: creating a PR is always allowed :-)
2018-03-02 09:30:00 <ncopa> bernhardgruen: thanks!
2018-03-02 09:31:13 <ncopa> A. Wilcox: http://build.alpinelinux.org/buildlogs/
2018-03-02 09:32:32 <ncopa> A. Wilcox: I'd like to parallelize compression if possible. I think GNU gzip will use multiple cores while busybox gzip only use one. so `apk add gzip` may speed up things
2018-03-02 09:33:15 <_ikke_> ncopa: gnu gzip also uses 1 core
2018-03-02 09:33:21 <_ikke_> ncopa: there is pigz which can be multi-core
2018-03-02 09:33:24 <bernhardgruen[m]> Isn't this pigz which uses multiple cores?
2018-03-02 09:33:30 <_ikke_> ^
2018-03-02 09:34:22 <ncopa> i thought GNU gzip also use multicore...
2018-03-02 09:35:18 <_ikke_> not that I'm aware of
2018-03-02 09:36:28 <bernhardgruen[m]> xz also supports multi-threading btw.
2018-03-02 09:36:59 <_ikke_> right
2018-03-02 09:42:09 <bernhardgruen[m]> I have a package (testing/burp) which compiles on my system but not on the builder. sha512sum seems to be different from mine locally. Reason for this seems to be: "the Sourceforge site is currently in Disaster Recovery mode" whoops
2018-03-02 09:42:16 <bernhardgruen[m]> So that could kill some other builds too.
2018-03-02 10:52:59 <Aerdan[m]> yes, sf is having some serious issues lately
2018-03-02 10:53:39 <Aerdan[m]> they switched DCs, and the new one seems to not be able to handle DDoS very well. maybe some tech dropped their disks, too. idk.
2018-03-02 19:54:37 <AWilcox[m]> Natanael Copa: I'm wondering if I should finish my technical demo of adding xz support to apk.
2018-03-02 20:26:37 <skarnet> ncopa ^
2018-03-02 22:59:23 <koldbrutality> lol typescript has over 11,700 tests
2018-03-02 22:59:45 <koldbrutality> i will make pull request for it
2018-03-02 23:00:08 <koldbrutality> already over 20k
2018-03-02 23:04:12 <koldbrutality> 59k passing
2018-03-03 02:04:30 <koldbrutality> I can't run server on Travis CI because of some permissions.
2018-03-03 02:05:00 <koldbrutality> so i had to disable check :'(  ...waste of time
2018-03-03 02:33:16 <duncan^> It's not necessarily a waste of time to enable the check.
2018-03-03 02:53:02 <kaniini> awilfox: yes
2018-03-03 19:42:30 <alsdkfjaslk> hi, could I ask a bit of an specific question about the dejavu-ttf fonts and its license?
2018-03-03 22:55:22 <duncan^> Hi, can you enable apparmor in linux-vanilla please?
2018-03-03 22:55:49 <duncan^> Given the demise of Grsecurity/PaX, it would be nice to support Apparmor on the kernel side on mainline
2018-03-03 22:56:20 <duncan^> I think all you'd need to do is set CONFIG_SECURITY_APPARMOR
2018-03-03 22:57:12 <duncan^> At least, I'm looking in edge and it's not enabled for Linux-vanilla
2018-03-03 22:59:31 <duncan^> It seems a shame given apparmor is packaged for Alpine
2018-03-03 23:31:28 <koldbrutality> I cannot do gui test on Travis?
2018-03-03 23:33:32 <koldbrutality> i will just disable checking because it segfaults on the server
2018-03-03 23:36:52 <duncan^> I guess also we should enable the dmesg restriction
2018-03-03 23:38:38 <skarnet> duncan^: the point of "linux-vanilla" is to be "vanilla"
2018-03-03 23:39:53 <koldbrutality> vanilla is just basic
2018-03-03 23:40:22 <koldbrutality> you can compile your own kernel with patches
2018-03-03 23:55:31 <duncan^> I think that's not right; it's not as if it's compiled from defconfig.
2018-03-03 23:56:01 <duncan^> So that's entirely unhelpful, thanks :)
2018-03-03 23:59:36 <skarnet> what part of "vanilla is vanilla" do you feel is not right
2018-03-04 01:05:12 <kaniini> the punch line is this is something i am already working on because we want it in adelie
2018-03-04 01:11:37 <duncan^> OK: can we clarify what vanilla is here - it's clearly not defconfig, but if apparmor isn't "vanilla" (it's in the tree and it's a module that is loaded), what is?
2018-03-04 02:27:41 <koldbrutality> why don't you just make a new kernel package and maintain it
2018-03-04 02:40:28 <danieli> bugs.a.o seems to be down, someone will have a look at it tomorrow
2018-03-04 02:40:34 <danieli> i don't have access to that
2018-03-04 02:57:53 <koldbrutality> i should make a ck-kernel package with bfs
2018-03-04 03:26:43 <koldbrutality> i will work on that and the pf patchset
2018-03-04 04:26:24 <koldbrutality> everything should just be module huh?
2018-03-04 04:26:38 <koldbrutality> i was using the default values
2018-03-04 04:32:22 <koldbrutality> i see its just default values
2018-03-04 08:30:39 <mepholic> ncopa: firefox 58 seems to work fine, there's a weird animation issue when closing a tab when you have lots of tabs open
2018-03-04 08:30:48 <mepholic> but that's the only problem I've seen
2018-03-04 10:18:32 <mps> mepholic: there is no firefox 58 in aarch64, what holds it? bug or something else
2018-03-04 10:18:46 <mepholic> not sure, probably no rust
2018-03-04 10:19:16 <mps> ah, I see
2018-03-04 11:39:50 <clandmeter> kaniini: you around?
2018-03-04 12:50:05 <BernhardG> clandmeter: would you please look into PR 3322 (burp). Thank you in advance.
2018-03-04 12:52:27 <danieli> why should it be fast tracked?
2018-03-04 12:53:32 <BernhardG> there is no specific reason other than I did changes (as requested) and did not get a response anymore.
2018-03-04 15:08:07 <clandmeter> bernhardgruen: done
2018-03-04 15:08:17 <clandmeter> bernhardgruen: thanks for taking the time.
2018-03-04 15:08:41 <BernhardG> I have to thank you, clandmeter
2018-03-04 15:55:27 <jirutka> could please someone look what’s wrong with vlc 3.0.1 on aarch64? http://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/vlc/vlc-3.0.1-r0.log
2018-03-04 16:20:16 <BernhardG> jirutka: there is a file missing "arm_neon/asm.S". There is a commit which adds it to the repository: https://git.videolan.org/?p=vlc/vlc-3.0.git;a=commit;h=29c4721b18ad422cc3cbb6aed9d321900dab0e51
2018-03-04 16:20:48 <jirutka> BernhardG: thank you!
2018-03-04 16:38:38 <jirutka> BernhardG: that patch didn’t help, still the same error :/
2018-03-04 16:40:43 <BernhardG> jirutka: I just looked into 3.0.0. It seems there was no include '.../asm.S' in that file merge_arm64.S at all.
2018-03-04 16:41:39 <BernhardG> All in all it seems to be an upstream fault. Maybe you could try to compile 3.0.0?
2018-03-04 17:02:32 <BernhardG> I intend to upgrade the boost library from 1.62.0 to 1.66.0 now I found out that one dependent package does not compile anymore with it. I think that already have a working fix for this other package (namecoin). How should I do a PR for this? both into one PR or separated PRs (namecoin builds fine with patch and the old version of boost)?
2018-03-04 18:10:31 <jirutka> BernhardG: both into one PR
2018-03-04 18:24:14 <BernhardG> It is unbelievable how slow the Travis CI builders are. Even my home PC seems faster and our gitlab ci build cluster is faster for sure.
2018-03-04 18:24:57 <jirutka> BernhardG: these builders are for free
2018-03-04 18:25:17 <BernhardG> Jirutka: It can't even compile one program to the end (takes to long).
2018-03-04 18:25:32 <jirutka> it runs on one core only
2018-03-04 18:25:38 <jirutka> so yeah, it is slow
2018-03-04 18:25:47 <BernhardG> Oh, didn't know that. That's another story then.
2018-03-05 04:29:13 <koldbrutality> what is the lowest x86 microarchitecture that alpine support?
2018-03-05 08:27:31 <BernhardG> jirutka: thanks for fixing testing/burp package.
2018-03-05 10:16:45 <ncopa> koldbrutality: i think alpine supports i586
2018-03-05 10:54:08 <jirutka> and don’t anyone dare to ask for supporting i386… there are other distros that looks like living museum… ;)
2018-03-05 10:59:37 <BernhardG> jirutka: just found out there is an error (probably from your change) with copying files to /usr/* instead of /usr/bin/* I will fix it really soon. (https://pkgs.alpinelinux.org/contents?branch=edge&name=burp-server&arch=x86_64&repo=testing)
2018-03-05 11:00:00 <jirutka> oh crap
2018-03-05 11:00:04 <jirutka> I’ll look at it
2018-03-05 11:00:37 <jirutka> yes, this is my fault, sorry about that :(
2018-03-05 11:02:14 <jirutka> I pushed fix
2018-03-05 11:02:26 <jirutka> don’t understand how I did such stupid mistake :(
2018-03-05 11:05:50 <BernhardG> No problem at all. I found out that I have to add libressl to it as it is needed to generate the certificates. I had that package already installed and therefore did not notice that dependency
2018-03-05 11:06:39 <jirutka> as depends to burp or burp-server?
2018-03-05 11:08:13 <BernhardG> For the server only. I'll do an update for it.
2018-03-05 11:15:16 <BernhardG> jirutka: In that context I found a bug in your one-context package. It writes "gateway " (empty) into interfaces if you have a eth1 and connect it to a network without gateway (internal Network).
2018-03-05 11:31:13 <BernhardG> There are some packages that don't show a Maintainer. I think this should get fixed as it makes it hard to contact a maintainer in case of errors or other requests.
2018-03-05 11:34:12 <ncopa> I an updating the description of the releases: https://alpinelinux.org/downloads/
2018-03-05 11:34:13 <ncopa> removing "vanilla" iso
2018-03-05 11:34:14 <ncopa> and removing "grsec"
2018-03-05 11:34:14 <ncopa> Any suggestion what to write about the rpi release?
2018-03-05 11:34:15 <ncopa> and xen
2018-03-05 11:34:16 <ncopa> Rpi: "Includes Raspberry Pi kernel. Designed for RPI 1,2 and 3. And much more..."
2018-03-05 11:34:24 <ncopa> Xen: Build-in support for Xen Hypervisor. Includes packages targed at Xen usage. Use for Xen Dom 0.
2018-03-05 11:34:37 <ncopa> or better suggestions?
2018-03-05 11:34:52 <_ikke_> ncopa: Is rpi still run-from-ram only? Might want to mention that
2018-03-05 11:35:21 <ncopa> well, all bootmedia are run-from-ram
2018-03-05 11:35:40 <ncopa> i havent tested install the rpi on disk so i dont know if it works
2018-03-05 11:36:01 <ncopa> but there shouldnt really be anything preventing us from fixing rpi to work on disk install
2018-03-05 11:36:31 <_ikke_> I heard at least someone managing to do it
2018-03-05 11:40:44 <ncopa> The above descriptions are ok?
2018-03-05 11:42:18 <_ikke_> I'm not sure if there is more to tell
2018-03-05 11:42:59 <ncopa> pushed
2018-03-05 11:43:03 <ncopa> we dont want tell more. we want say as little as possible
2018-03-05 11:43:28 <ncopa> without making any confusion what iso is doing what and why
2018-03-05 11:44:26 <_ikke_> right
2018-03-05 11:46:20 <jirutka> BernhardG: could you please open an issue in https://github.com/jirutka/one-context/issues ? just as reminder for me
2018-03-05 12:56:09 <jirutka> ncopa: please look at https://github.com/alpinelinux/aports/pull/3483
2018-03-05 16:39:14 <BernhardG> Natanael Copa: Is there any reason why Alpine 3.7.0 uses an (unsupported) edge version of docker (currently 17.10). I would prefer having stable versions in stable Alpine releases.
2018-03-05 16:39:15 <BernhardG> Is a backport of the current edge version possible / allowed?
2018-03-05 16:41:06 <_ikke_> BernhardG: Some people ask for the latest version
2018-03-05 16:41:46 <BernhardG> _ikke_: 18.02 would be the last version.
2018-03-05 16:42:01 <_ikke_> Right, it hasn't been updated to that version yet then :P
2018-03-05 16:42:45 <BernhardG> I think the best (for all interests) would be to have a docker 17.12.1 (current stable) and a docker-edge 18.02 (current edge) package
2018-03-05 16:43:32 <BernhardG> I did the last jump from 17.12.0 to 17.12.1 (as I assumed that most users like a stable version)
2018-03-05 16:43:33 <_ikke_> Right, I think that makes sense
2018-03-05 16:43:45 <BernhardG> I could also provide a docker-edge package if needed.
2018-03-05 16:45:10 <BernhardG> But the main still remains: would it be possible to backup 17.12.1 to Alpine 3.7.0?
2018-03-05 17:26:48 <BernhardG> Lousy mobile typos. The main question remains: would it be possible to backport 17.12.1 to Alpine 3.7.0 - sorry.
2018-03-05 17:39:55 <dehoptu[m]> WIP zsh completion for apk: https://gist.github.com/sroracle/1c8588ce099735ada8e922f32f4d4a18
2018-03-05 18:53:19 <andypost> can someone accept missed security upgrade for 3.5 branch https://github.com/alpinelinux/aports/pull/3500
2018-03-05 18:53:47 <andypost> other branches already updated but php 7.0 only in 3.5
2018-03-05 22:54:31 <jirutka> is there anyone who use Alpine desktop on notebook?
2018-03-05 22:55:14 <mps> jirutka: yes
2018-03-05 22:55:40 <jirutka> mps: which environment? Xfce4, Gnome 2, …?
2018-03-05 22:56:18 <mps> awesome wm, I do not use Desktop Environment
2018-03-05 22:56:31 <mps> but my wife use Xfce4
2018-03-05 22:58:19 <jirutka> mps: what do you use (or how) to control things like screen and keyboard backlight, audio, switching screens between more displays/projector, wifi, power management, …?
2018-03-05 22:59:40 <jirutka> mps: I’ve never used Linux on desktop/notebook for more than a day and even that was very long time ago and only main-stream heavyweight distros, so I’m quite a newbie in this area
2018-03-05 22:59:41 <mps> I built from source some of helper programs for backlight, keyboard
2018-03-05 23:00:14 <jirutka> which ones?
2018-03-05 23:00:20 <mps> jirutka: I use Alpine on x86_64 and chromebook
2018-03-05 23:01:00 <jirutka> btw I found https://github.com/gobolinux/GoboLight, it’s pretty new project, looks neat, already made aport for it https://pkgs.alpinelinux.org/package/edge/testing/x86_64/gobolight
2018-03-05 23:01:16 <jirutka> I mean what helper programs
2018-03-05 23:01:32 <hs3dUBwdmCjy> arandr for "switching screens between more displays/projector"
2018-03-05 23:01:47 <mps> but, I installed AL to my wifes notebook, Xfce4 with basic tools (alsa, firefox-esr, geeqie and so on)
2018-03-05 23:02:30 <jirutka> hs3dUBwdmCjy: this? http://christian.amsuess.com/tools/arandr/
2018-03-05 23:02:45 <mps> she uses it mostly for browsing, image view, listen music and other simple tasks
2018-03-05 23:02:46 <jirutka> (FYI I don’t have new notebook yet, just asking in advance)
2018-03-05 23:03:12 <mps> It was easy for simple tasks
2018-03-05 23:03:46 <mps> but it was a litle complicated to install AL with awesome wm
2018-03-05 23:03:59 <jirutka> I wonder if Xfce4 already has built-in tools for controlling such things or I have to find some tool for very task
2018-03-05 23:04:08 <jirutka> s/very/every/
2018-03-05 23:04:12 <mps> but most applications works without problem
2018-03-05 23:05:00 <mps> AFAIK, Xfce have xradr interface/applet to control monitors
2018-03-05 23:05:35 <clandmeter> xfce4 works nice on my chromebook (except for the audio which is kernel related).
2018-03-05 23:05:43 <mps> there is also network-manager for wifi and network control
2018-03-05 23:05:51 <ncopa> i use alpine and xfce on my macbook
2018-03-05 23:06:09 <jirutka> I’m not sure if I want to use network-manager… I’d like to avoid D-bus and similar craps
2018-03-05 23:06:32 <jirutka> ncopa: really? I thought that you use macOS on MacBook
2018-03-05 23:06:33 <mps> clandmeter: I have same experience with chromebook, problem is audio and it is kernel problem
2018-03-05 23:07:02 <ncopa> i manage wifi manually by editing wpa_supplicant.conf, i havent found any proper gui for wifi yet
2018-03-05 23:07:09 <ncopa> jirutka: its dualboot
2018-03-05 23:07:10 <mps> clandmeter: btw, what kind is your chromebook?
2018-03-05 23:07:11 <clandmeter> mps: it should be fixed with 15 kernels
2018-03-05 23:07:17 <ncopa> the talk i did at dockercon was with alpine
2018-03-05 23:07:17 <clandmeter> .15 kernels
2018-03-05 23:07:19 <jirutka> I’ll have Fujitsu Lifebook U748
2018-03-05 23:07:50 <ncopa> randr in xfce works sort of, but its not flawless
2018-03-05 23:07:51 <clandmeter> toshiba
2018-03-05 23:07:55 <dehoptu[m]> wpa_gui works nice for managing wifi imo
2018-03-05 23:08:00 <ncopa> it was a bit messy to set up the externa screen and google presenter
2018-03-05 23:08:24 <mps> clandmeter: I have samsung chromebook one, kernel is 4.4.118, aarch64
2018-03-05 23:08:27 <ncopa> maybe i should have a look at wpa_gui again
2018-03-05 23:08:43 <mps> ncopa: wpa_gui works for me
2018-03-05 23:09:13 <mps> ncopa: just have to manually start udhcp
2018-03-05 23:09:35 <ncopa> aarch64 chromebook. thats pretty cool
2018-03-05 23:10:02 <ncopa> i have issues with resolution and external screens at times
2018-03-05 23:10:05 <clandmeter> mps: ah thats a complete different animal.
2018-03-05 23:10:07 <mps> ncopa: you helped me a few months ago
2018-03-05 23:10:24 <ncopa> and the sleep function is a bit weird (or broken) on xfce
2018-03-05 23:10:48 <ncopa> laptop gets hot when i close the lid
2018-03-05 23:11:09 <ncopa> after a while
2018-03-05 23:11:28 <mps> ncopa: I configured acpid for sleep control
2018-03-05 23:11:44 <mps> never had problem with it
2018-03-05 23:12:29 <jirutka> btw Fujitsu provides even so-called non-vPro configurations, this means without Intel Trojan horse AMT :P this was one of my requirements, I found that only Fujitsu and Dell sells it (and Purism and System76, but these are overpriced as hell and not very good)
2018-03-05 23:12:30 <ncopa> mps: i have forgotten who i have helped, sorry :)
2018-03-05 23:12:48 <dehoptu[m]> same
2018-03-05 23:12:57 <dehoptu[m]> kinda annoying to set up but it gets the job done
2018-03-05 23:13:14 <mps> ncopa: it doesn't mater :)
2018-03-05 23:14:03 <mps> your help was the 'switch' which assured me that I should install AL on notebook
2018-03-05 23:14:25 <jirutka> :)
2018-03-05 23:14:53 <ncopa> mps: what have i done....
2018-03-05 23:14:55 <ncopa> :)
2018-03-05 23:15:16 <jirutka> how it looks with Firefox on Alpine? non-ESR is still in testing… this is kinda critical for me
2018-03-05 23:16:19 <mps> ncopa: I forgot exactly, but IIRC I asked for never version of the firefox-esr for aarch64 and you built it in the few hours and informed me here in the IRC
2018-03-05 23:16:32 <ncopa> non-ESR will probably stay in testing. we can only support ESR for stable branches
2018-03-05 23:16:39 <ncopa> im using chromium
2018-03-05 23:16:48 <mps> that was very persuading
2018-03-05 23:16:53 <jirutka> ncopa: and does it work? non-ESR Firefox?
2018-03-05 23:17:09 <ncopa> ah, that i think i remember
2018-03-05 23:17:14 <mps> no, that was ESR
2018-03-05 23:17:43 <jirutka> I definitely don’t wanna use Chromium
2018-03-05 23:17:50 <mps> on aarch64 firefox-esr is only available
2018-03-05 23:17:55 <ncopa> it sort of works on x86_64
2018-03-05 23:18:00 <ncopa> i had one site that didnt work last time i tried
2018-03-05 23:18:01 <ncopa> so i switched back to chromium
2018-03-05 23:18:01 <mps> yes
2018-03-05 23:18:02 <jirutka> what does it mean “sort of”?
2018-03-05 23:18:36 <ncopa> there was a site. dont remember what it was
2018-03-05 23:18:49 <mps> there is no rust compiler for aarch64 ready and because that firefox (proper) can't be built
2018-03-05 23:19:01 <ncopa> bank, or flight booking or something else
2018-03-05 23:19:01 <jirutka> i know
2018-03-05 23:19:07 <ncopa> ah, my power company, who proviced me with electricity
2018-03-05 23:19:14 <jirutka> heh
2018-03-05 23:19:22 <jirutka> it crashed on that site?
2018-03-05 23:19:28 <ncopa> rust
2018-03-05 23:19:41 <ncopa> we need rust ported to the other arches
2018-03-05 23:19:45 <jirutka> i know
2018-03-05 23:19:47 <ncopa> atleast aarch64 and ppc64le
2018-03-05 23:19:53 <ncopa> no, the page was just flipping
2018-03-05 23:19:55 <jirutka> i’ve already commented on that a week ago…
2018-03-05 23:19:59 <jirutka> flipping? o.O
2018-03-05 23:19:59 <ncopa> like it was forever loading or something
2018-03-05 23:20:03 <ncopa> it was a login site
2018-03-05 23:20:09 <jirutka> hm, weird
2018-03-05 23:22:09 <mps> so, no one except me run AL desktop on the arm machines?
2018-03-05 23:24:01 <mps> never mind, I want to say big thank you to you who made AL
2018-03-05 23:25:46 <mps> few days ago I needed complicated perl web framework which I never managed to set properly on Debian, but it took me less than hour to build and install it with abuild on Alpine
2018-03-05 23:26:10 <mps> I was really excited how it was easy :)
2018-03-05 23:26:41 <mps> yes, it was hackish, but it was successful
2018-03-05 23:40:16 <jirutka> andypost: welcome on board! :)
2018-03-05 23:45:16 <ncopa> PR queue is below 200. im going to bed
2018-03-05 23:45:29 <ncopa> goodnight
2018-03-05 23:46:45 <jirutka> ncopa: you did not backported tor security fix…
2018-03-05 23:52:13 <jirutka> hm, probably b/c there’s 0.3.1.x not 0.3.2.x in 3.7-stable
2018-03-06 00:04:09 <andypost> jirutka, thanks! will do my best ...carefully)
2018-03-06 00:04:45 <jirutka> andypost: I believe you will! :)
2018-03-06 00:05:24 <jirutka> andypost: did clandmeter already explain to you how to commit (to git.a.o, never directly to GH), how easily merge PRs etc?
2018-03-06 00:06:49 <andypost> jirutka, yes, everything is clear
2018-03-06 00:06:56 <jirutka> andypost: perfect!
2018-03-06 00:07:20 <andypost> btw dovecot security fix probably needs backport
2018-03-06 00:07:43 <kaniini> +1 to jirutka for pushing for andypost to be given maintainer privs
2018-03-06 00:07:50 <kaniini> +1 to andypost for actually joining us ;)
2018-03-06 00:08:28 <jirutka> andypost: yes, you’re right, dovecot should be definitely backported
2018-03-06 00:10:11 <andypost> I did not update components cos no idea about affected they or not, but new version has incompatibility with logs so not sure how to upgrade now
2018-03-06 00:11:05 <jirutka> what incompatibility with logs?
2018-03-06 00:11:59 <jirutka> I don’t see any note about breaking change in logging in https://www.dovecot.org/list/dovecot-news/2018-February/000370.html
2018-03-06 00:12:07 <andypost> https://www.dovecot.org/list/dovecot-news/2017-December/000366.html
2018-03-06 00:13:23 <hs3dUBwdmCjy> jirutka: arandr is packaged in alpine
2018-03-06 00:13:32 <hs3dUBwdmCjy> but yes the one you linked
2018-03-06 00:17:50 <jirutka> andypost: that’s for 2.3.0, but your last upgrade is to 2.2.34, so… how is it related?
2018-03-06 00:19:30 <andypost> jirutka, I used to try upgrade to 2.3 but it failed (needs config changes) that's why I filed PR with secfix only
2018-03-06 00:20:48 <jirutka> I’ve merged upgrade to 2.2.34 to 3.7-stable (2.2.33.2 → 2.2.34), but in 3.6-stable it’s on 2.2.27 :/
2018-03-06 00:21:39 <jirutka> I don’t know if dovecot follows semver so there are not any breaking changes between 2.2.27 and 2.2.34
2018-03-06 00:35:01 <jirutka> i need to go sleep, gn!
2018-03-06 00:35:44 <jirutka> andypost: btw feel free to upgrade php7 to 7.2.x if it’s ready
2018-03-06 00:38:56 <andypost> jirutka, I'd better wait 2 weeks more
2018-03-06 00:39:30 <jirutka> andypost: why 2 weeks? some php release is planned in 2 weeks?
2018-03-06 00:39:41 <kaniini> note that we are entering soft freeze for 3.8 soon
2018-03-06 00:39:53 <kaniini> most of 3.8 was ruined by meltdown/spectre mitigation unfortunately
2018-03-06 00:40:04 <kaniini> so if you would like php 7.2 in 3.8
2018-03-06 00:40:09 <kaniini> it would be appreciated to do it sooner than later
2018-03-06 00:40:59 <jirutka> could you please be more specific about “soon”?
2018-03-06 00:41:08 <andypost> jirutka, no) basically drupal 8.5 will be released & this version will start support php 7.2 so I will move my CI on it - and then can detect more regressions
2018-03-06 00:41:13 <kaniini> as derivatives are likely to freeze as well
2018-03-06 00:41:48 <andypost> actually in 2 days
2018-03-06 00:42:30 <andypost> I just prefer to test it enough
2018-03-06 00:42:44 <jirutka> okay, that’s reasonable!
2018-03-06 00:42:45 <andypost> too many incompatibilities
2018-03-06 00:42:46 <kaniini> jirutka: end of march
2018-03-06 00:43:18 <jirutka> okay, so we have still some time
2018-03-06 00:44:27 <jirutka> I’d like to get some new lang into 3.8 (among others), currently working on Crystal and Reason :P
2018-03-06 00:45:38 <jirutka> good night
2018-03-06 01:07:55 <mitchty> question on a community apk, so i've found out the armhf ghc problem appears to be a bug in ghc thats getting looked at by people that can debug ghc better than I
2018-03-06 01:08:09 <mitchty> but ghc 8.2.2 builds easy on x86_64
2018-03-06 01:08:49 <mitchty> should I split ghc out into ghc80 and ghc82 and have a provides to keep x86_64 up to date until armhf can get fixed? or rather what is the overall strategy for situations such as these
2018-03-06 02:31:36 <kaniini> if you want to
2018-03-06 03:00:30 <Aerdan[m]> is there any particular reason we have lua5.1, lua5.2, *and* lua5.3? it is causing incompatibilities, such as weechat-lua is built against 5.1 but lua-cjson is built against 5.2.
2018-03-06 03:44:36 <koldbrutality> something like vlc might require a specific version
2018-03-06 03:46:53 <koldbrutality> sometimes patching is not trivial
2018-03-06 06:15:55 <tmh1999> clandmeter: it looks like you just set up boot.a.o ? I was wondering how the initramfs is loaded ? In the qemu setup, only the kernel is specified.
2018-03-06 06:20:59 <tmh1999> is the initramfs loaded through network ? If so, I suppose they are located at : https://boot.alpinelinux.org/alpine-ipxe/ . But I don't think any of those files are/contain an initramfs.
2018-03-06 06:31:22 <dehoptu[m]> https://boot.alpinelinux.org/images/latest-stable/x86_64/initramfs-vanilla
2018-03-06 06:31:35 <dehoptu[m]> is referenced from https://boot.alpinelinux.org/boot.ipxe
2018-03-06 06:33:25 <tmh1999> dehoptu[m]: wow how did you find that ?
2018-03-06 06:34:08 <dehoptu[m]> Just snooping :P
2018-03-06 06:34:12 <tmh1999> <dehoptu[m] : oh gotchat
2018-03-06 06:34:25 <tmh1999> I thought it was a bin file
2018-03-06 06:34:41 <tmh1999> dehoptu[m]: thanks!
2018-03-06 07:11:46 <clandmeter> tmh1999: yes it's just a txt file
2018-03-06 07:12:56 <tmh1999> clandmeter: yes. one quick question while you are here. after loading the initramfs, do you need other file system so the init could switch_root to ?
2018-03-06 07:13:21 <_ikke_> I guess tmpfs is used?
2018-03-06 07:14:06 <clandmeter> What _ikke_ said
2018-03-06 07:14:25 <clandmeter> If no root is specified tmpfs is used
2018-03-06 07:14:53 <tmh1999> _ikke_ :so it stay on ram. I'm still trying to figure out the initramfs-init.in script. What I want is basically setup a SSH server while the rootfs is on tmpfs, so that I can ssh in, then do setup-alpine
2018-03-06 07:15:38 <clandmeter> You need a overlay to do that
2018-03-06 07:16:27 <clandmeter> That's not supported via my script
2018-03-06 07:16:50 <clandmeter> But you can host your own boot script
2018-03-06 07:17:37 <clandmeter> And build your own ipxe which will load your own
2018-03-06 07:20:39 <tmh1999> clandmeter : Understood. What I am trying to do is, to understand how the 2nd file system is loaded after initramfs, by reading your netboot work. I need to configure the network while in being in that 2nd filesystem, because the network interface in s390x do not work out of the box.
2018-03-06 07:20:45 <clandmeter> Not sure which cmline it is. Probably something with ovl=http://...
2018-03-06 07:20:46 <clandmeter> We could extend the current script to do more. I will add it to git soon.
2018-03-06 07:21:47 <tmh1999> clandmeter : I may need to setup a couple of questionaries, like in setup-alpine, setup-disk. So that user can setup their own networking stuff. Then, setup a ssh server, then ssh into it to setup-alpine.
2018-03-06 07:22:32 <clandmeter> I'm going to work. we can talk later if you like
2018-03-06 07:22:44 <tmh1999> clandmeter :  Thanks btw
2018-03-06 07:28:50 <tmh1999> _ikke_ : Guess I can safely ignoring this https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n442 and skip to #455 ?
2018-03-06 07:43:16 <_ikke_> tmh1999: I wouldn't know, sorry
2018-03-06 08:04:26 <tmh1999> it turns out /etc/mdev.conf has a line for cdrom.
2018-03-06 08:04:33 <tmh1999> dang
2018-03-06 08:06:49 <tmh1999> I was mistaken that, instead of a tmpfs, initramfs switch_root to the cdrom as new rootfs. dang!
2018-03-06 08:07:14 <clandmeter> morning
2018-03-06 08:07:19 <clandmeter> cdrom?
2018-03-06 08:07:23 <tmh1999> morning
2018-03-06 08:07:37 <tmh1999> clandmeter: no it's another thing, not netboot.
2018-03-06 08:08:55 <clandmeter> tmh1999: regarding netboot, i dont think ipxe supports your arch. https://git.ipxe.org/ipxe.git/tree/HEAD:/src/arch
2018-03-06 08:09:05 <tmh1999> yes
2018-03-06 08:09:36 <tmh1999> I was trying to understand your way of doing netboot in other to do the thing I mentioned above
2018-03-06 08:10:11 <tmh1999> I thought you customized the init script
2018-03-06 08:10:38 <tmh1999> oh you did, did you ?
2018-03-06 08:10:52 <clandmeter> no its all vanilla or upstreamed
2018-03-06 08:11:03 <tmh1999> okay
2018-03-06 08:11:04 <clandmeter> we already supported netbooting
2018-03-06 08:11:12 <tmh1999> yeah
2018-03-06 08:11:14 <clandmeter> the only more recent addition is fetching the modloop via modloop initd
2018-03-06 08:12:03 <clandmeter> and fetching an ovl file via network, for instance to setup additional networking and ssh.
2018-03-06 08:13:24 <tmh1999> understood. nice thing to have. it's better now to install on pcengines boards.
2018-03-06 08:13:30 <tmh1999> :)
2018-03-06 08:41:07 <ncopa> seems like librsvg now require rust
2018-03-06 09:44:11 <ncopa> we will need rust for the other arches sooner than later
2018-03-06 12:38:02 <ncopa> i have been looking at goffice on x86
2018-03-06 12:38:14 <ncopa> we have a problem there, and i think its the same as we have in firefox
2018-03-06 12:38:50 <ncopa> the test suite fails when it is checking its math functions
2018-03-06 12:39:02 <ncopa> apparently goffice has its own library for math
2018-03-06 12:39:30 <ncopa> and the test suite checks it against the libc math lib
2018-03-06 12:39:43 <ncopa> (why not just use libc math then?)
2018-03-06 12:40:11 <ncopa> apparently they mess with the FPU state in a way that confuses musl libc functions
2018-03-06 12:40:40 <ncopa> so musl sin() returns unexpected value
2018-03-06 12:41:24 <ncopa> this basically means that if you mix libc math function with goffice math functions you may end up with something unexpected
2018-03-06 12:42:33 <ncopa> i wonder if we should either skip this test or disable goffice (and gnumeric) on x86
2018-03-06 12:58:14 <mps> any chance to fix bug/issue https://bugs.alpinelinux.org/issues/8598
2018-03-06 13:05:44 <jottr> Hi all. I hope this is the right place, since it's an ongoing issue: https://github.com/rspec/rspec-support/issues/341#issuecomment-364373387 renders ruby containers unusable when used with alpine.
2018-03-06 13:06:24 <jottr> We consider this a severe issue, since it forces us to move everything to ubuntu containers now. We'd highly prefer to stay on alpine.
2018-03-06 13:09:14 <jottr> Could we manually increase stack size? E.g. by setting RLIMIT_STACK to a higher value?
2018-03-06 13:19:26 <skarnet> jottr: this has nothing to do with RLIMIT_STACK, but with the default thread stack
2018-03-06 13:19:56 <skarnet> the correct workaround is to patch the ruby interpreter in Alpine, increasing the default thread stack size
2018-03-06 13:20:42 <skarnet> so that even if ruby doesn't offer a way to modify it, then at least it explicitly sets it to a given size instead of relying on the libc-provided default
2018-03-06 13:22:31 <jottr> skarnet: Ok. Can't find a related issue to that though. How and where should I escalate this? Issue tracker? Are there specific people I could/should ping? I believe this is quite severe and might bite people using alpine with ruby
2018-03-06 13:23:45 <skarnet> now that it has been mentioned here, it will likely be picked up, but if you want to accelerate the pace, you can find the maintainer of the ruby package (listed in the APKBUILD) and ping them directly.
2018-03-06 13:25:57 <skarnet> also, what Alpine can do at this point is really a workaround, and the problem should mainly be reported to, and handled by, the Ruby authors: they're assuming a big default thread stack size, which is an incorrect assumption that happens to be true when using glibc.
2018-03-06 13:28:11 <ncopa> jottr: interesting. we had similar issue with python
2018-03-06 13:28:23 <ncopa> we *have*
2018-03-06 13:28:54 <ncopa> there is a maxrecursiondepth (or similar) value in python
2018-03-06 13:29:19 <ncopa> and python will check for some known platforms and explicitly increase the thread stack size if its known to be small
2018-03-06 13:29:43 <ncopa> (which is backwards imho, should assume small and check for known ok platforms)
2018-03-06 13:31:19 <ncopa> https://bugs.python.org/issue32307
2018-03-06 13:31:35 <ncopa> jottr: we need a minimal testcase that demonstrates the problem
2018-03-06 13:31:53 <jottr> Hm. So should this be something that's fixed in the interpreter code itself or should alpine ruby containers be patched for now to allow larer stack size?
2018-03-06 13:32:16 <jottr> ncopa: I believe someone created one already. Hold on
2018-03-06 13:32:31 <jottr> ncopa: https://bugs.ruby-lang.org/issues/14387
2018-03-06 13:33:54 <skarnet> you got it
2018-03-06 13:34:27 <jottr> Also https://github.com/koshigoe/ruby-2.5.0-stack-level-too-deep
2018-03-06 13:34:44 <skarnet> the ideal solution is probably a workaround in Alpine until the Ruby devs implement the real fix.
2018-03-06 13:34:59 <_ikke_> which might never happen
2018-03-06 13:35:02 <ncopa> it should be fixed in ruby interpreter code
2018-03-06 13:35:14 <ncopa> that ruby issue seems like the correct thing to fix
2018-03-06 13:35:37 <skarnet> absolutely
2018-03-06 13:36:19 <jottr> Ok. So should this be escalated somehow? Or is it just me that sees this as serious issue?
2018-03-06 13:37:31 <ncopa> i agree its serious
2018-03-06 13:37:55 <ncopa> jottr: can you please create an issue on bugs.alpinelinux.org with the above links
2018-03-06 13:38:19 <ncopa> i dont think i will have time to look at it today but i can try tomorrow
2018-03-06 13:38:24 <ncopa> i dont think its too difficult to fix
2018-03-06 13:38:40 <ncopa> there is a LD_PRELOAD trick you could use meanwhile
2018-03-06 13:38:45 <ncopa> let me see if i find it
2018-03-06 13:40:25 <ncopa> A small C wrapper hack: https://github.com/esnme/ultrajson/issues/254#issuecomment-314862445
2018-03-06 13:41:14 <jottr> ncopa: Thx. So the plan is to indeed patch it at container image level for now?
2018-03-06 13:41:24 <jottr> Just so we know where we should track this
2018-03-06 13:53:44 <ncopa> jottr: for now, yes, but this should be fixed in ruby
2018-03-06 13:53:48 <ncopa> i think i can have a patch for alpine packages ruby fairly soon
2018-03-06 13:54:54 <ncopa> the official ruby doecker images uses source from upstream, but we may get those patched too, while they/we figure out how to solve it upstream
2018-03-06 15:23:19 <jottr> ncopa: Thank you so much.
2018-03-06 18:57:04 <tmh1999> awilfox[m] : https://qz.com/1220822/scientists-have-documented-a-secret-supercolony-of-1-5-million-penguins-with-the-help-of-nasa-images-drones-and-artificial-intelligence/
2018-03-06 23:05:46 <kaniini> erlang is a disaster on alpine
2018-03-06 23:06:35 <kaniini> i'm going to try to clean this up as best i can
2018-03-06 23:28:14 <Aerdan[m]> https://github.com/alpinelinux/aports/pull/3531
2018-03-07 00:03:32 <duncan^> I should like to use USB-based smartcard, such as Yubikey, with Alpine.
2018-03-07 00:03:52 <duncan^> Particularly, in GnuPG.
2018-03-07 00:04:50 <duncan^> Unfortunately, we cannot do this without 1) enabling the internal CCID driver (--enable-ccid-driver build-time configuration option) and 2) enabling libusb support in GnuPG (--enable-libusb).
2018-03-07 00:05:03 <duncan^> Could this be added?
2018-03-07 00:06:15 <duncan^> In fact, enabling scdaemon would also be neccessary (--enable-scdaemon)
2018-03-07 09:33:20 <ncopa> duncan^: i guess we can do that. can you please create an issue at bugs.a.o? so we can refer to it in the commit message. might be good to have in history why we changed it
2018-03-07 09:58:47 <duncan^> ncopa: Sure. Thanks.
2018-03-07 10:00:03 <_ikke_> +1
2018-03-07 10:05:55 <duncan^> for "affected versions", I guess select 3.8.0 as it's something that might be useful for the next release (it would require a dependency on libusb IIRC)
2018-03-07 10:09:37 <duncan^> eh, "target version", more like. Sorry for the noise.
2018-03-07 10:22:54 <duncan^> heh!
2018-03-07 10:38:40 <ncopa> duncan^: looks like debian only have a simplified verification tool, and the rest is a full blown gnupg
2018-03-07 10:40:00 <duncan^> Hmm, they do seem to split up gnupg-agent and gnupg: https://packages.debian.org/stretch/gnupg
2018-03-07 10:40:19 <duncan^> I think it's so that (somehow) one can use the agent without gnupg or something
2018-03-07 10:40:47 <duncan^> but not vice versa as GnuPG 2.x's architecture is to separate operations from the program
2018-03-07 10:40:57 <duncan^> they also split out dirmngr and scdaemon
2018-03-07 10:41:38 <duncan^> the whole thing is a mess
2018-03-07 10:54:30 <ncopa> i have no clue how to split it properly
2018-03-07 10:56:50 <duncan^> It seems like it would cause more trouble than not, e.g. https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059981.html
2018-03-07 10:56:55 <duncan^> 
ACTION shivers

2018-03-07 10:57:08 <bernhardgruen> How about two packages gnupg and gnupg-full for example.
2018-03-07 10:58:05 <ncopa> would prefer avoid that
2018-03-07 10:58:29 <duncan^> There doesn't seem to be a significant difference in size: gpg binary is 3.8M, gpg-agent is 1.6M, gpgsm is 2.0M, libgcrypt is a massive 4.0M, etc
2018-03-07 10:58:55 <duncan^> and the current package already depends on sqlite because it builds with trust-on-first-use trust model support
2018-03-07 10:59:13 <duncan^> (IIRC)
2018-03-07 10:59:57 <duncan^> I guess it would make sense to add the gpgv standalone package though
2018-03-07 11:00:44 <ncopa> i saw debian builds it static too
2018-03-07 11:01:07 <ncopa> probably because they use it for verifying .deb packages
2018-03-07 11:01:08 <ncopa> which we dont
2018-03-07 11:04:30 <duncan^> Yes, apt appears to depend on it, so I guess that's the case
2018-03-07 11:07:35 <ncopa> reading that email...
2018-03-07 11:08:14 <ncopa> sounds like it would be useful with a rewrite of a gpg-like tool/library which is compatible with the gpg signatures
2018-03-07 11:08:24 <ncopa> simplified tool
2018-03-07 11:08:48 <ncopa> with stable API
2018-03-07 11:09:06 <duncan^> The OpenPGP specification is not simple though, which is also a problem with such a tool.
2018-03-07 11:10:00 <duncan^> That may be why OpenBSD made their signify tool, but that seems to have much-reduced assumptions because they did not need GnuPG for that application.
2018-03-07 11:11:58 <ncopa> and we dont use gpg for .apk either
2018-03-07 11:12:06 <ncopa> oh well, what a mess
2018-03-07 11:12:21 <ncopa> i think we simply enable the needed options and live with the bloat
2018-03-07 11:12:55 <ncopa> bernhardgruen: hi, re docker-ce stable/edge
2018-03-07 11:13:45 <ncopa> i think we should upgrade alpine 3.7 to latest stable docker-ce, and have alpine edge to use docker-ce edge
2018-03-07 11:15:10 <bernhardgruen> I am fine with that. Then 3.8 should have 18.03.0, right?
2018-03-07 11:17:29 <ncopa> which will be the next stable, if i understand things right?
2018-03-07 11:17:36 <ncopa> yes, that is what i want
2018-03-07 11:18:20 <bernhardgruen> Docker stable releases are currently published in a 3 month interval.
2018-03-07 11:18:43 <bernhardgruen> So yes. 18.03 will be a stable version
2018-03-07 11:19:57 <bernhardgruen> if you like I can send a pull request for edge which will contain 18.02 after your backport to 3.7
2018-03-07 13:35:10 <ncopa> bernhardgruen: i pushed docker 17.12 to alpine 3.7
2018-03-07 13:42:56 <ncopa> awilfox: we have an issue with moving v4l-utils to community (commit 689327e79503480e774cff04560f8e4c695f5824)
2018-03-07 13:43:02 <ncopa> ffmpeg is in main and depends on v4l-utils
2018-03-07 13:43:06 <ncopa> this means that it is no longer possible to build everything in 'main' repo without also building 'community'
2018-03-07 13:43:11 <ncopa> it also means that we can no longer provide 2 year support for ffmpeg since one of its depends only have 6 month support
2018-03-07 13:44:29 <ncopa> we need to either move the entire reverse dependency chain over to community, or move qt5 to main
2018-03-07 13:44:52 <ncopa> qt5-qtbase should be enough
2018-03-07 13:48:53 <ncopa> hum, i think we can move the reverse deptree
2018-03-07 14:40:19 <terra> Guys, I want to test some APKBUILDs with a single command like "abuild -r" but I don't want packages to be generated and build folders to be removed.
2018-03-07 14:44:44 <terra> I want this order: "abuild clean deps prepare build rootpkg" but rootpkg build packages creates new index.
2018-03-07 14:59:18 <clandmeter2> -K keeps build folder
2018-03-07 14:59:37 <clandmeter2> and dont exclude our girls!
2018-03-07 15:00:22 <skarnet> wishful thinking
2018-03-07 15:04:03 <ncopa> i moved ffmpeg to community
2018-03-07 15:13:47 <terra> do admins prefer git pull requests instead of mails?
2018-03-07 15:14:14 <terra> I have packages waiting to be reviewed
2018-03-07 15:14:33 <terra> I mean new aports
2018-03-07 15:21:02 <clandmeter2> there is no specific preference
2018-03-07 15:21:53 <clandmeter2> use you own preference instead.
2018-03-07 20:57:35 <okeuday_bak> Hi, could someone merge https://github.com/alpinelinux/aports/pull/3438 ?
2018-03-07 21:25:20 <id4rk> mps: if they are going to add the serial feature, it would be better to add it with speed 115200
2018-03-07 21:27:21 <id4rk> at least in the apu boards the bios boots with 115200 so it would go seamless into setup... not having to switch speeds on putty for installation, maybe a speed should be used which is used by default by most of the boards
2018-03-07 21:30:04 <mps>  id4rk: in last ten years every board with which I worked usually auto set/change speed to the speed of the terminal emulator which I use and set
2018-03-07 21:30:15 <mps> never had problem with speed
2018-03-07 21:31:06 <id4rk> mps: ok
2018-03-07 21:32:03 <mps> id4rk: try to connect with some terminal emulator to see, screen for example
2018-03-07 21:33:00 <mps> novadays I even do not look at the speed of serial interface when I use console
2018-03-07 21:34:23 <mps> id4rk: btw, why you talk on #alpine-linux and #alpine-devel about the same topic, or my irssi making a mess
2018-03-07 23:10:40 <id4rk> 
ACTION is chatting from the apu now :)

2018-03-07 23:11:20 <id4rk> brb
2018-03-07 23:23:47 <mps> id4rk: congratulation :)
2018-03-07 23:25:20 <id4rk> mps: thank you! =]
2018-03-08 08:56:34 <ncopa> mps: i cannot reproduce https://bugs.alpinelinux.org/issues/8598
2018-03-08 11:13:14 <mps> ncopa: how can I help with https://bugs.alpinelinux.org/issues/8598
2018-03-08 11:13:36 <clandmeter2> ncopa, why cant i have a bridge interface without a bridge-port?
2018-03-08 11:18:58 <clandmeter2> ah i need to explicitly define bridge-ports to none.
2018-03-08 12:12:37 <id4rk> Is there a problem with the bug reporting? i cannot register... says...login is invalid
2018-03-08 12:19:26 <clandmeter2> i can login just fine.
2018-03-08 12:35:04 <id4rk> Im trying to register.
2018-03-08 12:35:29 <jottr> ncopa2: Returning to the stack-issue I raised yesterday. Is there a place this is being tracked? It seems it's not in https://github.com/docker-library/ruby/issues Or am I looking in the wrong place?
2018-03-08 12:37:21 <ncopa> jottr: its tracked here: https://bugs.ruby-lang.org/issues/14387
2018-03-08 12:37:42 <ncopa> i know what the problem is (i think)
2018-03-08 12:37:49 <ncopa> but I don't know what the proper fix is
2018-03-08 12:38:35 <ncopa> so what happens is that ruby now check so you don't run out of stack space (which is good)
2018-03-08 12:39:00 <ncopa> to do so they check how much stack space you have, using pthread_getattr_np(pthread_self())
2018-03-08 12:39:36 <ncopa> what the stack size should be for main thread is not well defined
2018-03-08 12:40:06 <ncopa> on musl it reports what the kernel can guarantee that you have
2018-03-08 12:40:26 <ncopa> in this case its ~128k
2018-03-08 12:40:46 <ncopa> in practice you can have up to ulimit -s for main thread
2018-03-08 12:41:54 <ncopa> so ruby thinks it has alot less stack space than it has in practice
2018-03-08 12:42:52 <ncopa> and it raises error earlier than needed
2018-03-08 13:05:40 <jottr> ncopa: thx for the update. So this means we'll have to wait until ruby devs have fixed it at their end, right?
2018-03-08 13:06:41 <ncopa> this may easily end up as a blame-game
2018-03-08 13:07:08 <ncopa> ruby devs may say that musl is broken
2018-03-08 13:07:30 <danieli> lol..
2018-03-08 13:07:48 <danieli> requiring a ridiculous amount of stack space is broken
2018-03-08 13:08:05 <jottr> ncopa: ah dang. The question is, how can we fix it downstream until they made up their mind of who's responsible
2018-03-08 13:08:34 <jottr> I'd really prefer to stay with alpine, than having to move to ubuntu containers because of this
2018-03-08 13:08:59 <ncopa> danieli: in this case, there is enough stack space, but ruby thinks that is has less than it has in practice
2018-03-08 13:09:13 <danieli> still broken
2018-03-08 13:09:48 <ncopa> yup
2018-03-08 13:10:19 <ncopa> jottr: i have some ideas how to work around it, but i don't like any of the options
2018-03-08 13:11:33 <ncopa> to fix it in ruby you'd have to check if pthred_self() main thread, but there are no portable way to do so
2018-03-08 13:12:46 <ncopa> i think its trivial to do that check in musl though
2018-03-08 13:12:56 <jottr> ncopa: Are musl devs aware?
2018-03-08 13:13:21 <ncopa> yes
2018-03-08 13:13:28 <ncopa> i asked in #musl
2018-03-08 13:13:44 <jottr> ncopa: cool thx
2018-03-08 13:14:50 <jottr> ncopa: Shouldn't this still be tracked on https://github.com/docker-library/ruby/issues as well? Since its affecting people downstream.
2018-03-08 13:15:37 <ncopa> i guess it should
2018-03-08 13:15:44 <ncopa> and it should be tracked in bugs.alpinelinux.org too
2018-03-08 13:16:01 <ncopa> jottr: it would be helpful if you created issues there
2018-03-08 13:30:20 <bernhardgruen> Seems to be the right way.
2018-03-08 13:32:13 <bernhardgruen> btw. I once had similar problems with Java 7 inside a container. The only solution was to update to Java 8 and add some special "docker relevant options".
2018-03-08 13:34:16 <jottr> ncopa: Ok, will do
2018-03-08 14:11:02 <abbierwolf> Hi. Yesterday I created some pull requests on github. What can I expect about the handling of these pull requests? Is there a period within the pull requests are handled or do I have to notify someone?
2018-03-08 14:11:27 <duncan^> The pull request was made, wait for it
2018-03-08 14:15:37 <abbierwolf> duncan^: I understand there are limited people who have to do the work. I was just wondering what the average period of waiting time is.
2018-03-08 14:16:30 <TBB> damn it libressl, seems they've messed with the default ciphers again... stuff that worked on Alpine 3.5 mysteriously stopped working after 3.7 upgrade
2018-03-08 14:18:02 <TBB> no problem with libressl doing things like that, but when it breaks every single tool on top of it that doesn't have a means of specifying a cipher outside the defaults, like wget and curl...
2018-03-08 14:23:15 <fabled> we had long thread on switching back to openssl
2018-03-08 14:23:34 <fabled> since openssl seems to have been picked up again, and libressl breaking stuff and removing useful stuff (e.g. engines)
2018-03-08 14:23:37 <fabled> ncopa, ^
2018-03-08 14:32:01 <ncopa> TBB: can you report the specific issue and a way for us to reproduce?
2018-03-08 14:32:03 <ncopa> fabled: i dont think we will switch back to openssl for v3.8 atleast
2018-03-08 14:42:26 <fabled> ncopa, yeah. it might be late, and it's going to be major change. but i think we may need to pick up from where the discussion was left on the mailing list.
2018-03-08 14:42:55 <TBB> ncopa, sure. before filing a ticket, I'll just tell you we've got some internal repos using https and using a specific ec cipher in our certs that for some reason is no longer among the default ones in libressl
2018-03-08 14:43:41 <TBB> and these defaults have changed somewhere between late 3.5 and 3.7
2018-03-08 14:44:39 <fabled> TBB: yes, we had ticket about this earlier too, let me find it
2018-03-08 14:44:45 <TBB> yeah, I've got it open
2018-03-08 14:44:50 <TBB> 8199
2018-03-08 14:44:57 <TBB> methinks
2018-03-08 14:45:02 <fabled> https://bugs.alpinelinux.org/issues/8199
2018-03-08 14:45:04 <fabled> yes
2018-03-08 16:37:38 <_ikke_> id4rk: still having issues registring on bugs.a.o?
2018-03-08 17:05:58 <id4rk> _ikke_: let me try again
2018-03-08 17:13:34 <id4rk> _ikke_: yes, after pressing submit i get a exclamationmark with a login is invalid
2018-03-08 17:17:38 <_ikke_> And that's right after registration?
2018-03-08 17:18:29 <_ikke_> I see other people successfuly created accounts today
2018-03-08 17:21:49 <_ikke_> logs don't give any indication of something going wrong
2018-03-08 19:07:59 <id4rk> _ikke_: I am home soon.
2018-03-08 19:39:31 <mps> ncopa: ayt
2018-03-08 19:40:15 <mps> ncopa: regarding issue https://bugs.alpinelinux.org/issues/8598
2018-03-08 20:29:58 <id4rk> _ikke_: it worked on the desktop...seems to be a mobile browser issue, at least with safari on iphone
2018-03-08 20:45:47 <_ikke_> id4rk: Hmm, ok. I cannot test that myself
2018-03-08 20:46:57 <id4rk> _ikke_: i will try to register with firefox on ios, to see if its your mobile version of the web or safari
2018-03-08 20:48:34 <id4rk> _ikke_: it also fails on firefox
2018-03-08 20:48:50 <id4rk> mobile
2018-03-08 20:49:21 <_ikke_> right, same render engine, just a different 'skin'
2018-03-08 20:51:58 <id4rk> Can anyone try to register an account on the bug tracker with Firefox/Chrome on Android?
2018-03-08 20:52:10 <id4rk> 
ACTION is curious now

2018-03-08 20:52:13 <_ikke_> I can on android
2018-03-08 20:53:11 <id4rk> i also tried it on the phone with wlan and mobile network so its not a provider issue
2018-03-08 20:54:25 <_ikke_> "Login is invalid"
2018-03-08 20:54:32 <id4rk> exactly
2018-03-08 20:58:31 <_ikke_> I'll check with my tablet to see if I can find differences in the request
2018-03-08 20:58:57 <jottr> ncopa2: Just came around to submit the issue: https://github.com/docker-library/ruby/issues/197
2018-03-08 21:05:40 <id4rk> 
ACTION *thumb-up*

2018-03-08 22:41:49 <_ikke_> id4rk: Ok, in my case it was because I had a space at the end
2018-03-09 06:00:36 <okeuday_bak> When attempting to build an ISO on x86 with the current aports repo, I am getting an error from update-kernel: "cp: can't stat '/tmp/update-kernel.fo0pMp/root/boot/System.map': No such file or directory", is anyone aware of this as a problem?
2018-03-09 06:56:21 <id4rk> _ikke_: maybe because i used autofill form, curious...
2018-03-09 08:08:09 <clandmeter2> okeuday_bak, its known
2018-03-09 08:09:46 <clandmeter2> okeuday_bak, which version of alpine-conf do you have installed?
2018-03-09 11:07:12 <bernhardgruen> It seems that since the last outage of sourceforge.net the method of downloading packages from there does not work anymore. I get always 502 oder 504 responses. Tested for different packages (in main).
2018-03-09 11:07:57 <bernhardgruen> This will make it impossible to rebuild those packages at the moment.
2018-03-09 11:14:24 <bernhardgruen> It seems the URLs work if I switch from http to https (tested for ngrep and sshpass).
2018-03-09 14:44:46 <neirac> is there a version of alpine with zfs on root ?
2018-03-09 14:45:42 <_ikke_> neirac: no need to cross-post :)
2018-03-09 14:49:01 <neirac> @_ikke_ I'm sorry. what version of alpine is suitable for development ? the xen one ?
2018-03-09 15:03:47 <duncan^> How do we know what would be suitable for your development pattern?
2018-03-09 15:41:07 <neirac> duncan^ I'm sorry, if I want to contribute to alpine linux, which of the currently available version is the best to use.
2018-03-09 15:44:23 <danieli> use whichever fits for the platform you're on
2018-03-09 15:44:39 <danieli> might as well just go with standard, you're going to need alpine-sdk, git and some stuff anyway
2018-03-09 15:45:32 <mps> in which runlevel udev should be
2018-03-09 15:45:52 <mps> default or sysinit?
2018-03-09 15:50:05 <neirac> danieli, thanks a lot.
2018-03-09 15:50:42 <danieli> neirac: the difference is mostly the amount of packages included, but some have different kernels - iirc -virt is slimmed down
2018-03-09 16:08:31 <jeffr76> Hello all
2018-03-09 16:09:23 <jeffr76> i would like to help patch a few vulns that are in a few libs
2018-03-09 16:09:47 <jeffr76> freetype is my first one
2018-03-09 16:10:13 <jeffr76> my question is do i change the APKBUILD in the git patch or only add the patchfile
2018-03-09 16:10:30 <danieli> if you add a .patch, you need to add it to sources in the apkbuild
2018-03-09 16:10:36 <danieli> if not, abuild ignores it
2018-03-09 16:10:48 <danieli> (you also need to run abuild checksum to get the checksum of your patch
2018-03-09 16:10:49 <danieli> )
2018-03-09 16:11:20 <jeffr76> ok, so what i send in is really 2 patches 1. to the files of the lib 2. to the build file APKBUILD
2018-03-09 16:11:43 <jeffr76> all as an email following http://wiki.alpinelinux.org/wiki/Creating_patches
2018-03-09 16:19:16 <danieli> install git, set it up, pull aports, make your changes, create a patch and either a) create a github PR or b) send the patch to alpine-aports@lists.alpine.aports (patchwork)
2018-03-09 16:20:17 <bernhardgruen> I only get danieli answers - what is wrong?
2018-03-09 16:20:25 <danieli> what?
2018-03-09 16:21:40 <bernhardgruen> On matrix I only get your anwers but no questions.
2018-03-09 16:21:52 <danieli> oh I see
2018-03-09 16:21:59 <danieli> I'm talking to jeffr76, no idea why you're not seeing it
2018-03-09 16:22:05 <danieli> I don't use matrix
2018-03-09 16:22:15 <duncan^> The future of chat is here
2018-03-09 16:22:15 <bernhardgruen> It like playing jeopardy in the alpine world.
2018-03-09 16:22:51 <danieli> jeffpardy
2018-03-09 16:24:31 <kaniini> if freenode is the future of chat, i'd rather stop chatting entirely
2018-03-09 16:24:39 <danieli> it's the 80s of chat
2018-03-09 16:24:44 <kaniini> (most likely the matrix bridge is overloading because it's a piece of junk node.js software)
2018-03-09 16:24:54 <danieli> probably, yeah
2018-03-09 16:25:02 <danieli> and aren't we running synapse (python)?
2018-03-09 16:25:05 <bernhardgruen> good to know - I know it is off topic. But... any better solution?
2018-03-09 16:25:50 <danieli> I've mostly been on email, discord and wire lately
2018-03-09 16:25:56 <kaniini> matrix.org itself provides the bridge for a few logistical reasons that can be summed up as "both the matrix to irc bridge sucks, and irc itself sucks"
2018-03-09 16:25:57 <danieli> discord for gaming
2018-03-09 16:26:34 <sroracle> discord is closed source
2018-03-09 16:26:38 <kaniini> i do not use proprietary communications services
2018-03-09 16:26:41 <kaniini> it is nice
2018-03-09 16:26:45 <danieli> it is indeed proprietary which is why i despise it
2018-03-09 16:28:31 <bernhardgruen> I looked into mattermost recently. Looks promising (comparable to slack somehow)
2018-03-09 16:29:39 <kaniini> i don't like mattermost because it lacks federation
2018-03-09 16:29:43 <kaniini> it is not enough of an improvement over irc servers
2018-03-09 16:32:28 <duncan^> IRCv3 seems to be better than Matrix.
2018-03-09 16:40:09 <jeffr76> @danieli thanks lets see if i can do it correctly :)
2018-03-09 16:54:50 <danieli> protip: don't prepend usernames with "@" on IRC
2018-03-09 16:56:37 <skarnet> he wanted you to be op :)
2018-03-09 16:57:00 <danieli> or someone is a bit used to $every_social_media_ever
2018-03-09 17:02:19 <mitchty> did apk change recently to not allow makedepends="$pkgname"? I'm hitting the fun of not being able to install the package i'm building with ghc, even though the entry is in the APKBUILD
2018-03-09 17:03:08 <_ikke_> You are trying to bootstram ghc?
2018-03-09 17:03:11 <_ikke_> bootstrap*
2018-03-09 17:03:18 <mitchty> no
2018-03-09 17:03:22 <mitchty> you build ghc with ghc
2018-03-09 17:03:30 <mitchty> always, even when bootstrapping
2018-03-09 17:03:39 <mitchty> i'm trying to build a new version of ghc
2018-03-09 17:03:39 <_ikke_> right
2018-03-09 17:04:11 <mitchty> but even though makedepends has $pkgname (tried with ghc too) and even though the package is there, its never installed into the chroot
2018-03-09 17:04:54 <_ikke_> isn't the chroot for packaging only/
2018-03-09 17:04:56 <_ikke_> ?
2018-03-09 17:04:57 <mitchty> confused as this worked normally, not quite sure why this would be failing now
2018-03-09 17:06:04 <mitchty> to clarify https://gist.github.com/mitchty/bcdc3e2395e0bd1595e29519514a7b58
2018-03-09 17:07:46 <mitchty> i see other things I specify getting installed prior to configure but not ghc/$pkgname if its there
2018-03-09 17:08:18 <_ikke_> mitchty: if ghc is already installed, apk does not have to install it again
2018-03-09 17:08:26 <_ikke_> mitchty: iirc, there is no chroot
2018-03-09 17:08:40 <mitchty> its not installed, these build images are minimal
2018-03-09 17:08:47 <mitchty> though I could install it again
2018-03-09 17:09:02 <_ikke_> ok
2018-03-09 17:09:55 <mitchty> though i don't see why i'd need to install a makedepends outside of the apkbuild
2018-03-09 17:12:01 <_ikke_> mitchty: But alpine is built from scratch every time
2018-03-09 17:12:08 <mitchty> even if this works, I'm still curious why I would need to install a dependency outside of the apkbuild
2018-03-09 17:13:03 <mitchty> and why if the apk isn't installed, but present in the repos, that apk dependency isn't installed during the configure/build phase
2018-03-09 17:14:07 <mitchty> _ikke_: not really pertinent to the issue I'm seeing here, in that an existing apk package in a repo that exists isn't getting installed, or am I misunderstanding how apk build is working?
2018-03-09 17:17:28 <mitchty> in essence, I'm confused how xz, which isn't installed outside of any builds, installs, but not ghc, despite both being present in the release repositories
2018-03-09 17:18:20 <_ikke_> mitchty: They might guard against that
2018-03-09 17:18:27 <_ikke_> trying to find it in the source
2018-03-09 17:19:39 <mitchty> that will make ghc in general not really easy to maintain
2018-03-09 17:19:55 <mitchty> i'd rather not have to bootstrap it for every release
2018-03-09 17:20:11 <mitchty> especially when there is no need to do so with an existing version
2018-03-09 17:20:36 <mitchty> as well as this worked prior, so I'd consider this a bit of a regression
2018-03-09 17:24:05 <mitchty> even if i'd be bootstrapping other arches off x86_64 for example, I'd still need/want to be able to specify I need ghc to build a bootstrap ghc
2018-03-09 17:24:19 <_ikke_> I can't see any changes in this regard in the repository
2018-03-09 17:25:57 <mitchty> any way to debug why it wouldnt' be installing a specified dependency?
2018-03-09 17:32:27 <_ikke_> mitchty: abuild is a shell script, so you could just run it with -x
2018-03-09 17:38:04 <okeuday_bak> clandmeter2: alpine-conf-3.7.0-r0
2018-03-09 17:49:59 <clandmeter2> Upgrade
2018-03-09 17:52:15 <okeuday_bak> clandmeter2: The apk upgrade refuses to upgrade on x86
2018-03-09 17:53:39 <okeuday_bak> clandmeter2: the mirror is http://mirrors.gigenet.com/alpinelinux/v3.7/main (i.e. in /etc/apk/repositories)
2018-03-09 17:54:13 <okeuday_bak> so I am not sure if that mirror is out of date, or if that is a normal problem for x86 for all mirrors
2018-03-09 17:58:09 <okeuday_bak> http://mirror.leaseweb.com/alpine/v3.7/main is the same, though that has alpine-conf-3.7.0-r1 for x86_64
2018-03-09 17:59:14 <clandmeter2> okeuday_bak you need r1
2018-03-09 18:00:43 <clandmeter2> ah x86 is probably stuck
2018-03-09 18:54:43 <mitchty> _ikke_: ok cool i'll dig in there to figure out whats changed, thanks for the help!
2018-03-09 20:41:42 <okeuday_bak> clandmeter2: I don't understand how x86 gets unstuck, or why it would be stuck, though it does look like it was stuck since February 9th
2018-03-09 20:52:03 <clandmeter2> algitbot, retry 3.7-stable
2018-03-09 20:54:13 <clandmeter2> okeuday_bak, yes the 3.7 builder for x86 seems MIA
2018-03-09 21:38:36 <clandmeter2> okeuday_bak, builder has been restarted
2018-03-09 21:38:48 <clandmeter2> but its a bit behind. so im not sure how long it will take.
2018-03-09 21:48:04 <okeuday_bak> clandmeter2: np, thanks
2018-03-09 21:48:23 <clandmeter2> i didnt do anyting, _ikke_ did :)
2018-03-10 01:53:07 <koldbrutality> is there a way to exclude patch?
2018-03-10 01:53:30 <koldbrutality> from being applied?
2018-03-10 01:53:43 <koldbrutality> nm i think i found a way
2018-03-10 01:56:28 <koldbrutality> i don't think there is a way
2018-03-10 01:58:09 <koldbrutality> ahhh... i need to write my own prepare
2018-03-10 06:44:52 <koldbrutality> ...working on packaging TRESOR cold-boot AES mitigation patch for x86/x86_64 systems.  Loop-Amnesia's cold-boot has a dangerous quirk for suspend dataloss
2018-03-10 11:39:48 <jirutka> kaniini: you fixed erlang packaging, I’ve fixed ocaml packaging, this goes well! :)
2018-03-10 22:25:34 <carlosdavidepto[> hello all alpine devs. I just dropped by to say thanks for an awesome distro.
2018-03-10 22:25:50 <carlosdavidepto[> I've been running a btrfs-raid0 pseudo-NAS thing cobbled together from NAS grade HDDs, AL 3.5 and a refurbished dell laptop that may at this point be 10 years old. This contraption has given me zero headaches in it's entire 1 year+ of existence. That's a solid distro right there.
2018-03-10 22:29:53 <carlosdavidepto[> (I meant btrfs-raid1 actually, but it does not actually change the value of the above statement much)
2018-03-11 04:50:39 <thetooth> looking for help with building a custom iso image, currently stuck after following the wiki guide: https://gist.github.com/thetooth/c56f4c49337e5da4b64bc76596c2a113
2018-03-11 04:53:27 <thetooth> before i go any further my expectation is to be able to create a self booting image that will perform self configuration, i am wanting to know how alpine does non-sys install boots, i.e. how does it know where to find existing configuration? i'd like to tie a first boot script into the disk image so when the iso is booted from pxe it will configure itself with a network, install and update, but then be
2018-03-11 04:53:28 <thetooth> self contained on the next boot
2018-03-11 07:35:04 <_ikke_> thetooth: alpine uses apkovls]
2018-03-11 08:16:45 <thetooth> _ikke_: nice, i figured out my error, aparently you can't build an edge image on v3.7, i was able to build a v3.7 no issue after changing the repo and tag
2018-03-11 08:21:03 <thetooth> last question is where is my entry point for adding custom startup configuration? i would like to go from a bare metal machine with one unformatted disk to a fully configured system on the next boot, all while remaining headless
2018-03-11 13:11:27 <_ikke_> thetooth: what kind of setup? sys, disk or data?
2018-03-11 13:12:55 <_ikke_> thetooth: sorry, it's called diskless vs sys
2018-03-11 13:16:39 <_ikke_> thetooth: during boot, alpine will look for an apkovl, which it will overlay on the root filesystem
2018-03-11 14:27:49 <nmeum> http://tpaste.us/VRw8
2018-03-11 14:27:54 <nmeum> ^ any objections regarding this abuild patch?
2018-03-11 14:42:14 <_ikke_> nmeum: btw, I've been looking at properly splitting the fzf package for each shell, but somehow the tests are failing (even before making any change)
2018-03-11 14:42:52 <_ikke_> might have to do with a go update
2018-03-11 14:43:03 <nmeum> that's strange
2018-03-11 14:43:12 <nmeum> what's the error message the tests are failing with?
2018-03-11 14:43:30 <_ikke_> Several of these:
2018-03-11 14:43:32 <_ikke_> "Errorf format %s has arg []rune(output) of wrong type []rune"
2018-03-11 14:43:41 <nmeum> the subpackage split is actually done after check() is run so it shouldn't affect the tests
2018-03-11 14:43:57 <_ikke_> No, this is before any change has been made to the APKBUILD
2018-03-11 14:44:00 <nmeum> ah
2018-03-11 14:44:02 <_ikke_> so must be something else that has change
2018-03-11 14:44:19 <nmeum> the go compiler was updated recently
2018-03-11 14:44:28 <_ikke_> yeah, I noticed
2018-03-11 14:44:53 <nmeum> did you try downgrading the compiler?
2018-03-11 14:45:04 <_ikke_> not yet
2018-03-11 15:01:12 <bernhardgruen> I'll just test it with go 1.9.4 (same problem with 1.10 on my PC btw.)
2018-03-11 15:02:26 <bernhardgruen> _ikke_, it works with 1.9.4 (from 3.7)
2018-03-11 15:03:25 <_ikke_> yes, just ran it myself with 1.9.4
2018-03-11 15:03:33 <bernhardgruen> with 1.10 the following message is there: loadinternal: cannot find runtime/cgo
2018-03-11 15:03:57 <bernhardgruen> I also saw this message with my docker 17.12.1 build.
2018-03-11 15:04:02 <_ikke_> right
2018-03-11 15:05:02 <bernhardgruen> Unfortunately, I don't know what that message means. But it was not there for 1.9.4
2018-03-11 15:06:50 <_ikke_> and google doesn't either
2018-03-11 15:08:40 <bernhardgruen> I found a setting `CGO_ENABLED=0` - to disable cgo. The C in cgo seems stand for "crosscompile"
2018-03-11 15:10:34 <_ikke_> testing
2018-03-11 15:13:32 <_ikke_> I defined it as an env variable as well as pass it to make, but doesn't seem to make a difference
2018-03-11 15:14:36 <bernhardgruen> same here (tested it on manjaro - with go 1.10)
2018-03-11 15:16:48 <bernhardgruen> at least the error does not seem to be alpine specific.
2018-03-11 15:23:32 <bernhardgruen> _ikke_: https://golang.org/doc/go1.10#test (-count=1 -vet=off added to go test)
2018-03-11 15:25:49 <bernhardgruen> _ikke_: (Makefile line 105) adding only -vet=off seems to be sufficient. After that the tests are working (on Manjaro)
2018-03-11 15:28:25 <_ikke_> So you are just disabling the vetting part, right?
2018-03-11 15:29:39 <_ikke_> bernhardgruen: confirmed that that at least lets the tests pass, thanks!
2018-03-11 15:31:55 <bernhardgruen> perfect - I think the upstream author should fix that and not just disable this vetting.
2018-03-11 15:33:28 <_ikke_> right, i'll create an issue
2018-03-11 15:34:02 <terra> Guys, I'm trying to compile PaleMonn on Alpine. anyone tried before?
2018-03-11 15:34:10 <terra> *PaleMoon
2018-03-11 15:45:22 <duncan^> You'll need to individually patch all the libraries it bundles (and applies its own patches to)
2018-03-11 15:45:36 <duncan^> [in the case that they do not compile under Musl)
2018-03-11 15:47:48 <skarnet> terra: just in case, you should be aware of the attitude of palemoon developers regarding people who build palemoon: https://github.com/jasperla/openbsd-wip/issues/86
2018-03-11 15:49:05 <skarnet> tl;dr: if you distribute it under the name "palemoon" with a different configuration than The Sacred One, they will come at you with guns blazing (instead of asking nicely).
2018-03-11 15:49:32 <terra> skarnet: I'm pretty aware of that situation :)
2018-03-11 15:50:16 <skarnet> all right then. I'd hate it if it happened to you. :)
2018-03-11 15:50:43 <terra> skarnet: I have to do it becuse bundles graphite doesn't compile :]
2018-03-11 15:50:48 <terra> *bundled
2018-03-11 15:51:14 <skarnet> ha.
2018-03-11 15:51:17 <terra> I patched it via freeBSD port tu use system graphite2
2018-03-11 15:51:45 <terra> But biggest problem ic toolchain compatibility
2018-03-11 15:51:51 <terra> *is
2018-03-11 15:52:21 <terra> I'm stuck on this: https://forum.palemoon.org/viewtopic.php?f=37&t=18561
2018-03-11 15:52:37 <skarnet> my personal choice would be to stop using palemoon entirely, I dislike giving exposure to people who don't respect Open Source contributors
2018-03-11 15:53:13 <terra> skarnet: I'm on that way..to be sure. But my goal is something technical overcome.
2018-03-11 15:53:55 <skarnet> I totally understand.
2018-03-11 15:56:42 <terra> duncan^: I'm trying to depend on system libraries as much as possible thus violating their distribution policies.
2018-03-11 15:57:34 <duncan^> Perhaps said distribution policies should be violateed.
2018-03-11 15:58:36 <terra> I want to see it compiles with minimum reqs
2018-03-11 15:59:01 <terra> then try to make an APKBUILD that permissible
2018-03-11 16:09:54 <xentec> jirutka, ncopa: LLVM 6.0 PR is ready https://github.com/alpinelinux/aports/pull/3583
2018-03-11 16:19:37 <_ikke_> nmeum: https://github.com/alpinelinux/aports/pull/3585
2018-03-11 16:20:49 <terra> xentec: good news then.
2018-03-11 16:25:45 <nmeum> _ikke_: added a comment. I am also personally not a huge fan of subpackage helper functions such as _do_shell but I that's just my personal preference I guess
2018-03-11 16:26:19 <nmeum> accept for the stuff I noted in the comment it looks good
2018-03-11 16:28:31 <_ikke_> nmeum: AH, didn't know about install_if
2018-03-11 16:35:36 <_ikke_> Is there a default location for these completion scripts so that they are active? Or is it the users responsibility?
2018-03-11 16:40:34 <nmeum> _ikke_: there is a default location
2018-03-11 16:40:48 <nmeum> it depends on the shell of cause
2018-03-11 16:41:14 <nmeum> zsh uses /usr/share/zsh/site-functions for instance
2018-03-11 16:41:34 <nmeum> just take a look at the community/docker APKBUILD it install the completion files to these default locations
2018-03-11 16:41:46 <_ikke_> ok
2018-03-11 16:41:48 <_ikke_> thanks
2018-03-11 16:47:17 <nmeum> you're welcome
2018-03-11 17:04:45 <_ikke_> nmeum: should I use similar subpkg names?
2018-03-11 17:04:49 <_ikke_> bashcomp, etc
2018-03-11 17:06:50 <nmeum> bashcomp is just the function name
2018-03-11 17:07:20 <nmeum> the subpackage name is $pkgname-bash-completion
2018-03-11 17:07:23 <_ikke_> ah, the functionname is overriden
2018-03-11 17:07:26 <nmeum> yep
2018-03-11 17:07:52 <nmeum> please use the same subpackage name, the function name is not important
2018-03-11 17:08:33 <_ikke_> right
2018-03-11 17:08:54 <_ikke_> But I'll change them as they clash with the shell command names right now
2018-03-11 17:43:39 <terra> Can I alter subpackage version e.g. subpkgver= ?
2018-03-11 18:12:36 <jirutka> terra: no
2018-03-11 18:19:59 <terra> jirutka: beacuse not implemented yet.. or it will break things?
2018-03-11 18:20:10 <jirutka> terra: break things
2018-03-11 18:20:19 <terra> ok
2018-03-11 18:56:48 <_ikke_> nmeum: I've updated the PR
2018-03-11 19:16:03 <nmeum> _ikke_: noticed one more thing regarding the fish completion subpackage, I added a comment to the PR
2018-03-11 19:21:40 <_ikke_> alright, makes sense :P
2018-03-11 20:49:45 <neirac> I was trying to create a custom iso but found this error (custom iso is the extended one provided in the git repo) modloop.grsec/tmp/usr/share/kernel/grsec/kernel.release': No such file or directory
2018-03-11 20:55:41 <neirac> just fix it, used hardened on kernel flavour
2018-03-11 22:05:44 <jirutka> neirac: have you tried https://github.com/alpinelinux/alpine-make-vm-image ?
2018-03-11 23:12:31 <joe___> Hey QQ regarding signing packages, I do  abuild-sign /path/to/my.apk -k /path/to/mykey.rsa - but then apk add /path/to/my.apk returns: BAD SIGNATURE, what am I doing wrong? :(
2018-03-11 23:21:15 <skarnet> joe___: have you added your public key to /etc/apk/keys ?
2018-03-11 23:21:23 <joe___> yes
2018-03-11 23:21:30 <joe___> was auto added by the abuild keygen
2018-03-12 06:10:07 <dsabogal> ncopa: nmeum: i think mkinitfs needs to be tweaked for the recent busybox upgrade to 1.28.1
2018-03-12 06:10:08 <dsabogal> when upgrading from (standard) 3.7.0 to edge, mkinitfs runs and i see the following:
2018-03-12 06:10:08 <dsabogal> cpio: skipping unsafe symlink to '/bin/busybox' in archive, set EXTRACT_UNSAFE_SYMLINKS=1 to extract
2018-03-12 06:10:08 <dsabogal> after rebooting, linux panics after failing to find init
2018-03-12 06:10:08 <dsabogal> running $(EXTRACT_UNSAFE_SYMLINKS=1 mkinitfs 4.9.73-0-hardened) immediately after the upgrade prevents this
2018-03-12 10:20:32 <nmeum> dsabogal: I didn't get that warning. will look at it asap
2018-03-12 10:55:33 <nmeum> dsabogal: this is caused by the /bin/sh symlink to /bin/busybox
2018-03-12 10:56:05 <nmeum> setting the magic env var seems to be a decent option for fixing this
2018-03-12 10:56:06 <nmeum> http://tpaste.us/ZPne
2018-03-12 11:04:07 <nmeum> it's still interessting that this warning is emitted even though we are creating an archive, not extracting one
2018-03-12 11:38:14 <nmeum> I also have a kind of ugly patch for busybox to work around this problem http://tpaste.us/dV6J
2018-03-12 12:11:25 <neirac> @jirutka the alpine-make-vm-image repo is preferred, to this one https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image ?
2018-03-12 12:16:42 <xentec> neirac: yes, the wiki is mostly outdated and it says right so in the middle of the page: "This material is obsolete ..."
2018-03-12 12:20:36 <clandmeter2> neirac, alpine-iso is eol, we now use aports/scripts/mkimage.sh
2018-03-12 12:28:30 <neirac> I'm trying to add zfs userland tools to a custom iso, I just added zfs to alpine-extended.packages, but when testing zfs is not installed
2018-03-12 12:36:19 <neirac> I'm missing something ? the kernel module loads fine
2018-03-12 12:37:54 <dsabogal> nmeum: thanks. upgrading from 3.7.0 to edge now succeeds without trouble
2018-03-12 13:15:52 <xentec> ncopa, kaniini: now that hardened is going, is paxmark still needed in some APKBUILDs?
2018-03-12 14:24:48 <tmh1999_> Hi, after https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n693, we are now in the new tmpfs sysroot, so that we can log in and run installation script. I wonder is there any way I could run some script after that line, but inside the new sysroot ?
2018-03-12 14:27:07 <tmh199> that command is actually : exec /bin/busybox switch_root /sysroot /sbin/init. while /sbin/init is a symlink to busybox. After that line, busybox start running the system. May be I think I can inject a couple of command in that process ? But I don't know how things work after that. Busybox starts openrc ?
2018-03-12 14:28:28 <jirutka> neirac: it depends… I missed that you need ISO image… do you really need ISO image, not an image for VM (e.g. qcow2, vmdk, …)? if you need ISO image, then alpine-make-vm-image is not for you; but if you need a typical image for VM, then alpine-make-vm-image is designed exactly for that, so it should be easier to use than our scripts for making ISO images
2018-03-12 14:29:24 <jirutka> neirac: moreover, I’m author of that script and use it at work, so I know that it works; I’ve never tried our scripts for making ISO images, so cannot support it
2018-03-12 14:32:09 <tmh199> jirutka, neirac: inside aports/scripts : ./mkimage.sh --arch x86_64 --profile standard --repository http://dl-2.alpinelinux.org/alpine/edge/main should create the ISO image
2018-03-12 14:50:59 <ncopa> tmh1999: hi! We have an issue with the builder for s390x. It hangs in test suite for grep
2018-03-12 14:51:00 <ncopa> main/grep
2018-03-12 14:51:23 <ncopa> it looks like its awk that is hanging
2018-03-12 14:52:17 <_ikke_> ah, still?
2018-03-12 14:52:31 <ncopa> yes
2018-03-12 14:52:45 <ncopa> i killed it now
2018-03-12 14:53:28 <ncopa> ah looks like kaniini disabled test suite
2018-03-12 15:00:11 <xentec> I wish I had some Threadrippers. building LLVM+clang+lld wastes too much time
2018-03-12 15:08:51 <tmh199> ncopa : Oh I thought you disabled it last week...
2018-03-12 15:11:41 <tmh1999> yeah I heard/saw the awk thing last (2) weeks
2018-03-12 15:14:40 <neirac> @jirutka I need an iso :(, I'm using this now to build the iso, it works but I have the same issue as before,  testing the created iso, typing zfs does not found the command it's like the package is never added to the iso
2018-03-12 15:16:21 <tmh1999> neirac : maybe extended profile has zfs
2018-03-12 15:16:49 <neirac> thmh1999 yes, the extended has zfs module, but not zfs userland tools, I added to the packages but it's not working
2018-03-12 15:17:32 <tmh1999> neirac : it has zfs apk package (userland tools), doesn't it ? https://git.alpinelinux.org/cgit/aports/tree/scripts/mkimg.standard.sh#n41
2018-03-12 15:17:57 <neirac> yes, but booting extended I type zfs and get command not found
2018-03-12 15:54:18 <tmh1999> Ah come back to injecting a script after https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n693 so that it could be executed inside the new sysroot. I think I can create an openrc service, and tell busybox/openrc to start the service and run the script. sounds doable.
2018-03-12 15:54:44 <tmh1999> hell yeah
2018-03-12 16:37:01 <neirac> what does it means when a package is flagged ?
2018-03-12 16:37:48 <jirutka> neirac: that it’s outdated… or if flagged by a human, that it _may_ be outdated (or the person just don’t understand what the hell is stable and mainline/unstable version etc)
2018-03-12 16:38:22 <neirac> @jirutka thanks for the explanation
2018-03-12 16:38:39 <jirutka> neirac: most “flags” are currently created based on notification from https://release-monitoring.org/
2018-03-12 16:39:04 <jirutka> neirac: you can see it in the flag message
2018-03-12 16:53:06 <neirac> @jirutka thanks, I was saw it.
2018-03-12 17:10:58 <clandmeter2> neirac, you need to install zfs after booting the iso.
2018-03-12 17:26:43 <neirac> clandmeter2 wny? i thought adding zfs package extended profile in the mkimg.standard.sh should do the trick.
2018-03-12 17:28:34 <neirac> clandmeter2 also that's a problem I think, I want to run from ram that means that pkg is gone after I reboot the machine
2018-03-12 17:30:04 <clandmeter2> Then you need to use an overlay
2018-03-12 17:31:18 <clandmeter2> By default no extra packages are installed. But are available on the iso for you to install manually.
2018-03-12 17:31:36 <neirac> clandmeter2 awesome
2018-03-12 17:31:58 <neirac> clandmeter2 ooh ok, I was going crazy not able to solve this
2018-03-12 17:32:19 <clandmeter2> Do you need to use iso to boot?
2018-03-12 17:32:37 <clandmeter2> Or can you boot from USB?
2018-03-12 17:33:21 <clandmeter2> You need persistence storage to store the ovl file
2018-03-12 17:33:57 <clandmeter2> Or grab it from http like netboot
2018-03-12 17:34:00 <neirac> usb is fine, I plan to install bare metal, but I want to build first a custom that boots the os from ram and has zfs to use the fisk to store containers
2018-03-12 17:35:32 <neirac> clandmeter2 I don't know about overlays, I'll check the wiki
2018-03-12 17:52:36 <clandmeter2> neirac, please do as this is our development channel. for support we have #alpine-linux
2018-03-12 18:02:04 <neirac> clandmeter2 ok thanks for the hints
2018-03-12 22:58:40 <mepholic> https://www.washingtonpost.com/business/technology/trump-blocks-broadcom-takeover-of-qualcomm/2018/03/12/9ff9c724-2647-11e8-a227-fd2b009466bc_story.html?utm_term=.ce32b87d20d8
2018-03-12 23:00:03 <jirutka> huh, he really did something positive? O.O
2018-03-12 23:00:44 <mepholic> looks like it
2018-03-13 03:49:16 <koldbrutality_> there are no opencl drivers for this distro?
2018-03-13 03:49:48 <koldbrutality_> i need someone to test my bitcoin miner package in opencl
2018-03-13 03:50:04 <koldbrutality_> for the gpu
2018-03-13 09:54:41 <ncopa> jirutka: good work with the ocaml stuff!
2018-03-13 12:10:19 <ncopa> do we really want enable kexec? https://github.com/alpinelinux/aports/pull/3584
2018-03-13 12:10:19 <ncopa> im super scared of it
2018-03-13 12:13:40 <skarnet> you shouldn't be scared, you should just say no :P
2018-03-13 12:18:44 <TBB> there are use cases for it, but it might not be a good idea for a default install, whatever the heck that means
2018-03-13 12:42:45 <jirutka> ncopa: kexec? definitely not
2018-03-13 13:24:18 <duncan^> Don't enable it
2018-03-13 14:13:04 <jirutka> ncopa: I wonder, why is ulimit shell’s built-in? I kinda don’t understand how it is related to shell to be built-in
2018-03-13 14:20:35 <skarnet> jirutka: you can't change your parent's state, so if ulimit was an external program, its effects wouldn't impact the shell itself
2018-03-13 14:20:45 <jirutka> skarnet: aha!
2018-03-13 14:20:52 <skarnet> ulimit has to be builtin to change the shell's state
2018-03-13 14:21:25 <skarnet> the alternative is to change your own state and then exec into another process with the state changed, that's exactly what https://skarnet.org/software/s6/s6-softlimit.html does
2018-03-13 15:58:22 <mitchty> is there anything special about the llvm musl armhf targets?
2018-03-13 16:02:00 <mitchty> rather how far off would armv6-alpine-linux be from armv6-unknown-linux-gnueabihf
2018-03-13 16:04:07 <mitchty> didn't see anything of huge note in the patches to llvm, i'm presuming that musl/musleabihf is largely the same as gnu
2018-03-13 16:09:00 <jirutka> mitchty: well, I’m officially maintainer of the llvm packages, but to be honest, I don’t know much about it (I’d be happy to entrust it to someone more competent in area of C compilers); from what I remember there are not any significant modifications for armhf, just common fixes for musl and adjusting for Alpine standards
2018-03-13 16:09:59 <mitchty> jirutka: np, i'm more wondering about things like armv6-alpine-linux supporting/expecting something like neon or hard float
2018-03-13 16:10:17 <mitchty> vs soft float
2018-03-13 16:11:04 <jirutka> mitchty: and that’s the problem, I know only that ”hf” part of armhf is hard-float and that it’s some arm flavour for older processors, but don’t really know what are real effects of this for programs :)
2018-03-13 16:11:25 <jirutka> (and compiler)
2018-03-13 16:11:36 <mitchty> heh, well its more in output from llvm in this case
2018-03-13 16:11:47 <mitchty> aka can't link something compiled with hard float to not
2018-03-13 16:11:57 <mitchty> etc... (arm is a mess)...
2018-03-13 16:12:52 <mitchty> I'll poke around more but figured asking would be worth a shot, now worries
2018-03-13 16:12:59 <mitchty> no even
2018-03-13 16:13:56 <jirutka> maybe Shiz may know more about it
2018-03-13 16:14:39 <Shiz> mitchty: do you mean armv6-alpine-linux-musleabihf?
2018-03-13 16:14:45 <Shiz> (as opposed to armv6-alpine-linux)
2018-03-13 16:17:36 <Shiz> mitchty: they both use the ARM EABI, aapcs-linux variant
2018-03-13 16:17:36 <jirutka> ha, Shiz is here! Shiz, there’s currently some effort to upgrade LLVM to version 6 and as we realized before, it seems that we have to merge separate aports of (some) LLVM components into one aport; could you please coordinate this and maybe take over LLVM maintainership? I’m not the best person for this complex compiler beast
2018-03-13 16:17:56 <Shiz> I think the only difference may be the dynamic linker/libc symbols
2018-03-13 16:18:01 <jirutka> (PR https://github.com/alpinelinux/aports/pull/3583)
2018-03-13 16:19:07 <Shiz> mitchty: I don't think there is much further difference as they both base on EABI aapcs-linux
2018-03-13 16:19:10 <Shiz> jirutka: I'll take a look
2018-03-13 16:19:15 <jirutka> Shiz: thank you!
2018-03-13 16:19:16 <Shiz> I'm not at all a fan of the integrated build though :(
2018-03-13 16:19:25 <xentec> help always appreciated
2018-03-13 16:20:19 <Shiz> I get why it's needed, it's just ugh, saly
2018-03-13 16:20:21 <Shiz> sadly*
2018-03-13 16:21:00 <jirutka> yeah, I’m not very happy from that too
2018-03-13 16:25:18 <Shiz> mitchty: from the LLVM patches that indeed seems to be the case
2018-03-13 16:25:48 <Shiz> dynamic linker and libc symbols are the only thing that differs i think, and even that is questionable if it's part of the abi
2018-03-13 16:33:42 <mitchty> Shiz: cool yep that answers things, the target I was getting from llvm was armv6-alpine-linux so wanted to make sure llvm is being told the right things
2018-03-13 16:34:45 <Shiz> hmm that should also output the abi part, odd
2018-03-13 16:42:32 <mitchty> its not a huge deal
2018-03-13 20:07:46 <mps> does last eudev update means that the udev will be put in sysinit runlevel instead of default
2018-03-14 12:36:40 <mps> ncopa: yesterday I asked does the new eudev update will put udev in sysinit runlevel instead of default
2018-03-14 12:38:07 <mps> I had to move it to sysinit to fix the problem with renaming network interface on boot
2018-03-14 12:54:17 <mps> I'm asking because I thought to fill a bug, but if it solved by last update then there is no need for the filling bug
2018-03-14 13:14:38 <clandmeter2> mps, new eudev?
2018-03-14 13:15:41 <mps> clandmeter2: yes, new update
2018-03-14 13:16:07 <clandmeter2> reference?
2018-03-14 13:16:11 <mps> I cannot install it to check if the problem fixed
2018-03-14 13:16:58 <mps> https://git.alpinelinux.org/cgit/aports/commit/?id=f32eca54071c2e63fea83032797da0e8b5a3dfa5
2018-03-14 13:17:36 <clandmeter2> thats still the same version. just small fix.
2018-03-14 13:17:39 <mps> "we should start the udev-postmount in default runlevel. It depends on localmount."
2018-03-14 13:18:06 <clandmeter2> so? udev still is in sysinit like it was, just not postmount
2018-03-14 13:18:30 <mps> yes, the version is same but I don't understand what that commit message means
2018-03-14 13:19:01 <mps> no, on my systems udev is in the default runlevel
2018-03-14 13:19:31 <clandmeter2> according to the setup-udev  script it should be in sysinit.
2018-03-14 13:20:27 <mps> huh, not on my machines, AL 3.7
2018-03-14 13:20:57 <mps> I had to remove it from default and add to sysinit manually
2018-03-14 13:21:01 <clandmeter2> how did it get added to runlevel?
2018-03-14 13:21:18 <mps> ah, yes
2018-03-14 13:21:21 <clandmeter2> did you add it yourself?
2018-03-14 13:21:45 <mps> just remember that I added it manually after install
2018-03-14 13:21:53 <mps> you are right
2018-03-14 13:21:54 <clandmeter2> there you go
2018-03-14 13:22:03 <clandmeter2> pebkac
2018-03-14 13:22:17 <mps> sorry for noise
2018-03-14 13:22:22 <clandmeter2> np :)
2018-03-14 13:22:41 <clandmeter2> and please use alpine-linux for support.
2018-03-14 13:23:27 <mps> of course, but I thought this subject was better for alpine-devel
2018-03-14 13:24:03 <clandmeter2> it does?
2018-03-14 13:24:39 <mps> well, after your explanation I'm not sure
2018-03-14 13:31:09 <terra> Anyone knows why PTHREAD_MUTEX_ADAPTIVE_NP is missing musl pthread.h ?
2018-03-14 13:31:18 <terra> *in
2018-03-14 13:31:59 <_ikke_> dalias would probably know, but he's only in #alpine-linux
2018-03-14 13:32:15 <clandmeter2> i guess thats also better asked in #musl
2018-03-14 13:32:42 <terra> clandmeter2: yes of course
2018-03-14 18:01:05 <sleewoo> hey, would nodejs 8.10 landing in 3.7 any time soon?
2018-03-14 18:01:26 <sleewoo> do not want use edge branch
2018-03-14 18:05:10 <sleewoo> seems Tim already committed it to master
2018-03-14 18:05:37 <sleewoo> any chance it will be committed to 3.7 soon?
2018-03-14 18:05:51 <sleewoo> thanks
2018-03-14 18:06:36 <_ikke_> anything in edge will be part of the next release
2018-03-14 18:06:53 <_ikke_> sleewoo: 3.7 would only get minor updates
2018-03-14 18:07:06 <_ikke_> not sure how 'big' the 8.10 upgrade is
2018-03-14 18:11:13 <sleewoo> _ikke_: got it, thanks
2018-03-14 18:11:29 <sleewoo> does not seem to be that "big"
2018-03-14 18:11:34 <sleewoo> same few lines diff as last commits like docker, django, ruby-bundler etc.
2018-03-14 18:13:56 <jirutka> main/nodejs is LTS, so yes, it should be backported
2018-03-14 18:15:28 <jirutka> I was looking into git log whom should i blame for not backporting it… and… apparently someone put my name into his commit! XD :(
2018-03-14 18:16:49 <_ikke_> :D
2018-03-14 18:16:51 <_ikke_> :P
2018-03-14 18:17:06 <jirutka> and 3.6-stable is also quite behind
2018-03-14 18:17:36 <jirutka> uhm :( sleewoo: I’m sorry about that, I’ve pushed upgrade to 3.7 few moments ago
2018-03-14 18:18:10 <sleewoo> jirutka: great! thanks
2018-03-14 19:49:56 <fcolista> what's happening to dl-cdn.alpinelinux.org ?
2018-03-14 19:50:10 <_ikke_> fcolista: care to elaborate?
2018-03-14 19:50:19 <danieli> is something happening to it?
2018-03-14 19:50:23 <fcolista> apk update is stuked
2018-03-14 19:50:31 <fcolista> no
2018-03-14 19:50:31 <danieli> stuck?
2018-03-14 19:50:34 <fcolista> it was a glitch
2018-03-14 19:50:37 <danieli> hmm
2018-03-14 19:51:23 <fcolista> nm
2018-03-14 19:51:42 <danieli> fastly had an incidence but only regarding new stuff and domain changes
2018-03-14 19:51:45 <danieli> incident*
2018-03-14 19:51:52 <danieli> my brain isn't braining right now
2018-03-14 19:52:21 <fcolista> it's slow
2018-03-14 19:53:21 <fcolista> umh..
2018-03-14 19:53:52 <fcolista> 50KB/sec in the average
2018-03-14 19:53:55 <fcolista> 2ua4020qdl:~$ wget  http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
2018-03-14 19:53:55 <fcolista> --2018-03-14 20:53:22--  http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
2018-03-14 19:53:55 <fcolista> Resolving dl-cdn.alpinelinux.org... 151.101.0.249, 151.101.64.249, 151.101.128.249, ...
2018-03-14 19:53:55 <fcolista> Connecting to dl-cdn.alpinelinux.org|151.101.0.249|:80... connected.
2018-03-14 19:53:59 <fcolista> HTTP request sent, awaiting response... 200 OK
2018-03-14 19:53:59 <danieli> jeez
2018-03-14 19:54:01 <fcolista> Length: 783458 (765K) [application/octet-stream]
2018-03-14 19:54:03 <fcolista> Saving to: 'APKINDEX.tar.gz.1'
2018-03-14 19:54:05 <fcolista> APKINDEX.tar.gz.1            100%[==============================================>] 765.10K  50.3KB/s    in 13s
2018-03-14 19:54:06 <danieli> uh.. mind pastebinning that?
2018-03-14 19:54:13 <fcolista> danieli, you are right
2018-03-14 19:54:13 <fcolista> sorry
2018-03-14 19:54:21 <danieli> freenode might kick you because of the recvq
2018-03-14 19:54:23 <danieli> :P
2018-03-14 19:54:43 <_ikke_> fcolista: the index is downloaded in an instant
2018-03-14 19:54:47 <fcolista> https://dpaste.de/ET4n
2018-03-14 19:55:05 <fcolista> _ikke_, i have different results
2018-03-14 19:55:07 <_ikke_> fcolista: It's not your network connection?
2018-03-14 19:55:12 <fcolista> no..
2018-03-14 19:55:36 <danieli> i like how the server says "Server: Cowboy\r\nX-Powered-By: Express"
2018-03-14 19:55:41 <danieli> erlang and nodejs
2018-03-14 19:55:58 <_ikke_> I reach the same IP as you, but no issues here
2018-03-14 19:56:10 <danieli> fcolista: try mtr to that IP?
2018-03-14 19:56:19 <danieli> it might be some peer in between having issues
2018-03-14 19:56:26 <_ikke_> http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
2018-03-14 19:56:26 <fcolista> https://dpaste.de/47Sn
2018-03-14 19:56:35 <_ikke_> http://tpaste.us/m5ox
2018-03-14 19:56:56 <danieli> different network peers for different paths to the endpoints
2018-03-14 19:57:03 <_ikke_> http://tpaste.us/Rj9b
2018-03-14 19:57:08 <danieli> speedtest always tests to a server close to you unless it's configured not to
2018-03-14 19:57:08 <fcolista> danieli, exactly
2018-03-14 19:57:31 <fcolista> danieli, jsut saying that is not my network connection
2018-03-14 19:57:33 <danieli> fastly's network is in CA, some network peer between you and them might be having some issues
2018-03-14 19:57:38 <fcolista> there's an issue withing the path
2018-03-14 19:57:40 <fcolista> right
2018-03-14 19:57:43 <danieli> mtr saying anything?
2018-03-14 19:57:46 <fcolista> https://dpaste.de/kEjc
2018-03-14 19:57:46 <_ikke_> yea
2018-03-14 19:57:55 <danieli> god that's slow
2018-03-14 19:57:59 <_ikke_> 
ACTION prefers raw links

2018-03-14 19:58:20 <danieli> raw link?
2018-03-14 19:58:20 <_ikke_> fcolista: indeed, can you try an mtr to that IP?
2018-03-14 19:58:25 <_ikke_> https://dpaste.de/kEjc/raw
2018-03-14 19:58:53 <fcolista> _ikke_, sure
2018-03-14 19:59:00 <danieli> one time I saw 20 jumps inside a single peer's network, would think it flipped over to OSPF and went haywire
2018-03-14 19:59:23 <danieli> back and forth between routers in the same subnet
2018-03-14 19:59:44 <_ikke_> routing loop
2018-03-14 19:59:50 <danieli> one deeper
2018-03-14 20:00:03 <danieli> but yeah, it was a loop of sorts
2018-03-14 20:00:11 <danieli> luckily i have redundant uplinks
2018-03-14 20:00:17 <danieli> different upstreams too
2018-03-14 20:00:18 <fcolista> trying 151.101.0.249
2018-03-14 20:00:30 <_ikke_> mtr -r -c 20 151.101.0.249
2018-03-14 20:00:34 <danieli> whichever works, their edge is probably in the same network
2018-03-14 20:00:42 <danieli> mtr -t ftw
2018-03-14 20:00:56 <danieli> then "d" twice
2018-03-14 20:00:57 <_ikke_> yea, but that's not easy to share
2018-03-14 20:01:17 <danieli> I've been on windows for a couple months, lightshot is nice
2018-03-14 20:01:31 <fcolista> https://dpaste.de/zPZ6
2018-03-14 20:01:51 <fcolista> packet loss in point 8
2018-03-14 20:02:03 <fcolista> s/point/host
2018-03-14 20:02:27 <danieli> yes, ae-8.r04.frnkge08.de.bb.gin.ntt.net
2018-03-14 20:02:51 <_ikke_> that doesn't say anything
2018-03-14 20:02:55 <_ikke_> the packet loss is not consistent
2018-03-14 20:03:00 <danieli> mm
2018-03-14 20:03:02 <fcolista> _ikke_, right
2018-03-14 20:03:07 <fcolista> is not consistent
2018-03-14 20:03:27 <fcolista> sawing packet loss to 151.101.0.249 too
2018-03-14 20:03:39 <fcolista> around 10%
2018-03-14 20:03:41 <_ikke_> The high latency is more telling
2018-03-14 20:05:16 <_ikke_> my latency is <10 ms
2018-03-14 20:05:42 <_ikke_> So I seem to hit a local node, while fcolista is router overseas
2018-03-14 20:05:56 <fcolista> I'm around 130ms
2018-03-14 20:06:00 <_ikke_> that's high
2018-03-14 20:06:03 <fcolista> it is
2018-03-14 20:06:30 <_ikke_> 64 bytes from 151.101.0.249: icmp_seq=4 ttl=60 time=9.51 ms
2018-03-14 20:06:38 <fcolista> https://dpaste.de/fVr4
2018-03-14 20:07:00 <fcolista> ping 151.101.0.249
2018-03-14 20:07:00 <fcolista> PING 151.101.0.249 (151.101.0.249) 56(84) bytes of data.
2018-03-14 20:07:00 <fcolista> 64 bytes from 151.101.0.249: icmp_seq=1 ttl=56 time=134 ms
2018-03-14 20:07:00 <fcolista> 64 bytes from 151.101.0.249: icmp_seq=2 ttl=56 time=131 ms
2018-03-14 20:07:16 <fcolista> problem is with ntt As
2018-03-14 20:07:23 <fcolista> AS2914
2018-03-14 20:07:40 <fcolista> high latency toward ntt
2018-03-14 20:09:48 <_ikke_> If I ping those IPs, I get about 30ms of latency
2018-03-14 20:09:58 <_ikke_> Problem is, you never see the return path
2018-03-14 20:10:05 <fcolista> cannot check it
2018-03-14 20:10:23 <fcolista> maybe I can find some router allowing telnet connection
2018-03-14 20:19:57 <_ikke_> fcolista: not sure if related, but apparently there are more issues on the internet
2018-03-14 20:20:05 <_ikke_> ie, netflix is having issues as well
2018-03-14 20:49:16 <clandmeter> yes the internet is oflfline
2018-03-14 20:49:28 <clandmeter> probably amazon issues?
2018-03-14 20:50:18 <clandmeter> i know some of the web-services i am using were not responding.
2018-03-14 21:08:11 <[[sroracle]]> Level3 had an outage yesterday, might be related to that
2018-03-14 22:34:19 <terra> Guys, I've build a PaleMoon package for Alpine. It runs just fine but when I try to install it via "apk add" I got this: https://paste.ee/p/TTmuq
2018-03-14 22:37:26 <clandmeter> apk del firefox-esr?
2018-03-14 22:38:14 <terra> but why? nothing there to be in conflict
2018-03-14 22:39:04 <terra> is this where "paxmark" get into business?
2018-03-14 22:40:25 <terra> apk thinks I'm trying to install same libs because contains same symbols due to the bundled ones.
2018-03-14 22:41:29 <clandmeter> paxmark has nothing to do with it.
2018-03-14 22:42:14 <clandmeter> we usually dont ship apps with bundled libs
2018-03-14 22:43:31 <terra> binaries installed at /usr/lib/palemoon-27.8.1
2018-03-14 22:43:45 <terra> should go somewhere else?
2018-03-14 22:47:36 <terra> if I remove bundled ones.. it still woes for firefox's own libxul.so. This is unusual.
2018-03-14 22:52:35 <opendata> Terra you might need to remove branding
2018-03-14 22:53:14 <opendata> Remember the palemoon guy want crazy about a someone packaging palemoon with system libs
2018-03-14 22:55:54 <terra> opendata: I can run it without any problem on same folder.
2018-03-14 23:00:12 <terra> library linking is intact. other apps doesn't link against bundled ones. I'm not only packager who comply branding.
2018-03-14 23:08:17 <terra> This can be apk/abuild bug.
2018-03-14 23:08:27 <terra> @ncopa ?
2018-03-14 23:10:00 <danieli> terra: not sure it'll highlight/mention him if you prepend "@" to the username
2018-03-14 23:10:53 <terra> ncopa ?
2018-03-14 23:11:40 <terra> @danieli <-- how does this look?
2018-03-14 23:11:53 <danieli> it highlighted me, guess it depends on the client
2018-03-14 23:12:05 <danieli> a "@" prepended to usernames means channel operator on irc
2018-03-14 23:12:32 <terra> yup!
2018-03-14 23:17:32 <clandmeter> what happens if you set ldpath=/usr/lib/palemoon-27.8.1 in apkbuild?
2018-03-14 23:22:58 <terra> clandmeter: https://paste.ee/p/f0k7h
2018-03-14 23:31:05 <terra> clandmeter: There is nothing about ldpath directive at APKBUILD reference doc.
2018-03-15 05:57:41 <I3N84DNightMonke> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
2018-03-15 05:57:41 <I3N84DNightMonke> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
2018-03-15 05:57:41 <I3N84DNightMonke> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
2018-03-15 05:57:41 <I3N84DNightMonke> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
2018-03-15 05:57:45 <I3N84DNightMonke> I 3 N 8 4 D N i g h t M o n k e   s l e e w o o   c z a r t   i d 4 r k   m a x i c e 8   L o c h n a i r   B i t L 0 G 1 c 2   f e k e p p   n e i r a c   c l a n d m e t e r 1   f a b l e d   b e r n h a r d g r u e n   k o l d b r u t a l i t y   b l e b   b l a h d o d o   b l u e n e s s   s t a t e l e s s   s k a r n e t   T s u t s u k a k u s h i   m a r b l e _ v i s i o n s   d a n i e l i   i c e 7 9 9   x e n t e c   
2018-03-15 06:00:44 <sleewoo> Jirutka, nodejs builds on edge and not on 3.7 cause libuv updated to 1.19 in edge
2018-03-15 06:00:56 <sleewoo> it is 1.17 in 3.7
2018-03-15 06:56:22 <kaniini> terra: be aware that palemoon will never be accepted into alpine
2018-03-15 06:58:00 <kaniini> terra: as such, you might want to look at $somask, which will probably solve your problem.  but again, we will never accept palemoon into alpine, so you will need to distribute the packages yourself (or just the APKBUILD)
2018-03-15 07:01:25 <kaniini> note that $somask is undocumented as using it is not really something that happens in normal alpine packages
2018-03-15 07:18:10 <fcolista> kaniini, any plan to upgrade gnome to 3.28?
2018-03-15 09:23:48 <fcolista> in which scenarios we want gobject-introspection and when not?
2018-03-15 10:21:52 <fcolista> going to push mate 1.20
2018-03-15 12:39:07 <PureTryOut[m]1> what was the end result of the discussion about replacing LibreSSL back to OpenSSL? are we still going through with that?
2018-03-15 12:43:50 <clandmeter> Possibly after 3.8
2018-03-15 12:51:12 <PureTryOut[m]1> after 3.8? damn, ok
2018-03-15 13:53:25 <jirutka> "sleewoo:	Jirutka, nodejs builds on edge and not on 3.7 cause libuv updated to 1.19 in edge" … what to do about this? I guess we cannot (shouldn’t) update libuv in stable branch…?
2018-03-15 15:55:19 <kaniini> fcolista: i don't have any plans to upgrade gnome, which is why it hasn't left testing.  we decided to go with KDE as the "main" desktop of adelie for now
2018-03-15 15:56:42 <jirutka> IMO Gnome is quite dead with its tight integration with systemd, isn’t it?
2018-03-15 15:56:51 <jirutka> I’m gonna use Xfce4 on Alpine
2018-03-15 15:59:00 <fcolista> jirutka, kaniinin did gnome3 without systemd support
2018-03-15 15:59:08 <jirutka> oh, really?
2018-03-15 15:59:11 <fcolista> yes
2018-03-15 15:59:14 <fcolista> and, kaniini :
2018-03-15 15:59:15 <jirutka> that’s hreat!
2018-03-15 15:59:17 <jirutka> great
2018-03-15 15:59:22 <fcolista> gnome-desktop is in community
2018-03-15 15:59:24 <fcolista> not in testing
2018-03-15 15:59:49 <jirutka> kaniini: how much patching did it require?
2018-03-15 16:04:14 <kaniini> not that much
2018-03-15 16:04:40 <kaniini> fcolista: if GNOME were moved to community, it was without my consent.  there's a lot of bugs with it still
2018-03-15 16:04:47 <kaniini> whoever moved it can maintain it =)
2018-03-15 16:05:15 <fcolista> kaniini, ahem...
2018-03-15 16:05:16 <fcolista> commit 40045db63d190ec8895ab18019485d31aa740112
2018-03-15 16:05:16 <fcolista> Author: William Pitcock <nenolod@dereferenced.org>
2018-03-15 16:05:16 <fcolista> Date:   Mon Jun 5 19:26:27 2017 +0000
2018-03-15 16:05:16 <fcolista>          
2018-03-15 16:05:16 <fcolista>     community/gnome-desktop: move from testing
2018-03-15 16:06:10 <kaniini> that's just one component though
2018-03-15 16:06:24 <kaniini> you need testing to get real GNOME3
2018-03-15 16:07:01 <fcolista> so it should be moved on testing
2018-03-15 16:07:12 <fcolista> no reason why it should be on community
2018-03-15 16:07:59 <jirutka> kaniini: I totally agree with “whoever moved it can maintain it =)” … and since, by some coincidance, you’re the one who moved it… :)
2018-03-15 16:08:07 <jirutka> :P
2018-03-15 16:08:26 <fcolista> ehehe
2018-03-15 16:08:37 <fcolista> gotta go
2018-03-15 16:08:40 <fcolista> cu
2018-03-15 16:09:04 <fcolista> (btw: since it was in community, that's why I've asked if/when you plan to upgrade to 3.28)
2018-03-15 16:11:14 <kaniini> fcolista: i don't have objection to upgrading it, but i don't have time to do it right now.  if it gets done, it will be after 3.8 release.
2018-03-15 22:03:02 <ollieparanoid[m]> jirutka: I know you're busy, but if you have time it would be nice if you (or someone else with commit rights) could take a look at the abuild PRs I've made (especially the -f and git error ones): https://github.com/alpinelinux/abuild/pulls
2018-03-15 22:03:40 <jirutka> ollieparanoid[m]: yes, sry, I‘ll look at it right now
2018-03-15 22:04:30 <ollieparanoid[m]> thanks!
2018-03-16 00:36:24 <louiz> When a package is marked as “flagged”, does that mean that someone signaled that it’s deprecated and it should be updated? If so, how can we see “how soon” will the package be updated?
2018-03-16 00:36:33 <louiz> Here, I’m talking about gcc 7
2018-03-16 00:36:39 <jirutka> louiz: not deprecated, but outdated
2018-03-16 00:36:44 <louiz> yes, outdated
2018-03-16 00:37:44 <jirutka> you can’t see how soon will be the package be updated, because of some problem with impossibility to travel in time…
2018-03-16 00:40:03 <louiz> yeah, I was more thinking about a bug tracker where the packaging of the new version could be discussed
2018-03-16 00:41:32 <jirutka> upgrades of most of the packages are not discussed in advance, only problematic ones, such as gcc or llvm…
2018-03-16 00:42:14 <jirutka> I don’t know what is the current state of gcc. We were limited by grsecurity, but this does not apply anymore, so we probably can upgrade to the latest version…?
2018-03-16 00:43:30 <louiz> that’d be great :P I was just checking here, to see if something was blocking it completely, just a lack of time/contributors or something else
2018-03-16 07:21:28 <ncopa> louiz: lack of time is the major issue
2018-03-16 07:21:33 <ncopa> we have a plan for gcc upgrade
2018-03-16 07:21:50 <ncopa> basically, we need a gcc6 package which includes gcc-java
2018-03-16 07:22:29 <ncopa> so we can bootstrap openjdk
2018-03-16 07:22:32 <ncopa> after that we can upgrade gcc
2018-03-16 09:33:38 <clandmeter> nodejs is broken in stable?
2018-03-16 09:37:23 <_ikke_> "sleewoo: Jirutka, nodejs builds on edge and not on 3.7 cause libuv updated to 1.19 in edge"
2018-03-16 09:43:53 <clandmeter> nodejs doesnt seem to work for me on stable with grsec kernel.
2018-03-16 10:11:21 <clandmeter> hmm, seems to only segfault on specific lxc host.
2018-03-16 14:00:24 <jirutka> clandmeter: I don’t know what to do with nodejs on 3.7, I guess we cannot (shouldn’t) update libuv in stable branch…?
2018-03-16 14:00:51 <jirutka> clandmeter: so maybe try to extract just fix of security bugs from newer patch-level version?
2018-03-16 14:01:57 <clandmeter> jirutka, idk, i just bumped into some weird error which seems unrelated to the libuv issue.
2018-03-16 16:12:30 <tmh1999_> say, I have added a feature in /etc/mkinitfs/mkinitfs.conf, update the initramfs, but when booting that feature is still not present (not available in modules.dep).
2018-03-17 21:37:32 <koldbrutality> anyone know how to fix? https://travis-ci.org/alpinelinux/aports/builds/354840272?utm_source=github_status&utm_medium=notification
2018-03-17 21:38:10 <koldbrutality> pull request: https://github.com/alpinelinux/aports/pull/3668
2018-03-17 21:44:49 <koldbrutality> it's a bad error message... i forgot to upload a patch file
2018-03-17 21:52:44 <koldbrutality> still same missing dependency message
2018-03-17 21:57:55 <_ikke_> right, I would not expect a missing patch leading to a dependency issue
2018-03-18 16:51:14 <ricardson> hi all
2018-03-18 16:52:00 <ricardson> looks like pdns-recursor have a security issue -> https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2017-08.html
2018-03-18 19:12:30 <bergers89> hi - asked same question on #alpine-linux but may be more appropriate for -devel: is there a way to see how many syscalls have been exectued on the system (i was looking into /proc/interrupts but i am mostly seeing device interrupts).
2018-03-18 19:23:18 <craftyguy> is libasan packaged in Alpine?
2018-03-18 19:24:07 <craftyguy> I'm not seeing it in the package contents search.. which seems surprising that it would not be there
2018-03-18 19:25:05 <craftyguy> but maybe it's a glibc thing? *shrug*
2018-03-18 19:27:39 <duncan^> craftyguy: Yes, those are a glibc thing.
2018-03-18 19:28:17 <craftyguy> duncan^: thanks for confirming :)
2018-03-18 21:03:46 <_ikke_> Anyone care to look over https://github.com/ncopa/mqtt-exec/pull/5 to check for obvious mistakes / improvements? I don't have a lot of c experience.
2018-03-18 21:26:48 <skarnet> I can't focus tonight, but gonna read it superficially when I can
2018-03-18 21:28:25 <skarnet> and I've already spotted a bug: on lines 162, 173 and 183, lines should be freed before returning, else it leaks
2018-03-18 21:29:48 <_ikke_> Right, but in that case it's going to exit anyway..
2018-03-18 21:30:20 <skarnet> but the function doesn't know that, and I don't know that when reading the function.
2018-03-18 21:30:31 <skarnet> If it was in main, ok. If it's in a function, the function's contract is broken.
2018-03-18 21:30:53 <_ikke_> right
2018-03-18 21:32:27 <Shiz> you've got a memleak in that realloc() too
2018-03-18 21:32:54 <Shiz> 216 has no null rturn check
2018-03-18 21:33:01 <Shiz> nor does 228
2018-03-18 21:34:15 <Shiz> the second memset on 326 isn't needed
2018-03-18 21:35:28 <_ikke_> for ud you mean?
2018-03-18 21:36:41 <skarnet> oh, it's a config file parser. It could be seriously improved by having a proper lexer/parser structure, and maybe malloc wouldn't even be needed.
2018-03-18 21:36:53 <skarnet> ncopa, you should know how to write those by now ;)
2018-03-18 22:48:24 <sh4rm4^bnc> kaniini, ncopa : when was alpine linux born ?
2018-03-18 22:56:22 <ollieparanoid[m]> here I think: http://git.net/ml/linux.leaf.devel/2005-08/msg00039.html
2018-03-18 23:03:52 <danieli> ollieparanoid[m]: gg, "Error 522" "Connection timed out"
2018-03-18 23:04:03 <danieli> backend server of git.net isn't healthy
2018-03-18 23:13:03 <Shiz> _ikke_: yes
2018-03-18 23:18:06 <ollieparanoid[m]> right, but that's the first announcement :p so it's from 2005-08
2018-03-19 00:36:15 <kaniini> the original alpine in 2005 yes
2018-03-19 00:36:20 <kaniini> alpine as we know it today was 2009-2010 era
2018-03-19 00:55:02 <sh4rm4^bnc> what's the difference between the 2005 original alpine vs the 2009 one ?
2018-03-19 01:00:39 <kaniini> original alpine was gentoo based
2018-03-19 01:00:46 <kaniini> shell scripts for package management etc
2018-03-19 10:46:30 <ncopa> yes, alpine was "born" around 2005-08
2018-03-19 10:46:52 <ncopa> _ikke_: i wonder if we should have the config file parser in separate PR
2018-03-19 11:26:05 <_ikke_> ncopa: sure, I just updated the branch, and realized later that that would also update the PR
2018-03-19 11:33:40 <_ikke_> ncopa: Ah, you already merged the first commit, right
2018-03-19 11:55:39 <_ikke_> ncopa: created a separate pull request
2018-03-19 13:44:55 <Trunet2> hello, Are you aware of the varnish 503 on the pkgs cdn?
2018-03-19 13:45:01 <Trunet2> <p>Details: cache-ams4145-AMS 1521466915 165672672</p>
2018-03-19 13:50:29 <ncopa> hum
2018-03-19 13:51:50 <Trunet2> on #alpine-linux some people are complaining, it was fine 30 minutes ago
2018-03-19 13:53:06 <Trunet2> looks ok now
2018-03-19 13:55:05 <ncopa> i think the backend had issues
2018-03-19 13:56:11 <Trunet2> I think so, well, it's fixed, thanks
2018-03-19 14:24:58 <errm> hi http://dl-cdn.alpinelinux.org seems to be down
2018-03-19 17:04:32 <mksully221> I took a look at the ppc64le testing/hylafaxplus build failure. Strangely I can't reproduce the failure on my Power8 setup building in fresh docker container,  lxc container, or qemu guest...Any suggestions on what might be different  using these configs compared to the official builder that I might try?
2018-03-19 17:32:06 <craftyguy> would the musl-dbg package in alpine help with resolving these symbols: https://hastebin.com/hizakejine.pas
2018-03-19 17:33:23 <craftyguy> I'm trying to debug an application that only blows up on alpine/musl (probably specific to musl though), and this is pretty much a dead end since literally anything could be calling free()
2018-03-19 17:36:35 <craftyguy> yay, looks like it does
2018-03-20 00:22:52 <tmh1999> guys, when you install Alpine in a remote server, which steps do you need to run after running setup-alpine to make sshd enabled by default and allow root user to be ssh-able. Chroot into the installed disk and enable ?
2018-03-20 00:40:48 <duncan^> tmh1999: This configuration is in sshd_config on the system in question. Add sshd to the default runlevel. But beware it is a really terrible idea to enable root login with passwords. If you do do it, enable SSH key login only.
2018-03-20 00:41:48 <tmh1999> duncan^: I understand I need to sshd to default, but how do you do that ? chroot into the newly installed system (on disk) to enable it ?
2018-03-20 00:43:13 <clandmeter> setup-alpine should have enabled sshd already.
2018-03-20 00:44:40 <tmh1999> clandmeter: right. It's enabled I just checked. But the remaining part of the question, which user (root?) you enable to be ssh-able ?
2018-03-20 00:45:40 <clandmeter> depends on your setup, add a user or use root.
2018-03-20 00:46:14 <duncan^> tmh1999: (assuming you aren't using dropbear) OpenSSH's  default *safe* configuration is not to allow root logins at all
2018-03-20 00:46:20 <duncan^> [over ssh]
2018-03-20 00:46:53 <tmh1999> clandmeter, duncan^: you chroot into the new installed disk to add user ?
2018-03-20 00:46:57 <clandmeter> default should allow key login for root
2018-03-20 00:47:47 <clandmeter> tmh1999, you could add your key to root authorized_keys
2018-03-20 00:48:07 <clandmeter> ssh as root and do the rest of your config.
2018-03-20 00:48:41 <tmh1999> clandmeter: but, how :| still need to chroot (at the end of running setup-alpine) in order to add my key to root authorized_keys, right ?
2018-03-20 00:49:14 <duncan^> Given you keep asking that, have you at least tried that method?
2018-03-20 00:49:25 <duncan^> It is one way to change the files on the target's filesystem yes
2018-03-20 00:49:32 <tmh1999> I did. But it looks ghetto...
2018-03-20 00:49:35 <clandmeter> why do you need to chroot to add a key?
2018-03-20 00:50:20 <tmh1999> clandmeter: Right. Just mount /dev/sda1 /mnt and echo the key in
2018-03-20 00:50:26 <tmh1999> no chroot my bad
2018-03-20 00:50:54 <tmh1999> okay if that's the way it should be. I just want to make sure I am not doing something ghetto.
2018-03-20 00:51:32 <tmh1999> clandmeter, duncan^ : thanks for confirmation
2018-03-20 00:51:40 <clandmeter> tmh1999, you cannot access the console after it has booted?
2018-03-20 00:52:27 <tmh1999> clandmeter: assuming no ? It's a remote server. No admin panel or anything
2018-03-20 00:54:46 <clandmeter> ok, then just mount it add add it and hope it works :)
2018-03-20 00:55:13 <clandmeter> and*
2018-03-20 00:56:22 <tmh1999> clandmeter: Yeah. My assumption about chroot is that, I thought sshd is not enabled on default runlevel by default. Since it is, then mount is enough. Thanks !
2018-03-20 08:02:33 <ncopa> I wonder if it would make sense to add support for ssh key to setup-alpine
2018-03-20 09:49:04 <tmh1999> pretty hard, like, "Do you want to add your ssh key to newly installed Aline?" . Yes. "How do you want to add public key?". Maybe I type it in ? Or fetch from remote ?
2018-03-20 09:49:22 <tmh1999> fetch from remote may make sense :D
2018-03-20 10:37:55 <_ikke_> Seems like rsyslog in edge got changed without bumping pkgrel, causing problems with dl-cdn
2018-03-20 11:03:05 <nmeum> _ikke_: what kind of problem?
2018-03-20 11:03:07 <nmeum> *problems
2018-03-20 12:18:39 <grharry> Hello there!  xen-pciback won't work  "APPEND /boot/xen.gz dom0_mem=8192M  --- /boot/vmlinuz-hardened xen-pciback.hide=(06:00.1)(06:00.0) alpine_dev=UUID=5A86-DF47:vfat modules=loop,squashfs,sd-mod,usb-storage quiet nomodeset --- /boot/initramfs-hardened"
2018-03-20 12:18:57 <grharry> What am I doing wrong!
2018-03-20 12:39:06 <_ikke_> nmeum: user reporting bad signature
2018-03-20 12:39:32 <_ikke_> nmeum: micw │ i get this with edge: ERROR: rsyslog-8.31.0-r0: BAD signature -- something broken there?
2018-03-20 12:45:45 <clandmeter> _ikke_, fixed
2018-03-20 12:46:27 <_ikke_> clandmeter: thx
2018-03-20 13:45:45 <jirutka> is Sören Tempel here?
2018-03-20 13:57:00 <skarnet> nmeum: ^
2018-03-20 13:57:29 <nmeum> jirutka: what's wrong?
2018-03-20 13:57:46 <jirutka> nmeum: aha, that’s you!
2018-03-20 13:57:57 <jirutka> nmeum: https://github.com/alpinelinux/aports#git-hooks
2018-03-20 13:58:19 <jirutka> nmeum: good to avoid manual copy-pasting pkgname to git commit log and typos ;)
2018-03-20 13:58:43 <jirutka> nmeum: prepare-commit-msg hook fills it for you
2018-03-20 13:59:57 <nmeum> ah, sounds neat. knew about them for a while but never bothered enabling them
2018-03-20 14:00:33 <nmeum> [x] enabled
2018-03-20 14:00:58 <nmeum> thanks for the hint
2018-03-20 14:01:39 <jirutka> nmeum: you’re welcome!
2018-03-20 14:02:14 <jirutka> nmeum: it do more than that, it also checks that you didn’t forgot to add some patch to the commit etc.
2018-03-20 14:02:40 <nmeum> sweet!
2018-03-20 14:03:12 <_ikke_> jirutka: Would it be an idea to somehow check that the pkgver/pkgrel is increased as well?
2018-03-20 14:03:31 <jirutka> _ikke_: no, because you don’t have to always bump pkgver/pkgrel
2018-03-20 14:04:48 <nmeum> jirutka: while you are here: do you still have any comments regarding https://github.com/alpinelinux/abuild/pull/32 ?
2018-03-20 14:05:02 <jirutka> _ikke_: for example when I have a series of commits modifying single APKBUILD, pkgrel should be bumped once per the series
2018-03-20 14:05:04 <nmeum> I looked over it briefly and I would just merge it as is unless you have anything that still needs to be changed
2018-03-20 14:05:20 <_ikke_> jirutka: yeah, understood
2018-03-20 14:07:47 <jirutka> nmeum: I’d just prefer to use `||` instead of `&&` where possible, it’s more safe, but as I found, POSIX defines behaviour of `set -e` in regard to short tests (e.g. `command1 && command2`), so it’s more a subjective thing than objective
2018-03-20 14:09:35 <nmeum> besides we already use `&&` all over the place in abuild so I don't think that should stop the pr from getting merged
2018-03-20 14:10:22 <jirutka> nmeum: yeah
2018-03-20 14:10:50 <nmeum> ok
2018-03-20 14:10:52 <nmeum> merged
2018-03-20 14:10:53 <nmeum> :p
2018-03-20 14:11:01 <jirutka> thanks
2018-03-20 16:28:37 <terra> Guys, how will COPYING text will tell that it is LGPL-2.0-only or LGPL-2.0-or-later ?
2018-03-20 16:39:42 <jirutka> terra: it does not, you have too look into copyright headers in sources… it’s problematic
2018-03-20 16:40:14 <jirutka> GPL is just complete mess
2018-03-20 16:41:10 <_ikke_> section 13 says the library would need to specify it, otherwise any version would be eligible
2018-03-20 17:00:12 <terra> thank guys.
2018-03-20 17:00:22 <terra> *s
2018-03-20 17:22:52 <kaniini> also note that GPL-2-only and GPL-3 are incompatible
2018-03-20 20:05:34 <duncan^> Hi, so I've got a metapackage, the sole functionality of which is to pull in other packages. I would like to have a related metapackage (e.g. <metapackage>-extra), which pulls in additional packages. I'm not sure how to do that with subpackages. Is this the correct way to approach this?
2018-03-20 20:06:04 <duncan^> Would a possible approach be as in https://git.alpinelinux.org/cgit/aports/tree/main/xfce4/APKBUILD ?
2018-03-20 20:06:32 <_ikke_> duncan^: You can specify different dependencies per subpackage
2018-03-20 20:06:49 <duncan^> Ah, great!
2018-03-20 20:06:51 <duncan^> Thanks.
2018-03-20 20:21:15 <craftyguy> is 'perf' hidden in some package in Alpine?
2018-03-20 20:22:48 <craftyguy> dang, just found this: https://bugs.alpinelinux.org/issues/7178
2018-03-21 00:08:16 <mitchty> craftyguy: yep, I have a partial implementation of this but got sidetracked, no perf makes me break out in hives too
2018-03-21 00:11:02 <craftyguy> mitchty: oh, is any of it functional yet?
2018-03-21 00:19:17 <mitchty> craftyguy: i'll have to look busy deadlines at work and other shenanigans delayed me from testing and i forgot to update my notes
2018-03-21 00:22:23 <mitchty> i forgot to look if ebpf is configured too
2018-03-21 00:22:46 <mitchty> both of those though would make debugging much more fun
2018-03-21 01:18:35 <terra> Anyone can explain what is the purpose of ldpath= in APKBUILD ?
2018-03-21 01:22:31 <jsmith-sandel> after building x86_64 vanilla kernel (using "/boot/config-vanilla") as a test and then apk install, system cannot mount root by uuid? missing driver in initrd?
2018-03-21 01:24:33 <jsmith-sandel> anyone using canbus ? that's my goal - seems I need a x86_64 "edge" kernel compiled with canbus enabled. Has anyone done that for alpine?
2018-03-21 01:26:26 <terra> jsmith-sandel: no reason to not do that.
2018-03-21 01:26:52 <terra> did you build your kernel via modifying aports?
2018-03-21 01:28:20 <terra> you should build a package that is going to trigger mkinitramfs
2018-03-21 01:31:57 <jsmith-sandel> I copied the linux-vanilla apk folder to my home and used that. It did trigger a run of mkinitramfs. I did change name from vanilla to avilon and have a kernel and initrd with seperate entries in grub.conf (saved me).
2018-03-21 01:34:36 <terra> linux /boot/vmlinuz-vanilla root=UUID=724c18e0-44bc-4222-86ad-ca9d524ae6c2 modules=sd-mod,usb-storage,ext4 rootfstype=ext4
2018-03-21 01:34:57 <terra> initrd /boot/initramfs-vanilla
2018-03-21 01:35:17 <terra> these are mine. but I use grub2.
2018-03-21 01:36:01 <jsmith-sandel>     linux   /boot/vmlinuz-avdisp modules=sd-mod,usb-storage,ext4 root=UUID=90a6fab5-dee6-4fbd-9feb-290cc2b470d2 rootfstype=ext4     initrd  /boot/initramfs-avdisp
2018-03-21 01:36:22 <jsmith-sandel> sorry named avdisp NOT avilon...
2018-03-21 01:36:35 <jsmith-sandel> linux   /boot/vmlinuz-vanilla modules=sd-mod,usb-storage,ext4 root=UUID=90a6fab5-dee6-4fbd-9feb-290cc2b470d2 silent quiet rootfstype=ext4
2018-03-21 01:36:45 <jsmith-sandel> initrd  /boot/initramfs-vanilla
2018-03-21 01:36:48 <jsmith-sandel> also grub2
2018-03-21 01:37:50 <terra> compare sizes of initramfs-vailla and initramfs-yourcustom
2018-03-21 01:38:27 <jsmith-sandel> noted on your kernel command line modules includes usb-storage and sd-mod, I use emmc hmm...
2018-03-21 01:40:09 <jsmith-sandel> same as mine but no obvious entry for mtd related stuff for emmc. I would *assume* that vanilla has those as built-in will quick check vanilla-config
2018-03-21 01:40:46 <jsmith-sandel> 10423752 Mar 15 11:46 initramfs-vanilla
2018-03-21 01:40:54 <jsmith-sandel> 22506600 Mar 20 12:01 initramfs-avdisp
2018-03-21 01:42:07 <terra> probably boot commandline issue
2018-03-21 01:42:28 <terra> I assume mainline kernel didn't changed module names
2018-03-21 01:42:50 <jsmith-sandel> linux   /boot/vmlinuz-vanilla modules=sd-mod,usb-storage,ext4 root=UUID=90a6fab5-dee6-4fbd-9feb-290cc2b470d2 silent quiet rootfstype=ext4
2018-03-21 01:43:01 <jsmith-sandel> linux   /boot/vmlinuz-avdisp modules=sd-mod,usb-storage,ext4 root=UUID=90a6fab5-dee6-4fbd-9feb-290cc2b470d2 rootfstype=ext4
2018-03-21 01:43:13 <jsmith-sandel> two command lines -
2018-03-21 01:44:31 <jsmith-sandel> avdisp panics and drops to cmdline as it cannot mount root - Im stuck there as no usb keyboard driver seems to be loaded
2018-03-21 01:45:14 <jsmith-sandel> only way out is power cycle
2018-03-21 01:46:27 <jsmith-sandel> any idea?
2018-03-21 01:46:42 <jsmith-sandel> suggested action(s) ?
2018-03-21 01:46:45 <terra> happen to me many times when I import Liquorix kernel. I solved generally regenerating initramfs but your initramfs is auto-generated.
2018-03-21 01:49:35 <terra> mkinitfs -c /etc/mkinitfs/mkinitfs.conf -o /boot/initramfs-4.14.3-1-zen.img -F "ata base cdrom ext2 ext3 ext4 kms mmc raid scsi usb virtio" 4.14.3-1-zen
2018-03-21 01:51:56 <jsmith-sandel> I will do on my target (other machine) now (with versions & name replaced) and have an answer in a jiffy (or two) - Thanks!
2018-03-21 01:57:23 <jsmith-sandel> Worked! - booting with new kernel, you da man!
2018-03-21 01:57:40 <terra> good!
2018-03-21 02:00:02 <jsmith-sandel> Will ad this to my notes for kustom kernel builds... Now I can move on to canbus drivers. I did manage to build can-utils from github and need to create a patch as code used gcc's error function.
2018-03-21 02:01:52 <terra> default mkinitfs doesn't work for custom kernels..IMHO
2018-03-21 02:01:55 <jsmith-sandel> I will create an APKBUILD for can-utils, how should I go about sharing that?
2018-03-21 02:02:09 <danieli> I've done quite a bit of vehicle hacking, most via CAN, but none using Alpine
2018-03-21 02:02:24 <terra> but you said it need a custom kernel?
2018-03-21 02:04:10 <jsmith-sandel> vanilla kernel (edge x86_64) has no support for canbus.
2018-03-21 02:04:28 <danieli> it's not hard to recompile, luckily
2018-03-21 02:04:58 <terra> send patches to alpine-aports@lists.alpinelinux.org. patches must be in sync with aports tree. So ypur patch is going to be placed in aports/testing/can-utils/APKBUILD
2018-03-21 02:05:09 <jsmith-sandel> that part went easy - thanks to you now running kernel with canbus support.
2018-03-21 02:05:32 <terra> you're welcome
2018-03-21 02:06:40 <jsmith-sandel> FYI - vcan0 now loaded and shows up in ifconfig!
2018-03-21 02:06:56 <jsmith-sandel> next up hw can device.
2018-03-21 02:07:32 <terra> I really don't know what "can" is
2018-03-21 02:07:47 <danieli> controller area network
2018-03-21 02:07:55 <danieli> usually used in automotive systems
2018-03-21 02:08:37 <terra> hmm
2018-03-21 02:22:17 <tmh1999> terra : I use aports/scripts to generate custom kernel + initramfs
2018-03-21 02:23:57 <terra> that's the sensible way to own a custom kernel if you're going to compile.
2018-03-21 02:24:46 <terra> but when you import a debian or arch kernel..things getting complicated you have to know how to generate a working initramfs.
2018-03-21 09:00:55 <clandmeter> anyone looking for a new workstation? https://www.servethehome.com/gigabyte-thunderxstation-using-cavium-thunderx2-launched/ :)
2018-03-21 09:02:30 <Gottox> awesome stuff, but won't be cheap, will it?
2018-03-21 09:21:27 <clandmeter> i dont know the price yet.
2018-03-21 11:08:14 <HRio> can this be merged? https://github.com/alpinelinux/aports/pull/3052 thanks
2018-03-21 11:08:35 <duncan^> You have made the pull request, just wait
2018-03-21 12:21:48 <clandmeter> HRio, looks like its merged but not auto closed.
2018-03-21 12:27:17 <terra> Anyone can explain what is the purpose of ldpath= in APKBUILD ?
2018-03-21 12:28:38 <terra> APKBUILD Reference doesn't mention about this.
2018-03-21 12:38:16 <ncopa> ldpath is to help abuild find shared libs that are stored in non-standard locations
2018-03-21 12:38:28 <ncopa> for its shared lib dependency detection
2018-03-21 12:40:00 <ncopa> for example, lets say you have plugins in /usr/lib/foo/*.so
2018-03-21 12:40:03 <ncopa> some of those depends on other plugins
2018-03-21 12:40:29 <ncopa> but abuild will only search for libs and shared libs dependencies in /usr/lib and /lib
2018-03-21 12:41:07 <ncopa> so to help abuild also look for deps in /usr/lib/foo it can automatically detect which subpackage that should depend on which
2018-03-21 12:57:35 <clandmeter> ncopa, https://github.com/alpinelinux/aports/pull/3052 isnt closed by i think you merged it?
2018-03-21 12:58:53 <ncopa> i thikn thte bot does not always autodetect that the PRs are merged when they are rebased
2018-03-21 13:00:50 <HRio> clandmeter: ncopa thanks
2018-03-21 13:01:30 <ncopa> np. thanks for your patience
2018-03-21 13:10:56 <HRio> someone here that can look at this fix https://github.com/alpinelinux/aports/pull/3263 ? Fixes the broken roundcube in 3.7
2018-03-21 14:28:15 <terra> ncopa: thanks for explanation.
2018-03-21 14:30:16 <terra> ncopa: It seems abuild checks non standard directories without defining ldpath. Have you any idea on this: https://bugs.alpinelinux.org/issues/8648 ?
2018-03-21 14:57:29 <nmeum> clandmeter: I hate to continue borthering you with this but what happend to the abuild license sanitycheck? (: I would personally like to have this feature in the next abuild release
2018-03-21 14:57:50 <clandmeter> nmeum, ah that one.
2018-03-21 14:58:16 <clandmeter> not sure where i put it. let me check
2018-03-21 14:58:20 <nmeum> :D
2018-03-21 14:58:54 <clandmeter> i have it applied to my local abuild so it bugs me all the time about incorrect licences
2018-03-21 14:59:25 <clandmeter> what are the qualified license separators now?
2018-03-21 14:59:34 <clandmeter> ive seen spaces, but also and.
2018-03-21 14:59:44 <nmeum> spaces
2018-03-21 14:59:50 <clandmeter> and some suggestion for comma.
2018-03-21 15:00:25 <nmeum> i would just stick to spaces, spdx license names don't includes spaces (iirc) so I don't see any problem with using spaces
2018-03-21 15:02:23 <clandmeter> what about moving warnings to the end of abuild process?
2018-03-21 15:03:59 <nmeum> hm, not sure could have some advantages. I would personally not include such a feature in the next release though
2018-03-21 15:04:54 <clandmeter> having them in the beginning is a bug imho.
2018-03-21 15:05:37 <nmeum> they do not only appear at the beginning some of them also appear during the package split for instance
2018-03-21 15:06:01 <clandmeter> right, well those can stay i guess.
2018-03-21 15:42:40 <clandmeter> nmeum, i added a PR for abuild
2018-03-21 15:44:19 <nmeum> nice
2018-03-21 15:44:20 <nmeum> thanks!
2018-03-21 15:48:09 <clandmeter> but as i mentioned, the warnings will be at the beginning of the build process. I dont think many users will see it.
2018-03-21 15:48:25 <clandmeter> only when we enforce it it will be noticed.
2018-03-21 15:48:51 <clandmeter> but that creates havoc
2018-03-21 15:50:09 <clandmeter> So my suggestion is to create a post build warning check for things like missing maintainer, incorrect license and such.
2018-03-21 16:14:06 <ncopa> im looking at mariadb upgrade
2018-03-21 16:14:14 <ncopa> looks like upgrade renames libmysqlclient to libmariadb client
2018-03-21 16:14:30 <ncopa> meaning that we need to rebuild lots of stuff
2018-03-21 16:15:04 <ncopa> is that something we want to do or should i look into how to keep compat?
2018-03-21 16:19:25 <kaniini> what about stuff that hardcodes -lmysqlclient
2018-03-21 18:52:08 <ncopa> i think they should work since tehre is a libmysqlclient.so -> libmariadb.so symlink
2018-03-21 20:14:02 <bernhardgruen[m]> Hey, do you already have an idea how to follow the Java release plan? Java 10 was released today - 6 months after Java 9.
2018-03-21 20:18:14 <bernhardgruen[m]> My idea to build it was to download the binary version of the JDK (e.g. the one used in the docker image) and then recompile the sources from scratch.
2018-03-21 22:19:31 <terra> Are packages building on headless systems? I mean is X running and DISPLAY set during build process?
2018-03-21 22:20:25 <terra> gst-plugins-base test suite requires X running.
2018-03-21 23:30:11 <duncan^> How can we specify a given package is public domain (as interpreted in the U.S.)?
2018-03-21 23:41:08 <andypost> hey, any idea about how to deal with https://bugs.alpinelinux.org/issues/8619
2018-03-22 00:29:14 <nmeum> andypost: other distros e.g. archlinux seem to remove the fonts from libwmf https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/libwmf#n76
2018-03-22 00:40:05 <andypost> nmeum, thanks! really nice workaround!
2018-03-22 01:00:00 <arch3y> tw
2018-03-22 01:57:52 <andypost> Looks everything is ready to PHP upgrade, but travis is not able to test it all https://github.com/alpinelinux/aports/pull/2873
2018-03-22 03:47:28 <deedubs> How should I be setting pkgver when upstream is 1.0.0-rc5 and abuild explodes with a invalid version message
2018-03-22 09:21:51 <chambbj> Can someone please review https://github.com/alpinelinux/aports/pull/3708 when you get a chance?
2018-03-22 09:30:51 <clandmeter> i wonder if its really necessary to update apk cache when i delete a package.
2018-03-22 09:37:55 <clandmeter> nmeum, you are right about grep being faster.
2018-03-22 09:38:04 <clandmeter> but i bumped into something which i think is a bug
2018-03-22 09:39:03 <clandmeter> i wanted to know how much it was faster so i run:
2018-03-22 09:39:16 <clandmeter> echo "aa" | grep -F -w "a"
2018-03-22 09:40:28 <clandmeter> this is true for bb but false for gnu grep.
2018-03-22 09:40:49 <_ikke_> hmm, how does -F and -w combine?
2018-03-22 09:41:20 <clandmeter> my input was a text file
2018-03-22 09:41:47 <clandmeter> so it had weird results for repeating chars.
2018-03-22 09:46:46 <bernhardgruen> Coming back to my OpenJDK (10) related question of yesterday. How would it be possible to build OpenJDK 9 and 10 for Alpine?
2018-03-22 09:48:10 <clandmeter> it only happens when the pattern is a single char and -F and -w are combined.
2018-03-22 10:10:05 <ncopa> bernhardgruen: everyting is possible. The impossible just takes longer time
2018-03-22 10:10:11 <ncopa> deedubs: use pkgver="1.0.0_rc5" and source="https://example.com/downloads/foo-${pkgver/_rc/-rc}.tar.gz"
2018-03-22 10:12:05 <bernhardgruen> ncopa, my preference would be to directly download the binaries of OpenJDK (they seem to run on Alpine) and then start the normal build using the Mecurial repository source codes (don't know if that works).
2018-03-22 10:13:21 <bernhardgruen> My problem is that our company heavily depends on java (nearly all our software is written in Java).
2018-03-22 10:15:03 <ncopa> building openjdk is a major project
2018-03-22 10:15:04 <ncopa> it also needs bootstrapping
2018-03-22 10:15:05 <ncopa> i think it should be possible to build openjdk9 with openjdk8
2018-03-22 10:15:31 <bernhardgruen> ncopa, next thing: the official openjdk docker image (which also uses alpine) directly uses the compiled versions from the alpine repo. Therefore there is currently no build for openjdk:9-alpine
2018-03-22 10:15:53 <ncopa> i am currently working on mariadb upgrade
2018-03-22 10:16:01 <ncopa> which is a bit hairy too
2018-03-22 10:16:31 <bernhardgruen> I saw it - will be a lot of work.
2018-03-22 10:17:32 <bernhardgruen> What is the IRC name of Timo (the maintainer of openjdk 8) btw?
2018-03-22 10:28:07 <clandmeter> fabled
2018-03-22 10:31:59 <bernhardgruen> thank you, clandmeter. I hope he is around in the next days.
2018-03-22 10:32:40 <clandmeter> he should, just wait a bit.
2018-03-22 10:33:08 <clandmeter> if not you can also email to devel list.
2018-03-22 10:34:17 <bernhardgruen> good point - I will subscribe the list in the first step.
2018-03-22 11:22:03 <terra> I upgraded gstreamer to 1.14.0 on my PC. I'm compiling gstream-vaapi (as new aport) against this version but when I install it via apk, apk insisting on to installing it via old 1.12 version.
2018-03-22 11:22:55 <terra> *gstreamer-vaapi
2018-03-22 11:29:57 <terra> I deleted cache.. re-compiled many times.. checked linked libraries.. everything seem ok with new 1.14.0
2018-03-22 11:50:27 <nmeum> clandmeter: that's probably caused by the fact that combining -w and -F is actually a bit nasty. `-F` usually only matches fixed strings
2018-03-22 11:52:34 <clandmeter> nmeum, check PR, it has been reported already.
2018-03-22 11:52:50 <nmeum> ah
2018-03-22 13:48:39 <duncan^> So I've got a metapackage. It only pulls in dependencies. I then have a subpackage to this metapackage, called <package>-extras.
2018-03-22 13:49:33 <duncan^> In this subpackage's extras() function, I also specify dependencies, a pkgname, and a pkgver. However, when building, it produces the following error:
2018-03-22 13:50:41 <duncan^> <package>-extras:couldn't find /home/user/aports/testing/<package>-extra/pkg/<package>-extra
2018-03-22 13:50:48 <duncan^> s
2018-03-22 13:51:28 <duncan^> then it basically says preparing it failed
2018-03-22 14:07:28 <Invader_Bork> has it ever been discussed of an alpine user package repo, like arch's aur?
2018-03-22 14:07:28 <bernhardgruen> duncan^, did you already specify the extra subpackage in the variable subpackages=""? like subpackages=$pkgname-extras"
2018-03-22 14:08:02 <duncan^> Yes, I did.
2018-03-22 14:10:39 <bernhardgruen> duncan^, you sometimes write extras and also extra. maybe its just a typo?
2018-03-22 14:10:55 <duncan^> Nope.
2018-03-22 14:12:04 <bernhardgruen> Do you have a public copy of your APKBUILD available?
2018-03-22 14:13:58 <clandmeter> duncan^,  you cannot define another pkgver in subpkg
2018-03-22 14:14:21 <PureTryOut[m]1> Invader_Bork: there has been some discussion for having some sort of PPA system like Ubuntu, but I don't recall something like the AUR being discussed
2018-03-22 14:16:04 <duncan^> bernhardgruen: Yes, it is like this: https://paste.debian.net/hidden/6ac8015c/
2018-03-22 14:16:11 <duncan^> clandmeter: I've not. I didn't mean to write that.
2018-03-22 14:18:38 <bernhardgruen> duncan^, don't specify pkgname="...-extra" inside extras(). and I think options="!check" is also not correct there.
2018-03-22 14:19:10 <Invader_Bork> PureTryOut[m]1, can you please point me towards that discussion?
2018-03-22 14:19:54 <clandmeter> duncan^, you made some mistakes here.
2018-03-22 14:20:06 <clandmeter> some options are only global
2018-03-22 14:20:18 <clandmeter> license arch and options
2018-03-22 14:20:28 <PureTryOut[m]1> Invader_Bork: sorry it has been quite a while ago, I have no clue how far back it is
2018-03-22 14:20:45 <PureTryOut[m]1> I'm also not entirely sure it's been discussed in this channel, it might've been in #postmarketos
2018-03-22 14:21:49 <clandmeter> you can set arch in global subpackages variable.
2018-03-22 14:21:55 <clandmeter> and this also defines the pkgname
2018-03-22 14:22:12 <Invader_Bork> PureTryOut[m]1, i see. thanks anyways :)
2018-03-22 14:22:33 <clandmeter> Invader_Bork, i do not recall a recent discussion.
2018-03-22 14:24:26 <clandmeter> but im sure it has been discussed before. maybe you can search the logs at: http://dev.alpinelinux.org/irclogs/
2018-03-22 14:33:47 <clandmeter> duncan^, i think at least you also have to create the $subpkgdir to make abuild happy.
2018-03-22 15:03:51 <Harm133> Hey guys, I'm a developer/sysadmin and would like to conribute. Don't have any particular intrests. What region of alpine could use help the most?
2018-03-22 15:04:38 <ncopa> hi
2018-03-22 15:05:07 <ncopa> our current biggest problems is: 1) fixing bugs, 2) review patches
2018-03-22 15:05:51 <Harm133> Alright :). I'll look into the bugs list
2018-03-22 15:06:24 <ncopa> bugs.alpinelinux.org
2018-03-22 15:09:19 <ncopa> we also need help with reviewing PRs and help contributors to fix things to a level where we can merge
2018-03-22 15:11:56 <Harm133> Honestly, I just started doing programmer work. Been doing sysadmin work for quite a while. Will start with some low prio bugs to start contributing :)
2018-03-22 15:22:39 <Harm133> #alpine-linux
2018-03-22 16:43:19 <cmpwhajj_>  hello folks, I've installed kubernetes v1.8.3 on alpine 3.7 and used flannel v0.9.1 as a network pod. after successfully installing the flannel with 'kubectl apply' command, the kubernenets pod k8s-dns-sidecar couldn't start. please has any one of you experienced this problem. PS I reproduced the setup on ubuntu and centos and it works like a charm. thank you
2018-03-22 16:44:35 <cmpwhajj_> please feel free to ask me for details so that you can reproduce the problem
2018-03-22 18:46:54 <Fusl> anyone available to take a look into these almost one month old PRs? https://github.com/alpinelinux/aports/pull/3377 https://github.com/alpinelinux/aports/pull/3378
2018-03-22 19:38:49 <danieli> cmpwhajj_: would easier if you just told us what you've tried in terms of troubleshooting and what exactly the issue is, if you've done any debugging
2018-03-22 21:24:26 <Harm133> where would I suggest patches for the ISOs? its regarding https://bugs.alpinelinux.org/issues/8704
2018-03-22 22:42:40 <Harm133> ncopa, why did you enable this ? https://git.alpinelinux.org/cgit/alpine-iso/patch/alpine-virt.conf.mk?id=260faac06f5e8233bb59876a33cdcb9d1d24313a
2018-03-23 00:41:21 <deedubs> I'm working on a kubernetes cluster offering built on Alpine. I'm working my way though the packages I need but I'd also like to contribute the the ecosystem as a whole. Is there a particular area where assistance is needed? I'd love to take over maintenof some packages. Bonus points if they are related to my work with containers / high security systems
2018-03-23 00:42:01 <deedubs> I can also offer general ops support as well for infrastructure efforts if that's a need
2018-03-23 01:19:05 <Xe> deedubs: did you do your cluster on metal or VM's?
2018-03-23 01:27:27 <tmh1999> in case I screw something up that, running $ lbu package misses out files in /etc/runlevels/*/ (symlinks to /etc/init.d/ services), what might be the things I screw up ?
2018-03-23 01:29:34 <tmh1999> alright reading lbu source ...
2018-03-23 01:37:09 <tmh1999> okay I am not sure if this behavior is intended but recent change in busybox related to EXTRACT_UNSAFE_SYMLINKS=1, break the tar when it extract the output of $ lbu package
2018-03-23 01:38:26 <tmh1999> let's check git log ..
2018-03-23 01:40:41 <tmh1999> problem at : https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-disk.in#n408
2018-03-23 01:41:11 <deedubs> Xe: initially targeting VMs but nothing is tied to that fact
2018-03-23 01:41:12 <tmh1999> is adding  EXTRACT_UNSAFE_SYMLINKS=1 to the tar acceptable ? Or should we fix something else ?
2018-03-23 01:45:36 <tmh1999> It looks like it needs so. nmeum patched one in mkinitfs
2018-03-23 01:46:09 <tmh1999> I will be sending a patch to alpine-conf to address this
2018-03-23 02:00:26 <tmh1999> okay there are many places we need to patch this EXTRACT_UNSAFE_SYMLINKS=1 in mkinitfs, alpine-conf, etc.
2018-03-23 02:01:05 <tmh1999> nmeum: Do you think this needs to be patched too ? https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n46
2018-03-23 02:09:46 <tmh1999> seems to be fixed upstream : https://git.busybox.net/busybox/commit/?id=a84db18fc71d09e801df0ebca048d82e90b32c6a
2018-03-23 02:10:25 <tmh1999> 1.28.1 stable release doesn't have this commit yet. So guess I cherry pick :D
2018-03-23 02:30:12 <tmh1999> https://github.com/alpinelinux/aports/pull/3733
2018-03-23 04:59:13 <Fusl> any alpine dev willing to merge https://github.com/alpinelinux/aports/pull/3735 for a security bugfix?
2018-03-23 05:03:15 <kaniini> yes i will look in a moment
2018-03-23 05:03:41 <kaniini> do you have a CVE for it
2018-03-23 05:27:48 <Fusl> there was no CVE id request for this one
2018-03-23 09:44:58 <ncopa> i have spent 2 days on a signle PR
2018-03-23 09:45:10 <ncopa> meanwhile the PR queue has increased to 250
2018-03-23 10:05:38 <Harm133> ncopa, could you comment on why you patched this in? https://git.alpinelinux.org/cgit/alpine-iso/patch/alpine-virt.conf.mk?id=260faac06f5e8233bb59876a33cdcb9d1d24313a
2018-03-23 10:23:34 <clandmeter> Harm133, i guess you know alpine-iso is deprecated?
2018-03-23 10:24:05 <Harm133> clandmeter, lol, nope
2018-03-23 10:24:33 <clandmeter> i think we should add a note in the repo about it.
2018-03-23 10:24:41 <clandmeter> you need to use aports/scripts
2018-03-23 10:24:44 <Harm133> I just started using alpine 2 days ago :)
2018-03-23 10:24:54 <clandmeter> mkimiage
2018-03-23 10:24:59 <clandmeter> mkimage....
2018-03-23 10:25:31 <ncopa> there were people asking for enable serial console by default
2018-03-23 10:25:42 <ncopa> i was afraid of doing that on all iso images
2018-03-23 10:25:59 <ncopa> but enabling serial console for virtual machines seemed safe
2018-03-23 10:26:05 <ncopa> and its sort of handy to have serial colsole from qemu for example
2018-03-23 10:26:18 <Harm133> Alright :) It just throws a bunch of errors into logs seeing I dont have a serial capeable device in my machine
2018-03-23 10:26:30 <ncopa> that is why i did it
2018-03-23 10:26:36 <ncopa> i suppose that boot option was copied to aports/scripts too
2018-03-23 10:27:10 <Harm133> Yes its in there, I manually edited the ISO yesterday and deleting the serial options made the errors dissapear
2018-03-23 10:28:19 <ncopa> i guess there is no harm done, except creating unecessary error messages
2018-03-23 10:52:06 <clandmeter1> Natanael Copa: seems we are limiting cores to 32 on aarch64
2018-03-23 10:54:16 <clandmeter1> i guess we should upgrade that to 256 and enable thunderx2
2018-03-23 11:23:57 <cmpwhajj_> hi folks, I installed flannel 1.9.0 with k8s 1.8.3 on alpine 3.7. The kube-dns pod can't start. The message I've found in kubelet log is: W0323 11:23:17.770709    4028 docker_sandbox.go:343] failed to read pod IP from plugin/docker: NetworkPlugin cni failed on the status hook for pod "kube-dns-545bc4bfd4-bf7gp_kube-system": Unexpected command
2018-03-23 11:28:25 <cmpwhajj_> I've shared instructions to reproduce the problem as well as the kubelet log and kube-dns log on this link https://github.com/wajdihajji/kubernetes-alpine
2018-03-23 11:29:22 <cmpwhajj_> I've reproduced the same setup on Ubuntu and Centos and I've not faced any issue
2018-03-23 12:13:21 <hs3dUBwdmCjy> did you check if any of your stuff is linked against glibc?
2018-03-23 13:13:00 <korylprince> Hello all, I've submitted a bug for the rt4 package here: https://bugs.alpinelinux.org/issues/8712 and submitted a patch here: https://patchwork.alpinelinux.org/patch/3903/ . My question is, is this the best way to get the patch accepted? Or would you rather a github pull?
2018-03-23 14:07:11 <mps> didn't know for patchwork, is it possible to use credentials from bugs.a.o to login to patchwork.a.o or new registration is required
2018-03-23 14:07:46 <_ikke_> mps: I don't think there is any coupling
2018-03-23 14:08:06 <_ikke_> I'm fairly certain even
2018-03-23 14:08:50 <mps> ok, but that would be nice feature
2018-03-23 14:09:54 <_ikke_> Nod
2018-03-23 14:10:24 <mps> btw, there is pwclient so I pressume it could used without going to web page, but I have first to install it and see
2018-03-23 16:14:52 <dandelion> Hi! All !
2018-03-23 16:16:05 <dandelion> when will be next version release ? 3.7.1 ?
2018-03-23 16:27:55 <ncopa> when we have the kernels sorted out
2018-03-23 16:32:54 <dandelion> thx
2018-03-23 16:33:25 <dandelion> is wayland/weston  working now ? ( aka no X  )
2018-03-23 17:01:34 <deedubs> Is there a good example of building a Golang apk with Go dependancies? I had it working locally but its exploding on Travis CI
2018-03-23 17:05:28 <_ikke_> docker, fzf
2018-03-23 17:32:01 <deedubs> Was that for me? _ikke_
2018-03-23 17:48:33 <_ikke_> deedubs: yes
2018-03-23 17:49:00 <deedubs> okay awesome. I'll take a look at the docker APKBUILD thanks so much
2018-03-23 17:49:29 <deedubs> It's funny that this is for runc, a docker alternative
2018-03-23 17:56:53 <deedubs> and I see they build runc too :|
2018-03-23 18:47:19 <clandmeter> skarnet, small upgrade ;-) http://dev.alpinelinux.org/~clandmeter/other/thunderx-dual-cpu.png
2018-03-23 18:48:27 <skarnet> so many cores and you're not doing anything with them. It's a terrible waste, I think you should gift that machine to me, I'd put it to good use. :P
2018-03-23 18:48:35 <_ikke_> haha :D
2018-03-23 18:48:47 <_ikke_> I'd also have a good use for it :P
2018-03-23 18:52:16 <clandmeter> it will soon make alpine babies :p
2018-03-23 18:55:45 <skarnet> parthenogenesis?
2018-03-23 18:59:27 <clandmeter> its in a rack i suppose, so who knows.
2018-03-23 19:14:09 <skarnet> what? you don't have it at home? :P
2018-03-23 19:23:18 <HRio> can somebody merge this small improvment https://github.com/alpinelinux/aports/pull/3667 ? already merged upstream
2018-03-23 19:48:27 <Harm133> How do you guys deal with issues like : https://bugs.alpinelinux.org/issues/8611 ? I've tried to reproduce the issue but cant with a fresh install. I guess the setting is a remnant of old config carried over from an earlier version.
2018-03-23 20:02:52 <bernhardgruen[m]> I will update the docker aport from 18.02.0 to 18.03.0 (stable version). That version could be backported to Alpine 3.7. How can I create a PR for that?
2018-03-23 20:07:39 <bernhardgruen[m]> All in all I am happy to announce that the switch to our Alpine Docker Hosts increased my free time a lot. Therefore I decided that I can spend part of my daily work time to work on Alpine.
2018-03-23 20:53:31 <_ikke_> nice to see an influx of new people
2018-03-23 21:00:00 <prspkt> hello from me as well. been using alpine for a few months
2018-03-23 23:04:22 <tmh1999> clandmeter: 126GB ram and 4gb swap :D
2018-03-24 07:23:01 <clandmeter> tmh1999, you need more swap with 128 of ram?
2018-03-24 08:39:46 <andypost> clandmeter, why you need a swap at all?
2018-03-24 08:56:40 <bernhardgruen[m]> How could the process of reviewing and accepting of PR improved? At the moment it takes IMHO way to long sometimes. For testing I propose to accept changes (from the maintainer of a package) directly. For community and main I assume this won't work. But there could be some acceptance process where maintainers and contributors of dependant packages vote pro/con the merge.
2018-03-24 08:56:41 <bernhardgruen[m]> This way some kind of peer reviewing takes place and the decision process gets faster.
2018-03-24 08:59:49 <clandmeter> andypost, i just used defaults provided by setup-alpine. i dont mind it allocates a bit of swap.
2018-03-24 09:48:10 <andypost> clandmeter, btw using zram could be better option
2018-03-24 10:13:58 <andypost> should I split this PR in 2 to make tests pass? Second commit depends on first one
2018-03-24 10:14:10 <andypost> https://github.com/alpinelinux/aports/pull/3717
2018-03-24 11:16:22 <nmeum> andypost[m]: no, it's okay as is
2018-03-24 11:16:54 <nmeum> will hopefully find some time to merge some PRs later this afternoon
2018-03-24 11:40:08 <andypost[m]> nmeum: thanks, also would be great to schedule php 7.2 switch
2018-03-24 11:40:30 <andypost[m]> It is really pita to reroll
2018-03-24 11:49:16 <nmeum> I really try to avoid interact with php packages since I don't know shit about php. somebody else has to take care of that
2018-03-24 12:44:17 <nmeum> andypost[m]: morged
2018-03-24 12:44:19 <nmeum> *merged
2018-03-24 13:53:23 <danieli> mordored
2018-03-24 13:53:27 <danieli> murdered
2018-03-24 14:49:55 <BitL0G1c> Is there a way to debug kworker processes in Alpine ? (perf is not available & the debugfs is not available on the hardened kernel)
2018-03-24 16:31:47 <tmh1999> clandmeter: no hard feeling, I just find it a little funny :D
2018-03-24 16:50:50 <terra> Hi guys..how can I prevent some library files treated as shared libraries during packaging?
2018-03-24 16:51:26 <terra> just like /usr/lib/firefox/libxul.so
2018-03-24 16:58:16 <terra> apk treats bundled libraries as shared libraries but this is getting problemtic with packages that have libraries with same base name.
2018-03-24 17:57:52 <kaniini> terra: somask in APKBUILD, but again, note that palemoon will *not* be accepted into alpine under any circumstance
2018-03-24 18:09:43 <duncan^> Let's say I've got a -dev subpackage, does it automatically depend on the main package?
2018-03-24 18:11:28 <danieli> why would it?
2018-03-24 18:15:29 <mps> kaniini: any hint why palemoon will not be accepted. I don't have opinion about that, I'm just curious
2018-03-24 18:17:14 <skarnet> kaniini: because the palemoon devs are a bunch of assholes who barge in with guns blazing when you do something that deviates subtly from their official instructions, instead of asking nicely?
2018-03-24 18:17:28 <skarnet> mps ^
2018-03-24 18:18:01 <mps> skarnet: tnx for explanation
2018-03-24 18:32:38 <duncan^> it's also made up of large parts of what are essentially unmaintained code
2018-03-24 19:13:21 <Harm133> can someone explain how package upgrades are handled with apk?
2018-03-24 19:13:35 <Harm133> Or point me towards the relevant documentation, cant really find it
2018-03-24 19:14:24 <_ikke_> Harm133: Anything in particular you are looking for?
2018-03-24 19:15:07 <Harm133> _ikke_, Yea, I want to create a patch for dovecot. Warning for breakage on certain 'older' configs if upgraded
2018-03-24 19:15:35 <Harm133> But I can't find where to write something like that :)
2018-03-24 19:16:20 <_ikke_> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#.24pkgname.post-upgrade
2018-03-24 19:17:55 <Harm133> _ikke_, thx ^^ Guess I was on the right track then :p
2018-03-24 19:19:12 <Harm133> but looking at this: https://git.alpinelinux.org/cgit/aports/tree/main/dovecot?h=3.7-stable Why are there 2 files called dovecot.initd & dovecot.logrotate ?
2018-03-24 19:20:06 <_ikke_> Harm133: THose are just files that get installed
2018-03-24 19:20:28 <_ikke_> https://git.alpinelinux.org/cgit/aports/tree/main/dovecot/APKBUILD?h=3.7-stable#n105
2018-03-24 19:20:29 <Harm133> nvm, they are in the APKBUILD. :)
2018-03-24 19:20:37 <Harm133> thx ^^
2018-03-24 23:14:52 <terra> kanini: I've chatted with palemoon dev and he was very nice on me. He already confirmed build parameters (mozconfig) of mine thus branding will not be an issue.
2018-03-25 00:26:53 <duncan^> terra: What happens if Alpine developers/maintainers decide to change the configuration, though? Does the Palemoon developer keep being nice?
2018-03-25 01:37:56 <terra> duncan^: I don't know why would LApine devs do such thing as long as they aware of branding issue.
2018-03-25 01:40:12 <terra> additionally, we have no limitations as long as we distribute it with a different branding like "New Moon". As additional package can be made easily.
2018-03-25 01:48:55 <terra> *an
2018-03-26 10:29:26 <ncopa> i think i have rebuilt everything in main and community against mariadb now
2018-03-26 10:29:47 <ncopa> i am ready to push it
2018-03-26 10:30:27 <ncopa> so what i have done is using mariadb-connector-c as client library and remove the conflicting client dev files from mariadb-dev
2018-03-26 10:30:59 <ncopa> a handful packages needs patching
2018-03-26 11:33:52 <ncopa> ok.. i think I have a problem
2018-03-26 11:34:17 <ncopa> mariadb-connector-c seems to use swapcontext and use some x86_64 specific assembly :-/
2018-03-26 11:37:35 <_ikke_> ugh
2018-03-26 12:03:27 <ncopa> looks like we have a fix for it for mariadb already. needs adjust a corresponding patch for connector-c
2018-03-26 12:20:44 <Gottox> Just managed to get gnome running with musl :D
2018-03-26 12:21:38 <ncopa> Gottox: congrats!
2018-03-26 12:24:25 <Gottox> webkit rendering a page correctly is still a game of pure chance, but that aside it runs very well.
2018-03-26 12:58:09 <fabled> ncopa, kaniini had libucontext done
2018-03-26 12:58:38 <ncopa> i fixed the cmake test
2018-03-26 12:58:52 <fabled> https://github.com/kaniini/libucontext
2018-03-26 12:59:09 <fabled> in case *context stuff is mandatory
2018-03-26 12:59:10 <ncopa> to not only test for header existance
2018-03-26 12:59:13 <fabled> right
2018-03-26 12:59:18 <ncopa> but also do link test
2018-03-26 12:59:20 <ncopa> ok
2018-03-26 12:59:28 <fabled> i had patch in mariadb for that
2018-03-26 12:59:38 <ncopa> i found it
2018-03-26 12:59:43 <fabled> it was also recently merged upstream
2018-03-26 12:59:57 <ncopa> and adapted it for mariadb-connector-c
2018-03-26 13:03:23 <Gottox> hows your mariadb switch going?
2018-03-26 13:09:17 <ncopa> i think its good now
2018-03-26 13:09:45 <ncopa> i solved all the known issues
2018-03-26 13:10:28 <ncopa> and i am waiting for the builders to complete
2018-03-26 13:10:33 <ncopa> i also pushed kernel update so it will take a while
2018-03-26 13:10:48 <ncopa> kunkku_: any objection to push this? http://tpaste.us/RjLW
2018-03-26 13:11:16 <ncopa> its from this: https://github.com/alpinelinux/aports/pull/2505
2018-03-26 13:39:39 <korylprince> For issue: https://bugs.alpinelinux.org/issues/8712  It looks like my v1 patch was merged instead of my v2 patch. The v1 patch contained a bug. Should I resubmit a new issue and/or bug?
2018-03-26 13:47:08 <ncopa> yeah, please submit new issue
2018-03-26 13:56:35 <korylprince> Sounds good!
2018-03-26 14:54:20 <andypost> can anyone backport https://github.com/alpinelinux/aports/pull/3764 to 3.7?
2018-03-26 16:30:32 <ncopa> andypost: looks like it fails to build on x86
2018-03-26 16:51:45 <andypost> ncopa, I see http://build.alpinelinux.org/buildlogs/build-edge-x86/community/php7-imagick/php7-imagick-3.4.3-r5.log
2018-03-26 16:53:58 <andypost> ncopa, is there a way to subscribe on build failures?
2018-03-26 16:54:50 <ncopa> i think the test is broken
2018-03-26 16:54:51 <ncopa> no 031
2018-03-26 16:54:52 <ncopa> i believe this will fix it: http://tpaste.us/ze9W
2018-03-26 16:55:01 <ncopa> there is #alpine-commits irc channel
2018-03-26 16:56:04 <ncopa> hum, the patch does not fix it
2018-03-26 16:57:28 <ncopa> because it has a typo. missing ;
2018-03-26 17:04:22 <andypost> ncopa, tested locally the test passing with this patch
2018-03-26 17:05:32 <andypost> x86_64 https://gist.github.com/andypost/dea1c45a072175449031f7ac7b0d9a66
2018-03-26 17:06:47 <ncopa> i pushed it
2018-03-26 17:08:29 <ncopa> oh my... 258 PRs
2018-03-26 17:08:34 <ncopa> and i spent 3 days on a single PR...
2018-03-26 17:13:06 <_ikke_> ncopa: can I help in some way/
2018-03-26 17:49:57 <andypost> ncopa, jirutka if php 7.2 upgrade will be commited to edge is there a way to keep 3.7 with 7.1?
2018-03-26 17:50:33 <jirutka> andypost: yes, ofc, this definitely should not be backported to existing stable branches
2018-03-26 17:51:03 <jirutka> (the upcoming release is 3.8)
2018-03-26 17:51:28 <_ikke_> andypost: 3.7 is a different branch, someone needs to explicitly commit to that branch
2018-03-26 17:52:08 <andypost> great! cos there's no BC
2018-03-26 17:52:25 <_ikke_> andypost: what breaks BC?
2018-03-26 17:52:53 <jirutka> BC?
2018-03-26 17:53:24 <_ikke_> backwards compattibility
2018-03-26 17:53:30 <andypost> yep
2018-03-26 17:55:09 <andypost> _ikke_, 7.2 has a lot of changes that incompatible with 7.1
2018-03-26 17:55:34 <andypost> _ikke_, and a lot of apps still not ready to work on it
2018-03-26 17:56:09 <jirutka> aha
2018-03-26 17:56:26 <jirutka> how many php packages are not compatible with 7.2 yet?
2018-03-26 17:56:28 <_ikke_> andypost: Trying to find a list of changes that are incompattible
2018-03-26 17:56:36 <andypost> _ikke_, http://php.net/manual/en/migration72.incompatible.php
2018-03-26 17:57:04 <_ikke_> thanks
2018-03-26 17:59:02 <andypost> jirutka, actually I did check mostly all in aports 2 month ago, and only one (php7-cassandra) was broken.. so moved to unmaintained
2018-03-26 17:59:27 <jirutka> andypost: that’s IMHO okay
2018-03-26 17:59:35 <andypost> https://github.com/alpinelinux/aports/pull/2873 is where we prepared all changes
2018-03-26 17:59:52 <jirutka> if someone needs 7.1, (s)he can still use v3.7
2018-03-26 18:00:02 <andypost> only imagick/gmagick got updates and needs bump
2018-03-26 18:01:15 <andypost> exactly, other options are build manually (for case when 3.7 has outdated versions) or setup own repo)
2018-03-26 18:01:51 <jirutka> yeah
2018-03-26 18:02:42 <andypost> jirutka, btw before 3.7.1 release can we update some packages?
2018-03-26 18:03:35 <jirutka> andypost: only non-breaking changes
2018-03-26 18:03:53 <jirutka> hm, ncopa, where do you plan to release v3.7.1?
2018-03-26 18:04:21 <skarnet> jirutka: you gonna package mdevd someday, or should I do it? maybe I can do the mechanism package, and let you handle the scripts with openrc if/when you want to make the switch from mdev?
2018-03-26 18:05:52 <jirutka> skarnet: have you already released that version that doesn’t need pipe between two commands?
2018-03-26 18:06:06 <skarnet> it's only been three months
2018-03-26 18:06:13 <jirutka> uh, aha
2018-03-26 18:06:41 <andypost> jirutka, yes, minor updates, like php7-apcu which has some segfaults on 3.7
2018-03-26 18:07:01 <jirutka> andypost: and fixes are welcome too ofc :)
2018-03-26 18:07:12 <jirutka> andypost: pls open PR against 3.7-stable with that
2018-03-26 18:07:44 <jirutka> skarnet: okay, if you prepare the aport and open PR or send patch, it’d be better
2018-03-26 18:07:48 <andypost> jirutka, will to, I just thought that 3.7 is set in stone))
2018-03-26 18:07:59 <_ikke_> jirutka: ncopa said when they got the kernels sorted out
2018-03-26 18:08:10 <jirutka> _ikke_: aha
2018-03-26 18:08:19 <_ikke_> "17:27:55           @ncopa │ when we have the kernels sorted out "
2018-03-26 18:08:51 <skarnet> jirutka: ok, should I stick to basics or should I try to implement "actually run the thing at startup instead of busybox mdev" ?
2018-03-26 18:09:10 <jirutka> skarnet: as you like ;)
2018-03-26 18:09:20 <skarnet> ok ^^
2018-03-26 18:19:02 <andypost> jirutka, is that fine to remove md5 & sha256 checksums? https://github.com/alpinelinux/aports/pull/3776
2018-03-26 18:19:12 <jirutka> andypost: yes, that’s fine
2018-03-26 18:20:26 <_ikke_> I see a lot of PRs are getting closed
2018-03-26 18:20:38 <_ikke_> :)
2018-03-26 18:21:25 <jirutka> _ikke_: actually not a lot enough, ncopa is quite desperate from growing PRs queue
2018-03-26 18:21:35 <_ikke_> yeah
2018-03-26 18:21:43 <_ikke_> I'm tracking it in Zabbix
2018-03-26 18:22:30 <_ikke_> https://imgur.com/a/P2o11
2018-03-26 18:24:09 <jirutka> wow
2018-03-26 18:28:15 <_ikke_> I'd like to help if there is any way
2018-03-26 18:30:38 <jirutka> _ikke_: please do code reviews of PRs :)
2018-03-26 18:31:25 <_ikke_> Empty fields should be left out, right?
2018-03-26 18:31:59 <jirutka> empty variables in apkbuild?
2018-03-26 18:32:03 <_ikke_> yeah
2018-03-26 18:32:17 <jirutka> yes
2018-03-26 18:32:30 <jirutka> and depends_dev should not be declared or used when there’s no -dev subpackage
2018-03-26 18:33:14 <_ikke_> right, makes sense
2018-03-26 18:37:24 <_ikke_> Any opinion about AUTO_GOPATH?
2018-03-26 18:45:04 <_ikke_> Seems to be a docker variable
2018-03-26 18:47:25 <skarnet> jirutka: in order to make mdevd a suitable mdev implementation I'd first need to rip mdevd.initd from busybox-initscripts and make an alternative, with a mdev package and a mdevd package. What's the simplest way of doing that? should I ask ncopa?
2018-03-26 18:49:13 <jirutka> skarnet: there’s /etc/init.d/mdev (not “d” at the end) in busybox-initscripts; but your program is named mdevd, so there’s not a conflict?
2018-03-26 18:49:40 <_ikke_> jirutka: can you add S-changes-requested to https://github.com/alpinelinux/aports/pull/3752?
2018-03-26 18:49:51 <_ikke_> (or someone else for that matter)
2018-03-26 18:50:37 <skarnet> jirutka: there's no conflict on the files, no. But there's conflict on the functionality: either you have mdev as a hotplug helper, or you're running mdevd. Having both is a bad idea.
2018-03-26 18:50:40 <andypost> _ikke_, done
2018-03-26 18:50:43 <_ikke_> andypost: thanks
2018-03-26 18:52:01 <skarnet> so, if mdevd is installed and used, mdev.initd should not be run (and a different mdevd.initd should be run instead)
2018-03-26 18:52:49 <skarnet> the proper way of doing that is to have a device manager virtual, which can be implemented by mdev, mdevd or eudev.
2018-03-26 18:53:07 <skarnet> Do we have that?
2018-03-26 18:54:33 <jirutka> skarnet: sort of…
2018-03-26 18:55:48 <jirutka> skarnet: I’m not sure how to cleanly handle this, I have to think about it
2018-03-26 18:56:01 <skarnet> I just told you: a virtual
2018-03-26 18:56:29 <_ikke_> a virtual what?
2018-03-26 18:56:39 <skarnet> virtual package / functionality / ...
2018-03-26 18:56:58 <skarnet> just as "mta" or "smtpd" which can have several implementations
2018-03-26 18:57:12 <skarnet> it comes down to whether or not apk has that functionality
2018-03-26 18:57:24 <jirutka> skarnet: we have provides and provider_priority
2018-03-26 18:57:24 <skarnet> if it doesn't, then it can still be done, but will be hackish
2018-03-26 18:57:24 <_ikke_> skarnet: apk has provides
2018-03-26 18:57:54 <jirutka> skarnet: so we have support for virtual packages, but we don’t have “alternatives”
2018-03-26 18:58:04 <skarnet> yeah, and eudev's APKBUILD has: provides="udev=176"
2018-03-26 18:58:10 <skarnet> which is USELESS
2018-03-26 18:58:21 <skarnet> because it doesn't say that it conflicts with mdev
2018-03-26 18:59:31 <skarnet> jirutka: can you show me an example of 2 packages that provide an implementation of a virtual package? I'll look at how it's done and take it from there
2018-03-26 18:59:42 <jirutka> conflicts are easy, just declare depends="!eudev"
2018-03-26 19:00:08 <skarnet> well I can't exactly declare depends=!busybox-initscripts
2018-03-26 19:00:34 <jirutka> you can’t, mdev init script must be moved into separate pkg mdev-openrc
2018-03-26 19:00:38 <skarnet> yup
2018-03-26 19:00:51 <jirutka> skarnet: not now, I’d like to finish smthg now and IRC is starting to disturb me too much :)
2018-03-26 19:01:08 <skarnet> fine
2018-03-26 19:01:24 <skarnet> I'll just push what I have and come back for a -r1 later
2018-03-26 19:31:54 <nmeum> skarnet: I didn't fully read up on your conversation with jirutka but OpenRC provides a feature called feature service. We could make mdev a virtual service and renaming the existing mdev service therebe allowing different mdev implementions to be used
2018-03-26 19:32:13 <nmeum> *rename
2018-03-26 19:32:16 <nmeum> *thereby
2018-03-26 19:32:53 <_ikke_> Can someone apply S-changes-requested? https://github.com/alpinelinux/aports/pull/3734
2018-03-26 19:33:07 <skarnet> nmeum: that would be great indeed! However, busybox-initscripts would still have to be edited to stop hardcoding the mdev invocation.
2018-03-26 19:34:54 <terra> Guy is it usual that a new aport request hadn't reviewed yet for 3+ weeks?
2018-03-26 19:35:00 <terra> *Guys
2018-03-26 19:35:35 <nmeum> yes, we only have very few people reviewing PRs currently
2018-03-26 19:35:39 <_ikke_> terra: We're a bit backlogged
2018-03-26 19:36:17 <terra> ok, let me keep my hopes fresh then.
2018-03-26 19:36:23 <nmeum> skarnet: in which way is it hardcoded?
2018-03-26 19:36:25 <_ikke_> terra: link/
2018-03-26 19:36:28 <_ikke_> ?
2018-03-26 19:37:37 <skarnet> nmeum: https://git.alpinelinux.org/cgit/aports/tree/main/busybox-initscripts/mdev.initd
2018-03-26 19:37:50 <terra> _ikke_: https://lists.alpinelinux.org/alpine-aports/5275.html
2018-03-26 19:39:10 <terra> I think I will separate the "groovymame" related packages
2018-03-26 19:39:21 <terra> *subpackages
2018-03-26 19:39:22 <skarnet> I can easily provide a mdevd.initd, but it won't be the default, and if it's openrc-add'd, then mdev needs to be openrc-del'd
2018-03-26 19:40:05 <nmeum> skarnet: if we make mdev a virtual service and rename that runscript it won't be invoked in the first place
2018-03-26 19:40:53 <skarnet> it's already the "dev" virtual service
2018-03-26 19:41:02 <nmeum> ah
2018-03-26 19:41:03 <nmeum> indeed
2018-03-26 19:41:04 <skarnet> My point is, things need to not break because it's a vital service
2018-03-26 19:41:16 <skarnet> it runs early, in rc.sysinit
2018-03-26 19:41:22 <_ikke_> terra: Why this construct? install -D -m755 mamearcade "$subpkgdir"/usr/bin/groovyarcade || install -D -m755 mamearcade64 "$subpkgdir"/usr/bin/groovyarcade
2018-03-26 19:41:51 <_ikke_> terra: depends on the arch which is available?
2018-03-26 19:41:57 <terra> _ikke_: it outs different executables depends on arch
2018-03-26 19:42:19 <terra> _ikke_: yep
2018-03-26 19:45:40 <jirutka> ncopa: https://github.com/alpinelinux/aports/pull/3570#discussion_r177177113
2018-03-26 19:49:03 <_ikke_> terra: this is a bit ouf of my league to properly review
2018-03-26 19:49:39 <terra> _ikke_: thanks anyway. Probably I'll file a new PR.
2018-03-26 20:09:17 <bernhardgruen[m]> How could the process of reviewing and accepting of PR get improved? At the moment it takes IMHO way to long sometimes. For testing I propose to accept changes (from the maintainer of a package) directly. For community and main this won't work. But there could be some acceptance process where maintainers and contributors of dependant packages vote pro/con the merge.
2018-03-26 20:09:18 <bernhardgruen[m]> This way some kind of peer reviewing takes place and the decision process gets faster. What do you think about it?
2018-03-26 20:10:21 <bernhardgruen[m]> How does the current reviewing process work? What needs to be done and checked?
2018-03-26 20:18:37 <_ikke_> https://github.com/alpinelinux/aports/pull/2300 Does this need a duplicate tag? (or just close?)
2018-03-26 20:25:41 <andypost> _ikke_, looks better to close cos there's newer version already in testing
2018-03-26 20:26:48 <_ikke_> andypost: right, that's what I was thinking
2018-03-26 20:37:17 <_ikke_> Doesn't default_dev handle this? Or am I missing something? https://github.com/alpinelinux/aports/pull/3287/files#diff-78f6410c7c2ca08639eb40212688aafaR28
2018-03-26 21:21:13 <bernhardgruen[m]> andypost: you marked my PR (boost) as duplicate. And also wrote that it uses the official sources. Should I just close my PR?
2018-03-26 21:31:02 <nmeum> bernhardgruen[m]: it's an interesssting idea. we definitly need to figure how to cope with the increasing number of unreviewed prs somehow. stuff like that is imho better discussed on the ml though
2018-03-26 21:35:58 <bernhardgruen[m]> Right, I will write my idea on the ML tomorrow morning (German Time). I would be happy if I could help reviewing PRs. (Also because I have some packages and upgrades that I would like to see in 3.8)
2018-03-26 22:01:18 <jirutka> bernhardgruen[m]: let’s mention such PRs here
2018-03-26 22:01:26 <jirutka> bernhardgruen: that you’d like to merge before 3.8
2018-03-26 22:03:50 <andypost> bernhardgruen[m], I'm not sure) I think better I will close my PR cos travis still fail
2018-03-26 22:04:41 <jirutka> andypost: which PR?
2018-03-26 22:04:52 <andypost> jirutka, https://github.com/alpinelinux/aports/pull/2960
2018-03-26 22:05:29 <andypost> jirutka, https://github.com/alpinelinux/aports/pull/3481 use valid source of download
2018-03-26 22:05:30 <jirutka> andypost: Travis fails due to time limit
2018-03-26 22:05:46 <andypost> I could update source as well
2018-03-26 22:06:21 <jirutka> +1 for changing source out of FS
2018-03-26 22:06:26 <jirutka> s/FS/SF/
2018-03-26 22:08:02 <jirutka> This `	https://dl.bintray.com/boostorg/release/$pkgver/source/"$pkgname"_"$_pkgver".tar.bz2` is really ugly
2018-03-26 22:08:27 <andypost> jirutka, which syntax is preferred? ${pkgname}_$_pkgver.tar.bz2
2018-03-26 22:08:40 <jirutka> so I suggest to update source in the first PR (Andy’s) and merge
2018-03-26 22:08:44 <jirutka> andypost: that
2018-03-26 22:09:35 <jirutka> not needed to mention removal of obsolete patch in commit title, just mention changed source
2018-03-26 22:11:07 <andypost> jirutka, pushed - is this fine?
2018-03-26 22:11:41 <jirutka> andypost: yeah
2018-03-26 22:14:18 <jirutka> now we need to trigger rebuild of all packages that depend on boost
2018-03-26 22:14:30 <jirutka> (i.e. bump their pkgrel)
2018-03-26 22:16:50 <andypost> jirutka, it needs but for they could fail to build like https://github.com/alpinelinux/aports/pull/3480
2018-03-26 22:17:35 <jirutka> well, and upgrade/fix those that are not compatible with new boost
2018-03-26 22:19:44 <andypost> jirutka, so the order should be upgrade first, then separate PR with bumps & fixes?
2018-03-26 22:21:05 <jirutka> andypost: since Boost fails to build on Travis due to timeout anyway, it’d be better to add bumps & fixes into the same PR, to make it more clear/easy for us
2018-03-26 22:21:32 <andypost> jirutka, then let''s get 3480 in first
2018-03-26 22:21:37 <jirutka> andypost: and in case of existing PRs with fixes, just mention them in the boost PR to not forget about them
2018-03-26 22:22:07 <jirutka> andypost: it will need to rebuild _after_ merging boost anyway, so I’d do it in single round
2018-03-26 22:22:31 <andypost> ah yep, so I can skip bump
2018-03-26 22:22:57 <jirutka> andypost: upgrades of such huge pkgs must be prepared locally
2018-03-26 22:23:04 <andypost> 
ACTION cheching PRs for dependent packages

2018-03-26 22:23:09 <jirutka> to verify what builds, what must be fixed etc.
2018-03-26 22:24:05 <jirutka> uff, there are gazillion pkgs depending on boost :(
2018-03-26 22:29:45 <andypost> jirutka, I see 16 only https://pkgs.alpinelinux.org/package/edge/main/x86_64/boost
2018-03-26 22:32:28 <jirutka> andypost: it has many subpackages
2018-03-26 22:32:35 <jirutka> andypost: this is more complicated, give me a sec
2018-03-26 22:32:52 <jirutka> andypost: I will query it from pkgs.a.o DB, that’s easier
2018-03-26 22:33:20 <andypost> ohh.. I see now
2018-03-26 22:35:38 <jirutka> 
ACTION it would be much easier with *real* SQL DB, not that SQLite3 toy >_<

2018-03-26 22:40:08 <jirutka> andypost: okay, these depend on some boost’s lib: http://tpaste.us/X6NE
2018-03-26 22:42:21 <andypost> jirutka, but what about this 23 https://pkgs.alpinelinux.org/package/edge/main/x86_64/boost-dev
2018-03-26 22:42:40 <andypost> at least libstaroffice is not listed in you excerpt
2018-03-26 22:43:35 <jirutka> hm, it does not dynamically link any boost’s lib
2018-03-26 22:44:14 <jirutka> I dunno, maybe it links some boost’s libs statically?
2018-03-26 22:45:37 <jirutka> I don’t know if we should rebuid them too
2018-03-26 22:46:01 <andypost> looks very strange, prabebly it points just headers dependency
2018-03-26 22:46:20 <jirutka> btw put all pure pkgrel bumps into single commit
2018-03-26 22:46:50 <andypost> jirutka, in the same commit as upgrade?
2018-03-26 22:47:40 <andypost> or second commit to PR?
2018-03-26 22:48:28 <jirutka> no, in separate following the upgrade; if we need to revert upgrade for some reason – pkgrel _technically_ should not be decreased
2018-03-26 23:01:58 <andypost> jirutka, pushed
2018-03-26 23:02:31 <jirutka> andypost: have you verified that all of them build with new boost?
2018-03-26 23:03:50 <andypost> jirutka, not cos they download dependencies prom repo, no idea how to check
2018-03-26 23:04:53 <jirutka> andypost: well, first build boost locally, add your ~/packages/main to /etc/apk/repositories, apk update and then build pkgs, they should pick your upgraded boost
2018-03-26 23:07:10 <andypost> jirutka, started build... meanwhile please check https://github.com/alpinelinux/aports/pull/3779
2018-03-26 23:08:23 <jirutka> andypost: 3779 is okay, just merge it; and better to bump pkgrel so it will get into pkgs.a.o
2018-03-26 23:12:38 <andypost> done
2018-03-26 23:36:36 <andypost> 
ACTION finished to build boost

2018-03-26 23:38:23 <andypost> impressive "boost-dev*: Package size: 205.9 MB"
2018-03-27 11:21:27 <andypost> how long build logs are stored?
2018-03-27 11:21:56 <andypost> ncopa, I filed upstream fix but now logs are gone https://github.com/mkoppanen/imagick/pull/232
2018-03-27 11:23:50 <clandmeter> andypost, check the log dir.
2018-03-27 11:24:24 <andypost> clandmeter, it has only latest build log( http://build.alpinelinux.org/buildlogs/build-edge-x86/community/php7-imagick/
2018-03-27 11:24:33 <clandmeter> correct
2018-03-27 11:24:38 <clandmeter> why would it store older logs?
2018-03-27 11:25:23 <andypost> sure, no reason.. but now I have no idea where to try reproduce
2018-03-27 11:25:42 <clandmeter> build it local without patch?
2018-03-27 11:25:57 <andypost> clandmeter, it fails only on x86
2018-03-27 11:26:24 <clandmeter> how do you build locally?
2018-03-27 11:26:33 <clandmeter> you are using lxc?
2018-03-27 11:26:50 <andypost> I'm using docker image so x86_64
2018-03-27 11:27:19 <clandmeter> hmm, i have no idea with docker.
2018-03-27 11:27:40 <clandmeter> but with lxc you can have both x86 and x86_64
2018-03-27 11:28:10 <clandmeter> i guess the same should apply to docker.
2018-03-27 11:30:02 <andypost> 
ACTION mostly vbox user so much familar with lxc(

2018-03-27 11:30:45 <clandmeter> well, vbox is a completely different animal.
2018-03-27 11:31:00 <clandmeter> what does your host run?
2018-03-27 11:31:10 <andypost> ubuntu
2018-03-27 11:33:48 <andypost> looks I need virtual iso
2018-03-27 11:33:59 <clandmeter> andypost, the only "complicated" part with lxc is networking.
2018-03-27 11:34:22 <clandmeter> the bridge setup is most simple.
2018-03-27 11:35:24 <clandmeter> we added support for this into dnsmasq to support lxc and xen.
2018-03-27 11:43:35 <clandmeter> but that doesnt really help you when you are on ubuntu.
2018-03-27 11:43:45 <clandmeter> andypost, ill run the build for you.
2018-03-27 11:46:24 <andypost> clandmeter, thanx, I'm still fighting with boost PR
2018-03-27 11:47:36 <andypost> I found https://wiki.alpinelinux.org/wiki/Howto-lxc-simple will try later cos servers are loaded with builds
2018-03-27 11:49:05 <clandmeter> docs seem a bit outdated.
2018-03-27 12:15:46 <andypost> clandmeter, thanks a lot for commenting, vbox also works but something weird with network access from host
2018-03-27 12:21:24 <andypost> please review https://github.com/alpinelinux/aports/pull/3783 I did test locally but better have another eyes on it
2018-03-27 12:22:44 <jirutka> [ANN] I made another script alpine-make-* script, this time for creating customized Alpine rootfs for containers https://github.com/jirutka/alpine-make-rootfs
2018-03-27 13:13:43 <jirutka> (and also added some appealing example https://github.com/jirutka/alpine-make-rootfs#examples)
2018-03-27 14:40:46 <jirutka> leitao: hmm, Crystal is new for me too; it’s quite a new language
2018-03-27 14:41:26 <leitao> jirutka, how does it differ from Rust and Golang?
2018-03-27 14:41:42 <jirutka> they have this wiki page with projects using Crystal: https://github.com/crystal-lang/crystal/wiki/Used-in-production
2018-03-27 14:42:53 <leitao> jirutka, yea, still have a few packages. Any of those are in Alpine at this moment?
2018-03-27 14:44:30 <jirutka> leitao: Crystal is like Ruby with static typing, powerful (global!) type inference, flexible macro system, built-in support for bindings to C, many perf optimizations built in the lang (e.g. struct type is allocated on stack, class is allocated on heap, enum maps closely to C enum etc). and compiled to native binary
2018-03-27 14:44:51 <jirutka> leitao: not yet, I’ve just packaged Crystal itself, next packages will follow
2018-03-27 14:45:52 <leitao> jirutka, right. I suppose it will not hurt us a lot if porting crystal to ppc64le does not become a high priority in the toolchain team, right?
2018-03-27 14:46:12 <jirutka> leitao: Crystal’s syntax is more-or-less superset of Ruby 1.9 syntax, so it’s very familiar for Ruby devs
2018-03-27 14:47:28 <jirutka> leitao: I’m personally very excited from Crystal and what they achieved; it really has feel of dynamic scripting lang, but actually it’s compiled to susprisingly effective native code
2018-03-27 14:47:43 <jirutka> leitao: its performance is comparable even with Rust and in many tests way better than Go
2018-03-27 14:47:51 <jirutka> (btw this just demonstrace how shitty Go is)
2018-03-27 14:48:33 <leitao> jirutka, yea, it seems an interesting language.
2018-03-27 14:49:43 <leitao> Anyway, I will need to keep an eye open on the community adoption in order to help to prioritize investment on it internally.
2018-03-27 14:49:57 <leitao> Probably something for the second half.
2018-03-27 14:51:23 <jirutka> it’s not a system programming language as Rust, it has garbage collector, so closer to Go, but in comparison with Go it provides more high level constructs, incomparable more powerful type system, cooperation with C world (including dynamic linking), better runtime etc.
2018-03-27 14:54:49 <jirutka> I’d say that ppl who come to Go from dynamic langs b/c of performance and “single binary” mantra would pick Crystal immediately instead of Go, if they know about it
2018-03-27 14:56:11 <jirutka> leitao: "it will not hurt us a lot if porting crystal to ppc64le does not become a high priority in the toolchain team, right?" … yeah, there’s still no 1.0 release, so it’s probably not high priority for ppc64le
2018-03-27 14:59:38 <jirutka> leitao: it’d be nice if you let Crystal devs know that IBM is considering to help them with porting to ppc64le in some near future :)
2018-03-27 15:01:20 <mps> jirutka: no ; as the statement terminator, I'll stay with go despite the fact that I'm not go fan
2018-03-27 15:01:59 <jirutka> mps: lol…
2018-03-27 15:02:52 <jirutka> okay, I should add: for people who are not too strongly fixed to C-like syntax…
2018-03-27 15:03:10 <mps> ok, just kidding, who knows what I will do in future, especially far
2018-03-27 15:03:25 <jirutka> and Crystal (same as Ruby) do support ";", just we don’t use it, b/c it’s totally unnecessary code noise
2018-03-27 15:10:14 <mps> just looking to crystal first time, it looks like a perl to my 'perl hacker' eyes
2018-03-27 15:11:51 <jirutka> mps: yes, Ruby is quite influenced by Perl
2018-03-27 15:15:27 <mps> jirutka: yes, I know, because that crystal look fine to me
2018-03-27 15:16:12 <jirutka> I’m personally not fan of Perl, but some syntax perl-isms are really nice
2018-03-27 15:16:25 <mps> if you didn't mentioned go above, who knows when I will look at crystal, tnx
2018-03-27 15:16:43 <jirutka> you’re welcome! :)
2018-03-27 15:16:53 <andypost> jirutka, all packages are building fine with boost (few after updates/patches) but I stuck on last one - anytun
2018-03-27 15:17:58 <andypost> jirutka, looks project is not active last 2 years
2018-03-27 15:18:17 <jirutka> andypost: yeah, looks quite abandoned
2018-03-27 15:18:51 <andypost> jirutka, how to deal with it?
2018-03-27 15:19:10 <jirutka> andypost: how bad is it? can it be easily fixed to be compatible?
2018-03-27 15:20:09 <andypost> jirutka, it not clean to me cos it's about posic nitpicks https://github.com/alpinelinux/aports/pull/2960#issuecomment-376352698
2018-03-27 15:20:16 <andypost> *posix
2018-03-27 15:21:01 <andypost> maybe contact maintainer?
2018-03-27 15:21:45 <jirutka> yeah
2018-03-27 15:21:47 <jirutka> fcolista:
2018-03-27 15:22:04 <jirutka> and if he can’t or don’t want fix it, then move to unmaintained
2018-03-27 15:22:25 <jirutka> Fedora does not have package for anytun :/
2018-03-27 15:22:34 <jirutka> nor Arch
2018-03-27 15:23:12 <jirutka> it’s not even in Gentoo
2018-03-27 15:24:18 <jirutka> Debian has, but since it’s a museum, they don’t have this problem with new boost yet
2018-03-27 15:25:37 <andypost> "museum")))
2018-03-27 15:34:13 <ncopa2> andypost: so its only anytun that fails with boost 1.66?
2018-03-27 15:35:32 <jirutka> ncopa got forked!
2018-03-27 15:35:57 <_ikke_> lol
2018-03-27 15:45:32 <ncopa2> apparently the matrix bridge is broken
2018-03-27 15:47:53 <andypost> ncopa2, yes, just files last PR & rebased cos you bumped mongo
2018-03-27 15:48:47 <andypost> ncopa2, last PR is https://github.com/alpinelinux/aports/pull/3788 it require fresh boost
2018-03-27 15:59:43 <andypost> matrix work for me
2018-03-27 16:07:26 <skarnet> I wouldn't object to forking ncopa... more ncopas would be good for Alpine
2018-03-27 16:10:07 <jirutka> skarnet: :)
2018-03-27 16:35:57 <andypost> jirutka, anytun finally build just need to recombine patches
2018-03-27 16:36:35 <jirutka> andypost: perfect! :)
2018-03-27 16:51:22 <andypost> jirutka, better to create new PR or append commit to existing one?
2018-03-27 16:51:40 <jirutka> andypost: which PR?
2018-03-27 16:51:47 <andypost> jirutka, for boost
2018-03-27 16:51:56 <jirutka> andypost: append to existing
2018-03-27 16:51:56 <andypost> for anytun
2018-03-27 16:53:37 <andypost> jirutka, pushed
2018-03-27 16:54:30 <andypost> the saver is -DBOOST_SYSTEM_ENABLE_DEPRECATED
2018-03-27 17:21:03 <mkumatag> HI, I have question related to release process of certain package. Package name "Bird" - https://pkgs.alpinelinux.org/packages?name=bird&branch=edge present in edge release under testing repo, so I need this package to be included in numbered version of alpine, so can someone help me understanding the process required for the same?
2018-03-27 17:22:06 <_ikke_> mkumatag: Someone, usually the maintainer, needs to decide it's stable enough to move it out of testing
2018-03-27 17:23:40 <mkumatag> okay, I see "Francesco Zanini" as maintainer, not really sure how to get more information about this person!
2018-03-27 17:24:34 <ncopa2> mkumatag: does it work? is it packaged properly? (ie are files where they should etc) Is default config ok?
2018-03-27 17:24:37 <_ikke_> look up the package in the aports repo, the APKBUILD contains their e-mail address?
2018-03-27 17:25:47 <mkumatag> _ikke_: got it, thanks for the quick help..
2018-03-27 17:26:37 <_ikke_> Let the maintainer know whether it's working for you, that'll help
2018-03-27 17:33:27 <mkumatag> okay..
2018-03-27 17:33:51 <nmeum> jirutka ncopa2: iirc one of you has a script for bumping pkgrels of aports which need to be rebuild due to an sonamebump. would you mind sharing this script or do I need to write my own? :)
2018-03-27 17:35:08 <ncopa2> $ tpaste < rebuild-since
2018-03-27 17:35:08 <ncopa2> http://tpaste.us/dVb5
2018-03-27 17:35:16 <ncopa2> its a hack though
2018-03-27 17:35:43 <jirutka> please update it to not create separate commit for each pkg, it just creates a noise
2018-03-27 17:36:54 <jirutka> it does not resolve libs of particular pkg and its subpkgs
2018-03-27 17:37:18 <jirutka> that’s quite tricky with current tools, I usually connect to pkgs.a.o DB and use SQL for that…
2018-03-27 17:40:36 <ncopa2> i normally prefer to avoid commits which covers multiple apkbuilds since it tends to mess up things when backporting things to stable branches
2018-03-27 17:41:32 <jirutka> yes, normally
2018-03-27 17:41:45 <jirutka> but pure pkgrel bumps are something else
2018-03-27 17:42:03 <jirutka> it doesn’t make sense to backport pkgrel bump and you effectively cannot revert it either
2018-03-27 17:42:27 <ncopa2> but i guess making it easier for jirutka is more important that making it easy to maintain stable branches
2018-03-27 17:42:44 <jirutka> no
2018-03-27 17:43:01 <jirutka> making it easy maintain stable branches is ofc important
2018-03-27 17:43:21 <jirutka> but pkgrel bumps are irrelevant for stable branches
2018-03-27 17:43:24 <andypost> ncopa2, is there any policy which changes could/should be backported?
2018-03-27 17:43:44 <ncopa2> secfixes needs to be fixed in stable branches
2018-03-27 17:44:07 <jirutka> I mean, create single commit with pure pkgrel bumps, not single commit with both pkg upgrade and pkgrel bumps
2018-03-27 17:44:26 <ncopa2> we accept bugfixes to latest stable too
2018-03-27 17:44:29 <ncopa2> if needed
2018-03-27 17:44:56 <ncopa2> jirutka: that should work yes
2018-03-27 17:45:09 <andypost> jirutka, I totally agree - "bump commits" does not work for stable branches
2018-03-27 17:45:59 <jirutka> moreover, upgrades that require rebuilding other pkgs are basically litmus paper for that such upgrade should not be backported, b/c it means it’s not backward compatible
2018-03-27 17:46:21 <ncopa2> correct, we dont backport ABI breaking stuff
2018-03-28 06:18:08 <fcolista> andypost, jirutka : just read the backlog re anytun
2018-03-28 06:18:20 <fcolista> yeah, the project is pretty old
2018-03-28 06:18:35 <fcolista> seems that there's an ongoing project for rewriting it in GO
2018-03-28 06:18:40 <fcolista> https://git.spreadspace.org/anytun/
2018-03-28 06:20:11 <fcolista> but nice that you have it fixed
2018-03-28 06:20:13 <fcolista> good job!
2018-03-28 07:06:28 <andypost[m]> fcolista: looks in repo last activity is also 2 years old
2018-03-28 08:49:15 <fcolista> andypost[m], the new one is 4months old
2018-03-28 09:48:18 <ncopa2> im working on the boot upgrade
2018-03-28 09:48:20 <ncopa> i am working on the boots upgrade
2018-03-28 09:48:20 <ncopa2> boost*
2018-03-28 11:14:44 <ncopa> does this work now?
2018-03-28 11:23:46 <clandmeter> i can see you
2018-03-28 11:23:55 <clandmeter> if thats what you mean :)
2018-03-28 11:35:09 <_ikke_> me too
2018-03-28 11:36:05 <ncopa> good. that was what i meant :)
2018-03-28 12:00:11 <clandmeter> still a few minutes delay though.
2018-03-28 12:01:11 <clandmeter1> test
2018-03-28 12:20:28 <ncopa> the crystal lang looks promising
2018-03-28 13:25:59 <mps> ncopa: regarding crystal lang, jirutka pointed me to it yesterday and can't stop reading its docs ;)
2018-03-28 13:26:45 <jirutka> 
ACTION is so happy!

2018-03-28 13:28:39 <mps> jirutka: :) though I'm missing curly braces for code blocks :] but I hope after some time it would be overcomed by me
2018-03-28 13:33:58 <nmeum> kaniini: regarding openrc-subpackages I created a PR adding one to all packages shipping runscripts https://github.com/alpinelinux/aports/pull/3803 if we really want to do this i would want to merge this asap since rebasing this is a pain
2018-03-28 14:19:13 <andypost> ncopa, you missed https://github.com/alpinelinux/aports/pull/3783
2018-03-28 14:35:21 <ncopa> whoops
2018-03-28 14:35:50 <ncopa> ok, i'll try fix it
2018-03-28 15:04:54 <jirutka> why did you merged ripgrep?!
2018-03-28 15:04:56 <jirutka> ncopa: ^
2018-03-28 15:05:00 <jirutka> ncopa: have you read comments?!
2018-03-28 15:05:46 <jirutka> aha, there are no comments… probably contributor opened new PR again…
2018-03-28 15:05:55 <jirutka> anyway, I’m gonna revert it
2018-03-28 15:05:56 <jirutka> it’s wrong
2018-03-28 15:06:23 <jirutka> it does not even use cargo --locked
2018-03-28 15:07:02 <ncopa> because there was commits after last comments
2018-03-28 15:07:09 <ncopa> https://github.com/alpinelinux/aports/pull/1250
2018-03-28 15:07:15 <ncopa> can you fix it?
2018-03-28 15:07:50 <ncopa> i wanted to clean up some of the older PRs
2018-03-28 15:09:12 <jirutka> not now
2018-03-28 15:09:26 <jirutka> we have to decide how to properly package rust aports
2018-03-28 15:09:37 <jirutka> I’ve opened this topic long time ago but zero input from others
2018-03-28 15:09:43 <ncopa> sorry
2018-03-28 15:10:21 <jirutka> and there were more problems with rust, how it link dynamic libraries, I don’t know if it’s still problem or already resolved
2018-03-28 15:10:31 <ncopa> i dont understand the problem or what alternatives we have
2018-03-28 15:10:34 <ncopa> and i dont understand how cargo works or is supposed to work
2018-03-28 15:11:16 <jirutka> we must discuss it, but not this week
2018-03-28 15:11:17 <ncopa> we just reject all rust related PRs til we sorted things out?
2018-03-28 15:12:26 <jirutka> I’d just keep them open until we sort things out
2018-03-28 15:12:32 <jirutka> some basic info https://github.com/alpinelinux/aports/blob/8f4fbdb510172d414d1f78fd08b013498c313cc3/community/cargo/APKBUILD#L16-L24
2018-03-28 15:13:14 <ncopa> ok
2018-03-28 15:14:15 <jirutka> also I didn’t want to add rust pkgs until it’s somehow stabilized – dynamic musl is still not supported by upstream, there are also problems with packing, we have older cargo version now, and it’s so frustrating experience that i was thinking about giving it up
2018-03-28 15:15:01 <ncopa> this rust business have only been pain
2018-03-28 15:15:02 <ncopa> we still dont have other arches than x86_64
2018-03-28 15:15:07 <jirutka> yes, and this
2018-03-28 15:15:35 <ncopa> merging PRs is currently a frustrating experience for me so i am thinking about giving that up...
2018-03-28 15:15:59 <jirutka> ?
2018-03-28 15:16:43 <jirutka> clandmeter: ncopa: it seems that crystal works on Scaleway armhf machine (armv7), but fails on ours (armv8) o.O how’s that possible?
2018-03-28 15:17:37 <clandmeter> what is the error on aarch64?
2018-03-28 15:17:46 <jirutka> not aarch64, it works on aarch64
2018-03-28 15:18:07 <jirutka> hmm, I’m running 3.7 on our arm, not edge… that may be the difference
2018-03-28 15:18:09 <jirutka> I missed that
2018-03-28 15:18:24 <clandmeter> why do you mention armv8?
2018-03-28 15:18:40 <jirutka> clandmeter: https://github.com/crystal-lang/crystal/pull/5862#issuecomment-375982400
2018-03-28 15:18:45 <ncopa> same binary?
2018-03-28 15:19:11 <jirutka> clandmeter: b/c uname -m in that LXC container returns armv8l
2018-03-28 15:19:48 <jirutka> clandmeter: aarch64 container identifies itself as aarch64
2018-03-28 15:19:59 <clandmeter> we have 2
2018-03-28 15:20:09 <clandmeter> but only one is compatible with arm32
2018-03-28 15:20:19 <jirutka> ncopa: yes, same binary… or at least I hope so… I’m actually not sure now, b/c I have many binaries here from many tries
2018-03-28 15:20:25 <clandmeter> thunderx is not armv7 compatible.
2018-03-28 15:20:43 <jirutka> 172.16.3.55
2018-03-28 15:20:49 <clandmeter> ill check
2018-03-28 15:21:11 <jirutka> hm, I think that real problem is that I cross-compiled on edge, but forgot that I have 3.7 in armhf container :(
2018-03-28 15:21:16 <jirutka> that’s stupid from me
2018-03-28 15:21:38 <clandmeter> that one is xgene i think.
2018-03-28 15:21:40 <clandmeter> should work
2018-03-28 15:21:49 <jirutka> but still… cross-compiled binary works, but the one I build using that cross-compiled binary does not
2018-03-28 15:21:52 <jirutka> this is weird
2018-03-28 15:22:32 <jirutka> eh, and I actually run edge here… why there’s 3.7.0 in /etc/os-release?!
2018-03-28 15:22:51 <nmeum> ncopa: what makes merging PRs frustrating for you?
2018-03-28 15:23:02 <jirutka> and in /etc/alpine-release
2018-03-28 15:24:13 <jirutka> aha, it is the same on my edge builder… I’m confused now
2018-03-28 15:24:14 <ncopa> there are too many of them and they often needs fix
2018-03-28 15:24:38 <ncopa> jirutka: those files are only touched when there are release. we havent done any releases in edge since 3.7-stable branched
2018-03-28 15:24:42 <ncopa> git log main/alpine-base gives you the history
2018-03-28 15:25:12 <jirutka> I see, I don’t know why I thought that it’s otherwise :(
2018-03-28 15:25:48 <ncopa> i guess we could update it to 3.8.0_alpha1 or similar
2018-03-28 15:26:24 <bernhardgruen> If a PR needs a fix I think the best way is to comment the PR.
2018-03-28 15:27:03 <bernhardgruen> To be true - I wouldn't accept PRs from too many sources (mail, mailing list, github, ...). This makes things complicated.
2018-03-28 15:28:04 <jirutka> bernhardgruen: that’s why I completely ignore patchwork (ML)… it’s unusable crap, especially for reviews or basically anything
2018-03-28 15:28:07 <ncopa> and close after a while without any response?
2018-03-28 15:28:10 <bernhardgruen> Oh - I forgot to write about my idea how to improve the whole process to the ML. guilty - sorry
2018-03-28 15:28:48 <bernhardgruen> ncopa, yeah - I would auto-close them after 2 weeks without response.
2018-03-28 15:29:21 <jirutka> bernhardgruen: without response from contributor to feedback… right?
2018-03-28 15:29:23 <nmeum> I don't think that's a good idea. especially when the pr fixes an issue in an apkbuild
2018-03-28 15:29:26 <bernhardgruen> I also would reject packages that don't declare a maintainer with a valid mail address, btw. (there are many packages with "none" as maintainer.
2018-03-28 15:29:38 <jirutka> bernhardgruen: it’d be very rude to close after 2 week w/o response from us
2018-03-28 15:29:55 <bernhardgruen> jirutka, right. Both sides have to do their work.
2018-03-28 15:30:56 <bernhardgruen> nmeum, if a PR fixes an issue then a merge would be possible, right?
2018-03-28 15:31:05 <jirutka> bernhardgruen: but it’s not contributors fault that we didn’t look at it until 2 weeks, so definitely not close; just when waiting for feedback from contrib, so tag S-changes-requested
2018-03-28 15:31:18 <jirutka> and we should also add some tag signalizing waiting for any other feedback
2018-03-28 15:32:10 <bernhardgruen> jirutka, No wrong. I wouldn't close PRs that are older than 2 weeks. I would close PRs where some committer gave feedback but the author did not respond.
2018-03-28 15:32:57 <ncopa> can this be closed now that we have llvm5? https://github.com/alpinelinux/aports/pull/1574
2018-03-28 15:33:00 <jirutka> ncopa: clandmeter: okay, now I have same Alpine version (latest edge), same binary and it really crashes on our machine and works so far on Scaleway
2018-03-28 15:33:25 <ncopa> i agree on that, if we auto close it would be due to lack of requested response
2018-03-28 15:33:37 <bernhardgruen> In best case (I assume this will be the case for most packages) the whole process gets easier for both sides.
2018-03-28 15:33:42 <jirutka> ncopa: clandmeter: build is still running, but it’s running fore more than 10 minutes, it crashed on our machine after just 2 minutes
2018-03-28 15:34:00 <ncopa> jirutka: welcome to the wonderful world of arm :)
2018-03-28 15:34:13 <jirutka> 
ACTION cries

2018-03-28 15:34:33 <ncopa> jirutka: maybe ask nsz for help
2018-03-28 15:34:52 <clandmeter> +1
2018-03-28 15:35:06 <jirutka> who’s nsz?
2018-03-28 15:35:12 <clandmeter> #musl
2018-03-28 15:35:28 <jirutka> aha
2018-03-28 15:35:54 <ncopa> musl dev
2018-03-28 15:35:56 <jirutka> I’m not even sure if it’s related to musl
2018-03-28 15:36:14 <jirutka> maybe it would not work even on gnu on that machine ?
2018-03-28 15:36:20 <clandmeter> yes, but he knows arm
2018-03-28 15:37:18 <jirutka> clandmeter: do our armhf builders run on the same machine and configuration as the container you gave me?
2018-03-28 15:37:48 <clandmeter> should be
2018-03-28 15:38:41 <clandmeter> Linux build-edge-armhf 4.4.19 #2 SMP Mon Sep 5 11:05:13 GMT 2016 armv8l GNU/Linux
2018-03-28 15:39:06 <jirutka> why’s there GNU/Linux?
2018-03-28 15:40:06 <jirutka> btw the error is: Invalid memory access (signal 7) at address 0xab5cd28b
2018-03-28 15:48:37 <jirutka> there’s one additional difference, LXC container, but IMO this can’t cause such thing, can it?
2018-03-28 15:58:54 <jirutka> sigh, I should really not work today… ofc there’s one more important difference – kernel; we have 4.4.19, scaleway 4.4.122-mainline
2018-03-28 16:01:05 <jirutka> clandmeter: why’s there such old kernel? could you update it?
2018-03-28 16:05:18 <bernhardgruen> jirutka, could this have something to do with 'lxc.cgroup.memory.limit_in_bytes = XXXM'? I know similar messages from java if it tries to use the amount of memory it sees (which is more than configured via cgroups)
2018-03-28 16:05:43 <jirutka> bernhardgruen: hmm, I dunno… clandmeter ?
2018-03-28 16:28:39 <andypost> jirutka, I noticed many times about kernel, travis using 4.4.0-101-generic and ubuntu 14(
2018-03-28 16:29:14 <jirutka> andypost: yeah, environment on Travis is outdated as hell :/
2018-03-28 16:30:47 <andypost> btw that's the main pita with docker... when someone using to start binaries build with 4.4 on 3.8 kernel
2018-03-28 16:31:11 <jirutka> ?
2018-03-28 16:31:18 <jirutka> isn’t that just problem with glibc?
2018-03-28 16:31:54 <jirutka> I’m running even very old kernels on some machines and don’t have any problem with compatibility tet
2018-03-28 16:31:57 <jirutka> yet
2018-03-28 16:32:15 <andypost> no, I faced it each month but each time for different binaries
2018-03-28 16:34:05 <andypost> with php the /dev/urandom is most common, so they used to fix it in language level(
2018-03-28 16:39:33 <jirutka> huh, I got Out of memory error on Freescale
2018-03-28 16:39:48 <jirutka> I have to enable swap
2018-03-28 16:39:58 <jirutka> 2 GiB of memory is not enough for optimized build
2018-03-28 16:41:53 <jirutka> s/Freescale/Scaleway/
2018-03-28 16:42:50 <andypost> ncopa, https://github.com/alpinelinux/aports/pull/2960 could be closed?
2018-03-28 16:49:32 <jirutka> i was wrong, crystal is already built (yay!), tests needed more RAM
2018-03-28 17:21:04 <andypost> jirutka, why not change travis to use "dist: xenial"? it has 4.13.0-1011-gcp kernel
2018-03-28 17:21:25 <jirutka> andypost: i didn’t know that they finally provide newer dist
2018-03-28 17:21:45 <andypost> jirutka, just tested it https://travis-ci.org/alpinelinux/aports/builds/359461399
2018-03-28 17:22:15 <andypost> 
ACTION diggin, probably it could use both

2018-03-28 17:38:00 <andypost> jirutka, this looks better https://github.com/alpinelinux/aports/pull/3807
2018-03-28 17:38:24 <jirutka> andypost: why?
2018-03-28 17:38:36 <andypost> cos both versions tested
2018-03-28 17:39:07 <jirutka> andypost: we have limited resources on Travis and this is IMO just waste of them
2018-03-28 17:39:29 <jirutka> andypost: I bet that 99 % of builds would not be affected by different kernel
2018-03-28 17:39:52 <andypost> git it, makes a lot of sense
2018-03-28 17:40:03 <andypost> *got
2018-03-28 17:40:24 <jirutka> git it is also good! +1
2018-03-28 17:56:08 <andypost> looks travis starts to hang now(
2018-03-28 18:00:54 <jirutka> andypost: hang?
2018-03-28 18:00:57 <andypost> jirutka, https://github.com/alpinelinux/aports/pull/3806
2018-03-28 18:01:17 <jirutka> andypost: that’s because of FTP
2018-03-28 18:01:19 <jirutka> donjt use FTP
2018-03-28 18:01:50 <jirutka> IMO we should hard-disable ftp:// in source
2018-03-28 18:02:16 <andypost> no, previous https://travis-ci.org/alpinelinux/aports/builds/359469176?
2018-03-28 18:02:56 <kaniini> and if there's no other choice?
2018-03-28 18:03:36 <jirutka> kaniini: no other choice? in 2018?
2018-03-28 18:05:04 <bernhardgruen[m]> FTP could be realised as an option which must be set if one has no other choice. But I doubt there is any current software that is only available via FTP.
2018-03-28 18:05:38 <andypost> jirutka, looks there's no other options for freetds(
2018-03-28 18:06:42 <bernhardgruen[m]> There is a girl repository
2018-03-28 18:06:50 <bernhardgruen[m]> Whoops s/Girl/git
2018-03-28 18:06:54 <jirutka> https://github.com/FreeTDS/freetds/releases
2018-03-28 18:07:11 <andypost> date is 2016
2018-03-28 18:08:49 <jirutka> sigh, another upstream that don’t know what the hell are git tags for :(
2018-03-28 18:08:54 <bernhardgruen[m]> There is no newer release
2018-03-28 18:09:33 <jirutka> https://github.com/FreeTDS/freetds/issues/135
2018-03-28 18:10:43 <jirutka> https://github.com/rails-sqlserver/tiny_tds/pull/384/files
2018-03-28 18:16:13 <andypost> updated but there's another hanging https://travis-ci.org/alpinelinux/aports/builds/359493285
2018-03-28 18:18:18 <jirutka> andypost: this one is bad, that’s problem on Travis infra :(
2018-03-28 18:18:43 <jirutka> I’d give it few hours and if it will continue hanging, revert back
2018-03-28 18:23:13 <bernhardgruen[m]> Would it be an option to use another Build Service? I read a few days ago that Gitlab.com has it's own CI and they offer free build time for open source projects.
2018-03-28 18:25:26 <hs3dUBwdmCjy> isn't gcc mostly on ftp?
2018-03-28 18:25:49 <hs3dUBwdmCjy> (including binutils/gdb and all that stuff)
2018-03-28 18:26:50 <andypost> bernhardgruen[m], how many runs they give?
2018-03-28 18:26:53 <jirutka> hs3dUBwdmCjy: no, it’s both on ftp and http
2018-03-28 18:27:24 <jirutka> bernhardgruen[m]: IIRC you can’t use GitLab CI as external CI
2018-03-28 18:27:26 <hs3dUBwdmCjy> in the apk we have ftp for gcc
2018-03-28 18:27:55 <hs3dUBwdmCjy> s/apk/APKBUILD
2018-03-28 18:27:55 <bernhardgruen[m]> andypost: don't really know.
2018-03-28 18:28:28 <jirutka> bernhardgruen[m]: there are many other options, but the last time I checked it, I didn’t find anything better (but some does not clearly specify what limits they have)
2018-03-28 18:28:33 <bernhardgruen[m]> Jirutka, with the new version this should be possible according to their release notes.
2018-03-28 18:30:54 <bernhardgruen[m]> Is it possible to run travis runner inside a Docker system? I currently have some unused x86_64 hardware in our data center.
2018-03-28 18:31:34 <jirutka> bernhardgruen[m]: Travis is not good for self hosting
2018-03-28 18:33:51 <bernhardgruen[m]> We use Jenkins and Gitlab CI for our systems. I currently also review Drone CI.
2018-03-28 18:34:08 <jirutka> bernhardgruen[m]: unfortunately I don’t know about any CI software I’d be satisfied with; Piper CI (built by my student) may be in future (https://github.com/francma/piper-ci), currently maybe Buildbot may be usable
2018-03-28 18:35:36 <jirutka> bernhardgruen[m]: we use GitLab CI at faculty, just b/c we already use GitLab (I’ve started with it many many years ago in times when it was not bloatware as todays); and before that Jenkins, that I really hated
2018-03-28 18:37:33 <andypost> jirutka, latest releases of gitlab-runner are not bound to gitlab and could be used easily
2018-03-28 18:37:59 <bernhardgruen[m]> I quite like Gitlab CI. It is far easier to use than Jenkins. But yeah Gitlab is fatware.
2018-03-28 18:38:39 <jirutka> andypost: how it can not be bound to GitLab? gitlab-runner is just… a runner, GitLab do all coordination work and also provides UI for users
2018-03-28 18:38:45 <bernhardgruen[m]> Anyway what is needed for a build of an aport? Not much from my knowledge. I currently also build apks with CI.
2018-03-28 18:39:23 <jirutka> bernhardgruen[m]: you can see it in alpine aports repo, directory .travis; it’s simple
2018-03-28 18:41:12 <andypost> 2k minutes per month for free, not so much https://about.gitlab.com/pricing/#saas
2018-03-28 18:43:04 <andypost> jirutka, is it fine to update & change URL in same commit? https://github.com/alpinelinux/aports/pull/3806
2018-03-28 18:43:28 <jirutka> andypost: yes
2018-03-28 18:44:43 <bernhardgruen[m]> Really not much - 2k minutes
2018-03-28 18:45:03 <jirutka> andypost: I don’t know how many we use on Travis; Travis has different accounting
2018-03-28 18:46:10 <jirutka> andypost: it should be probably possible to information about past builds from Travis API and count it
2018-03-28 18:50:07 <jirutka> the biggest problem we currently have with Travis is limit 50 minutes per build, bigger software needs more time
2018-03-28 18:52:35 <andypost> jirutka, sometimes tests running longer then build
2018-03-28 19:37:06 <andypost> jirutka, better to accept it asap & backport https://github.com/alpinelinux/aports/pull/3810
2018-03-29 13:30:21 <ncopa> from next week i will start set up builders for v3.8
2018-03-29 13:30:25 <ncopa> we should stop adding new stuff from next week
2018-03-29 13:30:38 <ncopa> and try fix the things we have
2018-03-29 13:31:41 <_ikke_> feature freeze
2018-03-29 13:41:54 <jirutka> xentec: Shiz: how it looks with LLVM 6?
2018-03-29 13:43:21 <ncopa> andypost: whats the status of php 7.2?
2018-03-29 16:43:21 <andypost> ncopa, php 7.2 90% ready, modernization got split to not mess with upgrade https://github.com/alpinelinux/aports/pull/3784
2018-03-29 16:44:43 <andypost> and I gonna accept https://github.com/alpinelinux/aports/pull/1572 before that
2018-03-29 16:45:36 <andypost> just have no time yet
2018-03-29 16:52:26 <andypost> jirutka, your comment about priority on https://github.com/alpinelinux/aports/pull/1572 does it means to update all packages?
2018-03-29 17:19:50 <jirutka> andypost: no…?
2018-03-29 17:36:58 <andypost> jirutka, I mean php-common required by a lot of packages
2018-03-29 21:31:13 <andypost> any idea why build fails to fetch packages?
2018-03-29 21:32:55 <Aerdan[m]> ollieparanoid: jsyk, the raspi nonfree firmware repo removed brcm80211 directory some time ago.
2018-03-30 04:10:34 <Aerdan[m]> nheko 0.2.1 PR submitted. I'd paste a link but they broke pasting. :V
2018-03-30 05:04:57 <kaniini> sounds gr8
2018-03-30 06:28:53 <fcolista> morning all
2018-03-30 09:33:08 <_ikke_> Anyone got an idea why this fails in een LXC container? (uwsgi)
2018-03-30 09:33:10 <_ikke_> capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_SETPCAP|1<<CAP_SYS_CHROOT, permitted=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_SETPCAP|1<<CAP_SYS_CHROOT, inheritable=1<<CAP_SETGID|1<<CAP_SETUID}) = -1 EPERM (Operation not permitted)
2018-03-30 09:51:46 <fcolista> what's the best way to have an unattended USB install with alpine?
2018-03-30 09:53:10 <_ikke_> alpine-setup has support for answer files, right?
2018-03-30 10:04:38 <clandmeter> yes it does. you should read the documentation.
2018-03-30 10:06:16 <clandmeter> ah we even have dcos about about it https://wiki.alpinelinux.org/wiki/Alpine_setup_scripts#setup-alpine
2018-03-30 10:13:42 <fcolista> thx guys!
2018-03-30 10:14:04 <fcolista> I want a customized apkovl
2018-03-30 10:14:16 <fcolista> so I can provide it to my friend
2018-03-30 10:14:26 <fcolista> i need a sort of apkovl builder
2018-03-30 10:14:33 <fcolista> I have a script who does that
2018-03-30 10:14:53 <fcolista> Wondering if alpine has something for that
2018-03-30 10:15:27 <fcolista> (i can create the apkovl inside an lxc-container of course and provide it)
2018-03-30 10:43:14 <clandmeter> fcolista, there is a script in aports scripts dir
2018-03-30 10:44:40 <fcolista> oh
2018-03-30 10:44:41 <fcolista> right
2018-03-30 10:44:45 <fcolista> genapkovl-*.sh
2018-03-30 13:51:19 <andypost> jirutka, I find PHP 7.2 patchset ready, does it makes sense to apply it before weekend?
2018-03-30 13:52:03 <andypost> I will try to rebuild it on scaleway arm8 a bit later today to be sure-sure
2018-03-30 14:46:33 <jirutka> andypost: yes
2018-03-30 14:55:03 <jirutka> kaniini: we should update ca-certificates
2018-03-30 15:54:42 <benw2> Hey, I'm trying to build an immutable alpine image to pxe boot. I'm trying to work out the best way to not only build this but automate the process. Anyone had any experience doing this?
2018-03-30 15:55:04 <benw2> looking at the netboot project, the magic seems to be done here - https://github.com/alpinelinux/alpine-netboot/blob/master/mknetboot.sh#L61
2018-03-30 15:55:41 <benw2> I can't find any documentation on the command and the source for it isn't that easy to read. Any help would be appreciated :)
2018-03-30 16:03:05 <jirutka> clandmeter: ^
2018-03-30 16:03:28 <_ikke_> THat's a fairly new project
2018-03-30 16:04:36 <benw2> _ikke_: update-kernel doesn't look to be, copyright was 2014-2015 :P
2018-03-30 16:04:45 <jirutka> benw2: I don’t know what exactly is needed for PXE boot, but if you need to automate building Alpine image, maybe https://github.com/alpinelinux/alpine-make-vm-image or https://github.com/jirutka/alpine-make-rootfs can help you
2018-03-30 16:04:48 <benw2> just gonna run some tests with it, see if I can work it out
2018-03-30 16:05:05 <benw2> ta jirutka, will take a look
2018-03-30 16:41:41 <clandmeter> benw2, the scripts for netboot is pretty simple. Its the similar procedure as generating kernel/initramfs for disk installation.
2018-03-30 16:41:55 <clandmeter> im not sure what you want to change?
2018-03-30 19:58:47 <azarus> Shouldn't the copyright year on alpinelinux.org be bumped to 2018?
2018-03-30 20:01:36 <_ikke_> azarus: No, not necessarity
2018-03-30 20:01:41 <_ikke_> necessarily*
2018-03-30 20:03:30 <azarus> What would warrant it not being bumped?
2018-03-30 20:04:02 <_ikke_> azarus: Nothing that hasn't updated on the site since then?
2018-03-30 20:04:15 <_ikke_> And the year means "Year of first publication"
2018-03-30 20:04:24 <azarus> Eh. Fair enough ;P
2018-03-30 20:33:41 <liwakura> how is the generic arm tarball generated?
2018-03-30 20:33:49 <liwakura> im looking for something like an git repo
2018-03-30 20:33:58 <liwakura> currently working on ODroid C2 support
2018-03-30 20:47:13 <andypost[m]> Whats wrong with s390x builder? It hangs all day
2018-03-30 22:27:43 <andypost> jirutka, please cherry-pick this to supported branches https://github.com/alpinelinux/aports/pull/3836
2018-03-30 22:34:28 <jirutka> done
2018-03-30 22:36:43 <andypost> jirutka, thanks, next is 7.2 I expect different number of test failures so probably better to bump version after all arch will report
2018-03-31 00:00:52 <andypost> jirutka, looks php 7.2 mostly landed without errors, please commit https://github.com/alpinelinux/aports/pull/3843 4 & 5 updates to their branches
2018-03-31 02:11:16 <g_n_u> hello. is there a way to enable support for 32bit apps ?
2018-03-31 02:20:01 <g_n_u> seems there is no posiblity to install nvidia drivers at all...
2018-03-31 10:38:52 <andypost> jirutka, thanks, the last one https://github.com/alpinelinux/aports/pull/3845 still fails on travis
2018-03-31 11:17:34 <mepholic> https://www.youtube.com/watch?v=V_Ac-SVYI48
2018-03-31 12:15:07 <jirutka> andypost: "mkdir: can't create directory '/home/travis/build/alpinelinux/aports/community/php7/src': Permission denied" … that’s weird…
2018-03-31 12:15:19 <jirutka> I’ll try it locally
2018-03-31 12:30:45 <andypost_> jirutka, something really weird with travis - many times it needs to restart jobs
2018-03-31 12:31:05 <andypost_> another example https://travis-ci.org/alpinelinux/aports/builds/360595448
2018-03-31 12:43:17 <terra> ERROR: Failed to set ownership on boot/vmlinuz-vanilla.apk-new: Operation not permitted
2018-03-31 12:43:56 <terra> What's the deal with playing with permissions of kernel related files?
2018-03-31 12:44:33 <terra> my /boot partition is vfat and apk is not friendly with it
2018-03-31 13:06:40 <TBB> don't worry about that, it's nothing crucial
2018-03-31 13:06:52 <TBB> some symlinks being created which vfat doesn't support
2018-03-31 13:07:25 <TBB> typical in uefi setups
2018-03-31 13:19:10 <clandmeter> If apk errors I don't think it finished it's process correctly?
2018-03-31 13:21:01 <jirutka> andypost_: maybe we should revert back to `dist: trusty` :/
2018-03-31 13:21:54 <andypost_> jirutka, I think about the same second day(
2018-03-31 13:24:41 <jirutka> I’ve reverted it back to trusty
2018-03-31 13:25:40 <andypost_> jirutka, can we get this to 3.7? this bug is really breaks a lot of tests https://github.com/alpinelinux/aports/pull/3808
2018-03-31 13:26:08 <andypost_> basically lots of tests suppose zlib built-in
2018-03-31 13:27:11 <jirutka> andypost_: I thought that we’ve already changed that to built-in…?
2018-03-31 13:27:16 <jirutka> andypost_: or it was something different?
2018-03-31 13:27:30 <andypost_> jirutka, it was in edge but missed to backport
2018-03-31 13:28:51 <andypost_> it was 1k PRs ago https://github.com/alpinelinux/aports/pull/2951
2018-03-31 14:25:44 <terra> clandmeter: apk finishes but this error remains somewhere because "apk fix" tries to re-install kernel according to this error.
2018-03-31 17:45:20 <fcolista> how would be possibile with shell expansion substitute the /last/ occurrence of a char?
2018-03-31 17:45:24 <fcolista> example:
2018-03-31 17:45:29 <fcolista> 1.2.3.4
2018-03-31 17:45:35 <fcolista> I want 1.2.3_4
2018-03-31 17:45:53 <fcolista> would it be possible in one shot?
2018-03-31 17:46:13 <fcolista> I've done this, but maybe there's a better way:
2018-03-31 17:46:22 <fcolista> v=1.2.3.4
2018-03-31 17:46:34 <fcolista> ${v%.*}${v//*./-}
2018-03-31 17:47:53 <fcolista> sorry, i want 1.2.3-4
2018-03-31 17:51:02 <jirutka> fcolista: ${v%.*}_${v##*.}
2018-03-31 17:51:19 <fcolista> jirutka, is not one shot
2018-03-31 17:51:34 <jirutka> fcolista: there’s no better way
2018-03-31 17:51:38 <fcolista> ok
2018-03-31 17:51:59 <jirutka> what exactly do you mean with “one shot”? you don’t need extra variable for this
2018-03-31 17:52:05 <fcolista> I know
2018-03-31 17:52:10 <fcolista> something like:
2018-03-31 17:52:43 <fcolista> ${v//%.*/_} if would have been possible
2018-03-31 17:53:17 <jirutka> unfortunately it’s not :(
2018-03-31 17:53:39 <fcolista> so I can substitute the first occurrence, but not the last..
2018-03-31 17:55:05 <jirutka> yes
2018-03-31 17:55:33 <fcolista> taht was the reason why I was asking..'cause in my opinion was strange
2018-03-31 17:55:45 <fcolista> but, ok
2018-03-31 17:56:30 <fcolista> i can delete last occurrence but not substitute. I think is a posix limitation 'cause bash be able to do that
2018-03-31 17:58:22 <fcolista> umh, probably not. I've read this somewhere but I can't find the link (saw that while is was checking this possibility)
2018-03-31 17:58:22 <fcolista> https://www.cyberciti.biz/tips/bash-shell-parameter-substitution-2.html
2018-03-31 18:00:02 <jirutka> `${foo/x/y}` is not defined by POSIX, it’s bash extension, but Busybox ash supports it (dash does not)
2018-03-31 18:19:48 <Benw2> Hey maybe this is a question for syslinux, but I'm trying to do an alpine pxe boot entirely on ipv6 slaac
2018-03-31 18:20:20 <Benw2> I can see the syslinux kernel boot param "ip=" exists and is specified in the alpine documentation, but it doesn't support slaac, only dhcp
2018-03-31 18:21:01 <Benw2> I will be chainloading with iPXE which supports ipv6 slaac, but is there any way to pass the networking settings onto the next step? eg. alpine?
2018-03-31 18:25:13 <jirutka> clandmeter: ^
2018-03-31 18:25:40 <jirutka> Benw2: I don’t know, but after you figure it out, please let us know, I’m interested in this
2018-03-31 18:26:28 <Benw2> jirutka: I'll likely forget but I'm going to attempt to open source the build under my companys github
2018-03-31 18:26:39 <Benw2> I will try my best to remember :)
2018-03-31 18:26:43 <Benw2> emailing myself now with your name
2018-03-31 18:26:53 <jirutka> Benw2: thanks :)
2018-03-31 18:28:02 <Benw2> it saddens me but if I don't get it working I'm going to have to opt for one of the traditional OS's
2018-03-31 18:28:39 <Benw2> I love centos, it's my main driver, but really wanted alpine for this since it boots like crazy quick and is dead small
2018-03-31 18:29:52 <jirutka> clandmeter: we need you here!! :)
2018-03-31 18:33:12 <Benw2> haha, in all honesty we may have to go to centos for political reasons, but I'll be working on getting alpine as a main driver for the stuff we'll be using it for
2018-03-31 18:33:46 <Benw2> we don't need all the fluff, we just need ssh and to launch the applications we want to run on there
2018-03-31 18:34:20 <Benw2> unfortunately I've got to work with what we already have which is an ipv6 network and a refusal from networks to do anything ipv4 on those :P
2018-03-31 18:34:40 <Benw2> tbf I would like to go 100% ipv6 slaac in general anyway
2018-03-31 21:23:24 <ollieparanoid[m]> Aerdan: thanks! FYI pasting works with me for nheko. I'm building master every other day and it was never broken for me. I'd recommend to open a bug report.
2018-03-31 21:24:39 <Aerdan[m]> well. it works now, so I'm just going to declare that a heisenbug and move on with my life. :p
2018-03-31 21:29:15 <ollieparanoid[m]> heh... my favorite nheko bug right now is this one: https://github.com/mujx/nheko/issues/288
2018-03-31 21:29:40 <ollieparanoid[m]> anyway, enough off topic
2018-03-31 22:02:25 <jirutka> clandmeter1: please see questions about iPXE above
2018-03-31 22:27:33 <andypost[m]> jirutka: how to find all dependencies for openssl? https://github.com/alpinelinux/aports/pull/3858
2018-03-31 22:28:55 <jirutka> andypost[m]: that’s basically just https://pkgs.alpinelinux.org/package/edge/main/x86_64/libcrypto1.0 (Required by) and https://pkgs.alpinelinux.org/package/edge/main/x86_64/libssl1.0 (Required by)
2018-03-31 22:37:36 <andypost[m]> jirutka: I packages that needs version bump
2018-03-31 22:37:48 <jirutka> andypost[m]: yes, these
2018-03-31 22:38:10 <jirutka> andypost[m]: only few packages depend on openssl, most depend on libressl instead
2018-03-31 22:39:23 <andypost[m]> This two are subpackages but I mean there could be some packages that statically build
2018-03-31 22:41:17 <andypost[m]> Like nodejs depends on openssl
2018-03-31 22:41:56 <jirutka> crap, I thought that we’ve already changed it to libressl :/
2018-03-31 22:41:59 <jirutka> hm
2018-03-31 22:44:55 <jirutka> it seems that it’s just nodejs, nodejs-current, and tomcat-native – these have openssl-dev in makedepends
2018-03-31 22:46:09 <andypost[m]> What about  easy-rsa & neo4j-client?
2018-03-31 22:46:53 <andypost[m]> So basically it needs to skim makedepends of whole db?
2018-03-31 22:49:30 <andypost[m]> Otoh openssl-dev required by 18 packages
2018-03-31 22:58:20 <jirutka> easy-rsa is just shell script
2018-03-31 22:59:11 <jirutka> don’t know about neo4j-client, but since it depends on openssl only, not libcrypto, libssl, I assumed that it just calls openssl binary instead of linking lib, but that’s just assumption
2018-03-31 23:20:07 <andypost_> jirutka, about version bump - should it be a single commit of 3 commits?
2018-03-31 23:20:30 <andypost_> jirutka, last time it was not clear after your discussion with ncopa
2018-03-31 23:20:47 <jirutka> andypost[m]: I prefer single commit for bumping depending aports (see last commits in aports)
2018-03-31 23:20:56 <jirutka> yes, we don’t have consensus yet
2018-03-31 23:23:30 <jirutka> actually, it’d be better to bump in the same commit as upgrade, argument against this (about backporting) was invalid, b/c rebuilding depending pkgs is needed on breaking changes and these are never backported to stable
2018-03-31 23:23:33 <andypost> I see https://git.alpinelinux.org/cgit/aports/commit/?id=bf98f5f50087d94d83e5107f2539d24e5ea806d9
2018-03-31 23:24:23 <andypost> jirutka, but I guess this upgrade will need backport
2018-03-31 23:25:22 <jirutka> actually… not https://abi-laboratory.pro/tracker/timeline/openssl/
2018-03-31 23:25:56 <jirutka> 1.0.2n and 1.0.2o are 100% binary compatible, so we need to rebuild just pkgs that link openssl statically
2018-03-31 23:26:11 <jirutka> i should have realized that before :/
2018-03-31 23:26:30 <andypost> yes, that's a was asked)
2018-03-31 23:26:59 <andypost> https://git.alpinelinux.org/cgit/aports/tree/main/nodejs/APKBUILD?h=3.6-stable#n28
2018-03-31 23:38:32 <andypost> anyway, pushed 2 commits