2019-02-01 08:56:11 <clandmeter> tmhoang: is it really needed to set jobs=1 in czmq?
2019-02-01 08:56:57 <tmhoang> clandmeter: czmq is kind of on hold I guess. I checked the tests good on s390x but ncopa found some tests failed on ppc64le.
2019-02-01 08:57:28 <tmhoang> thinking about spin an QEMU emulation vm for ppc64le but still couldn't find time this. I could do on weekend.
2019-02-01 08:58:07 <clandmeter> yep seems to fail
2019-02-01 08:59:50 <tmhoang> strange thing cmake shows the bug while autotools dont. Running the same ctest commands.
2019-02-01 09:00:25 <tmhoang> the sha1 functions they ship is the problem.
2019-02-01 09:00:33 <tmhoang> would look closer this weekend
2019-02-01 10:14:40 <mps> AinNero: did you 'pushed' your fixes for non-free/b43-firmware to aports?
2019-02-01 10:48:36 <AinNero> mps: https://github.com/alpinelinux/aports/pull/5606
2019-02-01 10:58:10 <p3rL> how do i add opencl in alpine
2019-02-01 11:09:52 <mps> AinNero: sorry, emergency maintenance call. It is not yet merged to aports?
2019-02-01 11:10:02 <AinNero> no
2019-02-01 11:10:28 <mps> you don't have merge rights?
2019-02-01 11:11:26 <AinNero> no
2019-02-01 11:12:37 <mps> your fix is ok, I tested it when you put it there, so I think it should be merged.
2019-02-01 11:13:24 <mps> just noticed it cleaning my copy of aports
2019-02-01 11:18:08 <mps> AinNero: heh, looks like it merged right now :)
2019-02-01 11:18:30 <clandmeter> its magic
2019-02-01 11:18:49 <AinNero> ^^
2019-02-01 11:19:28 <mps> clandmeter: why your nick was in my mind when I saw it on #alpine-commits :)
2019-02-01 14:38:41 <tmhoang> anyone know if openjdk in mixed mode or interpreted mode that has JIT support ?
2019-02-01 14:38:52 <tmhoang> I guess it is mixed mode ?
2019-02-01 15:40:06 <jwh> hmmmm
2019-02-01 15:41:25 <jwh> reckon we could get CONFIG_RTL8723BS added to linux-vanilla?
2019-02-01 15:41:33 <jwh> maybe a couple of others as well
2019-02-01 16:06:16 <jwh> or should I just whip up a PR and let someone decide?
2019-02-01 18:08:51 <gdh> Hello, I am having trouble updating a package. It used to have "option=!check", but now the test suite can be enabled with a configure switch. However, it seems that the check() function is being run before the build is finished. What could I possibly be doing wrong?
2019-02-01 18:09:04 <mort___> clandmeter: am trying to get aarch64 efi boot media built but having a problem. do you have a second to advise please?
2019-02-01 18:11:05 <_ikke_> gdh: That doesn't make sense, abuild works synchronously
2019-02-01 18:11:41 <gdh> _ikke_, I figured as much, but that seems to be what is happening.
2019-02-01 18:13:25 <gdh> I still think it is because I did something wrong, though, not that it is *actually* what is happening.
2019-02-01 18:13:51 <_ikke_> gdh: perhaps you can share your aport?
2019-02-01 18:13:59 <_ikke_> eg. APKBUILD
2019-02-01 18:14:46 <gdh> Before I do, I have a question that just came up: when I run `abuild checksum`, am I supposed to commit the result?
2019-02-01 18:20:09 <gdh> If I do, that may be the problem; I did not realize that I might need to.
2019-02-01 18:21:58 <mps> gdh: if you changed something is src 'field' in APKBUILD then you should run 'abuild checksum'
2019-02-01 18:23:11 <mps> anyway, after changes in APKBUILD it is good to rerun 'abuild checksum' just in case
2019-02-01 18:23:59 <mps> or if you change patch files
2019-02-01 18:33:28 <gdh> Ah, I think I know what the problem is. Does abuild run multiple tests in parallel?
2019-02-01 19:21:13 <HRio> hi can somebody have final look on this (change for main/) https://github.com/alpinelinux/aports/pull/5527 and commit? thanks
2019-02-01 21:34:00 <jwh> tar: Error opening archive: Failed to open '/dev/st0'
2019-02-01 21:34:01 <jwh> hm
2019-02-01 21:34:08 <jwh> why is it doing that...
2019-02-01 21:36:16 <jwh> what on earth
2019-02-01 21:42:54 <AinNero> tape devices! long time no see
2019-02-01 21:43:10 <jwh> it's generating a broken tar -C
2019-02-01 21:43:40 <jwh> >>> softethervpn: Unpacking /var/cache/distfiles/softethervpn-pkgver.tar.gz...
2019-02-01 21:43:44 <jwh> + gunzip -c /var/cache/distfiles/softethervpn-pkgver.tar.gz
2019-02-01 21:43:44 <jwh> + tar -C /data/jwh/aports/testing/softethervpn/src -x
2019-02-01 21:43:45 <jwh> tar: Error opening archive: Failed to open '/dev/st0'
2019-02-01 21:44:17 <AinNero> which tar is that?
2019-02-01 21:44:33 <jwh> busybox I'm guessing
2019-02-01 21:44:37 <jwh> but it needs -xf
2019-02-01 21:44:42 <jwh> I think for busybox anyway
2019-02-01 21:44:55 <jwh> argument order is wrong regardless :D
2019-02-01 21:46:02 <jwh> hm
2019-02-01 21:46:11 <jwh> oh
2019-02-01 21:46:19 <jwh> not in the chroot my bad :D
2019-02-01 21:46:32 <jwh> but the args are stil weird
2019-02-01 22:01:03 <SpaceToast> jwh: not a single compliant tar implementation will accept non-f
2019-02-01 22:01:07 <SpaceToast> without -f it defaults to tape devices
2019-02-01 22:01:11 <SpaceToast> always provide -f
2019-02-01 22:03:36 <jwh> thats exactly my point ;)
2019-02-01 22:03:40 <jwh> [21:43:10] < jwh> it's generating a broken tar -C
2019-02-01 22:03:57 <jwh> question is why (tar was bsdtar, but why does it care?)
2019-02-01 22:04:06 <jwh> and why does that cause it to miss -f
2019-02-01 22:05:34 <jwh> obviously bsdtar is tar on my systems because I'm not a monster, bsdtar is the best tar :D
2019-02-01 22:07:13 <jwh> sigh, project ships broken anyway
2019-02-01 22:07:26 <jwh> submodules aren't included in github releases
2019-02-01 22:08:59 <jwh> why do so many projects not ship source archives that *actuallY* work
2019-02-01 22:09:47 <jwh> developers who don't reinit their environment between releases suck, as it means a new environment does not work like its intended
2019-02-01 22:22:55 <mps> SpaceToast: would you mind to look in small note I prepared about RDRAND and boot delay on released v3.9?
2019-02-01 22:23:32 <mps> here it is: http://tpaste.us/xpjD
2019-02-01 22:23:34 <SpaceToast> mps: sure, please pm it to me and I'll look at it once I get home (not too long)
2019-02-01 22:24:43 <mps> I think something like that will be needed in next few days or week
2019-02-01 22:34:18 <jwh> https://gist.githubusercontent.com/joeholden/1a9b078e44cb1df65796bbe649dbd2ab/raw/96bad712aee661cb9c0d198ba526cd77225d16ab/gistfile1.txt
2019-02-01 22:34:21 <jwh> :D
2019-02-01 22:34:57 <jwh> are your eyes bleeding yet?
2019-02-01 22:37:00 <mps> jwh: why you don't put -C destdir
2019-02-01 22:37:05 <jwh> for what?
2019-02-01 22:37:10 <jwh> the extras/
2019-02-01 22:37:11 <jwh> ?
2019-02-01 22:37:14 <mps> tar
2019-02-01 22:37:48 <mps> destdir is where you want to extract, ofc
2019-02-01 22:38:51 <mps> just superficial note, didn't tried your APKBUILD
2019-02-01 22:39:01 <jwh> well
2019-02-01 22:39:49 <mps> it's coincidence that right now I'm trying something like you but for different package
2019-02-01 22:41:51 <jwh> what I'd ideally like is a way to cut the top dir off, a la patch -p1
2019-02-01 22:43:40 <jwh> I don't see an option in busybox tar though
2019-02-01 22:45:44 <mps> I suspect that busybox tar support --wildcards option
2019-02-01 22:45:53 <jwh> oh hm, good point
2019-02-01 22:46:44 <mps> add tar makedepends and use it's 'full power' ;)
2019-02-01 22:50:16 <mps> wait, it supports but moaning that it doesn't
2019-02-01 22:50:16 <jwh> oh I'm blind, strip components is there
2019-02-01 22:53:14 <mps> nice that you found solution. going out for a little fresh air
2019-02-01 22:53:22 <jwh> thanks
2019-02-01 22:53:53 <mps> yw
2019-02-01 22:54:53 <jwh> updated gist, if someone could test it on non-x86 that would be nice <3
2019-02-01 23:11:44 <SpaceToast> mps: looked at your note - it's worded slightly weird, and is extlinux-specific
2019-02-01 23:12:41 <mps> because my wording I asked you for help
2019-02-01 23:12:54 <mps> :)
2019-02-01 23:13:23 <mps> I skipped grub because it is not default boot looder
2019-02-01 23:13:48 <mps> but we could add it to note
2019-02-01 23:13:58 <jwh> it's generic, should add a note about adding it to whatever bootloader you use as cmdline arg
2019-02-01 23:14:12 <mps> although I didn't tried to boot with it
2019-02-01 23:14:25 <jwh> can I see it?
2019-02-01 23:14:38 <SpaceToast> mps: let me quickly jot something down
2019-02-01 23:15:23 <mps> jwh: already posted here but here it is again http://tpaste.us/xpjD
2019-02-01 23:15:39 <jwh> oh, my bad
2019-02-01 23:16:28 <jwh> hm, should probaly also note that if you don't want to trust RDRAND but still want a sensible boot time, you can use rngd or haveged
2019-02-01 23:16:42 <jwh> rngd can also optionally mix from rdrand
2019-02-01 23:17:16 <mps> yeah, doesn't it mentioned there \:)
2019-02-01 23:17:51 <mps> rngd will not start without some hardware source, iirc
2019-02-01 23:18:19 <jwh> oh hm, thought it had multiple sources
2019-02-01 23:18:33 <jwh> just haveged then I guess, as RDRAND isn't always available
2019-02-01 23:18:57 <mps> I thought to add note about haveged for machines without hardware entropy sources, but obviously I didn't
2019-02-01 23:19:42 <SpaceToast> mps: I'd do something closer to http://tpaste.us/YMww , but it's still kind of awkward
2019-02-01 23:19:45 <mps> haveged is simplest and easiest solution
2019-02-01 23:19:52 <SpaceToast> (I'm very tired right now, not exactly optimal)
2019-02-01 23:20:17 <SpaceToast> haveged has some unfortunate decisions in-code, I'd rather just trust my cpu (or wait a bit longer)
2019-02-01 23:20:32 <SpaceToast> I recall there was another daemon that was more appropriate, but I don't remember what it was
2019-02-01 23:20:50 <jwh> SpaceToast: that only works if you have a cpu rng though
2019-02-01 23:20:54 <mps> SpaceToast: thanks, that is enough for short note, maybe add haveged
2019-02-01 23:20:55 <jwh> lots of platforms don't
2019-02-01 23:21:08 <SpaceToast> mps: I... did?
2019-02-01 23:21:21 <mps> it is not intended to be comprehensive guide, at the end
2019-02-01 23:21:35 <jwh> none of my vm hosts have rdrand for example, so the only acceptable solution is haveged
2019-02-01 23:21:51 <mps> SpaceToast: I see
2019-02-01 23:22:47 <jwh> I'd imagine it's worse for people who have more things on boot, if its 30 seconds+ just for sshd, how bad is it going to be with lots of other stuff waiting for entropy?
2019-02-01 23:22:55 <mps> in last two days I answered that same questions few times, and not only I but also other people
2019-02-01 23:23:53 <mps> next time someone asks I will simply give url which SpaceToast just posted
2019-02-01 23:24:11 <SpaceToast> jwh: not much of a difference
2019-02-01 23:24:20 <SpaceToast> once you get ~128bits of entropy you can go for a very long time from then on
2019-02-01 23:24:29 <jwh> yeah
2019-02-01 23:24:34 <SpaceToast> and sshd will wait for the 128bits
2019-02-01 23:24:45 <SpaceToast> so no real difference :)
2019-02-01 23:24:58 <jwh> assuming you don't need more, yeah sure
2019-02-01 23:25:09 <SpaceToast> it'll be a couple of years before you need more
2019-02-01 23:25:15 <SpaceToast> you can go a very long time on 128 bits
2019-02-01 23:25:19 <SpaceToast> that's what I just said...
2019-02-01 23:25:26 <jwh> anyway someone test my apkbuild on non-x86
2019-02-01 23:25:31 <jwh> pretty please?
2019-02-01 23:25:33 <mps> we are not discussing perfect entropy now, I hope :)
2019-02-01 23:25:42 <jwh> SpaceToast: hmmm
2019-02-01 23:25:44 <SpaceToast> my builder is still waiting for the patch :(
2019-02-01 23:25:56 <jwh> SpaceToast: but consuming it means it empties, right?
2019-02-01 23:26:03 <SpaceToast> no
2019-02-01 23:26:16 <SpaceToast> all of your RNG goes through de-biasing and whitening, and gets fed into PRNG
2019-02-01 23:26:29 <SpaceToast> and that PRNG needs ~128bits
2019-02-01 23:26:32 <jwh> ohhh, well that used to be the case?
2019-02-01 23:26:33 <SpaceToast> to go for a very long time.
2019-02-01 23:26:36 <SpaceToast> nope
2019-02-01 23:26:43 <SpaceToast> entropy is hard to estimate (duh)
2019-02-01 23:26:43 <jwh> hm, maybe I'm thinking of non-linux
2019-02-01 23:26:51 <SpaceToast> non-linux is a lot saner than linux right now :)
2019-02-01 23:26:55 <jwh> heh
2019-02-01 23:26:58 <SpaceToast> linux is stuck because they don't want to break userland
2019-02-01 23:27:01 <jwh> tbf it always was
2019-02-01 23:27:05 <SpaceToast> what used to happen
2019-02-01 23:27:17 <SpaceToast> is urandom would be fed from the random pool
2019-02-01 23:27:21 <jwh> yeah
2019-02-01 23:27:24 <SpaceToast> and the random pool would get blocked
2019-02-01 23:27:27 <SpaceToast> when the "counter" got too low
2019-02-01 23:27:31 <SpaceToast> but the counter doesn't mean anything
2019-02-01 23:27:39 <SpaceToast> https://www.2uo.de/myths-about-urandom - enjoy (this is mostly accurate)
2019-02-01 23:27:45 <jwh> yeah thats what I meant
2019-02-01 23:29:21 <SpaceToast> the correct solution is to use getrandom(2) on linux and stop worrying
2019-02-01 23:29:29 <SpaceToast> but it's non-portable (being a syscall and all)
2019-02-01 23:29:35 <SpaceToast> also, getentropy(2) on openbsd (also good)
2019-02-01 23:29:49 <jwh> yeah
2019-02-01 23:29:55 <jwh> makes sense
2019-02-01 23:31:33 <jwh> obviously the only true source of randomness is stupid lava lamps
2019-02-01 23:31:58 <SpaceToast> I wouldn't trust much besides photon superposition
2019-02-01 23:32:20 <jwh> heh
2019-02-01 23:32:30 <jwh> https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/
2019-02-01 23:32:35 <mps> X-rays from nuclear fision, in the CPU :)
2019-02-01 23:32:38 <jwh> some hairy hands nonsense there
2019-02-01 23:32:38 <jwh> :D
2019-02-02 02:53:31 <leo-unglaub> i have to add a route every time my interface comes up, the line is ¨ip route add 172.31.1.1 dev eth0¨. Where do i put this line in my interfaces file?
2019-02-02 03:02:40 <SpaceToast> leo-unglaub: post-up <my command> in the interface section
2019-02-02 03:02:55 <SpaceToast> I think there's supposed to be a thing dedicated to routes though, but I'm not sure if busybox ifupdown implements that
2019-02-02 03:04:37 <leo-unglaub> SpaceToast, i already did that
2019-02-02 03:04:42 <leo-unglaub> but is does not get executed
2019-02-02 03:04:59 <SpaceToast> considering I have an interface that does not work without post-up commands...
2019-02-02 03:05:05 <SpaceToast> I'll express my doubts
2019-02-02 03:05:21 <leo-unglaub> hmm
2019-02-02 03:05:57 <leo-unglaub> do i have to use an absolute path in that file?
2019-02-02 03:07:21 <SpaceToast> nope
2019-02-02 03:08:26 <SpaceToast> here's an example `post-down ip link del $IFACE`
2019-02-02 03:08:26 <leo-unglaub> hmm, i had the same thing a couple of months back
2019-02-02 03:10:12 <leo-unglaub> hmm, exactly like i have
2019-02-02 03:10:52 <leo-unglaub> hmm, i an going to put the commands in my crontab with @reboot
2019-02-02 03:10:56 <leo-unglaub> should do the trick as well
2019-02-02 03:11:27 <SpaceToast> if you say so ¯\_(ツ)_/¯
2019-02-02 03:12:09 <leo-unglaub> hmm
2019-02-02 03:15:36 <leo-unglaub> is there something else i have to enable in order for this to work?
2019-02-02 03:17:56 <SpaceToast> only the usual ifupdown stuff
2019-02-02 03:18:07 <SpaceToast> so having the networking service in a runlevel
2019-02-02 03:19:05 <leo-unglaub> hmm, that i have
2019-02-02 03:19:26 <leo-unglaub> that is strange
2019-02-02 03:22:57 <leo-unglaub> https://pastebin.com/raw/rB77jCKH <- thats my file
2019-02-02 03:23:14 <leo-unglaub> when i execute the commands manually they work fine
2019-02-02 03:25:31 <SpaceToast> erm
2019-02-02 03:25:35 <SpaceToast> why do you need those at all?
2019-02-02 03:26:03 <leo-unglaub> to get network connectivity in the datacenter
2019-02-02 03:26:25 <SpaceToast> have you consider not having a 255.255.255.255 netmask?
2019-02-02 03:26:31 <SpaceToast> just being on the same network as the gateway?
2019-02-02 03:26:45 <leo-unglaub> no, the netmask is correct
2019-02-02 03:26:56 <leo-unglaub> thats a new trend in datecenters here now, that is correct
2019-02-02 03:27:14 <SpaceToast> either way, this is the development channel
2019-02-02 03:27:24 <SpaceToast> pretty sure none of this has anything to do with alpine development :)
2019-02-02 03:27:28 <SpaceToast> please ask in #alpine-linux
2019-02-02 13:51:30 <AinNero> openrc-qemu is broken, we need https://github.com/jirutka/qemu-openrc/pull/4
2019-02-02 13:52:21 <AinNero> qemu is failing on options that got removed
2019-02-02 14:10:37 <AinNero> jirutka: are you still maintaining that code?
2019-02-02 15:27:19 <leo-unglaub> the hiawatha package is currently broken. It needs a rebuild (together with mbedtls). Could someone of you please be so kind and bump the version on it so it can be installed again on edge? thanks! https://pastebin.com/raw/LgHdv3QY
2019-02-02 16:55:21 <mps> any know rationale for omitted file url scheme for curl in Alpine
2019-02-02 16:55:42 <mps> s/any/anyone/
2019-02-02 16:55:42 <alpine-meetbot> mps meant to say: anyone know rationale for omitted file url scheme for curl in Alpine
2019-02-03 00:27:34 <jwh> hm
2019-02-03 00:29:23 <jwh> any suggestions before I open a PR for this? I'm not sure it's good enough (ignore lack of initd etc) https://gist.github.com/joeholden/1a9b078e44cb1df65796bbe649dbd2ab
2019-02-03 01:08:56 <vkrishn> hi, hope this is not asecurity concern in al, https://blog.cryptographyengineering.com/2018/09/23/why-im-leaving-chrome/
2019-02-03 01:11:07 <AinNero> vkrishn: we dont ship chrome
2019-02-03 01:11:19 <AinNero> not sure how chromium is related
2019-02-03 01:11:24 <jwh> ah you spoke, you're it!
2019-02-03 01:12:36 <mps> chromium is OS on itself, about 630MB source tarball
2019-02-03 01:13:52 <mps> tried to fix it and build on Alpine but after some think asked myself: *for what*
2019-02-03 01:13:54 <vkrishn> AinNero: ok, thanks, I don't either of them, just wondered
2019-02-03 01:14:03 <jwh> mps: you're it too :D
2019-02-03 01:14:27 <AinNero> vkrishn: like, people warned about google and chrome 10 years ago, this is not a surprise at all
2019-02-03 01:16:04 <mps> actually don't use it for years, even on phone install firefox just in case although don't use browser on phone
2019-02-03 01:16:05 <jwh> hm, I remember that particular bit of news
2019-02-03 01:16:14 <jwh> and it hasn't actually manifested like people claimed
2019-02-03 01:17:06 <jwh> unless you're already signed in, it won't continue to sign you in automatically
2019-02-03 01:17:07 <mps> looking in google last years I even stopped to us go-lang
2019-02-03 01:17:26 <jwh> even if chrome itself is signed in with a sync account
2019-02-03 01:17:32 <mps> switched to crystal and trying to learn rust
2019-02-03 01:18:25 <mps> not that I trust mozilla but looks better for now at least
2019-02-03 01:19:08 <jwh> both the non-MS options are actually worse
2019-02-03 01:20:13 <mps> rust looks quite fine, don't know why i ignored it for some years, awkward syntax to my eyes probably
2019-02-03 01:20:40 <jwh> probably because we don't need another ruby? :)
2019-02-03 01:21:07 <mps> crystal is ruby like
2019-02-03 01:21:18 <jwh> don't know why everyone feels the need to invent their own language with broken packaging and dependency management these days
2019-02-03 01:21:23 <jwh> is it a perceived claim to fame?
2019-02-03 01:21:58 <mps> jwh: fully agree with you. C is best of languages, imo
2019-02-03 01:22:16 <jwh> well its the foundation
2019-02-03 01:22:21 <jwh> but everyone sucks at writing good C
2019-02-03 01:22:23 <mps> ok, forth is near
2019-02-03 01:22:36 <jwh> because it requires you to actually do it properly and care about memory management, buffers, etc
2019-02-03 01:22:41 <jwh> none of the hippy dippy languages do
2019-02-03 01:23:06 <jwh> but there are choices that are C-like and hand hold you through memory management, like D
2019-02-03 01:23:31 <jwh> one can use C within D
2019-02-03 01:23:35 <mps> the problem with C is there are order of magnitude less developers who knows than the developers who thinks they know C
2019-02-03 01:23:39 <jwh> whilst getting all the benefits
2019-02-03 01:24:51 <SpaceToast> D is pretty nice
2019-02-03 01:24:51 <mps> oh, we are offtopic, sorry
2019-02-03 01:25:20 <jwh> I honestly think a lot of the modern stuff is just kids unwilling to larn
2019-02-03 01:25:22 <jwh> learn*
2019-02-03 01:25:36 <jwh> also the reason why they keep making the mistakes everyone else did 2 decades ago
2019-02-03 01:25:39 <jwh> lol
2019-02-03 01:25:52 <jwh> the whole "we know better" attitude
2019-02-03 01:26:26 <mps> jwh: we have #alpine-offtopic channel
2019-02-03 01:26:45 <jwh> thats nice :P
2019-02-03 01:27:00 <jwh> anyway, someone check my apkbuild!
2019-02-03 01:27:18 <jwh> I don't like it, but I can't come up with a cleaner way
2019-02-03 01:27:46 <mps> I looked lightly but don't have time to try it, you want it on arm?
2019-02-03 01:28:24 <jwh> preferably, but also just the general structure and the horrible mess of extracting archives into the builddir
2019-02-03 01:30:23 <mps> maybe I will have some time tomorrow evening to try it on aarch64
2019-02-03 01:30:30 <jwh> thanks
2019-02-03 01:31:10 <mps> but, for what is that package useful, don't we have enough VPN's already
2019-02-03 01:34:55 <jwh> it's actually useful
2019-02-03 01:35:13 <jwh> also its multiprotocol
2019-02-03 01:35:30 <mps> isn't it proprietary
2019-02-03 01:35:43 <jwh> https://www.softether.org/3-spec
2019-02-03 01:35:44 <jwh> no
2019-02-03 01:36:25 <jwh> also it has features people use, like working AAA and stuff
2019-02-03 01:36:57 <jwh> but at this point anything is better than the mess of tunnel types and total lack of any configuration support
2019-02-03 01:37:12 <mps> uh, I was probably tired last night when I looked at it
2019-02-03 01:37:35 <jwh> it has it's own tunnel mode, but its still open source so it's no different from any other type
2019-02-03 01:37:48 <jwh> I like theirs though, it's ethernet over https
2019-02-03 01:37:49 <jwh> heh
2019-02-03 01:38:19 <mps> I prefer wireguard :)
2019-02-03 01:38:30 <jwh> no thanks :D
2019-02-03 01:38:40 <jwh> zero interop, not flexible
2019-02-03 01:38:57 <mps> but fast
2019-02-03 01:39:09 <jwh> so are others though
2019-02-03 01:40:13 <mps> ok, give me your apkbuild, I'm behind aarch64
2019-02-03 01:40:34 <jwh> https://gist.githubusercontent.com/joeholden/1a9b078e44cb1df65796bbe649dbd2ab/raw/cdf32054fe5dc00871b3d119aa495a9e2392eee5/gistfile1.txt
2019-02-03 01:40:49 <jwh> has no init.d, just build testing atm, but it's easy enough to test startup
2019-02-03 01:41:25 <jwh> I'll need to split it up into subpackages anyway as the package includes 3 components
2019-02-03 01:41:30 <jwh> so people might want just the client etc
2019-02-03 01:42:44 <mps> ok, on that arm where I'm now link is slow
2019-02-03 01:44:25 <jwh> oh ok
2019-02-03 01:46:29 <jwh> oh
2019-02-03 01:46:33 <jwh> I did a dumb on that version
2019-02-03 01:48:00 <jwh> updated
2019-02-03 01:48:32 <mps> Configuring incomplete, errors occurred!
2019-02-03 01:48:53 <jwh> hm, missing deps?
2019-02-03 01:49:16 <mps> http://tpaste.us/5woM
2019-02-03 01:49:32 <mps> there is log
2019-02-03 01:50:06 <jwh> hm, thats not so useful
2019-02-03 01:50:44 <jwh> there doesn't appear to be any errors in there
2019-02-03 01:50:46 <mps> I don't understand why it failed
2019-02-03 01:51:03 <jwh> yeah it's not being verbose enough
2019-02-03 01:51:12 <mps> I did abuild checksum deps unpack prepare build
2019-02-03 01:52:15 <mps> Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
2019-02-03 01:52:41 <mps> maybe missing libcurses-dev
2019-02-03 01:54:35 <jwh> oh
2019-02-03 01:54:38 <jwh> hmmm
2019-02-03 01:54:43 <jwh> did I do it wrong
2019-02-03 01:54:51 <mps> you should add ncurses-dev to makedepends
2019-02-03 01:55:05 <mps> [100%] Built target hamcore-archive-build
2019-02-03 01:55:05 <jwh> yeah is missing
2019-02-03 01:55:23 <jwh> I need to get a proper build script setup that does itvin a chroot
2019-02-03 01:55:26 <jwh> so I don't miss deps
2019-02-03 01:55:30 <jwh> it in*
2019-02-03 01:55:56 <mps> I have softethervpn-5.01.9668-r0.apk
2019-02-03 01:56:06 <jwh> cool ok
2019-02-03 01:56:27 <jwh> just need to tidy it up now and do init
2019-02-03 01:56:28 <mps> but I will not test if it is work
2019-02-03 01:56:39 <jwh> runtime testing requires a lot of effort, so don't bother
2019-02-03 01:56:52 <mps> that is new: makedepends="cmake openssl-dev ncurses-dev readline-dev zlib-dev"
2019-02-03 01:57:31 <jwh> yeah
2019-02-03 01:57:41 <jwh> thought I might be missing something, thanks
2019-02-03 01:57:55 <jwh> something else pulled it in on my build box, so I didn't pick it up
2019-02-03 01:57:58 <mps> ok, I'm tired, going to bed, good night
2019-02-03 01:58:08 <jwh> night, thanks
2019-02-03 01:58:39 <mps> see you tomorrow :)
2019-02-03 10:04:06 <notlistening> Hi all, I am trying to setup a cross compiling server for alpine 3.8 using aports. The outcome is that I can cross compile a Docker apk for armhf with custom patches. Any pointers on the setup / process
2019-02-03 14:04:17 <andypost> notlistening, I suggest to use chroot for that, much easy to setup
2019-02-03 16:49:05 <Mo0O> hi there, do you know if it's possible using awall to set a policy for a port range?
2019-02-03 18:27:06 <rmoriz> hi! Is there a solution to cross-compile a package for a specific non-native arch? say ARMv6?
2019-02-03 18:29:06 <AinNero> yes, thats how new architectures are bootstrapped
2019-02-03 18:39:21 <rmoriz> AinNero: where can I find it?
2019-02-03 18:41:45 <AinNero> there is the scripts/bootstrap.sh in the aports
2019-02-03 18:42:06 <AinNero> but dont expect it to be easyt
2019-02-03 18:45:07 <rmoriz> thanks!
2019-02-03 19:14:15 <jwh> not in this case, but if its an already supported arch you could just use qemu user and binfmt
2019-02-03 19:18:25 <rmoriz> jwh: I'm using docker, qemu and binfmt right now to try to build the mono package from testing for arm
2019-02-03 22:41:50 <andypost> ncopa, #9958 needs you
2019-02-03 22:42:30 <andypost> libssh2-dev always require libressl for some reason
2019-02-04 04:07:35 <danieli> odd that rebuilding it doesn't help
2019-02-04 08:55:47 <clandmeter> andypost: why do you think its related to libressl?
2019-02-04 09:54:40 <vkrishn> could someone have a look if __EOF__ in
2019-02-04 09:54:40 <vkrishn> https://git.alpinelinux.org/alpine-conf/tree/setup-alpine.in#n36 should be at start of the line, I get error like,
2019-02-04 09:54:43 <vkrishn> syntax error: unexpected end of file (expecting "}")
2019-02-04 09:57:24 <vkrishn> if its an issue, it might if in other scritps too, same formatting of here-documents
2019-02-04 10:02:41 <pardis> Works for me
2019-02-04 10:03:05 <pardis> Is your /bin/sh a symlink to busybox or something else?
2019-02-04 10:04:59 <vkrishn> yes, I tried in al 3.7
2019-02-04 10:11:30 <pardis> `setup-alpine -h` works for me on 3.7 too
2019-02-04 10:11:38 <pardis> There must be something wrong with your setup
2019-02-04 10:20:36 <vkrishn> try them, https://tpaste.us/Kgon , http://tpaste.us/oaNq
2019-02-04 10:30:56 <vkrishn> I had edited, one of them at some point, was testing something, and added space, tab works now
2019-02-04 10:40:58 <vkrishn> possibly a busybox issue
2019-02-04 11:35:00 <tboerger[m]> is there an easy way to solve the upgrade issues at https://cloud.drone.io/dockhippie/alpine/1/3/2 and https://cloud.drone.io/dockhippie/alpine/1/2/2?
2019-02-04 11:41:26 <danieli> tboerger[m]: looks like it's a little off relating to uh
2019-02-04 11:41:29 <danieli> libcrypto
2019-02-04 11:41:52 <danieli> i'd remove libressl, make sure openssl is installed, and run `apk fix`
2019-02-04 11:43:12 <tboerger[m]> hum... i really pulled directly from `arm32v6/alpine:edge` and `arm64v8/alpine:edge` which are the official docker images for these architectures and just try to upgrade :(
2019-02-04 11:43:20 <tboerger[m]> i will give it a try
2019-02-04 11:45:19 <tboerger[m]> oh god... the arm64v8/alpine:edge comes with 3.7 repos configured 🤦
2019-02-04 11:51:04 <clandmeter> tboerger[m]: the problem is they are based on rootfs tarball (i think)
2019-02-04 11:51:14 <clandmeter> edge doesnt have such tarball
2019-02-04 11:51:34 <tboerger[m]> yeah, just looked into some kind of build definiton of them
2019-02-04 11:51:51 <clandmeter> Its on the list of things to fix.
2019-02-04 11:51:54 <tboerger[m]> https://github.com/gliderlabs/docker-alpine/blob/c4f57192a21b4cccb746381ccfdcde4773ddf32a/versions/library-edge/x86_64/options compared to https://github.com/gliderlabs/docker-alpine/blob/c4f57192a21b4cccb746381ccfdcde4773ddf32a/versions/library-edge/armhf/options or https://github.com/gliderlabs/docker-alpine/blob/c4f57192a21b4cccb746381ccfdcde4773ddf32a/versions/library-edge/aarch64/options
2019-02-04 11:52:04 <clandmeter> periodic edge snapshots
2019-02-04 11:52:37 <tboerger[m]> just the question why they build amd64 differently :)
2019-02-04 11:53:33 <tboerger[m]> andy shinn is not part of this channel :(
2019-02-04 11:54:08 <clandmeter> i htink there is an issue on bugs.a.o
2019-02-04 12:03:24 <tboerger[m]> https://bugs.alpinelinux.org/issues/9873 refers to https://github.com/gliderlabs/docker-alpine/pull/465 which haven't been merged :(
2019-02-04 12:04:24 <tboerger[m]> and https://bugs.alpinelinux.org/issues/9925 is more or less a duplicate of 9873, just that it talks about i386
2019-02-04 12:52:25 <andypost[m]> clandmeter, because installing libssh2-dev installs libressl
2019-02-04 12:54:13 <andypost[m]> But when I do rebuild it tells about openssl but dependency in final package remains
2019-02-04 12:57:45 <mps> andypost[m]: hmm, do you work on 3.9 installed from scratch or upgraded
2019-02-04 12:59:09 <andypost[m]> mps using docker 3.9 and edge from official images
2019-02-04 12:59:20 <mps> I noticed that the libssh2 pulls libressl on not fully upgraded v3.9
2019-02-04 13:00:03 <mps> but after 'apk upgrade -a' then it doesn't, i.e. pulls openssl
2019-02-04 13:01:22 <mps> maybe this docker image have something which requires libressl. I had one package localy built which did that
2019-02-04 13:01:55 <tmhoang> clandmeter: are you okay with me getting the openrc pr ( aports/pull/6183, aports/pull/6184) staying in aports, at least for 3.9.[1,2,3..] ? For getting it upstream to openrc, it might take a while ....
2019-02-04 13:05:32 <andypost[m]> mps, as it's reproducable on bare alpine images surely something wrong
2019-02-04 13:06:15 <mps> andypost[m]: which arch, x86_64?
2019-02-04 13:06:22 <andypost[m]> Yep
2019-02-04 13:06:54 <mps> hmm, strange, on my machine it ok.
2019-02-04 13:07:30 <clandmeter> andypost[m]: its pkgconfig that pulls in libressl
2019-02-04 13:07:40 <tmhoang> clandmeter: I was thinking of create a service like todclock besides hwclock so it wouldn't mess up with hwclock.
2019-02-04 13:07:45 <mps> and in aports libssh2 looks fine, maybe need trigger to rebuild and upload
2019-02-04 13:07:53 <tmhoang> so it would avoid if arch else like ncopa mentioned the other day
2019-02-04 13:08:32 <tmhoang> <ncopa> im not to happy with adding arch specific if ...else. what i was thinking is that we can probably do *tool specific* if ... else. or case $tool in ...
2019-02-04 13:08:43 <andypost[m]> mps as I added rebuild to PR but it does not help
2019-02-04 13:11:02 <mps> hmm, 'apk info | grep libressl' shows nothing on my machine
2019-02-04 13:11:50 <mps> and, 'apk version libssh2-dev' shows 'libssh2-dev-1.8.0-r4                    = 1.8.0-r4'
2019-02-04 13:16:55 <clandmeter> problem is both openssl and libressl provide libcrypto and similar.
2019-02-04 13:17:04 <clandmeter> but the version of libressl is higher
2019-02-04 13:17:17 <clandmeter> so it will always be selected instead of openssl
2019-02-04 13:19:43 <clandmeter> im not 100% sure how to solve this. we could temp modify the pkgconf and add dependency to openssl-dev, but this problem is bigger than just libssh2.
2019-02-04 13:23:08 <tboerger[m]> is there an easy way to get this 3.7 edge docker image fuckup solved? got an edge repositories file, but this fails of course: docker run -ti --rm -v $(pwd)/repositories:/etc/apk/repositories arm64v8/alpine:edge sh -c 'apk update && apk del -f libressl && apk add openssl && apk upgrade -a'
2019-02-04 13:23:20 <tboerger[m]> ERROR: libcrypto1.1-1.1.1a-r1: trying to overwrite etc/ssl/openssl.cnf owned by libressl2.6-libcrypto-2.6.3-r0.
2019-02-04 13:26:39 <clandmeter> tboerger[m]: did you upgrade to 3.9?
2019-02-04 13:27:05 <tboerger[m]> clandmeter: i would like to -.-
2019-02-04 13:27:24 <clandmeter> is that where  the error came from?
2019-02-04 13:27:34 <clandmeter> upgrade to 3.9
2019-02-04 13:30:52 <clandmeter> looks like the replaces only cover the ones from 3.8
2019-02-04 13:31:07 <clandmeter> i wonder if replaces supports wildcards
2019-02-04 13:31:49 <tboerger[m]> currently the docker container contains a repositories file refering to v3.7, if i replace it with a repositories file refering to edge i'm not able to upgrade, if i replace it with v3.9 it also fails to upgrade: https://gist.github.com/tboerger/98a7ad9f2a33e1c62ca6f33a4e1255f2
2019-02-04 13:32:22 <clandmeter> append an apk fix
2019-02-04 13:32:26 <clandmeter> it should fix the issue
2019-02-04 13:32:38 <tboerger[m]> after the upgrade?
2019-02-04 13:32:42 <clandmeter> yes
2019-02-04 13:32:49 <clandmeter> i know its not optimal
2019-02-04 13:33:12 <tboerger[m]> so i need to ignore the exit code >0
2019-02-04 13:33:28 <clandmeter> take the exit code of apk fix
2019-02-04 13:33:42 <clandmeter> if thats still broken than something is still wrong
2019-02-04 13:33:46 <tboerger[m]> docker run -ti --rm -v $(pwd)/repositories:/etc/apk/repositories arm64v8/alpine:edge sh -c 'apk update && apk upgrade -a || true && apk fix'
2019-02-04 13:34:10 <clandmeter> yes but you could just do || apk fix
2019-02-04 13:34:31 <tboerger[m]> true... thanks
2019-02-04 13:35:00 <clandmeter> the upgrade path is designed from version to version, not skipping one...
2019-02-04 13:35:10 <clandmeter> its a bug though
2019-02-04 13:35:44 <clandmeter> andypost[m]: can you wait for a fix for that php issue?
2019-02-04 13:37:22 <clandmeter> fabled: you around?
2019-02-04 13:37:40 <fabled> clandmeter, yes (but on phone)
2019-02-04 13:38:00 <clandmeter> fabled: i think we have an issue with pkgconfig with libressl and openssl
2019-02-04 13:38:17 <clandmeter> they both provide the same, and libressl version is higher.
2019-02-04 13:39:07 <tboerger[m]> it's a shame... alpine and ubuntu are the only arm docker images that nearly directly build without issues :(
2019-02-04 13:39:35 <clandmeter> tboerger[m]: docker images will be fixed after ncopa gets back from holiday.
2019-02-04 13:39:36 <fabled> hum. i remember talking about that with ncopa earlier
2019-02-04 13:39:39 <tboerger[m]> ok, debian only got an issue on version 8 with arm64... but opensuse is such a huge mess
2019-02-04 13:40:13 <tboerger[m]> yeah, now it seems to work for me. just the tiny upgrade issue for the edge image was blocking but that seems to work for now.
2019-02-04 13:41:17 <tboerger[m]> https://cloud.drone.io/dockhippie/alpine/4 edge, 3.9, 3.8, 3.7 and 3.6 built with my additional packages on amd64, arm32v6 and arm64v8 <3
2019-02-04 13:45:15 <clandmeter> fabled: was there any decision how to fix it? should we get rid of the libressl pkgconfig file?
2019-02-04 13:48:07 <fabled> i don't remember what was he conclusion. or if there was any plan... maybe we just noticed the issue.
2019-02-04 13:49:01 <clandmeter> i dont see any other other than removing libressl or the pc file?
2019-02-04 13:49:12 <clandmeter> s/other/way
2019-02-04 13:49:12 <alpine-meetbot> clandmeter meant to say: i dont see any way other than removing libressl or the pc file?
2019-02-04 13:49:59 <tboerger[m]> thanks for the help :)
2019-02-04 14:00:11 <ncopa> Looks like we need to add replaces in libcrypto
2019-02-04 14:00:11 <alpine-meetbot> ncopa: 2019-01-30 - 08:52:48 <clandmeter> tell ncopa arm releases are incomplete
2019-02-04 14:00:34 <clandmeter> :)
2019-02-04 14:00:45 <clandmeter> we have
2019-02-04 14:00:50 <clandmeter> but they are versioned
2019-02-04 14:01:01 <clandmeter> can we use wildcards in replaces?
2019-02-04 14:01:16 <clandmeter> i asume not
2019-02-04 14:01:17 <ncopa> Ok. I'll try get my laptop and an internet connection later today
2019-02-04 14:24:13 <andypost[m]> tboerger docker images for edge arm could get rebuild but as https://github.com/gliderlabs/docker-alpine/pull/465#issuecomment-456177202 images not ready
2019-02-04 14:25:41 <ncopa> Re #9959 I think we can add a soname prefix to libressl
2019-02-04 14:48:43 <tboerger[m]> andypost: yeah, have seen that issue. but won't resolve my issue on short-term. for now i have worked around that.
2019-02-04 15:44:30 <clandmeter> ncopa: doesnt look like soname prefix will change pc:name
2019-02-04 17:47:03 <jwh> ugh, forgot how to do the supervise magic already
2019-02-04 17:51:48 <mps> jwh: you mean supervise with openrc?
2019-02-04 17:51:52 <jwh> ye
2019-02-04 17:52:00 <jwh> supervisor-daemon, remembered now :D
2019-02-04 17:52:31 <mps> I'm using runit, much beter than openrc supervise
2019-02-04 17:53:03 <jwh> gotta work for most users though, otherwise i'd probably agree
2019-02-04 17:53:59 <mps> thought to send proposal to build runit busybox applets by default
2019-02-04 17:54:16 <mps> i.e. enable in busybox config
2019-02-04 17:54:25 <jwh> hm, tricky to support both by default though right?
2019-02-04 17:54:52 <mps> no, if you don't need apk don't install it
2019-02-04 17:55:01 <jwh> ah
2019-02-04 17:55:20 <jwh> ok i've got a dilemma here
2019-02-04 17:55:48 <jwh> do I a) start the applications the way they are intended to be, or use hacky methods to appease openrc and potentially put users in a situation where it isn't supported
2019-02-04 17:56:55 <mps> aha, you want it packaged and not for your personal use. then openrc is right path, I presume
2019-02-04 17:57:11 <jwh> well, personal use too of course
2019-02-04 17:57:22 <jwh> but its pretty decent software so everyone should be able to use it
2019-02-04 17:57:43 <mps> understand, but you are just another user of the package
2019-02-04 17:58:24 <jwh> afterall, if I use it there is more chance of it being maintained - I guess thats true for most people/packages
2019-02-04 17:59:30 <mps> of course
2019-02-04 18:01:02 <jwh> got a few decisions to make about how I do this
2019-02-04 18:01:58 <jwh> the entire package is only 10MB, seems silly to split it up and try and get the file lists right for the sake of maybe a couple of MB
2019-02-04 18:02:13 <jwh> since the shared libs/utilities take up a fair amount
2019-02-04 18:02:42 <jwh> and really, they work in concert anyway so the roles aren't strictly defined
2019-02-04 18:07:58 <clandmeter> jwh: smaller isn't silly. Alpine is small by design.
2019-02-04 18:08:49 <clandmeter> Our decisions are always to try to keep things minimal as possible.
2019-02-04 18:09:59 <jwh> well, it's also a balance between size and utility right?
2019-02-04 18:12:18 <clandmeter> I'm just referring to your remark. Ofc it needs to make sense.
2019-02-04 18:15:17 <clandmeter> I think 10mb is not so small, but compared to a similar app it could be.
2019-02-04 18:15:35 <jwh> well its like 7 vpn protocols, server, bridge and client
2019-02-04 18:15:53 <clandmeter> Ah that one
2019-02-04 18:15:55 <jwh> but client and server might use bridge in common configs etc, so I'm not sure it makes sense
2019-02-04 18:23:05 <jwh> guess I can submit it as-is and see if it draws any coments
2019-02-04 18:23:07 <jwh> comments*
2019-02-04 18:59:34 <ncopa> clandmeter: you are right re sonameprefix and pc:*
2019-02-04 19:00:27 <ncopa> some options we have
2019-02-04 19:00:44 <ncopa> we could introduc a pcprefix, similar to sonameprefix
2019-02-04 19:01:34 <ncopa> and set libressl to use pcprefix="libressl:" so the provides becomes "pc:libressl:libssl"
2019-02-04 19:03:15 <ncopa> the other option is to add an explicit depends=openssl-dev to all the packages depending on pc:libssl, pc:libcrypto and pc:openssl
2019-02-04 19:04:00 <ncopa> an third option is to remove the pc:* provides from libressl package
2019-02-04 19:04:34 <ncopa> that way you would need to explicitly add libressl-dev to depends, or you would get the provides from openssl
2019-02-04 19:04:57 <ncopa> no, that wont work
2019-02-04 19:05:23 <ncopa> you'd end up depending on both libressl-dev and an automatic pc:libssl
2019-02-04 19:05:32 <ncopa> which would pull in openssl in addition
2019-02-04 19:41:30 <SpaceToast> Another option could be to add a priority system for pc: (and so and cmd... while we're at it)
2019-02-04 19:42:01 <SpaceToast> And let it resolve automatically (i.e if libressl is in world, it's preferred even if lower priority)
2019-02-04 19:46:09 <ncopa> that is an interesting idea
2019-02-04 19:47:00 <ncopa> i think we sort of have that already
2019-02-04 19:47:03 <ncopa> with versions
2019-02-04 19:47:15 <ncopa> it prioritizes the highest versino
2019-02-04 19:47:19 <ncopa> version*
2019-02-04 19:47:44 <ncopa> but will use the installed if it satisfies the dependency
2019-02-04 19:48:00 <ncopa> unless --update is added as option
2019-02-04 19:48:28 <SpaceToast> yes - apk prioritizes the highest version
2019-02-04 19:48:33 <SpaceToast> which suggests it can prioritize any metric
2019-02-04 19:48:49 <ncopa> what we need is to make apk explicitly use libressl-dev if that was the one that was used during build
2019-02-04 19:48:58 <SpaceToast> version numbers might not match for providers (e.g libressl and openssl, what we're running into), so it's not the best priority indicator
2019-02-04 19:49:25 <ncopa> we cannot use exact version numbers either
2019-02-04 19:49:29 <SpaceToast> so all that'd need to happen to make priorities a reality is just check if priority is a variable in APKBUILD, if yes, then use the highest "priority", if not, use highest version
2019-02-04 19:49:35 <ncopa> since libressl may get updated
2019-02-04 19:49:37 <SpaceToast> I'm envisoning something like niceness :)
2019-02-04 19:50:02 <SpaceToast> so APKBUILD could have priority=0 on libressl and priority=10 on openssl, so openssl would get autoselected unless libressl is already there
2019-02-04 19:50:27 <ncopa> i don think that is correct in this case
2019-02-04 19:50:58 <ncopa> if libressl was used during build then it must pick libressl, regardless of what is currently there
2019-02-04 19:51:05 <SpaceToast> hmm
2019-02-04 19:51:30 <SpaceToast> maybe an option to disable automatic so: pc: etc detection (which'd require them to be manually enumerated) then?
2019-02-04 19:52:15 <ncopa> yes, but its somewhat tricky
2019-02-04 19:52:19 <ncopa> to give an example
2019-02-04 19:52:37 <ncopa> libfoo is build with makedepends=libressl-dev
2019-02-04 19:53:03 <ncopa> libfoo-dev ends up with a depends=pc:libssl
2019-02-04 19:53:47 <SpaceToast> sure, but both of those are in foo/APKBUILD (or libfoo)
2019-02-04 19:54:25 <SpaceToast> so if that APKBUILD has options=!autodepend, the developer would need to do dev() { depends="libressl" default_dev }
2019-02-04 19:54:28 <ncopa> if we remove the provides=pc:libssl in libressl, how does abuild know that it also should be removed from libfoo-dev?
2019-02-04 19:54:55 <ncopa> we'd need options=!autodepend in libfoo
2019-02-04 19:56:09 <ncopa> and if we are aware of that there, then we could as well have done depends=libressl-dev
2019-02-04 19:56:35 <ncopa> this becomes sort of tricky when the dependeny is indirect
2019-02-04 19:57:33 <SpaceToast> well yes
2019-02-04 19:57:35 <SpaceToast> that's what I meant
2019-02-04 19:57:39 <SpaceToast> !autodepend would be in libfoo
2019-02-04 19:57:42 <ncopa> so what i want is to specify in the libressl APKBUILD, that every package that may end up on libressl-dev as dependency should automatically set !autodepend and instead depend on libressl-dev
2019-02-04 19:57:43 <SpaceToast> (foo/APKBUILD - see above)
2019-02-04 19:58:24 <ncopa> we sort of have this in with shared libraries
2019-02-04 19:58:44 <SpaceToast> are there any scenarios where pc: is not accompanies by an so:?
2019-02-04 19:58:54 <ncopa> yes
2019-02-04 19:59:29 <ncopa> if the provides=so:something is missing, abuild will resolve the dependency and automatically add the package hat provides the file as direct dependency
2019-02-04 19:59:43 <ncopa> this is from before we had support for provides in apk
2019-02-04 20:00:28 <ncopa> so, if we in libressl has a pcprefix="libressl:" and libressl-dev gets a provides="pc:libressl:libssl"
2019-02-04 20:01:25 <ncopa> then we during build of libfoo need to check if the needed libssl has a prefix or not
2019-02-04 20:01:49 <ncopa> s/has a prefix/has a pcprefix/
2019-02-04 20:01:49 <alpine-meetbot> ncopa meant to say: then we during build of libfoo need to check if the needed libssl has a pcprefix or not
2019-02-04 20:02:08 <ncopa> and use the pcprefix if its there
2019-02-04 20:03:28 <ncopa> that way, if libfoo has makedepends="libressl-dev", it will when adding the depends to libfoo detect that it needs libssl pkg-config file
2019-02-04 20:03:58 <ncopa> but instead of blindly add pc:libssl (like it does now), it will check if the current installed .pc file has a pcprefix
2019-02-04 20:04:38 <ncopa> so, find the .pc file, find the what package provides that file, list the providers of that package
2019-02-04 20:04:57 <ncopa> and search for pc:*libssl
2019-02-04 20:05:17 <ncopa> and use what it finds as depends
2019-02-04 20:05:23 <ncopa> i think that would work
2019-02-04 20:06:09 <ncopa> but can we solve this in a simpler way?
2019-02-04 20:06:19 <SpaceToast> that does indeed sound pretty complex
2019-02-04 20:07:00 <ncopa> i dont like it beacause its complext
2019-02-04 20:07:33 <ncopa> a second option is to do:
2019-02-04 20:08:19 <ncopa> in libressl we add options="!autopc" (or "!autopcprovides" or whatever we end up call it")
2019-02-04 20:08:47 <ncopa> which will make abuild skip adding the provides=pc:*
2019-02-04 20:11:00 <ncopa> when abuild later build libfoo, it will see that it depends on a libssl.pc file, but instead of blindly add depends=pc:libssl, it will verify that something installed is actually providing it, and if not, it will find which package that provides the needed, currently installed, libssl.pc file, and add that as an explicit depends not libfoo-dev
2019-02-04 20:11:29 <ncopa> s/not/to/
2019-02-04 20:11:29 <alpine-meetbot> ncopa meant to say: when abuild later build libfoo, it will see that it depends on a libssl.pc file, but instead of blindly add depends=pc:libssl, it will verify that something installed is actually providing it, and if to, it will find which package that provides the needed, currently installed, libssl.pc file, and add that as an explicit depends not libfoo-dev
2019-02-04 20:12:10 <ncopa> s/depends not/depends to/
2019-02-04 20:12:10 <alpine-meetbot> ncopa meant to say: when abuild later build libfoo, it will see that it depends on a libssl.pc file, but instead of blindly add depends=pc:libssl, it will verify that something installed is actually providing it, and if to, it will find which package that provides the needed, currently installed, libssl.pc file, and add that as an explicit depends to libfoo-dev
2019-02-04 21:01:46 <AinNero> protonesso: i do remember you!
2019-02-04 21:02:38 <AinNero> how did you find here?
2019-02-04 21:03:31 <protonesso> Who are you
2019-02-04 21:04:34 <protonesso> AinNero
2019-02-04 21:05:41 <AinNero> you made pull requests with my commits in it between forks of sabotage linux
2019-02-04 21:05:52 <AinNero> i blocked you to stop the notification spam
2019-02-04 21:05:58 <AinNero> i think late 2016 or early 2017
2019-02-04 21:06:34 <AinNero> huge PITA
2019-02-04 21:10:57 <protonesso> oh
2019-02-04 21:11:50 <protonesso> Yeah I did it
2019-02-04 21:11:58 <protonesso> for fun
2019-02-04 21:12:20 <protonesso> AinNero: let's go to offtopic channel?
2019-02-04 21:17:28 <clandmeter> ncopa: still here?
2019-02-04 21:17:35 <ncopa> im here
2019-02-04 21:17:42 <clandmeter> nice :)
2019-02-04 21:17:54 <clandmeter> what about $provider_priority
2019-02-04 21:17:54 <ncopa> for 15-30mins or so i think
2019-02-04 21:19:11 <clandmeter> cant we somehow use?
2019-02-04 21:19:14 <ncopa> the problem with provider priority is that it may say that openssl-dev satisfies the dependency if libressl is missing, even if it at some point had higher priority
2019-02-04 21:19:54 <ncopa> we dont want one of them to be prioritized, we want one of them as exclusive dep
2019-02-04 21:20:34 <clandmeter> ok
2019-02-04 21:21:29 <protonesso> ncopa: can you add tigervnc?
2019-02-04 21:21:44 <ncopa> probably, but not now
2019-02-04 21:21:52 <protonesso> I compiled it today on my pc
2019-02-04 21:21:56 <ncopa> maybe in two weeks or so
2019-02-04 21:22:39 <ncopa> im officially on vacation so i will only deal with emergencies
2019-02-04 21:23:03 <clandmeter> ncopa: i have a patch (kind of ready) to add support for extra fw option in our release scripts.
2019-02-04 21:23:09 <protonesso> font-utils was broken when I was compiling xorg-server for tigervnc
2019-02-04 21:23:27 <clandmeter> it would be nice if we could add it when we do 3.9.1 so we are able to fix rpi wifi.
2019-02-04 21:23:36 <protonesso> I was needed to recompile it
2019-02-04 21:23:59 <protonesso> and then autoreconf -fiv worked
2019-02-04 21:24:36 <clandmeter> seems rpi fw will pull in another fw so modinfo doesnt detected this.
2019-02-04 21:24:37 <ncopa> clandmeter: ok
2019-02-04 21:24:42 <protonesso> ncopa: I think you should consider it
2019-02-04 21:25:01 <protonesso> also disable nls when you're building tigervnc package
2019-02-04 21:25:34 <protonesso> else you'll have errors with musl libintl
2019-02-04 21:25:47 <ncopa> protonesso: if font-utils is broken, can you please file a bug report on bugs.a.o with all the details and i´ll have a look at it when i get a chance (not now)
2019-02-04 21:26:06 <protonesso> I'll do it tomorrow
2019-02-04 21:26:09 <clandmeter> ncopa: do we have a shortime solution to address the bootdelay issues because of lack of entropy?
2019-02-04 21:26:19 <clandmeter> i mean as a note somwhere
2019-02-04 21:27:20 <ncopa> the best thing i can think of is to add it to a FAQ
2019-02-04 21:27:55 <ncopa> we have a FAQ on the wiki we could use til we have a better place
2019-02-04 21:28:07 <ncopa> unless SpaceToast has better idea
2019-02-04 21:28:27 <clandmeter> would it be an option to detect entropy at boot and display a message if its low?
2019-02-04 21:28:47 <ncopa> hm
2019-02-04 21:28:50 <clandmeter> sshd and ntpd needs some
2019-02-04 21:28:58 <ncopa> and wpa_supplicant
2019-02-04 21:29:11 <clandmeter> i think on real hw we dont see it (yet)
2019-02-04 21:29:19 <clandmeter> its mostly vm's
2019-02-04 21:29:22 <ncopa> i think it would be so much easier if we just enabled the "trust hw" by default
2019-02-04 21:29:28 <ncopa> it happens on my lappy
2019-02-04 21:29:34 <ncopa> with wpa_supplicant
2019-02-04 21:29:38 <clandmeter> ah ok
2019-02-04 21:30:28 <clandmeter> we could enable it by default and make it an option in the installed to opt-out
2019-02-04 21:30:41 <clandmeter> but you like to skip questions in the installer :)
2019-02-04 21:31:10 <ncopa> yeah, i dont think we want ask questions in the installer
2019-02-04 21:31:13 <ncopa> hum...
2019-02-04 21:31:22 <ncopa> i think this is somewhat tricky
2019-02-04 21:31:56 <ncopa> i wonder if there are any other distro that choses to not trust the cpu?
2019-02-04 21:32:08 <ncopa> i guess they all select "trust cpu rng"
2019-02-04 21:32:18 <ncopa> which i think was the default previously
2019-02-04 21:32:46 <clandmeter> im sure the outcome would not be acceptable for them.
2019-02-04 21:33:08 <ncopa> exactly
2019-02-04 21:33:23 <ncopa> it would be interesting to check what other distros do here
2019-02-04 21:34:19 <ncopa> if we chose to trust the cpu we have the argument that "all(?) other distros does, so we are not any worse, and if its a problem for you, then please add the needed boot option"
2019-02-04 21:35:29 <ncopa> i wonder if we could check in setup-alpine who much entropy there is and if we detect that it is too low, we set the boot option to trust cpu
2019-02-04 21:36:02 <ncopa> so the most common cases, like vms, things will work
2019-02-04 21:36:25 <clandmeter> problem is upgrades
2019-02-04 21:36:37 <ncopa> but we at the same time make it visible for end user (via /proc/cmdline) that we have set it for them
2019-02-04 21:36:39 <ncopa> yeah
2019-02-04 21:37:20 <ncopa> hm
2019-02-04 21:37:42 <ncopa> i think we have an issue related to this
2019-02-04 21:39:40 <clandmeter> i think a warning would kind of alarm systems that have upgraded.
2019-02-04 21:42:36 <ncopa> i cannot find the issue
2019-02-04 21:43:42 <ncopa> can you please create an issue on bugs.a.o, with the details, also mentioning that while this can be fixed via adding boot option from installer, it is a problem for upgraders
2019-02-04 21:43:52 <ncopa> and mark it "high"
2019-02-04 21:44:25 <ncopa> then we also have paper trail for any decision we do regarding this
2019-02-04 21:46:34 <mps> ncopa: SpaceToast and I made some short notes about boot delay regarding RDRAND, two days ago
2019-02-04 21:47:46 <mps> we started from here http://tpaste.us/xpjD and ended with this https://tpaste.us/YMww maybe could be useful
2019-02-04 21:48:47 <ncopa> its useful
2019-02-04 21:49:00 <ncopa> but i wonder if we should change our kernel config
2019-02-04 21:49:14 <ncopa> would be good to know what other distros do
2019-02-04 21:49:18 <mps> you decide, but imo we should not
2019-02-04 21:50:19 <mps> I stated it clearly in the first version of notes why, but I'm not one who have last words, I prefer some kind of consuses
2019-02-04 21:50:33 <ncopa> i guess the quick fix would be to add it to some FAQ
2019-02-04 21:50:40 <ncopa> and point users who gets affected
2019-02-04 21:50:43 <mps> eh, and SpaceToast reworded it nicely
2019-02-04 21:50:53 <ncopa> perfect
2019-02-04 21:51:06 <ncopa> im ok to add it to the official release notes for 3.9.0
2019-02-04 21:51:35 <mps> I think the best place would be to add it to release note, or better short link to that FAQ
2019-02-04 21:51:48 <ncopa> and send an email to alpine-use (and maybe alpine-devel), pointing to the FAQ
2019-02-04 21:52:19 <mps> very good idea, I think :)
2019-02-04 21:52:25 <ncopa> but it would also be nice if people who do `apk upgrade` gets some sort of warning about it
2019-02-04 21:52:51 <mps> yes, but I don't have idea how to add this
2019-02-04 21:53:18 <ncopa> i guess first step is to ad it to notes and FAQ
2019-02-04 21:53:23 <ncopa> and then send email about it
2019-02-04 21:53:27 <ncopa> so people are aware
2019-02-04 21:53:36 <mps> I agree
2019-02-04 21:53:53 <ncopa> i think we also should create a ticket on bugs.a.o, so people can follow the progress
2019-02-04 21:54:23 <ncopa> and can come with feedback or suggestions how to fix it
2019-02-04 21:54:25 <mps> there is a ticket, I think, maybe just add FAQ to it
2019-02-04 21:54:36 <ncopa> ok
2019-02-04 21:55:29 <ncopa> i could not find the other ticket
2019-02-04 21:55:34 <ncopa> thanks clandmeter!
2019-02-04 21:55:56 <ncopa> ok, good, then users can see that we are aware of the issue
2019-02-04 21:56:15 <ncopa> mps: can you please add your notes to the FAQ in wiki?
2019-02-04 21:57:18 <mps> let me elaborate a little my thought about that issue (RDRAND) in my not perfect English. Alpine is 'marketed' as Secure and if the something which is not agreed by big  community would be source of criticism to Alpine
2019-02-04 21:57:29 <clandmeter> i think whats really bad imho is that ppl would like to try alpine in a vm
2019-02-04 21:57:40 <clandmeter> but they cant even boot it properly now :(
2019-02-04 21:57:47 <mps> will add it, in a ten/twenty minutes
2019-02-04 21:57:55 <ncopa> yes, its not good that its "broken" by default
2019-02-04 21:58:27 <mps> does vm's have rdrand?
2019-02-04 21:58:47 <mps> for VM's virtio-rng is solution
2019-02-04 21:59:28 <clandmeter> mps: what if you vps provider doesnt expose the device?
2019-02-04 22:00:02 <ncopa> will virtio-rng be autoloaded?
2019-02-04 22:00:14 <mps> but, you all core devs should decide, whatever you agree, for me personally it is not problem
2019-02-04 22:00:26 <ncopa> or maybe I have to enable the device in my qemu
2019-02-04 22:00:38 <clandmeter> i think thats what has to happen
2019-02-04 22:00:44 <clandmeter> not sure though
2019-02-04 22:01:04 <mps> clandmeter: if the vps provider doesn't expose device than you have no choice anyway, or I'm wrong
2019-02-04 22:01:56 <ncopa> so, the big unknowns here is: "how big problem is it", "how bad is it to trust the hw rng"
2019-02-04 22:02:16 <mps> for VPS without emulated device there is haveged and also for physical devices without god source of entropy
2019-02-04 22:02:49 <clandmeter> ok maybe i didnt catch your point mps
2019-02-04 22:02:55 <mps> ncopa: I feel somehow that that question will not be answered soon
2019-02-04 22:03:01 <clandmeter> i thought you said its THE solution :)
2019-02-04 22:03:37 <ncopa> short term solution is to document how to workaround it if/when you are affected
2019-02-04 22:03:55 <clandmeter> even if disabling is best, we cannot remove features without letting users know.
2019-02-04 22:03:55 <ncopa> long term will be to decide if we should change kernel config
2019-02-04 22:04:14 <mps> that question started a lot of heated discussions on many security list or forums for some years without clear conclusion
2019-02-04 22:04:26 <SpaceToast> imo it's better to trust it by default
2019-02-04 22:04:34 <SpaceToast> people react to things being slow by "speeding them up"
2019-02-04 22:04:43 <SpaceToast> often in ways that are much much worse than the thing that was originally being avoided
2019-02-04 22:04:46 <ncopa> that is what the kernel commit says. they pushed problem downstream
2019-02-04 22:05:00 <SpaceToast> (e.g see suggestions to run find / to "populate rng" when generating x.509 certs)
2019-02-04 22:05:21 <mps> I had idea to propose two lines in boot menu: boot secure and slow and another boot fast
2019-02-04 22:06:06 <mps> maybe better: "boot secure and maybe slow" and another "boot fast ???"
2019-02-04 22:06:50 <clandmeter> the issue here is that secure doesnt need to be slow.
2019-02-04 22:07:14 <mps> clandmeter: you already added FAQ, nice
2019-02-04 22:07:26 <ncopa> i dont remember if I mentioned this issue on the alpine-devel mailing list?
2019-02-04 22:07:31 <ncopa> we should discuss it there
2019-02-04 22:07:40 <mps> yes, because that I added 'maybe'
2019-02-04 22:07:43 <clandmeter> mps faq?
2019-02-04 22:08:03 <mps> no, in bugs.a.o
2019-02-04 22:08:36 <clandmeter> ah ok
2019-02-04 22:08:37 <clandmeter> yes
2019-02-04 22:08:40 <clandmeter> i copied your info
2019-02-04 22:08:42 <ncopa> i will be afk for a couple of days
2019-02-04 22:09:06 <mps> I see, and not only my but SpaceToast also
2019-02-04 22:09:21 <clandmeter> ncopa: do you have time to fix the sigs?
2019-02-04 22:09:39 <mps> do you have little time to ask state of llvm upgrade?
2019-02-04 22:10:06 <ncopa> clandmeter: not really. i think that may need to wait til i get access to my work computer (mid Feb)
2019-02-04 22:10:35 <clandmeter> ok
2019-02-04 22:10:54 <clandmeter> at least we can tell that to some users. they were asking for it.
2019-02-04 22:11:10 <mps> ok, just to tell that the llvm7 is broken with gcc 8.2 They plan to release llvm7.1.x but don't know when
2019-02-04 22:11:49 <mps> so, for now I will concentrate on llvm6 and other tools
2019-02-04 22:11:59 <ncopa> mps: sound good
2019-02-04 22:12:43 <ncopa> i think my first thing to do is fix the pkg-config provides issue in abuild (#9959)
2019-02-04 22:12:44 <mps> for now we don't have other choices. I actually build it and build new crystal with llvm6
2019-02-04 22:13:32 <ncopa> i think we will have to add support to abuild for pcprefix in abuild
2019-02-04 22:13:41 <mps> thinking aloud, maybe it would be better to send llvm questions to alpine-devel ML, than here?
2019-02-04 22:13:54 <ncopa> send it to alpine-devel
2019-02-04 22:14:04 <ncopa> then we also get the discussion archived
2019-02-04 22:14:12 <mps> ok, good night to all
2019-02-04 22:14:24 <ncopa> i need to go too
2019-02-04 22:14:39 <ncopa> clandmeter: big thanks!
2019-02-04 22:14:50 <ncopa> i owe you a couple of beers now...
2019-02-04 22:15:01 <clandmeter> for breaking your holiday?
2019-02-04 22:15:03 <clandmeter> :p
2019-02-04 22:16:29 <clandmeter> Brahma or Antarctica  would be fine ;-)
2019-02-04 22:44:31 <clandmeter> mps, i added a simple howto regarding wireguard on wiki. i remember you asked for it.
2019-02-04 22:58:51 <mps> clandmeter: thanks, I see it
2019-02-04 23:04:00 <mps> no need for wg-quick, I see
2019-02-04 23:08:31 <SpaceToast> clandmeter: ip-route shouldn't be needed with address+netmask, and I use $IFACE in the {pre,post}-{up,down} segments
2019-02-04 23:08:34 <SpaceToast> otherwise looks good!
2019-02-05 08:38:20 <tmhoang> clandmeter: so it seems the ntpd + sshd delay at boot time is due to lack of entropy as you mentioned earlier. Interesting, I missed that.
2019-02-05 08:40:12 <danieli> sounds plausible
2019-02-05 08:40:34 <danieli> install and run haveged, and consider enabling any hardware randomness sources if any are present
2019-02-05 08:41:21 <rnalrd> tmhoang, on bare metal?
2019-02-05 08:41:41 <tmhoang> rnalrd: I'm rolling in vms :D
2019-02-05 08:42:11 <tmhoang> 2019-02-04 21:47:46 <mps> we started from here http://tpaste.us/xpjD and ended with this https://tpaste.us/YMww maybe could be useful ->
2019-02-05 08:43:20 <rnalrd> tmhoang, yeah, solved with rng-tools
2019-02-05 08:43:51 <rnalrd> tnx, nice option
2019-02-05 08:44:16 <tmhoang> yeah understood, thanks. I'm looking for the exact kernel cmdline because sometimes I need to boot via netboot (i,e. can't yet install rng-tools or haveged)
2019-02-05 08:45:41 <tmhoang> or add pkgs=
2019-02-05 08:45:56 <tmhoang> pkgs=rng-tools,haveged
2019-02-05 08:47:50 <clandmeter> that wont start them afaik
2019-02-05 08:48:15 <clandmeter> the cmdline is random.trust_cpu=on
2019-02-05 08:48:18 <tya99> may or may not be helpful (it's for a RP) https://wiki.alpinelinux.org/wiki/Linux_Router_with_VPN_on_a_Raspberry_Pi#Random_number_generation
2019-02-05 08:48:39 <tya99> more so how to configure rng-tools cos the documentation sucks
2019-02-05 08:48:57 <tmhoang> clandmeter: that's the one
2019-02-05 08:50:05 <tmhoang> doc ain't no suck :P
2019-02-05 08:50:17 <tya99> no for rng-tools it did
2019-02-05 08:50:29 <tmhoang> I mean edit it
2019-02-05 08:50:33 <tya99> when i was using alpine linux 3.7 it stopped working when i upgraded to 3.8
2019-02-05 08:50:42 <tya99> so yeah i wrote that wiki article there
2019-02-05 08:50:55 <tya99> i mean upstream's documentation on rng-tools afaik
2019-02-05 08:51:18 <tmhoang> hm. understood. thanks
2019-02-05 08:51:54 <tya99> that bit there at the bottom changed
2019-02-05 08:52:03 <tya99> ie RNGD_OPTS
2019-02-05 08:55:03 <tya99> ScrumpyJack: https://git.alpinelinux.org/aports/tree/community/rng-tools/APKBUILD you should update the url
2019-02-05 08:55:27 <tya99> sourceforge has no version 6 https://sourceforge.net/projects/gkernel/files/rng-tools/
2019-02-05 08:56:12 <tya99> looks like it's now on github https://github.com/nhorman/rng-tools
2019-02-05 08:56:38 <TBB> yeah, the conf.d entry has needed a change since version 5 already IIRC
2019-02-05 08:57:05 <rnalrd> conf.d entry was updated by me, and was included in v3.9
2019-02-05 08:57:27 <tya99> ah
2019-02-05 09:17:59 <clandmeter> AinNero: ^
2019-02-05 09:18:57 <AinNero> 
ACTION grumbles

2019-02-05 09:19:23 <clandmeter> you are the initramfs master :)
2019-02-05 09:19:33 <AinNero> i'd really like to have push access or a staging repo on g.a.o
2019-02-05 09:20:20 <AinNero> (for mkinitfs)
2019-02-05 09:21:39 <AinNero> seems like the staging area on g.a.o is rather unused..
2019-02-05 09:22:09 <clandmeter> what do you mean with staging area?
2019-02-05 09:23:48 <AinNero> own git tip where i can merge stuff in, and the head maintainer only merges that tip in
2019-02-05 09:24:10 <AinNero> differently from PRs that it usually contains several commits, probably also merged from other people
2019-02-05 09:24:29 <_ikke_> So you mean branch ACLs
2019-02-05 09:25:05 <AinNero> sort of.
2019-02-05 09:28:22 <clandmeter> AinNero: you mean a staging repo to share with other users, or a user repo where you can push yourself and we pull from?
2019-02-05 09:29:06 <clandmeter> for the record, we can provide user repos for users that contribute regularly.
2019-02-05 09:29:39 <clandmeter> for aports it just easier to do PR based style cause it supports travis.
2019-02-05 09:29:56 <AinNero> mh
2019-02-05 11:52:59 <fcolista> gns3 is broken after the upgrade qt5 upgrade to 5.11
2019-02-05 11:53:59 <fcolista> http://pyqt.sourceforge.net/Docs/PyQt5/incompatibilities.html#pyqt-v5-11
2019-02-05 12:41:55 <jwh> hm
2019-02-05 12:42:51 <jwh> should really fix the installer so it works OOTB on v6 only
2019-02-05 12:46:39 <jwh> or is it that the website(s) only have v4
2019-02-05 12:50:14 <jwh> actually, this one won't even resolve anythign
2019-02-05 12:50:29 <jwh> even though the nameserver given is reachable
2019-02-05 12:51:08 <jwh> what gives?
2019-02-05 12:51:35 <jwh> ohhh hang on
2019-02-05 12:51:48 <jwh> ok
2019-02-05 15:36:57 <jwh> if I have multiple init scripts, will -openrc package magic handle that ok?
2019-02-05 15:38:01 <jwh> also I think I'm gonna seperate this out, but I'm not sure how to handle multiple packages in a single apkbuild - is there an example of another that does it cleanly?
2019-02-05 15:39:52 <TBB> have a look at how hplip is packaged if your goal is to make separate packages instead of subpackages
2019-02-05 15:40:30 <jwh> well i'd like to keep it in the apk build, but I can at least make it a bit more user friendly by allowing the client to be installed without the server
2019-02-05 15:40:35 <jwh> if that make sense
2019-02-05 15:41:01 <TBB> I'm strictly guessing (although it's a bit of an educated guess) that the magic is just splitting openrc files to a subpackage if they reside under /etc/init.d/
2019-02-05 15:41:36 <TBB> yeah, it makes sense, you could in that case just use -client and -server subpackages
2019-02-05 15:41:40 <jwh> init files as well yeah, but a couple of libraries and some binaries
2019-02-05 15:41:51 <jwh> yeah thats what I wanna do
2019-02-05 15:49:34 <jwh> hm
2019-02-05 15:50:02 <jwh> hplip doesn't really seperate them out, guessing -libs will just package libraries seperately?
2019-02-05 15:57:54 <TBB> oh yeah, I selected that package as an example because it, IIRC, makes a completely separate package not named like standard subpackages
2019-02-05 15:58:21 <jwh> oh right, yeah, hm
2019-02-05 15:59:11 <tmhoang> rnalrd: oh now the czmq situation has not been resolved yet on s390x .... https://github.com/alpinelinux/aports/pull/6187
2019-02-05 15:59:20 <jwh> hm
2019-02-05 15:59:22 <rnalrd> yeah, just noticed
2019-02-05 15:59:35 <jwh> not sure how i should do this then...
2019-02-05 15:59:59 <tmhoang> never mind, we could just let the builder spitting failure for a few days until ncopa is back
2019-02-05 16:00:05 <tmhoang> if that's ok for you
2019-02-05 16:00:08 <jwh> unless the main package installs the client and -server is a subpackage
2019-02-05 16:00:44 <tmhoang> I should have mentioned that in the comment for maintainers, like you. Would do next time, rnalrd.
2019-02-05 16:00:56 <rnalrd> np, tnx
2019-02-05 16:01:10 <tmhoang> I'm heading home. Nice a good night
2019-02-05 16:01:16 <TBB> jwh, I'd use $pkgname as a meta package that installs both and package $pkgname-server and $pkgname-client separately
2019-02-05 16:01:16 <tmhoang> *Have
2019-02-05 16:01:16 <rnalrd> i should have double checked depends througly
2019-02-05 16:01:25 <rnalrd> EoD here too
2019-02-05 16:01:25 <rnalrd> cy
2019-02-05 16:01:27 <rnalrd> cu*
2019-02-05 18:29:27 <psih0man> hello! I'm using alpine linux stable on raspberrypi 3 and I want to setup a personal router. For this, I would like to install openconnect, but I can see it is not packaged yet in official or community provided repos. Can you please add this package in one of your next releases? :)
2019-02-05 18:31:11 <psih0man> I also tried to join #alpine-linux, but I couldn't, for some reason... So I sincerely appologise if this is not the place to make such a request.
2019-02-05 18:32:01 <jwh> submit a PR :D
2019-02-05 18:32:08 <psih0man> I want to congratulate you for this nice piece of work!
2019-02-05 18:32:56 <_ikke_> psih0man: What happens when you try to join #alpine-linux?
2019-02-05 18:34:01 <psih0man> _ikke_, it says that my nickname is not registered and I need to login. however, I am logged in with a username and a passowrd
2019-02-05 18:34:27 <psih0man>  #alpine-linux :Cannot join channel (+r) - you need to be identified with services - see https://freenode.net/kb/answer/registration
2019-02-05 18:34:46 <jwh> you're not identified
2019-02-05 18:35:27 <psih0man> I do not understand what identification means, aside from logging in with NickServ
2019-02-05 18:35:36 <jwh> yes, that, but you aren't logged in
2019-02-05 18:35:56 <jwh> you have to login each time you connect...
2019-02-05 18:36:39 <psih0man> I automatically log in. I'm using HexChat and I set it up to log me in each time I start i up.. Let me paste the log
2019-02-05 18:37:02 <clandmeter> Try it manually
2019-02-05 18:37:04 <jwh> you're really not logged in
2019-02-05 18:38:01 <clandmeter> Add please don't paste in this channel
2019-02-05 18:38:45 <psih0man> You are right: I was not identified. Now I am and I successfully joined the other channel.
2019-02-05 18:38:47 <jwh> oh phew, I thought I'd immediately gotten everything I had learnt about building go just then...
2019-02-05 18:38:48 <psih0man> Thank you.
2019-02-05 18:38:52 <jwh> the horror
2019-02-05 18:39:02 <jwh> ugh, forgotten*
2019-02-05 18:51:17 <jwh> is there a post install message or something?
2019-02-05 18:53:55 <_ikke_> Nothing built-in afaik
2019-02-05 18:54:00 <_ikke_> Just an echo in a post-inst script
2019-02-05 18:54:39 <jwh> ah that will do
2019-02-05 18:54:54 <clandmeter> Which we prefer you don't use like that
2019-02-05 18:54:56 <jwh> or I could just put some notes in conf.d, people should really check those before starting anyway
2019-02-05 18:55:45 <jwh> just need to figure how to capture the stdout now and direct it somewhere useful
2019-02-05 18:56:06 <jwh> unless openrc has something already that can capture it
2019-02-05 18:57:12 <jwh> oh looks like it got something in .37
2019-02-05 18:58:04 <jwh> not really sure how to apply that to init.d though
2019-02-05 19:07:00 <jwh> right wel thats one more package off my list, even if it isn't ready yet
2019-02-05 20:49:45 <AinNero> ncopa: do you have a list on mkinitfs issues?
2019-02-05 21:05:42 <AinNero> im still working on a testing setup for mkinitfs
2019-02-05 21:05:59 <AinNero> because its rather painful to test several usecases manually
2019-02-05 21:08:00 <clandmeter> AinNero: he wont be back for some time.
2019-02-05 21:08:11 <AinNero> oh.
2019-02-05 21:08:17 <AinNero> why?
2019-02-05 21:08:23 <clandmeter> holidays
2019-02-05 21:08:56 <AinNero> oh, a dayjob maintainer
2019-02-05 21:16:40 <AinNero> clandmeter: the libressl/openssl issue seems trivial, but testing is difficult
2019-02-05 21:17:22 <jwh> crazy, linux-vanilla ci job is still going
2019-02-05 21:17:53 <clandmeter> it will probably timeout
2019-02-05 21:18:01 <jwh> ah heh
2019-02-05 21:18:10 <jwh> all that building for a one line change
2019-02-05 21:19:10 <clandmeter> AinNero: i can test it locally, i just dont have time atm.
2019-02-05 21:19:49 <AinNero> like i said, currently working on a test suite with qemu and expect
2019-02-05 21:29:48 <jwh> The job exceeded the maximum time limit for jobs, and has been terminated.
2019-02-05 21:29:49 <jwh> heh
2019-02-05 21:48:29 <ddevault> anything special I should do when sending an aports patch that should be backported to 3.9?
2019-02-05 21:52:51 <ddevault> I'm just gonna mention it in the patch commentary
2019-02-06 08:19:02 <tmhoang> rnalrd: please just leave all my current open issues as is and don't merge them. I'm waiting ncopa back for discussion.
2019-02-06 08:20:12 <rnalrd> tmhoang, including the clocksource thing?
2019-02-06 08:20:19 <tmhoang> yeah everything
2019-02-06 08:20:25 <rnalrd> k
2019-02-06 08:20:36 <tmhoang> that's my proposal, other dev want changes
2019-02-06 08:20:48 <tmhoang> thanks
2019-02-06 08:20:53 <rnalrd> yw
2019-02-06 11:26:38 <PureTryOut[m]> is there a way to do something like `install_if="$pkgname && !$someotherpackage"`?
2019-02-06 11:29:02 <_ikke_> PureTryOut[m]: Can't seem to find an existing case
2019-02-06 11:29:39 <PureTryOut[m]> Damn
2019-02-06 11:32:37 <PureTryOut[m]> Oh I see abuild now supports git checkouts? That's awesome
2019-02-06 11:33:09 <AinNero> ... now? did i miss a change?
2019-02-06 11:41:31 <PureTryOut[m]> Well, it didn't last time I checked, but that was quite a while ago
2019-02-06 11:42:02 <PureTryOut[m]> I've been downloading tar archives when using specific commits, but that seems unessecary now.
2019-02-06 13:16:38 <clandmeter> sigh, grub is awful
2019-02-06 13:18:21 <AinNero> there is syslinux for efi, but i dont know the reasoning while alpine doesn't use it
2019-02-06 13:21:05 <clandmeter> i have no clue how to load all_video.
2019-02-06 13:24:32 <mps> if I have board with uefi I will try syslinux uefi
2019-02-06 13:25:11 <clandmeter> i think the problem is that this box is booted via efi and grub doesnt load the correct video drivers
2019-02-06 13:30:38 <clandmeter> we need a proper wiki entry for this crap
2019-02-06 13:31:33 <AinNero> i'd surely love to do this, but i still got enough work to do on mkinitfs
2019-02-06 13:32:13 <clandmeter> what is the diff btween all_video and all other video drivers?
2019-02-06 16:33:51 <tomc> Can someone please point me to any documentation on how to use github.com/alpinelinux/aports/scripts/bootstrap.sh?
2019-02-06 16:36:20 <AinNero> tomc: what are you trying to do?
2019-02-06 16:37:06 <tomc> I'm trying to create a build environment to build armhf packages on an x86_64 host.#
2019-02-06 16:37:26 <danieli> why not qemu?
2019-02-06 16:37:56 <tomc> Because it's docker I'm trying to build and building it under qemu takes >8 hours.
2019-02-06 16:38:23 <AinNero> cross-compiling for many packages is broken, and thats not our fault
2019-02-06 16:38:50 <AinNero> the bootstrap mechanism is more to cross-compile the base system
2019-02-06 16:39:02 <AinNero> so the other packages can be compiled non-cross via qemu
2019-02-06 16:39:35 <tomc> Understood.  I'm happy hacking around the docker source to make it build, or to accept that it can't be done if it can't be done.  But so far the bootstrap.sh script fails to build a gcc cross-compiler at all.
2019-02-06 16:40:59 <AinNero> is it a requirement to build it yourself?
2019-02-06 16:41:11 <AinNero> because there are armhf rootfs tarballs available
2019-02-06 16:42:24 <tomc> But that won't include the cross-compiler, will it?
2019-02-06 16:43:16 <AinNero> no, with the rootfs, you use qemu and compile 'natively'
2019-02-06 16:45:18 <AinNero> have you previously made software to cross-compile?
2019-02-06 16:46:38 <tomc> Yes, I've built a cross-compiler using crosstool-ng in an alpine docker container and used this to recompile docker.  It's rather complicated though, because the resulting toolchain isn't multiarch-aware and so there is lots of hacking around pkgconfig files and so on.
2019-02-06 16:46:54 <tomc> I was trying bootstrap.sh to see if it produced a more workable build environment.
2019-02-06 16:47:16 <AinNero> uhm, are you just after the toolchain?
2019-02-06 16:47:48 <sorear> can you get a working docker without gcc at all?  it's a Go program…
2019-02-06 16:48:08 <tomc> It's a go program, but it uses CGO & so requires a working target C compiler.
2019-02-06 16:48:27 <tomc> It depends on lvm2-dev, btrfs-progs-dev and libltdl.
2019-02-06 16:48:34 <tomc> As C dependencies.
2019-02-06 16:50:02 <AinNero> RE: multiarch-aware
2019-02-06 16:50:12 <AinNero> you used -L and -I and sysroot?
2019-02-06 16:51:13 <tomc> Yes.  But the docker source uses pkg-config to set GCC options.  And the libdevmapper pkg-config file has the library directory hard-coded as /lib.
2019-02-06 16:51:25 <tomc> So it ends up trying to link the host libdevmapper.so.
2019-02-06 16:51:36 <AinNero> pkgconfig has a sysroot path for that
2019-02-06 16:52:20 <AinNero> iirc PKG_CONFIG_SYSROOT_DIR
2019-02-06 16:52:59 <tomc> Well there you go, you live and learn.
2019-02-06 16:53:10 <tomc> Thanks.
2019-02-06 16:53:31 <tomc> Is the advice then definitely not to use an environment produced by bootstrap.sh to cross-compile apk packages?
2019-02-06 16:54:49 <AinNero> if you are able to make it work for your usecase, you might as well use it
2019-02-06 16:58:00 <AinNero> but its not an user-friendly interface for a task, its more like an instruction for experienced users where to start trying
2019-02-06 16:58:57 <AinNero> afk for a while
2019-02-06 17:00:15 <tomc> Thanks for your help.
2019-02-06 19:23:24 <ddevault> ERROR: py3-six-1.11.0-r0: BAD signature
2019-02-06 19:23:26 <ddevault> on edge
2019-02-06 19:27:45 <_ikke_> apparently it has been reverter
2019-02-06 19:27:47 <_ikke_> reverted
2019-02-06 19:29:51 <ddevault> should I open a ticket on bugs.alpinelinux.org?
2019-02-06 19:29:55 <_ikke_> hold on
2019-02-06 19:31:26 <_ikke_> Can you try again?
2019-02-06 19:31:33 <ddevault> yup
2019-02-06 19:31:36 <_ikke_> ddevault: are you using x86_64?
2019-02-06 19:31:39 <ddevault> yes
2019-02-06 19:31:40 <_ikke_> ok
2019-02-06 19:31:50 <ddevault> works :)
2019-02-06 19:31:51 <_ikke_> I purged it from fastly
2019-02-06 19:31:52 <ddevault> thanks!
2019-02-06 19:31:58 <_ikke_> np
2019-02-06 19:32:55 <jwh> v6? *runs*
2019-02-06 19:33:08 <ddevault> hm
2019-02-06 19:33:15 <_ikke_> ?
2019-02-06 19:33:21 <ddevault> I say fixed, but only in my isolated test case
2019-02-06 19:33:26 <ddevault> https://builds.sr.ht/~sircmpwn/job/26570
2019-02-06 19:33:31 <ddevault> failed in the real deal https://builds.sr.ht/~sircmpwn/job/26571
2019-02-06 19:33:35 <ddevault> lemme try again, maybe it's a fluke
2019-02-06 19:37:20 <ddevault> bizzare. It works when I apk add py-six but not when abuild -r picks it up
2019-02-06 19:37:49 <ddevault> oh! _ikke_ py3-six is separately broken
2019-02-06 19:37:55 <ddevault> I bet py2-six as well
2019-02-06 19:38:19 <ddevault> aye, it is
2019-02-06 19:38:22 <_ikke_> I purged all 3
2019-02-06 19:38:29 <_ikke_> py-six py3-six and py2-six
2019-02-06 19:38:34 <_ikke_> just now
2019-02-06 19:38:37 <ddevault> ty, let's see
2019-02-06 19:39:01 <ddevault> yep, all in working order. Thanks again!
2019-02-06 19:40:26 <_ikke_> \o/
2019-02-07 00:01:30 <jwh> ah this is perverse, having to boot arch to get alpine on these VMs
2019-02-07 04:09:44 <oko72> anybody alive
2019-02-07 04:10:27 <SpaceToast> nope, only the undead roam these halls
2019-02-07 04:13:57 <oko72> I am run Xen Dom0 on 3.9.0 release with a major caveat
2019-02-07 04:14:41 <oko72> Namely two servers I have were originally installed with 3.5 xen-hardened kernel on the top of LVM SSD
2019-02-07 04:15:31 <oko72> I was unable to replace hardened kernel with vanilla kernel during 3.7 to 3.8 upgrade
2019-02-07 04:15:57 <oko72> due to the fact that xen-vanilla could not find volume groups.
2019-02-07 04:16:17 <oko72> so I still have Linux xen1.int.autonlab.org 4.9.65-1-hardened #2-Alpine
2019-02-07 04:16:38 <SpaceToast> strange, sounds more like an initrd thing
2019-02-07 04:16:45 <SpaceToast> but I've never so much as touched xen
2019-02-07 04:17:00 <oko72> I have not done anything fancy during the 3.5 installation. I was following installer options.
2019-02-07 04:17:32 <oko72> I am fully aware that if I chose physical block device instead of LVM I would not have any problems replacing
2019-02-07 04:17:38 <oko72> hardened kernel with vanilla
2019-02-07 04:17:50 <oko72> I have done that on my test system.
2019-02-07 04:18:11 <SpaceToast> AinNero: any ideas?
2019-02-07 04:18:22 <oko72> Is there anything I can do to replace obsolete hardened kernel with vanilla
2019-02-07 04:18:53 <SpaceToast> well I'm not actually sure what's wrong with your system
2019-02-07 04:18:58 <SpaceToast> vanilla kernel SHOULD have support for lvm
2019-02-07 04:19:05 <oko72> more mkinitfs.conf
2019-02-07 04:19:09 <SpaceToast> yes
2019-02-07 04:19:12 <oko72> features="ata base ide scsi usb virtio ext4 lvm"
2019-02-07 04:19:13 <SpaceToast> "could not find volume groups" isn't particularly descriptive
2019-02-07 04:20:24 <oko72> Please check http://collabedit.com/8n9aj
2019-02-07 04:20:55 <oko72> When I try to boot vanilla kernel boot process complain that can't find /dev/vg0/lv_root
2019-02-07 04:21:52 <oko72> I meant to say that I get dropped to  initramfs console
2019-02-07 04:23:08 <oko72> I reported the "upgrade bug" https://bugs.alpinelinux.org/issues/9062
2019-02-07 04:23:46 <oko72> The bug is very easy to reproduce. Just do a fresh installation of 3.7 xen with hardened kernel on the LVM instead of pure block device
2019-02-07 04:24:26 <oko72> then try to upgrade by editing /etc/apk/repositories
2019-02-07 04:24:58 <oko72> and running apk update, apk upgrade, sync, reboot.
2019-02-07 04:25:06 <oko72> You will break your test system
2019-02-07 04:27:24 <oko72> Also Ubuntu 18.04 netplan seems to break vif driver. I can't get Ubuntu 18.04.1 to run as DomU
2019-02-07 04:27:47 <oko72> I am awaiting for 18.04.2 to released to try again.
2019-02-07 04:28:50 <oko72> What would be the simplest way to backup existing configuration files and do a fresh installation?
2019-02-07 04:29:08 <oko72> lbu?
2019-02-07 04:29:40 <oko72> I am long time OpenBSD users but not very skilled with Alpine which I use only as Xen Dom0
2019-02-07 04:30:18 <SpaceToast> hmm, I'm not sure if lbu can do that, but I don't really use it
2019-02-07 04:30:28 <SpaceToast> lbu is meant for "diskless" style installs
2019-02-07 04:30:38 <SpaceToast> (where it backs up configuration files, and then loads them into tmpfs during boot)
2019-02-07 04:31:54 <SpaceToast> oko72: you see how your extlinux.conf has modules=sd-mod,usb-storage,ext4 ?
2019-02-07 04:32:51 <SpaceToast> can you try adding `dm-mod` to that list?
2019-02-07 04:32:59 <SpaceToast> (just as a test :) )
2019-02-07 04:36:47 <oko72> I can try adding dm-mod to the list but not tonight. I only have remote access to production systems
2019-02-07 04:37:02 <oko72> Breaking them tonight might mean that I don't have a job tomorrow.
2019-02-07 04:37:12 <SpaceToast> ok, do try that, and/or anything AinNero suggests (an initrd contributor around here)
2019-02-07 04:37:36 <oko72> I will hang around for AinNero suggestions
2019-02-07 04:38:09 <oko72> Any comments on Ubuntu 18.04.1 netplan network problems.
2019-02-07 04:38:41 <oko72> I have few Ubuntu 16.04 DomUs and I am holding upgrade for now
2019-02-07 04:38:54 <SpaceToast> netplan is stupid and never should have been made the default
2019-02-07 04:39:01 <SpaceToast> but that's not really related to alpine development :)
2019-02-07 04:39:02 <oko72> +1
2019-02-07 04:39:10 <oko72> +1
2019-02-07 04:39:34 <oko72> I 100% agree with both statements but id doesn't hurt to ask
2019-02-07 04:40:13 <SpaceToast> there's always #alpine-linux (for alpine queries that are not development-related) and #alpine-offtopic (for anything you want!)
2019-02-07 04:40:27 <SpaceToast> I'm znc-detached from the former, but any channel I'm in, I can always be summoned to by mentioning my nickname
2019-02-07 04:43:45 <oko72> I tried on  #alpine-linux but no luck. I can live with broken 18.04 DomUs but I will have to do something about hardened kernel
2019-02-07 04:44:07 <oko72> IIRC that thing is not going to be supported for a vary long time.
2019-02-07 04:44:23 <oko72> I will have to replace it with vanilla one way or another.
2019-02-07 09:02:11 <AinNero> oko72: do you have /etc/mkinitfs/mkinitfs.conf.apk-new ?
2019-02-07 13:08:46 <PureTryOut[m]> so I'm trying to build Qt4 (don't ask me why lol) but it fails in the packaging fase. `attr_set: No such file or directory. Could not set "pax.flags" for /home/pmos/build/pkg/qt/usr/bin/qmlviewer`. Is pax even used anymore? Could I just remove the `paxmark` command?
2019-02-07 13:10:13 <p4Wv1qn095FW> correct
2019-02-07 13:25:54 <tmhoang> what is kernel module name to get lvm working at boot time (getting /dev/vg0/lv_root up) ?
2019-02-07 13:39:15 <tmhoang> dm-mod ?
2019-02-07 13:40:25 <clandmeter> modprobe dm-mod
2019-02-07 13:42:15 <tmhoang> clandmeter: yes sir
2019-02-07 13:42:38 <tmhoang> after upgrading to edge, my alpine s390x box can't boot... investigating
2019-02-07 13:43:57 <danieli> strange, any interesting output?
2019-02-07 13:50:14 <tmhoang>  /dev/vg0/lv_root can't be brought up. I'm trying to create a new initramfs by booting from netboot and chroot into the disk.
2019-02-07 13:51:25 <tmhoang> I got a rescue shell here, # lsmod shows no dm_mod kernel module
2019-02-07 13:51:34 <AinNero> ehh
2019-02-07 13:51:42 <clandmeter> wasnt there another user with similar issue?
2019-02-07 13:51:43 <tmhoang> I should add "lvm" to /etc/mkinitfs/mkinitfs.conf and rerun mkinitfs
2019-02-07 13:51:49 <AinNero> same as https://bugs.alpinelinux.org/issues/9062
2019-02-07 13:51:51 <AinNero> ?
2019-02-07 13:52:02 <AinNero> clandmeter: yeah, now im panicking
2019-02-07 13:52:28 <tmhoang> I got these all the time back when I'm dev-ing 3.7-3.8 s390x port but need to recal ...
2019-02-07 13:52:48 <AinNero> tmhoang: you upgraded from which version to which?
2019-02-07 13:52:52 <tmhoang> from 3.9
2019-02-07 13:52:57 <tmhoang> from 3.9 to edge
2019-02-07 13:53:07 <tmhoang> no, let me remember ...
2019-02-07 13:54:07 <tmhoang> I'm always on edge to be exact, and I just apk upgrade today.
2019-02-07 13:54:23 <tmhoang> havent done so since 3.9.0 release
2019-02-07 14:05:23 <tmhoang> so as I said, I netboot and mount the disk, chroot, downgrade kernel from 4.19.19(edge) to 4.19.18 (v3.9) and it boots for me ( thanks to presence of dm-mod.ko)
2019-02-07 14:05:46 <tmhoang> so linux-vanilla in edge is missing dm-mod.ko or mkinitfs in edge is not including it
2019-02-07 14:06:24 <clandmeter> https://pkgs.alpinelinux.org/contents?file=dm-mod.ko&path=&name=linux-vanilla&branch=edge
2019-02-07 14:06:38 <clandmeter> i dont think its the kernel
2019-02-07 14:06:42 <tmhoang> clandmeter: so it is mkinitfs business
2019-02-07 14:07:02 <AinNero> there had been 3 patches via aports
2019-02-07 14:07:46 <AinNero> between 3.9 and edge
2019-02-07 14:08:35 <tmhoang> AinNero: Probably earlier than 3.9. I've always on edge and I don't remember exactly when was the last time I ran apk upgrade ...
2019-02-07 14:08:55 <AinNero> are you connected via serial?
2019-02-07 14:09:00 <tmhoang> kind of
2019-02-07 14:09:20 <AinNero> could you capture the console/printk output when debug_init is enabled?
2019-02-07 14:09:32 <AinNero> debug_init is a kernel command line option
2019-02-07 14:09:36 <tmhoang> I'm back to business with it :D
2019-02-07 14:09:52 <tmhoang> don't want to apk upgrade again just to reproduce the bug :D
2019-02-07 14:09:52 <tmhoang> sorry
2019-02-07 14:09:56 <clandmeter> tmhoang: the module is not included in initramfs?
2019-02-07 14:10:02 <tmhoang> yes sir
2019-02-07 14:10:10 <tmhoang> I'm back to 4.19.18
2019-02-07 14:10:11 <clandmeter> what does that mean?
2019-02-07 14:10:16 <clandmeter> yes its not?
2019-02-07 14:10:19 <clandmeter> :)
2019-02-07 14:10:22 <tmhoang> not included :D
2019-02-07 14:10:28 <AinNero> oh, that would be the cause then
2019-02-07 14:10:45 <tmhoang> yeah, since mkinitfs does not include dm-mod -> initramfs does not have it
2019-02-07 14:11:34 <tmhoang> I could reproduce tonight when I'm off the clock ...
2019-02-07 14:16:20 <AinNero> tmhoang: is the lvm in your /etc/mkinitfs/mkinitfs.conf?
2019-02-07 14:16:35 <AinNero> because per default its not, but that wouldn't explain why it worked previously
2019-02-07 14:16:45 <tmhoang> now yes
2019-02-07 14:17:32 <AinNero> that fixed it?
2019-02-07 14:17:54 <AinNero> usually setup-disk inserts it there
2019-02-07 14:19:34 <tmhoang> hum... it was there. I don't remember if I insert it manually or setup-disk.
2019-02-07 14:20:30 <AinNero> hm, i'll try to reproduce later this day
2019-02-07 16:15:34 <vkrishn> hi, since grsec is not being used, would adding 'aufs' as module still be an issue ?
2019-02-07 16:17:57 <vkrishn> if its ok, I can add a request in bugs.a.o
2019-02-07 17:25:32 <AinNero> oko72: i updated from 3.8.2 to edge on a lvm system and could not reproduce your issue
2019-02-07 18:42:31 <PureTryOut[m]> I'm trying to build a package that is looking for the "qtwaylandscanner" binary via cmake. Since this binary isn't in `/usr/bin` but in `/usr/lib/qt5/bin`, it can not find it and the compilation fails. I could manually symlink the binary to the right spot, but that is most definitely wrong. How would I work around this?
2019-02-07 21:11:36 <AinNero> can someone reproduce this? boot the 3.9.0 virt iso in qemu and try setup-alpine
2019-02-07 21:11:55 <AinNero> setup-apkrepos hangs on fetching the mirror list
2019-02-07 21:15:13 <AinNero> pcap dump shows that some communication is taking place: http://0x0.st/zsd5.txt
2019-02-07 22:01:08 <skyne98> Hello there, everyone!
2019-02-07 22:02:03 <skyne98> I have a slightly unusual question, is it ok if I ask it here?
2019-02-07 22:02:32 <_ikke_> Hard to tell without seeing the actual question ;-)
2019-02-07 22:06:32 <skyne98> Well, I have an idea of creating a rust-oriented linux distro (a toy one for now) and I have been looking for a good "platform" for it. I am trying to look for a very small distro, which can be very lightweight (small amount of packages, access to low-level configurations), has a permissive license and doesn't use systemd. Basically, I am looking for something as close to a bare kernel as possible.
2019-02-07 22:06:33 <skyne98> Alpine linux is an amazing project, so I wonder if it can become a foundation for my little project.
2019-02-07 22:07:21 <_ikke_> I don't see why not (not an official answer from Alpine Linux though)
2019-02-07 22:08:16 <_ikke_> only downside might be that alpine is based on musl
2019-02-07 22:09:32 <skyne98> Yeah, this is one of the reasons why I decided to ask here first. Does Alpine linux at all support usual dynamically linked binaries?
2019-02-07 22:10:08 <_ikke_> sure, enough projects use dynamically linked libraries
2019-02-07 22:10:51 <skyne98> In that case, were can alpine being based on musl start being a problem?
2019-02-07 22:11:06 <mps> skyne98: would you mind to tell a little more what you mean by 'rust-oriented linux distro'
2019-02-07 22:11:30 <SpaceToast> we have rust, and cargo, and they (usually) work
2019-02-07 22:11:40 <_ikke_> skyne98: when code depends on glibc features
2019-02-07 22:11:58 <SpaceToast> dynamically linked binaries work fine with musl - the reason static linking is mentioned a lot is because it's horribly broken with glibc, but not with musl
2019-02-07 22:13:43 <skyne98> mps: the general idea is to toy around with writing custom operating system elements from scratch in rust. Some of the interesting components are already available, such as full wayland server/client libraries, which makes it even more interesting
2019-02-07 22:14:08 <skyne98> Also rust because it's the only system language I can somewhat write code in
2019-02-07 22:14:35 <mps> you want to have linux kernel, libc and rest in rust, if i understood you
2019-02-07 22:15:26 <skyne98> mps: yes, in the beginning also some init system, device daemon and stuff like this
2019-02-07 22:15:29 <mps> i.e. all userspace written in rust
2019-02-07 22:15:43 <skyne98> exactly
2019-02-07 22:16:17 <skyne98> if you are interested in the general concept, I can share a small primer on google docs, but it's mostly ideas scribbled down on paper
2019-02-07 22:16:24 <mps> rust works fine on Alpine with musl, but only x86_64 for now
2019-02-07 22:17:33 <mps> you only have to start write code and keep in mind that you need llvm to build rust
2019-02-07 22:18:08 <skyne98> I think that in the beginning I can limit myself to using binaries built on the host system
2019-02-07 22:18:41 <mps> well, shell could work as init system also
2019-02-07 22:19:47 <skyne98> I agree, but writing my own init script and daemons goes way out of scope of my knowledge for now
2019-02-07 22:22:22 <skyne98> What will be the best place to start? Aports?
2019-02-07 22:22:47 <_ikke_> To start with what exactly?
2019-02-07 22:23:33 <mps> just finished patches for llvm6 batteries :) I deserve a little rest/siesta
2019-02-07 22:23:46 <_ikke_> mps: sleep tight ;)
2019-02-07 22:23:57 <skyne98> Have a nice sleep :)
2019-02-07 22:24:03 <skyne98> Thanks for your help, mps
2019-02-07 22:24:46 <skyne98> _ikke_: to setup a small repo which will allow me to make quick test builds, maybe introduce a couple of packages
2019-02-07 22:24:49 <mps> _ikke_: thanks, but I suspect that the some code from clang will stay in my head as was last night in bed :)
2019-02-07 22:25:14 <_ikke_> skyne98: I would create separate repositories to host the actual code
2019-02-07 22:25:37 <_ikke_> skyne98: then you could create APKBUILDS that fetch the code from those repos to create actual apks
2019-02-07 22:26:16 <skyne98> _ikke_: Hm, so basically make my own "repository"?
2019-02-07 22:26:21 <mps> skyne98: some basic codes in linux distro deserve rewrite in better C++, i.e. Rust
2019-02-07 22:26:51 <mps> basic daemons and utilities, I mean
2019-02-07 22:27:16 <skyne98> mps: maybe one day I will be able to rewrite a couple of important system binaries myself and be useful :D
2019-02-07 22:27:42 <_ikke_> skyne98: yes
2019-02-07 22:28:01 <_ikke_> skyne98: aports only hosts APKBUILD definitions + auxilery files
2019-02-07 22:28:30 <mps> some are already rewritten, and I find it quite interesting, even started to learn rust a more seriously
2019-02-07 22:28:58 <skyne98> _ikke_: my idea was to basically make one package with my own "package manager" (which doesn't yet exist) and then use it to set the system up
2019-02-07 22:29:15 <skyne98> mps: really? specifically in Alpine, or in the linux community in general?
2019-02-07 22:29:35 <mps> Alpine, before all. of course
2019-02-07 22:29:41 <_ikke_> skyne98: sure, that can work
2019-02-07 22:30:54 <mps> I'm working to bootstrap rust on ARM for Alpine. I have it working for aarch64 and armv7 but not yet ready for builders
2019-02-07 22:31:24 <_ikke_> going to sleep, night all
2019-02-07 22:31:32 <skyne98> _ikke_: good night
2019-02-07 22:31:45 <mps> good night :)
2019-02-07 22:31:59 <skyne98> mps: what are the complications? rustc itself doesn't want to be built with musl on arm?
2019-02-07 22:32:38 <jwh> hmph
2019-02-07 22:32:43 <mps> upstream (to say mildly) is not friendly for musl on ARM's
2019-02-07 22:32:55 <mps> and for musl in general
2019-02-07 22:32:58 <jwh> why is this box timing out for gpg key fetching
2019-02-07 22:33:40 <jwh> weird
2019-02-07 22:34:17 <skyne98> mps: in my own experience, rust is still super funky with its musl builds. I haven't managed to build nearly any pure-rust libs using musl target, which quite weird, imho
2019-02-07 22:35:40 <jwh> oh
2019-02-07 22:35:42 <mps> I built some test programs on x86_64, aarch64 and armv7 without big problems. Only big package which tried is firefox
2019-02-07 22:35:45 <jwh> shady ipv6 support bites again
2019-02-07 22:35:46 <jwh> sigh
2019-02-07 22:39:19 <skyne98> mps: I tried building gfx-rs, webrender and servo crates, which all seem very important to me
2019-02-07 22:39:32 <skyne98> also I have tried building alacritty
2019-02-07 22:39:48 <skyne98> nothing worked for me, unfortunately (out of the box)
2019-02-07 22:41:37 <mps> you mean on Alpine?
2019-02-07 22:42:52 <skyne98> nope, mostly on ubuntu
2019-02-07 22:42:59 <skyne98> I haven't used alpine ever (yet)
2019-02-07 22:45:37 <jwh> umm
2019-02-07 22:45:38 <jwh> lol
2019-02-07 22:46:20 <mps> I don't have to make/program anything in rust rihgt now but learning it at slow pace to use it for system programming when I will have to do such 'things'
2019-02-07 22:47:58 <mps> I wasted about year on golang in the hope that it could be system programming language, but I was wrong
2019-02-07 22:49:24 <skyne98> btw, guys, should I try using alpine instead of ubuntu? I am that kind of a person that always attracts towards interesting projects, but I am slightly afraid of jumping to alpine as my daily-driver (mostly because I have only recently started having a stable experience on linux, having learnt more stuff)
2019-02-07 22:51:12 <mps> skyne98: It took me about six months before I finally decide that I will use Alpine. Tried it in qemu, on arm SBC's and played with some time before full switch
2019-02-07 22:51:35 <skyne98> mps: what are the benefits?
2019-02-07 22:51:41 <mps> after more than twenty years of experience with debian
2019-02-07 22:52:46 <mps> benefits: as Alpine www page says: Small, Simple, Secure. And I would add Fast but really Fast!
2019-02-07 22:53:55 <skyne98> what about nvidia proprietary drivers?
2019-02-07 22:55:25 <mps> doesn't work, to put simply. Alpine have poor support for anything proprietary
2019-02-07 22:55:38 <mps> closed source, I mean
2019-02-07 23:00:25 <skyne98> that's some bad news, has anyone tried manually running the installer from Nvidia drivers website?
2019-02-07 23:02:01 <TBB> it's that good old "glibc only" problem I guess; could work with the required compatibility layer, but the lack of a wiki article indicates nobody's managed to get it to work just yet
2019-02-07 23:03:26 <skyne98> what if you don't REALLY mind glibc that much?
2019-02-07 23:03:44 <skyne98> linux distro is a linux distro after all, right?
2019-02-07 23:04:58 <mps> skyne98: I tried, and after some time asked self: on what I'm wasting time. And now I fully understand Linus's comment "**** you, Nvidia"
2019-02-07 23:05:00 <TBB> but then the question becomes, why Alpine at all... and I say that as someone who both likes running Alpine and would love to utilize his nVidia products beyond what nouveau has support for
2019-02-07 23:05:41 <skyne98> true, true
2019-02-07 23:06:32 <skyne98> but does nouveau support vulkan?
2019-02-07 23:06:38 <skyne98> I wonder
2019-02-07 23:08:19 <mps> I have a luck to have also Intel card on notebook so just disabled nvidia and 'forgot' that it is inside
2019-02-07 23:11:14 <skyne98> unfortunately I am dual xeon + gtx 1060, so it's my only graphics card
2019-02-07 23:18:28 <mps> skyne98: sorry, late is here. going to sleep. good night :)
2019-02-07 23:21:31 <skyne98> mps: good night, thanks for your time :)
2019-02-07 23:23:34 <mps> you are welcome, see you :)
2019-02-07 23:29:44 <skyne98> see you!
2019-02-07 23:41:27 <skyne98> ok, I go now too, guys, have a nice sleep
2019-02-08 01:49:36 <notlistening> Hi all just looking for pointers on how to cross compile aports, which tools/package etc I should use.
2019-02-08 01:49:54 <notlistening> no * & jokes please
2019-02-08 02:17:14 <oko72> AinNero: yes I do have  /etc/mkinitfs/mkinitfs.conf.apk-new
2019-02-08 02:21:31 <oko72> AinNero: Of course you can't reproduce the issue from 3.8.2 to 3.9. You need to start with 3.7 xen-hardened on LVM and try to upgrade to 3.8.
2019-02-08 02:22:20 <oko72> Even 3.7 to 3.8 on regular disk works OK. The case I am reporting is from 3.7 LVM xen-hardened to 3.8 xen-vanilla
2019-02-08 02:22:29 <oko72> Then the things break
2019-02-08 02:25:49 <oko72> AinNero: mkinitfs.conf.apk-new doesn't contain LVM
2019-02-08 02:25:57 <oko72> AinNero features="ata base cdrom ext4 keymap kms mmc raid scsi usb virtio"
2019-02-08 02:26:06 <oko72> I am guessing I need to add LVM there?
2019-02-08 02:32:36 <oko72> AinNero: I am guessing I need to add lvm to mkinitfs.conf.apk-new and run mkinitfs
2019-02-08 09:06:20 <AinNero> oko72: lvm needs to be in mkinitfs.conf, the apk-new is what the package manager creates/changes upon update
2019-02-08 09:18:12 <ollieparanoid[m]> clandmeter, ncopa or anybody else: would be nice if you could take a look at this simple armv7 for nettle patch: https://github.com/alpinelinux/aports/pull/6256
2019-02-08 09:39:03 <mps> ollieparanoid[m]: is that problem for nettle or armv7
2019-02-08 10:15:55 <clandmeter> mps: its mentioned in the pr
2019-02-08 10:27:25 <mps> clandmeter: ah, I see. it is only for main/nettle and not armv7 in general.
2019-02-08 10:31:30 <PureTryOut[m]> I'm trying to build a package that is looking for the `qtwaylandscanner` binary via cmake. Since this binary isn't in `/usr/bin` but in `/usr/lib/qt5/bin`, it can not find it and the compilation fails. I could manually symlink the binary to the right spot before building, but that is most definitely wrong. How would I work around this?
2019-02-08 14:11:57 <oko72> AinNero: but my mkinitfs.conf does contain lvm features="ata base ide scsi usb virtio ext4 lvm"
2019-02-08 14:12:39 <oko72> however mkinitrs.conf.apk-new doesn't contain lvm
2019-02-08 14:12:58 <AinNero> thats to be expected, since apk-new is always the alpine default
2019-02-08 14:13:07 <oko72> AinNero however mkinitrs.conf apk-new doesn't contain lvm
2019-02-08 14:13:44 <oko72> AinNero: Any suggestions?
2019-02-08 14:14:14 <oko72> AinNero: Should I run mkinitrs after apk add linux-vanilla?
2019-02-08 14:14:32 <AinNero> mkinitfs is run automatically if you add or update kernels
2019-02-08 14:14:51 <oko72> AinNero: That is what I thought.
2019-02-08 14:15:32 <oko72> So I have a reproducible problem. If you start with 3.7 on LVM (xen-hardened) and try to upgrade to 3.8 xen-hardened things will work
2019-02-08 14:15:47 <AinNero> i havent got around to test the xen image
2019-02-08 14:16:02 <oko72> However once you add 3.8 xen-vanilla things will break
2019-02-08 14:16:41 <AinNero> i might test it later
2019-02-08 14:16:50 <oko72> and the damn thing can't find logical vollume
2019-02-08 14:16:52 <AinNero> do the xen images also work in qemu? without kvm support?
2019-02-08 14:17:11 <oko72> I have no idea I am running it on the physical hardware
2019-02-08 14:17:30 <AinNero> i dont have physical hardware to test it right now
2019-02-08 14:18:06 <oko72> Also as long as you use plain block device instead of lvm upgrade from 3.7 xen-hardened to 3.8 xen-vanilla things will work as expected
2019-02-08 14:18:36 <oko72> I can't believe I am the only one bitten by this. To make things funnier I really had no need for LVM.
2019-02-08 14:19:04 <oko72> I am just alpine noob so I pick LVM as that is default for the Red Hat which we use on all computing nodes in the LAB
2019-02-08 14:19:13 <AinNero> calm down god dammit
2019-02-08 14:19:43 <oko72> I am calm. Sorry if I came across as nervous.
2019-02-08 14:20:17 <AinNero> can you verify that the new initramfs (which doesn't boot) has the device mapper modules?
2019-02-08 14:20:30 <oko72> I can just reinstall the server once I have more time but I would prefer to fix things.
2019-02-08 14:21:40 <AinNero> yeah, and im currently trying to figure out what is wrong that could be fixed
2019-02-08 14:22:26 <AinNero> which is difficult because i dont have physical hardware around
2019-02-08 14:22:35 <AinNero> so i could tell you some things you could check
2019-02-08 14:23:44 <oko72> I just added linux-vanilla to 3.9 production server please see http://collabedit.com/5cwxh
2019-02-08 14:24:19 <oko72> now
2019-02-08 14:25:35 <AinNero> is the lvm/dm module in initramfs-hardened?
2019-02-08 14:28:41 <AinNero> zcat /boot/initramfs-hardened | cpio -t | grep dm_mod
2019-02-08 14:33:44 <AinNero> eh, in initramfs-vanilla
2019-02-08 14:33:55 <AinNero> is the lvm/dm module in initramfs-hardened?
2019-02-08 14:34:04 <AinNero> zcat /boot/initramfs-vanilla | cpio -t | grep dm_mod
2019-02-08 14:34:25 <oko72_> 69163 blocks
2019-02-08 14:34:41 <oko72_> looks like a binary file unless vi in the base can't display UTF
2019-02-08 14:35:39 <AinNero> dont know, initramfs have ever been binaries
2019-02-08 14:35:43 <AinNero> but thanks for the information
2019-02-08 14:36:04 <AinNero> but the hardened initramfs does have the kernel module?
2019-02-08 14:36:47 <oko72_> xen1:/boot# zcat /boot/initramfs-hardened | cpio -t | grep dm_mod
2019-02-08 14:36:56 <oko72_> 82895 blocks
2019-02-08 14:37:28 <oko72_> But as I said it look gibberish when I try to see with vi
2019-02-08 14:37:28 <AinNero> ye, my mistake, its dm-mod, not dm_mod
2019-02-08 14:37:55 <AinNero> oko72_: what did you expect to see?
2019-02-08 14:37:56 <oko72_> xen1:/boot# zcat /boot/initramfs-hardened | cpio -t | grep dm-mod
2019-02-08 14:37:58 <oko72_> lib/modules/4.9.65-1-hardened/kernel/drivers/md/dm-mod.ko
2019-02-08 14:38:04 <oko72_> 82895 blocks
2019-02-08 14:38:23 <oko72_> xen1:/boot# zcat /boot/initramfs-vanilla | cpio -t | grep dm-mo
2019-02-08 14:38:31 <oko72_> lib/modules/4.19.18-0-vanilla/kernel/drivers/md/dm-mod.ko
2019-02-08 14:38:39 <oko72_> 69163 blocks
2019-02-08 14:39:10 <oko72_> Looks like both initramfs files do have dm-mo kernel module
2019-02-08 14:40:06 <oko72_> AinNero: For some reason I thought initramfs-hardened and initramfs-vanilla were plain text files.
2019-02-08 14:40:23 <oko72_> My bad
2019-02-08 14:40:34 <oko72_> Alpine Linux n00b
2019-02-08 14:40:51 <SpaceToast> initramfs is always a cpio archive, on linux in general
2019-02-08 14:41:04 <SpaceToast> oko72_: have you tried adding dm-mod to the list of modules= in your kernel command line yet?
2019-02-08 14:41:26 <AinNero> what SpaceToast said
2019-02-08 14:41:27 <oko72_> Using OpenBSD most of my adult life. This is a paid job
2019-02-08 14:42:02 <oko72_> you see how your extlinux.conf has modules=sd-mod,usb-storage,ext4 ?
2019-02-08 14:42:10 <oko72_> can you try adding `dm-mod` to that list?
2019-02-08 14:42:24 <SpaceToast> yeah, that thing I suggested when you first came in, and you said you'd do it later :)
2019-02-08 14:43:17 <oko72_> I didn't have a physical access to the machine. I could not effort to break production server over night. I will again have access in about 2 h
2019-02-08 14:43:25 <oko72_> is that what you want me to add?
2019-02-08 14:44:16 <oko72_> AinNero: I didn't realized SpaceToast just joined. I posted his exact words
2019-02-08 14:44:37 <SpaceToast> I never left
2019-02-08 14:45:18 <oko72_> AinNero: Do you want me to follow on SpaceToast suggestion?
2019-02-08 14:45:21 <SpaceToast> and by my count that happened ~33h ago
2019-02-08 14:45:45 <AinNero> oko72_: you can try that, but i would be surprised if that would make a difference
2019-02-08 14:45:57 <AinNero> dm-mod module is usually autoloaded by lvm activity
2019-02-08 14:46:26 <AinNero> you could test that out by editing the kernel command line during boot
2019-02-08 14:48:22 <AinNero> if the lack of loaded dm-mod would be the issue, then my home laptop wouldn't boot as well
2019-02-08 14:49:29 <oko72_> Got it.
2019-02-08 14:50:54 <AinNero> since the difference between vanilla and xen-vanilla is basically just the hypervisor, i think this might be a kernel bug
2019-02-08 14:51:48 <oko72_> I am glad to hear that I am not crazy.
2019-02-08 14:52:22 <oko72_> I just can't believe I am the only one running Xen on the top of LVM. No other people complained
2019-02-08 14:53:03 <AinNero> maybe you are the only one who did <unsupported thing>
2019-02-08 14:53:07 <oko72_> and as I said the upgrade 3.7 xen-hardened to 3.8 xen-vanilla goes fine as long as you have just a HDD not LVM
2019-02-08 14:53:28 <oko72_> LVM is an option in the installer
2019-02-08 14:53:36 <AinNero> yes
2019-02-08 14:53:36 <AinNero> yes
2019-02-08 14:53:37 <oko72_> I realized that I should just gone with defaults
2019-02-08 14:53:48 <oko72_> It was too late.
2019-02-08 14:54:01 <oko72_> I have 2 production servers and 2 dozens of virtual machines
2019-02-08 14:54:19 <AinNero> how is your wife doing?
2019-02-08 14:55:00 <oko72_> Sorry I am not following your last question. Is that some kind joke?
2019-02-08 14:58:05 <AinNero> i dont know, this seemed like smalltalk to me
2019-02-08 15:00:21 <clandmeter> can we move this conversation to #alpine-linux please?
2019-02-08 15:00:29 <clandmeter> this is not a support channel
2019-02-08 15:10:22 <ncopa> hi, how are things going here?
2019-02-08 15:12:19 <AinNero> ncopa: lvm problems during updates, we dont know stuff, im still working on an testing rig for mkinitfs
2019-02-08 15:12:32 <AinNero> shouldn'
2019-02-08 15:12:41 <AinNero> *..'t you be on vacation ?
2019-02-08 15:12:47 <ncopa> i still am
2019-02-08 15:20:12 <ncopa> AinNero: is it reported on bugs.a.o?
2019-02-08 15:20:43 <AinNero> the wget timeout? or one of the two lvm issues?
2019-02-08 15:22:26 <ncopa> i was thinking of the lvm issues
2019-02-08 15:23:26 <AinNero> there is #9062
2019-02-08 15:24:25 <AinNero> i wrote some expect scripts for qemu, but that was unable to reproduce 9062
2019-02-08 15:24:38 <AinNero> but instead resulted in a functional system
2019-02-08 15:26:38 <ncopa> i wonder if it related the dom0 thingy?
2019-02-08 15:27:43 <AinNero> i guess so.
2019-02-08 15:31:16 <AinNero> maybe xen is testable with qemu
2019-02-08 15:37:24 <ncopa> i think kvm supports nested virt with a kernel module option
2019-02-08 15:37:43 <ncopa> i have mixed success with it earlier
2019-02-08 15:39:27 <AinNero> i think i might push for serial console support per default even in vanilla images
2019-02-08 15:39:34 <AinNero> so i can test them via expect scripts
2019-02-08 15:39:54 <AinNero> i'll show you the code when you are back to work
2019-02-08 15:41:21 <ncopa> ugh, the internet connection here is not good
2019-02-08 15:41:47 <ncopa> im having problem even with downloading the last emails
2019-02-08 15:41:58 <AinNero> vacation is not for working
2019-02-08 15:42:26 <AinNero> also, vacation is essential for stress-testing the truck factor
2019-02-08 15:43:00 <ncopa> indeed
2019-02-08 15:43:08 <AinNero> ah,. bus factorm usually
2019-02-08 15:43:15 <AinNero> train factor for TempleOS tho
2019-02-08 16:22:43 <tmhoang> I got the lvm issue yesterday. Mostly the cause is lvm is missing in the initramfs after upgrading kernel from 4.19.18 to 4.19.19. Dont know why "lvm" was removed in my mkinitfs.conf. Adding "lvm" back to it is fine though.
2019-02-08 16:31:00 <AinNero> tmhoang: i just updated my laptop to that version, i'll reboot it and hope it comes back up
2019-02-08 16:31:12 <tmhoang> :D
2019-02-08 16:31:44 <AinNero> i have to grab it anyways later this day
2019-02-08 16:32:30 <tmhoang> it's friday, take it easy and chill :D
2019-02-08 16:33:41 <AinNero> i got good news and bad news
2019-02-08 16:33:49 <AinNero> the good news, i can reproduce your issue
2019-02-08 16:33:58 <AinNero> the bad news, im off heading home. see ya!
2019-02-08 16:34:10 <_ikke_>  o/
2019-02-08 16:35:13 <tmhoang> :D
2019-02-08 16:35:23 <tmhoang> usb drive to rescue
2019-02-08 16:35:34 <tmhoang> _ikke_ have a good one!
2019-02-08 17:00:35 <AinNero> yeah, its failing at boot
2019-02-08 17:00:40 <AinNero> no lvm2 binary in initramfs
2019-02-08 17:29:21 <ncopa> huh? how come?
2019-02-08 17:31:00 <AinNero> other issue: 3.9 netboot ends up with zlib: BAD Signature
2019-02-08 17:31:09 <AinNero> means apk is missing symbols
2019-02-08 17:52:20 <danieli> i just had to fix my thoroughly broken arch system because of signature (gpg) issues :)
2019-02-08 17:53:34 <_ikke_> danieli: How did that happen?
2019-02-08 17:55:34 <danieli> upgraded readline to 8, which gpg depends on
2019-02-08 17:55:50 <danieli> i didn't fully explore it but 7 -> 8 broke it badly, and i had to reinstall 7 together with 8
2019-02-08 17:57:06 <_ikke_> I apparently already have readline 8
2019-02-08 18:01:29 <AinNero> i suspect my lvm problem is unrelated to tmhoang's issue
2019-02-08 18:01:49 <AinNero> "someone uninstalled lvm because they were unaware that the system was installed using lvm"
2019-02-08 18:21:22 <ncopa> i think the sed upgrade broke virtualbox-guest-modules-vanilla build
2019-02-08 18:28:46 <ncopa> sigh, ftp.gnu.org is down again
2019-02-08 18:28:54 <ncopa> http://ftp.gnu.org that is
2019-02-08 18:35:08 <jwh> hey ncopa
2019-02-08 18:35:16 <jwh> enjoying vacation? :D
2019-02-08 18:35:42 <ncopa> yeah, i am waiting for my OH, and am a bit bored...
2019-02-08 18:35:46 <jwh> ah
2019-02-08 18:39:56 <mps> OT, can project leader have holidays ;)
2019-02-08 18:40:20 <ncopa> ofc we can
2019-02-08 18:40:33 <ncopa> its just that getting back from holidays is a very bad idea :)
2019-02-08 18:40:59 <_ikke_> haha :D
2019-02-08 18:41:05 <ncopa> so if you take vacation, you should probably not return :)
2019-02-08 18:42:48 <mps> btw, anyone have comments on my mail to alpine-devel about llvm
2019-02-08 18:43:25 <ncopa> i havent dared to open the email...
2019-02-08 18:44:28 <mps> understand, and not asked you in the first place, but others who are 'at work'
2019-02-08 18:45:55 <ncopa> i quick read it
2019-02-08 18:46:26 <ncopa> re llvm3.9 i think we shoudl ask the maintainer (jirutka?), im in favor of removing it if nothing depends on it
2019-02-08 18:47:08 <ncopa> i suggest that you ask maintainer, and if you dont get any answer within reasonable time (a week?), you just go ahead and remove it
2019-02-08 18:48:46 <mps> I built and tested all batteries on x86_64, aarch64 and armv7. could post aports patches but had a hope that someone will have something to say about my proposal, so didn't posted them yet.
2019-02-08 18:49:37 <mps> well, llvm3.9 not a issue now, it could stay there some time without problem
2019-02-08 18:49:56 <ncopa> i want it removed unless something is depending on it
2019-02-08 18:50:05 <ncopa> i think there was something, crystal or something
2019-02-08 18:50:15 <ncopa> or maybe julia
2019-02-08 18:50:44 <mps> didn't found anything in main, commuunity and testing
2019-02-08 18:51:33 <ncopa> may be its _llvmver=3.9 depends=llvm$_llvmver or similar
2019-02-08 18:51:45 <mps> yes, julia depends on it, but julia is in unmaintained
2019-02-08 18:51:53 <ncopa> but its no hurry
2019-02-08 18:51:56 <ncopa> as you said
2019-02-08 18:52:26 <ncopa> ping me again next week (wednesday) if you dont get any feedback
2019-02-08 18:52:43 <mps> I don't know anything about julia, maybe it depends on this exact version
2019-02-08 18:52:58 <ncopa> i think it did
2019-02-08 18:53:08 <ncopa> i think i asked in some github PR at some point
2019-02-08 18:53:26 <ncopa> but i dont remember the details
2019-02-08 18:53:54 <mps> my question is, should I post patches for version 6 of llvm tools
2019-02-08 18:54:25 <ncopa> i think i would have preferred llvm7, but it depends on how difficult it is to fix it
2019-02-08 18:54:44 <ncopa> so i´d ask upstream if they have a simple patch for the gcc 8 problem
2019-02-08 18:54:58 <ncopa> or if they recommend wait for 7.1
2019-02-08 18:55:07 <mps> llvm7 have problems with gcc 8.2 toolchain
2019-02-08 18:55:43 <ncopa> question is how difficult it is to fix it
2019-02-08 18:56:04 <mps> they announced release 7.1.x but when it will be released no one told
2019-02-08 18:56:04 <ncopa> if its a one-liner patch, then i think we should go for that
2019-02-08 18:56:27 <ncopa> so they probably already have the patch for the gcc 8 fix somewhere
2019-02-08 18:56:47 <ncopa> but if its complictated to backport the fix to 7.0, then i think we can just go ahead and do llvm6
2019-02-08 18:56:53 <ncopa> since its already working
2019-02-08 18:57:01 <mps> I looked at patch and to me it is not simple, and not sure if it final which would solve issues
2019-02-08 18:57:06 <ncopa> ok
2019-02-08 18:57:14 <ncopa> then lets go for llvm6 for now
2019-02-08 18:57:48 <mps> when they release 7.1 we can try to add it, and we should add it
2019-02-08 18:57:53 <ncopa> yeah
2019-02-08 18:59:00 <ncopa> i dont have my email set up for responding atm
2019-02-08 18:59:02 <ncopa> sorry
2019-02-08 18:59:02 <mps> rust, crystal (and ponyc, iirc) depends on llvm6 for now, so we have to have llvm6 for some time, that is my understanding
2019-02-08 18:59:47 <mps> although rust and crystal also works with llvm5, too
2019-02-08 19:00:12 <mps> didn't looked deeply in ponyc
2019-02-08 19:01:55 <mps> ncopa: np for not answering mail, you are on holidays at the end
2019-02-08 19:14:01 <mps> is there problem with patchwork.a.o ?
2019-02-08 19:14:51 <mps> uh, no. looks like it is a little slower than was earlier
2019-02-08 19:20:02 <mps> patches for llvm6 batteries are on patchwork.a.o
2019-02-08 21:35:23 <ddevault> py{2,3,}-six has a broken signature again
2019-02-08 21:35:34 <_ikke_> hmm
2019-02-08 21:37:10 <_ikke_> sigh, riht
2019-02-08 21:37:12 <_ikke_> right
2019-02-08 21:37:19 <_ikke_> it first got reverted, now it got upgraded again
2019-02-08 21:37:28 <_ikke_> but both versions existed already
2019-02-08 21:38:37 <_ikke_> Can you check now?
2019-02-08 21:38:57 <ddevault> yep, working on it...
2019-02-08 21:39:41 <ddevault> ncopa: when you get a minute, can you look at this? needs to land in 3.9 https://patchwork.alpinelinux.org/patch/4457/
2019-02-08 21:39:49 <ddevault> _ikke_: good to go, thanks!
2019-02-08 22:09:45 <SpaceToast> Is there any chance at a bump to testing/lxd? 3.9 has a severe musl-related bug (whose fix I'd recommend backporting if it wasn't in testing) that's fixed in the (now-out) 3.10; I mentioned it to fcolista here a few times and marked it as out of data on pkgs.a.o, but it really should just be a version bump - it's kind of a blocker for my builder to be running :)
2019-02-09 06:23:24 <clandmeter> SpaceToast: done
2019-02-09 06:24:02 <SpaceToast> clandmeter: thanks a lot! Will test tomorrow and get back to you :)
2019-02-09 16:19:01 <jwh> hmph, was hoping 8723bs was enough for the bluetooth too but it's not having ti
2019-02-09 16:22:22 <jwh> actually theres a bunch of bluetooth stuff missing
2019-02-09 17:04:44 <clandmeter> \o/
2019-02-09 17:09:07 <clandmeter> i just added re-signing to abuild (locally)
2019-02-09 17:10:14 <clandmeter> the heavy lifting is ofc done by somebody else....
2019-02-09 17:10:27 <clandmeter> 
ACTION points in fabled direction

2019-02-09 17:11:42 <SpaceToast> clandmeter: as an update, lxd 3.10 works just fine, including the bug fix, ty again :)
2019-02-09 17:12:26 <clandmeter> 10+ years and a few glasses of wine, and alpine keeps amazing me. still so much unknown ground to cover in our distro.
2019-02-09 17:12:46 <clandmeter> SpaceToast: salut
2019-02-09 17:14:00 <clandmeter> +e but thats the wine :)
2019-02-09 17:14:45 <clandmeter> so it should be trivial now to build pkgs locally and resign them elsewhere.
2019-02-09 17:15:25 <mps> clandmeter: prost :) with a glass of good homemade red wine
2019-02-09 17:15:39 <clandmeter> mps, we need that wine :)
2019-02-09 17:15:43 <SpaceToast> a bit early to be drinking here ^^ later, mayhaps!
2019-02-09 17:16:08 <clandmeter> mps: you keep mentioning it, that means sharing! :)
2019-02-09 17:17:21 <mps> clandmeter: some of my friends from your country will visit me in a two week, I can send you a bottle if they are not thirsty to much
2019-02-09 17:17:34 <clandmeter> haha
2019-02-09 17:17:40 <clandmeter> good :)
2019-02-09 17:18:00 <mps> you live in nl, I think
2019-02-09 17:18:03 <clandmeter> i have nothing to return though
2019-02-09 17:18:13 <clandmeter> yes south
2019-02-09 17:19:06 <mps> eh, my friends (business partner) are also on south
2019-02-09 17:19:33 <clandmeter> nice
2019-02-09 17:19:36 <mps> near Eindhoven
2019-02-09 17:19:44 <clandmeter> i am in ehv
2019-02-09 17:20:15 <clandmeter> tech center of the world... blablabla
2019-02-09 17:20:22 <mps> heh, chances are high that you will 'see' mentioned bottle :)
2019-02-09 17:21:09 <clandmeter> i would save it for a special irc day :)
2019-02-09 17:22:04 <mps> will see with them if they are willing to be 'postman'
2019-02-09 21:22:57 <kaniini> is there some reason EDAC is not enabled on our kernels
2019-02-09 22:08:37 <SpaceToast> mps: I and others (currently rnalrd) are seeing sporadic segfaults when trying to build rust packages with cargo - anything I can do to help debug it? (seems to happen at random points during the build, I initially thought it was just the downloading section, but I had one during linking)
2019-02-09 22:13:34 <mps> SpaceToast: on x86_64?
2019-02-09 22:13:39 <SpaceToast> yes
2019-02-09 22:13:59 <SpaceToast> suddenly dropping (in various points of the build) with "Segmentation fault" or "Segmentation faultres"
2019-02-09 22:14:03 <mps> and with llvm5, i presume
2019-02-09 22:14:06 <SpaceToast> yeah
2019-02-09 22:14:17 <SpaceToast> just basic `abuild -r`
2019-02-09 22:14:20 <mps> how much memory you have
2019-02-09 22:14:23 <SpaceToast> 48gb.
2019-02-09 22:14:38 <SpaceToast> (1 currently used)
2019-02-09 22:14:43 <mps> huh, then memory is not problem
2019-02-09 22:14:52 <SpaceToast> I would assume not :)
2019-02-09 22:15:07 <SpaceToast> the same package used to build just fine a month or two ago on a system with 2gb ram
2019-02-09 22:15:07 <mps> I had segfault during build with 6GB RAM
2019-02-09 22:15:19 <SpaceToast> so it's a new breakage
2019-02-09 22:15:34 <SpaceToast> I ran `apk upgrade -a` just in case, but the behavior's the same
2019-02-09 22:15:38 <mps> after adding 4GB issue is solved, i.e. no segfaults during build
2019-02-09 22:15:45 <SpaceToast> and it happens at random points, once even before the "fetching packages" started
2019-02-09 22:16:01 <SpaceToast> so it's "while cargo is running", not even "during build" necessarily
2019-02-09 22:16:14 <SpaceToast> I initially suspected openssl/libressl but it does happen during building too
2019-02-09 22:16:25 <SpaceToast> so I suspect llvm a bit more, but 5 is autoselected for cargo
2019-02-09 22:16:33 <mps> aha, so actually cargo segfaults
2019-02-09 22:16:52 <SpaceToast> yes, it's not rustc (at least as far as I can tell)
2019-02-09 22:17:05 <SpaceToast> it's possible rustc segfaults too, but cargo definitely does
2019-02-09 22:17:21 <SpaceToast> I can give you some APKBUILDs to run a few times (it's inconsistent) if you'd like
2019-02-09 22:17:33 <mps> didn't noticed that in my testing
2019-02-09 22:17:45 <SpaceToast> currently it's reproduced on at least two systems :/
2019-02-09 22:17:56 <SpaceToast> it'd be interesting if yours didn't have any problems
2019-02-09 22:19:28 <mps> right now, I 'messed' rust build with some patches and trying to build with llvm6. will checkout it later and try build on edge
2019-02-09 22:19:41 <SpaceToast> ok, ty
2019-02-09 22:19:49 <SpaceToast> if I can help with any details, feel free to /query
2019-02-09 22:19:55 <SpaceToast> (and please do ping me if/when you figure it out)
2019-02-09 22:20:01 <mps> will see tomorrow, midnight is nearing heer
2019-02-09 22:20:09 <SpaceToast> nw
2019-02-09 22:20:16 <jwh> man
2019-02-09 22:20:20 <jwh> when did the kernel get so big
2019-02-09 22:20:26 <SpaceToast> jwh: progressively
2019-02-09 22:20:30 <SpaceToast> most of it is drivers though
2019-02-09 22:20:34 <SpaceToast> like 75%+
2019-02-09 22:20:57 <jwh> heh
2019-02-09 22:21:08 <jwh> I can't figure out how to make ps show me the time I ran abuild
2019-02-09 22:21:28 <jwh> don't think busybox ps does
2019-02-09 22:21:59 <jwh> jwh      25251  0.0  0.0   1988  1500 pts/1    S+   20:02   0:00 /bin/ash -e /usr/bin/abuild -r
2019-02-09 22:22:02 <jwh> Sat Feb  9 22:21:54 UTC 2019
2019-02-09 22:22:11 <jwh> sadface
2019-02-09 22:22:14 <mps> SpaceToast: just remembered I had segfaults building rust on aarch64 but that is in trying to bootstrap it
2019-02-09 23:14:56 <skyne98_> Hey, guys, I am facing one interesting issue right now: trying to make my own versions of alpine-baselayout and alpine-base using a Docker container conflicts with the installed packages
2019-02-09 23:15:21 <skyne98_> Is there a more correct way doing this?
2019-02-09 23:15:35 <SpaceToast> tag your repository, install the tagged version explicitly
2019-02-09 23:16:33 <skyne98_> So they can somehow co-exist, even though they have file conflicts in the post-install scripts?
2019-02-09 23:17:03 <SpaceToast> they'll be mutually exclusive, of course
2019-02-09 23:17:08 <SpaceToast> but yours will replace the main repo one
2019-02-09 23:20:28 <skyne98_> Ok, thanks for a good advice
2019-02-09 23:25:32 <skyne98_> Is there a way to create a local empty repository for such cases?
2019-02-09 23:25:46 <skyne98_> I wan't able to find anything in the documentation, unfortunatelly
2019-02-09 23:25:53 <skyne98_> unfortunately*
2019-02-09 23:26:36 <SpaceToast> use any directory
2019-02-09 23:27:01 <SpaceToast> when you use `abuild -r` it'll be dropped into REPODEST, which is ~/packages by default
2019-02-09 23:27:14 <SpaceToast> can be overriden in /etc/abuild.conf and ~/.abuild/abuild.conf
2019-02-09 23:28:18 <skyne98_> Oh, looks like it can also be overridden with a -p flag, can't it?
2019-02-09 23:28:56 <SpaceToast> capital -P, but yes
2019-02-09 23:54:12 <skyne98_> Oh, I forgot to mention, my packages are named differently, does that influence anything by any chance?
2019-02-09 23:54:46 <skyne98_> I suspect it won't allow using the tag trick mentioned above
2019-02-10 00:05:52 <SpaceToast> yeah, no ^^
2019-02-10 00:06:28 <SpaceToast> you could use replaces= in the APKBUILD I think
2019-02-10 00:06:30 <SpaceToast> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#replaces
2019-02-10 00:10:01 <skyne98_> I managed to overcome it by just purging alpine-baselayout beforehand
2019-02-10 00:10:10 <skyne98_> I hope I broke nothing in the process :D
2019-02-10 01:29:30 <jwh> bleh
2019-02-10 01:29:31 <jwh> thats it
2019-02-10 01:29:35 <jwh> 
ACTION turns off ipv6 on all alpine boxes

2019-02-10 01:29:40 <jwh> it's just useles
2019-02-10 01:29:42 <jwh> useless*
2019-02-10 08:56:55 <danieli> sigh.
2019-02-10 13:49:49 <skyne98> Hey, guys! Good "morning" :D
2019-02-10 13:53:12 <_ikke_> hi
2019-02-10 13:53:15 <skyne98> A small question again, which package can cause problems with absence of /sbin/init?
2019-02-10 13:53:38 <skyne98> I am still in the process of making my own "alpine-base" and "alpine-baselayout" forks
2019-02-10 13:54:06 <skyne98> At the moment I can successfully build an ISO, but it fails to run /sbin/init
2019-02-10 13:54:28 <_ikke_> afaik it's the kernel / initramfs that tries to run that
2019-02-10 13:57:47 <skyne98> It's definitely trying to run it, but what package provides it? My suspicion falls on OpenRC and busybox-initscripts, but they seem to contain only daemon configurations
2019-02-10 13:57:51 <skyne98> Maybe I am just blind :D
2019-02-10 13:59:12 <skyne98> Ok, seems like the file is there, hmmm. Also the message is "/sbin/init not found in new root."
2019-02-10 14:32:37 <skyne98> Btw, where is init supposed to be in Alpine?
2019-02-10 14:32:49 <skyne98> I see an init file in a root of the initfs
2019-02-10 14:55:08 <SpaceToast> skyne98: see bootparam(7)'s section that starts with init=
2019-02-10 14:55:30 <SpaceToast> in alpine, the initramfs has a shell script in /init, and the system proper has a symlink in /sbin/init that points to busybox
2019-02-10 14:55:48 <SpaceToast> which will run busybox init and thus parse inittab, which will launch openrc
2019-02-10 15:16:00 <skyne98> Thanks for the info :)
2019-02-10 15:26:46 <hacker420[m]> Hey guys, I'm trying to compile SuperTuxKart on Alpine and I'm running into this error
2019-02-10 15:27:08 <hacker420[m]> https://bpaste.net/show/c7786c526029
2019-02-10 15:27:58 <_ikke_> seems to be a dependency on glibc
2019-02-10 15:28:53 <hacker420[m]> Oh
2019-02-10 15:29:00 <hacker420[m]> So I can't fix that?
2019-02-10 15:29:42 <_ikke_> maybe, maybe not
2019-02-10 15:31:08 <_ikke_> You can try to google for that type in combination with musl
2019-02-10 15:36:54 <hacker420[m]> Alright, thanks for help
2019-02-10 15:52:36 <mps> SpaceToast: which version of cargo you have when rebuilding rust?
2019-02-10 15:53:20 <skyne98> Btw, guys, have you seen https://github.com/thepowersgang/mrustc?
2019-02-10 15:53:29 <skyne98> It claims it can build rustc and cargo
2019-02-10 15:54:07 <SpaceToast> mps: latest edge (since it's an edge builder using `abuild -r`)
2019-02-10 15:54:12 <SpaceToast> so 1.31.1-r1
2019-02-10 15:54:57 <mps> and rust is same version, I presume.
2019-02-10 15:55:09 <SpaceToast> yeah
2019-02-10 15:55:24 <SpaceToast> also notable that the segfaults are sporadic - they can happen anywhere during the build as long as cargo is running
2019-02-10 15:55:34 <SpaceToast> (during the download phase, build phase, or link phase)
2019-02-10 15:55:41 <mps> which version of rust you are trying to build
2019-02-10 15:55:45 <SpaceToast> I'm not building rust
2019-02-10 15:55:51 <SpaceToast> as I mentioned, I'm building rust-based packages
2019-02-10 15:56:00 <mps> ah, so.
2019-02-10 15:56:00 <SpaceToast> and getting segfaults in the process at random places
2019-02-10 15:56:17 <mps> do you have APKBUILD for that package
2019-02-10 15:56:26 <SpaceToast> I have several, and offered to send them to you :)
2019-02-10 15:56:39 <SpaceToast> can I PM?
2019-02-10 15:56:39 <mps> sorry, I missed that.
2019-02-10 15:56:46 <mps> ofc, you can
2019-02-10 16:13:22 <skyne98> Hm, I noticed another confusing thing. The iso script seems to install the initramfs packages with a --no-script flag while the alpine-baselayout and alpine-base both have scripts that set the system up (such as create an inittab)
2019-02-10 16:13:28 <skyne98> Am I missing something here?
2019-02-10 21:34:59 <foldedcascode> i'm a bit confused about the rust *-alpine-linux-musl* targets
2019-02-10 21:35:34 <foldedcascode> (from the apkbuild patches)
2019-02-10 21:36:17 <mps> would you mind to tel what is confusing
2019-02-10 21:36:31 <foldedcascode> they seem to pass their full target triple to llvm, but building llvm (in context of building rustc) doesn't seem to know what to do with them
2019-02-10 21:36:46 <foldedcascode> and the llvm apkbuild doesn't seem to have any relevant patches
2019-02-10 21:38:23 <mps> hmm, I'm not expert in llvm, but looks like it know what to do at the end
2019-02-10 21:41:59 <foldedcascode> yeah, i'm not claiming llvm can't build code for those triples or anything. just having problems building llvm itself in one of the steps of building rustc.
2019-02-10 21:42:05 <foldedcascode> ah well
2019-02-10 21:44:12 <mps> llvm is not built during rust building, on Alpine I mean
2019-02-10 21:46:12 <mps> did you looked prepare function in APKBUILD
2019-02-10 21:48:00 <foldedcascode> i think it's getting built because i'm trying to cross-compile?
2019-02-10 21:48:01 <foldedcascode> hm
2019-02-10 21:48:30 <mps> no, look 'rm -Rf src/llvm/' line
2019-02-10 21:49:09 <foldedcascode> oops, thanks mps
2019-02-10 21:50:07 <mps> foldedcascode: are you just curious about rust on Alpine, or you work with it 'something'
2019-02-10 21:50:09 <foldedcascode> although i think if i do that i may need to grab the target arch's llvm so it's available for linking, right?
2019-02-10 21:50:50 <mps> Alpine does native build
2019-02-10 21:50:52 <foldedcascode> figured i would try to get rust running on armhf alpine
2019-02-10 21:51:26 <mps> aha, I'm working on run it on aarch64 and armv7
2019-02-10 21:51:46 <foldedcascode> oh! how is that going for you?
2019-02-10 21:52:15 <mps> well, I have apk's but didn't tested it well
2019-02-10 21:56:29 <foldedcascode> cool! curious to see them if you've posted them somewhere
2019-02-10 21:56:47 <foldedcascode> gtg, ttyl
2019-02-10 21:58:15 <mps> last week I worked on llvm 6 for alpine so didn't had much time to test it.
2019-02-10 21:59:09 <mps> could put it somewhere, but have no idea where
2019-02-11 07:07:01 <fcolista> SpaceToast, hi
2019-02-11 07:07:49 <SpaceToast> mm, 'evening?
2019-02-11 07:12:39 <SpaceToast> what's up?
2019-02-11 07:13:05 <SpaceToast> (it's kind of 2 am here, and I've work in ~5-6 hours, so if it's nothing urgent I'll go back to sleep)
2019-02-11 07:51:17 <danieli> morning fcolista
2019-02-11 07:51:33 <fcolista> hey danieli ! hi
2019-02-11 07:51:35 <fcolista> Hi SpaceToast
2019-02-11 07:51:36 <fcolista> sorry
2019-02-11 07:51:56 <fcolista> just to let you know that I pushed lxd 3.10
2019-02-11 07:52:11 <fcolista> sorry for the delay, i was away for 2 days
2019-02-11 08:09:52 <clandmeter> fcolista: you pushed 3.10?
2019-02-11 08:21:29 <fcolista> yes
2019-02-11 08:52:11 <clandmeter> fcolista: where?
2019-02-11 09:26:09 <fcolista> oh
2019-02-11 09:26:12 <fcolista> in my dreams
2019-02-11 09:26:19 <fcolista> It was in my local repo
2019-02-11 09:26:22 <danieli> lol
2019-02-11 09:26:25 <fcolista> :D
2019-02-11 09:26:28 <fcolista> 6be04380d37d935a30fc6c9e54efbe620a7a0f8a
2019-02-11 09:26:34 <fcolista> just saw you did it in git log
2019-02-11 09:26:49 <fcolista> while i remember I did it, and not seen that you were already did it
2019-02-11 09:27:19 <fcolista> heh
2019-02-11 09:27:20 <fcolista> ok
2019-02-11 09:27:22 <fcolista> gotcha
2019-02-11 09:27:38 <fcolista> i had to git stash due to py3-qt5 I was working with...
2019-02-11 09:27:53 <fcolista> that's why i rememeber to have done it..
2019-02-11 09:30:07 <clandmeter> ;-)
2019-02-11 09:39:57 <danieli> i occasionally stash when i'm out working, and forget about it
2019-02-11 09:40:02 <danieli> until someone pokes me
2019-02-11 09:47:43 <fcolista> hehe
2019-02-11 09:48:49 <danieli> fyi: I requested RPi add Alpine to their downlaods page
2019-02-11 09:48:55 <danieli> s/lao/loa
2019-02-11 09:48:55 <alpine-meetbot> danieli meant to say: fyi: I requested RPi add Alpine to their downloads page
2019-02-11 10:05:25 <clandmeter> danieli: which page?
2019-02-11 10:05:42 <danieli> raspberrypi.org/downloads
2019-02-11 10:05:50 <clandmeter> ah ok
2019-02-11 10:06:21 <clandmeter> i need to fix the images
2019-02-11 10:45:36 <rnalrd> hi
2019-02-11 10:46:08 <rnalrd> quick question: RPi3B+ is supported?
2019-02-11 10:47:11 <_ikke_> I believe it should, not certain though
2019-02-11 10:47:35 <_ikke_> "Designed for RPI 1, 2 and 3."
2019-02-11 10:47:47 <rnalrd> looks like you have my same certainty :)
2019-02-11 10:47:55 <_ikke_> haha :P
2019-02-11 10:48:24 <rnalrd> trying to boot one, now testing raspbian because no luck so far
2019-02-11 10:59:36 <clandmeter> rnalrd: should be supported
2019-02-11 11:01:36 <clandmeter> rnalrd: which issue do you have?
2019-02-11 11:22:42 <rnalrd> ok raspian boots
2019-02-11 11:24:17 <rnalrd> clandmeter, no video signal when attempting to boot with alpine-uboot-3.9.0-armv7.tar.gz
2019-02-11 11:24:38 <clandmeter> uhm
2019-02-11 11:24:45 <clandmeter> thats not made for raspbian
2019-02-11 11:24:53 <rnalrd> doh
2019-02-11 11:24:55 <clandmeter> the releases are incomplete
2019-02-11 11:25:01 <clandmeter> ncopa needs to fix it.
2019-02-11 11:25:08 <clandmeter> i have a working release if yhou like
2019-02-11 11:25:40 <clandmeter> https://dev.alpinelinux.org/~clandmeter/other/alpine-rpi-190203-aarch64.tar.gz
2019-02-11 11:26:04 <rnalrd> 3B+ is 64-bit?
2019-02-11 11:27:00 <clandmeter> Processor: Broadcom BCM2837B0, Cortex-A-53, 64-bit SoC @ 1.4 GHz
2019-02-11 11:28:00 <rnalrd> nice, thanks!!
2019-02-11 11:28:04 <mps> aren't all RPi3 64bit?
2019-02-11 11:28:20 <clandmeter> and limited some older ones too
2019-02-11 11:28:50 <clandmeter> but that they didnt announce.
2019-02-11 12:30:02 <danieli> that cortex a53 can do 32-bit afaik
2019-02-11 13:30:23 <clandmeter> danieli: 64bit is not officially supported by rpi, so yes its 32bit capable.
2019-02-11 13:35:26 <mps> a53 could execute arm32 binaries, even under aarch64 as base system
2019-02-11 13:41:39 <clandmeter> why would the base system matter in this regard?
2019-02-11 13:45:14 <mps> it doesn't, just wanted to note possibility to run 32bit binaries under 64bit system
2019-02-11 14:15:27 <danieli> i believe the first releases of raspbian for the 3 were 32
2019-02-11 14:15:33 <danieli> but later on, i'm pretty sure they rolled out 64
2019-02-11 14:30:24 <clandmeter> http://www.raspbian.org/RaspbianFAQ#What_compilation_options_should_be_set_Raspbian_code.3F
2019-02-11 16:24:43 <_ikke_> ^ that's a feature :P
2019-02-11 16:25:09 <clandmeter> :)
2019-02-11 16:25:12 <clandmeter> i need to fix  that
2019-02-11 16:25:23 <clandmeter> added to my ever growing list
2019-02-11 16:25:26 <_ikke_> heh
2019-02-11 16:49:38 <danieli> need some help?
2019-02-11 17:01:10 <mps> I messed one of my edge containers, couldn't build curl properly. it builds without errors but there is no /usr/lib/libcurl.so.4.5.0 which must be there
2019-02-11 17:01:42 <mps> 'abuild deps' works fine
2019-02-11 17:08:17 <mps> anyone have idea how to fix it
2019-02-11 17:24:08 <mps> SpaceToast: built your exa APKBUILD 'three times in row' without any error on aarch64
2019-02-11 17:28:38 <mps> fd couldn't be built because this error: error[E0425]: cannot find value `MAP_32BIT` in module `libc`
2019-02-11 17:40:03 <mps> ripgrep built fine
2019-02-11 17:50:21 <SpaceToast> mps: are the changes/patches in edge on dl-cdn.a.o now?
2019-02-11 17:50:36 <SpaceToast> ("can I run an upgrade and test myself", rather)
2019-02-11 17:56:21 <mps> SpaceToast: not yet, have a problem with building curl and libcurl
2019-02-11 17:56:36 <SpaceToast> which look to be the issue to begin with ^^;;
2019-02-11 17:56:53 <SpaceToast> let me take a look at the MAP_32BIT real quick, but if it's not a segmentation fault that's fine
2019-02-11 17:57:06 <SpaceToast> the issue is how sporadic the failures are, so it's possible it's not solved (but I would hope it is!)
2019-02-11 17:57:12 <mps> only on x86_64, on aarch64 works with curl as it is
2019-02-11 17:57:27 <SpaceToast> that's... interesting
2019-02-11 17:57:37 <mps> also to me
2019-02-11 17:58:37 <mps> I patched curl, but have to fix my x86_64 edge build container
2019-02-11 17:59:35 <mps> but I'm 99% percent sure that the problem is curl and not cargo
2019-02-11 17:59:51 <SpaceToast> it does look like it, now
2019-02-11 18:00:12 <SpaceToast> that also means it's likely that other packages could be affected (just without anyone hitting the bad code so far)
2019-02-11 18:00:19 <mps> 1% could be cargo+libcurl combo
2019-02-11 18:00:36 <mps> seems you are right
2019-02-11 18:00:39 <SpaceToast> it might be that cargo uses libcurl's http/2 functions
2019-02-11 18:00:44 <SpaceToast> which might be the source of the issue
2019-02-11 18:00:51 <mps> that is!
2019-02-11 18:01:24 <mps> I could post you patch for curl in a few minutes
2019-02-11 18:01:37 <SpaceToast> I'm currently at work (1pm here)
2019-02-11 18:01:49 <SpaceToast> if you could, can you git-send-email to toast@toastin.space, and I'll try compiling a copy myself?
2019-02-11 18:02:16 <mps> ah, ok. will post patch to patchwork.a.o then
2019-02-11 18:02:49 <mps> ok, could whatever you like
2019-02-11 18:02:52 <SpaceToast> ^^ ty
2019-02-11 18:03:05 <SpaceToast> I'll test with the patch on the build server
2019-02-11 18:03:11 <SpaceToast> probably this evening or tomorrow
2019-02-11 18:04:57 <mps> ok, will do something when preparing it to be clean
2019-02-11 18:47:56 <vkrishn> setup-alpine also asks for dropbear as an alternate install, but may not be present in some isos, hope its ok ?
2019-02-11 18:52:00 <SpaceToast> vkrishn: `apk add --quiet $pkgs` happens in setup-sshd::41
2019-02-11 18:52:13 <SpaceToast> setup-sshd happens after setting up networking and repositories
2019-02-11 18:52:19 <SpaceToast> so it just needs to be in main
2019-02-11 18:52:29 <SpaceToast> which it is :)
2019-02-11 18:55:12 <vkrishn> so if someone downloads alpine-virt-3.9.0-x86_64.iso, and tries to choose dropbear during setup, it would not work
2019-02-11 18:57:50 <SpaceToast> it would
2019-02-11 18:57:54 <SpaceToast> assuming they set up networking and apkrepos
2019-02-11 18:58:00 <SpaceToast> which you do want to set up if you're running setup-alpine anyway
2019-02-11 18:58:23 <vkrishn> ok
2019-02-11 19:05:23 <mps> SpaceToast: https://patchwork.alpinelinux.org/patch/4497/
2019-02-11 19:06:26 <mps> built exa four times in a row without problem with this patch applied to curl
2019-02-11 19:06:51 <SpaceToast> on x86_64?
2019-02-11 19:06:56 <mps> yes
2019-02-11 19:07:05 <_ikke_> commit message could use some improvement ;-)
2019-02-11 19:07:18 <SpaceToast> nice!
2019-02-11 19:07:42 <mps> _ikke_: wording commits is my big issue
2019-02-11 19:08:03 <_ikke_> Try to describe why you change things, not literally what you changed
2019-02-11 19:08:07 <SpaceToast> mps: I'll try it when I get home
2019-02-11 19:08:14 <_ikke_> for example, "bump pkgrel" is redundant
2019-02-11 19:08:15 <SpaceToast> any thoughts as to submitting it to upstream?
2019-02-11 19:08:34 <_ikke_> You want to explain why the fix needs to happen in the first place
2019-02-11 19:08:34 <mps> it is already upstream
2019-02-11 19:08:43 <mps> I took it from there
2019-02-11 19:09:02 <SpaceToast> oh, ok, so we're just waiting for a release, then?
2019-02-11 19:09:20 <mps> yes, I wrote in annotations that
2019-02-11 19:09:28 <SpaceToast> aha
2019-02-11 19:10:53 <mps> _ikke_: I explained a little bit more in annotation in mail
2019-02-11 19:11:18 <_ikke_> I see, though that won't be part of the actualy commit mesasge
2019-02-11 19:11:24 <_ikke_> actual*
2019-02-11 19:13:23 <mps> I know, the problem is to find right words i.e. translate to English words from my head and I'm like to look perfect and because that waste too much time on messages.
2019-02-11 19:13:42 <SpaceToast> ^^
2019-02-11 19:13:51 <SpaceToast> if you want, I can give some polyglot hints
2019-02-11 19:14:16 <mps> SpaceToast: do whatever you think is right
2019-02-11 19:14:34 <SpaceToast> I find that if you dynamically translate what you want to say in your head, it'll never sound natural
2019-02-11 19:14:40 <SpaceToast> and it's a lot of work too :)
2019-02-11 19:14:55 <mps> right
2019-02-11 19:15:08 <SpaceToast> basically every language I've gotten to a comfortable point with, the "holy grail" is being able to think in it
2019-02-11 19:15:26 <SpaceToast> once you're able to think in a language (even if the thoughts are very simple), the rate of learning accelerates drastically
2019-02-11 19:15:35 <SpaceToast> and you avoid issues like mismatched syntax and so on
2019-02-11 19:16:12 <mps> probably you are right, but I don't have time to waste of fine points of the different language
2019-02-11 19:16:26 <SpaceToast> ¯\_(ツ)_/¯
2019-02-11 19:18:18 <mps> I'm working on problem solving in different fields of human life so don't have enough resources/time to learn something what is not of primary importance for problems solving, sorry
2019-02-11 19:19:23 <SpaceToast> I don't really care either way, just offering advice on how to improve the thing you were lamenting :)
2019-02-11 19:19:37 <mps> to me is important that we understand each other and are willing to understand each other. then the problem solving become easier
2019-02-11 19:20:08 <mps> I didn't lamented, that was someone else who initiated that
2019-02-11 19:21:01 <mps> SpaceToast: please inform me of your results when you test issue
2019-02-11 19:21:48 <SpaceToast> sure :)
2019-02-11 19:23:31 <_ikke_> mps: how about something like: "main/curl: fix segfault when running cargo", and then add context in the body of the commit message
2019-02-11 19:28:46 <_ikke_> https://seclists.org/oss-sec/2019/q1/119
2019-02-11 19:28:55 <_ikke_> runc container break-out vulnerability
2019-02-11 19:30:53 <mps> _ikke_: perfect, I agree
2019-02-11 19:32:17 <vkrishn> forgot to mention, I am looking for free webhosting+git+ssh, space 200mb should be ok, for moving my site insteps.net to it, any suggestions are welcomed
2019-02-11 19:32:46 <_ikke_> please don't spam this around
2019-02-11 19:33:04 <mps> _ikke_: should I rewrite it and send new patch?
2019-02-11 19:33:53 <vkrishn> sorry, wanted to write on al-linux channel, but went otherway
2019-02-11 20:20:53 <_ikke_> Anyone knows why /bin/ash -c 'printf "\376\777" | xxd' returns something different than /bin/bash -c 'printf "\376\777" | xxd'
2019-02-11 20:30:04 <_ikke_> Looks like \777 is a bug
2019-02-11 20:38:41 <_ikke_> I see what is happening
2019-02-11 20:52:14 <SpaceToast> Which one is bugged?
2019-02-11 20:54:07 <_ikke_> \777
2019-02-11 20:54:23 <_ikke_> It tries to generate a bom
2019-02-11 20:54:31 <_ikke_> fffe
2019-02-11 20:54:44 <_ikke_> 777 is 511, which is >255
2019-02-11 20:55:06 <_ikke_> It appears most shells just truncate the value to 255
2019-02-11 20:55:23 <_ikke_> but ash interprets it as \77 + '7'
2019-02-11 20:56:18 <SpaceToast> ah
2019-02-11 21:33:02 <SpaceToast> AinNero: is there any chance of changing nlplug-findfs to make recuse_opts->maxdepth configurable (+ handling that in initrd)?
2019-02-11 21:33:11 <SpaceToast> looks like that was the issue I was running into :)
2019-02-11 21:33:40 <SpaceToast> (I'd need a value of 3, but making it user-configurable should make alpine much easier to multihost)
2019-02-11 21:34:09 <SpaceToast> perhaps even share that value for initramfs-init.in::244
2019-02-11 21:50:03 <_ikke_> Once some patches are applied I've got one sets of tests of the git test suite passing on alpine linux that fail now
2019-02-11 21:50:16 <_ikke_> Trying to get it passing completely
2019-02-11 23:01:42 <LBlaboon> hey all! cross-posting this from #alpine since i'm not sure which channel is more appropriate...
2019-02-11 23:01:46 <LBlaboon> i'm an engineer at linode (a vps provider based in philly), and we're working on adding alpine as one of our supported out-of-the-box distros
2019-02-11 23:01:54 <LBlaboon> i was wondering if anyone on the alpine team is interested in partnering up on the effort
2019-02-11 23:05:47 <danieli> LBlaboon: come to #alpine-infra, and explain exactly what you need help with
2019-02-11 23:06:45 <danieli> we prefer to keep anything and everything infrastructure there :) sorry to move you around so much
2019-02-11 23:07:35 <LBlaboon> it's all good! sorry for being noisy >.<
2019-02-11 23:08:05 <danieli> it's fine, don't worry
2019-02-11 23:15:32 <skyne98> Hey guys! Small question again: is there a way to reference a local git repository for building a package?
2019-02-11 23:15:44 <skyne98> Or maybe just include a directory?
2019-02-11 23:16:06 <skyne98> The only way I am seeing right now is making a tarball each time and including it instead...
2019-02-12 05:15:20 <SpaceToast> mps: as an update - with the libcurl patch installed, I managed to build all of my packages 1st try, so I can move with updating them and adding new ones now; thanks!
2019-02-12 05:15:31 <SpaceToast> thankfully, it's in upstream already, so worst case we can just wait for the next release in-repos
2019-02-12 07:30:57 <_ikke_> SpaceToast: yeah, it might be easier to just wait for an upstream release
2019-02-12 07:31:04 <_ikke_> they seem to have short release cycles
2019-02-12 09:44:18 <AinNero> SpaceToast: please open a ticket
2019-02-12 11:12:53 <BitL0G1c> anyone starting seeing TLS library problem on postfix / dovecot ? - ACCEPT_SR_CLNT_HELLO_C:wrong version number:ssl_srvr.c:857 (both client & server support TLS 1.2)
2019-02-12 15:14:15 <besedad_> hi everyone.
2019-02-12 15:15:59 <besedad_> i'm trying to build custom image for my rpi, however mkimage.sh complains that /edge/main/aarch64/APKINDEX.tar.gz has unknown signature.
2019-02-12 15:16:33 <besedad_> sh mkimage.sh --arch aarch64 --repository http://dl-cdn.alpinelinux.org/alp
2019-02-12 15:16:35 <besedad_> ine/edge/main/ --profile rpi
2019-02-12 15:17:29 <besedad_> that's the command i run. the script stops at: ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main/: UNTRUSTED signature
2019-02-12 15:17:58 <tmhoang> <besedad_> : probably try different mirror would help
2019-02-12 15:21:38 <besedad_> tmhoang: i did try to use other mirrors just now. same problem.
2019-02-12 15:22:55 <besedad_> don't know if that is relevant but i'm building inside of a docker container. it's alpine:edge.
2019-02-12 15:23:49 <tmhoang> <besedad_>: are you building this on a same arch (aarch64) host ? if not probably get the aarch64 key ? https://git.alpinelinux.org/aports/plain/main/alpine-keys/alpine-devel@lists.alpinelinux.org-58199dcc.rsa.pub
2019-02-12 15:27:10 <besedad_> tmhoang: yeah that did the trick, thanks. still some other error (grzip: invalid magic).
2019-02-12 15:27:38 <besedad_> tmhoang: i'm building on x86_64.
2019-02-12 15:29:00 <tmhoang> besedad_: some people have been doing/running/building multi-arch thing with docker (i.e. smoothly running aarch64 containers on x86) but I have never tried. Probably something like FROM alpine:aarch64 or sort of.
2019-02-12 15:29:43 <tmhoang> some other use qemu emulation (through tcg) to run alpine aarch64 host, then build the image in there.
2019-02-12 15:30:44 <besedad_> tmhoang: i think i'm bit confused. do i need to use same platform for which i am building iso/tarball for?
2019-02-12 15:31:38 <besedad_> tmhoang: because looking at the error (invalid magic), it seems mkimage expects gzip built fo aarch64.
2019-02-12 15:31:47 <tmhoang> I think you have
2019-02-12 15:31:52 <clandmeter> i think you have
2019-02-12 15:31:54 <clandmeter> echo
2019-02-12 15:32:07 <tmhoang> clandmeter
2019-02-12 15:32:14 <clandmeter> thats why you also got the error with keys
2019-02-12 15:32:35 <besedad_> tmhoang: alright, that explains it. thanks a lot.
2019-02-12 15:33:13 <tmhoang> besedad_ : btw next time if you have aarch64 in mind, summon the aarch64/arm* king, clandmeter.
2019-02-12 15:33:42 <clandmeter> besedad_: is the image you are creating specific?
2019-02-12 15:34:07 <clandmeter> tmhoang: that too much honor :)
2019-02-12 15:34:27 <besedad_> clandmeter: i want to preinstall specific packages so that the binaries are ready to use after boot.
2019-02-12 15:34:47 <tmhoang> besedad_ : try the multi-arch docker path. It should work.
2019-02-12 15:35:13 <tmhoang> (it's user-space emulation, I guess)
2019-02-12 15:36:25 <clandmeter> besedad_: adding them to the image does not automatically install them. not sure you are aware.
2019-02-12 15:37:39 <besedad_> tmhoang: can you point me to the specifics? do you mean https://hub.docker.com/r/multiarch/alpine?
2019-02-12 15:38:54 <besedad_> clandmeter: no, i didn't know. so how do i make a package available in the image? i looked at gnepkovl-*.sh scripts, thinking that if i add desired packages in the list, it will all work out.
2019-02-12 15:39:12 <clandmeter> think again :)
2019-02-12 15:39:49 <clandmeter> alpine will boot tmpfs mode
2019-02-12 15:40:38 <clandmeter> what is installed is defined by initramfs and optionally your ovl file which holds your world file.
2019-02-12 15:41:15 <clandmeter> when you add more packages it only means the local repo on media will have them.
2019-02-12 15:41:32 <clandmeter> so you dont need internet to query a remote repo
2019-02-12 15:42:46 <besedad_> hmm, i see. thank you for clarification. i think i could work with that. i coudl add a "first boot" script that installs the packages.
2019-02-12 15:43:33 <clandmeter> i think what you are trying to do is already possible with a custom ovl file
2019-02-12 15:43:36 <besedad_> the reason i wanted the packages to be already installed is that there's a chance of no internet connection. so having the packages locally would work.
2019-02-12 15:44:57 <clandmeter> right well then you need to create your own image.
2019-02-12 15:46:21 <besedad_> clandmeter: so ovl files work only for remote packages?
2019-02-12 15:46:36 <clandmeter> no
2019-02-12 15:46:53 <clandmeter> but if the packages are not in your local repo, you will need another repo.
2019-02-12 15:48:28 <clandmeter> you can also setup apk cache
2019-02-12 15:48:46 <clandmeter> it will cache the missing packages on your storage
2019-02-12 15:48:53 <clandmeter> same place as your ovl ffile
2019-02-12 15:49:27 <tmhoang> besedad_ : probably this : https://hub.docker.com/r/multiarch/alpine .  But personally I would fire a qemu vm.
2019-02-12 15:54:12 <besedad_> clandmeter: okay, i'm probably wrong but. would it work if i would build my custom image with all the required packages included in it, modify the /etc/apk/world so that it lists the packages in order to automatically install them?
2019-02-12 15:54:32 <clandmeter> yes that would work
2019-02-12 15:54:39 <clandmeter> but you can already do that
2019-02-12 15:54:57 <clandmeter> you dont need a custom image if you use apk cache
2019-02-12 15:54:59 <besedad_> clandmeter: sure i do, but that would not cover the scenario where there's no internet connection.
2019-02-12 15:55:20 <clandmeter> it does, but we should probably discus this in #alpine-linux
2019-02-12 15:55:42 <besedad_> clandmeter: see you there.
2019-02-12 15:56:22 <besedad_> clandmeter: or maybe not, cause i have to be identified with the service.
2019-02-12 15:59:22 <clandmeter> besedad_: https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Local_Cache
2019-02-12 15:59:36 <clandmeter> but for more support i would prefer you use #alpine-linux
2019-02-12 15:59:50 <clandmeter> thats what its for.
2019-02-12 16:00:45 <besedad_> clandmeter: thank you. i will try to read a bit before asking more questions. thanks guys, you were really helpful.
2019-02-12 17:43:08 <SpaceToast> AinNero: ty, enjoy ^
2019-02-12 19:05:57 <jwh> man, freenode is just awful
2019-02-12 19:07:32 <_ikke__> jwh: ah, you as well
2019-02-12 19:10:25 <jwh> sup
2019-02-12 19:11:14 <jwh> gonna have to pick out a server that doesn't suck rather than using the round robin
2019-02-12 19:12:49 <jwh> you'd think since they're PIA now they could get a decent set heh
2019-02-12 19:15:53 <jwh> doesn't help that irssi will try and stick to the same server either :(
2019-02-12 19:16:46 <_ikke__> weechat seems to have picked a different server
2019-02-12 19:17:41 <jwh> heh
2019-02-12 19:18:21 <jwh> it's mostly annoying as I still haven't enabled sasl auth, so most of my channels don't join
2019-02-12 19:18:21 <_ikke__> I did do a manual reconnect, so that might have contributed to that
2019-02-12 19:18:26 <jwh> yeah
2019-02-12 19:18:31 <_ikke__> ah, yeah, i do have sasl
2019-02-12 19:18:35 <_ikke__> so easy
2019-02-12 19:18:43 <jwh> yeah, just laziness heh
2019-02-12 19:20:23 <_ikke__> It's more work to not do it :P
2019-02-12 19:20:31 <jwh> yeah, done it now :P
2019-02-12 23:35:18 <jwh> does network/interfaces *really* still not support cidr notation?
2019-02-12 23:35:59 <jwh> it wasn't excusable a decade ago, should be considered a crime now :D
2019-02-12 23:37:34 <jwh> bleh, looks like debians version finally got it, but not busybox?
2019-02-12 23:45:19 <SpaceToast> busybox ifupdown hasn't really been maintained since 2006 or so
2019-02-12 23:45:43 <SpaceToast> I have a patch sitting that I'll be sending at some point that fixes a random memory leak that's been there since then
2019-02-12 23:46:24 <jwh> heh
2019-02-12 23:47:16 <jwh> wonder how difficult it would be to add proper support
2019-02-12 23:48:02 <jwh> all it needs to do is figure out if the 'address' key ends in /[0-9]{1,3}
2019-02-12 23:48:10 <jwh> I think, I was never any good at regex
2019-02-12 23:48:45 <jwh> but then, if it uses ifconfig it's probably not going to work anyway as I don't think busybox ifconfig works properly like the old net tools version either
2019-02-12 23:49:07 <jwh> something else that really shouldn't exist heh
2019-02-12 23:54:32 <SpaceToast> it uses ip(1) if it can find it
2019-02-12 23:55:36 <jwh> ah, well in that case it should reall support it then, since the busybox version of ip can figure it out properly
2019-02-12 23:55:39 <jwh> really*
2019-02-13 08:06:12 <fcolista> clandmeter, jirutka, ncopa : we have an issue with sip/qt5.12/python.
2019-02-13 08:06:26 <fcolista> sip is not shipped anymore with py3-qt5
2019-02-13 08:06:29 <fcolista> this breaks gns3
2019-02-13 08:07:01 <fcolista> py-sip now ships sip.py for qt5
2019-02-13 08:07:22 <fcolista> But requires different makefiles.
2019-02-13 08:07:26 <fcolista> This is what I've done:
2019-02-13 08:07:27 <fcolista> https://dpaste.de/bYnX/raw
2019-02-13 08:08:07 <clandmeter> morning
2019-02-13 08:08:24 <clandmeter> i remember sip mentioned here 2 weeks before
2019-02-13 08:09:14 <fcolista> since then we have upgraded qt from 5.11 to 5.12
2019-02-13 08:09:22 <fcolista> this behavior has been introduced with 5.11
2019-02-13 08:09:54 <clandmeter> ah yes dalias mentioned it
2019-02-13 08:10:34 <clandmeter> 2019-01-28 20:38:03 <dalias> any idea why my py3-sip package would lack the /usr/bin/sip program?
2019-02-13 08:10:34 <clandmeter> 2019-01-28 20:38:19 <dalias> pkgs.alpinelinux.org says it's there but my installed package doesn't have it
2019-02-13 08:10:34 <clandmeter> 2019-01-28 20:43:56 <dalias> somehow there's a broken py3-sip-4.19.13-r0 in addition to the one i should be getting py3-sip-4.19.5-r0
2019-02-13 08:10:34 <clandmeter> 2019-01-28 20:45:43 <ncopa> seems like we have 2 different py3-sip
2019-02-13 08:10:34 <clandmeter> 2019-01-28 20:46:11 <ncopa> one provided by community/py-sip and one provided by community/py3-sip
2019-02-13 08:10:35 <clandmeter> 2019-01-28 20:48:03 <ncopa> dalias: the /usr/bin/sip program comes with py-sip, which has 2 subpackages, py2-sip and py3-sip
2019-02-13 08:10:48 <clandmeter> hmm paste would be better :)
2019-02-13 08:11:00 <fcolista> :)
2019-02-13 08:11:03 <clandmeter> is this related?
2019-02-13 08:11:10 <fcolista> partially
2019-02-13 08:11:29 <fcolista> now this new APKBUILD ships /usr/bin/sip correctly
2019-02-13 08:11:41 <fcolista> and sip qt5
2019-02-13 08:12:38 <fcolista> but I would like to know if this is a correct approach
2019-02-13 08:16:36 <clandmeter> did you copy and paste this from somehwere else?
2019-02-13 08:18:12 <fcolista> no
2019-02-13 08:18:19 <clandmeter> ah ok from the original make
2019-02-13 08:18:25 <fcolista> I've used as base python-sip in arch
2019-02-13 08:18:52 <fcolista> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/sip
2019-02-13 08:21:28 <clandmeter> i think in general its ok
2019-02-13 08:22:10 <fcolista> clandmeter, this is what the APKBUILD produces:
2019-02-13 08:22:10 <fcolista> https://dpaste.de/CRT4/raw
2019-02-13 08:22:15 <clandmeter> i think you dont need to copy 4x
2019-02-13 08:22:17 <fcolista> which LGTM
2019-02-13 08:22:39 <clandmeter> if you need the python2 name you can simple symlink
2019-02-13 08:22:45 <clandmeter> simply
2019-02-13 08:23:03 <fcolista> ah yes
2019-02-13 08:23:07 <clandmeter> and  CXXFLAGS="$CXXFLAGS"
2019-02-13 08:23:08 <fcolista> makes sense
2019-02-13 08:23:10 <clandmeter> what is that?
2019-02-13 08:23:31 <fcolista> umh...that was there since ages. I've unotouched it
2019-02-13 08:23:48 <clandmeter> and -fPIC is that set by default?
2019-02-13 08:23:59 <fcolista> same
2019-02-13 08:24:14 <clandmeter> yes but by you so i wonder why
2019-02-13 08:24:16 <clandmeter> :)
2019-02-13 08:24:43 <fcolista> old pkg needed that
2019-02-13 08:24:50 <fcolista> maybe now is not needed anymore
2019-02-13 08:27:58 <clandmeter> fcolista: what is the reson they provide two makefiles?
2019-02-13 08:28:06 <clandmeter> s/reson/reason/
2019-02-13 08:28:06 <alpine-meetbot> clandmeter meant to say: fcolista: what is the reason they provide two makefiles?
2019-02-13 08:28:40 <fcolista> good question.
2019-02-13 08:28:42 <fcolista> This:
2019-02-13 08:28:43 <fcolista> $python configure.py --sip-module PyQt5.sip --no-too
2019-02-13 08:28:50 <fcolista> does not build /usr/bin/sip
2019-02-13 08:28:56 <fcolista> while $python configure.py
2019-02-13 08:29:08 <fcolista> does not build PyQt5.sip
2019-02-13 08:29:56 <fcolista> maybe:
2019-02-13 08:29:57 <fcolista>  $python configure.py --sip-module PyQt5.sip
2019-02-13 08:30:04 <fcolista> builds both
2019-02-13 08:30:28 <fcolista> right
2019-02-13 08:30:29 <fcolista> yes
2019-02-13 08:31:11 <clandmeter> so you probably dont need both
2019-02-13 08:31:14 <fcolista> https://dpaste.de/U0A0/raw
2019-02-13 08:31:17 <fcolista> much better now
2019-02-13 08:31:25 <fcolista> exactly
2019-02-13 08:31:28 <clandmeter> my advise would be  to check fedora
2019-02-13 08:31:33 <clandmeter> https://src.fedoraproject.org/cgit/rpms/sip.git/tree/sip.spec
2019-02-13 16:50:35 <jwh> umm
2019-02-13 16:50:43 <jwh> libvirt-lxc is busted, sigh
2019-02-13 16:50:53 <jwh> do any platforms actually work properly anymore :/
2019-02-13 16:51:05 <jwh> systemd broken it on at least arch too
2019-02-13 16:55:14 <fcolista> jwh, can you please provide a way to test it quickly?
2019-02-13 16:55:18 <fcolista> To reproduce the issue
2019-02-13 16:55:41 <jwh> install it, try and start an lxc container - it's just missing cgroups by the looks of it, so probably not so bad
2019-02-13 16:56:15 <jwh> https://gitlab.com/zorinsllc/vmthings/blob/master/lxc.sh - quick script
2019-02-13 16:56:31 <jwh> needs lxc-download installed also
2019-02-13 17:00:15 <jwh> hm
2019-02-13 17:00:39 <SpaceToast> "do any platforms actually work properly anymore :/" - lxd works pretty well now :D
2019-02-13 17:00:46 <jwh> yeah
2019-02-13 17:00:48 <SpaceToast> not with libvirt, but on its own
2019-02-13 17:00:49 <jwh> that was my net stop
2019-02-13 17:00:52 <jwh> next*
2019-02-13 17:01:03 <jwh> shame though, libvirt was always quite useful
2019-02-13 17:01:07 <SpaceToast> if you need any help with it, feel free to ask :) (but idk anything about the libvirt integration)
2019-02-13 17:01:13 <SpaceToast> to me, libvirt seems very painful
2019-02-13 17:01:44 <jwh> well, I liked the semi sensible interface to multiple vm types (lxc, kvm etc)
2019-02-13 17:01:48 <SpaceToast> the point of lxd was to make lxc easier/faster to configure and interact with; libvirt feels like going backwards on that goal to me
2019-02-13 17:01:57 <SpaceToast> ah, yeah, if you need several backends it makes sense
2019-02-13 17:02:01 <jwh> libvirt predated lxd though
2019-02-13 17:02:04 <SpaceToast> yes
2019-02-13 17:02:32 <jwh> at the time there was *nothing* except your own wrappers around qemu
2019-02-13 17:03:30 <jwh> better the devil you know or something, it's not the first time it's broken quite badly - theres a kernel default that was enabled without any testing it seems that breaks kvm too
2019-02-13 17:03:53 <SpaceToast> mhm
2019-02-13 17:03:59 <SpaceToast> lxd was actually broken on musl in general for a very long time
2019-02-13 17:04:06 <SpaceToast> but I noticed it and got upstream to fix it :D
2019-02-13 17:04:07 <jwh> but only libvirt seems to do things in such an order/manner that triggers it
2019-02-13 17:04:30 <jwh> but the actual kernel code is broken and nobody has fixed it
2019-02-13 17:05:42 <jwh> that script needs adjusting for alpine anyway, but stil hm
2019-02-13 17:06:13 <jwh> SpaceToast: can lxd do monitoring/stats, like disk/net/cpu etc?
2019-02-13 17:06:53 <SpaceToast> jwh: yes, `lxc info $CONTAINER`
2019-02-13 17:07:04 <SpaceToast> here's the data I currently got from running it on magni (my build server):
2019-02-13 17:07:42 <SpaceToast> IP list, Processes Running, CPU Usage (in seconds, since launch I think?), Memory Usage (current and peak), Network Usage (per-interface, bytes/packets received in lifetime)
2019-02-13 17:08:12 <SpaceToast> so you have more than VMs on some things, and less on others
2019-02-13 17:08:39 <jwh> that will probably do, how sensible is the config? like I just want the container with an eth/tap/whatever interface thrown in a bridge on start
2019-02-13 17:08:41 <SpaceToast> you can also do cgroup stuff to limit how many CPU cores they can use, pin specific ones, limit memory usage, limit swap, limit IO (network/disk) speeds/usage, etc
2019-02-13 17:08:47 <SpaceToast> that's the default :)
2019-02-13 17:08:50 <jwh> oh ok
2019-02-13 17:09:19 <jwh> guess I should have a look
2019-02-13 17:09:23 <SpaceToast> by default it makes a local bridge, assigns an auto-generated (or user-specified) IP to it, and runs dnsmasq on the host
2019-02-13 17:09:30 <jwh> oh, nooooooooooo
2019-02-13 17:09:35 <jwh> can I turn all that of?
2019-02-13 17:09:37 <jwh> off*
2019-02-13 17:09:38 <SpaceToast> yup
2019-02-13 17:09:41 <SpaceToast> I usually have it make an unconfigured bridge attached to the real network
2019-02-13 17:09:48 <SpaceToast> so it talks to my global dhcp server instead
2019-02-13 17:09:55 <SpaceToast> (full layer2 integration)
2019-02-13 17:09:59 <jwh> yeah, thats all I want, eth0 is in a bridge, just want containers dumped into the same bridge
2019-02-13 17:10:11 <SpaceToast> you can do that, but I'd recommend using a second interface
2019-02-13 17:10:23 <SpaceToast> so you can have lxd manage the container-only bridge
2019-02-13 17:10:38 <SpaceToast> makes it happier, but you can have it use unmanaged bridges too
2019-02-13 17:11:03 <jwh> hm, I'll see how upset it gets first :D
2019-02-13 17:11:05 <SpaceToast> it also integrates with zfs/lvm-thin/btrfs to make that stuff easier
2019-02-13 17:11:08 <SpaceToast> alright ^^
2019-02-13 17:11:32 <jwh> I definitely need to start using fresh containers for my aports checkouts anyway
2019-02-13 17:11:53 <SpaceToast> btw, if you need any more help, I'd recommend we move this to #alpine-offtopic :)
2019-02-13 17:11:57 <SpaceToast> but feel free to ping me whenever
2019-02-13 17:12:06 <jwh> yeah
2019-02-13 17:12:15 <SpaceToast> I personally find lxd to be *the* optimal subserver solution and am willing to help people that want to use it
2019-02-13 17:12:24 <jwh> I'll see if I can convince libvirt to be less upset first anyway, for the greater good or something
2019-02-13 17:12:25 <SpaceToast> (kind of like I find alpine to be great, and am willing to help people set it up)
2019-02-13 17:12:30 <SpaceToast> enjoy!
2019-02-13 17:12:56 <jwh> it should probably work OOTB if it's in the repo heh
2019-02-13 17:13:06 <SpaceToast> it's in testing/
2019-02-13 17:13:21 <SpaceToast> it only recently got fixed (thanks to me, upstream, and clandmeter)
2019-02-13 17:13:34 <jwh> libvirt-lxc I mean, but yeah lxd being in testing makes sense
2019-02-13 17:23:02 <jwh> bleh, can't even get it to try now... error: internal error: Failed to allocate free veth pair after 10 attempts
2019-02-13 17:24:40 <jwh> that'll probably be busybox ip though
2019-02-13 17:25:07 <SpaceToast> on servers that actually do networking, one of the first things I do is `apk add iproute2`
2019-02-13 17:25:23 <SpaceToast> I'm considering adding ifupdown to that, since now that I've seen the sources of busybox's version....
2019-02-13 17:26:18 <jwh> if only iproute2 was enough, the networking config just isn't useful enough for anything except basic things
2019-02-13 17:26:21 <jwh> :(
2019-02-13 17:27:11 <jwh> not sure what the alternative is though
2019-02-13 17:27:21 <SpaceToast> you mean ifupdown?
2019-02-13 17:27:54 <jwh> that, plus the syntax for expressing configs
2019-02-13 17:28:18 <SpaceToast> well, for cli networking config
2019-02-13 17:28:27 <SpaceToast> you have ifupdown variants, netplan.io, systemd-networkd...
2019-02-13 17:28:36 <jwh> sure, but not on alpine heh
2019-02-13 17:28:40 <SpaceToast> you also have custom solutions like netifrc
2019-02-13 17:29:09 <SpaceToast> I do find some things lacking in ifupdown, but it tends to be better than the other ones IME
2019-02-13 17:29:19 <SpaceToast> but making a new thing "kind of like that" sounds like an interesting idea
2019-02-13 17:29:35 <SpaceToast> it's particularly lacking in ipv6, e.g PD has to be handled by dhcpcd by hand, for example
2019-02-13 17:29:35 <jwh> well thats largely the problem, they're all lacking
2019-02-13 17:29:51 <jwh> I ported netifd because I could
2019-02-13 17:31:01 <jwh> but without any of the supporting stuff it's not particularly useful
2019-02-13 17:37:46 <ncopa> hi
2019-02-13 17:37:51 <ncopa> finally back
2019-02-13 17:38:24 <_ikke_> ncopa: o/
2019-02-13 17:38:33 <_ikke_> Did you enjoy your trip?
2019-02-13 17:38:53 <SpaceToast> \o/ welcome back ncopa
2019-02-13 17:38:58 <jwh> hm, so libvirt-lxc works on this other box, but not the one I tested on yesterday, awesome
2019-02-13 17:41:30 <jwh> ncopa: hey
2019-02-13 17:45:46 <ncopa> yes, it was nice to be disconnected for a while
2019-02-13 17:47:28 <jwh> so if the license is "custom", what should the value of license be in the apkbuild?
2019-02-13 17:49:09 <clandmeter> Value?
2019-02-13 17:49:23 <jwh> yes, what should it be set to
2019-02-13 17:50:01 <jwh> wiki isn't actually clear, https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license
2019-02-13 17:50:49 <clandmeter> I don't get your issue
2019-02-13 17:51:00 <clandmeter> You set it to custom
2019-02-13 17:51:14 <jwh> literally "custom" ?
2019-02-13 17:51:16 <clandmeter> And include the file in doc
2019-02-13 17:51:17 <jwh> thats what i'm asking
2019-02-13 17:51:21 <clandmeter> Yes
2019-02-13 17:51:24 <jwh> ok cool
2019-02-13 17:51:25 <jwh> thanks
2019-02-13 17:51:48 <clandmeter> We need a policy for that
2019-02-13 17:51:58 <jwh> yeah
2019-02-13 17:52:04 <clandmeter> I think the wiki is a good start
2019-02-13 17:52:32 <jwh> it just needs a note clarifying what it should be if not SPDX/OSI
2019-02-13 17:53:17 <clandmeter> custom should always include a license file in the aport
2019-02-13 17:53:31 <clandmeter> I guess that makes sense
2019-02-13 17:53:46 <jwh> yeah that's mentioned but doesn't explicitly say that it should be license="custom"
2019-02-13 17:53:55 <jwh> it's somewhat left to the reader to guess
2019-02-13 17:54:19 <clandmeter> We could add a notice in the license check
2019-02-13 17:54:52 <clandmeter> But that's post write
2019-02-13 17:55:10 <jwh> yeah
2019-02-13 17:55:36 <jwh> maybe a check if it's custom, that there is a LICENSE file or similar in -doc would be useful as well as a note on the wiki
2019-02-13 17:55:48 <clandmeter> I think SpaceToast will add a section in docs
2019-02-13 17:56:08 <SpaceToast> clandmeter: yup, that's planned, but that belongs in the developer handbook
2019-02-13 17:56:12 <SpaceToast> that's still a ways off :)
2019-02-13 17:56:35 <clandmeter> Yes but closer than before
2019-02-13 17:56:44 <SpaceToast> for sure!
2019-02-13 17:56:56 <clandmeter> Before was already uhm... Docs??
2019-02-13 17:56:56 <SpaceToast> user handbook has now entered editing cycle
2019-02-13 17:57:01 <jwh> oohhh
2019-02-13 17:57:14 <SpaceToast> once it's out I'm taking a month-ish break (avoid burnout etc) and then I start on the dev handbook :)
2019-02-13 17:57:20 <clandmeter> Grr
2019-02-13 17:57:24 <clandmeter> Autocorrect
2019-02-13 17:58:00 <SpaceToast> so I expect this to float up around mid-late april / early may, depending on what order I write the dev stuff in
2019-02-13 18:05:17 <clandmeter> ncopa, I'll send you my patched to you for rpi tomorrow
2019-02-13 18:05:29 <ncopa> good!
2019-02-13 18:05:35 <clandmeter> Patches...
2019-02-13 18:12:35 <ncopa> I think im gonna push musl update
2019-02-13 18:12:40 <ncopa> any reason to not do so?
2019-02-13 18:13:12 <clandmeter> Holiday mood
2019-02-13 18:36:57 <mps> huh, now we have to check musl patches in packages
2019-02-13 19:13:52 <ncopa> mps?
2019-02-13 19:15:21 <_ikke_> ncopa: I think they mean that if we update musl, we need to check all existing patches that fix things for our current version of musl
2019-02-13 19:15:51 <mps> ncopa: I thought maybe not all patches could be applied cleanly and some will not be needed with upgraded musl
2019-02-13 19:16:07 <ncopa> i looked over them
2019-02-13 19:16:11 <mps> _ikke_: thank for help
2019-02-13 19:16:22 <ncopa> there is only one that i need to ask kaniini about
2019-02-13 19:16:30 <ncopa> for static PIR
2019-02-13 19:16:36 <ncopa> s/PIR/PIE
2019-02-13 19:16:36 <alpine-meetbot> ncopa meant to say: for static PIE
2019-02-13 19:16:50 <jwh> huh, does grub not require extlinux anymore?
2019-02-13 19:17:12 <kaniini> ncopa: which patch is that
2019-02-13 19:17:21 <ncopa> kaniini: the handle-aux-at_base.patch
2019-02-13 19:17:30 <ncopa> i wonder if its reported upstream
2019-02-13 19:17:50 <ncopa> or if patch should be sent upstream
2019-02-13 19:18:10 <ncopa> jwh: correct, we now use grub-mkconfig instead
2019-02-13 19:18:36 <jwh> ah good
2019-02-13 19:18:57 <clandmeter> Reminds me
2019-02-13 19:19:08 <clandmeter> I had issues wish grub
2019-02-13 19:19:08 <ncopa> kaniini: this one: https://git.alpinelinux.org/aports/tree/main/musl/handle-aux-at_base.patch
2019-02-13 19:19:27 <kaniini> ask dalias about it
2019-02-13 19:19:30 <kaniini> he gave it to me
2019-02-13 19:19:31 <kaniini> :)
2019-02-13 19:19:39 <ncopa> lol
2019-02-13 19:19:41 <ncopa> ok
2019-02-13 19:19:51 <kaniini> it is needed for certain glibc binaries
2019-02-13 19:20:45 <ncopa> _ikke_: please see PM
2019-02-13 19:25:44 <ncopa> kaniini: btw, i saw that your stack gap size increase patch got upstreamed
2019-02-13 19:28:15 <mps> I also noticed that doubling, is it good or bad?
2019-02-13 19:29:27 <mps> more memory will be used as first thing, but maybe stack will be safer
2019-02-13 19:32:05 <ncopa> its good
2019-02-13 19:33:40 <mps> yes, right now reread release notes about it, sounds good
2019-02-13 19:34:00 <ncopa> there was some stack gap vulnerability some time ago, which would jump over the page protecting stack
2019-02-13 19:34:25 <ncopa> i think there was only a single function in musl that used more than 1 page of stack
2019-02-13 19:34:49 <ncopa> so only that function was exploitable
2019-02-13 19:34:54 <ncopa> i dont remember which func it was
2019-02-13 19:35:12 <ncopa> with this patch we plugged that too
2019-02-13 19:35:34 <jwh> hm, where is boot-time scripts/runlevels setup?  adding alpine-base doesn't do it, is it in setup-alpine?
2019-02-13 19:35:51 <clandmeter> initramfs
2019-02-13 19:36:08 <jwh> well I mean, when installing to e.g a chroot (or in this case, another disk)
2019-02-13 19:36:21 <clandmeter> for the base, rest is setup-alpine
2019-02-13 19:36:26 <jwh> ah hm ok
2019-02-13 19:36:42 <mps> I expect better performance from this increase in stack size and guard size
2019-02-13 19:36:50 <clandmeter> setup-alpine will use the running system
2019-02-13 19:36:58 <clandmeter> its not ment to run from another os
2019-02-13 19:37:08 <jwh> what I mean is:
2019-02-13 19:37:14 <jwh> bash-4.4# rc-update
2019-02-13 19:37:14 <jwh> bash-4.4#
2019-02-13 19:37:50 <jwh> guess I can just add the same from the running system, was just hoping there might be a convenient bit I can get the defaults from
2019-02-13 19:38:24 <clandmeter> initramfs-init has the basics
2019-02-13 19:38:47 <jwh> https://github.com/alpinelinux/alpine-make-vm-image/blob/master/alpine-make-vm-image#L462
2019-02-13 19:38:50 <jwh> I cheated :D
2019-02-13 19:39:04 <jwh> yeah but that doesn't help when bootstrapping
2019-02-13 19:39:05 <clandmeter> yes i was about to mention that.
2019-02-13 19:40:25 <mps> building llvm6 on musl 1.1.21 passed fine :)
2019-02-13 19:40:26 <ncopa> jwh: initramfs does that on the first boot, the setup-disk script will clone the running system
2019-02-13 19:40:32 <jwh> ncopa: ahhhh
2019-02-13 19:40:53 <clandmeter> thats what i just said :p
2019-02-13 19:41:18 <jwh> I can't boot the installer on this box, so i'm installing from existing OS
2019-02-13 19:41:20 <ncopa> clandmeter: sorry for repeating you :)
2019-02-13 19:41:31 <jwh> otherwise yeah I'd just use setup-alpine
2019-02-13 19:41:42 <ncopa> jwh: so you would need to copy the logic from initramfs
2019-02-13 19:41:59 <clandmeter> i did the same on scaleway to make my own image
2019-02-13 19:42:10 <ncopa> i mean, manually add the services that are needed
2019-02-13 19:42:15 <clandmeter> use regular apk add --root
2019-02-13 19:42:20 <clandmeter> and do the other parts manually
2019-02-13 19:42:22 <jwh> yeah thats what I did
2019-02-13 19:42:32 <ncopa> then you did good :)
2019-02-13 19:42:56 <jwh> I *did* have an image that had all this done (and bios+efi boot), but it's nowhere to be seen now :(
2019-02-13 19:43:40 <clandmeter> i did have efi issues on scaleway
2019-02-13 19:43:56 <clandmeter> the naming of the efi loader is incorrect
2019-02-13 19:44:01 <jwh> ah heh
2019-02-13 19:44:08 <jwh> they do weird stuff
2019-02-13 19:44:15 <clandmeter> we do distro/whatever.efi
2019-02-13 19:44:28 <clandmeter> alpine/...
2019-02-13 19:44:31 <jwh> yeah
2019-02-13 19:44:40 <jwh> the default path is boot/boot$arch.efi
2019-02-13 19:44:42 <clandmeter> im not sure it was the file or the parent dir
2019-02-13 19:44:49 <clandmeter> yeah, that works
2019-02-13 19:44:59 <clandmeter> efi is a mess regrading that.
2019-02-13 19:45:01 <jwh> really whatever sets up the bootloader should copy it to the right place as well
2019-02-13 19:45:07 <jwh> since efivars isn't always available
2019-02-13 19:45:10 <jwh> or used....
2019-02-13 19:45:23 <clandmeter> good luck on a vm :)
2019-02-13 19:45:52 <jwh> well thats why my image had it where it was expected, boot/bootia32.efi and bootiax64.efi or w/e
2019-02-13 19:45:57 <jwh> can't remember the names
2019-02-13 19:45:59 <clandmeter> ncopa: i also noticed vga issues with grub
2019-02-13 19:46:10 <clandmeter> i needed to enable all_video or it wont show
2019-02-13 19:47:08 <clandmeter> :q
2019-02-13 19:47:12 <clandmeter> oops
2019-02-13 19:47:39 <clandmeter> glad it wasnt my login prompt :)
2019-02-13 19:49:36 <danieli> ha
2019-02-13 19:49:43 <danieli> password123
2019-02-13 19:49:50 <danieli> crap, that wasn't my terminal!
2019-02-13 19:49:59 <clandmeter> wtf how did you know?
2019-02-13 19:50:09 <danieli> i'm psychic when it comes to passwords :)
2019-02-13 19:50:13 <SpaceToast> hunter2
2019-02-13 19:50:44 <_ikke_> Why do I see *******?
2019-02-13 19:51:40 <danieli> clandmeter: or I'm just doing password reuse attacks on you ;) https://haveibeenpwned.com/
2019-02-13 19:52:01 <SpaceToast> _ikke_: because freenode automatically censors your password!
2019-02-13 19:52:31 <_ikke_> aha, wow, did not know that
2019-02-13 19:52:33 <_ikke_> :P
2019-02-13 19:52:46 <_ikke_> myawesomepassword
2019-02-13 19:54:44 <SpaceToast> wow! all I see is ********!
2019-02-14 01:00:26 <jwh> hm
2019-02-14 01:01:07 <jwh> I need to fix grub... did anyone have any thoughts on adding i386-efi?  I'm not sure how to name it, i386_efi is *ugly* and really it should be part of grub-efi
2019-02-14 01:01:15 <jwh> I have a diff somewhere
2019-02-14 06:29:20 <jwh> hm, does it mention anywhere that if dhcpcd isinstalled that will be used instead? I can't find anything pertaining to it
2019-02-14 06:36:58 <SpaceToast> jwh: read from here onwards https://git.busybox.net/busybox/tree/networking/ifupdown.c#n98
2019-02-14 06:39:13 <jwh> ahhhh its in busybox not alpine
2019-02-14 06:39:18 <jwh> that explains why I couldn't find it :D
2019-02-14 06:40:11 <jwh> thanks
2019-02-14 06:40:27 <jwh> 
ACTION adds dhcpcd to default package list

2019-02-14 09:34:11 <danieli> what do we think of using a fork to replace a dead project?
2019-02-14 09:34:16 <danieli> knockd, in this instance
2019-02-14 09:40:30 <ncopa> danieli: if the fork is maintained, then ok with me
2019-02-14 09:41:30 <danieli> ncopa: gotcha
2019-02-14 09:42:09 <mps> if you fork project you have to take responsibility to maintain it, but you know that. imo, forked or not it just important how it is maintained
2019-02-14 09:43:37 <mps> btw, Alpine have fwknop, which better fills my use cases than knockd
2019-02-14 09:50:17 <danieli> ncopa: http://tpaste.us/aR6Z
2019-02-14 09:50:25 <danieli> I'm at an airport so here you go, a patch
2019-02-14 10:11:57 <kaniini> danieli: heh i found out the problem :)))))
2019-02-14 10:12:31 <kaniini> danieli: IBM has some eco mode crap where they undervolt the memory (which works fine with *their* memory, but does not work so fine with IS memory configurations)
2019-02-14 10:12:48 <kaniini> i disabled said eco mode crap
2019-02-14 10:12:51 <kaniini> and life has been better
2019-02-14 10:20:29 <ncopa> danieli: there is a 0.8 tag, so i think we should use that instead of a specific git commit
2019-02-14 10:32:31 <clandmeter> this repo has issues disabled.
2019-02-14 10:32:40 <clandmeter> i sounds like a bad choice as upstream
2019-02-14 10:32:42 <clandmeter> it
2019-02-14 11:28:21 <ncopa> have good and bad news re chromium
2019-02-14 11:28:30 <ncopa> good is that i managed update it to 72
2019-02-14 11:28:37 <ncopa> bad is that it is still broken :-(
2019-02-14 11:28:46 <ncopa> this chromium issue drives me nuts
2019-02-14 11:32:02 <fcolista> ncopa, I have a fix for GNS3. Edge is fine, but on 3.9-stable is still broken. I want to commit these two patches (cherry-picked from edge). Would you agree?
2019-02-14 11:32:02 <fcolista> https://dpaste.de/frbO/raw
2019-02-14 11:32:09 <fcolista> https://dpaste.de/kF0Y/raw
2019-02-14 11:44:57 <ncopa> fcolista: i guess thats ok
2019-02-14 11:45:11 <ncopa> there are some questionable whitespace changes in first commit
2019-02-14 11:45:18 <ncopa> tabs replaced with spaces
2019-02-14 11:50:13 <jwh> aha, error: internal error: no cgroup backend available
2019-02-14 11:50:30 <jwh> that was the error I was getting
2019-02-14 11:52:36 <jwh> I can't figure out what its missing
2019-02-14 11:52:52 <clandmeter> what are you trying to do?
2019-02-14 11:53:11 <jwh> figure out why libvirt-lxc sometimes works, sometimes doesn't
2019-02-14 11:53:26 <jwh> on one box it work(ed), now it doesn't
2019-02-14 11:53:39 <clandmeter> cgroups service is started?
2019-02-14 11:53:42 <jwh> for no apparent reason *except* a newer linux-vanilla
2019-02-14 11:53:46 <jwh> hm
2019-02-14 11:54:21 <jwh> ok thats odd, it wasn't started, or at least didn't start properly
2019-02-14 11:54:28 <jwh> but it *did* before
2019-02-14 11:54:42 <clandmeter> does it start properly now?
2019-02-14 11:54:47 <jwh> yeah
2019-02-14 11:54:54 <jwh> but what the hell, why did it stop
2019-02-14 11:54:59 <clandmeter> make sure it starts at boot
2019-02-14 11:55:16 <clandmeter> lxc depends on openrc
2019-02-14 11:55:18 <clandmeter> err
2019-02-14 11:55:21 <clandmeter> cgroups
2019-02-14 11:55:22 <clandmeter> via openrc
2019-02-14 11:55:40 <jwh> hm, libvirt should probably also depend on it
2019-02-14 11:55:45 <clandmeter> so if you do things manually with lxc you need to do that mnaully too
2019-02-14 11:55:57 <clandmeter> could be.
2019-02-14 11:56:09 <jwh> wonder what was starting it before so that it was working
2019-02-14 11:56:13 <clandmeter> i have no clue about libvirt, maybe in some sittuations its not neeed
2019-02-14 11:56:59 <jwh> it's definitely needed for lxc, maybe other cases like kvm also if using namespaces
2019-02-14 11:58:01 <jwh> yeah so, on the box it works OOTB on, cgroups isn't started by default either
2019-02-14 11:58:04 <jwh> something starts it
2019-02-14 11:58:23 <jwh> but... this new box is a direct copy of that, just that its been updated
2019-02-14 11:58:43 <clandmeter> something has requested cgroups
2019-02-14 11:58:49 <jwh> yeah
2019-02-14 11:58:51 <clandmeter> scan your initd files for cgroups inclusion
2019-02-14 11:58:52 <jwh> question is what has changed
2019-02-14 11:59:25 <jwh> it's only mentioned by lxc, but that isn't enabled on either
2019-02-14 12:01:44 <jwh> going to drive me mental lol
2019-02-14 12:03:00 <clandmeter> maybe set openrc to debug and see what happens.
2019-02-14 12:03:04 <clandmeter> not sure  htat makes a diff.
2019-02-14 12:03:24 <jwh> yeah I'll have to see if I can reproduce it properly
2019-02-14 12:11:18 <mps> how to fixes programs which needs libcurses.a, in Alpine we have libncursesw.a
2019-02-14 12:12:23 <mps> add link to libcurses.at to libncursesw.a or patch the program
2019-02-14 12:31:47 <jwh> ok next thing, why isn't the mmc/sd slot on this working, kernel config looks like it should work
2019-02-14 12:32:12 <jwh> it should look like....
2019-02-14 12:32:14 <jwh> [    3.744958] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
2019-02-14 12:32:14 <jwh> [    3.761429] mmc1: SDHCI controller on ACPI [80860F14:00] using ADMA
2019-02-14 12:32:14 <jwh> [    3.781344] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
2019-02-14 12:32:22 <jwh> but mmc2 is missing on my alpine one
2019-02-14 12:32:30 <jwh> identical devices, other has arch
2019-02-14 12:37:21 <fcolista> ncopa, let me fix the whitespace there
2019-02-14 13:17:04 <mps> are there any guides how to make dynamic and static packages of the compilers from the same APKBUILD
2019-02-14 13:17:46 <mps> I have seen and worked with static libs
2019-02-14 14:01:39 <jwh> bleh screw it, libvirt-lxc is just hopelessly broken
2019-02-14 14:01:46 <jwh> shutdown reboots, destroy errors
2019-02-14 14:02:11 <jwh> doesn't work on systemd, and now not non-systemd
2019-02-14 14:02:12 <jwh> gg
2019-02-14 14:13:19 <jwh> compile time options are wrong anyway
2019-02-14 14:18:14 <jwh> or at least, it needs some post-install loving
2019-02-14 14:58:33 <jwh> SpaceToast: lxd needs bsdtar btw, busybox tar won't cut it
2019-02-14 14:58:39 <jwh> or maybe gtar
2019-02-14 14:58:41 <jwh> whichever
2019-02-14 14:59:23 <jwh> just a dependency on gtar should do
2019-02-14 15:15:58 <clandmeter> jwh: which alpine version are you on?
2019-02-14 15:16:56 <jwh> edge
2019-02-14 15:17:31 <clandmeter> is libvirt compatible with lxc v3?
2019-02-14 15:17:51 <jwh> I'd hope so, it works... just not very well
2019-02-14 15:18:02 <jwh> can't shutdown guests, can't destroy
2019-02-14 15:18:18 <jwh> shutdown is reboot regardless of the config
2019-02-14 15:20:10 <clandmeter> v3 has lots of changes, could be compat issue.
2019-02-14 15:20:27 <jwh> hm perhaps
2019-02-14 15:21:14 <jwh> it's broken in other absurd ways on other distros too though, so I've just given up on it as its not usable
2019-02-14 15:21:56 <jwh> you'd think since its a redhat product now they'd get it working properly with systemd
2019-02-14 15:22:51 <fcolista>  /0\
2019-02-14 15:26:49 <jwh> fcolista: yo
2019-02-14 15:26:58 <jwh> fcolista: lxd needs a dependency on tar :D
2019-02-14 15:31:54 <fcolista> ok
2019-02-14 15:32:23 <jwh> it passes --xattrs options that busybox tar doesn't understand
2019-02-14 15:35:47 <fcolista> jwh, jsut updated
2019-02-14 15:35:51 <jwh> cool thanks
2019-02-14 15:36:08 <fcolista> thix lxd is too much integrated with systemd stuff
2019-02-14 15:36:21 <fcolista> in the long run, maintaining this will be a nightmare
2019-02-14 15:36:22 <jwh> heh
2019-02-14 15:36:27 <fcolista> (also now...)
2019-02-14 15:36:45 <jwh> yeah it's not looking promising for a bunch of projects
2019-02-14 15:37:49 <fcolista> how r u using lxd, if i can ask?
2019-02-14 15:38:07 <jwh> not very well yet, trying to convince it to actually wor
2019-02-14 15:38:09 <jwh> work*
2019-02-14 15:38:29 <SpaceToast> I've been using it just fine since the 3.10 bump as my main server multiplexer at home
2019-02-14 15:38:40 <SpaceToast> and I've been using it at work for something like 2 years
2019-02-14 15:38:42 <SpaceToast> \o\
2019-02-14 15:39:00 <fcolista> SpaceToast, multiplexer server?
2019-02-14 15:39:05 <SpaceToast> it looks like people just have trouble remembering the subuid/gid stuff, since it's specific to (all) container servers
2019-02-14 15:39:07 <fcolista> (btw: bumped with tar)
2019-02-14 15:39:26 <SpaceToast> fcolista: just a term that means "running many servers on one system", meant to encompass VMs, paravirt and containers
2019-02-14 15:39:31 <jwh> well, a user would expect lxd init && lxc launch whatever (as given by lxd) would just wor tbf (not including the subuid/gid bits)
2019-02-14 15:39:41 <jwh> work*
2019-02-14 15:40:01 <jwh> I got uh
2019-02-14 15:40:02 <jwh> Error: Failed to run: /memfd:liblxc (deleted) forkstart special-mudfish /var/lib/lxd/containers /var/log/lxd/special-mudfish/lxc.conf:
2019-02-14 15:40:06 <jwh> Try `lxc info --show-log local:special-mudfish` for more info
2019-02-14 15:40:08 <jwh> log was empty
2019-02-14 15:40:20 <SpaceToast> strange
2019-02-14 15:40:28 <SpaceToast> I currently have lxd running quite well
2019-02-14 15:40:46 <jwh> just nuked it, starting again
2019-02-14 15:40:56 <SpaceToast> ok, I was gonna ask for configs
2019-02-14 15:41:13 <SpaceToast> also lxd version (make sure you're on 3.10 or higher)
2019-02-14 15:41:15 <jwh> just accepted the defaults, except using existing br0, rather than a new one
2019-02-14 15:41:34 <jwh> lxd-3.10-r0
2019-02-14 15:41:39 <jwh> whatever is in edge
2019-02-14 15:41:47 <jwh> or testing, actually
2019-02-14 15:42:31 <jwh> oh thats cool, it didn't even save the config
2019-02-14 15:43:12 <fcolista> jwh: http://dup.pw/aports/d1680677
2019-02-14 15:43:17 <jwh> wonder if printing the preseed is whats breaking that, lets see
2019-02-14 15:43:41 <jwh> fcolista: awesome
2019-02-14 15:43:46 <SpaceToast> it probably is, printing preseed is meant for setting up clusters
2019-02-14 15:43:53 <SpaceToast> (so you copy that to every system and set up all at once)
2019-02-14 15:43:57 <jwh> yeah
2019-02-14 15:44:09 <fcolista> jwh, package is built. Just wait for having it available in the repo.
2019-02-14 15:44:16 <fcolista> ping me if i can do something else
2019-02-14 15:44:20 <SpaceToast> ^ same
2019-02-14 15:44:21 <jwh> tinkerbell:~# lxc launch ubuntu:18.04
2019-02-14 15:44:21 <jwh> Creating the container
2019-02-14 15:44:24 <jwh> lets see
2019-02-14 15:44:27 <SpaceToast> I have to go do "waking up" stuff ^^
2019-02-14 15:44:28 <fcolista> I'll leave in 15min
2019-02-14 15:44:32 <jwh> okies
2019-02-14 15:44:38 <SpaceToast> I'll be back in ~an hour though
2019-02-14 15:44:49 <fcolista> I would use lxd with two host, actually, and zfs as storage
2019-02-14 15:45:02 <jwh> well, I was going to investigate the clustering once it works locally
2019-02-14 15:45:03 <fcolista> trying also to do "live migration" among the nodes
2019-02-14 15:45:08 <jwh> yeah
2019-02-14 15:45:15 <fcolista> that would be /cool/
2019-02-14 15:45:25 <SpaceToast> preferably 3 so you can have a real quorum in your cluster :)
2019-02-14 15:45:26 <jwh> thats what i'm looking forward too :D
2019-02-14 15:45:34 <SpaceToast> I might eventually get one running at $dayjob
2019-02-14 15:45:36 <fcolista> +1 SpaceToast :)
2019-02-14 15:45:40 <SpaceToast> (well I'll have two soon enough)
2019-02-14 15:45:40 <jwh> hm can you have a vote-only node?
2019-02-14 15:45:45 <SpaceToast> at home one is just fine though
2019-02-14 15:45:50 <SpaceToast> jwh: sure, just don't put any containers on it
2019-02-14 15:45:53 <jwh> ah
2019-02-14 15:45:55 <jwh> fair enough
2019-02-14 15:45:58 <fcolista> hehe
2019-02-14 15:46:02 <jwh> alright, so it failed in the same way, sigh
2019-02-14 15:46:15 <fcolista> sometimes, the coolest solutions are the easiest ;-)
2019-02-14 15:46:28 <SpaceToast> fcolista: it's honestly quite unfortunate that there are issues, at least for me, lxd has been undeniably best in-class
2019-02-14 15:46:40 <jwh> http://ix.io/1B3D
2019-02-14 15:46:43 <jwh> helpful :D
2019-02-14 15:46:53 <fcolista> SpaceToast, yeah...
2019-02-14 15:46:55 <SpaceToast> (compared to docker (though might not be same class), libvirt, lxc standalone, etc)
2019-02-14 15:47:10 <fcolista> I use lxc a lot
2019-02-14 15:47:14 <fcolista> but standalone
2019-02-14 15:47:16 <jwh> it wasn't that long ago libvirt actually worked, and it was just delightful
2019-02-14 15:47:35 <SpaceToast> lxc standalone is kind of a pain to do a lot of things with, like shared volumes
2019-02-14 15:47:39 <jwh> but its broken now, and doesn't work with recent systemd as it hijacks everything
2019-02-14 15:47:58 <jwh> nspawn touching things it shouldn't, really
2019-02-14 15:48:04 <fcolista> jwh, after the "tar" issue, what else is broken with lxd in edge?
2019-02-14 15:48:33 <jwh> thats the only thing for packaging, theres a lack of subuid/gid in shadow-uidmap but thats an easy fix realy
2019-02-14 15:48:34 <SpaceToast> fcolista: they think /etc/subuid should be auto-populated at least for root, but that's not your package afaik
2019-02-14 15:48:36 <jwh> really*
2019-02-14 15:48:41 <jwh> yeah
2019-02-14 15:49:00 <fcolista> SpaceToast, ok. That can be easily generated as a normal installation step, right?
2019-02-14 15:49:02 <jwh> atm it won't even boot a container with the defaults (lxd managed bridge)
2019-02-14 15:49:25 <SpaceToast> fcolista: the issue is that that file's meant to be user-generated, so it's kind of... complicated
2019-02-14 15:49:37 <SpaceToast> jwh: try apk fix-ing liblxc and co
2019-02-14 15:49:42 <fcolista> yes, this is what I meant
2019-02-14 15:49:49 <fcolista> is something that the user does
2019-02-14 15:49:58 <fcolista> after they have installed lxd
2019-02-14 15:50:05 <jwh> well... theres no harm in shipping a sane default for root at least
2019-02-14 15:50:11 <SpaceToast> normally, yeah, it just seems that no one is aware of it
2019-02-14 15:50:17 <fcolista> tbh, was better to say "configuration" step
2019-02-14 15:50:24 <jwh> especially as lxd requires it even for root
2019-02-14 15:50:44 <SpaceToast> fcolista: perhaps we could print a post-first-install message suggesting users set it up?
2019-02-14 15:50:46 <jwh> and its probably only a matter of time before other packages do the same
2019-02-14 15:50:53 <fcolista> APKBUILD can have triggers which come up with a README saying "hey this is what you need to do...."
2019-02-14 15:51:19 <fcolista> SpaceToast, exactly. Is not a post-install message, riather a trigger. But that was the idea, yes
2019-02-14 15:51:43 <jwh> wait
2019-02-14 15:51:59 <jwh> (deleted), looks like lsof or similar output?
2019-02-14 15:52:11 <jwh> but either way, its supposed to have something there
2019-02-14 15:52:18 <SpaceToast> I don't use lsof often enough to know
2019-02-14 15:52:28 <jwh> it appears in the config too
2019-02-14 15:52:35 <SpaceToast> yeah, so it looks like something's missing
2019-02-14 15:52:40 <SpaceToast> potentially lxc
2019-02-14 15:53:05 <jwh> well, I need lxc to launch it, so its installed, did apk fix just in case, no errors though
2019-02-14 15:53:09 <SpaceToast> speaking of, make sure you have the cgroups service enabled (usually it goes into boot)
2019-02-14 15:53:14 <jwh> lxc.hook.pre-start = /memfd:liblxc (deleted) callhook /var/lib/lxd 2 start
2019-02-14 15:53:14 <jwh> lxc.hook.post-stop = /memfd:liblxc (deleted) callhook /var/lib/lxd 2 stop
2019-02-14 15:53:14 <SpaceToast> and the lxd service started
2019-02-14 15:53:30 <jwh> that (deleted) shouldn't be there
2019-02-14 15:53:38 <SpaceToast> let me look at what I have
2019-02-14 15:53:40 <jwh> otherwise it looks ok
2019-02-14 15:53:52 <jwh> and yeah I got cgroups
2019-02-14 15:54:06 <SpaceToast> huh
2019-02-14 15:54:18 <SpaceToast> that `/memfd:liblxc (deleted)` should just be `/usr/sbin/lxd`
2019-02-14 15:54:32 <SpaceToast> at least that's what it is on my system
2019-02-14 15:54:39 <SpaceToast> but I have to go for that specified period now, bbl \o
2019-02-14 15:54:41 <jwh> it looks like some hacky shell scripts generate it
2019-02-14 15:54:42 <jwh> kk
2019-02-14 15:54:53 <SpaceToast> it's generated by go code :D
2019-02-14 15:55:00 <jwh> same thing!
2019-02-14 15:55:08 <jwh> also, just for completeness:
2019-02-14 15:55:12 <jwh> tinkerbell:~# grep cgroup /etc/init.d/lxd
2019-02-14 15:55:12 <jwh> tinkerbell:~# grep cgroup /etc/init.d/lxc
2019-02-14 15:55:12 <jwh>         need localmount sysfs cgroups
2019-02-14 15:56:35 <jwh> same/similar cgroup setup in lxd might be useful
2019-02-14 15:57:37 <jwh> tinkerbell:~# lsof | grep liblxc
2019-02-14 15:57:37 <jwh> 3222    /memfd:liblxc (deleted) /dev/null
2019-02-14 15:57:37 <jwh> 3222    /memfd:liblxc (deleted) /dev/null
2019-02-14 15:57:42 <jwh> yeah its parsing lsof output
2019-02-14 15:57:45 <jwh> how disgusting
2019-02-14 15:58:35 <jwh> it's likely that because it failed before and the fd is still open, the terrible parsing is picking up the wrong output
2019-02-14 15:59:55 <jwh> problem is, whatever startup does causes lots of left over fd's for deleted files
2019-02-14 16:03:55 <jwh> unless.... I wonder
2019-02-14 16:05:04 <jwh> nope not that
2019-02-14 16:08:52 <jwh> what I wanna know is what ridiculous person decided parsing lsof was a good, and why its needed for a binary location?!
2019-02-14 16:08:57 <jwh> good idea*
2019-02-14 16:15:25 <SpaceToast> jwh: have you tried `rc-service lxd restart`?
2019-02-14 16:15:34 <SpaceToast> it's possible that `apk fix liblxc` broke the fd
2019-02-14 16:18:22 <jwh> its like that after a fresh boot
2019-02-14 16:18:47 <jwh> I thought maybe it was busybox lsof ignoring flags (as it does), but real lsof doesn't work either
2019-02-14 16:19:08 <jwh> but either way whichever dumbass added the code to parse lsof needs to be shot :D
2019-02-14 16:20:15 <jwh> well I mean, it could be something else, but its persistent even if I replace lsof with a shell script
2019-02-14 16:20:29 <SpaceToast> doesn't that suggest it's *not* lsof?
2019-02-14 16:20:49 <SpaceToast> or do you mean that if you put `echo hello world` into /usr/bin/lsof it outputs that into lxc.conf?
2019-02-14 16:20:52 <jwh> yes, but the string (deleted) (and the fd name) is from lsof
2019-02-14 16:20:56 <jwh> maybe some built in thing I dunno
2019-02-14 16:21:06 <SpaceToast> so... not lsof, then
2019-02-14 16:21:12 <SpaceToast> just similar format
2019-02-14 16:21:25 <jwh> well, it's go, so there is probably lsof written in go because why the hell not
2019-02-14 16:21:26 <SpaceToast> so they're parsing open fds (which is strange, but less strange than running lsof and capturing output)
2019-02-14 16:21:28 <jwh> :D
2019-02-14 16:21:50 <jwh> but actually, I think thats the format the kernel dumps it in too
2019-02-14 16:21:57 <SpaceToast> hmm
2019-02-14 16:22:07 <SpaceToast> sounds like you have some problems on your system
2019-02-14 16:22:22 <jwh> fresh install should really not be this broken
2019-02-14 16:22:29 <SpaceToast> mine was a fresh install too
2019-02-14 16:22:34 <SpaceToast> and works fine
2019-02-14 16:22:52 <jwh> what else do you have installed?
2019-02-14 16:23:00 <jwh> because...
2019-02-14 16:23:23 <mps> for what is used compiler-rt in Alpine? nothing depends on it, as far as I found
2019-02-14 16:23:26 <jwh> http://ix.io/1B3M
2019-02-14 16:23:34 <SpaceToast> http://tpaste.us/NKwB
2019-02-14 16:23:35 <jwh> that should probably not be present just by lxd starting
2019-02-14 16:23:50 <jwh> hm
2019-02-14 16:23:51 <jwh> let me see
2019-02-14 16:24:09 <SpaceToast> `lsof | grep liblxc` has no output
2019-02-14 16:24:54 <SpaceToast> ignore the lxc-libs thing, that was during debugging for 3.10, shouldn't really affect anything
2019-02-14 16:24:55 <jwh> hm
2019-02-14 16:25:30 <SpaceToast> (I have the "current" version installed atm, it's just a remnant in world; removed it and `apk add` didn't change anything)
2019-02-14 16:25:31 <jwh> which runlevel do you have lxd in?
2019-02-14 16:25:48 <SpaceToast> default
2019-02-14 16:25:50 <SpaceToast> and cgroups in boot
2019-02-14 16:25:54 <jwh> mmk
2019-02-14 16:26:26 <SpaceToast> http://sprunge.us/IIkzbr - openrc
2019-02-14 16:26:44 <SpaceToast> lxcfs isn't required btw, I had everything working without it
2019-02-14 16:26:47 <jwh> so really, the same as me
2019-02-14 16:26:52 <SpaceToast> it's just so containers see hardware as per their caps
2019-02-14 16:26:58 <SpaceToast> yeah, as I said, something seems to be seriously wrong with your system
2019-02-14 16:27:01 <jwh> sans lxcfs
2019-02-14 16:27:21 <jwh> well it can't possibly be, since its installed from fresh
2019-02-14 16:27:22 <SpaceToast> lxcfs is a post-everything-works addition so htop and co. show containers their restrictions
2019-02-14 16:27:47 <jwh> but either way... lxd really shouldn't need to be checking open fds if the path is literally /usr/sbin/lxd
2019-02-14 16:27:52 <jwh> its dumb
2019-02-14 16:28:08 <SpaceToast> well, it's /usr/sbin/lxd *here*
2019-02-14 16:28:18 <SpaceToast> but in general it should probably use $PATH
2019-02-14 16:28:42 <jwh> its just asking to fail by doing stupid things like that
2019-02-14 16:32:24 <jwh> I wonder... if it was something that was broken during init and thats carried over to anything I create and thus whatever I do makes no odds :D
2019-02-14 16:35:12 <SpaceToast> maybe ¯\_(ツ)_/¯
2019-02-14 16:49:44 <jwh> so, just to prove a point
2019-02-14 16:49:53 <jwh> entirely new  VM on vultr
2019-02-14 16:50:42 <jwh> setup-alpine, rc-update add cgroups boot, apk add lxd, rc-update add lxd, reboot
2019-02-14 16:50:48 <jwh> those same deleted entries exist
2019-02-14 16:52:06 <jwh> oh and switching to edge and apk -U upgrade -a before adding lxd, of course
2019-02-14 16:53:58 <SpaceToast> then I wonder why *my* system works well
2019-02-14 16:54:06 <jwh> is it literally a brand new install?
2019-02-14 16:54:09 <SpaceToast> yup
2019-02-14 16:54:20 <SpaceToast> from 3.9 rc image
2019-02-14 16:54:27 <SpaceToast> literally installed specifically to host lxd
2019-02-14 16:54:29 <jwh> hmmm
2019-02-14 16:54:42 <jwh> only difference then is I'm installing from the release iso
2019-02-14 16:54:43 <SpaceToast> it was broken for a bit because lxd 3.9 had that musl issue
2019-02-14 16:55:03 <jwh> are you using edge, or just testing for lxd?
2019-02-14 16:55:05 <SpaceToast> but it still worked, just the thing was broken
2019-02-14 16:55:07 <SpaceToast> I'm full edge
2019-02-14 16:55:26 <jwh> ok, so whats the difference
2019-02-14 16:55:38 <jwh> do you just do lxd init, lxc launch ?
2019-02-14 16:55:54 <SpaceToast> well lxd init happened a while ago, but yeah
2019-02-14 16:56:11 <jwh> hm, previous version?
2019-02-14 16:56:20 <SpaceToast> yes, but I don't think they changed anything in the init code
2019-02-14 16:56:29 <SpaceToast> and erm, all it does is populate the default profile
2019-02-14 16:56:32 <SpaceToast> and storage/network
2019-02-14 16:56:44 <jwh> hm
2019-02-14 16:56:52 <SpaceToast> and all my default profile does is say "storage there, network there"
2019-02-14 16:59:25 <SpaceToast> but you're really not supposed to have weird closed memfds
2019-02-14 16:59:42 <SpaceToast> lsof | grep memfd -> no output
2019-02-14 16:59:47 <SpaceToast> but for `fd` I do have a few, lxd-related
2019-02-14 17:00:03 <SpaceToast> http://tpaste.us/xpKD
2019-02-14 17:00:24 <SpaceToast> guessing it doesn't *parse* fds, it's just trying to find the invocator of the event handler (itself)
2019-02-14 17:00:31 <SpaceToast> but for some reason it's broken on your system
2019-02-14 17:00:31 <jwh> yeah probably
2019-02-14 17:00:47 <jwh> if its broken by setup-alpine, its probably broken on all systems
2019-02-14 17:00:48 <jwh> heh
2019-02-14 17:00:50 <SpaceToast> which is seriously wrong ^^
2019-02-14 17:00:51 <jwh> question is why
2019-02-14 17:00:55 <SpaceToast> that's true I didn't use setup-alpine
2019-02-14 17:00:58 <SpaceToast> I set up my systems by hand
2019-02-14 17:01:02 <SpaceToast> (+ setup-disk)
2019-02-14 17:01:16 <SpaceToast> because I have... specific partitioning needs
2019-02-14 17:01:24 <SpaceToast> but how would setup-alpine break fds?
2019-02-14 17:02:31 <jwh> well it doesn't, but thats the "proper" install method so if that doesn't work (didn't work with my normal setup by hand either, so using setup-alpine rules out something I did)
2019-02-14 17:02:58 <SpaceToast> it's so proper we're considering replacing/rewriting it ^^
2019-02-14 17:03:09 <SpaceToast> speaking of "proper" install methods...
2019-02-14 17:03:39 <SpaceToast> the docs are actually in the editing cycle right now (still beta, I'll push it to 0.1b from 0.1a soon), if you wanna double check to make sure everything looks right
2019-02-14 17:04:09 <jwh> hm, actually, what arch?
2019-02-14 17:04:18 <SpaceToast> x86_64
2019-02-14 17:04:49 <jwh> alright, I'm out of ideas
2019-02-14 17:04:53 <jwh> but yeah shoot me the docs and I'll have a look
2019-02-14 17:05:49 <jwh> oh, sec, +g
2019-02-14 17:05:56 <jwh> go, sorry
2019-02-14 17:06:25 <SpaceToast> not sure what/how much you got ^^
2019-02-14 17:06:31 <SpaceToast> didn't notice your +g before sending
2019-02-14 17:06:56 <jwh> still on from the stupid spambots
2019-02-14 17:18:43 <jwh> would really help if the debug was... well, debug
2019-02-14 17:18:44 <jwh> heh
2019-02-14 17:19:02 <jwh> apparentl debug means "normal level of logging you'd expect"
2019-02-14 17:19:07 <jwh> apparently*
2019-02-14 17:19:10 <SpaceToast> hold on re: debug
2019-02-14 17:19:23 <SpaceToast> for real debug you want
2019-02-14 17:19:25 <SpaceToast> --debug --verbose
2019-02-14 17:19:30 <SpaceToast> in /etc/conf.d/lxd
2019-02-14 17:19:44 <jwh> I've got it running in a screen window with those flags
2019-02-14 17:19:52 <jwh> still looks like normal logs heh
2019-02-14 17:20:04 <SpaceToast> the --verbose part is for lcx
2019-02-14 17:20:06 <SpaceToast> lxc*
2019-02-14 17:20:10 <jwh> I need it to dump what its actually doing, without attaching it to strace or similar
2019-02-14 17:20:11 <SpaceToast> lxc's logs become erm... quite large
2019-02-14 17:20:13 <jwh> hm
2019-02-14 17:21:07 <jwh> at least, all --debug --verbose gets me is the api calls
2019-02-14 17:21:15 <jwh> which is what I'd expect for default logging, not debug
2019-02-14 17:21:27 <jwh> why is it *always* go applications that have shit debug/logging
2019-02-14 17:21:28 <jwh> lol
2019-02-14 17:23:07 <jwh> incidentally, lxcfs doesn't start anyway, cgmanager: Error mounting unified: No such file or directory
2019-02-14 17:23:21 <SpaceToast> erm... that sounds like you have broken cgroups
2019-02-14 17:23:32 <jwh> yeah
2019-02-14 17:23:35 <SpaceToast> which'd certainly explain a lot
2019-02-14 17:23:47 <jwh> this is what I was just thinking
2019-02-14 17:24:00 <jwh> none on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
2019-02-14 17:24:12 <SpaceToast> that's all you got?
2019-02-14 17:24:15 <SpaceToast> yeah you got broken cgroups
2019-02-14 17:24:24 <jwh> no, thats the unified one
2019-02-14 17:24:36 <jwh> sec I'll pb
2019-02-14 17:24:54 <jwh> http://ix.io/1B48
2019-02-14 17:25:01 <SpaceToast> you're supposed to have http://sprunge.us/GOCb2q
2019-02-14 17:25:16 <SpaceToast> I also have this in rc.conf http://sprunge.us/KegHjG
2019-02-14 17:25:20 <jwh> looks about right
2019-02-14 17:25:26 <jwh> oh hm
2019-02-14 17:25:37 <jwh> let me check rc.conf
2019-02-14 17:25:58 <jwh> hybrid appears to be the default anyway
2019-02-14 17:26:18 <SpaceToast> yeah yours appears to be hybrid
2019-02-14 17:26:36 <jwh> rc_cgroup_controllers is "" though
2019-02-14 17:26:49 <jwh> commented out, haven't touched rc.conf so whatever the default is
2019-02-14 17:27:58 <SpaceToast> not rc_cgroup_controllers, rc_controller_cgroups
2019-02-14 17:28:01 <SpaceToast> very different things
2019-02-14 17:28:05 <jwh> oh my bad
2019-02-14 17:28:12 <jwh> not confusing at all
2019-02-14 17:28:24 <jwh> #rc_controller_cgroups="YES"
2019-02-14 17:28:27 <jwh> so same, reall
2019-02-14 17:28:28 <SpaceToast> hm
2019-02-14 17:28:30 <jwh> really*
2019-02-14 17:28:46 <jwh> according to the comments the default is the same behaviour as hybrid and YEs
2019-02-14 17:28:51 <SpaceToast> actually wait, hold on
2019-02-14 17:28:54 <SpaceToast> I might have a custom lxcfs patch
2019-02-14 17:29:37 <SpaceToast> ah yeah
2019-02-14 17:29:41 <SpaceToast> remove the `depend cgproxy`
2019-02-14 17:29:44 <SpaceToast> that thing is dumb
2019-02-14 17:29:47 <jwh> still trying to figure out where its picking up the stupid open fds from
2019-02-14 17:29:59 <jwh> because it works if fixed manually
2019-02-14 17:30:02 <SpaceToast> well on my system there's a clear eventfd
2019-02-14 17:30:12 <SpaceToast> so it's using its own memory-internal fd
2019-02-14 17:30:14 <jwh> well I mean, ignoring the ones on boot
2019-02-14 17:30:17 <SpaceToast> that's getting closed by *something*
2019-02-14 17:30:20 <jwh> but lxc start
2019-02-14 17:30:31 <jwh> but maybe it really needs lxcfs?
2019-02-14 17:30:56 <SpaceToast> it does not
2019-02-14 17:31:03 <SpaceToast> as I said, I had it running perfectly well w/o lxcfs
2019-02-14 17:31:12 <SpaceToast> what lxcfs does is it makes containers "see" their limitations
2019-02-14 17:31:17 <jwh> ah
2019-02-14 17:31:19 <SpaceToast> e.g htop will show 1 cpu core if it's limited to 1 core
2019-02-14 17:31:23 <SpaceToast> w/o lxcfs it'll see all the cores
2019-02-14 17:31:29 <jwh> ok, well I mean it's one less thing for it to get upset about if its there I guess
2019-02-14 17:31:40 <SpaceToast> that shouldn't do anything with eventfd
2019-02-14 17:31:58 <jwh> well if I ignore all the other glaring problems and fix the config it generates, I'm hoping it'll be enough
2019-02-14 17:32:04 <jwh> but I can't even find it in the source
2019-02-14 17:32:15 <jwh> the abstraction is excessive
2019-02-14 17:32:49 <jwh> oh also
2019-02-14 17:32:54 <SpaceToast> are you running this on the vanilla kernel?
2019-02-14 17:32:58 <jwh> 3         3847 3856 3         root  txt       REG                0,5 32014784       8095 /memfd:liblxc (deleted)
2019-02-14 17:33:01 <jwh> 3         3847 3856 3         root  mem       REG              179,3   720728     520494 /usr/lib/liblxc.so.1.5.0
2019-02-14 17:33:04 <jwh> hm
2019-02-14 17:33:05 <jwh> yeah
2019-02-14 17:33:06 <jwh> is yours virt?
2019-02-14 17:33:08 <SpaceToast> no
2019-02-14 17:33:10 <jwh> oh o
2019-02-14 17:33:11 <jwh> ok
2019-02-14 17:35:09 <SpaceToast> you seem to be the first one to run into the whole memfd thing
2019-02-14 17:35:44 <SpaceToast> this is the closest thing I can find and I doubt it's related https://github.com/lxc/lxc/issues/1296
2019-02-14 17:35:54 <SpaceToast> might be time to submit a bug report?
2019-02-14 17:35:58 <jwh> it's entirely possible that the way ubuntu sets it up, or the environment its launched in, is what its expecting
2019-02-14 17:36:06 <jwh> but the actual fix is no so much dumbassery heh
2019-02-14 17:36:09 <jwh> not*
2019-02-14 17:36:19 <SpaceToast> but.... I have it running on fresh alpine
2019-02-14 17:36:39 <SpaceToast> that I literally upgraded and rebooted yesterday!
2019-02-14 17:36:43 <jwh> meh
2019-02-14 17:36:53 <jwh> theres something different about our installs then
2019-02-14 17:37:19 <jwh> if you don't see the same by installing and enabling lxd, then theres something very wrong
2019-02-14 17:37:24 <jwh> since they should be 100% identical
2019-02-14 17:38:03 <SpaceToast> ok, let's try this
2019-02-14 17:38:27 <jwh> I wanna know what the hell its doing with memfd and liblxc anyway
2019-02-14 17:38:41 <SpaceToast> liblxc is what actually does the containerization
2019-02-14 17:38:45 <jwh> it looks dumb whatever its doing
2019-02-14 17:38:53 <SpaceToast> lxd is a wrapper (for cgroups, storage, etc) around lxc
2019-02-14 17:38:55 <jwh> yeah but why is it mangling that with memfd
2019-02-14 17:38:57 <SpaceToast> `sha512sum $(which lxd) $(which lxc) /usr/lib/liblxc.so.1.5.0`
2019-02-14 17:39:15 <jwh> sec
2019-02-14 17:39:19 <SpaceToast> http://sprunge.us/RdobhQ
2019-02-14 17:40:20 <jwh> not a single one is the same as that
2019-02-14 17:40:22 <jwh> oh but, -r1
2019-02-14 17:40:35 <jwh> installed it after the tar dep got added
2019-02-14 17:40:43 <SpaceToast> that shouldn't change anything
2019-02-14 17:40:48 <SpaceToast> let me upgrade and reboot I guess
2019-02-14 17:41:05 <jwh> they're not reproducible builds are they?
2019-02-14 17:41:17 <SpaceToast> no, we want to have reproducible builds eventually
2019-02-14 17:41:18 <jwh> probably nonsense like timestamps
2019-02-14 17:41:22 <SpaceToast> but I don't see any reason they shouldn't be
2019-02-14 17:41:25 <SpaceToast> anyway, rebooting
2019-02-14 17:41:27 <jwh> kk
2019-02-14 17:41:34 <SpaceToast> (it'll take a bit, 48gb of ram takes a bit to post)
2019-02-14 17:41:59 <jwh> heh
2019-02-14 17:42:06 <jwh> http://ix.io/1B4f
2019-02-14 17:42:19 <jwh> thats from the vultr vm I setup to start with a clean environment
2019-02-14 17:42:41 <jwh> untainted by my hardware or install mehods
2019-02-14 17:42:44 <jwh> methods
2019-02-14 17:43:12 <SpaceToast> uh oh
2019-02-14 17:43:15 <jwh> but they match the ones on my local machines
2019-02-14 17:43:23 <jwh> sup?
2019-02-14 17:43:25 <SpaceToast> hello there!
2019-02-14 17:43:28 <SpaceToast> I can't start anything
2019-02-14 17:43:30 <SpaceToast> memfd problems :D
2019-02-14 17:43:33 <jwh> :)
2019-02-14 17:43:43 <jwh> so....
2019-02-14 17:43:48 <SpaceToast> so someone broke something
2019-02-14 17:43:49 <jwh> it was bumped a couple of days ago
2019-02-14 17:43:52 <SpaceToast> I bet it's lxc libs
2019-02-14 17:44:30 <jwh> tinkerbell:~/lxd# grep -riH memfd
2019-02-14 17:44:30 <jwh> tinkerbell:~/lxd#
2019-02-14 17:44:34 <jwh> bleh
2019-02-14 17:44:42 <jwh> everything is wrapped up in abstraction libs
2019-02-14 17:44:49 <SpaceToast> "fix CVE-2019-5736"
2019-02-14 17:44:52 <SpaceToast> hmmm
2019-02-14 17:45:04 <jwh> ah what a surprise
2019-02-14 17:45:37 <jwh> Merge pull request #5491 from brauner/2019-02-13/remove_cmdline_parsi...
2019-02-14 17:45:37 <jwh> @stgraber
2019-02-14 17:45:37 <jwh> stgraber committed 18 hours ago
2019-02-14 17:45:37 <jwh> lxd: remove /proc/self/cmdline parsing
2019-02-14 17:45:37 <jwh> @brauner
2019-02-14 17:45:38 <jwh> brauner committed 19 hours ago
2019-02-14 17:45:40 <jwh> :D
2019-02-14 17:45:40 <SpaceToast> sigh, runc fixes
2019-02-14 17:45:54 <jwh> god damn morons
2019-02-14 17:45:59 <SpaceToast> can we get that in please? :D
2019-02-14 17:46:02 <SpaceToast> I want my builder back up ;-;
2019-02-14 17:46:10 <jwh> honestly, take their computers away
2019-02-14 17:46:32 <jwh> https://github.com/lxc/lxd/commit/2149bdaf895a1145d49e7627b50e0097678de189
2019-02-14 17:46:33 <jwh> what
2019-02-14 17:46:33 <jwh> the
2019-02-14 17:46:35 <SpaceToast> oh, that "fix CVE" patch is what ADDED the memfd stuff
2019-02-14 17:46:36 <jwh> *fuck*
2019-02-14 17:46:39 <SpaceToast> lxd didn't have it originally
2019-02-14 17:47:12 <jwh> there are some horrors in these diffs
2019-02-14 17:47:54 <jwh> hm, when was that committed?
2019-02-14 17:48:00 <SpaceToast> Feb 12
2019-02-14 17:48:09 <SpaceToast> so tl;dr liblxc is broken right now
2019-02-14 17:48:28 <jwh> ok
2019-02-14 17:48:40 <jwh> I'll built it with (some) of the horribleness reverted and see
2019-02-14 17:48:42 <jwh> build*
2019-02-14 17:48:58 <SpaceToast> ok
2019-02-14 17:49:08 <SpaceToast> please do send lxc-libs apk and I'll install locally
2019-02-14 17:49:12 <jwh> although actually, with your box you might be faster :P
2019-02-14 17:49:50 <SpaceToast> my box can't build anything right now
2019-02-14 17:49:54 <jwh> oh
2019-02-14 17:49:54 <SpaceToast> because my builder is the containre
2019-02-14 17:49:56 <jwh> all in lxc?
2019-02-14 17:49:57 <SpaceToast> ... that I can't start
2019-02-14 17:49:57 <jwh> ah heh
2019-02-14 17:49:58 <SpaceToast> yeah
2019-02-14 17:50:03 <jwh> ok gimme a few
2019-02-14 17:50:14 <SpaceToast> the physical host is a minimal lxd master
2019-02-14 17:50:16 <jwh> no local checkout as I nuked them to fix lxd...
2019-02-14 17:50:30 <SpaceToast> and it turns out it wasn't lxd all along :/
2019-02-14 17:50:35 <jwh> yup
2019-02-14 17:50:43 <jwh> love wasting my time
2019-02-14 17:50:49 <SpaceToast> wonder how/if to even report this one
2019-02-14 17:51:00 <SpaceToast> and if maybe someone already has
2019-02-14 17:51:07 <SpaceToast> I'm ok with just keeping the older liblxc around for a while but erm
2019-02-14 17:51:12 <jwh> well, need to figure specifically which bit breaks it
2019-02-14 17:51:17 <SpaceToast> (it's not like I run runc, right?)
2019-02-14 17:51:20 <jwh> can maybe just patch that particular bit
2019-02-14 17:51:24 <SpaceToast> mhm
2019-02-14 17:51:28 <SpaceToast> if you could do that it'd be really helpful
2019-02-14 17:51:34 <SpaceToast> I'm kind of swamped right now :/
2019-02-14 17:51:38 <jwh> :(
2019-02-14 17:51:46 <SpaceToast> ($dayjob is moving offices and I'm the only admin, and the docs take a lot more time than you'd think)
2019-02-14 17:51:58 <jwh> same heh, but having working containers would make my life a *lot* easier
2019-02-14 17:52:01 <SpaceToast> I had to get the musl fix done because yeah, but egh
2019-02-14 17:52:33 <jwh> heh
2019-02-14 17:54:47 <jwh> alright building, lets see
2019-02-14 17:55:25 <SpaceToast> at least the report itself should be simple; "this patch/commit breaks lxd"
2019-02-14 17:55:38 <jwh> well
2019-02-14 17:55:48 <jwh> it looks like there might actually be 2 issues
2019-02-14 17:55:56 <jwh> memfd *and* the cmdline parsing thats generating garbage
2019-02-14 17:56:06 <jwh> they've reverted the latter
2019-02-14 17:56:19 <jwh> but first things first
2019-02-14 17:56:20 <SpaceToast> mhm
2019-02-14 17:56:24 <SpaceToast> let's get our containers working :)
2019-02-14 17:56:28 <jwh> yes quite
2019-02-14 17:57:21 <mpmc> jwh: That was very British, quite :p
2019-02-14 17:57:37 <jwh> oh hello
2019-02-14 17:57:38 <jwh> ltns
2019-02-14 18:05:17 <jwh> alright well its built, lemme see if its fixed
2019-02-14 18:05:27 <jwh> insane size packages
2019-02-14 18:09:36 <jwh> tinkerbell:~# lxd -dv
2019-02-14 18:09:36 <jwh> Segmentation fault
2019-02-14 18:09:38 <jwh> no then
2019-02-14 18:11:12 <SpaceToast> did you just undo clandmeter's commit?
2019-02-14 18:11:17 <SpaceToast> because I think that *should* work
2019-02-14 18:11:53 <jwh> hm
2019-02-14 18:12:34 <SpaceToast> you know, this should affect all lxd installations once the new lxc version comes out, so it should get fixed on its own later (?)
2019-02-14 18:12:51 <jwh> I was trying to fix the problem rather than downgrading, but I can certainly build that for you
2019-02-14 18:13:10 <SpaceToast> well getting things back to a working state sounds like a good idea
2019-02-14 18:13:18 <jwh> yeah
2019-02-14 18:13:20 <SpaceToast> once that's done you can do security.nesting true on a dedicated container for fixing this
2019-02-14 18:13:21 <jwh> ok 10 mins
2019-02-14 18:26:52 <jwh> hm
2019-02-14 18:45:42 <SpaceToast> clandmeter: just fyi, the patch you added to lxc on Feb 12 broke lxd in horrible ways; jwh is going to open an issue with lxd and hopefully upstream will fix everything soon - just making sure you're informed
2019-02-14 18:46:14 <jwh> wonder why ubuntu haven't noticed
2019-02-14 18:46:28 <jwh> lack of testing or it just happens to work with their environment
2019-02-14 18:46:54 <jwh> but I can't even see in the patch where it could possibly get the fds from
2019-02-14 18:46:57 <SpaceToast> jwh: I think it's because lxc hasn't had a release with the patch yet
2019-02-14 18:47:00 <SpaceToast> we added it early
2019-02-14 18:47:03 <jwh> ah
2019-02-14 18:47:32 <jwh> oh I missed the fd = heh
2019-02-14 18:48:29 <jwh> alright, I'll open an issue, let them deal with it how they wish
2019-02-14 18:53:59 <jwh> actually
2019-02-14 18:54:10 <jwh> hes committed some related stuff since, I'll see if its fixed
2019-02-14 18:55:53 <SpaceToast> :D
2019-02-14 18:56:08 <jwh> if it is I might just open an issue anyway, where is my apology D
2019-02-14 18:56:09 <jwh> :D
2019-02-14 18:56:34 <SpaceToast> well, if it is, then the answer will be "why did you get stuff from git, just wait for the release"
2019-02-14 18:56:40 <SpaceToast> (and I'd actually agree with it in most cases)
2019-02-14 18:56:50 <jwh> yeah
2019-02-14 18:56:51 <SpaceToast> people that run runc deserve it anyway :^)
2019-02-14 18:56:57 <jwh> thats why I haven't opened an issue et
2019-02-14 18:56:58 <jwh> yet*
2019-02-14 18:57:07 <jwh> and heh, yeah
2019-02-14 18:57:15 <jwh> the whole vulnerability was idiotic
2019-02-14 18:58:12 <jwh> lol, the subsequent commits revert the large majority of that patch
2019-02-14 18:59:11 <jwh> and then... the next one adds it back
2019-02-14 18:59:13 <jwh> what a mess
2019-02-14 18:59:42 <jwh> https://github.com/lxc/lxc/commit/cee55b59cd0f7446bae25d02bcd23805ce43aaa4
2019-02-14 19:00:01 <jwh> gg on testing
2019-02-14 19:00:19 <SpaceToast> enjoy ^^
2019-02-14 19:00:26 <SpaceToast> at least you have a very easy way to test it, right?
2019-02-14 19:00:38 <jwh> build, reboot, see if it starts :d
2019-02-14 19:00:56 <SpaceToast> oh you don't need to reboot
2019-02-14 19:01:15 <SpaceToast> just apk add new_lxc-libs.apk, rc-service lxd restart, and try (re)starting a container
2019-02-14 19:01:18 <SpaceToast> all you need to do :D
2019-02-14 19:01:54 <jwh> well I also wanna check what the state is on boot
2019-02-14 19:02:05 <jwh> see if its hosed before even trying to start somerthing
2019-02-14 19:02:09 <jwh> something*
2019-02-14 19:02:59 <SpaceToast> I'd say that you can skip the boot test until it works when just restarting
2019-02-14 19:03:13 <SpaceToast> I suspect it's a simple superset
2019-02-14 19:03:47 <jwh> yeah probably
2019-02-14 19:03:59 <jwh> well, I'll see if this is better
2019-02-14 19:13:26 <danieli> ncopa: it doesn't look like the latest commits are in it
2019-02-14 19:13:36 <danieli> sorry, I'm out travelling, and it's one hell of a shitty trip
2019-02-14 19:20:25 <jwh> SpaceToast: still here?
2019-02-14 19:20:26 <jwh> tinkerbell:~# lxc start good-panther
2019-02-14 19:20:26 <jwh> tinkerbell:~#
2019-02-14 19:20:30 <SpaceToast> sort of
2019-02-14 19:20:31 <jwh> but... can you test?
2019-02-14 19:20:35 <SpaceToast> sure, PM details
2019-02-14 19:20:46 <jwh> I'll just upload r3, tryagain directory
2019-02-14 19:21:52 <jwh> k, there
2019-02-14 19:22:12 <SpaceToast> jwh: what exactly is -r3? (what did you do)
2019-02-14 19:22:34 <jwh> readded the patch clandmeter added, cherry picked subsequent fixes
2019-02-14 19:22:53 <jwh> it would be *much* easier if every *fix* that guy committed didn't need another 4 commits to undo all the mess it makes
2019-02-14 19:22:55 <SpaceToast> it runs, let me reboot
2019-02-14 19:22:56 <jwh> lol
2019-02-14 19:23:16 <jwh> but I narrowed it down to 4
2019-02-14 19:23:24 <jwh> well, 3 and a half patches I guess
2019-02-14 19:23:38 <SpaceToast> reboot gonna take a while, ofc
2019-02-14 19:23:39 <jwh> I left them as-is though, rather than rolling them into one
2019-02-14 19:23:41 <jwh> yeah
2019-02-14 19:24:44 <SpaceToast> seems to run fine
2019-02-14 19:24:51 <SpaceToast> so all patches should be removed next release, right?
2019-02-14 19:25:02 <jwh> yeah, unless they make it worse again heh
2019-02-14 19:25:16 <SpaceToast> good news though
2019-02-14 19:25:16 <jwh> but it just looks like he didn't test on musl before committing for the most part
2019-02-14 19:25:24 <SpaceToast> they don't use musl
2019-02-14 19:25:27 <SpaceToast> they work for canonical
2019-02-14 19:25:27 <jwh> yea
2019-02-14 19:25:38 <SpaceToast> I should keep this -r3 and it'll PROBABLY get auto-replaced next release?
2019-02-14 19:25:42 <jwh> in their defence they do appear to be trying to fix it to work on non-glibc
2019-02-14 19:25:52 <jwh> yeah
2019-02-14 19:25:56 <SpaceToast> well yes, when I complained they fixed the musl thing :)
2019-02-14 19:26:01 <SpaceToast> they just don't officially test
2019-02-14 19:26:07 <SpaceToast> but this patch seems like it'd affect everything
2019-02-14 19:26:23 <jwh> I'll throw the package up somewhere in a bit, so if someone wants to tidy it up and commit (hint hint)
2019-02-14 19:26:40 <jwh> actually...
2019-02-14 19:27:00 <SpaceToast> I can throw the lxc-libs package alone on my builder if you'd like
2019-02-14 19:27:04 <SpaceToast> well on my storage
2019-02-14 19:27:06 <SpaceToast> whatever
2019-02-14 19:27:16 <jwh> http://ix.io/1B4I
2019-02-14 19:27:21 <jwh> diff against master
2019-02-14 19:27:29 <SpaceToast> wew
2019-02-14 19:27:54 <jwh> no notes or comments, just hashes to lookup sorry
2019-02-14 19:32:03 <jwh> have a million things to do and I need a nap before the race is on :(
2019-02-14 19:32:44 <SpaceToast> yeah
2019-02-14 19:32:48 <SpaceToast> have a good nap!
2019-02-14 19:33:09 <jwh> well not just yet... it's not on until 2am or something my time
2019-02-14 19:35:34 <jwh> at least I can return to what I started hours ago :D
2019-02-14 20:49:02 <jwh> screw it, gonna open a pr, it's probably not up to standard but it's in testing anyway :D
2019-02-14 21:01:27 <clandmeter> hi
2019-02-14 21:01:37 <_ikke_> o/
2019-02-14 21:01:51 <clandmeter> so i broke lxc?
2019-02-14 21:02:19 <_ikke_> did you?
2019-02-14 21:02:43 <clandmeter> i think thats the summary of the above
2019-02-14 21:05:34 <jwh> ubuntu broke lxc
2019-02-14 21:05:48 <jwh> the runc fix broke it
2019-02-14 21:06:16 <clandmeter> yeah, it seemed nasty enough to patch it in.
2019-02-14 21:06:35 <clandmeter> but seems with some consequence
2019-02-14 21:06:39 <jwh> yeah
2019-02-14 21:06:47 <clandmeter> so you have a fix?
2019-02-14 21:06:59 <jwh> well, I gathered the patches required to fix it, theres a diff against master here, http://ix.io/1B4I
2019-02-14 21:07:18 <jwh> it's a bit horrible, but it will at least work until the next release comes with the fixes in
2019-02-14 21:13:10 <clandmeter> if you need to apply something ping me
2019-02-14 21:14:34 <jwh> well, that will apply to master as-is and work fine
2019-02-14 21:14:48 <jwh> I can open a PR instead
2019-02-14 21:15:17 <clandmeter> yes or git format pathc is also ok with some notes whats going on.
2019-02-14 21:15:33 <clandmeter> whatever you prefer
2019-02-14 21:15:38 <jwh> okies
2019-02-14 21:15:46 <clandmeter> and thanks for getting to the bottom of this
2019-02-14 21:15:51 <jwh> np
2019-02-14 21:50:59 <jwh> clandmeter: https://github.com/alpinelinux/aports/pull/6337
2019-02-14 21:51:45 <fcolista> omg...
2019-02-14 21:52:16 <fcolista> thx jwh...
2019-02-14 21:52:48 <fcolista> I've still to understand why *buntu mess-up the container world
2019-02-14 21:54:33 <clandmeter> jwh, nice! ill try to check it tomorrow. wife is waiting.
2019-02-14 21:58:20 <jwh> okies
2019-02-14 23:03:28 <jwh> fcolista: SpaceToast helped too
2019-02-14 23:03:31 <jwh> :D
2019-02-14 23:03:53 <SpaceToast> fcolista: on the other hand, they did create both lxc and lxd
2019-02-14 23:04:24 <SpaceToast> imagine being stuck with just docker and runc :)
2019-02-14 23:04:59 <jwh> he
2019-02-14 23:05:00 <jwh> heh
2019-02-14 23:10:52 <SpaceToast> does anyone know why our dhcpcd has `persistent` enabled by default?
2019-02-14 23:10:58 <SpaceToast> it causes... "funny" ipv6 failures
2019-02-14 23:11:21 <jwh> I installed that everywhere today actually so I had working v6...
2019-02-14 23:11:24 <jwh> not seen anything yert
2019-02-14 23:11:26 <jwh> yet*
2019-02-14 23:11:32 <SpaceToast> jwh: one day, you will see
2019-02-14 23:11:34 <SpaceToast> alternatively
2019-02-14 23:11:37 <SpaceToast> just disable that option
2019-02-14 23:11:39 <SpaceToast> before it's too late
2019-02-14 23:11:52 <jwh> honestly the v6 support is so bad I don't have any expectations heh
2019-02-14 23:12:00 <jwh> (still can't install from v6 either)
2019-02-14 23:12:42 <SpaceToast> basically, if dhcpcd (basically required for proper DHCPv6) has persistent on, it will fail to send its hostname in response to a DHCP6 RA
2019-02-14 23:12:49 <SpaceToast> because it'll assume that it's not reconfiguring
2019-02-14 23:12:53 <jwh> but short of using something useful instead of udhcpc[6] by default, there isn't much to be done
2019-02-14 23:12:54 <SpaceToast> (even if the suppression isn't there)
2019-02-14 23:13:06 <jwh> hm
2019-02-14 23:13:09 <jwh> let me see
2019-02-14 23:13:18 <SpaceToast> so at some point you keep getting the address, but not the lease
2019-02-14 23:13:21 <SpaceToast> which breaks internal DDNS
2019-02-14 23:13:26 <SpaceToast> (among other side effects)
2019-02-14 23:13:39 <jwh> do you have the M bit set?
2019-02-14 23:13:45 <SpaceToast> if you're using dnsmasq, just make sure you have `dhcp-client-update` in dnsmasq, and *no* `persistent` in dhcpcd.conf
2019-02-14 23:14:06 <SpaceToast> I have no idea :)
2019-02-14 23:14:09 <jwh> I have a very specific setup (that also means android can't do v6)
2019-02-14 23:14:11 <SpaceToast> my RA is dnsmasq
2019-02-14 23:14:14 <jwh> because android is terrible
2019-02-14 23:14:18 <SpaceToast> yeah android still doesn't have DHCPv6
2019-02-14 23:14:26 <SpaceToast> oh, yeah I have M
2019-02-14 23:14:34 <jwh> I set the M bit in ra, so they will only get addresses from dhcpv6
2019-02-14 23:14:48 <jwh> ah ok
2019-02-14 23:15:00 <SpaceToast> I have very specific desires for my internal networks :)
2019-02-14 23:15:03 <SpaceToast> slaac is no good
2019-02-14 23:15:08 <jwh> tbh I've been rebooting stuff with lxc and whatnot today so nothing probably been up long enough
2019-02-14 23:15:29 <SpaceToast> (I want two simple things - ipv4 and ipv6, where ipv6 is globally reachable; and to be able to ping any system by its hostname *inside* of the network)
2019-02-14 23:15:31 <jwh> yeah, I need a useful addressing policy and working dns resolution, so "standard" v6 setups are no good
2019-02-14 23:15:37 <jwh> and I don't want no temporary addresses eithr
2019-02-14 23:15:40 <SpaceToast> (that latter requires DHCPv6)
2019-02-14 23:15:54 <jwh> let me check my config
2019-02-14 23:17:19 <SpaceToast> do you know if there's an nmap script (or similar) to inspect RA bits?
2019-02-14 23:17:20 <jwh> ah no I don't have client update, just the dhcp-range, dhcp-range=set=eth1,::1,::ff,constructor:eth1
2019-02-14 23:17:34 <jwh> hm
2019-02-14 23:17:46 <jwh> I think I saw one, but tcpdump should probably tell you
2019-02-14 23:20:27 <jwh> yeah, hop limit 64, Flags [managed, other stateful],
2019-02-14 23:20:36 <jwh> icmp6 and 'ip6[40] = 134' as your expression
2019-02-14 23:28:52 <jwh> I like that go now runs out of memory (apparently, no oom) when building traefik
2019-02-14 23:31:06 <jwh> 2G of ram just to start linking, nice, not ridiculous at all
2019-02-14 23:31:48 <jwh> make that 3
2019-02-14 23:36:18 <SpaceToast> jwh: found one, rdisc6 helps :D
2019-02-14 23:36:34 <jwh> ah
2019-02-14 23:36:38 <jwh> good to know
2019-02-14 23:36:51 <SpaceToast> so I have stateful address conf, stateful other conf, and on-link bits
2019-02-14 23:37:02 <SpaceToast> but yeah it's a dhcpcd issue, nothing less, nothing more
2019-02-14 23:37:24 <jwh> how long do you see before it happens, just at lease expiry?
2019-02-14 23:37:36 <SpaceToast> at least lease expiry, which is min 2h
2019-02-14 23:37:37 <jwh> ugh that made no sense
2019-02-14 23:37:42 <jwh> ah ok
2019-02-14 23:37:42 <SpaceToast> I only noticed after like a week
2019-02-14 23:38:16 <jwh> guess I'll have to wait for that fun
2019-02-14 23:38:54 <SpaceToast> is it really that hard to change 2 options?
2019-02-14 23:39:17 <jwh> I wanna figure out why it breaks
2019-02-14 23:39:35 <SpaceToast> I'm pretty sure it just assumes it's already configured
2019-02-14 23:39:40 <SpaceToast> (since that's what the flag is for, after all)
2019-02-14 23:39:46 <jwh> hm
2019-02-14 23:44:50 <jwh> updated https://github.com/alpinelinux/aports/pull/6230 too
2019-02-14 23:52:29 <SpaceToast> btw, jwh, you got debian ifupdown running, right?
2019-02-14 23:53:07 <jwh> no, didn't bother once I realised dhcpcd works
2019-02-14 23:53:25 <jwh> or rather, once I realised busybox will exec it
2019-02-14 23:53:52 <SpaceToast> ah, ok
2019-02-14 23:53:59 <SpaceToast> I tried adding it (while debugging the dhcpv6 problem)
2019-02-14 23:54:02 <SpaceToast> it... seems rather broken
2019-02-14 23:56:20 <jwh> yeah, honestly I've always hated the ifupdown stuff so
2019-02-14 23:56:43 <SpaceToast> I don't mind the idea, but the execution seems to be consistently lacking
2019-02-14 23:56:52 <SpaceToast> ... but I'm not crazy enough to dive into writing my own (yet?)
2019-02-14 23:57:14 <jwh> well theres plenty that can be moulded, I had netifd running, but no config yet
2019-02-14 23:58:13 <SpaceToast> I'm thinking the issue is everyone focuses on "describing" things
2019-02-14 23:58:18 <SpaceToast> whereas I'd be down with shortcuts for executing
2019-02-15 00:00:32 <jwh> heh
2019-02-15 00:00:50 <jwh> well, you need a sensible way of expressing configs for anything other than very basic configs
2019-02-15 00:10:30 <jwh> at least I got my prs all done before the race o/
2019-02-15 09:06:11 <mps> anyone have idea does Alpine need to have compiler-rt
2019-02-15 09:15:50 <deveh1> hey, upgraded my alpine server, and elixir and erlang no longer work
2019-02-15 09:15:52 <deveh1> ~  iex dlsym: Resource temporarily unavailable [1]    2310 abort      iex
2019-02-15 09:16:05 <deveh1> any ideas?
2019-02-15 14:01:47 <jwh> guyyyys, #6337 :P
2019-02-15 14:01:54 <jwh> PR that is
2019-02-15 15:22:12 <jwh> hm, think I broke my kernele...
2019-02-15 15:22:17 <jwh> depmod: can't open 'modules.builtin': No such file or directory
2019-02-15 15:22:21 <jwh> depmod: WARNING: could not open /lib/modules/4.19.21-1-vanilla/modules.order: No such file or directory
2019-02-15 15:22:24 <jwh> it is not amused
2019-02-15 15:22:31 <jwh> unless upgrading broke it, hm
2019-02-15 15:22:54 <jwh> huh, yeah, weird
2019-02-15 15:23:07 <ncopa> PR6337
2019-02-15 15:23:33 <jwh> ummm
2019-02-15 15:23:36 <jwh> pulll?
2019-02-15 15:23:43 <ncopa> exactly
2019-02-15 15:23:50 <ncopa> pr6337
2019-02-15 15:24:29 <ncopa> PR#6337
2019-02-15 15:24:36 <jwh> lol
2019-02-15 15:25:51 <jwh> bleh, I'm still missing something to get this bluetooth working
2019-02-15 15:26:15 <jwh> its SDIO I believe, but I'm missing an mmc device
2019-02-15 15:26:33 <jwh> I can't find the magic kernel symbol that covers it
2019-02-15 15:26:59 <ncopa> do you have other distro or kernel that detects it?
2019-02-15 15:27:15 <jwh> yeah, arch does - so I'm comparing possibly related symbols
2019-02-15 15:27:21 <ncopa> then you could save the list of loaded modules
2019-02-15 15:27:23 <jwh> but alas
2019-02-15 15:27:31 <jwh> well they build a lot in, so that may not show up
2019-02-15 15:27:38 <ncopa> and compare with alpines loaded modules
2019-02-15 15:27:52 <jwh> theres some HCIUART stuff missing, but it's not those
2019-02-15 15:28:12 <ncopa> its probably a kernel module
2019-02-15 15:28:15 <jwh> unless... it needs to be built in and not a module and thats why its not working
2019-02-15 15:28:27 <jwh> as pinctrl appears to be required, module on alpine but builtin on arch
2019-02-15 15:29:03 <jwh> more tinkering, my work is never done :D
2019-02-15 15:29:17 <ncopa> are there any modules on arch that are not loaded with alpine?
2019-02-15 15:29:31 <jwh> just checking
2019-02-15 15:30:38 <jwh> nothing that looks obviously related, however... this is missing from kernel messages:
2019-02-15 15:30:45 <jwh> [    3.781344] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
2019-02-15 15:30:55 <jwh> which appears to be where the wifi+bluetooth is
2019-02-15 15:31:04 <jwh> or at least the bluetooth, i think the wifi works
2019-02-15 15:31:17 <ncopa> i dont think thats blutetooth
2019-02-15 15:31:21 <jwh> but that could also be the card reader... the bios switches them around at random
2019-02-15 15:31:25 <ncopa> mmc is memory card?
2019-02-15 15:31:33 <jwh> yeah but you can interface over SDHCI
2019-02-15 15:31:38 <jwh> not restricted to cards
2019-02-15 15:31:57 <jwh> Im not sure how to get the topology from a running system
2019-02-15 15:32:16 <ncopa> maybe via /sys/ ?
2019-02-15 15:33:01 <jwh> yeah its in here somewhere heh
2019-02-15 15:33:57 <ncopa> look in /sys/class/bluetooth/hci0/device/
2019-02-15 15:34:41 <jwh> oh its h5
2019-02-15 15:34:43 <jwh> haaaaang on
2019-02-15 15:35:06 <mps> ncopa: have you few minutes? you are maintainer of compiler-rt, for what is used it on Alpine
2019-02-15 15:35:22 <jwh> lrwxrwxrwx 1 root root    0 Feb 15 15:34 driver -> ../../../../../bus/serial/drivers/hci_uart_h5
2019-02-15 15:35:25 <jwh> lrwxrwxrwx 1 root root    0 Feb 15 15:34 firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/80860F0A:00/OBDA8723:00
2019-02-15 15:35:40 <ncopa> hci_uart_h5
2019-02-15 15:35:44 <ncopa> is the kernel module you need
2019-02-15 15:35:59 <ncopa> jwh> theres some HCIUART stuff missing, but it's not those
2019-02-15 15:36:03 <jwh> yeah I need to find the symbol, theres nothing matching h5 in config.gz for arch
2019-02-15 15:36:12 <jwh> Iirc this is vendor specific
2019-02-15 15:36:22 <ncopa> brb
2019-02-15 15:37:06 <jwh> aha, think I found the missing one
2019-02-15 15:37:26 <jwh> CONFIG_BT_HCIUART_RTL=y
2019-02-15 15:37:35 <jwh> completely overlooked it
2019-02-15 15:38:06 <jwh> oh wait no, I got that one
2019-02-15 15:44:52 <fcolista> ERROR: unsatisfiable constraints:
2019-02-15 15:44:52 <fcolista>   ossp-uuid-1.6.2-r0:
2019-02-15 15:44:52 <fcolista>     conflicts: util-linux-dev-2.33-r0[pc:uuid=1.6.2]
2019-02-15 15:44:52 <fcolista>     satisfies: .makedepends-guacamole-server-0[ossp-uuid] fontconfig-dev-2.13.1-r0[pc:uuid]
2019-02-15 15:44:52 <fcolista>   util-linux-dev-2.33-r0:
2019-02-15 15:44:52 <fcolista>     conflicts: ossp-uuid-1.6.2-r0[pc:uuid=2.33.0]
2019-02-15 15:44:54 <fcolista>     satisfies: glib-dev-2.58.1-r2[util-linux-dev] fontconfig-dev-2.13.1-r0[pc:uuid]
2019-02-15 15:45:47 <jwh> oh fun
2019-02-15 15:45:56 <fcolista> need to bump pkgrel
2019-02-15 16:35:10 <jwh> muahahahaha!
2019-02-15 16:35:11 <jwh> got it
2019-02-15 16:36:01 <jwh> well, kinda
2019-02-15 16:36:47 <jwh> fixes the card reader so I'll send that
2019-02-15 16:52:19 <mps> is it possible to have conditionally files in src in APKBUILD? i.e. instead of a file name to put variable
2019-02-15 16:52:38 <jwh> iirc yes
2019-02-15 16:53:15 <mps> jwh: do you know of package where I can look example
2019-02-15 16:54:03 <jwh> hm
2019-02-15 16:54:20 <p4Wv1qn095FW> APKBUILDs are shell scripts
2019-02-15 16:54:31 <p4Wv1qn095FW> you can evaluate conditions, and based on those set or change variables.
2019-02-15 16:54:34 <mps> p4Wv1qn095FW: I know
2019-02-15 16:54:40 <jwh> I think most use variables for package files,, like....
2019-02-15 16:54:44 <jwh> source="$pkgname-$pkgver.tar.gz::https://github.com/containous/traefik/archive/v$pkgver.tar.gz
2019-02-15 16:54:54 <mps> but will be checksum calculated properly
2019-02-15 16:55:20 <jwh> should be expanded, so I guess
2019-02-15 16:55:22 <jwh> try it and see
2019-02-15 16:56:08 <p4Wv1qn095FW> yeah, for checksums you should have the file in the sources variable. and then in the prepare/build/package function you can leave them out if you want...
2019-02-15 16:56:10 <mps> that one I know and use it, I'm trying to include patch defined in variable
2019-02-15 16:57:58 <mps> hmm, source="abc.tar.gz", and then source="$source\nxxxx.patch"
2019-02-15 17:05:19 <mps> ah, community/ghc have this (and some other packages, even linux-vanilla). thanks for hints and help. everyday learn something new about Alpine
2019-02-15 17:23:45 <jwh> hm
2019-02-15 17:24:15 <jwh> wonder why this is bool not tristate, and if it could be tristate
2019-02-15 17:26:38 <mps> jwh: then it will not be bool, at least in binary numeric system. in trinary maybe bool could have tristate
2019-02-15 17:38:19 <jwh> well
2019-02-15 17:38:22 <jwh> n/y/m
2019-02-15 17:38:55 <mps> this is tristate, not Boolean
2019-02-15 17:40:16 <mps> this looks like from kernel or busybox and similar configs, where 'm' means 'module'
2019-02-15 17:40:21 <jwh> yes
2019-02-15 17:40:33 <jwh> its currently bool (y/n), I need to see if it can be y/n/m
2019-02-15 17:41:05 <mps> would you tell about package you are talking
2019-02-15 17:41:34 <mps> about what package*
2019-02-15 17:41:36 <jwh> kernel symbol, CONFIG_PINCTRL_BAYTRAIL
2019-02-15 17:42:02 <mps> ah, some drivers cannot be built as module
2019-02-15 17:42:26 <jwh> the others are tristate, so either its an oversight or it does something specific that rules it out being a module
2019-02-15 17:43:06 <mps> no, it is ok, simply it is not written as a module
2019-02-15 17:43:36 <jwh> wonder if I could just get away with adding module declarations
2019-02-15 17:44:09 <mps> I suspect that is possible. did you looked at it's source
2019-02-15 17:44:27 <jwh> yeah
2019-02-15 17:44:36 <jwh> there are no declarations, gonna try now
2019-02-15 17:45:18 <mps> kernel modules need some initialization 'boilerplate' to be built as module
2019-02-15 17:45:34 <jwh> yeah
2019-02-15 17:46:52 <mps> I didn't wrote module for about two decades, so forgot what is needed in init
2019-02-15 17:47:51 <jwh> a lot of messing about :D
2019-02-15 17:48:55 <jwh> am I being blind
2019-02-15 17:49:01 <mps> it is not to complicated, imo, but you need to understand how to convert it, and could be fine brain gymnastic at the end
2019-02-15 17:49:28 <jwh> can't work out where .config is moved to
2019-02-15 17:49:41 <mps> s/not to/not too/
2019-02-15 17:49:41 <alpine-meetbot> mps meant to say: it is not too complicated, imo, but you need to understand how to convert it, and could be fine brain gymnastic at the end
2019-02-15 17:50:48 <jwh> well, even if its simple I'm not sure its worth carryin a patch, and I'm not versed with submitting anything upstream
2019-02-15 17:57:46 <mps> in what section it is in kernel config
2019-02-15 17:58:03 <jwh> no idea in menuconfig, but its gpio -> pinctrl
2019-02-15 17:58:14 <jwh> under intel, drivers/pinctrl/intel
2019-02-15 17:58:37 <jwh> https://github.com/torvalds/linux/tree/master/drivers/pinctrl/intel
2019-02-15 17:59:28 <mps> it is for x86 only in config?
2019-02-15 17:59:35 <jwh> yeah
2019-02-15 17:59:48 <jwh> baytrail is an x86 soc
2019-02-15 18:01:28 <mps> if you enable it (set 'y') it should be included in it's 'super' driver
2019-02-15 18:01:40 <jwh> yeah
2019-02-15 18:01:51 <jwh> all the others can be built as a module though, sooooo
2019-02-15 18:03:55 <mps> I don't have now and x86 kernel build environment, so couldn't check
2019-02-15 18:04:10 <mps> s/and/an/
2019-02-15 18:04:10 <alpine-meetbot> mps meant to say: I don't have now an x86 kernel build environment, so couldn't check
2019-02-15 18:04:47 <jwh> well, I have the hardware thats why I'm checking :D
2019-02-15 18:13:46 <mps> if the pinctrl driver cannot be built as module then when you select CONFIG_PINCTRL_BAYTRAIL=y in will be in the kernel
2019-02-15 18:14:13 <jwh> yes
2019-02-15 18:14:16 <mps> so, if the driver maintainers think that is right solution I don't see problem
2019-02-15 18:14:37 <jwh> thats why I'm checking if it works as a module, perhaps someone can prod upstream
2019-02-15 18:14:38 <mps> build it as they made it
2019-02-15 18:14:52 <jwh> since its a bit silly to build it in when the platforms it applies to is very very small
2019-02-15 18:15:44 <jwh> it's on my list anyway :D
2019-02-15 18:16:38 <mps> well, some could be built as module and some not. If you don't want to rewrite it then build it as 'monolith' (included in kernel)
2019-02-15 18:19:18 <jwh> well I guess its pretty small and everyone else builds it in, why not
2019-02-15 18:22:07 <jwh> annoyingly the mmc driver doesn't actually complain, it just stays silent without that
2019-02-15 18:22:53 <jwh> fixing it was on my list of things to do, but I was actually trying to fix bluetooth :D
2019-02-15 20:03:48 <jwh> man, I really need a go expert to help me with this
2019-02-15 21:32:09 <user__> hey guys. i've built a custom image for rpi but since i do not have a monitor with hdmi i want to use ssh. i included openssh-server apk in the image and placed the name in /etc/apk/world. still i cannot access the server as if the configuration did not work (i'm using the default one). if the configuration is to blame here, what steps should i follow to change it? i assume "Listen 0.0.0.0" is all it takes.
2019-02-15 21:35:30 <user__> oh i also forgot to mention, that "rc_add sshd boot" is also in my genapkovl-* file.
2019-02-16 05:04:22 <ddevault> mpv is broken in edge due to ffmpeg ABI breakage
2019-02-16 05:04:24 <ddevault> rebuild is needed
2019-02-16 05:08:10 <ddevault> might also mention that I would like to see it rebuilt for both x86_64 and aarch64, though I'm sure eventually it'd be rebuilt for everyhting
2019-02-16 05:08:13 <ddevault> everything, even
2019-02-16 09:50:47 <nmeum> ddevault: fixed, thanks!
2019-02-16 16:53:17 <ddevault> nmeum: np
2019-02-16 16:53:26 <ddevault> I just realized that mpv on alpine still doesn't have wayland support, though
2019-02-16 16:53:30 <ddevault> I sent that patch like a year ago -_-
2019-02-16 21:08:23 <kr0k01> Hi all
2019-02-16 21:10:47 <kr0k01> I have a problem with mariabackup since version 10.3.12. On backup (mariabackup --backup --target-dir=/foo/bar) I get "Segmentation fault (core dumped)"
2019-02-16 21:11:31 <kr0k01> When I'm using the mariabackup binary from version 10.3.11 (and mariadb server 10.3.12), backup is working fine.
2019-02-16 21:12:14 <kr0k01> Does anyone use mariabackup and can confirm this?
2019-02-17 06:42:45 <jwh> bleeeh, can't convince this armv7 to boot
2019-02-17 07:30:14 <_ikke_> jwh: try to be more convincing :p
2019-02-17 07:30:41 <jwh> lol
2019-02-17 07:30:55 <jwh> I gave up, pitfa without any console or video
2019-02-17 07:31:17 <jwh> need some prebuilt images or at least tarballs that contain a working / (a la alarm)
2019-02-17 13:34:47 <_ikke_> Is it normal for packages to have a dependency on ca-certificates directly?
2019-02-17 13:50:31 <jwh> god damn it, what the hell is missing from my kernel config
2019-02-17 13:50:48 <jwh> gonna suck if I have to comb through every possible symbol
2019-02-17 14:04:29 <jwh> [Feb 17 14:04:19] NOTICE[4909]: loader.c:1498 load_modules: 292 modules will be loaded.
2019-02-17 14:04:32 <jwh> Segmentation fault
2019-02-17 14:04:33 <jwh> hm
2019-02-17 14:04:37 <jwh> well thats good
2019-02-17 14:33:42 <hatramatra_> \part
2019-02-17 14:35:45 <clandmeter> _ikke_: yes
2019-02-17 14:36:49 <_ikke_> clandmeter: alright
2019-02-17 14:37:24 <_ikke_> Do we mind binary files (png) in aports? I do see a few of them existing already
2019-02-17 14:38:17 <_ikke_> https://github.com/alpinelinux/aports/pull/5177/files#diff-df4071786a21dd95a6d7b90f4b7ee5e3
2019-02-17 17:12:35 <z3ntu> ncopa: I don't think the `iptables` package should have a file in `/usr/etc/ethertypes	` , maybe you should fix that :)
2019-02-17 17:12:53 <z3ntu> `--sysconfdir=/etc`
2019-02-17 17:17:43 <_ikke_> z3ntu: feel free to submit a patch
2019-02-17 17:28:10 <z3ntu> _ikke__ my experience with patches have been months of waiting, and this should be a trivial change for a maintainer to do
2019-02-17 17:30:48 <SpaceToast> _ikke_: I'd imagine the png files aren't from the original source (aka the submitter isn't the one that made them), so I'd personally rather they be in the sources list, right?
2019-02-17 17:31:00 <SpaceToast> (or extracted from the tarball, or what have you)
2019-02-17 17:31:13 <SpaceToast> we don't really want to be distributing potentially copyrighted content, after all
2019-02-17 17:31:21 <SpaceToast> and it's nicer to the git repo :)
2019-02-17 18:04:39 <_ikke_> SpaceToast: not sure what you suggest
2019-02-17 18:04:59 <SpaceToast> the submitter got that PNG from somewhere
2019-02-17 18:05:06 <SpaceToast> they didn't make it themselves
2019-02-17 18:05:16 <SpaceToast> source="https://wherever.they.got.it"
2019-02-17 18:05:34 <SpaceToast> it might even be in the release tarball, for all we know
2019-02-17 18:14:07 <_ikke_> It's not in the release tarball
2019-02-17 18:14:25 <SpaceToast> but it definitely isn't an original creation by the submitter.
2019-02-17 18:14:30 <_ikke_> I would not expect so, no
2019-02-17 18:14:32 <SpaceToast> meaning they got it *somewhere*
2019-02-17 18:14:44 <SpaceToast> and thus the apkbuild can get it from the same somewhere
2019-02-17 18:15:03 <SpaceToast> likely with fewer potential issues :)
2019-02-17 18:16:18 <_ikke_> We would still distribute the file if we would include it in the .apk file, so it doesn't make a lot of difference regarding copyriht
2019-02-17 18:16:22 <_ikke_> copyright
2019-02-17 18:16:34 <_ikke_> But I will ask the submitter
2019-02-17 18:16:57 <SpaceToast> I'm thinking of various bindist instances like with firefox, where they allow distributing certain things as long as they're from the "original source"
2019-02-17 18:17:00 <SpaceToast> but not otherwise
2019-02-17 18:17:56 <_ikke_> ok
2019-02-17 18:18:32 <SpaceToast> either way, we should make it clear to contributors that copyrighted content shouldn't be in; I'll try and remember that for when I get there re: docs
2019-02-17 18:18:44 <SpaceToast> but in the scenario it's not copyrighted, I'd still rather fetch things that are fetch-able
2019-02-17 18:21:04 <_ikke_> yes, I agree
2019-02-17 18:27:33 <jwh> I give up
2019-02-17 18:27:50 <jwh> whatever is missing from the alpine kernel config I can't find
2019-02-17 18:29:16 <jwh> config its given never makes it into the actual build tree either, sigh
2019-02-17 18:35:49 <jwh> don't have any more time to waste on it, especially as its fragile anyway due to no systemd
2019-02-17 18:48:27 <TBB> well that's a new one, fragility due to no systemd :)
2019-02-17 18:54:54 <jwh> not really, it's getting progressively worse
2019-02-18 02:56:11 <KH405> Hi all, could somebody explain the difference between the version in : https://alpinelinux.org/downloads/.
2019-02-18 02:56:28 <KH405> I know there is a small difference but I wanted to know more
2019-02-18 02:56:33 <SpaceToast> is the little text under the version names not sufficient?
2019-02-18 04:30:04 <KH405> Not really, I wanted to know more :S
2019-02-18 04:30:24 <KH405> Is it just what is package with the base ISO different ?
2019-02-18 04:30:43 <SpaceToast> mostly, yeah :)
2019-02-18 04:30:53 <SpaceToast> the virt one has a virt kernel (as it basically says)
2019-02-18 04:30:58 <SpaceToast> and the xen one has a xen kernel
2019-02-18 04:31:08 <SpaceToast> and the arch-specific ones are arch-specific
2019-02-18 04:33:25 <KH405> What do you mean by arch specific ?
2019-02-18 04:34:01 <TBB> cpu architecture specific - x86, x86_64, ARM etc
2019-02-18 04:34:42 <SpaceToast> the raspberry pi one won't run on x86 ;)
2019-02-18 04:35:09 <KH405> Good, for my use case, I'm looking specificaly between standard and extended, the extended descriptions reads: Runs from RAM. Is this specific to that version ?
2019-02-18 04:39:35 <SpaceToast> no, it means that extended isos will usually be installed in ramdisk mode
2019-02-18 04:39:48 <SpaceToast> all alpine isos run from ram by default
2019-02-18 04:40:41 <KH405> Ok, so the difference between these twos are just installed packages if I understand correctly
2019-02-18 05:27:21 <_ikke_> KH405: THe difference is in the amount of packages that are present on the iso
2019-02-18 05:27:31 <_ikke_> KH405: if you have an internet connection, the standard image suffices
2019-02-18 05:28:49 <KH405> _ikke_: Thank you!
2019-02-18 08:03:15 <xsteadfastx> could some look over this: https://github.com/alpinelinux/aports/pull/5814 the travis test fails but i have no idea why
2019-02-18 08:08:00 <clandmeter> https://travis-ci.org/alpinelinux/aports/builds/493270231#L658
2019-02-18 08:09:26 <clandmeter> xsteadfastx: https://travis-ci.org/alpinelinux/aports/builds/493270231#L521
2019-02-18 08:12:36 <xsteadfastx> clandmeter: i know but here on my box i dont have a checksum error
2019-02-18 08:12:52 <clandmeter> delete the local tarball and regen
2019-02-18 08:14:17 <xsteadfastx> ok
2019-02-18 08:14:26 <xsteadfastx> but with this error i have no idea what is going on
2019-02-18 08:14:30 <xsteadfastx> or what i could do about it
2019-02-18 08:16:24 <xsteadfastx> ok i think i know what the problem is... it needs a newer version of libunpp which is also in the PR
2019-02-18 08:22:06 <xsteadfastx> thats what i checked right now on my box
2019-02-18 13:52:16 <p4Wv1qn095FW> ncopa: i cannot build kicad due to a bug in glm: https://github.com/g-truc/glm/issues/832 - it can be fixed by reverting this patch: https://github.com/g-truc/glm/commit/68c7e7e50b934cd265251a0660096f1415647bbb - it is known upstream, but unfixed so far: https://bugs.launchpad.net/kicad/+bug/1804030
2019-02-18 13:52:51 <p4Wv1qn095FW> would you update glm please?
2019-02-18 13:53:25 <p4Wv1qn095FW> shall i open a bug on b.a.o for this?
2019-02-18 14:01:36 <AinNero> yes
2019-02-18 14:01:47 <mps> p4Wv1qn095FW: interesting, did you tried to patch glm and build it locally
2019-02-18 14:02:48 <mps> I intended to package kicad, but if you already did it you saved my time :)
2019-02-18 14:06:58 <p4Wv1qn095FW> yes, you should check our aports-ugly repo: https://github.com/aports-ugly/aports/tree/master/ugly
2019-02-18 14:16:11 <mps> looks like your repo is related to electronics and radio
2019-02-18 15:15:36 <p4Wv1qn095FW> mostly yes. but also other stuff
2019-02-18 15:19:17 <p4Wv1qn095FW> mps and yes, kicad works since a long time in alpine, i've been using it with great joy
2019-02-18 15:19:48 <mps> are you HAM (radio operator)? I built svxlink on Alpine for use on radio repetear
2019-02-18 15:39:21 <p4Wv1qn095FW> no, i am a freebander
2019-02-18 15:41:14 <mps> ok, anyway we share interest to electronics :)
2019-02-18 15:42:42 <mps> btw, thank you for kicad APKBUILD
2019-02-18 15:44:17 <p4Wv1qn095FW> i'm into reversing/tracking/intercepting digital transmissions, ham voice/cw stuff is super boring at best, and super annoying most of the time... ;)
2019-02-18 15:45:26 <mps> todays ham is a digital at it's good part
2019-02-18 15:46:29 <p4Wv1qn095FW> i once held a licence for gsm/umts though ;)
2019-02-18 15:47:30 <mps> and no, i don't want say that your interest is not good, it is really interesting but I don't have time to dive into it
2019-02-18 15:48:23 <p4Wv1qn095FW> yeah, reversing a transmission is quite a lot of time. a lot
2019-02-18 15:49:14 <mps> reverse engineering anything requires time and strong will
2019-02-18 22:44:46 <jwh> bah, all 3 of my PRs are still open :((
2019-02-18 23:02:55 <mattleibow> Hey there folks!
2019-02-18 23:06:39 <danieli> heya
2019-02-19 03:35:36 <SpaceToast> danieli: just in case you haven't heard (you were interested in getting D into alpine as well, from what I recall) - D made it into GCC9
2019-02-19 03:35:44 <SpaceToast> so it may be easier to gte it in later :)
2019-02-19 08:19:07 <fcolista> uff
2019-02-19 08:19:08 <fcolista> https://github.com/greenbone/gvm-libs/releases
2019-02-19 08:19:27 <fcolista> they go from v9.0.0 to v1.0.0 rather than v.10.0.0
2019-02-19 08:19:30 <fcolista> why!?!?!?!!?
2019-02-19 08:20:14 <clandmeter> haha
2019-02-19 08:20:29 <clandmeter> because they have no idea how versioning works
2019-02-19 08:25:32 <fcolista> I think this might create issue with apk when it comes to upgrade it..
2019-02-19 08:26:15 <clandmeter> it will
2019-02-19 08:26:30 <fcolista> heh...
2019-02-19 08:26:32 <fcolista> uff
2019-02-19 08:26:52 <clandmeter> probably create an issue for it on their github
2019-02-19 08:26:58 <fcolista> +1
2019-02-19 08:27:19 <jlanda> they changed the name too
2019-02-19 08:27:20 <clandmeter> but i don't think they will change versioning just for sanity
2019-02-19 08:27:35 <jlanda> OpenVAS v9, next major -> GVM 1.0
2019-02-19 08:27:55 <jlanda> its werid, but at least its not OpenVAS v1 after OpenVAS v9 :D
2019-02-19 08:28:12 <jlanda> s/werid/weird
2019-02-19 08:36:03 <fcolista> opened an issue on GH..let's see how they will reply
2019-02-19 08:36:50 <fcolista> openvas-libs was already renamed as gvm-libs with 9.0.3
2019-02-19 08:37:07 <fcolista> so  does not make any sense to set gvm-libs v1.0.0
2019-02-19 08:37:18 <fcolista> it's a downgrade for any package manager..
2019-02-19 08:54:46 <fcolista> hehe I bet that this versioning thunghy gonna become a flame in GH ..
2019-02-19 08:54:54 <fcolista> *thinghy
2019-02-19 08:55:06 <fcolista> looks that openvas devels are quite sensitive..
2019-02-19 11:01:51 <ScrumpyJack> blimey
2019-02-19 11:23:12 <_ikke_> conclusion, we only care what we do, not what others do, so it doesn't matter how we do our versions
2019-02-19 11:24:16 <_ikke_> oink 357 -> 364 PRs open on GH
2019-02-19 11:28:14 <AinNero> im somewhat dissatisfied that there is alot of useless stuff packaged
2019-02-19 11:28:20 <AinNero> like pip packages?
2019-02-19 11:30:00 <_ikke_> You mean projects from pip packaged?
2019-02-19 11:31:06 <AinNero> or just parts of the setup.py ecosystem
2019-02-19 11:32:06 <AinNero> almost every community/py-* is just an adaptor to convert setup.py pkg to apk
2019-02-19 11:33:27 <_ikke_> isn't every c project just an adopter of (c|auto)make to apk?
2019-02-19 11:33:56 <AinNero> but c is compiled, not just repacked
2019-02-19 11:34:08 <AinNero> python is a interpreter language
2019-02-19 11:34:13 <AinNero> *interpreted
2019-02-19 11:34:23 <_ikke_> But wouldn't it make sense to have a consistent package format?
2019-02-19 11:34:46 <_ikke_> If I install project foo, I should not have to run another package manager to get the rest of the deps
2019-02-19 11:34:50 <AinNero> that would be nice, but python already has the virtualenv/pip stuff
2019-02-19 11:35:06 <_ikke_> right, node has npm, ruby has bundler
2019-02-19 11:35:28 <AinNero> we dont re-package nom and bundles, either, right?
2019-02-19 11:35:34 <AinNero> *mpm
2019-02-19 11:35:42 <_ikke_> lol
2019-02-19 11:36:02 <_ikke_> We do repackage a lot of ruby gems as well
2019-02-19 11:36:57 <_ikke_> And we do see the extra work that is creating
2019-02-19 11:49:11 <clandmeter> it makes sense to package them when they have arch depended code.
2019-02-19 11:50:39 <clandmeter> _ikke_: im thinking of significantly lower the stale limit for the stale bot.
2019-02-19 11:50:59 <clandmeter> somehow the modification time gets reset after some time.
2019-02-19 11:51:12 <clandmeter> so setting it very high like we do now is useless.
2019-02-19 11:51:20 <_ikke_> clandmeter: hmm, ok, wonder what is triggering that
2019-02-19 11:51:33 <_ikke_> I do notice a lot of PRs have been updated by a force-push of algitbot
2019-02-19 11:51:46 <clandmeter> i did some testing and if  you go back few months the  results turn up none
2019-02-19 11:52:37 <clandmeter> yes but i also checked a few that have nothing in history but still is modified somehow
2019-02-19 12:05:55 <jlanda> oh, I love the gvm-libs drama, we don't care about you, but please, talk to us before changing your packaging name the next time, wtf
2019-02-19 12:10:23 <fcolista> jlanda, are you a openvas dev?
2019-02-19 12:10:41 <fcolista> *an
2019-02-19 12:10:42 <jlanda> not at all, I read you about it earlier today :D
2019-02-19 12:11:02 <fcolista> ah ok
2019-02-19 12:11:24 <fcolista> I've not intended to be rude on that post
2019-02-19 12:11:40 <jlanda> I just don't understand their last reply. On one hand they're saying that they don't care about third party packaging but at the same time they are asking you to talk to them before changing your package name
2019-02-19 12:12:41 <jlanda> I don't see a rude tone on your post, it looks more like a too defensive position on their side
2019-02-19 12:12:45 <fcolista> jlanda, yes. But I'm not going to reply, since it's useless and I don't want to argue. IMHO they have managed this renaming/reversionig very wrong.
2019-02-19 12:12:55 <jlanda> and a confusing repo management
2019-02-19 12:12:59 <jlanda> yeah, I agree
2019-02-19 12:13:12 <jlanda> gvm-libs is a new lib? then make a new repo, their free
2019-02-19 12:13:33 <jlanda> keep the openva-libs repo as openva-libs, set a deprecating note in the readme and point to gvm-libs brand new repo
2019-02-19 12:13:41 <jlanda> and there, use the versioning as you want
2019-02-19 12:13:47 <jlanda> that would be much better option
2019-02-19 12:13:54 <fcolista> but according with other distro, alpine was the only one haveing renamed openvas-libraries to gvm-libs. So I was too "quick" in doing that (even if i did it on dec 2017)
2019-02-19 12:14:14 <fcolista> now the page is no longer available, but they mentioned this "rename"
2019-02-19 12:15:15 <_ikke_> fcolista: waybackmachine?
2019-02-19 12:15:31 <_ikke_> Not sure if it matters to have the page though :)
2019-02-19 12:15:40 <fcolista> the fact is that the versioning they have choose has break (also) the consistency between package name and version
2019-02-19 12:16:27 <fcolista> _ikke_, I don't want to be picky. Their position is clear, I've done what I think was right, and renamed gvm-libs to openvas-libraries.
2019-02-19 12:16:31 <fcolista> I think that it's enough.
2019-02-19 12:16:55 <fcolista> We want to be kind with other devs, my point was not to "win" a topic.
2019-02-19 12:17:04 <fcolista> or an argument
2019-02-19 12:17:19 <fcolista> it was only intended to highlight what I believe was an error.
2019-02-19 12:17:53 <fcolista> was AND is
2019-02-19 12:18:37 <ScrumpyJack> AinNero: packages are great at filling air gaps, you only have one repo to maintine locally
2019-02-19 12:18:40 <_ikke_> :-)
2019-02-19 12:23:48 <ScrumpyJack> maintain, even
2019-02-19 15:34:05 <mps> anyone experienced issue with libxml2 upgrade from 2.9.8 to 2.9.9
2019-02-19 16:02:36 <fcolista> mps what kind of issue?
2019-02-19 16:14:13 <_ikke_> Hmm, in wonder what happened here: https://github.com/alpinelinux/aports/pull/6334/files
2019-02-19 16:15:14 <mps> crystal fails to pass tests with 2.9.9 downgraded libxml2 to 2.9.8 and it worked
2019-02-19 16:58:55 <ncopa> AinNero: I think it may or may not make sense to re-package language package managers, like pip, and ruby gems, depending on the application
2019-02-19 16:59:44 <ncopa> it is convenient for the end user to only need to deal with one package manager
2019-02-19 17:00:08 <ncopa> if user wants install docker-compose, then its convenient to only do: apk add docker-compose
2019-02-19 17:00:34 <ncopa> instead of: apk add python3 pip && pip install docker-compose
2019-02-19 17:01:16 <jwh> you also end up with a broken system by using pip as well as packages
2019-02-19 17:01:19 <SpaceToast> there's also the question of various package managers having varying issues
2019-02-19 17:01:20 <jwh> either use packages, or venv
2019-02-19 17:01:23 <SpaceToast> yeah, like with pip
2019-02-19 17:01:32 <SpaceToast> and venv-based installs break on python updates
2019-02-19 17:01:34 <jwh> pip is probably the best example
2019-02-19 17:01:39 <ncopa> use may just want a single application or tool, and dont care what language it is implemented in
2019-02-19 17:01:44 <SpaceToast> similar story with cargo - you can't update all installed cargo packages, you have to go one by one
2019-02-19 17:02:13 <SpaceToast> if the language-specific package manager is properly (ideally) implemented, I wouldn't have any issues, but I'm not really aware of any like that
2019-02-19 17:02:14 <jwh> venv does isolate you from a lot of those, since you can at least contain the exact python version and packages
2019-02-19 17:02:31 <jwh> I mean it's dumb, but what you gonna do
2019-02-19 17:02:36 <ncopa> in that case i think it make sense to re-package as apk, including the deps
2019-02-19 17:03:01 <jwh> the problem though, is there are 1000s of libraries
2019-02-19 17:03:19 <ncopa> in other cases you want a framwork, for your own application. lets say someone uses python flask to make a web app
2019-02-19 17:03:35 <ncopa> in that case, it does not really make sense to apk add py-* deps
2019-02-19 17:03:40 <jwh> really people deploying projects should be using venvs from whatever source control they use
2019-02-19 17:03:42 <ncopa> and its probably better to go with pip
2019-02-19 17:03:56 <jwh> same with other languages, global packages are a nightmare
2019-02-19 17:04:24 <ncopa> so i think it does not make sense to package all 10000 pips as apk
2019-02-19 17:04:31 <jwh> yes
2019-02-19 17:04:47 <ncopa> now with python and perl its relatively easy to repack
2019-02-19 17:04:54 <_ikke_> Why is this an issue with all these languages, but not with C projects?
2019-02-19 17:05:03 <_ikke_> Is it because they are more mature and change less?
2019-02-19 17:05:07 <ncopa> but for ruby, its a nightmare
2019-02-19 17:05:08 <jwh> it is with C libraries, just not as bad
2019-02-19 17:05:30 <jwh> most try and keep some sort of compat and people tend to keep up with them
2019-02-19 17:05:31 <ncopa> other languages has introduced their own package management
2019-02-19 17:05:35 <jwh> but openssl is a good example
2019-02-19 17:05:36 <SpaceToast> because C is less vulnerable to the lisp curse
2019-02-19 17:05:44 <ncopa> standard package manager that is
2019-02-19 17:05:45 <SpaceToast> and because C doesn't have a "real" package manager
2019-02-19 17:05:46 <_ikke_> lisp curse>
2019-02-19 17:05:46 <jwh> curses, etc
2019-02-19 17:05:58 <_ikke_> ?
2019-02-19 17:06:01 <ncopa> C is old, and does not have any standard package manager
2019-02-19 17:06:11 <ncopa> same with c++
2019-02-19 17:06:29 <SpaceToast> _ikke_: http://winestockwebdesign.com/Essays/Lisp_Curse.html
2019-02-19 17:07:12 <SpaceToast> there are less libraries written in C because writing things in C is harder; and as a result the things that do end up getting finished also tend to be more complete
2019-02-19 17:07:26 <ncopa> i think there have been some efforts for C and C++ package managers, but i dont think they ever catched on
2019-02-19 17:07:55 <jwh> it's not really worth it for C, there aren't breaking changes with every update in most libraries
2019-02-19 17:08:01 <jwh> not like these other languages
2019-02-19 17:08:14 <ncopa> package managers like rpm, deb etc have sort of solved the need for C package manager
2019-02-19 17:11:23 <SpaceToast> the difference is in who makes the packages, actually
2019-02-19 17:11:37 <SpaceToast> with pip, gem, etc, the developer makes and uploads/registers/whatever their package
2019-02-19 17:11:42 <TBB> I once tried packaging something for Alpine that used C components that sort of came from a package repository
2019-02-19 17:11:43 <SpaceToast> in rpm/deb/etc it's the maintainers
2019-02-19 17:12:00 <SpaceToast> so I can see why C/C++ package managers keep trying to spring up, but it just doesn't work out
2019-02-19 17:12:01 <TBB> it was the most horrific packaging effort I've ever had to go through
2019-02-19 20:56:31 <clandmeter> I just enabled drone CI on aports pull requests. https://cloud.drone.io/alpinelinux/aports
2019-02-19 20:56:47 <_ikke_> \o/
2019-02-19 20:56:47 <clandmeter> if something is broken let me know.
2019-02-19 20:57:34 <_ikke_> At least this one allows you to copy things from the build log :-)
2019-02-19 20:58:04 <_ikke_> travis collapses the current section when you try to do that
2019-02-19 20:58:33 <clandmeter> there is some logic in the build script for travis regarding collapsing. could be a feature.
2019-02-19 20:58:56 <clandmeter> nice thing about drone is that it now supports 5 arches
2019-02-19 20:59:00 <_ikke_> yes, and the collapsing is not an issue, but you don't expect it to happen when you try to select text
2019-02-19 20:59:07 <_ikke_> yes, that's very nice
2019-02-19 20:59:09 <clandmeter> mps also your favorite arches ;-)
2019-02-19 20:59:17 <clandmeter> and it wont time out on larger projects
2019-02-19 20:59:26 <clandmeter> so we can build kernels
2019-02-19 20:59:33 <_ikke_> s390 and ppc64le missing, kind of expected
2019-02-19 20:59:59 <_ikke_> s/s390/s390x/
2019-02-19 21:00:18 <clandmeter> ppc maybe in the future, but that depends on packet.net
2019-02-19 21:01:14 <clandmeter> you can follow drone activity here: https://cloud.drone.io/alpinelinux/aports
2019-02-19 21:02:50 <clandmeter> andypost[m]: did you add that label autoamtically?
2019-02-19 21:05:11 <andypost[m]> clandmeter: no, checking release notes and build now
2019-02-19 21:05:30 <clandmeter> andypost[m]: did you see new CI?
2019-02-19 21:05:46 <andypost[m]> not yet
2019-02-19 21:07:25 <andypost[m]> oh, nice!
2019-02-19 21:07:39 <andypost[m]> https://cloud.drone.io/alpinelinux/aports/1
2019-02-19 21:07:48 <clandmeter> yep
2019-02-19 21:08:10 <andypost[m]> btw s390x broken in chroot(
2019-02-19 21:08:37 <andypost[m]> curl any https fails with core dump
2019-02-19 21:08:59 <clandmeter> you have a s390x container?
2019-02-19 21:09:28 <andypost[m]> no, I'm using chroot and only x86-64 in docker
2019-02-19 21:09:51 <_ikke_> how is that supposed to work?
2019-02-19 21:10:48 <andypost[m]> _ikke_: this one https://github.com/alpinelinux/alpine-chroot-install
2019-02-19 21:11:16 <_ikke_> ah, with qemu-user and binfmt
2019-02-19 21:11:19 <_ikke_> ok
2019-02-19 21:12:41 <clandmeter> https://github.com/alpinelinux/alpine-chroot-install/commit/4ee1b1878a0f29160fdc4d5f8b3aee75c5576caa
2019-02-19 21:13:10 <clandmeter> andypost[m]: ^
2019-02-19 21:14:35 <andypost[m]> so it's not my local! cos I'm trying to resetup it now(
2019-02-19 21:24:53 <mps> clandmeter: you are talking about drone.io? I have seen your messages on infra when you started to work in it
2019-02-19 21:25:06 <mps> but didn't had time to look at it
2019-02-19 21:25:20 <_ikke_> mps: yes
2019-02-19 21:25:50 <clandmeter> mps: its only active when you create pr's. i dont think you use github.
2019-02-19 21:26:04 <mps> I have it in my 'head' to look when find some time
2019-02-19 21:26:07 <clandmeter> cloud.drone.io is github only
2019-02-19 21:26:43 <mps> ah, only github users can 'use' these drones
2019-02-19 21:27:18 <mps> btw, what is with idea to move to gitlab
2019-02-19 21:27:42 <_ikke_> There are no concrete plans
2019-02-19 21:28:12 <_ikke_> If we would move to gitlab, we want to self-host it, but it's quite complex to get running on alpine
2019-02-19 21:28:36 <clandmeter> the idea is still and idea and is still interesting.
2019-02-19 21:28:52 <clandmeter> we have somebody who is looking into it.
2019-02-19 21:29:06 <mps> why to self-host it? alpine doesn't self-host github too
2019-02-19 21:29:33 <clandmeter> thats one of the reasons we dont like github
2019-02-19 21:29:52 <mps> eh, good, I agree here
2019-02-19 21:29:59 <_ikke_> there is not a lot of reason to switch from hosted git to hosted gitlab
2019-02-19 21:30:02 <_ikke_> hosted github*
2019-02-19 21:30:06 <clandmeter> i mean not prefer. i do like github
2019-02-19 21:30:28 <mps> I remember that someone offered help with preparing gitlab, but forgot who was that
2019-02-19 21:33:00 <mps> and, for Alpine to self-host gitlab is the only solution to run debian/ubuntu (or something similar) under lxc, imho
2019-02-19 21:34:10 <mps> andypost[m]: you mentioned segfault with curl, is that with http2 or any version
2019-02-19 21:37:49 <andypost[m]> mps: gonna check, I did check only for packages from github, but any curl https;// fails, finsihing setup manually
2019-02-19 21:38:01 <_ikke_> mps: We can use the existing gitlab docker image
2019-02-19 21:38:11 <_ikke_> which runs on ubuntu iirc
2019-02-19 21:38:51 <mps> andypost[m]: I posted a patch to curl a week ago, iirc, which fixes segfaults in some urls
2019-02-19 21:39:55 <mps> _ikke_: that is also good option, but anyway not waste a time trying to make gitlab to run natively on Alpine
2019-02-19 21:40:39 <andypost[m]> mps, basically https://gist.github.com/andypost/650ab920ea0dac3296c40fb4b7ce1662
2019-02-19 21:41:46 <mps> what dmesg says after these fails
2019-02-19 21:42:38 <mps> and what is your curl apk version
2019-02-19 21:44:05 <andypost[m]> _ikke_: I'm using gitlab for 2 years as official docker image in 20ppl team without issues, it works well on 16GB ram machine and 8 cores x86-64
2019-02-19 21:44:13 <mps> clandmeter: your neighbors were here today :)
2019-02-19 21:45:16 <clandmeter> mps: nice
2019-02-19 21:45:20 <clandmeter> and did they agree?
2019-02-19 21:45:58 <mps> yes, of course, they will be at home in few days :)
2019-02-19 21:46:59 <mps> I will inform you when everything is on the place
2019-02-19 21:47:05 <clandmeter> :)
2019-02-19 21:47:21 <clandmeter> i will make room in my cellar :D
2019-02-19 21:47:56 <mps> huh, don't make a big one ;)
2019-02-19 21:48:18 <andypost[m]> mps: added as comment to gist
2019-02-19 21:49:29 <andypost[m]> mps, btw I got few reports about php7-curl which fails to fetch in parallel mode
2019-02-19 21:50:02 <mps> that is ubuntu kernel?
2019-02-19 21:50:06 <andypost[m]> did not dig yet, but that started last week
2019-02-19 21:51:39 <andypost[m]> mps 4.15.0-46-generic
2019-02-19 21:52:16 <mps> so, your build machine works in container on ubuntu?
2019-02-19 21:52:23 <andypost[m]> but used to try the same on deb with older kernel
2019-02-19 21:52:37 <andypost[m]> right now yes
2019-02-19 21:53:54 <mps> andypost[m]: SpaceToast had a similar issue and after upgrading curl to 7.64.0-r1 everything worked
2019-02-19 21:54:28 <mps> what version is curl on your build box
2019-02-19 21:55:47 <andypost[m]> 7.58
2019-02-19 21:57:23 <andypost[m]> I thought it because pure connection (I'm in mountains now) but gonna try on scaleway
2019-02-19 21:57:57 <mps> ah, that version is about year ago, iirc
2019-02-19 21:58:17 <mps> that is not 3.9 or edge?
2019-02-19 21:59:40 <andypost[m]> finsihed setup s390x - it possible to  install after I did change apk-repos to http
2019-02-19 22:00:45 <mps> then your problem is/was not related to the http2 issue in curl
2019-02-19 22:01:08 <mps> sorry for wasting your time
2019-02-19 22:01:24 <andypost[m]> mps: added one more comment to gist
2019-02-19 22:01:51 <andypost[m]> surely issue in curl
2019-02-19 22:05:15 <mps> now i see it is curl 7.64.0 but couldn't see pkgrel version. is it  7.64.0-r0 or  7.64.0-r1
2019-02-19 22:05:58 <andypost[m]> exactly curl-7.64.0-r1
2019-02-19 22:06:32 <andypost[m]> at least it's fresh install and apk info tell this
2019-02-19 22:06:37 <mps> could you give me some url which causes segfault
2019-02-19 22:06:54 <andypost[m]> goo.gl as I showed
2019-02-19 22:09:39 <mps> ah, didn't saw it. it works on aarch64, armv7 and x86_64 without problem
2019-02-19 22:12:52 <andypost[m]> looks I need to bump php7 to check it cos I can reproduce issue with php7-curl on multi connection
2019-02-19 22:24:24 <mps> hmm, nothing about that issue on their site, maybe this is s390x specific
2019-02-19 22:29:39 <andypost[m]> looks yep, cos other arches works fine
2019-02-19 22:49:53 <andypost[m]> clandmeter: is there limits for drone runs?
2019-02-19 23:24:43 <andypost[m]> so drone no longer works( https://github.com/alpinelinux/aports/pull/6415
2019-02-20 07:37:47 <clandmeter> Morning
2019-02-20 07:37:58 <clandmeter> I'm looking on GitHub
2019-02-20 07:38:17 <fcolista> clandmeter, morning. Looking @GH me too. Lot of PR.
2019-02-20 07:38:32 <clandmeter> Seems webhooks return http 500
2019-02-20 07:39:03 <clandmeter> I will check with drone ppl
2019-02-20 08:57:13 <ncopa> morning
2019-02-20 08:57:35 <ncopa> maybe we could run our own drone instance on our ppc64le machine?
2019-02-20 08:57:37 <ncopa> and s390x
2019-02-20 08:57:53 <clandmeter> if we can combine it with lxc
2019-02-20 08:58:37 <ncopa> <@_ikke_> there is not a lot of reason to switch from hosted git to hosted gitlab
2019-02-20 08:58:55 <ncopa> there are a couple of reasons why hosted gitlab is better than hosted github
2019-02-20 08:59:49 <ncopa> one is that i believe that we can import issues from our current redmine into gitlab and keep the issue id (which means we can do simple redirects from existing URLs to new issue)
2019-02-20 08:59:59 <ncopa> that i dont think we can with github
2019-02-20 09:00:59 <ncopa> second reason is that with gitlab we have a better exit strategy. With gitlab we *can* move from hosted to self hosted if we for some reason would need/want that in future
2019-02-20 09:01:18 <ncopa> there is no easy way to export or move out from github
2019-02-20 09:01:28 <ncopa> so the lock-in with github is stronger
2019-02-20 09:01:50 <_ikke_> Right
2019-02-20 09:02:47 <ncopa> so i think hosted gitlab puts us in better position than hosted github
2019-02-20 09:03:33 <clandmeter> i dotn think it will be easy to migrate from hosted to local gitlab.
2019-02-20 09:03:37 <ncopa> that said, im not 100% sure that we can keep the issue id from redmine if we go for hosted gitlab
2019-02-20 09:03:39 <_ikke_> Are you able to export from hosted gitlab to self-hosted gitlab?
2019-02-20 09:03:57 <ncopa> i assume it is possible, but i dont know
2019-02-20 09:04:00 <clandmeter> i have not seen any tool to do that.
2019-02-20 09:04:15 <ncopa> i assume it to be easier than move out from github
2019-02-20 09:04:40 <ncopa> i think it would be better if we could run our own gitlab instance
2019-02-20 09:04:47 <_ikke_> One thing that's easier is that people are already used to the interface
2019-02-20 09:04:58 <ncopa> with github?
2019-02-20 09:05:08 <_ikke_> no, if we would have hosted gitlab and move to self-hosted
2019-02-20 09:05:19 <ncopa> right
2019-02-20 09:06:30 <ncopa> i think mort will look into create a gitlab docker image based on alpine
2019-02-20 09:08:30 <clandmeter> i wonder if drone actually runs on those 2 arches.
2019-02-20 09:09:26 <clandmeter> but it would be nice for our devs to be able to testrun on it.
2019-02-20 09:16:01 <jlanda> I'm deploying a couple of gitlab ce instances with https://github.com/sameersbn/docker-gitlab . It's based on ubuntu, but it could be a good place to copy some code from ;)
2019-02-20 09:16:49 <jlanda> _ikke_: bot gitlab ce and cloud gitlab can import projects/repos from another gitlab instance
2019-02-20 09:16:57 <jlanda> s/bot/both
2019-02-20 09:16:57 <alpine-meetbot> jlanda meant to say: _ikke_: both gitlab ce and cloud gitlab can import projects/repos from another gitlab instance
2019-02-20 09:18:21 <clandmeter> jlanda: so you can mirgrate cloud to local installation?
2019-02-20 09:18:21 <_ikke_> jlanda: ok, good to know
2019-02-20 09:18:45 <jlanda> clandmeter: I haven't tryed it by myself, but in theory, yes
2019-02-20 09:20:04 <jlanda> you need to activate the gitlab.com oauth on your gitlab-ce instance during the migration
2019-02-20 09:20:34 <jlanda> it has an option to import from github too, but dunnot what the hell does with issues/PRs etc since github is not friendly to export those things
2019-02-20 09:21:09 <clandmeter> i guess using github api you can come a long way.
2019-02-20 09:21:28 <jlanda> and can need a long time to import :D
2019-02-20 09:22:06 <jlanda> https://docs.gitlab.com/ee/user/project/import/gitlab_com.html
2019-02-20 09:22:28 <jlanda> ar, that's the ee version doc. s/ee/ce ;)
2019-02-20 09:27:25 <tmhoang> ncopa, clandmeter: what is drone :D I must have missed that.
2019-02-20 09:27:47 <ncopa> https://drone.io/
2019-02-20 09:27:50 <clandmeter> https://cloud.drone.io/
2019-02-20 09:28:26 <tmhoang> interesting
2019-02-20 09:28:44 <clandmeter> tmhoang: i added it to aports on github for pr's
2019-02-20 09:29:08 <tmhoang> also, please let me know how/when you want to discuss the s390x tod clocksource (RTC thing) situation.
2019-02-20 09:34:46 <clandmeter> i think they officially only support arm32/64 and amd64
2019-02-20 10:21:17 <ScrumpyJack> is there a move to gitlab? self-hosted? with CI/CD?
2019-02-20 10:25:17 <_ikke_> ScrumpyJack: There is a wish
2019-02-20 11:28:42 <ncopa> i think i figured out why chromium crashes
2019-02-20 11:31:27 <clandmeter> i wonder if the issues we are having with drone are related to how we use github.
2019-02-20 11:33:13 <_ikke_> In what regard?
2019-02-20 11:33:35 <clandmeter> its a mirror
2019-02-20 11:33:53 <ncopa> how do you plug drone to github?
2019-02-20 11:34:02 <ncopa> as a webhook?
2019-02-20 11:34:04 <clandmeter> yes
2019-02-20 11:34:12 <clandmeter> its automatic config
2019-02-20 11:34:36 <clandmeter> if you go to webhooks and open the drone one you can see a history of postings
2019-02-20 11:35:02 <clandmeter> the message that returns from drone is "not found"
2019-02-20 11:35:36 <clandmeter> i wonder if the PR and a mirror would run at the same time it could conflict.
2019-02-20 11:36:12 <clandmeter> if i rerun  the webhook afterwards, it just works.
2019-02-20 11:36:51 <clandmeter> i asked the author to take a look at the backend of some debug info.
2019-02-20 11:37:08 <clandmeter> s/of/for
2019-02-20 11:37:08 <alpine-meetbot> clandmeter meant to say: i asked the author to take a look at the backend for some debug info.
2019-02-20 11:46:10 <clandmeter> hmm
2019-02-20 11:46:22 <clandmeter> does travis not run testsuites?
2019-02-20 11:48:07 <ncopa> i thought it does
2019-02-20 11:48:10 <ncopa> but i dont know
2019-02-20 11:49:56 <clandmeter> looks like something is off
2019-02-20 11:50:04 <clandmeter> seems to build much more  than just the PR
2019-02-20 11:50:43 <_ikke_> example?
2019-02-20 12:14:37 <duncaen> chromium 72 breaks again with pthread stacksize issues, I think I'm going to remove the default pthread stacksize patch from voidlinux and use LDFLAGS to set a higher stack size
2019-02-20 12:23:47 <clandmeter> i disabled drone for now. the changed file calculation is broken.
2019-02-20 12:24:14 <_ikke_> sad
2019-02-20 12:26:46 <clandmeter> the not found seems drone cannot find our drone yml
2019-02-20 12:27:02 <clandmeter> i wonder if its related to ppl who push with older master where its not included yet.
2019-02-20 12:45:40 <ncopa> duncaen: are you sure its pthread stack size?
2019-02-20 12:46:08 <ncopa> i am looking at chromium 72 as we speak
2019-02-20 12:46:20 <ncopa> and i have issues with crashes
2019-02-20 12:46:25 <duncaen> it worked with chelf
2019-02-20 12:46:31 <duncaen> hm I don't get crashes
2019-02-20 12:46:54 <duncaen> gmail just hangs with seccomp sandbox enabled
2019-02-20 12:47:26 <ncopa> same here
2019-02-20 12:47:38 <duncaen> http://sprunge.us/TAEwvx
2019-02-20 12:47:41 <ncopa> i think it crashes in sandbox
2019-02-20 12:47:52 <duncaen> attached strace to the renderer processes noticed these error patterns
2019-02-20 12:48:01 <duncaen> yea
2019-02-20 12:48:34 <ncopa> i once had a crash with --no-sandbox
2019-02-20 12:48:59 <ncopa> and I have had problems since chromium 71
2019-02-20 12:49:02 <ncopa> https://bugs.alpinelinux.org/issues/9808
2019-02-20 12:49:24 <ncopa> good idea to try setting stack size via elf
2019-02-20 12:50:08 <duncaen> 2097152chelf -s 2097152 /usr/lib/chromium/chromium
2019-02-20 12:50:19 <duncaen> https://github.com/Gottox/chelf
2019-02-20 12:50:30 <duncaen> this works here
2019-02-20 12:51:18 <duncaen> hm but not consistently
2019-02-20 12:52:27 <ncopa> right
2019-02-20 12:52:44 <ncopa> the hangs/crashes is not consistent
2019-02-20 12:52:48 <ncopa> so i think its a race of some sort
2019-02-20 12:53:08 <ncopa> it tends to get better if i let it run for a while
2019-02-20 12:53:49 <duncaen> ok time to abort the build...
2019-02-20 12:54:05 <duncaen> the first thing I suspected was something about service workers
2019-02-20 12:54:47 <duncaen> but they are now starting after increasing the stack
2019-02-20 12:55:04 <ncopa> my impression is that it happens by random
2019-02-20 12:55:30 <ncopa> if it was stack size i would expect it to also happen with --no-sandbox
2019-02-20 12:55:57 <ncopa> duncaen: what version of chromium did you test?
2019-02-20 12:56:18 <ncopa> i saw that .109 has a fix for a race
2019-02-20 12:56:40 <duncaen> .109
2019-02-20 12:57:22 <ncopa> for me it sounds like it could be: https://chromium.googlesource.com/chromium/src/+/67cf2319fd490c620faedb606830752ef695450d
2019-02-20 12:57:44 <ncopa> but if it still happens with .109....
2019-02-20 12:57:51 <ncopa> then its something else :-(
2019-02-20 12:58:19 <duncaen> sounds related
2019-02-20 12:58:52 <duncaen> but checked again the version in the running chromium, its .109
2019-02-20 12:59:17 <ncopa> another thing i suspect is the -fno-delete-null-pointer-check
2019-02-20 12:59:31 <ncopa> that it gets disabled somehow
2019-02-20 12:59:39 <ncopa> do you build with gcc or clang?
2019-02-20 12:59:50 <duncaen> clang again afaik
2019-02-20 12:59:58 <ncopa> i build with gcc
2019-02-20 13:01:45 <ncopa> im also trying to fix build on armv7
2019-02-20 13:01:46 <duncaen> now I can't get it to hang anymore with strace attached to the renderers
2019-02-20 13:02:08 <ncopa> but it happens if you dont have strace attached?
2019-02-20 13:02:24 <ncopa> it smells like a timing issue, a race of some sort
2019-02-20 13:02:58 <duncaen> yes it has to be some race, sometimes its then on the next restart its broken again
2019-02-20 13:03:44 <duncaen> would be really nice to have debugging symbols
2019-02-20 13:04:28 <ncopa> things that almost always triggers it for me: slack, login to google, google spreadsheet
2019-02-20 13:04:57 <ncopa> build chromium with debugging enabled will make it *huge*
2019-02-20 13:05:15 <ncopa> how do you attach strace to the renderers?
2019-02-20 13:05:40 <duncaen> chromium --allow-sandbox-debugging --renderer-cmd-prefix='strace -o strace -ff'
2019-02-20 13:05:49 <duncaen> in a directory where it can dump all the logs
2019-02-20 13:06:35 <ncopa> like /tmp
2019-02-20 13:06:37 <ncopa> nice
2019-02-20 13:06:40 <duncaen> if i attach gdb later to a hung tab its just in a futex syscall with 60 frames
2019-02-20 13:06:44 <duncaen> #0  0x00007f1b0f312c9e in __syscall_cp_c (nr=202, u=93998587999740, v=128, w=-2147483632, x=0, y=0, z=0)
2019-02-20 13:07:24 <duncaen> hm tmp is a good idea, I just did it in a normal directory, maybe this way it could trigger it again
2019-02-20 13:07:45 <ncopa> i once got a crash dump: https://bugs.alpinelinux.org/issues/9808#note-10
2019-02-20 13:08:25 <ncopa> but i dont know if its same issue
2019-02-20 13:09:43 <duncaen> i don't think i can get it to hang with --single-process or --disable-seccomp-sandbox
2019-02-20 13:10:22 <ncopa> it happened after a while
2019-02-20 13:10:35 <ncopa> relatively long time
2019-02-20 13:10:54 <ncopa> hum... yes, it does not happen with strace
2019-02-20 13:12:53 <duncaen> got it to hang with --disable-seccomp-filter-sandbox, but its the same syscall_cp_c with futex/202
2019-02-20 13:17:30 <ncopa> ok, then its not seccomp filter
2019-02-20 13:18:15 <ncopa> just adding --allow-sandbox-debugging does not seem to make problem go away
2019-02-20 13:18:40 <duncaen> yep
2019-02-20 13:18:52 <duncaen> but --single-process I think
2019-02-20 13:19:08 <ncopa> also --no-sandbox
2019-02-20 13:19:42 <duncaen> just got a crash
2019-02-20 13:19:47 <duncaen> [19483:19483:0220/141918.464300:FATAL:render_process_host_impl.cc(4071)] Check failed: render_process_host->InSameStoragePartition( BrowserContext::GetStoragePartition(browser_context, site_instance, false )).
2019-02-20 13:19:52 <duncaen> with --single-process
2019-02-20 13:20:29 <duncaen> http://sprunge.us/8qeztb
2019-02-20 13:23:45 <duncaen> this sucks, it might be related or maybe not because single-process is completely different
2019-02-20 13:25:23 <duncaen> I think if it would be related I would see the same failed check with multiple processes too
2019-02-20 13:27:50 <ncopa> i had other crash with --single-process
2019-02-20 13:31:32 <duncaen> no luck triggering the hang on a glibc system
2019-02-20 13:32:42 <ncopa> maybe we should ask for help in #musl
2019-02-20 13:47:02 <duncaen> hm yes might be something with pthreads
2019-02-20 13:47:47 <ncopa> do you have a tip how to find the pid of the process that hangs?
2019-02-20 13:50:29 <duncaen> tools -> task manager
2019-02-20 13:51:02 <duncaen> the process has multiple threads
2019-02-20 13:51:27 <duncaen> i'm currently attaching to them one by one to see where they are at
2019-02-20 13:52:51 <duncaen> they are either in __pthread_cond_timedwait or epoll_wait
2019-02-20 13:53:44 <ncopa> https://tpaste.us/eegb
2019-02-20 13:54:14 <duncaen> oh nice you have some symbols
2019-02-20 13:54:25 <ncopa> i found the binary in the out/Release dir
2019-02-20 13:54:34 <ncopa> before it was stripped
2019-02-20 13:55:01 <ncopa> thank for the task manager tip
2019-02-20 13:57:20 <duncaen> tail /proc/$HUNG_TAB/task/26*/wchan
2019-02-20 13:57:31 <duncaen> s/26*/*/
2019-02-20 13:57:31 <alpine-meetbot> duncaen meant to say: tail /proc/$HUNG_TAB/task/*/wchan
2019-02-20 13:58:00 <duncaen> nice bot
2019-02-20 13:58:29 <duncaen> maybe the backtrace from the one that is in epoll_wait is useful
2019-02-20 13:58:48 <duncaen> #2  0x00007f77f6b9af38 in event_base_loop () at /lib/libevent-2.1.so.6
2019-02-20 13:58:57 <duncaen> maybe not
2019-02-20 13:59:03 <ncopa> hum
2019-02-20 13:59:07 <ncopa> may be different issue
2019-02-20 13:59:31 <ncopa> hum
2019-02-20 13:59:41 <ncopa> i think we use system libevent?
2019-02-20 13:59:48 <ncopa> instead of bundled libevent
2019-02-20 14:00:14 <ncopa> #2  0x00007f3ecdb28753 in __timedwait (addr=addr@entry=0x55c8838093fc, val=-2147483632, clk=clk@entry=0, at=at@entry=0x0, priv=priv@entry=128)
2019-02-20 14:00:27 <ncopa> i think the "val" there looks suspicious
2019-02-20 14:00:35 <ncopa> i think we should ask #musl
2019-02-20 14:18:38 <duncaen> ncopa: https://cs.chromium.org/chromium/src/v8/src/base/platform/condition-variable.cc?type=cs&g=0&l=18
2019-02-20 14:18:48 <duncaen> (V8_OS_LINUX && V8_LIBC_GLIBC)
2019-02-20 14:19:32 <duncaen> there are some other glibc specific instances
2019-02-20 14:19:49 <duncaen> which would probably work with musl
2019-02-20 14:21:17 <ncopa> oh thats interesting
2019-02-20 14:21:26 <ncopa> i will check that after lunch
2019-02-20 14:21:29 <ncopa> bbl
2019-02-20 14:54:05 <duncaen> ncopa: try chromium --js-flags="--single-threaded true"
2019-02-20 14:54:45 <duncaen> I think I can't reproduce it with --single-threaded
2019-02-20 15:16:42 <ncopa> got some feedback from nsz in #musl
2019-02-20 15:33:29 <mps> p4Wv1qn095FW: did you posted glm gcc patch about which we talked yesterday
2019-02-20 15:39:27 <p4Wv1qn095FW> nope. i was hoping it would get picked up here, but if no progress i'll send a PR later this evening, if i don't forget about it.
2019-02-20 15:41:18 <_ikke_> Anoying when projects require git repositories to build (because they insist on being able to retrieve the commit hash)
2019-02-20 15:41:51 <mps> ok, I'm testing it locally so wanted to ask you if you will or you did. I didn't wanted to send patch if you plan to send it
2019-02-20 15:44:02 <mps> to me it looks like something similar is already there
2019-02-20 15:58:07 <p4Wv1qn095FW> mps if you could test this, it would be awesome. but i presume it should work.
2019-02-20 15:58:22 <p4Wv1qn095FW> just undo this: https://github.com/g-truc/glm/commit/68c7e7e50b934cd265251a0660096f1415647bbb
2019-02-20 16:00:37 <mps> p4Wv1qn095FW: it will few steps works, first I have to build kicad dependencies from your aports and if all passed then could try kicad at the end
2019-02-20 16:01:32 <mps> I just wanted to know would you take these steps, or you have plan to do
2019-02-20 16:02:07 <mps> if not, I will put that on my queue, to not forgot it
2019-02-20 16:08:20 <p4Wv1qn095FW> i can, but only later today, and i possibly need to be reminded /o\
2019-02-20 16:11:44 <mps> imo, it would be better if you do all that because you know what is needed. I just wanted to remind you and to ask if you plan to push all that, would be nice to have kicad on Alpine
2019-02-20 16:49:21 <_ikke_> Yay, amount of open PRs is going down :-)
2019-02-20 16:50:03 <_ikke_> It used to be almost 400 at the beginning of the month
2019-02-20 16:50:49 <jwh> *cough*
2019-02-20 16:50:50 <jwh> :D
2019-02-20 16:54:02 <p4Wv1qn095FW> mps: i just kicked on a kicad build with the patched glm
2019-02-20 19:26:23 <danieli> fyi https://coocoor.com/advisory/cve/CVE-2019-8912
2019-02-20 19:28:40 <_ikke_> Is that the issue someone wanted to reach out to Alpine about?
2019-02-20 19:45:58 <danieli> no idea
2019-02-20 19:46:04 <danieli> probably not? but it is possible
2019-02-20 19:46:06 <danieli> ncopa: ?
2019-02-20 19:46:28 <danieli> debians tracker @ https://security-tracker.debian.org/tracker/CVE-2019-8912
2019-02-20 20:43:07 <duncaen> ncopa: nsenter --pid=/proc/9499/ns/pid mount -t proc profs /tmp/proc works as workaround for pid namespaces without mount namespaces...
2019-02-20 21:04:32 <ace1> i'm looking for a security contact for alpine
2019-02-20 21:05:00 <ace1> we'd prefer not to put it in as a public github issue if there's a security contact
2019-02-20 21:09:14 <_ikke_> ace1: ncopa would be the security contact
2019-02-20 21:13:56 <_ikke_> ncopa@alpinelinux.org fyi
2019-02-20 21:16:58 <ace1> bedankt ikke :)
2019-02-20 21:17:59 <_ikke_> :-)
2019-02-20 21:26:43 <danieli> ace1: also: https://alpinelinux.org/keys/ncopa.asc
2019-02-20 21:26:52 <danieli> :)
2019-02-20 21:27:36 <_ikke_> ah, was trying to find a public location for that
2019-02-20 21:28:00 <_ikke_> Where did you find that?
2019-02-20 21:28:04 <danieli> googled "ncopa.asc"
2019-02-20 21:28:11 <danieli> I recalled the filename but not the location
2019-02-20 21:28:18 <_ikke_> aha
2019-02-20 21:28:42 <danieli> googled it with the double quotes, that is
2019-02-20 23:58:28 <p4Wv1qn095FW> mps my test compile run correctly, i just created this PR for glm to fix this: https://github.com/alpinelinux/aports/pull/6426
2019-02-21 01:38:09 <jwh> hm, bluez-deprecated doesn't include spdtool and stuff?
2019-02-21 01:38:14 <jwh> how misleading
2019-02-21 01:38:28 <jwh> oh it does nm
2019-02-21 07:41:09 <ncopa> duncaen: I may have a fix for the chromium/v8 deadlock
2019-02-21 08:34:40 <clandmeter> did anyone here already play with go modules in aports?
2019-02-21 08:45:34 <duncaen> ncopa: nice, how did you find the bug?
2019-02-21 08:48:53 <ncopa> duncaen: with help from you, nsz and dalias ;)
2019-02-21 08:49:20 <ncopa> dalias and nsz helped me to find the 2 threads that was waiting on same mutex
2019-02-21 08:49:50 <ncopa> the backtrace from those shows what code is involved
2019-02-21 08:50:12 <ncopa> one thread is FlushOutputQueue: https://cs.chromium.org/chromium/src/v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc?q=v8::internal::OptimizingCompileDispatcher::FlushOutputQueue&sq=package:chromium&g=0&l=141
2019-02-21 08:50:46 <ncopa> and the other is CompileNext: https://cs.chromium.org/chromium/src/v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc?q=v8::internal::OptimizingCompileDispatcher::CompileNext&sq=package:chromium&g=0&l=126
2019-02-21 08:51:00 <duncaen> any idea why thhis was only triggered now and only with musl?
2019-02-21 08:51:07 <ncopa> no
2019-02-21 08:51:33 <ncopa> but i think it may be triggered by completely other factors (butterfly effect)
2019-02-21 08:51:44 <ncopa> bug can have been there for long time
2019-02-21 08:52:06 <ncopa> for example, the bug is not triggered if you run it via strace
2019-02-21 08:52:28 <duncaen> so like musl being a tiny bit faster in creating the threads compared to glibc could have triggered it?
2019-02-21 08:52:35 <ncopa> possibly
2019-02-21 08:52:52 <ncopa> or some other code part is slightly slower
2019-02-21 08:53:20 <ncopa> if you look at the CompileNext function
2019-02-21 08:53:28 <duncaen> hm right, maybe the namespaces add to it too and then trigger it, this is something that is weird
2019-02-21 08:54:07 <ncopa> the mutex is held from base::MutexGuard constructor
2019-02-21 08:54:58 <ncopa> and is released at the end of the context ie at the  closing bracket }
2019-02-21 08:55:33 <ncopa> which means that it still holds the mutex when calling isolate_->stack_guard()->RequestInstallCode();
2019-02-21 08:56:10 <ncopa> my fix thesis is: http://tpaste.us/nMeg
2019-02-21 08:56:38 <ncopa> which makes it release the mutex early, before messing with stack guard
2019-02-21 08:57:06 <ncopa> i have not reproduced the issue yet
2019-02-21 08:57:10 <duncaen> nice
2019-02-21 08:57:32 <ncopa> im not 100% sure its the proper fix, but my intuition tells me it could be the fix
2019-02-21 08:57:39 <ncopa> or workaround at least
2019-02-21 09:00:08 <ncopa> slack eats insanely much cpu
2019-02-21 09:00:17 <ncopa> this is not healty
2019-02-21 09:00:38 <duncaen> thats something I noticed with the hagging tabs too
2019-02-21 09:01:17 <duncaen> but i think this was just chromium trying to get a response from the locked process
2019-02-21 09:02:19 <ncopa> that what i thought too, but im not sure that is what happens
2019-02-21 09:02:20 <ncopa> hum
2019-02-21 09:02:23 <ncopa> slack crashed now
2019-02-21 09:04:04 <ncopa> i think crash is separate issue
2019-02-21 09:04:37 <ncopa> ok, i think im gonna push this with chromium-72
2019-02-21 09:04:49 <ncopa> but i will try fix the armv7 build first
2019-02-21 09:06:01 <duncaen> are you going to keep the pthread patch or add the ldflags?
2019-02-21 09:06:36 <ncopa> you mean pthread stack size?
2019-02-21 09:06:41 <ncopa> im gonna keep that
2019-02-21 09:07:03 <ncopa> it is possible we need a patch for v8 too
2019-02-21 09:07:36 <duncaen> yes
2019-02-21 09:07:43 <ncopa> hum... might actually be worth adding ldflag
2019-02-21 09:08:33 <duncaen> without the patch GetDefaultThreadStacksize would return 0 and then use the default
2019-02-21 09:08:44 <duncaen> just checking the other place now
2019-02-21 09:08:58 <ncopa> i saw v8 had pthread_create too
2019-02-21 09:09:21 <duncaen> I think v8 does the stack calculations already by itsel
2019-02-21 09:09:40 <ncopa> yes, but not sure how or where it gets its default from
2019-02-21 09:10:29 <duncaen> ah hm the kShutdownDetectorThreadStackSize still needs the patch because it uses PTHREAD_STACK_MIN, which would be still too small
2019-02-21 09:12:48 <duncaen> https://cs.chromium.org/chromium/src/v8/src/base/platform/platform-posix.cc?dr&q=file:src/v8+pthread_create&g=0&l=765
2019-02-21 09:12:54 <duncaen> yes this looks like it should be patched
2019-02-21 09:13:05 <duncaen> in the case when v8 wants the "default"
2019-02-21 09:13:41 <ncopa> yes, that is the section i was thinking of when i said that v8 may need to be patched
2019-02-21 09:14:16 <ncopa> i dont know what the stack_size is set to ro where it gets its value from
2019-02-21 09:17:01 <mps> p4Wv1qn095FW: nice, hope it will be soon pulled to aports
2019-02-21 09:21:52 <duncaen> I think stack_size is always 0 unless a --stack_size flag is passed
2019-02-21 09:22:28 <duncaen> hm there has to be another case, the flag has a default #define V8_DEFAULT_STACK_SIZE_KB 984
2019-02-21 09:26:21 <duncaen> can't find any case where its 0, they all default to the flag
2019-02-21 09:28:57 <ncopa> i ran a chelf on the binary and interestingly., slack has not crashed yet
2019-02-21 09:30:08 <ncopa> i think i also should report the deadlock upstram
2019-02-21 09:30:13 <ncopa> upstream*
2019-02-21 09:30:31 <duncaen> yes doesn't look musl specfic at all
2019-02-21 09:31:24 <ncopa> yes, i dont think its musl specific
2019-02-21 09:32:21 <duncaen> one thing I learned from this is, pid namespaces are weird
2019-02-21 09:32:29 <ncopa> yup :)
2019-02-21 09:32:31 <duncaen> not sure why they even use them
2019-02-21 09:32:58 <duncaen> maybe "suspending/resuming the set of processes"
2019-02-21 09:34:18 <duncaen> is it possible to run something setuid from a user pidnamespace to kill random root processe
2019-02-21 09:34:28 <duncaen> if the process uses /proc
2019-02-21 09:34:29 <ncopa> and i think a pid in that namespace cannot see process ouside the "container"
2019-02-21 09:35:40 <duncaen> yes "see" as in use kill(), but thats about it I think
2019-02-21 09:36:55 <ncopa> http://man7.org/linux/man-pages/man7/pid_namespaces.7.html see the "/proc and PID namespaces"
2019-02-21 09:39:15 <ncopa> duncaen: what is the ldflag to set pthread stack size?
2019-02-21 09:39:54 <duncaen> -Wl,-z,stack-size=2097152
2019-02-21 09:39:56 <ncopa> found it: -Wl,-z,stack-size=N
2019-02-21 09:40:39 <duncaen> only the base/threading/platform_thread_linux.cc patch can go
2019-02-21 09:41:13 <ncopa> i will keep it i think, because i need to backport it to our 3.9-stable branch
2019-02-21 09:43:24 <duncaen> https://cs.chromium.org/chromium/src/sandbox/linux/services/credentials.cc?dr=C&g=0&l=80
2019-02-21 09:43:44 <duncaen> the use of PTHREAD_STACK_MIN looks it could lead to bugs
2019-02-21 09:45:13 <ncopa> what is PTHREAD_STACK_MIN set to?
2019-02-21 09:45:57 <duncaen> ./include/limits.h:#define PTHREAD_STACK_MIN 2048
2019-02-21 09:46:37 <ncopa> so the buf is only 2k
2019-02-21 09:46:44 <ncopa> should be ok?
2019-02-21 09:47:00 <ncopa> i got another crashing tab
2019-02-21 09:47:14 <duncaen> its 16384 with glibc
2019-02-21 09:47:18 <duncaen> but I guess it doesn't matter
2019-02-21 09:49:03 <duncaen> looks like it does only chroot() chdir() and then exits
2019-02-21 09:53:20 <ncopa> nice! i think i made it build on armv7
2019-02-21 09:53:24 <ncopa> will try aarch64 too now
2019-02-21 09:55:14 <ncopa> btw, i remove the chromium-skia-harmony patch
2019-02-21 09:55:24 <ncopa> to be closer upstream
2019-02-21 10:00:22 <duncaen> https://cs.chromium.org/chromium/src/base/process/launch_posix.cc?type=cs&q=PTHREAD_STACK_MIN&g=0&l=685
2019-02-21 10:00:37 <duncaen> this one might be used as stack for longer running processes
2019-02-21 10:03:34 <andypost[m]> Is there a way to point specific package to dependencies as workaround for https://github.com/alpinelinux/aports/pull/6226#issuecomment-460379251
2019-02-21 10:08:42 <ncopa> duncaen: im reporting it upstream to v8 devs. is it true that the deadlock was not reproducible with  --js-flags="--single-threaded true"?
2019-02-21 10:09:21 <duncaen> couldn't get it to hang this way, but who knows maybe its just a workaround and the issue actually exists
2019-02-21 10:09:35 <duncaen> even then
2019-02-21 10:10:36 <ncopa> makes sense
2019-02-21 10:10:49 <ncopa> it was a deadlock of two different threads waiting for the same mutex
2019-02-21 10:11:41 <duncaen> I did try many different flags flags that change threading, but couldn't find any other flag that fixed it
2019-02-21 10:11:44 <duncaen> --single-process
2019-02-21 10:11:46 <duncaen> ilation false --parallel-compaction false --parallel-pointer-update false --parallel-marking false --parallel-scavenge false --minor-mc-parallel-marking false"
2019-02-21 10:14:05 <ncopa> it makes prefect sense that it does not deadlock with single thread
2019-02-21 10:15:05 <duncaen> yep I think with all the parallel and concurrent flags disable there is still some thread which would dead lock
2019-02-21 14:41:43 <PureTryOut[m]> I'm trying to build qt5-qtwayland for 3.9 for a private repository, but for whatever reason it fails with "Project ERROR: Could not find feature xkbcommon.". However, since the APKBUILD used is the same as the one in edge, this dependency is installed. The version of that dep is the same as in 3.9 and in edge it seems. What could cause it to fail in 3.9 but work fine in edge?
2019-02-21 16:03:10 <p4Wv1qn095FW> huh, i get a "ERROR: texmf-dist-2018.48566-r0: BAD signature" from http://mirror.leaseweb.com/alpine/edge/
2019-02-21 18:35:49 <PureTryOut[m]> Could anyone help me out with my qt5-qtwayland issue?
2019-02-21 20:01:08 <ncopa> PureTryOut[m]: i have no clue whats wrong and I dont have time right now. Feel free to ping me tomorrow and I will have a look
2019-02-21 20:01:52 <PureTryOut[m]> Thanks!
2019-02-21 20:01:59 <PureTryOut[m]> Will do!
2019-02-21 20:16:16 <ace1> thanks daniel i hadn't seen your message yesterday but we were able to contact nataneal and sent it encrypted, it would be great if you guys had a security page with that info on there for other researchers :)
2019-02-21 20:18:58 <SpaceToast> hey ace1, I'm writing the alpine docs - I think I'll add a note on that to the developer handbook (once it's there) in the contributing section :)
2019-02-21 20:51:55 <ace1> thanks!
2019-02-21 21:07:47 <AinNero> >:(
2019-02-21 21:08:42 <AinNero> can we make a policy to not ship /run stuff via apk?
2019-02-21 21:09:08 <_ikke_> Doesn't that already exist?
2019-02-21 21:09:12 <SpaceToast> I'm confused - what kinda /run stuff?
2019-02-21 21:09:29 <SpaceToast> /run is canonically tmpfs so it should probably be handled the same as /tmp
2019-02-21 21:09:48 <AinNero>  /run is sorta guaranteered to be non-persistent
2019-02-21 21:10:10 <SpaceToast> so is /tmp :)
2019-02-21 21:10:13 <SpaceToast> (well it's supposed to be)
2019-02-21 21:10:21 <SpaceToast> I think we clean /tmp on boot just in case it isn't tmpfs
2019-02-21 21:10:43 <AinNero> thats beside the point
2019-02-21 21:11:23 <SpaceToast> well, my point is that, whatever the case, we should probably treat /run like /tmp :)
2019-02-21 21:11:36 <AinNero> tmp is still disk on alpine, usually
2019-02-21 21:12:31 <SpaceToast> except it is not meant to be persistent, canonically is on tmpfs, and is cleaned on boot to emulate that; sure
2019-02-21 21:13:13 <AinNero> back to the topic
2019-02-21 21:13:21 <AinNero> people put /run into package
2019-02-21 21:13:32 <AinNero> which is an awful thing for quite many cases
2019-02-21 21:16:30 <SpaceToast> looks like there's actually no checking for /run *or* /tmp
2019-02-21 21:16:37 <SpaceToast> so we should probably check for all of those
2019-02-21 21:17:32 <AinNero> i'd argue to not put anything in /var as well and create it dynamically
2019-02-21 21:17:41 <AinNero> as long as we want to support data mode
2019-02-22 06:48:50 <user___> hello. is python3 apk broken on aarch64? everytime I try to run python3 interpreter it breaks with segfault. i tried 3.9 and edge.
2019-02-22 06:52:41 <ncopa> user___: i am not able to reproduce: ncopa-edge-aarch64:~/aports/community/chromium$ python3 -c "print('hello world')"
2019-02-22 06:52:41 <ncopa> hello world
2019-02-22 06:53:31 <ncopa> ace1: thanks for your email. i have some questions about it. How can i respond?
2019-02-22 06:59:05 <user___> ncopa: is there any way i can run diagnostics? i tried valgrind but that just spits out endless stream of malloc'd and invalid reads/writes.
2019-02-22 07:00:44 <user___> i noticed most errors come from libpython, which probably isn't surprising.
2019-02-22 07:33:36 <user___> this is some python unrelated problem. gdb too segfaults. perhaps something in libc?
2019-02-22 07:35:18 <user___> hmm, gdb embeds python.
2019-02-22 07:39:40 <ncopa> can you run it via strace?
2019-02-22 07:39:46 <ncopa> what kernel is it? uname -a
2019-02-22 07:50:26 <user___> ncopa kernel 4.19.18-0-rpi
2019-02-22 07:54:23 <ncopa> user___: what rpi is it?
2019-02-22 07:54:33 <user___> rpi 3b+
2019-02-22 07:54:42 <ncopa> can you please report it on bugs.alpinelinux.org? with the above info
2019-02-22 07:54:57 <ncopa> i have an rpi somewhere here, but i dont have time to look at it right now
2019-02-22 07:55:00 <ncopa> hopefully next week
2019-02-22 07:55:03 <user___> i noticed someone else filed the bug here: https://github.com/gliderlabs/docker-alpine/issues/486
2019-02-22 07:55:12 <user___> is it okay to follow up there?
2019-02-22 07:55:32 <ncopa> i guess
2019-02-22 07:58:38 <user___> this has already been filed here too: https://bugs.alpinelinux.org/issues/9981
2019-02-22 09:31:05 <mps> clandmeter: ^
2019-02-22 09:31:22 <clandmeter> ?
2019-02-22 09:31:39 <mps> PM me
2019-02-22 09:32:33 <mps> please, I forgot to add :)
2019-02-22 09:36:03 <mps> you cannot now?
2019-02-22 11:02:23 <m15k> Hi guys. I wonder if someone is working on a mirror like https://snapshot.debian.org/ which acts like an archive for packages. This could easily be used to produce reproducable docker images.
2019-02-22 11:03:02 <m15k> BTW is there anything in addition to the mqtt subscription to be notified on package repository update?
2019-02-22 11:08:03 <ncopa> we want something like https://snapshot.debian.org/ but i dont think anyone is currently working on it
2019-02-22 11:12:42 <PureTryOut[m]> ncopa: you told me to ping you today so you can have a look at my problem with building qt5-qtwayland for Alpine 3.9. So, ping 😄
2019-02-22 11:14:57 <m15k> ncopa: Maybe I'm thinking to easy but: Wouldn't there be a master repo with all artifacts which is symlinked in the snapshot folders...
2019-02-22 11:15:08 <m15k> Am I missing something?
2019-02-22 11:22:39 <ncopa> PureTryOut[m]: it builds for me
2019-02-22 11:24:03 <_ikke_> does moving a package from testing to community require a pkgrel dump?
2019-02-22 11:24:12 <ncopa> no
2019-02-22 11:24:21 <_ikke_> right
2019-02-22 11:25:02 <PureTryOut[m]> That is on 3.9?
2019-02-22 11:25:09 <ncopa> PureTryOut[m]: yes
2019-02-22 11:25:16 <PureTryOut[m]> Huh, even more weird...
2019-02-22 11:25:18 <_ikke_> https://github.com/alpinelinux/aports/pull/6358 asks for the package to be backported to 3.9
2019-02-22 11:25:21 <ncopa> x86_64
2019-02-22 11:25:38 <PureTryOut[m]> any Idea what I can do to debug this?
2019-02-22 11:26:35 <ncopa> hm
2019-02-22 11:26:39 <ncopa> looking at this
2019-02-22 11:26:56 <ncopa> why was it added directly to community and not to testing repo first?
2019-02-22 11:28:06 <PureTryOut[m]> Because we used it for a while in postmarketOS without problems. I asked about it in the PR but it got merged without questioning
2019-02-22 11:28:12 <PureTryOut[m]> and yeah, in edge it actually works fine
2019-02-22 11:28:29 <PureTryOut[m]> also, I just got it to compile on 3.9 when redirecting the console output to a file, but it failed again when not doing that... wtf
2019-02-22 11:29:39 <ncopa> depends="qt5-qtdeclarative libxcomposite wayland qt5-qtquickcontrols2"
2019-02-22 11:29:56 <ncopa> i would expect those be automatically detected by abuild
2019-02-22 11:30:37 <ncopa> http://tpaste.us/qKba
2019-02-22 11:30:37 <PureTryOut[m]> Well all dependencies get installed according to apk, that isn't the problem.
2019-02-22 11:30:55 <PureTryOut[m]> Huh, yeah redirecting the console output to a file somehow fixes this...?
2019-02-22 11:31:06 <ncopa> yes, thats not the problem, but thats not how we deal with dependencies either
2019-02-22 11:31:31 <PureTryOut[m]> What do you mean?
2019-02-22 11:31:32 <ncopa> im am thinking of backporting it to v3.9
2019-02-22 11:31:38 <PureTryOut[m]> Oh that'd be good
2019-02-22 11:31:52 <ncopa> and if we are to support this, then we should probably do the dependencies properly
2019-02-22 11:32:02 <PureTryOut[m]> Sorry, what is not good about it atm?
2019-02-22 11:33:35 <ncopa> i think it explicitly pulls in libxcomposite, but i dont think it is actually using it
2019-02-22 11:33:38 <ncopa> from the build log:
2019-02-22 11:33:46 <ncopa>   XComposite EGL ......................... no
2019-02-22 11:33:46 <ncopa>   XComposite GLX ......................... no
2019-02-22 11:34:33 <PureTryOut[m]> Ah, good call
2019-02-22 11:34:43 <ncopa> it also pulls in "wayland" package as explicit dependency, but i think it actually only needs:
2019-02-22 11:34:46 <ncopa>         so:libwayland-client.so.0
2019-02-22 11:34:46 <ncopa>         so:libwayland-cursor.so.0
2019-02-22 11:34:46 <ncopa>         so:libwayland-server.so.0
2019-02-22 11:34:46 <ncopa>         so:libwayland-egl.so.1
2019-02-22 11:35:13 <ncopa> meaning if nots libraries moves to another package (for example "wayland1.0")
2019-02-22 11:35:25 <ncopa> then is the depends="wayland" broken
2019-02-22 11:36:03 <PureTryOut[m]> Ah ok, TIL. I should check that output better
2019-02-22 11:36:03 <ncopa> same applies to qt5-qtquickcontrols2 and qt5-qtdeclarative
2019-02-22 11:37:13 <fcolista> anyone has experienced that alpine on boot does not load sometimes the apkvol (alpine 3.9)
2019-02-22 11:37:47 <ncopa> boot from USB?
2019-02-22 11:38:08 <ncopa> fcolista: try add usbdelay=5 or similar as boot option
2019-02-22 11:38:30 <fcolista> yes froim USB
2019-02-22 11:38:39 <ncopa> is apkovl on the same usb as it boots from?
2019-02-22 11:38:55 <fcolista> yes
2019-02-22 11:39:03 <fcolista> 3.9 has the second partition with efi
2019-02-22 11:39:08 <fcolista> in the root there's the apkovl
2019-02-22 11:39:19 <fcolista> is loaded randomly
2019-02-22 11:39:29 <fcolista> if you reboot, it starts from scratch
2019-02-22 11:39:36 <fcolista> after a second reboot, it loads the apkovl
2019-02-22 11:39:42 <ncopa> is it the same partition as it has the apks directory?
2019-02-22 11:40:24 <fcolista> no
2019-02-22 11:40:36 <fcolista> I cannot copy it because that partition is read-only
2019-02-22 11:41:08 <ncopa> can you remount it rw?
2019-02-22 11:41:08 <fcolista> making the ISO from alpine 3.9, it creates two partitions
2019-02-22 11:41:10 <fcolista> no
2019-02-22 11:41:15 <fcolista> cannot remount rw
2019-02-22 11:41:35 <ncopa> ok
2019-02-22 11:41:42 <ncopa> i find it weird
2019-02-22 11:42:08 <ncopa> i think what happens is that it finds apks direcotry (.boot_repository file)
2019-02-22 11:42:23 <ncopa> but finding the other partition takes too much time for some reason
2019-02-22 11:42:25 <fcolista> it's mounted read-only and cannot change it
2019-02-22 11:42:28 <ncopa> more than 1 sec
2019-02-22 11:42:47 <ncopa> and it times out as if there were no apkovl
2019-02-22 11:43:04 <ncopa> i think adding usbdelay=5 may solve it
2019-02-22 11:43:06 <fcolista> but I can't modify the syslinux.cfg
2019-02-22 11:43:09 <fcolista> since is RO
2019-02-22 11:43:34 <fcolista> it sais that is write-protected
2019-02-22 11:44:09 <ncopa> but if it uses efi, then it does not use syslinux?
2019-02-22 11:44:18 <ncopa> oh, you just puth the apkovl on the efi partition
2019-02-22 11:44:27 <fcolista> that's what I did
2019-02-22 11:44:36 <fcolista> the apkvol is in the second partition where there's only efi
2019-02-22 11:44:54 <fcolista> the first partition has apks/boot/etc...
2019-02-22 11:45:04 <ncopa> and is iso9660
2019-02-22 11:45:09 <ncopa> which is read-only
2019-02-22 11:45:27 <ncopa> i guess the best thing would be to recreate the bootable usb with setup-bootable
2019-02-22 11:45:28 <fcolista> i created the usb with dd using the 3.9 x86_64 iso
2019-02-22 11:45:43 <ncopa> unless you need it to boot with efi
2019-02-22 11:46:27 <fcolista> it does not start
2019-02-22 11:46:42 <ncopa> PureTryOut[m]: i think this is the proper way to do it:  http://tpaste.us/NKJB
2019-02-22 11:46:50 <fcolista> i guess i need to disable efi boot from bios
2019-02-22 11:47:20 <ncopa> PureTryOut[m]: i think i will push that, and if it works for you I can backport it
2019-02-22 11:47:54 <ncopa> depends should normally be empty
2019-02-22 11:48:48 <PureTryOut[m]> Yeah sure, I'd love it to be backported thanks!
2019-02-22 11:53:53 <ncopa> PureTryOut[m]: i also think your 3.9 env is broken somehow. do you use tmux? or lxc?
2019-02-22 11:53:58 <ncopa> i think i have seen something similar
2019-02-22 11:54:11 <ncopa> and it was resolved when i rebooted my lxc
2019-02-22 11:54:28 <PureTryOut[m]> I do not. It's a clean chroot
2019-02-22 11:54:45 <ncopa> try "logout" from the chroot
2019-02-22 11:54:50 <ncopa> and enter again
2019-02-22 11:55:10 <PureTryOut[m]> just exit you mean? I already rebooted my PC between yesterday and today, don't think this will make a difference lol
2019-02-22 11:55:12 <ncopa> it may also be something broken with your tty or /dev/null or similar
2019-02-22 11:55:19 <ncopa> ok
2019-02-22 11:57:30 <ncopa> fabled: what do you think about replace the community/rethinkdb/openssl-1.1-all.patch  with the upstream patch from 2.4.0 branch?
2019-02-22 11:58:49 <ncopa> this one: https://github.com/rethinkdb/rethinkdb/commit/3156820e058cd410078a4c39d5a2a85f6b714c07
2019-02-22 11:59:07 <ncopa> i think they solve same thing
2019-02-22 12:05:31 <mps> how to add package from pinned @testing to makedepends in APKBUILD
2019-02-22 12:08:09 <_ikke_> Don't think that's supported
2019-02-22 12:10:41 <ncopa> thats not supported
2019-02-22 12:11:56 <mps> so, only solution is to have unpinned test in repositories?
2019-02-22 12:12:07 <mps> s/test/testing/
2019-02-22 12:12:07 <alpine-meetbot> mps meant to say: so, only solution is to have unpinned testing in repositories?
2019-02-22 12:12:28 <ncopa> yes
2019-02-22 12:12:56 <mps> ok, thanks for explanation
2019-02-22 12:13:26 <ncopa> clandmeter: we want backport the modoopfw option to v3.9 right?
2019-02-22 12:13:29 <ncopa> for 3.9.1
2019-02-22 12:28:21 <fabled> ncopa, replacing stuff with upstream versions sounds good
2019-02-22 12:33:28 <ncopa> thats what im thinking. can you please have a short look at it and see so they dont do anything obviously stupid? I see that your changes comes from high up upstream
2019-02-22 12:33:48 <ncopa> s/high/higher/
2019-02-22 12:33:48 <alpine-meetbot> ncopa meant to say: thats what im thinking. can you please have a short look at it and see so they dont do anything obviously stupid? I see that your changes comes from higher up upstream
2019-02-22 12:37:26 <fabled> ncopa, it's a bit different approach but looks like it fixes the same issues as i fixed
2019-02-22 12:37:52 <ncopa> ok, i'll push it and see what happens
2019-02-22 12:37:56 <ncopa> to edge that is
2019-02-22 12:41:03 <mps> could files pkgname.pre-install and pkgname.post-install be empty if they are not need to do anything during install/removal of package
2019-02-22 12:42:31 <mps> or they must have '#!/bin/sh ....' boilerplate in their content
2019-02-22 12:44:25 <mps> ok, I see that they must have that boilerplate
2019-02-22 12:47:54 <_ikke_> Couldn't you just remove them?
2019-02-22 12:49:20 <mps> tried but then 'abuild sanitycheck' says that the package is not 'sane'
2019-02-22 12:50:02 <_ikke_> mps: did you remove the entries from the APKBUILD as well?
2019-02-22 12:50:03 <mps> it is because there is pkgname.initd file probably
2019-02-22 12:50:27 <mps> pre and post install aren't in APKBUILD
2019-02-22 12:50:51 <_ikke_> lots of packages don't have a pre and post install script
2019-02-22 12:51:33 <mps> right, I know that and because that thought I can delete them from new package I'm preparing
2019-02-22 12:51:54 <mps> but looks like for 'daemon' packages the must exists
2019-02-22 12:52:51 <mps> I'm not sure in what just wrote, and hope that someone who knows will explain that better (for SpaceToast to add to dev guide :) )
2019-02-22 12:53:37 <_ikke_> Doesn't make sense at all that it should be required for services
2019-02-22 12:54:34 <mps> really don't know, tried without them and abuild says the package is not sane
2019-02-22 12:55:28 <mps> tried with empty and then build passes but then install doesn't work saying: RROR: metalog-20181125-r0.pre-install: script exited with error 127
2019-02-22 12:55:53 <mps> with shebang boilerplate everything is fine
2019-02-22 12:57:45 <_ikke_> I've never had abuild complain about missing install files
2019-02-22 12:59:46 <mps> also I don't had for 'normal' packages, but have for server/daemon packages
2019-02-22 13:03:29 <_ikke_> mps: do you have an -openrc sub pakcage?
2019-02-22 13:03:31 <_ikke_> package
2019-02-22 13:04:15 <mps> didn't yet added but will add it
2019-02-22 13:04:49 <mps> I'm testing does it works first
2019-02-22 13:05:32 <mps> I mean, does binary works
2019-02-22 13:18:26 <mps> _ikke_: sorry, I was blind, pre and post were in install of the APKBUILD
2019-02-22 15:15:16 <mps> TBB: https://patchwork.alpinelinux.org/patch/4521/
2019-02-22 15:34:12 <andypost[m]> ncopa pcprefix should be added only to *ssl packages? How to use it for php-ssh?
2019-02-22 15:58:58 <odc> we need more smart opinions here: https://bugs.alpinelinux.org/issues/9960
2019-02-22 16:01:55 <ncopa> andypost[m]: the pcprefix is just to make libressl's provides=so:libssl go away
2019-02-22 16:02:50 <mps> odc: maybe there missing note about virtio-rng for VM's?
2019-02-22 16:04:54 <odc> mps: "missing a note"?
2019-02-22 16:05:32 <odc> I know CoreOS has the virtio-rng module statically compiled, and they don't have the issue
2019-02-22 16:05:56 <odc> on Alpine it's a dynamic module
2019-02-22 16:06:06 <odc> maybe it makes a difference?
2019-02-22 16:06:24 <ncopa> so when libssh2-dev says it needs pc:libssl it will pick openssl-dev
2019-02-22 16:06:46 <ncopa> odc: that is quite possible
2019-02-22 16:06:53 <AinNero> hm, i managed the entropy shortage on my systems with -device virtio-rng-pci, using the virt flavour
2019-02-22 16:07:22 <mps> odc: for VM's virtio-rng should be added to modules, and yes on Alpine it is module, not built in kernel
2019-02-22 16:07:39 <AinNero> i tought, if we add capability to find arbitrary files to nlplug-findfs, we could preseed files on boot media
2019-02-22 16:07:42 <PureTryOut[m]> I just got a notification that someone has a package flagged out of date. However, it isn't out of date and it's already the newest version out there (qt5-qtvirtualkeyboard). Can I just ignore it or can I somehow unflag it?
2019-02-22 16:09:08 <odc> I don't know if AWS EC2 provides virtio-rng, gonna check
2019-02-22 16:40:00 <clandmeter> PureTryOut[m]: just ignore it
2019-02-22 16:40:08 <clandmeter> it will reset on next update
2019-02-22 16:43:05 <PureTryOut[m]> Ok
2019-02-22 16:43:29 <PureTryOut[m]> Can I report the email adres for abuse then? The message is also just "Ya", seems like a troll to me
2019-02-22 17:00:36 <odc> looks like some people have entropy problems even with virtio-rng. And AWS has zero info on that subject :/  Action plan: try a kernel where virtio-rng is builtin and see if it changes anything. Else: provide rngd or haveged by default with virt images
2019-02-22 17:01:19 <odc> or at least with ec2 images
2019-02-22 17:05:46 <ace1> ncopa: i'm sure regina will send you an answer soon but the Cisco Talos Vendor reporting key is 0x0E16F693 on public key servers (described here https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html)  also available on the bottom of this page https://www.talosintelligence.com/vulnerability_reports#disclosed
2019-02-22 17:07:48 <mps> odc: actually I patched kernel for ARM boxes without good source of entropy, changed/reverted crng init
2019-02-22 18:31:26 <_ikke_> In an lxc container that I've just updated: Error relocating /usr/bin/curl: curl_url_cleanup: symbol not found
2019-02-22 18:31:33 <_ikke_> Any idea how I can fix that?
2019-02-22 18:35:01 <_ikke_> curl and libcurl version seems to mismatch
2019-02-22 18:39:20 <_ikke_> How can I find what holds libcurl back?
2019-02-22 18:43:21 <mps> 'apk info -r libcurl' could help
2019-02-22 18:44:00 <_ikke_> I decided to reinstall it (and as a resuld removing things that depend on it), and that fixed it
2019-02-22 19:47:21 <AinNero> SpaceToast: did you have some concepts for a mdev-based replacement for nlplug-findfs?
2019-02-22 20:01:22 <SpaceToast> AinNero: yes, but I'm a tad bit busy right now :)
2019-02-22 20:01:34 <SpaceToast> poke me again around 7pm EST (or anytime Sunday(
2019-02-22 20:01:48 <SpaceToast> we're moving offices at work right now and I obviously have to get everything set up before people start coming in
2019-02-22 20:09:33 <jammers> Is the dev group here still using Buildroot as shown in the wiki? https://wiki.alpinelinux.org/wiki/Cross-Compiler_targeting_Alpine
2019-02-22 20:11:06 <_ikke_> afaik, the official builders not using a buildroot atm
2019-02-22 20:11:17 <_ikke_> s/not/are not/
2019-02-22 20:11:17 <alpine-meetbot> _ikke_ meant to say: afaik, the official builders are not using a buildroot atm
2019-02-22 20:13:09 <jammers> what toolchain is being used to build edge cross compiling for ARM on x86-64?
2019-02-22 20:13:25 <_ikke_> alpine is not cross-compiling
2019-02-22 20:13:32 <_ikke_> everything is built on native hardware
2019-02-22 20:14:17 <jammers> I dont have any ARMHF machine up to tha task     :(
2019-02-22 20:17:26 <jammers> is it your armhf machine being used?
2019-02-22 20:19:45 <_ikke_> We use armv7 hardware, but don't know what exactly
2019-02-22 20:20:14 <mps> jammers: what you want to be tested
2019-02-22 20:20:38 <jammers> I just need a  static version of 'dialog' for armeabi and armhf. I tried buildroot, and the binary does run, but screen output is garbled
2019-02-22 20:21:28 <mps> I have one box but it is now armv7
2019-02-22 20:21:49 <mps> don't know if I can build armhf on it
2019-02-22 20:22:19 <jammers> that bin would still run tho, not sure of performance hit if any for that app
2019-02-22 20:22:29 <jammers> arm7 bin
2019-02-22 20:24:08 <mps> but dialog is small package and probably could be built on small SBC's, i.e. 1GB of RAM
2019-02-22 20:27:36 <jammers> ugh, offsite with flakey wifi.
2019-02-22 20:29:15 <jammers> would you mind making the arm7 static dialog binary?
2019-02-22 20:33:52 <mps> you mean armv7?
2019-02-22 20:34:48 <mps> do you have APKBUILD for static version
2019-02-22 20:36:11 <mps> aports version doesn't have flags/options for static version
2019-02-22 20:39:20 <jammers> yes armv7,  I was using buildroot, not APKBUILD, but could you pass the LD -static flag in the env?
2019-02-22 20:40:03 <jammers> not familiar enough with APKBUILD internals to know where to change in inside
2019-02-22 20:40:07 <mps> huh, it needs libncursesw static first
2019-02-22 20:40:31 <jammers> yes ncurses-lib static 1st
2019-02-22 20:42:54 <mps> ncurses-static, actually
2019-02-22 20:43:25 <mps> what CFLAGS should be set to build static dialog
2019-02-22 20:44:13 <mps> build libdialog.a but dialog is still dynamic
2019-02-22 20:44:47 <jammers>  CC='gcc -static'
2019-02-22 20:45:26 <jammers> or CFLAGS='-static
2019-02-22 20:46:23 <jammers> sometime have to go as far as   make SHARED=0 CFLAGS='-static
2019-02-22 20:48:17 <mps> didn't work, still dynamic
2019-02-22 20:50:56 <jammers> the clue may be in the busybox static APKBUILD configs
2019-02-22 20:51:24 <mps> here is changed APKBUILD http://tpaste.us/yPKg
2019-02-22 20:55:49 <mps> although, 'ldd dialog' shows just 'ldd (0xf7e0a000);
2019-02-22 20:57:59 <jammers> email sent mps
2019-02-22 20:58:45 <mps> greylist in action
2019-02-22 20:59:45 <jammers> did the binary run ok. easy test is    dialog --yesno testing 20 30
2019-02-22 21:00:47 <mps> it works
2019-02-22 21:01:14 <mps> maybe need to add something to LDFLAGS
2019-02-22 21:03:01 <jammers> something like  ./configure LDFLAGS="-static" && make
2019-02-22 21:04:23 <mps> already tried and still same result
2019-02-22 21:07:24 <jammers> maybe post #2 here : https://github.com/docker-library/golang/issues/152
2019-02-22 21:08:31 <jammers> maybe '-extldflags "-static"'
2019-02-22 21:11:55 <mps> this will not work
2019-02-22 21:15:11 <jammers> aha     --enable-static \  like here:   https://github.com/Francesco149/sharenix/commit/20cbd7a4dd44ae51430db892a7c04d956c3b76fc
2019-02-22 21:18:00 <mps> dialog configure doesn't have that option, first thing I looked for
2019-02-22 21:23:23 <jammers> if the dyn ncurses, musl  are not there, dialog should try to link with the static libs, I think this is how build-root overcomes some package deficiencies for its static builds
2019-02-22 21:26:29 <mps> ncurses-dev is needed because they contains header
2019-02-22 21:27:22 <jammers> yes, I just mean build ncurses static only
2019-02-22 21:27:53 <mps> ncurses-static contains static libs of the ncurses
2019-02-22 21:29:19 <mps> for some reason linker links static libraries but add ldd and make final binary dynamic, only ldd is dynamically linked in
2019-02-22 21:33:33 <mps> I have no more ideas how to make it static
2019-02-22 21:35:03 <jammers> so adding --enable-static \  had no effect in APKBUILD ?
2019-02-22 21:35:59 <mps> no, because dialog configure script doesn't have that option
2019-02-22 21:36:22 <mps> anyway, tried but as expected didn't worked
2019-02-22 21:38:18 <jammers> if you run that binary in an empty chroot, does it work?
2019-02-22 21:39:09 <mps> empty chroot? how to do it
2019-02-22 21:40:37 <jammers> put the file in an empty folder, cd to folder, chroot .  dialog --help
2019-02-22 21:43:11 <mps> actually like this: chroot . /dialog -help
2019-02-22 21:43:17 <mps> it works
2019-02-22 21:46:01 <jammers> I can test it as well if you email it :)
2019-02-22 21:47:04 <mps> are you sure? you will trust some random person from the net and run binary without proper check of some trojan inside
2019-02-22 21:55:39 <jammers> will sandbox it :)
2019-02-22 21:57:11 <mps> ok, PM me
2019-02-22 21:58:21 <jammers> email sent
2019-02-22 22:02:56 <mps> where, to some of alpine ML's
2019-02-22 22:03:51 <jammers> to ms1*** gmail
2019-02-22 22:05:28 <mps> I suspect I'll receive it, don't have relation with gmail
2019-02-22 22:27:19 <jwh> awww what, no android-tools for armhf?
2019-02-22 22:27:28 <jwh> RIP
2019-02-22 22:28:01 <jwh> broken or just untested?
2019-02-22 22:28:47 <mps> I think it is made only for x86_64 by upstream
2019-02-22 22:28:51 <jwh> ah
2019-02-22 22:28:54 <jwh> lamers
2019-02-22 22:30:39 <mps> you expected something else from them :/
2019-02-22 22:30:46 <jwh> I guess not lol
2019-02-22 22:31:04 <jwh> but since like none of the android devices are x86 (and they don't even officially support x86), thats just rude
2019-02-22 22:31:34 <mps> there are x86 android devices, I own one
2019-02-22 22:31:54 <jwh> an official one?
2019-02-22 22:32:00 <jwh> or the android x86 project?
2019-02-22 22:32:14 <mps> oh, asus one
2019-02-22 22:32:30 <jwh> with proper android?
2019-02-22 22:32:43 <mps> and yes, AOSP (android base) could be built for x86
2019-02-22 22:32:54 <mps> it is supported, afaik
2019-02-22 22:32:56 <jwh> yeah AOSP doesn't really count
2019-02-22 22:33:08 <jwh> theres way too much missing
2019-02-22 22:33:23 <jwh> get screwed by google play protect now anyway
2019-02-22 22:33:48 <mps> I have one ASUS phonepad with x86 android officially supported I think
2019-02-22 22:34:08 <jwh> hm, still
2019-02-22 22:34:10 <jwh> very few devices
2019-02-22 22:34:36 <jwh> maybe that will change with intels new stuff thoguh
2019-02-22 22:34:39 <jwh> though*
2019-02-22 22:34:40 <mps> it was when bought, now I suspect it is 'end of life'
2019-02-23 00:20:04 <jwh> mps: hm
2019-02-23 00:22:39 <mps> jwh: maybe it could be built on arm's
2019-02-23 00:22:58 <jwh> I just built it
2019-02-23 00:23:13 <jwh> apart from lxd not actually attaching the phone to the container...
2019-02-23 00:23:17 <jwh> adb runs ok though
2019-02-23 00:23:42 <mps> heh, I tried on aarch64 but it failed
2019-02-23 00:24:04 <jwh> hm, this is armhf
2019-02-23 00:24:09 <mps> probably should try on armv7
2019-02-23 00:24:28 <jwh> wait what
2019-02-23 00:24:42 <jwh> oh, wrong window
2019-02-23 00:24:50 <jwh> but yeah, it works on arm anyway as arch build it
2019-02-23 00:25:22 <mps> ok, will try on armv7 later
2019-02-23 00:25:43 <jwh> only thing I needed to do was change some errors to warnings
2019-02-23 00:25:51 <mps> but on aarch64 obviously needs patches or some tweaks
2019-02-23 00:25:51 <jwh> but it should be fine
2019-02-23 00:26:04 <jwh> probably the same thing
2019-02-23 00:26:26 <jwh> -Wno-error=attributes
2019-02-23 00:26:31 <jwh> it should probably be fixed
2019-02-23 00:26:37 <mps> tell me, you build it from aports testing
2019-02-23 00:26:39 <jwh> but I didn't wanna look into boringssl
2019-02-23 00:26:43 <jwh> yes
2019-02-23 00:26:52 <jwh> just added the above to CFLAGS/CXXFLAGs
2019-02-23 00:27:09 <jwh> don't care if other stuff is broken, only want adb so haven't tested the rest of it
2019-02-23 00:28:07 <jwh> but since its built for ALARM I'd imagine its just fine
2019-02-23 00:29:37 <mps> wait, you built it on arch linux
2019-02-23 00:31:46 <mps> heh, on armv7 it passed
2019-02-23 00:31:52 <jwh> no, on alpnie
2019-02-23 00:31:54 <jwh> alpine
2019-02-23 00:32:35 <jwh> I use alarm as a reference though, they've done most of the hard work :D
2019-02-23 00:32:43 <jwh> http://ix.io/1BNM
2019-02-23 00:34:58 <mps> it passed 'abuild -r' on Alpine armv7
2019-02-23 00:37:35 <mps> lets try on aarch64
2019-02-23 00:38:19 <jwh> ye
2019-02-23 00:38:30 <jwh> I don't have any aarch64, only arm7
2019-02-23 00:38:34 <jwh> armv7*
2019-02-23 00:39:14 <mps> I have arm's everywhere :)
2019-02-23 00:39:26 <jwh> https://github.com/archlinuxarm/PKGBUILDs/tree/master/community/android-tools
2019-02-23 00:39:32 <jwh> not sure if those patches are needed
2019-02-23 00:40:03 <jwh> might  be better if they are
2019-02-23 00:40:06 <jwh> included
2019-02-23 00:40:07 <mps> '-Wno-error=attributes' is what is needed, at least for now
2019-02-23 00:40:19 <jwh> aame on arm64?
2019-02-23 00:40:57 <mps> 'abuild -r' passed also on aarch64
2019-02-23 00:41:29 <jwh> ok cool
2019-02-23 00:41:31 <mps> huh, how I'm ignorant
2019-02-23 00:42:15 <mps> I wrote a hour or two ago it not possible
2019-02-23 00:43:34 <mps> it needs test with real hardware, and I will do that in next few days to see if it really works
2019-02-23 00:44:51 <mps> it late (or to early) here now, need to go to bed.
2019-02-23 00:45:38 <mps> jwh: thanks for big help to build this tool
2019-02-23 00:45:40 <jwh> well, I have real hardware but I don't think lxd is working properly
2019-02-23 00:45:58 <jwh> I attached my android phone but its not showing up, at least on alpine
2019-02-23 00:46:19 <mps> if you have real hardware why you need lxd to test it
2019-02-23 00:46:51 <jwh> no alpine on my armv7 board, at least not until I've add a kernel aport
2019-02-23 00:47:05 <jwh> its headless and I can't make the uart work, so no debug
2019-02-23 00:47:21 <mps> ah, so. build your own as I do for all of my arm's
2019-02-23 00:47:33 <jwh> yeah, but without any console I can't see why it breaks
2019-02-23 00:47:35 <jwh> so...
2019-02-23 00:48:33 <mps> eh, we can talk about that in a day or two, I'm tired now and is time for sleep. good night
2019-02-23 00:48:40 <jwh> night
2019-02-23 00:49:09 <jwh> oh
2019-02-23 00:49:14 <jwh> it works after I stop/start
2019-02-23 00:49:16 <jwh> guess hotplug is broken
2019-02-23 00:49:24 <jwh> abuild:~# adb devices
2019-02-23 00:49:24 <jwh> List of devices attached
2019-02-23 00:49:24 <jwh> 42006f40ccbdc4df        unauthorized
2019-02-23 00:50:08 <jwh> abuild:~# adb shell uptime
2019-02-23 00:50:08 <jwh>  01:50:04 up 1 day, 21:54,  0 users,  load average: 3.63, 3.60, 3.58
2019-02-23 00:50:11 <jwh> good enough for me
2019-02-23 09:56:04 <_ikke_> Looks like testing/py-pandas 0.23.4-r0 is hanging
2019-02-23 09:56:25 <_ikke_> builders are not doing a lot
2019-02-23 10:03:27 <fabo> hi, what's the process to get a package out of testing, and moved to edge or an actual released Alpine?
2019-02-23 10:04:55 <_ikke_> are you the maintainer or just a user of that package?
2019-02-23 10:07:21 <fabo> _ikke_: currently a user, I've got an updated APKBUILD for latest release
2019-02-23 10:08:54 <_ikke_> You can talk to the maintainer providing them feedback to say that the package works and can be moved to probably community
2019-02-23 10:09:25 <fabo> _ikke_: the maintainer line is empty -> https://github.com/alpinelinux/aports/blob/master/testing/uboot-tools/APKBUILD
2019-02-23 10:09:38 <_ikke_> ah, it's unmaintained
2019-02-23 10:10:01 <_ikke_> are you willing to maintain that package?
2019-02-23 10:10:19 <fabo> I'm happy to step up and maintain it in community
2019-02-23 10:11:44 <_ikke_> feel free to submit a pull request here https://github.com/alpinelinux/aports or provide a patch to the alpine-devel mailingl ist
2019-02-23 10:11:51 <_ikke_> alpine-aports I mean
2019-02-23 10:12:47 <fabo> _ikke_: ack, thanks for the pointer
2019-02-23 16:02:53 <ddevault> this should be applied to alpine 3.9 https://github.com/alpinelinux/aports/pull/6225
2019-02-24 12:02:49 <mps> how to download github PR as patch from WEB interface? here is a patch https://github.com/crystal-lang/crystal/pull/7477/commits/a55796be911334f5a02f7407af1b6b6bb5219b53#diff-55a89fb13123f835270f1e54fa91ee6c
2019-02-24 12:03:32 <mps> it is related to upgrade of libxml2 and failed build of the crystal after that upgrade
2019-02-24 12:04:35 <mps> maybe I'm blind, but I don't see option on above url to download that patch (PR) as patch file
2019-02-24 12:06:13 <jwh> same as almost everywhere else, just add .patch to the url
2019-02-24 12:06:26 <jwh> commits etc
2019-02-24 12:07:34 <mps> meh, gitlab have 'plain diff' and 'email patches'
2019-02-24 12:08:09 <jwh> .patch is *much* nicer
2019-02-24 12:08:19 <jwh> since you can script it etc
2019-02-24 12:08:36 <mps> and no, for me adding .patch after url don't work, don't know why
2019-02-24 12:08:51 <jwh> it does
2019-02-24 12:09:13 <jwh> https://github.com/crystal-lang/crystal/pull/7477/commits/a55796be911334f5a02f7407af1b6b6bb5219b53.patch
2019-02-24 12:09:42 <mps> with wget got hml file
2019-02-24 12:10:21 <jwh> [root@htpc ~]# curl -sL https://github.com/crystal-lang/crystal/pull/7477/commits/a55796be911334f5a02f7407af1b6b6bb5219b53.patch | head -n2
2019-02-24 12:10:24 <jwh> From a55796be911334f5a02f7407af1b6b6bb5219b53 Mon Sep 17 00:00:00 2001
2019-02-24 12:10:25 <jwh> From: Ary Borenszweig <asterite@gmail.com>
2019-02-24 12:10:36 <jwh> should be ok
2019-02-24 12:10:41 <mps> oh, must be something else, your url works
2019-02-24 12:10:52 <jwh> did you remove the #?
2019-02-24 12:11:01 <jwh> thats not part of the url so it won't work
2019-02-24 12:11:29 <mps> wget https://github.com/crystal-lang/crystal/pull/7477/commits/a55796be911334f5a02f7407af1b6b6bb5219b53.patch
2019-02-24 12:11:34 <mps> that worked
2019-02-24 12:11:51 <jwh> was gonna ask if it was the redirect that broke it
2019-02-24 12:11:56 <jwh> but guess not
2019-02-24 12:12:38 <mps> don't understand these github comlex fiddling with url's :(
2019-02-24 12:13:01 <jwh> there are a few other shortcuts for .patch
2019-02-24 12:13:04 <jwh> pretty handy
2019-02-24 12:13:29 <jwh> I have many horrible shell aliases that use patch id to grab diffs and PRs from githube etc :D
2019-02-24 12:14:11 <mps> I presume they have it, but why they don't put url or button or 'copy patch url' to download patch on the PR page
2019-02-24 12:14:31 <jwh> yeah dunno
2019-02-24 12:15:37 <mps> for people who do not use github much it is unintuitive, at least for me
2019-02-24 12:37:21 <clandmeter> mps: just append .patch to pr number
2019-02-24 12:39:41 <mps> clandmeter: thanks, jwh already helped me
2019-02-24 12:40:32 <clandmeter> that was for a commit
2019-02-24 12:40:43 <mps> latest libxml2 upgrade introduced that bug which I need to fix
2019-02-24 12:41:00 <jwh> if in doubt, just add .patch :D
2019-02-24 12:41:04 <jwh> it works in a lot of places
2019-02-24 12:41:08 <mps> ah, pr number, sounds better idea
2019-02-24 12:41:32 <jwh> I think it also works in .. diffs too
2019-02-24 12:42:37 <mps> yes, got a PR number with .patch extension. Nice :)
2019-02-24 12:44:21 <mps> but still have to lament, why they didn't put button or something with a hint to download patch :/
2019-02-24 15:05:47 <hjaekel> how can I test my build on other platforms? My build is successful on x86_64, but fails von x86, aarch64, armhf, and armv7
2019-02-24 15:06:52 <dnull> Well yeah, those are different architectures
2019-02-24 15:07:07 <dnull> You have to build for each
2019-02-24 15:08:54 <hjaekel> dnull, here is my problem: https://cloud.drone.io/alpinelinux/aports/54/4/2
2019-02-24 15:09:29 <hjaekel> in order to find the solution for the build problem, I have to test locally; or should I push and see if drone.io can build?
2019-02-24 15:13:39 <mps> hjaekel: `armv8l-unknown-linux-musleabihf' machine `armv8l-unknown-linux' not recognized
2019-02-24 15:15:03 <mps> not sure, but probably should be aarch64 instead of armv8l
2019-02-24 15:17:13 <hjaekel> mps, I already found this line; my solution strategy is mostly try and error, I can try aarch64 and see if it builds. Usually I need more than one try, and I don't want to push to GitHub each time
2019-02-24 15:19:13 <hjaekel> mps, line 48 in my APKBUILD already tries to replace arm* with aarch32
2019-02-24 15:19:55 <mps> that drone.io service is new in Alpine and I don't have idea could it be used in 'try and error' workflow
2019-02-24 15:22:15 <hjaekel> it's better than Travis, on Travis we only had x86_64
2019-02-24 15:23:20 <mps> yes, it looks better. ask clandmeter how you could use 'drones'
2019-02-24 15:23:20 <_ikke_> it's still 'beta' though
2019-02-24 15:23:29 <_ikke_> (for us)
2019-02-24 15:24:25 <AinNero> hjaekel: _jarch does not really seem used
2019-02-24 15:25:07 <AinNero> so the configure is not affected by that switch case
2019-02-24 15:25:47 <hjaekel> AinNero, ups, you are right
2019-02-24 15:33:02 <clandmeter> hjaekel: you also need update_config_sub
2019-02-24 15:34:24 <hjaekel> clandmeter, what is update_config_sub?
2019-02-24 15:35:08 <clandmeter> it updates config.sub
2019-02-24 15:39:56 <clandmeter> hjaekel: do you need to overide the unpack function?
2019-02-24 15:44:36 <hjaekel> clandmeter, I don't understand why I need to update the config.sub; where do I have to put update_config_sub?
2019-02-24 15:44:55 <clandmeter> normally in prepare
2019-02-24 15:45:28 <hjaekel> clandmeter, maybe the code I wrote in the unpack function can be better placed somewhere else...
2019-02-24 15:45:48 <clandmeter> i wonder why you did that
2019-02-24 15:45:57 <clandmeter> the only thing you need is the rename of the dires?
2019-02-24 15:46:05 <clandmeter> s/dires/dirs
2019-02-24 15:46:39 <hjaekel> yes, rename and move the dirs
2019-02-24 15:46:47 <clandmeter> do that in prepare
2019-02-24 15:46:57 <clandmeter> and append default_prepare
2019-02-24 15:47:04 <hjaekel> OK
2019-02-24 15:47:13 <clandmeter> you can find some refs in aports\
2019-02-24 15:48:27 <clandmeter> there are also some whitespace issues
2019-02-24 15:48:38 <hjaekel> if you are doing a review of my APKBUILD please keep in mind that openjdk9 is only necessary for building openjdk10 and should be deleted afterwards... the final goal is openjdk11
2019-02-24 15:49:31 <clandmeter> if its going to be commited lets do it the right way.
2019-02-24 15:50:07 <clandmeter> i dont think the errors you have are related to drone.
2019-02-24 15:50:45 <hjaekel> ok I will do it
2019-02-24 15:50:55 <clandmeter> err
2019-02-24 15:50:59 <clandmeter> not related
2019-02-24 15:51:00 <hjaekel> no, the errors are related to my try and error workflow
2019-02-24 15:51:15 <clandmeter> yeah its sunday
2019-02-24 15:51:19 <clandmeter> my typing sucks
2019-02-24 15:51:49 <clandmeter> but drone is new in our infra, so could be it has issues.
2019-02-24 15:52:05 <clandmeter> but im glad we can catch arch issues like this.
2019-02-24 15:52:09 <clandmeter> saves us some troubles
2019-02-24 17:50:00 <Mis012[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/wZpGrgClOHjajkVwJVopgsQZ >

2019-02-24 17:52:45 <danieli> matrix?
2019-02-24 17:52:58 <danieli> oh right, it posts a link to a website containing long messages instead of posting them, I forgot
2019-02-24 17:57:02 <AinNero> who does deprive who?
2019-02-24 17:57:53 <Mis012[m]> AinNero: the tool is commented out in the install phase upstream (bluez)
2019-02-24 18:00:31 <AinNero> i dont see the code for that
2019-02-24 18:04:48 <Mis012[m]> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=56178b62564b26d3ff033fe7f5cae600e8826144
2019-02-24 18:06:25 <AinNero> why do you think someone from this channel would know?
2019-02-24 18:07:34 <AinNero> you should ask upstream
2019-02-24 18:08:25 <Mis012[m]> I don't think it will be reverted upstream, and this is the distribution where I personally need it
2019-02-24 18:08:26 <Mis012[m]> Arch ovewrites it downstream as well
2019-02-24 18:11:21 <AinNero> ah, so you want a patch included
2019-02-24 18:12:42 <Mis012[m]> <freenode_Ain "ah, so you want a patch included"> If you agree it's a good solution
2019-02-24 18:12:53 <Mis012[m]> damn, matrix reply
2019-02-24 18:12:55 <Mis012[m]> sorry
2019-02-24 18:14:39 <AinNero> im just a nobody here
2019-02-24 18:36:51 <_ikke_> can someone review this before I push this? https://github.com/alpinelinux/aports/pull/6470
2019-02-24 19:26:23 <_ikke_> I've pushed this to master, but it remains open: https://github.com/alpinelinux/aports/pull/6458
2019-02-24 19:59:34 <kaniini> it seems musl 1.1.21 breaks erlang
2019-02-24 19:59:41 <kaniini> very annoying
2019-02-24 21:52:03 <mps> jwh: did you tested android-tools on armhf or armv7
2019-02-24 21:53:01 <jwh> they're the same thing
2019-02-24 21:53:43 <jwh> just different name depending who you ask
2019-02-24 21:54:28 <mps> well, I mean build on armhf or armv7
2019-02-24 21:54:47 <jwh> same answer
2019-02-24 21:54:48 <jwh> lol
2019-02-24 21:55:17 <mps> and are they same thing is for arguments which I wont pursue here :)
2019-02-24 21:55:55 <jwh> probably armhf
2019-02-24 21:55:59 <jwh> whatever the default is
2019-02-24 21:56:01 <mps> anyway, on which arch you tested it
2019-02-24 21:56:26 <jwh> abuild:~# apk --print-arch
2019-02-24 21:56:27 <jwh> armhf
2019-02-24 21:56:34 <mps> eh, nice
2019-02-24 21:57:09 <mps> I finished building apk's on aarch64 and armv7
2019-02-24 21:57:27 <jwh> oh cool aarch64 just has the same warning right?
2019-02-24 21:58:11 <jwh> I've been using mine with adb for server type things, works fine
2019-02-24 21:58:17 <mps> and preparing patch for APKBUILD, asked you because want to add armhf in arch's and in flags in APKBUILD
2019-02-24 21:58:52 <mps> yes, both aarch64 and armv7 needs that flag
2019-02-24 21:58:58 <jwh> if it builds on one it will build on the other
2019-02-24 21:59:07 <jwh> so all good
2019-02-24 21:59:16 <jwh> are you going to add that flag conditionally based on arch?
2019-02-24 21:59:16 <mps> but I don't have armhf to test if build works on it
2019-02-24 21:59:22 <jwh> or just do it for every arch
2019-02-24 21:59:46 <mps> case "$CARCH" in ... etc
2019-02-24 21:59:47 <jwh> not sure if its worth "fixing" (silencing)
2019-02-24 22:00:02 <jwh> gcc should figure it out
2019-02-24 22:00:13 <mps> look here http://tpaste.us/jXv5
2019-02-24 22:01:07 <mps> maybe would be better to paste just diff?
2019-02-24 22:01:18 <jwh> looks good
2019-02-24 22:01:37 <jwh> *) as well
2019-02-24 22:01:39 <mps> diff is here http://tpaste.us/DL8a
2019-02-24 22:01:54 <jwh> and just remove it from the cmake args
2019-02-24 22:02:02 <jwh> because...
2019-02-24 22:02:19 <jwh> non-armhf/aarch64 will have empty CXXFLAGS
2019-02-24 22:02:40 <mps> sure?
2019-02-24 22:02:43 <jwh> or rather, empty in that apkbuild
2019-02-24 22:02:54 <jwh> but if anyone wants to add other flags they'll have to change it
2019-02-24 22:03:13 <mps> you are right, because it will use defaults, I think
2019-02-24 22:03:14 <jwh> doesn't really matter, just neater
2019-02-24 22:03:42 <jwh> might want to add the same for CFLAGS
2019-02-24 22:03:46 <mps> but don't like to mess with ncopa's work to much :)
2019-02-24 22:04:11 <mps> it is not needed for CFLAGS
2019-02-24 22:04:49 <jwh> yeah I know, but it means it doesn't need to be done if anything else needs adding (ime)
2019-02-24 22:06:28 <mps> my principle in change software is to be least possibly intrusive, i.e. step by step
2019-02-24 22:07:26 <jwh> heh, I'm a fan of parity, doesn't really matter though
2019-02-24 22:08:13 <mps> for your pleasure I will try without flags on x86_64
2019-02-24 22:08:53 <jwh> lol
2019-02-24 22:09:08 <jwh> I'm all good as long as its built :D
2019-02-24 22:10:37 <mps> it uses c++ so CFLAGS are actually irrelevant there
2019-02-24 22:11:12 <mps> I mean, only c++
2019-02-24 22:11:23 <jwh> yeah, I meant for completeness
2019-02-24 22:12:19 <mps> it build on x86_64 with this APKBUILD http://tpaste.us/Bo89
2019-02-24 22:12:47 <mps> removed these two lines with CFLAGS and CXXFLAGS
2019-02-24 22:13:53 <mps> I thought it will, and they really are not needed there as you wrote, but again I don't like to mess what ncopa done
2019-02-24 22:14:00 <mps> nothing more
2019-02-24 22:15:28 <jwh> I didn't say remove them
2019-02-24 22:15:58 <jwh> I said they should have parity, as in if you have a case for CXXFLAGS, also include CFLAGS
2019-02-24 22:16:18 <jwh> personal preference, so up to you
2019-02-24 22:17:06 <mps> no, I wanted to ask you will you send patched APKBUILD or I
2019-02-24 22:17:33 <jwh> oh
2019-02-24 22:17:50 <jwh> I'm easy either way
2019-02-24 22:17:56 <jwh> you can take it if you want
2019-02-24 22:19:08 <mps> how do you say 'alea jacta est'
2019-02-24 22:20:59 <jwh> the die is cast?
2019-02-24 22:21:16 <jwh> "it is done"
2019-02-24 22:21:23 <mps> however you want, you discovered solution I just fixed APKBUILD and tested on few arch's
2019-02-24 22:22:28 <jwh> I'm watching the race atm, so I can do it in a couple of hours if you don't
2019-02-24 22:23:07 <mps> probably better translation to English is 'the dice is cast' of the Caeser's 'Alea iacta est'
2019-02-24 22:23:51 <jwh> well, dice is plural
2019-02-24 22:23:52 <jwh> die is singular
2019-02-24 22:24:08 <jwh> the translation is 'die'
2019-02-24 22:25:31 <mps> ah, thanks for explanation, I'm learning every day
2019-02-24 22:25:58 <mps> btw, it works on aarch64
2019-02-24 22:26:02 <jwh> ah cool
2019-02-24 22:27:10 <mps> to not burden you more I will take responsibility to post patch, you enjoy watching race
2019-02-24 22:28:17 <mps> if you agree, of course
2019-02-24 22:28:54 <danieli> dlsym: Resource temporarily unavailable
2019-02-24 22:28:55 <danieli> hm, on erlang
2019-02-24 22:29:05 <jwh> mps: yeah no problem, thanks
2019-02-24 22:29:25 <jwh> race is just about over anyway, my driver is falling back :(
2019-02-24 22:31:20 <mps> meh, so we are at the start. to repeat if you want to make patch and send please do, you found solution and credits belong to you, I just helped a little
2019-02-24 22:32:13 <jwh> just send a PR, no worries
2019-02-24 22:32:45 <mps> huh, ok, will do in minutes
2019-02-24 22:34:24 <mps> oh, sorry, you have github account? if so then please do it because I don't have and I have to send to patchworks.a.o and that is slower process for patches
2019-02-24 22:35:01 <jwh> oh
2019-02-24 22:35:02 <mps> I'll make APKBUILD with armhf and post it to tpaste for you
2019-02-24 22:35:10 <jwh> yeah I can do it
2019-02-24 22:37:56 <mps> wait few seconds for just one build cycle
2019-02-24 22:38:27 <jwh> ok
2019-02-24 22:40:46 <mps> here it is: http://tpaste.us/xpQJ
2019-02-24 22:42:58 <jwh> thanks, I'll do it soon
2019-02-24 23:02:18 <jwh> hm
2019-02-24 23:02:24 <jwh> I think you cut some bits out
2019-02-24 23:02:48 <jwh> oh
2019-02-24 23:02:58 <jwh> I completely missed its a diff :D
2019-02-24 23:08:34 <mps> what is needed for PR? complete file or diff
2019-02-24 23:09:26 <jwh> it's ok I was being dumb
2019-02-24 23:09:34 <jwh> drone is nice, more architectures
2019-02-24 23:09:48 <jwh> https://github.com/alpinelinux/aports/pull/6472
2019-02-24 23:10:34 <jwh> oh
2019-02-24 23:10:49 <jwh> mps: CXXFLAGS are needed it seems
2019-02-24 23:11:35 <jwh> or the x86 builder is broken, hm
2019-02-24 23:12:00 <mps> I didn't remove CXXFLAGS
2019-02-24 23:12:11 <jwh> oh, right
2019-02-24 23:12:17 <jwh> sorry, apparently I'm not all here
2019-02-24 23:12:55 <jwh> ehhh, no excuse for 32bit x86 anymore anyway :D
2019-02-24 23:13:00 <mps> meh, forgot to bump pkgrel
2019-02-24 23:13:09 <jwh> I'll bump it
2019-02-24 23:13:37 <mps> I don't have x86 build box
2019-02-24 23:14:11 <mps> maybe I should add lxc x86 container
2019-02-24 23:15:13 <jwh> me neither
2019-02-24 23:15:22 <jwh> I don't think it's related though
2019-02-24 23:15:28 <jwh> I mean, it can't be
2019-02-24 23:16:23 <jwh> x86 builder output is openssl linking related
2019-02-24 23:16:39 <jwh> not I said the walrus
2019-02-24 23:19:55 <mps> walrus? sorry I'm self taught in English and seems that the English is your native language and I don't understand your fine points quite well
2019-02-24 23:20:26 <mps> to me walrus is polar animal and nothing more
2019-02-24 23:22:03 <jwh> I don't think it's really a saying
2019-02-24 23:22:46 <jwh> just means "not me"
2019-02-24 23:23:24 <jwh> or not anything, really lol
2019-02-24 23:24:19 <mps> sorry, can't get it, but never mind, all good :)
2019-02-24 23:24:56 <jwh> It was a line from a British TV show, I think it was a reference to a poem from alice in wonderland but I do not know literature that well
2019-02-24 23:26:31 <mps> I like Alice in wonderland, but read it just translated and not original
2019-02-24 23:27:18 <jwh> heh
2019-02-24 23:28:16 <jwh> hm, looks like force pushing kills the drone checks on the PR?
2019-02-24 23:28:46 <mps> go to work, if it cannot be built on x86 I will spin x86 lxc tomorrow and try
2019-02-24 23:29:16 <mps> some time I already contemplating to spin x86 container
2019-02-24 23:29:48 <jwh> I can spin one up, I don't think it's related though... none of the build options actually changed and its openssl related aaaaannnnd its fine on x86_64
2019-02-24 23:31:08 <mps> here is late now, going to drink a glass of wine and go to bed
2019-02-24 23:31:38 <jwh> ok, night
2019-02-24 23:32:04 <mps> good night to you and all
2019-02-25 06:25:46 <grey_geek> I would like to install aarch64 on RPI3.  I did find the instructions here https://wiki.alpinelinux.org/wiki/Raspberry_Pi for the armhf (32bit) but not for aarch64
2019-02-25 07:00:20 <jwh> not a development question, grey_geek
2019-02-25 09:28:21 <AinNero> uhm, does alpine have official ZFS support?
2019-02-25 09:28:32 <AinNero> i'd like to add some test cases for setting up and using ZFS
2019-02-25 09:28:46 <ncopa> i think we sort of have
2019-02-25 09:28:54 <ncopa> i think we announced ZFS in some release notes
2019-02-25 09:30:06 <AinNero> hm, in 3.5.0
2019-02-25 09:30:45 <ncopa> seems like we dont have _FORTIFY_SOURCE in our default clang
2019-02-25 09:31:06 <ncopa> and it does not look like fortify-headers work at all with clang
2019-02-25 11:18:20 <clandmeter> ncopa: any problem with https://tpaste.us/oaDq ?
2019-02-25 11:26:27 <ncopa> what is the usecase for it?
2019-02-25 11:26:33 <_ikke_> drone.io color output
2019-02-25 11:26:49 <_ikke_> Was about to mention that :D
2019-02-25 11:27:39 <ncopa> clandmeter: i guess it is ok
2019-02-25 11:28:47 <ncopa> i think we may need disable FORTIFY_SOURCE in qemu
2019-02-25 11:30:02 <_ikke_> ncopa: as a result of that qemu bug?
2019-02-25 11:30:07 <ncopa> yes
2019-02-25 11:30:23 <ncopa> the problem is that they depend on atomic operations some places
2019-02-25 11:30:34 <ncopa> and support for unaligned other places
2019-02-25 11:30:42 <clandmeter> ncopa: drone doesnt have tty available but it does support colored output. so forcing is the only way i guess.
2019-02-25 11:30:57 <ncopa> and its not clear where atomic is needed and where unaligned is needed
2019-02-25 11:31:47 <ncopa> the current imlpementation for unaligned access happens to be atomic too on most systems so they use that
2019-02-25 11:59:17 <ncopa> stateless: It seems that the fortify-headers implementation breaks qemu. I wonder if we could use __builtin_memcpy instead of __orig_memcpy
2019-02-25 11:59:47 <ncopa> stateless: see this email thread: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06183.html
2019-02-25 12:56:30 <stateless> ncopa: aha yeah possibly
2019-02-25 12:56:41 <mps> clandmeter: I put you in Assignee field of the issue 10034 because you are maintainer of the libxml2. Is that ok?
2019-02-25 12:56:53 <stateless> ncopa: do you have a local patch for this at the moment?
2019-02-25 12:57:31 <ncopa> stateless: i didnt dare to change fortify-headers, i just changed qemu for now
2019-02-25 12:57:34 <stateless> ok
2019-02-25 12:57:53 <ncopa> https://git.alpinelinux.org/aports/commit/?id=228579f6c7663dc4107b1b418367e968513277f9
2019-02-25 12:58:14 <ncopa> stateless: but i think it has impact on perfomance in all other packages
2019-02-25 12:58:22 <stateless> ncopa: does this affect other calls to memcpy in fortify headers?
2019-02-25 12:58:25 <stateless> or only the memcpy override
2019-02-25 12:58:29 <ncopa> i dont know
2019-02-25 12:58:32 <stateless> ok
2019-02-25 12:59:20 <ncopa> i also dont know the sideeffects it may have to call __builtin_memcpy directly from fortify-headers
2019-02-25 13:00:59 <mps> patch which closes #10034 is here: https://patchwork.alpinelinux.org/patch/4526/
2019-02-25 13:03:05 <stateless> ncopa: http://ix.io/1BZL
2019-02-25 13:03:12 <stateless> i will add some more info into the commit once i understand the issue
2019-02-25 13:03:43 <stateless> so qemu depends on certain atomicity guarantees that are not provided if you just call memcpy() but instead are guaranteed if you call __builtin_memcpy()?
2019-02-25 13:05:52 <ncopa> well, it is a bug in qemu, which uses a function that is supposed to be guaranteed to work on unaligned addresses, but does not really guarantee to be atomic
2019-02-25 13:06:17 <ncopa> it is implicitly atomic due to gcc optimizes away the memcpy call
2019-02-25 13:06:34 <ncopa> and some parts of qemu depends on this behavior
2019-02-25 13:06:49 <ncopa> so its qemu that is broken basically
2019-02-25 13:07:50 <stateless> aha i see
2019-02-25 13:08:01 <ncopa> what i discovered while analyzing this is that with fortify-headers, gcc does not optimize away the memcpy call, which may have effect on performance
2019-02-25 13:08:03 <stateless> ncopa: ok however, there is still a possible performance regression in fortify
2019-02-25 13:08:08 <stateless> yes
2019-02-25 13:08:09 <ncopa> exactly
2019-02-25 13:08:30 <stateless> ok i will create a patch for fortify that uses builtins
2019-02-25 13:09:31 <ncopa> there is assembly output here: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg06583.html
2019-02-25 13:11:00 <ncopa> what i notice is that gcc does not perform the bounds check at all on debian and fedora with -D_FORTIFY_SOURCE=2
2019-02-25 13:11:07 <ncopa> it gets optimized away
2019-02-25 13:12:22 <ncopa> $ sh -x test.sh -O2 2>&1| tpaste
2019-02-25 13:12:22 <ncopa> http://tpaste.us/Kgzb
2019-02-25 13:12:50 <ncopa> that is when I modify fortify-headers to use __builtin_memcpy
2019-02-25 13:13:41 <ncopa> note that there are no call to memcpy function there, but it still does the check, where glibc implementation does not
2019-02-25 13:13:47 <stateless> aha
2019-02-25 13:16:08 <ncopa> i dont know if that is "fixable", or if its deisred to fix that
2019-02-25 13:17:51 <stateless> ncopa: http://ix.io/1BZQ
2019-02-25 13:17:54 <stateless> a preliminary patch i suppose
2019-02-25 13:19:11 <stateless> do you want to include that as an external patch in your fortify-headers package, run with it for a while and then I can push it upstream and generate a new release?
2019-02-25 13:28:27 <ncopa> Yeah, i can do that
2019-02-25 13:32:53 <ncopa> i wonder if we should drop the check if size is less than 4 or similar
2019-02-25 13:33:09 <ncopa> i wonder how/why the check is optimized away on glibc
2019-02-25 13:35:50 <ncopa> another thing i discovered is that FORTIFY_SOURCE=2 does not work with clang at all
2019-02-25 13:37:06 <ncopa> i guess we need patch clang for that
2019-02-25 13:40:14 <stateless> ncopa: aha i see, i can have a look at that
2019-02-25 13:40:24 <stateless> i remember it was broken with clang
2019-02-25 13:40:49 <stateless> i think this __builtin_va_arg_pack() ro similar
2019-02-25 13:40:51 <stateless> iirc
2019-02-25 13:41:59 <ncopa> and i think an equivalent to this is missing for clang too: https://git.alpinelinux.org/aports/tree/main/gcc/gcc-4.9-musl-fortify.patch
2019-02-25 13:43:06 <stateless> yeah possibly
2019-02-25 13:50:01 <ncopa> fcolista: i think py-pandas is broken for some reason
2019-02-25 13:50:13 <ncopa> it does not look like it creates the expected subpackages
2019-02-25 13:50:26 <ncopa> i dont know why
2019-02-25 13:51:10 <fcolista> ncopa, ok
2019-02-25 13:51:12 <fcolista> going to check
2019-02-25 13:55:27 <ncopa> fcolista: also have a look at this if you can: https://github.com/alpinelinux/aports/pull/6251
2019-02-25 13:56:47 <fcolista> pk
2019-02-25 14:03:02 <ncopa> i think im gonna disable py-pandas package meanwhile, it makes the builders busy all the time
2019-02-25 14:03:59 <ncopa> actually, im gonna revert it
2019-02-25 14:04:00 <fcolista> yes it takes forever..
2019-02-25 14:55:22 <ncopa> stateless: apparently someone else has noticed fortify-source behavior: http://lists.alpinelinux.org/alpine-devel/6448.html
2019-02-25 14:56:31 <stateless> yeah
2019-02-25 14:56:40 <stateless> well hopefully with builtin_memcpy things are better performance wise
2019-02-25 20:23:46 <Mis012[m]> ncopa: Hi, I see you're the maintainer of bluez, do you think it would be possible to patch it to install btmgmt?
2019-02-25 20:43:12 <ncopa> Mis012[m]: i guess I can do that. Are there any other distro that does that, so I can have a look at how they do it?
2019-02-25 20:44:12 <Mis012[m]> ncopa: Arch linux I believe.
2019-02-25 20:45:22 <_ikke_> /usr/bin/btmgmt is owned by bluez-utils
2019-02-25 20:45:25 <_ikke_> (on archlinux)
2019-02-25 20:46:00 <danieli> +1
2019-02-25 20:50:13 <ncopa> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/bluez#n100
2019-02-25 20:50:21 <ncopa> i wonder if its broken from upstram
2019-02-25 20:50:32 <ncopa> s/upstram/supstream/
2019-02-25 20:53:10 <ncopa> noinst_PROGRAMS += tools/btmgmt tools/obex-client-tool tools/obex-server-tool \
2019-02-25 20:53:11 <ncopa>                         tools/bluetooth-player tools/obexctl
2019-02-25 20:53:11 <ncopa>                                                                  
2019-02-25 20:53:24 <_ikke_> Why do they mark it as noinst?
2019-02-25 20:54:17 <Mis012[m]> they believe it's an internal debbuging tool and they believe that's a reason to not install it
2019-02-25 20:54:53 <Mis012[m]> but there are certain needed features of it that are not available otherwise
2019-02-25 20:55:13 <ncopa> i think it would be good to report it upstream
2019-02-25 20:55:27 <ncopa> i dont know which of the tools that should be installed or not
2019-02-25 20:56:12 <Mis012[m]> This one is needed to make bluetooth work on some devices
2019-02-25 20:56:41 <ncopa> Mis012[m]: i would appreciate if you could create an issue on bugs.a.o with the details. Then I can point to those details when I ask upstream about it
2019-02-25 20:56:59 <jwh> if you're adding tools, can you add back all the "deprecated" ones that aren't infact deprecated as they're still maintained enough to work and don't have any replacement because bluez is an embarassing disaster
2019-02-25 20:57:02 <jwh> :D
2019-02-25 20:57:36 <_ikke_> archlnux has a legacy package
2019-02-25 20:57:40 <jwh> yeah
2019-02-25 20:58:23 <jwh> this is an upstream problem though, calling them legacy or deprecated is absurd, as there is no replacement for them
2019-02-25 20:58:32 <jwh> maybe the meant "regression"
2019-02-25 20:58:36 <ncopa> alpine has bluez-deprecated
2019-02-25 20:58:43 <ncopa> re btmgmt: https://www.spinics.net/lists/linux-bluetooth/msg70148.html
2019-02-25 20:58:58 <jwh> yeah but really, shouldn't be
2019-02-25 20:59:19 <Mis012[m]> ncopa: I know of one usecase, I'm sure there are more but their response to a similar request has been "if you really need it, do it downstream" which is what Arch did I guess
2019-02-25 20:59:59 <ncopa> apparently they made it install by default in 2017
2019-02-25 21:00:38 <mps> hmm, I wouldn't take Arch as reference, there are a lot of cruft
2019-02-25 21:01:19 <jwh> pick and choose :D
2019-02-25 21:01:58 <mps> jwh: no, Arch is good distro but not a reference
2019-02-25 21:02:12 <jwh> yes
2019-02-25 21:02:18 <mps> that is just my opinion, nothing more
2019-02-25 21:02:26 <ncopa> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/Makefile.tools?id=56178b62564b26d3ff033fe7f5cae600e8826144
2019-02-25 21:02:59 <ncopa> it does not look like fedora is installing btmgmt either
2019-02-25 21:03:11 <_ikke_> "There are plans, so we remove them already before we implemented said plans"
2019-02-25 21:03:13 <_ikke_> right
2019-02-25 21:04:01 <_ikke_> makes a lot of sense
2019-02-25 21:04:08 <Mis012[m]> ncopa: I linked that about 100 posts earlier.
2019-02-25 21:04:25 <Mis012[m]> ikke: yeah, my exact reaction
2019-02-25 21:04:58 <jwh> "Don't install btmgmt as there are plans for other tools to cover the likes of hciconfig, etc."
2019-02-25 21:05:01 <jwh> ah yes
2019-02-25 21:05:02 <Mis012[m]> ncopa: but I didn't pay any attention to dates, stupid me. thanks for the full timeline
2019-02-25 21:05:06 <jwh> like the ~7 other utilities
2019-02-25 21:05:21 <jwh> 3 years or something, none have been replaced
2019-02-25 21:06:02 <Mis012[m]> why can't we have nice things...
2019-02-25 21:06:15 <jwh> because nobody has ported android bluertooth yet
2019-02-25 21:06:18 <jwh> bluetooth*
2019-02-25 21:06:29 <ncopa> i had similar problem years ago
2019-02-25 21:06:40 <ncopa> a bit after bluez5 was out
2019-02-25 21:06:46 <Mis012[m]> <freenode_jwh "because nobody has ported androi"> android bluetooth solely exists because GPL afaik
2019-02-25 21:06:49 <ncopa> i could not attach bt keyboards
2019-02-25 21:07:11 <ncopa> i ended up start writing xfce-bluetooth
2019-02-25 21:07:17 <jwh> android ditched bluez because it was a waste of space and wrote their own
2019-02-25 21:07:19 <jwh> but its still gpl
2019-02-25 21:07:27 <jwh> and is probably not that hard to port
2019-02-25 21:07:38 <Mis012[m]> <freenode_jwh "but its still gpl"> wow what?
2019-02-25 21:07:42 <ncopa> but as soon i got my bt keyboard paried i lost motivation to finish xfce-bluetooth :)
2019-02-25 21:07:48 <jwh> or parts of it were
2019-02-25 21:08:05 <Mis012[m]> <freenode_jwh "and is probably not that hard to"> we need to fix bluez, not port Google's android stuff
2019-02-25 21:08:16 <Mis012[m]> <freenode_jwh "or parts of it were"> uh hm
2019-02-25 21:08:37 <jwh> nobody can fix bluez, they're still going backwards
2019-02-25 21:08:57 <ncopa> i should continue tomorrow
2019-02-25 21:09:10 <ncopa> Mis012[m]: please file a bug on bugs.a.o or i will forget about it
2019-02-25 21:09:19 <Mis012[m]> jwh: so fork?
2019-02-25 21:09:41 <Mis012[m]> ncopa: thanks for a reminder, I forgot already :(
2019-02-25 21:10:02 <ncopa> nice to hear that its not only me who forgets about things :)
2019-02-25 21:10:16 <jwh> you'd have to fork, either build on bluez4 which actually worked to a reasonable degree, or fork 5 and forward port a load of stuff
2019-02-25 21:10:20 <jwh> and it'll still be a mess
2019-02-25 21:15:06 <jwh> oh
2019-02-25 21:15:20 <jwh> it looks like building the android stack on linux proper was actually supported previously
2019-02-25 21:15:27 <jwh> interesting
2019-02-25 21:15:49 <_ikke_> ncopa: would it be a problem to run setup.py build_ext --inplace in a check stage? Running tests for py-zmq apparently requires that
2019-02-25 21:21:23 <ncopa> dunno what build_ext --inplace does and im on my way away from key
2019-02-25 21:21:27 <ncopa> keyb
2019-02-25 21:21:43 <ncopa> not healty sit so long day with keyboard
2019-02-25 21:22:08 <_ikke_> it builds the library in place so that it can used from the sourcedir (for testing)
2019-02-25 21:22:51 <ncopa> should note be any problem as long as it does not gets installed that way
2019-02-25 21:22:52 <_ikke_> afaik it does not affect the actual build, but it's a seperate build, but I'm not entirely sure
2019-02-25 21:22:58 <_ikke_> yeah
2019-02-25 21:23:00 <_ikke_> Was comparing
2019-02-25 21:26:34 <_ikke_> ncopa: if I look at the files that end up in pkg/ they are the same, so I don't think it would change that
2019-02-25 21:40:44 <SpaceToast> might have a new lxd bug, fcolista are you around?
2019-02-25 21:43:45 <jwh> oh good
2019-02-25 21:43:48 <jwh> I love lxd bugs
2019-02-25 21:44:14 <jwh> that hash I made has some issues btw, but theres no way I'm digging into that horribleness when a new version will be out
2019-02-25 21:44:33 <jwh> at least, I think they're related... may not be
2019-02-25 21:51:35 <SpaceToast> when I set up clustering (excite, eh?), it fails to bind to the address/port combo
2019-02-25 21:51:43 <SpaceToast> claiming it's already use
2019-02-25 21:51:50 <SpaceToast> I suspect it's being used by itself, for remote as is though
2019-02-25 21:56:06 <jwh> oh
2019-02-25 22:29:39 <SpaceToast> ncopa: pingu's route handling is great, but it breaks nat; any suggestions?
2019-02-25 22:40:13 <SpaceToast> Nvm, looks like you just need to set the IP rule priority to be > built-in tables
2019-02-25 22:40:32 <SpaceToast> (I suspect that your workaround for source-pings doesn't actually matter/isn't needed)
2019-02-25 23:01:00 <SpaceToast> re: lxd I guess I'll just not do a cluster yet (I only have two hosts anyway, and it's recommended to have at least 3)
2019-02-25 23:08:33 <jwh> I went with arch on my production (yeah yeah) lxd hosts in the end, couldn't wait around and hope they get it right
2019-02-25 23:08:46 <jwh> but I still have a test one at home
2019-02-25 23:09:29 <jwh> trying to find some cheap boxes atm for lab stuff, closer to 5VDC the better heh (tablet type socs etc)
2019-02-25 23:18:33 <SpaceToast> for me it was more ubuntu (canonical *is* devving lxd) or alpine
2019-02-25 23:18:52 <SpaceToast> ended up picking alpine
2019-02-25 23:18:56 <SpaceToast> about to finish getting it working
2019-02-25 23:19:59 <jwh> I just cannot stand debian/ubuntu, so arch or alpine heh
2019-02-25 23:20:30 <jwh> fine on containers for convenience when upstream projects supply apt repos (like mysql etc), otherwise nah
2019-02-25 23:24:26 <SpaceToast> ah
2019-02-25 23:24:32 <SpaceToast> lxd is my primary infrastructure handler
2019-02-25 23:24:37 <SpaceToast> ^^;;
2019-02-25 23:24:43 <SpaceToast> (at home, and now also at work)
2019-02-25 23:25:06 <SpaceToast> I can't stand libvirt, lxc solo is a pain in so many ways, and docker/k8s are... special, and don't fit a lot of use-cases (that I often have)
2019-02-25 23:25:18 <jwh> pretty much the same
2019-02-25 23:25:38 <SpaceToast> so lxd is less convenience and more "something I'm actually going to use a lot" :)
2019-02-25 23:25:44 <jwh> libvirt is broken anyway with lxc atm, far too many bugs with kvm too, but also I'm trying to go for containers
2019-02-25 23:25:52 <SpaceToast> yeah I recall this conversation
2019-02-25 23:25:53 <jwh> and k8s does not fit my design at all either
2019-02-25 23:26:01 <SpaceToast> it's really too bad lxd has the occasional problems
2019-02-25 23:26:06 <SpaceToast> because it's really the optimal interface
2019-02-25 23:26:09 <jwh> yeah
2019-02-25 23:26:17 <jwh> also easy rest api+++
2019-02-25 23:26:38 <jwh> pretty much a requirement for anything new I build - gotta have a sensible API I can hook up to my monitoring etc
2019-02-25 23:29:07 <jwh> what do you use your containers for?
2019-02-25 23:35:08 <SpaceToast> basically everything?
2019-02-25 23:35:17 <jwh> lol fair enough
2019-02-25 23:35:26 <SpaceToast> anything that should be a server is a container, except for the gateway/dhcp/tftp/dns server (which is a single physical machine)
2019-02-25 23:35:30 <jwh> kinda meant in what setting (home, work etc)
2019-02-25 23:35:38 <SpaceToast> all other physical servers are lxd hosts, and host all the actual stuff
2019-02-25 23:35:43 <SpaceToast> home *and* work, yes ;)
2019-02-25 23:35:49 <jwh> ah
2019-02-25 23:35:52 <SpaceToast> at home I have a single dual-socket system
2019-02-25 23:36:02 <SpaceToast> @ work (where I am now) I was trying to get a cluster running, but no luck
2019-02-25 23:36:12 <SpaceToast> I have a hunch as to what I'm supposed to do and have decided I don't feel like doing it though
2019-02-25 23:36:22 <jwh> lol
2019-02-25 23:36:28 <SpaceToast> but a bunch of remote-connected lxd hosts are fine too :)
2019-02-25 23:36:42 <jwh> I'm not clustering atm due to the shared storage requirement
2019-02-25 23:36:49 <jwh> and I don't really wanna run ceph on the lxd hosts
2019-02-25 23:37:23 <SpaceToast> you don't have to run ceph
2019-02-25 23:37:29 <jwh> but... I build all the applications to fail, so they just have multiple instances
2019-02-25 23:37:31 <SpaceToast> you just need to have the same storage topography
2019-02-25 23:37:42 <jwh> yeah
2019-02-25 23:37:52 <SpaceToast> but yeah, as an example, here's my @home topography (excluding clients)
2019-02-25 23:38:42 <SpaceToast> heimdall => gateway/tftp/dhcp etc; sauron => lxd host (everything from now on are containers); magni => builder; alfred => web server; gabriel => weechat relay host
2019-02-25 23:39:12 <jwh> ah cool
2019-02-25 23:39:15 <SpaceToast> since you can use cgroups to specify basically any restriction (even more than virt in some cases, like num of procs allowed), I just use it as a much easier to access libvirt
2019-02-25 23:39:25 <jwh> yeah
2019-02-25 23:39:31 <SpaceToast> (e.g alfred is limited to 1 cpu core and 1gb ram, magni... not so much)
2019-02-25 23:40:10 <jwh> I'm not using restrictions atm, it's really just a convenient way to seperate/isolate applications
2019-02-25 23:40:22 <jwh> same at home really
2019-02-25 23:40:48 <jwh> but being able to limit resources is useful for my production stuff
2019-02-25 23:41:30 <SpaceToast> yeah :)
2019-02-25 23:45:08 <jwh> just need to get the orchestration down for alpine containers + config etc
2019-02-26 00:36:18 <jwh> hm, can I trigger another drone build for a PR without pushing?
2019-02-26 00:36:24 <jwh> https://cloud.drone.io/alpinelinux/aports/75/1/2
2019-02-26 00:36:34 <jwh> looks like the builder was/is broken?
2019-02-26 00:37:48 <jwh> oh hm
2019-02-26 00:38:15 <jwh> nope
2019-02-26 00:46:14 <mps> jwh: do you know where is the problem? which arch?
2019-02-26 00:47:05 <jwh> i386
2019-02-26 00:47:15 <jwh> just starting a builder to look
2019-02-26 00:47:22 <jwh> but I don't think it's related
2019-02-26 00:47:40 <mps> ah yes. i586
2019-02-26 00:49:00 <jwh> well, I will as soon as sshd starts
2019-02-26 00:49:02 <jwh> 
ACTION rollseyes

2019-02-26 00:49:11 <jwh> systemd is such a pain in the dick
2019-02-26 00:49:31 <mps> why it is i586, shouldn't it be x86
2019-02-26 00:50:00 <jwh> dunno
2019-02-26 00:50:05 <mps> systemd? drone uses systemd? ughhh
2019-02-26 00:50:07 <jwh> no
2019-02-26 00:50:15 <jwh> my x86 lxd host does
2019-02-26 00:51:18 <mps> I had electricity outage this morning, till 15:00 so didn't installed x86 lxc container
2019-02-26 00:51:49 <mps> electric company had some works on their cables
2019-02-26 00:52:15 <mps> hope I will find some time tomorrow
2019-02-26 00:52:56 <mps> could you start drone on just one arch? i.e. skip x86
2019-02-26 00:53:14 <mps> for now, I mean, we will test it anyway
2019-02-26 00:53:36 <jwh> I was trying to find an option to kick a build off but I don't think I can
2019-02-26 00:55:28 <mps> hmm, I had a day with a lot of my 'business' work, and in Alpine fixed the libxml2 and now testing different versions of crystal lang so don't have time and power to try android-tools on x86
2019-02-26 00:56:49 <mps> if you do not solve this x86 issue we can try tomorrow together, I'm now really tired
2019-02-26 00:57:16 <jwh> yeah I'm kinda busy, got yet another box to piss about with because systemd is a waste of time these days
2019-02-26 00:57:20 <jwh> really starting to not love it so much
2019-02-26 00:57:52 <mps> where you use systemd?
2019-02-26 01:05:26 <SpaceToast> systemd is funny :)
2019-02-26 01:05:42 <SpaceToast> some interesting ideas (as is usual with Lennart), but the details (design and implementation) are just awful
2019-02-26 01:06:14 <SpaceToast> then again, some things williamh does to openrc makes me want to fork it on the regular...
2019-02-26 01:06:26 <mps> I was one of the first users and proponents of systemd :(
2019-02-26 01:06:27 <SpaceToast> maybe one day alpine will be interested in forking it and I'll maintain/dev it ^^;;
2019-02-26 01:06:28 <jwh> its failings are starting to outweight the benefit
2019-02-26 01:06:40 <SpaceToast> mps: well, the idea *is* interesting!
2019-02-26 01:06:57 <jwh> it does this really good thing where it'll start half the system, then drop to an "emergency" console for some unimportant unit
2019-02-26 01:06:58 <SpaceToast> just... lennart bit off more than he could chew, and this time no large group jumped in to save it (like with pulse)
2019-02-26 01:07:08 <jwh> rather than fail early
2019-02-26 01:07:15 <mps> yes, but where it ended is not interesting, really
2019-02-26 01:07:27 <jwh> it could at least provide an ability to unfuck it remoely
2019-02-26 01:07:30 <jwh> remotely*
2019-02-26 01:07:33 <jwh> if it's gonna do stpid shit
2019-02-26 01:07:35 <jwh> stupid*
2019-02-26 01:07:41 <SpaceToast> jwh: you mean ipmi, right? ;)
2019-02-26 01:07:50 <jwh> but... it's still not s bad as busybox/openrc/alpine/whatever :D
2019-02-26 01:08:00 <jwh> slight typo in interfaces, 0 networking
2019-02-26 01:08:10 <SpaceToast> just don't typo in interfaces!
2019-02-26 01:08:15 <SpaceToast> also, you know you can test your config, right?
2019-02-26 01:08:18 <SpaceToast> (ifup -n)
2019-02-26 01:08:18 <mps> it was main force which made me to switch to alpine
2019-02-26 01:08:24 <jwh> it'll fail entirely even if its just an interface that doesn't appear quick enough
2019-02-26 01:08:27 <jwh> like usb
2019-02-26 01:08:38 <jwh> its uh
2019-02-26 01:08:51 <jwh> not really good enough, but thats sysvinit heh
2019-02-26 01:08:53 <SpaceToast> jwh: also, if you have issues with openrc; ping me, I'll help (same with lxd) :)
2019-02-26 01:09:08 <SpaceToast> oh, you can use openrc-init to remove that :^)
2019-02-26 01:09:20 <SpaceToast> it's badly documented, and I'm not touching that codebase unless I get to refactor half of it
2019-02-26 01:09:25 <jwh> it just needs better hotplug, but then init becomes everything else which we already have systemd for
2019-02-26 01:09:28 <jwh> so
2019-02-26 01:10:47 <mps> for some reasons I'm starting to 'dislike' hotplug
2019-02-26 01:11:14 <jwh> whatever is managing the system needs to be able to react to changes in config though
2019-02-26 01:11:24 <jwh> can't just fire it once at boot and hope everything is ready
2019-02-26 01:11:42 <jwh> but using networkmanager is just excessive (and hideous)
2019-02-26 01:11:56 <SpaceToast> I do find it kind of questionable that "usb nic" is coming into question in "can't debug it remotely" scenarios though
2019-02-26 01:12:06 <jwh> was an example
2019-02-26 01:12:14 <mps> 'someone' promised he will package iwd :)
2019-02-26 01:12:26 <jwh> but certainly a case of where hardware might not be ready quick enough
2019-02-26 01:13:06 <SpaceToast> mps: you should whois me at some point, that'll be fun ;)
2019-02-26 01:13:09 <SpaceToast> also I will!
2019-02-26 01:13:14 <SpaceToast> I just have a lot of stuff before it on the todo list :/
2019-02-26 01:13:25 <SpaceToast> for instance, in the last 4 days, I've worked for roughly 44h :D
2019-02-26 01:13:26 <jwh> or if the user plugs in a nic after boot, it's pretty much expected that it'll work these days
2019-02-26 01:13:32 <SpaceToast> wait, 33h*, but still
2019-02-26 01:13:37 <mps> if 'someone' don't have time for iwd, maybe I will do it, i already prepared some thing
2019-02-26 01:13:46 <SpaceToast> feel free :)
2019-02-26 01:13:49 <jwh> is iwd actually an improvement?
2019-02-26 01:13:50 <SpaceToast> do poke me re: openrc though
2019-02-26 01:14:00 <SpaceToast> jwh: it's a massive improvement to wpa_supplicant
2019-02-26 01:14:55 <TBB> surely not featurewise though, wpa_supplicant can handle about a bazillion things
2019-02-26 01:15:03 <mps> i built connman-gtk as add-on to iwd
2019-02-26 01:15:12 <jwh> I think I'd like it better if it didn't look like bluez config
2019-02-26 01:15:18 <jwh> also incidentall an intel fuckup
2019-02-26 01:15:22 <jwh> incidentally*
2019-02-26 01:15:26 <SpaceToast> TBB: I've yet to hear of a use-case that wpa_supplicant covers, but iwd didn't
2019-02-26 01:15:29 <jwh> cli looks like bluetoothctl too
2019-02-26 01:15:51 <SpaceToast> if someone (maybe the one that said they'd try and do so) packaged D that'd be nice too ^^
2019-02-26 01:15:58 <mps> iwd is big step forward, I hope
2019-02-26 01:16:02 <SpaceToast> but gdc is mainlining in gcc-9
2019-02-26 01:16:06 <TBB> SpaceToast: you've surely read through the wpa supplicant example conf? that's a -lot- of ground to cover
2019-02-26 01:16:07 <SpaceToast> so that might make it much easier
2019-02-26 01:16:22 <TBB> 
ACTION is just flapping his lips as usual

2019-02-26 01:16:24 <SpaceToast> TBB: I've read through wpa_supplicant.conf(5)
2019-02-26 01:17:42 <SpaceToast> WPA (personal and enterprise) - check; EAP-PEAP - check, EAP-TTLS - check, 802.1X - check
2019-02-26 01:17:54 <SpaceToast> EAP-TLS as well
2019-02-26 01:17:59 <SpaceToast> so that seems to cover basically everything
2019-02-26 01:18:18 <SpaceToast> but you also get some other stuff, like ad-hoc, being an AP rather than a client, etc
2019-02-26 01:18:37 <mps> SpaceToast: Rust lang eats a lot of my time which I have for Alpine
2019-02-26 01:18:50 <SpaceToast> mps: I can tell :( but you're doing a good job, so that's ok :)
2019-02-26 01:19:02 <SpaceToast> re: someone I meant danieli (who told me they'd try to get dmd and libphobos in)
2019-02-26 01:19:18 <mps> not good as I would like it to be
2019-02-26 01:19:33 <SpaceToast> I can certainly relate to that feeling
2019-02-26 01:19:49 <SpaceToast> still, you're very helpful, and no one's expecting perfection (I hope!)
2019-02-26 01:19:51 <danieli> I did have a look at it but it wasn't trivial
2019-02-26 01:20:00 <SpaceToast> danieli: that's what I was worried about :/
2019-02-26 01:20:03 <danieli> remind me on wednesday when I'm home from work and I'll have another look
2019-02-26 01:20:08 <SpaceToast> alright, sure :)
2019-02-26 01:20:10 <SpaceToast> have you looked at gcc-9 btw?
2019-02-26 01:20:15 <SpaceToast> d is getting mainlined
2019-02-26 01:20:20 <SpaceToast> (might make things easier)
2019-02-26 01:20:28 <danieli> yeah, I heard, but haven't looked it in the seams
2019-02-26 01:20:39 <SpaceToast> I've only kept up with the submission status, not how it's been done
2019-02-26 01:21:33 <mps> also i looked to gcc-9, seems it is in stage to be packaged right now, but I'm not expert on gcc
2019-02-26 01:21:59 <SpaceToast> gcc-9 isn't there yet
2019-02-26 01:22:18 <SpaceToast> in fact, it'll take until 9.3 for proper stability, but I'll be using it from 9.1 (which should come out... at some point?)
2019-02-26 01:22:37 <mps> no, I mean a plans about it
2019-02-26 01:23:04 <SpaceToast> gcc9 stage 1 is April 24
2019-02-26 01:23:42 <SpaceToast> oh wait that was last year
2019-02-26 01:23:48 <SpaceToast> stage 4 was Jan 4
2019-02-26 01:23:52 <SpaceToast> yeah, maybe it'll be 9.1 soon then
2019-02-26 01:24:07 <mps> yes, today is announced 8.3 and when reading bug fixes/improvements to 8.2 it looks hmm, a lot of things not 'fine' in 8.2
2019-02-26 01:24:30 <SpaceToast> GNU are erm... known for their "high quality" software, yes :/
2019-02-26 01:24:39 <SpaceToast> unfortunately, llvm is very unlikely to mainline D
2019-02-26 01:24:46 <mps> hehe, right :)
2019-02-26 01:25:15 <SpaceToast> I see gcc-9:d as a (hopefully) convenient bootstrap tool
2019-02-26 01:26:01 <mps> having experience with all that good software I ask myself 'how anything work at the end'
2019-02-26 01:26:24 <SpaceToast> usually through sheer accident :D
2019-02-26 01:26:44 <SpaceToast> it's sad though, even with the amount of breakages llvm tends to have, it still looks oh so good in face of most GNU things :(
2019-02-26 01:27:13 <mps> I concluded that there must be some $DEITY which cares about all that :)
2019-02-26 01:27:40 <SpaceToast> a friend of mine's convinced I'm a minor deity, and I do care about the random things I make working...
2019-02-26 01:27:55 <SpaceToast> perhaps there are many other people like that that, through collective prayers for things to not fall apart, are keeping the world afloat~
2019-02-26 01:28:11 <SpaceToast> anyway, we've gone offtopic now, I think, and I've resting to attend to :)
2019-02-26 01:28:14 <SpaceToast> \o till tomorrow
2019-02-26 01:29:17 <mps> right, going out to clear air and smoke one cigarette before going to bed. Good night to all
2019-02-26 04:45:27 <bratkartoffel> Can someone please merge https://github.com/alpinelinux/aports/pull/6179 ? I'm finished with the openjdk9, 10 and 11 ports and would love to finally get them into alpine
2019-02-26 07:23:02 <ncopa> bratkartoffel: re openjdk10 and 11: https://github.com/alpinelinux/aports/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+openjdk
2019-02-26 07:32:58 <fcolista> SpaceToast, hi!
2019-02-26 07:37:34 <bratkartoffel_> ncopa: yes, I saw the other PRs by hjaekel. I'm currently taking a look on his changes, but I think he is missing some patches for other archs. I've also branches for 10 and 11 ready to be sent, I just wanted to wait for my 9 to get merged.
2019-02-26 08:12:37 <clandmeter> bratkartoffel: https://cloud.drone.io/alpinelinux/aports/76/1/2
2019-02-26 08:22:52 <ncopa> bratkartoffel_: have a look at his crypto tests
2019-02-26 08:25:14 <ncopa> im gonna push your pr with a few modifications
2019-02-26 08:25:33 <ncopa> the pkgver is 9.0.4_p12
2019-02-26 08:25:47 <ncopa> and i will split the src.zip to its own subpackage
2019-02-26 08:26:23 <ncopa> i also reorder the package splitting so we dont need move back stuff in headless
2019-02-26 08:27:28 <ncopa> i also move the first lines in build() to prepare
2019-02-26 08:27:53 <ncopa> so it is possible to re-run `abuild build` multiple times
2019-02-26 09:04:40 <bratkartoffel_> ncopa: thanks for merging + enhancing this one. I see that the drone build fails due to timeouts von armv7 / armhf and due to a compile error on x86. I'll take a look at this after work.
2019-02-26 10:38:11 <mps> can anyone who have right to do scp upload to dev.alpinelinux.org, trigger snapshot for community/crystal, i.e. 'abuild snapshot'
2019-02-26 10:38:29 <clandmeter> ok
2019-02-26 10:38:39 <fabo> adding a new package to testing is just a matter to submit a PR and get it reviewed?
2019-02-26 10:39:06 <mps> clandmeter: in stable, forgot to add
2019-02-26 10:39:27 <clandmeter> 
ACTION slaps mps with edge snapshot

2019-02-26 10:40:12 <clandmeter> fabo: correct
2019-02-26 10:40:20 <mps> probably will work on edge, but would be better in stable, so we will know it works on stable with libxml2 patch from yesterday
2019-02-26 10:42:01 <fabo> clandmeter: thanks
2019-02-26 10:47:17 <clandmeter> mps: looks like its not using all threads
2019-02-26 10:47:36 <clandmeter> only uses one core
2019-02-26 10:48:57 <mps> right, but didn't wanted to fiddle with this for now
2019-02-26 10:50:15 <mps> I planned to investigate this later (a lot later)
2019-02-26 10:50:40 <clandmeter> ok. its just very slow now.
2019-02-26 10:51:06 <mps> it takes about 30 minutes on my box
2019-02-26 10:52:07 <mps> and, don't forget both arch's, x86_64 and aarch64
2019-02-26 10:52:26 <clandmeter> i dont htink i have a stable aarch64
2019-02-26 10:53:27 <clandmeter> oh i have
2019-02-26 10:53:33 <mps> ok, then on edge.
2019-02-26 10:53:44 <mps> aha, nice
2019-02-26 10:58:14 <clandmeter> upload fails
2019-02-26 10:58:21 <clandmeter> incorrect permissions of the target directory
2019-02-26 11:00:19 <mps> how I can help with this
2019-02-26 11:02:11 <clandmeter> ok i moved x86_64 manually
2019-02-26 11:02:19 <clandmeter> should be available now
2019-02-26 11:02:53 <mps> it is, I see it there
2019-02-26 11:03:05 <clandmeter> aarch64 will take considerably longer.
2019-02-26 11:03:40 <mps> no problem, I'm not in hurry. Thanks for help
2019-02-26 11:33:09 <mps> clandmeter: aarch64 of the crystal static is there. Thanks, now I could start preparing new version APKBUILD
2019-02-26 11:33:57 <clandmeter> yup
2019-02-26 11:47:38 <mps> clandmeter: fyi, forgot to tell that crystal isn't multi-threaded yet
2019-02-26 13:06:39 <ncopa> i think have a way to create vfat release image
2019-02-26 13:06:43 <ncopa> for efi
2019-02-26 13:07:19 <ncopa> would be nice to have an alpine-standard-aarch64.img
2019-02-26 13:07:32 <ncopa> and maybe even x86_64
2019-02-26 13:08:02 <ncopa> it is currently inconvenient to create a bootable efi image
2019-02-26 13:08:07 <ncopa> for aarch64
2019-02-26 13:09:08 <ncopa> i wonder if we should generate a grub.efi for our netboot release
2019-02-26 13:29:15 <ncopa> _ikke_: re community/memtester
2019-02-26 13:29:46 <ncopa> we normally add new packages to testing repo first
2019-02-26 13:30:14 <ncopa> only time when we add directly to community or main is when we update a main or community package that introduces new dependency
2019-02-26 13:37:25 <fabo> ncopa: re aarch64 image with grub efi, what's your issue? we have such oe images for some boards
2019-02-26 13:53:29 <ncopa> fabo: the issue is that it is not trivial to create an alpine efi boot image for aarch64, if you dont have a aarch64 system handy
2019-02-26 13:53:55 <ncopa> none of our aarch64 release images gives you the boot.efi file
2019-02-26 13:54:55 <ncopa> so i was thinkgin that we could ship an alpine-aarch64.img disk image that you can simply dd
2019-02-26 13:55:20 <fabo> ncopa: on oe, we create the boot image on x86. it requires dd/dosfstools/mtools
2019-02-26 13:56:09 <fabo> which dev board is targeted?
2019-02-26 13:56:31 <ncopa> xgene atleast
2019-02-26 13:56:37 <ncopa> would be nice with something generic
2019-02-26 13:56:59 <ncopa> how do you create the grub efi file?
2019-02-26 13:58:17 <ncopa> and how do you create the GPT partitions?
2019-02-26 13:58:50 <fabo> ncopa: with grub-mkimage (https://github.com/96boards/meta-96boards/blob/master/recipes-bsp/grub/grub-efi_2.%25.bbappend)
2019-02-26 13:59:27 <ncopa> ok
2019-02-26 14:00:32 <fabo> ncopa: for the GPT partitions, we use gptfdisk (create an image with dd then use gptfdisk)
2019-02-26 14:01:07 <fabo> it will require some work to make it more generic, but it could be worth looking as a starting point
2019-02-26 14:01:39 <fabo> https://github.com/96boards/meta-96boards/blob/master/recipes-bsp/uefi/edk2-hikey_git.bb
2019-02-26 14:16:31 <_ikke_> ncopa: hmmm, I though it did that, sorry
2019-02-26 14:16:36 <_ikke_> ncopa: Maybe I confused PRs
2019-02-26 14:17:26 <clandmeter> you did
2019-02-26 14:17:32 <clandmeter> just not edited commit msg
2019-02-26 14:22:41 <ncopa> fabo: so as i understand, you generate the efi binary with grub-mkimage, which you mcopy into a fat parition image
2019-02-26 14:23:20 <ncopa> how do you get the fat partition image into the full disk image with GPT?
2019-02-26 14:27:33 <ncopa> looks like you dont
2019-02-26 14:27:52 <ncopa> looks like you create a partition table image, with only the partition table
2019-02-26 14:28:26 <ncopa> so i guess you need to dd if=ptable-linux-4g.img of=/dev/disk
2019-02-26 14:28:38 <ncopa> make kernel reload the partition table on /dev/disk
2019-02-26 14:29:01 <ncopa> and then dd if=boot.img of=/dev/<partition>
2019-02-26 14:33:33 <_ikke_> ncopa: Indeed, I asked the author to move it to testing first, but the commit message wasn't updated
2019-02-26 14:35:58 <ncopa> so it got added to testing but commit message was wrong?
2019-02-26 14:36:44 <ncopa> not a big deal, but we should probably try be consequent on adding packages to testing only
2019-02-26 14:44:52 <_ikke_> yes, I agree
2019-02-26 14:44:57 <_ikke_> And yes, that's the case
2019-02-26 15:09:45 <fabo> ncopa: correct, we don't a single full disk image
2019-02-26 15:10:02 <fabo> +have
2019-02-26 18:38:42 <mps> is it considered as bad manner to post issue to bugs.a.o which will request upgrade of package and after that send patch for upgrade to patchwork.a.o
2019-02-26 18:39:23 <mps> simulating PR on github, actually
2019-02-26 18:39:32 <ncopa> :)
2019-02-26 18:39:45 <ncopa> depends a bit on how important the upgrade is
2019-02-26 18:40:38 <ncopa> mps: which patch is it?
2019-02-26 18:40:53 <ncopa> im trying to prioritize things fro v3.9 branch now
2019-02-26 18:41:03 <ncopa> ie bugfixes
2019-02-26 18:41:10 <mps> hmm, how one knows how it is important. for sender of the patch it is probably important but for other it could totally opposite
2019-02-26 18:41:45 <mps> crystal lang upgrade to 0.27.2, and it is for edge not stable
2019-02-26 18:42:11 <ncopa> ok, then it will have to wait a bit
2019-02-26 18:42:21 <ncopa> also, i woudl like to merge the llvm stuff you did
2019-02-26 18:42:34 <mps> I could send patch to patchwork.a.o but then I have to annoy you and other here about it
2019-02-26 18:42:49 <ncopa> send it to patchwork
2019-02-26 18:42:58 <ncopa> and feel free to annoy me after v3.9.1 is out
2019-02-26 18:43:14 <mps> regarding llvm, they announced version 8.0 for the end of this month
2019-02-26 18:43:26 <ncopa> right, i hope to merge llvm6 this week
2019-02-26 18:43:57 <mps> maybe we could skip llvm6? I don't have strong opinion yet
2019-02-26 18:44:39 <mps> if they release it on time and we test it and everything went fine, I mean
2019-02-26 18:45:26 <mps> but llvm7 is not on the horizon yet, i.e. it looks like it is far behind horizon :)
2019-02-26 18:46:15 <ncopa> and around 1 april we should have a feature freeze
2019-02-26 18:46:22 <mps> llvm 7.1 I mean, huh should look before pressing enter
2019-02-26 18:46:50 <ncopa> so gcc, clang and others should be frozen in the beginning of april
2019-02-26 18:47:27 <ncopa> is it realistic to have rust for more arches before beginning of april?
2019-02-26 18:48:04 <mps> aha, ok. we should consider llvm in a few days. Don't know any package which needs llvm7 or llvm8
2019-02-26 18:48:34 <ncopa> yes, i want do llvm this week
2019-02-26 18:48:42 <ncopa> need to get 3.9.1 out first
2019-02-26 18:48:45 <mps> rust will be ready for armv7 and aarch64, I hope
2019-02-26 18:48:58 <ncopa> i have fixed the release script for armv7 i think
2019-02-26 18:49:12 <mps> it works for some packages but didn't tested it a lot
2019-02-26 18:49:16 <ncopa> and made it generate efi executable for aarch64
2019-02-26 18:49:55 <ncopa> there is still a nasty bug in python3 that affects rpi3 aarch64
2019-02-26 18:50:08 <ncopa> https://bugs.python.org/issue36107
2019-02-26 18:50:34 <mps> I don't know python and have 'fear' to look at python packages
2019-02-26 18:50:36 <ncopa> oh, we should upgrade python to 3.7 also
2019-02-26 18:51:00 <ncopa> its pythons C code thats buggy i think
2019-02-26 18:51:12 <ncopa> sounds like buffer overflow
2019-02-26 18:51:20 <mps> what about iwd? I talked with nice iwd people on #iwd channel
2019-02-26 18:51:22 <ncopa> its a bit weird that it only affects rpi
2019-02-26 18:51:32 <ncopa> what is iwd?
2019-02-26 18:51:53 <mps> Internet Wireless Daemon
2019-02-26 18:52:13 <mps> https://iwd.wiki.kernel.org/
2019-02-26 18:52:25 <ncopa> ah, that is intels wpa_supplicant replacement
2019-02-26 18:52:30 <mps> yes
2019-02-26 18:52:34 <ncopa> i was thinking of it today or yesterday
2019-02-26 18:52:42 <ncopa> we should make that work too
2019-02-26 18:52:58 <mps> I made apk of ell libs on which iwd depends
2019-02-26 18:53:27 <mps> and first version of iwd, but didn't tested it
2019-02-26 18:54:08 <mps> to repeat myself, I talked with iwd developers about packaging and ideas
2019-02-26 18:55:04 <ncopa> looks like kernel needs patches before 4.20
2019-02-26 18:55:19 <mps> for now they bundle ell libs with iwd but they have plan to make it separate because ell libs will be used for bluez and ophono
2019-02-26 18:56:07 <mps> I think kernel needs some options enabled and could work with 4.19, but not tested that
2019-02-26 18:57:19 <mps> I would like to hear from you and other Alpine developers which option is better:: package ell and iwd separately or in one apk
2019-02-26 18:57:58 <mps> knowing that in the future they will separate it and ell will be used for bluez and ophono
2019-02-26 18:58:37 <mps> although they make right now separate packages already
2019-02-26 18:59:26 <ncopa> im about to make an edge release
2019-02-26 18:59:36 <ncopa> eg a rolling snapshot release
2019-02-26 18:59:42 <_ikke_> the first one, right/
2019-02-26 18:59:44 <_ikke_> ?
2019-02-26 18:59:47 <_ikke_> or did you make them earlier
2019-02-26 19:00:07 <ncopa> i did earlier
2019-02-26 19:00:15 <ncopa> last time was v160223
2019-02-26 19:00:19 <ncopa> 2016
2019-02-26 19:00:35 <ncopa> i think i will tag it as v20180226
2019-02-26 19:00:58 <ncopa> which makes it more visible as snapshot
2019-02-26 19:01:03 <_ikke_> ah ok
2019-02-26 19:01:07 <ncopa> i wonder what I should use for alpine-base version
2019-02-26 19:01:21 <ncopa> its currently 3.9.0
2019-02-26 19:01:31 <ncopa> i was thinking 3.9.0_alpha1
2019-02-26 19:01:53 <ncopa> s/3.9.0/3.10.0/
2019-02-26 19:02:08 <ncopa> 3.10.0_alpha1
2019-02-26 19:02:19 <ncopa> or maybe 3.10_alpha1
2019-02-26 19:02:45 <ncopa> or maybe even 3.10_alpha<stamp>
2019-02-26 19:02:46 <_ikke_> ok, so it's more like a pre-release then a rolling release snapshot
2019-02-26 19:03:05 <ncopa> it is actually a rolling release snapshot
2019-02-26 19:03:34 <ncopa> but as soon we get our 3.10 RC out, we will make version to 3.10
2019-02-26 19:04:04 <ncopa> and 3 (in 3.10) as smaller than the number 20190226
2019-02-26 19:04:10 <ncopa> so apk will not upgrade
2019-02-26 19:04:28 <ncopa> that is why i am thinking of use 3.10_alpha
2019-02-26 19:04:42 <ncopa> i could also call it 3.10_pre
2019-02-26 19:07:36 <ncopa> i dont remember if _pre is treated older or newer than _rc
2019-02-26 19:08:25 <_ikke_> by what
2019-02-26 19:08:27 <_ikke_> /
2019-02-26 19:08:29 <_ikke_> ?
2019-02-26 19:08:38 <_ikke_> apk?
2019-02-26 19:08:52 <ncopa> foo-1.0_rc1 and foo-1.0_pre1
2019-02-26 19:09:01 <ncopa> which will apk treat as the newest?
2019-02-26 19:09:24 <_ikke_> How would an aports tag affect apk?
2019-02-26 19:09:57 <_ikke_> is it because alpine-base follows aports tags?
2019-02-26 19:10:12 <ncopa> if i make pkgver=20190226 now
2019-02-26 19:10:28 <ncopa> and later change it to 3.10.0_rc1
2019-02-26 19:10:43 <ncopa> then will apk not upgrade from 20190226
2019-02-26 19:10:58 <ncopa> because it will treat the version number as higher
2019-02-26 19:11:05 <_ikke_> right
2019-02-26 19:11:11 <_ikke_> 20190226 > 3
2019-02-26 19:11:13 <ncopa> it will compare 20190226 with 3
2019-02-26 19:11:15 <ncopa> yes
2019-02-26 19:11:26 <ncopa> and if we do pkgver=2019.02.26
2019-02-26 19:11:31 <_ikke_> it still is
2019-02-26 19:11:35 <ncopa> apk will say that 2019>3
2019-02-26 19:11:51 <ncopa> so i think we need to set pkgver=3.10something
2019-02-26 19:12:11 <ncopa> 3.10_alpha20190226 will work
2019-02-26 19:12:46 <ncopa> 3.10_alpha, 3.10_beta and 3.10_pre will work
2019-02-26 19:13:21 <ncopa>         cat >"$pkgdir"/etc/issue<<EOF
2019-02-26 19:13:21 <ncopa> Welcome to Alpine Linux ${pkgver%.*}
2019-02-26 19:13:38 <ncopa> we also generate the "welcome to Alpine" message from alpine-bas
2019-02-26 19:13:51 <ncopa> so what do we want to see when we boot edge snapshot?
2019-02-26 19:14:26 <ncopa> currently my edge desktop say "welcome to Alpine 3.9"
2019-02-26 19:15:23 <ncopa> it woudl be nicer with "Welcome to Alpine edge $date"
2019-02-26 19:16:28 <ncopa> do we want create iso image too?
2019-02-26 19:16:46 <ncopa> currently we only generate minirootfs and netboot
2019-02-26 19:17:59 <_ikke_> Does it make sense to generate an iso?
2019-02-26 19:18:17 <ncopa> it may be handy
2019-02-26 19:18:25 <ncopa> but it will also eat space on the mirrors
2019-02-26 19:18:27 <ncopa> ok
2019-02-26 19:18:35 <ncopa> lets not do that
2019-02-26 19:18:45 <ncopa> i think i will only generate minirootfs for now
2019-02-26 19:19:13 <_ikke_> trying to grasp the logic of apk_version_compare_blob_fuzzy
2019-02-26 19:20:01 <ncopa> $ apk version --test "1.0_rc1" "1.0_pre1"
2019-02-26 19:20:01 <ncopa> >
2019-02-26 19:20:26 <_ikke_> right, was looking for that
2019-02-26 19:20:55 <ncopa>  static const char *pre_suffixes[] = { "alpha", "beta", "pre", "rc" };
2019-02-26 19:22:24 <ncopa> i think 3.10_pre$datestamp is sort of nice
2019-02-26 19:24:01 <ncopa> we can also do 3.9_git20190226
2019-02-26 19:24:57 <_ikke_> right, postfix
2019-02-26 19:25:07 <_ikke_> makes sense
2019-02-26 19:25:39 <ncopa> but that will make 3.9.1 > 3.9_git20190226
2019-02-26 19:26:00 <ncopa> so i think we can only use _alpha, _beta or _pre
2019-02-26 19:26:08 <mps> ncopa: you asked for it :) https://patchwork.alpinelinux.org/patch/4527/ nice people in crystal lang community will be thankful because they could build static crystal applications only on Alpine
2019-02-26 19:26:18 <_ikke_> ncopa: right, was just testing that
2019-02-26 19:29:28 <ncopa> i think 3.10_pre20190226 is what looks best
2019-02-26 19:29:50 <_ikke_> ok
2019-02-26 19:30:02 <ncopa> _alpha is sort of good because it indicates that it is not stable
2019-02-26 19:30:30 <ncopa> but _alpha also sounds like its broken
2019-02-26 19:30:46 <ncopa> hmm maybe thats a good thing :)
2019-02-26 19:31:08 <_ikke_> https://github.com/RUB-NDS/TLS-Padding-Oracles
2019-02-26 19:32:51 <ncopa> _ikke_: does it affect libressl?
2019-02-26 19:32:59 <ncopa> seems like openssl 1.1.1 is not affected
2019-02-26 19:52:51 <ncopa> crystal is slow
2019-02-26 19:55:37 <mps> single threaded
2019-02-26 19:57:14 <mps> I tested it on both arch's (x86_64 and aarch64) before posted patch
2019-02-26 19:58:48 <mps> btw, I resolved dilemma about packaging iwd and ell. Debian, Fedora and Void make separate packages, only Arch have both in one
2019-02-26 19:59:15 <mps> I think we should make separate apk's. what do you think?
2019-02-26 20:48:14 <ncopa> yeah, i think you can split out the runtime libs
2019-02-26 20:49:54 <_ikke_> yay, all my packages are considered up-to-date by repology :)
2019-02-26 20:53:17 <mps> _ikke_: there is Alpine? didn't know
2019-02-26 20:53:40 <_ikke_> mps: Yes, Alpinelinux is tracked by repology
2019-02-26 20:54:03 <_ikke_> https://repology.org/projects/?inrepo=alpine_edge
2019-02-26 20:55:24 <mps> thanks
2019-02-26 20:56:10 <mps> ncopa: yes, for iwd pkcs8 missing in kernel 4.19
2019-02-26 21:07:49 <ncopa> mps: so it may make sense to add it to testing for now, and fix it properly on next kernel upgrade
2019-02-26 21:09:03 <mps> I think so, but will ask on #iwd channel. do you plan to upgrade kernel for next stable
2019-02-26 21:20:33 <mps> ncopa: this bug (Kernel 4.20+ is required for this feature.) in iwd is just a warning, not bug
2019-02-26 21:23:17 <mps> we can even patch 4.19 if we want to have 'WPA-Enterprise connections using TLS' in iwd
2019-02-26 22:28:20 <mps> iwd works on Alpine with kernel  4.19.18-0-vanilla. whoohoo
2019-02-26 22:31:03 <SpaceToast> \o/
2019-02-26 22:31:09 <SpaceToast> mps: can it do AP mode?
2019-02-26 22:32:38 <mps> looks like it can, just built it, need to prepare apk and check all that configs
2019-02-26 22:33:08 <mps> just testing if iwctl works
2019-02-26 22:33:47 <mps> will need few days to check and prepare proper APKBUILD
2019-02-26 22:33:50 <SpaceToast> ah ok
2019-02-26 22:33:52 <SpaceToast> still, great job, ty :D
2019-02-26 22:34:54 <mps> last few days I worked on crystal lang, today it is finished, now I have to go back to rust and in meantime to test iwd
2019-02-26 22:50:50 <mps> SpaceToast: for now can't find how to set it in AP mode :( don't know is it possible at all. will see
2019-02-26 22:51:48 <SpaceToast> I know it's possible
2019-02-26 22:51:54 <SpaceToast> idk if you can make it persistent though
2019-02-26 22:52:19 <SpaceToast> in iwctl you can see it under the "Access Point:" section
2019-02-26 22:53:08 <jwh> :((
2019-02-26 22:53:10 <jwh> sadface
2019-02-26 22:55:01 <mps> "Start an access point called "network name" with a passphrase" you mean
2019-02-26 22:56:56 <mps> to iwctl command 'ap wlan0 start "xyzasd" 123456qwertt' answer is 'No ap on device: 'wlan0''
2019-02-26 22:57:28 <mps> and 'ap list' says 'No devices in access point mode available.'
2019-02-26 23:05:08 <SpaceToast> yeah you have to switch it to that mode
2019-02-26 23:05:16 <SpaceToast> something along those lines, I'm at work right now so I can't verify
2019-02-26 23:06:14 <mps> ok, no problem, we have some time before next freeze. good night
2019-02-26 23:06:35 <mps> meh, next Alpine edge freeze
2019-02-26 23:06:44 <SpaceToast> \o
2019-02-26 23:06:51 <SpaceToast> jwh: what's wrong?
2019-02-26 23:07:40 <jwh> my PRs are still open without comments :P
2019-02-26 23:10:48 <jwh> probably gonna close the lxd one
2019-02-26 23:11:01 <jwh> should be a release in a week or so judging by previous ones
2019-02-26 23:19:14 <PureTryOut[m]> Sadly there are tons of PRs open without comments 😞
2019-02-26 23:20:43 <jwh> heh
2019-02-27 04:42:16 <foldedcascode> hi, is this an okay place to poke people about failing binary repo package builds?
2019-02-27 04:45:16 <basdb> fwiw the wiki page is missing some information on apk, such as the --virtual option: https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management
2019-02-27 04:45:21 <jwh> speak :D
2019-02-27 04:48:46 <foldedcascode> looks like libvpx update on edge today broke some things on arm
2019-02-27 04:49:13 <foldedcascode> or, maybe not just on arm
2019-02-27 04:50:17 <foldedcascode> https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/vlc/vlc-3.0.6-r1.log is popping up for everything that depends on libvpx, seems like
2019-02-27 04:52:12 <basdb> unrelated note, it'd be nice to have arm-none-eabi (GNU Arm Toolchain) part of the alpine packages (community, extra, or other)
2019-02-27 04:55:55 <foldedcascode> looks from here like they want libvpx.so.4, but the update built .6
2019-02-27 04:55:58 <foldedcascode> https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/libvpx/libvpx-1.8.0-r0.log
2019-02-27 04:57:02 <foldedcascode> anyways, idk how this usually gets resolved, just wanted to bring it up
2019-02-27 06:48:48 <ncopa> foldedcascode: i was me who pushed it so I need to fix it ASAP
2019-02-27 06:49:07 <ncopa> things like this is why there are so many open PRs
2019-02-27 06:49:48 <ncopa> there was like 3 different open PRs for libvpx. I had to spend time on figure out which to pick
2019-02-27 06:49:58 <ncopa> and comment on the others
2019-02-27 06:50:38 <ncopa> the PR failed on travis, but was explained that it was due to too much time to build
2019-02-27 06:50:43 <ncopa> so i built it locally
2019-02-27 06:50:59 <ncopa> and it failed on one package
2019-02-27 06:51:10 <ncopa> gst-plugins-good
2019-02-27 06:51:15 <ncopa> which i spent time to fix
2019-02-27 06:51:24 <ncopa> and then i pushed
2019-02-27 06:51:45 <ncopa> only to find out that it was broken on many other arches.... /o\
2019-02-27 08:04:03 <foldedcascode> ncopa: ah well. thanks for taking a look!
2019-02-27 08:17:02 <ncopa> foldedcascode: thanks for the poke
2019-02-27 08:17:36 <ncopa> and to answer that question, yes, its definitively ok to poke ppl about build failures here
2019-02-27 08:22:15 <mps> ncopa: when you are here, how we should ell libs package. ell is dependency for iwd about which we talked yesterday
2019-02-27 08:22:51 <mps> libell, ell-libs or just ell
2019-02-27 08:23:20 <mps> we will -dev package also
2019-02-27 08:24:47 <mps> in void linux it is named simply 'ell'
2019-02-27 08:25:56 <mps> in debian it is 'libell0'
2019-02-27 08:26:57 <mps> I'm personally for 'ell' and 'ell-dev' but want to hear what other thinks
2019-02-27 08:27:40 <ncopa> mps: is the ell sources shipped in its own source package, and will be its own APKBUILD?
2019-02-27 08:27:52 <ncopa> or is it shipped with iwd source package
2019-02-27 08:28:37 <mps> source is ell-version.tar.gz
2019-02-27 08:29:20 <mps> it is also bundled with iwd but will be split out when iwd 1.0 is released
2019-02-27 08:29:34 <ncopa> are there any binaries in addition to the libs?
2019-02-27 08:29:54 <mps> no, ell just libs
2019-02-27 08:30:04 <ncopa> then it makes no sense to split out ell-libs
2019-02-27 08:30:25 <ncopa> build it as "ell" and add "ell-dev" subpackage
2019-02-27 08:30:28 <ncopa> and -doc
2019-02-27 08:30:47 <mps> Debian, Fedora and Void already use separate packages of ell and iwd
2019-02-27 08:30:56 <ncopa> yeah, makes sense
2019-02-27 08:30:59 <ncopa> lets do that
2019-02-27 08:31:02 <mps> only Arch use bundled
2019-02-27 08:31:44 <mps> they don't have docs ready right now, but we could make something simple
2019-02-27 08:32:56 <mps> btw, did you read backlog of this channel from last night
2019-02-27 08:33:22 <mps> iwd works with kernel 4.19 on my test box
2019-02-27 08:37:45 <ncopa> i saw, very nice
2019-02-27 08:38:40 <mps> I'll try to finish ell APKBUILD today and post it
2019-02-27 08:38:41 <clandmeter> damn, patchwork and github is a mess
2019-02-27 08:38:55 <clandmeter> lots of duplicated stuff
2019-02-27 08:39:06 <clandmeter> mps: did you see the clang stuff on github?
2019-02-27 08:39:22 <mps> no? give me url
2019-02-27 08:49:29 <ncopa> crazy idea: make a github webhook that searches patchwork for similar patches when new PR is created
2019-02-27 08:49:55 <ncopa> and I wonder if we can kick out patchwork if we get our own gitlab?
2019-02-27 08:51:38 <ncopa> mps: the reason i tend to look at github PRs over patchwork is that with github we have CI that runs a test compile for us
2019-02-27 08:51:45 <ncopa> and tells me if it builds or not
2019-02-27 08:51:59 <ncopa> which is half the work done already
2019-02-27 08:52:01 <clandmeter> yes that was my idea also
2019-02-27 08:52:46 <clandmeter> yes we should have proper ci
2019-02-27 08:52:54 <clandmeter> we shbould not need t o build anything local anymore
2019-02-27 08:53:11 <clandmeter> just a matter of fetching the PR and merge it
2019-02-27 08:53:16 <clandmeter> if we like it
2019-02-27 08:57:46 <mps> ncopa: yes, I know, and only reason I didn't registered to github is the hope that Alpine will move to gitlab (soon)
2019-02-27 08:59:34 <mps> imo, gitlab is better than github and it is more 'safe' in case github finish their mission of the extend, embrace and extinguish
2019-02-27 09:02:25 <mps> clandmeter: I still thinks that is good to have local builds (as an option) where we can see and control build process. that fits better to my workflow
2019-02-27 09:03:13 <clandmeter> mps: you always need to have an option for local builds, else you are no developer anymor ;-)
2019-02-27 09:03:57 <mps> of course, CI is good and useful for a lot of works
2019-02-27 09:29:41 <_ikke_> hmm, it misses a dependency
2019-02-27 09:30:26 <clandmeter> sopel?
2019-02-27 09:31:14 <_ikke_> yes
2019-02-27 09:31:22 <_ikke_> unit tests didn't catch that apparently
2019-02-27 09:31:44 <_ikke_> pkg_resources.DistributionNotFound: The 'dnspython<3.0' distribution was not found and is required by sopel
2019-02-27 09:31:54 <clandmeter> i always try to read the setup.py
2019-02-27 09:32:16 <_ikke_> right, good tip
2019-02-27 09:33:43 <clandmeter> i was looking if there was a way to read it and alarm about missing deps.
2019-02-27 09:33:53 <clandmeter> couldnt find much, but im not into python that much.
2019-02-27 11:21:50 <_ikke_> setup.py doesn't mention dnspython
2019-02-27 11:24:05 <_ikke_> ah, its in requirements.txt
2019-02-27 11:35:22 <_ikke_> .uptime
2019-02-27 11:35:22 <alpine-meetbot> I've been sitting here for 0:00:33 and I keep going!
2019-02-27 12:35:31 <fabo> is there a toolchain guy that can take a look at https://bugs.alpinelinux.org/issues/10030 ?
2019-02-27 15:04:06 <ncopa> whee! edge builders are finally ok
2019-02-27 15:04:19 <ncopa> i think i better tag snapshot release before something new happens
2019-02-27 15:04:34 <ncopa> ugh..
2019-02-27 15:04:40 <ncopa> and ofc something new already happened
2019-02-27 15:04:45 <ncopa> kernel 4.19.26
2019-02-27 15:08:07 <TBB> :)
2019-02-27 15:08:58 <ncopa> ha, tagging snapshot release make builders behave funny :)
2019-02-27 15:09:41 <p4Wv1qn095FW> partying hard?
2019-02-27 15:10:48 <clandmeter> is this a first in regular series?
2019-02-27 15:11:46 <ncopa> clandmeter: what do you mean?
2019-02-27 15:13:00 <clandmeter> you are tagging a edge snapshot i presume?
2019-02-27 15:13:10 <clandmeter> we were talking about regular edge releases
2019-02-27 15:13:14 <clandmeter> before
2019-02-27 15:26:16 <ncopa> yes
2019-02-27 15:26:33 <ncopa> yes i hope to tag edge snapshots monthly
2019-02-27 15:26:42 <ncopa> or bi-monthly
2019-02-27 15:26:48 <ncopa> or similar
2019-02-27 16:07:14 <mps> ncopa: I prepared APKBUILD for ell libs. anyone are willing to look at it before I post it to patchwork.a.o
2019-02-27 16:07:50 <mps> it is here: http://tpaste.us/RgM4
2019-02-27 16:08:11 <mps> comments and patches are welcome
2019-02-27 16:08:53 <mps> check is disabled because there is bug in unit tests which I reported upstrem. they will look at it
2019-02-27 16:38:37 <bratkartoffel_> The openjdk9 aport is really strange... Cross-Compiling for all archs works, but "real" compile on 32 bit qemu-systems fails
2019-02-27 17:13:25 <ncopa> mps: i think it looks good enough for merge, just need a comment in there explaning why check is disabled
2019-02-27 17:13:58 <ncopa> maybe even with url to upstream bug so its easy for next person to see if it can be enabled again
2019-02-27 17:18:59 <mps> don't have upstream url because I reported issue in #iwd IRC channel
2019-02-27 17:19:48 <mps> I can copy messages from irc but that will bloat APKBUILD, I fear
2019-02-27 17:20:24 <mps> anyway, most distro don't run check on it
2019-02-27 17:21:37 <mps> other option if someone knows how specific unit test could be removed from Makefiles to post patch for that
2019-02-27 17:22:25 <mps> btw, iwd works on Alpine stable with kernel 4.4.174, on my chromebook
2019-02-27 17:23:37 <PureTryOut[m]> ncopa: so if you're going to backport qt5-qtwayland to 3.9, can I expect it in 3.9.1 or will it come earlier?
2019-02-27 18:50:39 <mps> I posted ell APKBUILD to patchwork.a.o https://patchwork.alpinelinux.org/patch/4528/ anyone interested please review
2019-02-27 18:51:43 <mps> SpaceToast: yes, iwd could be set in AP mode
2019-02-27 18:52:49 <mps> I have to prepare init script and config files for it, but it looks fine
2019-02-27 18:53:47 <SpaceToast> \o/
2019-02-27 18:59:09 <mps> SpaceToast: look here: http://tpaste.us/9gnP  address is obfuscated of course
2019-02-27 18:59:41 <SpaceToast> looks good!
2019-02-27 18:59:51 <SpaceToast> as usual, if you need help with anything openrc, do feel free to ask me :)
2019-02-27 19:00:20 <mps> that is thing which I searching for
2019-02-27 19:00:55 <mps> only that is missing
2019-02-27 19:01:38 <mps> right now I'm looking to gentoo init script
2019-02-27 19:02:46 <mps> it looks somewhat strange to my eyes, but I'm far from expert in that
2019-02-27 19:03:07 <SpaceToast> let me take a look at it
2019-02-27 19:03:31 <mps> could post url in ten minutes, right now I'm out
2019-02-27 19:03:45 <SpaceToast> no, no, looks about right
2019-02-27 19:03:54 <SpaceToast> https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/iwd/files/iwd.initd
2019-02-27 19:03:54 <mps> ah, ok
2019-02-27 19:03:55 <SpaceToast> this, right?
2019-02-27 19:04:06 <mps> I think it is
2019-02-27 19:04:15 <SpaceToast> yeah that looks about correct
2019-02-27 19:04:27 <SpaceToast> I'd also add a "before net", maybe, in the depends
2019-02-27 19:04:37 <SpaceToast> but this is what most services should generally look like
2019-02-27 19:04:47 <mps> do you think it can be used?
2019-02-27 19:05:00 <SpaceToast> if we have the same paths, sure
2019-02-27 19:05:38 <mps> ok, then I will stole it and put. we can fix it if something doesn't work for us
2019-02-27 19:06:00 <mps> yes, path is /usr/libexec/iwd
2019-02-27 19:06:59 <mps> and, btw, where to put dbus 'script'
2019-02-27 19:07:12 <SpaceToast> ?
2019-02-27 19:07:20 <mps> usr/share/dbus-1/system.d/iwd-dbus.conf
2019-02-27 19:07:38 <SpaceToast> wherever dbus will pick it up, I'd imagine
2019-02-27 19:07:49 <SpaceToast> I'm not that familiar with dbus, tbfh, beyond some unfortunate details
2019-02-27 19:07:51 <mps> system.d looks strange, but it works
2019-02-27 19:08:57 <mps> and I think we should not use ead for now, other distros also don't use it
2019-02-27 19:09:28 <SpaceToast> I'm not even sure what ead is
2019-02-27 19:09:44 <mps> ethernet auth daemon
2019-02-27 19:10:23 <mps> iwd for wired ethernet, at the end
2019-02-27 19:11:56 <mps> I think we should skip ophono and bluez in first version for Alpine
2019-02-27 19:12:11 <mps> anyway we don't have ophono
2019-02-27 19:12:22 <SpaceToast> mhm
2019-02-27 19:12:33 <SpaceToast> ead seems mostly separate, we can do that later for sure
2019-02-27 19:13:01 <SpaceToast> bluez would be good to have later - many laptop systems use bluetooth for at least one peripheral
2019-02-27 19:13:02 <mps> my mind agrees with you
2019-02-27 19:13:22 <SpaceToast> we currently have a pretty bad reputation when it comes to client-facing devices, and having bluez in-tree would be a step towards improving that :)
2019-02-27 19:13:30 <mps> yes, we should go in that step by step I think
2019-02-27 19:13:38 <SpaceToast> yeah, for now just iwd seems good - it's useful both on servers and clients
2019-02-27 19:14:20 <mps> nice that we agree, we will do that way
2019-02-27 19:14:42 <SpaceToast> sounds good to me :)
2019-02-27 19:14:49 <mps> I can post later APKBUILD for you if you want to look at it
2019-02-27 19:15:16 <SpaceToast> sure, I'll try and make sure there aren't any extraneous default overrides
2019-02-27 19:17:01 <mps> ok, see you later
2019-02-27 20:38:25 <mps> SpaceToast: would you like 'git format-patch' or APKBUILD and iwd.initd files
2019-02-27 20:38:58 <SpaceToast> I'm a bit busy right now (dealing with some "special" people atm :/)
2019-02-27 20:39:07 <SpaceToast> so feel free to git-format-patch to toast@toastin.space
2019-02-27 20:39:12 <SpaceToast> I'll reply by email once I've some time, ok?
2019-02-27 20:40:29 <mps> ok, we are not in hurry, but your review will be appreciated. so, easy :)
2019-02-27 20:50:46 <_ikke_> Anyone got a comment on https://github.com/alpinelinux/aports/pull/6442#issuecomment-468002915?
2019-02-27 20:52:37 <danieli> I'm guessing that person, by "hashed zip", means a tarball of a specific commit?
2019-02-27 20:52:50 <_ikke_> danieli: yes, I assume that as well
2019-02-27 20:53:06 <jwh> so... how do I trigger another drone build? :D
2019-02-27 20:53:11 <danieli> you can replace ".zip" in that link with ".tar.gz" and use that, if there are no releases available
2019-02-27 20:53:57 <_ikke_> jwh: iirc, you have to push again. So something like git commit --amend -C@; git push --force-with-lease
2019-02-27 20:54:06 <jwh> oh
2019-02-27 20:54:08 <jwh> hmp
2019-02-27 20:54:10 <jwh> hmph
2019-02-27 20:54:36 <_ikke_> danieli: hmm: http://pyropus.ca/software/memtester/old-versions/
2019-02-27 20:55:05 <jwh> well, https://cloud.drone.io/alpinelinux/aports/75/1/2
2019-02-27 20:55:12 <jwh> theres nothing wrong with the port, builder sucks
2019-02-27 20:56:02 <_ikke_> drone.io is new for us, so of course there can still be issues
2019-02-27 20:56:26 <jwh> well, it looks like a linker issue so either it just happened to build during a rebuild or something
2019-02-27 20:56:31 <jwh> or its broken on x86
2019-02-27 20:57:01 <jwh> I don't think it's drone related
2019-02-27 20:57:45 <_ikke_> danieli: do you happen to know how to get an archive from kernel.org (cgit)?
2019-02-27 20:58:09 <_ikke_> ah, found it
2019-02-27 20:58:19 <danieli> ha
2019-02-27 20:58:22 <danieli> that was quick
2019-02-27 20:58:39 <danieli> roughly 37 seconds
2019-02-27 20:58:59 <_ikke_> But his comment was that it's more common to use snapshots than to download commit archives
2019-02-27 20:59:04 <clandmeter> i sometimes use hashes
2019-02-27 20:59:06 <jwh> oh, lol, that command broke it D
2019-02-27 20:59:07 <jwh> :D
2019-02-27 20:59:23 <_ikke_> clandmeter: is there a preference?
2019-02-27 20:59:42 <clandmeter> preference is to ask upstream to do a tag :)
2019-02-27 20:59:45 <_ikke_> heh
2019-02-27 21:00:00 <jwh> https://cloud.drone.io/alpinelinux/aports/116
2019-02-27 21:00:01 <jwh> RIP
2019-02-27 21:00:08 <_ikke_> apparently there used to be tagged releases, but the last one was from 2012
2019-02-27 21:00:09 <clandmeter> making a snapshot makes no sense if you can fetch a hashed tarball
2019-02-27 21:00:25 <_ikke_> right, that was my feeling as well
2019-02-27 21:00:46 <clandmeter> so I normally just add a _sha= to the apkbuild
2019-02-27 21:01:04 <_ikke_> right
2019-02-27 21:01:05 <clandmeter> and set a proper version 0.whatetver_gitdate
2019-02-27 21:01:37 <clandmeter> where the version would be the last known version
2019-02-27 21:01:39 <_ikke_> If I look here http://pyropus.ca/software/memtester/old-versions/
2019-02-27 21:01:45 <_ikke_> 4.3.0
2019-02-27 21:02:57 <_ikke_> jwh: sigh :-)
2019-02-27 21:03:26 <clandmeter> and why is it called mmc-utils?
2019-02-27 21:03:32 <jwh> _ikke_: probably me :D
2019-02-27 21:03:44 <jwh> oh
2019-02-27 21:03:57 <jwh> its because drone fetches master first, then merges pr
2019-02-27 21:04:01 <jwh> rebased, easymode
2019-02-27 21:05:08 <clandmeter> jwh im looking at that atm
2019-02-27 21:05:25 <jwh> oh
2019-02-27 21:06:37 <jwh> meh, its still failing on x86
2019-02-27 21:07:01 <jwh> but nothing changed for non-arm in my PR, so whatever heh
2019-02-27 21:08:42 <_ikke_> clandmeter: downside of our current rebase workflow is that I have a branches where I have no idea what was upstreamed and what not ;O
2019-02-27 21:08:44 <_ikke_> :P
2019-02-27 21:09:20 <jwh> https://patch-diff.githubusercontent.com/raw/alpinelinux/aports/pull/6472.diff that's the pr btw, as you can see nothing touched except setting cxxflags for arm
2019-02-27 21:15:52 <clandmeter> jwh: i wonder what happens here
2019-02-27 21:16:01 <clandmeter> i just tried this locally and it just works
2019-02-27 21:16:28 <clandmeter> _ikke_: what do you mean with "current rebase workflow"?
2019-02-27 21:17:34 <_ikke_> clandmeter: rebase every commit on top of master
2019-02-27 21:19:46 <clandmeter> are you talking about drone?
2019-02-27 21:20:03 <_ikke_> no
2019-02-27 21:20:11 <_ikke_> the general aports workflow
2019-02-27 21:20:20 <clandmeter> ah ok
2019-02-27 21:20:23 <clandmeter> we have one?
2019-02-27 21:20:27 <_ikke_> yes
2019-02-27 21:20:40 <jwh> clandmeter: sme
2019-02-27 21:20:42 <jwh> same*
2019-02-27 21:20:52 <clandmeter> jwh: im checking with drone ppl
2019-02-27 21:23:00 <clandmeter> _ikke_: you have branches locally with changes which you dont know if they are merged?
2019-02-27 21:23:16 <jwh> clandmeter: thx
2019-02-27 21:23:17 <SpaceToast> mps: sent you feedback, most of it is good, just a few small changes that would be good-to-haves
2019-02-27 21:23:48 <_ikke_> clandmeter: exactly
2019-02-27 21:23:54 <SpaceToast> clandmeter: also, please no longer worry about poking me re: turbo-paste; I wrote my own instead :)
2019-02-27 21:24:02 <_ikke_> clandmeter: I can probably use git cherry to get an idea
2019-02-27 21:24:35 <clandmeter> SpaceToast: np, its trivial to make one.
2019-02-27 21:24:45 <SpaceToast> mostly, the devil's in the details :)
2019-02-27 21:25:41 <clandmeter> _ikke_: the branches you have are your own or from github?
2019-02-27 21:26:09 <_ikke_> both :-)
2019-02-27 21:26:28 <_ikke_> mostly PRs that I applied locally or created locally
2019-02-27 21:26:55 <_ikke_> git cherry helps
2019-02-27 21:30:59 <clandmeter> _ikke_: there is no one workflow for git i guess. ppl do it in different ways.
2019-02-27 21:31:28 <clandmeter> you can fetch branches or you can fetch a diff and apply it to master directly
2019-02-27 21:31:44 <_ikke_> yes, but the end-result is the same
2019-02-27 21:31:50 <_ikke_> One linear branch
2019-02-27 21:31:55 <clandmeter> yes?
2019-02-27 21:32:04 <clandmeter> i dont see the issue here
2019-02-27 21:32:24 <clandmeter> if you rebase your changes are on top?
2019-02-27 21:32:33 <_ikke_> Normally when you merge branches, you can ask git what branches have been merged or not
2019-02-27 21:32:42 <_ikke_> so you can easily see which can be removed and which not
2019-02-27 21:33:25 <_ikke_> But now there is no relation between the commits you created and the commits that actually make it to master
2019-02-27 21:37:08 <clandmeter> _ikke_: how else do you want to see our workflow?
2019-02-27 21:38:26 <mps> SpaceToast: any hint how iwd init script works, there is no start/stop functions ?
2019-02-27 21:38:49 <SpaceToast> mps: you know how abuild has default dev(), openrc() etc functions?
2019-02-27 21:38:57 <SpaceToast> openrc has default start(), stop(), etc functions
2019-02-27 21:39:04 <SpaceToast> and you want to use them as often as possible.
2019-02-27 21:39:14 <mps> hah, thanks
2019-02-27 21:39:14 <_ikke_> clandmeter: one thing that might help, but probably a lot more involved, would be updating the topic branches where the PRs were created from
2019-02-27 21:39:16 <SpaceToast> this is a good introduction in case you're unfamiliar: https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
2019-02-27 21:39:26 <SpaceToast> mps: I'll have a much more in-depth coverage of it in the developer handbook once I get to that
2019-02-27 21:39:42 <SpaceToast> but I'm still swamped at work (moving offices is quite the undertaking, and I'm the only ranking admin)
2019-02-27 21:40:04 <mps> can't wait for it, especially of this fine points with openrc
2019-02-27 21:40:27 <mps> thank you again for explanation
2019-02-27 21:41:53 <mps> I will adapt iwd according your suggestions. do you think it is ready for aports after these changes
2019-02-27 21:42:35 <SpaceToast> well, I'm not exactly an authority in that regard
2019-02-27 21:42:45 <mps> and, commented lines, I forgot to delete them, they were for testing connman
2019-02-27 21:42:46 <_ikke_> clandmeter: but I'm not actually asking for something to change
2019-02-27 21:42:48 <SpaceToast> but with my suggested changes it should be good imo, assuming it passes tests and runs (which it seems to)
2019-02-27 21:43:29 <mps> it passes and runs on aarch64 on kernel 4.4.174
2019-02-27 21:44:05 <tdtrask> I getting a problem on Alpine 3.8 trying to run Freeswitch with Lua code. Cannot load lua-session with 'Error relocating'. Any ideas?
2019-02-27 21:44:07 <mps> and tried it on x86_64 with linux-vanilla 4.19.18
2019-02-27 21:44:08 <tdtrask> user.err freeswitch[22910]: bd6e297b-09cf-4332-a7d6-153314eb7734 2019-02-27 01:40:32.973418 [ERR] mod_lua.cpp:203 error loading module 'socket.core' from file '/usr/lib/lua/5.2/socket/core.so': 	Error relocating /usr/lib/lua/5.2/socket/core.so:
2019-02-27 21:45:43 <tdtrask> seems like a problem in lua-socket to me
2019-02-27 21:46:05 <tdtrask> (not sure why I typed lua-session a minute ago)
2019-02-27 22:21:40 <tdtrask> Nevermind, turned out to be a misconfiguration pointing to Lua 5.2 libraries when Freeswitch is build with lua5.3-dev.
2019-02-27 22:25:39 <kpcyrd> I've noticed installing the net-tools package causes a system with 2 ifconfig binaries, busybox is at /sbin/ifconfig and net-tools is at /bin/ifconfig, so depending on root/not-root you get a different program. Is that intentionally or a bug?
2019-02-27 22:34:52 <mps> ncopa: I posted iwd to patchwork.a.o https://patchwork.alpinelinux.org/patch/4529/ tested it a bit on x86_64 (4.19.18-0-vanilla) and aarch64 (kernel 4.4.174)
2019-02-27 22:35:42 <mps> SpaceToast: here is a aports patch: https://patchwork.alpinelinux.org/patch/4529
2019-02-27 22:43:10 <mps> btw, if someone wants to play with network-manager and iwd NM should be upgraded to 1.12 or better 1.14.
2019-02-27 23:11:07 <clandmeter> jwh: still here?
2019-02-27 23:12:50 <jwh> yo
2019-02-27 23:13:37 <clandmeter> the android tools aport is yours?
2019-02-27 23:14:16 <jwh> no, just an update to add it for arm
2019-02-27 23:14:28 <clandmeter> yes i mean the PR
2019-02-27 23:14:32 <jwh> oh, yes
2019-02-27 23:14:55 <clandmeter> i think your history is not in line with regular aports
2019-02-27 23:15:02 <clandmeter> it needs a rebase
2019-02-27 23:15:07 <jwh> I rebased it and pushed again
2019-02-27 23:15:19 <jwh> but that doesn't cause undefined references
2019-02-27 23:16:20 <clandmeter> something is different
2019-02-27 23:16:32 <jwh> there is literally nothing different
2019-02-27 23:16:37 <clandmeter> if i pull your pr ref into aports it fetches a lot of stuff
2019-02-27 23:16:38 <jwh> it builds on everything apart from x86
2019-02-27 23:16:49 <jwh> oh, the history is probably broken
2019-02-27 23:16:50 <clandmeter> err fetch
2019-02-27 23:16:54 <jwh> but that doesn't explain the build being broken
2019-02-27 23:16:57 <clandmeter> yes
2019-02-27 23:17:34 <clandmeter> hmm
2019-02-27 23:17:41 <clandmeter> i think im mixing pr's here
2019-02-27 23:17:52 <clandmeter> did you get clone issues before?
2019-02-27 23:17:59 <clandmeter> on drone
2019-02-27 23:18:03 <jwh> only when I pushed without rebasing
2019-02-27 23:18:08 <jwh> as it does fetch;merge
2019-02-27 23:18:12 <clandmeter> exactly
2019-02-27 23:18:21 <jwh> but I pushed rebased tree
2019-02-27 23:18:31 <clandmeter> yes and then it worked i guess
2019-02-27 23:18:34 <jwh> nope
2019-02-27 23:18:38 <clandmeter> i mean the clone
2019-02-27 23:18:41 <jwh> oh, yeah
2019-02-27 23:18:55 <jwh> travis does a clean clone by the looks of it
2019-02-27 23:19:01 <jwh> so it doesn't care about that
2019-02-27 23:19:16 <clandmeter> right
2019-02-27 23:19:35 <jwh> but... why is the x86 build broken on drone
2019-02-27 23:20:01 <jwh> or is it just that I'm out of date and theres some package update thats broken it
2019-02-27 23:23:01 <clandmeter> i havent looked into that yet
2019-02-27 23:23:16 <jwh> well, it was last built 2 days ago so it must be fine
2019-02-27 23:37:57 <mps> clandmeter: I tested this on aarch64, armv7 and x86_64, all went fine
2019-02-27 23:39:38 <jwh> it's not us :D
2019-02-27 23:41:43 <mps> jwh: don't understand. I tested it but you found solution. Sorry if I misunderstood you
2019-02-27 23:42:27 <jwh> theres no problem, don't worry
2019-02-27 23:44:57 <mps> I just wanted to confirm your assertion that it works, nothing more :)
2019-02-27 23:45:39 <jwh> well, it *did*
2019-02-27 23:45:45 <jwh> just updated my i386 builder
2019-02-27 23:45:56 <jwh> but either way, we didn't touch x86
2019-02-27 23:47:01 <mps> that's true. sorry I promised that I will install x86 lxc, but worked on ell lib and iwd
2019-02-28 00:01:28 <jwh> >>> android-tools: Create android-tools-9.0.0_p33-r1.apk
2019-02-28 00:01:28 <jwh> >>> android-tools: Build complete at Thu, 28 Feb 2019 00:02:23 +0000 elapsed time 0h 16m 0s
2019-02-28 00:01:32 <jwh> still works fine
2019-02-28 00:01:52 <jwh> something is off
2019-02-28 00:03:51 <mps> jwh: what arch?
2019-02-28 00:04:28 <jwh> x86...
2019-02-28 00:05:48 <mps> heh, then it works. maybe drone doesn't work 'nice'
2019-02-28 00:06:09 <jwh> it doesn't look like it builds with a fresh image
2019-02-28 00:06:18 <jwh> so if something was broken when I raised the PR, it will stay broken
2019-02-28 00:09:46 <mps> do you have build log, it should where is the error
2019-02-28 00:13:46 <jwh> https://cloud.drone.io/alpinelinux/aports/118/2/1
2019-02-28 00:13:53 <jwh> theres no debug output, so just undefined references
2019-02-28 00:16:43 <mps> looks similar on all arch's but only x86 marked as failed
2019-02-28 00:17:57 <jwh> no other arch has any errros
2019-02-28 00:17:58 <jwh> errors
2019-02-28 00:19:31 <mps> seems boringssl have problem on Alpine x86
2019-02-28 00:19:38 <jwh> it doesn't
2019-02-28 00:20:02 <mps>  undefined reference to `ChaCha20_ctr32'
2019-02-28 00:20:15 <jwh> theres nothing wrong with android-tools on x86, the builder is broken
2019-02-28 00:20:35 <mps> line 2634
2019-02-28 00:22:09 <jwh> there is nothing wrong
2019-02-28 00:22:24 <mps> if it succeed on you physical x86 machine with edge installed then the problem is with builder probably
2019-02-28 00:22:51 <jwh> its entirely possible it didn't get created properly, or theres a partial update or something
2019-02-28 00:23:29 <jwh> https://pkgs.alpinelinux.org/package/edge/testing/x86/android-tools
2019-02-28 00:23:35 <jwh> couple of weeks ago
2019-02-28 00:23:40 <mps> I see a lot of 'undefined reference' in log
2019-02-28 00:26:34 <jwh> https://cloud.drone.io/alpinelinux/aports/120
2019-02-28 00:27:04 <jwh> broken builder
2019-02-28 00:27:13 <jwh> because... x86 works here
2019-02-28 00:27:22 <jwh> and other arch, ofc
2019-02-28 00:28:18 <jwh> hm
2019-02-28 00:28:35 <jwh> should arch be amd64 for the x86 pipeline?
2019-02-28 00:29:36 <mps> no, it is x86, afaik
2019-02-28 00:30:44 <jwh> the docs helpfully don't specify a list of possible arch
2019-02-28 00:30:56 <jwh> amd64 might be the right one
2019-02-28 00:31:05 <jwh> if it describes hardware not environment
2019-02-28 00:32:51 <SpaceToast> the amd64/x86_64 divide is always kind of confusing
2019-02-28 00:33:35 <jwh>  image: alpinelinux/alpine-drone-ci:edge-x86
2019-02-28 00:33:36 <jwh> should be fine
2019-02-28 00:33:39 <SpaceToast> because x86 is intel's architecture, amd64 is x86 + amd's 64 bit extensions, but because it's an extension (even though it's quite essential), people like saying x86_64 (_64 being the extended part), but that immediately brings intel to mind because x86 is theirs :D
2019-02-28 00:33:56 <jwh> it *should* be amd64, but linux has to be different etc
2019-02-28 00:33:56 <jwh> :D
2019-02-28 00:34:08 <jwh> everyone else calls it amd64
2019-02-28 00:34:34 <SpaceToast> it really depends on case-by-case
2019-02-28 00:34:37 <mps> amd64 always looked strange to me
2019-02-28 00:34:38 <SpaceToast> canonical calls it amd64, for example
2019-02-28 00:34:43 <jwh> I mean OS
2019-02-28 00:34:45 <SpaceToast> but yes, amd64 is the technically correct name
2019-02-28 00:34:56 <jwh> *BSD, windows, non-unices etc
2019-02-28 00:35:11 <SpaceToast> yeah, but I'm saying that even above OS level opinions differ
2019-02-28 00:35:18 <SpaceToast> (e.g on https://alpinelinux.org/downloads/ we use x86_64)
2019-02-28 00:35:30 <jwh> well really distributions should just follow kernel convention
2019-02-28 00:35:36 <jwh> far less problematic
2019-02-28 00:35:50 <jwh> whatever uname -m says, thats what it is heh
2019-02-28 00:35:56 <SpaceToast> in short, "kind of confusing" :)
2019-02-28 00:36:03 <jwh> except mips64, coz thats a weird one
2019-02-28 00:36:10 <SpaceToast> and arm variants... ;)
2019-02-28 00:36:39 <jwh> although endianness isn't the same as arch, soooo
2019-02-28 00:37:14 <jwh> anyway
2019-02-28 00:37:20 <jwh> I can't debug why it doesn't work
2019-02-28 00:37:52 <mps> what arch you use on your machine, x86?
2019-02-28 00:38:00 <jwh> i386
2019-02-28 00:38:04 <jwh> because thats what it is D
2019-02-28 00:38:07 <jwh> :D*
2019-02-28 00:38:25 <jwh> but yes, x86 in alpine parlance
2019-02-28 00:38:32 <jwh> not ambiguous at all
2019-02-28 00:39:13 <mps> if you work in these you have to accept that naming chaos
2019-02-28 00:39:34 <SpaceToast> I'm kind of lucky, all my stuff is amd64 :)
2019-02-28 00:39:46 <jwh> well, you know why its absurd?
2019-02-28 00:39:53 <jwh> PR has nothing to do with x86
2019-02-28 00:39:55 <SpaceToast> the separation *I* have to work a lot with is UEFI/BIOS
2019-02-28 00:40:05 <jwh> it merely adds arm
2019-02-28 00:40:18 <SpaceToast> mayhaps it was broken all along ;)
2019-02-28 00:40:40 <jwh> it's possible something broken it in the 14 days since it was last built
2019-02-28 00:40:43 <jwh> broke*
2019-02-28 00:40:48 <mps> something is wrong with boringssl on x86 builder
2019-02-28 00:40:55 <jwh> but then it builds fine on my x86 lxc
2019-02-28 00:41:58 <jwh> anyway, sleepy time
2019-02-28 00:42:31 <mps> yes, good night all :)
2019-02-28 01:00:57 <SpaceToast> jwh: have you encountered the "fun" that is trying to run a systemd guest on a non-systemd lxd (or even lxc, really) host?
2019-02-28 01:07:28 <jwh> yes
2019-02-28 01:07:40 <jwh> I couldn't tell if I broke it or not though
2019-02-28 01:07:49 <jwh> but it's probably just missing some cgroups
2019-02-28 01:07:58 <jwh> but who needs debug in lxd right?
2019-02-28 01:08:03 <jwh> or lxc
2019-02-28 01:18:30 <jwh> man, adb needs to be able to read a config file
2019-02-28 01:18:38 <jwh> or env or somerthing
2019-02-28 01:18:43 <jwh> so I can persist forwars
2019-02-28 01:18:46 <jwh> forwards
2019-02-28 01:19:11 <SpaceToast> jwh: it's a systemd thing
2019-02-28 01:19:18 <SpaceToast> systemd wants to have its own cgroupv1 cgroup
2019-02-28 01:19:27 <jwh> also hm, what magic do I need to tell lxd/lxc to allow something like chrony to work
2019-02-28 01:19:43 <jwh> I don't really want it touching system time, but ntp and stuff
2019-02-28 01:19:44 <SpaceToast> the default openrc cgroup isn't erm... configurable, so I had to write my own script for it :/
2019-02-28 01:19:48 <jwh> ah
2019-02-28 01:20:06 <SpaceToast> I'm gonna write a replacement to the openrc one and submit it upstream (or try to get it in tree if william wants nothing to do with it)
2019-02-28 01:20:17 <SpaceToast> but that was erm... unfortunate
2019-02-28 01:20:30 <jwh> heh
2019-02-28 01:20:50 <SpaceToast> you can have my quick "hack" one if you have to do stuff
2019-02-28 01:20:57 <SpaceToast> but because of this I'm gonna be reinstalling the new ones at work with 'buntu
2019-02-28 01:21:01 <SpaceToast> just to avoid... problems
2019-02-28 01:21:19 <SpaceToast> at home it's fine, I can do whatever, but I don't want anyone at work to suffer because I'm doing experimental stuff
2019-02-28 01:21:49 <jwh> running ones have arch on atm (partly because of systemd not working, partly because of not having chance to create an apkbuild for exynos kernel yet)
2019-02-28 01:22:03 <jwh> mainline armv7 one is broken on this board at least
2019-02-28 01:26:21 <jwh> bleh
2019-02-28 01:26:33 <jwh> still no way to set capabilities for lxd?
2019-02-28 01:27:00 <jwh> wonder if I can get away with setcap
2019-02-28 01:27:39 <SpaceToast> it's not really an lxd thing
2019-02-28 01:27:47 <jwh> well
2019-02-28 01:27:53 <SpaceToast> linux doesn't have support for caps in an unprivileged filesystem namespace
2019-02-28 01:27:54 <jwh> lxd is doing management, so
2019-02-28 01:27:57 <jwh> oh hm
2019-02-28 01:27:59 <SpaceToast> you can set the container to be privileged
2019-02-28 01:28:03 <SpaceToast> and then it'll just work
2019-02-28 01:28:10 <jwh> may have to do that
2019-02-28 01:28:11 <SpaceToast> but, that's what the other guys are doing, and it's not very nice, is it? ;)
2019-02-28 01:28:16 <jwh> no
2019-02-28 01:28:21 <SpaceToast> suid isn't all that bad if it's in an unprivileged container, though
2019-02-28 01:28:28 <SpaceToast> so in most cases you can get away with that
2019-02-28 01:28:38 <jwh> no bluetooth namespacing either :(
2019-02-28 01:28:41 <SpaceToast> also I wonder if you could privileged -> setcap -> poweroff -> deprivilege
2019-02-28 01:28:45 <jwh> so I can't contain the horribleness
2019-02-28 01:28:54 <jwh> thats what I'm just checking heh
2019-02-28 01:31:48 <jwh> was hoping I coudl get away with setcap on unprivileged too, but nm
2019-02-28 01:32:17 <SpaceToast> yeah, kernel no likey
2019-02-28 01:32:45 <jwh> kinda silly, cap should just work
2019-02-28 01:32:46 <jwh> but heh
2019-02-28 01:43:00 <jwh> hm
2019-02-28 01:43:06 <jwh> still can't start chron
2019-02-28 01:43:07 <jwh> chrony
2019-02-28 01:43:48 <jwh>   security.privileged: "true"
2019-02-28 01:46:10 <jwh> hm, think setcap broke it
2019-02-28 01:50:27 <jwh> hm, issue on github suggests it should work for privileged
2019-02-28 01:50:34 <jwh> but the lxc container needs the cap not the file :D
2019-02-28 01:57:06 <jwh> doesn't work either, gg
2019-02-28 04:20:32 <craftyguy> if a package, foo, builds subpackages and the apkbuild has a 'provides=bar', do the foo-* packages implicitly have 'provides=bar-*' ?
2019-02-28 07:11:27 <ncopa> PureTryOut[m]: i just backported qt5-qtwayland to v3.9
2019-02-28 07:20:05 <ncopa> craftyguy: they shouldnt. if they do it is a bug
2019-02-28 07:21:42 <ncopa> what do you think abou this? I fint it controversial https://patchwork.alpinelinux.org/patch/4525/
2019-02-28 07:49:36 <PureTryOut[m]> ncopa: awesome, thanks!
2019-02-28 08:00:03 <ncopa> i saw that we have qt 5.12.0 in v3.9 and 5.12.1 in edge
2019-02-28 08:00:24 <ncopa> file a bug if you want upgrade v3.9 to 5.12.1 (if you have a specific problem with 5.12.0)
2019-02-28 08:47:54 <mps> ncopa: have to go to short travel, will look at iwd bugs afternoon or this night
2019-02-28 08:50:05 <ncopa> im gonna disable all archch except x86 and x86_64 for now i think
2019-02-28 08:54:34 <mps> ncopa: disable it, we will see later what is cause. sorry now have to go
2019-02-28 11:45:07 <ncopa> mps: i found a fix for it. works on all arches except ppc64le now
2019-02-28 14:51:17 <grharry> Hello, in one of my servers running apache I see a process [kthrtld]  which has a TCP connection to some server in Holland and the apache2 server shows a defunt status!
2019-02-28 14:51:33 <grharry> obviously I am hacked !
2019-02-28 14:51:50 <grharry> anyone knows something about it ?
2019-02-28 14:56:01 <grharry> Compromised?? In one of my servers running apache I see a process [kthrtld]  which has a TCP connection to some server in Holland and the apache2 server shows a defunt status! Anybody seen something similar ?
2019-02-28 15:16:43 <danieli> ... no patience?
2019-02-28 15:17:15 <clandmeter> ncopa: the edge releases will not be signed?
2019-02-28 15:17:21 <danieli> what, why not?
2019-02-28 15:18:03 <clandmeter> well if he wants to automate it it would make it more difficult.
2019-02-28 15:18:34 <clandmeter> the sigs are not here atm, so thats why im asking
2019-02-28 15:29:06 <ncopa> oh. i didnt think about that...
2019-02-28 15:31:24 <clandmeter> thats what you have me for ;-)
2019-02-28 15:35:26 <clandmeter> ncopa: so i can reply on a sig?
2019-02-28 15:54:02 <clandmeter> s/reply/rely
2019-02-28 15:54:02 <alpine-meetbot> clandmeter meant to say: ncopa: so i can rely on a sig?
2019-02-28 15:55:12 <clandmeter> im trying to fix boot.a.o. what is the topic to listen for new releases?
2019-02-28 16:10:35 <ncopa> $upload_msg "$rel/releases/$arch"
2019-02-28 16:10:52 <ncopa> so "edge/releases/#"
2019-02-28 16:11:09 <ncopa> or if you want a specific arch you can specify that
2019-02-28 16:11:28 <ncopa> im working on the official docker image release
2019-02-28 16:15:44 <ncopa> im pretty happy with result: https://github.com/ncopa/docker-brew-alpine
2019-02-28 16:40:33 <clandmeter> ncopa: how can i listen for the latest-stable releases?
2019-02-28 16:55:54 <mps> ncopa: I apologize for problem I made posting iwd APKBUILD and forgot to run test (abuild chekck) on aarch64 and armv7, and just check on x86_64
2019-02-28 16:57:35 <mps> just read complete conversation from #iwd channel, you fixed it really fast
2019-02-28 17:01:46 <mps> small note, do we need linux-headers in makedepends? it we be pulled by glib-dev which pulls libffi-dev and this one pulls linux-headers
2019-02-28 17:11:09 <mps> s/it we/it will/
2019-02-28 17:11:09 <alpine-meetbot> mps meant to say: small note, do we need linux-headers in makedepends? it will be pulled by glib-dev which pulls libffi-dev and this one pulls linux-headers
2019-02-28 18:45:53 <andypost[m]> interesting mentions of AL in context of managing security https://snyk.io/opensourcesecurity-2019/
2019-02-28 18:52:15 <danieli> Alpine Linux handles vulnerabilities differently than
2019-02-28 18:52:15 <danieli> the other major distros, who prefer to backport sets
2019-02-28 18:52:16 <danieli> of patches. At Alpine, they prefer rapid release cycles
2019-02-28 18:52:16 <danieli> for their images, with each image release providing a
2019-02-28 18:52:16 <danieli> system library upgrade.
2019-02-28 18:52:29 <danieli> and no sec advisory program
2019-02-28 18:53:00 <danieli> still an interesting mention, yeah
2019-02-28 19:06:28 <mps> clandmeter: you mentioned yesterday morning some PR on github regarding llvm/clang. I just looked at it and I'm puzzled. What is these PR? from some official developers or random people?
2019-02-28 19:08:02 <mps> I see there is even crystal PR for 0.27.2
2019-02-28 19:08:27 <mps> eh, PR for crystal 0.27.2
2019-02-28 19:10:25 <mps> I have feeling that I waste effort on these because I work alone and there are some people trying to do same. why we do not work together?
2019-02-28 19:10:58 <SpaceToast> probably because they don't know you exist
2019-02-28 19:11:05 <SpaceToast> just as you did not know they exist
2019-02-28 19:11:49 <SpaceToast> feel free to invite them and work on things together :)
2019-02-28 19:12:20 <mps> eh, I noticed jirutka there
2019-02-28 19:12:43 <SpaceToast> he doesn't talk around here very much
2019-02-28 19:12:51 <mps> so, he is still active, in some way with Alpine
2019-02-28 19:12:53 <SpaceToast> there was apparently some event before I came around that led to that
2019-02-28 19:13:09 <SpaceToast> my understanding is he avoids communication with other core devs since said event
2019-02-28 19:13:35 <mps> I remember what happened but thought he left Alpine
2019-02-28 19:14:43 <SpaceToast> I'm not even sure when it was :) I've been doing alpine-related things for quite a while now (at least ~1-1.5 years), but I haven't bothered to do anything with upstream until a few months ago
2019-02-28 19:14:49 <SpaceToast> and I was still involved with gentoo at the time, most likely
2019-02-28 19:15:02 <SpaceToast> (now I only really watch openrc and musl)
2019-02-28 19:15:29 <SpaceToast> either way, I'm pretty sure he still does things, though the scope may be different
2019-02-28 19:15:32 <kaniini> i don't think it is productive to discuss the situation with jirutka
2019-02-28 19:16:40 <mps> well, after all I think Alpine needs better collaboration platform desperately
2019-02-28 19:16:42 <SpaceToast> the discussion is about communication channels between various contributors, jirutka is a side-topic (due to said channels being broken)
2019-02-28 19:17:14 <SpaceToast> I've many ideas as to how we could better organize alpine, but I don't think anyone asked (nor plans to ask) me, so I'm mostly keeping them to myself :)
2019-02-28 19:17:15 <kaniini> mps: the issue is not collaboration platforms, the issue is ... something else entirely
2019-02-28 19:18:02 <mps> kaniini: I don't talk about jirutka case, but in general
2019-02-28 19:18:12 <kaniini> as for collaboration, yes
2019-02-28 19:18:17 <kaniini> better tools are needed
2019-02-28 19:18:33 <kaniini> but that specific case is not a good justification
2019-02-28 19:19:06 <kaniini> the issue is that he wishes to use these collaboration tools in a way which bends what is acceptable under the CoC
2019-02-28 19:19:21 <andypost[m]> mps, what you mean under platform? hosted gitlab/gitea/im?
2019-02-28 19:19:40 <mps> andypost[m]: I'm for gitlab, of course
2019-02-28 19:19:44 <kaniini> changing the tools would not change the problem
2019-02-28 19:20:04 <kaniini> in that case
2019-02-28 19:20:05 <kaniini> :)
2019-02-28 19:20:05 <SpaceToast> I agree with kaniini, it's more of a policy/direction problem
2019-02-28 19:20:15 <SpaceToast> it should be encouraged to communicate, rather than just throw patches into the pile
2019-02-28 19:20:33 <kaniini> yes, and
2019-02-28 19:20:48 <SpaceToast> I think we could benefit from some structure as well
2019-02-28 19:20:48 <kaniini> a lot of the reason why communication is not so great is actually because
2019-02-28 19:20:51 <mps> kaniini: problems will always arise with people who have strong will, but that could be solved. at the end we all are 'grown' people
2019-02-28 19:20:54 <kaniini> people would submit things for review
2019-02-28 19:21:01 <kaniini> and then other people who will go unnamed
2019-02-28 19:21:10 <kaniini> would come into the PR or whatever
2019-02-28 19:21:22 <kaniini> and start asking questions like "are you smoking crack?!?!?!?!?!?!"
2019-02-28 19:21:27 <kaniini> which is what lead to the CoC
2019-02-28 19:21:37 <kaniini> of course CoC is not a complete fix
2019-02-28 19:21:44 <SpaceToast> ah, I see
2019-02-28 19:21:52 <kaniini> and, the damage was already sustained of course
2019-02-28 19:22:18 <mps> I'm not for CoC, because I think it couldn't solve any serious problem
2019-02-28 19:22:36 <kaniini> so the compromise was eventually that [unnamed person] would be allowed to remain on core on the condition they do not interact with anyone
2019-02-28 19:23:07 <kaniini> which is a shame, but
2019-02-28 19:23:21 <kaniini> point being that there is no technical solution
2019-02-28 19:23:33 <SpaceToast> well, that's the specific case
2019-02-28 19:23:44 <SpaceToast> the general case (as in, the one that started the conversation) is quite different
2019-02-28 19:23:46 <mps> I'm for platform/workflow which allow and encourage more communication and more collaboration
2019-02-28 19:24:27 <kaniini> sure
2019-02-28 19:24:42 <kaniini> i am just saying that 95% of the time, the problem isn't that
2019-02-28 19:24:56 <mps> there is no techical solution for social problems and never will be. social problems should be resolved 'social' way
2019-02-28 19:25:06 <kaniini> what needs to be done is actually 'team maintenance'
2019-02-28 19:25:10 <kaniini> for most packages
2019-02-28 19:25:18 <kaniini> like other distros have done
2019-02-28 19:25:23 <mps> agreed
2019-02-28 19:25:29 <kaniini> but there is not yet consensus for it
2019-02-28 19:25:36 <SpaceToast> kaniini: I was going to suggest an approach towards that, yes
2019-02-28 19:25:40 <kaniini> and i rather spend my time working on things which have less friction
2019-02-28 19:25:42 <SpaceToast> once I got to documenting it in the developer parts :)
2019-02-28 19:25:53 <SpaceToast> and I would still rather go over / suggest it then ^^
2019-02-28 19:26:01 <SpaceToast> but yes, this is an obvious problem area that needs to be solved
2019-02-28 19:26:14 <kaniini> well
2019-02-28 19:26:19 <kaniini> anyone can start a discussion
2019-02-28 19:26:27 <SpaceToast> yeah, it'll just be topical at the time
2019-02-28 19:26:30 <kaniini> you don't have to convince me :)
2019-02-28 19:26:40 <SpaceToast> (and the resolution will be needed, since I'll need SOMETHING to write down :D )
2019-02-28 19:26:48 <SpaceToast> ^^ good to know kaniini
2019-02-28 19:27:39 <kaniini> however
2019-02-28 19:28:08 <kaniini> in my own personal opinion, i don't think it helps morale that the person who used to come into reviews and ask if people were smoking crack
2019-02-28 19:28:11 <kaniini> is still on core
2019-02-28 19:29:56 <kaniini> but as i said, i'd rather spend my time pursuing things which have less friction
2019-02-28 19:30:12 <SpaceToast> that is fair
2019-02-28 19:30:52 <mps> I'm not in favor for strict or rigid rules because I think we can work and manage some people who are not well socialy 'grown'
2019-02-28 19:31:42 <mps> imo, we need better communication and colaboration, be it platform or whatever
2019-02-28 19:31:56 <kaniini> mps: i would not define the Alpine CoC as 'strict' or 'rigid'
2019-02-28 19:32:09 <SpaceToast> it's worded quite strangely
2019-02-28 19:32:10 <kaniini> mps: it is, quite literally, "don't be a dick" spelled out in a more defined way
2019-02-28 19:32:19 <SpaceToast> but enforcement is clearly done appropriately, so I don't mind :)
2019-02-28 19:33:10 <kaniini> but yes
2019-02-28 19:33:13 <kaniini> my suggestion would be
2019-02-28 19:33:20 <kaniini> write up a proposal for team maintenance
2019-02-28 19:33:34 <mps> kaniini: that is quite acceptable. but for grown people I suspect that even this simple rule is needed. I is assumed in most if not all cultures over world
2019-02-28 19:33:58 <kaniini> mps: and as has been demonstrated, it is unfortunately needed
2019-02-28 19:34:02 <SpaceToast> kaniini: as mentioned, I already have one (not in writing, but it shouldn't take long to put it down); I'm just waiting until the user handbook is fully finished, published, and I start on the developer docs
2019-02-28 19:34:18 <kaniini> SpaceToast: okay, well
2019-02-28 19:34:25 <kaniini> in 2030 when this is done
2019-02-28 19:34:31 <SpaceToast> hah
2019-02-28 19:34:32 <kaniini> i'll give it my support
2019-02-28 19:34:41 <SpaceToast> I expect mid-late March
2019-02-28 19:34:44 <SpaceToast> hopefully
2019-02-28 19:34:58 <SpaceToast> user docs are content-complete (for now), I'm just editing them up to my standards
2019-02-28 19:35:09 <SpaceToast> after that I have to get the UI figured out, and that'll be it
2019-02-28 20:03:24 <jwh> *cough*
2019-02-28 20:03:25 <jwh> :D
2019-02-28 20:03:52 <SpaceToast> hey jwh, what's up? :)
2019-02-28 20:04:56 <jwh> guess!
2019-02-28 20:05:07 <SpaceToast> you got something working
2019-02-28 20:05:09 <SpaceToast> what is it?
2019-02-28 20:05:11 <jwh> no
2019-02-28 20:05:19 <jwh> just grumbling at PRs again :D
2019-02-28 20:05:22 <SpaceToast> ah
2019-02-28 20:05:38 <jwh> was just reading the drone log again
2019-02-28 20:05:44 <jwh> can't see why it broke/breaks
2019-02-28 20:06:26 <jwh> but since its fine and a no-op for the broken arch anyway, merge pretty please :D
2019-02-28 20:07:47 <mps> jwh: I installed x86 lxc and will look at problem, and not that I don't believe you but just want to see how it works in controlled ENV
2019-02-28 20:08:18 <jwh> lol
2019-02-28 20:08:19 <jwh> ok
2019-02-28 20:08:59 <mps> but now working to check llvm6 with gcc 8.3, when that finish I'll try android-tools
2019-02-28 20:09:37 <mps> SpaceToast: have you seen in testing?
2019-02-28 20:09:49 <SpaceToast> have I seen what?
2019-02-28 20:09:55 <mps> iwd ***
2019-02-28 20:10:08 <SpaceToast> ah, no
2019-02-28 20:10:17 <SpaceToast> as mentioned, I'm nonstop busy because of $dayjob->move()
2019-02-28 20:10:25 <jwh> :(
2019-02-28 20:10:30 <SpaceToast> I'm only really partially here in between waiting for containers to come up / down / stuff to install / etc
2019-02-28 20:10:31 <mps> eh, understand you
2019-02-28 20:10:35 <SpaceToast> had a day off yesterday though!
2019-02-28 20:10:38 <jwh> I'm really busy as well, sucks eh
2019-02-28 20:10:44 <SpaceToast> easy ~20+ commits to docs
2019-02-28 20:10:59 <jwh> some invoices got paid today though, so I'm having tomorrow off :D
2019-02-28 20:11:01 <mps> I thought you want to try it ASAP
2019-02-28 20:11:16 <SpaceToast> oh, I'm sorry I gave you that impression
2019-02-28 20:11:26 <SpaceToast> I'm using my dedicated AP while I figure the iwd situation out
2019-02-28 20:11:46 <mps> really, then sorry because I bothered you with it
2019-02-28 20:12:11 <jwh> next on my list: replacing prtg
2019-02-28 20:12:16 <jwh> this will be a fun one
2019-02-28 20:12:28 <SpaceToast> oh pinging me is fine
2019-02-28 20:12:33 <SpaceToast> as long as it's not middle of the night for me :)
2019-02-28 20:12:37 <mps> SpaceToast: I thought you want to test it because of writing user docs
2019-02-28 20:12:43 <SpaceToast> (in case it isn't known, I'm in EST (-5))
2019-02-28 20:12:56 <SpaceToast> that's on my TODO list, but I'm happy with the current contents of the user docs
2019-02-28 20:13:00 <SpaceToast> it'll be something I add in later
2019-02-28 20:13:16 <SpaceToast> atm I'm trying to edit them to a proper standard so they can be officially published :)
2019-02-28 20:13:20 <mps> EST -5, you live in Atlantic ocean?
2019-02-28 20:13:29 <jwh> lol
2019-02-28 20:13:31 <jwh> east coast
2019-02-28 20:13:37 <mps> Grenland?
2019-02-28 20:13:47 <SpaceToast> Montreal, Canad
2019-02-28 20:13:49 <SpaceToast> a
2019-02-28 20:14:01 <SpaceToast> I live on an island in the middle of a gigantic river :)
2019-02-28 20:14:06 <mps> ah, not far from Grenland :)
2019-02-28 20:14:16 <SpaceToast> not that far, no, but it's quite a bit north
2019-02-28 20:15:04 <jwh> ugh, blogflare suck so bad
2019-02-28 20:15:08 <mps> because that you are active at late night from CET
2019-02-28 20:15:18 <SpaceToast> yes, it's not actually that late for me ^^
2019-02-28 20:15:28 <mps> now, understrand
2019-02-28 20:15:38 <SpaceToast> I usually fall asleep before 2AM EST, which is 8AM CET
2019-02-28 20:15:51 <SpaceToast> so by the time you are likely to wake up I have likely fallen asleep
2019-02-28 20:16:11 <mps> nice to know to not bother you too early :)
2019-02-28 20:16:34 <SpaceToast> :)
2019-02-28 20:18:13 <jwh> well.... I'm about to start my first production container, better work
2019-02-28 20:20:00 <jwh> need to figure out what to replace PRTG with though, hm
2019-02-28 20:36:18 <jwh> hm, lxd only works with simple bridges right?
2019-02-28 20:36:36 <jwh> like, it's not even able to configure vlan aware bridges right?
2019-02-28 20:37:02 <ncopa> lxc used to support alot of different network configs
2019-02-28 20:37:27 <jwh> well I'd imagine it still does, but lxd doesn't seem to be able to configure much on its own
2019-02-28 20:37:31 <ncopa> iirc also included openvswitch, which can do vlans and stuff
2019-02-28 20:38:03 <jwh> yeah, I was gonna use ovs, but a vlan aware bridge will do just as well if lxd can be told to configure it
2019-02-28 20:38:29 <jwh> doesn't look like it supports anything except host or adding veth to a bridge
2019-02-28 20:38:33 <jwh> sigh
2019-02-28 20:38:41 <ncopa> you mean bindge an interface and also bridge all the vlan on top ov it?
2019-02-28 20:39:00 <jwh> not quite, in modern kernels the bridge driver also supports vlans
2019-02-28 20:39:12 <jwh> so you can just add interfaces to a bridge, then set pvid and tagged interfaces for bridge members
2019-02-28 20:39:16 <jwh> rather than seperate bridges per vlan
2019-02-28 20:39:32 <jwh> also supports vepa and pvlan type stuff etc
2019-02-28 20:40:00 <jwh> and obviously its much faster than ovs as ovs slows right down if you use it as a l2 switch
2019-02-28 20:40:12 <SpaceToast> jwh: lxd can't manage vlan tags, but it can use prepared bridges
2019-02-28 20:40:30 <jwh> yeah, I was hoping for at least bridge vlan support
2019-02-28 20:40:44 <jwh> maybe I can make it exec something on start?
2019-02-28 20:40:44 <SpaceToast> you can always just make a bridge per vlan and save them as separate networks
2019-02-28 20:40:54 <jwh> yeah I was trying to avoid that as its messy heh
2019-02-28 20:41:12 <SpaceToast> and of course you can just make vlans inside the container
2019-02-28 20:41:19 <SpaceToast> you just get the raw interface, after all
2019-02-28 20:42:01 <jwh> yeah
2019-02-28 20:42:24 <jwh> but the whole point of doing it in the bridge is that its still host controlled and it doesn't require guests to care (which they shouldn't really)
2019-02-28 20:43:12 <jwh> [root@tinkerbell ~]# bridge vlan | grep veth
2019-02-28 20:43:12 <jwh> vethWBFLWD       1 PVID Egress Untagged
2019-02-28 20:43:12 <jwh> veth454ABP       1 PVID Egress Untagged
2019-02-28 20:43:17 <jwh> guess manually isn't an option either :D
2019-02-28 20:44:50 <jwh> the bridge driver pretty became a sort-of switch
2019-02-28 20:44:55 <ncopa> i wonder if #alpine-linux may be a better place for lxc configuration discussion
2019-02-28 20:44:59 <jwh> probably
2019-02-28 20:45:10 <ncopa> i have tagged new snapshot release
2019-02-28 20:45:31 <jwh> hm actually, maybe you can shed some light on this drone weirdness
2019-02-28 20:46:20 <jwh> oh cool
2019-02-28 20:46:49 <ncopa> mps: i was wrong about the linux-headers depend, i think the problem i had was something else
2019-02-28 20:48:07 <jwh> I opened a 2nd pr, did the same thing :(
2019-02-28 20:48:21 <jwh> pretty sure its drone related but I can't fix it ofc
2019-02-28 20:50:59 <mps> ncopa: it is not problem as I see, linux-headers are pulled anyway because of libffi dependency
2019-02-28 20:52:19 <mps> I noted that just to learn how to set similar dependencies in future. btw, thank you for fast fix of ell. I was on trip and couldn't help
2019-02-28 20:52:44 <mps> and fix for iwd, of course
2019-02-28 20:53:41 <mps> ncopa: another note regarding llvm6, it passed on aarch64 with gcc 8.3, right now testing on x86_64
2019-02-28 20:56:51 <Mis012[m]> ncopa: Can I do something to speed up the btmgmt issue? I don't have much else to work on tomorrow anyway
2019-02-28 20:57:49 <ncopa> mps: nice
2019-02-28 20:58:25 <ncopa> Mis012[m]: sorry but that have been down prioritized.
2019-02-28 20:58:44 <ncopa> Mis012[m]: you could possbly ask upstream about what plan they have for the alternative tool
2019-02-28 20:58:48 <ncopa> and what the status is for it
2019-02-28 20:59:03 <ncopa> might be its already done. it is years since they reverted the commit
2019-02-28 20:59:15 <ncopa> then you could ask them to include it again
2019-02-28 20:59:57 <Mis012[m]> Good thing I don't have anything better to do :)
2019-02-28 21:00:08 <ncopa> if upstream still dont want to include btmbmt, then we could create a separate subpackage named bluez-btmgmt, or maybe just "btmgmt"
2019-02-28 21:00:22 <ncopa> i dont hitnk we want install all the tools like arch does
2019-02-28 21:00:39 <mps> Mis012[m]: what is with bluez, in what shape and state it is, do you know
2019-02-28 21:00:47 <ncopa> yeah, its good if you can help with communication with upstream
2019-02-28 21:01:12 <ncopa> bluez works sort of, at least with my apple keyboard
2019-02-28 21:01:23 <Mis012[m]> I have no affiliation with bluez
2019-02-28 21:01:35 <_ikke_> mps: afaik, they are in the middle of a transition, but it's down halfway (already removing / deprecating things without providing alternatives)
2019-02-28 21:02:12 <_ikke_> See https://wiki.archlinux.org/index.php/Bluetooth#Deprecated_BlueZ_tools for an overview
2019-02-28 21:02:21 <mps> I'm asking because i read that it will be somehow 'integraded' with iwd
2019-02-28 21:03:04 <ncopa> i think bluetoothctl solved the problem with a simple agent, to pari/unpair, connect/disconnect etc
2019-02-28 21:03:22 <jwh> it's a mess
2019-02-28 21:03:46 <jwh> fully expect iwd to receive similar treatment
2019-02-28 21:03:54 <jwh> since intel made bluez broken too
2019-02-28 21:04:28 <mps> I read that iwd intention is to be all radio/wireless devices controler in Linux
2019-02-28 21:04:51 <Mis012[m]> again, why can't we have nice things :(
2019-02-28 21:04:58 <mps> read somewhere but forgot url
2019-02-28 21:05:20 <jwh> mps: of course it is
2019-02-28 21:05:25 <_ikke_> ncopa: I have a bluetooth serial adapter that you need one of the deprecated tools to use
2019-02-28 21:05:35 <jwh> because then they can exert their desires on it
2019-02-28 21:05:57 <_ikke_> I believe rfcomm. I haven't found a way to use the newer toosl to use it
2019-02-28 21:06:07 <jwh> there isn't any newer tool
2019-02-28 21:06:18 <jwh> same for the rest of the tools they deprecated
2019-02-28 21:06:23 <Mis012[m]> _ikke_: shouldn't it be standard enough not to need userspace?
2019-02-28 21:06:25 <jwh> it's ridiculous
2019-02-28 21:06:38 <mps> I stopped to play with bluetooth few years ago, wires are more stable :)
2019-02-28 21:06:39 <jwh> you need rfcomm to expose serial over bluetooth
2019-02-28 21:06:43 <jwh> there is no alternative
2019-02-28 21:06:59 <_ikke_> mps: Not sure how I would achieve that
2019-02-28 21:07:11 <Mis012[m]> there is e.g bt hid subsystem
2019-02-28 21:07:17 <ncopa> i htink we have the deprecated tools in a separate package
2019-02-28 21:07:23 <jwh> none of that will connect services
2019-02-28 21:07:37 <jwh> it isn't a hid, for a start ;)
2019-02-28 21:07:54 <Mis012[m]> <freenode_nco "i htink we have the deprecated t"> some of them definitely
2019-02-28 21:08:12 <jwh> argh my regex isn't working
2019-02-28 21:08:28 <jwh> it's supposed to filter out that ridiculous quoting
2019-02-28 21:08:29 <Mis012[m]> <freenode_jwh "it isn't a hid, for a start ;)"> of course :P but usb to serial exposes tty as well
2019-02-28 21:08:38 <jwh> what
2019-02-28 21:08:56 <mps> Mis012[m]: please do not quote, messages are already here
2019-02-28 21:09:07 <jwh> not only do not quote, that is *horrible*
2019-02-28 21:09:10 <jwh> what client is that
2019-02-28 21:09:15 <SpaceToast> jwh: it's matrix
2019-02-28 21:09:20 <SpaceToast> and this is why no one likes it
2019-02-28 21:09:20 <jwh> oh, that nonsense
2019-02-28 21:09:21 <jwh> explains it all
2019-02-28 21:09:27 <Mis012[m]> I alway forget :/
2019-02-28 21:09:45 <jwh> not only is it ugly, it doesn't even have the full nick
2019-02-28 21:09:46 <jwh> ...
2019-02-28 21:10:30 <jwh> I did have matrix on my ignore list for similar reasons, since out of the 100s of matrix connections very few are real users because why bother when you can just use a normal client
2019-02-28 21:10:33 <Mis012[m]> this is clearly irc, they could consider not using such format :(
2019-02-28 21:11:09 <jwh> yes
2019-02-28 21:11:19 <_ikke_> Today my 4GB VM ran out of ram + swap because I kept slack open
2019-02-28 21:11:25 <jwh> lol
2019-02-28 21:11:35 <jwh> web 2.0 is awesome
2019-02-28 21:12:07 <Mis012[m]> but Riot for android is not electron :)
2019-02-28 21:13:26 <ncopa> someone once said that alpine docker image is smaller than the docker web page :)
2019-02-28 21:13:43 <Mis012[m]> :D
2019-02-28 21:13:48 <ncopa> due to its web 2.0 stuff
2019-02-28 21:14:08 <jwh> lol
2019-02-28 21:14:12 <jwh> probably
2019-02-28 21:14:31 <mps> ah, here it is 'Marcel Holtmann, the maintainer of the BlueZ Bluetooth daemon since 2004' and Marcel is also iwd developer
2019-02-28 21:14:45 <mps> https://www.linux.com/news/event/ELCE/2017/new-linux-wifi-daemon-streamlines-networking-stack
2019-02-28 21:14:53 <Mis012[m]> I remember when I thought web 2.0 was a good idea... I feel old
2019-02-28 21:15:51 <ncopa> mps: ah that explains
2019-02-28 21:16:24 <Mis012[m]> “We decided to create a wireless daemon that actually works on IoT devices,”
2019-02-28 21:16:25 <Mis012[m]> GPLv3 pretty please
2019-02-28 21:16:38 <jwh> hm
2019-02-28 21:16:46 <_ikke_> what is iwd btw?
2019-02-28 21:16:47 <Mis012[m]> perfect combination
2019-02-28 21:16:48 <jwh> thats the guy that broke bluez I think
2019-02-28 21:16:52 <jwh> _ikke_: bluez, for wifi
2019-02-28 21:16:53 <jwh> D
2019-02-28 21:16:53 <mps> I think they told something in that line on #iwd channel
2019-02-28 21:16:54 <jwh> :D*
2019-02-28 21:17:09 <jwh> it even has the same config and cli style
2019-02-28 21:17:26 <Mis012[m]> whine
2019-02-28 21:17:27 <ncopa> same philosophy behind it
2019-02-28 21:17:28 <mps> _ikke_: Internet Wireless Daemon https://iwd.wiki.kernel.org/
2019-02-28 21:17:36 <ncopa> you save state in a local database
2019-02-28 21:17:38 <jwh> but good luck, it's all gonna be dbus
2019-02-28 21:17:45 <ncopa> eg you sabe which wifi you are connected to
2019-02-28 21:17:47 <SpaceToast> _ikke_: iwd is the official successor to wpa_supplicant
2019-02-28 21:17:50 <SpaceToast> by intel
2019-02-28 21:17:51 <ncopa> and when you restart it reconnects
2019-02-28 21:18:07 <_ikke_> SpaceToast: ah ok
2019-02-28 21:18:08 <jwh> like... already happens with wpa_supplicant
2019-02-28 21:18:10 <ncopa> wpa_supplicant does not save any state
2019-02-28 21:18:12 <jwh> just order networks
2019-02-28 21:18:31 <mps> and appeared today in testing, thanks to ncopa help :)
2019-02-28 21:18:33 <jwh> or, like many tools already do, just write out the config on demand
2019-02-28 21:18:48 <_ikke_> I wonder btw when the fix readline for bluetoothctl, it's horribly broken
2019-02-28 21:18:55 <_ikke_> s/the/they
2019-02-28 21:18:55 <alpine-meetbot> _ikke_ meant to say: I wonder btw when they fix readline for bluetoothctl, it's horribly broken
2019-02-28 21:18:59 <jwh> _ikke_: heh
2019-02-28 21:19:15 <Mis012[m]> The daemon is difficult to use because it adds support for “just about every OS or wireless extension,” including many things that are never actually used, says Holtmann.
2019-02-28 21:19:19 <jwh> it keeps biting me, as enter doesn't work
2019-02-28 21:19:31 <jwh> Mis012[m]: what does, wpa_supplicant?
2019-02-28 21:19:45 <jwh> I mean sure, who needs .1x
2019-02-28 21:19:47 <jwh> :D
2019-02-28 21:19:48 <ncopa> i have some thoughts and ideas how to implement xfce-bluetooth, but i have never had the time to finish it
2019-02-28 21:19:57 <Mis012[m]> jwh: yeah...
2019-02-28 21:20:10 <mps> iwd is intended for ophono and Ethernet (wired) Auth also
2019-02-28 21:20:31 <jwh> lennart has nothing on this guy
2019-02-28 21:20:36 <Mis012[m]> we need wpa_supplicant for bluetooth, not the other way around
2019-02-28 21:20:37 <mps> also, sim cards and 5G
2019-02-28 21:20:42 <jwh> this guy is singlehandedly breaking all connectivity
2019-02-28 21:21:03 <Mis012[m]> mps: whine
2019-02-28 21:21:19 <mps> Mis012[m]:who? :)
2019-02-28 21:21:22 <jwh> you mean ofono thats alreasd broken
2019-02-28 21:21:25 <jwh> already*
2019-02-28 21:21:36 <jwh> and 802.1x that works absolutely fine and has done for many yers
2019-02-28 21:21:39 <jwh> years*
2019-02-28 21:21:52 <Mis012[m]> mps: me... smells like EEE
2019-02-28 21:21:53 <mps> jwh: tell me one software thing which are not broken
2019-02-28 21:21:58 <jwh> all of these require dbus btw
2019-02-28 21:22:07 <jwh> at some point it's not going to work on non-systemd
2019-02-28 21:22:09 <jwh> just saying
2019-02-28 21:22:22 <ncopa> this discussion is not productive for development
2019-02-28 21:22:42 <ncopa> i wonder why the release i just tagged does not show up on master mirror
2019-02-28 21:22:46 <ncopa> something mube be broken
2019-02-28 21:22:51 <jwh> it *is* about development though, someone will have to maintain it heh
2019-02-28 21:24:14 <Mis012[m]> “We extended ELL with cryptographic support libraries instead of using OpenSSL, which is huge, and is not an easy interface,”
2019-02-28 21:24:22 <jwh> lol
2019-02-28 21:24:30 <Mis012[m]> jesus...
2019-02-28 21:24:52 <Mis012[m]> it's not even funny
2019-02-28 21:26:28 <ncopa> ell already have utf8 utils
2019-02-28 21:26:52 <ncopa> which had interesting bugs that only appeared on some arches
2019-02-28 21:28:04 <ncopa> ok, so the new release snashot didnt show up because i didnt tag it
2019-02-28 21:28:09 <ncopa> stupid me
2019-02-28 21:28:26 <_ikke_> releases are hard
2019-02-28 21:28:29 <ncopa> i misspelled git -> gti
2019-02-28 21:28:33 <ncopa> and didnt notice
2019-02-28 21:28:49 <ncopa> it means i should probably just go to bed
2019-02-28 21:29:53 <jwh> lol
2019-02-28 21:30:00 <jwh> perhaps
2019-02-28 21:33:15 <mps> ncopa: llvm6 on x86_64 edge: 'apk update' 'apk upgrade' that means gcc 8.3 . then 'abuild deps unpack prepare build check' result is here: http://tpaste.us/aREq
2019-02-28 21:46:59 <clandmeter> jwh: >>> ERROR: android-tools: build failed
2019-02-28 21:47:11 <clandmeter> thats on my local x86 builder on lxc
2019-02-28 21:48:22 <mps> clandmeter: just tried on my local with same result
2019-02-28 21:59:48 <mps> jwh: android-tools fails locally on x86, boringssl is the problem
2019-02-28 22:00:11 <jwh> hm
2019-02-28 22:00:18 <jwh> on real x86 hardware?
2019-02-28 22:00:30 <jwh> because it succeeds on x86 lxc
2019-02-28 22:00:36 <_ikke_> it's real hardware
2019-02-28 22:00:43 <jwh> in fact
2019-02-28 22:00:43 <mps> no, lxc on x86_64
2019-02-28 22:00:49 <jwh> I'm just not going to use x86 because its ambigious and silly
2019-02-28 22:00:51 <jwh> i386
2019-02-28 22:00:59 <jwh> ambiguous*
2019-02-28 22:01:08 <jwh> mps: why does yours fail?
2019-02-28 22:01:10 <jwh> mine does not
2019-02-28 22:01:21 <jwh> and
2019-02-28 22:01:28 <jwh> its packaged, so it builds fine
2019-02-28 22:01:29 <mps> like one on drone you posted last night
2019-02-28 22:01:38 <clandmeter> mine does drone does and mps does.
2019-02-28 22:02:04 <jwh> [root@tinkerbell ~]# lxc exec -- abuild-i386 uname -a
2019-02-28 22:02:05 <jwh> Linux abuild-i386 4.20.12-arch1-1-ARCH #1 SMP PREEMPT Sat Feb 23 15:11:34 UTC 2019 i686 Linux
2019-02-28 22:02:56 <jwh> see, x86_32
2019-02-28 22:03:01 <jwh> x32?
2019-02-28 22:03:04 <jwh> i3x6?
2019-02-28 22:03:29 <jwh> anyway, not relevant to the PR, so don't care either way heh
2019-02-28 22:03:50 <mps> wait, you are building on ArchLinux?
2019-02-28 22:03:58 <jwh> ...
2019-02-28 22:04:00 <jwh> no
2019-02-28 22:04:16 <mps> Linux abuild-i386 4.20.12-arch1-1-ARCH
2019-02-28 22:04:32 <jwh> containers share the host kernel, obviously
2019-02-28 22:05:01 <mps> then this info is useless
2019-02-28 22:05:14 <jwh> no it isn't
2019-02-28 22:05:18 <jwh> it shows arch
2019-02-28 22:05:19 <_ikke_> containers are not virtual machines, I cannot repeat that often enough :P
2019-02-28 22:05:41 <jwh> hence why I asked if it was real hardware or not
2019-02-28 22:06:01 <SpaceToast> _ikke_: containers are virtual machines minus the suck ;)
2019-02-28 22:06:02 <jwh> in case it was something that differs between i386 kernel and 32 bit userland on a 64bit kernel
2019-02-28 22:06:37 <mps> kernel doesn't play role in building
2019-02-28 22:06:46 <jwh> ...
2019-02-28 22:06:50 <jwh> k i'm out
2019-02-28 22:07:01 <mps> toolchain and libs are important
2019-02-28 22:07:16 <jwh> what are toolchain and libs?
2019-02-28 22:07:17 <jwh> userland
2019-02-28 22:07:18 <jwh> jesus
2019-02-28 22:07:43 <clandmeter> jwh: i need to correct myself, it does build.
2019-02-28 22:07:49 <jwh> I know it builds
2019-02-28 22:07:50 <jwh> :)
2019-02-28 22:08:07 <jwh> I know it does because its in the repo
2019-02-28 22:08:25 <mps> clandmeter: edge or 3.9
2019-02-28 22:08:44 <jwh> and the PR is a no-op for non-arm
2019-02-28 22:09:09 <jwh> all this messing about is just muddying the ater
2019-02-28 22:09:10 <clandmeter> not sure what happens on drone
2019-02-28 22:09:11 <jwh> water*
2019-02-28 22:09:18 <clandmeter> could be it runs in 64 bit mode
2019-02-28 22:09:22 <clandmeter> need to check
2019-02-28 22:09:48 <jwh> I just suggested that, but it would appear it spawns an amd64 container with 32bit userland
2019-02-28 22:09:55 <jwh> which is how I'm building
2019-02-28 22:11:26 <clandmeter> yes it does, i think drone doesnt support 32bit container
2019-02-28 22:11:39 <clandmeter> so only userland is 32bit
2019-02-28 22:11:45 <jwh> hm
2019-02-28 22:12:19 <jwh> so could it be that terriblessl sees amd64 and completely manages to hose itself
2019-02-28 22:12:35 <clandmeter> yes i think thhats what happens
2019-02-28 22:12:37 <jwh> let me see....
2019-02-28 22:12:41 <clandmeter> takes uname
2019-02-28 22:12:46 <clandmeter> and messes things up
2019-02-28 22:13:07 <jwh> well thats a completely broken design choice by google (surprising!)
2019-02-28 22:13:26 <clandmeter> i also see other distros ship a different version of boringssl
2019-02-28 22:13:47 <jwh> ok so, whatever builds the packages that end up in the repo
2019-02-28 22:13:55 <jwh> does that use a 32bit container?
2019-02-28 22:14:05 <jwh> or is it a vm, or what?
2019-02-28 22:14:06 <clandmeter> builder should be fine
2019-02-28 22:14:12 <jwh> well it is, thats why I'm asking
2019-02-28 22:14:12 <clandmeter> same as what i just did
2019-02-28 22:14:20 <jwh> since it manages to build ok
2019-02-28 22:14:23 <jwh> ok
2019-02-28 22:14:43 <jwh> alright so boringssl is dumb, can at least fix it now
2019-02-28 22:15:06 <clandmeter> i just copied the container so it didnt have correct lxc arch set
2019-02-28 22:15:40 <jwh> so if uname -m is x86_64, does it work if you do linux32 abuild?
2019-02-28 22:15:56 <clandmeter> yes my container is set to linux32
2019-02-28 22:16:03 <clandmeter> and builders should also
2019-02-28 22:16:08 <jwh> ok cool
2019-02-28 22:16:10 <jwh> so hm
2019-02-28 22:16:20 <jwh> should probably fix that in the drone ci config if possible
2019-02-28 22:16:33 <clandmeter> i cant
2019-02-28 22:16:37 <clandmeter> its not done by drone
2019-02-28 22:16:41 <jwh> if they don't set arch, can at least run builds under linux32
2019-02-28 22:16:59 <clandmeter> i could ask about it, maybe they can support it
2019-02-28 22:17:11 <jwh> I was looking for a list of platforms they support but I couldn't find one in their docs
2019-02-28 22:17:19 <clandmeter> docs are a bit vague
2019-02-28 22:17:21 <jwh> yeah
2019-02-28 22:17:58 <jwh> but if they really don't support 32bit containers, then modifying the build script is probably the only sensible way heh
2019-02-28 22:26:55 <jwh> clandmeter: your theory is correct
2019-02-28 22:26:56 <jwh> https://cloud.drone.io/alpinelinux/aports/146/1/2
2019-02-28 22:28:54 <jwh> sooo
2019-02-28 22:28:59 <jwh> mps: why does your lxc fail?
2019-02-28 22:29:15 <jwh> is the arch wrong?
2019-02-28 22:30:16 <mps> really don't know, it is first time i installed x86 lxc and tried anything with it
2019-02-28 22:30:25 <jwh> what does apk --print-arch say?
2019-02-28 22:30:32 <mps> x86
2019-02-28 22:30:32 <jwh> and uname -m
2019-02-28 22:31:10 <mps> x86_64
2019-02-28 22:31:14 <jwh> yeah
2019-02-28 22:31:18 <jwh> same problem as the drone builder
2019-02-28 22:31:56 <mps> why build depends on uname at all
2019-02-28 22:32:04 <jwh> exactly, it's broken
2019-02-28 22:32:31 <jwh> it's probably doing something stupid based on what it thinks the arch is, rather than letting the compiler get it right
2019-02-28 22:33:09 <mps> this is good to know before I start to build other packages on x86 lxc
2019-02-28 22:33:25 <jwh> your lxc isn't configured properly though really
2019-02-28 22:33:54 <jwh> [root@tinkerbell ~]# lxc exec -- abuild-i386 uname -m
2019-02-28 22:33:54 <jwh> i686
2019-02-28 22:34:02 <mps> could be, I converted it from chroot
2019-02-28 22:34:12 <jwh> ah
2019-02-28 22:34:19 <jwh> lxc should set the arch really
2019-02-28 22:34:35 <jwh> if you do linux32 abuild, it will work
2019-02-28 22:34:37 <mps> apk --print says it is set
2019-02-28 22:34:51 <clandmeter> apk doesnt look at uname
2019-02-28 22:35:09 <mps> but maybe somewhere in lxc config I have to set personality
2019-02-28 22:35:11 <clandmeter> apk --print-arch you mean right
2019-02-28 22:35:22 <jwh> yeah --print-arch isn't the same
2019-02-28 22:35:32 <jwh> but the question is where to fix it
2019-02-28 22:35:35 <clandmeter> thats the targetted arch it was build for
2019-02-28 22:35:45 <mps> look like they are synonim
2019-02-28 22:36:12 <clandmeter> jwh: docker doesnt seem to have a x86 version
2019-02-28 22:36:27 <clandmeter> so drone doesnt support it
2019-02-28 22:36:32 <jwh> ah
2019-02-28 22:37:05 <clandmeter> ill check with ncopa tomorrow
2019-02-28 22:37:11 <mps> clandmeter: btw, these drones looks nice, like looking in console/terminal during build
2019-02-28 22:37:32 <jwh> could just add a condition to build.sh, if arch is x86, either exec under linux32, or just set UNAME_m etc if thats enough?
2019-02-28 22:38:08 <clandmeter> its an option, but i like to discus it first.
2019-02-28 22:38:22 <jwh> yeah
2019-02-28 22:38:24 <clandmeter> im not much of a toolchain person.
2019-02-28 22:40:27 <clandmeter> so drone uses https://download.docker.com/linux/static/stable/
2019-02-28 22:40:43 <clandmeter> which doesnt provide x86
2019-02-28 22:41:08 <jwh> that explains why the drone config has platform: amd64
2019-02-28 22:41:17 <jwh> should probably make sure it looks like 32bit for x86 heh
2019-02-28 22:45:02 <clandmeter> bed time now. gnite
2019-02-28 22:45:06 <jwh> night